[PATCH 2/2] drm/atomic: Pass the full state to CRTC atomic begin and flush

Maxime Ripard maxime at cerno.tech
Sat Oct 31 09:59:05 UTC 2020


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 at linux.intel.com>

Thanks!
Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20201031/62b5067d/attachment.sig>


More information about the dri-devel mailing list