All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>,
	intel-gfx@lists.freedesktop.org, damien.lespiau@intel.com
Subject: Re: [RFC PATCH] drm/i915/skl: Add DC6 disabling as a power well
Date: Thu, 24 Sep 2015 18:20:14 +0300	[thread overview]
Message-ID: <20150924152014.GA26517@intel.com> (raw)
In-Reply-To: <20150924125016.GA10347@patrik-desktop.isw.intel.com>

On Thu, Sep 24, 2015 at 02:50:16PM +0200, Patrik Jakobsson wrote:
> On Wed, Sep 23, 2015 at 01:18:00PM +0200, Patrik Jakobsson wrote:
> > On Wed, Sep 23, 2015 at 10:43:00AM +0200, Daniel Vetter wrote:
> > > On Mon, Sep 21, 2015 at 10:00:45AM +0200, Patrik Jakobsson wrote:
> > > > On Wed, Sep 16, 2015 at 11:10:07PM +0300, Ville Syrjälä wrote:
> > > > > On Fri, Sep 11, 2015 at 01:55:22PM +0200, Patrik Jakobsson wrote:
> > > > > > We need to be able to control if DC6 is allowed or not. Much like
> > > > > > requesting power to a specific piece of the hardware we need to be able
> > > > > > to request that we don't enter DC6 during certain hw access.
> > > > > > 
> > > > > > To solve this without introducing too much infrastructure I'm hooking
> > > > > > into the power well / power domain framework. DC6 prevention is modeled
> > > > > > much like an enabled power well. Thus I'm using the terminology on/off
> > > > > > for DC states instead of enable/disable.
> > > > > > 
> > > > > > The problem that started this work is the need for DC6 to be disabled
> > > > > > when accessing DP_AUX_A during CRTC on/off. That is also fixed in this
> > > > > > patch.
> > > > > > 
> > > > > > This is posted as an RFC since DMC and DC state handling is being
> > > > > > reworked and will possibly affect the outcome of this patch. The patch
> > > > > > has known warnings.
> > > > > > 
> > > > > > Signed-off-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/intel_ddi.c        |  9 +++++
> > > > > >  drivers/gpu/drm/i915/intel_drv.h        |  2 +
> > > > > >  drivers/gpu/drm/i915/intel_runtime_pm.c | 69 +++++++++++++++++++++++++--------
> > > > > >  3 files changed, 64 insertions(+), 16 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > index 4823184..c2c1ad2 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > @@ -2288,6 +2288,8 @@ static void intel_ddi_pre_enable(struct intel_encoder *intel_encoder)
> > > > > >  	if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
> > > > > >  		struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > > > >  
> > > > > > +		intel_display_power_get(dev_priv, POWER_DOMAIN_AUX_A);
> > > > > > +
> > > > > 
> > > > > These I think shouldn't be necessary with my
> > > > > intel_display_port_aux_power_domain() stuff since intel_dp_aux_ch() will
> > > > > itself grab the appropriate power domain.
> > > > > 
> > > > > That's of course assuming that AUX is the only reason why we need to
> > > > > keep DC6 disabled here.
> > > > > 
> > > > 
> > > > The upside with having get/put around bigger aux transfers is that we don't get
> > > > tons of enable/disable lines in the log. My vote is that we keep this but also
> > > > have your fine-grained get/puts.
> > > 
> > > Imo the correct solution to avoid this is by adding a slight bit of
> > > hystersis to the power well code. Which means that yes, we reinvent
> > > another feature of the core power_domain code in our home-grown solution -
> > > I hate it when my years old predictions come true ;-)
> > > 
> > > Sprinkling higher-level get/put calls all over the place is imo just
> > > leaking the abstraction, which isn't good.
> > > -Daniel
> > 
> > With Ville's patches the problem is not as bad as I first thought. We can add
> > hysteresis later if needed.
> > 
> > -Patrik
> 
> So I discovered that we cannot have DC5 and DC6 as seperate power wells since
> they are mutually exclusive. As Ville pointed out we don't use DC5 for anything
> so we could get away for now with just DC6 as a power well.
> 
> As I see it there are three ways to go about this:
> 
> A. Add AUX A to Power well 2.
> This would power up PW2 during DP Aux A even though we don't need it but since
> we get the side effect of DC6 being disabled it should work.
> 
> B. Add DC6 off as a power well and remove DC5 off.
> Fairly straight forward but assumes we don't need DC5 control.
> 
> C. Add multi-state support for the DC power well.
> Would be the nice way but perhaps a bit overkill. Good thing about this would be
> that we can incorporate DC9 control for BXT and unify more of the DC code.
> 
> So A, B or C?

After some spitballing with Imre we came up with the following power well layout,
which I think matches the documented seuqences in the spec the best:

display well:
    domains: 
        all
    enable:
        init display sequence
            enable pch reset handshake
            enable pw1 and miscio
            enable cdclk pll
            enable dbuf
        dc_state_en = up_to_dc6
    disable:
        dc_state_en = disable
        uninit display sequence
            disable dbuf
            disable cdclk pll
            disable pw1 and miscio

dc6 off well:
    domains:
        gmbus, dc5 off well domains
    enable:
        dc_state_en = up_to_dc5
    disable:
        dc_state_en = up_to_dc6

dc5 off well:
    domains:
        aux A, pw2 well domains
    enable:
        dc_state_en = disable
    disable:
        dc_state_en = up_to_dc5

pw2 well:
    domains:
        ddi B/C/D/E, aux B/C/D/E, vga, audio, pipe B/C, pfit B/C
    enable:
        enable pw2
    disable:
        disable pw2

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-09-24 15:20 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-11 11:55 [RFC PATCH] drm/i915/skl: Add DC6 disabling as a power well Patrik Jakobsson
2015-09-14  9:50 ` Daniel Vetter
2015-09-14 10:35   ` Patrik Jakobsson
2015-09-16 20:10 ` Ville Syrjälä
2015-09-17 11:14   ` Ville Syrjälä
2015-09-17 11:45     ` Ville Syrjälä
2015-09-23  8:40       ` Daniel Vetter
2015-09-21 10:43     ` Patrik Jakobsson
2015-09-21 11:12       ` Patrik Jakobsson
2015-09-21  8:00   ` Patrik Jakobsson
2015-09-21  8:26     ` Jani Nikula
2015-09-21  8:45       ` Patrik Jakobsson
2015-09-23  8:43     ` Daniel Vetter
2015-09-23 11:18       ` Patrik Jakobsson
2015-09-24 12:50         ` Patrik Jakobsson
2015-09-24 15:20           ` Ville Syrjälä [this message]
2015-09-25  8:56             ` Patrik Jakobsson
2015-09-25  9:41               ` Imre Deak
2015-09-25 11:37                 ` Patrik Jakobsson
2015-09-25 11:32               ` Ville Syrjälä

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=20150924152014.GA26517@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=damien.lespiau@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    /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.