Re: linux-4.4 bisected: kwin5 stuck on kde5 loading screen with radeon

[Daniel Vetter]

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