Commen=
t # 19
on bug 69675<=
/a>
from =
Anssi Hannula
(In reply to comment #=
16)
> + u64 n, d;
> +
> + if (*CTS =3D=3D 0) {
> + n =3D (u64)clock * N;
> + d =3D 128ULL * (u64)freq;
> + *CTS =3D div64_u64(n, d);
> + *CTS *=3D 1000ULL;
> + }
Hmm, I believe we should multiply before division, otherwise the result will
not be right... like this:
+ if (*CTS =3D=3D 0) {
+ n =3D (u64)clock * N * 1000ULL;
+ d =3D 128ULL * (u64)freq;
+ *CTS =3D div64_u64(n, d);
+ }
Also, maximum value for d is actually 128*48000, so no need for u64 for it,=
and
then one can use div_64u(u64,u32) for division. Similarly, CTS/N values are
just 20-bit so no need to u64 them (it might even be confusing), u64 for ju=
st
the "n" variable should be enough.
> Subject: [PATCH 3/3] drm/radeon: use hw generate=
d CTS/N values for audio
Just checking: What N value does the Hw use in that mode? The ones written =
in
by the driver, some hardcoded N or does it select one on its own? Though it
doesn't really matter much (since any reasonable N should work as long as C=
TS
is correct), except that if it uses the driver-set value we better not remo=
ve
the write to the N register :)
(In reply to comment #15)
> Somewhat related, the calculation in r600_hdmi_c=
alc_cts() is not very good
> as it loses a tonne of precision (roughly ten bits' worth). Given the =
range
> of the inputs, you might need to do the calculations in a 64-bit space=
.
I'm a bit interested if the calculated values "seem" to work if y=
ou only fix
the precisions there (Alex' patch1 plus my first tweak above), without addi=
ng
the correct values in the table?
If the actual freq is closer to 74176 instead of 74175.8, the calculated va=
lues
should actually be better than the table value (as you noticed, the table
values expect exact /1.001 rate), and it could be the calculation precision
issue (*1000 in the wrong place) then caused the audio issues as the CTS was
more wildly wrong...