[RFC PATCH v3 0/2] Enable seamless boot (fastboot) for PTL

[RFC PATCH v3 0/2] Enable seamless boot (fastboot) for PTL

[Juasheem Sultan]

Resending with cover letter from v2. There were no significant code
changes. Only resending due to mail failure.

This patch series is the second revision of a series of patches meant
to add support for seamless framebuffer handoff within the Xe driver.
It was tested on Panther Lake platforms.

The goal of this series is to achieve a flicker-free transition from
the bootloader (BIOS/UEFI) to the kernel driver by strictly adhering
to the hardware state established by the firmware.

Thank you for the feedback on the previous revision.

This new patch series was created with that feedback in mind. That
revision was too rough of an implementation that had a considerable
amount of useless code and fixed problems that it unecessarily
introduced. Because of that, I completely reworked and rewrote the
solution into a much smaller, efficient version that properly makes
use of the existing infrastructure. This patch series has two specific
focal points. It enables Xe to properly adopt a framebuffer from bios
by fixing how we read stolen memory and it synchronizes an inherited
crtc state with the new state so that we can perform an initial commit.
This allows us to achieve seamless handoff between the firmware and
kernel with minimal changes required.

---
Changes since v1
- v2 Complete rewrite of the code
- v3 Resending due to failure of patches to send

Juasheem Sultan (2):
  drm/xe/display: Fix reading the framebuffer from stolen memory
  drm/i915/display: Synchronize crtc_state for initial commit

 drivers/gpu/drm/i915/display/intel_display.c  | 19 ++++++++++++++++
 drivers/gpu/drm/xe/display/xe_plane_initial.c | 22 ++++++++++++++++++-
 2 files changed, 40 insertions(+), 1 deletion(-)

-- 
2.52.0.457.g6b5491de43-goog

[RFC PATCH v3 1/2] drm/xe/display: Fix reading the framebuffer from stolen memory

[Juasheem Sultan]

Currently, we attempt to pin stolen memory using the ggtt address. This
doesn't appear to actually read the framebuffer that was setup by the
bios. Instead, we have to use the underlying physical address offset
within stolen memory.

Signed-off-by: Juasheem Sultan <jdsultan@google.com>
---
 drivers/gpu/drm/xe/display/xe_plane_initial.c | 22 ++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xe/display/xe_plane_initial.c b/drivers/gpu/drm/xe/display/xe_plane_initial.c
index 94f00def811b..2b84d0cc97e3 100644
--- a/drivers/gpu/drm/xe/display/xe_plane_initial.c
+++ b/drivers/gpu/drm/xe/display/xe_plane_initial.c
@@ -22,6 +22,7 @@
 #include "intel_plane.h"
 #include "intel_plane_initial.h"
 #include "xe_bo.h"
+#include "xe_ttm_stolen_mgr.h"
 #include "xe_vram_types.h"
 #include "xe_wa.h"
 
