[PATCH 0/2] ARM: shmobile: Add support for RZ/A2

[PATCH 0/2] ARM: shmobile: Add support for RZ/A2

[Chris Brandt]

Introduce RZ/A2 (R7S9210) as an SoC that can be selected.


Chris Brandt (2):
  ARM: shmobile: Add basic RZ/A2 SoC support
  dt-bindings: arm: Document RZ/A2 SoC DT bindings

 Documentation/devicetree/bindings/arm/shmobile.txt |  2 ++
 arch/arm/mach-shmobile/Kconfig                     |  6 +++++
 arch/arm/mach-shmobile/Makefile                    |  1 +
 arch/arm/mach-shmobile/setup-r7s9210.c             | 27 ++++++++++++++++++++++
 4 files changed, 36 insertions(+)
 create mode 100644 arch/arm/mach-shmobile/setup-r7s9210.c

-- 
2.16.1

[PATCH 1/2] ARM: shmobile: Add basic RZ/A2 SoC support

[Chris Brandt]

Add the RZ/A2 SoC to the Renesas SoC collection.

Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
---
 arch/arm/mach-shmobile/Kconfig         |  6 ++++++
 arch/arm/mach-shmobile/Makefile        |  1 +
 arch/arm/mach-shmobile/setup-r7s9210.c | 27 +++++++++++++++++++++++++++
 3 files changed, 34 insertions(+)
 create mode 100644 arch/arm/mach-shmobile/setup-r7s9210.c

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 0b67254eabb2..9338eb0d574f 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -54,6 +54,12 @@ config ARCH_R7S72100
 	select SYS_SUPPORTS_SH_MTU2
 	select RENESAS_OSTM
 
+config ARCH_R7S9210
+	bool "RZ/A2 (R7S9210)"
+	select PM
+	select PM_GENERIC_DOMAINS
+	select RENESAS_OSTM
+
 config ARCH_R8A73A4
 	bool "R-Mobile APE6 (R8A73A40)"
 	select ARCH_RMOBILE
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index b33dc59d8698..5591646cb9bb 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_ARCH_R8A7778)	+= setup-r8a7778.o
 obj-$(CONFIG_ARCH_R8A7779)	+= setup-r8a7779.o
 obj-$(CONFIG_ARCH_EMEV2)	+= setup-emev2.o
 obj-$(CONFIG_ARCH_R7S72100)	+= setup-r7s72100.o
+obj-$(CONFIG_ARCH_R7S9210)	+= setup-r7s9210.o
 
 # CPU reset vector handling objects
 cpu-y				:= platsmp.o headsmp.o
diff --git a/arch/arm/mach-shmobile/setup-r7s9210.c b/arch/arm/mach-shmobile/setup-r7s9210.c
new file mode 100644
index 000000000000..573fb9955e7e
--- /dev/null
+++ b/arch/arm/mach-shmobile/setup-r7s9210.c
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * r7s9210 processor support
+ *
+ * Copyright (C) 2018  Renesas Electronics Corporation
+ * Copyright (C) 2018  Chris Brandt
+ *
+ */
+
+#include <linux/kernel.h>
+
+#include <asm/mach/arch.h>
+
+#include "common.h"
+
+static const char *const r7s9210_boards_compat_dt[] __initconst = {
+	"renesas,r7s9210",
+	NULL,
+};
+
+DT_MACHINE_START(R7S72100_DT, "Generic R7S9210 (Flattened Device Tree)")
+	.l2c_aux_val    = 0,
+	.l2c_aux_mask   = ~0,
+	.init_early	= shmobile_init_delay,
+	.init_late	= shmobile_init_late,
+	.dt_compat	= r7s9210_boards_compat_dt,
+MACHINE_END
-- 
2.16.1

Re: [PATCH 1/2] ARM: shmobile: Add basic RZ/A2 SoC support

[Geert Uytterhoeven]

Hi Chris,

On Thu, Jul 12, 2018 at 5:02 AM Chris Brandt <chris.brandt@renesas.com> wrote:
> Add the RZ/A2 SoC to the Renesas SoC collection.
>
> Signed-off-by: Chris Brandt <chris.brandt@renesas.com>

