mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
To: Harikrishna Shenoy <h-shenoy@ti.com>
Cc: jonas@kwiboo.se, jernej.skrabec@gmail.com,
	maarten.lankhorst@linux.intel.com, tzimmermann@suse.de,
	airlied@gmail.com, simona@ffwll.ch, lyude@redhat.com,
	luca.ceresoli@bootlin.com, viro@zeniv.linux.org.uk,
	andy.yan@rock-chips.com, linux@treblig.org, javierm@redhat.com,
	linux-kernel@vger.kernel.org, devarsht@ti.com,
	j-choudhary@ti.com, u-kumar1@ti.com, s-jain1@ti.com,
	andrzej.hajda@intel.com, neil.armstrong@linaro.org,
	rfoss@kernel.org, Laurent.pinchart@ideasonboard.com,
	mripard@kernel.org, lumag@kernel.org, dianders@chromium.org,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v5 6/6] drm/bridge: cadence: cdns-mhdp8546-core: Handle HDCP state in bridge atomic check
Date: Mon, 1 Sep 2025 13:18:42 +0300	[thread overview]
Message-ID: <4e7fb22e-8b15-46e5-906b-9b2aa65f2911@ideasonboard.com> (raw)
In-Reply-To: <20250811075904.1613519-7-h-shenoy@ti.com>

Hi,

On 11/08/2025 10:59, Harikrishna Shenoy wrote:
> Now that we have DBANC framework and legacy connector functions removed,
> handle the HDCP disabling in bridge atomic check rather than in connector
> atomic check previously.

Both this and the patch 4 make me feel a bit confused: In patch 1 a
bunch of code is removed. Then in patches 4 and 6 we add it back. Yes,
we don't add it back the same way, but this raises the question if the
first patch then breaks these two features, until patches 4 and 6 add it
back.

Or is the case that with DRM_BRIDGE_ATTACH_NO_CONNECTOR, which is the
way tidss uses this, none of the code removed in patch 1 was even being
called? And thus, in theory, patches 4 and 6 could even be added before
patch 1?

The patches nor the cover letter really explain well what's going on
here. The "fixes" tags also confuse me. So is the current upstream
driver working fine or not? Are there bugs? It would be good to fix
those bugs first, then do the cleanup of removing the old code. Maybe
that's difficult to do and this patch order makes sense, but it's all
left very unclear to the reviewer.

 Tomi

> 
> Signed-off-by: Harikrishna Shenoy <h-shenoy@ti.com>
> ---
>  .../drm/bridge/cadence/cdns-mhdp8546-core.c   | 23 +++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> index 4fb1db3e030c..af41b2908a74 100644
> --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> @@ -1960,6 +1960,10 @@ static int cdns_mhdp_atomic_check(struct drm_bridge *bridge,
>  {
>  	struct cdns_mhdp_device *mhdp = bridge_to_mhdp(bridge);
>  	const struct drm_display_mode *mode = &crtc_state->adjusted_mode;
> +	struct drm_connector_state *old_state, *new_state;
> +	struct drm_atomic_state *state = crtc_state->state;
> +	struct drm_connector *conn = mhdp->connector;
> +	u64 old_cp, new_cp;
>  
>  	mutex_lock(&mhdp->link_mutex);
>  
> @@ -1979,6 +1983,25 @@ static int cdns_mhdp_atomic_check(struct drm_bridge *bridge,
>  	if (mhdp->info)
>  		bridge_state->input_bus_cfg.flags = *mhdp->info->input_bus_flags;
>  
> +	if (conn && mhdp->hdcp_supported) {
> +		old_state = drm_atomic_get_old_connector_state(state, conn);
> +		new_state = drm_atomic_get_new_connector_state(state, conn);
> +		old_cp = old_state->content_protection;
> +		new_cp = new_state->content_protection;
> +
> +		if (old_state->hdcp_content_type != new_state->hdcp_content_type &&
> +		    new_cp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
> +			new_state->content_protection = DRM_MODE_CONTENT_PROTECTION_DESIRED;
> +			crtc_state = drm_atomic_get_new_crtc_state(state, new_state->crtc);
> +			crtc_state->mode_changed = true;
> +		}
> +
> +		if (!new_state->crtc) {
> +			if (old_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED)
> +				new_state->content_protection = DRM_MODE_CONTENT_PROTECTION_DESIRED;
> +		}
> +	}
> +
>  	mutex_unlock(&mhdp->link_mutex);
>  	return 0;
>  }


  reply	other threads:[~2025-09-01 10:18 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-11  7:58 [PATCH v5 0/6] MHDP8546 fixes related to DBANC usecase Harikrishna Shenoy
2025-08-11  7:58 ` [PATCH v5 1/6] drm/bridge: cadence: cdns-mhdp8546-core: Remove legacy support for connector initialisation in bridge Harikrishna Shenoy
2025-09-01  9:52   ` Tomi Valkeinen
2025-09-02  8:28     ` Harikrishna Shenoy
2025-08-11  7:59 ` [PATCH v5 2/6] drm/bridge: cadence: cdns-mhdp8546*: Change drm_connector from structure to pointer Harikrishna Shenoy
2025-09-01 10:00   ` Tomi Valkeinen
2025-09-02  8:32     ` Harikrishna Shenoy
2025-08-11  7:59 ` [PATCH v5 3/6] drm/bridge: cadence: cdns-mhdp8546-core: Set the mhdp connector earlier in atomic_enable() Harikrishna Shenoy
2025-09-01 10:05   ` Tomi Valkeinen
2025-09-02  9:27     ` Harikrishna Shenoy
2025-08-11  7:59 ` [PATCH v5 4/6] drm/bridge: cadence: cdns-mhdp8546-core: Add mode_valid hook to drm_bridge_funcs Harikrishna Shenoy
2025-09-01 10:07   ` Tomi Valkeinen
2025-08-11  7:59 ` [PATCH v5 5/6] drm/bridge: cadence: cdns-mhdp8546-core: Reduce log level for DPCD read/write Harikrishna Shenoy
2025-09-01 10:08   ` Tomi Valkeinen
2025-08-11  7:59 ` [PATCH v5 6/6] drm/bridge: cadence: cdns-mhdp8546-core: Handle HDCP state in bridge atomic check Harikrishna Shenoy
2025-09-01 10:18   ` Tomi Valkeinen [this message]
2025-09-02 11:34     ` Harikrishna Shenoy

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=4e7fb22e-8b15-46e5-906b-9b2aa65f2911@ideasonboard.com \
    --to=tomi.valkeinen@ideasonboard.com \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=airlied@gmail.com \
    --cc=andrzej.hajda@intel.com \
    --cc=andy.yan@rock-chips.com \
    --cc=devarsht@ti.com \
    --cc=dianders@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=h-shenoy@ti.com \
    --cc=j-choudhary@ti.com \
    --cc=javierm@redhat.com \
    --cc=jernej.skrabec@gmail.com \
    --cc=jonas@kwiboo.se \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@treblig.org \
    --cc=luca.ceresoli@bootlin.com \
    --cc=lumag@kernel.org \
    --cc=lyude@redhat.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=rfoss@kernel.org \
    --cc=s-jain1@ti.com \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    --cc=u-kumar1@ti.com \
    --cc=viro@zeniv.linux.org.uk \
    /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®