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
