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

Message ID 20180712030149.91385-3-chris.brandt@renesas.com
State Changes Requested
Headers show
Series
  • ARM: shmobile: Add support for RZ/A2
Related show

Commit Message

Chris Brandt July 12, 2018, 3:01 a.m.
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(+)

Comments

Geert Uytterhoeven July 12, 2018, 12:14 p.m. | #1
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
Chris Brandt July 12, 2018, 1:15 p.m. | #2
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
Geert Uytterhoeven July 12, 2018, 1:35 p.m. | #3
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
Chris Brandt July 12, 2018, 3:48 p.m. | #4
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
Geert Uytterhoeven July 13, 2018, 12:13 p.m. | #5
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
Chris Brandt July 13, 2018, 4:33 p.m. | #6
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

Patch

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)