[PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support

Dirk Behme dirk.behme at de.bosch.com
Thu May 26 00:32:16 PDT 2016

On 26.05.2016 09:03, Geert Uytterhoeven wrote:
> Hi Dirk,
> On Wed, May 25, 2016 at 9:32 AM, Dirk Behme <dirk.behme at de.bosch.com> 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



&scif2 {
	clocks = <&cpg CPG_MOD 310>,
		 <&cpg CPG_CORE R8A7795_CLK_S3D1>,

&scif2 {
	clocks = <&cpg CPG_MOD 310>,
		 <&cpg CPG_CORE R8A7796_CLK_S3D1>,

should be done better.

Best regards


More information about the linux-arm-kernel mailing list