[PATCH v3 0/2] Initial RTD1319 SoC and Realtek PymParticle EVB support

[PATCH v3 0/2] Initial RTD1319 SoC and Realtek PymParticle EVB support

[James Tai]

Hi Andreas,

This series adds Device Trees for the Realtek RTD1319 SoC and Realtek's
PymParticle EVB.

The v3 correct the GIC redistributor address range and adding the virtual
maintenance interrupt for architecture timer.

v2 -> v3:
* Add virtual maintenance interrupt for architecture timer
* Correct the GIC redistributor address range

v1 -> v2:
* Reserve the boot ROM address
* Reserve boot loader address
* Reserve audio/video FW address
* Reserve RPC and ring buffer address
* Reserve TEE address
* Support 1 GiB RAM by default
* Reduce rbus range to 2 MiB
* Apply the syscon for ISO,MISC,CRT,SB2,SCPU_WRAPPER
* Adjust compatible strings order in document

Cc: devicetree@vger.kernel.org
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Andreas Färber <afaerber@suse.de>

James Tai (2):
  dt-bindings: arm: realtek: Document RTD1319 and Realtek PymParticle
    EVB
  arm64: dts: realtek: Add RTD1319 SoC and Realtek PymParticle EVB

 .../devicetree/bindings/arm/realtek.yaml      |   6 +
 arch/arm64/boot/dts/realtek/Makefile          |   2 +
 .../boot/dts/realtek/rtd1319-pymparticle.dts  |  43 ++++
 arch/arm64/boot/dts/realtek/rtd1319.dtsi      |  12 +
 arch/arm64/boot/dts/realtek/rtd13xx.dtsi      | 213 ++++++++++++++++++
 5 files changed, 276 insertions(+)
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1319-pymparticle.dts
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1319.dtsi
 create mode 100644 arch/arm64/boot/dts/realtek/rtd13xx.dtsi

-- 
2.25.0

[PATCH v3 1/2] dt-bindings: arm: realtek: Document RTD1319 and Realtek PymParticle EVB

[James Tai]

Define compatible strings for Realtek RTD1319 SoC and Realtek PymParticle
EVB.

Signed-off-by: James Tai <james.tai@realtek.com>
---
 v2 -> v3: Unchanged

 v1 -> v2:
 * Put string in alphabetical order

 Documentation/devicetree/bindings/arm/realtek.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/realtek.yaml b/Documentation/devicetree/bindings/arm/realtek.yaml
index 845f9c76d6f7..3b48ae71fdd8 100644
--- a/Documentation/devicetree/bindings/arm/realtek.yaml
+++ b/Documentation/devicetree/bindings/arm/realtek.yaml
@@ -42,6 +42,12 @@ properties:
               - synology,ds418 # Synology DiskStation DS418
           - const: realtek,rtd1296
 
+      # RTD1319 SoC based boards
+      - items:
+          - enum:
+              - realtek,pymparticle # Realtek PymParticle EVB
+          - const: realtek,rtd1319
+
       # RTD1395 SoC based boards
       - items:
           - enum:
-- 
2.25.0

[PATCH v3 2/2] arm64: dts: realtek: Add RTD1319 SoC and Realtek PymParticle EVB

[James Tai]

Add Device Trees for Realtek RTD1319 SoC family, RTD1319 SoC and
Realtek PymParticle EVB.

Signed-off-by: James Tai <james.tai@realtek.com>
---
 v2 -> v3:
 * Add virtual maintenance interrupt for architecture timer
 * Correct the GIC redistributor address range

 v1 -> v2:
 * Reserve the boot ROM address
 * Reserve boot loader address
 * Reserve audio/video FW address
 * Reserve RPC and ring buffer address
 * Reserve TEE address
 * Support 1 GiB RAM by default
 * Reduce rbus range to 2 MiB
 * Apply the syscon for ISO,MISC,CRT,SB2,SCPU_WRAPPER
 * Adjust compatible strings order in document

 arch/arm64/boot/dts/realtek/Makefile          |   2 +
 .../boot/dts/realtek/rtd1319-pymparticle.dts  |  43 ++++
 arch/arm64/boot/dts/realtek/rtd1319.dtsi      |  12 +
 arch/arm64/boot/dts/realtek/rtd13xx.dtsi      | 213 ++++++++++++++++++
 4 files changed, 270 insertions(+)
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1319-pymparticle.dts
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1319.dtsi
 create mode 100644 arch/arm64/boot/dts/realtek/rtd13xx.dtsi

