[RFC 8/9] HACK: drm/msm/mdp5: Add support for legacy cursor updates

[Daniel Vetter]

On Mon, Dec 19, 2016 at 05:00:49PM +0100, Daniel Vetter wrote:
> On Mon, Dec 19, 2016 at 05:38:57PM +0530, Archit Taneja wrote:
> > @@ -873,6 +894,81 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
> >  	return ret;
> >  }
> >  
> > +static int mdp5_update_cursor_plane_legacy(struct drm_plane *plane,
> > +			struct drm_crtc *crtc, struct drm_framebuffer *fb,
> > +			int crtc_x, int crtc_y,
> > +			unsigned int crtc_w, unsigned int crtc_h,
> > +			uint32_t src_x, uint32_t src_y,
> > +			uint32_t src_w, uint32_t src_h)
> > +{
> > +	struct drm_plane_state *plane_state, *new_plane_state;
> > +	struct mdp5_plane_state *mdp5_pstate;
> > +	struct drm_crtc_state *crtc_state = crtc->state;
> > +	int ret;
> > +
> > +	if (!crtc_state->active || drm_atomic_crtc_needs_modeset(crtc_state))
> 
> Until you do some kind of normal flip on the primary after a modeset no
> one will ever change the needs_modeset(crtc_state) if you only ever do
> async flips. Sounds like a bug, and vc4 doesn't check for it. Why do you
> need this?

Self-correct: The slow-path will duplicate the crtc state also and clear
needs_modeset, which means only the very first cursor move after a modeset
will be slow. I think that's ok.

But this kind of trickery is a good reason to try to extract this logic a
bit better I think.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch