From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Paulo Zanoni <przanoni@gmail.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 1/5] drm/i915: Add intel_display_power_{get, put} to request power for specific domains
Date: Fri, 13 Sep 2013 23:49:21 +0300 [thread overview]
Message-ID: <20130913204921.GF4531@intel.com> (raw)
In-Reply-To: <CA+gsUGRZwFb2ULamDeyEwfi3v6A9Lr14MzurQxkmP=Lgbh05ow@mail.gmail.com>
On Fri, Sep 13, 2013 at 05:05:59PM -0300, Paulo Zanoni wrote:
> Hi
>
> 2013/9/12 <ville.syrjala@linux.intel.com>:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Add APIs to get/put power well references for specific purposes.
> >
> > Also reorganize the internal i915_request power well handling to use the
> > reference count just like everyone else. This way all we need to do is
> > check the reference count and we know whether the power well needs to be
> > enabled of disabled.
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/intel_drv.h | 4 ++
> > drivers/gpu/drm/i915/intel_pm.c | 92 ++++++++++++++++++++++++++++++++++++----
> > 2 files changed, 87 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > index 774ebb6..2ecd3d2 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -763,6 +763,10 @@ extern void i915_remove_power_well(struct drm_device *dev);
> >
> > extern bool intel_display_power_enabled(struct drm_device *dev,
> > enum intel_display_power_domain domain);
> > +extern void intel_display_power_get(struct drm_device *dev,
> > + enum intel_display_power_domain domain);
> > +extern void intel_display_power_put(struct drm_device *dev,
> > + enum intel_display_power_domain domain);
> > extern void intel_init_power_well(struct drm_device *dev);
> > extern void intel_set_power_well(struct drm_device *dev, bool enable);
> > extern void intel_enable_gt_powersave(struct drm_device *dev);
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> > index 8cffef4..4962303 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -5333,6 +5333,69 @@ static void __intel_set_power_well(struct drm_device *dev, bool enable)
> > }
> > }
> >
> > +void intel_display_power_get(struct drm_device *dev,
> > + enum intel_display_power_domain domain)
> > +{
> > + struct drm_i915_private *dev_priv = dev->dev_private;
> > + struct i915_power_well *power_well = &dev_priv->power_well;
> > +
> > + if (!HAS_POWER_WELL(dev))
> > + return;
> > +
> > + switch (domain) {
> > + case POWER_DOMAIN_PIPE_A:
> > + case POWER_DOMAIN_TRANSCODER_EDP:
> > + return;
> > + case POWER_DOMAIN_PIPE_B:
> > + case POWER_DOMAIN_PIPE_C:
> > + case POWER_DOMAIN_PIPE_A_PANEL_FITTER:
> > + case POWER_DOMAIN_PIPE_B_PANEL_FITTER:
> > + case POWER_DOMAIN_PIPE_C_PANEL_FITTER:
> > + case POWER_DOMAIN_TRANSCODER_A:
> > + case POWER_DOMAIN_TRANSCODER_B:
> > + case POWER_DOMAIN_TRANSCODER_C:
>
> I know I'm the one who added all these domains, but I have to say I
> only did this because of the reviewers, I don't really like the
> interface. With your addition there's a new problem: you can get the
> POWER_DOMAIN_PIPE_B interface and then put the
> POWER_COMAIN_PIPE_C_PANEL_FITTER and no one will notice. I really
> think the power well itself should be the domain. Also, in cases like
> the suspend/resume code we don't have any domain that makes sense. But
> what's *not* ugly about the power well code?
>
> I'm not suggesting you to fix that, I'm more kinda asking for ideas, I
> may want to reorganize this code yet again when doing the D3 feature.
> (Just because every single time we touch the power well code we have
> to refactor it!)
In other platforms we're going to have totally different mix of
functional blocks vs. power wells. So assuming we want to deal with those
using a unified API we do need something like this. But maybe there's a
better way to go, haven't really thought about it.
>
>
> > + spin_lock_irq(&power_well->lock);
> > + if (!power_well->count++)
> > + __intel_set_power_well(power_well->device, true);
> > + spin_unlock_irq(&power_well->lock);
> > + return;
> > + default:
> > + BUG();
> > + }
> > +}
> > +
> > +void intel_display_power_put(struct drm_device *dev,
> > + enum intel_display_power_domain domain)
> > +{
> > + struct drm_i915_private *dev_priv = dev->dev_private;
> > + struct i915_power_well *power_well = &dev_priv->power_well;
> > +
> > + if (!HAS_POWER_WELL(dev))
> > + return;
> > +
> > + switch (domain) {
> > + case POWER_DOMAIN_PIPE_A:
> > + case POWER_DOMAIN_TRANSCODER_EDP:
> > + return;
> > + case POWER_DOMAIN_PIPE_B:
> > + case POWER_DOMAIN_PIPE_C:
> > + case POWER_DOMAIN_PIPE_A_PANEL_FITTER:
> > + case POWER_DOMAIN_PIPE_B_PANEL_FITTER:
> > + case POWER_DOMAIN_PIPE_C_PANEL_FITTER:
> > + case POWER_DOMAIN_TRANSCODER_A:
> > + case POWER_DOMAIN_TRANSCODER_B:
> > + case POWER_DOMAIN_TRANSCODER_C:
> > + spin_lock_irq(&power_well->lock);
> > + WARN_ON(!power_well->count);
> > + if (!--power_well->count)
> > + __intel_set_power_well(power_well->device, false);
> > + spin_unlock_irq(&power_well->lock);
> > + return;
> > + default:
> > + BUG();
> > + }
> > +}
> > +
> > static struct i915_power_well *hsw_pwr;
> >
> > /* Display audio driver power well request */
> > @@ -5342,8 +5405,7 @@ void i915_request_power_well(void)
> > return;
> >
> > spin_lock_irq(&hsw_pwr->lock);
> > - if (!hsw_pwr->count++ &&
> > - !hsw_pwr->i915_request)
> > + if (!hsw_pwr->count++)
> > __intel_set_power_well(hsw_pwr->device, true);
> > spin_unlock_irq(&hsw_pwr->lock);
> > }
> > @@ -5357,8 +5419,7 @@ void i915_release_power_well(void)
> >
> > spin_lock_irq(&hsw_pwr->lock);
> > WARN_ON(!hsw_pwr->count);
> > - if (!--hsw_pwr->count &&
> > - !hsw_pwr->i915_request)
> > + if (!--hsw_pwr->count)
> > __intel_set_power_well(hsw_pwr->device, false);
> > spin_unlock_irq(&hsw_pwr->lock);
> > }
> > @@ -5394,15 +5455,28 @@ void intel_set_power_well(struct drm_device *dev, bool enable)
> > return;
> >
> > spin_lock_irq(&power_well->lock);
> > +
> > + /*
> > + * This function will only ever contribute one
> > + * to the power well reference count. i915_request
> > + * is what tracks whether we have or have not
> > + * added the one to the reference count.
> > + */
> > + if (power_well->i915_request == enable)
> > + goto out;
> > +
> > power_well->i915_request = enable;
> >
> > - /* only reject "disable" power well request */
> > - if (power_well->count && !enable) {
> > - spin_unlock_irq(&power_well->lock);
> > - return;
>
> And now to the real problem of the patch: previously whenever we got a
> call to "enable" we'd call __intel_set_power_well and certainly write
> the register. Now with this patch we may not do this due to
> i915_request and the count. This breaks suspend/resume where just
> after we resume we call intel_set_power_well(dev, true) but then the
> new code doesn't really writes the register since i915_request is
> already true. As a consequence, we see "unclaimed register" messages
> complaining about registers 70008, 71008 and 72008. Perhaps in the
> resume path we should fix our tracking and force the "enable" somehow.
Hmm. I guess we anyway want to force the power well to be active during
resume regardless of where the refcount was left.
So maybe just a resume power well func or something:
intel_resume_power_well()
{
if (!i915_request) {
i915_request = true;
count++;
}
__set_power_well(true);
}
>
>
> > + if (enable) {
> > + if (!power_well->count++)
> > + __intel_set_power_well(dev, true);
> > + } else {
> > + WARN_ON(!power_well->count);
> > + if (!--power_well->count)
> > + __intel_set_power_well(dev, false);
> > }
> >
> > - __intel_set_power_well(dev, enable);
> > + out:
> > spin_unlock_irq(&power_well->lock);
> > }
> >
> > --
> > 1.8.1.5
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> --
> Paulo Zanoni
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2013-09-13 20:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-12 14:12 [PATCH 0/5] drm/i915: VGA vs. power well ville.syrjala
2013-09-12 14:12 ` [PATCH 1/5] drm/i915: Add intel_display_power_{get, put} to request power for specific domains ville.syrjala
2013-09-13 20:05 ` Paulo Zanoni
2013-09-13 20:49 ` Ville Syrjälä [this message]
2013-09-13 21:43 ` Paulo Zanoni
2013-09-12 14:12 ` [PATCH 2/5] drm/i915: Refactor power well refcount inc/dec operations ville.syrjala
2013-09-13 20:09 ` Paulo Zanoni
2013-09-13 20:16 ` Chris Wilson
2013-09-12 14:12 ` [PATCH 3/5] drm/i915: Add POWER_DOMAIN_VGA ville.syrjala
2013-09-13 20:16 ` Paulo Zanoni
2013-09-12 14:12 ` [PATCH 4/5] drm/i915: Pull intel_init_power_well() out of intel_modeset_init_hw() ville.syrjala
2013-09-13 20:19 ` Paulo Zanoni
2013-09-13 20:26 ` Ville Syrjälä
2013-09-12 14:12 ` [PATCH 5/5] drm/i915: Fix unclaimed register access due to delayed VGA memroy disable ville.syrjala
2013-09-13 20:27 ` Paulo Zanoni
2013-09-13 20:59 ` 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=20130913204921.GF4531@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox