On Thu, Oct 29, 2020 at 03:55:37PM +0200, Ville Syrjälä wrote:
> On Wed, Oct 28, 2020 at 01:32:22PM +0100, Maxime Ripard wrote:
> > The current atomic helpers have either their object state being passed as
> > an argument or the full atomic state.
> >
> > The former is the pattern that was done at first, before switching to the
> > latter for new hooks or when it was needed.
> >
> > Let's start convert all the remaining helpers to provide a consistent
> > interface, starting with the CRTC's atomic_begin and atomic_flush.
> >
> > The conversion was done using the coccinelle script below, built tested on
> > all the drivers and actually tested on vc4.
> >
> <snip>
> > @@ -323,26 +323,27 @@ static void ingenic_drm_crtc_atomic_begin(struct
> > drm_crtc *crtc,
> > }
> >
> > static void ingenic_drm_crtc_atomic_flush(struct drm_crtc *crtc,
> > - struct drm_crtc_state *oldstate)
> > + struct drm_atomic_state *state)
> > {
> > struct ingenic_drm *priv = drm_crtc_get_priv(crtc);
> > - struct drm_crtc_state *state = crtc->state;
> > - struct drm_pending_vblank_event *event = state->event;
> > + struct drm_crtc_state *crtc_state = crtc->state;
>
> Looks like quite a few places could use a followup to
> switch to get_{old,new}_crtc_state().That one is not entirely clear to me. crtc->state is documented as the current CRTC state, but in atomic_begin / atomic_flush, does that mean that it's the old state that we're going to replace, or the new state that is going to replace the current state? > Patch lgtm > Reviewed-by: Ville Syrjälä <[email protected]> Thanks! Maxime
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
