Re: [Intel-gfx] [PATCH] drm/i915: Debugfs disable RPS boost and idle
Thanks for the timely reply, Daniel.
The intention to bring debugfs for RPS boost and idle is when boost and
idle are disabled, we are able to have a clear vision of what normal
turbo algorithm.
It‘s very helpful to verify if the turbo algorithm is working as
expected, at least from the VPG validation team.
Without the debugfs hooks, the RPS boost or idle may kicks in at anytime
and any circumstances, which makes it complicated.
It does not mean RPS boost and idle is doing anything wrong, that's a
different story. A fixed frequency setting is useful in some other cases
but not enough to verify turbo algorithm.
I'd like to add the purpose in commit msg if it's not clear.
On 4/25/2014 10:41 AM, Daniel Vetter wrote:
On Fri, Apr 25, 2014 at 7:29 PM, Daisy Sun wrote:
RP frequency request is affected by 2 modules: normal turbo
algorithm and RPS boost algorithm. By adding RPS boost algorithm
to the mix, the final frequency becomes relatively unpredictable.
Add a switch to enable/disable RPS boost functionality. When
disabled, RP frequency will follow the normal turbo algorithm only
This only really describes what the patch does, not why the rps boost
is a problem and why exactly we need to disable it. If you want to set
a fixed frequency then we have interfaces in sysfs for that, if the
booster does something stupid then we need to fix that.
-Daniel
Issue: VIZ-3801
Signed-off-by: Daisy Sun
---
drivers/gpu/drm/i915/i915_debugfs.c | 40 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 8 ++--
3 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1e83ae4..2077bbd 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3486,6 +3486,45 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_drop_caches_fops,
i915_drop_caches_get, i915_drop_caches_set,
"0x%08llx\n");
+static int i915_rps_disable_boost_get(void *data, u64 *val)
+{
+ struct drm_device *dev = data;
+ drm_i915_private *dev_priv = dev->dev_private;
+
+ if (INTEL_INFO(dev)->gen < 6)
+ return -ENODEV;
+
+ *val = dev_priv->rps.debugfs_disable_boost;
+
+ return 0;
+}
+
+static int i915_rps_disable_boost_set(void *data, u64 val)
+{
+ struct drm_device *dev = data;
+ drm_i915_private *dev_priv = dev->dev_private;
+ int ret;
+
+ flush_delayed_work(&dev_priv->rps.delayed_resume_work);
+
+ DRM_DEBUG_DRIVER("Setting RPS disable Boost-Idle mode to %s\n",
+val ? "on" : "off");
+
+ ret = mutex_lock_interruptible(&dev_priv->rps.hw_lock);
+ if (ret)
+ return ret;
+
+ dev_priv->rps.debugfs_disable_boost = val;
+
+ mutex_unlock(&dev_priv->rps.hw_lock);
+
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_rps_disable_boost_fops,
+ i915_rps_disable_boost_get, i915_rps_disable_boost_set,
+ "%llu\n");
+
static int
i915_max_freq_get(void *data, u64 *val)
{
@@ -3821,6 +3860,7 @@ static const struct i915_debugfs_files {
{"i915_wedged", &i915_wedged_fops},
{"i915_max_freq", &i915_max_freq_fops},
{"i915_min_freq", &i915_min_freq_fops},
+ {"i915_rps_disable_boost", &i915_rps_disable_boost_fops},
{"i915_cache_sharing", &i915_cache_sharing_fops},
{"i915_ring_stop", &i915_ring_stop_fops},
{"i915_ring_missed_irq", &i915_ring_missed_irq_fops},
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 272aa7a..9c427da 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -847,6 +847,7 @@ struct intel_gen6_power_mgmt {
int last_adj;
enum { LOW_POWER, BETWEEN, HIGH_POWER } power;
+ bool debugfs_disable_boost;
bool enabled;
struct delayed_work delayed_resume_work;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 75c1c76..6acac14 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3163,7 +3163,9 @@ void gen6_rps_idle(struct drm_i915_private *dev_priv)
struct drm_device *dev = dev_priv->dev;
mutex_lock(&dev_priv->rps.hw_lock);
- if (dev_priv->rps.enabled) {
+
+ if (dev_priv->rps.enabled
+ && !dev_priv->rps.debugfs_disable_boost) {
if (IS_VALLEYVIEW(dev))
vlv_set_rps_idle(dev_priv);
else
@@ -3178,7 +3180,9 @@ void gen6_rps_boost(struct drm_i915_private *dev_priv)
struct drm_device *dev = dev_priv->dev;
mutex_lock(&dev_priv->rps.hw_lock);
- if (dev_priv->rps.enabled) {
+
+ if (dev_priv->rps.enabled
+ && !dev_priv->rps.debugfs_disable_boost) {
if (IS_VALLEYVIEW(dev))
Re: [Intel-gfx] [PATCH v3] drm/i915: Debugfs disable RPS boost and idle
"So can you not tracepoints to give EI results for up/down signals and filter out the noise? ", Do you mean I don't need the debugfs at all? For developer, he/she is able to trace anything including the point of Turbo algorithm adjustment(+n/-n). But as a black box, validation will not see the cause but only the result. Boost / Idle function will set RP frequency to Max / Min, turbo algorithm will +n / -n depends on our implementation. My intention is to block the disturbance of Boost /Idle, then the RPS frequency change can only cause bye Turbo algorithm. - Daisy On 5/5/2014 10:51 PM, Chris Wilson wrote: On Mon, May 05, 2014 at 02:50:27PM -0700, Daisy Sun wrote: RP frequency request is affected by 2 modules: normal turbo algorithm and RPS boost algorithm. By adding RPS boost algorithm to the mix, the final frequency becomes relatively unpredictable. Add a switch to enable/disable RPS boost functionality. When disabled, RP frequency will follow the normal turbo algorithm only. Intention: when boost and idle are disabled, we have a clear vision of turbo algorithm. It‘s very helpful to verify if the turbo algorithm is working as expected. Without debugfs hooks, the RPS boost or idle may kick in at anytime and any circumstances. The algorithm is still not the same as you "intended". So can you not tracepoints to give EI results for up/down signals and filter out the noise? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bdw: Broaden FBC resolution limit to 4096x4096
Yes, the change starts from HSW. I'll update the patch.
what's the "rant" I need to insert? I was not in the list a year ago:),
having some trouble find the email as reference.
Any archives I can look into?
On 6/16/2014 11:15 AM, Daniel Vetter wrote:
On Mon, Jun 16, 2014 at 06:11:45PM +0100, Damien Lespiau wrote:
On Mon, Jun 16, 2014 at 05:52:12PM +0100, Damien Lespiau wrote:
From: Daisy Sun
Staring from BDW, the resolution limit of FBC has increased to
4096x4096>
Issue: APDEV-2935
Otc-Tracker: VIZ-3826
Change-Id: I842f64e3cf2c0d18d29ef1bcfef3b9bb1f1764ac
Signed-off-by: Daisy Sun
Reviewed-by: Damien Lespiau
Iirc 4kx4k is allowed on hsw already, albeit with the lower 2k lines being
uncompressed. Please double-check bspec and update the patch.
Also: Please insert rant here that I've written a mail a year ago about
the piles of little issues in our fbc feature checking.
-Daniel
--
Damien
---
drivers/gpu/drm/i915/intel_pm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0b088fe..8cc60fc 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -529,7 +529,10 @@ void intel_update_fbc(struct drm_device *dev)
goto out_disable;
}
- if (IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5) {
+ if (INTEL_INFO(dev)->gen >= 8) {
+ max_width = 4096;
+ max_height = 4096;
+ } else if (IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5) {
max_width = 4096;
max_height = 2048;
} else {
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bdw: Broaden FBC resolution limit to 4096x4096
IC. I started working from BDW FBC, did not check all the gens thoroughly:-) Sent out a version 2 just now. - Daisy On 6/16/2014 2:49 PM, Daniel Vetter wrote: On Mon, Jun 16, 2014 at 10:41 PM, Sun, Daisy wrote: Yes, the change starts from HSW. I'll update the patch. what's the "rant" I need to insert? I was not in the list a year ago:), having some trouble find the email as reference. Any archives I can look into? No rant to insert for you ;-) That was a placeholder in my mail, instead of boring people with all the details. Iirc that was to the internal mailing list, and could be older than a year even. Essentially there's a bunch of constraints about pixel depth and pfit usage on recent platforms that we don't quite check correctly. Your patch update to check for gen >= 8 || IS_HASWELL is perfectly fine as-is. -Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: BDW Software Turbo
GT is not going to run at a single frequency all the time actually. It starts from a single frequency, and then will dynamically adjust according to the GT utilization, either go up or down. From this perspective, SW turbo function the same as the HW turbo. For the algorithm, we did go over the design forum before implementation. What kind of improvement is expected? Please let me know if any important case is not taken into account. Thanks. - Daisy On 7/10/2014 1:32 AM, Chris Wilson wrote: On Wed, Jul 09, 2014 at 06:00:48PM -0700, Daisy Sun wrote: BDW supports GT C0 residency reporting in constant time unit. Driver calculates GT utilization based on C0 residency and adjusts RP frequency up/down accordingly. This explanation is a bit thin on the ground for why you want to run permanently at a single GPU frequency. And the algorithm looks primitive at best. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: BDW Software Turbo
This Software turbo will mainly take place of the hardware driven interrupt part without touching the boost/idle strategy. So gen6_rps_boost and gen6_rps_idle will still function for BDW. I can revise the commit message to clarify. On 7/10/2014 12:07 PM, Chris Wilson wrote: On Thu, Jul 10, 2014 at 11:42:59AM -0700, Sun, Daisy wrote: GT is not going to run at a single frequency all the time actually. It starts from a single frequency, and then will dynamically adjust according to the GT utilization, either go up or down. From this perspective, SW turbo function the same as the HW turbo. Urm, read your code again. For the algorithm, we did go over the design forum before implementation. What kind of improvement is expected? Please let me know if any important case is not taken into account. Thanks. You have no faststart or boost strategy, so typical desktop usage will feel very laggy. For a large number of use cases you never change freequency. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: BDW Software Turbo
1) The design is by no means to disable boost and idle strategy. They are every effective dealing with burst request, bring up the responsiveness. 2) The patch did disable part of gen6_set_rps_thresholds(), but gen6_set_rps is supposed to function the same as before. Would you point out the code which is suspicious to disable set_rps path? 3) The function will be called when flip happened, this should cover most of the cases. One exception is background media process without any display output, it's relatively rare. Please let me know if you have concern on other cases, I will try to cover it definitely. -Original Message- From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] Sent: Thursday, July 10, 2014 11:16 PM To: Sun, Daisy Cc: intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: BDW Software Turbo On Thu, Jul 10, 2014 at 07:39:32PM -0700, Sun, Daisy wrote: > > This Software turbo will mainly take place of the hardware driven > interrupt part without touching the boost/idle strategy. > So gen6_rps_boost and gen6_rps_idle will still function for BDW. You still are not addressing that your function is either called at a random time, and more often than not, never. You also disabled the set_rps paths which would have disabled boost and idle. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: BDW Software Turbo
Hi Daniel, Chris The concern for traditional X and media server do make sense. I'll update the patch with RP_UP_EI_INTERRUPT as trigger instead of the page flip. Thanks for the valuable input. - Daisy -Original Message- From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Monday, July 14, 2014 12:04 AM To: Sun, Daisy Cc: Chris Wilson; intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: BDW Software Turbo On Mon, Jul 14, 2014 at 8:59 AM, Daniel Vetter wrote: > On Mon, Jul 14, 2014 at 04:22:44AM +0000, Sun, Daisy wrote: >> 3) The function will be called when flip happened, this should cover >> most of the cases. One exception is background media process without >> any display output, it's relatively rare. Please let me know if you >> have concern on other cases, I will try to cover it definitely. > > Traditional X never flips. And we kinda have to keep this working. > Instead of checking when flipping we need to check at regular time > intervals I guess, for as long as the gt is busy. Oh and transcode servers are a real thing apparently. They also never flip, and we actually care from a business pov ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: BDW Software Turbo
Yes, timer can be helpful. A revised proposal is that flip trigger + timer to cover together. I'll come up with more details soon. - Daisy On 7/25/2014 12:22 AM, Daniel Vetter wrote: On Thu, Jul 24, 2014 at 01:28:21PM -0700, Jesse Barnes wrote: If that won't work, you could just use a timer, or tie into some other event that happens when the GPU is busy (e.g. execbuf or retire) instead of trying to tie into the display side of things. Yes, tying into a normal timer is probably best. At least I get the impression that we only need something regular. Of course once the gpu is idle we need to stop rearming that timer and restart it upon first batch when transitioning out of idle. -Daniel Jesse On Tue, 15 Jul 2014 06:35:20 +0000 "Sun, Daisy" wrote: Hi Daniel, Chris The concern for traditional X and media server do make sense. I'll update the patch with RP_UP_EI_INTERRUPT as trigger instead of the page flip. Thanks for the valuable input. - Daisy -Original Message- From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Monday, July 14, 2014 12:04 AM To: Sun, Daisy Cc: Chris Wilson; intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: BDW Software Turbo On Mon, Jul 14, 2014 at 8:59 AM, Daniel Vetter wrote: On Mon, Jul 14, 2014 at 04:22:44AM +, Sun, Daisy wrote: 3) The function will be called when flip happened, this should cover most of the cases. One exception is background media process without any display output, it's relatively rare. Please let me know if you have concern on other cases, I will try to cover it definitely. Traditional X never flips. And we kinda have to keep this working. Instead of checking when flipping we need to check at regular time intervals I guess, for as long as the gt is busy. Oh and transcode servers are a real thing apparently. They also never flip, and we actually care from a business pov ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: BDW Software Turbo
we have reconsidered good suggestions and evaluated performance and complexity again. Timer Constant callback would continuously wake up CPU and entire package, results in lower CPU and package C-state and shorter battery life, especially for standby time. execbuf is a good one, and we had taken it into account too. execbuf can happen much more frequent than flips. Synchronization and calculation overhead were the main reasons that we tried to avoid using too much IA resource to benefit GT. Here's is a revised version of software turbo for BDW, please take a look and see if there's any concern. For software turbo, it can be tough to find out a perfect solution , may need some trade-off. Revised design: GT busyness will still be calculated when page_flip comes in, then GT frequency will be adjusted accordingly. This point stays the same as previous design. For the cases no flip will happen(server or background task with no display activity) which is a previous concern, set GT frequency to RP0(no turbo algorithm interfered in this case). Implementation details: 1) Driver start with RP0 as GT frequency. 2) When the flip comes, do the regular software turbo busyness calculation. Also set a timer with 250ms; 3) If the flip keep coming in time, keep turbo algorithm, reset timer; 4) When the timer is fired, set RP frequency to RP0 so that the background task will still be taken care of(the RPS boost and idle need to be disabled in this situation). 5)If the flip comes again, go to 2). To recap, For most common cases, GT will run at a desired frequency as a result of software turbo algorithm; For background workloads or no flip environment, GT will be running at RP0 with shorter execution time to extend RC6 and pkg C state residency as long as power is concerned. I'll start with the implementation if all concerns are ironed out. - Daisy On 7/25/2014 12:22 AM, Daniel Vetter wrote: On Thu, Jul 24, 2014 at 01:28:21PM -0700, Jesse Barnes wrote: If that won't work, you could just use a timer, or tie into some other event that happens when the GPU is busy (e.g. execbuf or retire) instead of trying to tie into the display side of things. Yes, tying into a normal timer is probably best. At least I get the impression that we only need something regular. Of course once the gpu is idle we need to stop rearming that timer and restart it upon first batch when transitioning out of idle. -Daniel Jesse On Tue, 15 Jul 2014 06:35:20 + "Sun, Daisy" wrote: Hi Daniel, Chris The concern for traditional X and media server do make sense. I'll update the patch with RP_UP_EI_INTERRUPT as trigger instead of the page flip. Thanks for the valuable input. - Daisy -Original Message- From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Monday, July 14, 2014 12:04 AM To: Sun, Daisy Cc: Chris Wilson; intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: BDW Software Turbo On Mon, Jul 14, 2014 at 8:59 AM, Daniel Vetter wrote: On Mon, Jul 14, 2014 at 04:22:44AM +, Sun, Daisy wrote: 3) The function will be called when flip happened, this should cover most of the cases. One exception is background media process without any display output, it's relatively rare. Please let me know if you have concern on other cases, I will try to cover it definitely. Traditional X never flips. And we kinda have to keep this working. Instead of checking when flipping we need to check at regular time intervals I guess, for as long as the gt is busy. Oh and transcode servers are a real thing apparently. They also never flip, and we actually care from a business pov ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/bdw: BDW Software Turbo
The expected design is a constant timer which will trigger GT busyness
calculation steadily, I understand.
Yet the case is that we would have to wrap up BDW related works as we
mentioned with Jesse, there are not enough resources to do further
development on the constant timer scheme, sorry that I'll not able to
rework this patch.
It would be great if Linux validation could at least do some
power/performance comparison study on the current solution to settle the
concerns. We feel this proposal has minimum package C-state impact and
hopefully better performance/watt impact.
Thanks,
Daisy
On 8/11/2014 2:33 PM, Daniel Vetter wrote:
On Mon, Aug 11, 2014 at 11:08:38AM -0700, Daisy Sun wrote:
BDW supports GT C0 residency reporting in constant time unit. Driver
calculates GT utilization based on C0 residency and adjusts RP
frequency up/down accordingly. For offscreen workload specificly,
set frequency to RP0.
Offscreen task is not restricted by frame rate, it can be
executed as soon as possible. Transcoding and serilized workload
between CPU and GPU both need high GT performance, RP0 is a good
option in this case. RC6 will kick in to compensate power
consumption when GT is not active.
v2: Rebase on recent drm-intel-nightly
v3: Add flip timerout monitor, when no flip is deteced within
100ms, set frequency to RP0.
Ok, let's make this really clear:
If you wire this into the flip handling in any way, I will not merge your
patch. The timer should be fully independant and tie into the gpu
busy/idle handling we already have.
Thanks, Daniel
Signed-off-by: Daisy Sun
[torourke: rebased on latest and resolved conflict]
Signed-off-by: Tom O'Rourke
---
drivers/gpu/drm/i915/i915_drv.h | 22
drivers/gpu/drm/i915/i915_irq.c | 21
drivers/gpu/drm/i915/i915_reg.h | 4 +
drivers/gpu/drm/i915/intel_display.c | 3 +
drivers/gpu/drm/i915/intel_pm.c | 230 +--
5 files changed, 241 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ef38c3b..f1c4c5b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -915,6 +915,23 @@ struct intel_rps_ei {
u32 media_c0;
};
+struct intel_rps_bdw_cal {
+ u32 it_threshold_pct; /* interrupt, in percentage */
+ u32 eval_interval; /* evaluation interval, in us */
+ u32 last_ts;
+ u32 last_c0;
+ bool is_up;
+};
+
+struct intel_rps_bdw_turbo {
+ struct intel_rps_bdw_cal up;
+ struct intel_rps_bdw_cal down;
+ struct timer_list flip_timer;
+ u32 timeout;
+ atomic_t flip_received;
+ struct work_struct work_max_freq;
+};
+
struct intel_gen6_power_mgmt {
/* work and pm_iir are protected by dev_priv->irq_lock */
struct work_struct work;
@@ -948,6 +965,9 @@ struct intel_gen6_power_mgmt {
bool enabled;
struct delayed_work delayed_resume_work;
+ bool is_bdw_sw_turbo; /* Switch of BDW software turbo */
+ struct intel_rps_bdw_turbo sw_turbo; /* Calculate RP interrupt timing */
+
/* manual wa residency calculations */
struct intel_rps_ei up_ei, down_ei;
@@ -2703,6 +2723,8 @@ extern void intel_disable_fbc(struct drm_device *dev);
extern bool ironlake_set_drps(struct drm_device *dev, u8 val);
extern void intel_init_pch_refclk(struct drm_device *dev);
extern void gen6_set_rps(struct drm_device *dev, u8 val);
+extern void bdw_software_turbo(struct drm_device *dev);
+extern void gen8_flip_interrupt(struct drm_device *dev);
extern void valleyview_set_rps(struct drm_device *dev, u8 val);
extern void intel_set_memory_cxsr(struct drm_i915_private *dev_priv,
bool enable);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6ef9d6f..367f8e1 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1961,6 +1961,27 @@ static void i9xx_pipe_crc_irq_handler(struct drm_device
*dev, enum pipe pipe)
res1, res2);
}
+void gen8_flip_interrupt(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ if (!dev_priv->rps.is_bdw_sw_turbo)
+ return;
+
+ if(atomic_read(&dev_priv->rps.sw_turbo.flip_received)) {
+ mod_timer(&dev_priv->rps.sw_turbo.flip_timer,
+
usecs_to_jiffies(dev_priv->rps.sw_turbo.timeout) + jiffies);
+ }
+ else {
+ dev_priv->rps.sw_turbo.flip_timer.expires =
+
usecs_to_jiffies(dev_priv->rps.sw_turbo.timeout) + jiffies;
+ add_timer(&dev_priv->rps.sw_turbo.flip_timer);
+ atomic_set(&dev_priv->rps.sw_turbo.flip_received, true);
+ }
+
+ bdw_software_turbo(dev);
+}
+
/* The RPS events need forcewake, so we add them to a work queue and mask
their
*
Re: [Intel-gfx] [PATCH] drm/i915/bdw: cancel the SW turbo tasks before runtime suspending
Need to reset the flip_received flag at the end of this block, indicate
that the flip interrupt will stop working.
+ if (dev_priv->rps.is_bdw_sw_turbo) {
+ del_timer_sync(&dev_priv->rps.sw_turbo.flip_timer);
+ cancel_work_sync(&dev_priv->rps.sw_turbo.work_max_freq);
+ atomic_set(&dev_priv->rps.sw_turbo.flip_received, false);
+ }
- Daisy
On 9/5/2014 6:00 AM, Paulo Zanoni wrote:
(adding Daisy Sun to the conversation)
2014-09-04 18:07 GMT-03:00 Paulo Zanoni :
From: Paulo Zanoni
If we don't cancel them, we may end up running them while the device
is runtime suspended, which will trigger lots and lots of WARNs on
dmesg.
Regression introduced by:
commit c76bb61a71083b2d90504cc6d0dda2047c5d63ca
Author: Daisy Sun
Date: Mon Aug 11 11:08:38 2014 -0700
drm/i915/bdw: BDW Software Turbo
Testcase: igt/pm_rpm/gem-execbuf (you may have to run it a few times)
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8ff3755..4ce217b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1448,6 +1448,10 @@ static int intel_runtime_suspend(struct device *device)
* intel_mark_idle().
*/
cancel_work_sync(&dev_priv->rps.work);
+ if (dev_priv->rps.is_bdw_sw_turbo) {
+ del_timer_sync(&dev_priv->rps.sw_turbo.flip_timer);
+ cancel_work_sync(&dev_priv->rps.sw_turbo.work_max_freq);
+ }
intel_runtime_pm_disable_interrupts(dev);
ret = intel_suspend_complete(dev_priv);
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
