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 3/7] drm/i915/vrr: Leave the transcoder to the joiner primary
Date: Sat, 14 Nov 2026 01:56:37 +0000 [thread overview]
Message-ID: <sashiko-outbox-214019@kernel.org> (raw)
In-Reply-To: <20261114014335.2132756-4-elxreno@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [High] drm/i915/vrr: Signed-off-by trailer uses handle instead of real
full name
--
commit 6f78fb0ff83ff8c9f4f0ac58ba24164db71f007e
Author: ElXreno <elxreno@gmail.com>
> drm/i915/vrr: Leave the transcoder to the joiner primary
>
> All joined pipes run off the transcoder of the primary, and the crtc
> states of the secondaries are copies of the primary's state, the VRR
> state included. The commit therefore reaches the transcoder level VRR
> functions for every joined pipe: intel_pre_update_crtc() calls
> intel_vrr_set_transcoder_timings() for each crtc whose VRR parameters
> changed, intel_pre_plane_update() and commit_pipe_post_planes() call
> intel_vrr_disable() and intel_vrr_enable(), and both commit paths
> call intel_vrr_send_push() and intel_vrr_check_push_sent() per crtc.
>
> Do these once, from the primary. When disabling VRR also switch the
> active timings of all joined pipes as soon as the transcoder has left
> VRR mode, rather than leaving the secondaries on the VRR timings
> until their own turn comes.
>
> The check in intel_vrr_set_transcoder_timings() drops the second,
> identical programming of the transcoder that a joined fixed refresh
> rate configuration gets today. Everything else depends on vrr.enable,
> which is never set with the joiner yet, so there is no other
> functional change. In particular the push a secondary sends for the
> PSR and Panel Replay frame change is left as it is.
>
> The checks in intel_vrr_set_transcoder_timings(), intel_vrr_send_push(),
> intel_vrr_enable() and intel_vrr_disable() are the ones Ankit Nautiyal
> posted in "drm/i915/vrr: Handle joiner with vrr", last in [1].
>
> [1] https://lore.kernel.org/intel-gfx/20250224061717.1095226-14-ankit.k.nautiyal@intel.com/
>
> Suggested-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> Signed-off-by: ElXreno <elxreno@gmail.com>
[Severity: High]
The Signed-off-by trailer uses a single-word handle ("ElXreno") rather
than a real full name, which does not meet the Developer's Certificate
of Origin requirements in Documentation/process/submitting-patches.rst.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261114014335.2132756-1-elxreno@gmail.com?part=3
next prev parent reply other threads:[~2026-11-14 1:56 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 [this message]
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
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-214019@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.