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