On Sun, 25 Sep 2016 23:50:29 +0200, Heiko Stuebner wrote:

Am Mittwoch, 7. September 2016, 19:18:23 CEST schrieb John Keeping:

quoted

On Wed, 07 Sep 2016 19:58:31 +0200, Heiko Stuebner wrote:  

quoted

Am Mittwoch, 7. September 2016, 17:53:29 CEST schrieb John Keeping:  

quoted

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.

quoted

quoted

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? :-)

Yes, this is difficult, although I expect a simple approach of setting
the input as fast as possible would work reasonably well in practice.
But even when the input is a mux with a fixed set of possible rates it
is difficult to extract its maximum frequency within the clock
framework.

One could also replace the generic fraction divider use with a rockchip-
specific implementation that somehow handles that.

I hadn't considered that, I assumed there would be a strong preference
for enhancing the generic code rather than writing a special case
implementation.

quoted

quoted

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.

Yes, I wouldn't suggest changing the clock mux in the upstream kernel.
I was hoping specifying an assigned parent in DT would be enough to keep
the parent set correctly, but it doesn't seem to be.

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.

The sensible heuristic is to minimize the length of the clock path when
there are two equally good routes, which would handle the case where the
I2S clock can be generated without the need for a fractional divider.
But I don't think the clock framework has any way to take into account
that a mux may end up bypassing another clock.

It seems that even without the fractional divider we can't get low
enough jitter to meet our requirements, so we've decided to use an
external clock for I2S.  As a result of that, we're no longer using this
part of the clock tree at all, so I'm happy to drop these patches.


John