On Thu, Apr 8, 2021 at 6:20 AM Maxime Ripard maxime@cerno.tech wrote:
Hi Stephen,
On Tue, Mar 30, 2021 at 11:56:15AM -0700, Stephen Boyd wrote:
Quoting Maxime Ripard (2021-03-30 08:35:27)
Hi Stephen,
On Mon, Mar 29, 2021 at 06:52:01PM -0700, Stephen Boyd wrote:
Trimming Cc list way down, sorry if that's too much.
Quoting Maxime Ripard (2021-02-19 04:00:30)
Many drivers reference the plane->state pointer in order to get the current plane state in their atomic_update or atomic_disable hooks, which would be the new plane state in the global atomic state since _swap_state happened when those hooks are run.
Does this mean drm_atomic_helper_swap_state()?
Yep. Previous to that call in drm_atomic_helper_commit, plane->state is the state currently programmed in the hardware, so the old state (that's the case you have with atomic_check for example)
Once drm_atomic_helper_swap_state has run, plane->state is now the state that needs to be programmed into the hardware, so the new state.
Ok, and I suppose that is called by drm_atomic_helper_commit()?
Yep :)
So presumably a modeset is causing this? I get the NULL pointer around the time we switch from the splash screen to the login screen. I think there's a modeset during that transition.
It's very likely yeah. I really don't get how that pointer could be null though :/
So I think I see what is going on.. the issue is the CRTC has changed, but not the plane, so there is no new-state for the plane.
But dpu_crtc_atomic_flush() iterates over all the attached planes, calling dpu_plane_restore() which leads into dpu_plane_atomic_update().. this is kinda dpu breaking the rules..
BR, -R