> --- /dev/null
> +++ b/arch/arm/mach-shmobile/setup-r7s9210.c
> @@ -0,0 +1,27 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * r7s9210 processor support
> + *
> + * Copyright (C) 2018  Renesas Electronics Corporation
> + * Copyright (C) 2018  Chris Brandt
> + *
> + */
> +
> +#include <linux/kernel.h>
> +
> +#include <asm/mach/arch.h>
> +
> +#include "common.h"
> +
> +static const char *const r7s9210_boards_compat_dt[] __initconst = {
> +       "renesas,r7s9210",
> +       NULL,
> +};
> +
> +DT_MACHINE_START(R7S72100_DT, "Generic R7S9210 (Flattened Device Tree)")
> +       .l2c_aux_val    = 0,
> +       .l2c_aux_mask   = ~0,
> +       .init_early     = shmobile_init_delay,
> +       .init_late      = shmobile_init_late,
> +       .dt_compat      = r7s9210_boards_compat_dt,
> +MACHINE_END

I'm wondering if you could do without any board code, i.e. without
setup-r7s9210.c?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: [PATCH 1/2] ARM: shmobile: Add basic RZ/A2 SoC support

[Chris Brandt]

Hi Geert,

On Thursday, July 12, 2018, Geert Uytterhoeven wrote:
> I'm wondering if you could do without any board code, i.e. without
> setup-r7s9210.c?

I think I see them being removed for R-Car.
But....I'm not sure how that actually works.

I'll have a look.

As you can see, there's really nothing in the RZ/A1 setup file either.


Chris

Re: [PATCH 1/2] ARM: shmobile: Add basic RZ/A2 SoC support

[Geert Uytterhoeven]

Hi Chris,

On Thu, Jul 12, 2018 at 5:40 PM Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On Thursday, July 12, 2018, Geert Uytterhoeven wrote:
> > I'm wondering if you could do without any board code, i.e. without
> > setup-r7s9210.c?
>
> I think I see them being removed for R-Car.
> But....I'm not sure how that actually works.
>
> I'll have a look.
>
> As you can see, there's really nothing in the RZ/A1 setup file either.

Yeah, that's why I asked: setup-r7s72100.c is the smallest setup file.

It uses shmobile_init_delay() to preset loops-per-jiffy, to avoid
calibrating the
delay loop, and shmobile_init_late() to make s2ram do more than s2idle.
As RZ/A doesn't have SMP, and thus there's no use for disabling secondary
CPU cores, the impact of the latter is small (read: I don't know what's the real
impact of calling cpu_idle_poll_ctrl()).

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: [PATCH 1/2] ARM: shmobile: Add basic RZ/A2 SoC support

[Chris Brandt]

Hi Geert,

On Thursday, July 12, 2018, Geert Uytterhoeven wrote:
> Yeah, that's why I asked: setup-r7s72100.c is the smallest setup file.
> 
> It uses shmobile_init_delay() to preset loops-per-jiffy, to avoid
> calibrating the
> delay loop, and shmobile_init_late() to make s2ram do more than s2idle.
> As RZ/A doesn't have SMP, and thus there's no use for disabling secondary
> CPU cores, the impact of the latter is small (read: I don't know what's
> the real
> impact of calling cpu_idle_poll_ctrl()).

It's been quite a while, but I remember when porting RZ/A1 code that 
without those two functions, things didn't work right. Of course that was 
many releases ago.


However, one thing that I know I need is

+	.l2c_aux_val    = 0,
+	.l2c_aux_mask   = ~0,

Without that, I don't get my L2C driver loaded.

Hence:
a96bb197693e ("ARM: 8660/1: shmobile: r7s72100: Enable L2 cache")

So at least for now, I would say I still need the setup file.


Chris

Re: [PATCH 1/2] ARM: shmobile: Add basic RZ/A2 SoC support

[Geert Uytterhoeven]

Hi Chris,

