From mboxrd@z Thu Jan 1 00:00:00 1970 From: tony@atomide.com (Tony Lindgren) Date: Mon, 2 Feb 2015 09:44:18 -0800 Subject: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm In-Reply-To: References: <20150117164709.GS18552@atomide.com> <20150117181404.GW18552@atomide.com> <20150119172914.GY18552@atomide.com> <20150123164756.GB7718@atomide.com> <20150126155850.GD28663@atomide.com> Message-ID: <20150202174416.GE9418@atomide.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org * Matthijs van Duin [150128 13:46]: > On 26 January 2015 at 16:58, Tony Lindgren wrote: > > See earlier I was assuming copy paste issues from dm814x to dm816x > > Ahh, you thought the 816x was 814x-derived... yes I can imagine that > will have led to some confusion. > > > I'm pretty sure I verified the that the audio_pll_clk1 is hardwwired > > to 32KiHz by looking at it with a scope on the clkout pin. > > Yeah it comes straight from the "rtcdivider" so it'll produce > 0.0016384 * devosc. Not much about "rtcdivider" in the dm816x TRM.. > The global clock structure overview in the TRM (figure 2-6) actually > correctly marks the former-audio-fapll clocks (except audio5 := osc0, > yielding sysclk22 after divider) but you already need to know what the > hell is going on to recognize that. That seems to be in the dm814x TRM. OK so it looks like in mainline kernel drivers/clk/ti/fapll.c we can then fix the hardcoded value in ti_fapll_synth_recalc_rate() to return the rate of fd->clk_ref multiplied 0.0016384 instead of 32768. And we probably should add what you're explaining to the comments also to make some sense out of it :) Regards, Tony