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

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

[Marek Marczykowski-Górecki]

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

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.

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

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

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

[Marek Marczykowski-Górecki]

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

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...

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

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

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

[Sebastian Reichel]

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

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.

Greetings,

-- Sebastian

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

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

[Marek Marczykowski-Górecki]

[-- 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 --]

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

[Dmitry Osipenko]

...
> 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...

Hi, glad it works. Potentially should be possible to detect and print a
msg. There should've been timeout errors on a driver probe with a wrong FW.

-- 
Best regards,
Dmitry