On Thu, Jul 12, 2018 at 7:34 PM Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On Thursday, July 12, 2018, Geert Uytterhoeven wrote:
> > Yeah, that's why I asked: setup-r7s72100.c is the smallest setup file.
> >
> > It uses shmobile_init_delay() to preset loops-per-jiffy, to avoid
> > calibrating the
> > delay loop, and shmobile_init_late() to make s2ram do more than s2idle.
> > As RZ/A doesn't have SMP, and thus there's no use for disabling secondary
> > CPU cores, the impact of the latter is small (read: I don't know what's
> > the real
> > impact of calling cpu_idle_poll_ctrl()).
>
> It's been quite a while, but I remember when porting RZ/A1 code that
> without those two functions, things didn't work right. Of course that was
> many releases ago.

Right, you may not have had an early timer running yet, causing the loop
calibration to hang. May have been fixed by ostm support.

> However, one thing that I know I need is
>
> +       .l2c_aux_val    = 0,
> +       .l2c_aux_mask   = ~0,
>
> Without that, I don't get my L2C driver loaded.
>
> Hence:
> a96bb197693e ("ARM: 8660/1: shmobile: r7s72100: Enable L2 cache")
>
> So at least for now, I would say I still need the setup file.

I forgot about the L2C. Yeah, it's a pity we still need board code to
enable the PL310 cache with default settings.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 2/2] dt-bindings: arm: Document RZ/A2 SoC DT bindings

[Chris Brandt]

Add device tree bindings documentation for Renesas RZ/A2 (r7s9210) SoC.

Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
---
 Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
index 89b4a389fbc7..7288c2081cd5 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -7,6 +7,8 @@ SoCs:
     compatible = "renesas,emev2"
   - RZ/A1H (R7S72100)
     compatible = "renesas,r7s72100"
+  - RZ/A2 (R7S9210)
+    compatible = "renesas,r7s9210"
   - SH-Mobile AG5 (R8A73A00/SH73A0)
     compatible = "renesas,sh73a0"
   - R-Mobile APE6 (R8A73A40)
-- 
2.16.1

Re: [PATCH 2/2] dt-bindings: arm: Document RZ/A2 SoC DT bindings

[Geert Uytterhoeven]

Hi Chris,

On Thu, Jul 12, 2018 at 5:02 AM Chris Brandt <chris.brandt@renesas.com> wrote:
> Add device tree bindings documentation for Renesas RZ/A2 (r7s9210) SoC.
>
> Signed-off-by: Chris Brandt <chris.brandt@renesas.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

> --- a/Documentation/devicetree/bindings/arm/shmobile.txt
> +++ b/Documentation/devicetree/bindings/arm/shmobile.txt
> @@ -7,6 +7,8 @@ SoCs:
>      compatible = "renesas,emev2"
>    - RZ/A1H (R7S72100)
>      compatible = "renesas,r7s72100"
> +  - RZ/A2 (R7S9210)
> +    compatible = "renesas,r7s9210"

There seems to be a difference between the r7s92104x and the r7s92105x
parts (with "x" just denoting a different packaging)?
Do we need one more digit?

>    - SH-Mobile AG5 (R8A73A00/SH73A0)
>      compatible = "renesas,sh73a0"
>    - R-Mobile APE6 (R8A73A40)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: [PATCH 2/2] dt-bindings: arm: Document RZ/A2 SoC DT bindings

[Chris Brandt]

Hi Geert,

On Thursday, July 12, 2018, Geert Uytterhoeven wrote:
> > +  - RZ/A2 (R7S9210)
> > +    compatible = "renesas,r7s9210"
> 
> There seems to be a difference between the r7s92104x and the r7s92105x
> parts (with "x" just denoting a different packaging)?
> Do we need one more digit?

From an "architecture" standpoint all the hardware in the RZ/A2 
(R7S9210xx series) will be the same. So from a device driver standpoint, 
CONFIG_ARCH_R7S9210 would cover everything.

The rest of the numbers are just for package and number of HW channels.
 
Of course, sometimes when they make smaller packages, they also make 
smaller silicon to make it cheaper. But in that case, they just simply 
remove HW or the number of channels for the hardware. (you don't need as 
many peripherals if you don't have as many pins anymore). But, they never 
change the functionality of the hardware.

Take for example RZ/A1
 RZ/A1H  R7S72100x
 RZ/A1M  R7S72101x
 RZ/A1L  R7S72102x
 RZ/A1LU R7S72103x

These parts all had the same hardware, but different package options And
the "L" parts were cheaper because they reduced the die size by 
removing HW.
But the same drivers worked on all of them because the IP was all 
exactly the same.
So I would have suggested CONFIG_ARCH_R7S7210 for the RZ/A1 series. 
(well, until I found about the R-Car part that took the same part number in 
this series)


As for the r7s92104x vs r7s92105x, that is for a HW feature that will 
have nothing to do with Linux, so we can ignore that number.

But even if we did make a tiny cut-down version of the device, say a 
R7S92106x, all HW IP would be the same, just less of it. So in my mind, the
architecture (from a CONFIG_ARCH perspective) is still the same. Maybe 
just a different .dtsi.

What do you think?

Chris

Re: [PATCH 2/2] dt-bindings: arm: Document RZ/A2 SoC DT bindings

[Geert Uytterhoeven]

Hi Chris,

On Thu, Jul 12, 2018 at 3:15 PM Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On Thursday, July 12, 2018, Geert Uytterhoeven wrote:
> > > +  - RZ/A2 (R7S9210)
> > > +    compatible = "renesas,r7s9210"
> >
> > There seems to be a difference between the r7s92104x and the r7s92105x
> > parts (with "x" just denoting a different packaging)?
> > Do we need one more digit?
>
> From an "architecture" standpoint all the hardware in the RZ/A2
> (R7S9210xx series) will be the same. So from a device driver standpoint,
> CONFIG_ARCH_R7S9210 would cover everything.
>
> The rest of the numbers are just for package and number of HW channels.
>
> Of course, sometimes when they make smaller packages, they also make
> smaller silicon to make it cheaper. But in that case, they just simply
> remove HW or the number of channels for the hardware. (you don't need as
> many peripherals if you don't have as many pins anymore). But, they never
> change the functionality of the hardware.
>
> Take for example RZ/A1
>  RZ/A1H  R7S72100x
>  RZ/A1M  R7S72101x
>  RZ/A1L  R7S72102x
>  RZ/A1LU R7S72103x
>
> These parts all had the same hardware, but different package options And
> the "L" parts were cheaper because they reduced the die size by
> removing HW.
> But the same drivers worked on all of them because the IP was all
> exactly the same.
> So I would have suggested CONFIG_ARCH_R7S7210 for the RZ/A1 series.
> (well, until I found about the R-Car part that took the same part number in
> this series)

That's the issue with using wildcards, or truncating part numbers: you
don't know what unrelated future parts may match...

> As for the r7s92104x vs r7s92105x, that is for a HW feature that will
> have nothing to do with Linux, so we can ignore that number.

OK.

> But even if we did make a tiny cut-down version of the device, say a
> R7S92106x, all HW IP would be the same, just less of it. So in my mind, the
> architecture (from a CONFIG_ARCH perspective) is still the same. Maybe
> just a different .dtsi.
>
> What do you think?

As the IP cores are the same in all variants, using
"renesas,r7s9210-<something>" should be fine for matching drivers to IP
cores. Same for CONFIG_ARCH_R7S9210.

However, as the actual dies differ between H, M, and L versions, there may
be integration issues to be worked around. So I think it would be wise to
use one more digit in the compatible value at the main SoC level, i.e.
"renesas,r7s92104".
Unless there's a hardware register to detect the version at runtime.
But it seems RZ/A2 doesn't have a Product Register
(PRR), which most other SH/R-Mobile and R-Car SoCs do have?

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: [PATCH 2/2] dt-bindings: arm: Document RZ/A2 SoC DT bindings

[Chris Brandt]

Hi Geert,

On Thursday, July 12, 2018, Geert Uytterhoeven wrote:
> As the IP cores are the same in all variants, using
> "renesas,r7s9210-<something>" should be fine for matching drivers to IP
> cores. Same for CONFIG_ARCH_R7S9210.
> 
> However, as the actual dies differ between H, M, and L versions, there may
> be integration issues to be worked around. So I think it would be wise to
> use one more digit in the compatible value at the main SoC level, i.e.
> "renesas,r7s92104".
> Unless there's a hardware register to detect the version at runtime.
> But it seems RZ/A2 doesn't have a Product Register
> (PRR), which most other SH/R-Mobile and R-Car SoCs do have?

There is supposed to be one. I specifically asked for it (and remember 
reviewing it).
But, now I'm not seeing it in the latest version of the manual.

Let me find out where it is.

Chris

RE: [PATCH 2/2] dt-bindings: arm: Document RZ/A2 SoC DT bindings

[Chris Brandt]

Hi Geert,

On Thursday, July 12, 2018, Geert Uytterhoeven wrote:
> As the IP cores are the same in all variants, using
> "renesas,r7s9210-<something>" should be fine for matching drivers to IP
> cores. Same for CONFIG_ARCH_R7S9210.
> 
> However, as the actual dies differ between H, M, and L versions, there may
> be integration issues to be worked around. So I think it would be wise to
> use one more digit in the compatible value at the main SoC level, i.e.
> "renesas,r7s92104".
> Unless there's a hardware register to detect the version at runtime.
> But it seems RZ/A2 doesn't have a Product Register
> (PRR), which most other SH/R-Mobile and R-Car SoCs do have?


There is an ID register in RZ/A2 that will have a different number for 
each silicon.
See the first entry in Table 5.6 (BSID register).

Technically, it's not  "PRR" like it's SH/R-Car devices. It's actually 
the boundary scan ID number. All RZ/A1 devices have this too. But with 
RZ/A1, you could only get to this register through JTAG (not by the CPU). 
So for RZ/A2+, they will mirror that register to CPU space.

So with that said, are we good with CONFIG_ARCH_R7S9210?

Chris

Re: [PATCH 2/2] dt-bindings: arm: Document RZ/A2 SoC DT bindings

[Geert Uytterhoeven]

Hi Chris,

On Fri, Jul 13, 2018 at 1:50 PM Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On Thursday, July 12, 2018, Geert Uytterhoeven wrote:
> > As the IP cores are the same in all variants, using
> > "renesas,r7s9210-<something>" should be fine for matching drivers to IP
> > cores. Same for CONFIG_ARCH_R7S9210.
> >
> > However, as the actual dies differ between H, M, and L versions, there may
> > be integration issues to be worked around. So I think it would be wise to
> > use one more digit in the compatible value at the main SoC level, i.e.
> > "renesas,r7s92104".
> > Unless there's a hardware register to detect the version at runtime.
> > But it seems RZ/A2 doesn't have a Product Register
> > (PRR), which most other SH/R-Mobile and R-Car SoCs do have?
>
> There is an ID register in RZ/A2 that will have a different number for
> each silicon.
> See the first entry in Table 5.6 (BSID register).
>
> Technically, it's not  "PRR" like it's SH/R-Car devices. It's actually
> the boundary scan ID number. All RZ/A1 devices have this too. But with
> RZ/A1, you could only get to this register through JTAG (not by the CPU).
> So for RZ/A2+, they will mirror that register to CPU space.

Cool. So if you add a "renesas,bsid" device node to the dtsi, and add
support for using that to drivers/soc/renesas/renesas-soc.c, then we can
use soc_device_match() to filter on SoC revision, if ever needed.

> So with that said, are we good with CONFIG_ARCH_R7S9210?

Yes, the Kconfig symbol is fine for sure.

Thansk!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: [PATCH 2/2] dt-bindings: arm: Document RZ/A2 SoC DT bindings

[Chris Brandt]

Hi Geert,

On Friday, July 13, 2018, Geert Uytterhoeven wrote:
> > There is an ID register in RZ/A2 that will have a different number for
> > each silicon.
> > See the first entry in Table 5.6 (BSID register).
> >
> > Technically, it's not  "PRR" like it's SH/R-Car devices. It's actually
> > the boundary scan ID number. All RZ/A1 devices have this too. But with
> > RZ/A1, you could only get to this register through JTAG (not by the CPU).
> > So for RZ/A2+, they will mirror that register to CPU space.
> 
> Cool. So if you add a "renesas,bsid" device node to the dtsi, and add
> support for using that to drivers/soc/renesas/renesas-soc.c, then we can
> use soc_device_match() to filter on SoC revision, if ever needed.

Oh, I see.


> > So with that said, are we good with CONFIG_ARCH_R7S9210?
> 
> Yes, the Kconfig symbol is fine for sure.
> 
> Thansk!

Cool...except now I have more code to go off and write ;)


Chris