Bug 62591 - radeon: DCE4+ HDMI setup should be updated/improved (to match fglrx)
Summary: radeon: DCE4+ HDMI setup should be updated/improved (to match fglrx)
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-other
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-06 13:03 UTC by Rafał Miłecki
Modified: 2016-03-23 18:59 UTC (History)
1 user (show)

See Also:
Kernel Version: 3.12-rc3
Subsystem:
Regression: No
Bisected commit-id:


Attachments
gdb script that allows tracing fglrx (1.38 KB, text/plain)
2013-10-06 13:08 UTC, Rafał Miłecki
Details
Log and comparison of HDMI setup on DCE4+ AMD GPUs (21.45 KB, text/html)
2013-10-06 13:10 UTC, Rafał Miłecki
Details
Log of fglrx operations with hacked READs to return 0 or 0xFFFFFFFF (15.19 KB, text/html)
2013-10-06 13:17 UTC, Rafał Miłecki
Details

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.

Note You need to log in before you can comment on or make changes to this bug.