* [PATCH v2] arm64: dts: renesas: condor/v3hsk: specify Ethernet PHY IRQs
From: Sergei Shtylyov @ 2018-06-13 16:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4acc208e-c593-1e8a-00ca-fc9a5574074e@cogentembedded.com>
Specify Ethernet PHY IRQs in the Condor/V3HSK board device trees, now that
we have the GPIO support (previously phylib had to resort to polling).
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes in version 2:
- merged in the analogous V3HSK patch, renamed the patch, and updated the
patch description accordingly.
arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 2 ++
arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts | 2 ++
2 files changed, 4 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
@@ -59,6 +59,8 @@
phy0: ethernet-phy at 0 {
rxc-skew-ps = <1500>;
reg = <0>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
};
};
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
@@ -48,6 +48,8 @@
phy0: ethernet-phy at 0 {
reg = <0>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <23 IRQ_TYPE_LEVEL_LOW>;
};
};
^ permalink raw reply
* [PATCH v2] arm64: dts: renesas: condor/v3hsk: specify Ethernet PHY IRQs
From: Sergei Shtylyov @ 2018-06-13 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <42861d8f-3570-03b9-987c-bb15fa92a9c7@cogentembedded.com>
On 06/13/2018 07:42 PM, Sergei Shtylyov wrote:
> Specify Ethernet PHY IRQs in the Condor/V3HSK board device trees, now that
> we have the GPIO support (previously phylib had to resort to polling).
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
Forgot to add the the patch is against the 'renesas-devel-20180613-v4.17' tag.
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH V5] ARM: shmobile: Rework the PMIC IRQ line quirk
From: Geert Uytterhoeven @ 2018-06-13 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613143626.rrdxq4i4guy2oryg@verge.net.au>
Hi Simon,
On Wed, Jun 13, 2018 at 4:36 PM Simon Horman <horms@verge.net.au> wrote:
> On Wed, Jun 13, 2018 at 01:21:34PM +0200, Geert Uytterhoeven wrote:
> > On Wed, Jun 13, 2018 at 1:06 PM Simon Horman <horms@verge.net.au> wrote:
> > > On Mon, Jun 11, 2018 at 02:15:13PM +0200, Marek Vasut wrote:
> > > > Rather than hard-coding the quirk topology, which stopped scaling,
> > > > parse the information from DT. The code looks for all compatible
> > > > PMICs -- da9063 and da9210 -- and checks if their IRQ line is tied
> > > > to the same pin. If so, the code sends a matching sequence to the
> > > > PMIC to deassert the IRQ.
> > > >
> > > > Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> > > > Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> > > > Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > > > Cc: Simon Horman <horms+renesas@verge.net.au>
> > > > Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
> > > > Cc: linux-renesas-soc at vger.kernel.org
> > > > Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> > > > Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> (on Koelsch)
> > >
> > > This looks fine to me but I will wait to see if there are other reviews
> > > before applying.
> > >
> > > Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> >
> > Note that applying it now will break gose, as its DTS doesn't describe all
> > regulators yet.
>
> Ok, so old DT will break with new kernels?
For Lager, it will break with pre-v4.2 DTS, so I think that's not a problem.
For Koelsch, the regulators were added even earlier.
Stout had all regulators from the initial support in upstream.
So Gose is the only issue. Do we care?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: qcom: sdm845: Add I2C, SPI, and UART9 nodes
From: Douglas Anderson @ 2018-06-13 16:53 UTC (permalink / raw)
To: linux-arm-kernel
This adds nodes to SDM845-dtsi for all the I2C ports, all the SPI
ports, and UART9. Note that I2C / SPI / UART are a bit strange on
sdm845 because each "serial engine" has 4 pins associated with it and
depending on which firmware has been loaded into the serial engine
(loaded by the BIOS) the serial engine can behave like an I2C port, a
SPI port, or a UART. As per the landed bindings that means that we
need to create one node for each possible mode that the port could be
in. With 16 serial engines that means 16 x 3 = 48 nodes.
We get away with only creating 33 nodes for now because it seems very
likely that SDM845-based boards will actually all use the same UART
(UART 9) for debug purposes. While another UART could be used for
something like Bluetooth communication we can cross that path when we
come to it. Some documentation that I saw implied that using a UART
for "high speed" communications actually needs yet another different
serial engine firmware anyway.
Note that quick measurements adding all these nodes adds <10k of extra
space per dtb that they're included with. If this becomes a problem
we may need to think of a different way to structure this so that
boards only get the nodes they need (or figure out how to get dtc to
strip 'disabled' nodes). For now it seems OK.
These nodes were programmatically generated with a fairly dumb python
script. See http://crosreview.com/1091631 for the source.
NOTE: at the moment SPI chip select doesn't appear to work in my tests
with the latest posted SPI driver. All testing of SPI with this patch
has been done by hacking SPI to GPIO chip select.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Changes in v2:
- Got rid of all sleep pinctrl states for now
- Add Bjorn's tags.
arch/arm64/boot/dts/qcom/sdm845.dtsi | 733 +++++++++++++++++++++++++++
1 file changed, 733 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index cdaabeb3c995..2407d39f74df 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -5,6 +5,7 @@
* Copyright (c) 2018, The Linux Foundation. All rights reserved.
*/
+#include <dt-bindings/clock/qcom,gcc-sdm845.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
/ {
@@ -13,6 +14,41 @@
#address-cells = <2>;
#size-cells = <2>;
+ aliases {
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ i2c4 = &i2c4;
+ i2c5 = &i2c5;
+ i2c6 = &i2c6;
+ i2c7 = &i2c7;
+ i2c8 = &i2c8;
+ i2c9 = &i2c9;
+ i2c10 = &i2c10;
+ i2c11 = &i2c11;
+ i2c12 = &i2c12;
+ i2c13 = &i2c13;
+ i2c14 = &i2c14;
+ i2c15 = &i2c15;
+ spi0 = &spi0;
+ spi1 = &spi1;
+ spi2 = &spi2;
+ spi3 = &spi3;
+ spi4 = &spi4;
+ spi5 = &spi5;
+ spi6 = &spi6;
+ spi7 = &spi7;
+ spi8 = &spi8;
+ spi9 = &spi9;
+ spi10 = &spi10;
+ spi11 = &spi11;
+ spi12 = &spi12;
+ spi13 = &spi13;
+ spi14 = &spi14;
+ spi15 = &spi15;
+ };
+
chosen { };
memory at 80000000 {
@@ -206,6 +242,456 @@
#power-domain-cells = <1>;
};
+ qupv3_id_0: geniqup at 8c0000 {
+ compatible = "qcom,geni-se-qup";
+ reg = <0x8c0000 0x6000>;
+ clock-names = "m-ahb", "s-ahb";
+ clocks = <&gcc GCC_QUPV3_WRAP_0_M_AHB_CLK>,
+ <&gcc GCC_QUPV3_WRAP_0_S_AHB_CLK>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ i2c0: i2c at 880000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0x880000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S0_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_i2c0_default>;
+ interrupts = <GIC_SPI 601 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi0: spi at 880000 {
+ compatible = "qcom,geni-spi";
+ reg = <0x880000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S0_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_spi0_default>;
+ interrupts = <GIC_SPI 601 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c1: i2c at 884000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0x884000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S1_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_i2c1_default>;
+ interrupts = <GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi1: spi at 884000 {
+ compatible = "qcom,geni-spi";
+ reg = <0x884000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S1_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_spi1_default>;
+ interrupts = <GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c2: i2c at 888000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0x888000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S2_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_i2c2_default>;
+ interrupts = <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi2: spi at 888000 {
+ compatible = "qcom,geni-spi";
+ reg = <0x888000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S2_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_spi2_default>;
+ interrupts = <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c3: i2c at 88c000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0x88c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S3_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_i2c3_default>;
+ interrupts = <GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi3: spi at 88c000 {
+ compatible = "qcom,geni-spi";
+ reg = <0x88c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S3_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_spi3_default>;
+ interrupts = <GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c4: i2c at 890000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0x890000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S4_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_i2c4_default>;
+ interrupts = <GIC_SPI 605 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi4: spi at 890000 {
+ compatible = "qcom,geni-spi";
+ reg = <0x890000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S4_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_spi4_default>;
+ interrupts = <GIC_SPI 605 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c5: i2c at 894000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0x894000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S5_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_i2c5_default>;
+ interrupts = <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi5: spi at 894000 {
+ compatible = "qcom,geni-spi";
+ reg = <0x894000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S5_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_spi5_default>;
+ interrupts = <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c6: i2c at 898000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0x898000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S6_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_i2c6_default>;
+ interrupts = <GIC_SPI 607 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi6: spi at 898000 {
+ compatible = "qcom,geni-spi";
+ reg = <0x898000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S6_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_spi6_default>;
+ interrupts = <GIC_SPI 607 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c7: i2c at 89c000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0x89c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S7_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_i2c7_default>;
+ interrupts = <GIC_SPI 608 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi7: spi at 89c000 {
+ compatible = "qcom,geni-spi";
+ reg = <0x89c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S7_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_spi7_default>;
+ interrupts = <GIC_SPI 608 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+ };
+
+ qupv3_id_1: geniqup at ac0000 {
+ compatible = "qcom,geni-se-qup";
+ reg = <0xac0000 0x6000>;
+ clock-names = "m-ahb", "s-ahb";
+ clocks = <&gcc GCC_QUPV3_WRAP_1_M_AHB_CLK>,
+ <&gcc GCC_QUPV3_WRAP_1_S_AHB_CLK>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ status = "disabled";
+
+ i2c8: i2c at a80000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa80000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S0_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_i2c8_default>;
+ interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi8: spi at a80000 {
+ compatible = "qcom,geni-spi";
+ reg = <0xa80000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S0_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_spi8_default>;
+ interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c9: i2c at a84000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa84000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S1_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_i2c9_default>;
+ interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi9: spi at a84000 {
+ compatible = "qcom,geni-spi";
+ reg = <0xa84000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S1_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_spi9_default>;
+ interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ uart9: serial at a84000 {
+ compatible = "qcom,geni-debug-uart";
+ reg = <0xa84000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S1_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_uart9_default>;
+ interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ i2c10: i2c at a88000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa88000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S2_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_i2c10_default>;
+ interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi10: spi at a88000 {
+ compatible = "qcom,geni-spi";
+ reg = <0xa88000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S2_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_spi10_default>;
+ interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c11: i2c at a8c000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa8c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S3_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_i2c11_default>;
+ interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi11: spi at a8c000 {
+ compatible = "qcom,geni-spi";
+ reg = <0xa8c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S3_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_spi11_default>;
+ interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c12: i2c at a90000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa90000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S4_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_i2c12_default>;
+ interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi12: spi at a90000 {
+ compatible = "qcom,geni-spi";
+ reg = <0xa90000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S4_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_spi12_default>;
+ interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c13: i2c at a94000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa94000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S5_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_i2c13_default>;
+ interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi13: spi at a94000 {
+ compatible = "qcom,geni-spi";
+ reg = <0xa94000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S5_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_spi13_default>;
+ interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c14: i2c at a98000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa98000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S6_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_i2c14_default>;
+ interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi14: spi at a98000 {
+ compatible = "qcom,geni-spi";
+ reg = <0xa98000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S6_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_spi14_default>;
+ interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c15: i2c at a9c000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa9c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S7_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_i2c15_default>;
+ interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi15: spi at a9c000 {
+ compatible = "qcom,geni-spi";
+ reg = <0xa9c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S7_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_spi15_default>;
+ interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+ };
+
tcsr_mutex_regs: syscon at 1f40000 {
compatible = "syscon";
reg = <0x1f40000 0x40000>;
@@ -219,6 +705,253 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+
+ qup_i2c0_default: qup-i2c0-default {
+ pinmux {
+ pins = "gpio0", "gpio1";
+ function = "qup0";
+ };
+ };
+
+ qup_i2c1_default: qup-i2c1-default {
+ pinmux {
+ pins = "gpio17", "gpio18";
+ function = "qup1";
+ };
+ };
+
+ qup_i2c2_default: qup-i2c2-default {
+ pinmux {
+ pins = "gpio27", "gpio28";
+ function = "qup2";
+ };
+ };
+
+ qup_i2c3_default: qup-i2c3-default {
+ pinmux {
+ pins = "gpio41", "gpio42";
+ function = "qup3";
+ };
+ };
+
+ qup_i2c4_default: qup-i2c4-default {
+ pinmux {
+ pins = "gpio89", "gpio90";
+ function = "qup4";
+ };
+ };
+
+ qup_i2c5_default: qup-i2c5-default {
+ pinmux {
+ pins = "gpio85", "gpio86";
+ function = "qup5";
+ };
+ };
+
+ qup_i2c6_default: qup-i2c6-default {
+ pinmux {
+ pins = "gpio45", "gpio46";
+ function = "qup6";
+ };
+ };
+
+ qup_i2c7_default: qup-i2c7-default {
+ pinmux {
+ pins = "gpio93", "gpio94";
+ function = "qup7";
+ };
+ };
+
+ qup_i2c8_default: qup-i2c8-default {
+ pinmux {
+ pins = "gpio65", "gpio66";
+ function = "qup8";
+ };
+ };
+
+ qup_i2c9_default: qup-i2c9-default {
+ pinmux {
+ pins = "gpio6", "gpio7";
+ function = "qup9";
+ };
+ };
+
+ qup_i2c10_default: qup-i2c10-default {
+ pinmux {
+ pins = "gpio55", "gpio56";
+ function = "qup10";
+ };
+ };
+
+ qup_i2c11_default: qup-i2c11-default {
+ pinmux {
+ pins = "gpio31", "gpio32";
+ function = "qup11";
+ };
+ };
+
+ qup_i2c12_default: qup-i2c12-default {
+ pinmux {
+ pins = "gpio49", "gpio50";
+ function = "qup12";
+ };
+ };
+
+ qup_i2c13_default: qup-i2c13-default {
+ pinmux {
+ pins = "gpio105", "gpio106";
+ function = "qup13";
+ };
+ };
+
+ qup_i2c14_default: qup-i2c14-default {
+ pinmux {
+ pins = "gpio33", "gpio34";
+ function = "qup14";
+ };
+ };
+
+ qup_i2c15_default: qup-i2c15-default {
+ pinmux {
+ pins = "gpio81", "gpio82";
+ function = "qup15";
+ };
+ };
+
+ qup_spi0_default: qup-spi0-default {
+ pinmux {
+ pins = "gpio0", "gpio1",
+ "gpio2", "gpio3";
+ function = "qup0";
+ };
+ };
+
+ qup_spi1_default: qup-spi1-default {
+ pinmux {
+ pins = "gpio17", "gpio18",
+ "gpio19", "gpio20";
+ function = "qup1";
+ };
+ };
+
+ qup_spi2_default: qup-spi2-default {
+ pinmux {
+ pins = "gpio27", "gpio28",
+ "gpio29", "gpio30";
+ function = "qup2";
+ };
+ };
+
+ qup_spi3_default: qup-spi3-default {
+ pinmux {
+ pins = "gpio41", "gpio42",
+ "gpio43", "gpio44";
+ function = "qup3";
+ };
+ };
+
+ qup_spi4_default: qup-spi4-default {
+ pinmux {
+ pins = "gpio89", "gpio90",
+ "gpio91", "gpio92";
+ function = "qup4";
+ };
+ };
+
+ qup_spi5_default: qup-spi5-default {
+ pinmux {
+ pins = "gpio85", "gpio86",
+ "gpio87", "gpio88";
+ function = "qup5";
+ };
+ };
+
+ qup_spi6_default: qup-spi6-default {
+ pinmux {
+ pins = "gpio45", "gpio46",
+ "gpio47", "gpio48";
+ function = "qup6";
+ };
+ };
+
+ qup_spi7_default: qup-spi7-default {
+ pinmux {
+ pins = "gpio93", "gpio94",
+ "gpio95", "gpio96";
+ function = "qup7";
+ };
+ };
+
+ qup_spi8_default: qup-spi8-default {
+ pinmux {
+ pins = "gpio65", "gpio66",
+ "gpio67", "gpio68";
+ function = "qup8";
+ };
+ };
+
+ qup_spi9_default: qup-spi9-default {
+ pinmux {
+ pins = "gpio6", "gpio7",
+ "gpio4", "gpio5";
+ function = "qup9";
+ };
+ };
+
+ qup_spi10_default: qup-spi10-default {
+ pinmux {
+ pins = "gpio55", "gpio56",
+ "gpio53", "gpio54";
+ function = "qup10";
+ };
+ };
+
+ qup_spi11_default: qup-spi11-default {
+ pinmux {
+ pins = "gpio31", "gpio32",
+ "gpio33", "gpio34";
+ function = "qup11";
+ };
+ };
+
+ qup_spi12_default: qup-spi12-default {
+ pinmux {
+ pins = "gpio49", "gpio50",
+ "gpio51", "gpio52";
+ function = "qup12";
+ };
+ };
+
+ qup_spi13_default: qup-spi13-default {
+ pinmux {
+ pins = "gpio105", "gpio106",
+ "gpio107", "gpio108";
+ function = "qup13";
+ };
+ };
+
+ qup_spi14_default: qup-spi14-default {
+ pinmux {
+ pins = "gpio33", "gpio34",
+ "gpio31", "gpio32";
+ function = "qup14";
+ };
+ };
+
+ qup_spi15_default: qup-spi15-default {
+ pinmux {
+ pins = "gpio81", "gpio82",
+ "gpio83", "gpio84";
+ function = "qup15";
+ };
+ };
+
+ qup_uart9_default: qup-uart9-default {
+ pinmux {
+ pins = "gpio4", "gpio5";
+ function = "qup9";
+ };
+ };
};
spmi_bus: spmi at c440000 {
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: qcom: sdm845: Enable debug UART and I2C10 on sdm845-mtp
From: Douglas Anderson @ 2018-06-13 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613165352.139060-1-dianders@chromium.org>
The debug UART is very useful to have. I2C10 is enabled as an example
of a I2C port we can talk on for now. Eventually we'll want to put
peripherals under it.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Changes in v2:
- Got rid of all sleep pinctrl states for now
- Add Bjorn's tags.
arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 45 +++++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
index 979ab49913f1..6d651f314193 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
@@ -12,4 +12,49 @@
/ {
model = "Qualcomm Technologies, Inc. SDM845 MTP";
compatible = "qcom,sdm845-mtp";
+
+ aliases {
+ serial0 = &uart9;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&i2c10 {
+ status = "okay";
+ clock-frequency = <400000>;
+};
+
+&qupv3_id_1 {
+ status = "okay";
+};
+
+&uart9 {
+ status = "okay";
+};
+
+/* PINCTRL - additions to nodes defined in sdm845.dtsi */
+
+&qup_i2c10_default {
+ pinconf {
+ pins = "gpio55", "gpio56";
+ drive-strength = <2>;
+ bias-disable;
+ };
+};
+
+&qup_uart9_default {
+ pinconf-tx {
+ pins = "gpio4";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ pinconf-rx {
+ pins = "gpio5";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
};
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings
From: Suzuki K Poulose @ 2018-06-13 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <HE1PR0802MB24127EC935B9AF6F82AB3B6EEE7E0@HE1PR0802MB2412.eurprd08.prod.outlook.com>
Hi Matt,
On 13/06/18 16:47, Matt Sealey wrote:
> Hi Suzuki,
>
>>> Why not use ?unit??
>>>
>>> I believe we had this discussion years ago about numbering serial ports
>>> and sdhci (i.e. how do you know it?s UART0 or UART1 from just the address?
>>> Some SoC?s don?t address sequentially *or* in a forward direction) - I
>>> believe it?s not exactly codified in ePAPR, not am I sure where it may be
>>> otherwise, but it exists.
>>
>> We have different situation here. We need to know *the port number* as
>> understood by the hardware, so that we can enable *the specific* port for
>> a given path.
>
> For the purposes of abstraction, each port will have the property of having
> a node which is pointed to by other nodes, and in the case of a true ATB
> endpoint, no other nodes behind it.
>
> It doesn't matter what the HW numbers it as as long as the driver can derive
> it from whatever you put in the DT. So a funnel (which is ~8 ports muxed into
> one output):
>
> f1p0: port {
> unit = <0>;
> endpoint = <&f1out>;
> };
> f1p1: port {
> unit = <4>;
> endpoint = <&f1out>;
> };
> f1out: port {
> endpoint = <&etf1>;
> };
>
> "unit" here is specific to the driver's understanding of ports within it's
I may be missing, but is "unit" something that already exists and used by
DT bindings already ? Or is this something new that we are proposing ?
> own cycle of the graph. For a replicator you can invert the logic - input
> ports don't need a unit, but the two outputs are filtered in CoreSight not
I would prefer to make the new property mandatory for all the ports to avoid
a potential problem in the future.
How do you represent a TMC-ETF which has one input and one output connection ?
Also what happens if we ever get a component which has m-to-n connections ?
> by leg but by transiting ATB ID in groups of 16 IDs. In that case maybe
> you would want to describe all 8 possible units on each leg with the first
> ID it would filter? Or just list tuples of filter IDs <id, first, last>
I am failing to follow the ATB ID group description above. As per the TRM,
e.g, replicator filters the "trace stream" based on the "trace ID", which I
believe can be programmed via IDFILTER<n> register. So why would we need that
to be part of the DT ?
>
> Who cares, really, as long as the driver knows what it means.
>
> You don't need to namespace every property.
>
>> As I mentioned above, we need the hardware numbers to enable the
>> "specific" port.
>
> Okay and how is this not able to be prescribed in a binding for "arm,coresight-funnel"
> that:
>
> "input ports are numbered from 0 to N where N is the maximum input port
> number. This number is identified with the "unit" property, which directly
> corresponds to the bit position in the funnel Ctrl_Reg register, and the
> bit position multiplied by 3 for each 3-bit priority in the funnel
> Priority_Ctrl_Reg, with N having a maximum of the defined register bitfield
> DEVID[PORTCOUNT], minus one, for that component"
The description looks over complicated to me at least, even after having known
bit of the programming interface of the components. I would prefer staying
closer to the terms used in the TRM ("slave/master" interfaces) and make it
easier for people to write the DT.
>
> Or a replicator:
>
> "output ports are numbered per the CoreSight ATB Replicator specification,
> unit corresponding to the IDFILTERn register controlling ID filters for
> that leg, with a maximum of the defined register bitfield DEVID[PORTNUM],
> minus one"
>
> One could clarify it, even, with labels for readability ("label" definitely
> is a well defined if also completely arbitrary property).
>
> ..
>
>> static void funnel_enable_hw(struct funnel_drvdata *drvdata, int port)
>> {
>> u32 functl;
>>
>> CS_UNLOCK(drvdata->base);
>>
>> functl = readl_relaxed(drvdata->base + FUNNEL_FUNCTL);
>> functl &= ~FUNNEL_HOLDTIME_MASK;
>> functl |= FUNNEL_HOLDTIME;
>> functl |= (1 << port);
>> writel_relaxed(functl, drvdata->base + FUNNEL_FUNCTL);
>> writel_relaxed(drvdata->priority, drvdata->base + FUNNEL_PRICTL);
>>
>> CS_LOCK(drvdata->base);
>> }
>>
>> No we don't need to parse it in both ways, up and down. Btw, the trace
>> paths are not statically created. They are done at runtime, as configured
>> by the user.
>
> You do realize this isn't how the hardware works, correct?
The "trace paths" mentioned above were indeed the software path, which
was constructed at runtime. The graph connections are indeed a one time
parsing at probe time and as you said they don't change. And by configuring,
I mean selecting the "source" and the "sink".
>
> Trace paths are fixed, they may diverge with different configurations, but
> the full CoreSight topology (all funnels, replicators and intermediary
> Components) is entirely unchangeable.
>
> The DT should provide the information to provide a reference acyclic directed
> graph of the entire topology (or entirely reasonably programmable topology where
> at all possible) - if a user wants to trace from ETM_0 then they only
> have particular paths to particular sinks, for instance ETM_0 and ETF_0
> may be on their own path, so you cannot just "configure as a user"
> a path from ETM_1 to ETF_0 since there isn't one.
>
> Walking said graphs with the knowledge that CoreSight specifically disallows
> loopbacks in ATB topology is basic computer science problem - literally a
> matter of topological sorting. But let's build a graph once and traverse it -
> don't build the graph partially each time or try and build it to cross-check
> every time. The paths are wires in the design, lets not fake to the user
> that there is any configurability in that or try and encode that in the
> DT.
Sorry for the confusion, as explained above, it is indeed a one time pass.
>
>> Coming back to your suggestion of "unit", what does it imply ?
>
> Whatever the driver likes. For uart and mmc, it was just a spurious number
> but it could be applied as the end of, say, ttyS<N> or mmcblk<N>p3 or used
> in any other driver-specific manner. The number you put in is up to you,
> but the valid numbers would be in the binding for that particular device.
>
>> Its too generic a term for something as concrete as a port number.
>
> Is it?
>
> Why would you need a whole other property type to encode a u32 that
> describes an arbitrary number specific to that hardware device?
So, if the suggestion is to use an existing property "unit", I am fine
with it, if people agree to it.
Thanks for the comments.
Cheers,
Suzuki
^ permalink raw reply
* [PATCH] PCI: xilinx: add missing of_node_put()
From: Nicholas Mc Guire @ 2018-06-13 17:20 UTC (permalink / raw)
To: linux-arm-kernel
The call to of_get_next_child() returns a node pointer with refcount
incremented thus it must be explicitly decremented here after the last
usage.
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Fixes: commit 8961def56845 ("PCI: xilinx: Add Xilinx AXI PCIe Host Bridge IP driver")
---
Problem found by an experimental cocinelle script
Patch was compile tested with: multi_v7_defconfig + ARCH_ZYNQ=y,
COMPILE_TEST=y, PCIE_XILINX=y
(with one sparse warning though not related to the change proposed)
Patch is against 4.17.0 (localversion-next is next-20180613)
drivers/pci/controller/pcie-xilinx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/controller/pcie-xilinx.c b/drivers/pci/controller/pcie-xilinx.c
index b110a3a..7b1389d 100644
--- a/drivers/pci/controller/pcie-xilinx.c
+++ b/drivers/pci/controller/pcie-xilinx.c
@@ -509,6 +509,7 @@ static int xilinx_pcie_init_irq_domain(struct xilinx_pcie_port *port)
port->leg_domain = irq_domain_add_linear(pcie_intc_node, PCI_NUM_INTX,
&intx_domain_ops,
port);
+ of_node_put(pcie_intc_node);
if (!port->leg_domain) {
dev_err(dev, "Failed to get a INTx IRQ domain\n");
return -ENODEV;
--
2.1.4
^ permalink raw reply related
* [PATCH] arm64: dts: hikey: Define wl1835 power capabilities
From: Valentin Schneider @ 2018-06-13 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613151305.17240-1-ryan@edited.us>
Hi,
On 13/06/18 16:13, Ryan Grachek wrote:
> These properties are required for compatibility with runtime PM.
> Without these properties, MMC host controller will not be aware
> of power capabilities. When the wlcore driver attempts to power
> on the device, it will erroneously fail with -EACCES.
>
I don't have a hikey620 to test this, but the hikey960 is suffering from the
same issue (see [1]). I added these properties to the dwmmc2 node of the
hikey960 (see snippet) and wlan0 does show up. Would you mind sending a
similar patch for that board ?
Thanks !
Valentin
[1]: https://lkml.org/lkml/2018/6/12/930
--->8
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
index 85aadf1b..c706f70 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
@@ -613,6 +613,8 @@
vmmc-supply = <&wlan_en>;
ti,non-removable;
non-removable;
+ cap-power-off-card;
+ keep-power-in-suspend;
#address-cells = <0x1>;
#size-cells = <0x0>;
status = "ok";
^ permalink raw reply related
* [PATCH 3/4] ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of BTB) to facilitate CVE_2017-5715 WA in OS
From: Russell King - ARM Linux @ 2018-06-13 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <780935f6-6506-0915-dfb2-b584c074b70d@gmail.com>
On Wed, Jun 13, 2018 at 01:06:13AM +0200, Marek Vasut wrote:
> On 06/12/2018 10:24 PM, Nishanth Menon wrote:
> > Enable CVE_2017_5715 and since we have our own v7_arch_cp15_set_acr
> > function to setup the bits, we are able to override the settings.
> >
> > Without this enabled, Linux kernel reports:
> > CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
> >
> > With this enabled, Linux kernel reports:
> > CPU0: Spectre v2: using ICIALLU workaround
> >
> > NOTE: This by itself does not enable the workaround for CPU1 (on
> > OMAP5 and DRA72/AM572 SoCs) and may require additional kernel patches.
> >
> > Signed-off-by: Nishanth Menon <nm@ti.com>
> > ---
> > arch/arm/mach-omap2/Kconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> > index 3bb1ecb58de0..77820cc8d1e4 100644
> > --- a/arch/arm/mach-omap2/Kconfig
> > +++ b/arch/arm/mach-omap2/Kconfig
> > @@ -53,6 +53,7 @@ config OMAP54XX
> > bool "OMAP54XX SoC"
> > select ARM_ERRATA_798870
> > select SYS_THUMB_BUILD
> > + select ARM_CORTEX_A15_CVE_2017_5715
> > imply NAND_OMAP_ELM
> > imply NAND_OMAP_GPMC
> > imply SPL_DISPLAY_PRINT
> >
>
> Can this be enabled for all CA15 systems somehow ? I am sure there are
> more that are vulnerable.
I think you're missing the point.
Spectre affects the _entire_ system. Working around it in just the
kernel does not mean that the system is no longer vulnerable.
Fixing the "system" means implementing the fixes also in the secure
world, which on A15 and A8 also means setting the IBE bit there. If
the IBE bit is set in the secure world, it will also be set in the
non-secure world.
The fact that the kernel is complaining is telling you that the
system as a whole does not have the workarounds in place to mitigate
against the vulnerability. Merely setting the IBE bit via some
secure API doesn't "magically" fix the secure world.
So, even if you were to set the IBE bit via some magic secure API,
the fact still remains: even with these workarounds in place, as I
understand it, the _system as a whole_ remains vulnerable - you
might as well _not_ have the kernel workarounds.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH 1/2] arm64: avoid alloc memory on offline node
From: Punit Agrawal @ 2018-06-13 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87lgbk59gs.fsf@e105922-lin.cambridge.arm.com>
Punit Agrawal <punit.agrawal@arm.com> writes:
[...]
>
> CONFIG_HAVE_MEMORYLESS node is not enabled on arm64 which means we end
> up returning the original node in the fallback path.
>
> Xie, does the below patch help? I can submit a proper patch if this
> fixes the issue for you.
>
> -- >8 --
> Subject: [PATCH] arm64/numa: Enable memoryless numa nodes
>
> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
> ---
> arch/arm64/Kconfig | 4 ++++
> arch/arm64/mm/numa.c | 2 ++
> 2 files changed, 6 insertions(+)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index eb2cf4938f6d..5317e9aa93ab 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -756,6 +756,10 @@ config USE_PERCPU_NUMA_NODE_ID
> def_bool y
> depends on NUMA
>
> +config HAVE_MEMORYLESS_NODES
> + def_bool y
> + depends on NUMA
> +
> config HAVE_SETUP_PER_CPU_AREA
> def_bool y
> depends on NUMA
> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
> index dad128ba98bf..c699dcfe93de 100644
> --- a/arch/arm64/mm/numa.c
> +++ b/arch/arm64/mm/numa.c
> @@ -73,6 +73,8 @@ EXPORT_SYMBOL(cpumask_of_node);
> static void map_cpu_to_node(unsigned int cpu, int nid)
> {
> set_cpu_numa_node(cpu, nid);
> + set_numa_mem(local_memory_node(nid));
Argh, this should be
set_cpu_numa_mem(cpu, local_memory_node(nid));
There is not guarantee that map_cpu_to_node() will be called on the
local cpu.
Hanjun, Xie - can you try with the update please?
Thanks,
Punit
> +
> if (nid >= 0)
> cpumask_set_cpu(cpu, node_to_cpumask_map[nid]);
> }
^ permalink raw reply
* [PATCH] arm64: dts: hikey960: Define wl1837 power capabilities
From: Ryan Grachek @ 2018-06-13 18:03 UTC (permalink / raw)
To: linux-arm-kernel
These properties are required for compatibility with runtime PM.
Without these properties, MMC host controller will not be aware
of power capabilities. When the wlcore driver attempts to power
on the device, it will erroneously fail with -EACCES. This fixes
a regression found here: https://lkml.org/lkml/2018/6/12/930
Signed-off-by: Ryan Grachek <ryan@edited.us>
---
arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
index c6999624ed8a..68c5a6c819ae 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
@@ -585,6 +585,8 @@
vmmc-supply = <&wlan_en>;
ti,non-removable;
non-removable;
+ cap-power-off-card;
+ keep-power-in-suspend;
#address-cells = <0x1>;
#size-cells = <0x0>;
status = "ok";
--
2.11.0
^ permalink raw reply related
* [PATCH] arm64: dts: hikey: Define wl1835 power capabilities
From: Ryan Grachek @ 2018-06-13 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <521dd38a-29b8-5670-4296-84b300921b3d@arm.com>
Hi Valentin,
On Wed, Jun 13, 2018 at 12:34 PM, Valentin Schneider
<valentin.schneider@arm.com> wrote:
> Hi,
>
> On 13/06/18 16:13, Ryan Grachek wrote:
>> These properties are required for compatibility with runtime PM.
>> Without these properties, MMC host controller will not be aware
>> of power capabilities. When the wlcore driver attempts to power
>> on the device, it will erroneously fail with -EACCES.
>>
>
> I don't have a hikey620 to test this, but the hikey960 is suffering from the
> same issue (see [1]). I added these properties to the dwmmc2 node of the
> hikey960 (see snippet) and wlan0 does show up. Would you mind sending a
> similar patch for that board ?
>
> Thanks !
>
> Valentin
>
> [1]: https://lkml.org/lkml/2018/6/12/930
>
> --->8
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> index 85aadf1b..c706f70 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> @@ -613,6 +613,8 @@
> vmmc-supply = <&wlan_en>;
> ti,non-removable;
> non-removable;
> + cap-power-off-card;
> + keep-power-in-suspend;
> #address-cells = <0x1>;
> #size-cells = <0x0>;
> status = "ok";
Not a problem. The patch can be found here:
https://patchwork.kernel.org/patch/10462767/
Ryan
^ permalink raw reply
* [PATCH] arm64/acpi: Add fixup for HPE m400 quirks
From: Geoff Levand @ 2018-06-13 18:22 UTC (permalink / raw)
To: linux-arm-kernel
Adds a new ACPI init routine acpi_fixup_m400_quirks that adds
a work-around for HPE ProLiant m400 APEI firmware problems.
The work-around disables APEI when CONFIG_ACPI_APEI is set and
m400 firmware is detected. Without this fixup m400 systems
experience errors like these on startup:
[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 2
[Hardware Error]: event severity: fatal
[Hardware Error]: Error 0, type: fatal
[Hardware Error]: section_type: memory error
[Hardware Error]: error_status: 0x0000000000001300
[Hardware Error]: error_type: 10, invalid address
Kernel panic - not syncing: Fatal hardware error!
Signed-off-by: Geoff Levand <geoff@infradead.org>
---
Hi,
It seems unlikely there will be any m400 firmware updates to fix
this problem. APEI support is desired for new ARM64 servers coming
to market. Distros are now forced to have their own fixes, not
enable APEI, or let m400 users fend for themselves.
Please consider.
-Geoff
arch/arm64/kernel/acpi.c | 40 ++++++++++++++++++++++++++++++++++++----
1 file changed, 36 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 7b09487ff8fb..3c315c2c7476 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -31,6 +31,8 @@
#include <asm/cpu_ops.h>
#include <asm/smp_plat.h>
+#include <acpi/apei.h>
+
#ifdef CONFIG_ACPI_APEI
# include <linux/efi.h>
# include <asm/pgtable.h>
@@ -177,6 +179,33 @@ static int __init acpi_fadt_sanity_check(void)
return ret;
}
+/*
+ * acpi_fixup_m400_quirks - Work-around for HPE ProLiant m400 APEI firmware
+ * problems.
+ */
+static void __init acpi_fixup_m400_quirks(void)
+{
+ acpi_status status;
+ struct acpi_table_header *header;
+#if !defined(CONFIG_ACPI_APEI)
+ int hest_disable = HEST_DISABLED;
+#endif
+
+ if (!IS_ENABLED(CONFIG_ACPI_APEI) || hest_disable != HEST_ENABLED)
+ return;
+
+ status = acpi_get_table(ACPI_SIG_HEST, 0, &header);
+
+ if (ACPI_SUCCESS(status) && !strncmp(header->oem_id, "HPE ", 6) &&
+ !strncmp(header->oem_table_id, "ProLiant", 8) &&
+ MIDR_IMPLEMENTOR(read_cpuid_id()) == ARM_CPU_IMP_APM) {
+ hest_disable = HEST_DISABLED;
+ pr_info("Disabled APEI for m400.\n");
+ }
+
+ acpi_put_table(header);
+}
+
/*
* acpi_boot_table_init() called from setup_arch(), always.
* 1. find RSDP and get its address, and then find XSDT
@@ -232,11 +261,14 @@ void __init acpi_boot_table_init(void)
if (acpi_disabled) {
if (earlycon_acpi_spcr_enable)
early_init_dt_scan_chosen_stdout();
- } else {
- acpi_parse_spcr(earlycon_acpi_spcr_enable, true);
- if (IS_ENABLED(CONFIG_ACPI_BGRT))
- acpi_table_parse(ACPI_SIG_BGRT, acpi_parse_bgrt);
+ return;
}
+
+ acpi_parse_spcr(earlycon_acpi_spcr_enable, true);
+ if (IS_ENABLED(CONFIG_ACPI_BGRT))
+ acpi_table_parse(ACPI_SIG_BGRT, acpi_parse_bgrt);
+
+ acpi_fixup_m400_quirks();
}
#ifdef CONFIG_ACPI_APEI
--
2.14.1
^ permalink raw reply related
* [PATCH] arm64: dts: hikey: Define wl1835 power capabilities
From: John Stultz @ 2018-06-13 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613151305.17240-1-ryan@edited.us>
On Wed, Jun 13, 2018 at 8:13 AM, Ryan Grachek <ryan@edited.us> wrote:
> These properties are required for compatibility with runtime PM.
> Without these properties, MMC host controller will not be aware
> of power capabilities. When the wlcore driver attempts to power
> on the device, it will erroneously fail with -EACCES.
>
> Signed-off-by: Ryan Grachek <ryan@edited.us>
Fixes: 60f36637bbbd ("wlcore: sdio: allow pm to handle sdio power")
Tested-by: John Stultz <john.stultz@linaro.org>
Acked-by: John Stultz <john.stultz@linaro.org>
Wei Xu: This fixes a functional regression with wifi on the HiKey
board that was introduced in 4.18-rc with commit 60f36637bbbd
("wlcore: sdio: allow pm to handle sdio power").
Could you please be sure to queue this for the 4.18-rc ?
thanks
-john
^ permalink raw reply
* [PATCH] arm64: dts: hikey: Define wl1835 power capabilities
From: Kalle Valo @ 2018-06-13 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANcMJZASEDRxaXwdG96nNeEDPrDm_ap5MjhXonEcg=yHZ8F=qg@mail.gmail.com>
John Stultz <john.stultz@linaro.org> writes:
> On Wed, Jun 13, 2018 at 8:13 AM, Ryan Grachek <ryan@edited.us> wrote:
>> These properties are required for compatibility with runtime PM.
>> Without these properties, MMC host controller will not be aware
>> of power capabilities. When the wlcore driver attempts to power
>> on the device, it will erroneously fail with -EACCES.
>>
>> Signed-off-by: Ryan Grachek <ryan@edited.us>
>
> Fixes: 60f36637bbbd ("wlcore: sdio: allow pm to handle sdio power")
> Tested-by: John Stultz <john.stultz@linaro.org>
> Acked-by: John Stultz <john.stultz@linaro.org>
>
> Wei Xu: This fixes a functional regression with wifi on the HiKey
> board that was introduced in 4.18-rc with commit 60f36637bbbd
> ("wlcore: sdio: allow pm to handle sdio power").
>
> Could you please be sure to queue this for the 4.18-rc ?
Adding linux-wireless so that wireless folks are aware of this wlcore
regression fix as well.
--
Kalle Valo
^ permalink raw reply
* [PATCH 1/2] ASoC: pxa: add binding for pxa2xx-ac97 audio complex
From: Robert Jarzmik @ 2018-06-13 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612221359.GA26741@rob-hp-laptop>
Rob Herring <robh@kernel.org> writes:
> On Mon, Jun 11, 2018 at 10:22:10PM +0200, Robert Jarzmik wrote:
>> This adds a binding for the Marvell PXA audio complex, available in
>> pxa2xx and pxa3xx variants.
>> +Required properties:
>> + - compatible: "marvell,pxa2xx-ac97"
>
> Don't use wildcards in compatible strings. Though this is so old...
Yes, I could use pxa270-ac97.
>> + - reset-gpio: gpio used for AC97 reset, refer to gpio.txt
> reset-gpios
Right, I'm on it.
>> + status = "okay";
>
> Don't show status in examples.
Sure.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH v2 0/5] Add R8A77980/Condor/V3HSK LVDS/HDMI support
From: Sergei Shtylyov @ 2018-06-13 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611081531.xaax5ouvffnarhq5@verge.net.au>
On 06/11/2018 11:15 AM, Simon Horman wrote:
>>> Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's
>>> 'renesas-devel-20180604-v4.17' tag. We're adding the R8A77980 FCPVD/VSPD/
>>> DU/LVDS device nodes and then describing the LVDS decoder and HDMI encoder
>>> connected to the LVDS output. These patches depend on the Thine THC63LVD1024
>>> driver and the R8A77980 LVDS support patch in order to work, and R8A77980
>>> GPIO DT patches in order to apply/compile...
>>>
>>> [1/5] arm64: dts: renesas: r8a77980: add FCPVD support
>>> [2/5] arm64: dts: renesas: r8a77980: add VSPD support
>>> [3/5] arm64: dts: renesas: r8a77980: add DU support
>>> [4/5] arm64: dts: renesas: r8a77980: add LVDS support
>>
>> Based on the recent request of the ARM SoC maintainers to avoid a plethora of
>> small patches, I think you can squash 1/5 to 4/5 all together.
>
> Agreed.
>
> Seregi could you please post a v2 with patches 1 - 4 squashed and the
It's going to be v3 already. :-)
> register range for VSPD0 reduced to 0x5000? Thanks!
More like increased. :-)
Working on it...
>>> [5/5] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support
MBR, Sergei
^ permalink raw reply
* [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
From: Florian Fainelli @ 2018-06-13 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJEFLXFf-Vq9c9XC41vBpisQwxkd06_v8Fmt6X=gp=2_g@mail.gmail.com>
On 06/12/2018 03:54 PM, Rob Herring wrote:
> On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
> <scott.branden@broadcom.com> wrote:
>> Hi Rob,
>>
>> Could you please kindly comment on change below.
>>
>> It allows board variants to be added easily via a simple define for
>> different number of SATA ports.
>>
>>
>>
>> On 18-06-04 09:22 AM, Florian Fainelli wrote:
>>>
>>> On 05/18/2018 11:34 AM, Scott Branden wrote:
>>>>
>>>> Move remaining sata configuration to stingray-sata.dtsi and enable
>>>> ports based on NUM_SATA defined.
>>>> Now, all that needs to be done is define NUM_SATA per board.
>>>
>>> Rob could you review this and let us know if this approach is okay or
>>> not? Thank you!
>>>
>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>> ---
>
>>>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>> index 8c68e0c..7f6d176 100644
>>>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>> @@ -43,7 +43,11 @@
>>>> interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
>>>> #address-cells = <1>;
>>>> #size-cells = <0>;
>>>> +#if (NUM_SATA > 0)
>>>> + status = "okay";
>>>> +#else
>>>> status = "disabled";
>>>> +#endif
>
> This only works if ports are contiguously enabled (0-N). You might not
> care, but it is not a pattern that works in general. And I'm not a fan
> of C preprocessing in DT files in general beyond just defines for
> single numbers.
Should we interpret this as a formal NAK?
--
Florian
^ permalink raw reply
* [PATCH] arm64: dts: hikey960: Define wl1837 power capabilities
From: John Stultz @ 2018-06-13 19:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613180321.16745-1-ryan@edited.us>
On Wed, Jun 13, 2018 at 11:03 AM, Ryan Grachek <ryan@edited.us> wrote:
> These properties are required for compatibility with runtime PM.
> Without these properties, MMC host controller will not be aware
> of power capabilities. When the wlcore driver attempts to power
> on the device, it will erroneously fail with -EACCES. This fixes
> a regression found here: https://lkml.org/lkml/2018/6/12/930
>
> Signed-off-by: Ryan Grachek <ryan@edited.us>
Fixes: 60f36637bbbd ("wlcore: sdio: allow pm to handle sdio power")
Tested-by: John Stultz <john.stultz@linaro.org>
Acked-by: John Stultz <john.stultz@linaro.org>
Wei Xu: This also fixes a functional regression with wifi on the
HiKey960 board that was introduced in 4.18-rc with commit 60f36637bbbd
("wlcore: sdio: allow pm to handle sdio power").
Could you please be sure to queue this for the 4.18-rc too?
thanks
-john
^ permalink raw reply
* [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings
From: Mathieu Poirier @ 2018-06-13 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <075b99a1-2a29-f6dc-e9f2-99f895c27d35@arm.com>
On 13 June 2018 at 11:07, Suzuki K Poulose <Suzuki.Poulose@arm.com> wrote:
> Hi Matt,
>
> On 13/06/18 16:47, Matt Sealey wrote:
>>
>> Hi Suzuki,
>>
>>>> Why not use ?unit??
>>>>
>>>> I believe we had this discussion years ago about numbering serial ports
>>>> and sdhci (i.e. how do you know it?s UART0 or UART1 from just the
>>>> address?
>>>> Some SoC?s don?t address sequentially *or* in a forward direction) - I
>>>> believe it?s not exactly codified in ePAPR, not am I sure where it may
>>>> be
>>>> otherwise, but it exists.
>>>
>>>
>>> We have different situation here. We need to know *the port number* as
>>> understood by the hardware, so that we can enable *the specific* port for
>>> a given path.
>>
>>
>> For the purposes of abstraction, each port will have the property of
>> having
>> a node which is pointed to by other nodes, and in the case of a true ATB
>> endpoint, no other nodes behind it.
>>
>> It doesn't matter what the HW numbers it as as long as the driver can
>> derive
>> it from whatever you put in the DT. So a funnel (which is ~8 ports muxed
>> into
>> one output):
>>
>> f1p0: port {
>> unit = <0>;
>> endpoint = <&f1out>;
>> };
>> f1p1: port {
>> unit = <4>;
>> endpoint = <&f1out>;
>> };
>> f1out: port {
>> endpoint = <&etf1>;
>> };
>>
>> "unit" here is specific to the driver's understanding of ports within it's
>
>
> I may be missing, but is "unit" something that already exists and used by
> DT bindings already ? Or is this something new that we are proposing ?
>
>> own cycle of the graph. For a replicator you can invert the logic - input
>> ports don't need a unit, but the two outputs are filtered in CoreSight not
>
>
> I would prefer to make the new property mandatory for all the ports to avoid
> a potential problem in the future.
>
> How do you represent a TMC-ETF which has one input and one output connection
> ?
> Also what happens if we ever get a component which has m-to-n connections ?
>
>> by leg but by transiting ATB ID in groups of 16 IDs. In that case maybe
>> you would want to describe all 8 possible units on each leg with the first
>> ID it would filter? Or just list tuples of filter IDs <id, first, last>
>
>
> I am failing to follow the ATB ID group description above. As per the TRM,
> e.g, replicator filters the "trace stream" based on the "trace ID", which I
> believe can be programmed via IDFILTER<n> register. So why would we need
> that
> to be part of the DT ?
>
>>
>> Who cares, really, as long as the driver knows what it means.
>>
>> You don't need to namespace every property.
>>
>>> As I mentioned above, we need the hardware numbers to enable the
>>> "specific" port.
>>
>>
>> Okay and how is this not able to be prescribed in a binding for
>> "arm,coresight-funnel"
>> that:
>>
>> "input ports are numbered from 0 to N where N is the maximum input port
>> number. This number is identified with the "unit" property, which directly
>> corresponds to the bit position in the funnel Ctrl_Reg register, and the
>> bit position multiplied by 3 for each 3-bit priority in the funnel
>> Priority_Ctrl_Reg, with N having a maximum of the defined register
>> bitfield
>> DEVID[PORTCOUNT], minus one, for that component"
>
>
> The description looks over complicated to me at least, even after having
> known
> bit of the programming interface of the components. I would prefer staying
> closer to the terms used in the TRM ("slave/master" interfaces) and make it
> easier for people to write the DT.
>
>>
>> Or a replicator:
>>
>> "output ports are numbered per the CoreSight ATB Replicator specification,
>> unit corresponding to the IDFILTERn register controlling ID filters for
>> that leg, with a maximum of the defined register bitfield DEVID[PORTNUM],
>> minus one"
>>
>> One could clarify it, even, with labels for readability ("label"
>> definitely
>> is a well defined if also completely arbitrary property).
>>
>> ..
>>
>>> static void funnel_enable_hw(struct funnel_drvdata *drvdata, int port)
>>> {
>>> u32 functl;
>>>
>>> CS_UNLOCK(drvdata->base);
>>>
>>> functl = readl_relaxed(drvdata->base + FUNNEL_FUNCTL);
>>> functl &= ~FUNNEL_HOLDTIME_MASK;
>>> functl |= FUNNEL_HOLDTIME;
>>> functl |= (1 << port);
>>> writel_relaxed(functl, drvdata->base + FUNNEL_FUNCTL);
>>> writel_relaxed(drvdata->priority, drvdata->base +
>>> FUNNEL_PRICTL);
>>>
>>> CS_LOCK(drvdata->base);
>>> }
>>>
>>> No we don't need to parse it in both ways, up and down. Btw, the trace
>>> paths are not statically created. They are done at runtime, as configured
>>> by the user.
>>
>>
>> You do realize this isn't how the hardware works, correct?
>
>
> The "trace paths" mentioned above were indeed the software path, which
> was constructed at runtime. The graph connections are indeed a one time
> parsing at probe time and as you said they don't change. And by configuring,
> I mean selecting the "source" and the "sink".
>
>>
>> Trace paths are fixed, they may diverge with different configurations, but
>> the full CoreSight topology (all funnels, replicators and intermediary
>> Components) is entirely unchangeable.
>>
>> The DT should provide the information to provide a reference acyclic
>> directed
>> graph of the entire topology (or entirely reasonably programmable topology
>> where
>> at all possible) - if a user wants to trace from ETM_0 then they only
>> have particular paths to particular sinks, for instance ETM_0 and ETF_0
>> may be on their own path, so you cannot just "configure as a user"
>> a path from ETM_1 to ETF_0 since there isn't one.
>
>
>>
>> Walking said graphs with the knowledge that CoreSight specifically
>> disallows
>> loopbacks in ATB topology is basic computer science problem - literally a
>> matter of topological sorting. But let's build a graph once and traverse
>> it -
>> don't build the graph partially each time or try and build it to
>> cross-check
>> every time. The paths are wires in the design, lets not fake to the user
>> that there is any configurability in that or try and encode that in the
>> DT.
>
>
> Sorry for the confusion, as explained above, it is indeed a one time pass.
>
>>
>>> Coming back to your suggestion of "unit", what does it imply ?
>>
>>
>> Whatever the driver likes. For uart and mmc, it was just a spurious number
>> but it could be applied as the end of, say, ttyS<N> or mmcblk<N>p3 or used
>> in any other driver-specific manner. The number you put in is up to you,
>> but the valid numbers would be in the binding for that particular device.
>>
>>> Its too generic a term for something as concrete as a port number.
>>
>>
>> Is it?
>>
>> Why would you need a whole other property type to encode a u32 that
>> describes an arbitrary number specific to that hardware device?
>
>
> So, if the suggestion is to use an existing property "unit", I am fine
> with it, if people agree to it.
If we're going to have something sharply different than ACPI I prefer
Rob's idea.
Mathieu
>
>
> Thanks for the comments.
>
> Cheers,
> Suzuki
^ permalink raw reply
* [PATCH 1/5] ARM: dts: cygnus: Fix I2C controller interrupt type
From: Florian Fainelli @ 2018-06-13 19:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528834891-17807-2-git-send-email-ray.jui@broadcom.com>
On 06/12/2018 01:21 PM, Ray Jui wrote:
> Fix I2C controller interrupt to use IRQ_TYPE_LEVEL_HIGH for Broadcom
> Cygnus SoC
>
> Fixes: b51c05a331ff ("ARM: dts: add I2C device nodes for Broadcom Cygnus")
This appears to be the only one that is truly needed here, the two
others below probably just moved things around but the offending commit
was already introduced in the above commit.
> Fixes: 0f0b21a83ad2 ("ARM: dts: Move all Cygnus peripherals into axi bus")
> Fixes: 9c5101f7a253 ("ARM: dts: Reorder Cygnus peripherals")
>
There is no need for an extra line between the last Fixes: tag and your
Signed-off-by tag.
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> ---
> arch/arm/boot/dts/bcm-cygnus.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
> index 9fe4f5a..835a6f7 100644
> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
> @@ -216,7 +216,7 @@
> reg = <0x18008000 0x100>;
> #address-cells = <1>;
> #size-cells = <0>;
> - interrupts = <GIC_SPI 85 IRQ_TYPE_NONE>;
> + interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
> clock-frequency = <100000>;
> status = "disabled";
> };
> @@ -245,7 +245,7 @@
> reg = <0x1800b000 0x100>;
> #address-cells = <1>;
> #size-cells = <0>;
> - interrupts = <GIC_SPI 86 IRQ_TYPE_NONE>;
> + interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
> clock-frequency = <100000>;
> status = "disabled";
> };
>
--
Florian
^ permalink raw reply
* [PATCH 2/5] ARM: dts: cygnus: Fix PCIe controller interrupt type
From: Florian Fainelli @ 2018-06-13 19:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528834891-17807-3-git-send-email-ray.jui@broadcom.com>
On 06/12/2018 01:21 PM, Ray Jui wrote:
> Fix PCIe controller interrupt to use IRQ_TYPE_LEVEL_HIGH for Broadcom
> Cygnus SoC
>
> Fixes: cd590b50a936 ("ARM: dts: enable PCIe support for Cygnus")
This one is valid
> Fixes: 0f0b21a83ad2 ("ARM: dts: Move all Cygnus peripherals into axi
> bus")
> Fixes: 9c5101f7a253 ("ARM: dts: Reorder Cygnus peripherals")
> Fixes: f6b889358a82 ("ARM: dts: Enable MSI support for Broadcom Cygnus")
And this one too, but the two others, I would probably drop them so we
can get the backports to be possibly applicable as far as when these two
commits can be resolved, does that work?
>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> ---
> arch/arm/boot/dts/bcm-cygnus.dtsi | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
> index 835a6f7..2c4df2d 100644
> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
> @@ -256,7 +256,7 @@
>
> #interrupt-cells = <1>;
> interrupt-map-mask = <0 0 0 0>;
> - interrupt-map = <0 0 0 0 &gic GIC_SPI 100 IRQ_TYPE_NONE>;
> + interrupt-map = <0 0 0 0 &gic GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
>
> linux,pci-domain = <0>;
>
> @@ -278,10 +278,10 @@
> compatible = "brcm,iproc-msi";
> msi-controller;
> interrupt-parent = <&gic>;
> - interrupts = <GIC_SPI 96 IRQ_TYPE_NONE>,
> - <GIC_SPI 97 IRQ_TYPE_NONE>,
> - <GIC_SPI 98 IRQ_TYPE_NONE>,
> - <GIC_SPI 99 IRQ_TYPE_NONE>;
> + interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
> };
> };
>
> @@ -291,7 +291,7 @@
>
> #interrupt-cells = <1>;
> interrupt-map-mask = <0 0 0 0>;
> - interrupt-map = <0 0 0 0 &gic GIC_SPI 106 IRQ_TYPE_NONE>;
> + interrupt-map = <0 0 0 0 &gic GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
>
> linux,pci-domain = <1>;
>
> @@ -313,10 +313,10 @@
> compatible = "brcm,iproc-msi";
> msi-controller;
> interrupt-parent = <&gic>;
> - interrupts = <GIC_SPI 102 IRQ_TYPE_NONE>,
> - <GIC_SPI 103 IRQ_TYPE_NONE>,
> - <GIC_SPI 104 IRQ_TYPE_NONE>,
> - <GIC_SPI 105 IRQ_TYPE_NONE>;
> + interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
> };
> };
>
>
--
Florian
^ permalink raw reply
* [PATCH v3 0/2] Add R8A77980/Condor/V3HSK LVDS/HDMI support
From: Sergei Shtylyov @ 2018-06-13 20:09 UTC (permalink / raw)
To: linux-arm-kernel
Hello!
Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20180613-v4.17' tag and the Condor/V3HSK TD patches adding
Ethernet PHY IRQs. We're adding the R8A77980 FCPVD/VSPD/DU/LVDS device nodes
and then describing the LVDS decoder and HDMI encoder connected to the LVDS
output on the Condor and V3HSK boards. These patches depend on the Thine
THC63LVD1024 driver and the R8A77980 LVDS support patch in order to work...
[1/2] arm64: dts: renesas: r8a77980: add FCPVD/VSPD/DU/LVDS support
[2/2] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support
WBR, Sergei
^ permalink raw reply
* [PATCH v3 1/2] arm64: dts: renesas: r8a77980: add FCPVD/VSPD/DU/LVDS support
From: Sergei Shtylyov @ 2018-06-13 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <95d0db34-713d-8206-00c2-ee9a42aab823@cogentembedded.com>
Describe the interconnected FCPVD0, VSPD0, DU, and LVDS0 devices in the
R8A77980 device tree...
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
Changes in version 3:
- merged in the VSPD/DU/LVDS patches, renamed the patch, and updated the patch
description accordingly;
- fixed the VSPD0's "reg" property.
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 77 ++++++++++++++++++++++++++++++
1 file changed, 77 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -653,6 +653,83 @@
resets = <&cpg 408>;
};
+ vspd0: vsp at fea20000 {
+ compatible = "renesas,vsp2";
+ reg = <0 0xfea20000 0 0x5000>;
+ interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 623>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 623>;
+ renesas,fcp = <&fcpvd0>;
+ };
+
+ fcpvd0: fcp at fea27000 {
+ compatible = "renesas,fcpv";
+ reg = <0 0xfea27000 0 0x200>;
+ clocks = <&cpg CPG_MOD 603>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 603>;
+ };
+
+ du: display at feb00000 {
+ compatible = "renesas,du-r8a77980",
+ "renesas,du-r8a77970";
+ reg = <0 0xfeb00000 0 0x80000>;
+ interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 724>;
+ clock-names = "du.0";
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 724>;
+ vsps = <&vspd0>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ du_out_rgb: endpoint {
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ du_out_lvds0: endpoint {
+ remote-endpoint = <&lvds0_in>;
+ };
+ };
+ };
+ };
+
+ lvds0: lvds-encoder at feb90000 {
+ compatible = "renesas,r8a77980-lvds";
+ reg = <0 0xfeb90000 0 0x14>;
+ clocks = <&cpg CPG_MOD 727>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 727>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ lvds0_in: endpoint {
+ remote-endpoint =
+ <&du_out_lvds0>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ lvds0_out: endpoint {
+ };
+ };
+ };
+ };
+
prr: chipid at fff00044 {
compatible = "renesas,prr";
reg = <0 0xfff00044 0 4>;
^ permalink raw reply
* [PATCH v3 2/2] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support
From: Sergei Shtylyov @ 2018-06-13 20:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <95d0db34-713d-8206-00c2-ee9a42aab823@cogentembedded.com>
Define the Condor/V3HSK board dependent parts of the DU and LVDS device
nodes. Also add the device nodes for Thine THC63LVD1024 LVDS decoder and
Analog Devices ADV7511W HDMI transmitter...
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes in version 2:
- added the V3HSK DT update, reworded the description, renamed the patch;
- added a space between the HDMI node name and a brace.
arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 106 +++++++++++++++++++++
arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts | 120 ++++++++++++++++++++++++
2 files changed, 226 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
@@ -45,6 +45,56 @@
regulator-boot-on;
regulator-always-on;
};
+
+ d1_8v: regulator-2 {
+ compatible = "regulator-fixed";
+ regulator-name = "D1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ hdmi-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con: endpoint {
+ remote-endpoint = <&adv7511_out>;
+ };
+ };
+ };
+
+ lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+ vcc-supply = <&d3_3v>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ thc63lvd1024_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+
+ port at 2 {
+ reg = <2>;
+ thc63lvd1024_out: endpoint {
+ remote-endpoint = <&adv7511_in>;
+ };
+ };
+ };
+ };
+
+ x1_clk: x1-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <148500000>;
+ };
};
&avb {
@@ -74,6 +124,13 @@
};
};
+&du {
+ clocks = <&cpg CPG_MOD 724>,
+ <&x1_clk>;
+ clock-names = "du.0", "dclkin.0";
+ status = "okay";
+};
+
&extal_clk {
clock-frequency = <16666666>;
};
@@ -102,6 +159,55 @@
gpio-controller;
#gpio-cells = <2>;
};
+
+ hdmi at 39 {
+ compatible = "adi,adv7511w";
+ reg = <0x39>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+ avdd-supply = <&d1_8v>;
+ dvdd-supply = <&d1_8v>;
+ pvdd-supply = <&d1_8v>;
+ bgvdd-supply = <&d1_8v>;
+ dvdd-3v-supply = <&d3_3v>;
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+ adi,input-style = <1>;
+ adi,input-justification = "evenly";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ adv7511_in: endpoint {
+ remote-endpoint = <&thc63lvd1024_out>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ adv7511_out: endpoint {
+ remote-endpoint = <&hdmi_con>;
+ };
+ };
+ };
+ };
+};
+
+&lvds0 {
+ status = "okay";
+
+ ports {
+ port at 1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <&thc63lvd1024_in>;
+ };
+ };
+ };
};
&mmc0 {
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
@@ -27,6 +27,63 @@
/* first 128MB is reserved for secure area. */
reg = <0 0x48000000 0 0x78000000>;
};
+
+ hdmi-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con: endpoint {
+ remote-endpoint = <&adv7511_out>;
+ };
+ };
+ };
+
+ lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+ vcc-supply = <&vcc3v3_d5>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ thc63lvd1024_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+
+ port at 2 {
+ reg = <2>;
+ thc63lvd1024_out: endpoint {
+ remote-endpoint = <&adv7511_in>;
+ };
+ };
+ };
+ };
+
+ vcc1v8_d4: regulator-0 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC1V8_D4";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vcc3v3_d5: regulator-1 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC3V3_D5";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+};
+
+&du {
+ status = "okay";
};
&extal_clk {
@@ -53,6 +110,64 @@
};
};
+&lvds0 {
+ status = "okay";
+
+ ports {
+ port at 1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <&thc63lvd1024_in>;
+ };
+ };
+ };
+};
+
+&i2c0 {
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+ clock-frequency = <400000>;
+
+ hdmi at 39 {
+ compatible = "adi,adv7511w";
+ #sound-dai-cells = <0>;
+ reg = <0x39>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+ avdd-supply = <&vcc1v8_d4>;
+ dvdd-supply = <&vcc1v8_d4>;
+ pvdd-supply = <&vcc1v8_d4>;
+ bgvdd-supply = <&vcc1v8_d4>;
+ dvdd-3v-supply = <&vcc3v3_d5>;
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+ adi,input-style = <1>;
+ adi,input-justification = "evenly";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ adv7511_in: endpoint {
+ remote-endpoint = <&thc63lvd1024_out>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ adv7511_out: endpoint {
+ remote-endpoint = <&hdmi_con>;
+ };
+ };
+ };
+ };
+};
+
&pfc {
gether_pins: gether {
groups = "gether_mdio_a", "gether_rgmii",
@@ -60,6 +175,11 @@
function = "gether";
};
+ i2c0_pins: i2c0 {
+ groups = "i2c0";
+ function = "i2c0";
+ };
+
scif0_pins: scif0 {
groups = "scif0_data";
function = "scif0";
^ 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