Re: [PATCH v6 3/3] drm/rockchip: Add basic RK3588 HDMI output support

[Cristian Ciocaltea]

On 9/10/24 11:49 PM, Heiko Stübner wrote:
> Am Dienstag, 10. September 2024, 18:39:54 CEST schrieb Heiko Stübner:
>> Am Dienstag, 10. September 2024, 17:41:42 CEST schrieb Cristian Ciocaltea:
>>> On 9/10/24 6:21 PM, Heiko Stübner wrote:
>>>> Am Dienstag, 10. September 2024, 17:07:57 CEST schrieb Heiko Stübner:
>>>>> Am Freitag, 6. September 2024, 03:17:42 CEST schrieb Cristian Ciocaltea:
>>>>>> The RK3588 SoC family integrates the newer Synopsys DesignWare HDMI 2.1
>>>>>> Quad-Pixel (QP) TX controller IP and a HDMI/eDP TX Combo PHY based on a
>>>>>> Samsung IP block.
>>>>>>
>>>>>> Add just the basic support for now, i.e. RGB output up to 4K@60Hz,
>>>>>> without audio, CEC or any of the HDMI 2.1 specific features.
>>>>>>
>>>>>> Co-developed-by: Algea Cao <algea.cao@xxxxxxxxxxxxxx>
>>>>>> Signed-off-by: Algea Cao <algea.cao@xxxxxxxxxxxxxx>
>>>>>> Tested-by: Heiko Stuebner <heiko@xxxxxxxxx>
>>>>>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@xxxxxxxxxxxxx>
>>>>>
>>>>> I had switched from the v3 to this v6 in my playground-kernel today,
>>>>> with v3 I've never seen those, but now with v6 I have gotten multiple
>>>>> times:
>>>>>
>>>>> [  805.730608] Internal error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP
>>>>> [  805.739764] Modules linked in: snd_soc_simple_card crct10dif_ce snd_soc_simple_card_utils panthor drm_gpuvm drm_exec fuse
>>>>> [  805.752031] CPU: 3 UID: 0 PID: 775 Comm: Xorg Not tainted 6.11.0-rc7-00099-g459302f1f908-dirty #934
>>>>> [  805.762143] Hardware name: Theobroma Systems RK3588-Q7 SoM on Haikou devkit (DT)
>>>>> [  805.770407] pstate: 204000c9 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>>>>> [  805.778186] pc : regmap_mmio_read32le+0x8/0x20
>>>>> [  805.783155] lr : regmap_mmio_read+0x44/0x70
>>>>> [  805.787828] sp : ffff80008293b830
>>>>> [  805.791516] x29: ffff80008293b830 x28: ffff80008293bce8 x27: ffff0001f20ab080
>>>>> [  805.799495] x26: ffff800081139500 x25: 0000000000000000 x24: 0000000000000010
>>>>> [  805.807472] x23: 0000000000000000 x22: ffff0001f5a4b400 x21: ffff80008293b8c4
>>>>> [  805.815450] x20: 0000000000000968 x19: ffff0001f5a27a80 x18: 0000000000000070
>>>>> [  805.823428] x17: 0002441400000005 x16: 000004650441043c x15: 0438000008980804
>>>>> [  805.831406] x14: 07d8089807800780 x13: 0438000008980804 x12: ffff800081133630
>>>>> [  805.839384] x11: 0002441400000005 x10: 000004650441043c x9 : ffff800081a59000
>>>>> [  805.847361] x8 : 07d8089807800780 x7 : 0000000000000000 x6 : ffff0001f5b453c0
>>>>> [  805.855339] x5 : ffff800080750dc0 x4 : 0000000000000968 x3 : 0000000000000968
>>>>> [  805.863316] x2 : ffff800080751520 x1 : 0000000000000968 x0 : ffff800083b20968
>>>>> [  805.871294] Call trace:
>>>>> [  805.874012]  regmap_mmio_read32le+0x8/0x20
>>>>> [  805.878588]  _regmap_bus_reg_read+0x6c/0xac
>>>>> [  805.883262]  _regmap_read+0x60/0xd8
>>>>> [  805.887159]  _regmap_update_bits+0xf4/0x140
>>>>> [  805.891832]  regmap_update_bits_base+0x64/0xa0
>>>>> [  805.896797]  dw_hdmi_qp_bridge_atomic_enable+0x134/0x220
>>>>> [  805.902734]  drm_atomic_bridge_chain_enable+0x54/0xc8
>>>>> [  805.908380]  drm_atomic_helper_commit_modeset_enables+0x194/0x280
>>>>> [  805.915190]  drm_atomic_helper_commit_tail_rpm+0x50/0xa0
>>>>> [  805.921125]  commit_tail+0xa0/0x1a0
>>>>> [  805.925021]  drm_atomic_helper_commit+0x17c/0x1b0
>>>>> [  805.930276]  drm_atomic_commit+0xb8/0x100
>>>>> [  805.934754]  drm_atomic_connector_commit_dpms+0xe0/0x110
>>>>> [  805.940690]  drm_mode_obj_set_property_ioctl+0x1c0/0x420
>>>>> [  805.946626]  drm_connector_property_set_ioctl+0x3c/0x68
>>>>> [  805.952465]  drm_ioctl_kernel+0xc0/0x130
>>>>> [  805.956846]  drm_ioctl+0x214/0x4a0
>>>>> [  805.960643]  __arm64_sys_ioctl+0xac/0xf8
>>>>> [  805.965025]  invoke_syscall+0x48/0x104
>>>>> [  805.969214]  el0_svc_common.constprop.0+0x40/0xe0
>>>>> [  805.974470]  do_el0_svc+0x1c/0x28
>>>>> [  805.978171]  el0_svc+0x34/0xe0
>>>>> [  805.981582]  el0t_64_sync_handler+0x120/0x12c
>>>>> [  805.986449]  el0t_64_sync+0x190/0x194
>>>>> [  805.990540] Code: d503201f d503201f f9400000 8b214000 (b9400000)
>>>>>
>>>>> I guess that might be some clocking issue?
>>>>
>>>> Forgot to add, this happens when the display has blanked and then is
>>>> supposed to unblank again.
>>>
>>> Hmm, I've never encountered this while testing with my v6.11-rc1 based
>>> tree.  What is your current kernel base?  Did you change it while
>>> switching from v3 to v6?
>>>
>>> I'll rebase my tree onto latest linux-next and see if I can reproduce.
>>
>> The setup is 6.11-rc7 with your hdmi series + my wip dsi + X11 running
>> on top.
>>
>> At some point after being idle a while this blanks the display, which will
>> probably turn off clocks and such. After moving the mouse or just
>> doing anything else that unblanks the display, that splat happens.
>>
>> Apart from updating mesa from 24.2.0 to 24.2.2 I haven't changed
>> anything in my test-setup so far.
> 
> So now I've re-tested all :-) ... test scenario was that I reverted the v6
> patches and then applied the older versions (and fixed up the dts if
> needed wrt the vo{1}-grf thing). So now really only the hdmi driver
> changed. So I booted, waited for the display to blank and hit reboot
> on the serial console:
> 
> - v3 console output turned back on and rebooted fine
> - v4 console output turned back on and rebooted fine
> - v5 hit the error from above
> - v6 hit the error from above
> 
> So something between v4 and v5 seems to cause the hickup.

Thanks a lot for taking the time to bisect it!  This is indeed a clock
related regression introduced by the recent changes around scrambling.

I couldn't initially reproduce because I had the HDMI0 PHY clock provider
enabled, required to verify the high TMDS clock ratio and scrambling setup
in 4K@60Hz display mode.  Without that clock provider enabled, the PHY
eventually enters runtime PM suspend state, which for some reason causes
the splat when trying to access the LINK_CONFIG0 register.

To unblock the series, I would consider dropping the scrambling support for
now, as it turned to be far more complicated to have it properly handled
than I initially assumed.  Will move this to a separate WIP patch in my dev
tree, along the vop2 improvements for display modes handling, and resubmit
as soon as I get this work in a better shape.