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); }
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.
These should be functionally equivalent to the older per/post modeset functions, except that they block out drm_vblank_get right away. There's only the clock adjusting code (outside of pageflips) in readone which uses drm_vblank_get. But that code doesn't synchronize against concurrent modesets and instead handles any such races by waiting for the right vblank to arrive with a short timetout.
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 kerneldoc for pre/post_modeset is wrong since as Michel Dänzer correctly pointed out it works if only using pre/post_modeset. The trouble that lead to this comment is the very old version of drm_vblank_off to clear out pending events when disabling a pipe, which did seem to wreak havoc with the trick used by pre/post_modeset. Michel also expressed dissatisfaction with intel folks pushing new interfaces with bogus justifications. I still maintain that having a consistent set of vblank behaviour across kms drivers, separate from any old UMS functions is a useful goal.
Cc: Michel Dänzer michel.daenzer@amd.com Signed-off-by: Daniel Vetter daniel.vetter@intel.com --- drivers/gpu/drm/radeon/atombios_crtc.c | 4 ++-- drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c index 42b2ea3fdcf3..77912fd48b69 100644 --- a/drivers/gpu/drm/radeon/atombios_crtc.c +++ b/drivers/gpu/drm/radeon/atombios_crtc.c @@ -274,13 +274,13 @@ void atombios_crtc_dpms(struct drm_crtc *crtc, int mode) if (ASIC_IS_DCE3(rdev) && !ASIC_IS_DCE6(rdev)) atombios_enable_crtc_memreq(crtc, ATOM_ENABLE); atombios_blank_crtc(crtc, ATOM_DISABLE); - drm_vblank_post_modeset(dev, radeon_crtc->crtc_id); + drm_vblank_on(dev, radeon_crtc->crtc_id); radeon_crtc_load_lut(crtc); break; case DRM_MODE_DPMS_STANDBY: case DRM_MODE_DPMS_SUSPEND: case DRM_MODE_DPMS_OFF: - drm_vblank_pre_modeset(dev, radeon_crtc->crtc_id); + drm_vblank_off(dev, radeon_crtc->crtc_id); if (radeon_crtc->enabled) atombios_blank_crtc(crtc, ATOM_ENABLE); if (ASIC_IS_DCE3(rdev) && !ASIC_IS_DCE6(rdev)) diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c index 678b4386540d..4259e27f3983 100644 --- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c +++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c @@ -330,13 +330,13 @@ static void radeon_crtc_dpms(struct drm_crtc *crtc, int mode) RADEON_CRTC_DISP_REQ_EN_B)); WREG32_P(RADEON_CRTC_EXT_CNTL, crtc_ext_cntl, ~(mask | crtc_ext_cntl)); } - drm_vblank_post_modeset(dev, radeon_crtc->crtc_id); + drm_vblank_on(dev, radeon_crtc->crtc_id); radeon_crtc_load_lut(crtc); break; case DRM_MODE_DPMS_STANDBY: case DRM_MODE_DPMS_SUSPEND: case DRM_MODE_DPMS_OFF: - drm_vblank_pre_modeset(dev, radeon_crtc->crtc_id); + drm_vblank_off(dev, radeon_crtc->crtc_id); if (radeon_crtc->crtc_id) WREG32_P(RADEON_CRTC2_GEN_CNTL, mask, ~(RADEON_CRTC2_EN | mask)); else {
On 27.05.2015 18:04, Daniel Vetter wrote:
These should be functionally equivalent to the older per/post modeset functions, except that they block out drm_vblank_get right away. There's only the clock adjusting code (outside of pageflips) in readone which uses drm_vblank_get. But that code doesn't synchronize against concurrent modesets and instead handles any such races by waiting for the right vblank to arrive with a short timetout.
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 kerneldoc for pre/post_modeset is wrong since as Michel Dänzer correctly pointed out it works if only using pre/post_modeset. The trouble that lead to this comment is the very old version of drm_vblank_off to clear out pending events when disabling a pipe, which did seem to wreak havoc with the trick used by pre/post_modeset. Michel also expressed dissatisfaction with intel folks pushing new interfaces with bogus justifications. I still maintain that having a consistent set of vblank behaviour across kms drivers, separate from any old UMS functions is a useful goal.
Cc: Michel Dänzer michel.daenzer@amd.com Signed-off-by: Daniel Vetter daniel.vetter@intel.com
Can you describe at least one tangible benefit this change provides for the radeon driver?
Because I'm afraid that this might cause subtle breakage, and since we don't have any rigorous tests for this like in intel-gpu-tools (yet?), it might be painful to track it down.
So, I'd like to have a good reason for taking the risk.
drivers/gpu/drm/radeon/atombios_crtc.c | 4 ++-- drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c index 42b2ea3fdcf3..77912fd48b69 100644 --- a/drivers/gpu/drm/radeon/atombios_crtc.c +++ b/drivers/gpu/drm/radeon/atombios_crtc.c @@ -274,13 +274,13 @@ void atombios_crtc_dpms(struct drm_crtc *crtc, int mode) if (ASIC_IS_DCE3(rdev) && !ASIC_IS_DCE6(rdev)) atombios_enable_crtc_memreq(crtc, ATOM_ENABLE); atombios_blank_crtc(crtc, ATOM_DISABLE);
drm_vblank_post_modeset(dev, radeon_crtc->crtc_id);
radeon_crtc_load_lut(crtc); break; case DRM_MODE_DPMS_STANDBY: case DRM_MODE_DPMS_SUSPEND: case DRM_MODE_DPMS_OFF:drm_vblank_on(dev, radeon_crtc->crtc_id);
drm_vblank_pre_modeset(dev, radeon_crtc->crtc_id);
if (radeon_crtc->enabled) atombios_blank_crtc(crtc, ATOM_ENABLE); if (ASIC_IS_DCE3(rdev) && !ASIC_IS_DCE6(rdev))drm_vblank_off(dev, radeon_crtc->crtc_id);
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c index 678b4386540d..4259e27f3983 100644 --- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c +++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c @@ -330,13 +330,13 @@ static void radeon_crtc_dpms(struct drm_crtc *crtc, int mode) RADEON_CRTC_DISP_REQ_EN_B)); WREG32_P(RADEON_CRTC_EXT_CNTL, crtc_ext_cntl, ~(mask | crtc_ext_cntl)); }
drm_vblank_post_modeset(dev, radeon_crtc->crtc_id);
radeon_crtc_load_lut(crtc); break; case DRM_MODE_DPMS_STANDBY: case DRM_MODE_DPMS_SUSPEND: case DRM_MODE_DPMS_OFF:drm_vblank_on(dev, radeon_crtc->crtc_id);
drm_vblank_pre_modeset(dev, radeon_crtc->crtc_id);
if (radeon_crtc->crtc_id) WREG32_P(RADEON_CRTC2_GEN_CNTL, mask, ~(RADEON_CRTC2_EN | mask)); else {drm_vblank_off(dev, radeon_crtc->crtc_id);
On Wed, May 27, 2015 at 06:21:24PM +0900, Michel Dänzer wrote:
On 27.05.2015 18:04, Daniel Vetter wrote:
These should be functionally equivalent to the older per/post modeset functions, except that they block out drm_vblank_get right away. There's only the clock adjusting code (outside of pageflips) in readone which uses drm_vblank_get. But that code doesn't synchronize against concurrent modesets and instead handles any such races by waiting for the right vblank to arrive with a short timetout.
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 kerneldoc for pre/post_modeset is wrong since as Michel Dänzer correctly pointed out it works if only using pre/post_modeset. The trouble that lead to this comment is the very old version of drm_vblank_off to clear out pending events when disabling a pipe, which did seem to wreak havoc with the trick used by pre/post_modeset. Michel also expressed dissatisfaction with intel folks pushing new interfaces with bogus justifications. I still maintain that having a consistent set of vblank behaviour across kms drivers, separate from any old UMS functions is a useful goal.
Cc: Michel Dänzer michel.daenzer@amd.com Signed-off-by: Daniel Vetter daniel.vetter@intel.com
Can you describe at least one tangible benefit this change provides for the radeon driver?
Because I'm afraid that this might cause subtle breakage, and since we don't have any rigorous tests for this like in intel-gpu-tools (yet?), it might be painful to track it down.
So, I'd like to have a good reason for taking the risk.
right now at most a bit of code to clean out pending events on modeset disable, for somewhat consistent behaviour with other drivers. But in general it's fairly ill-defined what happens with vblank events.
Longer-term Rob&I have a pile of patches and refactorings for drm_irq.c planned so that drivers don't need to open-code all the event handling and cleanup code (for both vblank and pageflips) and maybe also some infrastructure for vblank callbacks (which also a lot of drivers hand-roll). But drm_irq.c has the trouble of being used by both kms and ums drivers, and I don't want to change any of the ums code too much. Hence first step (which has been ongoing for a while now) is trying to create a clean split between functions/features used by kms drivers and those used by the ums ioctls.
Anyway that's just my overall plan, there's not going to be a problem if you decide not to apply these patches. I just want to make sure that any such drm core refactoring projects aren't seen as intel-only, hence I send around these patches. And ofc I'd be nice to know if this does unintentionally break something, to make sure the new stuff is as widely suitable as possible. But in the end it's your call. -Daniel
drivers/gpu/drm/radeon/atombios_crtc.c | 4 ++-- drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c index 42b2ea3fdcf3..77912fd48b69 100644 --- a/drivers/gpu/drm/radeon/atombios_crtc.c +++ b/drivers/gpu/drm/radeon/atombios_crtc.c @@ -274,13 +274,13 @@ void atombios_crtc_dpms(struct drm_crtc *crtc, int mode) if (ASIC_IS_DCE3(rdev) && !ASIC_IS_DCE6(rdev)) atombios_enable_crtc_memreq(crtc, ATOM_ENABLE); atombios_blank_crtc(crtc, ATOM_DISABLE);
drm_vblank_post_modeset(dev, radeon_crtc->crtc_id);
radeon_crtc_load_lut(crtc); break; case DRM_MODE_DPMS_STANDBY: case DRM_MODE_DPMS_SUSPEND: case DRM_MODE_DPMS_OFF:drm_vblank_on(dev, radeon_crtc->crtc_id);
drm_vblank_pre_modeset(dev, radeon_crtc->crtc_id);
if (radeon_crtc->enabled) atombios_blank_crtc(crtc, ATOM_ENABLE); if (ASIC_IS_DCE3(rdev) && !ASIC_IS_DCE6(rdev))drm_vblank_off(dev, radeon_crtc->crtc_id);
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c index 678b4386540d..4259e27f3983 100644 --- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c +++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c @@ -330,13 +330,13 @@ static void radeon_crtc_dpms(struct drm_crtc *crtc, int mode) RADEON_CRTC_DISP_REQ_EN_B)); WREG32_P(RADEON_CRTC_EXT_CNTL, crtc_ext_cntl, ~(mask | crtc_ext_cntl)); }
drm_vblank_post_modeset(dev, radeon_crtc->crtc_id);
radeon_crtc_load_lut(crtc); break; case DRM_MODE_DPMS_STANDBY: case DRM_MODE_DPMS_SUSPEND: case DRM_MODE_DPMS_OFF:drm_vblank_on(dev, radeon_crtc->crtc_id);
drm_vblank_pre_modeset(dev, radeon_crtc->crtc_id);
if (radeon_crtc->crtc_id) WREG32_P(RADEON_CRTC2_GEN_CNTL, mask, ~(RADEON_CRTC2_EN | mask)); else {drm_vblank_off(dev, radeon_crtc->crtc_id);
-- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
On 27.05.2015 18:41, Daniel Vetter wrote:
On Wed, May 27, 2015 at 06:21:24PM +0900, Michel Dänzer wrote:
On 27.05.2015 18:04, Daniel Vetter wrote:
These should be functionally equivalent to the older per/post modeset functions, except that they block out drm_vblank_get right away. There's only the clock adjusting code (outside of pageflips) in readone which uses drm_vblank_get. But that code doesn't synchronize against concurrent modesets and instead handles any such races by waiting for the right vblank to arrive with a short timetout.
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 kerneldoc for pre/post_modeset is wrong since as Michel Dänzer correctly pointed out it works if only using pre/post_modeset. The trouble that lead to this comment is the very old version of drm_vblank_off to clear out pending events when disabling a pipe, which did seem to wreak havoc with the trick used by pre/post_modeset. Michel also expressed dissatisfaction with intel folks pushing new interfaces with bogus justifications. I still maintain that having a consistent set of vblank behaviour across kms drivers, separate from any old UMS functions is a useful goal.
Cc: Michel Dänzer michel.daenzer@amd.com Signed-off-by: Daniel Vetter daniel.vetter@intel.com
Can you describe at least one tangible benefit this change provides for the radeon driver?
Because I'm afraid that this might cause subtle breakage, and since we don't have any rigorous tests for this like in intel-gpu-tools (yet?), it might be painful to track it down.
So, I'd like to have a good reason for taking the risk.
right now at most a bit of code to clean out pending events on modeset disable, for somewhat consistent behaviour with other drivers. But in general it's fairly ill-defined what happens with vblank events.
Yeah, while that's nice to have, I don't think it makes too much difference in practice.
Anyway, I'm giving this patch a spin, and it does indeed cause userspace fallout, at least with DRI3/Present enabled, because the vblank and pageflip ioctls now return -EINVAL while the CRTC is off. However, it looks like fixing that up might not be too bad, so I'm cautiously optimistic for this change. But I'd like some more time for testing and fixing userspace.
On Thu, May 28, 2015 at 04:11:53PM +0900, Michel Dänzer wrote:
On 27.05.2015 18:41, Daniel Vetter wrote:
On Wed, May 27, 2015 at 06:21:24PM +0900, Michel Dänzer wrote:
On 27.05.2015 18:04, Daniel Vetter wrote:
These should be functionally equivalent to the older per/post modeset functions, except that they block out drm_vblank_get right away. There's only the clock adjusting code (outside of pageflips) in readone which uses drm_vblank_get. But that code doesn't synchronize against concurrent modesets and instead handles any such races by waiting for the right vblank to arrive with a short timetout.
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 kerneldoc for pre/post_modeset is wrong since as Michel Dänzer correctly pointed out it works if only using pre/post_modeset. The trouble that lead to this comment is the very old version of drm_vblank_off to clear out pending events when disabling a pipe, which did seem to wreak havoc with the trick used by pre/post_modeset. Michel also expressed dissatisfaction with intel folks pushing new interfaces with bogus justifications. I still maintain that having a consistent set of vblank behaviour across kms drivers, separate from any old UMS functions is a useful goal.
Cc: Michel Dänzer michel.daenzer@amd.com Signed-off-by: Daniel Vetter daniel.vetter@intel.com
Can you describe at least one tangible benefit this change provides for the radeon driver?
Because I'm afraid that this might cause subtle breakage, and since we don't have any rigorous tests for this like in intel-gpu-tools (yet?), it might be painful to track it down.
So, I'd like to have a good reason for taking the risk.
right now at most a bit of code to clean out pending events on modeset disable, for somewhat consistent behaviour with other drivers. But in general it's fairly ill-defined what happens with vblank events.
Yeah, while that's nice to have, I don't think it makes too much difference in practice.
Anyway, I'm giving this patch a spin, and it does indeed cause userspace fallout, at least with DRI3/Present enabled, because the vblank and pageflip ioctls now return -EINVAL while the CRTC is off. However, it looks like fixing that up might not be too bad, so I'm cautiously optimistic for this change. But I'd like some more time for testing and fixing userspace.
Hm that's a bummer, since it means the abi userspace sees has already diverged between drivers :(
And because drm_irq.c is still a giant mess with no clear drm core -> driver interface there's also no way for drivers to overwrite the normal behaviour to keep old, driver-specific userspace happy. Adding such a hook for kms drivers is definitely something I want to do. With all the modeset entry points and atomic helpers you can do that and so keep old userspace working even if the more strict semantics of atomic would break it (which was an important goal with all the super-flexible helper library).
Otoh asking for a vblank event on a dead pipe smells like a userspace bug and could result in stuck compositors. Not sure what's best here really. -Daniel
On 28.05.2015 17:38, Daniel Vetter wrote:
On Thu, May 28, 2015 at 04:11:53PM +0900, Michel Dänzer wrote:
On 27.05.2015 18:41, Daniel Vetter wrote:
On Wed, May 27, 2015 at 06:21:24PM +0900, Michel Dänzer wrote:
On 27.05.2015 18:04, Daniel Vetter wrote:
These should be functionally equivalent to the older per/post modeset functions, except that they block out drm_vblank_get right away. There's only the clock adjusting code (outside of pageflips) in readone which uses drm_vblank_get. But that code doesn't synchronize against concurrent modesets and instead handles any such races by waiting for the right vblank to arrive with a short timetout.
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 kerneldoc for pre/post_modeset is wrong since as Michel Dänzer correctly pointed out it works if only using pre/post_modeset. The trouble that lead to this comment is the very old version of drm_vblank_off to clear out pending events when disabling a pipe, which did seem to wreak havoc with the trick used by pre/post_modeset. Michel also expressed dissatisfaction with intel folks pushing new interfaces with bogus justifications. I still maintain that having a consistent set of vblank behaviour across kms drivers, separate from any old UMS functions is a useful goal.
Cc: Michel Dänzer michel.daenzer@amd.com Signed-off-by: Daniel Vetter daniel.vetter@intel.com
Can you describe at least one tangible benefit this change provides for the radeon driver?
Because I'm afraid that this might cause subtle breakage, and since we don't have any rigorous tests for this like in intel-gpu-tools (yet?), it might be painful to track it down.
So, I'd like to have a good reason for taking the risk.
right now at most a bit of code to clean out pending events on modeset disable, for somewhat consistent behaviour with other drivers. But in general it's fairly ill-defined what happens with vblank events.
Yeah, while that's nice to have, I don't think it makes too much difference in practice.
Anyway, I'm giving this patch a spin, and it does indeed cause userspace fallout, at least with DRI3/Present enabled, because the vblank and pageflip ioctls now return -EINVAL while the CRTC is off. However, it looks like fixing that up might not be too bad, so I'm cautiously optimistic for this change. But I'd like some more time for testing and fixing userspace.
[...]
Otoh asking for a vblank event on a dead pipe smells like a userspace bug and could result in stuck compositors. Not sure what's best here really.
Agreed, and we're already careful not to do that with DRI2, just not yet with DRI3/Present (which isn't in any xf86-video-ati release yet).
On 28.05.2015 18:03, Michel Dänzer wrote:
On 28.05.2015 17:38, Daniel Vetter wrote:
On Thu, May 28, 2015 at 04:11:53PM +0900, Michel Dänzer wrote:
On 27.05.2015 18:41, Daniel Vetter wrote:
On Wed, May 27, 2015 at 06:21:24PM +0900, Michel Dänzer wrote:
On 27.05.2015 18:04, Daniel Vetter wrote:
These should be functionally equivalent to the older per/post modeset functions, except that they block out drm_vblank_get right away. There's only the clock adjusting code (outside of pageflips) in readone which uses drm_vblank_get. But that code doesn't synchronize against concurrent modesets and instead handles any such races by waiting for the right vblank to arrive with a short timetout.
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 kerneldoc for pre/post_modeset is wrong since as Michel Dänzer correctly pointed out it works if only using pre/post_modeset. The trouble that lead to this comment is the very old version of drm_vblank_off to clear out pending events when disabling a pipe, which did seem to wreak havoc with the trick used by pre/post_modeset. Michel also expressed dissatisfaction with intel folks pushing new interfaces with bogus justifications. I still maintain that having a consistent set of vblank behaviour across kms drivers, separate from any old UMS functions is a useful goal.
Cc: Michel Dänzer michel.daenzer@amd.com Signed-off-by: Daniel Vetter daniel.vetter@intel.com
Can you describe at least one tangible benefit this change provides for the radeon driver?
Because I'm afraid that this might cause subtle breakage, and since we don't have any rigorous tests for this like in intel-gpu-tools (yet?), it might be painful to track it down.
So, I'd like to have a good reason for taking the risk.
right now at most a bit of code to clean out pending events on modeset disable, for somewhat consistent behaviour with other drivers. But in general it's fairly ill-defined what happens with vblank events.
Yeah, while that's nice to have, I don't think it makes too much difference in practice.
Anyway, I'm giving this patch a spin, and it does indeed cause userspace fallout, at least with DRI3/Present enabled, because the vblank and pageflip ioctls now return -EINVAL while the CRTC is off. However, it looks like fixing that up might not be too bad, so I'm cautiously optimistic for this change. But I'd like some more time for testing and fixing userspace.
[...]
Otoh asking for a vblank event on a dead pipe smells like a userspace bug and could result in stuck compositors. Not sure what's best here really.
Agreed, and we're already careful not to do that with DRI2, just not yet with DRI3/Present (which isn't in any xf86-video-ati release yet).
I've fixed up the DRI3/Present code as well. This patch (with maybe some cleanups to the commit log, in particular I'm not sure the third paragraph should be there) is
Acked-and-Tested-by: Michel Dänzer michel.daenzer@amd.com
On 14.07.2015 17:13, Michel Dänzer wrote:
On 28.05.2015 18:03, Michel Dänzer wrote:
On 28.05.2015 17:38, Daniel Vetter wrote:
On Thu, May 28, 2015 at 04:11:53PM +0900, Michel Dänzer wrote:
On 27.05.2015 18:41, Daniel Vetter wrote:
On Wed, May 27, 2015 at 06:21:24PM +0900, Michel Dänzer wrote:
On 27.05.2015 18:04, Daniel Vetter wrote: > These should be functionally equivalent to the older per/post modeset > functions, except that they block out drm_vblank_get right away. > There's only the clock adjusting code (outside of pageflips) in > readone which uses drm_vblank_get. But that code doesn't synchronize > against concurrent modesets and instead handles any such races by > waiting for the right vblank to arrive with a short timetout. > > 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 kerneldoc for pre/post_modeset is wrong since as Michel > Dänzer correctly pointed out it works if only using pre/post_modeset. > The trouble that lead to this comment is the very old version of > drm_vblank_off to clear out pending events when disabling a pipe, > which did seem to wreak havoc with the trick used by pre/post_modeset. > Michel also expressed dissatisfaction with intel folks pushing new > interfaces with bogus justifications. I still maintain that having a > consistent set of vblank behaviour across kms drivers, separate from > any old UMS functions is a useful goal. > > Cc: Michel Dänzer michel.daenzer@amd.com > Signed-off-by: Daniel Vetter daniel.vetter@intel.com
Can you describe at least one tangible benefit this change provides for the radeon driver?
Because I'm afraid that this might cause subtle breakage, and since we don't have any rigorous tests for this like in intel-gpu-tools (yet?), it might be painful to track it down.
So, I'd like to have a good reason for taking the risk.
right now at most a bit of code to clean out pending events on modeset disable, for somewhat consistent behaviour with other drivers. But in general it's fairly ill-defined what happens with vblank events.
Yeah, while that's nice to have, I don't think it makes too much difference in practice.
Anyway, I'm giving this patch a spin, and it does indeed cause userspace fallout, at least with DRI3/Present enabled, because the vblank and pageflip ioctls now return -EINVAL while the CRTC is off. However, it looks like fixing that up might not be too bad, so I'm cautiously optimistic for this change. But I'd like some more time for testing and fixing userspace.
[...]
Otoh asking for a vblank event on a dead pipe smells like a userspace bug and could result in stuck compositors. Not sure what's best here really.
Agreed, and we're already careful not to do that with DRI2, just not yet with DRI3/Present (which isn't in any xf86-video-ati release yet).
I've fixed up the DRI3/Present code as well. This patch (with maybe some cleanups to the commit log, in particular I'm not sure the third paragraph should be there) is
Acked-and-Tested-by: Michel Dänzer michel.daenzer@amd.com
Recently, I'm occasionally (about once a week) getting a hang on DPMS off, see the attached dmesg snippet. I'm having trouble making sense of the backtraces; any opinions on whether this looks like an issue in the driver, DRM core or somewhere else?
On Fri, Aug 07, 2015 at 04:26:59PM +0900, Michel Dänzer wrote:
On 14.07.2015 17:13, Michel Dänzer wrote:
On 28.05.2015 18:03, Michel Dänzer wrote:
On 28.05.2015 17:38, Daniel Vetter wrote:
On Thu, May 28, 2015 at 04:11:53PM +0900, Michel Dänzer wrote:
On 27.05.2015 18:41, Daniel Vetter wrote:
On Wed, May 27, 2015 at 06:21:24PM +0900, Michel Dänzer wrote: > On 27.05.2015 18:04, Daniel Vetter wrote: >> These should be functionally equivalent to the older per/post modeset >> functions, except that they block out drm_vblank_get right away. >> There's only the clock adjusting code (outside of pageflips) in >> readone which uses drm_vblank_get. But that code doesn't synchronize >> against concurrent modesets and instead handles any such races by >> waiting for the right vblank to arrive with a short timetout. >> >> 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 kerneldoc for pre/post_modeset is wrong since as Michel >> Dänzer correctly pointed out it works if only using pre/post_modeset. >> The trouble that lead to this comment is the very old version of >> drm_vblank_off to clear out pending events when disabling a pipe, >> which did seem to wreak havoc with the trick used by pre/post_modeset. >> Michel also expressed dissatisfaction with intel folks pushing new >> interfaces with bogus justifications. I still maintain that having a >> consistent set of vblank behaviour across kms drivers, separate from >> any old UMS functions is a useful goal. >> >> Cc: Michel Dänzer michel.daenzer@amd.com >> Signed-off-by: Daniel Vetter daniel.vetter@intel.com > > Can you describe at least one tangible benefit this change provides for > the radeon driver? > > Because I'm afraid that this might cause subtle breakage, and since we > don't have any rigorous tests for this like in intel-gpu-tools (yet?), > it might be painful to track it down. > > So, I'd like to have a good reason for taking the risk.
right now at most a bit of code to clean out pending events on modeset disable, for somewhat consistent behaviour with other drivers. But in general it's fairly ill-defined what happens with vblank events.
Yeah, while that's nice to have, I don't think it makes too much difference in practice.
Anyway, I'm giving this patch a spin, and it does indeed cause userspace fallout, at least with DRI3/Present enabled, because the vblank and pageflip ioctls now return -EINVAL while the CRTC is off. However, it looks like fixing that up might not be too bad, so I'm cautiously optimistic for this change. But I'd like some more time for testing and fixing userspace.
[...]
Otoh asking for a vblank event on a dead pipe smells like a userspace bug and could result in stuck compositors. Not sure what's best here really.
Agreed, and we're already careful not to do that with DRI2, just not yet with DRI3/Present (which isn't in any xf86-video-ati release yet).
I've fixed up the DRI3/Present code as well. This patch (with maybe some cleanups to the commit log, in particular I'm not sure the third paragraph should be there) is
Acked-and-Tested-by: Michel Dänzer michel.daenzer@amd.com
Recently, I'm occasionally (about once a week) getting a hang on DPMS off, see the attached dmesg snippet. I'm having trouble making sense of the backtraces; any opinions on whether this looks like an issue in the driver, DRM core or somewhere else?
I have no idea since with the limited information (I can't decode to the exact instruction where it's seemingly stuck on) I can't even figure out why it's dead. I did look around for locking inversion or similar things.
Is this with full kernel debugging (lockdep and all that) enabled?
Any yeah exact lines of where it dies might be useful. -Daniel
-- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[363595.550600] INFO: rcu_sched detected stalls on CPUs/tasks: { 3} (detected by 1, t=5252 jiffies, g=3257787, c=3257786, q=418) [363595.550622] Task dump for CPU 3: [363595.550628] Xorg R running task 0 1542 1480 0x0000000c [363595.550638] ffffffffa018f3bd ffff880232ba2160 00014a5f550c77c5 ffff88022ab3f968 [363595.550646] ffffffffa0076337 ffff88022ab3f9f8 000000de33ba0000 ffff8802338f8000 [363595.550652] ffffffffa018f25d ffff88022ab3f9b8 ffffffffa0076dcf 0000000000058af0 [363595.550658] Call Trace: [363595.550743] [<ffffffffa018f3bd>] ? radeon_get_vblank_timestamp_kms+0x3d/0xf30 [radeon] [363595.550777] [<ffffffffa0076337>] ? drm_vblank_count_and_time+0x107/0x140 [drm] [363595.550806] [<ffffffffa018f25d>] ? radeon_get_vblank_counter_kms+0x3d/0x40 [radeon] [363595.550832] [<ffffffffa0076dcf>] ? drm_vblank_cleanup+0x1df/0x330 [drm] [363595.550844] [<ffffffff810b2048>] ? __wake_up+0x48/0x60 [363595.550870] [<ffffffffa0077a40>] ? drm_vblank_off+0xb0/0x1e0 [drm] [363595.550918] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [363595.550950] [<ffffffffa0198a06>] ? atombios_crtc_dpms+0x36/0x1e50 [radeon] [363595.550988] [<ffffffffa0198b7a>] ? atombios_crtc_dpms+0x1aa/0x1e50 [radeon] [363595.551034] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [363595.551082] [<ffffffffa02174ad>] ? atombios_set_edp_panel_power+0xc5d/0xce0 [radeon] [363595.551117] [<ffffffffa0106397>] ? drm_helper_crtc_in_use+0x1b7/0x1f0 [drm_kms_helper] [363595.551138] [<ffffffffa0107156>] ? drm_crtc_helper_set_config+0x116/0xb50 [drm_kms_helper] [363595.551149] [<ffffffff8158f85d>] ? __ww_mutex_lock+0x1d/0xc0 [363595.551191] [<ffffffffa01b51e8>] ? radeon_encoder_is_digital+0x1d8/0xe50 [radeon] [363595.551220] [<ffffffffa0080e36>] ? drm_mode_set_config_internal+0x66/0x100 [drm] [363595.551248] [<ffffffffa00855b9>] ? drm_mode_setcrtc+0x189/0x540 [drm] [363595.551280] [<ffffffffa00758d5>] ? drm_ioctl+0x1a5/0x840 [drm] [363595.551289] [<ffffffff8107ecf6>] ? dequeue_signal+0x36/0x180 [363595.551318] [<ffffffffa018a04c>] ? radeon_drm_ioctl+0x4c/0x5e0 [radeon] [363595.551327] [<ffffffff811e7840>] ? do_vfs_ioctl+0x2e0/0x4e0 [363595.551332] [<ffffffff8107ec0f>] ? recalc_sigpending+0x1f/0x60 [363595.551338] [<ffffffff8107f6b2>] ? __set_task_blocked+0x32/0x80 [363595.551347] [<ffffffff81474645>] ? __sys_recvmsg+0x65/0x80 [363595.551353] [<ffffffff811e7ac1>] ? SyS_ioctl+0x81/0xa0 [363595.551361] [<ffffffff810141e2>] ? sys_rt_sigreturn+0xb2/0xc0 [363595.551370] [<ffffffff81591a72>] ? system_call_fastpath+0x16/0x75 [363597.748018] ------------[ cut here ]------------ [363597.748044] WARNING: CPU: 3 PID: 1542 at kernel/watchdog.c:304 watchdog_overflow_callback+0x92/0xc0() [363597.748049] Watchdog detected hard LOCKUP on cpu 3 [363597.748052] Modules linked in: [363597.748057] vhost_net vhost macvtap macvlan dm_snapshot dm_bufio rfcomm xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables bnep btusb btintel btbcm bluetooth uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev media binfmt_misc snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device cpufreq_userspace cpufreq_conservative cpufreq_stats cpufreq_powersave nls_utf8 nls_cp437 vfat fat tpm_infineon rtsx_pci_ms memstick rtsx_pci_sdmmc mmc_core hp_wmi snd_hda_codec_realtek sparse_keymap rfkill snd_hda_codec_generic kvm_amd kvm crct10dif_pclmul [363597.748152] crc32_pclmul crc32c_intel pcspkr ghash_clmulni_intel snd_hda_codec_hdmi psmouse serio_raw efivars ohci_pci edac_mce_amd i2c_piix4 fam15h_power snd_hda_intel k10temp snd_hda_controller edac_core sg r8169 snd_hda_codec xhci_pci snd_hda_core ehci_pci ohci_hcd rtsx_pci snd_hwdep xhci_hcd mfd_core ehci_hcd snd_pcm mii snd_timer snd usbcore soundcore usb_common shpchp battery hp_accel lis3lv02d input_polldev tpm_tis hp_wireless tpm ac evdev acpi_cpufreq processor sch_fq_codel cuse fuse tun loop firewire_sbp2 firewire_core crc_itu_t parport_pc ppdev lp parport efivarfs autofs4 ext4 crc16 mbcache jbd2 dm_crypt dm_mod md_mod sd_mod amdkfd aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd radeon ahci libahci libata i2c_algo_bit ttm drm_kms_helper scsi_mod drm i2c_core thermal [363597.748267] wmi video thermal_sys button [363597.748280] CPU: 3 PID: 1542 Comm: Xorg Not tainted 4.1.3+ #185 [363597.748285] Hardware name: Hewlett-Packard HP EliteBook 725 G2/221D, BIOS M84 Ver. 01.06 01/15/2015 [363597.748290] ffffffff81728cbf ffff88023ed85ab0 ffffffff8158c0dc 0000000000000007 [363597.748298] ffff88023ed85b00 ffff88023ed85af0 ffffffff8107362a 0000000000000000 [363597.748304] ffff880236318000 0000000000000000 ffff88023ed85c40 ffff88023ed85ef8 [363597.748311] Call Trace: [363597.748315] <NMI> [<ffffffff8158c0dc>] dump_stack+0x45/0x57 [363597.748333] [<ffffffff8107362a>] warn_slowpath_common+0x8a/0xc0 [363597.748339] [<ffffffff810736a6>] warn_slowpath_fmt+0x46/0x50 [363597.748348] [<ffffffff81116d32>] watchdog_overflow_callback+0x92/0xc0 [363597.748357] [<ffffffff811560ac>] __perf_event_overflow+0x8c/0x220 [363597.748365] [<ffffffff81156c14>] perf_event_overflow+0x14/0x20 [363597.748373] [<ffffffff8102b766>] x86_pmu_handle_irq+0x116/0x160 [363597.748387] [<ffffffff81029e4b>] perf_event_nmi_handler+0x2b/0x50 [363597.748393] [<ffffffff81017f10>] nmi_handle+0x80/0x120 [363597.748399] [<ffffffff810184b2>] default_do_nmi+0x42/0x110 [363597.748404] [<ffffffff81018608>] do_nmi+0x88/0xd0 [363597.748411] [<ffffffff81593d6f>] end_repeat_nmi+0x1e/0x2e [363597.748444] [<ffffffffa007627c>] ? drm_vblank_count_and_time+0x4c/0x140 [drm] [363597.748470] [<ffffffffa007627c>] ? drm_vblank_count_and_time+0x4c/0x140 [drm] [363597.748496] [<ffffffffa007627c>] ? drm_vblank_count_and_time+0x4c/0x140 [drm] [363597.748500] <<EOE>> [<ffffffffa0077a40>] ? drm_vblank_off+0xb0/0x1e0 [drm] [363597.748577] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [363597.748611] [<ffffffffa0198a06>] atombios_crtc_dpms+0x36/0x1e50 [radeon] [363597.748650] [<ffffffffa0198b7a>] atombios_crtc_dpms+0x1aa/0x1e50 [radeon] [363597.748698] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [363597.748747] [<ffffffffa02174ad>] ? atombios_set_edp_panel_power+0xc5d/0xce0 [radeon] [363597.748784] [<ffffffffa0106397>] drm_helper_crtc_in_use+0x1b7/0x1f0 [drm_kms_helper] [363597.748806] [<ffffffffa0107156>] drm_crtc_helper_set_config+0x116/0xb50 [drm_kms_helper] [363597.748814] [<ffffffff8158f85d>] ? __ww_mutex_lock+0x1d/0xc0 [363597.748858] [<ffffffffa01b51e8>] radeon_encoder_is_digital+0x1d8/0xe50 [radeon] [363597.748888] [<ffffffffa0080e36>] drm_mode_set_config_internal+0x66/0x100 [drm] [363597.748917] [<ffffffffa00855b9>] drm_mode_setcrtc+0x189/0x540 [drm] [363597.748951] [<ffffffffa00758d5>] drm_ioctl+0x1a5/0x840 [drm] [363597.748959] [<ffffffff8107ecf6>] ? dequeue_signal+0x36/0x180 [363597.748989] [<ffffffffa018a04c>] radeon_drm_ioctl+0x4c/0x5e0 [radeon] [363597.748998] [<ffffffff811e7840>] do_vfs_ioctl+0x2e0/0x4e0 [363597.749004] [<ffffffff8107ec0f>] ? recalc_sigpending+0x1f/0x60 [363597.749010] [<ffffffff8107f6b2>] ? __set_task_blocked+0x32/0x80 [363597.749019] [<ffffffff81474645>] ? __sys_recvmsg+0x65/0x80 [363597.749025] [<ffffffff811e7ac1>] SyS_ioctl+0x81/0xa0 [363597.749033] [<ffffffff810141e2>] ? sys_rt_sigreturn+0xb2/0xc0 [363597.749041] [<ffffffff81591a72>] system_call_fastpath+0x16/0x75 [363597.749047] ---[ end trace 7cdbfeead6bdba16 ]--- [363658.627194] INFO: rcu_sched detected stalls on CPUs/tasks: { 3} (detected by 2, t=21007 jiffies, g=3257787, c=3257786, q=1614) [363658.627216] Task dump for CPU 3: [363658.627222] Xorg R running task 0 1542 1480 0x0000000c [363658.627233] ffffffffa018f3bd ffff880232ba2160 00014a5f550c77c5 ffff88022ab3f968 [363658.627241] ffffffffa0076337 ffff88022ab3f9f8 000000de33ba0000 ffff8802338f8000 [363658.627248] ffffffffa018f25d ffff88022ab3f9b8 ffffffffa0076dcf 0000000000058af0 [363658.627255] Call Trace: [363658.627342] [<ffffffffa018f3bd>] ? radeon_get_vblank_timestamp_kms+0x3d/0xf30 [radeon] [363658.627377] [<ffffffffa0076337>] ? drm_vblank_count_and_time+0x107/0x140 [drm] [363658.627409] [<ffffffffa018f25d>] ? radeon_get_vblank_counter_kms+0x3d/0x40 [radeon] [363658.627436] [<ffffffffa0076dcf>] ? drm_vblank_cleanup+0x1df/0x330 [drm] [363658.627450] [<ffffffff810b2048>] ? __wake_up+0x48/0x60 [363658.627477] [<ffffffffa0077a40>] ? drm_vblank_off+0xb0/0x1e0 [drm] [363658.627528] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [363658.627563] [<ffffffffa0198a06>] ? atombios_crtc_dpms+0x36/0x1e50 [radeon] [363658.627603] [<ffffffffa0198b7a>] ? atombios_crtc_dpms+0x1aa/0x1e50 [radeon] [363658.627651] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [363658.627702] [<ffffffffa02174ad>] ? atombios_set_edp_panel_power+0xc5d/0xce0 [radeon] [363658.627738] [<ffffffffa0106397>] ? drm_helper_crtc_in_use+0x1b7/0x1f0 [drm_kms_helper] [363658.627760] [<ffffffffa0107156>] ? drm_crtc_helper_set_config+0x116/0xb50 [drm_kms_helper] [363658.627770] [<ffffffff8158f85d>] ? __ww_mutex_lock+0x1d/0xc0 [363658.627816] [<ffffffffa01b51e8>] ? radeon_encoder_is_digital+0x1d8/0xe50 [radeon] [363658.627846] [<ffffffffa0080e36>] ? drm_mode_set_config_internal+0x66/0x100 [drm] [363658.627876] [<ffffffffa00855b9>] ? drm_mode_setcrtc+0x189/0x540 [drm] [363658.627911] [<ffffffffa00758d5>] ? drm_ioctl+0x1a5/0x840 [drm] [363658.627920] [<ffffffff8107ecf6>] ? dequeue_signal+0x36/0x180 [363658.627951] [<ffffffffa018a04c>] ? radeon_drm_ioctl+0x4c/0x5e0 [radeon] [363658.627961] [<ffffffff811e7840>] ? do_vfs_ioctl+0x2e0/0x4e0 [363658.627967] [<ffffffff8107ec0f>] ? recalc_sigpending+0x1f/0x60 [363658.627973] [<ffffffff8107f6b2>] ? __set_task_blocked+0x32/0x80 [363658.627982] [<ffffffff81474645>] ? __sys_recvmsg+0x65/0x80 [363658.627989] [<ffffffff811e7ac1>] ? SyS_ioctl+0x81/0xa0 [363658.627997] [<ffffffff810141e2>] ? sys_rt_sigreturn+0xb2/0xc0 [363658.628006] [<ffffffff81591a72>] ? system_call_fastpath+0x16/0x75 [363721.703913] INFO: rcu_sched detected stalls on CPUs/tasks: { 3} (detected by 0, t=36762 jiffies, g=3257787, c=3257786, q=2731) [363721.703934] Task dump for CPU 3: [363721.703940] Xorg R running task 0 1542 1480 0x0000000c [363721.703950] ffffffffa018f3bd ffff880232ba2160 00014a5f550c77c5 ffff88022ab3f968 [363721.703958] ffffffffa0076337 ffff88022ab3f9f8 000000de33ba0000 ffff8802338f8000 [363721.703964] ffffffffa018f25d ffff88022ab3f9b8 ffffffffa0076dcf 0000000000058af0 [363721.703971] Call Trace: [363721.704057] [<ffffffffa018f3bd>] ? radeon_get_vblank_timestamp_kms+0x3d/0xf30 [radeon] [363721.704091] [<ffffffffa0076337>] ? drm_vblank_count_and_time+0x107/0x140 [drm] [363721.704120] [<ffffffffa018f25d>] ? radeon_get_vblank_counter_kms+0x3d/0x40 [radeon] [363721.704146] [<ffffffffa0076dcf>] ? drm_vblank_cleanup+0x1df/0x330 [drm] [363721.704158] [<ffffffff810b2048>] ? __wake_up+0x48/0x60 [363721.704184] [<ffffffffa0077a40>] ? drm_vblank_off+0xb0/0x1e0 [drm] [363721.704232] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [363721.704264] [<ffffffffa0198a06>] ? atombios_crtc_dpms+0x36/0x1e50 [radeon] [363721.704301] [<ffffffffa0198b7a>] ? atombios_crtc_dpms+0x1aa/0x1e50 [radeon] [363721.704346] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [363721.704393] [<ffffffffa02174ad>] ? atombios_set_edp_panel_power+0xc5d/0xce0 [radeon] [363721.704428] [<ffffffffa0106397>] ? drm_helper_crtc_in_use+0x1b7/0x1f0 [drm_kms_helper] [363721.704449] [<ffffffffa0107156>] ? drm_crtc_helper_set_config+0x116/0xb50 [drm_kms_helper] [363721.704459] [<ffffffff8158f85d>] ? __ww_mutex_lock+0x1d/0xc0 [363721.704501] [<ffffffffa01b51e8>] ? radeon_encoder_is_digital+0x1d8/0xe50 [radeon] [363721.704531] [<ffffffffa0080e36>] ? drm_mode_set_config_internal+0x66/0x100 [drm] [363721.704559] [<ffffffffa00855b9>] ? drm_mode_setcrtc+0x189/0x540 [drm] [363721.704592] [<ffffffffa00758d5>] ? drm_ioctl+0x1a5/0x840 [drm] [363721.704600] [<ffffffff8107ecf6>] ? dequeue_signal+0x36/0x180 [363721.704629] [<ffffffffa018a04c>] ? radeon_drm_ioctl+0x4c/0x5e0 [radeon] [363721.704638] [<ffffffff811e7840>] ? do_vfs_ioctl+0x2e0/0x4e0 [363721.704643] [<ffffffff8107ec0f>] ? recalc_sigpending+0x1f/0x60 [363721.704649] [<ffffffff8107f6b2>] ? __set_task_blocked+0x32/0x80 [363721.704658] [<ffffffff81474645>] ? __sys_recvmsg+0x65/0x80 [363721.704663] [<ffffffff811e7ac1>] ? SyS_ioctl+0x81/0xa0 [363721.704671] [<ffffffff810141e2>] ? sys_rt_sigreturn+0xb2/0xc0 [363721.704681] [<ffffffff81591a72>] ? system_call_fastpath+0x16/0x75 [363784.780503] INFO: rcu_sched detected stalls on CPUs/tasks: { 3} (detected by 2, t=52517 jiffies, g=3257787, c=3257786, q=3875) [363784.780524] Task dump for CPU 3: [363784.780530] Xorg R running task 0 1542 1480 0x0000000c [363784.780540] ffffffffa018f3bd ffff880232ba2160 00014a5f550c77c5 ffff88022ab3f968 [363784.780548] ffffffffa0076337 ffff88022ab3f9f8 000000de33ba0000 ffff8802338f8000 [363784.780555] ffffffffa018f25d ffff88022ab3f9b8 ffffffffa0076dcf 0000000000058af0 [363784.780562] Call Trace: [363784.780649] [<ffffffffa018f3bd>] ? radeon_get_vblank_timestamp_kms+0x3d/0xf30 [radeon] [363784.780686] [<ffffffffa0076337>] ? drm_vblank_count_and_time+0x107/0x140 [drm] [363784.780717] [<ffffffffa018f25d>] ? radeon_get_vblank_counter_kms+0x3d/0x40 [radeon] [363784.780744] [<ffffffffa0076dcf>] ? drm_vblank_cleanup+0x1df/0x330 [drm] [363784.780757] [<ffffffff810b2048>] ? __wake_up+0x48/0x60 [363784.780785] [<ffffffffa0077a40>] ? drm_vblank_off+0xb0/0x1e0 [drm] [363784.780836] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [363784.780871] [<ffffffffa0198a06>] ? atombios_crtc_dpms+0x36/0x1e50 [radeon] [363784.780911] [<ffffffffa0198b7a>] ? atombios_crtc_dpms+0x1aa/0x1e50 [radeon] [363784.780961] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [363784.781011] [<ffffffffa02174ad>] ? atombios_set_edp_panel_power+0xc5d/0xce0 [radeon] [363784.781047] [<ffffffffa0106397>] ? drm_helper_crtc_in_use+0x1b7/0x1f0 [drm_kms_helper] [363784.781069] [<ffffffffa0107156>] ? drm_crtc_helper_set_config+0x116/0xb50 [drm_kms_helper] [363784.781079] [<ffffffff8158f85d>] ? __ww_mutex_lock+0x1d/0xc0 [363784.781125] [<ffffffffa01b51e8>] ? radeon_encoder_is_digital+0x1d8/0xe50 [radeon] [363784.781155] [<ffffffffa0080e36>] ? drm_mode_set_config_internal+0x66/0x100 [drm] [363784.781184] [<ffffffffa00855b9>] ? drm_mode_setcrtc+0x189/0x540 [drm] [363784.781219] [<ffffffffa00758d5>] ? drm_ioctl+0x1a5/0x840 [drm] [363784.781228] [<ffffffff8107ecf6>] ? dequeue_signal+0x36/0x180 [363784.781260] [<ffffffffa018a04c>] ? radeon_drm_ioctl+0x4c/0x5e0 [radeon] [363784.781269] [<ffffffff811e7840>] ? do_vfs_ioctl+0x2e0/0x4e0 [363784.781275] [<ffffffff8107ec0f>] ? recalc_sigpending+0x1f/0x60 [363784.781282] [<ffffffff8107f6b2>] ? __set_task_blocked+0x32/0x80 [363784.781291] [<ffffffff81474645>] ? __sys_recvmsg+0x65/0x80 [363784.781297] [<ffffffff811e7ac1>] ? SyS_ioctl+0x81/0xa0 [363784.781305] [<ffffffff810141e2>] ? sys_rt_sigreturn+0xb2/0xc0 [363784.781315] [<ffffffff81591a72>] ? system_call_fastpath+0x16/0x75 [363847.857225] INFO: rcu_sched detected stalls on CPUs/tasks: { 3} (detected by 1, t=68272 jiffies, g=3257787, c=3257786, q=5065) [363847.857245] Task dump for CPU 3: [363847.857252] Xorg R running task 0 1542 1480 0x0000000c [363847.857261] ffffffffa018f3bd ffff880232ba2160 00014a5f550c77c5 ffff88022ab3f968 [363847.857269] ffffffffa0076337 ffff88022ab3f9f8 000000de33ba0000 ffff8802338f8000 [363847.857276] ffffffffa018f25d ffff88022ab3f9b8 ffffffffa0076dcf 0000000000058af0 [363847.857282] Call Trace: [363847.857368] [<ffffffffa018f3bd>] ? radeon_get_vblank_timestamp_kms+0x3d/0xf30 [radeon] [363847.857402] [<ffffffffa0076337>] ? drm_vblank_count_and_time+0x107/0x140 [drm] [363847.857431] [<ffffffffa018f25d>] ? radeon_get_vblank_counter_kms+0x3d/0x40 [radeon] [363847.857457] [<ffffffffa0076dcf>] ? drm_vblank_cleanup+0x1df/0x330 [drm] [363847.857470] [<ffffffff810b2048>] ? __wake_up+0x48/0x60 [363847.857496] [<ffffffffa0077a40>] ? drm_vblank_off+0xb0/0x1e0 [drm] [363847.857544] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [363847.857576] [<ffffffffa0198a06>] ? atombios_crtc_dpms+0x36/0x1e50 [radeon] [363847.857614] [<ffffffffa0198b7a>] ? atombios_crtc_dpms+0x1aa/0x1e50 [radeon] [363847.857660] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [363847.857707] [<ffffffffa02174ad>] ? atombios_set_edp_panel_power+0xc5d/0xce0 [radeon] [363847.857742] [<ffffffffa0106397>] ? drm_helper_crtc_in_use+0x1b7/0x1f0 [drm_kms_helper] [363847.857763] [<ffffffffa0107156>] ? drm_crtc_helper_set_config+0x116/0xb50 [drm_kms_helper] [363847.857774] [<ffffffff8158f85d>] ? __ww_mutex_lock+0x1d/0xc0 [363847.857816] [<ffffffffa01b51e8>] ? radeon_encoder_is_digital+0x1d8/0xe50 [radeon] [363847.857845] [<ffffffffa0080e36>] ? drm_mode_set_config_internal+0x66/0x100 [drm] [363847.857873] [<ffffffffa00855b9>] ? drm_mode_setcrtc+0x189/0x540 [drm] [363847.857906] [<ffffffffa00758d5>] ? drm_ioctl+0x1a5/0x840 [drm] [363847.857914] [<ffffffff8107ecf6>] ? dequeue_signal+0x36/0x180 [363847.857944] [<ffffffffa018a04c>] ? radeon_drm_ioctl+0x4c/0x5e0 [radeon] [363847.857952] [<ffffffff811e7840>] ? do_vfs_ioctl+0x2e0/0x4e0 [363847.857958] [<ffffffff8107ec0f>] ? recalc_sigpending+0x1f/0x60 [363847.857963] [<ffffffff8107f6b2>] ? __set_task_blocked+0x32/0x80 [363847.857972] [<ffffffff81474645>] ? __sys_recvmsg+0x65/0x80 [363847.857978] [<ffffffff811e7ac1>] ? SyS_ioctl+0x81/0xa0 [363847.857986] [<ffffffff810141e2>] ? sys_rt_sigreturn+0xb2/0xc0 [363847.857994] [<ffffffff81591a72>] ? system_call_fastpath+0x16/0x75 [363910.933881] INFO: rcu_sched detected stalls on CPUs/tasks: { 3} (detected by 0, t=84027 jiffies, g=3257787, c=3257786, q=6167) [363910.933902] Task dump for CPU 3: [363910.933909] Xorg R running task 0 1542 1480 0x0000000c [363910.933918] ffffffffa018f3bd ffff880232ba2160 00014a5f550c77c5 ffff88022ab3f968 [363910.933926] ffffffffa0076337 ffff88022ab3f9f8 000000de33ba0000 ffff8802338f8000 [363910.933933] ffffffffa018f25d ffff88022ab3f9b8 ffffffffa0076dcf 0000000000058af0 [363910.933939] Call Trace: [363910.934025] [<ffffffffa018f3bd>] ? radeon_get_vblank_timestamp_kms+0x3d/0xf30 [radeon] [363910.934059] [<ffffffffa0076337>] ? drm_vblank_count_and_time+0x107/0x140 [drm] [363910.934088] [<ffffffffa018f25d>] ? radeon_get_vblank_counter_kms+0x3d/0x40 [radeon] [363910.934113] [<ffffffffa0076dcf>] ? drm_vblank_cleanup+0x1df/0x330 [drm] [363910.934125] [<ffffffff810b2048>] ? __wake_up+0x48/0x60 [363910.934151] [<ffffffffa0077a40>] ? drm_vblank_off+0xb0/0x1e0 [drm] [363910.934199] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [363910.934231] [<ffffffffa0198a06>] ? atombios_crtc_dpms+0x36/0x1e50 [radeon] [363910.934267] [<ffffffffa0198b7a>] ? atombios_crtc_dpms+0x1aa/0x1e50 [radeon] [363910.934313] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [363910.934359] [<ffffffffa02174ad>] ? atombios_set_edp_panel_power+0xc5d/0xce0 [radeon] [363910.934394] [<ffffffffa0106397>] ? drm_helper_crtc_in_use+0x1b7/0x1f0 [drm_kms_helper] [363910.934415] [<ffffffffa0107156>] ? drm_crtc_helper_set_config+0x116/0xb50 [drm_kms_helper] [363910.934424] [<ffffffff8158f85d>] ? __ww_mutex_lock+0x1d/0xc0 [363910.934467] [<ffffffffa01b51e8>] ? radeon_encoder_is_digital+0x1d8/0xe50 [radeon] [363910.934495] [<ffffffffa0080e36>] ? drm_mode_set_config_internal+0x66/0x100 [drm] [363910.934523] [<ffffffffa00855b9>] ? drm_mode_setcrtc+0x189/0x540 [drm] [363910.934556] [<ffffffffa00758d5>] ? drm_ioctl+0x1a5/0x840 [drm] [363910.934564] [<ffffffff8107ecf6>] ? dequeue_signal+0x36/0x180 [363910.934593] [<ffffffffa018a04c>] ? radeon_drm_ioctl+0x4c/0x5e0 [radeon] [363910.934602] [<ffffffff811e7840>] ? do_vfs_ioctl+0x2e0/0x4e0 [363910.934607] [<ffffffff8107ec0f>] ? recalc_sigpending+0x1f/0x60 [363910.934612] [<ffffffff8107f6b2>] ? __set_task_blocked+0x32/0x80 [363910.934621] [<ffffffff81474645>] ? __sys_recvmsg+0x65/0x80 [363910.934627] [<ffffffff811e7ac1>] ? SyS_ioctl+0x81/0xa0 [363910.934635] [<ffffffff810141e2>] ? sys_rt_sigreturn+0xb2/0xc0 [363910.934644] [<ffffffff81591a72>] ? system_call_fastpath+0x16/0x75 [363974.010538] INFO: rcu_sched detected stalls on CPUs/tasks: { 3} (detected by 0, t=99782 jiffies, g=3257787, c=3257786, q=7418) [363974.010559] Task dump for CPU 3: [363974.010566] Xorg R running task 0 1542 1480 0x0000000c [363974.010576] ffffffffa018f3bd ffff880232ba2160 00014a5f550c77c5 ffff88022ab3f968 [363974.010584] ffffffffa0076337 ffff88022ab3f9f8 000000de33ba0000 ffff8802338f8000 [363974.010590] ffffffffa018f25d ffff88022ab3f9b8 ffffffffa0076dcf 0000000000058af0 [363974.010596] Call Trace: [363974.010682] [<ffffffffa018f3bd>] ? radeon_get_vblank_timestamp_kms+0x3d/0xf30 [radeon] [363974.010717] [<ffffffffa0076337>] ? drm_vblank_count_and_time+0x107/0x140 [drm] [363974.010746] [<ffffffffa018f25d>] ? radeon_get_vblank_counter_kms+0x3d/0x40 [radeon] [363974.010771] [<ffffffffa0076dcf>] ? drm_vblank_cleanup+0x1df/0x330 [drm] [363974.010784] [<ffffffff810b2048>] ? __wake_up+0x48/0x60 [363974.010810] [<ffffffffa0077a40>] ? drm_vblank_off+0xb0/0x1e0 [drm] [363974.010858] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [363974.010890] [<ffffffffa0198a06>] ? atombios_crtc_dpms+0x36/0x1e50 [radeon] [363974.010927] [<ffffffffa0198b7a>] ? atombios_crtc_dpms+0x1aa/0x1e50 [radeon] [363974.010973] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [363974.011020] [<ffffffffa02174ad>] ? atombios_set_edp_panel_power+0xc5d/0xce0 [radeon] [363974.011055] [<ffffffffa0106397>] ? drm_helper_crtc_in_use+0x1b7/0x1f0 [drm_kms_helper] [363974.011076] [<ffffffffa0107156>] ? drm_crtc_helper_set_config+0x116/0xb50 [drm_kms_helper] [363974.011086] [<ffffffff8158f85d>] ? __ww_mutex_lock+0x1d/0xc0 [363974.011128] [<ffffffffa01b51e8>] ? radeon_encoder_is_digital+0x1d8/0xe50 [radeon] [363974.011157] [<ffffffffa0080e36>] ? drm_mode_set_config_internal+0x66/0x100 [drm] [363974.011185] [<ffffffffa00855b9>] ? drm_mode_setcrtc+0x189/0x540 [drm] [363974.011217] [<ffffffffa00758d5>] ? drm_ioctl+0x1a5/0x840 [drm] [363974.011226] [<ffffffff8107ecf6>] ? dequeue_signal+0x36/0x180 [363974.011254] [<ffffffffa018a04c>] ? radeon_drm_ioctl+0x4c/0x5e0 [radeon] [363974.011263] [<ffffffff811e7840>] ? do_vfs_ioctl+0x2e0/0x4e0 [363974.011268] [<ffffffff8107ec0f>] ? recalc_sigpending+0x1f/0x60 [363974.011274] [<ffffffff8107f6b2>] ? __set_task_blocked+0x32/0x80 [363974.011283] [<ffffffff81474645>] ? __sys_recvmsg+0x65/0x80 [363974.011289] [<ffffffff811e7ac1>] ? SyS_ioctl+0x81/0xa0 [363974.011297] [<ffffffff810141e2>] ? sys_rt_sigreturn+0xb2/0xc0 [363974.011306] [<ffffffff81591a72>] ? system_call_fastpath+0x16/0x75 [364037.087195] INFO: rcu_sched detected stalls on CPUs/tasks: { 3} (detected by 0, t=115537 jiffies, g=3257787, c=3257786, q=8508) [364037.087216] Task dump for CPU 3: [364037.087223] Xorg R running task 0 1542 1480 0x0000000c [364037.087233] ffffffffa018f3bd ffff880232ba2160 00014a5f550c77c5 ffff88022ab3f968 [364037.087240] ffffffffa0076337 ffff88022ab3f9f8 000000de33ba0000 ffff8802338f8000 [364037.087247] ffffffffa018f25d ffff88022ab3f9b8 ffffffffa0076dcf 0000000000058af0 [364037.087253] Call Trace: [364037.087340] [<ffffffffa018f3bd>] ? radeon_get_vblank_timestamp_kms+0x3d/0xf30 [radeon] [364037.087375] [<ffffffffa0076337>] ? drm_vblank_count_and_time+0x107/0x140 [drm] [364037.087404] [<ffffffffa018f25d>] ? radeon_get_vblank_counter_kms+0x3d/0x40 [radeon] [364037.087429] [<ffffffffa0076dcf>] ? drm_vblank_cleanup+0x1df/0x330 [drm] [364037.087441] [<ffffffff810b2048>] ? __wake_up+0x48/0x60 [364037.087467] [<ffffffffa0077a40>] ? drm_vblank_off+0xb0/0x1e0 [drm] [364037.087515] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [364037.087548] [<ffffffffa0198a06>] ? atombios_crtc_dpms+0x36/0x1e50 [radeon] [364037.087585] [<ffffffffa0198b7a>] ? atombios_crtc_dpms+0x1aa/0x1e50 [radeon] [364037.087630] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [364037.087677] [<ffffffffa02174ad>] ? atombios_set_edp_panel_power+0xc5d/0xce0 [radeon] [364037.087712] [<ffffffffa0106397>] ? drm_helper_crtc_in_use+0x1b7/0x1f0 [drm_kms_helper] [364037.087733] [<ffffffffa0107156>] ? drm_crtc_helper_set_config+0x116/0xb50 [drm_kms_helper] [364037.087742] [<ffffffff8158f85d>] ? __ww_mutex_lock+0x1d/0xc0 [364037.087785] [<ffffffffa01b51e8>] ? radeon_encoder_is_digital+0x1d8/0xe50 [radeon] [364037.087814] [<ffffffffa0080e36>] ? drm_mode_set_config_internal+0x66/0x100 [drm] [364037.087842] [<ffffffffa00855b9>] ? drm_mode_setcrtc+0x189/0x540 [drm] [364037.087875] [<ffffffffa00758d5>] ? drm_ioctl+0x1a5/0x840 [drm] [364037.087883] [<ffffffff8107ecf6>] ? dequeue_signal+0x36/0x180 [364037.087912] [<ffffffffa018a04c>] ? radeon_drm_ioctl+0x4c/0x5e0 [radeon] [364037.087920] [<ffffffff811e7840>] ? do_vfs_ioctl+0x2e0/0x4e0 [364037.087926] [<ffffffff8107ec0f>] ? recalc_sigpending+0x1f/0x60 [364037.087931] [<ffffffff8107f6b2>] ? __set_task_blocked+0x32/0x80 [364037.087940] [<ffffffff81474645>] ? __sys_recvmsg+0x65/0x80 [364037.087946] [<ffffffff811e7ac1>] ? SyS_ioctl+0x81/0xa0 [364037.087954] [<ffffffff810141e2>] ? sys_rt_sigreturn+0xb2/0xc0 [364037.087963] [<ffffffff81591a72>] ? system_call_fastpath+0x16/0x75 [364100.163850] INFO: rcu_sched detected stalls on CPUs/tasks: { 3} (detected by 0, t=131292 jiffies, g=3257787, c=3257786, q=9716) [364100.163870] Task dump for CPU 3: [364100.163878] Xorg R running task 0 1542 1480 0x0000000c [364100.163888] ffffffffa018f3bd ffff880232ba2160 00014a5f550c77c5 ffff88022ab3f968 [364100.163895] ffffffffa0076337 ffff88022ab3f9f8 000000de33ba0000 ffff8802338f8000 [364100.163902] ffffffffa018f25d ffff88022ab3f9b8 ffffffffa0076dcf 0000000000058af0 [364100.163908] Call Trace: [364100.163995] [<ffffffffa018f3bd>] ? radeon_get_vblank_timestamp_kms+0x3d/0xf30 [radeon] [364100.164029] [<ffffffffa0076337>] ? drm_vblank_count_and_time+0x107/0x140 [drm] [364100.164059] [<ffffffffa018f25d>] ? radeon_get_vblank_counter_kms+0x3d/0x40 [radeon] [364100.164084] [<ffffffffa0076dcf>] ? drm_vblank_cleanup+0x1df/0x330 [drm] [364100.164096] [<ffffffff810b2048>] ? __wake_up+0x48/0x60 [364100.164122] [<ffffffffa0077a40>] ? drm_vblank_off+0xb0/0x1e0 [drm] [364100.164169] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [364100.164201] [<ffffffffa0198a06>] ? atombios_crtc_dpms+0x36/0x1e50 [radeon] [364100.164238] [<ffffffffa0198b7a>] ? atombios_crtc_dpms+0x1aa/0x1e50 [radeon] [364100.164283] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [364100.164331] [<ffffffffa02174ad>] ? atombios_set_edp_panel_power+0xc5d/0xce0 [radeon] [364100.164366] [<ffffffffa0106397>] ? drm_helper_crtc_in_use+0x1b7/0x1f0 [drm_kms_helper] [364100.164387] [<ffffffffa0107156>] ? drm_crtc_helper_set_config+0x116/0xb50 [drm_kms_helper] [364100.164397] [<ffffffff8158f85d>] ? __ww_mutex_lock+0x1d/0xc0 [364100.164439] [<ffffffffa01b51e8>] ? radeon_encoder_is_digital+0x1d8/0xe50 [radeon] [364100.164468] [<ffffffffa0080e36>] ? drm_mode_set_config_internal+0x66/0x100 [drm] [364100.164496] [<ffffffffa00855b9>] ? drm_mode_setcrtc+0x189/0x540 [drm] [364100.164529] [<ffffffffa00758d5>] ? drm_ioctl+0x1a5/0x840 [drm] [364100.164538] [<ffffffff8107ecf6>] ? dequeue_signal+0x36/0x180 [364100.164566] [<ffffffffa018a04c>] ? radeon_drm_ioctl+0x4c/0x5e0 [radeon] [364100.164575] [<ffffffff811e7840>] ? do_vfs_ioctl+0x2e0/0x4e0 [364100.164580] [<ffffffff8107ec0f>] ? recalc_sigpending+0x1f/0x60 [364100.164586] [<ffffffff8107f6b2>] ? __set_task_blocked+0x32/0x80 [364100.164595] [<ffffffff81474645>] ? __sys_recvmsg+0x65/0x80 [364100.164601] [<ffffffff811e7ac1>] ? SyS_ioctl+0x81/0xa0 [364100.164609] [<ffffffff810141e2>] ? sys_rt_sigreturn+0xb2/0xc0 [364100.164617] [<ffffffff81591a72>] ? system_call_fastpath+0x16/0x75 [364163.240507] INFO: rcu_sched detected stalls on CPUs/tasks: { 3} (detected by 1, t=147047 jiffies, g=3257787, c=3257786, q=10800) [364163.240528] Task dump for CPU 3: [364163.240535] Xorg R running task 0 1542 1480 0x0000000c [364163.240544] ffffffffa018f3bd ffff880232ba2160 00014a5f550c77c5 ffff88022ab3f968 [364163.240552] ffffffffa0076337 ffff88022ab3f9f8 000000de33ba0000 ffff8802338f8000 [364163.240559] ffffffffa018f25d ffff88022ab3f9b8 ffffffffa0076dcf 0000000000058af0 [364163.240565] Call Trace: [364163.240653] [<ffffffffa018f3bd>] ? radeon_get_vblank_timestamp_kms+0x3d/0xf30 [radeon] [364163.240687] [<ffffffffa0076337>] ? drm_vblank_count_and_time+0x107/0x140 [drm] [364163.240716] [<ffffffffa018f25d>] ? radeon_get_vblank_counter_kms+0x3d/0x40 [radeon] [364163.240742] [<ffffffffa0076dcf>] ? drm_vblank_cleanup+0x1df/0x330 [drm] [364163.240754] [<ffffffff810b2048>] ? __wake_up+0x48/0x60 [364163.240780] [<ffffffffa0077a40>] ? drm_vblank_off+0xb0/0x1e0 [drm] [364163.240828] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [364163.240860] [<ffffffffa0198a06>] ? atombios_crtc_dpms+0x36/0x1e50 [radeon] [364163.240898] [<ffffffffa0198b7a>] ? atombios_crtc_dpms+0x1aa/0x1e50 [radeon] [364163.240944] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [364163.240991] [<ffffffffa02174ad>] ? atombios_set_edp_panel_power+0xc5d/0xce0 [radeon] [364163.241026] [<ffffffffa0106397>] ? drm_helper_crtc_in_use+0x1b7/0x1f0 [drm_kms_helper] [364163.241047] [<ffffffffa0107156>] ? drm_crtc_helper_set_config+0x116/0xb50 [drm_kms_helper] [364163.241057] [<ffffffff8158f85d>] ? __ww_mutex_lock+0x1d/0xc0 [364163.241099] [<ffffffffa01b51e8>] ? radeon_encoder_is_digital+0x1d8/0xe50 [radeon] [364163.241128] [<ffffffffa0080e36>] ? drm_mode_set_config_internal+0x66/0x100 [drm] [364163.241157] [<ffffffffa00855b9>] ? drm_mode_setcrtc+0x189/0x540 [drm] [364163.241189] [<ffffffffa00758d5>] ? drm_ioctl+0x1a5/0x840 [drm] [364163.241198] [<ffffffff8107ecf6>] ? dequeue_signal+0x36/0x180 [364163.241227] [<ffffffffa018a04c>] ? radeon_drm_ioctl+0x4c/0x5e0 [radeon] [364163.241235] [<ffffffff811e7840>] ? do_vfs_ioctl+0x2e0/0x4e0 [364163.241241] [<ffffffff8107ec0f>] ? recalc_sigpending+0x1f/0x60 [364163.241246] [<ffffffff8107f6b2>] ? __set_task_blocked+0x32/0x80 [364163.241255] [<ffffffff81474645>] ? __sys_recvmsg+0x65/0x80 [364163.241261] [<ffffffff811e7ac1>] ? SyS_ioctl+0x81/0xa0 [364163.241269] [<ffffffff810141e2>] ? sys_rt_sigreturn+0xb2/0xc0 [364163.241278] [<ffffffff81591a72>] ? system_call_fastpath+0x16/0x75 [364226.317162] INFO: rcu_sched detected stalls on CPUs/tasks: { 3} (detected by 1, t=162802 jiffies, g=3257787, c=3257786, q=11912) [364226.317183] Task dump for CPU 3: [364226.317190] Xorg R running task 0 1542 1480 0x0000000c [364226.317199] ffffffffa018f3bd ffff880232ba2160 00014a5f550c77c5 ffff88022ab3f968 [364226.317207] ffffffffa0076337 ffff88022ab3f9f8 000000de33ba0000 ffff8802338f8000 [364226.317213] ffffffffa018f25d ffff88022ab3f9b8 ffffffffa0076dcf 0000000000058af0 [364226.317220] Call Trace: [364226.317306] [<ffffffffa018f3bd>] ? radeon_get_vblank_timestamp_kms+0x3d/0xf30 [radeon] [364226.317339] [<ffffffffa0076337>] ? drm_vblank_count_and_time+0x107/0x140 [drm] [364226.317368] [<ffffffffa018f25d>] ? radeon_get_vblank_counter_kms+0x3d/0x40 [radeon] [364226.317394] [<ffffffffa0076dcf>] ? drm_vblank_cleanup+0x1df/0x330 [drm] [364226.317406] [<ffffffff810b2048>] ? __wake_up+0x48/0x60 [364226.317432] [<ffffffffa0077a40>] ? drm_vblank_off+0xb0/0x1e0 [drm] [364226.317480] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [364226.317513] [<ffffffffa0198a06>] ? atombios_crtc_dpms+0x36/0x1e50 [radeon] [364226.317549] [<ffffffffa0198b7a>] ? atombios_crtc_dpms+0x1aa/0x1e50 [radeon] [364226.317595] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [364226.317642] [<ffffffffa02174ad>] ? atombios_set_edp_panel_power+0xc5d/0xce0 [radeon] [364226.317677] [<ffffffffa0106397>] ? drm_helper_crtc_in_use+0x1b7/0x1f0 [drm_kms_helper] [364226.317698] [<ffffffffa0107156>] ? drm_crtc_helper_set_config+0x116/0xb50 [drm_kms_helper] [364226.317709] [<ffffffff8158f85d>] ? __ww_mutex_lock+0x1d/0xc0 [364226.317751] [<ffffffffa01b51e8>] ? radeon_encoder_is_digital+0x1d8/0xe50 [radeon] [364226.317780] [<ffffffffa0080e36>] ? drm_mode_set_config_internal+0x66/0x100 [drm] [364226.317808] [<ffffffffa00855b9>] ? drm_mode_setcrtc+0x189/0x540 [drm] [364226.317841] [<ffffffffa00758d5>] ? drm_ioctl+0x1a5/0x840 [drm] [364226.317849] [<ffffffff8107ecf6>] ? dequeue_signal+0x36/0x180 [364226.317879] [<ffffffffa018a04c>] ? radeon_drm_ioctl+0x4c/0x5e0 [radeon] [364226.317887] [<ffffffff811e7840>] ? do_vfs_ioctl+0x2e0/0x4e0 [364226.317892] [<ffffffff8107ec0f>] ? recalc_sigpending+0x1f/0x60 [364226.317898] [<ffffffff8107f6b2>] ? __set_task_blocked+0x32/0x80 [364226.317907] [<ffffffff81474645>] ? __sys_recvmsg+0x65/0x80 [364226.317913] [<ffffffff811e7ac1>] ? SyS_ioctl+0x81/0xa0 [364226.317921] [<ffffffff810141e2>] ? sys_rt_sigreturn+0xb2/0xc0 [364226.317930] [<ffffffff81591a72>] ? system_call_fastpath+0x16/0x75 [364289.393819] INFO: rcu_sched detected stalls on CPUs/tasks: { 3} (detected by 1, t=178557 jiffies, g=3257787, c=3257786, q=15911) [364289.393840] Task dump for CPU 3: [364289.393847] Xorg R running task 0 1542 1480 0x0000000c [364289.393856] ffffffffa018f3bd ffff880232ba2160 00014a5f550c77c5 ffff88022ab3f968 [364289.393864] ffffffffa0076337 ffff88022ab3f9f8 000000de33ba0000 ffff8802338f8000 [364289.393871] ffffffffa018f25d ffff88022ab3f9b8 ffffffffa0076dcf 0000000000058af0 [364289.393877] Call Trace: [364289.393964] [<ffffffffa018f3bd>] ? radeon_get_vblank_timestamp_kms+0x3d/0xf30 [radeon] [364289.393998] [<ffffffffa0076337>] ? drm_vblank_count_and_time+0x107/0x140 [drm] [364289.394028] [<ffffffffa018f25d>] ? radeon_get_vblank_counter_kms+0x3d/0x40 [radeon] [364289.394053] [<ffffffffa0076dcf>] ? drm_vblank_cleanup+0x1df/0x330 [drm] [364289.394066] [<ffffffff810b2048>] ? __wake_up+0x48/0x60 [364289.394093] [<ffffffffa0077a40>] ? drm_vblank_off+0xb0/0x1e0 [drm] [364289.394141] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [364289.394173] [<ffffffffa0198a06>] ? atombios_crtc_dpms+0x36/0x1e50 [radeon] [364289.394210] [<ffffffffa0198b7a>] ? atombios_crtc_dpms+0x1aa/0x1e50 [radeon] [364289.394255] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [364289.394302] [<ffffffffa02174ad>] ? atombios_set_edp_panel_power+0xc5d/0xce0 [radeon] [364289.394337] [<ffffffffa0106397>] ? drm_helper_crtc_in_use+0x1b7/0x1f0 [drm_kms_helper] [364289.394358] [<ffffffffa0107156>] ? drm_crtc_helper_set_config+0x116/0xb50 [drm_kms_helper] [364289.394369] [<ffffffff8158f85d>] ? __ww_mutex_lock+0x1d/0xc0 [364289.394411] [<ffffffffa01b51e8>] ? radeon_encoder_is_digital+0x1d8/0xe50 [radeon] [364289.394441] [<ffffffffa0080e36>] ? drm_mode_set_config_internal+0x66/0x100 [drm] [364289.394469] [<ffffffffa00855b9>] ? drm_mode_setcrtc+0x189/0x540 [drm] [364289.394502] [<ffffffffa00758d5>] ? drm_ioctl+0x1a5/0x840 [drm] [364289.394510] [<ffffffff8107ecf6>] ? dequeue_signal+0x36/0x180 [364289.394539] [<ffffffffa018a04c>] ? radeon_drm_ioctl+0x4c/0x5e0 [radeon] [364289.394548] [<ffffffff811e7840>] ? do_vfs_ioctl+0x2e0/0x4e0 [364289.394554] [<ffffffff8107ec0f>] ? recalc_sigpending+0x1f/0x60 [364289.394560] [<ffffffff8107f6b2>] ? __set_task_blocked+0x32/0x80 [364289.394569] [<ffffffff81474645>] ? __sys_recvmsg+0x65/0x80 [364289.394575] [<ffffffff811e7ac1>] ? SyS_ioctl+0x81/0xa0 [364289.394583] [<ffffffff810141e2>] ? sys_rt_sigreturn+0xb2/0xc0 [364289.394592] [<ffffffff81591a72>] ? system_call_fastpath+0x16/0x75 [364352.470408] INFO: rcu_sched detected stalls on CPUs/tasks: { 3} (detected by 2, t=194312 jiffies, g=3257787, c=3257786, q=17678) [364352.470429] Task dump for CPU 3: [364352.470436] Xorg R running task 0 1542 1480 0x0000000c [364352.470446] ffffffffa018f3bd ffff880232ba2160 00014a5f550c77c5 ffff88022ab3f968 [364352.470455] ffffffffa0076337 ffff88022ab3f9f8 000000de33ba0000 ffff8802338f8000 [364352.470462] ffffffffa018f25d ffff88022ab3f9b8 ffffffffa0076dcf 0000000000058af0 [364352.470469] Call Trace: [364352.470554] [<ffffffffa018f3bd>] ? radeon_get_vblank_timestamp_kms+0x3d/0xf30 [radeon] [364352.470589] [<ffffffffa0076337>] ? drm_vblank_count_and_time+0x107/0x140 [drm] [364352.470621] [<ffffffffa018f25d>] ? radeon_get_vblank_counter_kms+0x3d/0x40 [radeon] [364352.470648] [<ffffffffa0076dcf>] ? drm_vblank_cleanup+0x1df/0x330 [drm] [364352.470662] [<ffffffff810b2048>] ? __wake_up+0x48/0x60 [364352.470689] [<ffffffffa0077a40>] ? drm_vblank_off+0xb0/0x1e0 [drm] [364352.470740] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [364352.470775] [<ffffffffa0198a06>] ? atombios_crtc_dpms+0x36/0x1e50 [radeon] [364352.470815] [<ffffffffa0198b7a>] ? atombios_crtc_dpms+0x1aa/0x1e50 [radeon] [364352.470864] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [364352.470915] [<ffffffffa02174ad>] ? atombios_set_edp_panel_power+0xc5d/0xce0 [radeon] [364352.470951] [<ffffffffa0106397>] ? drm_helper_crtc_in_use+0x1b7/0x1f0 [drm_kms_helper] [364352.470973] [<ffffffffa0107156>] ? drm_crtc_helper_set_config+0x116/0xb50 [drm_kms_helper] [364352.470983] [<ffffffff8158f85d>] ? __ww_mutex_lock+0x1d/0xc0 [364352.471029] [<ffffffffa01b51e8>] ? radeon_encoder_is_digital+0x1d8/0xe50 [radeon] [364352.471060] [<ffffffffa0080e36>] ? drm_mode_set_config_internal+0x66/0x100 [drm] [364352.471089] [<ffffffffa00855b9>] ? drm_mode_setcrtc+0x189/0x540 [drm] [364352.471124] [<ffffffffa00758d5>] ? drm_ioctl+0x1a5/0x840 [drm] [364352.471132] [<ffffffff8107ecf6>] ? dequeue_signal+0x36/0x180 [364352.471164] [<ffffffffa018a04c>] ? radeon_drm_ioctl+0x4c/0x5e0 [radeon] [364352.471174] [<ffffffff811e7840>] ? do_vfs_ioctl+0x2e0/0x4e0 [364352.471180] [<ffffffff8107ec0f>] ? recalc_sigpending+0x1f/0x60 [364352.471186] [<ffffffff8107f6b2>] ? __set_task_blocked+0x32/0x80 [364352.471195] [<ffffffff81474645>] ? __sys_recvmsg+0x65/0x80 [364352.471202] [<ffffffff811e7ac1>] ? SyS_ioctl+0x81/0xa0 [364352.471210] [<ffffffff810141e2>] ? sys_rt_sigreturn+0xb2/0xc0 [364352.471219] [<ffffffff81591a72>] ? system_call_fastpath+0x16/0x75 [364415.547131] INFO: rcu_sched detected stalls on CPUs/tasks: { 3} (detected by 0, t=210067 jiffies, g=3257787, c=3257786, q=18767) [364415.547152] Task dump for CPU 3: [364415.547159] Xorg R running task 0 1542 1480 0x0000000c [364415.547169] ffffffffa018f3bd ffff880232ba2160 00014a5f550c77c5 ffff88022ab3f968 [364415.547177] ffffffffa0076337 ffff88022ab3f9f8 000000de33ba0000 ffff8802338f8000 [364415.547183] ffffffffa018f25d ffff88022ab3f9b8 ffffffffa0076dcf 0000000000058af0 [364415.547189] Call Trace: [364415.547277] [<ffffffffa018f3bd>] ? radeon_get_vblank_timestamp_kms+0x3d/0xf30 [radeon] [364415.547311] [<ffffffffa0076337>] ? drm_vblank_count_and_time+0x107/0x140 [drm] [364415.547341] [<ffffffffa018f25d>] ? radeon_get_vblank_counter_kms+0x3d/0x40 [radeon] [364415.547366] [<ffffffffa0076dcf>] ? drm_vblank_cleanup+0x1df/0x330 [drm] [364415.547378] [<ffffffff810b2048>] ? __wake_up+0x48/0x60 [364415.547404] [<ffffffffa0077a40>] ? drm_vblank_off+0xb0/0x1e0 [drm] [364415.547452] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [364415.547484] [<ffffffffa0198a06>] ? atombios_crtc_dpms+0x36/0x1e50 [radeon] [364415.547521] [<ffffffffa0198b7a>] ? atombios_crtc_dpms+0x1aa/0x1e50 [radeon] [364415.547566] [<ffffffffa0215032>] ? atombios_get_encoder_mode+0x132/0x1e0 [radeon] [364415.547614] [<ffffffffa02174ad>] ? atombios_set_edp_panel_power+0xc5d/0xce0 [radeon] [364415.547649] [<ffffffffa0106397>] ? drm_helper_crtc_in_use+0x1b7/0x1f0 [drm_kms_helper] [364415.547670] [<ffffffffa0107156>] ? drm_crtc_helper_set_config+0x116/0xb50 [drm_kms_helper] [364415.547681] [<ffffffff8158f85d>] ? __ww_mutex_lock+0x1d/0xc0 [364415.547723] [<ffffffffa01b51e8>] ? radeon_encoder_is_digital+0x1d8/0xe50 [radeon] [364415.547752] [<ffffffffa0080e36>] ? drm_mode_set_config_internal+0x66/0x100 [drm] [364415.547780] [<ffffffffa00855b9>] ? drm_mode_setcrtc+0x189/0x540 [drm] [364415.547813] [<ffffffffa00758d5>] ? drm_ioctl+0x1a5/0x840 [drm] [364415.547822] [<ffffffff8107ecf6>] ? dequeue_signal+0x36/0x180 [364415.547851] [<ffffffffa018a04c>] ? radeon_drm_ioctl+0x4c/0x5e0 [radeon] [364415.547859] [<ffffffff811e7840>] ? do_vfs_ioctl+0x2e0/0x4e0 [364415.547865] [<ffffffff8107ec0f>] ? recalc_sigpending+0x1f/0x60 [364415.547870] [<ffffffff8107f6b2>] ? __set_task_blocked+0x32/0x80 [364415.547880] [<ffffffff81474645>] ? __sys_recvmsg+0x65/0x80 [364415.547886] [<ffffffff811e7ac1>] ? SyS_ioctl+0x81/0xa0 [364415.547893] [<ffffffff810141e2>] ? sys_rt_sigreturn+0xb2/0xc0 [364415.547902] [<ffffffff81591a72>] ? system_call_fastpath+0x16/0x75
Now that all drivers are switched over to drm_vblank_on/off we can relegate pre/post_modeset to the purely drm_irq.c internal role of supporting on userspace.
As usual switch to the drm_legacy_ prefix to make it clear this is for old drivers only.
Signed-off-by: Daniel Vetter daniel.vetter@intel.com --- Documentation/DocBook/drm.tmpl | 2 -- drivers/gpu/drm/drm_irq.c | 41 ++++------------------------------------- include/drm/drmP.h | 4 ---- 3 files changed, 4 insertions(+), 43 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index b6fc354a20e7..5eef6323dbb3 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -3803,8 +3803,6 @@ int num_ioctls;</synopsis> drm_helper_connector_dpms() in reaction to fbdev blanking events. Do drivers that don't implement (or just don't use) fbcon compatibility need to call those functions themselves? -- KMS drivers must call drm_vblank_pre_modeset() and drm_vblank_post_modeset() - around mode setting. Should this be done in the DRM core? - vblank_disable_allowed is set to 1 in the first drm_vblank_post_modeset() call and never set back to 0. It seems to be safe to permanently set it to 1 in drm_vblank_init() for KMS driver, and it might be safe for UMS drivers as diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index 1967e7fc9805..038c8b3256da 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -1359,30 +1359,7 @@ void drm_crtc_vblank_on(struct drm_crtc *crtc) } EXPORT_SYMBOL(drm_crtc_vblank_on);
-/** - * drm_vblank_pre_modeset - account for vblanks across mode sets - * @dev: DRM device - * @crtc: CRTC in question - * - * Account for vblank events across mode setting events, which will likely - * reset the hardware frame counter. - * - * This is done by grabbing a temporary vblank reference to ensure that the - * vblank interrupt keeps running across the modeset sequence. With this the - * software-side vblank frame counting will ensure that there are no jumps or - * discontinuities. - * - * Unfortunately this approach is racy and also doesn't work when the vblank - * interrupt stops running, e.g. across system suspend resume. It is therefore - * highly recommended that drivers use the newer drm_vblank_off() and - * drm_vblank_on() instead. drm_vblank_pre_modeset() only works correctly when - * using "cooked" software vblank frame counters and not relying on any hardware - * counters. - * - * Drivers must call drm_vblank_post_modeset() when re-enabling the same crtc - * again. - */ -void drm_vblank_pre_modeset(struct drm_device *dev, int crtc) +static void drm_legacy_vblank_pre_modeset(struct drm_device *dev, int crtc) { struct drm_vblank_crtc *vblank = &dev->vblank[crtc];
@@ -1406,17 +1383,8 @@ void drm_vblank_pre_modeset(struct drm_device *dev, int crtc) vblank->inmodeset |= 0x2; } } -EXPORT_SYMBOL(drm_vblank_pre_modeset);
-/** - * drm_vblank_post_modeset - undo drm_vblank_pre_modeset changes - * @dev: DRM device - * @crtc: CRTC in question - * - * This function again drops the temporary vblank reference acquired in - * drm_vblank_pre_modeset. - */ -void drm_vblank_post_modeset(struct drm_device *dev, int crtc) +static void drm_legacy_vblank_post_modeset(struct drm_device *dev, int crtc) { struct drm_vblank_crtc *vblank = &dev->vblank[crtc]; unsigned long irqflags; @@ -1436,7 +1404,6 @@ void drm_vblank_post_modeset(struct drm_device *dev, int crtc) vblank->inmodeset = 0; } } -EXPORT_SYMBOL(drm_vblank_post_modeset);
/* * drm_modeset_ctl - handle vblank event counter changes across mode switch @@ -1469,10 +1436,10 @@ int drm_modeset_ctl(struct drm_device *dev, void *data,
switch (modeset->cmd) { case _DRM_PRE_MODESET: - drm_vblank_pre_modeset(dev, crtc); + drm_legacy_vblank_pre_modeset(dev, crtc); break; case _DRM_POST_MODESET: - drm_vblank_post_modeset(dev, crtc); + drm_legacy_vblank_post_modeset(dev, crtc); break; default: return -EINVAL; diff --git a/include/drm/drmP.h b/include/drm/drmP.h index df6d9970d9a4..bf22298559d1 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -962,10 +962,6 @@ static inline wait_queue_head_t *drm_crtc_vblank_waitqueue(struct drm_crtc *crtc return &crtc->dev->vblank[drm_crtc_index(crtc)].queue; }
-/* Modesetting support */ -extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc); -extern void drm_vblank_post_modeset(struct drm_device *dev, int crtc); - /* Stub support (drm_stub.h) */ extern struct drm_master *drm_master_get(struct drm_master *master); extern void drm_master_put(struct drm_master **master);
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.
thanks, -mario
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
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
On Fri, May 29, 2015 at 07:23:35PM +0200, Mario Kleiner wrote:
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.
Oh right totally missed the nv50+ code. I only grepped for pre/post_modeset ...
Below untested diff should help. I also realized that the pre-nv50 code lacks drm_vblank_on/off in the dpms callback, so there's more work to do anyway for this one here.
Thanks, Daniel
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c b/drivers/gpu/drm/nouveau/nv50_display.c index 7da7958556a3..a16c37d8f7e1 100644 --- a/drivers/gpu/drm/nouveau/nv50_display.c +++ b/drivers/gpu/drm/nouveau/nv50_display.c @@ -997,6 +997,10 @@ nv50_crtc_cursor_show_hide(struct nouveau_crtc *nv_crtc, bool show, bool update) static void nv50_crtc_dpms(struct drm_crtc *crtc, int mode) { + if (mode == DRM_MODE_DPMS_ON) + drm_crtc_vblank_on(crtc); + else + drm_crtc_vblank_off(crtc); }
static void @@ -1036,6 +1040,8 @@ nv50_crtc_prepare(struct drm_crtc *crtc) }
nv50_crtc_cursor_show_hide(nv_crtc, false, false); + + drm_crtc_vblank_on(crtc); }
static void @@ -1045,6 +1051,8 @@ nv50_crtc_commit(struct drm_crtc *crtc) struct nv50_mast *mast = nv50_mast(crtc->dev); u32 *push;
+ drm_crtc_vblank_on(crtc); + push = evo_wait(mast, 32); if (push) { if (nv50_vers(mast) < G82_DISP_CORE_CHANNEL_DMA) {
On 05/29/2015 07:35 PM, Daniel Vetter wrote:
On Fri, May 29, 2015 at 07:23:35PM +0200, Mario Kleiner wrote:
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.
Oh right totally missed the nv50+ code. I only grepped for pre/post_modeset ...
Below untested diff should help. I also realized that the pre-nv50 code lacks drm_vblank_on/off in the dpms callback, so there's more work to do anyway for this one here.
Thanks, Daniel
The diff on top of your patch is now tested and helps. suspend->resume is now fine on nv50. In your patch, nouveau_display_resume() would also need to get a now unused "int head" removed to make the compiler happy.
-mario
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c b/drivers/gpu/drm/nouveau/nv50_display.c index 7da7958556a3..a16c37d8f7e1 100644 --- a/drivers/gpu/drm/nouveau/nv50_display.c +++ b/drivers/gpu/drm/nouveau/nv50_display.c @@ -997,6 +997,10 @@ nv50_crtc_cursor_show_hide(struct nouveau_crtc *nv_crtc, bool show, bool update) static void nv50_crtc_dpms(struct drm_crtc *crtc, int mode) {
if (mode == DRM_MODE_DPMS_ON)
drm_crtc_vblank_on(crtc);
else
drm_crtc_vblank_off(crtc);
}
static void
@@ -1036,6 +1040,8 @@ nv50_crtc_prepare(struct drm_crtc *crtc) }
nv50_crtc_cursor_show_hide(nv_crtc, false, false);
drm_crtc_vblank_on(crtc); }
static void
@@ -1045,6 +1051,8 @@ nv50_crtc_commit(struct drm_crtc *crtc) struct nv50_mast *mast = nv50_mast(crtc->dev); u32 *push;
- drm_crtc_vblank_on(crtc);
- push = evo_wait(mast, 32); if (push) { if (nv50_vers(mast) < G82_DISP_CORE_CHANNEL_DMA) {
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.
v2: Don't forget about nv50+, reported by Mario.
Tested-by: Mario Kleiner mario.kleiner.de@gmail.com 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 | 6 +----- drivers/gpu/drm/nouveau/nv50_display.c | 8 ++++++++ 3 files changed, 11 insertions(+), 7 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); }
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..9d2d647da3aa 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -584,7 +584,7 @@ nouveau_display_resume(struct drm_device *dev, bool runtime) { struct nouveau_drm *drm = nouveau_drm(dev); struct drm_crtc *crtc; - int ret, head; + int ret;
/* re-pin fb/cursors */ list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) { @@ -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. diff --git a/drivers/gpu/drm/nouveau/nv50_display.c b/drivers/gpu/drm/nouveau/nv50_display.c index 7da7958556a3..a16c37d8f7e1 100644 --- a/drivers/gpu/drm/nouveau/nv50_display.c +++ b/drivers/gpu/drm/nouveau/nv50_display.c @@ -997,6 +997,10 @@ nv50_crtc_cursor_show_hide(struct nouveau_crtc *nv_crtc, bool show, bool update) static void nv50_crtc_dpms(struct drm_crtc *crtc, int mode) { + if (mode == DRM_MODE_DPMS_ON) + drm_crtc_vblank_on(crtc); + else + drm_crtc_vblank_off(crtc); }
static void @@ -1036,6 +1040,8 @@ nv50_crtc_prepare(struct drm_crtc *crtc) }
nv50_crtc_cursor_show_hide(nv_crtc, false, false); + + drm_crtc_vblank_on(crtc); }
static void @@ -1045,6 +1051,8 @@ nv50_crtc_commit(struct drm_crtc *crtc) struct nv50_mast *mast = nv50_mast(crtc->dev); u32 *push;
+ drm_crtc_vblank_on(crtc); + push = evo_wait(mast, 32); if (push) { if (nv50_vers(mast) < G82_DISP_CORE_CHANNEL_DMA) {
On 06/15/2015 08:07 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.
v2: Don't forget about nv50+, reported by Mario.
Tested-by: Mario Kleiner mario.kleiner.de@gmail.com 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 | 6 +----- drivers/gpu/drm/nouveau/nv50_display.c | 8 ++++++++ 3 files changed, 11 insertions(+), 7 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); }
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..9d2d647da3aa 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -584,7 +584,7 @@ nouveau_display_resume(struct drm_device *dev, bool runtime) { struct nouveau_drm *drm = nouveau_drm(dev); struct drm_crtc *crtc;
- int ret, head;
int ret;
/* re-pin fb/cursors */ list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
@@ -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.
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c b/drivers/gpu/drm/nouveau/nv50_display.c index 7da7958556a3..a16c37d8f7e1 100644 --- a/drivers/gpu/drm/nouveau/nv50_display.c +++ b/drivers/gpu/drm/nouveau/nv50_display.c @@ -997,6 +997,10 @@ nv50_crtc_cursor_show_hide(struct nouveau_crtc *nv_crtc, bool show, bool update) static void nv50_crtc_dpms(struct drm_crtc *crtc, int mode) {
if (mode == DRM_MODE_DPMS_ON)
drm_crtc_vblank_on(crtc);
else
drm_crtc_vblank_off(crtc);
}
static void
@@ -1036,6 +1040,8 @@ nv50_crtc_prepare(struct drm_crtc *crtc) }
nv50_crtc_cursor_show_hide(nv_crtc, false, false);
drm_crtc_vblank_on(crtc); }
static void
@@ -1045,6 +1051,8 @@ nv50_crtc_commit(struct drm_crtc *crtc) struct nv50_mast *mast = nv50_mast(crtc->dev); u32 *push;
- drm_crtc_vblank_on(crtc);
- push = evo_wait(mast, 32); if (push) { if (nv50_vers(mast) < G82_DISP_CORE_CHANNEL_DMA) {
This is
Reviewed-and-tested-by: Mario Kleiner mario.kleiner.de@gmail.com
-mario
dri-devel@lists.freedesktop.org