[PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support
Simon Horman
horms at verge.net.au
Tue May 24 17:48:25 PDT 2016
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.
More information about the linux-arm-kernel
mailing list