From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
To: Yashas D <y-d@ti.com>
Cc: Laurent.pinchart@ideasonboard.com, jonas@kwiboo.se,
jernej.skrabec@gmail.com, luca.ceresoli@bootlin.com,
maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, r-ravikumar@ti.com, sjakhade@cadence.com,
yamonkar@cadence.com, u-kumar1@ti.com, devarsht@ti.com,
s-jain1@ti.com, d-mittal@ti.com, b-padhi@ti.com,
andrzej.hajda@intel.com, neil.armstrong@linaro.org,
rfoss@kernel.org, airlied@gmail.com, simona@ffwll.ch,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 2/2] drm: bridge: cdns-mhdp8546: Add no-hpd property
Date: Fri, 21 Aug 2026 13:30:24 +0300 [thread overview]
Message-ID: <9e5bae91-b72f-4c71-9bea-ccafdf9747a3@ideasonboard.com> (raw)
In-Reply-To: <20260802153825.1570435-3-y-d@ti.com>
Hi,
On 02/08/2026 18:38, Yashas D wrote:
> From: Rahul T R <r-ravikumar@ti.com>
>
> Add a 'no-hpd' boolean property to support boards where the HPD line
> cannot be used for hotplug detection due to hardware limitations.
>
> On TI J721S2 EVMs, the DP0 HPD resistor is not populated from factory
> (DNI), so the HPD signal is not physically connected to SoC pin AA24
> by default which makes HPD unavailable but AA24 must be in DP0_HPD
> mux mode for the MHDP firmware to operate.
>
> When this property is set, the driver uses auxiliary channel (AUX) DPCD
> reads to detect monitor presence instead of hardware HPD signals. The
> DRM framework polls the connection status via the .detect() callback,
> providing hotplug detection without requiring the HPD pin.
>
> Valid use cases:
> - HPD pin not routed to connector on PCB
> - HPD signal muxed with another function on SoC
> - Hardware designs where HPD cannot reliably detect monitor presence
>
> Signed-off-by: Rahul T R <r-ravikumar@ti.com>
> Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
> Signed-off-by: Harikrishna Shenoy <h-shenoy@ti.com>
> Signed-off-by: Yashas D <y-d@ti.com>
> ---
> .../drm/bridge/cadence/cdns-mhdp8546-core.c | 79 +++++++++++++++++--
> .../drm/bridge/cadence/cdns-mhdp8546-core.h | 1 +
> 2 files changed, 72 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> index 504a3186ebb3..ae9bbec855f3 100644
> --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> @@ -53,6 +53,8 @@
> #include "cdns-mhdp8546-hdcp.h"
> #include "cdns-mhdp8546-j721e.h"
>
> +static int cdns_mhdp_update_link_status(struct cdns_mhdp_device *mhdp);
> +
> static void cdns_mhdp_bridge_hpd_enable(struct drm_bridge *bridge)
> {
> struct cdns_mhdp_device *mhdp = bridge_to_mhdp(bridge);
> @@ -698,7 +700,9 @@ static int cdns_mhdp_fw_activate(const struct firmware *fw,
> * MHDP_HW_STOPPED happens only due to driver removal when
> * bridge should already be detached.
> */
> - cdns_mhdp_bridge_hpd_enable(&mhdp->bridge);
> +
> + if (!mhdp->no_hpd)
> + cdns_mhdp_bridge_hpd_enable(&mhdp->bridge);
>
> spin_unlock(&mhdp->start_lock);
>
> @@ -739,7 +743,13 @@ static void cdns_mhdp_fw_cb(const struct firmware *fw, void *context)
> spin_lock(&mhdp->start_lock);
> bridge_attached = mhdp->bridge_attached;
> spin_unlock(&mhdp->start_lock);
> - if (bridge_attached)
> +
> + if (!bridge_attached)
> + return;
> +
> + if (mhdp->no_hpd)
> + cdns_mhdp_update_link_status(mhdp);
> + else
> drm_bridge_hpd_notify(&mhdp->bridge, cdns_mhdp_detect(mhdp));
> }
>
> @@ -788,9 +798,14 @@ static ssize_t cdns_mhdp_transfer(struct drm_dp_aux *aux,
> ret = cdns_mhdp_dpcd_read(mhdp, msg->address,
> msg->buffer, msg->size);
> if (ret) {
> - dev_dbg(mhdp->dev,
> - "Failed to read DPCD addr %u\n",
> - msg->address);
> + if (mhdp->no_hpd)
> + dev_dbg(mhdp->dev,
> + "Failed to read DPCD addr %u\n",
> + msg->address);
> + else
> + dev_err(mhdp->dev,
> + "Failed to read DPCD addr %u\n",
> + msg->address);
Is this intentional? Earlier dev_dbg was used. Now the "normal" case is
dev_err. I think we can keep it as dev_dbg.
Tomi
next prev parent reply other threads:[~2026-08-21 10:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-02 15:38 [PATCH v6 0/2] Add no-hpd property to the cadence bridge Yashas D
2026-08-02 15:38 ` [PATCH v6 1/2] dt-bindings: display: bridge: cdns,mhdp8546: " Yashas D
2026-08-03 6:43 ` Krzysztof Kozlowski
2026-08-02 15:38 ` [PATCH v6 2/2] drm: bridge: cdns-mhdp8546: Add no-hpd property Yashas D
2026-08-21 10:30 ` Tomi Valkeinen [this message]
2026-09-07 8:04 ` Yashas D
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9e5bae91-b72f-4c71-9bea-ccafdf9747a3@ideasonboard.com \
--to=tomi.valkeinen@ideasonboard.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=airlied@gmail.com \
--cc=andrzej.hajda@intel.com \
--cc=b-padhi@ti.com \
--cc=conor+dt@kernel.org \
--cc=d-mittal@ti.com \
--cc=devarsht@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luca.ceresoli@bootlin.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=r-ravikumar@ti.com \
--cc=rfoss@kernel.org \
--cc=robh@kernel.org \
--cc=s-jain1@ti.com \
--cc=simona@ffwll.ch \
--cc=sjakhade@cadence.com \
--cc=tzimmermann@suse.de \
--cc=u-kumar1@ti.com \
--cc=y-d@ti.com \
--cc=yamonkar@cadence.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®