* [PATCH v2 renesas/devel 01/13] ARM: dts: r8a7779: Use R-Car Gen 1 fallback binding for i2c nodes
From: Simon Horman @ 2016-12-13 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481629559-14187-1-git-send-email-horms+renesas@verge.net.au>
Use recently added R-Car Gen 1 fallback binding for i2c nodes in
DT for r8a7779 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7779 and the
fallback binding for R-Car Gen 1.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/r8a7779.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 55a7c1e37c57..f47a0edc26d4 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -173,7 +173,7 @@
i2c0: i2c at ffc70000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7779";
+ compatible = "renesas,i2c-r8a7779", "renesas,rcar-gen1-i2c";
reg = <0xffc70000 0x1000>;
interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp0_clks R8A7779_CLK_I2C0>;
@@ -184,7 +184,7 @@
i2c1: i2c at ffc71000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7779";
+ compatible = "renesas,i2c-r8a7779", "renesas,rcar-gen1-i2c";
reg = <0xffc71000 0x1000>;
interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp0_clks R8A7779_CLK_I2C1>;
@@ -195,7 +195,7 @@
i2c2: i2c at ffc72000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7779";
+ compatible = "renesas,i2c-r8a7779", "renesas,rcar-gen1-i2c";
reg = <0xffc72000 0x1000>;
interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp0_clks R8A7779_CLK_I2C2>;
@@ -206,7 +206,7 @@
i2c3: i2c at ffc73000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7779";
+ compatible = "renesas,i2c-r8a7779", "renesas,rcar-gen1-i2c";
reg = <0xffc73000 0x1000>;
interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp0_clks R8A7779_CLK_I2C3>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH v2 renesas/devel 00/13] ARM, arm64: dts: Use R-Car fallback bindings for i2c/iic nodes
From: Simon Horman @ 2016-12-13 11:45 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
this short series makes use of newly added R-Car fallback bindings in i2c
and iic nodes of the DTs for SoCs where the drivers in question are already
used.
This should have no run-time effect at this time as the current driver
implementations use the same initialisation squeuences for SoC-specific and
R-Car fallback bindings for all the cases covered by this patch-set.
Based on renesas-devel-20161212-v4.9
Changes since v1:
* s/iii/iic/
* Differentiate subject lines for i2c and iic patches
* Reviewed-by tags from Geert
Simon Horman (13):
ARM: dts: r8a7779: Use R-Car Gen 1 fallback binding for i2c nodes
ARM: dts: r8a7778: Use R-Car Gen 1 fallback binding for i2c nodes
ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for i2c nodes
ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for i2c nodes
ARM: dts: r8a7792: Use R-Car Gen 2 fallback binding for i2c nodes
ARM: dts: r8a7793: Use R-Car Gen 2 fallback binding for i2c nodes
ARM: dts: r8a7794: Use R-Car Gen 2 fallback binding for i2c nodes
arm64: dts: r8a7795: Use R-Car Gen 3 fallback binding for i2c nodes
arm64: dts: r8a7796: Use R-Car Gen 3 fallback binding for i2c nodes
ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for iic nodes
ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for iic nodes
ARM: dts: r8a7793: Use R-Car Gen 2 fallback binding for iic nodes
ARM: dts: r8a7794: Use R-Car Gen 2 fallback binding for iic nodes
arch/arm/boot/dts/r8a7778.dtsi | 8 ++++----
arch/arm/boot/dts/r8a7779.dtsi | 8 ++++----
arch/arm/boot/dts/r8a7790.dtsi | 20 ++++++++++++--------
arch/arm/boot/dts/r8a7791.dtsi | 21 ++++++++++++---------
arch/arm/boot/dts/r8a7792.dtsi | 18 ++++++++++++------
arch/arm/boot/dts/r8a7793.dtsi | 21 ++++++++++++---------
arch/arm/boot/dts/r8a7794.dtsi | 18 ++++++++++--------
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 21 ++++++++++++++-------
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 21 ++++++++++++++-------
9 files changed, 94 insertions(+), 62 deletions(-)
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply
* [PATCH v5] arm64: fpsimd: improve stacking logic in non-interruptible context
From: Ard Biesheuvel @ 2016-12-13 11:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213111120.GF1574@e103592.cambridge.arm.com>
On 13 December 2016 at 11:11, Dave Martin <Dave.Martin@arm.com> wrote:
> 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...
>
That is a fair point. We'd be better off doing a spin_trylock)_, and
whoever gets the lock first can perform the fpsimd_save_state() until
completion.
> 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()?
>
I am not sure I follow here: do you mean the this_cpu_inc_return would
be simpler if we would en-/disable interrupts?
> Did I miss something, or does increasing the count around the outermost
> case too without IRQ disabling not work, in the non-SVE case?
>
I think it does work for the non-SVE case, since it will restore the
FP/SIMD state after returning.
^ permalink raw reply
* [PATCH] ARM: soft-reboot into same mode that we entered the kernel
From: Mark Rutland @ 2016-12-13 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213111115.GX14217@n2100.armlinux.org.uk>
On Tue, Dec 13, 2016 at 11:11:15AM +0000, Russell King - ARM Linux wrote:
> On Tue, Dec 13, 2016 at 10:54:11AM +0000, Mark Rutland wrote:
> > On Fri, Dec 09, 2016 at 07:49:37PM +0000, Russell King wrote:
> > > 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.
Ok. This is definitely less than ideal.
We should be able to fix that up more generally, and pass separate
parameters (as we do on arm64).
> It hasn't been clear what the scope of the API, or the stub ABI actually
> is - nothing about that is really documented,
The hyp-stub is part of the kernel image, and the API is private to that
particular image, so we can change things -- there's no ABI to worry
about.
> 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.)
Sure. I'm more than willing to review/test patches for this.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v2 3/3] ARM: dts: dra72-evm: drop NAND support
From: Sekhar Nori @ 2016-12-13 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1481628266.git.nsekhar@ti.com>
For the existing IOdelay configuration via U-Boot, NAND is
not supported on dra72-evm (both Rev B and Rev C).
Disable it. Commit 46cfc8945887 ("ARM: dts: dra72-evm: Remove
pinmux configurations for erratum i869") has already removed
pinmuxing for NAND making it unusable.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
arch/arm/boot/dts/dra72-evm-common.dtsi | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dra72-evm-common.dtsi b/arch/arm/boot/dts/dra72-evm-common.dtsi
index e50fbeea96e0..64553476c678 100644
--- a/arch/arm/boot/dts/dra72-evm-common.dtsi
+++ b/arch/arm/boot/dts/dra72-evm-common.dtsi
@@ -280,7 +280,12 @@
};
&gpmc {
- status = "okay";
+ /*
+ * For the existing IOdelay configuration via U-Boot we don't
+ * support NAND on dra72-evm. Keep it disabled. Enabling it
+ * requires a different configuration by U-Boot.
+ */
+ status = "disabled";
ranges = <0 0 0x08000000 0x01000000>; /* minimum GPMC partition = 16MB */
nand at 0,0 {
/* To use NAND, DIP switch SW5 must be set like so:
--
2.9.0
^ permalink raw reply related
* [PATCH v2 2/3] ARM: dts: dra7-evm: add pinmux configuration for mmc1/2
From: Sekhar Nori @ 2016-12-13 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1481628266.git.nsekhar@ti.com>
From: Kishon Vijay Abraham I <kishon@ti.com>
Add pinmux configuration for SD card slot and eMMC device
found on TI's DRA74x EVM.
Only the default modes are supported. For higher speed modes
(UHS and HS200) to function, we need full fledged IODelay support
in kernel. IODelay support is yet to be added.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
[nsekhar at ti.com: rebase to mainline/master, use IOPAD() macro,
update commit message]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
arch/arm/boot/dts/dra7-evm.dts | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 80ebfd6a5c7b..40465d5277e6 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -164,6 +164,33 @@
DRA7XX_CORE_IOPAD(0x3818, MUX_MODE15 | PULL_UP) /* wakeup0.off */
>;
};
+
+ mmc1_pins_default: mmc1_pins_default {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x376c, PIN_INPUT | MUX_MODE14) /* mmc1sdcd.gpio219 */
+ DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_clk.clk */
+ DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_cmd.cmd */
+ DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat0.dat0 */
+ DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat1.dat1 */
+ DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat2.dat2 */
+ DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc1_dat3.dat3 */
+ >;
+ };
+
+ mmc2_pins_default: mmc2_pins_default {
+ pinctrl-single,pins = <
+ DRA7XX_CORE_IOPAD(0x349c, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a23.mmc2_clk */
+ DRA7XX_CORE_IOPAD(0x34b0, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_cs1.mmc2_cmd */
+ DRA7XX_CORE_IOPAD(0x34a0, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a24.mmc2_dat0 */
+ DRA7XX_CORE_IOPAD(0x34a4, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a25.mmc2_dat1 */
+ DRA7XX_CORE_IOPAD(0x34a8, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a26.mmc2_dat2 */
+ DRA7XX_CORE_IOPAD(0x34ac, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a27.mmc2_dat3 */
+ DRA7XX_CORE_IOPAD(0x348c, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a19.mmc2_dat4 */
+ DRA7XX_CORE_IOPAD(0x3490, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a20.mmc2_dat5 */
+ DRA7XX_CORE_IOPAD(0x3494, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a21.mmc2_dat6 */
+ DRA7XX_CORE_IOPAD(0x3498, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_a22.mmc2_dat7 */
+ >;
+ };
};
&i2c1 {
@@ -402,6 +429,8 @@
&mmc1 {
status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins_default>;
vmmc-supply = <&evm_3v3_sd>;
vmmc_aux-supply = <&ldo1_reg>;
bus-width = <4>;
@@ -414,6 +443,8 @@
&mmc2 {
status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_pins_default>;
vmmc-supply = <&evm_3v3_sw>;
bus-width = <8>;
};
--
2.9.0
^ permalink raw reply related
* [PATCH v2 1/3] ARM: dts: dra7-evm: Remove pinmux configurations for erratum i869
From: Sekhar Nori @ 2016-12-13 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1481628266.git.nsekhar@ti.com>
Pinmuxing for DRA7x/AM57x family of processors need to be done in IO
isolation as part of initial bootloader executed from SRAM. This is
done as part of iodelay configuration sequence and is required due
to the limitations introduced by erratum ID: i869[1] (IO Glitches
can occur when changing IO settings) and elaborated in the Technical
Reference Manual[2] 18.4.6.1.7 Isolation Requirements.
Only peripheral that is permitted for dynamic pin mux configuration
is MMC and DCAN. MMC is permitted to change to accommodate the
requirements for varied speeds (which require IO-delay support in
kernel as well). DCAN is a result of i893[1] (DCAN initialization
sequence).
DCAN pinmux is retained in this patch. MMC pinmux is missing from
the dra7-evm.dts file and the board is relying on configuration done
by bootloader. A subsequent patch will add MMC pinmux configuration.
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.
[1] http://www.ti.com/lit/pdf/sprz429
[2] http://www.ti.com/lit/pdf/sprui30
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
arch/arm/boot/dts/dra7-evm.dts | 267 +----------------------------------------
1 file changed, 6 insertions(+), 261 deletions(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 132f2be10889..80ebfd6a5c7b 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -151,204 +151,6 @@
};
&dra7_pmx_core {
- pinctrl-names = "default";
- pinctrl-0 = <&vtt_pin>;
-
- vtt_pin: pinmux_vtt_pin {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x37b4, PIN_OUTPUT | MUX_MODE14) /* spi1_cs1.gpio7_11 */
- >;
- };
-
- i2c1_pins: pinmux_i2c1_pins {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x3800, PIN_INPUT | MUX_MODE0) /* i2c1_sda */
- DRA7XX_CORE_IOPAD(0x3804, PIN_INPUT | MUX_MODE0) /* i2c1_scl */
- >;
- };
-
- i2c2_pins: pinmux_i2c2_pins {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x3808, PIN_INPUT | MUX_MODE0) /* i2c2_sda */
- DRA7XX_CORE_IOPAD(0x380c, PIN_INPUT | MUX_MODE0) /* i2c2_scl */
- >;
- };
-
- i2c3_pins: pinmux_i2c3_pins {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x3688, PIN_INPUT | MUX_MODE9) /* gpio6_14.i2c3_sda */
- DRA7XX_CORE_IOPAD(0x368c, PIN_INPUT | MUX_MODE9) /* gpio6_15.i2c3_scl */
- >;
- };
-
- mcspi1_pins: pinmux_mcspi1_pins {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x37a4, PIN_INPUT | MUX_MODE0) /* spi1_sclk */
- DRA7XX_CORE_IOPAD(0x37a8, PIN_INPUT | MUX_MODE0) /* spi1_d1 */
- DRA7XX_CORE_IOPAD(0x37ac, PIN_INPUT | MUX_MODE0) /* spi1_d0 */
- DRA7XX_CORE_IOPAD(0x37b0, PIN_INPUT_SLEW | MUX_MODE0) /* spi1_cs0 */
- DRA7XX_CORE_IOPAD(0x37b8, PIN_INPUT_SLEW | MUX_MODE6) /* spi1_cs2.hdmi1_hpd */
- DRA7XX_CORE_IOPAD(0x37bc, PIN_INPUT_SLEW | MUX_MODE6) /* spi1_cs3.hdmi1_cec */
- >;
- };
-
- mcspi2_pins: pinmux_mcspi2_pins {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x37c0, PIN_INPUT | MUX_MODE0) /* spi2_sclk */
- DRA7XX_CORE_IOPAD(0x37c4, PIN_INPUT_SLEW | MUX_MODE0) /* spi2_d1 */
- DRA7XX_CORE_IOPAD(0x37c8, PIN_INPUT_SLEW | MUX_MODE0) /* spi2_d1 */
- DRA7XX_CORE_IOPAD(0x37cc, PIN_INPUT_SLEW | MUX_MODE0) /* spi2_cs0 */
- >;
- };
-
- uart1_pins: pinmux_uart1_pins {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x37e0, PIN_INPUT_SLEW | MUX_MODE0) /* uart1_rxd */
- DRA7XX_CORE_IOPAD(0x37e4, PIN_INPUT_SLEW | MUX_MODE0) /* uart1_txd */
- DRA7XX_CORE_IOPAD(0x37e8, PIN_INPUT | MUX_MODE3) /* uart1_ctsn */
- DRA7XX_CORE_IOPAD(0x37ec, PIN_INPUT | MUX_MODE3) /* uart1_rtsn */
- >;
- };
-
- uart2_pins: pinmux_uart2_pins {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x37f0, PIN_INPUT | MUX_MODE0) /* uart2_rxd */
- DRA7XX_CORE_IOPAD(0x37f4, PIN_INPUT | MUX_MODE0) /* uart2_txd */
- DRA7XX_CORE_IOPAD(0x37f8, PIN_INPUT | MUX_MODE0) /* uart2_ctsn */
- DRA7XX_CORE_IOPAD(0x37fc, PIN_INPUT | MUX_MODE0) /* uart2_rtsn */
- >;
- };
-
- uart3_pins: pinmux_uart3_pins {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x3648, PIN_INPUT_SLEW | MUX_MODE0) /* uart3_rxd */
- DRA7XX_CORE_IOPAD(0x364c, PIN_INPUT_SLEW | MUX_MODE0) /* uart3_txd */
- >;
- };
-
- usb1_pins: pinmux_usb1_pins {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x3680, PIN_INPUT_SLEW | MUX_MODE0) /* usb1_drvvbus */
- >;
- };
-
- usb2_pins: pinmux_usb2_pins {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x3684, PIN_INPUT_SLEW | MUX_MODE0) /* usb2_drvvbus */
- >;
- };
-
- nand_flash_x16: nand_flash_x16 {
- /* On DRA7 EVM, GPMC_WPN and NAND_BOOTn comes from DIP switch
- * So NAND flash requires following switch settings:
- * SW5.1 (NAND_BOOTn) = ON (LOW)
- * SW5.9 (GPMC_WPN) = OFF (HIGH)
- */
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x3400, PIN_INPUT | MUX_MODE0) /* gpmc_ad0 */
- DRA7XX_CORE_IOPAD(0x3404, PIN_INPUT | MUX_MODE0) /* gpmc_ad1 */
- DRA7XX_CORE_IOPAD(0x3408, PIN_INPUT | MUX_MODE0) /* gpmc_ad2 */
- DRA7XX_CORE_IOPAD(0x340c, PIN_INPUT | MUX_MODE0) /* gpmc_ad3 */
- DRA7XX_CORE_IOPAD(0x3410, PIN_INPUT | MUX_MODE0) /* gpmc_ad4 */
- DRA7XX_CORE_IOPAD(0x3414, PIN_INPUT | MUX_MODE0) /* gpmc_ad5 */
- DRA7XX_CORE_IOPAD(0x3418, PIN_INPUT | MUX_MODE0) /* gpmc_ad6 */
- DRA7XX_CORE_IOPAD(0x341c, PIN_INPUT | MUX_MODE0) /* gpmc_ad7 */
- DRA7XX_CORE_IOPAD(0x3420, PIN_INPUT | MUX_MODE0) /* gpmc_ad8 */
- DRA7XX_CORE_IOPAD(0x3424, PIN_INPUT | MUX_MODE0) /* gpmc_ad9 */
- DRA7XX_CORE_IOPAD(0x3428, PIN_INPUT | MUX_MODE0) /* gpmc_ad10 */
- DRA7XX_CORE_IOPAD(0x342c, PIN_INPUT | MUX_MODE0) /* gpmc_ad11 */
- DRA7XX_CORE_IOPAD(0x3430, PIN_INPUT | MUX_MODE0) /* gpmc_ad12 */
- DRA7XX_CORE_IOPAD(0x3434, PIN_INPUT | MUX_MODE0) /* gpmc_ad13 */
- DRA7XX_CORE_IOPAD(0x3438, PIN_INPUT | MUX_MODE0) /* gpmc_ad14 */
- DRA7XX_CORE_IOPAD(0x343c, PIN_INPUT | MUX_MODE0) /* gpmc_ad15 */
- DRA7XX_CORE_IOPAD(0x34d8, PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_wait0 */
- DRA7XX_CORE_IOPAD(0x34cc, PIN_OUTPUT | MUX_MODE0) /* gpmc_wen */
- DRA7XX_CORE_IOPAD(0x34b4, PIN_OUTPUT_PULLUP | MUX_MODE0) /* gpmc_csn0 */
- DRA7XX_CORE_IOPAD(0x34c4, PIN_OUTPUT | MUX_MODE0) /* gpmc_advn_ale */
- DRA7XX_CORE_IOPAD(0x34c8, PIN_OUTPUT | MUX_MODE0) /* gpmc_oen_ren */
- DRA7XX_CORE_IOPAD(0x34d0, PIN_OUTPUT | MUX_MODE0) /* gpmc_be0n_cle */
- >;
- };
-
- cpsw_default: cpsw_default {
- pinctrl-single,pins = <
- /* Slave 1 */
- DRA7XX_CORE_IOPAD(0x3650, PIN_OUTPUT | MUX_MODE0) /* rgmii0_txc.rgmii0_txc */
- DRA7XX_CORE_IOPAD(0x3654, PIN_OUTPUT | MUX_MODE0) /* rgmii0_txctl.rgmii0_txctl */
- DRA7XX_CORE_IOPAD(0x3658, PIN_OUTPUT | MUX_MODE0) /* rgmii0_td3.rgmii0_txd3 */
- DRA7XX_CORE_IOPAD(0x365c, PIN_OUTPUT | MUX_MODE0) /* rgmii0_txd2.rgmii0_txd2 */
- DRA7XX_CORE_IOPAD(0x3660, PIN_OUTPUT | MUX_MODE0) /* rgmii0_txd1.rgmii0_txd1 */
- DRA7XX_CORE_IOPAD(0x3664, PIN_OUTPUT | MUX_MODE0) /* rgmii0_txd0.rgmii0_txd0 */
- DRA7XX_CORE_IOPAD(0x3668, PIN_INPUT | MUX_MODE0) /* rgmii0_rxc.rgmii0_rxc */
- DRA7XX_CORE_IOPAD(0x366c, PIN_INPUT | MUX_MODE0) /* rgmii0_rxctl.rgmii0_rxctl */
- DRA7XX_CORE_IOPAD(0x3670, PIN_INPUT | MUX_MODE0) /* rgmii0_rxd3.rgmii0_rxd3 */
- DRA7XX_CORE_IOPAD(0x3674, PIN_INPUT | MUX_MODE0) /* rgmii0_rxd2.rgmii0_rxd2 */
- DRA7XX_CORE_IOPAD(0x3678, PIN_INPUT | MUX_MODE0) /* rgmii0_rxd1.rgmii0_rxd1 */
- DRA7XX_CORE_IOPAD(0x367c, PIN_INPUT | MUX_MODE0) /* rgmii0_rxd0.rgmii0_rxd0 */
-
- /* Slave 2 */
- DRA7XX_CORE_IOPAD(0x3598, PIN_OUTPUT | MUX_MODE3) /* vin2a_d12.rgmii1_txc */
- DRA7XX_CORE_IOPAD(0x359c, PIN_OUTPUT | MUX_MODE3) /* vin2a_d13.rgmii1_tctl */
- DRA7XX_CORE_IOPAD(0x35a0, PIN_OUTPUT | MUX_MODE3) /* vin2a_d14.rgmii1_td3 */
- DRA7XX_CORE_IOPAD(0x35a4, PIN_OUTPUT | MUX_MODE3) /* vin2a_d15.rgmii1_td2 */
- DRA7XX_CORE_IOPAD(0x35a8, PIN_OUTPUT | MUX_MODE3) /* vin2a_d16.rgmii1_td1 */
- DRA7XX_CORE_IOPAD(0x35ac, PIN_OUTPUT | MUX_MODE3) /* vin2a_d17.rgmii1_td0 */
- DRA7XX_CORE_IOPAD(0x35b0, PIN_INPUT | MUX_MODE3) /* vin2a_d18.rgmii1_rclk */
- DRA7XX_CORE_IOPAD(0x35b4, PIN_INPUT | MUX_MODE3) /* vin2a_d19.rgmii1_rctl */
- DRA7XX_CORE_IOPAD(0x35b8, PIN_INPUT | MUX_MODE3) /* vin2a_d20.rgmii1_rd3 */
- DRA7XX_CORE_IOPAD(0x35bc, PIN_INPUT | MUX_MODE3) /* vin2a_d21.rgmii1_rd2 */
- DRA7XX_CORE_IOPAD(0x35c0, PIN_INPUT | MUX_MODE3) /* vin2a_d22.rgmii1_rd1 */
- DRA7XX_CORE_IOPAD(0x35c4, PIN_INPUT | MUX_MODE3) /* vin2a_d23.rgmii1_rd0 */
- >;
-
- };
-
- cpsw_sleep: cpsw_sleep {
- pinctrl-single,pins = <
- /* Slave 1 */
- DRA7XX_CORE_IOPAD(0x3650, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x3654, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x3658, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x365c, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x3660, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x3664, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x3668, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x366c, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x3670, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x3674, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x3678, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x367c, MUX_MODE15)
-
- /* Slave 2 */
- DRA7XX_CORE_IOPAD(0x3598, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x359c, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x35a0, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x35a4, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x35a8, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x35ac, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x35b0, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x35b4, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x35b8, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x35bc, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x35c0, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x35c4, MUX_MODE15)
- >;
- };
-
- davinci_mdio_default: davinci_mdio_default {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x363c, PIN_OUTPUT_PULLUP | MUX_MODE0) /* mdio_d.mdio_d */
- DRA7XX_CORE_IOPAD(0x3640, PIN_INPUT_PULLUP | MUX_MODE0) /* mdio_clk.mdio_clk */
- >;
- };
-
- davinci_mdio_sleep: davinci_mdio_sleep {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x363c, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x3640, MUX_MODE15)
- >;
- };
-
dcan1_pins_default: dcan1_pins_default {
pinctrl-single,pins = <
DRA7XX_CORE_IOPAD(0x37d0, PIN_OUTPUT_PULLUP | MUX_MODE0) /* dcan1_tx */
@@ -362,37 +164,10 @@
DRA7XX_CORE_IOPAD(0x3818, MUX_MODE15 | PULL_UP) /* wakeup0.off */
>;
};
-
- atl_pins: pinmux_atl_pins {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x3698, PIN_OUTPUT | MUX_MODE5) /* xref_clk1.atl_clk1 */
- DRA7XX_CORE_IOPAD(0x369c, PIN_OUTPUT | MUX_MODE5) /* xref_clk2.atl_clk2 */
- >;
- };
-
- mcasp3_pins: pinmux_mcasp3_pins {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x3724, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mcasp3_aclkx */
- DRA7XX_CORE_IOPAD(0x3728, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mcasp3_fsx */
- DRA7XX_CORE_IOPAD(0x372c, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mcasp3_axr0 */
- DRA7XX_CORE_IOPAD(0x3730, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mcasp3_axr1 */
- >;
- };
-
- mcasp3_sleep_pins: pinmux_mcasp3_sleep_pins {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x3724, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x3728, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x372c, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x3730, MUX_MODE15)
- >;
- };
};
&i2c1 {
status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&i2c1_pins>;
clock-frequency = <400000>;
tps659038: tps659038 at 58 {
@@ -581,8 +356,6 @@
&i2c2 {
status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&i2c2_pins>;
clock-frequency = <400000>;
pcf_hdmi: gpio at 26 {
@@ -602,41 +375,29 @@
&i2c3 {
status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&i2c3_pins>;
clock-frequency = <400000>;
};
&mcspi1 {
status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&mcspi1_pins>;
};
&mcspi2 {
status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&mcspi2_pins>;
};
&uart1 {
status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&uart1_pins>;
interrupts-extended = <&crossbar_mpu GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
<&dra7_pmx_core 0x3e0>;
};
&uart2 {
status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&uart2_pins>;
};
&uart3 {
status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&uart3_pins>;
};
&mmc1 {
@@ -732,14 +493,10 @@
&usb1 {
dr_mode = "peripheral";
- pinctrl-names = "default";
- pinctrl-0 = <&usb1_pins>;
};
&usb2 {
dr_mode = "host";
- pinctrl-names = "default";
- pinctrl-0 = <&usb2_pins>;
};
&elm {
@@ -747,9 +504,12 @@
};
&gpmc {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&nand_flash_x16>;
+ /*
+ * For the existing IOdelay configuration via U-Boot we don't
+ * support NAND on dra7-evm. Keep it disabled. Enabling it
+ * requires a different configuration by U-Boot.
+ */
+ status = "disabled";
ranges = <0 0 0x08000000 0x01000000>; /* minimum GPMC partition = 16MB */
nand at 0,0 {
compatible = "ti,omap2-nand";
@@ -845,9 +605,6 @@
&mac {
status = "okay";
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&cpsw_default>;
- pinctrl-1 = <&cpsw_sleep>;
dual_emac;
};
@@ -863,12 +620,6 @@
dual_emac_res_vlan = <2>;
};
-&davinci_mdio {
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&davinci_mdio_default>;
- pinctrl-1 = <&davinci_mdio_sleep>;
-};
-
&dcan1 {
status = "ok";
pinctrl-names = "default", "sleep", "active";
@@ -878,9 +629,6 @@
};
&atl {
- pinctrl-names = "default";
- pinctrl-0 = <&atl_pins>;
-
assigned-clocks = <&abe_dpll_sys_clk_mux>,
<&atl_gfclk_mux>,
<&dpll_abe_ck>,
@@ -899,9 +647,6 @@
&mcasp3 {
#sound-dai-cells = <0>;
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&mcasp3_pins>;
- pinctrl-1 = <&mcasp3_sleep_pins>;
assigned-clocks = <&mcasp3_ahclkx_mux>;
assigned-clock-parents = <&atl_clkin2_ck>;
--
2.9.0
^ 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
* [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 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 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] 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 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 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] 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 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 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 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 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 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 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 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 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 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 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
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