From: Jani Nikula <jani.nikula@linux.intel.com>
To: Juasheem Sultan <jdsultan@google.com>,
intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>,
Sean Paul <seanpaul@google.com>,
Manasi Navare <navaremanasi@google.com>,
Drew Davenport <ddavenport@google.com>,
Juasheem Sultan <jdsultan@google.com>
Subject: Re: [RFC PATCH 00/10] Enable seamless boot (fastboot) for PTL
Date: Fri, 16 Jan 2026 13:39:52 +0200 [thread overview]
Message-ID: <2015894f4f7351c6a2ac77f32348877ed110d95c@intel.com> (raw)
In-Reply-To: <20260115-upstream-prep-v1-0-001d5b38fc11@google.com>
On Thu, 15 Jan 2026, Juasheem Sultan <jdsultan@google.com> wrote:
> This RFC patch series proposes an implementation of seamless boot (fastboot)
> support for Panther Lake (PTL) platforms within the Xe driver, mirroring
> functionality already present in i915. The primary focus is on devices using
> MSO (Multi-Segment Operation) panels and EDP panels.
>
> 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.
The goal is something we obviously share.
> Key areas addressed in this revision:
> 1. **Boot State Preservation**: Where necessary, make amendments to initial
> hardware readouts and ensure that the framebuffer state as established
> by firmware is correctly passed into the driver as a memory object.
> 2. **Atomic State Handoff**: Adjusting the atomic commit path to prevent
> unnecessary pipe disables or power well toggles when inheriting a valid
> boot state.
> 3. **Passive Probing**: Introducing a "passive" initialization path that
> builds the DRM software state without triggering hardware resets.
>
> This is an initial implementation subject to discussion.
- There's just way, *way* too much code duplication. I can't even make
myself read through the entire thing because it's all familiar
existing stuff, just subtly different. I can't stress this
enough. There's so much duplication that I won't take on telling you
what needs to be done. It's on you to figure out how to deduplicate.
- There's way too much magic values and hacking for a specific
configuration.
- There's way too much code being added in xe_display.c when the goal is
to unify and deduplicate everything under i915/display. All of this
needs to happen in the i915/display directory, shared between i915 and
xe drivers.
- There's way too many random unrelated unexplained things going on
here. Things like unused struct members being added, commented out
code being added, stuff being first added and then removed later in
the series.
- There are way too many things being done in individual patches. The
"key changes include" lists in commit messages are a pretty big
clue. Each patch should do one thing, and one thing only. At times it
feels like the changes in single patches aren't even related to each
other.
All in all, I get the distinct feeling a lot of this is LLM generated,
which is something you'd do well to disclose if it's indeed the
case. Please see [1] for current discussion on the matter.
Again, the goal is something we share, but I honestly fear taking this
series as the starting point for that will be counter-productive.
I would love to see small, focused patch series tackling existing issues
one by one, instead of a giant hack attempting to fix everything at
once.
BR,
Jani.
[1] https://lore.kernel.org/r/20260113000612.1133427-1-dave.hansen@linux.intel.com
>
> Change-Id: I5cd3bdd4f6f687f007e91f6d0afbfeecfc06762b
> Signed-off-by: Juasheem Sultan <jdsultan@google.com>
> ---
> Juasheem Sultan (10):
> drm/i915/display: Implement passive initialization for splash screen preservation
> drm/xe/display: Implement seamless boot state reconstruction for PTL
> drm/i915/display: Implement aggressive boot state preservation for PTL
> drm/xe/display: Fix initial plane reconstruction and stolen memory handling
> drm/i915/display: Enable early PLL readout and robustify modeset setup
> drm/i915/display: Fix vblank timestamps and update logic for fastboot
> drm/i915/display: Implement seamless fastboot for MSO panels on PTL
> drm/i915/display: Robustify fastboot and power init for seamless boot
> drm/i915/display: Fix initial plane config readout and MSO stride for PTL
> drm/i915/display: Refactor initial plane readout and harden boot handover
>
> drivers/gpu/drm/i915/display/intel_bios.c | 40 +-
> drivers/gpu/drm/i915/display/intel_cdclk.c | 36 -
> drivers/gpu/drm/i915/display/intel_cdclk.h | 41 +-
> drivers/gpu/drm/i915/display/intel_connector.c | 9 +
> drivers/gpu/drm/i915/display/intel_connector.h | 1 +
> drivers/gpu/drm/i915/display/intel_crtc.c | 62 +-
> drivers/gpu/drm/i915/display/intel_ddi.c | 205 +++++-
> drivers/gpu/drm/i915/display/intel_ddi.h | 2 +
> drivers/gpu/drm/i915/display/intel_display.c | 814 +++++++++++++++++++--
> drivers/gpu/drm/i915/display/intel_display.h | 6 +
> drivers/gpu/drm/i915/display/intel_display_core.h | 2 +
> .../gpu/drm/i915/display/intel_display_driver.c | 329 ++++++++-
> drivers/gpu/drm/i915/display/intel_display_power.c | 16 +-
> drivers/gpu/drm/i915/display/intel_display_types.h | 8 +
> drivers/gpu/drm/i915/display/intel_dp.c | 372 ++++++++--
> drivers/gpu/drm/i915/display/intel_dp.h | 5 +
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 16 +-
> drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 1 +
> drivers/gpu/drm/i915/display/intel_hdmi.c | 39 +
> drivers/gpu/drm/i915/display/intel_hdmi.h | 2 +
> drivers/gpu/drm/i915/display/intel_modeset_setup.c | 7 +
> .../gpu/drm/i915/display/intel_modeset_verify.c | 14 +-
> drivers/gpu/drm/i915/display/intel_panel.c | 41 +-
> drivers/gpu/drm/i915/display/intel_panel.h | 3 +
> drivers/gpu/drm/i915/display/intel_plane_initial.c | 53 ++
> drivers/gpu/drm/i915/display/skl_universal_plane.c | 32 +-
> drivers/gpu/drm/xe/display/xe_display.c | 309 +++++++-
> drivers/gpu/drm/xe/display/xe_display.h | 2 +
> drivers/gpu/drm/xe/display/xe_plane_initial.c | 28 +-
> drivers/gpu/drm/xe/xe_device.c | 2 +-
> drivers/gpu/drm/xe/xe_ggtt.h | 3 +
> drivers/gpu/drm/xe/xe_ttm_stolen_mgr.c | 2 +
> 32 files changed, 2302 insertions(+), 200 deletions(-)
> ---
> base-commit: 812e4b8966d421afd4df8f794bf15f1a1a3ec7b6
> change-id: 20260115-upstream-prep-b29156970a75
>
> Best regards,
--
Jani Nikula, Intel
prev parent reply other threads:[~2026-01-16 11:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-15 16:54 [RFC PATCH 00/10] Enable seamless boot (fastboot) for PTL Juasheem Sultan
2026-01-15 16:54 ` [PATCH RFC 01/10] drm/i915/display: Implement passive initialization for splash screen preservation Juasheem Sultan
2026-01-15 16:54 ` [PATCH RFC 02/10] drm/xe/display: Implement seamless boot state reconstruction for PTL Juasheem Sultan
2026-01-15 16:54 ` [PATCH RFC 03/10] drm/i915/display: Implement aggressive boot state preservation " Juasheem Sultan
2026-01-15 16:54 ` [PATCH RFC 04/10] drm/xe/display: Fix initial plane reconstruction and stolen memory handling Juasheem Sultan
2026-01-15 16:54 ` [PATCH RFC 05/10] drm/i915/display: Enable early PLL readout and robustify modeset setup Juasheem Sultan
2026-01-15 16:54 ` [PATCH RFC 06/10] drm/i915/display: Fix vblank timestamps and update logic for fastboot Juasheem Sultan
2026-01-15 16:54 ` [PATCH RFC 07/10] drm/i915/display: Implement seamless fastboot for MSO panels on PTL Juasheem Sultan
2026-01-15 16:54 ` [PATCH RFC 08/10] drm/i915/display: Robustify fastboot and power init for seamless boot Juasheem Sultan
2026-01-15 16:54 ` [PATCH RFC 09/10] drm/i915/display: Fix initial plane config readout and MSO stride for PTL Juasheem Sultan
2026-01-15 16:54 ` [PATCH RFC 10/10] drm/i915/display: Refactor initial plane readout and harden boot handover Juasheem Sultan
2026-01-16 11:39 ` Jani Nikula [this message]
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=2015894f4f7351c6a2ac77f32348877ed110d95c@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=ddavenport@google.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jdsultan@google.com \
--cc=navaremanasi@google.com \
--cc=rodrigo.vivi@intel.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