On Mon, Jun 04, 2018 at 11:13:53AM -0700, Sinclair Yeh wrote: > On Wed, May 30, 2018 at 11:08:57PM +0300, Ville Syrjälä wrote: > > On Fri, May 25, 2018 at 09:50:34PM +0300, Ville Syrjala wrote: > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > Instead of plane->fb (which we're going to deprecate for atomic drivers) > > > we need to look at plane->state->fb. The maze of code leading to > > > vmw_kms_helper_dirty() wasn't particularly clear, but my analysis > > > concluded that the calls originating from vmw_*_primary_plane_atomic_update() > > > all pass in the crtc which means we'll never end up in this branch > > > of the function. All other callers use drm_modeset_lock_all() somewhere > > > higher up, which means accessing plane->state is safe. We'll toss in > > > a lockdep assert to catch wrongdoers. > > > > > > v2: Drop the comment and make the code do what it did before (Thomas) > > > > > > Cc: Deepak Rawat <drawat@xxxxxxxxxx> > > > Cc: Thomas Hellstrom <thellstrom@xxxxxxxxxx> > > > Cc: Sinclair Yeh <syeh@xxxxxxxxxx> > > > Cc: VMware Graphics <linux-graphics-maintainer@xxxxxxxxxx> > > > Cc: Daniel Vetter <daniel.vetter@xxxxxxxx> > > > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > --- > > > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 9 ++++++--- > > > 1 file changed, 6 insertions(+), 3 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c > > > index 2e4c38bb846d..5417eb1b486e 100644 > > > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c > > > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c > > > @@ -2326,9 +2326,12 @@ int vmw_kms_helper_dirty(struct vmw_private *dev_priv, > > > } else { > > > list_for_each_entry(crtc, &dev_priv->dev->mode_config.crtc_list, > > > head) { > > > - if (crtc->primary->fb != &framebuffer->base) > > > - continue; > > > - units[num_units++] = vmw_crtc_to_du(crtc); > > > + struct drm_plane *plane = crtc->primary; > > > + > > > + lockdep_assert_held(&plane->mutex); > > > > kbuild test robot told me > > >> include/linux/lockdep.h:347:52: error: 'struct drm_modeset_lock' has > > >> no member named 'dep_map' > > #define lockdep_is_held(lock) lock_is_held(&(lock)->dep_map) > > > > Maybe I'll just drop the asserts? Or do people really want them > > (in which case I gues I need to dig out the underlying mutex)? > > Eitherway is fine with me. I just dropped them, and pushe the series to drm-misc-next. Thanks for the reviews everyone. Fingers crossed that no new uses of the legacy pointers have been added in the meantime. A quick grep didn't seem to catch anything at least, but selective blindness can occur sometimes. So just holler if anything broke... -- Ville Syrjälä Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx