From: "Michel Dänzer" <michel@daenzer.net>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 5/5] drm/i915: Allow vblank interrupts during modeset and eliminate some vblank races
Date: Fri, 30 May 2014 12:13:09 +0900 [thread overview]
Message-ID: <5387F745.4090301@daenzer.net> (raw)
In-Reply-To: <CAKMK7uFp+HbngWLsm6giGOCu9p=uQvTkYPijcerzSi2f_-4LdQ@mail.gmail.com>
On 29.05.2014 19:56, Daniel Vetter wrote:
> On Thu, May 29, 2014 at 6:11 AM, Michel Dänzer <michel@daenzer.net> wrote:
>>
>>> We could rename the off/on to pre/post_modeset if you like, but then
>>> someone gets to audit all the other drivers. That someone isn't
>>> going to be me.
>>
>> I appreciate your caution wrt other drivers, but I'm worried that having
>> a second mechanism for keeping the DRM vblank counter consistent might
>> cause subtle problems for drivers using the existing mechanism anyway.
>
> I think that risk is rather low. Only i915 has been stupid enough to
> use both drm_vblank_off + pre/post_modeset in the normal crtc
> enable/disable functions. Everyone else uses either or the other,
> except for tegra which uses pre/post in the ->prepare/commit hooks and
> off in the crtc->disable callback. So should still get consistent
> results (since after ->disable vblank consistency stops mattering).
>
> The reason we do all this is that we want to kill the delayed vblank
> put for i915, which is possible if you have a hw vblank counter.
That should also be possible with pre/post_modeset. (Not sure
eliminating it completely is a good idea for the reasons you mentioned
before, but at least decreasing it significantly should be no problem. I
think even dropping the default a lot for all drivers should be rather
low risk)
> There's apparently more stuff wrong here still, so while we wrestle
> around probably best to leave other drivers out. I guess once this is
> all done I have to roll it out across all drivers so that we have
> consistent behaviour again ...
Since AFAICT radeon isn't affected by the problem drm_vblank_off() was
supposed to solve originally, I'd prefer if it didn't start using that
and potentially suffer from all the trouble it seems to cause.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2014-05-30 3:13 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-21 19:03 [PATCH 0/5] drm: Allow vblank interrupts during modeset and make the code less racy ville.syrjala
2014-02-21 19:03 ` [PATCH 1/5] drm: Use correct spinlock flavor in drm_vblank_get() ville.syrjala
2014-02-26 19:24 ` [Intel-gfx] " Jesse Barnes
2014-02-21 19:03 ` [PATCH 2/5] drm: Make the vblank disable timer per-crtc ville.syrjala
2014-02-26 19:32 ` Jesse Barnes
2014-02-21 19:03 ` [PATCH 3/5] drm: Allow the driver to reject vblank requests only when it really has the vblank interrupts disabled ville.syrjala
2014-02-26 19:41 ` Jesse Barnes
2014-03-04 9:24 ` Daniel Vetter
2014-03-05 12:38 ` Ville Syrjälä
2014-03-05 13:55 ` Daniel Vetter
2014-02-21 19:03 ` [PATCH 4/5] drm: Allow reenabling of vblank interrupts even if refcount>0 ville.syrjala
2014-02-26 19:44 ` Jesse Barnes
2014-03-04 9:16 ` Daniel Vetter
2014-03-05 12:33 ` Ville Syrjälä
2014-02-21 19:03 ` [PATCH 5/5] drm/i915: Allow vblank interrupts during modeset and eliminate some vblank races ville.syrjala
2014-02-24 3:48 ` Michel Dänzer
2014-02-24 12:11 ` Ville Syrjälä
2014-02-25 2:58 ` Michel Dänzer
2014-02-26 19:48 ` Jesse Barnes
2014-03-04 9:13 ` Daniel Vetter
2014-05-28 9:12 ` Michel Dänzer
2014-05-28 11:19 ` [Intel-gfx] " Ville Syrjälä
2014-05-29 4:11 ` Michel Dänzer
2014-05-29 10:56 ` Daniel Vetter
2014-05-30 3:13 ` Michel Dänzer [this message]
2014-02-28 8:56 ` Ville Syrjälä
2014-03-04 9:15 ` Daniel Vetter
-- strict thread matches above, loose matches on Subject: below --
2025-05-07 21:55 Morales Manuel
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=5387F745.4090301@daenzer.net \
--to=michel@daenzer.net \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--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 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.