diff --git a/arch/arm64/boot/dts/realtek/Makefile b/arch/arm64/boot/dts/realtek/Makefile
index ef8d8fcbaa05..c0ae96f324eb 100644
--- a/arch/arm64/boot/dts/realtek/Makefile
+++ b/arch/arm64/boot/dts/realtek/Makefile
@@ -9,6 +9,8 @@ dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-zidoo-x9s.dtb
 
 dtb-$(CONFIG_ARCH_REALTEK) += rtd1296-ds418.dtb
 
+dtb-$(CONFIG_ARCH_REALTEK) += rtd1319-pymparticle.dtb
+
 dtb-$(CONFIG_ARCH_REALTEK) += rtd1395-bpi-m4.dtb
 dtb-$(CONFIG_ARCH_REALTEK) += rtd1395-lionskin.dtb
 
diff --git a/arch/arm64/boot/dts/realtek/rtd1319-pymparticle.dts b/arch/arm64/boot/dts/realtek/rtd1319-pymparticle.dts
new file mode 100644
index 000000000000..2a36d220fef6
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd1319-pymparticle.dts
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+/*
+ * Copyright (c) 2019 Realtek Semiconductor Corp.
+ */
+
+/dts-v1/;
+
+#include "rtd1319.dtsi"
+
+/ {
+	compatible = "realtek,pymparticle", "realtek,rtd1319";
+	model = "Realtek PymParticle EVB";
+
+	memory@2e000 {
+		device_type = "memory";
+		reg = <0x2e000 0x3ffd2000>; /* boot ROM to 1 GiB or 2 GiB */
+	};
+
+	chosen {
+		stdout-path = "serial0:460800n8";
+	};
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+	};
+};
+
+/* debug console (J1) */
+&uart0 {
+	status = "okay";
+};
+
+/* M.2 slot (CON8) */
+&uart1 {
+	status = "disabled";
+};
+
+/* GPIO connector (T1) */
+&uart2 {
+	status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/realtek/rtd1319.dtsi b/arch/arm64/boot/dts/realtek/rtd1319.dtsi
new file mode 100644
index 000000000000..1dcee00009cd
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd1319.dtsi
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+/*
+ * Realtek RTD1319 SoC
+ *
+ * Copyright (c) 2019 Realtek Semiconductor Corp.
+ */
+
+#include "rtd13xx.dtsi"
+
+/ {
+	compatible = "realtek,rtd1319";
+};
diff --git a/arch/arm64/boot/dts/realtek/rtd13xx.dtsi b/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
new file mode 100644
index 000000000000..f6d73f18345d
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+/*
+ * Realtek RTD13xx SoC family
+ *
+ * Copyright (c) 2019 Realtek Semiconductor Corp.
+ */
+
+/memreserve/	0x0000000000000000 0x000000000002e000; /* Boot ROM */
+/memreserve/	0x000000000002e000 0x0000000000100000; /* Boot loader */
+/memreserve/	0x000000000f400000 0x0000000000500000; /* Video FW */
+/memreserve/	0x000000000f900000 0x0000000000500000; /* Audio FW */
+/memreserve/	0x0000000010000000 0x0000000000014000; /* Audio FW RAM */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+	interrupt-parent = <&gic>;
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		rpc_comm: rpc@3f000 {
+			reg = <0x3f000 0x1000>;
+		};
+
+		rpc_ringbuf: rpc@1ffe000 {
+			reg = <0x1ffe000 0x4000>;
+		};
+
+		tee: tee@10100000 {
+			reg = <0x10100000 0xf00000>;
+			no-map;
+		};
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu0: cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0>;
+			enable-method = "psci";
+			next-level-cache = <&l2>;
+		};
+
+		cpu1: cpu@100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x100>;
+			enable-method = "psci";
+			next-level-cache = <&l2>;
+		};
+
+		cpu2: cpu@200 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x200>;
+			enable-method = "psci";
+			next-level-cache = <&l2>;
+		};
+
+		cpu3: cpu@300 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x300>;
+			enable-method = "psci";
+			next-level-cache = <&l2>;
+		};
+
+		l2: l2-cache {
+			compatible = "cache";
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
+			     <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
+			     <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
+			     <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>,
+			     <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
+	};
+
+	arm_pmu: pmu {
+		compatible = "arm,armv8-pmuv3";
+		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW>;
+		interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
+	};
+
+	psci {
+		compatible = "arm,psci-1.0";
+		method = "smc";
+	};
+
+	osc27M: osc {
+		compatible = "fixed-clock";
+		clock-frequency = <27000000>;
+		clock-output-names = "osc27M";
+		#clock-cells = <0>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x00000000 0x00000000 0x0002e000>, /* boot ROM */
+			 <0xff100000 0xff100000 0x00200000>, /* GIC */
+			 <0x98000000 0x98000000 0x00200000>; /* rbus */
+
+		rbus: bus@98000000 {
+			compatible = "simple-bus";
+			reg = <0x98000000 0x200000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0x0 0x98000000 0x200000>;
+
+			crt: syscon@0 {
+				compatible = "syscon", "simple-mfd";
+				reg = <0x0 0x1000>;
+				reg-io-width = <4>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0x0 0x0 0x1000>;
+			};
+
+			iso: syscon@7000 {
+				compatible = "syscon", "simple-mfd";
+				reg = <0x7000 0x1000>;
+				reg-io-width = <4>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0x0 0x7000 0x1000>;
+			};
+
+			sb2: syscon@1a000 {
+				compatible = "syscon", "simple-mfd";
+				reg = <0x1a000 0x1000>;
+				reg-io-width = <4>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0x0 0x1a000 0x1000>;
+			};
+
+			misc: syscon@1b000 {
+				compatible = "syscon", "simple-mfd";
+				reg = <0x1b000 0x1000>;
+				reg-io-width = <4>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0x0 0x1b000 0x1000>;
+			};
+
+			scpu_wrapper: syscon@1d000 {
+				compatible = "syscon", "simple-mfd";
+				reg = <0x1d000 0x1000>;
+				reg-io-width = <4>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0x0 0x1d000 0x1000>;
+			};
+		};
+
+		gic: interrupt-controller@ff100000 {
+			compatible = "arm,gic-v3";
+			reg = <0xff100000 0x10000>,
+			      <0xff140000 0x80000>;
+			interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-controller;
+			#interrupt-cells = <3>;
+		};
+	};
+};
+
+&iso {
+	uart0: serial0@800 {
+		compatible = "snps,dw-apb-uart";
+		reg = <0x800 0x400>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
+		clock-frequency = <432000000>;
+		status = "disabled";
+	};
+};
+
+&misc {
+	uart1: serial1@200 {
+		compatible = "snps,dw-apb-uart";
+		reg = <0x200 0x400>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
+		clock-frequency = <432000000>;
+		status = "disabled";
+	};
+
+	uart2: serial2@400 {
+		compatible = "snps,dw-apb-uart";
+		reg = <0x400 0x400>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
+		clock-frequency = <432000000>;
+		status = "disabled";
+	};
+};
-- 
2.25.0

Re: [PATCH v3 1/2] dt-bindings: arm: realtek: Document RTD1319 and Realtek PymParticle EVB

[Rob Herring]

On Tue, 4 Feb 2020 22:52:06 +0800, James Tai wrote:
> Define compatible strings for Realtek RTD1319 SoC and Realtek PymParticle
> EVB.
> 
> Signed-off-by: James Tai <james.tai@realtek.com>
> ---
>  v2 -> v3: Unchanged
> 
>  v1 -> v2:
>  * Put string in alphabetical order
> 
>  Documentation/devicetree/bindings/arm/realtek.yaml | 6 ++++++
>  1 file changed, 6 insertions(+)
> 

Please add Acked-by/Reviewed-by tags when posting new versions. However,
there's no need to repost patches *only* to add the tags. The upstream
maintainer will do that for acks received on the version they apply.

If a tag was not added on purpose, please state why and what changed.

RE: [PATCH v3 1/2] dt-bindings: arm: realtek: Document RTD1319 and Realtek PymParticle EVB

[James Tai [戴志峰]]

Hi Rob,

> 
> On Tue, 4 Feb 2020 22:52:06 +0800, James Tai wrote:
> > Define compatible strings for Realtek RTD1319 SoC and Realtek
> > PymParticle EVB.
> >
> > Signed-off-by: James Tai <james.tai@realtek.com>
> > ---
> >  v2 -> v3: Unchanged
> >
> >  v1 -> v2:
> >  * Put string in alphabetical order
> >
> >  Documentation/devicetree/bindings/arm/realtek.yaml | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> 
> Please add Acked-by/Reviewed-by tags when posting new versions. However,
> there's no need to repost patches *only* to add the tags. The upstream
> maintainer will do that for acks received on the version they apply.
> 
> If a tag was not added on purpose, please state why and what changed.
> 
I will improve it.

Thank you for your reply.

Regards,
James

Re: [PATCH v3 1/2] dt-bindings: arm: realtek: Document RTD1319 and Realtek PymParticle EVB

[Andreas Färber]

Hi James,

Am 04.02.20 um 15:52 schrieb James Tai:
> Define compatible strings for Realtek RTD1319 SoC and Realtek PymParticle
> EVB.
> 
> Signed-off-by: James Tai <james.tai@realtek.com>
> ---
>   v2 -> v3: Unchanged
> 
>   v1 -> v2:
>   * Put string in alphabetical order
> 
>   Documentation/devicetree/bindings/arm/realtek.yaml | 6 ++++++
>   1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/realtek.yaml b/Documentation/devicetree/bindings/arm/realtek.yaml
> index 845f9c76d6f7..3b48ae71fdd8 100644
> --- a/Documentation/devicetree/bindings/arm/realtek.yaml
> +++ b/Documentation/devicetree/bindings/arm/realtek.yaml
> @@ -42,6 +42,12 @@ properties:
>                 - synology,ds418 # Synology DiskStation DS418
>             - const: realtek,rtd1296
>   
> +      # RTD1319 SoC based boards
> +      - items:
> +          - enum:
> +              - realtek,pymparticle # Realtek PymParticle EVB

The board seems labelled "PYM_PARTICLES".

While Wikipedia has nothing on that, I found this explanation:
https://marvel.fandom.com/wiki/Pym_Particles

So, are you sure it's PymParticle and not "Pym Particle" with space or 
"Pym Particles" with space and plural S? The S would affect also the 
.dts filename. For the compatible string the question is pymparticle or 
pym-particle.

By comparison, LION-SKIN was named lion-skin in the compatible and 
spelled Lion Skin in textual form. If you believe that should be fixed, 
now would be the time to revisit those patches that didn't make v5.7.

Thanks,
Andreas

> +          - const: realtek,rtd1319
> +
>         # RTD1395 SoC based boards
>         - items:
>             - enum:

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)

RE: [PATCH v3 1/2] dt-bindings: arm: realtek: Document RTD1319 and Realtek PymParticle EVB

[James Tai [戴志峰]]

Hi Andreas,

Thanks for your review!

>
> > diff --git a/Documentation/devicetree/bindings/arm/realtek.yaml
> > b/Documentation/devicetree/bindings/arm/realtek.yaml
> > index 845f9c76d6f7..3b48ae71fdd8 100644
> > --- a/Documentation/devicetree/bindings/arm/realtek.yaml
> > +++ b/Documentation/devicetree/bindings/arm/realtek.yaml
> > @@ -42,6 +42,12 @@ properties:
> >                 - synology,ds418 # Synology DiskStation DS418
> >             - const: realtek,rtd1296
> >
> > +      # RTD1319 SoC based boards
> > +      - items:
> > +          - enum:
> > +              - realtek,pymparticle # Realtek PymParticle EVB
> 
> The board seems labelled "PYM_PARTICLES".
> 
> While Wikipedia has nothing on that, I found this explanation:
> https://marvel.fandom.com/wiki/Pym_Particles
> 
> So, are you sure it's PymParticle and not "Pym Particle" with space or "Pym
> Particles" with space and plural S? The S would affect also the .dts filename.
>
I should change the string to "Pym Particles".

> For the compatible string the question is pymparticle or pym-particle.
> 
The compatible string is "pym-particles".

> By comparison, LION-SKIN was named lion-skin in the compatible and spelled
> Lion Skin in textual form. If you believe that should be fixed, now would be the
> time to revisit those patches that didn't make v5.7.
> 
I'll check those relevant patches.

Thank you.

Regards,
James

Re: [PATCH v3 1/2] dt-bindings: arm: realtek: Document RTD1319 and Realtek PymParticle EVB

[Andreas Färber]

Hi James,

