Quoting Jon Hunter (2018-07-19 08:06:50) > > On 19/07/18 15:22, Peter De Schrijver wrote: > > The first 3 possible parents of clk_out_[1-3] are defined as clk_m, clk_m/2 > > and clk_m/4. However They are actually osc, osc/2 and osc/4. In chips prior > > to Tegra210 clk_m and osc had the same frequency, so this difference didn't > > matter. Since Tegra210 however, clk_m is a divided version of osc. This > > results in CCF reporting the rate as only half the actual rate on Tegra210. > > To fix this, we add new clocks which have osc, osc/2, osc/4 and the > > respective extern clock as their possible parents and use them for > > Tegra210. Also 2 new DT clock defines are added to reflect the new > > names of clk_m/2 and clk_m/4. The old defines are still kept for backwards > > compatibility. > > > > Signed-off-by: Peter De Schrijver <pdeschrijver@xxxxxxxxxx> > I gave this a whirl on the Tegra210 Smaug which uses the PMC CLK_OUT1 to > clock the audio codec, but unfortunately this did not work. The good news > is that I know why. Basically, for Tegra210 there is a slight change in the > behaviour of the CLKx_ACCEPT_REQ bit. Essentially, this bit must always be > set if you want to use any of the osc clocks to drive the CLK_OUTx. Setting > this bit does not effect the CLK_OUTx if you are using the CAR to drive the > pin. The simplest thing to do for Tegra210 is to always set the > CLKx_ACCEPT_REQ. > So resend with that bit also set? -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
