Hi, On Wed, Oct 15, 2025 at 01:49:33AM +0300, Dmitry Baryshkov wrote: > On Tue, Oct 14, 2025 at 11:31:47AM +0200, Maxime Ripard wrote: > > The drm_private_obj initialization was inconsistent with the rest of the > > KMS objects. Indeed, it required to pass a preallocated state in > > drm_private_obj_init(), while all the others objects would have a reset > > callback that would be called later on to create the state. > > > > However, reset really is meant to reset the hardware and software state. > > That it creates an initial state is a side-effect that has been used in > > all objects but drm_private_obj. This is made more complex since some > > drm_private_obj, the DisplayPort ones in particular, need to be > > persistent across and suspend/resume cycle, and such a cycle would call > > drm_mode_config_reset(). > > Doesn't that mean that we need to save private objects's state in > drm_atomic_helper_duplicate_state() and restore it in > drm_atomic_helper_commit_duplicated_state()? Private objects don't have > .atomic_commit() callbacks, but they can be used by other objects during > drm_atomic_commit().
Not really, because private objs aren't reset in drm_mode_config_reset(), so there's nothing to save and restore, the objects before the suspend are still going to be there after the resume. Maxime
signature.asc
Description: PGP signature
