All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michel Dänzer" <michel@daenzer.net>
To: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [RFC PATCH] drm/vblanks: Deal with HW vblank counter resets.
Date: Tue, 7 Nov 2017 10:47:00 +0100	[thread overview]
Message-ID: <d749aef1-4738-6800-2e6c-a872f15ad3f7@daenzer.net> (raw)
In-Reply-To: <20171107062617.4227-1-dhinakaran.pandiyan@intel.com>

On 07/11/17 07:26 AM, Dhinakaran Pandiyan wrote:
> Some HW vblank counters reset due to power management events, which messes
> up the vblank counting logic. This leads to screen freezes with user space
> waiting on vblank events that may not occur if the counter keeps resetting.
> 
> For e.g., After the HW vblank counter resets
> [    9.007359] [drm:drm_update_vblank_count [drm]] updating vblank count
> on crtc 0: current=297, diff=4294965389, hw=5 hw_last=1912
> 
> So, fall back to the SW counter, computed using  vblank timestamps
> and frame duration, when the HW counter value deviates by 50% of the SW
> computed value.
> 
> I have tested this patch on my SKL laptop with i915.enable_psr=1 and it
> *seems* to solve the screen freeze issue seen with PSR when DMC is loaded.
> 
> Known issues:
> 1) The 50% deviation margin is arbitrary.
> 2) "Redundant vblirq ignored" messages are more frequent.
> 
> I am sending this as an RFC to get feedback on whether the fall back
> approach is sane and if it should be implemented in the core.

Is there no way for the driver to know under which circumstances the
reset to 0 might happen? If there is, maybe it could be solved by
calling drm_crtc_vblank_off() before it might happen and
drm_crtc_vblank_on() after it might have happened.

Otherwise, might it be better not to use the HW counter at all when it's
known not to be reliable?


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2017-11-07  9:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-07  6:26 [RFC PATCH] drm/vblanks: Deal with HW vblank counter resets Dhinakaran Pandiyan
2017-11-07  9:07 ` ✗ Fi.CI.BAT: failure for " Patchwork
2017-11-07  9:47 ` Michel Dänzer [this message]
2017-11-07 10:50   ` [RFC PATCH] " Ville Syrjälä
2017-11-07 10:55     ` Michel Dänzer
2017-11-07 11:26       ` Ville Syrjälä
2017-11-07 12:39   ` Daniel Vetter
2017-11-07 19:14     ` Pandiyan, Dhinakaran
2017-11-08 12:29 ` ✓ Fi.CI.BAT: success for " Patchwork

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=d749aef1-4738-6800-2e6c-a872f15ad3f7@daenzer.net \
    --to=michel@daenzer.net \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dhinakaran.pandiyan@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=rodrigo.vivi@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.