[RFC v3 5/8] drm/msm: update cursors asynchronously through atomic

[Daniel Vetter]

On Wed, May 17, 2017 at 10:56:25AM +0530, Archit Taneja wrote:
> Hi,
> 
> On 05/16/2017 08:14 PM, Archit Taneja wrote:
> > 
> > 
> > On 5/13/2017 12:40 AM, Gustavo Padovan wrote:
> > > From: Gustavo Padovan <gustavo.padovan at collabora.com>
> > > 
> > > Add support to async updates of cursors by using the new atomic
> > > interface for that. Basically what this commit does is do what
> > > mdp5_update_cursor_plane_legacy() did but through atomic.
> > 
> > Works well on DB820c (which has a APQ8096 SoC).
> > 
> > Tested-by: Archit Taneja <architt at codeaurora.org>
> 
> Actually, after some more thorough testing, I found one issue, mentioned below.
> 
> > 
> > > 
> > > v3: move size checks back to drivers (Ville Syrjälä)
> > > 
> > > v2: move fb setting to core and use new state (Eric Anholt)
> > > 
> > > Cc: Rob Clark <robdclark at gmail.com>
> > > Signed-off-by: Gustavo Padovan <gustavo.padovan at collabora.com>
> > > ---
> > >   drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 151 +++++++++++++-----------------
> > >   1 file changed, 63 insertions(+), 88 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> > > index a38c5fe..07106c1 100644
> > > --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> > > +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> > > @@ -33,15 +33,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
> > >           struct drm_crtc *crtc, struct drm_framebuffer *fb,
> > >           struct drm_rect *src, struct drm_rect *dest);
> > >   -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_modeset_acquire_ctx *ctx);
> > > -
> > >   static struct mdp5_kms *get_kms(struct drm_plane *plane)
> > >   {
> > >       struct msm_drm_private *priv = plane->dev->dev_private;
> > > @@ -257,7 +248,7 @@ static const struct drm_plane_funcs mdp5_plane_funcs = {
> > >   };
> > >     static const struct drm_plane_funcs mdp5_cursor_plane_funcs = {
> > > -        .update_plane = mdp5_update_cursor_plane_legacy,
> > > +        .update_plane = drm_atomic_helper_update_plane,
> > >           .disable_plane = drm_atomic_helper_disable_plane,
> > >           .destroy = mdp5_plane_destroy,
> > >           .set_property = drm_atomic_helper_plane_set_property,
> > > @@ -484,11 +475,73 @@ static void mdp5_plane_atomic_update(struct drm_plane *plane,
> > >       }
> > >   }
> > >   +static int mdp5_plane_atomic_async_check(struct drm_plane *plane,
> > > +                     struct drm_plane_state *state)
> > > +{
> > > +    struct mdp5_plane_state *mdp5_state = to_mdp5_plane_state(state);
> > > +    struct drm_crtc_state *crtc_state;
> > > +
> > > +    crtc_state = drm_atomic_get_existing_crtc_state(state->state,
> > > +                            state->crtc);
> 
> I see a kernel splat here (a NULL pointer dereference). The async_check
> function assumes that there is always going to be a plane_state->crtc
> available. This doesn't seem to be the case at least in the
> drm_atomic_helper_disable_plane() path. Moving the check to set
> legacy_cursor_update after calling __drm_atomic_helper_disable_plane()
> seems to fix the issue. Do you think it's a legit fix?

Yes, plane_state->crtc == NULL is what happens when disabling a plane. I
guess simplest would be to just not handle this for the async cursor
helpers.

I thought we've had tons of igts to test this ...

> One more point w.r.t msm driver is that we don't use the default
> drm_atomic_helper_commit() for our atomic_commit op. So I had to
> call drm_atomic_helper_async_commit() from our atomic_commit
> implementation
> (i.e, in msm_atomic_commit in drivers/gpu/drm/msm/msm_atomic.c)

Would be great to fix that - msm predates the nonblocking support in the
commit helper, but since this is fixed there's no reason anymore for
driver-private commit functions. Or at least there shouldn't be, for
almost all drivers. You can stuff all your hw commit logic into
atomic_commit_tail.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch