Hi Simon,
On 27.05.2016 09:32, Dirk Behme wrote:
Hi Simon,
On 27.05.2016 02:42, Simon Horman wrote:
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.
Well, we could continue this kind of discussion infinite ;)
But I agree to your below point "Lets discuss the change on its merits"
and therefore stop here and continue with the technical aspects below ....
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.
I totally agree, thanks! Let's continue below ...
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).
We already talked about that in an other thread, and I think I missed
that change you mentioned. So I'm fine with your proposal. I just saw
that it's different between r8a7795 and r8a7796 and wanted to highlight
that it should be the same.
* 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?
Fine with me :)
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.
Ok.
Thanks!
Hmm, could you kindly help me to remember what's the recent status of
your discussion above regarding a hierarchical structure of the RCar3
device trees?
Best regards
Dirk
