public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: "Luca Ceresoli" <luca.ceresoli@bootlin.com>
To: "Cristian Ciocaltea" <cristian.ciocaltea@collabora.com>,
	"Andrzej Hajda" <andrzej.hajda@intel.com>,
	"Neil Armstrong" <neil.armstrong@linaro.org>,
	"Robert Foss" <rfoss@kernel.org>,
	"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
	"Jonas Karlman" <jonas@kwiboo.se>,
	"Jernej Skrabec" <jernej.skrabec@gmail.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Sandy Huang" <hjc@rock-chips.com>,
	"Heiko Stübner" <heiko@sntech.de>,
	"Andy Yan" <andy.yan@rock-chips.com>
Cc: <kernel@collabora.com>, <dri-devel@lists.freedesktop.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-rockchip@lists.infradead.org>,
	"Diederik de Haas" <diederik@cknow-tech.com>,
	"Maud Spierings" <maud_spierings@hotmail.com>
Subject: Re: [PATCH v2 1/4] drm/bridge: Add ->detect_ctx hook and drm_bridge_detect_ctx()
Date: Wed, 14 Jan 2026 11:08:20 +0100	[thread overview]
Message-ID: <DFO89S1NDME1.1644YSMOMAAJ6@bootlin.com> (raw)
In-Reply-To: <20260113-dw-hdmi-qp-scramb-v2-1-ae7b2c58d24d@collabora.com>

Hello Cristian,

On Mon Jan 12, 2026 at 11:26 PM CET, Cristian Ciocaltea wrote:
> Add an atomic variant of the ->detect callback and a new helper to call
> the hook while passing an optional drm_modeset_acquire_ctx reference.
>
> When both ->detect_ctx and ->detect are defined, the latter is ignored.
> If acquire_ctx is unset, the function takes care of the locking,
> while also handling EDEADLK.
>
> Tested-by: Diederik de Haas <diederik@cknow-tech.com>
> Tested-by: Maud Spierings <maud_spierings@hotmail.com>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
>  drivers/gpu/drm/drm_bridge.c | 58 ++++++++++++++++++++++++++++++++++++++++++++
>  include/drm/drm_bridge.h     | 30 +++++++++++++++++++++++
>  2 files changed, 88 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 6dcf8f6d3ecf..0ef12bf98011 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -1344,6 +1344,64 @@ drm_bridge_detect(struct drm_bridge *bridge, struct drm_connector *connector)
>  }
>  EXPORT_SYMBOL_GPL(drm_bridge_detect);
>
> +/**
> + * drm_bridge_detect_ctx - check if anything is attached to the bridge output
> + * @bridge: bridge control structure
> + * @connector: attached connector
> + * @ctx: acquire_ctx, or NULL to let this function handle locking
> + *
> + * If the bridge supports output detection, as reported by the
> + * DRM_BRIDGE_OP_DETECT bridge ops flag, call &drm_bridge_funcs.detect_ctx
> + * or &drm_bridge_funcs.detect for the bridge and return the connection status.
> + * Otherwise return connector_status_unknown.
> + *
> + * When both @ctx and &drm_bridge_funcs.detect_ctx are not set, this helper
> + * function is equivalent to drm_bridge_detect() above.
> + *
> + * RETURNS:
> + * The detection status on success, or connector_status_unknown if the bridge
> + * doesn't support output detection.
> + * If @ctx is set, it might also return -EDEADLK.
> + */
> +int drm_bridge_detect_ctx(struct drm_bridge *bridge,
> +			  struct drm_connector *connector,
> +			  struct drm_modeset_acquire_ctx *ctx)

Shouldn't this new function return the same type as detect, i.e. enum
drm_connector_status?

Otherwise (see below)...

