| Message ID | 1481204729-9058-5-git-send-email-maarten.lankhorst@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Dec 08, 2016 at 02:45:27PM +0100, Maarten Lankhorst wrote: > The current api doesn't take into account that whenever properties like > rotation or z-pos change we have to wait for vblank. To make sure > that we wait correctly, err on the side of caution and wait whenever > a plane is added to state. Why do we need to wait when rotation or zpos has changed? I'm a bit lost ... So rotation makes sense since often that means a special, rotated mapping (or a different offset on omap's TILER as a different example). But z-pos I have no idad why that matters. -Daniel > > Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > --- > drivers/gpu/drm/drm_atomic_helper.c | 6 +----- > 1 file changed, 1 insertion(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c > index ccf0bed9bf4a..fdeaea84a3b7 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -1123,11 +1123,7 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, > for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) { > struct drm_crtc_state *new_crtc_state = crtc->state; > > - if (!new_crtc_state->active) > - continue; > - > - if (!drm_atomic_helper_framebuffer_changed(dev, > - old_state, crtc)) > + if (!new_crtc_state->active || !new_crtc_state->planes_changed) > continue; > > ret = drm_crtc_vblank_get(crtc); > -- > 2.7.4 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
Op 08-12-16 om 16:43 schreef Daniel Vetter: > On Thu, Dec 08, 2016 at 02:45:27PM +0100, Maarten Lankhorst wrote: >> The current api doesn't take into account that whenever properties like >> rotation or z-pos change we have to wait for vblank. To make sure >> that we wait correctly, err on the side of caution and wait whenever >> a plane is added to state. > Why do we need to wait when rotation or zpos has changed? I'm a bit lost > ... So rotation makes sense since often that means a special, rotated > mapping (or a different offset on omap's TILER as a different example). > But z-pos I have no idad why that matters. It was meant as example, blocking commit always waits for the changes to be visible before returning, from what I understand. So if any plane property changes we have to wait for the changes to be visible first. ~Maarten
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index ccf0bed9bf4a..fdeaea84a3b7 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -1123,11 +1123,7 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) { struct drm_crtc_state *new_crtc_state = crtc->state; - if (!new_crtc_state->active) - continue; - - if (!drm_atomic_helper_framebuffer_changed(dev, - old_state, crtc)) + if (!new_crtc_state->active || !new_crtc_state->planes_changed) continue; ret = drm_crtc_vblank_get(crtc);
The current api doesn't take into account that whenever properties like rotation or z-pos change we have to wait for vblank. To make sure that we wait correctly, err on the side of caution and wait whenever a plane is added to state. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> --- drivers/gpu/drm/drm_atomic_helper.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-)