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ä <ville.syrjala@xxxxxxxxxxxxxxx>
Thanks!
Maxime
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