> +{
> +	if (!(bridge->ops & DRM_BRIDGE_OP_DETECT))
> +		return connector_status_unknown;
> +
> +	if (bridge->funcs->detect_ctx) {
> +		struct drm_modeset_acquire_ctx br_ctx;
> +		int ret;
> +
> +		if (ctx)
> +			return bridge->funcs->detect_ctx(bridge, connector, ctx);
> +
> +		drm_modeset_acquire_init(&br_ctx, 0);
> +retry:
> +		ret = drm_modeset_lock(&connector->dev->mode_config.connection_mutex,
> +				       &br_ctx);
> +		if (!ret)
> +			ret = bridge->funcs->detect_ctx(bridge, connector, &br_ctx);
> +
> +		if (ret == -EDEADLK) {
> +			drm_modeset_backoff(&br_ctx);
> +			goto retry;
> +		}
> +
> +		if (ret < 0)
> +			ret = connector_status_unknown;
> +
> +		drm_modeset_drop_locks(&br_ctx);
> +		drm_modeset_acquire_fini(&br_ctx);
> +
> +		return ret;
> +	}
> +
> +	return bridge->funcs->detect(bridge, connector);

...here you're converting an enum into an int, which is ok-isk but not
ideal.

> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -664,6 +664,33 @@ struct drm_bridge_funcs {
>  	enum drm_connector_status (*detect)(struct drm_bridge *bridge,
>  					    struct drm_connector *connector);
>
> +	/**
> +	 * @detect_ctx:
> +	 *
> +	 * Check if anything is attached to the bridge output.
> +	 *
> +	 * This callback is optional, if not implemented the bridge will be
> +	 * considered as always having a component attached to its output.
> +	 * Bridges that implement this callback shall set the
> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> +	 *
> +	 * This is the atomic version of &drm_bridge_funcs.detect.

I may be missing something, but I'm a bit puzzled by the "atomic" word
here. For other funcs in this struct there's the old non-atomic func X and
the new atomic_X func that receives a pointer to struct drm_atomic_state.

Here I think you are using "atomic" with a more generic meaning. Maybe we'd
better use another wording to not confuse readers?

> +	 *
> +	 * To avoid races against concurrent connector state updates, the
> +	 * helper libraries always call this with ctx set to a valid context,
> +	 * and &drm_mode_config.connection_mutex will always be locked with
> +	 * the ctx parameter set to this ctx. This allows taking additional
> +	 * locks as required.
> +	 *
> +	 * RETURNS:
> +	 *
> +	 * &drm_connector_status indicating the bridge output status,
> +	 * or the error code returned by drm_modeset_lock(), -EDEADLK.
> +	 */
> +	int (*detect_ctx)(struct drm_bridge *bridge,
> +			  struct drm_connector *connector,
> +			  struct drm_modeset_acquire_ctx *ctx);

As above, shouldn't this new func return the same type as detect?

Best regards,
Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


  reply	other threads:[~2026-01-14 10:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-12 22:26 [PATCH v2 0/4] Add HDMI 2.0 support to DW HDMI QP TX Cristian Ciocaltea
2026-01-12 22:26 ` [PATCH v2 1/4] drm/bridge: Add ->detect_ctx hook and drm_bridge_detect_ctx() Cristian Ciocaltea
2026-01-14 10:08   ` Luca Ceresoli [this message]
2026-01-14 23:04     ` Cristian Ciocaltea
2026-01-12 22:26 ` [PATCH v2 2/4] drm/bridge-connector: Switch to using ->detect_ctx hook Cristian Ciocaltea
2026-01-12 22:26 ` [PATCH v2 3/4] drm/bridge: dw-hdmi-qp: Add high TMDS clock ratio and scrambling support Cristian Ciocaltea
2026-01-13 15:00   ` Maxime Ripard
2026-01-13 15:10     ` Cristian Ciocaltea
2026-01-12 22:26 ` [PATCH v2 4/4] drm/rockchip: dw_hdmi_qp: Do not send HPD events for all connectors Cristian Ciocaltea
2026-01-12 22:40 ` [PATCH v2 0/4] Add HDMI 2.0 support to DW HDMI QP TX Cristian Ciocaltea
2026-01-14 16:16   ` Chris Morgan

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=DFO89S1NDME1.1644YSMOMAAJ6@bootlin.com \
    --to=luca.ceresoli@bootlin.com \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=airlied@gmail.com \
    --cc=andrzej.hajda@intel.com \
    --cc=andy.yan@rock-chips.com \
    --cc=cristian.ciocaltea@collabora.com \
    --cc=diederik@cknow-tech.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=heiko@sntech.de \
    --cc=hjc@rock-chips.com \
    --cc=jernej.skrabec@gmail.com \
    --cc=jonas@kwiboo.se \
    --cc=kernel@collabora.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=maud_spierings@hotmail.com \
    --cc=mripard@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=rfoss@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    /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