On Fri, Apr 30, 2021 at 09:44:42AM -0700, Rob Clark wrote: > On Thu, Apr 8, 2021 at 6:20 AM Maxime Ripard <maxime@xxxxxxxxxx> 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. Yeah you're not allowed to touch an object's hw state in ->atomic_commit without acquiring it's state in atomic_check. Otherwise the synchronization across commits that atomic helpers provides goes boom. > 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.. You're probably missing a drm_atomic_add_affected_planes() somewhere. Without looking at the code at least, it might be that if you just blindly do that you take too many states by default and oversynchronize across multiple crtc, which isn't great. But better than getting the rules wrong :-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
