On Mon, Jan 25, 2016 at 10:42 PM, Mario Kleiner <mario.kleiner.de@xxxxxxxxx> wrote: >> >>> Now the patch i want to try next to fix the drm_vblank_pre/post_modeset >>> regression in Linux 4.4/4.5 is to add a ... >>> >>> if ((diff > 1) && vblank->inmodeset) diff = 1; >>> >>> ... to the bottom of drm_update_vblank_count(). That should hopefully >>> restore the pre/post_modeset behavior as close to the original behavior >>> as >>> possible. As a side effect it would also prevent the counter jump caused >>> by >>> redundant calls to drm_vblank_off(). >> >> >> Hm, can we just frob pre/post_modeset only with some checks? I'd like to >> not put that kind of "I have no idea about my hw state" hacks into the new >> helpers. Otherwise not even atomic drivers can start to gain WARN_ONs to >> enforce correct usage, which would be a real bummer imo. >> -Daniel >> > > We could check for only (vblank->inmodeset & 0x2) to only apply it to the > legacy pre/post path, trusting that the drm_vblank_off/on path will be made > robust in a different way, e.g., by the stuff discussed above and careful > implementation in each kms driver that uses those. Atm. radeon doesn't use > off/on, so your enablement patch set can make sure it does the right thing > from the beginning. > > rockchip-kms may need similar treatment to radeon to avoid redundant calls. > > Btw. how the patch to drm_update_vblank_count() close to the bottom would > actually look is more like: > > if ((diff > 1) && > ((vblank->inmodeset & 0x2) || (flags & DRM_CALLED_FROM_VBLIRQ))) > diff = 1; Yeah I think that should work as a short-term fix for radoen. When you do that, can you pls do a second patch to give the magic 0x2 and 0x1 some meaning? Otherwise this is super-hard to understand code ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
