Add HDMI for Gameforce Ace
Subsystems (6)
v2 cover Add HDMI for Gameforce Ace
From: Chris Morgan <[email protected]>
Add support for the micro HDMI port for the Gameforce Ace. This port does not have a HPD pin so it requires making changes to the HDMI controller to support this configuration.
Changes since v1:
- Simplified checking of no-hpd parameter and changed to device_property_read_bool() function.
Chris Morgan (3):
dt-bindings: display: rockchip: Add no-hpd for dw-hdmi-qp controller drm/bridge: dw-hdmi-qp: Add support for missing HPD
arm64: dts: rockchip: Add HDMI to Gameforce Ace
.../rockchip/rockchip,rk3588-dw-hdmi-qp.yaml | 6 ++ .../dts/rockchip/rk3588s-gameforce-ace.dts | 63 +++++++++++++++++++ drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 32 ++++++++-- 3 files changed, 97 insertions(+), 4 deletions(-)
Signature · 1 line
2.43.0
PATCH v2 1/3 dt-bindings: display: rockchip: Add no-hpd for dw-hdmi-qp controller
From: Chris Morgan <[email protected]>
Add an attribute of "no-hpd" for the Rockchip dw-hdmi-qp controller. This is used to describe implementations where the HPD pin is not connected or used for other purposes, such as in the RK3588S based Gameforce Ace which repurposed the GPIO for an additional face button.
The "no-hpd" option was chosen to be consistent with other devices which already define this parameter for broken or missing hpd functionality.
--- .../display/rockchip/rockchip,rk3588-dw-hdmi-qp.yaml | 6 ++++++ 1 file changed, 6 insertions(+)
Documentation/devicetree/bindings/display/rockchip/rockchip,rk3588-dw-hdmi-qp.yaml +6 -0
@@ -69,6 +69,12 @@ properties: - const: main - const: hpd + no-hpd: + type: boolean + description: + The HPD pin is not present or used for another purpose, and the EDID + must be polled instead to determine if a device is attached. + phys: maxItems: 1 description: The HDMI/eDP PHY
Signature · 1 line
2.43.0
PATCH v2 2/3 drm/bridge: dw-hdmi-qp: Add support for missing HPD
In reply to Chris MorganFrom: Chris Morgan <[email protected]>
Add support for the dw-hdmi-qp driver to handle devices with missing HPD pins.
Since in this situation we are now polling for the EDID data via i2c change the error message to a debug message when we are unable to complete an i2c read, as a disconnected device would otherwise fill dmesg with i2c read errors.
--- drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 32 +++++++++++++++++--- 1 file changed, 28 insertions(+), 4 deletions(-)
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c +28 -4
@@ -145,6 +145,7 @@ struct dw_hdmi_qp {struct regmap *regm;unsigned long tmds_char_rate; +bool no_hpd; }; static void dw_hdmi_qp_write(struct dw_hdmi_qp *hdmi, unsigned int val,
@@ -520,6 +521,11 @@ static int dw_hdmi_qp_i2c_read(struct dw_hdmi_qp *hdmi, i2c->is_regaddr = true; } +/* +* Mark errors as debug messages when using no_hpd so no device +* attached does not fill up dmesg. +*/ +while (length--) {reinit_completion (&i2c->cmp);
@@ -535,14 +541,20 @@ static int dw_hdmi_qp_i2c_read(struct dw_hdmi_qp *hdmi, stat =wait_for_completion_timeout (&i2c->cmp,HZ /10 );if (!stat) { -dev_err (hdmi->dev,"i2c read timed out\n" ); +if (hdmi->no_hpd) +dev_dbg (hdmi->dev,"i2c read timed out\n" ); +else +dev_err (hdmi->dev,"i2c read timed out\n" );dw_hdmi_qp_write (hdmi,0x01 ,I2CM_CONTROL0 );return -EAGAIN ; }/* Check for error condition on the bus */ if (i2c->stat &I2CM_NACK_RCVD_IRQ ) { -dev_err (hdmi->dev,"i2c read error\n" ); +if (hdmi->no_hpd) +dev_dbg (hdmi->dev,"i2c read error\n" ); +else +dev_err (hdmi->dev,"i2c read error\n" );dw_hdmi_qp_write (hdmi,0x01 ,I2CM_CONTROL0 );return -EIO ; }
@@ -879,6 +891,15 @@ static enum drm_connector_status dw_hdmi_qp_bridge_detect(struct drm_bridge *bridge, struct drm_connector *connector) { struct dw_hdmi_qp *hdmi = bridge->driver_private; +const struct drm_edid *drm_edid; + +if (hdmi->no_hpd) { + drm_edid =drm_edid_read_ddc (connector, bridge->ddc); +if (drm_edid) +return connector_status_connected; +else +return connector_status_disconnected; + }return hdmi->phy.ops->read_hpd (hdmi, hdmi->phy.data); }
@@ -1074,12 +1095,15 @@ struct dw_hdmi_qp *dw_hdmi_qp_bind(struct platform_device *pdev,if (ret)return ERR_PTR (ret); + hdmi->no_hpd =device_property_read_bool (dev,"no-hpd" ); + hdmi->bridge.driver_private = hdmi; hdmi->bridge.ops =DRM_BRIDGE_OP_DETECT |DRM_BRIDGE_OP_EDID |DRM_BRIDGE_OP_HDMI | -DRM_BRIDGE_OP_HDMI_AUDIO | -DRM_BRIDGE_OP_HPD ; +DRM_BRIDGE_OP_HDMI_AUDIO ; +if (!hdmi->no_hpd) + hdmi->bridge.ops |=DRM_BRIDGE_OP_HPD ; hdmi->bridge.of_node = pdev->dev.of_node; hdmi->bridge.type =DRM_MODE_CONNECTOR_HDMIA ; hdmi->bridge.vendor ="Synopsys" ;
Signature · 1 line
2.43.0
Re: [PATCH v2 2/3] drm/bridge: dw-hdmi-qp: Add support for missing HPD
Quoted 28 lines · Chris Morgan
From: Chris Morgan <[email protected]>
Add support for the dw-hdmi-qp driver to handle devices with missing HPD pins.
Since in this situation we are now polling for the EDID data via i2c change the error message to a debug message when we are unable to complete an i2c read, as a disconnected device would otherwise fill dmesg with i2c read errors.
Signed-off-by Chris Morgan <[email protected]>--- drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 32 +++++++++++++++++--- 1 file changed, 28 insertions(+), 4 deletions(-)drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c +1
-0@@ -145,6 +145,7 @@ struct dw_hdmi_qp {struct regmap *regm;unsigned long tmds_char_rate; +bool no_hpd; }; static void dw_hdmi_qp_write(struct dw_hdmi_qp *hdmi, unsigned int val,
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c static int dw_hdmi_qp_i2c_read(struct dw_hdmi_qp *hdmi, · line 528
Quoted 8 lines
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c +5
-0@@ -520,6 +521,11 @@ static int dw_hdmi_qp_i2c_read(struct dw_hdmi_qp *hdmi, i2c->is_regaddr = true; } +/* +* Mark errors as debug messages when using no_hpd so no device +* attached does not fill up dmesg. +*/ +
Using the *_ratelimited() variant - see below - would make this comment kind of redundant. Moreover, you've already explained the rationale behind the change in the commit description. Hence I'd rather drop it.
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c static int dw_hdmi_qp_i2c_read(struct dw_hdmi_qp *hdmi, · line 545
Quoted 10 lines
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c +2
-1while (length--) {reinit_completion (&i2c->cmp);@@ -535,14 +541,20 @@ static int dw_hdmi_qp_i2c_read(struct dw_hdmi_qp *hdmi, stat =wait_for_completion_timeout (&i2c->cmp,HZ /10 );if (!stat) { -dev_err (hdmi->dev,"i2c read timed out\n" ); +if (hdmi->no_hpd) +dev_dbg (hdmi->dev,"i2c read timed out\n" );
I think it's worth switching to dev_dbg_ratelimited() in this case.
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c static int dw_hdmi_qp_i2c_read(struct dw_hdmi_qp *hdmi, · line 555
Quoted 11 lines
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c +4
-1+else +dev_err (hdmi->dev,"i2c read timed out\n" );dw_hdmi_qp_write (hdmi,0x01 ,I2CM_CONTROL0 );return -EAGAIN ; }/* Check for error condition on the bus */ if (i2c->stat &I2CM_NACK_RCVD_IRQ ) { -dev_err (hdmi->dev,"i2c read error\n" ); +if (hdmi->no_hpd) +dev_dbg (hdmi->dev,"i2c read error\n" );
Same here.
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c static int dw_hdmi_qp_i2c_read(struct dw_hdmi_qp *hdmi, · line 560
Quoted 5 lines
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c +2
-0+else +dev_err (hdmi->dev,"i2c read error\n" );dw_hdmi_qp_write (hdmi,0x01 ,I2CM_CONTROL0 );return -EIO ; }
[...]
Regardless,
Maxime Ripard
maintainerRe: [PATCH v2 2/3] drm/bridge: dw-hdmi-qp: Add support for missing HPD
In reply to Chris MorganHi,
Quoted 11 lines · Chris Morgan
From: Chris Morgan <[email protected]>
Add support for the dw-hdmi-qp driver to handle devices with missing HPD pins.
Since in this situation we are now polling for the EDID data via i2c change the error message to a debug message when we are unable to complete an i2c read, as a disconnected device would otherwise fill dmesg with i2c read errors.
Signed-off-by Chris Morgan <[email protected]>
You must also disable any mode using the scrambler when there's no hotplug interrupt available.
Maxime
Re: [PATCH v2 2/3] drm/bridge: dw-hdmi-qp: Add support for missing HPD
Quoted 13 lines · Maxime Ripard
Hi,
Quoted 10 lines · Chris Morgan
From: Chris Morgan <[email protected]>
Add support for the dw-hdmi-qp driver to handle devices with missing HPD pins.
Since in this situation we are now polling for the EDID data via i2c change the error message to a debug message when we are unable to complete an i2c read, as a disconnected device would otherwise fill dmesg with i2c read errors.
Quoted 4 lines
Quoted 1 line
Signed-off-by Chris Morgan <[email protected]>You must also disable any mode using the scrambler when there's no hotplug interrupt available.
Is there a simple way to do that? I'm not seeing any references to scrambling in the current driver.
Should I just limit the rate to HDMI14_MAX_TMDSCLK (340000000) under dw_hdmi_qp_bridge_tmds_char_rate_valid() if using EDID polling? A document I found online from Synopsys [1] claims that scrambling is used by default at rates above 340 (if I'm reading it right) and used opportunistically at rates below 340.
Thank you,
Chris
[1] https://www.synopsys.com/blogs/chip-design/hdmi-scrambling-higher-data-rates.html
Quoted 2 lines
Maxime
Maxime Ripard
maintainerRe: [PATCH v2 2/3] drm/bridge: dw-hdmi-qp: Add support for missing HPD
Quoted 19 lines · Chris Morgan
Quoted 13 lines · Maxime Ripard
Hi,
Quoted 10 lines · Chris Morgan
From: Chris Morgan <[email protected]>
Add support for the dw-hdmi-qp driver to handle devices with missing HPD pins.
Since in this situation we are now polling for the EDID data via i2c change the error message to a debug message when we are unable to complete an i2c read, as a disconnected device would otherwise fill dmesg with i2c read errors.
Quoted 4 lines
Quoted 1 line
Signed-off-by Chris Morgan <[email protected]>You must also disable any mode using the scrambler when there's no hotplug interrupt available.
Quoted 8 lines
Is there a simple way to do that? I'm not seeing any references to scrambling in the current driver.
Should I just limit the rate to
HDMI14_MAX_TMDSCLK(340000000) underdw_hdmi_qp_bridge_tmds_char_rate_valid()if using EDID polling? A document I found online from Synopsys [1] claims that scrambling is used by default at rates above 340 (if I'm reading it right) and used opportunistically at rates below 340.
Yep, that's what you should be testing for :)
Maxime
Re: [PATCH v2 2/3] drm/bridge: dw-hdmi-qp: Add support for missing HPD
Quoted 29 lines · Maxime Ripard
Quoted 19 lines · Chris Morgan
Quoted 13 lines · Maxime Ripard
Hi,
Quoted 10 lines · Chris Morgan
From: Chris Morgan <[email protected]>
Add support for the dw-hdmi-qp driver to handle devices with missing HPD pins.
Since in this situation we are now polling for the EDID data via i2c change the error message to a debug message when we are unable to complete an i2c read, as a disconnected device would otherwise fill dmesg with i2c read errors.
Quoted 4 lines
Quoted 1 line
Signed-off-by Chris Morgan <[email protected]>You must also disable any mode using the scrambler when there's no hotplug interrupt available.
Quoted 8 lines
Is there a simple way to do that? I'm not seeing any references to scrambling in the current driver.
Should I just limit the rate to
HDMI14_MAX_TMDSCLK(340000000) underdw_hdmi_qp_bridge_tmds_char_rate_valid()if using EDID polling? A document I found online from Synopsys [1] claims that scrambling is used by default at rates above 340 (if I'm reading it right) and used opportunistically at rates below 340.
Quoted 3 lines
Yep, that's what you should be testing for :)
Maxime
Thanks, though now that I dig into it I'm a bit more confused on the best way forward. It looks like for today the driver is hard-limited to HDMI14_MAX_TMDSCLK because scrambling isn't supported. I'm assuming it will be at some point, suggesting that we *will* need this in the future. Is it sufficient to just add a comment there noting we need to check, or should I add a check there (that does nothing today) to ensure when we do support faster rates we are ready?
Thank you,
Chris
Re: [PATCH v2 2/3] drm/bridge: dw-hdmi-qp: Add support for missing HPD
Quoted 34 lines · Chris Morgan
Quoted 29 lines · Maxime Ripard
Quoted 19 lines · Chris Morgan
Quoted 13 lines · Maxime Ripard
Hi,
Quoted 10 lines · Chris Morgan
From: Chris Morgan <[email protected]>
Add support for the dw-hdmi-qp driver to handle devices with missing HPD pins.
Since in this situation we are now polling for the EDID data via i2c change the error message to a debug message when we are unable to complete an i2c read, as a disconnected device would otherwise fill dmesg with i2c read errors.
Quoted 4 lines
Quoted 1 line
Signed-off-by Chris Morgan <[email protected]>You must also disable any mode using the scrambler when there's no hotplug interrupt available.
Quoted 8 lines
Is there a simple way to do that? I'm not seeing any references to scrambling in the current driver.
Should I just limit the rate to
HDMI14_MAX_TMDSCLK(340000000) underdw_hdmi_qp_bridge_tmds_char_rate_valid()if using EDID polling? A document I found online from Synopsys [1] claims that scrambling is used by default at rates above 340 (if I'm reading it right) and used opportunistically at rates below 340.Quoted 3 lines
Yep, that's what you should be testing for :)
Maxime
Quoted 7 lines
Thanks, though now that I dig into it I'm a bit more confused on the best way forward. It looks like for today the driver is hard-limited to
HDMI14_MAX_TMDSCLKbecause scrambling isn't supported. I'm assuming it will be at some point, suggesting that we *will* need this in the future. Is it sufficient to just add a comment there noting we need to check, or should I add a check there (that does nothing today) to ensure when we do support faster rates we are ready?
I plan to work on upstreaming the scrambling support soon. Adding a TODO comment would be enough for me to take care of the rest, but I'll still need your help to get that tested, though. :-)
Cristian
Re: [PATCH v2 2/3] drm/bridge: dw-hdmi-qp: Add support for missing HPD
Quoted 43 lines · Cristian Ciocaltea
Quoted 34 lines · Chris Morgan
Quoted 29 lines · Maxime Ripard
Quoted 19 lines · Chris Morgan
Quoted 13 lines · Maxime Ripard
Hi,
Quoted 10 lines · Chris Morgan
From: Chris Morgan <[email protected]>
Add support for the dw-hdmi-qp driver to handle devices with missing HPD pins.
Since in this situation we are now polling for the EDID data via i2c change the error message to a debug message when we are unable to complete an i2c read, as a disconnected device would otherwise fill dmesg with i2c read errors.
Quoted 4 lines
Quoted 1 line
Signed-off-by Chris Morgan <[email protected]>You must also disable any mode using the scrambler when there's no hotplug interrupt available.
Quoted 8 lines
Is there a simple way to do that? I'm not seeing any references to scrambling in the current driver.
Should I just limit the rate to
HDMI14_MAX_TMDSCLK(340000000) underdw_hdmi_qp_bridge_tmds_char_rate_valid()if using EDID polling? A document I found online from Synopsys [1] claims that scrambling is used by default at rates above 340 (if I'm reading it right) and used opportunistically at rates below 340.Quoted 3 lines
Yep, that's what you should be testing for :)
Maxime
Quoted 7 lines
Thanks, though now that I dig into it I'm a bit more confused on the best way forward. It looks like for today the driver is hard-limited to
HDMI14_MAX_TMDSCLKbecause scrambling isn't supported. I'm assuming it will be at some point, suggesting that we *will* need this in the future. Is it sufficient to just add a comment there noting we need to check, or should I add a check there (that does nothing today) to ensure when we do support faster rates we are ready?
Quoted 5 lines
I plan to work on upstreaming the scrambling support soon. Adding a TODO comment would be enough for me to take care of the rest, but I'll still need your help to get that tested, though. :-)
Cristian
Okay, I'll add a TODO there to make sure that we put in special handling for when we have scrambling enabled, then when you have patches ready I can test it.
Thank you,
Chris
PATCH v2 3/3 arm64: dts: rockchip: Add HDMI to Gameforce Ace
In reply to Chris MorganFrom: Chris Morgan <[email protected]>
Add support for the HDMI port for the Gameforce Ace. The HDMI port has no HPD pin present (the manufacturer's devicetree states the pin is reused for an additional face button) so add the attribute of no-hpd to poll for connected devices.
--- .../dts/rockchip/rk3588s-gameforce-ace.dts | 63 +++++++++++++++++++ 1 file changed, 63 insertions(+)
arch/arm64/boot/dts/rockchip/rk3588s-gameforce-ace.dts +63 -0
@@ -300,6 +300,20 @@ amp_headphone: headphone-amplifier { sound-name-prefix = "Headphones Amplifier"; }; + hdmi0-con { + compatible = "hdmi-connector"; + ddc-en-gpios = <&gpio4 RK_PB3 GPIO_ACTIVE_HIGH>; + pinctrl-0 = <&hdmi0_en>; + pinctrl-names = "default"; + type = "d"; + + port { + hdmi0_con_in: endpoint { + remote-endpoint = <&hdmi0_out_con>; + }; + }; + }; + pwm_fan: pwm-fan { compatible = "pwm-fan"; #cooling-cells = <2>;
@@ -498,6 +512,34 @@ &gpu { status = "okay"; }; +&hdmi0 { + no-hpd; + pinctrl-0 = <&hdmim0_tx0_cec>, <&hdmim0_tx0_scl>, + <&hdmim0_tx0_sda>; + pinctrl-names = "default"; + status = "okay"; +}; + +&hdmi0_in { + hdmi0_in_vp0: endpoint { + remote-endpoint = <&vp0_out_hdmi0>; + }; +}; + +&hdmi0_out { + hdmi0_out_con: endpoint { + remote-endpoint = <&hdmi0_con_in>; + }; +}; + +&hdmi0_sound { + status = "okay"; +}; + +&hdptxphy0 { + status = "okay"; +}; + &i2c0 { pinctrl-0 = <&i2c0m2_xfer>; pinctrl-names = "default";
@@ -746,6 +788,10 @@ &i2s0_sdi0 status = "okay"; }; +&i2s5_8ch { + status = "okay"; +}; + &mipidcphy0 { status = "okay"; };
@@ -842,6 +888,13 @@ charger_int_h: charger-int-h { }; }; + hdmi { + hdmi0_en: hdmi0-en { + rockchip,pins = + <4 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>; + }; + }; + hym8563 { hym8563_int: hym8563-int { rockchip,pins =
@@ -1416,6 +1469,16 @@ &vop_mmu { status = "okay"; }; +&vp0 { + #address-cells = <1>; + #size-cells = <0>; + + vp0_out_hdmi0: endpoint@ROCKCHIP_VOP2_EP_HDMI0 { + reg = <ROCKCHIP_VOP2_EP_HDMI0>; + remote-endpoint = <&hdmi0_in_vp0>; + }; +}; + &vp3 { #address-cells = <1>; #size-cells = <0>;
Signature · 1 line
2.43.0