All of lore.kernel.org
 help / color / mirror / Atom feed
From: Imre Deak <imre.deak@intel.com>
To: Animesh Manna <animesh.manna@intel.com>
Cc: intel-gfx@lists.freedesktop.org,
	Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [SKL-DMC-BUGFIX 2/5] drm/i915/skl: Making DC6 entry is the last call in suspend flow.
Date: Mon, 12 Oct 2015 16:32:13 +0300	[thread overview]
Message-ID: <1444656733.13337.31.camel@intel.com> (raw)
In-Reply-To: <1438619136-18268-3-git-send-email-animesh.manna@intel.com>

On ma, 2015-08-03 at 21:55 +0530, Animesh Manna wrote:
> Mmio register access after dc6/dc5 entry is not allowed when
> DC6 power states are enabled according to bspec (bspec-id 0527),
> so enabling dc6 as the last call in suspend flow.

The MMIO range BSpec-ID 0527 refers to is the DMC MMIO range. The driver
uses this MMIO range only to program the FW image, it doesn't access it
afterwards. So that's not a good justification to keep DC6 disabled.

That BSpec-ID also mentions that DC6 together with DC5 needs to be
disabled around modesets, which we need to address by disabling both
DC5/6, but only around modesets.

Later discussions with HW people revealed that there is an open issue
related to DC6, see [1]. The suggested workaround for that issue is to
keep DC6 disabled all the time and use a manual sequence to enable
deeper power states (see "Sequence for Software to Allow Package C9-C10"
in BSpec).

Based on this what we need to do in this patch is simply disable DC6. As
a follow-up to this patchset we need to:
- Add the manual PC9/10 sequence.
- Prevent DC5/6 during modesets (and DPAUX transfers).
- Move out the remaining parts of the display init/uninit sequence from
the suspend/resume path.
- Add a module options to select between enabling DC6 and running the
manual PC9/10 sequence. People still would like to experiment with DC6
and we may end up enabling it in the end if all the open issues get
resolved. For that case enabling DC6 should still happen at the place
where it happens now, that is after disabling PW2.

Please see my corresponding comments inlined below.

[1]
http://lists.freedesktop.org/archives/intel-gfx/2015-October/077669.html

