* [PATCH 19/31] ARM: dts: r8a7745: add SYS-DMAC support
From: Simon Horman @ 2016-11-17 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479391750.git.horms+renesas@verge.net.au>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Describe SYS-DMAC0/1 in the R8A7745 device tree.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7745.dtsi | 64 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 64 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index fbf72ddd82b7..437c5ad933d1 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -93,6 +93,70 @@
compatible = "renesas,r8a7745-rst";
reg = <0 0xe6160000 0 0x100>;
};
+
+ dmac0: dma-controller at e6700000 {
+ compatible = "renesas,dmac-r8a7745",
+ "renesas,rcar-dmac";
+ reg = <0 0xe6700000 0 0x20000>;
+ interrupts = <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12", "ch13", "ch14";
+ clocks = <&cpg CPG_MOD 219>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ #dma-cells = <1>;
+ dma-channels = <15>;
+ };
+
+ dmac1: dma-controller at e6720000 {
+ compatible = "renesas,dmac-r8a7745",
+ "renesas,rcar-dmac";
+ reg = <0 0xe6720000 0 0x20000>;
+ interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12", "ch13", "ch14";
+ clocks = <&cpg CPG_MOD 218>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ #dma-cells = <1>;
+ dma-channels = <15>;
+ };
};
/* External root clock */
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 20/31] ARM: dts: r8a7745: add [H]SCIF{|A|B} support
From: Simon Horman @ 2016-11-17 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479391750.git.horms+renesas@verge.net.au>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Describe [H]SCIF{|A|B} ports in the R8A7745 device tree.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
[simon: consistently use tabs for indentation]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7745.dtsi | 261 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 261 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 437c5ad933d1..99ccdd0d3014 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -157,6 +157,267 @@
#dma-cells = <1>;
dma-channels = <15>;
};
+
+ scifa0: serial at e6c40000 {
+ compatible = "renesas,scifa-r8a7745",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c40000 0 0x40>;
+ interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 204>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x21>, <&dmac0 0x22>,
+ <&dmac1 0x21>, <&dmac1 0x22>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa1: serial at e6c50000 {
+ compatible = "renesas,scifa-r8a7745",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c50000 0 0x40>;
+ interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 203>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x25>, <&dmac0 0x26>,
+ <&dmac1 0x25>, <&dmac1 0x26>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa2: serial at e6c60000 {
+ compatible = "renesas,scifa-r8a7745",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c60000 0 0x40>;
+ interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 202>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x27>, <&dmac0 0x28>,
+ <&dmac1 0x27>, <&dmac1 0x28>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa3: serial at e6c70000 {
+ compatible = "renesas,scifa-r8a7745",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c70000 0 0x40>;
+ interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 1106>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x1b>, <&dmac0 0x1c>,
+ <&dmac1 0x1b>, <&dmac1 0x1c>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa4: serial at e6c78000 {
+ compatible = "renesas,scifa-r8a7745",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c78000 0 0x40>;
+ interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 1107>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x1f>, <&dmac0 0x20>,
+ <&dmac1 0x1f>, <&dmac1 0x20>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa5: serial at e6c80000 {
+ compatible = "renesas,scifa-r8a7745",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c80000 0 0x40>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 1108>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x23>, <&dmac0 0x24>,
+ <&dmac1 0x23>, <&dmac1 0x24>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifb0: serial at e6c20000 {
+ compatible = "renesas,scifb-r8a7745",
+ "renesas,rcar-gen2-scifb", "renesas,scifb";
+ reg = <0 0xe6c20000 0 0x100>;
+ interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 206>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x3d>, <&dmac0 0x3e>,
+ <&dmac1 0x3d>, <&dmac1 0x3e>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifb1: serial at e6c30000 {
+ compatible = "renesas,scifb-r8a7745",
+ "renesas,rcar-gen2-scifb", "renesas,scifb";
+ reg = <0 0xe6c30000 0 0x100>;
+ interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 207>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x19>, <&dmac0 0x1a>,
+ <&dmac1 0x19>, <&dmac1 0x1a>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifb2: serial at e6ce0000 {
+ compatible = "renesas,scifb-r8a7745",
+ "renesas,rcar-gen2-scifb", "renesas,scifb";
+ reg = <0 0xe6ce0000 0 0x100>;
+ interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 216>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x1d>, <&dmac0 0x1e>,
+ <&dmac1 0x1d>, <&dmac1 0x1e>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif0: serial at e6e60000 {
+ compatible = "renesas,scif-r8a7745",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6e60000 0 0x40>;
+ interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 721>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x29>, <&dmac0 0x2a>,
+ <&dmac1 0x29>, <&dmac1 0x2a>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif1: serial at e6e68000 {
+ compatible = "renesas,scif-r8a7745",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6e68000 0 0x40>;
+ interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 720>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x2d>, <&dmac0 0x2e>,
+ <&dmac1 0x2d>, <&dmac1 0x2e>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif2: serial at e6e58000 {
+ compatible = "renesas,scif-r8a7745",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6e58000 0 0x40>;
+ interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 719>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x2b>, <&dmac0 0x2c>,
+ <&dmac1 0x2b>, <&dmac1 0x2c>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif3: serial at e6ea8000 {
+ compatible = "renesas,scif-r8a7745",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6ea8000 0 0x40>;
+ interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 718>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x2f>, <&dmac0 0x30>,
+ <&dmac1 0x2f>, <&dmac1 0x30>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif4: serial at e6ee0000 {
+ compatible = "renesas,scif-r8a7745",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6ee0000 0 0x40>;
+ interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 715>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0xfb>, <&dmac0 0xfc>,
+ <&dmac1 0xfb>, <&dmac1 0xfc>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif5: serial at e6ee8000 {
+ compatible = "renesas,scif-r8a7745",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6ee8000 0 0x40>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 714>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0xfd>, <&dmac0 0xfe>,
+ <&dmac1 0xfd>, <&dmac1 0xfe>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ hscif0: serial at e62c0000 {
+ compatible = "renesas,hscif-r8a7745",
+ "renesas,rcar-gen2-hscif", "renesas,hscif";
+ reg = <0 0xe62c0000 0 0x60>;
+ interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 717>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x39>, <&dmac0 0x3a>,
+ <&dmac1 0x39>, <&dmac1 0x3a>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ hscif1: serial at e62c8000 {
+ compatible = "renesas,hscif-r8a7745",
+ "renesas,rcar-gen2-hscif", "renesas,hscif";
+ reg = <0 0xe62c8000 0 0x60>;
+ interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 716>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x4d>, <&dmac0 0x4e>,
+ <&dmac1 0x4d>, <&dmac1 0x4e>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ hscif2: serial at e62d0000 {
+ compatible = "renesas,hscif-r8a7745",
+ "renesas,rcar-gen2-hscif", "renesas,hscif";
+ reg = <0 0xe62d0000 0 0x60>;
+ interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 713>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x3b>, <&dmac0 0x3c>,
+ <&dmac1 0x3b>, <&dmac1 0x3c>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
};
/* External root clock */
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 21/31] ARM: dts: r8a7745: add Ether support
From: Simon Horman @ 2016-11-17 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479391750.git.horms+renesas@verge.net.au>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Define the generic R8A7745 part of the Ether device node.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7745.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 99ccdd0d3014..6fe48157f906 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -418,6 +418,18 @@
power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
status = "disabled";
};
+
+ ether: ethernet at ee700000 {
+ compatible = "renesas,ether-r8a7745";
+ reg = <0 0xee700000 0 0x400>;
+ interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 813>;
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ phy-mode = "rmii";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
};
/* External root clock */
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 22/31] ARM: dts: r8a7745: add IRQC support
From: Simon Horman @ 2016-11-17 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479391750.git.horms+renesas@verge.net.au>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Describe the IRQC interrupt controller in the R8A7745 device tree.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7745.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 6fe48157f906..0b2e2f37150f 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -62,6 +62,25 @@
IRQ_TYPE_LEVEL_HIGH)>;
};
+ irqc: interrupt-controller at e61c0000 {
+ compatible = "renesas,irqc-r8a7745", "renesas,irqc";
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ reg = <0 0xe61c0000 0 0x200>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 407>;
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ };
+
timer {
compatible = "arm,armv7-timer";
interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) |
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 23/31] ARM: dts: sk-rzg1e: initial device tree
From: Simon Horman @ 2016-11-17 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479391750.git.horms+renesas@verge.net.au>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Add the initial device tree for the R8A7745 SoC based SK-RZG1E board.
The board has 1 debug serial port (SCIF2); include support for it,
so that the serial console can work.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/r8a7745-sk-rzg1e.dts | 39 ++++++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+)
create mode 100644 arch/arm/boot/dts/r8a7745-sk-rzg1e.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f83ea57c97f9..6f8cd1436ee8 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -678,6 +678,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
r8a73a4-ape6evm.dtb \
r8a7740-armadillo800eva.dtb \
r8a7743-sk-rzg1m.dtb \
+ r8a7745-sk-rzg1e.dtb \
r8a7778-bockw.dtb \
r8a7779-marzen.dtb \
r8a7790-lager.dtb \
diff --git a/arch/arm/boot/dts/r8a7745-sk-rzg1e.dts b/arch/arm/boot/dts/r8a7745-sk-rzg1e.dts
new file mode 100644
index 000000000000..667ec4b259d5
--- /dev/null
+++ b/arch/arm/boot/dts/r8a7745-sk-rzg1e.dts
@@ -0,0 +1,39 @@
+/*
+ * Device Tree Source for the SK-RZG1E board
+ *
+ * Copyright (C) 2016 Cogent Embedded, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "r8a7745.dtsi"
+
+/ {
+ model = "SK-RZG1E";
+ compatible = "renesas,sk-rzg1e", "renesas,r8a7745";
+
+ aliases {
+ serial0 = &scif2;
+ };
+
+ chosen {
+ bootargs = "ignore_loglevel";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory at 40000000 {
+ device_type = "memory";
+ reg = <0 0x40000000 0 0x40000000>;
+ };
+};
+
+&extal_clk {
+ clock-frequency = <20000000>;
+};
+
+&scif2 {
+ status = "okay";
+};
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 24/31] ARM: dts: sk-rzg1e: add Ether support
From: Simon Horman @ 2016-11-17 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479391750.git.horms+renesas@verge.net.au>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Define the SK-RZG1E board dependent part of the Ether device node.
Enable DHCP and NFS root for the kernel booting.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7745-sk-rzg1e.dts | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7745-sk-rzg1e.dts b/arch/arm/boot/dts/r8a7745-sk-rzg1e.dts
index 667ec4b259d5..97840b340197 100644
--- a/arch/arm/boot/dts/r8a7745-sk-rzg1e.dts
+++ b/arch/arm/boot/dts/r8a7745-sk-rzg1e.dts
@@ -20,7 +20,7 @@
};
chosen {
- bootargs = "ignore_loglevel";
+ bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
stdout-path = "serial0:115200n8";
};
@@ -37,3 +37,16 @@
&scif2 {
status = "okay";
};
+
+ðer {
+ phy-handle = <&phy1>;
+ renesas,ether-link-active-low;
+ status = "okay";
+
+ phy1: ethernet-phy at 1 {
+ reg = <1>;
+ interrupt-parent = <&irqc>;
+ interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+ micrel,led-mode = <1>;
+ };
+};
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 25/31] ARM: dts: r8a73a4: Add device node for PRR
From: Simon Horman @ 2016-11-17 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479391750.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Add a device node for the Product Register, which provides SoC product
and revision information.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a73a4.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index ca8672778fe0..53183ffe04c1 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -751,6 +751,11 @@
};
};
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0 0xff000044 0 4>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,sysc-r8a73a4", "renesas,sysc-rmobile";
reg = <0 0xe6180000 0 0x8000>, <0 0xe6188000 0 0x8000>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 26/31] ARM: dts: r8a7779: Add device node for PRR
From: Simon Horman @ 2016-11-17 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479391750.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Add a device node for the Product Register, which provides SoC product
and revision information.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7779.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 3005308a1807..9d3bb74bd3f6 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -590,6 +590,11 @@
};
};
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0xff000044 4>;
+ };
+
sysc: system-controller at ffd85000 {
compatible = "renesas,r8a7779-sysc";
reg = <0xffd85000 0x0200>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 27/31] ARM: dts: r8a7790: Add device node for PRR
From: Simon Horman @ 2016-11-17 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479391750.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Add a device node for the Product Register, which provides SoC product
and revision information.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7790.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index a946474be9cf..f554ef3c8096 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1471,6 +1471,11 @@
};
};
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0 0xff000044 0 4>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7790-sysc";
reg = <0 0xe6180000 0 0x0200>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [GIT PULL] Second Round of Renesas ARM Based SoC DT Updates for v4.10
From: Simon Horman @ 2016-11-17 14:11 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Hi Kevin, Hi Arnd,
Please consider these second round of Renesas ARM based SoC DT updates for v4.10.
This pull request is based on a merge of:
* The previous round of such requests, tagged as renesas-dt-for-v4.10,
which I have already sent a pull-request for.
* The rzg-clock-defs tag of Geert Uytterhoeven's renesas-driver's tree.
This is to provide dependencies for adding the r8a7743 and r8a7745 SoCs.
* The "Second Round of Renesas ARM Based SoC Drivers Updates for v4.10",
tagged as renesas-drivers2-for-v4.10, which I have also sent a pull
request for. This is included to provide dependencies for adding device
nodes for PRR, and adding the r8a7743 and r8a7745 SoCs..
The following changes since commit 71eaf88fb7784932956a998968f609c9a89cd739:
Merge branch 'rzg-clock-defs' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into dt-for-v4.10 (2016-11-17 14:58:57 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-dt2-for-v4.10
for you to fetch changes up to cb74f5808db5105baaf127c51660bbb1a10313c4:
ARM: dts: r8a7794: Add device node for PRR (2016-11-17 15:07:49 +0100)
----------------------------------------------------------------
Second Round of Renesas ARM Based SoC DT Updates for v4.10
Enhancements:
* Add device nodes for PRR
* Add r8a7745 SoC and sk-rzg1e board
* Add r8a7743 SoC and sk-rzg1m board
* Enable SDR-104 and I2C demuxer on alt, koelsch and lager boards
Corrections:
* Use SYSC "always-on" PM Domain for sound on r8a7794 SoC
* Correct hsusb parent clock on r8a7794 SoC
* Correct PFC names for DU on alt board
----------------------------------------------------------------
Geert Uytterhoeven (9):
ARM: dts: r8a7794: Correct hsusb parent clock
ARM: dts: r8a7794: Use SYSC "always-on" PM Domain for sound
ARM: dts: r8a73a4: Add device node for PRR
ARM: dts: r8a7779: Add device node for PRR
ARM: dts: r8a7790: Add device node for PRR
ARM: dts: r8a7791: Add device node for PRR
ARM: dts: r8a7792: Add device node for PRR
ARM: dts: r8a7793: Add device node for PRR
ARM: dts: r8a7794: Add device node for PRR
Jacopo Mondi (1):
ARM: dts: alt: Fix PFC names for DU
Sergei Shtylyov (14):
ARM: dts: r8a7743: initial SoC device tree
ARM: dts: r8a7743: add SYS-DMAC support
ARM: dts: r8a7743: add [H]SCIF{A|B} support
ARM: dts: r8a7743: add Ether support
ARM: dts: r8a7743: add IRQC support
ARM: dts: sk-rzg1m: initial device tree
ARM: dts: sk-rzg1m: add Ether support
ARM: dts: r8a7745: initial SoC device tree
ARM: dts: r8a7745: add SYS-DMAC support
ARM: dts: r8a7745: add [H]SCIF{|A|B} support
ARM: dts: r8a7745: add Ether support
ARM: dts: r8a7745: add IRQC support
ARM: dts: sk-rzg1e: initial device tree
ARM: dts: sk-rzg1e: add Ether support
Simon Horman (7):
ARM: dts: lager: rename and reindex i2cexio
ARM: dts: lager: use demuxer for IIC1/I2C1
ARM: dts: koelsch: use demuxer for I2C1
ARM: dts: alt: use demuxer for I2C4
ARM: dts: lager: Enable UHS-I SDR-104
ARM: dts: koelsch: Enable UHS-I SDR-104
ARM: dts: alt: Enable UHS-I SDR-104
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/r8a73a4.dtsi | 5 +
arch/arm/boot/dts/r8a7743-sk-rzg1m.dts | 57 ++++
arch/arm/boot/dts/r8a7743.dtsi | 476 +++++++++++++++++++++++++++++++++
arch/arm/boot/dts/r8a7745-sk-rzg1e.dts | 52 ++++
arch/arm/boot/dts/r8a7745.dtsi | 476 +++++++++++++++++++++++++++++++++
arch/arm/boot/dts/r8a7779.dtsi | 5 +
arch/arm/boot/dts/r8a7790-lager.dts | 52 +++-
arch/arm/boot/dts/r8a7790.dtsi | 5 +
arch/arm/boot/dts/r8a7791-koelsch.dts | 36 +++
arch/arm/boot/dts/r8a7791.dtsi | 5 +
arch/arm/boot/dts/r8a7792.dtsi | 5 +
arch/arm/boot/dts/r8a7793.dtsi | 5 +
arch/arm/boot/dts/r8a7794-alt.dts | 40 ++-
arch/arm/boot/dts/r8a7794.dtsi | 11 +-
15 files changed, 1220 insertions(+), 12 deletions(-)
create mode 100644 arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
create mode 100644 arch/arm/boot/dts/r8a7743.dtsi
create mode 100644 arch/arm/boot/dts/r8a7745-sk-rzg1e.dts
create mode 100644 arch/arm/boot/dts/r8a7745.dtsi
^ permalink raw reply
* [PATCH 28/31] ARM: dts: r8a7791: Add device node for PRR
From: Simon Horman @ 2016-11-17 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479391750.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Add a device node for the Product Register, which provides SoC product
and revision information.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7791.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 091d7fb6ee7d..4c50de2faef1 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -1485,6 +1485,11 @@
};
};
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0 0xff000044 0 4>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7791-sysc";
reg = <0 0xe6180000 0 0x0200>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 29/31] ARM: dts: r8a7792: Add device node for PRR
From: Simon Horman @ 2016-11-17 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479391750.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Add a device node for the Product Register, which provides SoC product
and revision information.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7792.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7792.dtsi b/arch/arm/boot/dts/r8a7792.dtsi
index a75e0cd312c5..69789020cf39 100644
--- a/arch/arm/boot/dts/r8a7792.dtsi
+++ b/arch/arm/boot/dts/r8a7792.dtsi
@@ -120,6 +120,11 @@
IRQ_TYPE_LEVEL_LOW)>;
};
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0 0xff000044 0 4>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7792-sysc";
reg = <0 0xe6180000 0 0x0200>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 30/31] ARM: dts: r8a7793: Add device node for PRR
From: Simon Horman @ 2016-11-17 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479391750.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Add a device node for the Product Register, which provides SoC product
and revision information.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7793.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 629d3d60d1cd..a377dda17724 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -1306,6 +1306,11 @@
};
};
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0 0xff000044 0 4>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7793-sysc";
reg = <0 0xe6180000 0 0x0200>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 31/31] ARM: dts: r8a7794: Add device node for PRR
From: Simon Horman @ 2016-11-17 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479391750.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Add a device node for the Product Register, which provides SoC product
and revision information.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7794.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 364b4aa8d1c1..63dc7f29d216 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -1377,6 +1377,11 @@
};
};
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0 0xff000044 0 4>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7794-sysc";
reg = <0 0xe6180000 0 0x0200>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [RFC PATCH] of: base: add support to get machine model name
From: Arnd Bergmann @ 2016-11-17 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <622ddcbc-69b9-98f2-51f3-e256764ecb93@arm.com>
On Thursday, November 17, 2016 2:08:30 PM CET Sudeep Holla wrote:
> On 17/11/16 13:50, Arnd Bergmann wrote:
> > On Thursday, November 17, 2016 11:50:50 AM CET Sudeep Holla wrote:
> >> Currently platforms/drivers needing to get the machine model name are
> >> replicating the same snippet of code. In some case, the OF reference
> >> counting is either missing or incorrect.
> >>
> >> This patch adds support to read the machine model name either using
> >> the "model" or the "compatible" property in the device tree root node.
> >>
> >> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> >
> > I like the idea. One small comment:
> >
>
> Thanks. I prefer it as single patch but it can't be applied to any tree.
> Any suggestions on handling this patch to fix the warning in -next ?
>
The patch that causes the warning is currently in the mmc tree, and I
don't think it would be good to have your entire patch in there too.
It's probably best to just fix the warning there now by adding another
open-coded copy of that function, and then apply your patch on top
for v4.11.
Arnd
^ permalink raw reply
* [RFC PATCH] of: base: add support to get machine model name
From: Sudeep Holla @ 2016-11-17 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2202339.ajrKjCY7Ro@wuerfel>
On 17/11/16 14:13, Arnd Bergmann wrote:
> On Thursday, November 17, 2016 2:08:30 PM CET Sudeep Holla wrote:
>> On 17/11/16 13:50, Arnd Bergmann wrote:
>>> On Thursday, November 17, 2016 11:50:50 AM CET Sudeep Holla wrote:
>>>> Currently platforms/drivers needing to get the machine model name are
>>>> replicating the same snippet of code. In some case, the OF reference
>>>> counting is either missing or incorrect.
>>>>
>>>> This patch adds support to read the machine model name either using
>>>> the "model" or the "compatible" property in the device tree root node.
>>>>
>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>>
>>> I like the idea. One small comment:
>>>
>>
>> Thanks. I prefer it as single patch but it can't be applied to any tree.
>> Any suggestions on handling this patch to fix the warning in -next ?
>>
> The patch that causes the warning is currently in the mmc tree, and I
> don't think it would be good to have your entire patch in there too.
>
> It's probably best to just fix the warning there now by adding another
> open-coded copy of that function, and then apply your patch on top
> for v4.11.
Sure, that's much simpler to deal with for now.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH next] arm64: remove "SMP: Total of %d processors activated." message
From: Will Deacon @ 2016-11-17 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479367946-38771-1-git-send-email-wangkefeng.wang@huawei.com>
On Thu, Nov 17, 2016 at 03:32:26PM +0800, Kefeng Wang wrote:
> There is a common SMP boot message in generic code on all arches,
> kill "SMP: Total of %d processors activated." in smp_cpus_done()
> on arm64.
>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> ---
> Boot message on qemu.
> [ 0.375116] smp: Brought up 1 node, 8 CPUs
> [ 0.383749] SMP: Total of 8 processors activated.
>
> arch/arm64/kernel/smp.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index cb87234..9db4a95 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -428,7 +428,6 @@ static void __init hyp_mode_check(void)
>
> void __init smp_cpus_done(unsigned int max_cpus)
> {
> - pr_info("SMP: Total of %d processors activated.\n", num_online_cpus());
> setup_cpu_features();
> hyp_mode_check();
> apply_alternatives_all();
Why? Are you proposing the same change to other architectures? Are you paid
per patch?
Will
^ permalink raw reply
* [PATCH] arm64: mm: Fix memmap to be initialized for the entire section
From: Will Deacon @ 2016-11-17 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109195132.GZ22012@rric.localdomain>
On Wed, Nov 09, 2016 at 08:51:32PM +0100, Robert Richter wrote:
> Thus, I don't see where my patch breaks code. Even acpi_os_ioremap()
> keeps the same behaviour as before since it still uses memblock_is_
> memory(). Could you more describe your concerns why do you think this
> patch breaks the kernel and moves the problem somewhere else? I
> believe it fixes the problem at all.
acpi_os_ioremap always ends up in __ioremap_caller, regardless of
memblock_is_memory(). __ioremap_caller then fails if pfn_valid is true.
Will
^ permalink raw reply
* Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'
From: Guenter Roeck @ 2016-11-17 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117105513.GA12273@leverpostej>
On 11/17/2016 02:55 AM, Mark Rutland wrote:
> On Wed, Nov 16, 2016 at 02:40:24PM -0800, Guenter Roeck wrote:
>> On Wed, Nov 16, 2016 at 08:27:09PM -0200, Fabio Estevam wrote:
>>> Hi Guenter,
>>>
>>> On Wed, Nov 16, 2016 at 8:10 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>>>>
>>>> Anyway, I guess the problem is that the "official" dtb files no longer provide
>>>> the skeleton /chosen and /memory nodes (and maybe others), and qemu seems to
>>>> expect that they are provided. Is that correct ?
>>>
>>> imx6qdl-sabrelite.dtsi provides chosen and memory nodes.
>>
>> Yes, but not the 'device_type' property, which the kernel seems to expect.
>
> Memory nodes require this property per ePAPR and the devicetree.org
> spec, so the bug is that we didn't add those when removing the
> skeleton.dtsi include.
>
The downside from qemu perspective is that the real hardware seems
to add the property unconditionally, or the boot failure would have
been seen there as well.
I submitted https://patchwork.ozlabs.org/patch/695951/; we'll see how it goes.
Guenter
>> The qemu patch below fixes the problem for sabrelite, I just don't know
>> if that is really the way to go. You tell me; I'll be happy to submit
>> the necessary patch(es) into qemu.
>
> As above, I don't think the below patch is necessary. The dt should have
> this property to begin with.
>
>> The same is true for 'chosen'. Right now qemu expects this node to exist.
>> It does exist for sabrelite, but apparently not for imx25-pdk.
>
> Having QEMU create a /chosen node if one does not exist already sounds
> sensible to me.
>
> Thanks,
> Mark.
>
>> Guenter
>>
>> ---
>> diff --git a/hw/arm/boot.c b/hw/arm/boot.c
>> index 1b913a4..080d1e5 100644
>> --- a/hw/arm/boot.c
>> +++ b/hw/arm/boot.c
>> @@ -486,6 +486,12 @@ static int load_dtb(hwaddr addr, const struct arm_boot_info *binfo,
>> g_free(nodename);
>> }
>> } else {
>> + Error *err = NULL;
>> +
>> + if (!qemu_fdt_getprop(fdt, "/memory", "device_type", NULL, &err)) {
>> + qemu_fdt_setprop_string(fdt, "/memory", "device_type", "memory");
>> + }
>> +
>> rc = qemu_fdt_setprop_sized_cells(fdt, "/memory", "reg",
>> acells, binfo->loader_start,
>> scells, binfo->ram_size);
>
^ permalink raw reply
* [PATCH 0/3] thermal: Fix module autoload for drivers
From: Eduardo Valentin @ 2016-11-17 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABxcv==keE6X5B1R+DSaZewVDdpCtuGF5j4S46YF3pncHT8q2Q@mail.gmail.com>
On Thu, Nov 17, 2016 at 08:50:11AM -0300, Javier Martinez Canillas wrote:
> Hello Eduardo,
>
> On Fri, Oct 14, 2016 at 11:34 AM, Javier Martinez Canillas
> <javier@osg.samsung.com> wrote:
> > Hello,
> >
> > This small series contains trivial fixes to allow modules to be autoloaded
> > when its correspoinding thermal device is registered.
> >
> > Best regards,
> > Javier
> >
> >
> > Javier Martinez Canillas (3):
> > thermal: max77620: Fix module autoload
> > thermal: tango: Fix module autoload
> > thermal: db8500: Fix module autoload
> >
>
> Any comments about these patches?
So far no. I am finalizing a couple of automated testing, but they are
in my queue.
Thanks for the fixes.
BR,
>
> Best regards,
> Javier
^ permalink raw reply
* [PATCH v5 1/7] drm: sunxi: Add a basic DRM driver for Allwinner DE2
From: Jean-Francois Moine @ 2016-11-17 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116213306.s5o5zi7pgppwuq7t@lukather>
On Wed, 16 Nov 2016 22:33:06 +0100
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> > > > The Device Engine just handles the planes of the LCDs, but, indeed,
> > > > the LCDs must know about the DE and the DE must know about the LCDs.
> > > > There are 2 ways to realize this knowledge in the DT:
> > > > 1) either the DE has one or two phandle's to the LCDs,
> > > > 2) or the LCDs have a phandle to the DE.
> > > >
> > > > I chose the 1st way, the DE ports pointing to the endpoint of the LCDs
> > > > which is part of the video link (OF-graph LCD <-> connector).
> > > > It would be possible to have phandles to the LCDs themselves, but this
> > > > asks for more code.
> > > >
> > > > The second way is also possible, but it also complexifies a bit the
> > > > exchanges DE <-> LCD.
> > >
> > > I'm still not sure how it would complexify anything, and why you can't
> > > use the display graph to model the relation between the display engine
> > > and the TCON (and why you want to use a generic property that refers
> > > to the of-graph while it really isn't).
> >
> > Complexification:
> > 1- my solution:
> > At startup time, the DE device is the DRM device.
>
> How do you deal with SoCs with multiple display engines then?
In the H3, A83T and A64, there is only one DE.
If many DEs in a SoC, there may be either one DRM device per DE or one
DRM device for the whole system. In this last case, the (global) DE
would have many resources (many I/O memory maps / IRQs..) and the
physical DE of each endpoint would be indicated by the position of its
phandle in the 'ports' array (DT documentation).
> > It has to know the devices entering in the video chains.
> > The CRTCs (LCD/TCON) are found by
> > ports[i] -> parent
> > The connectors are found by
> > ports[i] -> endpoint -> remote_endpoint -> parent
> > 2- with ports pointing to the LCDs:
> > The CRTCs (LCD/TCON) are simply
> > ports[i]
> > The connectors are found by
> > loop on all ports of ports[i]
> > ports[i][j] -> endpoint -> remote_endpoint -> parent
> > 3- with a phandle to the DE in the LCDs:
>
> What do you mean with LCD? Panels? Why would panels have a phandle to
> the display engine?
LCD is the same as CRTC. I don't think people will connect old CRT's to
their new ARM boards. LCD's may be panels, modern TV sets, or any
digital display. The word LCD seems clearer to me in this context, even
if there may a DAC as an ancoder.
> > The DE cannot be the DRM device because there is no information about
> > the video devices in the DT. Then, the DRM devices are the LCDs.
> > These LCDs must give their indices to the DE. So, the DE must implement
> > some callback function to accept a LCD definition, and there must be
> > a list of DEs in the driver to make the association DE <-> LCD[i]
> > Some more problem may be raised if a user wants to have the same frame
> > buffer on the 2 LCDs of a DE.
>
> I have no idea what you're talking about, sorry.
Here is the DT (I am using back 'CRTC'):
de: display-controller at xxx {
...
};
crtc0: crt-controller at xxx{
...
display-controller = <&de>;
ports {
... /* to the crtc0 connectors */
}
};
crtc1: crt-controller at xxx{
...
display-controller = <&de>;
ports {
... /* to the crtc1 connectors */
};
};
There are 2 DRM devices: one on crtc0, the other one on crtc1.
The DE device is isolated. But, to treat the planes, it must receive
information about the CRTCs. How?
> > Anyway, my solution is already used in the IMX Soc.
> > See 'display-subsystem' in arch/arm/boot/dts/imx6q.dtsi for an example.
>
> Pointing out random example in the tree doesn't make a compelling
> argument.
This is not a random example. There was a thread about the 'ports'
phandle in the DT definition of the IMX video subsystem, and what kind
of OF function should be used (see one of my previous mails). In the DRI
list, nobody objected about the phandle by itself.
> > > > > > > Panel functions? In the CRTC driver?
> > > > > >
> > > > > > Yes, dumb panel.
> > > > >
> > > > > What do you mean by that? Using a Parallel/RGB interface?
> > > >
> > > > Sorry, I though this was a well-known name. The 'dump panel' was used
> > > > in the documentation of my previous ARM machine as the video frame sent
> > > > to the HDMI controller. 'video_frame' is OK for you?
> > >
> > > If it's the frame sent to the encoder, then it would be the CRTC by
> > > DRM's nomenclature.
> >
> > The CRTC is a software entity. The frame buffer is a hardware entity.
>
> Why are you about framebuffer now, this is nowhere in that
> discussion. Any way, the framebuffer is also what is put in a plane,
> so there's a name collision here, and you'll probably want to change
> it.
>
> Judging by the previous discussion, this should really be called
> encoder if it encodes the frames on a bus format, or CRTC if it
> composes the planes.
I think that we will end in agreeing on the words. We just need some
time!
Here is how I understand the Allwinner's DE2:
- the TCON is the piece of hardware which gets some memory area and
sends it to a bus according to some configuation (screen resolution,
timings...). The bus data are encoded and transmitted to the connector.
At the end, the display device receives frames. So, going back to the
TCON, the memory are is the frame buffer.
- this frame buffer is virtual, empty, 'dumb', it is a dumb panel!
It is filled by planes. This job is done by a specific image
processor, the one contained in the DE2.
- the DE2 processor gets the plane source images from the SoC memory.
It adjusts the images according to many configuration parameters and
includes the result into the frame buffer.
So:
LCD = CRTC = frame buffer = dumb panel = TCON
- LCD = hardware piece of a display device (terminal side) which renders
the colored pixels in a digital way. By extension, the hardware part
(computer side) of a display engine which handles the definitions of
a digital or analog physical display device. By extension also,
the software structure (driver side) which defines a physical screen.
- CRTC = DRM software entity which handles the definitions of a screen,
but not just a CRT.
- frame buffer = piece of memory which contains the images which are
sent to a screen.
- dumb panel = abstract entity which defines the characteristics of a
physical screen.
You may note that, in the DE2 scheme, the TCON and LCD are not in the
same (software) device while they are part of the same DRM software
entity, the CTRC.
> > > > > If it is similar, I think hardcoding the pipe number is pretty bad,
> > > > > because that would restrict the combination of planes and formats,
> > > > > while some other might have worked.
> > > >
> > > > From what I understood about the DE2, the pipes just define the priority
> > > > of the overlay channels (one pipe for one channel).
> > > > With the cursor constraint, there must be at least 2 channels in
> > > > order (primary, cursor). Then, with these 2 channels/pipes, there can be
> > > > 6 so-called overlay planes (3 RGB/YUV and 3 RGB only).
> > > > Enabling the pipes 2 and 3 (LCD 0 only) would offer 8 more planes, but
> > > > RGB only. Then, it might be useful to have dynamic pipes.
> > >
> > > That's very valuable (and definitely should go into a comment),
> > > thanks!
> > >
> > > I still believe that's it should be into a (simple at first)
> > > atomic_check. That would be easier to extend and quite easy to
> > > document and get simply by looking at the code.
> >
> > Sorry for I don't understand what you mean.
>
> You can check all the constraints you exposed above in atomic_check
> instead of hardcoding it.
Sorry, but I don't like to run useless code for pure static definition.
> > The DE and the LCDs are different devices on different drivers.
> > A DE must be only one device because it has to handle concurent
> > accesses from its 2 LCDs. Then 2 drivers.
>
> If it's different drivers, why are they in the same module?
>
> > But only one module. Why? Because there cannot be double direction
> > calls from one module to an other one, and, in our case, for example,
> > - the DRM (DE) device must call vblank functions which are handled in
> > the CRTC (TCON) device, and
> > - the CRTC device must call DE initialization functions at startup time.
>
> I'm sorry, but that doesn't make any sense. The crtc device should
> take care of the CRTC functions. Your DRM CRTC and encoders can
> definitely be shared across different devices, you can have a look at
> how we're doing it for sun4i.
>
> We basically have 3 drivers to create most of the display pipeline:
> - One for the DRM device
> - One for the display engine
> - One for the TCON
Your DRM device is useless. It is simpler to have the DRM device as the
display engine.
Also, maybe, you have not the constraint the DE being shared between
2 CRTCs.
> Once they have all loaded and registered in the component framework,
> their bind callback is called, and it's when the DRM entities are
> created using exported functions to manipulate what needs to be setup.
>
> It's definitely doable, it just takes some effort.
It seems you did not look at what I have coded...
> > On the other side, removing the cursor would just let one more plane.
> > Do we really need this one? In other words, I'd be pleased to know how
> > you run 7 applications doing video overlay.
>
> You can use those planes to do composition too, with each application
> having one or more plane. Android uses that.
>
> There's no argument to have a cursor plane, really. Even regular
> graphic stack like X can use a regular overlay to have its cursor on
> it. It doesn't *remove* anything, it just allows to use the plane for
> what it was supposed to be used for.
I'd be glad to know how you can have a hardware cursor without defining
it in drm_crtc_init_with_planes().
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH 0/3] thermal: Fix module autoload for drivers
From: Javier Martinez Canillas @ 2016-11-17 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117145327.GA2781@localhost.localdomain>
Hello Eduardo,
On 11/17/2016 11:53 AM, Eduardo Valentin wrote:
> On Thu, Nov 17, 2016 at 08:50:11AM -0300, Javier Martinez Canillas wrote:
>> Hello Eduardo,
>>
>> On Fri, Oct 14, 2016 at 11:34 AM, Javier Martinez Canillas
>> <javier@osg.samsung.com> wrote:
>>> Hello,
>>>
>>> This small series contains trivial fixes to allow modules to be autoloaded
>>> when its correspoinding thermal device is registered.
>>>
>>> Best regards,
>>> Javier
>>>
>>>
>>> Javier Martinez Canillas (3):
>>> thermal: max77620: Fix module autoload
>>> thermal: tango: Fix module autoload
>>> thermal: db8500: Fix module autoload
>>>
>>
>> Any comments about these patches?
>
> So far no. I am finalizing a couple of automated testing, but they are
> in my queue.
>
Ok, I also got your automated emails about them being applied.
> Thanks for the fixes.
>
Thanks.
> BR,
>
>>
>> Best regards,
>> Javier
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'
From: Mark Rutland @ 2016-11-17 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <198d764e-1612-81b4-5f4e-0c221a23c8e0@roeck-us.net>
On Thu, Nov 17, 2016 at 06:44:55AM -0800, Guenter Roeck wrote:
> On 11/17/2016 02:55 AM, Mark Rutland wrote:
> >On Wed, Nov 16, 2016 at 02:40:24PM -0800, Guenter Roeck wrote:
> >>On Wed, Nov 16, 2016 at 08:27:09PM -0200, Fabio Estevam wrote:
> >>>Hi Guenter,
> >>>
> >>>On Wed, Nov 16, 2016 at 8:10 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> >>>>
> >>>>Anyway, I guess the problem is that the "official" dtb files no longer provide
> >>>>the skeleton /chosen and /memory nodes (and maybe others), and qemu seems to
> >>>>expect that they are provided. Is that correct ?
> >>>
> >>>imx6qdl-sabrelite.dtsi provides chosen and memory nodes.
> >>
> >>Yes, but not the 'device_type' property, which the kernel seems to expect.
> >
> >Memory nodes require this property per ePAPR and the devicetree.org
> >spec, so the bug is that we didn't add those when removing the
> >skeleton.dtsi include.
>
> The downside from qemu perspective is that the real hardware seems
> to add the property unconditionally, or the boot failure would have
> been seen there as well.
>
> I submitted https://patchwork.ozlabs.org/patch/695951/; we'll see how it goes.
Sure, the firmare/bootlaoder you're using may add this automatically.
My worry is that adding this to a generic file in QEMU only serves to
mask this class of bug for other boards (i.e. they'll work fine in QEMU,
but not on real HW using whatever bootlaoder happens ot be there).
Thanks,
Mark.
^ permalink raw reply
* [PATCH V8 2/6] thermal: bcm2835: add thermal driver for bcm2835 soc
From: Eduardo Valentin @ 2016-11-17 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <766e1b70-d83a-eb52-fa2b-aec435e85673@martin.sperl.org>
Hello Martin,
On Thu, Nov 17, 2016 at 10:51:33AM +0100, Martin Sperl wrote:
>
>
> On 17.11.2016 03:11, Eduardo Valentin wrote:
> >Hey Martin,
> >
> >Very sorry for the late feedback. Not so sure if this one got queued
> >already or not. Anyways, just minor questions as follows:
> >
> >On Wed, Nov 02, 2016 at 10:18:22AM +0000, kernel at martin.sperl.org wrote:
> >>From: Martin Sperl <kernel@martin.sperl.org>
> >>
> >>Add basic thermal driver for bcm2835 SOC.
> >>
> >>This driver currently relies on the firmware setting up the
> >>tsense HW block and does not set it up itself.
> >>
> >>Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
> >>Acked-by: Eric Anholt <eric@anholt.net>
> >>Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
> >>
> ...
> >>+static int bcm2835_thermal_adc2temp(
> >>+ const struct bcm2835_thermal_info *info, u32 adc)
> >>+{
> >>+ return info->offset + (adc * info->slope);
> >
> >Any specific reason we cannot use thermal_zone_params->slope and
> >thermal_zone_params->offset?
>
> You could - the patch was just rebased to 4.9 and those slope and
> offset just got merged during this cycle.
>
> Do we really need to modify it - the patch has been around since 4.6.
>
> >>+
> >>+static int bcm2835_thermal_get_trip_temp(
> >>+ struct thermal_zone_device *tz, int trip, int *temp)
> >>+{
> >>+ struct bcm2835_thermal_data *data = tz->devdata;
> >>+ u32 val = readl(data->regs + BCM2835_TS_TSENSCTL);
> >>+
> >>+ /* get the THOLD bits */
> >>+ val &= BCM2835_TS_TSENSCTL_THOLD_MASK;
> >>+ val >>= BCM2835_TS_TSENSCTL_THOLD_SHIFT;
> >>+
> >>+ /* if it is zero then use the info value */
> >>+ if (val)
> >
> >Is this a read only register or is this driver supposed to program it?
> >In which scenario it would be 0? Can this be added as comments?
>
> It is RW, but the Firmware typically sets up the thermal device with the
> correct values already - this is just a fallback.
OK, but how do you differentiate from a buggy firmware or misconfigured
hardware? How do you know if the firmware is supposed to be loaded and
ready? There is no firmware loading in this driver. Also, there is no
dependency with a driver that loads firmware, or at least, I missed it.
>
> >>+static int bcm2835_thermal_get_temp(struct thermal_zone_device *tz,
> >>+ int *temp)
> >>+{
> >>+ struct bcm2835_thermal_data *data = tz->devdata;
> >>+ u32 val = readl(data->regs + BCM2835_TS_TSENSSTAT);
> >>+
> >>+ if (!(val & BCM2835_TS_TSENSSTAT_VALID))
> >
> >What cases you would get the valid bit not set? Do you need to wait for
> >the conversion to finish?
>
> I guess: if you have just enabled the HW-block (which the FW does much
> in advance) and start to read the value immediately (before the first sample
> period has finished), then this will not be valid.
>
Then again, how does this driver make sure the initialization procedure
is correct, and that by the time it is using the hardware, the hardware
is in a sane state?
Back to the original question, does it mean the hardware is in
some sort of continuous ADC conversion mode or reading the temperature
requires specific steps to get the conversion done, and therefore you
are checking the valid bit here?
> So do you need another version of the patchset that uses that new API?
I think the API usage is change that can be done together with
clarification for the above questions too: on hardware state,
firmware loading, maybe a master driver dependency, and the ADC
conversion sequence, which are not well clear to me on this driver. As long as
this is clarified and documented in the code (can be simple comments so
it is clear to whoever reads in the future), then I would be OK with
this driver.
>
> Thanks,
> Martin
^ permalink raw reply
* [PATCH] arm64: mm: Fix memmap to be initialized for the entire section
From: Robert Richter @ 2016-11-17 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117142528.GJ22855@arm.com>
Thanks for your answer.
On 17.11.16 14:25:29, Will Deacon wrote:
> On Wed, Nov 09, 2016 at 08:51:32PM +0100, Robert Richter wrote:
> > Thus, I don't see where my patch breaks code. Even acpi_os_ioremap()
> > keeps the same behaviour as before since it still uses memblock_is_
> > memory(). Could you more describe your concerns why do you think this
> > patch breaks the kernel and moves the problem somewhere else? I
> > believe it fixes the problem at all.
>
> acpi_os_ioremap always ends up in __ioremap_caller, regardless of
> memblock_is_memory(). __ioremap_caller then fails if pfn_valid is true.
But that's the reason my patch changed the code to use memblock_is_
map_memory() instead. I was looking into the users of pfn_valid() esp.
in arm64 code and changed it where required.
This week I looked into the kernel again for code that might break by
a pfn_valid() change. I found try_ram_remap() in memremap.c that has
changed behaviour now, but this is explicit for MEMREMAP_WB, so it
should be fine.
Maybe it might be better to use page_is_ram() in addition to
pfn_valid() where necessary. This should work now after commit:
e7cd190385d1 arm64: mark reserved memblock regions explicitly in iomem
I still think pfn_valid() is not the correct use to determine the mem
attributes for mappings, there are further checks required.
The risk of breaking something with my patch is small and limited only
to the mapping of efi reserved regions (which is the state of 4.4). If
something breaks anyway it can easily be fixed by adding more checks
to pfn_valid() as suggested above.
-Robert
^ 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