From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Juasheem Sultan <jdsultan@google.com>
Cc: Maarten Lankhorst <dev@lankhorst.se>,
intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
Jani Nikula <jani.nikula@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Manasi Navare <navaremanasi@google.com>,
Drew Davenport <ddavenport@google.com>,
Sean Paul <seanpaul@google.com>,
Samuel Jacob <samjaco@google.com>,
Rajat Jain <rajatja@google.com>
Subject: Re: [PATCH v4 2/2] drm/i915/display: Sync state to BIOS for seamless handoff
Date: Fri, 27 Mar 2026 12:11:54 +0200 [thread overview]
Message-ID: <acZX6htfhw4v0G8c@intel.com> (raw)
In-Reply-To: <CAH6Pru5Me2pY31JF2GP61k3gy8XDaLfmH7U6jpAwXoYvGEZBwA@mail.gmail.com>
On Thu, Mar 26, 2026 at 04:10:13PM -0700, Juasheem Sultan wrote:
> Hi,
>
> Thanks for looking at this.
>
> You're saying instead of manually adopting the state that I should focus on
> modifying the comparisons that we do to determine if we can perform a
> fastset?
We don't want any fuzzy fastset hacks anywhere. I intentionally killed
all that stuff because it was making it impossible to trust that the
software state actually represents what the hardware is doing.
Someone needs to figure out what exactly is the difference between
the states between the GOP and the driver, and then figure out where
that difference is coming from.
>
> -Juasheem
>
> On Wed, Mar 18, 2026 at 5:00 AM Maarten Lankhorst <dev@lankhorst.se> wrote:
>
> > Hey,
> >
> > Den 2026-03-17 kl. 23:09, skrev Juasheem Sultan:
> > > Align DP timings and C10 PLL state with BIOS values if within a 0.5%
> > > clock threshold. This prevents minor mismatches from triggering a full
> > > modeset during the first atomic commit, ensuring a flicker-free handoff.
> > >
> > > Signed-off-by: Juasheem Sultan <jdsultan@google.com>
> > > ---
> > > drivers/gpu/drm/i915/display/intel_display.c | 67 ++++++++++++++++++++
> > > 1 file changed, 67 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index c4246481fc2f..22e5e931f134 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -6397,6 +6397,71 @@ static int
> > intel_atomic_check_config_and_link(struct intel_atomic_state *state)
> > >
> > > return ret;
> > > }
> > > +
> > > +// Helper function to sanitize pll state
> > > +static void intel_sanitize_pll_state(struct intel_crtc_state
> > *old_crtc_state,
> > > + struct intel_crtc_state *new_crtc_state)
> > > +{
> > > + int j;
> > > +
> > > + for (j = 4; j < 9; j++) {
> > > + if (new_crtc_state->dpll_hw_state.cx0pll.c10.pll[j] !=
> > > +
> > old_crtc_state->dpll_hw_state.cx0pll.c10.pll[j]) {
> > > + new_crtc_state->dpll_hw_state.cx0pll.c10.pll[j] =
> > > +
> > old_crtc_state->dpll_hw_state.cx0pll.c10.pll[j];
> > > + }
> > > + }
> > > +}
> > > +
> > > +/*
> > > + * intel_dp_sanitize_seamless_boot - Snap driver state to BIOS state
> > for seamless handoff.
> > > + * @state: the atomic state to sanitize
> > > + *
> > > + * This function compares the driver's calculated new_state with the
> > inherited BIOS state
> > > + * (old_state). If they are within a small threshold (e.g., 0.5% for
> > clock), it "snaps"
> > > + * the new_state to match the BIOS state exactly. This prevents minor
> > state mismatches
> > > + * that would otherwise force a full modeset (and a screen flicker)
> > during the initial
> > > + * kernel handoff.
> > > + */
> > > +static void intel_dp_sanitize_seamless_boot(struct intel_atomic_state
> > *state)
> > > +{
> > > + struct intel_display *display = to_intel_display(state);
> > > + struct intel_crtc_state *new_crtc_state, *old_crtc_state;
> > > + struct intel_crtc *crtc;
> > > + struct intel_encoder *encoder;
> > > + int i;
> > > +
> > > + for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> > new_crtc_state, i) {
> > > + /*
> > > + * We must check old_crtc_state->inherited because
> > new_crtc_state->inherited
> > > + * is cleared at the start of intel_atomic_check for
> > userspace commits.
> > > + */
> > > + if (!old_crtc_state->inherited ||
> > !new_crtc_state->hw.active)
> > > + continue;
> > > +
> > > + if (intel_crtc_has_dp_encoder(new_crtc_state)) {
> > > + int old_clock =
> > old_crtc_state->hw.adjusted_mode.crtc_clock;
> > > + int new_clock =
> > new_crtc_state->hw.adjusted_mode.crtc_clock;
> > > + int threshold = old_clock / 200; /* 0.5% */
> > > +
> > > + if (abs(new_clock - old_clock) <= threshold) {
> > > + new_crtc_state->hw.pipe_mode.crtc_clock =
> > old_clock;
> > > +
> > new_crtc_state->hw.adjusted_mode.crtc_clock = old_clock;
> > > + new_crtc_state->pixel_rate =
> > old_crtc_state->pixel_rate;
> > > + new_crtc_state->dp_m_n =
> > old_crtc_state->dp_m_n;
> > > + }
> > > + }
> > > +
> > > + for_each_intel_encoder_mask(display->drm, encoder,
> > > + new_crtc_state->uapi.encoder_mask) {
> > > + if (intel_encoder_is_c10phy(encoder)) {
> > > + if
> > (!new_crtc_state->dpll_hw_state.cx0pll.ssc_enabled)
> > > +
> > intel_sanitize_pll_state(old_crtc_state, new_crtc_state);
> > > + }
> > > + }
> > > + }
> > > +}
> > > +
> > > /**
> > > * intel_atomic_check - validate state object
> > > * @dev: drm device
> > > @@ -6447,6 +6512,8 @@ int intel_atomic_check(struct drm_device *dev,
> > > if (ret)
> > > goto fail;
> > >
> > > + intel_dp_sanitize_seamless_boot(state);
> > > +
> > > for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> > > if (!intel_crtc_needs_modeset(new_crtc_state))
> > > continue;
> >
> > This might fix boot state, but in a way that complicates the code
> > considerably.
> >
> > Have you considered updating intel_pipe_config_compare instead?
> >
> > Kind regards,
> > ~Maarten Lankhorst
> >
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2026-03-27 10:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-17 22:09 [PATCH v4 0/2] Enable seamless boot (fastboot) for PTL Juasheem Sultan
2026-03-17 22:09 ` [PATCH v4 1/2] drm/xe/display: Fix reading the framebuffer from stolen memory Juasheem Sultan
2026-03-18 12:05 ` Maarten Lankhorst
2026-03-17 22:09 ` [PATCH v4 2/2] drm/i915/display: Sync state to BIOS for seamless handoff Juasheem Sultan
2026-03-18 12:00 ` Maarten Lankhorst
2026-03-26 23:10 ` Juasheem Sultan
2026-03-27 8:58 ` Maarten Lankhorst
2026-03-27 10:11 ` Ville Syrjälä [this message]
2026-04-01 16:19 ` Maarten Lankhorst
2026-04-01 17:44 ` Ville Syrjälä
2026-04-01 17:56 ` Ville Syrjälä
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=acZX6htfhw4v0G8c@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=ddavenport@google.com \
--cc=dev@lankhorst.se \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=jdsultan@google.com \
--cc=navaremanasi@google.com \
--cc=rajatja@google.com \
--cc=rodrigo.vivi@intel.com \
--cc=samjaco@google.com \
--cc=seanpaul@google.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