[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)

[bugzilla-daemon@freedesktop.org]

[-- Attachment #1.1: Type: text/plain, Size: 2115 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=69675

--- Comment #19 from Anssi Hannula <anssi@mageia.org> ---
(In reply to comment #16)
> +	u64 n, d;
> +
> +	if (*CTS == 0) {
> +		n = (u64)clock * N;
> +		d = 128ULL * (u64)freq;
> +		*CTS = div64_u64(n, d);
> +		*CTS *= 1000ULL;
> +	}

Hmm, I believe we should multiply before division, otherwise the result will
not be right... like this:
+    if (*CTS == 0) {
+        n = (u64)clock * N * 1000ULL;
+        d = 128ULL * (u64)freq;
+        *CTS = 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 just
the "n" variable should be enough.

> Subject: [PATCH 3/3] drm/radeon: use hw generated 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 CTS
is correct), except that if it uses the driver-set value we better not remove
the write to the N register :)

(In reply to comment #15)
> Somewhat related, the calculation in r600_hdmi_calc_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 you only fix
the precisions there (Alex' patch1 plus my first tweak above), without adding
the correct values in the table?

If the actual freq is closer to 74176 instead of 74175.8, the calculated values
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...

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 3125 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel