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

Hi Chris,

On Fri, Jul 13, 2018 at 1:50 PM Chris Brandt [off-list ref] wrote:

On Thursday, July 12, 2018, Geert Uytterhoeven wrote:

quoted

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