Thanks for your fix, Dyllan, and for giving the series a spin. Would you mind if I simply picked up your patch from https://gitlab.freedesktop.org/dyllan500/linux/-/commit/560a1b22e4f764b8325e17f1d8f6dbbfd008e409 when I merge the series?
Harry On 2026-05-02 10:08, Dyllan Kobal wrote: > [You don't often get email from [email protected]. Learn why this is > important at https://aka.ms/LearnAboutSenderIdentification ] > > 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 >
