Plane transitional helper prototypes mismatch their methods

Daniel Vetter daniel at ffwll.ch
Mon Jul 2 08:47:03 UTC 2018


On Sun, Jul 01, 2018 at 04:34:02PM +0100, Russell King - ARM Linux wrote:
> Ping.
> 
> On Mon, Jun 25, 2018 at 04:52:16PM +0100, Russell King - ARM Linux wrote:
> > Hi,
> > 
> > Currently, the transitional plane helpers have prototypes that
> > do not have the drm_modeset_acquire_ctx argument:
> > 
> > int drm_plane_helper_update(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);
> > int drm_plane_helper_disable(struct drm_plane *plane);
> > 
> > However, the helper methods have this as the last argument:
> > 
> >         int (*update_plane)(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);
> >         int (*disable_plane)(struct drm_plane *plane,
> >                              struct drm_modeset_acquire_ctx *ctx);
> > 
> > Are these transitional helpers supposed to be plugged into these
> > methods directly?  Looking back in the history, the following commit
> > to i915 seems to suggest that they were designed to be plugged
> > directly into these methods:
> > 
> > commit ea2c67bb4affa84080c616920f3899f123786e56
> > Author: Matt Roper <matthew.d.roper at intel.com>
> > Date:   Tue Dec 23 10:41:52 2014 -0800
> > 
> >     drm/i915: Move to atomic plane helpers (v9)
> > 
> > It seems easy to add this argument to drm_plane_helper_update() as
> > it has no current users, but the drm_plane_helper_disable()
> > transitional helper seems to be used extensively by what are
> > otherwise fully atomic modeset drivers, despite being described as
> > only a transitional helper.

Yes, I forgotten to add the acquire_ctx to them to make them match up
again. Upfront Acked-by: Daniel Vetter <daniel.vetter at ffwll.ch> on the
patch to re-add that.

> > drivers/gpu/drm/arm/hdlcd_crtc.c:   drm_plane_helper_disable(plane);
> > drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c: drm_plane_helper_disable(plane);
> > drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c: drm_plane_helper_disable(plane);
> > drivers/gpu/drm/arc/arcpgu_crtc.c:  drm_plane_helper_disable(plane);
> > drivers/gpu/drm/sti/sti_hqvdp.c:    drm_plane_helper_disable(drm_plane);
> > drivers/gpu/drm/sti/sti_gdp.c:      drm_plane_helper_disable(drm_plane);
> > drivers/gpu/drm/sti/sti_cursor.c:   drm_plane_helper_disable(drm_plane);
> > drivers/gpu/drm/vc4/vc4_plane.c:    drm_plane_helper_disable(plane);
> > drivers/gpu/drm/zte/zx_plane.c:     drm_plane_helper_disable(plane);
> > 
> > Are these drivers buggy using the transitional helper, which won't do
> > anything but change the state of that single plane, leaving the CRTC,
> > encoders, bridges, etc all active?

Yes that's all buggy usage. I've started sprinkling
WARN_ON(drm_drv_uses_adomit_modeset) on such legacy functions, but
drm_plane_helper_disable() is used a bit too much really.

It's all the same cargo-cult though in the plane->destroy hook. What
drivers should do instead is:
- Shut down the hw before cleaning up their modeset objects using
  something like drm_atomic_helper_shutdown().
- Remove the drm_plane_helper_disable().

But for your patch to add the ctx argument everywhere I think just passing
NULL is ok too. It's not going to make things worse :-) Since that patch
needs to touch a bunch of drivers probably best if we get it landed
through drm-misc-next.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the dri-devel mailing list