| Message ID | 1379620986-1702-3-git-send-email-przanoni@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Sep 19, 2013 at 05:03:06PM -0300, Paulo Zanoni wrote: > From: Paulo Zanoni <paulo.r.zanoni@intel.com> > > At the end of haswell_crtc_enable we have an intel_wait_for_vblank > with a big comment, and the message suggests it's a workaround for > something we don't really understand. So I removed that wait and > started getting HW state readout error messages saying that the IPS > state is not what we expected. > > I investigated and concluded that after you write IPS_ENABLE to > IPS_CTL, the bit will only actually become 1 on the next vblank. So > add code to wait for the IPS_ENABLE bit. We don't really need this > wait right now due to the wait I already mentioned, but at least this > one has a reason to be there, while the other one is just to > workaround some problem: we may remove it in the future. > > The wait also acts as a POSTING_READ which we missed. > > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Both patches: Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> I was thinking that maybe the intel_wait_for_vblank would be better from a documenting perspective - and it would also give warnings for trying to enable ips whilst the pipe was off. But you would still need the wait for IPS_ENABLE as confirmation anyway. -Chris
On Thu, Sep 19, 2013 at 09:24:33PM +0100, Chris Wilson wrote: > On Thu, Sep 19, 2013 at 05:03:06PM -0300, Paulo Zanoni wrote: > > From: Paulo Zanoni <paulo.r.zanoni@intel.com> > > > > At the end of haswell_crtc_enable we have an intel_wait_for_vblank > > with a big comment, and the message suggests it's a workaround for > > something we don't really understand. So I removed that wait and > > started getting HW state readout error messages saying that the IPS > > state is not what we expected. > > > > I investigated and concluded that after you write IPS_ENABLE to > > IPS_CTL, the bit will only actually become 1 on the next vblank. So > > add code to wait for the IPS_ENABLE bit. We don't really need this > > wait right now due to the wait I already mentioned, but at least this > > one has a reason to be there, while the other one is just to > > workaround some problem: we may remove it in the future. > > > > The wait also acts as a POSTING_READ which we missed. > > > > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > > Both patches: > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> > > I was thinking that maybe the intel_wait_for_vblank would be better from > a documenting perspective - and it would also give warnings for trying > to enable ips whilst the pipe was off. But you would still need the wait > for IPS_ENABLE as confirmation anyway. Both queued for -next, thanks for the patches&review. -Daniel
2013/9/20 Daniel Vetter <daniel@ffwll.ch>: > On Thu, Sep 19, 2013 at 09:24:33PM +0100, Chris Wilson wrote: >> On Thu, Sep 19, 2013 at 05:03:06PM -0300, Paulo Zanoni wrote: >> > From: Paulo Zanoni <paulo.r.zanoni@intel.com> >> > >> > At the end of haswell_crtc_enable we have an intel_wait_for_vblank >> > with a big comment, and the message suggests it's a workaround for >> > something we don't really understand. So I removed that wait and >> > started getting HW state readout error messages saying that the IPS >> > state is not what we expected. >> > >> > I investigated and concluded that after you write IPS_ENABLE to >> > IPS_CTL, the bit will only actually become 1 on the next vblank. So >> > add code to wait for the IPS_ENABLE bit. We don't really need this >> > wait right now due to the wait I already mentioned, but at least this >> > one has a reason to be there, while the other one is just to >> > workaround some problem: we may remove it in the future. >> > >> > The wait also acts as a POSTING_READ which we missed. >> > >> > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> >> >> Both patches: >> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> >> >> I was thinking that maybe the intel_wait_for_vblank would be better from >> a documenting perspective - and it would also give warnings for trying >> to enable ips whilst the pipe was off. But you would still need the wait >> for IPS_ENABLE as confirmation anyway. > > Both queued for -next, thanks for the patches&review. Hmmm, this patch depends on the "enable planes only after the pipe is really running" patch. Due to that missing patch, now I get "[drm:hsw_enable_ips] *ERROR* Timed out waiting for IPS enable" when booting. I should have said this, sorry :( I > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Fri, Sep 20, 2013 at 12:18:29PM -0300, Paulo Zanoni wrote: > 2013/9/20 Daniel Vetter <daniel@ffwll.ch>: > > On Thu, Sep 19, 2013 at 09:24:33PM +0100, Chris Wilson wrote: > >> On Thu, Sep 19, 2013 at 05:03:06PM -0300, Paulo Zanoni wrote: > >> > From: Paulo Zanoni <paulo.r.zanoni@intel.com> > >> > > >> > At the end of haswell_crtc_enable we have an intel_wait_for_vblank > >> > with a big comment, and the message suggests it's a workaround for > >> > something we don't really understand. So I removed that wait and > >> > started getting HW state readout error messages saying that the IPS > >> > state is not what we expected. > >> > > >> > I investigated and concluded that after you write IPS_ENABLE to > >> > IPS_CTL, the bit will only actually become 1 on the next vblank. So > >> > add code to wait for the IPS_ENABLE bit. We don't really need this > >> > wait right now due to the wait I already mentioned, but at least this > >> > one has a reason to be there, while the other one is just to > >> > workaround some problem: we may remove it in the future. > >> > > >> > The wait also acts as a POSTING_READ which we missed. > >> > > >> > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > >> > >> Both patches: > >> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> > >> > >> I was thinking that maybe the intel_wait_for_vblank would be better from > >> a documenting perspective - and it would also give warnings for trying > >> to enable ips whilst the pipe was off. But you would still need the wait > >> for IPS_ENABLE as confirmation anyway. > > > > Both queued for -next, thanks for the patches&review. > > Hmmm, this patch depends on the "enable planes only after the pipe is > really running" patch. Due to that missing patch, now I get > "[drm:hsw_enable_ips] *ERROR* Timed out waiting for IPS enable" when > booting. I should have said this, sorry :( Ok, I've dropped it again. -Daniel
2013/9/20 Daniel Vetter <daniel@ffwll.ch>: > On Fri, Sep 20, 2013 at 12:18:29PM -0300, Paulo Zanoni wrote: >> 2013/9/20 Daniel Vetter <daniel@ffwll.ch>: >> > On Thu, Sep 19, 2013 at 09:24:33PM +0100, Chris Wilson wrote: >> >> On Thu, Sep 19, 2013 at 05:03:06PM -0300, Paulo Zanoni wrote: >> >> > From: Paulo Zanoni <paulo.r.zanoni@intel.com> >> >> > >> >> > At the end of haswell_crtc_enable we have an intel_wait_for_vblank >> >> > with a big comment, and the message suggests it's a workaround for >> >> > something we don't really understand. So I removed that wait and >> >> > started getting HW state readout error messages saying that the IPS >> >> > state is not what we expected. >> >> > >> >> > I investigated and concluded that after you write IPS_ENABLE to >> >> > IPS_CTL, the bit will only actually become 1 on the next vblank. So >> >> > add code to wait for the IPS_ENABLE bit. We don't really need this >> >> > wait right now due to the wait I already mentioned, but at least this >> >> > one has a reason to be there, while the other one is just to >> >> > workaround some problem: we may remove it in the future. >> >> > >> >> > The wait also acts as a POSTING_READ which we missed. >> >> > >> >> > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> >> >> >> >> Both patches: >> >> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> >> >> >> >> I was thinking that maybe the intel_wait_for_vblank would be better from >> >> a documenting perspective - and it would also give warnings for trying >> >> to enable ips whilst the pipe was off. But you would still need the wait >> >> for IPS_ENABLE as confirmation anyway. >> > >> > Both queued for -next, thanks for the patches&review. >> >> Hmmm, this patch depends on the "enable planes only after the pipe is >> really running" patch. Due to that missing patch, now I get >> "[drm:hsw_enable_ips] *ERROR* Timed out waiting for IPS enable" when >> booting. I should have said this, sorry :( > > Ok, I've dropped it again. It should be safe to merge it now. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Tue, Oct 08, 2013 at 06:02:30PM -0300, Paulo Zanoni wrote: > 2013/9/20 Daniel Vetter <daniel@ffwll.ch>: > > On Fri, Sep 20, 2013 at 12:18:29PM -0300, Paulo Zanoni wrote: > >> 2013/9/20 Daniel Vetter <daniel@ffwll.ch>: > >> > On Thu, Sep 19, 2013 at 09:24:33PM +0100, Chris Wilson wrote: > >> >> On Thu, Sep 19, 2013 at 05:03:06PM -0300, Paulo Zanoni wrote: > >> >> > From: Paulo Zanoni <paulo.r.zanoni@intel.com> > >> >> > > >> >> > At the end of haswell_crtc_enable we have an intel_wait_for_vblank > >> >> > with a big comment, and the message suggests it's a workaround for > >> >> > something we don't really understand. So I removed that wait and > >> >> > started getting HW state readout error messages saying that the IPS > >> >> > state is not what we expected. > >> >> > > >> >> > I investigated and concluded that after you write IPS_ENABLE to > >> >> > IPS_CTL, the bit will only actually become 1 on the next vblank. So > >> >> > add code to wait for the IPS_ENABLE bit. We don't really need this > >> >> > wait right now due to the wait I already mentioned, but at least this > >> >> > one has a reason to be there, while the other one is just to > >> >> > workaround some problem: we may remove it in the future. > >> >> > > >> >> > The wait also acts as a POSTING_READ which we missed. > >> >> > > >> >> > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > >> >> > >> >> Both patches: > >> >> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> > >> >> > >> >> I was thinking that maybe the intel_wait_for_vblank would be better from > >> >> a documenting perspective - and it would also give warnings for trying > >> >> to enable ips whilst the pipe was off. But you would still need the wait > >> >> for IPS_ENABLE as confirmation anyway. > >> > > >> > Both queued for -next, thanks for the patches&review. > >> > >> Hmmm, this patch depends on the "enable planes only after the pipe is > >> really running" patch. Due to that missing patch, now I get > >> "[drm:hsw_enable_ips] *ERROR* Timed out waiting for IPS enable" when > >> booting. I should have said this, sorry :( > > > > Ok, I've dropped it again. > > It should be safe to merge it now. Done, thanks for the ping. -Daniel
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 78ff5ed..8fd13ab 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3374,6 +3374,14 @@ static void hsw_enable_ips(struct intel_crtc *crtc) * for a vblank, so all we need to do here is to enable the IPS bit. */ assert_plane_enabled(dev_priv, crtc->plane); I915_WRITE(IPS_CTL, IPS_ENABLE); + + /* The bit only becomes 1 in the next vblank, so this wait here is + * essentially intel_wait_for_vblank. If we don't have this and don't + * wait for vblanks until the end of crtc_enable, then the HW state + * readout code will complain that the expected IPS_CTL value is not the + * one we read. */ + if (wait_for(I915_READ_NOTRACE(IPS_CTL) & IPS_ENABLE, 50)) + DRM_ERROR("Timed out waiting for IPS enable\n"); } static void hsw_disable_ips(struct intel_crtc *crtc)