Am 15.04.20 um 10:58 schrieb James Tai [戴志峰]:
>>> diff --git a/Documentation/devicetree/bindings/arm/realtek.yaml
>>> b/Documentation/devicetree/bindings/arm/realtek.yaml
>>> index 845f9c76d6f7..3b48ae71fdd8 100644
>>> --- a/Documentation/devicetree/bindings/arm/realtek.yaml
>>> +++ b/Documentation/devicetree/bindings/arm/realtek.yaml
>>> @@ -42,6 +42,12 @@ properties:
>>>                  - synology,ds418 # Synology DiskStation DS418
>>>              - const: realtek,rtd1296
>>>
>>> +      # RTD1319 SoC based boards
>>> +      - items:
>>> +          - enum:
>>> +              - realtek,pymparticle # Realtek PymParticle EVB
>>
>> The board seems labelled "PYM_PARTICLES".
>>
>> While Wikipedia has nothing on that, I found this explanation:
>> https://marvel.fandom.com/wiki/Pym_Particles
>>
>> So, are you sure it's PymParticle and not "Pym Particle" with space or "Pym
>> Particles" with space and plural S? The S would affect also the .dts filename.
>>
> I should change the string to "Pym Particles".

Okay, in that case I suggest rtd1319-pymparticles.dts for consistency. 
Unless you want to change rtd1395-lionskin.dts to rtd1395-lion-skin.dts.

>> For the compatible string the question is pymparticle or pym-particle.
>>
> The compatible string is "pym-particles".

Works for me. (always assuming we both imply the "realtek," prefix)

If you send a v4, please double-check the comments in patch 2/2.

>> By comparison, LION-SKIN was named lion-skin in the compatible and spelled
>> Lion Skin in textual form. If you believe that should be fixed, now would be the
>> time to revisit those patches that didn't make v5.7.
>>
> I'll check those relevant patches.

Thanks,
Andreas

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)

Re: [PATCH v3 2/2] arm64: dts: realtek: Add RTD1319 SoC and Realtek PymParticle EVB

[Andreas Färber]

Hi James,

A couple more nits to consider for v4:

Am 04.02.20 um 15:52 schrieb James Tai:
> diff --git a/arch/arm64/boot/dts/realtek/rtd1319-pymparticle.dts b/arch/arm64/boot/dts/realtek/rtd1319-pymparticle.dts
> new file mode 100644
> index 000000000000..2a36d220fef6
> --- /dev/null
> +++ b/arch/arm64/boot/dts/realtek/rtd1319-pymparticle.dts
> @@ -0,0 +1,43 @@
> +// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
> +/*
> + * Copyright (c) 2019 Realtek Semiconductor Corp.

2019-2020? (also elsewhere)

> + */
> +
> +/dts-v1/;
> +
> +#include "rtd1319.dtsi"
> +
> +/ {
> +	compatible = "realtek,pymparticle", "realtek,rtd1319";
> +	model = "Realtek PymParticle EVB";
> +
> +	memory@2e000 {
> +		device_type = "memory";
> +		reg = <0x2e000 0x3ffd2000>; /* boot ROM to 1 GiB or 2 GiB */
> +	};
> +
> +	chosen {
> +		stdout-path = "serial0:460800n8";
> +	};
> +
> +	aliases {
> +		serial0 = &uart0;
> +		serial1 = &uart1;
> +		serial2 = &uart2;
> +	};
> +};
> +
> +/* debug console (J1) */
> +&uart0 {
> +	status = "okay";
> +};
> +
> +/* M.2 slot (CON8) */

Also J14 and CON2 (unless the board is mislabeled?).

/* J14 and M.2 slots (CON2, CON8) */ ?

> +&uart1 {
> +	status = "disabled";
> +};
> +
> +/* GPIO connector (T1) */
> +&uart2 {
> +	status = "disabled";
> +};
> diff --git a/arch/arm64/boot/dts/realtek/rtd1319.dtsi b/arch/arm64/boot/dts/realtek/rtd1319.dtsi
> new file mode 100644
> index 000000000000..1dcee00009cd
> --- /dev/null
> +++ b/arch/arm64/boot/dts/realtek/rtd1319.dtsi
> @@ -0,0 +1,12 @@
> +// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
> +/*
> + * Realtek RTD1319 SoC
> + *
> + * Copyright (c) 2019 Realtek Semiconductor Corp.
> + */
> +
> +#include "rtd13xx.dtsi"
> +
> +/ {
> +	compatible = "realtek,rtd1319";
> +};
> diff --git a/arch/arm64/boot/dts/realtek/rtd13xx.dtsi b/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
> new file mode 100644
> index 000000000000..f6d73f18345d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
> @@ -0,0 +1,213 @@
> +// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
> +/*
> + * Realtek RTD13xx SoC family
> + *
> + * Copyright (c) 2019 Realtek Semiconductor Corp.
> + */
> +
> +/memreserve/	0x0000000000000000 0x000000000002e000; /* Boot ROM */

