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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
