| Message ID | 54147012.40609@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sat, Sep 13, 2014 at 06:25:54PM +0200, Mario Kleiner wrote: > The current drm-next misses Ville's original Patch 14/19, the one i first > objected, then objected to my objection. It is needed to avoid actual > regressions. Attached a trivially rebased (v2) of Ville's patch to go on top > of drm-next, also as tgz in case my e-mail client mangles the patch again, > because it's one of those "email hates me" weeks. Oh dear, I've made a decent mess of all of this really. Picked up to make sure it doesn't get lost again. -Daniel
On Mon, 15 Sep 2014, Daniel Vetter <daniel@ffwll.ch> wrote: > On Sat, Sep 13, 2014 at 06:25:54PM +0200, Mario Kleiner wrote: >> The current drm-next misses Ville's original Patch 14/19, the one i first >> objected, then objected to my objection. It is needed to avoid actual >> regressions. Attached a trivially rebased (v2) of Ville's patch to go on top >> of drm-next, also as tgz in case my e-mail client mangles the patch again, >> because it's one of those "email hates me" weeks. > > Oh dear, I've made a decent mess of all of this really. Picked up to make > sure it doesn't get lost again. After all this nice ping pong our QA has reported a bisected regression on this commit: https://bugs.freedesktop.org/show_bug.cgi?id=84161 BR, Jani.
On Tue, Sep 23, 2014 at 03:48:25PM +0300, Jani Nikula wrote: > On Mon, 15 Sep 2014, Daniel Vetter <daniel@ffwll.ch> wrote: > > On Sat, Sep 13, 2014 at 06:25:54PM +0200, Mario Kleiner wrote: > >> The current drm-next misses Ville's original Patch 14/19, the one i first > >> objected, then objected to my objection. It is needed to avoid actual > >> regressions. Attached a trivially rebased (v2) of Ville's patch to go on top > >> of drm-next, also as tgz in case my e-mail client mangles the patch again, > >> because it's one of those "email hates me" weeks. > > > > Oh dear, I've made a decent mess of all of this really. Picked up to make > > sure it doesn't get lost again. > > After all this nice ping pong our QA has reported a bisected regression > on this commit: https://bugs.freedesktop.org/show_bug.cgi?id=84161 Looks like a minuscule timing change which resulted in us detecting a fifo underrun. Or at least I don't see any other related information that would indicate otherwise ... -Daniel
On 23/09/14 15:51, Daniel Vetter wrote: > On Tue, Sep 23, 2014 at 03:48:25PM +0300, Jani Nikula wrote: >> On Mon, 15 Sep 2014, Daniel Vetter <daniel@ffwll.ch> wrote: >>> On Sat, Sep 13, 2014 at 06:25:54PM +0200, Mario Kleiner wrote: >>>> The current drm-next misses Ville's original Patch 14/19, the one i first >>>> objected, then objected to my objection. It is needed to avoid actual >>>> regressions. Attached a trivially rebased (v2) of Ville's patch to go on top >>>> of drm-next, also as tgz in case my e-mail client mangles the patch again, >>>> because it's one of those "email hates me" weeks. >>> >>> Oh dear, I've made a decent mess of all of this really. Picked up to make >>> sure it doesn't get lost again. >> >> After all this nice ping pong our QA has reported a bisected regression >> on this commit: https://bugs.freedesktop.org/show_bug.cgi?id=84161 > > Looks like a minuscule timing change which resulted in us detecting a fifo > underrun. Or at least I don't see any other related information that would > indicate otherwise ... > -Daniel > There's nothing in that code path which could cause this - except for altered execution timing. I've seen that warning as well on my Intel HD Ironlake Mobile (MBP 2010), but only spuriously when plugging/unplugging an external display into the laptop iirc, so i thought it would be unrelated. -mario
From c0a5228a7fc43d4c3615a471c340b68bcb2caa16 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com> Date: Wed, 6 Aug 2014 14:49:57 +0300 Subject: [PATCH] drm: Don't update vblank timestamp when the counter didn't change (v2) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit If we already have a timestamp for the current vblank counter, don't update it with a new timestmap. Small errors can creep in between two timestamp queries for the same vblank count, which could be confusing to userspace when it queries the timestamp for the same vblank sequence number twice. This problem gets exposed when the vblank disable timer is not used (or is set to expire quickly) and thus we can get multiple vblank disable<->enable transition during the same frame which would all attempt to update the timestamp with the latest estimate. Testcase: igt/kms_flip/flip-vs-expired-vblank Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com> v2:Mario: Trivial rebase on top of current drm-next (13-Sep-2014) Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> --- drivers/gpu/drm/drm_irq.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index 80ff94a..e73cbda 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -126,6 +126,9 @@ static void drm_update_vblank_count(struct drm_device *dev, int crtc) DRM_DEBUG("updating vblank count on crtc %d, missed %d\n", crtc, diff); + if (diff == 0) + return; + /* Reinitialize corresponding vblank timestamp if high-precision query * available. Skip this step if query unsupported or failed. Will * reinitialize delayed at next vblank interrupt in that case. -- 1.9.1