@@ -120,7 +121,26 @@ initial_plane_bo(struct xe_device *xe,
 
 		if (!stolen)
 			return NULL;
-		phys_base = base;
+
+		/* Read PTE to find physical address backing the GGTT address */
+		u64 pte = xe_ggtt_read_pte(tile0->mem.ggtt, base);
+		u64 phys_addr = pte & ~(page_size - 1);
+
+		u64 stolen_base = xe_ttm_stolen_gpu_offset(xe);
+
+		drm_dbg_kms(&xe->drm,
+			"Stolen Framebuffer base=%x pte=%llx phys_addr=%llx stolen_base=%llx\n",
+			 base, pte, phys_addr, stolen_base);
+
+		/* Make sure that the physical address is in the range of stolen memory */
+		if (phys_addr >= stolen_base) {
+			phys_base = phys_addr - stolen_base;
+		} else {
+			drm_err(&xe->drm, "Stolen memory outside of stolen range phys_base=%pa\n",
+				&phys_base);
+			return NULL;
+		}
+
 		flags |= XE_BO_FLAG_STOLEN;
 
 		if (XE_GT_WA(xe_root_mmio_gt(xe), 22019338487_display))
-- 
2.52.0.457.g6b5491de43-goog

[RFC PATCH v3 2/2] drm/i915/display: Synchronize crtc_state for initial commit

[Juasheem Sultan]

When attempting the initial commit, there is a mismatch between
the new crtc_state and the old crtc_state. This causes us to fail the
pipe_config comparison and force a modeset. In the case where we are
inheriting an initialized state, we can sync the new and the old state
to pass the comparison and allow us to do a fastset and achieve an
uninterrupted handoff to userspace.

Signed-off-by: Juasheem Sultan <jdsultan@google.com>
---
 drivers/gpu/drm/i915/display/intel_display.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index 0d527cf22866..6eef4bd2e251 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5736,6 +5736,25 @@ static void intel_crtc_check_fastset(const struct intel_crtc_state *old_crtc_sta
 	if (old_crtc_state->vrr.in_range != new_crtc_state->vrr.in_range)
 		new_crtc_state->update_lrr = false;
 
+	/* Copying crtc state if inheriting an old state for commit */
+	if (old_crtc_state->inherited) {
+		new_crtc_state->hw = old_crtc_state->hw;
+
+		new_crtc_state->port_clock = old_crtc_state->port_clock;
+		new_crtc_state->pipe_bpp = old_crtc_state->pipe_bpp;
+		new_crtc_state->cpu_transcoder = old_crtc_state->cpu_transcoder;
+		new_crtc_state->lane_count = old_crtc_state->lane_count;
+		new_crtc_state->output_types = old_crtc_state->output_types;
+		new_crtc_state->dp_m_n = old_crtc_state->dp_m_n;
+		new_crtc_state->framestart_delay = old_crtc_state->framestart_delay;
+		new_crtc_state->pixel_multiplier = old_crtc_state->pixel_multiplier;
+		new_crtc_state->pixel_rate = old_crtc_state->pixel_rate;
+		new_crtc_state->enhanced_framing = old_crtc_state->enhanced_framing;
+		new_crtc_state->dpll_hw_state = old_crtc_state->dpll_hw_state;
+		new_crtc_state->intel_dpll = old_crtc_state->intel_dpll;
+		new_crtc_state->vrr.guardband = old_crtc_state->vrr.guardband;
+	}
+
 	if (!intel_pipe_config_compare(old_crtc_state, new_crtc_state, true)) {
 		drm_dbg_kms(display->drm, "[CRTC:%d:%s] fastset requirement not met, forcing full modeset\n",
 			    crtc->base.base.id, crtc->base.name);
-- 
2.52.0.457.g6b5491de43-goog

Re: [RFC PATCH v3 2/2] drm/i915/display: Synchronize crtc_state for initial commit

[Manasi Navare]

[-- Attachment #1: Type: text/plain, Size: 3439 bytes --]

Thanks Jausheem for the revision, this definitely simplifies the hardcoding
of the crtc state values and just make sure the new_crtc_state is inherited
from old_crtc_state.
The logic looks good to me.

You could try and move the new_crtc_state = old_crtc_state assignments to a
separate function and call them from intel_ctomic_check()at the top which
ends up calling intel_crtc_check_fastset() , in which case then this will
return true and no modeset would be required.

Other than that it looks good to me.
@Jani Nikula <jani.nikula@intel.com>  let me know what you think, look
forward to your feedback on this new revision and if it looks okay with the
fastset approach.

Manasi

On Wed, Jan 21, 2026 at 12:47 PM Juasheem Sultan <jdsultan@google.com>
wrote:

> When attempting the initial commit, there is a mismatch between
> the new crtc_state and the old crtc_state. This causes us to fail the
> pipe_config comparison and force a modeset. In the case where we are
> inheriting an initialized state, we can sync the new and the old state
> to pass the comparison and allow us to do a fastset and achieve an
> uninterrupted handoff to userspace.
>
> Signed-off-by: Juasheem Sultan <jdsultan@google.com>
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 0d527cf22866..6eef4bd2e251 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5736,6 +5736,25 @@ static void intel_crtc_check_fastset(const struct
> intel_crtc_state *old_crtc_sta
>         if (old_crtc_state->vrr.in_range != new_crtc_state->vrr.in_range)
>                 new_crtc_state->update_lrr = false;
>
> +       /* Copying crtc state if inheriting an old state for commit */
> +       if (old_crtc_state->inherited) {
> +               new_crtc_state->hw = old_crtc_state->hw;
> +
> +               new_crtc_state->port_clock = old_crtc_state->port_clock;
> +               new_crtc_state->pipe_bpp = old_crtc_state->pipe_bpp;
> +               new_crtc_state->cpu_transcoder =
> old_crtc_state->cpu_transcoder;
> +               new_crtc_state->lane_count = old_crtc_state->lane_count;
> +               new_crtc_state->output_types =
> old_crtc_state->output_types;
> +               new_crtc_state->dp_m_n = old_crtc_state->dp_m_n;
> +               new_crtc_state->framestart_delay =
> old_crtc_state->framestart_delay;
> +               new_crtc_state->pixel_multiplier =
> old_crtc_state->pixel_multiplier;
> +               new_crtc_state->pixel_rate = old_crtc_state->pixel_rate;
> +               new_crtc_state->enhanced_framing =
> old_crtc_state->enhanced_framing;
> +               new_crtc_state->dpll_hw_state =
> old_crtc_state->dpll_hw_state;
> +               new_crtc_state->intel_dpll = old_crtc_state->intel_dpll;
> +               new_crtc_state->vrr.guardband =
> old_crtc_state->vrr.guardband;
> +       }
> +
>         if (!intel_pipe_config_compare(old_crtc_state, new_crtc_state,
> true)) {
>                 drm_dbg_kms(display->drm, "[CRTC:%d:%s] fastset
> requirement not met, forcing full modeset\n",
>                             crtc->base.base.id, crtc->base.name);
> --
> 2.52.0.457.g6b5491de43-goog
>
>

[-- Attachment #2: Type: text/html, Size: 4437 bytes --]

Re: [RFC PATCH v3 2/2] drm/i915/display: Synchronize crtc_state for initial commit

[Jani Nikula]

On Wed, 21 Jan 2026, Juasheem Sultan <jdsultan@google.com> wrote:
> When attempting the initial commit, there is a mismatch between
> the new crtc_state and the old crtc_state. This causes us to fail the
> pipe_config comparison and force a modeset. In the case where we are
> inheriting an initialized state, we can sync the new and the old state
> to pass the comparison and allow us to do a fastset and achieve an
> uninterrupted handoff to userspace.
>
> Signed-off-by: Juasheem Sultan <jdsultan@google.com>
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index 0d527cf22866..6eef4bd2e251 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5736,6 +5736,25 @@ static void intel_crtc_check_fastset(const struct intel_crtc_state *old_crtc_sta
>  	if (old_crtc_state->vrr.in_range != new_crtc_state->vrr.in_range)
>  		new_crtc_state->update_lrr = false;
>  
> +	/* Copying crtc state if inheriting an old state for commit */
> +	if (old_crtc_state->inherited) {
> +		new_crtc_state->hw = old_crtc_state->hw;
> +
> +		new_crtc_state->port_clock = old_crtc_state->port_clock;
> +		new_crtc_state->pipe_bpp = old_crtc_state->pipe_bpp;
> +		new_crtc_state->cpu_transcoder = old_crtc_state->cpu_transcoder;
> +		new_crtc_state->lane_count = old_crtc_state->lane_count;
> +		new_crtc_state->output_types = old_crtc_state->output_types;
> +		new_crtc_state->dp_m_n = old_crtc_state->dp_m_n;
> +		new_crtc_state->framestart_delay = old_crtc_state->framestart_delay;
> +		new_crtc_state->pixel_multiplier = old_crtc_state->pixel_multiplier;
> +		new_crtc_state->pixel_rate = old_crtc_state->pixel_rate;
> +		new_crtc_state->enhanced_framing = old_crtc_state->enhanced_framing;
> +		new_crtc_state->dpll_hw_state = old_crtc_state->dpll_hw_state;
> +		new_crtc_state->intel_dpll = old_crtc_state->intel_dpll;
> +		new_crtc_state->vrr.guardband = old_crtc_state->vrr.guardband;

I'd like to see logs of what the differences are.

BR,
Jani.

> +	}
> +
>  	if (!intel_pipe_config_compare(old_crtc_state, new_crtc_state, true)) {
>  		drm_dbg_kms(display->drm, "[CRTC:%d:%s] fastset requirement not met, forcing full modeset\n",
>  			    crtc->base.base.id, crtc->base.name);

-- 
Jani Nikula, Intel

Re: [RFC PATCH v3 2/2] drm/i915/display: Synchronize crtc_state for initial commit

[Juasheem Sultan]

[-- Attachment #1: Type: text/plain, Size: 8563 bytes --]

> I'd like to see logs of what the differences are.

Here's the logs from the pipe_config_compare without my patch:
<6>[   43.743023] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.enable (expected yes, found no)
<6>[   43.763730] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.active (expected yes, found no)
<6>[   43.789093] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in cpu_transcoder (expected 0, found -1)
<6>[   43.814759] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met ihw.enablen lane_count (expected 2, found 0)
<6>[   43.835751] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in dp_m_n (expected tu 64 data 8007832/8388608 link
333659/524288, found tu 0, data 0/0 link 0/0)
<6>[   43.835753] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in output_types (expected 0x00000100, found 0x00000000)
<6>[   43.835754] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in framestart_delay (expected 1, found 0)
<6>[   43.856743] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.pipe_mode.crtc_hdisplay (expected 1920, found 0)
<6>[   43.888602] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.pipe_mode.crtc_htotal (expected 2080, found 0)
<6>[   43.888603] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.pipe_mode.crtc_hblank_start (expected 1920, found
0)
<6>[   43.888604] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.pipe_mode.crtc_hblank_end (expected 2080, found 0)
<6>[   43.888604] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.pipe_mode.crtc_hsync_start (expected 1966, found
0)
<6>[   43.888605] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.pipe_mode.crtc_hsync_end (expected 1996, found 0)
<6>[   43.888605] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.pipe_mode.crtc_vdisplay (expected 1200, found 0)
<6>[   43.888606] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.pipe_mode.crtc_vsync_start (expected 1210, found
0)
<6>[   43.888607] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.pipe_mode.crtc_vsync_end (expected 1216, found 0)
<6>[   43.911732] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.pipe_mode.crtc_vtotal (expected 1236, found 0)
<6>[   43.911733] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.pipe_mode.crtc_vblank_end (expected 1236, found 0)
<6>[   43.932520] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.adjusted_mode.crtc_hdisplay (expected 1920, found
0)
<6>[   43.960305] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.adjusted_mode.crtc_htotal (expected 2080, found 0)
<6>[   43.960306] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.adjusted_mode.crtc_hblank_start (expected 1920,
found 0)
<6>[   43.960306] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.adjusted_mode.crtc_hblank_end (expected 2080,
found 0)
<6>[   43.960307] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.adjusted_mode.crtc_hsync_start (expected 1966,
found 0)
<6>[   43.960307] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.adjusted_mode.crtc_hsync_end (expected 1996,
found 0)
<6>[   43.960308] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.adjusted_mode.crtc_vdisplay (expected 1200, found
0)
<6>[   43.960308] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.adjusted_mode.crtc_vsync_start (expected 1210,
found 0)
<6>[   43.960309] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.adjusted_mode.crtc_vsync_end (expected 1216,
found 0)
<6>[   43.960310] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.adjusted_mode.crtc_vtotal (expected 1236, found 0)
<6>[   43.960310] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.adjusted_mode.crtc_vblank_end (expected 1236,
found 0)
<6>[   43.988392] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in pixel_multiplier (expected 1, found 0)
<6>[   43.988393] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.adjusted_mode.flags (2) (expected 2, found 0)
<6>[   44.016086] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.adjusted_mode.flags (8) (expected 8, found 0)
<6>[   44.016087] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in enhanced_framing (expected yes, found no)
<6>[   44.016088] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in pipe_bpp (expected 24, found 0)
<6>[   44.044074] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.pipe_mode.crtc_clock (expected 154647, found 0)
<6>[   44.044075] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in hw.adjusted_mode.crtc_clock (expected 154647, found
0)
<6>[   44.044075] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in port_clock (expected 243000, found 0)
<6>[   44.044077] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met in vrr.guardband (expected 35, found 0)
<6>[   44.065890] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
requirement not met, forcing full modeset

On Thu, Jan 22, 2026 at 7:29 AM Jani Nikula <jani.nikula@linux.intel.com>
wrote:

> On Wed, 21 Jan 2026, Juasheem Sultan <jdsultan@google.com> wrote:
> > When attempting the initial commit, there is a mismatch between
> > the new crtc_state and the old crtc_state. This causes us to fail the
> > pipe_config comparison and force a modeset. In the case where we are
> > inheriting an initialized state, we can sync the new and the old state
> > to pass the comparison and allow us to do a fastset and achieve an
> > uninterrupted handoff to userspace.
> >
> > Signed-off-by: Juasheem Sultan <jdsultan@google.com>
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c | 19 +++++++++++++++++++
> >  1 file changed, 19 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> > index 0d527cf22866..6eef4bd2e251 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -5736,6 +5736,25 @@ static void intel_crtc_check_fastset(const struct
> intel_crtc_state *old_crtc_sta
> >       if (old_crtc_state->vrr.in_range != new_crtc_state->vrr.in_range)
> >               new_crtc_state->update_lrr = false;
> >
> > +     /* Copying crtc state if inheriting an old state for commit */
> > +     if (old_crtc_state->inherited) {
> > +             new_crtc_state->hw = old_crtc_state->hw;
> > +
> > +             new_crtc_state->port_clock = old_crtc_state->port_clock;
> > +             new_crtc_state->pipe_bpp = old_crtc_state->pipe_bpp;
> > +             new_crtc_state->cpu_transcoder =
> old_crtc_state->cpu_transcoder;
> > +             new_crtc_state->lane_count = old_crtc_state->lane_count;
> > +             new_crtc_state->output_types =
> old_crtc_state->output_types;
> > +             new_crtc_state->dp_m_n = old_crtc_state->dp_m_n;
> > +             new_crtc_state->framestart_delay =
> old_crtc_state->framestart_delay;
> > +             new_crtc_state->pixel_multiplier =
> old_crtc_state->pixel_multiplier;
> > +             new_crtc_state->pixel_rate = old_crtc_state->pixel_rate;
> > +             new_crtc_state->enhanced_framing =
> old_crtc_state->enhanced_framing;
> > +             new_crtc_state->dpll_hw_state =
> old_crtc_state->dpll_hw_state;
> > +             new_crtc_state->intel_dpll = old_crtc_state->intel_dpll;
> > +             new_crtc_state->vrr.guardband =
> old_crtc_state->vrr.guardband;
>
> I'd like to see logs of what the differences are.
>
> BR,
> Jani.
>
> > +     }
> > +
> >       if (!intel_pipe_config_compare(old_crtc_state, new_crtc_state,
> true)) {
> >               drm_dbg_kms(display->drm, "[CRTC:%d:%s] fastset
> requirement not met, forcing full modeset\n",
> >                           crtc->base.base.id, crtc->base.name);
>
> --
> Jani Nikula, Intel
>

[-- Attachment #2: Type: text/html, Size: 9962 bytes --]

Re: [RFC PATCH v3 2/2] drm/i915/display: Synchronize crtc_state for initial commit

[Manasi Navare]

[-- Attachment #1: Type: text/plain, Size: 9427 bytes --]

Thanks Jausheem for the pipe mismatch logs without your patch. And so with
your patch now since you set new_crtc_state to old_crtc_state, this goes
away and it meets the fastset right?

@Jani Nikula <jani.nikula@intel.com> : Did you want to take a look at any
other logs? The above logs are stripped out from kernel logging without his
patch and with his patch it becomes a fastset as expected.
Let us know if there is any other feedback to improve the design for
enabling seamless boot?

Regards
Manasi

On Tue, Jan 27, 2026 at 12:05 AM Juasheem Sultan <jdsultan@google.com>
wrote:

> > I'd like to see logs of what the differences are.
>
> Here's the logs from the pipe_config_compare without my patch:
> <6>[   43.743023] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.enable (expected yes, found no)
> <6>[   43.763730] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.active (expected yes, found no)
> <6>[   43.789093] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in cpu_transcoder (expected 0, found -1)
> <6>[   43.814759] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met ihw.enablen lane_count (expected 2, found 0)
> <6>[   43.835751] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in dp_m_n (expected tu 64 data 8007832/8388608 link
> 333659/524288, found tu 0, data 0/0 link 0/0)
> <6>[   43.835753] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in output_types (expected 0x00000100, found 0x00000000)
> <6>[   43.835754] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in framestart_delay (expected 1, found 0)
> <6>[   43.856743] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.pipe_mode.crtc_hdisplay (expected 1920, found 0)
> <6>[   43.888602] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.pipe_mode.crtc_htotal (expected 2080, found 0)
> <6>[   43.888603] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.pipe_mode.crtc_hblank_start (expected 1920, found
> 0)
> <6>[   43.888604] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.pipe_mode.crtc_hblank_end (expected 2080, found 0)
> <6>[   43.888604] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.pipe_mode.crtc_hsync_start (expected 1966, found
> 0)
> <6>[   43.888605] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.pipe_mode.crtc_hsync_end (expected 1996, found 0)
> <6>[   43.888605] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.pipe_mode.crtc_vdisplay (expected 1200, found 0)
> <6>[   43.888606] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.pipe_mode.crtc_vsync_start (expected 1210, found
> 0)
> <6>[   43.888607] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.pipe_mode.crtc_vsync_end (expected 1216, found 0)
> <6>[   43.911732] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.pipe_mode.crtc_vtotal (expected 1236, found 0)
> <6>[   43.911733] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.pipe_mode.crtc_vblank_end (expected 1236, found 0)
> <6>[   43.932520] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.adjusted_mode.crtc_hdisplay (expected 1920, found
> 0)
> <6>[   43.960305] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.adjusted_mode.crtc_htotal (expected 2080, found 0)
> <6>[   43.960306] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.adjusted_mode.crtc_hblank_start (expected 1920,
> found 0)
> <6>[   43.960306] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.adjusted_mode.crtc_hblank_end (expected 2080,
> found 0)
> <6>[   43.960307] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.adjusted_mode.crtc_hsync_start (expected 1966,
> found 0)
> <6>[   43.960307] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.adjusted_mode.crtc_hsync_end (expected 1996,
> found 0)
> <6>[   43.960308] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.adjusted_mode.crtc_vdisplay (expected 1200, found
> 0)
> <6>[   43.960308] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.adjusted_mode.crtc_vsync_start (expected 1210,
> found 0)
> <6>[   43.960309] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.adjusted_mode.crtc_vsync_end (expected 1216,
> found 0)
> <6>[   43.960310] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.adjusted_mode.crtc_vtotal (expected 1236, found 0)
> <6>[   43.960310] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.adjusted_mode.crtc_vblank_end (expected 1236,
> found 0)
> <6>[   43.988392] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in pixel_multiplier (expected 1, found 0)
> <6>[   43.988393] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.adjusted_mode.flags (2) (expected 2, found 0)
> <6>[   44.016086] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.adjusted_mode.flags (8) (expected 8, found 0)
> <6>[   44.016087] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in enhanced_framing (expected yes, found no)
> <6>[   44.016088] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in pipe_bpp (expected 24, found 0)
> <6>[   44.044074] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.pipe_mode.crtc_clock (expected 154647, found 0)
> <6>[   44.044075] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in hw.adjusted_mode.crtc_clock (expected 154647, found
> 0)
> <6>[   44.044075] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in port_clock (expected 243000, found 0)
> <6>[   44.044077] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met in vrr.guardband (expected 35, found 0)
> <6>[   44.065890] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> requirement not met, forcing full modeset
>
> On Thu, Jan 22, 2026 at 7:29 AM Jani Nikula <jani.nikula@linux.intel.com>
> wrote:
>
>> On Wed, 21 Jan 2026, Juasheem Sultan <jdsultan@google.com> wrote:
>> > When attempting the initial commit, there is a mismatch between
>> > the new crtc_state and the old crtc_state. This causes us to fail the
>> > pipe_config comparison and force a modeset. In the case where we are
>> > inheriting an initialized state, we can sync the new and the old state
>> > to pass the comparison and allow us to do a fastset and achieve an
>> > uninterrupted handoff to userspace.
>> >
>> > Signed-off-by: Juasheem Sultan <jdsultan@google.com>
>> > ---
>> >  drivers/gpu/drm/i915/display/intel_display.c | 19 +++++++++++++++++++
>> >  1 file changed, 19 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>> b/drivers/gpu/drm/i915/display/intel_display.c
>> > index 0d527cf22866..6eef4bd2e251 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_display.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> > @@ -5736,6 +5736,25 @@ static void intel_crtc_check_fastset(const
>> struct intel_crtc_state *old_crtc_sta
>> >       if (old_crtc_state->vrr.in_range != new_crtc_state->vrr.in_range)
>> >               new_crtc_state->update_lrr = false;
>> >
>> > +     /* Copying crtc state if inheriting an old state for commit */
>> > +     if (old_crtc_state->inherited) {
>> > +             new_crtc_state->hw = old_crtc_state->hw;
>> > +
>> > +             new_crtc_state->port_clock = old_crtc_state->port_clock;
>> > +             new_crtc_state->pipe_bpp = old_crtc_state->pipe_bpp;
>> > +             new_crtc_state->cpu_transcoder =
>> old_crtc_state->cpu_transcoder;
>> > +             new_crtc_state->lane_count = old_crtc_state->lane_count;
>> > +             new_crtc_state->output_types =
>> old_crtc_state->output_types;
>> > +             new_crtc_state->dp_m_n = old_crtc_state->dp_m_n;
>> > +             new_crtc_state->framestart_delay =
>> old_crtc_state->framestart_delay;
>> > +             new_crtc_state->pixel_multiplier =
>> old_crtc_state->pixel_multiplier;
>> > +             new_crtc_state->pixel_rate = old_crtc_state->pixel_rate;
>> > +             new_crtc_state->enhanced_framing =
>> old_crtc_state->enhanced_framing;
>> > +             new_crtc_state->dpll_hw_state =
>> old_crtc_state->dpll_hw_state;
>> > +             new_crtc_state->intel_dpll = old_crtc_state->intel_dpll;
>> > +             new_crtc_state->vrr.guardband =
>> old_crtc_state->vrr.guardband;
>>
>> I'd like to see logs of what the differences are.
>>
>> BR,
>> Jani.
>>
>> > +     }
>> > +
>> >       if (!intel_pipe_config_compare(old_crtc_state, new_crtc_state,
>> true)) {
>> >               drm_dbg_kms(display->drm, "[CRTC:%d:%s] fastset
>> requirement not met, forcing full modeset\n",
>> >                           crtc->base.base.id, crtc->base.name);
>>
>> --
>> Jani Nikula, Intel
>>
>

[-- Attachment #2: Type: text/html, Size: 10977 bytes --]

Re: [RFC PATCH v3 2/2] drm/i915/display: Synchronize crtc_state for initial commit

[Jani Nikula]

On Tue, 03 Feb 2026, Manasi Navare <navaremanasi@google.com> wrote:
> Thanks Jausheem for the pipe mismatch logs without your patch. And so with
> your patch now since you set new_crtc_state to old_crtc_state, this goes
> away and it meets the fastset right?
>
> @Jani Nikula <jani.nikula@intel.com> : Did you want to take a look at any
> other logs? The above logs are stripped out from kernel logging without his
> patch and with his patch it becomes a fastset as expected.
> Let us know if there is any other feedback to improve the design for
> enabling seamless boot?

I think it would be better to file an issue at fdo gitlab and attach the
full logs with debugs as described at [1]. The short snippets don't
really give a good picture of what's going on.

The initial commit should be about 1) reading out the hw state to sw
state, 2) some sanitization steps where there might be discrepancies
between read out state and what would be the computed state, 3) ensuring
everything matches in the initial commit so fastset is possible.

In the below log snippet, everything's being turned off. That's not just
about some individual values differing and requiring a full
modeset. It's hard to say what's going on. But simply copying the state
over is not the way to go.


BR,
Jani.



[1] https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html

>
> Regards
> Manasi
>
> On Tue, Jan 27, 2026 at 12:05 AM Juasheem Sultan <jdsultan@google.com>
> wrote:
>
>> > I'd like to see logs of what the differences are.
>>
>> Here's the logs from the pipe_config_compare without my patch:
>> <6>[   43.743023] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.enable (expected yes, found no)
>> <6>[   43.763730] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.active (expected yes, found no)
>> <6>[   43.789093] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in cpu_transcoder (expected 0, found -1)
>> <6>[   43.814759] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met ihw.enablen lane_count (expected 2, found 0)
>> <6>[   43.835751] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in dp_m_n (expected tu 64 data 8007832/8388608 link
>> 333659/524288, found tu 0, data 0/0 link 0/0)
>> <6>[   43.835753] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in output_types (expected 0x00000100, found 0x00000000)
>> <6>[   43.835754] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in framestart_delay (expected 1, found 0)
>> <6>[   43.856743] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.pipe_mode.crtc_hdisplay (expected 1920, found 0)
>> <6>[   43.888602] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.pipe_mode.crtc_htotal (expected 2080, found 0)
>> <6>[   43.888603] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.pipe_mode.crtc_hblank_start (expected 1920, found
>> 0)
>> <6>[   43.888604] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.pipe_mode.crtc_hblank_end (expected 2080, found 0)
>> <6>[   43.888604] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.pipe_mode.crtc_hsync_start (expected 1966, found
>> 0)
>> <6>[   43.888605] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.pipe_mode.crtc_hsync_end (expected 1996, found 0)
>> <6>[   43.888605] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.pipe_mode.crtc_vdisplay (expected 1200, found 0)
>> <6>[   43.888606] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.pipe_mode.crtc_vsync_start (expected 1210, found
>> 0)
>> <6>[   43.888607] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.pipe_mode.crtc_vsync_end (expected 1216, found 0)
>> <6>[   43.911732] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.pipe_mode.crtc_vtotal (expected 1236, found 0)
>> <6>[   43.911733] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.pipe_mode.crtc_vblank_end (expected 1236, found 0)
>> <6>[   43.932520] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.adjusted_mode.crtc_hdisplay (expected 1920, found
>> 0)
>> <6>[   43.960305] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.adjusted_mode.crtc_htotal (expected 2080, found 0)
>> <6>[   43.960306] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.adjusted_mode.crtc_hblank_start (expected 1920,
>> found 0)
>> <6>[   43.960306] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.adjusted_mode.crtc_hblank_end (expected 2080,
>> found 0)
>> <6>[   43.960307] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.adjusted_mode.crtc_hsync_start (expected 1966,
>> found 0)
>> <6>[   43.960307] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.adjusted_mode.crtc_hsync_end (expected 1996,
>> found 0)
>> <6>[   43.960308] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.adjusted_mode.crtc_vdisplay (expected 1200, found
>> 0)
>> <6>[   43.960308] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.adjusted_mode.crtc_vsync_start (expected 1210,
>> found 0)
>> <6>[   43.960309] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.adjusted_mode.crtc_vsync_end (expected 1216,
>> found 0)
>> <6>[   43.960310] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.adjusted_mode.crtc_vtotal (expected 1236, found 0)
>> <6>[   43.960310] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.adjusted_mode.crtc_vblank_end (expected 1236,
>> found 0)
>> <6>[   43.988392] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in pixel_multiplier (expected 1, found 0)
>> <6>[   43.988393] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.adjusted_mode.flags (2) (expected 2, found 0)
>> <6>[   44.016086] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.adjusted_mode.flags (8) (expected 8, found 0)
>> <6>[   44.016087] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in enhanced_framing (expected yes, found no)
>> <6>[   44.016088] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in pipe_bpp (expected 24, found 0)
>> <6>[   44.044074] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.pipe_mode.crtc_clock (expected 154647, found 0)
>> <6>[   44.044075] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in hw.adjusted_mode.crtc_clock (expected 154647, found
>> 0)
>> <6>[   44.044075] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in port_clock (expected 243000, found 0)
>> <6>[   44.044077] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met in vrr.guardband (expected 35, found 0)
>> <6>[   44.065890] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> requirement not met, forcing full modeset
>>
>> On Thu, Jan 22, 2026 at 7:29 AM Jani Nikula <jani.nikula@linux.intel.com>
>> wrote:
>>
>>> On Wed, 21 Jan 2026, Juasheem Sultan <jdsultan@google.com> wrote:
>>> > When attempting the initial commit, there is a mismatch between
>>> > the new crtc_state and the old crtc_state. This causes us to fail the
>>> > pipe_config comparison and force a modeset. In the case where we are
>>> > inheriting an initialized state, we can sync the new and the old state
>>> > to pass the comparison and allow us to do a fastset and achieve an
>>> > uninterrupted handoff to userspace.
>>> >
>>> > Signed-off-by: Juasheem Sultan <jdsultan@google.com>
>>> > ---
>>> >  drivers/gpu/drm/i915/display/intel_display.c | 19 +++++++++++++++++++
>>> >  1 file changed, 19 insertions(+)
>>> >
>>> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>>> b/drivers/gpu/drm/i915/display/intel_display.c
>>> > index 0d527cf22866..6eef4bd2e251 100644
>>> > --- a/drivers/gpu/drm/i915/display/intel_display.c
>>> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
>>> > @@ -5736,6 +5736,25 @@ static void intel_crtc_check_fastset(const
>>> struct intel_crtc_state *old_crtc_sta
>>> >       if (old_crtc_state->vrr.in_range != new_crtc_state->vrr.in_range)
>>> >               new_crtc_state->update_lrr = false;
>>> >
>>> > +     /* Copying crtc state if inheriting an old state for commit */
>>> > +     if (old_crtc_state->inherited) {
>>> > +             new_crtc_state->hw = old_crtc_state->hw;
>>> > +
>>> > +             new_crtc_state->port_clock = old_crtc_state->port_clock;
>>> > +             new_crtc_state->pipe_bpp = old_crtc_state->pipe_bpp;
>>> > +             new_crtc_state->cpu_transcoder =
>>> old_crtc_state->cpu_transcoder;
>>> > +             new_crtc_state->lane_count = old_crtc_state->lane_count;
>>> > +             new_crtc_state->output_types =
>>> old_crtc_state->output_types;
>>> > +             new_crtc_state->dp_m_n = old_crtc_state->dp_m_n;
>>> > +             new_crtc_state->framestart_delay =
>>> old_crtc_state->framestart_delay;
>>> > +             new_crtc_state->pixel_multiplier =
>>> old_crtc_state->pixel_multiplier;
>>> > +             new_crtc_state->pixel_rate = old_crtc_state->pixel_rate;
>>> > +             new_crtc_state->enhanced_framing =
>>> old_crtc_state->enhanced_framing;
>>> > +             new_crtc_state->dpll_hw_state =
>>> old_crtc_state->dpll_hw_state;
>>> > +             new_crtc_state->intel_dpll = old_crtc_state->intel_dpll;
>>> > +             new_crtc_state->vrr.guardband =
>>> old_crtc_state->vrr.guardband;
>>>
>>> I'd like to see logs of what the differences are.
>>>
>>> BR,
>>> Jani.
>>>
>>> > +     }
>>> > +
>>> >       if (!intel_pipe_config_compare(old_crtc_state, new_crtc_state,
>>> true)) {
>>> >               drm_dbg_kms(display->drm, "[CRTC:%d:%s] fastset
>>> requirement not met, forcing full modeset\n",
>>> >                           crtc->base.base.id, crtc->base.name);
>>>
>>> --
>>> Jani Nikula, Intel
>>>
>>

-- 
Jani Nikula, Intel

Re: [RFC PATCH v3 2/2] drm/i915/display: Synchronize crtc_state for initial commit

[Manasi Navare]

[-- Attachment #1: Type: text/plain, Size: 12450 bytes --]

On Tue, Feb 3, 2026 at 11:47 AM Jani Nikula <jani.nikula@intel.com> wrote:

> On Tue, 03 Feb 2026, Manasi Navare <navaremanasi@google.com> wrote:
> > Thanks Jausheem for the pipe mismatch logs without your patch. And so
> with
> > your patch now since you set new_crtc_state to old_crtc_state, this goes
> > away and it meets the fastset right?
> >
> > @Jani Nikula <jani.nikula@intel.com> : Did you want to take a look at
> any
> > other logs? The above logs are stripped out from kernel logging without
> his
> > patch and with his patch it becomes a fastset as expected.
> > Let us know if there is any other feedback to improve the design for
> > enabling seamless boot?
>
> I think it would be better to file an issue at fdo gitlab and attach the
> full logs with debugs as described at [1]. The short snippets don't
> really give a good picture of what's going on.
>
> The initial commit should be about 1) reading out the hw state to sw
> state, 2) some sanitization steps where there might be discrepancies
> between read out state and what would be the computed state, 3) ensuring
> everything matches in the initial commit so fastset is possible.
>
> In the below log snippet, everything's being turned off. That's not just
> about some individual values differing and requiring a full
> modeset. It's hard to say what's going on. But simply copying the state
> over is not the way to go.
>

Thanks Jani for your feedback.
@Jani Nikula <jani.nikula@intel.com>  so ideally the expectation would be
that if the FW is initializing the HW to a state, then we should do a
readout
and save that into pipe_config and that should have the values set by the
FW and now next would be to make sure that
the new_crtc_state matches those values ensuring fastset, is that the
correct understanding?
We are possibly missing that HW state readout, since FW programs the HW,
the pipe_config is still all 0s unless
we add the HW state readout and set pipe_config to that?

@Jausheem, we need to understand why everything is turned off on the HW
because of which during the readout,
where the pipe_config_compare throws a mismatch we see that in the
pipe_config (Found values) are all 0.
If we expect that the fimware has programmed the HW to some initial value,
which it should have then
the HW state read out or the found values should not be all 0s.
Could we double check that hw state read out has the values that FW has set
it to,
without your patch and making sure DRM HWC is not clearing out all the
crtcs/connectors
on the initial modeset (so reverting that clean up patch).

As per Jani's suggestion if that is not the case, we can file a bug against
the kernel at FDO and have them triage this.

Regards
Manasi

>
>
> BR,
> Jani.
>
>
>
> [1]
> https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html
>
> >
> > Regards
> > Manasi
> >
> > On Tue, Jan 27, 2026 at 12:05 AM Juasheem Sultan <jdsultan@google.com>
> > wrote:
> >
> >> > I'd like to see logs of what the differences are.
> >>
> >> Here's the logs from the pipe_config_compare without my patch:
> >> <6>[   43.743023] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.enable (expected yes, found no)
> >> <6>[   43.763730] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.active (expected yes, found no)
> >> <6>[   43.789093] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in cpu_transcoder (expected 0, found -1)
> >> <6>[   43.814759] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met ihw.enablen lane_count (expected 2, found 0)
> >> <6>[   43.835751] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in dp_m_n (expected tu 64 data 8007832/8388608 link
> >> 333659/524288, found tu 0, data 0/0 link 0/0)
> >> <6>[   43.835753] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in output_types (expected 0x00000100, found
> 0x00000000)
> >> <6>[   43.835754] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in framestart_delay (expected 1, found 0)
> >> <6>[   43.856743] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.pipe_mode.crtc_hdisplay (expected 1920, found
> 0)
> >> <6>[   43.888602] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.pipe_mode.crtc_htotal (expected 2080, found 0)
> >> <6>[   43.888603] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.pipe_mode.crtc_hblank_start (expected 1920,
> found
> >> 0)
> >> <6>[   43.888604] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.pipe_mode.crtc_hblank_end (expected 2080,
> found 0)
> >> <6>[   43.888604] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.pipe_mode.crtc_hsync_start (expected 1966,
> found
> >> 0)
> >> <6>[   43.888605] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.pipe_mode.crtc_hsync_end (expected 1996,
> found 0)
> >> <6>[   43.888605] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.pipe_mode.crtc_vdisplay (expected 1200, found
> 0)
> >> <6>[   43.888606] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.pipe_mode.crtc_vsync_start (expected 1210,
> found
> >> 0)
> >> <6>[   43.888607] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.pipe_mode.crtc_vsync_end (expected 1216,
> found 0)
> >> <6>[   43.911732] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.pipe_mode.crtc_vtotal (expected 1236, found 0)
> >> <6>[   43.911733] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.pipe_mode.crtc_vblank_end (expected 1236,
> found 0)
> >> <6>[   43.932520] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.adjusted_mode.crtc_hdisplay (expected 1920,
> found
> >> 0)
> >> <6>[   43.960305] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.adjusted_mode.crtc_htotal (expected 2080,
> found 0)
> >> <6>[   43.960306] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.adjusted_mode.crtc_hblank_start (expected
> 1920,
> >> found 0)
> >> <6>[   43.960306] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.adjusted_mode.crtc_hblank_end (expected 2080,
> >> found 0)
> >> <6>[   43.960307] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.adjusted_mode.crtc_hsync_start (expected 1966,
> >> found 0)
> >> <6>[   43.960307] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.adjusted_mode.crtc_hsync_end (expected 1996,
> >> found 0)
> >> <6>[   43.960308] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.adjusted_mode.crtc_vdisplay (expected 1200,
> found
> >> 0)
> >> <6>[   43.960308] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.adjusted_mode.crtc_vsync_start (expected 1210,
> >> found 0)
> >> <6>[   43.960309] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.adjusted_mode.crtc_vsync_end (expected 1216,
> >> found 0)
> >> <6>[   43.960310] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.adjusted_mode.crtc_vtotal (expected 1236,
> found 0)
> >> <6>[   43.960310] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.adjusted_mode.crtc_vblank_end (expected 1236,
> >> found 0)
> >> <6>[   43.988392] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in pixel_multiplier (expected 1, found 0)
> >> <6>[   43.988393] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.adjusted_mode.flags (2) (expected 2, found 0)
> >> <6>[   44.016086] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.adjusted_mode.flags (8) (expected 8, found 0)
> >> <6>[   44.016087] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in enhanced_framing (expected yes, found no)
> >> <6>[   44.016088] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in pipe_bpp (expected 24, found 0)
> >> <6>[   44.044074] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.pipe_mode.crtc_clock (expected 154647, found
> 0)
> >> <6>[   44.044075] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in hw.adjusted_mode.crtc_clock (expected 154647,
> found
> >> 0)
> >> <6>[   44.044075] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in port_clock (expected 243000, found 0)
> >> <6>[   44.044077] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met in vrr.guardband (expected 35, found 0)
> >> <6>[   44.065890] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
> >> requirement not met, forcing full modeset
> >>
> >> On Thu, Jan 22, 2026 at 7:29 AM Jani Nikula <
> jani.nikula@linux.intel.com>
> >> wrote:
> >>
> >>> On Wed, 21 Jan 2026, Juasheem Sultan <jdsultan@google.com> wrote:
> >>> > When attempting the initial commit, there is a mismatch between
> >>> > the new crtc_state and the old crtc_state. This causes us to fail the
> >>> > pipe_config comparison and force a modeset. In the case where we are
> >>> > inheriting an initialized state, we can sync the new and the old
> state
> >>> > to pass the comparison and allow us to do a fastset and achieve an
> >>> > uninterrupted handoff to userspace.
> >>> >
> >>> > Signed-off-by: Juasheem Sultan <jdsultan@google.com>
> >>> > ---
> >>> >  drivers/gpu/drm/i915/display/intel_display.c | 19
> +++++++++++++++++++
> >>> >  1 file changed, 19 insertions(+)
> >>> >
> >>> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> >>> b/drivers/gpu/drm/i915/display/intel_display.c
> >>> > index 0d527cf22866..6eef4bd2e251 100644
> >>> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> >>> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> >>> > @@ -5736,6 +5736,25 @@ static void intel_crtc_check_fastset(const
> >>> struct intel_crtc_state *old_crtc_sta
> >>> >       if (old_crtc_state->vrr.in_range !=
> new_crtc_state->vrr.in_range)
> >>> >               new_crtc_state->update_lrr = false;
> >>> >
> >>> > +     /* Copying crtc state if inheriting an old state for commit */
> >>> > +     if (old_crtc_state->inherited) {
> >>> > +             new_crtc_state->hw = old_crtc_state->hw;
> >>> > +
> >>> > +             new_crtc_state->port_clock =
> old_crtc_state->port_clock;
> >>> > +             new_crtc_state->pipe_bpp = old_crtc_state->pipe_bpp;
> >>> > +             new_crtc_state->cpu_transcoder =
> >>> old_crtc_state->cpu_transcoder;
> >>> > +             new_crtc_state->lane_count =
> old_crtc_state->lane_count;
> >>> > +             new_crtc_state->output_types =
> >>> old_crtc_state->output_types;
> >>> > +             new_crtc_state->dp_m_n = old_crtc_state->dp_m_n;
> >>> > +             new_crtc_state->framestart_delay =
> >>> old_crtc_state->framestart_delay;
> >>> > +             new_crtc_state->pixel_multiplier =
> >>> old_crtc_state->pixel_multiplier;
> >>> > +             new_crtc_state->pixel_rate =
> old_crtc_state->pixel_rate;
> >>> > +             new_crtc_state->enhanced_framing =
> >>> old_crtc_state->enhanced_framing;
> >>> > +             new_crtc_state->dpll_hw_state =
> >>> old_crtc_state->dpll_hw_state;
> >>> > +             new_crtc_state->intel_dpll =
> old_crtc_state->intel_dpll;
> >>> > +             new_crtc_state->vrr.guardband =
> >>> old_crtc_state->vrr.guardband;
> >>>
> >>> I'd like to see logs of what the differences are.
> >>>
> >>> BR,
> >>> Jani.
> >>>
> >>> > +     }
> >>> > +
> >>> >       if (!intel_pipe_config_compare(old_crtc_state, new_crtc_state,
> >>> true)) {
> >>> >               drm_dbg_kms(display->drm, "[CRTC:%d:%s] fastset
> >>> requirement not met, forcing full modeset\n",
> >>> >                           crtc->base.base.id, crtc->base.name);
> >>>
> >>> --
> >>> Jani Nikula, Intel
> >>>
> >>
>
> --
> Jani Nikula, Intel
>

[-- Attachment #2: Type: text/html, Size: 16118 bytes --]

Re: [RFC PATCH v3 2/2] drm/i915/display: Synchronize crtc_state for initial commit

[Manasi Navare]

[-- Attachment #1: Type: text/plain, Size: 13914 bytes --]

Hi @Jani Nikula <jani.nikula@intel.com> :

Before we file a fdo issue with complete debug logs to understand what the
FW is setting up the HW at, I wanted to understand a few more things in
terms of the final solution:

-  Ideally if the FW is setting up the initial state or programming the HW
registers for the initial splashscreen, for the initial commit when we do
the HW state readout, it should have the HW values programmed to some mode
parameters
-  Then like you suggested, we would need to read out the HW state
- Could you elaborate on "1) reading out the hw state to sw
state? - Does that mean do the HW state readout and compute
pipe_config/crtc_state for that?

- Then add some sanitization to have this computed pipe_config that will be
programmed to the HW
- Then ensure that both are same so that the intel fastset logic can apply
fastset?

It would be great if you can reply so that we can collect the necessary
logs, file a bug report on fdo and also send the next ervision of the
patches.

Regards
Manasi
On Tue, Feb 3, 2026 at 1:03 PM Manasi Navare <navaremanasi@google.com>
wrote:

>
>
> On Tue, Feb 3, 2026 at 11:47 AM Jani Nikula <jani.nikula@intel.com> wrote:
>
>> On Tue, 03 Feb 2026, Manasi Navare <navaremanasi@google.com> wrote:
>> > Thanks Jausheem for the pipe mismatch logs without your patch. And so
>> with
>> > your patch now since you set new_crtc_state to old_crtc_state, this goes
>> > away and it meets the fastset right?
>> >
>> > @Jani Nikula <jani.nikula@intel.com> : Did you want to take a look at
>> any
>> > other logs? The above logs are stripped out from kernel logging without
>> his
>> > patch and with his patch it becomes a fastset as expected.
>> > Let us know if there is any other feedback to improve the design for
>> > enabling seamless boot?
>>
>> I think it would be better to file an issue at fdo gitlab and attach the
>> full logs with debugs as described at [1]. The short snippets don't
>> really give a good picture of what's going on.
>>
>> The initial commit should be about 1) reading out the hw state to sw
>> state, 2) some sanitization steps where there might be discrepancies
>> between read out state and what would be the computed state, 3) ensuring
>> everything matches in the initial commit so fastset is possible.
>>
>> In the below log snippet, everything's being turned off. That's not just
>> about some individual values differing and requiring a full
>> modeset. It's hard to say what's going on. But simply copying the state
>> over is not the way to go.
>>
>
> Thanks Jani for your feedback.
> @Jani Nikula <jani.nikula@intel.com>  so ideally the expectation would be
> that if the FW is initializing the HW to a state, then we should do a
> readout
> and save that into pipe_config and that should have the values set by the
> FW and now next would be to make sure that
> the new_crtc_state matches those values ensuring fastset, is that the
> correct understanding?
> We are possibly missing that HW state readout, since FW programs the HW,
> the pipe_config is still all 0s unless
> we add the HW state readout and set pipe_config to that?
>
> @Jausheem, we need to understand why everything is turned off on the HW
> because of which during the readout,
> where the pipe_config_compare throws a mismatch we see that in the
> pipe_config (Found values) are all 0.
> If we expect that the fimware has programmed the HW to some initial value,
> which it should have then
> the HW state read out or the found values should not be all 0s.
> Could we double check that hw state read out has the values that FW has
> set it to,
> without your patch and making sure DRM HWC is not clearing out all the
> crtcs/connectors
> on the initial modeset (so reverting that clean up patch).
>
> As per Jani's suggestion if that is not the case, we can file a bug
> against the kernel at FDO and have them triage this.
>
> Regards
> Manasi
>
>>
>>
>> BR,
>> Jani.
>>
>>
>>
>> [1]
>> https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html
>>
>> >
>> > Regards
>> > Manasi
>> >
>> > On Tue, Jan 27, 2026 at 12:05 AM Juasheem Sultan <jdsultan@google.com>
>> > wrote:
>> >
>> >> > I'd like to see logs of what the differences are.
>> >>
>> >> Here's the logs from the pipe_config_compare without my patch:
>> >> <6>[   43.743023] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.enable (expected yes, found no)
>> >> <6>[   43.763730] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.active (expected yes, found no)
>> >> <6>[   43.789093] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in cpu_transcoder (expected 0, found -1)
>> >> <6>[   43.814759] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met ihw.enablen lane_count (expected 2, found 0)
>> >> <6>[   43.835751] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in dp_m_n (expected tu 64 data 8007832/8388608 link
>> >> 333659/524288, found tu 0, data 0/0 link 0/0)
>> >> <6>[   43.835753] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in output_types (expected 0x00000100, found
>> 0x00000000)
>> >> <6>[   43.835754] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in framestart_delay (expected 1, found 0)
>> >> <6>[   43.856743] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.pipe_mode.crtc_hdisplay (expected 1920,
>> found 0)
>> >> <6>[   43.888602] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.pipe_mode.crtc_htotal (expected 2080, found
>> 0)
>> >> <6>[   43.888603] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.pipe_mode.crtc_hblank_start (expected 1920,
>> found
>> >> 0)
>> >> <6>[   43.888604] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.pipe_mode.crtc_hblank_end (expected 2080,
>> found 0)
>> >> <6>[   43.888604] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.pipe_mode.crtc_hsync_start (expected 1966,
>> found
>> >> 0)
>> >> <6>[   43.888605] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.pipe_mode.crtc_hsync_end (expected 1996,
>> found 0)
>> >> <6>[   43.888605] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.pipe_mode.crtc_vdisplay (expected 1200,
>> found 0)
>> >> <6>[   43.888606] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.pipe_mode.crtc_vsync_start (expected 1210,
>> found
>> >> 0)
>> >> <6>[   43.888607] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.pipe_mode.crtc_vsync_end (expected 1216,
>> found 0)
>> >> <6>[   43.911732] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.pipe_mode.crtc_vtotal (expected 1236, found
>> 0)
>> >> <6>[   43.911733] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.pipe_mode.crtc_vblank_end (expected 1236,
>> found 0)
>> >> <6>[   43.932520] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.adjusted_mode.crtc_hdisplay (expected 1920,
>> found
>> >> 0)
>> >> <6>[   43.960305] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.adjusted_mode.crtc_htotal (expected 2080,
>> found 0)
>> >> <6>[   43.960306] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.adjusted_mode.crtc_hblank_start (expected
>> 1920,
>> >> found 0)
>> >> <6>[   43.960306] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.adjusted_mode.crtc_hblank_end (expected 2080,
>> >> found 0)
>> >> <6>[   43.960307] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.adjusted_mode.crtc_hsync_start (expected
>> 1966,
>> >> found 0)
>> >> <6>[   43.960307] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.adjusted_mode.crtc_hsync_end (expected 1996,
>> >> found 0)
>> >> <6>[   43.960308] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.adjusted_mode.crtc_vdisplay (expected 1200,
>> found
>> >> 0)
>> >> <6>[   43.960308] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.adjusted_mode.crtc_vsync_start (expected
>> 1210,
>> >> found 0)
>> >> <6>[   43.960309] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.adjusted_mode.crtc_vsync_end (expected 1216,
>> >> found 0)
>> >> <6>[   43.960310] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.adjusted_mode.crtc_vtotal (expected 1236,
>> found 0)
>> >> <6>[   43.960310] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.adjusted_mode.crtc_vblank_end (expected 1236,
>> >> found 0)
>> >> <6>[   43.988392] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in pixel_multiplier (expected 1, found 0)
>> >> <6>[   43.988393] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.adjusted_mode.flags (2) (expected 2, found 0)
>> >> <6>[   44.016086] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.adjusted_mode.flags (8) (expected 8, found 0)
>> >> <6>[   44.016087] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in enhanced_framing (expected yes, found no)
>> >> <6>[   44.016088] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in pipe_bpp (expected 24, found 0)
>> >> <6>[   44.044074] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.pipe_mode.crtc_clock (expected 154647, found
>> 0)
>> >> <6>[   44.044075] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in hw.adjusted_mode.crtc_clock (expected 154647,
>> found
>> >> 0)
>> >> <6>[   44.044075] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in port_clock (expected 243000, found 0)
>> >> <6>[   44.044077] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met in vrr.guardband (expected 35, found 0)
>> >> <6>[   44.065890] xe 0000:00:02.0: [drm] [CRTC:88:pipe A] fastset
>> >> requirement not met, forcing full modeset
>> >>
>> >> On Thu, Jan 22, 2026 at 7:29 AM Jani Nikula <
>> jani.nikula@linux.intel.com>
>> >> wrote:
>> >>
>> >>> On Wed, 21 Jan 2026, Juasheem Sultan <jdsultan@google.com> wrote:
>> >>> > When attempting the initial commit, there is a mismatch between
>> >>> > the new crtc_state and the old crtc_state. This causes us to fail
>> the
>> >>> > pipe_config comparison and force a modeset. In the case where we are
>> >>> > inheriting an initialized state, we can sync the new and the old
>> state
>> >>> > to pass the comparison and allow us to do a fastset and achieve an
>> >>> > uninterrupted handoff to userspace.
>> >>> >
>> >>> > Signed-off-by: Juasheem Sultan <jdsultan@google.com>
>> >>> > ---
>> >>> >  drivers/gpu/drm/i915/display/intel_display.c | 19
>> +++++++++++++++++++
>> >>> >  1 file changed, 19 insertions(+)
>> >>> >
>> >>> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>> >>> b/drivers/gpu/drm/i915/display/intel_display.c
>> >>> > index 0d527cf22866..6eef4bd2e251 100644
>> >>> > --- a/drivers/gpu/drm/i915/display/intel_display.c
>> >>> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> >>> > @@ -5736,6 +5736,25 @@ static void intel_crtc_check_fastset(const
>> >>> struct intel_crtc_state *old_crtc_sta
>> >>> >       if (old_crtc_state->vrr.in_range !=
>> new_crtc_state->vrr.in_range)
>> >>> >               new_crtc_state->update_lrr = false;
>> >>> >
>> >>> > +     /* Copying crtc state if inheriting an old state for commit */
>> >>> > +     if (old_crtc_state->inherited) {
>> >>> > +             new_crtc_state->hw = old_crtc_state->hw;
>> >>> > +
>> >>> > +             new_crtc_state->port_clock =
>> old_crtc_state->port_clock;
>> >>> > +             new_crtc_state->pipe_bpp = old_crtc_state->pipe_bpp;
>> >>> > +             new_crtc_state->cpu_transcoder =
>> >>> old_crtc_state->cpu_transcoder;
>> >>> > +             new_crtc_state->lane_count =
>> old_crtc_state->lane_count;
>> >>> > +             new_crtc_state->output_types =
>> >>> old_crtc_state->output_types;
>> >>> > +             new_crtc_state->dp_m_n = old_crtc_state->dp_m_n;
>> >>> > +             new_crtc_state->framestart_delay =
>> >>> old_crtc_state->framestart_delay;
>> >>> > +             new_crtc_state->pixel_multiplier =
>> >>> old_crtc_state->pixel_multiplier;
>> >>> > +             new_crtc_state->pixel_rate =
>> old_crtc_state->pixel_rate;
>> >>> > +             new_crtc_state->enhanced_framing =
>> >>> old_crtc_state->enhanced_framing;
>> >>> > +             new_crtc_state->dpll_hw_state =
>> >>> old_crtc_state->dpll_hw_state;
>> >>> > +             new_crtc_state->intel_dpll =
>> old_crtc_state->intel_dpll;
>> >>> > +             new_crtc_state->vrr.guardband =
>> >>> old_crtc_state->vrr.guardband;
>> >>>
>> >>> I'd like to see logs of what the differences are.
>> >>>
>> >>> BR,
>> >>> Jani.
>> >>>
>> >>> > +     }
>> >>> > +
>> >>> >       if (!intel_pipe_config_compare(old_crtc_state, new_crtc_state,
>> >>> true)) {
>> >>> >               drm_dbg_kms(display->drm, "[CRTC:%d:%s] fastset
>> >>> requirement not met, forcing full modeset\n",
>> >>> >                           crtc->base.base.id, crtc->base.name);
>> >>>
>> >>> --
>> >>> Jani Nikula, Intel
>> >>>
>> >>
>>
>> --
>> Jani Nikula, Intel
>>
>

[-- Attachment #2: Type: text/html, Size: 17806 bytes --]

Re: [RFC PATCH v3 2/2] drm/i915/display: Synchronize crtc_state for initial commit

[Jani Nikula]

On Mon, 02 Mar 2026, Manasi Navare <navaremanasi@google.com> wrote:
> Hi @Jani Nikula <jani.nikula@intel.com> :
>
> Before we file a fdo issue with complete debug logs to understand what the
> FW is setting up the HW at, I wanted to understand a few more things in
> terms of the final solution:
>
> -  Ideally if the FW is setting up the initial state or programming the HW
> registers for the initial splashscreen, for the initial commit when we do
> the HW state readout, it should have the HW values programmed to some mode
> parameters
> -  Then like you suggested, we would need to read out the HW state
> - Could you elaborate on "1) reading out the hw state to sw
> state? - Does that mean do the HW state readout and compute
> pipe_config/crtc_state for that?
>
> - Then add some sanitization to have this computed pipe_config that will be
> programmed to the HW
> - Then ensure that both are same so that the intel fastset logic can apply
> fastset?

Let's start with the regular modesets, ignoring the probe for a bit.

For every modeset, we have the old (current) state and the new
state. These are both software states. We compare the states to
determine whether a full modeset is required or not. This is mostly
dependent on what the hardware can change on the fly. If we can bypass a
full modeset, we call it a fastset.

We write either the full new state (modeset) or just the changes
(fastset) to the hardware, and the new state becomes the old (current)
state.

After that, we read back the hardware state to verify we did everything
right. This is the state checker. The comparison is done using the same
functions as for determining whether a full modeset is required.

Rinse and repeat.

At probe, we obviously don't have the old (current) software state. We
create it by reading out the hardware state, using the same mechanisms
as in the state checker. We call it the inherited state. We do the
initial commit with that.

Then we arrive at the first userspace/client initiated modeset. It goes
through the same paths as the regular modeset. If we can get away with a
fastset, we call it fastboot i.e. no full modeset at boot.

That's the basic idea, anyway. Now the caveats.

Sometimes GOP (or whatever pre-os) ends up using slightly different
parameters for the same mode than the driver. Or we might not be able to
read out everything. Or we lose accuracy in the sw->hw->sw changes. Or
the pre-os enables stuff that it doesn't even use or care about. We
wiggle around those issues using sanitization or ignoring small
differences or simply bypassing some parts on the first modeset.

Obviously, if there are gaps in the state readout in the first place,
the inherited state will be incomplete, and likely leads to a full
modeset. (And we also miss out on the state verification of those
parts.)

If the GOP (or pre-os) sets a mode, and the first modeset requests a
completely different mode, you can't have fastboot either.

The thing we absolutely can't do is what patch 2 here does. We can't
simply copy over stuff from one state to another, and hope it works. It
might appear to work by coincidence in some cases, but it is all
wrong. It ignores the computed modeset parameters for the new state,
even if userspace tries a completely different mode. It bypasses the
comparison for whether a full modeset is needed or not. It's not
discretional, it depends on what the hardware can change on the fly, and
it's undocumented at best what happens when you try to change such
things without a modeset.

You can do a lot of debugging based on just looking at the debug output
for the state comparison where we decide a fastset (and in this case
fastboot) is not possible. Where does the differing info come from? Is
there a readout in place? Is something completely zero in the readout,
or are there minor differences? Do you get fastsets on the second and
subsequent regular modesets? Etc. Etc.


HTH,
Jani.


-- 
Jani Nikula, Intel

Re: [RFC PATCH v3 2/2] drm/i915/display: Synchronize crtc_state for initial commit

[Juasheem Sultan]

[-- Attachment #1: Type: text/plain, Size: 5748 bytes --]

Hi @Jani Nikula <jani.nikula@linux.intel.com>

Thank you for the clarifications. I've investigated the issue and
determined the source of the discrepancy between the driver and firmware
set display state. Firstly, it appears userspace issued a commit that
completely cleared the screen. This explains why we saw all 0s without my
changes. I have fixed that on our side, so I shouldn't have to worry about
that when debugging.

You can do a lot of debugging based on just looking at the debug output
> for the state comparison where we decide a fastset (and in this case
> fastboot) is not possible. Where does the differing info come from? Is
> there a readout in place? Is something completely zero in the readout,
> or are there minor differences? Do you get fastsets on the second and
> subsequent regular modesets? Etc. Etc.


We can commit the state that's originally read from the hardware. When
userspace attempts its first commit, the PLL state and clock that the
driver calculates differ slightly from what the BIOS has set. This is
causing us to modeset. I slightly modified how the pll state was calculated
and added a small tolerance to the clock comparison; this fixes the issue,
making the state seamless, but I'm not sure exactly how this should be
solved. In order to avoid publishing any potentially secure information, I
have created an internal bug where we can discuss exactly how to resolve
this.

On Tue, Mar 3, 2026 at 1:44 AM Jani Nikula <jani.nikula@intel.com> wrote:

> On Mon, 02 Mar 2026, Manasi Navare <navaremanasi@google.com> wrote:
> > Hi @Jani Nikula <jani.nikula@intel.com> :
> >
> > Before we file a fdo issue with complete debug logs to understand what
> the
> > FW is setting up the HW at, I wanted to understand a few more things in
> > terms of the final solution:
> >
> > -  Ideally if the FW is setting up the initial state or programming the
> HW
> > registers for the initial splashscreen, for the initial commit when we do
> > the HW state readout, it should have the HW values programmed to some
> mode
> > parameters
> > -  Then like you suggested, we would need to read out the HW state
> > - Could you elaborate on "1) reading out the hw state to sw
> > state? - Does that mean do the HW state readout and compute
> > pipe_config/crtc_state for that?
> >
> > - Then add some sanitization to have this computed pipe_config that will
> be
> > programmed to the HW
> > - Then ensure that both are same so that the intel fastset logic can
> apply
> > fastset?
>
> Let's start with the regular modesets, ignoring the probe for a bit.
>
> For every modeset, we have the old (current) state and the new
> state. These are both software states. We compare the states to
> determine whether a full modeset is required or not. This is mostly
> dependent on what the hardware can change on the fly. If we can bypass a
> full modeset, we call it a fastset.
>
> We write either the full new state (modeset) or just the changes
> (fastset) to the hardware, and the new state becomes the old (current)
> state.
>
> After that, we read back the hardware state to verify we did everything
> right. This is the state checker. The comparison is done using the same
> functions as for determining whether a full modeset is required.
>
> Rinse and repeat.
>
> At probe, we obviously don't have the old (current) software state. We
> create it by reading out the hardware state, using the same mechanisms
> as in the state checker. We call it the inherited state. We do the
> initial commit with that.
>
> Then we arrive at the first userspace/client initiated modeset. It goes
> through the same paths as the regular modeset. If we can get away with a
> fastset, we call it fastboot i.e. no full modeset at boot.
>
> That's the basic idea, anyway. Now the caveats.
>
> Sometimes GOP (or whatever pre-os) ends up using slightly different
> parameters for the same mode than the driver. Or we might not be able to
> read out everything. Or we lose accuracy in the sw->hw->sw changes. Or
> the pre-os enables stuff that it doesn't even use or care about. We
> wiggle around those issues using sanitization or ignoring small
> differences or simply bypassing some parts on the first modeset.
>
> Obviously, if there are gaps in the state readout in the first place,
> the inherited state will be incomplete, and likely leads to a full
> modeset. (And we also miss out on the state verification of those
> parts.)
>
> If the GOP (or pre-os) sets a mode, and the first modeset requests a
> completely different mode, you can't have fastboot either.
>
> The thing we absolutely can't do is what patch 2 here does. We can't
> simply copy over stuff from one state to another, and hope it works. It
> might appear to work by coincidence in some cases, but it is all
> wrong. It ignores the computed modeset parameters for the new state,
> even if userspace tries a completely different mode. It bypasses the
> comparison for whether a full modeset is needed or not. It's not
> discretional, it depends on what the hardware can change on the fly, and
> it's undocumented at best what happens when you try to change such
> things without a modeset.
>
> You can do a lot of debugging based on just looking at the debug output
> for the state comparison where we decide a fastset (and in this case
> fastboot) is not possible. Where does the differing info come from? Is
> there a readout in place? Is something completely zero in the readout,
> or are there minor differences? Do you get fastsets on the second and
> subsequent regular modesets? Etc. Etc.
>
>
> HTH,
> Jani.
>
>
> --
> Jani Nikula, Intel
>

[-- Attachment #2: Type: text/html, Size: 6756 bytes --]

✗ Fi.CI.BUILD: failure for Enable seamless boot (fastboot) for PTL

[Patchwork]

== Series Details ==

Series: Enable seamless boot (fastboot) for PTL
URL   : https://patchwork.freedesktop.org/series/160446/
State : failure

== Summary ==

Error: patch https://patchwork.freedesktop.org/api/1.0/series/160446/revisions/1/mbox/ not applied
Applying: drm/xe/display: Fix reading the framebuffer from stolen memory
Using index info to reconstruct a base tree...
A	drivers/gpu/drm/xe/display/xe_plane_initial.c
Falling back to patching base and 3-way merge...
CONFLICT (modify/delete): drivers/gpu/drm/xe/display/xe_plane_initial.c deleted in HEAD and modified in drm/xe/display: Fix reading the framebuffer from stolen memory. Version drm/xe/display: Fix reading the framebuffer from stolen memory of drivers/gpu/drm/xe/display/xe_plane_initial.c left in tree.
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm/xe/display: Fix reading the framebuffer from stolen memory
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Build failed, no error log produced