From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Subject: Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree Date: Mon, 13 Jun 2016 09:12:58 +0200 Message-ID: References: <13205049.n7pM8utpHF@wasted.cogentembedded.com> <2539026.OyU5nvpxa6@wasted.cogentembedded.com> <20160601005751.GG20527@verge.net.au> <20160610010245.GA10152@verge.net.au> <8efb1c7e-5463-2556-744c-d327886d92d4@cogentembedded.com> <1b9a4cf4-1101-ccbf-772b-49b8a689a1b6@cogentembedded.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <1b9a4cf4-1101-ccbf-772b-49b8a689a1b6@cogentembedded.com> Sender: linux-renesas-soc-owner@vger.kernel.org To: Sergei Shtylyov , Kuninori Morimoto Cc: Simon Horman , "open list:MEDIA DRIVERS FOR RENESAS - FCP" , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , "devicetree@vger.kernel.org" , Magnus Damm , Russell King , "linux-arm-kernel@lists.infradead.org" List-Id: devicetree@vger.kernel.org Hi Sergei, On Fri, Jun 10, 2016 at 10:50 PM, Sergei Shtylyov wrote: > On 06/10/2016 11:42 PM, Geert Uytterhoeven wrote: >>> The only problem I'm seeing (again) is the RCAN clock failing to >>> register: >>> >>> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12) >>> >>> I was going to look at it yesterday but (wrongly) thought it somehow >>> cured itself... I'll look at it now. >> >> The RCAN parent is the second clock in the CPG node's "clocks" property, >> which you didn't provide. > > Actually, the things are more complex. The figure 7.1c suggests that the > RCAN clock has different parent on R8A7792 than on the other SoCs -- namely > PLL1/VCO 1/4. That may be, since there's just no USB_EXTAL signal on this > SoC (it doesn't seem to support any USB IPs). Which means the > 'clk-rcar-gen2' driver can't work with the RCAN clock in its current form. Right, I had forgotten about that. Fortunately the clk-rcar-gen2 driver has a sane failure mode for this case ;-) it seems the RCAN clock can just be modeled as a fixed clock. However, its divider value isn't clear to me, as 15.9 MHz cannot be generated from PLL1 using an integer divider. Morimoto-san, can you please ask for clarification? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds