On Mon, 02 Mar 2026, Manasi Navare <[email protected]> wrote: > Hi @Jani Nikula <[email protected]> : > > 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
