arch/arm64/configs/defconfig | 1 + drivers/gpu/drm/bridge/synopsys/Kconfig | 8 + drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 224 ++++++++++++++++++++++++- drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.h | 14 ++ drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c | 77 +++++---- include/drm/bridge/dw_hdmi_qp.h | 2 + 6 files changed, 284 insertions(+), 42 deletions(-)
The first patch in the series implements the CEC capability of the
Synopsys DesignWare HDMI QP TX controller found in RK3588 & RK3576 Socs.
This is based on the downstream code, but rewritten on top of the CEC
helpers added recently to the DRM HDMI connector framework.
The second patch is needed for RK3576 in order to fixup the timer base
setup according to the actual reference clock rate, which differs
slightly from RK3588.
The following three patches setup platform data with the new information
expected by the HDMI QP transmitter library, while improving the error
handling in the probe path.
Please note the CEC helpers were affected by a resource deallocation
issue which could crash the kernel and freeze the system under certain
test conditions. This has been already fixed in v6.17-rc1 via commit
19920ab98e17 ("drm/display: hdmi-cec-helper: Fix adapter
unregistration").
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
Changes in v4:
- Fixed the bisect-related issues reported by Daniel by implementing
the following operations in dw_hdmi_qp_bind():
* Disable CEC support when the related IRQ is not available
* Set ref_clk_rate to vendor default in case it was not provided by
the platform driver
* In both scenarios, also print a warning message to highlight the
need for fixing the platform driver
- Simplified dw_hdmi_qp_cec_init() a bit
* Removed the now obsolete cec->irq validation test
* Removed the superfluous error checking and logging around
devm_request_threaded_irq() call (it already handles all that)
- Collected R-b tags from Daniel
- Rebased series onto next-20250903
- Link to v3: https://lore.kernel.org/r/20250825-rk3588-hdmi-cec-v3-0-95324fb22592@collabora.com
Changes in v3:
- Fixup PATCH 1 according to the recent upstream commit 02bb63d1a593
("drm/bridge: Make dp/hdmi_audio_* callback keep the same paramter
order with get_modes") which changed the signature of ->hdmi_cec_init()
callback of struct drm_bridge_funcs; while at it, also update the
copyright section
- Updated cover letter to indicate that the CEC helpers fix is already
available since v6.17-rc1
- Rebased series onto next-20250825
- Link to v2: https://lore.kernel.org/r/20250710-rk3588-hdmi-cec-v2-0-f5884be34bc1@collabora.com
Changes in v2:
- Collected R-b tag from Dmitry
- Restructured the generic bridge patches to not depend on the
platform-specific changes and updated cover letter accordingly (Heiko)
- Replaced the loop searching for "ref" clock with clk_get() (Maxime)
- Added new patch "drm/rockchip: dw_hdmi_qp: Improve error handling with
dev_err_probe()"
- Link to v1: https://lore.kernel.org/r/20250704-rk3588-hdmi-cec-v1-0-2bd8de8700cd@collabora.com
---
Cristian Ciocaltea (6):
drm/bridge: dw-hdmi-qp: Add CEC support
drm/bridge: dw-hdmi-qp: Fixup timer base setup
drm/rockchip: dw_hdmi_qp: Improve error handling with dev_err_probe()
drm/rockchip: dw_hdmi_qp: Provide CEC IRQ in dw_hdmi_qp_plat_data
drm/rockchip: dw_hdmi_qp: Provide ref clock rate in dw_hdmi_qp_plat_data
arm64: defconfig: Enable DW HDMI QP CEC support
arch/arm64/configs/defconfig | 1 +
drivers/gpu/drm/bridge/synopsys/Kconfig | 8 +
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 224 ++++++++++++++++++++++++-
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.h | 14 ++
drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c | 77 +++++----
include/drm/bridge/dw_hdmi_qp.h | 2 +
6 files changed, 284 insertions(+), 42 deletions(-)
---
base-commit: 5d50cf9f7cf20a17ac469c20a2e07c29c1f6aab7
change-id: 20250703-rk3588-hdmi-cec-cea8f523df48
On Wed, Sep 03, 2025 at 09:50:58PM +0300, Cristian Ciocaltea wrote:
> The first patch in the series implements the CEC capability of the
> Synopsys DesignWare HDMI QP TX controller found in RK3588 & RK3576 Socs.
> This is based on the downstream code, but rewritten on top of the CEC
> helpers added recently to the DRM HDMI connector framework.
>
> The second patch is needed for RK3576 in order to fixup the timer base
> setup according to the actual reference clock rate, which differs
> slightly from RK3588.
>
> The following three patches setup platform data with the new information
> expected by the HDMI QP transmitter library, while improving the error
> handling in the probe path.
>
> Please note the CEC helpers were affected by a resource deallocation
> issue which could crash the kernel and freeze the system under certain
> test conditions. This has been already fixed in v6.17-rc1 via commit
> 19920ab98e17 ("drm/display: hdmi-cec-helper: Fix adapter
> unregistration").
>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Cristian, I'm sorry for almost off-topic, but as you are working on this
driver: would it be possible to support HDMI (vendor-specific) and SPD
InfoFrames in the dw-hdmi-qp driver?
--
With best wishes
Dmitry
Hi Dmitry,
On 9/5/25 2:48 AM, Dmitry Baryshkov wrote:
> On Wed, Sep 03, 2025 at 09:50:58PM +0300, Cristian Ciocaltea wrote:
>> The first patch in the series implements the CEC capability of the
>> Synopsys DesignWare HDMI QP TX controller found in RK3588 & RK3576 Socs.
>> This is based on the downstream code, but rewritten on top of the CEC
>> helpers added recently to the DRM HDMI connector framework.
>>
>> The second patch is needed for RK3576 in order to fixup the timer base
>> setup according to the actual reference clock rate, which differs
>> slightly from RK3588.
>>
>> The following three patches setup platform data with the new information
>> expected by the HDMI QP transmitter library, while improving the error
>> handling in the probe path.
>>
>> Please note the CEC helpers were affected by a resource deallocation
>> issue which could crash the kernel and freeze the system under certain
>> test conditions. This has been already fixed in v6.17-rc1 via commit
>> 19920ab98e17 ("drm/display: hdmi-cec-helper: Fix adapter
>> unregistration").
>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>
> Cristian, I'm sorry for almost off-topic, but as you are working on this
> driver: would it be possible to support HDMI (vendor-specific) and SPD
> InfoFrames in the dw-hdmi-qp driver?
Sure, no worries. I'll be on leave for the next two weeks, but I can handle
it on my return.
Regards,
Cristian
On Fri, Sep 05, 2025 at 09:32:36AM +0300, Cristian Ciocaltea wrote:
> Hi Dmitry,
>
> On 9/5/25 2:48 AM, Dmitry Baryshkov wrote:
> > On Wed, Sep 03, 2025 at 09:50:58PM +0300, Cristian Ciocaltea wrote:
> >> The first patch in the series implements the CEC capability of the
> >> Synopsys DesignWare HDMI QP TX controller found in RK3588 & RK3576 Socs.
> >> This is based on the downstream code, but rewritten on top of the CEC
> >> helpers added recently to the DRM HDMI connector framework.
> >>
> >> The second patch is needed for RK3576 in order to fixup the timer base
> >> setup according to the actual reference clock rate, which differs
> >> slightly from RK3588.
> >>
> >> The following three patches setup platform data with the new information
> >> expected by the HDMI QP transmitter library, while improving the error
> >> handling in the probe path.
> >>
> >> Please note the CEC helpers were affected by a resource deallocation
> >> issue which could crash the kernel and freeze the system under certain
> >> test conditions. This has been already fixed in v6.17-rc1 via commit
> >> 19920ab98e17 ("drm/display: hdmi-cec-helper: Fix adapter
> >> unregistration").
> >>
> >> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> >
> > Cristian, I'm sorry for almost off-topic, but as you are working on this
> > driver: would it be possible to support HDMI (vendor-specific) and SPD
> > InfoFrames in the dw-hdmi-qp driver?
>
> Sure, no worries. I'll be on leave for the next two weeks, but I can handle
> it on my return.
Nice, thanks!
--
With best wishes
Dmitry
On Wed, Sep 03, 2025 at 09:50:58PM +0300, Cristian Ciocaltea wrote: > The first patch in the series implements the CEC capability of the > Synopsys DesignWare HDMI QP TX controller found in RK3588 & RK3576 Socs. > This is based on the downstream code, but rewritten on top of the CEC > helpers added recently to the DRM HDMI connector framework. For the past couple of weeks we've been seeing various instability with the graphics drivers on the Rock 5B in -next, the most common system is that we get faults in code that looks suspiciously relevant to this series: <6>[ 17.353368] rockchip-drm display-subsystem: bound fdd90000.vop (ops vop2_component_ops [rockchipdrm]) <6>[ 17.355237] dwhdmiqp-rockchip fde80000.hdmi: registered DesignWare HDMI QP I2C bus driver / # <1>[ 17.357803] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098 ... <4>[ 17.372390] Hardware name: Radxa ROCK 5B (DT) ... <4>[ 17.382082] Call trace: <4>[ 17.382317] drm_bridge_connector_hdmi_cec_init+0x8/0x38 [drm_display_helper] (P) <4>[ 17.383003] drm_bridge_connector_init+0x658/0x678 [drm_display_helper] <4>[ 17.383612] dw_hdmi_qp_rockchip_bind+0x35c/0x4d8 [rockchipdrm] <4>[ 17.384159] component_bind_all+0x118/0x248 <4>[ 17.384550] rockchip_drm_bind+0xb4/0x20c [rockchipdrm] <4>[ 17.385034] try_to_bring_up_aggregate_device+0x164/0x1d0 <4>[ 17.385528] component_master_add_with_match+0xc4/0x104 <4>[ 17.386008] rockchip_drm_platform_probe+0x1f8/0x31c [rockchipdrm] (from today's -next, Unfortunately we haven't managed to point at a specific commit, it looks like this might be triggered by multiple serieses interacting with each other. I'm not sure what other information might be useful here?
Hi Mark, On 10/28/25 2:38 PM, Mark Brown wrote: > On Wed, Sep 03, 2025 at 09:50:58PM +0300, Cristian Ciocaltea wrote: >> The first patch in the series implements the CEC capability of the >> Synopsys DesignWare HDMI QP TX controller found in RK3588 & RK3576 Socs. >> This is based on the downstream code, but rewritten on top of the CEC >> helpers added recently to the DRM HDMI connector framework. > > For the past couple of weeks we've been seeing various instability with > the graphics drivers on the Rock 5B in -next, the most common system is > that we get faults in code that looks suspiciously relevant to this > series: > > <6>[ 17.353368] rockchip-drm display-subsystem: bound fdd90000.vop (ops vop2_component_ops [rockchipdrm]) > <6>[ 17.355237] dwhdmiqp-rockchip fde80000.hdmi: registered DesignWare HDMI QP I2C bus driver > / # <1>[ 17.357803] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098 > > ... > > <4>[ 17.372390] Hardware name: Radxa ROCK 5B (DT) > > ... > > <4>[ 17.382082] Call trace: > <4>[ 17.382317] drm_bridge_connector_hdmi_cec_init+0x8/0x38 [drm_display_helper] (P) > <4>[ 17.383003] drm_bridge_connector_init+0x658/0x678 [drm_display_helper] > <4>[ 17.383612] dw_hdmi_qp_rockchip_bind+0x35c/0x4d8 [rockchipdrm] > <4>[ 17.384159] component_bind_all+0x118/0x248 > <4>[ 17.384550] rockchip_drm_bind+0xb4/0x20c [rockchipdrm] > <4>[ 17.385034] try_to_bring_up_aggregate_device+0x164/0x1d0 > <4>[ 17.385528] component_master_add_with_match+0xc4/0x104 > <4>[ 17.386008] rockchip_drm_platform_probe+0x1f8/0x31c [rockchipdrm] > > (from today's -next, > > Unfortunately we haven't managed to point at a specific commit, it looks > like this might be triggered by multiple serieses interacting with each > other. I'm not sure what other information might be useful here? Thanks for reporting, I will investigate. Regards, Cristian
On 10/28/25 2:42 PM, Cristian Ciocaltea wrote: > Hi Mark, > > On 10/28/25 2:38 PM, Mark Brown wrote: >> On Wed, Sep 03, 2025 at 09:50:58PM +0300, Cristian Ciocaltea wrote: >>> The first patch in the series implements the CEC capability of the >>> Synopsys DesignWare HDMI QP TX controller found in RK3588 & RK3576 Socs. >>> This is based on the downstream code, but rewritten on top of the CEC >>> helpers added recently to the DRM HDMI connector framework. >> >> For the past couple of weeks we've been seeing various instability with >> the graphics drivers on the Rock 5B in -next, the most common system is >> that we get faults in code that looks suspiciously relevant to this >> series: >> >> <6>[ 17.353368] rockchip-drm display-subsystem: bound fdd90000.vop (ops vop2_component_ops [rockchipdrm]) >> <6>[ 17.355237] dwhdmiqp-rockchip fde80000.hdmi: registered DesignWare HDMI QP I2C bus driver >> / # <1>[ 17.357803] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098 >> >> ... >> >> <4>[ 17.372390] Hardware name: Radxa ROCK 5B (DT) >> >> ... >> >> <4>[ 17.382082] Call trace: >> <4>[ 17.382317] drm_bridge_connector_hdmi_cec_init+0x8/0x38 [drm_display_helper] (P) >> <4>[ 17.383003] drm_bridge_connector_init+0x658/0x678 [drm_display_helper] >> <4>[ 17.383612] dw_hdmi_qp_rockchip_bind+0x35c/0x4d8 [rockchipdrm] >> <4>[ 17.384159] component_bind_all+0x118/0x248 >> <4>[ 17.384550] rockchip_drm_bind+0xb4/0x20c [rockchipdrm] >> <4>[ 17.385034] try_to_bring_up_aggregate_device+0x164/0x1d0 >> <4>[ 17.385528] component_master_add_with_match+0xc4/0x104 >> <4>[ 17.386008] rockchip_drm_platform_probe+0x1f8/0x31c [rockchipdrm] >> >> (from today's -next, >> >> Unfortunately we haven't managed to point at a specific commit, it looks >> like this might be triggered by multiple serieses interacting with each >> other. I'm not sure what other information might be useful here? > > Thanks for reporting, I will investigate. This seems to have been already addressed: https://lore.kernel.org/all/20251017-drm-bridge-alloc-getput-bridge-connector-fix-hdmi_cec-v2-0-667abf6d47c0@bootlin.com/ > Regards, > Cristian
On Tue, Oct 28, 2025 at 04:57:03PM +0200, Cristian Ciocaltea wrote: > This seems to have been already addressed: > https://lore.kernel.org/all/20251017-drm-bridge-alloc-getput-bridge-connector-fix-hdmi_cec-v2-0-667abf6d47c0@bootlin.com/ Ah, good. Hopefully that lands soon, do you have any idea what's holding it up?
On 10/28/25 5:08 PM, Mark Brown wrote: > On Tue, Oct 28, 2025 at 04:57:03PM +0200, Cristian Ciocaltea wrote: > >> This seems to have been already addressed: > >> https://lore.kernel.org/all/20251017-drm-bridge-alloc-getput-bridge-connector-fix-hdmi_cec-v2-0-667abf6d47c0@bootlin.com/ > > Ah, good. Hopefully that lands soon, do you have any idea what's > holding it up? I guess it's just the complexity, since that is part of a larger work concerning DRM bridges: https://lore.kernel.org/all/20250926-drm-bridge-alloc-getput-bridge-connector-v2-1-138b4bb70576@bootlin.com/
On Tue, Oct 28, 2025 at 05:24:42PM +0200, Cristian Ciocaltea wrote: > On 10/28/25 5:08 PM, Mark Brown wrote: > > On Tue, Oct 28, 2025 at 04:57:03PM +0200, Cristian Ciocaltea wrote: > >> This seems to have been already addressed: > >> https://lore.kernel.org/all/20251017-drm-bridge-alloc-getput-bridge-connector-fix-hdmi_cec-v2-0-667abf6d47c0@bootlin.com/ > > Ah, good. Hopefully that lands soon, do you have any idea what's > > holding it up? > I guess it's just the complexity, since that is part of a larger work concerning DRM bridges: > https://lore.kernel.org/all/20250926-drm-bridge-alloc-getput-bridge-connector-v2-1-138b4bb70576@bootlin.com/ Oh dear, I'll perhaps follow up there - sometimes this breaks boot entirely depending on which way we hit the issue so at least getting the revert in would be good.
Hello Heiko,
On 9/3/25 9:50 PM, Cristian Ciocaltea wrote:
> The first patch in the series implements the CEC capability of the
> Synopsys DesignWare HDMI QP TX controller found in RK3588 & RK3576 Socs.
> This is based on the downstream code, but rewritten on top of the CEC
> helpers added recently to the DRM HDMI connector framework.
>
> The second patch is needed for RK3576 in order to fixup the timer base
> setup according to the actual reference clock rate, which differs
> slightly from RK3588.
>
> The following three patches setup platform data with the new information
> expected by the HDMI QP transmitter library, while improving the error
> handling in the probe path.
>
> Please note the CEC helpers were affected by a resource deallocation
> issue which could crash the kernel and freeze the system under certain
> test conditions. This has been already fixed in v6.17-rc1 via commit
> 19920ab98e17 ("drm/display: hdmi-cec-helper: Fix adapter
> unregistration").
>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> Changes in v4:
> - Fixed the bisect-related issues reported by Daniel by implementing
> the following operations in dw_hdmi_qp_bind():
> * Disable CEC support when the related IRQ is not available
> * Set ref_clk_rate to vendor default in case it was not provided by
> the platform driver
> * In both scenarios, also print a warning message to highlight the
> need for fixing the platform driver
> - Simplified dw_hdmi_qp_cec_init() a bit
> * Removed the now obsolete cec->irq validation test
> * Removed the superfluous error checking and logging around
> devm_request_threaded_irq() call (it already handles all that)
> - Collected R-b tags from Daniel
> - Rebased series onto next-20250903
I forgot to mention that luckily there are no conflicts with the patches
introducing the hw-specific bitfield operations in next-20250903, which this
revision is based on.
I verified the series still applies cleanly onto drm-misc-next, while commit
ad24f6e10a5f ("drm/rockchip: dw_hdmi_qp: switch to FIELD_PREP_WM16 macro")
responsible for the macro conversion can be further cherry-picked without
issues on top of all that. The resulting file content of
drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c is identical to what's
expected after applying this patch set onto next-20250903.
Regards,
Cristian
Hi,
On 9/3/25 10:52 PM, Cristian Ciocaltea wrote:
> Hello Heiko,
>
> On 9/3/25 9:50 PM, Cristian Ciocaltea wrote:
>> The first patch in the series implements the CEC capability of the
>> Synopsys DesignWare HDMI QP TX controller found in RK3588 & RK3576 Socs.
>> This is based on the downstream code, but rewritten on top of the CEC
>> helpers added recently to the DRM HDMI connector framework.
>>
>> The second patch is needed for RK3576 in order to fixup the timer base
>> setup according to the actual reference clock rate, which differs
>> slightly from RK3588.
>>
>> The following three patches setup platform data with the new information
>> expected by the HDMI QP transmitter library, while improving the error
>> handling in the probe path.
>>
>> Please note the CEC helpers were affected by a resource deallocation
>> issue which could crash the kernel and freeze the system under certain
>> test conditions. This has been already fixed in v6.17-rc1 via commit
>> 19920ab98e17 ("drm/display: hdmi-cec-helper: Fix adapter
>> unregistration").
>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>> ---
>> Changes in v4:
>> - Fixed the bisect-related issues reported by Daniel by implementing
>> the following operations in dw_hdmi_qp_bind():
>> * Disable CEC support when the related IRQ is not available
>> * Set ref_clk_rate to vendor default in case it was not provided by
>> the platform driver
>> * In both scenarios, also print a warning message to highlight the
>> need for fixing the platform driver
>> - Simplified dw_hdmi_qp_cec_init() a bit
>> * Removed the now obsolete cec->irq validation test
>> * Removed the superfluous error checking and logging around
>> devm_request_threaded_irq() call (it already handles all that)
>> - Collected R-b tags from Daniel
>> - Rebased series onto next-20250903
>
> I forgot to mention that luckily there are no conflicts with the patches
> introducing the hw-specific bitfield operations in next-20250903, which this
> revision is based on.
>
> I verified the series still applies cleanly onto drm-misc-next, while commit
> ad24f6e10a5f ("drm/rockchip: dw_hdmi_qp: switch to FIELD_PREP_WM16 macro")
> responsible for the macro conversion can be further cherry-picked without
> issues on top of all that. The resulting file content of
> drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c is identical to what's
> expected after applying this patch set onto next-20250903.
Could we get this merged, please? This would unblock some other patchsets
conflicting with it.
I've just checked and it applies cleanly on top of v6.18-rc1. Also seems to work
fine, at least I haven't noticed any regressions so far.
Thanks,
Cristian
On Wed, 03 Sep 2025 21:50:58 +0300, Cristian Ciocaltea wrote:
> The first patch in the series implements the CEC capability of the
> Synopsys DesignWare HDMI QP TX controller found in RK3588 & RK3576 Socs.
> This is based on the downstream code, but rewritten on top of the CEC
> helpers added recently to the DRM HDMI connector framework.
>
> The second patch is needed for RK3576 in order to fixup the timer base
> setup according to the actual reference clock rate, which differs
> slightly from RK3588.
>
> [...]
Applied, thanks!
[1/6] drm/bridge: dw-hdmi-qp: Add CEC support
commit: e4a2d54a2f1a9c9a1971651832c8f0ad9d3782c4
[2/6] drm/bridge: dw-hdmi-qp: Fixup timer base setup
commit: f7a1de0d86221000dc0699a8b48ad3a848e766d9
[3/6] drm/rockchip: dw_hdmi_qp: Improve error handling with dev_err_probe()
commit: b6736a4ea3fa68524074a18334f344a34a05bee8
[4/6] drm/rockchip: dw_hdmi_qp: Provide CEC IRQ in dw_hdmi_qp_plat_data
commit: 9baa02327adf2b1e919e95af23036102cfd0133f
[5/6] drm/rockchip: dw_hdmi_qp: Provide ref clock rate in dw_hdmi_qp_plat_data
commit: 33ea4d520fbda505e2cfe5b36ebf522de1f3f5e9
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
On Wed, 03 Sep 2025 21:50:58 +0300, Cristian Ciocaltea wrote:
> The first patch in the series implements the CEC capability of the
> Synopsys DesignWare HDMI QP TX controller found in RK3588 & RK3576 Socs.
> This is based on the downstream code, but rewritten on top of the CEC
> helpers added recently to the DRM HDMI connector framework.
>
> The second patch is needed for RK3576 in order to fixup the timer base
> setup according to the actual reference clock rate, which differs
> slightly from RK3588.
>
> [...]
Applied, thanks!
[6/6] arm64: defconfig: Enable DW HDMI QP CEC support
commit: ae753d769a5f63cddd483ec50067ec61eef5489d
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
© 2016 - 2026 Red Hat, Inc.