| Message ID | 1464054880-25843-2-git-send-email-horms+renesas@verge.net.au (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Simon, On 24.05.2016 03:54, Simon Horman wrote: > Basic support for the Gen 3 R-Car M3-W SoC. > > Based on work for the r8a7795 and r8a7796 SoCs by > Takeshi Kihara, Dirk Behme and Geert Uytterhoeven. > > Signed-off-by: Simon Horman <horms+renesas@verge.net.au> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> > --- > v3 > * As suggested by Geert Uytterhoeven: > - Drop 0x from unit address of gic > * As suggested by Khiem Nguyen: > - Use psci-0.2 > * Added Reviewed-by tag from Geert Uytterhoeven > > v2 > * As suggested by Geert Uytterhoeven: > - Move L2_CA57 node under cpus node and include reg property > - Omit status = "disabled" from scif_clk node > --- > Documentation/devicetree/bindings/arm/shmobile.txt | 4 + > arch/arm64/Kconfig.platforms | 6 ++ > arch/arm64/boot/dts/renesas/r8a7796.dtsi | 120 +++++++++++++++++++++ > 3 files changed, 130 insertions(+) > create mode 100644 arch/arm64/boot/dts/renesas/r8a7796.dtsi > > diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt > index 9cf67e48f222..d5ed554830d7 100644 > --- a/Documentation/devicetree/bindings/arm/shmobile.txt > +++ b/Documentation/devicetree/bindings/arm/shmobile.txt > @@ -29,6 +29,8 @@ SoCs: > compatible = "renesas,r8a7794" > - R-Car H3 (R8A77950) > compatible = "renesas,r8a7795" > + - R-Car M3-W (R8A77960) > + compatible = "renesas,r8a7796" > > > Boards: > @@ -61,5 +63,7 @@ Boards: > compatible = "renesas,porter", "renesas,r8a7791" > - Salvator-X (RTP0RC7795SIPB0010S) > compatible = "renesas,salvator-x", "renesas,r8a7795"; > + - Salvator-X > + compatible = "renesas,salvator-x", "renesas,r8a7796"; > - SILK (RTP0RC7794LCB00011S) > compatible = "renesas,silk", "renesas,r8a7794" > diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms > index efa77c146415..16d8d26839ea 100644 > --- a/arch/arm64/Kconfig.platforms > +++ b/arch/arm64/Kconfig.platforms > @@ -114,6 +114,12 @@ config ARCH_R8A7795 > help > This enables support for the Renesas R-Car H3 SoC. > > +config ARCH_R8A7796 > + bool "Renesas R-Car M3-W SoC Platform" > + depends on ARCH_RENESAS > + help > + This enables support for the Renesas R-Car M3-W SoC. > + > config ARCH_STRATIX10 > bool "Altera's Stratix 10 SoCFPGA Family" > help > diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi > new file mode 100644 > index 000000000000..178debf68318 > --- /dev/null > +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi > @@ -0,0 +1,120 @@ > +/* > + * Device Tree Source for the r8a7796 SoC > + * > + * Copyright (C) 2016 Renesas Electronics Corp. > + * > + * This file is licensed under the terms of the GNU General Public License > + * version 2. This program is licensed "as is" without any warranty of any > + * kind, whether express or implied. > + */ > + > +#include <dt-bindings/clock/r8a7796-cpg-mssr.h> > +#include <dt-bindings/interrupt-controller/arm-gic.h> With Renesas R-Car3 we will get a whole family of SoCs. I.e. different computing power (e.g. different number of Cores) with more or less similar peripherals. I would think that we want to reflect this in the device tree, too. Therefore I think what we want is a hierarchy of device trees. Similar what's done with other SoC families (compare e.g. i.MX6). E.g. we want an initial rcar3.dtsi, which contains all common parts of all R-Car3 SoCs. E.g. one CA57 core, the SCIF where its common etc. Then you will have the r8a779x.dtsi which includes the rcar3.dtsi and extends it for SoC specific parts. Which then will be included by the board device trees, as already done, now. Or in other words: As soon as you have similar parts in the r8a779x.dtsi's, it's time to think about moving the parts one hierarchy level up into the rcar3.dtsi. Else you will end up in a maintenance hell once you have to change/fix anything. Best regards Dirk
Hi Dirk, On Tue, May 24, 2016 at 07:30:17AM +0200, Dirk Behme wrote: > Hi Simon, [...] > With Renesas R-Car3 we will get a whole family of SoCs. I.e. different > computing power (e.g. different number of Cores) with more or less similar > peripherals. > > I would think that we want to reflect this in the device tree, too. > Therefore I think what we want is a hierarchy of device trees. Similar > what's done with other SoC families (compare e.g. i.MX6). > > E.g. we want an initial rcar3.dtsi, which contains all common parts of all > R-Car3 SoCs. E.g. one CA57 core, the SCIF where its common etc. > > Then you will have the r8a779x.dtsi which includes the rcar3.dtsi and > extends it for SoC specific parts. Which then will be included by the board > device trees, as already done, now. > > Or in other words: As soon as you have similar parts in the r8a779x.dtsi's, > it's time to think about moving the parts one hierarchy level up into the > rcar3.dtsi. Else you will end up in a maintenance hell once you have to > change/fix anything. Thanks for raising this issue. I agree entirely that we should work towards a situation where maintenance is as easy as it can be. However, due to the per-SoC binding scheme that we are using for IP related to Renesas SoCs I suspect that very few DT nodes can be shared between SoCs verbatim. Probably some sort of scheme can be cooked up using preprocessor macros. And probably there are other ways to resolve this problem. But I would prefer if we worked towards resolving this maintenance problem in parallel with rather than as a dependency of merging r8a7796 support into mainline.
Hi Simon, On 25.05.2016 02:48, Simon Horman wrote: > Hi Dirk, > > On Tue, May 24, 2016 at 07:30:17AM +0200, Dirk Behme wrote: >> Hi Simon, > > [...] > >> With Renesas R-Car3 we will get a whole family of SoCs. I.e. different >> computing power (e.g. different number of Cores) with more or less similar >> peripherals. >> >> I would think that we want to reflect this in the device tree, too. >> Therefore I think what we want is a hierarchy of device trees. Similar >> what's done with other SoC families (compare e.g. i.MX6). >> >> E.g. we want an initial rcar3.dtsi, which contains all common parts of all >> R-Car3 SoCs. E.g. one CA57 core, the SCIF where its common etc. >> >> Then you will have the r8a779x.dtsi which includes the rcar3.dtsi and >> extends it for SoC specific parts. Which then will be included by the board >> device trees, as already done, now. >> >> Or in other words: As soon as you have similar parts in the r8a779x.dtsi's, >> it's time to think about moving the parts one hierarchy level up into the >> rcar3.dtsi. Else you will end up in a maintenance hell once you have to >> change/fix anything. > > Thanks for raising this issue. > > I agree entirely that we should work towards a situation where maintenance > is as easy as it can be. However, due to the per-SoC binding scheme that > we are using for IP related to Renesas SoCs I suspect that very few DT nodes > can be shared between SoCs verbatim. Could you kindly share an example for this? Looking into the H3 and the M3-W manual, it looks to me that ~90% (?) of the peripherals are the same. > Probably some sort of scheme can be cooked up using preprocessor macros. > And probably there are other ways to resolve this problem. But I would > prefer if we worked towards resolving this maintenance problem in parallel > with rather than as a dependency of merging r8a7796 support into mainline. I'd propose to do it correct from the beginning. Doing it later would either be more work or forgotten, and never be done, then. For a starting point, I'd propose to put the r8a7795.dtsi and r8a7796.dtsi into a graphical diff tool and move all common parts to a rcar3.dtsi (I'd be happy to discuss the name, though) Best regards Dirk
On 24.05.2016 03:54, Simon Horman wrote: > Basic support for the Gen 3 R-Car M3-W SoC. > > Based on work for the r8a7795 and r8a7796 SoCs by > Takeshi Kihara, Dirk Behme and Geert Uytterhoeven. > > Signed-off-by: Simon Horman <horms+renesas@verge.net.au> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> > --- > v3 > * As suggested by Geert Uytterhoeven: > - Drop 0x from unit address of gic > * As suggested by Khiem Nguyen: > - Use psci-0.2 > * Added Reviewed-by tag from Geert Uytterhoeven > > v2 > * As suggested by Geert Uytterhoeven: > - Move L2_CA57 node under cpus node and include reg property > - Omit status = "disabled" from scif_clk node > --- > Documentation/devicetree/bindings/arm/shmobile.txt | 4 + > arch/arm64/Kconfig.platforms | 6 ++ > arch/arm64/boot/dts/renesas/r8a7796.dtsi | 120 +++++++++++++++++++++ > 3 files changed, 130 insertions(+) > create mode 100644 arch/arm64/boot/dts/renesas/r8a7796.dtsi > > diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt > index 9cf67e48f222..d5ed554830d7 100644 > --- a/Documentation/devicetree/bindings/arm/shmobile.txt > +++ b/Documentation/devicetree/bindings/arm/shmobile.txt > @@ -29,6 +29,8 @@ SoCs: > compatible = "renesas,r8a7794" > - R-Car H3 (R8A77950) > compatible = "renesas,r8a7795" > + - R-Car M3-W (R8A77960) > + compatible = "renesas,r8a7796" > > > Boards: > @@ -61,5 +63,7 @@ Boards: > compatible = "renesas,porter", "renesas,r8a7791" > - Salvator-X (RTP0RC7795SIPB0010S) > compatible = "renesas,salvator-x", "renesas,r8a7795"; > + - Salvator-X > + compatible = "renesas,salvator-x", "renesas,r8a7796"; > - SILK (RTP0RC7794LCB00011S) > compatible = "renesas,silk", "renesas,r8a7794" > diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms > index efa77c146415..16d8d26839ea 100644 > --- a/arch/arm64/Kconfig.platforms > +++ b/arch/arm64/Kconfig.platforms > @@ -114,6 +114,12 @@ config ARCH_R8A7795 > help > This enables support for the Renesas R-Car H3 SoC. > > +config ARCH_R8A7796 > + bool "Renesas R-Car M3-W SoC Platform" > + depends on ARCH_RENESAS > + help > + This enables support for the Renesas R-Car M3-W SoC. > + > config ARCH_STRATIX10 > bool "Altera's Stratix 10 SoCFPGA Family" > help > diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi > new file mode 100644 > index 000000000000..178debf68318 > --- /dev/null > +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi > @@ -0,0 +1,120 @@ > +/* > + * Device Tree Source for the r8a7796 SoC > + * > + * Copyright (C) 2016 Renesas Electronics Corp. > + * > + * This file is licensed under the terms of the GNU General Public License > + * version 2. This program is licensed "as is" without any warranty of any > + * kind, whether express or implied. > + */ > + > +#include <dt-bindings/clock/r8a7796-cpg-mssr.h> > +#include <dt-bindings/interrupt-controller/arm-gic.h> > + > +/ { > + compatible = "renesas,r8a7796"; > + #address-cells = <2>; > + #size-cells = <2>; > + > + psci { > + compatible = "arm,psci-0.2"; > + method = "smc"; > + }; > + > + cpus { > + #address-cells = <1>; > + #size-cells = <0>; > + > + /* 1 core only at this point */ > + a57_0: cpu@0 { > + compatible = "arm,cortex-a57", "arm,armv8"; > + reg = <0x0>; > + device_type = "cpu"; > + next-level-cache = <&L2_CA57>; > + enable-method = "psci"; > + }; > + > + L2_CA57: cache-controller@0 { > + compatible = "cache"; > + reg = <0>; > + cache-unified; > + cache-level = <2>; > + }; > + }; It looks to me that in the r8a7795.dtsi the cache-controller node is outside the cpus node? I'd think that we should keep is consistent. Best regards Dirk
Hi Dirk, On Wed, May 25, 2016 at 07:10:26AM +0200, Dirk Behme wrote: > Hi Simon, > > On 25.05.2016 02:48, Simon Horman wrote: > >Hi Dirk, > > > >On Tue, May 24, 2016 at 07:30:17AM +0200, Dirk Behme wrote: > >>Hi Simon, > > > >[...] > > > >>With Renesas R-Car3 we will get a whole family of SoCs. I.e. different > >>computing power (e.g. different number of Cores) with more or less similar > >>peripherals. > >> > >>I would think that we want to reflect this in the device tree, too. > >>Therefore I think what we want is a hierarchy of device trees. Similar > >>what's done with other SoC families (compare e.g. i.MX6). > >> > >>E.g. we want an initial rcar3.dtsi, which contains all common parts of all > >>R-Car3 SoCs. E.g. one CA57 core, the SCIF where its common etc. > >> > >>Then you will have the r8a779x.dtsi which includes the rcar3.dtsi and > >>extends it for SoC specific parts. Which then will be included by the board > >>device trees, as already done, now. > >> > >>Or in other words: As soon as you have similar parts in the r8a779x.dtsi's, > >>it's time to think about moving the parts one hierarchy level up into the > >>rcar3.dtsi. Else you will end up in a maintenance hell once you have to > >>change/fix anything. > > > >Thanks for raising this issue. > > > >I agree entirely that we should work towards a situation where maintenance > >is as easy as it can be. However, due to the per-SoC binding scheme that > >we are using for IP related to Renesas SoCs I suspect that very few DT nodes > >can be shared between SoCs verbatim. > > > Could you kindly share an example for this? Looking into the H3 and the M3-W > manual, it looks to me that ~90% (?) of the peripherals are the same. The background is that this is a conversation that has been going around for years. The basic thinking is that at this point we have documentation that indicates that many hardware blocks on the H3 and M3-W are the same. But we do not have insight into the internal versioning of the IP blocks nor if they are really the same. And furthermore even if they are currently the same we don't really know if that will continue to be the case. Probably it is. Maybe it isn't. The response has been to take a conservative approach to DT bindings to give us the flexibility to update the driver implementation to reflect any differences that subsequently surface. And by providing per-SoC bindings these driver changes can be activated on a per-SoC basis without updating DTB files (which may be burned into ROMs). There is of course scope to take a different approach. But getting consensus on this is frankly difficult. And at the very least I would expect it to take time. > >Probably some sort of scheme can be cooked up using preprocessor macros. > >And probably there are other ways to resolve this problem. But I would > >prefer if we worked towards resolving this maintenance problem in parallel > >with rather than as a dependency of merging r8a7796 support into mainline. > > > I'd propose to do it correct from the beginning. > > Doing it later would either be more work or forgotten, and never be done, > then. I'm sorry but I don't agree. I think that having r8a7796 support in mainline is a higher priority than sorting this out. > For a starting point, I'd propose to put the r8a7795.dtsi and r8a7796.dtsi > into a graphical diff tool and move all common parts to a rcar3.dtsi (I'd be > happy to discuss the name, though) I'm not opposed to that. But being consistent with my statement above I would prefer it to be done as follow-up work. My suspicion is that right now much of the proposed r8a7796.dtsi can be moved into a hypothetical rcar3.dtsi. But that this is because the proposed r8a7796.dtsi is very small. I would not expect nearly such a large proportion of r8a7795.dtsi to be able to be moved into rcar3.dtsi because it enables more hardware blocks and they typically have (or should have in keeping with the prevailing policy as described above) per-SoC bindings. I believe that there is also a another issue which is that we wish to control enabling features on different SoCs once they are known to work. Of course things slip through the cracks. But blindly assuming all IP blocks enabled for one SoC work on another, even if based on the documentation, seems to be asking for trouble to me. For one thing it implies that the level of firmware support is the same. As for a name, I suggest rcar-gen3.dtsi.
On Wed, May 25, 2016 at 09:38:23AM +0200, Dirk Behme wrote: > On 24.05.2016 03:54, Simon Horman wrote: > >Basic support for the Gen 3 R-Car M3-W SoC. > > > >Based on work for the r8a7795 and r8a7796 SoCs by > >Takeshi Kihara, Dirk Behme and Geert Uytterhoeven. > > > >Signed-off-by: Simon Horman <horms+renesas@verge.net.au> > >Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> > >--- > >v3 > >* As suggested by Geert Uytterhoeven: > > - Drop 0x from unit address of gic > >* As suggested by Khiem Nguyen: > > - Use psci-0.2 > >* Added Reviewed-by tag from Geert Uytterhoeven > > > >v2 > >* As suggested by Geert Uytterhoeven: > > - Move L2_CA57 node under cpus node and include reg property > > - Omit status = "disabled" from scif_clk node > >--- > > Documentation/devicetree/bindings/arm/shmobile.txt | 4 + > > arch/arm64/Kconfig.platforms | 6 ++ > > arch/arm64/boot/dts/renesas/r8a7796.dtsi | 120 +++++++++++++++++++++ > > 3 files changed, 130 insertions(+) > > create mode 100644 arch/arm64/boot/dts/renesas/r8a7796.dtsi > > > >diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt > >index 9cf67e48f222..d5ed554830d7 100644 > >--- a/Documentation/devicetree/bindings/arm/shmobile.txt > >+++ b/Documentation/devicetree/bindings/arm/shmobile.txt > >@@ -29,6 +29,8 @@ SoCs: > > compatible = "renesas,r8a7794" > > - R-Car H3 (R8A77950) > > compatible = "renesas,r8a7795" > >+ - R-Car M3-W (R8A77960) > >+ compatible = "renesas,r8a7796" > > > > > > Boards: > >@@ -61,5 +63,7 @@ Boards: > > compatible = "renesas,porter", "renesas,r8a7791" > > - Salvator-X (RTP0RC7795SIPB0010S) > > compatible = "renesas,salvator-x", "renesas,r8a7795"; > >+ - Salvator-X > >+ compatible = "renesas,salvator-x", "renesas,r8a7796"; > > - SILK (RTP0RC7794LCB00011S) > > compatible = "renesas,silk", "renesas,r8a7794" > >diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms > >index efa77c146415..16d8d26839ea 100644 > >--- a/arch/arm64/Kconfig.platforms > >+++ b/arch/arm64/Kconfig.platforms > >@@ -114,6 +114,12 @@ config ARCH_R8A7795 > > help > > This enables support for the Renesas R-Car H3 SoC. > > > >+config ARCH_R8A7796 > >+ bool "Renesas R-Car M3-W SoC Platform" > >+ depends on ARCH_RENESAS > >+ help > >+ This enables support for the Renesas R-Car M3-W SoC. > >+ > > config ARCH_STRATIX10 > > bool "Altera's Stratix 10 SoCFPGA Family" > > help > >diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi > >new file mode 100644 > >index 000000000000..178debf68318 > >--- /dev/null > >+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi > >@@ -0,0 +1,120 @@ > >+/* > >+ * Device Tree Source for the r8a7796 SoC > >+ * > >+ * Copyright (C) 2016 Renesas Electronics Corp. > >+ * > >+ * This file is licensed under the terms of the GNU General Public License > >+ * version 2. This program is licensed "as is" without any warranty of any > >+ * kind, whether express or implied. > >+ */ > >+ > >+#include <dt-bindings/clock/r8a7796-cpg-mssr.h> > >+#include <dt-bindings/interrupt-controller/arm-gic.h> > >+ > >+/ { > >+ compatible = "renesas,r8a7796"; > >+ #address-cells = <2>; > >+ #size-cells = <2>; > >+ > >+ psci { > >+ compatible = "arm,psci-0.2"; > >+ method = "smc"; > >+ }; > >+ > >+ cpus { > >+ #address-cells = <1>; > >+ #size-cells = <0>; > >+ > >+ /* 1 core only at this point */ > >+ a57_0: cpu@0 { > >+ compatible = "arm,cortex-a57", "arm,armv8"; > >+ reg = <0x0>; > >+ device_type = "cpu"; > >+ next-level-cache = <&L2_CA57>; > >+ enable-method = "psci"; > >+ }; > >+ > >+ L2_CA57: cache-controller@0 { > >+ compatible = "cache"; > >+ reg = <0>; > >+ cache-unified; > >+ cache-level = <2>; > >+ }; > >+ }; > > > It looks to me that in the r8a7795.dtsi the cache-controller node is outside > the cpus node? I'd think that we should keep is consistent. As of c10cdf93a119 ("arm64: dts: r8a7795: Fix W=1 dtc warnings"), which was recently added to the devel branch of the renesas tree, the cache-controller is inside the cpu node on the r8a7795.dtsi. This patch aims to be consistent with that change.
Hi Simon, On 26.05.2016 04:28, Simon Horman wrote: > Hi Dirk, > > On Wed, May 25, 2016 at 07:10:26AM +0200, Dirk Behme wrote: >> Hi Simon, >> >> On 25.05.2016 02:48, Simon Horman wrote: >>> Hi Dirk, >>> >>> On Tue, May 24, 2016 at 07:30:17AM +0200, Dirk Behme wrote: >>>> Hi Simon, >>> >>> [...] >>> >>>> With Renesas R-Car3 we will get a whole family of SoCs. I.e. different >>>> computing power (e.g. different number of Cores) with more or less similar >>>> peripherals. >>>> >>>> I would think that we want to reflect this in the device tree, too. >>>> Therefore I think what we want is a hierarchy of device trees. Similar >>>> what's done with other SoC families (compare e.g. i.MX6). >>>> >>>> E.g. we want an initial rcar3.dtsi, which contains all common parts of all >>>> R-Car3 SoCs. E.g. one CA57 core, the SCIF where its common etc. >>>> >>>> Then you will have the r8a779x.dtsi which includes the rcar3.dtsi and >>>> extends it for SoC specific parts. Which then will be included by the board >>>> device trees, as already done, now. >>>> >>>> Or in other words: As soon as you have similar parts in the r8a779x.dtsi's, >>>> it's time to think about moving the parts one hierarchy level up into the >>>> rcar3.dtsi. Else you will end up in a maintenance hell once you have to >>>> change/fix anything. >>> >>> Thanks for raising this issue. >>> >>> I agree entirely that we should work towards a situation where maintenance >>> is as easy as it can be. However, due to the per-SoC binding scheme that >>> we are using for IP related to Renesas SoCs I suspect that very few DT nodes >>> can be shared between SoCs verbatim. >> >> >> Could you kindly share an example for this? Looking into the H3 and the M3-W >> manual, it looks to me that ~90% (?) of the peripherals are the same. > > The background is that this is a conversation that has been going around > for years. The basic thinking is that at this point we have documentation > that indicates that many hardware blocks on the H3 and M3-W are the same. > But we do not have insight into the internal versioning of the IP blocks > nor if they are really the same. And furthermore even if they are currently > the same we don't really know if that will continue to be the case. > > Probably it is. Maybe it isn't. The response has been to take a > conservative approach to DT bindings to give us the flexibility to update > the driver implementation to reflect any differences that subsequently > surface. And by providing per-SoC bindings these driver changes can be > activated on a per-SoC basis without updating DTB files (which may be > burned into ROMs). Sorry, but I don't think that these are good arguments for this kind of discussion ;) The discussion has to be based on facts. And not on "maybe" or "probably". The fact is that the documentation tells us that the IPs are the same. And the documentation tells us where this isn't the case. This is what we can reflect in the code and the device trees. Or the other way around: I don't ask to not have any SoC specific device trees (r8a7795.dtsi, r8a7796.dtsi etc). So we *always* have the option to move anything to them, once there might be any difference found or documented. But maintaining x (x > 5?) quite similar device trees just because there *might* be the possibility that one or two device *might* be different doesn't sound like a good argument to me. Or again, an other way: If I understood correctly, you are working already since some time on R-Car, e.g. R-Car Gen2. How many examples do you have from the Gen2 family where the IP blocks are different that they need to be distinguished in the device tree? >>> Probably some sort of scheme can be cooked up using preprocessor macros. >>> And probably there are other ways to resolve this problem. But I would >>> prefer if we worked towards resolving this maintenance problem in parallel >>> with rather than as a dependency of merging r8a7796 support into mainline. >> >> >> I'd propose to do it correct from the beginning. >> >> Doing it later would either be more work or forgotten, and never be done, >> then. > > I'm sorry but I don't agree. I think that having r8a7796 support > in mainline is a higher priority than sorting this out. Looking at the example I gave in http://article.gmane.org/gmane.linux.kernel.renesas-soc/4013 which took me < 1h to create, I'm not sure what would block us from mainlining the r8a7796 *including* this. >> For a starting point, I'd propose to put the r8a7795.dtsi and r8a7796.dtsi >> into a graphical diff tool and move all common parts to a rcar3.dtsi (I'd be >> happy to discuss the name, though) > > I'm not opposed to that. But being consistent with my statement above > I would prefer it to be done as follow-up work. > > My suspicion is that right now much of the proposed r8a7796.dtsi can be > moved into a hypothetical rcar3.dtsi. But that this is because the proposed > r8a7796.dtsi is very small. I would not expect nearly such a large > proportion of r8a7795.dtsi to be able to be moved into rcar3.dtsi because > it enables more hardware blocks and they typically have (or should have in > keeping with the prevailing policy as described above) per-SoC bindings. What doesn't prevent us to use a rcar3.dtsi like given in http://article.gmane.org/gmane.linux.kernel.renesas-soc/4013 Having a rcar3.dtsi gives us *both* options. It doesn't force us to use the one or the other. I.e. we have for each IP block the *option* to declare it as common (put it onto rcar3.dtsi) *or* SoC specific (put it into r8a779x.dtsi). Without having a common rcar3.dtsi we don't have this option at all. So I think the conclusion is: Let's have all options (by adding a rcar3.dtsi) and then decide for each IP block individually where to place it best. Or move it later from the common dtsi to the individual dtsi once there is an issue found (what I really doubt that it will happen that often, but this is an other topic ;) ) > I believe that there is also a another issue which is that we wish > to control enabling features on different SoCs once they are known to work. > Of course things slip through the cracks. But blindly assuming all > IP blocks enabled for one SoC work on another, even if based on the > documentation, seems to be asking for trouble to me. For one thing > it implies that the level of firmware support is the same. > > As for a name, I suggest rcar-gen3.dtsi. Sounds good to me :) Best regards Dirk
On Thu, May 26, 2016 at 09:14:16AM +0200, Dirk Behme wrote: > Hi Simon, > > On 26.05.2016 04:28, Simon Horman wrote: > >Hi Dirk, > > > >On Wed, May 25, 2016 at 07:10:26AM +0200, Dirk Behme wrote: > >>Hi Simon, > >> > >>On 25.05.2016 02:48, Simon Horman wrote: > >>>Hi Dirk, > >>> > >>>On Tue, May 24, 2016 at 07:30:17AM +0200, Dirk Behme wrote: > >>>>Hi Simon, > >>> > >>>[...] > >>> > >>>>With Renesas R-Car3 we will get a whole family of SoCs. I.e. different > >>>>computing power (e.g. different number of Cores) with more or less similar > >>>>peripherals. > >>>> > >>>>I would think that we want to reflect this in the device tree, too. > >>>>Therefore I think what we want is a hierarchy of device trees. Similar > >>>>what's done with other SoC families (compare e.g. i.MX6). > >>>> > >>>>E.g. we want an initial rcar3.dtsi, which contains all common parts of all > >>>>R-Car3 SoCs. E.g. one CA57 core, the SCIF where its common etc. > >>>> > >>>>Then you will have the r8a779x.dtsi which includes the rcar3.dtsi and > >>>>extends it for SoC specific parts. Which then will be included by the board > >>>>device trees, as already done, now. > >>>> > >>>>Or in other words: As soon as you have similar parts in the r8a779x.dtsi's, > >>>>it's time to think about moving the parts one hierarchy level up into the > >>>>rcar3.dtsi. Else you will end up in a maintenance hell once you have to > >>>>change/fix anything. > >>> > >>>Thanks for raising this issue. > >>> > >>>I agree entirely that we should work towards a situation where maintenance > >>>is as easy as it can be. However, due to the per-SoC binding scheme that > >>>we are using for IP related to Renesas SoCs I suspect that very few DT nodes > >>>can be shared between SoCs verbatim. > >> > >> > >>Could you kindly share an example for this? Looking into the H3 and the M3-W > >>manual, it looks to me that ~90% (?) of the peripherals are the same. > > > >The background is that this is a conversation that has been going around > >for years. The basic thinking is that at this point we have documentation > >that indicates that many hardware blocks on the H3 and M3-W are the same. > >But we do not have insight into the internal versioning of the IP blocks > >nor if they are really the same. And furthermore even if they are currently > >the same we don't really know if that will continue to be the case. > > > >Probably it is. Maybe it isn't. The response has been to take a > >conservative approach to DT bindings to give us the flexibility to update > >the driver implementation to reflect any differences that subsequently > >surface. And by providing per-SoC bindings these driver changes can be > >activated on a per-SoC basis without updating DTB files (which may be > >burned into ROMs). > > > Sorry, but I don't think that these are good arguments for this kind of > discussion ;) From my point of view this is the central point. It is my believe that we simply do not have enough information to conclude that the IP blocks will be the same in perpetuity. > The discussion has to be based on facts. And not on "maybe" or "probably". > The fact is that the documentation tells us that the IPs are the same. And > the documentation tells us where this isn't the case. This is what we can > reflect in the code and the device trees. > > Or the other way around: I don't ask to not have any SoC specific device > trees (r8a7795.dtsi, r8a7796.dtsi etc). So we *always* have the option to > move anything to them, once there might be any difference found or > documented. But maintaining x (x > 5?) quite similar device trees just > because there *might* be the possibility that one or two device *might* be > different doesn't sound like a good argument to me. > > Or again, an other way: If I understood correctly, you are working already > since some time on R-Car, e.g. R-Car Gen2. How many examples do you have > from the Gen2 family where the IP blocks are different that they need to be > distinguished in the device tree? I think the question is different. The question is, if a difference comes up, how do we handle it? So far we have a solution. Not an ideal one, but a solution none the less. I do agree entirely that replicated DTs leads to significant maintenance overhead. But lets not throw the baby out with the bath water. > >>>Probably some sort of scheme can be cooked up using preprocessor macros. > >>>And probably there are other ways to resolve this problem. But I would > >>>prefer if we worked towards resolving this maintenance problem in parallel > >>>with rather than as a dependency of merging r8a7796 support into mainline. > >> > >> > >>I'd propose to do it correct from the beginning. > >> > >>Doing it later would either be more work or forgotten, and never be done, > >>then. > > > >I'm sorry but I don't agree. I think that having r8a7796 support > >in mainline is a higher priority than sorting this out. > > > Looking at the example I gave in > > http://article.gmane.org/gmane.linux.kernel.renesas-soc/4013 > > which took me < 1h to create, I'm not sure what would block us from > mainlining the r8a7796 *including* this. Point taken. Lets discuss the change on its merits. > >>For a starting point, I'd propose to put the r8a7795.dtsi and r8a7796.dtsi > >>into a graphical diff tool and move all common parts to a rcar3.dtsi (I'd be > >>happy to discuss the name, though) > > > >I'm not opposed to that. But being consistent with my statement above > >I would prefer it to be done as follow-up work. > > > >My suspicion is that right now much of the proposed r8a7796.dtsi can be > >moved into a hypothetical rcar3.dtsi. But that this is because the proposed > >r8a7796.dtsi is very small. I would not expect nearly such a large > >proportion of r8a7795.dtsi to be able to be moved into rcar3.dtsi because > >it enables more hardware blocks and they typically have (or should have in > >keeping with the prevailing policy as described above) per-SoC bindings. > > > What doesn't prevent us to use a rcar3.dtsi like given in > > http://article.gmane.org/gmane.linux.kernel.renesas-soc/4013 > > > Having a rcar3.dtsi gives us *both* options. It doesn't force us to use the > one or the other. I.e. we have for each IP block the *option* to declare it > as common (put it onto rcar3.dtsi) *or* SoC specific (put it into > r8a779x.dtsi). > > Without having a common rcar3.dtsi we don't have this option at all. > > So I think the conclusion is: Let's have all options (by adding a > rcar3.dtsi) and then decide for each IP block individually where to place it > best. Or move it later from the common dtsi to the individual dtsi once > there is an issue found (what I really doubt that it will happen that often, > but this is an other topic ;) ) I think that most of the nodes you have moved into the common dtsi file make sense. But there are some I am less sure about: * cpus Probably there are some central aspects of cpus that are shared between the r8a7795 and r8a7796. And I think that your patch captures that. But I also think that there will be non-shared aspects and perhaps the complexity of splitting the cpus node between per-SoC and common dtsi files isn't worth it. I don't feel strongly about this at this point. I am also particularly sensitive about enabling CPU features across multiple SoCs. But I think that the scheme you propose allows for per-SoC control of features in per-SoC dtsi files. So I think I am ok about that at this point. Lastly, shouldn't the cache-controller go inside the cpu node in the common dtsi file to reflect the change recently made upstream to r8a7795.dtsi and the structure of r8a7796.dtsi in the current patchset (v3). * cpg, scif2 This is the compatibility string issue. Could we at least agree to defer this part of the discussion and thus omit these nodes from the common dtsi file at this time? I understand that you are concerned that if we don't handle this now it will be forgotten. FWIW I strongly doubt this particular problem will be forgotten. > >I believe that there is also a another issue which is that we wish > >to control enabling features on different SoCs once they are known to work. > >Of course things slip through the cracks. But blindly assuming all > >IP blocks enabled for one SoC work on another, even if based on the > >documentation, seems to be asking for trouble to me. For one thing > >it implies that the level of firmware support is the same. > > > >As for a name, I suggest rcar-gen3.dtsi. > > > Sounds good to me :) > > > Best regards > > Dirk > > > >
On Fri, May 27, 2016 at 2:42 AM, Simon Horman <horms@verge.net.au> wrote: > Probably there are some central aspects of cpus that are shared > between the r8a7795 and r8a7796. And I think that your patch captures > that. But I also think that there will be non-shared aspects and > perhaps the complexity of splitting the cpus node between per-SoC > and common dtsi files isn't worth it. R8a7795 and r8a7796 have different numbers of CPU cores, and different maximum frequencies, thus needing different operating-point properties. 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
Hi Simon, On 27.05.2016 02:42, Simon Horman wrote: > On Thu, May 26, 2016 at 09:14:16AM +0200, Dirk Behme wrote: >> Hi Simon, >> >> On 26.05.2016 04:28, Simon Horman wrote: >>> Hi Dirk, >>> >>> On Wed, May 25, 2016 at 07:10:26AM +0200, Dirk Behme wrote: >>>> Hi Simon, >>>> >>>> On 25.05.2016 02:48, Simon Horman wrote: >>>>> Hi Dirk, >>>>> >>>>> On Tue, May 24, 2016 at 07:30:17AM +0200, Dirk Behme wrote: >>>>>> Hi Simon, >>>>> >>>>> [...] >>>>> >>>>>> With Renesas R-Car3 we will get a whole family of SoCs. I.e. different >>>>>> computing power (e.g. different number of Cores) with more or less similar >>>>>> peripherals. >>>>>> >>>>>> I would think that we want to reflect this in the device tree, too. >>>>>> Therefore I think what we want is a hierarchy of device trees. Similar >>>>>> what's done with other SoC families (compare e.g. i.MX6). >>>>>> >>>>>> E.g. we want an initial rcar3.dtsi, which contains all common parts of all >>>>>> R-Car3 SoCs. E.g. one CA57 core, the SCIF where its common etc. >>>>>> >>>>>> Then you will have the r8a779x.dtsi which includes the rcar3.dtsi and >>>>>> extends it for SoC specific parts. Which then will be included by the board >>>>>> device trees, as already done, now. >>>>>> >>>>>> Or in other words: As soon as you have similar parts in the r8a779x.dtsi's, >>>>>> it's time to think about moving the parts one hierarchy level up into the >>>>>> rcar3.dtsi. Else you will end up in a maintenance hell once you have to >>>>>> change/fix anything. >>>>> >>>>> Thanks for raising this issue. >>>>> >>>>> I agree entirely that we should work towards a situation where maintenance >>>>> is as easy as it can be. However, due to the per-SoC binding scheme that >>>>> we are using for IP related to Renesas SoCs I suspect that very few DT nodes >>>>> can be shared between SoCs verbatim. >>>> >>>> >>>> Could you kindly share an example for this? Looking into the H3 and the M3-W >>>> manual, it looks to me that ~90% (?) of the peripherals are the same. >>> >>> The background is that this is a conversation that has been going around >>> for years. The basic thinking is that at this point we have documentation >>> that indicates that many hardware blocks on the H3 and M3-W are the same. >>> But we do not have insight into the internal versioning of the IP blocks >>> nor if they are really the same. And furthermore even if they are currently >>> the same we don't really know if that will continue to be the case. >>> >>> Probably it is. Maybe it isn't. The response has been to take a >>> conservative approach to DT bindings to give us the flexibility to update >>> the driver implementation to reflect any differences that subsequently >>> surface. And by providing per-SoC bindings these driver changes can be >>> activated on a per-SoC basis without updating DTB files (which may be >>> burned into ROMs). >> >> >> Sorry, but I don't think that these are good arguments for this kind of >> discussion ;) > >>From my point of view this is the central point. It is my believe that we > simply do not have enough information to conclude that the IP blocks will > be the same in perpetuity. > >> The discussion has to be based on facts. And not on "maybe" or "probably". >> The fact is that the documentation tells us that the IPs are the same. And >> the documentation tells us where this isn't the case. This is what we can >> reflect in the code and the device trees. >> >> Or the other way around: I don't ask to not have any SoC specific device >> trees (r8a7795.dtsi, r8a7796.dtsi etc). So we *always* have the option to >> move anything to them, once there might be any difference found or >> documented. But maintaining x (x > 5?) quite similar device trees just >> because there *might* be the possibility that one or two device *might* be >> different doesn't sound like a good argument to me. >> >> Or again, an other way: If I understood correctly, you are working already >> since some time on R-Car, e.g. R-Car Gen2. How many examples do you have >> from the Gen2 family where the IP blocks are different that they need to be >> distinguished in the device tree? > > I think the question is different. The question is, if a difference comes > up, how do we handle it? > > So far we have a solution. Not an ideal one, but a solution none the less. > I do agree entirely that replicated DTs leads to significant maintenance > overhead. But lets not throw the baby out with the bath water. Well, we could continue this kind of discussion infinite ;) But I agree to your below point "Lets discuss the change on its merits" and therefore stop here and continue with the technical aspects below .... >>>>> Probably some sort of scheme can be cooked up using preprocessor macros. >>>>> And probably there are other ways to resolve this problem. But I would >>>>> prefer if we worked towards resolving this maintenance problem in parallel >>>>> with rather than as a dependency of merging r8a7796 support into mainline. >>>> >>>> >>>> I'd propose to do it correct from the beginning. >>>> >>>> Doing it later would either be more work or forgotten, and never be done, >>>> then. >>> >>> I'm sorry but I don't agree. I think that having r8a7796 support >>> in mainline is a higher priority than sorting this out. >> >> >> Looking at the example I gave in >> >> http://article.gmane.org/gmane.linux.kernel.renesas-soc/4013 >> >> which took me < 1h to create, I'm not sure what would block us from >> mainlining the r8a7796 *including* this. > > Point taken. Lets discuss the change on its merits. I totally agree, thanks! Let's continue below ... >>>> For a starting point, I'd propose to put the r8a7795.dtsi and r8a7796.dtsi >>>> into a graphical diff tool and move all common parts to a rcar3.dtsi (I'd be >>>> happy to discuss the name, though) >>> >>> I'm not opposed to that. But being consistent with my statement above >>> I would prefer it to be done as follow-up work. >>> >>> My suspicion is that right now much of the proposed r8a7796.dtsi can be >>> moved into a hypothetical rcar3.dtsi. But that this is because the proposed >>> r8a7796.dtsi is very small. I would not expect nearly such a large >>> proportion of r8a7795.dtsi to be able to be moved into rcar3.dtsi because >>> it enables more hardware blocks and they typically have (or should have in >>> keeping with the prevailing policy as described above) per-SoC bindings. >> >> >> What doesn't prevent us to use a rcar3.dtsi like given in >> >> http://article.gmane.org/gmane.linux.kernel.renesas-soc/4013 >> >> >> Having a rcar3.dtsi gives us *both* options. It doesn't force us to use the >> one or the other. I.e. we have for each IP block the *option* to declare it >> as common (put it onto rcar3.dtsi) *or* SoC specific (put it into >> r8a779x.dtsi). >> >> Without having a common rcar3.dtsi we don't have this option at all. >> >> So I think the conclusion is: Let's have all options (by adding a >> rcar3.dtsi) and then decide for each IP block individually where to place it >> best. Or move it later from the common dtsi to the individual dtsi once >> there is an issue found (what I really doubt that it will happen that often, >> but this is an other topic ;) ) > > I think that most of the nodes you have moved into the common dtsi file > make sense. But there are some I am less sure about: > > * cpus > > Probably there are some central aspects of cpus that are shared > between the r8a7795 and r8a7796. And I think that your patch captures > that. But I also think that there will be non-shared aspects and > perhaps the complexity of splitting the cpus node between per-SoC > and common dtsi files isn't worth it. > > I don't feel strongly about this at this point. > > I am also particularly sensitive about enabling CPU features across > multiple SoCs. But I think that the scheme you propose allows for > per-SoC control of features in per-SoC dtsi files. So I think > I am ok about that at this point. > > Lastly, shouldn't the cache-controller go inside the cpu node > in the common dtsi file to reflect the change recently made > upstream to r8a7795.dtsi and the structure of r8a7796.dtsi in > the current patchset (v3). We already talked about that in an other thread, and I think I missed that change you mentioned. So I'm fine with your proposal. I just saw that it's different between r8a7795 and r8a7796 and wanted to highlight that it should be the same. > * cpg, scif2 > > This is the compatibility string issue. > > Could we at least agree to defer this part of the discussion > and thus omit these nodes from the common dtsi file at this time? Fine with me :) > I understand that you are concerned that if we don't handle this > now it will be forgotten. FWIW I strongly doubt this particular > problem will be forgotten. Ok. Thanks! Best regards Dirk
Hi Simon, On 27.05.2016 09:32, Dirk Behme wrote: > Hi Simon, > > On 27.05.2016 02:42, Simon Horman wrote: >> On Thu, May 26, 2016 at 09:14:16AM +0200, Dirk Behme wrote: >>> Hi Simon, >>> >>> On 26.05.2016 04:28, Simon Horman wrote: >>>> Hi Dirk, >>>> >>>> On Wed, May 25, 2016 at 07:10:26AM +0200, Dirk Behme wrote: >>>>> Hi Simon, >>>>> >>>>> On 25.05.2016 02:48, Simon Horman wrote: >>>>>> Hi Dirk, >>>>>> >>>>>> On Tue, May 24, 2016 at 07:30:17AM +0200, Dirk Behme wrote: >>>>>>> Hi Simon, >>>>>> >>>>>> [...] >>>>>> >>>>>>> With Renesas R-Car3 we will get a whole family of SoCs. I.e. >>>>>>> different >>>>>>> computing power (e.g. different number of Cores) with more or >>>>>>> less similar >>>>>>> peripherals. >>>>>>> >>>>>>> I would think that we want to reflect this in the device tree, too. >>>>>>> Therefore I think what we want is a hierarchy of device trees. >>>>>>> Similar >>>>>>> what's done with other SoC families (compare e.g. i.MX6). >>>>>>> >>>>>>> E.g. we want an initial rcar3.dtsi, which contains all common >>>>>>> parts of all >>>>>>> R-Car3 SoCs. E.g. one CA57 core, the SCIF where its common etc. >>>>>>> >>>>>>> Then you will have the r8a779x.dtsi which includes the rcar3.dtsi >>>>>>> and >>>>>>> extends it for SoC specific parts. Which then will be included by >>>>>>> the board >>>>>>> device trees, as already done, now. >>>>>>> >>>>>>> Or in other words: As soon as you have similar parts in the >>>>>>> r8a779x.dtsi's, >>>>>>> it's time to think about moving the parts one hierarchy level up >>>>>>> into the >>>>>>> rcar3.dtsi. Else you will end up in a maintenance hell once you >>>>>>> have to >>>>>>> change/fix anything. >>>>>> >>>>>> Thanks for raising this issue. >>>>>> >>>>>> I agree entirely that we should work towards a situation where >>>>>> maintenance >>>>>> is as easy as it can be. However, due to the per-SoC binding >>>>>> scheme that >>>>>> we are using for IP related to Renesas SoCs I suspect that very >>>>>> few DT nodes >>>>>> can be shared between SoCs verbatim. >>>>> >>>>> >>>>> Could you kindly share an example for this? Looking into the H3 and >>>>> the M3-W >>>>> manual, it looks to me that ~90% (?) of the peripherals are the same. >>>> >>>> The background is that this is a conversation that has been going >>>> around >>>> for years. The basic thinking is that at this point we have >>>> documentation >>>> that indicates that many hardware blocks on the H3 and M3-W are the >>>> same. >>>> But we do not have insight into the internal versioning of the IP >>>> blocks >>>> nor if they are really the same. And furthermore even if they are >>>> currently >>>> the same we don't really know if that will continue to be the case. >>>> >>>> Probably it is. Maybe it isn't. The response has been to take a >>>> conservative approach to DT bindings to give us the flexibility to >>>> update >>>> the driver implementation to reflect any differences that subsequently >>>> surface. And by providing per-SoC bindings these driver changes can be >>>> activated on a per-SoC basis without updating DTB files (which may be >>>> burned into ROMs). >>> >>> >>> Sorry, but I don't think that these are good arguments for this kind of >>> discussion ;) >> >>> From my point of view this is the central point. It is my believe >>> that we >> simply do not have enough information to conclude that the IP blocks will >> be the same in perpetuity. >> >>> The discussion has to be based on facts. And not on "maybe" or >>> "probably". >>> The fact is that the documentation tells us that the IPs are the >>> same. And >>> the documentation tells us where this isn't the case. This is what we >>> can >>> reflect in the code and the device trees. >>> >>> Or the other way around: I don't ask to not have any SoC specific device >>> trees (r8a7795.dtsi, r8a7796.dtsi etc). So we *always* have the >>> option to >>> move anything to them, once there might be any difference found or >>> documented. But maintaining x (x > 5?) quite similar device trees just >>> because there *might* be the possibility that one or two device >>> *might* be >>> different doesn't sound like a good argument to me. >>> >>> Or again, an other way: If I understood correctly, you are working >>> already >>> since some time on R-Car, e.g. R-Car Gen2. How many examples do you have >>> from the Gen2 family where the IP blocks are different that they need >>> to be >>> distinguished in the device tree? >> >> I think the question is different. The question is, if a difference comes >> up, how do we handle it? >> >> So far we have a solution. Not an ideal one, but a solution none the >> less. >> I do agree entirely that replicated DTs leads to significant maintenance >> overhead. But lets not throw the baby out with the bath water. > > > Well, we could continue this kind of discussion infinite ;) > > But I agree to your below point "Lets discuss the change on its merits" > and therefore stop here and continue with the technical aspects below .... > > >>>>>> Probably some sort of scheme can be cooked up using preprocessor >>>>>> macros. >>>>>> And probably there are other ways to resolve this problem. But I >>>>>> would >>>>>> prefer if we worked towards resolving this maintenance problem in >>>>>> parallel >>>>>> with rather than as a dependency of merging r8a7796 support into >>>>>> mainline. >>>>> >>>>> >>>>> I'd propose to do it correct from the beginning. >>>>> >>>>> Doing it later would either be more work or forgotten, and never be >>>>> done, >>>>> then. >>>> >>>> I'm sorry but I don't agree. I think that having r8a7796 support >>>> in mainline is a higher priority than sorting this out. >>> >>> >>> Looking at the example I gave in >>> >>> http://article.gmane.org/gmane.linux.kernel.renesas-soc/4013 >>> >>> which took me < 1h to create, I'm not sure what would block us from >>> mainlining the r8a7796 *including* this. >> >> Point taken. Lets discuss the change on its merits. > > > I totally agree, thanks! Let's continue below ... > > >>>>> For a starting point, I'd propose to put the r8a7795.dtsi and >>>>> r8a7796.dtsi >>>>> into a graphical diff tool and move all common parts to a >>>>> rcar3.dtsi (I'd be >>>>> happy to discuss the name, though) >>>> >>>> I'm not opposed to that. But being consistent with my statement above >>>> I would prefer it to be done as follow-up work. >>>> >>>> My suspicion is that right now much of the proposed r8a7796.dtsi can be >>>> moved into a hypothetical rcar3.dtsi. But that this is because the >>>> proposed >>>> r8a7796.dtsi is very small. I would not expect nearly such a large >>>> proportion of r8a7795.dtsi to be able to be moved into rcar3.dtsi >>>> because >>>> it enables more hardware blocks and they typically have (or should >>>> have in >>>> keeping with the prevailing policy as described above) per-SoC >>>> bindings. >>> >>> >>> What doesn't prevent us to use a rcar3.dtsi like given in >>> >>> http://article.gmane.org/gmane.linux.kernel.renesas-soc/4013 >>> >>> >>> Having a rcar3.dtsi gives us *both* options. It doesn't force us to >>> use the >>> one or the other. I.e. we have for each IP block the *option* to >>> declare it >>> as common (put it onto rcar3.dtsi) *or* SoC specific (put it into >>> r8a779x.dtsi). >>> >>> Without having a common rcar3.dtsi we don't have this option at all. >>> >>> So I think the conclusion is: Let's have all options (by adding a >>> rcar3.dtsi) and then decide for each IP block individually where to >>> place it >>> best. Or move it later from the common dtsi to the individual dtsi once >>> there is an issue found (what I really doubt that it will happen that >>> often, >>> but this is an other topic ;) ) >> >> I think that most of the nodes you have moved into the common dtsi file >> make sense. But there are some I am less sure about: >> >> * cpus >> >> Probably there are some central aspects of cpus that are shared >> between the r8a7795 and r8a7796. And I think that your patch captures >> that. But I also think that there will be non-shared aspects and >> perhaps the complexity of splitting the cpus node between per-SoC >> and common dtsi files isn't worth it. >> >> I don't feel strongly about this at this point. >> >> I am also particularly sensitive about enabling CPU features across >> multiple SoCs. But I think that the scheme you propose allows for >> per-SoC control of features in per-SoC dtsi files. So I think >> I am ok about that at this point. >> >> Lastly, shouldn't the cache-controller go inside the cpu node >> in the common dtsi file to reflect the change recently made >> upstream to r8a7795.dtsi and the structure of r8a7796.dtsi in >> the current patchset (v3). > > > We already talked about that in an other thread, and I think I missed > that change you mentioned. So I'm fine with your proposal. I just saw > that it's different between r8a7795 and r8a7796 and wanted to highlight > that it should be the same. > > >> * cpg, scif2 >> >> This is the compatibility string issue. >> >> Could we at least agree to defer this part of the discussion >> and thus omit these nodes from the common dtsi file at this time? > > > Fine with me :) > > >> I understand that you are concerned that if we don't handle this >> now it will be forgotten. FWIW I strongly doubt this particular >> problem will be forgotten. > > > Ok. > > Thanks! Hmm, could you kindly help me to remember what's the recent status of your discussion above regarding a hierarchical structure of the RCar3 device trees? Best regards Dirk
On Wed, Jun 29, 2016 at 10:15:27AM +0200, Dirk Behme wrote: > Hi Simon, ... > Hmm, could you kindly help me to remember what's the recent status of your > discussion above regarding a hierarchical structure of the RCar3 device > trees? Hi Dirk, From my point of view the most promising avenue at this time is work that Geert has been doing to explore making things more flexible by updating the DT automatically at run time. He can expand on this but the idea is to add per-soc compat strings and otherwise update the DT into a per-SoC version. This ought to allow significant portions of the DT to be common between SoCs in the same R-Car generation for at lest Gen 2 and Gen 3.
Hi Simon, On 21.07.2016 01:51, Simon Horman wrote: > On Wed, Jun 29, 2016 at 10:15:27AM +0200, Dirk Behme wrote: >> Hi Simon, > > ... > >> Hmm, could you kindly help me to remember what's the recent status of your >> discussion above regarding a hierarchical structure of the RCar3 device >> trees? > > Hi Dirk, > >>From my point of view the most promising avenue at this time is work that > Geert has been doing to explore making things more flexible by updating the > DT automatically at run time. He can expand on this but the idea is to add > per-soc compat strings and otherwise update the DT into a per-SoC version. > This ought to allow significant portions of the DT to be common between > SoCs in the same R-Car generation for at lest Gen 2 and Gen 3. There are two topics: a) Hierarchical static structure of devices trees and clock definitions for RCar3 SoCs b) Detecting of RCar3 SoC type and engineering sample revisions at runtime About which topic do you talk here? I think we shouldn't mix them. Best regards Dirk P.S.: If you like, we could have a chat in #renesas-soc, too :)
Hi Dirk, On Thu, Jul 21, 2016 at 07:20:30AM +0200, Dirk Behme wrote: > Hi Simon, > > On 21.07.2016 01:51, Simon Horman wrote: > >On Wed, Jun 29, 2016 at 10:15:27AM +0200, Dirk Behme wrote: > >>Hi Simon, > > > >... > > > >>Hmm, could you kindly help me to remember what's the recent status of your > >>discussion above regarding a hierarchical structure of the RCar3 device > >>trees? > > > >Hi Dirk, > > > >>From my point of view the most promising avenue at this time is work that > >Geert has been doing to explore making things more flexible by updating the > >DT automatically at run time. He can expand on this but the idea is to add > >per-soc compat strings and otherwise update the DT into a per-SoC version. > >This ought to allow significant portions of the DT to be common between > >SoCs in the same R-Car generation for at lest Gen 2 and Gen 3. > > > There are two topics: > > a) Hierarchical static structure of devices trees and clock definitions for > RCar3 SoCs > b) Detecting of RCar3 SoC type and engineering sample revisions at runtime > > About which topic do you talk here? I think we shouldn't mix them. I was referring to topic a) which I would describe as consolidation of static DT descriptions. However, I believe that the same or a similar approach to DT fixups can also be used for problem b). I agree we should discuss these topics separately. > Best regards > > Dirk > > P.S.: If you like, we could have a chat in #renesas-soc, too :) Sure. In general I am there when I am at my desk and not completely consumed by work at hand.
diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt index 9cf67e48f222..d5ed554830d7 100644 --- a/Documentation/devicetree/bindings/arm/shmobile.txt +++ b/Documentation/devicetree/bindings/arm/shmobile.txt @@ -29,6 +29,8 @@ SoCs: compatible = "renesas,r8a7794" - R-Car H3 (R8A77950) compatible = "renesas,r8a7795" + - R-Car M3-W (R8A77960) + compatible = "renesas,r8a7796" Boards: @@ -61,5 +63,7 @@ Boards: compatible = "renesas,porter", "renesas,r8a7791" - Salvator-X (RTP0RC7795SIPB0010S) compatible = "renesas,salvator-x", "renesas,r8a7795"; + - Salvator-X + compatible = "renesas,salvator-x", "renesas,r8a7796"; - SILK (RTP0RC7794LCB00011S) compatible = "renesas,silk", "renesas,r8a7794" diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index efa77c146415..16d8d26839ea 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -114,6 +114,12 @@ config ARCH_R8A7795 help This enables support for the Renesas R-Car H3 SoC. +config ARCH_R8A7796 + bool "Renesas R-Car M3-W SoC Platform" + depends on ARCH_RENESAS + help + This enables support for the Renesas R-Car M3-W SoC. + config ARCH_STRATIX10 bool "Altera's Stratix 10 SoCFPGA Family" help diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi new file mode 100644 index 000000000000..178debf68318 --- /dev/null +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi @@ -0,0 +1,120 @@ +/* + * Device Tree Source for the r8a7796 SoC + * + * Copyright (C) 2016 Renesas Electronics Corp. + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed "as is" without any warranty of any + * kind, whether express or implied. + */ + +#include <dt-bindings/clock/r8a7796-cpg-mssr.h> +#include <dt-bindings/interrupt-controller/arm-gic.h> + +/ { + compatible = "renesas,r8a7796"; + #address-cells = <2>; + #size-cells = <2>; + + psci { + compatible = "arm,psci-0.2"; + method = "smc"; + }; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + /* 1 core only at this point */ + a57_0: cpu@0 { + compatible = "arm,cortex-a57", "arm,armv8"; + reg = <0x0>; + device_type = "cpu"; + next-level-cache = <&L2_CA57>; + enable-method = "psci"; + }; + + L2_CA57: cache-controller@0 { + compatible = "cache"; + reg = <0>; + cache-unified; + cache-level = <2>; + }; + }; + + extal_clk: extal { + compatible = "fixed-clock"; + #clock-cells = <0>; + /* This value must be overridden by the board */ + clock-frequency = <0>; + }; + + extalr_clk: extalr { + compatible = "fixed-clock"; + #clock-cells = <0>; + /* This value must be overridden by the board */ + clock-frequency = <0>; + }; + + /* External SCIF clock - to be overridden by boards that provide it */ + scif_clk: scif { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <0>; + }; + + soc { + compatible = "simple-bus"; + interrupt-parent = <&gic>; + #address-cells = <2>; + #size-cells = <2>; + ranges; + + gic: interrupt-controller@f1010000 { + compatible = "arm,gic-400"; + #interrupt-cells = <3>; + #address-cells = <0>; + interrupt-controller; + reg = <0x0 0xf1010000 0 0x1000>, + <0x0 0xf1020000 0 0x20000>, + <0x0 0xf1040000 0 0x20000>, + <0x0 0xf1060000 0 0x20000>; + interrupts = <GIC_PPI 9 + (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_HIGH)>; + }; + + timer { + compatible = "arm,armv8-timer"; + interrupts = <GIC_PPI 13 + (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>, + <GIC_PPI 14 + (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>, + <GIC_PPI 11 + (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>, + <GIC_PPI 10 + (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>; + }; + + cpg: clock-controller@e6150000 { + compatible = "renesas,r8a7796-cpg-mssr"; + reg = <0 0xe6150000 0 0x1000>; + clocks = <&extal_clk>, <&extalr_clk>; + clock-names = "extal", "extalr"; + #clock-cells = <2>; + #power-domain-cells = <0>; + }; + + scif2: serial@e6e88000 { + compatible = "renesas,scif-r8a7796", + "renesas,rcar-gen3-scif", "renesas,scif"; + reg = <0 0xe6e88000 0 64>; + interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 310>, + <&cpg CPG_CORE R8A7796_CLK_S3D1>, + <&scif_clk>; + clock-names = "fck", "brg_int", "scif_clk"; + power-domains = <&cpg>; + status = "disabled"; + }; + }; +};