On Sat, Oct 31, 2020 at 10:59:05AM +0100, Maxime Ripard wrote:
> 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?
That depends on whether it's being used before or after the
swap_state(). Before swap_state() foo->state is the old state,
after swap_state() foo->state is the new state.
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
