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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
