From: sashiko-bot@kernel.org
To: ElXreno <elxreno@gmail.com>,
intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 6/7] drm/i915: Evade the vblank on the scanline of the joiner primary
Date: Sat, 14 Nov 2026 01:53:45 +0000 [thread overview]
Message-ID: <sashiko-outbox-214015@kernel.org> (raw)
In-Reply-To: <20261114014335.2132756-7-elxreno@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [High] drm/i915: Signed-off-by trailer uses handle instead of real
name
--
commit 516746727da5577decb0038cc22a5dddd9cbc589
Author: ElXreno <elxreno@gmail.com>
> drm/i915: Evade the vblank on the scanline of the joiner primary
>
> The scanline counter of a joiner secondary pipe was observed to wrap
> at 8192 lines on Arrow Lake, with pipes A and B joined. Sampling
> PIPEDSL of both pipes, they agree up to line 8191, which is the
> largest value pipe B ever returns, while pipe A counts on up to the
> vmax vtotal. From line 8192 on pipe B reads 8192 lines less than
> pipe A. This comes from measurement only, I have no documentation for
> it, and I could not check whether it is a property of the joiner
> secondary or of that pipe.
>
> It is harmless as long as vtotal stays below 8192, which every fixed
> refresh rate mode that needs the joiner does. With VRR the vmax
> vtotal can be larger, 12200 for a 3840x2400@240 mode with a 48 Hz
> lower limit. The vmax vblank start at line 12160 then reads as 3968
> on the secondary, vblank evasion on that pipe never sees its evasion
> window, and the pipe gets armed across the vblank:
>
> Atomic update failure on pipe B (start=48480 end=48481) time 8 us, min 12101, max 12159, scanline start 3965, end 3969
>
> All joined pipes run off the timings of the primary, so look at the
> scanline counter of the primary when evading the vblank on a
> secondary. This matters for the commits that still take the per pipe
> critical sections with the joiner.
>
> Only the evasion is changed. The vblank timestamps of a secondary
> still come from its own counter, and so does the end scanline in the
> message above, while the start scanline is now the primary's.
>
> Signed-off-by: ElXreno <elxreno@gmail.com>
[Severity: High]
Documentation/process/submitting-patches.rst requires a real name in the
Signed-off-by trailer and does not permit handles or pseudonyms. Could
this be updated to use a full real name in both the Author header and
Signed-off-by line?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261114014335.2132756-1-elxreno@gmail.com?part=6
next prev parent reply other threads:[~2026-11-14 1:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-14 1:43 [PATCH 0/7] drm/i915: VRR with the pipe joiner ElXreno
2026-11-14 1:43 ` [PATCH 1/7] drm/i915/panel: Fix the pixel clock overflow in the VRR vtotal ElXreno
2026-11-14 1:54 ` sashiko-bot
2026-11-14 1:43 ` [PATCH 2/7] drm/i915/vrr: Fix the pixel clock overflow in the vmax computation ElXreno
2026-11-14 1:52 ` sashiko-bot
2026-11-14 1:43 ` [PATCH 3/7] drm/i915/vrr: Leave the transcoder to the joiner primary ElXreno
2026-11-14 1:56 ` sashiko-bot
2026-11-14 1:43 ` [PATCH 4/7] drm/i915: Split intel_update_crtc() into its stages ElXreno
2026-11-14 1:48 ` sashiko-bot
2026-11-14 1:43 ` [PATCH 5/7] drm/i915: Arm joined pipes within one vblank evasion for VRR ElXreno
2026-11-14 2:02 ` sashiko-bot
2026-11-14 1:43 ` [PATCH 6/7] drm/i915: Evade the vblank on the scanline of the joiner primary ElXreno
2026-11-14 1:53 ` sashiko-bot [this message]
2026-11-14 1:43 ` [PATCH 7/7] drm/i915/vrr: Allow VRR with the pipe joiner ElXreno
2026-11-14 2:24 ` sashiko-bot
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=sashiko-outbox-214015@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=elxreno@gmail.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.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 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.