All of lore.kernel.org
 help / color / mirror / Atom feed
From: Imre Deak <imre.deak@intel.com>
To: Paulo Zanoni <przanoni@gmail.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Paulo Zanoni <paulo.r.zanoni@intel.com>
Subject: Re: [PATCH 04/11] drm/i915: get runtime PM at intel_set_mode
Date: Fri, 28 Feb 2014 15:07:18 +0200	[thread overview]
Message-ID: <1393592838.3479.45.camel@intelbox> (raw)
In-Reply-To: <CA+gsUGR5EiwzZ0Vcq0nXjo2_P=HYwV7PGCjrN+Q16tVW_jvDvA@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 2768 bytes --]

On Mon, 2014-02-24 at 11:34 -0300, Paulo Zanoni wrote:
> 2014-02-24 8:23 GMT-03:00 Imre Deak <imre.deak@intel.com>:
> > On Fri, 2014-02-21 at 13:52 -0300, Paulo Zanoni wrote:
> >> From: Paulo Zanoni <paulo.r.zanoni@intel.com>
> >>
> >> Otherwise, when we run intel_modeset_check_state we may already be
> >> runtime suspended, and our state checking code will read registers
> >> while the device is suspended. This can only happen if your
> >> autosuspend_delay_ms is low (not the default 10s).
> >>
> >> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> >> ---
> >>  drivers/gpu/drm/i915/intel_display.c | 5 +++++
> >>  1 file changed, 5 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> >> index 10ec401..c64fb7f 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -9746,13 +9746,18 @@ 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;
> >> +     struct drm_i915_private *dev_priv = dev->dev_private;
> >>       int ret;
> >>
> >> +     intel_runtime_pm_get(dev_priv);
> >> +
> >>       ret = __intel_set_mode(crtc, mode, x, y, fb);
> >>
> >>       if (ret == 0)
> >>               intel_modeset_check_state(crtc->dev);
> >>
> >> +     intel_runtime_pm_put(dev_priv);
> >>       return ret;
> >>  }
> >
> > Ideally these should be done as part of a power domain get/put as some
> > platforms will need to turn on some power wells too and on that path we
> > do anyway a runtime PM get/put.
> >
> > In the latest VLV power domain support patchset [1] I added the power
> > domain get/put and state check to places I thought necessary. I haven't
> > tested it on HSW but afaics the ones added for the HW state readout code
> > would solve the issue you describe here.
> 
> Yes. I just quickly read the patches, and they seem to try to solve
> this problem. Due to the reasons you wrote on the first paragraph, I
> think in the long term we want the power domains solution. But as I
> mentioned in the cover letter, this series contains bug fixes and
> maybe we want them on -fixes and even stable Kernels, so maybe we want
> to merge this patch, then later merge the code that uses power
> domains, then remove the runitme_pm_get calls and leave just the power
> domain calls? I'm not sure.

Ok, I can rebase my patchset based on the above.

Note that runtime PM was enabled post 3.13, so this fix is needed for
-fixes, but not for stable kernels.

The same goes for patch 5/11.

--Imre

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

  reply	other threads:[~2014-02-28 13:07 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-21 16:52 [PATCH 00/11] Runtime PM fixes Paulo Zanoni
2014-02-21 16:52 ` [PATCH 01/11] drm/i915: Accurately track when we mark the hardware as idle/busy Paulo Zanoni
2014-02-21 16:55   ` Chris Wilson
2014-02-21 17:04     ` Paulo Zanoni
2014-02-21 17:27       ` Chris Wilson
2014-02-21 19:34         ` Paulo Zanoni
2014-03-05 13:13           ` Daniel Vetter
2014-03-05 13:15             ` Chris Wilson
2014-02-21 16:52 ` [PATCH 02/11] drm/i915: put runtime PM only at the end of intel_mark_idle Paulo Zanoni
2014-02-21 17:28   ` Jesse Barnes
2014-03-05 13:14     ` Daniel Vetter
2014-02-21 16:52 ` [PATCH 03/11] drm/i915: put runtime PM only when we actually release force_wake Paulo Zanoni
2014-02-21 17:34   ` Jesse Barnes
2014-02-21 20:08     ` Paulo Zanoni
2014-02-21 20:16       ` Jesse Barnes
2014-02-21 20:58         ` Paulo Zanoni
2014-03-05 13:17         ` Daniel Vetter
2014-02-21 16:52 ` [PATCH 04/11] drm/i915: get runtime PM at intel_set_mode Paulo Zanoni
2014-02-21 17:35   ` Jesse Barnes
2014-02-24 11:23   ` Imre Deak
2014-02-24 14:34     ` Paulo Zanoni
2014-02-28 13:07       ` Imre Deak [this message]
2014-03-05 13:25   ` Daniel Vetter
2014-03-06 16:30     ` Paulo Zanoni
2014-02-21 16:52 ` [PATCH 05/11] drm/i915: get runtime PM while trying to detect CRT Paulo Zanoni
2014-02-21 17:37   ` Jesse Barnes
2014-02-24 11:33   ` Imre Deak
2014-02-24 14:36     ` Paulo Zanoni
2014-02-21 16:52 ` [PATCH 06/11] drm/i915: get/put runtime PM in more places at i915_debugfs.c Paulo Zanoni
2014-02-21 17:41   ` Jesse Barnes
2014-02-21 17:46     ` Paulo Zanoni
2014-03-05 13:29       ` Daniel Vetter
2014-02-21 16:52 ` [PATCH 07/11] drm/i915: kill dev_priv->pc8.gpu_idle Paulo Zanoni
2014-02-28 13:50   ` Imre Deak
2014-02-28 20:11     ` Paulo Zanoni
2014-03-05 13:31       ` Daniel Vetter
2014-02-21 16:52 ` [PATCH 08/11] drm/i915: call assert_device_not_suspended at gen6_force_wake_work Paulo Zanoni
2014-02-21 18:05   ` Paulo Zanoni
2014-02-28 14:12     ` Imre Deak
2014-02-21 16:52 ` [PATCH 09/11] drm/i915: assert force wake is disabled when we runtime suspend Paulo Zanoni
2014-02-28 14:32   ` Imre Deak
2014-02-21 16:52 ` [PATCH 10/11] drm/i915: don't get/put runtime PM at the debugfs forcewake file Paulo Zanoni
2014-02-28 14:34   ` Imre Deak
2014-03-05 13:41   ` Daniel Vetter
2014-02-21 16:52 ` [PATCH 11/11] drm/i915: assert we're not runtime suspended when writing registers Paulo Zanoni
2014-02-28 15:16   ` Imre Deak
2014-03-05 13:44     ` Daniel Vetter
2014-03-05 13:46       ` Daniel Vetter

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=1393592838.3479.45.camel@intelbox \
    --to=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=paulo.r.zanoni@intel.com \
    --cc=przanoni@gmail.com \
    /path/to/YOUR_REPLY

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

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