[PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support

[Simon Horman]

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
> 
> 
> 
>