On Fri, Sep 04, 2015 at 04:50:03PM -0700, Doug Anderson wrote:
> Russell,
>
> On Fri, Sep 4, 2015 at 2:24 PM, Russell King - ARM Linux
> <linux@xxxxxxxxxxxxxxxx> wrote:
> >> In your case you're probably making the value that Linux
> >> asked you to make, AKA 25.175000 MHz.
> >
> > ... which is the spec value.
>
> This is where we're not on the same page. Where in the spec does it
> say 25.17500 MHz? I see in the spec:
> 25.2 / 1.001
Section 4 of CEA-861-B, which defines the video clock rates and their
accuracy of 0.5%.
> ...and this is a crucial difference here. Please double-check my math, but:
>
> (25175000 * 4576) / (128 * 32000.)
> => 28125.1953125
>
> (25174825 * 4576) / (128 * 32000.)
> => 28125.0
>
> This calculation is what led to my belief that the goal here is to
> make an integral CTS. If you have 25.175 MHZ clock and N of 4576 you
> _will not_ have an integral CTS. If you instead have 25.174825 MHz
> clock and N of 4576 you _will_ have an integral CTS.
Right, but 25.175 is close enough to 25.174825. Do this calculation:
25175000 * 4576 / 28125 / 128
That'll give you the resulting audio sample rate, which is 32000.222Hz.
That's an error of... 0.00069%, which is probably around the typical
error of your average crystal oscillator. Really not worth bothering
with.
> Said another way:
>
> 1. The reason 25174825 Hz has a different N is to make an integral CTS.
>
> 2. If you are indeed making 25175000 then there is no need for a
> different N to make an integral CTS
>
> 3. If you use 4576 for N but you're making 25175000 Hz, you end up in
> a _worse_ position than if you use the standard 4096 for N.
Total rubbish. Sorry, but it is.
Follow the code. Pixel clock is 25175000. For 32kHz, N will be 4576.
25175000 * 4576 = 1.152008e11. Divide that by the audio clock rate
(128 * 32000) gives 28125.19531. Since we're using integer division,
that gets rounded down to 28125.
DRM uses a clock rate of "25175" to represent 25.2/1.001 modes. So,
if your hardware sets a video clock rate of 25.2MHz/1.001, then you
end up with a sample rate of exactly 32kHz. If you set exactly
25.175MHz, you end up with an approximate 32kHz sample rate - one
which is 0.00069% in error, which is (excluse the language) fuck all
different from exactly 32kHz.
Are you _really_ going to continue arguing over a 0.00069% error?
If you are, I'm not going to listen anymore - it's soo damned small
that it's not worth bothering with. At all.
The only time that you'd need to worry about it is if you wanted a
super-accurate system, and for that you'd need an atomic clock to
source your system clocks to reduce aging effects, temperature
induced drift, etc, maybe locking the atomic clock to a national
frequency standard like the Anthorn MSF 60kHz transmitter signal
broadcast by the UK National Physics Laboratory.
> >> As a first step I'd suggest just removing all the special cases and
> >> add a comment. From real world testing it doesn't seem terribly
> >> critical to be slightly off on CTS. ...and in any case for any clock
> >> rates except the small handful in the HDMI spec we'll be slightly off
> >> on CTS anyway...
> >
> > They're not "special cases" made up to fit something - they're from the
> > tables in the HDMI specification.
>
> They are definitely "special cases". There is a general rule in the
> code you posted (aim for 128 * freq) and these are cases for certain
> clocks that are an exception to the general rule. AKA they are
> special cases.
Sorry, I disagree with you.
> > That assumes that the audio and video clocks are coherent. On iMX6
> > hardware using this, the audio is clocked at the rate defined by the
> > TDMS clock and the CTS/N values.
>
> I'll admit I haven't looked at the audio section of dw_hdmi much, but
> I'd imagine that for all users of this controller / PHY the audio and
> video clocks are coherent.
Not if the audio clock comes from an I2S master rather than being
sourced from the HDMI block.
> I think in the perfect world we'd be able to generate exactly
> 25174825.174825177 Hz and we'd use all the rates from the HDMI spec.
To generate something of that accuracy, you'd need something like a
caesium fountain atomic clock.
> and we'd get spot on 32 kHz audio. ...but I'm simply saying that
> we're not in that perfect world yet.
>
> Also note that there are many many rates not in the HDMI spec that
> could benefit from similar optimization of trying to adjust N to make
> an integral CTS.
Now go and look at the HDMI spec, where it gives the CTS value for
74.25/1.001 for 32kHz. That can't be represented by an integer CTS
value, so using this hardware, we can't generate that sample rate
without an error. We'd use a fixed CTS value of 210937 instead, which
works out at a 0.00024% error. Again, not worth worrying about.
>
> ---
>
> As a side note: I realized one part of the HDMI spec that isn't trying
> to make an integral value but still uses a different value for N: 297
> MHz. From the DesignWare spec I have it appears that 594 MHz is
> similar. For those cases it looks like we have:
297MHz _does_ work.
297000000 * 3072 / 222750 = 128 * 32000 exactly.
>
> if (pixel_clk == 297000000) {
> switch (freq) {
> case 32000:
> return (128 * freq) / 1333;
Plug the numbers in. 128 * 32000 / 1333 = 3072.96 but because we're using
integer math, that's 3072. Which just happens to be the value in the HDMI
spec.
> case 44100:
> case 48000:
> case 88200:
> case 96000:
> case 176400:
> return (128 * freq) / 1200;
Do the math again. You get the spec figures for N.
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
