From: Dyllan Kobal <[email protected]>
Hi Harry, Rodrigo, Jerry,
Tested this series on Navi 22 (RX 6700 XT class, DCN 3.0.2) with a
Sony Bravia 8 II as the HDMI sink. Hit a NULL deref at amdgpu probe:
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor instruction fetch in kernel mode
Oops: Oops: 0010 [#1] SMP NOPTI
CPU: 14 UID: 0 PID: 568 Comm: (udev-worker) Not tainted 6.19.0+
RIP: 0010:0x0
Call Trace:
<TASK>
hdmi_frl_perform_link_training_with_fallback+0x64/0x110 [amdgpu]
hdmi_frl_verify_link_cap+0x24e/0x5d0 [amdgpu]
link_detect+0x4b4/0x550 [amdgpu]
amdgpu_dm_initialize_drm_device+0x73f/0xb21 [amdgpu]
amdgpu_dm_init.cold+0x734/0x86c [amdgpu]
dm_hw_init+0x1b/0x90 [amdgpu]
amdgpu_device_ip_init+0x690/0x7fe [amdgpu]
amdgpu_device_init.cold+0x460/0x781 [amdgpu]
amdgpu_driver_load_kms+0x19/0x80 [amdgpu]
amdgpu_pci_probe+0x19b/0x550 [amdgpu]
Cause: this patch wires .setup_hdmi_frl_link into the dcn314, dcn32,
dcn35, dcn351, dcn401 and dcn42 hwss tables, but not into dcn30's.
The dcn30 family (dcn30/302/303 — Navi 21/22/23) does get FRL
resource creation per patches 16/17, so hdmi_frl_verify_link_cap()
runs on these ASICs and dispatches through the NULL
hwss.setup_hdmi_frl_link inside hdmi_frl_perform_link_training_with_fallback().
amdgpu probe is fatally aborted with no display.
Fix locally:
--- a/drivers/gpu/drm/amd/display/dc/hwss/dcn30/dcn30_init.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn30/dcn30_init.c
@@ -105,6 +105,7 @@ static const struct hw_sequencer_funcs dcn30_funcs = {
.enable_tmds_link_output = dce110_enable_tmds_link_output,
.enable_dp_link_output = dce110_enable_dp_link_output,
.disable_link_output = dce110_disable_link_output,
+ .setup_hdmi_frl_link = dcn30_setup_hdmi_frl_link,
.set_disp_pattern_generator = dcn30_set_disp_pattern_generator,
.get_dcc_en_bits = dcn10_get_dcc_en_bits,
.update_visual_confirm_color = dcn10_update_visual_confirm_color,
With that one-line fix folded in, the Bravia comes up at 4K@120Hz
10bpc RGB native FRL on cold boot. Live register state confirms the
HPO HDMI block is what is driving the link, not legacy TMDS:
- All legacy DIG[0-5] show DIG_BE_EN_CNTL.DIG_ENABLE = 0
- All legacy SYMCLK[A-E] show CLOCK_ENABLE = 0
- DIG0_HDMI_CONTROL.HDMI_DATA_SCRAMBLE_EN = 0
(HDMI 2.0 TMDS scramble path is provably idle)
- HPO_TOP_CLOCK_CONTROL.HPO_HDMISTREAMCLK_GATE_DIS = 1
(HPO HDMI stream clock is forced on)
- PHYASYMCLK_CLOCK_CNTL.PHYASYMCLK_FORCE_EN = 1,
PHYASYMCLK_FORCE_SRC_SEL = 1 (FRL signaling source selected)
Worth noting: the public dcn_3_0_2 ASIC register headers in tree do
not expose any of the HPO HDMI / HDMI_FRL_ENC / HDMI_LINK_ENC
register offsets — they only define HPO_HDMISTREAMCLK_GATE_DIS as a
single bit field inside HPO_TOP_CLOCK_CONTROL. Despite that, the
silicon clearly decodes the rest of the block (the relative offsets
from dcn_3_1_2 evidently land at usable addresses on dcn_3_0_2).
This is the first time, to my knowledge, that native HDMI 2.1 FRL
has been demonstrated working on a Navi 22-class card on Linux.
Happy to retest a v2 if you fold the fix in.
Reported-by: Dyllan Kobal <[email protected]>
Tested-by: Dyllan Kobal <[email protected]> # Navi 22 + Bravia 8 II, 4K@120
10bpc RGB
Thanks,
-Dyllan
