Bug 62591

Summary:	radeon: DCE4+ HDMI setup should be updated/improved (to match fglrx)
Product:	Drivers	Reporter:	Rafał Miłecki (zajec5)
Component:	Video(DRI - non Intel)	Assignee:	drivers_video-other
Status:	NEW ---
Severity:	normal	CC:	szg00000
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	3.12-rc3	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	gdb script that allows tracing fglrx Log and comparison of HDMI setup on DCE4+ AMD GPUs Log of fglrx operations with hacked READs to return 0 or 0xFFFFFFFF

Description Rafał Miłecki 2013-10-06 13:03:22 UTC

HDMI (AKA audio) mode support in radeon driver is mostly coming from RE efforts.

There was some code released by AMD (see 0001-WIP-port-of-hdmi-dp-audio-code-to-newer-kernel.patch) based on the internal specs, but it appears specs don't cover some corner cases. Setting some bit resulted in black display and it seems fglrx contains many workarounds to support all TVs well.

Current code isn't based on perfect RE method, we were mostly observing registers, not tracing fglrx operations. Later we mixed our code with released patch logic, but we still don't behave like fglrx in all operations.

It should be a good idea to trace fglrx operations and improve radeon's code to match it as much as possible.

Comment 1 Rafał Miłecki 2013-10-06 13:08:01 UTC

Created attachment 110321 [details]
gdb script that allows tracing fglrx

Attached fglrx.gdb allows tracing R/W operations performed by fglrx.

Please note it contains some hacks like:
set $curreg = ($rdi & 0x1FFFF) - 0x6000
that are probably environment-specific.

It may also not work on x86 (was tested on x86_64).

Comment 2 Rafał Miłecki 2013-10-06 13:10:26 UTC

Created attachment 110331 [details]
Log and comparison of HDMI setup on DCE4+ AMD GPUs

Comment 3 Rafał Miłecki 2013-10-06 13:15:43 UTC

The only problem with the attached log is we can't know what fglrx really did in (for example) following operation:
RREG32(0x00007c5c) → 0x00000000
WREG32(0x00007c5c) ← 0x00000000

It's easy to guess fglrx cleared some bit(s), but we can't really say which.

So I came with the idea of faking 0x7c5c read to return 0xFFFFFFFF.

Comment 4 Rafał Miłecki 2013-10-06 13:17:11 UTC

Created attachment 110341 [details]
Log of fglrx operations with hacked READs to return 0 or 0xFFFFFFFF

It contains log for HD6320 (DCE4.1) only, but it should be enough.

Comment 5 Rafał Miłecki 2013-10-13 15:16:37 UTC

In the last attachment you could see that faking 0x5e78 register read to 0xFFFFFFFF made fglrx believe audio is already enabled and it didn't do anything.

So I had to fake as much bits as possible without letting fglrx not initialize audio. This resulted in the:

RREG32(0x00005e78) → 0x70ffffff
RREG32(0x00005e80) → 0xffffffff
WREG32(0x00005e80) ← 0xfc000001);
WREG32(0x00005e78) ← 0xffffffff);

Thanks to that we know nothing in the 0x5e78 has to be cleared and what bits should be cleared in the 0x5e80.