Hi John, sorry this took so long, Am Mittwoch, 7. September 2016, 19:18:23 CEST schrieb John Keeping: > On Wed, 07 Sep 2016 19:58:31 +0200, Heiko Stuebner wrote: > > Am Mittwoch, 7. September 2016, 17:53:29 CEST schrieb John Keeping: > > > To minimize jitter on the I2S clocks, it is important that the > > > denominator in the fractional divider is much greater than the > > > numerator. Add identifiers for these internal clocks so that the > > > specific clock topology and rates can be specified in the device tree. > > > > The TRM states that the denominator must be bigger than 20. Is this the > > one > > you found or did you find further constraints? > > Is it not that the denominator must be bigger than 20 times the > numerator? That's what we found, although it seems that the greater the > divisor the better, so our aim is dividing down from 594MHz from GPLL to > the target rate in i2s_frac. That is good to know ... the TRM probably lost the real information during translation or so and only states that hard value. Looking at the rk3368 TRM just now, the value really is 20 times greater than the numerator. > > Did you try teaching the fractional divider to handle these constraints > > before going this way? > > No, I hadn't looked at doing that. I'm not sure how that would work, > we'd need to add support for fractional divider changing the parent rate > wouldn't we? Doug had a somewhat similar problem, mentioning the lack of a "bestdiv" equivalent that the standard divider provides. I'm not sure if there isn't a way to provide something like this and/or make the fractional clock honor specific requirments concerning numerator/denominator - any mathematicians around? :-) One could also replace the generic fraction divider use with a rockchip- specific implementation that somehow handles that. > > Exporting the internal clocks really would be sort of plan d or e, after > > handling this in the clock framework failed. Especially as i2s rates are > > probably dependant on the media being handled (frequencies and such), so > > setting fractional rates statically in the dts won't help you much in the > > general case, as any new playback could trigger a clk_set_rate call > > anyway? > > We're not setting the fractional rate specifically, instead we're > setting the i2s_pre rate and parent explicitly and banning the i2s_src > mux setting to i2s_pre, which means that clk_set_rate on sclk_i2s0 will > always change i2s_frac but leave i2s_pre alone. But then you are again in the situation where some requested rate can ignore those fractional-divider constraints? In general I really don't like encoding such board-specific behaviour into the generic clock tree, like needing to disable parent relationships. It works for your board now but does not necessarily for all other boards, which might require other "hacks" and also doesn't solve the general problem for all other fractional dividers we have. Heiko -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
