| Message ID | 1365537090-11518-1-git-send-email-daniel.vetter@ffwll.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Apr 09, 2013 at 09:51:30PM +0200, Daniel Vetter wrote: > It will be only consistent once we've restored all the crtcs. Since a > bunch of other callers also want to just restore a single crtc, add a > boolean to disable checking only where it doesn't make sense. > > Note that intel_modeset_setup_hw_state already has a call to > intel_modeset_check_state at the end, so we don't reduce the amount of > checking. > > v2: Try harder not to create a big patch (Chris). To what does tree does this patch apply? Tried v3.8.6 and master d02a9a89. Thanks, Richard
On Wed, Apr 10, 2013 at 01:59:02PM +0200, Richard Cochran wrote: > On Tue, Apr 09, 2013 at 09:51:30PM +0200, Daniel Vetter wrote: > > It will be only consistent once we've restored all the crtcs. Since a > > bunch of other callers also want to just restore a single crtc, add a > > boolean to disable checking only where it doesn't make sense. > > > > Note that intel_modeset_setup_hw_state already has a call to > > intel_modeset_check_state at the end, so we don't reduce the amount of > > checking. > > > > v2: Try harder not to create a big patch (Chris). > > To what does tree does this patch apply? > > Tried v3.8.6 and master d02a9a89. It's written against drm-intel-next-queued at http://cgit.freedesktop.org/~danvet/drm-intel I've thought that it should apply pretty cleanly against older kernels, too. Apparently it conflicts a bit in intel_modeset_setup_hw_state, you can just do the s/intel_crtc_restore_mode/__intel_set_mode/ change manually. -Daniel
On Wed, Apr 10, 2013 at 02:07:24PM +0200, Daniel Vetter wrote: > > It's written against drm-intel-next-queued at > > http://cgit.freedesktop.org/~danvet/drm-intel > > I've thought that it should apply pretty cleanly against older kernels, > too. Apparently it conflicts a bit in intel_modeset_setup_hw_state, you > can just do the s/intel_crtc_restore_mode/__intel_set_mode/ change > manually. I couldn't see right away how to fix it up, so I just compiled your drm-intel-next-queued plus this patch. If I close the netbook's lid and open it again, the screen is blank, no backlight, and the machine seems to be frozen. I think I can live with the warning. Thanks anyhow, Richard
On Wed, Apr 10, 2013 at 7:27 PM, Richard Cochran <richardcochran@gmail.com> wrote: > On Wed, Apr 10, 2013 at 02:07:24PM +0200, Daniel Vetter wrote: >> >> It's written against drm-intel-next-queued at >> >> http://cgit.freedesktop.org/~danvet/drm-intel >> >> I've thought that it should apply pretty cleanly against older kernels, >> too. Apparently it conflicts a bit in intel_modeset_setup_hw_state, you >> can just do the s/intel_crtc_restore_mode/__intel_set_mode/ change >> manually. > > I couldn't see right away how to fix it up, so I just compiled your > drm-intel-next-queued plus this patch. If I close the netbook's lid > and open it again, the screen is blank, no backlight, and the machine > seems to be frozen. > > I think I can live with the warning. That patch should crash at all, so this is not expected. Can you pls check whether plain drm-intel-nightly is broken, too? I'll quickly port the patch (in it's latest v3 version) to 3.9-rc kernels for you to test. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Wed, Apr 10, 2013 at 10:03:25PM +0200, Daniel Vetter wrote: > That patch should crash at all, so this is not expected. Can you pls > check whether plain drm-intel-nightly is broken, too? I did try drm-intel-nightly just now (1dd83e3), and it also freezes the machine. I first verified that the power button shutdown is working (before starting X). Then, with X running, closing and reopening the lid results in a blank screen (no backlight) and a seemingly frozen box. > I'll quickly port the patch (in it's latest v3 version) to 3.9-rc > kernels for you to test. Okay, I'll try this next. Thanks, Richard
On Thu, Apr 11, 2013 at 7:52 PM, Richard Cochran <richardcochran@gmail.com> wrote: > On Wed, Apr 10, 2013 at 10:03:25PM +0200, Daniel Vetter wrote: > >> That patch should crash at all, so this is not expected. Can you pls >> check whether plain drm-intel-nightly is broken, too? > > I did try drm-intel-nightly just now (1dd83e3), and it also freezes > the machine. I first verified that the power button shutdown is > working (before starting X). Then, with X running, closing and > reopening the lid results in a blank screen (no backlight) and a > seemingly frozen box. I've just tracked down and fixed an bug which can lead to a hard-hang in the crtc restore code (which is used both in the lid handler when opening and on resume). If you could please test this patch (on top of drm-intel-nightly): https://patchwork.kernel.org/patch/2428971/ >> I'll quickly port the patch (in it's latest v3 version) to 3.9-rc >> kernels for you to test. > > Okay, I'll try this next. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Thu, Apr 11, 2013 at 08:14:10PM +0200, Daniel Vetter wrote: > > I've just tracked down and fixed an bug which can lead to a hard-hang > in the crtc restore code (which is used both in the lid handler when > opening and on resume). If you could please test this patch (on top of > drm-intel-nightly): > > https://patchwork.kernel.org/patch/2428971/ Okay, will do. > >> I'll quickly port the patch (in it's latest v3 version) to 3.9-rc > >> kernels for you to test. FWIW, this does work, no freeze, no warning, but instead: Apr 11 20:30:49 netboy laptop-mode: Laptop mode Apr 11 20:30:49 netboy laptop-mode: enabled, Apr 11 20:30:49 netboy laptop-mode: not active [unchanged] Apr 11 20:30:53 netboy kernel: [ 75.450783] [drm:i9xx_crtc_mode_set] *ERROR* Couldn't find PLL settings for mode! Apr 11 20:30:53 netboy laptop-mode: Laptop mode Apr 11 20:30:53 netboy laptop-mode: enabled, Apr 11 20:30:53 netboy laptop-mode: not active [unchanged] Thanks, Richard
On Thu, Apr 11, 2013 at 08:14:10PM +0200, Daniel Vetter wrote: > > I've just tracked down and fixed an bug which can lead to a hard-hang > in the crtc restore code (which is used both in the lid handler when > opening and on resume). If you could please test this patch (on top of > drm-intel-nightly): > > https://patchwork.kernel.org/patch/2428971/ Now I can confirm this works fine, with no warnings, errors, or freezes. Thanks, Richard
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 8809813..2959fb8 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -7916,9 +7916,9 @@ intel_modeset_check_state(struct drm_device *dev) } } -int intel_set_mode(struct drm_crtc *crtc, - struct drm_display_mode *mode, - int x, int y, struct drm_framebuffer *fb) +static int __intel_set_mode(struct drm_crtc *crtc, + struct drm_display_mode *mode, + int x, int y, struct drm_framebuffer *fb) { struct drm_device *dev = crtc->dev; drm_i915_private_t *dev_priv = dev->dev_private; @@ -8012,8 +8012,6 @@ done: if (ret && crtc->enabled) { crtc->hwmode = *saved_hwmode; crtc->mode = *saved_mode; - } else { - intel_modeset_check_state(dev); } out: @@ -8022,9 +8020,25 @@ out: return ret; } +int intel_set_mode(struct drm_crtc *crtc, + struct drm_display_mode *mode, + int x, int y, struct drm_framebuffer *fb) +{ + int ret; + + ret = __intel_set_mode(crtc, mode, x, y, fb); + + if (ret == 0) + intel_modeset_check_state(crtc->dev); + + return ret; +} + void intel_crtc_restore_mode(struct drm_crtc *crtc) { - intel_set_mode(crtc, &crtc->mode, crtc->x, crtc->y, crtc->fb); + __intel_set_mode(crtc, &crtc->mode, crtc->x, crtc->y, crtc->fb); + + intel_modeset_check_state(crtc->dev); } #undef for_each_intel_crtc_masked @@ -9333,10 +9347,16 @@ setup_pipes: } if (force_restore) { + /* + * We need to use raw interfaces for restoring state to avoid + * checking (bogus) intermediate states. + */ for_each_pipe(pipe) { struct drm_crtc *crtc = dev_priv->pipe_to_crtc_mapping[pipe]; - intel_crtc_restore_mode(crtc); + + __intel_set_mode(crtc, &crtc->mode, crtc->x, crtc->y, + crtc->fb); } list_for_each_entry(plane, &dev->mode_config.plane_list, head) intel_plane_restore(plane);
It will be only consistent once we've restored all the crtcs. Since a bunch of other callers also want to just restore a single crtc, add a boolean to disable checking only where it doesn't make sense. Note that intel_modeset_setup_hw_state already has a call to intel_modeset_check_state at the end, so we don't reduce the amount of checking. v2: Try harder not to create a big patch (Chris). References: https://lkml.org/lkml/2013/3/16/60 Cc: Tomas Melin <tomas.melin@iki.fi> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> --- drivers/gpu/drm/i915/intel_display.c | 34 +++++++++++++++++++++++++++------- 1 file changed, 27 insertions(+), 7 deletions(-)