Re: [PATCH 1/2] drm/radeon: Use drm_vblank_off/on to fix vblank counter trouble.

From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: daniel.vetter@ffwll.ch, "Michel Dänzer" <michel@daenzer.net>,
	dri-devel@lists.freedesktop.org, alexander.deucher@amd.com,
	christian.koenig@amd.com, vbabka@suse.cz
Subject: Re: [PATCH 1/2] drm/radeon: Use drm_vblank_off/on to fix vblank counter trouble.
Date: Thu, 21 Jan 2016 22:12:35 +0200	[thread overview]
Message-ID: <20160121201235.GK23290@intel.com> (raw)
In-Reply-To: <56A0A1D1.3000905@gmail.com>

On Thu, Jan 21, 2016 at 10:16:01AM +0100, Mario Kleiner wrote:
> On 01/21/2016 09:25 AM, Michel Dänzer wrote:
> > On 21.01.2016 17:16, Mario Kleiner wrote:
> >>
> >> This patch replaces calls to drm_vblank_pre/post_modeset in the
> >> drivers dpms code with calls to drm_vblank_off/on, as recommended
> >> for drivers with hw counters that reset to zero during modeset.
> >
> > Sounds like you fell for the drm_vblank_on/off propaganda. :( This was
> > working fine with drm_vblank_pre/post_modeset, that it broke is simply a
> > regression.
> >
> 
> I agree with you that pre/post modeset breakage is a regression. It's 
> just that i stumbled over the on/off stuff while searching for a 
> solution and the other sort of hacks i could think of looked similar or 
> more convoluted/hacky/fragile to me. And they probably wouldn't solve 
> that other small race i found as easily - I don't think it's likely to 
> happen (often/at all?) in practice, but i have trouble "forgetting" 
> about its existence now.
> 
> >
> > I'm not against switching to drm_vblank_on/off for 4.6, but it's not a
> > solution for older kernels.
> >
> >
> 
> Linux 4.4 is an especially important stable kernel for me because it's 
> supposed to be the standard distro kernel for Ubuntu 16.04-LTS and 
> siblings/derivatives (Linux Mint) for up to the next 5 years. Having 
> many of my neuroscience users ending on that kernel as their very first 
> impression of Linux with something potentially broken in vblank land 
> scares me. The reliability of timing/timestamping stuff is 
> super-important for them, at the same time hand-holding many of them 
> through non-standard kernel upgrades would be so much not fun. Just to 
> say i'm probably way too biased wrt. what solution for this should get 
> backported into an older kernel.

In hindsight I/we should have probably just totally forked the vblank
code and leave radeon to do whatever it was doing since people were
apparently satisfied with its state at the time. I guess it would
still be possible to do that if needed, though I've not looked at how
much extra indirection would be required.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel