Re: [Intel-gfx] [PATCH v10 1/2] drm/i915/guc : Removing enable_guc_loading and enable_guc_submission module parameters

2017-11-28 Thread Sagar Arun Kamble



On 11/28/2017 1:24 AM, Sujaritha Sundaresan wrote:

We currently have two module parameters that control GuC:
"enable_guc_loading" and "enable_guc_submission". Whenever
we need submission=1, we also need loading=1.We also need
loading=1 when we want to want to verify the HuC, which
is every time we have a HuC (but all platforms with HuC
have a GuC and viceversa).

The above module parameters are being replaced by a single
enable_guc modparam.

v2: Clarifying the commit message (Anusha)

v3: Unify seq_puts messages, Re-factoring code as per review (Michal)

v4: Rebase

v5: Separating message unification into a separate patch

v6: Re-factoring code (Sagar, Michal)
 Rebase

v7: Applying review comments (Sagar)
 Rebase

v8: Change to NEEDS_GUC_FW (Chris)
 Applying review comments (Michal)
 Clarifying commit message (Joonas)

v9: Applying review comments (Michal)

v10: Introducing enable_guc modparam
 Applying review comments (Michal)

Signed-off-by: Sujaritha Sundaresan 
Cc: Daniele Ceraolo Spurio 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
Cc: Oscar Mateo 
Cc: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/i915_debugfs.c |  6 +--
  drivers/gpu/drm/i915/i915_drv.h | 12 +++--
  drivers/gpu/drm/i915/i915_gem_context.c |  4 +-
  drivers/gpu/drm/i915/i915_gem_gtt.c |  2 +-
  drivers/gpu/drm/i915/i915_irq.c |  4 +-
  drivers/gpu/drm/i915/i915_params.c  | 11 ++--
  drivers/gpu/drm/i915/i915_params.h  |  3 +-
  drivers/gpu/drm/i915/intel_guc.c|  2 +-
  drivers/gpu/drm/i915/intel_guc_log.c|  6 +--
  drivers/gpu/drm/i915/intel_uc.c | 96 
++
  10 files changed, 77 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index cb3e5aa..c12452d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2360,7 +2360,7 @@ static int i915_huc_load_status_info(struct seq_file *m, 
void *data)
struct drm_i915_private *dev_priv = node_to_i915(m->private);
struct drm_printer p;
  
-	if (!HAS_HUC_UCODE(dev_priv)) {

+   if (!HAS_HUC(dev_priv)) {
seq_puts(m, "not supported\n");
return 0;
}
@@ -2381,7 +2381,7 @@ static int i915_guc_load_status_info(struct seq_file *m, 
void *data)
struct drm_printer p;
u32 tmp, i;
  
-	if (!HAS_GUC_UCODE(dev_priv)) {

+   if (!HAS_GUC(dev_priv)) {
seq_puts(m, "not supported\n");
return 0;
}
@@ -2466,7 +2466,7 @@ static bool check_guc_submission(struct seq_file *m)
seq_printf(m, "GuC submission %s\n",
HAS_GUC(dev_priv) ?

This HAS_GUC check is not present in drm-tip. Please rebase the patch.

"not supported" :
-   HAS_GUC_SCHED(dev_priv) ?
+   NEEDS_GUC_LOAD(dev_priv) ?
"disabled" :
"failed");
return false;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2b76625..c4e1c7e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3220,10 +3220,16 @@ static inline unsigned int i915_sg_segment_size(void)
   * properties, so we have separate macros to test them.
   */
  #define HAS_GUC(dev_priv) ((dev_priv)->info.has_guc)
+#define HAS_HUC(dev_priv)  (HAS_GUC(dev_priv))
  #define HAS_GUC_CT(dev_priv)  ((dev_priv)->info.has_guc_ct)
-#define HAS_GUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
-#define HAS_GUC_SCHED(dev_priv)(HAS_GUC(dev_priv))
-#define HAS_HUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
+#define HAS_GUC_FW(dev_priv) \
+   ((dev_priv)->guc.fw.fetch_status == INTEL_UC_FIRMWARE_SUCCESS)
+#define HAS_HUC_FW(dev_priv) \
+   ((dev_priv)->huc.fw.fetch_status == INTEL_UC_FIRMWARE_SUCCESS)
+
+#define NEEDS_GUC_LOAD(dev_priv) \
+   (HAS_GUC(dev_priv) && HAS_GUC_FW(dev_priv) && \
+   (HAS_HUC_FW(dev_priv) || i915_modparams.enable_guc))

Indentation does not look right. A space needed before "(HAS_HUC_FW*"
  
  #define HAS_RESOURCE_STREAMER(dev_priv) ((dev_priv)->info.has_resource_streamer)
  
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c

index c1efbaf..f9240dd 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -316,7 +316,7 @@ static u32 default_desc_template(const struct 
drm_i915_private *i915,
 * present or not in use we still need a small bias as ring wraparound
 * at offset 0 sometimes hangs. No idea why.
 */
-   if (HAS_GUC(dev_priv) && i915_modparams.enable_guc_loading)
+   if (NEEDS_GUC_LOAD(dev_p

[Intel-gfx] [PATCH v2 0/3] drm/i915/guc: Update default GuC FW for SKL/BXT/KBL

2017-11-28 Thread Sagar Arun Kamble
With new GuC firmwares (SKL v9.33, BXT v9.29, KBL v9.39) available now
at 01.org downloads, let us update the default firmware versions.

Cc: Spotswood John A 
Cc: Anusha Srivatsa 
Cc: Michal Wajdeczko 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 

Sagar Arun Kamble (3):
  drm/i915/guc: Change default GuC FW for SKL to v9.33
  drm/i915/guc: Change default GuC FW for BXT to v9.29
  drm/i915/guc: Change default GuC FW for KBL to v9.39

 drivers/gpu/drm/i915/intel_guc_fw.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

-- 
1.9.1

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


[Intel-gfx] [PATCH v2 3/3] drm/i915/guc: Change default GuC FW for KBL to v9.39

2017-11-28 Thread Sagar Arun Kamble
This patch makes v9.39 firmware as default firmware for KBL.

Note: GuC logging control is changed with this firmware. GuC is
expecting i915 to set control bit to enable "default logging"
while using GuC action UK_LOG_ENABLE_LOGGING.
However i915 is currently not doing this because it is version
specific change and can be handled entirely in GuC. It will need
to be fixed in future firmwares.

This update includes (since v9.14):

- DCC spec changes for BXT + DCT enabling
- Bug Fix for power conservation feature SLPC_DCC
- Scheduler 1-element submission during DCC cycles.
- SB based Pre-ETM/ETM flow enabling for debug signed GuC/HuC
- Moving GuC non_critical r/w data to lower SRAM 64KB
- Media engine Reset fix.  Correctly marking context for resubmission in
  Media Reset case.
- ABT Disable bug fix. Disabled Evaluation mode on context change.
- Async FW in Engine Schedule feature (not enabled from KMD)
- GuC clean up to align developer build in line to production build.
- Disable ARAT interrupt before programming ARAT delta.
- Memory range check in Parse to avoid failure due to overflow.
- GuC Msg Channel Hang WA - Stall GUC for mmio access when IDI is low
  during CPD flow.
- Fix for submit queue over flow issue
- Enabling IBC on KBL GT3 15W, GT4 45W
- Disabling wrong device ID WA in production signed kernel
- Enabling WA for MSGCH hang issue upto required KBL stepping
- Clear forcewake in CSB when SQ is empty.
- 3Tries of GuC2CSME wake request
- During reset one parameter was not getting accounted
- Disable DCC 1-elem mode submission
- Move UkGuckmdInterface.h file from 2016 folders to common 2016 folder.
- This is file location change.No functional change done as part of this
  check in.
- Enabling Guc Log changes for ultra low logging for OCA
- Enabling Dynamic Render Power Well Hysteresis Programming for Compute
  Worklaods
- Enabling build failure check to catch critical section overflow.
- Disable build.bat redundant prints.
- Move few least used functions to non-critical section.
- Rearrange GuC documentation folder structure.
- Synchronize SLPC internal debug interface with other branches.
- Fixing Issue with Default Guc Log changes for OCA using special Control
  Bit
- Aggressive DCC implementation for supported platforms.

v2: Rebase. Updated commit message.

Signed-off-by: Jeff McGee 
Signed-off-by: Sagar Arun Kamble 
Cc: Spotswood John A 
Cc: Anusha Srivatsa 
Cc: Michal Wajdeczko 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_guc_fw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c 
b/drivers/gpu/drm/i915/intel_guc_fw.c
index df2ff96..89862fa 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -37,7 +37,7 @@
 #define BXT_FW_MINOR 29
 
 #define KBL_FW_MAJOR 9
-#define KBL_FW_MINOR 14
+#define KBL_FW_MINOR 39
 
 #define GLK_FW_MAJOR 10
 #define GLK_FW_MINOR 56
-- 
1.9.1

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


[Intel-gfx] [PATCH v2 2/3] drm/i915/guc: Change default GuC FW for BXT to v9.29

2017-11-28 Thread Sagar Arun Kamble
This patch makes v9.29 firmware as default firmware for BXT.

Note: GuC logging control is changed with this firmware. GuC is
expecting i915 to set control bit to enable "default logging"
while using GuC action UK_LOG_ENABLE_LOGGING.
However i915 is currently not doing this because it is version
specific change and can be handled entirely in GuC. It will need
to be fixed in future firmwares.

This update includes (since v8.7):

- Added support to log media reset count for host to read it
- BXT WA for fixing MTP hangs. WaDisableDOPRenderClkGatingAtSubmit
- Sub-feature level control for power management features.
- Minor clean-up for power management interface.
- Unified power management interface and scheduler interface into
  1 file using same version.
- Bug Fix for multi context scheduler flag.
- DCC spec changes for BXT + DCT enabling
- Springboard based Pre-ETM/ETM flow enabling for debug signed GuC/HuC
- Moving GuC non_critical r/w data to lower SRAM 64KB
- Enabled IBC for BXT
- Media engine Reset fix.  Correctly marking context for resubmission in
  Media Reset case.
- SLPC Dynamic RPe fix to resolve issues where incorrect frequency was set.
- ABT Disable bug fix. Disabled Evaluation mode on context change.
- GuC clean up to align developer build in line to production build.
- Disable ARAT interrupt before programming ARAT delta.
- Memory range check in Parse to avoid failure due to overflow.
- Clear forcewake in CSB when SQ is empty.
- SLPC IBC 1.6 for APL to ensure multiplier does not cap IA below Pe.
- Move UkGuckmdInterface.h file from 2016 folders to common 2016 folder.
- This is file location change. No functional change done as part of this
  check in.
- 3 tries of wake request needed from GuC2CSME for ME to wake up. Request
  has come from ME spec
- During reset one parameter was not getting accounted
- Enabling Guc Log changes for ultra low logging for OCA
- Disable build.bat redundant prints.
- Move few least used functions to non-critical section.
- Rearrange GuC documentation folder structure.
- Fixing Issue with Default Guc Log changes for OCA using special Control
  Bit

v2: Rebase. Updated commit message.

Signed-off-by: Jeff McGee 
Signed-off-by: Sagar Arun Kamble 
Cc: Spotswood John A 
Cc: Anusha Srivatsa 
Cc: Michal Wajdeczko 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_guc_fw.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c 
b/drivers/gpu/drm/i915/intel_guc_fw.c
index 631e932..df2ff96 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -33,8 +33,8 @@
 #define SKL_FW_MAJOR 9
 #define SKL_FW_MINOR 33
 
-#define BXT_FW_MAJOR 8
-#define BXT_FW_MINOR 7
+#define BXT_FW_MAJOR 9
+#define BXT_FW_MINOR 29
 
 #define KBL_FW_MAJOR 9
 #define KBL_FW_MINOR 14
-- 
1.9.1

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


[Intel-gfx] [PATCH v2 1/3] drm/i915/guc: Change default GuC FW for SKL to v9.33

2017-11-28 Thread Sagar Arun Kamble
This patch makes v9.33 firmware as default firmware for SKL.

Note: GuC logging control is changed with this firmware. GuC is
expecting i915 to set control bit to enable "default logging"
while using GuC action UK_LOG_ENABLE_LOGGING.
However i915 is currently not doing this because it is version
specific change and can be handled entirely in GuC. It will need
to be fixed in future firmwares.

This update includes (since v6.1):

- HuC RSA Keys updated.
- Adding per engine preemption support in GuC scheduler
- Minor bug fixes.
- Added support to log media reset count for host to read it
- Sub-feature level control for power management features.
- Minor clean-up for power management interface.
- Unified power management interface and scheduler interface into
  1 file using same version.
- Bug Fix for multi context scheduler flag.
- DCC spec changes for BXT + DCT enabling
- SB based Pre-ETM/ETM flow enabling for debug signed GuC/HuC
- Moving GuC non_critical r/w data to lower SRAM 64KB
- Media engine Reset fix.  Correctly marking context for resubmission in
  Media Reset case.
- ABT Disable bug fix. Disabled Evaluation mode on context change.
- Async FW in Engine Schedule feature (not enabled from KMD)
- GuC clean up to align developer build in line to production build.
- DCC consistency fix for SKL
- Disable ARAT interrupt before programming ARAT delta.
- Memory range check in Parse to avoid failure due to overflow.
- Enabled WA for MSGCH hang issue
- Clear forcewake in CSB when SQ is empty.
- Move UkGuckmdInterface.h file from 2016 folders to common 2016 folder.
- This is file location change.No functional change done as part of this
  check in.
- Enable decoupled freq for SKL GT4
- 3 tries of wake request needed from GuC2CSME for ME to wake up. Request
  has come from ME spec
- During reset one parameter was not getting accounted
- Enabling Guc Log changes for ultra low logging for OCA
- Enabling build failure check to catch critical section overflow.
- Disable build.bat redundant prints.
- Move few least used functions to non-critical section.
- Rearrange GuC documentation folder structure.
- Synchronize SLPC internal debug interface with other branches.
- Fixing Issue with Default Guc Log changes for OCA using special Control
  Bit

v2: Rebase. Updated commit message.

Signed-off-by: Jeff McGee 
Signed-off-by: Sagar Arun Kamble 
Cc: Spotswood John A 
Cc: Anusha Srivatsa 
Cc: Michal Wajdeczko 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_guc_fw.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c 
b/drivers/gpu/drm/i915/intel_guc_fw.c
index bbab4e1..631e932 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -30,8 +30,8 @@
 #include "intel_guc_fw.h"
 #include "i915_drv.h"
 
-#define SKL_FW_MAJOR 6
-#define SKL_FW_MINOR 1
+#define SKL_FW_MAJOR 9
+#define SKL_FW_MINOR 33
 
 #define BXT_FW_MAJOR 8
 #define BXT_FW_MINOR 7
-- 
1.9.1

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


Re: [Intel-gfx] [PATCH v2 0/3] drm/i915/guc: Update default GuC FW for SKL/BXT/KBL

2017-11-28 Thread Sagar Arun Kamble



On 11/29/2017 12:41 PM, Joonas Lahtinen wrote:

On Wed, 2017-11-29 at 11:47 +0530, Sagar Arun Kamble wrote:

With new GuC firmwares (SKL v9.33, BXT v9.29, KBL v9.39) available now
at 01.org downloads, let us update the default firmware versions.

I thought the agreement was for them to be at linux-firmware repo?


Sorry. I should have mentioned linux-firmware.git. They are merged there.



Regards, Joonas


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


Re: [Intel-gfx] [PATCH v4 3/4] drm/i915: Consolidate checks for engine stats availability

2017-11-29 Thread Sagar Arun Kamble



On 11/28/2017 6:34 PM, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Sagar noticed the check can be consolidated between the engine stats
implementation and the PMU.

My first choice was a static inline helper but that got into include
ordering mess quickly fast so I went with a macro instead. At some point
we should perhaps looking into taking out the non-ringubffer bits from
intel_ringbuffer.h into a new intel_engine.h or something.

v2: Use engine->flags. (Chris Wilson)
v3: Rebase and mark GuC as not yet supported. (Chris Wilson)
v4: Move flag setting to intel_engines_reset_default_submission.
 (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
Suggested-by: Sagar Arun Kamble 
Cc: Sagar Arun Kamble 
Reviewed-by: Chris Wilson  (v2)
---
  drivers/gpu/drm/i915/i915_pmu.c | 11 ---
  drivers/gpu/drm/i915/intel_engine_cs.c  |  8 +---
  drivers/gpu/drm/i915/intel_guc_submission.c |  2 ++
  drivers/gpu/drm/i915/intel_lrc.c|  2 ++
  drivers/gpu/drm/i915/intel_ringbuffer.h |  6 ++
  5 files changed, 19 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 3357b690ce90..c3c641ec962b 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -90,11 +90,6 @@ static unsigned int event_enabled_bit(struct perf_event 
*event)
return config_enabled_bit(event->attr.config);
  }
  
-static bool supports_busy_stats(struct drm_i915_private *i915)

-{
-   return INTEL_GEN(i915) >= 8;
-}
-
  static bool pmu_needs_timer(struct drm_i915_private *i915, bool gpu_active)
  {
u64 enable;
@@ -123,8 +118,10 @@ static bool pmu_needs_timer(struct drm_i915_private *i915, 
bool gpu_active)
/*
 * Also there is software busyness tracking available we do not
 * need the timer for I915_SAMPLE_BUSY counter.
+*
+* Use RCS as proxy for all engines.
 */
-   else if (supports_busy_stats(i915))
+   else if (intel_engine_supports_stats(i915->engine[RCS]))
enable &= ~BIT(I915_SAMPLE_BUSY);
  
  	/*

@@ -447,7 +444,7 @@ static void i915_pmu_event_read(struct perf_event *event)
  
  static bool engine_needs_busy_stats(struct intel_engine_cs *engine)

  {
-   return supports_busy_stats(engine->i915) &&
+   return intel_engine_supports_stats(engine) &&
   (engine->pmu.enable & BIT(I915_SAMPLE_BUSY));
  }
  
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c

index d27e124d826a..a35f8d3a55fd 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1527,8 +1527,10 @@ void intel_engines_reset_default_submission(struct 
drm_i915_private *i915)
struct intel_engine_cs *engine;
enum intel_engine_id id;
  
-	for_each_engine(engine, i915, id)

+   for_each_engine(engine, i915, id) {
engine->set_default_submission(engine);
+   engine->flags |= I915_ENGINE_SUPPORTS_STATS;
+   }
  }
  
  /**

@@ -1829,7 +1831,7 @@ int intel_enable_engine_stats(struct intel_engine_cs 
*engine)
  {
unsigned long flags;
  
-	if (INTEL_GEN(engine->i915) < 8)

+   if (!intel_engine_supports_stats(engine))
return -ENODEV;
  
  	spin_lock_irqsave(&engine->stats.lock, flags);

@@ -1890,7 +1892,7 @@ void intel_disable_engine_stats(struct intel_engine_cs 
*engine)
  {
unsigned long flags;
  
-	if (INTEL_GEN(engine->i915) < 8)

+   if (!intel_engine_supports_stats(engine))
return;
  
  	spin_lock_irqsave(&engine->stats.lock, flags);

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index cf1cc2cb6722..912ff143d531 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -1453,6 +1453,8 @@ int intel_guc_submission_enable(struct intel_guc *guc)
execlists->tasklet.func = guc_submission_tasklet;
engine->park = guc_submission_park;
engine->unpark = guc_submission_unpark;
+
+   engine->flags &= ~I915_ENGINE_SUPPORTS_STATS;
}
  
  	return 0;

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 479f880c0f2f..b811f7cddd7e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1983,6 +1983,8 @@ intel_engine_setup_execlist(struct intel_engine_cs 
*engine)
I am seeing intel_engine_init_execlist function in drm-tip. and that 
will get called for < gen 8 too so this
may not be right place. Setting it in logical_ring_setup and clearing in 
intel_init_ring_buffer is more clearer I guess.
  
  	execlists->queue = RB_ROOT;

execlists->first = NULL;
+
+   engine->flags |= I915_ENGINE_SUPPORTS_STATS;
  }
  
  static void

Re: [Intel-gfx] [PATCH v6 2/2] drm/i915: Consolidate checks for engine stats availability

2017-11-29 Thread Sagar Arun Kamble



On 11/29/2017 2:57 PM, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Sagar noticed the check can be consolidated between the engine stats
implementation and the PMU.

My first choice was a static inline helper but that got into include
ordering mess quickly fast so I went with a macro instead. At some point
we should perhaps looking into taking out the non-ringubffer bits from
intel_ringbuffer.h into a new intel_engine.h or something.

v2: Use engine->flags. (Chris Wilson)
v3: Rebase and mark GuC as not yet supported. (Chris Wilson)
v4: Move flag setting to intel_engines_reset_default_submission.
 (Chris Wilson)
v5: Move flag setting to logical_ring_setup.
v6: intel_engines_reset_default_submission is the wrong place to set the
 flag - it needs to be in execlists_set_default_submission. (Sagar)

Signed-off-by: Tvrtko Ursulin 
Suggested-by: Sagar Arun Kamble 
Cc: Sagar Arun Kamble 
Reviewed-by: Chris Wilson  (v2)


Reviewed-by: Sagar Arun Kamble 


---
  drivers/gpu/drm/i915/i915_pmu.c | 11 ---
  drivers/gpu/drm/i915/intel_engine_cs.c  |  4 ++--
  drivers/gpu/drm/i915/intel_guc_submission.c |  2 ++
  drivers/gpu/drm/i915/intel_lrc.c|  4 
  drivers/gpu/drm/i915/intel_ringbuffer.h |  6 ++
  5 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 1c0ee9d68b04..e8e2faf4982f 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -90,11 +90,6 @@ static unsigned int event_enabled_bit(struct perf_event 
*event)
return config_enabled_bit(event->attr.config);
  }
  
-static bool supports_busy_stats(struct drm_i915_private *i915)

-{
-   return INTEL_GEN(i915) >= 8;
-}
-
  static bool pmu_needs_timer(struct drm_i915_private *i915, bool gpu_active)
  {
u64 enable;
@@ -123,8 +118,10 @@ static bool pmu_needs_timer(struct drm_i915_private *i915, 
bool gpu_active)
/*
 * Also there is software busyness tracking available we do not
 * need the timer for I915_SAMPLE_BUSY counter.
+*
+* Use RCS as proxy for all engines.
 */
-   else if (supports_busy_stats(i915))
+   else if (intel_engine_supports_stats(i915->engine[RCS]))
enable &= ~BIT(I915_SAMPLE_BUSY);
  
  	/*

@@ -447,7 +444,7 @@ static void i915_pmu_event_read(struct perf_event *event)
  
  static bool engine_needs_busy_stats(struct intel_engine_cs *engine)

  {
-   return supports_busy_stats(engine->i915) &&
+   return intel_engine_supports_stats(engine) &&
   (engine->pmu.enable & BIT(I915_SAMPLE_BUSY));
  }
  
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c

index fede62daf3e1..cffd0c812b7e 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1863,7 +1863,7 @@ int intel_enable_engine_stats(struct intel_engine_cs 
*engine)
  {
unsigned long flags;
  
-	if (INTEL_GEN(engine->i915) < 8)

+   if (!intel_engine_supports_stats(engine))
return -ENODEV;
  
  	spin_lock_irqsave(&engine->stats.lock, flags);

@@ -1924,7 +1924,7 @@ void intel_disable_engine_stats(struct intel_engine_cs 
*engine)
  {
unsigned long flags;
  
-	if (INTEL_GEN(engine->i915) < 8)

+   if (!intel_engine_supports_stats(engine))
return;
  
  	spin_lock_irqsave(&engine->stats.lock, flags);

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index cf1cc2cb6722..912ff143d531 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -1453,6 +1453,8 @@ int intel_guc_submission_enable(struct intel_guc *guc)
execlists->tasklet.func = guc_submission_tasklet;
engine->park = guc_submission_park;
engine->unpark = guc_submission_unpark;
+
+   engine->flags &= ~I915_ENGINE_SUPPORTS_STATS;
}
  
  	return 0;

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 570864583e28..ef513e1c10f3 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1919,6 +1919,8 @@ static void execlists_set_default_submission(struct 
intel_engine_cs *engine)
  
  	engine->park = NULL;

engine->unpark = NULL;
+
+   engine->flags |= I915_ENGINE_SUPPORTS_STATS;
  }
  
  static void

@@ -1963,6 +1965,8 @@ logical_ring_setup(struct intel_engine_cs *engine)
/* Intentionally left blank. */
engine->buffer = NULL;
  
+	engine->flags |= I915_ENGINE_SUPPORTS_STATS;

+
fw_domains = intel_uncore_forcewake_for_reg(dev_priv,
RING_ELSP(engine),
FW_REG_WRITE);
di

Re: [Intel-gfx] [PATCH] drm/i915: Unifying debugfs return codes for unsupported features

2017-11-29 Thread Sagar Arun Kamble



On 11/28/2017 9:12 PM, Michal Wajdeczko wrote:

Instead of trying different seq_puts messages, lets use common
-ENODEV error code to indicate missing/unsupported feature.

Suggested-by: Chris Wilson 
Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Sagar Arun Kamble 
Cc: Sujaritha Sundaresan 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 47 ++---
  1 file changed, 23 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2829447..5023acd 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1635,10 +1635,8 @@ static int i915_fbc_status(struct seq_file *m, void 
*unused)
  {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
  
-	if (!HAS_FBC(dev_priv)) {

-   seq_puts(m, "FBC unsupported on this chipset\n");
-   return 0;
-   }
+   if (!HAS_FBC(dev_priv))
+   return -ENODEV;
  
  	intel_runtime_pm_get(dev_priv);

mutex_lock(&dev_priv->fbc.lock);
@@ -1714,10 +1712,8 @@ static int i915_ips_status(struct seq_file *m, void 
*unused)
  {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
  
-	if (!HAS_IPS(dev_priv)) {

-   seq_puts(m, "not supported\n");
-   return 0;
-   }
+   if (!HAS_IPS(dev_priv))
+   return -ENODEV;
  
  	intel_runtime_pm_get(dev_priv);
  
@@ -1803,10 +1799,8 @@ static int i915_ring_freq_table(struct seq_file *m, void *unused)

int gpu_freq, ia_freq;
unsigned int max_gpu_freq, min_gpu_freq;
  
-	if (!HAS_LLC(dev_priv)) {

-   seq_puts(m, "unsupported on this chipset\n");
-   return 0;
-   }
+   if (!HAS_LLC(dev_priv))
+   return -ENODEV;
  
  	intel_runtime_pm_get(dev_priv);
  
@@ -2287,7 +2281,7 @@ static int i915_huc_load_status_info(struct seq_file *m, void *data)

struct drm_printer p;
  
  	if (!HAS_HUC_UCODE(dev_priv))

-   return 0;
+   return -ENODEV;
  
  	p = drm_seq_file_printer(m);

intel_uc_fw_dump(&dev_priv->huc.fw, &p);
@@ -2305,8 +2299,8 @@ static int i915_guc_load_status_info(struct seq_file *m, 
void *data)
struct drm_printer p;
u32 tmp, i;
  
-	if (!HAS_GUC_UCODE(dev_priv))

-   return 0;
+   if (!HAS_GUC(dev_priv))
+   return -ENODEV;
  
  	p = drm_seq_file_printer(m);

intel_uc_fw_dump(&dev_priv->guc.fw, &p);
@@ -2400,6 +2394,9 @@ static int i915_guc_info(struct seq_file *m, void *data)
struct drm_i915_private *dev_priv = node_to_i915(m->private);
const struct intel_guc *guc = &dev_priv->guc;
  
+	if (!HAS_GUC(dev_priv))

+   return -ENODEV;
+
if (!check_guc_submission(m))
Should this function check_guc_submission be updated in this patch with 
proper message now?

Should we add HAS_GUC check to i915_guc_log_control_get as well?

return 0;
  
@@ -2428,6 +2425,9 @@ static int i915_guc_stage_pool(struct seq_file *m, void *data)

unsigned int tmp;
int index;
  
+	if (!HAS_GUC(dev_priv))

+   return -ENODEV;
+
if (!check_guc_submission(m))
return 0;
  
@@ -2482,6 +2482,9 @@ static int i915_guc_log_dump(struct seq_file *m, void *data)

u32 *log;
int i = 0;
  
+	if (!HAS_GUC(dev_priv))

+   return -ENODEV;
+
if (dump_load_err)
obj = dev_priv->guc.load_err_log;
else if (dev_priv->guc.log.vma)
@@ -2576,10 +2579,8 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
enum pipe pipe;
bool enabled = false;
  
-	if (!HAS_PSR(dev_priv)) {

-   seq_puts(m, "PSR not supported\n");
-   return 0;
-   }
+   if (!HAS_PSR(dev_priv))
+   return -ENODEV;
  
  	intel_runtime_pm_get(dev_priv);
  
@@ -2818,10 +2819,8 @@ static int i915_dmc_info(struct seq_file *m, void *unused)

struct drm_i915_private *dev_priv = node_to_i915(m->private);
struct intel_csr *csr;
  
-	if (!HAS_CSR(dev_priv)) {

-   seq_puts(m, "not supported\n");
-   return 0;
-   }
+   if (!HAS_CSR(dev_priv))
+   return -ENODEV;
  
  	csr = &dev_priv->csr;
  
@@ -3357,7 +3356,7 @@ static int i915_ddb_info(struct seq_file *m, void *unused)

int plane;
  
  	if (INTEL_GEN(dev_priv) < 9)

-   return 0;
+   return -ENODEV;
  
  	drm_modeset_lock_all(dev);
  


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


Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Impletments dynamic WOPCM partitioning.

2017-11-29 Thread Sagar Arun Kamble



On 11/29/2017 6:31 AM, Yaodong Li wrote:

On 11/16/2017 08:00 PM, Sagar Arun Kamble wrote:



On 11/17/2017 3:17 AM, Michal Wajdeczko wrote:
On Thu, 16 Nov 2017 08:34:01 +0100, Sagar Arun Kamble 
 wrote:



Typo in the subject.
GLK showing failure to load GuC with this approach on CI.

On 11/15/2017 10:47 PM, Jackie Li wrote:

Static WOPCM partitioning will lead to GuC loading failure
if the GuC/HuC firmware size exceeded current static 512KB
partition boundary.

This patch enables the dynamical calculation of the WOPCM aperture
used by GuC/HuC firmware. GuC WOPCM offset is  set to
HuC size + reserved WOPCM size. GuC WOPCM size is set to
total WOPCM size - GuC WOPCM offset - RC6CTX size. In this case,
GuC WOPCM offset will be updated based on the size of HuC firmware
while GuC WOPCM size will be set to use all the remaining WOPCM 
space.


v2:
  - Removed intel_wopcm_init (Ville/Sagar/Joonas)
  - Renamed and Moved the intel_wopcm_partition into intel_guc 
(Sagar)

  - Removed unnecessary function calls (Joonas)
  - Init GuC WOPCM partition as soon as firmware fetching is 
completed


Signed-off-by: Jackie Li 



+    err = do_wopcm_partition(i915, offset + huc_size, reserved);
+    if (err) {
+    if (!huc_size)
+    goto fail;
+
+    /* Partition without loading HuC FW. */
+    err = do_wopcm_partition(i915, offset, reserved);
+    if (err)
+    goto fail;
+    }
+
+    /*
+ * Check hardware restriction on Gen9
+ * GuC WOPCM size is at least 4 bytes larger than GuC WOPCM 
base due

+ * to hardware limitation on Gen9.
+ */
+    if (IS_GEN9(i915)) {
+    wopcm_base = wp->offset + GEN9_GUC_WOPCM_OFFSET;
+    if (unlikely(wopcm_base > wp->size))
+    goto fail;
+
+    delta = wp->size - wopcm_base;
+    if (unlikely(delta < GEN9_GUC_WOPCM_DELTA))
+    goto fail;
+    }
+
+    if (guc_fw->fetch_status == INTEL_UC_FIRMWARE_SUCCESS) {
+    guc_size = guc_fw->header_size + guc_fw->ucode_size;
+    /* Need 8K stack for GuC */
+    guc_size += GUC_WOPCM_STACK_RESERVED;
+    }
+
+    if (guc_size > wp->size)
+    goto fail;
+
+    DRM_DEBUG_DRIVER("GuC WOPCM offset %dKB, size %dKB, top %dKB\n",
+    wp->offset >> 10, wp->size >> 10, wp->top >> 10);
+
+    return;
+
+fail:
+    DRM_ERROR("WOPCM partitioning failed. Falling back to 
execlist mode\n");

+
+    intel_uc_fini_fw(i915);
This is correct but should be handled from intel_uc_init_fw with this 
function returning status.

it's a good idea. I will do it.

Something like this will be good

diff --git a/drivers/gpu/drm/i915/intel_uc.c 
b/drivers/gpu/drm/i915/intel_uc.c

index 1e2a30a..04c45d0 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -90,6 +90,15 @@ void intel_uc_init_fw(struct drm_i915_private *dev_priv)
 {
    intel_uc_fw_fetch(dev_priv, &dev_priv->huc.fw);
    intel_uc_fw_fetch(dev_priv, &dev_priv->guc.fw);
+
+   ret = intel_uc_init_wopcm_partition(dev_priv);
+   if (ret) {
+   intel_uc_fw_fini(&dev_priv->guc.fw);
+   intel_uc_fw_fini(&dev_priv->huc.fw);
+   i915_modparams.enable_guc_loading = 0;
+   i915_modparams.enable_guc_submission = 0;
+   i915_modparams.guc_log_level = -1;
+   }
 }
+    /* GuC submission won't work without valid GuC WOPCM 
partition */

+    if (i915_modparams.enable_guc_submission)
+    i915_modparams.enable_guc_submission = 0;
+
+    i915_modparams.enable_guc_loading = 0;
+}
This sanitization will be handled by intel_guc_fw_upload during 
intel_uc_init_hw so not needed.

It's too late to do it until intel_uc_init_hw.

Yes. Let us not do wopcm_init in uc_init_hw as wopcm_init is one time task.
This modparam update is correct.

what I wanted to guarantee here was guc submission
would be disabled as long as the partitioning failed, so that we won't 
need to allocate the kernel
context above guc wopcm top. we sure can ignore the partitioning 
failure can continue allocating
the context above guc wopcm top, but the problem is we don't have a 
valid guc wopcm top value
if the partitioning was failed. another benefit to disable the guc 
here is we won't even bother to call
down into the logics in intel_uc_init_hw since we've already known for 
sure. I cannot enable guc

submission on the partitioning failure.

Agree.

+
  void intel_uc_init_fw(struct drm_i915_private *dev_priv)
  {
  intel_uc_fw_fetch(dev_priv, &dev_priv->huc.fw);
  intel_uc_fw_fetch(dev_priv, &dev_priv->guc.fw);
+    guc_init_wopcm_partition(dev_priv);
Create intel_uc_init_wopcm_partition(dev_priv) and call 
intel_guc_init_wopcm_partition(guc) from there.


hmm, I'm not sure what benefit you expect from this call chain ?

wanted to avoid firmware specific calls from here but I w

Re: [Intel-gfx] [PATCH v10 1/2] drm/i915/guc : Removing enable_guc_loading and enable_guc_submission module parameters

2017-11-29 Thread Sagar Arun Kamble



On 11/29/2017 5:44 PM, Michal Wajdeczko wrote:
On Tue, 28 Nov 2017 11:41:57 +0100, Sagar Arun Kamble 
 wrote:





On 11/28/2017 1:24 AM, Sujaritha Sundaresan wrote:

We currently have two module parameters that control GuC:
"enable_guc_loading" and "enable_guc_submission". Whenever
we need submission=1, we also need loading=1.We also need
loading=1 when we want to want to verify the HuC, which
is every time we have a HuC (but all platforms with HuC
have a GuC and viceversa).






+
+    /* Making sure that our auto is well defined */
+    GEM_BUG_ON(auto_enable_guc < 0);
+    GEM_BUG_ON((auto_enable_guc > 0) && !HAS_GUC_FW(dev_priv));
+    GEM_BUG_ON((auto_enable_guc & 2) && !HAS_HUC_FW(dev_priv));
+
+    if (i915_modparams.enable_guc < 0)
+    i915_modparams.enable_guc = auto_enable_guc;
+
+    if (i915_modparams.enable_guc > 0) {
+    if (!HAS_GUC(dev_priv) || !HAS_GUC_FW(dev_priv)) {
+    DRM_INFO("Ignoring option enable_guc=%d - %s\n",
+ i915_modparams.enable_guc,
+ !HAS_GUC(dev_priv) ? "no GuC hardware" :
+ "no GuC firmware");
+    i915_modparams.enable_guc = 0;
+    }
  }
  -    /* A negative value means "use platform default" */
-    if (i915_modparams.enable_guc_loading < 0)
-    i915_modparams.enable_guc_loading = HAS_GUC_UCODE(dev_priv);
-
-    /* Verify firmware version */
-    if (i915_modparams.enable_guc_loading) {
-    if (HAS_HUC_UCODE(dev_priv))
-    intel_huc_select_fw(&dev_priv->huc);
-
-    if (intel_guc_fw_select(&dev_priv->guc))
-    i915_modparams.enable_guc_loading = 0;
+    if (i915_modparams.enable_guc & 2) {
+    if (!HAS_HUC_FW(dev_priv)) {
+    DRM_INFO("Ignoring option enable_guc=%d - %s\n",
+    i915_modparams.enable_guc, "no HuC firmware");
+    i915_modparams.enable_guc = 0;
Clearing only HuC status from enable_guc would be proper I guess. 
Sorry I did not see this earlier.


My understanding is that if user had specified non-zero positive value of
'enable_guc' then it means that he requests *all* GuC options to be 
available
(something like our old '2=required' mode). If any of required option 
is not

available then we should not try to cherry-pick/drop single option.
I think we wanted to enable HuC for some platforms but not enable GuC 
submission. Anusha can you

please confirm if such cherry-picking is needed through module parameter.


Note that if user don't care about specific option, then user should 
use -1(auto)
mode and rely on driver decision what is available and in which 
configuration.
And for 'auto' mode we try to make sure to do not select broken 
configurations.
In that case we can just have 3 values for enable_guc (if cherry-picking 
is not to be done)

-1: auto (whatever is available)
0: all disabled
1: all enabled if available else all disabled


Michal


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


[Intel-gfx] [PATCH v2 0/3] drm/i915/guc: Update default GuC FW for SKL/BXT/KBL

2017-11-29 Thread Sagar Arun Kamble
With new GuC firmwares (SKL v9.33, BXT v9.29, KBL v9.39) merged now
in linux-firmware.git, let us update the default firmware versions.

Cc: Spotswood John A 
Cc: Anusha Srivatsa 
Cc: Michal Wajdeczko 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 

Sagar Arun Kamble (3):
  drm/i915/guc: Change default GuC FW for SKL to v9.33
  drm/i915/guc: Change default GuC FW for BXT to v9.29
  drm/i915/guc: Change default GuC FW for KBL to v9.39

 drivers/gpu/drm/i915/intel_guc_fw.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

-- 
1.9.1

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


[Intel-gfx] [PATCH v2 1/3] drm/i915/guc: Change default GuC FW for SKL to v9.33

2017-11-29 Thread Sagar Arun Kamble
This patch makes v9.33 firmware as default firmware for SKL.

Note: GuC logging control is changed with this firmware. GuC is
expecting i915 to set control bit to enable "default logging"
while using GuC action UK_LOG_ENABLE_LOGGING.
However i915 is currently not doing this because it is version
specific change and can be handled entirely in GuC. It will need
to be fixed in future firmwares.

This update includes (since v6.1):

- HuC RSA Keys updated.
- Adding per engine preemption support in GuC scheduler
- Minor bug fixes.
- Added support to log media reset count for host to read it
- Sub-feature level control for power management features.
- Minor clean-up for power management interface.
- Unified power management interface and scheduler interface into
  1 file using same version.
- Bug Fix for multi context scheduler flag.
- DCC spec changes for BXT + DCT enabling
- SB based Pre-ETM/ETM flow enabling for debug signed GuC/HuC
- Moving GuC non_critical r/w data to lower SRAM 64KB
- Media engine Reset fix.  Correctly marking context for resubmission in
  Media Reset case.
- ABT Disable bug fix. Disabled Evaluation mode on context change.
- Async FW in Engine Schedule feature (not enabled from KMD)
- GuC clean up to align developer build in line to production build.
- DCC consistency fix for SKL
- Disable ARAT interrupt before programming ARAT delta.
- Memory range check in Parse to avoid failure due to overflow.
- Enabled WA for MSGCH hang issue
- Clear forcewake in CSB when SQ is empty.
- Move UkGuckmdInterface.h file from 2016 folders to common 2016 folder.
- This is file location change.No functional change done as part of this
  check in.
- Enable decoupled freq for SKL GT4
- 3 tries of wake request needed from GuC2CSME for ME to wake up. Request
  has come from ME spec
- During reset one parameter was not getting accounted
- Enabling Guc Log changes for ultra low logging for OCA
- Enabling build failure check to catch critical section overflow.
- Disable build.bat redundant prints.
- Move few least used functions to non-critical section.
- Rearrange GuC documentation folder structure.
- Synchronize SLPC internal debug interface with other branches.
- Fixing Issue with Default Guc Log changes for OCA using special Control
  Bit

v2: Rebase. Updated commit message.

Signed-off-by: Jeff McGee 
Signed-off-by: Sagar Arun Kamble 
Cc: Spotswood John A 
Cc: Anusha Srivatsa 
Cc: Michal Wajdeczko 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_guc_fw.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c 
b/drivers/gpu/drm/i915/intel_guc_fw.c
index bbab4e1..631e932 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -30,8 +30,8 @@
 #include "intel_guc_fw.h"
 #include "i915_drv.h"
 
-#define SKL_FW_MAJOR 6
-#define SKL_FW_MINOR 1
+#define SKL_FW_MAJOR 9
+#define SKL_FW_MINOR 33
 
 #define BXT_FW_MAJOR 8
 #define BXT_FW_MINOR 7
-- 
1.9.1

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


[Intel-gfx] [PATCH v2 3/3] drm/i915/guc: Change default GuC FW for KBL to v9.39

2017-11-29 Thread Sagar Arun Kamble
This patch makes v9.39 firmware as default firmware for KBL.

Note: GuC logging control is changed with this firmware. GuC is
expecting i915 to set control bit to enable "default logging"
while using GuC action UK_LOG_ENABLE_LOGGING.
However i915 is currently not doing this because it is version
specific change and can be handled entirely in GuC. It will need
to be fixed in future firmwares.

This update includes (since v9.14):

- DCC spec changes for BXT + DCT enabling
- Bug Fix for power conservation feature SLPC_DCC
- Scheduler 1-element submission during DCC cycles.
- SB based Pre-ETM/ETM flow enabling for debug signed GuC/HuC
- Moving GuC non_critical r/w data to lower SRAM 64KB
- Media engine Reset fix.  Correctly marking context for resubmission in
  Media Reset case.
- ABT Disable bug fix. Disabled Evaluation mode on context change.
- Async FW in Engine Schedule feature (not enabled from KMD)
- GuC clean up to align developer build in line to production build.
- Disable ARAT interrupt before programming ARAT delta.
- Memory range check in Parse to avoid failure due to overflow.
- GuC Msg Channel Hang WA - Stall GUC for mmio access when IDI is low
  during CPD flow.
- Fix for submit queue over flow issue
- Enabling IBC on KBL GT3 15W, GT4 45W
- Disabling wrong device ID WA in production signed kernel
- Enabling WA for MSGCH hang issue upto required KBL stepping
- Clear forcewake in CSB when SQ is empty.
- 3Tries of GuC2CSME wake request
- During reset one parameter was not getting accounted
- Disable DCC 1-elem mode submission
- Move UkGuckmdInterface.h file from 2016 folders to common 2016 folder.
- This is file location change.No functional change done as part of this
  check in.
- Enabling Guc Log changes for ultra low logging for OCA
- Enabling Dynamic Render Power Well Hysteresis Programming for Compute
  Worklaods
- Enabling build failure check to catch critical section overflow.
- Disable build.bat redundant prints.
- Move few least used functions to non-critical section.
- Rearrange GuC documentation folder structure.
- Synchronize SLPC internal debug interface with other branches.
- Fixing Issue with Default Guc Log changes for OCA using special Control
  Bit
- Aggressive DCC implementation for supported platforms.

v2: Rebase. Updated commit message.

Signed-off-by: Jeff McGee 
Signed-off-by: Sagar Arun Kamble 
Cc: Spotswood John A 
Cc: Anusha Srivatsa 
Cc: Michal Wajdeczko 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_guc_fw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c 
b/drivers/gpu/drm/i915/intel_guc_fw.c
index df2ff96..89862fa 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -37,7 +37,7 @@
 #define BXT_FW_MINOR 29
 
 #define KBL_FW_MAJOR 9
-#define KBL_FW_MINOR 14
+#define KBL_FW_MINOR 39
 
 #define GLK_FW_MAJOR 10
 #define GLK_FW_MINOR 56
-- 
1.9.1

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


[Intel-gfx] [PATCH v2 2/3] drm/i915/guc: Change default GuC FW for BXT to v9.29

2017-11-29 Thread Sagar Arun Kamble
This patch makes v9.29 firmware as default firmware for BXT.

Note: GuC logging control is changed with this firmware. GuC is
expecting i915 to set control bit to enable "default logging"
while using GuC action UK_LOG_ENABLE_LOGGING.
However i915 is currently not doing this because it is version
specific change and can be handled entirely in GuC. It will need
to be fixed in future firmwares.

This update includes (since v8.7):

- Added support to log media reset count for host to read it
- BXT WA for fixing MTP hangs. WaDisableDOPRenderClkGatingAtSubmit
- Sub-feature level control for power management features.
- Minor clean-up for power management interface.
- Unified power management interface and scheduler interface into
  1 file using same version.
- Bug Fix for multi context scheduler flag.
- DCC spec changes for BXT + DCT enabling
- Springboard based Pre-ETM/ETM flow enabling for debug signed GuC/HuC
- Moving GuC non_critical r/w data to lower SRAM 64KB
- Enabled IBC for BXT
- Media engine Reset fix.  Correctly marking context for resubmission in
  Media Reset case.
- SLPC Dynamic RPe fix to resolve issues where incorrect frequency was set.
- ABT Disable bug fix. Disabled Evaluation mode on context change.
- GuC clean up to align developer build in line to production build.
- Disable ARAT interrupt before programming ARAT delta.
- Memory range check in Parse to avoid failure due to overflow.
- Clear forcewake in CSB when SQ is empty.
- SLPC IBC 1.6 for APL to ensure multiplier does not cap IA below Pe.
- Move UkGuckmdInterface.h file from 2016 folders to common 2016 folder.
- This is file location change. No functional change done as part of this
  check in.
- 3 tries of wake request needed from GuC2CSME for ME to wake up. Request
  has come from ME spec
- During reset one parameter was not getting accounted
- Enabling Guc Log changes for ultra low logging for OCA
- Disable build.bat redundant prints.
- Move few least used functions to non-critical section.
- Rearrange GuC documentation folder structure.
- Fixing Issue with Default Guc Log changes for OCA using special Control
  Bit

v2: Rebase. Updated commit message.

Signed-off-by: Jeff McGee 
Signed-off-by: Sagar Arun Kamble 
Cc: Spotswood John A 
Cc: Anusha Srivatsa 
Cc: Michal Wajdeczko 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_guc_fw.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c 
b/drivers/gpu/drm/i915/intel_guc_fw.c
index 631e932..df2ff96 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -33,8 +33,8 @@
 #define SKL_FW_MAJOR 9
 #define SKL_FW_MINOR 33
 
-#define BXT_FW_MAJOR 8
-#define BXT_FW_MINOR 7
+#define BXT_FW_MAJOR 9
+#define BXT_FW_MINOR 29
 
 #define KBL_FW_MAJOR 9
 #define KBL_FW_MINOR 14
-- 
1.9.1

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


Re: [Intel-gfx] [PATCH v3] drm/i915: Use exponential backoff for wait_for()

2017-11-29 Thread Sagar Arun Kamble



On 11/30/2017 8:34 AM, John Harrison wrote:

On 11/24/2017 6:12 AM, Chris Wilson wrote:

Quoting Michał Winiarski (2017-11-24 12:37:56)

Since we see the effects for GuC preeption, let's gather some evidence.

(SKL)
intel_guc_send_mmio latency: 100 rounds of gem_exec_latency --r '*-preemption'

drm-tip:
  usecs   : count distribution
  0 -> 1  : 0||
  2 -> 3  : 0||
  4 -> 7  : 0||
  8 -> 15 : 44   ||
 16 -> 31 : 1088 ||
 32 -> 63 : 832  ||
 64 -> 127: 0||
128 -> 255: 0||
256 -> 511: 12   ||
512 -> 1023   : 0||
   1024 -> 2047   : 29899|*   |
   2048 -> 4095   : 131033   ||

Such pretty graphs. Reminds me of the bpf hist output, I wonder if we
could create a tracepoint/kprobe that would output a histogram for each
waiter (filterable ofc). Benefit? Just thinking of tuning the
spin/sleep, in which case overall metrics are best
(intel_eait_for_register needs to be optimised for the typical case). I
am wondering if we could tune the spin period down to 5us, 2us? And then
have the 10us sleep.

We would also need a typical workload to run, it's profile-guided
optimisation after all. Hmm.
-Chris


It took me a while to get back to this but I've now had chance to run 
with this exponential backoff scheme on the original system that 
showed the problem. It was a slightly messy back port due to the 
customer tree being much older than current nightly. I'm pretty sure I 
got it correct though. However, I'm not sure what the recommendation 
is for the two timeout values. Using the default of '10, 10' in the 
patch, I still get lots of very long delays. 
Recommended setting currently is Wmin=10, Wmax=10 for wait_for_us and 
Wmin=10, Wmax=1000 for wait_for.


Exponential backoff is more helpful inside wait_for if wait_for_us prior 
to wait_for is smaller.
Setting Wmax less than Wmin is effectively changing the backoff strategy 
to just linear waits of Wmin.
I have to up the Wmin value to at least 140 to get a stall free 
result. Which is plausible given that the big spike in the results of 
any fast version is at 110-150us. Also of note is that a Wmin between 
10 and 110 actually makes things worse. Changing Wmax has no effect.


In the following table, 'original' is the original driver before any 
changes and 'retry loop' is the version using the first workaround of 
just running the busy poll wait in a 10x loop. The other columns are 
using the backoff patch with the given Wmin/Wmax values. Note that the 
times are bucketed to 10us up to 500us and then in 500us lumps 
thereafter. The value listed is the lower limit, i.e. there were no 
times of <10us measured. Each case was run for 1000 samples.


Below setting like in current nightly will suit this workload and as you 
have found this will also likely complete most waits in <150us.
If many samples had been beyond 160us and less than 300us we might have 
been needed to change Wmin to may be 15 or 20 to ensure the

exponential rise caps around 300us.

wait_for_us(10, 10)
wait_for()

#define wait_for _wait_for(10, 1000)

    Time    Original    10/10 50/10 100/10    110/10    
130/10    140/10  RetryLoop
    10us:  2 2 2 2 2 2 
2 2

    30us:  1 1 1 1 1
    50us:  1
    70us: 14    63 56    64    
63    61
    80us:  8    41 52    44    
46    41
    90us:  6    24 10    28    
12    17
   100us:    2 4    20 16    17    
17    22
   110us:   13 21    14    
13    11
   120us:  6   366 633   636   
660   650
   130us:    2 2    46 125    
95    86    95
   140us:    3 2    16 18    32    
46    48
   150us:  210 3    12 13    37    
32    31
   160us:  322 1    18 10    14    
12    17
   170us:  157 4 5 5 3 
5 2
   180us:

Re: [Intel-gfx] [PATCH v3] drm/i915: Use exponential backoff for wait_for()

2017-11-29 Thread Sagar Arun Kamble



On 11/30/2017 12:45 PM, John Harrison wrote:

On 11/29/2017 10:19 PM, Sagar Arun Kamble wrote:

On 11/30/2017 8:34 AM, John Harrison wrote:

On 11/24/2017 6:12 AM, Chris Wilson wrote:

Quoting Michał Winiarski (2017-11-24 12:37:56)

Since we see the effects for GuC preeption, let's gather some evidence.

(SKL)
intel_guc_send_mmio latency: 100 rounds of gem_exec_latency --r '*-preemption'

drm-tip:
  usecs   : count distribution
  0 -> 1  : 0||
  2 -> 3  : 0||
  4 -> 7  : 0||
  8 -> 15 : 44   ||
 16 -> 31 : 1088 ||
 32 -> 63 : 832  ||
 64 -> 127: 0||
128 -> 255: 0||
256 -> 511: 12   ||
512 -> 1023   : 0||
   1024 -> 2047   : 29899|*   |
   2048 -> 4095   : 131033   ||

Such pretty graphs. Reminds me of the bpf hist output, I wonder if we
could create a tracepoint/kprobe that would output a histogram for each
waiter (filterable ofc). Benefit? Just thinking of tuning the
spin/sleep, in which case overall metrics are best
(intel_eait_for_register needs to be optimised for the typical case). I
am wondering if we could tune the spin period down to 5us, 2us? And then
have the 10us sleep.

We would also need a typical workload to run, it's profile-guided
optimisation after all. Hmm.
-Chris


It took me a while to get back to this but I've now had chance to 
run with this exponential backoff scheme on the original system that 
showed the problem. It was a slightly messy back port due to the 
customer tree being much older than current nightly. I'm pretty sure 
I got it correct though. However, I'm not sure what the 
recommendation is for the two timeout values. Using the default of 
'10, 10' in the patch, I still get lots of very long delays. 
Recommended setting currently is Wmin=10, Wmax=10 for wait_for_us and 
Wmin=10, Wmax=1000 for wait_for.


Exponential backoff is more helpful inside wait_for if wait_for_us 
prior to wait_for is smaller.
Setting Wmax less than Wmin is effectively changing the backoff 
strategy to just linear waits of Wmin.
I have to up the Wmin value to at least 140 to get a stall free 
result. Which is plausible given that the big spike in the results 
of any fast version is at 110-150us. Also of note is that a Wmin 
between 10 and 110 actually makes things worse. Changing Wmax has no 
effect.


In the following table, 'original' is the original driver before any 
changes and 'retry loop' is the version using the first workaround 
of just running the busy poll wait in a 10x loop. The other columns 
are using the backoff patch with the given Wmin/Wmax values. Note 
that the times are bucketed to 10us up to 500us and then in 500us 
lumps thereafter. The value listed is the lower limit, i.e. there 
were no times of <10us measured. Each case was run for 1000 samples.


Below setting like in current nightly will suit this workload and as 
you have found this will also likely complete most waits in <150us.
If many samples had been beyond 160us and less than 300us we might 
have been needed to change Wmin to may be 15 or 20 to ensure the

exponential rise caps around 300us.

wait_for_us(10, 10)
wait_for()

#define wait_for _wait_for(10, 1000)

But as shown in the table, a setting of 10/10 does not work well for 
this workload. The best results possible are a large spike of waits in 
the 120-130us bucket with a small tail out to 150us. Whereas, the 
10/10 setting produces a spike from 150-170us with the tail extending 
to 240us and an appreciable number of samples stretching all the way 
out to the 1-10ms range. A regular delay of multiple milliseconds is 
not acceptable when this path is supposed to be a low latency 
pre-emption to switch to some super high priority time critical task. 
And as noted, I did try a bunch of different settings for Wmax but 
nothing seemed to make much of a difference. E.g. 10/10 vs 10/1000 
produced pretty much identical results. Hence it didn't seem worth 
including those in the table.


Wmin = 10us leads us to total delay of 150us in 3 loops (this might be 
tight to catch most conditions)

Wmin = 25us can lead us to total delay of 175us in 3 loops

Since most conditions are likely to complete around 140us-160us, Looks 
lik

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] drm/i915/huc: Move firmware selection to init_early

2017-11-30 Thread Sagar Arun Kamble



On 12/1/2017 12:40 AM, Chris Wilson wrote:

Quoting Patchwork (2017-11-30 18:37:38)

== Series Details ==

Series: series starting with [1/6] drm/i915/huc: Move firmware selection to 
init_early
URL   : https://patchwork.freedesktop.org/series/34694/
State : failure

WARNING: Long output truncated

What's CI is trying to tell us there at the end is that we have a NULL
deref in guc_doorbell_destroy if we fail to load the guc firmware. So we
need to double check all the guc_init_submission failure paths.

guc_submission_disable in intel_uc_fini_hw is gated by module param still.
either we need to migrate to internal submission init state or update 
enable_guc=0 on guc init

failure when we have set auto option.
Taking sanitization past guc_fetch and making intel_uc_fw_is_selected 
rely on fetch_status looks
best option though because if we want to return -EIO then i915 load 
should mark as device init
failure which isn't happening currently (leading to reset path failures 
as well)

I'm still on the fence as to whether forcing -EIO on init failure is a
good plan.  We still have to go through all the reset code, teaching it
that it's ok to fail (or at least the failure is expected and to be
quiet, as we've already already the user to it).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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


Re: [Intel-gfx] [PATCH v2 5/7] drm/i915/guc: Combine enable_guc_loading|submission modparams

2017-12-01 Thread Sagar Arun Kamble



On 12/1/2017 4:03 PM, Michal Wajdeczko wrote:

We currently have two module parameters that control GuC:
"enable_guc_loading" and "enable_guc_submission". Whenever
we need submission=1, we also need loading=1. We also need
loading=1 when we want to want to load and verify the HuC.

Lets combine above module parameters into one "enable_guc"
modparam. New supported bit values are:

  0=disable GuC (no GuC submission, no HuC)
  1=enable GuC submission
  2=enable HuC load

Special value "-1" can be used to let driver decide what
option should be enabled for given platform based on
hardware/firmware availability or preference.

Explicit enabling any of the GuC features makes GuC load
a required step, fallback to non-GuC mode will not be
supported.

v2: Don't use -EIO

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Sagar Arun Kamble 
Cc: Sujaritha Sundaresan 



+void intel_uc_sanitize_options(struct drm_i915_private *dev_priv)
+{
+   struct intel_uc_fw *guc_fw = &dev_priv->guc.fw;
+   struct intel_uc_fw *huc_fw = &dev_priv->huc.fw;
+   int enable_guc = __get_default_enable_guc(dev_priv);
  
  	/* A negative value means "use platform default" */

-   if (i915_modparams.enable_guc_submission < 0)
-   i915_modparams.enable_guc_submission = HAS_GUC_SCHED(dev_priv);
+   if (i915_modparams.enable_guc < 0)
+   i915_modparams.enable_guc = enable_guc;
+
+   /* Verify GuC firmware availability */
+   if (USES_GUC(dev_priv) && !intel_uc_fw_is_selected(guc_fw)) {
+   DRM_WARN("Incompatible option enable_guc=%d - %s\n",
+i915_modparams.enable_guc,
+!HAS_GUC(dev_priv) ? "no GuC hardware" :
+ "no GuC firmware");
+   }
+
+   /* Verify HuC firmware availability */
+   if (USES_GUC_SUBMISSION(dev_priv) && !intel_uc_fw_is_selected(huc_fw)) {

should be USES_HUC here
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 4/7] drm/i915/uc: Don't use -EIO to report missing firmware

2017-12-01 Thread Sagar Arun Kamble



On 12/1/2017 6:01 PM, Chris Wilson wrote:

Quoting Michal Wajdeczko (2017-12-01 10:33:14)

-EIO has special meaning and is used when we want to allow
engine initialization to fail and mark GPU as wedged.
Missing firmware does not fit into this scenario as this is
permanent error not related to GPU condition.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Sagar Arun Kamble 

Ok, keeping -EIO to mean something special is a good idea. So if upload
now fails, we abort loading of the driver with ENOEXEC.

Is that sensible? Let's say due to fs corruption, or other error, we
aren't able to upload a fw, what should we do? If we abort the driver
load at this point, the user is likely left with a blank screen. If we
use -EIO, at least KMS is still functional and the user can still
interact with the system. (If we just fell back to execlists, then the
system remains very usable.)

What is the plan for HW initialisation failure?
Earlier we were returning -EIO from intel_uc_init_hw when GuC 
load/submission was "required" (enable_guc_loading/submission=2).
Keeping the same behavior I feel we should return -EIO if (enable_guc & 
1) (need to know that user requested "required")
I feel on auto mode (need to know user requested "auto") falling back to 
execlists makes sense as user dint enforce, so we should be returning 0 
then.

-Chris


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


Re: [Intel-gfx] [PATCH v2 6/7] drm/i915/huc: Load HuC only if requested

2017-12-01 Thread Sagar Arun Kamble



On 12/1/2017 4:03 PM, Michal Wajdeczko wrote:

Our new "enable_guc" modparam allows to control whenever HuC
should be loaded. However existing code will try load and
authenticate HuC always when we use the GuC. This patch is
trying to enforce modparam selection.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Sagar Arun Kamble 



  int intel_uc_init_hw(struct drm_i915_private *dev_priv)
  {
struct intel_guc *guc = &dev_priv->guc;
+   struct intel_huc *huc = &dev_priv->huc;
int ret, attempts;
  
  	if (!USES_GUC(dev_priv))

@@ -220,7 +221,12 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
if (ret)
goto err_submission;
  
-		intel_huc_init_hw(&dev_priv->huc);

+   if (USES_HUC(dev_priv)) {
+   ret = intel_huc_init_hw(huc);
+   if (ret)
+   break;

this break should be "goto err_submission" as GuC is still not ready.
looks like user has to be very careful with param now that HuC failure 
can block GuC tasks too.

+   }
+
intel_guc_init_params(guc);
ret = intel_guc_fw_upload(guc);
if (ret == 0 || ret != -EAGAIN)
@@ -238,7 +244,12 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
if (ret)
goto err_log_capture;
  
-	intel_huc_auth(&dev_priv->huc);

+   if (USES_HUC(dev_priv)) {
+   ret = intel_huc_auth(huc);
+   if (ret)
+   goto err_interrupts;
+   }
+
if (USES_GUC_SUBMISSION(dev_priv)) {
if (i915_modparams.guc_log_level >= 0)
gen9_enable_guc_interrupts(dev_priv);
@@ -252,6 +263,8 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 guc->fw.major_ver_found, guc->fw.minor_ver_found);
dev_info(dev_priv->drm.dev, "GuC submission %s\n",
 enableddisabled(USES_GUC_SUBMISSION(dev_priv)));
+   dev_info(dev_priv->drm.dev, "HuC %s\n",
+enableddisabled(USES_HUC(dev_priv)));
  
  	return 0;
  


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


Re: [Intel-gfx] [RFC 1/4] drm/i915/perf: Add support to correlate GPU timestamp with system time

2017-12-06 Thread Sagar Arun Kamble



On 12/5/2017 7:28 PM, Lionel Landwerlin wrote:

On 15/11/17 12:25, Chris Wilson wrote:

Quoting Sagar Arun Kamble (2017-11-15 12:13:51)

  #include 
  #include 
@@ -2149,6 +2150,14 @@ struct i915_perf_stream {
  * @oa_config: The OA configuration used by the stream.
  */
 struct i915_oa_config *oa_config;
+
+   /**
+    * System time correlation variables.
+    */
+   struct cyclecounter cc;
+   spinlock_t systime_lock;
+   struct timespec64 start_systime;
+   struct timecounter tc;

This pattern is repeated a lot by struct timecounter users. (I'm still
trying to understand why the common case is not catered for by a
convenience timecounter api.)


  };
    /**
diff --git a/drivers/gpu/drm/i915/i915_perf.c 
b/drivers/gpu/drm/i915/i915_perf.c

index 00be015..72ddc34 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -192,6 +192,7 @@
   */
    #include 
+#include 
  #include 
  #include 
  @@ -2391,6 +2392,56 @@ static unsigned int i915_perf_poll(struct 
file *file, poll_table *wait)

  }
    /**
+ * i915_cyclecounter_read - read raw cycle/timestamp counter
+ * @cc: cyclecounter structure
+ */
+static u64 i915_cyclecounter_read(const struct cyclecounter *cc)
+{
+   struct i915_perf_stream *stream = container_of(cc, 
typeof(*stream), cc);

+   struct drm_i915_private *dev_priv = stream->dev_priv;
+   u64 ts_count;
+
+   intel_runtime_pm_get(dev_priv);
+   ts_count = I915_READ64_2x32(GEN4_TIMESTAMP,
+   GEN7_TIMESTAMP_UDW);
+   intel_runtime_pm_put(dev_priv);
+
+   return ts_count;
+}
+
+static void i915_perf_init_cyclecounter(struct i915_perf_stream 
*stream)

+{
+   struct drm_i915_private *dev_priv = stream->dev_priv;
+   int cs_ts_freq = dev_priv->perf.oa.timestamp_frequency;
+   struct cyclecounter *cc = &stream->cc;
+   u32 maxsec;
+
+   cc->read = i915_cyclecounter_read;
+   cc->mask = CYCLECOUNTER_MASK(CS_TIMESTAMP_WIDTH(dev_priv));
+   maxsec = cc->mask / cs_ts_freq;
+
+   clocks_calc_mult_shift(&cc->mult, &cc->shift, cs_ts_freq,
+  NSEC_PER_SEC, maxsec);
+}
+
+static void i915_perf_init_timecounter(struct i915_perf_stream 
*stream)

+{
+#define SYSTIME_START_OFFSET   35 /* Counter read takes about 
350us */

+   unsigned long flags;
+   u64 ns;
+
+   i915_perf_init_cyclecounter(stream);
+   spin_lock_init(&stream->systime_lock);
+
+   getnstimeofday64(&stream->start_systime);
+   ns = timespec64_to_ns(&stream->start_systime) + 
SYSTIME_START_OFFSET;

Use ktime directly. Or else Arnd will be back with a patch to fix it.
(All non-ktime interfaces are effectively deprecated; obsolete for
drivers.)


+ spin_lock_irqsave(&stream->systime_lock, flags);
+   timecounter_init(&stream->tc, &stream->cc, ns);
+   spin_unlock_irqrestore(&stream->systime_lock, flags);
+}
+
+/**
   * i915_perf_enable_locked - handle `I915_PERF_IOCTL_ENABLE` ioctl
   * @stream: A disabled i915 perf stream
   *
@@ -2408,6 +2459,8 @@ static void i915_perf_enable_locked(struct 
i915_perf_stream *stream)

 /* Allow stream->ops->enable() to refer to this */
 stream->enabled = true;
  +   i915_perf_init_timecounter(stream);
+
 if (stream->ops->enable)
 stream->ops->enable(stream);
  }
diff --git a/drivers/gpu/drm/i915/i915_reg.h 
b/drivers/gpu/drm/i915/i915_reg.h

index cfdf4f8..e7e6966 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8882,6 +8882,12 @@ enum skl_power_gate {
    /* Gen4+ Timestamp and Pipe Frame time stamp registers */
  #define GEN4_TIMESTAMP _MMIO(0x2358)
+#define GEN7_TIMESTAMP_UDW _MMIO(0x235C)
+#define PRE_GEN7_TIMESTAMP_WIDTH   32
+#define GEN7_TIMESTAMP_WIDTH   36
+#define CS_TIMESTAMP_WIDTH(dev_priv) \
+   (INTEL_GEN(dev_priv) < 7 ? PRE_GEN7_TIMESTAMP_WIDTH : \
+  GEN7_TIMESTAMP_WIDTH)

s/PRE_GEN7/GEN4/ would be consistent.
If you really want to add support for earlier, I9XX_.


Why not use the RING_TIMESTAMP() RING_TIMESTAMP_UDW() ?
There's already used for the reg_read ioctl.


Yes. We can use these.





Ok. I can accept the justification, and we are not the only ones who do
the cyclecounter -> timecounter correction like this.
-Chris





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


Re: [Intel-gfx] [RFC 4/4] drm/i915/perf: Send system clock monotonic time in perf samples

2017-12-06 Thread Sagar Arun Kamble



On 12/5/2017 7:52 PM, Lionel Landwerlin wrote:

On 15/11/17 12:13, Sagar Arun Kamble wrote:

From: Sourab Gupta 

Currently, we have the ability to only forward the GPU timestamps in the
samples (which are generated via OA reports). This limits the ability to
correlate these samples with the system events.

An ability is therefore needed to report timestamps in different clock
domains, such as CLOCK_MONOTONIC, in the perf samples to be of more
practical use to the userspace. This ability becomes important
when we want to correlate/plot GPU events/samples with other system 
events

on the same timeline (e.g. vblank events, or timestamps when work was
submitted to kernel, etc.)

The patch here proposes a mechanism to achieve this. The correlation
between gpu time and system time is established using the timestamp 
clock
associated with the command stream, abstracted as 
timecounter/cyclecounter

to retrieve gpu/system time correlated values.

v2: Added i915_driver_init_late() function to capture the new late init
phase for perf (Chris)

v3: Removed cross-timestamp changes.

Signed-off-by: Sourab Gupta 
Signed-off-by: Sagar Arun Kamble 
Cc: Lionel Landwerlin 
Cc: Chris Wilson 
Cc: Sourab Gupta 
Cc: Matthew Auld 
---
  drivers/gpu/drm/i915/i915_perf.c | 27 +++
  include/uapi/drm/i915_drm.h  |  7 +++
  2 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_perf.c 
b/drivers/gpu/drm/i915/i915_perf.c

index 3b721d7..94ee924 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -336,6 +336,7 @@
    #define SAMPLE_OA_REPORT    BIT(0)
  #define SAMPLE_GPU_TS    BIT(1)
+#define SAMPLE_SYSTEM_TS    BIT(2)
    /**
   * struct perf_open_properties - for validated properties given to 
open a stream
@@ -622,6 +623,7 @@ static int append_oa_sample(struct 
i915_perf_stream *stream,

  struct drm_i915_perf_record_header header;
  u32 sample_flags = stream->sample_flags;
  u64 gpu_ts = 0;
+    u64 system_ts = 0;
    header.type = DRM_I915_PERF_RECORD_SAMPLE;
  header.pad = 0;
@@ -647,6 +649,23 @@ static int append_oa_sample(struct 
i915_perf_stream *stream,

    if (copy_to_user(buf, &gpu_ts, I915_PERF_TS_SAMPLE_SIZE))
  return -EFAULT;
+    buf += I915_PERF_TS_SAMPLE_SIZE;


This is a ridiculous nit, but I think using sizeof(u64) would be more 
readable than this I915_PERF_TS_SAMPLE_SIZE define.


Will update. Thanks.




+    }
+
+    if (sample_flags & SAMPLE_SYSTEM_TS) {
+    gpu_ts = get_gpu_ts_from_oa_report(stream, report);
+    /*
+ * XXX: timecounter_cyc2time considers time backwards if delta
+ * timestamp is more than half the max ns time covered by
+ * counter. It will be ~35min for 36 bit counter. If this much
+ * sampling duration is needed we will have to update tc->nsec
+ * by explicitly reading the timecounter (timecounter_read)
+ * before this duration.
+ */
+    system_ts = timecounter_cyc2time(&stream->tc, gpu_ts);
+
+    if (copy_to_user(buf, &system_ts, I915_PERF_TS_SAMPLE_SIZE))
+    return -EFAULT;
  }
    (*offset) += header.size;
@@ -2137,6 +2156,11 @@ static int i915_oa_stream_init(struct 
i915_perf_stream *stream,

  stream->sample_size += I915_PERF_TS_SAMPLE_SIZE;
  }
  +    if (props->sample_flags & SAMPLE_SYSTEM_TS) {
+    stream->sample_flags |= SAMPLE_SYSTEM_TS;
+    stream->sample_size += I915_PERF_TS_SAMPLE_SIZE;
+    }
+
  dev_priv->perf.oa.oa_buffer.format_size = format_size;
  if (WARN_ON(dev_priv->perf.oa.oa_buffer.format_size == 0))
  return -EINVAL;
@@ -2857,6 +2881,9 @@ static int read_properties_unlocked(struct 
drm_i915_private *dev_priv,

  case DRM_I915_PERF_PROP_SAMPLE_GPU_TS:
  props->sample_flags |= SAMPLE_GPU_TS;
  break;
+    case DRM_I915_PERF_PROP_SAMPLE_SYSTEM_TS:
+    props->sample_flags |= SAMPLE_SYSTEM_TS;
+    break;
  case DRM_I915_PERF_PROP_OA_METRICS_SET:
  if (value == 0) {
  DRM_DEBUG("Unknown OA metric set ID\n");
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 0b9249e..283859c 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1453,6 +1453,12 @@ enum drm_i915_perf_property_id {
  DRM_I915_PERF_PROP_SAMPLE_GPU_TS,
    /**
+ * This property requests inclusion of CLOCK_MONOTONIC system 
time in

+ * the perf sample data.
+ */
+    DRM_I915_PERF_PROP_SAMPLE_SYSTEM_TS,
+
+    /**
   * The value specifies which set of OA unit metrics should be
   * be configured, defining the contents of any OA unit reports.
   */
@@ -1539,6 +1545,7 @@ enum drm_i915_perf_record_type {
   *
   * { u32 oa_report[]; } && DRM_I915_PERF_PROP_SAMPLE_OA
   * { u64

Re: [Intel-gfx] [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events

2017-12-06 Thread Sagar Arun Kamble



On 12/5/2017 8:07 PM, Lionel Landwerlin wrote:

On 05/12/17 14:28, Robert Bragg wrote:



On Tue, Dec 5, 2017 at 2:16 PM, Lionel Landwerlin 
<mailto:lionel.g.landwer...@intel.com>> wrote:


Hey Sagar,

Sorry for the delay looking into this series.
I've done some userspace/UI work in GPUTop to try to correlate
perf samples/tracepoints with i915 perf reports.

I wanted to avoid having to add too much logic into the kernel
and tried to sample both cpu clocks & gpu timestamps from userspace.
So far that's not working. People more knowledgable than I would
have realized that the kernel can sneak in work into syscalls.
So result is that 2 syscalls (one to get the cpu clock, one for
the gpu timestamp) back to back from the same thread leads to
time differences of anywhere from a few microseconds to in some
cases close to 1millisecond. So it's basically unworkable.
Anyway the UI work won't go to waste :)

I'm thinking to go with your approach.
>From my experiment with gputop, it seems we might want to use a
different cpu clock source though or make it configurable.
The perf infrastructure allows you to choose what clock you want
to use. Since we want to avoid time adjustments on that clock
(because we're adding deltas), a clock monotonic raw would make
most sense.


I would guess the most generally useful clock domain to correlate 
with the largest number of interesting events would surely be 
CLOCK_MONOTONIC, not _MONOTONIC_RAW.


E.g. here's some discussion around why vblank events use 
CLOCK_MONOTINIC: 
https://lists.freedesktop.org/archives/dri-devel/2012-October/028878.html


Br,
- Robert


Thanks Rob, then I guess making it configurable when opening the 
stream would be the safest option.



All timecounter users today rely on monotonic clock (Can request for clock 
real/wall time, clock boot time, clock tai time
corresponding to monotonic clock).
Agree that we will need to have configuration option about clock to be used 
like in trace_clock in ftrace.




I'll look at adding some tests for this too.

    Thanks,

    -
Lionel

On 15/11/17 12:13, Sagar Arun Kamble wrote:

We can compute system time corresponding to GPU timestamp by
taking a
reference point (CPU monotonic time, GPU timestamp) and then
adding
delta time computed using timecounter/cyclecounter support in
kernel.
We have to configure cyclecounter with the GPU timestamp
frequency.
Earlier approach that was based on cross-timestamp is not
needed. It
was being used to approximate the frequency based on invalid
assumptions
(possibly drift was being seen in the time due to precision
issue).
The precision of time from GPU clocks is already in ns and
timecounter
takes care of it as verified over variable durations.

This series adds base timecounter/cyclecounter changes and
changes to
    get GPU and CPU timestamps in OA samples.

Sagar Arun Kamble (1):
   drm/i915/perf: Add support to correlate GPU timestamp with
system time

Sourab Gupta (3):
   drm/i915/perf: Add support for collecting 64 bit
timestamps with OA
     reports
   drm/i915/perf: Extract raw GPU timestamps from OA reports
   drm/i915/perf: Send system clock monotonic time in perf
samples

  drivers/gpu/drm/i915/i915_drv.h  |  11 
  drivers/gpu/drm/i915/i915_perf.c | 124
++-
  drivers/gpu/drm/i915/i915_reg.h  |   6 ++
  include/uapi/drm/i915_drm.h      |  14 +
  4 files changed, 154 insertions(+), 1 deletion(-)


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
<mailto:Intel-gfx@lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
<https://lists.freedesktop.org/mailman/listinfo/intel-gfx>






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


Re: [Intel-gfx] [PATCH v3 7/8] drm/i915/huc: Load HuC only if requested

2017-12-06 Thread Sagar Arun Kamble



On 12/5/2017 10:08 PM, Michal Wajdeczko wrote:

Our new "enable_guc" modparam allows to control whenever HuC
should be loaded. However existing code will try load and
authenticate HuC always when we use the GuC. This patch is
trying to enforce modparam selection.

v2: no need to cast PTR_ERR (Chris)
 fetch/fini only if required (Michal)
 fix wrong break (Sagar)

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Sagar Arun Kamble 





  /**
@@ -186,6 +190,7 @@ static void guc_disable_communication(struct intel_guc *guc)
  int intel_uc_init_hw(struct drm_i915_private *dev_priv)
  {
struct intel_guc *guc = &dev_priv->guc;
+   struct intel_huc *huc = &dev_priv->huc;
int ret, attempts;
  
  	if (!USES_GUC(dev_priv))

@@ -233,7 +238,12 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
if (ret)
goto err_submission;
  
-		intel_huc_init_hw(&dev_priv->huc);

+   if (USES_HUC(dev_priv)) {
+   ret = intel_huc_init_hw(huc);
+   if (ret)
+   goto err_submission;
+   }
+
intel_guc_init_params(guc);
ret = intel_guc_fw_upload(guc);
if (ret == 0 || ret != -EAGAIN)
@@ -251,7 +261,12 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
if (ret)
goto err_log_capture;
  
-	intel_huc_auth(&dev_priv->huc);

+   if (USES_HUC(dev_priv)) {
+   ret = intel_huc_auth(huc);
+   if (ret)
+   goto err_interrupts;


I think we need to create new label "err_communication" and jump there since 
interrupts are not yet enabled.
Planning to move interrupts enabling before enabling communication in the other 
series - https://patchwork.freedesktop.org/patch/183349/

With that updated patch looks good to me.
Reviewed-by: Sagar Arun Kamble 


+   }
+
if (USES_GUC_SUBMISSION(dev_priv)) {
if (i915_modparams.guc_log_level >= 0)
gen9_enable_guc_interrupts(dev_priv);
@@ -265,6 +280,8 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 guc->fw.major_ver_found, guc->fw.minor_ver_found);
dev_info(dev_priv->drm.dev, "GuC submission %s\n",
 enableddisabled(USES_GUC_SUBMISSION(dev_priv)));
+   dev_info(dev_priv->drm.dev, "HuC %s\n",
+enableddisabled(USES_HUC(dev_priv)));
  
  	return 0;
  


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


Re: [Intel-gfx] [RFC 2/4] drm/i915/perf: Add support for collecting 64 bit timestamps with OA reports

2017-12-21 Thread Sagar Arun Kamble



On 12/6/2017 9:31 PM, Lionel Landwerlin wrote:

On 15/11/17 12:13, Sagar Arun Kamble wrote:

--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1447,6 +1447,12 @@ enum drm_i915_perf_property_id {
  DRM_I915_PERF_PROP_SAMPLE_OA,
    /**
+ * The value of this property set to 1 requests inclusion of GPU
+ * timestamp in the perf sample data.
+ */
+    DRM_I915_PERF_PROP_SAMPLE_GPU_TS,
+
+    /**
   * The value specifies which set of OA unit metrics should be
   * be configured, defining the contents of any OA unit reports.
   */



Inserting this, not at the end of this enum break API/ABI.
This applies to other patches too.

Thanks. Will update.

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


Re: [Intel-gfx] [RFC 3/4] drm/i915/perf: Extract raw GPU timestamps from OA reports

2017-12-21 Thread Sagar Arun Kamble



On 12/7/2017 1:25 AM, Lionel Landwerlin wrote:

On 15/11/17 12:13, Sagar Arun Kamble wrote:

From: Sourab Gupta 

The OA reports contain the least significant 32 bits of the gpu 
timestamp.

This patch enables retrieval of the timestamp field from OA reports, to
forward as 64 bit raw gpu timestamps in the perf samples.

v2: Rebase w.r.t new timecounter support.

Signed-off-by: Sourab Gupta 
Signed-off-by: Sagar Arun Kamble 
Cc: Lionel Landwerlin 
Cc: Chris Wilson 
Cc: Sourab Gupta 
Cc: Matthew Auld 
---
  drivers/gpu/drm/i915/i915_drv.h  |  2 ++
  drivers/gpu/drm/i915/i915_perf.c | 26 +-
  2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h 
b/drivers/gpu/drm/i915/i915_drv.h

index e08bc85..5534cd2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2151,6 +2151,8 @@ struct i915_perf_stream {
   */
  struct i915_oa_config *oa_config;
  +    u64 last_gpu_ts;
+
  /**
   * System time correlation variables.
   */
diff --git a/drivers/gpu/drm/i915/i915_perf.c 
b/drivers/gpu/drm/i915/i915_perf.c

index f7e748c..3b721d7 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -575,6 +575,26 @@ static int append_oa_status(struct 
i915_perf_stream *stream,

  }
    /**
+ * get_gpu_ts_from_oa_report - Retrieve absolute gpu timestamp from 
OA report

+ *
+ * Note: We are assuming that we're updating last_gpu_ts frequently 
enough so

+ * that it's never possible to see multiple overflows before we compare
+ * sample_ts to last_gpu_ts. Since this is significantly large duration
+ * (~6min for 80ns ts base), we can safely assume so.
+ */
+static u64 get_gpu_ts_from_oa_report(struct i915_perf_stream *stream,
+ const u8 *report)
+{
+    u32 sample_ts = *(u32 *)(report + 4);
+    u32 delta;
+
+    delta = sample_ts - (u32)stream->last_gpu_ts;
+    stream->last_gpu_ts += delta;
+
+    return stream->last_gpu_ts;
+}
+
+/**
   * append_oa_sample - Copies single OA report into userspace read() 
buffer.

   * @stream: An i915-perf stream opened for OA metrics
   * @buf: destination buffer given by userspace
@@ -622,7 +642,9 @@ static int append_oa_sample(struct 
i915_perf_stream *stream,

  }
    if (sample_flags & SAMPLE_GPU_TS) {
-    /* Timestamp to be populated from OA report */
+    /* Timestamp populated from OA report */
+    gpu_ts = get_gpu_ts_from_oa_report(stream, report);
+
  if (copy_to_user(buf, &gpu_ts, I915_PERF_TS_SAMPLE_SIZE))
  return -EFAULT;
  }


I think everything above this line should be merged int patch 2.
It's better to have a single functional patch.

Yes. Will merge.


@@ -2421,6 +2443,8 @@ static u64 i915_cyclecounter_read(const struct 
cyclecounter *cc)

  GEN7_TIMESTAMP_UDW);
  intel_runtime_pm_put(dev_priv);
  +    stream->last_gpu_ts = ts_count;


This doesn't look right. You're already adding a delta in 
get_gpu_ts_from_oa_report().
This will produce incorrect timestamps. Since at the moment we won't 
allow opening without PROP_SAMPLE_OA, I would just drop this line.



Yes. makes sense. will remove.

+
  return ts_count;
  }





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


Re: [Intel-gfx] [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events

2017-12-21 Thread Sagar Arun Kamble



On 12/7/2017 1:32 AM, Lionel Landwerlin wrote:
I've put together some trival IGT tests : 
https://github.com/djdeath/intel-gpu-tools/commits/wip/djdeath/cpu-timestamps
With a few changes which I pointed in the review : 
https://github.com/djdeath/linux/commit/d0e4cf4d3f464491b4ffe97d112284d1ce73656d


Put together it seems to work relatively well.
There is still a small drift happening between the 2 timestamps. I've 
noticed over a 160ms of OA reports, there is a accumulated difference 
of ~35us between the GPU timestamp and cpu timestamps.
I may be doing something wrong with the scaling in the tests, or maybe 
there is an issue in the kernel, or both.
Went through the testcase. scaled_gpu_delta calculation is same as what 
timecounter does in kernel for calculating system_time corresponding
to gpu timestamp hence we don't see much of delta between these two 
times/time deltas.
Ideally we should be testing the system time delta by sampling system 
time and gpu timestamp atomically (which isn't feasible unless we do 
some precise adjustments)
I have attempted to check these two times/delta by sampling them in 
debugfs and reading over variable periods manually and checking the delta.

https://github.com/sakamble/i915-timestamp-support/commit/03be3056752d7b05a02cd01f5c20b3fcfcf18395

It is showing that delta is less than 10us in most cases for 30min and 
occasionally around 20-30us. Again this delta might be because of 
initial time setting as well.
timecounter initializing system time and gpu clocks as pair should be 
highly accurate for which I have currently taken 350us start offset.


I think gpu timestamp clock is highly stable as seen in my testing on 
SKL. I think this clock is used for calculations in GuC too so will
be good to get confirmation about the stability of this clock from them 
and HW team.


   systemd-udevd-169   [001]  3.035812: i915_driver_load: sys 
start time: 1512308011156099790


   systemd-udevd-169   [001] d... 3.036012: i915_cyclecounter_read: 
52025098974


 cat-1654  [001]     52.407957: i915_cyclecounter_read: 
52617562292


 cat-1654  [001]     52.407958: i915_timestamp_info: 
sys time: 1512308060527894638


 cat-1654  [001]     52.407958: i915_timestamp_info: 
ts: 52617562292 device time: 1512308060528043050


 cat-1684  [001]    177.239733: i915_cyclecounter_read: 
54115543581


 cat-1684  [001]    177.239736: i915_timestamp_info: 
sys time: 151230818535902


 cat-1684  [001]    177.239737: i915_timestamp_info: 
ts: 54115543581 device time: 1512308185359817372


 cat-1693  [001]    329.820374: i915_cyclecounter_read: 
55946511277


 cat-1693  [001]    329.820377: i915_timestamp_info: 
sys time: 1512308337940301732


 cat-1693  [001]    329.820378: i915_timestamp_info: 
ts: 55946511277 device time: 1512308337940458996



samples (177, 329) = 6494ns>



 cat-1702  [001]    506.980313: i915_cyclecounter_read: 
58072430542


 cat-1702  [001]    506.980315: i915_timestamp_info: 
sys time: 1512308515100233102


 cat-1702  [001]    506.980317: i915_timestamp_info: 
ts: 58072430542 device time: 1512308515100398084


samples (329, 506) = 6494ns>




I'll build the GPUTop parts and see if the results make sense.

Thanks!,

-
Lionel

On 15/11/17 12:13, Sagar Arun Kamble wrote:

We can compute system time corresponding to GPU timestamp by taking a
reference point (CPU monotonic time, GPU timestamp) and then adding
delta time computed using timecounter/cyclecounter support in kernel.
We have to configure cyclecounter with the GPU timestamp frequency.
Earlier approach that was based on cross-timestamp is not needed. It
was being used to approximate the frequency based on invalid assumptions
(possibly drift was being seen in the time due to precision issue).
The precision of time from GPU clocks is already in ns and timecounter
takes care of it as verified over variable durations.

This series adds base timecounter/cyclecounter changes and changes to
get GPU and CPU timestamps in OA samples.

Sagar Arun Kamble (1):
   drm/i915/perf: Add support to correlate GPU timestamp with system 
time


Sourab Gupta (3):
   drm/i915/perf: Add support for collecting 64 bit timestamps with OA
 reports
   drm/i915/perf: Extract raw GPU timestamps from OA reports
   drm/i915/perf: Send system clock monotonic time in perf samples

  drivers/gpu/drm/i915/i915_drv.h  |  11 
  drivers/gpu/drm/i915/i915_perf.c | 124 
++-

  drivers/gpu/drm/i915/i915_reg.h  |   6 ++
  include/uapi/drm/i915_drm.h  |  14 +
  4 files changed, 154 insertions(+), 1 deletion(-)





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


Re: [Intel-gfx] [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events

2017-12-21 Thread Sagar Arun Kamble



On 12/22/2017 10:45 AM, Sagar Arun Kamble wrote:




On 12/7/2017 1:32 AM, Lionel Landwerlin wrote:
I've put together some trival IGT tests : 
https://github.com/djdeath/intel-gpu-tools/commits/wip/djdeath/cpu-timestamps
With a few changes which I pointed in the review : 
https://github.com/djdeath/linux/commit/d0e4cf4d3f464491b4ffe97d112284d1ce73656d


Put together it seems to work relatively well.
There is still a small drift happening between the 2 timestamps. I've 
noticed over a 160ms of OA reports, there is a accumulated difference 
of ~35us between the GPU timestamp and cpu timestamps.
I may be doing something wrong with the scaling in the tests, or 
maybe there is an issue in the kernel, or both.
Went through the testcase. scaled_gpu_delta calculation is same as 
what timecounter does in kernel for calculating system_time corresponding
to gpu timestamp hence we don't see much of delta between these two 
times/time deltas.
Ideally we should be testing the system time delta by sampling system 
time and gpu timestamp atomically (which isn't feasible unless we do 
some precise adjustments)
I have attempted to check these two times/delta by sampling them in 
debugfs and reading over variable periods manually and checking the delta.

https://github.com/sakamble/i915-timestamp-support/commit/03be3056752d7b05a02cd01f5c20b3fcfcf18395

It is showing that delta is less than 10us in most cases for 30min and 
occasionally around 20-30us. Again this delta might be because of 
initial time setting as well.
timecounter initializing system time and gpu clocks as pair should be 
highly accurate for which I have currently taken 350us start offset.


I think gpu timestamp clock is highly stable as seen in my testing on 
SKL. I think this clock is used for calculations in GuC too so will
be good to get confirmation about the stability of this clock from 
them and HW team.


   systemd-udevd-169   [001]  3.035812: i915_driver_load: sys 
start time: 1512308011156099790


   systemd-udevd-169   [001] d... 3.036012: 
i915_cyclecounter_read: 52025098974


 cat-1654  [001]     52.407957: 
i915_cyclecounter_read: 52617562292


 cat-1654  [001]     52.407958: i915_timestamp_info: 
sys time: 1512308060527894638


 cat-1654  [001]     52.407958: i915_timestamp_info: 
ts: 52617562292 device time: 1512308060528043050


 cat-1684  [001]    177.239733: 
i915_cyclecounter_read: 54115543581


 cat-1684  [001]    177.239736: i915_timestamp_info: 
sys time: 151230818535902


 cat-1684  [001]    177.239737: i915_timestamp_info: 
ts: 54115543581 device time: 1512308185359817372


 cat-1693  [001]    329.820374: 
i915_cyclecounter_read: 55946511277


 cat-1693  [001]    329.820377: i915_timestamp_info: 
sys time: 1512308337940301732


 cat-1693  [001]    329.820378: i915_timestamp_info: 
ts: 55946511277 device time: 1512308337940458996



samples (177, 329) = 6494ns>



 cat-1702  [001]    506.980313: 
i915_cyclecounter_read: 58072430542


 cat-1702  [001]    506.980315: i915_timestamp_info: 
sys time: 1512308515100233102


 cat-1702  [001]    506.980317: i915_timestamp_info: 
ts: 58072430542 device time: 1512308515100398084


samples (329, 506) = 6494ns>



Fixing typo here:
samples (329, 506) = 7718ns>


I'll build the GPUTop parts and see if the results make sense.

Thanks!,

-
Lionel

On 15/11/17 12:13, Sagar Arun Kamble wrote:

We can compute system time corresponding to GPU timestamp by taking a
reference point (CPU monotonic time, GPU timestamp) and then adding
delta time computed using timecounter/cyclecounter support in kernel.
We have to configure cyclecounter with the GPU timestamp frequency.
Earlier approach that was based on cross-timestamp is not needed. It
was being used to approximate the frequency based on invalid 
assumptions

(possibly drift was being seen in the time due to precision issue).
The precision of time from GPU clocks is already in ns and timecounter
takes care of it as verified over variable durations.

This series adds base timecounter/cyclecounter changes and changes to
get GPU and CPU timestamps in OA samples.

Sagar Arun Kamble (1):
   drm/i915/perf: Add support to correlate GPU timestamp with system 
time


Sourab Gupta (3):
   drm/i915/perf: Add support for collecting 64 bit timestamps with OA
 reports
   drm/i915/perf: Extract raw GPU timestamps from OA reports
   drm/i915/perf: Send system clock monotonic time in perf samples

  drivers/gpu/drm/i915/i915_drv.h  |  11 
  drivers/gpu/drm/i915/i915_perf.c | 124 
++-

  drivers/gpu/drm/i915/i915_reg.h  |   6 ++
  include/uapi/drm/i915_drm.h  |  14 +
  4 files changed, 154 insertions(+), 1 deletion(-)







__

Re: [Intel-gfx] [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events

2017-12-21 Thread Sagar Arun Kamble



On 12/7/2017 6:18 AM, Robert Bragg wrote:



On Wed, Nov 15, 2017 at 12:13 PM, Sagar Arun Kamble 
mailto:sagar.a.kam...@intel.com>> wrote:


We can compute system time corresponding to GPU timestamp by taking a
reference point (CPU monotonic time, GPU timestamp) and then adding
delta time computed using timecounter/cyclecounter support in kernel.
We have to configure cyclecounter with the GPU timestamp frequency.
Earlier approach that was based on cross-timestamp is not needed. It
was being used to approximate the frequency based on invalid
assumptions
(possibly drift was being seen in the time due to precision issue).
The precision of time from GPU clocks is already in ns and timecounter
takes care of it as verified over variable durations.


Hi Sagar,

I have some doubts about this analysis...

The intent behind Sourab's original approach was to be able to 
determine the frequency at runtime empirically because the constants 
we have aren't particularly accurate. Without a perfectly stable 
frequency that's known very precisely then an interpolated correlation 
will inevitably drift. I think the nature of HW implies we can't 
expect to have either of those. Then the general idea had been to try 
and use existing kernel infrastructure for a problem which isn't 
unique to GPU clocks.

Hi Robert,

Testing on SKL shows timestamps drift only about 10us for sampling done 
in kernel for about 30min time.
Verified with changes from 
https://github.com/sakamble/i915-timestamp-support/commits/drm-tip
Note that since we are sampling counter in debugfs, there is likely 
overhead of read that is adding to drift so adjustment might be needed.
But with OA reports we just have to worry about initial timecounter 
setup where we need accurate pair of system time and GPU timestamp clock 
counts.
I think timestamp clock is highly stable and we don't need logic to 
determine frequency at runtime. Will try to get confirmation from HW 
team as well.


If we need to determine the frequency, Sourab's approach needs to refined as
1. It can be implemented entirely in i915 because what we need is pair 
of system time and gpu clocks over different durations.
2. crosstimestamp framework usage in that approach is incorrect as 
ideally we should be sending ART counter and GPU counter. Instead we were

hacking to send the TSC clock.
Quoting Thomas from  https://patchwork.freedesktop.org/patch/144298/
get_device_system_crosststamp() is for timestamps taken via a clock 
which is directly correlated with the timekeeper clocksource.


ART and TSC are correlated via: TSC = (ART * scale) + offset
get_device_system_crosststamp() invokes the device function which reads 
ART, which is converted to CLOCK_MONOTONIC_RAW by the conversion above,
and then uses interpolation to map the CLOCK_MONOTONIC_RAW value to 
CLOCK_MONOTONIC.
The device function does not know anything about TSC. All it knows about 
is ART.


I am not aware if GPU timestamp clock is correlated with TSC like ART 
for ethernet drivers and if i915 can read ART like ethernet drivers.
3. I have seen precision issues in the calculations in 
i915_perf_clock_sync_work and usage of MONO_RAW which might jump time.


That's not to say that a more limited, simpler solution based on 
frequent re-correlation wouldn't be more than welcome if tracking an 
accurate frequency is too awkward for now
Adjusting timecounter time can be another option if we confirm that GPU 
timestamp frequency is stable.

, but I think some things need to be considered in that case:

- It would be good to quantify the kind of drift seen in practice to 
know how frequently it's necessary to re-synchronize. It sounds like 
you've done this ("as verified over variable durations") so I'm 
curious what kind of drift you saw. I'd imagine you would see a 
significant drift over, say, one second and it might not take much 
longer for the drift to even become clearly visible to the user when 
plotted in a UI. For reference I once updated the arb_timer_query test 
in piglit to give some insight into this drift 
(https://lists.freedesktop.org/archives/piglit/2016-September/020673.html) 
and at least from what I wrote back then it looks like I was seeing a 
drift of a few milliseconds per second on SKL. I vaguely recall it 
being much worse given the frequency constants we had for Haswell.


On SKL I have seen very small drift of less than 10us over a period of 
30 minutes.
Verified with changes from 
https://github.com/sakamble/i915-timestamp-support/commits/drm-tip


36bit counter will overflow in about 95min at 12mhz and timecounter 
framework considers
counter value with delta from timecounter init of more than half of 
total time covered by counter as time in the past so current approach 
works for less than 45min.
Will need to add overflow watchdog support like other drivers which just 
rei

Re: [Intel-gfx] [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events

2017-12-22 Thread Sagar Arun Kamble



On 12/21/2017 6:29 PM, Lionel Landwerlin wrote:

Some more findings I made while playing with this series & GPUTop.
Turns out the 2ms drift per second is due to timecounter. Adding the 
delta this way :


https://github.com/djdeath/linux/commit/7b002cb360483e331053aec0f98433a5bd5c5c3f#diff-9b74bd0cfaa90b601d80713c7bd56be4R607

Eliminates the drift.
I see two imp. changes 1. approximation of start time during 
init_timecounter 2. overflow handling in delta accumulation.
With these incorporated, I guess timecounter should also work in same 
fashion.

Timelines of perf i915 tracepoints & OA reports now make a lot more sense.

There is still the issue that reading the CPU clock & the RCS 
timestamp is inherently not atomic. So there is a delta there.
I think we should add a new i915 perf record type to express the delta 
that we measure this way :


https://github.com/djdeath/linux/commit/7b002cb360483e331053aec0f98433a5bd5c5c3f#diff-9b74bd0cfaa90b601d80713c7bd56be4R2475

So that userspace knows there might be a global offset between the 2 
times and is able to present it.

agree on this. Delta ns1-ns0 can be interpreted as max drift.
Measurement on my KBL system were in the order of a few microseconds 
(~30us).
I guess we might be able to setup the correlation point better 
(masking interruption?) to reduce the delta.

already using spin_lock. Do you mean NMI?


Thanks,

-
Lionel


On 07/12/17 00:57, Robert Bragg wrote:



On Thu, Dec 7, 2017 at 12:48 AM, Robert Bragg > wrote:



at least from what I wrote back then it looks like I was seeing a
drift of a few milliseconds per second on SKL. I vaguely recall
it being much worse given the frequency constants we had for Haswell.


Sorry I didn't actually re-read my own message properly before 
referencing it :) Apparently the 2ms per second drift was for 
Haswell, so presumably not quite so bad for SKL.


- Robert



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





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


Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc : GEM_BUG_ON for GuC reset

2017-12-22 Thread Sagar Arun Kamble



On 12/21/2017 6:37 AM, Sujaritha Sundaresan wrote:

Including GEM_BUG_ON for GuC reset function in
intel_uncore.
Can be reframed - "Instead of returning -EINVAL, GEM_BUG_ON when GuC 
reset is invoked for

platforms not supporting as we don't expect to invoke it"
Subject can be - "GEM_BUG_ON on invoking GuC reset function for non-GuC 
platforms"


Signed-off-by: Sujaritha Sundaresan 
Cc: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/intel_uncore.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 89547b61..94e1fb3 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1936,8 +1936,7 @@ int intel_reset_guc(struct drm_i915_private *dev_priv)
  {
int ret;
  
-	if (!HAS_GUC(dev_priv))

-   return -EINVAL;
+   GEM_BUG_ON(!HAS_GUC(dev_priv));
  
  	intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);

ret = gen6_hw_domain_reset(dev_priv, GEN9_GRDOM_GUC);


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


Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add GuC support for engine busy stats

2017-12-22 Thread Sagar Arun Kamble



On 11/29/2017 6:03 PM, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Wire up the engine busy stats accounting to the GuC submission backend.

Since there is not

no

  context out interrupt we need to place the accounting
callbacks per-request in order to correctly pair with user interrupts.

v2: Rebase.
v3: Commit update.

Signed-off-by: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/intel_guc_submission.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 912ff143d531..d80d2a3214da 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -781,6 +781,7 @@ static void guc_dequeue(struct intel_engine_cs *engine)
INIT_LIST_HEAD(&rq->priotree.link);
  
  			__i915_gem_request_submit(rq);

+   intel_engine_context_in(rq->engine);

Shouldn't we also invoke execlists_context_status_change for GVT-g.

trace_i915_gem_request_in(rq,
  port_index(port, execlists));
last = rq;
@@ -813,6 +814,7 @@ static void guc_submission_tasklet(unsigned long data)
  
  	rq = port_request(&port[0]);

while (rq && i915_gem_request_completed(rq)) {
+   intel_engine_context_out(rq->engine);
trace_i915_gem_request_out(rq);
i915_gem_request_put(rq);
  
@@ -1453,8 +1455,6 @@ int intel_guc_submission_enable(struct intel_guc *guc)

execlists->tasklet.func = guc_submission_tasklet;
engine->park = guc_submission_park;
engine->unpark = guc_submission_unpark;
-
-   engine->flags &= ~I915_ENGINE_SUPPORTS_STATS;

Should we explicitly set this flag even though execlists is setting it.

}
  
  	return 0;

Overall change looks good to me.
GuC publishing engine data will make it more precise as we understand.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events

2017-12-25 Thread Sagar Arun Kamble



On 12/22/2017 3:46 PM, Lionel Landwerlin wrote:

On 22/12/17 09:30, Sagar Arun Kamble wrote:




On 12/21/2017 6:29 PM, Lionel Landwerlin wrote:

Some more findings I made while playing with this series & GPUTop.
Turns out the 2ms drift per second is due to timecounter. Adding the 
delta this way :


https://github.com/djdeath/linux/commit/7b002cb360483e331053aec0f98433a5bd5c5c3f#diff-9b74bd0cfaa90b601d80713c7bd56be4R607

Eliminates the drift.
I see two imp. changes 1. approximation of start time during 
init_timecounter 2. overflow handling in delta accumulation.
With these incorporated, I guess timecounter should also work in same 
fashion.


I think the arithmetic in timecounter is inherently lossy and that's 
why we're seeing a drift.
Could you share details about platform, scenario in which 2ms drift per 
second is being seen with timecounter.

I did not observe this on SKL.

Could we be using it wrong?

if we use two changes highlighted above with timecounter maybe we will 
get same results as your current implementation.
In the patch above, I think there is still a drift because of the 
potential fractional part loss at every delta we add.
But it should only be a fraction of a nanosecond multiplied by the 
number of reports over a period of time.
With a report every 1us, that should still be much less than a 1ms of 
drift over 1s.



timecounter interface takes care of fractional parts so that should help us.
we can either go with timecounter or our own implementation provided 
conversions are precise.
We can probably do better by always computing the clock using the 
entire delta rather than the accumulated delta.


issue is that the reported clock cycles in the OA report is 32bits LSB 
of GPU TS whereas counter is 36bits. Hence we will need to
accumulate the delta. ofc there is assumption that two reports can't be 
spaced with count value of 0x apart.
Timelines of perf i915 tracepoints & OA reports now make a lot more 
sense.


There is still the issue that reading the CPU clock & the RCS 
timestamp is inherently not atomic. So there is a delta there.
I think we should add a new i915 perf record type to express the 
delta that we measure this way :


https://github.com/djdeath/linux/commit/7b002cb360483e331053aec0f98433a5bd5c5c3f#diff-9b74bd0cfaa90b601d80713c7bd56be4R2475

So that userspace knows there might be a global offset between the 2 
times and is able to present it.

agree on this. Delta ns1-ns0 can be interpreted as max drift.
Measurement on my KBL system were in the order of a few microseconds 
(~30us).
I guess we might be able to setup the correlation point better 
(masking interruption?) to reduce the delta.

already using spin_lock. Do you mean NMI?


I don't actually know much on this point.
if spin_lock is the best we can do, then that's it :)



Thanks,

-
Lionel


On 07/12/17 00:57, Robert Bragg wrote:



On Thu, Dec 7, 2017 at 12:48 AM, Robert Bragg <mailto:rob...@sixbynine.org>> wrote:



at least from what I wrote back then it looks like I was seeing
a drift of a few milliseconds per second on SKL. I vaguely
recall it being much worse given the frequency constants we had
for Haswell.


Sorry I didn't actually re-read my own message properly before 
referencing it :) Apparently the 2ms per second drift was for 
Haswell, so presumably not quite so bad for SKL.


- Robert



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









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


Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc : Decoupling ADS and logs from submission

2017-12-28 Thread Sagar Arun Kamble



On 12/28/2017 4:18 AM, Sujaritha Sundaresan wrote:

The Additional Data Struct (ADS) contains objects that are required by
GuC post FW load and are not necessarily submission-only. Even with
submission disabled we may require something inside the ADS, so it
makes more sense for them to be always created.

Similarly, we still want to access GuC logs and even if GuC submission
is disable

we will need access to GuC logs even if GuC submission is disabled

  to debug issues with GuC loading or with whatever we're using
GuC for. To make a concrete example, the pages used by GuC to save state
during suspend are allocated as part of the ADS.
This statement is no more true as we have made change to pass 
shared_data during suspend
and not ads. Nonetheless I agree on the change to move ads alloc/dealloc 
out of submission

paths.


Signed-off-by: Sujaritha Sundaresan 
Cc: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 

with above changes
Reviewed-by: Sagar Arun Kamble 

---
  drivers/gpu/drm/i915/Makefile   |   1 +
  drivers/gpu/drm/i915/intel_guc.c|  18 
  drivers/gpu/drm/i915/intel_guc_ads.c| 151 
  drivers/gpu/drm/i915/intel_guc_ads.h|  33 ++
  drivers/gpu/drm/i915/intel_guc_submission.c | 134 
  5 files changed, 203 insertions(+), 134 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/intel_guc_ads.c
  create mode 100644 drivers/gpu/drm/i915/intel_guc_ads.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 091aef2..4d9e2f8 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -83,6 +83,7 @@ i915-y += i915_cmd_parser.o \
  i915-y += intel_uc.o \
  intel_uc_fw.o \
  intel_guc.o \
+ intel_guc_ads.o \
  intel_guc_ct.o \
  intel_guc_fw.o \
  intel_guc_log.o \
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 3c6bf5a..50b4725 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -23,6 +23,7 @@
   */
  
  #include "intel_guc.h"

+#include "intel_guc_ads.h"
  #include "intel_guc_submission.h"
  #include "i915_drv.h"
  
@@ -163,10 +164,25 @@ int intel_guc_init(struct intel_guc *guc)

return ret;
GEM_BUG_ON(!guc->shared_data);
  
+	ret = intel_guc_log_create(guc);

+   if (ret)
+   goto err_shared;
+
+   ret = intel_guc_ads_create(guc);
+   if (ret)
+   goto err_log;
+   GEM_BUG_ON(!guc->ads_vma);
+
/* We need to notify the guc whenever we change the GGTT */
i915_ggtt_enable_guc(dev_priv);
  
  	return 0;

+
+err_log:
+   intel_guc_log_destroy(guc);
+err_shared:
+   guc_shared_data_destroy(guc);
+   return ret;
  }
  
  void intel_guc_fini(struct intel_guc *guc)

@@ -174,6 +190,8 @@ void intel_guc_fini(struct intel_guc *guc)
struct drm_i915_private *dev_priv = guc_to_i915(guc);
  
  	i915_ggtt_disable_guc(dev_priv);

+   intel_guc_ads_destroy(guc);
+   intel_guc_log_destroy(guc);
guc_shared_data_destroy(guc);
  }
  
diff --git a/drivers/gpu/drm/i915/intel_guc_ads.c b/drivers/gpu/drm/i915/intel_guc_ads.c

new file mode 100644
index 000..f6066bc
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_guc_ads.c
@@ -0,0 +1,151 @@
+/*
+ * Copyright © 2014-2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "intel_guc_ads.h"
+#include "intel_uc.h"
+#include "i915_drv.h"
+
+/*
+ * The Additional Data Struct (ADS) has pointers for different buffers used by
+ * the GuC. One single gem object contains the ADS struct itself (guc_ads), the
+ * scheduling policies (guc_policies), a structure describing a collection of
+ * registe

Re: [Intel-gfx] [v2 PATCH 2/2] drm/i915/guc : GEM_BUG_ON on invoking GuC reset function

2017-12-28 Thread Sagar Arun Kamble



On 12/28/2017 4:18 AM, Sujaritha Sundaresan wrote:

Instead of returning -EINVAL, GEM_BUG_ON when GuC reset is invoked for
platforms not supporting as we don't expect to invoke it.

v2: re-wording commit message and subject (Sagar)

Signed-off-by: Sujaritha Sundaresan 
Cc: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 

Reviewed-by: Sagar Arun Kamble 

---
  drivers/gpu/drm/i915/intel_uncore.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 89547b61..94e1fb3 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1936,8 +1936,7 @@ int intel_reset_guc(struct drm_i915_private *dev_priv)
  {
int ret;
  
-	if (!HAS_GUC(dev_priv))

-   return -EINVAL;
+   GEM_BUG_ON(!HAS_GUC(dev_priv));
  
  	intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);

ret = gen6_hw_domain_reset(dev_priv, GEN9_GRDOM_GUC);


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


Re: [Intel-gfx] [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events

2018-01-02 Thread Sagar Arun Kamble



On 12/28/2017 10:43 PM, Lionel Landwerlin wrote:

On 26/12/17 05:32, Sagar Arun Kamble wrote:




On 12/22/2017 3:46 PM, Lionel Landwerlin wrote:

On 22/12/17 09:30, Sagar Arun Kamble wrote:




On 12/21/2017 6:29 PM, Lionel Landwerlin wrote:

Some more findings I made while playing with this series & GPUTop.
Turns out the 2ms drift per second is due to timecounter. Adding 
the delta this way :


https://github.com/djdeath/linux/commit/7b002cb360483e331053aec0f98433a5bd5c5c3f#diff-9b74bd0cfaa90b601d80713c7bd56be4R607

Eliminates the drift.
I see two imp. changes 1. approximation of start time during 
init_timecounter 2. overflow handling in delta accumulation.
With these incorporated, I guess timecounter should also work in 
same fashion.


I think the arithmetic in timecounter is inherently lossy and that's 
why we're seeing a drift.
Could you share details about platform, scenario in which 2ms drift 
per second is being seen with timecounter.

I did not observe this on SKL.


The 2ms drift was on SKL GT4.

I have checked the timecounter arithmetic. Accuracy is very high (of the 
order of micro ns per tick).
I interpreted maxsec parameter in calculation of mult/shift using 
clocks_calc_mult_shift function as total time covered by counter
but actually it controls the conversion accuracy. Since we want best 
possible accuracy passing zero should be preferred there.
For instance below are the mult/shift values and time reported for 10 
minutes with these values for SKL GT2 12mhz.
As you can see drift due to calculation is only about 2us. We should 
check by passing zero to clocks_calc_mult_shift and
delta handling new added with timecounter on SKL GT4. 2ms is huge drift 
and it is very unlikely related to these calculations.


maxsec, mult, shift, tick time (mult/2^shift), total time 
(10*60*1200 * tick time), drift due to calculation

0, 2796202667, 25, 83.3334326, 600,000,000,071.525, 71ns
3000, 174762667, 21, 83.3349227, 600,000,001,144.409, 1144ns
6000, 87381333, 20, 83.3301544, 599,999,997,711.181, 2289ns
With the patch above, I'm seeing only a ~40us drift over ~7seconds of 
recording both perf tracepoints & i915 perf reports.
I'm tracking the kernel tracepoints adding gem requests and the i915 
perf reports.
Here a screenshot at the beginning of the 7s recording : 
https://i.imgur.com/hnexgjQ.png (you can see the gem request add 
before the work starts in the i915 perf reports).
At the end of the recording, the gem requests appear later than the 
work in the i915 perf report : https://i.imgur.com/oCd0C9T.png



Looks like we need to have error margin of only few microseconds :)
I'll try to prepare some IGT tests that show the drift using perf & 
i915 perf, so we can run those on different platforms.
I tend to mostly test on a SKL GT4 & KBL GT2, but BXT definitely needs 
more attention...



Could we be using it wrong?

if we use two changes highlighted above with timecounter maybe we 
will get same results as your current implementation.
In the patch above, I think there is still a drift because of the 
potential fractional part loss at every delta we add.
But it should only be a fraction of a nanosecond multiplied by the 
number of reports over a period of time.
With a report every 1us, that should still be much less than a 1ms 
of drift over 1s.


timecounter interface takes care of fractional parts so that should 
help us.
we can either go with timecounter or our own implementation provided 
conversions are precise.


Looking at clocks_calc_mult_shift(), it seems clear to me that there 
is less precision when using timecounter :


 /*
  * Find the conversion shift/mult pair which has the best
  * accuracy and fits the maxsec conversion range:
  */

We can improve upon this by passing zero as maxsec to 
clocks_calc_mult_shift.
On the other hand, there is a performance penalty for doing a div64 
for every report.


We can probably do better by always computing the clock using the 
entire delta rather than the accumulated delta.


issue is that the reported clock cycles in the OA report is 32bits 
LSB of GPU TS whereas counter is 36bits. Hence we will need to
accumulate the delta. ofc there is assumption that two reports can't 
be spaced with count value of 0x apart.


You're right :)
I thought maybe we could do this :

Look at teduhe opening period parameter, if it's superior to the 
period of timestamps wrapping, make sure we schle some work on kernel 
context to generate a context switch report (like at least once every 
6 minutes on gen9).



Looks fine to me.
Timelines of perf i915 tracepoints & OA reports now make a lot 
more sense.


There is still the issue that reading the CPU clock & the RCS 
timestamp is inherently not atomic. So there is a delta there.
I think we should add a new i915 perf record type to express the 
delta that we measure this way :


https://github.com/dj

Re: [Intel-gfx] [RFC] drm/i915: Add a new modparam for customized ring multiplier

2018-01-03 Thread Sagar Arun Kamble
Since ring frequency programming needs consideration of both IA and GT 
frequency requests I think keeping the logic
to program the ring frequency table in driver that monitors both IA/GT 
busyness and power budgets like intel_ips
will be more appropriate. intel_ips is relying on global load derived 
from all CPUs.
I understand that power awareness and busyness based policy might be 
trickier but having that as tunable will give better flexibility.


On 1/3/2018 11:51 PM, Yaodong Li wrote:


You are thinking of plugging into intel_pstate to make it smarter 
for ia freq transitions?
Yep. This seems a correct step to give some automatic support instead 
of parameter/hardcoded multiplier.


Does this mean we should use cpufreq/intel_pstate based approach 
instead of the current modparam solution for Gen9?


Some concerns and questions about intel_pstate approach:
a) Currently, we cannot get the accurate pstate/target freq value from 
cpufreq in intel_pstate active mode since
 these values won't be exported to cpufreq layer, so if we won't 
change intel_pstate code then we only can get

 the max cpu freq of a new policy.
b) intel_pstate policy is attached to each logic cpu, which means we 
will receive policy/freq transition notification
    for each logic cpu freq change. One question is how we are going 
to decide the freq of the ring? just use the max

    cpu freq reported?
c) With the intel_pstate approach we may still run into thermal 
throttling, in this case, can a certain cooling device

    be triggered to lower the cpu freq?

Thanks and Regards,
-Jackie



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


[Intel-gfx] [PATCH v3 00/12] GuC Interrupts/Log updates

2018-01-04 Thread Sagar Arun Kamble
This series addresses following features/fixes:
1. Restructuring to move GuC interrupts related functions to guc.c
2. Making GuC interrupts enable/disable reference based and tying up with
   logging at all places.
3. Handle suspend/resume/reset for GuC interrupts.
4. Logging fixes about RPM wakeref and skipping relay release during
   uc_fini.

Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Radoslaw Szwichtenberg 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 

Sagar Arun Kamble (12):
  drm/i915: Export low level PM IRQ functions to use from GuC functions
  drm/i915/guc: Move GuC interrupts related functions from i915_irq.c to
intel_guc.c
  drm/i915/guc: Pass intel_guc struct parameter to GuC interrupts
functions
  drm/i915/guc: Add description and comments about guc_log_level
parameter
  drm/i915/guc: Fix GuC interrupts disabling with logging
  drm/i915/guc: Separate creation/release of runtime logging data from
base logging data
  drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts
  drm/i915/guc: Make guc_log_level parameter immutable
  drm/i915/guc: Make GuC log related functions depend only on log level
  drm/i915/guc: Add client support to enable/disable GuC interrupts
  drm/i915/guc: Restore GuC interrupts across suspend/reset if enabled
  HAX: drm/i915/guc: enable GuC submission/logging for CI

 drivers/gpu/drm/i915/i915_debugfs.c  |   8 +-
 drivers/gpu/drm/i915/i915_drv.c  |   4 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c  |   8 +-
 drivers/gpu/drm/i915/i915_irq.c  |  78 ++-
 drivers/gpu/drm/i915/i915_params.c   |   3 +-
 drivers/gpu/drm/i915/i915_params.h   |   4 +-
 drivers/gpu/drm/i915/intel_display.c |   2 +
 drivers/gpu/drm/i915/intel_drv.h |   7 +-
 drivers/gpu/drm/i915/intel_guc.c | 141 +--
 drivers/gpu/drm/i915/intel_guc.h |  13 +++-
 drivers/gpu/drm/i915/intel_guc_log.c |  64 +++-
 drivers/gpu/drm/i915/intel_guc_log.h |   8 ++
 drivers/gpu/drm/i915/intel_uc.c  |  29 ---
 13 files changed, 225 insertions(+), 144 deletions(-)

-- 
1.9.1

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


[Intel-gfx] [PATCH v3 01/12] drm/i915: Export low level PM IRQ functions to use from GuC functions

2018-01-04 Thread Sagar Arun Kamble
In order to separate GuC IRQ handling functions from i915_irq.c we need
to export the low level pm irq handlers. Export pm_iir, reset_pm_iir and
enable/disable_pm_irq functions.

v2-v3: Rebase.

Suggested-by: Michal Wajdeczko 
Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_irq.c  | 8 
 drivers/gpu/drm/i915/intel_drv.h | 4 
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 3517c65..7a9e1a7 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -306,7 +306,7 @@ void gen5_disable_gt_irq(struct drm_i915_private *dev_priv, 
uint32_t mask)
ilk_update_gt_irq(dev_priv, mask, 0);
 }
 
-static i915_reg_t gen6_pm_iir(struct drm_i915_private *dev_priv)
+i915_reg_t gen6_pm_iir(struct drm_i915_private *dev_priv)
 {
return INTEL_GEN(dev_priv) >= 8 ? GEN8_GT_IIR(2) : GEN6_PMIIR;
 }
@@ -369,7 +369,7 @@ void gen6_mask_pm_irq(struct drm_i915_private *dev_priv, 
u32 mask)
__gen6_mask_pm_irq(dev_priv, mask);
 }
 
-static void gen6_reset_pm_iir(struct drm_i915_private *dev_priv, u32 
reset_mask)
+void gen6_reset_pm_iir(struct drm_i915_private *dev_priv, u32 reset_mask)
 {
i915_reg_t reg = gen6_pm_iir(dev_priv);
 
@@ -380,7 +380,7 @@ static void gen6_reset_pm_iir(struct drm_i915_private 
*dev_priv, u32 reset_mask)
POSTING_READ(reg);
 }
 
-static void gen6_enable_pm_irq(struct drm_i915_private *dev_priv, u32 
enable_mask)
+void gen6_enable_pm_irq(struct drm_i915_private *dev_priv, u32 enable_mask)
 {
lockdep_assert_held(&dev_priv->irq_lock);
 
@@ -390,7 +390,7 @@ static void gen6_enable_pm_irq(struct drm_i915_private 
*dev_priv, u32 enable_mas
/* unmask_pm_irq provides an implicit barrier (POSTING_READ) */
 }
 
-static void gen6_disable_pm_irq(struct drm_i915_private *dev_priv, u32 
disable_mask)
+void gen6_disable_pm_irq(struct drm_i915_private *dev_priv, u32 disable_mask)
 {
lockdep_assert_held(&dev_priv->irq_lock);
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 30f791f..3a7e18c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1234,8 +1234,12 @@ void intel_pch_fifo_underrun_irq_handler(struct 
drm_i915_private *dev_priv,
 /* i915_irq.c */
 void gen5_enable_gt_irq(struct drm_i915_private *dev_priv, uint32_t mask);
 void gen5_disable_gt_irq(struct drm_i915_private *dev_priv, uint32_t mask);
+i915_reg_t gen6_pm_iir(struct drm_i915_private *dev_priv);
 void gen6_mask_pm_irq(struct drm_i915_private *dev_priv, u32 mask);
 void gen6_unmask_pm_irq(struct drm_i915_private *dev_priv, u32 mask);
+void gen6_reset_pm_iir(struct drm_i915_private *dev_priv, u32 reset_mask);
+void gen6_enable_pm_irq(struct drm_i915_private *dev_priv, u32 enable_mask);
+void gen6_disable_pm_irq(struct drm_i915_private *dev_priv, u32 disable_mask);
 void gen6_reset_rps_interrupts(struct drm_i915_private *dev_priv);
 void gen6_enable_rps_interrupts(struct drm_i915_private *dev_priv);
 void gen6_disable_rps_interrupts(struct drm_i915_private *dev_priv);
-- 
1.9.1

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


[Intel-gfx] [PATCH v3 04/12] drm/i915/guc: Add description and comments about guc_log_level parameter

2018-01-04 Thread Sagar Arun Kamble
guc_log_level parameter takes effect when GuC is loaded which is
controlled through enable_guc parameter. Add this relation info.
in parameter description and documentation.
Earlier, this patch was added to sanitize guc_log_level like old
GuC parameters enable_guc_loading/submission. With new parameter
enable_guc, sanitization of guc_log_level is no more needed.

v2: Added documentation to intel_guc_log.c and param description
about GuC loading dependency. (Michal Wajdeczko)

v3: Removed sanitization of module parameter guc_log_level.
Previous review comments not applicable now.

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin  #v2
---
 drivers/gpu/drm/i915/i915_params.c   | 3 ++-
 drivers/gpu/drm/i915/intel_guc_log.c | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index b5f3eb4..a93a6ca 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -155,7 +155,8 @@ struct i915_params i915_modparams __read_mostly = {
"(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)");
 
 i915_param_named(guc_log_level, int, 0400,
-   "GuC firmware logging level (-1:disabled (default), 0-3:enabled)");
+   "GuC firmware logging level. This takes effect only if GuC is to be "
+   "loaded (depends on enable_guc) (-1:disabled (default), 0-3:enabled)");
 
 i915_param_named_unsafe(guc_firmware_path, charp, 0400,
"GuC firmware path to use instead of the default one");
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 59a9021..d0131bc 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -34,6 +34,7 @@
  * DOC: GuC firmware log
  *
  * Firmware log is enabled by setting i915.guc_log_level to non-negative level.
+ * This takes effect only if GuC is to be loaded based on enable_guc.
  * Log data is printed out via reading debugfs i915_guc_log_dump. Reading from
  * i915_guc_load_status will print out firmware loading status and scratch
  * registers value.
-- 
1.9.1

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


[Intel-gfx] [PATCH v3 06/12] drm/i915/guc: Separate creation/release of runtime logging data from base logging data

2018-01-04 Thread Sagar Arun Kamble
GuC log runtime/relay channel data will get released during i915
unregister, and only GuC log vma needs to be released during fini. To
achieve this, prepare separate helpers to create/destroy base and runtime
logging.
This separation is also needed to couple runtime log data and interrupts
handling together. In future we might not want to consider runtime data
creation failure as catastrophic to abort GuC load. Then we can ignore
the return error codes from intel_guc_log_runtime_create().

v2: Rebase.

v3: Refined usage of intel_guc_log_destroy and created new function
intel_guc_log_runtime_destroy. (Tvrtko)
Added intel_guc_log_runtime_create to separate the creation part as well.

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_guc.c |  8 +++-
 drivers/gpu/drm/i915/intel_guc_log.c | 22 --
 drivers/gpu/drm/i915/intel_guc_log.h |  2 ++
 3 files changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 14bf508d..0184c86 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -168,9 +168,13 @@ int intel_guc_init(struct intel_guc *guc)
if (ret)
goto err_shared;
 
-   ret = intel_guc_ads_create(guc);
+   ret = intel_guc_log_runtime_create(guc);
if (ret)
goto err_log;
+
+   ret = intel_guc_ads_create(guc);
+   if (ret)
+   goto err_log_runtime;
GEM_BUG_ON(!guc->ads_vma);
 
/* We need to notify the guc whenever we change the GGTT */
@@ -178,6 +182,8 @@ int intel_guc_init(struct intel_guc *guc)
 
return 0;
 
+err_log_runtime:
+   intel_guc_log_runtime_destroy(guc);
 err_log:
intel_guc_log_destroy(guc);
 err_shared:
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index d0131bc..18d1b49 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -357,7 +357,7 @@ static bool guc_log_has_runtime(struct intel_guc *guc)
return guc->log.runtime.buf_addr != NULL;
 }
 
-static int guc_log_runtime_create(struct intel_guc *guc)
+int intel_guc_log_runtime_create(struct intel_guc *guc)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
void *vaddr;
@@ -365,6 +365,9 @@ static int guc_log_runtime_create(struct intel_guc *guc)
size_t n_subbufs, subbuf_size;
int ret;
 
+   if (i915_modparams.guc_log_level < 0)
+   return 0;
+
lockdep_assert_held(&dev_priv->drm.struct_mutex);
 
GEM_BUG_ON(guc_log_has_runtime(guc));
@@ -420,7 +423,7 @@ static int guc_log_runtime_create(struct intel_guc *guc)
return ret;
 }
 
-static void guc_log_runtime_destroy(struct intel_guc *guc)
+void intel_guc_log_runtime_destroy(struct intel_guc *guc)
 {
/*
 * It's possible that the runtime stuff was never allocated because
@@ -446,7 +449,7 @@ static int guc_log_late_setup(struct intel_guc *guc)
 * handle log buffer flush interrupts would not have been done 
yet,
 * so do that now.
 */
-   ret = guc_log_runtime_create(guc);
+   ret = intel_guc_log_runtime_create(guc);
if (ret)
goto err;
}
@@ -458,7 +461,7 @@ static int guc_log_late_setup(struct intel_guc *guc)
return 0;
 
 err_runtime:
-   guc_log_runtime_destroy(guc);
+   intel_guc_log_runtime_destroy(guc);
 err:
/* logging will remain off */
i915_modparams.guc_log_level = -1;
@@ -536,12 +539,6 @@ int intel_guc_log_create(struct intel_guc *guc)
 
guc->log.vma = vma;
 
-   if (i915_modparams.guc_log_level >= 0) {
-   ret = guc_log_runtime_create(guc);
-   if (ret < 0)
-   goto err_vma;
-   }
-
/* each allocated unit is a page */
flags = GUC_LOG_VALID | GUC_LOG_NOTIFY_ON_HALF_FULL |
(GUC_LOG_DPC_PAGES << GUC_LOG_DPC_SHIFT) |
@@ -553,8 +550,6 @@ int intel_guc_log_create(struct intel_guc *guc)
 
return 0;
 
-err_vma:
-   i915_vma_unpin_and_release(&guc->log.vma);
 err:
/* logging will be off */
i915_modparams.guc_log_level = -1;
@@ -563,7 +558,6 @@ int intel_guc_log_create(struct intel_guc *guc)
 
 void intel_guc_log_destroy(struct intel_guc *guc)
 {
-   guc_log_runtime_destroy(guc);
i915_vma_unpin_and_release(&guc->log.vma);
 }
 
@@ -639,6 +633,6 @@ void i915_guc_log_unregister(struct drm_i915_private 
*dev_priv)
mutex_lock(&dev_priv->drm.struct_mutex);
/* GuC logging is currently the only user of Guc2Host interrupts */
intel_disable_guc_interrupts(&dev_priv->guc);
-   guc_log_runtime_destroy(&

[Intel-gfx] [PATCH v3 03/12] drm/i915/guc: Pass intel_guc struct parameter to GuC interrupts functions

2018-01-04 Thread Sagar Arun Kamble
GuC interrupts handling functions are GuC specific functions hence update
the parameter from dev_priv to intel_guc struct.

v2-v3: Rebase.

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_irq.c  |  2 +-
 drivers/gpu/drm/i915/intel_guc.c | 22 +++---
 drivers/gpu/drm/i915/intel_guc.h |  8 
 drivers/gpu/drm/i915/intel_guc_log.c |  8 +++-
 drivers/gpu/drm/i915/intel_uc.c  |  8 
 5 files changed, 27 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 3f4eff9..a1ae057 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1447,7 +1447,7 @@ static void gen8_gt_irq_handler(struct drm_i915_private 
*dev_priv,
gen6_rps_irq_handler(dev_priv, gt_iir[2]);
 
if (gt_iir[2] & dev_priv->pm_guc_events)
-   intel_guc_irq_handler(dev_priv, gt_iir[2]);
+   intel_guc_irq_handler(&dev_priv->guc, gt_iir[2]);
 }
 
 static bool bxt_port_hotplug_long_detect(enum port port, u32 val)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index e95ff2d..14bf508d 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -400,7 +400,7 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
 
-   intel_disable_guc_interrupts(dev_priv);
+   intel_disable_guc_interrupts(guc);
 
data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
/* any value greater than GUC_POWER_D0 */
@@ -446,7 +446,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
return 0;
 
if (i915_modparams.guc_log_level >= 0)
-   intel_enable_guc_interrupts(dev_priv);
+   intel_enable_guc_interrupts(guc);
 
data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
data[1] = GUC_POWER_D0;
@@ -508,15 +508,19 @@ u32 intel_guc_wopcm_size(struct drm_i915_private 
*dev_priv)
return wopcm_size;
 }
 
-void intel_reset_guc_interrupts(struct drm_i915_private *dev_priv)
+void intel_reset_guc_interrupts(struct intel_guc *guc)
 {
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
spin_lock_irq(&dev_priv->irq_lock);
gen6_reset_pm_iir(dev_priv, dev_priv->pm_guc_events);
spin_unlock_irq(&dev_priv->irq_lock);
 }
 
-void intel_enable_guc_interrupts(struct drm_i915_private *dev_priv)
+void intel_enable_guc_interrupts(struct intel_guc *guc)
 {
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
spin_lock_irq(&dev_priv->irq_lock);
if (!dev_priv->guc.interrupts_enabled) {
WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) &
@@ -527,8 +531,10 @@ void intel_enable_guc_interrupts(struct drm_i915_private 
*dev_priv)
spin_unlock_irq(&dev_priv->irq_lock);
 }
 
-void intel_disable_guc_interrupts(struct drm_i915_private *dev_priv)
+void intel_disable_guc_interrupts(struct intel_guc *guc)
 {
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
spin_lock_irq(&dev_priv->irq_lock);
dev_priv->guc.interrupts_enabled = false;
 
@@ -537,11 +543,13 @@ void intel_disable_guc_interrupts(struct drm_i915_private 
*dev_priv)
spin_unlock_irq(&dev_priv->irq_lock);
synchronize_irq(dev_priv->drm.irq);
 
-   intel_reset_guc_interrupts(dev_priv);
+   intel_reset_guc_interrupts(guc);
 }
 
-void intel_guc_irq_handler(struct drm_i915_private *dev_priv, u32 gt_iir)
+void intel_guc_irq_handler(struct intel_guc *guc, u32 gt_iir)
 {
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
if (gt_iir & GEN9_GUC_TO_HOST_INT_EVENT) {
/* Sample the log buffer flush related bits & clear them out now
 * itself from the message identity register to minimize the
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index c37d34d..49f33b9 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -131,9 +131,9 @@ static inline u32 guc_ggtt_offset(struct i915_vma *vma)
 int intel_guc_resume(struct drm_i915_private *dev_priv);
 struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size);
 u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
-void intel_reset_guc_interrupts(struct drm_i915_private *dev_priv);
-void intel_enable_guc_interrupts(struct drm_i915_private *dev_priv);
-void intel_disable_guc_interrupts(struct drm_i915_private *dev_priv);
-void intel_guc_irq_handler(struct drm_i915_private *dev_priv, u32 pm_iir);
+void intel_reset_guc_interrupts(struct intel_guc *guc);
+void intel_enable_guc_interrupts(struct intel_guc *guc);
+void i

[Intel-gfx] [PATCH v3 05/12] drm/i915/guc: Fix GuC interrupts disabling with logging

2018-01-04 Thread Sagar Arun Kamble
With guc_log_unregister disabling runtime logging and interrupts, there
is no need to disable interrupts during uc_fini_hw hence it is removed.
With GuC CT buffer mechanism, interrupt disabling can be added later at
a point where CT mechanism ceases.

v2: Rebase.

v3: Moved this patch earlier in the series. (Tvrtko)

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_uc.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index f82453b..bc7f549 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -377,7 +377,4 @@ void intel_uc_fini_hw(struct drm_i915_private *dev_priv)
intel_guc_submission_disable(guc);
 
guc_disable_communication(guc);
-
-   if (USES_GUC_SUBMISSION(dev_priv))
-   intel_disable_guc_interrupts(guc);
 }
-- 
1.9.1

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


[Intel-gfx] [PATCH v3 02/12] drm/i915/guc: Move GuC interrupts related functions from i915_irq.c to intel_guc.c

2018-01-04 Thread Sagar Arun Kamble
GuC interrupts handling is core GuC functionality. Better to keep it
with other core functions in intel_guc.c. Since they are used from
uC functions, GuC logging and i915 irq handling keeping them grouped in
intel_guc.c instead of intel_uc.c.

v2-v3: Rebase.

Suggested-by: Michal Wajdeczko 
Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_irq.c  | 70 +--
 drivers/gpu/drm/i915/intel_drv.h |  3 --
 drivers/gpu/drm/i915/intel_guc.c | 71 +++-
 drivers/gpu/drm/i915/intel_guc.h |  4 ++
 drivers/gpu/drm/i915/intel_guc_log.c |  6 +--
 drivers/gpu/drm/i915/intel_uc.c  |  8 ++--
 6 files changed, 81 insertions(+), 81 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7a9e1a7..3f4eff9 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -203,7 +203,6 @@ static void gen2_assert_iir_is_zero(struct drm_i915_private 
*dev_priv,
 } while (0)
 
 static void gen6_rps_irq_handler(struct drm_i915_private *dev_priv, u32 
pm_iir);
-static void gen9_guc_irq_handler(struct drm_i915_private *dev_priv, u32 
pm_iir);
 
 /* For display hotplug interrupt */
 static inline void
@@ -450,38 +449,6 @@ void gen6_disable_rps_interrupts(struct drm_i915_private 
*dev_priv)
gen6_reset_rps_interrupts(dev_priv);
 }
 
-void gen9_reset_guc_interrupts(struct drm_i915_private *dev_priv)
-{
-   spin_lock_irq(&dev_priv->irq_lock);
-   gen6_reset_pm_iir(dev_priv, dev_priv->pm_guc_events);
-   spin_unlock_irq(&dev_priv->irq_lock);
-}
-
-void gen9_enable_guc_interrupts(struct drm_i915_private *dev_priv)
-{
-   spin_lock_irq(&dev_priv->irq_lock);
-   if (!dev_priv->guc.interrupts_enabled) {
-   WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) &
-  dev_priv->pm_guc_events);
-   dev_priv->guc.interrupts_enabled = true;
-   gen6_enable_pm_irq(dev_priv, dev_priv->pm_guc_events);
-   }
-   spin_unlock_irq(&dev_priv->irq_lock);
-}
-
-void gen9_disable_guc_interrupts(struct drm_i915_private *dev_priv)
-{
-   spin_lock_irq(&dev_priv->irq_lock);
-   dev_priv->guc.interrupts_enabled = false;
-
-   gen6_disable_pm_irq(dev_priv, dev_priv->pm_guc_events);
-
-   spin_unlock_irq(&dev_priv->irq_lock);
-   synchronize_irq(dev_priv->drm.irq);
-
-   gen9_reset_guc_interrupts(dev_priv);
-}
-
 /**
  * bdw_update_port_irq - update DE port interrupt
  * @dev_priv: driver private
@@ -1480,7 +1447,7 @@ static void gen8_gt_irq_handler(struct drm_i915_private 
*dev_priv,
gen6_rps_irq_handler(dev_priv, gt_iir[2]);
 
if (gt_iir[2] & dev_priv->pm_guc_events)
-   gen9_guc_irq_handler(dev_priv, gt_iir[2]);
+   intel_guc_irq_handler(dev_priv, gt_iir[2]);
 }
 
 static bool bxt_port_hotplug_long_detect(enum port port, u32 val)
@@ -1757,41 +1724,6 @@ static void gen6_rps_irq_handler(struct drm_i915_private 
*dev_priv, u32 pm_iir)
}
 }
 
-static void gen9_guc_irq_handler(struct drm_i915_private *dev_priv, u32 gt_iir)
-{
-   if (gt_iir & GEN9_GUC_TO_HOST_INT_EVENT) {
-   /* Sample the log buffer flush related bits & clear them out now
-* itself from the message identity register to minimize the
-* probability of losing a flush interrupt, when there are back
-* to back flush interrupts.
-* There can be a new flush interrupt, for different log buffer
-* type (like for ISR), whilst Host is handling one (for DPC).
-* Since same bit is used in message register for ISR & DPC, it
-* could happen that GuC sets the bit for 2nd interrupt but Host
-* clears out the bit on handling the 1st interrupt.
-*/
-   u32 msg, flush;
-
-   msg = I915_READ(SOFT_SCRATCH(15));
-   flush = msg & (INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED |
-  INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER);
-   if (flush) {
-   /* Clear the message bits that are handled */
-   I915_WRITE(SOFT_SCRATCH(15), msg & ~flush);
-
-   /* Handle flush interrupt in bottom half */
-   queue_work(dev_priv->guc.log.runtime.flush_wq,
-  &dev_priv->guc.log.runtime.flush_work);
-
-   dev_priv->guc.log.flush_interrupt_count++;
-   } else {
-   /* Not clearing of unhandled event bits won't result in
-* re-triggering of the interrupt.
- 

[Intel-gfx] [PATCH v3 07/12] drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts

2018-01-04 Thread Sagar Arun Kamble
Disabling GuC interrupts involves access to GuC IRQ control registers
hence ensure device is RPM awake.

v2: Add comment about need to synchronize flush work and log runtime
destroy

v3: Moved patch earlier in the series and removed comment about future
work. (Tvrtko)

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_guc_log.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 18d1b49..3a895a3 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -632,7 +632,10 @@ void i915_guc_log_unregister(struct drm_i915_private 
*dev_priv)
 
mutex_lock(&dev_priv->drm.struct_mutex);
/* GuC logging is currently the only user of Guc2Host interrupts */
+   intel_runtime_pm_get(dev_priv);
intel_disable_guc_interrupts(&dev_priv->guc);
+   intel_runtime_pm_put(dev_priv);
+
intel_guc_log_runtime_destroy(&dev_priv->guc);
mutex_unlock(&dev_priv->drm.struct_mutex);
 }
-- 
1.9.1

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


[Intel-gfx] [PATCH v3 11/12] drm/i915/guc: Restore GuC interrupts across suspend/reset if enabled

2018-01-04 Thread Sagar Arun Kamble
In order to override the disable/enable control of GuC interrupts during
suspend/reset cycle we are creating two new functions suspend/restore
guc_interrupts which check if interrupts were enabled and disable them
on suspend and enable them on resume. They are used to restore interrupts
across reset as well.

Further restructuring of runtime_pm_enable/disable_interrupts and
suspend/restore_guc_interrupts will be done in upcoming patches.

v2: Rebase.

v3: Updated suspend/restore with the new low level get/put functions.
(Tvrtko)

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_display.c |  2 ++
 drivers/gpu/drm/i915/intel_guc.c | 32 
 drivers/gpu/drm/i915/intel_guc.h |  2 ++
 3 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0cd3559..2e0db53 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3676,8 +3676,10 @@ void intel_finish_reset(struct drm_i915_private 
*dev_priv)
 * The display has been reset as well,
 * so need a full re-initialization.
 */
+   intel_suspend_guc_interrupts(&dev_priv->guc);
intel_runtime_pm_disable_interrupts(dev_priv);
intel_runtime_pm_enable_interrupts(dev_priv);
+   intel_restore_guc_interrupts(&dev_priv->guc);
 
intel_pps_unlock_regs_wa(dev_priv);
intel_modeset_init_hw(dev);
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index d356c40..28a418a 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -406,8 +406,7 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
 
-   if (guc->log.level >= 0)
-   intel_put_guc_interrupts(guc, GUC_INTR_CLIENT_LOG);
+   intel_suspend_guc_interrupts(guc);
 
data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
/* any value greater than GUC_POWER_D0 */
@@ -452,8 +451,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
 
-   if (guc->log.level >= 0)
-   intel_get_guc_interrupts(guc, GUC_INTR_CLIENT_LOG);
+   intel_restore_guc_interrupts(guc);
 
data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
data[1] = GUC_POWER_D0;
@@ -548,6 +546,16 @@ void intel_get_guc_interrupts(struct intel_guc *guc, enum 
guc_intr_client id)
spin_unlock_irq(&dev_priv->irq_lock);
 }
 
+void intel_restore_guc_interrupts(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
+   spin_lock_irq(&dev_priv->irq_lock);
+   if (guc->interrupt_clients)
+   __intel_get_guc_interrupts(guc);
+   spin_unlock_irq(&dev_priv->irq_lock);
+}
+
 static void __intel_put_guc_interrupts(struct intel_guc *guc)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
@@ -576,6 +584,22 @@ void intel_put_guc_interrupts(struct intel_guc *guc, enum 
guc_intr_client id)
intel_reset_guc_interrupts(guc);
 }
 
+void intel_suspend_guc_interrupts(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
+   spin_lock_irq(&dev_priv->irq_lock);
+   if (!guc->interrupt_clients) {
+   spin_unlock_irq(&dev_priv->irq_lock);
+   return;
+   }
+   __intel_put_guc_interrupts(guc);
+   spin_unlock_irq(&dev_priv->irq_lock);
+   synchronize_irq(dev_priv->drm.irq);
+
+   intel_reset_guc_interrupts(guc);
+}
+
 void intel_guc_irq_handler(struct intel_guc *guc, u32 gt_iir)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index af74392..2c14781 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -140,5 +140,7 @@ static inline u32 guc_ggtt_offset(struct i915_vma *vma)
 void intel_get_guc_interrupts(struct intel_guc *guc, enum guc_intr_client id);
 void intel_put_guc_interrupts(struct intel_guc *guc, enum guc_intr_client id);
 void intel_guc_irq_handler(struct intel_guc *guc, u32 pm_iir);
+void intel_suspend_guc_interrupts(struct intel_guc *guc);
+void intel_restore_guc_interrupts(struct intel_guc *guc);
 
 #endif
-- 
1.9.1

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


[Intel-gfx] [PATCH v3 08/12] drm/i915/guc: Make guc_log_level parameter immutable

2018-01-04 Thread Sagar Arun Kamble
This patch introduces i915 internal state variable in GuC log struct,
"level" which will be copied from guc_log_level modparam during i915
load and thereafter be available for user updates. This will make
guc_log_level parameter immutable.

Suggested-by: Tvrtko Ursulin 
Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  2 +-
 drivers/gpu/drm/i915/intel_guc.c |  6 +++---
 drivers/gpu/drm/i915/intel_guc_log.c | 23 ++-
 drivers/gpu/drm/i915/intel_guc_log.h |  6 ++
 drivers/gpu/drm/i915/intel_uc.c  | 11 +--
 5 files changed, 29 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2bb6307..16f9a95 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2459,7 +2459,7 @@ static int i915_guc_log_control_get(void *data, u64 *val)
if (!dev_priv->guc.log.vma)
return -EINVAL;
 
-   *val = i915_modparams.guc_log_level;
+   *val = dev_priv->guc.log.level;
 
return 0;
 }
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 0184c86..d351642 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -253,9 +253,9 @@ void intel_guc_init_params(struct intel_guc *guc)
 
params[GUC_CTL_LOG_PARAMS] = guc->log.flags;
 
-   if (i915_modparams.guc_log_level >= 0) {
+   if (guc->log.level >= 0) {
params[GUC_CTL_DEBUG] =
-   i915_modparams.guc_log_level << GUC_LOG_VERBOSITY_SHIFT;
+   guc->log.level << GUC_LOG_VERBOSITY_SHIFT;
} else {
params[GUC_CTL_DEBUG] = GUC_LOG_DISABLED;
}
@@ -451,7 +451,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
 
-   if (i915_modparams.guc_log_level >= 0)
+   if (guc->log.level >= 0)
intel_enable_guc_interrupts(guc);
 
data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 3a895a3..d979830 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -148,7 +148,7 @@ static int guc_log_relay_file_create(struct intel_guc *guc)
struct dentry *log_dir;
int ret;
 
-   if (i915_modparams.guc_log_level < 0)
+   if (guc->log.level < 0)
return 0;
 
/* For now create the log file in /sys/kernel/debug/dri/0 dir */
@@ -365,7 +365,7 @@ int intel_guc_log_runtime_create(struct intel_guc *guc)
size_t n_subbufs, subbuf_size;
int ret;
 
-   if (i915_modparams.guc_log_level < 0)
+   if (guc->log.level < 0)
return 0;
 
lockdep_assert_held(&dev_priv->drm.struct_mutex);
@@ -427,7 +427,7 @@ void intel_guc_log_runtime_destroy(struct intel_guc *guc)
 {
/*
 * It's possible that the runtime stuff was never allocated because
-* guc_log_level was < 0 at the time
+* guc->log.level was < 0 at the time
 **/
if (!guc_log_has_runtime(guc))
return;
@@ -464,7 +464,7 @@ static int guc_log_late_setup(struct intel_guc *guc)
intel_guc_log_runtime_destroy(guc);
 err:
/* logging will remain off */
-   i915_modparams.guc_log_level = -1;
+   guc->log.level = -1;
return ret;
 }
 
@@ -485,7 +485,7 @@ static void guc_log_capture_logs(struct intel_guc *guc)
 static void guc_flush_logs(struct intel_guc *guc)
 {
if (!USES_GUC_SUBMISSION(dev_priv) ||
-   (i915_modparams.guc_log_level < 0))
+   guc->log.level < 0)
return;
 
/* First disable the interrupts, will be renabled afterwards */
@@ -513,9 +513,6 @@ int intel_guc_log_create(struct intel_guc *guc)
 
GEM_BUG_ON(guc->log.vma);
 
-   if (i915_modparams.guc_log_level > GUC_LOG_VERBOSITY_MAX)
-   i915_modparams.guc_log_level = GUC_LOG_VERBOSITY_MAX;
-
/* The first page is to save log buffer state. Allocate one
 * extra page for others in case for overlap */
size = (1 + GUC_LOG_DPC_PAGES + 1 +
@@ -552,7 +549,7 @@ int intel_guc_log_create(struct intel_guc *guc)
 
 err:
/* logging will be off */
-   i915_modparams.guc_log_level = -1;
+   guc->log.level = -1;
return ret;
 }
 
@@ -575,7 +572,7 @@ int i915_guc_log_control(struct drm_i915_private *dev_priv, 
u64 control_val)
return -EINVAL;
 
/* This combination doesn't make sense & won't have any effect */
-   if (!log_param.logging_enabled && 

[Intel-gfx] [PATCH v3 12/12] HAX: drm/i915/guc: enable GuC submission/logging for CI

2018-01-04 Thread Sagar Arun Kamble
Also 1) revert ("drm/i915/guc: Assert that we switch between
known ggtt->invalidate functions")
2) fix RPM resume interrupt enabling w.r.t GuC resume
3) disable guc log streaming DRM logs
---
 drivers/gpu/drm/i915/i915_drv.c  | 4 ++--
 drivers/gpu/drm/i915/i915_gem_gtt.c  | 8 ++--
 drivers/gpu/drm/i915/i915_params.h   | 4 ++--
 drivers/gpu/drm/i915/intel_guc_log.c | 2 +-
 4 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6c8da9d..c8460c5 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2659,6 +2659,8 @@ static int intel_runtime_resume(struct device *kdev)
if (intel_uncore_unclaimed_mmio(dev_priv))
DRM_DEBUG_DRIVER("Unclaimed access during suspend, bios?\n");
 
+   intel_runtime_pm_enable_interrupts(dev_priv);
+
intel_guc_resume(dev_priv);
 
if (IS_GEN9_LP(dev_priv)) {
@@ -2682,8 +2684,6 @@ static int intel_runtime_resume(struct device *kdev)
i915_gem_init_swizzling(dev_priv);
i915_gem_restore_fences(dev_priv);
 
-   intel_runtime_pm_enable_interrupts(dev_priv);
-
/*
 * On VLV/CHV display interrupts are part of the display
 * power well, so hpd is reinitialized from there. For
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index c5f3938..fdd3345 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3549,8 +3549,6 @@ int i915_ggtt_enable_hw(struct drm_i915_private *dev_priv)
 
 void i915_ggtt_enable_guc(struct drm_i915_private *i915)
 {
-   GEM_BUG_ON(i915->ggtt.invalidate != gen6_ggtt_invalidate);
-
i915->ggtt.invalidate = guc_ggtt_invalidate;
 
i915_ggtt_invalidate(i915);
@@ -3558,10 +3556,8 @@ void i915_ggtt_enable_guc(struct drm_i915_private *i915)
 
 void i915_ggtt_disable_guc(struct drm_i915_private *i915)
 {
-   /* We should only be called after i915_ggtt_enable_guc() */
-   GEM_BUG_ON(i915->ggtt.invalidate != guc_ggtt_invalidate);
-
-   i915->ggtt.invalidate = gen6_ggtt_invalidate;
+   if (i915->ggtt.invalidate == guc_ggtt_invalidate)
+   i915->ggtt.invalidate = gen6_ggtt_invalidate;
 
i915_ggtt_invalidate(i915);
 }
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index c963603..25b7e88 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,8 +47,8 @@
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
-   param(int, guc_log_level, -1) \
+   param(int, enable_guc, -1) \
+   param(int, guc_log_level, 1) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
param(int, mmio_debug, 0) \
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index ddd4f6d..da0554c 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -339,7 +339,7 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
/* Used rate limited to avoid deluge of messages, logs might be
 * getting consumed by User at a slow rate.
 */
-   DRM_ERROR_RATELIMITED("no sub-buffer to capture logs\n");
+   //DRM_ERROR_RATELIMITED("no sub-buffer to capture logs\n");
guc->log.capture_miss_count++;
}
 }
-- 
1.9.1

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


[Intel-gfx] [PATCH v3 09/12] drm/i915/guc: Make GuC log related functions depend only on log level

2018-01-04 Thread Sagar Arun Kamble
With GuC log level set properly only for cases where GuC is loaded we can
remove the GuC submission checks from flush_guc_logs and guc_log_register,
unregister and uc_fini_hw functions. It is important to note that GuC log
runtime data has to be freed during driver unregister.
Freeing of that data can't be gated by guc_log_level check because if we
free GuC log runtime only when log level >=0 then it will not be destroyed
when logging is disabled after enabling before driver unload.

Also, with this patch GuC interrupts are enabled first after GuC load if
logging is enabled. GuC to Host interrupts will be needed for GuC CT
buffer recv mechanism and hence we will be adding support to control that
interrupt based on ref. taken by Log or CT recv feature in next patch. To
prepare for that all interrupt updates are now gated by GuC log level
checks.

v2: Rebase. Updated check in i915_guc_log_unregister to be based on
guc_log_level. (Michal Wajdeczko)

v3: Rebase. Made all GuC log related functions depend only log level.
Updated uC init w.r.t enabling of GuC interrupts. Commit message update.
Rebase w.r.t guc_log_level immutable changes. (Tvrtko)

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_guc.c |  3 ++-
 drivers/gpu/drm/i915/intel_guc_log.c | 17 +++--
 drivers/gpu/drm/i915/intel_uc.c  | 15 ---
 3 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index d351642..36d1bca 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -406,7 +406,8 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
 
-   intel_disable_guc_interrupts(guc);
+   if (guc->log.level >= 0)
+   intel_disable_guc_interrupts(guc);
 
data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
/* any value greater than GUC_POWER_D0 */
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index d979830..7bc0065 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -484,8 +484,7 @@ static void guc_log_capture_logs(struct intel_guc *guc)
 
 static void guc_flush_logs(struct intel_guc *guc)
 {
-   if (!USES_GUC_SUBMISSION(dev_priv) ||
-   guc->log.level < 0)
+   if (guc->log.level < 0)
return;
 
/* First disable the interrupts, will be renabled afterwards */
@@ -613,8 +612,7 @@ int i915_guc_log_control(struct drm_i915_private *dev_priv, 
u64 control_val)
 
 void i915_guc_log_register(struct drm_i915_private *dev_priv)
 {
-   if (!USES_GUC_SUBMISSION(dev_priv) ||
-   dev_priv->guc.log.level < 0)
+   if (dev_priv->guc.log.level < 0)
return;
 
mutex_lock(&dev_priv->drm.struct_mutex);
@@ -624,14 +622,13 @@ void i915_guc_log_register(struct drm_i915_private 
*dev_priv)
 
 void i915_guc_log_unregister(struct drm_i915_private *dev_priv)
 {
-   if (!USES_GUC_SUBMISSION(dev_priv))
-   return;
-
mutex_lock(&dev_priv->drm.struct_mutex);
/* GuC logging is currently the only user of Guc2Host interrupts */
-   intel_runtime_pm_get(dev_priv);
-   intel_disable_guc_interrupts(&dev_priv->guc);
-   intel_runtime_pm_put(dev_priv);
+   if (dev_priv->guc.log.level >= 0) {
+   intel_runtime_pm_get(dev_priv);
+   intel_disable_guc_interrupts(&dev_priv->guc);
+   intel_runtime_pm_put(dev_priv);
+   }
 
intel_guc_log_runtime_destroy(&dev_priv->guc);
mutex_unlock(&dev_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index e2e2020..fb5edcc 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -318,9 +318,12 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
if (ret)
goto err_log_capture;
 
+   if (guc->log.level >= 0)
+   intel_enable_guc_interrupts(guc);
+
ret = guc_enable_communication(guc);
if (ret)
-   goto err_log_capture;
+   goto err_interrupts;
 
if (USES_HUC(dev_priv)) {
ret = intel_huc_auth(huc);
@@ -329,12 +332,9 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
}
 
if (USES_GUC_SUBMISSION(dev_priv)) {
-   if (guc->log.level >= 0)
-   intel_enable_guc_interrupts(guc);
-
ret = intel_guc_submission_enable(guc);
if (ret)
-   goto err_interrupts;
+   goto err_communication;
}
 
dev_info

[Intel-gfx] [PATCH v3 10/12] drm/i915/guc: Add client support to enable/disable GuC interrupts

2018-01-04 Thread Sagar Arun Kamble
This patch adds support to enable/disable GuC interrupts for different
features without impacting other's need. Currently GuC log capture and
CT buffer receive mechanisms use the GuC interrupts. GuC interrupts are
currently enabled and disabled in different logging scenarios all gated
by log level.

v2: Rebase with all GuC interrupt handlers moved to intel_guc.c. Handling
multiple clients for GuC interrupts enable/disable.
(Michal Wajdeczko)

v3: Removed spin lock and using test_bit in i915_guc_info. Prepared low
level helpers to get/put GuC interrupts that can be reused during
suspend/resume. (Tvrtko)

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  6 +
 drivers/gpu/drm/i915/intel_guc.c | 47 +++-
 drivers/gpu/drm/i915/intel_guc.h | 11 ++---
 drivers/gpu/drm/i915/intel_guc_log.c |  6 ++---
 drivers/gpu/drm/i915/intel_uc.c  |  4 +--
 5 files changed, 54 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 16f9a95..eef4c8b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2340,6 +2340,12 @@ static int i915_guc_info(struct seq_file *m, void *data)
GEM_BUG_ON(!guc->execbuf_client);
GEM_BUG_ON(!guc->preempt_client);
 
+   seq_puts(m, "GuC Interrupt Clients: ");
+   if (test_bit(GUC_INTR_CLIENT_LOG, &guc->interrupt_clients))
+   seq_puts(m, "GuC Logging\n");
+   else
+   seq_puts(m, "None\n");
+
seq_printf(m, "Doorbell map:\n");
seq_printf(m, "\t%*pb\n", GUC_NUM_DOORBELLS, guc->doorbell_bitmap);
seq_printf(m, "Doorbell next cacheline: 0x%x\n\n", guc->db_cacheline);
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 36d1bca..d356c40 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -407,7 +407,7 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv)
return 0;
 
if (guc->log.level >= 0)
-   intel_disable_guc_interrupts(guc);
+   intel_put_guc_interrupts(guc, GUC_INTR_CLIENT_LOG);
 
data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
/* any value greater than GUC_POWER_D0 */
@@ -453,7 +453,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
return 0;
 
if (guc->log.level >= 0)
-   intel_enable_guc_interrupts(guc);
+   intel_get_guc_interrupts(guc, GUC_INTR_CLIENT_LOG);
 
data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
data[1] = GUC_POWER_D0;
@@ -524,28 +524,51 @@ void intel_reset_guc_interrupts(struct intel_guc *guc)
spin_unlock_irq(&dev_priv->irq_lock);
 }
 
-void intel_enable_guc_interrupts(struct intel_guc *guc)
+static void __intel_get_guc_interrupts(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
+   lockdep_assert_held(&dev_priv->irq_lock);
+
+   WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) &
+  dev_priv->pm_guc_events);
+   gen6_enable_pm_irq(dev_priv, dev_priv->pm_guc_events);
+}
+
+void intel_get_guc_interrupts(struct intel_guc *guc, enum guc_intr_client id)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
 
spin_lock_irq(&dev_priv->irq_lock);
-   if (!dev_priv->guc.interrupts_enabled) {
-   WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) &
-  dev_priv->pm_guc_events);
-   dev_priv->guc.interrupts_enabled = true;
-   gen6_enable_pm_irq(dev_priv, dev_priv->pm_guc_events);
-   }
+
+   if (!guc->interrupt_clients)
+   __intel_get_guc_interrupts(guc);
+   __set_bit(id, &guc->interrupt_clients);
+
spin_unlock_irq(&dev_priv->irq_lock);
 }
 
-void intel_disable_guc_interrupts(struct intel_guc *guc)
+static void __intel_put_guc_interrupts(struct intel_guc *guc)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
 
-   spin_lock_irq(&dev_priv->irq_lock);
-   dev_priv->guc.interrupts_enabled = false;
+   lockdep_assert_held(&dev_priv->irq_lock);
 
gen6_disable_pm_irq(dev_priv, dev_priv->pm_guc_events);
+}
+
+void intel_put_guc_interrupts(struct intel_guc *guc, enum guc_intr_client id)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
+   spin_lock_irq(&dev_priv->irq_lock);
+
+   __clear_bit(id, &guc->interrupt_clients);
+   if (guc->interrupt_clients) {
+   spin_unlock_irq(&dev_priv->irq_lock);
+   return;
+   }
+   __intel_put_guc

Re: [Intel-gfx] [PATCH v3 03/12] drm/i915/guc: Pass intel_guc struct parameter to GuC interrupts functions

2018-01-04 Thread Sagar Arun Kamble



On 1/4/2018 10:01 PM, Michal Wajdeczko wrote:
On Thu, 04 Jan 2018 17:23:05 +0100, Chris Wilson 
 wrote:



Quoting Sagar Arun Kamble (2018-01-04 16:21:45)
GuC interrupts handling functions are GuC specific functions hence 
update

the parameter from dev_priv to intel_guc struct.

v2-v3: Rebase.

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_irq.c  |  2 +-
 drivers/gpu/drm/i915/intel_guc.c | 22 +++---
 drivers/gpu/drm/i915/intel_guc.h |  8 
 drivers/gpu/drm/i915/intel_guc_log.c |  8 +++-
 drivers/gpu/drm/i915/intel_uc.c  |  8 
 5 files changed, 27 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c 
b/drivers/gpu/drm/i915/i915_irq.c

index 3f4eff9..a1ae057 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1447,7 +1447,7 @@ static void gen8_gt_irq_handler(struct 
drm_i915_private *dev_priv,

    gen6_rps_irq_handler(dev_priv, gt_iir[2]);

    if (gt_iir[2] & dev_priv->pm_guc_events)
-   intel_guc_irq_handler(dev_priv, gt_iir[2]);
+   intel_guc_irq_handler(&dev_priv->guc, gt_iir[2]);
 }

 static bool bxt_port_hotplug_long_detect(enum port port, u32 val)
diff --git a/drivers/gpu/drm/i915/intel_guc.c 
b/drivers/gpu/drm/i915/intel_guc.c

index e95ff2d..14bf508d 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -400,7 +400,7 @@ int intel_guc_suspend(struct drm_i915_private 
*dev_priv)

    if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
    return 0;

-   intel_disable_guc_interrupts(dev_priv);
+   intel_disable_guc_interrupts(guc);

    data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
    /* any value greater than GUC_POWER_D0 */
@@ -446,7 +446,7 @@ int intel_guc_resume(struct drm_i915_private 
*dev_priv)

    return 0;

    if (i915_modparams.guc_log_level >= 0)
-   intel_enable_guc_interrupts(dev_priv);
+   intel_enable_guc_interrupts(guc);

    data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
    data[1] = GUC_POWER_D0;
@@ -508,15 +508,19 @@ u32 intel_guc_wopcm_size(struct 
drm_i915_private *dev_priv)

    return wopcm_size;
 }

-void intel_reset_guc_interrupts(struct drm_i915_private *dev_priv)
+void intel_reset_guc_interrupts(struct intel_guc *guc)
 {
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
    spin_lock_irq(&dev_priv->irq_lock);
    gen6_reset_pm_iir(dev_priv, dev_priv->pm_guc_events);
    spin_unlock_irq(&dev_priv->irq_lock);
 }

-void intel_enable_guc_interrupts(struct drm_i915_private *dev_priv)
+void intel_enable_guc_interrupts(struct intel_guc *guc)
 {
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
    spin_lock_irq(&dev_priv->irq_lock);
    if (!dev_priv->guc.interrupts_enabled) {
    WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) &
@@ -527,8 +531,10 @@ void intel_enable_guc_interrupts(struct 
drm_i915_private *dev_priv)

    spin_unlock_irq(&dev_priv->irq_lock);
 }

-void intel_disable_guc_interrupts(struct drm_i915_private *dev_priv)
+void intel_disable_guc_interrupts(struct intel_guc *guc)
 {
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
    spin_lock_irq(&dev_priv->irq_lock);
    dev_priv->guc.interrupts_enabled = false;

@@ -537,11 +543,13 @@ void intel_disable_guc_interrupts(struct 
drm_i915_private *dev_priv)

    spin_unlock_irq(&dev_priv->irq_lock);
    synchronize_irq(dev_priv->drm.irq);

-   intel_reset_guc_interrupts(dev_priv);
+   intel_reset_guc_interrupts(guc);
 }

-void intel_guc_irq_handler(struct drm_i915_private *dev_priv, u32 
gt_iir)

+void intel_guc_irq_handler(struct intel_guc *guc, u32 gt_iir)
 {
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
    if (gt_iir & GEN9_GUC_TO_HOST_INT_EVENT) {
    /* Sample the log buffer flush related bits & clear 
them out now
 * itself from the message identity register to 
minimize the
diff --git a/drivers/gpu/drm/i915/intel_guc.h 
b/drivers/gpu/drm/i915/intel_guc.h

index c37d34d..49f33b9 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -131,9 +131,9 @@ static inline u32 guc_ggtt_offset(struct 
i915_vma *vma)

 int intel_guc_resume(struct drm_i915_private *dev_priv);
 struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 
size);

 u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
-void intel_reset_guc_interrupts(struct drm_i915_private *dev_priv);
-void intel_enable_guc_interrupts(struct drm_i915_private *dev_priv);
-void intel_disable_guc_interrupts(struct drm_i915_private *dev_priv);
-void intel_guc_irq_hand

Re: [Intel-gfx] [PATCH v3 12/12] HAX: drm/i915/guc: enable GuC submission/logging for CI

2018-01-04 Thread Sagar Arun Kamble



On 1/4/2018 9:59 PM, Chris Wilson wrote:

Quoting Sagar Arun Kamble (2018-01-04 16:21:54)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6c8da9d..c8460c5 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2659,6 +2659,8 @@ static int intel_runtime_resume(struct device *kdev)
 if (intel_uncore_unclaimed_mmio(dev_priv))
 DRM_DEBUG_DRIVER("Unclaimed access during suspend, bios?\n");
  
+   intel_runtime_pm_enable_interrupts(dev_priv);

+
 intel_guc_resume(dev_priv);
  
 if (IS_GEN9_LP(dev_priv)) {

@@ -2682,8 +2684,6 @@ static int intel_runtime_resume(struct device *kdev)
 i915_gem_init_swizzling(dev_priv);
 i915_gem_restore_fences(dev_priv);
  
-   intel_runtime_pm_enable_interrupts(dev_priv);

Have I missed the pending patch?
There is suspend/resume related restructuring series for GuC/GEM that is 
in queue post this series.

Was reviewed partly some time back.

Thanks
Sagar

-Chris


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


Re: [Intel-gfx] [PATCH v3 04/12] drm/i915/guc: Add description and comments about guc_log_level parameter

2018-01-04 Thread Sagar Arun Kamble



On 1/4/2018 10:22 PM, Michal Wajdeczko wrote:
On Thu, 04 Jan 2018 17:21:46 +0100, Sagar Arun Kamble 
 wrote:



guc_log_level parameter takes effect when GuC is loaded which is
controlled through enable_guc parameter. Add this relation info.

^^^
Extra "."


in parameter description and documentation.
Earlier, this patch was added to sanitize guc_log_level like old
GuC parameters enable_guc_loading/submission. With new parameter
enable_guc, sanitization of guc_log_level is no more needed.


Hmm, I think we still need to sanitize log_level if it was wrongly
enabled without enabling GuC first (in intel_uc_sanitize_options).
I think it would not be harmful as all decisions based on it will be 
gated by USES_GUC.




v2: Added documentation to intel_guc_log.c and param description
about GuC loading dependency. (Michal Wajdeczko)

v3: Removed sanitization of module parameter guc_log_level.
Previous review comments not applicable now.

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin  #v2
---
 drivers/gpu/drm/i915/i915_params.c   | 3 ++-
 drivers/gpu/drm/i915/intel_guc_log.c | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c

index b5f3eb4..a93a6ca 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -155,7 +155,8 @@ struct i915_params i915_modparams __read_mostly = {
 "(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)");
i915_param_named(guc_log_level, int, 0400,
-    "GuC firmware logging level (-1:disabled (default), 0-3:enabled)");
+    "GuC firmware logging level. This takes effect only if GuC is to 
be "
+    "loaded (depends on enable_guc) (-1:disabled (default), 
0-3:enabled)");


Btw, I was planing to change above values to follow schema used in 
other modparams:


-1: auto (then it can be controlled by USES_GUC and DRM_I915_DEBUG_GUC)
 0: disabled
 1: enabled (legacy level 0)
 2: enabled (legacy level 1)
 3: enabled (legacy level 2)
 4: enabled (legacy level 3)

So now I'm not sure that I want your patch ;)


Makes sense. Will drop this patch.

Thanks
Sagar

i915_param_named_unsafe(guc_firmware_path, charp, 0400,
 "GuC firmware path to use instead of the default one");
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c

index 59a9021..d0131bc 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -34,6 +34,7 @@
  * DOC: GuC firmware log
  *
  * Firmware log is enabled by setting i915.guc_log_level to 
non-negative level.

+ * This takes effect only if GuC is to be loaded based on enable_guc.


... based on i915.enable_guc modparam.

  * Log data is printed out via reading debugfs i915_guc_log_dump. 
Reading from
  * i915_guc_load_status will print out firmware loading status and 
scratch

  * registers value.


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


Re: [Intel-gfx] [PATCH v3 09/12] drm/i915/guc: Make GuC log related functions depend only on log level

2018-01-04 Thread Sagar Arun Kamble



On 1/4/2018 10:45 PM, Michal Wajdeczko wrote:
On Thu, 04 Jan 2018 17:21:51 +0100, Sagar Arun Kamble 
 wrote:


With GuC log level set properly only for cases where GuC is loaded we 
can
remove the GuC submission checks from flush_guc_logs and 
guc_log_register,
unregister and uc_fini_hw functions. It is important to note that GuC 
log

runtime data has to be freed during driver unregister.
Freeing of that data can't be gated by guc_log_level check because if we
free GuC log runtime only when log level >=0 then it will not be 
destroyed

when logging is disabled after enabling before driver unload.

Also, with this patch GuC interrupts are enabled first after GuC load if
logging is enabled. GuC to Host interrupts will be needed for GuC CT
buffer recv mechanism and hence we will be adding support to control 
that
interrupt based on ref. taken by Log or CT recv feature in next 
patch. To

prepare for that all interrupt updates are now gated by GuC log level
checks.

v2: Rebase. Updated check in i915_guc_log_unregister to be based on
guc_log_level. (Michal Wajdeczko)

v3: Rebase. Made all GuC log related functions depend only log level.
Updated uC init w.r.t enabling of GuC interrupts. Commit message update.
Rebase w.r.t guc_log_level immutable changes. (Tvrtko)

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_guc.c |  3 ++-
 drivers/gpu/drm/i915/intel_guc_log.c | 17 +++--
 drivers/gpu/drm/i915/intel_uc.c  | 15 ---
 3 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c 
b/drivers/gpu/drm/i915/intel_guc.c

index d351642..36d1bca 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -406,7 +406,8 @@ int intel_guc_suspend(struct drm_i915_private 
*dev_priv)

 if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
 return 0;
-    intel_disable_guc_interrupts(guc);
+    if (guc->log.level >= 0)
+    intel_disable_guc_interrupts(guc);
data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
 /* any value greater than GUC_POWER_D0 */
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c

index d979830..7bc0065 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -484,8 +484,7 @@ static void guc_log_capture_logs(struct intel_guc 
*guc)

static void guc_flush_logs(struct intel_guc *guc)
 {
-    if (!USES_GUC_SUBMISSION(dev_priv) ||
-    guc->log.level < 0)
+    if (guc->log.level < 0)
 return;
/* First disable the interrupts, will be renabled afterwards */
@@ -613,8 +612,7 @@ int i915_guc_log_control(struct drm_i915_private 
*dev_priv, u64 control_val)

void i915_guc_log_register(struct drm_i915_private *dev_priv)
 {
-    if (!USES_GUC_SUBMISSION(dev_priv) ||
-    dev_priv->guc.log.level < 0)
+    if (dev_priv->guc.log.level < 0)
 return;
mutex_lock(&dev_priv->drm.struct_mutex);
@@ -624,14 +622,13 @@ void i915_guc_log_register(struct 
drm_i915_private *dev_priv)

void i915_guc_log_unregister(struct drm_i915_private *dev_priv)
 {
-    if (!USES_GUC_SUBMISSION(dev_priv))
-    return;
-
 mutex_lock(&dev_priv->drm.struct_mutex);
 /* GuC logging is currently the only user of Guc2Host interrupts */
-    intel_runtime_pm_get(dev_priv);
-    intel_disable_guc_interrupts(&dev_priv->guc);
-    intel_runtime_pm_put(dev_priv);
+    if (dev_priv->guc.log.level >= 0) {


Can we move "if (guc->log.level >= 0)" condition check to
intel_guc_[disable|enable]_interrupts functions? Then we
should be able to avoid repeating this check over and over
and it will be also easier for use once we add new CTB check.

I will create a new wrapper function for this logging specific check. 
Will not move the check to
guc_enable|disable_intr as it will be low level handler to 
enable/disable interrupts to be used

by logging, CTB.

+    intel_runtime_pm_get(dev_priv);
+    intel_disable_guc_interrupts(&dev_priv->guc);
+    intel_runtime_pm_put(dev_priv);
+    }
intel_guc_log_runtime_destroy(&dev_priv->guc);
 mutex_unlock(&dev_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/intel_uc.c 
b/drivers/gpu/drm/i915/intel_uc.c

index e2e2020..fb5edcc 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -318,9 +318,12 @@ int intel_uc_init_hw(struct drm_i915_private 
*dev_priv)

 if (ret)
 goto err_log_capture;
+    if (guc->log.level >= 0)
+    intel_enable_guc_interrupts(guc);
+
 ret = guc_enable_communication(guc);
 if (ret)
-    goto err_log_capture;
+    goto err_interrupts;
if (USES_HUC(dev_priv)) {
 ret = intel_huc_auth(huc);
@@ -329,12 +332,9 @@ int intel_uc_init_hw(struct

Re: [Intel-gfx] [PATCH v3 03/12] drm/i915/guc: Pass intel_guc struct parameter to GuC interrupts functions

2018-01-04 Thread Sagar Arun Kamble



On 1/4/2018 10:52 PM, Michal Wajdeczko wrote:
On Thu, 04 Jan 2018 17:21:45 +0100, Sagar Arun Kamble 
 wrote:


GuC interrupts handling functions are GuC specific functions hence 
update

the parameter from dev_priv to intel_guc struct.

v2-v3: Rebase.

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_irq.c  |  2 +-
 drivers/gpu/drm/i915/intel_guc.c | 22 +++---
 drivers/gpu/drm/i915/intel_guc.h |  8 
 drivers/gpu/drm/i915/intel_guc_log.c |  8 +++-
 drivers/gpu/drm/i915/intel_uc.c  |  8 
 5 files changed, 27 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c 
b/drivers/gpu/drm/i915/i915_irq.c

index 3f4eff9..a1ae057 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1447,7 +1447,7 @@ static void gen8_gt_irq_handler(struct 
drm_i915_private *dev_priv,

 gen6_rps_irq_handler(dev_priv, gt_iir[2]);
if (gt_iir[2] & dev_priv->pm_guc_events)
-    intel_guc_irq_handler(dev_priv, gt_iir[2]);
+    intel_guc_irq_handler(&dev_priv->guc, gt_iir[2]);
 }
static bool bxt_port_hotplug_long_detect(enum port port, u32 val)
diff --git a/drivers/gpu/drm/i915/intel_guc.c 
b/drivers/gpu/drm/i915/intel_guc.c

index e95ff2d..14bf508d 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -400,7 +400,7 @@ int intel_guc_suspend(struct drm_i915_private 
*dev_priv)

 if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
 return 0;
-    intel_disable_guc_interrupts(dev_priv);
+    intel_disable_guc_interrupts(guc);


Hmm, if we disable irq here, then we might have problems with
sending this message to GuC if we use CTB as comm mechanism...


Yes. This gets fixed in the later patches in the series.

data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
 /* any value greater than GUC_POWER_D0 */
@@ -446,7 +446,7 @@ int intel_guc_resume(struct drm_i915_private 
*dev_priv)

 return 0;
if (i915_modparams.guc_log_level >= 0)
-    intel_enable_guc_interrupts(dev_priv);
+    intel_enable_guc_interrupts(guc);
data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
 data[1] = GUC_POWER_D0;
@@ -508,15 +508,19 @@ u32 intel_guc_wopcm_size(struct 
drm_i915_private *dev_priv)

 return wopcm_size;
 }
-void intel_reset_guc_interrupts(struct drm_i915_private *dev_priv)
+void intel_reset_guc_interrupts(struct intel_guc *guc)
 {
+    struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
 spin_lock_irq(&dev_priv->irq_lock);
 gen6_reset_pm_iir(dev_priv, dev_priv->pm_guc_events);
 spin_unlock_irq(&dev_priv->irq_lock);
 }
-void intel_enable_guc_interrupts(struct drm_i915_private *dev_priv)
+void intel_enable_guc_interrupts(struct intel_guc *guc)
 {
+    struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
 spin_lock_irq(&dev_priv->irq_lock);
 if (!dev_priv->guc.interrupts_enabled) {


Just spotted:
as we have "guc" try to use "guc->" instead of "dev_priv->guc."


Ok :)

WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) &
@@ -527,8 +531,10 @@ void intel_enable_guc_interrupts(struct 
drm_i915_private *dev_priv)

 spin_unlock_irq(&dev_priv->irq_lock);
 }
-void intel_disable_guc_interrupts(struct drm_i915_private *dev_priv)
+void intel_disable_guc_interrupts(struct intel_guc *guc)
 {
+    struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
 spin_lock_irq(&dev_priv->irq_lock);
 dev_priv->guc.interrupts_enabled = false;


same here (and possibly in other places too)


Sure.
@@ -537,11 +543,13 @@ void intel_disable_guc_interrupts(struct 
drm_i915_private *dev_priv)

 spin_unlock_irq(&dev_priv->irq_lock);
 synchronize_irq(dev_priv->drm.irq);
-    intel_reset_guc_interrupts(dev_priv);
+    intel_reset_guc_interrupts(guc);
 }
-void intel_guc_irq_handler(struct drm_i915_private *dev_priv, u32 
gt_iir)

+void intel_guc_irq_handler(struct intel_guc *guc, u32 gt_iir)
 {
+    struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
 if (gt_iir & GEN9_GUC_TO_HOST_INT_EVENT) {
 /* Sample the log buffer flush related bits & clear them out 
now

  * itself from the message identity register to minimize the
diff --git a/drivers/gpu/drm/i915/intel_guc.h 
b/drivers/gpu/drm/i915/intel_guc.h

index c37d34d..49f33b9 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -131,9 +131,9 @@ static inline u32 guc_ggtt_offset(struct i915_vma 
*vma)

 int intel_guc_resume(struct drm_i915_private *dev_priv);
 struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 
size);

 u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
-void intel_reset_guc_interrupts(struct drm_i915_private *dev_priv);
-void intel_enab

Re: [Intel-gfx] [PATCH v3 10/12] drm/i915/guc: Add client support to enable/disable GuC interrupts

2018-01-04 Thread Sagar Arun Kamble



On 1/4/2018 11:09 PM, Michal Wajdeczko wrote:
On Thu, 04 Jan 2018 17:21:52 +0100, Sagar Arun Kamble 
 wrote:



This patch adds support to enable/disable GuC interrupts for different
features without impacting other's need. Currently GuC log capture and
CT buffer receive mechanisms use the GuC interrupts. GuC interrupts are
currently enabled and disabled in different logging scenarios all gated
by log level.

v2: Rebase with all GuC interrupt handlers moved to intel_guc.c. 
Handling

multiple clients for GuC interrupts enable/disable.
(Michal Wajdeczko)

v3: Removed spin lock and using test_bit in i915_guc_info. Prepared low
level helpers to get/put GuC interrupts that can be reused during
suspend/resume. (Tvrtko)

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  6 +
 drivers/gpu/drm/i915/intel_guc.c | 47 
+++-

 drivers/gpu/drm/i915/intel_guc.h | 11 ++---
 drivers/gpu/drm/i915/intel_guc_log.c |  6 ++---
 drivers/gpu/drm/i915/intel_uc.c  |  4 +--
 5 files changed, 54 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c

index 16f9a95..eef4c8b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2340,6 +2340,12 @@ static int i915_guc_info(struct seq_file *m, 
void *data)

 GEM_BUG_ON(!guc->execbuf_client);
 GEM_BUG_ON(!guc->preempt_client);
+    seq_puts(m, "GuC Interrupt Clients: ");
+    if (test_bit(GUC_INTR_CLIENT_LOG, &guc->interrupt_clients))
+    seq_puts(m, "GuC Logging\n");
+    else
+    seq_puts(m, "None\n");
+


Maybe this can be done in intel_guc_log.c as part of:

void intel_guc_log_dump(const struct intel_guc_log *log, struct 
drm_printer *p);


Idea is to know as part of GuC global information, which all features 
have enabled GuC to Host Interrupts.
I can add it in the i915_guc_log_dump as to whether interrupt is enabled 
but then I think it will be good to have

it here to know interrupt status together at once we have CTB as well.



 seq_printf(m, "Doorbell map:\n");
 seq_printf(m, "\t%*pb\n", GUC_NUM_DOORBELLS, guc->doorbell_bitmap);
 seq_printf(m, "Doorbell next cacheline: 0x%x\n\n", 
guc->db_cacheline);
diff --git a/drivers/gpu/drm/i915/intel_guc.c 
b/drivers/gpu/drm/i915/intel_guc.c

index 36d1bca..d356c40 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -407,7 +407,7 @@ int intel_guc_suspend(struct drm_i915_private 
*dev_priv)

 return 0;
if (guc->log.level >= 0)
-    intel_disable_guc_interrupts(guc);
+    intel_put_guc_interrupts(guc, GUC_INTR_CLIENT_LOG);
data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
 /* any value greater than GUC_POWER_D0 */
@@ -453,7 +453,7 @@ int intel_guc_resume(struct drm_i915_private 
*dev_priv)

 return 0;
if (guc->log.level >= 0)
-    intel_enable_guc_interrupts(guc);
+    intel_get_guc_interrupts(guc, GUC_INTR_CLIENT_LOG);
data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
 data[1] = GUC_POWER_D0;
@@ -524,28 +524,51 @@ void intel_reset_guc_interrupts(struct 
intel_guc *guc)

 spin_unlock_irq(&dev_priv->irq_lock);
 }
-void intel_enable_guc_interrupts(struct intel_guc *guc)
+static void __intel_get_guc_interrupts(struct intel_guc *guc)
+{
+    struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
+    lockdep_assert_held(&dev_priv->irq_lock);
+
+    WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) &
+   dev_priv->pm_guc_events);
+    gen6_enable_pm_irq(dev_priv, dev_priv->pm_guc_events);
+}
+
+void intel_get_guc_interrupts(struct intel_guc *guc, enum 
guc_intr_client id)


What about intel_guc_interrupts_get(guc, id) ?


 {
 struct drm_i915_private *dev_priv = guc_to_i915(guc);
spin_lock_irq(&dev_priv->irq_lock);
-    if (!dev_priv->guc.interrupts_enabled) {
-    WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) &
-   dev_priv->pm_guc_events);
-    dev_priv->guc.interrupts_enabled = true;
-    gen6_enable_pm_irq(dev_priv, dev_priv->pm_guc_events);
-    }
+
+    if (!guc->interrupt_clients)
+    __intel_get_guc_interrupts(guc);
+    __set_bit(id, &guc->interrupt_clients);


Do we care about scenarios when we call "get" more than once?
Maybe we need GEM_WARN_ON at the minimum ?

Then I'm wondering if "get/put" are correct if we don't do any
refcounting... maybe "enable/disable" are more appropriate then?

enabling/disabling more than once should not be a problem. will update 
the names

as suggested as we don't refcount.

+
 spin_unlock_irq(&dev_priv->irq_lock);
 }
-void intel_disa

Re: [Intel-gfx] [PATCH v3 11/12] drm/i915/guc: Restore GuC interrupts across suspend/reset if enabled

2018-01-04 Thread Sagar Arun Kamble



On 1/4/2018 11:19 PM, Michal Wajdeczko wrote:
On Thu, 04 Jan 2018 17:21:53 +0100, Sagar Arun Kamble 
 wrote:



In order to override the disable/enable control of GuC interrupts during
suspend/reset cycle we are creating two new functions suspend/restore
guc_interrupts which check if interrupts were enabled and disable them
on suspend and enable them on resume. They are used to restore 
interrupts

across reset as well.

Further restructuring of runtime_pm_enable/disable_interrupts and
suspend/restore_guc_interrupts will be done in upcoming patches.

v2: Rebase.

v3: Updated suspend/restore with the new low level get/put functions.
(Tvrtko)

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_display.c |  2 ++
 drivers/gpu/drm/i915/intel_guc.c | 32 


 drivers/gpu/drm/i915/intel_guc.h |  2 ++
 3 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c

index 0cd3559..2e0db53 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3676,8 +3676,10 @@ void intel_finish_reset(struct 
drm_i915_private *dev_priv)

  * The display has been reset as well,
  * so need a full re-initialization.
  */
+    intel_suspend_guc_interrupts(&dev_priv->guc);
 intel_runtime_pm_disable_interrupts(dev_priv);
 intel_runtime_pm_enable_interrupts(dev_priv);
+    intel_restore_guc_interrupts(&dev_priv->guc);
    intel_pps_unlock_regs_wa(dev_priv);
 intel_modeset_init_hw(dev);
diff --git a/drivers/gpu/drm/i915/intel_guc.c 
b/drivers/gpu/drm/i915/intel_guc.c

index d356c40..28a418a 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -406,8 +406,7 @@ int intel_guc_suspend(struct drm_i915_private 
*dev_priv)

 if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
 return 0;
-    if (guc->log.level >= 0)
-    intel_put_guc_interrupts(guc, GUC_INTR_CLIENT_LOG);
+    intel_suspend_guc_interrupts(guc);


Hmm, maybe we should introduce

intel_uc_suspend(struct drm_i915_private *dev_priv)

which will call separately

intel_guc_suspend(guc); /* send suspend action */
intel_guc_suspend_interrupts(guc);

Yes. Ordering was not correct. I have this change as part of 
suspend/resume restructuring from GuC/GEM which will follow

after this. Will keep as it is for now in this patch.

data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
 /* any value greater than GUC_POWER_D0 */
@@ -452,8 +451,7 @@ int intel_guc_resume(struct drm_i915_private 
*dev_priv)

 if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
 return 0;
-    if (guc->log.level >= 0)
-    intel_get_guc_interrupts(guc, GUC_INTR_CLIENT_LOG);
+    intel_restore_guc_interrupts(guc);
data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
 data[1] = GUC_POWER_D0;
@@ -548,6 +546,16 @@ void intel_get_guc_interrupts(struct intel_guc 
*guc, enum guc_intr_client id)

 spin_unlock_irq(&dev_priv->irq_lock);
 }
+void intel_restore_guc_interrupts(struct intel_guc *guc)
+{
+    struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
+    spin_lock_irq(&dev_priv->irq_lock);
+    if (guc->interrupt_clients)
+    __intel_get_guc_interrupts(guc);
+    spin_unlock_irq(&dev_priv->irq_lock);
+}
+
 static void __intel_put_guc_interrupts(struct intel_guc *guc)
 {
 struct drm_i915_private *dev_priv = guc_to_i915(guc);
@@ -576,6 +584,22 @@ void intel_put_guc_interrupts(struct intel_guc 
*guc, enum guc_intr_client id)

 intel_reset_guc_interrupts(guc);
 }
+void intel_suspend_guc_interrupts(struct intel_guc *guc)
+{
+    struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
+    spin_lock_irq(&dev_priv->irq_lock);
+    if (!guc->interrupt_clients) {
+    spin_unlock_irq(&dev_priv->irq_lock);
+    return;
+    }
+    __intel_put_guc_interrupts(guc);
+    spin_unlock_irq(&dev_priv->irq_lock);
+    synchronize_irq(dev_priv->drm.irq);
+
+    intel_reset_guc_interrupts(guc);
+}
+
 void intel_guc_irq_handler(struct intel_guc *guc, u32 gt_iir)
 {
 struct drm_i915_private *dev_priv = guc_to_i915(guc);
diff --git a/drivers/gpu/drm/i915/intel_guc.h 
b/drivers/gpu/drm/i915/intel_guc.h

index af74392..2c14781 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -140,5 +140,7 @@ static inline u32 guc_ggtt_offset(struct i915_vma 
*vma)
 void intel_get_guc_interrupts(struct intel_guc *guc, enum 
guc_intr_client id);
 void intel_put_guc_interrupts(struct intel_guc *guc, enum 
guc_intr_client id);

 void intel_guc_irq_handler(struct intel_guc *guc, u32 pm_iir);
+void intel_suspend_guc_interrupts(struct intel_guc *guc);
+void intel_restore_guc_interrupts

[Intel-gfx] [PATCH v4 9/9] HAX: drm/i915/guc: enable GuC submission/logging for CI

2018-01-05 Thread Sagar Arun Kamble
Also 1) revert ("drm/i915/guc: Assert that we switch between
known ggtt->invalidate functions")
2) fix RPM resume interrupt enabling w.r.t GuC resume
3) disable guc log streaming DRM logs
---
 drivers/gpu/drm/i915/i915_drv.c  | 4 ++--
 drivers/gpu/drm/i915/i915_gem_gtt.c  | 8 ++--
 drivers/gpu/drm/i915/i915_params.h   | 4 ++--
 drivers/gpu/drm/i915/intel_guc_log.c | 4 ++--
 4 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6c8da9d..c8460c5 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2659,6 +2659,8 @@ static int intel_runtime_resume(struct device *kdev)
if (intel_uncore_unclaimed_mmio(dev_priv))
DRM_DEBUG_DRIVER("Unclaimed access during suspend, bios?\n");
 
+   intel_runtime_pm_enable_interrupts(dev_priv);
+
intel_guc_resume(dev_priv);
 
if (IS_GEN9_LP(dev_priv)) {
@@ -2682,8 +2684,6 @@ static int intel_runtime_resume(struct device *kdev)
i915_gem_init_swizzling(dev_priv);
i915_gem_restore_fences(dev_priv);
 
-   intel_runtime_pm_enable_interrupts(dev_priv);
-
/*
 * On VLV/CHV display interrupts are part of the display
 * power well, so hpd is reinitialized from there. For
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index f2a0f55..979709b 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3550,8 +3550,6 @@ int i915_ggtt_enable_hw(struct drm_i915_private *dev_priv)
 
 void i915_ggtt_enable_guc(struct drm_i915_private *i915)
 {
-   GEM_BUG_ON(i915->ggtt.invalidate != gen6_ggtt_invalidate);
-
i915->ggtt.invalidate = guc_ggtt_invalidate;
 
i915_ggtt_invalidate(i915);
@@ -3559,10 +3557,8 @@ void i915_ggtt_enable_guc(struct drm_i915_private *i915)
 
 void i915_ggtt_disable_guc(struct drm_i915_private *i915)
 {
-   /* We should only be called after i915_ggtt_enable_guc() */
-   GEM_BUG_ON(i915->ggtt.invalidate != guc_ggtt_invalidate);
-
-   i915->ggtt.invalidate = gen6_ggtt_invalidate;
+   if (i915->ggtt.invalidate == guc_ggtt_invalidate)
+   i915->ggtt.invalidate = gen6_ggtt_invalidate;
 
i915_ggtt_invalidate(i915);
 }
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index c963603..25b7e88 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,8 +47,8 @@
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
-   param(int, guc_log_level, -1) \
+   param(int, enable_guc, -1) \
+   param(int, guc_log_level, 1) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
param(int, mmio_debug, 0) \
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index fd2a40e..84c0fc7 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -225,7 +225,7 @@ static bool guc_check_log_buf_overflow(struct intel_guc 
*guc,
/* buffer_full_cnt is a 4 bit counter */
guc->log.total_overflow_count[type] += 16;
}
-   DRM_ERROR_RATELIMITED("GuC log buffer overflow\n");
+   //DRM_ERROR_RATELIMITED("GuC log buffer overflow\n");
}
 
return overflow;
@@ -338,7 +338,7 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
/* Used rate limited to avoid deluge of messages, logs might be
 * getting consumed by User at a slow rate.
 */
-   DRM_ERROR_RATELIMITED("no sub-buffer to capture logs\n");
+   //DRM_ERROR_RATELIMITED("no sub-buffer to capture logs\n");
guc->log.capture_miss_count++;
}
 }
-- 
1.9.1

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


[Intel-gfx] [PATCH v4 1/9] drm/i915/guc: Move GuC interrupts related functions from i915_irq.c to intel_guc.c

2018-01-05 Thread Sagar Arun Kamble
GuC interrupts handling is core GuC functionality. Better to keep it
with other core functions in intel_guc.c. Since they are used from
uC functions, GuC log and i915 irq handling we are keeping them grouped
in intel_guc.c instead of intel_uc.c. Also update the function parameter
from dev_priv to intel_guc struct while we are at it.

In order to separate GuC IRQ handling functions from i915_irq.c we need
to export the low level pm irq handlers. Export pm_iir, reset_pm_iir and
enable/disable_pm_irq functions.

v2-v3: Rebase.

v4: Squashed patches to change the parameter and move to guc.c. Using
readily available guc struct instead of referencing via dev_priv. (Michal)
s/intel_*_guc_interrupts/intel_guc_*_interrupts. (Chris)

Suggested-by: Michal Wajdeczko 
Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin  #v3
---
 drivers/gpu/drm/i915/i915_irq.c  | 78 +++---
 drivers/gpu/drm/i915/intel_drv.h |  7 ++--
 drivers/gpu/drm/i915/intel_guc.c | 81 ++--
 drivers/gpu/drm/i915/intel_guc.h |  4 ++
 drivers/gpu/drm/i915/intel_guc_log.c |  8 ++--
 drivers/gpu/drm/i915/intel_uc.c  |  8 ++--
 6 files changed, 98 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 3517c65..a1ae057 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -203,7 +203,6 @@ static void gen2_assert_iir_is_zero(struct drm_i915_private 
*dev_priv,
 } while (0)
 
 static void gen6_rps_irq_handler(struct drm_i915_private *dev_priv, u32 
pm_iir);
-static void gen9_guc_irq_handler(struct drm_i915_private *dev_priv, u32 
pm_iir);
 
 /* For display hotplug interrupt */
 static inline void
@@ -306,7 +305,7 @@ void gen5_disable_gt_irq(struct drm_i915_private *dev_priv, 
uint32_t mask)
ilk_update_gt_irq(dev_priv, mask, 0);
 }
 
-static i915_reg_t gen6_pm_iir(struct drm_i915_private *dev_priv)
+i915_reg_t gen6_pm_iir(struct drm_i915_private *dev_priv)
 {
return INTEL_GEN(dev_priv) >= 8 ? GEN8_GT_IIR(2) : GEN6_PMIIR;
 }
@@ -369,7 +368,7 @@ void gen6_mask_pm_irq(struct drm_i915_private *dev_priv, 
u32 mask)
__gen6_mask_pm_irq(dev_priv, mask);
 }
 
-static void gen6_reset_pm_iir(struct drm_i915_private *dev_priv, u32 
reset_mask)
+void gen6_reset_pm_iir(struct drm_i915_private *dev_priv, u32 reset_mask)
 {
i915_reg_t reg = gen6_pm_iir(dev_priv);
 
@@ -380,7 +379,7 @@ static void gen6_reset_pm_iir(struct drm_i915_private 
*dev_priv, u32 reset_mask)
POSTING_READ(reg);
 }
 
-static void gen6_enable_pm_irq(struct drm_i915_private *dev_priv, u32 
enable_mask)
+void gen6_enable_pm_irq(struct drm_i915_private *dev_priv, u32 enable_mask)
 {
lockdep_assert_held(&dev_priv->irq_lock);
 
@@ -390,7 +389,7 @@ static void gen6_enable_pm_irq(struct drm_i915_private 
*dev_priv, u32 enable_mas
/* unmask_pm_irq provides an implicit barrier (POSTING_READ) */
 }
 
-static void gen6_disable_pm_irq(struct drm_i915_private *dev_priv, u32 
disable_mask)
+void gen6_disable_pm_irq(struct drm_i915_private *dev_priv, u32 disable_mask)
 {
lockdep_assert_held(&dev_priv->irq_lock);
 
@@ -450,38 +449,6 @@ void gen6_disable_rps_interrupts(struct drm_i915_private 
*dev_priv)
gen6_reset_rps_interrupts(dev_priv);
 }
 
-void gen9_reset_guc_interrupts(struct drm_i915_private *dev_priv)
-{
-   spin_lock_irq(&dev_priv->irq_lock);
-   gen6_reset_pm_iir(dev_priv, dev_priv->pm_guc_events);
-   spin_unlock_irq(&dev_priv->irq_lock);
-}
-
-void gen9_enable_guc_interrupts(struct drm_i915_private *dev_priv)
-{
-   spin_lock_irq(&dev_priv->irq_lock);
-   if (!dev_priv->guc.interrupts_enabled) {
-   WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) &
-  dev_priv->pm_guc_events);
-   dev_priv->guc.interrupts_enabled = true;
-   gen6_enable_pm_irq(dev_priv, dev_priv->pm_guc_events);
-   }
-   spin_unlock_irq(&dev_priv->irq_lock);
-}
-
-void gen9_disable_guc_interrupts(struct drm_i915_private *dev_priv)
-{
-   spin_lock_irq(&dev_priv->irq_lock);
-   dev_priv->guc.interrupts_enabled = false;
-
-   gen6_disable_pm_irq(dev_priv, dev_priv->pm_guc_events);
-
-   spin_unlock_irq(&dev_priv->irq_lock);
-   synchronize_irq(dev_priv->drm.irq);
-
-   gen9_reset_guc_interrupts(dev_priv);
-}
-
 /**
  * bdw_update_port_irq - update DE port interrupt
  * @dev_priv: driver private
@@ -1480,7 +1447,7 @@ static void gen8_gt_irq_handler(struct drm_i915_private 
*dev_priv,
gen6_rps_irq_handler(dev_priv, gt_iir[2]);
 
if (gt_iir[2] & dev_priv->pm_guc_events)
-   gen9_guc_irq_handler(dev_priv, gt_iir[2]);
+   in

[Intel-gfx] [PATCH v4 5/9] drm/i915/guc: Make guc_log_level parameter immutable

2018-01-05 Thread Sagar Arun Kamble
This patch introduces i915 internal state variable in GuC log struct,
"level" which will be copied from guc_log_level modparam during i915
load and thereafter be available for user updates. This will make
guc_log_level parameter immutable.

v2: Rebase.

Suggested-by: Tvrtko Ursulin 
Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  2 +-
 drivers/gpu/drm/i915/intel_guc.c |  6 +++---
 drivers/gpu/drm/i915/intel_guc_log.c | 23 ++-
 drivers/gpu/drm/i915/intel_guc_log.h |  6 ++
 drivers/gpu/drm/i915/intel_uc.c  | 11 +--
 5 files changed, 29 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2bb6307..16f9a95 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2459,7 +2459,7 @@ static int i915_guc_log_control_get(void *data, u64 *val)
if (!dev_priv->guc.log.vma)
return -EINVAL;
 
-   *val = i915_modparams.guc_log_level;
+   *val = dev_priv->guc.log.level;
 
return 0;
 }
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 9dac3ee..710b4c4 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -253,9 +253,9 @@ void intel_guc_init_params(struct intel_guc *guc)
 
params[GUC_CTL_LOG_PARAMS] = guc->log.flags;
 
-   if (i915_modparams.guc_log_level >= 0) {
+   if (guc->log.level >= 0) {
params[GUC_CTL_DEBUG] =
-   i915_modparams.guc_log_level << GUC_LOG_VERBOSITY_SHIFT;
+   guc->log.level << GUC_LOG_VERBOSITY_SHIFT;
} else {
params[GUC_CTL_DEBUG] = GUC_LOG_DISABLED;
}
@@ -451,7 +451,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
 
-   if (i915_modparams.guc_log_level >= 0)
+   if (guc->log.level >= 0)
intel_guc_enable_interrupts(guc);
 
data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 7bae6eb..aa6434a 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -147,7 +147,7 @@ static int guc_log_relay_file_create(struct intel_guc *guc)
struct dentry *log_dir;
int ret;
 
-   if (i915_modparams.guc_log_level < 0)
+   if (guc->log.level < 0)
return 0;
 
/* For now create the log file in /sys/kernel/debug/dri/0 dir */
@@ -364,7 +364,7 @@ int intel_guc_log_runtime_create(struct intel_guc *guc)
size_t n_subbufs, subbuf_size;
int ret;
 
-   if (i915_modparams.guc_log_level < 0)
+   if (guc->log.level < 0)
return 0;
 
lockdep_assert_held(&dev_priv->drm.struct_mutex);
@@ -426,7 +426,7 @@ void intel_guc_log_runtime_destroy(struct intel_guc *guc)
 {
/*
 * It's possible that the runtime stuff was never allocated because
-* guc_log_level was < 0 at the time
+* guc->log.level was < 0 at the time
 **/
if (!guc_log_has_runtime(guc))
return;
@@ -463,7 +463,7 @@ static int guc_log_late_setup(struct intel_guc *guc)
intel_guc_log_runtime_destroy(guc);
 err:
/* logging will remain off */
-   i915_modparams.guc_log_level = -1;
+   guc->log.level = -1;
return ret;
 }
 
@@ -484,7 +484,7 @@ static void guc_log_capture_logs(struct intel_guc *guc)
 static void guc_flush_logs(struct intel_guc *guc)
 {
if (!USES_GUC_SUBMISSION(dev_priv) ||
-   (i915_modparams.guc_log_level < 0))
+   guc->log.level < 0)
return;
 
/* First disable the interrupts, will be renabled afterwards */
@@ -512,9 +512,6 @@ int intel_guc_log_create(struct intel_guc *guc)
 
GEM_BUG_ON(guc->log.vma);
 
-   if (i915_modparams.guc_log_level > GUC_LOG_VERBOSITY_MAX)
-   i915_modparams.guc_log_level = GUC_LOG_VERBOSITY_MAX;
-
/* The first page is to save log buffer state. Allocate one
 * extra page for others in case for overlap */
size = (1 + GUC_LOG_DPC_PAGES + 1 +
@@ -551,7 +548,7 @@ int intel_guc_log_create(struct intel_guc *guc)
 
 err:
/* logging will be off */
-   i915_modparams.guc_log_level = -1;
+   guc->log.level = -1;
return ret;
 }
 
@@ -574,7 +571,7 @@ int i915_guc_log_control(struct drm_i915_private *dev_priv, 
u64 control_val)
return -EINVAL;
 
/* This combination doesn't make sense & won't have any effect */
-   if (!log_param.logging_enabled && 

[Intel-gfx] [PATCH v4 2/9] drm/i915/guc: Fix GuC interrupts disabling with logging

2018-01-05 Thread Sagar Arun Kamble
With guc_log_unregister disabling runtime logging and interrupts, there
is no need to disable interrupts during uc_fini_hw hence it is removed.
With GuC CT buffer mechanism, interrupt disabling can be added later at
a point where CT mechanism ceases.

v2: Rebase.

v3: Moved this patch earlier in the series. (Tvrtko)

v4: Rebase.

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_uc.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 16ed558..0e1227f 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -377,7 +377,4 @@ void intel_uc_fini_hw(struct drm_i915_private *dev_priv)
intel_guc_submission_disable(guc);
 
guc_disable_communication(guc);
-
-   if (USES_GUC_SUBMISSION(dev_priv))
-   intel_guc_disable_interrupts(guc);
 }
-- 
1.9.1

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


[Intel-gfx] [PATCH v4 0/9] GuC Interrupts/Log updates

2018-01-05 Thread Sagar Arun Kamble
This series addresses following features/fixes:
1. Restructuring to move GuC interrupts related functions to guc.c
2. Making GuC interrupts enable/disable client based and tying up with
   logging at all places.
3. Handle suspend/resume/reset for GuC interrupts.
4. Logging fixes about RPM wakeref and skipping relay release during
   uc_fini.

v2: Rebase.
v3: Made guc_log_level parameter immutable, client support for interrupt
control.
v4: Consolidated patches and addressed reviews. Dropped patch about
guc_log_level sanitization.

Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Radoslaw Szwichtenberg 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 

Sagar Arun Kamble (9):
  drm/i915/guc: Move GuC interrupts related functions from i915_irq.c to
intel_guc.c
  drm/i915/guc: Fix GuC interrupts disabling with logging
  drm/i915/guc: Separate creation/release of runtime logging data from
base logging data
  drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts
  drm/i915/guc: Make guc_log_level parameter immutable
  drm/i915/guc: Make GuC log related functions depend only on log level
  drm/i915/guc: Add client support to enable/disable GuC interrupts
  drm/i915/guc: Restore GuC interrupts across suspend/reset if enabled
  HAX: drm/i915/guc: enable GuC submission/logging for CI

 drivers/gpu/drm/i915/i915_debugfs.c  |   8 +-
 drivers/gpu/drm/i915/i915_drv.c  |   4 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c  |   8 +-
 drivers/gpu/drm/i915/i915_irq.c  |  78 ++-
 drivers/gpu/drm/i915/i915_params.h   |   4 +-
 drivers/gpu/drm/i915/intel_display.c |   2 +
 drivers/gpu/drm/i915/intel_drv.h |   7 +-
 drivers/gpu/drm/i915/intel_guc.c | 145 +--
 drivers/gpu/drm/i915/intel_guc.h |  15 +++-
 drivers/gpu/drm/i915/intel_guc_log.c |  79 ++-
 drivers/gpu/drm/i915/intel_guc_log.h |  10 +++
 drivers/gpu/drm/i915/intel_uc.c  |  27 ---
 12 files changed, 242 insertions(+), 145 deletions(-)

-- 
1.9.1

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


[Intel-gfx] [PATCH v4 4/9] drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts

2018-01-05 Thread Sagar Arun Kamble
Disabling GuC interrupts involves access to GuC IRQ control registers
hence ensure device is RPM awake.

v2: Add comment about need to synchronize flush work and log runtime
destroy

v3: Moved patch earlier in the series and removed comment about future
work. (Tvrtko)

v4: Rebase.

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_guc_log.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index d866645..7bae6eb 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -631,7 +631,10 @@ void i915_guc_log_unregister(struct drm_i915_private 
*dev_priv)
 
mutex_lock(&dev_priv->drm.struct_mutex);
/* GuC logging is currently the only user of Guc2Host interrupts */
+   intel_runtime_pm_get(dev_priv);
intel_guc_disable_interrupts(&dev_priv->guc);
+   intel_runtime_pm_put(dev_priv);
+
intel_guc_log_runtime_destroy(&dev_priv->guc);
mutex_unlock(&dev_priv->drm.struct_mutex);
 }
-- 
1.9.1

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


[Intel-gfx] [PATCH v4 7/9] drm/i915/guc: Add client support to enable/disable GuC interrupts

2018-01-05 Thread Sagar Arun Kamble
This patch adds support to enable/disable GuC interrupts for different
features without impacting other's need. Currently GuC log capture and
CT buffer receive mechanisms use the GuC interrupts. GuC interrupts are
currently enabled and disabled in different logging scenarios all gated
by log level.

v2: Rebase with all GuC interrupt handlers moved to intel_guc.c. Handling
multiple clients for GuC interrupts enable/disable.
(Michal Wajdeczko)

v3: Removed spin lock and using test_bit in i915_guc_info. Prepared low
level helpers to get/put GuC interrupts that can be reused during
suspend/resume. (Tvrtko)

v4: Rebase. Removed comments about logging being sole user of interrupts.
s/guc_intr_client/intel_guc_intr_client. Reverted function names to
enable/disable_interrupts from get/put_interrupts as applicable. (Michal)

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  6 +
 drivers/gpu/drm/i915/intel_guc.c | 45 
 drivers/gpu/drm/i915/intel_guc.h | 13 ---
 drivers/gpu/drm/i915/intel_guc_log.c |  6 ++---
 4 files changed, 53 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 16f9a95..eef4c8b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2340,6 +2340,12 @@ static int i915_guc_info(struct seq_file *m, void *data)
GEM_BUG_ON(!guc->execbuf_client);
GEM_BUG_ON(!guc->preempt_client);
 
+   seq_puts(m, "GuC Interrupt Clients: ");
+   if (test_bit(GUC_INTR_CLIENT_LOG, &guc->interrupt_clients))
+   seq_puts(m, "GuC Logging\n");
+   else
+   seq_puts(m, "None\n");
+
seq_printf(m, "Doorbell map:\n");
seq_printf(m, "\t%*pb\n", GUC_NUM_DOORBELLS, guc->doorbell_bitmap);
seq_printf(m, "Doorbell next cacheline: 0x%x\n\n", guc->db_cacheline);
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 7b06c7b..7d66ee5 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -522,28 +522,53 @@ void intel_guc_reset_interrupts(struct intel_guc *guc)
spin_unlock_irq(&dev_priv->irq_lock);
 }
 
-void intel_guc_enable_interrupts(struct intel_guc *guc)
+static void __intel_guc_enable_interrupts(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
+   lockdep_assert_held(&dev_priv->irq_lock);
+
+   WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) &
+  dev_priv->pm_guc_events);
+   gen6_enable_pm_irq(dev_priv, dev_priv->pm_guc_events);
+}
+
+void intel_guc_enable_interrupts(struct intel_guc *guc,
+enum intel_guc_intr_client id)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
 
spin_lock_irq(&dev_priv->irq_lock);
-   if (!guc->interrupts_enabled) {
-   WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) &
-  dev_priv->pm_guc_events);
-   guc->interrupts_enabled = true;
-   gen6_enable_pm_irq(dev_priv, dev_priv->pm_guc_events);
-   }
+
+   if (!guc->interrupt_clients)
+   __intel_guc_enable_interrupts(guc);
+   __set_bit(id, &guc->interrupt_clients);
+
spin_unlock_irq(&dev_priv->irq_lock);
 }
 
-void intel_guc_disable_interrupts(struct intel_guc *guc)
+static void __intel_guc_disable_interrupts(struct intel_guc *guc)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
 
-   spin_lock_irq(&dev_priv->irq_lock);
-   guc->interrupts_enabled = false;
+   lockdep_assert_held(&dev_priv->irq_lock);
 
gen6_disable_pm_irq(dev_priv, dev_priv->pm_guc_events);
+}
+
+void intel_guc_disable_interrupts(struct intel_guc *guc,
+ enum intel_guc_intr_client id)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
+   spin_lock_irq(&dev_priv->irq_lock);
+
+   __clear_bit(id, &guc->interrupt_clients);
+   if (guc->interrupt_clients) {
+   spin_unlock_irq(&dev_priv->irq_lock);
+   return;
+   }
+   __intel_guc_disable_interrupts(guc);
 
spin_unlock_irq(&dev_priv->irq_lock);
synchronize_irq(dev_priv->drm.irq);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 1df9222..f248565 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -34,6 +34,11 @@
 #include "intel_uc_fw.h"
 #include "i915_vma.h"
 
+enum intel_guc_intr_client {
+   GUC_INTR_CLIENT_LOG = 0,

[Intel-gfx] [PATCH v4 8/9] drm/i915/guc: Restore GuC interrupts across suspend/reset if enabled

2018-01-05 Thread Sagar Arun Kamble
In order to override the disable/enable control of GuC interrupts during
suspend/reset cycle we are creating two new functions suspend/restore
guc_interrupts which check if interrupts were enabled and disable them
on suspend and enable them on resume. They are used to restore interrupts
across reset as well.

Further restructuring of runtime_pm_enable/disable_interrupts and
suspend/restore_guc_interrupts will be done in upcoming patches.

v2: Rebase.

v3: Updated suspend/restore with the new low level get/put functions.
(Tvrtko)

v4: Rebase. s/intel_*_guc_interrupts/intel_guc_*_interrupts (Michal)

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_display.c |  2 ++
 drivers/gpu/drm/i915/intel_guc.c | 30 --
 drivers/gpu/drm/i915/intel_guc.h |  2 ++
 3 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0cd3559..fe5e71a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3676,8 +3676,10 @@ void intel_finish_reset(struct drm_i915_private 
*dev_priv)
 * The display has been reset as well,
 * so need a full re-initialization.
 */
+   intel_guc_suspend_interrupts(&dev_priv->guc);
intel_runtime_pm_disable_interrupts(dev_priv);
intel_runtime_pm_enable_interrupts(dev_priv);
+   intel_guc_restore_interrupts(&dev_priv->guc);
 
intel_pps_unlock_regs_wa(dev_priv);
intel_modeset_init_hw(dev);
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 7d66ee5..0a33eda 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -406,7 +406,7 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
 
-   intel_guc_log_disable_interrupts(guc);
+   intel_guc_suspend_interrupts(guc);
 
data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
/* any value greater than GUC_POWER_D0 */
@@ -451,7 +451,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
 
-   intel_guc_log_enable_interrupts(guc);
+   intel_guc_restore_interrupts(guc);
 
data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
data[1] = GUC_POWER_D0;
@@ -547,6 +547,16 @@ void intel_guc_enable_interrupts(struct intel_guc *guc,
spin_unlock_irq(&dev_priv->irq_lock);
 }
 
+void intel_guc_restore_interrupts(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
+   spin_lock_irq(&dev_priv->irq_lock);
+   if (guc->interrupt_clients)
+   __intel_guc_enable_interrupts(guc);
+   spin_unlock_irq(&dev_priv->irq_lock);
+}
+
 static void __intel_guc_disable_interrupts(struct intel_guc *guc)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
@@ -576,6 +586,22 @@ void intel_guc_disable_interrupts(struct intel_guc *guc,
intel_guc_reset_interrupts(guc);
 }
 
+void intel_guc_suspend_interrupts(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
+   spin_lock_irq(&dev_priv->irq_lock);
+   if (!guc->interrupt_clients) {
+   spin_unlock_irq(&dev_priv->irq_lock);
+   return;
+   }
+   __intel_guc_disable_interrupts(guc);
+   spin_unlock_irq(&dev_priv->irq_lock);
+   synchronize_irq(dev_priv->drm.irq);
+
+   intel_guc_reset_interrupts(guc);
+}
+
 void intel_guc_irq_handler(struct intel_guc *guc, u32 gt_iir)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index f248565..ef7d2fd 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -142,5 +142,7 @@ void intel_guc_enable_interrupts(struct intel_guc *guc,
 void intel_guc_disable_interrupts(struct intel_guc *guc,
  enum intel_guc_intr_client id);
 void intel_guc_irq_handler(struct intel_guc *guc, u32 pm_iir);
+void intel_guc_suspend_interrupts(struct intel_guc *guc);
+void intel_guc_restore_interrupts(struct intel_guc *guc);
 
 #endif
-- 
1.9.1

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


[Intel-gfx] [PATCH v4 6/9] drm/i915/guc: Make GuC log related functions depend only on log level

2018-01-05 Thread Sagar Arun Kamble
With GuC log level set properly only for cases where GuC is loaded we can
remove the GuC submission checks from flush_guc_logs and guc_log_register,
unregister and uc_fini_hw functions. It is important to note that GuC log
runtime data has to be freed during driver unregister.
Freeing of that data can't be gated by guc_log_level check because if we
free GuC log runtime only when log level >=0 then it will not be destroyed
when logging is disabled after enabling before driver unload.

Also, with this patch GuC interrupts are enabled first after GuC load if
logging is enabled. GuC to Host interrupts will be needed for GuC CTB
mechanism and hence we will be adding client support to control the
interrupt for Log and CTB feature in next patch. To prepare for that all
interrupt updates are now gated by GuC log level checks through new
functions intel_guc_log_*_interrupts.

v2: Rebase. Updated check in i915_guc_log_unregister to be based on
guc_log_level. (Michal Wajdeczko)

v3: Rebase. Made all GuC log related functions depend only log level.
Updated uC init w.r.t enabling of GuC interrupts. Commit message update.
Rebase w.r.t guc_log_level immutable changes. (Tvrtko)

v4: Rebase. Prepared new functions intel_guc_log_*_interrupts to reduce
log level checks. (Michal)
Added HAS_GUC checks to i915_guc_log_register/unregister as the parameter
is not sanitized. (Sagar)

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_guc.c |  5 ++---
 drivers/gpu/drm/i915/intel_guc_log.c | 29 +
 drivers/gpu/drm/i915/intel_guc_log.h |  2 ++
 drivers/gpu/drm/i915/intel_uc.c  | 13 ++---
 4 files changed, 31 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 710b4c4..7b06c7b 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -406,7 +406,7 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
 
-   intel_guc_disable_interrupts(guc);
+   intel_guc_log_disable_interrupts(guc);
 
data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
/* any value greater than GUC_POWER_D0 */
@@ -451,8 +451,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
 
-   if (guc->log.level >= 0)
-   intel_guc_enable_interrupts(guc);
+   intel_guc_log_enable_interrupts(guc);
 
data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
data[1] = GUC_POWER_D0;
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index aa6434a..1e535e6 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -483,12 +483,11 @@ static void guc_log_capture_logs(struct intel_guc *guc)
 
 static void guc_flush_logs(struct intel_guc *guc)
 {
-   if (!USES_GUC_SUBMISSION(dev_priv) ||
-   guc->log.level < 0)
+   if (guc->log.level < 0)
return;
 
/* First disable the interrupts, will be renabled afterwards */
-   intel_guc_disable_interrupts(guc);
+   intel_guc_log_disable_interrupts(guc);
 
/* Before initiating the forceful flush, wait for any pending/ongoing
 * flush to complete otherwise forceful flush may not actually happen.
@@ -594,7 +593,7 @@ int i915_guc_log_control(struct drm_i915_private *dev_priv, 
u64 control_val)
}
 
/* GuC logging is currently the only user of Guc2Host 
interrupts */
-   intel_guc_enable_interrupts(guc);
+   intel_guc_log_enable_interrupts(guc);
} else {
/* Once logging is disabled, GuC won't generate logs & send an
 * interrupt. But there could be some data in the log buffer
@@ -612,8 +611,10 @@ int i915_guc_log_control(struct drm_i915_private 
*dev_priv, u64 control_val)
 
 void i915_guc_log_register(struct drm_i915_private *dev_priv)
 {
-   if (!USES_GUC_SUBMISSION(dev_priv) ||
-   dev_priv->guc.log.level < 0)
+   if (!HAS_GUC(dev_priv))
+   return;
+
+   if (dev_priv->guc.log.level < 0)
return;
 
mutex_lock(&dev_priv->drm.struct_mutex);
@@ -623,15 +624,27 @@ void i915_guc_log_register(struct drm_i915_private 
*dev_priv)
 
 void i915_guc_log_unregister(struct drm_i915_private *dev_priv)
 {
-   if (!USES_GUC_SUBMISSION(dev_priv))
+   if (!HAS_GUC(dev_priv))
return;
 
mutex_lock(&dev_priv->drm.struct_mutex);
/* GuC logging is currently the only user of Guc2Host interrupts */
intel_runtime_pm_get(dev_priv);
-   intel_guc_disable_interrupts(&

[Intel-gfx] [PATCH v4 3/9] drm/i915/guc: Separate creation/release of runtime logging data from base logging data

2018-01-05 Thread Sagar Arun Kamble
GuC log runtime/relay channel data will get released during i915
unregister, and only GuC log vma needs to be released during fini. To
achieve this, prepare separate helpers to create/destroy base and runtime
logging.
This separation is also needed to couple runtime log data and interrupts
handling together. In future we might not want to consider runtime data
creation failure as catastrophic to abort GuC load. Then we can ignore
the return error codes from intel_guc_log_runtime_create().

v2: Rebase.

v3: Refined usage of intel_guc_log_destroy and created new function
intel_guc_log_runtime_destroy. (Tvrtko)
Added intel_guc_log_runtime_create to separate the creation part as well.

v4: Rebase.

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_guc.c |  8 +++-
 drivers/gpu/drm/i915/intel_guc_log.c | 22 --
 drivers/gpu/drm/i915/intel_guc_log.h |  2 ++
 3 files changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 7278bde..9dac3ee 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -168,9 +168,13 @@ int intel_guc_init(struct intel_guc *guc)
if (ret)
goto err_shared;
 
-   ret = intel_guc_ads_create(guc);
+   ret = intel_guc_log_runtime_create(guc);
if (ret)
goto err_log;
+
+   ret = intel_guc_ads_create(guc);
+   if (ret)
+   goto err_log_runtime;
GEM_BUG_ON(!guc->ads_vma);
 
/* We need to notify the guc whenever we change the GGTT */
@@ -178,6 +182,8 @@ int intel_guc_init(struct intel_guc *guc)
 
return 0;
 
+err_log_runtime:
+   intel_guc_log_runtime_destroy(guc);
 err_log:
intel_guc_log_destroy(guc);
 err_shared:
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 84ae6f8..d866645 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -356,7 +356,7 @@ static bool guc_log_has_runtime(struct intel_guc *guc)
return guc->log.runtime.buf_addr != NULL;
 }
 
-static int guc_log_runtime_create(struct intel_guc *guc)
+int intel_guc_log_runtime_create(struct intel_guc *guc)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
void *vaddr;
@@ -364,6 +364,9 @@ static int guc_log_runtime_create(struct intel_guc *guc)
size_t n_subbufs, subbuf_size;
int ret;
 
+   if (i915_modparams.guc_log_level < 0)
+   return 0;
+
lockdep_assert_held(&dev_priv->drm.struct_mutex);
 
GEM_BUG_ON(guc_log_has_runtime(guc));
@@ -419,7 +422,7 @@ static int guc_log_runtime_create(struct intel_guc *guc)
return ret;
 }
 
-static void guc_log_runtime_destroy(struct intel_guc *guc)
+void intel_guc_log_runtime_destroy(struct intel_guc *guc)
 {
/*
 * It's possible that the runtime stuff was never allocated because
@@ -445,7 +448,7 @@ static int guc_log_late_setup(struct intel_guc *guc)
 * handle log buffer flush interrupts would not have been done 
yet,
 * so do that now.
 */
-   ret = guc_log_runtime_create(guc);
+   ret = intel_guc_log_runtime_create(guc);
if (ret)
goto err;
}
@@ -457,7 +460,7 @@ static int guc_log_late_setup(struct intel_guc *guc)
return 0;
 
 err_runtime:
-   guc_log_runtime_destroy(guc);
+   intel_guc_log_runtime_destroy(guc);
 err:
/* logging will remain off */
i915_modparams.guc_log_level = -1;
@@ -535,12 +538,6 @@ int intel_guc_log_create(struct intel_guc *guc)
 
guc->log.vma = vma;
 
-   if (i915_modparams.guc_log_level >= 0) {
-   ret = guc_log_runtime_create(guc);
-   if (ret < 0)
-   goto err_vma;
-   }
-
/* each allocated unit is a page */
flags = GUC_LOG_VALID | GUC_LOG_NOTIFY_ON_HALF_FULL |
(GUC_LOG_DPC_PAGES << GUC_LOG_DPC_SHIFT) |
@@ -552,8 +549,6 @@ int intel_guc_log_create(struct intel_guc *guc)
 
return 0;
 
-err_vma:
-   i915_vma_unpin_and_release(&guc->log.vma);
 err:
/* logging will be off */
i915_modparams.guc_log_level = -1;
@@ -562,7 +557,6 @@ int intel_guc_log_create(struct intel_guc *guc)
 
 void intel_guc_log_destroy(struct intel_guc *guc)
 {
-   guc_log_runtime_destroy(guc);
i915_vma_unpin_and_release(&guc->log.vma);
 }
 
@@ -638,6 +632,6 @@ void i915_guc_log_unregister(struct drm_i915_private 
*dev_priv)
mutex_lock(&dev_priv->drm.struct_mutex);
/* GuC logging is currently the only user of Guc2Host interrupts */
intel_guc_disable_interrupts(&dev_priv->guc);
-   guc_log_runtim

Re: [Intel-gfx] [PATCH v3 04/12] drm/i915/guc: Add description and comments about guc_log_level parameter

2018-01-05 Thread Sagar Arun Kamble



On 1/5/2018 10:24 AM, Sagar Arun Kamble wrote:



On 1/4/2018 10:22 PM, Michal Wajdeczko wrote:
On Thu, 04 Jan 2018 17:21:46 +0100, Sagar Arun Kamble 
 wrote:



guc_log_level parameter takes effect when GuC is loaded which is
controlled through enable_guc parameter. Add this relation info.

^^^
Extra "."


in parameter description and documentation.
Earlier, this patch was added to sanitize guc_log_level like old
GuC parameters enable_guc_loading/submission. With new parameter
enable_guc, sanitization of guc_log_level is no more needed.


Hmm, I think we still need to sanitize log_level if it was wrongly
enabled without enabling GuC first (in intel_uc_sanitize_options).
I think it would not be harmful as all decisions based on it will be 
gated by USES_GUC.
I was wrong. i915_guc_log_register/unregister were changed by my series 
to only rely on guc_log_level.
I have added HAS_GUC check in those function in v4 patch. Is that option 
okay or we should sanitize this parameter?




v2: Added documentation to intel_guc_log.c and param description
about GuC loading dependency. (Michal Wajdeczko)

v3: Removed sanitization of module parameter guc_log_level.
Previous review comments not applicable now.

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin  #v2
---
 drivers/gpu/drm/i915/i915_params.c   | 3 ++-
 drivers/gpu/drm/i915/intel_guc_log.c | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c

index b5f3eb4..a93a6ca 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -155,7 +155,8 @@ struct i915_params i915_modparams __read_mostly = {
 "(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)");
i915_param_named(guc_log_level, int, 0400,
-    "GuC firmware logging level (-1:disabled (default), 
0-3:enabled)");
+    "GuC firmware logging level. This takes effect only if GuC is 
to be "
+    "loaded (depends on enable_guc) (-1:disabled (default), 
0-3:enabled)");


Btw, I was planing to change above values to follow schema used in 
other modparams:


-1: auto (then it can be controlled by USES_GUC and DRM_I915_DEBUG_GUC)
 0: disabled
 1: enabled (legacy level 0)
 2: enabled (legacy level 1)
 3: enabled (legacy level 2)
 4: enabled (legacy level 3)

So now I'm not sure that I want your patch ;)


Makes sense. Will drop this patch.

Thanks
Sagar

i915_param_named_unsafe(guc_firmware_path, charp, 0400,
 "GuC firmware path to use instead of the default one");
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c

index 59a9021..d0131bc 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -34,6 +34,7 @@
  * DOC: GuC firmware log
  *
  * Firmware log is enabled by setting i915.guc_log_level to 
non-negative level.

+ * This takes effect only if GuC is to be loaded based on enable_guc.


... based on i915.enable_guc modparam.

  * Log data is printed out via reading debugfs i915_guc_log_dump. 
Reading from
  * i915_guc_load_status will print out firmware loading status and 
scratch

  * registers value.




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


Re: [Intel-gfx] [RFC] drm/i915: Add a new modparam for customized ring multiplier

2018-01-05 Thread Sagar Arun Kamble



On 1/5/2018 3:22 AM, Yaodong Li wrote:


On 01/03/2018 10:10 PM, Sagar Arun Kamble wrote:
Since ring frequency programming needs consideration of both IA and 
GT frequency requests I think keeping the logic
to program the ring frequency table in driver that monitors both 
IA/GT busyness and power budgets like intel_ips
will be more appropriate. intel_ips is relying on global load derived 
from all CPUs.
I understand that power awareness and busyness based policy might be 
trickier but having that as tunable will give better flexibility.


By just looking into the current code, the way intel_ips checks gpu 
busyness cannot reflect the actual workload of GT
(e.g. gpu busy is true even if there's only one pending request), in 
this case, we shall not increase the ring freq if we
want to use a "workload monitoring" based solution. so we need a more 
accurate way to monitor the current GT workload
(e.g.  when the pending request count reaches a center tunable 
threshold??).

Yes. May be we can share the PMU data about engine busyness with intel_ips.



On 1/3/2018 11:51 PM, Yaodong Li wrote:


You are thinking of plugging into intel_pstate to make it smarter 
for ia freq transitions?
Yep. This seems a correct step to give some automatic support 
instead of parameter/hardcoded multiplier.


Does this mean we should use cpufreq/intel_pstate based approach 
instead of the current modparam solution for Gen9?


Some concerns and questions about intel_pstate approach:
a) Currently, we cannot get the accurate pstate/target freq value 
from cpufreq in intel_pstate active mode since
 these values won't be exported to cpufreq layer, so if we won't 
change intel_pstate code then we only can get

 the max cpu freq of a new policy.
b) intel_pstate policy is attached to each logic cpu, which means we 
will receive policy/freq transition notification
    for each logic cpu freq change. One question is how we are going 
to decide the freq of the ring? just use the max

    cpu freq reported?
c) With the intel_pstate approach we may still run into thermal 
throttling, in this case, can a certain cooling device

    be triggered to lower the cpu freq?

Thanks and Regards,
-Jackie







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


Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for GuC Interrupts/Log updates (rev3)

2018-01-05 Thread Sagar Arun Kamble



On 1/5/2018 2:42 PM, Patchwork wrote:

== Series Details ==

Series: GuC Interrupts/Log updates (rev3)
URL   : https://patchwork.freedesktop.org/series/32179/
State : failure

== Summary ==

Series 32179v3 GuC Interrupts/Log updates
https://patchwork.freedesktop.org/api/1.0/series/32179/revisions/3/mbox/

Test core_auth:
 Subgroup basic-auth:
 pass   -> SKIP   (fi-skl-gvtdvm)
Test core_prop_blob:
 Subgroup basic:
 pass   -> SKIP   (fi-skl-gvtdvm)
Test debugfs_test:
 Subgroup read_all_entries:
 incomplete -> PASS   (fi-snb-2520m) fdo#103713 +1
 pass   -> DMESG-WARN (fi-skl-6260u)
 pass   -> DMESG-WARN (fi-skl-6600u)
 pass   -> DMESG-WARN (fi-skl-6700hq)
 pass   -> DMESG-WARN (fi-skl-6700k2)
 pass   -> DMESG-WARN (fi-skl-6770hq)
 pass   -> SKIP   (fi-skl-gvtdvm)
 pass   -> DMESG-WARN (fi-bxt-dsi)
 pass   -> DMESG-WARN (fi-bxt-j4205)
 pass   -> DMESG-WARN (fi-kbl-7500u) fdo#103285
 pass   -> DMESG-WARN (fi-kbl-7560u)
 pass   -> DMESG-WARN (fi-kbl-7567u)
 pass   -> DMESG-WARN (fi-kbl-r)
These are related to circular locking between struct_mutex, mmap_sem, 
i_mutex_key, relay_channels_mutex.
Separating debugfs and relay channel setup from struct_mutex should 
likely resolve this and will be addressed

in new patch series.

Test drv_getparams_basic:
 Subgroup basic-eu-total:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup basic-subslice-total:
 pass   -> SKIP   (fi-skl-gvtdvm)
Test drv_hangman:
 Subgroup error-state-basic:
 pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_basic:
 Subgroup bad-close:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup create-close:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup create-fd-close:
 pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_busy:
 Subgroup basic-busy-default:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup basic-hang-default:
 pass   -> SKIP   (fi-skl-gvtdvm) fdo#104108 +2
Test gem_close_race:
 Subgroup basic-process:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup basic-threads:
 pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_cpu_reloc:
 Subgroup basic:
 pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_cs_tlb:
 Subgroup basic-default:
 pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_create:
 Subgroup basic:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup basic-files:
 pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_exec:
 Subgroup basic:
 pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_param:
 Subgroup basic:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup basic-default:
 pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_switch:
 Subgroup basic-default:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup basic-default-heavy:
 pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_exec_basic:
 Subgroup basic-blt:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup basic-bsd:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup basic-bsd1:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup basic-bsd2:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup basic-default:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup basic-render:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup basic-vebox:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup gtt-blt:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup gtt-bsd:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup gtt-bsd1:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup gtt-bsd2:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup gtt-default:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup gtt-render:
 pass   -> SKIP   (fi-skl-gvtdvm)
WARNING: Long output truncated
fi-glk-1 failed to collect. IGT log at Patchwork_7614/fi-glk-1/igt.log

3e7d28b655aefefe51f1d7ac6aba46d6ca03b658 drm-tip: 2018y-01m-04d-22h-45m-20s UTC 
integration manifest
5a97f4912290 HAX: drm/i915/guc: enable GuC submission/logging for CI
728519ffad84 drm/i915/guc: Restore GuC i

Re: [Intel-gfx] [RFC] drm/i915: Add a new modparam for customized ring multiplier

2018-01-08 Thread Sagar Arun Kamble



On 1/6/2018 5:53 AM, Yaodong Li wrote:

On 01/05/2018 02:15 AM, Sagar Arun Kamble wrote:



On 1/5/2018 3:22 AM, Yaodong Li wrote:


On 01/03/2018 10:10 PM, Sagar Arun Kamble wrote:
Since ring frequency programming needs consideration of both IA and 
GT frequency requests I think keeping the logic
to program the ring frequency table in driver that monitors both 
IA/GT busyness and power budgets like intel_ips
will be more appropriate. intel_ips is relying on global load 
derived from all CPUs.
I understand that power awareness and busyness based policy might 
be trickier but having that as tunable will give better flexibility.


By just looking into the current code, the way intel_ips checks gpu 
busyness cannot reflect the actual workload of GT
(e.g. gpu busy is true even if there's only one pending request), in 
this case, we shall not increase the ring freq if we
want to use a "workload monitoring" based solution. so we need a 
more accurate way to monitor the current GT workload
(e.g.  when the pending request count reaches a center tunable 
threshold??).
Yes. May be we can share the PMU data about engine busyness with 
intel_ips.
Thank you Sagar! Can you tell more about how we can get the gpu 
busyness from PMU data?


It seems to be not possible as of now since pmu is reporting accumulated 
busy time per engine without info about time they became active/idle,
unless I am missing something. Also having pmu ON in release environment 
needs to be checked. Chris, could you please clarify on pmu usage here.


Also thinking about below two options to get the GPU busyness:
1. Sharing i915 rps power zone (LOW_POWER, BETWEEN, HIGH_POWER) to 
intel_ips (kind of indicators of GPU load)
2. Sampling GT C0 counter to derive full GPU busyness. This though may 
not have been tested much so far across platforms.


I think the solution would be to set the ring freq table to use a ring 
freq >= current ia freq (for all possible gpu freq) once we found
gpu workload is high (need to tune the threshold), and we will 
decrease the ring freq (use a 2x multiplier?) once we found the GT
workload is low. The benefit to use the intel_ips is it can tell both 
the cpu & gpu busyness. However, we do need an accurate way

to check at least the busyness of gpu for this issue.

Agree.

Thanks
Sagar



On 1/3/2018 11:51 PM, Yaodong Li wrote:


You are thinking of plugging into intel_pstate to make it 
smarter for ia freq transitions?
Yep. This seems a correct step to give some automatic support 
instead of parameter/hardcoded multiplier.


Does this mean we should use cpufreq/intel_pstate based approach 
instead of the current modparam solution for Gen9?


Some concerns and questions about intel_pstate approach:
a) Currently, we cannot get the accurate pstate/target freq value 
from cpufreq in intel_pstate active mode since
 these values won't be exported to cpufreq layer, so if we 
won't change intel_pstate code then we only can get

 the max cpu freq of a new policy.
b) intel_pstate policy is attached to each logic cpu, which means 
we will receive policy/freq transition notification
    for each logic cpu freq change. One question is how we are 
going to decide the freq of the ring? just use the max

    cpu freq reported?
c) With the intel_pstate approach we may still run into thermal 
throttling, in this case, can a certain cooling device

    be triggered to lower the cpu freq?

Thanks and Regards,
-Jackie











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


Re: [Intel-gfx] [PATCH 02/22] drm/i915/icl: Enable Sampler DFR

2018-04-20 Thread Sagar Arun Kamble



On 4/13/2018 9:30 PM, Oscar Mateo wrote:

Sampler Dynamic Frequency Rebalancing (DFR) aims to reduce Sampler
power by dynamically changing its clock frequency in low-throughput
conditions. This patches enables it by default on Gen11.

v2: Wrong operation to clear the bit (Praveen)
v3: Rebased on top of the WA refactoring

Cc: Sagar Arun Kamble 
Cc: Praveen Paneri 
Cc: Mika Kuoppala 
Signed-off-by: Oscar Mateo 

Reviewed-by: Sagar Arun Kamble 

---
  drivers/gpu/drm/i915/i915_reg.h  | 3 +++
  drivers/gpu/drm/i915/intel_workarounds.c | 4 
  2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f2ee225..4b7e6bc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8218,6 +8218,9 @@ enum {
  #define GEN8_GARBCNTL   _MMIO(0xB004)
  #define   GEN9_GAPS_TSV_CREDIT_DISABLE  (1<<7)
  
+#define GEN10_DFR_RATIO_EN_AND_CHICKEN	_MMIO(0x9550)

+#define   DFR_DISABLE  (1 << 9)
+
  /* IVYBRIDGE DPF */
  #define GEN7_L3CDERRST1(slice)_MMIO(0xB008 + (slice) * 0x200) 
/* L3CD Error Status 1 */
  #define   GEN7_L3CDERRST1_ROW_MASK(0x7ff<<14)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c 
b/drivers/gpu/drm/i915/intel_workarounds.c
index 8c2d17c..34a0b56 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -692,6 +692,10 @@ static void icl_gt_workarounds_apply(struct 
drm_i915_private *dev_priv)
I915_WRITE(_3D_CHICKEN3,
   _MASKED_BIT_ENABLE(_3D_CHICKEN3_AA_LINE_QUALITY_FIX_ENABLE));
  
+	/* This is not an Wa. Enable to reduce Sampler power */

+   I915_WRITE(GEN10_DFR_RATIO_EN_AND_CHICKEN,
+  (I915_READ(GEN10_DFR_RATIO_EN_AND_CHICKEN) & ~DFR_DISABLE));
+
/* WaInPlaceDecompressionHang:icl */
I915_WRITE(GEN9_GAMT_ECO_REG_RW_IA, (I915_READ(GEN9_GAMT_ECO_REG_RW_IA) 
|
 
GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS));


--
Thanks,
Sagar

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


Re: [Intel-gfx] [PATCH] drm/i915: Use ktime on wait_for

2018-04-20 Thread Sagar Arun Kamble



On 4/20/2018 3:24 PM, Mika Kuoppala wrote:

We use jiffies to determine when wait expires. However
Imre did find out that jiffies can and will do a >1
increments on certain situations [1]. When this happens
in a wait_for loop, we return timeout errorneously
much earlier than what the real wallclock would say.

We can't afford our waits to timeout prematurely.
Discard jiffies and change to ktime to detect timeouts.

Reported-by: Imre Deak 
References: https://lkml.org/lkml/2018/4/18/798 [1]
Cc: Imre Deak 
Cc: Chris Wilson 
Cc: Ville Syrjälä 
Signed-off-by: Mika Kuoppala 
---
  drivers/gpu/drm/i915/intel_drv.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 8b20824e806e..ac7565220aa3 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -49,12 +49,12 @@
   * check the condition before the timeout.
   */
  #define __wait_for(OP, COND, US, Wmin, Wmax) ({ \
-   unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1;   \
+   const ktime_t end__ = ktime_add_ns(ktime_get_raw(), 1000ll * (US)); \

Is ktime_get_raw() monotonic? Thomas suggested ktime_get()

long wait__ = (Wmin); /* recommended min for usleep is 10 us */ \
int ret__;  \
might_sleep();  \
for (;;) {  \
-   bool expired__ = time_after(jiffies, timeout__);\
+   const bool expired__ = ktime_after(ktime_get_raw(), end__); \
OP; \
if (COND) { \
ret__ = 0;  \


--
Thanks,
Sagar

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


Re: [Intel-gfx] [PATCH] drm/i915: Use ktime on wait_for

2018-04-20 Thread Sagar Arun Kamble



On 4/20/2018 4:09 PM, Chris Wilson wrote:

Quoting Sagar Arun Kamble (2018-04-20 11:23:50)


On 4/20/2018 3:24 PM, Mika Kuoppala wrote:

We use jiffies to determine when wait expires. However
Imre did find out that jiffies can and will do a >1
increments on certain situations [1]. When this happens
in a wait_for loop, we return timeout errorneously
much earlier than what the real wallclock would say.

We can't afford our waits to timeout prematurely.
Discard jiffies and change to ktime to detect timeouts.

Reported-by: Imre Deak 
References: https://lkml.org/lkml/2018/4/18/798 [1]
Cc: Imre Deak 
Cc: Chris Wilson 
Cc: Ville Syrjälä 
Signed-off-by: Mika Kuoppala 
---
   drivers/gpu/drm/i915/intel_drv.h | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 8b20824e806e..ac7565220aa3 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -49,12 +49,12 @@
* check the condition before the timeout.
*/
   #define __wait_for(OP, COND, US, Wmin, Wmax) ({ \
- unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1;   \
+ const ktime_t end__ = ktime_add_ns(ktime_get_raw(), 1000ll * (US)); \

Is ktime_get_raw() monotonic? Thomas suggested ktime_get()

It proclaims to be monotonic, without the clock drift calibration. For
the milliseconds we should be sleeping at most, I hope that is
immaterial.
Yes. I remembered from Imre's comment[1] that raw clock can jump and 
will not be calibrated. If jumps are are not > jiffies we should be good 
get_raw then.


[1] 
https://lists.freedesktop.org/archives/dri-devel/2012-October/028878.html

-Chris


--
Thanks,
Sagar

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


[Intel-gfx] drm/i915/slpc: If using SLPC, do not set frequency

2016-08-19 Thread Sagar Arun Kamble
From: Tom O'Rourke 

When frequency requests are made by SLPC, host driver
should not attempt to make frequency requests due to
potential conflicts.

Host-based turbo operations are already avoided when
SLPC is used.  This change covers other frequency
requests such as from sysfs or debugfs interfaces.

A later patch in this series updates sysfs/debugfs
interfaces for setting max/min frequencies with SLPC.

v2: Use intel_slpc_active instead of HAS_SLPC (Paulo)

Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_pm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7156fb5..3b3f487 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4952,6 +4952,9 @@ void gen6_rps_boost(struct drm_i915_private *dev_priv,
 
 void intel_set_rps(struct drm_i915_private *dev_priv, u8 val)
 {
+   if (intel_slpc_active(dev_priv))
+   return;
+
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
valleyview_set_rps(dev_priv, val);
else
-- 
1.9.1

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


[Intel-gfx] drm/i915/slpc: Add i915_slpc_info to debugfs

2016-08-19 Thread Sagar Arun Kamble
From: Tom O'Rourke 

i915_slpc_info shows the contents of SLPC shared data
parsed into text format.

v2: reformat slpc info (Radek)
squashed query task state info
in slpc info, kunmap before seq_print (Paulo)
return void instead of ignored return value (Paulo)
v3: Avoid magic numbers and use local variables (Jon Bloomfield)
v5: Removed WARN_ON for checking msb of gtt address of
shared gem obj. (ChrisW)
Moved definition of power plan and power source to earlier
patch in the series.
drm/i915/slpc: Allocate/Release/Initialize SLPC shared data
(Akash)

Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 184 
 drivers/gpu/drm/i915/intel_slpc.c   |  19 
 drivers/gpu/drm/i915/intel_slpc.h   |   1 +
 3 files changed, 204 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7e125a1..cfe6dac 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1350,6 +1350,189 @@ static const struct file_operations i915_slpc_dcc_fops 
= {
.llseek  = seq_lseek
 };
 
+static int i915_slpc_info(struct seq_file *m, void *unused)
+{
+   struct drm_info_node *node = m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_i915_gem_object *obj;
+   struct page *page;
+   void *pv = NULL;
+   struct slpc_shared_data data;
+   int i, value;
+   enum slpc_global_state global_state;
+   enum slpc_platform_sku platform_sku;
+   enum slpc_host_os host_os;
+   enum slpc_power_plan power_plan;
+   enum slpc_power_source power_source;
+
+   obj = dev_priv->guc.slpc.vma->obj;
+   if (obj) {
+   intel_slpc_query_task_state(dev_priv);
+
+   page = i915_gem_object_get_page(obj, 0);
+   if (page)
+   pv = kmap_atomic(page);
+   }
+
+   if (pv) {
+   data = *(struct slpc_shared_data *) pv;
+   kunmap_atomic(pv);
+
+   seq_printf(m, "SLPC Version: %d.%d.%d (0x%8x)\n",
+  data.slpc_version >> 16,
+  (data.slpc_version >> 8) & 0xFF,
+  data.slpc_version & 0xFF,
+  data.slpc_version);
+   seq_printf(m, "shared data size: %d\n", data.shared_data_size);
+
+   global_state = (enum slpc_global_state) data.global_state;
+   seq_printf(m, "global state: %d (", global_state);
+   switch (global_state) {
+   case SLPC_GLOBAL_STATE_NOT_RUNNING:
+   seq_puts(m, "not running)\n");
+   break;
+   case SLPC_GLOBAL_STATE_INITIALIZING:
+   seq_puts(m, "initializing)\n");
+   break;
+   case SLPC_GLOBAL_STATE_RESETTING:
+   seq_puts(m, "resetting)\n");
+   break;
+   case SLPC_GLOBAL_STATE_RUNNING:
+   seq_puts(m, "running)\n");
+   break;
+   case SLPC_GLOBAL_STATE_SHUTTING_DOWN:
+   seq_puts(m, "shutting down)\n");
+   break;
+   case SLPC_GLOBAL_STATE_ERROR:
+   seq_puts(m, "error)\n");
+   break;
+   default:
+   seq_puts(m, "unknown)\n");
+   break;
+   }
+
+   platform_sku = (enum slpc_platform_sku)
+   data.platform_info.platform_sku;
+   seq_printf(m, "sku: %d (", platform_sku);
+   switch (platform_sku) {
+   case SLPC_PLATFORM_SKU_UNDEFINED:
+   seq_puts(m, "undefined)\n");
+   break;
+   case SLPC_PLATFORM_SKU_ULX:
+   seq_puts(m, "ULX)\n");
+   break;
+   case SLPC_PLATFORM_SKU_ULT:
+   seq_puts(m, "ULT)\n");
+   break;
+   case SLPC_PLATFORM_SKU_T:
+   seq_puts(m, "T)\n");
+   break;
+   case SLPC_PLATFORM_SKU_MOBL:
+   seq_puts(m, "Mobile)\n");
+   break;
+   case SLPC_PLATFORM_SKU_DT:
+   seq_puts(m, "DT)\n");
+   break;
+   case SLPC_PLATFORM_SKU_UNKNOWN:
+   default:
+   seq_puts(m, "unknown)\n");
+   break;
+   }
+

[Intel-gfx] drm/i915: Remove RPM suspend dependency on rps.enabled and related changes

2016-08-19 Thread Sagar Arun Kamble
For Gen9, RPM suspend is failing if rps.enabled=false. This is needed for
other platforms as RC6 and RPS enabling is indicated by rps.enabled.
RPM Suspend depends only on RC6, so we need to remove the check of rps.enabled.
For Gen9 RC6 and RPS enabling is separated hence do rps.enabled check only
for non-Gen9 platforms. Once RC6 and RPS enabling is separated for other GENs
this check can be completely removed.
Moved setting of rps.enabled to platform level functions as there is case of
disabling of RPS in gen9_enable_rps.

Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_drv.c | 10 +-
 drivers/gpu/drm/i915/intel_pm.c | 20 ++--
 2 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 13ae340..bc2c67b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2284,9 +2284,17 @@ static int intel_runtime_suspend(struct device *device)
struct drm_i915_private *dev_priv = to_i915(dev);
int ret;
 
-   if (WARN_ON_ONCE(!(dev_priv->rps.enabled && intel_enable_rc6(
+   if (WARN_ON_ONCE(!intel_enable_rc6()))
return -ENODEV;
 
+   /*
+* Once RC6 and RPS enabling is separated for non-GEN9 platforms
+* below check should be removed.
+   */
+   if (!IS_GEN9(dev))
+   if (WARN_ON_ONCE(!dev_priv->rps.enabled))
+   return -ENODEV;
+
if (WARN_ON_ONCE(!HAS_RUNTIME_PM(dev)))
return -ENODEV;
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 99014d7..954e332 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4966,6 +4966,7 @@ static void gen9_disable_rc6(struct drm_i915_private 
*dev_priv)
 static void gen9_disable_rps(struct drm_i915_private *dev_priv)
 {
I915_WRITE(GEN6_RP_CONTROL, 0);
+   dev_priv->rps.enabled = false;
 }
 
 static void gen6_disable_rps(struct drm_i915_private *dev_priv)
@@ -4973,11 +4974,16 @@ static void gen6_disable_rps(struct drm_i915_private 
*dev_priv)
I915_WRITE(GEN6_RC_CONTROL, 0);
I915_WRITE(GEN6_RPNSWREQ, 1 << 31);
I915_WRITE(GEN6_RP_CONTROL, 0);
+
+   dev_priv->rps.enabled = false;
+
 }
 
 static void cherryview_disable_rps(struct drm_i915_private *dev_priv)
 {
I915_WRITE(GEN6_RC_CONTROL, 0);
+
+   dev_priv->rps.enabled = false;
 }
 
 static void valleyview_disable_rps(struct drm_i915_private *dev_priv)
@@ -4989,6 +4995,8 @@ static void valleyview_disable_rps(struct 
drm_i915_private *dev_priv)
I915_WRITE(GEN6_RC_CONTROL, 0);
 
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+
+   dev_priv->rps.enabled = false;
 }
 
 static void intel_print_rc6_info(struct drm_i915_private *dev_priv, u32 mode)
@@ -5206,6 +5214,8 @@ static void gen9_enable_rps(struct drm_i915_private 
*dev_priv)
reset_rps(dev_priv, gen6_set_rps);
 
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+
+   dev_priv->rps.enabled = true;
 }
 
 static void gen9_enable_rc6(struct drm_i915_private *dev_priv)
@@ -5349,6 +5359,8 @@ static void gen8_enable_rps(struct drm_i915_private 
*dev_priv)
reset_rps(dev_priv, gen6_set_rps);
 
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+
+   dev_priv->rps.enabled = true;
 }
 
 static void gen6_enable_rps(struct drm_i915_private *dev_priv)
@@ -5445,6 +5457,8 @@ static void gen6_enable_rps(struct drm_i915_private 
*dev_priv)
}
 
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+
+   dev_priv->rps.enabled = true;
 }
 
 static void gen6_update_ring_freq(struct drm_i915_private *dev_priv)
@@ -5919,6 +5933,8 @@ static void cherryview_enable_rps(struct drm_i915_private 
*dev_priv)
reset_rps(dev_priv, valleyview_set_rps);
 
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+
+   dev_priv->rps.enabled = true;
 }
 
 static void valleyview_enable_rps(struct drm_i915_private *dev_priv)
@@ -5999,6 +6015,8 @@ static void valleyview_enable_rps(struct drm_i915_private 
*dev_priv)
reset_rps(dev_priv, valleyview_set_rps);
 
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+
+   dev_priv->rps.enabled = true;
 }
 
 static unsigned long intel_pxfreq(u32 vidfreq)
@@ -6588,7 +6606,6 @@ void intel_disable_gt_powersave(struct drm_i915_private 
*dev_priv)
ironlake_disable_drps(dev_priv);
}
 
-   dev_priv->rps.enabled = false;
mutex_unlock(&dev_priv->rps.hw_lock);
 }
 
@@ -6632,7 +6649,6 @@ void intel_enable_gt_powersave(struct drm_i915_private 
*dev_priv)
WARN_ON(dev_priv->rps.efficient_freq < dev_priv->rps.min_freq);
WARN_ON(dev_priv->rps.efficient_freq > dev_priv->rps.max_freq);
 
-   dev_priv->rps.enabled = true;
mutex_unlock(&dev_priv->rp

[Intel-gfx] drm/i915/slpc: Send shutdown event

2016-08-19 Thread Sagar Arun Kamble
From: Tom O'Rourke 

Send SLPC shutdown event during disable, suspend, and reset
operations.  Sending shutdown event while already shutdown
is OK.

v2: return void instead of ignored error code (Paulo)

v5: Removed WARN_ON for checking msb of gtt address of
shared gem obj. (ChrisW)
Added SLPC state update during disable, suspend and reset.
Changed semantics of reset. It is supposed to just disable. (Sagar)

Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_slpc.c | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_slpc.c 
b/drivers/gpu/drm/i915/intel_slpc.c
index 161cd13..5a1e6f2 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -52,6 +52,19 @@ static void host2guc_slpc_reset(struct drm_i915_private 
*dev_priv)
host2guc_slpc(dev_priv, data, 4);
 }
 
+static void host2guc_slpc_shutdown(struct drm_i915_private *dev_priv)
+{
+   u32 data[4];
+   u32 shared_data_gtt_offset = i915_ggtt_offset(dev_priv->guc.slpc.vma);
+
+   data[0] = HOST2GUC_ACTION_SLPC_REQUEST;
+   data[1] = SLPC_EVENT(SLPC_EVENT_SHUTDOWN, 2);
+   data[2] = shared_data_gtt_offset;
+   data[3] = 0;
+
+   host2guc_slpc(dev_priv, data, 4);
+}
+
 static u8 slpc_get_platform_sku(struct drm_device *dev)
 {
enum slpc_platform_sku platform_sku;
@@ -149,12 +162,14 @@ void intel_slpc_cleanup(struct drm_i915_private *dev_priv)
 
 void intel_slpc_suspend(struct drm_i915_private *dev_priv)
 {
-   return;
+   host2guc_slpc_shutdown(dev_priv);
+   dev_priv->guc.slpc.enabled = false;
 }
 
 void intel_slpc_disable(struct drm_i915_private *dev_priv)
 {
-   return;
+   host2guc_slpc_shutdown(dev_priv);
+   dev_priv->guc.slpc.enabled = false;
 }
 
 void intel_slpc_enable(struct drm_i915_private *dev_priv)
@@ -167,5 +182,6 @@ void intel_slpc_enable(struct drm_i915_private *dev_priv)
 
 void intel_slpc_reset(struct drm_i915_private *dev_priv)
 {
-   return;
+   host2guc_slpc_shutdown(dev_priv);
+   dev_priv->guc.slpc.enabled = false;
 }
-- 
1.9.1

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


[Intel-gfx] drm/i915/slpc: Add enable/disable debugfs for slpc

2016-08-19 Thread Sagar Arun Kamble
From: Tom O'Rourke 

Adds debugfs hooks for each slpc task.

The enable/disable debugfs files are
i915_slpc_gtperf, i915_slpc_balancer, and i915_slpc_dcc.

Each of these can take the values:
"default", "enabled", or "disabled"

v2: update for SLPC v2015.2.4
dfps and turbo merged and renamed "gtperf"
ibc split out and renamed "balancer"
v3: Avoid magic numbers (Jon Bloomfield)

Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 252 
 drivers/gpu/drm/i915/intel_slpc.h   |   5 +
 2 files changed, 257 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index fb497ea1..7e125a1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1101,6 +1101,255 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_next_seqno_fops,
i915_next_seqno_get, i915_next_seqno_set,
"0x%llx\n");
 
+static int slpc_enable_disable_get(struct drm_device *dev, u64 *val,
+  enum slpc_param_id enable_id,
+  enum slpc_param_id disable_id)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   int override_enable, override_disable;
+   u32 value_enable, value_disable;
+   int ret = 0;
+
+   if (!intel_slpc_active(dev_priv)) {
+   ret = -ENODEV;
+   } else if (val) {
+   intel_slpc_get_param(dev_priv, enable_id, &override_enable,
+&value_enable);
+   intel_slpc_get_param(dev_priv, disable_id, &override_disable,
+&value_disable);
+
+   /* set the output value:
+   * 0: default
+   * 1: enabled
+   * 2: disabled
+   * 3: unknown (should not happen)
+   */
+   if (override_disable && (1 == value_disable))
+   *val = SLPC_PARAM_TASK_DISABLED;
+   else if (override_enable && (1 == value_enable))
+   *val = SLPC_PARAM_TASK_ENABLED;
+   else if (!override_enable && !override_disable)
+   *val = SLPC_PARAM_TASK_DEFAULT;
+   else
+   *val = SLPC_PARAM_TASK_UNKNOWN;
+
+   } else {
+   ret = -EINVAL;
+   }
+
+   return ret;
+}
+
+static int slpc_enable_disable_set(struct drm_device *dev, u64 val,
+  enum slpc_param_id enable_id,
+  enum slpc_param_id disable_id)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   int ret = 0;
+
+   if (!intel_slpc_active(dev_priv)) {
+   ret = -ENODEV;
+   } else if (SLPC_PARAM_TASK_DEFAULT == val) {
+   /* set default */
+   intel_slpc_unset_param(dev_priv, enable_id);
+   intel_slpc_unset_param(dev_priv, disable_id);
+   } else if (SLPC_PARAM_TASK_ENABLED == val) {
+   /* set enable */
+   intel_slpc_set_param(dev_priv, enable_id, 1);
+   intel_slpc_unset_param(dev_priv, disable_id);
+   } else if (SLPC_PARAM_TASK_DISABLED == val) {
+   /* set disable */
+   intel_slpc_set_param(dev_priv, disable_id, 1);
+   intel_slpc_unset_param(dev_priv, enable_id);
+   } else {
+   ret = -EINVAL;
+   }
+
+   return ret;
+}
+
+static void slpc_param_show(struct seq_file *m, enum slpc_param_id enable_id,
+   enum slpc_param_id disable_id)
+{
+   struct drm_device *dev = m->private;
+   const char *status;
+   u64 val;
+   int ret;
+
+   ret = slpc_enable_disable_get(dev, &val, enable_id, disable_id);
+
+   if (ret) {
+   seq_printf(m, "error %d\n", ret);
+   } else {
+   switch (val) {
+   case SLPC_PARAM_TASK_DEFAULT:
+   status = "default\n";
+   break;
+
+   case SLPC_PARAM_TASK_ENABLED:
+   status = "enabled\n";
+   break;
+
+   case SLPC_PARAM_TASK_DISABLED:
+   status = "disabled\n";
+   break;
+
+   default:
+   status = "unknown\n";
+   break;
+   }
+
+   seq_puts(m, status);
+   }
+}
+
+static int slpc_param_write(struct seq_file *m, const char __user *ubuf,
+   size_t len, enum slpc_param_id enable_id,
+   enum slpc_param_id disable_id)
+{
+   struct drm_device *dev = m->private;
+   u64 val;
+   int ret = 0;
+  

[Intel-gfx] drm/i915/slpc: Update current requested frequency

2016-08-19 Thread Sagar Arun Kamble
From: Tom O'Rourke 

When SLPC is controlling requested frequency, the rps.cur_freq
value is not used to make the frequency request.

Before using rps.cur_freq in sysfs or debugfs, read
requested frequency from register to get the value
most recently requested by SLPC firmware.

v2: replace HAS_SLPC with intel_slpc_active (Paulo)
v3: Avoid magic numbers (Nick)
Use a function for repeated code (Jon)

Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 6 ++
 drivers/gpu/drm/i915/i915_drv.h | 5 +
 drivers/gpu/drm/i915/i915_reg.h | 1 +
 drivers/gpu/drm/i915/i915_sysfs.c   | 8 
 4 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 01ae5ee..a99a3f6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1110,6 +1110,9 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
 
intel_runtime_pm_get(dev_priv);
 
+   if (intel_slpc_active(dev_priv))
+   dev_priv->rps.cur_freq = gen9_read_requested_freq(dev_priv);
+
if (IS_GEN5(dev)) {
u16 rgvswctl = I915_READ16(MEMSWCTL);
u16 rgvstat = I915_READ16(MEMSTAT_ILK);
@@ -2372,6 +2375,9 @@ static int i915_rps_boost_info(struct seq_file *m, void 
*data)
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_file *file;
 
+   if (intel_slpc_active(dev_priv))
+   dev_priv->rps.cur_freq = gen9_read_requested_freq(dev_priv);
+
seq_printf(m, "RPS enabled? %d\n", dev_priv->rps.enabled);
seq_printf(m, "GPU busy? %s [%x]\n",
   yesno(dev_priv->gt.awake), dev_priv->gt.active_engines);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 764fad0..fcd2e98 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3913,4 +3913,9 @@ bool i915_memcpy_from_wc(void *dst, const void *src, 
unsigned long len);
__T;\
 })
 
+static inline u8 gen9_read_requested_freq(struct drm_i915_private *dev_priv)
+{
+   return (u8) GEN9_GET_FREQUENCY(I915_READ(GEN6_RPNSWREQ));
+}
+
 #endif
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d4adf28..1654245 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6997,6 +6997,7 @@ enum {
 #define   GEN6_FREQUENCY(x)((x)<<25)
 #define   HSW_FREQUENCY(x) ((x)<<24)
 #define   GEN9_FREQUENCY(x)((x)<<23)
+#define   GEN9_GET_FREQUENCY(x)((x)>>23)
 #define   GEN6_OFFSET(x)   ((x)<<19)
 #define   GEN6_AGGRESSIVE_TURBO(0<<15)
 #define GEN6_RC_VIDEO_FREQ _MMIO(0xA00C)
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index f1ffde7..8404816 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -302,6 +302,14 @@ static ssize_t gt_cur_freq_mhz_show(struct device *kdev,
struct drm_device *dev = minor->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
 
+   if (intel_slpc_active(dev_priv)) {
+   intel_runtime_pm_get(dev_priv);
+   mutex_lock(&dev_priv->rps.hw_lock);
+   dev_priv->rps.cur_freq = gen9_read_requested_freq(dev_priv);
+   mutex_unlock(&dev_priv->rps.hw_lock);
+   intel_runtime_pm_put(dev_priv);
+   }
+
return snprintf(buf, PAGE_SIZE, "%d\n",
intel_gpu_freq(dev_priv,
   dev_priv->rps.cur_freq));
-- 
1.9.1

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


[Intel-gfx] drm/i915/slpc: Use intel_slpc_* functions if supported

2016-08-19 Thread Sagar Arun Kamble
From: Tom O'Rourke 

On platforms with SLPC support: call intel_slpc_*()
functions from corresponding intel_*_gt_powersave()
functions; and do not use rps functions.

v2: return void instead of ignored error code (Paulo)
enable/disable RC6 in SLPC flows (Sagar)
replace HAS_SLPC() use with intel_slpc_enabled()
or intel_slpc_active() (Paulo)
v3: Fix for renaming gen9_disable_rps to gen9_disable_rc6 in
"drm/i915/bxt: Explicitly clear the Turbo control register"

v5: Defer RC6 and SLPC enabling to intel_gen6_powersave_work. (Sagar)
Performance drop with SLPC was happening as ring frequency table
was not programmed when SLPC was enabled. This patch programs ring
frequency table with SLPC. Initial reset of SLPC is based on kernel
parameter as planning to add slpc state in intel_slpc_active. Cleanup
is also based on kernel parameter as SLPC gets disabled in
disable/suspend.(Sagar)

v6: Rebase.

Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/Makefile |  3 +-
 drivers/gpu/drm/i915/intel_drv.h  |  4 ++
 drivers/gpu/drm/i915/intel_guc.h  |  1 +
 drivers/gpu/drm/i915/intel_pm.c   | 98 ++-
 drivers/gpu/drm/i915/intel_slpc.c | 56 ++
 drivers/gpu/drm/i915/intel_slpc.h | 35 ++
 6 files changed, 165 insertions(+), 32 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_slpc.c
 create mode 100644 drivers/gpu/drm/i915/intel_slpc.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 3412413..b768c66 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -51,7 +51,8 @@ i915-y += i915_cmd_parser.o \
 
 # general-purpose microcontroller (GuC) support
 i915-y += intel_guc_loader.o \
- i915_guc_submission.o
+ i915_guc_submission.o \
+ intel_slpc.o
 
 # autogenerated null render state
 i915-y += intel_renderstate_gen6.o \
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1c700b0..16fe13d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1692,6 +1692,10 @@ void chv_phy_powergate_lanes(struct intel_encoder 
*encoder,
 bool chv_phy_powergate_ch(struct drm_i915_private *dev_priv, enum dpio_phy phy,
  enum dpio_channel ch, bool override);
 
+static inline int intel_slpc_active(struct drm_i915_private *dev_priv)
+{
+   return 0;
+}
 
 /* intel_pm.c */
 void intel_init_clock_gating(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 27a7459..cd23c4e 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -27,6 +27,7 @@
 #include "intel_guc_fwif.h"
 #include "i915_guc_reg.h"
 #include "intel_ringbuffer.h"
+#include "intel_slpc.h"
 
 struct drm_i915_gem_request;
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 954e332..7156fb5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4893,7 +4893,8 @@ void gen6_rps_idle(struct drm_i915_private *dev_priv)
 * our rpm wakeref. And then disable the interrupts to stop any
 * futher RPS reclocking whilst we are asleep.
 */
-   gen6_disable_rps_interrupts(dev_priv);
+   if (!intel_slpc_active(dev_priv))
+   gen6_disable_rps_interrupts(dev_priv);
 
mutex_lock(&dev_priv->rps.hw_lock);
if (dev_priv->rps.enabled) {
@@ -6544,6 +6545,9 @@ void intel_init_gt_powersave(struct drm_i915_private 
*dev_priv)
/* Finally allow us to boost to max by default */
dev_priv->rps.boost_freq = dev_priv->rps.max_freq;
 
+   if (intel_slpc_enabled())
+   intel_slpc_init(dev_priv);
+
mutex_unlock(&dev_priv->rps.hw_lock);
mutex_unlock(&dev_priv->drm.struct_mutex);
 
@@ -6552,7 +6556,9 @@ void intel_init_gt_powersave(struct drm_i915_private 
*dev_priv)
 
 void intel_cleanup_gt_powersave(struct drm_i915_private *dev_priv)
 {
-   if (IS_VALLEYVIEW(dev_priv))
+   if (intel_slpc_enabled())
+   intel_slpc_cleanup(dev_priv);
+   else if (IS_VALLEYVIEW(dev_priv))
valleyview_cleanup_gt_powersave(dev_priv);
 
if (!i915.enable_rc6)
@@ -6572,28 +6578,42 @@ void intel_suspend_gt_powersave(struct drm_i915_private 
*dev_priv)
if (INTEL_GEN(dev_priv) < 6)
return;
 
-   if (cancel_delayed_work_sync(&dev_priv->rps.autoenable_work))
+   if (cancel_delayed_work_sync(&dev_priv->rps.autoenable_work)) {
+   if (intel_slpc_active(dev_priv))
+   intel_slpc_suspend(dev_priv);
intel_runtime_pm_put(dev_priv);
+   }
 
/* gen6_rps_idle() will be called later to disable interrupts */
 }
 
 void intel

[Intel-gfx] drm/i915/slpc: Add enable_slpc module parameter

2016-08-19 Thread Sagar Arun Kamble
From: Tom O'Rourke 

i915.enable_slpc is used to override the default for slpc usage.
The expected values are -1=auto, 0=disabled [default], 1=enabled.

slpc_enable_sanitize() converts i915.enable_slpc to either 0 or 1.
Interpretation of default value is based on HAS_SLPC(), after
slpc_version_check().  This function also enforces the requirement
that guc_submission is required for slpc.

intel_slpc_enabled() returns 1 if SLPC should be used.

v2: Add early call to sanitize enable_slpc in intel_guc_ucode_init

v5: Remove sanitize enable_slpc call before firmware version check
is performed. (ChrisW)
Version check is added in next patch and that will be done as
part of slpc_enable_sanitize function in the next patch. (Sagar)
Updated slpc option sanitize function call for platforms without
GuC support. This was caught by CI BAT.

Suggested-by: Paulo Zanoni 
Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_params.c  |  6 ++
 drivers/gpu/drm/i915/i915_params.h  |  1 +
 drivers/gpu/drm/i915/intel_guc.h|  6 ++
 drivers/gpu/drm/i915/intel_guc_loader.c | 30 ++
 4 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 768ad89..72b3097 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -36,6 +36,7 @@ struct i915_params i915 __read_mostly = {
.enable_dc = -1,
.enable_fbc = -1,
.enable_execlists = -1,
+   .enable_slpc = 0,
.enable_hangcheck = true,
.enable_ppgtt = -1,
.enable_psr = -1,
@@ -131,6 +132,11 @@ MODULE_PARM_DESC(enable_execlists,
"Override execlists usage. "
"(-1=auto [default], 0=disabled, 1=enabled)");
 
+module_param_named_unsafe(enable_slpc, i915.enable_slpc, int, 0400);
+MODULE_PARM_DESC(enable_slpc,
+   "Override single-loop-power-controller (slpc) usage. "
+   "(-1=auto, 0=disabled [default], 1=enabled)");
+
 module_param_named_unsafe(enable_psr, i915.enable_psr, int, 0600);
 MODULE_PARM_DESC(enable_psr, "Enable PSR "
 "(0=disabled, 1=enabled - link mode chosen per-platform, 
2=force link-standby mode, 3=force link-off mode) "
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 3a0dd78..391c471 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -39,6 +39,7 @@ struct i915_params {
int enable_fbc;
int enable_ppgtt;
int enable_execlists;
+   int enable_slpc;
int enable_psr;
unsigned int preliminary_hw_support;
int disable_power_well;
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 9e6b948..27a7459 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -146,6 +146,12 @@ struct intel_guc {
uint32_t last_seqno[I915_NUM_ENGINES];
 };
 
+static inline int intel_slpc_enabled(void)
+{
+WARN_ON(i915.enable_slpc < 0);
+return i915.enable_slpc;
+}
+
 /* intel_guc_loader.c */
 extern void intel_guc_init(struct drm_device *dev);
 extern int intel_guc_setup(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 324812d..75b360f 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -144,6 +144,25 @@ static void direct_interrupts_to_guc(struct 
drm_i915_private *dev_priv)
}
 }
 
+static void sanitize_slpc_option(struct drm_device *dev)
+{
+   /* Handle default case */
+   if (i915.enable_slpc < 0)
+   i915.enable_slpc = HAS_SLPC(dev);
+
+   /* slpc requires hardware support and compatible firmware */
+   if (!HAS_SLPC(dev))
+   i915.enable_slpc = 0;
+
+   /* slpc requires guc loaded */
+   if (!i915.enable_guc_loading)
+   i915.enable_slpc = 0;
+
+   /* slpc requires guc submission */
+   if (!i915.enable_guc_submission)
+   i915.enable_slpc = 0;
+}
+
 static u32 get_gttype(struct drm_i915_private *dev_priv)
 {
/* XXX: GT type based on PCI device ID? field seems unused by fw */
@@ -728,18 +747,21 @@ void intel_guc_init(struct drm_device *dev)
guc_fw->guc_fw_fetch_status = GUC_FIRMWARE_NONE;
guc_fw->guc_fw_load_status = GUC_FIRMWARE_NONE;
 
-   /* Early (and silent) return if GuC loading is disabled */
+   /* Return if GuC loading is disabled sanitizing SLPC option */
if (!i915.enable_guc_loading)
-   return;
+   goto out;
if (fw_path == NULL)
-   return;
+   goto out;
if (*fw_path == '\0')
-   return;
+   goto out;
 
guc_fw->guc_fw

[Intel-gfx] drm/i915/slpc: Add slpc_status enum values

2016-08-19 Thread Sagar Arun Kamble
From: Tom O'Rourke 

v2: fix whitespace (Sagar)

Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_slpc.h | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_slpc.h 
b/drivers/gpu/drm/i915/intel_slpc.h
index 031e36b..9fe9ae3 100644
--- a/drivers/gpu/drm/i915/intel_slpc.h
+++ b/drivers/gpu/drm/i915/intel_slpc.h
@@ -28,6 +28,33 @@
 #define SLPC_MINOR_VER 4
 #define SLPC_VERSION ((2015 << 16) | (SLPC_MAJOR_VER << 8) | (SLPC_MINOR_VER))
 
+enum slpc_status {
+   SLPC_STATUS_OK = 0,
+   SLPC_STATUS_ERROR = 1,
+   SLPC_STATUS_ILLEGAL_COMMAND = 2,
+   SLPC_STATUS_INVALID_ARGS = 3,
+   SLPC_STATUS_INVALID_PARAMS = 4,
+   SLPC_STATUS_INVALID_DATA = 5,
+   SLPC_STATUS_OUT_OF_RANGE = 6,
+   SLPC_STATUS_NOT_SUPPORTED = 7,
+   SLPC_STATUS_NOT_IMPLEMENTED = 8,
+   SLPC_STATUS_NO_DATA = 9,
+   SLPC_STATUS_EVENT_NOT_REGISTERED = 10,
+   SLPC_STATUS_REGISTER_LOCKED = 11,
+   SLPC_STATUS_TEMPORARILY_UNAVAILABLE = 12,
+   SLPC_STATUS_VALUE_ALREADY_SET = 13,
+   SLPC_STATUS_VALUE_ALREADY_UNSET = 14,
+   SLPC_STATUS_VALUE_NOT_CHANGED = 15,
+   SLPC_STATUS_MISMATCHING_VERSION = 16,
+   SLPC_STATUS_MEMIO_ERROR = 17,
+   SLPC_STATUS_EVENT_QUEUED_REQ_DPC = 18,
+   SLPC_STATUS_EVENT_QUEUED_NOREQ_DPC = 19,
+   SLPC_STATUS_NO_EVENT_QUEUED = 20,
+   SLPC_STATUS_OUT_OF_SPACE = 21,
+   SLPC_STATUS_TIMEOUT = 22,
+   SLPC_STATUS_NO_LOCK = 23,
+};
+
 enum slpc_event_id {
SLPC_EVENT_RESET = 0,
SLPC_EVENT_SHUTDOWN = 1,
-- 
1.9.1

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


[Intel-gfx] Add support for GuC-based SLPC

2016-08-19 Thread Sagar Arun Kamble
SLPC (Single Loop Power Controller) is a replacement for
some host-based power management features.  The SLPC
implementation runs in firmware on GuC.

This series has been tested with SKL GuC firmware
version 9.18 which is yet to be released. Performance and
power testing with these patches and 9.18 firmware is at
parity and in some cases better than host solution today
on various Linux benchmarks.

The graphics power management features in SLPC in this
version are called GTPERF, BALANCER, and DCC.

GTPERF is a combination of DFPS (Dynamic FPS) and Turbo.
DFPS adjusts requested graphics frequency to maintain
target framerate.  Turbo adjusts requested graphics
frequency to maintain target GT busyness; this includes
an adaptive boost turbo method.

BALANCER adjusts balance between power budgets for IA
and GT in power limited scenarios.  BALANCER is only
active when all display pipes are in "game" mode.

DCC (Duty Cycle Control) adjusts requested graphics
frequency and stalls guc-scheduler to maintain actual
graphics frequency in efficient range.

The last series can be found in the archive at
"[Intel-gfx] [PATCH v4 00/21] Add support for GuC-based SLPC"
https://lists.freedesktop.org/archives/intel-gfx/2016-April/094445.html

This series incorporates feedback from code reviews on earlier series.
It drops the display mode notification patches as it is not needed for
Turbo part of GTPERF. This series also adds new interface changes for
SLPC support on 9.18 GuC Firmware which is not yet published.
Will like to get review started prior to firmware is published.

With SLPC disabled by default, this series should be 
safe to merge now and it can be enabled when 9.18 firmware is released. 

VIZ-6773, VIZ-6889

Cc: Chris Wilson 
Cc: Daniel Vetter 
Cc: Beuchat, Marc 
Cc: Jeff McGee 

Sagar Arun Kamble (7):
  drm/i915: Remove RPM suspend dependency on rps.enabled and related
changes
  drm/i915: Check GuC load status for Host to GuC action and SLPC status
  drm/i915: Mark GuC load status as PENDING in i915_drm_resume_early
  drm/i915/slpc: Only Enable GTPERF, Disable DCC, Balancer, IBC, FPS
Stall
  drm/i915/slpc: Keep RP SW Mode enabled while disabling rps
  drm/i915: Add support for SKL/BXT 9.18 GuC Firmware for SLPC
  drm/i915/slpc: Update freq min/max softlimits

Tom O'Rourke (19):
  drm/i915/slpc: Expose guc functions for use with SLPC
  drm/i915/slpc: Add has_slpc capability flag
  drm/i915/slpc: Add SKL SLPC Support
  drm/i915/slpc: Add enable_slpc module parameter
  drm/i915/slpc: Sanitize SLPC version
  drm/i915/slpc: Use intel_slpc_* functions if supported
  drm/i915/slpc: Enable SLPC in guc if supported
  drm/i915/slpc: If using SLPC, do not set frequency
  drm/i915/slpc: Allocate/Release/Initialize SLPC shared data
  drm/i915/slpc: Update current requested frequency
  drm/i915/slpc: Send reset event
  drm/i915/slpc: Send shutdown event
  drm/i915/slpc: Add slpc_status enum values
  drm/i915/slpc: Add parameter unset/set/get functions
  drm/i915/slpc: Add slpc support for max/min freq
  drm/i915/slpc: Add enable/disable debugfs for slpc
  drm/i915/slpc: Add i915_slpc_info to debugfs
  drm/i915/slpc: Add broxton support
  drm/i915/slpc: Enable SLPC, where supported

 drivers/gpu/drm/i915/Makefile  |   3 +-
 drivers/gpu/drm/i915/i915_debugfs.c| 461 +
 drivers/gpu/drm/i915/i915_drv.c|  17 +-
 drivers/gpu/drm/i915/i915_drv.h|   7 +
 drivers/gpu/drm/i915/i915_guc_submission.c |  21 +-
 drivers/gpu/drm/i915/i915_params.c |   6 +
 drivers/gpu/drm/i915/i915_params.h |   1 +
 drivers/gpu/drm/i915/i915_pci.c|   3 +
 drivers/gpu/drm/i915/i915_reg.h|   1 +
 drivers/gpu/drm/i915/i915_sysfs.c  |  26 ++
 drivers/gpu/drm/i915/intel_drv.h   |  13 +
 drivers/gpu/drm/i915/intel_guc.h   |  10 +
 drivers/gpu/drm/i915/intel_guc_loader.c|  50 +++-
 drivers/gpu/drm/i915/intel_pm.c| 132 ++---
 drivers/gpu/drm/i915/intel_slpc.c  | 370 +++
 drivers/gpu/drm/i915/intel_slpc.h  | 212 +
 16 files changed, 1281 insertions(+), 52 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_slpc.c
 create mode 100644 drivers/gpu/drm/i915/intel_slpc.h

-- 
1.9.1

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


[Intel-gfx] drm/i915: Check GuC load status for Host to GuC action and SLPC status

2016-08-19 Thread Sagar Arun Kamble
Host to GuC actions should not be invoked when GuC isn't loaded hence
add early return in i915_guc_action if GuC load status is not SUCCESS.
Also, SLPC status has to be linked with GuC load status to make sure
SLPC actions get invoked when GuC is loaded.

Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 5 +
 drivers/gpu/drm/i915/intel_drv.h   | 4 
 2 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 680d9b4..27c937b 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -78,6 +78,8 @@ static inline bool host2guc_action_response(struct 
drm_i915_private *dev_priv,
 int i915_guc_action(struct intel_guc *guc, u32 *data, u32 len)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   struct intel_guc_fw *guc_fw = &guc->guc_fw;
+
u32 status;
int i;
int ret;
@@ -85,6 +87,9 @@ int i915_guc_action(struct intel_guc *guc, u32 *data, u32 len)
if (WARN_ON(len < 1 || len > 15))
return -EINVAL;
 
+   if (WARN_ON(guc_fw->guc_fw_load_status != GUC_FIRMWARE_SUCCESS))
+   return -ENODEV;
+
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
 
dev_priv->guc.action_count += 1;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c46d619..71936dc 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1694,8 +1694,12 @@ bool chv_phy_powergate_ch(struct drm_i915_private 
*dev_priv, enum dpio_phy phy,
 
 static inline int intel_slpc_active(struct drm_i915_private *dev_priv)
 {
+   struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw;
int ret = 0;
 
+   if (guc_fw->guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
+   return 0;
+
if (dev_priv->guc.slpc.vma && dev_priv->guc.slpc.enabled)
ret = 1;
 
-- 
1.9.1

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


[Intel-gfx] drm/i915/slpc: Add has_slpc capability flag

2016-08-19 Thread Sagar Arun Kamble
From: Tom O'Rourke 

Add has_slpc capablity flag to indicate GuC firmware
supports single loop power control (SLPC).  SLPC is
a replacement for some host-based power management
features.

v2: fix whitespace (Sagar)

Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_drv.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 35caa9b..764fad0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -646,6 +646,7 @@ struct intel_csr {
func(is_kabylake) sep \
func(is_preliminary) sep \
func(has_fbc) sep \
+   func(has_slpc) sep \
func(has_pipe_cxsr) sep \
func(has_hotplug) sep \
func(cursor_needs_physical) sep \
@@ -2800,6 +2801,7 @@ struct drm_i915_cmd_table {
 #define HAS_GUC(dev)   (IS_GEN9(dev))
 #define HAS_GUC_UCODE(dev) (HAS_GUC(dev))
 #define HAS_GUC_SCHED(dev) (HAS_GUC(dev))
+#define HAS_SLPC(dev)  (INTEL_INFO(dev)->has_slpc)
 
 #define HAS_RESOURCE_STREAMER(dev) (IS_HASWELL(dev) || \
INTEL_INFO(dev)->gen >= 8)
-- 
1.9.1

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


[Intel-gfx] drm/i915/slpc: Sanitize SLPC version

2016-08-19 Thread Sagar Arun Kamble
From: Tom O'Rourke 

The SLPC interface has changed and could continue to
change.  Only GuC versions known to be compatible are
supported here.

On Skylake, GuC firmware v6 is supported.  Other
platforms and versions can be added here later.

v5: Updated with modified sanitize_slpc_option in earlier patch.

Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_guc_loader.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 75b360f..6765edf 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -146,6 +146,9 @@ static void direct_interrupts_to_guc(struct 
drm_i915_private *dev_priv)
 
 static void sanitize_slpc_option(struct drm_device *dev)
 {
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw;
+
/* Handle default case */
if (i915.enable_slpc < 0)
i915.enable_slpc = HAS_SLPC(dev);
@@ -161,6 +164,9 @@ static void sanitize_slpc_option(struct drm_device *dev)
/* slpc requires guc submission */
if (!i915.enable_guc_submission)
i915.enable_slpc = 0;
+
+   if (IS_SKYLAKE(dev_priv) && (guc_fw->guc_fw_major_found != 6))
+   i915.enable_slpc = 0;
 }
 
 static u32 get_gttype(struct drm_i915_private *dev_priv)
-- 
1.9.1

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


[Intel-gfx] drm/i915: Add support for SKL/BXT 9.18 GuC Firmware for SLPC

2016-08-19 Thread Sagar Arun Kamble
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 63 ++--
 drivers/gpu/drm/i915/intel_guc_loader.c | 12 +++---
 drivers/gpu/drm/i915/intel_slpc.c   | 28 -
 drivers/gpu/drm/i915/intel_slpc.h   | 73 ++---
 4 files changed, 103 insertions(+), 73 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0efb3f8..961a125 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1359,10 +1359,10 @@ static int i915_slpc_info(struct seq_file *m, void 
*unused)
struct page *page;
void *pv = NULL;
struct slpc_shared_data data;
+   struct slpc_task_state_data *task_data;
int i, value;
enum slpc_global_state global_state;
enum slpc_platform_sku platform_sku;
-   enum slpc_host_os host_os;
enum slpc_power_plan power_plan;
enum slpc_power_source power_source;
 
@@ -1379,11 +1379,6 @@ static int i915_slpc_info(struct seq_file *m, void 
*unused)
data = *(struct slpc_shared_data *) pv;
kunmap_atomic(pv);
 
-   seq_printf(m, "SLPC Version: %d.%d.%d (0x%8x)\n",
-  data.slpc_version >> 16,
-  (data.slpc_version >> 8) & 0xFF,
-  data.slpc_version & 0xFF,
-  data.slpc_version);
seq_printf(m, "shared data size: %d\n", data.shared_data_size);
 
global_state = (enum slpc_global_state) data.global_state;
@@ -1442,20 +1437,6 @@ static int i915_slpc_info(struct seq_file *m, void 
*unused)
seq_printf(m, "slice count: %d\n",
   data.platform_info.slice_count);
 
-   host_os = (enum slpc_host_os) data.platform_info.host_os;
-   seq_printf(m, "host OS: %d (", host_os);
-   switch (host_os) {
-   case SLPC_HOST_OS_UNDEFINED:
-   seq_puts(m, "undefined)\n");
-   break;
-   case SLPC_HOST_OS_WINDOWS_8:
-   seq_puts(m, "Windows 8)\n");
-   break;
-   default:
-   seq_puts(m, "unknown)\n");
-   break;
-   }
-
seq_printf(m, "power plan/source: 0x%x\n\tplan:\t",
   data.platform_info.power_plan_source);
power_plan = (enum slpc_power_plan) SLPC_POWER_PLAN(
@@ -1502,17 +1483,37 @@ static int i915_slpc_info(struct seq_file *m, void 
*unused)
   data.platform_info.P1_freq * 50,
   data.platform_info.Pe_freq * 50,
   data.platform_info.Pn_freq * 50);
-   seq_printf(m, "RAPL package power 
limits:\n\t0x%08x\n\t0x%08x\n",
-  data.platform_info.package_rapl_limit_high,
-  data.platform_info.package_rapl_limit_low);
-   seq_printf(m, "task state data: 0x%08x\n",
-  data.task_state_data);
-   seq_printf(m, "\tturbo active: %d\n",
-  (data.task_state_data & 1));
-   seq_printf(m, "\tdfps stall possible: %d\n\tgame mode: 
%d\n\tdfps target fps: %d\n",
-  (data.task_state_data & 2),
-  (data.task_state_data & 4),
-  (data.task_state_data >> 3) & 0xFF);
+   task_data = &data.task_state_data;
+   seq_printf(m, "task state data: 0x%08x 0x%08x\n",
+  task_data->bitfield1, task_data->bitfield2);
+
+   seq_printf(m, "\tgtperf task active: %s\n",
+  yesno(task_data->gtperf_task_active));
+   seq_printf(m, "\tgtperf stall possible: %s\n",
+  yesno(task_data->gtperf_stall_possible));
+   seq_printf(m, "\tgtperf gaming mode: %s\n",
+  yesno(task_data->gtperf_gaming_mode));
+   seq_printf(m, "\tgtperf target fps: %d\n",
+  task_data->gtperf_target_fps);
+
+   seq_printf(m, "\tdcc task active: %s\n",
+  yesno(task_data->dcc_task_active));
+   seq_printf(m, "\tin dcc: %s\n",
+  yesno(task_data->in_dcc));
+   seq_printf(m, "\tin dct: %s\n",
+  yesno(task_data->in_dct));
+   seq_printf(m, "\tfreq switch active: %d\n",
+  task_data->freq_switch_active);

[Intel-gfx] drm/i915/slpc: Expose guc functions for use with SLPC

2016-08-19 Thread Sagar Arun Kamble
From: Tom O'Rourke 

Expose host2guc_action for use by SLPC in intel_slpc.c.

Expose functions to allocate and release objects used
by GuC to be used for SLPC shared memory object.

v5: Updated function names as they need to be made extern. (ChrisW)

Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 16 
 drivers/gpu/drm/i915/intel_guc.h   |  2 ++
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index bb40792..680d9b4 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -47,7 +47,7 @@
  * Firmware writes a success/fail code back to the action register after
  * processes the request. The kernel driver polls waiting for this update and
  * then proceeds.
- * See host2guc_action()
+ * See i915_guc_action()
  *
  * Doorbells:
  * Doorbells are interrupts to uKernel. A doorbell is a single cache line (QW)
@@ -75,7 +75,7 @@ static inline bool host2guc_action_response(struct 
drm_i915_private *dev_priv,
return GUC2HOST_IS_RESPONSE(val);
 }
 
-static int host2guc_action(struct intel_guc *guc, u32 *data, u32 len)
+int i915_guc_action(struct intel_guc *guc, u32 *data, u32 len)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
u32 status;
@@ -141,7 +141,7 @@ static int host2guc_allocate_doorbell(struct intel_guc *guc,
data[0] = HOST2GUC_ACTION_ALLOCATE_DOORBELL;
data[1] = client->ctx_index;
 
-   return host2guc_action(guc, data, 2);
+   return i915_guc_action(guc, data, 2);
 }
 
 static int host2guc_release_doorbell(struct intel_guc *guc,
@@ -152,7 +152,7 @@ static int host2guc_release_doorbell(struct intel_guc *guc,
data[0] = HOST2GUC_ACTION_DEALLOCATE_DOORBELL;
data[1] = client->ctx_index;
 
-   return host2guc_action(guc, data, 2);
+   return i915_guc_action(guc, data, 2);
 }
 
 static int host2guc_sample_forcewake(struct intel_guc *guc,
@@ -169,7 +169,7 @@ static int host2guc_sample_forcewake(struct intel_guc *guc,
/* bit 0 and 1 are for Render and Media domain separately */
data[1] = GUC_FORCEWAKE_RENDER | GUC_FORCEWAKE_MEDIA;
 
-   return host2guc_action(guc, data, ARRAY_SIZE(data));
+   return i915_guc_action(guc, data, ARRAY_SIZE(data));
 }
 
 /*
@@ -621,7 +621,7 @@ static void i915_guc_submit(struct drm_i915_gem_request *rq)
  *
  * Return: A i915_vma if successful, otherwise an ERR_PTR.
  */
-static struct i915_vma *guc_allocate_vma(struct intel_guc *guc, u32 size)
+struct i915_vma *guc_allocate_vma(struct intel_guc *guc, u32 size)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
struct drm_i915_gem_object *obj;
@@ -1066,7 +1066,7 @@ int intel_guc_suspend(struct drm_device *dev)
/* first page is shared data with GuC */
data[2] = i915_ggtt_offset(ctx->engine[RCS].state);
 
-   return host2guc_action(guc, data, ARRAY_SIZE(data));
+   return i915_guc_action(guc, data, ARRAY_SIZE(data));
 }
 
 
@@ -1091,5 +1091,5 @@ int intel_guc_resume(struct drm_device *dev)
/* first page is shared data with GuC */
data[2] = i915_ggtt_offset(ctx->engine[RCS].state);
 
-   return host2guc_action(guc, data, ARRAY_SIZE(data));
+   return i915_guc_action(guc, data, ARRAY_SIZE(data));
 }
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index c973262..9e6b948 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -155,9 +155,11 @@ extern int intel_guc_suspend(struct drm_device *dev);
 extern int intel_guc_resume(struct drm_device *dev);
 
 /* i915_guc_submission.c */
+int i915_guc_action(struct intel_guc *guc, u32 *data, u32 len);
 int i915_guc_submission_init(struct drm_i915_private *dev_priv);
 int i915_guc_submission_enable(struct drm_i915_private *dev_priv);
 int i915_guc_wq_check_space(struct drm_i915_gem_request *rq);
+struct i915_vma *guc_allocate_vma(struct intel_guc *guc, u32 size);
 void i915_guc_submission_disable(struct drm_i915_private *dev_priv);
 void i915_guc_submission_fini(struct drm_i915_private *dev_priv);
 
-- 
1.9.1

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


[Intel-gfx] drm/i915/slpc: Update freq min/max softlimits

2016-08-19 Thread Sagar Arun Kamble
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_slpc.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_slpc.c 
b/drivers/gpu/drm/i915/intel_slpc.c
index 26cea21..2bfb30f 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -286,6 +286,10 @@ void intel_slpc_disable(struct drm_i915_private *dev_priv)
 
 void intel_slpc_enable(struct drm_i915_private *dev_priv)
 {
+   struct drm_i915_gem_object *obj;
+   struct page *page;
+   void *pv = NULL;
+   struct slpc_shared_data data;
u64 val;
 
host2guc_slpc_reset(dev_priv);
@@ -330,6 +334,32 @@ void intel_slpc_enable(struct drm_i915_private *dev_priv)
 
SLPC_PARAM_GLOBAL_ENABLE_BALANCER_IN_NON_GAMING_MODE,
 0);
 
+   obj = dev_priv->guc.slpc.vma->obj;
+   if (obj) {
+   intel_slpc_query_task_state(dev_priv);
+
+   page = i915_gem_object_get_page(obj, 0);
+   if (page)
+   pv = kmap_atomic(page);
+   }
+
+   if (pv) {
+   data = *(struct slpc_shared_data *) pv;
+   kunmap_atomic(pv);
+
+   /*
+* TODO: Define separate variables for slice and unslice
+*   frequencies for driver state variable.
+*/
+   dev_priv->rps.max_freq_softlimit =
+   data.task_state_data.freq_unslice_max;
+   dev_priv->rps.min_freq_softlimit =
+   data.task_state_data.freq_unslice_min;
+
+   dev_priv->rps.max_freq_softlimit *= GEN9_FREQ_SCALER;
+   dev_priv->rps.min_freq_softlimit *= GEN9_FREQ_SCALER;
+   }
+
return;
 }
 
-- 
1.9.1

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


[Intel-gfx] drm/i915/slpc: Enable SLPC, where supported

2016-08-19 Thread Sagar Arun Kamble
From: Tom O'Rourke 

This patch makes SLPC enabled by default on
platforms with hardware/firmware support.

v5: Removing warning "enable_slpc < 0" as it is
set to -1 with this patch now. This was caught by CI BAT.

Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_params.c | 4 ++--
 drivers/gpu/drm/i915/intel_guc.h   | 1 -
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 72b3097..7b3b3fd 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -36,7 +36,7 @@ struct i915_params i915 __read_mostly = {
.enable_dc = -1,
.enable_fbc = -1,
.enable_execlists = -1,
-   .enable_slpc = 0,
+   .enable_slpc = -1,
.enable_hangcheck = true,
.enable_ppgtt = -1,
.enable_psr = -1,
@@ -135,7 +135,7 @@ MODULE_PARM_DESC(enable_execlists,
 module_param_named_unsafe(enable_slpc, i915.enable_slpc, int, 0400);
 MODULE_PARM_DESC(enable_slpc,
"Override single-loop-power-controller (slpc) usage. "
-   "(-1=auto, 0=disabled [default], 1=enabled)");
+   "(-1=auto [default], 0=disabled, 1=enabled)");
 
 module_param_named_unsafe(enable_psr, i915.enable_psr, int, 0600);
 MODULE_PARM_DESC(enable_psr, "Enable PSR "
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 4a551f6..b340733 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -151,7 +151,6 @@ struct intel_guc {
 
 static inline int intel_slpc_enabled(void)
 {
-WARN_ON(i915.enable_slpc < 0);
 return i915.enable_slpc;
 }
 
-- 
1.9.1

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


[Intel-gfx] drm/i915/slpc: Allocate/Release/Initialize SLPC shared data

2016-08-19 Thread Sagar Arun Kamble
From: Tom O'Rourke 

SLPC shared data is used to pass information
to/from SLPC in GuC firmware.

For Skylake, platform sku type and slice count
are identified from device id and fuse values.

Support for other platforms needs to be added.

v2: Update for SLPC interface version 2015.2.4
intel_slpc_active() returns 1 if slpc initialized (Paulo)
v3: change default host_os to "Windows"
v4: Spelling fixes (Sagar Kamble and Nick Hoath)
v5: Added WARN for checking if upper 32bits of GTT offset
of shared object are zero. (ChrisW)
Changed function call from gem_allocate/release_guc_obj to
i915_guc_allocate/release_gem_obj. (Sagar)
Updated commit message and moved POWER_PLAN and POWER_SOURCE
definition from later patch. (Akash)
Add struct_mutex locking while allocating/releasing slpc shared
object. This was caught by CI BAT. Adding SLPC state variable
to determine if it is active as it not just dependent on shared
data setup.
Rebase with guc_allocate_vma related changes.

Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_drv.h  |  7 ++-
 drivers/gpu/drm/i915/intel_guc.h  |  2 +
 drivers/gpu/drm/i915/intel_pm.c   |  6 ++-
 drivers/gpu/drm/i915/intel_slpc.c | 90 ++-
 drivers/gpu/drm/i915/intel_slpc.h | 78 +
 5 files changed, 178 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 16fe13d..c46d619 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1694,7 +1694,12 @@ bool chv_phy_powergate_ch(struct drm_i915_private 
*dev_priv, enum dpio_phy phy,
 
 static inline int intel_slpc_active(struct drm_i915_private *dev_priv)
 {
-   return 0;
+   int ret = 0;
+
+   if (dev_priv->guc.slpc.vma && dev_priv->guc.slpc.enabled)
+   ret = 1;
+
+   return ret;
 }
 
 /* intel_pm.c */
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index cd23c4e..4a551f6 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -145,6 +145,8 @@ struct intel_guc {
 
uint64_t submissions[I915_NUM_ENGINES];
uint32_t last_seqno[I915_NUM_ENGINES];
+
+   struct intel_slpc slpc;
 };
 
 static inline int intel_slpc_enabled(void)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3b3f487..6dc33cf 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6559,7 +6559,8 @@ void intel_init_gt_powersave(struct drm_i915_private 
*dev_priv)
 
 void intel_cleanup_gt_powersave(struct drm_i915_private *dev_priv)
 {
-   if (intel_slpc_enabled())
+   if (intel_slpc_enabled() &&
+   dev_priv->guc.slpc.vma)
intel_slpc_cleanup(dev_priv);
else if (IS_VALLEYVIEW(dev_priv))
valleyview_cleanup_gt_powersave(dev_priv);
@@ -6649,7 +6650,8 @@ void intel_enable_gt_powersave(struct drm_i915_private 
*dev_priv)
 
mutex_lock(&dev_priv->rps.hw_lock);
 
-   if (intel_slpc_enabled()) {
+   if (intel_slpc_enabled() &&
+   dev_priv->guc.slpc.vma) {
gen9_enable_rc6(dev_priv);
intel_slpc_enable(dev_priv);
if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
diff --git a/drivers/gpu/drm/i915/intel_slpc.c 
b/drivers/gpu/drm/i915/intel_slpc.c
index b2e8d91..ba5b23a 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -22,17 +22,103 @@
  *
  */
 #include 
+#include 
 #include "i915_drv.h"
 #include "intel_guc.h"
 
+static u8 slpc_get_platform_sku(struct drm_device *dev)
+{
+   enum slpc_platform_sku platform_sku;
+
+   if (IS_SKL_ULX(dev))
+   platform_sku = SLPC_PLATFORM_SKU_ULX;
+   else if (IS_SKL_ULT(dev))
+   platform_sku = SLPC_PLATFORM_SKU_ULT;
+   else
+   platform_sku = SLPC_PLATFORM_SKU_DT;
+
+   return (u8) platform_sku;
+}
+
+static u8 slpc_get_slice_count(struct drm_device *dev)
+{
+   u8 slice_count = 1;
+
+   if (IS_SKYLAKE(dev))
+   slice_count = INTEL_INFO(dev)->slice_total;
+
+   return slice_count;
+}
+
+static void slpc_shared_data_init(struct drm_i915_private *dev_priv)
+{
+   struct drm_i915_gem_object *obj;
+   struct page *page;
+   struct slpc_shared_data *data;
+   u64 msr_value;
+
+   if (!dev_priv->guc.slpc.vma)
+   return;
+
+   obj = dev_priv->guc.slpc.vma->obj;
+
+   page = i915_gem_object_get_page(obj, 0);
+   if (page) {
+   data = kmap_atomic(page);
+   memset(data, 0, sizeof(struct slpc_shared_data));
+
+   data->slpc_version = SLPC_VERSION;
+   data->shared_data_size = sizeof(struct slpc_shared_

[Intel-gfx] drm/i915/slpc: Add broxton support

2016-08-19 Thread Sagar Arun Kamble
From: Tom O'Rourke 

Adds has_slpc to broxton info and adds broxton to
version check. The SLPC interface version 2015.2.4
is found in Broxton Guc v5.

v2-v4: Rebase.

v5: Adjusted slpc version check for major version 8.
Added message if version mismatch happens for easier debug. (Sagar)

Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_pci.c | 1 +
 drivers/gpu/drm/i915/intel_guc_loader.c | 5 -
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index e678051..60a5eb5 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -342,6 +342,7 @@ static const struct intel_device_info intel_broxton_info = {
.has_ddi = 1,
.has_fpga_dbg = 1,
.has_fbc = 1,
+   .has_slpc = 1,
.has_pooled_eu = 0,
GEN_DEFAULT_PIPEOFFSETS,
IVB_CURSOR_OFFSETS,
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 2edd255..a4ab8f9 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -165,8 +165,11 @@ static void sanitize_slpc_option(struct drm_device *dev)
if (!i915.enable_guc_submission)
i915.enable_slpc = 0;
 
-   if (IS_SKYLAKE(dev_priv) && (guc_fw->guc_fw_major_found != 6))
+   if ((IS_SKYLAKE(dev_priv) && (guc_fw->guc_fw_major_found != 6))
+|| (IS_BROXTON(dev_priv) && (guc_fw->guc_fw_major_found != 8))) {
+   DRM_INFO("SLPC not supported with current GuC firmware\n");
i915.enable_slpc = 0;
+   }
 }
 
 static u32 get_gttype(struct drm_i915_private *dev_priv)
-- 
1.9.1

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


[Intel-gfx] drm/i915/slpc: Send reset event

2016-08-19 Thread Sagar Arun Kamble
From: Tom O'Rourke 

Add host2guc SLPC reset event and send reset event
during enable.

v2: extract host2guc_slpc to handle slpc status code
coding style changes (Paulo)

v5: Removed WARN_ON for checking msb of gtt address of
shared gem obj. (ChrisW)
host2guc_action to i915_guc_action change.(Sagar)
Updating SLPC enabled status. (Sagar)

Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_slpc.c | 29 +
 drivers/gpu/drm/i915/intel_slpc.h | 14 ++
 2 files changed, 43 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_slpc.c 
b/drivers/gpu/drm/i915/intel_slpc.c
index ba5b23a..161cd13 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -26,6 +26,32 @@
 #include "i915_drv.h"
 #include "intel_guc.h"
 
+static void host2guc_slpc(struct drm_i915_private *dev_priv, u32 *data, u32 
len)
+{
+   int ret = i915_guc_action(&dev_priv->guc, data, len);
+
+   if (!ret) {
+   ret = I915_READ(SOFT_SCRATCH(1));
+   ret &= SLPC_EVENT_STATUS_MASK;
+   }
+
+   if (ret)
+   DRM_ERROR("event 0x%x status %d\n", (data[1] >> 8), ret);
+}
+
+static void host2guc_slpc_reset(struct drm_i915_private *dev_priv)
+{
+   u32 data[4];
+   u32 shared_data_gtt_offset = i915_ggtt_offset(dev_priv->guc.slpc.vma);
+
+   data[0] = HOST2GUC_ACTION_SLPC_REQUEST;
+   data[1] = SLPC_EVENT(SLPC_EVENT_RESET, 2);
+   data[2] = shared_data_gtt_offset;
+   data[3] = 0;
+
+   host2guc_slpc(dev_priv, data, 4);
+}
+
 static u8 slpc_get_platform_sku(struct drm_device *dev)
 {
enum slpc_platform_sku platform_sku;
@@ -133,6 +159,9 @@ void intel_slpc_disable(struct drm_i915_private *dev_priv)
 
 void intel_slpc_enable(struct drm_i915_private *dev_priv)
 {
+   host2guc_slpc_reset(dev_priv);
+   dev_priv->guc.slpc.enabled = true;
+
return;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_slpc.h 
b/drivers/gpu/drm/i915/intel_slpc.h
index e951289..031e36b 100644
--- a/drivers/gpu/drm/i915/intel_slpc.h
+++ b/drivers/gpu/drm/i915/intel_slpc.h
@@ -28,6 +28,20 @@
 #define SLPC_MINOR_VER 4
 #define SLPC_VERSION ((2015 << 16) | (SLPC_MAJOR_VER << 8) | (SLPC_MINOR_VER))
 
+enum slpc_event_id {
+   SLPC_EVENT_RESET = 0,
+   SLPC_EVENT_SHUTDOWN = 1,
+   SLPC_EVENT_PLATFORM_INFO_CHANGE = 2,
+   SLPC_EVENT_DISPLAY_MODE_CHANGE = 3,
+   SLPC_EVENT_FLIP_COMPLETE = 4,
+   SLPC_EVENT_QUERY_TASK_STATE = 5,
+   SLPC_EVENT_PARAMETER_SET = 6,
+   SLPC_EVENT_PARAMETER_UNSET = 7,
+};
+
+#define SLPC_EVENT(id, argc) ((u32) (id) << 8 | (argc))
+#define SLPC_EVENT_STATUS_MASK 0xFF
+
 enum slpc_global_state {
SLPC_GLOBAL_STATE_NOT_RUNNING = 0,
SLPC_GLOBAL_STATE_INITIALIZING = 1,
-- 
1.9.1

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


[Intel-gfx] drm/i915/slpc: Add SKL SLPC Support

2016-08-19 Thread Sagar Arun Kamble
From: Tom O'Rourke 

This patch adds has_slpc to skylake info.

The SLPC interface has changed and could continue to
change.  Only GuC versions known to be compatible are
supported here.

On Skylake, GuC firmware v6 is supported.  Other
platforms and versions can be added here later.

v2: Move slpc_version_check to intel_guc_ucode_init
v3: fix whitespace (Sagar)
v5: Moved version check to different patch as has_slpc
should not be updated based on it. Instead module paramter
should be updated based on version check. (Sagar)
Added support to skylake_gt3 as well. (Sagar)

Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_pci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 2587b1b..e678051 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -322,12 +322,14 @@ static const struct intel_device_info intel_skylake_info 
= {
BDW_FEATURES,
.is_skylake = 1,
.gen = 9,
+   .has_slpc = 1,
 };
 
 static const struct intel_device_info intel_skylake_gt3_info = {
BDW_FEATURES,
.is_skylake = 1,
.gen = 9,
+   .has_slpc = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
 };
 
-- 
1.9.1

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


[Intel-gfx] drm/i915: Mark GuC load status as PENDING in i915_drm_resume_early

2016-08-19 Thread Sagar Arun Kamble
This will help avoid Host to GuC actions being called till GuC gets
loaded during i915_drm_resume.

Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_drv.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index bc2c67b..b6921c1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1629,6 +1629,7 @@ static int i915_drm_resume(struct drm_device *dev)
 static int i915_drm_resume_early(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
+   struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw;
int ret;
 
/*
@@ -1685,6 +1686,12 @@ static int i915_drm_resume_early(struct drm_device *dev)
DRM_ERROR("Resume prepare failed: %d, continuing anyway\n",
  ret);
 
+   /*
+* Mark GuC FW load status as PENDING to avoid any Host to GuC actions
+* invoked till GuC gets loaded in i915_drm_resume.
+   */
+   guc_fw->guc_fw_load_status = GUC_FIRMWARE_PENDING;
+
intel_uncore_early_sanitize(dev_priv, true);
 
if (IS_BROXTON(dev_priv)) {
-- 
1.9.1

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


[Intel-gfx] drm/i915/slpc: Add parameter unset/set/get functions

2016-08-19 Thread Sagar Arun Kamble
From: Tom O'Rourke 

Add slpc_param_id enum values.
Add events for setting/unsetting parameters.

v2: use host2guc_slpc
update slcp_param_id enum values for SLPC 2015.2.4
return void instead of ignored error code (Paulo)

Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_slpc.c | 99 +++
 drivers/gpu/drm/i915/intel_slpc.h | 26 +-
 2 files changed, 124 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_slpc.c 
b/drivers/gpu/drm/i915/intel_slpc.c
index 5a1e6f2..120bdab 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -65,6 +65,105 @@ static void host2guc_slpc_shutdown(struct drm_i915_private 
*dev_priv)
host2guc_slpc(dev_priv, data, 4);
 }
 
+static void host2guc_slpc_set_param(struct drm_i915_private *dev_priv,
+   enum slpc_param_id id, u32 value)
+{
+   u32 data[4];
+
+   data[0] = HOST2GUC_ACTION_SLPC_REQUEST;
+   data[1] = SLPC_EVENT(SLPC_EVENT_PARAMETER_SET, 2);
+   data[2] = (u32) id;
+   data[3] = value;
+
+   host2guc_slpc(dev_priv, data, 4);
+}
+
+static void host2guc_slpc_unset_param(struct drm_i915_private *dev_priv,
+ enum slpc_param_id id)
+{
+   u32 data[3];
+
+   data[0] = HOST2GUC_ACTION_SLPC_REQUEST;
+   data[1] = SLPC_EVENT(SLPC_EVENT_PARAMETER_UNSET, 1);
+   data[2] = (u32) id;
+
+   host2guc_slpc(dev_priv, data, 3);
+}
+
+void intel_slpc_unset_param(struct drm_i915_private *dev_priv, enum 
slpc_param_id id)
+{
+   struct drm_i915_gem_object *obj;
+   struct page *page;
+   struct slpc_shared_data *data = NULL;
+
+   obj = dev_priv->guc.slpc.vma->obj;
+   if (obj) {
+   page = i915_gem_object_get_page(obj, 0);
+   if (page)
+   data = kmap_atomic(page);
+   }
+
+   if (data) {
+   data->override_parameters_set_bits[id >> 5]
+   &= (~(1 << (id % 32)));
+   data->override_parameters_values[id] = 0;
+   kunmap_atomic(data);
+
+   host2guc_slpc_unset_param(dev_priv, id);
+   }
+}
+
+void intel_slpc_set_param(struct drm_i915_private *dev_priv, enum 
slpc_param_id id,
+ u32 value)
+{
+   struct drm_i915_gem_object *obj;
+   struct page *page;
+   struct slpc_shared_data *data = NULL;
+
+   obj = dev_priv->guc.slpc.vma->obj;
+   if (obj) {
+   page = i915_gem_object_get_page(obj, 0);
+   if (page)
+   data = kmap_atomic(page);
+   }
+
+   if (data) {
+   data->override_parameters_set_bits[id >> 5]
+   |= (1 << (id % 32));
+   data->override_parameters_values[id] = value;
+   kunmap_atomic(data);
+
+   host2guc_slpc_set_param(dev_priv, id, value);
+   }
+}
+
+void intel_slpc_get_param(struct drm_i915_private *dev_priv, enum 
slpc_param_id id,
+ int *overriding, u32 *value)
+{
+   struct drm_i915_gem_object *obj;
+   struct page *page;
+   struct slpc_shared_data *data = NULL;
+   u32 bits;
+
+   obj = dev_priv->guc.slpc.vma->obj;
+   if (obj) {
+   page = i915_gem_object_get_page(obj, 0);
+   if (page)
+   data = kmap_atomic(page);
+   }
+
+   if (data) {
+   if (overriding) {
+   bits = data->override_parameters_set_bits[id >> 5];
+   *overriding = (0 != (bits & (1 << (id % 32;
+   }
+   if (value)
+   *value = data->override_parameters_values[id];
+
+   kunmap_atomic(data);
+   }
+}
+
 static u8 slpc_get_platform_sku(struct drm_device *dev)
 {
enum slpc_platform_sku platform_sku;
diff --git a/drivers/gpu/drm/i915/intel_slpc.h 
b/drivers/gpu/drm/i915/intel_slpc.h
index 9fe9ae3..040c240 100644
--- a/drivers/gpu/drm/i915/intel_slpc.h
+++ b/drivers/gpu/drm/i915/intel_slpc.h
@@ -69,6 +69,26 @@ enum slpc_event_id {
 #define SLPC_EVENT(id, argc) ((u32) (id) << 8 | (argc))
 #define SLPC_EVENT_STATUS_MASK 0xFF
 
+enum slpc_param_id {
+   SLPC_PARAM_TASK_ENABLE_GTPERF = 0,
+   SLPC_PARAM_TASK_DISABLE_GTPERF = 1,
+   SLPC_PARAM_TASK_ENABLE_BALANCER = 2,
+   SLPC_PARAM_TASK_DISABLE_BALANCER = 3,
+   SLPC_PARAM_TASK_ENABLE_DCC = 4,
+   SLPC_PARAM_TASK_DISABLE_DCC = 5,
+   SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ = 6,
+   SLPC_PARAM_GLOBAL_MAX_GT_UNSLICE_FREQ_MHZ = 7,
+   SLPC_PARAM_GLOBAL_MIN_GT_SLICE_FREQ_MHZ = 8,
+   SLPC_PARAM_GLOBAL_MAX_GT_SLICE_FREQ_MHZ = 9,
+   S

[Intel-gfx] drm/i915/slpc: Add slpc support for max/min freq

2016-08-19 Thread Sagar Arun Kamble
From: Tom O'Rourke 

Update sysfs and debugfs functions to set SLPC
parameters when setting max/min frequency.

v2: Update for SLPC 2015.2.4 (params for both slice and unslice)
Replace HAS_SLPC with intel_slpc_active() (Paulo)

Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 18 ++
 drivers/gpu/drm/i915/i915_sysfs.c   | 18 ++
 2 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index a99a3f6..fb497ea1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4959,6 +4959,15 @@ i915_max_freq_set(void *data, u64 val)
 
dev_priv->rps.max_freq_softlimit = val;
 
+   if (intel_slpc_active(dev_priv)) {
+   intel_slpc_set_param(dev_priv,
+SLPC_PARAM_GLOBAL_MAX_GT_UNSLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));
+   intel_slpc_set_param(dev_priv,
+SLPC_PARAM_GLOBAL_MAX_GT_SLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));
+   }
+
intel_set_rps(dev_priv, val);
 
mutex_unlock(&dev_priv->rps.hw_lock);
@@ -5015,6 +5024,15 @@ i915_min_freq_set(void *data, u64 val)
 
dev_priv->rps.min_freq_softlimit = val;
 
+   if (intel_slpc_active(dev_priv)) {
+   intel_slpc_set_param(dev_priv,
+SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));
+   intel_slpc_set_param(dev_priv,
+SLPC_PARAM_GLOBAL_MIN_GT_SLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));
+   }
+
intel_set_rps(dev_priv, val);
 
mutex_unlock(&dev_priv->rps.hw_lock);
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index 8404816..57f9ada 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -408,6 +408,15 @@ static ssize_t gt_max_freq_mhz_store(struct device *kdev,
 
dev_priv->rps.max_freq_softlimit = val;
 
+   if (intel_slpc_active(dev_priv)) {
+   intel_slpc_set_param(dev_priv,
+SLPC_PARAM_GLOBAL_MAX_GT_UNSLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));
+   intel_slpc_set_param(dev_priv,
+SLPC_PARAM_GLOBAL_MAX_GT_SLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));
+   }
+
val = clamp_t(int, dev_priv->rps.cur_freq,
  dev_priv->rps.min_freq_softlimit,
  dev_priv->rps.max_freq_softlimit);
@@ -465,6 +474,15 @@ static ssize_t gt_min_freq_mhz_store(struct device *kdev,
 
dev_priv->rps.min_freq_softlimit = val;
 
+   if (intel_slpc_active(dev_priv)) {
+   intel_slpc_set_param(dev_priv,
+SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));
+   intel_slpc_set_param(dev_priv,
+SLPC_PARAM_GLOBAL_MIN_GT_SLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));
+   }
+
val = clamp_t(int, dev_priv->rps.cur_freq,
  dev_priv->rps.min_freq_softlimit,
  dev_priv->rps.max_freq_softlimit);
-- 
1.9.1

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


[Intel-gfx] drm/i915/slpc: Only Enable GTPERF, Disable DCC, Balancer, IBC, FPS Stall

2016-08-19 Thread Sagar Arun Kamble
v2: Updated tasks and frequency post reset.
v3: Added DFPS param update for MAX_FPS and FPS Stall.

Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  2 +-
 drivers/gpu/drm/i915/intel_slpc.c   | 29 +
 drivers/gpu/drm/i915/intel_slpc.h   |  5 +
 3 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index cfe6dac..0efb3f8 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1140,7 +1140,7 @@ static int slpc_enable_disable_get(struct drm_device 
*dev, u64 *val,
return ret;
 }
 
-static int slpc_enable_disable_set(struct drm_device *dev, u64 val,
+int slpc_enable_disable_set(struct drm_device *dev, u64 val,
   enum slpc_param_id enable_id,
   enum slpc_param_id disable_id)
 {
diff --git a/drivers/gpu/drm/i915/intel_slpc.c 
b/drivers/gpu/drm/i915/intel_slpc.c
index bf0840a..4356dfa 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -292,9 +292,38 @@ void intel_slpc_disable(struct drm_i915_private *dev_priv)
 
 void intel_slpc_enable(struct drm_i915_private *dev_priv)
 {
+   u64 val;
+
host2guc_slpc_reset(dev_priv);
dev_priv->guc.slpc.enabled = true;
 
+   /* Enable only GTPERF task, Disable others */
+   val = SLPC_PARAM_TASK_ENABLED;
+   slpc_enable_disable_set(&dev_priv->drm, val,
+   SLPC_PARAM_TASK_ENABLE_GTPERF,
+   SLPC_PARAM_TASK_DISABLE_GTPERF);
+
+   val = SLPC_PARAM_TASK_DISABLED;
+   slpc_enable_disable_set(&dev_priv->drm, val,
+   SLPC_PARAM_TASK_ENABLE_BALANCER,
+   SLPC_PARAM_TASK_DISABLE_BALANCER);
+
+   slpc_enable_disable_set(&dev_priv->drm, val,
+   SLPC_PARAM_TASK_ENABLE_DCC,
+   SLPC_PARAM_TASK_DISABLE_DCC);
+
+   intel_slpc_set_param(dev_priv,
+SLPC_PARAM_GLOBAL_DISABLE_IA_GT_BALANCING,
+1);
+
+   intel_slpc_set_param(dev_priv,
+SLPC_PARAM_DFPS_THRESHOLD_MAX_FPS,
+0);
+
+   intel_slpc_set_param(dev_priv,
+SLPC_PARAM_DFPS_DISABLE_FRAMERATE_STALLING,
+1);
+
return;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_slpc.h 
b/drivers/gpu/drm/i915/intel_slpc.h
index 3d2e4ce..a1e573e 100644
--- a/drivers/gpu/drm/i915/intel_slpc.h
+++ b/drivers/gpu/drm/i915/intel_slpc.h
@@ -181,4 +181,9 @@ void intel_slpc_set_param(struct drm_i915_private 
*dev_priv, enum slpc_param_id
 void intel_slpc_get_param(struct drm_i915_private *dev_priv, enum 
slpc_param_id id,
  int *overriding, u32 *value);
 void intel_slpc_query_task_state(struct drm_i915_private *dev_priv);
+
+/* i915_debugfs.c */
+int slpc_enable_disable_set(struct drm_device *dev, u64 val,
+   enum slpc_param_id enable_id,
+   enum slpc_param_id disable_id);
 #endif
-- 
1.9.1

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


  1   2   3   4   5   6   7   8   9   10   >