Re: [PATCH v2 11/11] drm/i915: Introduce separate status variable for RC6 and LLC ring frequency setup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 10/6/2017 6:25 PM, Chris Wilson wrote:
Quoting Sagar Arun Kamble (2017-10-06 13:13:40)
Defined new struct intel_rc6 to hold RC6 specific state and
intel_ring_pstate to hold ring specific state.

v2: s/intel_ring_pstate/intel_llc_pstate and rebase. (Chris)

Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@xxxxxxxxx>
Cc: Imre Deak <imre.deak@xxxxxxxxx>
Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@xxxxxxxxx>
---
  drivers/gpu/drm/i915/i915_drv.c |  2 +-
  drivers/gpu/drm/i915/i915_drv.h | 10 ++++++++
  drivers/gpu/drm/i915/intel_pm.c | 57 +++++++++++++++++++++++++++++++----------
  3 files changed, 54 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 470807c..154f231 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2502,7 +2502,7 @@ static int intel_runtime_suspend(struct device *kdev)
         struct drm_i915_private *dev_priv = to_i915(dev);
         int ret;
- if (WARN_ON_ONCE(!(dev_priv->pm.rps.enabled && intel_rc6_enabled())))
+       if (WARN_ON_ONCE(!(dev_priv->pm.rc6.enabled && intel_rc6_enabled())))
                 return -ENODEV;
if (WARN_ON_ONCE(!HAS_RUNTIME_PM(dev_priv)))
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 45944a8..a07aa71 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1363,8 +1363,18 @@ struct intel_rps {
         struct intel_rps_ei ei;
  };
+struct intel_rc6 {
+       bool enabled;
+};
+
+struct intel_llc_pstate {
+       bool configured;
+};
+
  struct intel_gen6_power_mgmt {
         struct intel_rps rps;
+       struct intel_rc6 rc6;
+       struct intel_llc_pstate llc_pstate;
         struct delayed_work autoenable_work;
/*
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 03264fe..df36a6f 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7873,7 +7873,12 @@ static void intel_init_emon(struct drm_i915_private *dev_priv)
static inline void intel_update_ring_freq(struct drm_i915_private *i915)
  {
+       if (READ_ONCE(i915->pm.llc_pstate.configured))
+               return;
Tell me about how you expect the locking around this function to be.

The READ_ONCE() implies that we are doing a optimistic peek outside of a
lock, but then we set configured without acquiring a lock, so I assume
we are inside some lock.

That looks true for all, we don't need READ_ONCE() anymore as we only
inspect inside the mutex (and so READ_ONCE is giving the wrong
impression).

+
         gen6_update_ring_freq(i915);
+
+       i915->pm.llc_pstate.configured = true;
  }
void intel_disable_gt_powersave(struct drm_i915_private *dev_priv)
  {
-       if (!READ_ONCE(dev_priv->pm.rps.enabled))
-               return;
-
         mutex_lock(&dev_priv->pm.pcu_lock);
intel_disable_rc6(dev_priv);
         intel_disable_rps(dev_priv);
+       if (HAS_LLC(dev_priv))
+               dev_priv->pm.llc_pstate.configured = false;
Always clear it? If no llc, it can never be configured.
Hmm, better if we just made it symmetrical with
s/intel_update_ring_freq/intel_enable_llc_pstate/ and
intel_disable_llc_pstate here.
Will update.

- dev_priv->pm.rps.enabled = false;
         mutex_unlock(&dev_priv->pm.pcu_lock);
  }
@@ -8080,7 +8103,10 @@ static void __intel_autoenable_gt_powersave(struct work_struct *work)
         struct intel_engine_cs *rcs;
         struct drm_i915_gem_request *req;
- if (READ_ONCE(dev_priv->pm.rps.enabled))
+       if (READ_ONCE(dev_priv->pm.rps.enabled) &&
+           READ_ONCE(dev_priv->pm.rc6.enabled) &&
+           !(HAS_LLC(dev_priv) ^
+             READ_ONCE(dev_priv->pm.llc_pstate.configured)))
                 goto out;
This optimisation has lost its appeal :)

Kill it, if we need something like it we can try again later.
-Chris
Sure. Understood that using READ_ONCE inside lock was unnecessary.
Will remove this triple condition.

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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux