All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Imre Deak <imre.deak@intel.com>, intel-gfx@lists.freedesktop.org
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>,
	ville.syrjala@intel.linux.com,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [PATCH] drm/i915: Add documentation to gen9_set_dc_state()
Date: Wed, 25 Apr 2018 12:49:14 +0300	[thread overview]
Message-ID: <87lgdbd3ad.fsf@intel.com> (raw)
In-Reply-To: <20180417113147.25120-1-imre.deak@intel.com>


Cc: Rodrigo, DK, Ville

On Tue, 17 Apr 2018, Imre Deak <imre.deak@intel.com> wrote:
> Add documentation to gen9_set_dc_state() on what enabling a given DC
> state means and at what point HW/DMC actually enters/exits these states.
>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Imre Deak <imre.deak@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
>
> [ On IRC I stated that PSR entry would be prevented in a given DC state,
>   but looking more at it I haven't found any proof for this. So as I
>   understand the only connection between PSR and DC states is that if
>   DC5/6 is disabled power saving will be blocked, which would otherwise
>   be possible when PSR is active and the display pipe is off. ]

I think I'm still missing a definitive answer to the question, who
disables PSR before DP AUX transactions?

Does intel_display_power_get(dev_priv, intel_dp->aux_power_domain) in
pps_lock() cause PSR exit, through the DC state change? If yes, this
needs to be properly documented in code. Maybe with a WARN_ON(psr
active) on top.

Quoting bspec 7530, "DDI A AUX channel transactions must not be sent
while SRD is enabled. SRD must be completely disabled before a DDI A AUX
channel transaction can be sent."

I'm also confused how sink CRC would ever work with PSR enabled.

BR,
Jani.


>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 53ea564f971e..40a7955886d4 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -542,6 +542,29 @@ void gen9_sanitize_dc_state(struct drm_i915_private *dev_priv)
>  	dev_priv->csr.dc_state = val;
>  }
>  
> +/**
> + * gen9_set_dc_state - set target display C power state
> + * @dev_priv: i915 device instance
> + * @state: target DC power state
> + * - DC_STATE_DISABLE
> + * - DC_STATE_EN_UPTO_DC5
> + * - DC_STATE_EN_UPTO_DC6
> + * - DC_STATE_EN_DC9
> + *
> + * Signal to DMC firmware/HW the target DC power state passed in @state.
> + * DMC/HW can turn off individual display clocks and power rails when entering
> + * a deeper DC power state (higher in number) and turns these back when exiting
> + * that state to a shallower power state (lower in number). The HW will decide
> + * when to actually enter a given state on an on-demand basis, for instance
> + * depending on the active state of display pipes. The state of display
> + * registers backed by affected power rails are saved/restored as needed.
> + *
> + * Based on the above enabling a deeper DC power state is asynchronous wrt.
> + * enabling it. Disabling a deeper power state is synchronous: for instance
> + * setting %DC_STATE_DISABLE won't complete until all HW resources are turned
> + * back on and register state is restored. This is guaranteed by the MMIO write
> + * to DC_STATE_EN blocking until the state is restored.
> + */
>  static void gen9_set_dc_state(struct drm_i915_private *dev_priv, uint32_t state)
>  {
>  	uint32_t val;

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2018-04-25  9:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-17 11:31 [PATCH] drm/i915: Add documentation to gen9_set_dc_state() Imre Deak
2018-04-17 12:25 ` ✓ Fi.CI.BAT: success for " Patchwork
2018-04-17 14:06 ` ✓ Fi.CI.IGT: " Patchwork
2018-04-25  9:01 ` [PATCH] " Daniel Vetter
2018-04-25  9:49 ` Jani Nikula [this message]
2018-04-25  9:50   ` Jani Nikula
2018-04-25 11:09     ` Imre Deak
2018-04-25 17:45       ` Rodrigo Vivi
2018-04-25 18:32         ` Dhinakaran Pandiyan
2018-04-25 18:47 ` Dhinakaran Pandiyan
2018-04-26 10:38   ` Imre Deak
2018-05-07 14:56 ` Imre Deak

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=87lgdbd3ad.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dhinakaran.pandiyan@intel.com \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=ville.syrjala@intel.linux.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.