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

[Simon Horman <horms@verge.net.au>]

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.