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 :/ Maxime
Attachment:
signature.asc
Description: PGP signature
