[Intel-gfx] "drm/i915: Use the correct crtc when sanitizing plane mapping" seems to cause the readback plane state to always be 0

[Hans de Goede]

Hi Ville,

While debugging the briefly purple screen on DSI panels issue for
which I just send a revert, I also noticed something odd with
your commit 9b27390139db ("drm/i915: Use the correct crtc when
sanitizing plane mapping").

When comparing drm.debug=0x1e logs between 4.19 and 4.20-rc1
I noticed that this bit of the initial hw state readback logging
in 4.19:

[drm:intel_modeset_setup_hw_state [i915]] pipe B active planes 0x1
[drm:intel_modeset_setup_hw_state [i915]] pipe B active planes 0x1
[drm:intel_modeset_setup_hw_state [i915]] pipe B active planes 0x1
[drm:intel_modeset_setup_hw_state [i915]] pipe B active planes 0x1

Changed to:

[drm:intel_modeset_setup_hw_state [i915]] pipe B active planes 0x0
[drm:intel_modeset_setup_hw_state [i915]] pipe B active planes 0x0
[drm:intel_modeset_setup_hw_state [i915]] pipe B active planes 0x0
[drm:intel_modeset_setup_hw_state [i915]] pipe B active planes 0x0

In 4.20-rc1 (the other pipes are off and report 0 active planes
in both cases).

At first I thought that this was the cause of the purple flicker,
but it wasn't and I'm not seeing any negative side-effects of this
(AFAICT).

Still this seems like a bug to me where the state read-back now no
longer detects the active primary plane on pipe B. This is on a
Cherry Trail device with a DSI panel.

I can confirm that reverting commit 9b27390139db ("drm/i915: Use
the correct crtc when sanitizing plane mapping") makes the
log messages the same as they were in 4.19 again.

Regards,

Hans