Can you check whether your U-Boot and LK respectively need this 
memreserve entry, here and for previous SoCs? Because for RTD16xx we 
don't seem to have any memreserve entries at all. We do have it in 
rtd139x.dtsi, rtd129x.dtsi and rtd1195.dtsi.

Unrelated: Since we're carving out the 2e000 or so from /memory node and 
mapping ranges for /soc, I've been wondering whether we should represent 
the Boot ROM as node somehow. But since it's a ROM with (I assume) 
binary code only, I didn't see any need to have it accessible as mtd-rom 
device, so it's way down my to-do list to research how other mainline 
platforms might model their boot ROMs... (maybe your team has time, or 
someone reading happens to know?)

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/mtd/mtd-physmap.txt

> +/memreserve/	0x000000000002e000 0x0000000000100000; /* Boot loader */

Is this a) correctly sized (not 0xd2000?) and b) still needed? I thought 
the documented sub-0x100000 memory corruption were fixed in newer BSPs?

> +/memreserve/	0x000000000f400000 0x0000000000500000; /* Video FW */
> +/memreserve/	0x000000000f900000 0x0000000000500000; /* Audio FW */
> +/memreserve/	0x0000000010000000 0x0000000000014000; /* Audio FW RAM */
[snip]

Are these needed for the bootloader not to overwrite preloaded firmware, 
or could these become /mem-reserve sub-nodes instead?

Long-term I'm assuming we would move the responsibility for loading 
these to the new kernel drivers (so that the bootloader doesn't need to 
take care anymore) and ship the needed blobs in linux-firmware.git?

Or is the video FW needed by the bootloader itself for HDMI/DP output?

Thanks,
Andreas

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)

RE: [PATCH v3 2/2] arm64: dts: realtek: Add RTD1319 SoC and Realtek PymParticle EVB

[James Tai [戴志峰]]

Hi Andreas,

> Am 04.02.20 um 15:52 schrieb James Tai:
> > diff --git a/arch/arm64/boot/dts/realtek/rtd1319-pymparticle.dts
> > b/arch/arm64/boot/dts/realtek/rtd1319-pymparticle.dts
> > new file mode 100644
> > index 000000000000..2a36d220fef6
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/realtek/rtd1319-pymparticle.dts
> > @@ -0,0 +1,43 @@
> > +// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
> > +/*
> > + * Copyright (c) 2019 Realtek Semiconductor Corp.
> 
> 2019-2020? (also elsewhere)
> 
Yes. It should be changed to "2019-2020".

> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "rtd1319.dtsi"
> > +
> > +/ {
> > +	compatible = "realtek,pymparticle", "realtek,rtd1319";
> > +	model = "Realtek PymParticle EVB";
> > +
> > +	memory@2e000 {
> > +		device_type = "memory";
> > +		reg = <0x2e000 0x3ffd2000>; /* boot ROM to 1 GiB or 2 GiB */
> > +	};
> > +
> > +	chosen {
> > +		stdout-path = "serial0:460800n8";
> > +	};
> > +
> > +	aliases {
> > +		serial0 = &uart0;
> > +		serial1 = &uart1;
> > +		serial2 = &uart2;
> > +	};
> > +};
> > +
> > +/* debug console (J1) */
> > +&uart0 {
> > +	status = "okay";
> > +};
> > +
> > +/* M.2 slot (CON8) */
> 
> Also J14 and CON2 (unless the board is mislabeled?).
> 
> /* J14 and M.2 slots (CON2, CON8) */ ?
> 
Yes. It should be changed to "M.2 slots (CON2, CON8)".

