[PATCH 00/15] Cedrus support for the Allwinner H5 and A64 platforms

[PATCH 00/15] Cedrus support for the Allwinner H5 and A64 platforms

[Paul Kocialkowski]

This series adds support for the Allwinner H5 and A64 platforms to the
cedrus stateless video codec driver, with minor fixes to H3 support.

It requires changes to the SRAM driver bindings and driver, to properly
support the H5 and the A64 C1 SRAM section. Because a H5-specific
system-control node is introduced, the dummy syscon node that was shared
between the H3 and H5 is removed in favor of each platform-specific node.
A few fixes are included to ensure that the EMAC clock configuration
register is still accessible through the sunxi SRAM driver (instead of the
dummy syscon node, that was there for this purpose) on the H3 and H5.

Some minor cosmetic fixes are also included regarding the video-codec
addresses in the device-tree.

Paul Kocialkowski (15):
  ARM: dts: sun8i-a33: Remove heading 0 in video-codec unit address
  ARM: dts: sun8i-h3: Remove heading 0 in video-codec unit address
  ARM: dts: sun8i-h3: Fix the system-control register range
  soc: sunxi: sram: Enable EMAC clock access for H3 variant
  dt-bindings: sram: sunxi: Add bindings for the H5 with SRAM C1
  soc: sunxi: sram: Add support for the H5 SoC system control
  arm64: dts: allwinner: h5: Add system-control node with SRAM C1
  ARM/arm64: sunxi: Move H3/H5 syscon label over to soc-specific nodes
  dt-bindings: sram: sunxi: Add compatible for the A64 SRAM C1
  arm64: dts: allwinner: a64: Add support for the SRAM C1 section
  dt-bindings: media: cedrus: Add compatibles for the A64 and H5
  media: cedrus: Add device-tree compatible and variant for H5 support
  media: cedrus: Add device-tree compatible and variant for A64 support
  arm64: dts: allwinner: h5: Add Video Engine and reserved memory node
  arm64: dts: allwinner: a64: Add Video Engine and reserved memory node

 .../devicetree/bindings/media/cedrus.txt      |  2 +
 .../devicetree/bindings/sram/sunxi-sram.txt   |  5 ++
 arch/arm/boot/dts/sun8i-a33.dtsi              |  2 +-
 arch/arm/boot/dts/sun8i-h3.dtsi               |  6 +--
 arch/arm/boot/dts/sunxi-h3-h5.dtsi            |  6 ---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 39 +++++++++++++++
 arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi  | 47 +++++++++++++++++++
 drivers/soc/sunxi/sunxi_sram.c                | 10 +++-
 drivers/staging/media/sunxi/cedrus/cedrus.c   | 16 +++++++
 9 files changed, 122 insertions(+), 11 deletions(-)

-- 
2.19.1

[PATCH 01/15] ARM: dts: sun8i-a33: Remove heading 0 in video-codec unit address

[Paul Kocialkowski]

This cosmetic change removes the heading 0 in the video-codec unit
address, as it's done for other nodes.

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
 arch/arm/boot/dts/sun8i-a33.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index c1cc8f09dd9a..17f54bd1aee4 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -269,7 +269,7 @@
 			};
 		};
 
-		video-codec@01c0e000 {
+		video-codec@1c0e000 {
 			compatible = "allwinner,sun8i-a33-video-engine";
 			reg = <0x01c0e000 0x1000>;
 			clocks = <&ccu CLK_BUS_VE>, <&ccu CLK_VE>,
-- 
2.19.1

Re: [PATCH 01/15] ARM: dts: sun8i-a33: Remove heading 0 in video-codec unit address

[Chen-Yu Tsai]

On Thu, Nov 15, 2018 at 10:50 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> This cosmetic change removes the heading 0 in the video-codec unit
> address, as it's done for other nodes.
>
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>

Nit: I'd prefer the subject prefix format be "<family>: <soc>: ... ",
or "sun8i: a33:" in this case. This format seems to be used more often
than your alternative format.

I can fix it up when applying.

Acked-by: Chen-Yu Tsai <wens@csie.org>

ChenYu

Re: [PATCH 01/15] ARM: dts: sun8i-a33: Remove heading 0 in video-codec unit address

[Paul Kocialkowski]

Hi,

Le jeudi 15 novembre 2018 à 23:50 +0800, Chen-Yu Tsai a écrit :
> On Thu, Nov 15, 2018 at 10:50 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > This cosmetic change removes the heading 0 in the video-codec unit
> > address, as it's done for other nodes.
> > 
> > Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> 
> Nit: I'd prefer the subject prefix format be "<family>: <soc>: ... ",
> or "sun8i: a33:" in this case. This format seems to be used more often
> than your alternative format.
> 
> I can fix it up when applying.

Understood, I will make sure to follow this convention next time.

Cheers,

Paul

> Acked-by: Chen-Yu Tsai <wens@csie.org>
> 
> ChenYu

[PATCH 02/15] ARM: dts: sun8i-h3: Remove heading 0 in video-codec unit address

[Paul Kocialkowski]

This cosmetic change removes the heading 0 in the video-codec unit
address, as it's done for other nodes.

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 3ecfabb10151..35d025af7deb 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -156,7 +156,7 @@
 			};
 		};
 
