* [PATCH v6 1/8] MFD: add bindings for STM32 Timers driver
From: Benjamin Gaignard @ 2016-12-13 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212185149.rt3xqpn3mbaavb4l@rob-hp-laptop>
2016-12-12 19:51 GMT+01:00 Rob Herring <robh@kernel.org>:
> On Fri, Dec 09, 2016 at 03:15:12PM +0100, Benjamin Gaignard wrote:
>> Add bindings information for STM32 Timers
>>
>> version 6:
>> - rename stm32-gtimer to stm32-timers
>> - change compatible
>> - add description about the IPs
>>
>> version 2:
>> - rename stm32-mfd-timer to stm32-gptimer
>> - only keep one compatible string
>>
>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>> ---
>> .../devicetree/bindings/mfd/stm32-timers.txt | 46 ++++++++++++++++++++++
>> 1 file changed, 46 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/stm32-timers.txt b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
>> new file mode 100644
>> index 0000000..b30868e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
>> @@ -0,0 +1,46 @@
>> +STM32 Timers driver bindings
>> +
>> +This IP provides 3 types of timer along with PWM functionality:
>> +- advanced-control timers consist of a 16-bit auto-reload counter driven by a programmable
>> + prescaler, break input feature, PWM outputs and complementary PWM ouputs channels.
>> +- general-purpose timers consist of a 16-bit or 32-bit auto-reload counter driven by a
>> + programmable prescaler and PWM outputs.
>> +- basic timers consist of a 16-bit auto-reload counter driven by a programmable prescaler.
>> +
>> +Required parameters:
>> +- compatible: must be "st,stm32-timers"
>> +
>> +- reg: Physical base address and length of the controller's
>> + registers.
>> +- clock-names: Set to "clk_int".
>
> 'clk' is redundant. Also, you don't really need -names when there is
> only one of them.
I use devm_regmap_init_mmio_clk() which get the clock by it name so
I have to define it in DT.
>> +- clocks: Phandle to the clock used by the timer module.
>> + For Clk properties, please refer to ../clock/clock-bindings.txt
>> +
>> +Optional parameters:
>> +- resets: Phandle to the parent reset controller.
>> + See ../reset/st,stm32-rcc.txt
>> +
>> +Optional subnodes:
>> +- pwm: See ../pwm/pwm-stm32.txt
>> +- timer: See ../iio/timer/stm32-timer-trigger.txt
>> +
>> +Example:
>> + timers at 40010000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40010000 0x400>;
>> + clocks = <&rcc 0 160>;
>> + clock-names = "clk_int";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + pinctrl-0 = <&pwm1_pins>;
>> + pinctrl-names = "default";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <0>;
>
> You don't need reg here as there is only one. In turn, you don't need
> #address-cells or #size-cells.
I use "reg" to set each timer configuration.
>From hardware point of view they are all the same except for which hardware
signals they could consume and/or send.
"reg" is used as index of the two tables in driver code.
>
>> + };
>> + };
>> --
>> 1.9.1
>>
^ permalink raw reply
* [PATCH v6 7/8] ARM: dts: stm32: add Timers driver for stm32f429 MCU
From: Benjamin Gaignard @ 2016-12-13 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212185943.ph7njaqb2lxtgdn4@rob-hp-laptop>
2016-12-12 19:59 GMT+01:00 Rob Herring <robh@kernel.org>:
> On Fri, Dec 09, 2016 at 03:15:18PM +0100, Benjamin Gaignard wrote:
>> Add Timers and it sub-nodes into DT for stm32f429 family.
>>
>> version 6:
>> - split patch in two: one for SoC family and one for stm32f469
>> discovery board.
>>
>> version 5:
>> - rename gptimer node to timers
>> - re-order timers node par addresses
>>
>> version 4:
>> - remove unwanted indexing in pwm@ and timer@ node name
>> - use "reg" instead of additional parameters to set timer
>> configuration
>>
>> version 3:
>> - use "st,stm32-timer-trigger" in DT
>>
>> version 2:
>> - use parameters to describe hardware capabilities
>> - do not use references for pwm and iio timer subnodes
>>
>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>> ---
>> arch/arm/boot/dts/stm32f429.dtsi | 275 +++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 275 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
>> index bca491d..d0fb9cc 100644
>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>> @@ -355,6 +355,21 @@
>> slew-rate = <2>;
>> };
>> };
>> +
>> + pwm1_pins: pwm at 1 {
>
> No reg prop, so should not have a unit-address. Given the names in the
> define below, seems like "timer1" would be appropriate.
>
Here pins muxing is only targeting PWM part of the the MFD , that why I have
labeled it with "pwm".
>> + pins {
>> + pinmux = <STM32F429_PA8_FUNC_TIM1_CH1>,
>> + <STM32F429_PB13_FUNC_TIM1_CH1N>,
>> + <STM32F429_PB12_FUNC_TIM1_BKIN>;
>> + };
>> + };
>> +
>> + pwm3_pins: pwm at 3 {
>> + pins {
>> + pinmux = <STM32F429_PB4_FUNC_TIM3_CH1>,
>> + <STM32F429_PB5_FUNC_TIM3_CH2>;
>> + };
>> + };
>> };
>>
>> rcc: rcc at 40023810 {
>> @@ -426,6 +441,266 @@
>> interrupts = <80>;
>> clocks = <&rcc 0 38>;
>> };
>> +
>> + timers2: timers at 40000000 {
>
> timer at ...
>
> It may be more than just a timer, there's not a better generic name.
"timer" is already used in DT for clocksource driver.
"timers" cover "advanced-control", "generic" and "basic" hardware timers IPs,
which share the same registers mapping (only the level of feature are different)
>
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40000000 0x400>;
>> + clocks = <&rcc 0 128>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <1>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers3: timers at 40000400 {
>
> ditto
>
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40000400 0x400>;
>> + clocks = <&rcc 0 129>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <2>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers4: timers at 40000800 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40000800 0x400>;
>> + clocks = <&rcc 0 130>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <3>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers5: timers at 40000C00 {
>
> timer at ...
>
> And use lowercase hex.
ok
>
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40000C00 0x400>;
>
> ditto
>
>> + clocks = <&rcc 0 131>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <4>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers6: timers at 40001000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40001000 0x400>;
>> + clocks = <&rcc 0 132>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <5>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers7: timers at 40001400 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40001400 0x400>;
>> + clocks = <&rcc 0 133>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <6>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers12: timers at 40001800 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40001800 0x400>;
>> + clocks = <&rcc 0 134>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <9>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers13: timers at 40001C00 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40001C00 0x400>;
>> + clocks = <&rcc 0 135>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers14: timers at 40002000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40002000 0x400>;
>> + clocks = <&rcc 0 136>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers1: timers at 40010000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40010000 0x400>;
>> + clocks = <&rcc 0 160>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <0>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers8: timers at 40010400 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40010400 0x400>;
>> + clocks = <&rcc 0 161>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <7>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers9: timers at 40014000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40014000 0x400>;
>> + clocks = <&rcc 0 176>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> +
>> + timer {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <8>;
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers10: timers at 40014400 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40014400 0x400>;
>> + clocks = <&rcc 0 177>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> + };
>> +
>> + timers11: timers at 40014800 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-timers";
>> + reg = <0x40014800 0x400>;
>> + clocks = <&rcc 0 178>;
>> + clock-names = "clk_int";
>> + status = "disabled";
>> +
>> + pwm {
>> + compatible = "st,stm32-pwm";
>> + status = "disabled";
>> + };
>> + };
>> };
>> };
>>
>> --
>> 1.9.1
>>
^ permalink raw reply
* [PATCH RFC 2/2] ARM: nommu: remap exception base address to RAM
From: Vladimir Murzin @ 2016-12-13 9:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161211131255.3221-1-afzal.mohd.ma@gmail.com>
On 11/12/16 13:12, Afzal Mohammed wrote:
> Remap exception base address to start of RAM in Kernel in !MMU mode.
>
> Based on existing Kconfig help, Kernel was expecting it to be
> configured by external support. Also earlier it was not possible to
> copy the exception table to start of RAM due to Kconfig dependency,
> which has been fixed by a change prior to this.
>
> Kernel text start at an offset of at least 32K to account for page
> tables in MMU case. On a !MMU build too this space is kept aside, and
> since 2 pages (8K) is the maximum for exception plus stubs, it can be
> placed at the start of RAM.
>
> Signed-off-by: Afzal Mohammed <afzal.mohd.ma@gmail.com>
> ---
>
> i am a bit shaky about this change, though it works here on Cortex-A9,
> this probably would have to be made robust so as to not cause issue on
> other v7-A's upon trying to do !MMU (this won't affect normal MMU boot),
> or specifically where security extensions are not enabled. Also effect
> of hypervisor extension also need to be considered. Please let know if
> any better ways to handle this.
You might need to check ID_PFR1 for that.
>
>
> arch/arm/Kconfig-nommu | 6 +++---
> arch/arm/kernel/head-nommu.S | 6 ++++++
> 2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/Kconfig-nommu b/arch/arm/Kconfig-nommu
> index b7576349528c..f57fbe3d5eb0 100644
> --- a/arch/arm/Kconfig-nommu
> +++ b/arch/arm/Kconfig-nommu
> @@ -46,9 +46,9 @@ config REMAP_VECTORS_TO_RAM
> If your CPU provides a remap facility which allows the exception
> vectors to be mapped to writable memory, say 'n' here.
>
> - Otherwise, say 'y' here. In this case, the kernel will require
> - external support to redirect the hardware exception vectors to
> - the writable versions located at DRAM_BASE.
> + Otherwise, say 'y' here. In this case, the kernel will
> + redirect the hardware exception vectors to the writable
> + versions located at DRAM_BASE.
>
> config ARM_MPU
> bool 'Use the ARM v7 PMSA Compliant MPU'
> diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
> index 6b4eb27b8758..ac31c9647830 100644
> --- a/arch/arm/kernel/head-nommu.S
> +++ b/arch/arm/kernel/head-nommu.S
> @@ -158,6 +158,12 @@ __after_proc_init:
> bic r0, r0, #CR_V
> #endif
> mcr p15, 0, r0, c1, c0, 0 @ write control reg
> +
> +#ifdef CONFIG_REMAP_VECTORS_TO_RAM
> + mov r3, #CONFIG_VECTORS_BASE @ read VECTORS_BASE
ldr r3,=CONFIG_VECTORS_BASE
would be more robust. I hit this in [1]
[1] https://www.spinics.net/lists/arm-kernel/msg546825.html
Cheers
Vladimir
> + mcr p15, 0, r3, c12, c0, 0 @ write to VBAR
> +#endif
> +
> #elif defined (CONFIG_CPU_V7M)
> /* For V7M systems we want to modify the CCR similarly to the SCTLR */
> #ifdef CONFIG_CPU_DCACHE_DISABLE
>
^ permalink raw reply
* [PATCH v1 2/3] clk: rockchip: add clock controller for rk3328
From: Shawn Lin @ 2016-12-13 9:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481618869-1239-3-git-send-email-zhangqing@rock-chips.com>
Hi, Elaine,
I always only keep an eye for mmc stuff here. :)
On 2016/12/13 16:47, Elaine Zhang wrote:
> Add the clock tree definition for the new rk3328 SoC.
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> ---
----8<--------------
> +
> + /* PD_MMC */
> + MMC(SCLK_SDMMC_DRV, "sdmmc_drv", "sclk_sdmmc",
> + RK3328_SDMMC_CON0, 1),
> + MMC(SCLK_SDMMC_SAMPLE, "sdmmc_sample", "sclk_sdmmc",
> + RK3328_SDMMC_CON1, 0),
> +
All of offset for these *_sample are wrong, and they should be 1
, the same as *_drv. You could refer to P565 of TRM instead the
section of CRU for these details.
> + MMC(SCLK_SDIO_DRV, "sdio_drv", "sclk_sdio",
> + RK3328_SDIO_CON0, 1),
> + MMC(SCLK_SDIO_SAMPLE, "sdio_sample", "sclk_sdio",
> + RK3328_SDIO_CON1, 0),
> +
> + MMC(SCLK_EMMC_DRV, "emmc_drv", "sclk_emmc",
> + RK3328_EMMC_CON0, 1),
> + MMC(SCLK_EMMC_SAMPLE, "emmc_sample", "sclk_emmc",
> + RK3328_EMMC_CON1, 0),
> +
> + MMC(SCLK_SDMMC_EXT_DRV, "sdmmc_ext_drv", "sclk_sdmmc_ext",
> + RK3328_SDMMC_EXT_CON0, 1),
> + MMC(SCLK_SDMMC_EXT_SAMPLE, "sdmmc_ext_sample", "sclk_sdmmc_ext",
> + RK3328_SDMMC_EXT_CON1, 0),
> +};
> +
----8<--------
> +#define RK3328_SDMMC_CON0 0x380
> +#define RK3328_SDMMC_CON1 0x384
> +#define RK3328_SDIO_CON0 0x388
> +#define RK3328_SDIO_CON1 0x38c
> +#define RK3328_EMMC_CON0 0x390
> +#define RK3328_EMMC_CON1 0x394
> +#define RK3328_SDMMC_EXT_CON0 0x398
> +#define RK3328_SDMMC_EXT_CON1 0x39C
Just wondering is it worth, but this uppercase 'C' isn't
consistent with the former lowercase
> +
> #define RK3368_PLL_CON(x) RK2928_PLL_CON(x)
> #define RK3368_CLKSEL_CON(x) ((x) * 0x4 + 0x100)
> #define RK3368_CLKGATE_CON(x) ((x) * 0x4 + 0x200)
> @@ -130,6 +152,7 @@
> enum rockchip_pll_type {
> pll_rk3036,
> pll_rk3066,
> + pll_rk3328,
> pll_rk3399,
> };
>
>
--
Best Regards
Shawn Lin
^ permalink raw reply
* [PATCH 1/2] ARM: dts: dra7-evm: Remove pinmux configurations for erratum i869
From: Sekhar Nori @ 2016-12-13 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b80e3cbc8a377abdb40ab11de78ce0b3fb67596f.1480411308.git.nsekhar@ti.com>
On Tuesday 29 November 2016 02:54 PM, Sekhar Nori wrote:
> A side-effect of this patch is that NAND support is removed. NAND
> pins clash with VOUT3 on DRA7-EVM. U-Boot selects VOUT3 over NAND
> as per TI EVM application needs.
I claimed this ..
> &gpmc {
> status = "okay";
> - pinctrl-names = "default";
> - pinctrl-0 = <&nand_flash_x16>;
> ranges = <0 0 0x08000000 0x01000000>; /* minimum GPMC partition = 16MB */
> nand at 0,0 {
> compatible = "ti,omap2-nand";
.. but forgot to keep the gpmc node disabled. I will fix this and send a
v2. dra72-evm-common.dtsi needs a similar patch. Will include that in v2
as well.
Thanks,
Sekhar
^ permalink raw reply
* Re: EXT: imx-sdma UART series failed for i.MX51
From: Alexander Shiyan @ 2016-12-13 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4f8cf2ee-3cd6-31ce-dc12-8a763f19f8e5@ge.com>
>???????????, 12 ??????? 2016, 16:48 +03:00 ?? "Han, Nandor (GE Healthcare)" <nandor.han@ge.com>:
>
>Hi Alexander,
>????Thanks for info. I have already posted a patch that probably will
>fix this issue.
>
>https://lkml.org/lkml/2016/10/11/319
>
>It was already tested on imx6 and imx53. Let me know how it works.
>
>Reference:
>http://lists-archives.com/linux-kernel/28679793-ext-pre-4-9-rc-dma-regression-imx6-sound-etc.html
Yes, it helps me, thanks!
---
^ permalink raw reply
* [PATCH v6 3/5] ARM: dts: stm32: Add I2C1 support for STM32F429 SoC
From: Alexandre Torgue @ 2016-12-13 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481559342-6106-4-git-send-email-cedric.madianga@gmail.com>
Hi Cedric,
On 12/12/2016 05:15 PM, M'boumba Cedric Madianga wrote:
> Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
> Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
Please Add a commit message.
> ---
> arch/arm/boot/dts/stm32f429.dtsi | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
> index 7de52ee..cbdece7 100644
> --- a/arch/arm/boot/dts/stm32f429.dtsi
> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> @@ -48,6 +48,7 @@
> #include "skeleton.dtsi"
> #include "armv7-m.dtsi"
> #include <dt-bindings/pinctrl/stm32f429-pinfunc.h>
> +#include <dt-bindings/mfd/stm32f4-rcc.h>
>
> / {
> clocks {
> @@ -337,6 +338,16 @@
> slew-rate = <2>;
> };
> };
> +
> + i2c1_pins_b: i2c1 at 0 {
> + pins1 {
> + pinmux = <STM32F429_PB9_FUNC_I2C1_SDA>;
> + drive-open-drain;
> + };
> + pins2 {
> + pinmux = <STM32F429_PB6_FUNC_I2C1_SCL>;
> + };
> + };
> };
>
> rcc: rcc at 40023810 {
> @@ -409,6 +420,18 @@
> interrupts = <80>;
> clocks = <&rcc 0 38>;
> };
> +
> + i2c1: i2c at 40005400 {
Can you check the order on device node please ? (should follow base@)
> + compatible = "st,stm32f4-i2c";
> + reg = <0x40005400 0x400>;
> + interrupts = <31>,
> + <32>;
> + resets = <&rcc STM32F4_APB1_RESET(I2C1)>;
> + clocks = <&rcc 0 STM32F4_APB1_CLOCK(I2C1)>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> };
> };
>
>
^ permalink raw reply
* [PATCH RFC 2/2] ARM: nommu: remap exception base address to RAM
From: Russell King - ARM Linux @ 2016-12-13 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161211131255.3221-1-afzal.mohd.ma@gmail.com>
On Sun, Dec 11, 2016 at 06:42:55PM +0530, Afzal Mohammed wrote:
> Remap exception base address to start of RAM in Kernel in !MMU mode.
>
> Based on existing Kconfig help, Kernel was expecting it to be
> configured by external support. Also earlier it was not possible to
> copy the exception table to start of RAM due to Kconfig dependency,
> which has been fixed by a change prior to this.
>
> Kernel text start at an offset of at least 32K to account for page
> tables in MMU case. On a !MMU build too this space is kept aside, and
> since 2 pages (8K) is the maximum for exception plus stubs, it can be
> placed at the start of RAM.
>
> Signed-off-by: Afzal Mohammed <afzal.mohd.ma@gmail.com>
> ---
>
> i am a bit shaky about this change, though it works here on Cortex-A9,
> this probably would have to be made robust so as to not cause issue on
> other v7-A's upon trying to do !MMU (this won't affect normal MMU boot),
> or specifically where security extensions are not enabled. Also effect
> of hypervisor extension also need to be considered. Please let know if
> any better ways to handle this.
>
>
> arch/arm/Kconfig-nommu | 6 +++---
> arch/arm/kernel/head-nommu.S | 6 ++++++
> 2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/Kconfig-nommu b/arch/arm/Kconfig-nommu
> index b7576349528c..f57fbe3d5eb0 100644
> --- a/arch/arm/Kconfig-nommu
> +++ b/arch/arm/Kconfig-nommu
> @@ -46,9 +46,9 @@ config REMAP_VECTORS_TO_RAM
> If your CPU provides a remap facility which allows the exception
> vectors to be mapped to writable memory, say 'n' here.
>
> - Otherwise, say 'y' here. In this case, the kernel will require
> - external support to redirect the hardware exception vectors to
> - the writable versions located at DRAM_BASE.
> + Otherwise, say 'y' here. In this case, the kernel will
> + redirect the hardware exception vectors to the writable
> + versions located at DRAM_BASE.
>
> config ARM_MPU
> bool 'Use the ARM v7 PMSA Compliant MPU'
> diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
> index 6b4eb27b8758..ac31c9647830 100644
> --- a/arch/arm/kernel/head-nommu.S
> +++ b/arch/arm/kernel/head-nommu.S
> @@ -158,6 +158,12 @@ __after_proc_init:
> bic r0, r0, #CR_V
> #endif
> mcr p15, 0, r0, c1, c0, 0 @ write control reg
> +
> +#ifdef CONFIG_REMAP_VECTORS_TO_RAM
> + mov r3, #CONFIG_VECTORS_BASE @ read VECTORS_BASE
> + mcr p15, 0, r3, c12, c0, 0 @ write to VBAR
> +#endif
> +
Is there really any need to do this in head.S ? I believe it's
entirely possible to do it later - arch/arm/mm/nommu.c:paging_init().
Also, if the region setup for the vectors was moved as well, it would
then be possible to check the ID registers to determine whether this
is supported, and make the decision where to locate the vectors base
more dynamically.
That leaves one pr_notice() call using the CONFIG_VECTORS_BASE
constant...
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v6 4/5] ARM: dts: stm32: Add I2C1 support for STM32429 eval board
From: Alexandre Torgue @ 2016-12-13 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481559342-6106-5-git-send-email-cedric.madianga@gmail.com>
Hi Cedric,
On 12/12/2016 05:15 PM, M'boumba Cedric Madianga wrote:
> Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
Can you please add a commit message.
> ---
> arch/arm/boot/dts/stm32429i-eval.dts | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts
> index afb90bc..74e0045 100644
> --- a/arch/arm/boot/dts/stm32429i-eval.dts
> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
> @@ -141,3 +141,9 @@
> pinctrl-names = "default";
> status = "okay";
> };
> +
> +&i2c1 {
> + pinctrl-0 = <&i2c1_pins_b>;
> + pinctrl-names = "default";
> + status = "okay";
> +};
>
^ permalink raw reply
* [PATCH v6 5/5] ARM: configs: stm32: Add I2C support for STM32 defconfig
From: Alexandre Torgue @ 2016-12-13 10:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481559342-6106-6-git-send-email-cedric.madianga@gmail.com>
Hi Cedric,
On 12/12/2016 05:15 PM, M'boumba Cedric Madianga wrote:
> Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
Can you please add a commit message.
Thx in advance
Alex
> ---
> arch/arm/configs/stm32_defconfig | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
> index e7b56d4..9494eaf 100644
> --- a/arch/arm/configs/stm32_defconfig
> +++ b/arch/arm/configs/stm32_defconfig
> @@ -52,6 +52,9 @@ CONFIG_SERIAL_NONSTANDARD=y
> CONFIG_SERIAL_STM32=y
> CONFIG_SERIAL_STM32_CONSOLE=y
> # CONFIG_HW_RANDOM is not set
> +CONFIG_I2C=y
> +CONFIG_I2C_CHARDEV=y
> +CONFIG_I2C_STM32F4=y
> # CONFIG_HWMON is not set
> # CONFIG_USB_SUPPORT is not set
> CONFIG_NEW_LEDS=y
>
^ permalink raw reply
* [PATCH v7 0/5] ARM: dts: da850: tilcdc related DT changes
From: Bartosz Golaszewski @ 2016-12-13 10:09 UTC (permalink / raw)
To: linux-arm-kernel
This series contains the last DT changes required for LCDC support
on da850-lcdk. The first one adds the dumb-vga-dac nodes, the second
limits the maximum pixel clock rate.
v1 -> v2:
- drop patch 3/3 (already merged)
- use max-pixelclock instead of max-bandwidth for display mode limiting
v2 -> v3:
- make the commit message in patch [2/2] more detailed
- move the max-pixelclock property to da850.dtsi as the limit
affects all da850-based boards
v3 -> v4:
- remove the input port from the display node
- move the display ports node to da850-lcdk.dts
- rename the vga_bridge node to vga-bridge
- move the LCDC pins to the LCDC node (from the vga bridge node)
v4 -> v5:
- rename the display label to lcdc
- instead of using the 'dumb-vga-dac' compatible, add bindings for
ti,ths8135 and use it as the vga-bridge node compatible
v5 -> v6:
- drop the endpoint numbers for nodes with single endpoints
- split patch 2/4 from v5 into two separate patches: one adding DT
bindings and one adding actual support for ths8135
v6 -> v7:
- simplified patch 4/5 by removing unnecessary properties from ports
and endpoints nodes
Bartosz Golaszewski (5):
ARM: dts: da850: rename the display node label
drm: bridge: add DT bindings for TI ths8135
drm: bridge: add support for TI ths8135
ARM: dts: da850-lcdk: add the vga-bridge node
ARM: dts: da850: specify the maximum pixel clock rate for tilcdc
.../bindings/display/bridge/ti,ths8135.txt | 46 +++++++++++++++++++
arch/arm/boot/dts/da850-lcdk.dts | 51 ++++++++++++++++++++++
arch/arm/boot/dts/da850.dtsi | 3 +-
drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 +
4 files changed, 100 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
--
2.9.3
^ permalink raw reply
* [PATCH v7 1/5] ARM: dts: da850: rename the display node label
From: Bartosz Golaszewski @ 2016-12-13 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481623759-12786-1-git-send-email-bgolaszewski@baylibre.com>
The tilcdc node name is 'display' as per the ePAPR 1.1 recommendation.
The label is also 'display', but change it to 'lcdc' to make it clear
what the underlying hardware is.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 104155d..6b0ef3d 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -458,7 +458,7 @@
dma-names = "tx", "rx";
};
- display: display at 213000 {
+ lcdc: display at 213000 {
compatible = "ti,da850-tilcdc";
reg = <0x213000 0x1000>;
interrupts = <52>;
--
2.9.3
^ permalink raw reply related
* [PATCH v7 2/5] drm: bridge: add DT bindings for TI ths8135
From: Bartosz Golaszewski @ 2016-12-13 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481623759-12786-1-git-send-email-bgolaszewski@baylibre.com>
THS8135 is a configurable video DAC. Add DT bindings for this chip.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../bindings/display/bridge/ti,ths8135.txt | 46 ++++++++++++++++++++++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
new file mode 100644
index 0000000..6ec1a88
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
@@ -0,0 +1,46 @@
+THS8135 Video DAC
+-----------------
+
+This is the binding for Texas Instruments THS8135 Video DAC bridge.
+
+Required properties:
+
+- compatible: Must be "ti,ths8135"
+
+Required nodes:
+
+This device has two video ports. Their connections are modelled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for RGB input
+- Video port 1 for VGA output
+
+Example
+-------
+
+vga-bridge {
+ compatible = "ti,ths8135";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+
+ vga_bridge_in: endpoint {
+ remote-endpoint = <&lcdc_out_vga>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ vga_bridge_out: endpoint {
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v7 3/5] drm: bridge: add support for TI ths8135
From: Bartosz Golaszewski @ 2016-12-13 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481623759-12786-1-git-send-email-bgolaszewski@baylibre.com>
THS8135 is a configurable video DAC, but no configuration is actually
necessary to make it work.
For now use the dumb-vga-dac driver to support it.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index e570698..86e9f9c 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -237,6 +237,7 @@ static int dumb_vga_remove(struct platform_device *pdev)
static const struct of_device_id dumb_vga_match[] = {
{ .compatible = "dumb-vga-dac" },
+ { .compatible = "ti,ths8135" },
{},
};
MODULE_DEVICE_TABLE(of, dumb_vga_match);
--
2.9.3
^ permalink raw reply related
* [PATCH v7 4/5] ARM: dts: da850-lcdk: add the vga-bridge node
From: Bartosz Golaszewski @ 2016-12-13 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481623759-12786-1-git-send-email-bgolaszewski@baylibre.com>
Add the vga-bridge node to the board DT together with corresponding
ports and vga connector. This allows to retrieve the edid info from
the display automatically.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 51 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 51 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index afcb482..1ae2260 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -51,6 +51,45 @@
system-clock-frequency = <24576000>;
};
};
+
+ vga-bridge {
+ compatible = "ti,ths8135";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+
+ vga_bridge_in: endpoint {
+ remote-endpoint = <&lcdc_out_vga>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ vga_bridge_out: endpoint {
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+ };
+
+ vga {
+ compatible = "vga-connector";
+
+ ddc-i2c-bus = <&i2c0>;
+
+ port {
+ vga_con_in: endpoint {
+ remote-endpoint = <&vga_bridge_out>;
+ };
+ };
+ };
};
&pmx_core {
@@ -236,3 +275,15 @@
&memctrl {
status = "okay";
};
+
+&lcdc {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_pins>;
+
+ port {
+ lcdc_out_vga: endpoint {
+ remote-endpoint = <&vga_bridge_in>;
+ };
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v7 5/5] ARM: dts: da850: specify the maximum pixel clock rate for tilcdc
From: Bartosz Golaszewski @ 2016-12-13 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481623759-12786-1-git-send-email-bgolaszewski@baylibre.com>
At maximum CPU frequency of 300 MHz the maximum pixel clock frequency
is 37.5 MHz[1]. We must filter out any mode for which the calculated
pixel clock rate would exceed this value.
Specify the max-pixelclock property for the display node for
da850-lcdk.
[1] http://processors.wiki.ti.com/index.php/OMAP-L1x/C674x/AM1x_LCD_Controller_(LCDC)_Throughput_and_Optimization_Techniques
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 6b0ef3d..58b1566 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -462,6 +462,7 @@
compatible = "ti,da850-tilcdc";
reg = <0x213000 0x1000>;
interrupts = <52>;
+ max-pixelclock = <37500>;
status = "disabled";
};
};
--
2.9.3
^ permalink raw reply related
* [PATCH v6 4/5] ARM: dts: da850-lcdk: add the vga-bridge node
From: Bartosz Golaszewski @ 2016-12-13 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9d5fa409-bb4f-f62b-2548-0a3b82228e08@ti.com>
2016-12-13 9:46 GMT+01:00 Tomi Valkeinen <tomi.valkeinen@ti.com>:
> Hi,
>
> On 12/12/16 15:05, Bartosz Golaszewski wrote:
>
>> +&lcdc {
>> + status = "okay";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&lcd_pins>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + lcdc_out: port at 1 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <1>;
>> +
>> + lcdc_out_vga: endpoint {
>> + reg = <0>;
>> + remote-endpoint = <&vga_bridge_in>;
>> + };
>> + };
>> + };
>> +};
>>
>
> This is not correct. LCDC has just one output, so port at 1 doesn't make
> sense. It's port at 0. But with just one port, you can leave "ports" away.
> And you don't need the port's label for anything, if I'm not mistaken. So:
>
> &lcdc {
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <&lcd_pins>;
>
> port {
> lcdc_out_vga: endpoint {
> remote-endpoint = <&vga_bridge_in>;
> };
> };
> };
>
> Tomi
>
Right, fixed in v7.
Thanks,
Bartosz
^ permalink raw reply
* [PATCH] ARM: soft-reboot into same mode that we entered the kernel
From: Mark Rutland @ 2016-12-13 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cFRAn-0003ob-HH@rmk-PC.armlinux.org.uk>
Hi,
On Fri, Dec 09, 2016 at 07:49:37PM +0000, Russell King wrote:
> When we soft-reboot (eg, kexec) from one kernel into the next, we need
> to ensure that we enter the new kernel in the same processor mode as
> when we were entered, so that (eg) the new kernel can install its own
> hypervisor - the old kernel's hypervisor will have been overwritten.
>
> In order to do this, we need to pass a flag to cpu_reset() so it knows
> what to do, and we need to modify the kernel's own hypervisor stub to
> allow it to handle a soft-reboot.
>
> As we are always guaranteed to install our own hypervisor if we're
> entered in HYP32 mode, and KVM will have moved itself out of the way
> on kexec/normal reboot, we can assume that our hypervisor is in place
> when we want to kexec, so changing our hypervisor API should not be a
> problem.
>
> Tested-by: Keerthy <j-keerthy@ti.com>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> Mark,
>
> Any opinions on this?
>
> Thanks.
The above sounds like the right thing to do, but I'm not familiar enough
with the 32-bit hyp + kvm code to say much about the implementation.
Hopefully Dave, Marc, or Christoffer have thoughts.
Otherwise, I only have a couple of minor comments below.
>
> arch/arm/include/asm/proc-fns.h | 4 ++--
> arch/arm/kernel/hyp-stub.S | 36 ++++++++++++++++++++++++++++++------
> arch/arm/kernel/reboot.c | 12 ++++++++++--
> arch/arm/mm/proc-v7.S | 12 ++++++++----
> 4 files changed, 50 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/include/asm/proc-fns.h b/arch/arm/include/asm/proc-fns.h
> index 8877ad5ffe10..f2e1af45bd6f 100644
> --- a/arch/arm/include/asm/proc-fns.h
> +++ b/arch/arm/include/asm/proc-fns.h
> @@ -43,7 +43,7 @@ extern struct processor {
> /*
> * Special stuff for a reset
> */
> - void (*reset)(unsigned long addr) __attribute__((noreturn));
> + void (*reset)(unsigned long addr, bool hvc) __attribute__((noreturn));
> /*
> * Idle the processor
> */
> @@ -88,7 +88,7 @@ extern void cpu_set_pte_ext(pte_t *ptep, pte_t pte);
> #else
> extern void cpu_set_pte_ext(pte_t *ptep, pte_t pte, unsigned int ext);
> #endif
> -extern void cpu_reset(unsigned long addr) __attribute__((noreturn));
> +extern void cpu_reset(unsigned long addr, bool hvc) __attribute__((noreturn));
>
> /* These three are private to arch/arm/kernel/suspend.c */
> extern void cpu_do_suspend(void *);
> diff --git a/arch/arm/kernel/hyp-stub.S b/arch/arm/kernel/hyp-stub.S
> index 15d073ae5da2..cab1ac36939d 100644
> --- a/arch/arm/kernel/hyp-stub.S
> +++ b/arch/arm/kernel/hyp-stub.S
> @@ -22,6 +22,9 @@
> #include <asm/assembler.h>
> #include <asm/virt.h>
>
> +#define HVC_GET_VECTORS -1
> +#define HVC_SOFT_RESTART 1
> +
> #ifndef ZIMAGE
> /*
> * For the kernel proper, we need to find out the CPU boot mode long after
> @@ -202,9 +205,18 @@ ARM_BE8(orr r7, r7, #(1 << 25)) @ HSCTLR.EE
> ENDPROC(__hyp_stub_install_secondary)
>
> __hyp_stub_do_trap:
> - cmp r0, #-1
> - mrceq p15, 4, r0, c12, c0, 0 @ get HVBAR
> - mcrne p15, 4, r0, c12, c0, 0 @ set HVBAR
> + cmp r0, #HVC_GET_VECTORS
> + bne 1f
> + mrc p15, 4, r0, c12, c0, 0 @ get HVBAR
> + b __hyp_stub_exit
> +
> +1: teq r0, #HVC_SOFT_RESTART
> + bne 1f
> + mov r0, r3
> + bx r0
> +
> +1: mcrne p15, 4, r0, c12, c0, 0 @ set HVBAR
> +__hyp_stub_exit:
> __ERET
> ENDPROC(__hyp_stub_do_trap)
>
> @@ -231,14 +243,26 @@ ENDPROC(__hyp_stub_do_trap)
> * initialisation entry point.
> */
> ENTRY(__hyp_get_vectors)
> - mov r0, #-1
> + mov r0, #HVC_GET_VECTORS
> + __HVC(0)
> + ret lr
> ENDPROC(__hyp_get_vectors)
> - @ fall through
> +
> ENTRY(__hyp_set_vectors)
> + tst r0, #31
> + bne 1f
> __HVC(0)
> - ret lr
> +1: ret lr
> ENDPROC(__hyp_set_vectors)
Why the new check? This looks unrelated to the rest of the patch.
> +ENTRY(__hyp_soft_restart)
> + mov r3, r0
> + mov r0, #HVC_SOFT_RESTART
> + __HVC(0)
> + mov r0, r3
> + ret lr
> +ENDPROC(__hyp_soft_restart)
> +
> #ifndef ZIMAGE
> .align 2
> .L__boot_cpu_mode_offset:
> diff --git a/arch/arm/kernel/reboot.c b/arch/arm/kernel/reboot.c
> index 3fa867a2aae6..f0e3c7f1ea21 100644
> --- a/arch/arm/kernel/reboot.c
> +++ b/arch/arm/kernel/reboot.c
> @@ -12,10 +12,11 @@
>
> #include <asm/cacheflush.h>
> #include <asm/idmap.h>
> +#include <asm/virt.h>
>
> #include "reboot.h"
>
> -typedef void (*phys_reset_t)(unsigned long);
> +typedef void (*phys_reset_t)(unsigned long, bool);
>
> /*
> * Function pointers to optional machine specific functions
> @@ -36,6 +37,7 @@ static u64 soft_restart_stack[16];
> static void __soft_restart(void *addr)
> {
> phys_reset_t phys_reset;
> + bool hvc = false;
>
> /* Take out a flat memory mapping. */
> setup_mm_for_reboot();
> @@ -51,7 +53,13 @@ static void __soft_restart(void *addr)
>
> /* Switch to the identity mapping. */
> phys_reset = (phys_reset_t)virt_to_idmap(cpu_reset);
> - phys_reset((unsigned long)addr);
> +
> +#ifdef CONFIG_ARM_VIRT_EXT
> + /* original stub should be restored by kvm */
> + hvc = is_hyp_mode_available();
> +#endif
When !CONFIG_ARM_VIRT_EXT, is_hyp_mode_available() is defined so as to
always be false, so we can drop the ifdef here.
> +
> + phys_reset((unsigned long)addr, hvc);
>
> /* Should never get here. */
> BUG();
> diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> index d00d52c9de3e..1846ca4255d0 100644
> --- a/arch/arm/mm/proc-v7.S
> +++ b/arch/arm/mm/proc-v7.S
> @@ -53,11 +53,15 @@ ENDPROC(cpu_v7_proc_fin)
> .align 5
> .pushsection .idmap.text, "ax"
> ENTRY(cpu_v7_reset)
> - mrc p15, 0, r1, c1, c0, 0 @ ctrl register
> - bic r1, r1, #0x1 @ ...............m
> - THUMB( bic r1, r1, #1 << 30 ) @ SCTLR.TE (Thumb exceptions)
> - mcr p15, 0, r1, c1, c0, 0 @ disable MMU
> + mrc p15, 0, r2, c1, c0, 0 @ ctrl register
> + bic r2, r2, #0x1 @ ...............m
> + THUMB( bic r2, r2, #1 << 30 ) @ SCTLR.TE (Thumb exceptions)
> + mcr p15, 0, r2, c1, c0, 0 @ disable MMU
> isb
> +#ifdef CONFIG_ARM_VIRT_EXT
> + teq r1, #0
> + bne __hyp_soft_restart
> +#endif
> bx r0
> ENDPROC(cpu_v7_reset)
> .popsection
> --
> 2.7.4
Thanks,
Mark.
^ permalink raw reply
* [PATCH v3 6/6] mfd: dt: Move syscon bindings to syscon subdirectory
From: Lee Jones @ 2016-12-13 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481604793.3112.32.camel@aj.id.au>
On Tue, 13 Dec 2016, Andrew Jeffery wrote:
> On Mon, 2016-12-12 at 09:39 -0600, Rob Herring wrote:
> > On Tue, Dec 06, 2016 at 01:53:21PM +1100, Andrew Jeffery wrote:
> > > The use of syscons is growing, lets collate them in their own part of
> > > the bindings tree.
> > >
> > > > > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> > > ---
> > > ?Documentation/devicetree/bindings/mfd/{ => syscon}/aspeed-scu.txt?????????| 0
> > > ?Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-gpbr.txt?????????| 0
> > > ?Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-matrix.txt???????| 0
> > > ?Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-smc.txt??????????| 0
> > > ?Documentation/devicetree/bindings/mfd/{ => syscon}/qcom,tcsr.txt??????????| 0
> > > ?Documentation/devicetree/bindings/mfd/{ => syscon}/syscon.txt?????????????| 0
> > > ?.../devicetree/bindings/mfd/{ => syscon}/ti-keystone-devctrl.txt??????????| 0
> > > ?7 files changed, 0 insertions(+), 0 deletions(-)
> > > ?rename Documentation/devicetree/bindings/mfd/{ => syscon}/aspeed-scu.txt (100%)
> > > ?rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-gpbr.txt (100%)
> > > ?rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-matrix.txt (100%)
> > > ?rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-smc.txt (100%)
> > > ?rename Documentation/devicetree/bindings/mfd/{ => syscon}/qcom,tcsr.txt (100%)
> > > ?rename Documentation/devicetree/bindings/mfd/{ => syscon}/syscon.txt (100%)
> > > ?rename Documentation/devicetree/bindings/mfd/{ => syscon}/ti-keystone-devctrl.txt (100%)
> >
> > I'm not so sure this is the right direction. syscon usage is pretty much?
> > spread throughout the tree.
>
> This patch was created based on my interpretation of Lee's feedback
> here:
>
> https://lkml.org/lkml/2016/11/18/650
>
> Lee's next email in the chain poked Arnd for an opinion, but Arnd
> didn't reply.
>
> I don't mind. I moved these bindings separately so we could just drop
> the patch if there was push-back. If we drop the whole idea I'll need
> to apply a small fix to patch 5/6 to avoid creating the syscon
> subdirectory.
The sub-directory is a good idea for drivers who are *solely* syscon
based.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH V6 00/10] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64
From: Shiju Jose @ 2016-12-13 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481147303-7979-1-git-send-email-tbaicar@codeaurora.org>
Hi Tyler,
We have tested V6 patch set on our platform. It worked fine.
Thanks,
Shiju
> -----Original Message-----
> From: Tyler Baicar [mailto:tbaicar at codeaurora.org]
> Sent: 07 December 2016 21:48
> To: christoffer.dall at linaro.org; marc.zyngier at arm.com;
> pbonzini at redhat.com; rkrcmar at redhat.com; linux at armlinux.org.uk;
> catalin.marinas at arm.com; will.deacon at arm.com; rjw at rjwysocki.net;
> lenb at kernel.org; matt at codeblueprint.co.uk; robert.moore at intel.com;
> lv.zheng at intel.com; nkaje at codeaurora.org; zjzhang at codeaurora.org;
> mark.rutland at arm.com; james.morse at arm.com; akpm at linux-foundation.org;
> eun.taik.lee at samsung.com; sandeepa.s.prabhu at gmail.com;
> labbott at redhat.com; shijie.huang at arm.com; rruigrok at codeaurora.org;
> paul.gortmaker at windriver.com; tn at semihalf.com; fu.wei at linaro.org;
> rostedt at goodmis.org; bristot at redhat.com; linux-arm-
> kernel at lists.infradead.org; kvmarm at lists.cs.columbia.edu;
> kvm at vger.kernel.org; linux-kernel at vger.kernel.org; linux-
> acpi at vger.kernel.org; linux-efi at vger.kernel.org; devel at acpica.org;
> Suzuki.Poulose at arm.com; punit.agrawal at arm.com; astone at redhat.com;
> harba at codeaurora.org; hanjun.guo at linaro.org; John Garry; Shiju Jose
> Cc: Tyler Baicar
> Subject: [PATCH V6 00/10] Add UEFI 2.6 and ACPI 6.1 updates for RAS on
> ARM64
>
> When a memory error, CPU error, PCIe error, or other type of hardware
> error that's covered by RAS occurs, firmware should populate the shared
> GHES memory location with the proper GHES structures to notify the OS
> of the error.
> For example, platforms that implement firmware first handling may
> implement separate GHES sources for corrected errors and uncorrected
> errors. If the error is an uncorrectable error, then the firmware will
> notify the OS immediately since the error needs to be handled ASAP. The
> OS will then be able to take the appropriate action needed such as
> offlining a page. If the error is a corrected error, then the firmware
> will not interrupt the OS immediately.
> Instead, the OS will see and report the error the next time it's GHES
> timer expires. The kernel will first parse the GHES structures and
> report the errors through the kernel logs and then notify the user
> space through RAS trace events. This allows user space applications
> such as RAS Daemon to see the errors and report them however the user
> desires. This patchset extends the kernel functionality for RAS errors
> based on updates in the UEFI 2.6 and ACPI 6.1 specifications.
>
> An example flow from firmware to user space could be:
>
> +---------------+
> +-------->| |
> | | GHES polling |--+
> +-------------+ | source | | +---------------+ +----------
> --+
> | | +---------------+ | | Kernel GHES | |
> |
> | Firmware | +-->| CPER AER and |-->| RAS
> trace |
> | | +---------------+ | | EDAC drivers | | event
> |
> +-------------+ | | | +---------------+ +----------
> --+
> | | GHES sci |--+
> +-------->| source |
> +---------------+
>
> Add support for Generic Hardware Error Source (GHES) v2, which
> introduces the capability for the OS to acknowledge the consumption of
> the error record generated by the Reliability, Availability and
> Serviceability (RAS) controller.
> This eliminates potential race conditions between the OS and the RAS
> controller.
>
> Add support for the timestamp field added to the Generic Error Data
> Entry v3, allowing the OS to log the time that the error is generated
> by the firmware, rather than the time the error is consumed. This
> improves the correctness of event sequences when analyzing error logs.
> The timestamp is added in ACPI 6.1, reference Table 18-343 Generic
> Error Data Entry.
>
> Add support for ARMv8 Common Platform Error Record (CPER) per UEFI 2.6
> specification. ARMv8 specific processor error information is reported
> as part of the CPER records. This provides more detail on for
> processor error logs. This can help describe ARMv8 cache, tlb, and bus
> errors.
>
> Synchronous External Abort (SEA) represents a specific processor error
> condition in ARM systems. A handler is added to recognize SEA errors,
> and a notifier is added to parse and report the errors before the
> process is killed. Refer to section N.2.1.1 in the Common Platform
> Error Record appendix of the UEFI 2.6 specification.
>
> Currently the kernel ignores CPER records that are unrecognized.
> On the other hand, UEFI spec allows for non-standard (eg. vendor
> proprietary) error section type in CPER (Common Platform Error Record),
> as defined in section N2.3 of UEFI version 2.5. Therefore, user is not
> able to see hardware error data of non-standard section.
>
> If section Type field of Generic Error Data Entry is unrecognized,
> prints out the raw data in dmesg buffer, and also adds a tracepoint for
> reporting such hardware errors.
>
> Currently even if an error status block's severity is fatal, the kernel
> does not honor the severity level and panic. With the firmware first
> model, the platform could inform the OS about a fatal hardware error
> through the non-NMI GHES notification type. The OS should panic when a
> hardware error record is received with this severity.
>
> Add support to handle SEAs that occur while a KVM guest kernel is
> running. Currently these are unsupported by the guest abort handling.
>
> Depends on: [PATCH v15] acpi, apei, arm64: APEI initial support for
> aarch64.
> https://lkml.org/lkml/2016/12/1/312
>
> V6: Change HEST_TYPE_GENERIC_V2 to IS_HEST_TYPE_GENERIC_V2 for
> readability
> Move APEI helper defines from cper.h to ghes.h
> Add data_len decrement back into print loop
> Change references to ARMv8 to just ARM
> Rewrite ARM processor context info parsing
> Check valid bit of ARM error info field before printing it
> Add include of linux/uuid.h in ghes.c
>
> V5: Fix GHES goto logic for error conditions
> Change ghes_do_read_ack to ghes_ack_error
> Make sure data version check is >= 3
> Use CPER helper functions in print functions
> Make handle_guest_sea() dummy function static for arm
> Add arm to subject line for KVM patch
>
> V4: Add bit offset left shift to read_ack_write value
> Make HEST generic and generic_v2 structures a union in the ghes
> structure
> Move gdata v3 helper functions into ghes.h to avoid duplication
> Reorder the timestamp print and avoid memcpy
> Add helper functions for gdata size checking
> Rename the SEA functions
> Add helper function for GHES panics
> Set fru_id to NULL UUID at variable declaration
> Limit ARM trace event parameters to the needed structures
> Reorder the ARM trace event variables to save space
> Add comment for why we don't pass SEAs to the guest when it aborts
> Move ARM trace event call into GHES driver instead of CPER
>
> V3: Fix unmapped address to the read_ack_register in ghes.c
> Add helper function to get the proper payload based on generic data
> entry
> version
> Move timestamp print to avoid changing function calls in cper.c
> Remove patch "arm64: exception: handle instruction abort at current
> EL"
> since the el1_ia handler is already added in 4.8
> Add EFI and ARM64 dependencies for HAVE_ACPI_APEI_SEA
> Add a new trace event for ARM type errors
> Add support to handle KVM guest SEAs
>
> V2: Add PSCI state print for the ARMv8 error type.
> Separate timestamp year into year and century using BCD format.
> Rebase on top of ACPICA 20160318 release and remove header file
> changes
> in include/acpi/actbl1.h.
> Add panic OS with fatal error status block patch.
> Add processing of unrecognized CPER error section patches with
> updates
> from previous comments. Original patches:
> https://lkml.org/lkml/2015/9/8/646
>
> V1: https://lkml.org/lkml/2016/2/5/544
>
> Jonathan (Zhixiong) Zhang (1):
> acpi: apei: panic OS with fatal error status block
>
> Tyler Baicar (9):
> acpi: apei: read ack upon ghes record consumption
> ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1
> efi: parse ARM processor error
> arm64: exception: handle Synchronous External Abort
> acpi: apei: handle SEA notification type for ARMv8
> efi: print unrecognized CPER section
> ras: acpi / apei: generate trace event for unrecognized CPER section
> trace, ras: add ARM processor error trace event
> arm/arm64: KVM: add guest SEA support
>
> arch/arm/include/asm/kvm_arm.h | 1 +
> arch/arm/include/asm/system_misc.h | 5 +
> arch/arm/kvm/mmu.c | 18 +++-
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/kvm_arm.h | 1 +
> arch/arm64/include/asm/system_misc.h | 15 +++
> arch/arm64/mm/fault.c | 71 ++++++++++--
> drivers/acpi/apei/Kconfig | 14 +++
> drivers/acpi/apei/ghes.c | 189
> +++++++++++++++++++++++++++++---
> drivers/acpi/apei/hest.c | 7 +-
> drivers/firmware/efi/cper.c | 204
> ++++++++++++++++++++++++++++++++---
> drivers/ras/ras.c | 2 +
> include/acpi/ghes.h | 27 ++++-
> include/linux/cper.h | 53 +++++++++
> include/ras/ras_event.h | 100 +++++++++++++++++
> 15 files changed, 664 insertions(+), 44 deletions(-)
>
> --
> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
> Technologies, Inc.
> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
> Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] ARM: soft-reboot into same mode that we entered the kernel
From: Russell King - ARM Linux @ 2016-12-13 11:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213105410.GB19985@leverpostej>
On Tue, Dec 13, 2016 at 10:54:11AM +0000, Mark Rutland wrote:
> Hi,
>
> On Fri, Dec 09, 2016 at 07:49:37PM +0000, Russell King wrote:
> > When we soft-reboot (eg, kexec) from one kernel into the next, we need
> > to ensure that we enter the new kernel in the same processor mode as
> > when we were entered, so that (eg) the new kernel can install its own
> > hypervisor - the old kernel's hypervisor will have been overwritten.
> >
> > In order to do this, we need to pass a flag to cpu_reset() so it knows
> > what to do, and we need to modify the kernel's own hypervisor stub to
> > allow it to handle a soft-reboot.
> >
> > As we are always guaranteed to install our own hypervisor if we're
> > entered in HYP32 mode, and KVM will have moved itself out of the way
> > on kexec/normal reboot, we can assume that our hypervisor is in place
> > when we want to kexec, so changing our hypervisor API should not be a
> > problem.
> >
> > Tested-by: Keerthy <j-keerthy@ti.com>
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > ---
> > Mark,
> >
> > Any opinions on this?
> >
> > Thanks.
>
> The above sounds like the right thing to do, but I'm not familiar enough
> with the 32-bit hyp + kvm code to say much about the implementation.
>
> Hopefully Dave, Marc, or Christoffer have thoughts.
>
> Otherwise, I only have a couple of minor comments below.
>
> >
> > arch/arm/include/asm/proc-fns.h | 4 ++--
> > arch/arm/kernel/hyp-stub.S | 36 ++++++++++++++++++++++++++++++------
> > arch/arm/kernel/reboot.c | 12 ++++++++++--
> > arch/arm/mm/proc-v7.S | 12 ++++++++----
> > 4 files changed, 50 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/proc-fns.h b/arch/arm/include/asm/proc-fns.h
> > index 8877ad5ffe10..f2e1af45bd6f 100644
> > --- a/arch/arm/include/asm/proc-fns.h
> > +++ b/arch/arm/include/asm/proc-fns.h
> > @@ -43,7 +43,7 @@ extern struct processor {
> > /*
> > * Special stuff for a reset
> > */
> > - void (*reset)(unsigned long addr) __attribute__((noreturn));
> > + void (*reset)(unsigned long addr, bool hvc) __attribute__((noreturn));
> > /*
> > * Idle the processor
> > */
> > @@ -88,7 +88,7 @@ extern void cpu_set_pte_ext(pte_t *ptep, pte_t pte);
> > #else
> > extern void cpu_set_pte_ext(pte_t *ptep, pte_t pte, unsigned int ext);
> > #endif
> > -extern void cpu_reset(unsigned long addr) __attribute__((noreturn));
> > +extern void cpu_reset(unsigned long addr, bool hvc) __attribute__((noreturn));
> >
> > /* These three are private to arch/arm/kernel/suspend.c */
> > extern void cpu_do_suspend(void *);
> > diff --git a/arch/arm/kernel/hyp-stub.S b/arch/arm/kernel/hyp-stub.S
> > index 15d073ae5da2..cab1ac36939d 100644
> > --- a/arch/arm/kernel/hyp-stub.S
> > +++ b/arch/arm/kernel/hyp-stub.S
> > @@ -22,6 +22,9 @@
> > #include <asm/assembler.h>
> > #include <asm/virt.h>
> >
> > +#define HVC_GET_VECTORS -1
> > +#define HVC_SOFT_RESTART 1
> > +
> > #ifndef ZIMAGE
> > /*
> > * For the kernel proper, we need to find out the CPU boot mode long after
> > @@ -202,9 +205,18 @@ ARM_BE8(orr r7, r7, #(1 << 25)) @ HSCTLR.EE
> > ENDPROC(__hyp_stub_install_secondary)
> >
> > __hyp_stub_do_trap:
> > - cmp r0, #-1
> > - mrceq p15, 4, r0, c12, c0, 0 @ get HVBAR
> > - mcrne p15, 4, r0, c12, c0, 0 @ set HVBAR
> > + cmp r0, #HVC_GET_VECTORS
> > + bne 1f
> > + mrc p15, 4, r0, c12, c0, 0 @ get HVBAR
> > + b __hyp_stub_exit
> > +
> > +1: teq r0, #HVC_SOFT_RESTART
> > + bne 1f
> > + mov r0, r3
> > + bx r0
> > +
> > +1: mcrne p15, 4, r0, c12, c0, 0 @ set HVBAR
> > +__hyp_stub_exit:
> > __ERET
> > ENDPROC(__hyp_stub_do_trap)
> >
> > @@ -231,14 +243,26 @@ ENDPROC(__hyp_stub_do_trap)
> > * initialisation entry point.
> > */
> > ENTRY(__hyp_get_vectors)
> > - mov r0, #-1
> > + mov r0, #HVC_GET_VECTORS
> > + __HVC(0)
> > + ret lr
> > ENDPROC(__hyp_get_vectors)
> > - @ fall through
> > +
> > ENTRY(__hyp_set_vectors)
> > + tst r0, #31
> > + bne 1f
> > __HVC(0)
> > - ret lr
> > +1: ret lr
> > ENDPROC(__hyp_set_vectors)
>
> Why the new check? This looks unrelated to the rest of the patch.
It's not unrelated. The ARM32 hyp-stub has a total crap ABI:
- r0 = -1 => read VBAR
- r0 != -1 => write r0 to VBAR
So, this check is there to ensure that you can't do something stupid
like:
__hyp_set_vectors(1)
and inadvertently end up invoking the restart method - the check is
there to "make room" for the new hyp call in the ABI.
It hasn't been clear what the scope of the API, or the stub ABI actually
is - nothing about that is really documented, so I didn't want to
radically redesign the stub ABI to be more sensible and risk breakage
elsewhere - especially as I'm reliant on others to test this. (All my
32-bit platforms enter the kernel in SVC mode from the boot loader, even
those which are virtualisation-capable.)
> > +ENTRY(__hyp_soft_restart)
> > + mov r3, r0
> > + mov r0, #HVC_SOFT_RESTART
> > + __HVC(0)
> > + mov r0, r3
> > + ret lr
> > +ENDPROC(__hyp_soft_restart)
> > +
> > #ifndef ZIMAGE
> > .align 2
> > .L__boot_cpu_mode_offset:
> > diff --git a/arch/arm/kernel/reboot.c b/arch/arm/kernel/reboot.c
> > index 3fa867a2aae6..f0e3c7f1ea21 100644
> > --- a/arch/arm/kernel/reboot.c
> > +++ b/arch/arm/kernel/reboot.c
> > @@ -12,10 +12,11 @@
> >
> > #include <asm/cacheflush.h>
> > #include <asm/idmap.h>
> > +#include <asm/virt.h>
> >
> > #include "reboot.h"
> >
> > -typedef void (*phys_reset_t)(unsigned long);
> > +typedef void (*phys_reset_t)(unsigned long, bool);
> >
> > /*
> > * Function pointers to optional machine specific functions
> > @@ -36,6 +37,7 @@ static u64 soft_restart_stack[16];
> > static void __soft_restart(void *addr)
> > {
> > phys_reset_t phys_reset;
> > + bool hvc = false;
> >
> > /* Take out a flat memory mapping. */
> > setup_mm_for_reboot();
> > @@ -51,7 +53,13 @@ static void __soft_restart(void *addr)
> >
> > /* Switch to the identity mapping. */
> > phys_reset = (phys_reset_t)virt_to_idmap(cpu_reset);
> > - phys_reset((unsigned long)addr);
> > +
> > +#ifdef CONFIG_ARM_VIRT_EXT
> > + /* original stub should be restored by kvm */
> > + hvc = is_hyp_mode_available();
> > +#endif
>
> When !CONFIG_ARM_VIRT_EXT, is_hyp_mode_available() is defined so as to
> always be false, so we can drop the ifdef here.
Ok.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v5] arm64: fpsimd: improve stacking logic in non-interruptible context
From: Dave Martin @ 2016-12-13 11:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481565387-8039-1-git-send-email-ard.biesheuvel@linaro.org>
On Mon, Dec 12, 2016 at 05:56:27PM +0000, Ard Biesheuvel wrote:
> Currently, we allow kernel mode NEON in softirq or hardirq context by
> stacking and unstacking a slice of the NEON register file for each call
> to kernel_neon_begin() and kernel_neon_end(), respectively.
>
> Given that
> a) a CPU typically spends most of its time in userland, during which time
> no kernel mode NEON in process context is in progress,
> b) a CPU spends most of its time in the kernel doing other things than
> kernel mode NEON when it gets interrupted to perform kernel mode NEON
> in softirq context
>
> the stacking and subsequent unstacking is only necessary if we are
> interrupting a thread while it is performing kernel mode NEON in process
> context, which means that in all other cases, we can simply preserve the
> userland FPSIMD state once, and only restore it upon return to userland,
> even if we are being invoked from softirq or hardirq context.
>
> So instead of checking whether we are running in interrupt context, keep
> track of the level of nested kernel mode NEON calls in progress, and only
> perform the eager stack/unstack if the level exceeds 1.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm64/kernel/fpsimd.c | 64 +++++++++++++++++++++++++++++++++-------------
> 1 file changed, 46 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 394c61db5566..c19363775436 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -220,45 +220,73 @@ void fpsimd_flush_task_state(struct task_struct *t)
>
> #ifdef CONFIG_KERNEL_MODE_NEON
>
> -static DEFINE_PER_CPU(struct fpsimd_partial_state, hardirq_fpsimdstate);
> -static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate);
> +/*
> + * Although unlikely, it is possible for three kernel mode NEON contexts to
> + * be live at the same time: process context, softirq context and hardirq
> + * context. So while the userland context is stashed in the thread's fpsimd
> + * state structure, we need two additional levels of storage.
> + */
> +static DEFINE_PER_CPU(struct fpsimd_partial_state, nested_fpsimdstate[2]);
> +static DEFINE_PER_CPU(int, kernel_neon_nesting_level);
>
> /*
> * Kernel-side NEON support functions
> */
> void kernel_neon_begin_partial(u32 num_regs)
> {
> - if (in_interrupt()) {
> - struct fpsimd_partial_state *s = this_cpu_ptr(
> - in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
> + struct fpsimd_partial_state *s;
> + int level;
>
> - BUG_ON(num_regs > 32);
> - fpsimd_save_partial_state(s, roundup(num_regs, 2));
> - } else {
> + preempt_disable();
> +
> + if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {
> /*
> * Save the userland FPSIMD state if we have one and if we
> * haven't done so already. Clear fpsimd_last_state to indicate
> * that there is no longer userland FPSIMD state in the
> * registers.
> */
> - preempt_disable();
> - if (current->mm &&
> - !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE))
> - fpsimd_save_state(¤t->thread.fpsimd_state);
> + if (current->mm) {
> + unsigned long flags;
> +
> + local_irq_save(flags);
For non-SVE hardware (i.e., all hardware for now), this raises mean IRQ
latency if KERNEL_MODE_NEON is used, to fix a bug that doesn't exist.
For SVE hardware, we would be disabling interrupts around typically a
few KB of stores. I don't know what the actual hardware numbers would
look like, but this feels like a disproportionate cost to the problem
being solved...
After all, why do this here...
> + if (!test_and_set_thread_flag(TIF_FOREIGN_FPSTATE))
> + fpsimd_save_state(¤t->thread.fpsimd_state);
> + local_irq_restore(flags);
> + } else {
> + set_thread_flag(TIF_FOREIGN_FPSTATE);
> + }
> this_cpu_write(fpsimd_last_state, NULL);
> }
> +
> + level = this_cpu_inc_return(kernel_neon_nesting_level);
...and yet go to all this trouble to avoid disabling IRQs for a _nested_
kernel_neon_begin()?
Did I miss something, or does increasing the count around the outermost
case too without IRQ disabling not work, in the non-SVE case?
Cheers
---Dave
> + BUG_ON(level > 3);
> +
> + if (level > 1) {
> + s = this_cpu_ptr(nested_fpsimdstate);
> +
> + WARN_ON_ONCE(num_regs > 32);
> + num_regs = min(roundup(num_regs, 2), 32U);
> +
> + fpsimd_save_partial_state(&s[level - 2], num_regs);
> + }
> }
> EXPORT_SYMBOL(kernel_neon_begin_partial);
>
> void kernel_neon_end(void)
> {
> - if (in_interrupt()) {
> - struct fpsimd_partial_state *s = this_cpu_ptr(
> - in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
> - fpsimd_load_partial_state(s);
> - } else {
> - preempt_enable();
> + struct fpsimd_partial_state *s;
> + int level;
> +
> + level = this_cpu_read(kernel_neon_nesting_level);
> + BUG_ON(level < 1);
> +
> + if (level > 1) {
> + s = this_cpu_ptr(nested_fpsimdstate);
> + fpsimd_load_partial_state(&s[level - 2]);
> }
> + this_cpu_dec(kernel_neon_nesting_level);
> + preempt_enable();
> }
> EXPORT_SYMBOL(kernel_neon_end);
>
> --
> 2.7.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 3/8] PWM: add pwm-stm32 DT bindings
From: Lee Jones @ 2016-12-13 11:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212190205.b5t3x6i2o7igldlo@rob-hp-laptop>
On Mon, 12 Dec 2016, Rob Herring wrote:
> On Fri, Dec 09, 2016 at 03:15:14PM +0100, Benjamin Gaignard wrote:
> > Define bindings for pwm-stm32
> >
> > version 6:
> > - change st,breakinput parameter format to make it usuable on stm32f7 too.
> >
> > version 2:
> > - use parameters instead of compatible of handle the hardware configuration
> >
> > Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> > ---
> > .../devicetree/bindings/pwm/pwm-stm32.txt | 33 ++++++++++++++++++++++
> > 1 file changed, 33 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> >
> > diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> > new file mode 100644
> > index 0000000..866f222
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> > @@ -0,0 +1,33 @@
> > +STMicroelectronics STM32 Timers PWM bindings
> > +
> > +Must be a sub-node of an STM32 Timers device tree node.
> > +See ../mfd/stm32-timers.txt for details about the parent node.
> > +
> > +Required parameters:
> > +- compatible: Must be "st,stm32-pwm".
> > +- pinctrl-names: Set to "default".
> > +- pinctrl-0: List of phandles pointing to pin configuration nodes for PWM module.
> > + For Pinctrl properties see ../pinctrl/pinctrl-bindings.txt
> > +
> > +Optional parameters:
> > +- st,breakinput: Arrays of three u32 <index level filter> to describe break input configurations.
> > + "index" indicates on which break input the configuration should be applied.
> > + "level" gives the active level (0=low or 1=high) for this configuration.
> > + "filter" gives the filtering value to be applied.
> > +
> > +Example:
> > + timers at 40010000 {
>
> timer at ...
No, it should be timers.
The 's' is intentional, since this parent (MFD) device houses 3
different types of timers. The "timer" node is a child of this one.
> With that,
>
> Acked-by: Rob Herring <robh@kernel.org>
>
>
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + compatible = "st,stm32-timers";
> > + reg = <0x40010000 0x400>;
> > + clocks = <&rcc 0 160>;
> > + clock-names = "clk_int";
> > +
> > + pwm {
> > + compatible = "st,stm32-pwm";
> > + pinctrl-0 = <&pwm1_pins>;
> > + pinctrl-names = "default";
> > + st,breakinput = <0 1 5>;
> > + };
> > + };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2] rtc: armada38x: Followed the new recommendation for errata implementation
From: Gregory CLEMENT @ 2016-12-13 11:25 UTC (permalink / raw)
To: linux-arm-kernel
According to RES-3124064:
The device supports CPU write and read access to the RTC time register.
However, due to this restriction, read and write from/to internal RTC
register may fail.
Workaround:
General setup:
1. Configure the RTC Mbus Bridge Timing Control register (offset 0x184A0)
to value 0xFD4D4FFF
Write RTC WRCLK Period to its maximum value (0x3FF)
Write RTC WRCLK setup to 0x29
Write RTC WRCLK High Time to 0x53 (default value)
Write RTC Read Output Delay to its maximum value (0x1F)
Mbus - Read All Byte Enable to 0x1 (default value)
2. Configure the RTC Test Configuration Register (offset 0xA381C) bit3
to '1' (Reserved, Marvell internal)
For any RTC register read operation:
1. Read the requested register 100 times.
2. Find the result that appears most frequently and use this result
as the correct value.
For any RTC register write operation:
1. Issue two dummy writes of 0x0 to the RTC Status register (offset
0xA3800).
2. Write the time to the RTC Time register (offset 0xA380C).
This patch is based on the work of Shaker Daibes
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
Hi,
this patch followed the patch series sent here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/473232.html
For now I kept the patch 2 converting to time64_t apart after Russell
King feedback.
I merged the patch 1 and 3 and I also substantially modified the 1st
patch with I think a better implementation.
- First I do not put anymore more a big array onto the stack as
suggested by Andrew Lunn.
- Then I optimize the way to find the correct value.
Gregory
drivers/rtc/rtc-armada38x.c | 121 +++++++++++++++++++++++++++++++++++---------
1 file changed, 97 insertions(+), 24 deletions(-)
diff --git a/drivers/rtc/rtc-armada38x.c b/drivers/rtc/rtc-armada38x.c
index 9a3f2a6f512e..458ef8da0484 100644
--- a/drivers/rtc/rtc-armada38x.c
+++ b/drivers/rtc/rtc-armada38x.c
@@ -29,50 +29,119 @@
#define RTC_TIME 0xC
#define RTC_ALARM1 0x10
+#define SOC_RTC_BRIDGE_TIMING_CTL 0x0
+#define SOC_RTC_PERIOD_OFFS 0
+#define SOC_RTC_PERIOD_MASK (0x3FF << SOC_RTC_PERIOD_OFFS)
+#define SOC_RTC_READ_DELAY_OFFS 26
+#define SOC_RTC_READ_DELAY_MASK (0x1F << SOC_RTC_READ_DELAY_OFFS)
+
#define SOC_RTC_INTERRUPT 0x8
#define SOC_RTC_ALARM1 BIT(0)
#define SOC_RTC_ALARM2 BIT(1)
#define SOC_RTC_ALARM1_MASK BIT(2)
#define SOC_RTC_ALARM2_MASK BIT(3)
+
+#define SAMPLE_NR 100
+
+struct value_to_freq {
+ u32 value;
+ u8 freq;
+};
+
struct armada38x_rtc {
struct rtc_device *rtc_dev;
void __iomem *regs;
void __iomem *regs_soc;
spinlock_t lock;
int irq;
+ struct value_to_freq *val_to_freq;
};
/*
* According to the datasheet, the OS should wait 5us after every
* register write to the RTC hard macro so that the required update
* can occur without holding off the system bus
+ * According to errata FE-3124064, Write to any RTC register
+ * may fail. As a workaround, before writing to RTC
+ * register, issue a dummy write of 0x0 twice to RTC Status
+ * register.
*/
+
static void rtc_delayed_write(u32 val, struct armada38x_rtc *rtc, int offset)
{
+ writel(0, rtc->regs + RTC_STATUS);
+ writel(0, rtc->regs + RTC_STATUS);
writel(val, rtc->regs + offset);
udelay(5);
}
+/* Update RTC-MBUS bridge timing parameters */
+static void rtc_update_mbus_timing_params(struct armada38x_rtc *rtc)
+{
+ uint32_t reg;
+
+ reg = readl(rtc->regs_soc + SOC_RTC_BRIDGE_TIMING_CTL);
+ reg &= ~SOC_RTC_PERIOD_MASK;
+ reg |= 0x3FF << SOC_RTC_PERIOD_OFFS; /* Maximum value */
+ reg &= ~SOC_RTC_READ_DELAY_MASK;
+ reg |= 0x1F << SOC_RTC_READ_DELAY_OFFS; /* Maximum value */
+ writel(reg, rtc->regs_soc + SOC_RTC_BRIDGE_TIMING_CTL);
+}
+
+static u32 read_rtc_register_wa(struct armada38x_rtc *rtc, u8 rtc_reg)
+{
+ int i, index_max, max = 0;
+
+ for (i = 0; i < SAMPLE_NR; i++) {
+ rtc->val_to_freq[i].value = readl(rtc->regs + rtc_reg);
+ rtc->val_to_freq[i].freq = 0;
+ }
+
+ for (i = 0; i < SAMPLE_NR; i++) {
+ int j = 0;
+ u32 value = rtc->val_to_freq[i].value;
+
+ while (rtc->val_to_freq[j].freq) {
+ if (rtc->val_to_freq[j].value == value) {
+ rtc->val_to_freq[j].freq++;
+ break;
+ }
+ j++;
+ }
+
+ if (!rtc->val_to_freq[j].freq) {
+ rtc->val_to_freq[j].value = value;
+ rtc->val_to_freq[j].freq = 1;
+ }
+
+ if (rtc->val_to_freq[j].freq > max) {
+ index_max = j;
+ max = rtc->val_to_freq[j].freq;
+ }
+
+ /*
+ * If a value have already half of the sample this is
+ * the most frequent one and we can stop the research
+ * right now
+ */
+ if (max > SAMPLE_NR / 2)
+ break;
+ }
+
+ return rtc->val_to_freq[index_max].value;
+}
+
static int armada38x_rtc_read_time(struct device *dev, struct rtc_time *tm)
{
struct armada38x_rtc *rtc = dev_get_drvdata(dev);
- unsigned long time, time_check, flags;
+ unsigned long time, flags;
spin_lock_irqsave(&rtc->lock, flags);
- time = readl(rtc->regs + RTC_TIME);
- /*
- * WA for failing time set attempts. As stated in HW ERRATA if
- * more than one second between two time reads is detected
- * then read once again.
- */
- time_check = readl(rtc->regs + RTC_TIME);
- if ((time_check - time) > 1)
- time_check = readl(rtc->regs + RTC_TIME);
-
+ time = read_rtc_register_wa(rtc, RTC_TIME);
spin_unlock_irqrestore(&rtc->lock, flags);
- rtc_time_to_tm(time_check, tm);
+ rtc_time_to_tm(time, tm);
return 0;
}
@@ -87,16 +156,9 @@ static int armada38x_rtc_set_time(struct device *dev, struct rtc_time *tm)
if (ret)
goto out;
- /*
- * According to errata FE-3124064, Write to RTC TIME register
- * may fail. As a workaround, after writing to RTC TIME
- * register, issue a dummy write of 0x0 twice to RTC Status
- * register.
- */
+
spin_lock_irqsave(&rtc->lock, flags);
rtc_delayed_write(time, rtc, RTC_TIME);
- rtc_delayed_write(0, rtc, RTC_STATUS);
- rtc_delayed_write(0, rtc, RTC_STATUS);
spin_unlock_irqrestore(&rtc->lock, flags);
out:
@@ -111,8 +173,8 @@ static int armada38x_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alrm)
spin_lock_irqsave(&rtc->lock, flags);
- time = readl(rtc->regs + RTC_ALARM1);
- val = readl(rtc->regs + RTC_IRQ1_CONF) & RTC_IRQ1_AL_EN;
+ time = read_rtc_register_wa(rtc, RTC_ALARM1);
+ val = read_rtc_register_wa(rtc, RTC_IRQ1_CONF) & RTC_IRQ1_AL_EN;
spin_unlock_irqrestore(&rtc->lock, flags);
@@ -182,7 +244,7 @@ static irqreturn_t armada38x_rtc_alarm_irq(int irq, void *data)
val = readl(rtc->regs_soc + SOC_RTC_INTERRUPT);
writel(val & ~SOC_RTC_ALARM1, rtc->regs_soc + SOC_RTC_INTERRUPT);
- val = readl(rtc->regs + RTC_IRQ1_CONF);
+ val = read_rtc_register_wa(rtc, RTC_IRQ1_CONF);
/* disable all the interrupts for alarm 1 */
rtc_delayed_write(0, rtc, RTC_IRQ1_CONF);
/* Ack the event */
@@ -196,7 +258,6 @@ static irqreturn_t armada38x_rtc_alarm_irq(int irq, void *data)
else
event |= RTC_PF;
}
-
rtc_update_irq(rtc->rtc_dev, 1, event);
return IRQ_HANDLED;
@@ -221,6 +282,11 @@ static __init int armada38x_rtc_probe(struct platform_device *pdev)
if (!rtc)
return -ENOMEM;
+ rtc->val_to_freq = devm_kcalloc(&pdev->dev, SAMPLE_NR,
+ sizeof(struct value_to_freq), GFP_KERNEL);
+ if (!rtc->val_to_freq)
+ return -ENOMEM;
+
spin_lock_init(&rtc->lock);
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "rtc");
@@ -253,6 +319,9 @@ static __init int armada38x_rtc_probe(struct platform_device *pdev)
if (rtc->irq != -1)
device_init_wakeup(&pdev->dev, 1);
+ /* Update RTC-MBUS bridge timing parameters */
+ rtc_update_mbus_timing_params(rtc);
+
rtc->rtc_dev = devm_rtc_device_register(&pdev->dev, pdev->name,
&armada38x_rtc_ops, THIS_MODULE);
if (IS_ERR(rtc->rtc_dev)) {
@@ -260,6 +329,7 @@ static __init int armada38x_rtc_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "Failed to register RTC device: %d\n", ret);
return ret;
}
+
return 0;
}
@@ -280,6 +350,9 @@ static int armada38x_rtc_resume(struct device *dev)
if (device_may_wakeup(dev)) {
struct armada38x_rtc *rtc = dev_get_drvdata(dev);
+ /* Update RTC-MBUS bridge timing parameters */
+ rtc_update_mbus_timing_params(rtc);
+
return disable_irq_wake(rtc->irq);
}
--
2.10.2
^ permalink raw reply related
* [PATCH v2 0/3] ARM: dts: dra7-evm: pinmuxing updates
From: Sekhar Nori @ 2016-12-13 11:29 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This patch series drops most of the pinmuxing from dra7-evm
to satisfy erratum i869 and adds missing eMMC and SD card pinmuxing.
The patches apply to latest linux-next. Tested on DRA74x EVM Rev H
using U-Boot 2016.11. Boot tested using NFS and basic testing carried
out on SD card, eMMC, Audio capture and playback.
NAND on DRA72 EVM is already unusable due to a similar patch. A patch
included here disables the GPMC node.
v1 -> v2:
- Add a patch to disable GPMC node on DRA72x EVM
- Disable GPMC node on DRA74x EVM
Kishon Vijay Abraham I (1):
ARM: dts: dra7-evm: add pinmux configuration for mmc1/2
Sekhar Nori (2):
ARM: dts: dra7-evm: Remove pinmux configurations for erratum i869
ARM: dts: dra72-evm: drop NAND support
arch/arm/boot/dts/dra7-evm.dts | 282 ++++----------------------------
arch/arm/boot/dts/dra72-evm-common.dtsi | 7 +-
2 files changed, 35 insertions(+), 254 deletions(-)
--
2.9.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox