| Message ID | 20180712030149.91385-3-chris.brandt@renesas.com |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
| Series | ARM: shmobile: Add support for RZ/A2 | expand |
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
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
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
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
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
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
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)
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(+)