From 43c7ecb1fa6b45633747773f055b8deb1c3e52be Mon Sep 17 00:00:00 2001 From: Matt Ranostay Date: Wed, 3 Dec 2014 12:53:00 +0000 Subject: iio:as3935: Add DT binding docs for AS3935 driver Document compatible string, required and optional DT properties for AS3935 chipset driver. Signed-off-by: Matt Ranostay Acked-by: Rob Herring Signed-off-by: Jonathan Cameron --- .../devicetree/bindings/iio/proximity/as3935.txt | 28 ++++++++++++++++++++++ .../devicetree/bindings/vendor-prefixes.txt | 1 + 2 files changed, 29 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/proximity/as3935.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/proximity/as3935.txt b/Documentation/devicetree/bindings/iio/proximity/as3935.txt new file mode 100644 index 0000000..ae23dd8 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/proximity/as3935.txt @@ -0,0 +1,28 @@ +Austrian Microsystems AS3935 Franklin lightning sensor device driver + +Required properties: + - compatible: must be "ams,as3935" + - reg: SPI chip select number for the device + - spi-cpha: SPI Mode 1. Refer to spi/spi-bus.txt for generic SPI + slave node bindings. + - interrupt-parent : should be the phandle for the interrupt controller + - interrupts : the sole interrupt generated by the device + + Refer to interrupt-controller/interrupts.txt for generic + interrupt client node bindings. + +Optional properties: + - ams,tuning-capacitor-pf: Calibration tuning capacitor stepping + value 0 - 120pF. This will require using the calibration data from + the manufacturer. + +Example: + +as3935@0 { + compatible = "ams,as3935"; + reg = <0>; + spi-cpha; + interrupt-parent = <&gpio1>; + interrupts = <16 1>; + ams,tuning-capacitor-pf = <80>; +}; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 40ce2df..2025cee 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -11,6 +11,7 @@ ak Asahi Kasei Corp. allwinner Allwinner Technology Co., Ltd. altr Altera Corp. amcc Applied Micro Circuits Corporation (APM, formally AMCC) +ams AMS AG amstaos AMS-Taos Inc. apm Applied Micro Circuits Corporation (APM) arm ARM Ltd. -- cgit v1.1 From 24ddb0e4bba4e98d3f3a783846789520e796b164 Mon Sep 17 00:00:00 2001 From: Matt Ranostay Date: Wed, 3 Dec 2014 12:53:00 +0000 Subject: iio: Add AS3935 lightning sensor support AS3935 chipset can detect lightning strikes and reports those back as events and the estimated distance to the storm. Signed-off-by: Matt Ranostay Reviewed-by: Marek Vasut Signed-off-by: Jonathan Cameron --- Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 b/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 new file mode 100644 index 0000000..6708c5e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 @@ -0,0 +1,16 @@ +What /sys/bus/iio/devices/iio:deviceX/in_proximity_raw +Date: March 2014 +KernelVersion: 3.15 +Contact: Matt Ranostay +Description: + Get the current distance in meters of storm (1km steps) + 1000-40000 = distance in meters + +What /sys/bus/iio/devices/iio:deviceX/sensor_sensitivity +Date: March 2014 +KernelVersion: 3.15 +Contact: Matt Ranostay +Description: + Show or set the gain boost of the amp, from 0-31 range. + 18 = indoors (default) + 14 = outdoors -- cgit v1.1 From c0a6b7ee9498269e4bf9a7e6676f2f45edca2f1a Mon Sep 17 00:00:00 2001 From: Sebastian Reichel Date: Fri, 3 Oct 2014 17:25:00 +0100 Subject: iio: documentation: Add ABI documentation for *_mean_raw Add ABI documentation for in_*_mean_raw files, which are already supported and used in the kernel for some time. Signed-off-by: Sebastian Reichel Signed-off-by: Jonathan Cameron --- Documentation/ABI/testing/sysfs-bus-iio | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 6e02c50..58ba333 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -210,6 +210,14 @@ Contact: linux-iio@vger.kernel.org Description: Scaled humidity measurement in milli percent. +What: /sys/bus/iio/devices/iio:deviceX/in_X_mean_raw +KernelVersion: 3.5 +Contact: linux-iio@vger.kernel.org +Description: + Averaged raw measurement from channel X. The number of values + used for averaging is device specific. The converting rules for + normal raw values also applies to the averaged raw values. + What: /sys/bus/iio/devices/iio:deviceX/in_accel_offset What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_offset What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_offset -- cgit v1.1 From cb2d956dd329caa11b5ece454dc52253aa038e73 Mon Sep 17 00:00:00 2001 From: Luciano Coelho Date: Mon, 17 Feb 2014 16:52:35 +0200 Subject: cfg80211: refactor cfg80211_can_use_iftype_chan() Separate the code that counts the interface types and channels from the code that check the interface combinations. The new function that checks for combinations is exported so it can be called by the drivers. This is done in preparation for moving the interface combinations checks out of cfg80211. Signed-off-by: Luciano Coelho Signed-off-by: Johannes Berg --- Documentation/DocBook/80211.tmpl | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl index 044b764..d9b9416 100644 --- a/Documentation/DocBook/80211.tmpl +++ b/Documentation/DocBook/80211.tmpl @@ -100,6 +100,7 @@ !Finclude/net/cfg80211.h wdev_priv !Finclude/net/cfg80211.h ieee80211_iface_limit !Finclude/net/cfg80211.h ieee80211_iface_combination +!Finclude/net/cfg80211.h cfg80211_check_combinations Actions and configuration -- cgit v1.1 From 668678185247303450e60df14569f94cf5775fea Mon Sep 17 00:00:00 2001 From: Lukasz Pawelczyk Date: Tue, 11 Mar 2014 17:07:06 +0100 Subject: Smack: adds smackfs/ptrace interface This allows to limit ptrace beyond the regular smack access rules. It adds a smackfs/ptrace interface that allows smack to be configured to require equal smack labels for PTRACE_MODE_ATTACH access. See the changes in Documentation/security/Smack.txt below for details. Signed-off-by: Lukasz Pawelczyk Signed-off-by: Rafal Krypa --- Documentation/security/Smack.txt | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/security/Smack.txt b/Documentation/security/Smack.txt index 7a2d30c..5597917 100644 --- a/Documentation/security/Smack.txt +++ b/Documentation/security/Smack.txt @@ -204,6 +204,16 @@ onlycap these capabilities are effective at for processes with any label. The value is set by writing the desired label to the file or cleared by writing "-" to the file. +ptrace + This is used to define the current ptrace policy + 0 - default: this is the policy that relies on smack access rules. + For the PTRACE_READ a subject needs to have a read access on + object. For the PTRACE_ATTACH a read-write access is required. + 1 - exact: this is the policy that limits PTRACE_ATTACH. Attach is + only allowed when subject's and object's labels are equal. + PTRACE_READ is not affected. Can be overriden with CAP_SYS_PTRACE. + 2 - draconian: this policy behaves like the 'exact' above with an + exception that it can't be overriden with CAP_SYS_PTRACE. revoke-subject Writing a Smack label here sets the access to '-' for all access rules with that subject label. -- cgit v1.1 From cd6339e6ced387ad67b5551dd2931cfd7e8b970b Mon Sep 17 00:00:00 2001 From: Zhao Qiang Date: Tue, 1 Apr 2014 17:10:50 +0800 Subject: spi: add "spi-lsb-first" to devicetree add optional property devicetree for SPI slave nodes into devicetree so that LSB mode can be enabled by devicetree. Signed-off-by: Zhao Qiang Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/spi-bus.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt b/Documentation/devicetree/bindings/spi/spi-bus.txt index e5a4d1b..22d5740 100644 --- a/Documentation/devicetree/bindings/spi/spi-bus.txt +++ b/Documentation/devicetree/bindings/spi/spi-bus.txt @@ -55,6 +55,8 @@ contain the following properties. chip select active high - spi-3wire - (optional) Empty property indicating device requires 3-wire mode. +- spi-lsb-first - (optional) Empty property indicating device requires + LSB first mode. - spi-tx-bus-width - (optional) The bus width(number of data wires) that used for MOSI. Defaults to 1 if not present. - spi-rx-bus-width - (optional) The bus width(number of data wires) that -- cgit v1.1 From c754064453e0d48043bd6a111f5c1f8ef1b75f7e Mon Sep 17 00:00:00 2001 From: Nicolin Chen Date: Tue, 1 Apr 2014 19:34:09 +0800 Subject: ASoC: fsl_sai: Add imx6sx platform support The next coming i.MX6 Solo X SoC also contains SAI module while we use imp_pcm_init() for i.MX platform. So this patch adds one compatible route for imx6sx and updates the DT doc accordingly. Signed-off-by: Nicolin Chen Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/fsl-sai.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl-sai.txt b/Documentation/devicetree/bindings/sound/fsl-sai.txt index 98611a6..35c09fe 100644 --- a/Documentation/devicetree/bindings/sound/fsl-sai.txt +++ b/Documentation/devicetree/bindings/sound/fsl-sai.txt @@ -7,7 +7,7 @@ codec/DSP interfaces. Required properties: -- compatible: Compatible list, contains "fsl,vf610-sai". +- compatible: Compatible list, contains "fsl,vf610-sai" or "fsl,imx6sx-sai". - reg: Offset and length of the register set for the device. - clocks: Must contain an entry for each entry in clock-names. - clock-names : Must include the "sai" entry. -- cgit v1.1 From ca3e35c7a37cb59b12a1839d03c621cf8fa9a3d9 Mon Sep 17 00:00:00 2001 From: Nicolin Chen Date: Thu, 10 Apr 2014 23:26:15 +0800 Subject: ASoC: fsl_sai: Add clock controls for SAI The SAI mainly has the following clocks: bus clock control and configure registers and to generate synchronous interrupts and DMA requests. mclk1, mclk2, mclk3 to generate the bit clock when the receiver or transmitter is configured for an internally generated bit clock. So this patch adds these clocks and their clock controls to the driver. [ To concern the old DTB cases, I've added a bit of extra code to make the driver compatible with them. And by marking clock NULL if failed to get, the clk_prepare() or clk_get_rate() would easily return 0 so no further path should be broken. -- by Nicolin ] Signed-off-by: Nicolin Chen Acked-by: Xiubo Li Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/fsl-sai.txt | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl-sai.txt b/Documentation/devicetree/bindings/sound/fsl-sai.txt index 35c09fe..0f4e238 100644 --- a/Documentation/devicetree/bindings/sound/fsl-sai.txt +++ b/Documentation/devicetree/bindings/sound/fsl-sai.txt @@ -10,7 +10,8 @@ Required properties: - compatible: Compatible list, contains "fsl,vf610-sai" or "fsl,imx6sx-sai". - reg: Offset and length of the register set for the device. - clocks: Must contain an entry for each entry in clock-names. -- clock-names : Must include the "sai" entry. +- clock-names : Must include the "bus" for register access and "mclk1" "mclk2" + "mclk3" for bit clock and frame clock providing. - dmas : Generic dma devicetree binding as described in Documentation/devicetree/bindings/dma/dma.txt. - dma-names : Two dmas have to be defined, "tx" and "rx". @@ -30,8 +31,10 @@ sai2: sai@40031000 { reg = <0x40031000 0x1000>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_sai2_1>; - clocks = <&clks VF610_CLK_SAI2>; - clock-names = "sai"; + clocks = <&clks VF610_CLK_PLATFORM_BUS>, + <&clks VF610_CLK_SAI2>, + <&clks 0>, <&clks 0>; + clock-names = "bus", "mclk1", "mclk2", "mclk3"; dma-names = "tx", "rx"; dmas = <&edma0 0 VF610_EDMA_MUXID0_SAI2_TX>, <&edma0 0 VF610_EDMA_MUXID0_SAI2_RX>; -- cgit v1.1 From 908b7032a8b5cb7110beac213f7d3058097fa5aa Mon Sep 17 00:00:00 2001 From: Oder Chiou Date: Thu, 10 Apr 2014 10:57:35 +0800 Subject: ASoC: rt5640: Add the info of rt5639 to the binding document The patch adds the info of rt5639 to the binding document. Signed-off-by: Oder Chiou Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/rt5640.txt | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/rt5640.txt b/Documentation/devicetree/bindings/sound/rt5640.txt index 068a114..bac4d9a 100644 --- a/Documentation/devicetree/bindings/sound/rt5640.txt +++ b/Documentation/devicetree/bindings/sound/rt5640.txt @@ -1,10 +1,10 @@ -RT5640 audio CODEC +RT5640/RT5639 audio CODEC This device supports I2C only. Required properties: -- compatible : "realtek,rt5640". +- compatible : One of "realtek,rt5640" or "realtek,rt5639". - reg : The I2C address of the device. @@ -18,7 +18,7 @@ Optional properties: - realtek,ldo1-en-gpios : The GPIO that controls the CODEC's LDO1_EN pin. -Pins on the device (for linking into audio routes): +Pins on the device (for linking into audio routes) for RT5639/RT5640: * DMIC1 * DMIC2 @@ -31,13 +31,16 @@ Pins on the device (for linking into audio routes): * HPOR * LOUTL * LOUTR - * MONOP - * MONON * SPOLP * SPOLN * SPORP * SPORN +Additional pins on the device for RT5640: + + * MONOP + * MONON + Example: rt5640 { -- cgit v1.1 From 2439ea1f0f8f4cc98dfae0d1cd5ba88f6c3ee9ad Mon Sep 17 00:00:00 2001 From: Sven Brandau Date: Wed, 2 Apr 2014 10:25:05 +0200 Subject: ASoC: sta350: Add codec driver The TI STA350 is an integrated 2.1-channel power amplifier that is controllable over I2C. This patch adds an ASoC driver for it. At a glance, this chip is very similar to the STA320 for which a driver already exists. In details, however, the register maps contain subtle differences which made a whole new driver easier to write and maintain. [daniel@zonque.org: cleanups, DT property rework, rebased on asoc-next] Signed-off-by: Sven Brandau Signed-off-by: Daniel Mack Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/st,sta350.txt | 107 +++++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/st,sta350.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/st,sta350.txt b/Documentation/devicetree/bindings/sound/st,sta350.txt new file mode 100644 index 0000000..9501888 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/st,sta350.txt @@ -0,0 +1,107 @@ +STA350 audio CODEC + +The driver for this device only supports I2C. + +Required properties: + + - compatible: "st,sta350" + - reg: the I2C address of the device for I2C + - reset-gpios: a GPIO spec for the reset pin. If specified, it will be + deasserted before communication to the codec starts. + + - power-down-gpios: a GPIO spec for the power down pin. If specified, + it will be deasserted before communication to the codec + starts. + + - vdd-dig-supply: regulator spec, providing 3.3V + - vdd-pll-supply: regulator spec, providing 3.3V + - vcc-supply: regulator spec, providing 5V - 26V + +Optional properties: + + - st,output-conf: number, Selects the output configuration: + 0: 2-channel (full-bridge) power, 2-channel data-out + 1: 2 (half-bridge). 1 (full-bridge) on-board power + 2: 2 Channel (Full-Bridge) Power, 1 Channel FFX + 3: 1 Channel Mono-Parallel + If parameter is missing, mode 0 will be enabled. + + - st,ch1-output-mapping: Channel 1 output mapping + - st,ch2-output-mapping: Channel 2 output mapping + - st,ch3-output-mapping: Channel 3 output mapping + 0: Channel 1 + 1: Channel 2 + 2: Channel 3 + If parameter is missing, channel 1 is choosen. + + - st,thermal-warning-recover: + If present, thermal warning recovery is enabled. + + - st,thermal-warning-adjustment: + If present, thermal warning adjustment is enabled. + + - st,fault-detect-recovery: + If present, then fault recovery will be enabled. + + - st,ffx-power-output-mode: string + The FFX power output mode selects how the FFX output timing is + configured. Must be one of these values: + - "drop-compensation" + - "tapered-compensation" + - "full-power-mode" + - "variable-drop-compensation" (default) + + - st,drop-compensation-ns: number + Only required for "st,ffx-power-output-mode" == + "variable-drop-compensation". + Specifies the drop compensation in nanoseconds. + The value must be in the range of 0..300, and only + multiples of 20 are allowed. Default is 140ns. + + - st,overcurrent-warning-adjustment: + If present, overcurrent warning adjustment is enabled. + + - st,max-power-use-mpcc: + If present, then MPCC bits are used for MPC coefficients, + otherwise standard MPC coefficients are used. + + - st,max-power-corr: + If present, power bridge correction for THD reduction near maximum + power output is enabled. + + - st,am-reduction-mode: + If present, FFX mode runs in AM reduction mode, otherwise normal + FFX mode is used. + + - st,odd-pwm-speed-mode: + If present, PWM speed mode run on odd speed mode (341.3 kHz) on all + channels. If not present, normal PWM spped mode (384 kHz) will be used. + + - st,distortion-compensation: + If present, distortion compensation variable uses DCC coefficient. + If not present, preset DC coefficient is used. + + - st,invalid-input-detect-mute: + If not present, automatic invalid input detect mute is enabled. + + + +Example: + +codec: sta350@38 { + compatible = "st,sta350"; + reg = <0x1c>; + reset-gpios = <&gpio1 19 0>; + power-down-gpios = <&gpio1 16 0>; + st,output-conf = <0x3>; // set output to 2-channel + // (full-bridge) power, + // 2-channel data-out + st,ch1-output-mapping = <0>; // set channel 1 output ch 1 + st,ch2-output-mapping = <0>; // set channel 2 output ch 1 + st,ch3-output-mapping = <0>; // set channel 3 output ch 1 + st,max-power-correction; // enables power bridge + // correction for THD reduction + // near maximum power output + st,invalid-input-detect-mute; // mute if no valid digital + // audio signal is provided. +}; -- cgit v1.1 From 78435c812afa70b8ddee789c7f37fc88738079a0 Mon Sep 17 00:00:00 2001 From: Heiko Stuebner Date: Wed, 19 Feb 2014 09:25:45 +0900 Subject: dt-bindings: add binding for clock-controller of s3c2443 and following Starting with the s3c2443 the s3c24xx series got a new clock tree compared to the previous s3c24xx socs. This binding describes the clock controller found in the s3c2443, s3c2416 and s3c2450 socs. Signed-off-by: Heiko Stuebner Acked-by: Tomasz Figa Signed-off-by: Kukjin Kim --- .../bindings/clock/samsung,s3c2443-clock.txt | 56 ++++++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt b/Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt new file mode 100644 index 0000000..e67bb05 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt @@ -0,0 +1,56 @@ +* Samsung S3C2443 Clock Controller + +The S3C2443 clock controller generates and supplies clock to various controllers +within the SoC. The clock binding described here is applicable to all SoCs in +the s3c24x family starting with the s3c2443. + +Required Properties: + +- compatible: should be one of the following. + - "samsung,s3c2416-clock" - controller compatible with S3C2416 SoC. + - "samsung,s3c2443-clock" - controller compatible with S3C2443 SoC. + - "samsung,s3c2450-clock" - controller compatible with S3C2450 SoC. +- reg: physical base address of the controller and length of memory mapped + region. +- #clock-cells: should be 1. + +Each clock is assigned an identifier and client nodes can use this identifier +to specify the clock which they consume. Some of the clocks are available only +on a particular SoC. + +All available clocks are defined as preprocessor macros in +dt-bindings/clock/s3c2443.h header and can be used in device +tree sources. + +External clocks: + +There are several clocks that are generated outside the SoC. It is expected +that they are defined using standard clock bindings with following +clock-output-names: + - "xti" - crystal input - required, + - "ext" - external clock source - optional, + - "ext_i2s" - external I2S clock - optional, + - "ext_uart" - external uart clock - optional, + +Example: Clock controller node: + + clocks: clock-controller@4c000000 { + compatible = "samsung,s3c2416-clock"; + reg = <0x4c000000 0x40>; + #clock-cells = <1>; + }; + +Example: 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" properties): + + serial@50004000 { + compatible = "samsung,s3c2440-uart"; + reg = <0x50004000 0x4000>; + interrupts = <1 23 3 4>, <1 23 4 4>; + clock-names = "uart", "clk_uart_baud2", + "clk_uart_baud3"; + clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>, + <&clocks SCLK_UART>; + status = "disabled"; + }; -- cgit v1.1 From 7d03fed8e56ba5ffdae67c64d181a010a2a56d9b Mon Sep 17 00:00:00 2001 From: Heiko Stuebner Date: Tue, 25 Feb 2014 09:50:44 +0900 Subject: dt-bindings: add documentation for s3c2412 clock controller Describe the clock controller of the s3c2412. Signed-off-by: Heiko Stuebner Signed-off-by: Kukjin Kim --- .../bindings/clock/samsung,s3c2412-clock.txt | 50 ++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/samsung,s3c2412-clock.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c2412-clock.txt b/Documentation/devicetree/bindings/clock/samsung,s3c2412-clock.txt new file mode 100644 index 0000000..2b43096 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/samsung,s3c2412-clock.txt @@ -0,0 +1,50 @@ +* Samsung S3C2412 Clock Controller + +The S3C2412 clock controller generates and supplies clock to various controllers +within the SoC. The clock binding described here is applicable to the s3c2412 +and s3c2413 SoCs in the s3c24x family. + +Required Properties: + +- compatible: should be "samsung,s3c2412-clock" +- reg: physical base address of the controller and length of memory mapped + region. +- #clock-cells: should be 1. + +Each clock is assigned an identifier and client nodes can use this identifier +to specify the clock which they consume. Some of the clocks are available only +on a particular SoC. + +All available clocks are defined as preprocessor macros in +dt-bindings/clock/s3c2412.h header and can be used in device +tree sources. + +External clocks: + +There are several clocks that are generated outside the SoC. It is expected +that they are defined using standard clock bindings with following +clock-output-names: + - "xti" - crystal input - required, + - "ext" - external clock source - optional, + +Example: Clock controller node: + + clocks: clock-controller@4c000000 { + compatible = "samsung,s3c2412-clock"; + reg = <0x4c000000 0x20>; + #clock-cells = <1>; + }; + +Example: 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" properties): + + serial@50004000 { + compatible = "samsung,s3c2412-uart"; + reg = <0x50004000 0x4000>; + interrupts = <1 23 3 4>, <1 23 4 4>; + clock-names = "uart", "clk_uart_baud2", "clk_uart_baud3"; + clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>, + <&clocks SCLK_UART>; + status = "disabled"; + }; -- cgit v1.1 From 1ef391084b22d75110171d34f565f57e4be9b2a6 Mon Sep 17 00:00:00 2001 From: Huang Shijie Date: Fri, 28 Feb 2014 15:58:00 +0800 Subject: Documentation: add the document for the SPI NOR framework This patch adds the document for the SPI NOR framework. Signed-off-by: Huang Shijie Acked-by: Marek Vasut Signed-off-by: Brian Norris --- Documentation/mtd/spi-nor.txt | 59 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 Documentation/mtd/spi-nor.txt (limited to 'Documentation') diff --git a/Documentation/mtd/spi-nor.txt b/Documentation/mtd/spi-nor.txt new file mode 100644 index 0000000..294d5b0 --- /dev/null +++ b/Documentation/mtd/spi-nor.txt @@ -0,0 +1,59 @@ + SPI NOR framework + ============================================ + +Part I - why we need this framework? +------------------------------------- + +The SPI bus controller only deals with the byte stream. +Some controller does not works like a SPI bus controller, it works +like a SPI NOR controller instead, such as the Freescale's QuadSPI controller. + +The Freescale's QuadSPI controller should know the NOR commands to +find the right LUT sequence. Unfortunately, the old code can not meet +this requirement. + +Part II - How does the framework work? +------------------------------------- + +This framework just adds a new layer between the MTD and the SPI bus driver. +With this new layer, the SPI NOR controller driver does not depend on the +m25p80 code anymore. + + Before this framework, the layer is like: + + MTD + ------------------------ + m25p80 + ------------------------ + SPI bus driver + ------------------------ + SPI NOR chip + + After this framework, the layer is like: + MTD + ------------------------ + SPI NOR framework + ------------------------ + m25p80 + ------------------------ + SPI bus driver + ------------------------ + SPI NOR chip + + With the SPI NOR controller driver(Freescale QuadSPI), it looks like: + MTD + ------------------------ + SPI NOR framework + ------------------------ + fsl-quadSPI + ------------------------ + SPI NOR chip + +Part III - How can the drivers use the framework +------------------------------------- + +The main API is the spi_nor_scan(). Before you call the hook, you should +initialize the necessary fields for spi_nor{}. +Please see the drivers/mtd/spi-nor/spi-nor.c for detail. +Please also reference to the fsl-quadspi.c when you want to write a new driver +for a SPI NOR controller. -- cgit v1.1 From c7a8a11c6bb78f49895d42294a88002ea544922f Mon Sep 17 00:00:00 2001 From: Huang Shijie Date: Mon, 24 Feb 2014 18:37:41 +0800 Subject: Documentation: add the binding file for Freescale QuadSPI driver This patch adds the binding file for Freescale QuadSPI driver. Signed-off-by: Huang Shijie Signed-off-by: Brian Norris --- .../devicetree/bindings/mtd/fsl-quadspi.txt | 35 ++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/fsl-quadspi.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt new file mode 100644 index 0000000..823d134 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt @@ -0,0 +1,35 @@ +* Freescale Quad Serial Peripheral Interface(QuadSPI) + +Required properties: + - compatible : Should be "fsl,vf610-qspi" + - reg : the first contains the register location and length, + the second contains the memory mapping address and length + - reg-names: Should contain the reg names "QuadSPI" and "QuadSPI-memory" + - interrupts : Should contain the interrupt for the device + - clocks : The clocks needed by the QuadSPI controller + - clock-names : the name of the clocks + +Optional properties: + - fsl,qspi-has-second-chip: The controller has two buses, bus A and bus B. + Each bus can be connected with two NOR flashes. + Most of the time, each bus only has one NOR flash + connected, this is the default case. + But if there are two NOR flashes connected to the + bus, you should enable this property. + (Please check the board's schematic.) + +Example: + +qspi0: quadspi@40044000 { + compatible = "fsl,vf610-qspi"; + reg = <0x40044000 0x1000>, <0x20000000 0x10000000>; + reg-names = "QuadSPI", "QuadSPI-memory"; + interrupts = <0 24 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clks VF610_CLK_QSPI0_EN>, + <&clks VF610_CLK_QSPI0>; + clock-names = "qspi_en", "qspi"; + + flash0: s25fl128s@0 { + .... + }; +}; -- cgit v1.1 From 254592db612aeb55d80399a04995b68f7da48c99 Mon Sep 17 00:00:00 2001 From: Brian Norris Date: Tue, 8 Apr 2014 20:17:04 -0700 Subject: Documentation: spi-nor: rewrite some portions Signed-off-by: Brian Norris Reviewed-by: Marek Vasut --- Documentation/mtd/spi-nor.txt | 37 ++++++++++++++++++++----------------- 1 file changed, 20 insertions(+), 17 deletions(-) (limited to 'Documentation') diff --git a/Documentation/mtd/spi-nor.txt b/Documentation/mtd/spi-nor.txt index 294d5b0..548d630 100644 --- a/Documentation/mtd/spi-nor.txt +++ b/Documentation/mtd/spi-nor.txt @@ -1,19 +1,23 @@ SPI NOR framework ============================================ -Part I - why we need this framework? -------------------------------------- +Part I - Why do we need this framework? +--------------------------------------- -The SPI bus controller only deals with the byte stream. -Some controller does not works like a SPI bus controller, it works -like a SPI NOR controller instead, such as the Freescale's QuadSPI controller. +SPI bus controllers (drivers/spi/) only deal with streams of bytes; the bus +controller operates agnostic of the specific device attached. However, some +controllers (such as Freescale's QuadSPI controller) cannot easily handle +arbitrary streams of bytes, but rather are designed specifically for SPI NOR. -The Freescale's QuadSPI controller should know the NOR commands to -find the right LUT sequence. Unfortunately, the old code can not meet -this requirement. +In particular, Freescale's QuadSPI controller must know the NOR commands to +find the right LUT sequence. Unfortunately, the SPI subsystem has no notion of +opcodes, addresses, or data payloads; a SPI controller simply knows to send or +receive bytes (Tx and Rx). Therefore, we must define a new layering scheme under +which the controller driver is aware of the opcodes, addressing, and other +details of the SPI NOR protocol. Part II - How does the framework work? -------------------------------------- +-------------------------------------- This framework just adds a new layer between the MTD and the SPI bus driver. With this new layer, the SPI NOR controller driver does not depend on the @@ -40,7 +44,7 @@ m25p80 code anymore. ------------------------ SPI NOR chip - With the SPI NOR controller driver(Freescale QuadSPI), it looks like: + With the SPI NOR controller driver (Freescale QuadSPI), it looks like: MTD ------------------------ SPI NOR framework @@ -49,11 +53,10 @@ m25p80 code anymore. ------------------------ SPI NOR chip -Part III - How can the drivers use the framework -------------------------------------- +Part III - How can drivers use the framework? +--------------------------------------------- -The main API is the spi_nor_scan(). Before you call the hook, you should -initialize the necessary fields for spi_nor{}. -Please see the drivers/mtd/spi-nor/spi-nor.c for detail. -Please also reference to the fsl-quadspi.c when you want to write a new driver -for a SPI NOR controller. +The main API is spi_nor_scan(). Before you call the hook, a driver should +initialize the necessary fields for spi_nor{}. Please see +drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to fsl-quadspi.c +when you want to write a new driver for a SPI NOR controller. -- cgit v1.1 From 205d52756f4091ffcf526f9d14853b18e3ca8d6f Mon Sep 17 00:00:00 2001 From: Harini Katakam Date: Mon, 14 Apr 2014 14:36:54 +0530 Subject: spi: Add devicetree bindings documentation for Cadence SPI Add spi-cadence bindings documentation. Signed-off-by: Harini Katakam Signed-off-by: Mark Brown --- .../devicetree/bindings/spi/spi-cadence.txt | 31 ++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/spi-cadence.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-cadence.txt b/Documentation/devicetree/bindings/spi/spi-cadence.txt new file mode 100644 index 0000000..94f0914 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-cadence.txt @@ -0,0 +1,31 @@ +Cadence SPI controller Device Tree Bindings +------------------------------------------- + +Required properties: +- compatible : Should be "cdns,spi-r1p6" or "xlnx,zynq-spi-r1p6". +- reg : Physical base address and size of SPI registers map. +- interrupts : Property with a value describing the interrupt + number. +- interrupt-parent : Must be core interrupt controller +- clock-names : List of input clock names - "ref_clk", "pclk" + (See clock bindings for details). +- clocks : Clock phandles (see clock bindings for details). + +Optional properties: +- num-cs : Number of chip selects used. + If a decoder is used, this will be the number of + chip selects after the decoder. +- is-decoded-cs : Flag to indicate whether decoder is used or not. + +Example: + + spi@e0007000 { + compatible = "xlnx,zynq-spi-r1p6"; + clock-names = "ref_clk", "pclk"; + clocks = <&clkc 26>, <&clkc 35>; + interrupt-parent = <&intc>; + interrupts = <0 49 4>; + num-cs = <4>; + is-decoded-cs = <0>; + reg = <0xe0007000 0x1000>; + } ; -- cgit v1.1 From 9b63cfbfd13b609e8d496852b6714ac686e31901 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Mon, 14 Apr 2014 10:09:08 +0200 Subject: regulator: s2mps11: Document external GPIO control Add documentation for new property for controlling (enable/disable) some of the S2MPS14 regulators by GPIO. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/mfd/s2mps11.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt index 802e839..d81ba30 100644 --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt @@ -56,6 +56,20 @@ for a particular group of BUCKs. So provide same regulator-ramp-delay. Grouping of BUCKs sharing ramp rate setting is as follow : BUCK[1, 6], BUCK[3, 4], and BUCK[7, 8, 10] +On S2MPS14 the LDO10, LDO11 and LDO12 can be configured to external control +over GPIO. To turn this feature on this property must be added to the regulator +sub-node: + - samsung,ext-control-gpios: GPIO specifier for one GPIO + controlling this regulator (enable/disable); +Example: + LDO12 { + regulator-name = "V_EMMC_2.8V"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + samsung,ext-control-gpios = <&gpk0 2 0>; + }; + + The regulator constraints inside the regulator nodes use the standard regulator bindings which are documented elsewhere. -- cgit v1.1 From 21200ad10aba00943f9aa832fab04b8926dc7a52 Mon Sep 17 00:00:00 2001 From: Vivien Didelot Date: Mon, 14 Apr 2014 16:50:17 -0400 Subject: HID: thingm: remove the "play" sysfs attribute When the thingm driver registers an instance of LED class, it creates a "play" sysfs attribute for this blink(1) specific feature. Since this feature is not specific to the RGB chip but to the HID device itself, let's remove this attribute from the LED instance and only implement what is useful to switch on and off the LED. This feature is still easily accessible through hidraw. Signed-off-by: Vivien Didelot Signed-off-by: Jiri Kosina --- Documentation/ABI/testing/sysfs-driver-hid-thingm | 7 ------- 1 file changed, 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-hid-thingm b/Documentation/ABI/testing/sysfs-driver-hid-thingm index abcffee..fda6185 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-thingm +++ b/Documentation/ABI/testing/sysfs-driver-hid-thingm @@ -14,10 +14,3 @@ Description: This attribute allows to set a fade time in milliseconds for the next color change. Read the attribute to know the current fade time. The default value is set to 0 (no fade time). For instance, set a fade time of 2 seconds with: echo 2000 > fade - -What: /sys/class/leds/blink1::/play -Date: January 2013 -Contact: Vivien Didelot -Description: This attribute is used to play/pause the light patterns. Write 1 - to start playing, 0 to stop. Reading this attribute returns the - current playing status. -- cgit v1.1 From aee114fd3c94f1be0f95af84d6ed25cd47702c41 Mon Sep 17 00:00:00 2001 From: Vivien Didelot Date: Mon, 14 Apr 2014 16:50:18 -0400 Subject: HID: thingm: remove the "fade" sysfs attribute As for the "play" sysfs attribute, remove this other non-standard attribute, so the driver only implements what is required to switch the LED on and off. Thus, a fade time won't be ideal for some fast-changing triggers. Signed-off-by: Vivien Didelot Signed-off-by: Jiri Kosina --- Documentation/ABI/testing/sysfs-driver-hid-thingm | 8 -------- 1 file changed, 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-hid-thingm b/Documentation/ABI/testing/sysfs-driver-hid-thingm index fda6185..735c5cb 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-thingm +++ b/Documentation/ABI/testing/sysfs-driver-hid-thingm @@ -6,11 +6,3 @@ Description: The ThingM blink1 is an USB RGB LED. The color notation is color. Write the 24-bit hexadecimal color to change the current LED color. The default color is full white (0xFFFFFF). For instance, set the color to green with: echo 00FF00 > rgb - -What: /sys/class/leds/blink1::/fade -Date: January 2013 -Contact: Vivien Didelot -Description: This attribute allows to set a fade time in milliseconds for - the next color change. Read the attribute to know the current - fade time. The default value is set to 0 (no fade time). For - instance, set a fade time of 2 seconds with: echo 2000 > fade -- cgit v1.1 From f70ed8a6f7cd9c55cc16287c584cb26efb53cbd7 Mon Sep 17 00:00:00 2001 From: Vivien Didelot Date: Mon, 14 Apr 2014 16:50:19 -0400 Subject: HID: thingm: refactor blink(1) support This patch refactors the way the thingm driver registers a blink(1) LED. In order to make the driver simpler and more standard, drop the "rgb" sysfs attribute and create one instance of LED class per RGB channel. Actually, the name of the LED class instance registered for a blink(1) device is "blink1::ABCD", where ABCD is the last 4 chars of the serial number. The driver now registers 3 instances per RGB chip, named "thingmX:{red,green,blue}:ledY" where X is the hidraw minor number and Y is the RGB chip number (as seen by the firmware). This patch also uses work queues to defer calls with the device, which now allows triggers to work as expected with this LED device. Also remove the brightness structure field and the brightness_get backend, as it is already handled by the LED class, and changes the prefix of functions and structures to thingm_ to match the driver name. Signed-off-by: Vivien Didelot Signed-off-by: Jiri Kosina --- Documentation/ABI/testing/sysfs-driver-hid-thingm | 8 -------- 1 file changed, 8 deletions(-) delete mode 100644 Documentation/ABI/testing/sysfs-driver-hid-thingm (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-hid-thingm b/Documentation/ABI/testing/sysfs-driver-hid-thingm deleted file mode 100644 index 735c5cb..0000000 --- a/Documentation/ABI/testing/sysfs-driver-hid-thingm +++ /dev/null @@ -1,8 +0,0 @@ -What: /sys/class/leds/blink1::/rgb -Date: January 2013 -Contact: Vivien Didelot -Description: The ThingM blink1 is an USB RGB LED. The color notation is - 3-byte hexadecimal. Read this attribute to get the last set - color. Write the 24-bit hexadecimal color to change the current - LED color. The default color is full white (0xFFFFFF). - For instance, set the color to green with: echo 00FF00 > rgb -- cgit v1.1 From d0fb47a5237d8b9576113568bacfd27892308b62 Mon Sep 17 00:00:00 2001 From: Jane Wan Date: Wed, 16 Apr 2014 13:09:39 -0700 Subject: spi: fsl-espi: Configure FSL eSPI CSBEF and CSAFT Make FSL eSPI CSnBEF and CSnAFT fields in ESPI_SPMODEn registers (n=0,1,2,3) configurable through device tree. CSnBEF is the chip select setup time. It's the delay in bits from the activation of chip select pin to the first clock for data frame. CSnAFT is the chip select hold time. It's the delay in bits from the last clock for data frame to the deactivation of chip select pin. The FSL eSPI driver hardcodes CSnBEF and CSnAFT to 0. Need to set them to a different value for some device. Signed-off-by: Jane Wan Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/fsl-spi.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/fsl-spi.txt b/Documentation/devicetree/bindings/spi/fsl-spi.txt index b032dd7..a233137 100644 --- a/Documentation/devicetree/bindings/spi/fsl-spi.txt +++ b/Documentation/devicetree/bindings/spi/fsl-spi.txt @@ -42,6 +42,10 @@ Required properties: - interrupts : should contain eSPI interrupt, the device has one interrupt. - fsl,espi-num-chipselects : the number of the chipselect signals. +Optional properties: +- fsl,csbef: chip select assertion time in bits before frame starts +- fsl,csaft: chip select negation time in bits after frame ends + Example: spi@110000 { #address-cells = <1>; @@ -51,4 +55,6 @@ Example: interrupts = <53 0x2>; interrupt-parent = <&mpic>; fsl,espi-num-chipselects = <4>; + fsl,csbef = <1>; + fsl,csaft = <1>; }; -- cgit v1.1 From b050b29e071a0b11262ad513700ab073f58c45b2 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Mon, 7 Apr 2014 10:01:28 -0300 Subject: [media] DocBook media: update bytesused field description For output buffers the application has to set the bytesused field. In reality applications often do not set this since drivers that deal with fix image sizes just override it anyway. The vb2 framework will replace this field with the length field if bytesused was set to 0 by the application, which is what happens in practice. Document this behavior. Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/io.xml | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 97a69bf..188e621 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -699,7 +699,12 @@ linkend="v4l2-buf-type" /> buffer. It depends on the negotiated data format and may change with each buffer for compressed variable size data like JPEG images. Drivers must set this field when type -refers to an input stream, applications when it refers to an output stream. +refers to an input stream, applications when it refers to an output stream. +If the application sets this to 0 for an output stream, then +bytesused will be set to the size of the +buffer (see the length field of this struct) by +the driver. For multiplanar formats this field is ignored and the +planes pointer is used instead. __u32 @@ -861,7 +866,11 @@ should set this to 0. The number of bytes occupied by data in the plane (its payload). Drivers must set this field when type - refers to an input stream, applications when it refers to an output stream. + refers to an input stream, applications when it refers to an output stream. + If the application sets this to 0 for an output stream, then + bytesused will be set to the size of the + plane (see the length field of this struct) + by the driver. __u32 -- cgit v1.1 From 5f26f2501b81190b60a0b72d611668fb6a59dd24 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Fri, 11 Apr 2014 05:02:29 -0300 Subject: [media] v4l2-pci-skeleton.c: fix alternate field handling For interlaced HDTV timings the correct field setting is FIELD_ALTERNATE, not INTERLACED. Update this template driver accordingly: - add check for the invalid combination of read() and FIELD_ALTERNATE. - in the interrupt handler set v4l2_buffer field to alternating TOP and BOTTOM. Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/v4l2-pci-skeleton.c | 39 +++++++++++++++++++-------- 1 file changed, 28 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/v4l2-pci-skeleton.c b/Documentation/video4linux/v4l2-pci-skeleton.c index 3a1c0d2..80251dc 100644 --- a/Documentation/video4linux/v4l2-pci-skeleton.c +++ b/Documentation/video4linux/v4l2-pci-skeleton.c @@ -77,7 +77,8 @@ struct skeleton { spinlock_t qlock; struct list_head buf_list; - unsigned int sequence; + unsigned field; + unsigned sequence; }; struct skel_buffer { @@ -124,7 +125,7 @@ static const struct v4l2_dv_timings_cap skel_timings_cap = { * Interrupt handler: typically interrupts happen after a new frame has been * captured. It is the job of the handler to remove the new frame from the * internal list and give it back to the vb2 framework, updating the sequence - * counter and timestamp at the same time. + * counter, field and timestamp at the same time. */ static irqreturn_t skeleton_irq(int irq, void *dev_id) { @@ -139,8 +140,15 @@ static irqreturn_t skeleton_irq(int irq, void *dev_id) spin_lock(&skel->qlock); list_del(&new_buf->list); spin_unlock(&skel->qlock); - new_buf->vb.v4l2_buf.sequence = skel->sequence++; v4l2_get_timestamp(&new_buf->vb.v4l2_buf.timestamp); + new_buf->vb.v4l2_buf.sequence = skel->sequence++; + new_buf->vb.v4l2_buf.field = skel->field; + if (skel->format.field == V4L2_FIELD_ALTERNATE) { + if (skel->field == V4L2_FIELD_BOTTOM) + skel->field = V4L2_FIELD_TOP; + else if (skel->field == V4L2_FIELD_TOP) + skel->field = V4L2_FIELD_BOTTOM; + } vb2_buffer_done(&new_buf->vb, VB2_BUF_STATE_DONE); } #endif @@ -160,6 +168,17 @@ static int queue_setup(struct vb2_queue *vq, const struct v4l2_format *fmt, { struct skeleton *skel = vb2_get_drv_priv(vq); + skel->field = skel->format.field; + if (skel->field == V4L2_FIELD_ALTERNATE) { + /* + * You cannot use read() with FIELD_ALTERNATE since the field + * information (TOP/BOTTOM) cannot be passed back to the user. + */ + if (vb2_fileio_is_active(q)) + return -EINVAL; + skel->field = V4L2_FIELD_TOP; + } + if (vq->num_buffers + *nbuffers < 3) *nbuffers = 3 - vq->num_buffers; @@ -173,10 +192,7 @@ static int queue_setup(struct vb2_queue *vq, const struct v4l2_format *fmt, /* * Prepare the buffer for queueing to the DMA engine: check and set the - * payload size and fill in the field. Note: if the format's field is - * V4L2_FIELD_ALTERNATE, then vb->v4l2_buf.field should be set in the - * interrupt handler since that's usually where you know if the TOP or - * BOTTOM field has been captured. + * payload size. */ static int buffer_prepare(struct vb2_buffer *vb) { @@ -190,7 +206,6 @@ static int buffer_prepare(struct vb2_buffer *vb) } vb2_set_plane_payload(vb, 0, size); - vb->v4l2_buf.field = skel->format.field; return 0; } @@ -319,10 +334,12 @@ static void skeleton_fill_pix_format(struct skeleton *skel, /* HDMI input */ pix->width = skel->timings.bt.width; pix->height = skel->timings.bt.height; - if (skel->timings.bt.interlaced) - pix->field = V4L2_FIELD_INTERLACED; - else + if (skel->timings.bt.interlaced) { + pix->field = V4L2_FIELD_ALTERNATE; + pix->height /= 2; + } else { pix->field = V4L2_FIELD_NONE; + } pix->colorspace = V4L2_COLORSPACE_REC709; } -- cgit v1.1 From 1b15611e1c30b37abe393d411c316cd659920bf5 Mon Sep 17 00:00:00 2001 From: Peter Zijlstra Date: Thu, 13 Mar 2014 19:00:35 +0100 Subject: arch,doc: Convert smp_mb__*() Update the documentation to reflect the change of barrier primitives. Signed-off-by: Peter Zijlstra Reviewed-by: Paul E. McKenney Acked-by: David Howells Link: http://lkml.kernel.org/n/tip-xslfehiga1twbk5uk94rij1e@git.kernel.org Cc: Linus Torvalds Cc: Randy Dunlap Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar --- Documentation/atomic_ops.txt | 31 +++++++++++------------------ Documentation/memory-barriers.txt | 42 ++++++++++----------------------------- 2 files changed, 23 insertions(+), 50 deletions(-) (limited to 'Documentation') diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt index d9ca5be..68542fe 100644 --- a/Documentation/atomic_ops.txt +++ b/Documentation/atomic_ops.txt @@ -285,15 +285,13 @@ If a caller requires memory barrier semantics around an atomic_t operation which does not return a value, a set of interfaces are defined which accomplish this: - void smp_mb__before_atomic_dec(void); - void smp_mb__after_atomic_dec(void); - void smp_mb__before_atomic_inc(void); - void smp_mb__after_atomic_inc(void); + void smp_mb__before_atomic(void); + void smp_mb__after_atomic(void); -For example, smp_mb__before_atomic_dec() can be used like so: +For example, smp_mb__before_atomic() can be used like so: obj->dead = 1; - smp_mb__before_atomic_dec(); + smp_mb__before_atomic(); atomic_dec(&obj->ref_count); It makes sure that all memory operations preceding the atomic_dec() @@ -302,15 +300,10 @@ operation. In the above example, it guarantees that the assignment of "1" to obj->dead will be globally visible to other cpus before the atomic counter decrement. -Without the explicit smp_mb__before_atomic_dec() call, the +Without the explicit smp_mb__before_atomic() call, the implementation could legally allow the atomic counter update visible to other cpus before the "obj->dead = 1;" assignment. -The other three interfaces listed are used to provide explicit -ordering with respect to memory operations after an atomic_dec() call -(smp_mb__after_atomic_dec()) and around atomic_inc() calls -(smp_mb__{before,after}_atomic_inc()). - A missing memory barrier in the cases where they are required by the atomic_t implementation above can have disastrous results. Here is an example, which follows a pattern occurring frequently in the Linux @@ -487,12 +480,12 @@ Finally there is the basic operation: Which returns a boolean indicating if bit "nr" is set in the bitmask pointed to by "addr". -If explicit memory barriers are required around clear_bit() (which -does not return a value, and thus does not need to provide memory -barrier semantics), two interfaces are provided: +If explicit memory barriers are required around {set,clear}_bit() (which do +not return a value, and thus does not need to provide memory barrier +semantics), two interfaces are provided: - void smp_mb__before_clear_bit(void); - void smp_mb__after_clear_bit(void); + void smp_mb__before_atomic(void); + void smp_mb__after_atomic(void); They are used as follows, and are akin to their atomic_t operation brothers: @@ -500,13 +493,13 @@ brothers: /* All memory operations before this call will * be globally visible before the clear_bit(). */ - smp_mb__before_clear_bit(); + smp_mb__before_atomic(); clear_bit( ... ); /* The clear_bit() will be visible before all * subsequent memory operations. */ - smp_mb__after_clear_bit(); + smp_mb__after_atomic(); There are two special bitops with lock barrier semantics (acquire/release, same as spinlocks). These operate in the same way as their non-_lock/unlock diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 556f951..46412bd 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -1583,20 +1583,21 @@ There are some more advanced barrier functions: insert anything more than a compiler barrier in a UP compilation. - (*) smp_mb__before_atomic_dec(); - (*) smp_mb__after_atomic_dec(); - (*) smp_mb__before_atomic_inc(); - (*) smp_mb__after_atomic_inc(); + (*) smp_mb__before_atomic(); + (*) smp_mb__after_atomic(); - These are for use with atomic add, subtract, increment and decrement - functions that don't return a value, especially when used for reference - counting. These functions do not imply memory barriers. + These are for use with atomic (such as add, subtract, increment and + decrement) functions that don't return a value, especially when used for + reference counting. These functions do not imply memory barriers. + + These are also used for atomic bitop functions that do not return a + value (such as set_bit and clear_bit). As an example, consider a piece of code that marks an object as being dead and then decrements the object's reference count: obj->dead = 1; - smp_mb__before_atomic_dec(); + smp_mb__before_atomic(); atomic_dec(&obj->ref_count); This makes sure that the death mark on the object is perceived to be set @@ -1606,27 +1607,6 @@ There are some more advanced barrier functions: operations" subsection for information on where to use these. - (*) smp_mb__before_clear_bit(void); - (*) smp_mb__after_clear_bit(void); - - These are for use similar to the atomic inc/dec barriers. These are - typically used for bitwise unlocking operations, so care must be taken as - there are no implicit memory barriers here either. - - Consider implementing an unlock operation of some nature by clearing a - locking bit. The clear_bit() would then need to be barriered like this: - - smp_mb__before_clear_bit(); - clear_bit( ... ); - - This prevents memory operations before the clear leaking to after it. See - the subsection on "Locking Functions" with reference to RELEASE operation - implications. - - See Documentation/atomic_ops.txt for more information. See the "Atomic - operations" subsection for information on where to use these. - - MMIO WRITE BARRIER ------------------ @@ -2283,11 +2263,11 @@ operations: change_bit(); With these the appropriate explicit memory barrier should be used if necessary -(smp_mb__before_clear_bit() for instance). +(smp_mb__before_atomic() for instance). The following also do _not_ imply memory barriers, and so may require explicit -memory barriers under some circumstances (smp_mb__before_atomic_dec() for +memory barriers under some circumstances (smp_mb__before_atomic() for instance): atomic_add(); -- cgit v1.1 From 290414499cf94284a97cc3c33214d13ccfcd896a Mon Sep 17 00:00:00 2001 From: Doug Anderson Date: Wed, 16 Apr 2014 16:12:28 -0700 Subject: regulator: tps65090: Allow setting the overcurrent wait time The tps65090 regulator allows you to specify how long you want it to wait before detecting an overcurrent condition. Allow specifying that through the device tree (or through platform data). Signed-off-by: Doug Anderson Signed-off-by: Simon Glass Signed-off-by: Michael Spang Signed-off-by: Sean Paul Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/regulator/tps65090.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/tps65090.txt b/Documentation/devicetree/bindings/regulator/tps65090.txt index 313a60b..34098023 100644 --- a/Documentation/devicetree/bindings/regulator/tps65090.txt +++ b/Documentation/devicetree/bindings/regulator/tps65090.txt @@ -21,6 +21,10 @@ Optional properties: number should be provided. If it is externally controlled and no GPIO entry then driver will just configure this rails as external control and will not provide any enable/disable APIs. +- ti,overcurrent-wait: This is applicable to FET registers, which have a + poorly defined "overcurrent wait" field. If this property is present it + should be between 0 - 3. If this property isn't present we won't touch the + "overcurrent wait" field and we'll leave it to the BIOS/EC to deal with. Each regulator is defined using the standard binding for regulators. -- cgit v1.1 From 35d35aae817706800a4913711d563a99e1dc380a Mon Sep 17 00:00:00 2001 From: Tushar Behera Date: Thu, 6 Mar 2014 11:34:43 +0530 Subject: dt-bindings: clock: Move at91.h to dt-bindigs/clock Most of the clock related dt-binding header files are located in dt-bindings/clock folder. It would be good to keep all the similar header files at a single location. Signed-off-by: Tushar Behera CC: Rob Landley CC: Andrew Victor CC: Jean-Christophe Plagniol-Villard Acked-by: Boris BREZILLON [nicolas.ferre@atmel.com: add new at91sam9261 & at91sam9rl] Signed-off-by: Nicolas Ferre --- Documentation/devicetree/bindings/clock/at91-clock.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt b/Documentation/devicetree/bindings/clock/at91-clock.txt index cd5e239..6794cdc 100644 --- a/Documentation/devicetree/bindings/clock/at91-clock.txt +++ b/Documentation/devicetree/bindings/clock/at91-clock.txt @@ -62,7 +62,7 @@ Required properties for PMC node: - interrupt-controller : tell that the PMC is an interrupt controller. - #interrupt-cells : must be set to 1. The first cell encodes the interrupt id, and reflect the bit position in the PMC_ER/DR/SR registers. - You can use the dt macros defined in dt-bindings/clk/at91.h. + You can use the dt macros defined in dt-bindings/clock/at91.h. 0 (AT91_PMC_MOSCS) -> main oscillator ready 1 (AT91_PMC_LOCKA) -> PLL A ready 2 (AT91_PMC_LOCKB) -> PLL B ready -- cgit v1.1 From a94e88cdd8057fe8ea84bbb6d9a89a823c7bc49b Mon Sep 17 00:00:00 2001 From: Lv Zheng Date: Fri, 4 Apr 2014 12:39:11 +0800 Subject: ACPICA: Tables: Avoid SSDT installation with acpi_gbl_disable_ssdt_table_load. It is reported that when acpi_gbl_disable_ssdt_table_load is specified, user still can see it installed into /sys/firmware/acpi/tables on Linux boxes. This is because the option only stops table "loading", but doesn't stop table "installing", thus it is still in the acpi_gbl_root_table_list. With previous cleanups, it is possible to prevent SSDT installations to make it not such confusing. The global variable is also renamed. Lv Zheng. Signed-off-by: Lv Zheng [rjw: Subject] Signed-off-by: Rafael J. Wysocki --- Documentation/kernel-parameters.txt | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 03e50b4..fbb58d7 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -237,7 +237,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted. This feature is enabled by default. This option allows to turn off the feature. - acpi_no_auto_ssdt [HW,ACPI] Disable automatic loading of SSDT + acpi_no_static_ssdt [HW,ACPI] + Disable installation of static SSDTs at early boot time + By default, SSDTs contained in the RSDT/XSDT will be + installed automatically and they will appear under + /sys/firmware/acpi/tables. + This option turns off this feature. + Note that specifying this option does not affect + dynamic table installation which will install SSDT + tables to /sys/firmware/acpi/tables/dynamic. acpica_no_return_repair [HW, ACPI] Disable AML predefined validation mechanism -- cgit v1.1 From d9a6ef1bb27e589ec40f792f3e742c3f54cbdb28 Mon Sep 17 00:00:00 2001 From: Andreas Larsson Date: Thu, 27 Mar 2014 16:15:54 +0100 Subject: usb: gadget: gr_udc: Expand devicetree documentation Provide more information on the two different interrupt cases and more information of endpoint buffer sizes. Suggested by Mark Rutland. Signed-off-by: Andreas Larsson Signed-off-by: Felipe Balbi --- Documentation/devicetree/bindings/usb/gr-udc.txt | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/gr-udc.txt b/Documentation/devicetree/bindings/usb/gr-udc.txt index 0c5118f..e944522 100644 --- a/Documentation/devicetree/bindings/usb/gr-udc.txt +++ b/Documentation/devicetree/bindings/usb/gr-udc.txt @@ -12,17 +12,23 @@ Required properties: - reg : Address and length of the register set for the device -- interrupts : Interrupt numbers for this device +- interrupts : Interrupt numbers for this device. Either one interrupt number + for all interrupts, or one for status related interrupts, one for IN + endpoint related interrupts and one for OUT endpoint related interrupts. Optional properties: -- epobufsizes : An array of buffer sizes for OUT endpoints. If the property is - not present, or for endpoints outside of the array, 1024 is assumed by - the driver. - -- epibufsizes : An array of buffer sizes for IN endpoints. If the property is - not present, or for endpoints outside of the array, 1024 is assumed by - the driver. +- epobufsizes : Array of buffer sizes for OUT endpoints when they differ + from the default size of 1024. The array is indexed by the OUT endpoint + number. If the property is present it typically contains one entry for + each OUT endpoint of the core. Fewer entries overrides the default sizes + only for as many endpoints as the array contains. + +- epibufsizes : Array of buffer sizes for IN endpoints when they differ + from the default size of 1024. The array is indexed by the IN endpoint + number. If the property is present it typically contains one entry for + each IN endpoint of the core. Fewer entries overrides the default sizes + only for as many endpoints as the array contains. For further information look in the documentation for the GLIB IP core library: http://www.gaisler.com/products/grlib/grip.pdf -- cgit v1.1 From a1a8b4594f8d30e650dad19832e17552219e5694 Mon Sep 17 00:00:00 2001 From: Clement Perrochaud Date: Wed, 2 Apr 2014 09:03:27 +0000 Subject: NFC: pn544: i2c: Add DTS Documentation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Describe the properties used by the PN544 NFC controller driver. Signed-off-by: Clément Perrochaud Signed-off-by: Samuel Ortiz --- .../devicetree/bindings/net/nfc/pn544.txt | 35 ++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/nfc/pn544.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/nfc/pn544.txt b/Documentation/devicetree/bindings/net/nfc/pn544.txt new file mode 100644 index 0000000..dab69f3 --- /dev/null +++ b/Documentation/devicetree/bindings/net/nfc/pn544.txt @@ -0,0 +1,35 @@ +* NXP Semiconductors PN544 NFC Controller + +Required properties: +- compatible: Should be "nxp,pn544-i2c". +- clock-frequency: IC work frequency. +- reg: address on the bus +- interrupt-parent: phandle for the interrupt gpio controller +- interrupts: GPIO interrupt to which the chip is connected +- enable-gpios: Output GPIO pin used for enabling/disabling the PN544 +- firmware-gpios: Output GPIO pin used to enter firmware download mode + +Optional SoC Specific Properties: +- pinctrl-names: Contains only one value - "default". +- pintctrl-0: Specifies the pin control groups used for this controller. + +Example (for ARM-based BeagleBone with PN544 on I2C2): + +&i2c2 { + + status = "okay"; + + pn544: pn544@28 { + + compatible = "nxp,pn544-i2c"; + + reg = <0x28>; + clock-frequency = <400000>; + + interrupt-parent = <&gpio1>; + interrupts = <17 GPIO_ACTIVE_HIGH>; + + enable-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>; + firmware-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>; + }; +}; -- cgit v1.1 From 3b82637813a9ea9f79ac6315341c59bfe408bf11 Mon Sep 17 00:00:00 2001 From: "Mark A. Greer" Date: Tue, 25 Mar 2014 08:54:41 -0700 Subject: NFC: trf7970a: Document the 'autosuspend-delay' DTS property The trf7970a driver recently had support added for the 'autosuspend-delay' property so document it. Signed-off-by: Mark A. Greer Signed-off-by: Samuel Ortiz --- Documentation/devicetree/bindings/net/nfc/trf7970a.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt index 8dd3ef7..1e43613 100644 --- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt +++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt @@ -12,6 +12,7 @@ Required properties: Optional SoC Specific Properties: - pinctrl-names: Contains only one value - "default". - pintctrl-0: Specifies the pin control groups used for this controller. +- autosuspend-delay: Specify autosuspend delay in milliseconds. Example (for ARM-based BeagleBone with TRF7970A on SPI1): @@ -29,6 +30,7 @@ Example (for ARM-based BeagleBone with TRF7970A on SPI1): ti,enable-gpios = <&gpio2 2 GPIO_ACTIVE_LOW>, <&gpio2 5 GPIO_ACTIVE_LOW>; vin-supply = <&ldo3_reg>; + autosuspend-delay = <30000>; status = "okay"; }; }; -- cgit v1.1 From 55f5587a4977384b88185b08e3c3ffbd9f0994f4 Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Mon, 31 Mar 2014 14:49:56 -0700 Subject: pinctrl: msm: Add documentation for pinctrl-apq8064 binding DT bindingdocumentation for qcom,apq8064-pinctrl driver. Signed-off-by: Bjorn Andersson Signed-off-by: Linus Walleij --- .../bindings/pinctrl/qcom,apq8064-pinctrl.txt | 88 ++++++++++++++++++++++ 1 file changed, 88 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt new file mode 100644 index 0000000..7181f92 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt @@ -0,0 +1,88 @@ +Qualcomm APQ8064 TLMM block + +Required properties: +- compatible: "qcom,apq8064-pinctrl" +- reg: Should be the base address and length of the TLMM block. +- interrupts: Should be the parent IRQ of the TLMM block. +- interrupt-controller: Marks the device node as an interrupt controller. +- #interrupt-cells: Should be two. +- gpio-controller: Marks the device node as a GPIO controller. +- #gpio-cells : Should be two. + The first cell is the gpio pin number and the + second cell is used for optional parameters. + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +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". + +Qualcomm'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. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + + pins, function, bias-disable, bias-pull-down, bias-pull,up, drive-strength, + output-low, output-high. + +Non-empty subnodes must specify the 'pins' property. + +Valid values for pins are: + gpio0-gpio89 + +Valid values for function are: + cam_mclk, codec_mic_i2s, codec_spkr_i2s, gsbi1, gsbi2, gsbi3, gsbi4, + gsbi4_cam_i2c, gsbi5, gsbi5_spi_cs1, gsbi5_spi_cs2, gsbi5_spi_cs3, gsbi6, + gsbi6_spi_cs1, gsbi6_spi_cs2, gsbi6_spi_cs3, gsbi7, gsbi7_spi_cs1, + gsbi7_spi_cs2, gsbi7_spi_cs3, gsbi_cam_i2c, hdmi, mi2s, riva_bt, riva_fm, + riva_wlan, sdc2, sdc4, slimbus, spkr_i2s, tsif1, tsif2, usb2_hsic, + +Example: + + msmgpio: pinctrl@800000 { + compatible = "qcom,apq8064-pinctrl"; + reg = <0x800000 0x4000>; + + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <0 32 0x4>; + + pinctrl-names = "default"; + pinctrl-0 = <&gsbi5_uart_default>; + + gsbi5_uart_default: gsbi5_uart_default { + mux { + pins = "gpio51", "gpio52"; + function = "gsbi5"; + }; + + tx { + pins = "gpio51"; + drive-strength = <4>; + bias-disable; + }; + + rx { + pins = "gpio52"; + drive-strength = <2>; + bias-pull-up; + }; + }; + }; -- cgit v1.1 From f9b0e251dfbf2c4da642ec9210db29a7ac63b81a Mon Sep 17 00:00:00 2001 From: Andrzej Hajda Date: Wed, 2 Apr 2014 12:29:46 +0200 Subject: drm: make mode_valid callback optional Many drm connectors do not need mode validation. The patch makes this callback optional and removes dumb implementations. v2: Rebase: - imx move to a shared (but still dummy) ->mode_valid implementation. - probe helpers have been extracted to drm_probe_helper.c Signed-off-by: Andrzej Hajda (v1) Signed-off-by: Daniel Vetter --- Documentation/DocBook/drm.tmpl | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 677a025..c72e146 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -1903,8 +1903,8 @@ void intel_crt_init(struct drm_device *dev) The function filters out modes larger than max_width and max_height - if specified. It then calls the connector - mode_valid helper operation for each mode in + if specified. It then calls the optional connector + mode_valid helper operation for each mode in the probed list to check whether the mode is valid for the connector. @@ -2265,7 +2265,7 @@ void intel_crt_init(struct drm_device *dev) Verify whether a mode is valid for the connector. Return MODE_OK for supported modes and one of the enum drm_mode_status values (MODE_*) - for unsupported modes. This operation is mandatory. + for unsupported modes. This operation is optional. As the mode rejection reason is currently not used beside for -- cgit v1.1 From 10b1f231441d8f4422c27c6e9cffc0cb2c3d871d Mon Sep 17 00:00:00 2001 From: Matthew Leach Date: Fri, 14 Mar 2014 10:18:20 +0000 Subject: documentaion: DT: allow a A5 compatible string in global timer The global timer is present on the Cortex A5. Add a compatibility string to the DT binding to allow a Cortex A5 global timer. Acked-by: Rob Herring Signed-off-by: Matthew Leach Signed-off-by: Daniel Lezcano --- Documentation/devicetree/bindings/arm/global_timer.txt | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/global_timer.txt b/Documentation/devicetree/bindings/arm/global_timer.txt index 1e54898..bdae3a8 100644 --- a/Documentation/devicetree/bindings/arm/global_timer.txt +++ b/Documentation/devicetree/bindings/arm/global_timer.txt @@ -4,8 +4,11 @@ ** Timer node required properties: -- compatible : Should be "arm,cortex-a9-global-timer" - Driver supports versions r2p0 and above. +- compatible : should contain + * "arm,cortex-a5-global-timer" for Cortex-A5 global timers. + * "arm,cortex-a9-global-timer" for Cortex-A9 global + timers or any compatible implementation. Note: driver + supports versions r2p0 and above. - interrupts : One interrupt to each core -- cgit v1.1 From 63cc122381bda123c2b1b0137cca09f66e5be660 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= Date: Tue, 25 Mar 2014 15:50:44 +0100 Subject: clocksource: efm32: use $vendor,$device scheme for compatible string MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Wolfram Sang pointed out that "efm32,$device" is non-standard. So use the common scheme and prefix device with "efm32-". The old compatible string is left in place until arch/arm/boot/dts/efm32* is fixed. Acked-by: Wolfram Sang Acked-by: Rob Herring Signed-off-by: Uwe Kleine-König Signed-off-by: Daniel Lezcano --- .../devicetree/bindings/timer/efm32,timer.txt | 23 ---------------------- .../bindings/timer/energymicro,efm32-timer.txt | 23 ++++++++++++++++++++++ 2 files changed, 23 insertions(+), 23 deletions(-) delete mode 100644 Documentation/devicetree/bindings/timer/efm32,timer.txt create mode 100644 Documentation/devicetree/bindings/timer/energymicro,efm32-timer.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/timer/efm32,timer.txt b/Documentation/devicetree/bindings/timer/efm32,timer.txt deleted file mode 100644 index 97a568f..0000000 --- a/Documentation/devicetree/bindings/timer/efm32,timer.txt +++ /dev/null @@ -1,23 +0,0 @@ -* EFM32 timer hardware - -The efm32 Giant Gecko SoCs come with four 16 bit timers. Two counters can be -connected to form a 32 bit counter. Each timer has three Compare/Capture -channels and can be used as PWM or Quadrature Decoder. Available clock sources -are the cpu's HFPERCLK (with a 10-bit prescaler) or an external pin. - -Required properties: -- compatible : Should be efm32,timer -- reg : Address and length of the register set -- clocks : Should contain a reference to the HFPERCLK - -Optional properties: -- interrupts : Reference to the timer interrupt - -Example: - -timer@40010c00 { - compatible = "efm32,timer"; - reg = <0x40010c00 0x400>; - interrupts = <14>; - clocks = <&cmu clk_HFPERCLKTIMER3>; -}; diff --git a/Documentation/devicetree/bindings/timer/energymicro,efm32-timer.txt b/Documentation/devicetree/bindings/timer/energymicro,efm32-timer.txt new file mode 100644 index 0000000..e502c11 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/energymicro,efm32-timer.txt @@ -0,0 +1,23 @@ +* EFM32 timer hardware + +The efm32 Giant Gecko SoCs come with four 16 bit timers. Two counters can be +connected to form a 32 bit counter. Each timer has three Compare/Capture +channels and can be used as PWM or Quadrature Decoder. Available clock sources +are the cpu's HFPERCLK (with a 10-bit prescaler) or an external pin. + +Required properties: +- compatible : Should be "energymicro,efm32-timer" +- reg : Address and length of the register set +- clocks : Should contain a reference to the HFPERCLK + +Optional properties: +- interrupts : Reference to the timer interrupt + +Example: + +timer@40010c00 { + compatible = "energymicro,efm32-timer"; + reg = <0x40010c00 0x400>; + interrupts = <14>; + clocks = <&cmu clk_HFPERCLKTIMER3>; +}; -- cgit v1.1 From f2061656209fb9a5d54bbb1999f0a633438504e7 Mon Sep 17 00:00:00 2001 From: Dominik Dingel Date: Wed, 9 Apr 2014 13:13:00 +0200 Subject: KVM: s390: Per-vm kvm device controls We sometimes need to get/set attributes specific to a virtual machine and so need something else than ONE_REG. Let's copy the KVM_DEVICE approach, and define the respective ioctls for the vm file descriptor. Signed-off-by: Dominik Dingel Reviewed-by: Cornelia Huck Acked-by: Alexander Graf Signed-off-by: Christian Borntraeger --- Documentation/virtual/kvm/api.txt | 8 ++++---- Documentation/virtual/kvm/devices/vm.txt | 10 ++++++++++ 2 files changed, 14 insertions(+), 4 deletions(-) create mode 100644 Documentation/virtual/kvm/devices/vm.txt (limited to 'Documentation') diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index a9380ba5..2014ff1 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -2314,8 +2314,8 @@ struct kvm_create_device { 4.80 KVM_SET_DEVICE_ATTR/KVM_GET_DEVICE_ATTR -Capability: KVM_CAP_DEVICE_CTRL -Type: device ioctl +Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device +Type: device ioctl, vm ioctl Parameters: struct kvm_device_attr Returns: 0 on success, -1 on error Errors: @@ -2340,8 +2340,8 @@ struct kvm_device_attr { 4.81 KVM_HAS_DEVICE_ATTR -Capability: KVM_CAP_DEVICE_CTRL -Type: device ioctl +Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device +Type: device ioctl, vm ioctl Parameters: struct kvm_device_attr Returns: 0 on success, -1 on error Errors: diff --git a/Documentation/virtual/kvm/devices/vm.txt b/Documentation/virtual/kvm/devices/vm.txt new file mode 100644 index 0000000..562bee6 --- /dev/null +++ b/Documentation/virtual/kvm/devices/vm.txt @@ -0,0 +1,10 @@ +Generic vm interface +==================================== + +The virtual machine "device" also accepts the ioctls KVM_SET_DEVICE_ATTR, +KVM_GET_DEVICE_ATTR, and KVM_HAS_DEVICE_ATTR. The interface uses the same +struct kvm_device_attr as other devices, but targets VM-wide settings +and controls. + +The groups and attributes per virtual machine, if any, are architecture +specific. -- cgit v1.1 From 4f718eab262868aeab83774ec4ce25e6a9906657 Mon Sep 17 00:00:00 2001 From: Dominik Dingel Date: Wed, 9 Apr 2014 13:13:00 +0200 Subject: KVM: s390: Exploiting generic userspace interface for cmma To enable CMMA and to reset its state we use the vm kvm_device ioctls, encapsulating attributes within the KVM_S390_VM_MEM_CTRL group. Signed-off-by: Dominik Dingel Signed-off-by: Christian Borntraeger --- Documentation/virtual/kvm/devices/vm.txt | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virtual/kvm/devices/vm.txt b/Documentation/virtual/kvm/devices/vm.txt index 562bee6..0d16f96 100644 --- a/Documentation/virtual/kvm/devices/vm.txt +++ b/Documentation/virtual/kvm/devices/vm.txt @@ -8,3 +8,19 @@ and controls. The groups and attributes per virtual machine, if any, are architecture specific. + +1. GROUP: KVM_S390_VM_MEM_CTRL +Architectures: s390 + +1.1. ATTRIBUTE: KVM_S390_VM_MEM_CTRL +Parameters: none +Returns: -EBUSY if already a vcpus is defined, otherwise 0 + +Enables CMMA for the virtual machine + +1.2. ATTRIBUTE: KVM_S390_VM_CLR_CMMA +Parameteres: none +Returns: 0 + +Clear the CMMA status for all guest pages, so any pages the guest marked +as unused are again used any may not be reclaimed by the host. -- cgit v1.1 From ffad018cc06ea1e3ada0f613676f97d408817182 Mon Sep 17 00:00:00 2001 From: David Hildenbrand Date: Mon, 3 Feb 2014 17:18:02 +0100 Subject: KVM: s390: add documentation for diag 501 Added documentation for diag 501, stating that no subfunctions are provided and no parameters are used. Signed-off-by: David Hildenbrand Reviewed-by: Cornelia Huck Signed-off-by: Christian Borntraeger --- Documentation/virtual/kvm/s390-diag.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virtual/kvm/s390-diag.txt b/Documentation/virtual/kvm/s390-diag.txt index f1de4fb..48c4921 100644 --- a/Documentation/virtual/kvm/s390-diag.txt +++ b/Documentation/virtual/kvm/s390-diag.txt @@ -78,3 +78,5 @@ DIAGNOSE function code 'X'501 - KVM breakpoint If the function code specifies 0x501, breakpoint functions may be performed. This function code is handled by userspace. + +This diagnose function code has no subfunctions and uses no parameters. -- cgit v1.1 From e50a00be5c420b4f28836dec281cdde4bed832a2 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Thu, 17 Apr 2014 11:06:45 +0200 Subject: clocksource: sun5i: Add support for reset controller The Allwinner A31 that uses this timer has the timer IP asserted in reset. Add an optional reset property to the DT, and deassert the timer from reset if it's there. Signed-off-by: Maxime Ripard Signed-off-by: Daniel Lezcano --- .../devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.txt b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.txt index 7c26154..27cfc7d 100644 --- a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.txt +++ b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.txt @@ -9,6 +9,9 @@ Required properties: one) - clocks: phandle to the source clock (usually the AHB clock) +Optionnal properties: +- resets: phandle to a reset controller asserting the timer + Example: timer@01c60000 { @@ -19,4 +22,5 @@ timer@01c60000 { <0 53 1>, <0 54 1>; clocks = <&ahb1_gates 19>; + resets = <&ahb1rst 19>; }; -- cgit v1.1 From 64d3b6a3f480154b6727dd2187f5f2b58c15da77 Mon Sep 17 00:00:00 2001 From: Nicolas Pitre Date: Wed, 9 Apr 2014 21:24:02 +0100 Subject: ARM: 8023/1: remove remnants of the static DMA mapping It looks like the static mapping area for DMA was replaced by dynamic allocation into the vmalloc area by commit e9da6e9905e6 but the information in Documentation/arm/memory.txt was not removed accordingly. CONSISTENT_END in arch/arm/include/asm/memory.h has no more users and can be removed as well. Signed-off-by: Nicolas Pitre Signed-off-by: Russell King --- Documentation/arm/memory.txt | 7 ------- 1 file changed, 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/arm/memory.txt b/Documentation/arm/memory.txt index 4bfb9ff..d74e8a5 100644 --- a/Documentation/arm/memory.txt +++ b/Documentation/arm/memory.txt @@ -44,13 +44,6 @@ fffe0000 fffe7fff ITCM mapping area for platforms with fff00000 fffdffff Fixmap mapping region. Addresses provided by fix_to_virt() will be located here. -ffc00000 ffefffff DMA memory mapping region. Memory returned - by the dma_alloc_xxx functions will be - dynamically mapped here. - -ff000000 ffbfffff Reserved for future expansion of DMA - mapping region. - fee00000 feffffff Mapping of PCI I/O space. This is a static mapping within the vmalloc space. -- cgit v1.1 From 4cd3675ebf74d7f559038ded6aa8088e4099a83d Mon Sep 17 00:00:00 2001 From: Chema Gonzalez Date: Mon, 21 Apr 2014 09:21:24 -0700 Subject: filter: added BPF random opcode Added a new ancillary load (bpf call in eBPF parlance) that produces a 32-bit random number. We are implementing it as an ancillary load (instead of an ISA opcode) because (a) it is simpler, (b) allows easy JITing, and (c) seems more in line with generic ISAs that do not have "get a random number" as a instruction, but as an OS call. The main use for this ancillary load is to perform random packet sampling. Signed-off-by: Chema Gonzalez Acked-by: Alexei Starovoitov Acked-by: Daniel Borkmann Signed-off-by: David S. Miller --- Documentation/networking/filter.txt | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt index 81f940f..82e1cb0 100644 --- a/Documentation/networking/filter.txt +++ b/Documentation/networking/filter.txt @@ -281,6 +281,7 @@ Possible BPF extensions are shown in the following table: cpu raw_smp_processor_id() vlan_tci vlan_tx_tag_get(skb) vlan_pr vlan_tx_tag_present(skb) + rand prandom_u32() These extensions can also be prefixed with '#'. Examples for low-level BPF: @@ -308,6 +309,18 @@ Examples for low-level BPF: ret #-1 drop: ret #0 +** icmp random packet sampling, 1 in 4 + ldh [12] + jne #0x800, drop + ldb [23] + jneq #1, drop + # get a random uint32 number + ld rand + mod #4 + jneq #1, drop + ret #-1 + drop: ret #0 + ** SECCOMP filter example: ld [4] /* offsetof(struct seccomp_data, arch) */ -- cgit v1.1 From bb0f1b5c1695b4399cfd2359c114ae63edbb3ad8 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Sun, 3 Nov 2013 21:09:27 +0100 Subject: drm: pass the irq explicitly to drm_irq_install Unfortunately this requires a drm-wide change, and I didn't see a sane way around that. Luckily it's fairly simple, we just need to inline the respective get_irq implementation from either drm_pci.c or drm_platform.c. With that we can now also remove drm_dev_to_irq from drm_irq.c. Reviewed-by: Thierry Reding Reviewed-by: Laurent Pinchart Signed-off-by: Daniel Vetter --- Documentation/DocBook/drm.tmpl | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 677a025..83dd0b0 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -342,21 +342,13 @@ char *date; 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 + The passed-in 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. -- cgit v1.1 From a05e54c103b0b8e1dab5d04b411f1d48387c4903 Mon Sep 17 00:00:00 2001 From: Liu Hua Date: Fri, 18 Apr 2014 09:43:32 +0100 Subject: ARM: 8031/2: change fixmap mapping region to support 32 CPUs In 32-bit ARM systems, the fixmap mapping region can support no more than 14 CPUs(total: 896k; one CPU: 64K). And we can configure NR_CPUS up to 32. So there is a mismatch. This patch moves fixmapping region downwards to region 0xffc00000- 0xffe00000. Then the fixmap mapping region can support up to 32 CPUs. Reviewed-by: Nicolas Pitre Signed-off-by: Liu Hua Signed-off-by: Russell King --- Documentation/arm/memory.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/arm/memory.txt b/Documentation/arm/memory.txt index d74e8a5..256c5e0 100644 --- a/Documentation/arm/memory.txt +++ b/Documentation/arm/memory.txt @@ -41,7 +41,7 @@ fffe8000 fffeffff DTCM mapping area for platforms with fffe0000 fffe7fff ITCM mapping area for platforms with ITCM mounted inside the CPU. -fff00000 fffdffff Fixmap mapping region. Addresses provided +fffc0000 ffdfffff Fixmap mapping region. Addresses provided by fix_to_virt() will be located here. fee00000 feffffff Mapping of PCI I/O space. This is a static -- cgit v1.1 From c4839c87f508bdb2e5d735a064124dd6289a2853 Mon Sep 17 00:00:00 2001 From: Tushar Behera Date: Wed, 23 Apr 2014 14:43:58 +0530 Subject: ASoC: max98095: Add an explicit of_match_table Create an explicit of_match_table entry for MAX98095 codec. Also add a binding Documentation for this compatible string. Signed-off-by: Tushar Behera Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/max98095.txt | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/max98095.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/max98095.txt b/Documentation/devicetree/bindings/sound/max98095.txt new file mode 100644 index 0000000..bacbeaa --- /dev/null +++ b/Documentation/devicetree/bindings/sound/max98095.txt @@ -0,0 +1,16 @@ +MAX98095 audio CODEC + +This device supports I2C only. + +Required properties: + +- compatible : "maxim,max98095". + +- reg : The I2C address of the device. + +Example: + +max98095: codec@11 { + compatible = "maxim,max98095"; + reg = <0x11>; +}; -- cgit v1.1 From b3ca11ff59bc5842b01f13421a17e6d9a8936784 Mon Sep 17 00:00:00 2001 From: Jyri Sarha Date: Mon, 24 Mar 2014 12:15:25 +0200 Subject: ASoC: simple-card: Move dai-link level properties away from dai subnodes The properties like format, bitclock-master, frame-master, bitclock-inversion, and frame-inversion should be common to the dais connected with a dai-link. For bitclock-master and frame-master properties to be unambiguous they need to indicate the mastering dai node with a phandle. Signed-off-by: Jyri Sarha Acked-by: Jean-Francois Moine Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/simple-card.txt | 88 ++++++++++++---------- 1 file changed, 50 insertions(+), 38 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt b/Documentation/devicetree/bindings/sound/simple-card.txt index 131aa2a..9b9df14 100644 --- a/Documentation/devicetree/bindings/sound/simple-card.txt +++ b/Documentation/devicetree/bindings/sound/simple-card.txt @@ -1,6 +1,6 @@ Simple-Card: -Simple-Card specifies audio DAI connection of SoC <-> codec. +Simple-Card specifies audio DAI connections of SoC <-> codec. Required properties: @@ -10,26 +10,51 @@ Optional properties: - simple-audio-card,name : User specified audio sound card name, one string property. -- simple-audio-card,format : CPU/CODEC common audio format. - "i2s", "right_j", "left_j" , "dsp_a" - "dsp_b", "ac97", "pdm", "msb", "lsb" - simple-audio-card,widgets : Please refer to widgets.txt. - simple-audio-card,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. -- dai-tdm-slot-num : Please refer to tdm-slot.txt. -- dai-tdm-slot-width : Please refer to tdm-slot.txt. +Optional subnodes: + +- simple-audio-card,dai-link : Container for dai-link level + properties and the CPU and CODEC + sub-nodes. This container may be + omitted when the card has only one + DAI link. See the examples and the + section bellow. + +Dai-link subnode properties and subnodes: + +If dai-link subnode is omitted and the subnode properties are directly +under "sound"-node the subnode property and subnode names have to be +prefixed with "simple-audio-card,"-prefix. -Required subnodes: +Required dai-link subnodes: -- simple-audio-card,dai-link : container for the CPU and CODEC sub-nodes - This container may be omitted when the - card has only one DAI link. - See the examples. +- cpu : CPU sub-node +- codec : CODEC sub-node -- simple-audio-card,cpu : CPU sub-node -- simple-audio-card,codec : CODEC sub-node +Optional dai-link subnode properties: + +- format : CPU/CODEC common audio format. + "i2s", "right_j", "left_j" , "dsp_a" + "dsp_b", "ac97", "pdm", "msb", "lsb" +- frame-master : Indicates dai-link frame master. + phandle to a cpu or codec subnode. +- bitclock-master : Indicates dai-link bit clock master. + phandle to a cpu or codec subnode. +- bitclock-inversion : bool property. Add this if the + dai-link uses bit clock inversion. +- frame-inversion : bool property. Add this if the + dai-link uses frame clock inversion. + +For backward compatibility the frame-master and bitclock-master +properties can be used as booleans in codec subnode to indicate if the +codec is the dai-link frame or bit clock master. In this case there +should be no dai-link node, the same properties should not be present +at sound-node level, and the bitclock-inversion and frame-inversion +properties should also be placed in the codec node if needed. Required CPU/CODEC subnodes properties: @@ -37,29 +62,21 @@ Required CPU/CODEC subnodes properties: Optional CPU/CODEC subnodes properties: -- format : CPU/CODEC specific audio format if needed. - see simple-audio-card,format -- frame-master : bool property. add this if subnode is frame master -- bitclock-master : bool property. add this if subnode is bitclock master -- bitclock-inversion : bool property. add this if subnode has clock inversion -- frame-inversion : bool property. add this if subnode has frame inversion +- dai-tdm-slot-num : Please refer to tdm-slot.txt. +- dai-tdm-slot-width : Please refer to tdm-slot.txt. - clocks / system-clock-frequency : specify subnode's clock if needed. it can be specified via "clocks" if system has clock node (= common clock), or "system-clock-frequency" (if system doens't support common clock) -Note: - * For 'format', 'frame-master', 'bitclock-master', 'bitclock-inversion' and - 'frame-inversion', the simple card will use the settings of CODEC for both - CPU and CODEC sides as we need to keep the settings identical for both ends - of the link. - Example 1 - single DAI link: sound { compatible = "simple-audio-card"; simple-audio-card,name = "VF610-Tower-Sound-Card"; simple-audio-card,format = "left_j"; + simple-audio-card,bitclock-master = <&dailink0_master>; + simple-audio-card,frame-master = <&dailink0_master>; simple-audio-card,widgets = "Microphone", "Microphone Jack", "Headphone", "Headphone Jack", @@ -69,17 +86,12 @@ sound { "Headphone Jack", "HP_OUT", "External Speaker", "LINE_OUT"; - dai-tdm-slot-num = <2>; - dai-tdm-slot-width = <8>; - simple-audio-card,cpu { sound-dai = <&sh_fsi2 0>; }; - simple-audio-card,codec { + dailink0_master: simple-audio-card,codec { sound-dai = <&ak4648>; - bitclock-master; - frame-master; clocks = <&osc>; }; }; @@ -105,31 +117,31 @@ Example 2 - many DAI links: sound { compatible = "simple-audio-card"; simple-audio-card,name = "Cubox Audio"; - simple-audio-card,format = "i2s"; simple-audio-card,dai-link@0 { /* I2S - HDMI */ - simple-audio-card,cpu { + format = "i2s"; + cpu { sound-dai = <&audio1 0>; }; - simple-audio-card,codec { + codec { sound-dai = <&tda998x 0>; }; }; simple-audio-card,dai-link@1 { /* S/PDIF - HDMI */ - simple-audio-card,cpu { + cpu { sound-dai = <&audio1 1>; }; - simple-audio-card,codec { + codec { sound-dai = <&tda998x 1>; }; }; simple-audio-card,dai-link@2 { /* S/PDIF - S/PDIF */ - simple-audio-card,cpu { + cpu { sound-dai = <&audio1 1>; }; - simple-audio-card,codec { + codec { sound-dai = <&spdif_codec>; }; }; -- cgit v1.1 From def8397c115dd456f80e7e5202bba8c2df79f936 Mon Sep 17 00:00:00 2001 From: Daniel Mack Date: Fri, 28 Mar 2014 19:05:05 +0100 Subject: ASoC: ak4104: Add regulator to documentation Add the vdd supply to Documentation/devicetree/bindings/sound/ak4104.txt. Signed-off-by: Daniel Mack Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/ak4104.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/ak4104.txt b/Documentation/devicetree/bindings/sound/ak4104.txt index b902ee3..deca5e1 100644 --- a/Documentation/devicetree/bindings/sound/ak4104.txt +++ b/Documentation/devicetree/bindings/sound/ak4104.txt @@ -8,6 +8,8 @@ Required properties: - reg : The chip select number on the SPI bus + - vdd-supply : A regulator node, providing 2.7V - 3.6V + Optional properties: - reset-gpio : a GPIO spec for the reset pin. If specified, it will be @@ -19,4 +21,5 @@ spdif: ak4104@0 { compatible = "asahi-kasei,ak4104"; reg = <0>; spi-max-frequency = <5000000>; + vdd-supply = <&vdd_3v3_reg>; }; -- cgit v1.1 From c3e1870c4aa320b592ef5ebcb5dd0690657a1226 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 23 Apr 2014 09:58:16 -0300 Subject: Documentation: Update cardlists Two new devices were added, but the cardlists weren't updated. Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/CARDLIST.bttv | 1 + Documentation/video4linux/CARDLIST.em28xx | 1 + 2 files changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/video4linux/CARDLIST.bttv b/Documentation/video4linux/CARDLIST.bttv index 2f6e935..b092c0a 100644 --- a/Documentation/video4linux/CARDLIST.bttv +++ b/Documentation/video4linux/CARDLIST.bttv @@ -164,3 +164,4 @@ 163 -> Bt848 Capture 14MHz 164 -> CyberVision CV06 (SV) 165 -> Kworld V-Stream Xpert TV PVR878 +166 -> PCI-8604PW diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx index e085b12..5a3ddcd3 100644 --- a/Documentation/video4linux/CARDLIST.em28xx +++ b/Documentation/video4linux/CARDLIST.em28xx @@ -92,3 +92,4 @@ 91 -> SpeedLink Vicious And Devine Laplace webcam (em2765) [1ae7:9003,1ae7:9004] 92 -> PCTV DVB-S2 Stick (461e) (em28178) 93 -> KWorld USB ATSC TV Stick UB435-Q V3 (em2874) [1b80:e34c] + 94 -> PCTV tripleStick (292e) (em28178) -- cgit v1.1 From e37559b22c63b557d242bfa1a07ab1b8f7d5d9f1 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Thu, 17 Apr 2014 02:47:21 -0300 Subject: [media] vb2: stop_streaming should return void The vb2 core ignores any return code from the stop_streaming op. And there really isn't anything it can do anyway in case of an error. So change the return type to void and update any drivers that implement it. The int return gave drivers the idea that this operation could actually fail, but that's really not the case. The pwc amd sdr-msi3101 drivers both had this construction: if (mutex_lock_interruptible(&s->v4l2_lock)) return -ERESTARTSYS; This has been updated to just call mutex_lock(). The stop_streaming op expects this to really stop streaming and I very much doubt this will work reliably if stop_streaming just returns without really stopping the DMA. Signed-off-by: Hans Verkuil Acked-by: Pawel Osciak Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/v4l2-pci-skeleton.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/v4l2-pci-skeleton.c b/Documentation/video4linux/v4l2-pci-skeleton.c index 80251dc..53dd346 100644 --- a/Documentation/video4linux/v4l2-pci-skeleton.c +++ b/Documentation/video4linux/v4l2-pci-skeleton.c @@ -269,7 +269,7 @@ static int start_streaming(struct vb2_queue *vq, unsigned int count) * Stop the DMA engine. Any remaining buffers in the DMA queue are dequeued * and passed on to the vb2 framework marked as STATE_ERROR. */ -static int stop_streaming(struct vb2_queue *vq) +static void stop_streaming(struct vb2_queue *vq) { struct skeleton *skel = vb2_get_drv_priv(vq); @@ -277,7 +277,6 @@ static int stop_streaming(struct vb2_queue *vq) /* Release all active buffers */ return_all_buffers(skel, VB2_BUF_STATE_ERROR); - return 0; } /* -- cgit v1.1 From 34d1cbdafd5b27bc06f47f557e0581b7b85d6f07 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Tue, 8 Apr 2014 13:39:59 -0300 Subject: [media] v4l: vsp1: Add DT bindings documentation All parameters supplied through platform data can now be passed through the device tree. Signed-off-by: Laurent Pinchart Acked-by: Sylwester Nawrocki Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/media/renesas,vsp1.txt | 43 ++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/renesas,vsp1.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.txt b/Documentation/devicetree/bindings/media/renesas,vsp1.txt new file mode 100644 index 0000000..87fe08a --- /dev/null +++ b/Documentation/devicetree/bindings/media/renesas,vsp1.txt @@ -0,0 +1,43 @@ +* Renesas VSP1 Video Processing Engine + +The VSP1 is a video processing engine that supports up-/down-scaling, alpha +blending, color space conversion and various other image processing features. +It can be found in the Renesas R-Car second generation SoCs. + +Required properties: + + - compatible: Must contain "renesas,vsp1" + + - reg: Base address and length of the registers block for the VSP1. + - interrupts: VSP1 interrupt specifier. + - clocks: A phandle + clock-specifier pair for the VSP1 functional clock. + + - renesas,#rpf: Number of Read Pixel Formatter (RPF) modules in the VSP1. + - renesas,#uds: Number of Up Down Scaler (UDS) modules in the VSP1. + - renesas,#wpf: Number of Write Pixel Formatter (WPF) modules in the VSP1. + + +Optional properties: + + - renesas,has-lif: Boolean, indicates that the LCD Interface (LIF) module is + available. + - renesas,has-lut: Boolean, indicates that the Look Up Table (LUT) module is + available. + - renesas,has-sru: Boolean, indicates that the Super Resolution Unit (SRU) + module is available. + + +Example: R8A7790 (R-Car H2) VSP1-S node + + vsp1@fe928000 { + compatible = "renesas,vsp1"; + reg = <0 0xfe928000 0 0x8000>; + interrupts = <0 267 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp1_clks R8A7790_CLK_VSP1_S>; + + renesas,has-lut; + renesas,has-sru; + renesas,#rpf = <5>; + renesas,#uds = <3>; + renesas,#wpf = <4>; + }; -- cgit v1.1 From 02b5269a24dfadf2fda6b427b84ee57bd3a06a72 Mon Sep 17 00:00:00 2001 From: Boris BREZILLON Date: Tue, 22 Apr 2014 15:38:06 +0200 Subject: pinctrl: sunxi: list all pinctrl compatible strings List all sunxi pinctrl compatible strings in order to be able to grep for those values. Signed-off-by: Boris BREZILLON Signed-off-by: Linus Walleij --- .../devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt index dff0e5f..d8d0656 100644 --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt @@ -6,8 +6,13 @@ the first two functions being GPIO in and out. The configuration on the pins includes drive strength and pull-up. Required properties: -- compatible: "allwinner,-pinctrl". Supported SoCs for now are: - sun5i-a13. +- compatible: Should be one of the followings (depending on you SoC): + "allwinner,sun4i-a10-pinctrl" + "allwinner,sun5i-a10s-pinctrl" + "allwinner,sun5i-a13-pinctrl" + "allwinner,sun6i-a31-pinctrl" + "allwinner,sun6i-a31-r-pinctrl" + "allwinner,sun7i-a20-pinctrl" - reg: Should contain the register physical address and length for the pin controller. -- cgit v1.1 From 625cb407b85a9e4208f1db5377cc08dd4a0d5387 Mon Sep 17 00:00:00 2001 From: Andy Gross Date: Mon, 14 Apr 2014 22:10:36 -0500 Subject: dt: Document Qualcomm IPQ8064 pinctrl binding Define a new binding for the Qualcomm TLMMv2 based pin controller inside the IPQ8064. Signed-off-by: Andy Gross Reviewed-by: Bjorn Andersson Signed-off-by: Linus Walleij --- .../bindings/pinctrl/qcom,ipq8064-pinctrl.txt | 95 ++++++++++++++++++++++ 1 file changed, 95 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt new file mode 100644 index 0000000..e0d35a4 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt @@ -0,0 +1,95 @@ +Qualcomm IPQ8064 TLMM block + +Required properties: +- compatible: "qcom,ipq8064-pinctrl" +- reg: Should be the base address and length of the TLMM block. +- interrupts: Should be the parent IRQ of the TLMM block. +- interrupt-controller: Marks the device node as an interrupt controller. +- #interrupt-cells: Should be two. +- gpio-controller: Marks the device node as a GPIO controller. +- #gpio-cells : Should be two. + The first cell is the gpio pin number and the + second cell is used for optional parameters. + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +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". + +Qualcomm'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. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + + pins, function, bias-disable, bias-pull-down, bias-pull,up, drive-strength, + output-low, output-high. + +Non-empty subnodes must specify the 'pins' property. + +Valid values for qcom,pins are: + gpio0-gpio68 + Supports mux, bias, and drive-strength + + sdc3_clk, sdc3_cmd, sdc3_data + Supports bias and drive-strength + + +Valid values for function are: + mdio, mi2s, pdm, ssbi, spmi, audio_pcm, gsbi1, gsbi2, gsbi4, gsbi5, + gsbi5_spi_cs1, gsbi5_spi_cs2, gsbi5_spi_cs3, gsbi6, gsbi7, nss_spi, sdc1, + spdif, nand, tsif1, tsif2, usb_fs_n, usb_fs, usb2_hsic, rgmii2, sata, + pcie1_rst, pcie1_prsnt, pcie1_pwren_n, pcie1_pwren, pcie1_pwrflt, + pcie1_clk_req, pcie2_rst, pcie2_prsnt, pcie2_pwren_n, pcie2_pwren, + pcie2_pwrflt, pcie2_clk_req, pcie3_rst, pcie3_prsnt, pcie3_pwren_n, + pcie3_pwren, pcie3_pwrflt, pcie3_clk_req, ps_hold + +Example: + + pinmux: pinctrl@800000 { + compatible = "qcom,ipq8064-pinctrl"; + reg = <0x800000 0x4000>; + + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <0 32 0x4>; + + pinctrl-names = "default"; + pinctrl-0 = <&gsbi5_uart_default>; + + gsbi5_uart_default: gsbi5_uart_default { + mux { + pins = "gpio18", "gpio19"; + function = "gsbi5"; + }; + + tx { + pins = "gpio18"; + drive-strength = <4>; + bias-disable; + }; + + rx { + pins = "gpio19"; + drive-strength = <2>; + bias-pull-up; + }; + }; + }; -- cgit v1.1 From 2d283862dc62daead9db0dc89cd0d0351e91f765 Mon Sep 17 00:00:00 2001 From: Alexey Charkov Date: Tue, 22 Apr 2014 19:28:09 +0400 Subject: net: via-rhine: add OF bus binding This should make the driver usable with VIA/WonderMedia ARM-based Systems-on-Chip integrated Rhine III adapters. Note that these are always in MMIO mode, and don't have any known EEPROM. Signed-off-by: Alexey Charkov Acked-by: Rob Herring Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/via-rhine.txt | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/via-rhine.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/via-rhine.txt b/Documentation/devicetree/bindings/net/via-rhine.txt new file mode 100644 index 0000000..334eca2 --- /dev/null +++ b/Documentation/devicetree/bindings/net/via-rhine.txt @@ -0,0 +1,17 @@ +* VIA Rhine 10/100 Network Controller + +Required properties: +- compatible : Should be "via,vt8500-rhine" for integrated + Rhine controllers found in VIA VT8500, WonderMedia WM8950 + and similar. These are listed as 1106:3106 rev. 0x84 on the + virtual PCI bus under vendor-provided kernels +- reg : Address and length of the io space +- interrupts : Should contain the controller interrupt line + +Examples: + +ethernet@d8004000 { + compatible = "via,vt8500-rhine"; + reg = <0xd8004000 0x100>; + interrupts = <10>; +}; -- cgit v1.1 From 924d38f404936495b59ef7fa3ff232d978d64b18 Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Mon, 14 Apr 2014 15:46:59 +0200 Subject: ARM: mvebu: prepare coherency code to support more SOCs The code that handles the coherency fabric of Armada 370 and Armada XP in arch/arm/mach-mvebu/coherency.c made the assumption that there was only one type of coherency fabric. Unfortunately, it turns out that upcoming SoCs have a slightly different coherency unit. In preparation to the introduction of the coherency support for more SoCs, this commit: * Introduces a data associated to the compatible string in the compatible string match table, so that the code can differantiate the variant of coherency unit being used. * Separates the coherency unit initialization code into its own function. Signed-off-by: Thomas Petazzoni Link: https://lkml.kernel.org/r/1397483228-25625-2-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper --- Documentation/devicetree/bindings/arm/coherency-fabric.txt | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/coherency-fabric.txt b/Documentation/devicetree/bindings/arm/coherency-fabric.txt index 17d8cd1..f0bfa37 100644 --- a/Documentation/devicetree/bindings/arm/coherency-fabric.txt +++ b/Documentation/devicetree/bindings/arm/coherency-fabric.txt @@ -4,7 +4,10 @@ Available on Marvell SOCs: Armada 370 and Armada XP Required properties: -- compatible: "marvell,coherency-fabric" +- compatible: the possible values are: + + * "marvell,coherency-fabric", to be used for the coherency fabric of + the Armada 370 and Armada XP. - reg: Should contain coherency fabric registers location and length. First pair for the coherency fabric registers, second pair -- cgit v1.1 From 77fa4b9ab0aafc0a06976814ad62aeff990dfd2c Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Mon, 14 Apr 2014 15:47:04 +0200 Subject: ARM: mvebu: add Armada 375 support to the coherency code The Armada 375, like the Armada 370 and Armada XP, has a coherency unit. However, unlike the coherency unit of 370/XP which does both CPU and I/O coherency, the one on Armada 735 only does I/O coherency. Therefore, instead of having two sets of registers (the first one being used mainly to register each CPU in the coherency fabric, the second one being used for the I/O coherency barrier), it has only one set of register (for the I/O coherency barrier). This commit adds a new "marvell,armada-375-coherency-fabric" compatible string for this variant of the coherency fabric. The custom DMA operations, and the way of triggering an I/O barrier is the same as Armada 370/XP, so the code changes are minimal. However, the set_cpu_coherent() function is not needed on Armada 375 and will not work. Signed-off-by: Thomas Petazzoni Link: https://lkml.kernel.org/r/1397483228-25625-7-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper --- .../devicetree/bindings/arm/coherency-fabric.txt | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/coherency-fabric.txt b/Documentation/devicetree/bindings/arm/coherency-fabric.txt index f0bfa37..dcd80d6 100644 --- a/Documentation/devicetree/bindings/arm/coherency-fabric.txt +++ b/Documentation/devicetree/bindings/arm/coherency-fabric.txt @@ -1,6 +1,6 @@ Coherency fabric ---------------- -Available on Marvell SOCs: Armada 370 and Armada XP +Available on Marvell SOCs: Armada 370, Armada 375 and Armada XP Required properties: @@ -9,11 +9,20 @@ Required properties: * "marvell,coherency-fabric", to be used for the coherency fabric of the Armada 370 and Armada XP. + * "marvell,armada-375-coherency-fabric", for the Armada 375 coherency + fabric. + - reg: Should contain coherency fabric registers location and - length. First pair for the coherency fabric registers, second pair - for the per-CPU fabric registers registers. + length. + + * For "marvell,coherency-fabric", the first pair for the coherency + fabric registers, second pair for the per-CPU fabric registers. + + * For "marvell,armada-375-coherency-fabric", only one pair is needed + for the per-CPU fabric registers. -Example: + +Examples: coherency-fabric@d0020200 { compatible = "marvell,coherency-fabric"; @@ -22,3 +31,8 @@ coherency-fabric@d0020200 { }; +coherency-fabric@21810 { + compatible = "marvell,armada-375-coherency-fabric"; + reg = <0x21810 0x1c>; +}; + -- cgit v1.1 From d0de9323822fada543f2f244eb67f520aa21ed77 Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Mon, 14 Apr 2014 15:47:06 +0200 Subject: ARM: mvebu: add Armada 38x support to the coherency code The Armada 38x has a coherency unit that is similar to the one of the Armada 375 SoC, except that it does not have the bug of the Armada 375 coherency unit that requires the XOR based workaround. This commit therefore extends the Marvell EBU coherency code with a new compatible string to support the Armada 38x coherency unit. Signed-off-by: Thomas Petazzoni Link: https://lkml.kernel.org/r/1397483228-25625-9-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper --- Documentation/devicetree/bindings/arm/coherency-fabric.txt | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/coherency-fabric.txt b/Documentation/devicetree/bindings/arm/coherency-fabric.txt index dcd80d6..8dd4661 100644 --- a/Documentation/devicetree/bindings/arm/coherency-fabric.txt +++ b/Documentation/devicetree/bindings/arm/coherency-fabric.txt @@ -1,6 +1,6 @@ Coherency fabric ---------------- -Available on Marvell SOCs: Armada 370, Armada 375 and Armada XP +Available on Marvell SOCs: Armada 370, Armada 375, Armada 38x and Armada XP Required properties: @@ -12,6 +12,9 @@ Required properties: * "marvell,armada-375-coherency-fabric", for the Armada 375 coherency fabric. + * "marvell,armada-380-coherency-fabric", for the Armada 38x coherency + fabric. + - reg: Should contain coherency fabric registers location and length. @@ -21,6 +24,8 @@ Required properties: * For "marvell,armada-375-coherency-fabric", only one pair is needed for the per-CPU fabric registers. + * For "marvell,armada-380-coherency-fabric", only one pair is needed + for the per-CPU fabric registers. Examples: -- cgit v1.1 From 3f20fb1153b374737acd40d42cb3cab2ae5dae35 Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Mon, 14 Apr 2014 15:50:28 +0200 Subject: ARM: mvebu: introduce CPU reset code The Armada 370 and Armada XP have registers that allow to reset the CPUs, which is particularly useful to take the secondary CPUs out of reset in the context of the SMP support. Unfortunately, an implementation mistake was originally made and the support for these registers was integrated into the PMSU driver, which is in fact completely unrelated. And it turns out that the Armada 375 has the same CPU reset registers, but does not have the PMSU registers. Therefore, this commit creates a small CPU reset driver. All it does is provide a simple mvebu_cpu_reset_deassert() function that the SMP support code can call to take secondary CPUs out of reset. As of this commit, the driver isn't being used, it will be used through changes in the following commits. Note that we initially planned to use the 'reset controller' framework, but it requires the addition of "resets" properties in the Device Tree, which are causing too many problems if we want to keep the Device Tree backward compatibility. Moreover, the 'reset controller' framework is mainly useful when a device driver needs to request a reset of its device from a separate reset controller. In our case, the CPU reset handling and the SMP core code are both located in arch/arm/mach-mvebu/ and are tightly linked together, so there's no real benefit in going through a separate framework. Signed-off-by: Thomas Petazzoni Link: https://lkml.kernel.org/r/1397483433-25836-2-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper --- Documentation/devicetree/bindings/arm/armada-cpu-reset.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/armada-cpu-reset.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/armada-cpu-reset.txt b/Documentation/devicetree/bindings/arm/armada-cpu-reset.txt new file mode 100644 index 0000000..b63a7b6 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/armada-cpu-reset.txt @@ -0,0 +1,14 @@ +Marvell Armada CPU reset controller +=================================== + +Required properties: + +- compatible: Should be "marvell,armada-370-cpu-reset". + +- reg: should be register base and length as documented in the + datasheet for the CPU reset registers + +cpurst: cpurst@20800 { + compatible = "marvell,armada-370-cpu-reset"; + reg = <0x20800 0x20>; +}; -- cgit v1.1 From 0c3acc746d2cd84c3654b6cc07eda2411584f4af Mon Sep 17 00:00:00 2001 From: Gregory CLEMENT Date: Mon, 14 Apr 2014 15:50:31 +0200 Subject: ARM: mvebu: extend the PMSU registers The initial binding for PMSU was wrong, as it didn't take into account all the registers from the PMSU and moreover it referred to the CPU reset registers which are not part of PMSU. The Power Management Unit Service block also controls the Coherency Fabric subsystem. These registers are needed for the CPU idle implementation for the Armada 370/XP, it allows to enter a deep CPU idle state where the Coherency Fabric and the L2 cache are powered down. This commit adds support for a new compatible for the PMSU node which includes the registers related to the coherency fabric. It also keeps compatibility with the old compatible string. Signed-off-by: Gregory CLEMENT Link: https://lkml.kernel.org/r/1397483433-25836-5-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Thomas Petazzoni Link: https://lkml.kernel.org/r/1397483433-25836-5-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper --- .../devicetree/bindings/arm/armada-370-xp-pmsu.txt | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt index 926b4d6..9761887 100644 --- a/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt +++ b/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt @@ -4,17 +4,15 @@ Available on Marvell SOCs: Armada 370 and Armada XP Required properties: -- compatible: "marvell,armada-370-xp-pmsu" +- compatible: should be "marvell,armada-370-pmsu", whereas + "marvell,armada-370-xp-pmsu" is deprecated and will be removed -- reg: Should contain PMSU registers location and length. First pair - for the per-CPU SW Reset Control registers, second pair for the - Power Management Service Unit. +- reg: Should contain PMSU registers location and length. Example: -armada-370-xp-pmsu@d0022000 { - compatible = "marvell,armada-370-xp-pmsu"; - reg = <0xd0022100 0x430>, - <0xd0020800 0x20>; +armada-370-xp-pmsu@22000 { + compatible = "marvell,armada-370-pmsu"; + reg = <0x22000 0x1000>; }; -- cgit v1.1 From 376e242429bf8539ef39a080ac113c8799840b13 Mon Sep 17 00:00:00 2001 From: Masami Hiramatsu Date: Thu, 17 Apr 2014 17:17:05 +0900 Subject: kprobes: Introduce NOKPROBE_SYMBOL() macro to maintain kprobes blacklist MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Introduce NOKPROBE_SYMBOL() macro which builds a kprobes blacklist at kernel build time. The usage of this macro is similar to EXPORT_SYMBOL(), placed after the function definition: NOKPROBE_SYMBOL(function); Since this macro will inhibit inlining of static/inline functions, this patch also introduces a nokprobe_inline macro for static/inline functions. In this case, we must use NOKPROBE_SYMBOL() for the inline function caller. When CONFIG_KPROBES=y, the macro stores the given function address in the "_kprobe_blacklist" section. Since the data structures are not fully initialized by the macro (because there is no "size" information), those are re-initialized at boot time by using kallsyms. Signed-off-by: Masami Hiramatsu Link: http://lkml.kernel.org/r/20140417081705.26341.96719.stgit@ltc230.yrl.intra.hitachi.co.jp Cc: Alok Kataria Cc: Ananth N Mavinakayanahalli Cc: Andrew Morton Cc: Anil S Keshavamurthy Cc: Arnd Bergmann Cc: Christopher Li Cc: Chris Wright Cc: David S. Miller Cc: Jan-Simon Möller Cc: Jeremy Fitzhardinge Cc: Linus Torvalds Cc: Randy Dunlap Cc: Rusty Russell Cc: linux-arch@vger.kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-sparse@vger.kernel.org Cc: virtualization@lists.linux-foundation.org Signed-off-by: Ingo Molnar --- Documentation/kprobes.txt | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt index 0cfb00f..4bbeca8 100644 --- a/Documentation/kprobes.txt +++ b/Documentation/kprobes.txt @@ -22,8 +22,9 @@ Appendix B: The kprobes sysctl interface Kprobes enables you to dynamically break into any kernel routine and collect debugging and performance information non-disruptively. You -can trap at almost any kernel code address, specifying a handler +can trap at almost any kernel code address(*), specifying a handler routine to be invoked when the breakpoint is hit. +(*: some parts of the kernel code can not be trapped, see 1.5 Blacklist) There are currently three types of probes: kprobes, jprobes, and kretprobes (also called return probes). A kprobe can be inserted @@ -273,6 +274,19 @@ using one of the following techniques: or - Execute 'sysctl -w debug.kprobes_optimization=n' +1.5 Blacklist + +Kprobes can probe most of the kernel except itself. This means +that there are some functions where kprobes cannot probe. Probing +(trapping) such functions can cause a recursive trap (e.g. double +fault) or the nested probe handler may never be called. +Kprobes manages such functions as a blacklist. +If you want to add a function into the blacklist, you just need +to (1) include linux/kprobes.h and (2) use NOKPROBE_SYMBOL() macro +to specify a blacklisted function. +Kprobes checks the given probe address against the blacklist and +rejects registering it, if the given address is in the blacklist. + 2. Architectures Supported Kprobes, jprobes, and return probes are implemented on the following -- cgit v1.1 From fd67f884782a281eb033e40b0f8eae623416035e Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Tue, 22 Apr 2014 23:26:07 +0200 Subject: pinctrl: mvebu: new driver for Orion platforms This commit extends the pinctrl mvebu logic with a new driver to cover Orion5x SoC. It supports the definitions for the 5181l, 5182 and 5281 variants of Orion5x, which are the three ones supported by the old style MPP code in arch/arm/mach-orion5x/. Signed-off-by: Thomas Petazzoni Acked-by: Sebastian Hesselbarth Signed-off-by: Linus Walleij --- .../bindings/pinctrl/marvell,orion-pinctrl.txt | 91 ++++++++++++++++++++++ 1 file changed, 91 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/marvell,orion-pinctrl.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,orion-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,orion-pinctrl.txt new file mode 100644 index 0000000..27570a3 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/marvell,orion-pinctrl.txt @@ -0,0 +1,91 @@ +* Marvell Orion SoC pinctrl driver for mpp + +Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding +part and usage. + +Required properties: +- compatible: "marvell,88f5181l-pinctrl", "marvell,88f5182-pinctrl", + "marvell,88f5281-pinctrl" + +- reg: two register areas, the first one describing the first two + contiguous MPP registers, and the second one describing the single + final MPP register, separated from the previous one. + +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. + +* Marvell Orion 88f5181l + +name pins functions +================================================================================ +mpp0 0 pcie(rstout), pci(req2), gpio +mpp1 1 gpio, pci(gnt2) +mpp2 2 gpio, pci(req3), pci-1(pme) +mpp3 3 gpio, pci(gnt3) +mpp4 4 gpio, pci(req4) +mpp5 5 gpio, pci(gnt4) +mpp6 6 gpio, pci(req5), pci-1(clk) +mpp7 7 gpio, pci(gnt5), pci-1(clk) +mpp8 8 gpio, ge(col) +mpp9 9 gpio, ge(rxerr) +mpp10 10 gpio, ge(crs) +mpp11 11 gpio, ge(txerr) +mpp12 12 gpio, ge(txd4) +mpp13 13 gpio, ge(txd5) +mpp14 14 gpio, ge(txd6) +mpp15 15 gpio, ge(txd7) +mpp16 16 ge(rxd4) +mpp17 17 ge(rxd5) +mpp18 18 ge(rxd6) +mpp19 19 ge(rxd7) + +* Marvell Orion 88f5182 + +name pins functions +================================================================================ +mpp0 0 pcie(rstout), pci(req2), gpio +mpp1 1 gpio, pci(gnt2) +mpp2 2 gpio, pci(req3), pci-1(pme) +mpp3 3 gpio, pci(gnt3) +mpp4 4 gpio, pci(req4), bootnand(re), sata0(prsnt) +mpp5 5 gpio, pci(gnt4), bootnand(we), sata1(prsnt) +mpp6 6 gpio, pci(req5), nand(re0), sata0(act) +mpp7 7 gpio, pci(gnt5), nand(we0), sata1(act) +mpp8 8 gpio, ge(col) +mpp9 9 gpio, ge(rxerr) +mpp10 10 gpio, ge(crs) +mpp11 11 gpio, ge(txerr) +mpp12 12 gpio, ge(txd4), nand(re1), sata0(ledprsnt) +mpp13 13 gpio, ge(txd5), nand(we1), sata1(ledprsnt) +mpp14 14 gpio, ge(txd6), nand(re2), sata0(ledact) +mpp15 15 gpio, ge(txd7), nand(we2), sata1(ledact) +mpp16 16 uart1(rxd), ge(rxd4), gpio +mpp17 17 uart1(txd), ge(rxd5), gpio +mpp18 18 uart1(cts), ge(rxd6), gpio +mpp19 19 uart1(rts), ge(rxd7), gpio + +* Marvell Orion 88f5281 + +name pins functions +================================================================================ +mpp0 0 pcie(rstout), pci(req2), gpio +mpp1 1 gpio, pci(gnt2) +mpp2 2 gpio, pci(req3), pci(pme) +mpp3 3 gpio, pci(gnt3) +mpp4 4 gpio, pci(req4), bootnand(re) +mpp5 5 gpio, pci(gnt4), bootnand(we) +mpp6 6 gpio, pci(req5), nand(re0) +mpp7 7 gpio, pci(gnt5), nand(we0) +mpp8 8 gpio, ge(col) +mpp9 9 gpio, ge(rxerr) +mpp10 10 gpio, ge(crs) +mpp11 11 gpio, ge(txerr) +mpp12 12 gpio, ge(txd4), nand(re1) +mpp13 13 gpio, ge(txd5), nand(we1) +mpp14 14 gpio, ge(txd6), nand(re2) +mpp15 15 gpio, ge(txd7), nand(we2) +mpp16 16 uart1(rxd), ge(rxd4) +mpp17 17 uart1(txd), ge(rxd5) +mpp18 18 uart1(cts), ge(rxd6) +mpp19 19 uart1(rts), ge(rxd7) -- cgit v1.1 From 20e5ea191524b482e1b4aa12b5ff4684717f44b8 Mon Sep 17 00:00:00 2001 From: Baruch Siach Date: Fri, 31 Jan 2014 12:07:45 +0200 Subject: spi: dw: document device tree binding Signed-off-by: Baruch Siach Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/spi-dw.txt | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/spi-dw.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-dw.txt b/Documentation/devicetree/bindings/spi/spi-dw.txt new file mode 100644 index 0000000..7b63ed6 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-dw.txt @@ -0,0 +1,24 @@ +Synopsys DesignWare SPI master + +Required properties: +- compatible: should be "snps,designware-spi" +- #address-cells: see spi-bus.txt +- #size-cells: see spi-bus.txt +- reg: address and length of the spi master registers +- interrupts: should contain one interrupt +- clocks: spi clock phandle +- num-cs: see spi-bus.txt + +Optional properties: +- cs-gpios: see spi-bus.txt + +Example: + +spi: spi@4020a000 { + compatible = "snps,designware-spi"; + interrupts = <11 1>; + reg = <0x4020a000 0x1000>; + clocks = <&pclk>; + num-cs = <2>; + cs-gpios = <&banka 0 0>; +}; -- cgit v1.1 From f05b42eaa22cd7c6736d31316e6046c5127f8721 Mon Sep 17 00:00:00 2001 From: Mahesh Bandewar Date: Tue, 22 Apr 2014 16:30:20 -0700 Subject: bonding: Added bond_tlb_xmit() for tlb mode. Re-organized the xmit function for the lb mode separating tlb xmit from the alb mode. This will enable use of the hashing policies like 802.3ad mode. Also extended use of xmit-hash-policy to tlb mode. Now the tlb-mode defaults to BOND_XMIT_POLICY_LAYER2 if the xmit policy module parameter is not set (just like 802.3ad, or Xor mode). Change-Id: I140257403d272df75f477b380207338d0f04963e Signed-off-by: Mahesh Bandewar Acked-by: Eric Dumazet Signed-off-by: David S. Miller --- Documentation/networking/bonding.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index a383c00..a97c567 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt @@ -769,7 +769,7 @@ use_carrier xmit_hash_policy Selects the transmit hash policy to use for slave selection in - balance-xor and 802.3ad modes. Possible values are: + balance-xor, 802.3ad, and tlb modes. Possible values are: layer2 -- cgit v1.1 From e9f0fb88493570200b8dc1cc02d3e676412d25bc Mon Sep 17 00:00:00 2001 From: Mahesh Bandewar Date: Tue, 22 Apr 2014 16:30:22 -0700 Subject: bonding: Add tlb_dynamic_lb parameter for tlb mode The aggresive load balancing causes packet re-ordering as active flows are moved from a slave to another within the group. Sometime this aggresive lb is not necessary if the preference is for less re-ordering. This parameter if used with value "0" disables this dynamic flow shuffling minimizing packet re-ordering. Of course the side effect is that it has to live with the static load balancing that the hashing distribution provides. This impact is less severe if the correct xmit-hashing-policy is used for the tlb setup. The default value of the parameter is set to "1" mimicing the earlier behavior. Ran the netperf test with 200 stream for 1 min between two hosts with 4x1G trunk (xmit-lb mode with xmit-policy L3+4) before and after these changes. Following was the command used for those 200 instances - netperf -t TCP_RR -l 60 -s 5 -H -- -r81920,81920 Transactions per second: Before change: 1,367.11 After change: 1,470.65 Change-Id: Ie3f75c77282cf602e83a6e833c6eb164e72a0990 Signed-off-by: Mahesh Bandewar Signed-off-by: David S. Miller --- Documentation/networking/bonding.txt | 42 ++++++++++++++++++++++++++++++------ 1 file changed, 35 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index a97c567..9c723ec 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt @@ -585,13 +585,19 @@ mode balance-tlb or 5 Adaptive transmit load balancing: channel bonding that - does not require any special switch support. The - outgoing traffic is distributed according to the - current load (computed relative to the speed) on each - slave. Incoming traffic is received by the current - slave. If the receiving slave fails, another slave - takes over the MAC address of the failed receiving - slave. + does not require any special switch support. + + In tlb_dynamic_lb=1 mode; the outgoing traffic is + distributed according to the current load (computed + relative to the speed) on each slave. + + In tlb_dynamic_lb=0 mode; the load balancing based on + current load is disabled and the load is distributed + only using the hash distribution. + + Incoming traffic is received by the current slave. + If the receiving slave fails, another slave takes over + the MAC address of the failed receiving slave. Prerequisite: @@ -736,6 +742,28 @@ primary_reselect This option was added for bonding version 3.6.0. +tlb_dynamic_lb + + Specifies if dynamic shuffling of flows is enabled in tlb + mode. The value has no effect on any other modes. + + The default behavior of tlb mode is to shuffle active flows across + slaves based on the load in that interval. This gives nice lb + characteristics but can cause packet reordering. If re-ordering is + a concern use this variable to disable flow shuffling and rely on + load balancing provided solely by the hash distribution. + xmit-hash-policy can be used to select the appropriate hashing for + the setup. + + The sysfs entry can be used to change the setting per bond device + and the initial value is derived from the module parameter. The + sysfs entry is allowed to be changed only if the bond device is + down. + + The default value is "1" that enables flow shuffling while value "0" + disables it. This option was added in bonding driver 3.7.1 + + updelay Specifies the time, in milliseconds, to wait before enabling a -- cgit v1.1 From f99858e0892f8bcb6540122d3b3c349cbacc75ac Mon Sep 17 00:00:00 2001 From: Li Jun Date: Wed, 23 Apr 2014 15:56:53 +0800 Subject: Documentation: ABI: usb: sysfs Description for chipidea USB OTG HNP and SRP This patch adds sysfs interface description for chipidea USB OTG HNP and SRP. Signed-off-by: Peter Chen Signed-off-by: Li Jun Signed-off-by: Greg Kroah-Hartman --- .../ABI/testing/sysfs-platform-chipidea-usb-otg | 56 ++++++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-platform-chipidea-usb-otg (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-platform-chipidea-usb-otg b/Documentation/ABI/testing/sysfs-platform-chipidea-usb-otg new file mode 100644 index 0000000..151c595 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-chipidea-usb-otg @@ -0,0 +1,56 @@ +What: /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_req +Date: Feb 2014 +Contact: Li Jun +Description: + Can be set and read. + Set a_bus_req(A-device bus request) input to be 1 if + the application running on the A-device wants to use the bus, + and to be 0 when the application no longer wants to use + the bus(or wants to work as peripheral). a_bus_req can also + be set to 1 by kernel in response to remote wakeup signaling + from the B-device, the A-device should decide to resume the bus. + + Valid values are "1" and "0". + + Reading: returns 1 if the application running on the A-device + is using the bus as host role, otherwise 0. + +What: /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_drop +Date: Feb 2014 +Contact: Li Jun +Description: + Can be set and read + The a_bus_drop(A-device bus drop) input is 1 when the + application running on the A-device wants to power down + the bus, and is 0 otherwise, When a_bus_drop is 1, then + the a_bus_req shall be 0. + + Valid values are "1" and "0". + + Reading: returns 1 if the bus is off(vbus is turned off) by + A-device, otherwise 0. + +What: /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req +Date: Feb 2014 +Contact: Li Jun +Description: + Can be set and read. + The b_bus_req(B-device bus request) input is 1 during the time + that the application running on the B-device wants to use the + bus as host, and is 0 when the application no longer wants to + work as host and decides to switch back to be peripheral. + + Valid values are "1" and "0". + + Reading: returns if the application running on the B device + is using the bus as host role, otherwise 0. + +What: /sys/bus/platform/devices/ci_hdrc.0/inputs/a_clr_err +Date: Feb 2014 +Contact: Li Jun +Description: + Only can be set. + The a_clr_err(A-device Vbus error clear) input is used to clear + vbus error, then A-device will power down the bus. + + Valid value is "1" -- cgit v1.1 From 9159e049c072bb4f77ac65a7c0fb05953b10fc21 Mon Sep 17 00:00:00 2001 From: Li Jun Date: Wed, 23 Apr 2014 15:56:54 +0800 Subject: Documentation: usb: add chipidea.txt for how to demo usb OTG HNP and SRP This patch adds a file chipidea.txt for how to demo chipidea usb OTG HNP and SRP functions via sysfs input files, any other possible information should be documented for chipidea usb driver in future can be added into this file. Signed-off-by: Peter Chen Signed-off-by: Li Jun Signed-off-by: Greg Kroah-Hartman --- Documentation/usb/chipidea.txt | 71 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 71 insertions(+) create mode 100644 Documentation/usb/chipidea.txt (limited to 'Documentation') diff --git a/Documentation/usb/chipidea.txt b/Documentation/usb/chipidea.txt new file mode 100644 index 0000000..4c0e2ea --- /dev/null +++ b/Documentation/usb/chipidea.txt @@ -0,0 +1,71 @@ +1. How to test OTG FSM(HNP and SRP) +----------------------------------- +To show how to demo OTG HNP and SRP functions via sys input files +with 2 Freescale i.MX6Q sabre SD boards. + +1.1 How to enable OTG FSM in menuconfig +--------------------------------------- +Select CONFIG_USB_OTG_FSM. +If you want to check some internal variables for otg fsm, +select CONFIG_USB_CHIPIDEA_DEBUG, there are 2 files which +can show otg fsm variables and some controller registers value: +cat /sys/kernel/debug/ci_hdrc.0/otg +cat /sys/kernel/debug/ci_hdrc.0/registers + +1.2 Test operations +------------------- +1) Power up 2 Freescale i.MX6Q sabre SD boards with gadget class driver loaded + (e.g. g_mass_storage). + +2) Connect 2 boards with usb cable with one end is micro A plug, the other end + is micro B plug. + + The A-device(with micro A plug inserted) should enumrate B-device. + +3) Role switch + On B-device: + echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req + + if HNP polling is not supported, also need: + On A-device: + echo 0 > /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_req + + B-device should take host role and enumrate A-device. + +4) A-device switch back to host. + On B-device: + echo 0 > /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req + + A-device should switch back to host and enumrate B-device. + +5) Remove B-device(unplug micro B plug) and insert again in 10 seconds, + A-device should enumrate B-device again. + +6) Remove B-device(unplug micro B plug) and insert again after 10 seconds, + A-device should NOT enumrate B-device. + + if A-device wants to use bus: + On A-device: + echo 0 > /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_drop + echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_req + + if B-device wants to use bus: + On B-device: + echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req + +7) A-device power down the bus. + On A-device: + echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_drop + + A-device should disconnect with B-device and power down the bus. + +8) B-device does data pulse for SRP. + On B-device: + echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req + + A-device should resume usb bus and enumrate B-device. + +1.3 Reference document +---------------------- +"On-The-Go and Embedded Host Supplement to the USB Revision 2.0 Specification +July 27, 2012 Revision 2.0 version 1.1a" -- cgit v1.1 From fcbee4d49f30eb0eaa83a62e6a3cab5a892ed93f Mon Sep 17 00:00:00 2001 From: Simon Horman Date: Thu, 24 Apr 2014 15:54:44 +0900 Subject: serial: sh-sci: Add device tree support for r8a7779 According to the platform data for the legacy-C initialisation of sh-sci for the r8a7779 SoC and my own testing the SCIx_SH4_SCIF_REGTYPE bit of scscr needs to be set. Signed-off-by: Simon Horman Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index 53e6c17..bba86de 100644 --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt @@ -12,6 +12,7 @@ Required properties: - "renesas,scifa-r8a7791" for R8A7791 (R-Car M2) SCIFA compatible UART. - "renesas,scifb-r8a7791" for R8A7791 (R-Car M2) SCIFB compatible UART. - "renesas,hscif-r8a7791" for R8A7791 (R-Car M2) HSCIF compatible UART. + - "renesas,scif-r8a7779" for R8A7779 (R-Car H1) SCIF compatible UART. - "renesas,scif" for generic SCIF compatible UART. - "renesas,scifa" for generic SCIFA compatible UART. - "renesas,scifb" for generic SCIFB compatible UART. -- cgit v1.1 From 0d3c673e7881e691991b2a4745bd4f149603baa2 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Fri, 18 Apr 2014 17:19:57 -0500 Subject: tty/serial: pl011: add generic earlycon support Add earlycon support for the pl011 serial port. This allows enabling the pl011 for console when early_params are processed. This is based on the arm64 earlyprintk support and is intended to replace it. Signed-off-by: Rob Herring Cc: Russell King Cc: Jiri Slaby Signed-off-by: Greg Kroah-Hartman --- Documentation/kernel-parameters.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 4384217..2609ead 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -883,6 +883,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. which are not unmapped. earlycon= [KNL] Output early console device and options. + uart[8250],io,[,options] uart[8250],mmio,[,options] uart[8250],mmio32,[,options] @@ -892,6 +893,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted. (mmio) or 32-bit (mmio32). The options are the same as for ttyS, above. + pl011, + Start an early, polled-mode console on a pl011 serial + port at the specified address. The pl011 serial port + must already be setup and configured. Options are not + yet supported. + earlyprintk= [X86,SH,BLACKFIN,ARM] earlyprintk=vga earlyprintk=efi -- cgit v1.1 From d50d7269ebcb438afa346cdffce0f4e2a1b9e831 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Fri, 18 Apr 2014 17:19:58 -0500 Subject: tty/serial: add arm/arm64 semihosting earlycon Add earlycon support for the arm/arm64 semihosting debug serial interface. This allows enabling a debug console when early_params are processed. This is based on the arm64 earlyprintk smh support and is intended to replace it. Signed-off-by: Rob Herring Cc: Jiri Slaby Signed-off-by: Greg Kroah-Hartman --- 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 2609ead..4946d8e 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -899,6 +899,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. must already be setup and configured. Options are not yet supported. + smh Use ARM semihosting calls for early console. + earlyprintk= [X86,SH,BLACKFIN,ARM] earlyprintk=vga earlyprintk=efi -- cgit v1.1 From 2aafb3864b9fa5ce83250537d940f973ef37b8dc Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Thu, 24 Apr 2014 19:26:16 -0700 Subject: Revert "serial: sh-sci: Add device tree support for r8a7779" This reverts commit fcbee4d49f30eb0eaa83a62e6a3cab5a892ed93f. It wasn't quite ready to go in yet, sorry about that. Cc: Simon Horman Cc: Laurent Pinchart Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index bba86de..53e6c17 100644 --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt @@ -12,7 +12,6 @@ Required properties: - "renesas,scifa-r8a7791" for R8A7791 (R-Car M2) SCIFA compatible UART. - "renesas,scifb-r8a7791" for R8A7791 (R-Car M2) SCIFB compatible UART. - "renesas,hscif-r8a7791" for R8A7791 (R-Car M2) HSCIF compatible UART. - - "renesas,scif-r8a7779" for R8A7779 (R-Car H1) SCIF compatible UART. - "renesas,scif" for generic SCIF compatible UART. - "renesas,scifa" for generic SCIFA compatible UART. - "renesas,scifb" for generic SCIFB compatible UART. -- cgit v1.1 From 89054c7b5bb83050fb783efc5a528eebb42c0925 Mon Sep 17 00:00:00 2001 From: Jon Ringle Date: Thu, 24 Apr 2014 20:56:07 -0400 Subject: serial: sc16is7xx: Add bindings documentation for the SC16IS7XX UARTs This patch adds the devicetree documentation for the NXP SC16IS7XX UARTs. Signed-off-by: Jon Ringle Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/serial/nxp,sc16is7xx.txt | 33 ++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt new file mode 100644 index 0000000..246c795 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt @@ -0,0 +1,33 @@ +* NXP SC16IS7xx advanced Universal Asynchronous Receiver-Transmitter (UART) + +Required properties: +- compatible: Should be one of the following: + - "nxp,sc16is740" for NXP SC16IS740, + - "nxp,sc16is741" for NXP SC16IS741, + - "nxp,sc16is750" for NXP SC16IS750, + - "nxp,sc16is752" for NXP SC16IS752, + - "nxp,sc16is760" for NXP SC16IS760, + - "nxp,sc16is762" for NXP SC16IS762. +- reg: I2C address of the SC16IS7xx device. +- interrupt-parent: The phandle for the interrupt controller that + services interrupts for this IC. +- interrupts: Should contain the UART interrupt +- clocks: Reference to the IC source clock. + +Optional properties: +- gpio-controller: Marks the device node as a GPIO controller. +- #gpio-cells: Should be two. The first cell is the GPIO number and + the second cell is used to specify the GPIO polarity: + 0 = active high, + 1 = active low. + +Example: + sc16is750: sc16is750@51 { + compatible = "nxp,sc16is750"; + reg = <0x51>; + clocks = <&clk20m>; + interrupt-parent = <&gpio3>; + interrupts = <7 IRQ_TYPE_EDGE_FALLING>; + gpio-controller; + #gpio-cells = <2>; + }; -- cgit v1.1 From 473153aff4b978006f1c5fbc0e9032fd11061709 Mon Sep 17 00:00:00 2001 From: Ben Hutchings Date: Tue, 22 Apr 2014 17:27:57 +0100 Subject: PCI: Update my email address Signed-off-by: Ben Hutchings Signed-off-by: Bjorn Helgaas --- Documentation/ABI/testing/sysfs-bus-pci | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index a3c5a66..ab8d76d 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci @@ -117,7 +117,7 @@ Description: What: /sys/bus/pci/devices/.../vpd Date: February 2008 -Contact: Ben Hutchings +Contact: Ben Hutchings Description: A file named vpd in a device directory will be a binary file containing the Vital Product Data for the -- cgit v1.1 From 05d8f6593d1d0b4677822136b61d48d7581c5d16 Mon Sep 17 00:00:00 2001 From: Ben Hutchings Date: Fri, 25 Apr 2014 12:25:42 -0600 Subject: PCI: Update my email address Signed-off-by: Ben Hutchings Signed-off-by: Bjorn Helgaas --- Documentation/ABI/testing/sysfs-bus-pci | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index a3c5a66..ab8d76d 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci @@ -117,7 +117,7 @@ Description: What: /sys/bus/pci/devices/.../vpd Date: February 2008 -Contact: Ben Hutchings +Contact: Ben Hutchings Description: A file named vpd in a device directory will be a binary file containing the Vital Product Data for the -- cgit v1.1 From 657315780005a676d294c7edf7548650c7e57f76 Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Fri, 25 Apr 2014 18:28:02 -0400 Subject: cgroup: add documentation about unified hierarchy Unified hierarchy will be the new version of cgroup interface. This patch adds Documentation/cgroups/unified-hierarchy.txt which describes the design and rationales of unified hierarchy. v2: Grammatical updates as per Randy Dunlap's review. Signed-off-by: Tejun Heo Cc: Randy Dunlap --- Documentation/cgroups/unified-hierarchy.txt | 359 ++++++++++++++++++++++++++++ 1 file changed, 359 insertions(+) create mode 100644 Documentation/cgroups/unified-hierarchy.txt (limited to 'Documentation') diff --git a/Documentation/cgroups/unified-hierarchy.txt b/Documentation/cgroups/unified-hierarchy.txt new file mode 100644 index 0000000..324b182 --- /dev/null +++ b/Documentation/cgroups/unified-hierarchy.txt @@ -0,0 +1,359 @@ + +Cgroup unified hierarchy + +April, 2014 Tejun Heo + +This document describes the changes made by unified hierarchy and +their rationales. It will eventually be merged into the main cgroup +documentation. + +CONTENTS + +1. Background +2. Basic Operation + 2-1. Mounting + 2-2. cgroup.subtree_control + 2-3. cgroup.controllers +3. Structural Constraints + 3-1. Top-down + 3-2. No internal tasks +4. Other Changes + 4-1. [Un]populated Notification + 4-2. Other Core Changes + 4-3. Per-Controller Changes + 4-3-1. blkio + 4-3-2. cpuset + 4-3-3. memory +5. Planned Changes + 5-1. CAP for resource control + + +1. Background + +cgroup allows an arbitrary number of hierarchies and each hierarchy +can host any number of controllers. While this seems to provide a +high level of flexibility, it isn't quite useful in practice. + +For example, as there is only one instance of each controller, utility +type controllers such as freezer which can be useful in all +hierarchies can only be used in one. The issue is exacerbated by the +fact that controllers can't be moved around once hierarchies are +populated. Another issue is that all controllers bound to a hierarchy +are forced to have exactly the same view of the hierarchy. It isn't +possible to vary the granularity depending on the specific controller. + +In practice, these issues heavily limit which controllers can be put +on the same hierarchy and most configurations resort to putting each +controller on its own hierarchy. Only closely related ones, such as +the cpu and cpuacct controllers, make sense to put on the same +hierarchy. This often means that userland ends up managing multiple +similar hierarchies repeating the same steps on each hierarchy +whenever a hierarchy management operation is necessary. + +Unfortunately, support for multiple hierarchies comes at a steep cost. +Internal implementation in cgroup core proper is dazzlingly +complicated but more importantly the support for multiple hierarchies +restricts how cgroup is used in general and what controllers can do. + +There's no limit on how many hierarchies there may be, which means +that a task's cgroup membership can't be described in finite length. +The key may contain any varying number of entries and is unlimited in +length, which makes it highly awkward to handle and leads to addition +of controllers which exist only to identify membership, which in turn +exacerbates the original problem. + +Also, as a controller can't have any expectation regarding what shape +of hierarchies other controllers would be on, each controller has to +assume that all other controllers are operating on completely +orthogonal hierarchies. This makes it impossible, or at least very +cumbersome, for controllers to cooperate with each other. + +In most use cases, putting controllers on hierarchies which are +completely orthogonal to each other isn't necessary. What usually is +called for is the ability to have differing levels of granularity +depending on the specific controller. In other words, hierarchy may +be collapsed from leaf towards root when viewed from specific +controllers. For example, a given configuration might not care about +how memory is distributed beyond a certain level while still wanting +to control how CPU cycles are distributed. + +Unified hierarchy is the next version of cgroup interface. It aims to +address the aforementioned issues by having more structure while +retaining enough flexibility for most use cases. Various other +general and controller-specific interface issues are also addressed in +the process. + + +2. Basic Operation + +2-1. Mounting + +Currently, unified hierarchy can be mounted with the following mount +command. Note that this is still under development and scheduled to +change soon. + + mount -t cgroup -o __DEVEL__sane_behavior cgroup $MOUNT_POINT + +All controllers which are not bound to other hierarchies are +automatically bound to unified hierarchy and show up at the root of +it. Controllers which are enabled only in the root of unified +hierarchy can be bound to other hierarchies at any time. This allows +mixing unified hierarchy with the traditional multiple hierarchies in +a fully backward compatible way. + + +2-2. cgroup.subtree_control + +All cgroups on unified hierarchy have a "cgroup.subtree_control" file +which governs which controllers are enabled on the children of the +cgroup. Let's assume a hierarchy like the following. + + root - A - B - C + \ D + +root's "cgroup.subtree_control" file determines which controllers are +enabled on A. A's on B. B's on C and D. This coincides with the +fact that controllers on the immediate sub-level are used to +distribute the resources of the parent. In fact, it's natural to +assume that resource control knobs of a child belong to its parent. +Enabling a controller in a "cgroup.subtree_control" file declares that +distribution of the respective resources of the cgroup will be +controlled. Note that this means that controller enable states are +shared among siblings. + +When read, the file contains a space-separated list of currently +enabled controllers. A write to the file should contain a +space-separated list of controllers with '+' or '-' prefixed (without +the quotes). Controllers prefixed with '+' are enabled and '-' +disabled. If a controller is listed multiple times, the last entry +wins. The specific operations are executed atomically - either all +succeed or fail. + + +2-3. cgroup.controllers + +Read-only "cgroup.controllers" file contains a space-separated list of +controllers which can be enabled in the cgroup's +"cgroup.subtree_control" file. + +In the root cgroup, this lists controllers which are not bound to +other hierarchies and the content changes as controllers are bound to +and unbound from other hierarchies. + +In non-root cgroups, the content of this file equals that of the +parent's "cgroup.subtree_control" file as only controllers enabled +from the parent can be used in its children. + + +3. Structural Constraints + +3-1. Top-down + +As it doesn't make sense to nest control of an uncontrolled resource, +all non-root "cgroup.subtree_control" files can only contain +controllers which are enabled in the parent's "cgroup.subtree_control" +file. A controller can be enabled only if the parent has the +controller enabled and a controller can't be disabled if one or more +children have it enabled. + + +3-2. No internal tasks + +One long-standing issue that cgroup faces is the competition between +tasks belonging to the parent cgroup and its children cgroups. This +is inherently nasty as two different types of entities compete and +there is no agreed-upon obvious way to handle it. Different +controllers are doing different things. + +The cpu controller considers tasks and cgroups as equivalents and maps +nice levels to cgroup weights. This works for some cases but falls +flat when children should be allocated specific ratios of CPU cycles +and the number of internal tasks fluctuates - the ratios constantly +change as the number of competing entities fluctuates. There also are +other issues. The mapping from nice level to weight isn't obvious or +universal, and there are various other knobs which simply aren't +available for tasks. + +The blkio controller implicitly creates a hidden leaf node for each +cgroup to host the tasks. The hidden leaf has its own copies of all +the knobs with "leaf_" prefixed. While this allows equivalent control +over internal tasks, it's with serious drawbacks. It always adds an +extra layer of nesting which may not be necessary, makes the interface +messy and significantly complicates the implementation. + +The memory controller currently doesn't have a way to control what +happens between internal tasks and child cgroups and the behavior is +not clearly defined. There have been attempts to add ad-hoc behaviors +and knobs to tailor the behavior to specific workloads. Continuing +this direction will lead to problems which will be extremely difficult +to resolve in the long term. + +Multiple controllers struggle with internal tasks and came up with +different ways to deal with it; unfortunately, all the approaches in +use now are severely flawed and, furthermore, the widely different +behaviors make cgroup as whole highly inconsistent. + +It is clear that this is something which needs to be addressed from +cgroup core proper in a uniform way so that controllers don't need to +worry about it and cgroup as a whole shows a consistent and logical +behavior. To achieve that, unified hierarchy enforces the following +structural constraint: + + Except for the root, only cgroups which don't contain any task may + have controllers enabled in their "cgroup.subtree_control" files. + +Combined with other properties, this guarantees that, when a +controller is looking at the part of the hierarchy which has it +enabled, tasks are always only on the leaves. This rules out +situations where child cgroups compete against internal tasks of the +parent. + +There are two things to note. Firstly, the root cgroup is exempt from +the restriction. Root contains tasks and anonymous resource +consumption which can't be associated with any other cgroup and +requires special treatment from most controllers. How resource +consumption in the root cgroup is governed is up to each controller. + +Secondly, the restriction doesn't take effect if there is no enabled +controller in the cgroup's "cgroup.subtree_control" file. This is +important as otherwise it wouldn't be possible to create children of a +populated cgroup. To control resource distribution of a cgroup, the +cgroup must create children and transfer all its tasks to the children +before enabling controllers in its "cgroup.subtree_control" file. + + +4. Other Changes + +4-1. [Un]populated Notification + +cgroup users often need a way to determine when a cgroup's +subhierarchy becomes empty so that it can be cleaned up. cgroup +currently provides release_agent for it; unfortunately, this mechanism +is riddled with issues. + +- It delivers events by forking and execing a userland binary + specified as the release_agent. This is a long deprecated method of + notification delivery. It's extremely heavy, slow and cumbersome to + integrate with larger infrastructure. + +- There is single monitoring point at the root. There's no way to + delegate management of a subtree. + +- The event isn't recursive. It triggers when a cgroup doesn't have + any tasks or child cgroups. Events for internal nodes trigger only + after all children are removed. This again makes it impossible to + delegate management of a subtree. + +- Events are filtered from the kernel side. A "notify_on_release" + file is used to subscribe to or suppress release events. This is + unnecessarily complicated and probably done this way because event + delivery itself was expensive. + +Unified hierarchy implements an interface file "cgroup.populated" +which can be used to monitor whether the cgroup's subhierarchy has +tasks in it or not. Its value is 0 if there is no task in the cgroup +and its descendants; otherwise, 1. poll and [id]notify events are +triggered when the value changes. + +This is significantly lighter and simpler and trivially allows +delegating management of subhierarchy - subhierarchy monitoring can +block further propagation simply by putting itself or another process +in the subhierarchy and monitor events that it's interested in from +there without interfering with monitoring higher in the tree. + +In unified hierarchy, the release_agent mechanism is no longer +supported and the interface files "release_agent" and +"notify_on_release" do not exist. + + +4-2. Other Core Changes + +- None of the mount options is allowed. + +- remount is disallowed. + +- rename(2) is disallowed. + +- The "tasks" file is removed. Everything should at process + granularity. Use the "cgroup.procs" file instead. + +- The "cgroup.procs" file is not sorted. pids will be unique unless + they got recycled in-between reads. + +- The "cgroup.clone_children" file is removed. + + +4-3. Per-Controller Changes + +4-3-1. blkio + +- blk-throttle becomes properly hierarchical. + + +4-3-2. cpuset + +- Tasks are kept in empty cpusets after hotplug and take on the masks + of the nearest non-empty ancestor, instead of being moved to it. + +- A task can be moved into an empty cpuset, and again it takes on the + masks of the nearest non-empty ancestor. + + +4-3-3. memory + +- use_hierarchy is on by default and the cgroup file for the flag is + not created. + + +5. Planned Changes + +5-1. CAP for resource control + +Unified hierarchy will require one of the capabilities(7), which is +yet to be decided, for all resource control related knobs. Process +organization operations - creation of sub-cgroups and migration of +processes in sub-hierarchies may be delegated by changing the +ownership and/or permissions on the cgroup directory and +"cgroup.procs" interface file; however, all operations which affect +resource control - writes to a "cgroup.subtree_control" file or any +controller-specific knobs - will require an explicit CAP privilege. + +This, in part, is to prevent the cgroup interface from being +inadvertently promoted to programmable API used by non-privileged +binaries. cgroup exposes various aspects of the system in ways which +aren't properly abstracted for direct consumption by regular programs. +This is an administration interface much closer to sysctl knobs than +system calls. Even the basic access model, being filesystem path +based, isn't suitable for direct consumption. There's no way to +access "my cgroup" in a race-free way or make multiple operations +atomic against migration to another cgroup. + +Another aspect is that, for better or for worse, the cgroup interface +goes through far less scrutiny than regular interfaces for +unprivileged userland. The upside is that cgroup is able to expose +useful features which may not be suitable for general consumption in a +reasonable time frame. It provides a relatively short path between +internal details and userland-visible interface. Of course, this +shortcut comes with high risk. We go through what we go through for +general kernel APIs for good reasons. It may end up leaking internal +details in a way which can exert significant pain by locking the +kernel into a contract that can't be maintained in a reasonable +manner. + +Also, due to the specific nature, cgroup and its controllers don't +tend to attract attention from a wide scope of developers. cgroup's +short history is already fraught with severely mis-designed +interfaces, unnecessary commitments to and exposing of internal +details, broken and dangerous implementations of various features. + +Keeping cgroup as an administration interface is both advantageous for +its role and imperative given its nature. Some of the cgroup features +may make sense for unprivileged access. If deemed justified, those +must be further abstracted and implemented as a different interface, +be it a system call or process-private filesystem, and survive through +the scrutiny that any interface for general consumption is required to +go through. + +Requiring CAP is not a complete solution but should serve as a +significant deterrent against spraying cgroup usages in non-privileged +programs. -- cgit v1.1 From 9e74d2926a283dac17d3ab22ca982aab3a4a05d8 Mon Sep 17 00:00:00 2001 From: Emil Renner Berthing Date: Sat, 29 Mar 2014 13:57:44 +0100 Subject: staging: imx-drm: add LVDS666 support for parallel display Support the LVDS666 format on the IPUv3 parallel display. This makes the screen work on my Hercules eCAFE Slim HD. Signed-off-by: Emil Renner Berthing Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt index 3be5ce7..e75f0e5 100644 --- a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt +++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt @@ -61,6 +61,7 @@ Required properties: Optional properties: - interface_pix_fmt: How this display is connected to the display interface. Currently supported types: "rgb24", "rgb565", "bgr666" + and "lvds666". - edid: verbatim EDID data block describing attached display. - ddc: phandle describing the i2c bus handling the display data channel -- cgit v1.1 From 66ecbfea762ad28bd108db76775483b491068b92 Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Tue, 22 Apr 2014 23:26:08 +0200 Subject: clk: mvebu: add Orion5x clock driver This commit adds a core clock driver for the Orion5x SoC, with support for the tclk, the CPU frequency and the DDR frequency. All the details about the Sample-At-Reset register were extracted from the U-Boot sources for Orion5x. Note that Orion5x does not have gatable clocks, so this core clock driver is sufficient to support clocking on Orion5x platforms. Signed-off-by: Thomas Petazzoni Acked-by: Sebastian Hesselbarth Link: https://lkml.kernel.org/r/1398202002-28530-5-git-send-email-thomas.petazzoni@free-electrons.com Cc: Mike Turquette Signed-off-by: Jason Cooper --- Documentation/devicetree/bindings/clock/mvebu-core-clock.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt index 307a503..dc5ea5b 100644 --- a/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt +++ b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt @@ -29,6 +29,11 @@ The following is a list of provided IDs and clock names on Kirkwood and Dove: 2 = l2clk (L2 Cache clock derived from CPU0 clock) 3 = ddrclk (DDR controller clock derived from CPU0 clock) +The following is a list of provided IDs and clock names on Orion5x: + 0 = tclk (Internal Bus clock) + 1 = cpuclk (CPU0 clock) + 2 = ddrclk (DDR controller clock derived from CPU0 clock) + Required properties: - compatible : shall be one of the following: "marvell,armada-370-core-clock" - For Armada 370 SoC core clocks @@ -38,6 +43,9 @@ Required properties: "marvell,dove-core-clock" - for Dove SoC core clocks "marvell,kirkwood-core-clock" - for Kirkwood SoC (except mv88f6180) "marvell,mv88f6180-core-clock" - for Kirkwood MV88f6180 SoC + "marvell,mv88f5182-core-clock" - for Orion MV88F5182 SoC + "marvell,mv88f5281-core-clock" - for Orion MV88F5281 SoC + "marvell,mv88f6183-core-clock" - for Orion MV88F6183 SoC - reg : shall be the register address of the Sample-At-Reset (SAR) register - #clock-cells : from common clock binding; shall be set to 1 -- cgit v1.1 From 0dbfc8fd32f3dbe3069969fd6120ce3c61964c40 Mon Sep 17 00:00:00 2001 From: Alexander Aring Date: Thu, 24 Apr 2014 19:09:06 +0200 Subject: devicetree: add at86rf230 bindings This patch adds devicetree bindings for the at86rf230 IEEE 802.15.4 SPI device driver. Signed-off-by: Alexander Aring Signed-off-by: David S. Miller --- .../bindings/net/ieee802154/at86rf230.txt | 23 ++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/ieee802154/at86rf230.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/ieee802154/at86rf230.txt b/Documentation/devicetree/bindings/net/ieee802154/at86rf230.txt new file mode 100644 index 0000000..d3bbdded --- /dev/null +++ b/Documentation/devicetree/bindings/net/ieee802154/at86rf230.txt @@ -0,0 +1,23 @@ +* AT86RF230 IEEE 802.15.4 * + +Required properties: + - compatible: should be "atmel,at86rf230", "atmel,at86rf231", + "atmel,at86rf233" or "atmel,at86rf212" + - spi-max-frequency: maximal bus speed, should be set to 7500000 depends + sync or async operation mode + - reg: the chipselect index + - interrupts: the interrupt generated by the device + +Optional properties: + - reset-gpio: GPIO spec for the rstn pin + - sleep-gpio: GPIO spec for the slp_tr pin + +Example: + + at86rf231@0 { + compatible = "atmel,at86rf231"; + spi-max-frequency = <7500000>; + reg = <0>; + interrupts = <19 1>; + interrupt-parent = <&gpio3>; + }; -- cgit v1.1 From fcecaeb026f9b35e679c12aed8a92bee3a673da0 Mon Sep 17 00:00:00 2001 From: Florian Fainelli Date: Thu, 24 Apr 2014 18:08:58 -0700 Subject: Documentation: add Broadcom SYSTEMPORT Device Tree bindings Add the Device Tree bindings documentation for the Broadcom SYSTEMPORT Ethernet MAC controller hardware. Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller --- .../bindings/net/broadcom-systemport.txt | 29 ++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/broadcom-systemport.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/broadcom-systemport.txt b/Documentation/devicetree/bindings/net/broadcom-systemport.txt new file mode 100644 index 0000000..1b7600e --- /dev/null +++ b/Documentation/devicetree/bindings/net/broadcom-systemport.txt @@ -0,0 +1,29 @@ +* Broadcom BCM7xxx Ethernet Systemport Controller (SYSTEMPORT) + +Required properties: +- compatible: should be one of "brcm,systemport-v1.00" or "brcm,systemport" +- reg: address and length of the register set for the device. +- interrupts: interrupts for the device, first cell must be for the the rx + interrupts, and the second cell should be for the transmit queues +- local-mac-address: Ethernet MAC address (48 bits) of this adapter +- phy-mode: Should be a string describing the PHY interface to the + Ethernet switch/PHY, see Documentation/devicetree/bindings/net/ethernet.txt +- fixed-link: see Documentation/devicetree/bindings/net/fsl-tsec-phy.txt for + the property specific details + +Optional properties: +- systemport,num-tier2-arb: number of tier 2 arbiters, an integer +- systemport,num-tier1-arb: number of tier 1 arbiters, an integer +- systemport,num-txq: number of HW transmit queues, an integer +- systemport,num-rxq: number of HW receive queues, an integer + +Example: +ethernet@f04a0000 { + compatible = "brcm,systemport-v1.00"; + reg = <0xf04a0000 0x4650>; + local-mac-address = [ 00 11 22 33 44 55 ]; + fixed-link = <0 1 1000 0 0>; + phy-mode = "gmii"; + interrupts = <0x0 0x16 0x0>, + <0x0 0x17 0x0>; +}; -- cgit v1.1 From 3e5314d3c8364b3e3611256caa005bb34e05372e Mon Sep 17 00:00:00 2001 From: Thierry Reding Date: Mon, 7 Apr 2014 15:45:30 +0200 Subject: pwm: Document signal polarity convention The PWM subsystem defines normal and inversed PWM signal polarity in an unambiguous way. In addition to the documentation in the linux/pwm.h header file, add a paragraph in Documentation/pwm.txt because people are likely to look there for guidance. Signed-off-by: Thierry Reding --- Documentation/pwm.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt index 93cb979..0527f61 100644 --- a/Documentation/pwm.txt +++ b/Documentation/pwm.txt @@ -97,6 +97,13 @@ pwm_chip as argument which provides a description of the PWM chip, the number of PWM devices provided by the chip and the chip-specific implementation of the supported PWM operations to the framework. +When implementing polarity support in a PWM driver, make sure to respect the +signal conventions in the PWM framework. By definition, normal polarity +characterizes a signal starts high for the duration of the duty cycle and +goes low for the remainder of the period. Conversely, a signal with inversed +polarity starts low for the duration of the duty cycle and goes high for the +remainder of the period. + Locking ------- -- cgit v1.1 From 810b4f51e8d0c2de9685f4addbf5ede7e589dd20 Mon Sep 17 00:00:00 2001 From: Tim Kryger Date: Fri, 25 Apr 2014 11:31:11 -0700 Subject: Documentation: dt: Add Kona PWM binding Add the binding description for the Kona PWM controller found on Broadcom's mobile SoCs. Signed-off-by: Tim Kryger Reviewed-by: Alex Elder Reviewed-by: Markus Mayer Signed-off-by: Thierry Reding --- .../devicetree/bindings/pwm/bcm-kona-pwm.txt | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt b/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt new file mode 100644 index 0000000..8eae9fe --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt @@ -0,0 +1,21 @@ +Broadcom Kona PWM controller device tree bindings + +This controller has 6 channels. + +Required Properties : +- compatible: should contain "brcm,kona-pwm" +- reg: physical base address and length of the controller's registers +- clocks: phandle + clock specifier pair for the external clock +- #pwm-cells: Should be 3. See pwm.txt in this directory for a + description of the cells format. + +Refer to clocks/clock-bindings.txt for generic clock consumer properties. + +Example: + +pwm: pwm@3e01a000 { + compatible = "brcm,bcm11351-pwm", "brcm,kona-pwm"; + reg = <0x3e01a000 0xc4>; + clocks = <&pwm_clk>; + #pwm-cells = <3>; +}; -- cgit v1.1 From 90887db8837bb2ea57c3541d56a002e9654082b3 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Wed, 9 Apr 2014 14:36:32 +0200 Subject: gpio: document gpio irqchips a bit more, describe helpers This adds some documentation about the GPIO irqchips, what types exist etc. Acked-by: Alexandre Courbot Signed-off-by: Linus Walleij --- Documentation/gpio/driver.txt | 59 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 59 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpio/driver.txt b/Documentation/gpio/driver.txt index f73cc7b..fa9a0a8 100644 --- a/Documentation/gpio/driver.txt +++ b/Documentation/gpio/driver.txt @@ -73,6 +73,65 @@ The IRQ portions of the GPIO block are implemented using an irqchip, using the header . So basically such a driver is utilizing two sub- systems simultaneously: gpio and irq. +GPIO irqchips usually fall in one of two categories: + +* CHAINED GPIO irqchips: these are usually the type that is embedded on + an SoC. This means that there is a fast IRQ handler for the GPIOs that + gets called in a chain from the parent IRQ handler, most typically the + system interrupt controller. This means the GPIO irqchip is registered + using irq_set_chained_handler() or the corresponding + gpiochip_set_chained_irqchip() helper function, and the GPIO irqchip + handler will be called immediately from the parent irqchip, while + holding the IRQs disabled. The GPIO irqchip will then end up calling + something like this sequence in its interrupt handler: + + static irqreturn_t tc3589x_gpio_irq(int irq, void *data) + chained_irq_enter(...); + generic_handle_irq(...); + chained_irq_exit(...); + + Chained GPIO irqchips typically can NOT set the .can_sleep flag on + struct gpio_chip, as everything happens directly in the callbacks. + +* NESTED THREADED GPIO irqchips: these are off-chip GPIO expanders and any + other GPIO irqchip residing on the other side of a sleeping bus. Of course + such drivers that need slow bus traffic to read out IRQ status and similar, + traffic which may in turn incur other IRQs to happen, cannot be handled + in a quick IRQ handler with IRQs disabled. Instead they need to spawn a + thread and then mask the parent IRQ line until the interrupt is handled + by the driver. The hallmark of this driver is to call something like + this in its interrupt handler: + + static irqreturn_t tc3589x_gpio_irq(int irq, void *data) + ... + handle_nested_irq(irq); + + The hallmark of threaded GPIO irqchips is that they set the .can_sleep + flag on struct gpio_chip to true, indicating that this chip may sleep + when accessing the GPIOs. + +To help out in handling the set-up and management of GPIO irqchips and the +associated irqdomain and resource allocation callbacks, the gpiolib has +some helpers that can be enabled by selecting the GPIOLIB_IRQCHIP Kconfig +symbol: + +* gpiochip_irqchip_add(): adds an irqchip to a gpiochip. It will pass + the struct gpio_chip* for the chip to all IRQ callbacks, so the callbacks + need to embed the gpio_chip in its state container and obtain a pointer + to the container using container_of(). + (See Documentation/driver-model/design-patterns.txt) + +* gpiochip_set_chained_irqchip(): sets up a chained irq handler for a + gpio_chip from a parent IRQ and passes the struct gpio_chip* as handler + data. (Notice handler data, since the irqchip data is likely used by the + parent irqchip!) This is for the chained type of chip. + +To use the helpers please keep the following in mind: + +- Make sure to assign all relevant members of the struct gpio_chip so that + the irqchip can initialize. E.g. .dev and .can_sleep shall be set up + properly. + It is legal for any IRQ consumer to request an IRQ from any irqchip no matter if that is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and irq_chip are orthogonal, and offering their services independent of each -- cgit v1.1 From 370a4516e401af82dcd89c34a99346c5869a879c Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Mon, 14 Apr 2014 20:33:12 +0200 Subject: gpio: rcar: Add optional functional clock to bindings Signed-off-by: Geert Uytterhoeven Cc: linux-gpio@vger.kernel.org Cc: devicetree@vger.kernel.org Acked-by: Laurent Pinchart Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt index f61cef7..941a26a 100644 --- a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt +++ b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt @@ -21,6 +21,12 @@ Required Properties: GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported. - gpio-ranges: Range of pins managed by the GPIO controller. +Optional properties: + + - clocks: Must contain a reference to the functional clock. The property is + mandatory if the hardware implements a controllable functional clock for + the GPIO instance. + Please refer to gpio.txt in this directory for details of gpio-ranges property and the common GPIO bindings used by client devices. -- cgit v1.1 From c4ec7430c30a4012a04aa5535919845f543f075d Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Tue, 22 Apr 2014 23:26:12 +0200 Subject: memory: mvebu-devbus: add Orion5x support This commit adds support for the Orion5x family of Marvell processors into the mvebu-devbus driver. It differs from the already supported Armada 370/XP by: * Having a single register (instead of two) for doing all the timing configuration. * Having a few less timing configuration parameters. For this reason, a separate compatible string "marvell,orion-devbus" is introduced. Signed-off-by: Thomas Petazzoni Acked-by: Sebastian Hesselbarth Tested-by: Ezequiel Garcia Link: https://lkml.kernel.org/r/1398202002-28530-9-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper --- .../bindings/memory-controllers/mvebu-devbus.txt | 25 +++++++++++++++++----- 1 file changed, 20 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt index 653c90c..55adde2 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt +++ b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt @@ -6,10 +6,11 @@ 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: + - compatible: Armada 370/XP SoC are supported using the + "marvell,mvebu-devbus" compatible string. - marvell,mvebu-devbus + Orion5x SoC are supported using the + "marvell,orion-devbus" compatible string. - reg: A resource specifier for the register space. This is the base address of a chip select within @@ -22,7 +23,7 @@ Required properties: integer values for each chip-select line in use: 0 -Mandatory timing properties for child nodes: +Timing properties for child nodes: Read parameters: @@ -30,21 +31,26 @@ Read parameters: 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. + Mandatory. - - devbus,bus-width: Defines the bus width (e.g. <16>) + - devbus,bus-width: Defines the bus width, in bits (e.g. <16>). + Mandatory. - 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. + Mandatory. - 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. + Mandatory. - 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). + Mandatory. - devbus,rd-setup-ps: Defines the time delay between DEV_CSn assertion to DEV_OEn assertion. If set to 0 (default), @@ -52,6 +58,8 @@ Read parameters: This parameter has no affect on parameter (no affect on first data sample). Set to a value smaller than . + Mandatory for "marvell,mvebu-devbus" + compatible string, ignored otherwise. - devbus,rd-hold-ps: Defines the time between the last data sample to the de-assertion of DEV_CSn. If set to 0 (default), @@ -62,16 +70,20 @@ Read parameters: last data sampled. Also this parameter has no affect on parameter. Set to a value smaller than . + Mandatory for "marvell,mvebu-devbus" + compatible string, ignored otherwise. Write parameters: - devbus,ale-wr-ps: Defines the time delay from the ALE[0] negation cycle to the DEV_WEn assertion. + Mandatory. - 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. + Mandatory. - devbus,wr-high-ps: Defines the time during which DEV_WEn is kept inactive (high) between data beats of a burst write. @@ -79,10 +91,13 @@ Write parameters: - ps. This parameter defines the hold time of address and data after DEV_WEn rise. + Mandatory. - devbus,sync-enable: Synchronous device enable. 1: True 0: False + Mandatory for "marvell,mvebu-devbus" compatible + string, ignored otherwise. 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 -- cgit v1.1 From 0456d3300edba52e47c6b5582cfe9d87756f5590 Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Tue, 22 Apr 2014 23:26:13 +0200 Subject: memory: mvebu-devbus: add a devbus, keep-config property Currently, the mvebu-devbus Device Tree binding makes defining the timing parameters mandatory. However, in practice, when converting Orion5x platforms to the Device Tree, we may not necessarily have easy access to the hardware platforms to fetch those values which were not defined in old-style board files: all these platforms rely on the bootloader setting the timing parameters correctly. In order to facilitate the migration to the Device Tree of this platform, this commit relaxes the mvebu-devbus Device Tree binding by introducing a 'devbus,keep-config' boolean property, which, if defined, will ignore all timing parameters passed in the Device Tree, and simply rely on the timing values already defined by the bootloader. Signed-off-by: Thomas Petazzoni Acked-by: Sebastian Hesselbarth Tested-by: Ezequiel Garcia Link: https://lkml.kernel.org/r/1398202002-28530-10-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper --- .../bindings/memory-controllers/mvebu-devbus.txt | 29 ++++++++++++++-------- 1 file changed, 18 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt index 55adde2..1ee3bc0 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt +++ b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt @@ -23,6 +23,13 @@ Required properties: integer values for each chip-select line in use: 0 +Optional properties: + + - devbus,keep-config This property can optionally be used to keep + using the timing parameters set by the + bootloader. It makes all the timing properties + described below unused. + Timing properties for child nodes: Read parameters: @@ -31,26 +38,26 @@ Read parameters: 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. - Mandatory. + Mandatory, except if devbus,keep-config is used. - devbus,bus-width: Defines the bus width, in bits (e.g. <16>). - Mandatory. + Mandatory, except if devbus,keep-config is used. - 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. - Mandatory. + Mandatory, except if devbus,keep-config is used. - 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. - Mandatory. + Mandatory, except if devbus,keep-config is used. - 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). - Mandatory. + Mandatory, except if devbus,keep-config is used. - devbus,rd-setup-ps: Defines the time delay between DEV_CSn assertion to DEV_OEn assertion. If set to 0 (default), @@ -58,8 +65,8 @@ Read parameters: This parameter has no affect on parameter (no affect on first data sample). Set to a value smaller than . - Mandatory for "marvell,mvebu-devbus" - compatible string, ignored otherwise. + Mandatory for "marvell,mvebu-devbus" compatible string, + except if devbus,keep-config is used. - devbus,rd-hold-ps: Defines the time between the last data sample to the de-assertion of DEV_CSn. If set to 0 (default), @@ -70,8 +77,8 @@ Read parameters: last data sampled. Also this parameter has no affect on parameter. Set to a value smaller than . - Mandatory for "marvell,mvebu-devbus" - compatible string, ignored otherwise. + Mandatory for "marvell,mvebu-devbus" compatible string, + except if devbus,keep-config is used. Write parameters: @@ -96,8 +103,8 @@ Write parameters: - devbus,sync-enable: Synchronous device enable. 1: True 0: False - Mandatory for "marvell,mvebu-devbus" compatible - string, ignored otherwise. + Mandatory for "marvell,mvebu-devbus" compatible string, + except if devbus,keep-config is used. 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 -- cgit v1.1 From cf7eb979116c2568e8bc3b6a7269c7a359864ace Mon Sep 17 00:00:00 2001 From: Thomas Gleixner Date: Sun, 13 Apr 2014 20:44:46 +0200 Subject: ARM: common: edma: Fix xbar mapping This is another great example of trainwreck engineering: commit 2646a0e529 (ARM: edma: Add EDMA crossbar event mux support) added support for using EDMA on peripherals which have no direct EDMA event mapping. The code compiles and does not explode in your face, but that's it. 1) Reading an u16 array from an u32 device tree array simply does not work. Even if the function is named "edma_of_read_u32_to_s16_array". It merily calls of_property_read_u16_array. So the resulting 16bit array will have every other entry = 0. 2) The DT entry for the xbar registers related to xbar has length 0x10 instead of the real length: 0xfd0 - 0xf90 = 0x40. Not a real problem as it does not cross a page boundary, but wrong nevertheless. 3) But none of this matters as the mapping never happens: After reading nonsense edma_of_read_u32_to_s16_array() invalidates the first array entry pair, so nobody can ever notice the braindamage by immediate explosion. Seems the QA criteria for this code was solely not to explode when someone adds edma-xbar-event-map entries to the DT. Goal achieved, congratulations! Not really helpful if someone wants to use edma on a device which requires a xbar mapping. Fix the issues by: - annotating the device tree entry with "/bits/ 16" as documented in the of_property_read_u16_array kernel doc - make the size of the xbar register mapping correct - invalidating the end of the array and not the start This convoluted mess wants to be completely rewritten as there is no point to keep the xbar_chan array memory and the iomapping of the xbar regs around forever. Marking the xbar mapped channels as used should be done right there. But that's a different issue and this patch is small enough to make it work and allows a simple backport for stable. Cc: stable@vger.kernel.org # v3.12+ Signed-off-by: Thomas Gleixner Signed-off-by: Sekhar Nori --- Documentation/devicetree/bindings/dma/ti-edma.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt index 9fbbdb7..68ff213 100644 --- a/Documentation/devicetree/bindings/dma/ti-edma.txt +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt @@ -29,6 +29,6 @@ edma: edma@49000000 { dma-channels = <64>; ti,edma-regions = <4>; ti,edma-slots = <256>; - ti,edma-xbar-event-map = <1 12 - 2 13>; + ti,edma-xbar-event-map = /bits/ 16 <1 12 + 2 13>; }; -- cgit v1.1 From 96224daa16d6589aff87339cf0f630ef13600a59 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Tue, 25 Feb 2014 09:47:34 -0800 Subject: documentation: Update sysfs path for rcu_cpu_stall_suppress Commit 6bfc09e2327d (rcu: Provide RCU CPU stall warnings for tiny RCU) moved the rcu_cpu_stall_suppress module parameter from rcutree.c to rcupdate.c, but failed to update Documentation/RCU/stallwarn.txt. This commit therefore repairs this omission. Reported-by: Kirill Tkhai Signed-off-by: Paul E. McKenney Reviewed-by: Josh Triplett --- Documentation/RCU/stallwarn.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt index 6f3a005..68fe3ad 100644 --- a/Documentation/RCU/stallwarn.txt +++ b/Documentation/RCU/stallwarn.txt @@ -24,7 +24,7 @@ CONFIG_RCU_CPU_STALL_TIMEOUT timing of the next warning for the current stall. Stall-warning messages may be enabled and disabled completely via - /sys/module/rcutree/parameters/rcu_cpu_stall_suppress. + /sys/module/rcupdate/parameters/rcu_cpu_stall_suppress. CONFIG_RCU_CPU_STALL_VERBOSE -- cgit v1.1 From b4c5bf353452c49edd860a67845627c9a8f32638 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Fri, 28 Feb 2014 16:11:28 -0800 Subject: documentation: Record rcu_dereference() value mishandling Recent LKML discussings (see http://lwn.net/Articles/586838/ and http://lwn.net/Articles/588300/ for the LWN writeups) brought out some ways of misusing the return value from rcu_dereference() that are not necessarily completely intuitive. This commit therefore documents what can and cannot safely be done with these values. Signed-off-by: Paul E. McKenney Reviewed-by: Josh Triplett --- Documentation/RCU/00-INDEX | 2 + Documentation/RCU/checklist.txt | 12 +- Documentation/RCU/rcu_dereference.txt | 371 ++++++++++++++++++++++++++++++++++ 3 files changed, 381 insertions(+), 4 deletions(-) create mode 100644 Documentation/RCU/rcu_dereference.txt (limited to 'Documentation') diff --git a/Documentation/RCU/00-INDEX b/Documentation/RCU/00-INDEX index fa57139..f773a26 100644 --- a/Documentation/RCU/00-INDEX +++ b/Documentation/RCU/00-INDEX @@ -12,6 +12,8 @@ lockdep-splat.txt - RCU Lockdep splats explained. NMI-RCU.txt - Using RCU to Protect Dynamic NMI Handlers +rcu_dereference.txt + - Proper care and feeding of return values from rcu_dereference() rcubarrier.txt - RCU and Unloadable Modules rculist_nulls.txt diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt index 9d10d1d..8779471 100644 --- a/Documentation/RCU/checklist.txt +++ b/Documentation/RCU/checklist.txt @@ -114,12 +114,16 @@ over a rather long period of time, but improvements are always welcome! http://www.openvms.compaq.com/wizard/wiz_2637.html The rcu_dereference() primitive is also an excellent - documentation aid, letting the person reading the code - know exactly which pointers are protected by RCU. + documentation aid, letting the person reading the + code know exactly which pointers are protected by RCU. Please note that compilers can also reorder code, and they are becoming increasingly aggressive about doing - just that. The rcu_dereference() primitive therefore - also prevents destructive compiler optimizations. + just that. The rcu_dereference() primitive therefore also + prevents destructive compiler optimizations. However, + with a bit of devious creativity, it is possible to + mishandle the return value from rcu_dereference(). + Please see rcu_dereference.txt in this directory for + more information. The rcu_dereference() primitive is used by the various "_rcu()" list-traversal primitives, such diff --git a/Documentation/RCU/rcu_dereference.txt b/Documentation/RCU/rcu_dereference.txt new file mode 100644 index 0000000..ceb05da --- /dev/null +++ b/Documentation/RCU/rcu_dereference.txt @@ -0,0 +1,371 @@ +PROPER CARE AND FEEDING OF RETURN VALUES FROM rcu_dereference() + +Most of the time, you can use values from rcu_dereference() or one of +the similar primitives without worries. Dereferencing (prefix "*"), +field selection ("->"), assignment ("="), address-of ("&"), addition and +subtraction of constants, and casts all work quite naturally and safely. + +It is nevertheless possible to get into trouble with other operations. +Follow these rules to keep your RCU code working properly: + +o You must use one of the rcu_dereference() family of primitives + to load an RCU-protected pointer, otherwise CONFIG_PROVE_RCU + will complain. Worse yet, your code can see random memory-corruption + bugs due to games that compilers and DEC Alpha can play. + Without one of the rcu_dereference() primitives, compilers + can reload the value, and won't your code have fun with two + different values for a single pointer! Without rcu_dereference(), + DEC Alpha can load a pointer, dereference that pointer, and + return data preceding initialization that preceded the store of + the pointer. + + In addition, the volatile cast in rcu_dereference() prevents the + compiler from deducing the resulting pointer value. Please see + the section entitled "EXAMPLE WHERE THE COMPILER KNOWS TOO MUCH" + for an example where the compiler can in fact deduce the exact + value of the pointer, and thus cause misordering. + +o Do not use single-element RCU-protected arrays. The compiler + is within its right to assume that the value of an index into + such an array must necessarily evaluate to zero. The compiler + could then substitute the constant zero for the computation, so + that the array index no longer depended on the value returned + by rcu_dereference(). If the array index no longer depends + on rcu_dereference(), then both the compiler and the CPU + are within their rights to order the array access before the + rcu_dereference(), which can cause the array access to return + garbage. + +o Avoid cancellation when using the "+" and "-" infix arithmetic + operators. For example, for a given variable "x", avoid + "(x-x)". There are similar arithmetic pitfalls from other + arithmetic operatiors, such as "(x*0)", "(x/(x+1))" or "(x%1)". + The compiler is within its rights to substitute zero for all of + these expressions, so that subsequent accesses no longer depend + on the rcu_dereference(), again possibly resulting in bugs due + to misordering. + + Of course, if "p" is a pointer from rcu_dereference(), and "a" + and "b" are integers that happen to be equal, the expression + "p+a-b" is safe because its value still necessarily depends on + the rcu_dereference(), thus maintaining proper ordering. + +o Avoid all-zero operands to the bitwise "&" operator, and + similarly avoid all-ones operands to the bitwise "|" operator. + If the compiler is able to deduce the value of such operands, + it is within its rights to substitute the corresponding constant + for the bitwise operation. Once again, this causes subsequent + accesses to no longer depend on the rcu_dereference(), causing + bugs due to misordering. + + Please note that single-bit operands to bitwise "&" can also + be dangerous. At this point, the compiler knows that the + resulting value can only take on one of two possible values. + Therefore, a very small amount of additional information will + allow the compiler to deduce the exact value, which again can + result in misordering. + +o If you are using RCU to protect JITed functions, so that the + "()" function-invocation operator is applied to a value obtained + (directly or indirectly) from rcu_dereference(), you may need to + interact directly with the hardware to flush instruction caches. + This issue arises on some systems when a newly JITed function is + using the same memory that was used by an earlier JITed function. + +o Do not use the results from the boolean "&&" and "||" when + dereferencing. For example, the following (rather improbable) + code is buggy: + + int a[2]; + int index; + int force_zero_index = 1; + + ... + + r1 = rcu_dereference(i1) + r2 = a[r1 && force_zero_index]; /* BUGGY!!! */ + + The reason this is buggy is that "&&" and "||" are often compiled + using branches. While weak-memory machines such as ARM or PowerPC + do order stores after such branches, they can speculate loads, + which can result in misordering bugs. + +o Do not use the results from relational operators ("==", "!=", + ">", ">=", "<", or "<=") when dereferencing. For example, + the following (quite strange) code is buggy: + + int a[2]; + int index; + int flip_index = 0; + + ... + + r1 = rcu_dereference(i1) + r2 = a[r1 != flip_index]; /* BUGGY!!! */ + + As before, the reason this is buggy is that relational operators + are often compiled using branches. And as before, although + weak-memory machines such as ARM or PowerPC do order stores + after such branches, but can speculate loads, which can again + result in misordering bugs. + +o Be very careful about comparing pointers obtained from + rcu_dereference() against non-NULL values. As Linus Torvalds + explained, if the two pointers are equal, the compiler could + substitute the pointer you are comparing against for the pointer + obtained from rcu_dereference(). For example: + + p = rcu_dereference(gp); + if (p == &default_struct) + do_default(p->a); + + Because the compiler now knows that the value of "p" is exactly + the address of the variable "default_struct", it is free to + transform this code into the following: + + p = rcu_dereference(gp); + if (p == &default_struct) + do_default(default_struct.a); + + On ARM and Power hardware, the load from "default_struct.a" + can now be speculated, such that it might happen before the + rcu_dereference(). This could result in bugs due to misordering. + + However, comparisons are OK in the following cases: + + o The comparison was against the NULL pointer. If the + compiler knows that the pointer is NULL, you had better + not be dereferencing it anyway. If the comparison is + non-equal, the compiler is none the wiser. Therefore, + it is safe to compare pointers from rcu_dereference() + against NULL pointers. + + o The pointer is never dereferenced after being compared. + Since there are no subsequent dereferences, the compiler + cannot use anything it learned from the comparison + to reorder the non-existent subsequent dereferences. + This sort of comparison occurs frequently when scanning + RCU-protected circular linked lists. + + o The comparison is against a pointer that references memory + that was initialized "a long time ago." The reason + this is safe is that even if misordering occurs, the + misordering will not affect the accesses that follow + the comparison. So exactly how long ago is "a long + time ago"? Here are some possibilities: + + o Compile time. + + o Boot time. + + o Module-init time for module code. + + o Prior to kthread creation for kthread code. + + o During some prior acquisition of the lock that + we now hold. + + o Before mod_timer() time for a timer handler. + + There are many other possibilities involving the Linux + kernel's wide array of primitives that cause code to + be invoked at a later time. + + o The pointer being compared against also came from + rcu_dereference(). In this case, both pointers depend + on one rcu_dereference() or another, so you get proper + ordering either way. + + That said, this situation can make certain RCU usage + bugs more likely to happen. Which can be a good thing, + at least if they happen during testing. An example + of such an RCU usage bug is shown in the section titled + "EXAMPLE OF AMPLIFIED RCU-USAGE BUG". + + o All of the accesses following the comparison are stores, + so that a control dependency preserves the needed ordering. + That said, it is easy to get control dependencies wrong. + Please see the "CONTROL DEPENDENCIES" section of + Documentation/memory-barriers.txt for more details. + + o The pointers are not equal -and- the compiler does + not have enough information to deduce the value of the + pointer. Note that the volatile cast in rcu_dereference() + will normally prevent the compiler from knowing too much. + +o Disable any value-speculation optimizations that your compiler + might provide, especially if you are making use of feedback-based + optimizations that take data collected from prior runs. Such + value-speculation optimizations reorder operations by design. + + There is one exception to this rule: Value-speculation + optimizations that leverage the branch-prediction hardware are + safe on strongly ordered systems (such as x86), but not on weakly + ordered systems (such as ARM or Power). Choose your compiler + command-line options wisely! + + +EXAMPLE OF AMPLIFIED RCU-USAGE BUG + +Because updaters can run concurrently with RCU readers, RCU readers can +see stale and/or inconsistent values. If RCU readers need fresh or +consistent values, which they sometimes do, they need to take proper +precautions. To see this, consider the following code fragment: + + struct foo { + int a; + int b; + int c; + }; + struct foo *gp1; + struct foo *gp2; + + void updater(void) + { + struct foo *p; + + p = kmalloc(...); + if (p == NULL) + deal_with_it(); + p->a = 42; /* Each field in its own cache line. */ + p->b = 43; + p->c = 44; + rcu_assign_pointer(gp1, p); + p->b = 143; + p->c = 144; + rcu_assign_pointer(gp2, p); + } + + void reader(void) + { + struct foo *p; + struct foo *q; + int r1, r2; + + p = rcu_dereference(gp2); + if (p == NULL) + return; + r1 = p->b; /* Guaranteed to get 143. */ + q = rcu_dereference(gp1); /* Guaranteed non-NULL. */ + if (p == q) { + /* The compiler decides that q->c is same as p->c. */ + r2 = p->c; /* Could get 44 on weakly order system. */ + } + do_something_with(r1, r2); + } + +You might be surprised that the outcome (r1 == 143 && r2 == 44) is possible, +but you should not be. After all, the updater might have been invoked +a second time between the time reader() loaded into "r1" and the time +that it loaded into "r2". The fact that this same result can occur due +to some reordering from the compiler and CPUs is beside the point. + +But suppose that the reader needs a consistent view? + +Then one approach is to use locking, for example, as follows: + + struct foo { + int a; + int b; + int c; + spinlock_t lock; + }; + struct foo *gp1; + struct foo *gp2; + + void updater(void) + { + struct foo *p; + + p = kmalloc(...); + if (p == NULL) + deal_with_it(); + spin_lock(&p->lock); + p->a = 42; /* Each field in its own cache line. */ + p->b = 43; + p->c = 44; + spin_unlock(&p->lock); + rcu_assign_pointer(gp1, p); + spin_lock(&p->lock); + p->b = 143; + p->c = 144; + spin_unlock(&p->lock); + rcu_assign_pointer(gp2, p); + } + + void reader(void) + { + struct foo *p; + struct foo *q; + int r1, r2; + + p = rcu_dereference(gp2); + if (p == NULL) + return; + spin_lock(&p->lock); + r1 = p->b; /* Guaranteed to get 143. */ + q = rcu_dereference(gp1); /* Guaranteed non-NULL. */ + if (p == q) { + /* The compiler decides that q->c is same as p->c. */ + r2 = p->c; /* Locking guarantees r2 == 144. */ + } + spin_unlock(&p->lock); + do_something_with(r1, r2); + } + +As always, use the right tool for the job! + + +EXAMPLE WHERE THE COMPILER KNOWS TOO MUCH + +If a pointer obtained from rcu_dereference() compares not-equal to some +other pointer, the compiler normally has no clue what the value of the +first pointer might be. This lack of knowledge prevents the compiler +from carrying out optimizations that otherwise might destroy the ordering +guarantees that RCU depends on. And the volatile cast in rcu_dereference() +should prevent the compiler from guessing the value. + +But without rcu_dereference(), the compiler knows more than you might +expect. Consider the following code fragment: + + struct foo { + int a; + int b; + }; + static struct foo variable1; + static struct foo variable2; + static struct foo *gp = &variable1; + + void updater(void) + { + initialize_foo(&variable2); + rcu_assign_pointer(gp, &variable2); + /* + * The above is the only store to gp in this translation unit, + * and the address of gp is not exported in any way. + */ + } + + int reader(void) + { + struct foo *p; + + p = gp; + barrier(); + if (p == &variable1) + return p->a; /* Must be variable1.a. */ + else + return p->b; /* Must be variable2.b. */ + } + +Because the compiler can see all stores to "gp", it knows that the only +possible values of "gp" are "variable1" on the one hand and "variable2" +on the other. The comparison in reader() therefore tells the compiler +the exact value of "p" even in the not-equals case. This allows the +compiler to make the return values independent of the load from "gp", +in turn destroying the ordering between this load and the loads of the +return values. This can result in "p->b" returning pre-initialization +garbage values. + +In short, rcu_dereference() is -not- optional when you are going to +dereference the resulting pointer. -- cgit v1.1 From d07e6d080d92ea72870c8d800ee2db82a61daac2 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Mon, 31 Mar 2014 13:36:33 -0700 Subject: documentation: Update API documentation This commit updates the list of RCU API members in whatisRCU.txt. Signed-off-by: Paul E. McKenney Reviewed-by: Josh Triplett --- Documentation/RCU/whatisRCU.txt | 55 ++++++++++++++++++++++++++++++++--------- 1 file changed, 44 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt index 0f0fb7c..49b8551 100644 --- a/Documentation/RCU/whatisRCU.txt +++ b/Documentation/RCU/whatisRCU.txt @@ -326,11 +326,11 @@ used as follows: a. synchronize_rcu() rcu_read_lock() / rcu_read_unlock() call_rcu() rcu_dereference() -b. call_rcu_bh() rcu_read_lock_bh() / rcu_read_unlock_bh() - rcu_dereference_bh() +b. synchronize_rcu_bh() rcu_read_lock_bh() / rcu_read_unlock_bh() + call_rcu_bh() rcu_dereference_bh() c. synchronize_sched() rcu_read_lock_sched() / rcu_read_unlock_sched() - preempt_disable() / preempt_enable() + call_rcu_sched() preempt_disable() / preempt_enable() local_irq_save() / local_irq_restore() hardirq enter / hardirq exit NMI enter / NMI exit @@ -794,10 +794,22 @@ in docbook. Here is the list, by category. RCU list traversal: + list_entry_rcu + list_first_entry_rcu + list_next_rcu list_for_each_entry_rcu + list_for_each_entry_continue_rcu + hlist_first_rcu + hlist_next_rcu + hlist_pprev_rcu hlist_for_each_entry_rcu + hlist_for_each_entry_rcu_bh + hlist_for_each_entry_continue_rcu + hlist_for_each_entry_continue_rcu_bh + hlist_nulls_first_rcu hlist_nulls_for_each_entry_rcu - list_for_each_entry_continue_rcu + hlist_bl_first_rcu + hlist_bl_for_each_entry_rcu RCU pointer/list update: @@ -806,28 +818,38 @@ RCU pointer/list update: list_add_tail_rcu list_del_rcu list_replace_rcu - hlist_del_rcu hlist_add_after_rcu hlist_add_before_rcu hlist_add_head_rcu + hlist_del_rcu + hlist_del_init_rcu hlist_replace_rcu list_splice_init_rcu() + hlist_nulls_del_init_rcu + hlist_nulls_del_rcu + hlist_nulls_add_head_rcu + hlist_bl_add_head_rcu + hlist_bl_del_init_rcu + hlist_bl_del_rcu + hlist_bl_set_first_rcu RCU: Critical sections Grace period Barrier rcu_read_lock synchronize_net rcu_barrier rcu_read_unlock synchronize_rcu rcu_dereference synchronize_rcu_expedited - call_rcu - kfree_rcu - + rcu_read_lock_held call_rcu + rcu_dereference_check kfree_rcu + rcu_dereference_protected bh: Critical sections Grace period Barrier rcu_read_lock_bh call_rcu_bh rcu_barrier_bh rcu_read_unlock_bh synchronize_rcu_bh rcu_dereference_bh synchronize_rcu_bh_expedited - + rcu_dereference_bh_check + rcu_dereference_bh_protected + rcu_read_lock_bh_held sched: Critical sections Grace period Barrier @@ -835,7 +857,12 @@ sched: Critical sections Grace period Barrier rcu_read_unlock_sched call_rcu_sched [preempt_disable] synchronize_sched_expedited [and friends] + rcu_read_lock_sched_notrace + rcu_read_unlock_sched_notrace rcu_dereference_sched + rcu_dereference_sched_check + rcu_dereference_sched_protected + rcu_read_lock_sched_held SRCU: Critical sections Grace period Barrier @@ -843,6 +870,8 @@ SRCU: Critical sections Grace period Barrier srcu_read_lock synchronize_srcu srcu_barrier srcu_read_unlock call_srcu srcu_dereference synchronize_srcu_expedited + srcu_dereference_check + srcu_read_lock_held SRCU: Initialization/cleanup init_srcu_struct @@ -850,9 +879,13 @@ SRCU: Initialization/cleanup All: lockdep-checked RCU-protected pointer access - rcu_dereference_check - rcu_dereference_protected + rcu_access_index rcu_access_pointer + rcu_dereference_index_check + rcu_dereference_raw + rcu_lockdep_assert + rcu_sleep_check + RCU_NONIDLE See the comment headers in the source code (or the docbook generated from them) for more information. -- cgit v1.1 From 31c26a6a842d541ca475a482112dda5993df2374 Mon Sep 17 00:00:00 2001 From: Tushar Behera Date: Mon, 28 Apr 2014 10:14:39 +0530 Subject: ASoC: samsung: Add sound card driver for Snow board Added machine driver to instantiate I2S based sound card on Snow board. It has MAX98095 audio codec on board. There are some other variants for Snow board which have MAX98090 audio codec. Hence support for MAX98090 is also added to this driver. Signed-off-by: Tushar Behera Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/snow.txt | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/snow.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/snow.txt b/Documentation/devicetree/bindings/sound/snow.txt new file mode 100644 index 0000000..678b191 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/snow.txt @@ -0,0 +1,17 @@ +Audio Binding for Snow boards + +Required properties: +- compatible : Can be one of the following, + "google,snow-audio-max98090" or + "google,snow-audio-max98095" +- samsung,i2s-controller: The phandle of the Samsung I2S controller +- samsung,audio-codec: The phandle of the audio codec + +Example: + +sound { + compatible = "google,snow-audio-max98095"; + + samsung,i2s-controller = <&i2s0>; + samsung,audio-codec = <&max98095>; +}; -- cgit v1.1 From 3046365bb470f0ec2f7cf5cb07a8ee7e4b490103 Mon Sep 17 00:00:00 2001 From: Srinivas Pandruvada Date: Tue, 29 Apr 2014 00:51:00 +0100 Subject: devres: introduce API "devm_kmemdup Introduce devm_kmemdup, which uses resource managed kmalloc. There are several request from maintainers to add this instead of using kmemdup. Signed-off-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron --- Documentation/driver-model/devres.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt index 4f7897e..4999518 100644 --- a/Documentation/driver-model/devres.txt +++ b/Documentation/driver-model/devres.txt @@ -236,6 +236,7 @@ certainly invest a bit more effort into libata core layer). MEM devm_kzalloc() devm_kfree() + devm_kmemdup() IIO devm_iio_device_alloc() -- cgit v1.1 From b4a2d475ae9baf8fcaa311ba62a404ba1efad147 Mon Sep 17 00:00:00 2001 From: Srinivas Pandruvada Date: Tue, 29 Apr 2014 00:51:00 +0100 Subject: iio: Added ABI description for quaternion Added documentation for reading quaternion components for 3D rotations. Signed-off-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron --- Documentation/ABI/testing/sysfs-bus-iio | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 58ba333..6b74691 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -792,6 +792,7 @@ 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 +What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_en KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: @@ -807,6 +808,7 @@ 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 +What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_type KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: @@ -853,6 +855,7 @@ 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 +What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_index KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: @@ -899,3 +902,12 @@ Contact: linux-iio@vger.kernel.org Description: This attribute is used to get/set the integration time in seconds. + +What: /sys/bus/iio/devices/iio:deviceX/in_rot_quaternion_raw +KernelVersion: 3.15 +Contact: linux-iio@vger.kernel.org +Description: + Raw value of quaternion components using a format + x y z w. Here x, y, and z component represents the axis about + which a rotation will occur and w component represents the + amount of rotation. -- cgit v1.1 From 27e289dce29764e488c1e13e9aa6950cad1f4aab Mon Sep 17 00:00:00 2001 From: Stratos Karafotis Date: Fri, 25 Apr 2014 23:15:23 +0300 Subject: cpufreq: Introduce macros for cpufreq_frequency_table iteration Many cpufreq drivers need to iterate over the cpufreq_frequency_table for various tasks. This patch introduces two macros which can be used for iteration over cpufreq_frequency_table keeping a common coding style across drivers: - cpufreq_for_each_entry: iterate over each entry of the table - cpufreq_for_each_valid_entry: iterate over each entry that contains a valid frequency. It should have no functional changes. Signed-off-by: Stratos Karafotis Acked-by: Lad, Prabhakar Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki --- Documentation/cpu-freq/cpu-drivers.txt | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'Documentation') diff --git a/Documentation/cpu-freq/cpu-drivers.txt b/Documentation/cpu-freq/cpu-drivers.txt index 48da5fd..b045fe5 100644 --- a/Documentation/cpu-freq/cpu-drivers.txt +++ b/Documentation/cpu-freq/cpu-drivers.txt @@ -228,3 +228,22 @@ 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. + +The following macros can be used as iterators over cpufreq_frequency_table: + +cpufreq_for_each_entry(pos, table) - iterates over all entries of frequency +table. + +cpufreq-for_each_valid_entry(pos, table) - iterates over all entries, +excluding CPUFREQ_ENTRY_INVALID frequencies. +Use arguments "pos" - a cpufreq_frequency_table * as a loop cursor and +"table" - the cpufreq_frequency_table * you want to iterate over. + +For example: + + struct cpufreq_frequency_table *pos, *driver_freq_table; + + cpufreq_for_each_entry(pos, driver_freq_table) { + /* Do something with pos */ + pos->frequency = ... + } -- cgit v1.1 From 780aaeff96819ca58e0cad830bfbe6eee9aef82c Mon Sep 17 00:00:00 2001 From: Alexander Shiyan Date: Sat, 26 Apr 2014 10:57:03 +0400 Subject: ASoC: mc13783: Add devicetree support This patch adds devicetree support for mc13783-codec. Signed-off-by: Alexander Shiyan Acked-by: Lee Jones Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/mfd/mc13xxx.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/mc13xxx.txt b/Documentation/devicetree/bindings/mfd/mc13xxx.txt index 1413f39..8aba488 100644 --- a/Documentation/devicetree/bindings/mfd/mc13xxx.txt +++ b/Documentation/devicetree/bindings/mfd/mc13xxx.txt @@ -10,6 +10,9 @@ Optional properties: - fsl,mc13xxx-uses-touch : Indicate the touchscreen controller is being used Sub-nodes: +- codec: Contain the Audio Codec node. + - adc-port: Contain PMIC SSI port number used for ADC. + - dac-port: Contain PMIC SSI port number used for DAC. - leds : Contain the led nodes and initial register values in property "led-control". Number of register depends of used IC, for MC13783 is 6, for MC13892 is 4, for MC34708 is 1. See datasheet for bits definitions of -- cgit v1.1 From eebeac03db93e5556f37de6ed940f89327cc221b Mon Sep 17 00:00:00 2001 From: Srikanth Thokala Date: Wed, 23 Apr 2014 20:23:25 +0530 Subject: dma: Add Xilinx Video DMA DT Binding Documentation Device-tree binding documentation of Xilinx Video DMA Engine Signed-off-by: Srikanth Thokala Acked-by: Rob Herring Signed-off-by: Vinod Koul --- .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt | 75 ++++++++++++++++++++++ 1 file changed, 75 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt new file mode 100644 index 0000000..1405ed0 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt @@ -0,0 +1,75 @@ +Xilinx AXI VDMA engine, it does transfers between memory and video devices. +It can be configured to have one channel or two channels. If configured +as two channels, one is to transmit to the video device and another is +to receive from the video device. + +Required properties: +- compatible: Should be "xlnx,axi-vdma-1.00.a" +- #dma-cells: Should be <1>, see "dmas" property below +- reg: Should contain VDMA registers location and length. +- xlnx,num-fstores: Should be the number of framebuffers as configured in h/w. +- dma-channel child node: Should have at least one channel and can have up to + two channels per device. This node specifies the properties of each + DMA channel (see child node properties below). + +Optional properties: +- xlnx,include-sg: Tells configured for Scatter-mode in + the hardware. +- xlnx,flush-fsync: Tells which channel to Flush on Frame sync. + It takes following values: + {1}, flush both channels + {2}, flush mm2s channel + {3}, flush s2mm channel + +Required child node properties: +- compatible: It should be either "xlnx,axi-vdma-mm2s-channel" or + "xlnx,axi-vdma-s2mm-channel". +- interrupts: Should contain per channel VDMA interrupts. +- xlnx,data-width: Should contain the stream data width, take values + {32,64...1024}. + +Optional child node properties: +- xlnx,include-dre: Tells hardware is configured for Data + Realignment Engine. +- xlnx,genlock-mode: Tells Genlock synchronization is + enabled/disabled in hardware. + +Example: +++++++++ + +axi_vdma_0: axivdma@40030000 { + compatible = "xlnx,axi-vdma-1.00.a"; + #dma_cells = <1>; + reg = < 0x40030000 0x10000 >; + xlnx,num-fstores = <0x8>; + xlnx,flush-fsync = <0x1>; + dma-channel@40030000 { + compatible = "xlnx,axi-vdma-mm2s-channel"; + interrupts = < 0 54 4 >; + xlnx,datawidth = <0x40>; + } ; + dma-channel@40030030 { + compatible = "xlnx,axi-vdma-s2mm-channel"; + interrupts = < 0 53 4 >; + xlnx,datawidth = <0x40>; + } ; +} ; + + +* DMA client + +Required properties: +- dmas: a list of <[Video DMA device phandle] [Channel ID]> pairs, + where Channel ID is '0' for write/tx and '1' for read/rx + channel. +- dma-names: a list of DMA channel names, one per "dmas" entry + +Example: +++++++++ + +vdmatest_0: vdmatest@0 { + compatible ="xlnx,axi-vdma-test-1.00.a"; + dmas = <&axi_vdma_0 0 + &axi_vdma_0 1>; + dma-names = "vdma0", "vdma1"; +} ; -- cgit v1.1 From 50bb0c94759bff8c62f1c7c8f774255e44ec1a41 Mon Sep 17 00:00:00 2001 From: Anup Patel Date: Tue, 29 Apr 2014 11:24:17 +0530 Subject: KVM: Documentation: Add info regarding KVM_ARM_VCPU_PSCI_0_2 feature We have in-kernel emulation of PSCI v0.2 in KVM ARM/ARM64. To provide PSCI v0.2 interface to VCPUs, we have to enable KVM_ARM_VCPU_PSCI_0_2 feature when doing KVM_ARM_VCPU_INIT ioctl. The patch updates documentation of KVM_ARM_VCPU_INIT ioctl to provide info regarding KVM_ARM_VCPU_PSCI_0_2 feature. Signed-off-by: Anup Patel Signed-off-by: Pranavkumar Sawargaonkar Acked-by: Christoffer Dall Acked-by: Marc Zyngier Signed-off-by: Christoffer Dall --- Documentation/virtual/kvm/api.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 2014ff1..556d056 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -2376,6 +2376,8 @@ Possible features: 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). + - KVM_ARM_VCPU_PSCI_0_2: Emulate PSCI v0.2 for the CPU. + Depends on KVM_CAP_ARM_PSCI_0_2. 4.83 KVM_ARM_PREFERRED_TARGET -- cgit v1.1 From 8ad6b634928a25971dc42dce101808b1491f87ec Mon Sep 17 00:00:00 2001 From: Anup Patel Date: Tue, 29 Apr 2014 11:24:19 +0530 Subject: KVM: Add KVM_EXIT_SYSTEM_EVENT to user space API header Currently, we don't have an exit reason to notify user space about a system-level event (for e.g. system reset or shutdown) triggered by the VCPU. This patch adds exit reason KVM_EXIT_SYSTEM_EVENT for this purpose. We can also inform user space about the 'type' and architecture specific 'flags' of a system-level event using the kvm_run structure. This newly added KVM_EXIT_SYSTEM_EVENT will be used by KVM ARM/ARM64 in-kernel PSCI v0.2 support to reset/shutdown VMs. Signed-off-by: Anup Patel Signed-off-by: Pranavkumar Sawargaonkar Reviewed-by: Christoffer Dall Reviewed-by: Marc Zyngier Signed-off-by: Christoffer Dall --- Documentation/virtual/kvm/api.txt | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 556d056..6a5de56 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -2740,6 +2740,21 @@ It gets triggered whenever both KVM_CAP_PPC_EPR are enabled and an external interrupt has just been delivered into the guest. User space should put the acknowledged interrupt vector into the 'epr' field. + /* KVM_EXIT_SYSTEM_EVENT */ + struct { +#define KVM_SYSTEM_EVENT_SHUTDOWN 1 +#define KVM_SYSTEM_EVENT_RESET 2 + __u32 type; + __u64 flags; + } system_event; + +If exit_reason is KVM_EXIT_SYSTEM_EVENT then the vcpu has triggered +a system-level event using some architecture specific mechanism (hypercall +or some special instruction). In case of ARM/ARM64, this is triggered using +HVC instruction based PSCI call from the vcpu. The 'type' field describes +the system-level event type. The 'flags' field describes architecture +specific flags for the system-level event. + /* Fix the size of the union. */ char padding[256]; }; -- cgit v1.1 From 8364f9af237f47fa128bd4e4f7b45beef890c994 Mon Sep 17 00:00:00 2001 From: "Ivan T. Ivanov" Date: Mon, 28 Apr 2014 16:34:15 +0300 Subject: usb: phy: msm: Add device tree support and binding information Allows controller to be specified via device tree. Signed-off-by: Ivan T. Ivanov Signed-off-by: Felipe Balbi --- .../devicetree/bindings/usb/msm-hsusb.txt | 67 ++++++++++++++++++++++ 1 file changed, 67 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt b/Documentation/devicetree/bindings/usb/msm-hsusb.txt index 5ea26c6..ee4123d 100644 --- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt +++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt @@ -15,3 +15,70 @@ Example EHCI controller device node: usb-phy = <&usb_otg>; }; +USB PHY with optional OTG: + +Required properties: +- compatible: Should contain: + "qcom,usb-otg-ci" for chipsets with ChipIdea 45nm PHY + "qcom,usb-otg-snps" for chipsets with Synopsys 28nm PHY + +- regs: Offset and length of the register set in the memory map +- interrupts: interrupt-specifier for the OTG interrupt. + +- clocks: A list of phandle + clock-specifier pairs for the + clocks listed in clock-names +- clock-names: Should contain the following: + "phy" USB PHY reference clock + "core" Protocol engine clock + "iface" Interface bus clock + "alt_core" Protocol engine clock for targets with asynchronous + reset methodology. (optional) + +- vdccx-supply: phandle to the regulator for the vdd supply for + digital circuit operation. +- v1p8-supply: phandle to the regulator for the 1.8V supply +- v3p3-supply: phandle to the regulator for the 3.3V supply + +- resets: A list of phandle + reset-specifier pairs for the + resets listed in reset-names +- reset-names: Should contain the following: + "phy" USB PHY controller reset + "link" USB LINK controller reset + +- qcom,otg-control: OTG control (VBUS and ID notifications) can be one of + 1 - PHY control + 2 - PMIC control + +Optional properties: +- dr_mode: One of "host", "peripheral" or "otg". Defaults to "otg" + +- qcom,phy-init-sequence: PHY configuration sequence values. This is related to Device + Mode Eye Diagram test. Start address at which these values will be + written is ULPI_EXT_VENDOR_SPECIFIC. Value of -1 is reserved as + "do not overwrite default value at this address". + For example: qcom,phy-init-sequence = < -1 0x63 >; + Will update only value at address ULPI_EXT_VENDOR_SPECIFIC + 1. + +Example HSUSB OTG controller device node: + + usb@f9a55000 { + compatible = "qcom,usb-otg-snps"; + reg = <0xf9a55000 0x400>; + interrupts = <0 134 0>; + dr_mode = "peripheral"; + + clocks = <&gcc GCC_XO_CLK>, <&gcc GCC_USB_HS_SYSTEM_CLK>, + <&gcc GCC_USB_HS_AHB_CLK>; + + clock-names = "phy", "core", "iface"; + + vddcx-supply = <&pm8841_s2_corner>; + v1p8-supply = <&pm8941_l6>; + v3p3-supply = <&pm8941_l24>; + + resets = <&gcc GCC_USB2A_PHY_BCR>, <&gcc GCC_USB_HS_BCR>; + reset-names = "phy", "link"; + + qcom,otg-control = <1>; + qcom,phy-init-sequence = < -1 0x63 >; + }; -- cgit v1.1 From cfa3ff5dfe6a11ac8bc4a080416984ab00b0980c Mon Sep 17 00:00:00 2001 From: "Ivan T. Ivanov" Date: Mon, 28 Apr 2014 16:34:17 +0300 Subject: usb: phy: msm: Add support for secondary PHY control Allow support to use 2nd HSPHY with USB2 Core. Some platforms may have configuration to allow USB controller work with any of the two HSPHYs present. By default driver configures USB core to use primary HSPHY. Add support to allow user select 2nd HSPHY using DT parameter. Signed-off-by: Ivan T. Ivanov Cc: Manu Gautam Signed-off-by: Felipe Balbi --- Documentation/devicetree/bindings/usb/msm-hsusb.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt b/Documentation/devicetree/bindings/usb/msm-hsusb.txt index ee4123d..0669667 100644 --- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt +++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt @@ -59,6 +59,12 @@ Optional properties: For example: qcom,phy-init-sequence = < -1 0x63 >; Will update only value at address ULPI_EXT_VENDOR_SPECIFIC + 1. +- qcom,phy-num: Select number of pyco-phy to use, can be one of + 0 - PHY one, default + 1 - Second PHY + Some platforms may have configuration to allow USB + controller work with any of the two HSPHYs present. + Example HSUSB OTG controller device node: usb@f9a55000 { -- cgit v1.1 From 01799b622217ffebdc95e8e0aedbd4cff6a35a50 Mon Sep 17 00:00:00 2001 From: "Ivan T. Ivanov" Date: Mon, 28 Apr 2014 16:34:22 +0300 Subject: usb: phy: msm: Vote for corner of VDD CX instead of voltage of VDD CX New platform uses RBCPR hardware feature, with that voting for absolute voltage of VDD CX is not required. Hence vote for corner of VDD CX which uses nominal corner voltage on VDD CX. Signed-off-by: Ivan T. Ivanov Cc: Mayank Rana Signed-off-by: Felipe Balbi --- Documentation/devicetree/bindings/usb/msm-hsusb.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt b/Documentation/devicetree/bindings/usb/msm-hsusb.txt index 0669667..2826f2a 100644 --- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt +++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt @@ -65,6 +65,10 @@ Optional properties: Some platforms may have configuration to allow USB controller work with any of the two HSPHYs present. +- qcom,vdd-levels: This property must be a list of three integer values + (no, min, max) where each value represents either a voltage + in microvolts or a value corresponding to voltage corner. + Example HSUSB OTG controller device node: usb@f9a55000 { @@ -87,4 +91,5 @@ Example HSUSB OTG controller device node: qcom,otg-control = <1>; qcom,phy-init-sequence = < -1 0x63 >; + qcom,vdd-levels = <1 5 7>; }; -- cgit v1.1 From 719e284369d23c3feb02d02ad58b3a516df47806 Mon Sep 17 00:00:00 2001 From: Roy Franz Date: Sat, 28 Sep 2013 08:44:21 -0700 Subject: doc: efi-stub.txt updates for ARM Update efi-stub.txt documentation to be more general and not x86 specific. Add ARM only "dtb=" command line option description. Signed-off-by: Roy Franz Signed-off-by: Leif Lindholm Acked-by: Grant Likely Acked-by: Catalin Marinas Signed-off-by: Matt Fleming --- Documentation/efi-stub.txt | 27 ++++++++++++++++++++------- 1 file changed, 20 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/efi-stub.txt b/Documentation/efi-stub.txt index c628788..26be7b0 100644 --- a/Documentation/efi-stub.txt +++ b/Documentation/efi-stub.txt @@ -1,13 +1,16 @@ The EFI Boot Stub --------------------------- -On the x86 platform, a bzImage can masquerade as a PE/COFF image, -thereby convincing EFI firmware loaders to load it as an EFI -executable. The code that modifies the bzImage header, along with the -EFI-specific entry point that the firmware loader jumps to are -collectively known as the "EFI boot stub", and live in +On the x86 and ARM platforms, a kernel zImage/bzImage can masquerade +as a PE/COFF image, thereby convincing EFI firmware loaders to load +it as an EFI executable. The code that modifies the bzImage header, +along with the EFI-specific entry point that the firmware loader +jumps to are collectively known as the "EFI boot stub", and live in arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c, -respectively. +respectively. For ARM the EFI stub is implemented in +arch/arm/boot/compressed/efi-header.S and +arch/arm/boot/compressed/efi-stub.c. EFI stub code that is shared +between architectures is in drivers/firmware/efi/efi-stub-helper.c. By using the EFI boot stub it's possible to boot a Linux kernel without the use of a conventional EFI boot loader, such as grub or @@ -23,7 +26,9 @@ The bzImage located in arch/x86/boot/bzImage must be copied to the EFI System Partition (ESP) and renamed with the extension ".efi". Without the extension the EFI firmware loader will refuse to execute it. It's not possible to execute bzImage.efi from the usual Linux file systems -because EFI firmware doesn't have support for them. +because EFI firmware doesn't have support for them. For ARM the +arch/arm/boot/zImage should be copied to the system partition, and it +may not need to be renamed. **** Passing kernel parameters from the EFI shell @@ -63,3 +68,11 @@ Notice how bzImage.efi can be specified with a relative path. That's because the image we're executing is interpreted by the EFI shell, which understands relative paths, whereas the rest of the command line is passed to bzImage.efi. + + +**** The "dtb=" option + +For the ARM architecture, we also need to be able to provide a device +tree to the kernel. This is done with the "dtb=" command line option, +and is processed in the same manner as the "initrd=" option that is +described above. -- cgit v1.1 From 5bcb59260f229d5d829da0e88400441a43d669f0 Mon Sep 17 00:00:00 2001 From: Alex Elder Date: Mon, 21 Apr 2014 16:26:24 -0500 Subject: ARM: dts: revise kona clock binding document The next patch defines a binding for a new Broadcom SoC that uses Kona style CCUs for its clocks. Update the generic Kona clock binding document so it's more natural to accomodate the definitions of additional SoC families. Specifically: - Define the compatible string values generically, referring to specific per-model values later in the document. - Put the device tree example immediately after the required properties listing, before the tables of SoC-specific values. - Clearly identify the start of the section defining specific values related to the BCM281XX family - Add a list of the specific BCM281XX family compatible strings. - Reword the description of the table slightly. Signed-off-by: Alex Elder Signed-off-by: Mike Turquette --- .../devicetree/bindings/clock/bcm-kona-clock.txt | 87 ++++++++++++---------- 1 file changed, 47 insertions(+), 40 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt b/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt index 56d1f49..ebe3ab6 100644 --- a/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt +++ b/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt @@ -10,12 +10,12 @@ This binding uses the common clock binding: Required properties: - compatible - Shall have one of the following values: - - "brcm,bcm11351-root-ccu" - - "brcm,bcm11351-aon-ccu" - - "brcm,bcm11351-hub-ccu" - - "brcm,bcm11351-master-ccu" - - "brcm,bcm11351-slave-ccu" + Shall have a value of the form "brcm,--ccu", + where is a Broadcom SoC model number and is + the name of a defined CCU. For example: + "brcm,bcm11351-root-ccu" + The compatible strings used for each supported SoC family + are defined below. - reg Shall define the base and range of the address space containing clock control registers @@ -26,12 +26,48 @@ Required properties: Shall be an ordered list of strings defining the names of the clocks provided by the CCU. +Device tree example: + + slave_ccu: slave_ccu { + compatible = "brcm,bcm11351-slave-ccu"; + reg = <0x3e011000 0x0f00>; + #clock-cells = <1>; + clock-output-names = "uartb", + "uartb2", + "uartb3", + "uartb4"; + }; + + ref_crystal_clk: ref_crystal { + #clock-cells = <0>; + compatible = "fixed-clock"; + clock-frequency = <26000000>; + }; + + uart@3e002000 { + compatible = "brcm,bcm11351-dw-apb-uart", "snps,dw-apb-uart"; + status = "disabled"; + reg = <0x3e002000 0x1000>; + clocks = <&slave_ccu BCM281XX_SLAVE_CCU_UARTB3>; + interrupts = ; + reg-shift = <2>; + reg-io-width = <4>; + }; + +BCM281XX family +--------------- +CCU compatible string values for SoCs in the BCM281XX family are: + "brcm,bcm11351-root-ccu" + "brcm,bcm11351-aon-ccu" + "brcm,bcm11351-hub-ccu" + "brcm,bcm11351-master-ccu" + "brcm,bcm11351-slave-ccu" -BCM281XX family SoCs use Kona CCUs. The following table defines -the set of CCUs and clock specifiers for BCM281XX clocks. When -a clock consumer references a clocks, its symbolic specifier -(rather than its numeric index value) should be used. These -specifiers are defined in "include/dt-bindings/clock/bcm281xx.h". +The following table defines the set of CCUs and clock specifiers for +BCM281XX family clocks. When a clock consumer references a clocks, +its symbolic specifier (rather than its numeric index value) should +be used. These specifiers are defined in: + "include/dt-bindings/clock/bcm281xx.h" CCU Clock Type Index Specifier --- ----- ---- ----- --------- @@ -62,32 +98,3 @@ specifiers are defined in "include/dt-bindings/clock/bcm281xx.h". slave bsc2 peri 7 BCM281XX_SLAVE_CCU_BSC2 slave bsc3 peri 8 BCM281XX_SLAVE_CCU_BSC3 slave pwm peri 9 BCM281XX_SLAVE_CCU_PWM - - -Device tree example: - - slave_ccu: slave_ccu { - compatible = "brcm,bcm11351-slave-ccu"; - reg = <0x3e011000 0x0f00>; - #clock-cells = <1>; - clock-output-names = "uartb", - "uartb2", - "uartb3", - "uartb4"; - }; - - ref_crystal_clk: ref_crystal { - #clock-cells = <0>; - compatible = "fixed-clock"; - clock-frequency = <26000000>; - }; - - uart@3e002000 { - compatible = "brcm,bcm11351-dw-apb-uart", "snps,dw-apb-uart"; - status = "disabled"; - reg = <0x3e002000 0x1000>; - clocks = <&slave_ccu BCM281XX_SLAVE_CCU_UARTB3>; - interrupts = ; - reg-shift = <2>; - reg-io-width = <4>; - }; -- cgit v1.1 From 7f2ce16801a0ee20f72608b643b9cafcdec370f1 Mon Sep 17 00:00:00 2001 From: Alex Elder Date: Mon, 21 Apr 2014 16:26:25 -0500 Subject: ARM: dts: define clock binding for bcm21664 Document the device tree binding for Broadcom BCM28164 clock control units and clocks. This SoC uses Kona CCUs, similar to the BCM281XX SoC family. Signed-off-by: Alex Elder Signed-off-by: Mike Turquette --- .../devicetree/bindings/clock/bcm-kona-clock.txt | 39 ++++++++++++++++++++++ 1 file changed, 39 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt b/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt index ebe3ab6..5286e26 100644 --- a/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt +++ b/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt @@ -98,3 +98,42 @@ be used. These specifiers are defined in: slave bsc2 peri 7 BCM281XX_SLAVE_CCU_BSC2 slave bsc3 peri 8 BCM281XX_SLAVE_CCU_BSC3 slave pwm peri 9 BCM281XX_SLAVE_CCU_PWM + + +BCM21664 family +--------------- +CCU compatible string values for SoCs in the BCM21664 family are: + "brcm,bcm21664-root-ccu" + "brcm,bcm21664-aon-ccu" + "brcm,bcm21664-master-ccu" + "brcm,bcm21664-slave-ccu" + +The following table defines the set of CCUs and clock specifiers for +BCM21664 family clocks. When a clock consumer references a clocks, +its symbolic specifier (rather than its numeric index value) should +be used. These specifiers are defined in: + "include/dt-bindings/clock/bcm21664.h" + + CCU Clock Type Index Specifier + --- ----- ---- ----- --------- + root frac_1m peri 0 BCM21664_ROOT_CCU_FRAC_1M + + aon hub_timer peri 0 BCM21664_AON_CCU_HUB_TIMER + + master sdio1 peri 0 BCM21664_MASTER_CCU_SDIO1 + master sdio2 peri 1 BCM21664_MASTER_CCU_SDIO2 + master sdio3 peri 2 BCM21664_MASTER_CCU_SDIO3 + master sdio4 peri 3 BCM21664_MASTER_CCU_SDIO4 + master sdio1_sleep peri 4 BCM21664_MASTER_CCU_SDIO1_SLEEP + master sdio2_sleep peri 5 BCM21664_MASTER_CCU_SDIO2_SLEEP + master sdio3_sleep peri 6 BCM21664_MASTER_CCU_SDIO3_SLEEP + master sdio4_sleep peri 7 BCM21664_MASTER_CCU_SDIO4_SLEEP + + slave uartb peri 0 BCM21664_SLAVE_CCU_UARTB + slave uartb2 peri 1 BCM21664_SLAVE_CCU_UARTB2 + slave uartb3 peri 2 BCM21664_SLAVE_CCU_UARTB3 + slave uartb4 peri 3 BCM21664_SLAVE_CCU_UARTB4 + slave bsc1 peri 4 BCM21664_SLAVE_CCU_BSC1 + slave bsc2 peri 5 BCM21664_SLAVE_CCU_BSC2 + slave bsc3 peri 6 BCM21664_SLAVE_CCU_BSC3 + slave bsc4 peri 7 BCM21664_SLAVE_CCU_BSC4 -- cgit v1.1 From 2d85a713dca8b1c96e78e9f17c6a9bc88d11515a Mon Sep 17 00:00:00 2001 From: Kumar Gala Date: Fri, 4 Apr 2014 11:31:29 -0500 Subject: clk: qcom: Add basic support for APQ8064 global clock controller clocks The APQ8064 and MSM8960 share a significant amount of clock data and code between the two SoCs. Rather than duplicating the data we just add support for a unqiue APQ8064 clock table into the MSM8960 code. For now add just enough clocks to get a basic serial port going on an APQ8064 device. Signed-off-by: Kumar Gala Reviewed-by: Stephen Boyd Signed-off-by: Mike Turquette [mturquette@linaro.org: trivial conflict due to missing ipq8064 support] --- Documentation/devicetree/bindings/clock/qcom,gcc.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt b/Documentation/devicetree/bindings/clock/qcom,gcc.txt index 767401f..7b7104e 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt @@ -4,6 +4,7 @@ Qualcomm Global Clock & Reset Controller Binding Required properties : - compatible : shall contain only one of the following: + "qcom,gcc-apq8064" "qcom,gcc-msm8660" "qcom,gcc-msm8960" "qcom,gcc-msm8974" -- cgit v1.1 From e1977464e8403b4d7ed23d6bdb3358e78b311aa0 Mon Sep 17 00:00:00 2001 From: Leif Lindholm Date: Thu, 28 Nov 2013 16:41:21 +0000 Subject: doc: arm: add UEFI support documentation This patch provides documentation of the [U]EFI runtime service and configuration features for the arm architecture. Cc: Rob Landley Cc: linux-doc@vger.kernel.org Signed-off-by: Leif Lindholm Acked-by: Grant Likely Acked-by: Catalin Marinas Signed-off-by: Matt Fleming --- Documentation/arm/00-INDEX | 2 ++ Documentation/arm/uefi.txt | 64 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 66 insertions(+) create mode 100644 Documentation/arm/uefi.txt (limited to 'Documentation') diff --git a/Documentation/arm/00-INDEX b/Documentation/arm/00-INDEX index a94090c..3b08bc2 100644 --- a/Documentation/arm/00-INDEX +++ b/Documentation/arm/00-INDEX @@ -46,5 +46,7 @@ swp_emulation - SWP/SWPB emulation handler/logging description tcm.txt - ARM Tightly Coupled Memory +uefi.txt + - [U]EFI configuration and runtime services documentation vlocks.txt - Voting locks, low-level mechanism relying on memory system atomic writes. diff --git a/Documentation/arm/uefi.txt b/Documentation/arm/uefi.txt new file mode 100644 index 0000000..d60030a --- /dev/null +++ b/Documentation/arm/uefi.txt @@ -0,0 +1,64 @@ +UEFI, the Unified Extensible Firmware Interface, is a specification +governing the behaviours of compatible firmware interfaces. It is +maintained by the UEFI Forum - http://www.uefi.org/. + +UEFI is an evolution of its predecessor 'EFI', so the terms EFI and +UEFI are used somewhat interchangeably in this document and associated +source code. As a rule, anything new uses 'UEFI', whereas 'EFI' refers +to legacy code or specifications. + +UEFI support in Linux +===================== +Booting on a platform with firmware compliant with the UEFI specification +makes it possible for the kernel to support additional features: +- UEFI Runtime Services +- Retrieving various configuration information through the standardised + interface of UEFI configuration tables. (ACPI, SMBIOS, ...) + +For actually enabling [U]EFI support, enable: +- CONFIG_EFI=y +- CONFIG_EFI_VARS=y or m + +The implementation depends on receiving information about the UEFI environment +in a Flattened Device Tree (FDT) - so is only available with CONFIG_OF. + +UEFI stub +========= +The "stub" is a feature that extends the Image/zImage into a valid UEFI +PE/COFF executable, including a loader application that makes it possible to +load the kernel directly from the UEFI shell, boot menu, or one of the +lightweight bootloaders like Gummiboot or rEFInd. + +The kernel image built with stub support remains a valid kernel image for +booting in non-UEFI environments. + +UEFI kernel support on ARM +========================== +UEFI kernel support on the ARM architectures (arm and arm64) is only available +when boot is performed through the stub. + +When booting in UEFI mode, the stub deletes any memory nodes from a provided DT. +Instead, the kernel reads the UEFI memory map. + +The stub populates the FDT /chosen node with (and the kernel scans for) the +following parameters: +________________________________________________________________________________ +Name | Size | Description +================================================================================ +linux,uefi-system-table | 64-bit | Physical address of the UEFI System Table. +-------------------------------------------------------------------------------- +linux,uefi-mmap-start | 64-bit | Physical address of the UEFI memory map, + | | populated by the UEFI GetMemoryMap() call. +-------------------------------------------------------------------------------- +linux,uefi-mmap-size | 32-bit | Size in bytes of the UEFI memory map + | | pointed to in previous entry. +-------------------------------------------------------------------------------- +linux,uefi-mmap-desc-size | 32-bit | Size in bytes of each entry in the UEFI + | | memory map. +-------------------------------------------------------------------------------- +linux,uefi-mmap-desc-ver | 32-bit | Version of the mmap descriptor format. +-------------------------------------------------------------------------------- +linux,uefi-stub-kern-ver | string | Copy of linux_banner from build. +-------------------------------------------------------------------------------- + +For verbose debug messages, specify 'uefi_debug' on the kernel command line. -- cgit v1.1 From cdd7857898c8d2a159118e663f59978e6b3542f2 Mon Sep 17 00:00:00 2001 From: Mark Salter Date: Fri, 29 Nov 2013 16:00:14 -0500 Subject: doc: arm64: add description of EFI stub support Add explanation of arm64 EFI stub and kernel image header changes needed to masquerade as a PE/COFF application. Signed-off-by: Mark Salter Signed-off-by: Leif Lindholm Acked-by: Grant Likely Acked-by: Catalin Marinas Signed-off-by: Matt Fleming --- Documentation/arm64/booting.txt | 4 ++++ Documentation/efi-stub.txt | 12 +++++++++--- 2 files changed, 13 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt index beb754e..37fc4f6 100644 --- a/Documentation/arm64/booting.txt +++ b/Documentation/arm64/booting.txt @@ -85,6 +85,10 @@ The decompressed kernel image contains a 64-byte header as follows: Header notes: - code0/code1 are responsible for branching to stext. +- when booting through EFI, code0/code1 are initially skipped. + res5 is an offset to the PE header and the PE header has the EFI + entry point (efi_stub_entry). When the stub has done its work, it + jumps to code0 to resume the normal boot process. The image must be placed at the specified offset (currently 0x80000) from the start of the system RAM and called there. The start of the diff --git a/Documentation/efi-stub.txt b/Documentation/efi-stub.txt index 26be7b0..7747024 100644 --- a/Documentation/efi-stub.txt +++ b/Documentation/efi-stub.txt @@ -12,6 +12,11 @@ arch/arm/boot/compressed/efi-header.S and arch/arm/boot/compressed/efi-stub.c. EFI stub code that is shared between architectures is in drivers/firmware/efi/efi-stub-helper.c. +For arm64, there is no compressed kernel support, so the Image itself +masquerades as a PE/COFF image and the EFI stub is linked into the +kernel. The arm64 EFI stub lives in arch/arm64/kernel/efi-entry.S +and arch/arm64/kernel/efi-stub.c. + By using the EFI boot stub it's possible to boot a Linux kernel without the use of a conventional EFI boot loader, such as grub or elilo. Since the EFI boot stub performs the jobs of a boot loader, in @@ -28,7 +33,8 @@ the extension the EFI firmware loader will refuse to execute it. It's not possible to execute bzImage.efi from the usual Linux file systems because EFI firmware doesn't have support for them. For ARM the arch/arm/boot/zImage should be copied to the system partition, and it -may not need to be renamed. +may not need to be renamed. Similarly for arm64, arch/arm64/boot/Image +should be copied but not necessarily renamed. **** Passing kernel parameters from the EFI shell @@ -72,7 +78,7 @@ is passed to bzImage.efi. **** The "dtb=" option -For the ARM architecture, we also need to be able to provide a device -tree to the kernel. This is done with the "dtb=" command line option, +For the ARM and arm64 architectures, we also need to be able to provide a +device tree to the kernel. This is done with the "dtb=" command line option, and is processed in the same manner as the "initrd=" option that is described above. -- cgit v1.1 From 3891a04aafd668686239349ea58f3314ea2af86b Mon Sep 17 00:00:00 2001 From: "H. Peter Anvin" Date: Tue, 29 Apr 2014 16:46:09 -0700 Subject: x86-64, espfix: Don't leak bits 31:16 of %esp returning to 16-bit stack The IRET instruction, when returning to a 16-bit segment, only restores the bottom 16 bits of the user space stack pointer. This causes some 16-bit software to break, but it also leaks kernel state to user space. We have a software workaround for that ("espfix") for the 32-bit kernel, but it relies on a nonzero stack segment base which is not available in 64-bit mode. In checkin: b3b42ac2cbae x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels we "solved" this by forbidding 16-bit segments on 64-bit kernels, with the logic that 16-bit support is crippled on 64-bit kernels anyway (no V86 support), but it turns out that people are doing stuff like running old Win16 binaries under Wine and expect it to work. This works around this by creating percpu "ministacks", each of which is mapped 2^16 times 64K apart. When we detect that the return SS is on the LDT, we copy the IRET frame to the ministack and use the relevant alias to return to userspace. The ministacks are mapped readonly, so if IRET faults we promote #GP to #DF which is an IST vector and thus has its own stack; we then do the fixup in the #DF handler. (Making #GP an IST exception would make the msr_safe functions unsafe in NMI/MC context, and quite possibly have other effects.) Special thanks to: - Andy Lutomirski, for the suggestion of using very small stack slots and copy (as opposed to map) the IRET frame there, and for the suggestion to mark them readonly and let the fault promote to #DF. - Konrad Wilk for paravirt fixup and testing. - Borislav Petkov for testing help and useful comments. Reported-by: Brian Gerst Signed-off-by: H. Peter Anvin Link: http://lkml.kernel.org/r/1398816946-3351-1-git-send-email-hpa@linux.intel.com Cc: Konrad Rzeszutek Wilk Cc: Borislav Petkov Cc: Andrew Lutomriski Cc: Linus Torvalds Cc: Dirk Hohndel Cc: Arjan van de Ven Cc: comex Cc: Alexander van Heukelum Cc: Boris Ostrovsky Cc: # consider after upstream merge --- Documentation/x86/x86_64/mm.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt index c584a51..afe68dd 100644 --- a/Documentation/x86/x86_64/mm.txt +++ b/Documentation/x86/x86_64/mm.txt @@ -12,6 +12,8 @@ ffffc90000000000 - ffffe8ffffffffff (=45 bits) vmalloc/ioremap space ffffe90000000000 - ffffe9ffffffffff (=40 bits) hole ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB) ... unused hole ... +ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks +... unused hole ... ffffffff80000000 - ffffffffa0000000 (=512 MB) kernel text mapping, from phys 0 ffffffffa0000000 - ffffffffff5fffff (=1525 MB) module mapping space ffffffffff600000 - ffffffffffdfffff (=8 MB) vsyscalls -- cgit v1.1 From 2a2c74b2efcb1a0ca3fdcb5fbb96ad8de6a29177 Mon Sep 17 00:00:00 2001 From: Alistair Popple Date: Thu, 6 Mar 2014 14:52:27 +1100 Subject: IBM Akebono: Add the Akebono platform This patch adds support for the IBM Akebono board. Signed-off-by: Alistair Popple Signed-off-by: Benjamin Herrenschmidt --- .../devicetree/bindings/powerpc/4xx/akebono.txt | 54 ++++++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 Documentation/devicetree/bindings/powerpc/4xx/akebono.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/powerpc/4xx/akebono.txt b/Documentation/devicetree/bindings/powerpc/4xx/akebono.txt new file mode 100644 index 0000000..db93921 --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/4xx/akebono.txt @@ -0,0 +1,54 @@ + +IBM Akebono board device tree +============================= + +The IBM Akebono board is a development board for the PPC476GTR SoC. + +0) The root node + + Required properties: + + - model : "ibm,akebono". + - compatible : "ibm,akebono" , "ibm,476gtr". + +1.a) The Secure Digital Host Controller Interface (SDHCI) node + + Represent the Secure Digital Host Controller Interfaces. + + Required properties: + + - compatible : should be "ibm,476gtr-sdhci","generic-sdhci". + - reg : should contain the SDHCI registers location and length. + - interrupt-parent : a phandle for the interrupt controller. + - interrupts : should contain the SDHCI interrupt. + +1.b) The Advanced Host Controller Interface (AHCI) SATA node + + Represents the advanced host controller SATA interface. + + Required properties: + + - compatible : should be "ibm,476gtr-ahci". + - reg : should contain the AHCI registers location and length. + - interrupt-parent : a phandle for the interrupt controller. + - interrupts : should contain the AHCI interrupt. + +1.c) The FPGA node + + The Akebono board stores some board information such as the revision + number in an FPGA which is represented by this node. + + Required properties: + + - compatible : should be "ibm,akebono-fpga". + - reg : should contain the FPGA registers location and length. + +1.d) The AVR node + + The Akebono board has an Atmel AVR microprocessor attached to the I2C + bus as a power controller for the board. + + Required properties: + + - compatible : should be "ibm,akebono-avr". + - reg : should contain the I2C bus address for the AVR. -- cgit v1.1 From e2c37d908336dc27c8b405f063c2a163124947fa Mon Sep 17 00:00:00 2001 From: Alistair Popple Date: Thu, 6 Mar 2014 14:52:28 +1100 Subject: powerpc: Added PCI MSI support using the HSTA module The PPC476GTR SoC supports message signalled interrupts (MSI) by writing to special addresses within the High Speed Transfer Assist (HSTA) module. This patch adds support for PCI MSI with a new system device. The DMA window is also updated to allow access to the entire 42-bit address range to allow PCI devices write access to the HSTA module. Signed-off-by: Alistair Popple Signed-off-by: Benjamin Herrenschmidt --- .../devicetree/bindings/powerpc/4xx/hsta.txt | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 Documentation/devicetree/bindings/powerpc/4xx/hsta.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/powerpc/4xx/hsta.txt b/Documentation/devicetree/bindings/powerpc/4xx/hsta.txt new file mode 100644 index 0000000..c737c83 --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/4xx/hsta.txt @@ -0,0 +1,19 @@ + +ppc476gtr High Speed Serial Assist (HSTA) node +============================================== + +The 476gtr SoC contains a high speed serial assist module attached +between the plb4 and plb6 system buses to provide high speed data +transfer between memory and system peripherals as well as support for +PCI message signalled interrupts. + +Currently only the MSI support is used by Linux using the following +device tree entries: + +Require properties: +- compatible : "ibm,476gtr-hsta-msi", "ibm,hsta-msi" +- reg : register mapping for the HSTA MSI space +- interrupt-parent : parent controller for mapping interrupts +- interrupts : ordered interrupt mapping for each MSI in the register + space. The first interrupt should be associated with a + register offset of 0x00, the second to 0x10, etc. -- cgit v1.1 From dec102aa9ac112d66133314815d20233c96ad749 Mon Sep 17 00:00:00 2001 From: Viresh Kumar Date: Tue, 22 Apr 2014 10:42:05 +0530 Subject: cpufreq: Make linux-pm@vger.kernel.org official mailing list There has been confusion all the time about which mailing list to follow for cpufreq activities, linux-pm@vger.kernel.org or cpufreq@vger.kernel.org. Since patches sent to cpufreq@vger.kernel.org don't go to Patchwork which is a maintenance workflow problem, make linux-pm@vger.kernel.org the official mailing list for cpufreq stuff and remove all references of cpufreq@vger.kernel.org from kernel source. Later, we can request that the list be dropped entirely. Signed-off-by: Viresh Kumar [rjw: Changelog] Signed-off-by: Rafael J. Wysocki --- Documentation/ABI/testing/sysfs-devices-system-cpu | 4 ++-- Documentation/cpu-freq/index.txt | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index d5a0d33..acb9bfc 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -128,7 +128,7 @@ Description: Discover cpuidle policy and mechanism What: /sys/devices/system/cpu/cpu#/cpufreq/* Date: pre-git history -Contact: cpufreq@vger.kernel.org +Contact: linux-pm@vger.kernel.org Description: Discover and change clock speed of CPUs Clock scaling allows you to change the clock speed of the @@ -146,7 +146,7 @@ Description: Discover and change clock speed of CPUs What: /sys/devices/system/cpu/cpu#/cpufreq/freqdomain_cpus Date: June 2013 -Contact: cpufreq@vger.kernel.org +Contact: linux-pm@vger.kernel.org Description: Discover CPUs in the same CPU frequency coordination domain freqdomain_cpus is the list of CPUs (online+offline) that share diff --git a/Documentation/cpu-freq/index.txt b/Documentation/cpu-freq/index.txt index 3d0b915..dc024ab 100644 --- a/Documentation/cpu-freq/index.txt +++ b/Documentation/cpu-freq/index.txt @@ -35,8 +35,8 @@ Mailing List ------------ There is a CPU frequency changing CVS commit and general list where you can report bugs, problems or submit patches. To post a message, -send an email to cpufreq@vger.kernel.org, to subscribe go to -http://vger.kernel.org/vger-lists.html#cpufreq and follow the +send an email to linux-pm@vger.kernel.org, to subscribe go to +http://vger.kernel.org/vger-lists.html#linux-pm and follow the instructions there. Links -- cgit v1.1 From d052a3d6a7955f917fe940b1fecdaf20fa61efae Mon Sep 17 00:00:00 2001 From: Sebastian Reichel Date: Mon, 28 Apr 2014 16:07:26 +0200 Subject: ASoC: omap: rx51: Add DT support This patch adds device tree support to the Nokia N900 audio driver and adds documentation for the DT binding. Signed-off-by: Sebastian Reichel Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/nokia,rx51.txt | 27 ++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/nokia,rx51.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/nokia,rx51.txt b/Documentation/devicetree/bindings/sound/nokia,rx51.txt new file mode 100644 index 0000000..72f93d9 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nokia,rx51.txt @@ -0,0 +1,27 @@ +* Nokia N900 audio setup + +Required properties: +- compatible: Should contain "nokia,n900-audio" +- nokia,cpu-dai: phandle for the McBSP node +- nokia,audio-codec: phandles for the main TLV320AIC3X node and the + auxiliary TLV320AIC3X node (in this order) +- nokia,headphone-amplifier: phandle for the TPA6130A2 node +- tvout-selection-gpios: GPIO for tvout selection +- jack-detection-gpios: GPIO for jack detection +- eci-switch-gpios: GPIO for ECI (Enhancement Control Interface) switch +- speaker-amplifier-gpios: GPIO for speaker amplifier + +Example: + +sound { + compatible = "nokia,n900-audio"; + + nokia,cpu-dai = <&mcbsp2>; + nokia,audio-codec = <&tlv320aic3x>, <&tlv320aic3x_aux>; + nokia,headphone-amplifier = <&tpa6130a2>; + + tvout-selection-gpios = <&gpio2 8 GPIO_ACTIVE_HIGH>; /* 40 */ + jack-detection-gpios = <&gpio6 17 GPIO_ACTIVE_HIGH>; /* 177 */ + eci-switch-gpios = <&gpio6 22 GPIO_ACTIVE_HIGH>; /* 182 */ + speaker-amplifier-gpios = <&twl_gpio 7 GPIO_ACTIVE_HIGH>; +}; -- cgit v1.1 From af98715f28174fabea8f1bea3d297b8f0ad1f84b Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Tue, 15 Apr 2014 17:13:33 +0200 Subject: dma: mmp_pdma: Fix the #dma-channels DT property documentation The property is optional and defaults to 32. Document it as such. Cc: devicetree@vger.kernel.org Signed-off-by: Laurent Pinchart Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/dma/mmp-dma.txt | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/mmp-dma.txt b/Documentation/devicetree/bindings/dma/mmp-dma.txt index a4fa4ef..7a802f6 100644 --- a/Documentation/devicetree/bindings/dma/mmp-dma.txt +++ b/Documentation/devicetree/bindings/dma/mmp-dma.txt @@ -1,17 +1,20 @@ * MARVELL MMP DMA controller Marvell Peripheral DMA Controller -Used platfroms: pxa688, pxa910, pxa3xx, etc +Used platforms: pxa688, pxa910, pxa3xx, etc Required properties: - compatible: Should be "marvell,pdma-1.0" - reg: Should contain DMA registers location and length. - interrupts: Either contain all of the per-channel DMA interrupts or one irq for pdma device -- #dma-channels: Number of DMA channels supported by the controller. + +Optional properties: +- #dma-channels: Number of DMA channels supported by the controller (defaults + to 32 when not specified) "marvell,pdma-1.0" -Used platfroms: pxa25x, pxa27x, pxa3xx, pxa93x, pxa168, pxa910, pxa688. +Used platforms: pxa25x, pxa27x, pxa3xx, pxa93x, pxa168, pxa910, pxa688. Examples: @@ -45,7 +48,7 @@ pdma: dma-controller@d4000000 { Marvell Two Channel DMA Controller used specifically for audio -Used platfroms: pxa688, pxa910 +Used platforms: pxa688, pxa910 Required properties: - compatible: Should be "marvell,adma-1.0" or "marvell,pxa910-squ" -- cgit v1.1 From 6d48f44b7b2af67b33c1ae5994b8f642685c8bc8 Mon Sep 17 00:00:00 2001 From: Grygorii Strashko Date: Wed, 30 Apr 2014 15:23:33 +0300 Subject: mdio_bus: implement devm_mdiobus_alloc/devm_mdiobus_free Add a resource managed devm_mdiobus_alloc[_size]()/devm_mdiobus_free() to automatically clean up MDIO bus alocations made by MDIO drivers, thus leading to simplified MDIO drivers code. Cc: Florian Fainelli Cc: Sergei Shtylyov Acked-and-tested-by: Lad, Prabhakar Signed-off-by: Grygorii Strashko Signed-off-by: David S. Miller --- Documentation/driver-model/devres.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt index 4f7897e..c74e044 100644 --- a/Documentation/driver-model/devres.txt +++ b/Documentation/driver-model/devres.txt @@ -308,3 +308,8 @@ SLAVE DMA ENGINE SPI devm_spi_register_master() + +MDIO + devm_mdiobus_alloc() + devm_mdiobus_alloc_size() + devm_mdiobus_free() -- cgit v1.1 From f9748ef13b6a7dfe9fe9bcae8b3a8cbc10c1e188 Mon Sep 17 00:00:00 2001 From: Thierry Reding Date: Fri, 25 Apr 2014 17:10:05 +0200 Subject: gpio: Add missing device-managed documentation Add the GPIO-related device-managed functions to the list of functions in Documentation/driver-model/devres.txt. Signed-off-by: Thierry Reding Signed-off-by: Linus Walleij --- Documentation/driver-model/devres.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt index 4f7897e..8ff1167c 100644 --- a/Documentation/driver-model/devres.txt +++ b/Documentation/driver-model/devres.txt @@ -308,3 +308,8 @@ SLAVE DMA ENGINE SPI devm_spi_register_master() + +GPIO + devm_gpiod_get() + devm_gpiod_get_index() + devm_gpiod_put() -- cgit v1.1 From 888c9c7366cef902531f27f6aa5fb787c86810d4 Mon Sep 17 00:00:00 2001 From: Peter Meerwald Date: Wed, 5 Feb 2014 16:57:00 +0000 Subject: iio: Add ABI documentation for object and ambient modifiers Signed-off-by: Peter Meerwald Signed-off-by: Jonathan Cameron --- Documentation/ABI/testing/sysfs-bus-iio | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 6b74691..ca3d3b7 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -114,14 +114,17 @@ What: /sys/bus/iio/devices/iio:deviceX/in_temp_raw What: /sys/bus/iio/devices/iio:deviceX/in_tempX_raw What: /sys/bus/iio/devices/iio:deviceX/in_temp_x_raw What: /sys/bus/iio/devices/iio:deviceX/in_temp_y_raw -What: /sys/bus/iio/devices/iio:deviceX/in_temp_z_raw +What: /sys/bus/iio/devices/iio:deviceX/in_temp_ambient_raw +What: /sys/bus/iio/devices/iio:deviceX/in_temp_object_raw KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: Raw (unscaled no bias removal etc.) temperature measurement. If an axis is specified it generally means that the temperature sensor is associated with one part of a compound device (e.g. - a gyroscope axis). Units after application of scale and offset + a gyroscope axis). The ambient and object modifiers distinguish + between ambient (reference) and distant temperature for contact- + less measurements. Units after application of scale and offset are milli degrees Celsius. What: /sys/bus/iio/devices/iio:deviceX/in_tempX_input -- cgit v1.1 From 065b055dce0cbc2c14fa602cf5ab9938b6a08793 Mon Sep 17 00:00:00 2001 From: Peter Meerwald Date: Wed, 5 Feb 2014 16:54:00 +0000 Subject: iio: Add intensity including ir and both modifiers to ABI documentation ex-post intensity has been in use for a long time but never documented it is beneficial to document what this is supposed to be Signed-off-by: Peter Meerwald Signed-off-by: Jonathan Cameron --- Documentation/ABI/testing/sysfs-bus-iio | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index ca3d3b7..9669c1f 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -895,6 +895,16 @@ Description: on-chip EEPROM. After power-up or chip reset the device will automatically load the saved configuration. +What: /sys/.../iio:deviceX/in_intensityY_raw +What: /sys/.../iio:deviceX/in_intensityY_ir_raw +What: /sys/.../iio:deviceX/in_intensityY_both_raw +KernelVersion: 3.4 +Contact: linux-iio@vger.kernel.org +Description: + Unit-less light intensity. Modifiers both and ir indicate + that measurements contains visible and infrared light + components or just infrared light, respectively. + What: /sys/.../iio:deviceX/in_intensity_red_integration_time What: /sys/.../iio:deviceX/in_intensity_green_integration_time What: /sys/.../iio:deviceX/in_intensity_blue_integration_time -- cgit v1.1 From 994265f180791b7502cebd10dcb550d941e182c7 Mon Sep 17 00:00:00 2001 From: Peter Meerwald Date: Wed, 5 Feb 2014 16:54:00 +0000 Subject: iio: Add ABI documentation for illuminance has been in use for a long time, but never documented; state that this measurement should be in lux (drivers may feel different about this) Signed-off-by: Peter Meerwald Signed-off-by: Jonathan Cameron --- Documentation/ABI/testing/sysfs-bus-iio | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 9669c1f..a9757dc 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -895,6 +895,15 @@ Description: on-chip EEPROM. After power-up or chip reset the device will automatically load the saved configuration. +What: /sys/.../iio:deviceX/in_illuminanceY_input +What: /sys/.../iio:deviceX/in_illuminanceY_raw +What: /sys/.../iio:deviceX/in_illuminanceY_mean_raw +KernelVersion: 3.4 +Contact: linux-iio@vger.kernel.org +Description: + Illuminance measurement, units after application of scale + and offset are lux. + What: /sys/.../iio:deviceX/in_intensityY_raw What: /sys/.../iio:deviceX/in_intensityY_ir_raw What: /sys/.../iio:deviceX/in_intensityY_both_raw -- cgit v1.1 From a48839509ad4be29e64e245e752c529c125ede49 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Fri, 28 Mar 2014 16:20:28 -0500 Subject: dt/bindings: add binding for ARM Versatile character LCD Add binding doc for Versatile platforms character LCD controller interface. Signed-off-by: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/misc/arm-charlcd.txt | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 Documentation/devicetree/bindings/misc/arm-charlcd.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/misc/arm-charlcd.txt b/Documentation/devicetree/bindings/misc/arm-charlcd.txt new file mode 100644 index 0000000..e28e2aa --- /dev/null +++ b/Documentation/devicetree/bindings/misc/arm-charlcd.txt @@ -0,0 +1,18 @@ +ARM Versatile Character LCD +----------------------------------------------------- +This binding defines the character LCD interface found on ARM Versatile AB +and PB reference platforms. + +Required properties: +- compatible : "arm,versatile-clcd" +- reg : Location and size of character LCD registers + +Optional properties: +- interrupts - single interrupt for character LCD. The character LCD can + operate in polled mode without an interrupt. + +Example: + lcd@10008000 { + compatible = "arm,versatile-lcd"; + reg = <0x10008000 0x1000>; + }; -- cgit v1.1 From 3a8ab8af08cad8d3cf1ceff7e5a5da365ac6b63e Mon Sep 17 00:00:00 2001 From: Sebastian Reichel Date: Sat, 1 Mar 2014 01:07:54 +0100 Subject: Documentation: HSI: Add some general description for the HSI subsystem Add a document, which gives a rough introduction about what HSI is and how its handled by the Linux kernel. Signed-off-by: Sebastian Reichel Reviewed-by: Pavel Machek --- Documentation/hsi.txt | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) create mode 100644 Documentation/hsi.txt (limited to 'Documentation') diff --git a/Documentation/hsi.txt b/Documentation/hsi.txt new file mode 100644 index 0000000..6ac6cd5 --- /dev/null +++ b/Documentation/hsi.txt @@ -0,0 +1,75 @@ +HSI - High-speed Synchronous Serial Interface + +1. Introduction +~~~~~~~~~~~~~~~ + +High Speed Syncronous Interface (HSI) is a fullduplex, low latency protocol, +that is optimized for die-level interconnect between an Application Processor +and a Baseband chipset. It has been specified by the MIPI alliance in 2003 and +implemented by multiple vendors since then. + +The HSI interface supports full duplex communication over multiple channels +(typically 8) and is capable of reaching speeds up to 200 Mbit/s. + +The serial protocol uses two signals, DATA and FLAG as combined data and clock +signals and an additional READY signal for flow control. An additional WAKE +signal can be used to wakeup the chips from standby modes. The signals are +commonly prefixed by AC for signals going from the application die to the +cellular die and CA for signals going the other way around. + ++------------+ +---------------+ +| Cellular | | Application | +| Die | | Die | +| | - - - - - - CAWAKE - - - - - - >| | +| T|------------ CADATA ------------>|R | +| X|------------ CAFLAG ------------>|X | +| |<----------- ACREADY ------------| | +| | | | +| | | | +| |< - - - - - ACWAKE - - - - - - -| | +| R|<----------- ACDATA -------------|T | +| X|<----------- ACFLAG -------------|X | +| |------------ CAREADY ----------->| | +| | | | +| | | | ++------------+ +---------------+ + +2. HSI Subsystem in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~ + +In the Linux kernel the hsi subsystem is supposed to be used for HSI devices. +The hsi subsystem contains drivers for hsi controllers including support for +multi-port controllers and provides a generic API for using the HSI ports. + +It also contains HSI client drivers, which make use of the generic API to +implement a protocol used on the HSI interface. These client drivers can +use an arbitrary number of channels. + +3. hsi-char Device +~~~~~~~~~~~~~~~~~~ + +Each port automatically registers a generic client driver called hsi_char, +which provides a charecter device for userspace representing the HSI port. +It can be used to communicate via HSI from userspace. Userspace may +configure the hsi_char device using the following ioctl commands: + +* HSC_RESET: + - flush the HSI port + +* HSC_SET_PM + - enable or disable the client. + +* HSC_SEND_BREAK + - send break + +* HSC_SET_RX + - set RX configuration + +* HSC_GET_RX + - get RX configuration + +* HSC_SET_TX + - set TX configuration + +* HSC_GET_TX + - get TX configuration -- cgit v1.1 From 2779ac167b1a1bf8153dca9f3a141c6148c6b89f Mon Sep 17 00:00:00 2001 From: Michael Kerrisk Date: Fri, 2 May 2014 12:13:10 +0200 Subject: timer_stats/doc: Fix /proc/timer_stats documentation Documentation/timers/timer_stats.txt claims: "The readout of /proc/timer_stats automatically disables sampling. The sampled information is kept until a new sample period is started. This allows multiple readouts." Some simple testing shows that reading from /proc/timer_stats does not disable sampling. Looking back over past source code, it appears that it never did. Signed-off-by: Michael Kerrisk Cc: Randy Dunlap Link: http://lkml.kernel.org/r/53636FB6.9060407@gmail.com [ Small tidyup of the changelog. ] Signed-off-by: Ingo Molnar --- Documentation/timers/timer_stats.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/timers/timer_stats.txt b/Documentation/timers/timer_stats.txt index 8abd40b..de835ee 100644 --- a/Documentation/timers/timer_stats.txt +++ b/Documentation/timers/timer_stats.txt @@ -39,9 +39,9 @@ To stop a sample period issue: The statistics can be retrieved by: # cat /proc/timer_stats -The readout of /proc/timer_stats automatically disables sampling. The sampled -information is kept until a new sample period is started. This allows multiple -readouts. +While sampling is enabled, each readout from /proc/timer_stats will see +newly updated statistics. Once sampling is disabled, the sampled information +is kept until a new sample period is started. This allows multiple readouts. Sample output of /proc/timer_stats: -- cgit v1.1 From 5799d6d4cf86c11503aee909a1ec555453c7f22a Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Tue, 15 Apr 2014 17:00:02 +0200 Subject: Documentation: dt-bindings: reformat and order list of ahci-platform compatibles The ahci-platform.txt Device Tree binding documentation is gaining a growing number of compatible strings, and it will gain one more with the addition of the Marvell Armada 380 AHCI support. It is therefore time to reformat this list into a proper bullet list, and more importantly order it alphabetically; Signed-off-by: Thomas Petazzoni Acked-by: Andrew Lunn Acked-by: Jason Cooper Signed-off-by: Tejun Heo --- Documentation/devicetree/bindings/ata/ahci-platform.txt | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt index 48b285f..5598862 100644 --- a/Documentation/devicetree/bindings/ata/ahci-platform.txt +++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt @@ -4,10 +4,14 @@ SATA nodes are defined to describe on-chip Serial ATA controllers. Each SATA controller should have its own node. Required properties: -- compatible : compatible list, one of "snps,spear-ahci", - "snps,exynos5440-ahci", "ibm,476gtr-ahci", - "allwinner,sun4i-a10-ahci", "fsl,imx53-ahci" - "fsl,imx6q-ahci" or "snps,dwc-ahci" +- compatible : compatible string, one of: + - "allwinner,sun4i-a10-ahci" + - "fsl,imx53-ahci" + - "fsl,imx6q-ahci" + - "ibm,476gtr-ahci" + - "snps,dwc-ahci" + - "snps,exynos5440-ahci" + - "snps,spear-ahci" - interrupts : - reg : -- cgit v1.1 From a3464ed2f14d19ba923930f7c0c284499d64eb5b Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Tue, 15 Apr 2014 17:00:03 +0200 Subject: ata: ahci_mvebu: new driver for Marvell Armada 380 AHCI interfaces The Marvell Armada 380 SoC includes two AHCI compatible interfaces. However, like all DMA-capable Marvell interface, they require special handling to configure MBus windows. Therefore, this commit adds a new ahci_mvebu driver, which relies on the libahci_platform.c code recently introduced. Signed-off-by: Thomas Petazzoni Acked-by: Jason Cooper Signed-off-by: Tejun Heo --- Documentation/devicetree/bindings/ata/ahci-platform.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt index 5598862..d6b07e8 100644 --- a/Documentation/devicetree/bindings/ata/ahci-platform.txt +++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt @@ -9,6 +9,7 @@ Required properties: - "fsl,imx53-ahci" - "fsl,imx6q-ahci" - "ibm,476gtr-ahci" + - "marvell,armada-380-ahci" - "snps,dwc-ahci" - "snps,exynos5440-ahci" - "snps,spear-ahci" -- cgit v1.1 From dfee07cceff94af498a8465353554e0b63c3b152 Mon Sep 17 00:00:00 2001 From: Alexei Starovoitov Date: Thu, 1 May 2014 08:16:03 -0700 Subject: net: filter: doc: expand and improve BPF documentation In particular, this patch tries to clarify internal BPF calling convention and adds internal BPF examples, JIT guide, use cases. Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Signed-off-by: David S. Miller --- Documentation/networking/filter.txt | 158 +++++++++++++++++++++++++++++++++++- 1 file changed, 154 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt index 82e1cb0..748fd38 100644 --- a/Documentation/networking/filter.txt +++ b/Documentation/networking/filter.txt @@ -613,7 +613,7 @@ Some core changes of the new internal format: Therefore, BPF calling convention is defined as: - * R0 - return value from in-kernel function + * R0 - return value from in-kernel function, and exit value for BPF program * R1 - R5 - arguments from BPF program to in-kernel function * R6 - R9 - callee saved registers that in-kernel function will preserve * R10 - read-only frame pointer to access stack @@ -659,9 +659,140 @@ Some core changes of the new internal format: - Introduces bpf_call insn and register passing convention for zero overhead calls from/to other kernel functions: - After a kernel function call, R1 - R5 are reset to unreadable and R0 has a - return type of the function. Since R6 - R9 are callee saved, their state is - preserved across the call. + Before an in-kernel function call, the internal BPF program needs to + place function arguments into R1 to R5 registers to satisfy calling + convention, then the interpreter will take them from registers and pass + to in-kernel function. If R1 - R5 registers are mapped to CPU registers + that are used for argument passing on given architecture, the JIT compiler + doesn't need to emit extra moves. Function arguments will be in the correct + registers and BPF_CALL instruction will be JITed as single 'call' HW + instruction. This calling convention was picked to cover common call + situations without performance penalty. + + After an in-kernel function call, R1 - R5 are reset to unreadable and R0 has + a return value of the function. Since R6 - R9 are callee saved, their state + is preserved across the call. + + For example, consider three C functions: + + u64 f1() { return (*_f2)(1); } + u64 f2(u64 a) { return f3(a + 1, a); } + u64 f3(u64 a, u64 b) { return a - b; } + + GCC can compile f1, f3 into x86_64: + + f1: + movl $1, %edi + movq _f2(%rip), %rax + jmp *%rax + f3: + movq %rdi, %rax + subq %rsi, %rax + ret + + Function f2 in BPF may look like: + + f2: + bpf_mov R2, R1 + bpf_add R1, 1 + bpf_call f3 + bpf_exit + + If f2 is JITed and the pointer stored to '_f2'. The calls f1 -> f2 -> f3 and + returns will be seamless. Without JIT, __sk_run_filter() interpreter needs to + be used to call into f2. + + For practical reasons all BPF programs have only one argument 'ctx' which is + already placed into R1 (e.g. on __sk_run_filter() startup) and the programs + can call kernel functions with up to 5 arguments. Calls with 6 or more arguments + are currently not supported, but these restrictions can be lifted if necessary + in the future. + + On 64-bit architectures all register map to HW registers one to one. For + example, x86_64 JIT compiler can map them as ... + + R0 - rax + R1 - rdi + R2 - rsi + R3 - rdx + R4 - rcx + R5 - r8 + R6 - rbx + R7 - r13 + R8 - r14 + R9 - r15 + R10 - rbp + + ... since x86_64 ABI mandates rdi, rsi, rdx, rcx, r8, r9 for argument passing + and rbx, r12 - r15 are callee saved. + + Then the following internal BPF pseudo-program: + + bpf_mov R6, R1 /* save ctx */ + bpf_mov R2, 2 + bpf_mov R3, 3 + bpf_mov R4, 4 + bpf_mov R5, 5 + bpf_call foo + bpf_mov R7, R0 /* save foo() return value */ + bpf_mov R1, R6 /* restore ctx for next call */ + bpf_mov R2, 6 + bpf_mov R3, 7 + bpf_mov R4, 8 + bpf_mov R5, 9 + bpf_call bar + bpf_add R0, R7 + bpf_exit + + After JIT to x86_64 may look like: + + push %rbp + mov %rsp,%rbp + sub $0x228,%rsp + mov %rbx,-0x228(%rbp) + mov %r13,-0x220(%rbp) + mov %rdi,%rbx + mov $0x2,%esi + mov $0x3,%edx + mov $0x4,%ecx + mov $0x5,%r8d + callq foo + mov %rax,%r13 + mov %rbx,%rdi + mov $0x2,%esi + mov $0x3,%edx + mov $0x4,%ecx + mov $0x5,%r8d + callq bar + add %r13,%rax + mov -0x228(%rbp),%rbx + mov -0x220(%rbp),%r13 + leaveq + retq + + Which is in this example equivalent in C to: + + u64 bpf_filter(u64 ctx) + { + return foo(ctx, 2, 3, 4, 5) + bar(ctx, 6, 7, 8, 9); + } + + In-kernel functions foo() and bar() with prototype: u64 (*)(u64 arg1, u64 + arg2, u64 arg3, u64 arg4, u64 arg5); will receive arguments in proper + registers and place their return value into '%rax' which is R0 in BPF. + Prologue and epilogue are emitted by JIT and are implicit in the + interpreter. R0-R5 are scratch registers, so BPF program needs to preserve + them across the calls as defined by calling convention. + + For example the following program is invalid: + + bpf_mov R1, 1 + bpf_call foo + bpf_mov R0, R1 + bpf_exit + + After the call the registers R1-R5 contain junk values and cannot be read. + In the future a BPF verifier can be used to validate internal BPF programs. Also in the new design, BPF is limited to 4096 insns, which means that any program will terminate quickly and will only call a fixed number of kernel @@ -676,6 +807,25 @@ A program, that is translated internally consists of the following elements: op:16, jt:8, jf:8, k:32 ==> op:8, a_reg:4, x_reg:4, off:16, imm:32 +So far 87 internal BPF instructions were implemented. 8-bit 'op' opcode field +has room for new instructions. Some of them may use 16/24/32 byte encoding. New +instructions must be multiple of 8 bytes to preserve backward compatibility. + +Internal BPF is a general purpose RISC instruction set. Not every register and +every instruction are used during translation from original BPF to new format. +For example, socket filters are not using 'exclusive add' instruction, but +tracing filters may do to maintain counters of events, for example. Register R9 +is not used by socket filters either, but more complex filters may be running +out of registers and would have to resort to spill/fill to stack. + +Internal BPF can used as generic assembler for last step performance +optimizations, socket filters and seccomp are using it as assembler. Tracing +filters may use it as assembler to generate code from kernel. In kernel usage +may not be bounded by security considerations, since generated internal BPF code +may be optimizing internal code path and not being exposed to the user space. +Safety of internal BPF can come from a verifier (TBD). In such use cases as +described, it may be used as safe instruction set. + Just like the original BPF, the new format runs within a controlled environment, is deterministic and the kernel can easily prove that. The safety of the program can be determined in two steps: first step does depth-first-search to disallow -- cgit v1.1 From 122b250511e28c87043a6583988d4616895b5b53 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Fri, 25 Apr 2014 16:59:00 +0200 Subject: drm/i915: Integrate cmd parser kerneldoc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Ville noticed that we have this nice kerneldoc but it's not integrated anywhere. Fix this asap! Cc: Ville Syrjälä Cc: Brad Volkin Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter --- Documentation/DocBook/drm.tmpl | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 83dd0b0..1c51d43 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -2942,6 +2942,11 @@ int num_ioctls; This sections covers all things related to the GEM implementation in the i915 driver. + + Batchbuffer Parsing +!Pdrivers/gpu/drm/i915/i915_cmd_parser.c batch buffer command parser +!Idrivers/gpu/drm/i915/i915_cmd_parser.c + -- cgit v1.1 From 2e33def0339c78d33312a4e1d6d85978920c3669 Mon Sep 17 00:00:00 2001 From: Javier Martinez Canillas Date: Thu, 10 Apr 2014 01:30:06 +0200 Subject: dma-buf: update exp_name when using dma_buf_export() commit c0b00a5 ("dma-buf: update debugfs output") modified the default exporter name to be the KBUILD_MODNAME pre-processor macro instead of __FILE__ but the documentation was not updated. Also the "Supporting existing mmap interfaces in exporters" section title seems wrong since talks about the interface used by importers. Signed-off-by: Javier Martinez Canillas Reviewed-by: Daniel Vetter Signed-off-by: Jiri Kosina --- Documentation/dma-buf-sharing.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 505e711..7d61cef 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -66,7 +66,7 @@ The dma_buf buffer sharing API usage contains the following steps: Exporting modules which do not wish to provide any specific name may use the helper define 'dma_buf_export()', with the same arguments as above, but - without the last argument; a __FILE__ pre-processor directive will be + without the last argument; a KBUILD_MODNAME pre-processor directive will be inserted in place of 'exp_name' instead. 2. Userspace gets a handle to pass around to potential buffer-users @@ -352,7 +352,7 @@ Being able to mmap an export dma-buf buffer object has 2 main use-cases: No special interfaces, userspace simply calls mmap on the dma-buf fd. -2. Supporting existing mmap interfaces in exporters +2. Supporting existing mmap interfaces in importers Similar to the motivation for kernel cpu access it is again important that the userspace code of a given importing subsystem can use the same interfaces -- cgit v1.1 From c98be0c96db00e9b6b02d31e0fa7590c54cdaaac Mon Sep 17 00:00:00 2001 From: Carlos Garcia Date: Fri, 4 Apr 2014 22:31:00 -0400 Subject: doc: spelling error changes Fixed multiple spelling errors. Acked-by: Randy Dunlap Signed-off-by: Carlos E. Garcia Signed-off-by: Jiri Kosina --- Documentation/DMA-attributes.txt | 2 +- Documentation/devicetree/bindings/arm/omap/omap.txt | 2 +- Documentation/devicetree/bindings/bus/mvebu-mbus.txt | 2 +- Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt | 2 +- Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt | 2 +- Documentation/devicetree/bindings/mmc/samsung-sdhci.txt | 2 +- Documentation/devicetree/bindings/mtd/gpmc-nand.txt | 2 +- Documentation/devicetree/bindings/mtd/gpmc-nor.txt | 2 +- Documentation/devicetree/bindings/mtd/gpmc-onenand.txt | 2 +- .../devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt | 12 ++++++------ Documentation/devicetree/bindings/powerpc/4xx/reboot.txt | 2 +- Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt | 2 +- Documentation/devicetree/bindings/regulator/regulator.txt | 2 +- Documentation/devicetree/bindings/spi/spi-bus.txt | 2 +- Documentation/dma-buf-sharing.txt | 2 +- Documentation/dynamic-debug-howto.txt | 2 +- Documentation/edac.txt | 2 +- Documentation/fb/sm501.txt | 2 +- Documentation/fb/sstfb.txt | 2 +- Documentation/filesystems/proc.txt | 4 ++-- Documentation/filesystems/sharedsubtree.txt | 2 +- Documentation/gpio/consumer.txt | 2 +- Documentation/hid/uhid.txt | 2 +- Documentation/input/alps.txt | 2 +- Documentation/input/input.txt | 2 +- Documentation/mtd/nand/pxa3xx-nand.txt | 2 +- Documentation/networking/can.txt | 2 +- Documentation/networking/dccp.txt | 2 +- Documentation/powerpc/transactional_memory.txt | 2 +- Documentation/rbtree.txt | 2 +- Documentation/rfkill.txt | 2 +- Documentation/robust-futexes.txt | 2 +- Documentation/s390/monreader.txt | 2 +- Documentation/security/Yama.txt | 2 +- Documentation/sound/alsa/ALSA-Configuration.txt | 4 ++-- Documentation/trace/events.txt | 2 +- Documentation/usb/mass-storage.txt | 2 +- Documentation/virtual/kvm/api.txt | 2 +- Documentation/vm/transhuge.txt | 4 ++-- Documentation/x86/earlyprintk.txt | 2 +- Documentation/x86/i386/IO-APIC.txt | 2 +- 41 files changed, 49 insertions(+), 49 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt index cc2450d..18dc52c 100644 --- a/Documentation/DMA-attributes.txt +++ b/Documentation/DMA-attributes.txt @@ -98,5 +98,5 @@ DMA_ATTR_FORCE_CONTIGUOUS By default DMA-mapping subsystem is allowed to assemble the buffer allocated by dma_alloc_attrs() function from individual pages if it can be mapped as contiguous chunk into device dma address space. By -specifing this attribute the allocated buffer is forced to be contiguous +specifying this attribute the allocated buffer is forced to be contiguous also in physical memory. diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index af9b4a0..aa719623 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -114,5 +114,5 @@ Boards: - AM43x EPOS EVM compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43" -- DRA7 EVM: Software Developement Board for DRA7XX +- DRA7 EVM: Software Development Board for DRA7XX compatible = "ti,dra7-evm", "ti,dra7" diff --git a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt index 7586fb6..5fa44f5 100644 --- a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt +++ b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt @@ -197,7 +197,7 @@ to be set by the operating system and that are guaranteed to be free of overlaps with one another or with the system memory ranges. Each entry in the property refers to exactly one window. If the operating system -choses to use a different set of mbus windows, it must ensure that any address +chooses to use a different set of mbus windows, it must ensure that any address translations performed from downstream devices are adapted accordingly. The operating system may insert additional mbus windows that do not conflict diff --git a/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt index 3ddc7cc..c306a2d0 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt @@ -54,7 +54,7 @@ Optional device specific properties: IO 8-15 are bank 2. These chips have two different interrupt outputs: One for bank 1 and another for bank 2. If irq-mirror is set, both interrupts are generated regardless of the bank that an input change - occured on. If it is not set, the interrupt are only generated for the + occurred on. If it is not set, the interrupt are only generated for the bank they belong to. On devices with only one interrupt output this property is useless. diff --git a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt index b8653ea..e5bc49f 100644 --- a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt +++ b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt @@ -12,7 +12,7 @@ extensions to the Synopsys Designware Mobile Storage Host Controller. Required Properties: * compatible: should be one of the following. - - "hisilicon,hi4511-dw-mshc": for controllers with hi4511 specific extentions. + - "hisilicon,hi4511-dw-mshc": for controllers with hi4511 specific extensions. Example: diff --git a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt index 328e990..42e0a9af 100644 --- a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt +++ b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt @@ -3,7 +3,7 @@ Samsung's SDHCI controller is used as a connectivity interface with external MMC, SD and eMMC storage mediums. This file documents differences between the core mmc properties described by mmc.txt and the properties used by the -Samsung implmentation of the SDHCI controller. +Samsung implementation of the SDHCI controller. Required SoC Specific Properties: - compatible: should be one of the following diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt index 5e1f31b..eb05255 100644 --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt @@ -43,7 +43,7 @@ Optional properties: ELM hardware engines should specify this device node in .dtsi Using ELM for ECC error correction frees some CPU cycles. -For inline partiton table parsing (optional): +For inline partition table parsing (optional): - #address-cells: should be set to 1 - #size-cells: should be set to 1 diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nor.txt b/Documentation/devicetree/bindings/mtd/gpmc-nor.txt index 420b3ab..4828c17 100644 --- a/Documentation/devicetree/bindings/mtd/gpmc-nor.txt +++ b/Documentation/devicetree/bindings/mtd/gpmc-nor.txt @@ -30,7 +30,7 @@ Optional properties: - gpmc,XXX Additional GPMC timings and settings parameters. See Documentation/devicetree/bindings/bus/ti-gpmc.txt -Optional properties for partiton table parsing: +Optional properties for partition table parsing: - #address-cells: should be set to 1 - #size-cells: should be set to 1 diff --git a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt index b752942..5d8fa52 100644 --- a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt +++ b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt @@ -17,7 +17,7 @@ Optional properties: - dma-channel: DMA Channel index -For inline partiton table parsing (optional): +For inline partition table parsing (optional): - #address-cells: should be set to 1 - #size-cells: should be set to 1 diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt index c119deb..54a6e82 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt @@ -73,9 +73,9 @@ Optional Properties (for standard pins): Otherwise: 0: fast slew rate 1: normal slew rate -- input-enable: No arguements. Enable input (does not affect +- input-enable: No arguments. Enable input (does not affect output.) -- input-disable: No arguements. Disable input (does not affect +- input-disable: No arguments. Disable input (does not affect output.) - drive-strength: Integer. Drive strength in mA. Valid values are 2, 4, 6, 8, 10, 12, 14, 16 mA. @@ -99,9 +99,9 @@ Optional Properties (for I2C pins): Otherwise: 0: fast slew rate 1: normal slew rate -- input-enable: No arguements. Enable input (does not affect +- input-enable: No arguments. Enable input (does not affect output.) -- input-disable: No arguements. Disable input (does not affect +- input-disable: No arguments. Disable input (does not affect output.) Optional Properties (for HDMI pins): @@ -111,9 +111,9 @@ Optional Properties (for HDMI pins): - slew-rate: Integer. Controls slew rate. 0: Standard(100kbps)& Fast(400kbps) mode 1: Highspeed (3.4Mbps) mode -- input-enable: No arguements. Enable input (does not affect +- input-enable: No arguments. Enable input (does not affect output.) -- input-disable: No arguements. Disable input (does not affect +- input-disable: No arguments. Disable input (does not affect output.) Example: diff --git a/Documentation/devicetree/bindings/powerpc/4xx/reboot.txt b/Documentation/devicetree/bindings/powerpc/4xx/reboot.txt index d721726..5bc6355 100644 --- a/Documentation/devicetree/bindings/powerpc/4xx/reboot.txt +++ b/Documentation/devicetree/bindings/powerpc/4xx/reboot.txt @@ -1,7 +1,7 @@ Reboot property to control system reboot on PPC4xx systems: By setting "reset_type" to one of the following values, the default -software reset mechanism may be overidden. Here the possible values of +software reset mechanism may be overridden. Here the possible values of "reset_type": 1 - PPC4xx core reset diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt b/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt index 9d54eb5..18a8810 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt @@ -82,7 +82,7 @@ PROPERTIES Which event source asserted the interrupt is captured in an EPU Interrupt Status Register (EPISR0,EPISR1). - Interrupt numbers are lised in order (perfmon, event0, event1). + Interrupt numbers are listed in order (perfmon, event0, event1). - interrupt-parent Usage: required diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt index e2c7f1e..8607433 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.txt +++ b/Documentation/devicetree/bindings/regulator/regulator.txt @@ -12,7 +12,7 @@ Optional properties: - 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) - For hardwares which support disabling ramp rate, it should be explicitly + For hardware which supports disabling ramp rate, it should be explicitly intialised to zero (regulator-ramp-delay = <0>) for disabling ramp delay. - regulator-enable-ramp-delay: The time taken, in microseconds, for the supply rail to reach the target voltage, plus/minus whatever tolerance the board diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt b/Documentation/devicetree/bindings/spi/spi-bus.txt index e5a4d1b..cc128ae 100644 --- a/Documentation/devicetree/bindings/spi/spi-bus.txt +++ b/Documentation/devicetree/bindings/spi/spi-bus.txt @@ -61,7 +61,7 @@ contain the following properties. used for MISO. Defaults to 1 if not present. Some SPI controllers and devices support Dual and Quad SPI transfer mode. -It allows data in SPI system transfered in 2 wires(DUAL) or 4 wires(QUAD). +It allows data in the SPI system to be transferred in 2 wires(DUAL) or 4 wires(QUAD). Now the value that spi-tx-bus-width and spi-rx-bus-width can receive is only 1(SINGLE), 2(DUAL) and 4(QUAD). Dual/Quad mode is not allowed when 3-wire mode is used. diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 7d61cef..67a4087 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -217,7 +217,7 @@ NOTES: and then allow further {map,unmap}_dma_buf operations from any buffer-user from the migrated backing-storage. - If the exporter cannot fulfil the backing-storage constraints of the new + If the exporter cannot fulfill the backing-storage constraints of the new buffer-user device as requested, dma_buf_attach() would return an error to denote non-compatibility of the new buffer-sharing request with the current buffer. diff --git a/Documentation/dynamic-debug-howto.txt b/Documentation/dynamic-debug-howto.txt index 46325eb..9417871 100644 --- a/Documentation/dynamic-debug-howto.txt +++ b/Documentation/dynamic-debug-howto.txt @@ -321,7 +321,7 @@ nullarbor:~ # echo -n 'func svc_process -p' > nullarbor:~ # echo -n 'format "nfsd: READ" +p' > /dynamic_debug/control -// enable messages in files of which the pathes include string "usb" +// enable messages in files of which the paths include string "usb" nullarbor:~ # echo -n '*usb* +p' > /dynamic_debug/control // enable all messages diff --git a/Documentation/edac.txt b/Documentation/edac.txt index 56c7e93..8bdc07c 100644 --- a/Documentation/edac.txt +++ b/Documentation/edac.txt @@ -550,7 +550,7 @@ installs itself as: /sys/devices/systm/edac/test-instance in this directory are various controls, a symlink and one or more 'instance' -directorys. +directories. The standard default controls are: diff --git a/Documentation/fb/sm501.txt b/Documentation/fb/sm501.txt index 8d17aeb..187f3b3 100644 --- a/Documentation/fb/sm501.txt +++ b/Documentation/fb/sm501.txt @@ -3,7 +3,7 @@ Configuration: You can pass the following kernel command line options to sm501 videoframebuffer: sm501fb.bpp= SM501 Display driver: - Specifiy bits-per-pixel if not specified by 'mode' + Specify bits-per-pixel if not specified by 'mode' sm501fb.mode= SM501 Display driver: Specify resolution as diff --git a/Documentation/fb/sstfb.txt b/Documentation/fb/sstfb.txt index 550ca77..13db107 100644 --- a/Documentation/fb/sstfb.txt +++ b/Documentation/fb/sstfb.txt @@ -10,7 +10,7 @@ Introduction The main page is located at , and if you want the latest version, check out the CVS, as the driver is a work in progress, I feel uncomfortable with releasing tarballs of something - not completely working...Don't worry, it's still more than useable + not completely working...Don't worry, it's still more than usable (I eat my own dog food) Please read the Bug section, and report any success or failure to me diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index f00bee14..d4fa7f5 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -234,7 +234,7 @@ Table 1-2: Contents of the status files (as of 2.6.30-rc7) ShdPnd bitmap of shared pending signals for the process SigBlk bitmap of blocked signals SigIgn bitmap of ignored signals - SigCgt bitmap of catched signals + SigCgt bitmap of caught signals CapInh bitmap of inheritable capabilities CapPrm bitmap of permitted capabilities CapEff bitmap of effective capabilities @@ -300,7 +300,7 @@ Table 1-4: Contents of the stat files (as of 2.6.30-rc7) pending bitmap of pending signals blocked bitmap of blocked signals sigign bitmap of ignored signals - sigcatch bitmap of catched signals + sigcatch bitmap of caught signals wchan address where process went to sleep 0 (place holder) 0 (place holder) diff --git a/Documentation/filesystems/sharedsubtree.txt b/Documentation/filesystems/sharedsubtree.txt index 4ede421..32a173d 100644 --- a/Documentation/filesystems/sharedsubtree.txt +++ b/Documentation/filesystems/sharedsubtree.txt @@ -727,7 +727,7 @@ replicas continue to be exactly same. mkdir -p /tmp/m3 mount --rbind /root /tmp/m3 - I wont' draw the tree..but it has 24 vfsmounts + I won't draw the tree..but it has 24 vfsmounts at step i the number of vfsmounts is V[i] = i*V[i-1]. diff --git a/Documentation/gpio/consumer.txt b/Documentation/gpio/consumer.txt index e42f77d..0ff8eb0 100644 --- a/Documentation/gpio/consumer.txt +++ b/Documentation/gpio/consumer.txt @@ -41,7 +41,7 @@ Both functions return either a valid GPIO descriptor, or an error code checkable with IS_ERR() (they will never return a NULL pointer). -ENOENT will be returned if and only if no GPIO has been assigned to the device/function/index triplet, other error codes are used for cases where a GPIO has been assigned but an error -occured while trying to acquire it. This is useful to discriminate between mere +occurred while trying to acquire it. This is useful to discriminate between mere errors and an absence of GPIO for optional GPIO parameters. Device-managed variants of these functions are also defined: diff --git a/Documentation/hid/uhid.txt b/Documentation/hid/uhid.txt index dc35a2b..31cabfd 100644 --- a/Documentation/hid/uhid.txt +++ b/Documentation/hid/uhid.txt @@ -114,7 +114,7 @@ the request was handled successfully. read() ------ -read() will return a queued ouput report. These output reports can be of type +read() will return a queued output report. These output reports can be of type UHID_START, UHID_STOP, UHID_OPEN, UHID_CLOSE, UHID_OUTPUT or UHID_OUTPUT_EV. No reaction is required to any of them but you should handle them according to your needs. Only UHID_OUTPUT and UHID_OUTPUT_EV have payloads. diff --git a/Documentation/input/alps.txt b/Documentation/input/alps.txt index e544c7f..90bca6f 100644 --- a/Documentation/input/alps.txt +++ b/Documentation/input/alps.txt @@ -94,7 +94,7 @@ PS/2 packet format Note that the device never signals overflow condition. -ALPS Absolute Mode - Protocol Verion 1 +ALPS Absolute Mode - Protocol Version 1 -------------------------------------- byte 0: 1 0 0 0 1 x9 x8 x7 diff --git a/Documentation/input/input.txt b/Documentation/input/input.txt index 666c06c..0acfddb 100644 --- a/Documentation/input/input.txt +++ b/Documentation/input/input.txt @@ -226,7 +226,7 @@ And so on up to js31. ~~~~~~~~~~~ evdev is the generic input event interface. It passes the events generated in the kernel straight to the program, with timestamps. The -API is still evolving, but should be useable now. It's described in +API is still evolving, but should be usable now. It's described in section 5. This should be the way for GPM and X to get keyboard and mouse diff --git a/Documentation/mtd/nand/pxa3xx-nand.txt b/Documentation/mtd/nand/pxa3xx-nand.txt index 840fd41..1074cbc 100644 --- a/Documentation/mtd/nand/pxa3xx-nand.txt +++ b/Documentation/mtd/nand/pxa3xx-nand.txt @@ -48,7 +48,7 @@ configurable between two modes: 1) Hamming, 2) BCH. Note that the actual BCH mode: BCH-4 or BCH-8 will depend on the way the controller is configured to transfer the data. -In the BCH mode the ECC code will be calculated for each transfered chunk +In the BCH mode the ECC code will be calculated for each transferred chunk and expected to be located (when reading/programming) right after the spare bytes as the figure above shows. diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt index 0cbe6ec..988be27 100644 --- a/Documentation/networking/can.txt +++ b/Documentation/networking/can.txt @@ -706,7 +706,7 @@ solution for a couple of reasons: RX_NO_AUTOTIMER: Prevent automatically starting the timeout monitor. - RX_ANNOUNCE_RESUME: If passed at RX_SETUP and a receive timeout occured, a + RX_ANNOUNCE_RESUME: If passed at RX_SETUP and a receive timeout occurred, a RX_CHANGED message will be generated when the (cyclic) receive restarts. TX_RESET_MULTI_IDX: Reset the index for the multiple frame transmission. diff --git a/Documentation/networking/dccp.txt b/Documentation/networking/dccp.txt index bf5dbe3..55c575f 100644 --- a/Documentation/networking/dccp.txt +++ b/Documentation/networking/dccp.txt @@ -86,7 +86,7 @@ built-in CCIDs. DCCP_SOCKOPT_CCID is write-only and sets both the TX and RX CCIDs at the same time, combining the operation of the next two socket options. This option is -preferrable over the latter two, since often applications will use the same +preferable over the latter two, since often applications will use the same type of CCID for both directions; and mixed use of CCIDs is not currently well understood. This socket option takes as argument at least one uint8_t value, or an array of uint8_t values, which must match available CCIDS (see above). CCIDs diff --git a/Documentation/powerpc/transactional_memory.txt b/Documentation/powerpc/transactional_memory.txt index dc23e58..9791e98a 100644 --- a/Documentation/powerpc/transactional_memory.txt +++ b/Documentation/powerpc/transactional_memory.txt @@ -160,7 +160,7 @@ 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 +because 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 diff --git a/Documentation/rbtree.txt b/Documentation/rbtree.txt index 61b6c48..39873ef 100644 --- a/Documentation/rbtree.txt +++ b/Documentation/rbtree.txt @@ -255,7 +255,7 @@ However, rbtree can be augmented to store such interval ranges in a structured way making it possible to do efficient lookup and exact match. This "extra information" stored in each node is the maximum hi -(max_hi) value among all the nodes that are its descendents. This +(max_hi) value among all the nodes that are its descendants. This information can be maintained at each node just be looking at the node and its immediate children. And this will be used in O(log n) lookup for lowest match (lowest start address among all possible matches) diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt index f430004..427e897 100644 --- a/Documentation/rfkill.txt +++ b/Documentation/rfkill.txt @@ -21,7 +21,7 @@ aircraft. The rfkill subsystem has a concept of "hard" and "soft" block, which differ little in their meaning (block == transmitters off) but rather in whether they can be changed or not: - - hard block: read-only radio block that cannot be overriden by software + - hard block: read-only radio block that cannot be overridden by software - soft block: writable radio block (need not be readable) that is set by the system software. diff --git a/Documentation/robust-futexes.txt b/Documentation/robust-futexes.txt index 0a9446a..af6fce2 100644 --- a/Documentation/robust-futexes.txt +++ b/Documentation/robust-futexes.txt @@ -210,7 +210,7 @@ i386 and x86_64 syscalls are wired up at the moment, and Ulrich has tested the new glibc code (on x86_64 and i386), and it works for his robust-mutex testcases. -All other architectures should build just fine too - but they wont have +All other architectures should build just fine too - but they won't have the new syscalls yet. Architectures need to implement the new futex_atomic_cmpxchg_inatomic() diff --git a/Documentation/s390/monreader.txt b/Documentation/s390/monreader.txt index beeaa4b..d372958 100644 --- a/Documentation/s390/monreader.txt +++ b/Documentation/s390/monreader.txt @@ -10,7 +10,7 @@ Author: Gerald Schaefer (geraldsc@de.ibm.com) Description =========== This item delivers a new Linux API in the form of a misc char device that is -useable from user space and allows read access to the z/VM Monitor Records +usable from user space and allows read access to the z/VM Monitor Records collected by the *MONITOR System Service of z/VM. diff --git a/Documentation/security/Yama.txt b/Documentation/security/Yama.txt index dd908cf..227a63f 100644 --- a/Documentation/security/Yama.txt +++ b/Documentation/security/Yama.txt @@ -37,7 +37,7 @@ still work as root). In mode 1, software that has defined application-specific relationships between a debugging process and its inferior (crash handlers, etc), prctl(PR_SET_PTRACER, pid, ...) can be used. An inferior can declare which -other process (and its descendents) are allowed to call PTRACE_ATTACH +other process (and its descendants) are allowed to call PTRACE_ATTACH against it. Only one such declared debugging process can exists for each inferior at a time. For example, this is used by KDE, Chromium, and Firefox's crash handlers, and by Wine for allowing only Wine processes diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index b8dd0df..7ccf933 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -948,7 +948,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. avoided as much as possible... MORE NOTES ON "azx_get_response timeout" PROBLEMS: - On some hardwares, you may need to add a proper probe_mask option + On some hardware, you may need to add a proper probe_mask option to avoid the "azx_get_response timeout" problem above, instead. This occurs when the access to non-existing or non-working codec slot (likely a modem one) causes a stall of the communication via HD-audio @@ -1124,7 +1124,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. buggy_irq - Enable workaround for buggy interrupts on some motherboards (default yes on nForce chips, otherwise off) - buggy_semaphore - Enable workaround for hardwares with buggy + buggy_semaphore - Enable workaround for hardware with buggy semaphores (e.g. on some ASUS laptops) (default off) spdif_aclink - Use S/PDIF over AC-link instead of direct connection diff --git a/Documentation/trace/events.txt b/Documentation/trace/events.txt index c94435d..75d25a1 100644 --- a/Documentation/trace/events.txt +++ b/Documentation/trace/events.txt @@ -443,7 +443,7 @@ The following commands are supported: The following command creates a snapshot every time a block request queue is unplugged with a depth > 1. If you were tracing a set of events or functions at the time, the snapshot trace buffer would - capture those events when the trigger event occured: + capture those events when the trigger event occurred: # echo 'snapshot if nr_rq > 1' > \ /sys/kernel/debug/tracing/events/block/block_unplug/trigger diff --git a/Documentation/usb/mass-storage.txt b/Documentation/usb/mass-storage.txt index 59063ad..e89803a 100644 --- a/Documentation/usb/mass-storage.txt +++ b/Documentation/usb/mass-storage.txt @@ -13,7 +13,7 @@ operation. Note that the driver is slightly non-portable in that it assumes - a single memory/DMA buffer will be useable for bulk-in and bulk-out + a single memory/DMA buffer will be usable for bulk-in and bulk-out endpoints. With most device controllers this is not an issue, but there may be some with hardware restrictions that prevent a buffer from being used by more than one endpoint. diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index a9380ba5..fe97350 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -2066,7 +2066,7 @@ the "Server" class MMU emulation supported by KVM. This can in turn be used by userspace to generate the appropriate device-tree properties for the guest operating system. -The structure contains some global informations, followed by an +The structure contains some global information, followed by an array of supported segment page sizes: struct kvm_ppc_smmu_info { diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt index 4a63953..6b31cfb 100644 --- a/Documentation/vm/transhuge.txt +++ b/Documentation/vm/transhuge.txt @@ -360,13 +360,13 @@ on any tail page, would mean having to split all hugepages upfront in get_user_pages which is unacceptable as too many gup users are performance critical and they must work natively on hugepages like they work natively on hugetlbfs already (hugetlbfs is simpler because -hugetlbfs pages cannot be splitted so there wouldn't be requirement of +hugetlbfs pages cannot be split so there wouldn't be requirement of accounting the pins on the tail pages for hugetlbfs). If we wouldn't account the gup refcounts on the tail pages during gup, we won't know anymore which tail page is pinned by gup and which is not while we run split_huge_page. But we still have to add the gup pin to the head page too, to know when we can free the compound page in case it's never -splitted during its lifetime. That requires changing not just +split during its lifetime. That requires changing not just get_page, but put_page as well so that when put_page runs on a tail page (and only on a tail page) it will find its respective head page, and then it will decrease the head page refcount in addition to the diff --git a/Documentation/x86/earlyprintk.txt b/Documentation/x86/earlyprintk.txt index f19802c..688e3ee 100644 --- a/Documentation/x86/earlyprintk.txt +++ b/Documentation/x86/earlyprintk.txt @@ -33,7 +33,7 @@ and two USB cables, connected like this: ... ( If your system does not list a debug port capability then you probably - wont be able to use the USB debug key. ) + won't be able to use the USB debug key. ) b.) You also need a Netchip USB debug cable/key: diff --git a/Documentation/x86/i386/IO-APIC.txt b/Documentation/x86/i386/IO-APIC.txt index 30b4c71..15f5baf 100644 --- a/Documentation/x86/i386/IO-APIC.txt +++ b/Documentation/x86/i386/IO-APIC.txt @@ -87,7 +87,7 @@ your PCI configuration: echo -n pirq=; echo `scanpci | grep T_L | cut -c56-` | sed 's/ /,/g' -note that this script wont work if you have skipped a few slots or if your +note that this script won't work if you have skipped a few slots or if your board does not do default daisy-chaining. (or the IO-APIC has the PIRQ pins connected in some strange way). E.g. if in the above case you have your SCSI card (IRQ11) in Slot3, and have Slot1 empty: -- cgit v1.1 From 15a0b3fba4e6770a3a6ce488b8de1350cc6a4bed Mon Sep 17 00:00:00 2001 From: Ilya Dryomov Date: Mon, 7 Apr 2014 13:43:52 +0400 Subject: doc: printk-formats: do not mention casts for u64/s64 Do not mention casts for u64/s64. Complements commit 2a7930bd77fe ("Documentation/printk-formats.txt: No casts needed for u64/s64"). Signed-off-by: Ilya Dryomov Acked-by: Randy Dunlap Signed-off-by: Jiri Kosina --- Documentation/printk-formats.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt index 6f4eb32..b449821 100644 --- a/Documentation/printk-formats.txt +++ b/Documentation/printk-formats.txt @@ -199,11 +199,11 @@ struct va_format: Do not use this feature without some mechanism to verify the correctness of the format string and va_list arguments. -u64 SHOULD be printed with %llu/%llx, (unsigned long long): +u64 SHOULD be printed with %llu/%llx: printk("%llu", u64_var); -s64 SHOULD be printed with %lld/%llx, (long long): +s64 SHOULD be printed with %lld/%llx: printk("%lld", s64_var); -- cgit v1.1 From c1e0cffddfb6a4702a660922b84e5ee274812bfe Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Tue, 11 Mar 2014 11:23:48 +0100 Subject: dma: imx-sdma: Spelling s/determnine/determine/ Signed-off-by: Geert Uytterhoeven Cc: Rob Herring Cc: devicetree@vger.kernel.org Signed-off-by: Jiri Kosina --- Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt index ee9be99..e577196 100644 --- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt +++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt @@ -8,7 +8,7 @@ Required properties: "fsl,imx51-sdma" "fsl,imx53-sdma" "fsl,imx6q-sdma" - The -to variants should be preferred since they allow to determnine the + The -to variants should be preferred since they allow to determine the correct ROM script addresses needed for the driver to work without additional firmware. - reg : Should contain SDMA registers location and length -- cgit v1.1 From 53a848be0a65c6fb105eb5ecb8b8b3edfa0f91ad Mon Sep 17 00:00:00 2001 From: Rajendra Nayak Date: Thu, 10 Apr 2014 11:33:13 -0500 Subject: bus: omap_l3_noc: Add DRA7 interconnect error data DRA7 is distinctly different from OMAP4 in terms of masters and clock domain organization. There two main clock domains which is divided as follows: <0x44000000 0x1000000> is clk1 and clk2 is the sub clock domain <0x45000000 0x1000> is clk3 Add all the data needed to handle L3 error handling on DRA7 devices and mark clk2 as subdomain and provide a compatible flag for functionality. Other than the data difference the hardware blocks involved are essentially the same. Signed-off-by: Rajendra Nayak [nm@ti.com: bugfixes and generic improvements, documentation] Signed-off-by: Nishanth Menon Acked-by: Santosh Shilimkar Acked-by: Peter Ujfalusi Tested-by: Darren Etheridge Tested-by: Sekhar Nori --- Documentation/devicetree/bindings/arm/omap/l3-noc.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt index c0105de..45d0fc2 100644 --- a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt +++ b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt @@ -6,6 +6,7 @@ provided by Arteris. Required properties: - compatible : Should be "ti,omap3-l3-smx" for OMAP3 family Should be "ti,omap4-l3-noc" for OMAP4 family + Should be "ti,dra7-l3-noc" for DRA7 family - reg: Contains L3 register address range for each noc domain. - ti,hwmods: "l3_main_1", ... One hwmod for each noc domain. -- cgit v1.1 From 27b7d5f3cc49f2e5cd6c005d73696058b7140c5c Mon Sep 17 00:00:00 2001 From: Afzal Mohammed Date: Mon, 2 Dec 2013 17:48:57 +0530 Subject: bus: omap_l3_noc: Add AM4372 interconnect error data Add AM4372 information to handle L3 error. AM4372 has two clk domains 100f and 200s. Provide flagmux and data associated with it. NOTE: Timeout doesn't have STDERRLOG_MAIN register. And per hardware team, L3 timeout error cannot be cleared the normal way (by setting bit 31 in STDERRLOG_MAIN), instead it may be required to do system reset. L3 error handler can't help in such scenarios. Hence indicate timeout target offset as L3_TARGET_NOT_SUPPORTED as done for undocumented bits. Signed-off-by: Dave Gerlach Signed-off-by: Afzal Mohammed Signed-off-by: Sekhar Nori Signed-off-by: Nishanth Menon Acked-by: Santosh Shilimkar Acked-by: Peter Ujfalusi Tested-by: Darren Etheridge Tested-by: Sekhar Nori --- Documentation/devicetree/bindings/arm/omap/l3-noc.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt index 45d0fc2..974624e 100644 --- a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt +++ b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt @@ -7,6 +7,7 @@ Required properties: - compatible : Should be "ti,omap3-l3-smx" for OMAP3 family Should be "ti,omap4-l3-noc" for OMAP4 family Should be "ti,dra7-l3-noc" for DRA7 family + Should be "ti,am4372-l3-noc" for AM43 family - reg: Contains L3 register address range for each noc domain. - ti,hwmods: "l3_main_1", ... One hwmod for each noc domain. -- cgit v1.1 From 09af62ff184bfeae4a72874ab28ed637a2329ee4 Mon Sep 17 00:00:00 2001 From: Daniel Mack Date: Mon, 5 May 2014 11:49:22 +0200 Subject: ASoC: sta350: fix DT bindings document Fix a misleading property description, and denote the fact that st,output-conf and st,ch*-output-mapping have to be passed as /bits/ 8. Signed-off-by: Daniel Mack Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/st,sta350.txt | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/st,sta350.txt b/Documentation/devicetree/bindings/sound/st,sta350.txt index 9501888..ecd7a62 100644 --- a/Documentation/devicetree/bindings/sound/st,sta350.txt +++ b/Documentation/devicetree/bindings/sound/st,sta350.txt @@ -25,6 +25,7 @@ Optional properties: 2: 2 Channel (Full-Bridge) Power, 1 Channel FFX 3: 1 Channel Mono-Parallel If parameter is missing, mode 0 will be enabled. + This property has to be specified as '/bits/ 8' value. - st,ch1-output-mapping: Channel 1 output mapping - st,ch2-output-mapping: Channel 2 output mapping @@ -33,6 +34,7 @@ Optional properties: 1: Channel 2 2: Channel 3 If parameter is missing, channel 1 is choosen. + This properties have to be specified as '/bits/ 8' values. - st,thermal-warning-recover: If present, thermal warning recovery is enabled. @@ -82,7 +84,7 @@ Optional properties: If not present, preset DC coefficient is used. - st,invalid-input-detect-mute: - If not present, automatic invalid input detect mute is enabled. + If present, automatic invalid input detect mute is enabled. @@ -93,12 +95,12 @@ codec: sta350@38 { reg = <0x1c>; reset-gpios = <&gpio1 19 0>; power-down-gpios = <&gpio1 16 0>; - st,output-conf = <0x3>; // set output to 2-channel + st,output-conf = /bits/ 8 <0x3>; // set output to 2-channel // (full-bridge) power, // 2-channel data-out - st,ch1-output-mapping = <0>; // set channel 1 output ch 1 - st,ch2-output-mapping = <0>; // set channel 2 output ch 1 - st,ch3-output-mapping = <0>; // set channel 3 output ch 1 + st,ch1-output-mapping = /bits/ 8 <0>; // set channel 1 output ch 1 + st,ch2-output-mapping = /bits/ 8 <0>; // set channel 2 output ch 1 + st,ch3-output-mapping = /bits/ 8 <0>; // set channel 3 output ch 1 st,max-power-correction; // enables power bridge // correction for THD reduction // near maximum power output -- cgit v1.1 From 7c2fcccc323909c1a4e56b79fc882168a0880146 Mon Sep 17 00:00:00 2001 From: Daniel Mack Date: Mon, 5 May 2014 11:49:23 +0200 Subject: ASoC: sta350: add support for bits in miscellaneous registers Add support for RPDNEN, NSHHPEN, BRIDGOFF, CPWMEN and PNDLSL, and add DT bindings to access them. Signed-off-by: Daniel Mack Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/st,sta350.txt | 24 +++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/st,sta350.txt b/Documentation/devicetree/bindings/sound/st,sta350.txt index ecd7a62..b7e71bf 100644 --- a/Documentation/devicetree/bindings/sound/st,sta350.txt +++ b/Documentation/devicetree/bindings/sound/st,sta350.txt @@ -86,7 +86,29 @@ Optional properties: - st,invalid-input-detect-mute: If present, automatic invalid input detect mute is enabled. - + - st,activate-mute-output: + If present, a mute output will be activated in ase the volume will + reach a value lower than -76 dBFS. + + - st,bridge-immediate-off: + If present, the bridge will be switched off immediately after the + power-down-gpio goes low. Otherwise, the bridge will wait for 13 + million clock cycles to pass before shutting down. + + - st,noise-shape-dc-cut: + If present, the noise-shaping technique on the DC cutoff filter are + enabled. + + - st,powerdown-master-volume: + If present, the power-down pin and I2C power-down functions will + act on the master volume. Otherwise, the functions will act on the + mute commands. + + - st,powerdown-delay-divider: + If present, the bridge power-down time will be divided by the provided + value. If not specified, a divider of 1 will be used. Allowed values + are 1, 2, 4, 8, 16, 32, 64 and 128. + This property has to be specified as '/bits/ 8' value. Example: -- cgit v1.1 From 3bb40619aca84905f87dd6bc7f6dce9efb525f28 Mon Sep 17 00:00:00 2001 From: Brian Austin Date: Mon, 5 May 2014 15:09:09 -0500 Subject: ASoC: cs42l56: bindings: sound: Add bindings for CS42L56 CODEC This patch adds binding documentation for the Cirrus Logic CS42L56 Low Power Stereo I2C CODEC Signed-off-by: Brian Austin Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/cs42l56.txt | 63 ++++++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/cs42l56.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/cs42l56.txt b/Documentation/devicetree/bindings/sound/cs42l56.txt new file mode 100644 index 0000000..4feb0eb --- /dev/null +++ b/Documentation/devicetree/bindings/sound/cs42l56.txt @@ -0,0 +1,63 @@ +CS42L52 audio CODEC + +Required properties: + + - compatible : "cirrus,cs42l56" + + - reg : the I2C address of the device for I2C + + - VA-supply, VCP-supply, VLDO-supply : power supplies for the device, + as covered in Documentation/devicetree/bindings/regulator/regulator.txt. + +Optional properties: + + - cirrus,gpio-nreset : GPIO controller's phandle and the number + of the GPIO used to reset the codec. + + - cirrus,chgfreq-divisor : Values used to set the Charge Pump Frequency. + Allowable values of 0x00 through 0x0F. These are raw values written to the + register, not the actual frequency. The frequency is determined by the following. + Frequency = MCLK / 4 * (N+2) + N = chgfreq_val + MCLK = Where MCLK is the frequency of the mclk signal after the MCLKDIV2 circuit. + + - cirrus,ain1a-ref-cfg, ain1b-ref-cfg : boolean, If present, AIN1A or AIN1B are configured + as a pseudo-differential input referenced to AIN1REF/AIN3A. + + - cirrus,ain2a-ref-cfg, ain2b-ref-cfg : boolean, If present, AIN2A or AIN2B are configured + as a pseudo-differential input referenced to AIN2REF/AIN3B. + + - cirrus,micbias-lvl: Set the output voltage level on the MICBIAS Pin. + 0 = 0.5 x VA + 1 = 0.6 x VA + 2 = 0.7 x VA + 3 = 0.8 x VA + 4 = 0.83 x VA + 5 = 0.91 x VA + + - cirrus,adaptive-pwr-cfg : Configures how the power to the Headphone and Lineout + Amplifiers adapt to the output signal levels. + 0 = Adapt to Volume Mode. Voltage level determined by the sum of the relevant volume settings. + 1 = Fixed - Headphone and Line Amp supply = + or - VCP/2. + 2 = Fixed - Headphone and Line Amp supply = + or - VCP. + 3 = Adapted to Signal; Voltage level is dynamically determined by the output signal. + + - cirrus,hpf-left-freq, hpf-right-freq : Sets the corner frequency (-3dB point) for the internal High-Pass + Filter. + 0 = 1.8Hz + 1 = 119Hz + 2 = 236Hz + 3 = 464Hz + + +Example: + +codec: codec@4b { + compatible = "cirrus,cs42l56"; + reg = <0x4b>; + gpio-reset = <&gpio 10 0>; + cirrus,chgfreq-divisor = <0x05>; + cirrus.ain1_ref_cfg; + cirrus,micbias-lvl = <5>; + VA-supply = <®_audio>; +}; -- cgit v1.1 From 75bb34190809c2d5e9dca0d478f22ac7cba7ec0c Mon Sep 17 00:00:00 2001 From: Steffen Trumtrar Date: Tue, 15 Apr 2014 17:18:11 -0500 Subject: Documentation: dt: socfpga: add reset-cells property To be able to use the reset-controller framework, the property #reset-cells is mandatory. Signed-off-by: Steffen Trumtrar Signed-off-by: Dinh Nguyen --- Documentation/devicetree/bindings/arm/altera/socfpga-reset.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-reset.txt b/Documentation/devicetree/bindings/arm/altera/socfpga-reset.txt index ecdb57d..32c1c8b 100644 --- a/Documentation/devicetree/bindings/arm/altera/socfpga-reset.txt +++ b/Documentation/devicetree/bindings/arm/altera/socfpga-reset.txt @@ -3,9 +3,11 @@ Altera SOCFPGA Reset Manager Required properties: - compatible : "altr,rst-mgr" - reg : Should contain 1 register ranges(address and length) +- #reset-cells: 1 Example: rstmgr@ffd05000 { + #reset-cells = <1>; compatible = "altr,rst-mgr"; reg = <0xffd05000 0x1000>; }; -- cgit v1.1 From dd16fc489730205019b4bec1dbb20c28821c7ab6 Mon Sep 17 00:00:00 2001 From: Steffen Trumtrar Date: Tue, 15 Apr 2014 17:19:12 -0500 Subject: Documentation: dt: reset: move socfpga-reset Instead of having the documentation for the socfpga-reset controller in a vendor specific directory, move it to the reset folder to all the other reset drivers. Signed-off-by: Steffen Trumtrar Signed-off-by: Dinh Nguyen --- .../devicetree/bindings/arm/altera/socfpga-reset.txt | 13 ------------- Documentation/devicetree/bindings/reset/socfpga-reset.txt | 13 +++++++++++++ 2 files changed, 13 insertions(+), 13 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/altera/socfpga-reset.txt create mode 100644 Documentation/devicetree/bindings/reset/socfpga-reset.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-reset.txt b/Documentation/devicetree/bindings/arm/altera/socfpga-reset.txt deleted file mode 100644 index 32c1c8b..0000000 --- a/Documentation/devicetree/bindings/arm/altera/socfpga-reset.txt +++ /dev/null @@ -1,13 +0,0 @@ -Altera SOCFPGA Reset Manager - -Required properties: -- compatible : "altr,rst-mgr" -- reg : Should contain 1 register ranges(address and length) -- #reset-cells: 1 - -Example: - rstmgr@ffd05000 { - #reset-cells = <1>; - compatible = "altr,rst-mgr"; - reg = <0xffd05000 0x1000>; - }; diff --git a/Documentation/devicetree/bindings/reset/socfpga-reset.txt b/Documentation/devicetree/bindings/reset/socfpga-reset.txt new file mode 100644 index 0000000..32c1c8b --- /dev/null +++ b/Documentation/devicetree/bindings/reset/socfpga-reset.txt @@ -0,0 +1,13 @@ +Altera SOCFPGA Reset Manager + +Required properties: +- compatible : "altr,rst-mgr" +- reg : Should contain 1 register ranges(address and length) +- #reset-cells: 1 + +Example: + rstmgr@ffd05000 { + #reset-cells = <1>; + compatible = "altr,rst-mgr"; + reg = <0xffd05000 0x1000>; + }; -- cgit v1.1 From 8cb289ed60668d3350dda5aa19b4fa1dce1c07f1 Mon Sep 17 00:00:00 2001 From: Dinh Nguyen Date: Wed, 16 Apr 2014 15:05:15 -0500 Subject: ARM: socfpga: dts: Add div-reg to the main_pll clocks The mpu_clk, main_clk, and dbg_base_clk outputs from the main PLL go through a pre-divider. Update socfpga.dtsi to represent those dividers for these clocks. Re-use the "div-reg" property that was used for the socfpga-gate-clock as this is the same thing. Also update the documentation. Signed-off-by: Dinh Nguyen --- Documentation/devicetree/bindings/clock/altr_socfpga.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/altr_socfpga.txt b/Documentation/devicetree/bindings/clock/altr_socfpga.txt index 5dfd145..f72e80e 100644 --- a/Documentation/devicetree/bindings/clock/altr_socfpga.txt +++ b/Documentation/devicetree/bindings/clock/altr_socfpga.txt @@ -21,8 +21,8 @@ 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. +- div-reg : For "socfpga-gate-clk" and "socfpga-periph-clock", div-reg contains + the divider register, bit shift, and width. - clk-phase : For the sdmmc_clk, contains the value of the clock phase that controls the SDMMC CIU clock. The first value is the clk_sample(smpsel), and the second value is the cclk_in_drv(drvsel). The clk-phase is used to enable the correct -- cgit v1.1 From e029ae5b787e08e976a683c6a45fac20fc227447 Mon Sep 17 00:00:00 2001 From: Thomas Huth Date: Wed, 26 Mar 2014 16:11:54 +0100 Subject: KVM: s390: Add clock comparator and CPU timer IRQ injection Add an interface to inject clock comparator and CPU timer interrupts into the guest. This is needed for handling the external interrupt interception. Signed-off-by: Thomas Huth Reviewed-by: David Hildenbrand Reviewed-by: Cornelia Huck Signed-off-by: Christian Borntraeger --- Documentation/virtual/kvm/api.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 2014ff1..0581f6c 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -2211,6 +2211,8 @@ KVM_S390_SIGP_STOP (vcpu) - sigp restart KVM_S390_PROGRAM_INT (vcpu) - program check; code in parm KVM_S390_SIGP_SET_PREFIX (vcpu) - sigp set prefix; prefix address in parm KVM_S390_RESTART (vcpu) - restart +KVM_S390_INT_CLOCK_COMP (vcpu) - clock comparator interrupt +KVM_S390_INT_CPU_TIMER (vcpu) - CPU timer interrupt KVM_S390_INT_VIRTIO (vm) - virtio external interrupt; external interrupt parameters in parm and parm64 KVM_S390_INT_SERVICE (vm) - sclp external interrupt; sclp parameter in parm -- cgit v1.1 From 08593fa6e4424d077ef0b02ecff77428a9f4ac00 Mon Sep 17 00:00:00 2001 From: George Cherian Date: Wed, 19 Mar 2014 15:39:59 +0530 Subject: doc: Add "ti,am437x-dwc3" comaptible for dwc3 glue Add the compatible "ti,am437x-dwc3" for dwc3 glue driver. Signed-off-by: George Cherian Acked-by: Roger Quadros Acked-by: Felipe Balbi Signed-off-by: Tony Lindgren --- Documentation/devicetree/bindings/usb/omap-usb.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt index 38b2fae..38d9bb8 100644 --- a/Documentation/devicetree/bindings/usb/omap-usb.txt +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt @@ -44,7 +44,9 @@ Board specific device node entry }; OMAP DWC3 GLUE - - compatible : Should be "ti,dwc3" + - compatible : Should be + * "ti,dwc3" for OMAP5 and DRA7 + * "ti,am437x-dwc3" for AM437x - ti,hwmods : Should be "usb_otg_ss" - reg : Address and length of the register set for the device. - interrupts : The irq number of this device that is used to interrupt the -- cgit v1.1 From 38b248db60e32734417534b57f9ab687c445113a Mon Sep 17 00:00:00 2001 From: Rajendra Nayak Date: Tue, 29 Apr 2014 16:35:10 +0530 Subject: ARM: dts: Add support for DRA72x family of devices DRA722 is part of DRA72x family which are single core cortex A15 devices with most infrastructure IPs otherwise same as whats on the DRA74x family. So move the cpu nodes into dra74x.dtsi and dra72x.dtsi respectively. Also add a minimal dra72-evm dts file. Signed-off-by: Rajendra Nayak Cc: linux-doc@vger.kernel.org Cc: devicetree@vger.kernel.org Acked-by: Arnd Bergmann [tony@atomide.com: updated for Makefile sorting] Signed-off-by: Tony Lindgren --- Documentation/devicetree/bindings/arm/omap/omap.txt | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index 36ede19..3bad259 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -80,7 +80,10 @@ SoCs: compatible = "ti,omap5432", "ti,omap5" - DRA742 - compatible = "ti,dra7xx", "ti,dra7" + compatible = "ti,dra742", "ti,dra74", "ti,dra7" + +- DRA722 + compatible = "ti,dra722", "ti,dra72", "ti,dra7" - AM4372 compatible = "ti,am4372", "ti,am43" @@ -120,5 +123,8 @@ Boards: - AM437x GP EVM compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43" -- DRA7 EVM: Software Developement Board for DRA7XX - compatible = "ti,dra7-evm", "ti,dra7" +- DRA742 EVM: Software Developement Board for DRA742 + compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7" + +- DRA722 EVM: Software Development Board for DRA722 + compatible = "ti,dra72-evm", "ti,dra722", "ti,dra72", "ti,dra7" -- cgit v1.1 From 9025d563cd9bd141a7b7f2095b6a760cd9d83a4e Mon Sep 17 00:00:00 2001 From: Naveen Krishna Chatradhi Date: Thu, 19 Dec 2013 11:36:08 +0530 Subject: thermal: samsung: change base_common to more meaningful base_second On Exynos5440 and Exynos5420 there are registers common across the TMU channels. To support that, we introduced a ADDRESS_MULTIPLE flag in the driver and the 2nd set of register base and size are provided in the "reg" property of the node. As per Amit's suggestion, this patch changes the base_common to base_second and SHARED_MEMORY to ADDRESS_MULTIPLE. Signed-off-by: Naveen Krishna Chatradhi Acked-by: Amit Daniel Kachhap Reviewed-by: Bartlomiej Zolnierkiewicz Reviewed-by: Tomasz Figa Signed-off-by: Eduardo Valentin --- Documentation/devicetree/bindings/thermal/exynos-thermal.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt index 284f530..a1aa602 100644 --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt @@ -11,8 +11,8 @@ - reg : Address range of the thermal registers. For soc's which has multiple instances of TMU and some registers are shared across all TMU's like interrupt related then 2 set of register has to supplied. First set - belongs to each instance of TMU and second set belongs to common TMU - registers. + belongs to register set of TMU instance and second set belongs to + registers shared with the TMU instance. - interrupts : Should contain interrupt for thermal system - clocks : The main clock for TMU device - clock-names : Thermal system clock name -- cgit v1.1 From 14a11dc7e0dbf4acdd9c7b703ebd088f14def739 Mon Sep 17 00:00:00 2001 From: Naveen Krishna Chatradhi Date: Thu, 19 Dec 2013 11:36:31 +0530 Subject: thermal: samsung: Add TMU support for Exynos5420 SoCs Exynos5420 has 5 TMU channels, the TRIMINFO register is misplaced for TMU channels 2, 3 and 4 TRIMINFO at 0x1006c000 contains data for TMU channel 3 TRIMINFO at 0x100a0000 contains data for TMU channel 4 TRIMINFO at 0x10068000 contains data for TMU channel 2 This patch 1 Adds the neccessary register changes and arch information to support Exynos5420 SoCs. 2. Handles the gate clock for misplaced TRIMINFO register 3. Updates the Documentation at Documentation/devicetree/bindings/thermal/exynos-thermal.txt Signed-off-by: Naveen Krishna Chatradhi Signed-off-by: Andrew Bresticker Acked-by: Amit Daniel Kachhap Reviewed-by: Bartlomiej Zolnierkiewicz Reviewed-by: Tomasz Figa Signed-off-by: Eduardo Valentin --- .../devicetree/bindings/thermal/exynos-thermal.txt | 45 +++++++++++++++++++++- 1 file changed, 44 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt index a1aa602..79c4055 100644 --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt @@ -6,6 +6,9 @@ "samsung,exynos4412-tmu" "samsung,exynos4210-tmu" "samsung,exynos5250-tmu" + "samsung,exynos5420-tmu" for TMU channel 0, 1 on Exynos5420 + "samsung,exynos5420-tmu-ext-triminfo" for TMU channels 2, 3 and 4 + Exynos5420 (Must pass triminfo base and triminfo clock) "samsung,exynos5440-tmu" - interrupt-parent : The phandle for the interrupt controller - reg : Address range of the thermal registers. For soc's which has multiple @@ -13,9 +16,24 @@ interrupt related then 2 set of register has to supplied. First set belongs to register set of TMU instance and second set belongs to registers shared with the TMU instance. + + NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU + channels 2, 3 and 4 + Use "samsung,exynos5420-tmu-ext-triminfo" in cases, there is a misplaced + register, also provide clock to access that base. + + TRIMINFO at 0x1006c000 contains data for TMU channel 3 + TRIMINFO at 0x100a0000 contains data for TMU channel 4 + TRIMINFO at 0x10068000 contains data for TMU channel 2 + - interrupts : Should contain interrupt for thermal system -- clocks : The main clock for TMU device +- clocks : The main clocks for TMU device + -- 1. operational clock for TMU channel + -- 2. optional clock to access the shared registers of TMU channel - clock-names : Thermal system clock name + -- "tmu_apbif" operational clock for current TMU channel + -- "tmu_triminfo_apbif" clock to access the shared triminfo register + for current TMU channel - vtmu-supply: This entry is optional and provides the regulator node supplying voltage to TMU. If needed this entry can be placed inside board/platform specific dts file. @@ -43,6 +61,31 @@ Example 2): clock-names = "tmu_apbif"; }; +Example 3): (In case of Exynos5420 "with misplaced TRIMINFO register") + tmu_cpu2: tmu@10068000 { + compatible = "samsung,exynos5420-tmu-ext-triminfo"; + reg = <0x10068000 0x100>, <0x1006c000 0x4>; + interrupts = <0 184 0>; + clocks = <&clock 318>, <&clock 318>; + clock-names = "tmu_apbif", "tmu_triminfo_apbif"; + }; + + tmu_cpu3: tmu@1006c000 { + compatible = "samsung,exynos5420-tmu-ext-triminfo"; + reg = <0x1006c000 0x100>, <0x100a0000 0x4>; + interrupts = <0 185 0>; + clocks = <&clock 318>, <&clock 319>; + clock-names = "tmu_apbif", "tmu_triminfo_apbif"; + }; + + tmu_gpu: tmu@100a0000 { + compatible = "samsung,exynos5420-tmu-ext-triminfo"; + reg = <0x100a0000 0x100>, <0x10068000 0x4>; + interrupts = <0 215 0>; + clocks = <&clock 319>, <&clock 318>; + clock-names = "tmu_apbif", "tmu_triminfo_apbif"; + }; + Note: For multi-instance tmu each instance should have an alias correctly numbered in "aliases" node. -- cgit v1.1 From 923488a53e7890566f298c2f67416af84ba2a21c Mon Sep 17 00:00:00 2001 From: Naveen Krishna Chatradhi Date: Fri, 20 Dec 2013 17:49:10 +0530 Subject: thermal: samsung: Add TMU support for Exynos5260 SoCs This patch adds the registers, bit fields and compatible strings required to support for the 5 TMU channels on Exynos5260. Signed-off-by: Naveen Krishna Chatradhi Signed-off-by: Eduardo Valentin --- Documentation/devicetree/bindings/thermal/exynos-thermal.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt index 79c4055..c949092 100644 --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt @@ -6,6 +6,7 @@ "samsung,exynos4412-tmu" "samsung,exynos4210-tmu" "samsung,exynos5250-tmu" + "samsung,exynos5260-tmu" "samsung,exynos5420-tmu" for TMU channel 0, 1 on Exynos5420 "samsung,exynos5420-tmu-ext-triminfo" for TMU channels 2, 3 and 4 Exynos5420 (Must pass triminfo base and triminfo clock) -- cgit v1.1 From d8d3d94b80aa1a1c0ca75c58b8abdc7356f38418 Mon Sep 17 00:00:00 2001 From: Al Viro Date: Tue, 4 Mar 2014 21:27:34 -0500 Subject: pass iov_iter to ->direct_IO() unmodified, for now Signed-off-by: Al Viro --- Documentation/filesystems/Locking | 3 +-- Documentation/filesystems/vfs.txt | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index eba7901..9b0d5a3 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -196,8 +196,7 @@ prototypes: 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, - loff_t offset, unsigned long nr_segs); + int (*direct_IO)(int, struct kiocb *, struct iov_iter *iter, loff_t offset); int (*get_xip_mem)(struct address_space *, pgoff_t, int, void **, unsigned long *); int (*migratepage)(struct address_space *, struct page *, struct page *); diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index 617f6d7..1846374 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -589,8 +589,7 @@ struct address_space_operations { 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, - loff_t offset, unsigned long nr_segs); + ssize_t (*direct_IO)(int, struct kiocb *, struct iov_iter *iter, loff_t offset); struct page* (*get_xip_page)(struct address_space *, sector_t, int); /* migrate the contents of a page to the specified target */ -- cgit v1.1 From 293bc9822fa9b3c9d4b7893bcb241e085580771a Mon Sep 17 00:00:00 2001 From: Al Viro Date: Tue, 11 Feb 2014 18:37:41 -0500 Subject: new methods: ->read_iter() and ->write_iter() Beginning to introduce those. Just the callers for now, and it's clumsier than it'll eventually become; once we finish converting aio_read and aio_write instances, the things will get nicer. For now, these guys are in parallel to ->aio_read() and ->aio_write(); they take iocb and iov_iter, with everything in iov_iter already validated. File offset is passed in iocb->ki_pos, iov/nr_segs - in iov_iter. Main concerns in that series are stack footprint and ability to split the damn thing cleanly. [fix from Peter Ujfalusi folded] Signed-off-by: Al Viro --- Documentation/filesystems/Locking | 2 ++ Documentation/filesystems/vfs.txt | 10 ++++++++-- 2 files changed, 10 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index 9b0d5a3..b18dd17 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -430,6 +430,8 @@ 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); + ssize_t (*read_iter) (struct kiocb *, struct iov_iter *); + ssize_t (*write_iter) (struct kiocb *, struct iov_iter *); 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); diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index 1846374..a1d0d7a 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -806,6 +806,8 @@ 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); + ssize_t (*read_iter) (struct kiocb *, struct iov_iter *); + ssize_t (*write_iter) (struct kiocb *, struct iov_iter *); 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); @@ -836,11 +838,15 @@ otherwise noted. read: called by read(2) and related system calls - aio_read: called by io_submit(2) and other asynchronous I/O operations + aio_read: vectored, possibly asynchronous read + + read_iter: possibly asynchronous read with iov_iter as destination write: called by write(2) and related system calls - aio_write: called by io_submit(2) and other asynchronous I/O operations + aio_write: vectored, possibly asynchronous write + + write_iter: possibly asynchronous write with iov_iter as source iterate: called when the VFS needs to read the directory contents -- cgit v1.1 From a0dd7b79657bd6644b914d16ce7f23468c44a7b4 Mon Sep 17 00:00:00 2001 From: Nishanth Menon Date: Mon, 5 May 2014 08:33:50 -0500 Subject: PM / OPP: Move cpufreq specific OPP functions out of generic OPP library CPUFreq specific helper functions for OPP (Operating Performance Points) now use generic OPP functions that allow CPUFreq to be be moved back into CPUFreq framework. This allows for independent modifications or future enhancements as needed isolated to just CPUFreq framework alone. Here, we just move relevant code and documentation to make this part of CPUFreq infrastructure. Cc: Kevin Hilman Signed-off-by: Nishanth Menon Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki --- Documentation/cpu-freq/core.txt | 29 +++++++++++++++++++++++++++++ Documentation/power/opp.txt | 40 +++++----------------------------------- 2 files changed, 34 insertions(+), 35 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cpu-freq/core.txt b/Documentation/cpu-freq/core.txt index 0060d76..70933ea 100644 --- a/Documentation/cpu-freq/core.txt +++ b/Documentation/cpu-freq/core.txt @@ -20,6 +20,7 @@ Contents: --------- 1. CPUFreq core and interfaces 2. CPUFreq notifiers +3. CPUFreq Table Generation with Operating Performance Point (OPP) 1. General Information ======================= @@ -92,3 +93,31 @@ values: cpu - number of the affected CPU old - old frequency new - new frequency + +3. CPUFreq Table Generation with Operating Performance Point (OPP) +================================================================== +For details about OPP, see Documentation/power/opp.txt + +dev_pm_opp_init_cpufreq_table - cpufreq framework typically is initialized with + cpufreq_frequency_table_cpuinfo which is provided with the list of + frequencies that are available for operation. This function provides + a ready to use conversion routine to translate the OPP layer's internal + information about the available frequencies into a format readily + providable to cpufreq. + + WARNING: Do not use this function in interrupt context. + + Example: + soc_pm_init() + { + /* Do things */ + r = dev_pm_opp_init_cpufreq_table(dev, &freq_table); + if (!r) + cpufreq_frequency_table_cpuinfo(policy, freq_table); + /* Do other things */ + } + + NOTE: This function is available only if CONFIG_CPU_FREQ is enabled in + addition to CONFIG_PM_OPP. + +dev_pm_opp_free_cpufreq_table - Free up the table allocated by dev_pm_opp_init_cpufreq_table diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt index b8a907d..a9adad8 100644 --- a/Documentation/power/opp.txt +++ b/Documentation/power/opp.txt @@ -10,8 +10,7 @@ Contents 3. OPP Search Functions 4. OPP Availability Control Functions 5. OPP Data Retrieval Functions -6. Cpufreq Table Generation -7. Data Structures +6. Data Structures 1. Introduction =============== @@ -72,7 +71,6 @@ operations until that OPP could be re-enabled if possible. OPP library facilitates this concept in it's implementation. The following operational functions operate only on available opps: opp_find_freq_{ceil, floor}, dev_pm_opp_get_voltage, dev_pm_opp_get_freq, dev_pm_opp_get_opp_count -and dev_pm_opp_init_cpufreq_table dev_pm_opp_find_freq_exact is meant to be used to find the opp pointer which can then be used for dev_pm_opp_enable/disable functions to make an opp available as required. @@ -96,10 +94,9 @@ using RCU read locks. The opp_find_freq_{exact,ceil,floor}, opp_get_{voltage, freq, opp_count} fall into this category. opp_{add,enable,disable} are updaters which use mutex and implement it's own -RCU locking mechanisms. dev_pm_opp_init_cpufreq_table acts as an updater and uses -mutex to implment RCU updater strategy. These functions should *NOT* be called -under RCU locks and other contexts that prevent blocking functions in RCU or -mutex operations from working. +RCU locking mechanisms. These functions should *NOT* be called under RCU locks +and other contexts that prevent blocking functions in RCU or mutex operations +from working. 2. Initial OPP List Registration ================================ @@ -311,34 +308,7 @@ dev_pm_opp_get_opp_count - Retrieve the number of available opps for a device /* Do other things */ } -6. Cpufreq Table Generation -=========================== -dev_pm_opp_init_cpufreq_table - cpufreq framework typically is initialized with - cpufreq_frequency_table_cpuinfo which is provided with the list of - frequencies that are available for operation. This function provides - a ready to use conversion routine to translate the OPP layer's internal - information about the available frequencies into a format readily - providable to cpufreq. - - WARNING: Do not use this function in interrupt context. - - Example: - soc_pm_init() - { - /* Do things */ - r = dev_pm_opp_init_cpufreq_table(dev, &freq_table); - if (!r) - cpufreq_frequency_table_cpuinfo(policy, freq_table); - /* Do other things */ - } - - NOTE: This function is available only if CONFIG_CPU_FREQ is enabled in - addition to CONFIG_PM as power management feature is required to - dynamically scale voltage and frequency in a system. - -dev_pm_opp_free_cpufreq_table - Free up the table allocated by dev_pm_opp_init_cpufreq_table - -7. Data Structures +6. Data Structures ================== Typically an SoC contains multiple voltage domains which are variable. Each domain is represented by a device pointer. The relationship to OPP can be -- cgit v1.1 From 886129a8eebebec260165741fe31421482371006 Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Tue, 6 May 2014 14:46:23 +0200 Subject: ACPI / video: change acpi-video brightness_switch_enabled default to 0 acpi-video is unique in that it not only generates brightness up/down keypresses, but also (sometimes) actively changes the brightness itself. This presents an inconsistent kernel interface to userspace, basically there are 2 different scenarios, depending on the laptop model: 1) On some laptops a brightness up/down keypress means: show a brightness osd with the current brightness, iow it is a brightness has changed notification. 2) Where as on (a lot of) other laptops it means a brightness up/down key was pressed, deal with it. Most of the desktop environments interpret any press as in scenario 2, and change the brightness up / down as a response to the key events, causing it to be changed twice, once by acpi-video and once by the DE. With the new default for video.use_native_backlight we will be moving even more laptops over to behaving as in scenario 2. Making the remaining laptops even more of a weird exception. Also note that it is hard to detect scenario 1 properly in userspace, and AFAIK none of the DE-s deals with it. Therefor this commit changes the default of brightness_switch_enabled to 0 making its behavior consistent with all the other backlight drivers. Signed-off-by: Hans de Goede Reviewed-by: Aaron Lu Signed-off-by: Rafael J. Wysocki --- Documentation/kernel-parameters.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 4384217..cc2c243 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -3461,7 +3461,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. the allocated input device; If set to 0, video driver will only send out the event without touching backlight brightness level. - default: 1 + default: 0 virtio_mmio.device= [VMMIO] Memory mapped virtio (platform) device. -- cgit v1.1 From 8a54cd5bd6ebf009b96ec79510b593f7ba5c0ff3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pali=20Roh=C3=A1r?= Date: Tue, 6 May 2014 13:01:56 +0200 Subject: PM / hibernate: Documentation: Fix script for unswapping MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit System can have mmaped also character devices (e.g dri devices by X) or deleted files. Running cat on character devices is really bad idea (system can hang) so run cat only on regular files. Also mmaped files can have spaces in filenames. Signed-off-by: Pali Rohár [rjw: Subject] Signed-off-by: Rafael J. Wysocki --- Documentation/power/swsusp.txt | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt index 079160e..f732a83 100644 --- a/Documentation/power/swsusp.txt +++ b/Documentation/power/swsusp.txt @@ -220,7 +220,10 @@ Q: After resuming, system is paging heavily, leading to very bad interactivity. A: Try running -cat `cat /proc/[0-9]*/maps | grep / | sed 's:.* /:/:' | sort -u` > /dev/null +cat /proc/[0-9]*/maps | grep / | sed 's:.* /:/:' | sort -u | while read file +do + test -f "$file" && cat "$file" > /dev/null +done after resume. swapoff -a; swapon -a may also be useful. -- cgit v1.1 From 905b1383d7650c1b1f4321cc6cc9e696c26fef25 Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen Date: Tue, 21 Jan 2014 11:17:08 +0200 Subject: Doc/DT: Add DT binding documentation for MIPI DPI Panel Add DT binding documentation for MIPI DPI Panel. Signed-off-by: Tomi Valkeinen Reviewed-by: Archit Taneja Cc: devicetree@vger.kernel.org --- .../devicetree/bindings/video/panel-dpi.txt | 45 ++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/panel-dpi.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/video/panel-dpi.txt b/Documentation/devicetree/bindings/video/panel-dpi.txt new file mode 100644 index 0000000..a40180b --- /dev/null +++ b/Documentation/devicetree/bindings/video/panel-dpi.txt @@ -0,0 +1,45 @@ +Generic MIPI DPI Panel +====================== + +Required properties: +- compatible: "panel-dpi" + +Optional properties: +- label: a symbolic name for the panel +- enable-gpios: panel enable gpio + +Required nodes: +- "panel-timing" containing video timings + (Documentation/devicetree/bindings/video/display-timing.txt) +- Video port for DPI input + +Example +------- + +lcd0: display@0 { + compatible = "samsung,lte430wq-f0c", "panel-dpi"; + label = "lcd"; + + port { + lcd_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; + + panel-timing { + clock-frequency = <9200000>; + hactive = <480>; + vactive = <272>; + hfront-porch = <8>; + hback-porch = <4>; + hsync-len = <41>; + vback-porch = <2>; + vfront-porch = <4>; + vsync-len = <10>; + + hsync-active = <0>; + vsync-active = <0>; + de-active = <1>; + pixelclk-active = <1>; + }; +}; -- cgit v1.1 From f8be053fc17d776f0505febf035c0a8cd20cc4b2 Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen Date: Wed, 23 Apr 2014 13:34:47 +0300 Subject: Doc/DT: hdmi-connector: add HPD GPIO documentation Add binding documentation for HDMI connector's HPD GPIO. Signed-off-by: Tomi Valkeinen Cc: devicetree@vger.kernel.org --- Documentation/devicetree/bindings/video/hdmi-connector.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/video/hdmi-connector.txt b/Documentation/devicetree/bindings/video/hdmi-connector.txt index ccccc19..acd5668 100644 --- a/Documentation/devicetree/bindings/video/hdmi-connector.txt +++ b/Documentation/devicetree/bindings/video/hdmi-connector.txt @@ -7,6 +7,7 @@ Required properties: Optional properties: - label: a symbolic name for the connector +- hpd-gpios: HPD GPIO number Required nodes: - Video port for HDMI input -- cgit v1.1 From 2c5c4075bcb998b54f51497b168ce0b280814e41 Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen Date: Wed, 23 Apr 2014 13:15:26 +0300 Subject: Doc/DT: ti,omap4-dss: hdmi lanes Add documentation for defining HDMI lane functions and polarities. Signed-off-by: Tomi Valkeinen Cc: devicetree@vger.kernel.org --- Documentation/devicetree/bindings/video/ti,omap4-dss.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/video/ti,omap4-dss.txt b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt index f85d6fc..b8c29fb 100644 --- a/Documentation/devicetree/bindings/video/ti,omap4-dss.txt +++ b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt @@ -109,3 +109,7 @@ Required properties: Optional nodes: - Video port for HDMI output + +HDMI Endpoint optional properties: +- lanes: list of 8 pin numbers for the HDMI lanes: CLK+, CLK-, D0+, D0-, + D1+, D1-, D2+, D2-. (default: 0,1,2,3,4,5,6,7) -- cgit v1.1 From 7c65bbc7dcface00b295bbd18bce82fe1db3d633 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (Red Hat)" Date: Tue, 6 May 2014 09:26:30 -0400 Subject: tracing: Add trace__enabled() function There are some code paths in the kernel that need to do some preparations before it calls a tracepoint. As that code is worthless overhead when the tracepoint is not enabled, it would be prudent to have that code only run when the tracepoint is active. To accomplish this, all tracepoints now get a static inline function called "trace__enabled()" which returns true when the tracepoint is enabled and false otherwise. As an added bonus, that function uses the static_key of the tracepoint such that no branch is needed. if (trace_mytracepoint_enabled()) { arg = process_tp_arg(); trace_mytracepoint(arg); } Will keep the "process_tp_arg()" (which may be expensive to run) from being executed when the tracepoint isn't enabled. It's best to encapsulate the tracepoint itself in the if statement just to keep races. For example, if you had: if (trace_mytracepoint_enabled()) arg = process_tp_arg(); trace_mytracepoint(arg); There's a chance that the tracepoint could be enabled just after the if statement, and arg will be undefined when calling the tracepoint. Link: http://lkml.kernel.org/r/20140506094407.507b6435@gandalf.local.home Acked-by: Mathieu Desnoyers Signed-off-by: Steven Rostedt --- Documentation/trace/tracepoints.txt | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) (limited to 'Documentation') diff --git a/Documentation/trace/tracepoints.txt b/Documentation/trace/tracepoints.txt index 6b018b5..a3efac6 100644 --- a/Documentation/trace/tracepoints.txt +++ b/Documentation/trace/tracepoints.txt @@ -115,6 +115,30 @@ If the tracepoint has to be used in kernel modules, an EXPORT_TRACEPOINT_SYMBOL_GPL() or EXPORT_TRACEPOINT_SYMBOL() can be used to export the defined tracepoints. +If you need to do a bit of work for a tracepoint parameter, and +that work is only used for the tracepoint, that work can be encapsulated +within an if statement with the following: + + if (trace_foo_bar_enabled()) { + int i; + int tot = 0; + + for (i = 0; i < count; i++) + tot += calculate_nuggets(); + + trace_foo_bar(tot); + } + +All trace_() calls have a matching trace__enabled() +function defined that returns true if the tracepoint is enabled and +false otherwise. The trace_() should always be within the +block of the if (trace__enabled()) to prevent races between +the tracepoint being enabled and the check being seen. + +The advantage of using the trace__enabled() is that it uses +the static_key of the tracepoint to allow the if statement to be implemented +with jump labels and avoid conditional branches. + Note: The convenience macro TRACE_EVENT provides an alternative way to define tracepoints. Check http://lwn.net/Articles/379903, http://lwn.net/Articles/381064 and http://lwn.net/Articles/383362 -- cgit v1.1 From f9e1716f919f1bce2749a3ec15f34759ded0a56d Mon Sep 17 00:00:00 2001 From: Boris BREZILLON Date: Tue, 22 Apr 2014 15:12:31 +0200 Subject: clk: at91: update main clk documentation Update main clk documentation to match main clk implementation rework. Signed-off-by: Boris BREZILLON Acked-by: Mike Turquette Signed-off-by: Nicolas Ferre --- .../devicetree/bindings/clock/at91-clock.txt | 56 ++++++++++++++++++---- 1 file changed, 47 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt b/Documentation/devicetree/bindings/clock/at91-clock.txt index cd5e239..26d2c84 100644 --- a/Documentation/devicetree/bindings/clock/at91-clock.txt +++ b/Documentation/devicetree/bindings/clock/at91-clock.txt @@ -15,8 +15,13 @@ Required properties: All at91 specific clocks (clocks defined below) must be child node of the PMC node. + "atmel,at91rm9200-clk-main-osc" + "atmel,at91sam9x5-clk-main-rc-osc" + at91 main clk sources + + "atmel,at91sam9x5-clk-main" "atmel,at91rm9200-clk-main": - at91 main oscillator + at91 main clock "atmel,at91rm9200-clk-master" or "atmel,at91sam9x5-clk-master": @@ -85,24 +90,57 @@ For example: /* put at91 clocks here */ }; +Required properties for main clock internal RC oscillator: +- interrupt-parent : must reference the PMC node. +- interrupts : shall be set to "<0>". +- clock-frequency : define the internal RC oscillator frequency. + +Optional properties: +- clock-accuracy : define the internal RC oscillator accuracy. + +For example: + main_rc_osc: main_rc_osc { + compatible = "atmel,at91sam9x5-clk-main-rc-osc"; + interrupt-parent = <&pmc>; + interrupts = <0>; + clock-frequency = <12000000>; + clock-accuracy = <50000000>; + }; + +Required properties for main clock oscillator: +- interrupt-parent : must reference the PMC node. +- interrupts : shall be set to "<0>". +- #clock-cells : from common clock binding; shall be set to 0. +- clocks : shall encode the main osc source clk sources (see atmel datasheet). + +Optional properties: +- atmel,osc-bypass : boolean property. Specified if a clock signal is provided + on XIN. + + clock signal is directly provided on XIN pin. + +For example: + main_osc: main_osc { + compatible = "atmel,at91rm9200-clk-main-osc"; + interrupt-parent = <&pmc>; + interrupts = <0>; + #clock-cells = <0>; + clocks = <&main_xtal>; + }; + Required properties for main clock: - interrupt-parent : must reference the PMC node. - interrupts : shall be set to "<0>". - #clock-cells : from common clock binding; shall be set to 0. -- clocks (optional if clock-frequency is provided) : shall be the slow clock - phandle. This clock is used to calculate the main clock rate if - "clock-frequency" is not provided. -- clock-frequency : the main oscillator frequency.Prefer the use of - "clock-frequency" over automatic clock rate calculation. +- clocks : shall encode the main clk sources (see atmel datasheet). For example: main: mainck { - compatible = "atmel,at91rm9200-clk-main"; + compatible = "atmel,at91sam9x5-clk-main"; interrupt-parent = <&pmc>; interrupts = <0>; #clock-cells = <0>; - clocks = <&ck32k>; - clock-frequency = <18432000>; + clocks = <&main_rc_osc &main_osc>; }; Required properties for master clock: -- cgit v1.1 From 4d735e548cdf6e8d92849a6dac2b4d5a9d2145f3 Mon Sep 17 00:00:00 2001 From: Boris BREZILLON Date: Tue, 22 Apr 2014 15:12:33 +0200 Subject: clk: at91: add slow clk documentation Add slow clk, and slow oscillators documentation. Signed-off-by: Boris BREZILLON Acked-by: Mike Turquette Signed-off-by: Nicolas Ferre --- .../devicetree/bindings/clock/at91-clock.txt | 72 ++++++++++++++++++++++ 1 file changed, 72 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt b/Documentation/devicetree/bindings/clock/at91-clock.txt index 26d2c84..27f9a27 100644 --- a/Documentation/devicetree/bindings/clock/at91-clock.txt +++ b/Documentation/devicetree/bindings/clock/at91-clock.txt @@ -6,6 +6,16 @@ This binding uses the common clock binding[1]. Required properties: - compatible : shall be one of the following: + "atmel,at91sam9x5-sckc": + at91 SCKC (Slow Clock Controller) + This node contains the slow clock definitions. + + "atmel,at91sam9x5-clk-slow-osc": + at91 slow oscillator + + "atmel,at91sam9x5-clk-slow-rc-osc": + at91 internal slow RC oscillator + "atmel,at91rm9200-pmc" or "atmel,at91sam9g45-pmc" or "atmel,at91sam9n12-pmc" or @@ -15,6 +25,11 @@ Required properties: All at91 specific clocks (clocks defined below) must be child node of the PMC node. + "atmel,at91sam9x5-clk-slow" (under sckc node) + or + "atmel,at91sam9260-clk-slow" (under pmc node): + at91 slow clk + "atmel,at91rm9200-clk-main-osc" "atmel,at91sam9x5-clk-main-rc-osc" at91 main clk sources @@ -59,6 +74,63 @@ Required properties: "atmel,at91sam9x5-clk-utmi": at91 utmi clock +Required properties for SCKC node: +- reg : defines the IO memory reserved for the SCKC. +- #size-cells : shall be 0 (reg is used to encode clk id). +- #address-cells : shall be 1 (reg is used to encode clk id). + + +For example: + sckc: sckc@fffffe50 { + compatible = "atmel,sama5d3-pmc"; + reg = <0xfffffe50 0x4> + #size-cells = <0>; + #address-cells = <1>; + + /* put at91 slow clocks here */ + }; + + +Required properties for internal slow RC oscillator: +- #clock-cells : from common clock binding; shall be set to 0. +- clock-frequency : define the internal RC oscillator frequency. + +Optional properties: +- clock-accuracy : define the internal RC oscillator accuracy. + +For example: + slow_rc_osc: slow_rc_osc { + compatible = "atmel,at91sam9x5-clk-slow-rc-osc"; + clock-frequency = <32768>; + clock-accuracy = <50000000>; + }; + +Required properties for slow oscillator: +- #clock-cells : from common clock binding; shall be set to 0. +- clocks : shall encode the main osc source clk sources (see atmel datasheet). + +Optional properties: +- atmel,osc-bypass : boolean property. Set this when a clock signal is directly + provided on XIN. + +For example: + slow_osc: slow_osc { + compatible = "atmel,at91rm9200-clk-slow-osc"; + #clock-cells = <0>; + clocks = <&slow_xtal>; + }; + +Required properties for slow clock: +- #clock-cells : from common clock binding; shall be set to 0. +- clocks : shall encode the slow clk sources (see atmel datasheet). + +For example: + clk32k: slck { + compatible = "atmel,at91sam9x5-clk-slow"; + #clock-cells = <0>; + clocks = <&slow_rc_osc &slow_osc>; + }; + Required properties for PMC node: - reg : defines the IO memory reserved for the PMC. - #size-cells : shall be 0 (reg is used to encode clk id). -- cgit v1.1 From 4b405efbe12de28b26289282b431323d73992381 Mon Sep 17 00:00:00 2001 From: Hubert Chaumette Date: Tue, 6 May 2014 09:40:16 +0200 Subject: Update Micrel KSZ90x1 binding documentation Renames micrel-ksz9021.txt to micrel-ksz90x1.txt and adds documentation for the KSZ9031 binding from patch 1. Also adds step increment information, and note about phy fixups. Signed-off-by: Hubert Chaumette Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller --- .../devicetree/bindings/net/micrel-ksz9021.txt | 49 ------------- .../devicetree/bindings/net/micrel-ksz90x1.txt | 83 ++++++++++++++++++++++ 2 files changed, 83 insertions(+), 49 deletions(-) delete mode 100644 Documentation/devicetree/bindings/net/micrel-ksz9021.txt create mode 100644 Documentation/devicetree/bindings/net/micrel-ksz90x1.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/micrel-ksz9021.txt b/Documentation/devicetree/bindings/net/micrel-ksz9021.txt deleted file mode 100644 index 997a63f..0000000 --- a/Documentation/devicetree/bindings/net/micrel-ksz9021.txt +++ /dev/null @@ -1,49 +0,0 @@ -Micrel KSZ9021 Gigabit Ethernet PHY - -Some boards require special tuning values, particularly when it comes to -clock delays. You can specify clock delay values by adding -micrel-specific properties to an Ethernet OF device node. - -All skew control options are specified in picoseconds. The minimum -value is 0, and the maximum value is 3000. - -Optional properties: - - rxc-skew-ps : Skew control of RXC pad - - rxdv-skew-ps : Skew control of RX CTL pad - - txc-skew-ps : Skew control of TXC pad - - txen-skew-ps : Skew control of TX_CTL pad - - rxd0-skew-ps : Skew control of RX data 0 pad - - rxd1-skew-ps : Skew control of RX data 1 pad - - rxd2-skew-ps : Skew control of RX data 2 pad - - rxd3-skew-ps : Skew control of RX data 3 pad - - txd0-skew-ps : Skew control of TX data 0 pad - - txd1-skew-ps : Skew control of TX data 1 pad - - txd2-skew-ps : Skew control of TX data 2 pad - - txd3-skew-ps : Skew control of TX data 3 pad - -Examples: - - /* Attach to an Ethernet device with autodetected PHY */ - &enet { - rxc-skew-ps = <3000>; - rxdv-skew-ps = <0>; - txc-skew-ps = <3000>; - txen-skew-ps = <0>; - status = "okay"; - }; - - /* Attach to an explicitly-specified PHY */ - mdio { - phy0: ethernet-phy@0 { - rxc-skew-ps = <3000>; - rxdv-skew-ps = <0>; - txc-skew-ps = <3000>; - txen-skew-ps = <0>; - reg = <0>; - }; - }; - ethernet@70000 { - status = "okay"; - phy = <&phy0>; - phy-mode = "rgmii-id"; - }; diff --git a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt new file mode 100644 index 0000000..692076f --- /dev/null +++ b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt @@ -0,0 +1,83 @@ +Micrel KSZ9021/KSZ9031 Gigabit Ethernet PHY + +Some boards require special tuning values, particularly when it comes to +clock delays. You can specify clock delay values by adding +micrel-specific properties to an Ethernet OF device node. + +Note that these settings are applied after any phy-specific fixup from +phy_fixup_list (see phy_init_hw() from drivers/net/phy/phy_device.c), +and therefore may overwrite them. + +KSZ9021: + + All skew control options are specified in picoseconds. The minimum + value is 0, the maximum value is 3000, and it is incremented by 200ps + steps. + + Optional properties: + + - rxc-skew-ps : Skew control of RXC pad + - rxdv-skew-ps : Skew control of RX CTL pad + - txc-skew-ps : Skew control of TXC pad + - txen-skew-ps : Skew control of TX CTL pad + - rxd0-skew-ps : Skew control of RX data 0 pad + - rxd1-skew-ps : Skew control of RX data 1 pad + - rxd2-skew-ps : Skew control of RX data 2 pad + - rxd3-skew-ps : Skew control of RX data 3 pad + - txd0-skew-ps : Skew control of TX data 0 pad + - txd1-skew-ps : Skew control of TX data 1 pad + - txd2-skew-ps : Skew control of TX data 2 pad + - txd3-skew-ps : Skew control of TX data 3 pad + +KSZ9031: + + All skew control options are specified in picoseconds. The minimum + value is 0, and the maximum is property-dependent. The increment + step is 60ps. + + Optional properties: + + Maximum value of 1860: + + - rxc-skew-ps : Skew control of RX clock pad + - txc-skew-ps : Skew control of TX clock pad + + Maximum value of 900: + + - rxdv-skew-ps : Skew control of RX CTL pad + - txen-skew-ps : Skew control of TX CTL pad + - rxd0-skew-ps : Skew control of RX data 0 pad + - rxd1-skew-ps : Skew control of RX data 1 pad + - rxd2-skew-ps : Skew control of RX data 2 pad + - rxd3-skew-ps : Skew control of RX data 3 pad + - txd0-skew-ps : Skew control of TX data 0 pad + - txd1-skew-ps : Skew control of TX data 1 pad + - txd2-skew-ps : Skew control of TX data 2 pad + - txd3-skew-ps : Skew control of TX data 3 pad + +Examples: + + /* Attach to an Ethernet device with autodetected PHY */ + &enet { + rxc-skew-ps = <3000>; + rxdv-skew-ps = <0>; + txc-skew-ps = <3000>; + txen-skew-ps = <0>; + status = "okay"; + }; + + /* Attach to an explicitly-specified PHY */ + mdio { + phy0: ethernet-phy@0 { + rxc-skew-ps = <3000>; + rxdv-skew-ps = <0>; + txc-skew-ps = <3000>; + txen-skew-ps = <0>; + reg = <0>; + }; + }; + ethernet@70000 { + status = "okay"; + phy = <&phy0>; + phy-mode = "rgmii-id"; + }; -- cgit v1.1 From b0571e7e4ec4d62b27711758417c388042f7bae7 Mon Sep 17 00:00:00 2001 From: Russell King Date: Sun, 6 Apr 2014 15:20:24 -0700 Subject: leds: leds-pwm: add DT support for LEDs wired to supply The non-DT driver allowed an active low property to be specified, but DT is missing this in its description. Add the property to the DT binding document, making it optional. It defaults to active high, which retains compatibility with existing descriptions. This should only be used for causes where the LED is wired to supply, and the PWM does not sensibly support its own inversion. Signed-off-by: Russell King Signed-off-by: Bryan Wu --- Documentation/devicetree/bindings/leds/leds-pwm.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/leds/leds-pwm.txt b/Documentation/devicetree/bindings/leds/leds-pwm.txt index 7297107..6c6583c 100644 --- a/Documentation/devicetree/bindings/leds/leds-pwm.txt +++ b/Documentation/devicetree/bindings/leds/leds-pwm.txt @@ -13,6 +13,8 @@ LED sub-node properties: For the pwms and pwm-names property please refer to: Documentation/devicetree/bindings/pwm/pwm.txt - max-brightness : Maximum brightness possible for the LED +- active-low : (optional) For PWMs where the LED is wired to supply + rather than ground. - label : (optional) see Documentation/devicetree/bindings/leds/common.txt - linux,default-trigger : (optional) -- cgit v1.1 From 9ef8c877e4ffca969fb2f1260ee133b12b563c2c Mon Sep 17 00:00:00 2001 From: Daniel Mack Date: Mon, 5 May 2014 04:46:54 -0700 Subject: leds: lp55xx: add DT bindings for LP55231 The TI55231 appears to be fully compatible to the 5523 model from National Semicondutor. This patch just adds DT bindings for it. Signed-off-by: Daniel Mack Acked-by: Milo Kim Signed-off-by: Bryan Wu --- Documentation/devicetree/bindings/leds/leds-lp55xx.txt | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt index c55b8c0..1b66a41 100644 --- a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt +++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt @@ -1,7 +1,13 @@ Binding for TI/National Semiconductor LP55xx Led Drivers Required properties: -- compatible: "national,lp5521" or "national,lp5523" or "ti,lp5562" or "ti,lp8501" +- compatible: one of + national,lp5521 + national,lp5523 + ti,lp55231 + ti,lp5562 + ti,lp8501 + - reg: I2C slave address - clock-mode: Input clock mode, (0: automode, 1: internal, 2: external) -- cgit v1.1 From 54f4d144eb0ae33b2973d8bf92768af8539bc16f Mon Sep 17 00:00:00 2001 From: Roger Quadros Date: Mon, 5 May 2014 12:54:41 +0300 Subject: phy: omap-usb2: Add clock names to Documentation binding Add "wkupclk" and "refclk" information to DT binding information. Reviewed-by: Felipe Balbi Signed-off-by: Roger Quadros Signed-off-by: Kishon Vijay Abraham I --- Documentation/devicetree/bindings/phy/ti-phy.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt index 788fb0f..9ce458f 100644 --- a/Documentation/devicetree/bindings/phy/ti-phy.txt +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt @@ -32,6 +32,11 @@ Required properties: - reg : Address and length of the register set for the device. - #phy-cells: determine the number of cells that should be given in the phandle while referencing this phy. + - clocks: a list of phandles and clock-specifier pairs, one for each entry in + clock-names. + - clock-names: should include: + * "wkupclk" - wakeup clock. + * "refclk" - reference clock (optional). Optional properties: - ctrl-module : phandle of the control module used by PHY driver to power on @@ -44,6 +49,8 @@ usb2phy@4a0ad080 { reg = <0x4a0ad080 0x58>; ctrl-module = <&omap_control_usb>; #phy-cells = <0>; + clocks = <&usb_phy_cm_clk32k>, <&usb_otg_ss_refclk960m>; + clock-names = "wkupclk", "refclk"; }; TI PIPE3 PHY -- cgit v1.1 From 6b9f16e6c2b712f724e6ca1538d18ea8a788dd90 Mon Sep 17 00:00:00 2001 From: Naveen Krishna Chatradhi Date: Thu, 8 May 2014 21:58:13 +0800 Subject: crypto: s5p-sss - Add device tree support This patch adds device tree support to the s5p-sss.c crypto driver. Signed-off-by: Naveen Krishna Chatradhi CC: David S. Miller CC: Acked-by: Vladimir Zapolskiy Signed-off-by: Herbert Xu --- .../devicetree/bindings/crypto/samsung-sss.txt | 25 ++++++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 Documentation/devicetree/bindings/crypto/samsung-sss.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt b/Documentation/devicetree/bindings/crypto/samsung-sss.txt new file mode 100644 index 0000000..f6e09a6 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt @@ -0,0 +1,25 @@ +Samsung SoC SSS (Security SubSystem) module + +The SSS module in S5PV210 SoC supports the following: +-- Feeder (FeedCtrl) +-- Advanced Encryption Standard (AES) +-- Data Encryption Standard (DES)/3DES +-- Public Key Accelerator (PKA) +-- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG +-- PRNG: Pseudo Random Number Generator + +Required properties: + +- compatible : Should contain entries for this and backward compatible + SSS versions: + - "samsung,s5pv210-secss" for S5PV210 SoC. +- reg : Offset and length of the register set for the module +- interrupts : interrupt specifiers of SSS module interrupts, should contain + two entries: + - first : feed control interrupt, + - second : hash interrupt. + +- clocks : list of clock phandle and specifier pairs for all clocks listed in + clock-names property. +- clock-names : list of device clock input names; should contain one entry + "secss". -- cgit v1.1 From 892451071de77a088a6227e36d3a2732d51c5b84 Mon Sep 17 00:00:00 2001 From: Naveen Krishna Chatradhi Date: Thu, 8 May 2014 21:58:14 +0800 Subject: crypto: s5p-sss - Add support for SSS module on Exynos This patch adds new compatible and variant struct to support the SSS module on Exynos4 (Exynos4210), Exynos5 (Exynos5420 and Exynos5250) for which 1. AES register are at an offset of 0x200 and 2. hash interrupt is not available Signed-off-by: Naveen Krishna Chatradhi Reviewed-by: Tomasz Figa CC: David S. Miller CC: Acked-by: Vladimir Zapolskiy Signed-off-by: Herbert Xu --- Documentation/devicetree/bindings/crypto/samsung-sss.txt | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt b/Documentation/devicetree/bindings/crypto/samsung-sss.txt index f6e09a6..a6dafa8 100644 --- a/Documentation/devicetree/bindings/crypto/samsung-sss.txt +++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt @@ -8,16 +8,25 @@ The SSS module in S5PV210 SoC supports the following: -- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG -- PRNG: Pseudo Random Number Generator +The SSS module in Exynos4 (Exynos4210) and +Exynos5 (Exynos5420 and Exynos5250) SoCs +supports the following also: +-- ARCFOUR (ARC4) +-- True Random Number Generator (TRNG) +-- Secure Key Manager + Required properties: - compatible : Should contain entries for this and backward compatible SSS versions: - "samsung,s5pv210-secss" for S5PV210 SoC. + - "samsung,exynos4210-secss" for Exynos4210, Exynos4212, Exynos4412, Exynos5250, + Exynos5260 and Exynos5420 SoCs. - reg : Offset and length of the register set for the module - interrupts : interrupt specifiers of SSS module interrupts, should contain - two entries: - - first : feed control interrupt, - - second : hash interrupt. + following entries: + - first : feed control interrupt (required for all variants), + - second : hash interrupt (required only for samsung,s5pv210-secss). - clocks : list of clock phandle and specifier pairs for all clocks listed in clock-names property. -- cgit v1.1 From 2c9b2240bee340711048589023eb057f23fda356 Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Mon, 14 Apr 2014 15:53:59 +0200 Subject: ARM: mvebu: use CPU_METHOD_OF_DECLARE for SMP on Armada XP This commit adds the CPU_METHOD_OF_DECLARE declaration for the Armada XP SMP operations. Note that the .smp_ops field of Armada XP DT_MACHINE structure is kept, in order to ensure we remain compatible with older Device Trees that do not include the "enable-method" property for the CPUs. Signed-off-by: Thomas Petazzoni Link: https://lkml.kernel.org/r/1397483648-26611-3-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper --- Documentation/devicetree/bindings/arm/cpus.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index 333f4ae..0dc59c3 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -185,6 +185,7 @@ nodes to be present and contain the properties described below. "qcom,gcc-msm8660" "qcom,kpss-acc-v1" "qcom,kpss-acc-v2" + "marvell,armada-xp-smp" - cpu-release-addr Usage: required for systems that have an "enable-method" -- cgit v1.1 From 1ee89e2231a1b04dc34765edd195725ddf4ba998 Mon Sep 17 00:00:00 2001 From: Gregory CLEMENT Date: Mon, 14 Apr 2014 15:54:05 +0200 Subject: ARM: mvebu: add SMP support for Armada 375 and Armada 38x This commit adds the SMP support for Armada 375 and Armada 38x. It turns out that the SMP logic for both of these SOCs are fairly similar, the only differences being: * A different method to set the secondary CPU boot address * An Armada 375 specific workaround needed for the early Z1 stepping, added by the following patch. Other than that, the patch is fairly straightforward and adds the usual platsmp and headsmp code, defining the smp_operations structure that is referenced from the DT_MACHINE structures. Signed-off-by: Gregory CLEMENT Link: https://lkml.kernel.org/r/1397483648-26611-9-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Thomas Petazzoni Link: https://lkml.kernel.org/r/1397483648-26611-9-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper --- Documentation/devicetree/bindings/arm/cpus.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index 0dc59c3..4bbcf4f 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -185,6 +185,8 @@ nodes to be present and contain the properties described below. "qcom,gcc-msm8660" "qcom,kpss-acc-v1" "qcom,kpss-acc-v2" + "marvell,armada-375-smp" + "marvell,armada-380-smp" "marvell,armada-xp-smp" - cpu-release-addr -- cgit v1.1 From b4bca24957c990a09dbddde75858b24150faec89 Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Mon, 14 Apr 2014 15:54:04 +0200 Subject: ARM: mvebu: add Armada 38x compatible string to pmsu Since the Armada 38x PMSU registers are slightly different than the Armada 370/XP PMSU ones, we introduce a new compatible string "armada-380-pmsu" in the PMSU driver. These differences are not visible for the current usage of the PMSU, but they might become visible in the future. Signed-off-by: Thomas Petazzoni Link: https://lkml.kernel.org/r/1397483648-26611-8-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper --- Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt index 9761887..26799ef 100644 --- a/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt +++ b/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt @@ -1,11 +1,14 @@ Power Management Service Unit(PMSU) ----------------------------------- -Available on Marvell SOCs: Armada 370 and Armada XP +Available on Marvell SOCs: Armada 370, Armada 38x and Armada XP Required properties: -- compatible: should be "marvell,armada-370-pmsu", whereas - "marvell,armada-370-xp-pmsu" is deprecated and will be removed +- compatible: should be one of: + - "marvell,armada-370-pmsu" for Armada 370 or Armada XP + - "marvell,armada-380-pmsu" for Armada 38x + - "marvell,armada-370-xp-pmsu" was used for Armada 370/XP but is now + deprecated and will be removed - reg: Should contain PMSU registers location and length. -- cgit v1.1 From bfc7a42a0e74f0b589a017679620d2a3edda9198 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Heiko=20St=C3=BCbner?= Date: Mon, 5 May 2014 13:58:00 +0200 Subject: pinctrl: rockchip: do not require 2nd register area Deprecate secondary register area for rk3188 pulls. Instead use big enough initial mapping of grf registers to catch all. The now deprecated register is still supported though. Signed-off-by: Heiko Stuebner Tested-by: Max Schwarz Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt index f378d34..78dafc9 100644 --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt @@ -22,6 +22,8 @@ Required properties for iomux controller: - compatible: one of "rockchip,rk2928-pinctrl", "rockchip,rk3066a-pinctrl" "rockchip,rk3066b-pinctrl", "rockchip,rk3188-pinctrl" - reg: first element is the general register space of the iomux controller + It should be large enough to contain also separate pull registers. + Deprecated: second element is the separate pull register space of the rk3188 Required properties for gpio sub nodes: -- cgit v1.1 From c51426efd3fa716e175da3b2f52c3ca0837fe737 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Heiko=20St=C3=BCbner?= Date: Mon, 5 May 2014 14:00:11 +0200 Subject: dt-bindings: adapt rockchip-pinctrl doc to changed bindings Introduce the syscons for grf and pmu and deprecate the previous register areas. Signed-off-by: Heiko Stuebner Tested-by: Max Schwarz Signed-off-by: Linus Walleij --- .../bindings/pinctrl/rockchip,pinctrl.txt | 28 +++++++++++++++------- 1 file changed, 20 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt index 78dafc9..cefef74 100644 --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt @@ -21,15 +21,23 @@ 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" + - rockchip,grf: phandle referencing a syscon providing the + "general register files" + +Optional properties for iomux controller: + - rockchip,pmu: phandle referencing a syscon providing the pmu registers + as some SoCs carry parts of the iomux controller registers there. + Required for at least rk3188 and rk3288. + +Deprecated properties for iomux controller: - reg: first element is the general register space of the iomux controller It should be large enough to contain also separate pull registers. - Deprecated: - second element is the separate pull register space of the rk3188 + second element is the separate pull register space of the rk3188. + Use rockchip,grf and rockchip,pmu described above instead. Required properties for gpio sub nodes: - compatible: "rockchip,gpio-bank", "rockchip,rk3188-gpio-bank0" - reg: register of the gpio bank (different than the iomux registerset) - second element: separate pull register for rk3188 bank0 - interrupts: base interrupt of the gpio bank in the interrupt controller - clocks: clock that drives this bank - gpio-controller: identifies the node as a gpio controller and pin bank. @@ -41,6 +49,10 @@ Required properties for gpio sub nodes: cells should use the standard two-cell scheme described in bindings/interrupt-controller/interrupts.txt +Deprecated properties for gpio sub nodes: + - reg: second element: separate pull register for rk3188 bank0, use + rockchip,pmu described above instead + 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 = . @@ -56,7 +68,8 @@ Examples: pinctrl@20008000 { compatible = "rockchip,rk3066a-pinctrl"; - reg = <0x20008000 0x150>; + rockchip,grf = <&grf>; + #address-cells = <1>; #size-cells = <1>; ranges; @@ -105,16 +118,15 @@ Example for rk3188: pinctrl@20008000 { compatible = "rockchip,rk3188-pinctrl"; - reg = <0x20008000 0xa0>, - <0x20008164 0x1a0>; + rockchip,grf = <&grf>; + rockchip,pmu = <&pmu>; #address-cells = <1>; #size-cells = <1>; ranges; gpio0: gpio0@0x2000a000 { compatible = "rockchip,rk3188-gpio-bank0"; - reg = <0x2000a000 0x100>, - <0x20004064 0x8>; + reg = <0x2000a000 0x100>; interrupts = ; clocks = <&clk_gates8 9>; -- cgit v1.1 From 1f32450911dfa243b8ff79cef62d2ddaeeb3e033 Mon Sep 17 00:00:00 2001 From: Marek Belisko Date: Thu, 8 May 2014 22:16:50 +0200 Subject: omapdss: panel-tpo-td028ec1: Add DT support. Signed-off-by: Marek Belisko Signed-off-by: Tomi Valkeinen --- .../bindings/video/toppoly,td028ttec1.txt | 30 ++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/toppoly,td028ttec1.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/video/toppoly,td028ttec1.txt b/Documentation/devicetree/bindings/video/toppoly,td028ttec1.txt new file mode 100644 index 0000000..7175dc3 --- /dev/null +++ b/Documentation/devicetree/bindings/video/toppoly,td028ttec1.txt @@ -0,0 +1,30 @@ +Toppoly TD028TTEC1 Panel +======================== + +Required properties: +- compatible: "toppoly,td028ttec1" + +Optional properties: +- label: a symbolic name for the panel + +Required nodes: +- Video port for DPI input + +Example +------- + +lcd-panel: td028ttec1@0 { + compatible = "toppoly,td028ttec1"; + reg = <0>; + spi-max-frequency = <100000>; + spi-cpol; + spi-cpha; + + label = "lcd"; + port { + lcd_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; +}; + -- cgit v1.1 From 29a1f2333e07bbbecb920cc78fd035fe8f53207a Mon Sep 17 00:00:00 2001 From: Thierry Reding Date: Fri, 25 Apr 2014 17:10:06 +0200 Subject: gpio: Add helpers for optional GPIOs Introduce gpiod_get_optional() and gpiod_get_index_optional() helpers that make it easier for drivers to handle optional GPIOs. Currently in order to handle optional GPIOs, a driver needs to special case error handling for -ENOENT, such as this: gpio = gpiod_get(dev, "foo"); if (IS_ERR(gpio)) { if (PTR_ERR(gpio) != -ENOENT) return PTR_ERR(gpio); gpio = NULL; } if (gpio) { /* set up GPIO */ } With these new helpers the above is reduced to: gpio = gpiod_get_optional(dev, "foo"); if (IS_ERR(gpio)) return PTR_ERR(gpio); if (gpio) { /* set up GPIO */ } While at it, device-managed variants of these functions are also provided. Signed-off-by: Thierry Reding Reviewed-by: Alexandre Courbot Signed-off-by: Linus Walleij --- Documentation/driver-model/devres.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt index 8ff1167c..10b8c5d 100644 --- a/Documentation/driver-model/devres.txt +++ b/Documentation/driver-model/devres.txt @@ -312,4 +312,6 @@ SPI GPIO devm_gpiod_get() devm_gpiod_get_index() + devm_gpiod_get_optional() + devm_gpiod_get_index_optional() devm_gpiod_put() -- cgit v1.1 From dedf2d44336e542d03653f60040938b0adce0a5f Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen Date: Wed, 23 Apr 2014 13:31:57 +0300 Subject: Doc/DT: Add OMAP5 DSS DT bindings Add DT binding documentation for OMAP5 Display Subsystem. Signed-off-by: Tomi Valkeinen Cc: devicetree@vger.kernel.org --- .../devicetree/bindings/video/ti,omap5-dss.txt | 96 ++++++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/ti,omap5-dss.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/video/ti,omap5-dss.txt b/Documentation/devicetree/bindings/video/ti,omap5-dss.txt new file mode 100644 index 0000000..38ffc8f --- /dev/null +++ b/Documentation/devicetree/bindings/video/ti,omap5-dss.txt @@ -0,0 +1,96 @@ +Texas Instruments OMAP5 Display Subsystem +========================================= + +See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic +description about OMAP Display Subsystem bindings. + +DSS Core +-------- + +Required properties: +- compatible: "ti,omap5-dss" +- reg: address and length of the register space +- ti,hwmods: "dss_core" +- clocks: handle to fclk +- clock-names: "fck" + +Required nodes: +- DISPC + +Optional nodes: +- DSS Submodules: RFBI, DSI, HDMI +- Video port for DPI output + +DPI Endpoint required properties: +- data-lines: number of lines used + + +DISPC +----- + +Required properties: +- compatible: "ti,omap5-dispc" +- reg: address and length of the register space +- ti,hwmods: "dss_dispc" +- interrupts: the DISPC interrupt +- clocks: handle to fclk +- clock-names: "fck" + + +RFBI +---- + +Required properties: +- compatible: "ti,omap5-rfbi" +- reg: address and length of the register space +- ti,hwmods: "dss_rfbi" +- clocks: handles to fclk and iclk +- clock-names: "fck", "ick" + +Optional nodes: +- Video port for RFBI output +- RFBI controlled peripherals + + +DSI +--- + +Required properties: +- compatible: "ti,omap5-dsi" +- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll' +- reg-names: "proto", "phy", "pll" +- interrupts: the DSI interrupt line +- ti,hwmods: "dss_dsi1" or "dss_dsi2" +- vdd-supply: power supply for DSI +- clocks: handles to fclk and pll clock +- clock-names: "fck", "sys_clk" + +Optional nodes: +- Video port for DSI output +- DSI controlled peripherals + +DSI Endpoint required properties: +- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-, + DATA1+, DATA1-, ... + + +HDMI +---- + +Required properties: +- compatible: "ti,omap5-hdmi" +- reg: addresses and lengths of the register spaces for 'wp', 'pll', 'phy', + 'core' +- reg-names: "wp", "pll", "phy", "core" +- interrupts: the HDMI interrupt line +- ti,hwmods: "dss_hdmi" +- vdda-supply: vdda power supply +- clocks: handles to fclk and pll clock +- clock-names: "fck", "sys_clk" + +Optional nodes: +- Video port for HDMI output + +HDMI Endpoint optional properties: +- lanes: list of 8 pin numbers for the HDMI lanes: CLK+, CLK-, D0+, D0-, + D1+, D1-, D2+, D2-. (default: 0,1,2,3,4,5,6,7) -- cgit v1.1 From 0953f78971040fff09064bb564d9ac0cd1fb4e69 Mon Sep 17 00:00:00 2001 From: Johan Hovold Date: Thu, 8 May 2014 10:09:20 +0200 Subject: net: mdio-gpio: fix device-tree binding documentation Fix aliases syntax in device-tree binding example to avoid copy-paste errors (the alias would be dropped silently). Signed-off-by: Johan Hovold Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/mdio-gpio.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/mdio-gpio.txt b/Documentation/devicetree/bindings/net/mdio-gpio.txt index c79bab0..8dbcf82 100644 --- a/Documentation/devicetree/bindings/net/mdio-gpio.txt +++ b/Documentation/devicetree/bindings/net/mdio-gpio.txt @@ -14,7 +14,7 @@ node. Example: aliases { - mdio-gpio0 = <&mdio0>; + mdio-gpio0 = &mdio0; }; mdio0: mdio { -- cgit v1.1 From d83271a6fa2ba4756250ccfde7d7f0d3e0b30d97 Mon Sep 17 00:00:00 2001 From: Beniamino Galvani Date: Tue, 6 May 2014 19:10:10 +0200 Subject: of: add mundoreader and radxa vendor prefixes Add new vendor prefixes for: * Mundo Reader S.L., a company that produces tablets and e-readers * Radxa, manufacturer of ARM boards Signed-off-by: Beniamino Galvani Acked-by: Rob Herring Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/vendor-prefixes.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index abc3080..53bd92f 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -79,6 +79,7 @@ microchip Microchip Technology Inc. mosaixtech Mosaix Technologies, Inc. moxa Moxa mpl MPL AG +mundoreader Mundo Reader S.L. mxicy Macronix International Co., Ltd. national National Semiconductor neonode Neonode Inc. @@ -98,6 +99,7 @@ powervr PowerVR (deprecated, use img) qca Qualcomm Atheros, Inc. qcom Qualcomm Technologies, Inc qnap QNAP Systems, Inc. +radxa Radxa raidsonic RaidSonic Technology GmbH ralink Mediatek/Ralink Technology Corp. ramtron Ramtron International -- cgit v1.1 From ac4eba8e6d1ec0f891f7f67f8106dd9977ed0373 Mon Sep 17 00:00:00 2001 From: Beniamino Galvani Date: Tue, 6 May 2014 19:10:11 +0200 Subject: ARM: dts: rockchip: add root compatible properties Add the missing 'compatible' property to device tree root node of - rk3066a-bqcurie2.dts - rk3188-radxarock.dts and document the new values. Signed-off-by: Beniamino Galvani Acked-by: Rob Herring Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/arm/rockchip.txt | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/rockchip.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt new file mode 100644 index 0000000..857f126 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/rockchip.txt @@ -0,0 +1,10 @@ +Rockchip platforms device tree bindings +--------------------------------------- + +- bq Curie 2 tablet: + Required root node properties: + - compatible = "mundoreader,bq-curie2", "rockchip,rk3066a"; + +- Radxa Rock board: + Required root node properties: + - compatible = "radxa,rock", "rockchip,rk3188"; -- cgit v1.1 From 7a5091d58419b4e5222abce58a40c072786ea1d6 Mon Sep 17 00:00:00 2001 From: "H. Peter Anvin" Date: Sun, 11 May 2014 20:25:20 -0700 Subject: x86, rdrand: When nordrand is specified, disable RDSEED as well One can logically expect that when the user has specified "nordrand", the user doesn't want any use of the CPU random number generator, neither RDRAND nor RDSEED, so disable both. Reported-by: Stephan Mueller Cc: Theodore Ts'o Link: http://lkml.kernel.org/r/21542339.0lFnPSyGRS@myon.chronox.de Signed-off-by: H. Peter Anvin --- Documentation/kernel-parameters.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 4384217..30a8ad0d 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2218,10 +2218,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. noreplace-smp [X86-32,SMP] Don't replace SMP instructions with UP alternatives - nordrand [X86] Disable the direct use of the RDRAND - instruction even if it is supported by the - processor. RDRAND is still available to user - space applications. + nordrand [X86] Disable kernel use of the RDRAND and + RDSEED instructions even if they are supported + by the processor. RDRAND and RDSEED are still + available to user space applications. noresume [SWSUSP] Disables resume and restores original swap space. -- cgit v1.1 From 5efaf09021a5817e5a274aa2d2fad8d92d12ed92 Mon Sep 17 00:00:00 2001 From: Zhangfei Gao Date: Mon, 21 Apr 2014 12:07:27 +0800 Subject: clk: hisi: add clk-hix5hd2.c Signed-off-by: Haifeng Yan Signed-off-by: Zhangfei Gao Signed-off-by: Haojian Zhuang --- .../devicetree/bindings/clock/hix5hd2-clock.txt | 31 ++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/hix5hd2-clock.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/hix5hd2-clock.txt b/Documentation/devicetree/bindings/clock/hix5hd2-clock.txt new file mode 100644 index 0000000..7894a64 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/hix5hd2-clock.txt @@ -0,0 +1,31 @@ +* Hisilicon Hix5hd2 Clock Controller + +The hix5hd2 clock controller generates and supplies clock to various +controllers within the hix5hd2 SoC. + +Required Properties: + +- compatible: should be "hisilicon,hix5hd2-clock" +- reg: Address and length of the register set +- #clock-cells: Should be <1> + +Each clock is assigned an identifier and client nodes use this identifier +to specify the clock which they consume. + +All these identifier could be found in . + +Examples: + clock: clock@f8a22000 { + compatible = "hisilicon,hix5hd2-clock"; + reg = <0xf8a22000 0x1000>; + #clock-cells = <1>; + }; + + uart0: uart@f8b00000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0xf8b00000 0x1000>; + interrupts = <0 49 4>; + clocks = <&clock HIX5HD2_FIXED_83M>; + clock-names = "apb_pclk"; + status = "disabled"; + }; -- cgit v1.1 From dc03294ac0b71ab110ad503ca18fc50f0eb15576 Mon Sep 17 00:00:00 2001 From: Ulf Hansson Date: Wed, 19 Mar 2014 12:55:35 +0100 Subject: mmc: mmci: Update DT documentation Document how to configure the regulator supplies and add an example of a typical mmci DT node. Signed-off-by: Ulf Hansson --- Documentation/devicetree/bindings/mmc/mmci.txt | 39 ++++++++++++++++++++++++-- 1 file changed, 36 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt b/Documentation/devicetree/bindings/mmc/mmci.txt index 2b584ca..ff233d1 100644 --- a/Documentation/devicetree/bindings/mmc/mmci.txt +++ b/Documentation/devicetree/bindings/mmc/mmci.txt @@ -8,8 +8,41 @@ by mmc.txt and the properties used by the mmci driver. Required properties: - compatible : contains "arm,pl18x", "arm,primecell". -- arm,primecell-periphid : contains the PrimeCell Peripheral ID. +- vmmc-supply : phandle to the regulator device tree node, mentioned + as the VCC/VDD supply in the eMMC/SD specs. Optional properties: -- mmc-cap-mmc-highspeed : indicates whether MMC is high speed capable -- mmc-cap-sd-highspeed : indicates whether SD is high speed capable +- arm,primecell-periphid : contains the PrimeCell Peripheral ID, it overrides + the ID provided by the HW +- mmc-cap-mmc-highspeed : indicates whether MMC is high speed capable. +- mmc-cap-sd-highspeed : indicates whether SD is high speed capable. +- vqmmc-supply : phandle to the regulator device tree node, mentioned + as the VCCQ/VDD_IO supply in the eMMC/SD specs. + +Example: + +sdi0_per1@80126000 { + compatible = "arm,pl18x", "arm,primecell"; + reg = <0x80126000 0x1000>; + interrupts = <0 60 IRQ_TYPE_LEVEL_HIGH>; + + dmas = <&dma 29 0 0x2>, /* Logical - DevToMem */ + <&dma 29 0 0x0>; /* Logical - MemToDev */ + dma-names = "rx", "tx"; + + clocks = <&prcc_kclk 1 5>, <&prcc_pclk 1 5>; + clock-names = "sdi", "apb_pclk"; + + max-frequency = <100000000>; + bus-width = <4>; + mmc-cap-sd-highspeed; + mmc-cap-mmc-highspeed; + cd-gpios = <&gpio2 31 0x4>; // 95 + + vmmc-supply = <&ab8500_ldo_aux3_reg>; + vqmmc-supply = <&vmmci>; + + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&sdi0_default_mode>; + pinctrl-1 = <&sdi0_sleep_mode>; +}; -- cgit v1.1 From ae94cafe293343c2680c638c7af8499d708e4d71 Mon Sep 17 00:00:00 2001 From: Ulf Hansson Date: Tue, 18 Mar 2014 10:46:37 +0100 Subject: mmc: mmci: Add DT bindings for signal direction Some variants have support for indicating the bus signal directions, which currently are configured through platform data. Add corresponding DT bindings to enable us to move away from using the platform data. Signed-off-by: Ulf Hansson Reviewed-by: Linus Walleij --- Documentation/devicetree/bindings/mmc/mmci.txt | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt b/Documentation/devicetree/bindings/mmc/mmci.txt index ff233d1..9bd2ffa 100644 --- a/Documentation/devicetree/bindings/mmc/mmci.txt +++ b/Documentation/devicetree/bindings/mmc/mmci.txt @@ -4,7 +4,8 @@ The ARM PrimeCell MMCI PL180 and PL181 provides an interface for reading and writing to MultiMedia and SD cards alike. This file documents differences between the core properties described -by mmc.txt and the properties used by the mmci driver. +by mmc.txt and the properties used by the mmci driver. Using "st" as +the prefix for a property, indicates support by the ST Micro variant. Required properties: - compatible : contains "arm,pl18x", "arm,primecell". @@ -18,6 +19,11 @@ Optional properties: - mmc-cap-sd-highspeed : indicates whether SD is high speed capable. - vqmmc-supply : phandle to the regulator device tree node, mentioned as the VCCQ/VDD_IO supply in the eMMC/SD specs. +- st,sig-dir-dat0 : bus signal direction pin used for DAT[0]. +- st,sig-dir-dat2 : bus signal direction pin used for DAT[2]. +- st,sig-dir-dat31 : bus signal direction pin used for DAT[3] and DAT[1]. +- st,sig-dir-dat74 : bus signal direction pin used for DAT[4] to DAT[7]. +- st,sig-dir-cmd : cmd signal direction pin used for CMD. Example: @@ -38,6 +44,9 @@ sdi0_per1@80126000 { mmc-cap-sd-highspeed; mmc-cap-mmc-highspeed; cd-gpios = <&gpio2 31 0x4>; // 95 + st,sig-dir-dat0; + st,sig-dir-dat2; + st,sig-dir-cmd; vmmc-supply = <&ab8500_ldo_aux3_reg>; vqmmc-supply = <&vmmci>; -- cgit v1.1 From 1a7e99c1fe080cc75ab34e1cbf788ed09b2f58b5 Mon Sep 17 00:00:00 2001 From: Ulf Hansson Date: Mon, 31 Mar 2014 14:19:21 +0200 Subject: mmc: mmci: Add DT bindings for feedback clock pin The ST Micro variant supports the option of using a feedback clock signal in favor of the clockout pin when latching incoming signals on the data bus. Since this is matter of how pins are being routed we need to provide a new DT binding to be able to configure this through DT. Signed-off-by: Ulf Hansson Reviewed-by: Linus Walleij --- Documentation/devicetree/bindings/mmc/mmci.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt b/Documentation/devicetree/bindings/mmc/mmci.txt index 9bd2ffa..2c8756f 100644 --- a/Documentation/devicetree/bindings/mmc/mmci.txt +++ b/Documentation/devicetree/bindings/mmc/mmci.txt @@ -24,6 +24,7 @@ Optional properties: - st,sig-dir-dat31 : bus signal direction pin used for DAT[3] and DAT[1]. - st,sig-dir-dat74 : bus signal direction pin used for DAT[4] to DAT[7]. - st,sig-dir-cmd : cmd signal direction pin used for CMD. +- st,sig-pin-fbclk : feedback clock signal pin used. Example: @@ -47,6 +48,7 @@ sdi0_per1@80126000 { st,sig-dir-dat0; st,sig-dir-dat2; st,sig-dir-cmd; + st,sig-pin-fbclk; vmmc-supply = <&ab8500_ldo_aux3_reg>; vqmmc-supply = <&vmmci>; -- cgit v1.1 From 3ad418e0f0c8ab78222f2db9547b21a2902d5a21 Mon Sep 17 00:00:00 2001 From: Ulf Hansson Date: Wed, 19 Mar 2014 13:38:05 +0100 Subject: mmc: mmci: Mark the DT bindings for highspeed mode as deprecated The common mmc DT parser supports bindings for highspeed mode, thus there are no need for mmci to provide it's own versions for these. Mark them as deprecated in the documentation. Signed-off-by: Ulf Hansson Acked-by: Linus Walleij Acked-by: Rob Herring --- Documentation/devicetree/bindings/mmc/mmci.txt | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt b/Documentation/devicetree/bindings/mmc/mmci.txt index 2c8756f..03796cf 100644 --- a/Documentation/devicetree/bindings/mmc/mmci.txt +++ b/Documentation/devicetree/bindings/mmc/mmci.txt @@ -15,8 +15,6 @@ Required properties: Optional properties: - arm,primecell-periphid : contains the PrimeCell Peripheral ID, it overrides the ID provided by the HW -- mmc-cap-mmc-highspeed : indicates whether MMC is high speed capable. -- mmc-cap-sd-highspeed : indicates whether SD is high speed capable. - vqmmc-supply : phandle to the regulator device tree node, mentioned as the VCCQ/VDD_IO supply in the eMMC/SD specs. - st,sig-dir-dat0 : bus signal direction pin used for DAT[0]. @@ -26,6 +24,10 @@ Optional properties: - st,sig-dir-cmd : cmd signal direction pin used for CMD. - st,sig-pin-fbclk : feedback clock signal pin used. +Deprecated properties: +- mmc-cap-mmc-highspeed : indicates whether MMC is high speed capable. +- mmc-cap-sd-highspeed : indicates whether SD is high speed capable. + Example: sdi0_per1@80126000 { @@ -42,8 +44,8 @@ sdi0_per1@80126000 { max-frequency = <100000000>; bus-width = <4>; - mmc-cap-sd-highspeed; - mmc-cap-mmc-highspeed; + cap-sd-highspeed; + cap-mmc-highspeed; cd-gpios = <&gpio2 31 0x4>; // 95 st,sig-dir-dat0; st,sig-dir-dat2; -- cgit v1.1 From 886cda418b2866386c2ed157252fb0369afc4357 Mon Sep 17 00:00:00 2001 From: Shawn Guo Date: Sat, 19 Apr 2014 11:15:06 +0800 Subject: ARM: imx6q: add the missing esai_ahb clock The esai_ahb clock is derived from ahb and used to provide ESAI the capability of register accessing and FSYS clock source for I2S clocks dividing. The gate bits of this esai_ahb clock are shared with the esai clock -- the baud clock, so we need to call imx_clk_gate2_shared() for these two clocks. Signed-off-by: Nicolin Chen 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 6aab72b..90ec91f 100644 --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt @@ -220,6 +220,7 @@ clocks and IDs. lvds2_sel 205 lvds1_gate 206 lvds2_gate 207 + esai_ahb 208 Examples: -- cgit v1.1 From 7654874ebb56d10e2a12a6511fd28c08ef8dd5ff Mon Sep 17 00:00:00 2001 From: Alexander Shiyan Date: Sun, 20 Apr 2014 09:18:51 +0400 Subject: ARM: i.MX27 clk: Add missing clocks for MSHC and RTIC This patch adds missing clocks handling for the Memory Stick Host Controller (MSHC) and Run-Time Integrity Checker (RTIC). Signed-off-by: Alexander Shiyan Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/clock/imx27-clock.txt | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/imx27-clock.txt b/Documentation/devicetree/bindings/clock/imx27-clock.txt index 7a20703..6bc9fd2 100644 --- a/Documentation/devicetree/bindings/clock/imx27-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx27-clock.txt @@ -98,7 +98,12 @@ clocks and IDs. fpm 83 mpll_osc_sel 84 mpll_sel 85 - spll_gate 86 + spll_gate 86 + mshc_div 87 + rtic_ipg_gate 88 + mshc_ipg_gate 89 + rtic_ahb_gate 90 + mshc_baud_gate 91 Examples: -- cgit v1.1 From 60b6dbeffb8c253d1f80527b28611e5e236dec51 Mon Sep 17 00:00:00 2001 From: Apelete Seketeli Date: Mon, 14 Apr 2014 22:12:56 +0200 Subject: documentation: docbook: document process of writing an musb glue layer Document the process of writing an musb glue layer by taking the Ingenic JZ4740 glue layer as an example, as it seems more simple than most glue layers due to the basic feature set of the JZ4740 USB device controller. Signed-off-by: Apelete Seketeli Signed-off-by: Felipe Balbi --- Documentation/DocBook/Makefile | 3 +- Documentation/DocBook/writing_musb_glue_layer.tmpl | 873 +++++++++++++++++++++ 2 files changed, 875 insertions(+), 1 deletion(-) create mode 100644 Documentation/DocBook/writing_musb_glue_layer.tmpl (limited to 'Documentation') diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index b444f2e..bec0665 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -14,7 +14,8 @@ DOCBOOKS := z8530book.xml device-drivers.xml \ genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ 80211.xml debugobjects.xml sh.xml regulator.xml \ alsa-driver-api.xml writing-an-alsa-driver.xml \ - tracepoint.xml drm.xml media_api.xml w1.xml + tracepoint.xml drm.xml media_api.xml w1.xml \ + writing_musb_glue_layer.xml include Documentation/DocBook/media/Makefile diff --git a/Documentation/DocBook/writing_musb_glue_layer.tmpl b/Documentation/DocBook/writing_musb_glue_layer.tmpl new file mode 100644 index 0000000..837eca7 --- /dev/null +++ b/Documentation/DocBook/writing_musb_glue_layer.tmpl @@ -0,0 +1,873 @@ + + + + + + Writing an MUSB Glue Layer + + + + Apelete + Seketeli + +
+ apelete at seketeli.net +
+ + + + + + 2014 + Apelete Seketeli + + + + + This documentation is free software; you can redistribute it + and/or modify it under the terms of the GNU General Public + License as published by the Free Software Foundation; either + version 2 of the License, or (at your option) any later version. + + + + This documentation is distributed in the hope that it will be + useful, but WITHOUT ANY WARRANTY; without even the implied + warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + See the GNU General Public License for more details. + + + + You should have received a copy of the GNU General Public License + along with this documentation; if not, write to the Free Software + Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + 02111-1307 USA + + + + For more details see the file COPYING in the Linux kernel source + tree. + + + + + + + + Introduction + + The Linux MUSB subsystem is part of the larger Linux USB + subsystem. It provides support for embedded USB Device Controllers + (UDC) that do not use Universal Host Controller Interface (UHCI) + or Open Host Controller Interface (OHCI). + + + Instead, these embedded UDC rely on the USB On-the-Go (OTG) + specification which they implement at least partially. The silicon + reference design used in most cases is the Multipoint USB + Highspeed Dual-Role Controller (MUSB HDRC) found in the Mentor + Graphics Inventra™ design. + + + As a self-taught exercise I have written an MUSB glue layer for + the Ingenic JZ4740 SoC, modelled after the many MUSB glue layers + in the kernel source tree. This layer can be found at + drivers/usb/musb/jz4740.c. In this documentation I will walk + through the basics of the jz4740.c glue layer, explaining the + different pieces and what needs to be done in order to write your + own device glue layer. + + + + + Linux MUSB Basics + + To get started on the topic, please read USB On-the-Go Basics (see + Resources) which provides an introduction of USB OTG operation at + the hardware level. A couple of wiki pages by Texas Instruments + and Analog Devices also provide an overview of the Linux kernel + MUSB configuration, albeit focused on some specific devices + provided by these companies. Finally, getting acquainted with the + USB specification at USB home page may come in handy, with + practical instance provided through the Writing USB Device Drivers + documentation (again, see Resources). + + + Linux USB stack is a layered architecture in which the MUSB + controller hardware sits at the lowest. The MUSB controller driver + abstract the MUSB controller hardware to the Linux USB stack. + + + ------------------------ + | | <------- drivers/usb/gadget + | Linux USB Core Stack | <------- drivers/usb/host + | | <------- drivers/usb/core + ------------------------ + ⬍ + -------------------------- + | | <------ drivers/usb/musb/musb_gadget.c + | MUSB Controller driver | <------ drivers/usb/musb/musb_host.c + | | <------ drivers/usb/musb/musb_core.c + -------------------------- + ⬍ + --------------------------------- + | MUSB Platform Specific Driver | + | | <-- drivers/usb/musb/jz4740.c + | aka "Glue Layer" | + --------------------------------- + ⬍ + --------------------------------- + | MUSB Controller Hardware | + --------------------------------- + + + As outlined above, the glue layer is actually the platform + specific code sitting in between the controller driver and the + controller hardware. + + + Just like a Linux USB driver needs to register itself with the + Linux USB subsystem, the MUSB glue layer needs first to register + itself with the MUSB controller driver. This will allow the + controller driver to know about which device the glue layer + supports and which functions to call when a supported device is + detected or released; remember we are talking about an embedded + controller chip here, so no insertion or removal at run-time. + + + All of this information is passed to the MUSB controller driver + through a platform_driver structure defined in the glue layer as: + + +static struct platform_driver jz4740_driver = { + .probe = jz4740_probe, + .remove = jz4740_remove, + .driver = { + .name = "musb-jz4740", + }, +}; + + + The probe and remove function pointers are called when a matching + device is detected and, respectively, released. The name string + describes the device supported by this glue layer. In the current + case it matches a platform_device structure declared in + arch/mips/jz4740/platform.c. Note that we are not using device + tree bindings here. + + + In order to register itself to the controller driver, the glue + layer goes through a few steps, basically allocating the + controller hardware resources and initialising a couple of + circuits. To do so, it needs to keep track of the information used + throughout these steps. This is done by defining a private + jz4740_glue structure: + + +struct jz4740_glue { + struct device *dev; + struct platform_device *musb; + struct clk *clk; +}; + + + The dev and musb members are both device structure variables. The + first one holds generic information about the device, since it's + the basic device structure, and the latter holds information more + closely related to the subsystem the device is registered to. The + clk variable keeps information related to the device clock + operation. + + + Let's go through the steps of the probe function that leads the + glue layer to register itself to the controller driver. + + + N.B.: For the sake of readability each function will be split in + logical parts, each part being shown as if it was independent from + the others. + + +static int jz4740_probe(struct platform_device *pdev) +{ + struct platform_device *musb; + struct jz4740_glue *glue; + struct clk *clk; + int ret; + + glue = devm_kzalloc(&pdev->dev, sizeof(*glue), GFP_KERNEL); + if (!glue) + return -ENOMEM; + + musb = platform_device_alloc("musb-hdrc", PLATFORM_DEVID_AUTO); + if (!musb) { + dev_err(&pdev->dev, "failed to allocate musb device\n"); + return -ENOMEM; + } + + clk = devm_clk_get(&pdev->dev, "udc"); + if (IS_ERR(clk)) { + dev_err(&pdev->dev, "failed to get clock\n"); + ret = PTR_ERR(clk); + goto err_platform_device_put; + } + + ret = clk_prepare_enable(clk); + if (ret) { + dev_err(&pdev->dev, "failed to enable clock\n"); + goto err_platform_device_put; + } + + musb->dev.parent = &pdev->dev; + + glue->dev = &pdev->dev; + glue->musb = musb; + glue->clk = clk; + + return 0; + +err_platform_device_put: + platform_device_put(musb); + return ret; +} + + + The first few lines of the probe function allocate and assign the + glue, musb and clk variables. The GFP_KERNEL flag (line 8) allows + the allocation process to sleep and wait for memory, thus being + usable in a blocking situation. The PLATFORM_DEVID_AUTO flag (line + 12) allows automatic allocation and management of device IDs in + order to avoid device namespace collisions with explicit IDs. With + devm_clk_get() (line 18) the glue layer allocates the clock -- the + devm_ prefix indicates that clk_get() is + managed: it automatically frees the allocated clock resource data + when the device is released -- and enable it. + + + Then comes the registration steps: + + +static int jz4740_probe(struct platform_device *pdev) +{ + struct musb_hdrc_platform_data *pdata = &jz4740_musb_platform_data; + + pdata->platform_ops = &jz4740_musb_ops; + + platform_set_drvdata(pdev, glue); + + ret = platform_device_add_resources(musb, pdev->resource, + pdev->num_resources); + if (ret) { + dev_err(&pdev->dev, "failed to add resources\n"); + goto err_clk_disable; + } + + ret = platform_device_add_data(musb, pdata, sizeof(*pdata)); + if (ret) { + dev_err(&pdev->dev, "failed to add platform_data\n"); + goto err_clk_disable; + } + + return 0; + +err_clk_disable: + clk_disable_unprepare(clk); +err_platform_device_put: + platform_device_put(musb); + return ret; +} + + + The first step is to pass the device data privately held by the + glue layer on to the controller driver through + platform_set_drvdata() (line 7). Next is passing on the device + resources information, also privately held at that point, through + platform_device_add_resources() (line 9). + + + Finally comes passing on the platform specific data to the + controller driver (line 16). Platform data will be discussed in + Chapter 4, but here + we are looking at the platform_ops function pointer (line 5) in + musb_hdrc_platform_data structure (line 3). This function + pointer allows the MUSB controller driver to know which function + to call for device operation: + + +static const struct musb_platform_ops jz4740_musb_ops = { + .init = jz4740_musb_init, + .exit = jz4740_musb_exit, +}; + + + Here we have the minimal case where only init and exit functions + are called by the controller driver when needed. Fact is the + JZ4740 MUSB controller is a basic controller, lacking some + features found in other controllers, otherwise we may also have + pointers to a few other functions like a power management function + or a function to switch between OTG and non-OTG modes, for + instance. + + + At that point of the registration process, the controller driver + actually calls the init function: + + +static int jz4740_musb_init(struct musb *musb) +{ + musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2); + if (!musb->xceiv) { + pr_err("HS UDC: no transceiver configured\n"); + return -ENODEV; + } + + /* Silicon does not implement ConfigData register. + * Set dyn_fifo to avoid reading EP config from hardware. + */ + musb->dyn_fifo = true; + + musb->isr = jz4740_musb_interrupt; + + return 0; +} + + + The goal of jz4740_musb_init() is to get hold of the transceiver + driver data of the MUSB controller hardware and pass it on to the + MUSB controller driver, as usual. The transceiver is the circuitry + inside the controller hardware responsible for sending/receiving + the USB data. Since it is an implementation of the physical layer + of the OSI model, the transceiver is also referred to as PHY. + + + Getting hold of the MUSB PHY driver data is done with + usb_get_phy() which returns a pointer to the structure + containing the driver instance data. The next couple of + instructions (line 12 and 14) are used as a quirk and to setup + IRQ handling respectively. Quirks and IRQ handling will be + discussed later in Chapter + 5 and Chapter 3. + + +static int jz4740_musb_exit(struct musb *musb) +{ + usb_put_phy(musb->xceiv); + + return 0; +} + + + Acting as the counterpart of init, the exit function releases the + MUSB PHY driver when the controller hardware itself is about to be + released. + + + Again, note that init and exit are fairly simple in this case due + to the basic set of features of the JZ4740 controller hardware. + When writing an musb glue layer for a more complex controller + hardware, you might need to take care of more processing in those + two functions. + + + Returning from the init function, the MUSB controller driver jumps + back into the probe function: + + +static int jz4740_probe(struct platform_device *pdev) +{ + ret = platform_device_add(musb); + if (ret) { + dev_err(&pdev->dev, "failed to register musb device\n"); + goto err_clk_disable; + } + + return 0; + +err_clk_disable: + clk_disable_unprepare(clk); +err_platform_device_put: + platform_device_put(musb); + return ret; +} + + + This is the last part of the device registration process where the + glue layer adds the controller hardware device to Linux kernel + device hierarchy: at this stage, all known information about the + device is passed on to the Linux USB core stack. + + +static int jz4740_remove(struct platform_device *pdev) +{ + struct jz4740_glue *glue = platform_get_drvdata(pdev); + + platform_device_unregister(glue->musb); + clk_disable_unprepare(glue->clk); + + return 0; +} + + + Acting as the counterpart of probe, the remove function unregister + the MUSB controller hardware (line 5) and disable the clock (line + 6), allowing it to be gated. + + + + + Handling IRQs + + Additionally to the MUSB controller hardware basic setup and + registration, the glue layer is also responsible for handling the + IRQs: + + +static irqreturn_t jz4740_musb_interrupt(int irq, void *__hci) +{ + unsigned long flags; + irqreturn_t retval = IRQ_NONE; + struct musb *musb = __hci; + + spin_lock_irqsave(&musb->lock, flags); + + musb->int_usb = musb_readb(musb->mregs, MUSB_INTRUSB); + musb->int_tx = musb_readw(musb->mregs, MUSB_INTRTX); + musb->int_rx = musb_readw(musb->mregs, MUSB_INTRRX); + + /* + * The controller is gadget only, the state of the host mode IRQ bits is + * undefined. Mask them to make sure that the musb driver core will + * never see them set + */ + musb->int_usb &= MUSB_INTR_SUSPEND | MUSB_INTR_RESUME | + MUSB_INTR_RESET | MUSB_INTR_SOF; + + if (musb->int_usb || musb->int_tx || musb->int_rx) + retval = musb_interrupt(musb); + + spin_unlock_irqrestore(&musb->lock, flags); + + return retval; +} + + + Here the glue layer mostly has to read the relevant hardware + registers and pass their values on to the controller driver which + will handle the actual event that triggered the IRQ. + + + The interrupt handler critical section is protected by the + spin_lock_irqsave() and counterpart spin_unlock_irqrestore() + functions (line 7 and 24 respectively), which prevent the + interrupt handler code to be run by two different threads at the + same time. + + + Then the relevant interrupt registers are read (line 9 to 11): + + + + + MUSB_INTRUSB: indicates which USB interrupts are currently + active, + + + + + MUSB_INTRTX: indicates which of the interrupts for TX + endpoints are currently active, + + + + + MUSB_INTRRX: indicates which of the interrupts for TX + endpoints are currently active. + + + + + Note that musb_readb() is used to read 8-bit registers at most, + while musb_readw() allows us to read at most 16-bit registers. + There are other functions that can be used depending on the size + of your device registers. See musb_io.h for more information. + + + Instruction on line 18 is another quirk specific to the JZ4740 + USB device controller, which will be discussed later in Chapter 5. + + + The glue layer still needs to register the IRQ handler though. + Remember the instruction on line 14 of the init function: + + +static int jz4740_musb_init(struct musb *musb) +{ + musb->isr = jz4740_musb_interrupt; + + return 0; +} + + + This instruction sets a pointer to the glue layer IRQ handler + function, in order for the controller hardware to call the handler + back when an IRQ comes from the controller hardware. The interrupt + handler is now implemented and registered. + + + + + Device Platform Data + + In order to write an MUSB glue layer, you need to have some data + describing the hardware capabilities of your controller hardware, + which is called the platform data. + + + Platform data is specific to your hardware, though it may cover a + broad range of devices, and is generally found somewhere in the + arch/ directory, depending on your device architecture. + + + For instance, platform data for the JZ4740 SoC is found in + arch/mips/jz4740/platform.c. In the platform.c file each device of + the JZ4740 SoC is described through a set of structures. + + + Here is the part of arch/mips/jz4740/platform.c that covers the + USB Device Controller (UDC): + + +/* USB Device Controller */ +struct platform_device jz4740_udc_xceiv_device = { + .name = "usb_phy_gen_xceiv", + .id = 0, +}; + +static struct resource jz4740_udc_resources[] = { + [0] = { + .start = JZ4740_UDC_BASE_ADDR, + .end = JZ4740_UDC_BASE_ADDR + 0x10000 - 1, + .flags = IORESOURCE_MEM, + }, + [1] = { + .start = JZ4740_IRQ_UDC, + .end = JZ4740_IRQ_UDC, + .flags = IORESOURCE_IRQ, + .name = "mc", + }, +}; + +struct platform_device jz4740_udc_device = { + .name = "musb-jz4740", + .id = -1, + .dev = { + .dma_mask = &jz4740_udc_device.dev.coherent_dma_mask, + .coherent_dma_mask = DMA_BIT_MASK(32), + }, + .num_resources = ARRAY_SIZE(jz4740_udc_resources), + .resource = jz4740_udc_resources, +}; + + + The jz4740_udc_xceiv_device platform device structure (line 2) + describes the UDC transceiver with a name and id number. + + + At the time of this writing, note that + "usb_phy_gen_xceiv" is the specific name to be used for + all transceivers that are either built-in with reference USB IP or + autonomous and doesn't require any PHY programming. You will need + to set CONFIG_NOP_USB_XCEIV=y in the kernel configuration to make + use of the corresponding transceiver driver. The id field could be + set to -1 (equivalent to PLATFORM_DEVID_NONE), -2 (equivalent to + PLATFORM_DEVID_AUTO) or start with 0 for the first device of this + kind if we want a specific id number. + + + The jz4740_udc_resources resource structure (line 7) defines the + UDC registers base addresses. + + + The first array (line 9 to 11) defines the UDC registers base + memory addresses: start points to the first register memory + address, end points to the last register memory address and the + flags member defines the type of resource we are dealing with. So + IORESOURCE_MEM is used to define the registers memory addresses. + The second array (line 14 to 17) defines the UDC IRQ registers + addresses. Since there is only one IRQ register available for the + JZ4740 UDC, start and end point at the same address. The + IORESOURCE_IRQ flag tells that we are dealing with IRQ resources, + and the name "mc" is in fact hard-coded in the MUSB core + in order for the controller driver to retrieve this IRQ resource + by querying it by its name. + + + Finally, the jz4740_udc_device platform device structure (line 21) + describes the UDC itself. + + + The "musb-jz4740" name (line 22) defines the MUSB + driver that is used for this device; remember this is in fact + the name that we used in the jz4740_driver platform driver + structure in Chapter + 2. The id field (line 23) is set to -1 (equivalent to + PLATFORM_DEVID_NONE) since we do not need an id for the device: + the MUSB controller driver was already set to allocate an + automatic id in Chapter + 2. In the dev field we care for DMA related information + here. The dma_mask field (line 25) defines the width of the DMA + mask that is going to be used, and coherent_dma_mask (line 26) + has the same purpose but for the alloc_coherent DMA mappings: in + both cases we are using a 32 bits mask. Then the resource field + (line 29) is simply a pointer to the resource structure defined + before, while the num_resources field (line 28) keeps track of + the number of arrays defined in the resource structure (in this + case there were two resource arrays defined before). + + + With this quick overview of the UDC platform data at the arch/ + level now done, let's get back to the MUSB glue layer specific + platform data in drivers/usb/musb/jz4740.c: + + +static struct musb_hdrc_config jz4740_musb_config = { + /* Silicon does not implement USB OTG. */ + .multipoint = 0, + /* Max EPs scanned, driver will decide which EP can be used. */ + .num_eps = 4, + /* RAMbits needed to configure EPs from table */ + .ram_bits = 9, + .fifo_cfg = jz4740_musb_fifo_cfg, + .fifo_cfg_size = ARRAY_SIZE(jz4740_musb_fifo_cfg), +}; + +static struct musb_hdrc_platform_data jz4740_musb_platform_data = { + .mode = MUSB_PERIPHERAL, + .config = &jz4740_musb_config, +}; + + + First the glue layer configures some aspects of the controller + driver operation related to the controller hardware specifics. + This is done through the jz4740_musb_config musb_hdrc_config + structure. + + + Defining the OTG capability of the controller hardware, the + multipoint member (line 3) is set to 0 (equivalent to false) + since the JZ4740 UDC is not OTG compatible. Then num_eps (line + 5) defines the number of USB endpoints of the controller + hardware, including endpoint 0: here we have 3 endpoints + + endpoint 0. Next is ram_bits (line 7) which is the width of the + RAM address bus for the MUSB controller hardware. This + information is needed when the controller driver cannot + automatically configure endpoints by reading the relevant + controller hardware registers. This issue will be discussed when + we get to device quirks in Chapter + 5. Last two fields (line 8 and 9) are also about device + quirks: fifo_cfg points to the USB endpoints configuration table + and fifo_cfg_size keeps track of the size of the number of + entries in that configuration table. More on that later in Chapter 5. + + + Then this configuration is embedded inside + jz4740_musb_platform_data musb_hdrc_platform_data structure (line + 11): config is a pointer to the configuration structure itself, + and mode tells the controller driver if the controller hardware + may be used as MUSB_HOST only, MUSB_PERIPHERAL only or MUSB_OTG + which is a dual mode. + + + Remember that jz4740_musb_platform_data is then used to convey + platform data information as we have seen in the probe function + in Chapter 2 + + + + + Device Quirks + + Completing the platform data specific to your device, you may also + need to write some code in the glue layer to work around some + device specific limitations. These quirks may be due to some + hardware bugs, or simply be the result of an incomplete + implementation of the USB On-the-Go specification. + + + The JZ4740 UDC exhibits such quirks, some of which we will discuss + here for the sake of insight even though these might not be found + in the controller hardware you are working on. + + + Let's get back to the init function first: + + +static int jz4740_musb_init(struct musb *musb) +{ + musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2); + if (!musb->xceiv) { + pr_err("HS UDC: no transceiver configured\n"); + return -ENODEV; + } + + /* Silicon does not implement ConfigData register. + * Set dyn_fifo to avoid reading EP config from hardware. + */ + musb->dyn_fifo = true; + + musb->isr = jz4740_musb_interrupt; + + return 0; +} + + + Instruction on line 12 helps the MUSB controller driver to work + around the fact that the controller hardware is missing registers + that are used for USB endpoints configuration. + + + Without these registers, the controller driver is unable to read + the endpoints configuration from the hardware, so we use line 12 + instruction to bypass reading the configuration from silicon, and + rely on a hard-coded table that describes the endpoints + configuration instead: + + +static struct musb_fifo_cfg jz4740_musb_fifo_cfg[] = { +{ .hw_ep_num = 1, .style = FIFO_TX, .maxpacket = 512, }, +{ .hw_ep_num = 1, .style = FIFO_RX, .maxpacket = 512, }, +{ .hw_ep_num = 2, .style = FIFO_TX, .maxpacket = 64, }, +}; + + + Looking at the configuration table above, we see that each + endpoints is described by three fields: hw_ep_num is the endpoint + number, style is its direction (either FIFO_TX for the controller + driver to send packets in the controller hardware, or FIFO_RX to + receive packets from hardware), and maxpacket defines the maximum + size of each data packet that can be transmitted over that + endpoint. Reading from the table, the controller driver knows that + endpoint 1 can be used to send and receive USB data packets of 512 + bytes at once (this is in fact a bulk in/out endpoint), and + endpoint 2 can be used to send data packets of 64 bytes at once + (this is in fact an interrupt endpoint). + + + Note that there is no information about endpoint 0 here: that one + is implemented by default in every silicon design, with a + predefined configuration according to the USB specification. For + more examples of endpoint configuration tables, see musb_core.c. + + + Let's now get back to the interrupt handler function: + + +static irqreturn_t jz4740_musb_interrupt(int irq, void *__hci) +{ + unsigned long flags; + irqreturn_t retval = IRQ_NONE; + struct musb *musb = __hci; + + spin_lock_irqsave(&musb->lock, flags); + + musb->int_usb = musb_readb(musb->mregs, MUSB_INTRUSB); + musb->int_tx = musb_readw(musb->mregs, MUSB_INTRTX); + musb->int_rx = musb_readw(musb->mregs, MUSB_INTRRX); + + /* + * The controller is gadget only, the state of the host mode IRQ bits is + * undefined. Mask them to make sure that the musb driver core will + * never see them set + */ + musb->int_usb &= MUSB_INTR_SUSPEND | MUSB_INTR_RESUME | + MUSB_INTR_RESET | MUSB_INTR_SOF; + + if (musb->int_usb || musb->int_tx || musb->int_rx) + retval = musb_interrupt(musb); + + spin_unlock_irqrestore(&musb->lock, flags); + + return retval; +} + + + Instruction on line 18 above is a way for the controller driver to + work around the fact that some interrupt bits used for USB host + mode operation are missing in the MUSB_INTRUSB register, thus left + in an undefined hardware state, since this MUSB controller + hardware is used in peripheral mode only. As a consequence, the + glue layer masks these missing bits out to avoid parasite + interrupts by doing a logical AND operation between the value read + from MUSB_INTRUSB and the bits that are actually implemented in + the register. + + + These are only a couple of the quirks found in the JZ4740 USB + device controller. Some others were directly addressed in the MUSB + core since the fixes were generic enough to provide a better + handling of the issues for others controller hardware eventually. + + + + + Conclusion + + Writing a Linux MUSB glue layer should be a more accessible task, + as this documentation tries to show the ins and outs of this + exercise. + + + The JZ4740 USB device controller being fairly simple, I hope its + glue layer serves as a good example for the curious mind. Used + with the current MUSB glue layers, this documentation should + provide enough guidance to get started; should anything gets out + of hand, the linux-usb mailing list archive is another helpful + resource to browse through. + + + + + Acknowledgements + + Many thanks to Lars-Peter Clausen and Maarten ter Huurne for + answering my questions while I was writing the JZ4740 glue layer + and for helping me out getting the code in good shape. + + + I would also like to thank the Qi-Hardware community at large for + its cheerful guidance and support. + + + + + Resources + + USB Home Page: + http://www.usb.org + + + linux-usb Mailing List Archives: + http://marc.info/?l=linux-usb + + + USB On-the-Go Basics: + http://www.maximintegrated.com/app-notes/index.mvp/id/1822 + + + Writing USB Device Drivers: + https://www.kernel.org/doc/htmldocs/writing_usb_driver/index.html + + + Texas Instruments USB Configuration Wiki Page: + http://processors.wiki.ti.com/index.php/Usbgeneralpage + + + Analog Devices Blackfin MUSB Configuration: + http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:drivers:musb + + + + -- cgit v1.1 From d8a4fb0e60c613d85eda57fd1701177ae2f1c6b5 Mon Sep 17 00:00:00 2001 From: Jaehoon Chung Date: Mon, 3 Mar 2014 11:36:41 +0900 Subject: mmc: dw_mmc: use the mmc_of_parse() instead of local parser mmc_of_parse() have been already parsed the general capability. Didn't need to use the local parser. Signed-off-by: Jaehoon Chung Acked-by: Seungwon Jeon Signed-off-by: Ulf Hansson Signed-off-by: Chris Ball --- Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt | 5 ----- 1 file changed, 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt index 8f3f133..2d4a725 100644 --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt @@ -69,10 +69,6 @@ Optional properties: * supports-highspeed: Enables support for high speed cards (up to 50MHz) -* caps2-mmc-hs200-1_8v: Supports mmc HS200 SDR 1.8V mode - -* caps2-mmc-hs200-1_2v: Supports mmc HS200 SDR 1.2V mode - * broken-cd: as documented in mmc core bindings. * vmmc-supply: The phandle to the regulator to use for vmmc. If this is @@ -103,7 +99,6 @@ board specific portions as listed below. clock-freq-min-max = <400000 200000000>; num-slots = <1>; supports-highspeed; - caps2-mmc-hs200-1_8v; broken-cd; fifo-depth = <0x80>; card-detect-delay = <200>; -- cgit v1.1 From 1b66e94e6b9995323190f31c51d8e1a6f516627e Mon Sep 17 00:00:00 2001 From: Jonas Jensen Date: Wed, 9 Apr 2014 15:54:11 +0200 Subject: mmc: moxart: Add MOXA ART SD/MMC driver Add SD/MMC driver for MOXA ART SoCs. The "MOXA ART MMC controller" is likely a faraday "ftsdc010", a controller with support in U-Boot: http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/ftsdc010_mci.c Signed-off-by: Jonas Jensen Acked-by: Arnd Bergmann Signed-off-by: Ulf Hansson Signed-off-by: Chris Ball --- .../devicetree/bindings/mmc/moxa,moxart-mmc.txt | 30 ++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt b/Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt new file mode 100644 index 0000000..b638191 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt @@ -0,0 +1,30 @@ +MOXA ART MMC Host Controller Interface + + Inherits from mmc binding[1]. + + [1] Documentation/devicetree/bindings/mmc/mmc.txt + +Required properties: + +- compatible : Must be "moxa,moxart-mmc" or "faraday,ftsdc010" +- reg : Should contain registers location and length +- interrupts : Should contain the interrupt number +- clocks : Should contain phandle for the clock feeding the MMC controller + +Optional properties: + +- dmas : Should contain two DMA channels, line request number must be 5 for + both channels +- dma-names : Must be "tx", "rx" + +Example: + + mmc: mmc@98e00000 { + compatible = "moxa,moxart-mmc"; + reg = <0x98e00000 0x5C>; + interrupts = <5 0>; + clocks = <&clk_apb>; + dmas = <&dma 5>, + <&dma 5>; + dma-names = "tx", "rx"; + }; -- cgit v1.1 From c373eb489b27b268c9b8c267b212d10864bc8cdd Mon Sep 17 00:00:00 2001 From: Seungwon Jeon Date: Wed, 23 Apr 2014 17:15:08 +0900 Subject: mmc: core: add DT bindings for eMMC HS400 1.8/1.2V Provide the option to configure these speed modes per host, for those host driver's that can't distinguish this in runtime. Specially, if host can support HS400, it means that host can also support HS200. Signed-off-by: Seungwon Jeon Signed-off-by: Ulf Hansson Signed-off-by: Chris Ball --- Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index 9dce540..3c18001 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -38,6 +38,8 @@ Optional properties: - mmc-highspeed-ddr-1_2v: eMMC high-speed DDR mode(1.2V I/O) is supported - mmc-hs200-1_8v: eMMC HS200 mode(1.8V I/O) is supported - mmc-hs200-1_2v: eMMC HS200 mode(1.2V I/O) is supported +- mmc-hs400-1_8v: eMMC HS400 mode(1.8V I/O) is supported +- mmc-hs400-1_2v: eMMC HS400 mode(1.2V I/O) is supported *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line polarity properties, we have to fix the meaning of the "normal" and "inverted" -- cgit v1.1 From f11cadd58280e3aed7f16eb648d50a8faf4ebb1a Mon Sep 17 00:00:00 2001 From: Heiko Stuebner Date: Fri, 9 May 2014 05:49:05 +0900 Subject: dt-bindings: add documentation for s3c2410 clock controller Describe the clock controller of s3c2410, s3c2440 and s3c2442. Signed-off-by: Heiko Stuebner Acked-by: Tomasz Figa Signed-off-by: Kukjin Kim --- .../bindings/clock/samsung,s3c2410-clock.txt | 50 ++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt b/Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt new file mode 100644 index 0000000..0b64ad8 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt @@ -0,0 +1,50 @@ +* Samsung S3C2410 Clock Controller + +The S3C2410 clock controller generates and supplies clock to various controllers +within the SoC. The clock binding described here is applicable to the s3c2410, +s3c2440 and s3c2442 SoCs in the s3c24x family. + +Required Properties: + +- compatible: should be one of the following. + - "samsung,s3c2410-clock" - controller compatible with S3C2410 SoC. + - "samsung,s3c2440-clock" - controller compatible with S3C2440 SoC. + - "samsung,s3c2442-clock" - controller compatible with S3C2442 SoC. +- reg: physical base address of the controller and length of memory mapped + region. +- #clock-cells: should be 1. + +Each clock is assigned an identifier and client nodes can use this identifier +to specify the clock which they consume. Some of the clocks are available only +on a particular SoC. + +All available clocks are defined as preprocessor macros in +dt-bindings/clock/samsung,s3c2410-clock.h header and can be used in device +tree sources. + +External clocks: + +The xti clock used as input for the plls is generated outside the SoC. It is +expected that is are defined using standard clock bindings with a +clock-output-names value of "xti". + +Example: Clock controller node: + + clocks: clock-controller@4c000000 { + compatible = "samsung,s3c2410-clock"; + reg = <0x4c000000 0x20>; + #clock-cells = <1>; + }; + +Example: 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" properties): + + serial@50004000 { + compatible = "samsung,s3c2440-uart"; + reg = <0x50004000 0x4000>; + interrupts = <1 23 3 4>, <1 23 4 4>; + clock-names = "uart", "clk_uart_baud2"; + clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>; + status = "disabled"; + }; -- cgit v1.1 From 8e33f91a0b84ae1964bef77cb92f5d41d97530c8 Mon Sep 17 00:00:00 2001 From: Ben Dooks Date: Tue, 15 Apr 2014 17:06:34 +0100 Subject: clk: shmobile: clk-mstp: change to using clock-indices With the addition of clock-indices, we need to change the renesas clock implementation to use these instead of the local definition of "renesas,clock-indices". Since this will break booting with older device trees, we add a simple auto-detection of which properties are present. Signed-off-by: Ben Dooks Acked-by: Geert Uytterhoeven Reviewed-by: Wolfram Sang Signed-off-by: Mike Turquette --- Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt index 5992dce..02a25d9 100644 --- a/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt @@ -43,7 +43,7 @@ Example clock-output-names = "tpu0", "mmcif1", "sdhi3", "sdhi2", "sdhi1", "sdhi0", "mmcif0"; - renesas,clock-indices = < + clock-indices = < R8A7790_CLK_TPU0 R8A7790_CLK_MMCIF1 R8A7790_CLK_SDHI3 R8A7790_CLK_SDHI2 R8A7790_CLK_SDHI1 R8A7790_CLK_SDHI0 R8A7790_CLK_MMCIF0 -- cgit v1.1 From 54e73016dd217be915ed83353d296f2a133d1ad5 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Tue, 22 Apr 2014 15:11:42 +0200 Subject: clk: Improve clk_ops documentation General: - Add parameter names to .round_rate() and .set_rate(). Documentation/clk.txt: - Add missing parameter for .set_rate(), - Add missing .debug_init(). include/linux/clk-provider.h: - Add parent rate documentation for .round_rate(), - Reorder documentation to match implementation order, - Add missing documentation for .init(). Signed-off-by: Geert Uytterhoeven Signed-off-by: Mike Turquette --- Documentation/clk.txt | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/clk.txt b/Documentation/clk.txt index c9c399a..1fee72f 100644 --- a/Documentation/clk.txt +++ b/Documentation/clk.txt @@ -68,21 +68,27 @@ the operations defined in clk.h: int (*is_enabled)(struct clk_hw *hw); unsigned long (*recalc_rate)(struct clk_hw *hw, unsigned long parent_rate); - long (*round_rate)(struct clk_hw *hw, unsigned long, - unsigned long *); + long (*round_rate)(struct clk_hw *hw, + unsigned long rate, + unsigned long *parent_rate); long (*determine_rate)(struct clk_hw *hw, unsigned long rate, unsigned long *best_parent_rate, struct clk **best_parent_clk); int (*set_parent)(struct clk_hw *hw, u8 index); u8 (*get_parent)(struct clk_hw *hw); - int (*set_rate)(struct clk_hw *hw, unsigned long); + int (*set_rate)(struct clk_hw *hw, + unsigned long rate, + unsigned long parent_rate); int (*set_rate_and_parent)(struct clk_hw *hw, unsigned long rate, - unsigned long parent_rate, u8 index); + unsigned long parent_rate, + u8 index); unsigned long (*recalc_accuracy)(struct clk_hw *hw, - unsigned long parent_accuracy); + unsigned long parent_accuracy); void (*init)(struct clk_hw *hw); + int (*debug_init)(struct clk_hw *hw, + struct dentry *dentry); }; Part 3 - hardware clk implementations -- cgit v1.1 From b4b3bfd0b319b206d4f2fe3380f3d7d594e6e414 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Mon, 14 Apr 2014 19:00:40 +0200 Subject: clk: Improve clock-indices binding documentation Improve the wording for the clock-indices binding documentation. Also replace "empty nodes" by "empty strings", as reported before by Sergei Shtylyov. Signed-off-by: Geert Uytterhoeven Acked-by: Laurent Pinchart Acked-by: Simon Horman Signed-off-by: Mike Turquette --- Documentation/devicetree/bindings/clock/clock-bindings.txt | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/clock-bindings.txt b/Documentation/devicetree/bindings/clock/clock-bindings.txt index 700e7aa..f157878 100644 --- a/Documentation/devicetree/bindings/clock/clock-bindings.txt +++ b/Documentation/devicetree/bindings/clock/clock-bindings.txt @@ -44,10 +44,9 @@ For example: clocks by index. The names should reflect the clock output signal names for the device. -clock-indices: If the identifyng number for the clocks in the node - is not linear from zero, then the this mapping allows - the mapping of identifiers into the clock-output-names - array. +clock-indices: If the identifying number for the clocks in the node + is not linear from zero, then this allows the mapping of + identifiers into the clock-output-names array. For example, if we have two clocks <&oscillator 1> and <&oscillator 3>: @@ -58,7 +57,7 @@ For example, if we have two clocks <&oscillator 1> and <&oscillator 3>: clock-output-names = "clka", "clkb"; } - This ensures we do not have any empty nodes in clock-output-names + This ensures we do not have any empty strings in clock-output-names ==Clock consumers== -- cgit v1.1 From d415fa1b88748d664b7b6a310dd8e699d2686cf7 Mon Sep 17 00:00:00 2001 From: Mugunthan V N Date: Fri, 9 May 2014 19:07:34 +0530 Subject: drivers: net: cpsw-phy-sel: add dra7xx support for phy sel Add dra7xx support for selecting the phy mode which is present in control module of dra7xx SoC Signed-off-by: Mugunthan V N Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/cpsw-phy-sel.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt b/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt index 7ff57a1..d9da911 100644 --- a/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt +++ b/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt @@ -2,7 +2,8 @@ TI CPSW Phy mode Selection Device Tree Bindings ----------------------------------------------- Required properties: -- compatible : Should be "ti,am3352-cpsw-phy-sel" +- compatible : Should be "ti,am3352-cpsw-phy-sel" for am335x platform and + "ti,dra7xx-cpsw-phy-sel" for dra7xx platform - reg : physical base address and size of the cpsw registers map - reg-names : names of the register map given in "reg" node -- cgit v1.1 From b80b93096bc05f013418e315ccc544ce2e8efc28 Mon Sep 17 00:00:00 2001 From: Mugunthan V N Date: Fri, 9 May 2014 19:07:35 +0530 Subject: drivers: net: cpsw-phy-sel: add am43xx platform support AM43xx phy mode selection is similar to AM33xx platform, so adding only the compatibility string to the driver Signed-off-by: Mugunthan V N Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/cpsw-phy-sel.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt b/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt index d9da911..764c0c7 100644 --- a/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt +++ b/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt @@ -4,6 +4,7 @@ TI CPSW Phy mode Selection Device Tree Bindings Required properties: - compatible : Should be "ti,am3352-cpsw-phy-sel" for am335x platform and "ti,dra7xx-cpsw-phy-sel" for dra7xx platform + "ti,am43xx-cpsw-phy-sel" for am43xx platform - reg : physical base address and size of the cpsw registers map - reg-names : names of the register map given in "reg" node -- cgit v1.1 From 7b42a997bfb93c6ae0709f34ec8e2860757804b5 Mon Sep 17 00:00:00 2001 From: Simon Horman Date: Fri, 18 Apr 2014 08:05:50 +0900 Subject: clk: shmobile: r8a7779: Add clocks support The R8A7779 SoC has several clocks that are too custom to be supported in a generic driver. Those clocks are all fixed rate clocks with multiplier and divisor set according to boot mode configuration. Based on work for R-Car Gen2 SoCs by Laurent Pinchart. Cc: devicetree@vger.kernel.org Acked-by: Laurent Pinchart Signed-off-by: Simon Horman Signed-off-by: Mike Turquette --- .../bindings/clock/renesas,r8a7779-cpg-clocks.txt | 27 ++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/renesas,r8a7779-cpg-clocks.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/renesas,r8a7779-cpg-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,r8a7779-cpg-clocks.txt new file mode 100644 index 0000000..ed3c8cb --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,r8a7779-cpg-clocks.txt @@ -0,0 +1,27 @@ +* Renesas R8A7779 Clock Pulse Generator (CPG) + +The CPG generates core clocks for the R8A7779. It includes one PLL and +several fixed ratio dividers + +Required Properties: + + - compatible: Must be "renesas,r8a7779-cpg-clocks" + - reg: Base address and length of the memory resource used by the CPG + + - clocks: Reference to the parent clock + - #clock-cells: Must be 1 + - clock-output-names: The names of the clocks. Supported clocks are "plla", + "z", "zs", "s", "s1", "p", "b", "out". + + +Example +------- + + cpg_clocks: cpg_clocks@ffc80000 { + compatible = "renesas,r8a7779-cpg-clocks"; + reg = <0 0xffc80000 0 0x30>; + clocks = <&extal_clk>; + #clock-cells = <1>; + clock-output-names = "plla", "z", "zs", "s", "s1", "p", + "b", "out"; + }; -- cgit v1.1 From 5483bf698f42a6f0467463b064084eb888298232 Mon Sep 17 00:00:00 2001 From: Simon Horman Date: Fri, 18 Apr 2014 08:05:51 +0900 Subject: clk: shmobile: r8a7779: Add MSTP clock support Add MSTP clock support for the r8a7779 SoC The only change required appears to be to note a new compatibility string in the bindings. Cc: devicetree@vger.kernel.org Acked-by: Laurent Pinchart Signed-off-by: Simon Horman Signed-off-by: Mike Turquette --- Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt index 02a25d9..30df825 100644 --- a/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt @@ -10,6 +10,7 @@ index in the group, from 0 to 31. Required Properties: - compatible: Must be one of the following + - "renesas,r8a7779-mstp-clocks" for R8A7779 (R-Car H1) MSTP gate clocks - "renesas,r8a7790-mstp-clocks" for R8A7790 (R-Car H2) MSTP gate clocks - "renesas,r8a7791-mstp-clocks" for R8A7791 (R-Car M2) MSTP gate clocks - "renesas,cpg-mstp-clock" for generic MSTP gate clocks -- cgit v1.1 From 9e552a04fd51ef241f8b3a15396487be9effbc2a Mon Sep 17 00:00:00 2001 From: Vivek Gautam Date: Tue, 13 May 2014 15:30:15 +0530 Subject: Documentation: Document Exynos5 USB 3.0 DRD PHY Add necessary binding documentation for USB 3.0 DRD PHY present on Exynos5 SoC series. Signed-off-by: Vivek Gautam Signed-off-by: Kishon Vijay Abraham I --- .../devicetree/bindings/phy/samsung-phy.txt | 47 ++++++++++++++++++++++ 1 file changed, 47 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index b422e38..2049261 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -114,3 +114,50 @@ Example: compatible = "samsung,exynos-sataphy-i2c"; reg = <0x38>; }; + +Samsung Exynos5 SoC series USB DRD PHY controller +-------------------------------------------------- + +Required properties: +- compatible : Should be set to one of the following supported values: + - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC, + - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC. +- reg : Register offset and length of USB DRD PHY register set; +- clocks: Clock IDs array as required by the controller +- clock-names: names of clocks correseponding to IDs in the clock property; + Required clocks: + - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock), + used for register access. + - ref: PHY's reference clock (usually crystal clock), used for + PHY operations, associated by phy name. It is used to + determine bit values for clock settings register. + For Exynos5420 this is given as 'sclk_usbphy30' in CMU. +- samsung,pmu-syscon: phandle for PMU system controller interface, used to + control pmu registers for power isolation. +- #phy-cells : from the generic PHY bindings, must be 1; + +For "samsung,exynos5250-usbdrd-phy" and "samsung,exynos5420-usbdrd-phy" +compatible PHYs, the second cell in the PHY specifier identifies the +PHY id, which is interpreted as follows: + 0 - UTMI+ type phy, + 1 - PIPE3 type phy, + +Example: + usbdrd_phy: usbphy@12100000 { + compatible = "samsung,exynos5250-usbdrd-phy"; + reg = <0x12100000 0x100>; + clocks = <&clock 286>, <&clock 1>; + clock-names = "phy", "ref"; + samsung,pmu-syscon = <&pmu_system_controller>; + #phy-cells = <1>; + }; + +- aliases: For SoCs like Exynos5420 having multiple USB 3.0 DRD PHY controllers, + 'usbdrd_phy' nodes should have numbered alias in the aliases node, + in the form of usbdrdphyN, N = 0, 1... (depending on number of + controllers). +Example: + aliases { + usbdrdphy0 = &usb3_phy0; + usbdrdphy1 = &usb3_phy1; + }; -- cgit v1.1 From aa9ba84b088a42f0ce522115675298e763815663 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Fri, 17 May 2013 12:32:46 -0300 Subject: [media] v4l: Add UYVY10_2X10 and VYUY10_2X10 media bus pixel codes Signed-off-by: Laurent Pinchart Reviewed-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/subdev-formats.xml | 128 +++++++++++++++++++++ 1 file changed, 128 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 7331ce1..6fb58de 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -1898,6 +1898,134 @@ y1 y0 + + V4L2_MBUS_FMT_UYVY10_2X10 + 0x2018 + + &dash-ent-22; + u9 + u8 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + &dash-ent-22; + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-22; + v9 + v8 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + + + + &dash-ent-22; + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + V4L2_MBUS_FMT_VYUY10_2X10 + 0x2019 + + &dash-ent-22; + v9 + v8 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + + + + &dash-ent-22; + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-22; + u9 + u8 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + &dash-ent-22; + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + V4L2_MBUS_FMT_YUYV10_2X10 0x200b -- cgit v1.1 From a678a198fdeab3368f1a3171453a7d43837e587b Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Fri, 17 May 2013 12:32:46 -0300 Subject: [media] v4l: Add UYVY10_1X20 and VYUY10_1X20 media bus pixel codes Signed-off-by: Laurent Pinchart Reviewed-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/subdev-formats.xml | 104 +++++++++++++++++++++ 1 file changed, 104 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 6fb58de..e3cbbb4 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -2436,6 +2436,110 @@ v1 v0 + + V4L2_MBUS_FMT_UYVY10_1X20 + 0x201a + + &dash-ent-12; + u9 + u8 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-12; + v9 + v8 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + V4L2_MBUS_FMT_VYUY10_1X20 + 0x201b + + &dash-ent-12; + v9 + v8 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-12; + u9 + u8 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + V4L2_MBUS_FMT_YUYV10_1X20 0x200d -- cgit v1.1 From 39d39af6093038491137decdef855c703a09f983 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Fri, 17 May 2013 12:32:46 -0300 Subject: [media] v4l: Add 12-bit YUV 4:2:0 media bus pixel codes Signed-off-by: Laurent Pinchart Reviewed-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/subdev-formats.xml | 288 +++++++++++++++++++++ 1 file changed, 288 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index e3cbbb4..a0fa7e0 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -2718,6 +2718,294 @@ v1 v0 + + V4L2_MBUS_FMT_UYVY12_2X12 + 0x201c + + &dash-ent-20; + u11 + u10 + u9 + u8 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + &dash-ent-20; + y11 + y10 + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-20; + v11 + v10 + v9 + v8 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + + + + &dash-ent-20; + y11 + y10 + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + V4L2_MBUS_FMT_VYUY12_2X12 + 0x201d + + &dash-ent-20; + v11 + v10 + v9 + v8 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + + + + &dash-ent-20; + y11 + y10 + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-20; + u11 + u10 + u9 + u8 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + &dash-ent-20; + y11 + y10 + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + V4L2_MBUS_FMT_YUYV12_2X12 + 0x201e + + &dash-ent-20; + y11 + y10 + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-20; + u11 + u10 + u9 + u8 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + &dash-ent-20; + y11 + y10 + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-20; + v11 + v10 + v9 + v8 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + V4L2_MBUS_FMT_YVYU12_2X12 + 0x201f + + &dash-ent-20; + y11 + y10 + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-20; + v11 + v10 + v9 + v8 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + + + + &dash-ent-20; + y11 + y10 + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-20; + u11 + u10 + u9 + u8 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + -- cgit v1.1 From 7ffd58ddab76969019098e97d687711451d32a3d Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Fri, 17 May 2013 12:32:46 -0300 Subject: [media] v4l: Add 12-bit YUV 4:2:2 media bus pixel codes Signed-off-by: Laurent Pinchart Reviewed-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/subdev-formats.xml | 240 +++++++++++++++++++++ 1 file changed, 240 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index a0fa7e0..b2d5a03 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -3006,6 +3006,246 @@ u1 u0 + + V4L2_MBUS_FMT_UYVY12_1X24 + 0x2020 + + &dash-ent-8; + u11 + u10 + u9 + u8 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + y11 + y10 + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-8; + v11 + v10 + v9 + v8 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + y11 + y10 + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + V4L2_MBUS_FMT_VYUY12_1X24 + 0x2021 + + &dash-ent-8; + v11 + v10 + v9 + v8 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + y11 + y10 + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-8; + u11 + u10 + u9 + u8 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + y11 + y10 + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + V4L2_MBUS_FMT_YUYV12_1X24 + 0x2022 + + &dash-ent-8; + y11 + y10 + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + u11 + u10 + u9 + u8 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + &dash-ent-8; + y11 + y10 + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + v11 + v10 + v9 + v8 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + V4L2_MBUS_FMT_YVYU12_1X24 + 0x2023 + + &dash-ent-8; + y11 + y10 + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + v11 + v10 + v9 + v8 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + + + + &dash-ent-8; + y11 + y10 + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + u11 + u10 + u9 + u8 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + -- cgit v1.1 From 93e268dca82eafb59157bfb7eb70e97fe3564412 Mon Sep 17 00:00:00 2001 From: Cho KyongHo Date: Mon, 12 May 2014 11:45:01 +0530 Subject: documentation: iommu: Add binding document of Exynos System MMU This patch adds a description of the device tree binding for the Samsung Exynos System MMU. Signed-off-by: Cho KyongHo Signed-off-by: Shaik Ameer Basha Signed-off-by: Joerg Roedel --- .../devicetree/bindings/iommu/samsung,sysmmu.txt | 65 ++++++++++++++++++++++ 1 file changed, 65 insertions(+) create mode 100644 Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt new file mode 100644 index 0000000..15b2a2b --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt @@ -0,0 +1,65 @@ +Samsung Exynos IOMMU H/W, System MMU (System Memory Management Unit) + +Samsung's Exynos architecture contains System MMUs that enables scattered +physical memory chunks visible as a contiguous region to DMA-capable peripheral +devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth. + +System MMU is an IOMMU and supports identical translation table format to +ARMv7 translation tables with minimum set of page properties including access +permissions, shareability and security protection. In addition, System MMU has +another capabilities like L2 TLB or block-fetch buffers to minimize translation +latency. + +System MMUs are in many to one relation with peripheral devices, i.e. single +peripheral device might have multiple System MMUs (usually one for each bus +master), but one System MMU can handle transactions from only one peripheral +device. The relation between a System MMU and the peripheral device needs to be +defined in device node of the peripheral device. + +MFC in all Exynos SoCs and FIMD, M2M Scalers and G2D in Exynos5420 has 2 System +MMUs. +* MFC has one System MMU on its left and right bus. +* FIMD in Exynos5420 has one System MMU for window 0 and 4, the other system MMU + for window 1, 2 and 3. +* M2M Scalers and G2D in Exynos5420 has one System MMU on the read channel and + the other System MMU on the write channel. +The drivers must consider how to handle those System MMUs. One of the idea is +to implement child devices or sub-devices which are the client devices of the +System MMU. + +Required properties: +- compatible: Should be "samsung,exynos-sysmmu" +- reg: A tuple of base address and size of System MMU registers. +- interrupt-parent: The phandle of the interrupt controller of System MMU +- interrupts: An interrupt specifier for interrupt signal of System MMU, + according to the format defined by a particular interrupt + controller. +- clock-names: Should be "sysmmu" if the System MMU is needed to gate its clock. + Optional "master" if the clock to the System MMU is gated by + another gate clock other than "sysmmu". + Exynos4 SoCs, there needs no "master" clock. + Exynos5 SoCs, some System MMUs must have "master" clocks. +- clocks: Required if the System MMU is needed to gate its clock. +- samsung,power-domain: Required if the System MMU is needed to gate its power. + Please refer to the following document: + Documentation/devicetree/bindings/arm/exynos/power_domain.txt + +Examples: + gsc_0: gsc@13e00000 { + compatible = "samsung,exynos5-gsc"; + reg = <0x13e00000 0x1000>; + interrupts = <0 85 0>; + samsung,power-domain = <&pd_gsc>; + clocks = <&clock CLK_GSCL0>; + clock-names = "gscl"; + }; + + sysmmu_gsc0: sysmmu@13E80000 { + compatible = "samsung,exynos-sysmmu"; + reg = <0x13E80000 0x1000>; + interrupt-parent = <&combiner>; + interrupts = <2 0>; + clock-names = "sysmmu", "master"; + clocks = <&clock CLK_SMMU_GSCL0>, <&clock CLK_GSCL0>; + samsung,power-domain = <&pd_gsc>; + }; -- cgit v1.1 From a563babeb5fbe721a046adf6f1cdc02e0a207c8d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= Date: Sun, 11 May 2014 10:47:14 +0200 Subject: net: cdc_mbim: add driver documentation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit An initial attempt on describing some of the odd APIs provided by this driver. Cc: Greg Suarez Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller --- Documentation/networking/cdc_mbim.txt | 339 ++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 Documentation/networking/cdc_mbim.txt (limited to 'Documentation') diff --git a/Documentation/networking/cdc_mbim.txt b/Documentation/networking/cdc_mbim.txt new file mode 100644 index 0000000..a15ea60 --- /dev/null +++ b/Documentation/networking/cdc_mbim.txt @@ -0,0 +1,339 @@ + cdc_mbim - Driver for CDC MBIM Mobile Broadband modems + ======================================================== + +The cdc_mbim driver supports USB devices conforming to the "Universal +Serial Bus Communications Class Subclass Specification for Mobile +Broadband Interface Model" [1], which is a further development of +"Universal Serial Bus Communications Class Subclass Specifications for +Network Control Model Devices" [2] optimized for Mobile Broadband +devices, aka "3G/LTE modems". + + +Command Line Parameters +======================= + +The cdc_mbim driver has no parameters of its own. But the probing +behaviour for NCM 1.0 backwards compatible MBIM functions (an +"NCM/MBIM function" as defined in section 3.2 of [1]) is affected +by a cdc_ncm driver parameter: + +prefer_mbim +----------- +Type: Boolean +Valid Range: N/Y (0-1) +Default Value: Y (MBIM is preferred) + +This parameter sets the system policy for NCM/MBIM functions. Such +functions will be handled by either the cdc_ncm driver or the cdc_mbim +driver depending on the prefer_mbim setting. Setting prefer_mbim=N +makes the cdc_mbim driver ignore these functions and lets the cdc_ncm +driver handle them instead. + +The parameter is writable, and can be changed at any time. A manual +unbind/bind is required to make the change effective for NCM/MBIM +functions bound to the "wrong" driver + + +Basic usage +=========== + +MBIM functions are inactive when unmanaged. The cdc_mbim driver only +provides an userspace interface to the MBIM control channel, and will +not participate in the management of the function. This implies that a +userspace MBIM management application always is required to enable a +MBIM function. + +Such userspace applications includes, but are not limited to: + - mbimcli (included with the libmbim [3] library), and + - ModemManager [4] + +Establishing a MBIM IP session reequires at least these actions by the +management application: + - open the control channel + - configure network connection settings + - connect to network + - configure IP interface + +Management application development +---------------------------------- +The driver <-> userspace interfaces are described below. The MBIM +control channel protocol is described in [1]. + + +MBIM control channel userspace ABI +================================== + +/dev/cdc-wdmX character device +------------------------------ +The driver creates a two-way pipe to the MBIM function control channel +using the cdc-wdm driver as a subdriver. The userspace end of the +control channel pipe is a /dev/cdc-wdmX character device. + +The cdc_mbim driver does not process or police messages on the control +channel. The channel is fully delegated to the userspace management +application. It is therefore up to this application to ensure that it +complies with all the control channel requirements in [1]. + +The cdc-wdmX device is created as a child of the MBIM control +interface USB device. The character device associated with a specific +MBIM function can be looked up using sysfs. For example: + + bjorn@nemi:~$ ls /sys/bus/usb/drivers/cdc_mbim/2-4:2.12/usbmisc + cdc-wdm0 + + bjorn@nemi:~$ grep . /sys/bus/usb/drivers/cdc_mbim/2-4:2.12/usbmisc/cdc-wdm0/dev + 180:0 + + +USB configuration descriptors +----------------------------- +The wMaxControlMessage field of the CDC MBIM functional descriptor +limits the maximum control message size. The managament application is +responsible for negotiating a control message size complying with the +requirements in section 9.3.1 of [1], taking this descriptor field +into consideration. + +The userspace application can access the CDC MBIM functional +descriptor of a MBIM function using either of the two USB +configuration descriptor kernel interfaces described in [6] or [7]. + +See also the ioctl documentation below. + + +Fragmentation +------------- +The userspace application is responsible for all control message +fragmentation and defragmentaion, as described in section 9.5 of [1]. + + +/dev/cdc-wdmX write() +--------------------- +The MBIM control messages from the management application *must not* +exceed the negotiated control message size. + + +/dev/cdc-wdmX read() +-------------------- +The management application *must* accept control messages of up the +negotiated control message size. + + +/dev/cdc-wdmX ioctl() +-------------------- +IOCTL_WDM_MAX_COMMAND: Get Maximum Command Size +This ioctl returns the wMaxControlMessage field of the CDC MBIM +functional descriptor for MBIM devices. This is intended as a +convenience, eliminating the need to parse the USB descriptors from +userspace. + + #include + #include + #include + #include + #include + int main() + { + __u16 max; + int fd = open("/dev/cdc-wdm0", O_RDWR); + if (!ioctl(fd, IOCTL_WDM_MAX_COMMAND, &max)) + printf("wMaxControlMessage is %d\n", max); + } + + +Custom device services +---------------------- +The MBIM specification allows vendors to freely define additional +services. This is fully supported by the cdc_mbim driver. + +Support for new MBIM services, including vendor specified services, is +implemented entirely in userspace, like the rest of the MBIM control +protocol + +New services should be registered in the MBIM Registry [5]. + + + +MBIM data channel userspace ABI +=============================== + +wwanY network device +-------------------- +The cdc_mbim driver represents the MBIM data channel as a single +network device of the "wwan" type. This network device is initially +mapped to MBIM IP session 0. + + +Multiplexed IP sessions (IPS) +----------------------------- +MBIM allows multiplexing up to 256 IP sessions over a single USB data +channel. The cdc_mbim driver models such IP sessions as 802.1q VLAN +subdevices of the master wwanY device, mapping MBIM IP session Z to +VLAN ID Z for all values of Z greater than 0. + +The device maximum Z is given in the MBIM_DEVICE_CAPS_INFO structure +described in section 10.5.1 of [1]. + +The userspace management application is responsible for adding new +VLAN links prior to establishing MBIM IP sessions where the SessionId +is greater than 0. These links can be added by using the normal VLAN +kernel interfaces, either ioctl or netlink. + +For example, adding a link for a MBIM IP session with SessionId 3: + + ip link add link wwan0 name wwan0.3 type vlan id 3 + +The driver will automatically map the "wwan0.3" network device to MBIM +IP session 3. + + +Device Service Streams (DSS) +---------------------------- +MBIM also allows up to 256 non-IP data streams to be multiplexed over +the same shared USB data channel. The cdc_mbim driver models these +sessions as another set of 802.1q VLAN subdevices of the master wwanY +device, mapping MBIM DSS session A to VLAN ID (256 + A) for all values +of A. + +The device maximum A is given in the MBIM_DEVICE_SERVICES_INFO +structure described in section 10.5.29 of [1]. + +The DSS VLAN subdevices are used as a practical interface between the +shared MBIM data channel and a MBIM DSS aware userspace application. +It is not intended to be presented as-is to an end user. The +assumption is that an userspace application initiating a DSS session +also takes care of the necessary framing of the DSS data, presenting +the stream to the end user in an appropriate way for the stream type. + +The network device ABI requires a dummy ethernet header for every DSS +data frame being transported. The contents of this header is +arbitrary, with the following exceptions: + - TX frames using an IP protocol (0x0800 or 0x86dd) will be dropped + - RX frames will have the protocol field set to ETH_P_802_3 (but will + not be properly formatted 802.3 frames) + - RX frames will have the destination address set to the hardware + address of the master device + +The DSS supporting userspace management application is responsible for +adding the dummy ethernet header on TX and stripping it on RX. + +This is a simple example using tools commonly available, exporting +DssSessionId 5 as a pty character device pointed to by a /dev/nmea +symlink: + + ip link add link wwan0 name wwan0.dss5 type vlan id 261 + ip link set dev wwan0.dss5 up + socat INTERFACE:wwan0.dss5,type=2 PTY:,echo=0,link=/dev/nmea + +This is only an example, most suitable for testing out a DSS +service. Userspace applications supporting specific MBIM DSS services +are expected to use the tools and programming interfaces required by +that service. + +Note that adding VLAN links for DSS sessions is entirely optional. A +management application may instead choose to bind a packet socket +directly to the master network device, using the received VLAN tags to +map frames to the correct DSS session and adding 18 byte VLAN ethernet +headers with the appropriate tag on TX. In this case using a socket +filter is recommended, matching only the DSS VLAN subset. This avoid +unnecessary copying of unrelated IP session data to userspace. For +example: + + static struct sock_filter dssfilter[] = { + /* use special negative offsets to get VLAN tag */ + BPF_STMT(BPF_LD|BPF_B|BPF_ABS, SKF_AD_OFF + SKF_AD_VLAN_TAG_PRESENT), + BPF_JUMP(BPF_JMP|BPF_JEQ|BPF_K, 1, 0, 6), /* true */ + + /* verify DSS VLAN range */ + BPF_STMT(BPF_LD|BPF_H|BPF_ABS, SKF_AD_OFF + SKF_AD_VLAN_TAG), + BPF_JUMP(BPF_JMP|BPF_JGE|BPF_K, 256, 0, 4), /* 256 is first DSS VLAN */ + BPF_JUMP(BPF_JMP|BPF_JGE|BPF_K, 512, 3, 0), /* 511 is last DSS VLAN */ + + /* verify ethertype */ + BPF_STMT(BPF_LD|BPF_H|BPF_ABS, 2 * ETH_ALEN), + BPF_JUMP(BPF_JMP|BPF_JEQ|BPF_K, ETH_P_802_3, 0, 1), + + BPF_STMT(BPF_RET|BPF_K, (u_int)-1), /* accept */ + BPF_STMT(BPF_RET|BPF_K, 0), /* ignore */ + }; + + + +Tagged IP session 0 VLAN +------------------------ +As described above, MBIM IP session 0 is treated as special by the +driver. It is initially mapped to untagged frames on the wwanY +network device. + +This mapping implies a few restrictions on multiplexed IPS and DSS +sessions, which may not always be practical: + - no IPS or DSS session can use a frame size greater than the MTU on + IP session 0 + - no IPS or DSS session can be in the up state unless the network + device representing IP session 0 also is up + +These problems can be avoided by optionally making the driver map IP +session 0 to a VLAN subdevice, similar to all other IP sessions. This +behaviour is triggered by adding a VLAN link for the magic VLAN ID +4094. The driver will then immediately start mapping MBIM IP session +0 to this VLAN, and will drop untagged frames on the master wwanY +device. + +Tip: It might be less confusing to the end user to name this VLAN +subdevice after the MBIM SessionID instead of the VLAN ID. For +example: + + ip link add link wwan0 name wwan0.0 type vlan id 4094 + + +VLAN mapping +------------ + +Summarizing the cdc_mbim driver mapping described above, we have this +relationship between VLAN tags on the wwanY network device and MBIM +sessions on the shared USB data channel: + + VLAN ID MBIM type MBIM SessionID Notes + --------------------------------------------------------- + untagged IPS 0 a) + 1 - 255 IPS 1 - 255 + 256 - 511 DSS 0 - 255 + 512 - 4093 b) + 4094 IPS 0 c) + + a) if no VLAN ID 4094 link exists, else dropped + b) unsupported VLAN range, unconditionally dropped + c) if a VLAN ID 4094 link exists, else dropped + + + + +References +========== + +[1] USB Implementers Forum, Inc. - "Universal Serial Bus + Communications Class Subclass Specification for Mobile Broadband + Interface Model", Revision 1.0 (Errata 1), May 1, 2013 + - http://www.usb.org/developers/docs/devclass_docs/ + +[2] USB Implementers Forum, Inc. - "Universal Serial Bus + Communications Class Subclass Specifications for Network Control + Model Devices", Revision 1.0 (Errata 1), November 24, 2010 + - http://www.usb.org/developers/docs/devclass_docs/ + +[3] libmbim - "a glib-based library for talking to WWAN modems and + devices which speak the Mobile Interface Broadband Model (MBIM) + protocol" + - http://www.freedesktop.org/wiki/Software/libmbim/ + +[4] ModemManager - "a DBus-activated daemon which controls mobile + broadband (2G/3G/4G) devices and connections" + - http://www.freedesktop.org/wiki/Software/ModemManager/ + +[5] "MBIM (Mobile Broadband Interface Model) Registry" + - http://compliance.usb.org/mbim/ + +[6] "/proc/bus/usb filesystem output" + - Documentation/usb/proc_usb_info.txt + +[7] "/sys/bus/usb/devices/.../descriptors" + - Documentation/ABI/stable/sysfs-bus-usb -- cgit v1.1 From 5888bcc5d24acf911c3d12719d72968c9b27a02f Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Wed, 14 May 2014 10:33:45 +0930 Subject: Documentation: Update kernel-parameters.tx 1) __setup() is messy, prefer module_param and core_param. 2) Document -- 3) Document modprobe scraping /proc/cmdline. 4) Document handing of leftover parameters to init. 5) Document use of quotes to protect whitespace. Reported-by: Andrew Morton Signed-off-by: Rusty Russell --- Documentation/kernel-parameters.txt | 40 +++++++++++++++++++++++-------------- 1 file changed, 25 insertions(+), 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 4384217..a42b9dd 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1,27 +1,37 @@ Kernel Parameters ~~~~~~~~~~~~~~~~~ -The following is a consolidated list of the kernel parameters as implemented -(mostly) by the __setup() macro and sorted into English Dictionary order -(defined as ignoring all punctuation and sorting digits before letters in a -case insensitive manner), and with descriptions where known. - -Module parameters for loadable modules are specified only as the -parameter name with optional '=' and value as appropriate, such as: - - modprobe usbcore blinkenlights=1 - -Module parameters for modules that are built into the kernel image -are specified on the kernel command line with the module name plus -'.' plus parameter name, with '=' and value if appropriate, such as: - - usbcore.blinkenlights=1 +The following is a consolidated list of the kernel parameters as +implemented by the __setup(), core_param() and module_param() macros +and sorted into English Dictionary order (defined as ignoring all +punctuation and sorting digits before letters in a case insensitive +manner), and with descriptions where known. + +The kernel parses parameters from the kernel command line up to "--"; +if it doesn't recognize a parameter and it doesn't contain a '.', the +parameter gets passed to init: parameters with '=' go into init's +environment, others are passed as command line arguments to init. +Everything after "--" is passed as an argument to init. + +Module parameters can be specified in two ways: via the kernel command +line with a module name prefix, or via modprobe, e.g.: + + (kernel command line) usbcore.blinkenlights=1 + (modprobe command line) modprobe usbcore blinkenlights=1 + +Parameters for modules which are built into the kernel need to be +specified on the kernel command line. modprobe looks through the +kernel command line (/proc/cmdline) and collects module parameters +when it loads a module, so the kernel command line can be used for +loadable modules too. Hyphens (dashes) and underscores are equivalent in parameter names, so log_buf_len=1M print-fatal-signals=1 can also be entered as log-buf-len=1M print_fatal_signals=1 +Double-quotes can be used to protect spaces in values, e.g.: + param="spaces in here" This document may not be entirely up to date and comprehensive. The command "modinfo -p ${modulename}" shows a current list of all parameters of a loadable -- cgit v1.1 From b557deadc5cca47aff93781b21fef468233c2ea8 Mon Sep 17 00:00:00 2001 From: Wolfram Sang Date: Wed, 14 May 2014 03:10:05 +0200 Subject: ARM: shmobile: r7s72100: document MSTP clock support Acked-by: Laurent Pinchart Acked-by: Magnus Damm Signed-off-by: Wolfram Sang Acked-by: Mike Turquette Signed-off-by: Simon Horman --- Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt index 5992dce..b5fc72621 100644 --- a/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt @@ -10,6 +10,7 @@ index in the group, from 0 to 31. Required Properties: - compatible: Must be one of the following + - "renesas,r7s72100-mstp-clocks" for R7S72100 (RZ) MSTP gate clocks - "renesas,r8a7790-mstp-clocks" for R8A7790 (R-Car H2) MSTP gate clocks - "renesas,r8a7791-mstp-clocks" for R8A7791 (R-Car M2) MSTP gate clocks - "renesas,cpg-mstp-clock" for generic MSTP gate clocks -- cgit v1.1 From df15e1de9c7f18289f40c9cf1f6bfa5fd662b1dd Mon Sep 17 00:00:00 2001 From: Shaik Ameer Basha Date: Wed, 14 May 2014 11:23:33 +0530 Subject: documentation/iommu: Add note on existing DT binding status The current dt binding for Exynos System MMU can be changed, if found incompatible with the support for "Generic IOMMU Binding". This patch adds a note to the binding documentation stating the same. Signed-off-by: Shaik Ameer Basha Acked-by: Arnd Bergmann Signed-off-by: Joerg Roedel --- Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt index 15b2a2b..6fa4c73 100644 --- a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt +++ b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt @@ -27,6 +27,11 @@ The drivers must consider how to handle those System MMUs. One of the idea is to implement child devices or sub-devices which are the client devices of the System MMU. +Note: +The current DT binding for the Exynos System MMU is incomplete. +The following properties can be removed or changed, if found incompatible with +the "Generic IOMMU Binding" support for attaching devices to the IOMMU. + Required properties: - compatible: Should be "samsung,exynos-sysmmu" - reg: A tuple of base address and size of System MMU registers. -- cgit v1.1 From fecc2d785ba99ce219f5c10d3b416dc9e74516b1 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Wed, 14 May 2014 14:58:57 +0200 Subject: Documentation: dt: Add new compatible for the A31 USB Phy Document the freshly introduced compatible for the USB phy in use in the Allwinner A31 SoC. Signed-off-by: Maxime Ripard Signed-off-by: Kishon Vijay Abraham I --- .../devicetree/bindings/phy/sun4i-usb-phy.txt | 23 ++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt index a82361b..16528b9 100644 --- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt +++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt @@ -2,15 +2,26 @@ Allwinner sun4i USB PHY ----------------------- Required properties: -- compatible : should be one of "allwinner,sun4i-a10-usb-phy", - "allwinner,sun5i-a13-usb-phy" or "allwinner,sun7i-a20-usb-phy" +- compatible : should be one of + * allwinner,sun4i-a10-usb-phy + * allwinner,sun5i-a13-usb-phy + * allwinner,sun6i-a31-usb-phy + * allwinner,sun7i-a20-usb-phy - reg : a list of offset + length pairs -- reg-names : "phy_ctrl", "pmu1" and for sun4i or sun7i "pmu2" +- reg-names : + * "phy_ctrl" + * "pmu1" + * "pmu2" for sun4i, sun6i or sun7i - #phy-cells : from the generic phy bindings, must be 1 -- clocks : phandle + clock specifier for the phy clock -- clock-names : "usb_phy" +- clocks : phandle + clock specifier for the phy clocks +- clock-names : + * "usb_phy" for sun4i, sun5i or sun7i + * "usb0_phy", "usb1_phy" and "usb2_phy" for sun6i - resets : a list of phandle + reset specifier pairs -- reset-names : "usb0_reset", "usb1_reset" and for sun4i or sun7i "usb2_reset" +- reset-names : + * "usb0_reset" + * "usb1_reset" + * "usb2_reset" for sun4i, sun6i or sun7i Example: usbphy: phy@0x01c13400 { -- cgit v1.1 From 87213d388e927aaa88b21d5ff7e1f75ca2288da1 Mon Sep 17 00:00:00 2001 From: Andrzej Pietrasiewicz Date: Thu, 8 May 2014 14:06:25 +0200 Subject: usb: gadget: configfs: OS String support Add handling of OS String extension from the configfs interface. A directory "os_desc" is added at the top level of a gadget's directories hierarchy. In the "os_desc" directory there are three attributes: "use", "b_vendor_code" and "qw_sign". If "use" contains "0" the OS string is not reported to the host. "b_vendor_code" contains a one-byte value which is used for custom per-device and per-interface requests. "qw_sign" contains an identifier to be reported as the "OS String" proper. Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Felipe Balbi --- Documentation/ABI/testing/configfs-usb-gadget | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/configfs-usb-gadget b/Documentation/ABI/testing/configfs-usb-gadget index 37559a0..0e7b786 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget +++ b/Documentation/ABI/testing/configfs-usb-gadget @@ -79,3 +79,14 @@ Description: product - gadget's product description manufacturer - gadget's manufacturer description +What: /config/usb-gadget/gadget/os_desc +Date: May 2014 +KernelVersion: 3.16 +Description: + This group contains "OS String" extension handling attributes. + + use - flag turning "OS Desctiptors" support on/off + b_vendor_code - one-byte value used for custom per-device and + per-interface requests + qw_sign - an identifier to be reported as "OS String" + proper -- cgit v1.1 From da4243145fb197622425d4c2feff5d6422f2391e Mon Sep 17 00:00:00 2001 From: Andrzej Pietrasiewicz Date: Thu, 8 May 2014 14:06:26 +0200 Subject: usb: gadget: configfs: OS Extended Compatibility descriptors support Add handling of OS Extended Compatibility descriptors from configfs interface. Hosts which expect the "OS Descriptors" ask only for configurations @ index 0, but linux-based USB devices can provide more than one configuration. This patch adds marking one of gadget's configurations the configuration to be reported at index 0, regardless of the actual sequence of usb_add_config invocations used for adding the configurations. The configuration is selected by creating a symbolic link pointing to it from the "os_desc" directory located at the top of a gadget's directory hierarchy. One kind of "OS Descriptors" are "Extended Compatibility Descriptors", which need to be specified per interface. This patch adds interface. directory in function's configfs directory to represent each interface defined by the function. Each interface's directory contains two attributes: "compatible_id" and "sub_compatible_id", which represent 8-byte strings to be reported to the host as the "Compatible ID" and "Sub Compatible ID". Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Felipe Balbi --- Documentation/ABI/testing/configfs-usb-gadget | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/configfs-usb-gadget b/Documentation/ABI/testing/configfs-usb-gadget index 0e7b786..5c0b3e6 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget +++ b/Documentation/ABI/testing/configfs-usb-gadget @@ -62,6 +62,19 @@ KernelVersion: 3.11 Description: This group contains functions available to this USB gadget. +What: /config/usb-gadget/gadget/functions/./interface. +Date: May 2014 +KernelVersion: 3.16 +Description: + This group contains "Feature Descriptors" specific for one + gadget's USB interface or one interface group described + by an IAD. + + The attributes: + + compatible_id - 8-byte string for "Compatible ID" + sub_compatible_id - 8-byte string for "Sub Compatible ID" + What: /config/usb-gadget/gadget/strings Date: Jun 2013 KernelVersion: 3.11 -- cgit v1.1 From 7419485f197c436d41535df78ddea1085042d271 Mon Sep 17 00:00:00 2001 From: Andrzej Pietrasiewicz Date: Thu, 8 May 2014 14:06:28 +0200 Subject: usb: gadget: configfs: OS Extended Properties descriptors support Add handling of OS Extended Properties descriptors from configfs interface. One kind of "OS Descriptors" are "Extended Properties" descriptors, which need to be specified per interface or per group of interfaces described by an IAD. This patch adds support for creating subdirectories in interface. directory located in the function's directory. Names of subdirectories created become names of properties. Each property contains two attributes: "type" and "data". The type can be a numeric value 1..7 while data is a blob interpreted depending on the type specified. The types are: 1 - unicode string 2 - unicode string with environment variables 3 - binary 4 - little-endian 32-bit 5 - big-endian 32-bit 6 - unicode string with a symbolic link 7 - multiple unicode strings Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Felipe Balbi --- Documentation/ABI/testing/configfs-usb-gadget | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/configfs-usb-gadget b/Documentation/ABI/testing/configfs-usb-gadget index 5c0b3e6..95a3658 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget +++ b/Documentation/ABI/testing/configfs-usb-gadget @@ -75,6 +75,27 @@ Description: compatible_id - 8-byte string for "Compatible ID" sub_compatible_id - 8-byte string for "Sub Compatible ID" +What: /config/usb-gadget/gadget/functions/./interface./ +Date: May 2014 +KernelVersion: 3.16 +Description: + This group contains "Extended Property Descriptors" specific for one + gadget's USB interface or one interface group described + by an IAD. + + The attributes: + + type - value 1..7 for interpreting the data + 1: unicode string + 2: unicode string with environment variable + 3: binary + 4: little-endian 32-bit + 5: big-endian 32-bit + 6: unicode string with a symbolic link + 7: multiple unicode strings + data - blob of data to be interpreted depending on + type + What: /config/usb-gadget/gadget/strings Date: Jun 2013 KernelVersion: 3.11 -- cgit v1.1 From a1a205df6ee224f62c6d21cedebcb723db17fe0d Mon Sep 17 00:00:00 2001 From: Kefeng Wang Date: Wed, 14 May 2014 14:13:42 +0800 Subject: ahci: add support for Hisilicon sata The hip04 SoC of hisilicon has an AHCI compliant SATA controller, and it is compliant with the ahci 1.3 and sata 3.0 specification. There is a wrong bit in HOST_CAP of hip04 sata controller, which enable unsupported feature of FBS, use AHCI_HFLAG_NO_FBS hflag to disable it. Reviewed-by: Hans de Goede Signed-off-by: Kefeng Wang Signed-off-by: Tejun Heo --- Documentation/devicetree/bindings/ata/ahci-platform.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt index d6b07e8..c96d8dc 100644 --- a/Documentation/devicetree/bindings/ata/ahci-platform.txt +++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt @@ -8,6 +8,7 @@ Required properties: - "allwinner,sun4i-a10-ahci" - "fsl,imx53-ahci" - "fsl,imx6q-ahci" + - "hisilicon,hisi-ahci" - "ibm,476gtr-ahci" - "marvell,armada-380-ahci" - "snps,dwc-ahci" -- cgit v1.1 From 5a989cf6a05a93a360f38f8a6900ce4dd1e4b6c4 Mon Sep 17 00:00:00 2001 From: Rahul Sharma Date: Mon, 24 Mar 2014 02:15:53 +0530 Subject: clk/exynos5260: add macros and documentation for exynos5260 Add macros which are used as Clock IDs in DT and clock file. It also adds the documentation for the exynos5260 clocks. Signed-off-by: Rahul Sharma Signed-off-by: Tomasz Figa --- .../devicetree/bindings/clock/exynos5260-clock.txt | 190 +++++++++++++++++++++ 1 file changed, 190 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/exynos5260-clock.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/exynos5260-clock.txt b/Documentation/devicetree/bindings/clock/exynos5260-clock.txt new file mode 100644 index 0000000..5496b2f --- /dev/null +++ b/Documentation/devicetree/bindings/clock/exynos5260-clock.txt @@ -0,0 +1,190 @@ +* Samsung Exynos5260 Clock Controller + +Exynos5260 has 13 clock controllers which are instantiated +independently from the device-tree. These clock controllers +generate and supply clocks to various hardware blocks within +the SoC. + +Each clock is assigned an identifier and client nodes can use +this identifier to specify the clock which they consume. All +available clocks are defined as preprocessor macros in +dt-bindings/clock/exynos5260-clk.h header and can be used in +device tree sources. + +External clocks: + +There are several clocks that are generated outside the SoC. It +is expected that they are defined using standard clock bindings +with following clock-output-names: + + - "fin_pll" - PLL input clock from XXTI + - "xrtcxti" - input clock from XRTCXTI + - "ioclk_pcm_extclk" - pcm external operation clock + - "ioclk_spdif_extclk" - spdif external operation clock + - "ioclk_i2s_cdclk" - i2s0 codec clock + +Phy clocks: + +There are several clocks which are generated by specific PHYs. +These clocks are fed into the clock controller and then routed to +the hardware blocks. These clocks are defined as fixed clocks in the +driver with following names: + + - "phyclk_dptx_phy_ch3_txd_clk" - dp phy clock for channel 3 + - "phyclk_dptx_phy_ch2_txd_clk" - dp phy clock for channel 2 + - "phyclk_dptx_phy_ch1_txd_clk" - dp phy clock for channel 1 + - "phyclk_dptx_phy_ch0_txd_clk" - dp phy clock for channel 0 + - "phyclk_hdmi_phy_tmds_clko" - hdmi phy tmds clock + - "phyclk_hdmi_phy_pixel_clko" - hdmi phy pixel clock + - "phyclk_hdmi_link_o_tmds_clkhi" - hdmi phy for hdmi link + - "phyclk_dptx_phy_o_ref_clk_24m" - dp phy reference clock + - "phyclk_dptx_phy_clk_div2" + - "phyclk_mipi_dphy_4l_m_rxclkesc0" + - "phyclk_usbhost20_phy_phyclock" - usb 2.0 phy clock + - "phyclk_usbhost20_phy_freeclk" + - "phyclk_usbhost20_phy_clk48mohci" + - "phyclk_usbdrd30_udrd30_pipe_pclk" + - "phyclk_usbdrd30_udrd30_phyclock" - usb 3.0 phy clock + +Required Properties for Clock Controller: + + - compatible: should be one of the following. + 1) "samsung,exynos5260-clock-top" + 2) "samsung,exynos5260-clock-peri" + 3) "samsung,exynos5260-clock-egl" + 4) "samsung,exynos5260-clock-kfc" + 5) "samsung,exynos5260-clock-g2d" + 6) "samsung,exynos5260-clock-mif" + 7) "samsung,exynos5260-clock-mfc" + 8) "samsung,exynos5260-clock-g3d" + 9) "samsung,exynos5260-clock-fsys" + 10) "samsung,exynos5260-clock-aud" + 11) "samsung,exynos5260-clock-isp" + 12) "samsung,exynos5260-clock-gscl" + 13) "samsung,exynos5260-clock-disp" + + - reg: physical base address of the controller and the length of + memory mapped region. + + - #clock-cells: should be 1. + + - clocks: list of clock identifiers which are fed as the input to + the given clock controller. Please refer the next section to find + the input clocks for a given controller. + + - clock-names: list of names of clocks which are fed as the input + to the given clock controller. + +Input clocks for top clock controller: + - fin_pll + - dout_mem_pll + - dout_bus_pll + - dout_media_pll + +Input clocks for peri clock controller: + - fin_pll + - ioclk_pcm_extclk + - ioclk_i2s_cdclk + - ioclk_spdif_extclk + - phyclk_hdmi_phy_ref_cko + - dout_aclk_peri_66 + - dout_sclk_peri_uart0 + - dout_sclk_peri_uart1 + - dout_sclk_peri_uart2 + - dout_sclk_peri_spi0_b + - dout_sclk_peri_spi1_b + - dout_sclk_peri_spi2_b + - dout_aclk_peri_aud + - dout_sclk_peri_spi0_b + +Input clocks for egl clock controller: + - fin_pll + - dout_bus_pll + +Input clocks for kfc clock controller: + - fin_pll + - dout_media_pll + +Input clocks for g2d clock controller: + - fin_pll + - dout_aclk_g2d_333 + +Input clocks for mif clock controller: + - fin_pll + +Input clocks for mfc clock controller: + - fin_pll + - dout_aclk_mfc_333 + +Input clocks for g3d clock controller: + - fin_pll + +Input clocks for fsys clock controller: + - fin_pll + - phyclk_usbhost20_phy_phyclock + - phyclk_usbhost20_phy_freeclk + - phyclk_usbhost20_phy_clk48mohci + - phyclk_usbdrd30_udrd30_pipe_pclk + - phyclk_usbdrd30_udrd30_phyclock + - dout_aclk_fsys_200 + +Input clocks for aud clock controller: + - fin_pll + - fout_aud_pll + - ioclk_i2s_cdclk + - ioclk_pcm_extclk + +Input clocks for isp clock controller: + - fin_pll + - dout_aclk_isp1_266 + - dout_aclk_isp1_400 + - mout_aclk_isp1_266 + +Input clocks for gscl clock controller: + - fin_pll + - dout_aclk_gscl_400 + - dout_aclk_gscl_333 + +Input clocks for disp clock controller: + - fin_pll + - phyclk_dptx_phy_ch3_txd_clk + - phyclk_dptx_phy_ch2_txd_clk + - phyclk_dptx_phy_ch1_txd_clk + - phyclk_dptx_phy_ch0_txd_clk + - phyclk_hdmi_phy_tmds_clko + - phyclk_hdmi_phy_ref_clko + - phyclk_hdmi_phy_pixel_clko + - phyclk_hdmi_link_o_tmds_clkhi + - phyclk_mipi_dphy_4l_m_txbyte_clkhs + - phyclk_dptx_phy_o_ref_clk_24m + - phyclk_dptx_phy_clk_div2 + - phyclk_mipi_dphy_4l_m_rxclkesc0 + - phyclk_hdmi_phy_ref_cko + - ioclk_spdif_extclk + - dout_aclk_peri_aud + - dout_aclk_disp_222 + - dout_sclk_disp_pixel + - dout_aclk_disp_333 + +Example 1: An example of a clock controller node is listed below. + + clock_mfc: clock-controller@11090000 { + compatible = "samsung,exynos5260-clock-mfc"; + clock = <&fin_pll>, <&clock_top TOP_DOUT_ACLK_MFC_333>; + clock-names = "fin_pll", "dout_aclk_mfc_333"; + reg = <0x11090000 0x10000>; + #clock-cells = <1>; + }; + +Example 2: UART controller node that consumes the clock generated by the + peri clock controller. Refer to the standard clock bindings for + information about 'clocks' and 'clock-names' property. + + serial@12C00000 { + compatible = "samsung,exynos4210-uart"; + reg = <0x12C00000 0x100>; + interrupts = <0 146 0>; + clocks = <&clock_peri PERI_PCLK_UART0>, <&clock_peri PERI_SCLK_UART0>; + clock-names = "uart", "clk_uart_baud0"; + }; + -- cgit v1.1 From efe32f6ea8123bc6456617b9f8830fa4c566be7a Mon Sep 17 00:00:00 2001 From: Tomasz Figa Date: Wed, 14 May 2014 17:03:20 +0200 Subject: ARM: S3C24XX: Remove omitted Kconfig selects and conditionals After full migration of s3c24xx to Common Clock Framework, some unneeded entries in Kconfig still remained. Delete them. Signed-off-by: Tomasz Figa --- Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt b/Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt index 0b64ad8..822505e 100644 --- a/Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt +++ b/Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt @@ -19,7 +19,7 @@ to specify the clock which they consume. Some of the clocks are available only on a particular SoC. All available clocks are defined as preprocessor macros in -dt-bindings/clock/samsung,s3c2410-clock.h header and can be used in device +dt-bindings/clock/s3c2410.h header and can be used in device tree sources. External clocks: -- cgit v1.1 From d7067f1c5fa0232001502569c6878d22308da268 Mon Sep 17 00:00:00 2001 From: Sachin Kamat Date: Tue, 13 May 2014 07:13:47 +0900 Subject: devicetree: bindings: document SYSRAM binding Add SRAM binding documentation. Signed-off-by: Sachin Kamat Acked-by: Arnd Bergmann Reviewed-by: Tomasz Figa [kgene.kim@samsung.com: changed name SRAM to SYSRAM] Signed-off-by: Kukjin Kim --- .../devicetree/bindings/arm/exynos/smp-sysram.txt | 38 ++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt b/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt new file mode 100644 index 0000000..4a0a4f7 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt @@ -0,0 +1,38 @@ +Samsung Exynos SYSRAM for SMP bringup: +------------------------------------ + +Samsung SMP-capable Exynos SoCs use part of the SYSRAM for the bringup +of the secondary cores. Once the core gets powered up it executes the +code that is residing at some specific location of the SYSRAM. + +Therefore reserved section sub-nodes have to be added to the mmio-sram +declaration. These nodes are of two types depending upon secure or +non-secure execution environment. + +Required sub-node properties: +- compatible : depending upon boot mode, should be + "samsung,exynos4210-sysram" : for Secure SYSRAM + "samsung,exynos4210-sysram-ns" : for Non-secure SYSRAM + +The rest of the properties should follow the generic mmio-sram discription +found in ../../misc/sysram.txt + +Example: + + sysram@02020000 { + compatible = "mmio-sram"; + reg = <0x02020000 0x54000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x02020000 0x54000>; + + smp-sysram@0 { + compatible = "samsung,exynos4210-sysram"; + reg = <0x0 0x1000>; + }; + + smp-sysram@53000 { + compatible = "samsung,exynos4210-sysram-ns"; + reg = <0x53000 0x1000>; + }; + }; -- cgit v1.1 From 409f01395b9afac302b943926466cd8dbca61d0a Mon Sep 17 00:00:00 2001 From: Fabio Estevam Date: Fri, 9 May 2014 00:01:50 -0300 Subject: Documentation: clock: fixed-clock: Remove unsupported 'gpios' property Remove the 'gpios' property from the documentation as this is something that the current fixed clock driver does not handle. Signed-off-by: Fabio Estevam Signed-off-by: Mike Turquette --- Documentation/devicetree/bindings/clock/fixed-clock.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/fixed-clock.txt b/Documentation/devicetree/bindings/clock/fixed-clock.txt index 48ea0ad..0641a663 100644 --- a/Documentation/devicetree/bindings/clock/fixed-clock.txt +++ b/Documentation/devicetree/bindings/clock/fixed-clock.txt @@ -12,7 +12,6 @@ Required properties: Optional properties: - clock-accuracy : accuracy of clock in ppb (parts per billion). Should be a single cell. -- gpios : From common gpio binding; gpio connection to clock enable pin. - clock-output-names : From common clock binding. Example: -- cgit v1.1 From 1e84443e69c1fdbef76fb3897294e924461a6c0a Mon Sep 17 00:00:00 2001 From: Boris BREZILLON Date: Wed, 14 May 2014 14:38:15 +0200 Subject: reset: sunxi: document sunxi's reset controllers bindings Add DT bindings documentation for sunxi's reset controllers. Signed-off-by: Boris BREZILLON Acked-by: Maxime Ripard Signed-off-by: Maxime Ripard Acked-by: Philipp Zabel --- .../bindings/reset/allwinner,sunxi-clock-reset.txt | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 Documentation/devicetree/bindings/reset/allwinner,sunxi-clock-reset.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/reset/allwinner,sunxi-clock-reset.txt b/Documentation/devicetree/bindings/reset/allwinner,sunxi-clock-reset.txt new file mode 100644 index 0000000..c8f7757 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/allwinner,sunxi-clock-reset.txt @@ -0,0 +1,21 @@ +Allwinner sunxi Peripheral Reset Controller +=========================================== + +Please also refer to reset.txt in this directory for common reset +controller binding usage. + +Required properties: +- compatible: Should be one of the following: + "allwinner,sun6i-a31-ahb1-reset" + "allwinner,sun6i-a31-clock-reset" +- reg: should be register base and length as documented in the + datasheet +- #reset-cells: 1, see below + +example: + +ahb1_rst: reset@01c202c0 { + #reset-cells = <1>; + compatible = "allwinner,sun6i-a31-ahb1-reset"; + reg = <0x01c202c0 0xc>; +}; -- cgit v1.1 From ebc3226202d5956a5963185222982d435378b899 Mon Sep 17 00:00:00 2001 From: Cornelia Huck Date: Fri, 9 May 2014 15:00:46 +0200 Subject: KVM: s390: announce irqfd capability s390 has acquired irqfd support with commit "KVM: s390: irq routing for adapter interrupts" (84223598778ba08041f4297fda485df83414d57e) but failed to announce it. Let's fix that. Signed-off-by: Cornelia Huck Acked-by: Christian Borntraeger Signed-off-by: Christian Borntraeger --- Documentation/virtual/kvm/api.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index a9380ba5..b4f5365 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -2126,7 +2126,7 @@ into the hash PTE second double word). 4.75 KVM_IRQFD Capability: KVM_CAP_IRQFD -Architectures: x86 +Architectures: x86 s390 Type: vm ioctl Parameters: struct kvm_irqfd (in) Returns: 0 on success, -1 on error -- cgit v1.1 From e2d5f05b745d19bc889c79977325b14853f3fc38 Mon Sep 17 00:00:00 2001 From: Ezequiel Garcia Date: Tue, 6 May 2014 13:59:50 -0300 Subject: thermal: armada: Support Armada 375 SoC Now that a generic infrastructure is in place, it's possible to support the new Armada 375 SoC thermal sensor. This sensor is similar to the one available in the already supported SoCs, with its specific temperature formula and specific sensor initialization. In addition, we also add support for the Z1 SoC stepping, which needs an initialization-quirk to work properly. Acked-by: Jason Cooper Signed-off-by: Ezequiel Garcia Signed-off-by: Zhang Rui --- Documentation/devicetree/bindings/thermal/armada-thermal.txt | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/armada-thermal.txt b/Documentation/devicetree/bindings/thermal/armada-thermal.txt index fff93d5..2a67e51 100644 --- a/Documentation/devicetree/bindings/thermal/armada-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/armada-thermal.txt @@ -1,11 +1,20 @@ -* Marvell Armada 370/XP thermal management +* Marvell Armada 370/375/XP thermal management Required properties: - compatible: Should be set to one of the following: marvell,armada370-thermal + marvell,armada375-thermal + marvell,armada375-z1-thermal marvell,armadaxp-thermal + Note: As the name suggests, "marvell,armada375-z1-thermal" + applies for the SoC Z1 stepping only. On such stepping + some quirks need to be done and the register offset differs + from the one in the A0 stepping. + The operating system may auto-detect the SoC stepping and + update the compatible and register offsets at runtime. + - reg: Device's register space. Two entries are expected, see the examples below. The first one is required for the sensor register; -- cgit v1.1 From e6e0a68c6cd585773fa1fbbd1ca71272afe15203 Mon Sep 17 00:00:00 2001 From: Ezequiel Garcia Date: Tue, 6 May 2014 13:59:51 -0300 Subject: thermal: armada: Support Armada 380 SoC Now that a generic infrastructure is in place, it's possible to support the Armada 380 SoC thermal sensor. This sensor is similar to the one available in the already supported SoCs, with its specific temperature formula and specific sensor initialization. Acked-by: Jason Cooper Signed-off-by: Ezequiel Garcia Signed-off-by: Zhang Rui --- Documentation/devicetree/bindings/thermal/armada-thermal.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/armada-thermal.txt b/Documentation/devicetree/bindings/thermal/armada-thermal.txt index 2a67e51..4cf0249 100644 --- a/Documentation/devicetree/bindings/thermal/armada-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/armada-thermal.txt @@ -1,4 +1,4 @@ -* Marvell Armada 370/375/XP thermal management +* Marvell Armada 370/375/380/XP thermal management Required properties: @@ -6,6 +6,7 @@ Required properties: marvell,armada370-thermal marvell,armada375-thermal marvell,armada375-z1-thermal + marvell,armada380-thermal marvell,armadaxp-thermal Note: As the name suggests, "marvell,armada375-z1-thermal" -- cgit v1.1 From e1cd3b361a4f1dd323252543f40d43509d80affa Mon Sep 17 00:00:00 2001 From: Ashwin Chaugule Date: Thu, 27 Mar 2014 11:08:57 -0400 Subject: Documentation: devicetree: Add new binding for PSCIv0.2 The PSCI v0.2+ spec defines standard values for PSCI function IDs. Add a new binding entry so that pre v0.2 implementations can use DT entries for function IDs and v0.2+ implementations use standard entries as defined by the PSCIv0.2 specification. Signed-off-by: Ashwin Chaugule Reviewed-by: Mark Rutland Acked-by: Rob Herring Acked-by: Catalin Marinas --- Documentation/devicetree/bindings/arm/psci.txt | 37 +++++++++++++++++++++++++- 1 file changed, 36 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt index 433afe9..b4a58f3 100644 --- a/Documentation/devicetree/bindings/arm/psci.txt +++ b/Documentation/devicetree/bindings/arm/psci.txt @@ -21,7 +21,15 @@ to #0. Main node required properties: - - compatible : Must be "arm,psci" + - compatible : should contain at least one of: + + * "arm,psci" : for implementations complying to PSCI versions prior to + 0.2. For these cases function IDs must be provided. + + * "arm,psci-0.2" : for implementations complying to PSCI 0.2. Function + IDs are not required and should be ignored by an OS with PSCI 0.2 + support, but are permitted to be present for compatibility with + existing software when "arm,psci" is later in the compatible list. - method : The method of calling the PSCI firmware. Permitted values are: @@ -45,6 +53,8 @@ Main node optional properties: Example: +Case 1: PSCI v0.1 only. + psci { compatible = "arm,psci"; method = "smc"; @@ -53,3 +63,28 @@ Example: cpu_on = <0x95c10002>; migrate = <0x95c10003>; }; + + +Case 2: PSCI v0.2 only + + psci { + compatible = "arm,psci-0.2"; + method = "smc"; + }; + +Case 3: PSCI v0.2 and PSCI v0.1. + + A DTB may provide IDs for use by kernels without PSCI 0.2 support, + enabling firmware and hypervisors to support existing and new kernels. + These IDs will be ignored by kernels with PSCI 0.2 support, which will + use the standard PSCI 0.2 IDs exclusively. + + psci { + compatible = "arm,psci-0.2", "arm,psci"; + method = "hvc"; + + cpu_on = < arbitrary value >; + cpu_off = < arbitrary value >; + + ... + }; -- cgit v1.1 From 3b9334ac835bb431e2186645230c9f1eb94b5d49 Mon Sep 17 00:00:00 2001 From: Pawel Moll Date: Wed, 30 Apr 2014 16:46:29 +0100 Subject: mfd: vexpress: Convert custom func API to regmap Components of the Versatile Express platform (configuration microcontrollers on motherboard and daughterboards in particular) talk to each other over a custom configuration bus. They provide miscellaneous functions (from clock generator control to energy sensors) which are represented as platform devices (and Device Tree nodes). The transactions on the bus can be generated by different "bridges" in the system, some of which are universal for the whole platform (for the price of high transfer latencies), others restricted to a subsystem (but much faster). Until now drivers for such functions were using custom "func" API, which is being replaced in this patch by regmap calls. This required: * a rework (and move to drivers/bus directory, as suggested by Samuel and Arnd) of the config bus core, which is much simpler now and uses device model infrastructure (class) to keep track of the bridges; non-DT case (soon to be retired anyway) is simply covered by a special device registration function * the new config-bus driver also takes over device population, so there is no need for special matching table for of_platform_populate nor "simple-bus" hack in the arm64 model dtsi file (relevant bindings documentation has been updated); this allows all the vexpress devices fit into normal device model, making it possible to remove plenty of early inits and other hacks in the near future * adaptation of the syscfg bridge implementation in the sysreg driver, again making it much simpler; there is a special case of the "energy" function spanning two registers, where they should be both defined in the tree now, but backward compatibility is maintained in the code * modification of the relevant drivers: * hwmon - just a straight-forward API change * power/reset driver - API change * regulator - API change plus error handling simplification * osc clock driver - this one required larger rework in order to turn in into a standard platform driver Signed-off-by: Pawel Moll Acked-by: Mark Brown Acked-by: Lee Jones Acked-by: Guenter Roeck Acked-by: Mike Turquette --- .../devicetree/bindings/arm/vexpress-sysreg.txt | 43 ++++++++++++++++------ Documentation/devicetree/bindings/arm/vexpress.txt | 15 +++++--- 2 files changed, 42 insertions(+), 16 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt b/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt index 5580e9c..57b423f 100644 --- a/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt +++ b/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt @@ -27,24 +27,45 @@ Example: This block also can also act a bridge to the platform's configuration bus via "system control" interface, addressing devices with site number, position in the board stack, config controller, function and device -numbers - see motherboard's TRM for more details. - -The node describing a config device must refer to the sysreg node via -"arm,vexpress,config-bridge" phandle (can be also defined in the node's -parent) and relies on the board topology properties - see main vexpress -node documentation for more details. It must also define the following -property: -- arm,vexpress-sysreg,func : must contain two cells: - - first cell defines function number (eg. 1 for clock generator, - 2 for voltage regulators etc.) - - device number (eg. osc 0, osc 1 etc.) +numbers - see motherboard's TRM for more details. All configuration +controller accessible via this interface must reference the sysreg +node via "arm,vexpress,config-bridge" phandle and define appropriate +topology properties - see main vexpress node documentation for more +details. Each child of such node describes one function and must +define the following properties: +- compatible value : must be one of (corresponding to the TRM): + "arm,vexpress-amp" + "arm,vexpress-dvimode" + "arm,vexpress-energy" + "arm,vexpress-muxfpga" + "arm,vexpress-osc" + "arm,vexpress-power" + "arm,vexpress-reboot" + "arm,vexpress-reset" + "arm,vexpress-scc" + "arm,vexpress-shutdown" + "arm,vexpress-temp" + "arm,vexpress-volt" +- arm,vexpress-sysreg,func : must contain a set of two cells long groups: + - first cell of each group defines the function number + (eg. 1 for clock generator, 2 for voltage regulators etc.) + - second cell of each group defines device number (eg. osc 0, + osc 1 etc.) + - some functions (eg. energy meter, with its 64 bit long counter) + are using more than one function/device number pair Example: mcc { + compatible = "arm,vexpress,config-bus"; arm,vexpress,config-bridge = <&v2m_sysreg>; osc@0 { compatible = "arm,vexpress-osc"; arm,vexpress-sysreg,func = <1 0>; }; + + energy@0 { + compatible = "arm,vexpress-energy"; + arm,vexpress-sysreg,func = <13 0>, <13 1>; + }; }; diff --git a/Documentation/devicetree/bindings/arm/vexpress.txt b/Documentation/devicetree/bindings/arm/vexpress.txt index ae49161..39844cd 100644 --- a/Documentation/devicetree/bindings/arm/vexpress.txt +++ b/Documentation/devicetree/bindings/arm/vexpress.txt @@ -80,12 +80,17 @@ but also control clock generators, voltage regulators, gather environmental data like temperature, power consumption etc. Even the video output switch (FPGA) is controlled that way. -Nodes describing devices controlled by this infrastructure should -point at the bridge device node: +The controllers are not mapped into normal memory address space +and must be accessed through bridges - other devices capable +of generating transactions on the configuration bus. + +The nodes describing configuration controllers must define +the following properties: +- compatible value: + compatible = "arm,vexpress,config-bus"; - bridge phandle: arm,vexpress,config-bridge = ; -This property can be also defined in a parent node (eg. for a DCC) -and is effective for all children. +and children describing available functions. Platform topology @@ -197,7 +202,7 @@ Example of a VE tile description (simplified) }; dcc { - compatible = "simple-bus"; + compatible = "arm,vexpress,config-bus"; arm,vexpress,config-bridge = <&v2m_sysreg>; osc@0 { -- cgit v1.1 From 974cc7b93441a0e78f030495436d1be7eb7c208d Mon Sep 17 00:00:00 2001 From: Pawel Moll Date: Wed, 23 Apr 2014 10:49:31 +0100 Subject: mfd: vexpress: Define the device as MFD cells This patch - finally, after over 6 months! :-( - addresses Samuel's request to split the vexpress-sysreg driver into smaller portions and define the device in a form of MFD cells: * LEDs code has been completely removed and replaced with "gpio-leds" nodes in the tree (referencing dedicated GPIO subnodes in sysreg - bindings documentation updated); this also better fits the reality as some variants of the motherboard don't have all the LEDs populated * syscfg bridge code has been extracted into a separate driver (placed in drivers/misc for no better place) * all the ID & MISC registers are defined as sysconf making them available for other drivers should they need to use them (and also to the user via /sys/kernel/debug/regmap which can be helpful in platform debugging) Signed-off-by: Pawel Moll Acked-by: Lee Jones --- .../devicetree/bindings/arm/vexpress-sysreg.txt | 36 ++++++++++++++++++++-- 1 file changed, 34 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt b/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt index 57b423f..00318d0 100644 --- a/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt +++ b/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt @@ -8,6 +8,8 @@ interrupt generation, MMC and NOR Flash control etc. Required node properties: - compatible value : = "arm,vexpress,sysreg"; - reg : physical base address and the size of the registers window + +Deprecated properties, replaced by GPIO subnodes (see below): - gpio-controller : specifies that the node is a GPIO controller - #gpio-cells : size of the GPIO specifier, should be 2: - first cell is the pseudo-GPIO line number: @@ -16,12 +18,42 @@ Required node properties: 2 - NOR FLASH WPn - second cell can take standard GPIO flags (currently ignored). +Control registers providing pseudo-GPIO lines must be represented +by subnodes, each of them requiring the following properties: +- compatible value : one of + "arm,vexpress-sysreg,sys_led" + "arm,vexpress-sysreg,sys_mci" + "arm,vexpress-sysreg,sys_flash" +- gpio-controller : makes the node a GPIO controller +- #gpio-cells : size of the GPIO specifier, must be 2: + - first cell is the function number: + - for sys_led : 0..7 = LED 0..7 + - for sys_mci : 0 = MMC CARDIN, 1 = MMC WPROT + - for sys_flash : 0 = NOR FLASH WPn + - second cell can take standard GPIO flags (currently ignored). + Example: v2m_sysreg: sysreg@10000000 { compatible = "arm,vexpress-sysreg"; reg = <0x10000000 0x1000>; - gpio-controller; - #gpio-cells = <2>; + + v2m_led_gpios: sys_led@08 { + compatible = "arm,vexpress-sysreg,sys_led"; + gpio-controller; + #gpio-cells = <2>; + }; + + v2m_mmc_gpios: sys_mci@48 { + compatible = "arm,vexpress-sysreg,sys_mci"; + gpio-controller; + #gpio-cells = <2>; + }; + + v2m_flash_gpios: sys_flash@4c { + compatible = "arm,vexpress-sysreg,sys_flash"; + gpio-controller; + #gpio-cells = <2>; + }; }; This block also can also act a bridge to the platform's configuration -- cgit v1.1 From a2aa24734d9dbbd3b9062c2459936c336278fa6a Mon Sep 17 00:00:00 2001 From: Sebastian Reichel Date: Fri, 28 Mar 2014 22:59:43 +0100 Subject: HSI: Add common DT binding for HSI client devices Implement and document generic DT bindings for HSI clients. Signed-off-by: Sebastian Reichel Reviewed-by: Pavel Machek Tested-By: Ivaylo Dimitrov --- .../devicetree/bindings/hsi/client-devices.txt | 44 ++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 Documentation/devicetree/bindings/hsi/client-devices.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/hsi/client-devices.txt b/Documentation/devicetree/bindings/hsi/client-devices.txt new file mode 100644 index 0000000..104c9a3 --- /dev/null +++ b/Documentation/devicetree/bindings/hsi/client-devices.txt @@ -0,0 +1,44 @@ +Each HSI port is supposed to have one child node, which +symbols the remote device connected to the HSI port. The +following properties are standardized for HSI clients: + +Required HSI configuration properties: + +- hsi-channel-ids: A list of channel ids + +- hsi-rx-mode: Receiver Bit transmission mode ("stream" or "frame") +- hsi-tx-mode: Transmitter Bit transmission mode ("stream" or "frame") +- hsi-mode: May be used instead hsi-rx-mode and hsi-tx-mode if + the transmission mode is the same for receiver and + transmitter +- hsi-speed-kbps: Max bit transmission speed in kbit/s +- hsi-flow: RX flow type ("synchronized" or "pipeline") +- hsi-arb-mode: Arbitration mode for TX frame ("round-robin", "priority") + +Optional HSI configuration properties: + +- hsi-channel-names: A list with one name per channel specified in the + hsi-channel-ids property + + +Device Tree node example for an HSI client: + +hsi-controller { + hsi-port { + modem: hsi-client { + compatible = "nokia,n900-modem"; + + hsi-channel-ids = <0>, <1>, <2>, <3>; + hsi-channel-names = "mcsaab-control", + "speech-control", + "speech-data", + "mcsaab-data"; + hsi-speed-kbps = <55000>; + hsi-mode = "frame"; + hsi-flow = "synchronized"; + hsi-arb-mode = "round-robin"; + + /* more client specific properties */ + }; + }; +}; -- cgit v1.1 From dc9df3154c082873591acf95036632e97215212e Mon Sep 17 00:00:00 2001 From: Sebastian Reichel Date: Sun, 15 Dec 2013 23:43:10 +0100 Subject: Documentation: DT: omap-ssi binding documentation Create device tree binding documentation for OMAP Synchronous Serial Interface (SSI) device. Signed-off-by: Sebastian Reichel Reviewed-by: Pavel Machek --- Documentation/devicetree/bindings/hsi/omap-ssi.txt | 97 ++++++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 Documentation/devicetree/bindings/hsi/omap-ssi.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/hsi/omap-ssi.txt b/Documentation/devicetree/bindings/hsi/omap-ssi.txt new file mode 100644 index 0000000..f26625e --- /dev/null +++ b/Documentation/devicetree/bindings/hsi/omap-ssi.txt @@ -0,0 +1,97 @@ +OMAP SSI controller bindings + +OMAP Synchronous Serial Interface (SSI) controller implements a legacy +variant of MIPI's High Speed Synchronous Serial Interface (HSI). + +Required properties: +- compatible: Should include "ti,omap3-ssi". +- reg-names: Contains the values "sys" and "gdd" (in this order). +- reg: Contains a matching register specifier for each entry + in reg-names. +- interrupt-names: Contains the value "gdd_mpu". +- interrupts: Contains matching interrupt information for each entry + in interrupt-names. +- ranges: Represents the bus address mapping between the main + controller node and the child nodes below. +- clock-names: Must include the following entries: + "ssi_ssr_fck": The OMAP clock of that name + "ssi_sst_fck": The OMAP clock of that name + "ssi_ick": The OMAP clock of that name +- clocks: Contains a matching clock specifier for each entry in + clock-names. +- #address-cells: Should be set to <1> +- #size-cells: Should be set to <1> + +Each port is represented as a sub-node of the ti,omap3-ssi device. + +Required Port sub-node properties: +- compatible: Should be set to the following value + ti,omap3-ssi-port (applicable to OMAP34xx devices) +- reg-names: Contains the values "tx" and "rx" (in this order). +- reg: Contains a matching register specifier for each entry + in reg-names. +- interrupt-parent Should be a phandle for the interrupt controller +- interrupts: Should contain interrupt specifiers for mpu interrupts + 0 and 1 (in this order). +- ti,ssi-cawake-gpio: Defines which GPIO pin is used to signify CAWAKE + events for the port. This is an optional board-specific + property. If it's missing the port will not be + enabled. + +Example for Nokia N900: + +ssi-controller@48058000 { + compatible = "ti,omap3-ssi"; + + /* needed until hwmod is updated to use the compatible string */ + ti,hwmods = "ssi"; + + reg = <0x48058000 0x1000>, + <0x48059000 0x1000>; + reg-names = "sys", + "gdd"; + + interrupts = <55>; + interrupt-names = "gdd_mpu"; + + clocks = <&ssi_ssr_fck>, + <&ssi_sst_fck>, + <&ssi_ick>; + clock-names = "ssi_ssr_fck", + "ssi_sst_fck", + "ssi_ick"; + + #address-cells = <1>; + #size-cells = <1>; + ranges; + + ssi-port@4805a000 { + compatible = "ti,omap3-ssi-port"; + + reg = <0x4805a000 0x800>, + <0x4805a800 0x800>; + reg-names = "tx", + "rx"; + + interrupt-parent = <&intc>; + interrupts = <67>, + <68>; + + ti,ssi-cawake-gpio = <&gpio5 23 GPIO_ACTIVE_HIGH>; /* 151 */ + } + + ssi-port@4805a000 { + compatible = "ti,omap3-ssi-port"; + + reg = <0x4805b000 0x800>, + <0x4805b800 0x800>; + reg-names = "tx", + "rx"; + + interrupt-parent = <&intc>; + interrupts = <69>, + <70>; + + status = "disabled"; /* second port is not used on N900 */ + } +} -- cgit v1.1 From eafaebd987fcd001e2c123c050939a29c625d673 Mon Sep 17 00:00:00 2001 From: Sebastian Reichel Date: Fri, 28 Mar 2014 20:19:44 +0100 Subject: HSI: Introduce Nokia N900 modem driver The Nokia N900's modem is connected via Synchronous Serial Interface (SSI), which is a legacy version of MIPI's High-speed Synchronous Serial Interface (HSI). The handles the GPIOs for enabling and resetting the modem and instanciates ssi-protocol for data exchange. It does not yet support exchanging voice data with the modem. Signed-off-by: Sebastian Reichel Reviewed-by: Pavel Machek Tested-By: Ivaylo Dimitrov --- .../devicetree/bindings/hsi/nokia-modem.txt | 57 ++++++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 Documentation/devicetree/bindings/hsi/nokia-modem.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/hsi/nokia-modem.txt b/Documentation/devicetree/bindings/hsi/nokia-modem.txt new file mode 100644 index 0000000..8a97978 --- /dev/null +++ b/Documentation/devicetree/bindings/hsi/nokia-modem.txt @@ -0,0 +1,57 @@ +Nokia modem client bindings + +The Nokia modem HSI client follows the common HSI client binding +and inherits all required properties. The following additional +properties are needed by the Nokia modem HSI client: + +Required properties: +- compatible: Should be one of + "nokia,n900-modem" +- hsi-channel-names: Should contain the following strings + "mcsaab-control" + "speech-control" + "speech-data" + "mcsaab-data" +- gpios: Should provide a GPIO handler for each GPIO listed in + gpio-names +- gpio-names: Should contain the following strings + "cmt_apeslpx" + "cmt_rst_rq" + "cmt_en" + "cmt_rst" + "cmt_bsi" +- interrupts: Should be IRQ handle for modem's reset indication + +Example: + +&ssi_port { + modem: hsi-client { + compatible = "nokia,n900-modem"; + + pinctrl-names = "default"; + pinctrl-0 = <&modem_pins>; + + hsi-channel-ids = <0>, <1>, <2>, <3>; + hsi-channel-names = "mcsaab-control", + "speech-control", + "speech-data", + "mcsaab-data"; + hsi-speed-kbps = <55000>; + hsi-mode = "frame"; + hsi-flow = "synchronized"; + hsi-arb-mode = "round-robin"; + + interrupts-extended = <&gpio3 8 IRQ_TYPE_EDGE_FALLING>; /* 72 */ + + gpios = <&gpio3 6 GPIO_ACTIVE_HIGH>, /* 70 */ + <&gpio3 9 GPIO_ACTIVE_HIGH>, /* 73 */ + <&gpio3 10 GPIO_ACTIVE_HIGH>, /* 74 */ + <&gpio3 11 GPIO_ACTIVE_HIGH>, /* 75 */ + <&gpio5 29 GPIO_ACTIVE_HIGH>; /* 157 */ + gpio-names = "cmt_apeslpx", + "cmt_rst_rq", + "cmt_en", + "cmt_rst", + "cmt_bsi"; + }; +}; -- cgit v1.1 From d55135689019c3a0b26bccd400d90c6d2fd13439 Mon Sep 17 00:00:00 2001 From: Anson Huang Date: Sun, 11 May 2014 22:47:09 +0800 Subject: ARM: imx: add clock driver for imx6sx Add clock driver for i.MX6 SoloX SoC. Signed-off-by: Anson Huang Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/clock/imx6sx-clock.txt | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/imx6sx-clock.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/imx6sx-clock.txt b/Documentation/devicetree/bindings/clock/imx6sx-clock.txt new file mode 100644 index 0000000..22362b9 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx6sx-clock.txt @@ -0,0 +1,13 @@ +* Clock bindings for Freescale i.MX6 SoloX + +Required properties: +- compatible: Should be "fsl,imx6sx-ccm" +- reg: Address and length of the register set +- #clock-cells: Should be <1> +- clocks: list of clock specifiers, must contain an entry for each required + entry in clock-names +- clock-names: should include entries "ckil", "osc", "ipp_di0" and "ipp_di1" + +The clock consumer should specify the desired clock by having the clock +ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6sx-clock.h +for the full list of i.MX6 SoloX clock IDs. -- cgit v1.1 From 46ae42498ef6febdaa6b51359f1ede38cd6b5a47 Mon Sep 17 00:00:00 2001 From: Fabio Estevam Date: Wed, 12 Mar 2014 02:55:46 +0800 Subject: ARM: mx25: Add CLKO support CLKO support is a clock output on mx25 which can output many of the internal clock sources. It is useful for debugging purpose or also for driving the audio codec for example. Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/clock/imx25-clock.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/imx25-clock.txt b/Documentation/devicetree/bindings/clock/imx25-clock.txt index db4f2f0..ba6b312 100644 --- a/Documentation/devicetree/bindings/clock/imx25-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx25-clock.txt @@ -139,6 +139,9 @@ clocks and IDs. uart5_ipg 124 reserved 125 wdt_ipg 126 + cko_div 127 + cko_sel 128 + cko 129 Examples: -- cgit v1.1 From 9d7bf297cb395c7a509e44df0e27a4cf6ba045e7 Mon Sep 17 00:00:00 2001 From: Stefan Agner Date: Thu, 3 Apr 2014 17:47:09 +0200 Subject: of: add vendor prefix for Toradex AG Adds toradex to the list of DT vendor prefixes. Signed-off-by: Stefan Agner Acked-by: Rob Herring Signed-off-by: Shawn Guo --- 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 abc3080..2855004 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -123,6 +123,7 @@ stericsson ST-Ericsson synology Synology, Inc. ti Texas Instruments tlm Trusted Logic Mobility +toradex Toradex AG toshiba Toshiba Corporation toumaz Toumaz usi Universal Scientifc Industrial Co., Ltd. -- cgit v1.1 From f61c42a7d9119a8b72b9607ba8e3a34111f81d8c Mon Sep 17 00:00:00 2001 From: Michal Hocko Date: Mon, 12 May 2014 16:34:17 +0200 Subject: memcg: remove tasks/children test from mem_cgroup_force_empty() Tejun has correctly pointed out that tasks/children test in mem_cgroup_force_empty is not correct because there is no other locking which preserves this state throughout the rest of the function so both new tasks can join the group or new children groups can be added while somebody is writing to memory.force_empty. A new task would break mem_cgroup_reparent_charges expectation that all failures as described by mem_cgroup_force_empty_list are temporal and there is no way out. The main use case for the knob as described by Documentation/cgroups/memory.txt is to: " The typical use case for this interface is before calling rmdir(). Because rmdir() moves all pages to parent, some out-of-use page caches can be moved to the parent. If you want to avoid that, force_empty will be useful. " This means that reparenting is not really required as rmdir will reparent pages implicitly from the safe context. If we remove it from mem_cgroup_force_empty then we are safe even with existing tasks because the number of reclaim attempts is bounded. Moreover the knob still does what the documentation claims (modulo reparenting which doesn't make any difference) and users might expect. Longterm we want to deprecate the whole knob and put the reparented pages to the tail of parent LRU during cgroup removal. tj: Removed unused variable @cgrp from mem_cgroup_force_empty() Signed-off-by: Michal Hocko Acked-by: Johannes Weiner Acked-by: Li Zefan Signed-off-by: Tejun Heo --- Documentation/cgroups/memory.txt | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index 2622115..8cb87e3 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt @@ -453,15 +453,11 @@ About use_hierarchy, see Section 6. 5.1 force_empty memory.force_empty interface is provided to make cgroup's memory usage empty. - You can use this interface only when the cgroup has no tasks. When writing anything to this # echo 0 > memory.force_empty - Almost all pages tracked by this memory cgroup will be unmapped and freed. - Some pages cannot be freed because they are locked or in-use. Such pages are - moved to parent (if use_hierarchy==1) or root (if use_hierarchy==0) and this - cgroup will be empty. + the cgroup will be reclaimed and as many pages reclaimed as possible. The typical use case for this interface is before calling rmdir(). Because rmdir() moves all pages to parent, some out-of-use page caches can be -- cgit v1.1 From 4ec6a9cc23cbadb4721eb3fe778389c4bbede893 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Fri, 16 May 2014 13:05:59 +0200 Subject: PM / runtime: Update documentation to reflect the current code flow The runtime PM documentation in runtime_pm.txt has not been updated after some changes to the system suspend and resume core code, so update it to reflect the current code flow. Signed-off-by: Rafael J. Wysocki Acked-by: Alan Stern --- Documentation/power/runtime_pm.txt | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt index 5f96daf..054893e 100644 --- a/Documentation/power/runtime_pm.txt +++ b/Documentation/power/runtime_pm.txt @@ -648,15 +648,17 @@ The PM core does its best to reduce the probability of race conditions between the runtime PM and system suspend/resume (and hibernation) callbacks by carrying out the following operations: - * During system suspend it calls pm_runtime_get_noresume() and - pm_runtime_barrier() for every device right before executing the - subsystem-level .suspend() callback for it. In addition to that it calls - __pm_runtime_disable() with 'false' as the second argument for every device - right before executing the subsystem-level .suspend_late() callback for it. - - * During system resume it calls pm_runtime_enable() and pm_runtime_put() - for every device right after executing the subsystem-level .resume_early() - callback and right after executing the subsystem-level .resume() callback + * During system suspend pm_runtime_get_noresume() is called for every device + right before executing the subsystem-level .prepare() callback for it and + pm_runtime_barrier() is called for every device right before executing the + subsystem-level .suspend() callback for it. In addition to that the PM core + calls __pm_runtime_disable() with 'false' as the second argument for every + device right before executing the subsystem-level .suspend_late() callback + for it. + + * During system resume pm_runtime_enable() and pm_runtime_put() are called for + every device right after executing the subsystem-level .resume_early() + callback and right after executing the subsystem-level .complete() callback for it, respectively. 7. Generic subsystem callbacks -- cgit v1.1 From f71495f3f0c5f0801823d1235b271a4a415d3df8 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Fri, 16 May 2014 02:47:37 +0200 Subject: PM / sleep: Update device PM documentation to cover direct_complete Update the device PM documentation in devices.txt and runtime_pm.txt to reflect the changes in the system suspend and resume handling related to the introduction of the new power.direct_complete flag. Signed-off-by: Rafael J. Wysocki Acked-by: Alan Stern --- Documentation/power/devices.txt | 34 ++++++++++++++++++++++++++++++---- Documentation/power/runtime_pm.txt | 17 +++++++++++++++++ 2 files changed, 47 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index 47d46df..d172bce 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt @@ -2,6 +2,7 @@ Device Power Management Copyright (c) 2010-2011 Rafael J. Wysocki , Novell Inc. Copyright (c) 2010 Alan Stern +Copyright (c) 2014 Intel Corp., Rafael J. Wysocki Most of the code in Linux is device drivers, so most of the Linux power @@ -326,6 +327,20 @@ the phases are: driver in some way for the upcoming system power transition, but it should not put the device into a low-power state. + For devices supporting runtime power management, the return value of the + prepare callback can be used to indicate to the PM core that it may + safely leave the device in runtime suspend (if runtime-suspended + already), provided that all of the device's descendants are also left in + runtime suspend. Namely, if the prepare callback returns a positive + number and that happens for all of the descendants of the device too, + and all of them (including the device itself) are runtime-suspended, the + PM core will skip the suspend, suspend_late and suspend_noirq suspend + phases as well as the resume_noirq, resume_early and resume phases of + the following system resume for all of these devices. In that case, + the complete callback will be called directly after the prepare callback + and is entirely responsible for bringing the device back to the + functional state as appropriate. + 2. The suspend methods should quiesce the device to stop it from performing I/O. They also may save the device registers and put it into the appropriate low-power state, depending on the bus type the device is on, @@ -400,12 +415,23 @@ When resuming from freeze, standby or memory sleep, the phases are: the resume callbacks occur; it's not necessary to wait until the complete phase. + Moreover, if the preceding prepare callback returned a positive number, + the device may have been left in runtime suspend throughout the whole + system suspend and resume (the suspend, suspend_late, suspend_noirq + phases of system suspend and the resume_noirq, resume_early, resume + phases of system resume may have been skipped for it). In that case, + the complete callback is entirely responsible for bringing the device + back to the functional state after system suspend if necessary. [For + example, it may need to queue up a runtime resume request for the device + for this purpose.] To check if that is the case, the complete callback + can consult the device's power.direct_complete flag. Namely, if that + flag is set when the complete callback is being run, it has been called + directly after the preceding prepare and special action may be required + to make the device work correctly afterward. + At the end of these phases, drivers should be as functional as they were before suspending: I/O can be performed using DMA and IRQs, and the relevant clocks are -gated on. Even if the device was in a low-power state before the system sleep -because of runtime power management, afterwards it should be back in its -full-power state. There are multiple reasons why it's best to do this; they are -discussed in more detail in Documentation/power/runtime_pm.txt. +gated on. However, the details here may again be platform-specific. For example, some systems support multiple "run" states, and the mode in effect at diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt index 5f96daf..e1bee8a 100644 --- a/Documentation/power/runtime_pm.txt +++ b/Documentation/power/runtime_pm.txt @@ -2,6 +2,7 @@ Runtime Power Management Framework for I/O Devices (C) 2009-2011 Rafael J. Wysocki , Novell Inc. (C) 2010 Alan Stern +(C) 2014 Intel Corp., Rafael J. Wysocki 1. Introduction @@ -444,6 +445,10 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: bool pm_runtime_status_suspended(struct device *dev); - return true if the device's runtime PM status is 'suspended' + bool pm_runtime_suspended_if_enabled(struct device *dev); + - return true if the device's runtime PM status is 'suspended' and its + 'power.disable_depth' field is equal to 1 + void pm_runtime_allow(struct device *dev); - set the power.runtime_auto flag for the device and decrease its usage counter (used by the /sys/devices/.../power/control interface to @@ -644,6 +649,18 @@ place (in particular, if the system is not waking up from hibernation), it may be more efficient to leave the devices that had been suspended before the system suspend began in the suspended state. +To this end, the PM core provides a mechanism allowing some coordination between +different levels of device hierarchy. Namely, if a system suspend .prepare() +callback returns a positive number for a device, that indicates to the PM core +that the device appears to be runtime-suspended and its state is fine, so it +may be left in runtime suspend provided that all of its descendants are also +left in runtime suspend. If that happens, the PM core will not execute any +system suspend and resume callbacks for all of those devices, except for the +complete callback, which is then entirely responsible for handling the device +as appropriate. This only applies to system suspend transitions that are not +related to hibernation (see Documentation/power/devices.txt for more +information). + The PM core does its best to reduce the probability of race conditions between the runtime PM and system suspend/resume (and hibernation) callbacks by carrying out the following operations: -- cgit v1.1 From 3be2a49e5c08d268f8af0dd4fe89a24ea8cdc339 Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Fri, 16 May 2014 16:14:05 +0200 Subject: of: provide a binding for fixed link PHYs Some Ethernet MACs have a "fixed link", and are not connected to a normal MDIO-managed PHY device. For those situations, a Device Tree binding allows to describe a "fixed link" using a special PHY node. This patch adds: * A documentation for the fixed PHY Device Tree binding. * An of_phy_is_fixed_link() function that an Ethernet driver can call on its PHY phandle to find out whether it's a fixed link PHY or not. It should typically be used to know if of_phy_register_fixed_link() should be called. * An of_phy_register_fixed_link() function that instantiates the fixed PHY into the PHY subsystem, so that when the driver calls of_phy_connect(), the PHY device associated to the OF node will be found. These two additional functions also support the old fixed-link Device Tree binding used on PowerPC platforms, so that ultimately, the network device drivers for those platforms could be converted to use of_phy_is_fixed_link() and of_phy_register_fixed_link() instead of of_phy_connect_fixed_link(), while keeping compatibility with their respective Device Tree bindings. Signed-off-by: Thomas Petazzoni Reviewed-by: Florian Fainelli Tested-by: Florian Fainelli Signed-off-by: David S. Miller --- .../devicetree/bindings/net/fixed-link.txt | 30 ++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/fixed-link.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/fixed-link.txt b/Documentation/devicetree/bindings/net/fixed-link.txt new file mode 100644 index 0000000..e956de1 --- /dev/null +++ b/Documentation/devicetree/bindings/net/fixed-link.txt @@ -0,0 +1,30 @@ +Fixed link Device Tree binding +------------------------------ + +Some Ethernet MACs have a "fixed link", and are not connected to a +normal MDIO-managed PHY device. For those situations, a Device Tree +binding allows to describe a "fixed link". + +Such a fixed link situation is described by creating a 'fixed-link' +sub-node of the Ethernet MAC device node, with the following +properties: + +* 'speed' (integer, mandatory), to indicate the link speed. Accepted + values are 10, 100 and 1000 +* 'full-duplex' (boolean, optional), to indicate that full duplex is + used. When absent, half duplex is assumed. +* 'pause' (boolean, optional), to indicate that pause should be + enabled. +* 'asym-pause' (boolean, optional), to indicate that asym_pause should + be enabled. + +Example: + +ethernet@0 { + ... + fixed-link { + speed = <1000>; + full-duplex; + }; + ... +}; -- cgit v1.1 From 664c6588e7ae2bc4f12230a03727159729e97f48 Mon Sep 17 00:00:00 2001 From: Chanwoo Choi Date: Sat, 17 May 2014 07:37:37 +0900 Subject: dt-bindings: add documentation for Exynos3250 clock controller The Exynos3250 clocks are statically listed and registered using the Samsung specific common clock helper functions. Both device tree based clock lookup and clkdev based clock lookups are supported. Signed-off-by: Chanwoo Choi Signed-off-by: Tomasz Figa Acked-by: Kyungmin Park Cc: Mike Turquette Cc: Kukjin Kim Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Cc: Randy Dunlap Acked-by: Tomasz Figa Signed-off-by: Kukjin Kim --- .../devicetree/bindings/clock/exynos3250-clock.txt | 41 ++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/exynos3250-clock.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/exynos3250-clock.txt b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt new file mode 100644 index 0000000..aadc9c5 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt @@ -0,0 +1,41 @@ +* Samsung Exynos3250 Clock Controller + +The Exynos3250 clock controller generates and supplies clock to various +controllers within the Exynos3250 SoC. + +Required Properties: + +- compatible: should be one of the following. + - "samsung,exynos3250-cmu" - controller compatible with Exynos3250 SoC. + +- reg: physical base address of the controller and length of memory mapped + region. + +- #clock-cells: should be 1. + +Each clock is assigned an identifier and client nodes can use this identifier +to specify the clock which they consume. + +All available clocks are defined as preprocessor macros in +dt-bindings/clock/exynos3250.h header and can be used in device +tree sources. + +Example 1: An example of a clock controller node is listed below. + + cmu: clock-controller@10030000 { + compatible = "samsung,exynos3250-cmu"; + reg = <0x10030000 0x20000>; + #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@13800000 { + compatible = "samsung,exynos4210-uart"; + reg = <0x13800000 0x100>; + interrupts = <0 109 0>; + clocks = <&cmu CLK_UART0>, <&cmu CLK_SCLK_UART0>; + clock-names = "uart", "clk_uart_baud0"; + }; -- cgit v1.1 From c6594025c0f8cea2ba089444a359495bd0ea3e6f Mon Sep 17 00:00:00 2001 From: Maxime Coquelin Date: Thu, 27 Feb 2014 13:17:27 +0100 Subject: ARM: STi: Add STiH407 SoC support This patch adds support to STiH407 SoC. Acked-by: Giuseppe Cavallaro Signed-off-by: Giuseppe Cavallaro Signed-off-by: Maxime Coquelin --- Documentation/arm/sti/stih407-overview.txt | 18 ++++++++++++++++++ Documentation/devicetree/bindings/arm/sti.txt | 15 +++++++++++++++ 2 files changed, 33 insertions(+) create mode 100644 Documentation/arm/sti/stih407-overview.txt create mode 100644 Documentation/devicetree/bindings/arm/sti.txt (limited to 'Documentation') diff --git a/Documentation/arm/sti/stih407-overview.txt b/Documentation/arm/sti/stih407-overview.txt new file mode 100644 index 0000000..3343f32 --- /dev/null +++ b/Documentation/arm/sti/stih407-overview.txt @@ -0,0 +1,18 @@ + STiH407 Overview + ================ + +Introduction +------------ + + The STiH407 is the new generation of SoC for Multi-HD, AVC set-top boxes + and server/connected client application for satellite, cable, terrestrial + and IP-STB markets. + + Features + - ARM Cortex-A9 1.5 GHz dual core CPU (28nm) + - SATA2, USB 3.0, PCIe, Gbit Ethernet + + Document Author + --------------- + + Maxime Coquelin , (c) 2014 ST Microelectronics diff --git a/Documentation/devicetree/bindings/arm/sti.txt b/Documentation/devicetree/bindings/arm/sti.txt new file mode 100644 index 0000000..92f16c7 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/sti.txt @@ -0,0 +1,15 @@ +ST STi Platforms Device Tree Bindings +--------------------------------------- + +Boards with the ST STiH415 SoC shall have the following properties: +Required root node property: +compatible = "st,stih415"; + +Boards with the ST STiH416 SoC shall have the following properties: +Required root node property: +compatible = "st,stih416"; + +Boards with the ST STiH407 SoC shall have the following properties: +Required root node property: +compatible = "st,stih407"; + -- cgit v1.1 From 840cf8259ce3db6ab81ed14729fde37cfb343104 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Fri, 18 Apr 2014 21:01:49 +0200 Subject: Documentation: dt: bindings: Document ARM PSCI enable method arm,psci is also a valid enable-method for the CPUs on ARM. Document it. Signed-off-by: Maxime Ripard --- Documentation/devicetree/bindings/arm/cpus.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index 333f4ae..ad6f775 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -182,6 +182,7 @@ nodes to be present and contain the properties described below. "psci" # On ARM 32-bit systems this property is optional and can be one of: + "arm,psci" "qcom,gcc-msm8660" "qcom,kpss-acc-v1" "qcom,kpss-acc-v2" -- cgit v1.1 From 913627b314b48e867721e3b3c4cfdcb1bda1307d Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Fri, 18 Apr 2014 21:01:51 +0200 Subject: Documentation: dt: bindings: Document Allwinner A31 enable method Document the necently introduced A31 enable-method as a valid option. Signed-off-by: Maxime Ripard --- Documentation/devicetree/bindings/arm/cpus.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index ad6f775..14611d2 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -183,6 +183,7 @@ nodes to be present and contain the properties described below. # On ARM 32-bit systems this property is optional and can be one of: "arm,psci" + "allwinner,sun6i-a31" "qcom,gcc-msm8660" "qcom,kpss-acc-v1" "qcom,kpss-acc-v2" -- cgit v1.1 From d8f17c49d3f26b5700624819adfd5349798b5162 Mon Sep 17 00:00:00 2001 From: Ezequiel Garcia Date: Sun, 18 May 2014 21:02:17 -0300 Subject: irqchip: armada-370-xp: Move the devicetree binding documentation Move the devicetree binding documentation to the interrupt-controller directory, where it belongs. Reviewed-by: Thomas Petazzoni Signed-off-by: Ezequiel Garcia Link: https://lkml.kernel.org/r/1400457737-1617-1-git-send-email-ezequiel.garcia@free-electrons.com Signed-off-by: Jason Cooper --- .../devicetree/bindings/arm/armada-370-xp-mpic.txt | 38 ---------------------- .../marvell,armada-370-xp-mpic.txt | 38 ++++++++++++++++++++++ 2 files changed, 38 insertions(+), 38 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,armada-370-xp-mpic.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt deleted file mode 100644 index 5fc0313..0000000 --- a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt +++ /dev/null @@ -1,38 +0,0 @@ -Marvell Armada 370, 375, 38x, XP Interrupt Controller ------------------------------------------------------ - -Required properties: -- compatible: Should be "marvell,mpic" -- interrupt-controller: Identifies the node as an interrupt controller. -- msi-controller: Identifies the node as an PCI Message Signaled - Interrupt controller. -- #interrupt-cells: The number of cells to define the interrupts. Should be 1. - The cell is the IRQ number - -- reg: Should contain PMIC registers location and length. First pair - for the main interrupt registers, second pair for the per-CPU - interrupt registers. For this last pair, to be compliant with SMP - support, the "virtual" must be use (For the record, these registers - automatically map to the interrupt controller registers of the - current CPU) - -Optional properties: - -- interrupts: If defined, then it indicates that this MPIC is - connected as a slave to another interrupt controller. This is - typically the case on Armada 375 and Armada 38x, where the MPIC is - connected as a slave to the Cortex-A9 GIC. The provided interrupt - indicate to which GIC interrupt the MPIC output is connected. - -Example: - - mpic: interrupt-controller@d0020000 { - compatible = "marvell,mpic"; - #interrupt-cells = <1>; - #address-cells = <1>; - #size-cells = <1>; - interrupt-controller; - msi-controller; - reg = <0xd0020a00 0x1d0>, - <0xd0021070 0x58>; - }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,armada-370-xp-mpic.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,armada-370-xp-mpic.txt new file mode 100644 index 0000000..5fc0313 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,armada-370-xp-mpic.txt @@ -0,0 +1,38 @@ +Marvell Armada 370, 375, 38x, XP Interrupt Controller +----------------------------------------------------- + +Required properties: +- compatible: Should be "marvell,mpic" +- interrupt-controller: Identifies the node as an interrupt controller. +- msi-controller: Identifies the node as an PCI Message Signaled + Interrupt controller. +- #interrupt-cells: The number of cells to define the interrupts. Should be 1. + The cell is the IRQ number + +- reg: Should contain PMIC registers location and length. First pair + for the main interrupt registers, second pair for the per-CPU + interrupt registers. For this last pair, to be compliant with SMP + support, the "virtual" must be use (For the record, these registers + automatically map to the interrupt controller registers of the + current CPU) + +Optional properties: + +- interrupts: If defined, then it indicates that this MPIC is + connected as a slave to another interrupt controller. This is + typically the case on Armada 375 and Armada 38x, where the MPIC is + connected as a slave to the Cortex-A9 GIC. The provided interrupt + indicate to which GIC interrupt the MPIC output is connected. + +Example: + + mpic: interrupt-controller@d0020000 { + compatible = "marvell,mpic"; + #interrupt-cells = <1>; + #address-cells = <1>; + #size-cells = <1>; + interrupt-controller; + msi-controller; + reg = <0xd0020a00 0x1d0>, + <0xd0021070 0x58>; + }; -- cgit v1.1 From 277bd320e7dd8b77de6d3b6b9757b08fcca0108b Mon Sep 17 00:00:00 2001 From: Oliver Hartkopp Date: Wed, 2 Apr 2014 20:25:27 +0200 Subject: can: add documentation for CAN filter usage optimisation To benefit from special filters for single SFF or single EFF CAN identifier subscriptions the CAN_EFF_FLAG bit and the CAN_RTR_FLAG bit has to be set together with the CAN_(SFF|EFF)_MASK in can_filter.mask. Signed-off-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde --- Documentation/networking/can.txt | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt index 2fa44cb..cdd381c 100644 --- a/Documentation/networking/can.txt +++ b/Documentation/networking/can.txt @@ -469,6 +469,41 @@ solution for a couple of reasons: having this 'send only' use-case we may remove the receive list in the Kernel to save a little (really a very little!) CPU usage. + 4.1.1.1 CAN filter usage optimisation + + The CAN filters are processed in per-device filter lists at CAN frame + reception time. To reduce the number of checks that need to be performed + while walking through the filter lists the CAN core provides an optimized + filter handling when the filter subscription focusses on a single CAN ID. + + For the possible 2048 SFF CAN identifiers the identifier is used as an index + to access the corresponding subscription list without any further checks. + For the 2^29 possible EFF CAN identifiers a 10 bit XOR folding is used as + hash function to retrieve the EFF table index. + + To benefit from the optimized filters for single CAN identifiers the + CAN_SFF_MASK or CAN_EFF_MASK have to be set into can_filter.mask together + with set CAN_EFF_FLAG and CAN_RTR_FLAG bits. A set CAN_EFF_FLAG bit in the + can_filter.mask makes clear that it matters whether a SFF or EFF CAN ID is + subscribed. E.g. in the example from above + + rfilter[0].can_id = 0x123; + rfilter[0].can_mask = CAN_SFF_MASK; + + both SFF frames with CAN ID 0x123 and EFF frames with 0xXXXXX123 can pass. + + To filter for only 0x123 (SFF) and 0x12345678 (EFF) CAN identifiers the + filter has to be defined in this way to benefit from the optimized filters: + + struct can_filter rfilter[2]; + + rfilter[0].can_id = 0x123; + rfilter[0].can_mask = (CAN_EFF_FLAG | CAN_RTR_FLAG | CAN_SFF_MASK); + rfilter[1].can_id = 0x12345678 | CAN_EFF_FLAG; + rfilter[1].can_mask = (CAN_EFF_FLAG | CAN_RTR_FLAG | CAN_EFF_MASK); + + setsockopt(s, SOL_CAN_RAW, CAN_RAW_FILTER, &rfilter, sizeof(rfilter)); + 4.1.2 RAW socket option CAN_RAW_ERR_FILTER As described in chapter 3.4 the CAN interface driver can generate so -- cgit v1.1 From bd21eaf92b249c9925b7fc2123b81167ff191270 Mon Sep 17 00:00:00 2001 From: Armen Baloyan Date: Fri, 11 Apr 2014 16:54:24 -0400 Subject: qla2xxx: Change copyright year to 2014 in all the source files. Signed-off-by: Armen Baloyan Signed-off-by: Saurav Kashyap Signed-off-by: Christoph Hellwig --- Documentation/scsi/LICENSE.qla2xxx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/scsi/LICENSE.qla2xxx b/Documentation/scsi/LICENSE.qla2xxx index 5020b7b..52f0b43 100644 --- a/Documentation/scsi/LICENSE.qla2xxx +++ b/Documentation/scsi/LICENSE.qla2xxx @@ -1,4 +1,4 @@ -Copyright (c) 2003-2013 QLogic Corporation +Copyright (c) 2003-2014 QLogic Corporation QLogic Linux FC-FCoE Driver This program includes a device driver for Linux 3.x. -- cgit v1.1 From 6520e968eef4f88c076a84a80e026049d157132e Mon Sep 17 00:00:00 2001 From: Alim Akhtar Date: Mon, 19 May 2014 22:15:08 +0900 Subject: clk: exynos5420: Add 5800 specific clocks Exynos5800 clock structure is mostly similar to 5420 with only a small delta changes. So the 5420 clock file is re-used for 5800 also. The common clocks for both are seggreagated and few clocks which are different for both are separately initialized. Signed-off-by: Alim Akhtar Signed-off-by: Arun Kumar K Acked-by: Tomasz Figa Signed-off-by: Kukjin Kim --- Documentation/devicetree/bindings/clock/exynos5420-clock.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt index ca88c97..d54f42c 100644 --- a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt @@ -1,12 +1,13 @@ * Samsung Exynos5420 Clock Controller The Exynos5420 clock controller generates and supplies clock to various -controllers within the Exynos5420 SoC. +controllers within the Exynos5420 SoC and for the Exynos5800 SoC. Required Properties: - compatible: should be one of the following. - "samsung,exynos5420-clock" - controller compatible with Exynos5420 SoC. + - "samsung,exynos5800-clock" - controller compatible with Exynos5800 SoC. - reg: physical base address of the controller and length of memory mapped region. -- cgit v1.1 From 221069bed0c73e876e1df1f6cd0140cb353fcd32 Mon Sep 17 00:00:00 2001 From: Alan Date: Mon, 19 May 2014 14:02:17 +0100 Subject: doc: Note need of bc in the kernel build from 3.10 onwards HPA did the world a favour and reduced the number of perl scripts in the universe. However we do now need bc Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=60575 Signed-off-by: Alan Cox Signed-off-by: Jiri Kosina --- Documentation/Changes | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/Changes b/Documentation/Changes index 07c75d1..2254db0 100644 --- a/Documentation/Changes +++ b/Documentation/Changes @@ -73,6 +73,11 @@ Perl You will need perl 5 and the following modules: Getopt::Long, Getopt::Std, File::Basename, and File::Find to build the kernel. +BC +-- + +You will need bc to build kernels 3.10 and higher + System utilities ================ -- cgit v1.1 From af987718f0bb238a7f09bf6aa9b87c7121e3bbd3 Mon Sep 17 00:00:00 2001 From: Antoine Tenart Date: Tue, 18 Mar 2014 15:32:46 +0100 Subject: ARM: berlin: add Marvell Armada 1500 pro to Marvell doc This adds Marvell Berlin Armada 1500 Pro (BG2Q) to Marvell SoC documentation. Signed-off-by: Antoine Tenart Signed-off-by: Sebastian Hesselbarth --- Documentation/arm/Marvell/README | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README index 963ec44..2cce540 100644 --- a/Documentation/arm/Marvell/README +++ b/Documentation/arm/Marvell/README @@ -234,6 +234,11 @@ Berlin family (Digital Entertainment) Core: Marvell PJ4B (ARMv7), Tauros3 L2CC Homepage: http://www.marvell.com/digital-entertainment/armada-1500/ Product Brief: http://www.marvell.com/digital-entertainment/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf + 88DE3114, Armada 1500 Pro + Design name: BG2-Q + Core: Quad Core ARM Cortex-A9, PL310 L2CC + Homepage: http://www.marvell.com/digital-entertainment/armada-1500-pro/ + Product Brief: http://www.marvell.com/digital-entertainment/armada-1500-pro/assets/Marvell_ARMADA_1500_PRO-01_product_brief.pdf 88DE???? Design name: BG3 Core: ARM Cortex-A15, CA15 integrated L2CC -- cgit v1.1 From 374ddcbf2dc2033afd9564c548fe790cf677a35b Mon Sep 17 00:00:00 2001 From: Antoine Tenart Date: Tue, 18 Mar 2014 15:32:45 +0100 Subject: ARM: dts: berlin: add the Marvell Armada 1500 pro Adds initial support for the Marvell Armada 1500 pro (BG2Q) SoC (Berlin family). The SoC has nodes for cpu, l2 cache controller, interrupt controllers, local timer, apb timers and uarts for now. Also add corresponding binding documentation. Signed-off-by: Antoine Tenart Signed-off-by: Alexandre Belloni Reviewed-by: Mark Rutland Signed-off-by: Sebastian Hesselbarth --- Documentation/devicetree/bindings/arm/marvell,berlin.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/marvell,berlin.txt b/Documentation/devicetree/bindings/arm/marvell,berlin.txt index 737afa5..0677003 100644 --- a/Documentation/devicetree/bindings/arm/marvell,berlin.txt +++ b/Documentation/devicetree/bindings/arm/marvell,berlin.txt @@ -12,6 +12,7 @@ SoC and board used. Currently known SoC compatibles are: "marvell,berlin2" for Marvell Armada 1500 (BG2, 88DE3100), "marvell,berlin2cd" for Marvell Armada 1500-mini (BG2CD, 88DE3005) "marvell,berlin2ct" for Marvell Armada ? (BG2CT, 88DE????) + "marvell,berlin2q" for Marvell Armada 1500-pro (BG2Q, 88DE3114) "marvell,berlin3" for Marvell Armada ? (BG3, 88DE????) * Example: -- cgit v1.1 From 55a4b07aaa7eb9dde7df2ee681ac9aa1d0fbd698 Mon Sep 17 00:00:00 2001 From: Sebastian Hesselbarth Date: Sat, 10 May 2014 13:46:12 +0200 Subject: dt-binding: ARM: add clock binding docs for Marvell Berlin2 SoCs This adds mandatory device tree binding documentation for the clock related IP found on Marvell Berlin2 (BG2, BG2CD, and BG2Q) SoCs to the Berlin SoC binding documentation. Signed-off-by: Sebastian Hesselbarth --- .../devicetree/bindings/arm/marvell,berlin.txt | 47 ++++++++++++++++++++++ 1 file changed, 47 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/marvell,berlin.txt b/Documentation/devicetree/bindings/arm/marvell,berlin.txt index 0677003..744a7ea 100644 --- a/Documentation/devicetree/bindings/arm/marvell,berlin.txt +++ b/Documentation/devicetree/bindings/arm/marvell,berlin.txt @@ -23,3 +23,50 @@ SoC and board used. Currently known SoC compatibles are: ... } + +* Marvell Berlin2 chip control binding + +Marvell Berlin SoCs have a chip control register set providing several +individual registers dealing with pinmux, padmux, clock, reset, and secondary +CPU boot address. Unfortunately, the individual registers are spread among the +chip control registers, so there should be a single DT node only providing the +different functions which are described below. + +Required properties: +- compatible: shall be one of + "marvell,berlin2-chip-ctrl" for BG2 + "marvell,berlin2cd-chip-ctrl" for BG2CD + "marvell,berlin2q-chip-ctrl" for BG2Q +- reg: address and length of following register sets for + BG2/BG2CD: chip control register set + BG2Q: chip control register set and cpu pll registers + +* Clock provider binding + +As clock related registers are spread among the chip control registers, the +chip control node also provides the clocks. Marvell Berlin2 (BG2, BG2CD, BG2Q) +SoCs share the same IP for PLLs and clocks, with some minor differences in +features and register layout. + +Required properties: +- #clock-cells: shall be set to 1 +- clocks: clock specifiers referencing the core clock input clocks +- clock-names: array of strings describing the input clock specifiers above. + Allowed clock-names for the reference clocks are + "refclk" for the SoCs osciallator input on all SoCs, + and SoC-specific input clocks for + BG2/BG2CD: "video_ext0" for the external video clock input + +Clocks provided by core clocks shall be referenced by a clock specifier +indexing one of the provided clocks. Refer to dt-bindings/clock/berlin.h +for the corresponding index mapping. + +Example: + +chip: chip-control@ea0000 { + compatible = "marvell,berlin2-chip-ctrl"; + #clock-cells = <1>; + reg = <0xea0000 0x400>; + clocks = <&refclk>, <&externaldev 0>; + clock-names = "refclk", "video_ext0"; +}; -- cgit v1.1 From e9673a752897c2127e5aefd4663016bca817a0fe Mon Sep 17 00:00:00 2001 From: Antoine Tenart Date: Mon, 5 May 2014 07:27:28 +0200 Subject: dt-binding: ARM: add pinctrl binding docs for Marvell Berlin2 SoCs Add pin control binding documentation to the SoC binding documentaion as pinctrl is part of chip/system control registers. The documentation also explains how to configure this group based controller. Signed-off-by: Antoine Tenart Signed-off-by: Sebastian Hesselbarth --- .../devicetree/bindings/arm/marvell,berlin.txt | 54 ++++++++++++++++++++++ 1 file changed, 54 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/marvell,berlin.txt b/Documentation/devicetree/bindings/arm/marvell,berlin.txt index 744a7ea..94013a9 100644 --- a/Documentation/devicetree/bindings/arm/marvell,berlin.txt +++ b/Documentation/devicetree/bindings/arm/marvell,berlin.txt @@ -41,6 +41,18 @@ Required properties: BG2/BG2CD: chip control register set BG2Q: chip control register set and cpu pll registers +* Marvell Berlin2 system control binding + +Marvell Berlin SoCs have a system control register set providing several +individual registers dealing with pinmux, padmux, and reset. + +Required properties: +- compatible: should be one of + "marvell,berlin2-system-ctrl" for BG2 + "marvell,berlin2cd-system-ctrl" for BG2CD + "marvell,berlin2q-system-ctrl" for BG2Q +- reg: address and length of the system control register set + * Clock provider binding As clock related registers are spread among the chip control registers, the @@ -61,6 +73,23 @@ Clocks provided by core clocks shall be referenced by a clock specifier indexing one of the provided clocks. Refer to dt-bindings/clock/berlin.h for the corresponding index mapping. +* Pin controller binding + +Pin control registers are part of both register sets, chip control and system +control. The pins controlled are organized in groups, so no actual pin +information is needed. + +A pin-controller node should contain subnodes representing the pin group +configurations, one per function. Each subnode has the group name and the muxing +function used. + +Be aware the Marvell Berlin datasheets use the keyword 'mode' for what is called +a 'function' in the pin-controller subsystem. + +Required subnode-properties: +- groups: a list of strings describing the group names. +- function: a string describing the function used to mux the groups. + Example: chip: chip-control@ea0000 { @@ -69,4 +98,29 @@ chip: chip-control@ea0000 { reg = <0xea0000 0x400>; clocks = <&refclk>, <&externaldev 0>; clock-names = "refclk", "video_ext0"; + + spi1_pmux: spi1-pmux { + groups = "G0"; + function = "spi1"; + }; +}; + +sysctrl: system-controller@d000 { + compatible = "marvell,berlin2-system-ctrl"; + reg = <0xd000 0x100>; + + uart0_pmux: uart0-pmux { + groups = "GSM4"; + function = "uart0"; + }; + + uart1_pmux: uart1-pmux { + groups = "GSM5"; + function = "uart1"; + }; + + uart2_pmux: uart2-pmux { + groups = "GSM3"; + function = "uart2"; + }; }; -- cgit v1.1 From f517a5f370de4171afe1487d67345d7eef1f1822 Mon Sep 17 00:00:00 2001 From: Christophe Ricard Date: Tue, 13 May 2014 22:03:40 +0200 Subject: NFC: dts: st21nfca_i2c: Add DTS Documentation Describe the properties used by the st21nfca NFC controller driver. Signed-off-by: Christophe Ricard Signed-off-by: Samuel Ortiz --- .../devicetree/bindings/net/nfc/st21nfca.txt | 33 ++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/nfc/st21nfca.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/nfc/st21nfca.txt b/Documentation/devicetree/bindings/net/nfc/st21nfca.txt new file mode 100644 index 0000000..4724fe6 --- /dev/null +++ b/Documentation/devicetree/bindings/net/nfc/st21nfca.txt @@ -0,0 +1,33 @@ +* STMicroelectronics SAS. ST21NFCA NFC Controller + +Required properties: +- compatible: Should be "st,st21nfca-i2c". +- clock-frequency: I²C work frequency. +- reg: address on the bus +- interrupt-parent: phandle for the interrupt gpio controller +- interrupts: GPIO interrupt to which the chip is connected +- enable-gpios: Output GPIO pin used for enabling/disabling the ST21NFCA + +Optional SoC Specific Properties: +- pinctrl-names: Contains only one value - "default". +- pintctrl-0: Specifies the pin control groups used for this controller. + +Example (for ARM-based BeagleBoard xM with ST21NFCA on I2C2): + +&i2c2 { + + status = "okay"; + + st21nfca: st21nfca@1 { + + compatible = "st,st21nfca_i2c"; + + reg = <0x01>; + clock-frequency = <400000>; + + interrupt-parent = <&gpio5>; + interrupts = <2 IRQ_TYPE_LEVEL_LOW>; + + enable-gpios = <&gpio5 29 GPIO_ACTIVE_HIGH>; + }; +}; -- cgit v1.1 From 39065401e2f77e15be1959c766a00e0a9e05a374 Mon Sep 17 00:00:00 2001 From: Joachim Eastwood Date: Mon, 12 May 2014 20:32:00 +0200 Subject: ARM: dts: Add support for OMAP4 Variscite OM44 family Add support for VAR-SOM-OM44[1] SODIMM system on module from Variscite. SoM features a OMAP4460, 1GB RAM, Gigabit Ethernet (LAN7500) and optional WLAN/BT. Also add support for VAR-STK-OM44 development board from Variscite. This kit features a VAR-SOM-OM44 and the carrier board VAR-OM44CustomBoard[2]. The VAR-STK-OM44 is the same as VAR-DVK-OM44 but without the LCD display. omap4-var-stk-om44.dts replace the old and very limited omap4-var-som.dts. [1] http://www.variscite.com/products/system-on-module-som/cortex-a9/var-som-om44-cpu-ti-omap-4-omap4460 [2] http://www.variscite.com/products/single-board-computers/var-om44customboard Signed-off-by: Joachim Eastwood Acked-by: Tomi Valkeinen Signed-off-by: Tony Lindgren --- Documentation/devicetree/bindings/arm/omap/omap.txt | 3 +++ Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 2 files changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index 3bad259..b2f1948 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -105,6 +105,9 @@ Boards: - OMAP4 DuoVero with Parlor : Commercial expansion board with daughter board compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4"; +- OMAP4 VAR-STK-OM44 : Commercial dev kit with VAR-OM44CustomBoard and VAR-SOM-OM44 w/WLAN + compatible = "variscite,var-stk-om44", "variscite,var-som-om44", "ti,omap4460", "ti,omap4"; + - OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x compatible = "ti,omap3-evm", "ti,omap3" diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index abc3080..cc5a116 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -127,6 +127,7 @@ toshiba Toshiba Corporation toumaz Toumaz usi Universal Scientifc Industrial Co., Ltd. v3 V3 Semiconductor +variscite Variscite Ltd. via VIA Technologies, Inc. voipac Voipac Technologies s.r.o. winbond Winbond Electronics corp. -- cgit v1.1 From bdfd0abdc67f17b71bd92ddff16449e8c16b2aa3 Mon Sep 17 00:00:00 2001 From: Joachim Eastwood Date: Mon, 12 May 2014 20:32:01 +0200 Subject: ARM: dts: Add support for OMAP4 VAR-DVK-OM44 Signed-off-by: Joachim Eastwood Acked-by: Tomi Valkeinen Signed-off-by: Tony Lindgren --- 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 b2f1948..189baba 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -108,6 +108,9 @@ Boards: - OMAP4 VAR-STK-OM44 : Commercial dev kit with VAR-OM44CustomBoard and VAR-SOM-OM44 w/WLAN compatible = "variscite,var-stk-om44", "variscite,var-som-om44", "ti,omap4460", "ti,omap4"; +- OMAP4 VAR-DVK-OM44 : Commercial dev kit with VAR-OM44CustomBoard, VAR-SOM-OM44 w/WLAN and LCD touchscreen + compatible = "variscite,var-dvk-om44", "variscite,var-som-om44", "ti,omap4460", "ti,omap4"; + - OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x compatible = "ti,omap3-evm", "ti,omap3" -- cgit v1.1 From bf28a5970de3a349ec05cea45ca5272404b6609f Mon Sep 17 00:00:00 2001 From: Michael Holzheu Date: Mon, 14 Apr 2014 10:38:05 +0200 Subject: s390/dump: Remove CONFIG_ZFCPDUMP Currently there are two s390 kernel dump config options "CONFIG_ZFCPDUMP" and "CONFIG_CRASH_DUMP". In order to keep things simple and because the "CONFIG_ZFCPDUMP" option already has a dependency to "CONFIG_CRASH_DUMP" remove the CONFIG_ZFCPDUMP option. Signed-off-by: Michael Holzheu Reviewed-by: Eric Farman Signed-off-by: Martin Schwidefsky --- Documentation/s390/zfcpdump.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/s390/zfcpdump.txt b/Documentation/s390/zfcpdump.txt index cf45d27..1cae248 100644 --- a/Documentation/s390/zfcpdump.txt +++ b/Documentation/s390/zfcpdump.txt @@ -21,7 +21,7 @@ standalone dump format. It can be used in the same way as e.g. /dev/mem. The dump format defines a 4K header followed by plain uncompressed memory. The register sets are stored in the prefix pages of the respective cpus. To build a dump enabled kernel with the zcore driver, the kernel config option -CONFIG_ZFCPDUMP has to be set. When reading from "zcore/mem", the part of +CONFIG_CRASH_DUMP has to be set. When reading from "zcore/mem", the part of memory, which has been saved by hardware is read by the driver via the SCLP hardware interface. The second part is just copied from the non overwritten real memory. @@ -32,7 +32,7 @@ SCSI disk. To build a zfcpdump kernel use the following settings in your kernel configuration: - * CONFIG_ZFCPDUMP=y + * CONFIG_CRASH_DUMP=y * Enable ZFCP driver * Enable SCSI driver * Enable ext2 and ext3 filesystems -- cgit v1.1 From 7d4c738ce522692cc328869a6633704e535d7124 Mon Sep 17 00:00:00 2001 From: Michael Holzheu Date: Mon, 14 Apr 2014 11:56:07 +0200 Subject: s390/zfcpdump: Update documentation in zfcpdump.txt Do the following changes: - Document new /proc/vmcore interface - Document partition dump external initramfs with s390-tools-1.24.0 - Remove initramfs config file because initramfs is now built automatically in s390-tools - Replace description of kernel config options with "make zfcpdump_defconfig" - Some editorial changes Signed-off-by: Michael Holzheu Signed-off-by: Martin Schwidefsky --- Documentation/s390/zfcpdump.txt | 71 +++++++++++------------------------------ 1 file changed, 18 insertions(+), 53 deletions(-) (limited to 'Documentation') diff --git a/Documentation/s390/zfcpdump.txt b/Documentation/s390/zfcpdump.txt index 1cae248..dc929be 100644 --- a/Documentation/s390/zfcpdump.txt +++ b/Documentation/s390/zfcpdump.txt @@ -1,15 +1,15 @@ -s390 SCSI dump tool (zfcpdump) +The s390 SCSI dump tool (zfcpdump) System z machines (z900 or higher) provide hardware support for creating system dumps on SCSI disks. The dump process is initiated by booting a dump tool, which has to create a dump of the current (probably crashed) Linux image. In order to not overwrite memory of the crashed Linux with data of the dump tool, the -hardware saves some memory plus the register sets of the boot cpu before the +hardware saves some memory plus the register sets of the boot CPU before the dump tool is loaded. There exists an SCLP hardware interface to obtain the saved memory afterwards. Currently 32 MB are saved. This zfcpdump implementation consists of a Linux dump kernel together with -a userspace dump tool, which are loaded together into the saved memory region +a user space dump tool, which are loaded together into the saved memory region below 32 MB. zfcpdump is installed on a SCSI disk using zipl (as contained in the s390-tools package) to make the device bootable. The operator of a Linux system can then trigger a SCSI dump by booting the SCSI disk, where zfcpdump @@ -19,68 +19,33 @@ The kernel part of zfcpdump is implemented as a debugfs file under "zcore/mem", which exports memory and registers of the crashed Linux in an s390 standalone dump format. It can be used in the same way as e.g. /dev/mem. The dump format defines a 4K header followed by plain uncompressed memory. The -register sets are stored in the prefix pages of the respective cpus. To build a +register sets are stored in the prefix pages of the respective CPUs. To build a dump enabled kernel with the zcore driver, the kernel config option CONFIG_CRASH_DUMP has to be set. When reading from "zcore/mem", the part of memory, which has been saved by hardware is read by the driver via the SCLP hardware interface. The second part is just copied from the non overwritten real memory. -The userspace application of zfcpdump can reside e.g. in an intitramfs or an -initrd. It reads from zcore/mem and writes the system dump to a file on a -SCSI disk. +Since kernel version 3.12 also the /proc/vmcore file can also be used to access +the dump. -To build a zfcpdump kernel use the following settings in your kernel -configuration: - * CONFIG_CRASH_DUMP=y - * Enable ZFCP driver - * Enable SCSI driver - * Enable ext2 and ext3 filesystems - * Disable as many features as possible to keep the kernel small. - E.g. network support is not needed at all. +To get a valid zfcpdump kernel configuration use "make zfcpdump_defconfig". -To use the zfcpdump userspace application in an initramfs you have to do the -following: +The s390 zipl tool looks for the zfcpdump kernel and optional initrd/initramfs +under the following locations: - * Copy the zfcpdump executable somewhere into your Linux tree. - E.g. to "arch/s390/boot/zfcpdump. If you do not want to include - shared libraries, compile the tool with the "-static" gcc option. - * If you want to include e2fsck, add it to your source tree, too. The zfcpdump - application attempts to start /sbin/e2fsck from the ramdisk. - * Use an initramfs config file like the following: +* kernel: /zfcpdump.image +* ramdisk: /zfcpdump.rd - dir /dev 755 0 0 - nod /dev/console 644 0 0 c 5 1 - nod /dev/null 644 0 0 c 1 3 - nod /dev/sda1 644 0 0 b 8 1 - nod /dev/sda2 644 0 0 b 8 2 - nod /dev/sda3 644 0 0 b 8 3 - nod /dev/sda4 644 0 0 b 8 4 - nod /dev/sda5 644 0 0 b 8 5 - nod /dev/sda6 644 0 0 b 8 6 - nod /dev/sda7 644 0 0 b 8 7 - nod /dev/sda8 644 0 0 b 8 8 - nod /dev/sda9 644 0 0 b 8 9 - nod /dev/sda10 644 0 0 b 8 10 - nod /dev/sda11 644 0 0 b 8 11 - nod /dev/sda12 644 0 0 b 8 12 - nod /dev/sda13 644 0 0 b 8 13 - nod /dev/sda14 644 0 0 b 8 14 - nod /dev/sda15 644 0 0 b 8 15 - file /init arch/s390/boot/zfcpdump 755 0 0 - file /sbin/e2fsck arch/s390/boot/e2fsck 755 0 0 - dir /proc 755 0 0 - dir /sys 755 0 0 - dir /mnt 755 0 0 - dir /sbin 755 0 0 +The zfcpdump directory is defined in the s390-tools package. - * Issue "make image" to build the zfcpdump image with initramfs. +The user space application of zfcpdump can reside in an intitramfs or an +initrd. It can also be included in a built-in kernel initramfs. The application +reads from /proc/vmcore or zcore/mem and writes the system dump to a SCSI disk. -In a Linux distribution the zfcpdump enabled kernel image must be copied to -/usr/share/zfcpdump/zfcpdump.image, where the s390 zipl tool is looking for the -dump kernel when preparing a SCSI dump disk. - -If you use a ramdisk copy it to "/usr/share/zfcpdump/zfcpdump.rd". +The s390-tools package version 1.24.0 and above builds an external zfcpdump +initramfs with a user space application that writes the dump to a SCSI +partition. For more information on how to use zfcpdump refer to the s390 'Using the Dump Tools book', which is available from -- cgit v1.1 From 3c320f3f5649667874d754e59bdd84dab185fe04 Mon Sep 17 00:00:00 2001 From: Dylan Reid Date: Mon, 19 May 2014 19:18:27 -0700 Subject: ALSA: hda - Add driver for Tegra SoC HDA This adds a driver for the HDA block in Tegra SoCs. The HDA bus is used to communicate with the HDMI codec on Tegra124. Most of the code is re-used from the Intel/PCI HDA driver. It brings over only two of the module params, power_save and probe_mask. Signed-off-by: Dylan Reid Reviewed-by: Stephen Warren Signed-off-by: Takashi Iwai --- .../bindings/sound/nvidia,tegra30-hda.txt | 28 ++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt new file mode 100644 index 0000000..c26f8ca --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt @@ -0,0 +1,28 @@ +NVIDIA Tegra30 HDA controller + +Required properties: +- compatible : "nvidia,tegra30-hda" +- reg : Should contain the HDA registers location and length. +- interrupts : The interrupt from the HDA controller. +- clocks : Must contain an entry for each required entry in clock-names. + See ../clocks/clock-bindings.txt for details. +- clock-names : Must include the following entries: hda, hdacodec_2x, hda2hdmi +- resets : Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. +- reset-names : Must include the following entries: hda, hdacodec_2x, hda2hdmi + +Example: + +hda@0,70030000 { + compatible = "nvidia,tegra124-hda", "nvidia,tegra30-hda"; + reg = <0x0 0x70030000 0x0 0x10000>; + interrupts = ; + clocks = <&tegra_car TEGRA124_CLK_HDA>, + <&tegra_car TEGRA124_CLK_HDA2HDMI>, + <&tegra_car TEGRA124_CLK_HDA2CODEC_2X>; + clock-names = "hda", "hda2hdmi", "hdacodec_2x"; + resets = <&tegra_car 125>, /* hda */ + <&tegra_car 128>; /* hda2hdmi */ + <&tegra_car 111>, /* hda2codec_2x */ + reset-names = "hda", "hda2hdmi", "hdacodec_2x"; +}; -- cgit v1.1 From bbc646fa53c3478e82e9e0fd708220d1193fd062 Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen Date: Thu, 15 May 2014 13:01:59 +0300 Subject: Doc/DT: Add binding doc for lgphilips,lb035q02.txt Add DT bindings documentation for LG.Philips LB035Q02 LCD panel. Signed-off-by: Tomi Valkeinen Cc: devicetree@vger.kernel.org --- .../bindings/video/lgphilips,lb035q02.txt | 33 ++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/lgphilips,lb035q02.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/video/lgphilips,lb035q02.txt b/Documentation/devicetree/bindings/video/lgphilips,lb035q02.txt new file mode 100644 index 0000000..1a1e653 --- /dev/null +++ b/Documentation/devicetree/bindings/video/lgphilips,lb035q02.txt @@ -0,0 +1,33 @@ +LG.Philips LB035Q02 Panel +========================= + +Required properties: +- compatible: "lgphilips,lb035q02" +- enable-gpios: panel enable gpio + +Optional properties: +- label: a symbolic name for the panel + +Required nodes: +- Video port for DPI input + +Example +------- + +lcd-panel: panel@0 { + compatible = "lgphilips,lb035q02"; + reg = <0>; + spi-max-frequency = <100000>; + spi-cpol; + spi-cpha; + + label = "lcd"; + + enable-gpios = <&gpio7 7 0>; + + port { + lcd_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; +}; -- cgit v1.1 From 8a46558da45daa1b5da34c953c3337292365f19f Mon Sep 17 00:00:00 2001 From: Tony Lindgren Date: Fri, 16 May 2014 09:48:40 +0300 Subject: Doc/DT: Add DT binding documentation for SHARP LS037V7DW01 Add DT binding documentation for SHARP LS037V7DW01 panel. Signed-off-by: Tony Lindgren Signed-off-by: Tomi Valkeinen Cc: devicetree@vger.kernel.org --- .../bindings/video/sharp,ls037v7dw01.txt | 43 ++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt b/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt new file mode 100644 index 0000000..0cc8981 --- /dev/null +++ b/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt @@ -0,0 +1,43 @@ +SHARP LS037V7DW01 TFT-LCD panel +=================================== + +Required properties: +- compatible: "sharp,ls037v7dw01" + +Optional properties: +- label: a symbolic name for the panel +- enable-gpios: a GPIO spec for the optional enable pin. + This pin is the INI pin as specified in the LS037V7DW01.pdf file. +- reset-gpios: a GPIO spec for the optional reset pin. + This pin is the RESB pin as specified in the LS037V7DW01.pdf file. +- mode-gpios: a GPIO + ordered MO, LR, and UD as specified in the LS037V7DW01.pdf file. + +Required nodes: +- Video port for DPI input + +This panel can have zero to five GPIOs to configure to change configuration +between QVGA and VGA mode and the scan direction. As these pins can be also +configured with external pulls, all the GPIOs are considered optional with holes +in the array. + +Example +------- + +Example when connected to a omap2+ based device: + +lcd0: display { + compatible = "sharp,ls037v7dw01"; + power-supply = <&lcd_3v3>; + enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */ + reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */ + mode-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */ + &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */ + &gpio1 3 GPIO_ACTIVE_HIGH>; /* gpio3, lcd UD */ + + port { + lcd_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; +}; -- cgit v1.1 From c594b057413d0ec6b0ef3881ae7c78b3bb1240f8 Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen Date: Fri, 16 May 2014 12:47:32 +0300 Subject: Doc/DT: Add DT binding documentation for TPO td043mtea1 panel Add DT binding documentation for TPO td043mtea1 panel Signed-off-by: Tomi Valkeinen Cc: devicetree@vger.kernel.org Cc: Grazvydas Ignotas --- .../devicetree/bindings/video/tpo,td043mtea1.txt | 33 ++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/tpo,td043mtea1.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/video/tpo,td043mtea1.txt b/Documentation/devicetree/bindings/video/tpo,td043mtea1.txt new file mode 100644 index 0000000..ec6d629 --- /dev/null +++ b/Documentation/devicetree/bindings/video/tpo,td043mtea1.txt @@ -0,0 +1,33 @@ +TPO TD043MTEA1 Panel +==================== + +Required properties: +- compatible: "tpo,td043mtea1" +- reset-gpios: panel reset gpio + +Optional properties: +- label: a symbolic name for the panel + +Required nodes: +- Video port for DPI input + +Example +------- + +lcd-panel: panel@0 { + compatible = "tpo,td043mtea1"; + reg = <0>; + spi-max-frequency = <100000>; + spi-cpol; + spi-cpha; + + label = "lcd"; + + reset-gpios = <&gpio7 7 0>; + + port { + lcd_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; +}; -- cgit v1.1 From 64b14519e5913e8d4de9f2e5d9ef59abba3ed83d Mon Sep 17 00:00:00 2001 From: Jens Axboe Date: Tue, 20 May 2014 08:17:35 -0600 Subject: htmldocs: fix bio.c location Commit f9c78b2be2ca moved bio.c from fs/ to block/, but didn't update the docbook location. Fix that up. Signed-off-by: Jens Axboe --- Documentation/DocBook/filesystems.tmpl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/filesystems.tmpl b/Documentation/DocBook/filesystems.tmpl index 4f67683..bcdfdb9 100644 --- a/Documentation/DocBook/filesystems.tmpl +++ b/Documentation/DocBook/filesystems.tmpl @@ -62,7 +62,7 @@ !Efs/mpage.c !Efs/namei.c !Efs/buffer.c -!Efs/bio.c +!Eblock/bio.c !Efs/seq_file.c !Efs/filesystems.c !Efs/fs-writeback.c -- cgit v1.1 From 80c578930ce77ba8bcfb226a184b482020bdda7b Mon Sep 17 00:00:00 2001 From: Mike Snitzer Date: Tue, 20 May 2014 13:38:33 -0400 Subject: dm thin: add 'no_space_timeout' dm-thin-pool module param Commit 85ad643b ("dm thin: add timeout to stop out-of-data-space mode holding IO forever") introduced a fixed 60 second timeout. Users may want to either disable or modify this timeout. Allow the out-of-data-space timeout to be configured using the 'no_space_timeout' dm-thin-pool module param. Setting it to 0 will disable the timeout, resulting in IO being queued until more data space is added to the thin-pool. Signed-off-by: Mike Snitzer Cc: stable@vger.kernel.org # 3.14+ --- Documentation/device-mapper/thin-provisioning.txt | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/device-mapper/thin-provisioning.txt b/Documentation/device-mapper/thin-provisioning.txt index 05a27e9..2f51735 100644 --- a/Documentation/device-mapper/thin-provisioning.txt +++ b/Documentation/device-mapper/thin-provisioning.txt @@ -309,7 +309,10 @@ ii) Status error_if_no_space|queue_if_no_space If the pool runs out of data or metadata space, the pool will either queue or error the IO destined to the data device. The - default is to queue the IO until more space is added. + default is to queue the IO until more space is added or the + 'no_space_timeout' expires. The 'no_space_timeout' dm-thin-pool + module parameter can be used to change this timeout -- it + defaults to 60 seconds but may be disabled using a value of 0. iii) Messages -- cgit v1.1 From 7d6d478f38fb1bdef30ae1a4c9d5aefb7cb2bb9b Mon Sep 17 00:00:00 2001 From: Andrew Lunn Date: Sat, 3 May 2014 20:30:11 +0200 Subject: ASoC: alc5623: Add device tree binding Let the ALC5623 codec be instantiated from DT. Add a simple binding for the additional control register and the jack detect register. Also, add a prompt to the Kconfig entry for this CODEC, so that it can be selected. Since kirkwood-t5325.c will no longer be used, we need to be able to enable the CODEC in the mvebu_v5_defconfig etc. Signed-off-by: Andrew Lunn Acked-by: Jason Cooper Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/alc5623.txt | 25 ++++++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/alc5623.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/alc5623.txt b/Documentation/devicetree/bindings/sound/alc5623.txt new file mode 100644 index 0000000..26c86c9 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/alc5623.txt @@ -0,0 +1,25 @@ +ALC5621/ALC5622/ALC5623 audio Codec + +Required properties: + + - compatible: "realtek,alc5623" + - reg: the I2C address of the device. + +Optional properties: + + - add-ctrl: Default register value for Reg-40h, Additional Control + Register. If absent or has the value of 0, the + register is untouched. + + - jack-det-ctrl: Default register value for Reg-5Ah, Jack Detect + Control Register. If absent or has value 0, the + register is untouched. + +Example: + + alc5621: alc5621@1a { + compatible = "alc5621"; + reg = <0x1a>; + add-ctrl = <0x3700>; + jack-det-ctrl = <0x4810>; + }; -- cgit v1.1 From 77f2ea2f8d0833f9e976368481fb9a0775acf9e7 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Wed, 30 Apr 2014 11:20:53 -0600 Subject: DMA-API: Clarify physical/bus address distinction The DMA-API documentation sometimes refers to "physical addresses" when it really means "bus addresses." Sometimes these are identical, but they may be different if the bridge leading to the bus performs address translation. Update the documentation to use "bus address" when appropriate. Also, consistently capitalize "DMA", use parens with function names, use dev_printk() in examples, and reword a few sections for clarity. No functional change; documentation changes only. Signed-off-by: Bjorn Helgaas Acked-by: Greg Kroah-Hartman Acked-by: Arnd Bergmann Acked-by: James Bottomley Acked-by: Randy Dunlap --- Documentation/DMA-API-HOWTO.txt | 192 +++++++++++++++++++++++++--------------- Documentation/DMA-API.txt | 139 +++++++++++++++-------------- Documentation/DMA-ISA-LPC.txt | 4 +- 3 files changed, 197 insertions(+), 138 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt index 5e98303..fd3727b 100644 --- a/Documentation/DMA-API-HOWTO.txt +++ b/Documentation/DMA-API-HOWTO.txt @@ -9,16 +9,76 @@ This is a guide to device driver writers on how to use the DMA API with example pseudo-code. For a concise description of the API, see DMA-API.txt. -Most of the 64bit platforms have special hardware that translates bus -addresses (DMA addresses) into physical addresses. This is similar to -how page tables and/or a TLB translates virtual addresses to physical -addresses on a CPU. This is needed so that e.g. PCI devices can -access with a Single Address Cycle (32bit DMA address) any page in the -64bit physical address space. Previously in Linux those 64bit -platforms had to set artificial limits on the maximum RAM size in the -system, so that the virt_to_bus() static scheme works (the DMA address -translation tables were simply filled on bootup to map each bus -address to the physical page __pa(bus_to_virt())). + CPU and DMA addresses + +There are several kinds of addresses involved in the DMA API, and it's +important to understand the differences. + +The kernel normally uses virtual addresses. Any address returned by +kmalloc(), vmalloc(), and similar interfaces is a virtual address and can +be stored in a "void *". + +The virtual memory system (TLB, page tables, etc.) translates virtual +addresses to CPU physical addresses, which are stored as "phys_addr_t" or +"resource_size_t". The kernel manages device resources like registers as +physical addresses. These are the addresses in /proc/iomem. The physical +address is not directly useful to a driver; it must use ioremap() to map +the space and produce a virtual address. + +I/O devices use a third kind of address: a "bus address" or "DMA address". +If a device has registers at an MMIO address, or if it performs DMA to read +or write system memory, the addresses used by the device are bus addresses. +In some systems, bus addresses are identical to CPU physical addresses, but +in general they are not. IOMMUs and host bridges can produce arbitrary +mappings between physical and bus addresses. + +Here's a picture and some examples: + + CPU CPU Bus + Virtual Physical Address + Address Address Space + Space Space + + +-------+ +------+ +------+ + | | |MMIO | Offset | | + | | Virtual |Space | applied | | + C +-------+ --------> B +------+ ----------> +------+ A + | | mapping | | by host | | + +-----+ | | | | bridge | | +--------+ + | | | | +------+ | | | | + | CPU | | | | RAM | | | | Device | + | | | | | | | | | | + +-----+ +-------+ +------+ +------+ +--------+ + | | Virtual |Buffer| Mapping | | + X +-------+ --------> Y +------+ <---------- +------+ Z + | | mapping | RAM | by IOMMU + | | | | + | | | | + +-------+ +------+ + +During the enumeration process, the kernel learns about I/O devices and +their MMIO space and the host bridges that connect them to the system. For +example, if a PCI device has a BAR, the kernel reads the bus address (A) +from the BAR and converts it to a CPU physical address (B). The address B +is stored in a struct resource and usually exposed via /proc/iomem. When a +driver claims a device, it typically uses ioremap() to map physical address +B at a virtual address (C). It can then use, e.g., ioread32(C), to access +the device registers at bus address A. + +If the device supports DMA, the driver sets up a buffer using kmalloc() or +a similar interface, which returns a virtual address (X). The virtual +memory system maps X to a physical address (Y) in system RAM. The driver +can use virtual address X to access the buffer, but the device itself +cannot because DMA doesn't go through the CPU virtual memory system. + +In some simple systems, the device can do DMA directly to physical address +Y. But in many others, there is IOMMU hardware that translates bus +addresses to physical addresses, e.g., it translates Z to Y. This is part +of the reason for the DMA API: the driver can give a virtual address X to +an interface like dma_map_single(), which sets up any required IOMMU +mapping and returns the bus address Z. The driver then tells the device to +do DMA to Z, and the IOMMU maps it to the buffer at address Y in system +RAM. So that Linux can use the dynamic DMA mapping, it needs some help from the drivers, namely it has to take into account that DMA addresses should be @@ -29,17 +89,17 @@ The following API will work of course even on platforms where no such hardware exists. Note that the DMA API works with any bus independent of the underlying -microprocessor architecture. You should use the DMA API rather than -the bus specific DMA API (e.g. pci_dma_*). +microprocessor architecture. You should use the DMA API rather than the +bus-specific DMA API, i.e., use the dma_map_*() interfaces rather than the +pci_map_*() interfaces. First of all, you should make sure #include -is in your driver. This file will obtain for you the definition of the -dma_addr_t (which can hold any valid DMA address for the platform) -type which should be used everywhere you hold a DMA (bus) address -returned from the DMA mapping functions. +is in your driver, which provides the definition of dma_addr_t. This type +can hold any valid DMA or bus address for the platform and should be used +everywhere you hold a DMA address returned from the DMA mapping functions. What memory is DMA'able? @@ -123,9 +183,9 @@ Here, dev is a pointer to the device struct of your device, and mask is a bit mask describing which bits of an address your device supports. It returns zero if your card can perform DMA properly on the machine given the address mask you provided. In general, the -device struct of your device is embedded in the bus specific device -struct of your device. For example, a pointer to the device struct of -your PCI device is pdev->dev (pdev is a pointer to the PCI device +device struct of your device is embedded in the bus-specific device +struct of your device. For example, &pdev->dev is a pointer to the +device struct of a PCI device (pdev is a pointer to the PCI device struct of your device). If it returns non-zero, your device cannot perform DMA properly on @@ -147,8 +207,7 @@ exactly why. The standard 32-bit addressing device would do something like this: if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) { - printk(KERN_WARNING - "mydev: No suitable DMA available.\n"); + dev_warn(dev, "mydev: No suitable DMA available\n"); goto ignore_this_device; } @@ -170,8 +229,7 @@ all 64-bits when accessing streaming DMA: } else if (!dma_set_mask(dev, DMA_BIT_MASK(32))) { using_dac = 0; } else { - printk(KERN_WARNING - "mydev: No suitable DMA available.\n"); + dev_warn(dev, "mydev: No suitable DMA available\n"); goto ignore_this_device; } @@ -187,8 +245,7 @@ the case would look like this: using_dac = 0; consistent_using_dac = 0; } else { - printk(KERN_WARNING - "mydev: No suitable DMA available.\n"); + dev_warn(dev, "mydev: No suitable DMA available\n"); goto ignore_this_device; } @@ -201,8 +258,7 @@ Finally, if your device can only drive the low 24-bits of address you might do something like: if (dma_set_mask(dev, DMA_BIT_MASK(24))) { - printk(KERN_WARNING - "mydev: 24-bit DMA addressing not available.\n"); + dev_warn(dev, "mydev: 24-bit DMA addressing not available\n"); goto ignore_this_device; } @@ -232,14 +288,14 @@ Here is pseudo-code showing how this might be done: card->playback_enabled = 1; } else { card->playback_enabled = 0; - printk(KERN_WARNING "%s: Playback disabled due to DMA limitations.\n", + dev_warn(dev, "%s: Playback disabled due to DMA limitations\n", card->name); } if (!dma_set_mask(dev, RECORD_ADDRESS_BITS)) { card->record_enabled = 1; } else { card->record_enabled = 0; - printk(KERN_WARNING "%s: Record disabled due to DMA limitations.\n", + dev_warn(dev, "%s: Record disabled due to DMA limitations\n", card->name); } @@ -331,7 +387,7 @@ context with the GFP_ATOMIC flag. Size is the length of the region you want to allocate, in bytes. This routine will allocate RAM for that region, so it acts similarly to -__get_free_pages (but takes size instead of a page order). If your +__get_free_pages() (but takes size instead of a page order). If your driver needs regions sized smaller than a page, you may prefer using the dma_pool interface, described below. @@ -343,11 +399,11 @@ the consistent DMA mask has been explicitly changed via dma_set_coherent_mask(). This is true of the dma_pool interface as well. -dma_alloc_coherent returns two values: the virtual address which you +dma_alloc_coherent() returns two values: the virtual address which you can use to access it from the CPU and dma_handle which you pass to the card. -The cpu return address and the DMA bus master address are both +The CPU virtual address and the DMA bus address are both guaranteed to be aligned to the smallest PAGE_SIZE order which is greater than or equal to the requested size. This invariant exists (for example) to guarantee that if you allocate a chunk @@ -359,13 +415,13 @@ To unmap and free such a DMA region, you call: dma_free_coherent(dev, size, cpu_addr, dma_handle); where dev, size are the same as in the above call and cpu_addr and -dma_handle are the values dma_alloc_coherent returned to you. +dma_handle are the values dma_alloc_coherent() returned to you. This function may not be called in interrupt context. If your driver needs lots of smaller memory regions, you can write -custom code to subdivide pages returned by dma_alloc_coherent, +custom code to subdivide pages returned by dma_alloc_coherent(), or you can use the dma_pool API to do that. A dma_pool is like -a kmem_cache, but it uses dma_alloc_coherent not __get_free_pages. +a kmem_cache, but it uses dma_alloc_coherent(), not __get_free_pages(). Also, it understands common hardware constraints for alignment, like queue heads needing to be aligned on N byte boundaries. @@ -381,29 +437,29 @@ type of data is "align" (which is expressed in bytes, and must be a power of two). If your device has no boundary crossing restrictions, pass 0 for alloc; passing 4096 says memory allocated from this pool must not cross 4KByte boundaries (but at that time it may be better to -go for dma_alloc_coherent directly instead). +use dma_alloc_coherent() directly instead). -Allocate memory from a dma pool like this: +Allocate memory from a DMA pool like this: cpu_addr = dma_pool_alloc(pool, flags, &dma_handle); flags are SLAB_KERNEL if blocking is permitted (not in_interrupt nor -holding SMP locks), SLAB_ATOMIC otherwise. Like dma_alloc_coherent, +holding SMP locks), SLAB_ATOMIC otherwise. Like dma_alloc_coherent(), this returns two values, cpu_addr and dma_handle. Free memory that was allocated from a dma_pool like this: dma_pool_free(pool, cpu_addr, dma_handle); -where pool is what you passed to dma_pool_alloc, and cpu_addr and -dma_handle are the values dma_pool_alloc returned. This function +where pool is what you passed to dma_pool_alloc(), and cpu_addr and +dma_handle are the values dma_pool_alloc() returned. This function may be called in interrupt context. Destroy a dma_pool by calling: dma_pool_destroy(pool); -Make sure you've called dma_pool_free for all memory allocated +Make sure you've called dma_pool_free() for all memory allocated from a pool before you destroy the pool. This function may not be called in interrupt context. @@ -418,7 +474,7 @@ one of the following values: DMA_FROM_DEVICE DMA_NONE -One should provide the exact DMA direction if you know it. +You should provide the exact DMA direction if you know it. DMA_TO_DEVICE means "from main memory to the device" DMA_FROM_DEVICE means "from the device to main memory" @@ -489,14 +545,14 @@ and to unmap it: dma_unmap_single(dev, dma_handle, size, direction); You should call dma_mapping_error() as dma_map_single() could fail and return -error. Not all dma implementations support dma_mapping_error() interface. +error. Not all DMA implementations support the dma_mapping_error() interface. However, it is a good practice to call dma_mapping_error() interface, which will invoke the generic mapping error check interface. Doing so will ensure -that the mapping code will work correctly on all dma implementations without +that the mapping code will work correctly on all DMA implementations without any dependency on the specifics of the underlying implementation. Using the returned address without checking for errors could result in failures ranging from panics to silent data corruption. A couple of examples of incorrect ways -to check for errors that make assumptions about the underlying dma +to check for errors that make assumptions about the underlying DMA implementation are as follows and these are applicable to dma_map_page() as well. @@ -516,12 +572,12 @@ Incorrect example 2: goto map_error; } -You should call dma_unmap_single when the DMA activity is finished, e.g. +You should call dma_unmap_single() when the DMA activity is finished, e.g., from the interrupt which told you that the DMA transfer is done. -Using cpu pointers like this for single mappings has a disadvantage, +Using cpu pointers like this for single mappings has a disadvantage: you cannot reference HIGHMEM memory in this way. Thus, there is a -map/unmap interface pair akin to dma_{map,unmap}_single. These +map/unmap interface pair akin to dma_{map,unmap}_single(). These interfaces deal with page/offset pairs instead of cpu pointers. Specifically: @@ -550,7 +606,7 @@ Here, "offset" means byte offset within the given page. You should call dma_mapping_error() as dma_map_page() could fail and return error as outlined under the dma_map_single() discussion. -You should call dma_unmap_page when the DMA activity is finished, e.g. +You should call dma_unmap_page() when the DMA activity is finished, e.g., from the interrupt which told you that the DMA transfer is done. With scatterlists, you map a region gathered from several regions by: @@ -588,18 +644,16 @@ PLEASE NOTE: The 'nents' argument to the dma_unmap_sg call must be it should _NOT_ be the 'count' value _returned_ from the dma_map_sg call. -Every dma_map_{single,sg} call should have its dma_unmap_{single,sg} -counterpart, because the bus address space is a shared resource (although -in some ports the mapping is per each BUS so less devices contend for the -same bus address space) and you could render the machine unusable by eating -all bus addresses. +Every dma_map_{single,sg}() call should have its dma_unmap_{single,sg}() +counterpart, because the bus address space is a shared resource and +you could render the machine unusable by consuming all bus addresses. If you need to use the same streaming DMA region multiple times and touch the data in between the DMA transfers, the buffer needs to be synced -properly in order for the cpu and device to see the most uptodate and +properly in order for the cpu and device to see the most up-to-date and correct copy of the DMA buffer. -So, firstly, just map it with dma_map_{single,sg}, and after each DMA +So, firstly, just map it with dma_map_{single,sg}(), and after each DMA transfer call either: dma_sync_single_for_cpu(dev, dma_handle, size, direction); @@ -623,9 +677,9 @@ or: as appropriate. After the last DMA transfer call one of the DMA unmap routines -dma_unmap_{single,sg}. If you don't touch the data from the first dma_map_* -call till dma_unmap_*, then you don't have to call the dma_sync_* -routines at all. +dma_unmap_{single,sg}(). If you don't touch the data from the first +dma_map_*() call till dma_unmap_*(), then you don't have to call the +dma_sync_*() routines at all. Here is pseudo code which shows a situation in which you would need to use the dma_sync_*() interfaces. @@ -690,12 +744,12 @@ to use the dma_sync_*() interfaces. } } -Drivers converted fully to this interface should not use virt_to_bus any -longer, nor should they use bus_to_virt. Some drivers have to be changed a -little bit, because there is no longer an equivalent to bus_to_virt in the +Drivers converted fully to this interface should not use virt_to_bus() any +longer, nor should they use bus_to_virt(). Some drivers have to be changed a +little bit, because there is no longer an equivalent to bus_to_virt() in the dynamic DMA mapping scheme - you have to always store the DMA addresses -returned by the dma_alloc_coherent, dma_pool_alloc, and dma_map_single -calls (dma_map_sg stores them in the scatterlist itself if the platform +returned by the dma_alloc_coherent(), dma_pool_alloc(), and dma_map_single() +calls (dma_map_sg() stores them in the scatterlist itself if the platform supports dynamic DMA mapping in hardware) in your driver structures and/or in the card registers. @@ -709,9 +763,9 @@ as it is impossible to correctly support them. DMA address space is limited on some architectures and an allocation failure can be determined by: -- checking if dma_alloc_coherent returns NULL or dma_map_sg returns 0 +- checking if dma_alloc_coherent() returns NULL or dma_map_sg returns 0 -- checking the returned dma_addr_t of dma_map_single and dma_map_page +- checking the dma_addr_t returned from dma_map_single() and dma_map_page() by using dma_mapping_error(): dma_addr_t dma_handle; @@ -794,7 +848,7 @@ Example 2: (if buffers are allocated in a loop, unmap all mapped buffers when dma_unmap_single(array[i].dma_addr); } -Networking drivers must call dev_kfree_skb to free the socket buffer +Networking drivers must call dev_kfree_skb() to free the socket buffer and return NETDEV_TX_OK if the DMA mapping fails on the transmit hook (ndo_start_xmit). This means that the socket buffer is just dropped in the failure case. @@ -831,7 +885,7 @@ transform some example code. DEFINE_DMA_UNMAP_LEN(len); }; -2) Use dma_unmap_{addr,len}_set to set these values. +2) Use dma_unmap_{addr,len}_set() to set these values. Example, before: ringp->mapping = FOO; @@ -842,7 +896,7 @@ transform some example code. dma_unmap_addr_set(ringp, mapping, FOO); dma_unmap_len_set(ringp, len, BAR); -3) Use dma_unmap_{addr,len} to access these values. +3) Use dma_unmap_{addr,len}() to access these values. Example, before: dma_unmap_single(dev, ringp->mapping, ringp->len, diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index e865279..1147eba 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt @@ -4,22 +4,26 @@ James E.J. Bottomley This document describes the DMA API. For a more gentle introduction -of the API (and actual examples) see -Documentation/DMA-API-HOWTO.txt. +of the API (and actual examples), see Documentation/DMA-API-HOWTO.txt. -This API is split into two pieces. Part I describes the API. Part II -describes the extensions to the API for supporting non-consistent -memory machines. Unless you know that your driver absolutely has to -support non-consistent platforms (this is usually only legacy -platforms) you should only use the API described in part I. +This API is split into two pieces. Part I describes the basic API. +Part II describes extensions for supporting non-consistent memory +machines. Unless you know that your driver absolutely has to support +non-consistent platforms (this is usually only legacy platforms) you +should only use the API described in part I. Part I - dma_ API ------------------------------------- -To get the dma_ API, you must #include +To get the dma_ API, you must #include . This +provides dma_addr_t and the interfaces described below. +A dma_addr_t can hold any valid DMA or bus address for the platform. It +can be given to a device to use as a DMA source or target. A cpu cannot +reference a dma_addr_t directly because there may be translation between +its physical address space and the bus address space. -Part Ia - Using large dma-coherent buffers +Part Ia - Using large DMA-coherent buffers ------------------------------------------ void * @@ -33,20 +37,21 @@ to make sure to flush the processor's write buffers before telling devices to read that memory.) This routine allocates a region of bytes of consistent memory. -It also returns a which may be cast to an unsigned -integer the same width as the bus and used as the physical address -base of the region. -Returns: a pointer to the allocated region (in the processor's virtual +It returns a pointer to the allocated region (in the processor's virtual address space) or NULL if the allocation failed. +It also returns a which may be cast to an unsigned integer the +same width as the bus and given to the device as the bus address base of +the region. + Note: consistent memory can be expensive on some platforms, and the minimum allocation length may be as big as a page, so you should consolidate your requests for consistent memory as much as possible. The simplest way to do that is to use the dma_pool calls (see below). -The flag parameter (dma_alloc_coherent only) allows the caller to -specify the GFP_ flags (see kmalloc) for the allocation (the +The flag parameter (dma_alloc_coherent() only) allows the caller to +specify the GFP_ flags (see kmalloc()) for the allocation (the implementation may choose to ignore flags that affect the location of the returned memory, like GFP_DMA). @@ -61,24 +66,24 @@ void dma_free_coherent(struct device *dev, size_t size, void *cpu_addr, dma_addr_t dma_handle) -Free the region of consistent memory you previously allocated. dev, -size and dma_handle must all be the same as those passed into the -consistent allocate. cpu_addr must be the virtual address returned by -the consistent allocate. +Free a region of consistent memory you previously allocated. dev, +size and dma_handle must all be the same as those passed into +dma_alloc_coherent(). cpu_addr must be the virtual address returned by +the dma_alloc_coherent(). Note that unlike their sibling allocation calls, these routines may only be called with IRQs enabled. -Part Ib - Using small dma-coherent buffers +Part Ib - Using small DMA-coherent buffers ------------------------------------------ To get this part of the dma_ API, you must #include -Many drivers need lots of small dma-coherent memory regions for DMA +Many drivers need lots of small DMA-coherent memory regions for DMA descriptors or I/O buffers. Rather than allocating in units of a page or more using dma_alloc_coherent(), you can use DMA pools. These work -much like a struct kmem_cache, except that they use the dma-coherent allocator, +much like a struct kmem_cache, except that they use the DMA-coherent allocator, not __get_free_pages(). Also, they understand common hardware constraints for alignment, like queue heads needing to be aligned on N-byte boundaries. @@ -87,7 +92,7 @@ for alignment, like queue heads needing to be aligned on N-byte boundaries. dma_pool_create(const char *name, struct device *dev, size_t size, size_t align, size_t alloc); -The pool create() routines initialize a pool of dma-coherent buffers +dma_pool_create() initializes a pool of DMA-coherent buffers for use with a given device. It must be called in a context which can sleep. @@ -102,25 +107,26 @@ from this pool must not cross 4KByte boundaries. void *dma_pool_alloc(struct dma_pool *pool, gfp_t gfp_flags, dma_addr_t *dma_handle); -This allocates memory from the pool; the returned memory will meet the size -and alignment requirements specified at creation time. Pass GFP_ATOMIC to -prevent blocking, or if it's permitted (not in_interrupt, not holding SMP locks), -pass GFP_KERNEL to allow blocking. Like dma_alloc_coherent(), this returns -two values: an address usable by the cpu, and the dma address usable by the -pool's device. +This allocates memory from the pool; the returned memory will meet the +size and alignment requirements specified at creation time. Pass +GFP_ATOMIC to prevent blocking, or if it's permitted (not +in_interrupt, not holding SMP locks), pass GFP_KERNEL to allow +blocking. Like dma_alloc_coherent(), this returns two values: an +address usable by the cpu, and the DMA address usable by the pool's +device. void dma_pool_free(struct dma_pool *pool, void *vaddr, dma_addr_t addr); This puts memory back into the pool. The pool is what was passed to -the pool allocation routine; the cpu (vaddr) and dma addresses are what +dma_pool_alloc(); the cpu (vaddr) and DMA addresses are what were returned when that routine allocated the memory being freed. void dma_pool_destroy(struct dma_pool *pool); -The pool destroy() routines free the resources of the pool. They must be +dma_pool_destroy() frees the resources of the pool. It must be called in a context which can sleep. Make sure you've freed all allocated memory back to the pool before you destroy it. @@ -187,9 +193,9 @@ dma_map_single(struct device *dev, void *cpu_addr, size_t size, enum dma_data_direction direction) Maps a piece of processor virtual memory so it can be accessed by the -device and returns the physical handle of the memory. +device and returns the bus address of the memory. -The direction for both api's may be converted freely by casting. +The direction for both APIs may be converted freely by casting. However the dma_ API uses a strongly typed enumerator for its direction: @@ -198,31 +204,30 @@ DMA_TO_DEVICE data is going from the memory to the device DMA_FROM_DEVICE data is coming from the device to the memory DMA_BIDIRECTIONAL direction isn't known -Notes: Not all memory regions in a machine can be mapped by this -API. Further, regions that appear to be physically contiguous in -kernel virtual space may not be contiguous as physical memory. Since -this API does not provide any scatter/gather capability, it will fail -if the user tries to map a non-physically contiguous piece of memory. -For this reason, it is recommended that memory mapped by this API be -obtained only from sources which guarantee it to be physically contiguous -(like kmalloc). - -Further, the physical address of the memory must be within the -dma_mask of the device (the dma_mask represents a bit mask of the -addressable region for the device. I.e., if the physical address of -the memory anded with the dma_mask is still equal to the physical -address, then the device can perform DMA to the memory). In order to +Notes: Not all memory regions in a machine can be mapped by this API. +Further, contiguous kernel virtual space may not be contiguous as +physical memory. Since this API does not provide any scatter/gather +capability, it will fail if the user tries to map a non-physically +contiguous piece of memory. For this reason, memory to be mapped by +this API should be obtained from sources which guarantee it to be +physically contiguous (like kmalloc). + +Further, the bus address of the memory must be within the +dma_mask of the device (the dma_mask is a bit mask of the +addressable region for the device, i.e., if the bus address of +the memory ANDed with the dma_mask is still equal to the bus +address, then the device can perform DMA to the memory). To ensure that the memory allocated by kmalloc is within the dma_mask, the driver may specify various platform-dependent flags to restrict -the physical memory range of the allocation (e.g. on x86, GFP_DMA -guarantees to be within the first 16Mb of available physical memory, +the bus address range of the allocation (e.g., on x86, GFP_DMA +guarantees to be within the first 16MB of available bus addresses, as required by ISA devices). Note also that the above constraints on physical contiguity and dma_mask may not apply if the platform has an IOMMU (a device which -supplies a physical to virtual mapping between the I/O memory bus and -the device). However, to be portable, device driver writers may *not* -assume that such an IOMMU exists. +maps an I/O bus address to a physical memory address). However, to be +portable, device driver writers may *not* assume that such an IOMMU +exists. Warnings: Memory coherency operates at a granularity called the cache line width. In order for memory mapped by this API to operate @@ -281,9 +286,9 @@ cache width is. int dma_mapping_error(struct device *dev, dma_addr_t dma_addr) -In some circumstances dma_map_single and dma_map_page will fail to create +In some circumstances dma_map_single() and dma_map_page() will fail to create a mapping. A driver can check for these errors by testing the returned -dma address with dma_mapping_error(). A non-zero return value means the mapping +DMA address with dma_mapping_error(). A non-zero return value means the mapping could not be created and the driver should take appropriate action (e.g. reduce current DMA mapping usage or delay and try again later). @@ -291,7 +296,7 @@ reduce current DMA mapping usage or delay and try again later). dma_map_sg(struct device *dev, struct scatterlist *sg, int nents, enum dma_data_direction direction) -Returns: the number of physical segments mapped (this may be shorter +Returns: the number of bus address segments mapped (this may be shorter than passed in if some elements of the scatter/gather list are physically or virtually adjacent and an IOMMU maps them with a single entry). @@ -299,7 +304,7 @@ entry). Please note that the sg cannot be mapped again if it has been mapped once. The mapping process is allowed to destroy information in the sg. -As with the other mapping interfaces, dma_map_sg can fail. When it +As with the other mapping interfaces, dma_map_sg() can fail. When it does, 0 is returned and a driver must take appropriate action. It is critical that the driver do something, in the case of a block driver aborting the request or even oopsing is better than doing nothing and @@ -335,7 +340,7 @@ must be the same as those and passed in to the scatter/gather mapping API. Note: must be the number you passed in, *not* the number of -physical entries returned. +bus address entries returned. void dma_sync_single_for_cpu(struct device *dev, dma_addr_t dma_handle, size_t size, @@ -391,10 +396,10 @@ The four functions above are just like the counterpart functions without the _attrs suffixes, except that they pass an optional struct dma_attrs*. -struct dma_attrs encapsulates a set of "dma attributes". For the +struct dma_attrs encapsulates a set of "DMA attributes". For the definition of struct dma_attrs see linux/dma-attrs.h. -The interpretation of dma attributes is architecture-specific, and +The interpretation of DMA attributes is architecture-specific, and each attribute should be documented in Documentation/DMA-attributes.txt. If struct dma_attrs* is NULL, the semantics of each of these @@ -458,7 +463,7 @@ Note: where the platform can return consistent memory, it will guarantee that the sync points become nops. Warning: Handling non-consistent memory is a real pain. You should -only ever use this API if you positively know your driver will be +only use this API if you positively know your driver will be required to work on one of the rare (usually non-PCI) architectures that simply cannot make consistent memory. @@ -496,26 +501,26 @@ dma_declare_coherent_memory(struct device *dev, dma_addr_t bus_addr, dma_addr_t device_addr, size_t size, int flags) -Declare region of memory to be handed out by dma_alloc_coherent when +Declare region of memory to be handed out by dma_alloc_coherent() when it's asked for coherent memory for this device. bus_addr is the physical address to which the memory is currently assigned in the bus responding region (this will be used by the platform to perform the mapping). -device_addr is the physical address the device needs to be programmed +device_addr is the bus address the device needs to be programmed with actually to address this memory (this will be handed out as the dma_addr_t in dma_alloc_coherent()). size is the size of the area (must be multiples of PAGE_SIZE). -flags can be or'd together and are: +flags can be ORed together and are: DMA_MEMORY_MAP - request that the memory returned from dma_alloc_coherent() be directly writable. DMA_MEMORY_IO - request that the memory returned from -dma_alloc_coherent() be addressable using read/write/memcpy_toio etc. +dma_alloc_coherent() be addressable using read()/write()/memcpy_toio() etc. One or both of these flags must be present. @@ -572,7 +577,7 @@ region is occupied. Part III - Debug drivers use of the DMA-API ------------------------------------------- -The DMA-API as described above as some constraints. DMA addresses must be +The DMA-API as described above has some constraints. DMA addresses must be released with the corresponding function with the same size for example. With the advent of hardware IOMMUs it becomes more and more important that drivers do not violate those constraints. In the worst case such a violation can @@ -690,11 +695,11 @@ architectural default. void debug_dmap_mapping_error(struct device *dev, dma_addr_t dma_addr); dma-debug interface debug_dma_mapping_error() to debug drivers that fail -to check dma mapping errors on addresses returned by dma_map_single() and +to check DMA mapping errors on addresses returned by dma_map_single() and dma_map_page() interfaces. This interface clears a flag set by debug_dma_map_page() to indicate that dma_mapping_error() has been called by the driver. When driver does unmap, debug_dma_unmap() checks the flag and if this flag is still set, prints warning message that includes call trace that leads up to the unmap. This interface can be called from dma_mapping_error() -routines to enable dma mapping error check debugging. +routines to enable DMA mapping error check debugging. diff --git a/Documentation/DMA-ISA-LPC.txt b/Documentation/DMA-ISA-LPC.txt index e767805..b1a1983 100644 --- a/Documentation/DMA-ISA-LPC.txt +++ b/Documentation/DMA-ISA-LPC.txt @@ -16,7 +16,7 @@ To do ISA style DMA you need to include two headers: #include The first is the generic DMA API used to convert virtual addresses to -physical addresses (see Documentation/DMA-API.txt for details). +bus addresses (see Documentation/DMA-API.txt for details). The second contains the routines specific to ISA DMA transfers. Since this is not present on all platforms make sure you construct your @@ -50,7 +50,7 @@ early as possible and not release it until the driver is unloaded.) Part III - Address translation ------------------------------ -To translate the virtual address to a physical use the normal DMA +To translate the virtual address to a bus address, use the normal DMA API. Do _not_ use isa_virt_to_phys() even though it does the same thing. The reason for this is that the function isa_virt_to_phys() will require a Kconfig dependency to ISA, not just ISA_DMA_API which -- cgit v1.1 From 88a984ba0795f14a3847edbd7fabe652289ea89b Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Tue, 20 May 2014 16:54:22 -0600 Subject: DMA-API: Change dma_declare_coherent_memory() CPU address to phys_addr_t dma_declare_coherent_memory() takes two addresses for a region of memory: a "bus_addr" and a "device_addr". I think the intent is that "bus_addr" is the physical address a *CPU* would use to access the region, and "device_addr" is the bus address the *device* would use to address the region. Rename "bus_addr" to "phys_addr" and change its type to phys_addr_t. Most callers already supply a phys_addr_t for this argument. The others supply a 32-bit integer (a constant, unsigned int, or __u32) and need no change. Use "unsigned long", not phys_addr_t, to hold PFNs. No functional change (this could theoretically fix a truncation in a config with 32-bit dma_addr_t and 64-bit phys_addr_t, but I don't think there are any such cases involving this code). Signed-off-by: Bjorn Helgaas Acked-by: Arnd Bergmann Acked-by: Greg Kroah-Hartman Acked-by: James Bottomley Acked-by: Randy Dunlap --- Documentation/DMA-API.txt | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index 1147eba..4f1cdc5 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt @@ -497,19 +497,18 @@ continuing on for size. Again, you *must* observe the cache line boundaries when doing this. int -dma_declare_coherent_memory(struct device *dev, dma_addr_t bus_addr, +dma_declare_coherent_memory(struct device *dev, phys_addr_t phys_addr, dma_addr_t device_addr, size_t size, int flags) Declare region of memory to be handed out by dma_alloc_coherent() when it's asked for coherent memory for this device. -bus_addr is the physical address to which the memory is currently -assigned in the bus responding region (this will be used by the -platform to perform the mapping). +phys_addr is the cpu physical address to which the memory is currently +assigned (this will be ioremapped so the cpu can access the region). device_addr is the bus address the device needs to be programmed -with actually to address this memory (this will be handed out as the +with to actually address this memory (this will be handed out as the dma_addr_t in dma_alloc_coherent()). size is the size of the area (must be multiples of PAGE_SIZE). -- cgit v1.1 From 6e5221558d35563dc656833a021543fba8185c41 Mon Sep 17 00:00:00 2001 From: Huang Shijie Date: Wed, 23 Apr 2014 15:12:47 +0800 Subject: Documentation: mtd: update the document for m25p80 The m25p80.c has used the SPI NOR framework now, and the m25p_ids has been moved to spi-nor.c and renamed to spi_nor_ids. This patch updates the document for m25p80. Signed-off-by: Huang Shijie Acked-by: Marek Vasut Signed-off-by: Brian Norris --- Documentation/devicetree/bindings/mtd/m25p80.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/m25p80.txt b/Documentation/devicetree/bindings/mtd/m25p80.txt index 6d3d576..4611aa8 100644 --- a/Documentation/devicetree/bindings/mtd/m25p80.txt +++ b/Documentation/devicetree/bindings/mtd/m25p80.txt @@ -5,8 +5,8 @@ Required properties: representing partitions. - compatible : Should be the manufacturer and the name of the chip. Bear in mind the DT binding is not Linux-only, but in case of Linux, see the - "m25p_ids" table in drivers/mtd/devices/m25p80.c for the list of - supported chips. + "spi_nor_ids" table in drivers/mtd/spi-nor/spi-nor.c for the list + of supported chips. - reg : Chip-Select number - spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at -- cgit v1.1 From edf02fb248022c13b2c86f08177b99ce619e693a Mon Sep 17 00:00:00 2001 From: pekon gupta Date: Mon, 19 May 2014 13:24:42 +0530 Subject: mtd: nand: omap: Documentation: How to select correct ECC scheme for your device ? - Adds DT binding property for BCH16 ECC scheme - Adds describes on factors which determine choice of ECC scheme for particular device CC: devicetree@vger.kernel.org Signed-off-by: Pekon Gupta Signed-off-by: Brian Norris --- .../devicetree/bindings/mtd/gpmc-nand.txt | 45 ++++++++++++++++++++++ 1 file changed, 45 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt index 5e1f31b..eb81435 100644 --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt @@ -28,6 +28,8 @@ Optional properties: "ham1" 1-bit Hamming ecc code "bch4" 4-bit BCH ecc code "bch8" 8-bit BCH ecc code + "bch16" 16-bit BCH ECC code + Refer below "How to select correct ECC scheme for your device ?" - ti,nand-xfer-type: A string setting the data transfer type. One of: @@ -90,3 +92,46 @@ Example for an AM33xx board: }; }; +How to select correct ECC scheme for your device ? +-------------------------------------------------- +Higher ECC scheme usually means better protection against bit-flips and +increased system lifetime. However, selection of ECC scheme is dependent +on various other factors also like; + +(1) support of built in hardware engines. + Some legacy OMAP SoC do not have ELM harware engine, so those SoC cannot + support ecc-schemes with hardware error-correction (BCHx_HW). However + such SoC can use ecc-schemes with software library for error-correction + (BCHx_HW_DETECTION_SW). The error correction capability with software + library remains equivalent to their hardware counter-part, but there is + slight CPU penalty when too many bit-flips are detected during reads. + +(2) Device parameters like OOBSIZE. + Other factor which governs the selection of ecc-scheme is oob-size. + Higher ECC schemes require more OOB/Spare area to store ECC syndrome, + so the device should have enough free bytes available its OOB/Spare + area to accomodate ECC for entire page. In general following expression + helps in determining if given device can accomodate ECC syndrome: + "2 + (PAGESIZE / 512) * ECC_BYTES" >= OOBSIZE" + where + OOBSIZE number of bytes in OOB/spare area + PAGESIZE number of bytes in main-area of device page + ECC_BYTES number of ECC bytes generated to protect + 512 bytes of data, which is: + '3' for HAM1_xx ecc schemes + '7' for BCH4_xx ecc schemes + '14' for BCH8_xx ecc schemes + '26' for BCH16_xx ecc schemes + + Example(a): For a device with PAGESIZE = 2048 and OOBSIZE = 64 and + trying to use BCH16 (ECC_BYTES=26) ecc-scheme. + Number of ECC bytes per page = (2 + (2048 / 512) * 26) = 106 B + which is greater than capacity of NAND device (OOBSIZE=64) + Hence, BCH16 cannot be supported on given device. But it can + probably use lower ecc-schemes like BCH8. + + Example(b): For a device with PAGESIZE = 2048 and OOBSIZE = 128 and + trying to use BCH16 (ECC_BYTES=26) ecc-scheme. + Number of ECC bytes per page = (2 + (2048 / 512) * 26) = 106 B + which can be accomodate in the OOB/Spare area of this device + (OOBSIZE=128). So this device can use BCH16 ecc-scheme. -- cgit v1.1 From 607e3a29203633eaec7334f2f58f9653df788a06 Mon Sep 17 00:00:00 2001 From: Robert Elliott Date: Tue, 20 May 2014 17:10:51 -0500 Subject: tracing: Add funcgraph_tail option to print function name after closing braces In the function-graph tracer, add a funcgraph_tail option to print the function name on all } lines, not just functions whose first line is no longer in the trace buffer. If a function calls other traced functions, its total time appears on its } line. This change allows grep to be used to determine the function for which the line corresponds. Update Documentation/trace/ftrace.txt to describe this new option. Link: http://lkml.kernel.org/p/20140520221041.8359.6782.stgit@beardog.cce.hp.com Signed-off-by: Robert Elliott Signed-off-by: Steven Rostedt --- Documentation/trace/ftrace.txt | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) (limited to 'Documentation') diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt index bd36598..2479b2a 100644 --- a/Documentation/trace/ftrace.txt +++ b/Documentation/trace/ftrace.txt @@ -2003,6 +2003,32 @@ want, depending on your needs. 360.774530 | 1) 0.594 us | __phys_addr(); +The function name is always displayed after the closing bracket +for a function if the start of that function is not in the +trace buffer. + +Display of the function name after the closing bracket may be +enabled for functions whose start is in the trace buffer, +allowing easier searching with grep for function durations. +It is default disabled. + + hide: echo nofuncgraph-tail > trace_options + show: echo funcgraph-tail > trace_options + + Example with nofuncgraph-tail (default): + 0) | putname() { + 0) | kmem_cache_free() { + 0) 0.518 us | __phys_addr(); + 0) 1.757 us | } + 0) 2.861 us | } + + Example with funcgraph-tail: + 0) | putname() { + 0) | kmem_cache_free() { + 0) 0.518 us | __phys_addr(); + 0) 1.757 us | } /* kmem_cache_free() */ + 0) 2.861 us | } /* putname() */ + You can put some comments on specific functions by using trace_printk() For example, if you want to put a comment inside the __might_sleep() function, you just have to include -- cgit v1.1 From 4284402924cc55e182008ca7e9d4fb1e891ff5ae Mon Sep 17 00:00:00 2001 From: Alexandre Belloni Date: Mon, 19 May 2014 22:42:37 +0200 Subject: pwm: modify PWM_LOOKUP to initialize all struct pwm_lookup members Now that PWM_LOOKUP is not used anymore, modify it to initialize all the members of struct pwm_lookup. Signed-off-by: Alexandre Belloni Signed-off-by: Thierry Reding --- Documentation/pwm.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt index 0527f61..ca895fd 100644 --- a/Documentation/pwm.txt +++ b/Documentation/pwm.txt @@ -19,7 +19,8 @@ should instead register a static mapping that can be used to match PWM consumers to providers, as given in the following example: static struct pwm_lookup board_pwm_lookup[] = { - PWM_LOOKUP("tegra-pwm", 0, "pwm-backlight", NULL), + PWM_LOOKUP("tegra-pwm", 0, "pwm-backlight", NULL, + 50000, PWM_POLARITY_NORMAL), }; static void __init board_init(void) -- cgit v1.1 From 8edffbb933619d568ea98edd3b55ec7c30df9274 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Thu, 8 May 2014 15:39:19 +0200 Subject: drm/doc: Discourage usage of MODESET_CTL ioctl MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Leftover from the old days of ums and should be used any longer. Since commit 29935554b384b1b3a7377d6f0b03b21d18a61683 Author: Laurent Pinchart Date: Wed May 30 00:58:09 2012 +0200 drm: Disallow DRM_IOCTL_MODESET_CTL for KMS drivers it is a complete no-Op for kms drivers. v2: Fix up mangled sentence spotted by Michel. Cc: Laurent Pinchart Cc: Michel Dänzer Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter --- Documentation/DocBook/drm.tmpl | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index ec81c20..ad93c3e 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -2861,12 +2861,12 @@ int num_ioctls; DRM_IOCTL_MODESET_CTL - This should be called by application level drivers before and - after mode setting, since on many devices the vertical blank - counter is reset at that time. Internally, the DRM snapshots - the last vblank count when the ioctl is called with the - _DRM_PRE_MODESET command, so that the counter won't go backwards - (which is dealt with when _DRM_POST_MODESET is used). + This was only used for user-mode-settind drivers around + modesetting changes to allow the kernel to update the vblank + interrupt after mode setting, since on many devices the vertical + blank counter is reset to 0 at some point during modeset. Modern + drivers should not call this any more since with kernel mode + setting it is a no-op. -- cgit v1.1 From f5752b38970990fa1495839751aed64bd178b9e0 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Thu, 8 May 2014 16:41:51 +0200 Subject: drm/irq: kerneldoc polish MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Integrate into the drm DocBook - Disable kerneldoc for functions not exported to drivers. - Properly document the new drm_vblank_on|off and add cautious comments explaining when drm_vblank_pre|post_modesets shouldn't be used. - General polish and OCD. v2: Polish as suggested by Thierry. Cc: Thierry Reding Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter --- Documentation/DocBook/drm.tmpl | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index ad93c3e..62573c1 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -2519,6 +2519,10 @@ void (*disable_vblank) (struct drm_device *dev, int crtc); with a call to drm_vblank_cleanup in the driver unload operation handler. + + Vertical Blanking and Interrupt Handling Functions Reference +!Edrivers/gpu/drm/drm_irq.c + @@ -2871,7 +2875,6 @@ int num_ioctls; - -- cgit v1.1 From bb7f32fe966aa009ef6757aa08067cca3b2ac913 Mon Sep 17 00:00:00 2001 From: Matt Porter Date: Wed, 23 Apr 2014 19:21:30 -0400 Subject: mfd: bcm590xx: Update binding with additional BCM59056 regulators The BCM59056 supports GPLDO1-6 and VBUS regulators in a secondary I2C slave address space. Add these regulators to the list of valid regulator node names for BCM59056. Signed-off-by: Matt Porter Signed-off-by: Lee Jones --- Documentation/devicetree/bindings/mfd/bcm590xx.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/bcm590xx.txt b/Documentation/devicetree/bindings/mfd/bcm590xx.txt index 1fe30e2..be51a15 100644 --- a/Documentation/devicetree/bindings/mfd/bcm590xx.txt +++ b/Documentation/devicetree/bindings/mfd/bcm590xx.txt @@ -19,7 +19,9 @@ Optional child nodes: The valid regulator node names for BCM59056 are: rfldo, camldo1, camldo2, simldo1, simldo2, sdldo, sdxldo, mmcldo1, mmcldo2, audldo, micldo, usbldo, vibldo, - csr, iosr1, iosr2, msr, sdsr1, sdsr2, vsr + csr, iosr1, iosr2, msr, sdsr1, sdsr2, vsr, + gpldo1, gpldo2, gpldo3, gpldo4, gpldo5, gpldo6, + vbus Example: pmu: bcm59056@8 { -- cgit v1.1 From fe4fd75b827a3c037d71ecaed04503e3637ccb1c Mon Sep 17 00:00:00 2001 From: Ezequiel Garcia Date: Wed, 14 May 2014 14:58:09 -0300 Subject: mtd: nand: pxa3xx: Add supported ECC strength and step size to the DT binding This commit updates the devicetree binding documentation for this driver with the supported ECC strength and step size combinations. Signed-off-by: Ezequiel Garcia Signed-off-by: Brian Norris --- Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt b/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt index 86e0a56..de8b517 100644 --- a/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt +++ b/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt @@ -17,6 +17,14 @@ Optional properties: - num-cs: Number of chipselect lines to usw - nand-on-flash-bbt: boolean to enable on flash bbt option if not present false + - nand-ecc-strength: number of bits to correct per ECC step + - nand-ecc-step-size: number of data bytes covered by a single ECC step + +The following ECC strength and step size are currently supported: + + - nand-ecc-strength = <1>, nand-ecc-step-size = <512> + - nand-ecc-strength = <4>, nand-ecc-step-size = <512> + - nand-ecc-strength = <8>, nand-ecc-step-size = <512> Example: -- cgit v1.1 From dfbbdbf4405d73012f158ae39dc3dd66cebcf418 Mon Sep 17 00:00:00 2001 From: Vivek Gautam Date: Thu, 22 May 2014 07:49:13 +0900 Subject: ARM: dts: Add sysreg sytem controller node to exynos5250 and exynos5420 This patch adds sysreg-syscon node to exynos5250 and exynos5420 device tree, to access System Register's registers using syscon driver. Signed-off-by: Kamil Debski [gautam.vivek@samsung.com: Split this syreg-syscon dts entry] [gautam.vivek@samsung.com: added similar syscon entry for exynos5420] Signed-off-by: Vivek Gautam [vikas.sajjan@samsung.com: updated the binding document] Signed-off-by: Vikas Sajjan Signed-off-by: Kukjin Kim --- Documentation/devicetree/bindings/arm/samsung/sysreg.txt | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt index 0ab3251..4fced6e 100644 --- a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt +++ b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt @@ -1,8 +1,10 @@ SAMSUNG S5P/Exynos SoC series System Registers (SYSREG) Properties: - - compatible : should contain "samsung,-sysreg", "syscon"; - For Exynos4 SoC series it should be "samsung,exynos4-sysreg", "syscon"; + - compatible : should contain two values. First value must be one from following list: + - "samsung,exynos4-sysreg" - for Exynos4 based SoCs, + - "samsung,exynos5-sysreg" - for Exynos5 based SoCs. + second value must be always "syscon". - reg : offset and length of the register set. Example: @@ -10,3 +12,8 @@ Example: compatible = "samsung,exynos4-sysreg", "syscon"; reg = <0x10010000 0x400>; }; + + syscon@10050000 { + compatible = "samsung,exynos5-sysreg", "syscon"; + reg = <0x10050000 0x5000>; + }; -- cgit v1.1 From 50bf46509f24c914562b4d818a155d8dc8f45e10 Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Sun, 20 Apr 2014 08:07:42 -0700 Subject: hwmon: (lm77) Do not preserve hysteresis when updating critical temp limit Updating the hysteresis value when updating the critical temperature limit was following the rule of 'least surprise'. However, it had the undesirable side effect of changing the hysteresis for all other attributes, which defeats the purpose of least surprise. In addition, it could result in invalid hysteresis values if the resulting hysteresis was too large. In such cases the resulting hysteresis ended up changed anyway, which again defeats the purpose. So drop that code and document the new behavior. Reviewed-by: Jean Delvare Signed-off-by: Guenter Roeck --- Documentation/hwmon/lm77 | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/lm77 b/Documentation/hwmon/lm77 index 57c3a46..bfc915f 100644 --- a/Documentation/hwmon/lm77 +++ b/Documentation/hwmon/lm77 @@ -18,5 +18,21 @@ sensor incorporates a band-gap type temperature sensor, 10-bit ADC, and a digital comparator with user-programmable upper and lower limit values. -Limits can be set through the Overtemperature Shutdown register and -Hysteresis register. +The LM77 implements 3 limits: low (temp1_min), high (temp1_max) and +critical (temp1_crit.) It also implements an hysteresis mechanism which +applies to all 3 limits. The relative difference is stored in a single +register on the chip, which means that the relative difference between +the limit and its hysteresis is always the same for all 3 limits. + +This implementation detail implies the following: +* When setting a limit, its hysteresis will automatically follow, the + difference staying unchanged. For example, if the old critical limit + was 80 degrees C, and the hysteresis was 75 degrees C, and you change + the critical limit to 90 degrees C, then the hysteresis will + automatically change to 85 degrees C. +* All 3 hysteresis can't be set independently. We decided to make + temp1_crit_hyst writable, while temp1_min_hyst and temp1_max_hyst are + read-only. Setting temp1_crit_hyst writes the difference between + temp1_crit_hyst and temp1_crit into the chip, and the same relative + hysteresis applies automatically to the low and high limits. +* The limits should be set before the hysteresis. -- cgit v1.1 From a9622663e0406932612ffd44fde586e59df9de43 Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Sat, 10 May 2014 09:56:15 -0700 Subject: hwmon: Document hwmon kernel API The hwmon subsystem has been around for a while. Time to document its kernel API. Acked-by: Randy Dunlap Signed-off-by: Guenter Roeck --- Documentation/hwmon/hwmon-kernel-api.txt | 107 +++++++++++++++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100644 Documentation/hwmon/hwmon-kernel-api.txt (limited to 'Documentation') diff --git a/Documentation/hwmon/hwmon-kernel-api.txt b/Documentation/hwmon/hwmon-kernel-api.txt new file mode 100644 index 0000000..2ecdbfc --- /dev/null +++ b/Documentation/hwmon/hwmon-kernel-api.txt @@ -0,0 +1,107 @@ +The Linux Hardware Monitoring kernel API. +========================================= + +Guenter Roeck + +Introduction +------------ + +This document describes the API that can be used by hardware monitoring +drivers that want to use the hardware monitoring framework. + +This document does not describe what a hardware monitoring (hwmon) Driver or +Device is. It also does not describe the API which can be used by user space +to communicate with a hardware monitoring device. If you want to know this +then please read the following file: Documentation/hwmon/sysfs-interface. + +For additional guidelines on how to write and improve hwmon drivers, please +also read Documentation/hwmon/submitting-patches. + +The API +------- +Each hardware monitoring driver must #include and, in most +cases, . linux/hwmon.h declares the following +register/unregister functions: + +struct device *hwmon_device_register(struct device *dev); +struct device * +hwmon_device_register_with_groups(struct device *dev, const char *name, + void *drvdata, + const struct attribute_group **groups); + +struct device * +devm_hwmon_device_register_with_groups(struct device *dev, + const char *name, void *drvdata, + const struct attribute_group **groups); + +void hwmon_device_unregister(struct device *dev); +void devm_hwmon_device_unregister(struct device *dev); + +hwmon_device_register registers a hardware monitoring device. The parameter +of this function is a pointer to the parent device. +This function returns a pointer to the newly created hardware monitoring device +or PTR_ERR for failure. If this registration function is used, hardware +monitoring sysfs attributes are expected to have been created and attached to +the parent device prior to calling hwmon_device_register. A name attribute must +have been created by the caller. + +hwmon_device_register_with_groups is similar to hwmon_device_register. However, +it has additional parameters. The name parameter is a pointer to the hwmon +device name. The registration function wil create a name sysfs attribute +pointing to this name. The drvdata parameter is the pointer to the local +driver data. hwmon_device_register_with_groups will attach this pointer +to the newly allocated hwmon device. The pointer can be retrieved by the driver +using dev_get_drvdata() on the hwmon device pointer. The groups parameter is +a pointer to a list of sysfs attribute groups. The list must be NULL terminated. +hwmon_device_register_with_groups creates the hwmon device with name attribute +as well as all sysfs attributes attached to the hwmon device. + +devm_hwmon_device_register_with_groups is similar to +hwmon_device_register_with_groups. However, it is device managed, meaning the +hwmon device does not have to be removed explicitly by the removal function. + +hwmon_device_unregister deregisters a registered hardware monitoring device. +The parameter of this function is the pointer to the registered hardware +monitoring device structure. This function must be called from the driver +remove function if the hardware monitoring device was registered with +hwmon_device_register or with hwmon_device_register_with_groups. + +devm_hwmon_device_unregister does not normally have to be called. It is only +needed for error handling, and only needed if the driver probe fails after +the call to devm_hwmon_device_register_with_groups. + +The header file linux/hwmon-sysfs.h provides a number of useful macros to +declare and use hardware monitoring sysfs attributes. + +In many cases, you can use the exsting define DEVICE_ATTR to declare such +attributes. This is feasible if an attribute has no additional context. However, +in many cases there will be additional information such as a sensor index which +will need to be passed to the sysfs attribute handling function. + +SENSOR_DEVICE_ATTR and SENSOR_DEVICE_ATTR_2 can be used to define attributes +which need such additional context information. SENSOR_DEVICE_ATTR requires +one additional argument, SENSOR_DEVICE_ATTR_2 requires two. + +SENSOR_DEVICE_ATTR defines a struct sensor_device_attribute variable. +This structure has the following fields. + +struct sensor_device_attribute { + struct device_attribute dev_attr; + int index; +}; + +You can use to_sensor_dev_attr to get the pointer to this structure from the +attribute read or write function. Its parameter is the device to which the +attribute is attached. + +SENSOR_DEVICE_ATTR_2 defines a struct sensor_device_attribute_2 variable, +which is defined as follows. + +struct sensor_device_attribute_2 { + struct device_attribute dev_attr; + u8 index; + u8 nr; +}; + +Use to_sensor_dev_attr_2 to get the pointer to this structure. Its parameter +is the device to which the attribute is attached. -- cgit v1.1 From 57d60b1b7e0d0d32602587fd032d56d7ed9e1556 Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Mon, 12 May 2014 10:11:32 -0700 Subject: hwmon: (emc1403) Add driver documentation With the driver now supporting several chip variants, it is about time to document what is supported. Signed-off-by: Guenter Roeck --- Documentation/hwmon/emc1403 | 56 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 Documentation/hwmon/emc1403 (limited to 'Documentation') diff --git a/Documentation/hwmon/emc1403 b/Documentation/hwmon/emc1403 new file mode 100644 index 0000000..b109e35 --- /dev/null +++ b/Documentation/hwmon/emc1403 @@ -0,0 +1,56 @@ +Kernel driver emc1403 +===================== + +Supported chips: + * SMSC / Microchip EMC1402, EMC1412 + Addresses scanned: I2C 0x18, 0x1c, 0x29, 0x4c, 0x4d, 0x5c + Prefix: 'emc1402' + Datasheets: + http://ww1.microchip.com/downloads/en/DeviceDoc/1412.pdf + http://ww1.microchip.com/downloads/en/DeviceDoc/1402.pdf + * SMSC / Microchip EMC1403, EMC1404, EMC1413, EMC1414 + Addresses scanned: I2C 0x18, 0x29, 0x4c, 0x4d + Prefix: 'emc1403', 'emc1404' + Datasheets: + http://ww1.microchip.com/downloads/en/DeviceDoc/1403_1404.pdf + http://ww1.microchip.com/downloads/en/DeviceDoc/1413_1414.pdf + * SMSC / Microchip EMC1422 + Addresses scanned: I2C 0x4c + Prefix: 'emc1422' + Datasheet: + http://ww1.microchip.com/downloads/en/DeviceDoc/1422.pdf + * SMSC / Microchip EMC1423, EMC1424 + Addresses scanned: I2C 0x4c + Prefix: 'emc1423', 'emc1424' + Datasheet: + http://ww1.microchip.com/downloads/en/DeviceDoc/1423_1424.pdf + +Author: + Kalhan Trisal Date: Mon, 12 May 2014 11:10:56 -0700 Subject: hwmon: (emc1403) Make all hyst attributes except for temp1_crit_hyst read-only All chips in this chip series only support a single hysteresis value. Having multiple writable hysteresis attributes is therefore confusing, since a single write affects all hysteresis temperatures. Make all but one (temp1_crit_hyst) read-only. Reviewed-by: Jean Delvare Signed-off-by: Guenter Roeck --- Documentation/hwmon/emc1403 | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/emc1403 b/Documentation/hwmon/emc1403 index b109e35..a869b0e 100644 --- a/Documentation/hwmon/emc1403 +++ b/Documentation/hwmon/emc1403 @@ -51,6 +51,9 @@ This implementation detail implies the following: was 80 degrees C, and the hysteresis was 75 degrees C, and you change the critical limit to 90 degrees C, then the hysteresis will automatically change to 85 degrees C. -* While hysteresis limits can be set for all critical limits, setting a single - hysteresis value affects the hysteresis values for all limits on all sensors. +* The hysteresis values can't be set independently. We decided to make + only temp1_crit_hyst writable, while all other hysteresis attributes + are read-only. Setting temp1_crit_hyst writes the difference between + temp1_crit_hyst and temp1_crit into the chip, and the same relative + hysteresis applies automatically to all other limits. * The limits should be set before the hysteresis. -- cgit v1.1 From 175c490c9e7f75dbe6addd937c41939c137c6847 Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Tue, 15 Apr 2014 22:07:30 -0700 Subject: hwmon: (jc42) Add support for STTS2004 and AT30TSE004 Also fix links to datasheets for other supported sensors from ST Microelectronics, and add links to several Atmel datasheets. Signed-off-by: Guenter Roeck --- Documentation/hwmon/jc42 | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/jc42 b/Documentation/hwmon/jc42 index 868d74d..f3893f7 100644 --- a/Documentation/hwmon/jc42 +++ b/Documentation/hwmon/jc42 @@ -5,9 +5,12 @@ Supported chips: * Analog Devices ADT7408 Datasheets: http://www.analog.com/static/imported-files/data_sheets/ADT7408.pdf - * Atmel AT30TS00 + * Atmel AT30TS00, AT30TS002A/B, AT30TSE004A Datasheets: http://www.atmel.com/Images/doc8585.pdf + http://www.atmel.com/Images/doc8711.pdf + http://www.atmel.com/Images/Atmel-8852-SEEPROM-AT30TSE002A-Datasheet.pdf + http://www.atmel.com/Images/Atmel-8868-DTS-AT30TSE004A-Datasheet.pdf * IDT TSE2002B3, TSE2002GB2, TS3000B3, TS3000GB2 Datasheets: http://www.idt.com/sites/default/files/documents/IDT_TSE2002B3C_DST_20100512_120303152056.pdf @@ -34,12 +37,13 @@ Supported chips: Datasheet: http://www.onsemi.com/pub_link/Collateral/CAT34TS02-D.PDF http://www.onsemi.com/pub/Collateral/CAT6095-D.PDF - * ST Microelectronics STTS424, STTS424E02, STTS2002, STTS3000 + * ST Microelectronics STTS424, STTS424E02, STTS2002, STTS2004, STTS3000 Datasheets: - http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00157556.pdf - http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00157558.pdf - http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00225278.pdf - http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATA_BRIEF/CD00270920.pdf + http://www.st.com/web/en/resource/technical/document/datasheet/CD00157556.pdf + http://www.st.com/web/en/resource/technical/document/datasheet/CD00157558.pdf + http://www.st.com/web/en/resource/technical/document/datasheet/CD00266638.pdf + http://www.st.com/web/en/resource/technical/document/datasheet/CD00225278.pdf + http://www.st.com/web/en/resource/technical/document/datasheet/DM00076709.pdf * JEDEC JC 42.4 compliant temperature sensor chips Datasheet: http://www.jedec.org/sites/default/files/docs/4_01_04R19.pdf -- cgit v1.1 From 41082d66bfd6fafe001c0902bb4622d7aee6f128 Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Sun, 6 Apr 2014 08:57:20 -0700 Subject: hwmon: Driver for NCT6683D Nuvoton NCT6683D is an eSIO with hardware monitoring capabilities. Signed-off-by: Guenter Roeck --- Documentation/hwmon/nct6683 | 57 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 Documentation/hwmon/nct6683 (limited to 'Documentation') diff --git a/Documentation/hwmon/nct6683 b/Documentation/hwmon/nct6683 new file mode 100644 index 0000000..c1301d4 --- /dev/null +++ b/Documentation/hwmon/nct6683 @@ -0,0 +1,57 @@ +Kernel driver nct6683 +===================== + +Supported chips: + * Nuvoton NCT6683D + Prefix: 'nct6683' + Addresses scanned: ISA address retrieved from Super I/O registers + Datasheet: Available from Nuvoton upon request + +Authors: + Guenter Roeck + +Description +----------- + +This driver implements support for the Nuvoton NCT6683D eSIO chip. + +The chips implement up to shared 32 temperature and voltage sensors. +It supports up to 16 fan rotation sensors and up to 8 fan control engines. + +Temperatures are measured in degrees Celsius. Measurement resolution is +0.5 degrees C. + +Voltage sensors (also known as IN sensors) report their values in millivolts. + +Fan rotation speeds are reported in RPM (rotations per minute). + +Usage Note +---------- + +Limit register locations on Intel boards with EC firmware version 1.0 +build date 04/03/13 do not match the register locations in the Nuvoton +datasheet. Nuvoton confirms that Intel uses a special firmware version +with different register addresses. The specification describing the Intel +firmware is held under NDA by Nuvoton and Intel and not available +to the public. + +Some of the register locations can be reverse engineered; others are too +well hidden. Given this, writing any values from the operating system is +considered too risky with this firmware and has been disabled. All limits +must all be written from the BIOS. + +The driver has only been tested with the Intel firmware, and by default +only instantiates on Intel boards. To enable it on non-Intel boards, +set the 'force' module parameter to 1. + +Tested Boards and Firmware Versions +----------------------------------- + +The driver has been reported to work with the following boards and +firmware versions. + +Board Firmware version +--------------------------------------------------------------- +Intel DH87RL NCT6683D EC firmware version 1.0 build 04/03/13 +Intel DH87MC NCT6683D EC firmware version 1.0 build 04/03/13 +Intel DB85FL NCT6683D EC firmware version 1.0 build 04/03/13 -- cgit v1.1 From 5ed9d92f1b0fbed3fe4370a91b4baed58c3d2a23 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Mon, 31 Mar 2014 14:54:57 +0200 Subject: i2c: mv64xxx: Change i2c compatibles for sunxi The Allwinner A10 compatibles were following a slightly different compatible patterns than the rest of the SoCs for historical reasons. Move to the other pattern for consistency across all Allwinner Socs. Signed-off-by: Maxime Ripard [wsa: dropped binding OK as per http://lists.infradead.org/pipermail/linux-arm-kernel/2014-February/229438.html] Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt index befd4fb..5c30026 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt @@ -5,7 +5,7 @@ Required properties : - reg : Offset and length of the register set for the device - compatible : Should be either: - - "allwinner,sun4i-i2c" + - "allwinner,sun4i-a10-i2c" - "allwinner,sun6i-a31-i2c" - "marvell,mv64xxx-i2c" - "marvell,mv78230-i2c" -- cgit v1.1 From a83bea7c1170ad8c68d65ed2fff6a533e68f67a4 Mon Sep 17 00:00:00 2001 From: Doug Anderson Date: Tue, 29 Apr 2014 10:30:51 -0700 Subject: i2c: mux: Add more warnings to i2c-arb-gpio-challenge docs This adds some more warnings to the i2c-arb-gpio-challenge docs to help encourage people not to use it in their designs unless they have no choice. Signed-off-by: Doug Anderson Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt index 1ac8ea8..bfeabb8 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt @@ -8,6 +8,12 @@ the standard I2C multi-master rules. Using GPIOs is generally useful in the case where there is a device on the bus that has errata and/or bugs that makes standard multimaster mode not feasible. +Note that this scheme works well enough but has some downsides: +* It is nonstandard (not using standard I2C multimaster) +* Having two masters on a bus in general makes it relatively hard to debug + problems (hard to tell if i2c issues were caused by one master, another, or + some device on the bus). + Algorithm: -- cgit v1.1 From 218e1496135e94e901bf1c136d81ede7e2b418b8 Mon Sep 17 00:00:00 2001 From: Naveen Krishna Ch Date: Mon, 28 Apr 2014 14:29:58 +0530 Subject: i2c: exynos5: add support for HSI2C on Exynos5260 SoC HSI2C module on Exynos5260 differs from current modules in following ways: 1. HSI2C on Exynos5260 has fifo_depth of 16bytes 2. Module needs to be reset as a part of init sequence. Hence, Following changes are involved. 1. Add a new compatible string and Updates the Documentation dt bindings. 2. Introduce a variant struct to support the changes in H/W 3. Reset the module during init. Thus, bringing the module back to default state irrespective of what firmware did with it. Signed-off-by: Naveen Krishna Chatradhi Signed-off-by: Pankaj Dubey Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/i2c-exynos5.txt | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt index 056732c..d4745e3 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt @@ -5,7 +5,14 @@ at various speeds ranging from 100khz to 3.4Mhz. Required properties: - compatible: value should be. - -> "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c. + -> "samsung,exynos5-hsi2c", (DEPRECATED) + for i2c compatible with HSI2C available + on Exynos5250 and Exynos5420 SoCs. + -> "samsung,exynos5250-hsi2c", for i2c compatible with HSI2C available + on Exynos5250 and Exynos5420 SoCs. + -> "samsung,exynos5260-hsi2c", for i2c compatible with HSI2C available + on Exynos5260 SoCs. + - reg: physical base address of the controller and length of memory mapped region. - interrupts: interrupt number to the cpu. @@ -26,7 +33,7 @@ Optional properties: Example: hsi2c@12ca0000 { - compatible = "samsung,exynos5-hsi2c"; + compatible = "samsung,exynos5250-hsi2c"; reg = <0x12ca0000 0x100>; interrupts = <56>; clock-frequency = <100000>; -- cgit v1.1 From 5aacb66656121ba8c917a905e0eef192c0b22212 Mon Sep 17 00:00:00 2001 From: Wolfram Sang Date: Fri, 2 May 2014 21:15:10 +0200 Subject: i2c: sh_mobile: add devicetree documentation Reported-by: Geert Uytterhoeven Signed-off-by: Wolfram Sang Signed-off-by: Wolfram Sang --- .../devicetree/bindings/i2c/i2c-sh_mobile.txt | 26 ++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt new file mode 100644 index 0000000..d2153ce --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt @@ -0,0 +1,26 @@ +Device tree configuration for Renesas IIC (sh_mobile) driver + +Required properties: +- compatible : "renesas,iic-". "renesas,rmobile-iic" as fallback +- reg : address start and address range size of device +- interrupts : interrupt of device +- clocks : clock for device +- #address-cells : should be <1> +- #size-cells : should be <0> + +Optional properties: +- clock-frequency : frequency of bus clock in Hz. Default 100kHz if unset. + +Pinctrl properties might be needed, too. See there. + +Example: + + iic0: i2c@e6500000 { + compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic"; + reg = <0 0xe6500000 0 0x425>; + interrupts = <0 174 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp3_clks R8A7790_CLK_IIC0>; + clock-frequency = <400000>; + #address-cells = <1>; + #size-cells = <0>; + }; -- cgit v1.1 From efc24e148009bb7965439a3a29abfb778a45061e Mon Sep 17 00:00:00 2001 From: Peter Ujfalusi Date: Fri, 16 May 2014 15:17:16 +0300 Subject: dt/bindings: ti,edma: Remove redundant properties from documentation From CCCFG register of eDMA3 we can get all the needed information for the driver about the IP: Number of channels: NUM_DMACH Number of regions: NUM_REGN Number of slots (PaRAM sets): NUM_PAENTRY Number of TC/EQ: NUM_EVQUE The ti,edma-regions; ti,edma-slots and dma-channels in DT are redundant since the very same information can be obtained from the HW. The mentioned properties are deprecated. Signed-off-by: Peter Ujfalusi Signed-off-by: Sekhar Nori --- Documentation/devicetree/bindings/dma/ti-edma.txt | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt index 9fbbdb7..ad67c41 100644 --- a/Documentation/devicetree/bindings/dma/ti-edma.txt +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt @@ -2,11 +2,8 @@ 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: @@ -17,6 +14,13 @@ Optional properties: - ti,hwmods: Name of the hwmods associated to the EDMA - ti,edma-xbar-event-map: Crossbar event to channel map +Deprecated properties: +Listed here in case one wants to boot an old kernel with new DTB. These +properties might need to be added to the new DTS files. +- ti,edma-regions: Number of regions +- ti,edma-slots: Number of slots +- dma-channels: Specify total DMA channels per CC + Example: edma: edma@49000000 { @@ -26,9 +30,6 @@ edma: edma@49000000 { 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 0e76718923ca71548636bf02adc48e6104e4fb05 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= Date: Fri, 25 Apr 2014 20:14:31 +0300 Subject: drm/i915: Add a brief description of the VLV display PHY internals MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Document the internal structure of the VLV display PHY a bit to help people understand how the different register blocks relate to each other. v2: Add a bit more text Make it a DOC: comment, but leave the ascii art out since it would get mangled Signed-off-by: Ville Syrjälä Reviewed-by: Chon Ming Lee Signed-off-by: Daniel Vetter --- Documentation/DocBook/drm.tmpl | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 62573c1..b4f12d4 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -2937,6 +2937,10 @@ int num_ioctls; probing, so those sections fully apply. + + DPIO +!Pdrivers/gpu/drm/i915/i915_reg.h DPIO + -- cgit v1.1 From 111a9c1467483f41a39282ec9f8146133c5524c2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= Date: Fri, 25 Apr 2014 20:14:32 +0300 Subject: drm/i915: Provide DPIO diagrams as docboox tables MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The ascii art version of the DPIO diagram gets mangled by docbook, so we can't use it there. Insted provide another version built using . Signed-off-by: Ville Syrjälä Reviewed-by: Chon Ming Lee Reviewed-by: Damien Lespiau Signed-off-by: Daniel Vetter --- Documentation/DocBook/drm.tmpl | 86 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 86 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index b4f12d4..9574bf2 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -2940,6 +2940,92 @@ int num_ioctls; DPIO !Pdrivers/gpu/drm/i915/i915_reg.h DPIO +
+ Dual channel PHY (VLV/CHV) + + + + + + + + + + + + + + + + + + CH0 + CH1 + + + + + CMN/PLL/REF + CMN/PLL/REF + + + PCS01 + PCS23 + PCS01 + PCS23 + + + TX0 + TX1 + TX2 + TX3 + TX0 + TX1 + TX2 + TX3 + + + DDI0 + DDI1 + + + +
+ + Single channel PHY (CHV) + + + + + + + + + + + CH0 + + + + + CMN/PLL/REF + + + PCS01 + PCS23 + + + TX0 + TX1 + TX2 + TX3 + + + DDI2 + + + +
-- cgit v1.1 From 19b7f796c375a8098924717b171ac5058129d2c4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?David=20Lanzend=C3=B6rfer?= Date: Mon, 12 May 2014 14:04:48 +0200 Subject: mmc: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The Allwinner sunxi mmc host uses dma in bus-master mode using a built-in designware idmac controller, which is identical to the one found in the mmc-dw hosts. However the rest of the host is not identical to mmc-dw, it deals with sending stop commands in hardware which makes it significantly different from the mmc-dw devices. Signed-off-by: David Lanzendörfer [hdegoede@redhat.com: various cleanups and fixes] Signed-off-by: Hans de Goede Acked-by: Maxime Ripard Acked-by: Arnd Bergmann Signed-off-by: Ulf Hansson Signed-off-by: Chris Ball --- .../devicetree/bindings/mmc/sunxi-mmc.txt | 43 ++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 Documentation/devicetree/bindings/mmc/sunxi-mmc.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt new file mode 100644 index 0000000..91b3a34 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt @@ -0,0 +1,43 @@ +* Allwinner sunxi MMC controller + +The highspeed MMC host controller on Allwinner SoCs provides an interface +for MMC, SD and SDIO types of memory cards. + +Supported maximum speeds are the ones of the eMMC standard 4.5 as well +as the speed of SD standard 3.0. +Absolute maximum transfer rate is 200MB/s + +Required properties: + - compatible : "allwinner,sun4i-a10-mmc" or "allwinner,sun5i-a13-mmc" + - reg : mmc controller base registers + - clocks : a list with 2 phandle + clock specifier pairs + - clock-names : must contain "ahb" and "mmc" + - interrupts : mmc controller interrupt + +Optional properties: + - resets : phandle + reset specifier pair + - reset-names : must contain "ahb" + - for cd, bus-width and additional generic mmc parameters + please refer to mmc.txt within this directory + +Examples: + - Within .dtsi: + mmc0: mmc@01c0f000 { + compatible = "allwinner,sun5i-a13-mmc"; + reg = <0x01c0f000 0x1000>; + clocks = <&ahb_gates 8>, <&mmc0_clk>; + clock-names = "ahb", "mod"; + interrupts = <0 32 4>; + status = "disabled"; + }; + + - Within dts: + mmc0: mmc@01c0f000 { + pinctrl-names = "default", "default"; + pinctrl-0 = <&mmc0_pins_a>; + pinctrl-1 = <&mmc0_cd_pin_reference_design>; + bus-width = <4>; + cd-gpios = <&pio 7 1 0>; /* PH1 */ + cd-inverted; + status = "okay"; + }; -- cgit v1.1 From 7b9613aca42a5522d269f89496fef7df10934335 Mon Sep 17 00:00:00 2001 From: Chanho Park Date: Fri, 23 May 2014 03:30:20 +0900 Subject: ARM: dts: add PMU syscon node for exynos4 This patch adds a PMU(Power Management Unit) syscon node. This should be required for USB Phy syscon regmap I/F. Cc: Kamil Debski Signed-off-by: Chanho Park Reviewed-by: Tomasz Figa Signed-off-by: Kukjin Kim --- Documentation/devicetree/bindings/arm/samsung/pmu.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt b/Documentation/devicetree/bindings/arm/samsung/pmu.txt index f1f1552..b562634 100644 --- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt +++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt @@ -2,6 +2,9 @@ SAMSUNG Exynos SoC series PMU Registers Properties: - compatible : should contain two values. First value must be one from following list: + - "samsung,exynos4210-pmu" - for Exynos4210 SoC, + - "samsung,exynos4212-pmu" - for Exynos4212 SoC, + - "samsung,exynos4412-pmu" - for Exynos4412 SoC, - "samsung,exynos5250-pmu" - for Exynos5250 SoC, - "samsung,exynos5420-pmu" - for Exynos5420 SoC. second value must be always "syscon". -- cgit v1.1 From 91c1d980d6013dec4292309aa1700af36b400477 Mon Sep 17 00:00:00 2001 From: Florian Fainelli Date: Thu, 22 May 2014 09:47:43 -0700 Subject: Documentation: devicetree: add old and deprecated 'fixed-link' Update the fixed-link Device Tree binding documentation to contain information about the old and deprecated 5-digit 'fixed-link' property. Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/fixed-link.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/fixed-link.txt b/Documentation/devicetree/bindings/net/fixed-link.txt index e956de1..82bf7e0 100644 --- a/Documentation/devicetree/bindings/net/fixed-link.txt +++ b/Documentation/devicetree/bindings/net/fixed-link.txt @@ -18,6 +18,18 @@ properties: * 'asym-pause' (boolean, optional), to indicate that asym_pause should be enabled. +Old, deprecated 'fixed-link' binding: + +* A 'fixed-link' property in the Ethernet MAC node, with 5 cells, of the + form with the following accepted values: + - a: emulated PHY ID, choose any but but unique to the all specified + fixed-links, from 0 to 31 + - b: duplex configuration: 0 for half duplex, 1 for full duplex + - c: link speed in Mbits/sec, accepted values are: 10, 100 and 1000 + - d: pause configuration: 0 for no pause, 1 for pause + - e: asymmetric pause configuration: 0 for no asymmetric pause, 1 for + asymmetric pause + Example: ethernet@0 { -- cgit v1.1 From ae21888f9ef34fc2584b6caceb93f0b496dd21d5 Mon Sep 17 00:00:00 2001 From: Florian Fainelli Date: Thu, 22 May 2014 09:47:44 -0700 Subject: Documentation: devicetree: net: refer to fixed-link.txt Update the Freescale TSEC PHY, Broadcom GENET & SYSTEMPORT Device Tree binding documentation to refer to the fixed-link Device Tree binding in fixed-link.txt. Reviewed-by: Thomas Petazzoni Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt | 2 +- Documentation/devicetree/bindings/net/broadcom-systemport.txt | 2 +- Documentation/devicetree/bindings/net/fsl-tsec-phy.txt | 5 +---- 3 files changed, 3 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt b/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt index f2febb9..451fef2 100644 --- a/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt +++ b/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt @@ -24,7 +24,7 @@ Optional properties: - fixed-link: When the GENET interface is connected to a MoCA hardware block or when operating in a RGMII to RGMII type of connection, or when the MDIO bus is voluntarily disabled, this property should be used to describe the "fixed link". - See Documentation/devicetree/bindings/net/fsl-tsec-phy.txt for information on + See Documentation/devicetree/bindings/net/fixed-link.txt for information on the property specifics Required child nodes: diff --git a/Documentation/devicetree/bindings/net/broadcom-systemport.txt b/Documentation/devicetree/bindings/net/broadcom-systemport.txt index 1b7600e..c183ea9 100644 --- a/Documentation/devicetree/bindings/net/broadcom-systemport.txt +++ b/Documentation/devicetree/bindings/net/broadcom-systemport.txt @@ -8,7 +8,7 @@ Required properties: - local-mac-address: Ethernet MAC address (48 bits) of this adapter - phy-mode: Should be a string describing the PHY interface to the Ethernet switch/PHY, see Documentation/devicetree/bindings/net/ethernet.txt -- fixed-link: see Documentation/devicetree/bindings/net/fsl-tsec-phy.txt for +- fixed-link: see Documentation/devicetree/bindings/net/fixed-link.txt for the property specific details Optional properties: diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt index 737cdef..be6ea89 100644 --- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt +++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt @@ -42,10 +42,7 @@ Properties: interrupt. For TSEC and eTSEC devices, the first interrupt is transmit, the second is receive, and the third is error. - phy-handle : See ethernet.txt file in the same directory. - - fixed-link : where a is emulated phy id - choose any, - but unique to the all specified fixed-links, b is duplex - 0 half, - 1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no - pause, 1 pause, e is asym_pause - 0 no asym_pause, 1 asym_pause. + - fixed-link : See fixed-link.txt in the same directory. - phy-connection-type : See ethernet.txt file in the same directory. This property is only really needed if the connection is of type "rgmii-id", as all other connection types are detected by hardware. -- cgit v1.1 From b0db5cdf3975134ca967e8b8370a8f0c91ce2329 Mon Sep 17 00:00:00 2001 From: Tobias Klauser Date: Tue, 20 May 2014 13:52:13 +0200 Subject: net: doc: Update references to skb->rxhash In commit 61b905da33 ("net: Rename skb->rxhash to skb->hash"), skb->rxhash was renamed to skb->hash. Update references in Documentation accordingly. Signed-off-by: Tobias Klauser Acked-by: Daniel Borkmann Signed-off-by: David S. Miller --- Documentation/networking/filter.txt | 2 +- Documentation/networking/packet_mmap.txt | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt index 81f940f..e3ba753 100644 --- a/Documentation/networking/filter.txt +++ b/Documentation/networking/filter.txt @@ -277,7 +277,7 @@ Possible BPF extensions are shown in the following table: mark skb->mark queue skb->queue_mapping hatype skb->dev->type - rxhash skb->rxhash + rxhash skb->hash cpu raw_smp_processor_id() vlan_tci vlan_tx_tag_get(skb) vlan_pr vlan_tx_tag_present(skb) diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt index 6fea79e..38112d5 100644 --- a/Documentation/networking/packet_mmap.txt +++ b/Documentation/networking/packet_mmap.txt @@ -578,7 +578,7 @@ processes. This also works in combination with mmap(2) on packet sockets. Currently implemented fanout policies are: - - PACKET_FANOUT_HASH: schedule to socket by skb's rxhash + - PACKET_FANOUT_HASH: schedule to socket by skb's packet hash - PACKET_FANOUT_LB: schedule to socket by round-robin - PACKET_FANOUT_CPU: schedule to socket by CPU packet arrives on - PACKET_FANOUT_RND: schedule to socket by random selection -- cgit v1.1 From 7a9e6da11c9478741947de3a37ac7de26abd23f0 Mon Sep 17 00:00:00 2001 From: Petr Oros Date: Thu, 22 May 2014 14:04:44 +0200 Subject: doc: fix incorrect formula to calculate CommitLimit value The formula to calculate "CommitLimit" value mentioned in kernel documentation is incorrect. Right formula is: CommitLimit = ([total RAM pages] - [total huge TLB pages]) * overcommit_ratio / 100 + [total swap pages] Signed-off-by: Petr Oros Acked-by: Randy Dunlap Signed-off-by: Jiri Kosina --- Documentation/filesystems/proc.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index d4fa7f5..324328d 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -854,7 +854,8 @@ WritebackTmp: Memory used by FUSE for temporary writeback buffers if strict overcommit accounting is enabled (mode 2 in 'vm.overcommit_memory'). The CommitLimit is calculated with the following formula: - CommitLimit = ('vm.overcommit_ratio' * Physical RAM) + Swap + CommitLimit = ([total RAM pages] - [total huge TLB pages]) * + overcommit_ratio / 100 + [total swap pages] For example, on a system with 1G of physical RAM and 7G of swap with a `vm.overcommit_ratio` of 30 it would yield a CommitLimit of 7.3G. -- cgit v1.1 From e8640b79a7607b4aab2956eea0e3538e826ea5b1 Mon Sep 17 00:00:00 2001 From: Valentin Longchamp Date: Tue, 22 Apr 2014 11:30:29 +0200 Subject: devicetree: bindings: add Zarlink to the vendor prefixes Even though the company belongs to Microsemi, many chips are still labeled as Zarlink. Among them is the family of network clock generators, the zl3034x. Signed-off-by: Valentin Longchamp Signed-off-by: Scott Wood --- 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 abc3080..1a6793b 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -135,3 +135,4 @@ wm Wondermedia Technologies, Inc. xes Extreme Engineering Solutions (X-ES) xlnx Xilinx zyxel ZyXEL Communications Corp. +zarlink Zarlink Semiconductor -- cgit v1.1 From bfee31f5bb9bb37aaa2bcb29c00e6ca976161dc7 Mon Sep 17 00:00:00 2001 From: Valentin Longchamp Date: Tue, 22 Apr 2014 11:30:30 +0200 Subject: devcietree: bindings: add some MFD Keymile FPGAs These are the bindings for 2 MFD devices used on some of the Keymile boards. The first one is the chassis managmenet bfticu FPGA. The second one is the board controller (reset, LEDs, GPIOs) QRIO CPDL. These FPGAs are used in the kmcoge4 board. Signed-off-by: Valentin Longchamp Signed-off-by: Scott Wood --- Documentation/devicetree/bindings/mfd/bfticu.txt | 25 ++++++++++++++++++++++++ Documentation/devicetree/bindings/mfd/qriox.txt | 17 ++++++++++++++++ 2 files changed, 42 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/bfticu.txt create mode 100644 Documentation/devicetree/bindings/mfd/qriox.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/bfticu.txt b/Documentation/devicetree/bindings/mfd/bfticu.txt new file mode 100644 index 0000000..65c9077 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/bfticu.txt @@ -0,0 +1,25 @@ +KEYMILE bfticu Chassis Management FPGA + +The bfticu is a multifunction device that manages the whole chassis. +Its main functionality is to collect IRQs from the whole chassis and signals +them to a single controller. + +Required properties: +- compatible: "keymile,bfticu" +- interrupt-controller: the bfticu FPGA is an interrupt controller +- interrupts: the main IRQ line to signal the collected IRQs +- #interrupt-cells : is 2 and their usage is compliant to the 2 cells variant + of Documentation/devicetree/bindings/interrupt-controller/interrupts.txt +- interrupt-parent: the parent IRQ ctrl the main IRQ is connected to +- reg: access on the parent local bus (chip select, offset in chip select, size) + +Example: + + chassis-mgmt@3,0 { + compatible = "keymile,bfticu"; + interrupt-controller; + #interrupt-cells = <2>; + reg = <3 0 0x100>; + interrupt-parent = <&mpic>; + interrupts = <6 1 0 0>; + }; diff --git a/Documentation/devicetree/bindings/mfd/qriox.txt b/Documentation/devicetree/bindings/mfd/qriox.txt new file mode 100644 index 0000000..f301e2d --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/qriox.txt @@ -0,0 +1,17 @@ +KEYMILE qrio Board Control CPLD + +The qrio is a multifunction device that controls the KEYMILE boards based on +the kmp204x design. +It is consists of a reset controller, watchdog timer, LEDs, and 2 IRQ capable +GPIO blocks. + +Required properties: +- compatible: "keymile,qriox" +- reg: access on the parent local bus (chip select, offset in chip select, size) + +Example: + + board-control@1,0 { + compatible = "keymile,qriox"; + reg = <1 0 0x80>; + }; -- cgit v1.1 From eaf76b2142d65f97380282b00709e1963d9aee1c Mon Sep 17 00:00:00 2001 From: Tang Yuantian Date: Thu, 8 May 2014 11:12:10 +0800 Subject: clk: qoriq: Update the clock bindings Main changs include: - Clarified the clock nodes' version number - Fixed a issue in example Singed-off-by: Tang Yuantian Signed-off-by: Scott Wood --- .../devicetree/bindings/clock/corenet-clock.txt | 134 ------------------- .../devicetree/bindings/clock/qoriq-clock.txt | 142 +++++++++++++++++++++ 2 files changed, 142 insertions(+), 134 deletions(-) delete mode 100644 Documentation/devicetree/bindings/clock/corenet-clock.txt create mode 100644 Documentation/devicetree/bindings/clock/qoriq-clock.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/corenet-clock.txt b/Documentation/devicetree/bindings/clock/corenet-clock.txt deleted file mode 100644 index 24711af..0000000 --- a/Documentation/devicetree/bindings/clock/corenet-clock.txt +++ /dev/null @@ -1,134 +0,0 @@ -* Clock Block on Freescale CoreNet Platforms - -Freescale CoreNet chips take primary clocking input from the external -SYSCLK signal. The SYSCLK input (frequency) is multiplied using -multiple phase locked loops (PLL) to create a variety of frequencies -which can then be passed to a variety of internal logic, including -cores and peripheral IP blocks. -Please refer to the Reference Manual for details. - -1. Clock Block Binding - -Required properties: -- compatible: Should contain a specific clock block compatible string - and a single chassis clock compatible string. - Clock block strings include, but not limited to, one of the: - * "fsl,p2041-clockgen" - * "fsl,p3041-clockgen" - * "fsl,p4080-clockgen" - * "fsl,p5020-clockgen" - * "fsl,p5040-clockgen" - * "fsl,t4240-clockgen" - * "fsl,b4420-clockgen" - * "fsl,b4860-clockgen" - Chassis clock strings include: - * "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks - * "fsl,qoriq-clockgen-2.0": for chassis 2.0 clocks -- reg: Describes the address of the device's resources within the - address space defined by its parent bus, and resource zero - represents the clock register set -- clock-frequency: Input system clock frequency - -Recommended properties: -- ranges: Allows valid translation between child's address space and - parent's. Must be present if the device has sub-nodes. -- #address-cells: Specifies the number of cells used to represent - physical base addresses. Must be present if the device has - sub-nodes and set to 1 if present -- #size-cells: Specifies the number of cells used to represent - the size of an address. Must be present if the device has - sub-nodes and set to 1 if present - -2. Clock Provider/Consumer Binding - -Most of the bindings are from the common clock binding[1]. - [1] Documentation/devicetree/bindings/clock/clock-bindings.txt - -Required properties: -- compatible : Should include one of the following: - * "fsl,qoriq-core-pll-1.0" for core PLL clocks (v1.0) - * "fsl,qoriq-core-pll-2.0" for core PLL clocks (v2.0) - * "fsl,qoriq-core-mux-1.0" for core mux clocks (v1.0) - * "fsl,qoriq-core-mux-2.0" for core mux clocks (v2.0) - * "fsl,qoriq-sysclk-1.0": for input system clock (v1.0). - It takes parent's clock-frequency as its clock. - * "fsl,qoriq-sysclk-2.0": for input system clock (v2.0). - It takes parent's clock-frequency as its clock. -- #clock-cells: From common clock binding. The number of cells in a - clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0" - clocks, or <1> for "fsl,qoriq-core-pll-[1,2].0" clocks. - For "fsl,qoriq-core-pll-[1,2].0" clocks, the single - clock-specifier cell may take the following values: - * 0 - equal to the PLL frequency - * 1 - equal to the PLL frequency divided by 2 - * 2 - equal to the PLL frequency divided by 4 - -Recommended properties: -- clocks: Should be the phandle of input parent clock -- clock-names: From common clock binding, indicates the clock name -- clock-output-names: From common clock binding, indicates the names of - output clocks -- reg: Should be the offset and length of clock block base address. - The length should be 4. - -Example for clock block and clock provider: -/ { - clockgen: global-utilities@e1000 { - compatible = "fsl,p5020-clockgen", "fsl,qoriq-clockgen-1.0"; - ranges = <0x0 0xe1000 0x1000>; - clock-frequency = <133333333>; - reg = <0xe1000 0x1000>; - #address-cells = <1>; - #size-cells = <1>; - - sysclk: sysclk { - #clock-cells = <0>; - compatible = "fsl,qoriq-sysclk-1.0"; - clock-output-names = "sysclk"; - } - - pll0: pll0@800 { - #clock-cells = <1>; - reg = <0x800 0x4>; - compatible = "fsl,qoriq-core-pll-1.0"; - clocks = <&sysclk>; - clock-output-names = "pll0", "pll0-div2"; - }; - - pll1: pll1@820 { - #clock-cells = <1>; - reg = <0x820 0x4>; - compatible = "fsl,qoriq-core-pll-1.0"; - clocks = <&sysclk>; - clock-output-names = "pll1", "pll1-div2"; - }; - - mux0: mux0@0 { - #clock-cells = <0>; - reg = <0x0 0x4>; - compatible = "fsl,qoriq-core-mux-1.0"; - clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>; - clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2"; - clock-output-names = "cmux0"; - }; - - mux1: mux1@20 { - #clock-cells = <0>; - reg = <0x20 0x4>; - compatible = "fsl,qoriq-core-mux-1.0"; - clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>; - clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2"; - clock-output-names = "cmux1"; - }; - }; - } - -Example for clock consumer: - -/ { - cpu0: PowerPC,e5500@0 { - ... - clocks = <&mux0>; - ... - }; - } diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt b/Documentation/devicetree/bindings/clock/qoriq-clock.txt new file mode 100644 index 0000000..5666812 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt @@ -0,0 +1,142 @@ +* Clock Block on Freescale CoreNet Platforms + +Freescale CoreNet chips take primary clocking input from the external +SYSCLK signal. The SYSCLK input (frequency) is multiplied using +multiple phase locked loops (PLL) to create a variety of frequencies +which can then be passed to a variety of internal logic, including +cores and peripheral IP blocks. +Please refer to the Reference Manual for details. + +All references to "1.0" and "2.0" refer to the QorIQ chassis version to +which the chip complies. + +Chassis Version Example Chips +--------------- ------------- +1.0 p4080, p5020, p5040 +2.0 t4240, b4860, t1040 + +1. Clock Block Binding + +Required properties: +- compatible: Should contain a specific clock block compatible string + and a single chassis clock compatible string. + Clock block strings include, but not limited to, one of the: + * "fsl,p2041-clockgen" + * "fsl,p3041-clockgen" + * "fsl,p4080-clockgen" + * "fsl,p5020-clockgen" + * "fsl,p5040-clockgen" + * "fsl,t4240-clockgen" + * "fsl,b4420-clockgen" + * "fsl,b4860-clockgen" + Chassis clock strings include: + * "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks + * "fsl,qoriq-clockgen-2.0": for chassis 2.0 clocks +- reg: Describes the address of the device's resources within the + address space defined by its parent bus, and resource zero + represents the clock register set +- clock-frequency: Input system clock frequency + +Recommended properties: +- ranges: Allows valid translation between child's address space and + parent's. Must be present if the device has sub-nodes. +- #address-cells: Specifies the number of cells used to represent + physical base addresses. Must be present if the device has + sub-nodes and set to 1 if present +- #size-cells: Specifies the number of cells used to represent + the size of an address. Must be present if the device has + sub-nodes and set to 1 if present + +2. Clock Provider/Consumer Binding + +Most of the bindings are from the common clock binding[1]. + [1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- compatible : Should include one of the following: + * "fsl,qoriq-core-pll-1.0" for core PLL clocks (v1.0) + * "fsl,qoriq-core-pll-2.0" for core PLL clocks (v2.0) + * "fsl,qoriq-core-mux-1.0" for core mux clocks (v1.0) + * "fsl,qoriq-core-mux-2.0" for core mux clocks (v2.0) + * "fsl,qoriq-sysclk-1.0": for input system clock (v1.0). + It takes parent's clock-frequency as its clock. + * "fsl,qoriq-sysclk-2.0": for input system clock (v2.0). + It takes parent's clock-frequency as its clock. +- #clock-cells: From common clock binding. The number of cells in a + clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0" + clocks, or <1> for "fsl,qoriq-core-pll-[1,2].0" clocks. + For "fsl,qoriq-core-pll-[1,2].0" clocks, the single + clock-specifier cell may take the following values: + * 0 - equal to the PLL frequency + * 1 - equal to the PLL frequency divided by 2 + * 2 - equal to the PLL frequency divided by 4 + +Recommended properties: +- clocks: Should be the phandle of input parent clock +- clock-names: From common clock binding, indicates the clock name +- clock-output-names: From common clock binding, indicates the names of + output clocks +- reg: Should be the offset and length of clock block base address. + The length should be 4. + +Example for clock block and clock provider: +/ { + clockgen: global-utilities@e1000 { + compatible = "fsl,p5020-clockgen", "fsl,qoriq-clockgen-1.0"; + ranges = <0x0 0xe1000 0x1000>; + clock-frequency = <133333333>; + reg = <0xe1000 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + + sysclk: sysclk { + #clock-cells = <0>; + compatible = "fsl,qoriq-sysclk-1.0"; + clock-output-names = "sysclk"; + }; + + pll0: pll0@800 { + #clock-cells = <1>; + reg = <0x800 0x4>; + compatible = "fsl,qoriq-core-pll-1.0"; + clocks = <&sysclk>; + clock-output-names = "pll0", "pll0-div2"; + }; + + pll1: pll1@820 { + #clock-cells = <1>; + reg = <0x820 0x4>; + compatible = "fsl,qoriq-core-pll-1.0"; + clocks = <&sysclk>; + clock-output-names = "pll1", "pll1-div2"; + }; + + mux0: mux0@0 { + #clock-cells = <0>; + reg = <0x0 0x4>; + compatible = "fsl,qoriq-core-mux-1.0"; + clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>; + clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2"; + clock-output-names = "cmux0"; + }; + + mux1: mux1@20 { + #clock-cells = <0>; + reg = <0x20 0x4>; + compatible = "fsl,qoriq-core-mux-1.0"; + clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>; + clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2"; + clock-output-names = "cmux1"; + }; + }; + } + +Example for clock consumer: + +/ { + cpu0: PowerPC,e5500@0 { + ... + clocks = <&mux0>; + ... + }; + } -- cgit v1.1 From 385510beda1da138f2f725abd351c16e370427f1 Mon Sep 17 00:00:00 2001 From: Diana Craciun Date: Mon, 5 May 2014 18:58:19 +0300 Subject: powerpc/fsl: Added binding for Freescale CoreNet coherency fabric (CCF) The CoreNet coherency fabric is a fabric-oriented, conectivity infrastructure that enables the implementation of coherent, multicore systems. The CCF acts as a central interconnect for cores, platform-level caches, memory subsystem, peripheral devices and I/O host bridges in the system. Signed-off-by: Diana Craciun [scottwood@freescale.com: formatting and minor changes] Signed-off-by: Scott Wood --- .../devicetree/bindings/powerpc/fsl/ccf.txt | 46 ++++++++++++++++++++++ .../devicetree/bindings/powerpc/fsl/cpus.txt | 11 ++++++ .../devicetree/bindings/powerpc/fsl/pamu.txt | 10 +++++ 3 files changed, 67 insertions(+) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/ccf.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ccf.txt b/Documentation/devicetree/bindings/powerpc/fsl/ccf.txt new file mode 100644 index 0000000..454da7e --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/fsl/ccf.txt @@ -0,0 +1,46 @@ +Freescale CoreNet Coherency Fabric(CCF) Device Tree Binding + +DESCRIPTION + +The CoreNet coherency fabric is a fabric-oriented, connectivity infrastructure +that enables the implementation of coherent, multicore systems. + +Required properties: + +- compatible: + fsl,corenet1-cf - CoreNet coherency fabric version 1. + Example chips: T4240, B4860 + + fsl,corenet2-cf - CoreNet coherency fabric version 2. + Example chips: P5040, P5020, P4080, P3041, P2041 + + fsl,corenet-cf - Used to represent the common registers + between CCF version 1 and CCF version 2. This compatible + is retained for compatibility reasons, as it was already + used for both CCF version 1 chips and CCF version 2 + chips. It should be specified after either + "fsl,corenet1-cf" or "fsl,corenet2-cf". + +- reg: + A standard property. Represents the CCF registers. + +- interrupts: + Interrupt mapping for CCF error interrupt. + +- fsl,ccf-num-csdids: + Specifies the number of Coherency Subdomain ID Port Mapping + Registers that are supported by the CCF. + +- fsl,ccf-num-snoopids: + Specifies the number of Snoop ID Port Mapping Registers that + are supported by CCF. + +Example: + + corenet-cf@18000 { + compatible = "fsl,corenet2-cf", "fsl,corenet-cf"; + reg = <0x18000 0x1000>; + interrupts = <16 2 1 31>; + fsl,ccf-num-csdids = <32>; + fsl,ccf-num-snoopids = <32>; + }; diff --git a/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt index 922c30a..f8cd239 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt @@ -20,3 +20,14 @@ PROPERTIES a property named fsl,eref-[CAT], where [CAT] is the abbreviated category name with all uppercase letters converted to lowercase, indicates that the category is supported by the implementation. + + - fsl,portid-mapping + Usage: optional + Value type: + Definition: The Coherency Subdomain ID Port Mapping Registers and + Snoop ID Port Mapping registers, which are part of the CoreNet + Coherency fabric (CCF), provide a CoreNet Coherency Subdomain + ID/CoreNet Snoop ID to cpu mapping functions. Certain bits from + these registers should be set if the coresponding CPU should be + snooped. This property defines a bitmask which selects the bit + that should be set if this cpu should be snooped. diff --git a/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt b/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt index 1f5e329..c2b2899 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt @@ -34,6 +34,15 @@ Optional properties: for legacy drivers. - interrupt-parent : Phandle to interrupt controller +- fsl,portid-mapping : + The Coherency Subdomain ID Port Mapping Registers and + Snoop ID Port Mapping registers, which are part of the + CoreNet Coherency fabric (CCF), provide a CoreNet + Coherency Subdomain ID/CoreNet Snoop ID to pamu mapping + functions. Certain bits from these registers should be + set if PAMUs should be snooped. This property defines + a bitmask which selects the bits that should be set if + PAMUs should be snooped. Child nodes: @@ -88,6 +97,7 @@ Example: compatible = "fsl,pamu-v1.0", "fsl,pamu"; reg = <0x20000 0x5000>; ranges = <0 0x20000 0x5000>; + fsl,portid-mapping = <0xf80000>; #address-cells = <1>; #size-cells = <1>; interrupts = < -- cgit v1.1 From 1be62c6cced607ee870e45512d021f0d6bd1a6c7 Mon Sep 17 00:00:00 2001 From: harninder rai Date: Thu, 15 May 2014 13:15:33 +0530 Subject: powerpc/mpc85xx: Add BSC9132 QDS Support - BSC9132 is an integrated device that targets Femto base station market. It combines Power Architecture e500v2 and DSP StarCore SC3850 technologies with MAPLE-B2F baseband acceleration processing elements - BSC9132QDS Overview 2Gbyte DDR3 (on board DDR) 32Mbyte 16bit NOR flash 128Mbyte 2K page size NAND Flash 256 Kbit M24256 I2C EEPROM 128 Mbit SPI Flash memory SD slot eTSEC1: Connected to SGMII PHY eTSEC2: Connected to SGMII PHY DUART interface: supports one UARTs up to 115200 bps for console display Signed-off-by: Harninder Rai Signed-off-by: Ruchika Gupta Signed-off-by: Scott Wood --- Documentation/devicetree/bindings/powerpc/fsl/board.txt | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt b/Documentation/devicetree/bindings/powerpc/fsl/board.txt index 380914e..700dec4 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt @@ -67,3 +67,20 @@ Example: gpio-controller; }; }; + +* Freescale on-board FPGA connected on I2C bus + +Some Freescale boards like BSC9132QDS have on board FPGA connected on +the i2c bus. + +Required properties: +- compatible: Should be a board-specific string followed by a string + indicating the type of FPGA. Example: + "fsl,-fpga", "fsl,fpga-qixis-i2c" +- reg: Should contain the address of the FPGA + +Example: + fpga: fpga@66 { + compatible = "fsl,bsc9132qds-fpga", "fsl,fpga-qixis-i2c"; + reg = <0x66>; + }; -- cgit v1.1 From a33d8ce729f670e1618eb3faa76246b61128008e Mon Sep 17 00:00:00 2001 From: "Ivan T. Ivanov" Date: Sun, 4 May 2014 09:24:40 +0800 Subject: usb: chipidea: msm: Add device tree binding information Document device tree binding information as required by the Qualcomm USB controller. Signed-off-by: Peter Chen Signed-off-by: Ivan T. Ivanov Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/ci-hdrc-qcom.txt | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-qcom.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-qcom.txt b/Documentation/devicetree/bindings/usb/ci-hdrc-qcom.txt new file mode 100644 index 0000000..f2899b5 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-qcom.txt @@ -0,0 +1,17 @@ +Qualcomm CI13xxx (Chipidea) USB controllers + +Required properties: +- compatible: should contain "qcom,ci-hdrc" +- reg: offset and length of the register set in the memory map +- interrupts: interrupt-specifier for the controller interrupt. +- usb-phy: phandle for the PHY device +- dr_mode: Should be "peripheral" + +Examples: + gadget@f9a55000 { + compatible = "qcom,ci-hdrc"; + reg = <0xf9a55000 0x400>; + dr_mode = "peripheral"; + interrupts = <0 134 0>; + usb-phy = <&usbphy0>; + }; -- cgit v1.1 From ec447ab138e033ad96a8c6649bce51ecdcc0abe0 Mon Sep 17 00:00:00 2001 From: Peter Chen Date: Sun, 4 May 2014 09:24:43 +0800 Subject: Doc: usb: chipidea: need to build both kernel Image and modules When tried to enable OTG FSM, we need to rebuild both kernel Image and modules, since there are some codes at gadget modules which are controlled by related configurations. Signed-off-by: Peter Chen Signed-off-by: Greg Kroah-Hartman --- Documentation/usb/chipidea.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/usb/chipidea.txt b/Documentation/usb/chipidea.txt index 4c0e2ea..995c8bc 100644 --- a/Documentation/usb/chipidea.txt +++ b/Documentation/usb/chipidea.txt @@ -5,7 +5,7 @@ with 2 Freescale i.MX6Q sabre SD boards. 1.1 How to enable OTG FSM in menuconfig --------------------------------------- -Select CONFIG_USB_OTG_FSM. +Select CONFIG_USB_OTG_FSM, rebuild kernel Image and modules. If you want to check some internal variables for otg fsm, select CONFIG_USB_CHIPIDEA_DEBUG, there are 2 files which can show otg fsm variables and some controller registers value: -- cgit v1.1 From c675a00c2d666c8e90da335eafbbae81201d53f7 Mon Sep 17 00:00:00 2001 From: Anders Berg Date: Thu, 15 May 2014 15:42:25 +0200 Subject: clk: Add clock driver for AXM55xx SoC Add clk driver to support clock blocks found on the AXM55xx devices. The driver provides clock implementations for three different types of clock devices on the AXM55xx device: PLL clock, a clock divider and a clock mux. Signed-off-by: Anders Berg Cc: Mark Rutland Signed-off-by: Mike Turquette --- .../devicetree/bindings/clock/lsi,axm5516-clks.txt | 29 ++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/lsi,axm5516-clks.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/lsi,axm5516-clks.txt b/Documentation/devicetree/bindings/clock/lsi,axm5516-clks.txt new file mode 100644 index 0000000..3ce97cf --- /dev/null +++ b/Documentation/devicetree/bindings/clock/lsi,axm5516-clks.txt @@ -0,0 +1,29 @@ +AXM5516 clock driver bindings +----------------------------- + +Required properties : +- compatible : shall contain "lsi,axm5516-clks" +- reg : shall contain base register location and length +- #clock-cells : shall contain 1 + +The consumer specifies the desired clock by having the clock ID in its "clocks" +phandle cell. See for the list of +supported clock IDs. + +Example: + + clks: clock-controller@2010020000 { + compatible = "lsi,axm5516-clks"; + #clock-cells = <1>; + reg = <0x20 0x10020000 0 0x20000>; + }; + + serial0: uart@2010080000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x20 0x10080000 0 0x1000>; + interrupts = ; + clocks = <&clks AXXIA_CLK_PER>; + clock-names = "apb_pclk"; + }; + }; + -- cgit v1.1 From 12e499d0ed1fa09940a573e5a8cce52b556f3c38 Mon Sep 17 00:00:00 2001 From: Xiubo Li Date: Fri, 23 May 2014 10:12:04 +0200 Subject: clocksource: ftm: Add FlexTimer Module (FTM) Timer devicetree Documentation The FTM binding could be used on Vybrid and LS1+, add a binding document for it. Signed-off-by: Xiubo Li Cc: Shawn Guo Cc: Jingchang Lu Signed-off-by: Daniel Lezcano --- .../devicetree/bindings/timer/fsl,ftm-timer.txt | 31 ++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt new file mode 100644 index 0000000..aa8c402 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt @@ -0,0 +1,31 @@ +Freescale FlexTimer Module (FTM) Timer + +Required properties: + +- compatible : should be "fsl,ftm-timer" +- reg : Specifies base physical address and size of the register sets for the + clock event device and clock source device. +- interrupts : Should be the clock event device interrupt. +- clocks : The clocks provided by the SoC to drive the timer, must contain an + entry for each entry in clock-names. +- clock-names : Must include the following entries: + o "ftm-evt" + o "ftm-src" + o "ftm-evt-counter-en" + o "ftm-src-counter-en" +- big-endian: One boolean property, the big endian mode will be in use if it is + present, or the little endian mode will be in use for all the device registers. + +Example: +ftm: ftm@400b8000 { + compatible = "fsl,ftm-timer"; + reg = <0x400b8000 0x1000 0x400b9000 0x1000>; + interrupts = <0 44 IRQ_TYPE_LEVEL_HIGH>; + clock-names = "ftm-evt", "ftm-src", + "ftm-evt-counter-en", "ftm-src-counter-en"; + clocks = <&clks VF610_CLK_FTM2>, + <&clks VF610_CLK_FTM3>, + <&clks VF610_CLK_FTM2_EXT_FIX_EN>, + <&clks VF610_CLK_FTM3_EXT_FIX_EN>; + big-endian; +}; -- cgit v1.1 From 1f154fadb102495747a25b5a64b4f388f941303e Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Fri, 23 May 2014 10:34:35 +0200 Subject: of: dma: doc fixes Signed-off-by: Geert Uytterhoeven Signed-off-by: Jiri Kosina --- Documentation/devicetree/bindings/dma/dma.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/dma.txt b/Documentation/devicetree/bindings/dma/dma.txt index 8f504e6..8210427 100644 --- a/Documentation/devicetree/bindings/dma/dma.txt +++ b/Documentation/devicetree/bindings/dma/dma.txt @@ -14,7 +14,7 @@ Required property: Optional properties: - dma-channels: Number of DMA channels supported by the controller. -- dma-requests: Number of DMA requests signals supported by the +- dma-requests: Number of DMA request signals supported by the controller. Example: @@ -44,7 +44,7 @@ Required property: #dma-cells property in the node referenced by phandle containing DMA controller specific information. This typically contains a DMA request line number or a - channel number, but can contain any data that is used + channel number, but can contain any data that is required for configuring a channel. - dma-names: Contains one identifier string for each DMA specifier in the dmas property. The specific strings that can be used -- cgit v1.1 From 51caa05a82df2501fdf1e3cd97e7c74befe48729 Mon Sep 17 00:00:00 2001 From: Jarkko Nikula Date: Wed, 21 May 2014 16:58:25 +0300 Subject: Documentation / ACPI: Fix location of GPIO documentation Commit fd8e198cfcaa ("Documentation: gpiolib: document new interface") moved Documentation/gpio.txt to Documentation/gpio/gpio-legacy.txt and added new documents for descriptor-based interface so fix the the location here to point Documentation/gpio/ since that what commit ccb6fbb99020 ("Documentation / ACPI: update to GPIO descriptor API") was looking for. Signed-off-by: Jarkko Nikula Acked-by: Mika Westerberg Signed-off-by: Linus Walleij --- Documentation/acpi/enumeration.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt index 2a1519b..fd786ea 100644 --- a/Documentation/acpi/enumeration.txt +++ b/Documentation/acpi/enumeration.txt @@ -296,7 +296,7 @@ specifies the path to the controller. In order to use these GPIOs in Linux we need to translate them to the corresponding Linux GPIO descriptors. There is a standard GPIO API for that and is documented in -Documentation/gpio.txt. +Documentation/gpio/. In the above example we can get the corresponding two GPIO descriptors with a code like this: -- cgit v1.1 From 3130a28a1568b1e447fbbbb5307573e0e4043bb3 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Wed, 23 Apr 2014 11:32:11 -0300 Subject: [media] v4l2-pci-skeleton: fix typo Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/v4l2-pci-skeleton.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/v4l2-pci-skeleton.c b/Documentation/video4linux/v4l2-pci-skeleton.c index 53dd346..46904fe 100644 --- a/Documentation/video4linux/v4l2-pci-skeleton.c +++ b/Documentation/video4linux/v4l2-pci-skeleton.c @@ -174,7 +174,7 @@ static int queue_setup(struct vb2_queue *vq, const struct v4l2_format *fmt, * You cannot use read() with FIELD_ALTERNATE since the field * information (TOP/BOTTOM) cannot be passed back to the user. */ - if (vb2_fileio_is_active(q)) + if (vb2_fileio_is_active(vq)) return -EINVAL; skel->field = V4L2_FIELD_TOP; } -- cgit v1.1 From 1d22924e1c4e299337e86e290c02c3e3eb43b608 Mon Sep 17 00:00:00 2001 From: Anders Berg Date: Fri, 23 May 2014 11:08:35 +0200 Subject: ARM: Add platform support for LSI AXM55xx SoC The AXM55xx family consists of devices that may contain up to 16 ARM Cortex-A15 cores (in a 4x4 cluster configuration). The cores within each cluster share an L2 cache, and the clusters are connected to each other via a CCN-504 cache coherent interconnect. This machine requires CONFIG_ARM_LPAE enabled as all peripherals are located above 4GB in the memory map. Signed-off-by: Anders Berg Acked-by: Linus Walleij Signed-off-by: Arnd Bergmann --- Documentation/devicetree/bindings/arm/axxia.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/axxia.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/axxia.txt b/Documentation/devicetree/bindings/arm/axxia.txt new file mode 100644 index 0000000..7b4ef9c --- /dev/null +++ b/Documentation/devicetree/bindings/arm/axxia.txt @@ -0,0 +1,12 @@ +Axxia AXM55xx device tree bindings + +Boards using the AXM55xx SoC need to have the following properties: + +Required root node property: + + - compatible = "lsi,axm5516" + +Boards: + + LSI AXM5516 Validation board (Amarillo) + compatible = "lsi,axm5516-amarillo", "lsi,axm5516" -- cgit v1.1 From 4a315e3457e008e0570c392822ae98cdf7761227 Mon Sep 17 00:00:00 2001 From: Anders Berg Date: Fri, 23 May 2014 11:08:38 +0200 Subject: power: reset: Add Axxia system reset driver Add Axxia (AXM55xx) SoC system reset driver. This driver handles only system reboot (and not power-off). Signed-off-by: Anders Berg Cc: Dmitry Eremin-Solenikov Cc: David Woodhouse Acked-by: Linus Walleij Signed-off-by: Arnd Bergmann --- .../devicetree/bindings/power_supply/axxia-reset.txt | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 Documentation/devicetree/bindings/power_supply/axxia-reset.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power_supply/axxia-reset.txt b/Documentation/devicetree/bindings/power_supply/axxia-reset.txt new file mode 100644 index 0000000..47e720d --- /dev/null +++ b/Documentation/devicetree/bindings/power_supply/axxia-reset.txt @@ -0,0 +1,20 @@ +Axxia Restart Driver + +This driver can do reset of the Axxia SoC. It uses the registers in the syscon +block to initiate a chip reset. + +Required Properties: + -compatible: "lsi,axm55xx-reset" + -syscon: phandle to the syscon node. + +Example: + + syscon: syscon@2010030000 { + compatible = "lsi,axxia-syscon", "syscon"; + reg = <0x20 0x10030000 0 0x2000>; + }; + + reset: reset@2010031000 { + compatible = "lsi,axm55xx-reset"; + syscon = <&syscon>; + }; -- cgit v1.1 From e60cbeedc48d80689c249ab5dcc3c31ad0452dea Mon Sep 17 00:00:00 2001 From: Johannes Berg Date: Thu, 22 May 2014 11:54:23 -0700 Subject: Documentation: fix DOCBOOKS=... building Prior to commit 4266129964b8 ("[media] DocBook: Move all media docbook stuff into its own directory") it was possible to build only a single (or more) book(s) by calling, for example make htmldocs DOCBOOKS=80211.xml This now fails: cp: target `.../Documentation/DocBook//media_api' is not a directory Ignore errors from that copy to make this possible again. Fixes: 4266129964b8 ("[media] DocBook: Move all media docbook stuff into its own directory") Signed-off-by: Johannes Berg Acked-by: Randy Dunlap Cc: Mauro Carvalho Chehab Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/DocBook/media/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/Makefile b/Documentation/DocBook/media/Makefile index f9fd615..1d27f0a 100644 --- a/Documentation/DocBook/media/Makefile +++ b/Documentation/DocBook/media/Makefile @@ -195,7 +195,7 @@ DVB_DOCUMENTED = \ # install_media_images = \ - $(Q)cp $(OBJIMGFILES) $(MEDIA_SRC_DIR)/v4l/*.svg $(MEDIA_OBJ_DIR)/media_api + $(Q)-cp $(OBJIMGFILES) $(MEDIA_SRC_DIR)/v4l/*.svg $(MEDIA_OBJ_DIR)/media_api $(MEDIA_OBJ_DIR)/%: $(MEDIA_SRC_DIR)/%.b64 $(Q)base64 -d $< >$@ -- cgit v1.1 From 08f9234ad6b0b8bc51046346eabf5b92e631e62a Mon Sep 17 00:00:00 2001 From: Andy Gross Date: Thu, 24 Apr 2014 11:31:20 -0500 Subject: soc: qcom: Add device tree binding for GSBI Add device tree binding support for the QCOM GSBI driver. Signed-off-by: Andy Gross Signed-off-by: Kumar Gala --- .../devicetree/bindings/soc/qcom/qcom,gsbi.txt | 78 ++++++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt new file mode 100644 index 0000000..4ce24d4 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt @@ -0,0 +1,78 @@ +QCOM GSBI (General Serial Bus Interface) Driver + +The GSBI controller is modeled as a node with zero or more child nodes, each +representing a serial sub-node device that is mux'd as part of the GSBI +configuration settings. The mode setting will govern the input/output mode of +the 4 GSBI IOs. + +Required properties: +- compatible: must contain "qcom,gsbi-v1.0.0" for APQ8064/IPQ8064 +- reg: Address range for GSBI registers +- clocks: required clock +- clock-names: must contain "iface" entry +- qcom,mode : indicates MUX value for configuration of the serial interface. + Please reference dt-bindings/soc/qcom,gsbi.h for valid mux values. + +Optional properties: +- qcom,crci : indicates CRCI MUX value for QUP CRCI ports. Please reference + dt-bindings/soc/qcom,gsbi.h for valid CRCI mux values. + +Required properties if child node exists: +- #address-cells: Must be 1 +- #size-cells: Must be 1 +- ranges: Must be present + +Properties for children: + +A GSBI controller node can contain 0 or more child nodes representing serial +devices. These serial devices can be a QCOM UART, I2C controller, spi +controller, or some combination of aforementioned devices. + +See the following for child node definitions: +Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt +Documentation/devicetree/bindings/spi/qcom,spi-qup.txt +Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt + +Example for APQ8064: + +#include + + gsbi4@16300000 { + compatible = "qcom,gsbi-v1.0.0"; + reg = <0x16300000 0x100>; + clocks = <&gcc GSBI4_H_CLK>; + clock-names = "iface"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + qcom,mode = ; + qcom,crci = ; + + /* child nodes go under here */ + + i2c_qup4: i2c@16380000 { + compatible = "qcom,i2c-qup-v1.1.1"; + reg = <0x16380000 0x1000>; + interrupts = <0 153 0>; + + clocks = <&gcc GSBI4_QUP_CLK>, <&gcc GSBI4_H_CLK>; + clock-names = "core", "iface"; + + clock-frequency = <200000>; + + #address-cells = <1>; + #size-cells = <0>; + + }; + + uart4: serial@16340000 { + compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm"; + reg = <0x16340000 0x1000>, + <0x16300000 0x1000>; + interrupts = <0 152 0x0>; + clocks = <&gcc GSBI4_UART_CLK>, <&gcc GSBI4_H_CLK>; + clock-names = "core", "iface"; + status = "ok"; + }; + }; + -- cgit v1.1 From 43339bed7010da6e7cf797db3216a136a974a0cd Mon Sep 17 00:00:00 2001 From: Eli Billauer Date: Fri, 16 May 2014 11:26:35 +0300 Subject: devres: Add devm_get_free_pages API devm_get_free_pages() and devm_free_pages() are the managed counterparts for __get_free_pages() and free_pages(). Signed-off-by: Eli Billauer Acked-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-model/devres.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt index 4999518..e1a2707 100644 --- a/Documentation/driver-model/devres.txt +++ b/Documentation/driver-model/devres.txt @@ -237,6 +237,8 @@ MEM devm_kzalloc() devm_kfree() devm_kmemdup() + devm_get_free_pages() + devm_free_pages() IIO devm_iio_device_alloc() -- cgit v1.1 From e2b9deb2ad34c9ca6e11a6193bf29088716c2b62 Mon Sep 17 00:00:00 2001 From: Kiran AVND Date: Mon, 19 May 2014 09:50:01 -0300 Subject: [media] s5p-mfc: Core support to add v8 decoder This patch adds variant data and core support for V8 decoder. This patch also adds the register definition file for new firmware version v8 for MFC. Signed-off-by: Kiran AVND Signed-off-by: Pawel Osciak Signed-off-by: Arun Kumar K [k.debski@samsung.com: Change MFC version macro name to MFC_V8_BIT] Signed-off-by: Kamil Debski Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/s5p-mfc.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt index f418168..3e3c5f3 100644 --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt @@ -10,7 +10,8 @@ Required properties: - compatible : value should be either one among the following (a) "samsung,mfc-v5" for MFC v5 present in Exynos4 SoCs (b) "samsung,mfc-v6" for MFC v6 present in Exynos5 SoCs - (b) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC + (c) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC + (d) "samsung,mfc-v8" for MFC v8 present in Exynos5800 SoC - reg : Physical base address of the IP registers and length of memory mapped region. -- cgit v1.1 From 1923ca92a618b6107d3a44b5c9f9360b104dcddb Mon Sep 17 00:00:00 2001 From: Ulrich Hecht Date: Fri, 23 May 2014 15:27:15 +0200 Subject: clk: shmobile: Add R8A7740-specific clock support Driver for the R8A7740's clocks that are too specific to be supported by a generic driver. Signed-off-by: Ulrich Hecht Acked-by: Geert Uytterhoeven Acked-by: Laurent Pinchart Signed-off-by: Mike Turquette --- .../bindings/clock/renesas,r8a7740-cpg-clocks.txt | 41 ++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/renesas,r8a7740-cpg-clocks.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/renesas,r8a7740-cpg-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,r8a7740-cpg-clocks.txt new file mode 100644 index 0000000..2c03302 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,r8a7740-cpg-clocks.txt @@ -0,0 +1,41 @@ +These bindings should be considered EXPERIMENTAL for now. + +* Renesas R8A7740 Clock Pulse Generator (CPG) + +The CPG generates core clocks for the R8A7740 SoC. It includes three PLLs +and several fixed ratio and variable ratio dividers. + +Required Properties: + + - compatible: Must be "renesas,r8a7740-cpg-clocks" + + - reg: Base address and length of the memory resource used by the CPG + + - clocks: Reference to the three parent clocks + - #clock-cells: Must be 1 + - clock-output-names: The names of the clocks. Supported clocks are + "system", "pllc0", "pllc1", "pllc2", "r", "usb24s", "i", "zg", "b", + "m1", "hp", "hpp", "usbp", "s", "zb", "m3", and "cp". + + - renesas,mode: board-specific settings of the MD_CK* bits + + +Example +------- + +cpg_clocks: cpg_clocks@e6150000 { + compatible = "renesas,r8a7740-cpg-clocks"; + reg = <0xe6150000 0x10000>; + clocks = <&extal1_clk>, <&extal2_clk>, <&extalr_clk>; + #clock-cells = <1>; + clock-output-names = "system", "pllc0", "pllc1", + "pllc2", "r", + "usb24s", + "i", "zg", "b", "m1", "hp", + "hpp", "usbp", "s", "zb", "m3", + "cp"; +}; + +&cpg_clocks { + renesas,mode = <0x05>; +}; -- cgit v1.1 From 04caa489301c5e01ac4e5d1c13abcecb2041300b Mon Sep 17 00:00:00 2001 From: Daniel Borkmann Date: Fri, 23 May 2014 18:43:59 +0200 Subject: net: filter: doc: add section for BPF test suite Mention the recently added test suite in the documentation file. Signed-off-by: Daniel Borkmann Acked-by: Alexei Starovoitov Signed-off-by: David S. Miller --- Documentation/networking/filter.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt index 748fd38..dc7dcc8 100644 --- a/Documentation/networking/filter.txt +++ b/Documentation/networking/filter.txt @@ -833,6 +833,20 @@ loops and other CFG validation; second step starts from the first insn and descends all possible paths. It simulates execution of every insn and observes the state change of registers and stack. +Testing +------- + +Next to the BPF toolchain, the kernel also ships a test module that contains +various test cases for classic and internal BPF that can be executed against +the BPF interpreter and JIT compiler. It can be found in lib/test_bpf.c and +enabled via Kconfig: + + CONFIG_TEST_BPF=m + +After the module has been built and installed, the test suite can be executed +via insmod or modprobe against 'test_bpf' module. Results of the test cases +including timings in nsec can be found in the kernel log (dmesg). + Misc ---- -- cgit v1.1 From 49b2f4c56fbf70ca693d6df1c491f0566d516aea Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki Date: Tue, 15 Apr 2014 08:35:25 -0300 Subject: [media] exynos4-is: Remove support for non-dt platforms All platforms supported by this driver are going to get device tree support in this kernel release so remove code that would have been actually not used any more. Signed-off-by: Sylwester Nawrocki Acked-by: Kyungmin Park Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/fimc.txt | 30 ------------------------------ 1 file changed, 30 deletions(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/fimc.txt b/Documentation/video4linux/fimc.txt index 7d6e160..e0c6b8b 100644 --- a/Documentation/video4linux/fimc.txt +++ b/Documentation/video4linux/fimc.txt @@ -140,39 +140,9 @@ You can either grep through the kernel log to find relevant information, i.e. or retrieve the information from /dev/media? with help of the media-ctl tool: # media-ctl -p -6. Platform support -=================== - -The machine code (arch/arm/plat-samsung and arch/arm/mach-*) must select -following options: - -CONFIG_S5P_DEV_FIMC0 mandatory -CONFIG_S5P_DEV_FIMC1 \ -CONFIG_S5P_DEV_FIMC2 | optional -CONFIG_S5P_DEV_FIMC3 | -CONFIG_S5P_SETUP_FIMC / -CONFIG_S5P_DEV_CSIS0 \ optional for MIPI-CSI interface -CONFIG_S5P_DEV_CSIS1 / - -Except that, relevant s5p_device_fimc? should be registered in the machine code -in addition to a "s5p-fimc-md" platform device to which the media device driver -is bound. The "s5p-fimc-md" device instance is required even if only mem-to-mem -operation is used. - -The description of sensor(s) attached to FIMC/MIPI-CSIS camera inputs should be -passed as the "s5p-fimc-md" device platform_data. The platform data structure -is defined in file include/media/s5p_fimc.h. - 7. Build ======== -This driver depends on following config options: -PLAT_S5P, -PM_RUNTIME, -I2C, -REGULATOR, -VIDEO_V4L2_SUBDEV_API, - If the driver is built as a loadable kernel module (CONFIG_VIDEO_SAMSUNG_S5P_FIMC=m) two modules are created (in addition to the core v4l2 modules): s5p-fimc.ko and optional s5p-csis.ko (MIPI-CSI receiver subdev). -- cgit v1.1 From 3eb51f5ec0dc9dfaa08bb8a376c2379c8a26d0d1 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Mon, 24 Mar 2014 09:48:13 -0300 Subject: [media] Documentation: media: Remove double 'struct' The XML entities for media structures start with the 'struct' word. Remove duplicate 'struct' from the entity users. Reported-by: Hans Verkuil Signed-off-by: Laurent Pinchart Acked-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/io.xml | 2 +- Documentation/DocBook/media/v4l/media-ioc-enum-links.xml | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 188e621..a086a5d 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -125,7 +125,7 @@ location of the buffers in device memory can be determined with the m.offset and length returned in a &v4l2-buffer; are passed as sixth and second parameter to the mmap() function. When using the multi-planar API, -struct &v4l2-buffer; contains an array of &v4l2-plane; structures, each +&v4l2-buffer; contains an array of &v4l2-plane; structures, each containing its own m.offset and length. When using the multi-planar API, every plane of every buffer has to be mapped separately, so the number of diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml index cf85485..74fb394 100644 --- a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml @@ -79,13 +79,13 @@ Entity id, set by the application. - struct &media-pad-desc; + &media-pad-desc; *pads Pointer to a pads array allocated by the application. Ignored if NULL. - struct &media-link-desc; + &media-link-desc; *links Pointer to a links array allocated by the application. Ignored if NULL. @@ -153,12 +153,12 @@ &cs-str; - struct &media-pad-desc; + &media-pad-desc; source Pad at the origin of this link. - struct &media-pad-desc; + &media-pad-desc; sink Pad at the target of this link. -- cgit v1.1 From 3cbe6e5bcad0b102c06b9c6029fda75630045475 Mon Sep 17 00:00:00 2001 From: Arun Kumar K Date: Wed, 14 May 2014 03:59:42 -0300 Subject: [media] v4l: Add source change event This event indicates that the video device has encountered a source parameter change during runtime. This can typically be a resolution change detected by a video decoder OR a format change detected by an input connector. This needs to be nofified to the userspace and the application may be expected to reallocate buffers before proceeding. The application can subscribe to events on a specific pad or input port which it is interested in. Signed-off-by: Arun Kumar K Acked-by: Sylwester Nawrocki Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 33 ++++++++++++++++++++++ .../DocBook/media/v4l/vidioc-subscribe-event.xml | 20 +++++++++++++ 2 files changed, 53 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml index 89891ad..820f86e 100644 --- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml +++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml @@ -242,6 +242,22 @@ + + struct <structname>v4l2_event_src_change</structname> + + &cs-str; + + + __u32 + changes + + A bitmask that tells what has changed. See . + + + + +
+ Changes @@ -270,6 +286,23 @@
+ + + Source Changes + + &cs-def; + + + V4L2_EVENT_SRC_CH_RESOLUTION + 0x0001 + This event gets triggered when a resolution change is + detected at an input. This can come from an input connector or + from a video decoder. + + + + +
&return-value; diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml index 5c70b61..f016254 100644 --- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml +++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml @@ -155,6 +155,26 @@ + V4L2_EVENT_SOURCE_CHANGE + 5 + + This event is triggered when a source parameter change is + detected during runtime by the video device. It can be a + runtime resolution change triggered by a video decoder or the + format change happening on an input connector. + This event requires that the id + matches the input index (when used with a video device node) + or the pad index (when used with a subdevice node) from which + you want to receive events. + + This event has a &v4l2-event-source-change; associated + with it. The changes bitfield denotes + what has changed for the subscribed pad. If multiple events + occurred before application could dequeue them, then the changes + will have the ORed value of all the events generated. + + + V4L2_EVENT_PRIVATE_START 0x08000000 Base event number for driver-private events. -- cgit v1.1 From e53c07724809bd3e103174fd27c5b6f00582a252 Mon Sep 17 00:00:00 2001 From: Florian Fainelli Date: Mon, 19 May 2014 13:06:00 -0700 Subject: Documentation: devicetree: add Broadcom GISB arbiter bindings This patch adds the Broadcom GISB arbiter Device Tree binding that is used on all Broadcom Set-top-box System-on-a-chip. Signed-off-by: Florian Fainelli Signed-off-by: Arnd Bergmann --- .../devicetree/bindings/bus/brcm,gisb-arb.txt | 30 ++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 Documentation/devicetree/bindings/bus/brcm,gisb-arb.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/bus/brcm,gisb-arb.txt b/Documentation/devicetree/bindings/bus/brcm,gisb-arb.txt new file mode 100644 index 0000000..e2d501d --- /dev/null +++ b/Documentation/devicetree/bindings/bus/brcm,gisb-arb.txt @@ -0,0 +1,30 @@ +Broadcom GISB bus Arbiter controller + +Required properties: + +- compatible: should be "brcm,gisb-arb" +- reg: specifies the base physical address and size of the registers +- interrupt-parent: specifies the phandle to the parent interrupt controller + this arbiter gets interrupt line from +- interrupts: specifies the two interrupts (timeout and TEA) to be used from + the parent interrupt controller + +Optional properties: + +- brcm,gisb-arb-master-mask: 32-bits wide bitmask used to specify which GISB + masters are valid at the system level +- brcm,gisb-arb-master-names: string list of the litteral name of the GISB + masters. Should match the number of bits set in brcm,gisb-master-mask and + the order in which they appear + +Example: + +gisb-arb@f0400000 { + compatible = "brcm,gisb-arb"; + reg = <0xf0400000 0x800>; + interrupts = <0>, <2>; + interrupt-parent = <&sun_l2_intc>; + + brcm,gisb-arb-master-mask = <0x7>; + brcm,gisb-arb-master-names = "bsp_0", "scpu_0", "cpu_0"; +}; -- cgit v1.1 From 7a1002e5ba6ebf17f8040f5176502527df8c38e8 Mon Sep 17 00:00:00 2001 From: Florian Fainelli Date: Mon, 19 May 2014 13:06:01 -0700 Subject: Documentation: sysfs: add Broadcom GISB arbiter sysfs properties This patch documents the sysfs properties exposed by the Broadcom GISB bus arbiter hardware. Signed-off-by: Florian Fainelli Signed-off-by: Arnd Bergmann --- Documentation/ABI/testing/sysfs-platform-brcmstb-gisb-arb | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-platform-brcmstb-gisb-arb (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-platform-brcmstb-gisb-arb b/Documentation/ABI/testing/sysfs-platform-brcmstb-gisb-arb new file mode 100644 index 0000000..f1bad92 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-brcmstb-gisb-arb @@ -0,0 +1,8 @@ +What: /sys/devices/../../gisb_arb_timeout +Date: May 2014 +KernelVersion: 3.17 +Contact: Florian Fainelli +Description: + Returns the currently configured raw timeout value of the + Broadcom Set Top Box internal GISB bus arbiter. Minimum value + is 1, and maximum value is 0xffffffff. -- cgit v1.1 From 481300ccf3ef5a79bb7ba59f77c96035134606d9 Mon Sep 17 00:00:00 2001 From: Stephen Boyd Date: Fri, 23 May 2014 12:57:17 -0700 Subject: devicetree: bindings: Properly document micrel ks8851 SPI chips The ks8851 SPI ethernet wasn't documented, but we documented the optional regulator supply for it under the mll based ethernet chip. Furthermore, that compatible string needed another 'l'. Fix all of this and document the optional vdd-io and reset-gpios properties. Cc: Nishanth Menon Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Cc: Signed-off-by: Stephen Boyd Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/micrel-ks8851.txt | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/micrel-ks8851.txt b/Documentation/devicetree/bindings/net/micrel-ks8851.txt index d54d0cc..bbdf9a7 100644 --- a/Documentation/devicetree/bindings/net/micrel-ks8851.txt +++ b/Documentation/devicetree/bindings/net/micrel-ks8851.txt @@ -1,9 +1,18 @@ -Micrel KS8851 Ethernet mac +Micrel KS8851 Ethernet mac (MLL) Required properties: -- compatible = "micrel,ks8851-ml" of parallel interface +- compatible = "micrel,ks8851-mll" of parallel interface - reg : 2 physical address and size of registers for data and command - interrupts : interrupt connection +Micrel KS8851 Ethernet mac (SPI) + +Required properties: +- compatible = "micrel,ks8851" or the deprecated "ks8851" +- reg : chip select number +- interrupts : interrupt connection + Optional properties: -- vdd-supply: supply for Ethernet mac +- vdd-supply: analog 3.3V supply for Ethernet mac +- vdd-io-supply: digital 1.8V IO supply for Ethernet mac +- reset-gpios: reset_n input pin -- cgit v1.1 From 0132514588f3a0685861221058116a383bff4deb Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Sun, 25 May 2014 17:23:07 +0200 Subject: hwmon: Document temp[1-*]_min_hyst sysfs attribute The temp[1-*]_min_hyst sysfs attribute is already implemented by 3 hwmon drivers (adt7x10, lm77 and lm92) but was missing from the standard interface. Also add temp[1-*]_lcrit_hyst for consistency, even though no driver implement that one for the time being. Signed-off-by: Jean Delvare Reviewed-by: Guenter Roeck --- Documentation/hwmon/sysfs-interface | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation') diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface index 79f8257..2cc95ad 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface @@ -327,6 +327,13 @@ temp[1-*]_max_hyst from the max value. RW +temp[1-*]_min_hyst + Temperature hysteresis value for min limit. + Unit: millidegree Celsius + Must be reported as an absolute temperature, NOT a delta + from the min value. + RW + temp[1-*]_input Temperature input value. Unit: millidegree Celsius RO @@ -362,6 +369,13 @@ temp[1-*]_lcrit Temperature critical min value, typically lower than Unit: millidegree Celsius RW +temp[1-*]_lcrit_hyst + Temperature hysteresis value for critical min limit. + Unit: millidegree Celsius + Must be reported as an absolute temperature, NOT a delta + from the critical min value. + RW + temp[1-*]_offset Temperature offset which is added to the temperature reading by the chip. -- cgit v1.1 From 9cfd65e80959836fed78704e8a127d4e10448d56 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Wed, 29 Jan 2014 10:07:13 -0300 Subject: [media] v4l: Add support for DV timings ioctls on subdev nodes Validate the pad field in the core code whenever specified. Signed-off-by: Laurent Pinchart Reviewed-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../DocBook/media/v4l/vidioc-dv-timings-cap.xml | 27 +++++++++++++++---- .../DocBook/media/v4l/vidioc-enum-dv-timings.xml | 30 +++++++++++++++++----- 2 files changed, 45 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml b/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml index cd7720d..28a8c1e 100644 --- a/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml @@ -1,11 +1,12 @@ - ioctl VIDIOC_DV_TIMINGS_CAP + ioctl VIDIOC_DV_TIMINGS_CAP, VIDIOC_SUBDEV_DV_TIMINGS_CAP &manvol; VIDIOC_DV_TIMINGS_CAP + VIDIOC_SUBDEV_DV_TIMINGS_CAP The capabilities of the Digital Video receiver/transmitter @@ -33,7 +34,7 @@ request - VIDIOC_DV_TIMINGS_CAP + VIDIOC_DV_TIMINGS_CAP, VIDIOC_SUBDEV_DV_TIMINGS_CAP @@ -54,10 +55,19 @@ interface and may change in the future. - To query the capabilities of the DV receiver/transmitter applications can call -this ioctl and the driver will fill in the structure. Note that drivers may return + To query the capabilities of the DV receiver/transmitter applications +can call the VIDIOC_DV_TIMINGS_CAP ioctl on a video node +and the driver will fill in the structure. Note that drivers may return different values after switching the video input or output. + When implemented by the driver DV capabilities of subdevices can be +queried by calling the VIDIOC_SUBDEV_DV_TIMINGS_CAP ioctl +directly on a subdevice node. The capabilities are specific to inputs (for DV +receivers) or outputs (for DV transmitters), applications must specify the +desired pad number in the &v4l2-dv-timings-cap; pad +field. Attempts to query capabilities on a pad that doesn't support them will +return an &EINVAL;. + struct <structname>v4l2_bt_timings_cap</structname> @@ -127,7 +137,14 @@ different values after switching the video input or output. __u32 - reserved[3] + pad + Pad number as reported by the media controller API. This field + is only used when operating on a subdevice node. When operating on a + video node applications must set this field to zero. + + + __u32 + reserved[2] Reserved for future extensions. Drivers must set the array to zero. diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml b/Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml index b3e17c1..b9fdfea 100644 --- a/Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml +++ b/Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml @@ -1,11 +1,12 @@ - ioctl VIDIOC_ENUM_DV_TIMINGS + ioctl VIDIOC_ENUM_DV_TIMINGS, VIDIOC_SUBDEV_ENUM_DV_TIMINGS &manvol; VIDIOC_ENUM_DV_TIMINGS + VIDIOC_SUBDEV_ENUM_DV_TIMINGS Enumerate supported Digital Video timings @@ -33,7 +34,7 @@ request - VIDIOC_ENUM_DV_TIMINGS + VIDIOC_ENUM_DV_TIMINGS, VIDIOC_SUBDEV_ENUM_DV_TIMINGS @@ -61,14 +62,21 @@ standards or even custom timings that are not in this list. To query the available timings, applications initialize the index field and zero the reserved array of &v4l2-enum-dv-timings; -and call the VIDIOC_ENUM_DV_TIMINGS ioctl with a pointer to this -structure. Drivers fill the rest of the structure or return an +and call the VIDIOC_ENUM_DV_TIMINGS ioctl on a video node with a +pointer to this structure. Drivers fill the rest of the structure or return an &EINVAL; when the index is out of bounds. To enumerate all supported DV timings, applications shall begin at index zero, incrementing by one until the driver returns EINVAL. Note that drivers may enumerate a different set of DV timings after switching the video input or output. + When implemented by the driver DV timings of subdevices can be queried +by calling the VIDIOC_SUBDEV_ENUM_DV_TIMINGS ioctl directly +on a subdevice node. The DV timings are specific to inputs (for DV receivers) or +outputs (for DV transmitters), applications must specify the desired pad number +in the &v4l2-enum-dv-timings; pad field. Attempts to +enumerate timings on a pad that doesn't support them will return an &EINVAL;. +
struct <structname>v4l2_enum_dv_timings</structname> @@ -82,8 +90,16 @@ application. __u32 - reserved[3] - Reserved for future extensions. Drivers must set the array to zero. + pad + Pad number as reported by the media controller API. This field + is only used when operating on a subdevice node. When operating on a + video node applications must set this field to zero. + + + __u32 + reserved[2] + Reserved for future extensions. Drivers and applications must + set the array to zero. &v4l2-dv-timings; @@ -103,7 +119,7 @@ application. EINVAL The &v4l2-enum-dv-timings; index -is out of bounds. +is out of bounds or the pad number is invalid. -- cgit v1.1 From f82f313e9739026ca96342b5b44c5c94072e166a Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Mon, 25 Nov 2013 16:19:08 -0300 Subject: [media] adv7604: Add DT support Parse the device tree node to populate platform data. Only the ADV7611 is currently support with DT. Signed-off-by: Laurent Pinchart Acked-by: Hans Verkuil Acked-by: Sylwester Nawrocki Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/media/i2c/adv7604.txt | 57 ++++++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/adv7604.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt b/Documentation/devicetree/bindings/media/i2c/adv7604.txt new file mode 100644 index 0000000..2efb48f --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt @@ -0,0 +1,57 @@ +* Analog Devices ADV7604/11 video decoder with HDMI receiver + +The ADV7604 and ADV7611 are multiformat video decoders with an integrated HDMI +receiver. The ADV7604 has four multiplexed HDMI inputs and one analog input, +and the ADV7611 has one HDMI input and no analog input. + +These device tree bindings support the ADV7611 only at the moment. + +Required Properties: + + - compatible: Must contain one of the following + - "adi,adv7611" for the ADV7611 + + - reg: I2C slave address + + - hpd-gpios: References to the GPIOs that control the HDMI hot-plug + detection pins, one per HDMI input. The active flag indicates the GPIO + level that enables hot-plug detection. + +The device node must contain one 'port' child node per device input and output +port, in accordance with the video interface bindings defined in +Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes +are numbered as follows. + + Port ADV7611 +------------------------------------------------------------ + HDMI 0 + Digital output 1 + +The digital output port node must contain at least one endpoint. + +Optional Properties: + + - reset-gpios: Reference to the GPIO connected to the device's reset pin. + +Example: + + hdmi_receiver@4c { + compatible = "adi,adv7611"; + reg = <0x4c>; + + reset-gpios = <&ioexp 0 GPIO_ACTIVE_LOW>; + hpd-gpios = <&ioexp 2 GPIO_ACTIVE_HIGH>; + + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + }; + port@1 { + reg = <1>; + hdmi_in: endpoint { + remote-endpoint = <&ccdc_in>; + }; + }; + }; -- cgit v1.1 From 6fa88045ef7db3d09af80aa00fd7c937b7289387 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Tue, 4 Feb 2014 20:23:16 -0300 Subject: [media] adv7604: Add endpoint properties to DT bindings Add support for the hsync-active, vsync-active and pclk-sample properties to the DT bindings and control BT.656 mode implicitly. Signed-off-by: Laurent Pinchart Acked-by: Hans Verkuil Acked-by: Sylwester Nawrocki Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/i2c/adv7604.txt | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index 2efb48f..c27cede 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt @@ -33,6 +33,19 @@ Optional Properties: - reset-gpios: Reference to the GPIO connected to the device's reset pin. +Optional Endpoint Properties: + + The following three properties are defined in video-interfaces.txt and are + valid for source endpoints only. + + - hsync-active: Horizontal synchronization polarity. Defaults to active low. + - vsync-active: Vertical synchronization polarity. Defaults to active low. + - pclk-sample: Pixel clock polarity. Defaults to output on the falling edge. + + If none of hsync-active, vsync-active and pclk-sample is specified the + endpoint will use embedded BT.656 synchronization. + + Example: hdmi_receiver@4c { -- cgit v1.1 From afad82ccbaefa099cc3bec1a70a014c13e325f9a Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Sun, 25 May 2014 11:15:03 -0300 Subject: [media] DocBook media: fix typo The reference to v4l2-event-source-change should have been v4l2-event-src-change. This caused a failure when building the spec. Fixed. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml index f016254..17efa87 100644 --- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml +++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml @@ -167,7 +167,7 @@ or the pad index (when used with a subdevice node) from which you want to receive events. - This event has a &v4l2-event-source-change; associated + This event has a &v4l2-event-src-change; associated with it. The changes bitfield denotes what has changed for the subscribed pad. If multiple events occurred before application could dequeue them, then the changes -- cgit v1.1 From f9b899c44fec53c1519b19f853e96191ae96b1c6 Mon Sep 17 00:00:00 2001 From: Masanari Iida Date: Thu, 15 May 2014 13:54:06 -0700 Subject: Documentation: fix typos in drm docbook Fix spelling typo in DocBook/drm.tmpl Signed-off-by: Masanari Iida Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/DocBook/drm.tmpl | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 677a025..ba60d93 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -79,7 +79,7 @@ This first part of the DRM Developer's Guide documents core DRM code, - helper libraries for writting drivers and generic userspace interfaces + helper libraries for writing drivers and generic userspace interfaces exposed by DRM drivers. @@ -459,7 +459,7 @@ char *date; providing a solution to every graphics memory-related problems, GEM identified common code between drivers and created a support library to share it. GEM has simpler initialization and execution requirements than - TTM, but has no video RAM management capabitilies and is thus limited to + TTM, but has no video RAM management capabilities and is thus limited to UMA devices. @@ -889,7 +889,7 @@ int (*prime_fd_to_handle)(struct drm_device *dev, vice versa. Drivers must use the kernel dma-buf buffer sharing framework to manage the PRIME file descriptors. Similar to the mode setting API PRIME is agnostic to the underlying buffer object manager, as - long as handles are 32bit unsinged integers. + long as handles are 32bit unsigned integers. While non-GEM drivers must implement the operations themselves, GEM @@ -2356,7 +2356,7 @@ void intel_crt_init(struct drm_device *dev) 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 + instances, and all other property information are stored in the property and shared between all instances of the property. @@ -2697,10 +2697,10 @@ int num_ioctls; Legacy Support Code - The section very brievely covers some of the old legacy support code which + The section very briefly covers some of the old legacy support code which is only used by old DRM drivers which have done a so-called shadow-attach to the underlying device instead of registering as a real driver. This - also includes some of the old generic buffer mangement and command + also includes some of the old generic buffer management and command submission code. Do not use any of this in new and modern drivers. -- cgit v1.1 From f9a0974d3f7049f6f753ebd28b8f0907983acf3c Mon Sep 17 00:00:00 2001 From: Paul McQuade Date: Thu, 15 May 2014 13:54:25 -0700 Subject: Documentation: update thunderbird email client settings Added setting to email-clients that is easier to read and is easier to setup thunderbird. Removed config settings and added GUI settings. Signed-off-by: Paul McQuade Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/email-clients.txt | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/email-clients.txt b/Documentation/email-clients.txt index e9f5dac..4e30eba 100644 --- a/Documentation/email-clients.txt +++ b/Documentation/email-clients.txt @@ -201,20 +201,15 @@ To beat some sense out of the internal editor, do this: - Edit your Thunderbird config settings so that it won't use format=flowed. Go to "edit->preferences->advanced->config editor" to bring up the - thunderbird's registry editor, and set "mailnews.send_plaintext_flowed" to - "false". + thunderbird's registry editor. -- Disable HTML Format: Set "mail.identity.id1.compose_html" to "false". +- Set "mailnews.send_plaintext_flowed" to "false" -- Enable "preformat" mode: Set "editor.quotesPreformatted" to "true". +- Set "mailnews.wraplength" from "72" to "0" -- Enable UTF8: Set "prefs.converted-to-utf8" to "true". +- "View" > "Message Body As" > "Plain Text" -- Install the "toggle wordwrap" extension. Download the file from: - https://addons.mozilla.org/thunderbird/addon/2351/ - Then go to "tools->add ons", select "install" at the bottom of the screen, - and browse to where you saved the .xul file. This adds an "Enable - Wordwrap" entry under the Options menu of the message composer. +- "View" > "Character Encoding" > "Unicode (UTF-8)" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ TkRat (GUI) -- cgit v1.1 From f76f133b0c3b182c2d4f4de21a04ba4c964d508d Mon Sep 17 00:00:00 2001 From: Jonathan Callen Date: Thu, 15 May 2014 13:54:52 -0700 Subject: Documentation: update java sample wrapper for java 7 The sample wrapper currently fails on some Java 7 .class files. This updates the wrapper to properly handle those files. Signed-off-by: Jonathan Callen Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/java.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/java.txt b/Documentation/java.txt index e6a7232..4180205 100644 --- a/Documentation/java.txt +++ b/Documentation/java.txt @@ -188,6 +188,9 @@ shift #define CP_METHODREF 10 #define CP_INTERFACEMETHODREF 11 #define CP_NAMEANDTYPE 12 +#define CP_METHODHANDLE 15 +#define CP_METHODTYPE 16 +#define CP_INVOKEDYNAMIC 18 /* Define some commonly used error messages */ @@ -242,14 +245,19 @@ void skip_constant(FILE *classfile, u_int16_t *cur) break; case CP_CLASS: case CP_STRING: + case CP_METHODTYPE: seekerr = fseek(classfile, 2, SEEK_CUR); break; + case CP_METHODHANDLE: + seekerr = fseek(classfile, 3, SEEK_CUR); + break; case CP_INTEGER: case CP_FLOAT: case CP_FIELDREF: case CP_METHODREF: case CP_INTERFACEMETHODREF: case CP_NAMEANDTYPE: + case CP_INVOKEDYNAMIC: seekerr = fseek(classfile, 4, SEEK_CUR); break; case CP_LONG: -- cgit v1.1 From 3568a1dbf174a1ae0022611998c4e5d588b5014d Mon Sep 17 00:00:00 2001 From: Jan Moskyto Matejka Date: Thu, 15 May 2014 13:55:34 -0700 Subject: Documentation: update /proc/stat "intr" count summary The sum at the beginning of line "intr" includes also unnumbered interrupts. It implies that the sum at the beginning isn't the sum of the remainder of the line, not even an estimation. Fixed the documentation to mention that. This behaviour was added to /proc/stat in commit a2eddfa95919 ("x86: make /proc/stat account for all interrupts") Signed-off-by: Jan Moskyto Matejka Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/filesystems/proc.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 8b9cd8e..264bcde 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -1245,8 +1245,9 @@ second). The meanings of the columns are as follows, from left to right: The "intr" line gives counts of interrupts serviced since boot time, for each of the possible system interrupts. The first column is the total of all -interrupts serviced; each subsequent column is the total for that particular -interrupt. +interrupts serviced including unnumbered architecture specific interrupts; +each subsequent column is the total for that particular numbered interrupt. +Unnumbered interrupts are not shown, only summed into the total. The "ctxt" line gives the total number of context switches across all CPUs. -- cgit v1.1 From f57051942fa48ed75928dfa3c392c1a849ba943a Mon Sep 17 00:00:00 2001 From: Kamil Debski Date: Wed, 14 May 2014 11:31:09 -0300 Subject: [media] v4l: Fix documentation of V4L2_PIX_FMT_H264_MVC and VP8 pixel formats The 'Code' column in the documentation should provide the real fourcc code that is used. Changed the documentation to provide the fourcc defined in videodev2.h Signed-off-by: Kamil Debski Acked-by: Sylwester Nawrocki Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/pixfmt.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index ea514d60..91dcbc8 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml @@ -772,7 +772,7 @@ extended control V4L2_CID_MPEG_STREAM_TYPE, see V4L2_PIX_FMT_H264_MVC - 'MVC' + 'M264' H264 MVC video elementary stream. @@ -812,7 +812,7 @@ extended control V4L2_CID_MPEG_STREAM_TYPE, see V4L2_PIX_FMT_VP8 - 'VP8' + 'VP80' VP8 video elementary stream. -- cgit v1.1 From 4ea7ceea5189f018800b9ed3b354bb4e2c39cd1a Mon Sep 17 00:00:00 2001 From: Christophe Ricard Date: Tue, 20 May 2014 21:45:04 +0200 Subject: NFC: dts: st21nfca_i2c: Correct minor typo in documentation Replaced st,st21nfca-i2c by st,st21nfca_i2c to be concistent with below configuration and driver in drivers/nfc/st21nfca/ Signed-off-by: Christophe Ricard Signed-off-by: Samuel Ortiz --- Documentation/devicetree/bindings/net/nfc/st21nfca.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/nfc/st21nfca.txt b/Documentation/devicetree/bindings/net/nfc/st21nfca.txt index 4724fe6..e4faa2e 100644 --- a/Documentation/devicetree/bindings/net/nfc/st21nfca.txt +++ b/Documentation/devicetree/bindings/net/nfc/st21nfca.txt @@ -1,7 +1,7 @@ * STMicroelectronics SAS. ST21NFCA NFC Controller Required properties: -- compatible: Should be "st,st21nfca-i2c". +- compatible: Should be "st,st21nfca_i2c". - clock-frequency: I²C work frequency. - reg: address on the bus - interrupt-parent: phandle for the interrupt gpio controller -- cgit v1.1 From 03eff46ce31dbb186fea3eb2016e1c41f000db7e Mon Sep 17 00:00:00 2001 From: Will Deacon Date: Fri, 9 May 2014 18:34:19 +0100 Subject: ARM: 8054/1: perf: add support for the Cortex-A17 PMU The Cortex-A17 PMU is identical to that of the A12, so wire up a new compatible string to the existing event structures. Signed-off-by: Will Deacon Signed-off-by: Russell King --- Documentation/devicetree/bindings/arm/pmu.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/pmu.txt b/Documentation/devicetree/bindings/arm/pmu.txt index fe5cef8..75ef91d 100644 --- a/Documentation/devicetree/bindings/arm/pmu.txt +++ b/Documentation/devicetree/bindings/arm/pmu.txt @@ -8,6 +8,7 @@ Required properties: - compatible : should be one of "arm,armv8-pmuv3" + "arm,cortex-a17-pmu" "arm,cortex-a15-pmu" "arm,cortex-a12-pmu" "arm,cortex-a9-pmu" -- cgit v1.1 From 9a6594fc5241ad96cff727a134f336b1f1eaa0f7 Mon Sep 17 00:00:00 2001 From: Masanari Iida Date: Thu, 15 May 2014 13:54:06 -0700 Subject: Documentation: fix typos in drm docbook Fix spelling typo in DocBook/drm.tmpl Signed-off-by: Masanari Iida Signed-off-by: Randy Dunlap Signed-off-by: Dave Airlie --- Documentation/DocBook/drm.tmpl | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index ec81c20..a21cdd5 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -79,7 +79,7 @@ This first part of the DRM Developer's Guide documents core DRM code, - helper libraries for writting drivers and generic userspace interfaces + helper libraries for writing drivers and generic userspace interfaces exposed by DRM drivers. @@ -451,7 +451,7 @@ char *date; providing a solution to every graphics memory-related problems, GEM identified common code between drivers and created a support library to share it. GEM has simpler initialization and execution requirements than - TTM, but has no video RAM management capabitilies and is thus limited to + TTM, but has no video RAM management capabilities and is thus limited to UMA devices. @@ -881,7 +881,7 @@ int (*prime_fd_to_handle)(struct drm_device *dev, vice versa. Drivers must use the kernel dma-buf buffer sharing framework to manage the PRIME file descriptors. Similar to the mode setting API PRIME is agnostic to the underlying buffer object manager, as - long as handles are 32bit unsinged integers. + long as handles are 32bit unsigned integers. While non-GEM drivers must implement the operations themselves, GEM @@ -2348,7 +2348,7 @@ void intel_crt_init(struct drm_device *dev) 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 + instances, and all other property information are stored in the property and shared between all instances of the property. @@ -2689,10 +2689,10 @@ int num_ioctls; Legacy Support Code - The section very brievely covers some of the old legacy support code which + The section very briefly covers some of the old legacy support code which is only used by old DRM drivers which have done a so-called shadow-attach to the underlying device instead of registering as a real driver. This - also includes some of the old generic buffer mangement and command + also includes some of the old generic buffer management and command submission code. Do not use any of this in new and modern drivers. -- cgit v1.1 From 4cbe1bfa27dcc8e757c723f27e5a8e8b5fc32117 Mon Sep 17 00:00:00 2001 From: Daniel Thompson Date: Fri, 23 May 2014 16:01:43 +0100 Subject: drm: Add 800x600 (SVGA) screen resolution to the built-in EDIDs The 800x600 (SVGA) screen resolution was lacking in the set of built-in selectable EDID screen resolutions that can be used to repair misbehaving monitor firmware. This patch adds the related data set and expands the documentation. Note that the SVGA bit occupies a different byte to all the existing users of the established timing bits forcing a rework of the ESTABLISHED_TIMINGS_BITS macro. Tested new EDID on an aged (and misbehaving) industrial LCD panel; existing EDIDs still pass edid-decode's checksum checks. Signed-off-by: Daniel Thompson Cc: Randy Dunlap Cc: David Airlie Cc: Carsten Emde Cc: linux-doc@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Reviewed-by: Alex Deucher Signed-off-by: Dave Airlie --- Documentation/EDID/1024x768.S | 2 +- Documentation/EDID/1280x1024.S | 2 +- Documentation/EDID/1600x1200.S | 2 +- Documentation/EDID/1680x1050.S | 2 +- Documentation/EDID/1920x1080.S | 2 +- Documentation/EDID/800x600.S | 41 +++++++++++++++++++++++++++++++++++++++++ Documentation/EDID/HOWTO.txt | 2 +- Documentation/EDID/edid.S | 17 ++++++++++++++--- 8 files changed, 61 insertions(+), 9 deletions(-) create mode 100644 Documentation/EDID/800x600.S (limited to 'Documentation') diff --git a/Documentation/EDID/1024x768.S b/Documentation/EDID/1024x768.S index 4b486fe..6f3e4b7 100644 --- a/Documentation/EDID/1024x768.S +++ b/Documentation/EDID/1024x768.S @@ -36,7 +36,7 @@ #define DPI 72 #define VFREQ 60 /* Hz */ #define TIMING_NAME "Linux XGA" -#define ESTABLISHED_TIMINGS_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */ +#define ESTABLISHED_TIMING2_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */ #define HSYNC_POL 0 #define VSYNC_POL 0 #define CRC 0x55 diff --git a/Documentation/EDID/1280x1024.S b/Documentation/EDID/1280x1024.S index a2799fe..bd9bef2a 100644 --- a/Documentation/EDID/1280x1024.S +++ b/Documentation/EDID/1280x1024.S @@ -36,7 +36,7 @@ #define DPI 72 #define VFREQ 60 /* Hz */ #define TIMING_NAME "Linux SXGA" -#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */ +/* No ESTABLISHED_TIMINGx_BITS */ #define HSYNC_POL 1 #define VSYNC_POL 1 #define CRC 0xa0 diff --git a/Documentation/EDID/1600x1200.S b/Documentation/EDID/1600x1200.S index 0ded64c..a45101c 100644 --- a/Documentation/EDID/1600x1200.S +++ b/Documentation/EDID/1600x1200.S @@ -36,7 +36,7 @@ #define DPI 72 #define VFREQ 60 /* Hz */ #define TIMING_NAME "Linux UXGA" -#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */ +/* No ESTABLISHED_TIMINGx_BITS */ #define HSYNC_POL 1 #define VSYNC_POL 1 #define CRC 0x9d diff --git a/Documentation/EDID/1680x1050.S b/Documentation/EDID/1680x1050.S index 96f67ca..b0d7c69 100644 --- a/Documentation/EDID/1680x1050.S +++ b/Documentation/EDID/1680x1050.S @@ -36,7 +36,7 @@ #define DPI 96 #define VFREQ 60 /* Hz */ #define TIMING_NAME "Linux WSXGA" -#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */ +/* No ESTABLISHED_TIMINGx_BITS */ #define HSYNC_POL 1 #define VSYNC_POL 1 #define CRC 0x26 diff --git a/Documentation/EDID/1920x1080.S b/Documentation/EDID/1920x1080.S index 36ed5d5..3084355e 100644 --- a/Documentation/EDID/1920x1080.S +++ b/Documentation/EDID/1920x1080.S @@ -36,7 +36,7 @@ #define DPI 96 #define VFREQ 60 /* Hz */ #define TIMING_NAME "Linux FHD" -#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */ +/* No ESTABLISHED_TIMINGx_BITS */ #define HSYNC_POL 1 #define VSYNC_POL 1 #define CRC 0x05 diff --git a/Documentation/EDID/800x600.S b/Documentation/EDID/800x600.S new file mode 100644 index 0000000..6644e26 --- /dev/null +++ b/Documentation/EDID/800x600.S @@ -0,0 +1,41 @@ +/* + 800x600.S: EDID data set for standard 800x600 60 Hz monitor + + Copyright (C) 2011 Carsten Emde + Copyright (C) 2014 Linaro Limited + + 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; either version 2 + of the License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. +*/ + +/* EDID */ +#define VERSION 1 +#define REVISION 3 + +/* Display */ +#define CLOCK 40000 /* kHz */ +#define XPIX 800 +#define YPIX 600 +#define XY_RATIO XY_RATIO_4_3 +#define XBLANK 256 +#define YBLANK 28 +#define XOFFSET 40 +#define XPULSE 128 +#define YOFFSET (63+1) +#define YPULSE (63+4) +#define DPI 72 +#define VFREQ 60 /* Hz */ +#define TIMING_NAME "Linux SVGA" +#define ESTABLISHED_TIMING1_BITS 0x01 /* Bit 0: 800x600 @ 60Hz */ +#define HSYNC_POL 1 +#define VSYNC_POL 1 +#define CRC 0xc2 + +#include "edid.S" diff --git a/Documentation/EDID/HOWTO.txt b/Documentation/EDID/HOWTO.txt index 7146db1..835db33 100644 --- a/Documentation/EDID/HOWTO.txt +++ b/Documentation/EDID/HOWTO.txt @@ -18,7 +18,7 @@ CONFIG_DRM_LOAD_EDID_FIRMWARE was introduced. It allows to provide an individually prepared or corrected EDID data set in the /lib/firmware directory from where it is loaded via the firmware interface. The code (see drivers/gpu/drm/drm_edid_load.c) contains built-in data sets for -commonly used screen resolutions (1024x768, 1280x1024, 1600x1200, +commonly used screen resolutions (800x600, 1024x768, 1280x1024, 1600x1200, 1680x1050, 1920x1080) as binary blobs, but the kernel source tree does not contain code to create these data. In order to elucidate the origin of the built-in binary EDID blobs and to facilitate the creation of diff --git a/Documentation/EDID/edid.S b/Documentation/EDID/edid.S index ea97ae2..7ac0327 100644 --- a/Documentation/EDID/edid.S +++ b/Documentation/EDID/edid.S @@ -33,6 +33,17 @@ #define XY_RATIO_5_4 0b10 #define XY_RATIO_16_9 0b11 +/* Provide defaults for the timing bits */ +#ifndef ESTABLISHED_TIMING1_BITS +#define ESTABLISHED_TIMING1_BITS 0x00 +#endif +#ifndef ESTABLISHED_TIMING2_BITS +#define ESTABLISHED_TIMING2_BITS 0x00 +#endif +#ifndef ESTABLISHED_TIMING3_BITS +#define ESTABLISHED_TIMING3_BITS 0x00 +#endif + #define mfgname2id(v1,v2,v3) \ ((((v1-'@')&0x1f)<<10)+(((v2-'@')&0x1f)<<5)+((v3-'@')&0x1f)) #define swap16(v1) ((v1>>8)+((v1&0xff)<<8)) @@ -139,7 +150,7 @@ white_x_y_msb: .byte 0x50,0x54 Bit 2 640x480 @ 75 Hz Bit 1 800x600 @ 56 Hz Bit 0 800x600 @ 60 Hz */ -estbl_timing1: .byte 0x00 +estbl_timing1: .byte ESTABLISHED_TIMING1_BITS /* Bit 7 800x600 @ 72 Hz Bit 6 800x600 @ 75 Hz @@ -149,11 +160,11 @@ estbl_timing1: .byte 0x00 Bit 2 1024x768 @ 72 Hz Bit 1 1024x768 @ 75 Hz Bit 0 1280x1024 @ 75 Hz */ -estbl_timing2: .byte ESTABLISHED_TIMINGS_BITS +estbl_timing2: .byte ESTABLISHED_TIMING2_BITS /* Bit 7 1152x870 @ 75 Hz (Apple Macintosh II) Bits 6-0 Other manufacturer-specific display mod */ -estbl_timing3: .byte 0x00 +estbl_timing3: .byte ESTABLISHED_TIMING3_BITS /* Standard timing */ /* X resolution, less 31, divided by 8 (256-2288 pixels) */ -- cgit v1.1 From 79499bca6c921d61f3ee5d20d71fb344ece1fdd2 Mon Sep 17 00:00:00 2001 From: Florian Fainelli Date: Fri, 23 May 2014 16:35:40 -0700 Subject: net: sysfs: add missing phys_port_id documentation Add documentation for the phys_port_id sysfs attribute of a network device. Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller --- Documentation/ABI/testing/sysfs-class-net | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-net b/Documentation/ABI/testing/sysfs-class-net index d922060e..416c5d5 100644 --- a/Documentation/ABI/testing/sysfs-class-net +++ b/Documentation/ABI/testing/sysfs-class-net @@ -169,6 +169,14 @@ Description: "unknown", "notpresent", "down", "lowerlayerdown", "testing", "dormant", "up". +What: /sys/class/net//phys_port_id +Date: July 2013 +KernelVersion: 3.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the interface unique physical port identifier within + the NIC, as a string. + What: /sys/class/net//speed Date: October 2009 KernelVersion: 2.6.33 -- cgit v1.1 From 1a02ef76acfa0e172e7c3b08e4efb89db84ef0a5 Mon Sep 17 00:00:00 2001 From: Florian Fainelli Date: Fri, 23 May 2014 16:35:41 -0700 Subject: net: sysfs: add documentation entries for /sys/class//queues Add sysfs documentation for the various attributes of a network interface exposed in /sys/class//queues/{rx,tx}-/ Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller --- Documentation/ABI/testing/sysfs-class-net-queues | 79 ++++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-net-queues (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-net-queues b/Documentation/ABI/testing/sysfs-class-net-queues new file mode 100644 index 0000000..5e9aeb9 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-net-queues @@ -0,0 +1,79 @@ +What: /sys/class//queues/rx-/rps_cpus +Date: March 2010 +KernelVersion: 2.6.35 +Contact: netdev@vger.kernel.org +Description: + Mask of the CPU(s) currently enabled to participate into the + Receive Packet Steering packet processing flow for this + network device queue. Possible values depend on the number + of available CPU(s) in the system. + +What: /sys/class//queues/rx-/rps_flow_cnt +Date: April 2010 +KernelVersion: 2.6.35 +Contact: netdev@vger.kernel.org +Description: + Number of Receive Packet Steering flows being currently + processed by this particular network device receive queue. + +What: /sys/class//queues/tx-/tx_timeout +Date: November 2011 +KernelVersion: 3.3 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of transmit timeout events seen by this + network interface transmit queue. + +What: /sys/class//queues/tx-/xps_cpus +Date: November 2010 +KernelVersion: 2.6.38 +Contact: netdev@vger.kernel.org +Description: + Mask of the CPU(s) currently enabled to participate into the + Transmit Packet Steering packet processing flow for this + network device transmit queue. Possible vaules depend on the + number of available CPU(s) in the system. + +What: /sys/class//queues/tx-/byte_queue_limits/hold_time +Date: November 2011 +KernelVersion: 3.3 +Contact: netdev@vger.kernel.org +Description: + Indicates the hold time in milliseconds to measure the slack + of this particular network device transmit queue. + Default value is 1000. + +What: /sys/class//queues/tx-/byte_queue_limits/inflight +Date: November 2011 +KernelVersion: 3.3 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of bytes (objects) in flight on this + network device transmit queue. + +What: /sys/class//queues/tx-/byte_queue_limits/limit +Date: November 2011 +KernelVersion: 3.3 +Contact: netdev@vger.kernel.org +Description: + Indicates the current limit of bytes allowed to be queued + on this network device transmit queue. This value is clamped + to be within the bounds defined by limit_max and limit_min. + +What: /sys/class//queues/tx-/byte_queue_limits/limit_max +Date: November 2011 +KernelVersion: 3.3 +Contact: netdev@vger.kernel.org +Description: + Indicates the absolute maximum limit of bytes allowed to be + queued on this network device transmit queue. See + include/linux/dynamic_queue_limits.h for the default value. + +What: /sys/class//queues/tx-/byte_queue_limits/limit_min +Date: November 2011 +KernelVersion: 3.3 +Contact: netdev@vger.kernel.org +Description: + Indicates the absolute minimum limit of bytes allowed to be + queued on this network device transmit queue. Default value is + 0. -- cgit v1.1 From 6044f9700645264c52f69033a2b4457b856202f7 Mon Sep 17 00:00:00 2001 From: Florian Fainelli Date: Fri, 23 May 2014 16:35:42 -0700 Subject: net: sysfs: document /sys/class/net/statistics/* Document the network device statistics counter that are exposed as sysfs attributes. Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller --- .../ABI/testing/sysfs-class-net-statistics | 201 +++++++++++++++++++++ 1 file changed, 201 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-net-statistics (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-net-statistics b/Documentation/ABI/testing/sysfs-class-net-statistics new file mode 100644 index 0000000..397118d --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-net-statistics @@ -0,0 +1,201 @@ +What: /sys/class//statistics/collisions +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of collisions seen by this network device. + This value might not be relevant with all MAC layers. + +What: /sys/class//statistics/multicast +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of multicast packets received by this + network device. + +What: /sys/class//statistics/rx_bytes +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of bytes received by this network device. + See the network driver for the exact meaning of when this + value is incremented. + +What: /sys/class//statistics/rx_compressed +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of compressed packets received by this + network device. This value might only be relevant for interfaces + that support packet compression (e.g: PPP). + +What: /sys/class//statistics/rx_crc_errors +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of packets received with a CRC (FCS) error + by this network device. Note that the specific meaning might + depend on the MAC layer used by the interface. + +What: /sys/class//statistics/rx_dropped +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of packets received by the network device + but dropped, that are not forwarded to the upper layers for + packet processing. See the network driver for the exact + meaning of this value. + +What: /sys/class//statistics/rx_fifo_errors +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of receive FIFO errors seen by this + network device. See the network driver for the exact + meaning of this value. + +What: /sys/class//statistics/rx_frame_errors +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of received frames with error, such as + alignment errors. Note that the specific meaning depends on + on the MAC layer protocol used. See the network driver for + the exact meaning of this value. + +What: /sys/class//statistics/rx_length_errors +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of received error packet with a length + error, oversized or undersized. See the network driver for the + exact meaning of this value. + +What: /sys/class//statistics/rx_missed_errors +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of received packets that have been missed + due to lack of capacity in the receive side. See the network + driver for the exact meaning of this value. + +What: /sys/class//statistics/rx_over_errors +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of received packets that are oversized + compared to what the network device is configured to accept + (e.g: larger than MTU). See the network driver for the exact + meaning of this value. + +What: /sys/class//statistics/rx_packets +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the total number of good packets received by this + network device. + +What: /sys/class//statistics/tx_aborted_errors +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of packets that have been aborted + during transmission by a network device (e.g: because of + a medium collision). See the network driver for the exact + meaning of this value. + +What: /sys/class//statistics/tx_bytes +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of bytes transmitted by a network + device. See the network driver for the exact meaning of this + value, in particular whether this accounts for all successfully + transmitted packets or all packets that have been queued for + transmission. + +What: /sys/class//statistics/tx_carrier_errors +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of packets that could not be transmitted + because of carrier errors (e.g: physical link down). See the + network driver for the exact meaning of this value. + +What: /sys/class//statistics/tx_compressed +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of transmitted compressed packets. Note + this might only be relevant for devices that support + compression (e.g: PPP). + +What: /sys/class//statistics/tx_dropped +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of packets dropped during transmission. + See the driver for the exact reasons as to why the packets were + dropped. + +What: /sys/class//statistics/tx_errors +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of packets in error during transmission by + a network device. See the driver for the exact reasons as to + why the packets were dropped. + +What: /sys/class//statistics/tx_fifo_errors +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of packets having caused a transmit + FIFO error. See the driver for the exact reasons as to why the + packets were dropped. + +What: /sys/class//statistics/tx_heartbeat_errors +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of packets transmitted that have been + reported as heartbeat errors. See the driver for the exact + reasons as to why the packets were dropped. + +What: /sys/class//statistics/tx_packets +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of packets transmitted by a network + device. See the driver for whether this reports the number of all + attempted or successful transmissions. + +What: /sys/class//statistics/tx_window_errors +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of packets not successfully transmitted + due to a window collision. The specific meaning depends on the + MAC layer used. On Ethernet this is usually used to report + late collisions errors. -- cgit v1.1 From e649c648469f947b4fa2ad79dd37510cdbafdce7 Mon Sep 17 00:00:00 2001 From: Kedareswara rao Appana Date: Wed, 21 May 2014 17:11:29 +0530 Subject: can: Add xilinx CAN device tree bindings documentation Add xilinx CAN bindings documentation. Signed-off-by: Kedareswara rao Appana Acked-by: Rob Herring Signed-off-by: Marc Kleine-Budde --- .../devicetree/bindings/net/can/xilinx_can.txt | 44 ++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/can/xilinx_can.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/can/xilinx_can.txt b/Documentation/devicetree/bindings/net/can/xilinx_can.txt new file mode 100644 index 0000000..fe38847 --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/xilinx_can.txt @@ -0,0 +1,44 @@ +Xilinx Axi CAN/Zynq CANPS controller Device Tree Bindings +--------------------------------------------------------- + +Required properties: +- compatible : Should be "xlnx,zynq-can-1.0" for Zynq CAN + controllers and "xlnx,axi-can-1.00.a" for Axi CAN + controllers. +- reg : Physical base address and size of the Axi CAN/Zynq + CANPS registers map. +- interrupts : Property with a value describing the interrupt + number. +- interrupt-parent : Must be core interrupt controller +- clock-names : List of input clock names - "can_clk", "pclk" + (For CANPS), "can_clk" , "s_axi_aclk"(For AXI CAN) + (See clock bindings for details). +- clocks : Clock phandles (see clock bindings for details). +- tx-fifo-depth : Can Tx fifo depth. +- rx-fifo-depth : Can Rx fifo depth. + + +Example: + +For Zynq CANPS Dts file: + zynq_can_0: can@e0008000 { + compatible = "xlnx,zynq-can-1.0"; + clocks = <&clkc 19>, <&clkc 36>; + clock-names = "can_clk", "pclk"; + reg = <0xe0008000 0x1000>; + interrupts = <0 28 4>; + interrupt-parent = <&intc>; + tx-fifo-depth = <0x40>; + rx-fifo-depth = <0x40>; + }; +For Axi CAN Dts file: + axi_can_0: axi-can@40000000 { + compatible = "xlnx,axi-can-1.00.a"; + clocks = <&clkc 0>, <&clkc 1>; + clock-names = "can_clk","s_axi_aclk" ; + reg = <0x40000000 0x10000>; + interrupt-parent = <&intc>; + interrupts = <0 59 1>; + tx-fifo-depth = <0x40>; + rx-fifo-depth = <0x40>; + }; -- cgit v1.1 From 0399d4db3edf5c58b6ec7f672f089f5085e49ed5 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Mon, 26 May 2014 13:40:59 +0200 Subject: PM / sleep: Introduce command line argument for sleep state enumeration On some systems the platform doesn't support neither PM_SUSPEND_MEM nor PM_SUSPEND_STANDBY, so PM_SUSPEND_FREEZE is the only available system sleep state. However, some user space frameworks only use the "mem" and (sometimes) "standby" sleep state labels, so the users of those systems need to modify user space in order to be able to use system suspend at all and that is not always possible. For this reason, add a new kernel command line argument, relative_sleep_states, allowing the users of those systems to change the way in which the kernel assigns labels to system sleep states. Namely, for relative_sleep_states=1, the "mem", "standby" and "freeze" labels will enumerate the available system sleem states from the deepest to the shallowest, respectively, so that "mem" is always present in /sys/power/state and the other state strings may or may not be presend depending on what is supported by the platform. Update system sleep states documentation to reflect this change. Signed-off-by: Rafael J. Wysocki --- Documentation/ABI/testing/sysfs-power | 29 ++++++++---- Documentation/kernel-parameters.txt | 7 +++ Documentation/power/states.txt | 87 ++++++++++++++++++++++------------- 3 files changed, 83 insertions(+), 40 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power index 64c9276..f455181 100644 --- a/Documentation/ABI/testing/sysfs-power +++ b/Documentation/ABI/testing/sysfs-power @@ -7,19 +7,30 @@ Description: subsystem. What: /sys/power/state -Date: August 2006 +Date: May 2014 Contact: Rafael J. Wysocki Description: - The /sys/power/state file controls the system power state. - Reading from this file returns what states are supported, - which is hard-coded to 'freeze' (Low-Power Idle), 'standby' - (Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk' - (Suspend-to-Disk). + The /sys/power/state file controls system sleep states. + Reading from this file returns the available sleep state + labels, which may be "mem", "standby", "freeze" and "disk" + (hibernation). The meanings of the first three labels depend on + the relative_sleep_states command line argument as follows: + 1) relative_sleep_states = 1 + "mem", "standby", "freeze" represent non-hibernation sleep + states from the deepest ("mem", always present) to the + shallowest ("freeze"). "standby" and "freeze" may or may + not be present depending on the capabilities of the + platform. "freeze" can only be present if "standby" is + present. + 2) relative_sleep_states = 0 (default) + "mem" - "suspend-to-RAM", present if supported. + "standby" - "power-on suspend", present if supported. + "freeze" - "suspend-to-idle", always present. Writing to this file one of these strings causes the system to - transition into that state. Please see the file - Documentation/power/states.txt for a description of each of - these states. + transition into the corresponding state, if available. See + Documentation/power/states.txt for a description of what + "suspend-to-RAM", "power-on suspend" and "suspend-to-idle" mean. What: /sys/power/disk Date: September 2006 diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 4384217..e19a88b 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2889,6 +2889,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted. [KNL, SMP] Set scheduler's default relax_domain_level. See Documentation/cgroups/cpusets.txt. + relative_sleep_states= + [SUSPEND] Use sleep state labeling where the deepest + state available other than hibernation is always "mem". + Format: { "0" | "1" } + 0 -- Traditional sleep state labels. + 1 -- Relative sleep state labels. + reserve= [KNL,BUGS] Force the kernel to ignore some iomem area reservetop= [X86-32] diff --git a/Documentation/power/states.txt b/Documentation/power/states.txt index 442d43d..50f3ef9 100644 --- a/Documentation/power/states.txt +++ b/Documentation/power/states.txt @@ -1,62 +1,87 @@ +System Power Management Sleep States -System Power Management States +(C) 2014 Intel Corp., Rafael J. Wysocki +The kernel supports up to four system sleep states generically, although three +of them depend on the platform support code to implement the low-level details +for each state. -The kernel supports four power management states generically, though -one is generic and the other three are dependent on platform support -code to implement the low-level details for each state. -This file describes each state, what they are -commonly called, what ACPI state they map to, and what string to write -to /sys/power/state to enter that state +The states are represented by strings that can be read or written to the +/sys/power/state file. Those strings may be "mem", "standby", "freeze" and +"disk", where the last one always represents hibernation (Suspend-To-Disk) and +the meaning of the remaining ones depends on the relative_sleep_states command +line argument. -state: Freeze / Low-Power Idle +For relative_sleep_states=1, the strings "mem", "standby" and "freeze" label the +available non-hibernation sleep states from the deepest to the shallowest, +respectively. In that case, "mem" is always present in /sys/power/state, +because there is at least one non-hibernation sleep state in every system. If +the given system supports two non-hibernation sleep states, "standby" is present +in /sys/power/state in addition to "mem". If the system supports three +non-hibernation sleep states, "freeze" will be present in /sys/power/state in +addition to "mem" and "standby". + +For relative_sleep_states=0, which is the default, the following descriptions +apply. + +state: Suspend-To-Idle ACPI state: S0 -String: "freeze" +Label: "freeze" -This state is a generic, pure software, light-weight, low-power state. -It allows more energy to be saved relative to idle by freezing user +This state is a generic, pure software, light-weight, system sleep state. +It allows more energy to be saved relative to runtime idle by freezing user space and putting all I/O devices into low-power states (possibly lower-power than available at run time), such that the processors can spend more time in their idle states. -This state can be used for platforms without Standby/Suspend-to-RAM + +This state can be used for platforms without Power-On Suspend/Suspend-to-RAM support, or it can be used in addition to Suspend-to-RAM (memory sleep) -to provide reduced resume latency. +to provide reduced resume latency. It is always supported. State: Standby / Power-On Suspend ACPI State: S1 -String: "standby" +Label: "standby" -This state offers minimal, though real, power savings, while providing -a very low-latency transition back to a working system. No operating -state is lost (the CPU retains power), so the system easily starts up +This state, if supported, offers moderate, though real, power savings, while +providing a relatively low-latency transition back to a working system. No +operating state is lost (the CPU retains power), so the system easily starts up again where it left off. -We try to put devices in a low-power state equivalent to D1, which -also offers low power savings, but low resume latency. Not all devices -support D1, and those that don't are left on. +In addition to freezing user space and putting all I/O devices into low-power +states, which is done for Suspend-To-Idle too, nonboot CPUs are taken offline +and all low-level system functions are suspended during transitions into this +state. For this reason, it should allow more energy to be saved relative to +Suspend-To-Idle, but the resume latency will generally be greater than for that +state. State: Suspend-to-RAM ACPI State: S3 -String: "mem" +Label: "mem" -This state offers significant power savings as everything in the -system is put into a low-power state, except for memory, which is -placed in self-refresh mode to retain its contents. +This state, if supported, offers significant power savings as everything in the +system is put into a low-power state, except for memory, which should be placed +into the self-refresh mode to retain its contents. All of the steps carried out +when entering Power-On Suspend are also carried out during transitions to STR. +Additional operations may take place depending on the platform capabilities. In +particular, on ACPI systems the kernel passes control to the BIOS (platform +firmware) as the last step during STR transitions and that usually results in +powering down some more low-level components that aren't directly controlled by +the kernel. -System and device state is saved and kept in memory. All devices are -suspended and put into D3. In many cases, all peripheral buses lose -power when entering STR, so devices must be able to handle the -transition back to the On state. +System and device state is saved and kept in memory. All devices are suspended +and put into low-power states. In many cases, all peripheral buses lose power +when entering STR, so devices must be able to handle the transition back to the +"on" state. -For at least ACPI, STR requires some minimal boot-strapping code to -resume the system from STR. This may be true on other platforms. +For at least ACPI, STR requires some minimal boot-strapping code to resume the +system from it. This may be the case on other platforms too. State: Suspend-to-disk ACPI State: S4 -String: "disk" +Label: "disk" This state offers the greatest power savings, and can be used even in the absence of low-level platform support for power management. This -- cgit v1.1 From 2942a0e285c46587a1025f12597df63ec04d08c6 Mon Sep 17 00:00:00 2001 From: Andrew Lunn Date: Thu, 22 May 2014 17:31:49 +0200 Subject: ASoC: simple-card: Support setting mclk via a fixed factor Some platforms require that the codecs mclk is a fixed multiplication factor of the audio stream rate. Add a optional property to the binding to hold this factor and implement a hw_params() function to make use of it. Signed-off-by: Andrew Lunn Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/simple-card.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt b/Documentation/devicetree/bindings/sound/simple-card.txt index 9b9df14..c2e9841 100644 --- a/Documentation/devicetree/bindings/sound/simple-card.txt +++ b/Documentation/devicetree/bindings/sound/simple-card.txt @@ -15,6 +15,9 @@ Optional properties: Each entry is a pair of strings, the first being the connection's sink, the second being the connection's source. +- simple-audio-card,mclk-fs : Multiplication factor between stream rate and codec + mclk. + Optional subnodes: - simple-audio-card,dai-link : Container for dai-link level -- cgit v1.1 From 199e7688bdf7d188d70c3432c96ec13d8a14b341 Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Thu, 22 May 2014 23:25:49 -0700 Subject: ASoC: rsnd: care DMA slave channel name for DT Renesas sound driver is supporting to use DMAEngine. But, DMA slave channel name "tx", "rx" is not enough in DT case. Becuase, it has many ports and path combination. This patch adds rsnd_dma_of_name() to find DMA channel name, for example memory to SSI0 is "mem_ssi0", SSI0 to memory is "ssi0_mem", SSI0 to SRC0 is "ssi0_src0", SRC0 to SSI0 is "src0_ssi0", SRC0 to DVC0 is "src0_dvc0"... Renesas sound want to use PIO transfer mode for some reasons. It will be PIO tranfer mode if device node doesn't have DMA settings. Signed-off-by: Kuninori Morimoto Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/renesas,rsnd.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt index a44e917..8346cab 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt @@ -20,6 +20,7 @@ Required properties: SSI subnode properties: - interrupts : Should contain SSI interrupt for PIO transfer - shared-pin : if shared clock pin +- pio-transfer : use PIO transfer mode SRC subnode properties: no properties at this point -- cgit v1.1 From cc9d190e48bc66e2e184a461e47d15c004724889 Mon Sep 17 00:00:00 2001 From: Philipp Zabel Date: Mon, 26 May 2014 10:38:14 +0200 Subject: of: Add vendor prefix for Linear Technology Corporation Add Linear Technology Corporation to the list of device tree vendor prefixes. Signed-off-by: Philipp Zabel Signed-off-by: Mark Brown --- 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 0f01c9b..98e739f 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -65,6 +65,7 @@ lantiq Lantiq Semiconductor lg LG Corporation linux Linux-specific binding lsi LSI Corp. (LSI Logic) +lltc Linear Technology Corporation marvell Marvell Technology Group Ltd. maxim Maxim Integrated Products microchip Microchip Technology Inc. -- cgit v1.1 From a3cd1de4ed19831fec98f981e348522e249a4e7a Mon Sep 17 00:00:00 2001 From: Philipp Zabel Date: Mon, 26 May 2014 10:38:15 +0200 Subject: regulator: ltc3589: Add DT binding documentation This patch adds the device tree binding documentation for Linear Technology LTC3589, LTC3589-1, and LTC3589-2 8-port regulators. Signed-off-by: Philipp Zabel Signed-off-by: Mark Brown --- .../devicetree/bindings/regulator/ltc3589.txt | 99 ++++++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/ltc3589.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/ltc3589.txt b/Documentation/devicetree/bindings/regulator/ltc3589.txt new file mode 100644 index 0000000..8010530 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/ltc3589.txt @@ -0,0 +1,99 @@ +Linear Technology LTC3589, LTC3589-1, and LTC3589-2 8-output regulators + +Required properties: +- compatible: "lltc,ltc3589", "lltc,ltc3589-1" or "lltc,ltc3589-2" +- reg: I2C slave address + +Required child node: +- regulators: Contains eight regulator child nodes sw1, sw2, sw3, bb-out, + ldo1, ldo2, ldo3, and ldo4, specifying the initialization data as + documented in Documentation/devicetree/bindings/regulator/regulator.txt. + +Each regulator is defined using the standard binding for regulators. The +nodes for sw1, sw2, sw3, bb-out, ldo1, and ldo2 additionally need to specify +the resistor values of their external feedback voltage dividers: + +Required properties (not on ldo3, ldo4): +- lltc,fb-voltage-divider: An array of two integers containing the resistor + values R1 and R2 of the feedback voltage divider in ohms. + +Regulators sw1, sw2, sw3, and ldo2 can regulate the feedback reference from +0.3625 V to 0.75 V in 12.5 mV steps. The output voltage thus ranges between +0.3625 * (1 + R1/R2) V and 0.75 * (1 + R1/R2) V. Regulators bb-out and ldo1 +have a fixed 0.8 V reference and thus output 0.8 * (1 + R1/R2) V. The ldo3 +regulator is fixed to 1.8 V on LTC3589 and to 2.8 V on LTC3589-1,2. The ldo4 +regulator can output between 1.8 V and 3.3 V on LTC3589 and between 1.2 V +and 3.2 V on LTC3589-1,2 in four steps. The ldo1 standby regulator can not +be disabled and thus should have the regulator-always-on property set. + +Example: + + ltc3589: pmic@34 { + compatible = "lltc,ltc3589-1"; + reg = <0x34>; + + regulators { + sw1_reg: sw1 { + regulator-min-microvolt = <591930>; + regulator-max-microvolt = <1224671>; + lltc,fb-voltage-divider = <100000 158000>; + regulator-ramp-delay = <7000>; + regulator-boot-on; + regulator-always-on; + }; + + sw2_reg: sw2 { + regulator-min-microvolt = <704123>; + regulator-max-microvolt = <1456803>; + lltc,fb-voltage-divider = <180000 191000>; + regulator-ramp-delay = <7000>; + regulator-boot-on; + regulator-always-on; + }; + + sw3_reg: sw3 { + regulator-min-microvolt = <1341250>; + regulator-max-microvolt = <2775000>; + lltc,fb-voltage-divider = <270000 100000>; + regulator-ramp-delay = <7000>; + regulator-boot-on; + regulator-always-on; + }; + + bb_out_reg: bb-out { + regulator-min-microvolt = <3387341>; + regulator-max-microvolt = <3387341>; + lltc,fb-voltage-divider = <511000 158000>; + regulator-boot-on; + regulator-always-on; + }; + + ldo1_reg: ldo1 { + regulator-min-microvolt = <1306329>; + regulator-max-microvolt = <1306329>; + lltc,fb-voltage-divider = <100000 158000>; + regulator-boot-on; + regulator-always-on; + }; + + ldo2_reg: ldo2 { + regulator-min-microvolt = <704123>; + regulator-max-microvolt = <1456806>; + lltc,fb-voltage-divider = <180000 191000>; + regulator-ramp-delay = <7000>; + regulator-boot-on; + regulator-always-on; + }; + + ldo3_reg: ldo3 { + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + regulator-boot-on; + }; + + ldo4_reg: ldo4 { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3200000>; + }; + }; + }; -- cgit v1.1 From b10ab7b838bdd86031aececcb386dc253ef3466f Mon Sep 17 00:00:00 2001 From: Tushar Behera Date: Mon, 26 May 2014 13:58:21 +0530 Subject: ASoC: max98090: Add master clock handling If master clock is provided through device tree, then update the master clock frequency during set_sysclk. Documentation has been updated to reflect the change. Signed-off-by: Tushar Behera Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/max98090.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/max98090.txt b/Documentation/devicetree/bindings/sound/max98090.txt index e4c8b36..a5e63fa 100644 --- a/Documentation/devicetree/bindings/sound/max98090.txt +++ b/Documentation/devicetree/bindings/sound/max98090.txt @@ -10,6 +10,12 @@ Required properties: - interrupts : The CODEC's interrupt output. +Optional properties: + +- clocks: The phandle of the master clock to the CODEC + +- clock-names: Should be "mclk" + Pins on the device (for linking into audio routes): * MIC1 -- cgit v1.1 From e3048c3d2be5b4a1c6a66db3bf3829c77b7788e0 Mon Sep 17 00:00:00 2001 From: Tushar Behera Date: Mon, 26 May 2014 13:58:22 +0530 Subject: ASoC: max98095: Add master clock handling If master clock is provided through device tree, then update the master clock frequency during set_sysclk. Documentation has been updated to reflect the change. Signed-off-by: Tushar Behera Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/max98095.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/max98095.txt b/Documentation/devicetree/bindings/sound/max98095.txt index bacbeaa..318a4c8 100644 --- a/Documentation/devicetree/bindings/sound/max98095.txt +++ b/Documentation/devicetree/bindings/sound/max98095.txt @@ -8,6 +8,12 @@ Required properties: - reg : The I2C address of the device. +Optional properties: + +- clocks: The phandle of the master clock to the CODEC + +- clock-names: Should be "mclk" + Example: max98095: codec@11 { -- cgit v1.1 From 26ab69cb4c1f77060bece483f2ec210163867782 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Heiko=20St=C3=BCbner?= Date: Thu, 27 Mar 2014 01:06:32 +0100 Subject: ARM: rockchip: convert smp bringup to CPU_METHOD_OF_DECLARE With the newly introduced CPU_METHOD_OF_DECLARE is not necessary anymore to reference the relevant smp_ops in the board file, but instead it can simply be set by the enable-method property of the cpu nodes. Signed-off-by: Heiko Stuebner Signed-off-by: Olof Johansson --- Documentation/devicetree/bindings/arm/cpus.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index e4b6daf..dffcac8 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -190,6 +190,7 @@ nodes to be present and contain the properties described below. "marvell,armada-375-smp" "marvell,armada-380-smp" "marvell,armada-xp-smp" + "rockchip,rk3066-smp" - cpu-release-addr Usage: required for systems that have an "enable-method" -- cgit v1.1 From e1dc566f43fe2540ad085b1410cc130a06f69557 Mon Sep 17 00:00:00 2001 From: Olof Johansson Date: Mon, 26 May 2014 11:14:36 -0700 Subject: Documentation: devicetree: arm: sort enable-method entries People have appended new entries instead of inserting them at the right location, so sort them. Signed-off-by: Olof Johansson --- Documentation/devicetree/bindings/arm/cpus.txt | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index dffcac8..1fe72a0 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -178,18 +178,18 @@ nodes to be present and contain the properties described below. Usage and definition depend on ARM architecture version. # On ARM v8 64-bit this property is required and must be one of: - "spin-table" "psci" + "spin-table" # On ARM 32-bit systems this property is optional and can be one of: - "arm,psci" "allwinner,sun6i-a31" - "qcom,gcc-msm8660" - "qcom,kpss-acc-v1" - "qcom,kpss-acc-v2" + "arm,psci" "marvell,armada-375-smp" "marvell,armada-380-smp" "marvell,armada-xp-smp" + "qcom,gcc-msm8660" + "qcom,kpss-acc-v1" + "qcom,kpss-acc-v2" "rockchip,rk3066-smp" - cpu-release-addr -- cgit v1.1 From f311a724a79669ac0336932d0361325afdb54279 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Tue, 20 May 2014 16:56:27 -0600 Subject: DMA-API: Capitalize "CPU" consistently Sometimes we used "cpu," other times "CPU." Use "CPU" consistently. Suggested-by: Randy Dunlap Signed-off-by: Bjorn Helgaas --- Documentation/DMA-API-HOWTO.txt | 8 ++++---- Documentation/DMA-API.txt | 12 ++++++------ 2 files changed, 10 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt index fd3727b..f599553 100644 --- a/Documentation/DMA-API-HOWTO.txt +++ b/Documentation/DMA-API-HOWTO.txt @@ -575,10 +575,10 @@ Incorrect example 2: You should call dma_unmap_single() when the DMA activity is finished, e.g., from the interrupt which told you that the DMA transfer is done. -Using cpu pointers like this for single mappings has a disadvantage: +Using CPU pointers like this for single mappings has a disadvantage: you cannot reference HIGHMEM memory in this way. Thus, there is a map/unmap interface pair akin to dma_{map,unmap}_single(). These -interfaces deal with page/offset pairs instead of cpu pointers. +interfaces deal with page/offset pairs instead of CPU pointers. Specifically: struct device *dev = &my_dev->dev; @@ -650,7 +650,7 @@ you could render the machine unusable by consuming all bus addresses. If you need to use the same streaming DMA region multiple times and touch the data in between the DMA transfers, the buffer needs to be synced -properly in order for the cpu and device to see the most up-to-date and +properly in order for the CPU and device to see the most up-to-date and correct copy of the DMA buffer. So, firstly, just map it with dma_map_{single,sg}(), and after each DMA @@ -665,7 +665,7 @@ or: as appropriate. Then, if you wish to let the device get at the DMA area again, -finish accessing the data with the cpu, and then before actually +finish accessing the data with the CPU, and then before actually giving the buffer to the hardware call either: dma_sync_single_for_device(dev, dma_handle, size, direction); diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index 4f1cdc5..5208840 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt @@ -19,7 +19,7 @@ To get the dma_ API, you must #include . This provides dma_addr_t and the interfaces described below. A dma_addr_t can hold any valid DMA or bus address for the platform. It -can be given to a device to use as a DMA source or target. A cpu cannot +can be given to a device to use as a DMA source or target. A CPU cannot reference a dma_addr_t directly because there may be translation between its physical address space and the bus address space. @@ -112,7 +112,7 @@ size and alignment requirements specified at creation time. Pass GFP_ATOMIC to prevent blocking, or if it's permitted (not in_interrupt, not holding SMP locks), pass GFP_KERNEL to allow blocking. Like dma_alloc_coherent(), this returns two values: an -address usable by the cpu, and the DMA address usable by the pool's +address usable by the CPU, and the DMA address usable by the pool's device. @@ -120,7 +120,7 @@ device. dma_addr_t addr); This puts memory back into the pool. The pool is what was passed to -dma_pool_alloc(); the cpu (vaddr) and DMA addresses are what +dma_pool_alloc(); the CPU (vaddr) and DMA addresses are what were returned when that routine allocated the memory being freed. @@ -355,7 +355,7 @@ void dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nelems, enum dma_data_direction direction) -Synchronise a single contiguous or scatter/gather mapping for the cpu +Synchronise a single contiguous or scatter/gather mapping for the CPU and device. With the sync_sg API, all the parameters must be the same as those passed into the single mapping API. With the sync_single API, you can use dma_handle and size parameters that aren't identical to @@ -504,8 +504,8 @@ dma_declare_coherent_memory(struct device *dev, phys_addr_t phys_addr, Declare region of memory to be handed out by dma_alloc_coherent() when it's asked for coherent memory for this device. -phys_addr is the cpu physical address to which the memory is currently -assigned (this will be ioremapped so the cpu can access the region). +phys_addr is the CPU physical address to which the memory is currently +assigned (this will be ioremapped so the CPU can access the region). device_addr is the bus address the device needs to be programmed with to actually address this memory (this will be handed out as the -- cgit v1.1 From 34c815fbdc1257e823726f8c6bcd9255d495058d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Emilio=20L=C3=B3pez?= Date: Tue, 20 May 2014 16:54:22 -0600 Subject: DMA-API: Fix duplicated word in DMA-API-HOWTO.txt MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit "coherent" is written twice when it should be just once. Signed-off-by: Emilio López Signed-off-by: Bjorn Helgaas --- Documentation/DMA-API-HOWTO.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt index f599553..b22ceff 100644 --- a/Documentation/DMA-API-HOWTO.txt +++ b/Documentation/DMA-API-HOWTO.txt @@ -249,10 +249,10 @@ the case would look like this: goto ignore_this_device; } -The coherent coherent mask will always be able to set the same or a -smaller mask as the streaming mask. However for the rare case that a -device driver only uses consistent allocations, one would have to -check the return value from dma_set_coherent_mask(). +The coherent mask will always be able to set the same or a smaller mask as +the streaming mask. However for the rare case that a device driver only +uses consistent allocations, one would have to check the return value from +dma_set_coherent_mask(). Finally, if your device can only drive the low 24-bits of address you might do something like: -- cgit v1.1 From 2af9da8638a139303b3cd535b458a1b2c80dd4f3 Mon Sep 17 00:00:00 2001 From: Gioh Kim Date: Tue, 20 May 2014 17:09:35 -0600 Subject: DMA-API: Update dma_pool_create ()and dma_pool_alloc() descriptions Use "boundary" to be more descriptive than "alloc" in the dma_pool_create() documentation. Replace "SLAB_KERNEL" and "SLAB_ATOMIC" with the correct "GFP_KERNEL" and "GFP_ATOMIC." [bhelgaas: changelog] Signed-off-by: Gioh Kim Signed-off-by: Bjorn Helgaas --- Documentation/DMA-API-HOWTO.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt index b22ceff..dcbbe36 100644 --- a/Documentation/DMA-API-HOWTO.txt +++ b/Documentation/DMA-API-HOWTO.txt @@ -429,13 +429,13 @@ Create a dma_pool like this: struct dma_pool *pool; - pool = dma_pool_create(name, dev, size, align, alloc); + pool = dma_pool_create(name, dev, size, align, boundary); The "name" is for diagnostics (like a kmem_cache name); dev and size are as above. The device's hardware alignment requirement for this type of data is "align" (which is expressed in bytes, and must be a power of two). If your device has no boundary crossing restrictions, -pass 0 for alloc; passing 4096 says memory allocated from this pool +pass 0 for boundary; passing 4096 says memory allocated from this pool must not cross 4KByte boundaries (but at that time it may be better to use dma_alloc_coherent() directly instead). @@ -443,8 +443,8 @@ Allocate memory from a DMA pool like this: cpu_addr = dma_pool_alloc(pool, flags, &dma_handle); -flags are SLAB_KERNEL if blocking is permitted (not in_interrupt nor -holding SMP locks), SLAB_ATOMIC otherwise. Like dma_alloc_coherent(), +flags are GFP_KERNEL if blocking is permitted (not in_interrupt nor +holding SMP locks), GFP_ATOMIC otherwise. Like dma_alloc_coherent(), this returns two values, cpu_addr and dma_handle. Free memory that was allocated from a dma_pool like this: -- cgit v1.1 From 6c6a3996f2c598b860f96731a158641837b50932 Mon Sep 17 00:00:00 2001 From: Sagar Kamble Date: Tue, 11 Mar 2014 19:55:29 +0530 Subject: Documentation: drm: describing drm properties exposed by various drivers MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Started documenting drm properties for drm drivers. This patch provides information about properties in drm, i915, psb and cdv/gma-500. Information about other properties can be added on top of these. v2: Added description of drm properties in armada, exynos, i2c/ch7006, noveau, omap, qxl, radeon, rcar-du v3: Removed "Property Object" column since it is implementation related. Property type column refined.[Ville's review comments] v4: Removed whitespace warnings and minor nits. [Randy's review comments] v5: Restructured output for ENUM properties v6: Review comments on formatting the table. [Laurent's review comments] v7: Minor restructuring. [Laurent's review comments] Cc: Rob Landley Cc: Dave Airlie Cc: Daniel Vetter Acked-by: Laurent Pinchart Cc: David Herrmann Cc: Alex Deucher Cc: "Ville Syrjälä" Cc: Sagar Kamble Cc: "Purushothaman, Vijay A" Cc: linux-doc@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Sagar Kamble Signed-off-by: Dave Airlie --- Documentation/DocBook/drm.tmpl | 849 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 849 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index a21cdd5..c1c9cf2 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -2442,6 +2442,855 @@ void intel_crt_init(struct drm_device *dev) pointer to the target object, a pointer to the previously created property and an initial instance value. + + Existing KMS Properties + + The following table gives description of drm properties exposed by various + modules/drivers. + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Owner Module/DriversGroupProperty NameTypeProperty ValuesObject attachedDescription/Restrictions
DRMGeneric“EDID”BLOB | IMMUTABLE0ConnectorContains id of edid blob ptr object.
“DPMS”ENUM{ “On”, “Standby”, “Suspend”, “Off” }ConnectorContains DPMS operation mode value.
DVI-I“subconnector”ENUM{ “Unknown”, “DVI-D”, “DVI-A” }ConnectorTBD
“select subconnector”ENUM{ “Automatic”, “DVI-D”, “DVI-A” }ConnectorTBD
TV“subconnector”ENUM{ "Unknown", "Composite", "SVIDEO", "Component", "SCART" }ConnectorTBD
“select subconnector”ENUM{ "Automatic", "Composite", "SVIDEO", "Component", "SCART" }ConnectorTBD
“mode”ENUM{ "NTSC_M", "NTSC_J", "NTSC_443", "PAL_B" } etc.ConnectorTBD
“left margin”RANGEMin=0, Max=100ConnectorTBD
“right margin”RANGEMin=0, Max=100ConnectorTBD
“top margin”RANGEMin=0, Max=100ConnectorTBD
“bottom margin”RANGEMin=0, Max=100ConnectorTBD
“brightness”RANGEMin=0, Max=100ConnectorTBD
“contrast”RANGEMin=0, Max=100ConnectorTBD
“flicker reduction”RANGEMin=0, Max=100ConnectorTBD
“overscan”RANGEMin=0, Max=100ConnectorTBD
“saturation”RANGEMin=0, Max=100ConnectorTBD
“hue”RANGEMin=0, Max=100ConnectorTBD
Optional“scaling mode”ENUM{ "None", "Full", "Center", "Full aspect" }ConnectorTBD
“dirty”ENUM | IMMUTABLE{ "Off", "On", "Annotate" }ConnectorTBD
i915Generic"Broadcast RGB"ENUM{ "Automatic", "Full", "Limited 16:235" }ConnectorTBD
“audio”ENUM{ "force-dvi", "off", "auto", "on" }ConnectorTBD
Standard name as in DRMStandard type as in DRMStandard value as in DRMStandard Object as in DRMTBD
SDVO-TV“mode”ENUM{ "NTSC_M", "NTSC_J", "NTSC_443", "PAL_B" } etc.ConnectorTBD
"left_margin"RANGEMin=0, Max= SDVO dependentConnectorTBD
"right_margin"RANGEMin=0, Max= SDVO dependentConnectorTBD
"top_margin"RANGEMin=0, Max= SDVO dependentConnectorTBD
"bottom_margin"RANGEMin=0, Max= SDVO dependentConnectorTBD
“hpos”RANGEMin=0, Max= SDVO dependentConnectorTBD
“vpos”RANGEMin=0, Max= SDVO dependentConnectorTBD
“contrast”RANGEMin=0, Max= SDVO dependentConnectorTBD
“saturation”RANGEMin=0, Max= SDVO dependentConnectorTBD
“hue”RANGEMin=0, Max= SDVO dependentConnectorTBD
“sharpness”RANGEMin=0, Max= SDVO dependentConnectorTBD
“flicker_filter”RANGEMin=0, Max= SDVO dependentConnectorTBD
“flicker_filter_adaptive”RANGEMin=0, Max= SDVO dependentConnectorTBD
“flicker_filter_2d”RANGEMin=0, Max= SDVO dependentConnectorTBD
“tv_chroma_filter”RANGEMin=0, Max= SDVO dependentConnectorTBD
“tv_luma_filter”RANGEMin=0, Max= SDVO dependentConnectorTBD
“dot_crawl”RANGEMin=0, Max=1ConnectorTBD
SDVO-TV/LVDS“brightness”RANGEMin=0, Max= SDVO dependentConnectorTBD
CDV gma-500Generic"Broadcast RGB"ENUM{ “Full”, “Limited 16:235” }ConnectorTBD
"Broadcast RGB"ENUM{ “off”, “auto”, “on” }ConnectorTBD
Standard name as in DRMStandard type as in DRMStandard value as in DRMStandard Object as in DRMTBD
PoulsboGeneric“backlight”RANGEMin=0, Max=100ConnectorTBD
Standard name as in DRMStandard type as in DRMStandard value as in DRMStandard Object as in DRMTBD
SDVO-TV“mode”ENUM{ "NTSC_M", "NTSC_J", "NTSC_443", "PAL_B" } etc.ConnectorTBD
"left_margin"RANGEMin=0, Max= SDVO dependentConnectorTBD
"right_margin"RANGEMin=0, Max= SDVO dependentConnectorTBD
"top_margin"RANGEMin=0, Max= SDVO dependentConnectorTBD
"bottom_margin"RANGEMin=0, Max= SDVO dependentConnectorTBD
“hpos”RANGEMin=0, Max= SDVO dependentConnectorTBD
“vpos”RANGEMin=0, Max= SDVO dependentConnectorTBD
“contrast”RANGEMin=0, Max= SDVO dependentConnectorTBD
“saturation”RANGEMin=0, Max= SDVO dependentConnectorTBD
“hue”RANGEMin=0, Max= SDVO dependentConnectorTBD
“sharpness”RANGEMin=0, Max= SDVO dependentConnectorTBD
“flicker_filter”RANGEMin=0, Max= SDVO dependentConnectorTBD
“flicker_filter_adaptive”RANGEMin=0, Max= SDVO dependentConnectorTBD
“flicker_filter_2d”RANGEMin=0, Max= SDVO dependentConnectorTBD
“tv_chroma_filter”RANGEMin=0, Max= SDVO dependentConnectorTBD
“tv_luma_filter”RANGEMin=0, Max= SDVO dependentConnectorTBD
“dot_crawl”RANGEMin=0, Max=1ConnectorTBD
SDVO-TV/LVDS“brightness”RANGEMin=0, Max= SDVO dependentConnectorTBD
armadaCRTC"CSC_YUV"ENUM{ "Auto" , "CCIR601", "CCIR709" }CRTCTBD
"CSC_RGB"ENUM{ "Auto", "Computer system", "Studio" }CRTCTBD
Overlay"colorkey"RANGEMin=0, Max=0xffffffPlaneTBD
"colorkey_min"RANGEMin=0, Max=0xffffffPlaneTBD
"colorkey_max"RANGEMin=0, Max=0xffffffPlaneTBD
"colorkey_val"RANGEMin=0, Max=0xffffffPlaneTBD
"colorkey_alpha"RANGEMin=0, Max=0xffffffPlaneTBD
"colorkey_mode"ENUM{ "disabled", "Y component", "U component" + , "V component", "RGB", “R component", "G component", "B component" }PlaneTBD
"brightness"RANGEMin=0, Max=256 + 255PlaneTBD
"contrast"RANGEMin=0, Max=0x7fffPlaneTBD
"saturation"RANGEMin=0, Max=0x7fffPlaneTBD
exynosCRTC“mode”ENUM{ "normal", "blank" }CRTCTBD
Overlay“zpos”RANGEMin=0, Max=MAX_PLANE-1PlaneTBD
i2c/ch7006_drvGeneric“scale”RANGEMin=0, Max=2ConnectorTBD
TVStandard names as in DRMStandard types as in DRMStandard Values as in DRMStandard object as in DRMTBD
“mode”ENUM{ "PAL", "PAL-M","PAL-N"}, ”PAL-Nc" + , "PAL-60", "NTSC-M", "NTSC-J" }ConnectorTBD
noveauNV10 Overlay"colorkey"RANGEMin=0, Max=0x01ffffffPlaneTBD
“contrast”RANGEMin=0, Max=8192-1PlaneTBD
“brightness”RANGEMin=0, Max=1024PlaneTBD
“hue”RANGEMin=0, Max=359PlaneTBD
“saturation”RANGEMin=0, Max=8192-1PlaneTBD
“iturbt_709”RANGEMin=0, Max=1PlaneTBD
Nv04 Overlay“colorkey”RANGEMin=0, Max=0x01ffffffPlaneTBD
“brightness”RANGEMin=0, Max=1024PlaneTBD
Display“dithering mode”ENUM{ "auto", "off", "on" }ConnectorTBD
“dithering depth”ENUM{ "auto", "off", "on", "static 2x2", "dynamic 2x2", "temporal" }ConnectorTBD
“underscan”ENUM{ "auto", "6 bpc", "8 bpc" }ConnectorTBD
“underscan hborder”RANGEMin=0, Max=128ConnectorTBD
“underscan vborder”RANGEMin=0, Max=128ConnectorTBD
“vibrant hue”RANGEMin=0, Max=180ConnectorTBD
“color vibrance”RANGEMin=0, Max=200ConnectorTBD
GenericStandard name as in DRMStandard type as in DRMStandard value as in DRMStandard Object as in DRMTBD
omapGeneric“rotation”BITMASK{ 0, "rotate-0" }, + { 1, "rotate-90" }, + { 2, "rotate-180" }, + { 3, "rotate-270" }, + { 4, "reflect-x" }, + { 5, "reflect-y" }CRTC, PlaneTBD
“zorder”RANGEMin=0, Max=3CRTC, PlaneTBD
qxlGeneric“hotplug_mode_update"RANGEMin=0, Max=1ConnectorTBD
radeonDVI-I“coherent”RANGEMin=0, Max=1ConnectorTBD
DAC enable load detect“load detection”RANGEMin=0, Max=1ConnectorTBD
TV Standard"tv standard"ENUM{ "ntsc", "pal", "pal-m", "pal-60", "ntsc-j" + , "scart-pal", "pal-cn", "secam" }ConnectorTBD
legacy TMDS PLL detect"tmds_pll"ENUM{ "driver", "bios" }-TBD
Underscan"underscan"ENUM{ "off", "on", "auto" }ConnectorTBD
"underscan hborder"RANGEMin=0, Max=128ConnectorTBD
"underscan vborder"RANGEMin=0, Max=128ConnectorTBD
Audio“audio”ENUM{ "off", "on", "auto" }ConnectorTBD
FMT Dithering“dither”ENUM{ "off", "on" }ConnectorTBD
GenericStandard name as in DRMStandard type as in DRMStandard value as in DRMStandard Object as in DRMTBD
rcar-duGeneric"alpha"RANGEMin=0, Max=255PlaneTBD
"colorkey"RANGEMin=0, Max=0x01ffffffPlaneTBD
"zpos"RANGEMin=1, Max=7PlaneTBD
+ -- cgit v1.1 From a257954bb38ab23dbf93df812b4b2c01cae29d8b Mon Sep 17 00:00:00 2001 From: Jiang Liu Date: Tue, 27 May 2014 16:07:37 +0800 Subject: genirq: Improve documentation to match current implementation Signed-off-by: Jiang Liu Cc: Konrad Rzeszutek Wilk Cc: Tony Luck Cc: Joerg Roedel Cc: Paul Gortmaker Cc: Greg Kroah-Hartman Cc: Benjamin Herrenschmidt Cc: Grant Likely Cc: Rafael J. Wysocki Cc: Bjorn Helgaas Cc: Randy Dunlap Cc: Yinghai Lu Cc: Jiri Kosina Link: http://lkml.kernel.org/r/1401178092-1228-3-git-send-email-jiang.liu@linux.intel.com Signed-off-by: Thomas Gleixner --- Documentation/IRQ-domain.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/IRQ-domain.txt b/Documentation/IRQ-domain.txt index 03df71a..8a8b82c 100644 --- a/Documentation/IRQ-domain.txt +++ b/Documentation/IRQ-domain.txt @@ -41,8 +41,7 @@ An interrupt controller driver creates and registers an irq_domain by calling one of the irq_domain_add_*() functions (each mapping method has a different allocator function, more on that later). The function will return a pointer to the irq_domain on success. The caller must -provide the allocator function with an irq_domain_ops structure with -the .map callback populated as a minimum. +provide the allocator function with an irq_domain_ops structure. In most cases, the irq_domain will begin empty without any mappings between hwirq and IRQ numbers. Mappings are added to the irq_domain -- cgit v1.1 From 2cc140fe360732bc5467df3ad932685c76078dd4 Mon Sep 17 00:00:00 2001 From: Anson Huang Date: Mon, 12 May 2014 23:10:35 +0800 Subject: pinctrl: add pinctrl driver for imx6sx Add a pinctrl driver for i.MX6 SoloX based on pinctrl-imx core driver. Signed-off-by: Anson Huang Signed-off-by: Shawn Guo Signed-off-by: Linus Walleij --- .../bindings/pinctrl/fsl,imx6sx-pinctrl.txt | 36 ++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx6sx-pinctrl.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6sx-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sx-pinctrl.txt new file mode 100644 index 0000000..b1b5952 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sx-pinctrl.txt @@ -0,0 +1,36 @@ +* Freescale i.MX6 SoloX IOMUX Controller + +Please refer to fsl,imx-pinctrl.txt in this directory for common binding part +and usage. + +Required properties: +- compatible: "fsl,imx6sx-iomuxc" +- fsl,pins: each entry consists of 6 integers and represents the mux and config + setting for one pin. The first 5 integers are specified using a PIN_FUNC_ID macro, which can be found in + imx6sx-pinfunc.h under device tree source folder. The last integer CONFIG is + the pad setting value like pull-up on this pin. Please refer to i.MX6 SoloX + Reference Manual for detailed CONFIG settings. + +CONFIG bits definition: +PAD_CTL_HYS (1 << 16) +PAD_CTL_PUS_100K_DOWN (0 << 14) +PAD_CTL_PUS_47K_UP (1 << 14) +PAD_CTL_PUS_100K_UP (2 << 14) +PAD_CTL_PUS_22K_UP (3 << 14) +PAD_CTL_PUE (1 << 13) +PAD_CTL_PKE (1 << 12) +PAD_CTL_ODE (1 << 11) +PAD_CTL_SPEED_LOW (0 << 6) +PAD_CTL_SPEED_MED (1 << 6) +PAD_CTL_SPEED_HIGH (3 << 6) +PAD_CTL_DSE_DISABLE (0 << 3) +PAD_CTL_DSE_260ohm (1 << 3) +PAD_CTL_DSE_130ohm (2 << 3) +PAD_CTL_DSE_87ohm (3 << 3) +PAD_CTL_DSE_65ohm (4 << 3) +PAD_CTL_DSE_52ohm (5 << 3) +PAD_CTL_DSE_43ohm (6 << 3) +PAD_CTL_DSE_37ohm (7 << 3) +PAD_CTL_SRE_FAST (1 << 0) +PAD_CTL_SRE_SLOW (0 << 0) -- cgit v1.1 From caee0055337ab96a5af844fba6e72d518d7287dd Mon Sep 17 00:00:00 2001 From: Ivan Khoronzhuk Date: Fri, 23 May 2014 16:32:39 -0400 Subject: Documentation: dt: add bindings for keystone reset driver This node is intended to allow SoC reset in case of software reset or appropriate watchdogs. The Keystone SoCs can contain up to 4 watchdog timers to reset SoC. Each watchdog timer event input is connected to the Reset Mux block. The Reset Mux block can be configured to cause reset or not. Additionally soft or hard reset can be configured. Reviewed-by: Arnd Bergmann Signed-off-by: Ivan Khoronzhuk [santosh.shilimkar@ti.com: Fixed the subject line] Signed-off-by: Santosh Shilimkar --- .../bindings/power/reset/keystone-reset.txt | 67 ++++++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/reset/keystone-reset.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/reset/keystone-reset.txt b/Documentation/devicetree/bindings/power/reset/keystone-reset.txt new file mode 100644 index 0000000..c82f12e --- /dev/null +++ b/Documentation/devicetree/bindings/power/reset/keystone-reset.txt @@ -0,0 +1,67 @@ +* Device tree bindings for Texas Instruments keystone reset + +This node is intended to allow SoC reset in case of software reset +of selected watchdogs. + +The Keystone SoCs can contain up to 4 watchdog timers to reset +SoC. Each watchdog timer event input is connected to the Reset Mux +block. The Reset Mux block can be configured to cause reset or not. + +Additionally soft or hard reset can be configured. + +Required properties: + +- compatible: ti,keystone-reset + +- ti,syscon-pll: phandle/offset pair. The phandle to syscon used to + access pll controller registers and the offset to use + reset control registers. + +- ti,syscon-dev: phandle/offset pair. The phandle to syscon used to + access device state control registers and the offset + in order to use mux block registers for all watchdogs. + +Optional properties: + +- ti,soft-reset: Boolean option indicating soft reset. + By default hard reset is used. + +- ti,wdt-list: WDT list that can cause SoC reset. It's not related + to WDT driver, it's just needed to enable a SoC related + reset that's triggered by one of WDTs. The list is + in format: <0>, <2>; It can be in random order and + begins from 0 to 3, as keystone can contain up to 4 SoC + reset watchdogs and can be in random order. + +Example 1: +Setup keystone reset so that in case software reset or +WDT0 is triggered it issues hard reset for SoC. + +pllctrl: pll-controller@02310000 { + compatible = "ti,keystone-pllctrl", "syscon"; + reg = <0x02310000 0x200>; +}; + +devctrl: device-state-control@02620000 { + compatible = "ti,keystone-devctrl", "syscon"; + reg = <0x02620000 0x1000>; +}; + +rstctrl: reset-controller { + compatible = "ti,keystone-reset"; + ti,syscon-pll = <&pllctrl 0xe4>; + ti,syscon-dev = <&devctrl 0x328>; + ti,wdt-list = <0>; +}; + +Example 2: +Setup keystone reset so that in case of software reset or +WDT0 or WDT2 is triggered it issues soft reset for SoC. + +rstctrl: reset-controller { + compatible = "ti,keystone-reset"; + ti,syscon-pll = <&pllctrl 0xe4>; + ti,syscon-dev = <&devctrl 0x328>; + ti,wdt-list = <0>, <2>; + ti,soft-reset; +}; -- cgit v1.1 From d30982b93a79aafa688e7df1f6948ad28bb94e89 Mon Sep 17 00:00:00 2001 From: Ivan Khoronzhuk Date: Fri, 23 May 2014 16:32:39 -0400 Subject: Documentation: dt: add bindings for keystone pll control controller The main pll controller used to drive theC66x CorePacs, the switch fabric, and a majority of the peripheral clocks (all but the ARM CorePacs, DDR3 and the NETCP modules) requires a PLL Controller to manage the various clock divisions, gating, and synchronization. Reviewed-by: Arnd Bergmann Acked-by: Mike Turquette Signed-off-by: Ivan Khoronzhuk [santosh.shilimkar@ti.com: Fixed the subject line] Signed-off-by: Santosh Shilimkar --- .../bindings/clock/ti-keystone-pllctrl.txt | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/ti-keystone-pllctrl.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/ti-keystone-pllctrl.txt b/Documentation/devicetree/bindings/clock/ti-keystone-pllctrl.txt new file mode 100644 index 0000000..3e6a81e --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti-keystone-pllctrl.txt @@ -0,0 +1,20 @@ +* Device tree bindings for Texas Instruments keystone pll controller + +The main pll controller used to drive theC66x CorePacs, the switch fabric, +and a majority of the peripheral clocks (all but the ARM CorePacs, DDR3 and +the NETCP modules) requires a PLL Controller to manage the various clock +divisions, gating, and synchronization. + +Required properties: + +- compatible: "ti,keystone-pllctrl", "syscon" + +- reg: contains offset/length value for pll controller + registers space. + +Example: + +pllctrl: pll-controller@0x02310000 { + compatible = "ti,keystone-pllctrl", "syscon"; + reg = <0x02310000 0x200>; +}; -- cgit v1.1 From c8dfe94bc7a14c6a644ce55ef77b7a81505c696f Mon Sep 17 00:00:00 2001 From: Florian Fainelli Date: Fri, 23 May 2014 17:40:54 -0700 Subject: Documentation: brcmstb-l2: Add Broadcom STB Level-2 interrupt controller binding This patch adds the Device Tree binding document for the Broadcom Set-top-box Level 2 interrupt controller hardware. Signed-off-by: Brian Norris Link: https://lkml.kernel.org/r/1400892054-24457-3-git-send-email-f.fainelli@gmail.com Signed-off-by: Florian Fainelli Signed-off-by: Jason Cooper --- .../bindings/interrupt-controller/brcm,l2-intc.txt | 29 ++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt new file mode 100644 index 0000000..448273a --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt @@ -0,0 +1,29 @@ +Broadcom Generic Level 2 Interrupt Controller + +Required properties: + +- compatible: should be "brcm,l2-intc" +- reg: specifies the base physical address and size of the registers +- interrupt-controller: identifies the node as an interrupt controller +- #interrupt-cells: specifies the number of cells needed to encode an + interrupt source. Should be 1. +- interrupt-parent: specifies the phandle to the parent interrupt controller + this controller is cacaded from +- interrupts: specifies the interrupt line in the interrupt-parent irq space + to be used for cascading + +Optional properties: + +- brcm,irq-can-wake: If present, this means the L2 controller can be used as a + wakeup source for system suspend/resume. + +Example: + +hif_intr2_intc: interrupt-controller@f0441000 { + compatible = "brcm,l2-intc"; + reg = <0xf0441000 0x30>; + interrupt-controller; + #interrupt-cells = <1>; + interrupt-parent = <&intc>; + interrupts = <0x0 0x20 0x0>; +}; -- cgit v1.1 From 34470e0bfae223e3f22bd2bd6e0e1dac366c9290 Mon Sep 17 00:00:00 2001 From: David Fries Date: Tue, 8 Apr 2014 22:37:08 -0500 Subject: connector: allow multiple messages to be sent in one packet This increases the amount of bundling to reduce the number of packets sent. For the one wire use there can be multiple struct w1_netlink_cmd in a struct w1_netlink_msg and multiple of those in struct cn_msg, and with this change multiple of those in a struct nlmsghdr, and at each level the len identifies there being multiple of the next. Signed-off-by: David Fries Acked-by: Evgeniy Polyakov Signed-off-by: Greg Kroah-Hartman --- Documentation/connector/connector.txt | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/connector/connector.txt b/Documentation/connector/connector.txt index e5c5f5e..e56abdb 100644 --- a/Documentation/connector/connector.txt +++ b/Documentation/connector/connector.txt @@ -24,7 +24,8 @@ netlink based networking for inter-process communication in a significantly easier way: int cn_add_callback(struct cb_id *id, char *name, void (*callback) (struct cn_msg *, struct netlink_skb_parms *)); -void cn_netlink_send(struct cn_msg *msg, u32 __group, int gfp_mask); +void cn_netlink_send_multi(struct cn_msg *msg, u16 len, u32 portid, u32 __group, int gfp_mask); +void cn_netlink_send(struct cn_msg *msg, u32 portid, u32 __group, int gfp_mask); struct cb_id { @@ -71,15 +72,21 @@ void cn_del_callback(struct cb_id *id); struct cb_id *id - unique connector's user identifier. -int cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask); +int cn_netlink_send_multi(struct cn_msg *msg, u16 len, u32 portid, u32 __groups, int gfp_mask); +int cn_netlink_send(struct cn_msg *msg, u32 portid, u32 __groups, int gfp_mask); Sends message to the specified groups. It can be safely called from softirq context, but may silently fail under strong memory pressure. If there are no listeners for given group -ESRCH can be returned. struct cn_msg * - message header(with attached data). + u16 len - for *_multi multiple cn_msg messages can be sent + u32 port - destination port. + If non-zero the message will be sent to the + given port, which should be set to the + original sender. u32 __group - destination group. - If __group is zero, then appropriate group will + If port and __group is zero, then appropriate group will be searched through all registered connector users, and message will be delivered to the group which was created for user with the same ID as in msg. -- cgit v1.1 From 8a0427d192e6043834414210dd14cc1289daff18 Mon Sep 17 00:00:00 2001 From: David Fries Date: Tue, 8 Apr 2014 22:37:09 -0500 Subject: w1: optional bundling of netlink kernel replies Applications can submit a set of commands in one packet to the kernel, and in some cases it is required such as reading the temperature sensor results. This adds an option W1_CN_BUNDLE to the flags of cn_msg to request the kernel to reply in one packet for efficiency. The cn_msg flags now check for unknown flag values and return an error if one is seen. See "Proper handling of unknown flags in system calls" http://lwn.net/Articles/588444/ This corrects the ack values returned as per the protocol standard, namely the original ack for status messages and seq + 1 for all others such as the data returned from a read. Some of the common variable names have been standardized as follows. struct cn_msg *cn struct w1_netlink_msg *msg struct w1_netlink_cmd *cmd struct w1_master *dev When an argument and a function scope variable would collide, add req_ to the argument. Signed-off-by: David Fries Acked-by: Evgeniy Polyakov Signed-off-by: Greg Kroah-Hartman --- Documentation/connector/connector.txt | 2 +- Documentation/w1/w1.generic | 2 +- Documentation/w1/w1.netlink | 13 ++++++++----- 3 files changed, 10 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/connector/connector.txt b/Documentation/connector/connector.txt index e56abdb..f6215f9 100644 --- a/Documentation/connector/connector.txt +++ b/Documentation/connector/connector.txt @@ -118,7 +118,7 @@ acknowledge number MUST be the same + 1. If we receive a message and its sequence number is not equal to one we are expecting, then it is a new message. If we receive a message and its sequence number is the same as one we are expecting, but its -acknowledge is not equal to the acknowledge number in the original +acknowledge is not equal to the sequence number in the original message + 1, then it is a new message. Obviously, the protocol header contains the above id. diff --git a/Documentation/w1/w1.generic b/Documentation/w1/w1.generic index a31c5a2..b2033c6 100644 --- a/Documentation/w1/w1.generic +++ b/Documentation/w1/w1.generic @@ -82,7 +82,7 @@ driver - (standard) symlink to the w1 driver w1_master_add - Manually register a slave device w1_master_attempts - the number of times a search was attempted w1_master_max_slave_count - - the maximum slaves that may be attached to a master + - maximum number of slaves to search for at a time w1_master_name - the name of the device (w1_bus_masterX) w1_master_pullup - 5V strong pullup 0 enabled, 1 disabled w1_master_remove - Manually remove a slave device diff --git a/Documentation/w1/w1.netlink b/Documentation/w1/w1.netlink index 927a52c..ef27271 100644 --- a/Documentation/w1/w1.netlink +++ b/Documentation/w1/w1.netlink @@ -30,7 +30,7 @@ Protocol. W1_SLAVE_CMD userspace command for slave device (read/write/touch) - __u8 res - reserved + __u8 status - error indication from kernel __u16 len - size of data attached to this header data union { __u8 id[8]; - slave unique device id @@ -44,10 +44,14 @@ Protocol. __u8 cmd - command opcode. W1_CMD_READ - read command W1_CMD_WRITE - write command - W1_CMD_TOUCH - touch command - (write and sample data back to userspace) W1_CMD_SEARCH - search command W1_CMD_ALARM_SEARCH - alarm search command + W1_CMD_TOUCH - touch command + (write and sample data back to userspace) + W1_CMD_RESET - send bus reset + W1_CMD_SLAVE_ADD - add slave to kernel list + W1_CMD_SLAVE_REMOVE - remove slave from kernel list + W1_CMD_LIST_SLAVES - get slaves list from kernel __u8 res - reserved __u16 len - length of data for this command For read command data must be allocated like for write command @@ -87,8 +91,7 @@ format: id0 ... idN Each message is at most 4k in size, so if number of master devices - exceeds this, it will be split into several messages, - cn.seq will be increased for each one. + exceeds this, it will be split into several messages. W1 search and alarm search commands. request: -- cgit v1.1 From 7d28e54b8d8dee31323433f5563534fc273bcda8 Mon Sep 17 00:00:00 2001 From: Vivek Gautam Date: Mon, 5 May 2014 10:32:57 +0530 Subject: usb: ohci-exynos: Add facility to use phy provided by the generic phy framework Add support to consume phy provided by Generic phy framework. Keeping the support for older usb-phy intact right now, in order to prevent any functionality break in absence of relevant device tree side change for ohci-exynos. Once we move to new phy in the device nodes for ohci, we can remove the support for older phys. Signed-off-by: Vivek Gautam Cc: Jingoo Han Acked-by: Alan Stern Acked-by: Kukjin Kim Reviewed-by: Tomasz Figa Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/exynos-usb.txt | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt b/Documentation/devicetree/bindings/usb/exynos-usb.txt index d967ba1..49a9c6f 100644 --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt @@ -38,6 +38,13 @@ Required properties: - interrupts: interrupt number to the cpu. - clocks: from common clock binding: handle to usb clock. - clock-names: from common clock binding: Shall be "usbhost". + - port: if in the SoC there are OHCI phys, they should be listed here. + One phy per port. Each port should have following entries: + - reg: port number on OHCI controller, e.g + On Exynos5250, port 0 is USB2.0 otg phy + port 1 is HSIC phy0 + port 2 is HSIC phy1 + - phys: from the *Generic PHY* bindings, specifying phy used by port. Example: usb@12120000 { @@ -47,6 +54,15 @@ Example: clocks = <&clock 285>; clock-names = "usbhost"; + + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + phys = <&usb2phy 1>; + status = "disabled"; + }; + }; DWC3 -- cgit v1.1 From 1c17675d6c733232f10afceec0bcd016ad3849f0 Mon Sep 17 00:00:00 2001 From: Kamil Debski Date: Mon, 5 May 2014 10:32:28 +0530 Subject: usb: ehci-exynos: Change to use phy provided by the generic phy framework Add the phy provider, supplied by new Exynos-usb2phy using Generic phy framework. Keeping the support for older USB phy intact right now, in order to prevent any functionality break in absence of relevant device tree side change for ehci-exynos. Once we move to new phy in the device nodes for ehci, we can remove the support for older phys. Signed-off-by: Kamil Debski [gautam.vivek@samsung.com: Addressed review comments from mailing list] [gautam.vivek@samsung.com: Kept the code for old usb-phy, and just added support for new exynos5-usb2phy in generic phy framework] [gautam.vivek@samsung.com: Edited the commit message] Signed-off-by: Vivek Gautam Cc: Jingoo Han Acked-by: Alan Stern Acked-by: Kukjin Kim Reviewed-by: Tomasz Figa Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/exynos-usb.txt | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt b/Documentation/devicetree/bindings/usb/exynos-usb.txt index 49a9c6f..a3b5990 100644 --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt @@ -12,6 +12,13 @@ Required properties: - interrupts: interrupt number to the cpu. - clocks: from common clock binding: handle to usb clock. - clock-names: from common clock binding: Shall be "usbhost". + - port: if in the SoC there are EHCI phys, they should be listed here. + One phy per port. Each port should have following entries: + - reg: port number on EHCI controller, e.g + On Exynos5250, port 0 is USB2.0 otg phy + port 1 is HSIC phy0 + port 2 is HSIC phy1 + - phys: from the *Generic PHY* bindings; specifying phy used by port. Optional properties: - samsung,vbus-gpio: if present, specifies the GPIO that @@ -27,6 +34,14 @@ Example: clocks = <&clock 285>; clock-names = "usbhost"; + + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + phys = <&usb2phy 1>; + status = "disabled"; + }; }; OHCI -- cgit v1.1 From 03398cfbfc4c2d473e03b0fb9438b3d84f31e713 Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Thu, 15 May 2014 12:17:30 +0200 Subject: Documentation: dt-bindings: update ehci-orion binding documentation This commit updates the Device Tree binding documentation of ehci-orion to take into account the fact that we can now optionally pass a clock and a PHY reference. Signed-off-by: Thomas Petazzoni Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/ehci-orion.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/ehci-orion.txt b/Documentation/devicetree/bindings/usb/ehci-orion.txt index 6bc09ec..17c3bc8 100644 --- a/Documentation/devicetree/bindings/usb/ehci-orion.txt +++ b/Documentation/devicetree/bindings/usb/ehci-orion.txt @@ -6,6 +6,11 @@ Required properties: region. - interrupts: The EHCI interrupt +Optional properties: +- clocks: reference to the clock +- phys: reference to the USB PHY +- phy-names: name of the USB PHY, should be "usb" + Example: ehci@50000 { -- cgit v1.1 From 023bfe83e278dca17abc491f8e1182211edb0559 Mon Sep 17 00:00:00 2001 From: Gregory CLEMENT Date: Thu, 15 May 2014 12:17:34 +0200 Subject: Documentation: dt-bindings: update xhci-platform DT binding This commit extends the compatible string list of the xhci-platform binding with the new "armada-375-xhci" and "armada-380-xhci" compatible strings. It is used to describe the XHCI controller which is available in the Armada 375 and 38x SoCs. It also indicates that an optional 'clocks' property is now supported. Signed-off-by: Gregory CLEMENT Signed-off-by: Thomas Petazzoni Acked-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/usb-xhci.txt | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt index 90f8f60..999be5c 100644 --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt @@ -1,11 +1,16 @@ USB xHCI controllers Required properties: - - compatible: should be "generic-xhci" (deprecated: "xhci-platform"). + - compatible: should be one of "generic-xhci", + "marvell,armada-375-xhci", "marvell,armada-380-xhci" (deprecated: + "xhci-platform"). - reg: should contain address and length of the standard XHCI register set for the device. - interrupts: one XHCI interrupt should be described here. +Optional property: + - clocks: reference to a clock + Example: usb@f0931000 { compatible = "generic-xhci"; -- cgit v1.1 From 4615f3bd089fc4c549ed90e14982b360779feb50 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Tue, 13 May 2014 17:44:20 +0200 Subject: usb: ohci-platform: Enable optional use of reset controller The OHCI controllers used in the Allwinner A31 are asserted in reset using a global reset controller. Add optional support for such a controller in the OHCI platform driver. Signed-off-by: Maxime Ripard Reviewed-by: Hans de Goede Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/usb-ohci.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt b/Documentation/devicetree/bindings/usb/usb-ohci.txt index 45f67d9..b968a1a 100644 --- a/Documentation/devicetree/bindings/usb/usb-ohci.txt +++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt @@ -12,6 +12,7 @@ Optional properties: - clocks : a list of phandle + clock specifier pairs - phys : phandle + phy specifier pair - phy-names : "usb" +- resets : phandle + reset specifier pair Example: -- cgit v1.1 From 2d87bbd634b0fe5aa2285fd2a095867158fb2cc3 Mon Sep 17 00:00:00 2001 From: Boris BREZILLON Date: Tue, 13 May 2014 17:44:19 +0200 Subject: usb: ehci-platform: add optional reset controller retrieval On the Allwinner's A31 SoC the reset line connected to the EHCI IP has to be deasserted for the EHCI block to be usable. Add support for an optional reset controller that will be deasserted on power off and asserted on power on. Signed-off-by: Boris BREZILLON Signed-off-by: Maxime Ripard Reviewed-by: Hans de Goede Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/usb-ehci.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt b/Documentation/devicetree/bindings/usb/usb-ehci.txt index ff151ec0..43c1a4e 100644 --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt @@ -15,6 +15,7 @@ Optional properties: - clocks : a list of phandle + clock specifier pairs - phys : phandle + phy specifier pair - phy-names : "usb" + - resets : phandle + reset specifier pair Example (Sequoia 440EPx): ehci@e0000300 { -- cgit v1.1 From 657d898a9320a7cdb9b94565d75ecf75c25cbf0a Mon Sep 17 00:00:00 2001 From: Marek Szyprowski Date: Thu, 22 May 2014 13:21:38 +0200 Subject: usb: usb5303: add support for reference clock specified in device tree USB3503 chip supports 8 values of reference clock. The value is specified by REF_SEL[1:0] pins and INT_N line. This patch add support for getting 'refclk' clock, enabling it and setting INT_N line according to the value of the gathered clock. If no clock has been specified, driver defaults to the old behaviour (assuming that clock has been specified by REF_SEL pins from primary reference clock frequencies table). Signed-off-by: Marek Szyprowski Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/usb3503.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/usb3503.txt b/Documentation/devicetree/bindings/usb/usb3503.txt index a018da4..221ac0d 100644 --- a/Documentation/devicetree/bindings/usb/usb3503.txt +++ b/Documentation/devicetree/bindings/usb/usb3503.txt @@ -15,6 +15,14 @@ Optional properties: - reset-gpios: Should specify GPIO for reset. - initial-mode: Should specify initial mode. (1 for HUB mode, 2 for STANDBY mode) +- refclk: Clock used for driving REFCLK signal (optional, if not provided + the driver assumes that clock signal is always available, its + rate is specified by REF_SEL pins and a value from the primary + reference clock frequencies table is used) +- refclk-frequency: Frequency of the REFCLK signal as defined by REF_SEL + pins (optional, if not provided, driver will not set rate of the + REFCLK signal and assume that a value from the primary reference + clock frequencies table is used) Examples: usb3503@08 { -- cgit v1.1 From 7869fc6e295cbb1f80e30555bebbc795abb5b9a7 Mon Sep 17 00:00:00 2001 From: Phil Edworthy Date: Mon, 12 May 2014 11:57:50 +0100 Subject: PCI: rcar: Add R-Car PCIe device tree bindings This patch adds the bindings for the R-Car PCIe driver. The driver resides under drivers/pci/host/pcie-rcar.c Signed-off-by: Phil Edworthy Signed-off-by: Bjorn Helgaas Reviewed-by: Lucas Stach Acked-by: Simon Horman --- Documentation/devicetree/bindings/pci/rcar-pci.txt | 47 ++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/rcar-pci.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt new file mode 100644 index 0000000..29d3b98 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt @@ -0,0 +1,47 @@ +* Renesas RCar PCIe interface + +Required properties: +- compatible: should contain one of the following + "renesas,pcie-r8a7779", "renesas,pcie-r8a7790", "renesas,pcie-r8a7791" +- reg: base address and length of the pcie controller registers. +- #address-cells: set to <3> +- #size-cells: set to <2> +- bus-range: PCI bus numbers covered +- device_type: set to "pci" +- ranges: ranges for the PCI memory and I/O regions. +- dma-ranges: ranges for the inbound memory regions. +- interrupts: two interrupt sources for MSI interrupts, followed by interrupt + source for hardware related interrupts (e.g. link speed change). +- #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. +- clocks: from common clock binding: clock specifiers for the PCIe controller + and PCIe bus clocks. +- clock-names: from common clock binding: should be "pcie" and "pcie_bus". + +Example: + +SoC specific DT Entry: + + pcie: pcie@fe000000 { + compatible = "renesas,pcie-r8a7791"; + reg = <0 0xfe000000 0 0x80000>; + #address-cells = <3>; + #size-cells = <2>; + bus-range = <0x00 0xff>; + device_type = "pci"; + ranges = <0x01000000 0 0x00000000 0 0xfe100000 0 0x00100000 + 0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000 + 0x02000000 0 0x30000000 0 0x30000000 0 0x08000000 + 0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>; + dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x40000000 + 0x42000000 2 0x00000000 2 0x00000000 0 0x40000000>; + interrupts = <0 116 4>, <0 117 4>, <0 118 4>; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic 0 116 4>; + clocks = <&mstp3_clks R8A7791_CLK_PCIE>, <&pcie_bus_clk>; + clock-names = "pcie", "pcie_bus"; + status = "disabled"; + }; -- cgit v1.1 From 26c88f930141f0d9e7673af2332ada67b7e8865a Mon Sep 17 00:00:00 2001 From: Sam bobroff Date: Wed, 21 May 2014 16:32:39 +1000 Subject: powerpc: Document sysfs DSCR interface Add some documentation about ... /sys/devices/system/cpu/dscr_default /sys/devices/system/cpu/cpuN/dscr ... to Documentation/ABI/stable. Signed-off-by: Sam Bobroff Signed-off-by: Benjamin Herrenschmidt --- Documentation/ABI/stable/sysfs-devices-system-cpu | 25 +++++++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 Documentation/ABI/stable/sysfs-devices-system-cpu (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-devices-system-cpu b/Documentation/ABI/stable/sysfs-devices-system-cpu new file mode 100644 index 0000000..33c133e --- /dev/null +++ b/Documentation/ABI/stable/sysfs-devices-system-cpu @@ -0,0 +1,25 @@ +What: /sys/devices/system/cpu/dscr_default +Date: 13-May-2014 +KernelVersion: v3.15.0 +Contact: +Description: Writes are equivalent to writing to + /sys/devices/system/cpu/cpuN/dscr on all CPUs. + Reads return the last written value or 0. + This value is not a global default: it is a way to set + all per-CPU defaults at the same time. +Values: 64 bit unsigned integer (bit field) + +What: /sys/devices/system/cpu/cpu[0-9]+/dscr +Date: 13-May-2014 +KernelVersion: v3.15.0 +Contact: +Description: Default value for the Data Stream Control Register (DSCR) on + a CPU. + This default value is used when the kernel is executing and + for any process that has not set the DSCR itself. + If a process ever sets the DSCR (via direct access to the + SPR) that value will be persisted for that process and used + on any CPU where it executes (overriding the value described + here). + If set by a process it will be inherited by child processes. +Values: 64 bit unsigned integer (bit field) -- cgit v1.1 From e7cd1d1eb16fcdf53001b926187a82f1f3e1a7e6 Mon Sep 17 00:00:00 2001 From: Tony Lindgren Date: Tue, 20 May 2014 11:17:54 -0700 Subject: mfd: twl4030-power: Add generic reset configuration The twl4030 PMIC needs to be configured properly for things like warm reset and deeper idle states so the PMIC manages the regulators properly based on the hardware triggers from the SoC. Earlier we have configured twl4030 using platform data, but we want to do it for device tree based booting also. In some cases configuring twl4030 is needed for things to work. For example, when rebooting an OMAP3530 at 125 MHz, it hangs. With this patch, TWL4030 will be reset when a warm reset occures, and OMAP3530 does not hang on reboot. Let's add device tree support and configure things for warm reset as the default when compatible = "ti,twl4030-power". More complicated configurations can be added to the driver based on other compatible flags. Note we now also make the pdata const like it should be. This allows use it for match->data with the device tree related functions. Based on earlier patch by Matthias Brugger and Lesly A M . Signed-off-by: Tony Lindgren Signed-off-by: Lee Jones --- Documentation/devicetree/bindings/mfd/twl4030-power.txt | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt b/Documentation/devicetree/bindings/mfd/twl4030-power.txt index 8e15ec3..b906116 100644 --- a/Documentation/devicetree/bindings/mfd/twl4030-power.txt +++ b/Documentation/devicetree/bindings/mfd/twl4030-power.txt @@ -5,7 +5,12 @@ 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" +- compatible : must be one of the following + "ti,twl4030-power" + "ti,twl4030-power-reset" + +The use of ti,twl4030-power-reset is recommended at least on +3530 that needs a special configuration for warm reset to work. Optional properties: - ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF or -- cgit v1.1 From 76714d2c090f836fe005008116075a7b5bfde852 Mon Sep 17 00:00:00 2001 From: Tony Lindgren Date: Tue, 20 May 2014 11:17:54 -0700 Subject: mfd: twl4030-power: Add recommended idle configuration These settings are based on the "Recommended Sleep Sequences for the Zoom Platform". The settings assume most of the regulators are under control of Linux, and twl4030 only cuts off VDD1 and VDD2 during off-idle as Linux cannot do it. For any board specific changes to these, let's patch them in as changes to the generic data in the follow-up patches. This keeps the board specific changes small. Note that this does not consider the twl5030 errata 27 and 28. That can be added later on after it has been tested. For more information about errata 27 and 28. Signed-off-by: Tony Lindgren Signed-off-by: Lee Jones --- Documentation/devicetree/bindings/mfd/twl4030-power.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt b/Documentation/devicetree/bindings/mfd/twl4030-power.txt index b906116..bbd6603 100644 --- a/Documentation/devicetree/bindings/mfd/twl4030-power.txt +++ b/Documentation/devicetree/bindings/mfd/twl4030-power.txt @@ -8,10 +8,14 @@ Required properties: - compatible : must be one of the following "ti,twl4030-power" "ti,twl4030-power-reset" + "ti,twl4030-power-idle" The use of ti,twl4030-power-reset is recommended at least on 3530 that needs a special configuration for warm reset to work. +When using ti,twl4030-power-idle, the TI recommended configuration +for idle modes is loaded to the tlw4030 PMIC. + 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. -- cgit v1.1 From 43fef47f94a1ae46fb2720dada32fa3b5547bee2 Mon Sep 17 00:00:00 2001 From: Tony Lindgren Date: Tue, 13 May 2014 18:34:09 -0700 Subject: mfd: twl4030-power: Add a configuration to turn off oscillator during off-idle Some oscillators can be turned off during off-idle saving few a little bit power at the cost of the oscillator start up latency. If you board can do this, you can now enable it by using the ti,twl4030-power-idle-osc-off compatible flag. Signed-off-by: Tony Lindgren Signed-off-by: Lee Jones --- Documentation/devicetree/bindings/mfd/twl4030-power.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt b/Documentation/devicetree/bindings/mfd/twl4030-power.txt index bbd6603..b9ee7b9 100644 --- a/Documentation/devicetree/bindings/mfd/twl4030-power.txt +++ b/Documentation/devicetree/bindings/mfd/twl4030-power.txt @@ -9,6 +9,7 @@ Required properties: "ti,twl4030-power" "ti,twl4030-power-reset" "ti,twl4030-power-idle" + "ti,twl4030-power-idle-osc-off" The use of ti,twl4030-power-reset is recommended at least on 3530 that needs a special configuration for warm reset to work. @@ -16,6 +17,11 @@ The use of ti,twl4030-power-reset is recommended at least on When using ti,twl4030-power-idle, the TI recommended configuration for idle modes is loaded to the tlw4030 PMIC. +When using ti,twl4030-power-idle-osc-off, the TI recommended +configuration is used with the external oscillator being shut +down during off-idle. Note that this does not work on all boards +depending on how the external oscillator is wired. + 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. -- cgit v1.1 From 7913ad1ad83409e7f9ed5758bb4324bf64c95a73 Mon Sep 17 00:00:00 2001 From: Finn Thain Date: Sat, 12 Apr 2014 23:48:56 +1000 Subject: m68k: Multi-platform EARLY_PRINTK Make the boot console available to more m68k platforms by leveraging the head.S debug console. The boot console is enabled by the "earlyprintk" command line argument which is how most other architectures do this. This is a change of behaviour for the Mac but does not negatively impact the common use-case which is not debugging. This is also a change of behaviour for other platforms because it means the serial port stays quiet when CONFIG_EARLY_PRINTK is not enabled. This is also an improvement for the common use-case. Signed-off-by: Finn Thain Tested-by: Stephen N Chivers [Geert: CONSOLE_DEBUG should depend on CONFIG_FONT_SUPPORT] Reported-by: kbuild test robot Signed-off-by: Geert Uytterhoeven --- Documentation/kernel-parameters.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 30a8ad0d..7da289e 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -892,7 +892,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. (mmio) or 32-bit (mmio32). The options are the same as for ttyS, above. - earlyprintk= [X86,SH,BLACKFIN,ARM] + earlyprintk= [X86,SH,BLACKFIN,ARM,M68k] earlyprintk=vga earlyprintk=efi earlyprintk=xen -- cgit v1.1 From ca6c55189a631f3380ff0a28f90d920a84e60d7b Mon Sep 17 00:00:00 2001 From: "Ivan T. Ivanov" Date: Tue, 27 May 2014 09:27:36 +0300 Subject: pinctrl: Enable "power-source" to be extracted from DT files Add "power-source" property to generic options used for DT parsing files. This enables drivers, which use generic pin configurations, to get the value passed to this property. Signed-off-by: Ivan T. Ivanov Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt index 4414163..fa40a17 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt @@ -156,6 +156,7 @@ input-disable - disable input on pin (no effect on output) input-schmitt-enable - enable schmitt-trigger mode input-schmitt-disable - disable schmitt-trigger mode input-debounce - debounce mode with debound time X +power-source - select between different power supplies 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 -- cgit v1.1 From aa76fcf473f6bfa839f37f77b6fdb71f0fb88d8f Mon Sep 17 00:00:00 2001 From: Tero Kristo Date: Fri, 21 Feb 2014 17:36:21 +0200 Subject: CLK: TI: DPLL: add support for omap2 core dpll OMAP2 has slightly different DPLL compared to later OMAP generations. This patch adds support for the ti,omap2-dpll-core-clock and also adds the bindings documentation. Signed-off-by: Tero Kristo --- Documentation/devicetree/bindings/clock/ti/dpll.txt | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt b/Documentation/devicetree/bindings/clock/ti/dpll.txt index 30bfdb7..50a1a42 100644 --- a/Documentation/devicetree/bindings/clock/ti/dpll.txt +++ b/Documentation/devicetree/bindings/clock/ti/dpll.txt @@ -30,6 +30,7 @@ Required properties: "ti,am3-dpll-clock", "ti,am3-dpll-core-clock", "ti,am3-dpll-x2-clock", + "ti,omap2-dpll-core-clock", - #clock-cells : from common clock binding; shall be set to 0. - clocks : link phandles of parent clocks, first entry lists reference clock @@ -41,6 +42,7 @@ Required properties: "mult-div1" - contains the multiplier / divider register base address "autoidle" - contains the autoidle register base address (optional) ti,am3-* dpll types do not have autoidle register + ti,omap2-* dpll type does not support idlest / autoidle registers Optional properties: - DPLL mode setting - defining any one or more of the following overrides @@ -73,3 +75,10 @@ Examples: clocks = <&sys_clkin_ck>, <&sys_clkin_ck>; reg = <0x90>, <0x5c>, <0x68>; }; + + dpll_ck: dpll_ck { + #clock-cells = <0>; + compatible = "ti,omap2-dpll-core-clock"; + clocks = <&sys_ck>, <&sys_ck>; + reg = <0x0500>, <0x0540>; + }; -- cgit v1.1 From 4d008589e271e28eae728eef7f5fb1f658f12b9f Mon Sep 17 00:00:00 2001 From: Tero Kristo Date: Mon, 24 Feb 2014 16:06:34 +0200 Subject: CLK: TI: APLL: add support for omap2 aplls This patch adds support for omap2 type aplls, which have gating and autoidle functionality. Signed-off-by: Tero Kristo --- .../devicetree/bindings/clock/ti/apll.txt | 24 +++++++++++++++++----- 1 file changed, 19 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/ti/apll.txt b/Documentation/devicetree/bindings/clock/ti/apll.txt index 7faf5a6..ade4dd4 100644 --- a/Documentation/devicetree/bindings/clock/ti/apll.txt +++ b/Documentation/devicetree/bindings/clock/ti/apll.txt @@ -14,18 +14,32 @@ a subtype of a DPLL [2], although a simplified one at that. [2] Documentation/devicetree/bindings/clock/ti/dpll.txt Required properties: -- compatible : shall be "ti,dra7-apll-clock" +- compatible : shall be "ti,dra7-apll-clock" or "ti,omap2-apll-clock" - #clock-cells : from common clock binding; shall be set to 0. - clocks : link phandles of parent clocks (clk-ref and clk-bypass) - reg : address and length of the register set for controlling the APLL. It contains the information of registers in the following order: - "control" - contains the control register base address - "idlest" - contains the idlest register base address + "control" - contains the control register offset + "idlest" - contains the idlest register offset + "autoidle" - contains the autoidle register offset (OMAP2 only) +- ti,clock-frequency : static clock frequency for the clock (OMAP2 only) +- ti,idlest-shift : bit-shift for the idlest field (OMAP2 only) +- ti,bit-shift : bit-shift for enable and autoidle fields (OMAP2 only) Examples: - apll_pcie_ck: apll_pcie_ck@4a008200 { + apll_pcie_ck: apll_pcie_ck { #clock-cells = <0>; clocks = <&apll_pcie_in_clk_mux>, <&dpll_pcie_ref_ck>; - reg = <0x4a00821c 0x4>, <0x4a008220 0x4>; + reg = <0x021c>, <0x0220>; compatible = "ti,dra7-apll-clock"; }; + + apll96_ck: apll96_ck { + #clock-cells = <0>; + compatible = "ti,omap2-apll-clock"; + clocks = <&sys_ck>; + ti,bit-shift = <2>; + ti,idlest-shift = <8>; + ti,clock-frequency = <96000000>; + reg = <0x0500>, <0x0530>, <0x0520>; + }; -- cgit v1.1 From 9fa160cb9f2f51ef8274df7b4f390edf6ae491c3 Mon Sep 17 00:00:00 2001 From: Tero Kristo Date: Thu, 27 Feb 2014 17:21:33 +0200 Subject: CLK: TI: gate: fixed DT binding documentation bugs ti,composite-gate-clock documentation was missing, also the register offset examples were wrong. Signed-off-by: Tero Kristo --- .../devicetree/bindings/clock/ti/gate.txt | 29 +++++++++++++++++++--- 1 file changed, 25 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/ti/gate.txt b/Documentation/devicetree/bindings/clock/ti/gate.txt index 125281a..03f8fde 100644 --- a/Documentation/devicetree/bindings/clock/ti/gate.txt +++ b/Documentation/devicetree/bindings/clock/ti/gate.txt @@ -25,6 +25,11 @@ Required properties: to map clockdomains properly "ti,hsdiv-gate-clock" - gate clock with OMAP36xx specific hardware handling, required for a hardware errata + "ti,composite-gate-clock" - composite gate clock, to be part of composite + clock + "ti,composite-no-wait-gate-clock" - composite gate clock that does not wait + for clock to be active before returning + from clk_enable() - #clock-cells : from common clock binding; shall be set to 0 - clocks : link to phandle of parent clock - reg : offset for register controlling adjustable gate, not needed for @@ -41,7 +46,7 @@ Examples: #clock-cells = <0>; compatible = "ti,gate-clock"; clocks = <&core_96m_fck>; - reg = <0x48004a00 0x4>; + reg = <0x0a00>; ti,bit-shift = <25>; }; @@ -57,7 +62,7 @@ Examples: #clock-cells = <0>; compatible = "ti,dss-gate-clock"; clocks = <&dpll4_m4x2_ck>; - reg = <0x48004e00 0x4>; + reg = <0x0e00>; ti,bit-shift = <0>; }; @@ -65,7 +70,7 @@ Examples: #clock-cells = <0>; compatible = "ti,am35xx-gate-clock"; clocks = <&ipss_ick>; - reg = <0x4800259c 0x4>; + reg = <0x059c>; ti,bit-shift = <1>; }; @@ -80,6 +85,22 @@ Examples: compatible = "ti,hsdiv-gate-clock"; clocks = <&dpll4_m2x2_mul_ck>; ti,bit-shift = <0x1b>; - reg = <0x48004d00 0x4>; + reg = <0x0d00>; ti,set-bit-to-disable; }; + + vlynq_gate_fck: vlynq_gate_fck { + #clock-cells = <0>; + compatible = "ti,composite-gate-clock"; + clocks = <&core_ck>; + ti,bit-shift = <3>; + reg = <0x0200>; + }; + + sys_clkout2_src_gate: sys_clkout2_src_gate { + #clock-cells = <0>; + compatible = "ti,composite-no-wait-gate-clock"; + clocks = <&core_ck>; + ti,bit-shift = <15>; + reg = <0x0070>; + }; -- cgit v1.1 From de742570745e12b53c70130ace958f2a60044000 Mon Sep 17 00:00:00 2001 From: Tero Kristo Date: Tue, 25 Feb 2014 19:16:07 +0200 Subject: CLK: TI: interface: add support for omap2430 specific interface clock OMAP2430 I2CHS modules require specific hardware ops to be used, so added a new compatible string for this. Signed-off-by: Tero Kristo --- Documentation/devicetree/bindings/clock/ti/interface.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/ti/interface.txt b/Documentation/devicetree/bindings/clock/ti/interface.txt index 064e8ca..3111a40 100644 --- a/Documentation/devicetree/bindings/clock/ti/interface.txt +++ b/Documentation/devicetree/bindings/clock/ti/interface.txt @@ -21,6 +21,8 @@ Required properties: "ti,omap3-dss-interface-clock" - interface clock with DSS specific HW handling "ti,omap3-ssi-interface-clock" - interface clock with SSI specific HW handling "ti,am35xx-interface-clock" - interface clock with AM35xx specific HW handling + "ti,omap2430-interface-clock" - interface clock with OMAP2430 specific HW + handling - #clock-cells : from common clock binding; shall be set to 0 - clocks : link to phandle of parent clock - reg : base address for the control register -- cgit v1.1 From 2d5e447914722f3c79103ad54baa1170661ac553 Mon Sep 17 00:00:00 2001 From: Peter Ujfalusi Date: Wed, 7 May 2014 13:20:46 +0300 Subject: dt:/bindings: DRA7 ATL (Audio Tracking Logic) clock bindings Audio Tracking Logic is designed to be used by HD Radio applications to synchronize the audio output clocks to the baseband clock. ATL can be also used to track errors between two reference clocks (BWS, AWS) and generate a modulated clock output which averages to some desired frequency. In essence ATL is generating a clock to be used by an audio codec and also to be used by the SoC as MCLK. To be able to integrate the ATL provided clocks to the clock tree we need two types of DT binding: - DT clock nodes to represent the ATL clocks towards the CCF - binding for the ATL IP itself which is going to handle the hw configuration The reason for this type of setup is that ATL itself is a separate device in the SoC, it has it's own address space and clock domain. Other IPs can use the ATL generated clock as their functional clock (McASPs for example) and external components like audio codecs can also use the very same clock as their MCLK. The ATL IP in DRA7 contains 4 ATL instences. Signed-off-by: Peter Ujfalusi Signed-off-by: Tero Kristo --- .../devicetree/bindings/clock/ti/dra7-atl.txt | 96 ++++++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/ti/dra7-atl.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/ti/dra7-atl.txt b/Documentation/devicetree/bindings/clock/ti/dra7-atl.txt new file mode 100644 index 0000000..585e8c1 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/dra7-atl.txt @@ -0,0 +1,96 @@ +Device Tree Clock bindings for ATL (Audio Tracking Logic) of DRA7 SoC. + +The ATL IP is used to generate clock to be used to synchronize baseband and +audio codec. A single ATL IP provides four ATL clock instances sharing the same +functional clock but can be configured to provide different clocks. +ATL can maintain a clock averages to some desired frequency based on the bws/aws +signals - can compensate the drift between the two ws signal. + +In order to provide the support for ATL and it's output clocks (which can be used +internally within the SoC or external components) two sets of bindings is needed: + +Clock tree binding: +This binding uses the common clock binding[1]. +To be able to integrate the ATL clocks with DT clock tree. +Provides ccf level representation of the ATL clocks to be used by drivers. +Since the clock instances are part of a single IP this binding is used as a node +for the DT clock tree, the IP driver is needed to handle the actual configuration +of the IP. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- compatible : shall be "ti,dra7-atl-clock" +- #clock-cells : from common clock binding; shall be set to 0. +- clocks : link phandles to functional clock of ATL + +Binding for the IP driver: +This binding is used to configure the IP driver which is going to handle the +configuration of the IP for the ATL clock instances. + +Required properties: +- compatible : shall be "ti,dra7-atl" +- reg : base address for the ATL IP +- ti,provided-clocks : List of phandles to the clocks associated with the ATL +- clocks : link phandles to functional clock of ATL +- clock-names : Shall be set to "fck" +- ti,hwmods : Shall be set to "atl" + +Optional properties: +Configuration of ATL instances: +- atl{0/1/2/3} { + - bws : Baseband word select signal selection + - aws : Audio word select signal selection +}; + +For valid word select signals, see the dt-bindings/clk/ti-dra7-atl.h include +file. + +Examples: +/* clock bindings for atl provided clocks */ +atl_clkin0_ck: atl_clkin0_ck { + #clock-cells = <0>; + compatible = "ti,dra7-atl-clock"; + clocks = <&atl_gfclk_mux>; +}; + +atl_clkin1_ck: atl_clkin1_ck { + #clock-cells = <0>; + compatible = "ti,dra7-atl-clock"; + clocks = <&atl_gfclk_mux>; +}; + +atl_clkin2_ck: atl_clkin2_ck { + #clock-cells = <0>; + compatible = "ti,dra7-atl-clock"; + clocks = <&atl_gfclk_mux>; +}; + +atl_clkin3_ck: atl_clkin3_ck { + #clock-cells = <0>; + compatible = "ti,dra7-atl-clock"; + clocks = <&atl_gfclk_mux>; +}; + +/* binding for the IP */ +atl: atl@4843c000 { + compatible = "ti,dra7-atl"; + reg = <0x4843c000 0x3ff>; + ti,hwmods = "atl"; + ti,provided-clocks = <&atl_clkin0_ck>, <&atl_clkin1_ck>, + <&atl_clkin2_ck>, <&atl_clkin3_ck>; + clocks = <&atl_gfclk_mux>; + clock-names = "fck"; + status = "disabled"; +}; + +#include + +&atl { + status = "okay"; + + atl2 { + bws = ; + aws = ; + }; +}; -- cgit v1.1 From d47b62f4b1c0374517ccbdf3ee4a7cceead58905 Mon Sep 17 00:00:00 2001 From: Ben Dooks Date: Tue, 20 May 2014 01:10:20 +0400 Subject: PCI: rcar: Add gen2 device tree support Add device tree probing support to the 'pci-rcar-gen2' driver. [Sergei: numerous fixes/cleanups/additions] [bhelgaas: whitespace fix] Signed-off-by: Ben Dooks Signed-off-by: Sergei Shtylyov Signed-off-by: Bjorn Helgaas Acked-by: Simon Horman Acked-by: Arnd Bergmann --- .../devicetree/bindings/pci/pci-rcar-gen2.txt | 66 ++++++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt new file mode 100644 index 0000000..d8ef5bf --- /dev/null +++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt @@ -0,0 +1,66 @@ +Renesas AHB to PCI bridge +------------------------- + +This is the bridge used internally to connect the USB controllers to the +AHB. There is one bridge instance per USB port connected to the internal +OHCI and EHCI controllers. + +Required properties: +- compatible: "renesas,pci-r8a7790" for the R8A7790 SoC; + "renesas,pci-r8a7791" for the R8A7791 SoC. +- reg: A list of physical regions to access the device: the first is + the operational registers for the OHCI/EHCI controllers and the + second is for the bridge configuration and control registers. +- interrupts: interrupt for the device. +- clocks: The reference to the device clock. +- bus-range: The PCI bus number range; as this is a single bus, the range + should be specified as the same value twice. +- #address-cells: must be 3. +- #size-cells: must be 2. +- #interrupt-cells: must be 1. +- interrupt-map: standard property used to define the mapping of the PCI + interrupts to the GIC interrupts. +- interrupt-map-mask: standard property that helps to define the interrupt + mapping. + +Example SoC configuration: + + pci0: pci@ee090000 { + compatible = "renesas,pci-r8a7790"; + clocks = <&mstp7_clks R8A7790_CLK_EHCI>; + reg = <0x0 0xee090000 0x0 0xc00>, + <0x0 0xee080000 0x0 0x1100>; + interrupts = <0 108 IRQ_TYPE_LEVEL_HIGH>; + status = "disabled"; + + bus-range = <0 0>; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + interrupt-map-mask = <0xff00 0 0 0x7>; + interrupt-map = <0x0000 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH + 0x0800 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH + 0x1000 0 0 2 &gic 0 108 IRQ_TYPE_LEVEL_HIGH>; + + pci@0,1 { + reg = <0x800 0 0 0 0>; + device_type = "pci"; + phys = <&usbphy 0 0>; + phy-names = "usb"; + }; + + pci@0,2 { + reg = <0x1000 0 0 0 0>; + device_type = "pci"; + phys = <&usbphy 0 0>; + phy-names = "usb"; + }; + }; + +Example board setup: + +&pci0 { + status = "okay"; + pinctrl-0 = <&usb0_pins>; + pinctrl-names = "default"; +}; -- cgit v1.1 From 9d4bde5fab13615a619ae74deb1a159c68506780 Mon Sep 17 00:00:00 2001 From: Matt Porter Date: Thu, 24 Apr 2014 13:12:56 -0400 Subject: dt: bindings: dwc2: fix required value for the phy-names property "7408484 usb: gadget: s3c-hsotg: enable generic phy support" introduces generic phy support to the dwc2.txt binding and the s3c-hsotg driver which implements support for the binding. The binding documentation incorrectly states that the phy-names property will be "device". The binding example, driver, and one dts user all implement the phy-names property as requiring "usb2-phy". Fix the dwc2.txt binding documentation to correctly specify "usb2-phy" as the appropriate value for phy-names. Reported-by: Tomasz Figa Signed-off-by: Matt Porter Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/usb/dwc2.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt index b8b6871..467ddd1 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.txt +++ b/Documentation/devicetree/bindings/usb/dwc2.txt @@ -13,7 +13,7 @@ Refer to clk/clock-bindings.txt for generic clock consumer properties Optional properties: - phys: phy provider specifier -- phy-names: shall be "device" +- phy-names: shall be "usb2-phy" Refer to phy/phy-bindings.txt for generic phy consumer properties Example: -- cgit v1.1 From e723e4429983333c6fbd3848de50333834d5e89c Mon Sep 17 00:00:00 2001 From: Stephen Boyd Date: Thu, 22 May 2014 14:00:09 -0700 Subject: devicetree: bindings: Document micrel vendor prefix There's one existing use of 'micrel' in the documentation so use 'micrel' instead of the company's ticker symbol 'mcrl'. Cc: Signed-off-by: Stephen Boyd Signed-off-by: Rob Herring --- 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 abc3080..cdb0793 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -75,6 +75,7 @@ linux Linux-specific binding lsi LSI Corp. (LSI Logic) marvell Marvell Technology Group Ltd. maxim Maxim Integrated Products +micrel Micrel Inc. microchip Microchip Technology Inc. mosaixtech Mosaix Technologies, Inc. moxa Moxa -- cgit v1.1 From 81bd1eb7af751666ace2f1dadb0b0101401807cd Mon Sep 17 00:00:00 2001 From: Simon Horman Date: Thu, 15 May 2014 20:00:58 +0900 Subject: serial: sh-sci: Add device tree support for r8a7779 Simply document a new compat string. There appears to be no need for a driver updates. Acked-by: Laurent Pinchart Signed-off-by: Simon Horman Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index 53e6c17..64fd7de 100644 --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt @@ -4,6 +4,7 @@ Required properties: - compatible: Must contain one of the following: + - "renesas,scif-r8a7779" for R8A7779 (R-Car H1) SCIF compatible UART. - "renesas,scif-r8a7790" for R8A7790 (R-Car H2) SCIF compatible UART. - "renesas,scifa-r8a7790" for R8A7790 (R-Car H2) SCIFA compatible UART. - "renesas,scifb-r8a7790" for R8A7790 (R-Car H2) SCIFB compatible UART. -- cgit v1.1 From 7f40605a2661d17275a1aa245498f4a12ad9ca9a Mon Sep 17 00:00:00 2001 From: Richard Genoud Date: Tue, 13 May 2014 20:20:41 +0200 Subject: tty/serial: atmel_serial: Fix device tree documentation RTS pin is an active low pin. For now, this doesn't change anything as the ACTIVE_LOW flag is not handled in atmel_serial, but it will be in 3.16. Signed-off-by: Richard Genoud Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/atmel-usart.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/atmel-usart.txt b/Documentation/devicetree/bindings/serial/atmel-usart.txt index 17c1042..2f7aad7 100644 --- a/Documentation/devicetree/bindings/serial/atmel-usart.txt +++ b/Documentation/devicetree/bindings/serial/atmel-usart.txt @@ -35,7 +35,7 @@ Example: clock-names = "usart"; atmel,use-dma-rx; atmel,use-dma-tx; - rts-gpios = <&pioD 15 0>; + rts-gpios = <&pioD 15 GPIO_ACTIVE_LOW>; }; - use DMA: -- cgit v1.1 From 84130aace83989c1dba073ed98dad721d2060258 Mon Sep 17 00:00:00 2001 From: Richard Genoud Date: Tue, 13 May 2014 20:20:43 +0200 Subject: tty/serial: Add GPIOLIB helpers for controlling modem lines This patch add some helpers to control modem lines (CTS/RTS/DSR...) via GPIO. This will be useful for many boards which have a serial controller that only handle CTS/RTS pins (or even just RX/TX). Signed-off-by: Richard Genoud Acked-by: Greg Kroah-Hartman Tested-by: Yegor Yefremov Signed-off-by: Greg Kroah-Hartman --- Documentation/serial/driver | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) (limited to 'Documentation') diff --git a/Documentation/serial/driver b/Documentation/serial/driver index c3a7689..3bba1ae 100644 --- a/Documentation/serial/driver +++ b/Documentation/serial/driver @@ -429,3 +429,28 @@ thus: struct uart_port port; int my_stuff; }; + +Modem control lines via GPIO +---------------------------- + +Some helpers are provided in order to set/get modem control lines via GPIO. + +mctrl_gpio_init(dev, idx): + This will get the {cts,rts,...}-gpios from device tree if they are + present and request them, set direction etc, and return an + allocated structure. devm_* functions are used, so there's no need + to call mctrl_gpio_free(). + +mctrl_gpio_free(dev, gpios): + This will free the requested gpios in mctrl_gpio_init(). + As devm_* function are used, there's generally no need to call + this function. + +mctrl_gpio_to_gpiod(gpios, gidx) + This returns the gpio structure associated to the modem line index. + +mctrl_gpio_set(gpios, mctrl): + This will sets the gpios according to the mctrl state. + +mctrl_gpio_get(gpios, mctrl): + This will update mctrl with the gpios values. -- cgit v1.1 From e0b0baadb7a4509bdcd5ba37d0be61e2c4bb0d48 Mon Sep 17 00:00:00 2001 From: Richard Genoud Date: Tue, 13 May 2014 20:20:44 +0200 Subject: tty/serial: at91: use mctrl_gpio helpers On sam9x5, dedicated CTS (and RTS) pins are unusable together with the LCDC, the EMAC, or the MMC because they share the same line. Moreover, the USART controller doesn't handle DTR/DSR/DCD/RI signals, so we have to control them via GPIO. This patch permits to use GPIOs to control the CTS/RTS/DTR/DSR/DCD/RI signals. Signed-off-by: Richard Genoud Acked-by: Greg Kroah-Hartman Acked-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/atmel-usart.txt | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/atmel-usart.txt b/Documentation/devicetree/bindings/serial/atmel-usart.txt index 2f7aad7..a6391e7 100644 --- a/Documentation/devicetree/bindings/serial/atmel-usart.txt +++ b/Documentation/devicetree/bindings/serial/atmel-usart.txt @@ -13,8 +13,9 @@ Required properties: Optional properties: - atmel,use-dma-rx: use of PDC or DMA for receiving data - atmel,use-dma-tx: use of PDC or DMA for transmitting data -- rts-gpios: specify a GPIO for RTS line. It will use specified PIO instead of the peripheral - function pin for the USART RTS feature. If unsure, don't specify this property. +- {rts,cts,dtr,dsr,rng,dcd}-gpios: specify a GPIO for RTS/CTS/DTR/DSR/RI/DCD line respectively. + It will use specified PIO instead of the peripheral function pin for the USART feature. + If unsure, don't specify this property. - add dma bindings for dma transfer: - dmas: DMA specifier, consisting of a phandle to DMA controller node, memory peripheral interface and USART DMA channel ID, FIFO configuration. @@ -36,6 +37,11 @@ Example: atmel,use-dma-rx; atmel,use-dma-tx; rts-gpios = <&pioD 15 GPIO_ACTIVE_LOW>; + cts-gpios = <&pioD 16 GPIO_ACTIVE_LOW>; + dtr-gpios = <&pioD 17 GPIO_ACTIVE_LOW>; + dsr-gpios = <&pioD 18 GPIO_ACTIVE_LOW>; + dcd-gpios = <&pioD 20 GPIO_ACTIVE_LOW>; + rng-gpios = <&pioD 19 GPIO_ACTIVE_LOW>; }; - use DMA: -- cgit v1.1 From 06aa82e498c144c7784a6f3d3b55458b272d6146 Mon Sep 17 00:00:00 2001 From: Murali Karicheri Date: Thu, 1 May 2014 15:04:53 -0400 Subject: serial: uart: add hw flow control support configuration 8250 uart driver currently supports only software assisted hw flow control. The software assisted hw flow control maintains a hw_stopped flag in the tty structure to stop and start transmission and use modem status interrupt for the event to drive the handshake signals. This is not needed if hw has flow control capabilities. This patch adds a DT attribute for enabling hw flow control for a uart port. Also skip stop and start if this flag is present in flag field of the port structure. Signed-off-by: Murali Karicheri CC: Rob Herring CC: Pawel Moll CC: Mark Rutland CC: Ian Campbell CC: Kumar Gala CC: Randy Dunlap CC: Jiri Slaby CC: Santosh Shilimkar Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/of-serial.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt b/Documentation/devicetree/bindings/serial/of-serial.txt index 1928a3e..7705477 100644 --- a/Documentation/devicetree/bindings/serial/of-serial.txt +++ b/Documentation/devicetree/bindings/serial/of-serial.txt @@ -37,6 +37,7 @@ Optional properties: - auto-flow-control: one way to enable automatic flow control support. The driver is allowed to detect support for the capability even without this property. +- has-hw-flow-control: the hardware has flow control capability. Example: -- cgit v1.1 From c7c1ce8061c0dc5b848e5df0ba459dbbf78057d7 Mon Sep 17 00:00:00 2001 From: Yoshihiro Shimoda Date: Wed, 28 May 2014 20:23:26 +0900 Subject: Documentation: dt-bindings: update xhci-platform DT binding for R-Car H2 and M2 This commit extends the compatible string list of the xhci-platform binding with the new "renesas,xhci-r8a7790" and "renesas,xhci-r8a7791" compatible strings. It is used to describe the xHCI controller which is available in the R-Car H2 and M2 SoCs. Acked-by: Geert Uytterhoeven Signed-off-by: Yoshihiro Shimoda Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/usb-xhci.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt index 999be5c..5a79377 100644 --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt @@ -2,7 +2,8 @@ USB xHCI controllers Required properties: - compatible: should be one of "generic-xhci", - "marvell,armada-375-xhci", "marvell,armada-380-xhci" (deprecated: + "marvell,armada-375-xhci", "marvell,armada-380-xhci", + "renesas,xhci-r8a7790", "renesas,xhci-r8a7791" (deprecated: "xhci-platform"). - reg: should contain address and length of the standard XHCI register set for the device. -- cgit v1.1 From 4a2883ec794dee96c1702ca847a48bfe5c3ab1f0 Mon Sep 17 00:00:00 2001 From: Josh Cartwright Date: Thu, 1 May 2014 16:40:26 -0500 Subject: spmi: of: fixup generic SPMI devicetree binding example The generic SPMI example was missing an equal sign in the assignment of the #size-cells property. Signed-off-by: Josh Cartwright Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/spmi/spmi.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spmi/spmi.txt b/Documentation/devicetree/bindings/spmi/spmi.txt index 462a42f..4bb10d1 100644 --- a/Documentation/devicetree/bindings/spmi/spmi.txt +++ b/Documentation/devicetree/bindings/spmi/spmi.txt @@ -26,7 +26,7 @@ Each child node must have one and only one 'reg' entry of type SPMI_USID. reg = <...>; #address-cells = <2>; - #size-cells <0>; + #size-cells = <0>; child@0 { compatible = "..."; -- cgit v1.1 From 782a985d7af26db39e86070d28f987cad21313c0 Mon Sep 17 00:00:00 2001 From: Alex Williamson Date: Tue, 20 May 2014 08:53:21 -0600 Subject: PCI: Introduce new device binding path using pci_dev.driver_override The driver_override field allows us to specify the driver for a device rather than relying on the driver to provide a positive match of the device. This shortcuts the existing process of looking up the vendor and device ID, adding them to the driver new_id, binding the device, then removing the ID, but it also provides a couple advantages. First, the above existing process allows the driver to bind to any device matching the new_id for the window where it's enabled. This is often not desired, such as the case of trying to bind a single device to a meta driver like pci-stub or vfio-pci. Using driver_override we can do this deterministically using: echo pci-stub > /sys/bus/pci/devices/0000:03:00.0/driver_override echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind echo 0000:03:00.0 > /sys/bus/pci/drivers_probe Previously we could not invoke drivers_probe after adding a device to new_id for a driver as we get non-deterministic behavior whether the driver we intend or the standard driver will claim the device. Now it becomes a deterministic process, only the driver matching driver_override will probe the device. To return the device to the standard driver, we simply clear the driver_override and reprobe the device: echo > /sys/bus/pci/devices/0000:03:00.0/driver_override echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind echo 0000:03:00.0 > /sys/bus/pci/drivers_probe Another advantage to this approach is that we can specify a driver override to force a specific binding or prevent any binding. For instance when an IOMMU group is exposed to userspace through VFIO we require that all devices within that group are owned by VFIO. However, devices can be hot-added into an IOMMU group, in which case we want to prevent the device from binding to any driver (override driver = "none") or perhaps have it automatically bind to vfio-pci. With driver_override it's a simple matter for this field to be set internally when the device is first discovered to prevent driver matches. Signed-off-by: Alex Williamson Signed-off-by: Bjorn Helgaas Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Alexander Graf Acked-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-bus-pci | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index a3c5a66..898ddc4 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci @@ -250,3 +250,24 @@ Description: valid. For example, writing a 2 to this file when sriov_numvfs is not 0 and not 2 already will return an error. Writing a 10 when the value of sriov_totalvfs is 8 will return an error. + +What: /sys/bus/pci/devices/.../driver_override +Date: April 2014 +Contact: Alex Williamson +Description: + This file allows the driver for a device to be specified which + will override standard static and dynamic ID matching. When + specified, only a driver with a name matching the value written + to driver_override will have an opportunity to bind to the + device. The override is specified by writing a string to the + driver_override file (echo pci-stub > driver_override) and + may be cleared with an empty string (echo > driver_override). + This returns the device to standard matching rules binding. + Writing to driver_override does not automatically unbind the + device from its current driver or make any attempt to + automatically load the specified driver. If no driver with a + matching name is currently loaded in the kernel, the device + will not bind to any driver. This also allows devices to + opt-out of driver binding using a driver_override name such as + "none". Only a single driver may be specified in the override, + there is no support for parsing delimiters. -- cgit v1.1 From 697787a16cae17f96a38e4ec82d9301457ada215 Mon Sep 17 00:00:00 2001 From: Andy Gross Date: Mon, 12 May 2014 17:16:08 -0500 Subject: pinctrl: msm: Add more MSM8X74 pin definitions This patch adds pin definitiones for the MSM8x74 TLMM. New definitions include: BLSP devices (I2C, UART, SPI, and UIM), mi2s, gp clk, pdm, gcc clk, cci_timer, cci_i2c, cam_clk, hsic, tsif, sdc3, sdc4, and other assorted pins. Signed-off-by: Andy Gross Acked-By: Bjorn Andersson Signed-off-by: Linus Walleij --- .../bindings/pinctrl/qcom,msm8974-pinctrl.txt | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt index 9fb89e3..73262b5 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt @@ -50,7 +50,27 @@ Valid values for pins are: Supports bias and drive-strength Valid values for function are: - blsp_i2c2, blsp_i2c6, blsp_i2c11, blsp_spi1, blsp_uart2, blsp_uart8, slimbus + cci_i2c0, cci_i2c1, uim1, uim2, uim_batt_alarm, + blsp_uim1, blsp_uart1, blsp_i2c1, blsp_spi1, + blsp_uim2, blsp_uart2, blsp_i2c2, blsp_spi2, + blsp_uim3, blsp_uart3, blsp_i2c3, blsp_spi3, + blsp_uim4, blsp_uart4, blsp_i2c4, blsp_spi4, + blsp_uim5, blsp_uart5, blsp_i2c5, blsp_spi5, + blsp_uim6, blsp_uart6, blsp_i2c6, blsp_spi6, + blsp_uim7, blsp_uart7, blsp_i2c7, blsp_spi7, + blsp_uim8, blsp_uart8, blsp_i2c8, blsp_spi8, + blsp_uim9, blsp_uart9, blsp_i2c9, blsp_spi9, + blsp_uim10, blsp_uart10, blsp_i2c10, blsp_spi10, + blsp_uim11, blsp_uart11, blsp_i2c11, blsp_spi11, + blsp_uim12, blsp_uart12, blsp_i2c12, blsp_spi12, + blsp_spi1_cs1, blsp_spi2_cs2, blsp_spi_cs3, blsp_spi2_cs1, blsp_spi2_cs2 + blsp_spi2_cs3, blsp_spi10_cs1, blsp_spi10_cs2, blsp_spi10_cs3, + sdc3, sdc4, gcc_gp_clk1, gcc_gp_clk2, gcc_gp_clk3, cci_timer0, cci_timer1, + cci_timer2, cci_timer3, cci_async_in0, cci_async_in1, cci_async_in2, + cam_mckl0, cam_mclk1, cam_mclk2, cam_mclk3, mdp_vsync, hdmi_cec, hdmi_ddc, + hdmi_hpd, edp_hpd, gp_pdm0, gp_pdm1, gp_pdm2, gp_pdm3, gp0_clk, gp1_clk, + gp_mn, tsif1, tsif2, hsic, grfc, audio_ref_clk, qua_mi2s, pri_mi2s, spkr_mi2s, + ter_mi2s, sec_mi2s, bt, fm, wlan, slimbus (Note that this is not yet the complete list of functions) -- cgit v1.1 From 2fe2023adf695d08af5b598b2be3b288a95d563c Mon Sep 17 00:00:00 2001 From: Stefan Richter Date: Thu, 29 May 2014 15:23:26 +0200 Subject: firewire: revert to 4 GB RDMA, fix protocols using Memory Space Undo a feature introduced in v3.14 by commit fcd46b34425d "firewire: Enable remote DMA above 4 GB". That change raised the minimum address at which protocol drivers and user programs can register for request reception from 0x0001'0000'0000 to 0x8000'0000'0000. It turned out that at least one vendor-specific protocol exists which uses lower addresses: https://bugzilla.kernel.org/show_bug.cgi?id=76921 For the time being, revert most of commit fcd46b34425d so that affected protocols work like with kernel v3.13 and before. Just keep the valid documentation parts from the regressing commit, and the ability to identify controllers which could be programmed to accept >32 bit physical DMA addresses. The rest of fcd46b34425d should probably be brought back as an optional instead of default feature. Reported-by: Fabien Spindler Cc: # 3.14+ Signed-off-by: Stefan Richter --- Documentation/debugging-via-ohci1394.txt | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/debugging-via-ohci1394.txt b/Documentation/debugging-via-ohci1394.txt index fa0151a..5c9a567 100644 --- a/Documentation/debugging-via-ohci1394.txt +++ b/Documentation/debugging-via-ohci1394.txt @@ -25,9 +25,11 @@ using data transfer rates in the order of 10MB/s or more. With most FireWire controllers, memory access is limited to the low 4 GB of physical address space. This can be a problem on IA64 machines where memory is located mostly above that limit, but it is rarely a problem on -more common hardware such as x86, x86-64 and PowerPC. However, at least -Agere/LSI FW643e and FW643e2 controllers are known to support access to -physical addresses above 4 GB. +more common hardware such as x86, x86-64 and PowerPC. + +At least LSI FW643e and FW643e2 controllers are known to support access to +physical addresses above 4 GB, but this feature is currently not enabled by +Linux. Together with a early initialization of the OHCI-1394 controller for debugging, this facility proved most useful for examining long debugs logs in the printk @@ -101,8 +103,9 @@ Step-by-step instructions for using firescope with early OHCI initialization: compliant, they are based on TI PCILynx chips and require drivers for Win- dows operating systems. - The mentioned kernel log message contains ">4 GB phys DMA" in case of - OHCI-1394 controllers which support accesses above this limit. + The mentioned kernel log message contains the string "physUB" if the + controller implements a writable Physical Upper Bound register. This is + required for physical DMA above 4 GB (but not utilized by Linux yet). 2) Establish a working FireWire cable connection: -- cgit v1.1 From c685841ee127e8023a33be68fd8af6fe192a3665 Mon Sep 17 00:00:00 2001 From: Stephen Boyd Date: Fri, 16 May 2014 16:07:13 -0700 Subject: clk: qcom: Support msm8974pro global clock control hardware A new PLL (gpll4) is added on msm8974 PRO devices to support a faster sdc1 clock rate. Add support for this and the two new sdcc cal clocks. Signed-off-by: Stephen Boyd Signed-off-by: Mike Turquette --- Documentation/devicetree/bindings/clock/qcom,gcc.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt b/Documentation/devicetree/bindings/clock/qcom,gcc.txt index 7b7104e..9cfcb4f 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt @@ -8,6 +8,8 @@ Required properties : "qcom,gcc-msm8660" "qcom,gcc-msm8960" "qcom,gcc-msm8974" + "qcom,gcc-msm8974pro" + "qcom,gcc-msm8974pro-ac" - reg : shall contain base register location and length - #clock-cells : shall contain 1 -- cgit v1.1 From f3383cf80e417e86fcc84a2eb4c96bc52842d8d9 Mon Sep 17 00:00:00 2001 From: Alexander Graf Date: Mon, 12 May 2014 01:08:32 +0200 Subject: KVM: PPC: Disable NX for old magic page using guests Old guests try to use the magic page, but map their trampoline code inside of an NX region. Since we can't fix those old kernels, try to detect whether the guest is sane or not. If not, just disable NX functionality in KVM so that old guests at least work at all. For newer guests, add a bit that we can set to keep NX functionality available. Signed-off-by: Alexander Graf --- Documentation/virtual/kvm/ppc-pv.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virtual/kvm/ppc-pv.txt b/Documentation/virtual/kvm/ppc-pv.txt index 4643cde..3195606 100644 --- a/Documentation/virtual/kvm/ppc-pv.txt +++ b/Documentation/virtual/kvm/ppc-pv.txt @@ -94,10 +94,24 @@ a bitmap of available features inside the magic page. The following enhancements to the magic page are currently available: KVM_MAGIC_FEAT_SR Maps SR registers r/w in the magic page + KVM_MAGIC_FEAT_MAS0_TO_SPRG7 Maps MASn, ESR, PIR and high SPRGs For enhanced features in the magic page, please check for the existence of the feature before using them! +Magic page flags +================ + +In addition to features that indicate whether a host is capable of a particular +feature we also have a channel for a guest to tell the guest whether it's capable +of something. This is what we call "flags". + +Flags are passed to the host in the low 12 bits of the Effective Address. + +The following flags are currently available for a guest to expose: + + MAGIC_PAGE_FLAG_NOT_MAPPED_NX Guest handles NX bits correclty wrt magic page + MSR bits ======== -- cgit v1.1 From 2f9c6943c546337ffe67b3c81d2eb38a32588c8a Mon Sep 17 00:00:00 2001 From: Paul Mackerras Date: Mon, 26 May 2014 19:48:34 +1000 Subject: KVM: PPC: Book3S: Add ONE_REG register names that were missed Commit 3b7834743f9 ("KVM: PPC: Book3S HV: Reserve POWER8 space in get/set_one_reg") added definitions for several KVM_REG_PPC_* symbols but missed adding some to api.txt. This adds them. Signed-off-by: Paul Mackerras Signed-off-by: Alexander Graf --- Documentation/virtual/kvm/api.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 0581f6c..9a95770 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -1794,6 +1794,11 @@ registers, find a list below: PPC | KVM_REG_PPC_MMCR0 | 64 PPC | KVM_REG_PPC_MMCR1 | 64 PPC | KVM_REG_PPC_MMCRA | 64 + PPC | KVM_REG_PPC_MMCR2 | 64 + PPC | KVM_REG_PPC_MMCRS | 64 + PPC | KVM_REG_PPC_SIAR | 64 + PPC | KVM_REG_PPC_SDAR | 64 + PPC | KVM_REG_PPC_SIER | 64 PPC | KVM_REG_PPC_PMC1 | 32 PPC | KVM_REG_PPC_PMC2 | 32 PPC | KVM_REG_PPC_PMC3 | 32 -- cgit v1.1 From e1d8a96daf641aea11c25268eab678a76215541a Mon Sep 17 00:00:00 2001 From: Paul Mackerras Date: Mon, 26 May 2014 19:48:35 +1000 Subject: KVM: PPC: Book3S: Move KVM_REG_PPC_WORT to an unused register number Commit b005255e12a3 ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs") added a definition of KVM_REG_PPC_WORT with the same register number as the existing KVM_REG_PPC_VRSAVE (though in fact the definitions are not identical because of the different register sizes.) For clarity, this moves KVM_REG_PPC_WORT to the next unused number, and also adds it to api.txt. Signed-off-by: Paul Mackerras Signed-off-by: Alexander Graf --- Documentation/virtual/kvm/api.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 9a95770..6b30290 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -1873,6 +1873,7 @@ registers, find a list below: PPC | KVM_REG_PPC_PPR | 64 PPC | KVM_REG_PPC_ARCH_COMPAT 32 PPC | KVM_REG_PPC_DABRX | 32 + PPC | KVM_REG_PPC_WORT | 64 PPC | KVM_REG_PPC_TM_GPR0 | 64 ... PPC | KVM_REG_PPC_TM_GPR31 | 64 -- cgit v1.1 From e7ef0b632eb45b0c725629da3561ecde8935a398 Mon Sep 17 00:00:00 2001 From: Tarek Dakhran Date: Tue, 27 May 2014 06:54:12 +0900 Subject: clk: exynos5410: register clocks using common clock framework The EXYNOS5410 clocks are statically listed and registered using the Samsung specific common clock helper functions. Signed-off-by: Tarek Dakhran Signed-off-by: Vyacheslav Tyrtov Reviewed-by: Tomasz Figa Signed-off-by: Kukjin Kim --- .../devicetree/bindings/clock/exynos5410-clock.txt | 45 ++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/exynos5410-clock.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/exynos5410-clock.txt b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt new file mode 100644 index 0000000..aeab635 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt @@ -0,0 +1,45 @@ +* Samsung Exynos5410 Clock Controller + +The Exynos5410 clock controller generates and supplies clock to various +controllers within the Exynos5410 SoC. + +Required Properties: + +- compatible: should be "samsung,exynos5410-clock" + +- reg: physical base address of the controller and length of memory mapped + region. + +- #clock-cells: should be 1. + +All available clocks are defined as preprocessor macros in +dt-bindings/clock/exynos5410.h header and can be used in device +tree sources. + +External clock: + +There is clock that is generated outside the SoC. It +is expected that it is defined using standard clock bindings +with following clock-output-name: + + - "fin_pll" - PLL input clock from XXTI + +Example 1: An example of a clock controller node is listed below. + + clock: clock-controller@0x10010000 { + compatible = "samsung,exynos5410-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@12C20000 { + compatible = "samsung,exynos4210-uart"; + reg = <0x12C00000 0x100>; + interrupts = <0 51 0>; + clocks = <&clock CLK_UART0>, <&clock CLK_SCLK_UART0>; + clock-names = "uart", "clk_uart_baud0"; + }; -- cgit v1.1 From 25023926a28666dde0fc73a9e7d51f601cd79b57 Mon Sep 17 00:00:00 2001 From: Chanwoo Choi Date: Sat, 31 May 2014 02:17:22 +0900 Subject: ARM: dts: add pmu sysreg node to exynos3250 This patch add pmusysreg node for Exynos3250 to access PMU (Power Management Unit) register in a centralized way using syscon driver. Signed-off-by: Chanwoo Choi Acked-by: Kyungmin Park Reviewed-by: Tomasz Figa Signed-off-by: Kukjin Kim --- Documentation/devicetree/bindings/arm/samsung/pmu.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt b/Documentation/devicetree/bindings/arm/samsung/pmu.txt index b562634..2a4ab04 100644 --- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt +++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt @@ -2,6 +2,7 @@ SAMSUNG Exynos SoC series PMU Registers Properties: - compatible : should contain two values. First value must be one from following list: + - "samsung,exynos3250-pmu" - for Exynos3250 SoC, - "samsung,exynos4210-pmu" - for Exynos4210 SoC, - "samsung,exynos4212-pmu" - for Exynos4212 SoC, - "samsung,exynos4412-pmu" - for Exynos4412 SoC, -- cgit v1.1 From ce292991d88b77160f348fb8a3a2cf6e78f4b456 Mon Sep 17 00:00:00 2001 From: Will Deacon Date: Fri, 22 Nov 2013 16:14:41 +0000 Subject: PCI: generic: Add generic PCI host controller driver Add support for a generic PCI host controller, such as a firmware-initialised device with static windows or an emulation by something such as kvmtool. The controller itself has no configuration registers and has its address spaces described entirely by the device-tree (using the bindings from ePAPR). Both CAM and ECAM are supported for Config Space accesses. Add corresponding documentation for the DT binding. [bhelgaas: currently uses the ARM-specific pci_common_init_dev() interface] Signed-off-by: Will Deacon Signed-off-by: Bjorn Helgaas Reviewed-by: Liviu Dudau --- .../devicetree/bindings/pci/host-generic-pci.txt | 100 +++++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/host-generic-pci.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.txt b/Documentation/devicetree/bindings/pci/host-generic-pci.txt new file mode 100644 index 0000000..f0b0436 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/host-generic-pci.txt @@ -0,0 +1,100 @@ +* Generic PCI host controller + +Firmware-initialised PCI host controllers and PCI emulations, such as the +virtio-pci implementations found in kvmtool and other para-virtualised +systems, do not require driver support for complexities such as regulator +and clock management. In fact, the controller may not even require the +configuration of a control interface by the operating system, instead +presenting a set of fixed windows describing a subset of IO, Memory and +Configuration Spaces. + +Such a controller can be described purely in terms of the standardized device +tree bindings communicated in pci.txt: + + +Properties of the host controller node: + +- compatible : Must be "pci-host-cam-generic" or "pci-host-ecam-generic" + depending on the layout of configuration space (CAM vs + ECAM respectively). + +- device_type : Must be "pci". + +- ranges : As described in IEEE Std 1275-1994, but must provide + at least a definition of non-prefetchable memory. One + or both of prefetchable Memory and IO Space may also + be provided. + +- bus-range : Optional property (also described in IEEE Std 1275-1994) + to indicate the range of bus numbers for this controller. + If absent, defaults to <0 255> (i.e. all buses). + +- #address-cells : Must be 3. + +- #size-cells : Must be 2. + +- reg : The Configuration Space base address and size, as accessed + from the parent bus. + + +Properties of the /chosen node: + +- linux,pci-probe-only + : Optional property which takes a single-cell argument. + If '0', then Linux will assign devices in its usual manner, + otherwise it will not try to assign devices and instead use + them as they are configured already. + +Configuration Space is assumed to be memory-mapped (as opposed to being +accessed via an ioport) and laid out with a direct correspondence to the +geography of a PCI bus address by concatenating the various components to +form an offset. + +For CAM, this 24-bit offset is: + + cfg_offset(bus, device, function, register) = + bus << 16 | device << 11 | function << 8 | register + +Whilst ECAM extends this by 4 bits to accomodate 4k of function space: + + cfg_offset(bus, device, function, register) = + bus << 20 | device << 15 | function << 12 | register + +Interrupt mapping is exactly as described in `Open Firmware Recommended +Practice: Interrupt Mapping' and requires the following properties: + +- #interrupt-cells : Must be 1 + +- interrupt-map : + +- interrupt-map-mask : + + +Example: + +pci { + compatible = "pci-host-cam-generic" + device_type = "pci"; + #address-cells = <3>; + #size-cells = <2>; + bus-range = <0x0 0x1>; + + // CPU_PHYSICAL(2) SIZE(2) + reg = <0x0 0x40000000 0x0 0x1000000>; + + // BUS_ADDRESS(3) CPU_PHYSICAL(2) SIZE(2) + ranges = <0x01000000 0x0 0x01000000 0x0 0x01000000 0x0 0x00010000>, + <0x02000000 0x0 0x41000000 0x0 0x41000000 0x0 0x3f000000>; + + + #interrupt-cells = <0x1>; + + // PCI_DEVICE(3) INT#(1) CONTROLLER(PHANDLE) CONTROLLER_DATA(3) + interrupt-map = < 0x0 0x0 0x0 0x1 &gic 0x0 0x4 0x1 + 0x800 0x0 0x0 0x1 &gic 0x0 0x5 0x1 + 0x1000 0x0 0x0 0x1 &gic 0x0 0x6 0x1 + 0x1800 0x0 0x0 0x1 &gic 0x0 0x7 0x1>; + + // PCI_DEVICE(3) INT#(1) + interrupt-map-mask = <0xf800 0x0 0x0 0x7>; +} -- cgit v1.1 From b042098063849794d69b5322fcc6cf9fb5f2586e Mon Sep 17 00:00:00 2001 From: "J. Bruce Fields" Date: Tue, 18 Mar 2014 17:44:10 -0400 Subject: nfsd4: allow exotic read compounds I'm not sure why a client would want to stuff multiple reads in a single compound rpc, but it's legal for them to do it, and we should really support it. Signed-off-by: J. Bruce Fields --- Documentation/filesystems/nfs/nfs41-server.txt | 2 -- 1 file changed, 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/nfs/nfs41-server.txt b/Documentation/filesystems/nfs/nfs41-server.txt index b930ad0..c49cd7e 100644 --- a/Documentation/filesystems/nfs/nfs41-server.txt +++ b/Documentation/filesystems/nfs/nfs41-server.txt @@ -176,7 +176,5 @@ Nonstandard compound limitations: ca_maxrequestsize request and a ca_maxresponsesize reply, so we may fail to live up to the promise we made in CREATE_SESSION fore channel negotiation. -* No more than one read-like operation allowed per compound; encoding - replies that cross page boundaries (except for read data) not handled. See also http://wiki.linux-nfs.org/wiki/index.php/Server_4.0_and_4.1_issues. -- cgit v1.1 From 2c6db77c021e89985c512ec9db9cbc5a34a7e3d9 Mon Sep 17 00:00:00 2001 From: Dylan Reid Date: Fri, 30 May 2014 19:15:47 -0700 Subject: ALSA: Docs: Fix typo in tegra_hda doc. The correct name of the third clock is hda2codec_2x. Signed-off-by: Dylan Reid Signed-off-by: Takashi Iwai --- Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt index c26f8ca..b4730c2 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt @@ -20,9 +20,9 @@ hda@0,70030000 { clocks = <&tegra_car TEGRA124_CLK_HDA>, <&tegra_car TEGRA124_CLK_HDA2HDMI>, <&tegra_car TEGRA124_CLK_HDA2CODEC_2X>; - clock-names = "hda", "hda2hdmi", "hdacodec_2x"; + clock-names = "hda", "hda2hdmi", "hda2codec_2x"; resets = <&tegra_car 125>, /* hda */ <&tegra_car 128>; /* hda2hdmi */ <&tegra_car 111>, /* hda2codec_2x */ - reset-names = "hda", "hda2hdmi", "hdacodec_2x"; + reset-names = "hda", "hda2hdmi", "hda2codec_2x"; }; -- cgit v1.1 From 4fc0a7e889e5540305926e41931cf3bc0a60abb2 Mon Sep 17 00:00:00 2001 From: Lv Zheng Date: Sat, 31 May 2014 08:15:02 +0800 Subject: ACPI: Fix x86 regression related to early mapping size limitation The following warning message is triggered: WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:136 __early_ioremap+0x11f/0x1f2() Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 3.15.0-rc1-00017-g86dfc6f3-dirty #298 Hardware name: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.99.99.x036.091920111209 09/19/2011 0000000000000009 ffffffff81b75c40 ffffffff817c627b 0000000000000000 ffffffff81b75c78 ffffffff81067b5d 000000000000007b 8000000000000563 00000000b96b20dc 0000000000000001 ffffffffff300e0c ffffffff81b75c88 Call Trace: [] dump_stack+0x45/0x56 [] warn_slowpath_common+0x7d/0xa0 [] warn_slowpath_null+0x1a/0x20 [] __early_ioremap+0x11f/0x1f2 [] early_ioremap+0x13/0x15 [] __acpi_map_table+0x13/0x18 [] acpi_os_map_memory+0x26/0x14e [] acpi_tb_acquire_table+0x42/0x70 [] acpi_tb_validate_table+0x27/0x37 [] acpi_tb_verify_table+0x22/0xd8 [] acpi_tb_install_non_fixed_table+0x60/0x1c9 [] acpi_tb_parse_root_table+0x218/0x26a [] ? early_idt_handlers+0x120/0x120 [] acpi_initialize_tables+0x57/0x59 [] acpi_table_init+0x1b/0x99 [] acpi_boot_table_init+0x1e/0x85 [] setup_arch+0x99d/0xcc6 [] ? early_idt_handlers+0x120/0x120 [] start_kernel+0x8b/0x415 [] ? early_idt_handlers+0x120/0x120 [] x86_64_start_reservations+0x2a/0x2c [] x86_64_start_kernel+0x13e/0x14d ---[ end trace 11ae599a1898f4e7 ]--- when installing the following table during early stage: ACPI: SSDT 0x00000000B9638018 07A0C4 (v02 INTEL S2600CP 00004000 INTL 20100331) The regression is caused by the size limitation of the x86 early IO mapping. The root cause is: 1. ACPICA doesn't split IO memory mapping and table mapping; 2. Linux x86 OSL implements acpi_os_map_memory() using a size limited fix-map mechanism during early boot stage, which is more suitable for only IO mappings. This patch fixes this issue by utilizing acpi_gbl_verify_table_checksum to disable the table mapping during early stage and enabling it again for the late stage. In this way, the normal code path is not affected. Then after the code related to the root cause is cleaned up, the early checksum verification can be easily re-enabled. A new boot parameter - acpi_force_table_verification is introduced for the platforms that require the checksum verification to stop loading bad tables. This fix also covers the checksum verification for the table overrides. Now large tables can also be overridden using the initrd override mechanism. Signed-off-by: Lv Zheng Reported-and-tested-by: Yuanhan Liu Signed-off-by: Rafael J. Wysocki --- Documentation/kernel-parameters.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 60a2789..4b7cc14 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -214,6 +214,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. unusable. The "log_buf_len" parameter may be useful if you need to capture more output. + acpi_force_table_verification [HW,ACPI] + Enable table checksum verification during early stage. + By default, this is disabled due to x86 early mapping + size limitation. + acpi_irq_balance [HW,ACPI] ACPI will balance active IRQs default in APIC mode -- cgit v1.1 From 437b680a222098f67ecb1690f8eb91f550bfaac8 Mon Sep 17 00:00:00 2001 From: Nicolas Pitre Date: Fri, 30 May 2014 20:58:27 +0100 Subject: ARM: 8066/1: correction for ARM patch 8031/2 A small mistake slipped through in memory.txt. Signed-off-by: Nicolas Pitre Signed-off-by: Russell King --- Documentation/arm/memory.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/arm/memory.txt b/Documentation/arm/memory.txt index 256c5e0..38dc06d 100644 --- a/Documentation/arm/memory.txt +++ b/Documentation/arm/memory.txt @@ -41,7 +41,7 @@ fffe8000 fffeffff DTCM mapping area for platforms with fffe0000 fffe7fff ITCM mapping area for platforms with ITCM mounted inside the CPU. -fffc0000 ffdfffff Fixmap mapping region. Addresses provided +ffc00000 ffdfffff Fixmap mapping region. Addresses provided by fix_to_virt() will be located here. fee00000 feffffff Mapping of PCI I/O space. This is a static -- cgit v1.1 From b8b52471e87a713e61d26fa2f546fda0fb04e8fd Mon Sep 17 00:00:00 2001 From: Andrew Bresticker Date: Tue, 22 Apr 2014 04:09:10 +0530 Subject: drm/exynos: dp: support hotplug detection via GPIO Certain bridge chips use a GPIO to indicate the cable status instead of the I_DP_HPD pin. This adds an optional device-tree property, "samsung,hpd-gpio", to the exynos-dp controller which indicates that the specified GPIO should be used for hotplug detection. The GPIO is then set up as an edge-triggered interrupt where the rising edge indicates hotplug-in and the falling edge indicates hotplug-out. Signed-off-by: Andrew Bresticker Signed-off-by: Rahul Sharma Signed-off-by: Ajay Kumar Acked-by: Jingoo Han Signed-off-by: Inki Dae --- Documentation/devicetree/bindings/video/exynos_dp.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt index 57ccdde..53dbccf 100644 --- a/Documentation/devicetree/bindings/video/exynos_dp.txt +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt @@ -62,6 +62,10 @@ Optional properties for dp-controller: -hsync-active-high: HSYNC polarity configuration. High if defined, Low if not defined + -samsung,hpd-gpio: + Hotplug detect GPIO. + Indicates which GPIO should be used for hotplug + detection Example: -- cgit v1.1 From a18a2ddabdcc9e2762b270cf4fc4b31cb1a8fce2 Mon Sep 17 00:00:00 2001 From: Rahul Sharma Date: Sun, 20 Apr 2014 15:51:17 +0530 Subject: drm/exynos: enable support for exynos5420 hdmi device Enable support for hdmi for exynos5420 hdmiphy. Add compatible string in the of_match table. Also added hdmiphy configuration values for exynos5420. Signed-off-by: Rahul Sharma Signed-off-by: Shirish S Signed-off-by: Inki Dae --- Documentation/devicetree/bindings/video/exynos_hdmi.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index f9187a2..75ada04 100644 --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt @@ -5,6 +5,7 @@ Required properties: 1) "samsung,exynos5-hdmi" 2) "samsung,exynos4210-hdmi" 3) "samsung,exynos4212-hdmi" + 4) "samsung,exynos5420-hdmi" - reg: physical base address of the hdmi and length of memory mapped region. - interrupts: interrupt number to the cpu. -- cgit v1.1 From 049d34e94f9aa2c3ed22a7bad75dd188ec7dacb9 Mon Sep 17 00:00:00 2001 From: Rahul Sharma Date: Tue, 20 May 2014 10:36:05 +0530 Subject: drm/exynos: use regmap interface to set hdmiphy control bit in pmu Exynos drm hdmi driver used to get dummy hdmiphy clock to control the PMU bit for hdmiphy. This bit needs to be set before setting any resolution to hdmi hardware. This was handled using dummy hdmiphy clock which is removed here. PMU is already defined as system controller for exynos SoCs. Hdmi driver is modified to control the phy enable bit inside PMU using regmap interfaces. Devicetree binding document for hdmi is also updated. Signed-off-by: Rahul Sharma Signed-off-by: Inki Dae --- Documentation/devicetree/bindings/video/exynos_hdmi.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index 75ada04..1fd8cf9 100644 --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt @@ -28,6 +28,7 @@ Required properties: "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi". - ddc: phandle to the hdmi ddc node - phy: phandle to the hdmi phy node +- samsung,syscon-phandle: phandle for system controller node for PMU. Example: @@ -38,4 +39,5 @@ Example: hpd-gpio = <&gpx3 7 1>; ddc = <&hdmi_ddc_node>; phy = <&hdmi_phy_node>; + samsung,syscon-phandle = <&pmu_system_controller>; }; -- cgit v1.1 From 9d296ec6fd4051c806677d39b3ce11d48d3d90d5 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Fri, 23 May 2014 10:34:35 +0200 Subject: of: dma: Grammar s/requests/request/, s/used required/required/ Signed-off-by: Geert Uytterhoeven Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/dma/dma.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/dma.txt b/Documentation/devicetree/bindings/dma/dma.txt index 8f504e6..8210427 100644 --- a/Documentation/devicetree/bindings/dma/dma.txt +++ b/Documentation/devicetree/bindings/dma/dma.txt @@ -14,7 +14,7 @@ Required property: Optional properties: - dma-channels: Number of DMA channels supported by the controller. -- dma-requests: Number of DMA requests signals supported by the +- dma-requests: Number of DMA request signals supported by the controller. Example: @@ -44,7 +44,7 @@ Required property: #dma-cells property in the node referenced by phandle containing DMA controller specific information. This typically contains a DMA request line number or a - channel number, but can contain any data that is used + channel number, but can contain any data that is required for configuring a channel. - dma-names: Contains one identifier string for each DMA specifier in the dmas property. The specific strings that can be used -- cgit v1.1 From 819a39510ed8e7f473309d071ede0fb02f0d0e79 Mon Sep 17 00:00:00 2001 From: Wolfram Sang Date: Tue, 27 May 2014 14:06:28 +0200 Subject: i2c: rcar: add compatibles for additional SoC Signed-off-by: Wolfram Sang Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/i2c-rcar.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt index dd8b2dd..16b3e07 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt @@ -7,6 +7,9 @@ Required properties: "renesas,i2c-r8a7779" "renesas,i2c-r8a7790" "renesas,i2c-r8a7791" + "renesas,i2c-r8a7792" + "renesas,i2c-r8a7793" + "renesas,i2c-r8a7794" - reg: physical base address of the controller and length of memory mapped region. - interrupts: interrupt specifier. -- cgit v1.1 From e3cfeefc0e491af00155525131285821e26f7715 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= Date: Fri, 30 May 2014 09:31:10 +0200 Subject: net: cdc_ncm: document the sysfs API MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Adding documentation for all the driver specific sysfs attributes. Cc: Peter Stuge Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller --- Documentation/ABI/testing/sysfs-class-net-cdc_ncm | 149 ++++++++++++++++++++++ 1 file changed, 149 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-net-cdc_ncm (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-net-cdc_ncm b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm new file mode 100644 index 0000000..5cedf72d --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm @@ -0,0 +1,149 @@ +What: /sys/class/net//cdc_ncm/min_tx_pkt +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork +Description: + The driver will pad NCM Transfer Blocks (NTBs) longer + than this to tx_max, allowing the device to receive + tx_max sized frames with no terminating short + packet. NTBs shorter than this limit are transmitted + as-is, without any padding, and are terminated with a + short USB packet. + + Padding to tx_max allows the driver to transmit NTBs + back-to-back without any interleaving short USB + packets. This reduces the number of short packet + interrupts in the device, and represents a tradeoff + between USB bus bandwidth and device DMA optimization. + + Set to 0 to pad all frames. Set greater than tx_max to + disable all padding. + +What: /sys/class/net//cdc_ncm/rx_max +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork +Description: + The maximum NTB size for RX. Cannot exceed the + maximum value supported by the device. Must allow at + least one max sized datagram plus headers. + + The actual limits are device dependent. See + dwNtbInMaxSize. + + Note: Some devices will silently ignore changes to + this value, resulting in oversized NTBs and + corresponding framing errors. + +What: /sys/class/net//cdc_ncm/tx_max +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork +Description: + The maximum NTB size for TX. Cannot exceed the + maximum value supported by the device. Must allow at + least one max sized datagram plus headers. + + The actual limits are device dependent. See + dwNtbOutMaxSize. + +What: /sys/class/net//cdc_ncm/tx_timer_usecs +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork +Description: + Datagram aggregation timeout in µs. The driver will + wait up to 3 times this timeout for more datagrams to + aggregate before transmitting an NTB frame. + + Valid range: 5 to 4000000 + + Set to 0 to disable aggregation. + +The following read-only attributes all represent fields of the +structure defined in section 6.2.1 "GetNtbParameters" of "Universal +Serial Bus Communications Class Subclass Specifications for Network +Control Model Devices" (CDC NCM), Revision 1.0 (Errata 1), November +24, 2010 from USB Implementers Forum, Inc. The descriptions are +quoted from table 6-3 of CDC NCM: "NTB Parameter Structure". + +What: /sys/class/net//cdc_ncm/bmNtbFormatsSupported +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork +Description: + Bit 0: 16-bit NTB supported (set to 1) + Bit 1: 32-bit NTB supported + Bits 2 – 15: reserved (reset to zero; must be ignored by host) + +What: /sys/class/net//cdc_ncm/dwNtbInMaxSize +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork +Description: + IN NTB Maximum Size in bytes + +What: /sys/class/net//cdc_ncm/wNdpInDivisor +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork +Description: + Divisor used for IN NTB Datagram payload alignment + +What: /sys/class/net//cdc_ncm/wNdpInPayloadRemainder +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork +Description: + Remainder used to align input datagram payload within + the NTB: (Payload Offset) mod (wNdpInDivisor) = + wNdpInPayloadRemainder + +What: /sys/class/net//cdc_ncm/wNdpInAlignment +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork +Description: + NDP alignment modulus for NTBs on the IN pipe. Shall + be a power of 2, and shall be at least 4. + +What: /sys/class/net//cdc_ncm/dwNtbOutMaxSize +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork +Description: + OUT NTB Maximum Size + +What: /sys/class/net//cdc_ncm/wNdpOutDivisor +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork +Description: + OUT NTB Datagram alignment modulus + +What: /sys/class/net//cdc_ncm/wNdpOutPayloadRemainder +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork +Description: + Remainder used to align output datagram payload + offsets within the NTB: Padding, shall be transmitted + as zero by function, and ignored by host. (Payload + Offset) mod (wNdpOutDivisor) = wNdpOutPayloadRemainder + +What: /sys/class/net//cdc_ncm/wNdpOutAlignment +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork +Description: + NDP alignment modulus for use in NTBs on the OUT + pipe. Shall be a power of 2, and shall be at least 4. + +What: /sys/class/net//cdc_ncm/wNtbOutMaxDatagrams +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork +Description: + Maximum number of datagrams that the host may pack + into a single OUT NTB. Zero means that the device + imposes no limit. -- cgit v1.1 From 75fa9ea6e3c0223cf9f56ed15b0ea3e9ccc627f1 Mon Sep 17 00:00:00 2001 From: Guennadi Liakhovetski Date: Sat, 31 May 2014 20:38:51 +0200 Subject: mmc: add a driver for the Renesas usdhi6rol0 SD/SDIO host controller This patch adds a driver for the Renesas usdhi6rol0 SD/SDIO host controller in both PIO and DMA modes. Signed-off-by: Guennadi Liakhovetski Signed-off-by: Chris Ball --- .../devicetree/bindings/mmc/usdhi6rol0.txt | 33 ++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 Documentation/devicetree/bindings/mmc/usdhi6rol0.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt b/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt new file mode 100644 index 0000000..8babdaa --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt @@ -0,0 +1,33 @@ +* Renesas usdhi6rol0 SD/SDIO host controller + +Required properties: + +- compatible: must be + "renesas,usdhi6rol0" +- interrupts: 3 interrupts, named "card detect", "data" and "SDIO" must be + specified +- clocks: a clock binding for the IMCLK input + +Optional properties: + +- vmmc-supply: a phandle of a regulator, supplying Vcc to the card +- vqmmc-supply: a phandle of a regulator, supplying VccQ to the card + +Additionally any standard mmc bindings from mmc.txt can be used. + +Example: + +sd0: sd@ab000000 { + compatible = "renesas,usdhi6rol0"; + reg = <0xab000000 0x200>; + interrupts = <0 23 0x4 + 0 24 0x4 + 0 25 0x4>; + interrupt-names = "card detect", "data", "SDIO"; + bus-width = <4>; + max-frequency = <50000000>; + cap-power-off-card; + clocks = <&imclk>; + vmmc-supply = <&vcc_sd0>; + vqmmc-supply = <&vccq_sd0>; +}; -- cgit v1.1 From f70e9d88a105db9a8cf4dc4d5675d0a54def70c9 Mon Sep 17 00:00:00 2001 From: Zhangfei Gao Date: Tue, 3 Jun 2014 13:49:36 +0800 Subject: Documentation: add Device tree bindings for Hisilicon hix5hd2 ethernet Signed-off-by: Zhangfei Gao Signed-off-by: David S. Miller --- .../bindings/net/hisilicon-hix5hd2-gmac.txt | 36 ++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt new file mode 100644 index 0000000..75d398b --- /dev/null +++ b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt @@ -0,0 +1,36 @@ +Hisilicon hix5hd2 gmac controller + +Required properties: +- compatible: should be "hisilicon,hix5hd2-gmac". +- reg: specifies base physical address(s) and size of the device registers. + The first region is the MAC register base and size. + The second region is external interface control register. +- interrupts: should contain the MAC interrupt. +- #address-cells: must be <1>. +- #size-cells: must be <0>. +- phy-mode: see ethernet.txt [1]. +- phy-handle: see ethernet.txt [1]. +- mac-address: see ethernet.txt [1]. +- clocks: clock phandle and specifier pair. + +- PHY subnode: inherits from phy binding [2] + +[1] Documentation/devicetree/bindings/net/ethernet.txt +[2] Documentation/devicetree/bindings/net/phy.txt + +Example: + gmac0: ethernet@f9840000 { + compatible = "hisilicon,hix5hd2-gmac"; + reg = <0xf9840000 0x1000>,<0xf984300c 0x4>; + interrupts = <0 71 4>; + #address-cells = <1>; + #size-cells = <0>; + phy-mode = "mii"; + phy-handle = <&phy2>; + mac-address = [00 00 00 00 00 00]; + clocks = <&clock HIX5HD2_MAC0_CLK>; + + phy2: ethernet-phy@2 { + reg = <2>; + }; + }; -- cgit v1.1 From 68bab8662f49b9e158f1d32f11becd4e48c04079 Mon Sep 17 00:00:00 2001 From: Peter Ujfalusi Date: Thu, 3 Apr 2014 13:54:41 +0300 Subject: mfd: twl6040: Optional clk32k clock handling In certain boards the source for the clk32k clock can be gated. In these boards the clk32k clock can be provided to the driver and it is going to be enabled/disabled when it is needed. If the clk32k clock is not provided the driver will assume that it is always running. Signed-off-by: Peter Ujfalusi Signed-off-by: Lee Jones --- Documentation/devicetree/bindings/mfd/twl6040.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/twl6040.txt b/Documentation/devicetree/bindings/mfd/twl6040.txt index 0f5dd70..a41157b 100644 --- a/Documentation/devicetree/bindings/mfd/twl6040.txt +++ b/Documentation/devicetree/bindings/mfd/twl6040.txt @@ -19,6 +19,8 @@ Required properties: Optional properties, nodes: - enable-active-high: To power on the twl6040 during boot. +- clocks: phandle to the clk32k clock provider +- clock-names: Must be "clk32k" Vibra functionality Required properties: -- cgit v1.1 From e4e3d1b03695c458a954954c8efae745517dd44d Mon Sep 17 00:00:00 2001 From: Boris BREZILLON Date: Fri, 9 May 2014 13:11:48 +0200 Subject: mfd: sun6i-prcm: Document DT bindings Document DT bindings of the PRCM (Power/Reset/Clock Management) unit. Signed-off-by: Boris BREZILLON Signed-off-by: Lee Jones --- .../devicetree/bindings/mfd/sun6i-prcm.txt | 59 ++++++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/sun6i-prcm.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt b/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt new file mode 100644 index 0000000..1f5a31fe --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt @@ -0,0 +1,59 @@ +* Allwinner PRCM (Power/Reset/Clock Management) Multi-Functional Device + +PRCM is an MFD device exposing several Power Management related devices +(like clks and reset controllers). + +Required properties: + - compatible: "allwinner,sun6i-a31-prcm" + - reg: The PRCM registers range + +The prcm node may contain several subdevices definitions: + - see Documentation/devicetree/clk/sunxi.txt for clock devices + - see Documentation/devicetree/reset/allwinner,sunxi-clock-reset.txt for reset + controller devices + + +Example: + + prcm: prcm@01f01400 { + compatible = "allwinner,sun6i-a31-prcm"; + reg = <0x01f01400 0x200>; + + /* Put subdevices here */ + ar100: ar100_clk { + compatible = "allwinner,sun6i-a31-ar100-clk"; + #clock-cells = <0>; + clocks = <&osc32k>, <&osc24M>, <&pll6>, <&pll6>; + }; + + ahb0: ahb0_clk { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clock-div = <1>; + clock-mult = <1>; + clocks = <&ar100_div>; + clock-output-names = "ahb0"; + }; + + apb0: apb0_clk { + compatible = "allwinner,sun6i-a31-apb0-clk"; + #clock-cells = <0>; + clocks = <&ahb0>; + clock-output-names = "apb0"; + }; + + apb0_gates: apb0_gates_clk { + compatible = "allwinner,sun6i-a31-apb0-gates-clk"; + #clock-cells = <1>; + clocks = <&apb0>; + clock-output-names = "apb0_pio", "apb0_ir", + "apb0_timer01", "apb0_p2wi", + "apb0_uart", "apb0_1wire", + "apb0_i2c"; + }; + + apb0_rst: apb0_rst { + compatible = "allwinner,sun6i-a31-clock-reset"; + #reset-cells = <1>; + }; + }; -- cgit v1.1 From 9d230c9e4f4e67cb1c1cb9e0f6142da16b0f2796 Mon Sep 17 00:00:00 2001 From: Doug Anderson Date: Wed, 30 Apr 2014 10:44:09 -0700 Subject: i2c: ChromeOS EC tunnel driver On ARM Chromebooks we have a few devices that are accessed by both the AP (the main "Application Processor") and the EC (the Embedded Controller). These are: * The battery (sbs-battery). * The power management unit tps65090. On the original Samsung ARM Chromebook these devices were on an I2C bus that was shared between the AP and the EC and arbitrated using some extranal GPIOs (see i2c-arb-gpio-challenge). The original arbitration scheme worked well enough but had some downsides: * It was nonstandard (not using standard I2C multimaster) * It only worked if the EC-AP communication was I2C * It was relatively hard to debug problems (hard to tell if i2c issues were caused by the EC, the AP, or some device on the bus). On the HP Chromebook 11 the design was changed to: * The AP/EC comms were still i2c, but the battery/tps65090 were no longer on the bus used for AP/EC communication. The battery was exposed to the AP through a limited i2c tunnel and tps65090 was exposed to the AP through a custom Linux driver. On the Samsung ARM Chromebook 2 the scheme is changed yet again, now: * The AP/EC comms are now using SPI for faster speeds. * The EC's i2c bus is exposed to the AP through a full i2c tunnel. The upstream "tegra124-venice2" uses the same scheme as the Samsung ARM Chromebook 2, though it has a different set of components on the other side of the bus. This driver supports the scheme used by the Samsung ARM Chromebook 2. Future patches to this driver could add support for the battery tunnel on the HP Chromebook 11 (and perhaps could even be used to access tps65090 on the HP Chromebook 11 instead of using a special driver, but I haven't researched that enough). Signed-off-by: Vincent Palatin Signed-off-by: Simon Glass Signed-off-by: Doug Anderson Reviewed-by: Wolfram Sang Signed-off-by: Lee Jones --- .../devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt | 39 ++++++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt b/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt new file mode 100644 index 0000000..898f030 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt @@ -0,0 +1,39 @@ +I2C bus that tunnels through the ChromeOS EC (cros-ec) +====================================================== +On some ChromeOS board designs we've got a connection to the EC (embedded +controller) but no direct connection to some devices on the other side of +the EC (like a battery and PMIC). To get access to those devices we need +to tunnel our i2c commands through the EC. + +The node for this device should be under a cros-ec node like google,cros-ec-spi +or google,cros-ec-i2c. + + +Required properties: +- compatible: google,cros-ec-i2c-tunnel +- google,remote-bus: The EC bus we'd like to talk to. + +Optional child nodes: +- One node per I2C device connected to the tunnelled I2C bus. + + +Example: + cros-ec@0 { + compatible = "google,cros-ec-spi"; + + ... + + i2c-tunnel { + compatible = "google,cros-ec-i2c-tunnel"; + #address-cells = <1>; + #size-cells = <0>; + + google,remote-bus = <0>; + + battery: sbs-battery@b { + compatible = "sbs,sbs-battery"; + reg = <0xb>; + sbs,poll-retry-count = <1>; + }; + }; + } -- cgit v1.1 From 60fd011bfaaae91f0f795621ba80d6f5d46ca966 Mon Sep 17 00:00:00 2001 From: Ivan Khoronzhuk Date: Thu, 22 May 2014 19:44:18 +0300 Subject: mfd: ti-keystone-devctrl: Add bindings for device state control The Keystone II devices have a set of registers that are used to control the status of its peripherals. This node is intended to allow access to this functionality. Reviewed-by: Arnd Bergmann Signed-off-by: Ivan Khoronzhuk Signed-off-by: Lee Jones --- .../devicetree/bindings/mfd/ti-keystone-devctrl.txt | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/ti-keystone-devctrl.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/ti-keystone-devctrl.txt b/Documentation/devicetree/bindings/mfd/ti-keystone-devctrl.txt new file mode 100644 index 0000000..20963c7 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/ti-keystone-devctrl.txt @@ -0,0 +1,19 @@ +* Device tree bindings for Texas Instruments keystone device state control + +The Keystone II devices have a set of registers that are used to control +the status of its peripherals. This node is intended to allow access to +this functionality. + +Required properties: + +- compatible: "ti,keystone-devctrl", "syscon" + +- reg: contains offset/length value for device state control + registers space. + +Example: + +devctrl: device-state-control@0x02620000 { + compatible = "ti,keystone-devctrl", "syscon"; + reg = <0x02620000 0x1000>; +}; -- cgit v1.1 From 1db823ee9f677e1a863cd04fda391a7520fcd0e8 Mon Sep 17 00:00:00 2001 From: Lucas Stach Date: Tue, 3 Jun 2014 08:44:25 -0600 Subject: PCI: designware: Split Exynos and i.MX bindings The glue around the core designware IP is significantly different between the Exynos and i.MX implementation, which is reflected in the DT bindings. This changes the i.MX6 binding to reuse as much as possible from the common designware binding and removes old cruft. I removed the optional GPIOs with the following reasoning: - disable-gpio: endpoint specific GPIO, not currently wired up in any code. Should be handled by the PCI device driver, not the host controller driver. - wake-up-gpio: same as above. - power-on-gpio: No user in any upstream DT. This should be handled by a regulator which shouldn't be controlled by the host driver, but rather by the PCI device driver. [bhelgaas: whitespace fixes] Signed-off-by: Lucas Stach Signed-off-by: Bjorn Helgaas --- .../devicetree/bindings/pci/designware-pcie.txt | 74 ++-------------------- .../devicetree/bindings/pci/fsl,imx6q-pcie.txt | 38 +++++++++++ .../bindings/pci/samsung,exynos5440-pcie.txt | 65 +++++++++++++++++++ 3 files changed, 109 insertions(+), 68 deletions(-) create mode 100644 Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt create mode 100644 Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt index d6fae13f..d0d15ee 100644 --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt @@ -1,15 +1,7 @@ * Synopsys 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" or "fsl,imx6q-pcie". -- reg: base addresses and lengths of the pcie controller, - the phy controller, additional register for the phy controller. -- interrupts: interrupt values for level interrupt, - 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". +- compatible: should contain "snps,dw-pcie" to identify the core. - #address-cells: set to <3> - #size-cells: set to <2> - device_type: set to "pci" @@ -19,65 +11,11 @@ Required properties: to define the mapping of the PCIe interface to interrupt numbers. - num-lanes: number of lanes to use +- clocks: Must contain an entry for each entry in clock-names. + See ../clocks/clock-bindings.txt for details. +- clock-names: Must include the following entries: + - "pcie" + - "pcie_bus" Optional properties: - reset-gpio: gpio pin number of power good signal - -Optional properties for fsl,imx6q-pcie -- power-on-gpio: gpio pin number of power-enable signal -- wake-up-gpio: gpio pin number of incoming wakeup signal -- disable-gpio: gpio pin number of outgoing rfkill/endpoint disable signal - -Example: - -SoC specific DT Entry: - - 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>; - num-lanes = <4>; - }; - - 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>; - num-lanes = <4>; - }; - -Board specific DT Entry: - - pcie@290000 { - reset-gpio = <&pin_ctrl 5 0>; - }; - - pcie@2a0000 { - reset-gpio = <&pin_ctrl 22 0>; - }; diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt new file mode 100644 index 0000000..9455fd0 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt @@ -0,0 +1,38 @@ +* Freescale i.MX6 PCIe interface + +This PCIe host controller is based on the Synopsis Designware PCIe IP +and thus inherits all the common properties defined in designware-pcie.txt. + +Required properties: +- compatible: "fsl,imx6q-pcie" +- reg: base addresse and length of the pcie controller +- interrupts: A list of interrupt outputs of the controller. Must contain an + entry for each entry in the interrupt-names property. +- interrupt-names: Must include the following entries: + - "msi": The interrupt that is asserted when an MSI is received +- clock-names: Must include the following additional entries: + - "pcie_phy" + +Example: + + pcie@0x01000000 { + compatible = "fsl,imx6q-pcie", "snps,dw-pcie"; + reg = <0x01ffc000 0x4000>; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + ranges = <0x00000800 0 0x01f00000 0x01f00000 0 0x00080000 + 0x81000000 0 0 0x01f80000 0 0x00010000 + 0x82000000 0 0x01000000 0x01000000 0 0x00f00000>; + num-lanes = <1>; + interrupts = ; + interrupt-names = "msi"; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0x7>; + interrupt-map = <0 0 0 1 &intc GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>, + <0 0 0 2 &intc GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>, + <0 0 0 3 &intc GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>, + <0 0 0 4 &intc GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clks 144>, <&clks 206>, <&clks 189>; + clock-names = "pcie", "pcie_bus", "pcie_phy"; + }; diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt new file mode 100644 index 0000000..4f9d23d --- /dev/null +++ b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt @@ -0,0 +1,65 @@ +* Samsung Exynos 5440 PCIe interface + +This PCIe host controller is based on the Synopsis Designware PCIe IP +and thus inherits all the common properties defined in designware-pcie.txt. + +Required properties: +- compatible: "samsung,exynos5440-pcie" +- reg: base addresses and lengths of the pcie controller, + the phy controller, additional register for the phy controller. +- interrupts: A list of interrupt outputs for level interrupt, + pulse interrupt, special interrupt. + +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 = <0 0 0 0 &gic GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>; + num-lanes = <4>; + }; + + 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 = <0 0 0 0 &gic GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>; + num-lanes = <4>; + }; + +Board specific DT Entry: + + pcie@290000 { + reset-gpio = <&pin_ctrl 5 0>; + }; + + pcie@2a0000 { + reset-gpio = <&pin_ctrl 22 0>; + }; -- cgit v1.1 From f9b2a735bdddf836214b5dca74f6ca7712e5a08c Mon Sep 17 00:00:00 2001 From: Mimi Zohar Date: Mon, 12 May 2014 09:28:11 -0400 Subject: ima: audit log files opened with O_DIRECT flag Files are measured or appraised based on the IMA policy. When a file, in policy, is opened with the O_DIRECT flag, a deadlock occurs. The first attempt at resolving this lockdep temporarily removed the O_DIRECT flag and restored it, after calculating the hash. The second attempt introduced the O_DIRECT_HAVELOCK flag. Based on this flag, do_blockdev_direct_IO() would skip taking the i_mutex a second time. The third attempt, by Dmitry Kasatkin, resolves the i_mutex locking issue, by re-introducing the IMA mutex, but uncovered another problem. Reading a file with O_DIRECT flag set, writes directly to userspace pages. A second patch allocates a user-space like memory. This works for all IMA hooks, except ima_file_free(), which is called on __fput() to recalculate the file hash. Until this last issue is addressed, do not 'collect' the measurement for measuring, appraising, or auditing files opened with the O_DIRECT flag set. Based on policy, permit or deny file access. This patch defines a new IMA policy rule option named 'permit_directio'. Policy rules could be defined, based on LSM or other criteria, to permit specific applications to open files with the O_DIRECT flag set. Changelog v1: - permit or deny file access based IMA policy rules Signed-off-by: Mimi Zohar Acked-by: Dmitry Kasatkin Cc: --- Documentation/ABI/testing/ima_policy | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy index f1c5cc9..4c3efe4 100644 --- a/Documentation/ABI/testing/ima_policy +++ b/Documentation/ABI/testing/ima_policy @@ -23,7 +23,7 @@ Description: [fowner]] lsm: [[subj_user=] [subj_role=] [subj_type=] [obj_user=] [obj_role=] [obj_type=]] - option: [[appraise_type=]] + option: [[appraise_type=]] [permit_directio] base: func:= [BPRM_CHECK][MMAP_CHECK][FILE_CHECK][MODULE_CHECK] mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC] -- cgit v1.1 From 3cbcb16095f916f50a5a55066fcc4be06946ce1e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?David=20Lanzend=C3=B6rfer?= Date: Mon, 12 May 2014 14:04:48 +0200 Subject: mmc: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The Allwinner sunxi mmc host uses dma in bus-master mode using a built-in designware idmac controller, which is identical to the one found in the mmc-dw hosts. However the rest of the host is not identical to mmc-dw, it deals with sending stop commands in hardware which makes it significantly different from the mmc-dw devices. Signed-off-by: David Lanzendörfer [hdegoede@redhat.com: various cleanups and fixes] Signed-off-by: Hans de Goede Acked-by: Maxime Ripard Acked-by: Arnd Bergmann Signed-off-by: Ulf Hansson Acked-by: Chris Ball Signed-off-by: Mike Turquette --- .../devicetree/bindings/mmc/sunxi-mmc.txt | 43 ++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 Documentation/devicetree/bindings/mmc/sunxi-mmc.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt new file mode 100644 index 0000000..91b3a34 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt @@ -0,0 +1,43 @@ +* Allwinner sunxi MMC controller + +The highspeed MMC host controller on Allwinner SoCs provides an interface +for MMC, SD and SDIO types of memory cards. + +Supported maximum speeds are the ones of the eMMC standard 4.5 as well +as the speed of SD standard 3.0. +Absolute maximum transfer rate is 200MB/s + +Required properties: + - compatible : "allwinner,sun4i-a10-mmc" or "allwinner,sun5i-a13-mmc" + - reg : mmc controller base registers + - clocks : a list with 2 phandle + clock specifier pairs + - clock-names : must contain "ahb" and "mmc" + - interrupts : mmc controller interrupt + +Optional properties: + - resets : phandle + reset specifier pair + - reset-names : must contain "ahb" + - for cd, bus-width and additional generic mmc parameters + please refer to mmc.txt within this directory + +Examples: + - Within .dtsi: + mmc0: mmc@01c0f000 { + compatible = "allwinner,sun5i-a13-mmc"; + reg = <0x01c0f000 0x1000>; + clocks = <&ahb_gates 8>, <&mmc0_clk>; + clock-names = "ahb", "mod"; + interrupts = <0 32 4>; + status = "disabled"; + }; + + - Within dts: + mmc0: mmc@01c0f000 { + pinctrl-names = "default", "default"; + pinctrl-0 = <&mmc0_pins_a>; + pinctrl-1 = <&mmc0_cd_pin_reference_design>; + bus-width = <4>; + cd-gpios = <&pio 7 1 0>; /* PH1 */ + cd-inverted; + status = "okay"; + }; -- cgit v1.1 From bfec07d0f8ed78b10df3ca3bc23e27de1166ea45 Mon Sep 17 00:00:00 2001 From: Chao Yu Date: Wed, 28 May 2014 08:56:09 +0800 Subject: f2fs: avoid overflow when large directory feathure is enabled When large directory feathure is enable, We have one case which could cause overflow in dir_buckets() as following: special case: level + dir_level >= 32 and level < MAX_DIR_HASH_DEPTH / 2. Here we define MAX_DIR_BUCKETS to limit the return value when the condition could trigger potential overflow. Changes from V1 o modify description of calculation in f2fs.txt suggested by Changman Lee. Suggested-by: Changman Lee Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim --- Documentation/filesystems/f2fs.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt index 25311e11..51afba1 100644 --- a/Documentation/filesystems/f2fs.txt +++ b/Documentation/filesystems/f2fs.txt @@ -461,11 +461,11 @@ The number of blocks and buckets are determined by, # of blocks in level #n = | `- 4, Otherwise - ,- 2^ (n + dir_level), - | if n < MAX_DIR_HASH_DEPTH / 2, + ,- 2^(n + dir_level), + | if n + dir_level < MAX_DIR_HASH_DEPTH / 2, # of buckets in level #n = | - `- 2^((MAX_DIR_HASH_DEPTH / 2 + dir_level) - 1), - Otherwise + `- 2^((MAX_DIR_HASH_DEPTH / 2) - 1), + Otherwise When F2FS finds a file name in a directory, at first a hash value of the file name is calculated. Then, F2FS scans the hash table in level #0 to find the -- cgit v1.1 From 5ea3b1b2f8ad9162684431ce6188102ca4c64b7a Mon Sep 17 00:00:00 2001 From: Akinobu Mita Date: Wed, 4 Jun 2014 16:06:54 -0700 Subject: cma: add placement specifier for "cma=" kernel parameter Currently, "cma=" kernel parameter is used to specify the size of CMA, but we can't specify where it is located. We want to locate CMA below 4GB for devices only supporting 32-bit addressing on 64-bit systems without iommu. This enables to specify the placement of CMA by extending "cma=" kernel parameter. Examples: 1. locate 64MB CMA below 4GB by "cma=64M@0-4G" 2. locate 64MB CMA exact at 512MB by "cma=64M@512M" Note that the DMA contiguous memory allocator on x86 assumes that page_address() works for the pages to allocate. So this change requires to limit end address of contiguous memory area upto max_pfn_mapped to prevent from locating it on highmem area by the argument of dma_contiguous_reserve(). Signed-off-by: Akinobu Mita Cc: Marek Szyprowski Cc: Konrad Rzeszutek Wilk Cc: David Woodhouse Cc: Don Dutile Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Andi Kleen Cc: Yinghai Lu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/kernel-parameters.txt | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index af55e13..adea3a2 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -630,8 +630,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. Also note the kernel might malfunction if you disable some critical bits. - cma=nn[MG] [ARM,KNL] - Sets the size of kernel global memory area for contiguous + cma=nn[MG]@[start[MG][-end[MG]]] + [ARM,X86,KNL] + Sets the size of kernel global memory area for + contiguous memory allocations and optionally the + placement constraint by the physical address range of memory allocations. For more information, see include/linux/dma-contiguous.h -- cgit v1.1 From 3dae7fec5e884a4e72e5416db0894de66f586201 Mon Sep 17 00:00:00 2001 From: Johannes Weiner Date: Wed, 4 Jun 2014 16:07:01 -0700 Subject: mm: memcontrol: remove hierarchy restrictions for swappiness and oom_control Per-memcg swappiness and oom killing can currently not be tweaked on a memcg that is part of a hierarchy, but not the root of that hierarchy. Users have complained that they can't configure this when they turned on hierarchy mode. In fact, with hierarchy mode becoming the default, this restriction disables the tunables entirely. But there is no good reason for this restriction. The settings for swappiness and OOM killing are taken from whatever memcg whose limit triggered reclaim and OOM invocation, regardless of its position in the hierarchy tree. Allow setting swappiness on any group. The knob on the root memcg already reads the global VM swappiness, make it writable as well. Allow disabling the OOM killer on any non-root memcg. Signed-off-by: Johannes Weiner Cc: Michal Hocko Cc: Tejun Heo Cc: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/cgroups/memory.txt | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index 2622115..1829c65 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt @@ -535,17 +535,15 @@ Note: 5.3 swappiness -Similar to /proc/sys/vm/swappiness, but affecting a hierarchy of groups only. +Similar to /proc/sys/vm/swappiness, but only affecting reclaim that is +triggered by this cgroup's hard limit. The tunable in the root cgroup +corresponds to the global swappiness setting. + Please note that unlike the global swappiness, memcg knob set to 0 really prevents from any swapping even if there is a swap storage available. This might lead to memcg OOM killer if there are no file pages to reclaim. -Following cgroups' swappiness can't be changed. -- root cgroup (uses /proc/sys/vm/swappiness). -- a cgroup which uses hierarchy and it has other cgroup(s) below it. -- a cgroup which uses hierarchy and not the root of hierarchy. - 5.4 failcnt A memory cgroup provides memory.failcnt and memory.memsw.failcnt files. @@ -754,7 +752,6 @@ You can disable the OOM-killer by writing "1" to memory.oom_control file, as: #echo 1 > memory.oom_control -This operation is only allowed to the top cgroup of a sub-hierarchy. If OOM-killer is disabled, tasks under cgroup will hang/sleep in memory cgroup's OOM-waitqueue when they request accountable memory. -- cgit v1.1 From 56a3c655a3d31cb1afef25b530b5ef6a1e7ddefd Mon Sep 17 00:00:00 2001 From: Li Zhong Date: Wed, 4 Jun 2014 16:07:03 -0700 Subject: memory-hotplug: update documentation to hide information about SECTIONS and remove end_phys_index Seems we all agree that information about SECTION, e.g. section size, sections per memory block should be kept as kernel internals, and not exposed to userspace. This patch updates Documentation/memory-hotplug.txt to refer to memory blocks instead of memory sections where appropriate and added a paragraph to explain that memory blocks are made of memory sections. The documentation update is mostly provided by Nathan. Also, as end_phys_index in code is actually not the end section id, but the end memory block id, which should always be the same as phys_index. So it is removed here. Signed-off-by: Li Zhong Reviewed-by: Zhang Yanfei Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/memory-hotplug.txt | 125 +++++++++++++++++++-------------------- 1 file changed, 61 insertions(+), 64 deletions(-) (limited to 'Documentation') diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt index 58340d5..f304edb 100644 --- a/Documentation/memory-hotplug.txt +++ b/Documentation/memory-hotplug.txt @@ -88,16 +88,21 @@ phase by hand. 1.3. Unit of Memory online/offline operation ------------ -Memory hotplug uses SPARSEMEM memory model. SPARSEMEM divides the whole memory -into chunks of the same size. The chunk is called a "section". The size of -a section is architecture dependent. For example, power uses 16MiB, ia64 uses -1GiB. The unit of online/offline operation is "one section". (see Section 3.) +Memory hotplug uses SPARSEMEM memory model which allows memory to be divided +into chunks of the same size. These chunks are called "sections". The size of +a memory section is architecture dependent. For example, power uses 16MiB, ia64 +uses 1GiB. -To determine the size of sections, please read this file: +Memory sections are combined into chunks referred to as "memory blocks". The +size of a memory block is architecture dependent and represents the logical +unit upon which memory online/offline operations are to be performed. The +default size of a memory block is the same as memory section size unless an +architecture specifies otherwise. (see Section 3.) + +To determine the size (in bytes) of a memory block please read this file: /sys/devices/system/memory/block_size_bytes -This file shows the size of sections in byte. ----------------------- 2. Kernel Configuration @@ -123,42 +128,35 @@ config options. (CONFIG_ACPI_CONTAINER). This option can be kernel module too. + -------------------------------- -4 sysfs files for memory hotplug +3 sysfs files for memory hotplug -------------------------------- -All sections have their device information in sysfs. Each section is part of -a memory block under /sys/devices/system/memory as +All memory blocks have their device information in sysfs. Each memory block +is described under /sys/devices/system/memory as /sys/devices/system/memory/memoryXXX -(XXX is the section id.) +(XXX is the memory block id.) -Now, XXX is defined as (start_address_of_section / section_size) of the first -section contained in the memory block. The files 'phys_index' and -'end_phys_index' under each directory report the beginning and end section id's -for the memory block covered by the sysfs directory. It is expected that all +For the memory block covered by the sysfs directory. It is expected that all memory sections in this range are present and no memory holes exist in the range. Currently there is no way to determine if there is a memory hole, but the existence of one should not affect the hotplug capabilities of the memory block. -For example, assume 1GiB section size. A device for a memory starting at +For example, assume 1GiB memory block size. A device for a memory starting at 0x100000000 is /sys/device/system/memory/memory4 (0x100000000 / 1Gib = 4) This device covers address range [0x100000000 ... 0x140000000) -Under each section, you can see 4 or 5 files, the end_phys_index file being -a recent addition and not present on older kernels. +Under each memory block, you can see 4 files: -/sys/devices/system/memory/memoryXXX/start_phys_index -/sys/devices/system/memory/memoryXXX/end_phys_index +/sys/devices/system/memory/memoryXXX/phys_index /sys/devices/system/memory/memoryXXX/phys_device /sys/devices/system/memory/memoryXXX/state /sys/devices/system/memory/memoryXXX/removable -'phys_index' : read-only and contains section id of the first section - in the memory block, same as XXX. -'end_phys_index' : read-only and contains section id of the last section - in the memory block. +'phys_index' : read-only and contains memory block id, same as XXX. 'state' : read-write at read: contains online/offline state of memory. at write: user can specify "online_kernel", @@ -185,6 +183,7 @@ For example: A backlink will also be created: /sys/devices/system/memory/memory9/node0 -> ../../node/node0 + -------------------------------- 4. Physical memory hot-add phase -------------------------------- @@ -227,11 +226,10 @@ You can tell the physical address of new memory to the kernel by % echo start_address_of_new_memory > /sys/devices/system/memory/probe -Then, [start_address_of_new_memory, start_address_of_new_memory + section_size) -memory range is hot-added. In this case, hotplug script is not called (in -current implementation). You'll have to online memory by yourself. -Please see "How to online memory" in this text. - +Then, [start_address_of_new_memory, start_address_of_new_memory + +memory_block_size] memory range is hot-added. In this case, hotplug script is +not called (in current implementation). You'll have to online memory by +yourself. Please see "How to online memory" in this text. ------------------------------ @@ -240,36 +238,36 @@ Please see "How to online memory" in this text. 5.1. State of memory ------------ -To see (online/offline) state of memory section, read 'state' file. +To see (online/offline) state of a memory block, read 'state' file. % cat /sys/device/system/memory/memoryXXX/state -If the memory section is online, you'll read "online". -If the memory section is offline, you'll read "offline". +If the memory block is online, you'll read "online". +If the memory block is offline, you'll read "offline". 5.2. How to online memory ------------ Even if the memory is hot-added, it is not at ready-to-use state. -For using newly added memory, you have to "online" the memory section. +For using newly added memory, you have to "online" the memory block. -For onlining, you have to write "online" to the section's state file as: +For onlining, you have to write "online" to the memory block's state file as: % echo online > /sys/devices/system/memory/memoryXXX/state -This onlining will not change the ZONE type of the target memory section, -If the memory section is in ZONE_NORMAL, you can change it to ZONE_MOVABLE: +This onlining will not change the ZONE type of the target memory block, +If the memory block is in ZONE_NORMAL, you can change it to ZONE_MOVABLE: % echo online_movable > /sys/devices/system/memory/memoryXXX/state -(NOTE: current limit: this memory section must be adjacent to ZONE_MOVABLE) +(NOTE: current limit: this memory block must be adjacent to ZONE_MOVABLE) -And if the memory section is in ZONE_MOVABLE, you can change it to ZONE_NORMAL: +And if the memory block is in ZONE_MOVABLE, you can change it to ZONE_NORMAL: % echo online_kernel > /sys/devices/system/memory/memoryXXX/state -(NOTE: current limit: this memory section must be adjacent to ZONE_NORMAL) +(NOTE: current limit: this memory block must be adjacent to ZONE_NORMAL) -After this, section memoryXXX's state will be 'online' and the amount of +After this, memory block XXX's state will be 'online' and the amount of available memory will be increased. Currently, newly added memory is added as ZONE_NORMAL (for powerpc, ZONE_DMA). @@ -284,22 +282,22 @@ This may be changed in future. 6.1 Memory offline and ZONE_MOVABLE ------------ Memory offlining is more complicated than memory online. Because memory offline -has to make the whole memory section be unused, memory offline can fail if -the section includes memory which cannot be freed. +has to make the whole memory block be unused, memory offline can fail if +the memory block includes memory which cannot be freed. In general, memory offline can use 2 techniques. -(1) reclaim and free all memory in the section. -(2) migrate all pages in the section. +(1) reclaim and free all memory in the memory block. +(2) migrate all pages in the memory block. In the current implementation, Linux's memory offline uses method (2), freeing -all pages in the section by page migration. But not all pages are +all pages in the memory block by page migration. But not all pages are migratable. Under current Linux, migratable pages are anonymous pages and -page caches. For offlining a section by migration, the kernel has to guarantee -that the section contains only migratable pages. +page caches. For offlining a memory block by migration, the kernel has to +guarantee that the memory block contains only migratable pages. -Now, a boot option for making a section which consists of migratable pages is -supported. By specifying "kernelcore=" or "movablecore=" boot option, you can +Now, a boot option for making a memory block which consists of migratable pages +is supported. By specifying "kernelcore=" or "movablecore=" boot option, you can create ZONE_MOVABLE...a zone which is just used for movable pages. (See also Documentation/kernel-parameters.txt) @@ -315,28 +313,27 @@ creates ZONE_MOVABLE as following. Size of memory for movable pages (for offline) is ZZZZ. -Note) Unfortunately, there is no information to show which section belongs +Note: Unfortunately, there is no information to show which memory block belongs to ZONE_MOVABLE. This is TBD. 6.2. How to offline memory ------------ -You can offline a section by using the same sysfs interface that was used in -memory onlining. +You can offline a memory block by using the same sysfs interface that was used +in memory onlining. % echo offline > /sys/devices/system/memory/memoryXXX/state -If offline succeeds, the state of the memory section is changed to be "offline". +If offline succeeds, the state of the memory block is changed to be "offline". If it fails, some error core (like -EBUSY) will be returned by the kernel. -Even if a section does not belong to ZONE_MOVABLE, you can try to offline it. -If it doesn't contain 'unmovable' memory, you'll get success. +Even if a memory block does not belong to ZONE_MOVABLE, you can try to offline +it. If it doesn't contain 'unmovable' memory, you'll get success. -A section under ZONE_MOVABLE is considered to be able to be offlined easily. -But under some busy state, it may return -EBUSY. Even if a memory section -cannot be offlined due to -EBUSY, you can retry offlining it and may be able to -offline it (or not). -(For example, a page is referred to by some kernel internal call and released - soon.) +A memory block under ZONE_MOVABLE is considered to be able to be offlined +easily. But under some busy state, it may return -EBUSY. Even if a memory +block cannot be offlined due to -EBUSY, you can retry offlining it and may be +able to offline it (or not). (For example, a page is referred to by some kernel +internal call and released soon.) Consideration: Memory hotplug's design direction is to make the possibility of memory offlining @@ -373,11 +370,11 @@ MEMORY_GOING_OFFLINE Generated to begin the process of offlining memory. Allocations are no longer possible from the memory but some of the memory to be offlined is still in use. The callback can be used to free memory known to a - subsystem from the indicated memory section. + subsystem from the indicated memory block. MEMORY_CANCEL_OFFLINE Generated if MEMORY_GOING_OFFLINE fails. Memory is available again from - the section that we attempted to offline. + the memory block that we attempted to offline. MEMORY_OFFLINE Generated after offlining memory is complete. @@ -413,8 +410,8 @@ node if necessary. -------------- - allowing memory hot-add to ZONE_MOVABLE. maybe we need some switch like sysctl or new control file. - - showing memory section and physical device relationship. - - showing memory section is under ZONE_MOVABLE or not + - showing memory block and physical device relationship. + - showing memory block is under ZONE_MOVABLE or not - test and make it better memory offlining. - support HugeTLB page migration and offlining. - memmap removing at memory offline. -- cgit v1.1 From 4f9b16a64753d0bb607454347036dc997fd03b82 Mon Sep 17 00:00:00 2001 From: Mel Gorman Date: Wed, 4 Jun 2014 16:07:14 -0700 Subject: mm: disable zone_reclaim_mode by default When it was introduced, zone_reclaim_mode made sense as NUMA distances punished and workloads were generally partitioned to fit into a NUMA node. NUMA machines are now common but few of the workloads are NUMA-aware and it's routine to see major performance degradation due to zone_reclaim_mode being enabled but relatively few can identify the problem. Those that require zone_reclaim_mode are likely to be able to detect when it needs to be enabled and tune appropriately so lets have a sensible default for the bulk of users. This patch (of 2): zone_reclaim_mode causes processes to prefer reclaiming memory from local node instead of spilling over to other nodes. This made sense initially when NUMA machines were almost exclusively HPC and the workload was partitioned into nodes. The NUMA penalties were sufficiently high to justify reclaiming the memory. On current machines and workloads it is often the case that zone_reclaim_mode destroys performance but not all users know how to detect this. Favour the common case and disable it by default. Users that are sophisticated enough to know they need zone_reclaim_mode will detect it. Signed-off-by: Mel Gorman Acked-by: Johannes Weiner Reviewed-by: Zhang Yanfei Acked-by: Michal Hocko Reviewed-by: Christoph Lameter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/sysctl/vm.txt | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index dd9d0e3..5b6da0f 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -772,16 +772,17 @@ This is value ORed together of 2 = Zone reclaim writes dirty pages out 4 = Zone reclaim swaps pages -zone_reclaim_mode is set during bootup to 1 if it is determined that pages -from remote zones will cause a measurable performance reduction. The -page allocator will then reclaim easily reusable pages (those page -cache pages that are currently not used) before allocating off node pages. - -It may be beneficial to switch off zone reclaim if the system is -used for a file server and all of memory should be used for caching files -from disk. In that case the caching effect is more important than +zone_reclaim_mode is disabled by default. For file servers or workloads +that benefit from having their data cached, zone_reclaim_mode should be +left disabled as the caching effect is likely to be more important than data locality. +zone_reclaim may be enabled if it's known that the workload is partitioned +such that each partition fits within a NUMA node and that accessing remote +memory would cause a measurable performance reduction. The page allocator +will then reclaim easily reusable pages (those page cache pages that are +currently not used) before allocating off node pages. + Allowing zone reclaim to write out pages stops processes that are writing large amounts of data from dirtying pages on other nodes. Zone reclaim will write out dirty pages if a zone fills up and so effectively -- cgit v1.1 From 2ee06468702e0742114823a537510cd6f038cacc Mon Sep 17 00:00:00 2001 From: Vladimir Davydov Date: Wed, 4 Jun 2014 16:07:28 -0700 Subject: Documentation/memcg: warn about incomplete kmemcg state Kmemcg is currently under development and lacks some important features. In particular, it does not have support of kmem reclaim on memory pressure inside cgroup, which practically makes it unusable in real life. Let's warn about it in both Kconfig and Documentation to prevent complaints arising. Signed-off-by: Vladimir Davydov Acked-by: Michal Hocko Cc: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/cgroups/memory.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index 1829c65..4937e6f 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt @@ -270,6 +270,11 @@ When oom event notifier is registered, event will be delivered. 2.7 Kernel Memory Extension (CONFIG_MEMCG_KMEM) +WARNING: Current implementation lacks reclaim support. That means allocation + attempts will fail when close to the limit even if there are plenty of + kmem available for reclaim. That makes this option unusable in real + life so DO NOT SELECT IT unless for development purposes. + With the Kernel memory extension, the Memory Controller is able to limit the amount of kernel memory used by the system. Kernel memory is fundamentally different than user memory, since it can't be swapped out, which makes it -- cgit v1.1 From 3ba08129e38437561df44c36b7ea9081185d5333 Mon Sep 17 00:00:00 2001 From: Naoya Horiguchi Date: Wed, 4 Jun 2014 16:11:02 -0700 Subject: mm/memory-failure.c: support use of a dedicated thread to handle SIGBUS(BUS_MCEERR_AO) Currently memory error handler handles action optional errors in the deferred manner by default. And if a recovery aware application wants to handle it immediately, it can do it by setting PF_MCE_EARLY flag. However, such signal can be sent only to the main thread, so it's problematic if the application wants to have a dedicated thread to handler such signals. So this patch adds dedicated thread support to memory error handler. We have PF_MCE_EARLY flags for each thread separately, so with this patch AO signal is sent to the thread with PF_MCE_EARLY flag set, not the main thread. If you want to implement a dedicated thread, you call prctl() to set PF_MCE_EARLY on the thread. Memory error handler collects processes to be killed, so this patch lets it check PF_MCE_EARLY flag on each thread in the collecting routines. No behavioral change for all non-early kill cases. Tony said: : The old behavior was crazy - someone with a multithreaded process might : well expect that if they call prctl(PF_MCE_EARLY) in just one thread, then : that thread would see the SIGBUS with si_code = BUS_MCEERR_A0 - even if : that thread wasn't the main thread for the process. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Naoya Horiguchi Reviewed-by: Tony Luck Cc: Kamil Iskra Cc: Andi Kleen Cc: Borislav Petkov Cc: Chen Gong Cc: [3.2+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/hwpoison.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/vm/hwpoison.txt b/Documentation/vm/hwpoison.txt index 5500684..6ae89a9 100644 --- a/Documentation/vm/hwpoison.txt +++ b/Documentation/vm/hwpoison.txt @@ -84,6 +84,11 @@ PR_MCE_KILL PR_MCE_KILL_EARLY: Early kill PR_MCE_KILL_LATE: Late kill PR_MCE_KILL_DEFAULT: Use system global default + Note that if you want to have a dedicated thread which handles + the SIGBUS(BUS_MCEERR_AO) on behalf of the process, you should + call prctl(PR_MCE_KILL_EARLY) on the designated thread. Otherwise, + the SIGBUS is sent to the main thread. + PR_MCE_KILL_GET return current mode -- cgit v1.1 From 4a0da71b96b9d4080c0820e9e7d02470ebe62dc6 Mon Sep 17 00:00:00 2001 From: Denys Vlasenko Date: Wed, 4 Jun 2014 16:11:03 -0700 Subject: Documentation/sysctl/vm.txt: clarify vfs_cache_pressure description Existing description is worded in a way which almost encourages setting of vfs_cache_pressure above 100, possibly way above it. Users are left in a dark what this numeric value is - an int? a percentage? what the scale is? As a result, we are getting reports about noticeable performance degradation from users who have set vfs_cache_pressure to ridiculously high values - because they thought there is no downside to it. Via code inspection it's obvious that this value is treated as a percentage. This patch changes text to reflect this fact, and adds a cautionary paragraph advising against setting vfs_cache_pressure sky high. Signed-off-by: Denys Vlasenko Cc: Alexander Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/sysctl/vm.txt | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index 5b6da0f..bd4b34c 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -746,8 +746,8 @@ Changing this takes effect whenever an application requests memory. vfs_cache_pressure ------------------ -Controls the tendency of the kernel to reclaim the memory which is used for -caching of directory and inode objects. +This percentage value controls the tendency of the kernel to reclaim +the memory which is used for caching of directory and inode objects. At the default value of vfs_cache_pressure=100 the kernel will attempt to reclaim dentries and inodes at a "fair" rate with respect to pagecache and @@ -757,6 +757,11 @@ never reclaim dentries and inodes due to memory pressure and this can easily lead to out-of-memory conditions. Increasing vfs_cache_pressure beyond 100 causes the kernel to prefer to reclaim dentries and inodes. +Increasing vfs_cache_pressure significantly beyond 100 may have negative +performance impact. Reclaim code needs to take various locks to find freeable +directory and inode objects. With vfs_cache_pressure=1000, it will look for +ten times more freeable objects than there are. + ============================================================== zone_reclaim_mode: -- cgit v1.1 From 6e099f557d9c6797c3ee3ee7b5c8cebe543ec1cc Mon Sep 17 00:00:00 2001 From: Dan Streetman Date: Wed, 4 Jun 2014 16:11:44 -0700 Subject: Documentation: expand/clarify debug documentation The pr_debug() and related debug print macros all differ from the normal pr_XXX() macros, in that the normal ones print unconditionally, while the debug macros are compiled out unless DEBUG is defined or CONFIG_DYNAMIC_DEBUG is set. This isn't obvious, and the only way to find this out is either to review the actual printk.h code or to read CodingStyle, and the message there doesn't highlight the fact. Change Documentation/CodingStyle to clearly indicate that pr_debug() and related debug printing macros behave differently than all other pr_XXX() macros, and attempt to clarify when and where the different debug printing methods might be used. Add short comment to printk.h above the pr_XXX() macros indicating that while these macros print unconditionally, pr_debug() does not. Signed-off-by: Dan Streetman Cc: Joe Perches Cc: Fabian Frederick Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/CodingStyle | 22 +++++++++++++++------- 1 file changed, 15 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 7fe0546..6b6bef3 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -660,15 +660,23 @@ There are a number of driver model diagnostic macros in which you should use to make sure messages are matched to the right device and driver, and are tagged with the right level: dev_err(), dev_warn(), dev_info(), and so forth. For messages that aren't associated with a -particular device, defines pr_debug() and pr_info(). +particular device, defines pr_notice(), pr_info(), +pr_warn(), pr_err(), etc. Coming up with good debugging messages can be quite a challenge; and once -you have them, they can be a huge help for remote troubleshooting. Such -messages should be compiled out when the DEBUG symbol is not defined (that -is, by default they are not included). When you use dev_dbg() or pr_debug(), -that's automatic. Many subsystems have Kconfig options to turn on -DDEBUG. -A related convention uses VERBOSE_DEBUG to add dev_vdbg() messages to the -ones already enabled by DEBUG. +you have them, they can be a huge help for remote troubleshooting. However +debug message printing is handled differently than printing other non-debug +messages. While the other pr_XXX() functions print unconditionally, +pr_debug() does not; it is compiled out by default, unless either DEBUG is +defined or CONFIG_DYNAMIC_DEBUG is set. That is true for dev_dbg() also, +and a related convention uses VERBOSE_DEBUG to add dev_vdbg() messages to +the ones already enabled by DEBUG. + +Many subsystems have Kconfig debug options to turn on -DDEBUG in the +corresponding Makefile; in other cases specific files #define DEBUG. And +when a debug message should be unconditionally printed, such as if it is +already inside a debug-related #ifdef secton, printk(KERN_DEBUG ...) can be +used. Chapter 14: Allocating memory -- cgit v1.1 From 7b0b73d76651e5f88c88b76efa18d719f832bf6f Mon Sep 17 00:00:00 2001 From: Prarit Bhargava Date: Wed, 4 Jun 2014 16:12:17 -0700 Subject: init/main.c: add initcall_blacklist kernel parameter When a module is built into the kernel the module_init() function becomes an initcall. Sometimes debugging through dynamic debug can help, however, debugging built in kernel modules is typically done by changing the .config, recompiling, and booting the new kernel in an effort to determine exactly which module caused a problem. This patchset can be useful stand-alone or combined with initcall_debug. There are cases where some initcalls can hang the machine before the console can be flushed, which can make initcall_debug output inaccurate. Having the ability to skip initcalls can help further debugging of these scenarios. Usage: initcall_blacklist= ex) added "initcall_blacklist=sgi_uv_sysfs_init" as a kernel parameter and the log contains: blacklisting initcall sgi_uv_sysfs_init ... ... initcall sgi_uv_sysfs_init blacklisted ex) added "initcall_blacklist=foo_bar,sgi_uv_sysfs_init" as a kernel parameter and the log contains: blacklisting initcall foo_bar blacklisting initcall sgi_uv_sysfs_init ... ... initcall sgi_uv_sysfs_init blacklisted [akpm@linux-foundation.org: tweak printk text] Signed-off-by: Prarit Bhargava Cc: Richard Weinberger Cc: Andi Kleen Cc: Josh Boyer Cc: Rob Landley Cc: Steven Rostedt Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Frederic Weisbecker Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/kernel-parameters.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index adea3a2..9973a7e 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1312,6 +1312,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. for working out where the kernel is dying during startup. + initcall_blacklist= [KNL] Do not execute a comma-separated list of + initcall functions. Useful for debugging built-in + modules and initcalls. + initrd= [BOOT] Specify the location of the initial ramdisk inport.irq= [HW] Inport (ATI XL and Microsoft) busmouse driver -- cgit v1.1 From 51fd371bbaf94018a1223b4e2cf20b9880fd92d4 Mon Sep 17 00:00:00 2001 From: Rob Clark Date: Tue, 19 Nov 2013 12:10:12 -0500 Subject: drm: convert crtc and connection_mutex to ww_mutex (v5) For atomic, it will be quite necessary to not need to care so much about locking order. And 'state' gives us a convenient place to stash a ww_ctx for any sort of update that needs to grab multiple crtc locks. Because we will want to eventually make locking even more fine grained (giving locks to planes, connectors, etc), split out drm_modeset_lock and drm_modeset_acquire_ctx to track acquired locks. Atomic will use this to keep track of which locks have been acquired in a transaction. v1: original v2: remove a few things not needed until atomic, for now v3: update for v3 of connection_mutex patch.. v4: squash in docbook v5: doc tweaks/fixes Signed-off-by: Rob Clark Reviewed-by: Daniel Vetter Signed-off-by: Dave Airlie --- Documentation/DocBook/drm.tmpl | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 00f1c25..efef637 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -1791,6 +1791,12 @@ void intel_crt_init(struct drm_device *dev) KMS API Functions !Edrivers/gpu/drm/drm_crtc.c + + KMS Locking +!Pdrivers/gpu/drm/drm_modeset_lock.c kms locking +!Iinclude/drm/drm_modeset_lock.h +!Edrivers/gpu/drm/drm_modeset_lock.c + -- cgit v1.1 From 91a6151be2a936e87ce422fcd9262377ad9ed91c Mon Sep 17 00:00:00 2001 From: Michael Ellerman Date: Mon, 26 May 2014 21:44:25 +1000 Subject: powerpc: Add cpu family documentation This patch adds some documentation on the different cpu families supported by arch/powerpc. Signed-off-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt --- Documentation/powerpc/cpu_families.txt | 221 +++++++++++++++++++++++++++++++++ 1 file changed, 221 insertions(+) create mode 100644 Documentation/powerpc/cpu_families.txt (limited to 'Documentation') diff --git a/Documentation/powerpc/cpu_families.txt b/Documentation/powerpc/cpu_families.txt new file mode 100644 index 0000000..fc08e22 --- /dev/null +++ b/Documentation/powerpc/cpu_families.txt @@ -0,0 +1,221 @@ +CPU Families +============ + +This document tries to summarise some of the different cpu families that exist +and are supported by arch/powerpc. + + +Book3S (aka sPAPR) +------------------ + + - Hash MMU + - Mix of 32 & 64 bit + + +--------------+ +----------------+ + | Old POWER | --------------> | RS64 (threads) | + +--------------+ +----------------+ + | + | + v + +--------------+ +----------------+ +------+ + | 601 | --------------> | 603 | ---> | e300 | + +--------------+ +----------------+ +------+ + | | + | | + v v + +--------------+ +----------------+ +-------+ + | 604 | | 750 (G3) | ---> | 750CX | + +--------------+ +----------------+ +-------+ + | | | + | | | + v v v + +--------------+ +----------------+ +-------+ + | 620 (64 bit) | | 7400 | | 750CL | + +--------------+ +----------------+ +-------+ + | | | + | | | + v v v + +--------------+ +----------------+ +-------+ + | POWER3/630 | | 7410 | | 750FX | + +--------------+ +----------------+ +-------+ + | | + | | + v v + +--------------+ +----------------+ + | POWER3+ | | 7450 | + +--------------+ +----------------+ + | | + | | + v v + +--------------+ +----------------+ + | POWER4 | | 7455 | + +--------------+ +----------------+ + | | + | | + v v + +--------------+ +-------+ +----------------+ + | POWER4+ | --> | 970 | | 7447 | + +--------------+ +-------+ +----------------+ + | | | + | | | + v v v + +--------------+ +-------+ +----------------+ + | POWER5 | | 970FX | | 7448 | + +--------------+ +-------+ +----------------+ + | | | + | | | + v v v + +--------------+ +-------+ +----------------+ + | POWER5+ | | 970MP | | e600 | + +--------------+ +-------+ +----------------+ + | + | + v + +--------------+ + | POWER5++ | + +--------------+ + | + | + v + +--------------+ +-------+ + | POWER6 | <-?-> | Cell | + +--------------+ +-------+ + | + | + v + +--------------+ + | POWER7 | + +--------------+ + | + | + v + +--------------+ + | POWER7+ | + +--------------+ + | + | + v + +--------------+ + | POWER8 | + +--------------+ + + + +---------------+ + | PA6T (64 bit) | + +---------------+ + + +IBM BookE +--------- + + - Software loaded TLB. + - All 32 bit + + +--------------+ + | 401 | + +--------------+ + | + | + v + +--------------+ + | 403 | + +--------------+ + | + | + v + +--------------+ + | 405 | + +--------------+ + | + | + v + +--------------+ + | 440 | + +--------------+ + | + | + v + +--------------+ +----------------+ + | 450 | --> | BG/P | + +--------------+ +----------------+ + | + | + v + +--------------+ + | 460 | + +--------------+ + | + | + v + +--------------+ + | 476 | + +--------------+ + + +Motorola/Freescale 8xx +---------------------- + + - Software loaded with hardware assist. + - All 32 bit + + +-------------+ + | MPC8xx Core | + +-------------+ + + +Freescale BookE +--------------- + + - Software loaded TLB. + - e6500 adds HW loaded indirect TLB entries. + - Mix of 32 & 64 bit + + +--------------+ + | e200 | + +--------------+ + + + +--------------------------------+ + | e500 | + +--------------------------------+ + | + | + v + +--------------------------------+ + | e500v2 | + +--------------------------------+ + | + | + v + +--------------------------------+ + | e500mc (Book3e) | + +--------------------------------+ + | + | + v + +--------------------------------+ + | e5500 (64 bit) | + +--------------------------------+ + | + | + v + +--------------------------------+ + | e6500 (HW TLB) (Multithreaded) | + +--------------------------------+ + + +IBM A2 core +----------- + + - Book3E, software loaded TLB + HW loaded indirect TLB entries. + - 64 bit + + +--------------+ +----------------+ + | A2 core | --> | WSP | + +--------------+ +----------------+ + | + | + v + +--------------+ + | BG/Q | + +--------------+ -- cgit v1.1 From 9161f5409798d52aa8598ff12575fde2327bed84 Mon Sep 17 00:00:00 2001 From: Davidlohr Bueso Date: Wed, 28 May 2014 21:36:43 -0700 Subject: locking/mutexes: Documentation update/rewrite Our mutexes have gone a long ways since the original implementation back in 2005/2006. However, the mutex-design.txt document is still stuck in the past, to the point where most of the information there is practically useless and, more important, simply incorrect. This patch pretty much rewrites it to resemble what we have nowadays. Since regular semaphores are almost much extinct in the kernel (most users now rely on mutexes or rwsems), it no longer makes sense to have such a close comparison, which was copied from most of the cover letter when Ingo introduced the generic mutex subsystem. Note that ww_mutexes are intentionally left out, leaving things as generic as possible. Signed-off-by: Davidlohr Bueso Cc: tim.c.chen@linux.intel.com Cc: paulmck@linux.vnet.ibm.com Cc: waiman.long@hp.com Cc: jason.low2@hp.com Cc: aswin@hp.com Cc: Linus Torvalds Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1401338203.2618.11.camel@buesod1.americas.hpqcorp.net Signed-off-by: Ingo Molnar --- Documentation/mutex-design.txt | 252 ++++++++++++++++++++++------------------- 1 file changed, 135 insertions(+), 117 deletions(-) (limited to 'Documentation') diff --git a/Documentation/mutex-design.txt b/Documentation/mutex-design.txt index 1dfe62c..ee231ed 100644 --- a/Documentation/mutex-design.txt +++ b/Documentation/mutex-design.txt @@ -1,139 +1,157 @@ Generic Mutex Subsystem started by Ingo Molnar +updated by Davidlohr Bueso - "Why on earth do we need a new mutex subsystem, and what's wrong - with semaphores?" +What are mutexes? +----------------- -firstly, there's nothing wrong with semaphores. But if the simpler -mutex semantics are sufficient for your code, then there are a couple -of advantages of mutexes: +In the Linux kernel, mutexes refer to a particular locking primitive +that enforces serialization on shared memory systems, and not only to +the generic term referring to 'mutual exclusion' found in academia +or similar theoretical text books. Mutexes are sleeping locks which +behave similarly to binary semaphores, and were introduced in 2006[1] +as an alternative to these. This new data structure provided a number +of advantages, including simpler interfaces, and at that time smaller +code (see Disadvantages). - - 'struct mutex' is smaller on most architectures: E.g. on x86, - 'struct semaphore' is 20 bytes, 'struct mutex' is 16 bytes. - A smaller structure size means less RAM footprint, and better - CPU-cache utilization. +[1] http://lwn.net/Articles/164802/ - - tighter code. On x86 i get the following .text sizes when - switching all mutex-alike semaphores in the kernel to the mutex - subsystem: +Implementation +-------------- - text data bss dec hex filename - 3280380 868188 396860 4545428 455b94 vmlinux-semaphore - 3255329 865296 396732 4517357 44eded vmlinux-mutex +Mutexes are represented by 'struct mutex', defined in include/linux/mutex.h +and implemented in kernel/locking/mutex.c. These locks use a three +state atomic counter (->count) to represent the different possible +transitions that can occur during the lifetime of a lock: - that's 25051 bytes of code saved, or a 0.76% win - off the hottest - codepaths of the kernel. (The .data savings are 2892 bytes, or 0.33%) - Smaller code means better icache footprint, which is one of the - major optimization goals in the Linux kernel currently. + 1: unlocked + 0: locked, no waiters + negative: locked, with potential waiters - - the mutex subsystem is slightly faster and has better scalability for - contended workloads. On an 8-way x86 system, running a mutex-based - kernel and testing creat+unlink+close (of separate, per-task files) - in /tmp with 16 parallel tasks, the average number of ops/sec is: +In its most basic form it also includes a wait-queue and a spinlock +that serializes access to it. CONFIG_SMP systems can also include +a pointer to the lock task owner (->owner) as well as a spinner MCS +lock (->osq), both described below in (ii). - Semaphores: Mutexes: +When acquiring a mutex, there are three possible paths that can be +taken, depending on the state of the lock: - $ ./test-mutex V 16 10 $ ./test-mutex V 16 10 - 8 CPUs, running 16 tasks. 8 CPUs, running 16 tasks. - checking VFS performance. checking VFS performance. - avg loops/sec: 34713 avg loops/sec: 84153 - CPU utilization: 63% CPU utilization: 22% +(i) fastpath: tries to atomically acquire the lock by decrementing the + counter. If it was already taken by another task it goes to the next + possible path. This logic is architecture specific. On x86-64, the + locking fastpath is 2 instructions: - i.e. in this workload, the mutex based kernel was 2.4 times faster - than the semaphore based kernel, _and_ it also had 2.8 times less CPU - utilization. (In terms of 'ops per CPU cycle', the semaphore kernel - performed 551 ops/sec per 1% of CPU time used, while the mutex kernel - performed 3825 ops/sec per 1% of CPU time used - it was 6.9 times - more efficient.) - - the scalability difference is visible even on a 2-way P4 HT box: - - Semaphores: Mutexes: - - $ ./test-mutex V 16 10 $ ./test-mutex V 16 10 - 4 CPUs, running 16 tasks. 8 CPUs, running 16 tasks. - checking VFS performance. checking VFS performance. - avg loops/sec: 127659 avg loops/sec: 181082 - CPU utilization: 100% CPU utilization: 34% - - (the straight performance advantage of mutexes is 41%, the per-cycle - efficiency of mutexes is 4.1 times better.) - - - there are no fastpath tradeoffs, the mutex fastpath is just as tight - as the semaphore fastpath. On x86, the locking fastpath is 2 - instructions: - - c0377ccb : - c0377ccb: f0 ff 08 lock decl (%eax) - c0377cce: 78 0e js c0377cde <.text..lock.mutex> - c0377cd0: c3 ret + 0000000000000e10 : + e21: f0 ff 0b lock decl (%rbx) + e24: 79 08 jns e2e the unlocking fastpath is equally tight: - c0377cd1 : - c0377cd1: f0 ff 00 lock incl (%eax) - c0377cd4: 7e 0f jle c0377ce5 <.text..lock.mutex+0x7> - c0377cd6: c3 ret - - - 'struct mutex' semantics are well-defined and are enforced if - CONFIG_DEBUG_MUTEXES is turned on. Semaphores on the other hand have - virtually no debugging code or instrumentation. The mutex subsystem - checks and enforces the following rules: - - * - only one task can hold the mutex at a time - * - only the owner can unlock the mutex - * - multiple unlocks are not permitted - * - recursive locking is not permitted - * - a mutex object must be initialized via the API - * - a mutex object must not be initialized via memset or copying - * - task may not exit with mutex held - * - memory areas where held locks reside must not be freed - * - held mutexes must not be reinitialized - * - mutexes may not be used in hardware or software interrupt - * contexts such as tasklets and timers - - furthermore, there are also convenience features in the debugging - code: - - * - uses symbolic names of mutexes, whenever they are printed in debug output - * - point-of-acquire tracking, symbolic lookup of function names - * - list of all locks held in the system, printout of them - * - owner tracking - * - detects self-recursing locks and prints out all relevant info - * - detects multi-task circular deadlocks and prints out all affected - * locks and tasks (and only those tasks) + 0000000000000bc0 : + bc8: f0 ff 07 lock incl (%rdi) + bcb: 7f 0a jg bd7 + + +(ii) midpath: aka optimistic spinning, tries to spin for acquisition + while the lock owner is running and there are no other tasks ready + to run that have higher priority (need_resched). The rationale is + that if the lock owner is running, it is likely to release the lock + soon. The mutex spinners are queued up using MCS lock so that only + one spinner can compete for the mutex. + + The MCS lock (proposed by Mellor-Crummey and Scott) is a simple spinlock + with the desirable properties of being fair and with each cpu trying + to acquire the lock spinning on a local variable. It avoids expensive + cacheline bouncing that common test-and-set spinlock implementations + incur. An MCS-like lock is specially tailored for optimistic spinning + for sleeping lock implementation. An important feature of the customized + MCS lock is that it has the extra property that spinners are able to exit + the MCS spinlock queue when they need to reschedule. This further helps + avoid situations where MCS spinners that need to reschedule would continue + waiting to spin on mutex owner, only to go directly to slowpath upon + obtaining the MCS lock. + + +(iii) slowpath: last resort, if the lock is still unable to be acquired, + the task is added to the wait-queue and sleeps until woken up by the + unlock path. Under normal circumstances it blocks as TASK_UNINTERRUPTIBLE. + +While formally kernel mutexes are sleepable locks, it is path (ii) that +makes them more practically a hybrid type. By simply not interrupting a +task and busy-waiting for a few cycles instead of immediately sleeping, +the performance of this lock has been seen to significantly improve a +number of workloads. Note that this technique is also used for rw-semaphores. + +Semantics +--------- + +The mutex subsystem checks and enforces the following rules: + + - Only one task can hold the mutex at a time. + - Only the owner can unlock the mutex. + - Multiple unlocks are not permitted. + - Recursive locking/unlocking is not permitted. + - A mutex must only be initialized via the API (see below). + - A task may not exit with a mutex held. + - Memory areas where held locks reside must not be freed. + - Held mutexes must not be reinitialized. + - Mutexes may not be used in hardware or software interrupt + contexts such as tasklets and timers. + +These semantics are fully enforced when CONFIG DEBUG_MUTEXES is enabled. +In addition, the mutex debugging code also implements a number of other +features that make lock debugging easier and faster: + + - Uses symbolic names of mutexes, whenever they are printed + in debug output. + - Point-of-acquire tracking, symbolic lookup of function names, + list of all locks held in the system, printout of them. + - Owner tracking. + - Detects self-recursing locks and prints out all relevant info. + - Detects multi-task circular deadlocks and prints out all affected + locks and tasks (and only those tasks). + + +Interfaces +---------- +Statically define the mutex: + DEFINE_MUTEX(name); + +Dynamically initialize the mutex: + mutex_init(mutex); + +Acquire the mutex, uninterruptible: + void mutex_lock(struct mutex *lock); + void mutex_lock_nested(struct mutex *lock, unsigned int subclass); + int mutex_trylock(struct mutex *lock); + +Acquire the mutex, interruptible: + int mutex_lock_interruptible_nested(struct mutex *lock, + unsigned int subclass); + int mutex_lock_interruptible(struct mutex *lock); + +Acquire the mutex, interruptible, if dec to 0: + int atomic_dec_and_mutex_lock(atomic_t *cnt, struct mutex *lock); + +Unlock the mutex: + void mutex_unlock(struct mutex *lock); + +Test if the mutex is taken: + int mutex_is_locked(struct mutex *lock); Disadvantages ------------- -The stricter mutex API means you cannot use mutexes the same way you -can use semaphores: e.g. they cannot be used from an interrupt context, -nor can they be unlocked from a different context that which acquired -it. [ I'm not aware of any other (e.g. performance) disadvantages from -using mutexes at the moment, please let me know if you find any. ] - -Implementation of mutexes -------------------------- - -'struct mutex' is the new mutex type, defined in include/linux/mutex.h and -implemented in kernel/locking/mutex.c. It is a counter-based mutex with a -spinlock and a wait-list. The counter has 3 states: 1 for "unlocked", 0 for -"locked" and negative numbers (usually -1) for "locked, potential waiters -queued". - -the APIs of 'struct mutex' have been streamlined: - - DEFINE_MUTEX(name); +Unlike its original design and purpose, 'struct mutex' is larger than +most locks in the kernel. E.g: on x86-64 it is 40 bytes, almost twice +as large as 'struct semaphore' (24 bytes) and 8 bytes shy of the +'struct rw_semaphore' variant. Larger structure sizes mean more CPU +cache and memory footprint. - mutex_init(mutex); +When to use mutexes +------------------- - void mutex_lock(struct mutex *lock); - int mutex_lock_interruptible(struct mutex *lock); - int mutex_trylock(struct mutex *lock); - void mutex_unlock(struct mutex *lock); - int mutex_is_locked(struct mutex *lock); - void mutex_lock_nested(struct mutex *lock, unsigned int subclass); - int mutex_lock_interruptible_nested(struct mutex *lock, - unsigned int subclass); - int atomic_dec_and_mutex_lock(atomic_t *cnt, struct mutex *lock); +Unless the strict semantics of mutexes are unsuitable and/or the critical +region prevents the lock from being shared, always prefer them to any other +locking primitive. -- cgit v1.1 From fff5de45ef82f12918d6558a07cdf27cdce7e3d9 Mon Sep 17 00:00:00 2001 From: Philipp Zabel Date: Thu, 15 May 2014 12:25:47 +0200 Subject: drm/panel: Add support for EDT ETM0700G0DH6 and ET070080DH6 panels The EDT ETM0700G0DH6 and ET070080DH6 are 7" 800x480 panels, which can be supported by the simple panel driver. Signed-off-by: Philipp Zabel Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/panel/edt,et070080dh6.txt | 10 ++++++++++ Documentation/devicetree/bindings/panel/edt,etm0700g0dh6.txt | 10 ++++++++++ 2 files changed, 20 insertions(+) create mode 100644 Documentation/devicetree/bindings/panel/edt,et070080dh6.txt create mode 100644 Documentation/devicetree/bindings/panel/edt,etm0700g0dh6.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/panel/edt,et070080dh6.txt b/Documentation/devicetree/bindings/panel/edt,et070080dh6.txt new file mode 100644 index 0000000..20cb38e --- /dev/null +++ b/Documentation/devicetree/bindings/panel/edt,et070080dh6.txt @@ -0,0 +1,10 @@ +Emerging Display Technology Corp. ET070080DH6 7.0" WVGA TFT LCD panel + +Required properties: +- compatible: should be "edt,et070080dh6" + +This panel is the same as ETM0700G0DH6 except for the touchscreen. +ET070080DH6 is the model with resistive touch. + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/edt,etm0700g0dh6.txt b/Documentation/devicetree/bindings/panel/edt,etm0700g0dh6.txt new file mode 100644 index 0000000..ee4b180 --- /dev/null +++ b/Documentation/devicetree/bindings/panel/edt,etm0700g0dh6.txt @@ -0,0 +1,10 @@ +Emerging Display Technology Corp. ETM0700G0DH6 7.0" WVGA TFT LCD panel + +Required properties: +- compatible: should be "edt,etm0700g0dh6" + +This panel is the same as ET070080DH6 except for the touchscreen. +ETM0700G0DH6 is the model with capacitive multitouch. + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- cgit v1.1 From 26ab0065794de0317776e97e58364ac30b33f6b2 Mon Sep 17 00:00:00 2001 From: Stefan Agner Date: Thu, 15 May 2014 11:38:45 +0200 Subject: drm/panel: add support for EDT ET057090DHU panel This panel is sold by Toradex for Colibri T20/T30 and Apalis T30 evaluation kits. Signed-off-by: Stefan Agner Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/panel/edt,et057090dhu.txt | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/devicetree/bindings/panel/edt,et057090dhu.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/panel/edt,et057090dhu.txt b/Documentation/devicetree/bindings/panel/edt,et057090dhu.txt new file mode 100644 index 0000000..4903d7b --- /dev/null +++ b/Documentation/devicetree/bindings/panel/edt,et057090dhu.txt @@ -0,0 +1,7 @@ +Emerging Display Technology Corp. 5.7" VGA TFT LCD panel + +Required properties: +- compatible: should be "edt,et057090dhu" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- cgit v1.1 From fb50a116bbbc25c7c11e00e6d10a53b9ec3c38e8 Mon Sep 17 00:00:00 2001 From: Thierry Reding Date: Fri, 28 Feb 2014 16:57:34 +0100 Subject: drm/tegra: hdmi - Add connector supply support Revert commit 18ebc0f404d5 "drm/tegra: hdmi: Enable VDD earlier for hotplug/DDC" and instead add a new supply for the +5V pin on the HDMI connector. The vdd-supply property refers to the regulator that supplies the AVDD_HDMI input on Tegra, rather than the +5V HDMI connector pin. This was never a problem before, because all boards had that pin hooked up to a regulator that was always on. Starting with Dalmore and continuing with Venice2, the +5V pin is controllable via a GPIO. For reasons unknown, the GPIO ended up as the controlling GPIO of the AVDD_HDMI supply in the Dalmore and Venice2 DTS files. But that's not correct. Instead, a separate supply must be introduced so that the +5V pin can be controlled separately from the supplies that feed the HDMI block within Tegra. A new hdmi-supply property is introduced that takes the place of the vdd-supply and vdd-supply is only enabled when HDMI is enabled rather than all the time. Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt index efa8b84..f13a6b8 100644 --- a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt +++ b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt @@ -136,6 +136,7 @@ of the following host1x client modules: - compatible: "nvidia,tegra-hdmi" - reg: Physical base address and length of the controller's registers. - interrupts: The interrupt outputs from the controller. + - hdmi-supply: supply for the +5V HDMI connector pin - vdd-supply: regulator for supply voltage - pll-supply: regulator for PLL - clocks: Must contain an entry for each entry in clock-names. -- cgit v1.1 From 3b077afb3a7d84bffbf6598697a17655933671d2 Mon Sep 17 00:00:00 2001 From: Thierry Reding Date: Fri, 14 Mar 2014 14:07:50 +0100 Subject: drm/tegra: dsi - Implement VDD supply support The DSI controllers are powered by a (typically 1.2V) regulator. Usually this is always on, so there was no need to support enabling or disabling it thus far. But in order not to consume any power when DSI is inactive, give the driver a chance to enable or disable the supply as needed. Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt index f13a6b8..b48f4ef 100644 --- a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt +++ b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt @@ -181,6 +181,7 @@ of the following host1x client modules: See ../reset/reset.txt for details. - reset-names: Must include the following entries: - dsi + - avdd-dsi-supply: phandle of a supply that powers the DSI controller - nvidia,mipi-calibrate: Should contain a phandle and a specifier specifying which pads are used by this DSI output and need to be calibrated. See also ../mipi/nvidia,tegra114-mipi.txt. -- cgit v1.1 From c6a1af8a1621913e2658eaff419bab7028b2c42c Mon Sep 17 00:00:00 2001 From: Thierry Reding Date: Mon, 19 May 2014 13:39:07 +0200 Subject: drm: Add device registration documentation Describe how devices are registered using the drm_*_init() functions. Adding this to docbook requires a largish set of changes to the comments in drm_{pci,usb,platform}.c since they are doxygen-style rather than proper kernel-doc and therefore mess with the docbook generation. While at it, mark usage of drm_put_dev() as discouraged in favour of calling drm_dev_unregister() and drm_dev_unref() directly. Acked-by: Daniel Vetter Signed-off-by: Thierry Reding --- Documentation/DocBook/drm.tmpl | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index efef637..ba09b6f 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -282,6 +282,16 @@ char *date; + Device Registration + + A number of functions are provided to help with device registration. + The functions deal with PCI, USB and platform devices, respectively. + +!Edrivers/gpu/drm/drm_pci.c +!Edrivers/gpu/drm/drm_usb.c +!Edrivers/gpu/drm/drm_platform.c + + Driver Load The load method is the driver and device -- cgit v1.1 From b528ae7190867cd079bae5d6cf48c17d673428ae Mon Sep 17 00:00:00 2001 From: Thierry Reding Date: Wed, 23 Apr 2014 11:52:10 +0200 Subject: drm: Document how to register devices without struct drm_bus With the recent addition of the drm_set_unique() function, devices can now be registered without requiring a drm_bus. Add a brief description to the DRM docbook to show how that can be achieved. Reviewed-by: Daniel Vetter Signed-off-by: Thierry Reding --- Documentation/DocBook/drm.tmpl | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index ba09b6f..d95027f 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -142,6 +142,12 @@ to register it with the DRM subsystem. + Newer drivers that no longer require a drm_bus + structure can alternatively use the low-level device initialization and + registration functions such as drm_dev_alloc() and + drm_dev_register() directly. + + The drm_driver structure contains static information that describes the driver and features it supports, and pointers to methods that the DRM core will call to implement the DRM API. @@ -290,6 +296,26 @@ char *date; !Edrivers/gpu/drm/drm_pci.c !Edrivers/gpu/drm/drm_usb.c !Edrivers/gpu/drm/drm_platform.c + + New drivers that no longer rely on the services provided by the + drm_bus structure can call the low-level + device registration functions directly. The + drm_dev_alloc() function can be used to allocate + and initialize a new drm_device structure. + Drivers will typically want to perform some additional setup on this + structure, such as allocating driver-specific data and storing a + pointer to it in the DRM device's dev_private + field. Drivers should also set the device's unique name using the + drm_dev_set_unique() function. After it has been + set up a device can be registered with the DRM subsystem by calling + drm_dev_register(). This will cause the device to + be exposed to userspace and will call the driver's + .load() implementation. When a device is + removed, the DRM device can safely be unregistered and freed by calling + drm_dev_unregister() followed by a call to + drm_dev_unref(). + +!Edrivers/gpu/drm/drm_stub.c Driver Load -- cgit v1.1 From 1c03a2d04d7ab6d27c1fef8614f08187d974bd21 Mon Sep 17 00:00:00 2001 From: Viresh Kumar Date: Mon, 2 Jun 2014 22:49:28 +0530 Subject: cpufreq: add support for intermediate (stable) frequencies Douglas Anderson, recently pointed out an interesting problem due to which udelay() was expiring earlier than it should. While transitioning between frequencies few platforms may temporarily switch to a stable frequency, waiting for the main PLL to stabilize. For example: When we transition between very low frequencies on exynos, like between 200MHz and 300MHz, we may temporarily switch to a PLL running at 800MHz. No CPUFREQ notification is sent for that. That means there's a period of time when we're running at 800MHz but loops_per_jiffy is calibrated at between 200MHz and 300MHz. And so udelay behaves badly. To get this fixed in a generic way, introduce another set of callbacks get_intermediate() and target_intermediate(), only for drivers with target_index() and CPUFREQ_ASYNC_NOTIFICATION unset. get_intermediate() should return a stable intermediate frequency platform wants to switch to, and target_intermediate() should set CPU to that frequency, before jumping to the frequency corresponding to 'index'. Core will take care of sending notifications and driver doesn't have to handle them in target_intermediate() or target_index(). NOTE: ->target_index() should restore to policy->restore_freq in case of failures as core would send notifications for that. Tested-by: Stephen Warren Signed-off-by: Viresh Kumar Reviewed-by: Doug Anderson Signed-off-by: Rafael J. Wysocki --- Documentation/cpu-freq/cpu-drivers.txt | 29 +++++++++++++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cpu-freq/cpu-drivers.txt b/Documentation/cpu-freq/cpu-drivers.txt index b045fe5..14f4e63 100644 --- a/Documentation/cpu-freq/cpu-drivers.txt +++ b/Documentation/cpu-freq/cpu-drivers.txt @@ -26,6 +26,7 @@ Contents: 1.4 target/target_index or setpolicy? 1.5 target/target_index 1.6 setpolicy +1.7 get_intermediate and target_intermediate 2. Frequency Table Helpers @@ -79,6 +80,10 @@ cpufreq_driver.attr - A pointer to a NULL-terminated list of "struct freq_attr" which allow to export values to sysfs. +cpufreq_driver.get_intermediate +and target_intermediate Used to switch to stable frequency while + changing CPU frequency. + 1.2 Per-CPU Initialization -------------------------- @@ -151,7 +156,7 @@ Some cpufreq-capable processors switch the frequency between certain limits on their own. These shall use the ->setpolicy call -1.4. target/target_index +1.5. target/target_index ------------- The target_index call has two arguments: struct cpufreq_policy *policy, @@ -160,6 +165,9 @@ and unsigned int index (into the exposed frequency table). The CPUfreq driver must set the new frequency when called here. The actual frequency must be determined by freq_table[index].frequency. +It should always restore to earlier frequency (i.e. policy->restore_freq) in +case of errors, even if we switched to intermediate frequency earlier. + Deprecated: ---------- The target call has three arguments: struct cpufreq_policy *policy, @@ -179,7 +187,7 @@ Here again the frequency table helper might assist you - see section 2 for details. -1.5 setpolicy +1.6 setpolicy --------------- The setpolicy call only takes a struct cpufreq_policy *policy as @@ -190,6 +198,23 @@ setting when policy->policy is CPUFREQ_POLICY_PERFORMANCE, and a powersaving-oriented setting when CPUFREQ_POLICY_POWERSAVE. Also check the reference implementation in drivers/cpufreq/longrun.c +1.7 get_intermediate and target_intermediate +-------------------------------------------- + +Only for drivers with target_index() and CPUFREQ_ASYNC_NOTIFICATION unset. + +get_intermediate should return a stable intermediate frequency platform wants to +switch to, and target_intermediate() should set CPU to to that frequency, before +jumping to the frequency corresponding to 'index'. Core will take care of +sending notifications and driver doesn't have to handle them in +target_intermediate() or target_index(). + +Drivers can return '0' from get_intermediate() in case they don't wish to switch +to intermediate frequency for some target frequency. In that case core will +directly call ->target_index(). + +NOTE: ->target_index() should restore to policy->restore_freq in case of +failures as core would send notifications for that. 2. Frequency Table Helpers -- cgit v1.1 From 7c123b6a1c5ce1d7900b4ef7bab5f0491e4f674e Mon Sep 17 00:00:00 2001 From: "Lendacky, Thomas" Date: Thu, 5 Jun 2014 09:15:00 -0500 Subject: amd-xgbe: AMD 10GbE device bindings documentation This patch provides the documentation of the device bindings for the AMD 10GbE platform driver. Signed-off-by: Tom Lendacky Signed-off-by: David S. Miller --- .../devicetree/bindings/net/amd-xgbe-phy.txt | 17 +++++++++++ Documentation/devicetree/bindings/net/amd-xgbe.txt | 34 ++++++++++++++++++++++ 2 files changed, 51 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/amd-xgbe-phy.txt create mode 100644 Documentation/devicetree/bindings/net/amd-xgbe.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/amd-xgbe-phy.txt b/Documentation/devicetree/bindings/net/amd-xgbe-phy.txt new file mode 100644 index 0000000..d01ed63 --- /dev/null +++ b/Documentation/devicetree/bindings/net/amd-xgbe-phy.txt @@ -0,0 +1,17 @@ +* AMD 10GbE PHY driver (amd-xgbe-phy) + +Required properties: +- compatible: Should be "amd,xgbe-phy-seattle-v1a" and + "ethernet-phy-ieee802.3-c45" +- reg: Address and length of the register sets for the device + - SerDes Rx/Tx registers + - SerDes integration registers (1/2) + - SerDes integration registers (2/2) + +Example: + xgbe_phy@e1240800 { + compatible = "amd,xgbe-phy-seattle-v1a", "ethernet-phy-ieee802.3-c45"; + reg = <0 0xe1240800 0 0x00400>, + <0 0xe1250000 0 0x00060>, + <0 0xe1250080 0 0x00004>; + }; diff --git a/Documentation/devicetree/bindings/net/amd-xgbe.txt b/Documentation/devicetree/bindings/net/amd-xgbe.txt new file mode 100644 index 0000000..ea0c790 --- /dev/null +++ b/Documentation/devicetree/bindings/net/amd-xgbe.txt @@ -0,0 +1,34 @@ +* AMD 10GbE driver (amd-xgbe) + +Required properties: +- compatible: Should be "amd,xgbe-seattle-v1a" +- reg: Address and length of the register sets for the device + - MAC registers + - PCS registers +- interrupt-parent: Should be the phandle for the interrupt controller + that services interrupts for this device +- interrupts: Should contain the amd-xgbe interrupt +- clocks: Should be the DMA clock for the amd-xgbe device (used for + calculating the correct Rx interrupt watchdog timer value on a DMA + channel for coalescing) +- clock-names: Should be the name of the DMA clock, "dma_clk" +- phy-handle: See ethernet.txt file in the same directory +- phy-mode: See ethernet.txt file in the same directory + +Optional properties: +- mac-address: mac address to be assigned to the device. Can be overridden + by UEFI. + +Example: + xgbe@e0700000 { + compatible = "amd,xgbe-seattle-v1a"; + reg = <0 0xe0700000 0 0x80000>, + <0 0xe0780000 0 0x80000>; + interrupt-parent = <&gic>; + interrupts = <0 325 4>; + clocks = <&xgbe_clk>; + clock-names = "dma_clk"; + phy-handle = <&phy>; + phy-mode = "xgmii"; + mac-address = [ 02 a1 a2 a3 a4 a5 ]; + }; -- cgit v1.1 From b4be018921879ba7452379af8fb7320833a12bd4 Mon Sep 17 00:00:00 2001 From: Nishanth Menon Date: Fri, 16 May 2014 05:45:59 -0500 Subject: CLK: TI: dpll: support OMAP5 MPU DPLL that need special handling for higher frequencies MPU DPLL on OMAP5, DRA75x, DRA72x has a limitation on the maximum frequency it can be locked at. Duty Cycle Correction circuit is used to recover a correct duty cycle for achieving higher frequencies (hardware internally switches output to M3 output(CLKOUTHIF) from M2 output (CLKOUT)). So provide support to setup required data to handle Duty cycle by the setting up the minimum frequency for DPLL. 1.4GHz is common for all these devices and is based on Technical Reference Manual information for OMAP5432((SWPU282U) chapter 3.6.3.3.1 "DPLLs Output Clocks Parameters", and equivalent information from DRA75x, DRA72x documentation(SPRUHP2E, SPRUHI2P). Signed-off-by: Nishanth Menon [t-kristo@ti.com: updated for latest dpll init API call] Signed-off-by: Tero Kristo --- Documentation/devicetree/bindings/clock/ti/dpll.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt b/Documentation/devicetree/bindings/clock/ti/dpll.txt index 50a1a42..df57009 100644 --- a/Documentation/devicetree/bindings/clock/ti/dpll.txt +++ b/Documentation/devicetree/bindings/clock/ti/dpll.txt @@ -24,6 +24,7 @@ Required properties: "ti,omap4-dpll-core-clock", "ti,omap4-dpll-m4xen-clock", "ti,omap4-dpll-j-type-clock", + "ti,omap5-mpu-dpll-clock", "ti,am3-dpll-no-gate-clock", "ti,am3-dpll-j-type-clock", "ti,am3-dpll-no-gate-j-type-clock", -- cgit v1.1 From c3811711a6fd3965bfd8c782fa5c014aecaeeffc Mon Sep 17 00:00:00 2001 From: Loc Ho Date: Fri, 6 Jun 2014 14:35:40 -0700 Subject: Documentation/devicetree/bindings: add documentation for the APM X-Gene SoC RTC DTS binding Signed-off-by: Rameshwar Prasad Sahu Signed-off-by: Loc Ho Cc: Jon Masters Cc: Alessandro Zummo Cc: Catalin Marinas Cc: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- .../devicetree/bindings/rtc/xgene-rtc.txt | 28 ++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/rtc/xgene-rtc.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/xgene-rtc.txt b/Documentation/devicetree/bindings/rtc/xgene-rtc.txt new file mode 100644 index 0000000..fd195c3 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/xgene-rtc.txt @@ -0,0 +1,28 @@ +* APM X-Gene Real Time Clock + +RTC controller for the APM X-Gene Real Time Clock + +Required properties: +- compatible : Should be "apm,xgene-rtc" +- reg: physical base address of the controller and length of memory mapped + region. +- interrupts: IRQ line for the RTC. +- #clock-cells: Should be 1. +- clocks: Reference to the clock entry. + +Example: + +rtcclk: rtcclk { + compatible = "fixed-clock"; + #clock-cells = <1>; + clock-frequency = <100000000>; + clock-output-names = "rtcclk"; +}; + +rtc: rtc@10510000 { + compatible = "apm,xgene-rtc"; + reg = <0x0 0x10510000 0x0 0x400>; + interrupts = <0x0 0x46 0x4>; + #clock-cells = <1>; + clocks = <&rtcclk 0>; +}; -- cgit v1.1 From 68164a73b1055191975419f5da7180294902f461 Mon Sep 17 00:00:00 2001 From: Heiko Stuebner Date: Fri, 6 Jun 2014 14:36:08 -0700 Subject: drivers/rtc/rtc-hym8563.c: add optional clock-output-names property This enables the setting of a custom clock name for the clock provided by the hym8563 rtc. Signed-off-by: Heiko Stuebner Reviewed-by: Mike Turquette Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt b/Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt index 31406fd..5c199ee 100644 --- a/Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt +++ b/Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt @@ -9,6 +9,9 @@ Required properties: - interrupts: rtc alarm/event interrupt - #clock-cells: the value should be 0 +Optional properties: +- clock-output-names: From common clock binding + Example: hym8563: hym8563@51 { -- cgit v1.1 From 190a8843ded231638d0e7ae7d8ca6a712472d114 Mon Sep 17 00:00:00 2001 From: Conrad Meyer Date: Fri, 6 Jun 2014 14:36:37 -0700 Subject: fs/fat/: add support for DOS 1.x formatted volumes Add structure for parsed BPB information, struct fat_bios_param_block, and move all of the deserialization and validation logic from fat_fill_super() into fat_read_bpb(). Add a 'dos1xfloppy' mount option to infer DOS 2.x BIOS Parameter Block defaults from block device geometry for ancient floppies and floppy images, as a fall-back from the default BPB parsing logic. When fat_read_bpb() finds an invalid FAT filesystem and dos1xfloppy is set, fall back to fat_read_static_bpb(). fat_read_static_bpb() validates that the entire BPB is zero, and that the floppy has a DOS-style 8086 code bootstrapping header. Then it fills in default BPB values from media size and a table.[0] Media size is assumed to be static for archaic FAT volumes. See also: [1]. Fixes kernel.org bug #42617. [0]: https://en.wikipedia.org/wiki/File_Allocation_Table#Exceptions [1]: http://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html [hirofumi@mail.parknet.co.jp: fix missed error code] Signed-off-by: Conrad Meyer Acked-by: OGAWA Hirofumi Signed-off-by: OGAWA Hirofumi Tested-by: Alan Cox Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/filesystems/vfat.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/vfat.txt b/Documentation/filesystems/vfat.txt index 4a93e98..ce1126a 100644 --- a/Documentation/filesystems/vfat.txt +++ b/Documentation/filesystems/vfat.txt @@ -172,6 +172,11 @@ nfs=stale_rw|nostale_ro To maintain backward compatibility, '-o nfs' is also accepted, defaulting to stale_rw +dos1xfloppy -- If set, use a fallback default BIOS Parameter Block + configuration, determined by backing device size. These static + parameters match defaults assumed by DOS 1.x for 160 kiB, + 180 kiB, 320 kiB, and 360 kiB floppies and floppy images. + : 0,1,yes,no,true,false -- cgit v1.1 From 8401aa1f59975c03eeebd3ac6d264cbdfe9af5de Mon Sep 17 00:00:00 2001 From: Jacob Keller Date: Fri, 6 Jun 2014 14:36:39 -0700 Subject: Documentation/SubmittingPatches: describe the Fixes: tag Update the SubmittingPatches process to include howto about the new 'Fixes:' tag to be used when a patch fixes an issue in a previous commit (found by git-bisect for example). Signed-off-by: Jacob Keller Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Cc: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/SubmittingPatches | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 2a8e89e..7e9abb8 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -132,6 +132,20 @@ Example: platform_set_drvdata(), but left the variable "dev" unused, delete it. +If your patch fixes a bug in a specific commit, e.g. you found an issue using +git-bisect, please use the 'Fixes:' tag with the first 12 characters of the +SHA-1 ID, and the one line summary. +Example: + + Fixes: e21d2170f366 ("video: remove unnecessary platform_set_drvdata()") + +The following git-config settings can be used to add a pretty format for +outputting the above style in the git log or git show commands + + [core] + abbrev = 12 + [pretty] + fixes = Fixes: %h (\"%s\") 3) Separate your changes. @@ -443,7 +457,7 @@ person it names. This tag documents that potentially interested parties have been included in the discussion -14) Using Reported-by:, Tested-by:, Reviewed-by: and Suggested-by: +14) Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes: If this patch fixes a problem reported by somebody else, consider adding a Reported-by: tag to credit the reporter for their contribution. Please @@ -498,6 +512,12 @@ idea was not posted in a public forum. That said, if we diligently credit our idea reporters, they will, hopefully, be inspired to help us again in the future. +A Fixes: tag indicates that the patch fixes an issue in a previous commit. It +is used to make it easy to determine where a bug originated, which can help +review a bug fix. This tag also assists the stable kernel team in determining +which stable kernel versions should receive your fix. This is the preferred +method for indicating a bug fixed by the patch. See #2 above for more details. + 15) The canonical patch format -- cgit v1.1 From 0b07cb8271507ca99cca79222a1dc92ba415f06b Mon Sep 17 00:00:00 2001 From: Fabian Frederick Date: Fri, 6 Jun 2014 14:36:40 -0700 Subject: Documentation/filesystems/seq_file.txt: create_proc_entry deprecated Linked article in seq_file.txt still uses create_proc_entry which was removed in commit 80e928f7ebb9 ("proc: Kill create_proc_entry()"). This patch adds information for kernel 3.10 and above Signed-off-by: Fabian Frederick Cc: Jonathan Corbet Cc: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/filesystems/seq_file.txt | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/seq_file.txt b/Documentation/filesystems/seq_file.txt index a1e2e0d..1fe0ccb 100644 --- a/Documentation/filesystems/seq_file.txt +++ b/Documentation/filesystems/seq_file.txt @@ -54,6 +54,15 @@ how the mechanism works without getting lost in other details. (Those wanting to see the full source for this module can find it at http://lwn.net/Articles/22359/). +Deprecated create_proc_entry + +Note that the above article uses create_proc_entry which was removed in +kernel 3.10. Current versions require the following update + +- entry = create_proc_entry("sequence", 0, NULL); +- if (entry) +- entry->proc_fops = &ct_file_ops; ++ entry = proc_create("sequence", 0, NULL, &ct_file_ops); The iterator interface -- cgit v1.1 From 615cc2c9cf9529846fbc342560d6787c2ccaaeea Mon Sep 17 00:00:00 2001 From: Alexey Dobriyan Date: Fri, 6 Jun 2014 14:36:41 -0700 Subject: Documentation/memory-barriers.txt: fix important typo re memory barriers Examples introducing neccesity of RMB+WMP pair reads as A=3 READ B www rrrrrr B=4 READ A Note the opposite order of reads vs writes. But the first example without barriers reads as A=3 READ A B=4 READ B There are 4 outcomes in the first example. But if someone new to the concept tries to insert barriers like this: A=3 READ A www rrrrrr B=4 READ B he will still get all 4 possible outcomes, because "READ A" is first. All this can be utterly confusing because barrier pair seems to be superfluous. In short, fixup first example to match latter examples with barriers. Signed-off-by: Alexey Dobriyan Cc: David Howells Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/memory-barriers.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 46412bd..f1dc4a2 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -115,8 +115,8 @@ For example, consider the following sequence of events: CPU 1 CPU 2 =============== =============== { A == 1; B == 2 } - A = 3; x = A; - B = 4; y = B; + A = 3; x = B; + B = 4; y = A; The set of accesses as seen by the memory system in the middle can be arranged in 24 different combinations: -- cgit v1.1 From f06e5153f4ae2e2f3b0300f0e260e40cb7fefd45 Mon Sep 17 00:00:00 2001 From: Masami Hiramatsu Date: Fri, 6 Jun 2014 14:37:07 -0700 Subject: kernel/panic.c: add "crash_kexec_post_notifiers" option for kdump after panic_notifers Add a "crash_kexec_post_notifiers" boot option to run kdump after running panic_notifiers and dump kmsg. This can help rare situations where kdump fails because of unstable crashed kernel or hardware failure (memory corruption on critical data/code), or the 2nd kernel is already broken by the 1st kernel (it's a broken behavior, but who can guarantee that the "crashed" kernel works correctly?). Usage: add "crash_kexec_post_notifiers" to kernel boot option. Note that this actually increases risks of the failure of kdump. This option should be set only if you worry about the rare case of kdump failure rather than increasing the chance of success. Signed-off-by: Masami Hiramatsu Acked-by: Motohiro Kosaki Acked-by: Vivek Goyal Cc: Eric Biederman Cc: Yoshihiro YUNOMAE Cc: Satoru MORIYA Cc: Tomoki Sekiyama Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/kernel-parameters.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 9973a7e..b9f6778 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2361,6 +2361,14 @@ bytes respectively. Such letter suffixes can also be entirely omitted. timeout < 0: reboot immediately Format: + crash_kexec_post_notifiers + Run kdump after running panic-notifiers and dumping + kmsg. This only for the users who doubt kdump always + succeeds in any situation. + Note that this also increases risks of kdump failure, + because some panic notifiers can make the crashed + kernel more unstable. + parkbd.port= [HW] Parallel port number the keyboard adapter is connected to, default is 0. Format: -- cgit v1.1 From f4aacea2f5d1a5f7e3154e967d70cf3f711bcd61 Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Fri, 6 Jun 2014 14:37:19 -0700 Subject: sysctl: allow for strict write position handling When writing to a sysctl string, each write, regardless of VFS position, begins writing the string from the start. This means the contents of the last write to the sysctl controls the string contents instead of the first: open("/proc/sys/kernel/modprobe", O_WRONLY) = 1 write(1, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"..., 4096) = 4096 write(1, "/bin/true", 9) = 9 close(1) = 0 $ cat /proc/sys/kernel/modprobe /bin/true Expected behaviour would be to have the sysctl be "AAAA..." capped at maxlen (in this case KMOD_PATH_LEN: 256), instead of truncating to the contents of the second write. Similarly, multiple short writes would not append to the sysctl. The old behavior is unlike regular POSIX files enough that doing audits of software that interact with sysctls can end up in unexpected or dangerous situations. For example, "as long as the input starts with a trusted path" turns out to be an insufficient filter, as what must also happen is for the input to be entirely contained in a single write syscall -- not a common consideration, especially for high level tools. This provides kernel.sysctl_writes_strict as a way to make this behavior act in a less surprising manner for strings, and disallows non-zero file position when writing numeric sysctls (similar to what is already done when reading from non-zero file positions). For now, the default (0) is to warn about non-zero file position use, but retain the legacy behavior. Setting this to -1 disables the warning, and setting this to 1 enables the file position respecting behavior. [akpm@linux-foundation.org: fix build] [akpm@linux-foundation.org: move misplaced hunk, per Randy] Signed-off-by: Kees Cook Cc: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/sysctl/kernel.txt | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index 9886c3d..708bb7f 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -77,6 +77,7 @@ show up in /proc/sys/kernel: - shmmni - stop-a [ SPARC only ] - sysrq ==> Documentation/sysrq.txt +- sysctl_writes_strict - tainted - threads-max - unknown_nmi_panic @@ -762,6 +763,26 @@ without users and with a dead originative process will be destroyed. ============================================================== +sysctl_writes_strict: + +Control how file position affects the behavior of updating sysctl values +via the /proc/sys interface: + + -1 - Legacy per-write sysctl value handling, with no printk warnings. + Each write syscall must fully contain the sysctl value to be + written, and multiple writes on the same sysctl file descriptor + will rewrite the sysctl value, regardless of file position. + 0 - (default) Same behavior as above, but warn about processes that + perform writes to a sysctl file descriptor when the file position + is not 0. + 1 - Respect file position when writing sysctl strings. Multiple writes + will append to the sysctl value buffer. Anything past the max length + of the sysctl value buffer will be ignored. Writes to numeric sysctl + entries must always be at file position 0 and the value must be + fully contained in the buffer sent in the write syscall. + +============================================================== + tainted: Non-zero if the kernel has been tainted. Numeric values, which -- cgit v1.1 From 688eb988d15af55c1d1b70b1ca9f6ce58f277c20 Mon Sep 17 00:00:00 2001 From: Michal Hocko Date: Fri, 6 Jun 2014 14:38:15 -0700 Subject: vmscan: memcg: always use swappiness of the reclaimed memcg Memory reclaim always uses swappiness of the reclaim target memcg (origin of the memory pressure) or vm_swappiness for global memory reclaim. This behavior was consistent (except for difference between global and hard limit reclaim) because swappiness was enforced to be consistent within each memcg hierarchy. After "mm: memcontrol: remove hierarchy restrictions for swappiness and oom_control" each memcg can have its own swappiness independent of hierarchical parents, though, so the consistency guarantee is gone. This can lead to an unexpected behavior. Say that a group is explicitly configured to not swapout by memory.swappiness=0 but its memory gets swapped out anyway when the memory pressure comes from its parent with a It is also unexpected that the knob is meaningless without setting the hard limit which would trigger the reclaim and enforce the swappiness. There are setups where the hard limit is configured higher in the hierarchy by an administrator and children groups are under control of somebody else who is interested in the swapout behavior but not necessarily about the memory limit. From a semantic point of view swappiness is an attribute defining anon vs. file proportional scanning of LRU which is memcg specific (unlike charges which are propagated up the hierarchy) so it should be applied to the particular memcg's LRU regardless where the memory pressure comes from. This patch removes vmscan_swappiness() and stores the swappiness into the scan_control structure. mem_cgroup_swappiness is then used to provide the correct value before shrink_lruvec is called. The global vm_swappiness is used for the root memcg. [hughd@google.com: oopses immediately when booted with cgroup_disable=memory] Signed-off-by: Michal Hocko Acked-by: Johannes Weiner Cc: Tejun Heo Signed-off-by: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/cgroups/memory.txt | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index 4937e6f..b3429ae 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt @@ -540,14 +540,13 @@ Note: 5.3 swappiness -Similar to /proc/sys/vm/swappiness, but only affecting reclaim that is -triggered by this cgroup's hard limit. The tunable in the root cgroup -corresponds to the global swappiness setting. - -Please note that unlike the global swappiness, memcg knob set to 0 -really prevents from any swapping even if there is a swap storage -available. This might lead to memcg OOM killer if there are no file -pages to reclaim. +Overrides /proc/sys/vm/swappiness for the particular group. The tunable +in the root cgroup corresponds to the global swappiness setting. + +Please note that unlike during the global reclaim, limit reclaim +enforces that 0 swappiness really prevents from any swapping even if +there is a swap storage available. This might lead to memcg OOM killer +if there are no file pages to reclaim. 5.4 failcnt -- cgit v1.1 From ffe2c748e283c5dc1b9b9ac116299dbfc11a609b Mon Sep 17 00:00:00 2001 From: Catalin Marinas Date: Fri, 6 Jun 2014 14:38:17 -0700 Subject: mm: introduce kmemleak_update_trace() The memory allocation stack trace is not always useful for debugging a memory leak (e.g. radix_tree_preload). This function, when called, updates the stack trace for an already allocated object. Signed-off-by: Catalin Marinas Cc: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/kmemleak.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt index a7563ec..b772418 100644 --- a/Documentation/kmemleak.txt +++ b/Documentation/kmemleak.txt @@ -142,6 +142,7 @@ kmemleak_alloc_percpu - notify of a percpu memory block allocation kmemleak_free - notify of a memory block freeing kmemleak_free_part - notify of a partial memory block freeing kmemleak_free_percpu - notify of a percpu memory block freeing +kmemleak_update_trace - update object allocation stack trace kmemleak_not_leak - mark an object as not a leak kmemleak_ignore - do not scan or report an object as leak kmemleak_scan_area - add scan areas inside a memory block -- cgit v1.1 From 33041a0d76d3c3e0aff28ac95a2ffdedf1282dbc Mon Sep 17 00:00:00 2001 From: "Kirill A. Shutemov" Date: Fri, 6 Jun 2014 14:38:23 -0700 Subject: mm: mark remap_file_pages() syscall as deprecated The remap_file_pages() system call is used to create a nonlinear mapping, that is, a mapping in which the pages of the file are mapped into a nonsequential order in memory. The advantage of using remap_file_pages() over using repeated calls to mmap(2) is that the former approach does not require the kernel to create additional VMA (Virtual Memory Area) data structures. Supporting of nonlinear mapping requires significant amount of non-trivial code in kernel virtual memory subsystem including hot paths. Also to get nonlinear mapping work kernel need a way to distinguish normal page table entries from entries with file offset (pte_file). Kernel reserves flag in PTE for this purpose. PTE flags are scarce resource especially on some CPU architectures. It would be nice to free up the flag for other usage. Fortunately, there are not many users of remap_file_pages() in the wild. It's only known that one enterprise RDBMS implementation uses the syscall on 32-bit systems to map files bigger than can linearly fit into 32-bit virtual address space. This use-case is not critical anymore since 64-bit systems are widely available. The plan is to deprecate the syscall and replace it with an emulation. The emulation will create new VMAs instead of nonlinear mappings. It's going to work slower for rare users of remap_file_pages() but ABI is preserved. One side effect of emulation (apart from performance) is that user can hit vm.max_map_count limit more easily due to additional VMAs. See comment for DEFAULT_MAX_MAP_COUNT for more details on the limit. [akpm@linux-foundation.org: fix spello] Signed-off-by: Kirill A. Shutemov Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Dave Jones Cc: Armin Rigo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/remap_file_pages.txt | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 Documentation/vm/remap_file_pages.txt (limited to 'Documentation') diff --git a/Documentation/vm/remap_file_pages.txt b/Documentation/vm/remap_file_pages.txt new file mode 100644 index 0000000..560e436 --- /dev/null +++ b/Documentation/vm/remap_file_pages.txt @@ -0,0 +1,28 @@ +The remap_file_pages() system call is used to create a nonlinear mapping, +that is, a mapping in which the pages of the file are mapped into a +nonsequential order in memory. The advantage of using remap_file_pages() +over using repeated calls to mmap(2) is that the former approach does not +require the kernel to create additional VMA (Virtual Memory Area) data +structures. + +Supporting of nonlinear mapping requires significant amount of non-trivial +code in kernel virtual memory subsystem including hot paths. Also to get +nonlinear mapping work kernel need a way to distinguish normal page table +entries from entries with file offset (pte_file). Kernel reserves flag in +PTE for this purpose. PTE flags are scarce resource especially on some CPU +architectures. It would be nice to free up the flag for other usage. + +Fortunately, there are not many users of remap_file_pages() in the wild. +It's only known that one enterprise RDBMS implementation uses the syscall +on 32-bit systems to map files bigger than can linearly fit into 32-bit +virtual address space. This use-case is not critical anymore since 64-bit +systems are widely available. + +The plan is to deprecate the syscall and replace it with an emulation. +The emulation will create new VMAs instead of nonlinear mappings. It's +going to work slower for rare users of remap_file_pages() but ABI is +preserved. + +One side effect of emulation (apart from performance) is that user can hit +vm.max_map_count limit more easily due to additional VMAs. See comment for +DEFAULT_MAX_MAP_COUNT for more details on the limit. -- cgit v1.1 From a333f7ad1db5e77eea411b058d95a5d3587ab141 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane=20Marchesin?= Date: Fri, 23 May 2014 19:27:59 -0700 Subject: drm/panel: simple - Add AUO B133XTN01 panel support MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This panel is used by nyan-big and can be supported by the simple-panel driver. Signed-off-by: Stéphane Marchesin [treding@nvidia.com: add device tree binding document] Signed-off-by: Thierry Reding --- Documentation/devicetree/bindings/panel/auo,b133xtn01.txt | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/devicetree/bindings/panel/auo,b133xtn01.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/panel/auo,b133xtn01.txt b/Documentation/devicetree/bindings/panel/auo,b133xtn01.txt new file mode 100644 index 0000000..7443b7c --- /dev/null +++ b/Documentation/devicetree/bindings/panel/auo,b133xtn01.txt @@ -0,0 +1,7 @@ +AU Optronics Corporation 13.3" WXGA (1366x768) TFT LCD panel + +Required properties: +- compatible: should be "auo,b133xtn01" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- cgit v1.1 From 9b758d4e293deb282dd4870503e4d2778cf69df0 Mon Sep 17 00:00:00 2001 From: "Srivatsa S. Bhat" Date: Mon, 9 Jun 2014 18:01:42 +0530 Subject: PM / Documentation: Update copyright in suspend-and-cpuhotplug.txt Extend the year to 2014 in the copyright. Signed-off-by: Srivatsa S. Bhat Signed-off-by: Rafael J. Wysocki --- Documentation/power/suspend-and-cpuhotplug.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/power/suspend-and-cpuhotplug.txt b/Documentation/power/suspend-and-cpuhotplug.txt index e13dafc..2850df3 100644 --- a/Documentation/power/suspend-and-cpuhotplug.txt +++ b/Documentation/power/suspend-and-cpuhotplug.txt @@ -1,6 +1,6 @@ Interaction of Suspend code (S3) with the CPU hotplug infrastructure - (C) 2011 Srivatsa S. Bhat + (C) 2011 - 2014 Srivatsa S. Bhat I. How does the regular CPU hotplug code differ from how the Suspend-to-RAM -- cgit v1.1 From 4c0dae57873edb1560b738c6519361c5ecd443ae Mon Sep 17 00:00:00 2001 From: Damien Lespiau Date: Mon, 9 Jun 2014 14:40:35 +0100 Subject: drm/doc: Fix nouveau typo Signed-off-by: Damien Lespiau Reviewed-by: Alex Deucher Signed-off-by: Dave Airlie --- Documentation/DocBook/drm.tmpl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index d95027f..c526d81 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -3081,7 +3081,7 @@ void intel_crt_init(struct drm_device *dev) TBD - noveau + nouveau NV10 Overlay "colorkey" RANGE -- cgit v1.1 From 597486164e4da173be643107b5d15da88f0d689a Mon Sep 17 00:00:00 2001 From: Damien Lespiau Date: Mon, 9 Jun 2014 14:20:22 +0100 Subject: drm/doc: Add the "type" plane property to the list of properties Matt aded this plane property before we had a table giving a summary of the properties. Add it there. Cc: Matt Roper Signed-off-by: Damien Lespiau Signed-off-by: Dave Airlie --- Documentation/DocBook/drm.tmpl | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index c526d81..7df3134 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -2502,7 +2502,7 @@ void intel_crt_init(struct drm_device *dev) Description/Restrictions - DRM + DRM Generic “EDID” BLOB | IMMUTABLE @@ -2518,6 +2518,14 @@ void intel_crt_init(struct drm_device *dev) Contains DPMS operation mode value. + Plane + “type” + ENUM | IMMUTABLE + { "Overlay", "Primary", "Cursor" } + Plane + Plane type + + DVI-I “subconnector” ENUM -- cgit v1.1 From 4be7f0a30bd85c82278ffd65527b5276ffa23fff Mon Sep 17 00:00:00 2001 From: Warren Turkal Date: Sun, 8 Jun 2014 22:19:29 -0700 Subject: kbuild: Fix a typo in documentation Signed-off-by: Warren Turkal Acked-by: Randy Dunlap Signed-off-by: Michal Marek --- Documentation/kbuild/modules.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/kbuild/modules.txt b/Documentation/kbuild/modules.txt index 69372fb..3fb39e0 100644 --- a/Documentation/kbuild/modules.txt +++ b/Documentation/kbuild/modules.txt @@ -470,7 +470,7 @@ build. Sometimes, an external module uses exported symbols from another external module. kbuild needs to have full knowledge of - all symbols to avoid spliitting out warnings about undefined + all symbols to avoid spitting out warnings about undefined symbols. Three solutions exist for this situation. NOTE: The method with a top-level kbuild file is recommended -- cgit v1.1 From ebc5e336077aa2ea595f8ab5f989601e7e443332 Mon Sep 17 00:00:00 2001 From: Ezequiel Garcia Date: Sat, 15 Mar 2014 15:18:04 -0300 Subject: ARM: mvebu: Add A375/A380 watchdog binding documentation This commit documents the new support for "marvell,armada-{375,380}-wdt" compatible strings and the extra 'reg' entry requirement. Signed-off-by: Ezequiel Garcia Reviewed-by: Guenter Roeck Acked-by: Jason Cooper Signed-off-by: Wim Van Sebroeck --- Documentation/devicetree/bindings/watchdog/marvel.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/watchdog/marvel.txt b/Documentation/devicetree/bindings/watchdog/marvel.txt index de11eb4..97223fd 100644 --- a/Documentation/devicetree/bindings/watchdog/marvel.txt +++ b/Documentation/devicetree/bindings/watchdog/marvel.txt @@ -5,11 +5,18 @@ Required Properties: - Compatibility : "marvell,orion-wdt" "marvell,armada-370-wdt" "marvell,armada-xp-wdt" + "marvell,armada-375-wdt" + "marvell,armada-380-wdt" - reg : Should contain two entries: first one with the timer control address, second one with the rstout enable address. +For "marvell,armada-375-wdt" and "marvell,armada-380-wdt": + +- reg : A third entry is mandatory and should contain the + shared mask/unmask RSTOUT address. + Optional properties: - interrupts : Contains the IRQ for watchdog expiration -- cgit v1.1 From 4cbfdac12cd14252e5bd4c963cffd7e61a698396 Mon Sep 17 00:00:00 2001 From: Ismael Luceno Date: Wed, 21 May 2014 17:24:27 -0300 Subject: Documentation: Add list of laptop models supported by the Compal driver Signed-off-by: Ismael Luceno Signed-off-by: Matthew Garrett --- Documentation/platform/x86-laptop-drivers.txt | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 Documentation/platform/x86-laptop-drivers.txt (limited to 'Documentation') diff --git a/Documentation/platform/x86-laptop-drivers.txt b/Documentation/platform/x86-laptop-drivers.txt new file mode 100644 index 0000000..01facd2 --- /dev/null +++ b/Documentation/platform/x86-laptop-drivers.txt @@ -0,0 +1,18 @@ +compal-laptop +============= +List of supported hardware: + +by Compal: + Compal FL90/IFL90 + Compal FL91/IFL91 + Compal FL92/JFL92 + Compal FT00/IFT00 + +by Dell: + Dell Vostro 1200 + Dell Mini 9 (Inspiron 910) + Dell Mini 10 (Inspiron 1010) + Dell Mini 10v (Inspiron 1011) + Dell Mini 1012 (Inspiron 1012) + Dell Inspiron 11z (Inspiron 1110) + Dell Mini 12 (Inspiron 1210) -- cgit v1.1 From e430f34ee5192c84bcabd3c79ab7e2388b5eec74 Mon Sep 17 00:00:00 2001 From: Alexei Starovoitov Date: Fri, 6 Jun 2014 14:46:06 -0700 Subject: net: filter: cleanup A/X name usage The macro 'A' used in internal BPF interpreter: #define A regs[insn->a_reg] was easily confused with the name of classic BPF register 'A', since 'A' would mean two different things depending on context. This patch is trying to clean up the naming and clarify its usage in the following way: - A and X are names of two classic BPF registers - BPF_REG_A denotes internal BPF register R0 used to map classic register A in internal BPF programs generated from classic - BPF_REG_X denotes internal BPF register R7 used to map classic register X in internal BPF programs generated from classic - internal BPF instruction format: struct sock_filter_int { __u8 code; /* opcode */ __u8 dst_reg:4; /* dest register */ __u8 src_reg:4; /* source register */ __s16 off; /* signed offset */ __s32 imm; /* signed immediate constant */ }; - BPF_X/BPF_K is 1 bit used to encode source operand of instruction In classic: BPF_X - means use register X as source operand BPF_K - means use 32-bit immediate as source operand In internal: BPF_X - means use 'src_reg' register as source operand BPF_K - means use 32-bit immediate as source operand Suggested-by: Chema Gonzalez Signed-off-by: Alexei Starovoitov Acked-by: Daniel Borkmann Acked-by: Chema Gonzalez Signed-off-by: David S. Miller --- Documentation/networking/filter.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt index 58c4439..9f49b86 100644 --- a/Documentation/networking/filter.txt +++ b/Documentation/networking/filter.txt @@ -805,7 +805,7 @@ to seccomp_data, for converted BPF filters R1 points to a skb. A program, that is translated internally consists of the following elements: - op:16, jt:8, jf:8, k:32 ==> op:8, a_reg:4, x_reg:4, off:16, imm:32 + op:16, jt:8, jf:8, k:32 ==> op:8, dst_reg:4, src_reg:4, off:16, imm:32 So far 87 internal BPF instructions were implemented. 8-bit 'op' opcode field has room for new instructions. Some of them may use 16/24/32 byte encoding. New -- cgit v1.1 From 6d1d14d5ce3e7880f91e7cfbdeca88128fe741ca Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Emilio=20L=C3=B3pez?= Date: Tue, 13 May 2014 13:29:26 -0300 Subject: clk: sunxi: document new A31 USB clock compatible MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Support for the USB gates and resets on A31 has been recently added using a new compatible, so let's document it here. Signed-off-by: Emilio López --- Documentation/devicetree/bindings/clock/sunxi.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt index a5160d8..1f6d3f4 100644 --- a/Documentation/devicetree/bindings/clock/sunxi.txt +++ b/Documentation/devicetree/bindings/clock/sunxi.txt @@ -41,6 +41,7 @@ Required properties: "allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31 "allwinner,sun4i-a10-usb-clk" - for usb gates + resets on A10 / A20 "allwinner,sun5i-a13-usb-clk" - for usb gates + resets on A13 + "allwinner,sun6i-a31-usb-clk" - for usb gates + resets on A31 Required properties for all clocks: - reg : shall be the control register address for the clock. -- cgit v1.1 From 5c89a8b65760a60eea38e0b172d04152ec03a067 Mon Sep 17 00:00:00 2001 From: Boris BREZILLON Date: Thu, 15 May 2014 10:55:12 +0200 Subject: clk: sunxi: document PRCM clock compatible strings MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Document new compatible strings for clock provided by the PRCM (Power/Reset/Clock Management) unit. Signed-off-by: Boris BREZILLON Signed-off-by: Emilio López --- Documentation/devicetree/bindings/clock/sunxi.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt index 1f6d3f4..b9ec668 100644 --- a/Documentation/devicetree/bindings/clock/sunxi.txt +++ b/Documentation/devicetree/bindings/clock/sunxi.txt @@ -20,12 +20,15 @@ Required properties: "allwinner,sun5i-a13-ahb-gates-clk" - for the AHB gates on A13 "allwinner,sun5i-a10s-ahb-gates-clk" - for the AHB gates on A10s "allwinner,sun7i-a20-ahb-gates-clk" - for the AHB gates on A20 + "allwinner,sun6i-a31-ar100-clk" - for the AR100 on A31 "allwinner,sun6i-a31-ahb1-mux-clk" - for the AHB1 multiplexer on A31 "allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31 "allwinner,sun4i-a10-apb0-clk" - for the APB0 clock + "allwinner,sun6i-a31-apb0-clk" - for the APB0 clock on A31 "allwinner,sun4i-a10-apb0-gates-clk" - for the APB0 gates on A10 "allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13 "allwinner,sun5i-a10s-apb0-gates-clk" - for the APB0 gates on A10s + "allwinner,sun6i-a31-apb0-gates-clk" - for the APB0 gates on A31 "allwinner,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20 "allwinner,sun4i-a10-apb1-clk" - for the APB1 clock "allwinner,sun4i-a10-apb1-mux-clk" - for the APB1 clock muxing -- cgit v1.1 From c41aa3ce938b684d853f1004072b6116a41bb1ce Mon Sep 17 00:00:00 2001 From: Max Schwarz Date: Wed, 11 Jun 2014 22:34:37 +0200 Subject: i2c: rk3x: add driver for Rockchip RK3xxx SoC I2C adapter Driver for the native I2C adapter found in Rockchip RK3xxx SoCs. Configuration is only possible through devicetree. The driver is interrupt driven and supports the I2C_M_IGNORE_NAK mangling bit. Signed-off-by: Max Schwarz Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/i2c-rk3x.txt | 42 ++++++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-rk3x.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt b/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt new file mode 100644 index 0000000..dde6c22 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt @@ -0,0 +1,42 @@ +* Rockchip RK3xxx I2C controller + +This driver interfaces with the native I2C controller present in Rockchip +RK3xxx SoCs. + +Required properties : + + - reg : Offset and length of the register set for the device + - compatible : should be "rockchip,rk3066-i2c", "rockchip,rk3188-i2c" or + "rockchip,rk3288-i2c". + - interrupts : interrupt number + - clocks : parent clock + +Required on RK3066, RK3188 : + + - rockchip,grf : the phandle of the syscon node for the general register + file (GRF) + - on those SoCs an alias with the correct I2C bus ID (bit offset in the GRF) + is also required. + +Optional properties : + + - clock-frequency : SCL frequency to use (in Hz). If omitted, 100kHz is used. + +Example: + +aliases { + i2c0 = &i2c0; +} + +i2c0: i2c@2002d000 { + compatible = "rockchip,rk3188-i2c"; + reg = <0x2002d000 0x1000>; + interrupts = ; + #address-cells = <1>; + #size-cells = <0>; + + rockchip,grf = <&grf>; + + clock-names = "i2c"; + clocks = <&cru PCLK_I2C0>; +}; -- cgit v1.1 From bb336ba0aaa5bef253d60bdeb08537ddecc7f42f Mon Sep 17 00:00:00 2001 From: Boris BREZILLON Date: Wed, 11 Jun 2014 11:17:29 +0200 Subject: i2c: sunxi: add P2WI DT bindings documentation P2WI (Push/Pull 2 Wire Interface) is an SMBus like bus used to communicate with some PMICs (like the AXP221). Document P2WI DT bindings which are pretty much the same as the one defined for the marvell's mv64xxx controller. Signed-off-by: Boris BREZILLON Signed-off-by: Wolfram Sang --- .../devicetree/bindings/i2c/i2c-sunxi-p2wi.txt | 41 ++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-sunxi-p2wi.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-sunxi-p2wi.txt b/Documentation/devicetree/bindings/i2c/i2c-sunxi-p2wi.txt new file mode 100644 index 0000000..6b76548 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-sunxi-p2wi.txt @@ -0,0 +1,41 @@ + +* Allwinner P2WI (Push/Pull 2 Wire Interface) controller + +Required properties : + + - reg : Offset and length of the register set for the device. + - compatible : Should one of the following: + - "allwinner,sun6i-a31-p2wi" + - interrupts : The interrupt line connected to the P2WI peripheral. + - clocks : The gate clk connected to the P2WI peripheral. + - resets : The reset line connected to the P2WI peripheral. + +Optional properties : + + - clock-frequency : Desired P2WI bus clock frequency in Hz. If not set the +default frequency is 100kHz + +A P2WI may contain one child node encoding a P2WI slave device. + +Slave device properties: + Required properties: + - reg : the I2C slave address used during the initialization + process to switch from I2C to P2WI mode + +Example: + + p2wi@01f03400 { + compatible = "allwinner,sun6i-a31-p2wi"; + reg = <0x01f03400 0x400>; + interrupts = <0 39 4>; + clocks = <&apb0_gates 3>; + clock-frequency = <6000000>; + resets = <&apb0_rst 3>; + + axp221: pmic@68 { + compatible = "x-powers,axp221"; + reg = <0x68>; + + /* ... */ + }; + }; -- cgit v1.1 From e4ad403269ff0ecdfb137b2a72349c30941cec7a Mon Sep 17 00:00:00 2001 From: Alexei Starovoitov Date: Tue, 10 Jun 2014 17:44:06 +0200 Subject: net: filter: mention eBPF terminology as well Since the term eBPF is used anyway on mailing list discussions, lets also document that in the main BPF documentation file and replace a couple of occurrences with eBPF terminology to be more clear. Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Signed-off-by: David S. Miller --- Documentation/networking/filter.txt | 85 +++++++++++++++++++------------------ 1 file changed, 43 insertions(+), 42 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt index 9f49b86..1c7fc6b 100644 --- a/Documentation/networking/filter.txt +++ b/Documentation/networking/filter.txt @@ -561,42 +561,43 @@ toolchain for developing and testing the kernel's JIT compiler. BPF kernel internals -------------------- -Internally, for the kernel interpreter, a different BPF instruction set +Internally, for the kernel interpreter, a different instruction set format with similar underlying principles from BPF described in previous paragraphs is being used. However, the instruction set format is modelled closer to the underlying architecture to mimic native instruction sets, so -that a better performance can be achieved (more details later). +that a better performance can be achieved (more details later). This new +ISA is called 'eBPF' or 'internal BPF' interchangeably. (Note: eBPF which +originates from [e]xtended BPF is not the same as BPF extensions! While +eBPF is an ISA, BPF extensions date back to classic BPF's 'overloading' +of BPF_LD | BPF_{B,H,W} | BPF_ABS instruction.) It is designed to be JITed with one to one mapping, which can also open up -the possibility for GCC/LLVM compilers to generate optimized BPF code through -a BPF backend that performs almost as fast as natively compiled code. +the possibility for GCC/LLVM compilers to generate optimized eBPF code through +an eBPF backend that performs almost as fast as natively compiled code. The new instruction set was originally designed with the possible goal in -mind to write programs in "restricted C" and compile into BPF with a optional +mind to write programs in "restricted C" and compile into eBPF with a optional GCC/LLVM backend, so that it can just-in-time map to modern 64-bit CPUs with -minimal performance overhead over two steps, that is, C -> BPF -> native code. +minimal performance overhead over two steps, that is, C -> eBPF -> native code. Currently, the new format is being used for running user BPF programs, which includes seccomp BPF, classic socket filters, cls_bpf traffic classifier, team driver's classifier for its load-balancing mode, netfilter's xt_bpf extension, PTP dissector/classifier, and much more. They are all internally converted by the kernel into the new instruction set representation and run -in the extended interpreter. For in-kernel handlers, this all works -transparently by using sk_unattached_filter_create() for setting up the -filter, resp. sk_unattached_filter_destroy() for destroying it. The macro -SK_RUN_FILTER(filter, ctx) transparently invokes the right BPF function to -run the filter. 'filter' is a pointer to struct sk_filter that we got from -sk_unattached_filter_create(), and 'ctx' the given context (e.g. skb pointer). -All constraints and restrictions from sk_chk_filter() apply before a -conversion to the new layout is being done behind the scenes! - -Currently, for JITing, the user BPF format is being used and current BPF JIT -compilers reused whenever possible. In other words, we do not (yet!) perform -a JIT compilation in the new layout, however, future work will successively -migrate traditional JIT compilers into the new instruction format as well, so -that they will profit from the very same benefits. Thus, when speaking about -JIT in the following, a JIT compiler (TBD) for the new instruction format is -meant in this context. +in the eBPF interpreter. For in-kernel handlers, this all works transparently +by using sk_unattached_filter_create() for setting up the filter, resp. +sk_unattached_filter_destroy() for destroying it. The macro +SK_RUN_FILTER(filter, ctx) transparently invokes eBPF interpreter or JITed +code to run the filter. 'filter' is a pointer to struct sk_filter that we +got from sk_unattached_filter_create(), and 'ctx' the given context (e.g. +skb pointer). All constraints and restrictions from sk_chk_filter() apply +before a conversion to the new layout is being done behind the scenes! + +Currently, the classic BPF format is being used for JITing on most of the +architectures. Only x86-64 performs JIT compilation from eBPF instruction set, +however, future work will migrate other JIT compilers as well, so that they +will profit from the very same benefits. Some core changes of the new internal format: @@ -605,35 +606,35 @@ Some core changes of the new internal format: The old format had two registers A and X, and a hidden frame pointer. The new layout extends this to be 10 internal registers and a read-only frame pointer. Since 64-bit CPUs are passing arguments to functions via registers - the number of args from BPF program to in-kernel function is restricted + the number of args from eBPF program to in-kernel function is restricted to 5 and one register is used to accept return value from an in-kernel function. Natively, x86_64 passes first 6 arguments in registers, aarch64/ sparcv9/mips64 have 7 - 8 registers for arguments; x86_64 has 6 callee saved registers, and aarch64/sparcv9/mips64 have 11 or more callee saved registers. - Therefore, BPF calling convention is defined as: + Therefore, eBPF calling convention is defined as: - * R0 - return value from in-kernel function, and exit value for BPF program - * R1 - R5 - arguments from BPF program to in-kernel function + * R0 - return value from in-kernel function, and exit value for eBPF program + * R1 - R5 - arguments from eBPF program to in-kernel function * R6 - R9 - callee saved registers that in-kernel function will preserve * R10 - read-only frame pointer to access stack - Thus, all BPF registers map one to one to HW registers on x86_64, aarch64, - etc, and BPF calling convention maps directly to ABIs used by the kernel on + Thus, all eBPF registers map one to one to HW registers on x86_64, aarch64, + etc, and eBPF calling convention maps directly to ABIs used by the kernel on 64-bit architectures. On 32-bit architectures JIT may map programs that use only 32-bit arithmetic and may let more complex programs to be interpreted. - R0 - R5 are scratch registers and BPF program needs spill/fill them if - necessary across calls. Note that there is only one BPF program (== one BPF - main routine) and it cannot call other BPF functions, it can only call - predefined in-kernel functions, though. + R0 - R5 are scratch registers and eBPF program needs spill/fill them if + necessary across calls. Note that there is only one eBPF program (== one + eBPF main routine) and it cannot call other eBPF functions, it can only + call predefined in-kernel functions, though. - Register width increases from 32-bit to 64-bit: Still, the semantics of the original 32-bit ALU operations are preserved - via 32-bit subregisters. All BPF registers are 64-bit with 32-bit lower + via 32-bit subregisters. All eBPF registers are 64-bit with 32-bit lower subregisters that zero-extend into 64-bit if they are being written to. That behavior maps directly to x86_64 and arm64 subregister definition, but makes other JITs more difficult. @@ -644,8 +645,8 @@ Some core changes of the new internal format: Operation is 64-bit, because on 64-bit architectures, pointers are also 64-bit wide, and we want to pass 64-bit values in/out of kernel functions, - so 32-bit BPF registers would otherwise require to define register-pair - ABI, thus, there won't be able to use a direct BPF register to HW register + so 32-bit eBPF registers would otherwise require to define register-pair + ABI, thus, there won't be able to use a direct eBPF register to HW register mapping and JIT would need to do combine/split/move operations for every register in and out of the function, which is complex, bug prone and slow. Another reason is the use of atomic 64-bit counters. @@ -690,7 +691,7 @@ Some core changes of the new internal format: subq %rsi, %rax ret - Function f2 in BPF may look like: + Function f2 in eBPF may look like: f2: bpf_mov R2, R1 @@ -702,7 +703,7 @@ Some core changes of the new internal format: returns will be seamless. Without JIT, __sk_run_filter() interpreter needs to be used to call into f2. - For practical reasons all BPF programs have only one argument 'ctx' which is + For practical reasons all eBPF programs have only one argument 'ctx' which is already placed into R1 (e.g. on __sk_run_filter() startup) and the programs can call kernel functions with up to 5 arguments. Calls with 6 or more arguments are currently not supported, but these restrictions can be lifted if necessary @@ -779,9 +780,9 @@ Some core changes of the new internal format: In-kernel functions foo() and bar() with prototype: u64 (*)(u64 arg1, u64 arg2, u64 arg3, u64 arg4, u64 arg5); will receive arguments in proper - registers and place their return value into '%rax' which is R0 in BPF. + registers and place their return value into '%rax' which is R0 in eBPF. Prologue and epilogue are emitted by JIT and are implicit in the - interpreter. R0-R5 are scratch registers, so BPF program needs to preserve + interpreter. R0-R5 are scratch registers, so eBPF program needs to preserve them across the calls as defined by calling convention. For example the following program is invalid: @@ -792,12 +793,12 @@ Some core changes of the new internal format: bpf_exit After the call the registers R1-R5 contain junk values and cannot be read. - In the future a BPF verifier can be used to validate internal BPF programs. + In the future an eBPF verifier can be used to validate internal BPF programs. -Also in the new design, BPF is limited to 4096 insns, which means that any +Also in the new design, eBPF is limited to 4096 insns, which means that any program will terminate quickly and will only call a fixed number of kernel functions. Original BPF and the new format are two operand instructions, -which helps to do one-to-one mapping between BPF insn and x86 insn during JIT. +which helps to do one-to-one mapping between eBPF insn and x86 insn during JIT. The input context pointer for invoking the interpreter function is generic, its content is defined by a specific use case. For seccomp register R1 points -- cgit v1.1 From 783e327b69e24924055359a4e5779d04c052974a Mon Sep 17 00:00:00 2001 From: Alexei Starovoitov Date: Tue, 10 Jun 2014 17:44:07 +0200 Subject: net: filter: document internal instruction encoding This patch adds a description of eBPFs instruction encoding in order to bring the documentation in line with the implementation. Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Signed-off-by: David S. Miller --- Documentation/networking/filter.txt | 161 ++++++++++++++++++++++++++++++++++++ 1 file changed, 161 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt index 1c7fc6b..ee78eba 100644 --- a/Documentation/networking/filter.txt +++ b/Documentation/networking/filter.txt @@ -834,6 +834,167 @@ loops and other CFG validation; second step starts from the first insn and descends all possible paths. It simulates execution of every insn and observes the state change of registers and stack. +eBPF opcode encoding +-------------------- + +eBPF is reusing most of the opcode encoding from classic to simplify conversion +of classic BPF to eBPF. For arithmetic and jump instructions the 8-bit 'code' +field is divided into three parts: + + +----------------+--------+--------------------+ + | 4 bits | 1 bit | 3 bits | + | operation code | source | instruction class | + +----------------+--------+--------------------+ + (MSB) (LSB) + +Three LSB bits store instruction class which is one of: + + Classic BPF classes: eBPF classes: + + BPF_LD 0x00 BPF_LD 0x00 + BPF_LDX 0x01 BPF_LDX 0x01 + BPF_ST 0x02 BPF_ST 0x02 + BPF_STX 0x03 BPF_STX 0x03 + BPF_ALU 0x04 BPF_ALU 0x04 + BPF_JMP 0x05 BPF_JMP 0x05 + BPF_RET 0x06 [ class 6 unused, for future if needed ] + BPF_MISC 0x07 BPF_ALU64 0x07 + +When BPF_CLASS(code) == BPF_ALU or BPF_JMP, 4th bit encodes source operand ... + + BPF_K 0x00 + BPF_X 0x08 + + * in classic BPF, this means: + + BPF_SRC(code) == BPF_X - use register X as source operand + BPF_SRC(code) == BPF_K - use 32-bit immediate as source operand + + * in eBPF, this means: + + BPF_SRC(code) == BPF_X - use 'src_reg' register as source operand + BPF_SRC(code) == BPF_K - use 32-bit immediate as source operand + +... and four MSB bits store operation code. + +If BPF_CLASS(code) == BPF_ALU or BPF_ALU64 [ in eBPF ], BPF_OP(code) is one of: + + BPF_ADD 0x00 + BPF_SUB 0x10 + BPF_MUL 0x20 + BPF_DIV 0x30 + BPF_OR 0x40 + BPF_AND 0x50 + BPF_LSH 0x60 + BPF_RSH 0x70 + BPF_NEG 0x80 + BPF_MOD 0x90 + BPF_XOR 0xa0 + BPF_MOV 0xb0 /* eBPF only: mov reg to reg */ + BPF_ARSH 0xc0 /* eBPF only: sign extending shift right */ + BPF_END 0xd0 /* eBPF only: endianness conversion */ + +If BPF_CLASS(code) == BPF_JMP, BPF_OP(code) is one of: + + BPF_JA 0x00 + BPF_JEQ 0x10 + BPF_JGT 0x20 + BPF_JGE 0x30 + BPF_JSET 0x40 + BPF_JNE 0x50 /* eBPF only: jump != */ + BPF_JSGT 0x60 /* eBPF only: signed '>' */ + BPF_JSGE 0x70 /* eBPF only: signed '>=' */ + BPF_CALL 0x80 /* eBPF only: function call */ + BPF_EXIT 0x90 /* eBPF only: function return */ + +So BPF_ADD | BPF_X | BPF_ALU means 32-bit addition in both classic BPF +and eBPF. There are only two registers in classic BPF, so it means A += X. +In eBPF it means dst_reg = (u32) dst_reg + (u32) src_reg; similarly, +BPF_XOR | BPF_K | BPF_ALU means A ^= imm32 in classic BPF and analogous +src_reg = (u32) src_reg ^ (u32) imm32 in eBPF. + +Classic BPF is using BPF_MISC class to represent A = X and X = A moves. +eBPF is using BPF_MOV | BPF_X | BPF_ALU code instead. Since there are no +BPF_MISC operations in eBPF, the class 7 is used as BPF_ALU64 to mean +exactly the same operations as BPF_ALU, but with 64-bit wide operands +instead. So BPF_ADD | BPF_X | BPF_ALU64 means 64-bit addition, i.e.: +dst_reg = dst_reg + src_reg + +Classic BPF wastes the whole BPF_RET class to represent a single 'ret' +operation. Classic BPF_RET | BPF_K means copy imm32 into return register +and perform function exit. eBPF is modeled to match CPU, so BPF_JMP | BPF_EXIT +in eBPF means function exit only. The eBPF program needs to store return +value into register R0 before doing a BPF_EXIT. Class 6 in eBPF is currently +unused and reserved for future use. + +For load and store instructions the 8-bit 'code' field is divided as: + + +--------+--------+-------------------+ + | 3 bits | 2 bits | 3 bits | + | mode | size | instruction class | + +--------+--------+-------------------+ + (MSB) (LSB) + +Size modifier is one of ... + + BPF_W 0x00 /* word */ + BPF_H 0x08 /* half word */ + BPF_B 0x10 /* byte */ + BPF_DW 0x18 /* eBPF only, double word */ + +... which encodes size of load/store operation: + + B - 1 byte + H - 2 byte + W - 4 byte + DW - 8 byte (eBPF only) + +Mode modifier is one of: + + BPF_IMM 0x00 /* classic BPF only, reserved in eBPF */ + BPF_ABS 0x20 + BPF_IND 0x40 + BPF_MEM 0x60 + BPF_LEN 0x80 /* classic BPF only, reserved in eBPF */ + BPF_MSH 0xa0 /* classic BPF only, reserved in eBPF */ + BPF_XADD 0xc0 /* eBPF only, exclusive add */ + +eBPF has two non-generic instructions: (BPF_ABS | | BPF_LD) and +(BPF_IND | | BPF_LD) which are used to access packet data. + +They had to be carried over from classic to have strong performance of +socket filters running in eBPF interpreter. These instructions can only +be used when interpreter context is a pointer to 'struct sk_buff' and +have seven implicit operands. Register R6 is an implicit input that must +contain pointer to sk_buff. Register R0 is an implicit output which contains +the data fetched from the packet. Registers R1-R5 are scratch registers +and must not be used to store the data across BPF_ABS | BPF_LD or +BPF_IND | BPF_LD instructions. + +These instructions have implicit program exit condition as well. When +eBPF program is trying to access the data beyond the packet boundary, +the interpreter will abort the execution of the program. JIT compilers +therefore must preserve this property. src_reg and imm32 fields are +explicit inputs to these instructions. + +For example: + + BPF_IND | BPF_W | BPF_LD means: + + R0 = ntohl(*(u32 *) (((struct sk_buff *) R6)->data + src_reg + imm32)) + and R1 - R5 were scratched. + +Unlike classic BPF instruction set, eBPF has generic load/store operations: + +BPF_MEM | | BPF_STX: *(size *) (dst_reg + off) = src_reg +BPF_MEM | | BPF_ST: *(size *) (dst_reg + off) = imm32 +BPF_MEM | | BPF_LDX: dst_reg = *(size *) (src_reg + off) +BPF_XADD | BPF_W | BPF_STX: lock xadd *(u32 *)(dst_reg + off16) += src_reg +BPF_XADD | BPF_DW | BPF_STX: lock xadd *(u64 *)(dst_reg + off16) += src_reg + +Where size is one of: BPF_B or BPF_H or BPF_W or BPF_DW. Note that 1 and +2 byte atomic increments are not supported. + Testing ------- -- cgit v1.1 From 1a539d372edd9832444e7a3daa710c444c014dc9 Mon Sep 17 00:00:00 2001 From: Tomas Pop Date: Thu, 5 Jun 2014 15:24:19 -0700 Subject: hwmon: add support for Sensirion SHTC1 sensor Add support for Sensirion SHTC1 and compatible temperature and humidity sensors. Signed-off-by: Tomas Pop Signed-off-by: Guenter Roeck --- Documentation/hwmon/shtc1 | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 Documentation/hwmon/shtc1 (limited to 'Documentation') diff --git a/Documentation/hwmon/shtc1 b/Documentation/hwmon/shtc1 new file mode 100644 index 0000000..6b1e054 --- /dev/null +++ b/Documentation/hwmon/shtc1 @@ -0,0 +1,43 @@ +Kernel driver shtc1 +=================== + +Supported chips: + * Sensirion SHTC1 + Prefix: 'shtc1' + Addresses scanned: none + Datasheet: http://www.sensirion.com/file/datasheet_shtc1 + + * Sensirion SHTW1 + Prefix: 'shtw1' + Addresses scanned: none + Datasheet: Not publicly available + +Author: + Johannes Winkelmann + +Description +----------- + +This driver implements support for the Sensirion SHTC1 chip, a humidity and +temperature sensor. Temperature is measured in degrees celsius, relative +humidity is expressed as a percentage. Driver can be used as well for SHTW1 +chip, which has the same electrical interface. + +The device communicates with the I2C protocol. All sensors are set to I2C +address 0x70. See Documentation/i2c/instantiating-devices for methods to +instantiate the device. + +There are two options configurable by means of shtc1_platform_data: +1. blocking (pull the I2C clock line down while performing the measurement) or + non-blocking mode. Blocking mode will guarantee the fastest result but + the I2C bus will be busy during that time. By default, non-blocking mode + is used. Make sure clock-stretching works properly on your device if you + want to use blocking mode. +2. high or low accuracy. High accuracy is used by default and using it is + strongly recommended. + +sysfs-Interface +--------------- + +temp1_input - temperature input +humidity1_input - humidity input -- cgit v1.1 From 6e8f21584a30ba6ce73cfef34f316d5bf3fadaab Mon Sep 17 00:00:00 2001 From: Andy Lutomirski Date: Thu, 12 Jun 2014 17:53:09 -0700 Subject: x86/vdso/doc: Rename vdso_test.c to vdso_standalone_test_x86.c This thing is hopelessly x86_64-specific: it's an example of how to access the vDSO without any runtime support at all. Signed-off-by: Andy Lutomirski Link: http://lkml.kernel.org/r/3efc170e0e166e15f0150c9fdb37d52488b9c0a4.1402620737.git.luto@amacapital.net Signed-off-by: H. Peter Anvin --- Documentation/vDSO/vdso_standalone_test_x86.c | 111 ++++++++++++++++++++++++++ Documentation/vDSO/vdso_test.c | 111 -------------------------- 2 files changed, 111 insertions(+), 111 deletions(-) create mode 100644 Documentation/vDSO/vdso_standalone_test_x86.c delete mode 100644 Documentation/vDSO/vdso_test.c (limited to 'Documentation') diff --git a/Documentation/vDSO/vdso_standalone_test_x86.c b/Documentation/vDSO/vdso_standalone_test_x86.c new file mode 100644 index 0000000..1523f5d --- /dev/null +++ b/Documentation/vDSO/vdso_standalone_test_x86.c @@ -0,0 +1,111 @@ +/* + * vdso_test.c: Sample code to test parse_vdso.c on x86_64 + * Copyright (c) 2011 Andy Lutomirski + * Subject to the GNU General Public License, version 2 + * + * You can amuse yourself by compiling with: + * gcc -std=gnu99 -nostdlib + * -Os -fno-asynchronous-unwind-tables -flto + * vdso_standalone_test_x86.c parse_vdso.c + * to generate a small binary with no dependencies at all. + */ + +#include +#include +#include +#include + +extern void *vdso_sym(const char *version, const char *name); +extern void vdso_init_from_sysinfo_ehdr(uintptr_t base); +extern void vdso_init_from_auxv(void *auxv); + +/* We need a libc functions... */ +int strcmp(const char *a, const char *b) +{ + /* This implementation is buggy: it never returns -1. */ + while (*a || *b) { + if (*a != *b) + return 1; + if (*a == 0 || *b == 0) + return 1; + a++; + b++; + } + + return 0; +} + +/* ...and two syscalls. This is x86_64-specific. */ +static inline long linux_write(int fd, const void *data, size_t len) +{ + + long ret; + asm volatile ("syscall" : "=a" (ret) : "a" (__NR_write), + "D" (fd), "S" (data), "d" (len) : + "cc", "memory", "rcx", + "r8", "r9", "r10", "r11" ); + return ret; +} + +static inline void linux_exit(int code) +{ + asm volatile ("syscall" : : "a" (__NR_exit), "D" (code)); +} + +void to_base10(char *lastdig, uint64_t n) +{ + while (n) { + *lastdig = (n % 10) + '0'; + n /= 10; + lastdig--; + } +} + +__attribute__((externally_visible)) void c_main(void **stack) +{ + /* Parse the stack */ + long argc = (long)*stack; + stack += argc + 2; + + /* Now we're pointing at the environment. Skip it. */ + while(*stack) + stack++; + stack++; + + /* Now we're pointing at auxv. Initialize the vDSO parser. */ + vdso_init_from_auxv((void *)stack); + + /* Find gettimeofday. */ + typedef long (*gtod_t)(struct timeval *tv, struct timezone *tz); + gtod_t gtod = (gtod_t)vdso_sym("LINUX_2.6", "__vdso_gettimeofday"); + + if (!gtod) + linux_exit(1); + + struct timeval tv; + long ret = gtod(&tv, 0); + + if (ret == 0) { + char buf[] = "The time is .000000\n"; + to_base10(buf + 31, tv.tv_sec); + to_base10(buf + 38, tv.tv_usec); + linux_write(1, buf, sizeof(buf) - 1); + } else { + linux_exit(ret); + } + + linux_exit(0); +} + +/* + * This is the real entry point. It passes the initial stack into + * the C entry point. + */ +asm ( + ".text\n" + ".global _start\n" + ".type _start,@function\n" + "_start:\n\t" + "mov %rsp,%rdi\n\t" + "jmp c_main" + ); diff --git a/Documentation/vDSO/vdso_test.c b/Documentation/vDSO/vdso_test.c deleted file mode 100644 index fff6334..0000000 --- a/Documentation/vDSO/vdso_test.c +++ /dev/null @@ -1,111 +0,0 @@ -/* - * vdso_test.c: Sample code to test parse_vdso.c on x86_64 - * Copyright (c) 2011 Andy Lutomirski - * Subject to the GNU General Public License, version 2 - * - * You can amuse yourself by compiling with: - * gcc -std=gnu99 -nostdlib - * -Os -fno-asynchronous-unwind-tables -flto - * vdso_test.c parse_vdso.c -o vdso_test - * to generate a small binary with no dependencies at all. - */ - -#include -#include -#include -#include - -extern void *vdso_sym(const char *version, const char *name); -extern void vdso_init_from_sysinfo_ehdr(uintptr_t base); -extern void vdso_init_from_auxv(void *auxv); - -/* We need a libc functions... */ -int strcmp(const char *a, const char *b) -{ - /* This implementation is buggy: it never returns -1. */ - while (*a || *b) { - if (*a != *b) - return 1; - if (*a == 0 || *b == 0) - return 1; - a++; - b++; - } - - return 0; -} - -/* ...and two syscalls. This is x86_64-specific. */ -static inline long linux_write(int fd, const void *data, size_t len) -{ - - long ret; - asm volatile ("syscall" : "=a" (ret) : "a" (__NR_write), - "D" (fd), "S" (data), "d" (len) : - "cc", "memory", "rcx", - "r8", "r9", "r10", "r11" ); - return ret; -} - -static inline void linux_exit(int code) -{ - asm volatile ("syscall" : : "a" (__NR_exit), "D" (code)); -} - -void to_base10(char *lastdig, uint64_t n) -{ - while (n) { - *lastdig = (n % 10) + '0'; - n /= 10; - lastdig--; - } -} - -__attribute__((externally_visible)) void c_main(void **stack) -{ - /* Parse the stack */ - long argc = (long)*stack; - stack += argc + 2; - - /* Now we're pointing at the environment. Skip it. */ - while(*stack) - stack++; - stack++; - - /* Now we're pointing at auxv. Initialize the vDSO parser. */ - vdso_init_from_auxv((void *)stack); - - /* Find gettimeofday. */ - typedef long (*gtod_t)(struct timeval *tv, struct timezone *tz); - gtod_t gtod = (gtod_t)vdso_sym("LINUX_2.6", "__vdso_gettimeofday"); - - if (!gtod) - linux_exit(1); - - struct timeval tv; - long ret = gtod(&tv, 0); - - if (ret == 0) { - char buf[] = "The time is .000000\n"; - to_base10(buf + 31, tv.tv_sec); - to_base10(buf + 38, tv.tv_usec); - linux_write(1, buf, sizeof(buf) - 1); - } else { - linux_exit(ret); - } - - linux_exit(0); -} - -/* - * This is the real entry point. It passes the initial stack into - * the C entry point. - */ -asm ( - ".text\n" - ".global _start\n" - ".type _start,@function\n" - "_start:\n\t" - "mov %rsp,%rdi\n\t" - "jmp c_main" - ); -- cgit v1.1 From 4ebbefd6b93c34d6da0d950b1d2e0dcca2f1e6ef Mon Sep 17 00:00:00 2001 From: Andy Lutomirski Date: Thu, 12 Jun 2014 17:53:10 -0700 Subject: x86/vdso/doc: Make vDSO examples more portable This adds a new vdso_test.c that's written entirely in C. It also makes all of the vDSO examples work on 32-bit x86. Cc: Stefani Seibold Signed-off-by: Andy Lutomirski Link: http://lkml.kernel.org/r/62b701fc44b79f118ac2b2d64d19965fc5c291fb.1402620737.git.luto@amacapital.net Signed-off-by: H. Peter Anvin --- Documentation/vDSO/parse_vdso.c | 67 ++++++++++++++++----------- Documentation/vDSO/vdso_standalone_test_x86.c | 45 ++++++++++++------ Documentation/vDSO/vdso_test.c | 52 +++++++++++++++++++++ 3 files changed, 123 insertions(+), 41 deletions(-) create mode 100644 Documentation/vDSO/vdso_test.c (limited to 'Documentation') diff --git a/Documentation/vDSO/parse_vdso.c b/Documentation/vDSO/parse_vdso.c index 8587020..1dbb4b8 100644 --- a/Documentation/vDSO/parse_vdso.c +++ b/Documentation/vDSO/parse_vdso.c @@ -1,6 +1,6 @@ /* * parse_vdso.c: Linux reference vDSO parser - * Written by Andrew Lutomirski, 2011. + * Written by Andrew Lutomirski, 2011-2014. * * This code is meant to be linked in to various programs that run on Linux. * As such, it is available with as few restrictions as possible. This file @@ -11,13 +11,14 @@ * it starts a program. It works equally well in statically and dynamically * linked binaries. * - * This code is tested on x86_64. In principle it should work on any 64-bit + * This code is tested on x86. In principle it should work on any * architecture that has a vDSO. */ #include #include #include +#include #include /* @@ -45,11 +46,18 @@ extern void *vdso_sym(const char *version, const char *name); /* And here's the code. */ - -#ifndef __x86_64__ -# error Not yet ported to non-x86_64 architectures +#ifndef ELF_BITS +# if ULONG_MAX > 0xffffffffUL +# define ELF_BITS 64 +# else +# define ELF_BITS 32 +# endif #endif +#define ELF_BITS_XFORM2(bits, x) Elf##bits##_##x +#define ELF_BITS_XFORM(bits, x) ELF_BITS_XFORM2(bits, x) +#define ELF(x) ELF_BITS_XFORM(ELF_BITS, x) + static struct vdso_info { bool valid; @@ -59,14 +67,14 @@ static struct vdso_info uintptr_t load_offset; /* load_addr - recorded vaddr */ /* Symbol table */ - Elf64_Sym *symtab; + ELF(Sym) *symtab; const char *symstrings; - Elf64_Word *bucket, *chain; - Elf64_Word nbucket, nchain; + ELF(Word) *bucket, *chain; + ELF(Word) nbucket, nchain; /* Version table */ - Elf64_Versym *versym; - Elf64_Verdef *verdef; + ELF(Versym) *versym; + ELF(Verdef) *verdef; } vdso_info; /* Straight from the ELF specification. */ @@ -92,9 +100,14 @@ void vdso_init_from_sysinfo_ehdr(uintptr_t base) vdso_info.load_addr = base; - Elf64_Ehdr *hdr = (Elf64_Ehdr*)base; - Elf64_Phdr *pt = (Elf64_Phdr*)(vdso_info.load_addr + hdr->e_phoff); - Elf64_Dyn *dyn = 0; + ELF(Ehdr) *hdr = (ELF(Ehdr)*)base; + if (hdr->e_ident[EI_CLASS] != + (ELF_BITS == 32 ? ELFCLASS32 : ELFCLASS64)) { + return; /* Wrong ELF class -- check ELF_BITS */ + } + + ELF(Phdr) *pt = (ELF(Phdr)*)(vdso_info.load_addr + hdr->e_phoff); + ELF(Dyn) *dyn = 0; /* * We need two things from the segment table: the load offset @@ -108,7 +121,7 @@ void vdso_init_from_sysinfo_ehdr(uintptr_t base) + (uintptr_t)pt[i].p_offset - (uintptr_t)pt[i].p_vaddr; } else if (pt[i].p_type == PT_DYNAMIC) { - dyn = (Elf64_Dyn*)(base + pt[i].p_offset); + dyn = (ELF(Dyn)*)(base + pt[i].p_offset); } } @@ -118,7 +131,7 @@ void vdso_init_from_sysinfo_ehdr(uintptr_t base) /* * Fish out the useful bits of the dynamic table. */ - Elf64_Word *hash = 0; + ELF(Word) *hash = 0; vdso_info.symstrings = 0; vdso_info.symtab = 0; vdso_info.versym = 0; @@ -131,22 +144,22 @@ void vdso_init_from_sysinfo_ehdr(uintptr_t base) + vdso_info.load_offset); break; case DT_SYMTAB: - vdso_info.symtab = (Elf64_Sym *) + vdso_info.symtab = (ELF(Sym) *) ((uintptr_t)dyn[i].d_un.d_ptr + vdso_info.load_offset); break; case DT_HASH: - hash = (Elf64_Word *) + hash = (ELF(Word) *) ((uintptr_t)dyn[i].d_un.d_ptr + vdso_info.load_offset); break; case DT_VERSYM: - vdso_info.versym = (Elf64_Versym *) + vdso_info.versym = (ELF(Versym) *) ((uintptr_t)dyn[i].d_un.d_ptr + vdso_info.load_offset); break; case DT_VERDEF: - vdso_info.verdef = (Elf64_Verdef *) + vdso_info.verdef = (ELF(Verdef) *) ((uintptr_t)dyn[i].d_un.d_ptr + vdso_info.load_offset); break; @@ -168,8 +181,8 @@ void vdso_init_from_sysinfo_ehdr(uintptr_t base) vdso_info.valid = true; } -static bool vdso_match_version(Elf64_Versym ver, - const char *name, Elf64_Word hash) +static bool vdso_match_version(ELF(Versym) ver, + const char *name, ELF(Word) hash) { /* * This is a helper function to check if the version indexed by @@ -188,7 +201,7 @@ static bool vdso_match_version(Elf64_Versym ver, /* First step: find the version definition */ ver &= 0x7fff; /* Apparently bit 15 means "hidden" */ - Elf64_Verdef *def = vdso_info.verdef; + ELF(Verdef) *def = vdso_info.verdef; while(true) { if ((def->vd_flags & VER_FLG_BASE) == 0 && (def->vd_ndx & 0x7fff) == ver) @@ -197,11 +210,11 @@ static bool vdso_match_version(Elf64_Versym ver, if (def->vd_next == 0) return false; /* No definition. */ - def = (Elf64_Verdef *)((char *)def + def->vd_next); + def = (ELF(Verdef) *)((char *)def + def->vd_next); } /* Now figure out whether it matches. */ - Elf64_Verdaux *aux = (Elf64_Verdaux*)((char *)def + def->vd_aux); + ELF(Verdaux) *aux = (ELF(Verdaux)*)((char *)def + def->vd_aux); return def->vd_hash == hash && !strcmp(name, vdso_info.symstrings + aux->vda_name); } @@ -213,10 +226,10 @@ void *vdso_sym(const char *version, const char *name) return 0; ver_hash = elf_hash(version); - Elf64_Word chain = vdso_info.bucket[elf_hash(name) % vdso_info.nbucket]; + ELF(Word) chain = vdso_info.bucket[elf_hash(name) % vdso_info.nbucket]; for (; chain != STN_UNDEF; chain = vdso_info.chain[chain]) { - Elf64_Sym *sym = &vdso_info.symtab[chain]; + ELF(Sym) *sym = &vdso_info.symtab[chain]; /* Check for a defined global or weak function w/ right name. */ if (ELF64_ST_TYPE(sym->st_info) != STT_FUNC) @@ -243,7 +256,7 @@ void *vdso_sym(const char *version, const char *name) void vdso_init_from_auxv(void *auxv) { - Elf64_auxv_t *elf_auxv = auxv; + ELF(auxv_t) *elf_auxv = auxv; for (int i = 0; elf_auxv[i].a_type != AT_NULL; i++) { if (elf_auxv[i].a_type == AT_SYSINFO_EHDR) { diff --git a/Documentation/vDSO/vdso_standalone_test_x86.c b/Documentation/vDSO/vdso_standalone_test_x86.c index 1523f5d..d462402 100644 --- a/Documentation/vDSO/vdso_standalone_test_x86.c +++ b/Documentation/vDSO/vdso_standalone_test_x86.c @@ -1,13 +1,14 @@ /* - * vdso_test.c: Sample code to test parse_vdso.c on x86_64 - * Copyright (c) 2011 Andy Lutomirski + * vdso_test.c: Sample code to test parse_vdso.c on x86 + * Copyright (c) 2011-2014 Andy Lutomirski * Subject to the GNU General Public License, version 2 * * You can amuse yourself by compiling with: * gcc -std=gnu99 -nostdlib - * -Os -fno-asynchronous-unwind-tables -flto + * -Os -fno-asynchronous-unwind-tables -flto -lgcc_s * vdso_standalone_test_x86.c parse_vdso.c - * to generate a small binary with no dependencies at all. + * to generate a small binary. On x86_64, you can omit -lgcc_s + * if you want the binary to be completely standalone. */ #include @@ -35,21 +36,31 @@ int strcmp(const char *a, const char *b) return 0; } -/* ...and two syscalls. This is x86_64-specific. */ -static inline long linux_write(int fd, const void *data, size_t len) +/* ...and two syscalls. This is x86-specific. */ +static inline long x86_syscall3(long nr, long a0, long a1, long a2) { - long ret; - asm volatile ("syscall" : "=a" (ret) : "a" (__NR_write), - "D" (fd), "S" (data), "d" (len) : +#ifdef __x86_64__ + asm volatile ("syscall" : "=a" (ret) : "a" (nr), + "D" (a0), "S" (a1), "d" (a2) : "cc", "memory", "rcx", "r8", "r9", "r10", "r11" ); +#else + asm volatile ("int $0x80" : "=a" (ret) : "a" (nr), + "b" (a0), "c" (a1), "d" (a2) : + "cc", "memory" ); +#endif return ret; } +static inline long linux_write(int fd, const void *data, size_t len) +{ + return x86_syscall3(__NR_write, fd, (long)data, (long)len); +} + static inline void linux_exit(int code) { - asm volatile ("syscall" : : "a" (__NR_exit), "D" (code)); + x86_syscall3(__NR_exit, code, 0, 0); } void to_base10(char *lastdig, uint64_t n) @@ -104,8 +115,14 @@ __attribute__((externally_visible)) void c_main(void **stack) asm ( ".text\n" ".global _start\n" - ".type _start,@function\n" - "_start:\n\t" - "mov %rsp,%rdi\n\t" - "jmp c_main" + ".type _start,@function\n" + "_start:\n\t" +#ifdef __x86_64__ + "mov %rsp,%rdi\n\t" + "jmp c_main" +#else + "push %esp\n\t" + "call c_main\n\t" + "int $3" +#endif ); diff --git a/Documentation/vDSO/vdso_test.c b/Documentation/vDSO/vdso_test.c new file mode 100644 index 0000000..8daeb7d7 --- /dev/null +++ b/Documentation/vDSO/vdso_test.c @@ -0,0 +1,52 @@ +/* + * vdso_test.c: Sample code to test parse_vdso.c + * Copyright (c) 2014 Andy Lutomirski + * Subject to the GNU General Public License, version 2 + * + * Compile with: + * gcc -std=gnu99 vdso_test.c parse_vdso.c + * + * Tested on x86, 32-bit and 64-bit. It may work on other architectures, too. + */ + +#include +#include +#include +#include +#include + +extern void *vdso_sym(const char *version, const char *name); +extern void vdso_init_from_sysinfo_ehdr(uintptr_t base); +extern void vdso_init_from_auxv(void *auxv); + +int main(int argc, char **argv) +{ + unsigned long sysinfo_ehdr = getauxval(AT_SYSINFO_EHDR); + if (!sysinfo_ehdr) { + printf("AT_SYSINFO_EHDR is not present!\n"); + return 0; + } + + vdso_init_from_sysinfo_ehdr(getauxval(AT_SYSINFO_EHDR)); + + /* Find gettimeofday. */ + typedef long (*gtod_t)(struct timeval *tv, struct timezone *tz); + gtod_t gtod = (gtod_t)vdso_sym("LINUX_2.6", "__vdso_gettimeofday"); + + if (!gtod) { + printf("Could not find __vdso_gettimeofday\n"); + return 1; + } + + struct timeval tv; + long ret = gtod(&tv, 0); + + if (ret == 0) { + printf("The time is %lld.%06lld\n", + (long long)tv.tv_sec, (long long)tv.tv_usec); + } else { + printf("__vdso_gettimeofday failed\n"); + } + + return 0; +} -- cgit v1.1 From a6e15a39048ec3229b9a53425f4384f55f6cc1b3 Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Fri, 13 Jun 2014 13:30:35 -0700 Subject: PM / hibernate: introduce "nohibernate" boot parameter To support using kernel features that are not compatible with hibernation, this creates the "nohibernate" kernel boot parameter to disable both hibernation and resume. This allows hibernation support to be a boot-time choice instead of only a compile-time choice. Signed-off-by: Kees Cook Acked-by: Pavel Machek Signed-off-by: Rafael J. Wysocki --- Documentation/kernel-parameters.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 6eaa9cd..f8f0466 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2184,6 +2184,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. in certain environments such as networked servers or real-time systems. + nohibernate [HIBERNATION] Disable hibernation and resume. + nohz= [KNL] Boottime enable/disable dynamic ticks Valid arguments: on, off Default: on @@ -2980,6 +2982,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. noresume Don't check if there's a hibernation image present during boot. nocompress Don't compress/decompress hibernation images. + no Disable hibernation and resume. retain_initrd [RAM] Keep initrd memory after extraction -- cgit v1.1 From 24f2e0273f80ec262a772059e140a0adef35296d Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Fri, 13 Jun 2014 13:30:36 -0700 Subject: x86, kaslr: boot-time selectable with hibernation Changes kASLR from being compile-time selectable (blocked by CONFIG_HIBERNATION), to being boot-time selectable (with hibernation available by default) via the "kaslr" kernel command line. Signed-off-by: Kees Cook Acked-by: Pavel Machek Signed-off-by: Rafael J. Wysocki --- Documentation/kernel-parameters.txt | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index f8f0466..8849049 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1474,6 +1474,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted. js= [HW,JOY] Analog joystick See Documentation/input/joystick.txt. + kaslr/nokaslr [X86] + Enable/disable kernel and module base offset ASLR + (Address Space Layout Randomization) if built into + the kernel. When CONFIG_HIBERNATION is selected, + kASLR is disabled by default. When kASLR is enabled, + hibernation will be disabled. + keepinitrd [HW,ARM] kernelcore=nn[KMG] [KNL,X86,IA-64,PPC] This parameter @@ -2110,10 +2117,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted. noapic [SMP,APIC] Tells the kernel to not make use of any IOAPICs that may be present in the system. - nokaslr [X86] - Disable kernel and module base offset ASLR (Address - Space Layout Randomization) if built into the kernel. - noautogroup Disable scheduler automatic task group creation. nobats [PPC] Do not use BATs for mapping kernel lowmem -- cgit v1.1 From 42e1358e103de0fe07d3e8ff40c16bb1fa844e26 Mon Sep 17 00:00:00 2001 From: Christian Riesch Date: Mon, 16 Jun 2014 14:46:45 +0200 Subject: ptp: In the testptp utility, use clock_adjtime from glibc when available clock_adjtime was included in glibc 2.14. _GNU_SOURCE must be defined to make it available. Signed-off-by: Christian Riesch Cc: Richard Cochran Acked-by: Richard Cochran Signed-off-by: David S. Miller --- Documentation/ptp/testptp.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ptp/testptp.c b/Documentation/ptp/testptp.c index f1ac2dae..ba1d502 100644 --- a/Documentation/ptp/testptp.c +++ b/Documentation/ptp/testptp.c @@ -17,6 +17,7 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ +#define _GNU_SOURCE #include #include #include @@ -46,12 +47,14 @@ #define CLOCK_INVALID -1 #endif -/* When glibc offers the syscall, this will go away. */ +/* clock_adjtime is not available in GLIBC < 2.14 */ +#if !__GLIBC_PREREQ(2, 14) #include static int clock_adjtime(clockid_t id, struct timex *tx) { return syscall(__NR_clock_adjtime, id, tx); } +#endif static clockid_t get_clockid(int fd) { -- cgit v1.1 From 0946807ae669d388a813a083f1184053206b99c5 Mon Sep 17 00:00:00 2001 From: Martin Peres Date: Mon, 9 Jun 2014 20:38:36 +0200 Subject: drm/nouveau/doc: update the thermal documentation Changes: - Change the maintainer's address (the labri address will expire soon); - Drop the note about not all families supporting all fan modes; - Add a note about the reported RPM not being accurate when driven outside the vbios-defined PWM range. Signed-off-by: Martin Peres Signed-off-by: Ben Skeggs --- Documentation/thermal/nouveau_thermal | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/thermal/nouveau_thermal b/Documentation/thermal/nouveau_thermal index efceb78..60bc293 100644 --- a/Documentation/thermal/nouveau_thermal +++ b/Documentation/thermal/nouveau_thermal @@ -4,7 +4,7 @@ Kernel driver nouveau Supported chips: * NV43+ -Authors: Martin Peres (mupuf) +Authors: Martin Peres (mupuf) Description --------- @@ -68,8 +68,9 @@ Your fan can be driven in different modes: NOTE: Be sure to use the manual mode if you want to drive the fan speed manually -NOTE2: Not all fan management modes may be supported on all chipsets. We are -working on it. +NOTE2: When operating in manual mode outside the vbios-defined +[PWM_min, PWM_max] range, the reported fan speed (RPM) may not be accurate +depending on your hardware. Bug reports --------- -- cgit v1.1 From a981296f048b99b0d5bb4d87c732a6cfb35a1c66 Mon Sep 17 00:00:00 2001 From: Michal Marek Date: Wed, 18 Jun 2014 17:15:17 +0200 Subject: Documentation: Fix DocBook build with relative $(srctree) After commits 890676c6 (kbuild: Use relative path when building in the source tree) and 9da0763b (kbuild: Use relative path when building in a subdir of the source tree), the $(srctree) variable can be a relative path. This breaks Documentation/DocBook/media/Makefile, because it tries to create symlinks from a subdirectory of the object tree to the source tree. Fix this by using a full path in this case. Reported-by: Randy Dunlap Acked-by: Randy Dunlap Tested-by: Randy Dunlap Signed-off-by: Michal Marek --- Documentation/DocBook/media/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/Makefile b/Documentation/DocBook/media/Makefile index 1d27f0a..639e748 100644 --- a/Documentation/DocBook/media/Makefile +++ b/Documentation/DocBook/media/Makefile @@ -202,8 +202,8 @@ $(MEDIA_OBJ_DIR)/%: $(MEDIA_SRC_DIR)/%.b64 $(MEDIA_OBJ_DIR)/v4l2.xml: $(OBJIMGFILES) @$($(quiet)gen_xml) - @(ln -sf $(MEDIA_SRC_DIR)/v4l/*xml $(MEDIA_OBJ_DIR)/) - @(ln -sf $(MEDIA_SRC_DIR)/dvb/*xml $(MEDIA_OBJ_DIR)/) + @(ln -sf `cd $(MEDIA_SRC_DIR) && /bin/pwd`/v4l/*xml $(MEDIA_OBJ_DIR)/) + @(ln -sf `cd $(MEDIA_SRC_DIR) && /bin/pwd`/dvb/*xml $(MEDIA_OBJ_DIR)/) $(MEDIA_OBJ_DIR)/videodev2.h.xml: $(srctree)/include/uapi/linux/videodev2.h $(MEDIA_OBJ_DIR)/v4l2.xml @$($(quiet)gen_xml) -- cgit v1.1 From c14105628b2e2eee04b2d6950e068eeddf49f2f1 Mon Sep 17 00:00:00 2001 From: Masahiro Yamada Date: Tue, 10 Jun 2014 16:36:14 +0900 Subject: kbuild: fix a typo in a kbuild document Signed-off-by: Masahiro Yamada Signed-off-by: Michal Marek --- Documentation/kbuild/makefiles.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index d567a7c..c600e2f 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -1171,7 +1171,7 @@ When kbuild executes, the following steps are followed (roughly): obvious reason. dtc - Create flattend device tree blob object suitable for linking + Create flattened device tree blob object suitable for linking into vmlinux. Device tree blobs linked into vmlinux are placed in an init section in the image. Platform code *must* copy the blob to non-init memory prior to calling unflatten_device_tree(). -- cgit v1.1 From 4a8573abe965115bc5b064401fd669b74e985258 Mon Sep 17 00:00:00 2001 From: Andy Gross Date: Thu, 12 Jun 2014 14:34:10 -0500 Subject: spi: qup: Remove chip select function This patch removes the chip select function. Chip select should instead be supported using GPIOs, defining the DT entry "cs-gpios", and letting the SPI core assert/deassert the chip select as it sees fit. The chip select control inside the controller is buggy. It is supposed to automatically assert the chip select based on the activity in the controller, but it is buggy and doesn't work at all. So instead we elect to use GPIOs. Signed-off-by: Andy Gross Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/qcom,spi-qup.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt b/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt index b82a268..bee6ff2 100644 --- a/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt +++ b/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt @@ -23,6 +23,12 @@ Optional properties: - spi-max-frequency: Specifies maximum SPI clock frequency, Units - Hz. Definition as per Documentation/devicetree/bindings/spi/spi-bus.txt +- num-cs: total number of chipselects +- cs-gpios: should specify GPIOs used for chipselects. + The gpios will be referred to as reg = in the SPI child + nodes. If unspecified, a single SPI device without a chip + select can be used. + SPI slave nodes must be children of the SPI master node and can contain properties described in Documentation/devicetree/bindings/spi/spi-bus.txt -- cgit v1.1 From 4a81e8328d3791a4f99bf5b436d050f6dc5ffea3 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Fri, 20 Jun 2014 16:49:01 -0700 Subject: rcu: Reduce overhead of cond_resched() checks for RCU Commit ac1bea85781e (Make cond_resched() report RCU quiescent states) fixed a problem where a CPU looping in the kernel with but one runnable task would give RCU CPU stall warnings, even if the in-kernel loop contained cond_resched() calls. Unfortunately, in so doing, it introduced performance regressions in Anton Blanchard's will-it-scale "open1" test. The problem appears to be not so much the increased cond_resched() path length as an increase in the rate at which grace periods complete, which increased per-update grace-period overhead. This commit takes a different approach to fixing this bug, mainly by moving the RCU-visible quiescent state from cond_resched() to rcu_note_context_switch(), and by further reducing the check to a simple non-zero test of a single per-CPU variable. However, this approach requires that the force-quiescent-state processing send resched IPIs to the offending CPUs. These will be sent only once the grace period has reached an age specified by the boot/sysfs parameter rcutree.jiffies_till_sched_qs, or once the grace period reaches an age halfway to the point at which RCU CPU stall warnings will be emitted, whichever comes first. Reported-by: Dave Hansen Signed-off-by: Paul E. McKenney Cc: Andi Kleen Cc: Christoph Lameter Cc: Mike Galbraith Cc: Eric Dumazet Reviewed-by: Josh Triplett [ paulmck: Made rcu_momentary_dyntick_idle() as suggested by the ktest build robot. Also fixed smp_mb() comment as noted by Oleg Nesterov. ] Merge with e552592e (Reduce overhead of cond_resched() checks for RCU) Signed-off-by: Paul E. McKenney --- Documentation/kernel-parameters.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 6eaa9cd..910c382 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2785,6 +2785,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted. leaf rcu_node structure. Useful for very large systems. + rcutree.jiffies_till_sched_qs= [KNL] + Set required age in jiffies for a + given grace period before RCU starts + soliciting quiescent-state help from + rcu_note_context_switch(). + rcutree.jiffies_till_first_fqs= [KNL] Set delay from grace-period initialization to first attempt to force quiescent states. -- cgit v1.1 From 7cdb0d25bc93e936edbfde12fe277ee21b88c1ef Mon Sep 17 00:00:00 2001 From: David Rientjes Date: Mon, 23 Jun 2014 13:22:03 -0700 Subject: mm, hotplug: probe interface is available on several platforms Documentation/memory-hotplug.txt incorrectly states that the memory driver "probe" interface is only supported on powerpc and is vague about its application on x86. Clarify the platforms that make this interface available if memory hotplug is enabled. Signed-off-by: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/memory-hotplug.txt | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt index f304edb..45134dc 100644 --- a/Documentation/memory-hotplug.txt +++ b/Documentation/memory-hotplug.txt @@ -209,15 +209,12 @@ If memory device is found, memory hotplug code will be called. 4.2 Notify memory hot-add event by hand ------------ -On powerpc, the firmware does not notify a memory hotplug event to the kernel. -Therefore, "probe" interface is supported to notify the event to the kernel. -This interface depends on CONFIG_ARCH_MEMORY_PROBE. - -CONFIG_ARCH_MEMORY_PROBE is supported on powerpc only. On x86, this config -option is disabled by default since ACPI notifies a memory hotplug event to -the kernel, which performs its hotplug operation as the result. Please -enable this option if you need the "probe" interface for testing purposes -on x86. +On some architectures, the firmware may not notify the kernel of a memory +hotplug event. Therefore, the memory "probe" interface is supported to +explicitly notify the kernel. This interface depends on +CONFIG_ARCH_MEMORY_PROBE and can be configured on powerpc, sh, and x86 +if hotplug is supported, although for x86 this should be handled by ACPI +notification. Probe interface is located at /sys/devices/system/memory/probe -- cgit v1.1 From 7cd2b0a34ab8e4db971920eef8982f985441adfb Mon Sep 17 00:00:00 2001 From: David Rientjes Date: Mon, 23 Jun 2014 13:22:04 -0700 Subject: mm, pcp: allow restoring percpu_pagelist_fraction default Oleg reports a division by zero error on zero-length write() to the percpu_pagelist_fraction sysctl: divide error: 0000 [#1] SMP DEBUG_PAGEALLOC CPU: 1 PID: 9142 Comm: badarea_io Not tainted 3.15.0-rc2-vm-nfs+ #19 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 task: ffff8800d5aeb6e0 ti: ffff8800d87a2000 task.ti: ffff8800d87a2000 RIP: 0010: percpu_pagelist_fraction_sysctl_handler+0x84/0x120 RSP: 0018:ffff8800d87a3e78 EFLAGS: 00010246 RAX: 0000000000000f89 RBX: ffff88011f7fd000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000010 RBP: ffff8800d87a3e98 R08: ffffffff81d002c8 R09: ffff8800d87a3f50 R10: 000000000000000b R11: 0000000000000246 R12: 0000000000000060 R13: ffffffff81c3c3e0 R14: ffffffff81cfddf8 R15: ffff8801193b0800 FS: 00007f614f1e9740(0000) GS:ffff88011f440000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007f614f1fa000 CR3: 00000000d9291000 CR4: 00000000000006e0 Call Trace: proc_sys_call_handler+0xb3/0xc0 proc_sys_write+0x14/0x20 vfs_write+0xba/0x1e0 SyS_write+0x46/0xb0 tracesys+0xe1/0xe6 However, if the percpu_pagelist_fraction sysctl is set by the user, it is also impossible to restore it to the kernel default since the user cannot write 0 to the sysctl. This patch allows the user to write 0 to restore the default behavior. It still requires a fraction equal to or larger than 8, however, as stated by the documentation for sanity. If a value in the range [1, 7] is written, the sysctl will return EINVAL. This successfully solves the divide by zero issue at the same time. Signed-off-by: David Rientjes Reported-by: Oleg Drokin Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/sysctl/vm.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index bd4b34c..4415aa9 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -702,7 +702,8 @@ The batch value of each per cpu pagelist is also updated as a result. It is set to pcp->high/4. The upper limit of batch is (PAGE_SHIFT * 8) The initial value is zero. Kernel does not use this value at boot time to set -the high water marks for each per cpu page list. +the high water marks for each per cpu page list. If the user writes '0' to this +sysctl, it will revert to this default behavior. ============================================================== -- cgit v1.1 From 88e15ce402c58f41037752da092683e90826742a Mon Sep 17 00:00:00 2001 From: Rickard Strandqvist Date: Mon, 23 Jun 2014 13:22:04 -0700 Subject: Documentation/accounting/getdelays.c: add missing null-terminate after strncpy call Added a guaranteed null-terminate after call to strncpy. This was partly found using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist Acked-by: Kees Cook Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/accounting/getdelays.c | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c index c6a06b7..f405780 100644 --- a/Documentation/accounting/getdelays.c +++ b/Documentation/accounting/getdelays.c @@ -314,6 +314,7 @@ int main(int argc, char *argv[]) break; case 'm': strncpy(cpumask, optarg, sizeof(cpumask)); + cpumask[sizeof(cpumask) - 1] = '\0'; maskset = 1; printf("cpumask %s maskset %d\n", cpumask, maskset); break; -- cgit v1.1 From ed235875e2ca983197831337a986f0517074e1a0 Mon Sep 17 00:00:00 2001 From: Aaron Tomlin Date: Mon, 23 Jun 2014 13:22:05 -0700 Subject: kernel/watchdog.c: print traces for all cpus on lockup detection A 'softlockup' is defined as a bug that causes the kernel to loop in kernel mode for more than a predefined period to time, without giving other tasks a chance to run. Currently, upon detection of this condition by the per-cpu watchdog task, debug information (including a stack trace) is sent to the system log. On some occasions, we have observed that the "victim" rather than the actual "culprit" (i.e. the owner/holder of the contended resource) is reported to the user. Often this information has proven to be insufficient to assist debugging efforts. To avoid loss of useful debug information, for architectures which support NMI, this patch makes it possible to improve soft lockup reporting. This is accomplished by issuing an NMI to each cpu to obtain a stack trace. If NMI is not supported we just revert back to the old method. A sysctl and boot-time parameter is available to toggle this feature. [dzickus@redhat.com: add CONFIG_SMP in certain areas] [akpm@linux-foundation.org: additional CONFIG_SMP=n optimisations] [mq@suse.cz: fix warning] Signed-off-by: Aaron Tomlin Signed-off-by: Don Zickus Cc: David S. Miller Cc: Mateusz Guzik Cc: Oleg Nesterov Signed-off-by: Jan Moskyto Matejka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/kernel-parameters.txt | 5 +++++ Documentation/sysctl/kernel.txt | 17 +++++++++++++++++ 2 files changed, 22 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 8849049..c1b9aa8 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -3130,6 +3130,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. [KNL] Should the soft-lockup detector generate panics. Format: + softlockup_all_cpu_backtrace= + [KNL] Should the soft-lockup detector generate + backtraces on all cpus. + Format: + sonypi.*= [HW] Sony Programmable I/O Control Device driver See Documentation/laptops/sonypi.txt diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index 708bb7f..c14374e 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -75,6 +75,7 @@ show up in /proc/sys/kernel: - shmall - shmmax [ sysv ipc ] - shmmni +- softlockup_all_cpu_backtrace - stop-a [ SPARC only ] - sysrq ==> Documentation/sysrq.txt - sysctl_writes_strict @@ -783,6 +784,22 @@ via the /proc/sys interface: ============================================================== +softlockup_all_cpu_backtrace: + +This value controls the soft lockup detector thread's behavior +when a soft lockup condition is detected as to whether or not +to gather further debug information. If enabled, each cpu will +be issued an NMI and instructed to capture stack trace. + +This feature is only applicable for architectures which support +NMI. + +0: do nothing. This is the default behavior. + +1: on detection capture more debug information. + +============================================================== + tainted: Non-zero if the kernel has been tainted. Numeric values, which -- cgit v1.1 From 8dbdb8e704db34085f5978c335c10256b0fb9629 Mon Sep 17 00:00:00 2001 From: Gregory CLEMENT Date: Mon, 23 Jun 2014 16:16:51 +0200 Subject: ARM: mvebu: Fix the improper use of the compatible string armada38x using a wildcard Wildcards in compatible strings should be avoid. "marvell,armada38x" was recently introduced but was not yet used. The armada 385 SoC is a superset of the armada 380 SoC (with more CPUs and more PCIe slots). So this patch replaces the use of "marvell,armada38x" by the "marvell,armada380" string. Signed-off-by: Gregory CLEMENT Link: https://lkml.kernel.org/r/1403533011-21339-1-git-send-email-gregory.clement@free-electrons.com Acked-by: Andrew Lunn Cc: # v3.15+ Signed-off-by: Jason Cooper --- Documentation/devicetree/bindings/arm/armada-38x.txt | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/armada-38x.txt b/Documentation/devicetree/bindings/arm/armada-38x.txt index 11f2330..ad9f8ed 100644 --- a/Documentation/devicetree/bindings/arm/armada-38x.txt +++ b/Documentation/devicetree/bindings/arm/armada-38x.txt @@ -6,5 +6,15 @@ following property: Required root node property: - - compatible: must contain either "marvell,armada380" or - "marvell,armada385" depending on the variant of the SoC being used. + - compatible: must contain "marvell,armada380" + +In addition, boards using the Marvell Armada 385 SoC shall have the +following property before the previous one: + +Required root node property: + +compatible: must contain "marvell,armada385" + +Example: + +compatible = "marvell,a385-rd", "marvell,armada385", "marvell,armada380"; -- cgit v1.1 From eab2014421fee297e769d1e464875cbb73a36c2f Mon Sep 17 00:00:00 2001 From: Naveen Krishna Chatradhi Date: Wed, 25 Jun 2014 11:59:30 +0530 Subject: devicetree: bindings: Document murata vendor prefix Add Murata Manufacturing Co., Ltd. to the list of device tree vendor prefixes. Murata manufactures NTC (Negative Temperature Coefficient) based Thermistors for small scale applications like Mobiles and PDAs. Signed-off-by: Naveen Krishna Chatradhi Acked-by: Mark Rutland Signed-off-by: Guenter Roeck --- 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 4d7f375..46a311e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -83,6 +83,7 @@ mosaixtech Mosaix Technologies, Inc. moxa Moxa mpl MPL AG mundoreader Mundo Reader S.L. +murata Murata Manufacturing Co., Ltd. mxicy Macronix International Co., Ltd. national National Semiconductor neonode Neonode Inc. -- cgit v1.1 From 8b6f5e0f19c3a28383a318edc4493875ae1d53dd Mon Sep 17 00:00:00 2001 From: Naveen Krishna Chatradhi Date: Wed, 25 Jun 2014 11:59:31 +0530 Subject: hwmon: (ntc_thermistor) Use the manufacturer name properly Murata Manufacturing Co., Ltd is the vendor for NTC (Negative Temperature coefficient) based Thermistors. But, the driver extensively uses "NTC" as the vendor name. This patch corrects the vendor name also updates the compatibility strings according to the vendor-prefix.txt Note: Drivers continue to support the previous compatible strings but further addition of these compatible strings in device tree is deprecated. Signed-off-by: Naveen Krishna Chatradhi Reviewed-by: Javier Martinez Canillas Signed-off-by: Guenter Roeck --- .../devicetree/bindings/arm/samsung/exynos-adc.txt | 2 +- .../devicetree/bindings/hwmon/ntc_thermistor.txt | 20 ++++++++++++++------ Documentation/hwmon/ntc_thermistor | 8 ++++---- 3 files changed, 19 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt index 5d49f2b..832fe8c 100644 --- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt @@ -48,7 +48,7 @@ adc@12D10000 { /* NTC thermistor is a hwmon device */ ncp15wb473@0 { - compatible = "ntc,ncp15wb473"; + compatible = "murata,ncp15wb473"; pullup-uv = <1800000>; pullup-ohm = <47000>; pulldown-ohm = <0>; diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt index c6f6667..b117b2e 100644 --- a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt +++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt @@ -3,11 +3,19 @@ NTC Thermistor hwmon sensors Requires node properties: - "compatible" value : one of - "ntc,ncp15wb473" - "ntc,ncp18wb473" - "ntc,ncp21wb473" - "ntc,ncp03wb473" - "ntc,ncp15wl333" + "murata,ncp15wb473" + "murata,ncp18wb473" + "murata,ncp21wb473" + "murata,ncp03wb473" + "murata,ncp15wl333" + +/* Usage of vendor name "ntc" is deprecated */ + "ntc,ncp15wb473" + "ntc,ncp18wb473" + "ntc,ncp21wb473" + "ntc,ncp03wb473" + "ntc,ncp15wl333" + - "pullup-uv" Pull up voltage in micro volts - "pullup-ohm" Pull up resistor value in ohms - "pulldown-ohm" Pull down resistor value in ohms @@ -21,7 +29,7 @@ Read more about iio bindings at Example: ncp15wb473@0 { - compatible = "ntc,ncp15wb473"; + compatible = "murata,ncp15wb473"; pullup-uv = <1800000>; pullup-ohm = <47000>; pulldown-ohm = <0>; diff --git a/Documentation/hwmon/ntc_thermistor b/Documentation/hwmon/ntc_thermistor index 3bfda94..057b770 100644 --- a/Documentation/hwmon/ntc_thermistor +++ b/Documentation/hwmon/ntc_thermistor @@ -1,7 +1,7 @@ Kernel driver ntc_thermistor ================= -Supported thermistors: +Supported thermistors from Murata: * Murata NTC Thermistors NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473, NCP15WL333 Prefixes: 'ncp15wb473', 'ncp18wb473', 'ncp21wb473', 'ncp03wb473', 'ncp15wl333' Datasheet: Publicly available at Murata @@ -15,9 +15,9 @@ Authors: Description ----------- -The NTC thermistor is a simple thermistor that requires users to provide the -resistance and lookup the corresponding compensation table to get the -temperature input. +The NTC (Negative Temperature Coefficient) thermistor is a simple thermistor +that requires users to provide the resistance and lookup the corresponding +compensation table to get the temperature input. The NTC driver provides lookup tables with a linear approximation function and four circuit models with an option not to use any of the four models. -- cgit v1.1 From 8b3dfdaf0c25a584cb31d04d2574115cf2d422ab Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Tue, 24 Jun 2014 13:55:25 +0200 Subject: ALSA: hda - Adjust speaker HPF and add LED support for HP Spectre 13 HP Spectre 13 has the IDT 92HD95 codec, and BIOS seems to set the default high-pass filter in some "safer" range, which results in the very soft tone from the built-in speakers in contrast to Windows. Also, the mute LED control is missing, since 92HD95 codec still has no HP-specific fixups for GPIO setups. This patch adds these missing features: the HPF is adjusted by the vendor-specific verb, and the LED is set up from a DMI string (but with the default polarity = 0 assumption due to the incomplete BIOS on the given machine). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=74841 Cc: Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 85c362d..d1ab5e1 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -286,6 +286,11 @@ STAC92HD83* hp-inv-led HP with broken BIOS for inverted mute LED auto BIOS setup (default) +STAC92HD95 +========== + hp-led LED support for HP laptops + hp-bass Bass HPF setup for HP Spectre 13 + STAC9872 ======== vaio VAIO laptop without SPDIF -- cgit v1.1 From 98ea2dba65932ffc456b6d7b11b8a0624e2f7b95 Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Fri, 13 Jun 2014 10:58:38 +0100 Subject: ARM: 8076/1: mm: add support for HW coherent systems in PL310 cache When a PL310 cache is used on a system that provides hardware coherency, the outer cache sync operation is useless, and can be skipped. Moreover, on some systems, it is harmful as it causes deadlocks between the Marvell coherency mechanism, the Marvell PCIe controller and the Cortex-A9. To avoid this, this commit introduces a new Device Tree property 'arm,io-coherent' for the L2 cache controller node, valid only for the PL310 cache. It identifies the usage of the PL310 cache in an I/O coherent configuration. Internally, it makes the driver disable the outer cache sync operation. Note that technically speaking, a fully coherent system wouldn't require any of the other .outer_cache operations. However, in practice, when booting secondary CPUs, these are not yet coherent, and therefore a set of cache maintenance operations are necessary at this point. This explains why we keep the other .outer_cache operations and only ->sync is disabled. While in theory any write to a PL310 register could cause the deadlock, in practice, disabling ->sync is sufficient to workaround the deadlock, since the other cache maintenance operations are only used in very specific situations. Contrary to previous versions of this patch, this new version does not simply NULL-ify the ->sync member, because the l2c_init_data structures are now 'const' and therefore cannot be modified, which is a good thing. Therefore, this patch introduces a separate l2c_init_data instance, called of_l2c310_coherent_data. Signed-off-by: Thomas Petazzoni 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 b513cb8..af527ee 100644 --- a/Documentation/devicetree/bindings/arm/l2cc.txt +++ b/Documentation/devicetree/bindings/arm/l2cc.txt @@ -40,6 +40,9 @@ Optional properties: - arm,filter-ranges : Starting address and length of window to filter. Addresses in the filter window are directed to the M1 port. Other addresses will go to the M0 port. +- arm,io-coherent : indicates that the system is operating in an hardware + I/O coherent mode. Valid only when the arm,pl310-cache compatible + string is used. - interrupts : 1 combined interrupt. - cache-id-part: cache id part number to be used if it is not present on hardware -- cgit v1.1 From 7d19e91b5220227814e9e875460c2c22c9660a5c Mon Sep 17 00:00:00 2001 From: Dan Carpenter Date: Fri, 27 Jun 2014 18:28:46 -0700 Subject: Documentation: add section about git to email-clients.txt These days most people use git to send patches so I have added a section about that. Signed-off-by: Dan Carpenter Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/email-clients.txt | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/email-clients.txt b/Documentation/email-clients.txt index 4e30eba..9af538be 100644 --- a/Documentation/email-clients.txt +++ b/Documentation/email-clients.txt @@ -1,6 +1,17 @@ Email clients info for Linux ====================================================================== +Git +---------------------------------------------------------------------- +These days most developers use `git send-email` instead of regular +email clients. The man page for this is quite good. On the receiving +end, maintainers use `git am` to apply the patches. + +If you are new to git then send your first patch to yourself. Save it +as raw text including all the headers. Run `git am raw_email.txt` and +then review the changelog with `git log`. When that works then send +the patch to the appropriate mailing list(s). + General Preferences ---------------------------------------------------------------------- Patches for the Linux kernel are submitted via email, preferably as -- cgit v1.1 From b27ebf77919fdc4e7f76b1972307c30c4a3c8859 Mon Sep 17 00:00:00 2001 From: Chen Yucong Date: Wed, 2 Jul 2014 15:22:36 -0700 Subject: mm:vmscan: update the trace-vmscan-postprocess.pl for event vmscan/mm_vmscan_lru_isolate When using trace-vmscan-postprocess.pl for checking the file/anon rate of scanning, we can find that it can not be performed. At the same time, the following message will be reported: WARNING: Format not as expected for event vmscan/mm_vmscan_lru_isolate 'file' != 'contig_taken' Fewer fields than expected in format at ./trace-vmscan-postprocess.pl line 171, line 76. In trace-vmscan-postprocess.pl, (contig_taken, contig_dirty, and contig_failed) are be associated respectively to (nr_lumpy_taken, nr_lumpy_dirty, and nr_lumpy_failed) for lumpy reclaim. Via commit c53919adc045 ("mm: vmscan: remove lumpy reclaim"), lumpy reclaim had already been removed by Mel, but the update for trace-vmscan-postprocess.pl was missed. Signed-off-by: Chen Yucong Cc: Mel Gorman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- .../trace/postprocess/trace-vmscan-postprocess.pl | 14 ++------------ 1 file changed, 2 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl index 00e425f..78c9a7b 100644 --- a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl +++ b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl @@ -47,7 +47,6 @@ use constant HIGH_KSWAPD_REWAKEUP => 21; use constant HIGH_NR_SCANNED => 22; use constant HIGH_NR_TAKEN => 23; use constant HIGH_NR_RECLAIMED => 24; -use constant HIGH_NR_CONTIG_DIRTY => 25; my %perprocesspid; my %perprocess; @@ -105,7 +104,7 @@ my $regex_direct_end_default = 'nr_reclaimed=([0-9]*)'; my $regex_kswapd_wake_default = 'nid=([0-9]*) order=([0-9]*)'; my $regex_kswapd_sleep_default = 'nid=([0-9]*)'; my $regex_wakeup_kswapd_default = 'nid=([0-9]*) zid=([0-9]*) order=([0-9]*)'; -my $regex_lru_isolate_default = 'isolate_mode=([0-9]*) order=([0-9]*) nr_requested=([0-9]*) nr_scanned=([0-9]*) nr_taken=([0-9]*) contig_taken=([0-9]*) contig_dirty=([0-9]*) contig_failed=([0-9]*)'; +my $regex_lru_isolate_default = 'isolate_mode=([0-9]*) order=([0-9]*) nr_requested=([0-9]*) nr_scanned=([0-9]*) nr_taken=([0-9]*) file=([0-9]*)'; my $regex_lru_shrink_inactive_default = 'nid=([0-9]*) zid=([0-9]*) nr_scanned=([0-9]*) nr_reclaimed=([0-9]*) priority=([0-9]*) flags=([A-Z_|]*)'; my $regex_lru_shrink_active_default = 'lru=([A-Z_]*) nr_scanned=([0-9]*) nr_rotated=([0-9]*) priority=([0-9]*)'; my $regex_writepage_default = 'page=([0-9a-f]*) pfn=([0-9]*) flags=([A-Z_|]*)'; @@ -200,7 +199,7 @@ $regex_lru_isolate = generate_traceevent_regex( $regex_lru_isolate_default, "isolate_mode", "order", "nr_requested", "nr_scanned", "nr_taken", - "contig_taken", "contig_dirty", "contig_failed"); + "file"); $regex_lru_shrink_inactive = generate_traceevent_regex( "vmscan/mm_vmscan_lru_shrink_inactive", $regex_lru_shrink_inactive_default, @@ -375,7 +374,6 @@ EVENT_PROCESS: } my $isolate_mode = $1; my $nr_scanned = $4; - my $nr_contig_dirty = $7; # To closer match vmstat scanning statistics, only count isolate_both # and isolate_inactive as scanning. isolate_active is rotation @@ -385,7 +383,6 @@ EVENT_PROCESS: if ($isolate_mode != 2) { $perprocesspid{$process_pid}->{HIGH_NR_SCANNED} += $nr_scanned; } - $perprocesspid{$process_pid}->{HIGH_NR_CONTIG_DIRTY} += $nr_contig_dirty; } elsif ($tracepoint eq "mm_vmscan_lru_shrink_inactive") { $details = $6; if ($details !~ /$regex_lru_shrink_inactive/o) { @@ -539,13 +536,6 @@ sub dump_stats { } } } - if ($stats{$process_pid}->{HIGH_NR_CONTIG_DIRTY}) { - print " "; - my $count = $stats{$process_pid}->{HIGH_NR_CONTIG_DIRTY}; - if ($count != 0) { - print "contig-dirty=$count "; - } - } print "\n"; } -- cgit v1.1 From 41629a8233470325bfbb60377f555f9e8acc879f Mon Sep 17 00:00:00 2001 From: Dirk Brandewie Date: Fri, 20 Jun 2014 07:28:00 -0700 Subject: intel_pstate: Update documentation of {max,min}_perf_pct sysfs files Update documentation to make the interpretation of the values clearer Link: https://bugzilla.kernel.org/show_bug.cgi?id=64251 Cc: 3.13+ # 3.13+ Signed-off-by: Dirk Brandewie Signed-off-by: Rafael J. Wysocki --- Documentation/cpu-freq/intel-pstate.txt | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cpu-freq/intel-pstate.txt b/Documentation/cpu-freq/intel-pstate.txt index e742d21..a69ffe1 100644 --- a/Documentation/cpu-freq/intel-pstate.txt +++ b/Documentation/cpu-freq/intel-pstate.txt @@ -15,10 +15,13 @@ New sysfs files for controlling P state selection have been added to /sys/devices/system/cpu/intel_pstate/ max_perf_pct: limits the maximum P state that will be requested by - the driver stated as a percentage of the available performance. + the driver stated as a percentage of the available performance. The + available (P states) performance may be reduced by the no_turbo + setting described below. min_perf_pct: limits the minimum P state that will be requested by - the driver stated as a percentage of the available performance. + the driver stated as a percentage of the max (non-turbo) + performance level. no_turbo: limits the driver to selecting P states below the turbo frequency range. -- cgit v1.1 From c760569d0e9c06b39dd19e82bff0b704d90a73b7 Mon Sep 17 00:00:00 2001 From: Prathyush K Date: Fri, 11 Jul 2014 08:02:15 +0900 Subject: ARM: EXYNOS: Add support for clock handling in power domain While powering on/off a local powerdomain in exynos5 chipsets, the input clocks to each device gets modified. This behaviour is based on the SYSCLK_SYS_PWR_REG registers. E.g. SYSCLK_MFC_SYS_PWR_REG = 0x0, the parent of input clock to MFC (aclk333) gets modified to oscclk = 0x1, no change in clocks. The recommended value of SYSCLK_SYS_PWR_REG before power gating any domain is 0x0. So we must also restore the clocks while powering on a domain everytime. This patch adds the framework for getting the required mux and parent clocks through a power domain device node. With this patch, while powering off a domain, parent is set to oscclk and while powering back on, its re-set to the correct parent which is as per the recommended pd on/off sequence. Signed-off-by: Prathyush K Signed-off-by: Andrew Bresticker Signed-off-by: Arun Kumar K Signed-off-by: Shaik Ameer Basha Reviewed-by: Tomasz Figa Signed-off-by: Kukjin Kim --- .../devicetree/bindings/arm/exynos/power_domain.txt | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt index 5216b41..8b4f7b7f 100644 --- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt +++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt @@ -9,6 +9,18 @@ Required Properties: - reg: physical base address of the controller and length of memory mapped region. +Optional Properties: +- clocks: List of clock handles. The parent clocks of the input clocks to the + devices in this power domain are set to oscclk before power gating + and restored back after powering on a domain. This is required for + all domains which are powered on and off and not required for unused + domains. +- clock-names: The following clocks can be specified: + - oscclk: Oscillator clock. + - pclkN, clkN: Pairs of parent of input clock and input clock to the + devices in this power domain. Maximum of 4 pairs (N = 0 to 3) + are supported currently. + Node of a device using power domains must have a samsung,power-domain property defined with a phandle to respective power domain. @@ -19,6 +31,14 @@ Example: reg = <0x10023C00 0x10>; }; + mfc_pd: power-domain@10044060 { + compatible = "samsung,exynos4210-pd"; + reg = <0x10044060 0x20>; + clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_SW_ACLK333>, + <&clock CLK_MOUT_USER_ACLK333>; + clock-names = "oscclk", "pclk0", "clk0"; + }; + Example of the node using power domain: node { -- cgit v1.1 From 1d9dbf154295aa33819b08340464ff15495e83d8 Mon Sep 17 00:00:00 2001 From: Darren Hart Date: Fri, 11 Jul 2014 11:03:39 +0000 Subject: ACPI / documentation: Remove reference to acpi_platform_device_ids from enumeration.txt As of: 4845934 ACPI / scan: use platform bus type by default for _HID enumeration ACPI uses the platform bus by default, changing the opt-in to an opt-out policy, eliminating the acpi_platform_device_ids table and replacing it with forbidden_id_list[]. Remove the qualifying paragraph from the acpi/enumeration documentation as it no longer applies. Reported-by: Max Eliaser Signed-off-by: Darren Hart Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/enumeration.txt | 6 ------ 1 file changed, 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt index fd786ea..e182be5 100644 --- a/Documentation/acpi/enumeration.txt +++ b/Documentation/acpi/enumeration.txt @@ -60,12 +60,6 @@ If the driver needs to perform more complex initialization like getting and configuring GPIOs it can get its ACPI handle and extract this information from ACPI tables. -Currently the kernel is not able to automatically determine from which ACPI -device it should make the corresponding platform device so we need to add -the ACPI device explicitly to acpi_platform_device_ids list defined in -drivers/acpi/acpi_platform.c. This limitation is only for the platform -devices, SPI and I2C devices are created automatically as described below. - DMA support ~~~~~~~~~~~ DMA controllers enumerated via ACPI should be registered in the system to -- cgit v1.1 From 34c4eda809e1efb16c554c07bb5df4c8ace9424e Mon Sep 17 00:00:00 2001 From: Simon Horman Date: Fri, 11 Jul 2014 11:11:08 +0200 Subject: serial: sh-sci: Add device tree support for r8a7{778,740,3a4} and sh73a0 Simply document new compat strings. There appears to be no need for a driver updates. Signed-off-by: Simon Horman Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index 64fd7de..b355660 100644 --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt @@ -4,6 +4,13 @@ Required properties: - compatible: Must contain one of the following: + - "renesas,scifa-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFA compatible UART. + - "renesas,scifb-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFB compatible UART. + - "renesas,scifa-r8a73a4" for R8A73A4 (R-Mobile APE6) SCIFA compatible UART. + - "renesas,scifb-r8a73a4" for R8A73A4 (R-Mobile APE6) SCIFB compatible UART. + - "renesas,scifa-r8a7740" for R8A7740 (R-Mobile A1) SCIFA compatible UART. + - "renesas,scifb-r8a7740" for R8A7740 (R-Mobile A1) SCIFB compatible UART. + - "renesas,scif-r8a7778" for R8A7778 (R-Car M1) SCIF compatible UART. - "renesas,scif-r8a7779" for R8A7779 (R-Car H1) SCIF compatible UART. - "renesas,scif-r8a7790" for R8A7790 (R-Car H2) SCIF compatible UART. - "renesas,scifa-r8a7790" for R8A7790 (R-Car H2) SCIFA compatible UART. -- cgit v1.1 From c8c3f7d621c1dd803e92d4cdd59e2f730be71a2b Mon Sep 17 00:00:00 2001 From: Paul Bolle Date: Sat, 12 Jul 2014 09:54:52 -0700 Subject: Documentation/Changes: clean up mcelog paragraph The paragraph on mcelog currently describes kernel v2.6.31. In that kernel the mce code (for i386, that is) was in transition. Ever since v2.6.32 the situation is much simpler (eg, mcelog is now needed to process events on almost all x86 machines, i386 and x86-64). Since this "document is designed to provide a list of the minimum levels of software necessary to run the 3.0 kernels" let's just describe that situation. Signed-off-by: Paul Bolle Acked-by: Andi Kleen Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/Changes | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/Changes b/Documentation/Changes index 2254db0..227bec8 100644 --- a/Documentation/Changes +++ b/Documentation/Changes @@ -280,12 +280,9 @@ that is possible. mcelog ------ -In Linux 2.6.31+ the i386 kernel needs to run the mcelog utility -as a regular cronjob similar to the x86-64 kernel to process and log -machine check events when CONFIG_X86_NEW_MCE is enabled. Machine check -events are errors reported by the CPU. Processing them is strongly encouraged. -All x86-64 kernels since 2.6.4 require the mcelog utility to -process machine checks. +On x86 kernels the mcelog utility is needed to process and log machine check +events when CONFIG_X86_MCE is enabled. Machine check events are errors reported +by the CPU. Processing them is strongly encouraged. Getting updated software ======================== -- cgit v1.1 From 8011b3c96f393b7ae95a6fd80e1634626c1b95ab Mon Sep 17 00:00:00 2001 From: Masanari Iida Date: Sat, 12 Jul 2014 09:55:15 -0700 Subject: DocBook: fix mtdnand typos This patch fixed spelling typo found in DocBook/mtdnand.tmpl. Signed-off-by: Masanari Iida Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/DocBook/mtdnand.tmpl | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/mtdnand.tmpl b/Documentation/DocBook/mtdnand.tmpl index cd11926..7da8f04 100644 --- a/Documentation/DocBook/mtdnand.tmpl +++ b/Documentation/DocBook/mtdnand.tmpl @@ -91,7 +91,7 @@ [MTD Interface] These functions provide the interface to the MTD kernel API. - They are not replacable and provide functionality + They are not replaceable and provide functionality which is complete hardware independent. @@ -100,14 +100,14 @@ [GENERIC] - Generic functions are not replacable and provide functionality + Generic functions are not replaceable and provide functionality which is complete hardware independent. [DEFAULT] Default functions provide hardware related functionality which is suitable for most of the implementations. These functions can be replaced by the - board driver if neccecary. Those functions are called via pointers in the + board driver if necessary. Those functions are called via pointers in the NAND chip description structure. The board driver can set the functions which should be replaced by board dependent functions before calling nand_scan(). If the function pointer is NULL on entry to nand_scan() then the pointer @@ -264,7 +264,7 @@ static void board_hwcontrol(struct mtd_info *mtd, int cmd) is set up nand_scan() is called. This function tries to detect and identify then chip. If a chip is found all the internal data fields are initialized accordingly. - The structure(s) have to be zeroed out first and then filled with the neccecary + The structure(s) have to be zeroed out first and then filled with the necessary information about the device. @@ -327,7 +327,7 @@ module_init(board_init); Exit function - The exit function is only neccecary if the driver is + The exit function is only necessary if the driver is compiled as a module. It releases all resources which are held by the chip driver and unregisters the partitions in the MTD layer. @@ -494,7 +494,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip) in this case. See rts_from4.c and diskonchip.c for implementation reference. In those cases we must also use bad block tables on FLASH, because the ECC layout is - interferring with the bad block marker positions. + interfering with the bad block marker positions. See bad block table support for details. @@ -542,7 +542,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip) nand_scan() calls the function nand_default_bbt(). nand_default_bbt() selects appropriate default - bad block table desriptors depending on the chip information + bad block table descriptors depending on the chip information which was retrieved by nand_scan(). @@ -554,7 +554,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip) Flash based tables - It may be desired or neccecary to keep a bad block table in FLASH. + It may be desired or necessary to keep a bad block table in FLASH. For AG-AND chips this is mandatory, as they have no factory marked bad blocks. They have factory marked good blocks. The marker pattern is erased when the block is erased to be reused. So in case of @@ -565,10 +565,10 @@ static void board_select_chip (struct mtd_info *mtd, int chip) of the blocks. - The blocks in which the tables are stored are procteted against + The blocks in which the tables are stored are protected against accidental access by marking them bad in the memory bad block table. The bad block table management functions are allowed - to circumvernt this protection. + to circumvent this protection. The simplest way to activate the FLASH based bad block table support @@ -592,7 +592,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip) User defined tables are created by filling out a nand_bbt_descr structure and storing the pointer in the nand_chip structure member bbt_td before calling nand_scan(). - If a mirror table is neccecary a second structure must be + If a mirror table is necessary a second structure must be created and a pointer to this structure must be stored in bbt_md inside the nand_chip structure. If the bbt_md member is set to NULL then only the main table is used @@ -666,7 +666,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip) For automatic placement some blocks must be reserved for bad block table storage. The number of reserved blocks is defined - in the maxblocks member of the babd block table description structure. + in the maxblocks member of the bad block table description structure. Reserving 4 blocks for mirrored tables should be a reasonable number. This also limits the number of blocks which are scanned for the bad block table ident pattern. @@ -1068,11 +1068,11 @@ in this page Filesystem support - The NAND driver provides all neccecary functions for a + The NAND driver provides all necessary functions for a filesystem via the MTD interface. - Filesystems must be aware of the NAND pecularities and + Filesystems must be aware of the NAND peculiarities and restrictions. One major restrictions of NAND Flash is, that you cannot write as often as you want to a page. The consecutive writes to a page, before erasing it again, are restricted to 1-3 writes, depending on the @@ -1222,7 +1222,7 @@ in this page #define NAND_BBT_VERSION 0x00000100 /* Create a bbt if none axists */ #define NAND_BBT_CREATE 0x00000200 -/* Write bbt if neccecary */ +/* Write bbt if necessary */ #define NAND_BBT_WRITE 0x00001000 /* Read and write back block contents when writing bbt */ #define NAND_BBT_SAVECONTENT 0x00002000 -- cgit v1.1 From 0ba4f6e4006634cf566ba9cc3acd40aebee44503 Mon Sep 17 00:00:00 2001 From: Masanari Iida Date: Sat, 12 Jul 2014 09:55:28 -0700 Subject: DocBook: fix various typos This patch fixed spelling typo in various template files within Documentation/Docbook. Signed-off-by: Masanari Iida Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/DocBook/gadget.tmpl | 2 +- Documentation/DocBook/genericirq.tmpl | 4 ++-- Documentation/DocBook/kernel-locking.tmpl | 2 +- Documentation/DocBook/libata.tmpl | 6 +++--- Documentation/DocBook/media_api.tmpl | 2 +- Documentation/DocBook/regulator.tmpl | 2 +- Documentation/DocBook/uio-howto.tmpl | 4 ++-- Documentation/DocBook/usb.tmpl | 2 +- Documentation/DocBook/writing-an-alsa-driver.tmpl | 2 +- 9 files changed, 13 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/gadget.tmpl b/Documentation/DocBook/gadget.tmpl index 4017f14..2c425d7 100644 --- a/Documentation/DocBook/gadget.tmpl +++ b/Documentation/DocBook/gadget.tmpl @@ -708,7 +708,7 @@ hardware level details could be very different. Systems need specialized hardware support to implement OTG, notably including a special Mini-AB jack -and associated transciever to support Dual-Role +and associated transceiver to support Dual-Role operation: they can act either as a host, using the standard Linux-USB host side driver stack, diff --git a/Documentation/DocBook/genericirq.tmpl b/Documentation/DocBook/genericirq.tmpl index 46347f6..59fb5c0 100644 --- a/Documentation/DocBook/genericirq.tmpl +++ b/Documentation/DocBook/genericirq.tmpl @@ -182,7 +182,7 @@ Each interrupt is described by an interrupt descriptor structure irq_desc. The interrupt is referenced by an 'unsigned int' numeric - value which selects the corresponding interrupt decription structure + value which selects the corresponding interrupt description structure in the descriptor structures array. The descriptor structure contains status information and pointers to the interrupt flow method and the interrupt chip structure @@ -470,7 +470,7 @@ if (desc->irq_data.chip->irq_eoi) To avoid copies of identical implementations of IRQ chips the core provides a configurable generic interrupt chip - implementation. Developers should check carefuly whether the + implementation. Developers should check carefully whether the generic chip fits their needs before implementing the same functionality slightly differently themselves. diff --git a/Documentation/DocBook/kernel-locking.tmpl b/Documentation/DocBook/kernel-locking.tmpl index 19f2a5a..e584ee1 100644 --- a/Documentation/DocBook/kernel-locking.tmpl +++ b/Documentation/DocBook/kernel-locking.tmpl @@ -1760,7 +1760,7 @@ as it would be on UP. -There is a furthur optimization possible here: remember our original +There is a further optimization possible here: remember our original cache code, where there were no reference counts and the caller simply held the lock whenever using the object? This is still possible: if you hold the lock, no one can delete the object, so you don't need to diff --git a/Documentation/DocBook/libata.tmpl b/Documentation/DocBook/libata.tmpl index deb71ba..d7fcdc5 100644 --- a/Documentation/DocBook/libata.tmpl +++ b/Documentation/DocBook/libata.tmpl @@ -677,7 +677,7 @@ and other resources, etc. - ATA_QCFLAG_ACTIVE is clared from qc->flags. + ATA_QCFLAG_ACTIVE is cleared from qc->flags. @@ -708,7 +708,7 @@ and other resources, etc. - qc->waiting is claread & completed (in that order). + qc->waiting is cleared & completed (in that order). @@ -1163,7 +1163,7 @@ and other resources, etc. Once sense data is acquired, this type of errors can be - handled similary to other SCSI errors. Note that sense data + handled similarly to other SCSI errors. Note that sense data may indicate ATA bus error (e.g. Sense Key 04h HARDWARE ERROR && ASC/ASCQ 47h/00h SCSI PARITY ERROR). In such cases, the error should be considered as an ATA bus error and diff --git a/Documentation/DocBook/media_api.tmpl b/Documentation/DocBook/media_api.tmpl index 4decb46..03f9a1f 100644 --- a/Documentation/DocBook/media_api.tmpl +++ b/Documentation/DocBook/media_api.tmpl @@ -68,7 +68,7 @@ several digital tv standards. While it is called as DVB API, in fact it covers several different video standards including DVB-T, DVB-S, DVB-C and ATSC. The API is currently being updated - to documment support also for DVB-S2, ISDB-T and ISDB-S. + to document support also for DVB-S2, ISDB-T and ISDB-S. The third part covers the Remote Controller API. The fourth part covers the Media Controller API. For additional information and for the latest development code, diff --git a/Documentation/DocBook/regulator.tmpl b/Documentation/DocBook/regulator.tmpl index 346e552..3b08a08 100644 --- a/Documentation/DocBook/regulator.tmpl +++ b/Documentation/DocBook/regulator.tmpl @@ -155,7 +155,7 @@ release regulators. Functions are provided to enable and disable the - reguator and to get and set the runtime parameters of the + regulator and to get and set the runtime parameters of the regulator. diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl index 9561815..bbe9c1f 100644 --- a/Documentation/DocBook/uio-howto.tmpl +++ b/Documentation/DocBook/uio-howto.tmpl @@ -766,10 +766,10 @@ framework to set up sysfs files for this region. Simply leave it alone. The dynamic memory regions will be allocated when the UIO device file, /dev/uioX is opened. - Simiar to static memory resources, the memory region information for + Similar to static memory resources, the memory region information for dynamic regions is then visible via sysfs at /sys/class/uio/uioX/maps/mapY/*. - The dynmaic memory regions will be freed when the UIO device file is + The dynamic memory regions will be freed when the UIO device file is closed. When no processes are holding the device file open, the address returned to userspace is ~0. diff --git a/Documentation/DocBook/usb.tmpl b/Documentation/DocBook/usb.tmpl index 8d57c18..85fc0e2 100644 --- a/Documentation/DocBook/usb.tmpl +++ b/Documentation/DocBook/usb.tmpl @@ -153,7 +153,7 @@ The Linux USB API supports synchronous calls for control and bulk messages. - It also supports asynchnous calls for all kinds of data transfer, + It also supports asynchronous calls for all kinds of data transfer, using request structures called "URBs" (USB Request Blocks). diff --git a/Documentation/DocBook/writing-an-alsa-driver.tmpl b/Documentation/DocBook/writing-an-alsa-driver.tmpl index d0056a4..6f639d9 100644 --- a/Documentation/DocBook/writing-an-alsa-driver.tmpl +++ b/Documentation/DocBook/writing-an-alsa-driver.tmpl @@ -5696,7 +5696,7 @@ struct _snd_pcm_runtime { suspending the PCM operations via snd_pcm_suspend_all() or snd_pcm_suspend(). It means that the PCM - streams are already stoppped when the register snapshot is + streams are already stopped when the register snapshot is taken. But, remember that you don't have to restart the PCM stream in the resume callback. It'll be restarted via trigger call with SNDRV_PCM_TRIGGER_RESUME -- cgit v1.1 From 3a57cc5f1935d824c36264e0fa888d7d6a9038c0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pali=20Roh=C3=A1r?= Date: Sat, 12 Jul 2014 09:56:22 -0700 Subject: Documenation/laptops: rename and update hpfall.c MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Dell kernel driver dell-smo8800 provides same freefall interface as hp_accel so program hpfall.c works also on Dell laptops. So rename it to freefall.c. Dell driver does not provide hp::hddprotect led so make sure that freefall.c works also if hp::hddprotect does not exist in sysfs. Additionally write info to syslog. Signed-off-by: Pali Rohár Cc: Sonal Santan Acked-by: Pavel Machek Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/laptops/00-INDEX | 4 +- Documentation/laptops/freefall.c | 177 +++++++++++++++++++++++++++++++++++++++ Documentation/laptops/hpfall.c | 146 -------------------------------- 3 files changed, 179 insertions(+), 148 deletions(-) create mode 100644 Documentation/laptops/freefall.c delete mode 100644 Documentation/laptops/hpfall.c (limited to 'Documentation') diff --git a/Documentation/laptops/00-INDEX b/Documentation/laptops/00-INDEX index d13b9a9..d399ae1 100644 --- a/Documentation/laptops/00-INDEX +++ b/Documentation/laptops/00-INDEX @@ -8,8 +8,8 @@ disk-shock-protection.txt - information on hard disk shock protection. dslm.c - Simple Disk Sleep Monitor program -hpfall.c - - (HP) laptop accelerometer program for disk protection. +freefall.c + - (HP/DELL) laptop accelerometer program for disk protection. laptop-mode.txt - how to conserve battery power using laptop-mode. sony-laptop.txt diff --git a/Documentation/laptops/freefall.c b/Documentation/laptops/freefall.c new file mode 100644 index 0000000..aab2ff0 --- /dev/null +++ b/Documentation/laptops/freefall.c @@ -0,0 +1,177 @@ +/* Disk protection for HP/DELL machines. + * + * Copyright 2008 Eric Piel + * Copyright 2009 Pavel Machek + * Copyright 2012 Sonal Santan + * Copyright 2014 Pali Rohár + * + * GPLv2. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +static int noled; +static char unload_heads_path[64]; +static char device_path[32]; +static const char app_name[] = "FREE FALL"; + +static int set_unload_heads_path(char *device) +{ + char devname[64]; + + if (strlen(device) <= 5 || strncmp(device, "/dev/", 5) != 0) + return -EINVAL; + strncpy(devname, device + 5, sizeof(devname) - 1); + strncpy(device_path, device, sizeof(device_path) - 1); + + snprintf(unload_heads_path, sizeof(unload_heads_path) - 1, + "/sys/block/%s/device/unload_heads", devname); + return 0; +} + +static int valid_disk(void) +{ + int fd = open(unload_heads_path, O_RDONLY); + + if (fd < 0) { + perror(unload_heads_path); + return 0; + } + + close(fd); + return 1; +} + +static void write_int(char *path, int i) +{ + char buf[1024]; + int fd = open(path, O_RDWR); + + if (fd < 0) { + perror("open"); + exit(1); + } + + sprintf(buf, "%d", i); + + if (write(fd, buf, strlen(buf)) != strlen(buf)) { + perror("write"); + exit(1); + } + + close(fd); +} + +static void set_led(int on) +{ + if (noled) + return; + write_int("/sys/class/leds/hp::hddprotect/brightness", on); +} + +static void protect(int seconds) +{ + const char *str = (seconds == 0) ? "Unparked" : "Parked"; + + write_int(unload_heads_path, seconds*1000); + syslog(LOG_INFO, "%s %s disk head\n", str, device_path); +} + +static int on_ac(void) +{ + /* /sys/class/power_supply/AC0/online */ + return 1; +} + +static int lid_open(void) +{ + /* /proc/acpi/button/lid/LID/state */ + return 1; +} + +static void ignore_me(int signum) +{ + protect(0); + set_led(0); +} + +int main(int argc, char **argv) +{ + int fd, ret; + struct stat st; + struct sched_param param; + + if (argc == 1) + ret = set_unload_heads_path("/dev/sda"); + else if (argc == 2) + ret = set_unload_heads_path(argv[1]); + else + ret = -EINVAL; + + if (ret || !valid_disk()) { + fprintf(stderr, "usage: %s (default: /dev/sda)\n", + argv[0]); + exit(1); + } + + fd = open("/dev/freefall", O_RDONLY); + if (fd < 0) { + perror("/dev/freefall"); + return EXIT_FAILURE; + } + + if (stat("/sys/class/leds/hp::hddprotect/brightness", &st)) + noled = 1; + + if (daemon(0, 0) != 0) { + perror("daemon"); + return EXIT_FAILURE; + } + + openlog(app_name, LOG_CONS | LOG_PID | LOG_NDELAY, LOG_LOCAL1); + + param.sched_priority = sched_get_priority_max(SCHED_FIFO); + sched_setscheduler(0, SCHED_FIFO, ¶m); + mlockall(MCL_CURRENT|MCL_FUTURE); + + signal(SIGALRM, ignore_me); + + for (;;) { + unsigned char count; + + ret = read(fd, &count, sizeof(count)); + alarm(0); + if ((ret == -1) && (errno == EINTR)) { + /* Alarm expired, time to unpark the heads */ + continue; + } + + if (ret != sizeof(count)) { + perror("read"); + break; + } + + protect(21); + set_led(1); + if (1 || on_ac() || lid_open()) + alarm(2); + else + alarm(20); + } + + closelog(); + close(fd); + return EXIT_SUCCESS; +} diff --git a/Documentation/laptops/hpfall.c b/Documentation/laptops/hpfall.c deleted file mode 100644 index b85dbba..0000000 --- a/Documentation/laptops/hpfall.c +++ /dev/null @@ -1,146 +0,0 @@ -/* Disk protection for HP machines. - * - * Copyright 2008 Eric Piel - * Copyright 2009 Pavel Machek - * - * GPLv2. - */ - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -char unload_heads_path[64]; - -int set_unload_heads_path(char *device) -{ - char devname[64]; - - if (strlen(device) <= 5 || strncmp(device, "/dev/", 5) != 0) - return -EINVAL; - strncpy(devname, device + 5, sizeof(devname)); - - snprintf(unload_heads_path, sizeof(unload_heads_path) - 1, - "/sys/block/%s/device/unload_heads", devname); - return 0; -} -int valid_disk(void) -{ - int fd = open(unload_heads_path, O_RDONLY); - if (fd < 0) { - perror(unload_heads_path); - return 0; - } - - close(fd); - return 1; -} - -void write_int(char *path, int i) -{ - char buf[1024]; - int fd = open(path, O_RDWR); - if (fd < 0) { - perror("open"); - exit(1); - } - sprintf(buf, "%d", i); - if (write(fd, buf, strlen(buf)) != strlen(buf)) { - perror("write"); - exit(1); - } - close(fd); -} - -void set_led(int on) -{ - write_int("/sys/class/leds/hp::hddprotect/brightness", on); -} - -void protect(int seconds) -{ - write_int(unload_heads_path, seconds*1000); -} - -int on_ac(void) -{ -// /sys/class/power_supply/AC0/online -} - -int lid_open(void) -{ -// /proc/acpi/button/lid/LID/state -} - -void ignore_me(void) -{ - protect(0); - set_led(0); -} - -int main(int argc, char **argv) -{ - int fd, ret; - struct sched_param param; - - if (argc == 1) - ret = set_unload_heads_path("/dev/sda"); - else if (argc == 2) - ret = set_unload_heads_path(argv[1]); - else - ret = -EINVAL; - - if (ret || !valid_disk()) { - fprintf(stderr, "usage: %s (default: /dev/sda)\n", - argv[0]); - exit(1); - } - - fd = open("/dev/freefall", O_RDONLY); - if (fd < 0) { - perror("/dev/freefall"); - return EXIT_FAILURE; - } - - daemon(0, 0); - param.sched_priority = sched_get_priority_max(SCHED_FIFO); - sched_setscheduler(0, SCHED_FIFO, ¶m); - mlockall(MCL_CURRENT|MCL_FUTURE); - - signal(SIGALRM, ignore_me); - - for (;;) { - unsigned char count; - - ret = read(fd, &count, sizeof(count)); - alarm(0); - if ((ret == -1) && (errno == EINTR)) { - /* Alarm expired, time to unpark the heads */ - continue; - } - - if (ret != sizeof(count)) { - perror("read"); - break; - } - - protect(21); - set_led(1); - if (1 || on_ac() || lid_open()) - alarm(2); - else - alarm(20); - } - - close(fd); - return EXIT_SUCCESS; -} -- cgit v1.1 From 2843768b701971ab10e62c77d5c75ad7c306f1bd Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Mon, 14 Jul 2014 19:35:45 +0200 Subject: Revert "ACPI / video: change acpi-video brightness_switch_enabled default to 0" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This reverts commit 886129a8eebeb (ACPI / video: change acpi-video brightness_switch_enabled default to 0) as it is reported to cause problems to happen. Fixes: 886129a8eebeb (ACPI / video: change acpi-video brightness_switch_enabled default to 0) Link: http://marc.info/?l=linux-acpi&m=140534286826819&w=2 Reported by: Bjørn Mork Signed-off-by: Rafael J. Wysocki --- Documentation/kernel-parameters.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index c1b9aa8..e332e71 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -3526,7 +3526,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. the allocated input device; If set to 0, video driver will only send out the event without touching backlight brightness level. - default: 0 + default: 1 virtio_mmio.device= [VMMIO] Memory mapped virtio (platform) device. -- cgit v1.1 From 1bf8cc3d017575a38d4361f56ccc0a670a16bcd9 Mon Sep 17 00:00:00 2001 From: Viresh Kumar Date: Fri, 11 Jul 2014 20:24:19 +0530 Subject: cpufreq: cpu0: OPPs can be populated at runtime OPPs can be populated statically, via DT, or added at run time with dev_pm_opp_add(). While this driver handles the first case correctly, it would fail to populate OPPs added at runtime. Because call to of_init_opp_table() would fail as there are no OPPs in DT and probe will return early. To fix this, remove error checking and call dev_pm_opp_init_cpufreq_table() unconditionally. Update bindings as well. Suggested-by: Stephen Boyd Tested-by: Stephen Boyd Signed-off-by: Viresh Kumar Acked-by: Santosh Shilimkar Signed-off-by: Rafael J. Wysocki --- Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt index f055515..366690c 100644 --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt @@ -8,10 +8,12 @@ Both required and optional properties listed below must be defined under node /cpus/cpu@0. Required properties: -- operating-points: Refer to Documentation/devicetree/bindings/power/opp.txt - for details +- None Optional properties: +- operating-points: Refer to Documentation/devicetree/bindings/power/opp.txt for + details. OPPs *must* be supplied either via DT, i.e. this property, or + populated at runtime. - clock-latency: Specify the possible maximum transition latency for clock, in unit of nanoseconds. - voltage-tolerance: Specify the CPU voltage tolerance in percentage. -- cgit v1.1 From 128bb95debc8302a999a495dd21726ca422da12a Mon Sep 17 00:00:00 2001 From: Daniel Mack Date: Tue, 15 Jul 2014 09:47:52 -0700 Subject: Input: add driver for Microchip's CAP1106 This patch adds a driver for Microchips CAP1106, an I2C driven, 6-channel capacitive touch sensor. For now, only the capacitive buttons are supported, and no specific settings that can be tweaked for individual channels, except for the device-wide sensitivity gain. The defaults seem to work just fine out of the box, so I'll leave configurable parameters for someone who's in need of them and who can actually measure the impact. All registers are prepared, however. Many of them are just not used for now. The implementation does not make any attempt to be compatible to platform data driven boards, but fully depends on CONFIG_OF. Power management functions are also left for volounteers with the ability to actually test them. Signed-off-by: Daniel Mack Signed-off-by: Dmitry Torokhov --- .../devicetree/bindings/input/cap1106.txt | 53 ++++++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/cap1106.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/input/cap1106.txt b/Documentation/devicetree/bindings/input/cap1106.txt new file mode 100644 index 0000000..4b46390 --- /dev/null +++ b/Documentation/devicetree/bindings/input/cap1106.txt @@ -0,0 +1,53 @@ +Device tree bindings for Microchip CAP1106, 6 channel capacitive touch sensor + +The node for this driver must be a child of a I2C controller node, as the +device communication via I2C only. + +Required properties: + + compatible: Must be "microchip,cap1106" + + reg: The I2C slave address of the device. + Only 0x28 is valid. + + interrupts: Property describing the interrupt line the + device's ALERT#/CM_IRQ# pin is connected to. + The device only has one interrupt source. + +Optional properties: + + autorepeat: Enables the Linux input system's autorepeat + feature on the input device. + + microchip,sensor-gain: Defines the gain of the sensor circuitry. This + effectively controls the sensitivity, as a + smaller delta capacitance is required to + generate the same delta count values. + Valid values are 1, 2, 4, and 8. + By default, a gain of 1 is set. + + linux,keycodes: Specifies an array of numeric keycode values to + be used for the channels. If this property is + omitted, KEY_A, KEY_B, etc are used as + defaults. The array must have exactly six + entries. + +Example: + +i2c_controller { + cap1106@28 { + compatible = "microchip,cap1106"; + interrupt-parent = <&gpio1>; + interrupts = <0 0>; + reg = <0x28>; + autorepeat; + microchip,sensor-gain = <2>; + + linux,keycodes = <103 /* KEY_UP */ + 106 /* KEY_RIGHT */ + 108 /* KEY_DOWN */ + 105 /* KEY_LEFT */ + 109 /* KEY_PAGEDOWN */ + 104>; /* KEY_PAGEUP */ + }; +} -- cgit v1.1 From 3974037039e925a9645e70e1dc91735d28faad95 Mon Sep 17 00:00:00 2001 From: Heiko Stuebner Date: Mon, 21 Jul 2014 10:02:11 -0700 Subject: Input: zforce - add regulator handling It's possible that the controller has an individually switchable power supply. Therefore add support to control a supplying regulator. As this is not always the case, the regulator is requested as optional. Signed-off-by: Heiko Stuebner Signed-off-by: Dmitry Torokhov --- Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt b/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt index 2faf1f1..80c37df 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt @@ -9,6 +9,9 @@ Required properties: - x-size: horizontal resolution of touchscreen - y-size: vertical resolution of touchscreen +Optional properties: +- vdd-supply: Regulator controlling the controller supply + Example: i2c@00000000 { @@ -18,6 +21,7 @@ Example: compatible = "neonode,zforce"; reg = <0x50>; interrupts = <2 0>; + vdd-supply = <®_zforce_vdd>; gpios = <&gpio5 6 0>, /* INT */ <&gpio5 9 0>; /* RST */ -- cgit v1.1 From 78188be3e5dd59cc2f67bf4cf573e579da186d39 Mon Sep 17 00:00:00 2001 From: Stephen Warren Date: Wed, 23 Jul 2014 12:23:23 -0700 Subject: Input: atmel_mxt_ts - implement device tree support Signed-off-by: Stephen Warren Signed-off-by: Nick Dyer Signed-off-by: Dmitry Torokhov --- .../devicetree/bindings/input/atmel,maxtouch.txt | 25 ++++++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/atmel,maxtouch.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt new file mode 100644 index 0000000..baef432 --- /dev/null +++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt @@ -0,0 +1,25 @@ +Atmel maXTouch touchscreen/touchpad + +Required properties: +- compatible: + atmel,maxtouch + +- reg: The I2C address of the device + +- interrupts: The sink for the touchpad's IRQ output + See ../interrupt-controller/interrupts.txt + +Optional properties for main touchpad device: + +- linux,gpio-keymap: An array of up to 4 entries indicating the Linux + keycode generated by each GPIO. Linux keycodes are defined in + . + +Example: + + touch@4b { + compatible = "atmel,maxtouch"; + reg = <0x4b>; + interrupt-parent = <&gpio>; + interrupts = ; + }; -- cgit v1.1 From a4054596e93048d50502f6c31c853bfeba5acb8e Mon Sep 17 00:00:00 2001 From: Roger Quadros Date: Mon, 28 Jul 2014 10:05:39 -0700 Subject: Input: pixcir_i2c_ts - add device tree support Provide device tree support and binding information. Also provide support for a new chip "pixcir_tangoc". Signed-off-by: Roger Quadros Signed-off-by: Dmitry Torokhov --- .../bindings/input/touchscreen/pixcir_i2c_ts.txt | 26 ++++++++++++++++++++++ .../devicetree/bindings/vendor-prefixes.txt | 1 + 2 files changed, 27 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt b/Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt new file mode 100644 index 0000000..6e55109 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt @@ -0,0 +1,26 @@ +* Pixcir I2C touchscreen controllers + +Required properties: +- compatible: must be "pixcir,pixcir_ts" or "pixcir,pixcir_tangoc" +- reg: I2C address of the chip +- interrupts: interrupt to which the chip is connected +- attb-gpio: GPIO connected to the ATTB line of the chip +- touchscreen-size-x: horizontal resolution of touchscreen (in pixels) +- touchscreen-size-y: vertical resolution of touchscreen (in pixels) + +Example: + + i2c@00000000 { + /* ... */ + + pixcir_ts@5c { + compatible = "pixcir,pixcir_ts"; + reg = <0x5c>; + interrupts = <2 0>; + attb-gpio = <&gpf 2 0 2>; + touchscreen-size-x = <800>; + touchscreen-size-y = <600>; + }; + + /* ... */ + }; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 46a311e..91bd228 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -99,6 +99,7 @@ panasonic Panasonic Corporation phytec PHYTEC Messtechnik GmbH picochip Picochip Ltd plathome Plat'Home Co., Ltd. +pixcir PIXCIR MICROELECTRONICS Co., Ltd powervr PowerVR (deprecated, use img) qca Qualcomm Atheros, Inc. qcom Qualcomm Technologies, Inc -- cgit v1.1