All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mario Kleiner <mario.kleiner.de@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Ben Skeggs <bskeggs@redhat.com>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH 1/3] drm/nouveau: Use drm_vblank_on/off consistently
Date: Fri, 29 May 2015 19:23:35 +0200	[thread overview]
Message-ID: <5568A097.7020904@gmail.com> (raw)
In-Reply-To: <20150529171921.GT8341@phenom.ffwll.local>



On 05/29/2015 07:19 PM, Daniel Vetter wrote:
> On Fri, May 29, 2015 at 06:50:06PM +0200, Mario Kleiner wrote:
>> On 05/27/2015 11:04 AM, Daniel Vetter wrote:
>>> In
>>>
>>> commit 9cba5efab5a8145ae6c52ea273553f069c294482
>>> Author: Mario Kleiner <mario.kleiner.de@gmail.com>
>>> Date:   Tue Jul 29 02:36:44 2014 +0200
>>>
>>>      drm/nouveau: Dis/Enable vblank irqs during suspend/resume
>>>
>>> drm_vblank_on/off calls where added around suspend/resume to make sure
>>> vblank stay doesn't go boom over that transition. But nouveau already
>>> used drm_vblank_pre/post_modeset over modesets. Instead use
>>> drm_vblank_on/off everyhwere. The slight change here is that after
>>> _off drm_vblank_get will refuse to work right away, but nouveau
>>> doesn't seem to depend upon that anywhere outside of the pageflip
>>> paths.
>>>
>>> The longer-term plan here is to switch all kms drivers to
>>> drm_vblank_on/off so that common code like pending event cleanup can
>>> be done there, while drm_vblank_pre/post_modeset will be purely
>>> drm internal for the old UMS ioctl.
>>>
>>> Note that the drm_vblank_off still seems required in the suspend path
>>> since nouveau doesn't explicitly disable crtcs. But on the resume side
>>> drm_helper_resume_force_mode should end up calling drm_vblank_on
>>> through the nouveau crtc hooks already. Hence remove the call in the
>>> resume code.
>>>
>>> Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
>>> Cc: Ben Skeggs <bskeggs@redhat.com>
>>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>>> ---
>>>   drivers/gpu/drm/nouveau/dispnv04/crtc.c   | 4 ++--
>>>   drivers/gpu/drm/nouveau/nouveau_display.c | 4 ----
>>>   2 files changed, 2 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
>>> index 3d96b49fe662..dab24066fa21 100644
>>> --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
>>> +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
>>> @@ -708,7 +708,7 @@ static void nv_crtc_prepare(struct drm_crtc *crtc)
>>>   	if (nv_two_heads(dev))
>>>   		NVSetOwner(dev, nv_crtc->index);
>>>
>>> -	drm_vblank_pre_modeset(dev, nv_crtc->index);
>>> +	drm_vblank_off(dev, nv_crtc->index);
>>>   	funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
>>>
>>>   	NVBlankScreen(dev, nv_crtc->index, true);
>>> @@ -740,7 +740,7 @@ static void nv_crtc_commit(struct drm_crtc *crtc)
>>>   #endif
>>>
>>>   	funcs->dpms(crtc, DRM_MODE_DPMS_ON);
>>> -	drm_vblank_post_modeset(dev, nv_crtc->index);
>>> +	drm_vblank_on(dev, nv_crtc->index);
>>>   }
>>
>> The above hunk is probably correct, but i couldn't test it without
>> sufficiently old pre-nv 50 hardware.
>>
>>>
>>>   static void nv_crtc_destroy(struct drm_crtc *crtc)
>>> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c
>>> index 8670d90cdc11..d824023f9fc6 100644
>>> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
>>> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
>>> @@ -620,10 +620,6 @@ nouveau_display_resume(struct drm_device *dev, bool runtime)
>>>   		nv_crtc->lut.depth = 0;
>>>   	}
>>>
>>> -	/* Make sure that drm and hw vblank irqs get resumed if needed. */
>>> -	for (head = 0; head < dev->mode_config.num_crtc; head++)
>>> -		drm_vblank_on(dev, head);
>>> -
>>>   	/* This should ensure we don't hit a locking problem when someone
>>>   	 * wakes us up via a connector.  We should never go into suspend
>>>   	 * while the display is on anyways.
>>>
>>
>> Tested this one and this hunk breaks suspend/resume. After a suspend/resume
>> cycle, all OpenGL apps and composited desktop are dead, as the core can't
>> get any vblank irq's enabled anymore.
>>
>> So the drm_vblank_on() is still needed here.
>
> Hm that's very surprising. As mentioned above the force_mode_restore
> should be calling nv_crtc_prepare already and fix this all up for us. I
> guess I need to dig out my nv card and trace what's really going on here.
>
> Enabling interrupts when the crtc is off isn't a good idea.
> -Daniel
>

I think the nv_crtc_prepare() path modified in your first hunk is only 
for the original nv04 display engine for very old cards. nv50+ 
(GeForce-8 and later) take different paths.

-mario
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-05-29 17:23 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-27  9:04 [PATCH 1/3] drm/nouveau: Use drm_vblank_on/off consistently Daniel Vetter
2015-05-27  9:04 ` [PATCH 2/3] drm/radeon: Switch to drm_vblank_on/off Daniel Vetter
2015-05-27  9:21   ` Michel Dänzer
2015-05-27  9:41     ` Daniel Vetter
2015-05-28  7:11       ` Michel Dänzer
2015-05-28  8:38         ` Daniel Vetter
2015-05-28  9:03           ` Michel Dänzer
2015-07-14  8:13             ` Michel Dänzer
2015-08-07  7:26               ` Michel Dänzer
2015-08-07  7:52                 ` Daniel Vetter
2015-05-27  9:04 ` [PATCH 3/3] drm/irq: Make drm_vblank_pre/post_modeset internal Daniel Vetter
2015-05-29 16:50 ` [PATCH 1/3] drm/nouveau: Use drm_vblank_on/off consistently Mario Kleiner
2015-05-29 17:19   ` Daniel Vetter
2015-05-29 17:23     ` Mario Kleiner [this message]
2015-05-29 17:35       ` Daniel Vetter
2015-06-05 19:40         ` Mario Kleiner
2015-06-15  6:07 ` [PATCH] " Daniel Vetter
2015-06-17  0:01   ` Mario Kleiner
  -- strict thread matches above, loose matches on Subject: below --
2016-01-21 10:08 [PATCH 1/3] " Daniel Vetter
2016-01-22  2:14 ` Michel Dänzer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5568A097.7020904@gmail.com \
    --to=mario.kleiner.de@gmail.com \
    --cc=bskeggs@redhat.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.