> > +&uart1 {
> > +	status = "disabled";
> > +};
> > +
> > +/* GPIO connector (T1) */
> > +&uart2 {
> > +	status = "disabled";
> > +};
> > diff --git a/arch/arm64/boot/dts/realtek/rtd1319.dtsi
> > b/arch/arm64/boot/dts/realtek/rtd1319.dtsi
> > new file mode 100644
> > index 000000000000..1dcee00009cd
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/realtek/rtd1319.dtsi
> > @@ -0,0 +1,12 @@
> > +// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
> > +/*
> > + * Realtek RTD1319 SoC
> > + *
> > + * Copyright (c) 2019 Realtek Semiconductor Corp.
> > + */
> > +
> > +#include "rtd13xx.dtsi"
> > +
> > +/ {
> > +	compatible = "realtek,rtd1319";
> > +};
> > diff --git a/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
> > b/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
> > new file mode 100644
> > index 000000000000..f6d73f18345d
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/realtek/rtd13xx.dtsi
> > @@ -0,0 +1,213 @@
> > +// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
> > +/*
> > + * Realtek RTD13xx SoC family
> > + *
> > + * Copyright (c) 2019 Realtek Semiconductor Corp.
> > + */
> > +
> > +/memreserve/	0x0000000000000000 0x000000000002e000; /* Boot ROM
> */
> 
> Can you check whether your U-Boot and LK respectively need this memreserve
> entry, here and for previous SoCs? Because for RTD16xx we don't seem to have
> any memreserve entries at all. We do have it in rtd139x.dtsi, rtd129x.dtsi and
> rtd1195.dtsi.
>
I've checked that the boot code doesn't need this memreserve entry.
Therefore, I will remove it.

> Unrelated: Since we're carving out the 2e000 or so from /memory node and
> mapping ranges for /soc, I've been wondering whether we should represent
> the Boot ROM as node somehow. But since it's a ROM with (I assume) binary
> code only, I didn't see any need to have it accessible as mtd-rom device, so it's
> way down my to-do list to research how other mainline platforms might model
> their boot ROMs... (maybe your team has time, or someone reading happens
> to know?)
> 
I'll add it to my to-do list.

> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Docum
> entation/devicetree/bindings/mtd/mtd-physmap.txt
> 
> > +/memreserve/	0x000000000002e000 0x0000000000100000; /* Boot
> loader */
> 
> Is this a) correctly sized (not 0xd2000?) and b) still needed? I thought the
> documented sub-0x100000 memory corruption were fixed in newer BSPs?
> 
We're in the process of re-planning the memory layout,
so that address will move to new address.

> > +/memreserve/	0x000000000f400000 0x0000000000500000; /* Video FW
> */
> > +/memreserve/	0x000000000f900000 0x0000000000500000; /* Audio FW
> */
> > +/memreserve/	0x0000000010000000 0x0000000000014000; /* Audio FW
> RAM */
> [snip]
> 
> Are these needed for the bootloader not to overwrite preloaded firmware, or
> could these become /mem-reserve sub-nodes instead?
> 
Yes. These could become /mem-reserve sub-nodes instead.

> Long-term I'm assuming we would move the responsibility for loading these to
> the new kernel drivers (so that the bootloader doesn't need to take care
> anymore) and ship the needed blobs in linux-firmware.git?
> 
> Or is the video FW needed by the bootloader itself for HDMI/DP output?
>
I agree with you. The video FW can be loaded into memory through this mechanism.
But the audio FW needed by the bootloader itself for HDMI/DP output. 
Therefore, the audio FW can't be loaded into memory through it.

Thank you.

Regards,
James

Re: [PATCH v3 2/2] arm64: dts: realtek: Add RTD1319 SoC and Realtek PymParticle EVB

[Robin Murphy]

On 2020-02-04 2:52 pm, James Tai wrote:
[...]
> +	arm_pmu: pmu {
> +		compatible = "arm,armv8-pmuv3";

The binding updates have landed now, so you can use "arm,cortex-a55-pmu" 
here.

Robin.

> +		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW>;
> +		interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
> +	};

RE: [PATCH v3 2/2] arm64: dts: realtek: Add RTD1319 SoC and Realtek PymParticle EVB

[James Tai [戴志峰]]

Hi Robin,

> On 2020-02-04 2:52 pm, James Tai wrote:
> [...]
> > +	arm_pmu: pmu {
> > +		compatible = "arm,armv8-pmuv3";
> 
> The binding updates have landed now, so you can use "arm,cortex-a55-pmu"
> here.
> 
Okay. I'll modify it in v4.

Thank you.

Regards,
James