[PATCH v3 10/11] drm: Use state helper instead of the plane state pointer

[Rob Clark]

On Thu, Apr 8, 2021 at 6:20 AM Maxime Ripard <maxime at 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