On 26.05.2016 09:03, Geert Uytterhoeven wrote:
Hi Dirk,
On Wed, May 25, 2016 at 9:32 AM, Dirk Behme <dirk.behme@xxxxxxxxxxxx> wrote:
P.S.: This also results in the question why we need similar
r8a7795-cpg-mssr.h and r8a7796-cpg-mssr.h with just different "numbers" for
the same clocks. Can't we use the same numbers on all SoCs, with just having
wholes in the list where the clocks don't exist on a SoC? I haven't looked
The CPG and MSSR block are the IP blocks that differ most among SoCs of the
same family. Some clocks are present on H3 only, others on M3-W only.
Yes, this is my understanding as well. Is the H3 a superset? And the
M3-W drops some clocks? Or are there really clocks which are on M3-W
only and not on H3?
Having a shared driver core, but different defines, is a compromise between
reusability and avoiding mistakes in DTSes (e.g. pointing to a nonexisting
clock due to copy and paste from another SoC).
Sounds like this is a nice additional argument to don't do all this copy
& paste and have a common rcar3.dtsi, instead :)
into the manual if these numbers are given by the hardware, though.
The actual numbers don't map to numbers in the datasheet, just to an unordered
list in a table. The list of number is considered part of the DT bindings, and
thus append-only (to be considered in case the datasheet is updated).
Ok, then there should be the option to find a clever way to define the
clocks common on all SoCs only once. And the clocks which are different
somehow on top, then.
To take the example from
http://article.gmane.org/gmane.linux.kernel.renesas-soc/4013
this
&scif2 {
clocks = <&cpg CPG_MOD 310>,
<&cpg CPG_CORE R8A7795_CLK_S3D1>,
<&scif_clk>;
};
&scif2 {
clocks = <&cpg CPG_MOD 310>,
<&cpg CPG_CORE R8A7796_CLK_S3D1>,
<&scif_clk>;
};
should be done better.
Best regards
Dirk