> 
> v1: Initial version.
> 
> v2: commit message updated based on comment from Vathsala.
> 
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Damien Lespiau <damien.lespiau@intel.com>
> Cc: Imre Deak <imre.deak@intel.com>
> Cc: Sunil Kamath <sunil.kamath@intel.com>
> Signed-off-by: Animesh Manna <animesh.manna@intel.com>
> Signed-off-by: Vathsala Nagaraju <vathsala.nagaraju@intel.com>
> Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_drv.c         | 12 ++++++------
>  drivers/gpu/drm/i915/intel_drv.h        |  2 ++
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 33 ++++++++-------------------------
>  3 files changed, 16 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 0d6775a..e1d0102 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1017,14 +1017,11 @@ static int skl_suspend_complete(struct drm_i915_private *dev_priv)
>  {
>  	/* Enabling DC6 is not a hard requirement to enter runtime D3 */
>  
> -	/*
> -	 * This is to ensure that CSR isn't identified as loaded before
> -	 * CSR-loading program is called during runtime-resume.
> -	 */
> -	intel_csr_load_status_set(dev_priv, FW_UNINITIALIZED);
> -
>  	skl_uninit_cdclk(dev_priv);
>  
> +	if (intel_csr_load_status_get(dev_priv) == FW_LOADED)
> +		skl_enable_dc6(dev_priv);
> +

Not needed, atm we shouldn't enable DC6 ever due to open issues under
investigation. Even if those investigations reveal that we can use DC6
it shouldn't be enabled here, rather at its current place after
disabling PW2.

>  	return 0;
>  }
>  
> @@ -1071,6 +1068,9 @@ static int skl_resume_prepare(struct drm_i915_private *dev_priv)
>  {
>  	struct drm_device *dev = dev_priv->dev;
>  
> +	if (intel_csr_load_status_get(dev_priv) == FW_LOADED)
> +		skl_disable_dc6(dev_priv);
> +

Not needed based on the previous comment.

>  	skl_init_cdclk(dev_priv);
>  	intel_csr_load_program(dev);
>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index 47cef0e..06f346f 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1117,6 +1117,8 @@ void bxt_enable_dc9(struct drm_i915_private *dev_priv);
>  void bxt_disable_dc9(struct drm_i915_private *dev_priv);
>  void skl_init_cdclk(struct drm_i915_private *dev_priv);
>  void skl_uninit_cdclk(struct drm_i915_private *dev_priv);
> +void skl_enable_dc6(struct drm_i915_private *dev_priv);
> +void skl_disable_dc6(struct drm_i915_private *dev_priv);
>  void intel_dp_get_m_n(struct intel_crtc *crtc,
>  		      struct intel_crtc_state *pipe_config);
>  void intel_dp_set_m_n(struct intel_crtc *crtc, enum link_m_n_set m_n);
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 6393b76..c660245 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -532,7 +532,7 @@ static void assert_can_disable_dc6(struct drm_i915_private *dev_priv)
>  		"DC6 already programmed to be disabled.\n");
>  }
>  
> -static void skl_enable_dc6(struct drm_i915_private *dev_priv)
> +void skl_enable_dc6(struct drm_i915_private *dev_priv)
>  {
>  	uint32_t val;
>  
> @@ -549,7 +549,7 @@ static void skl_enable_dc6(struct drm_i915_private *dev_priv)
>  	POSTING_READ(DC_STATE_EN);
>  }
>  
> -static void skl_disable_dc6(struct drm_i915_private *dev_priv)
> +void skl_disable_dc6(struct drm_i915_private *dev_priv)
>  {
>  	uint32_t val;
>  
> @@ -610,10 +610,10 @@ static void skl_set_power_well(struct drm_i915_private *dev_priv,
>  				!I915_READ(HSW_PWR_WELL_BIOS),
>  				"Invalid for power well status to be enabled, unless done by the BIOS, \
>  				when request is to disable!\n");
> -			if ((GEN9_ENABLE_DC5(dev) || SKL_ENABLE_DC6(dev)) &&
> -				power_well->data == SKL_DISP_PW_2) {
> +			if (power_well->data == SKL_DISP_PW_2) {
> +				if (GEN9_ENABLE_DC5(dev))
> +					gen9_disable_dc5(dev_priv);
>  				if (SKL_ENABLE_DC6(dev)) {
> -					skl_disable_dc6(dev_priv);
>  					/*
>  					 * DDI buffer programming unnecessary during driver-load/resume
>  					 * as it's already done during modeset initialization then.
> @@ -621,8 +621,6 @@ static void skl_set_power_well(struct drm_i915_private *dev_priv,
>  					 */
>  					if (!dev_priv->power_domains.initializing)
>  						intel_prepare_ddi(dev);
> -				} else {
> -					gen9_disable_dc5(dev_priv);

Instead of this please just redefine GEN9_ENABLE_DC5 and SKL_ENABLE_DC6
accordingly. We want to keep the possibility to use DC6, (adding a
module option for it as a follow-up), and then this is still the right
place to disable it.

>  				}
>  			}
>  			I915_WRITE(HSW_PWR_WELL_DRIVER, tmp | req_mask);
> @@ -642,24 +640,9 @@ static void skl_set_power_well(struct drm_i915_private *dev_priv,
>  			POSTING_READ(HSW_PWR_WELL_DRIVER);
>  			DRM_DEBUG_KMS("Disabling %s\n", power_well->name);
>  
> -			if ((GEN9_ENABLE_DC5(dev) || SKL_ENABLE_DC6(dev)) &&
> -				power_well->data == SKL_DISP_PW_2) {
> -				enum csr_state state;
> -				/* TODO: wait for a completion event or
> -				 * similar here instead of busy
> -				 * waiting using wait_for function.
> -				 */
> -				wait_for((state = intel_csr_load_status_get(dev_priv)) !=
> -						FW_UNINITIALIZED, 1000);
> -				if (state != FW_LOADED)
> -					DRM_ERROR("CSR firmware not ready (%d)\n",
> -							state);
> -				else
> -					if (SKL_ENABLE_DC6(dev))
> -						skl_enable_dc6(dev_priv);
> -					else
> -						gen9_enable_dc5(dev_priv);
> -			}
> +			if (GEN9_ENABLE_DC5(dev) &&
> +				power_well->data == SKL_DISP_PW_2)
> +					gen9_enable_dc5(dev_priv);

Removing the blocking wait is ok, though you should have mentioned in
the commit log why and have this change in a separate patch. Instead of
removing skl_enable_dc6() please redefine the macros as explained above.

--Imre

>  		}
>  	}
>  


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

  parent reply	other threads:[~2015-10-12 13:32 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-03 16:25 [SKL-DMC-BUGFIX 0/5] SKL PC10 entry fixes Animesh Manna
2015-08-03 16:25 ` [SKL-DMC-BUGFIX 1/5] drm/i915/gen9: Removed byte swapping for csr firmware Animesh Manna
2015-08-04  3:46   ` Nagaraju, Vathsala
2015-08-04  5:55     ` Animesh Manna
2015-08-05  9:01       ` Daniel Vetter
2015-08-06  9:20         ` Animesh Manna
2015-09-11 15:29         ` Mika Kuoppala
2015-09-14  7:35           ` [REGRESSION] " Daniel Vetter
2015-09-17  9:36             ` Mika Kuoppala
2015-08-04 11:24   ` [SKL-DMC-BUGFIX 1/5] " Sunil Kamath
2015-08-03 16:25 ` [SKL-DMC-BUGFIX 2/5] drm/i915/skl: Making DC6 entry is the last call in suspend flow Animesh Manna
2015-08-04 11:25   ` Sunil Kamath
2015-08-05  9:07     ` Daniel Vetter
2015-08-05  9:05   ` Daniel Vetter
2015-08-06  9:17     ` Animesh Manna
2015-08-06 10:50       ` [PATCH " Animesh Manna
2015-08-06 13:18       ` [SKL-DMC-BUGFIX " Daniel Vetter
2015-08-06 14:38         ` Animesh Manna
2015-08-06 15:38           ` Daniel Vetter
2015-10-12 13:32   ` Imre Deak [this message]
2015-10-12 15:43     ` [PATCH] drm/i915: Disable DC6 for now Rodrigo Vivi
2015-10-13  1:24       ` Hindman, Gavin
2015-08-03 16:25 ` [SKL-DMC-BUGFIX 3/5] drm/i915/skl: Do not disable cdclk PLL if csr firmware is present Animesh Manna
2015-08-04 11:26   ` Sunil Kamath
2015-08-05  9:12   ` Daniel Vetter
2015-08-06  9:03     ` Animesh Manna
2015-08-06 11:23       ` Animesh Manna
2015-10-12 13:37   ` Imre Deak
2015-10-12 14:07     ` Imre Deak
2015-10-12 14:46       ` Patrik Jakobsson
2015-10-12 15:11         ` Imre Deak
2015-08-03 16:25 ` [SKL-DMC-BUGFIX 4/5] drm/i915/skl: Block disable call for pw1 if dmc " Animesh Manna
2015-08-04 11:27   ` Sunil Kamath
2015-08-05  9:14   ` Daniel Vetter
2015-08-06  8:57     ` Animesh Manna
2015-10-12 13:45   ` Imre Deak
2015-08-03 16:25 ` [SKL-DMC-BUGFIX 5/5] drm/i915/skl: Removed csr firmware load in resume path Animesh Manna
2015-08-04 11:20   ` Sunil Kamath
2015-08-04 11:33     ` Animesh Manna
2015-08-06  9:49       ` Animesh Manna
2015-10-12 14:02   ` Imre Deak
2015-08-03 18:47 ` [SKL-DMC-BUGFIX 0/5] SKL PC10 entry fixes Zanoni, Paulo R
2015-08-04 11:31   ` Sunil Kamath
2015-08-04 13:14     ` Zanoni, Paulo R

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=1444656733.13337.31.camel@intel.com \
    --to=imre.deak@intel.com \
    --cc=animesh.manna@intel.com \
    --cc=daniel.vetter@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=rajneesh.bhardwaj@intel.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.