On Thu, 2017-03-30 at 12:36 +0200, Maarten Lankhorst wrote: > Op 30-03-17 om 10:42 schreef Dhinakaran Pandiyan: > > From: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan@xxxxxxxxx> > > > > Having an ->atomic_release callback is useful to release shared resources > > that get allocated in compute_config(). This function is expected to be > > called in the atomic_check() phase before new resources are acquired. > > > > v4: Document that the function is conditionally called and before > > other atomic_checks() (Daniel) > > v3: Use the new 'for_each_oldnew_connector_in_state()' macro. > > v2: Moved the caller hunk to this patch (Daniel) > > > > Cc: Daniel Vetter <daniel.vetter@xxxxxxxx> > > Cc: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx> > > Cc: Archit Taneja <architt@xxxxxxxxxxxxxx> > > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Harry Wentland <Harry.wentland@xxxxxxx> > > Reviewed-by: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx> > > Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > Suggested-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@xxxxxxxxx> > > --- > > drivers/gpu/drm/drm_atomic_helper.c | 19 +++++++++++++++++++ > > include/drm/drm_modeset_helper_vtables.h | 16 ++++++++++++++++ > > 2 files changed, 35 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c > > index d14094d..9d07669 100644 > > --- a/drivers/gpu/drm/drm_atomic_helper.c > > +++ b/drivers/gpu/drm/drm_atomic_helper.c > > @@ -586,6 +586,25 @@ drm_atomic_helper_check_modeset(struct drm_device *dev, > > } > > } > > > > + for_each_oldnew_connector_in_state(state, connector, old_connector_state, new_connector_state, i) { > > + const struct drm_connector_helper_funcs *conn_funcs; > > + struct drm_crtc_state *crtc_state; > > + > > + conn_funcs = connector->helper_private; > > + if (!conn_funcs->atomic_release) > > + continue; > > + > > + if (!old_connector_state->crtc) > > + continue; > > + > > + crtc_state = drm_atomic_get_existing_crtc_state(state, old_connector_state->crtc); > > + > > + if (crtc_state->connectors_changed || > > + crtc_state->mode_changed || > > + (crtc_state->active_changed && !crtc_state->active)) > > + conn_funcs->atomic_release(connector, new_connector_state); > > + } > > + > > return mode_fixup(state); > > } > Oops, I'm just looking at patch 5 again.. > > atomic_release should return an int to allow error propogation. There's no good reason why it shouldn't. > This would allow handling errors in patch 5 more gracefully. Makes sense, will change that. This made me think about how intel_dp_mst_atomic_release() handles an invalid mst_port reference i.e., in case the port is gone. I'll fix both and send a new version. -DK > > EXPORT_SYMBOL(drm_atomic_helper_check_modeset); > > diff --git a/include/drm/drm_modeset_helper_vtables.h b/include/drm/drm_modeset_helper_vtables.h > > index 091c422..84e80aa 100644 > > --- a/include/drm/drm_modeset_helper_vtables.h > > +++ b/include/drm/drm_modeset_helper_vtables.h > > @@ -836,6 +836,22 @@ struct drm_connector_helper_funcs { > > */ > > struct drm_encoder *(*atomic_best_encoder)(struct drm_connector *connector, > > struct drm_connector_state *connector_state); > > + > > + /** > > + * @atomic_release: > > + * > > + * This function is conditionally called to release shared resources > > + * when the attached CRTC's mode changes or it's connectors change or > > + * becomes inactive. It is called before the corresponding > > + * &drm_crtc_helper_funcs.atomic_check or > > + * &drm_crtc_helper_funcs.mode_fixup hooks are called. > > + * > > + * NOTE: > > + * > > + * This function is called in the check phase of an atomic update. > > + */ > > + void (*atomic_release)(struct drm_connector *connector, > > + struct drm_connector_state *connector_state); > > }; > > > > /** > > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel