From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Horman Date: Thu, 08 Jan 2015 00:38:27 +0000 Subject: Re: [PATCH] ARM: shmobile: r8a7794: Correct SDHI clock node names Message-Id: <20150108003826.GF18943@verge.net.au> List-Id: References: <1420418648-7815-1-git-send-email-horms+renesas@verge.net.au> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-arm-kernel@lists.infradead.org On Mon, Jan 05, 2015 at 10:41:14AM +0100, Geert Uytterhoeven wrote: > On Mon, Jan 5, 2015 at 1:44 AM, Simon Horman wrote: > > diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi > > index 8f78da5..9856e9c 100644 > > --- a/arch/arm/boot/dts/r8a7794.dtsi > > +++ b/arch/arm/boot/dts/r8a7794.dtsi > > @@ -294,14 +294,14 @@ > > "lb", "qspi", "sdh", "sd0", "z"; > > }; > > /* Variable factor clocks */ > > - sd1_clk: sd2_clk@e6150078 { > > + sd1_clk: sd1_clk@e6150078 { > > compatible = "renesas,r8a7794-div6-clock", "renesas,cpg-div6-clock"; > > reg = <0 0xe6150078 0 4>; > > clocks = <&pll1_div2_clk>; > > #clock-cells = <0>; > > clock-output-names = "sd1"; > > }; > > - sd2_clk: sd3_clk@e615007c { > > + sd2_clk: sd2_clk@e615007c { > > compatible = "renesas,r8a7794-div6-clock", "renesas,cpg-div6-clock"; > > reg = <0 0xe615007c 0 4>; > > clocks = <&pll1_div2_clk>; > > According to the documentation, SDCKCR is 0xe6150074, not ..78, > SD2CKCR is 0xe6150078, not ..7c. > For reference SD3CKCR is 0xe615026c. > > Note that r8a7791.dtsi also has the mismatches between the labels and node > names. > > The discrepancy is caused by the different number of SDHI modules in the > different SoCs of the R-Car Gen2 family. > > - r8a7790 has hardware modules SDHI0, SDHI1, SDHI2, and SDHI3. > - r8a7791 and r8a7794 have hardware modules SDHI0, SDHI2, and SDHI3, > but call the last two instances SDHI1 and SDHI2, while the clock registers > are not renumbered. > So instance SDHI1 uses SD2CKCR, and instance SDHI2 uses SD3CKCR, right? I had not noticed, but yes that does seem to be the case. > That means the node names are actually correct. But the register value and > unit address for the second clock are still wrong, they should be (0x)e615007c, Ok, that makes sense. But in that the labels want updating, right? > cfr. in r8a7791.dtsi. > > Note that IMHO the clock-output-names are wrong, for both r8a7791 and r8a7794, > as the hardware documentation calls these "sd2" and "sd3", not "sd1" and "sd2". Excellent. I think we can easily change that for the r8a7794 as the nodes aren't being consumed nor have been part of a release. But I'm less sure about a path forward for the r8a7791. What are your thoughts?