-		video-codec@01c0e000 {
+		video-codec@1c0e000 {
 			compatible = "allwinner,sun8i-h3-video-engine";
 			reg = <0x01c0e000 0x1000>;
 			clocks = <&ccu CLK_BUS_VE>, <&ccu CLK_VE>,
-- 
2.19.1

Re: [PATCH 02/15] ARM: dts: sun8i-h3: Remove heading 0 in video-codec unit address

[Chen-Yu Tsai]

On Thu, Nov 15, 2018 at 10:50 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> This cosmetic change removes the heading 0 in the video-codec unit
> address, as it's done for other nodes.
>
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>

Other than the subject format we can fix when applying,

Acked-by: Chen-Yu Tsai <wens@csie.org>

[PATCH 03/15] ARM: dts: sun8i-h3: Fix the system-control register range

[Paul Kocialkowski]

Unlike in previous generations, the system-control register range is not
limited to a size of 0x30 on the H3. In particular, the EMAC clock
configuration register (accessed through syscon) is at offset 0x30 in
that range.

Extend the register size to its full range (0x1000) as a result.

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 35d025af7deb..7157d954fb8c 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -136,7 +136,7 @@
 	soc {
 		system-control@1c00000 {
 			compatible = "allwinner,sun8i-h3-system-control";
-			reg = <0x01c00000 0x30>;
+			reg = <0x01c00000 0x1000>;
 			#address-cells = <1>;
 			#size-cells = <1>;
 			ranges;
-- 
2.19.1

Re: [PATCH 03/15] ARM: dts: sun8i-h3: Fix the system-control register range

[Chen-Yu Tsai]

On Thu, Nov 15, 2018 at 10:50 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Unlike in previous generations, the system-control register range is not
> limited to a size of 0x30 on the H3. In particular, the EMAC clock
> configuration register (accessed through syscon) is at offset 0x30 in
> that range.
>
> Extend the register size to its full range (0x1000) as a result.
>
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>

Other than the subject format,

Acked-by: Chen-Yu Tsai <wens@csie.org>

[PATCH 04/15] soc: sunxi: sram: Enable EMAC clock access for H3 variant

[Paul Kocialkowski]

Just like the A64 and H5, the H3 SoC uses the system control block
to enable the EMAC clock.

Add a variant structure definition for the H3 and use it over the A10
one. This will allow using the H3-specific binding for the syscon node
attached to the EMAC instead of the generic syscon binding.

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
 drivers/soc/sunxi/sunxi_sram.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/sunxi/sunxi_sram.c b/drivers/soc/sunxi/sunxi_sram.c
index b4b0f3480bd3..afa86b5506eb 100644
--- a/drivers/soc/sunxi/sunxi_sram.c
+++ b/drivers/soc/sunxi/sunxi_sram.c
@@ -300,6 +300,10 @@ static const struct sunxi_sramc_variant sun4i_a10_sramc_variant = {
 	/* Nothing special */
 };
 
+static const struct sunxi_sramc_variant sun8i_h3_sramc_variant = {
+	.has_emac_clock = true,
+};
+
 static const struct sunxi_sramc_variant sun50i_a64_sramc_variant = {
 	.has_emac_clock = true,
 };
@@ -379,7 +383,7 @@ static const struct of_device_id sunxi_sram_dt_match[] = {
 	},
 	{
 		.compatible = "allwinner,sun8i-h3-system-control",
-		.data = &sun4i_a10_sramc_variant,
+		.data = &sun8i_h3_sramc_variant,
 	},
 	{
 		.compatible = "allwinner,sun50i-a64-sram-controller",
-- 
2.19.1

Re: [PATCH 04/15] soc: sunxi: sram: Enable EMAC clock access for H3 variant

[Chen-Yu Tsai]

On Thu, Nov 15, 2018 at 10:50 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Just like the A64 and H5, the H3 SoC uses the system control block
> to enable the EMAC clock.
>
> Add a variant structure definition for the H3 and use it over the A10
> one. This will allow using the H3-specific binding for the syscon node
> attached to the EMAC instead of the generic syscon binding.
>
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>

Reviewed-by: Chen-Yu Tsai <wens@csie.org>

[PATCH 05/15] dt-bindings: sram: sunxi: Add bindings for the H5 with SRAM C1

[Paul Kocialkowski]

This introduces new bindings for the H5 SoC in the SRAM controller.
Because the SRAM layout is different from other SoCs, no backward
compatibility is assumed with any of them.

However, the C1 SRAM section alone looks similar to previous SoCs,
so it is compatible with the initial A10 binding.

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
 Documentation/devicetree/bindings/sram/sunxi-sram.txt | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/sram/sunxi-sram.txt b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
index 62dd0748f0ef..c043a6a4011e 100644
--- a/Documentation/devicetree/bindings/sram/sunxi-sram.txt
+++ b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
@@ -18,6 +18,7 @@ Required properties:
     - "allwinner,sun8i-h3-system-control"
     - "allwinner,sun50i-a64-sram-controller" (deprecated)
     - "allwinner,sun50i-a64-system-control"
+    - "allwinner,sun50i-h5-system-control"
     - "allwinner,sun50i-h6-system-control", "allwinner,sun50i-a64-system-control"
 - reg : sram controller register offset + length
 
@@ -55,6 +56,9 @@ The valid sections compatible for H3 are:
 The valid sections compatible for A64 are:
     - allwinner,sun50i-a64-sram-c
 
+The valid sections compatible for H5 are:
+    - allwinner,sun50i-h5-sram-c1, allwinner,sun4i-a10-sram-c1
+
 The valid sections compatible for H6 are:
     - allwinner,sun50i-h6-sram-c, allwinner,sun50i-a64-sram-c
 
-- 
2.19.1

Re: [PATCH 05/15] dt-bindings: sram: sunxi: Add bindings for the H5 with SRAM C1

[Rob Herring]

On Thu, 15 Nov 2018 15:50:03 +0100, Paul Kocialkowski wrote:
> This introduces new bindings for the H5 SoC in the SRAM controller.
> Because the SRAM layout is different from other SoCs, no backward
> compatibility is assumed with any of them.
> 
> However, the C1 SRAM section alone looks similar to previous SoCs,
> so it is compatible with the initial A10 binding.
> 
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> ---
>  Documentation/devicetree/bindings/sram/sunxi-sram.txt | 4 ++++
>  1 file changed, 4 insertions(+)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

[PATCH 06/15] soc: sunxi: sram: Add support for the H5 SoC system control

[Paul Kocialkowski]

This adds the H5 SoC compatible to the list of device-tree matches for
the SRAM driver. Since the variant is the same as the A64 (that precedes
the H5), the same variant description is used.

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
 drivers/soc/sunxi/sunxi_sram.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/soc/sunxi/sunxi_sram.c b/drivers/soc/sunxi/sunxi_sram.c
index afa86b5506eb..9df844dffffe 100644
--- a/drivers/soc/sunxi/sunxi_sram.c
+++ b/drivers/soc/sunxi/sunxi_sram.c
@@ -393,6 +393,10 @@ static const struct of_device_id sunxi_sram_dt_match[] = {
 		.compatible = "allwinner,sun50i-a64-system-control",
 		.data = &sun50i_a64_sramc_variant,
 	},
+	{
+		.compatible = "allwinner,sun50i-h5-system-control",
+		.data = &sun50i_a64_sramc_variant,
+	},
 	{ },
 };
 MODULE_DEVICE_TABLE(of, sunxi_sram_dt_match);
-- 
2.19.1

[PATCH 07/15] arm64: dts: allwinner: h5: Add system-control node with SRAM C1

[Paul Kocialkowski]

Add the H5-specific system control node description to its device-tree
with support for the SRAM C1 section, that will be used by the video
codec node later on.

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
 arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 22 ++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
index b41dc1aab67d..c2d14b22b8c1 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
@@ -94,6 +94,28 @@
 	};
 
 	soc {
+		system-control@1c00000 {
+			compatible = "allwinner,sun50i-h5-system-control";
+			reg = <0x01c00000 0x1000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+
+			sram_c1: sram@1d00000 {
+				compatible = "mmio-sram";
+				reg = <0x01d00000 0x80000>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0 0x01d00000 0x80000>;
+
+				ve_sram: sram-section@0 {
+					compatible = "allwinner,sun50i-h5-sram-c1",
+						     "allwinner,sun4i-a10-sram-c1";
+					reg = <0x000000 0x80000>;
+				};
+			};
+		};
+
 		mali: gpu@1e80000 {
 			compatible = "allwinner,sun50i-h5-mali", "arm,mali-450";
 			reg = <0x01e80000 0x30000>;
-- 
2.19.1

Re: [PATCH 07/15] arm64: dts: allwinner: h5: Add system-control node with SRAM C1

[Chen-Yu Tsai]

On Thu, Nov 15, 2018 at 10:50 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Add the H5-specific system control node description to its device-tree
> with support for the SRAM C1 section, that will be used by the video
> codec node later on.
>
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 22 ++++++++++++++++++++
>  1 file changed, 22 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> index b41dc1aab67d..c2d14b22b8c1 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> @@ -94,6 +94,28 @@
>         };
>
>         soc {
> +               system-control@1c00000 {
> +                       compatible = "allwinner,sun50i-h5-system-control";
> +                       reg = <0x01c00000 0x1000>;
> +                       #address-cells = <1>;
> +                       #size-cells = <1>;
> +                       ranges;
> +
> +                       sram_c1: sram@1d00000 {
> +                               compatible = "mmio-sram";
> +                               reg = <0x01d00000 0x80000>;

I'll try to check this one tomorrow.

I did find something interesting on the H3: there also seems to be SRAM at
0x01dc0000 to 0x01dcfeff , again mapped by the same bits as SRAM C1.

And on the A33, the SRAM C1 range is 0x01d00000 to 0x01d478ff.

This was found by mapping the SRAM to the CPU, then using devmem to poke
around the register range. If there's SRAM, the first read would typically
return random data, and a subsequent write to it would set some value that
would be read back correctly. If there's no SRAM, a read either returns 0x0
or some random data that can't be overwritten.

You might want to check the other SoCs.

ChenYu

> +                               #address-cells = <1>;
> +                               #size-cells = <1>;
> +                               ranges = <0 0x01d00000 0x80000>;
> +
> +                               ve_sram: sram-section@0 {
> +                                       compatible = "allwinner,sun50i-h5-sram-c1",
> +                                                    "allwinner,sun4i-a10-sram-c1";
> +                                       reg = <0x000000 0x80000>;
> +                               };
> +                       };
> +               };
> +
>                 mali: gpu@1e80000 {
>                         compatible = "allwinner,sun50i-h5-mali", "arm,mali-450";
>                         reg = <0x01e80000 0x30000>;
> --
> 2.19.1
>

Re: [PATCH 07/15] arm64: dts: allwinner: h5: Add system-control node with SRAM C1

[Chen-Yu Tsai]

On Fri, Nov 16, 2018 at 12:52 AM Chen-Yu Tsai <wens@csie.org> wrote:
>
> On Thu, Nov 15, 2018 at 10:50 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> >
> > Add the H5-specific system control node description to its device-tree
> > with support for the SRAM C1 section, that will be used by the video
> > codec node later on.
> >
> > Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > ---
> >  arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 22 ++++++++++++++++++++
> >  1 file changed, 22 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> > index b41dc1aab67d..c2d14b22b8c1 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> > @@ -94,6 +94,28 @@
> >         };
> >
> >         soc {
> > +               system-control@1c00000 {
> > +                       compatible = "allwinner,sun50i-h5-system-control";
> > +                       reg = <0x01c00000 0x1000>;
> > +                       #address-cells = <1>;
> > +                       #size-cells = <1>;
> > +                       ranges;
> > +
> > +                       sram_c1: sram@1d00000 {
> > +                               compatible = "mmio-sram";
> > +                               reg = <0x01d00000 0x80000>;
>
> I'll try to check this one tomorrow.
>
> I did find something interesting on the H3: there also seems to be SRAM at
> 0x01dc0000 to 0x01dcfeff , again mapped by the same bits as SRAM C1.
>
> And on the A33, the SRAM C1 range is 0x01d00000 to 0x01d478ff.
>
> This was found by mapping the SRAM to the CPU, then using devmem to poke
> around the register range. If there's SRAM, the first read would typically
> return random data, and a subsequent write to it would set some value that
> would be read back correctly. If there's no SRAM, a read either returns 0x0
> or some random data that can't be overwritten.
>
> You might want to check the other SoCs.

This range seems to contain stuff other than SRAM, possibly fixed lookup
tables. Since this is entirely unknown, lets just stick to the known full
range instead.

ChenYu

> > +                               #address-cells = <1>;
> > +                               #size-cells = <1>;
> > +                               ranges = <0 0x01d00000 0x80000>;
> > +
> > +                               ve_sram: sram-section@0 {
> > +                                       compatible = "allwinner,sun50i-h5-sram-c1",
> > +                                                    "allwinner,sun4i-a10-sram-c1";
> > +                                       reg = <0x000000 0x80000>;
> > +                               };
> > +                       };
> > +               };
> > +
> >                 mali: gpu@1e80000 {
> >                         compatible = "allwinner,sun50i-h5-mali", "arm,mali-450";
> >                         reg = <0x01e80000 0x30000>;
> > --
> > 2.19.1
> >

Re: [PATCH 07/15] arm64: dts: allwinner: h5: Add system-control node with SRAM C1

[Paul Kocialkowski]

[-- Attachment #1: Type: text/plain, Size: 4068 bytes --]

Hi,

On Fri, 2018-11-30 at 11:38 +0800, Chen-Yu Tsai wrote:
> On Fri, Nov 16, 2018 at 12:52 AM Chen-Yu Tsai <wens@csie.org> wrote:
> > On Thu, Nov 15, 2018 at 10:50 PM Paul Kocialkowski
> > <paul.kocialkowski@bootlin.com> wrote:
> > > Add the H5-specific system control node description to its device-tree
> > > with support for the SRAM C1 section, that will be used by the video
> > > codec node later on.
> > > 
> > > Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > > ---
> > >  arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 22 ++++++++++++++++++++
> > >  1 file changed, 22 insertions(+)
> > > 
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> > > index b41dc1aab67d..c2d14b22b8c1 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> > > @@ -94,6 +94,28 @@
> > >         };
> > > 
> > >         soc {
> > > +               system-control@1c00000 {
> > > +                       compatible = "allwinner,sun50i-h5-system-control";
> > > +                       reg = <0x01c00000 0x1000>;
> > > +                       #address-cells = <1>;
> > > +                       #size-cells = <1>;
> > > +                       ranges;
> > > +
> > > +                       sram_c1: sram@1d00000 {
> > > +                               compatible = "mmio-sram";
> > > +                               reg = <0x01d00000 0x80000>;
> > 
> > I'll try to check this one tomorrow.
> > 
> > I did find something interesting on the H3: there also seems to be SRAM at
> > 0x01dc0000 to 0x01dcfeff , again mapped by the same bits as SRAM C1.
> > 
> > And on the A33, the SRAM C1 range is 0x01d00000 to 0x01d478ff.
> > 
> > This was found by mapping the SRAM to the CPU, then using devmem to poke
> > around the register range. If there's SRAM, the first read would typically
> > return random data, and a subsequent write to it would set some value that
> > would be read back correctly. If there's no SRAM, a read either returns 0x0
> > or some random data that can't be overwritten.
> > 
> > You might want to check the other SoCs.
> 
> This range seems to contain stuff other than SRAM, possibly fixed lookup
> tables. Since this is entirely unknown, lets just stick to the known full
> range instead.

Thanks for investigating all this!

I also conducted some tests and found that the H5 has its SRAM C1
(marked as SRAM C in the manual) at 0x18000. However for the A64, SRAM
C1 gets mapped to 0x1D00000. There is also SRAM C at 0x18000 but this
one seems unrelated to the VPU and only used by DE2 (as already
described in the A64 dt).

I share your conclusion that there seems to be more than SRAM in there.
Testing with devmem write/read on the start address was reliable as a
test, but some chunks in the range did not behave like SRAM (not the
same value read).

I agree that we should keep the known full range as there are lots of
unknowns here.

Cheers,

Paul

> ChenYu
> 
> > > +                               #address-cells = <1>;
> > > +                               #size-cells = <1>;
> > > +                               ranges = <0 0x01d00000 0x80000>;
> > > +
> > > +                               ve_sram: sram-section@0 {
> > > +                                       compatible = "allwinner,sun50i-h5-sram-c1",
> > > +                                                    "allwinner,sun4i-a10-sram-c1";
> > > +                                       reg = <0x000000 0x80000>;
> > > +                               };
> > > +                       };
> > > +               };
> > > +
> > >                 mali: gpu@1e80000 {
> > >                         compatible = "allwinner,sun50i-h5-mali", "arm,mali-450";
> > >                         reg = <0x01e80000 0x30000>;
> > > --
> > > 2.19.1
> > > 
-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH 08/15] ARM/arm64: sunxi: Move H3/H5 syscon label over to soc-specific nodes

[Paul Kocialkowski]

Now that we have specific nodes for the H3 and H5 system-controller
that allow proper access to the EMAC clock configuration register,
we no longer need a common dummy syscon node.

Switch the syscon label over to each platform's dtsi file.

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
 arch/arm/boot/dts/sun8i-h3.dtsi              | 2 +-
 arch/arm/boot/dts/sunxi-h3-h5.dtsi           | 6 ------
 arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 2 +-
 3 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 7157d954fb8c..b337a9282783 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -134,7 +134,7 @@
 	};
 
 	soc {
-		system-control@1c00000 {
+		syscon: system-control@1c00000 {
 			compatible = "allwinner,sun8i-h3-system-control";
 			reg = <0x01c00000 0x1000>;
 			#address-cells = <1>;
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 4b1530ebe427..9175ff0fb59a 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -152,12 +152,6 @@
 			};
 		};
 
-		syscon: syscon@1c00000 {
-			compatible = "allwinner,sun8i-h3-system-controller",
-				"syscon";
-			reg = <0x01c00000 0x1000>;
-		};
-
 		dma: dma-controller@1c02000 {
 			compatible = "allwinner,sun8i-h3-dma";
 			reg = <0x01c02000 0x1000>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
index c2d14b22b8c1..4f0e2df875ba 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
@@ -94,7 +94,7 @@
 	};
 
 	soc {
-		system-control@1c00000 {
+		syscon: system-control@1c00000 {
 			compatible = "allwinner,sun50i-h5-system-control";
 			reg = <0x01c00000 0x1000>;
 			#address-cells = <1>;
-- 
2.19.1

Re: [PATCH 08/15] ARM/arm64: sunxi: Move H3/H5 syscon label over to soc-specific nodes

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1760 bytes --]

On Thu, Nov 15, 2018 at 03:50:06PM +0100, Paul Kocialkowski wrote:
> Now that we have specific nodes for the H3 and H5 system-controller
> that allow proper access to the EMAC clock configuration register,
> we no longer need a common dummy syscon node.
> 
> Switch the syscon label over to each platform's dtsi file.
> 
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> ---
>  arch/arm/boot/dts/sun8i-h3.dtsi              | 2 +-
>  arch/arm/boot/dts/sunxi-h3-h5.dtsi           | 6 ------
>  arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 2 +-
>  3 files changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 7157d954fb8c..b337a9282783 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -134,7 +134,7 @@
>  	};
>  
>  	soc {
> -		system-control@1c00000 {
> +		syscon: system-control@1c00000 {
>  			compatible = "allwinner,sun8i-h3-system-control";
>  			reg = <0x01c00000 0x1000>;
>  			#address-cells = <1>;
> diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> index 4b1530ebe427..9175ff0fb59a 100644
> --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> @@ -152,12 +152,6 @@
>  			};
>  		};
>  
> -		syscon: syscon@1c00000 {
> -			compatible = "allwinner,sun8i-h3-system-controller",
> -				"syscon";
> -			reg = <0x01c00000 0x1000>;
> -		};
> -

You're also dropping the syscon compatible there. But I'm not sure how
it could work with the H3 EMAC driver that would overwrite the
compatible already.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 08/15] ARM/arm64: sunxi: Move H3/H5 syscon label over to soc-specific nodes

[Chen-Yu Tsai]

On Fri, Nov 16, 2018 at 5:39 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Thu, Nov 15, 2018 at 03:50:06PM +0100, Paul Kocialkowski wrote:
> > Now that we have specific nodes for the H3 and H5 system-controller
> > that allow proper access to the EMAC clock configuration register,
> > we no longer need a common dummy syscon node.
> >
> > Switch the syscon label over to each platform's dtsi file.
> >
> > Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > ---
> >  arch/arm/boot/dts/sun8i-h3.dtsi              | 2 +-
> >  arch/arm/boot/dts/sunxi-h3-h5.dtsi           | 6 ------
> >  arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 2 +-
> >  3 files changed, 2 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> > index 7157d954fb8c..b337a9282783 100644
> > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > @@ -134,7 +134,7 @@
> >       };
> >
> >       soc {
> > -             system-control@1c00000 {
> > +             syscon: system-control@1c00000 {
> >                       compatible = "allwinner,sun8i-h3-system-control";
> >                       reg = <0x01c00000 0x1000>;
> >                       #address-cells = <1>;
> > diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > index 4b1530ebe427..9175ff0fb59a 100644
> > --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > @@ -152,12 +152,6 @@
> >                       };
> >               };
> >
> > -             syscon: syscon@1c00000 {
> > -                     compatible = "allwinner,sun8i-h3-system-controller",
> > -                             "syscon";
> > -                     reg = <0x01c00000 0x1000>;
> > -             };
> > -
>
> You're also dropping the syscon compatible there. But I'm not sure how
> it could work with the H3 EMAC driver that would overwrite the
> compatible already.

I assume you are referring to the previous patch? The node names are not
the same, hence the previous patch is adding another node for the system
controller, and this patch removes the old one with the "syscon" compatible.

We already patched the EMAC driver to support the new SRAM controller based
regmap, so other than making people unhappy about having to update their
DT, I don't think there would be any problems. This also means H3 in -next
currently has _two_ syscon nodes.

ChenYu

Re: [PATCH 08/15] ARM/arm64: sunxi: Move H3/H5 syscon label over to soc-specific nodes

[Paul Kocialkowski]

Hi,

Le vendredi 16 novembre 2018 à 17:47 +0800, Chen-Yu Tsai a écrit :
> On Fri, Nov 16, 2018 at 5:39 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > On Thu, Nov 15, 2018 at 03:50:06PM +0100, Paul Kocialkowski wrote:
> > > Now that we have specific nodes for the H3 and H5 system-controller
> > > that allow proper access to the EMAC clock configuration register,
> > > we no longer need a common dummy syscon node.
> > > 
> > > Switch the syscon label over to each platform's dtsi file.
> > > 
> > > Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > > ---
> > >  arch/arm/boot/dts/sun8i-h3.dtsi              | 2 +-
> > >  arch/arm/boot/dts/sunxi-h3-h5.dtsi           | 6 ------
> > >  arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 2 +-
> > >  3 files changed, 2 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> > > index 7157d954fb8c..b337a9282783 100644
> > > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > > @@ -134,7 +134,7 @@
> > >       };
> > > 
> > >       soc {
> > > -             system-control@1c00000 {
> > > +             syscon: system-control@1c00000 {
> > >                       compatible = "allwinner,sun8i-h3-system-control";
> > >                       reg = <0x01c00000 0x1000>;
> > >                       #address-cells = <1>;
> > > diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > > index 4b1530ebe427..9175ff0fb59a 100644
> > > --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > > +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > > @@ -152,12 +152,6 @@
> > >                       };
> > >               };
> > > 
> > > -             syscon: syscon@1c00000 {
> > > -                     compatible = "allwinner,sun8i-h3-system-controller",
> > > -                             "syscon";
> > > -                     reg = <0x01c00000 0x1000>;
> > > -             };
> > > -
> > 
> > You're also dropping the syscon compatible there. But I'm not sure how
> > it could work with the H3 EMAC driver that would overwrite the
> > compatible already.
> 
> I assume you are referring to the previous patch? The node names are not
> the same, hence the previous patch is adding another node for the system
> controller, and this patch removes the old one with the "syscon" compatible.
> 
> We already patched the EMAC driver to support the new SRAM controller based
> regmap, so other than making people unhappy about having to update their
> DT, I don't think there would be any problems. This also means H3 in -next
> currently has _two_ syscon nodes.

Yes, the point is indeed to only have a single node per platform (in
the platform dtsi) instead of two (one in the common h3-h5 dtsi and one
in the platform dtsi).

I guess updating the dt is not even a hard requirement after this
series: things will keep working with the dummy syscon node for giving
the EMAC driver access to the syscon registers.

Cheers,

Paul

Re: [PATCH 08/15] ARM/arm64: sunxi: Move H3/H5 syscon label over to soc-specific nodes

[Maxime Ripard]

Hi,

On Fri, Nov 16, 2018 at 05:47:50PM +0800, Chen-Yu Tsai wrote:
> On Fri, Nov 16, 2018 at 5:39 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Thu, Nov 15, 2018 at 03:50:06PM +0100, Paul Kocialkowski wrote:
> > > Now that we have specific nodes for the H3 and H5 system-controller
> > > that allow proper access to the EMAC clock configuration register,
> > > we no longer need a common dummy syscon node.
> > >
> > > Switch the syscon label over to each platform's dtsi file.
> > >
> > > Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > > ---
> > >  arch/arm/boot/dts/sun8i-h3.dtsi              | 2 +-
> > >  arch/arm/boot/dts/sunxi-h3-h5.dtsi           | 6 ------
> > >  arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 2 +-
> > >  3 files changed, 2 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> > > index 7157d954fb8c..b337a9282783 100644
> > > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > > @@ -134,7 +134,7 @@
> > >       };
> > >
> > >       soc {
> > > -             system-control@1c00000 {
> > > +             syscon: system-control@1c00000 {
> > >                       compatible = "allwinner,sun8i-h3-system-control";
> > >                       reg = <0x01c00000 0x1000>;
> > >                       #address-cells = <1>;
> > > diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > > index 4b1530ebe427..9175ff0fb59a 100644
> > > --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > > +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > > @@ -152,12 +152,6 @@
> > >                       };
> > >               };
> > >
> > > -             syscon: syscon@1c00000 {
> > > -                     compatible = "allwinner,sun8i-h3-system-controller",
> > > -                             "syscon";
> > > -                     reg = <0x01c00000 0x1000>;
> > > -             };
> > > -
> >
> > You're also dropping the syscon compatible there. But I'm not sure how
> > it could work with the H3 EMAC driver that would overwrite the
> > compatible already.
> 
> I assume you are referring to the previous patch? The node names are not
> the same, hence the previous patch is adding another node for the system
> controller, and this patch removes the old one with the "syscon" compatible.
> 
> We already patched the EMAC driver to support the new SRAM controller based
> regmap, so other than making people unhappy about having to update their
> DT, I don't think there would be any problems. This also means H3 in -next
> currently has _two_ syscon nodes.

Ah, indeed, I missed that. Pointing that out in the commit log could
be nice though.

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[PATCH 09/15] dt-bindings: sram: sunxi: Add compatible for the A64 SRAM C1

[Paul Kocialkowski]

This introduces a new compatible for the A64 SRAM C1 section, that is
compatible with the SRAM C1 section as found on the A10.

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
 Documentation/devicetree/bindings/sram/sunxi-sram.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/sram/sunxi-sram.txt b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
index c043a6a4011e..cf221d299a8f 100644
--- a/Documentation/devicetree/bindings/sram/sunxi-sram.txt
+++ b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
@@ -55,6 +55,7 @@ The valid sections compatible for H3 are:
 
 The valid sections compatible for A64 are:
     - allwinner,sun50i-a64-sram-c
+    - allwinner,sun50i-a64-sram-c1, allwinner,sun4i-a10-sram-c1
 
 The valid sections compatible for H5 are:
     - allwinner,sun50i-h5-sram-c1, allwinner,sun4i-a10-sram-c1
-- 
2.19.1

Re: [PATCH 09/15] dt-bindings: sram: sunxi: Add compatible for the A64 SRAM C1

[Rob Herring]

On Thu, 15 Nov 2018 15:50:07 +0100, Paul Kocialkowski wrote:
> This introduces a new compatible for the A64 SRAM C1 section, that is
> compatible with the SRAM C1 section as found on the A10.
> 
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> ---
>  Documentation/devicetree/bindings/sram/sunxi-sram.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

[PATCH 10/15] arm64: dts: allwinner: a64: Add support for the SRAM C1 section

[Paul Kocialkowski]

Add the description for the SRAM C1 section to the A64 device-tree.

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index f3a66f888205..88b3e9110833 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -277,6 +277,20 @@
 					reg = <0x0000 0x28000>;
 				};
 			};
+
+			sram_c1: sram@1d00000 {
+				compatible = "mmio-sram";
+				reg = <0x01d00000 0x80000>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0 0x01d00000 0x80000>;
+
+				ve_sram: sram-section@0 {
+					compatible = "allwinner,sun50i-a64-sram-c1",
+						     "allwinner,sun4i-a10-sram-c1";
+					reg = <0x000000 0x80000>;
+				};
+			};
 		};
 
 		dma: dma-controller@1c02000 {
-- 
2.19.1

Re: [PATCH 10/15] arm64: dts: allwinner: a64: Add support for the SRAM C1 section

[Chen-Yu Tsai]

On Thu, Nov 15, 2018 at 10:50 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Add the description for the SRAM C1 section to the A64 device-tree.
>
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index f3a66f888205..88b3e9110833 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -277,6 +277,20 @@
>                                         reg = <0x0000 0x28000>;
>                                 };
>                         };
> +
> +                       sram_c1: sram@1d00000 {
> +                               compatible = "mmio-sram";
> +                               reg = <0x01d00000 0x80000>;

I can confirm that this SRAM region is indeed at this address. However the
size is only 0x40000, not 0x80000. The address ranges should be fixed.

One hiccup is that the VE reset has to be de-asserted and the VE bus clock
has to be ungated for the CPU to access this region when it's mapped to the
CPU.

One other thing I find interesting is that in the previous SoCs, the bits
that control this mapping says 50K, but in reality it is 512K for the older
SoCs, and 256K for this one.

ChenYu

> +                               #address-cells = <1>;
> +                               #size-cells = <1>;
> +                               ranges = <0 0x01d00000 0x80000>;
> +
> +                               ve_sram: sram-section@0 {
> +                                       compatible = "allwinner,sun50i-a64-sram-c1",
> +                                                    "allwinner,sun4i-a10-sram-c1";
> +                                       reg = <0x000000 0x80000>;
> +                               };
> +                       };
>                 };
>
>                 dma: dma-controller@1c02000 {
> --
> 2.19.1
>

[PATCH 11/15] dt-bindings: media: cedrus: Add compatibles for the A64 and H5

[Paul Kocialkowski]

This introduces two new compatibles for the cedrus driver, for the
A64 and H5 platforms.

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
 Documentation/devicetree/bindings/media/cedrus.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/cedrus.txt b/Documentation/devicetree/bindings/media/cedrus.txt
index a089a0c1ff05..b3c0635dcd0e 100644
--- a/Documentation/devicetree/bindings/media/cedrus.txt
+++ b/Documentation/devicetree/bindings/media/cedrus.txt
@@ -11,6 +11,8 @@ Required properties:
 			- "allwinner,sun7i-a20-video-engine"
 			- "allwinner,sun8i-a33-video-engine"
 			- "allwinner,sun8i-h3-video-engine"
+			- "allwinner,sun50i-a64-video-engine"
+			- "allwinner,sun50i-h5-video-engine"
 - reg			: register base and length of VE;
 - clocks		: list of clock specifiers, corresponding to entries in
 			  the clock-names property;
-- 
2.19.1

Re: [PATCH 11/15] dt-bindings: media: cedrus: Add compatibles for the A64 and H5

[Rob Herring]

On Thu, 15 Nov 2018 15:50:09 +0100, Paul Kocialkowski wrote:
> This introduces two new compatibles for the cedrus driver, for the
> A64 and H5 platforms.
> 
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> ---
>  Documentation/devicetree/bindings/media/cedrus.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

[PATCH 12/15] media: cedrus: Add device-tree compatible and variant for H5 support

[Paul Kocialkowski]

Add the necessary compatible for supporting the H5 SoC along with a
description of the capabilities of this variant.

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
 drivers/staging/media/sunxi/cedrus/cedrus.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/media/sunxi/cedrus/cedrus.c
index 82558455384a..f04b9bf23774 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -388,6 +388,10 @@ static const struct cedrus_variant sun8i_h3_cedrus_variant = {
 	.capabilities	= CEDRUS_CAPABILITY_UNTILED,
 };
 
+static const struct cedrus_variant sun50i_h5_cedrus_variant = {
+	.capabilities	= CEDRUS_CAPABILITY_UNTILED,
+};
+
 static const struct of_device_id cedrus_dt_match[] = {
 	{
 		.compatible = "allwinner,sun4i-a10-video-engine",
@@ -409,6 +413,10 @@ static const struct of_device_id cedrus_dt_match[] = {
 		.compatible = "allwinner,sun8i-h3-video-engine",
 		.data = &sun8i_h3_cedrus_variant,
 	},
+	{
+		.compatible = "allwinner,sun50i-h5-video-engine",
+		.data = &sun50i_h5_cedrus_variant,
+	},
 	{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, cedrus_dt_match);
-- 
2.19.1

[PATCH 13/15] media: cedrus: Add device-tree compatible and variant for A64 support

[Paul Kocialkowski]

Add the necessary compatible for supporting the A64 SoC along with a
description of the capabilities of this variant.

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
 drivers/staging/media/sunxi/cedrus/cedrus.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/media/sunxi/cedrus/cedrus.c
index f04b9bf23774..a71d8b659f8d 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -388,6 +388,10 @@ static const struct cedrus_variant sun8i_h3_cedrus_variant = {
 	.capabilities	= CEDRUS_CAPABILITY_UNTILED,
 };
 
+static const struct cedrus_variant sun50i_a64_cedrus_variant = {
+	.capabilities	= CEDRUS_CAPABILITY_UNTILED,
+};
+
 static const struct cedrus_variant sun50i_h5_cedrus_variant = {
 	.capabilities	= CEDRUS_CAPABILITY_UNTILED,
 };
@@ -413,6 +417,10 @@ static const struct of_device_id cedrus_dt_match[] = {
 		.compatible = "allwinner,sun8i-h3-video-engine",
 		.data = &sun8i_h3_cedrus_variant,
 	},
+	{
+		.compatible = "allwinner,sun50i-a64-video-engine",
+		.data = &sun50i_a64_cedrus_variant,
+	},
 	{
 		.compatible = "allwinner,sun50i-h5-video-engine",
 		.data = &sun50i_h5_cedrus_variant,
-- 
2.19.1

[PATCH 14/15] arm64: dts: allwinner: h5: Add Video Engine and reserved memory node

[Paul Kocialkowski]

This adds nodes for the Video Engine and the associated reserved memory
for the H5. Up to 96 MiB of memory are dedicated to the CMA pool.

The pool is located at the end of the first 256 MiB of RAM so that the
VPU can access it. It is unclear whether this is still a hard
requirement for this platform, but it seems safer that way.

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
 arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 25 ++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
index 4f0e2df875ba..6cc9698cab49 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
@@ -93,6 +93,20 @@
 				(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
 	};
 
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		cma_pool: cma@4a000000 {
+			compatible = "shared-dma-pool";
+			size = <0x6000000>;
+			alloc-ranges = <0x4a000000 0x6000000>;
+			reusable;
+			linux,cma-default;
+		};
+	};
+
 	soc {
 		syscon: system-control@1c00000 {
 			compatible = "allwinner,sun50i-h5-system-control";
@@ -116,6 +130,17 @@
 			};
 		};
 
+		video-codec@1c0e000 {
+			compatible = "allwinner,sun50i-h5-video-engine";
+			reg = <0x01c0e000 0x1000>;
+			clocks = <&ccu CLK_BUS_VE>, <&ccu CLK_VE>,
+				 <&ccu CLK_DRAM_VE>;
+			clock-names = "ahb", "mod", "ram";
+			resets = <&ccu RST_BUS_VE>;
+			interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
+			allwinner,sram = <&ve_sram 1>;
+		};
+
 		mali: gpu@1e80000 {
 			compatible = "allwinner,sun50i-h5-mali", "arm,mali-450";
 			reg = <0x01e80000 0x30000>;
-- 
2.19.1

Re: [linux-sunxi] [PATCH 14/15] arm64: dts: allwinner: h5: Add Video Engine and reserved memory node

[Chen-Yu Tsai]

On Thu, Nov 15, 2018 at 10:51 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> This adds nodes for the Video Engine and the associated reserved memory
> for the H5. Up to 96 MiB of memory are dedicated to the CMA pool.
>
> The pool is located at the end of the first 256 MiB of RAM so that the
> VPU can access it. It is unclear whether this is still a hard
> requirement for this platform, but it seems safer that way.

I think we can actually test this. You could move the reserved memory
pool beyond 256 MiB, and have cedrus decode stuff, and try to display
the results. If it's gibberish, or the system crashes, it's likely the
memory access wrapped around at 256 MiB.

What do you think?

ChenYu

Re: [linux-sunxi] [PATCH 14/15] arm64: dts: allwinner: h5: Add Video Engine and reserved memory node

[Paul Kocialkowski]

[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]

Hi,

On Thu, 2018-11-15 at 23:35 +0800, Chen-Yu Tsai wrote:
> On Thu, Nov 15, 2018 at 10:51 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > This adds nodes for the Video Engine and the associated reserved memory
> > for the H5. Up to 96 MiB of memory are dedicated to the CMA pool.
> > 
> > The pool is located at the end of the first 256 MiB of RAM so that the
> > VPU can access it. It is unclear whether this is still a hard
> > requirement for this platform, but it seems safer that way.
> 
> I think we can actually test this. You could move the reserved memory
> pool beyond 256 MiB, and have cedrus decode stuff, and try to display
> the results. If it's gibberish, or the system crashes, it's likely the
> memory access wrapped around at 256 MiB.
> 
> What do you think?

I did the test on various platforms and found that starting with the
A33, the VPU can map any address in RAM! SO we shouldn't need reserved
memory nodes for these devices after all.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH 15/15] arm64: dts: allwinner: a64: Add Video Engine and reserved memory node

[Paul Kocialkowski]

This adds nodes for the Video Engine and the associated reserved memory
for the A64. Up to 96 MiB of memory are dedicated to the CMA pool.

The pool is located at the end of the first 256 MiB of RAM so that the
VPU can access it. It is unclear whether this is still a hard
requirement for this platform, but it seems safer that way.

Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 25 +++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 88b3e9110833..a35a5c9ffbbe 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -185,6 +185,20 @@
 			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
 	};
 
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		cma_pool: cma@4a000000 {
+			compatible = "shared-dma-pool";
+			size = <0x6000000>;
+			alloc-ranges = <0x4a000000 0x6000000>;
+			reusable;
+			linux,cma-default;
+		};
+	};
+
 	soc {
 		compatible = "simple-bus";
 		#address-cells = <1>;
@@ -373,6 +387,17 @@
 			};
 		};
 
+		video-codec@1c0e000 {
+			compatible = "allwinner,sun50i-h5-video-engine";
+			reg = <0x01c0e000 0x1000>;
+			clocks = <&ccu CLK_BUS_VE>, <&ccu CLK_VE>,
+				 <&ccu CLK_DRAM_VE>;
+			clock-names = "ahb", "mod", "ram";
+			resets = <&ccu RST_BUS_VE>;
+			interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
+			allwinner,sram = <&ve_sram 1>;
+		};
+
 		mmc0: mmc@1c0f000 {
 			compatible = "allwinner,sun50i-a64-mmc";
 			reg = <0x01c0f000 0x1000>;
-- 
2.19.1

Re: [PATCH 15/15] arm64: dts: allwinner: a64: Add Video Engine and reserved memory node

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]

On Thu, Nov 15, 2018 at 03:50:13PM +0100, Paul Kocialkowski wrote:
> This adds nodes for the Video Engine and the associated reserved memory
> for the A64. Up to 96 MiB of memory are dedicated to the CMA pool.
> 
> The pool is located at the end of the first 256 MiB of RAM so that the
> VPU can access it. It is unclear whether this is still a hard
> requirement for this platform, but it seems safer that way.
> 
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 25 +++++++++++++++++++
>  1 file changed, 25 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 88b3e9110833..a35a5c9ffbbe 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -185,6 +185,20 @@
>  			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>  	};
>  
> +	reserved-memory {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +		cma_pool: cma@4a000000 {
> +			compatible = "shared-dma-pool";
> +			size = <0x6000000>;
> +			alloc-ranges = <0x4a000000 0x6000000>;

This introduces a DTC warning, since you're using a unit-address, but
don't have a reg register.

I've fixed it in the other DT by renaming that node to
default-pool. You can also drop the label, it's not used anywhere.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]