Re: [PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support
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.
Re: [PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support
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 :)
Re: [PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support
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.
Re: [PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support
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 w
Re: [PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support
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 wo
Re: [PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support
On Fri, May 27, 2016 at 2:42 AM, Simon Horman 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 -- ge...@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 v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support
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:/
Re: [PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support
Hi Geert, On 26.05.2016 10:05, Geert Uytterhoeven wrote: Hi Dirk, On Thu, May 26, 2016 at 9:32 AM, Dirk Behme wrote: On 26.05.2016 09:03, Geert Uytterhoeven wrote: On Wed, May 25, 2016 at 9:32 AM, Dirk Behme wrote: P.S.: This also results in the question why we need similar r8a7795-cpg-mssr.h and r8a7796-cpg-mssr.h with just different "numbers" for the same clocks. Can't we use the same numbers on all SoCs, with just having wholes in the list where the clocks don't exist on a SoC? I haven't looked The CPG and MSSR block are the IP blocks that differ most among SoCs of the same family. Some clocks are present on H3 only, others on M3-W only. Yes, this is my understanding as well. Is the H3 a superset? And the M3-W drops some clocks? Or are there really clocks which are on M3-W only and not on H3? H3 is not a superset. M3-W e.g. has more S0Dx clocks (for x = 2, 3, 6, 8, 12). Ok, thanks! this &scif2 { clocks = <&cpg CPG_MOD 310>, <&cpg CPG_CORE R8A7795_CLK_S3D1>, <&scif_clk>; }; &scif2 { clocks = <&cpg CPG_MOD 310>, <&cpg CPG_CORE R8A7796_CLK_S3D1>, <&scif_clk>; }; should be done better. That's a bad example, as both SoCs use S3D1 ;-) Then, I'd propose to find a clever way to put the common parts into a rcar-gen3.dtsi and ... Now look at e.g. i2c: - On H3, the parent of the i2c module clock is S3D2, - On M3-W, the parent of the i2c module clock is S3D2 for i2c0/1/2, and S0D6 for i2c3/4/5/6. ... to keep the differences in the r8a7795.dtsi, r8a7796.dtsi etc. Best regards Dirk
Re: [PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support
Hi Dirk, On Thu, May 26, 2016 at 9:32 AM, Dirk Behme wrote: > On 26.05.2016 09:03, Geert Uytterhoeven wrote: >> On Wed, May 25, 2016 at 9:32 AM, Dirk Behme >> wrote: >>> P.S.: This also results in the question why we need similar >>> r8a7795-cpg-mssr.h and r8a7796-cpg-mssr.h with just different "numbers" >>> for >>> the same clocks. Can't we use the same numbers on all SoCs, with just >>> having >>> wholes in the list where the clocks don't exist on a SoC? I haven't >>> looked >> >> The CPG and MSSR block are the IP blocks that differ most among SoCs of >> the >> same family. Some clocks are present on H3 only, others on M3-W only. > > Yes, this is my understanding as well. Is the H3 a superset? And the M3-W > drops some clocks? Or are there really clocks which are on M3-W only and not > on H3? H3 is not a superset. M3-W e.g. has more S0Dx clocks (for x = 2, 3, 6, 8, 12). > this > > &scif2 { > clocks = <&cpg CPG_MOD 310>, > <&cpg CPG_CORE R8A7795_CLK_S3D1>, > <&scif_clk>; > }; > > &scif2 { > clocks = <&cpg CPG_MOD 310>, > <&cpg CPG_CORE R8A7796_CLK_S3D1>, > <&scif_clk>; > }; > > should be done better. That's a bad example, as both SoCs use S3D1 ;-) Now look at e.g. i2c: - On H3, the parent of the i2c module clock is S3D2, - On M3-W, the parent of the i2c module clock is S3D2 for i2c0/1/2, and S0D6 for i2c3/4/5/6. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support
On 26.05.2016 09:03, Geert Uytterhoeven wrote: Hi Dirk, On Wed, May 25, 2016 at 9:32 AM, Dirk Behme wrote: P.S.: This also results in the question why we need similar r8a7795-cpg-mssr.h and r8a7796-cpg-mssr.h with just different "numbers" for the same clocks. Can't we use the same numbers on all SoCs, with just having wholes in the list where the clocks don't exist on a SoC? I haven't looked The CPG and MSSR block are the IP blocks that differ most among SoCs of the same family. Some clocks are present on H3 only, others on M3-W only. Yes, this is my understanding as well. Is the H3 a superset? And the M3-W drops some clocks? Or are there really clocks which are on M3-W only and not on H3? Having a shared driver core, but different defines, is a compromise between reusability and avoiding mistakes in DTSes (e.g. pointing to a nonexisting clock due to copy and paste from another SoC). Sounds like this is a nice additional argument to don't do all this copy & paste and have a common rcar3.dtsi, instead :) into the manual if these numbers are given by the hardware, though. The actual numbers don't map to numbers in the datasheet, just to an unordered list in a table. The list of number is considered part of the DT bindings, and thus append-only (to be considered in case the datasheet is updated). Ok, then there should be the option to find a clever way to define the clocks common on all SoCs only once. And the clocks which are different somehow on top, then. To take the example from http://article.gmane.org/gmane.linux.kernel.renesas-soc/4013 this &scif2 { clocks = <&cpg CPG_MOD 310>, <&cpg CPG_CORE R8A7795_CLK_S3D1>, <&scif_clk>; }; &scif2 { clocks = <&cpg CPG_MOD 310>, <&cpg CPG_CORE R8A7796_CLK_S3D1>, <&scif_clk>; }; should be done better. Best regards Dirk
Re: [PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support
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 bindi
Re: [PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support
Hi Dirk, On Wed, May 25, 2016 at 9:32 AM, Dirk Behme wrote: > P.S.: This also results in the question why we need similar > r8a7795-cpg-mssr.h and r8a7796-cpg-mssr.h with just different "numbers" for > the same clocks. Can't we use the same numbers on all SoCs, with just having > wholes in the list where the clocks don't exist on a SoC? I haven't looked The CPG and MSSR block are the IP blocks that differ most among SoCs of the same family. Some clocks are present on H3 only, others on M3-W only. Having a shared driver core, but different defines, is a compromise between reusability and avoiding mistakes in DTSes (e.g. pointing to a nonexisting clock due to copy and paste from another SoC). > into the manual if these numbers are given by the hardware, though. The actual numbers don't map to numbers in the datasheet, just to an unordered list in a table. The list of number is considered part of the DT bindings, and thus append-only (to be considered in case the datasheet is updated). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support
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 > >Reviewed-by: Geert Uytterhoeven > >--- > >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 ..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 > >+#include > >+ > >+/ { > >+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.
Re: [PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support
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.
Re: [PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support
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 Reviewed-by: Geert Uytterhoeven --- 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 ..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 +#include + +/ { + 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
Re: [PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support
On 25.05.2016 07:10, 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. 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) To give an example what I'm talking about kindly have a look to the attached (draft) patch. Best regards Dirk P.S.: This also results in the question why we need similar r8a7795-cpg-mssr.h and r8a7796-cpg-mssr.h with just different "numbers" for the same clocks. Can't we use the same numbers on all SoCs, with just having wholes in the list where the clocks don't exist on a SoC? I haven't looked into the manual if these numbers are given by the hardware, though. >From 08078bf12780176ab116fe5f39a378f5ee374ae3 Mon Sep 17 00:00:00 2001 From: Dirk Behme Date: Wed, 25 May 2016 09:23:58 +0200 Subject: [PATCH] arm64: dts: Renesas R-Car3: Introduce common rcar3.dtsi The R-Car3 SoC family will contain several similar SoCs, sharing several peripherals. Introduce a common rcar3.dtsi containing the common parts of all R-Car3 family SoCs. Signed-off-by: Dirk Behme --- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 109 ++ arch/arm64/boot/dts/renesas/r8a7796.dtsi | 109 ++ arch/arm64/boot/dts/renesas/rcar3.dtsi | 112 +++ 3 files changed, 125 insertions(+), 205 deletions(-) create mode 100644 arch/arm64/boot/dts/renesas/rcar3.dtsi diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index a7315eb..0737ed2 100644 --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi @@ -10,11 +10,10 @@ #include #include +#include "rcar3.dtsi" / { compatible = "renesas,r8a7795"; - #address-cells = <2>; - #size-cells = <2>; aliases { i2c0 = &i2c0; @@ -26,23 +25,7 @@ i2c6 = &i2c6; }; - psci { - compatible = "arm,psci-0.2"; - method = "smc"; - }; - cpus { - #address-cells = <1>; - #size-cells = <0>; - - a57_0: cpu@0 { - compatible = "arm,cortex-a57", "arm,armv8"; - reg = <0x0>; - device_type = "cpu"; - next-level-cache = <&L2_CA57>; - enable-method = "psci"; - }; - a57_1: cpu@1 { compatible = "arm,cortex-a57","arm,armv8"; reg = <0x1>; @@ -66,32 +49,12 @@ }; }; - L2_CA57: cache-controller@0 { - compatible = "cache"; - cache-unified; - cache-level = <2>; - }; - L2_CA53: cache-controller@1 { compatible = "cache"; cache-unified; cache-level = <2>; }; - extal_clk: extal { - compatible = "fixed-clock"; -
Re: [PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support
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
Re: [PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support
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.
Re: [PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support
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 Reviewed-by: Geert Uytterhoeven --- 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 ..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 +#include 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
[PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support
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 Reviewed-by: Geert Uytterhoeven --- 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 ..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 +#include + +/ { + 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@f101 { + compatible = "arm,gic-400"; + #interrupt-cells = <3>; + #address-cells = <0>; + interrupt-controller; + reg = <0x0 0xf101 0 0x1000>, + <0x0 0xf102 0 0x2>, + <0x0 0xf104 0 0x2>, + <0x