Re: "signal is not locked" with HDMI RX driver on RK3588

["Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>]

[-- Attachment #1: Type: text/plain, Size: 3800 bytes --]

On Mon, Jun 30, 2025 at 07:51:39PM +0200, Sebastian Reichel wrote:
> Hi,
> 
> On Mon, Jun 30, 2025 at 03:57:03PM +0200, Marek Marczykowski-Górecki wrote:
> > On Mon, Jun 30, 2025 at 02:39:32PM +0200, Marek Marczykowski-Górecki wrote:
> > > Hi,
> > > 
> > > First of all, thanks for all the work regarding upstreaming the driver!
> > > 
> > > I try to use it on two boards:
> > > - Orange Pi 5B
> > > - Rock 5B+
> > > 
> > > In both cases, when I use the upstream driver in 6.16-rc, I hit similar
> > > issue:
> > > 1. `v4l2-ctl -d /dev/video2 --set-edid type=hdmi-4k-300mhz` - this works
> > > 2. EDID is properly presented to the device on the other side of the
> > > HDMI cable, I can select to use that "display"
> > > 3. But then, the hdmirx complains:
> > > 
> > >     v4l2-ctl -d /dev/video2 --query-dv-timings
> > >     VIDIOC_QUERY_DV_TIMINGS: failed: No locks available
> > > 
> > > And kernel shows:
> > > [ 4033.823023] snps_hdmirx fdee0000.hdmi_receiver: hdmirx_phy_register_write wait cr write done failed
> > > [ 4033.847027] snps_hdmirx fdee0000.hdmi_receiver: hdmirx_phy_register_write wait cr write done failed
> > > [ 4033.870976] snps_hdmirx fdee0000.hdmi_receiver: hdmirx_phy_register_write wait cr write done failed
> > > [ 4033.894998] snps_hdmirx fdee0000.hdmi_receiver: hdmirx_phy_register_write wait cr write done failed
> > > ...
> > > [ 4061.975400] fdee0000.hdmi_receiver: hdmirx_query_dv_timings: signal is not locked
> > > 
> > > In this state actually capturing video stream doesn't work either.
> > > 
> > > I tried also rockchip-release branch from
> > > https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux (at
> > > 33755850faeb0e53e634390d147cc261a60d2898) with the same result.
> > > 
> > > If I try the same with the 6.12.13-current-rockchip64 kernel from Armbian,
> > > it works fine. I tried to compare the drivers, but there are quite a few
> > > differences so it's hard to spot any obvious issue (it could be also an
> > > issue somewhere else...).
> > > 
> > > Any ideas? I can try to add some debugging info or test patches, if you
> > > point me what would be helpful.
> > 
> > If I take u-boot from
> > https://gitlab.collabora.com/hardware-enablement/rockchip-3588/u-boot/
> > (rockchip branch at 60501605e3f48b155af83193dfd9ad73362b8e25) and stop
> > loading device-tree from a separate file, I get a different error:
> > 
> >     VIDIOC_QUERY_DV_TIMINGS: failed: Numerical result out of range
> > 
> > (and no extra messages from kernel)
> > My goal is to capture in 4k at 30fps (or even lower), but I get this
> > error also with lower resolutions like 1920x1200@60fps. Unfortunately I
> > don't know which value specifically is out of range...
> 
> You are probably just using the wrong TF-A firmware. Rockchip's
> binary-only firmware contains a workaround/quirk, which handles the
> main HDMI-RX interrupt and then provides a virtual one on one of the
> reserved interrupt lines. The kernel has to use the virtual one,
> otherwise the driver is not functional.
> 
> The upstream (open source) TF-A does not contain this workaround and
> the kernel must use the original HDMI-RX interrupt line, as the
> reserved interrupt line is not doing anything at all.
> 
> The RK3588 device tree, which is provided as part of the mainline
> Linux kernel describes the interrupt lines from the hardware and
> thus needs to be used with the upstream TF-A.

That was it, thanks! Not it just works!

Is it possible for the driver to detect this situation and either
adjust, or at least print some more helpful message? I would have never
guessed to look there based on the existing symptoms...

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]