Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Graham O'Connor" <graham.oconnor@gmail.com>
Cc: devicetree@vger.kernel.org, conor+dt@kernel.org, robh@kernel.org
Subject: Re: [PATCH 3/6] drm/msm/dp: Limit voltage swing level to 2 for RA620 bridge
Date: Fri, 22 May 2026 06:55:47 +0000	[thread overview]
Message-ID: <20260522065548.2CCD81F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260522060645.4399-4-graham.oconnor@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] A device-specific workaround for the RA620 bridge is applied globally, capping the maximum voltage swing and pre-emphasis levels for all DP devices using the MSM DP driver.
--

commit cfc03fd78122eb643ca94e4cccdc197ffa9a8de0
Author: Graham O'Connor <graham.oconnor@gmail.com>

drm/msm/dp: Limit voltage swing level to 2 for RA620 bridge

This commit reduces the maximum DisplayPort link training level to 2 to work
around a link training failure specific to the RA620 DP-to-HDMI bridge used
on the Radxa Dragon Q6A platform.

> diff --git a/drivers/gpu/drm/msm/dp/dp_link.h b/drivers/gpu/drm/msm/dp/dp_link.h
> index 76125e9c07e9c..ff0d8e99d87c9 100644
> --- a/drivers/gpu/drm/msm/dp/dp_link.h
> +++ b/drivers/gpu/drm/msm/dp/dp_link.h
> @@ -24,7 +24,7 @@ struct msm_dp_link_info {
>  	unsigned long capabilities;
>  };
>  
> -#define DP_TRAIN_LEVEL_MAX	3
> +#define DP_TRAIN_LEVEL_MAX	2

[Severity: High]
Does this change globally cap the maximum voltage swing and pre-emphasis
levels for all DisplayPort devices using the MSM DP driver?

Because the DP specification supports voltage swing up to level 3, which is
often required for signal integrity over long cables or at high bandwidths,
removing this capability globally can cause link training failures and
unstable connections on fully compliant displays.

Furthermore, since maximum pre-emphasis is calculated as DP_TRAIN_LEVEL_MAX
minus the voltage level, capping this macro at 2 means that if a voltage
swing level of 2 is used, the pre-emphasis level is strictly constrained to 0.

Could this hardware-specific workaround for the RA620 bridge be implemented
conditionally (for example, via DPCD OUI detection, bridge properties, or
device tree matching) rather than permanently degrading global subsystem
capabilities for all platforms?

>  
>  struct msm_dp_link_test_video {
>  	u32 test_video_pattern;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260522060645.4399-1-graham.oconnor@gmail.com?part=3

  reply	other threads:[~2026-05-22  6:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-22  6:06 [PATCH 0/6] arm64: qcom: Enable additional hardware on Radxa Dragon Q6A Graham O'Connor
2026-05-22  6:06 ` [PATCH 1/6] soc: qcom: rpmh-rsc: Skip TCS init when RSC is managed by firmware Graham O'Connor
2026-05-22  6:48   ` sashiko-bot
2026-05-22  6:06 ` [PATCH 2/6] firmware: qcom: scm: Allow EFI variable access on Radxa Dragon Q6A Graham O'Connor
2026-05-22  6:06 ` [PATCH 3/6] drm/msm/dp: Limit voltage swing level to 2 for RA620 bridge Graham O'Connor
2026-05-22  6:55   ` sashiko-bot [this message]
2026-05-22  9:28   ` Konrad Dybcio
2026-05-22  6:06 ` [PATCH 4/6] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Add regulator supplies and disable EUD Graham O'Connor
2026-05-22  7:27   ` sashiko-bot
2026-05-22  6:06 ` [PATCH 5/6] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable GPU and display pipeline Graham O'Connor
2026-05-22  6:44   ` Neil Armstrong
2026-05-22  7:52   ` sashiko-bot
2026-05-22  6:06 ` [PATCH 6/6] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable USB3 SuperSpeed Graham O'Connor
2026-05-22  6:44   ` Neil Armstrong
2026-05-22 10:13 ` [PATCH 0/6] arm64: qcom: Enable additional hardware on Radxa Dragon Q6A Graham O'Connor

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=20260522065548.2CCD81F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=graham.oconnor@gmail.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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