Am Freitag, den 13.03.2015, 08:50 +0100 schrieb Uwe Kleine-K?nig:

On Thu, Mar 12, 2015 at 09:57:53AM +0100, Philipp Zabel wrote:

quoted

Am Mittwoch, den 11.03.2015, 18:21 -0700 schrieb Stephen Boyd:
[...]

quoted

Why does Philipp like 110Hz the most? Where is the desire for that rate
coming from?

quoted

And the lower
abs(1 / 110 - 1 / r) the better. 

Similarly, where is this requirement coming from? Some datasheet? Or is
it just some arbitrary decision we've made that may not hold true for
all consumers?

It's not comming from a datasheet. But that's what I guess is the right
metric for quite some cases. E.g. an UART sample rate and I also
wouldn't be surprised if Philipp's panel example would call for this
metric, too.

For an UART running with say 38400 Bd you want to sample with a freqency
of 38400 Hz (not considering oversampling, but that is only a factor
that doesn't makes my reasoning wrong). If you now consider 38401 Hz and
38399 Hz the respective deltas are 1 Hz. But if you look at the time
between two samples we have:

	38401 Hz -> 26.04098852 us -> delta: 0.6781507 ns
	38400 Hz -> 26.04166667 us
	38399 Hz -> 26.04234485 us -> delta: 0.6781861 ns

So with 38401 it takes a little longer until the slightly deviating rate
results in sampling the wrong bit.

quoted

In this use case, the driver doesn't want the pixel clock to stay below
a hard frequency limit, but to get as close as possible to the target
frequency, either above or below, so the relative error to the nominal
panel refresh rate stays as small as possible. Thus for a fictional
target rate of 110 Hz, I'd like to minimize abs((round_rate / 110) - 1).

Note that minimizing

	abs((round_rate / 110) - 1)

is equivalent to minimizing

	abs(round_rate - 110)

Of course, and you're right, I should want to minimize the delta of the
interval time, not of the rate so that if playing back a video stream at
exactly the nominal frequency, it takes as long as possible until I have
to drop or duplicate a frame to stay in sync.

regards
Philipp