From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Imre Deak <imre.deak@intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 2/5] drm/i915/dp: Calculate DSC slice count based on per-slice peak throughput
Date: Mon, 22 Sep 2025 22:34:40 +0300 [thread overview]
Message-ID: <aNGk0M6Vix9CqLXt@intel.com> (raw)
In-Reply-To: <20250918211223.209674-3-imre.deak@intel.com>
On Fri, Sep 19, 2025 at 12:12:20AM +0300, Imre Deak wrote:
> Use the branch device's actual per-slice peak throughput to calculate
> the minimum number of required DSC slices, falling back to the
> hard-coded throughput values (as suggested by the DP Standard) if the
> device's reported throughput value is 0.
>
> For now use the minimum of the two throughput values, which is ok,
> potentially resulting in a higher than required minimum slice count.
> This doesn't change the current way of using the same minimum throughput
> value regardless of the RGB/YUV output format used.
>
> Signed-off-by: Imre Deak <imre.deak@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 47 +++++++++++++++++++++----
> 1 file changed, 41 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 2eab591a8ef56..a963a58c87372 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1011,6 +1011,26 @@ u16 intel_dp_dsc_get_max_compressed_bpp(struct intel_display *display,
> return bits_per_pixel;
> }
>
> +static int dsc_per_slice_throughput(struct intel_display *display, int mode_clock, int bw_code)
s/bw_code/throughput_mode/ or something maybe to make it match the spec
a bit better? "bw_code" is I think what we've been calling the
LINK_BW_SET value.
> +{
> + switch (bw_code) {
> + case 0:
> + if (mode_clock <= DP_DSC_PEAK_PIXEL_RATE)
> + return DP_DSC_MAX_ENC_THROUGHPUT_0;
> + else
> + return DP_DSC_MAX_ENC_THROUGHPUT_1;
These look like some unhelpful single use defines. I'd get
rid of them and just stick the actual numbers here.
> + case 1:
> + return 340000;
> + case 2 ... 14:
> + return 400000 + 50000 * (bw_code - 2);
> + case 15:
> + return 170000;
> + default:
> + drm_err(display->drm, "Invalid DSC peak throughput code\n");
This whole thing looks like it belongs in some drm helper.
Probably best to pass in struct drm_device from the start
so that moving it over will later be easier.
> + return 340000;
> + }
> +}
> +
> u8 intel_dp_dsc_get_slice_count(const struct intel_connector *connector,
> int mode_clock, int mode_hdisplay,
> int num_joined_pipes)
> @@ -1018,13 +1038,28 @@ u8 intel_dp_dsc_get_slice_count(const struct intel_connector *connector,
> struct intel_display *display = to_intel_display(connector);
> u8 min_slice_count, i;
> int max_slice_width;
> + int tp_rgb_yuv444;
> + int tp_yuv422_420;
> + u8 val;
>
> - if (mode_clock <= DP_DSC_PEAK_PIXEL_RATE)
> - min_slice_count = DIV_ROUND_UP(mode_clock,
> - DP_DSC_MAX_ENC_THROUGHPUT_0);
> - else
> - min_slice_count = DIV_ROUND_UP(mode_clock,
> - DP_DSC_MAX_ENC_THROUGHPUT_1);
> + val = connector->dp.dsc_dpcd[DP_DSC_PEAK_THROUGHPUT - DP_DSC_SUPPORT];
> + tp_rgb_yuv444 = dsc_per_slice_throughput(display, mode_clock,
> + REG_FIELD_GET8(DP_DSC_THROUGHPUT_MODE_0_MASK,
> + val));
> + tp_yuv422_420 = dsc_per_slice_throughput(display, mode_clock,
> + REG_FIELD_GET8(DP_DSC_THROUGHPUT_MODE_1_MASK,
> + val));
> +
> + /*
> + * TODO: Use the throughput value specific to the actual RGB/YUV
> + * format of the output.
> + * For now use the smaller of these, which is ok, potentially
> + * resulting in a higher than required minimum slice count.
> + * The RGB/YUV444 throughput value should be always either equal
> + * or smaller than the YUV422/420 value, but let's not depend on
> + * this assumption.
> + */
> + min_slice_count = DIV_ROUND_UP(mode_clock, min(tp_rgb_yuv444, tp_yuv422_420));
>
> /*
> * Due to some DSC engine BW limitations, we need to enable second
> --
> 2.49.1
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2025-09-22 19:34 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-18 21:12 [PATCH 0/5] drm/i915/dp: Work around a DSC pixel throughput issue Imre Deak
2025-09-18 21:12 ` [PATCH 1/5] drm/dp: Add quirk for Synaptics DSC throughput link-bpp limit Imre Deak
2025-09-20 17:18 ` kernel test robot
2025-09-22 13:46 ` [PATCH v2 " Imre Deak
2025-09-18 21:12 ` [PATCH 2/5] drm/i915/dp: Calculate DSC slice count based on per-slice peak throughput Imre Deak
2025-09-22 19:34 ` Ville Syrjälä [this message]
2025-09-23 11:47 ` Imre Deak
2025-09-18 21:12 ` [PATCH 3/5] drm/i915/dp: Pass DPCD device descriptor to intel_dp_get_dsc_sink_cap() Imre Deak
2025-09-18 21:12 ` [PATCH 4/5] drm/i915/dp: Verify branch devices' overall pixel throughput/line width Imre Deak
2025-09-22 19:35 ` Ville Syrjälä
2025-09-22 20:06 ` Ville Syrjälä
2025-09-23 12:00 ` Imre Deak
2025-09-18 21:12 ` [PATCH 5/5] drm/i915/dp: Handle Synaptics DSC throughput link-bpp quirk Imre Deak
2025-09-22 13:46 ` [PATCH v2 " Imre Deak
2025-09-22 20:17 ` Ville Syrjälä
2025-09-23 12:08 ` Imre Deak
2025-09-25 22:08 ` [PATCH v4 " Imre Deak
2025-09-18 21:57 ` ✗ CI.checkpatch: warning for drm/i915/dp: Work around a DSC pixel throughput issue Patchwork
2025-09-18 21:58 ` ✓ CI.KUnit: success " Patchwork
2025-09-18 22:34 ` ✓ Xe.CI.BAT: " Patchwork
2025-09-18 23:32 ` ✓ i915.CI.BAT: " Patchwork
2025-09-19 21:10 ` ✓ i915.CI.Full: " Patchwork
2025-09-22 14:32 ` ✓ i915.CI.BAT: success for drm/i915/dp: Work around a DSC pixel throughput issue (rev3) Patchwork
2025-09-22 14:35 ` ✗ CI.checkpatch: warning " Patchwork
2025-09-22 14:36 ` ✓ CI.KUnit: success " Patchwork
2025-09-22 15:49 ` ✗ Xe.CI.BAT: failure " Patchwork
2025-09-22 16:04 ` Imre Deak
2025-09-24 5:44 ` Ravali, JupallyX
2025-09-22 16:19 ` ✗ i915.CI.Full: " Patchwork
2025-09-22 19:03 ` ✓ Xe.CI.Full: success " Patchwork
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=aNGk0M6Vix9CqLXt@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.