mimic the behavior of vblank_disable_fn(), another caller of
drm_vblank_disable_and_save().
This avoids oopsing, while trying to disable vblank on a not connected display:
[ 12.768079] WARNING: CPU: 0 PID: 274 at drivers/gpu/drm/drm_vblank.c:609
drm_calc_vbltimestamp_from_scanoutpos+0x296/0x32
Mh ok,
paper over in nouveau_display_fini until Ben comes up with a better idea
then?!
Greetings,
Tobias
On 7/20/17 10:13 AM, Daniel Vetter wrote:
> On Wed, Jul 19, 2017 at 04:10:50PM -0400, Ilia Mirkin wrote:
>> I believe the solution is to not call drm_crtc_vblank_off for atomic
>> modesett
On Thu, Jul 20, 2017 at 11:58 PM, Tobias Klausmann
wrote:
> Mh ok,
>
> paper over in nouveau_display_fini until Ben comes up with a better idea
> then?!
No paper needed, just don't call drm_vblank_off for the atomic case.
Not sure why that patch isn't landed yet, it should be simple.
-Daniel
>
>
On Wed, Jul 19, 2017 at 04:10:50PM -0400, Ilia Mirkin wrote:
> I believe the solution is to not call drm_crtc_vblank_off for atomic
> modesetting in nouveau_display_fini. I think Ben's working on it.
Yes, the goal of vblank_on/off was very much to not paper over driver bugs
with clever tricks like
I believe the solution is to not call drm_crtc_vblank_off for atomic
modesetting in nouveau_display_fini. I think Ben's working on it.
On Wed, Jul 19, 2017 at 1:25 PM, Tobias Klausmann
wrote:
> mimic the behavior of vblank_disable_fn(), another caller of
> drm_vblank_disable_and_save().
>
> This