Hi all, On Thu, 16 Jan 2020 at 07:37, Thomas Zimmermann <tzimmermann@xxxxxxx> wrote: > > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c > > index 7cf3cf936547..23d2f51fc1d4 100644 > > --- a/drivers/gpu/drm/drm_atomic_state_helper.c > > +++ b/drivers/gpu/drm/drm_atomic_state_helper.c > > @@ -149,6 +149,11 @@ void __drm_atomic_helper_crtc_duplicate_state(struct drm_crtc *crtc, > > /* Self refresh should be canceled when a new update is available */ > > state->active = drm_atomic_crtc_effectively_active(state); > > state->self_refresh_active = false; > > + > > + if (drm_dev_has_vblank(crtc->dev)) > > + state->no_vblank = true; > > + else > > + state->no_vblank = false; > > } > > EXPORT_SYMBOL(__drm_atomic_helper_crtc_duplicate_state); > > I think the if/else branches are in the wrong order. > > But generally speaking, is it really that easy? The xen driver already > has to work around simple-kms's auto-enabling of no_vblank (see patch > 4). Maybe this settings interferes with other drivers as well. At least > the calls for sending fake vblanks should be removed from all affected > drivers. > I'm not sure if setting no_vblank based on dev->num_crtcs is the correct thing. >From the original commit and associated description for no_vblank: In some cases CRTCs are active but are not able to generating events, at least not at every frame at it's expected to. This is typically the case when the CRTC is feeding a writeback connector... Reflects the ability of a CRTC to send VBLANK events.... The proposed handling of no_vblank feels a little dirty, although nothing better comes to mind. Nevertheless code seems perfectly reasonable, so if it were me I'd merge it. HTH Emil _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
