From: Mika Kahola <mika.kahola@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/dsi: Silence atomic update failure with DSI panel
Date: Wed, 06 Sep 2017 13:09:38 +0300 [thread overview]
Message-ID: <1504692578.12240.67.camel@intel.com> (raw)
In-Reply-To: <20170905161140.jbvxhzpzo4wrnfoo@phenom.ffwll.local>
On Tue, 2017-09-05 at 18:11 +0200, Daniel Vetter wrote:
> On Tue, Sep 05, 2017 at 04:35:04PM +0300, Mika Kahola wrote:
> >
> > It appears that we cannot trust scanline counters when MIPI/DSI
> > display is
> > connected. In CI system this appears as flickering errors that
> > randomly
> > appear in test cases. To avoid this flickering, let's just silence
> > atomic
> > update failure in case with DSI panel.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102403
> > Signed-off-by: Mika Kahola <mika.kahola@intel.com>
> This just changes a loud atomic failure to a silent atomic failure.
> What
> we instead need to do is actually fix the bug, not hide it.
>
BSpec has a notion that (PIPE_SCANLINE) that is "Not supported with
MIPI DSI."
That's why I thought it might be ok to silence the error as the
computation that we try to accomplish wouldn't work anyway. Maybe this
way we could remove DSI from being blackllisted.
> This means DSI is atm blacklisted almost entirely, but well it's
> broken,
> so no harm in that.
>
> Please no polishing of just results in CI, it needs to give us honest
> results.
> -Daniel
> >
> > ---
> > drivers/gpu/drm/i915/intel_sprite.c | 32 +++++++++++++++++------
> > ---------
> > 1 file changed, 17 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index b0d6e3e..8511072 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -205,23 +205,25 @@ void intel_pipe_update_end(struct
> > intel_crtc_state *new_crtc_state)
> > if (intel_vgpu_active(dev_priv))
> > return;
> >
> > - if (crtc->debug.start_vbl_count &&
> > - crtc->debug.start_vbl_count != end_vbl_count) {
> > - DRM_ERROR("Atomic update failure on pipe %c
> > (start=%u end=%u) time %lld us, min %d, max %d, scanline start %d,
> > end %d\n",
> > - pipe_name(pipe), crtc-
> > >debug.start_vbl_count,
> > - end_vbl_count,
> > - ktime_us_delta(end_vbl_time, crtc-
> > >debug.start_vbl_time),
> > - crtc->debug.min_vbl, crtc-
> > >debug.max_vbl,
> > - crtc->debug.scanline_start,
> > scanline_end);
> > - }
> > + if (!intel_crtc_has_type(new_crtc_state,
> > INTEL_OUTPUT_DSI)) {
> > + if (crtc->debug.start_vbl_count &&
> > + crtc->debug.start_vbl_count != end_vbl_count)
> > {
> > + DRM_ERROR("Atomic update failure on pipe
> > %c (start=%u end=%u) time %lld us, min %d, max %d, scanline start
> > %d, end %d\n",
> > + pipe_name(pipe), crtc-
> > >debug.start_vbl_count,
> > + end_vbl_count,
> > + ktime_us_delta(end_vbl_time,
> > crtc->debug.start_vbl_time),
> > + crtc->debug.min_vbl, crtc-
> > >debug.max_vbl,
> > + crtc->debug.scanline_start,
> > scanline_end);
> > + }
> > #ifdef CONFIG_DRM_I915_DEBUG_VBLANK_EVADE
> > - else if (ktime_us_delta(end_vbl_time, crtc-
> > >debug.start_vbl_time) >
> > - VBLANK_EVASION_TIME_US)
> > - DRM_WARN("Atomic update on pipe (%c) took %lld us,
> > max time under evasion is %u us\n",
> > - pipe_name(pipe),
> > - ktime_us_delta(end_vbl_time, crtc-
> > >debug.start_vbl_time),
> > - VBLANK_EVASION_TIME_US);
> > + else if (ktime_us_delta(end_vbl_time, crtc-
> > >debug.start_vbl_time) >
> > + VBLANK_EVASION_TIME_US)
> > + DRM_WARN("Atomic update on pipe (%c) took
> > %lld us, max time under evasion is %u us\n",
> > + pipe_name(pipe),
> > + ktime_us_delta(end_vbl_time,
> > crtc->debug.start_vbl_time),
> > + VBLANK_EVASION_TIME_US);
> > #endif
> > + }
> > }
> >
> > static void
> > --
> > 2.7.4
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Mika Kahola - Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2017-09-06 10:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-05 13:35 [PATCH] drm/i915/dsi: Silence atomic update failure with DSI panel Mika Kahola
2017-09-05 14:00 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-09-05 16:00 ` ✗ Fi.CI.IGT: warning " Patchwork
2017-09-05 16:11 ` [PATCH] " Daniel Vetter
2017-09-06 10:09 ` Mika Kahola [this message]
2017-09-06 16:48 ` Martin Peres
2017-09-08 6:58 ` Daniel Vetter
2017-09-07 11:29 ` Maarten Lankhorst
2017-09-07 11:47 ` Ville Syrjälä
2017-09-07 11:48 ` Mika Kahola
2017-09-07 11:59 ` Ville Syrjälä
2017-09-08 7:00 ` Daniel Vetter
2017-09-08 14:15 ` Shankar, Uma
2017-09-08 8:54 ` kbuild test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1504692578.12240.67.camel@intel.com \
--to=mika.kahola@intel.com \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox