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

[Jani Nikula <jani.nikula@intel.com>]

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