dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Yongxing Mou" <yongxing.mou@oss.qualcomm.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v7 15/35] drm/msm/dp: factor out _helper variants of bridge ops accepting a panel
Date: Tue, 29 Sep 2026 04:43:05 +0000	[thread overview]
Message-ID: <20260929044306.2CC341F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260929-msm-dp-mst-v7-15-4b81473185e7@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] msm_dp_display_post_enable() hardcodes root dp->panel, breaking stream-specific PSR config
--

commit ce954c1f87fec9b4ffb2b11bf4184d722dd05ced
Author: Abhinav Kumar <quic_abhinavk@quicinc.com>

drm/msm/dp: factor out _helper variants of bridge ops accepting a panel

The atomic bridge callbacks (set_mode / enable / disable /
post_disable) on dp_display currently hard-code dp->panel. This
commit introduces helper variants that take a struct msm_dp_panel
pointer to allow the upcoming DP MST encoder to drive link-level
prepare and unprepare uniformly.

> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
[ ... ]
> +void msm_dp_display_enable_helper(struct msm_dp *msm_dp_display,
> +				  struct msm_dp_panel *msm_dp_panel)
> +{
> +	int rc = 0;
> +	struct msm_dp_display_private *dp;
> +
> +	dp = container_of(msm_dp_display, struct msm_dp_display_private, msm_dp_display);
> +
> +	rc = msm_dp_display_enable(dp, msm_dp_panel);
> +	if (rc)
> +		DRM_ERROR("DP display enable failed, rc=%d\n", rc);
> +
> +	rc = msm_dp_display_post_enable(msm_dp_display);

[Severity: Medium]
Does this call correctly configure PSR for MST streams?

This helper correctly accepts a stream-specific msm_dp_panel, but
msm_dp_display_post_enable() was not refactored to take a panel argument.

Looking at msm_dp_display_post_enable():

static int msm_dp_display_post_enable(struct msm_dp *msm_dp_display)
{
        ...
        if (msm_dp_display->psr_supported)
                msm_dp_ctrl_config_psr(dp->ctrl, dp->panel);
        ...
}

It still hardcodes the root dp->panel instead of the active stream's panel.
Could this misconfiguration lead to missing or incorrect PSR setup on MST
streams?

> +	if (rc) {
> +		DRM_ERROR("DP display post enable failed, rc=%d\n", rc);
> +		msm_dp_display_disable(dp, msm_dp_panel);
> +	}
> +
> +	drm_dbg_dp(msm_dp_display->drm_dev, "type=%d Done\n", msm_dp_display->connector_type);
> +}
[ ... ]
> +void msm_dp_display_disable_helper(struct msm_dp *msm_dp_display,
> +				   struct msm_dp_panel *msm_dp_panel)
> +{
> +	struct msm_dp_display_private *dp;
> +
> +	dp = container_of(msm_dp_display, struct msm_dp_display_private, msm_dp_display);
>  
>  	/*
>  	 * If .atomic_enable() bailed out - link training failure is the common
> @@ -1521,17 +1542,28 @@ void msm_dp_display_atomic_disable(struct msm_dp *dp)
>  	 * TrustZone-level SOCCP/ADSP force-stop and a silent SoC reset.
>  	 * There is nothing to push idle, so leave it alone.
>  	 */
> -	if (!dp->power_on)
> +	if (!msm_dp_display->active_stream_cnt)
>  		return;

[Severity: High]
This is a pre-existing issue, but could this safety guard be bypassed if a
stream fails to enable?

Looking at msm_dp_display_enable(), active_stream_cnt is incremented
unconditionally even if msm_dp_ctrl_on_stream() fails:

static int msm_dp_display_enable(struct msm_dp_display_private *dp,
                                 struct msm_dp_panel *msm_dp_panel)
{
        rc = msm_dp_ctrl_on_stream(dp->ctrl, msm_dp_panel, ...);
        msm_dp_display->active_stream_cnt++;
        return rc;
}

If msm_dp_ctrl_on_stream() returns an error during standard atomic commit paths
(e.g., due to a transient hardware failure like pixel clock enablement),
active_stream_cnt is artificially greater than zero. Later, when the stream is
disabled, this check evaluates to true.

Pushing idle patterns to a controller that failed to enable will time out,
which as documented here can cause a TrustZone-level SOCCP/ADSP force-stop and
a silent SoC reset.

Can we avoid incrementing active_stream_cnt when msm_dp_ctrl_on_stream()
fails?

> -	msm_dp_ctrl_push_vcpf(msm_dp_display->ctrl, msm_dp_display->panel);
> -	msm_dp_ctrl_mst_timeslot_setup(msm_dp_display->ctrl);
> -	msm_dp_ctrl_mst_send_act(msm_dp_display->ctrl, msm_dp_display->panel);
> +	msm_dp_ctrl_push_vcpf(dp->ctrl, msm_dp_panel);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260929-msm-dp-mst-v7-0-4b81473185e7@oss.qualcomm.com?part=15

  reply	other threads:[~2026-09-29  4:43 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-29  4:25 [PATCH v7 00/35] drm/msm/dp: Add MST support for MSM chipsets Yongxing Mou
2026-09-29  4:25 ` [PATCH v7 01/35] drm/msm/dp: move link-level teardown from display_disable to display_unprepare Yongxing Mou
2026-09-29  4:49   ` sashiko-bot
2026-10-01 10:11   ` Dmitry Baryshkov
2026-09-29  4:25 ` [PATCH v7 02/35] drm/msm/dp: Pass panel to msm_dp_ctrl_config_msa() Yongxing Mou
2026-10-01 10:13   ` Dmitry Baryshkov
2026-09-29  4:25 ` [PATCH v7 03/35] drm/msm/dp: drop redundant config_ctrl_link() from msm_dp_ctrl_on_stream() Yongxing Mou
2026-10-01 10:13   ` Dmitry Baryshkov
2026-09-29  4:25 ` [PATCH v7 04/35] drm/msm/dp: introduce stream_id for each DP panel Yongxing Mou
2026-09-29  4:44   ` sashiko-bot
2026-10-01 10:23   ` Dmitry Baryshkov
2026-09-29  4:25 ` [PATCH v7 05/35] drm/msm/dp: add support for programming p1/p2/p3 register blocks Yongxing Mou
2026-10-01 10:24   ` Dmitry Baryshkov
2026-09-29  4:25 ` [PATCH v7 06/35] drm/msm/dp: add MST stream register definitions Yongxing Mou
2026-10-01 10:26   ` Dmitry Baryshkov
2026-09-29  4:25 ` [PATCH v7 07/35] drm/msm/dp: add stream-aware link register accessors Yongxing Mou
2026-09-29  4:48   ` sashiko-bot
2026-10-01 10:26   ` Dmitry Baryshkov
2026-09-29  4:25 ` [PATCH v7 08/35] drm/msm/dp: add support to send ACT packets for MST Yongxing Mou
2026-09-29  4:42   ` sashiko-bot
2026-10-01 10:32   ` Dmitry Baryshkov
2026-09-29  4:25 ` [PATCH v7 09/35] drm/msm/dp: add support to enable MST in mainlink control Yongxing Mou
2026-09-29  4:25 ` [PATCH v7 10/35] drm/msm/dp: no need to update tu calculation for mst Yongxing Mou
2026-09-29  4:25 ` [PATCH v7 11/35] drm/msm/dp: always program MST_FIFO_CONSTANT_FILL for MST use cases Yongxing Mou
2026-09-29  4:25 ` [PATCH v7 12/35] drm/msm/dp: add support for sending VCPF packets in DP controller Yongxing Mou
2026-09-29  4:49   ` sashiko-bot
2026-10-01 10:34     ` Dmitry Baryshkov
2026-09-29  4:25 ` [PATCH v7 13/35] drm/msm/dp: add support for MST channel slot allocation Yongxing Mou
2026-09-29  4:42   ` sashiko-bot
2026-10-01 10:52   ` Dmitry Baryshkov
2026-09-29  4:25 ` [PATCH v7 14/35] drm/msm/dp: replace power_on with active_stream_cnt Yongxing Mou
2026-09-29  4:44   ` sashiko-bot
2026-09-29  4:25 ` [PATCH v7 15/35] drm/msm/dp: factor out _helper variants of bridge ops accepting a panel Yongxing Mou
2026-09-29  4:43   ` sashiko-bot [this message]
2026-09-29  4:25 ` [PATCH v7 16/35] drm/msm/dp: add link_ready to manage link-level operations Yongxing Mou
2026-09-29  4:39   ` sashiko-bot
2026-09-29  4:25 ` [PATCH v7 17/35] drm/msm/dp: add msm_dp_display_get_panel() to initialize DP panel Yongxing Mou
2026-09-29  4:44   ` sashiko-bot
2026-09-29  4:25 ` [PATCH v7 18/35] drm/msm/dp: introduce dp_mst_drm module Yongxing Mou
2026-09-29  4:48   ` sashiko-bot
2026-09-29  4:25 ` [PATCH v7 19/35] drm/msm/dp: add MST connector creation and topology callbacks Yongxing Mou
2026-09-29  4:48   ` sashiko-bot
2026-09-29  4:25 ` [PATCH v7 20/35] drm/msm/dpu: pass msm_display_info to dpu_encoder_get_intf() Yongxing Mou
2026-09-29  4:25 ` [PATCH v7 21/35] drm/msm/dpu: use stream_id to select MST interfaces Yongxing Mou
2026-09-29  4:25 ` [PATCH v7 22/35] drm/msm/dpu: add per-stream MST encoders Yongxing Mou
2026-09-29  4:46   ` sashiko-bot
2026-09-29  4:25 ` [PATCH v7 23/35] drm/msm/dp: move link capabilities to dp_link Yongxing Mou
2026-09-29  4:25 ` [PATCH v7 24/35] drm/msm/dp: add atomic stream handling for MST Yongxing Mou
2026-09-29  4:54   ` sashiko-bot
2026-09-29  4:25 ` [PATCH v7 25/35] drm/bridge_connector: suppress hotplug for IRQ_HPD without status changes Yongxing Mou
2026-09-29  4:51   ` sashiko-bot
2026-09-29  4:25 ` [PATCH v7 26/35] drm/bridge_connector: avoid detect-based HPD notifications for DisplayPort Yongxing Mou
2026-09-29  4:25 ` [PATCH v7 27/35] drm/msm/dp: add HPD callback for dp MST Yongxing Mou
2026-09-29  4:55   ` sashiko-bot
2026-09-29  4:25 ` [PATCH v7 28/35] drm/msm/dp: wire MST helpers into atomic check and commit paths Yongxing Mou
2026-09-29  4:25 ` [PATCH v7 29/35] drm/msm/dp: mark the SST bridge disconnected when mst is active Yongxing Mou
2026-09-29  4:25 ` [PATCH v7 30/35] drm/msm/dp: enable MST on capable sinks Yongxing Mou
2026-09-29  4:58   ` sashiko-bot
2026-09-29  4:25 ` [PATCH v7 31/35] drm/msm/dp: mark the SST bridge disconnected when an MST-capable sink is present Yongxing Mou
2026-09-29  4:25 ` [PATCH v7 32/35] drm/msm/dp: mark the SST connector disconnected when MST is enabled Yongxing Mou
2026-09-29  4:54   ` sashiko-bot
2026-09-29  4:25 ` [PATCH v7 33/35] drm/msm/dp: wake threaded handler for HPD IRQs Yongxing Mou
2026-09-29  4:25 ` [PATCH v7 34/35] drm/msm/dp: order IRQ HPD handling with plug state changes Yongxing Mou
2026-09-29  4:54   ` sashiko-bot
2026-09-29  4:25 ` [PATCH v7 35/35] soc: qcom: pmic-glink-altmode: skip retimer reset on DP IRQ Yongxing Mou
2026-09-29  4:55   ` sashiko-bot
2026-10-03  0:46 ` [PATCH v7 00/35] drm/msm/dp: Add MST support for MSM chipsets Dmitry Baryshkov

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=20260929044306.2CC341F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=yongxing.mou@oss.qualcomm.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