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

Michel Dänzer michel at daenzer.net
Thu Jan 21 19:17:16 PST 2016


On 21.01.2016 18:16, 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.

Finding and fixing the cause of a regression isn't a hack, it's
established procedure.


> 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.

That's something which should be addressed independently from the
regression fix.

Please split up the PM fixes from your patch into one or two separate
patches (which may be appropriate for 4.5 / stable trees), and leave the
switch to drm_vblank_on/off to Daniel's patch for 4.6.


>> 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.

But fast-tracking the switch to drm_vblank_on/off, which haven't been
widely tested with this driver, all the way to 4.4 seems less risky to
you? Seriously?

> Just to say i'm probably way too biased wrt. what solution for this
> should get backported into an older kernel.

At the risk of sounding like a broken record: There's a bug in 4.4 (and
older/newer kernels) causing the vblank counter to jump forward across
DPMS off with drm_vblank_on/off. So it sounds like you don't want to use
those at least until we've found and fixed that.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer


More information about the dri-devel mailing list