Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/10] drm/i915/guc: Create intel_guc.c for defining GuC specific functionality (rev2)

[Kamble, Sagar A]

Kindly ignore this failure and series. This was old series and due to replying 
a patch to it, BAT faced issue.

-Original Message-
From: Patchwork [mailto:patchw...@emeril.freedesktop.org] 
Sent: Friday, September 22, 2017 4:30 PM
To: Kamble, Sagar A <sagar.a.kam...@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.BAT: failure for series starting with [01/10] drm/i915/guc: 
Create intel_guc.c for defining GuC specific functionality (rev2)

== Series Details ==

Series: series starting with [01/10] drm/i915/guc: Create intel_guc.c for 
defining GuC specific functionality (rev2)
URL   : https://patchwork.freedesktop.org/series/30486/
State : failure

== Summary ==

  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CHK include/generated/bounds.h
  CHK include/generated/timeconst.h
  CHK include/generated/asm-offsets.h
  CALLscripts/checksyscalls.sh
  CHK scripts/mod/devicetable-offsets.h
  CHK include/generated/compile.h
  CHK kernel/config_data.h
  CC [M]  drivers/gpu/drm/i915/intel_uc.o
drivers/gpu/drm/i915/intel_uc.c: In function ‘intel_uc_system_suspend’:
drivers/gpu/drm/i915/intel_uc.c:441:1: error: version control conflict marker 
in file  <<<<<<< HEAD  ^~~
drivers/gpu/drm/i915/intel_uc.c:444:1: error: version control conflict marker 
in file  ===  ^~~
drivers/gpu/drm/i915/intel_uc.c:452:1: error: version control conflict marker 
in file  >>>>>>> drm/i915/guc: Update GuC suspend functionality in 
intel_uc_suspend path  ^~~
scripts/Makefile.build:311: recipe for target 'drivers/gpu/drm/i915/intel_uc.o' 
failed
make[4]: *** [drivers/gpu/drm/i915/intel_uc.o] Error 1
scripts/Makefile.build:570: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:570: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:570: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1019: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for GuC Fixes, Minor restructuring changes and v9+ logging change

[Kamble, Sagar A]

Test kms_flip:
Subgroup modeset-vs-vblank-race:
pass   -> FAIL   (shard-hsw)

https://bugs.freedesktop.org/show_bug.cgi?id=102917


-Original Message-
From: Patchwork [mailto:patchw...@emeril.freedesktop.org] 
Sent: Thursday, September 21, 2017 2:25 AM
To: Kamble, Sagar A <sagar.a.kam...@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.IGT: failure for GuC Fixes, Minor restructuring changes and 
v9+ logging change

== Series Details ==

Series: GuC Fixes, Minor restructuring changes and v9+ logging change
URL   : https://patchwork.freedesktop.org/series/30666/
State : failure

== Summary ==

Test kms_flip:
Subgroup modeset-vs-vblank-race:
pass   -> FAIL   (shard-hsw)
Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252 +1

fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-hswtotal:2317 pass:1247 dwarn:2   dfail:0   fail:11  skip:1057 
time:9646s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5770/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/14] drm/i915/guc: Pass intel_guc struct as parameter to intel_guc_wopcm_size

[Kamble, Sagar A]

On 9/20/2017 1:47 AM, Michal Wajdeczko wrote:
On Tue, 19 Sep 2017 19:27:38 +0200, Sagar Arun Kamble 
 wrote:



Pass intel_guc struct as parameter to intel_guc_wopcm_size instead of
drm_i915_private. intel_guc_suspend/resume parameters are not updated in
this patch as those functions are updated in the upcoming patches.



hmm, missing answer to the "why" question.
To maintain the symmetry with other intel_guc* functions defined in 
intel_guc_loader.c I changed this even though this only accesses dev_priv.
Also thought in future some member in intel_guc will have info about 
wopcm size. But currently since it only depends on dev_priv I think
it makes more sense to move this as inline into intel_uc.c as you said 
below.



Cc: Michal Wajdeczko 
Cc: Michał Winiarski 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_guc_loader.c | 3 ++-
 drivers/gpu/drm/i915/intel_uc.c | 4 ++--
 drivers/gpu/drm/i915/intel_uc.h | 2 +-
 3 files changed, 5 insertions(+), 4 deletions(-)

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

index 8b0ae7f..6ee7c16 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -250,8 +250,9 @@ static int guc_ucode_xfer_dma(struct 
drm_i915_private *dev_priv,

 return ret;
 }
-u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv)
+u32 intel_guc_wopcm_size(struct intel_guc *guc)


Maybe better option would be to convert this function into inline
as it is used only in uc.c file.

Michal


 {
+struct drm_i915_private *dev_priv = guc_to_i915(guc);
 u32 wopcm_size = GUC_WOPCM_TOP;
/* On BXT, the top of WOPCM is reserved for RC6 context */
diff --git a/drivers/gpu/drm/i915/intel_uc.c 
b/drivers/gpu/drm/i915/intel_uc.c

index 0178ba4..b91f848 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -188,7 +188,7 @@ static void fetch_uc_fw(struct drm_i915_private 
*dev_priv,

 size = uc_fw->header_size + uc_fw->ucode_size;
/* Top 32k of WOPCM is reserved (8K stack + 24k RC6 context). */
-if (size > intel_guc_wopcm_size(dev_priv)) {
+if (size > intel_guc_wopcm_size(_priv->guc)) {
 DRM_ERROR("Firmware is too large to fit in WOPCM\n");
 goto fail;
 }
@@ -353,7 +353,7 @@ int intel_uc_init_hw(struct drm_i915_private 
*dev_priv)

 }
/* init WOPCM */
-I915_WRITE(GUC_WOPCM_SIZE, intel_guc_wopcm_size(dev_priv));
+I915_WRITE(GUC_WOPCM_SIZE, intel_guc_wopcm_size(guc));
 I915_WRITE(DMA_GUC_WOPCM_OFFSET,
GUC_WOPCM_OFFSET_VALUE | HUC_LOADING_AGENT_GUC);
diff --git a/drivers/gpu/drm/i915/intel_uc.h 
b/drivers/gpu/drm/i915/intel_uc.h

index 7703c9a..8560a7e 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -227,7 +227,7 @@ static inline void intel_guc_notify(struct 
intel_guc *guc)

 int intel_guc_init_hw(struct intel_guc *guc);
 int intel_guc_suspend(struct drm_i915_private *dev_priv);
 int intel_guc_resume(struct drm_i915_private *dev_priv);
-u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv);
+u32 intel_guc_wopcm_size(struct intel_guc *guc);
/* i915_guc_submission.c */
 int i915_guc_submission_init(struct drm_i915_private *dev_priv);


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

Re: [Intel-gfx] [PATCH 02/14] drm/i915: Create intel_uc_init_mmio to initialize MMIO interface prior to uc init

[Kamble, Sagar A]

On 9/20/2017 1:58 AM, Michal Wajdeczko wrote:
On Tue, 19 Sep 2017 19:27:39 +0200, Sagar Arun Kamble 
 wrote:



This patch adds new function intel_uc_init_mmio which will initialize
MMIO access related variables prior to uc load/init.

v2: Removed unnecessary export of guc_send_init_regs. Created
intel_uc_init_mmio that currently wraps guc_init_send_regs. (Michal)

Cc: Michal Wajdeczko 
Cc: Michał Winiarski 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_drv.c | 2 ++
 drivers/gpu/drm/i915/intel_uc.c | 7 +--
 drivers/gpu/drm/i915/intel_uc.h | 1 +
 3 files changed, 8 insertions(+), 2 deletions(-)

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

index 5c111ea..ef4f84d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1002,6 +1002,8 @@ static int i915_driver_init_mmio(struct 
drm_i915_private *dev_priv)

intel_uncore_init(dev_priv);
+intel_uc_init_mmio(dev_priv);
+
 ret = intel_engines_init_mmio(dev_priv);
 if (ret)
 goto err_uncore;
diff --git a/drivers/gpu/drm/i915/intel_uc.c 
b/drivers/gpu/drm/i915/intel_uc.c

index b91f848..f2ccb7c 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -288,6 +288,11 @@ static void guc_init_send_regs(struct intel_guc 
*guc)

 guc->send_regs.fw_domains = fw_domains;
 }
+void intel_uc_init_mmio(struct drm_i915_private *dev_priv)
+{
+guc_init_send_regs(_priv->guc);
+}
+
 static void guc_capture_load_err_log(struct intel_guc *guc)
 {
 if (!guc->log.vma || i915.guc_log_level < 0)
@@ -309,8 +314,6 @@ static int guc_enable_communication(struct 
intel_guc *guc)

 {
 struct drm_i915_private *dev_priv = guc_to_i915(guc);
-guc_init_send_regs(guc);
-
 if (HAS_GUC_CT(dev_priv))
 return intel_guc_enable_ct(guc);
diff --git a/drivers/gpu/drm/i915/intel_uc.h 
b/drivers/gpu/drm/i915/intel_uc.h

index 8560a7e..60bf814 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -206,6 +206,7 @@ struct intel_huc {
 void intel_uc_init_early(struct drm_i915_private *dev_priv);
 void intel_uc_init_fw(struct drm_i915_private *dev_priv);
 void intel_uc_fini_fw(struct drm_i915_private *dev_priv);
+void intel_uc_init_mmio(struct drm_i915_private *dev_priv);


As init_mmio() is called prior to init_fw() please try to keep
the same order in their declarations.

Michal

Ok. Will update this.



 int intel_uc_init_hw(struct drm_i915_private *dev_priv);
 void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
 int intel_guc_sample_forcewake(struct intel_guc *guc);


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

Re: [Intel-gfx] [PATCH 00/14] GuC code restructuring and fixes

[Kamble, Sagar A]

On 9/20/2017 1:45 AM, Michal Wajdeczko wrote:
On Tue, 19 Sep 2017 19:27:37 +0200, Sagar Arun Kamble 
 wrote:


This series is based on reviews from 
https://patchwork.freedesktop.org/series/30502/.


Cc: Michal Wajdeczko 
Cc: Michał Winiarski 

Sagar Arun Kamble (14):
  drm/i915/guc: Pass intel_guc struct as parameter to
intel_guc_wopcm_size
  drm/i915: Create intel_uc_init_mmio to initialize MMIO interface prior
to uc init
  drm/i915/guc: Create intel_guc_init_early
  drm/i915: Create intel_guc.h, intel_huc.h and intel_uc_common.h
  drm/i915/guc: Move GuC specific functionality from intel_uc.c to
intel_guc.c
  drm/i915: Create uc runtime and system suspend/resume helpers
  drm/i915/guc: Update prototype/name of GuC suspend/resume fns and move
to intel_guc.c
  drm/i915/guc: Update GuC ggtt.invalidate/interrupts/communication
across RPM suspend/resume
  drm/i915/guc: Update suspend functionality in intel_uc_suspend path
  drm/i915/guc: Reuse GuC suspend functionality in reset path
  drm/i915/guc: Fix GuC cleanup in unload path
  drm/i915/guc: Remove i915_guc_log_unregister
  drm/i915/guc: Enable default/critical logging in GuC by default from
GuC v9
  drm/i915: Reorganize HuC authentication



Refactoring whole guc code in one series can be very long task.
By adding more and more fixes here you're preventing merge of the
most important patch.

Michal

Will float the fixes first now and then will restart the restructuring.
Current patches are smaller logical changes w.r.t restructuring compared 
to my earlier series so I thought

it would be nice to get those in along with the fixes. Thanks Michal.

 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/i915_drv.c|  28 +++-
 drivers/gpu/drm/i915/i915_gem.c|   9 +-
 drivers/gpu/drm/i915/i915_guc_submission.c |  54 +--
 drivers/gpu/drm/i915/intel_guc.c   | 246 
+

 drivers/gpu/drm/i915/intel_guc.h   | 185 ++
 drivers/gpu/drm/i915/intel_guc_fwif.h  |   4 +-
 drivers/gpu/drm/i915/intel_guc_loader.c|   3 +-
 drivers/gpu/drm/i915/intel_guc_log.c   |  25 ++-
 drivers/gpu/drm/i915/intel_huc.c   |  22 +--
 drivers/gpu/drm/i915/intel_huc.h   |  41 +
 drivers/gpu/drm/i915/intel_uc.c| 165 ++-
 drivers/gpu/drm/i915/intel_uc.h| 205 
++--

 drivers/gpu/drm/i915/intel_uc_common.h |  67 
 14 files changed, 653 insertions(+), 402 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_guc.c
 create mode 100644 drivers/gpu/drm/i915/intel_guc.h
 create mode 100644 drivers/gpu/drm/i915/intel_huc.h
 create mode 100644 drivers/gpu/drm/i915/intel_uc_common.h


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

Re: [Intel-gfx] [PATCH 00/20] Add support for GuC-based SLPC

[Kamble, Sagar A]

On 9/19/2017 4:00 PM, Joonas Lahtinen wrote:

On Tue, 2017-09-12 at 08:39 +, Szwichtenberg, Radoslaw wrote:

On Fri, 2017-09-01 at 12:55 +0530, Sagar Arun Kamble wrote:

SLPC (Single Loop Power Controller) is a replacement for some host-based
power management features. The SLPC implementation runs in GuC firmware.
This series has been tested with SKL/APL/KBL GuC firmware v9 and v10
which are yet to be released on 01.org.

The graphics power management features in SLPC are called GTPERF,
BALANCER, and DCC.
1. 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.
2. BALANCER adjusts balance between power budgets for IA and GT in power
limited scenarios.
3. DCC (Duty Cycle Control) adjusts requested graphics frequency and stalls
guc-scheduler to maintain actual graphics frequency in efficient range.

This series activates GTPERF Turbo and BALANCER in GuC SLPC.
Patch to enable SLPC by default on platforms having support is removed
from this series as there are following new changes to be added in future
before we enable GuC/SLPC by default:
1. Link waitboost with SLPC.
2. Handle CPG as part of SLPC.
3. IA p-state logic update with GuC submission.

In order to enable CI/PnP testing of SLPC and to avoid frequent
rebase, this series should be safe for merge with feature in disabled
state.

v2: Addressed review comments on v1. Removed patch to enable SLPC by
 default.

v3: Addressed WARNING in igt@drv_module_reload_basic flagged by trybot BAT.
 Added change for sanitizing GT PM during reset. Added separate patch
 for sysfs interface to know HW requested frequency. Also, earlier
 patches did not go as series hence were not correctly picked up by BAT.

v4: Changes to multiple patches. CI BAT is passing. Performance run on SKL
 GT2 done and shows perf at parity with Host Turbo. For BXT, SLPC
 improves performance when GuC is enabled compared to Host Turbo.
 This series keeps only support of 9.18 firmware for better readability.
 If needed, other SLPC interfaces for different GuC version will be
 added later.

v5: This series incorporates feedback from code reviews on earlier series
 and adds following new changes:
1. More changes for separation of RPS and RC6 handling for Gen9.
2. Tied up SLPC enabling with GuC load/GuC submission sequence.
3. SLPC structures are defined explicitly for event input/output.
4. Definition of SLPC parameter control and task control functions
   agnostic to the underlying param definitions as they might
   change with GuC versions and prepared helpers for common tasks.
5. Transition of i915 overrides done through host to guc events
   to shared data and single reset event.
6. Handling SLPC status post reset through shared memory.
7. Derived helpers for setting frequency limits.
8. Removed sysfs interface to know RPNSWREQ as it is available in
   debugfs interface i915_frequency_info.
9. Simple igt test to verify SLPC configuration by i915 in various
   driver scenarios is prepared.

v6: This series adds following new changes:
1. Updated intel_guc_send for SLPC to receive output data from GuC.
2. Added task overrides and min frequency overrides in intel_slpc_init.
   min frequency is set to Rpe.
3. New debugfs interface added to set/unset/read SLPC parameters
   other than tasks and frequencies. SLPC reset post parameter update
   added.
4. SLPC parameters persist as part of i915-GuC shared data hence not
   overriding frequency limits while re-enabling SLPC.
5. Other minor fixes to clear pm_rps_events, clflush the shared data.

v7: This series adds following new changes:
1. Reordered patches. SLPC communication interfaces (structures and
   functions) are pulled into patches earlier in the series.
2. Eliminated dependency on i915.enable_slpc at various functions where
   rps_enabled is available.
3. s/i915_ggtt_offset/guc_ggtt_offset and sanitization of parameter
   in intel_uc_sanitize_options.

v8: Activated Balancer. Changed prototype of SLPC functions to accept
 struct intel_slpc as parameter instead of drm_i915_private.

VIZ-6889, VIZ-6890

Cc: Chris Wilson 
Cc: Daniel Vetter 
Cc: Beuchat, Marc 
Cc: Radoslaw Szwichtenberg 
Cc: Jeff McGee 
Cc: Arkadiusz Hiler 
Cc: Oscar Mateo 
Cc: Michał Winiarski 

I did enable SLPC on my machine and looks like everything is working fine. I
will be spending more time reviewing whole series and also running some tests on

Re: [Intel-gfx] [CI 7/9] drm/i915/guc: Submit GuC workitems containing coalesced requests

[Kamble, Sagar A]

Minor change needed: With removal of i915_guc_wq_reserve and void 
i915_guc_wq_unreserve, declaration "struct drm_i915_gem_request" can be 
removed from intel_uc.h


On 9/18/2017 3:34 PM, Chris Wilson wrote:

From: Michał Winiarski 

To create an upper bound on number of GuC workitems, we need to change
the way that requests are being submitted. Rather than submitting each
request as an individual workitem, we can do coalescing in a similar way
we're handlig execlist submission ports. We also need to stop pretending
that we're doing "lite-restore" in GuC submission (we would create a
workitem each time we hit this condition). This allows us to completely
remove the reservation, replacing it with a compile time check.

v2: Also coalesce when replaying on reset (Daniele)
v3: Consistent wq_resv - per-request (Daniele)
v4: Squash removing wq_resv
v5: Reflect i915_guc_submit argument changes in doc
v6: Rebase on top of execlists reset/restart fix (Chris)

References: https://bugs.freedesktop.org/show_bug.cgi?id=101873
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Jeff McGee 
Cc: Michal Wajdeczko 
Cc: Oscar Mateo 
Signed-off-by: Michał Winiarski 
Reviewed-by: Chris Wilson 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20170914083216.10192-2-michal.winiar...@intel.com
Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_debugfs.c|   2 -
  drivers/gpu/drm/i915/i915_guc_submission.c | 181 ++---
  drivers/gpu/drm/i915/intel_lrc.c   |  25 +---
  drivers/gpu/drm/i915/intel_uc.h|  11 --
  4 files changed, 63 insertions(+), 156 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 62133dd303ac..0364f0d2d76e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2451,8 +2451,6 @@ static void i915_guc_client_info(struct seq_file *m,
seq_printf(m, "\tWQ size %d, offset: 0x%x, tail %d\n",
client->wq_size, client->wq_offset, client->wq_tail);
  
-	seq_printf(m, "\tWork queue full: %u\n", client->no_wq_space);

-
for_each_engine(engine, dev_priv, id) {
u64 submissions = client->submissions[id];
tot += submissions;
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index c180ff1423fd..16b31f70114e 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -406,63 +406,6 @@ static void guc_stage_desc_fini(struct intel_guc *guc,
memset(desc, 0, sizeof(*desc));
  }
  
-/**

- * i915_guc_wq_reserve() - reserve space in the GuC's workqueue
- * @request:   request associated with the commands
- *
- * Return: 0 if space is available
- * -EAGAIN if space is not currently available
- *
- * This function must be called (and must return 0) before a request
- * is submitted to the GuC via i915_guc_submit() below. Once a result
- * of 0 has been returned, it must be balanced by a corresponding
- * call to submit().
- *
- * Reservation allows the caller to determine in advance that space
- * will be available for the next submission before committing resources
- * to it, and helps avoid late failures with complicated recovery paths.
- */
-int i915_guc_wq_reserve(struct drm_i915_gem_request *request)
-{
-   const size_t wqi_size = sizeof(struct guc_wq_item);
-   struct i915_guc_client *client = request->i915->guc.execbuf_client;
-   struct guc_process_desc *desc = __get_process_desc(client);
-   u32 freespace;
-   int ret;
-
-   spin_lock_irq(>wq_lock);
-   freespace = CIRC_SPACE(client->wq_tail, desc->head, client->wq_size);
-   freespace -= client->wq_rsvd;
-   if (likely(freespace >= wqi_size)) {
-   client->wq_rsvd += wqi_size;
-   ret = 0;
-   } else {
-   client->no_wq_space++;
-   ret = -EAGAIN;
-   }
-   spin_unlock_irq(>wq_lock);
-
-   return ret;
-}
-
-static void guc_client_update_wq_rsvd(struct i915_guc_client *client, int size)
-{
-   unsigned long flags;
-
-   spin_lock_irqsave(>wq_lock, flags);
-   client->wq_rsvd += size;
-   spin_unlock_irqrestore(>wq_lock, flags);
-}
-
-void i915_guc_wq_unreserve(struct drm_i915_gem_request *request)
-{
-   const int wqi_size = sizeof(struct guc_wq_item);
-   struct i915_guc_client *client = request->i915->guc.execbuf_client;
-
-   GEM_BUG_ON(READ_ONCE(client->wq_rsvd) < wqi_size);
-   guc_client_update_wq_rsvd(client, -wqi_size);
-}
-
  /* Construct a Work Item and append it to the GuC's Work Queue */
  static void guc_wq_item_append(struct i915_guc_client *client,
 

Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Export guc_init_send_regs and call only during intel_uc_init_hw

[Kamble, Sagar A]

On 9/18/2017 3:49 PM, Michal Wajdeczko wrote:
On Mon, 18 Sep 2017 12:11:24 +0200, Sagar Arun Kamble 
 wrote:



s/guc_init_send_regs/intel_guc_init_send_regs.
Added declaration in intel_uc.h. Calling it from intel_uc_init_hw as it
is one time setup.

Cc: Michal Wajdeczko 
Cc: Michał Winiarski 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_uc.c | 6 +++---
 drivers/gpu/drm/i915/intel_uc.h | 1 +
 2 files changed, 4 insertions(+), 3 deletions(-)

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

index 0178ba4..499ecf3 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -271,7 +271,7 @@ static inline i915_reg_t guc_send_reg(struct 
intel_guc *guc, u32 i)

 return _MMIO(guc->send_regs.base + 4 * i);
 }
-static void guc_init_send_regs(struct intel_guc *guc)
+void intel_guc_init_send_regs(struct intel_guc *guc)


Hmm, there is no reason to export this function now, as it called
by the function defined below.
Yeah :) ... I was probably thinking this to be defined in intel_guc.c 
which is changed with this series.



 {
 struct drm_i915_private *dev_priv = guc_to_i915(guc);
 enum forcewake_domains fw_domains = 0;
@@ -309,8 +309,6 @@ static int guc_enable_communication(struct 
intel_guc *guc)

 {
 struct drm_i915_private *dev_priv = guc_to_i915(guc);
-guc_init_send_regs(guc);
-
 if (HAS_GUC_CT(dev_priv))
 return intel_guc_enable_ct(guc);
@@ -386,6 +384,8 @@ int intel_uc_init_hw(struct drm_i915_private 
*dev_priv)

 if (ret)
 goto err_log_capture;
+intel_guc_init_send_regs(guc);
+


Hmm, if you want to make it 'one-time-setup' then this is still
wrong place as intel_uc_init_hw() can be called several times
during driver life cycle. Maybe all we need is new function
intel_uc_init(dev_priv) as existing intel_uc_init_early() may
be too early ;)

Michal

Right. Will move this in i915_driver_init_mmio after intel_uncore_init.



 ret = guc_enable_communication(guc);
 if (ret)
 goto err_log_capture;
diff --git a/drivers/gpu/drm/i915/intel_uc.h 
b/drivers/gpu/drm/i915/intel_uc.h

index 7703c9a..77e6d83 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -211,6 +211,7 @@ struct intel_huc {
 int intel_guc_sample_forcewake(struct intel_guc *guc);
 int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32 
len);
 int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, 
u32 len);

+void intel_guc_init_send_regs(struct intel_guc *guc);
static inline int intel_guc_send(struct intel_guc *guc, const u32 
*action, u32 len)

 {


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

Re: [Intel-gfx] [PATCH 06/10] drm/i915/huc: Move HuC specific declarations from intel_uc.h to intel_huc.h

[Kamble, Sagar A]

On 9/18/2017 1:43 AM, Michal Wajdeczko wrote:
On Sun, 17 Sep 2017 14:17:30 +0200, Sagar Arun Kamble 
 wrote:


Missing commit message

Sorry. Will update.



Cc: Michal Wajdeczko 
Cc: Michał Winiarski 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_huc.h | 39 
+++

 drivers/gpu/drm/i915/intel_uc.h  | 12 
 3 files changed, 40 insertions(+), 12 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_huc.h

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

index b0f38bb..a3b7435 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -60,6 +60,7 @@
 #include "intel_dpll_mgr.h"
 #include "intel_uc.h"
 #include "intel_guc.h"
+#include "intel_huc.h"


Huc/Guc details shall be wrapped into "intel_uc.h"

Yes. Will update.



 #include "intel_lrc.h"
 #include "intel_ringbuffer.h"
diff --git a/drivers/gpu/drm/i915/intel_huc.h 
b/drivers/gpu/drm/i915/intel_huc.h

new file mode 100644
index 000..4604a40
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -0,0 +1,39 @@
+/*
+ * Copyright © 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.
+ *
+ */
+#ifndef _INTEL_HUC_H_
+#define _INTEL_HUC_H_
+
+struct intel_huc {
+/* Generic uC firmware management */
+struct intel_uc_fw fw;
+
+/* HuC-specific additions */
+};
+
+/* intel_huc.c */
+void intel_huc_select_fw(struct intel_huc *huc);
+void intel_huc_init_hw(struct intel_huc *huc);
+void intel_huc_auth(struct intel_huc *huc);
+
+#endif
diff --git a/drivers/gpu/drm/i915/intel_uc.h 
b/drivers/gpu/drm/i915/intel_uc.h

index aad0b1c..0d346ef 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -98,13 +98,6 @@ struct intel_uc_fw {
 uint32_t ucode_offset;
 };
-struct intel_huc {
-/* Generic uC firmware management */
-struct intel_uc_fw fw;
-
-/* HuC-specific additions */
-};
-
 /* intel_uc.c */
 void intel_uc_sanitize_options(struct drm_i915_private *dev_priv);
 void intel_uc_init_early(struct drm_i915_private *dev_priv);
@@ -113,9 +106,4 @@ struct intel_huc {
 int intel_uc_init_hw(struct drm_i915_private *dev_priv);
 void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
-/* intel_huc.c */
-void intel_huc_select_fw(struct intel_huc *huc);
-void intel_huc_init_hw(struct intel_huc *huc);
-void intel_huc_auth(struct intel_huc *huc);
-
 #endif




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

Re: [Intel-gfx] [PATCH 01/10] drm/i915/guc: Create intel_guc.c for defining GuC specific functionality

[Kamble, Sagar A]

On 9/18/2017 1:00 AM, Michal Wajdeczko wrote:
On Sun, 17 Sep 2017 14:17:25 +0200, Sagar Arun Kamble 
 wrote:



Create intel_guc.c and move guc communication init functionality from
intel_uc.c. Prepared new initialization function intel_guc_init_early.
Moved below functions to intel_guc.c.
1. intel_guc_send_nop
2. gen8_guc_raise_irq
And below functions to intel_guc.h.
1. intel_guc_send
2. intel_guc_notify

Cc: Michal Wajdeczko 
Cc: Michał Winiarski 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/Makefile  |  1 +
 drivers/gpu/drm/i915/i915_guc_submission.c |  1 +
 drivers/gpu/drm/i915/intel_guc.c   | 47 
++
 drivers/gpu/drm/i915/intel_guc.h   | 43 
+++

 drivers/gpu/drm/i915/intel_guc_ct.c|  1 +
 drivers/gpu/drm/i915/intel_guc_log.c   |  1 +
 drivers/gpu/drm/i915/intel_huc.c   |  1 +
 drivers/gpu/drm/i915/intel_uc.c| 22 ++
 drivers/gpu/drm/i915/intel_uc.h| 11 ---
 9 files changed, 97 insertions(+), 31 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_guc.c
 create mode 100644 drivers/gpu/drm/i915/intel_guc.h

diff --git a/drivers/gpu/drm/i915/Makefile 
b/drivers/gpu/drm/i915/Makefile

index 1cb8059..e13fc19 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -59,6 +59,7 @@ i915-y += i915_cmd_parser.o \
# general-purpose microcontroller (GuC) support
 i915-y += intel_uc.o \
+  intel_guc.o \
   intel_guc_ct.o \
   intel_guc_log.o \
   intel_guc_loader.o \
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c

index 3f9d227..f37cd47 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -24,6 +24,7 @@
 #include 
 #include "i915_drv.h"
 #include "intel_uc.h"
+#include "intel_guc.h"


Please reorder your patches and make sure that no
explicit #include "intel_guc.h" are needed.

Sure. Will update.



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

new file mode 100644
index 000..0c62cc2
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -0,0 +1,47 @@
+/*
+ * Copyright © 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 "i915_drv.h"
+
+int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32 
len)

+{
+WARN(1, "Unexpected send: action=%#x\n", *action);
+return -ENODEV;
+}
+


hmm, you're moving send functions in patch 002/010
I think I should squash these patches together as I don't see clear 
separation.

Will prepare new patch to take out any delta refactoring done.



+static void gen8_guc_raise_irq(struct intel_guc *guc)
+{
+struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
+I915_WRITE(GUC_SEND_INTERRUPT, GUC_SEND_TRIGGER);
+}
+
+void intel_guc_init_early(struct intel_guc *guc)
+{
+intel_guc_ct_init_early(>ct);
+
+mutex_init(>send_mutex);
+guc->send = intel_guc_send_nop;
+guc->notify = gen8_guc_raise_irq;
+}
diff --git a/drivers/gpu/drm/i915/intel_guc.h 
b/drivers/gpu/drm/i915/intel_guc.h

new file mode 100644
index 000..76b7113
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright © 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 

Re: [Intel-gfx] [PATCH 04/10] drm/i915/guc: Move GuC specific declarations from intel_uc.h to intel_guc.h

[Kamble, Sagar A]

On 9/17/2017 11:54 PM, Michal Wajdeczko wrote:
On Sun, 17 Sep 2017 14:17:28 +0200, Sagar Arun Kamble 
 wrote:


Maybe to make this refactoring series much clearer you should start 
with this patch ?

and btw, please don't forget about adding commit description.
Sorry. Will update the patch and reorder. Tend to think that change 
obvious from commit subject does

not need the commit message. Will add commit message.



Cc: Michal Wajdeczko 
Cc: Michał Winiarski 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_drv.h  |   1 +
 drivers/gpu/drm/i915/intel_guc.h | 126 
+++
 drivers/gpu/drm/i915/intel_uc.h  | 125 
--

 3 files changed, 127 insertions(+), 125 deletions(-)

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

index 5aecbf7..b0f38bb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -59,6 +59,7 @@
 #include "intel_bios.h"
 #include "intel_dpll_mgr.h"
 #include "intel_uc.h"
+#include "intel_guc.h"


Hmm, the goal of previous (unfinished) refactoring was to
wrap all details about Guc/Huc into generic single "uc"
component. Thus any "guc"/"huc" specific headers shall
be included by master "intel_uc.h". If this is hard to
make, then maybe we should postpone changes in .h and
current limit refactoring only to .c files.

Michal

Sure. I will limit the factoring only to .c files.



 #include "intel_lrc.h"
 #include "intel_ringbuffer.h"
diff --git a/drivers/gpu/drm/i915/intel_guc.h 
b/drivers/gpu/drm/i915/intel_guc.h

index 06f2d27..919b6e1 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -24,6 +24,102 @@
 #ifndef _INTEL_GUC_H_
 #define _INTEL_GUC_H_
+/*
+ * This structure primarily describes the GEM object shared with the 
GuC.
+ * The specs sometimes refer to this object as a "GuC context", but 
we use

+ * the term "client" to avoid confusion with hardware contexts. This
+ * GEM object is held for the entire lifetime of our interaction with
+ * the GuC, being allocated before the GuC is loaded with its firmware.
+ * Because there's no way to update the address used by the GuC after
+ * initialisation, the shared object must stay pinned into the GGTT as
+ * long as the GuC is in use. We also keep the first page (only) mapped
+ * into kernel address space, as it includes shared data that must be
+ * updated on every request submission.
+ *
+ * The single GEM object described here is actually made up of several
+ * separate areas, as far as the GuC is concerned. The first page (kept
+ * kmap'd) includes the "process descriptor" which holds sequence 
data for

+ * the doorbell, and one cacheline which actually *is* the doorbell; a
+ * write to this will "ring the doorbell" (i.e. send an interrupt to 
the

+ * GuC). The subsequent  pages of the client object constitute the work
+ * queue (a circular array of work items), again described in the 
process

+ * descriptor. Work queue pages are mapped momentarily as required.
+ */
+struct i915_guc_client {
+struct i915_vma *vma;
+void *vaddr;
+struct i915_gem_context *owner;
+struct intel_guc *guc;
+
+uint32_t engines;/* bitmap of (host) engine ids */
+uint32_t priority;
+u32 stage_id;
+uint32_t proc_desc_offset;
+
+u16 doorbell_id;
+unsigned long doorbell_offset;
+
+spinlock_t wq_lock;
+/* Per-engine counts of GuC submissions */
+uint64_t submissions[I915_NUM_ENGINES];
+};
+
+struct intel_guc_log {
+uint32_t flags;
+struct i915_vma *vma;
+/* The runtime stuff gets created only when GuC logging gets 
enabled */

+struct {
+void *buf_addr;
+struct workqueue_struct *flush_wq;
+struct work_struct flush_work;
+struct rchan *relay_chan;
+} runtime;
+/* logging related stats */
+u32 capture_miss_count;
+u32 flush_interrupt_count;
+u32 prev_overflow_count[GUC_MAX_LOG_BUFFER];
+u32 total_overflow_count[GUC_MAX_LOG_BUFFER];
+u32 flush_count[GUC_MAX_LOG_BUFFER];
+};
+
+struct intel_guc {
+struct intel_uc_fw fw;
+struct intel_guc_log log;
+struct intel_guc_ct ct;
+
+/* Log snapshot if GuC errors during load */
+struct drm_i915_gem_object *load_err_log;
+
+/* intel_guc_recv interrupt related state */
+bool interrupts_enabled;
+
+struct i915_vma *ads_vma;
+struct i915_vma *stage_desc_pool;
+void *stage_desc_pool_vaddr;
+struct ida stage_ids;
+
+struct i915_guc_client *execbuf_client;
+
+DECLARE_BITMAP(doorbell_bitmap, GUC_NUM_DOORBELLS);
+uint32_t db_cacheline;/* Cyclic counter mod pagesize*/
+
+/* GuC's FW specific registers used in MMIO send */
+struct {
+u32 base;
+unsigned int count;
+enum forcewake_domains fw_domains;
+} send_regs;
+
+

Re: [Intel-gfx] [PATCH] drm/i915: Increase the busyspin durations for i915_wait_request

[Kamble, Sagar A]

Thanks Chris. LGTM.

Minor inputs below


On 9/14/2017 3:28 PM, Chris Wilson wrote:

An interesting discussion regarding "hybrid interrupt polling" for NVMe
came to the conclusion that the ideal busyspin before sleeping was half
of the expected request latency (and better if it was already halfway
through that request). This suggested that we too should look again at
our tradeoff between spinning and waiting. Currently, our spin simply
tries to hide the cost of enabling the interrupt, which is good to avoid
penalising nop requests (i.e. test throughput) and not much else.
Studying real world workloads suggests that a spin of upto 500us can
dramatically boost performance, but the suggestion is that this is not
from avoiding interrupt latency per-se, but from secondary effects of
sleeping such as allowing the CPU reduce cstate and context switch away.
To offset those costs from penalising the active client, bump the initial
spin somewhat to 250us and the secondary spin to 20us to balance the cost
of another context switch following the interrupt.

Suggested-by: Sagar Kamble 
Signed-off-by: Chris Wilson 
Cc: Sagar Kamble 
Cc: Eero Tamminen 
Cc: Tvrtko Ursulin 
Cc: Ben Widawsky 
Cc: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/i915_gem_request.c | 25 +
  1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 813a3b546d6e..ccbdaf6a0e4d 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -1155,8 +1155,20 @@ long i915_wait_request(struct drm_i915_gem_request *req,
GEM_BUG_ON(!intel_wait_has_seqno());
GEM_BUG_ON(!i915_sw_fence_signaled(>submit));
  
-	/* Optimistic short spin before touching IRQs */

-   if (i915_spin_request(req, state, 5))
+   /* Optimistic short spin before touching IRQs.
+*
+* We use a rather large value here to offset the penalty of switching
+* away from the active task. Frequently, the client will wait upon
+* an old swapbuffer to throttle itself to remain within a frame of
+* the gpu. If the client is running in lockstep with the gpu, then
+* it should not be waiting long at all, and a sleep now will incur
+* extra scheduler latency in producing the next frame. So we sleep

Typo? Should this be "So we spin for longer"

+* for longer to try and keep the client running.
+*
+* We need ~5us to enable the irq, ~20us to hide a context switch,
+* we use 250us to keep the cache hot.
+*/
+   if (i915_spin_request(req, state, 250))
Hybrid polling introduces sleep of 1/2 request duration prior to poll of 
1/2 request duration.

Should we reorder here to achieve the same?

goto complete;
  
  	set_current_state(state);

@@ -1212,8 +1224,13 @@ long i915_wait_request(struct drm_i915_gem_request *req,
__i915_wait_request_check_and_reset(req))
continue;
  
-		/* Only spin if we know the GPU is processing this request */

-   if (i915_spin_request(req, state, 2))
+   /*
+* A quick spin now we are on the CPU to offset the cost of
+* context switching away (and so spin for roughly the same as
+* the scheduler latency). We only spin if we know the GPU is
+* processing this request, and so likely to finish shortly.
+*/
+   if (i915_spin_request(req, state, 20))
break;
  
  		if (!intel_wait_check_request(, req)) {


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

Re: [Intel-gfx] [PATCH 6/6] drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts

[Kamble, Sagar A]

On 9/14/2017 9:41 PM, Michal Wajdeczko wrote:
On Thu, 14 Sep 2017 18:04:27 +0200, Kamble, Sagar A 
<sagar.a.kam...@intel.com> wrote:





On 9/14/2017 6:07 PM, Michal Wajdeczko wrote:
On Thu, 14 Sep 2017 11:55:08 +0200, Sagar Arun Kamble 
<sagar.a.kam...@intel.com> wrote:



From: "Kamble, Sagar A" <sagar.a.kam...@intel.com>

Disabling GuC interrupts involves access to GuC IRQ control registers
hence ensure device is RPM awake.

Cc: Michal Wajdeczko <michal.wajdec...@intel.com>
Signed-off-by: Sagar Arun Kamble <sagar.a.kam...@intel.com>
---
 drivers/gpu/drm/i915/intel_guc_log.c | 2 ++
 1 file changed, 2 insertions(+)

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

index ba36162..d7557b5 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -657,8 +657,10 @@ void i915_guc_log_unregister(struct 
drm_i915_private *dev_priv)

 return;
mutex_lock(_priv->drm.struct_mutex);
+intel_runtime_pm_get(dev_priv);
 /* GuC logging is currently the only user of Guc2Host 
interrupts */

 gen9_disable_guc_interrupts(dev_priv);
+intel_runtime_pm_put(dev_priv);
 guc_log_runtime_destroy(_priv->guc);


Maybe we should just destroy runtime here, and allow irq to be disabled
by intel_uc_fini_hw() which will be called right after. This will also
fix the upcoming case when log will not be the only user of Guc irqs.

See https://patchwork.freedesktop.org/patch/170390/

Michal
Destroying runtime here may create issues as enabled GuC interrupts 
may be causing the use of the guc_log_runtime.


Yes, but this should be easy to fix.


Should we move the i915_driver_unregister post i915_gem_unload?


But then we will have to handle the case when gem was unloaded but
driver will still be in registered state.

Note that as guc log will not be the only user of the guc irqs,
code that disables irq will be removed from this function anyway.

Michal
I see now that guc_log_runtime_destroy already happen along 
intel_uc_fini_hw->i915_guc_submission_fini->intel_guc_log_destroy path too.
So we can remove guc_log_unregister completely with irq_disable 
happening as part of intel_guc_unload and guc_log_runtime_destroy too 
handled.





mutex_unlock(_priv->drm.struct_mutex);
 }


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

Re: [Intel-gfx] [PATCH 6/6] drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts

[Kamble, Sagar A]

On 9/14/2017 6:07 PM, Michal Wajdeczko wrote:
On Thu, 14 Sep 2017 11:55:08 +0200, Sagar Arun Kamble 
<sagar.a.kam...@intel.com> wrote:



From: "Kamble, Sagar A" <sagar.a.kam...@intel.com>

Disabling GuC interrupts involves access to GuC IRQ control registers
hence ensure device is RPM awake.

Cc: Michal Wajdeczko <michal.wajdec...@intel.com>
Signed-off-by: Sagar Arun Kamble <sagar.a.kam...@intel.com>
---
 drivers/gpu/drm/i915/intel_guc_log.c | 2 ++
 1 file changed, 2 insertions(+)

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

index ba36162..d7557b5 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -657,8 +657,10 @@ void i915_guc_log_unregister(struct 
drm_i915_private *dev_priv)

 return;
mutex_lock(_priv->drm.struct_mutex);
+intel_runtime_pm_get(dev_priv);
 /* GuC logging is currently the only user of Guc2Host interrupts */
 gen9_disable_guc_interrupts(dev_priv);
+intel_runtime_pm_put(dev_priv);
 guc_log_runtime_destroy(_priv->guc);


Maybe we should just destroy runtime here, and allow irq to be disabled
by intel_uc_fini_hw() which will be called right after. This will also
fix the upcoming case when log will not be the only user of Guc irqs.

See https://patchwork.freedesktop.org/patch/170390/

Michal
Destroying runtime here may create issues as enabled GuC interrupts may 
be causing the use of the guc_log_runtime.

Should we move the i915_driver_unregister post i915_gem_unload?



mutex_unlock(_priv->drm.struct_mutex);
 }


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

Re: [Intel-gfx] [PATCH 5/6] drm/i915/guc: Enable default/critical logging in GuC by default from GuC v9

[Kamble, Sagar A]

On 9/14/2017 6:43 PM, Michal Wajdeczko wrote:
On Thu, 14 Sep 2017 11:55:07 +0200, Sagar Arun Kamble 
<sagar.a.kam...@intel.com> wrote:



From: "Kamble, Sagar A" <sagar.a.kam...@intel.com>

With GuC v9, new type of Default/critical logging in GuC to enable
capturing minimal important logs in production systems efficiently.
This patch enables this logging in GuC by default always. It should
be noted that streaming support with half-full interrupt mechanism
that is present for normal logging is not present for this type of
logging.

v2: Emulating GuC critical logging through i915.guc_log_level. Setting
this to 0 will make GuC critical logging ON and setting it to 1-4 will
communicate log level of 0-3 to GuC.


Is this statement still valid ?
If not, make sure to say so in later updates.

Will update this description.




v3: Commit message update. Enable default/critical logging in GuC 
always.

Fixed RPM wake during guc_log_unregister in the unload path.

v4: Moved RPM wake change to separate patch. Removed GUC_DEBUG_RESERVED
and updated name of new bit to be version agnostic. Updated parameter to
struct intel_guc * and name of macro NEEDS_GUC_CRITICAL_LOGGING.
Removed explicit clearing of GUC_CRITICAL_LOGGING_DISABLED from
params[GUC_CTL_DEBUG] as it is unnecessary. (Michal Wajdeczko)

v5: Removed GUC_CRITICAL_LOGGING_DISABLED. Added HAS_GUC check to
GUC_NEEDS_CRITICAL_LOGGING. (Michal Wajdeczko)

Cc: Chheda Harsh J <harsh.j.chh...@intel.com>
Cc: Fry Gregory P <gregory.p@intel.com>
Cc: Spotswood John A <john.a.spotsw...@intel.com>
Cc: Anusha Srivatsa <anusha.sriva...@intel.com>
Cc: Michal Wajdeczko <michal.wajdec...@intel.com>
Cc: Michał Winiarski <michal.winiar...@intel.com>
Signed-off-by: Jeff McGee <jeff.mc...@intel.com>
Signed-off-by: Sagar Arun Kamble <sagar.a.kam...@intel.com>
---
 drivers/gpu/drm/i915/intel_guc_fwif.h | 15 +--
 drivers/gpu/drm/i915/intel_guc_log.c  |  4 +++-
 2 files changed, 16 insertions(+), 3 deletions(-)

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

index 7eb6b4f..231b87e 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -127,7 +127,6 @@
 #define   GUC_PROFILE_ENABLED(1 << 7)
 #define   GUC_WQ_TRACK_ENABLED(1 << 8)
 #define   GUC_ADS_ENABLED(1 << 9)
-#define   GUC_DEBUG_RESERVED(1 << 10)
 #define   GUC_ADS_ADDR_SHIFT11
 #define   GUC_ADS_ADDR_MASK0xf800
@@ -135,6 +134,17 @@
#define GUC_CTL_MAX_DWORDS(SOFT_SCRATCH_COUNT - 2) /* [1..14] */
+/*
+ * Critical logging in GuC is to be enabled always from GuC v9+.
+ * (for KBL - v9.39+)
+ */
+#define GUC_NEEDS_CRITICAL_LOGGING(guc)\
+(HAS_GUC(guc_to_i915(guc)) && \
+ (((IS_SKYLAKE(guc_to_i915(guc)) || 
IS_BROXTON(guc_to_i915(guc))) && \

+   guc->fw.major_ver_found >= 9) || \
+  (IS_KABYLAKE(guc_to_i915(guc)) && guc->fw.major_ver_found >= 9 
&& \

+   guc->fw.minor_ver_found >= 39)))
+


Hmm, I was thinking about something simpler like this:

#define GUC_NEEDS_CRITICAL_LOGGING(guc)\
(HAS_GUC(guc_to_i915(guc) && \
(guc->fw.major_ver_found >= 9) && \
(guc->fw.minor_ver_found >= (IS_KABYLAKE(guc_to_i915(guc) ? 39 : 0))

and I'm not sure that this macro shall be defined in fwif.h file.

As it is only used in one place, maybe it can defined/expanded just 
there ?

Sure. I will change this.


Michal


 /**
  * DOC: GuC Firmware Layout
  *
@@ -539,7 +549,8 @@ struct guc_log_buffer_state {
 u32 logging_enabled:1;
 u32 reserved1:3;
 u32 verbosity:4;
-u32 reserved2:24;
+u32 critical_logging_enabled:1;
+u32 reserved2:23;
 };
 u32 value;
 } __packed;
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c

index 16d3b87..ba36162 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -589,7 +589,6 @@ void intel_guc_log_destroy(struct intel_guc *guc)
 int i915_guc_log_control(struct drm_i915_private *dev_priv, u64 
control_val)

 {
 struct intel_guc *guc = _priv->guc;
-
 union guc_log_control log_param;
 int ret;
@@ -603,6 +602,9 @@ int i915_guc_log_control(struct drm_i915_private 
*dev_priv, u64 control_val)

 if (!log_param.logging_enabled && (i915.guc_log_level < 0))
 return 0;
+if (GUC_NEEDS_CRITICAL_LOGGING(guc))
+log_param.critical_logging_enabled = 1;
+
 ret = guc_log_control(guc, log_param.value);
 if (ret < 0) {
 DRM_DEBUG_DRIVER("guc_logging_control action failed %d\n", 
ret);


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

Re: [Intel-gfx] [PATCH 2/6] drm/i915/guc: Make guc_enable/disable_communication functions public

[Kamble, Sagar A]

On 9/14/2017 9:01 PM, Michal Wajdeczko wrote:
On Thu, 14 Sep 2017 11:55:04 +0200, Sagar Arun Kamble 
<sagar.a.kam...@intel.com> wrote:



From: "Kamble, Sagar A" <sagar.a.kam...@intel.com>

This patch is moving guc_enable_communication and
guc_disable_communication to intel_guc.c and making it available for
use through intel_guc.h.
Intent is to reuse this function for calling from intel_uc_init_hw
and also as part of intel_uc_fini_hw where it will be coupled with
other teardown related to GuC in the upcoming patch.


Hmm, but both intel_uc_init_hw() and intel_uc_fini_hw() shall stay in
intel_uc.c and the best place for guc_[enable|disable]_communication()
functions is also in intel_uc.c as they provide generic switch between
MMIO/CT send mechanism, so I'm not so sure that we need this patch.

Michal

Hi Michal,

Plan was to disable communication while entering rpm/system suspend, 
reset, unload
and enable back when resuming. If we don't want to update these 
mechanisms across rpm/system suspend or reset will

remove this patch then.




Cc: Michal Wajdeczko <michal.wajdec...@intel.com>
Cc: Michał Winiarski <michal.winiar...@intel.com>
Signed-off-by: Sagar Arun Kamble <sagar.a.kam...@intel.com>
---
 drivers/gpu/drm/i915/intel_guc.c | 21 +
 drivers/gpu/drm/i915/intel_guc.h |  2 ++
 drivers/gpu/drm/i915/intel_uc.c  | 29 -
 3 files changed, 27 insertions(+), 25 deletions(-)

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

index 5559e00..75bb830 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -181,3 +181,24 @@ void intel_guc_auth_huc(struct intel_guc *guc, 
struct intel_huc *huc)

 out:
 i915_vma_unpin(vma);
 }
+
+int intel_guc_enable_communication(struct intel_guc *guc)
+{
+struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
+if (HAS_GUC_CT(dev_priv))
+return intel_guc_enable_ct(guc);
+
+guc->send = intel_guc_send_mmio;
+return 0;
+}
+
+void intel_guc_disable_communication(struct intel_guc *guc)
+{
+struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
+if (HAS_GUC_CT(dev_priv))
+intel_guc_disable_ct(guc);
+
+guc->send = intel_guc_send_nop;
+}
diff --git a/drivers/gpu/drm/i915/intel_guc.h 
b/drivers/gpu/drm/i915/intel_guc.h

index 9a282aa..8ed0e81 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -149,6 +149,8 @@ static inline u32 guc_ggtt_offset(struct i915_vma 
*vma)
 int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32 
len);
 int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, 
u32 len);

 void intel_guc_auth_huc(struct intel_guc *guc, struct intel_huc *huc);
+int intel_guc_enable_communication(struct intel_guc *guc);
+void intel_guc_disable_communication(struct intel_guc *guc);
/* intel_guc_loader.c */
 int intel_guc_select_fw(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/intel_uc.c 
b/drivers/gpu/drm/i915/intel_uc.c

index a3fc4c8..30c004c 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -265,27 +265,6 @@ static void guc_free_load_err_log(struct 
intel_guc *guc)

 i915_gem_object_put(guc->load_err_log);
 }
-static int guc_enable_communication(struct intel_guc *guc)
-{
-struct drm_i915_private *dev_priv = guc_to_i915(guc);
-
-if (HAS_GUC_CT(dev_priv))
-return intel_guc_enable_ct(guc);
-
-guc->send = intel_guc_send_mmio;
-return 0;
-}
-
-static void guc_disable_communication(struct intel_guc *guc)
-{
-struct drm_i915_private *dev_priv = guc_to_i915(guc);
-
-if (HAS_GUC_CT(dev_priv))
-intel_guc_disable_ct(guc);
-
-guc->send = intel_guc_send_nop;
-}
-
 int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 {
 struct intel_guc *guc = _priv->guc;
@@ -295,7 +274,7 @@ int intel_uc_init_hw(struct drm_i915_private 
*dev_priv)

 if (!i915.enable_guc_loading)
 return 0;
-guc_disable_communication(guc);
+intel_guc_disable_communication(guc);
 gen9_reset_guc_interrupts(dev_priv);
/* We need to notify the guc whenever we change the GGTT */
@@ -347,7 +326,7 @@ int intel_uc_init_hw(struct drm_i915_private 
*dev_priv)

intel_guc_init_send_regs(guc);
-ret = guc_enable_communication(guc);
+ret = intel_guc_enable_communication(guc);
 if (ret)
 goto err_log_capture;
@@ -373,7 +352,7 @@ int intel_uc_init_hw(struct drm_i915_private 
*dev_priv)

  * marks the GPU as wedged until reset).
  */
 err_interrupts:
-guc_disable_communication(guc);
+intel_guc_disable_communication(guc);
 gen9_disable_guc_interrupts(dev_priv);
 err_log_capture:
 guc_capture_load_err_log(guc);
@@ -410,7 +389,7 @@ void intel_uc_fini_hw(struct drm_i915_private 
*dev_priv)

 if (i915.enable_guc_submission)
 i915_guc_submission_di

Re: [Intel-gfx] [PATCH 5/6] drm/i915/guc: Enable default/critical logging in GuC by default from GuC v9

[Kamble, Sagar A]

On 9/11/2017 11:34 PM, Michal Wajdeczko wrote:

On Mon, Sep 11, 2017 at 11:32:23AM +0530, Sagar Arun Kamble wrote:

From: "Kamble, Sagar A" <sagar.a.kam...@intel.com>

With GuC v9, new type of Default/critical logging in GuC to enable
capturing minimal important logs in production systems efficiently.
This patch enables this logging in GuC by default always. It should
be noted that streaming support with half-full interrupt mechanism
that is present for normal logging is not present for this type of
logging.

v2: Emulating GuC critical logging through i915.guc_log_level. Setting
this to 0 will make GuC critical logging ON and setting it to 1-4 will
communicate log level of 0-3 to GuC.

v3: Commit message update. Enable default/critical logging in GuC always.
Fixed RPM wake during guc_log_unregister in the unload path.

v4: Moved RPM wake change to separate patch. Removed GUC_DEBUG_RESERVED
and updated name of new bit to be version agnostic. Updated parameter to
struct intel_guc * and name of macro NEEDS_GUC_CRITICAL_LOGGING.
Removed explicit clearing of GUC_CRITICAL_LOGGING_DISABLED from
params[GUC_CTL_DEBUG] as it is unnecessary. (Michal Wajdeczko)

Cc: Chheda Harsh J <harsh.j.chh...@intel.com>
Cc: Fry Gregory P <gregory.p@intel.com>
Cc: Spotswood John A <john.a.spotsw...@intel.com>
Cc: Anusha Srivatsa <anusha.sriva...@intel.com>
Cc: Michal Wajdeczko <michal.wajdec...@intel.com>
Cc: Michał Winiarski <michal.winiar...@intel.com>
Signed-off-by: Jeff McGee <jeff.mc...@intel.com>
Signed-off-by: Sagar Arun Kamble <sagar.a.kam...@intel.com>
---
  drivers/gpu/drm/i915/intel_guc_fwif.h | 15 +--
  drivers/gpu/drm/i915/intel_guc_log.c  |  4 +++-
  2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 5fa2860..3ef228b 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -131,7 +131,7 @@
  #define   GUC_PROFILE_ENABLED (1 << 7)
  #define   GUC_WQ_TRACK_ENABLED(1 << 8)
  #define   GUC_ADS_ENABLED (1 << 9)
-#define   GUC_DEBUG_RESERVED   (1 << 10)
+#define   GUC_CRITICAL_LOGGING_DISABLED(1 << 10)

Looks like we don't need this at all
I had disabled this logging in the initial version of patch to reduce 
the impact.
So earlier I had to explicitly declare this bit and set in the 
guc_params[CTL_DEBUG].
But recommendation from GuC team is to keep this always enabled hence we 
can do away with not touching
guc_params[CTL_DEBUG] at all but then in order to make the users aware 
that bit 10 being unset has some meaning I was
clearing it explicitly. Wont removing this bit definition now eliminate 
the meaning for bit 10 while loading GuC all together?






  #define   GUC_ADS_ADDR_SHIFT  11
  #define   GUC_ADS_ADDR_MASK   0xf800
  
@@ -139,6 +139,16 @@
  
  #define GUC_CTL_MAX_DWORDS		(SOFT_SCRATCH_COUNT - 2) /* [1..14] */
  
+/*

+ * Critical logging in GuC is to be enabled always from GuC v9+.
+ * (for KBL - v9.39+)
+ */
+#define GUC_NEEDS_CRITICAL_LOGGING(guc)\
+   (((IS_SKYLAKE(guc_to_i915(guc)) || IS_BROXTON(guc_to_i915(guc))) && \

Can we use here HAS_GUC() ? Comment says that this is for all Guc

Michal

Yes. Will add this.




+   guc->fw.major_ver_found >= 9) || \
+ (IS_KABYLAKE(guc_to_i915(guc)) && guc->fw.major_ver_found >= 9 && \
+   guc->fw.minor_ver_found >= 39))
+
  /**
   * DOC: GuC Firmware Layout
   *
@@ -539,7 +549,8 @@ struct guc_log_buffer_state {
u32 logging_enabled:1;
u32 reserved1:3;
u32 verbosity:4;
-   u32 reserved2:24;
+   u32 critical_logging_enabled:1;
+   u32 reserved2:23;
};
u32 value;
  } __packed;
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 16d3b87..ba36162 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -589,7 +589,6 @@ void intel_guc_log_destroy(struct intel_guc *guc)
  int i915_guc_log_control(struct drm_i915_private *dev_priv, u64 control_val)
  {
struct intel_guc *guc = _priv->guc;
-
union guc_log_control log_param;
int ret;
  
@@ -603,6 +602,9 @@ int i915_guc_log_control(struct drm_i915_private *dev_priv, u64 control_val)

if (!log_param.logging_enabled && (i915.guc_log_level < 0))
return 0;
  
+	if (GUC_NEEDS_CRITICAL_LOGGING(guc))

+   log_param.critical_logging_enabled = 1;
+
ret = guc_log_control(guc, log_param.value);
if (ret < 0) {
DRM_DEBUG_DRIVER("guc_logging_control action failed %d\n", ret);
--
1.9.1



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

Re: [Intel-gfx] [PATCH 6/6] drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts

[Kamble, Sagar A]

On 9/11/2017 11:04 PM, Michal Wajdeczko wrote:

On Mon, Sep 11, 2017 at 11:32:24AM +0530, Sagar Arun Kamble wrote:

Disabling GuC interrupts involves access to GuC IRQ control registers
hence ensure device is RPM awake.

Cc: Michal Wajdeczko 
Signed-off-by: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/intel_guc_log.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index ba36162..d7557b5 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -657,8 +657,10 @@ void i915_guc_log_unregister(struct drm_i915_private 
*dev_priv)
return;
  
  	mutex_lock(_priv->drm.struct_mutex);

+   intel_runtime_pm_get(dev_priv);
/* GuC logging is currently the only user of Guc2Host interrupts */
gen9_disable_guc_interrupts(dev_priv);
+   intel_runtime_pm_put(dev_priv);

There are other places in this file where guc interrupts are enabled/disabled.
Shouldn't we do the same there ?

Regards,
Michal
Those are already covered by the RPM locks along the paths 
i915_gem_init_hw, i915_guc_log_control, guc_unpause, guc_pause caller in 
system suspend, i915_reset.



guc_log_runtime_destroy(_priv->guc);
mutex_unlock(_priv->drm.struct_mutex);
  }
--
1.9.1



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

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Separate GuC/HuC specific functionality from intel_uc

[Kamble, Sagar A]

On 9/7/2017 5:54 PM, Michał Winiarski wrote:

On Fri, Sep 01, 2017 at 11:02:09AM +0530, Sagar Arun Kamble wrote:

Removed unnecessary intel_uc.h includes as it is present in i915_drv.h.
Created intel_guc.c and intel_guc.h for placing GuC specific code.
Created intel_huc.h to refer to HuC specific functions.

v2: Prepared intel_uc_common.h. huc_auth code declaration adjusted.
Moved enable/disable_communication to intel_uc.c (Michal)

In v2 you also renamed things, moved things around (and addressed all of the
other review comments from Michał).

Yes. Sorry. Will update in the next revision.



Cc: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Signed-off-by: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/Makefile  |   1 +
  drivers/gpu/drm/i915/i915_drv.c|   1 -
  drivers/gpu/drm/i915/i915_guc_submission.c |   1 -
  drivers/gpu/drm/i915/intel_guc.c   | 193 ++
  drivers/gpu/drm/i915/intel_guc.h   | 200 +++
  drivers/gpu/drm/i915/intel_guc_loader.c|   1 -
  drivers/gpu/drm/i915/intel_huc.c   |  50 +-
  drivers/gpu/drm/i915/intel_huc.h   |  38 +
  drivers/gpu/drm/i915/intel_uc.c| 128 +--
  drivers/gpu/drm/i915/intel_uc.h| 254 +
  drivers/gpu/drm/i915/intel_uc_common.h | 101 
  11 files changed, 545 insertions(+), 423 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/intel_guc.c
  create mode 100644 drivers/gpu/drm/i915/intel_guc.h
  create mode 100644 drivers/gpu/drm/i915/intel_huc.h
  create mode 100644 drivers/gpu/drm/i915/intel_uc_common.h

[SNIP]


diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 22ae52b..c87a2b4 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -24,256 +24,8 @@
  #ifndef _INTEL_UC_H_
  #define _INTEL_UC_H_
  

[SNIP]


-/* intel_huc.c */
-void intel_huc_select_fw(struct intel_huc *huc);
-void intel_huc_init_hw(struct intel_huc *huc);
-void intel_guc_auth_huc(struct drm_i915_private *dev_priv);
+#include 
+#include 
+#include 

^^^
Will this build? (well... it passed BAT, but it doesn't compile on my box).
drivers/gpu/drm/i915 is not -I, so we should use quote marks, not angle
brackets.

Separate header, why? Can't we merge intel_uc_common.h with intel_uc.h?

-Michał
Will change these to quote marks. I added this as separate header to not 
declare struct intel_uc_fw in same header as struct intel_guc and struct 
intel_huc.
We can merge but then it will take #include for intel_guc.h and 
intel_huc.h to the end of file.
If we want to keep intel_guc.h and intel_huc.h at the top, they should 
reference pointer to struct intel_uc_fw.

For readability I feel having intel_uc_common.h also seems intuitive.

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

Re: [Intel-gfx] [PATCH 3/4] drm/i915/guc: Fix GuC HW/SW state cleanup in unload path

[Kamble, Sagar A]

On 9/5/2017 8:24 PM, Michał Winiarski wrote:

On Fri, Sep 01, 2017 at 11:02:11AM +0530, Sagar Arun Kamble wrote:

Teardown of GuC HW/SW state was not properly done in unload path.
During unload, we can rely on intel_guc_reset_prepare being done
as part of i915_gem_suspend for disabling GuC interfaces.
We will have to disable GuC submission prior to suspend as that involves
communication with GuC to destroy doorbell. So intel_uc_fini_hw has to
be called as part of i915_gem_suspend during unload as that really
takes care of finishing the GuC operations. Created new parameter for
i915_gem_suspend to handle unload/suspend path w.r.t gem and GuC suspend.
GuC related allocations are cleaned up as part of intel_uc_cleanup_hw.

Is this still accurate description? After changes from v2?

No. Sorry. Will update this in the new version.



v2: Prepared i915_gem_unload. (Michal)

Cc: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Signed-off-by: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/i915_drv.c|  6 +--
  drivers/gpu/drm/i915/i915_drv.h|  1 +
  drivers/gpu/drm/i915/i915_gem.c| 79 ++
  drivers/gpu/drm/i915/intel_guc.c   | 13 ++
  drivers/gpu/drm/i915/intel_guc.h   |  1 +
  drivers/gpu/drm/i915/intel_uc.c| 14 +++---
  drivers/gpu/drm/i915/intel_uc_common.h |  1 +
  7 files changed, 103 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b2e8f95..b6cc2fe 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -601,7 +601,7 @@ static void i915_gem_fini(struct drm_i915_private *dev_priv)
i915_gem_drain_workqueue(dev_priv);
  
  	mutex_lock(_priv->drm.struct_mutex);

-   intel_uc_fini_hw(dev_priv);
+   intel_uc_cleanup_hw(dev_priv);
i915_gem_cleanup_engines(dev_priv);
i915_gem_contexts_fini(dev_priv);
i915_gem_cleanup_userptr(dev_priv);
@@ -682,7 +682,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
return 0;
  
  cleanup_gem:

-   if (i915_gem_suspend(dev_priv))
+   if (i915_gem_unload(dev_priv))
DRM_ERROR("failed to idle hardware; continuing to unload!\n");
i915_gem_fini(dev_priv);
  cleanup_uc:
@@ -1375,7 +1375,7 @@ void i915_driver_unload(struct drm_device *dev)
  
  	i915_driver_unregister(dev_priv);
  
-	if (i915_gem_suspend(dev_priv))

+   if (i915_gem_unload(dev_priv))
DRM_ERROR("failed to idle hardware; continuing to unload!\n");
  
  	intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 064bf0f..570e71e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3628,6 +3628,7 @@ void i915_gem_reset_engine(struct intel_engine_cs *engine,
  int i915_gem_wait_for_idle(struct drm_i915_private *dev_priv,
   unsigned int flags);
  int __must_check i915_gem_suspend(struct drm_i915_private *dev_priv);
+int __must_check i915_gem_unload(struct drm_i915_private *dev_priv);
  void i915_gem_resume(struct drm_i915_private *dev_priv);
  int i915_gem_fault(struct vm_fault *vmf);
  int i915_gem_object_wait(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 977500f..24cefe9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4624,6 +4624,85 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
return ret;
  }
  
+int i915_gem_unload(struct drm_i915_private *dev_priv)

+{
+   struct drm_device *dev = _priv->drm;
+   int ret;
+
+   intel_runtime_pm_get(dev_priv);
+   intel_suspend_gt_powersave(dev_priv);
+
+   mutex_lock(>struct_mutex);
+
+   /* We have to flush all the executing contexts to main memory so
+* that they can saved in the hibernation image. To ensure the last
+* context image is coherent, we have to switch away from it. That
+* leaves the dev_priv->kernel_context still active when
+* we actually suspend, and its image in memory may not match the GPU
+* state. Fortunately, the kernel_context is disposable and we do
+* not rely on its state.
+*/
+   ret = i915_gem_switch_to_kernel_context(dev_priv);
+   if (ret)
+   goto err_unlock;
+
+   ret = i915_gem_wait_for_idle(dev_priv,
+I915_WAIT_INTERRUPTIBLE |
+I915_WAIT_LOCKED);
+   if (ret)
+   goto err_unlock;
+
+   assert_kernel_context_is_current(dev_priv);
+   i915_gem_contexts_lost(dev_priv);
+   mutex_unlock(>struct_mutex);
+
+   cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
+   

Re: [Intel-gfx] [PATCH i-g-t 1/1] igt/dapc: Test Driver Assisted Performance Capture (DAPC)

[Kamble, Sagar A]

Thanks Lionel for the review. Will revamp the testcase.


Thanks

Sagar

On 8/29/2017 2:21 PM, Lionel Landwerlin wrote:

Hi Sagar,

Thanks for writing this test. It looks promising but there are a few 
issues that needs to be addressed for this to run in CI.

Please have a look at the comments below.

Thanks!

On 28/08/17 10:53, Sagar Arun Kamble wrote:

This test verifies different i915 perf sampling options for fields like
PID, CTX ID, Timestamp, OA Report, TAG, MMIO.

Cc: Lionel Landwerlin 
Signed-off-by: Sourab Gupta 
Signed-off-by: Sagar Arun Kamble 
---
  tests/Makefile.sources |1 +
  tests/dapc.c   | 1017 


  2 files changed, 1018 insertions(+)
  create mode 100644 tests/dapc.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index bb013c7..61feb0d 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -26,6 +26,7 @@ TESTS_progs = \
  core_getversion \
  core_prop_blob \
  core_setmaster_vs_auth \
+dapc \
  debugfs_test \
  drm_import_export \
  drm_mm \
diff --git a/tests/dapc.c b/tests/dapc.c
new file mode 100644
index 000..f49b1cd
--- /dev/null
+++ b/tests/dapc.c
@@ -0,0 +1,1017 @@
+/*
+ * Copyright © 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.
+ *
+ * dapc: Driver Assisted Performance Capture
+ * This tests the i915 perf functionality to sample various 
metrics by
+ * associating with the CS stream or just standalone periodic OA 
samples.
+ * Verifies fields like PID, CTX ID, Timestamp, OA Report, MMIO, 
Tags are

+ * generated properly for each sample.
+ *
+ * Authors:
+ *   Sourab Gupta 
+ *   Sagar Arun Kamble 
+ *
+ */
+#define _GNU_SOURCE
+#include "xf86drm.h"
+#include "i915_drm.h"
+#include "igt_core.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+


To be able to run this test in the continuous integration system, we 
need it to be autonomous.
The following macro requires user interaction. Unfortunately that 
won't work.
Please look at the other tests to create subtests and make sure we can 
run this in the CI.

Thanks!

Yes. Will update this.



+#define COLLECT_DATA { \
+printf("(%s) Collecting data. ", __func__); \
+printf("Press enter to continue...\n"); \
+getc(stdin); \
+}
+


It would be good to test stream configurations with different sizes.
For example only Pid, or Tag & Pid or SourceInfo & ctx ID & Tag, etc...
And verify that we get reports with appropriate sizes.

Sure. Will try to add testcases for those combinations too.


+#define OA_SAMPLE_SIZE_MAX(8 +/* drm_i915_perf_record_header 
*/ \

+ 8 +/* source info */ \
+ 8 +/* ctx ID */ \
+ 8 +/* Pid */ \
+ 8 +/* Tag */ \
+ 256) /* raw OA counter snapshot */
+
+#define TS_SAMPLE_SIZE_MAX(8 +/* drm_i915_perf_record_header 
*/ \

+ 8 +/* ctx ID */ \
+ 8 +/* Pid */ \
+ 8 +/* Tag */ \
+ 8)/* Timestamp */ \
+
+#define TS_MMIO_SAMPLE_SIZE_MAX(8 +   /* 
drm_i915_perf_record_header */ \

+ 8 +   /* ctx ID */ \
+ 8 +   /* Pid */ \
+ 8 +   /* Tag */ \
+ 8 +   /* Timestamp */ \
+ 4*I915_PERF_MMIO_NUM_MAX)/* MMIO reg */
+
+#define OA_TS_MMIO_SAMPLE_SIZE_MAX (8 +   /* 
drm_i915_perf_record_header */ \

+8 +   /* source info */ \
+8 +   /* ctx ID */ \
+8 +   /* Pid */ \
+  

Re: [Intel-gfx] [PATCH i-g-t 1/1] igt/dapc: Test Driver Assisted Performance Capture (DAPC)

[Kamble, Sagar A]

On 8/30/2017 3:09 PM, Daniel Vetter wrote:

One more on top of Lionel's coments.

On Mon, Aug 28, 2017 at 03:23:03PM +0530, Sagar Arun Kamble wrote:

+int main(int argc, char **argv)
+{
+   bool ret;
+   int option;
+   int platform;
+
+   if (argc != 3) {
+   printf("Usage: \n./dapc  \
+   \nPlatform: 0-HSW, 1-BDW, 2-SKL\n\
+   \nTest_mode:\n\
+   \t0 - RCS OA mode\n\
+   \t1 - RCS TS mode\n\
+   \t2 - RCS TS+MMIO mode\n\
+   \t3 - RCS OA+TS+MMIO mode\n\
+   \t4 - Periodic OA mode\n");
+   return 0;
+   }
+
+   ret = initialize();
+   if (!ret)
+   return -1;
+
+   platform = atoi(argv[1]);
+   switch (platform) {
+   case 0:
+   arch = ARCH_HSW;
+   break;
+   case 1:
+   arch = ARCH_BDW;
+   break;
+   case 2:
+   arch = ARCH_SKL;
+   break;
+   default:
+   fprintf(stderr, "Invalid platform:%d\n", platform);
+   return -1;
+   }
+
+   option = atoi(argv[2]);

Please convert this into a proper igt testcase that enumrates subtests
like all the others. Otherwise CI won't pick it up, which makes this
wasted effort. This means using igt_main, igt_subtest, igt_fixture and all
the various igt_assert/require macros we have to check results.

Also dapc is not a good testcase name, needs some proper prefixing.
-Daniel

Yes. Will update the testcase. Thank you Daniel.



+   switch (option) {
+   case 0:
+   test_perf_dapc_rcs_oa();
+   break;
+   case 1:
+   test_perf_dapc_rcs_ts();
+   break;
+   case 2:
+   test_perf_dapc_rcs_ts_mmio();
+   break;
+   case 3:
+   test_perf_dapc_rcs_oa_ts_mmio();
+   break;
+   case 4:
+   test_perf_dapc_periodic_oa();
+   break;
+   default:
+   fprintf(stderr, "Invalid Option:%d\n", option);
+   return -1;
+   }
+
+   return 0;
+}
--
1.9.1

___
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: Make some RPS functions static

[Kamble, Sagar A]

Reviewed-by: Sagar Arun Kamble <sagar.a.kam...@intel.com>

-Original Message-
From: Mateo Lozano, Oscar 
Sent: Thursday, August 24, 2017 5:28 AM
To: intel-gfx@lists.freedesktop.org
Cc: Mateo Lozano, Oscar <oscar.ma...@intel.com>; Kamble, Sagar A 
<sagar.a.kam...@intel.com>; Vivi, Rodrigo <rodrigo.v...@intel.com>
Subject: [PATCH 1/2] drm/i915: Make some RPS functions static

They are not used anywhere else. Also, fix a small typo in a comment.

No functional changes.

Cc: Sagar Arun Kamble <sagar.a.kam...@intel.com>
Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
Signed-off-by: Oscar Mateo <oscar.ma...@intel.com>
---
 drivers/gpu/drm/i915/i915_irq.c  | 8 
 drivers/gpu/drm/i915/intel_drv.h | 3 ---
 2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index e21ce9c..5d391e6 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -336,7 +336,7 @@ void gen6_mask_pm_irq(struct drm_i915_private *dev_priv, 
u32 mask)
__gen6_mask_pm_irq(dev_priv, mask);
 }
 
-void gen6_reset_pm_iir(struct drm_i915_private *dev_priv, u32 reset_mask)
+static void gen6_reset_pm_iir(struct drm_i915_private *dev_priv, u32 
reset_mask)
 {
i915_reg_t reg = gen6_pm_iir(dev_priv);
 
@@ -347,7 +347,7 @@ void gen6_reset_pm_iir(struct drm_i915_private *dev_priv, 
u32 reset_mask)
POSTING_READ(reg);
 }
 
-void gen6_enable_pm_irq(struct drm_i915_private *dev_priv, u32 enable_mask)
+static void gen6_enable_pm_irq(struct drm_i915_private *dev_priv, u32 
enable_mask)
 {
lockdep_assert_held(_priv->irq_lock);
 
@@ -357,7 +357,7 @@ void gen6_enable_pm_irq(struct drm_i915_private *dev_priv, 
u32 enable_mask)
/* unmask_pm_irq provides an implicit barrier (POSTING_READ) */
 }
 
-void gen6_disable_pm_irq(struct drm_i915_private *dev_priv, u32 disable_mask)
+static void gen6_disable_pm_irq(struct drm_i915_private *dev_priv, u32 
disable_mask)
 {
lockdep_assert_held(_priv->irq_lock);
 
@@ -405,7 +405,7 @@ void gen6_disable_rps_interrupts(struct drm_i915_private 
*dev_priv)
synchronize_irq(dev_priv->drm.irq);
 
/* Now that we will not be generating any more work, flush any
-* outsanding tasks. As we are called on the RPS idle path,
+* outstanding tasks. As we are called on the RPS idle path,
 * we will reset the GPU to minimum frequencies, so the current
 * state of the worker can be discarded.
 */
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f60995f..74c1860 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1206,11 +1206,8 @@ 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);
-void gen6_reset_pm_iir(struct drm_i915_private *dev_priv, u32 mask);
 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_enable_pm_irq(struct drm_i915_private *dev_priv, uint32_t mask);
-void gen6_disable_pm_irq(struct drm_i915_private *dev_priv, uint32_t 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

Re: [Intel-gfx] [PATCH 03/12] drm/i915: Framework for capturing command stream based OA reports and ctx id info.

[Kamble, Sagar A]

Hi Chis,

Understood the need to handle request reordering. 
Are you suggesting following paths:
1. cs samples list for stream be read based on the order of submission from 
submit timestamps/OA capture timestamps.
2. put the commands to capture during eb_submit and patch the offset in vma 
where data is to be captured, populate cs sample list during 
__i915_gem_request_submit

For preemption, it would then simplify by just discarding the cs sample and 
relying on corresponding next  __i915_gem_request_submit.

Thanks
Sagar

-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] 
Sent: Monday, July 31, 2017 3:42 PM
To: Kamble, Sagar A <sagar.a.kam...@intel.com>; intel-gfx@lists.freedesktop.org
Cc: Sourab Gupta <sourab.gu...@intel.com>
Subject: Re: [Intel-gfx] [PATCH 03/12] drm/i915: Framework for capturing 
command stream based OA reports and ctx id info.

Quoting Chris Wilson (2017-07-31 09:34:30)
> Quoting Sagar Arun Kamble (2017-07-31 08:59:36)
> > +/**
> > + * i915_perf_stream_emit_sample_capture - Insert the commands to 
> > +capture perf
> > + * metrics into the GPU command stream
> > + * @stream: An i915-perf stream opened for GPU metrics
> > + * @request: request in whose context the metrics are being collected.
> > + * @preallocate: allocate space in ring for related sample.
> > + */
> > +static void i915_perf_stream_emit_sample_capture(
> > +   struct i915_perf_stream *stream,
> > +   struct drm_i915_gem_request 
> > *request,
> > +   bool preallocate) {
> > +   struct reservation_object *resv = stream->cs_buffer.vma->resv;
> > +   struct i915_perf_cs_sample *sample;
> > +   unsigned long flags;
> > +   int ret;
> > +
> > +   sample = kzalloc(sizeof(*sample), GFP_KERNEL);
> > +   if (sample == NULL) {
> > +   DRM_ERROR("Perf sample alloc failed\n");
> > +   return;
> > +   }
> > +
> > +   sample->request = i915_gem_request_get(request);
> > +   sample->ctx_id = request->ctx->hw_id;
> > +
> > +   insert_perf_sample(stream, sample);
> > +
> > +   if (stream->sample_flags & SAMPLE_OA_REPORT) {
> > +   ret = i915_emit_oa_report_capture(request,
> > + preallocate,
> > + sample->offset);
> > +   if (ret)
> > +   goto err_unref;
> > +   }
> 
> This is incorrect as the requests may be reordered. You either need to 
> declare the linear ordering of requests through the sample buffer, or 
> we have to delay setting sample->offset until execution, and even then 
> we need to disable preemption when using SAMPLE_OA_REPORT.

Thinking about it, you do need to serialise based on stream->vma, or else where 
a stream->vma per capture context.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/12] drm/i915: Framework for capturing command stream based OA reports and ctx id info.

[Kamble, Sagar A]

From: sourab gupta [mailto:sourabgu...@gmail.com]
Sent: Wednesday, August 2, 2017 8:17 AM
To: Landwerlin, Lionel G <lionel.g.landwer...@intel.com>
Cc: Kamble, Sagar A <sagar.a.kam...@intel.com>; 
intel-gfx@lists.freedesktop.org; Sourab Gupta <sourab.gu...@intel.com>
Subject: Re: [Intel-gfx] [PATCH 03/12] drm/i915: Framework for capturing 
command stream based OA reports and ctx id info.



On Wed, Aug 2, 2017 at 2:28 AM, Lionel Landwerlin 
<lionel.g.landwer...@intel.com<mailto:lionel.g.landwer...@intel.com>> wrote:
On 01/08/17 19:05, sourab gupta wrote:


On Tue, Aug 1, 2017 at 2:59 PM, Kamble, Sagar A 
<sagar.a.kam...@intel.com<mailto:sagar.a.kam...@intel.com>> wrote:


-Original Message-
From: Landwerlin, Lionel G
Sent: Monday, July 31, 2017 9:16 PM
To: Kamble, Sagar A 
<sagar.a.kam...@intel.com<mailto:sagar.a.kam...@intel.com>>; 
intel-gfx@lists.freedesktop.org<mailto:intel-gfx@lists.freedesktop.org>
Cc: Sourab Gupta <sourab.gu...@intel.com<mailto:sourab.gu...@intel.com>>
Subject: Re: [Intel-gfx] [PATCH 03/12] drm/i915: Framework for capturing 
command stream based OA reports and ctx id info.

On 31/07/17 08:59, Sagar Arun Kamble wrote:
> From: Sourab Gupta <sourab.gu...@intel.com<mailto:sourab.gu...@intel.com>>
>
> This patch introduces a framework to capture OA counter reports associated
> with Render command stream. We can then associate the reports captured
> through this mechanism with their corresponding context id's. This can be
> further extended to associate any other metadata information with the
> corresponding samples (since the association with Render command stream
> gives us the ability to capture these information while inserting the
> corresponding capture commands into the command stream).
>
> The OA reports generated in this way are associated with a corresponding
> workload, and thus can be used the delimit the workload (i.e. sample the
> counters at the workload boundaries), within an ongoing stream of periodic
> counter snapshots.
>
> There may be usecases wherein we need more than periodic OA capture mode
> which is supported currently. This mode is primarily used for two usecases:
>  - Ability to capture system wide metrics, alongwith the ability to map
>the reports back to individual contexts (particularly for HSW).
>  - Ability to inject tags for work, into the reports. This provides
>visibility into the multiple stages of work within single context.
>
> The userspace will be able to distinguish between the periodic and CS based
> OA reports by the virtue of source_info sample field.
>
> The command MI_REPORT_PERF_COUNT can be used to capture snapshots of OA
> counters, and is inserted at BB boundaries.
> The data thus captured will be stored in a separate buffer, which will
> be different from the buffer used otherwise for periodic OA capture mode.
> The metadata information pertaining to snapshot is maintained in a list,
> which also has offsets into the gem buffer object per captured snapshot.
> In order to track whether the gpu has completed processing the node,
> a field pertaining to corresponding gem request is added, which is tracked
> for completion of the command.
>
> Both periodic and CS based reports are associated with a single stream
> (corresponding to render engine), and it is expected to have the samples
> in the sequential order according to their timestamps. Now, since these
> reports are collected in separate buffers, these are merge sorted at the
> time of forwarding to userspace during the read call.
>
> v2: Aligning with the non-perf interface (custom drm ioctl based). Also,
> few related patches are squashed together for better readability
>
> v3: Updated perf sample capture emit hook name. Reserving space upfront
> in the ring for emitting sample capture commands and using
> req->fence.seqno for tracking samples. Added SRCU protection for streams.
> Changed the stream last_request tracking to resv object. (Chris)
> Updated perf.sample_lock spin_lock usage to avoid softlockups. Moved
> stream to global per-engine structure. (Sagar)
> Update unpin and put in the free routines to i915_vma_unpin_and_release.
> Making use of perf stream cs_buffer vma resv instead of separate resv obj.
> Pruned perf stream vma resv during gem_idle. (Chris)
> Changed payload field ctx_id to u64 to keep all sample data aligned at 8
> bytes. (Lionel)
> stall/flush prior to sample capture is not added. Do we need to give this
> control to user to select whether to stall/flush at each sample?
>
> Signed-off-by: Sourab Gupta 
> <sourab.gu...@intel.com<mailto:sourab.gu...@intel.com>>
> Signed-off-by: Robert Bragg 
> <rob...@sixbynine.org<mailto:rob...@sixbynine.

Re: [Intel-gfx] [PATCH 03/12] drm/i915: Framework for capturing command stream based OA reports and ctx id info.

[Kamble, Sagar A]

-Original Message-
From: Landwerlin, Lionel G 
Sent: Monday, July 31, 2017 9:16 PM
To: Kamble, Sagar A <sagar.a.kam...@intel.com>; intel-gfx@lists.freedesktop.org
Cc: Sourab Gupta <sourab.gu...@intel.com>
Subject: Re: [Intel-gfx] [PATCH 03/12] drm/i915: Framework for capturing 
command stream based OA reports and ctx id info.

On 31/07/17 08:59, Sagar Arun Kamble wrote:
> From: Sourab Gupta <sourab.gu...@intel.com>
>
> This patch introduces a framework to capture OA counter reports associated
> with Render command stream. We can then associate the reports captured
> through this mechanism with their corresponding context id's. This can be
> further extended to associate any other metadata information with the
> corresponding samples (since the association with Render command stream
> gives us the ability to capture these information while inserting the
> corresponding capture commands into the command stream).
>
> The OA reports generated in this way are associated with a corresponding
> workload, and thus can be used the delimit the workload (i.e. sample the
> counters at the workload boundaries), within an ongoing stream of periodic
> counter snapshots.
>
> There may be usecases wherein we need more than periodic OA capture mode
> which is supported currently. This mode is primarily used for two usecases:
>  - Ability to capture system wide metrics, alongwith the ability to map
>the reports back to individual contexts (particularly for HSW).
>  - Ability to inject tags for work, into the reports. This provides
>visibility into the multiple stages of work within single context.
>
> The userspace will be able to distinguish between the periodic and CS based
> OA reports by the virtue of source_info sample field.
>
> The command MI_REPORT_PERF_COUNT can be used to capture snapshots of OA
> counters, and is inserted at BB boundaries.
> The data thus captured will be stored in a separate buffer, which will
> be different from the buffer used otherwise for periodic OA capture mode.
> The metadata information pertaining to snapshot is maintained in a list,
> which also has offsets into the gem buffer object per captured snapshot.
> In order to track whether the gpu has completed processing the node,
> a field pertaining to corresponding gem request is added, which is tracked
> for completion of the command.
>
> Both periodic and CS based reports are associated with a single stream
> (corresponding to render engine), and it is expected to have the samples
> in the sequential order according to their timestamps. Now, since these
> reports are collected in separate buffers, these are merge sorted at the
> time of forwarding to userspace during the read call.
>
> v2: Aligning with the non-perf interface (custom drm ioctl based). Also,
> few related patches are squashed together for better readability
>
> v3: Updated perf sample capture emit hook name. Reserving space upfront
> in the ring for emitting sample capture commands and using
> req->fence.seqno for tracking samples. Added SRCU protection for streams.
> Changed the stream last_request tracking to resv object. (Chris)
> Updated perf.sample_lock spin_lock usage to avoid softlockups. Moved
> stream to global per-engine structure. (Sagar)
> Update unpin and put in the free routines to i915_vma_unpin_and_release.
> Making use of perf stream cs_buffer vma resv instead of separate resv obj.
> Pruned perf stream vma resv during gem_idle. (Chris)
> Changed payload field ctx_id to u64 to keep all sample data aligned at 8
> bytes. (Lionel)
> stall/flush prior to sample capture is not added. Do we need to give this
> control to user to select whether to stall/flush at each sample?
>
> Signed-off-by: Sourab Gupta <sourab.gu...@intel.com>
> Signed-off-by: Robert Bragg <rob...@sixbynine.org>
> Signed-off-by: Sagar Arun Kamble <sagar.a.kam...@intel.com>
> ---
>   drivers/gpu/drm/i915/i915_drv.h|  101 ++-
>   drivers/gpu/drm/i915/i915_gem.c|1 +
>   drivers/gpu/drm/i915/i915_gem_execbuffer.c |8 +
>   drivers/gpu/drm/i915/i915_perf.c   | 1185 
> ++--
>   drivers/gpu/drm/i915/intel_engine_cs.c |4 +
>   drivers/gpu/drm/i915/intel_ringbuffer.c|2 +
>   drivers/gpu/drm/i915/intel_ringbuffer.h|5 +
>   include/uapi/drm/i915_drm.h|   15 +
>   8 files changed, 1073 insertions(+), 248 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 2c7456f..8b1cecf 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1985,6 +1985,24 @@ struct i915_perf_stream_ops {
>* The stream will 

Re: [Intel-gfx] [PATCH 06/12] drm/i915: Populate ctx ID for periodic OA reports

[Kamble, Sagar A]

Ctx_id for first submission will be its corresponding context as CS sample for 
that is allocated during submission with ctx_id taken from ctx->hw_id.
For periodic reports, cs sample after those reports will have the ctx_id info 
as the timestamp of that CS sample's report is greater than periodic report.

With no CS samples, periodic reports can't be associated with last context 
hence that would need change in following patch to set last ctx id to INVALID
f5f73cf drm/i915: Flush periodic samples, in case of no pending CS sample 
requests

Timestamps of OA reports taken before and after batch are used to associate 
ctx_id information with OA reports.
So for e.g. for batches B1, B2 if following is the timeline:
B1.start -> P1 -> P2 -> B1.end -> P3 -> B2.start -> P4 -> B2.end

Then while reading CS samples will be read first interleaved with OA samples so
Read sequence will be
1. Read B1.start report
2. Read P1 and P2 and associate with B1's context
3. Read B1.end report
4. Read P3 and associate with B1 (this is incorrect - should not be tagged with 
any context)
5. Read B2.start report
6. Read P4 and associate with B2's context
7. Read B2.end report



-Original Message-
From: Landwerlin, Lionel G 
Sent: Monday, July 31, 2017 2:57 PM
To: Kamble, Sagar A <sagar.a.kam...@intel.com>; intel-gfx@lists.freedesktop.org
Cc: Sourab Gupta <sourab.gu...@intel.com>
Subject: Re: [Intel-gfx] [PATCH 06/12] drm/i915: Populate ctx ID for periodic 
OA reports

Hi Sagar,

I'm curious to what happens if 2 contexts submit requests which a time period 
smaller than the sampling OA period on Gen7.5.
My understanding is that with this change you'll only retain the last 
submission and then the ctx_id reported in the SAMPLE_CTX_ID field will be 
incorrect for the first workload.

Am I missing something?

-
Lionel

On 31/07/17 08:59, Sagar Arun Kamble wrote:
> From: Sourab Gupta <sourab.gu...@intel.com>
>
> This adds support for populating the ctx id for the periodic OA 
> reports when requested through the corresponding property.
>
> For Gen8, the OA reports itself have the ctx ID and it is the one 
> programmed into HW while submitting workloads. Thus it's retrieved 
> from reports itself.
> For Gen7, the OA reports don't have any such field, and we can 
> populate this field with the last seen ctx ID while sending CS reports.
>
> Signed-off-by: Sourab Gupta <sourab.gu...@intel.com>
> Signed-off-by: Sagar Arun Kamble <sagar.a.kam...@intel.com>
> ---
>   drivers/gpu/drm/i915/i915_drv.h  |  8 ++
>   drivers/gpu/drm/i915/i915_perf.c | 58 
> +++-
>   2 files changed, 54 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> b/drivers/gpu/drm/i915/i915_drv.h index fb81315..6c011f3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2077,6 +2077,8 @@ struct i915_perf_stream {
>   
>   wait_queue_head_t poll_wq;
>   bool pollin;
> +
> + u32 last_ctx_id;
>   };
>   
>   /**
> @@ -2151,6 +2153,12 @@ struct i915_oa_ops {
>* generations.
>*/
>   u32 (*oa_hw_tail_read)(struct drm_i915_private *dev_priv);
> +
> + /**
> +  * @get_ctx_id: Retrieve the ctx_id associated with the (periodic) OA
> +  * report.
> +  */
> + u32 (*get_ctx_id)(struct i915_perf_stream *stream, const u8 
> +*report);
>   };
>   
>   /*
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> index 905c5bb..1f5ebdb 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -790,6 +790,45 @@ static u32 oa_buffer_num_reports_unlocked(
>   return aged_tail == INVALID_TAIL_PTR ? 0 : num_reports;
>   }
>   
> +static u32 gen7_oa_buffer_get_ctx_id(struct i915_perf_stream *stream,
> + const u8 *report)
> +{
> + if (!stream->cs_mode)
> + WARN_ONCE(1,
> + "CTX ID can't be retrieved if command stream mode not 
> enabled");
> +
> + /*
> +  * OA reports generated in Gen7 don't have the ctx ID information.
> +  * Therefore, just rely on the ctx ID information from the last CS
> +  * sample forwarded
> +  */
> + return stream->last_ctx_id;
> +}
> +
> +static u32 gen8_oa_buffer_get_ctx_id(struct i915_perf_stream *stream,
> + const u8 *report)
> +{
> + u32 ctx_id;
> +
> + /* The ctx ID present in the OA reports have intel_context::hw_id
> +  * present, since this is programmed into the ELSP in execlist mode.
> +  * In non-execlist mode, fall back to retrieving the ctx ID from the
> +  * last saved ctx 

Re: [Intel-gfx] [RFC 01/14] RFC drm/i915: Expose a PMU interface for perf queries

[Kamble, Sagar A]

Can we reuse calc_residency defined in i915_sysfs.c


On 7/18/2017 8:06 PM, Tvrtko Ursulin wrote:

From: Chris Wilson 

The first goal is to be able to measure GPU (and invidual ring) busyness
without having to poll registers from userspace. (Which not only incurs
holding the forcewake lock indefinitely, perturbing the system, but also
runs the risk of hanging the machine.) As an alternative we can use the
perf event counter interface to sample the ring registers periodically
and send those results to userspace.

To be able to do so, we need to export the two symbols from
kernel/events/core.c to register and unregister a PMU device.

v2: Use a common timer for the ring sampling.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/Makefile   |   1 +
  drivers/gpu/drm/i915/i915_drv.c |   2 +
  drivers/gpu/drm/i915/i915_drv.h |  23 ++
  drivers/gpu/drm/i915/i915_pmu.c | 452 
  drivers/gpu/drm/i915/intel_ringbuffer.h |   2 +
  include/uapi/drm/i915_drm.h |  41 +++
  kernel/events/core.c|   1 +
  7 files changed, 522 insertions(+)
  create mode 100644 drivers/gpu/drm/i915/i915_pmu.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index f8227318dcaf..1c720013dc42 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -26,6 +26,7 @@ i915-y := i915_drv.o \
  
  i915-$(CONFIG_COMPAT)   += i915_ioc32.o

  i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o intel_pipe_crc.o
+i915-$(CONFIG_PERF_EVENTS) += i915_pmu.o
  
  # GEM code

  i915-y += i915_cmd_parser.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d310d8245dca..f18ce519f6a2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1194,6 +1194,7 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
struct drm_device *dev = _priv->drm;
  
  	i915_gem_shrinker_init(dev_priv);

+   i915_pmu_register(dev_priv);
  
  	/*

 * Notify a valid surface after modesetting,
@@ -1247,6 +1248,7 @@ static void i915_driver_unregister(struct 
drm_i915_private *dev_priv)
intel_opregion_unregister(dev_priv);
  
  	i915_perf_unregister(dev_priv);

+   i915_pmu_unregister(dev_priv);
  
  	i915_teardown_sysfs(dev_priv);

i915_guc_log_unregister(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7c6fab08a2e6..de518503e033 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -40,6 +40,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -2093,6 +2094,12 @@ struct intel_cdclk_state {
unsigned int cdclk, vco, ref;
  };
  
+enum {

+   __I915_SAMPLE_FREQ_ACT = 0,
+   __I915_SAMPLE_FREQ_REQ,
+   __I915_NUM_PMU_SAMPLERS
+};
+
  struct drm_i915_private {
struct drm_device drm;
  
@@ -2591,6 +2598,13 @@ struct drm_i915_private {

int irq;
} lpe_audio;
  
+	struct {

+   struct pmu base;
+   struct hrtimer timer;
+   u64 enable;
+   u64 sample[__I915_NUM_PMU_SAMPLERS];
+   } pmu;
+
/*
 * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
 * will be rejected. Instead look for a better place.
@@ -3760,6 +3774,15 @@ extern void i915_perf_fini(struct drm_i915_private 
*dev_priv);
  extern void i915_perf_register(struct drm_i915_private *dev_priv);
  extern void i915_perf_unregister(struct drm_i915_private *dev_priv);
  
+/* i915_pmu.c */

+#ifdef CONFIG_PERF_EVENTS
+extern void i915_pmu_register(struct drm_i915_private *i915);
+extern void i915_pmu_unregister(struct drm_i915_private *i915);
+#else
+static inline void i915_pmu_register(struct drm_i915_private *i915) {}
+static inline void i915_pmu_unregister(struct drm_i915_private *i915) {}
+#endif
+
  /* i915_suspend.c */
  extern int i915_save_state(struct drm_i915_private *dev_priv);
  extern int i915_restore_state(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
new file mode 100644
index ..f03ddad44da6
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -0,0 +1,452 @@
+#include 
+#include 
+
+#include "i915_drv.h"
+#include "intel_ringbuffer.h"
+
+#define FREQUENCY 200
+#define PERIOD max_t(u64, 1, NSEC_PER_SEC / FREQUENCY)
+
+#define RING_MASK 0x
+#define RING_MAX 32
+
+static void engines_sample(struct drm_i915_private *dev_priv)
+{
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+   bool fw = false;
+
+   if ((dev_priv->pmu.enable & RING_MASK) == 0)
+   return;
+
+   if (!dev_priv->gt.awake)
+   return;
+
+   if (!intel_runtime_pm_get_if_in_use(dev_priv))
+   return;
+
+   

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915: Suspend GuC prior to GPU Reset during GEM suspend

[Kamble, Sagar A]

On 4/5/2017 6:32 PM, David Weinehall wrote:

On 2017-04-05 15:54, Joonas Lahtinen wrote:

On ke, 2017-04-05 at 15:51 +0530, Sagar Arun Kamble wrote:
i915 is currently doing Full GPU reset at the end of suspend 
followed by

GuC suspend. This reset bypasses the GuC. We need to tell the GuC to
suspend before we do a direct intel_gpu_reset, Otherwise the gpu 
state will

no longer match the GuC's expectations and its suspend will not be
successful. With this change, i915 suspends GuC after suspending GEM 
and

before doing Full GPU reset.

+ David, Oscar and Michel

My understanding is that reloading GuC firmware after each resume is a
major bottleneck in resume time, and we instead should be telling GuC
to suspend and not reset the GPU, at most only reset the engines.

Regards, Joonas


If this is possible, then yes, it'd definitely be preferable. If not,
then doing the GuC + HuC loading asynchronously on resume would be 
preferable.

Anusha mentioned working on asynchronous loading, hence added to CC.


Kind regards, David
Data points about GuC load times for reference that I collected today on 
SKL and APL.
At Rpn(lowest frequency) it loads/becomes ready in 3-4 jiffies. Running 
at >=RPe it becomes ready in a jiffy.

Are these times in tolerable limits?
Another concern Daniele highlighted was rare chance of WOPCM persisting 
post suspend/resume and hence needing reload.
I believe the fetch from disk must be time consuming during boot time 
load and for that asynchronous

load can be pursued.

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

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Suspend GuC during GEM Suspend prior to GPU Reset

[Kamble, Sagar A]

On 4/5/2017 2:30 PM, Chris Wilson wrote:

On Wed, Apr 05, 2017 at 11:04:34AM +0530, Sagar Arun Kamble wrote:

During S3/S4 suspend, i915 sends HOST2GUC with ENTER_S_STATE action
for suspending GuC. GuC stops scheduling at this point. i915 is
currently doing explicit GPU reset during suspend ensuring GEM is idle.
Suspend GuC prior to triggering GPU Reset to ensure GuC stays idle too.

Why would a gpu reset cause the guc to think it was not idle, and
futhermore ignore the suspend request afterwards? Should we not be
completely disabling the guc along the system suspend path? Especially
if it is so easily confused?
-Chris
Post GPU reset, GuC firmware is unloaded and GuC is not ready till we 
reinitialize the firmware so
all Host to GuC actions are bound to fail. ENTER_S_STATE is disabling 
GuC scheduling completely.
GuC is saving the needed state and ensuring wake events are disabled. So 
we need to trigger this

action prior to resetting GPU in suspend path.




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

Re: [Intel-gfx] [PATCH] drm/i915/guc: limit forcewake to blitter domain in guc_send

[Kamble, Sagar A]

Reviewed-by: Sagar Arun Kamble 

On 3/24/2017 8:18 PM, Daniele Ceraolo Spurio wrote:

The forcewake_get call in the guc_send_mmio function was added to
avoid getting and releasing forcewake on each register access.
While this makes sense, all GuC registers are in the blitter range
so no need to wake all the wells.

Signed-off-by: Daniele Ceraolo Spurio 
---
  drivers/gpu/drm/i915/intel_uc.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 4a872cd..e016227 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -245,7 +245,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len)
return -EINVAL;
  
  	mutex_lock(>send_mutex);

-   intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+   intel_uncore_forcewake_get(dev_priv, FORCEWAKE_BLITTER);
  
  	dev_priv->guc.action_count += 1;

dev_priv->guc.action_cmd = action[0];
@@ -283,7 +283,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len)
}
dev_priv->guc.action_status = status;
  
-	intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);

+   intel_uncore_forcewake_put(dev_priv, FORCEWAKE_BLITTER);
mutex_unlock(>send_mutex);
  
  	return ret;


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

Re: [Intel-gfx] [PATCH v7 05/21] drm/i915/slpc: Sanitize GuC version

[Kamble, Sagar A]

Thanks Joonas, Michal. Will update this patch.

On 3/22/2017 9:00 PM, Joonas Lahtinen wrote:

On ke, 2017-03-22 at 16:18 +0100, Michal Wajdeczko wrote:

On Wed, Mar 22, 2017 at 03:33:38PM +0530, Sagar Arun Kamble wrote:

@@ -130,6 +130,8 @@ struct intel_uc_fw {
uint32_t ucode_offset;
  };
  
+#define FIRMWARE_URL  "https://01.org/linuxgraphics/intel-linux-gr

aphics-firmwares"

Is it ok that we use such generic macro name without any intel/i915
prefix?

Definitely not, this is result of moving from .c to .h. Need to add
I915_ prefix.

Regards, Joonas


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

Re: [Intel-gfx] [i-g-t 1/1] tests/gem_gtt_hog: Clear the parameters for GEM_CREATE ioctl

[Kamble, Sagar A]

On 3/20/2017 2:25 PM, Chris Wilson wrote:

On Mon, Mar 20, 2017 at 02:16:54PM +0530, Kamble, Sagar A wrote:


On 3/20/2017 1:11 PM, Chris Wilson wrote:

On Mon, Mar 20, 2017 at 11:32:15AM +0530, Sagar Arun Kamble wrote:

Due to garbage data seen by i915, gem_create_ioctl failed for gem obj
created with drmIoctl(GEM_CREATE) without properly initialized
parameters. Can be fixed by calling gem_create helper too.

Whose bug are you working around?
-Chris

Found out now that this is happening due to mismatch in the libdrm headers 
32bit/64bit flags for GEM_CREATE.
Able to resolve by properly using the proper definitions.
Will this fix be still applicable as flags would stay uninitialized with 
current call to drmIoctl?

At the moment, create.pad is never tested ergo it is valid to contain
garbage and as demonstrated that behaviour is already relied upon by
userspace.

How did the headers vary? The defintion is
struct drm_i915_gem_create {
 /**
  * Requested size for the object.
  *
  * The (page-aligned) allocated size for the object will be returned.
  */
 __u64 size;
 /**
  * Returned handle for the object.
  *
  * Object handles are nonzero.
  */
 __u32 handle;
 __u32 pad;
};
which should be 32/64bit safe. Otherwise we need a compat ioctl for the
same reason as not breaking 32bit userspace on 64bit kernel.
-Chris


This behavior is with internal Android kernel where gem_create has extra member as 
"__u64 flags"
added for stolen objects.
With pad value exception and size, handle set properly this patch does not 
apply then.





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

Re: [Intel-gfx] [i-g-t 1/1] tests/gem_gtt_hog: Clear the parameters for GEM_CREATE ioctl

[Kamble, Sagar A]

On 3/20/2017 1:11 PM, Chris Wilson wrote:

On Mon, Mar 20, 2017 at 11:32:15AM +0530, Sagar Arun Kamble wrote:

Due to garbage data seen by i915, gem_create_ioctl failed for gem obj
created with drmIoctl(GEM_CREATE) without properly initialized
parameters. Can be fixed by calling gem_create helper too.

Whose bug are you working around?
-Chris


Found out now that this is happening due to mismatch in the libdrm headers 
32bit/64bit flags for GEM_CREATE.
Able to resolve by properly using the proper definitions.
Will this fix be still applicable as flags would stay uninitialized with 
current call to drmIoctl?





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

Re: [Intel-gfx] [PATCH v6 19/23] drm/i915/slpc: Set default values for tasks and min frequency parameters

[Kamble, Sagar A]

On 3/17/2017 2:48 AM, Chris Wilson wrote:

On Thu, Mar 16, 2017 at 11:58:23PM +0530, Sagar Arun Kamble wrote:

@@ -862,6 +904,10 @@ void intel_slpc_init(struct drm_i915_private *dev_priv)
  
  	dev_priv->guc.slpc.active = false;
  
+	mutex_lock(_priv->rps.hw_lock);

+   gen6_init_rps_frequencies(dev_priv);
+   mutex_unlock(_priv->rps.hw_lock);

Maybe you shouldn't have broken it earlier?
-Chris
This change is to override SLPC defaults so tasks that are not needed 
are marked OFF and frequency limits are set with min=Rpe

Should i move this change to below commit:
drm/i915/slpc: Allocate/Release/Initialize SLPC shared data





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

Re: [Intel-gfx] [PATCH v6 06/23] drm/i915/slpc: Use intel_slpc_* functions if supported

[Kamble, Sagar A]

On 3/17/2017 2:35 AM, Chris Wilson wrote:

On Thu, Mar 16, 2017 at 11:58:10PM +0530, Sagar Arun Kamble wrote:

On platforms with SLPC support: call intel_slpc_*() functions from
intel_*_gt_powersave() functions and GuC setup functions and do not
use rps functions. intel_slpc_enable is tied to GuC setup.
With SLPC, intel_enable_gt_powersave will only handle RC6 and ring
frequencies. intel_init_gt_powersave will check if SLPC has started
running through shared data and update initial state that i915 needs
like frequency limits.
Host will not manage GT frequency with this change.

v1: 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)
 Fix for renaming gen9_disable_rps to gen9_disable_rc6 in
 "drm/i915/bxt: Explicitly clear the Turbo control register"
 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)

v2: Usage of INTEL_GEN instead of INTEL_INFO->gen (David)
 Checkpatch update.

v3: Rebase

v4: Removed reset functions to comply with *_gt_powersave routines.
 (Sagar)

v5: Removed intel_slpc_active. Relying on slpc.active for control flows
 that are based on SLPC active status in GuC. State setup/cleanup needed
 for SLPC is handled using kernel parameter i915.enable_slpc. Moved SLPC
 init and enabling to GuC enable path as SLPC in GuC can start doing the
 setup post GuC init. Commit message update. (Sagar)

v6: Rearranged function definitions.

Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/Makefile  |  3 +-
  drivers/gpu/drm/i915/i915_drv.c|  2 ++
  drivers/gpu/drm/i915/i915_gem.c|  8 +
  drivers/gpu/drm/i915/i915_guc_submission.c |  3 ++
  drivers/gpu/drm/i915/intel_pm.c| 51 --
  drivers/gpu/drm/i915/intel_slpc.c  | 46 +++
  drivers/gpu/drm/i915/intel_slpc.h  | 38 ++
  drivers/gpu/drm/i915/intel_uc.c| 11 +++
  drivers/gpu/drm/i915/intel_uc.h|  3 ++
  9 files changed, 154 insertions(+), 11 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 2cf0450..a4a8e0b 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -60,7 +60,8 @@ i915-y += intel_uc.o \
  intel_guc_log.o \
  intel_guc_loader.o \
  intel_huc.o \
- i915_guc_submission.o
+ i915_guc_submission.o \
+ intel_slpc.o

Something here is not in alphabetical order.


Yes. Will fix this.



  
  # autogenerated null render state

  i915-y += intel_renderstate_gen6.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0302d24..c0eb3d2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1762,6 +1762,8 @@ static int i915_drm_resume_early(struct drm_device *dev)
hsw_disable_pc8(dev_priv);
}
  
+	dev_priv->guc.slpc.active = false;

+
intel_uncore_sanitize(dev_priv);
  
  	if (IS_GEN9_LP(dev_priv) ||

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d87983b..db55285 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2900,6 +2900,14 @@ void i915_gem_reset(struct drm_i915_private *dev_priv)
  
  	i915_gem_restore_fences(dev_priv);
  
+	/*

+* GPU is reset at this point, Hence mark SLPC as inactive to

First sentence is redundant.


Will fix this.




+* not send h2g action to shutdown SLPC as that will fail.
+* enable_gt_powersave will setup RC6 and ring frequencies and
+* SLPC will be enabled post GuC initialization.
+*/
+   dev_priv->guc.slpc.active = false;

It suggests we should be hooking guc into the reset prepare/do/finish
more thoroughly.


Yes. Might have to rework w.r.t these flows. Will update.




+
if (dev_priv->gt.awake) {
intel_sanitize_gt_powersave(dev_priv);
intel_enable_gt_powersave(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 5ec2cbd..1c9f859 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -902,6 +902,9 @@ int 

Re: [Intel-gfx] [PATCH v6 05/23] drm/i915/slpc: Sanitize GuC version

[Kamble, Sagar A]

On 3/17/2017 2:26 AM, Chris Wilson wrote:

On Thu, Mar 16, 2017 at 11:58:09PM +0530, Sagar Arun Kamble wrote:

From: Tom O'Rourke 

The SLPC interface is dependent on GuC version.
Only GuC versions known to be compatible are supported here.

SLPC with GuC firmware v9 is supported with this series.
Other platforms and corresponding checks added later in the series.

v1: Updated with modified sanitize_slpc_option in earlier patch.

v2-v3: Rebase.

v4: Updated support for GuC firmware v9.

v5: Commit subject updated.

v6: Commit subject and message update. Add support condition as >=v9.

Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/intel_uc.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 31b90fb..1dcfbd5 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -83,6 +83,8 @@ void intel_uc_init_early(struct drm_i915_private *dev_priv)
  
  void sanitize_slpc_option(struct drm_i915_private *dev_priv)

  {
+   struct intel_uc_fw *guc_fw = _priv->guc.fw;
+
/* slpc requires hardware support and compatible firmware */
if (!HAS_SLPC(dev_priv))
i915.enable_slpc = 0;
@@ -94,6 +96,11 @@ void sanitize_slpc_option(struct drm_i915_private *dev_priv)
/* slpc requires guc submission */
if (!i915.enable_guc_submission)
i915.enable_slpc = 0;
+
+   if (guc_fw->major_ver_found < 9) {
+   DRM_INFO("SLPC not supported with current GuC firmware\n");

Say the actual version found, the requirement and the likely consequence.
Is it important enough to direct the user to 01.org?
-Chris

Ok. Will update this. Will add details of firmware needed from 01.org.

Thanks
Sagar




___
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 Add support for GuC-based SLPC (rev7)

[Kamble, Sagar A]

Apologies for this erroneous patch.

My .config did not have CONFIG_DRM_I915_WERROR set so did not catch.

Should have let this through trybot for this change.

On 3/16/2017 10:53 PM, Patchwork wrote:

== Series Details ==

Series: Add support for GuC-based SLPC (rev7)
URL   : https://patchwork.freedesktop.org/series/2691/
State : failure

== Summary ==

   CC [M]  drivers/gpu/drm/i915/gvt/gvt.o
   CC [M]  drivers/gpu/drm/i915/gvt/trace_points.o
   CC [M]  drivers/gpu/drm/i915/gvt/vgpu.o
   LD  drivers/pci/pcie/aer/aerdriver.o
   CC [M]  drivers/gpu/drm/i915/gvt/firmware.o
   CC [M]  drivers/gpu/drm/i915/gvt/interrupt.o
   CC [M]  drivers/gpu/drm/i915/gvt/gtt.o
   CC [M]  drivers/gpu/drm/i915/gvt/cfg_space.o
   LD  net/packet/built-in.o
   CC [M]  drivers/gpu/drm/i915/gvt/opregion.o
   CC [M]  drivers/gpu/drm/i915/gvt/mmio.o
   CC [M]  drivers/gpu/drm/i915/gvt/display.o
   CC [M]  drivers/gpu/drm/i915/gvt/execlist.o
   LD  drivers/pci/pcie/aer/built-in.o
   CC [M]  drivers/gpu/drm/i915/gvt/edid.o
   CC [M]  drivers/gpu/drm/i915/gvt/scheduler.o
   CC [M]  drivers/gpu/drm/i915/gvt/sched_policy.o
   CC [M]  drivers/gpu/drm/i915/gvt/render.o
   CC [M]  drivers/gpu/drm/i915/intel_lpe_audio.o
   CC [M]  drivers/gpu/drm/i915/gvt/cmd_parser.o
   LD  drivers/pci/pcie/built-in.o
   LD  sound/built-in.o
   LD  kernel/sched/built-in.o
   LD  kernel/built-in.o
   LD  drivers/tty/serial/8250/8250.o
   LD [M]  drivers/net/ethernet/broadcom/genet/genet.o
   LD  net/xfrm/built-in.o
   LD [M]  drivers/gpu/drm/vgem/vgem.o
   LD  drivers/usb/storage/usb-storage.o
   LD  drivers/usb/storage/built-in.o
   AR  lib/lib.a
   EXPORTS lib/lib-ksyms.o
   LD  lib/built-in.o
   LD [M]  drivers/usb/serial/usbserial.o
   LD  drivers/thermal/thermal_sys.o
   LD  drivers/thermal/built-in.o
drivers/gpu/drm/i915/intel_slpc.c:47:5: error: initializer-string for array of 
chars is too long [-Werror]
  "If non-zero, algorithm will slow down "
  ^
drivers/gpu/drm/i915/intel_slpc.c:47:5: note: (near initialization for 
‘slpc_paramlist[10].name’)
   LD  net/ipv6/ipv6.o
   LD  net/ipv6/built-in.o
   LD  drivers/gpu/drm/drm.o
   LD [M]  drivers/net/ethernet/intel/igbvf/igbvf.o
   LD  drivers/usb/gadget/udc/udc-core.o
   LD  drivers/usb/gadget/udc/built-in.o
   LD  drivers/tty/serial/8250/8250_base.o
   LD  drivers/tty/serial/8250/built-in.o
   LD  drivers/tty/serial/built-in.o
cc1: all warnings being treated as errors
scripts/Makefile.build:294: recipe for target 
'drivers/gpu/drm/i915/intel_slpc.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_slpc.o] Error 1
make[4]: *** Waiting for unfinished jobs
   LD  drivers/video/fbdev/core/fb.o
   LD  drivers/usb/gadget/libcomposite.o
   LD  drivers/video/fbdev/core/built-in.o
   LD  drivers/usb/gadget/built-in.o
   LD  drivers/video/fbdev/built-in.o
   LD  drivers/spi/built-in.o
   LD  fs/btrfs/btrfs.o
   LD  drivers/iommu/built-in.o
   LD  drivers/tty/vt/built-in.o
   LD  drivers/scsi/scsi_mod.o
   LD  fs/btrfs/built-in.o
   LD  drivers/tty/built-in.o
   LD  drivers/pci/built-in.o
   LD  drivers/video/console/built-in.o
   LD  drivers/video/built-in.o
   LD [M]  drivers/net/ethernet/intel/e1000/e1000.o
   LD  net/ipv4/built-in.o
   LD  drivers/usb/core/usbcore.o
   LD  drivers/scsi/sd_mod.o
   LD  drivers/scsi/built-in.o
   LD  drivers/usb/core/built-in.o
   CC  arch/x86/kernel/cpu/capflags.o
   LD  arch/x86/kernel/cpu/built-in.o
   LD  arch/x86/kernel/built-in.o
   LD  net/core/built-in.o
   LD  arch/x86/built-in.o
   LD  net/built-in.o
   LD  drivers/md/md-mod.o
   LD  drivers/md/built-in.o
   LD  fs/ext4/ext4.o
   LD  fs/ext4/built-in.o
   LD  fs/built-in.o
   LD  drivers/usb/host/xhci-hcd.o
   LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
   LD [M]  drivers/net/ethernet/intel/igb/igb.o
   LD  drivers/usb/host/built-in.o
   LD  drivers/usb/built-in.o
   LD  drivers/net/ethernet/built-in.o
   LD  drivers/net/built-in.o
scripts/Makefile.build:553: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:553: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:553: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1002: recipe for target 'drivers' failed
make: *** [drivers] Error 2

___
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] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/guc: Release GuC interrupts in i915_guc_submission_disable

[Kamble, Sagar A]

On 3/13/2017 3:17 PM, Chris Wilson wrote:

On Mon, Mar 13, 2017 at 10:28:34AM +0530, Kamble, Sagar A wrote:


On 3/12/2017 6:29 PM, Chris Wilson wrote:

On Sat, Mar 11, 2017 at 04:17:34AM -, Patchwork wrote:

== Series Details ==

Series: series starting with [1/3] drm/i915/guc: Release GuC interrupts in 
i915_guc_submission_disable
URL   : https://patchwork.freedesktop.org/series/21090/
State : success

== Summary ==

Series 21090v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/21090/revisions/1/mbox/

Test kms_pipe_crc_basic:
 Subgroup hang-read-crc-pipe-b:
 dmesg-warn -> PASS   (fi-byt-j1900)

Applied, thanks for the quick fix. It is looking much neater now as well
:)
-Chris

Thanks Chris.
I feel unmasking of ARAT_EXPIRED is hard coding the behavior with GuC.
Ideally rps enabling should happen post GuC load in reset path like in load 
time flow.

The catch though is that we don't go through a rps disable sequence
point across reset. We might be able to do an explict disable/enable
pair now.


Yes.




That way instead of hard coding interrupts to be kept as ARAT_EXPIRED we will 
be able to derive from bits unmasked by GuC in PMINTRMSK.
So before GuC load, we should be resetting RPS interrupts (making PMINRMSK=~0u) 
and then derive interrupts to be kept unmasked by Host.
And then enable RPS. Current state is fine as we know GuC isn't using other PM 
interrupts. (might use some of those in SLPC)

But the set of bits used by guc will be fixed depending on what mode we
are in, and should already be setup by time we reset. You just have a
slightly more elaborate guc interrupts enable/disable sequence, I don't
see that as making anything simpler or more elegant yet - but anticipate
enlightenment.
-Chris


Agree that bits used will be fixed and no need to dynamically determine.
Other bits if needed will be configured by GuC SLPC and in that case Host
RPS flows will not update the registers. So the current implementation looks 
fine.

Thanks
Sagar


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

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/guc: Release GuC interrupts in i915_guc_submission_disable

[Kamble, Sagar A]

On 3/12/2017 6:29 PM, Chris Wilson wrote:

On Sat, Mar 11, 2017 at 04:17:34AM -, Patchwork wrote:

== Series Details ==

Series: series starting with [1/3] drm/i915/guc: Release GuC interrupts in 
i915_guc_submission_disable
URL   : https://patchwork.freedesktop.org/series/21090/
State : success

== Summary ==

Series 21090v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/21090/revisions/1/mbox/

Test kms_pipe_crc_basic:
 Subgroup hang-read-crc-pipe-b:
 dmesg-warn -> PASS   (fi-byt-j1900)

Applied, thanks for the quick fix. It is looking much neater now as well
:)
-Chris


Thanks Chris.
I feel unmasking of ARAT_EXPIRED is hard coding the behavior with GuC.
Ideally rps enabling should happen post GuC load in reset path like in load 
time flow.
That way instead of hard coding interrupts to be kept as ARAT_EXPIRED we will 
be able to derive from bits unmasked by GuC in PMINTRMSK.
So before GuC load, we should be resetting RPS interrupts (making PMINRMSK=~0u) 
and then derive interrupts to be kept unmasked by Host.
And then enable RPS. Current state is fine as we know GuC isn't using other PM 
interrupts. (might use some of those in SLPC)





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

Re: [Intel-gfx] [PATCH] drm/i915: Rename REDIRECT_TO_GUC bit

[Kamble, Sagar A]

LGTM.
Reviewed-by: Sagar Arun Kamble

PS: Might need updating comments in the guc_interrupts_capture to align with 
new name and semantics of this bit
w.r.t pm_intrmsk_mbz.

On 3/12/2017 6:57 PM, Chris Wilson wrote:

The REDIRECT_TO_GUC bit is a strange beast as it is a disable bit -
setting the bit in the pm interrupt generation stops the interrupt going
to the guc (not sending it to the guc as the name implies). To help the
reader rename it to DISABLE_REDIRECT_TO_GUC so that we keep the bspec
greppable name without it being as confusing!

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Oscar Mateo 
Cc: Radoslaw Szwichtenberg 
Cc: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 4 ++--
  drivers/gpu/drm/i915/i915_irq.c| 2 +-
  drivers/gpu/drm/i915/i915_reg.h| 2 +-
  3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index ca7723fd0f79..84fd49d5680e 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -975,7 +975,7 @@ static void guc_interrupts_capture(struct drm_i915_private 
*dev_priv)
 * result in the register bit being left SET!
 */
dev_priv->rps.pm_intrmsk_mbz |= ARAT_EXPIRED_INTRMSK;
-   dev_priv->rps.pm_intrmsk_mbz &= ~GEN8_PMINTR_REDIRECT_TO_GUC;
+   dev_priv->rps.pm_intrmsk_mbz &= ~GEN8_PMINTR_DISABLE_REDIRECT_TO_GUC;
  }
  
  int i915_guc_submission_enable(struct drm_i915_private *dev_priv)

@@ -1037,7 +1037,7 @@ static void guc_interrupts_release(struct 
drm_i915_private *dev_priv)
I915_WRITE(GUC_VCS2_VCS1_IER, 0);
I915_WRITE(GUC_WD_VECS_IER, 0);
  
-	dev_priv->rps.pm_intrmsk_mbz |= GEN8_PMINTR_REDIRECT_TO_GUC;

+   dev_priv->rps.pm_intrmsk_mbz |= GEN8_PMINTR_DISABLE_REDIRECT_TO_GUC;
dev_priv->rps.pm_intrmsk_mbz &= ~ARAT_EXPIRED_INTRMSK;
  
  }

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a522da712cc8..89ccf3e1fda5 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4282,7 +4282,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
dev_priv->rps.pm_intrmsk_mbz |= GEN6_PM_RP_UP_EI_EXPIRED;
  
  	if (INTEL_INFO(dev_priv)->gen >= 8)

-   dev_priv->rps.pm_intrmsk_mbz |= GEN8_PMINTR_REDIRECT_TO_GUC;
+   dev_priv->rps.pm_intrmsk_mbz |= 
GEN8_PMINTR_DISABLE_REDIRECT_TO_GUC;
  
  	if (IS_GEN2(dev_priv)) {

/* Gen2 doesn't have a hardware frame counter */
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 19d42e8813c4..5d88c35c41cd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7453,7 +7453,7 @@ enum {
  #define VLV_RCEDATA   _MMIO(0xA0BC)
  #define GEN6_RC6pp_THRESHOLD  _MMIO(0xA0C0)
  #define GEN6_PMINTRMSK_MMIO(0xA168)
-#define   GEN8_PMINTR_REDIRECT_TO_GUC  (1<<31)
+#define   GEN8_PMINTR_DISABLE_REDIRECT_TO_GUC  (1<<31)
  #define   ARAT_EXPIRED_INTRMSK(1<<9)
  #define GEN8_MISC_CTRL0   _MMIO(0xA180)
  #define VLV_PWRDWNUPCTL   _MMIO(0xA294)


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

Re: [Intel-gfx] [PATCH] drm/i915: Include GuC fw version in error state

[Kamble, Sagar A]

On 2/24/2017 4:19 PM, Chris Wilson wrote:

On Fri, Feb 24, 2017 at 11:43:32AM +0100, Michal Wajdeczko wrote:

On Fri, Feb 24, 2017 at 09:13:29AM +, Chris Wilson wrote:

On Fri, Feb 24, 2017 at 09:13:05AM +0530, Kamble, Sagar A wrote:

Reviewed-by: Sagar Arun Kamble [1]<sagar.a.kam...@intel.com>

On 2/24/2017 4:41 AM, Michel Thierry wrote:

  There was no way to check if the platform is running the latest firmware.

  Cc: Tvrtko Ursulin [2]<tvrtko.ursu...@intel.com>
  Cc: Arkadiusz Hiler [3]<arkadiusz.hi...@intel.com>
  Signed-off-by: Michel Thierry [4]<michel.thie...@intel.com>
  ---
   drivers/gpu/drm/i915/i915_gpu_error.c | 10 ++
   1 file changed, 10 insertions(+)

  diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
  index 2b1d15668192..e022187916ee 100644
  --- a/drivers/gpu/drm/i915/i915_gpu_error.c
  +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
  @@ -632,6 +632,16 @@ int i915_error_state_to_str(struct 
drm_i915_error_state_buf *m,
 CSR_VERSION_MINOR(csr->version));
  }

  +   if (HAS_GUC_UCODE(dev_priv)) {
  +   struct intel_uc_fw *guc_fw = _priv->guc.fw;
  +
  +   err_printf(m, "GuC loaded: %s\n",
  +  yesno(guc_fw->load_status ==
  +INTEL_UC_FIRMWARE_SUCCESS));
  +   err_printf(m, "GuC fw version: %d.%d\n",
  +  guc_fw->major_ver_found, guc_fw->minor_ver_found);
  +   }
  +

Hmm. The firmware may change between the hang and cat
/sys/class/drm/card0/error (as it will be reloaded after the reset).

Btw, maybe we should add counter that will be incremented on each fw reload
and reported here ?

If it occurs to you that we need it for post-mortem debugging and having
it is worth more than any potential confusion

I can see the need for knowing what guc/huc/dmc/etc was running at the
time of a hang - I just hope that what was previously running before an
earlier reset doesn't contribute. But that's why we focus on the first
error in a system...
-Chris

GT reset count is present already in error state. GuC kernel parameters 
are present and this

change will help us identify which firmware issue was encountered.
So I feel printing ver_found should be enough.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Include GuC fw version in error state

[Kamble, Sagar A]

Reviewed-by: Sagar Arun Kamble 

On 2/24/2017 4:41 AM, Michel Thierry wrote:

There was no way to check if the platform is running the latest firmware.

Cc: Tvrtko Ursulin 
Cc: Arkadiusz Hiler 
Signed-off-by: Michel Thierry 
---
  drivers/gpu/drm/i915/i915_gpu_error.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 2b1d15668192..e022187916ee 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -632,6 +632,16 @@ int i915_error_state_to_str(struct 
drm_i915_error_state_buf *m,
   CSR_VERSION_MINOR(csr->version));
}
  
+	if (HAS_GUC_UCODE(dev_priv)) {

+   struct intel_uc_fw *guc_fw = _priv->guc.fw;
+
+   err_printf(m, "GuC loaded: %s\n",
+  yesno(guc_fw->load_status ==
+INTEL_UC_FIRMWARE_SUCCESS));
+   err_printf(m, "GuC fw version: %d.%d\n",
+  guc_fw->major_ver_found, guc_fw->minor_ver_found);
+   }
+
err_printf(m, "EIR: 0x%08x\n", error->eir);
err_printf(m, "IER: 0x%08x\n", error->ier);
for (i = 0; i < error->ngtier; i++)


___
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: Handle validation of relocation object with length >=2GB

[Kamble, Sagar A]

On 2/13/2017 6:03 PM, Chris Wilson wrote:

On Mon, Feb 13, 2017 at 02:25:29PM +0200, Joonas Lahtinen wrote:

On ma, 2017-02-13 at 11:02 +, Chris Wilson wrote:

On Mon, Feb 13, 2017 at 12:58:57PM +0200, Joonas Lahtinen wrote:

On ma, 2017-02-13 at 12:14 +0530, Sagar Arun Kamble wrote:

From: "sagar.a.kam...@intel.com" 

With prefaulting extended to support >=2GB, i915 can handle
relocation objects >=2GB. type conversion of length from int to
unsigned long in access_ok was making the validation bail out with
-EFAULT.

Testcase: igt/gem_exec_reloc/wc-31
Cc: Daniel Vetter 
Cc: Chris Wilson 
Signed-off-by: Sagar Arun Kamble 

With the correct "From:" and with "size_t" as type, this is;

Reviewed-by: Joonas Lahtinen 

My earlier comments still apply in that this is not how I fixed this
years ago, and I still much prefer my fix.

Where are the earlier comments? I must have missed them.

I replied to the first time this patch landed in my inbox, which might
have been trybotted.
-Chris
Chris, I thought those comments were about relocs_total and relocs_max 
values.

Pasting below inputs from trybot.


The abi is limited to 32b max relocs.

Please see
https://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=prescheduler=bcf3bca07f21a4c0c754ccecca81228c28437906
(a patch that is years overdue) in which this just evaporates.
-Chris
-



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

Re: [Intel-gfx] [PATCH 1/2] mm: Handle prefault for size >= 2GB

[Kamble, Sagar A]

On 2/13/2017 4:18 PM, Joonas Lahtinen wrote:

On ma, 2017-02-13 at 12:14 +0530, Sagar Arun Kamble wrote:

From: "sagar.a.kam...@intel.com" 

https://kernel.org/doc/html/latest/process/submitting-patches.html#the-
canonical-patch-format

# git config --global user.name "Sagar Arun Kamble"
Thanks Joonas. Even though ~/.gitconfig has user.name set properly 
"From" is not getting set properly.

Will find out the problem.



i915 gem_exec_reloc subtests *-31 exercise relocation entries object
that is of size >=2GB. This patch will allow prefaulting >=2GB size.

Cc: Daniel Vetter 
Cc: Chris Wilson 
Signed-off-by: Sagar Arun Kamble 




@@ -538,7 +538,8 @@ static inline void wait_on_page_writeback(struct page *page)
  /*
   * Fault everything in given userspace address range in.
   */
-static inline int fault_in_pages_writeable(char __user *uaddr, int size)
+static inline int fault_in_pages_writeable(char __user *uaddr,
+  unsigned long size)
  {
char __user *end = uaddr + size - 1;

ptrdiff_t would be more appropriate for both functions. With those and
correct "From:", this is;

Reviewed-by: Joonas Lahtinen 

Regards, Joonas


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

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915: Do RPM Wake during GuC/HuC status read

[Kamble, Sagar A]

On 2/4/2017 7:40 PM, Arkadiusz Hiler wrote:

On Fri, Feb 03, 2017 at 01:58:33PM +0530, Sagar Arun Kamble wrote:

HUC_STATUS, GUC_STATUS, SOFT_SCRATCH registers are read in debugfs
and getparam ioctl. This patch covers those accesses by RPM get/put.

v2: Covering access in i915_getparam(I915_PARAM_HUC_STATUS) (ChrisW)

Cc: Arkadiusz Hiler 
Cc: Anusha Srivatsa 
Cc: Fiedorowicz, Lukasz 
Signed-off-by: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 6 ++
  drivers/gpu/drm/i915/i915_drv.c | 5 ++---
  2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3ae0656..639ed12 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2374,7 +2374,9 @@ static int i915_huc_load_status_info(struct seq_file *m, 
void *data)
seq_printf(m, "\tRSA: offset is %d; size = %d\n",
huc_fw->rsa_offset, huc_fw->rsa_size);
  
+	intel_runtime_pm_get(dev_priv);

seq_printf(m, "\nHuC status 0x%08x:\n", I915_READ(HUC_STATUS2));
+   intel_runtime_pm_put(dev_priv);
  
  	return 0;

  }

Are you sure that HUC_STATUS2 requires RPM get for reading?

I remember trying reading it with device forcefully asleep and it
succeed just fine.

Hi Arek,

Faced following warning with device runtime_status=suspended.
Also this register lies in media forcewake range and should have similar 
RPM get/put needs as other registers unless this has special behavior I 
am not aware of.


[  153.923576] WARNING: CPU: 1 PID: 1859 at 
drivers/gpu/drm/i915/intel_drv.h:1698 gen9_decoupled_read32+0x1a1/0x1c0 
[i915]

[  153.923578] Device suspended during HW access
[  153.923580] Modules linked in: spi_pxa2xx_platform 8250_dw 
i2c_designware_platform i2c_designware_core intel_rapl 
intel_telemetry_debugfs intel_telemetry_pltdrv intel_punit_ipc 
intel_telemetry_core x86_pkg_temp_thermal binfmt_misc coretemp kvm_intel 
snd_soc_skl kvm snd_soc_rt298 snd_soc_skl_ipc snd_soc_rt286 
snd_soc_sst_ipc snd_soc_rl6347a snd_soc_sst_dsp snd_hda_ext_core 
snd_soc_sst_match irqbypass nls_iso8859_1 crct10dif_pclmul crc32_pclmul 
ghash_clmulni_intel pcbc snd_hda_codec_hdmi snd_hda_intel snd_hda_codec 
snd_hda_core snd_soc_core snd_hwdep aesni_intel snd_compress aes_x86_64 
ac97_bus crypto_simd snd_pcm_dmaengine glue_helper cryptd snd_pcm 
intel_rapl_perf snd_seq_midi snd_seq_midi_event wdat_wdt snd_rawmidi 
input_leds serio_raw snd_seq pwm_lpss_pci pwm_lpss snd_seq_device 
snd_timer idma64
[  153.923671]  virt_dma intel_lpss_pci intel_lpss snd 
hid_sensor_accel_3d hid_sensor_magn_3d hid_sensor_als hid_sensor_gyro_3d 
hid_sensor_incl_3d hid_sensor_rotation hid_sensor_press 
hid_sensor_trigger mei_me industrialio_triggered_buffer kfifo_buf 
hid_sensor_iio_common industrialio mei soundcore shpchp rfkill_gpio 
soc_button_array intel_vbtn tpm_crb ucsi intel_hid intel_pmc_ipc 
sparse_keymap mac_hid autofs4 hid_generic usbhid hid_sensor_custom 
hid_sensor_hub intel_ishtp_hid i915(E) drm_kms_helper syscopyarea 
psmouse igb sysfillrect sdhci_pci sysimgblt fb_sys_fops sdhci dca ptp 
drm pps_core ahci intel_ish_ipc i2c_algo_bit libahci intel_ishtp i2c_hid 
hid video fjes pinctrl_broxton pinctrl_intel
[  153.923768] CPU: 1 PID: 1859 Comm: cat Tainted: G U  W   E 
4.10.0-rc6-ww5.5mainlinestaging #12
[  153.923771] Hardware name: Intel Corp. Broxton P/Apollolake RVP1C, 
BIOS APLIRVPA.X64.0151.B24.1609210905 09/21/2016

[  153.923773] Call Trace:
[  153.923785]  dump_stack+0x63/0x90
[  153.923791]  __warn+0xd1/0xf0
[  153.923795]  warn_slowpath_fmt+0x4f/0x60
[  153.923803]  ? seq_vprintf+0x35/0x50
[  153.923893]  gen9_decoupled_read32+0x1a1/0x1c0 [i915]
[  153.923969]  i915_huc_load_status_info+0x132/0x150 [i915]
[  153.923974]  seq_read+0x119/0x3e0
[  153.923981]  full_proxy_read+0x51/0x80
[  153.923988]  __vfs_read+0x28/0x130
[  153.923993]  ? security_file_permission+0x9d/0xc0
[  153.923998]  ? rw_verify_area+0x4e/0xb0
[  153.924003]  vfs_read+0x93/0x130
[  153.924009]  SyS_read+0x46/0xa0
[  153.924015]  entry_SYSCALL_64_fastpath+0x1e/0xad
[  153.924019] RIP: 0033:0x7fe18cd44680
[  153.924022] RSP: 002b:7ffe7d991eb8 EFLAGS: 0246 ORIG_RAX: 

[  153.924027] RAX: ffda RBX: 7fe18d011b20 RCX: 
7fe18cd44680
[  153.924030] RDX: 0002 RSI: 7fe18d1fb000 RDI: 
0003
[  153.924032] RBP: 00021010 R08:  R09: 

[  153.924035] R10: 037b R11: 0246 R12: 
00022000
[  153.924037] R13: 7fe18d011b78 R14: 1000 R15: 
0002

[  153.924042] ---[ end trace 6529f5b46f5753d0 ]---
[  153.974135] [drm:__gen9_decoupled_mmio_access [i915]] *ERROR* 
Decoupled MMIO wait timed out






___
Intel-gfx mailing list

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Do RPM Wake during GuC/HuC status read

[Kamble, Sagar A]

On 2/3/2017 1:07 PM, Chris Wilson wrote:

On Fri, Feb 03, 2017 at 01:00:18PM +0530, Sagar Arun Kamble wrote:

HUC_STATUS, GUC_STATUS, SOFT_SCRATCH  registers are read in debugfs.
This patch covers those accesses by RPM get/put.

See also I915_PARAM_HUC_STATUS.
Yes. Will update this. Daniel had commented that this was broken. Will 
float rev2



Cc: Arkadiusz Hiler 
Cc: Anusha Srivatsa 
Signed-off-by: Sagar Arun Kamble 

Testcase? There's definitely at least one that should be covering this.

Did you mean testcase to verify GuC/HuC load status and param value?

-Chris



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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Reserve the upper end of the Global GTT for the GuC

[Kamble, Sagar A]

On 12/22/2016 2:40 AM, Daniele Ceraolo Spurio wrote:



On 21/12/16 06:11, Chris Wilson wrote:

The GuC would like to own the upper portion of the GTT for itself, so
exclude it from our drm_mm to prevent us using it.


I had a quick chat with a GuC dev and he is pretty sure that GuC can't 
reserve any GTT areas for itself (and that is why we do the allocation 
for the buffers the GuC uses). However, it looks like the offsets 
above 0xFEE0 are reserved internally from the GuC point of view 
for some private resources, similarly to what happens for the offsets 
below GUC_WOPCM_TOP. This means that we should be able to actually use 
those offsets from the host side, but we can't pass any object placed 
there to GuC. The GuC FW will drop any operation on objects placed 
above 0xFEE0, which may be what caused the issues with 
guc_submission (not sure of this since I haven't seen the report).
golden_context_lrca, reg_state, reg_state_buffer addresses in ADS that 
makes GuC load fail:

[4.955330] [drm:i915_guc_submission_init [i915]]  fffe7000 8542c8 854b18

With this patch applied golden_context_lrca gets placed properly and GuC 
load succeeds.

[4.953817] [drm:i915_guc_submission_init [i915]]  fede7000 8542c8 854b18
The fix below might still be ok for us as reducing the GGTT size by a 
small amount shouldn't be a big issue, but I'd prefer the comment and 
the commit message to be updated.


To also reply to Michal question, I was told that the region size is 
fixed and not FW dependent.


Thanks,
Daniele



Signed-off-by: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Arkadiusz Hiler 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c   | 5 +
 drivers/gpu/drm/i915/intel_guc_fwif.h | 3 +++
 2 files changed, 8 insertions(+)

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

index 6af9311f72f5..96bc0e83286a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3176,6 +3176,11 @@ int i915_ggtt_probe_hw(struct drm_i915_private 
*dev_priv)

 if (ret)
 return ret;

+if (HAS_GUC_SCHED(dev_priv)) {
+ggtt->base.total -= GUC_GGTT_RESERVED_TOP;
+ggtt->mappable_end = min(ggtt->mappable_end, ggtt->base.total);
+}
+
 if ((ggtt->base.total - 1) >> 32) {
 DRM_ERROR("We never expected a Global GTT with more than 
32bits"

   " of address space! Found %lldM!\n",
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h

index 3202b32b5638..3361d38ed859 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -23,6 +23,9 @@
 #ifndef _INTEL_GUC_FWIF_H
 #define _INTEL_GUC_FWIF_H

+/* A small region at the top of the global GTT is reserved for use 
by the GuC */

+#define GUC_GGTT_RESERVED_TOP0x120
+
 #define GFXCORE_FAMILY_GEN912
 #define GFXCORE_FAMILY_UNKNOWN0x7fff



___
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] drm/i915/guc: Do not bypass forcewakes in i915_guc_submit

[Kamble, Sagar A]

On 11/17/2016 3:06 PM, Tvrtko Ursulin wrote:


On 17/11/2016 09:28, Chris Wilson wrote:

On Thu, Nov 17, 2016 at 09:17:35AM +, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Commit ed4596ea992d ("drm/i915/guc: WA to address the Ringbuffer
coherency issue"), based on incorrect assumptions from a partialy
broken commit 0dd356bb6ff5 ("drm/i915: Eliminate Gen9 special
case") used POSTING_READ_FW instead of the POSTING_READ. With the
latter buggy commit fixed this call site needs fixing as well.


The theory here is that we don't need the powerwell to force the write
from CPU to be visible before another agent.

I missed the report, so I am genuinely interested in knowing whether the
theory about the write being posted without the powerwll.


Just that the commit message for the patch used "guc registers are not 
in any forcewake domain" reasoning, which was false - based on a 
partially broken patch. See "drm/i915: Fix gen9 forcewake range table".


Regards,

Tvrtko


Verified this fix without forcewake, so this patch will not be needed.
Have couple of queries. Chris, could you please clarify:
1. why POSTING_READ is done in flush_gtt_write_domain and not 
POSTING_READ_FW like this case?

2. how does read from forcewake mmio range work if well is down?

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

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Give write permission to gt_boost_freq_mhz

[Kamble, Sagar A]

Hi Daniel, Chris,


Sorry for not clarifying the purpose and if any misunderstanding.
This was to allow running at fixed frequency.

Kindly clarify if it is intentional to have _store routine without S_IWUSR.

On 10/24/2016 2:42 PM, Chris Wilson wrote:

On Mon, Oct 24, 2016 at 11:05:13AM +0200, Daniel Vetter wrote:

On Mon, Oct 24, 2016 at 10:00:49AM +0530, Sagar Arun Kamble wrote:

And uabi change with 0 commit message. This needs to be _much_ better ;-)

A case where the author cut'n'paste the wrong thing because he can't
read S_INCOMPREHENSIBLELINENOISE as opposed to the traditional 0600.
-Chris



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

Re: [Intel-gfx] [PATCH v4 25/26] drm/i915: Add sysfs interface to know the HW requested frequency

[Kamble, Sagar A]

On 9/9/2016 10:13 PM, Chris Wilson wrote:

On Fri, Sep 09, 2016 at 06:21:44PM +0530, Sagar Arun Kamble wrote:

With SLPC, user can read this value to know SLPC requested frequency.

Not SLPC specific, even elsewhere there may be a delay between the cur
value and the req (just means something more on SLPC).
cur_freq is updated whenever RPNSWREQ is written so they should be same 
right?

Where will delay come into picture?


Though I'm never keen on expanding the stable ABI, I can't object to
this given the existence of the others - but I will ask for a use case
other than debug.

For testing SLPC requests from Host side we have to rely on read of RPNSWREQ

-Chris



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

Re: [Intel-gfx] [PATCH v4 23/26] drm/i915/slpc: Keep RP SW Mode enabled while disabling rps

[Kamble, Sagar A]

On 9/9/2016 10:28 PM, Chris Wilson wrote:

On Fri, Sep 09, 2016 at 06:21:42PM +0530, Sagar Arun Kamble wrote:

With SLPC, only RP SW Mode control should be left enabled by i915.
Else, SLPC requests through through RPNSWREQ will not be granted.

Signed-off-by: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/intel_pm.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 70e08d9..d06c9bb 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5064,7 +5064,13 @@ 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);
+   uint32_t rp_ctl = 0;

u32 rp_ctl = 0;


+
+   /* RP SW Mode Control will be needed for SLPC, Hence not clearing.*/

/* RP SW Mode Control will be needed for SLPC, so keep it enabled. */


+   if (i915.enable_slpc)

intel_slpc_enabled() ? (consistency!)

Will update this.



+   rp_ctl = I915_READ(GEN6_RP_CONTROL) & GEN6_RP_MEDIA_MODE_MASK;

Ok, so this is not doing what you describe. This is preserving state,
yes. But if we know that state is meant to be enabled for SLPC why are
we reading it back.

I am left with questions about what is happening behind our backs, and
what the code is trying to hide.
Will fix this. SLPC is going to request frequency hence we need to make 
sure host

does not tamper RP_CONTROL settings.

-Chris



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

Re: [Intel-gfx] [PATCH v4 24/26] drm/i915/slpc: Enable SLPC, where supported

[Kamble, Sagar A]

On 9/9/2016 10:15 PM, Chris Wilson wrote:

On Fri, Sep 09, 2016 at 06:21:43PM +0530, Sagar Arun Kamble wrote:

From: Tom O'Rourke 

This patch makes SLPC enabled by default on
platforms with hardware/firmware support.

v1: 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 6e24e60..e9e1163 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);

Remove this from the original path, and make it return a bool, since
i915.enable_slpc is always sanitized.

The this patch simply becomes flipping the switch.

Will update this.

-Chris



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

Re: [Intel-gfx] [PATCH v4 18/26] drm/i915/slpc: Add i915_slpc_info to debugfs

[Kamble, Sagar A]

On 9/9/2016 10:44 PM, Chris Wilson wrote:

On Fri, Sep 09, 2016 at 06:21:37PM +0530, Sagar Arun Kamble wrote:

+   if (!intel_slpc_active(dev_priv))
+   return -ENODEV;

Can we really say slpc is active without an slpc.vma?

No. Will remove this check.

-Chris



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

Re: [Intel-gfx] [PATCH v4 16/26] drm/i915/slpc: Add slpc support for max/min freq

[Kamble, Sagar A]

On 9/9/2016 10:19 PM, Chris Wilson wrote:

On Fri, Sep 09, 2016 at 06:21:35PM +0530, Sagar Arun Kamble wrote:

From: Tom O'Rourke 

Update sysfs and debugfs functions to set SLPC
parameters when setting max/min frequency.

v1: 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 71bce32..0956d1f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4873,6 +4873,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));

Hmm, there are a lot of these casts. Why?

Changing intel_gpu_freq(), intel_freq_opcode() to take and return
unsigned would help.

will fix this

-Chris



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

Re: [Intel-gfx] [PATCH v4 17/26] drm/i915/slpc: Add enable/disable debugfs for slpc

[Kamble, Sagar A]

On 9/9/2016 10:24 PM, Chris Wilson wrote:

On Fri, Sep 09, 2016 at 06:21:36PM +0530, Sagar Arun Kamble wrote:

+static ssize_t slpc_dcc_write(struct file *file, const char __user *ubuf,
+ size_t len, loff_t *offp)
+{
+   struct seq_file *m = file->private_data;
+   int ret = 0;
+
+   ret = slpc_param_write(m, ubuf, len, SLPC_PARAM_TASK_ENABLE_DCC,
+  SLPC_PARAM_TASK_DISABLE_DCC);
+   if (ret)
+   return (size_t) ret;

What value is (ssize_t)(size_t)-1 as seen by userspace? Is it negative?

Will fix this. casting is not needed.

-Chris



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

Re: [Intel-gfx] [PATCH v4 11/26] drm/i915/slpc: Update sysfs/debugfs interfaces for frequency parameters

[Kamble, Sagar A]

On 9/9/2016 10:43 PM, Chris Wilson wrote:

On Fri, Sep 09, 2016 at 06:21:30PM +0530, Sagar Arun Kamble wrote:

From: Tom O'Rourke 

When SLPC is controlling requested frequency, the rps.cur_freq
value is not used to make the frequency request.

Requested frequency from register RPNSWREQ has the value
most recently requested by SLPC firmware. Adding new sysfs
interface gt_req_freq_mhz to know this value.
SLPC requested value needs to be made available to i915 without
reading RPNSWREQ.

v1: Replace HAS_SLPC with intel_slpc_active (Paulo)
 Avoid magic numbers (Nick)
 Use a function for repeated code (Jon)

v2: Add "SLPC Active" to i915_frequency_info output and
 don't update cur_freq as it is driver internal request. (Chris)

v3: Removing sysfs interface gt_req_freq_mhz out of this patch
 for proper division of functionality. (Sagar)

v4: idle_freq, boost_freq are also not used with SLPC.

Signed-off-by: Tom O'Rourke 
Signed-off-by: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 24 ++--
  drivers/gpu/drm/i915/i915_sysfs.c   |  3 +++
  2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 02b627e..71bce32 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1083,6 +1083,9 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
  
  	intel_runtime_pm_get(dev_priv);
  
+	if (intel_slpc_active(dev_priv))

+   seq_puts(m, "SLPC Active\n");
+
if (IS_GEN5(dev_priv)) {
u16 rgvswctl = I915_READ16(MEMSWCTL);
u16 rgvstat = I915_READ16(MEMSTAT_ILK);
@@ -1250,15 +1253,21 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
seq_printf(m, "Max overclocked frequency: %dMHz\n",
   intel_gpu_freq(dev_priv, dev_priv->rps.max_freq));
  
-		seq_printf(m, "Current freq: %d MHz\n",

-  intel_gpu_freq(dev_priv, dev_priv->rps.cur_freq));
+   if (!intel_slpc_active(dev_priv)) {

Just keep printing them, we have the banner upfront, and being able to
track and compare internal values vs hw state is still important. (And
the ordering was fairly intentional.)

cur_freq, idle_freq, boost_freq will not be applicable with SLPC.
With SLPC we should rely on value from RPNSWREQ for cur_freq.



+   seq_printf(m, "Current freq: %d MHz\n",
+  intel_gpu_freq(dev_priv,
+ dev_priv->rps.cur_freq));
+   seq_printf(m, "Idle freq: %d MHz\n",
+  intel_gpu_freq(dev_priv,
+ dev_priv->rps.idle_freq));
+   seq_printf(m, "Boost freq: %d MHz\n",
+  intel_gpu_freq(dev_priv,
+ dev_priv->rps.boost_freq));
+   }
+
seq_printf(m, "Actual freq: %d MHz\n", cagf);
-   seq_printf(m, "Idle freq: %d MHz\n",
-  intel_gpu_freq(dev_priv, dev_priv->rps.idle_freq));
seq_printf(m, "Min freq: %d MHz\n",
   intel_gpu_freq(dev_priv, dev_priv->rps.min_freq));
-   seq_printf(m, "Boost freq: %d MHz\n",
-  intel_gpu_freq(dev_priv, dev_priv->rps.boost_freq));
seq_printf(m, "Max freq: %d MHz\n",
   intel_gpu_freq(dev_priv, dev_priv->rps.max_freq));
seq_printf(m,
@@ -2315,6 +2324,9 @@ static int i915_rps_boost_info(struct seq_file *m, void 
*data)
struct drm_device *dev = _priv->drm;
struct drm_file *file;
  
+	if (intel_slpc_active(dev_priv))

+   return -ENODEV;
+
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_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index 1012eee..020d64e 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -299,6 +299,9 @@ static ssize_t gt_cur_freq_mhz_show(struct device *kdev,
  {
struct drm_i915_private *dev_priv = kdev_minor_to_i915(kdev);
  
+	if (intel_slpc_active(dev_priv))

+   return -ENODEV;

Ok, I had a thought that we allowed the user to directly set cur freq,
but we don't.
-Chris



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

Re: [Intel-gfx] [PATCH v4 10/26] drm/i915/slpc: Allocate/Release/Initialize SLPC shared data

[Kamble, Sagar A]

On 9/9/2016 10:38 PM, Chris Wilson wrote:

On Fri, Sep 09, 2016 at 06:21:29PM +0530, Sagar Arun Kamble wrote:

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.

v1: Update for SLPC interface version 2015.2.4
 intel_slpc_active() returns 1 if slpc initialized (Paulo)
 change default host_os to "Windows"
 Spelling fixes (Sagar Kamble and Nick Hoath)
 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.

v2: WARN_ON for platform_sku validity and space changes. (David)
 Checkpatch update.

v3: Fixing WARNING in igt@drv_module_reload_basic found in trybot BAT
 with SLPC Enabled.

v4: Updated support for GuC v9. s/slice_total/hweight8(slice_mask)/ (Dave).

Reviewed-by: David Weinehall 
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 | 88 ++
  drivers/gpu/drm/i915/intel_slpc.h | 99 +++
  5 files changed, 199 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cf9aa24..796c52f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1707,7 +1707,12 @@ bool chv_phy_powergate_ch(struct drm_i915_private 
*dev_priv, enum dpio_phy phy,
  

I am going to need an idiot's guide here as to the difference between
enabled() and active().
Idea was to set active only when shared data is initialized. enabled was 
used to do initial/final setup.

Will change this and make consistent everywhere by keeping only one state.



  static inline int intel_slpc_active(struct drm_i915_private *dev_priv)

bool.

will update



  {
-   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 83dec66..6e24e60 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 d187066..2211f7b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6656,7 +6656,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);
@@ -6746,7 +6747,8 @@ void intel_enable_gt_powersave(struct drm_i915_private 
*dev_priv)
  
  	mutex_lock(_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 be9e84c..972db18 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -22,15 +22,103 @@
   *
   */
  #include 
+#include 
  #include "i915_drv.h"
  #include "intel_guc.h"
  
+static unsigned int slpc_get_platform_sku(struct drm_i915_private *dev_priv)

+{
+   enum slpc_platform_sku platform_sku;
+
+   if (IS_SKL_ULX(dev_priv))
+   platform_sku = SLPC_PLATFORM_SKU_ULX;
+   else if (IS_SKL_ULT(dev_priv))
+   platform_sku = SLPC_PLATFORM_SKU_ULT;
+   else
+   platform_sku = SLPC_PLATFORM_SKU_DT;
+
+   WARN_ON(platform_sku > 0xFF);
+
+   return platform_sku;
+}
+
+static unsigned int 

Re: [Intel-gfx] [PATCH v4 07/26] drm/i915/slpc: Use intel_slpc_* functions if supported

[Kamble, Sagar A]

Thanks for the review.


On 9/9/2016 10:50 PM, Chris Wilson wrote:

On Fri, Sep 09, 2016 at 06:21:26PM +0530, Sagar Arun Kamble wrote:

@@ -6720,31 +6743,38 @@ void intel_enable_gt_powersave(struct drm_i915_private 
*dev_priv)
+   if (intel_slpc_enabled()) {
+   } else {
  
-	WARN_ON(dev_priv->rps.max_freq < dev_priv->rps.min_freq);

-   WARN_ON(dev_priv->rps.idle_freq > dev_priv->rps.max_freq);
+   WARN_ON(dev_priv->rps.max_freq < dev_priv->rps.min_freq);
+   WARN_ON(dev_priv->rps.idle_freq > dev_priv->rps.max_freq);
  
-	WARN_ON(dev_priv->rps.efficient_freq < dev_priv->rps.min_freq);

-   WARN_ON(dev_priv->rps.efficient_freq > dev_priv->rps.max_freq);
+   WARN_ON(dev_priv->rps.efficient_freq < dev_priv->rps.min_freq);
+   WARN_ON(dev_priv->rps.efficient_freq > dev_priv->rps.max_freq);

You seem to be chickening out of some sanity checks on values we present
to the user.
-Chris


Will restore these. idle_freq not applicable to SLPC hence will remove 
check for it with SLPC.






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

Re: [Intel-gfx] [PATCH v4 09/26] drm/i915/slpc: If using SLPC, do not set frequency

[Kamble, Sagar A]

On 9/9/2016 10:51 PM, Chris Wilson wrote:

On Fri, Sep 09, 2016 at 06:21:28PM +0530, Sagar Arun Kamble wrote:

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.

v1: 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 db5c4ef..d187066 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5047,6 +5047,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;

active not enabled?

All of the other checks in rps are enabled, right?
-Chris


Will change this to make consistent.





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

Re: [Intel-gfx] [PATCH v4 10/25] drm/i915/slpc: Allocate/Release/Initialize SLPC shared data

[Kamble, Sagar A]

On 9/7/2016 8:26 PM, Dave Gordon wrote:

On 07/09/16 14:52, kbuild test robot wrote:

Hi Tom,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20160907]
[cannot apply to v4.8-rc5]
[if your patch is applied to the wrong git tree, please drop us a 
note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or 
--base=auto for convenience) to record what (public, well-known) 
commit your patch series was built on]

[Check https://git-scm.com/docs/git-format-patch for more information]

url: 
https://github.com/0day-ci/linux/commits/Sagar-Arun-Kamble/Add-support-for-GuC-based-SLPC/20160907-201335

base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-defconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=i386

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_slpc.c: In function 
'slpc_get_slice_count':
drivers/gpu/drm/i915/intel_slpc.c:50:37: error: 'const struct 
intel_device_info' has no member named 'slice_total'

  slice_count = INTEL_INFO(dev_priv)->slice_total;
^~

vim +50 drivers/gpu/drm/i915/intel_slpc.c

44
45static unsigned int slpc_get_slice_count(struct 
drm_i915_private *dev_priv)

46{
47unsigned int slice_count = 1;
48
49if (IS_SKYLAKE(dev_priv))
  > 50slice_count = INTEL_INFO(dev_priv)->slice_total;
51
52return slice_count;
53}

---
0-DAY kernel test infrastructureOpen Source 
Technology Center

https://lists.01.org/pipermail/kbuild-all Intel Corporation



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


Is this the right fix?

Yes. I forgot to rebase. Thanks.
Will be sending new series as v4 as earlier one did not go as 
series(went as individual patches - i had done "git format-patch -k ")


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

index 1a3a515..77a316e 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -207,7 +207,7 @@ static unsigned int slpc_get_slice_count(struct 
drm_i915_private *dev_priv)

unsigned int slice_count = 1;

if (IS_SKYLAKE(dev_priv))
-   slice_count = INTEL_INFO(dev_priv)->slice_total;
+   slice_count = 
hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask);


return slice_count;
 }

.Dave.


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

Re: [Intel-gfx] drm/i915/slpc: Update freq min/max softlimits

[Kamble, Sagar A]

On 8/24/2016 2:07 PM, Chris Wilson wrote:

On Sun, Aug 21, 2016 at 09:39:17PM +0530, Kamble, Sagar A wrote:


On 8/21/2016 2:09 PM, Chris Wilson wrote:

On Sun, Aug 21, 2016 at 11:39:22AM +0530, Kamble, Sagar A wrote:

On 8/20/2016 1:32 PM, Chris Wilson wrote:

On Sat, Aug 20, 2016 at 10:39:25AM +0530, Sagar Arun Kamble wrote:

+   obj = dev_priv->guc.slpc.vma->obj;
+   if (obj) {

OOPS.

Fixed in next series.

+   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);

Can kmap_atomic return zero?

Fixed in next series.

+
+   /*
+* 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;

These are user values, you do not get to arbitrarily rewrite them.

You control dev_priv->rps.[min|max]_freq.

With SLPC, GuC firmware SLPC S/W requested frequency be operated in
the softlimits analogous to
Host softlimits. Limits might be different with SLPC and can be
controlled through regular interfaces.
dev_priv->rps.[min|max]_freq are HW Min/Max.

Exactly. The soft limits are *only* set by the user. They are not to
modified by the driver. (The caveat would be a dynamic update of the hw
range, but that too should never be required.)
-Chris

This initialization is similar to following from intel_init_gt_powersave
 dev_priv->rps.max_freq_softlimit = dev_priv->rps.max_freq;
 dev_priv->rps.min_freq_softlimit = dev_priv->rps.min_freq;
I assume min_freq is hw min(RPn). With SLPC, min_freq(RPn) will not
be requested.
SLPC operating range today is (>Rpe, Rp0) so I wanted user to know
the min_softlimit being initialized by SLPC by default.

Hmm, my mistake here was thinking this was more than a one off. Setting
the initial soft (user) range on startup is fine. Continually changing
them after userspace registration is not. (The value the user writes
into the limit is what should be read back - without very good reason,
such as the hard limits changing).
-Chris
I interpreted the rewrite differently, thinking SLPC should not write it 
post init_gt_powersave.
As discussed, I will change this to make sure SLPC init does not touch 
these values once it is

initialized in the load path.




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

Re: [Intel-gfx] drm/i915/slpc: Update freq min/max softlimits

[Kamble, Sagar A]

On 8/21/2016 2:09 PM, Chris Wilson wrote:

On Sun, Aug 21, 2016 at 11:39:22AM +0530, Kamble, Sagar A wrote:


On 8/20/2016 1:32 PM, Chris Wilson wrote:

On Sat, Aug 20, 2016 at 10:39:25AM +0530, Sagar Arun Kamble wrote:

+   obj = dev_priv->guc.slpc.vma->obj;
+   if (obj) {

OOPS.

Fixed in next series.

+   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);

Can kmap_atomic return zero?

Fixed in next series.

+
+   /*
+* 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;

These are user values, you do not get to arbitrarily rewrite them.

You control dev_priv->rps.[min|max]_freq.

With SLPC, GuC firmware SLPC S/W requested frequency be operated in
the softlimits analogous to
Host softlimits. Limits might be different with SLPC and can be
controlled through regular interfaces.
dev_priv->rps.[min|max]_freq are HW Min/Max.

Exactly. The soft limits are *only* set by the user. They are not to
modified by the driver. (The caveat would be a dynamic update of the hw
range, but that too should never be required.)
-Chris

This initialization is similar to following from intel_init_gt_powersave
dev_priv->rps.max_freq_softlimit = dev_priv->rps.max_freq;
dev_priv->rps.min_freq_softlimit = dev_priv->rps.min_freq;
I assume min_freq is hw min(RPn). With SLPC, min_freq(RPn) will not be 
requested.

SLPC operating range today is (>Rpe, Rp0) so I wanted user to know
the min_softlimit being initialized by SLPC by default.






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

Re: [Intel-gfx] Add support for GuC-based SLPC

[Kamble, Sagar A]

On 8/20/2016 1:46 PM, Chris Wilson wrote:

On Sat, Aug 20, 2016 at 10:38:59AM +0530, Sagar Arun Kamble wrote:

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.

Patches pending to support your claims?
-Chris
Only pending GuC firmware 9.18 integration. All kernel side changes for 
SLPC are part of the series.
I added patch to enable SLPC by default in this series, will remove in 
the next series and can add it

once 9.18 firmware gets integrated.




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

Re: [Intel-gfx] drm/i915/slpc: Update current requested frequency

[Kamble, Sagar A]

On 8/20/2016 1:45 PM, Chris Wilson wrote:

On Sat, Aug 20, 2016 at 10:39:10AM +0530, Sagar Arun Kamble wrote:

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);

Do not alter cur_freq here, as we print out RPNSWEQ and updating
cur_freq defeats the purpose of showing the internal value vs the hw
value.

Instead add "SLPC active" to the output.

Fixed in the next series.



+
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))
return -ENODEV;

Fixed in the next series.
  
+	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));
+}

Removed in the next series.

Move to sysfs and look carefully at what you wrote.


  #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);

Use get_if_in_use and just show a stale value when the hw is asleep
would be my preference. cur_freq is just our request, act_freq is the
actual hw value.
With cur_freq not making sense currently with SLPC, I am removing this 
altogether and adding new sysfs interface

for knowing HW requested frequency which will be ideally SLPC requested.



+   mutex_lock(_priv->rps.hw_lock);

Useless mutex.


+   dev_priv->rps.cur_freq = gen9_read_requested_freq(dev_priv);
+   mutex_unlock(_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 mailing list

Re: [Intel-gfx] drm/i915/slpc: Update freq min/max softlimits

[Kamble, Sagar A]

On 8/20/2016 1:32 PM, Chris Wilson wrote:

On Sat, Aug 20, 2016 at 10:39:25AM +0530, Sagar Arun Kamble wrote:

+   obj = dev_priv->guc.slpc.vma->obj;
+   if (obj) {

OOPS.

Fixed in next series.



+   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);

Can kmap_atomic return zero?

Fixed in next series.



+
+   /*
+* 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;

These are user values, you do not get to arbitrarily rewrite them.

You control dev_priv->rps.[min|max]_freq.
With SLPC, GuC firmware SLPC S/W requested frequency be operated in the 
softlimits analogous to
Host softlimits. Limits might be different with SLPC and can be 
controlled through regular interfaces.

dev_priv->rps.[min|max]_freq are HW Min/Max.

-Chris



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

Re: [Intel-gfx] drm/i915: Check GuC load status for Host to GuC action and SLPC status

[Kamble, Sagar A]

Thanks for the review Deepak.

Have incorporated the changes and will send in next series.


On 8/20/2016 10:40 AM, Deepak S wrote:



On 20/08/16 10:39 AM, Sagar Arun Kamble wrote:

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_fw;
+

remove the blank line

  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 = _priv->guc.guc_fw;
  int ret = 0;
  +if (guc_fw->guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
+return 0;
+

Since we are initializing ret=0, I think can do "return ret" right?

  if (dev_priv->guc.slpc.vma && dev_priv->guc.slpc.enabled)
  ret = 1;


___
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] drm/i915/slpc: Use intel_slpc_* functions if supported

[Kamble, Sagar A]

Thanks for the review David.

Have incorporated the changes and will send in next series.


On 8/20/2016 1:57 PM, David Weinehall wrote:

On Sat, Aug 20, 2016 at 10:39:06AM +0530, Sagar Arun Kamble wrote:

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"

v4?


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(_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(_priv->rps.hw_lock);
mutex_unlock(_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(_priv->rps.autoenable_work))

+   if (cancel_delayed_work_sync(_priv->rps.autoenable_work)) {
+   if (intel_slpc_active(dev_priv))
+ 

Re: [Intel-gfx] [PATCH v3] drm/i915/gen9: Update i915_drpc_info debugfs for coarse pg & forcewake info

[Kamble, Sagar A]

Reviewed-by: Sagar Arun Kamble >



On 6/27/2016 8:10 PM, akash.g...@intel.com wrote:

From: Akash Goel 

Updated the i915_drpc_info debugfs with coarse power gating & forcewake
info for Gen9.

v2: Change all IS_GEN9() by gen >= 9 (Damien)

v3: Rebase

Cc: Damien Lespiau 
Signed-off-by: Akash Goel 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 21 -
  drivers/gpu/drm/i915/i915_reg.h |  3 +++
  2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index f664884..5185e02 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1588,6 +1588,7 @@ static int gen6_drpc_info(struct seq_file *m)
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
u32 rpmodectl1, gt_core_status, rcctl1, rc6vids = 0;
+   u32 gen9_powergate_enable = 0, gen9_powergate_status = 0;
unsigned forcewake_count;
int count = 0, ret;
  
@@ -1615,6 +1616,10 @@ static int gen6_drpc_info(struct seq_file *m)
  
  	rpmodectl1 = I915_READ(GEN6_RP_CONTROL);

rcctl1 = I915_READ(GEN6_RC_CONTROL);
+   if (INTEL_INFO(dev)->gen >= 9) {
+   gen9_powergate_enable = I915_READ(GEN9_PG_ENABLE);
+   gen9_powergate_status = I915_READ(GEN9_PWRGT_DOMAIN_STATUS);
+   }
mutex_unlock(>struct_mutex);
mutex_lock(_priv->rps.hw_lock);
sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS, );
@@ -1633,6 +1638,12 @@ static int gen6_drpc_info(struct seq_file *m)
   yesno(rcctl1 & GEN6_RC_CTL_RC1e_ENABLE));
seq_printf(m, "RC6 Enabled: %s\n",
   yesno(rcctl1 & GEN6_RC_CTL_RC6_ENABLE));
+   if (INTEL_INFO(dev)->gen >= 9) {
+   seq_printf(m, "Render Well Gating Enabled: %s\n",
+   yesno(gen9_powergate_enable & GEN9_RENDER_PG_ENABLE));
+   seq_printf(m, "Media Well Gating Enabled: %s\n",
+   yesno(gen9_powergate_enable & GEN9_MEDIA_PG_ENABLE));
+   }
seq_printf(m, "Deep RC6 Enabled: %s\n",
   yesno(rcctl1 & GEN6_RC_CTL_RC6p_ENABLE));
seq_printf(m, "Deepest RC6 Enabled: %s\n",
@@ -1661,6 +1672,14 @@ static int gen6_drpc_info(struct seq_file *m)
  
  	seq_printf(m, "Core Power Down: %s\n",

   yesno(gt_core_status & GEN6_CORE_CPD_STATE_MASK));
+   if (INTEL_INFO(dev)->gen >= 9) {
+   seq_printf(m, "Render Power Well: %s\n",
+   (gen9_powergate_status &
+GEN9_PWRGT_RENDER_STATUS_MASK) ? "Up" : "Down");
+   seq_printf(m, "Media Power Well: %s\n",
+   (gen9_powergate_status &
+GEN9_PWRGT_MEDIA_STATUS_MASK) ? "Up" : "Down");
+   }
  
  	/* Not exactly sure what this is */

seq_printf(m, "RC6 \"Locked to RPn\" residency since boot: %u\n",
@@ -1678,7 +1697,7 @@ static int gen6_drpc_info(struct seq_file *m)
   GEN6_DECODE_RC6_VID(((rc6vids >> 8) & 0xff)));
seq_printf(m, "RC6++ voltage: %dmV\n",
   GEN6_DECODE_RC6_VID(((rc6vids >> 16) & 0xff)));
-   return 0;
+   return i915_forcewake_domains(m, NULL);
  }
  
  static int i915_drpc_info(struct seq_file *m, void *unused)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c6bfbf8..1c8d029 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6955,6 +6955,9 @@ enum {
  #define  ECOBUS   _MMIO(0xa180)
  #defineFORCEWAKE_MT_ENABLE(1<<5)
  #define  VLV_SPAREG2H _MMIO(0xA194)
+#define  GEN9_PWRGT_DOMAIN_STATUS  _MMIO(0xA2A0)
+#define   GEN9_PWRGT_MEDIA_STATUS_MASK (1 << 0)
+#define   GEN9_PWRGT_RENDER_STATUS_MASK(1 << 1)
  
  #define  GTFIFODBG_MMIO(0x12)

  #defineGT_FIFO_SBDEDICATE_FREE_ENTRY_CHV  (0x1f << 20)


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

Re: [Intel-gfx] [PATCH v2] drm/i915:gen9: restrict WaC6DisallowByGfxPause

[Kamble, Sagar A]

Reviewed-by: Sagar Arun Kamble 

On 7/20/2016 3:30 PM, tim.g...@intel.com wrote:

From: Tim Gore 

WaC6DisallowByGfxPause is currently applied unconditionally
but is not required in all revisions.

v2: extend application of workaround to agree with w/a
database, which differs from the HSD.

References: HSD#2133391
Signed-off-by: Tim Gore 
---
  drivers/gpu/drm/i915/intel_guc_loader.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 605c696..96b0259 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -349,7 +349,9 @@ static int guc_ucode_xfer(struct drm_i915_private *dev_priv)
}
  
  	/* WaC6DisallowByGfxPause*/

-   I915_WRITE(GEN6_GFXPAUSE, 0x30FFF);
+   if (IS_SKL_REVID(dev, 0, SKL_REVID_C0) ||
+   IS_BXT_REVID(dev, 0, BXT_REVID_B0))
+   I915_WRITE(GEN6_GFXPAUSE, 0x30FFF);
  
  	if (IS_BROXTON(dev))

I915_WRITE(GEN9LP_GT_PM_CONFIG, GT_DOORBELL_ENABLE);


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

Re: [Intel-gfx] [PATCH] drm/i915:gen9: restrict WaC6DisallowByGfxPause

[Kamble, Sagar A]

On 7/15/2016 7:19 PM, tim.g...@intel.com wrote:

From: Tim Gore 

WaC6DisallowByGfxPause is currently applied unconditionally
but is not required in all revisions.

References: HSD#2133391
Signed-off-by: Tim Gore 
---
  drivers/gpu/drm/i915/intel_guc_loader.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 605c696..173dcef 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -349,7 +349,9 @@ static int guc_ucode_xfer(struct drm_i915_private *dev_priv)
}
  
  	/* WaC6DisallowByGfxPause*/

-   I915_WRITE(GEN6_GFXPAUSE, 0x30FFF);
+   if (IS_SKL_REVID(dev, 0, SKL_REVID_B0) ||
+   IS_BXT_REVID(dev, 0, BXT_REVID_A1))
I see this is applicable till BXT B0 and SKL C0 in wa_database. Am I 
missing something?

+   I915_WRITE(GEN6_GFXPAUSE, 0x30FFF);
  
  	if (IS_BROXTON(dev))

I915_WRITE(GEN9LP_GT_PM_CONFIG, GT_DOORBELL_ENABLE);


___
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/bxt: Fix sanity check for BIOS RC6 setup

[Kamble, Sagar A]

On 7/1/2016 2:45 PM, Imre Deak wrote:

On pe, 2016-07-01 at 12:19 +0530, Kamble, Sagar A wrote:


Have seen BIOS having option "RC6" disabled and "GTPM" enabled for cases
where there are RC6 specific issues.

It's possible although I haven't seen any based on the specs I have and
the tests I ran. In any case the checks I added should catch any such
missing setup and if there is something on top of that we need to add
those (along with an update to the specification).


GTPM option entails setup for other features as well I guess.

Yes, it affects RPS setup too, but my point was that disabling it is
what leaves RC6 unconfigured. I guess this doesn't really matter in the
end, the main thing is that we check all the RC6 specific registers.


In such cases - Can we output some DRM_INFO log saying BIOS has disabled
RC6 although setup is available.

Yes, can add that, but since it's something we'd need for debugging I'd
use DRM_DEBUG.

Fine. With this:
Reviewed-by: Sagar Arun Kamble <sagar.a.kam...@intel.com>



Do we need to also check for other unit level clock gating register
setup done by BIOS like: GEN7_MISCCPCTL, GEN6_UCGCTL1 to
GEN6_UCGCTL4,
GEN8_UCGCTL6 etc.

These are subject to change with later HW steppings. In any case their
default value is the more conservative scenario with clock gating
disabled, which should still allow RC6 functionality. They can be also
enabled/disabled separately from the GTPM option in BIOS setup (via
sub-options to GTPM), something we haven't checked so far anyway.

Are you ok if I add a debug print for these too?

We can skip given that these are not so much impacting RC6 as you said.




--Imre


Thanks
Sagar


On 6/29/2016 9:43 PM, Imre Deak wrote:

BXT BIOS has two options related to GPU power management:
"RC6(Render
Standby)" and "GT PM Support". The assumption so far was that
disabling
either of these options would leave RC6 uninitialized. According to
my
tests this isn't so: for a proper RC6 setup we only need the "GT PM
Support" option to be enabled while the "RC6" option only controls
whether RC6 is left enabled or not by BIOS. OTOH we were missing a
few
checks to ensure a proper RC6 setup. Add these now and don't fail
the
sanity check if RC6 is disabled. This fixes a problem where RC6
remains
disabled after reloading the driver, since we explicitly disable
RC6
during unloading.

CC: Sagar Arun Kamble <sagar.a.kam...@intel.com>
Signed-off-by: Imre Deak <imre.d...@intel.com>
---
   drivers/gpu/drm/i915/i915_reg.h |  5 +
   drivers/gpu/drm/i915/intel_pm.c | 19 ++-
   2 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index c6bfbf8..92b4046 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7085,12 +7085,17 @@ enum {
   #define GEN6_RC6pp_THRESHOLD _MMIO(0xA0C0)
   #define GEN6_PMINTRMSK   _MMIO(0xA16
8)
   #define   GEN8_PMINTR_REDIRECT_TO_NON_DISP   (1<<31)
+#define GEN8_MISC_CTRL0_MMIO(0xA18
0)
   #define VLV_PWRDWNUPCTL  _MMIO(0xA2
94)
   #define GEN9_MEDIA_PG_IDLE_HYSTERESIS_MMIO(0xA0C4
)
   #define GEN9_RENDER_PG_IDLE_HYSTERESIS   _MMIO(0xA0C
8)
   #define GEN9_PG_ENABLE   _MMIO(0xA21
0)
   #define GEN9_RENDER_PG_ENABLE(1<<0)
   #define GEN9_MEDIA_PG_ENABLE (1<<1)
+#define GEN8_PUSHBUS_CONTROL   _MMIO(0xA248)
+#define GEN8_PUSHBUS_ENABLE_MMIO(0xA250)
+#define GEN8_PUSHBUS_SHIFT _MMIO(0xA25C)
+
   
   #define VLV_CHICKEN_3_MMIO(VLV_DI

SPLAY_BASE + 0x7040C)
   #define  PIXEL_OVERLAP_CNT_MASK  (3 << 30)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 5dce264..fe76991 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5015,11 +5015,20 @@ static bool bxt_check_bios_rc6_setup(struct
drm_i915_private *dev_priv)
enable_rc6 = false;
}
   
-	if (!(I915_READ(GEN6_RC_CONTROL) & (GEN6_RC_CTL_RC6_ENABLE

|
-   GEN6_RC_CTL_HW_ENABLE)
) &&
-   ((I915_READ(GEN6_RC_CONTROL) & GEN6_RC_CTL_HW_ENABLE)
||
-!(I915_READ(GEN6_RC_STATE) & RC6_STATE))) {
-   DRM_DEBUG_DRIVER("HW/SW RC6 is not enabled by
BIOS.\n");
+   if (!I915_READ(GEN8_PUSHBUS_CONTROL) ||
+   !I915_READ(GEN8_PUSHBUS_ENABLE) ||
+   !I915_READ(GEN8_PUSHBUS_SHIFT)) {
+   DRM_DEBUG_DRIVER("Pushbus not setup properly.\n");
+   enable_rc6 = false;
+   }
+
+   if (!I915_READ(GEN6_GFXPAUSE)) {
+   DRM_DEBUG_DRIVER("GFX pause not setup
prop

Re: [Intel-gfx] [PATCH 2/2] drm/i915/bxt: Fix sanity check for BIOS RC6 setup

[Kamble, Sagar A]

Have seen BIOS having option "RC6" disabled and "GTPM" enabled for cases 
where there are RC6 specific issues.

GTPM option entails setup for other features as well I guess.
In such cases - Can we output some DRM_INFO log saying BIOS has disabled 
RC6 although setup is available.


Do we need to also check for other unit level clock gating register 
setup done by BIOS like: GEN7_MISCCPCTL, GEN6_UCGCTL1 to GEN6_UCGCTL4, 
GEN8_UCGCTL6 etc.


Thanks
Sagar


On 6/29/2016 9:43 PM, Imre Deak wrote:

BXT BIOS has two options related to GPU power management: "RC6(Render
Standby)" and "GT PM Support". The assumption so far was that disabling
either of these options would leave RC6 uninitialized. According to my
tests this isn't so: for a proper RC6 setup we only need the "GT PM
Support" option to be enabled while the "RC6" option only controls
whether RC6 is left enabled or not by BIOS. OTOH we were missing a few
checks to ensure a proper RC6 setup. Add these now and don't fail the
sanity check if RC6 is disabled. This fixes a problem where RC6 remains
disabled after reloading the driver, since we explicitly disable RC6
during unloading.

CC: Sagar Arun Kamble 
Signed-off-by: Imre Deak 
---
  drivers/gpu/drm/i915/i915_reg.h |  5 +
  drivers/gpu/drm/i915/intel_pm.c | 19 ++-
  2 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c6bfbf8..92b4046 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7085,12 +7085,17 @@ enum {
  #define GEN6_RC6pp_THRESHOLD  _MMIO(0xA0C0)
  #define GEN6_PMINTRMSK_MMIO(0xA168)
  #define   GEN8_PMINTR_REDIRECT_TO_NON_DISP(1<<31)
+#define GEN8_MISC_CTRL0_MMIO(0xA180)
  #define VLV_PWRDWNUPCTL   _MMIO(0xA294)
  #define GEN9_MEDIA_PG_IDLE_HYSTERESIS _MMIO(0xA0C4)
  #define GEN9_RENDER_PG_IDLE_HYSTERESIS_MMIO(0xA0C8)
  #define GEN9_PG_ENABLE_MMIO(0xA210)
  #define GEN9_RENDER_PG_ENABLE (1<<0)
  #define GEN9_MEDIA_PG_ENABLE  (1<<1)
+#define GEN8_PUSHBUS_CONTROL   _MMIO(0xA248)
+#define GEN8_PUSHBUS_ENABLE_MMIO(0xA250)
+#define GEN8_PUSHBUS_SHIFT _MMIO(0xA25C)
+
  
  #define VLV_CHICKEN_3_MMIO(VLV_DISPLAY_BASE + 0x7040C)

  #define  PIXEL_OVERLAP_CNT_MASK   (3 << 30)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 5dce264..fe76991 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5015,11 +5015,20 @@ static bool bxt_check_bios_rc6_setup(struct 
drm_i915_private *dev_priv)
enable_rc6 = false;
}
  
-	if (!(I915_READ(GEN6_RC_CONTROL) & (GEN6_RC_CTL_RC6_ENABLE |

-   GEN6_RC_CTL_HW_ENABLE)) &&
-   ((I915_READ(GEN6_RC_CONTROL) & GEN6_RC_CTL_HW_ENABLE) ||
-!(I915_READ(GEN6_RC_STATE) & RC6_STATE))) {
-   DRM_DEBUG_DRIVER("HW/SW RC6 is not enabled by BIOS.\n");
+   if (!I915_READ(GEN8_PUSHBUS_CONTROL) ||
+   !I915_READ(GEN8_PUSHBUS_ENABLE) ||
+   !I915_READ(GEN8_PUSHBUS_SHIFT)) {
+   DRM_DEBUG_DRIVER("Pushbus not setup properly.\n");
+   enable_rc6 = false;
+   }
+
+   if (!I915_READ(GEN6_GFXPAUSE)) {
+   DRM_DEBUG_DRIVER("GFX pause not setup properly.\n");
+   enable_rc6 = false;
+   }
+
+   if (!I915_READ(GEN8_MISC_CTRL0)) {
+   DRM_DEBUG_DRIVER("GPM control not setup properly.\n");
enable_rc6 = false;
}
  


___
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: Fix log type for RC6 debug messages

[Kamble, Sagar A]

Reviewed-by: Sagar Arun Kamble 

On 6/29/2016 9:43 PM, Imre Deak wrote:

RC6 isn't really a KMS feature, so use the more proper DRIVER log type
for RC6 related debug messages.

CC: Sagar Arun Kamble 
Signed-off-by: Imre Deak 
---
  drivers/gpu/drm/i915/intel_pm.c | 26 ++
  1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d7f8ba8..5dce264 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4973,14 +4973,15 @@ static void intel_print_rc6_info(struct 
drm_i915_private *dev_priv, u32 mode)
mode = 0;
}
if (HAS_RC6p(dev_priv))
-   DRM_DEBUG_KMS("Enabling RC6 states: RC6 %s RC6p %s RC6pp %s\n",
- onoff(mode & GEN6_RC_CTL_RC6_ENABLE),
- onoff(mode & GEN6_RC_CTL_RC6p_ENABLE),
- onoff(mode & GEN6_RC_CTL_RC6pp_ENABLE));
+   DRM_DEBUG_DRIVER("Enabling RC6 states: "
+"RC6 %s RC6p %s RC6pp %s\n",
+onoff(mode & GEN6_RC_CTL_RC6_ENABLE),
+onoff(mode & GEN6_RC_CTL_RC6p_ENABLE),
+onoff(mode & GEN6_RC_CTL_RC6pp_ENABLE));
  
  	else

-   DRM_DEBUG_KMS("Enabling RC6 states: RC6 %s\n",
- onoff(mode & GEN6_RC_CTL_RC6_ENABLE));
+   DRM_DEBUG_DRIVER("Enabling RC6 states: RC6 %s\n",
+onoff(mode & GEN6_RC_CTL_RC6_ENABLE));
  }
  
  static bool bxt_check_bios_rc6_setup(struct drm_i915_private *dev_priv)

@@ -4990,7 +4991,7 @@ static bool bxt_check_bios_rc6_setup(struct 
drm_i915_private *dev_priv)
unsigned long rc6_ctx_base;
  
  	if (!(I915_READ(RC6_LOCATION) & RC6_CTX_IN_DRAM)) {

-   DRM_DEBUG_KMS("RC6 Base location not set properly.\n");
+   DRM_DEBUG_DRIVER("RC6 Base location not set properly.\n");
enable_rc6 = false;
}
  
@@ -5002,7 +5003,7 @@ static bool bxt_check_bios_rc6_setup(struct drm_i915_private *dev_priv)

if (!((rc6_ctx_base >= ggtt->stolen_reserved_base) &&
  (rc6_ctx_base + PAGE_SIZE <= ggtt->stolen_reserved_base +
ggtt->stolen_reserved_size))) {
-   DRM_DEBUG_KMS("RC6 Base address not as expected.\n");
+   DRM_DEBUG_DRIVER("RC6 Base address not as expected.\n");
enable_rc6 = false;
}
  
@@ -5010,7 +5011,7 @@ static bool bxt_check_bios_rc6_setup(struct drm_i915_private *dev_priv)

  ((I915_READ(PWRCTX_MAXCNT_VCSUNIT0) & IDLE_TIME_MASK) > 1) &&
  ((I915_READ(PWRCTX_MAXCNT_BCSUNIT) & IDLE_TIME_MASK) > 1) &&
  ((I915_READ(PWRCTX_MAXCNT_VECSUNIT) & IDLE_TIME_MASK) > 1))) {
-   DRM_DEBUG_KMS("Engine Idle wait time not set properly.\n");
+   DRM_DEBUG_DRIVER("Engine Idle wait time not set properly.\n");
enable_rc6 = false;
}
  
@@ -5018,7 +5019,7 @@ static bool bxt_check_bios_rc6_setup(struct drm_i915_private *dev_priv)

GEN6_RC_CTL_HW_ENABLE)) &&
((I915_READ(GEN6_RC_CONTROL) & GEN6_RC_CTL_HW_ENABLE) ||
 !(I915_READ(GEN6_RC_STATE) & RC6_STATE))) {
-   DRM_DEBUG_KMS("HW/SW RC6 is not enabled by BIOS.\n");
+   DRM_DEBUG_DRIVER("HW/SW RC6 is not enabled by BIOS.\n");
enable_rc6 = false;
}
  
@@ -5050,8 +5051,9 @@ int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6)

mask = INTEL_RC6_ENABLE;
  
  		if ((enable_rc6 & mask) != enable_rc6)

-   DRM_DEBUG_KMS("Adjusting RC6 mask to %d (requested %d, valid 
%d)\n",
- enable_rc6 & mask, enable_rc6, mask);
+   DRM_DEBUG_DRIVER("Adjusting RC6 mask to %d "
+"(requested %d, valid %d)\n",
+enable_rc6 & mask, enable_rc6, mask);
  
  		return enable_rc6 & mask;

}


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

Re: [Intel-gfx] [PATCH v4 1/1] drm/i915: Update GEN6_PMINTRMSK setup with GuC enabled

[Kamble, Sagar A]

On 6/1/2016 7:59 PM, Matt Roper wrote:

On Wed, Jun 01, 2016 at 07:54:42AM +0100, Chris Wilson wrote:

On Tue, May 31, 2016 at 04:18:34PM -0700, Matt Roper wrote:

On Tue, May 31, 2016 at 09:51:53AM +0100, Chris Wilson wrote:

On Tue, May 31, 2016 at 01:58:27PM +0530, Sagar Arun Kamble wrote:

On Loading, GuC sets PM interrupts routing (bit 31) and clears ARAT
expired interrupt (bit 9). Host turbo also updates this register
in RPS flows. This patch ensures bit 31 and bit 9 setup by GuC persists.
ARAT timer interrupt is needed in GuC for various features. It also
facilitates halting GuC and hence achieving RC6. PM interrupt routing
will not impact RPS interrupt reception by host as GuC will redirect
them.
This patch fixes igt test pm_rc6_residency that was failing with guc
load/submission enabled. Tested with SKL GuC v6.1 and BXT GuC v5.1 and v8.7.

v2: i915_irq/i915_pm decoupling from intel_guc. (ChrisW)

v3: restructuring the mask update and rebase w.r.t Ville's patch. (ChrisW)

v4: Updating the pm_intr_keep during direct_interrupts_to_guc. (Sagar)

Cc: Chris Harris 
Cc: Zhe Wang 
Cc: Deepak S 
Cc: Satyanantha, Rama Gopal M 
Cc: Akash Goel 
Signed-off-by: Sagar Arun Kamble 

I can understand what you mean by this patch, perfect!
Reviewed-by: Chris Wilson 
-Chris

Testcase: igt/pm_rc6_residency
Tested-by: Matt Roper 

Merged to dinq.  Thanks for the patch and review.

This was only the second patch, it also wants the first patch to always
use gen6_sanitize_pm_mask otherwise we loose the interrupt bypass from
gen6_rps_idle(). That should have been caught by the testcase...
-Chris

Hmm, I guess is misunderstood the message thread flow here and didn't
realize there was another patch necessary as well.  I did find that just
this one patch caused the IGT to start passing where it had failed
before (on BXT), so not sure why I didn't run into problems.  I did
merge in a couple un-related TSC patches (required to keep my BXT stable
in general) before testing, but I don't think that would have changed
the behavior here.
Testcase did not catch it because guc loading/submission is disabled by 
default.

I have submitted BAT request with guc loading/submission enabled on trybot.
Waiting for the results.



Matt


--
Chris Wilson, Intel Open Source Technology Centre


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

Re: [Intel-gfx] [PATCH v4 1/1] drm/i915: Update GEN6_PMINTRMSK setup with GuC enabled

[Kamble, Sagar A]

On 6/1/2016 12:24 PM, Chris Wilson wrote:

On Tue, May 31, 2016 at 04:18:34PM -0700, Matt Roper wrote:

On Tue, May 31, 2016 at 09:51:53AM +0100, Chris Wilson wrote:

On Tue, May 31, 2016 at 01:58:27PM +0530, Sagar Arun Kamble wrote:

On Loading, GuC sets PM interrupts routing (bit 31) and clears ARAT
expired interrupt (bit 9). Host turbo also updates this register
in RPS flows. This patch ensures bit 31 and bit 9 setup by GuC persists.
ARAT timer interrupt is needed in GuC for various features. It also
facilitates halting GuC and hence achieving RC6. PM interrupt routing
will not impact RPS interrupt reception by host as GuC will redirect
them.
This patch fixes igt test pm_rc6_residency that was failing with guc
load/submission enabled. Tested with SKL GuC v6.1 and BXT GuC v5.1 and v8.7.

v2: i915_irq/i915_pm decoupling from intel_guc. (ChrisW)

v3: restructuring the mask update and rebase w.r.t Ville's patch. (ChrisW)

v4: Updating the pm_intr_keep during direct_interrupts_to_guc. (Sagar)

Cc: Chris Harris 
Cc: Zhe Wang 
Cc: Deepak S 
Cc: Satyanantha, Rama Gopal M 
Cc: Akash Goel 
Signed-off-by: Sagar Arun Kamble 

I can understand what you mean by this patch, perfect!
Reviewed-by: Chris Wilson 
-Chris

Testcase: igt/pm_rc6_residency
Tested-by: Matt Roper 

Merged to dinq.  Thanks for the patch and review.

This was only the second patch, it also wants the first patch to always
use gen6_sanitize_pm_mask otherwise we loose the interrupt bypass from
gen6_rps_idle(). That should have been caught by the testcase...
-Chris
BAT picked up these patches separately. I had submitted them in sequence 
although I updated current patch twice posting them together.

How is this supposed to work?




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

Re: [Intel-gfx] ✗ Ro.CI.BAT: warning for series starting with [1/1] drm/i915: Never fully mask the the EI up rps interrupt on SNB/IVB

[Kamble, Sagar A]

These warnings are too not related to the patch.
Kindly push this patch.

On 5/31/2016 4:35 PM, Patchwork wrote:

== Series Details ==

Series: series starting with [1/1] drm/i915: Never fully mask the the EI up rps 
interrupt on SNB/IVB
URL   : https://patchwork.freedesktop.org/series/7990/
State : warning

== Summary ==

Series 7990v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/7990/revisions/1/mbox

Test gem_busy:
 Subgroup basic-parallel-render:
 pass   -> DMESG-WARN (ro-ivb2-i7-3770)
 Subgroup basic-render:
 pass   -> DMESG-WARN (ro-ivb2-i7-3770)
Test gem_close_race:
 Subgroup basic-process:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test gem_cs_tlb:
 Subgroup basic-default:
 pass   -> DMESG-WARN (ro-ivb2-i7-3770)
Test gem_exec_basic:
 Subgroup readonly-render:
 dmesg-warn -> PASS   (ro-ivb2-i7-3770)
Test gem_exec_flush:
 Subgroup basic-uc-prw-default:
 pass   -> DMESG-WARN (ro-skl-i7-6700hq)
 Subgroup basic-uc-ro-default:
 pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test gem_exec_parallel:
 Subgroup basic:
 pass   -> DMESG-WARN (ro-ivb2-i7-3770)
Test gem_exec_store:
 Subgroup basic-all:
 pass   -> DMESG-WARN (ro-ivb2-i7-3770)
 Subgroup basic-blt:
 dmesg-warn -> PASS   (ro-ivb2-i7-3770)
 Subgroup basic-default:
 dmesg-warn -> PASS   (ro-ivb2-i7-3770)
Test gem_flink_basic:
 Subgroup bad-flink:
 pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test gem_mmap_gtt:
 Subgroup basic-short:
 pass   -> DMESG-WARN (ro-skl-i7-6700hq)
 Subgroup basic-small-copy:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test gem_storedw_loop:
 Subgroup basic-bsd:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test gem_tiled_pread_basic:
 pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test kms_addfb_basic:
 Subgroup addfb25-framebuffer-vs-set-tiling:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)
 Subgroup addfb25-x-tiled:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)
 Subgroup addfb25-y-tiled-small:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)
 Subgroup bad-pitch-1024:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)
 Subgroup bad-pitch-63:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)
 Subgroup basic-x-tiled:
 pass   -> DMESG-WARN (ro-skl-i7-6700hq)
 Subgroup too-high:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)
 Subgroup too-wide:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test kms_force_connector_basic:
 Subgroup force-edid:
 pass   -> DMESG-WARN (ro-ivb2-i7-3770)

fi-bdw-i7-5557u  total:102  pass:93   dwarn:0   dfail:0   fail:0   skip:8
fi-byt-n2820 total:209  pass:168  dwarn:0   dfail:0   fail:3   skip:38
fi-hsw-i7-4770k  total:209  pass:190  dwarn:0   dfail:0   fail:0   skip:19
fi-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23
fi-skl-i7-6700k  total:209  pass:184  dwarn:0   dfail:0   fail:0   skip:25
fi-snb-i7-2600   total:209  pass:170  dwarn:0   dfail:0   fail:0   skip:39
ro-bdw-i5-5250u  total:102  pass:93   dwarn:0   dfail:0   fail:0   skip:8
ro-bdw-i7-5600u  total:102  pass:75   dwarn:0   dfail:0   fail:0   skip:26
ro-bsw-n3050 total:209  pass:168  dwarn:0   dfail:0   fail:2   skip:39
ro-byt-n2820 total:209  pass:169  dwarn:0   dfail:0   fail:3   skip:37
ro-hsw-i3-4010u  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23
ro-hsw-i7-4770r  total:102  pass:82   dwarn:0   dfail:0   fail:0   skip:19
ro-ilk-i7-620lm  total:1pass:0dwarn:0   dfail:0   fail:0   skip:0
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57
ro-ivb-i7-3770   total:102  pass:75   dwarn:0   dfail:0   fail:0   skip:26
ro-ivb2-i7-3770  total:102  pass:42   dwarn:37  dfail:0   fail:0   skip:22
ro-skl-i7-6700hq total:204  pass:175  dwarn:8   dfail:0   fail:0   skip:21
ro-snb-i7-2620M  total:102  pass:72   dwarn:0   dfail:0   fail:0   skip:29
fi-bsw-n3050 failed to connect after reboot
ro-bdw-i7-5557U failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1055/

031f2bb drm-intel-nightly: 2016y-05m-30d-17h-51m-33s UTC integration manifest
5779419 drm/i915: Never fully mask the the EI up rps interrupt on SNB/IVB



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

Re: [Intel-gfx] ✗ Ro.CI.BAT: warning for series starting with [v4,1/1] drm/i915: Update GEN6_PMINTRMSK setup with GuC enabled (rev5)

[Kamble, Sagar A]

Warnings are not related to the patch. Kindly push this patch.
Have filed bug for IVB warnings: 
https://bugs.freedesktop.org/show_bug.cgi?id=96293
For SKL warnings there is already a bug: 
https://bugs.freedesktop.org/show_bug.cgi?id=95632


Thanks
Sagar

On 5/31/2016 5:08 PM, Patchwork wrote:

== Series Details ==

Series: series starting with [v4,1/1] drm/i915: Update GEN6_PMINTRMSK setup 
with GuC enabled (rev5)
URL   : https://patchwork.freedesktop.org/series/7972/
State : warning

== Summary ==

Series 7972v5 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/7972/revisions/5/mbox

Test gem_busy:
 Subgroup basic-parallel-bsd:
 pass   -> DMESG-WARN (ro-ivb2-i7-3770)
Test gem_close_race:
 Subgroup basic-process:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test gem_cs_tlb:
 Subgroup basic-default:
 pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test gem_ctx_exec:
 Subgroup basic:
 pass   -> DMESG-WARN (ro-ivb2-i7-3770)
Test gem_exec_basic:
 Subgroup readonly-render:
 dmesg-warn -> PASS   (ro-ivb2-i7-3770)
Test gem_exec_flush:
 Subgroup basic-wb-pro-default:
 pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test gem_exec_store:
 Subgroup basic-blt:
 dmesg-warn -> PASS   (ro-ivb2-i7-3770)
 Subgroup basic-default:
 dmesg-warn -> PASS   (ro-ivb2-i7-3770)
Test gem_exec_suspend:
 Subgroup basic:
 pass   -> DMESG-WARN (ro-ivb2-i7-3770)
Test gem_storedw_loop:
 Subgroup basic-bsd:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test kms_addfb_basic:
 Subgroup addfb25-framebuffer-vs-set-tiling:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)
 Subgroup addfb25-x-tiled:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)
 Subgroup bad-pitch-1024:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)
 Subgroup bad-pitch-63:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)
 Subgroup bad-pitch-65536:
 pass   -> DMESG-WARN (ro-skl-i7-6700hq)
 Subgroup bad-pitch-999:
 pass   -> DMESG-WARN (ro-skl-i7-6700hq)
 Subgroup too-high:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)
 Subgroup too-wide:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test kms_flip:
 Subgroup basic-flip-vs-wf_vblank:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test kms_force_connector_basic:
 Subgroup force-connector-state:
 pass   -> DMESG-WARN (ro-ivb2-i7-3770)
Test kms_psr_sink_crc:
 Subgroup psr_basic:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)

fi-bdw-i7-5557u  total:102  pass:93   dwarn:0   dfail:0   fail:0   skip:8
fi-bsw-n3050 total:209  pass:167  dwarn:0   dfail:0   fail:2   skip:40
fi-byt-n2820 total:209  pass:168  dwarn:0   dfail:0   fail:3   skip:38
fi-hsw-i7-4770k  total:209  pass:190  dwarn:0   dfail:0   fail:0   skip:19
fi-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23
fi-skl-i7-6700k  total:209  pass:184  dwarn:0   dfail:0   fail:0   skip:25
fi-snb-i7-2600   total:209  pass:170  dwarn:0   dfail:0   fail:0   skip:39
ro-bdw-i5-5250u  total:102  pass:93   dwarn:0   dfail:0   fail:0   skip:8
ro-bdw-i7-5600u  total:102  pass:75   dwarn:0   dfail:0   fail:0   skip:26
ro-bsw-n3050 total:209  pass:168  dwarn:0   dfail:0   fail:2   skip:39
ro-byt-n2820 total:209  pass:169  dwarn:0   dfail:0   fail:3   skip:37
ro-hsw-i3-4010u  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23
ro-hsw-i7-4770r  total:102  pass:82   dwarn:0   dfail:0   fail:0   skip:19
ro-ilk-i7-620lm  total:1pass:0dwarn:0   dfail:0   fail:0   skip:0
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57
ro-ivb-i7-3770   total:52   pass:37   dwarn:0   dfail:0   fail:0   skip:14
ro-ivb2-i7-3770  total:102  pass:44   dwarn:35  dfail:0   fail:0   skip:22
ro-skl-i7-6700hq total:204  pass:177  dwarn:6   dfail:0   fail:0   skip:21
ro-snb-i7-2620M  total:102  pass:72   dwarn:0   dfail:0   fail:0   skip:29
ro-bdw-i7-5557U failed to connect after reboot
ro-ivb-i7-3770 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1057/

031f2bb drm-intel-nightly: 2016y-05m-30d-17h-51m-33s UTC integration manifest
db75f2f drm/i915: Update GEN6_PMINTRMSK setup with GuC enabled



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

Re: [Intel-gfx] [PATCH v3 1/1] drm/i915: Update GEN6_PMINTRMSK setup with GuC enabled

[Kamble, Sagar A]

On 5/31/2016 1:48 AM, Chris Wilson wrote:

On Tue, May 31, 2016 at 12:16:11AM +0530, Sagar Arun Kamble wrote:

  void gen6_disable_rps_interrupts(struct drm_i915_private *dev_priv)
@@ -4580,6 +4568,28 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
else
dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS;
  
+	dev_priv->rps.pm_intr_keep = 0;

+
+   /*
+* SNB,IVB can while VLV,CHV may hard hang on looping batchbuffer
+* if GEN6_PM_UP_EI_EXPIRED is masked.
+*
+* TODO: verify if this can be reproduced on VLV,CHV.
+*/
+   if (INTEL_INFO(dev_priv)->gen <= 7 && !IS_HASWELL(dev_priv))
+   dev_priv->rps.pm_intr_keep |= GEN6_PM_RP_UP_EI_EXPIRED;
+
+   /*
+* If GuC submission is enabled keep PM interrupts routed to GuC
+* and unmask ARAT Expired interrupt as it is needed by GuC.
+   */
+   if (INTEL_INFO(dev_priv)->gen >= 8) {
+   if (i915.enable_guc_submission)
+   dev_priv->rps.pm_intr_keep |= 
GEN8_ARAT_EXPIRED_INT_MASK;
+   else
+   dev_priv->rps.pm_intr_keep |= 
GEN8_PMINTR_REDIRECT_TO_NON_DISP;

The logic doesn't match the comment. Don't you want

if (i915.enable_guc_submission) {
dev_priv->rps.pm_intr_keep |= GEN8_ARAT_EXPIRED_INT_MASK;
dev_priv->rps.pm_intr_keep |= GEN8_PMINTR_REDIRECT_TO_NON_DISP;
}
We don't want to keep GEN8_PMINTR_REDIRECT_TO_NON_DISP if GuC submission 
is used.

I added WARN_ON for bits of GEN6_PMINTRMASK if GuC has set expected.
With GuC loaded bit 31 will be set and bit 9 is reset. GuC might reset 
other bits if it needs
those interrupts. I am extending the logic to other interrupts to make 
it extensible.

Certainly this patch is looking more neat now :) ... Thank you.


as implied by the comment? Although I'm guessing the
i915.enable_guc_submission will be refined in future, it should do for
now.


+   WARN_ON(!(I915_READ(GEN6_PMINTRMSK) |
+   GEN8_PMINTR_REDIRECT_TO_NON_DISP));

Always false;


+   WARN_ON(I915_READ(GEN6_PMINTRMSK) |
+   GEN8_ARAT_EXPIRED_INT_MASK);

Always true.

I don't this was quite what you meant :)

But the patch is a lot neater now!
-Chris



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

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Update the forcewake range

[Kamble, Sagar A]

Reviewed-by: Sagar Arun Kamble 

On 4/29/2016 9:54 AM, akash.g...@intel.com wrote:

From: Akash Goel 

Update made to the Gen9 forcewake range to cover the OA registers.
MMIO locations 0x2700-0x2FFF belong to the same power domain
as 0x2000-0x26FF.

Signed-off-by: Akash Goel 
---
  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 4f1dfe6..7387426 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -699,8 +699,7 @@ static bool is_gen8_shadowed(u32 offset)
REG_RANGE((reg), 0xB00,  0x2000)
  
  #define FORCEWAKE_GEN9_RENDER_RANGE_OFFSET(reg) \

-   (REG_RANGE((reg), 0x2000, 0x2700) || \
-REG_RANGE((reg), 0x3000, 0x4000) || \
+   (REG_RANGE((reg), 0x2000, 0x4000) || \
 REG_RANGE((reg), 0x5200, 0x8000) || \
 REG_RANGE((reg), 0x8140, 0x8160) || \
 REG_RANGE((reg), 0x8300, 0x8500) || \


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

Re: [Intel-gfx] [PATCH] drm/i915: Add RPS debugfs disabling for gen6+ platforms

[Kamble, Sagar A]

Get/Put RPM ref around RP_CONTROL write and outside mutex lock.

On 2/18/2016 2:56 PM, ankitprasad.r.sha...@intel.com wrote:

From: Ankitprasad Sharma 

This patch exposes a new debugfs interface 'i915_rps_disable'
Following 2 values shall be echoed into this file.
'0' - RPS explicitly enabled .
'1' - RPS explicitly disabled.

This interface provides capabilty to enable/disable Turbo feature
at runtime, which is needed for its validation.

Signed-off-by: Deepak S 
Signed-off-by: Praveen Paneri 
Signed-off-by: Ankitprasad Sharma 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 55 +
  drivers/gpu/drm/i915/i915_drv.h |  2 ++
  2 files changed, 57 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index aa7c7a3..1f58540 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -5023,6 +5023,60 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_min_freq_fops,
i915_min_freq_get, i915_min_freq_set,
"%llu\n");
  
+static int i915_rps_disable_get(void *data, u64 *val)

+{
+   struct drm_device *dev = data;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
+   if(INTEL_INFO(dev)->gen < 6)
+   return -ENODEV;
+
+   flush_delayed_work(_priv->rps.delayed_resume_work);
+
+   *val = dev_priv->rps.rps_disable;
+
+   return 0;
+}
+
+static int i915_rps_disable_set(void *data, u64 val)
+{
+   struct drm_device *dev = data;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   int ret;
+
+   flush_delayed_work(_priv->rps.delayed_resume_work);
+
+   if(INTEL_INFO(dev)->gen < 6)
+   return -ENODEV;
+
+   DRM_DEBUG_DRIVER("Setting RPS disable %s\n",
+val ? "true" : "false");
+
+   ret = mutex_lock_interruptible(_priv->rps.hw_lock);
+   if (ret)
+   return ret;
+
+   dev_priv->rps.rps_disable = val;
+
+   if (val)
+   I915_WRITE(GEN6_RP_CONTROL, 0);
+   else
+   I915_WRITE(GEN6_RP_CONTROL, GEN6_RP_MEDIA_TURBO |
+   GEN6_RP_MEDIA_HW_NORMAL_MODE |
+   GEN6_RP_MEDIA_IS_GFX |
+   GEN6_RP_ENABLE |
+   GEN6_RP_UP_BUSY_AVG |
+   GEN6_RP_DOWN_IDLE_AVG);
+
+   mutex_unlock(_priv->rps.hw_lock);
+
+   return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_rps_disable_fops,
+   i915_rps_disable_get, i915_rps_disable_set,
+   "%llu\n");
+
  static int
  i915_cache_sharing_get(void *data, u64 *val)
  {
@@ -5391,6 +5445,7 @@ static const struct i915_debugfs_files {
{"i915_wedged", _wedged_fops},
{"i915_max_freq", _max_freq_fops},
{"i915_min_freq", _min_freq_fops},
+   {"i915_rps_disable", _rps_disable_fops},
{"i915_cache_sharing", _cache_sharing_fops},
{"i915_ring_stop", _ring_stop_fops},
{"i915_ring_missed_irq", _ring_missed_irq_fops},
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9d67097..28e3537 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1169,6 +1169,8 @@ struct intel_gen6_power_mgmt {
u8 up_threshold; /* Current %busy required to uplock */
u8 down_threshold; /* Current %busy required to downclock */
  
+	bool rps_disable;

+
int last_adj;
enum { LOW_POWER, BETWEEN, HIGH_POWER } power;
  


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

Re: [Intel-gfx] [RFC 00/22] Add support for GuC-based SLPC

[Kamble, Sagar A]

Hi Paulo,

Thanks for comments.
1. Will make change related to #define for number of pipes and remove 
the unnecessary ones.
2. vrefresh is almost same as "clock/(htotal*vtotal) if we round up 
later. Will keep it vrefresh for now.


Thanks
Sagar


On 2/4/2016 1:55 AM, Zanoni, Paulo R wrote:

Em Qua, 2016-01-20 às 18:26 -0800, tom.orou...@intel.com escreveu:

From: Tom O'Rourke 

SLPC (Single Loop Power Controller) is a replacement for
some host-based power management features.  The SLPC
implemenation runs in firmware on GuC.

This series is a first request for comments.  This series
is not expected to be merged.  After changes based on
comments, a later patch series will be sent for merging.
  
This series has been tested with SKL guc firmware

versions 4.3 and 4.7.  The graphics power management
features in SLPC in those versions are DFPS (Dynamic FPS),
Turbo, and DCC (Duty Cycle Control).  DFPS adjusts
requested graphics frequency to maintain target framerate.
Turbo adjusts requested graphics frequency to maintain
target GT busyness.  DCC adjusts requested graphics
frequency and stalls guc-scheduler to maintain actual
graphics frequency in efficient range.

Patch 1/22 is included ihere for convenience and should be
part of an earlier series.  SLPC assumes guc firmware has
been loaded and GuC submission is enabled.

Patch 22/22 sets the flag to enable SLPC on SKL.  Without
this patch, the previous patches should have no effect.

VIZ-6773, VIZ-6889

Hi

Some high-level comments for the whole series:

In many places there are 8 spaces instead of tabs.

There are also some lines containing just a tab character.

Lots of Yoda conditions: if (constant == variable).

Some functions would get much simpler if they had early returns.

I certainly wouldn't complain if you also extracted the relevant
rps/powersave code out of intel_pm.c to its own file with a nice
documentation. Of course, this could be done after the series.

Lots of ignored return values. It seems the inner functions all check
for errors and return them to their callers, but the top-most functions
added by the series just ignore the errors. See my previous comment on
patch 14 about this for suggestions.

There are no checks for GuC version here. We know that the SLPC ABI is
not stable and can change in new firmware versions, so I expect the
SLPC code to only run if it finds the specific _whitelisted_ GuC
versions. No "if (version >= num) use_slpc=true;", please.

I'm not 100% sure, but from what I could understand, it seems I'll get
a broken machine with no RPS at all if I don't have the GuC firmware
files - or if the GuC version is not the expected. IMHO this is a
regression since I currently don't have any firmware files and my SKL
machine works.

I see most of the functions are protected by "HAS_SLPC". Usually
HAS_SOMETHING is used for hardware features and is expected to be
constant on platforms. I suggest you to add a possible driver parameter
such as i915.enable_slpc, and also add a new "intel_slpc_enabled()" or
"intel_using_slpc()" function and replace all the HAS_SLPC checks with
these. This way, we'll be able to easily disable SLPC in case we don't
want it (such as due to a regression) or if there's no firmware or
incorrect firmware version, and revert back to the old (current)
behavior of driver-based turbo. The only HAS_SLPC check should be
during SLPC initialization. Having an easy way to enable/disable SLPC
will also be immensely helpful when we start running workloads to
decide if we want to enable it.

You could even go further and make the i915.enable_slpc param be a mask
where it's possible to select each sub-feature individually (dfps,
turbo, dcc).

Some of the checks for shared_data_obj could also become calls to an
inline function with a nice name such as intel_slpc_enabled() or
something else.

I see there's a specific pattern on the places that call
host2guc_action(). Perhaps we could move that common code to its own
function? It would also be nice to add a name to the 0xFF mask that we
return - and that gets ignored at the end of the call chains.

Patch 5 needs a commit message. Actually, when reviewing patch 4 I
thought it had broken RC6, until I saw patch 5, so maybe you could just
squash both commits into one.

On patch 13, those defines such as MAX_INTEL_PIPES are weird and
confusing (why do we check if they were already defined?), especially
since we already have I915_MAX_PIPES. And the only value that is
actually used is MAX_NUM_OF_PIPE. I would vote for you to only keep
this define, and prefix it with SLPC, such as SLPC_NUM_OF_PIPES (or any
other better name).

On patches 14/15, is mode->vrefresh accurate enough? Don't we want the
more-precise "clock/(htotal*vtotal)" value?

On patch 17. I'm not an expert here, but I'm not sure if we can call
kmap_atomic and then do those seq_printf calls without kunmap.

Thanks,
Paulo


Dave Gordon (1):
   drm/i915: Enable GuC submission, where supported

Re: [Intel-gfx] [PATCH 1/1] drm/i915/skl: fix RC6 residency time calculation

[Kamble, Sagar A]

Ok. I related my change to below definition:

#define GT_INTERVAL_FROM_US(dev_priv, us) (IS_GEN9(dev_priv) ? \
(IS_BROXTON(dev_priv) ? \
INTERVAL_0_833_US(us) : \
INTERVAL_1_33_US(us)) : \
INTERVAL_1_28_US(us))

This is using 1.33us unit for SKL.
May be we need to define these based on mode (normal/PSMI).
Not sure how to determine modes.

Thanks
Sagar


On 2/3/2016 10:40 PM, Imre Deak wrote:

On ke, 2016-02-03 at 11:29 +0530, Sagar Arun Kamble wrote:

The RC6 residency time unit is 1.33us on SKL according to the
specification, so update the calculation accordingly.

Cc: Imre Deak 
Signed-off-by: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/i915_sysfs.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index c6188dd..9aa49a9 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -58,7 +58,8 @@ static u32 calc_residency(struct drm_device *dev,
} else if (IS_BROXTON(dev)) {
units = 1;
div = 1200; /* 833.33ns */
-   }
+   } else if (IS_SKYLAKE(dev))
+   units = 133ULL;

Hrm. The SKL/GT_GFX_RC6 description in ConfigDB doesn't say anything
about the units, the BSpec "Timestamp Bases" provides two values for
two different modes:

1.33us and 1.28us

Not sure what are these different modes.

BSpec GT_GFX_RC6 description specifies 1.28us.

Running igt/pm_rc6_residency calculating with the current 1.28us results in:
Residency in rc6 or deeper state: 2983 ms (sleep duration 3003 ms) (ratio to 
expected duration: 0,99)
Subtest rc6-accuracy: SUCCESS (0,000s)

and after applying your patch (calculating with 1.33us):
Residency in rc6 or deeper state: 3101 ms (sleep duration 3001 ms) (ratio to 
expected duration: 1,03)
(pm_rc6_residency:6281) CRITICAL: Test assertion failure function 
residency_accuracy, file pm_rc6_residency.c:110:
(pm_rc6_residency:6281) CRITICAL: Failed assertion: ratio > 0.9 && ratio <= 1
(pm_rc6_residency:6281) CRITICAL: Sysfs RC6 residency counter is inaccurate.

While the measurement can be inaccurate, normally we should only err by
measuring less duration in RC6 than the duration of the actual sleep.
So I'm not convinced that 1.33us is the correct value..

--Imre

  
  	raw_time = I915_READ(reg) * units;

ret = DIV_ROUND_UP_ULL(raw_time, div);


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

Re: [Intel-gfx] [PATCH v6 1/1] drm/i915/bxt: Check BIOS RC6 setup before enabling RC6

[Kamble, Sagar A]

Thanks for the review Imre.
I Kept that BSD2 check thinking some BXT revision might support it :)
Will remove the check and send the patch.

Thanks
Sagar

On 2/2/2016 9:48 PM, Imre Deak wrote:

On pe, 2016-01-29 at 23:22 +0530, Sagar Arun Kamble wrote:

RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6
setup registers. If those are not setup Driver should not enable RC6.
For implementing this, driver can check RC_CTRL0 and RC_CTRL1 values
to know if BIOS has enabled HW/SW RC6.
This will also enable user to control RC6 using BIOS settings alone.
RC6 related instability can be avoided by disabling via BIOS settings
till driver fixes it.

v2: Had placed logic in gen8 function by mistake. Fixed it.
Ensuring RPM is not enabled in case BIOS disabled RC6.

v3: Need to disable RPM if RC6 is disabled due to BIOS settings. (Daniel)
Runtime PM enabling happens before gen9_enable_rc6.
Moved the updation of enable_rc6 parameter in intel_uncore_sanitize.

v4: Added elaborate check for BIOS RC6 setup. Prepared check_pctx for bxt. 
(Imre)

v5: Caching reserved stolen base and size in the driver private data.
Reorganized RC6 setup check. Moved from gen9_enable_rc6 to 
intel_uncore_sanitize. (Imre)

v6: Rebasing on the patch submitted by Imre that moves gem_init_stolen earlier 
in the load.

Cc: Imre Deak 
Change-Id: If89518708e133be6b3c7c6f90869fb66224b7b87
Signed-off-by: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/i915_gem_gtt.h|  2 ++
  drivers/gpu/drm/i915/i915_gem_stolen.c |  3 ++
  drivers/gpu/drm/i915/i915_reg.h| 11 +++
  drivers/gpu/drm/i915/intel_drv.h   |  1 +
  drivers/gpu/drm/i915/intel_pm.c| 60 --
  drivers/gpu/drm/i915/intel_uncore.c|  2 ++
  6 files changed, 77 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index f520c90..66a6da2 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -342,6 +342,8 @@ struct i915_gtt {
  
  	size_t stolen_size;		/* Total size of stolen memory */

size_t stolen_usable_size;  /* Total size minus BIOS reserved */
+   size_t stolen_reserved_base;
+   size_t stolen_reserved_size;
u64 mappable_end;   /* End offset that we can CPU map */
struct io_mapping *mappable;/* Mapping to our CPU mappable region */
phys_addr_t mappable_base;  /* PA of our GMADR */
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index c384dc9..ba1a00d 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -458,6 +458,9 @@ int i915_gem_init_stolen(struct drm_device *dev)
return 0;
}
  
+	dev_priv->gtt.stolen_reserved_base = reserved_base;

+   dev_priv->gtt.stolen_reserved_size = reserved_size;
+
/* It is possible for the reserved area to end before the end of stolen
 * memory, so just consider the start. */
reserved_total = stolen_top - reserved_base;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 65e32a3..00aac28 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6781,6 +6781,16 @@ enum skl_disp_power_wells {
  
  #define  VLV_PMWGICZ_MMIO(0x1300a4)
  
+#define  RC6_LOCATION_MMIO(0xD40)

+#define  RC6_CTX_IN_DRAM   1
+#define  RC6_CTX_BASE  _MMIO(0xD48)
+#define  RC6_CTX_BASE_MASK 0xFFF0
+#define  PWRCTX_MAXCNT_RCSUNIT _MMIO(0x2054)
+#define  PWRCTX_MAXCNT_VCSUNIT0_MMIO(0x12054)
+#define  PWRCTX_MAXCNT_BCSUNIT _MMIO(0x22054)
+#define  PWRCTX_MAXCNT_VECSUNIT_MMIO(0x1A054)
+#define  PWRCTX_MAXCNT_VCSUNIT1_MMIO(0x1C054)
+#define  IDLE_TIME_MASK0xF
  #define  FORCEWAKE_MMIO(0xA18C)
  #define  FORCEWAKE_VLV_MMIO(0x1300b0)
  #define  FORCEWAKE_ACK_VLV_MMIO(0x1300b4)
@@ -6919,6 +6929,7 @@ enum skl_disp_power_wells {
  #define GEN6_RPDEUC   _MMIO(0xA084)
  #define GEN6_RPDEUCSW _MMIO(0xA088)
  #define GEN6_RC_STATE _MMIO(0xA094)
+#define RC6_STATE  (1<<18)
  #define GEN6_RC1_WAKE_RATE_LIMIT  _MMIO(0xA098)
  #define GEN6_RC6_WAKE_RATE_LIMIT  _MMIO(0xA09C)
  #define GEN6_RC6pp_WAKE_RATE_LIMIT_MMIO(0xA0A0)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f620023..aaa2051a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1560,6 +1560,7 @@ void skl_wm_get_hw_state(struct drm_device *dev);
  void 

Re: [Intel-gfx] [RFC 14/22] drm/i915/slpc: Notification of Display mode change

[Kamble, Sagar A]

Thanks for the review Paulo.
Will incorporate the suggestions.

Thanks
Sagar

On 1/21/2016 6:54 PM, Zanoni, Paulo R wrote:

Em Qua, 2016-01-20 às 18:26 -0800, tom.orou...@intel.com escreveu:

From: Sagar Arun Kamble 

GuC SLPC need to be sent data related to Active pipes, refresh rates,
widi pipes, fullscreen pipes related via host to GuC display mode
change event.
This patch defines the event and implements trigger of the event.

Signed-off-by: Sagar Arun Kamble 
Acked-by: Tom O'Rourke 

(this is just a comment from a quick look at the file, not a full
review)


---
  drivers/gpu/drm/i915/intel_display.c |  2 +
  drivers/gpu/drm/i915/intel_slpc.c| 92

  drivers/gpu/drm/i915/intel_slpc.h|  1 +
  3 files changed, 95 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 06ab6df..7c3d902 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13638,6 +13638,8 @@ static int intel_atomic_commit(struct
drm_device *dev,
 */
intel_uncore_arm_unclaimed_mmio_detection(dev_priv);
  
+	intel_slpc_update_display_mode_info(dev);

+
return 0;
  }
  
diff --git a/drivers/gpu/drm/i915/intel_slpc.c

b/drivers/gpu/drm/i915/intel_slpc.c
index f155d88..f5f7cad 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -74,6 +74,27 @@ static int host2guc_slpc_shutdown(struct
drm_i915_private *dev_priv)
return ret;
  }
  
+static int host2guc_slpc_display_mode_change(struct drm_i915_private

*dev_priv)
+{
+u32 data[7];
+   int ret, i;
+
+data[0] = HOST2GUC_ACTION_SLPC_REQUEST;
+data[1] = SLPC_EVENT(SLPC_EVENT_DISPLAY_MODE_CHANGE,
MAX_NUM_OF_PIPE + 1);
+   data[2] = dev_priv-

guc.slpc.display_mode_params.global_data;

+   for(i = 0; i < MAX_NUM_OF_PIPE; ++i)
+   data[3+i] = dev_priv-

guc.slpc.display_mode_params.per_pipe_info[i].data;

+
+ret = host2guc_action(_priv->guc, data, 7);
+
+   if (0 == ret) {

https://en.wikipedia.org/wiki/Yoda_conditions are not part of our usual
coding style.


+   ret = I915_READ(SOFT_SCRATCH(1));
+   ret &= 0xFF;
+   }
+
+   return ret;
+}

There are some tab/space issues in the function above.

Just a suggestion, not a request: for both functions you introduced,
since the only callers do not bother to check the return values, you
could just make the functions return void. Having unchecked return
values may give a false sense that errors would be caught by the upper
layer, when in fact they aren't. In a lot of cases it's better to just
print some error message instead of returning some value that is going
to be ignored.


+
  static u8 slpc_get_platform_sku(struct drm_i915_gem_object *obj)
  {
struct drm_device *dev = obj->base.dev;
@@ -225,3 +246,74 @@ int intel_slpc_reset(struct drm_device *dev)
  
  	return ret;

  }
+
+int intel_slpc_update_display_mode_info(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_crtc *crtc;
+   struct intel_crtc *intel_crtc;
+   struct drm_connector *connector;
+   struct intel_connector *intel_connector;
+   struct drm_encoder *encoder;
+   struct intel_encoder *intel_encoder;
+   struct intel_display_pipe_basic_info *per_pipe_info;
+   struct intel_slpc_display_mode_event_params *cur_params,
old_params;
+   bool notify = false;
+
+   if (!HAS_SLPC(dev))
+   return -EINVAL;
+
+   cur_params = _priv->guc.slpc.display_mode_params;
+
+   /* Copy display mode parameters for comparison */
+   old_params.global_data  = cur_params->global_data;
+   cur_params->global_data = 0;
+
+   for_each_intel_crtc(dev, intel_crtc) {
+   per_pipe_info = _params-

per_pipe_info[intel_crtc->pipe];

+   old_params.per_pipe_info[intel_crtc->pipe].data =
per_pipe_info->data;
+   per_pipe_info->data = 0;
+   }
+
+   for_each_intel_crtc(dev, intel_crtc) {
+   struct intel_crtc_state *pipe_config;
+
+   per_pipe_info = _params-

per_pipe_info[intel_crtc->pipe];

+   crtc = _crtc->base;
+   pipe_config = to_intel_crtc_state(crtc->state);
+
+   if (pipe_config->base.active) {

As far as I understand from the new atomic locking model, since this
code is called from intel_atomic_commit, it can't just iterate through
every crtc/encoder/connector checking state structures. During an
atomic commit we can only look at the objects affected by the commit,
so we have to use things such as for_each_crtc_in_state().

It seems to me that the model here could be:
- At driver load, during or after HW state readout, initialize some
state structure to make it match the hardware.
- Whenever there's an atomic 

Re: [Intel-gfx] [RFC 14/22] drm/i915/slpc: Notification of Display mode change

[Kamble, Sagar A]

Thanks for the review Ville.
I will update the patch.

On 1/22/2016 10:44 PM, Ville Syrjälä wrote:

On Wed, Jan 20, 2016 at 06:26:16PM -0800, tom.orou...@intel.com wrote:

From: Sagar Arun Kamble 

GuC SLPC need to be sent data related to Active pipes, refresh rates,
widi pipes, fullscreen pipes related via host to GuC display mode
change event.
This patch defines the event and implements trigger of the event.

Signed-off-by: Sagar Arun Kamble 
Acked-by: Tom O'Rourke 
---
  drivers/gpu/drm/i915/intel_display.c |  2 +
  drivers/gpu/drm/i915/intel_slpc.c| 92 
  drivers/gpu/drm/i915/intel_slpc.h|  1 +
  3 files changed, 95 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 06ab6df..7c3d902 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13638,6 +13638,8 @@ static int intel_atomic_commit(struct drm_device *dev,
 */
intel_uncore_arm_unclaimed_mmio_detection(dev_priv);
  
+	intel_slpc_update_display_mode_info(dev);

+
return 0;
  }
  
diff --git a/drivers/gpu/drm/i915/intel_slpc.c b/drivers/gpu/drm/i915/intel_slpc.c

index f155d88..f5f7cad 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -74,6 +74,27 @@ static int host2guc_slpc_shutdown(struct drm_i915_private 
*dev_priv)
return ret;
  }
  
+static int host2guc_slpc_display_mode_change(struct drm_i915_private *dev_priv)

+{
+u32 data[7];
+   int ret, i;
+
+data[0] = HOST2GUC_ACTION_SLPC_REQUEST;
+data[1] = SLPC_EVENT(SLPC_EVENT_DISPLAY_MODE_CHANGE, MAX_NUM_OF_PIPE + 
1);
+   data[2] = dev_priv->guc.slpc.display_mode_params.global_data;
+   for(i = 0; i < MAX_NUM_OF_PIPE; ++i)
+   data[3+i] = 
dev_priv->guc.slpc.display_mode_params.per_pipe_info[i].data;
+
+ret = host2guc_action(_priv->guc, data, 7);
+
+   if (0 == ret) {
+   ret = I915_READ(SOFT_SCRATCH(1));
+   ret &= 0xFF;
+   }
+
+   return ret;
+}
+
  static u8 slpc_get_platform_sku(struct drm_i915_gem_object *obj)
  {
struct drm_device *dev = obj->base.dev;
@@ -225,3 +246,74 @@ int intel_slpc_reset(struct drm_device *dev)
  
  	return ret;

  }
+
+int intel_slpc_update_display_mode_info(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_crtc *crtc;
+   struct intel_crtc *intel_crtc;
+   struct drm_connector *connector;
+   struct intel_connector *intel_connector;
+   struct drm_encoder *encoder;
+   struct intel_encoder *intel_encoder;
+   struct intel_display_pipe_basic_info *per_pipe_info;
+   struct intel_slpc_display_mode_event_params *cur_params, old_params;
+   bool notify = false;
+
+   if (!HAS_SLPC(dev))
+   return -EINVAL;
+
+   cur_params = _priv->guc.slpc.display_mode_params;
+
+   /* Copy display mode parameters for comparison */
+   old_params.global_data  = cur_params->global_data;
+   cur_params->global_data = 0;
+
+   for_each_intel_crtc(dev, intel_crtc) {
+   per_pipe_info = _params->per_pipe_info[intel_crtc->pipe];
+   old_params.per_pipe_info[intel_crtc->pipe].data = 
per_pipe_info->data;
+   per_pipe_info->data = 0;
+   }
+
+   for_each_intel_crtc(dev, intel_crtc) {
+   struct intel_crtc_state *pipe_config;
+
+   per_pipe_info = _params->per_pipe_info[intel_crtc->pipe];
+   crtc = _crtc->base;
+   pipe_config = to_intel_crtc_state(crtc->state);
+
+   if (pipe_config->base.active) {
+   for_each_encoder_on_crtc(dev, crtc, intel_encoder) {
+   encoder = _encoder->base;
+   for_each_connector_on_encoder(dev, encoder, 
intel_connector) {
+   connector = _connector->base;
+   if (connector->status == 
connector_status_connected) {

The connecotr/encoder stuff should not be here. We can enable a pipe
without any connected connectors. Also locking is fail.

The patch also fails to explain why the guc needs to know any of this
stuff. It makes me very suspicious that the guc is going to start
poking at some display stuff behind the driver's back. I actually
think that doing some display stuff in the guc might be neat, but not
when it's a black box blob.


+   struct drm_display_mode *mode = 
>mode;
+   /* FIXME: Update is_widi based 
on encoder */
+   per_pipe_info->is_widi = 0;
+   per_pipe_info->refresh_rate = 
mode->vrefresh;
+

Re: [Intel-gfx] Why idle_freq is set to RPn and not RPe

[Kamble, Sagar A]

On 12/30/2015 4:20 PM, Chris Wilson wrote:

On Wed, Dec 30, 2015 at 04:09:46PM +0530, Kamble, Sagar A wrote:

Turbo frequency range is Rpe to Rp0 when GPU is active as, on workload
submission frequency is taken to Rpe.

Does the HW require us to drop to RPn before entering RC6?
If we can enter RC6 even with other frequencies I think we can keep
running at Rpe on Idle.

Remember that we quite frequently prevent the hardware going into RC6,
I assume this is threshold times in TO/EI mode for which GT is idle but 
not power gated.

and that it has been known for the hardware to fail to enter RC6 itself
(through driver error or whatnot).
And assume this is because of forcewake/rc6 setup errors in driver paths 
which should not happen in best case :)

Agree that running at Rpn makes sense.

  Going to the extreme, why wouldn't
you set Rp0 on idle, since that will give the best restart latency?
True. We can have different logic that starts from Rp0 and comes down if 
perf is met.

-Chris


Thanks for the inputs Chris.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Why idle_freq is set to RPn and not RPe

[Kamble, Sagar A]

Hi Chris,

With below commit, idle frequency is made RPn (HW Min).
Why are we not keeping it at RPe (Efficient Frequency)?
My understanding was to set Rpe on idle so that when GPU is out of RC6 
it can start operating at efficient frequency.


commit aed242ff7ebb697e4dff912bd4dc7ec7192f7581
Author: Chris Wilson 
Date:   Wed Mar 18 09:48:21 2015 +

drm/i915: Relax RPS contraints to allows setting minfreq on idle


Thanks
Sagar

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

Re: [Intel-gfx] Why idle_freq is set to RPn and not RPe

[Kamble, Sagar A]

Turbo frequency range is Rpe to Rp0 when GPU is active as, on workload 
submission frequency is taken to Rpe.


Does the HW require us to drop to RPn before entering RC6?
If we can enter RC6 even with other frequencies I think we can keep 
running at Rpe on Idle.


Only benefit of running at Rpn might be some additional power saving 
when workload is very lightweight. Is that correct Chris?



Thanks
Sagar



On 12/30/2015 3:20 PM, Szwichtenberg, Radoslaw wrote:

Hello Chris!

The question is: why this change in behavior was made?

On previous platforms Gfx Turbo frequency selection range in driver was in between 
Rpe & Rp0. Since Rpe is the possible Fmax at Vmin, it was used as the starting 
frequency once driver booted and any value lower than that was not requested.

Thanks!
Radek


-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Wednesday, December 30, 2015 10:31 AM
To: Kamble, Sagar A
Cc: S, Deepak; Szwichtenberg, Radoslaw; Intel Graphics Development; Goel,
Akash
Subject: Re: Why idle_freq is set to RPn and not RPe

On Wed, Dec 30, 2015 at 02:51:27PM +0530, Kamble, Sagar A wrote:

Hi Chris,

With below commit, idle frequency is made RPn (HW Min).
Why are we not keeping it at RPe (Efficient Frequency)?
My understanding was to set Rpe on idle so that when GPU is out of
RC6 it can start operating at efficient frequency.

The driver is *idle*. When there is work to be submitted to the GPU, then
we go back to RPe (though we wait for it to wake up first). RPe is just an
inflexion point on the power curve.
-Chris

--
Chris Wilson, Intel Open Source Technology Centre


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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Apply broader WaRsDisableCoarsePowerGating for guc also

[Kamble, Sagar A]

Reviewed-by: Sagar Arun Kamble 

On 12/16/2015 10:48 PM, Mika Kuoppala wrote:

commit 344df9809f45 ("drm/i915/skl: Disable coarse power gating up until F0")
failed to take into account that the same workaround is used in guc
when forcewake is sampled.

Wrap the condition check inside a macro and use it in both places
to fix the guc side scope.

Cc: Dave Gordon 
Cc: Sagar Arun Kamble 
Signed-off-by: Mika Kuoppala 
---
  drivers/gpu/drm/i915/i915_drv.h| 5 +
  drivers/gpu/drm/i915/i915_guc_submission.c | 6 ++
  drivers/gpu/drm/i915/intel_pm.c| 4 +---
  3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 18be127f5678..bd667a17ad96 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2564,6 +2564,11 @@ struct drm_i915_cmd_table {
  
  /* Early gen2 have a totally busted CS tlb and require pinned batches. */

  #define HAS_BROKEN_CS_TLB(dev)(IS_I830(dev) || IS_845G(dev))
+
+/* WaRsDisableCoarsePowerGating:skl,bxt */
+#define NEEDS_WaRsDisableCoarsePowerGating(dev) (IS_BXT_REVID(dev, 0, 
BXT_REVID_A1) || \
+((IS_SKL_GT3(dev) || IS_SKL_GT4(dev)) 
&& \
+ IS_SKL_REVID(dev, 0, 
SKL_REVID_F0)))
  /*
   * dp aux and gmbus irq on gen4 seems to be able to generate legacy interrupts
   * even when in MSI mode. This results in spurious interrupt warnings if the
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 05aa7e61cbe0..9cc3b8474dae 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -158,10 +158,8 @@ static int host2guc_sample_forcewake(struct intel_guc *guc,
  
  	data[0] = HOST2GUC_ACTION_SAMPLE_FORCEWAKE;

/* WaRsDisableCoarsePowerGating:skl,bxt */
-   if (!intel_enable_rc6(dev_priv->dev) ||
-   IS_BXT_REVID(dev, 0, BXT_REVID_A1) ||
-   (IS_SKL_GT3(dev) && IS_SKL_REVID(dev, 0, SKL_REVID_E0)) ||
-   (IS_SKL_GT4(dev) && IS_SKL_REVID(dev, 0, SKL_REVID_E0)))
+   if (!intel_enable_rc6(dev) ||
+   NEEDS_WaRsDisableCoarsePowerGating(dev))
data[1] = 0;
else
/* bit 0 and 1 are for Render and Media domain separately */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d385d9991eed..e1de96099924 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4713,9 +4713,7 @@ static void gen9_enable_rc6(struct drm_device *dev)
 * 3b: Enable Coarse Power Gating only when RC6 is enabled.
 * WaRsDisableCoarsePowerGating:skl,bxt - Render/Media PG need to be 
disabled with RC6.
 */
-   if (IS_BXT_REVID(dev, 0, BXT_REVID_A1) ||
-   ((IS_SKL_GT3(dev) || IS_SKL_GT4(dev)) &&
-IS_SKL_REVID(dev, 0, SKL_REVID_F0)))
+   if (NEEDS_WaRsDisableCoarsePowerGating(dev))
I915_WRITE(GEN9_PG_ENABLE, 0);
else
I915_WRITE(GEN9_PG_ENABLE, (rc6_mask & GEN6_RC_CTL_RC6_ENABLE) ?


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

Re: [Intel-gfx] [PATCH 2/2] igt/pm_rps: Add checks for freq = idle (RPn) in specific cases.

[Kamble, Sagar A]

On 12/4/2015 8:52 PM, Imre Deak wrote:

On to, 2015-12-03 at 16:43 -0800, Bob Paauwe wrote:

On Tue, 1 Dec 2015 19:43:05 +0200
Imre Deak  wrote:


On ti, 2015-12-01 at 09:22 -0800, Bob Paauwe wrote:

On Tue, 1 Dec 2015 15:56:55 +0200
Imre Deak  wrote:


On ma, 2015-11-30 at 16:23 -0800, Bob Paauwe wrote:

Now that the frequency can drop below the user specified
minimum
when
the gpu is idle, add some checking to verify that it really
does
drop
down to the RPn frequency in specific cases.

To do this, modify the main test flow to take two 'check'
routines
instead of one. When running the config-min-max-idle subtest
make
use of the second check routine to verify that the frequency
drops
to RPn instead of simply <= user min frequency.  For all
other
subtests, use the original check routines for both checks.

Signed-off-by: Bob Paauwe 

I don't see the point. The frequency should always drop to the
idle
frequency if the GPU is idle, it's not enough that it's below
MIN-
freq.
So why do we need separate CUR-freq<=MIN-freq and CUR-
freq==idle-
freq
checks?

I started from the premise that it should always drop to idle but
that's just not the case.

It is the correct premise and if it doesn't hold then there is a
real
bug either in the testcase or the kernel which needs to be
addressed
differently. I haven't found anything concrete but one suspect is
the
logic that waits for the GPU idle condition, maybe the timeout
value idle_check() or the hard-coded duration in do_load_gpu() is
incorrect. In any case let's not paper over this issue, the very
reason
we have test cases is to uncover such bugs.


The min_max_config() function is used for
both the idle and loaded subtests.  If you try to check for
freq=idle
when doing the loaded subtest it will fail since it never goes
idle.
Even in the idle subtest there are cases where it doesn't drop
down
to
idle.

The only place we should check for freq==idle is in idle_check()
and
that one is not called during the loaded subtest, it wouldn't even
make
sense to do so. So I'm not sure how this subtest fails for you.


I suppose I could duplicate min_max_config and have a
min_max_config_idle() and min_max_conifg_not_idle() for use by
the
different subtests.

The point of the "check" argument of min_max_config() is to
distinguish
between the idle and loaded cases. The check functions passed in
know
already if they can expect the frequency to reach the idle
frequency
or not.


The real problem is that the test was not designed to handle the
case
where the freq could drop below min and probably needs to be
re-designed.  I've been trying to find a quick fix vs. a complete
overhaul as this isn't really a priority for me.

I think we only need your first patch and if there is any failure
after
that we have to root cause that and fix it properly.

--Imre

You're right.  I'm working with BXT and it seems like it's got some
unique issues with RPS.  I just sent a new patch based on the first
one
but with the changes you suggested to check for ==idle instead of
<=min.

Maybe you have some insights into what I'm seeing with BXT?  The first
problem I had was that I would see threshold up interrupts but not any
threshold down interrupts.  The missing down interrupts was related to
the BIOS setting.  I had runtime PM disabled so it seems strange that I
was getting the up interrupts.

How was runtime pM disabled? Think RPM and RPS are not related.

Yes, I saw this too. I wonder if we could check this somehow and not
enable RPS if BIOS hasn't set things up properly. Sagar has a patch
that checks the RC6 setup [1]; that's not exactly RPS, but since they
are setup at the same place I think we could use that for now for RPS
too.
FYI Turbo is disabled until A1 due to issues with RC6 enabled. Which 
registers exactly do we need to check
from BIOS RPS programming perspective? I see that RP control is set by 
BIOS ... Is that check enough?



With the BIOS setting corrected, the driver started disabling the down
interrupts once the freq dropped to min or just below because of the min
vs. idle difference.  I have a patch for this that I'll send shortly.

Hm, that's not necessarily a problem. To reach the idle frequency we
don't depend on the up/down interrupts. The idle frequency gets set
explicitly from intel_mark_idle(), so if you don't reach the idle freq
then this function doesn't get called for some reason. Or as I said
earlier we just don't wait enough in do_load_gpu() or idle_check() in
the test, so we read out cur-freq before intel_mark_idle() would get
called.


The remaining issue seems to be some type of timing issue. I've had
to
add a 35000us sleep between updating the interrupt enable register
(0xA168) and the posting read of freq. register (0xA008), otherwise
it
acts like the change to the interrupt enable register never happened.
None of the documentation I have indicates that this is needed.

What happens exactly? The 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/skl: Disable coarse power gating up until F0

[Kamble, Sagar A]

Reviewed-by: Sagar Arun Kamble 

On 12/7/2015 9:59 PM, Mika Kuoppala wrote:

There is conflicting info between E0 and F0 steppings
for this workarounds. Trust more authoritative source and
be conservative and extend also for F0.

This prevents numerous (>50) gpu hangs with SKL GT4e
during piglit run.

References: HSD: gen9lp/2134184
Cc: Sagar Arun Kamble 
Signed-off-by: Mika Kuoppala 
---
  drivers/gpu/drm/i915/intel_pm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ee05ce8..7096c06 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4717,7 +4717,7 @@ static void gen9_enable_rc6(struct drm_device *dev)
 */
if (IS_BXT_REVID(dev, 0, BXT_REVID_A1) ||
((IS_SKL_GT3(dev) || IS_SKL_GT4(dev)) &&
-IS_SKL_REVID(dev, 0, SKL_REVID_E0)))
+IS_SKL_REVID(dev, 0, SKL_REVID_F0)))
I915_WRITE(GEN9_PG_ENABLE, 0);
else
I915_WRITE(GEN9_PG_ENABLE, (rc6_mask & GEN6_RC_CTL_RC6_ENABLE) ?


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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl: Double RC6 WRL always on

[Kamble, Sagar A]

Reviewed-by: Sagar Arun Kamble 

On 12/7/2015 9:59 PM, Mika Kuoppala wrote:

WaRsDoubleRc6WrlWithCoarsePowerGating should
be enabled for all Skylakes. Make it so.

Cc: Sagar Arun Kamble 
Signed-off-by: Mika Kuoppala 
---
  drivers/gpu/drm/i915/intel_pm.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7096c06..8598456 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4673,8 +4673,7 @@ static void gen9_enable_rc6(struct drm_device *dev)
/* 2b: Program RC6 thresholds.*/
  
  	/* WaRsDoubleRc6WrlWithCoarsePowerGating: Doubling WRL only when CPG is enabled */

-   if (IS_SKYLAKE(dev) && !((IS_SKL_GT3(dev) || IS_SKL_GT4(dev)) &&
-IS_SKL_REVID(dev, 0, SKL_REVID_E0)))
+   if (IS_SKYLAKE(dev))
I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 108 << 16);
else
I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 54 << 16);


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

Re: [Intel-gfx] [PATCH v3] drm/i915/guc: Add host2guc notification for suspend and resume

[Kamble, Sagar A]

Reviewed-by: Sagar Arun Kamble 

On 9/30/2015 10:16 PM, yu@intel.com wrote:

From: Alex Dai 

Add host2guc interface to notify GuC power state changes when
enter or resume from power saving state.

v3: Move intel_guc_suspend to i915_drm_suspend for consistency.

v2: Add GuC suspend/resume to runtime suspend/resume too

v1: Change to a more flexible way when fill host to GuC scratch
data in order to remove hard coding.

Signed-off-by: Alex Dai 
---
  drivers/gpu/drm/i915/i915_drv.c|  8 +
  drivers/gpu/drm/i915/i915_guc_submission.c | 50 ++
  drivers/gpu/drm/i915/intel_guc.h   |  2 ++
  drivers/gpu/drm/i915/intel_guc_fwif.h  |  8 +
  drivers/gpu/drm/i915/intel_guc_loader.c|  4 ++-
  5 files changed, 71 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1cb6b82..760e0ce 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -638,6 +638,8 @@ static int i915_drm_suspend(struct drm_device *dev)
return error;
}
  
+	intel_guc_suspend(dev);

+
intel_suspend_gt_powersave(dev);
  
  	/*

@@ -767,6 +769,8 @@ static int i915_drm_resume(struct drm_device *dev)
}
mutex_unlock(>struct_mutex);
  
+	intel_guc_resume(dev);

+
intel_modeset_init_hw(dev);
  
  	spin_lock_irq(_priv->irq_lock);

@@ -1500,6 +1504,8 @@ static int intel_runtime_suspend(struct device *device)
i915_gem_release_all_mmaps(dev_priv);
mutex_unlock(>struct_mutex);
  
+	intel_guc_suspend(dev);

+
intel_suspend_gt_powersave(dev);
intel_runtime_pm_disable_interrupts(dev_priv);
  
@@ -1559,6 +1565,8 @@ static int intel_runtime_resume(struct device *device)

intel_opregion_notify_adapter(dev, PCI_D0);
dev_priv->pm.suspended = false;
  
+	intel_guc_resume(dev);

+
if (IS_GEN6(dev_priv))
intel_init_pch_refclk(dev);
  
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c

index 0b1797f..036b42b 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -923,3 +923,53 @@ void i915_guc_submission_fini(struct drm_device *dev)
gem_release_guc_obj(guc->ctx_pool_obj);
guc->ctx_pool_obj = NULL;
  }
+
+/**
+ * intel_guc_suspend() - notify GuC entering suspend state
+ * @dev:   drm device
+ */
+int intel_guc_suspend(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_guc *guc = _priv->guc;
+   struct intel_context *ctx;
+   u32 data[3];
+
+   if (!i915.enable_guc_submission)
+   return 0;
+
+   ctx = dev_priv->ring[RCS].default_context;
+
+   data[0] = HOST2GUC_ACTION_ENTER_S_STATE;
+   /* any value greater than GUC_POWER_D0 */
+   data[1] = GUC_POWER_D1;
+   /* first page is shared data with GuC */
+   data[2] = i915_gem_obj_ggtt_offset(ctx->engine[RCS].state);
+
+   return host2guc_action(guc, data, ARRAY_SIZE(data));
+}
+
+
+/**
+ * intel_guc_resume() - notify GuC resuming from suspend state
+ * @dev:   drm device
+ */
+int intel_guc_resume(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_guc *guc = _priv->guc;
+   struct intel_context *ctx;
+   u32 data[3];
+
+   if (!i915.enable_guc_submission)
+   return 0;
+
+   ctx = dev_priv->ring[RCS].default_context;
+
+   data[0] = HOST2GUC_ACTION_EXIT_S_STATE;
+   data[1] = GUC_POWER_D0;
+   /* first page is shared data with GuC */
+   data[2] = i915_gem_obj_ggtt_offset(ctx->engine[RCS].state);
+
+   return host2guc_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 63e73f3..5ba5866 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -116,6 +116,8 @@ extern void intel_guc_ucode_init(struct drm_device *dev);
  extern int intel_guc_ucode_load(struct drm_device *dev);
  extern void intel_guc_ucode_fini(struct drm_device *dev);
  extern const char *intel_guc_fw_status_repr(enum intel_guc_fw_status status);
+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_submission_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index f0a9e82..d25c5b7 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -293,12 +293,20 @@ struct guc_context_desc {
  #define GUC_FORCEWAKE_RENDER  (1 << 0)
  #define GUC_FORCEWAKE_MEDIA   (1 << 1)
  
+#define GUC_POWER_UNSPECIFIED	0

+#define GUC_POWER_D0   1
+#define GUC_POWER_D1   2

Re: [Intel-gfx] [PATCH] drm/i915/guc: Don't forward flip interrupts to GuC

[Kamble, Sagar A]

On 10/1/2015 2:22 PM, Jani Nikula wrote:

On Thu, 01 Oct 2015, Daniel Vetter  wrote:

On Wed, Sep 30, 2015 at 10:16:14AM -0700, O'Rourke, Tom wrote:

On Wed, Sep 30, 2015 at 09:57:37AM -0700, yu@intel.com wrote:

From: Sagar Arun Kamble 

Due to flip interrupts GuC stays awake always and GT does not enter
RC6. Do not route those interrupts to GuC for now. Driver won't touch
DE_GUCRMR register and leave it as what default value.

Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Alex Dai 

[TOR:] This patch was previously sent.  Still looks good to me.

Yeah when resending reviewed patches please include the r-b tag to avoid
wasting people's time.

Reviewed-by: Tom O'Rourke 

Queued for -next, thanks for the patch.

Hmm, what's the impact on skl rc6 in v4.3?

This change was prepared with v4.3 firmware.
Even with GuC v4.3 firmware, SKL RC6 does not work if flip interrupts 
are routed to GuC.


BR,
Jani.




-Daniel


---
  drivers/gpu/drm/i915/intel_guc_loader.c | 10 --
  1 file changed, 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index ae85366..934b003 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -90,9 +90,6 @@ static void direct_interrupts_to_host(struct drm_i915_private 
*dev_priv)
for_each_ring(ring, dev_priv, i)
I915_WRITE(RING_MODE_GEN7(ring), irqs);
  
-	/* tell DE to send nothing to GuC */

-   I915_WRITE(DE_GUCRMR, ~0);
-
/* route all GT interrupts to the host */
I915_WRITE(GUC_BCS_RCS_IER, 0);
I915_WRITE(GUC_VCS2_VCS1_IER, 0);
@@ -110,13 +107,6 @@ static void direct_interrupts_to_guc(struct 
drm_i915_private *dev_priv)
for_each_ring(ring, dev_priv, i)
I915_WRITE(RING_MODE_GEN7(ring), irqs);
  
-	/* tell DE to send (all) flip_done to GuC */

-   irqs = DERRMR_PIPEA_PRI_FLIP_DONE | DERRMR_PIPEA_SPR_FLIP_DONE |
-  DERRMR_PIPEB_PRI_FLIP_DONE | DERRMR_PIPEB_SPR_FLIP_DONE |
-  DERRMR_PIPEC_PRI_FLIP_DONE | DERRMR_PIPEC_SPR_FLIP_DONE;
-   /* Unmasked bits will cause GuC response message to be sent */
-   I915_WRITE(DE_GUCRMR, ~irqs);
-
/* route USER_INTERRUPT to Host, all others are sent to GuC. */
irqs = GT_RENDER_USER_INTERRUPT << GEN8_RCS_IRQ_SHIFT |
   GT_RENDER_USER_INTERRUPT << GEN8_BCS_IRQ_SHIFT;
--
1.9.1

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

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

--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Add host2guc notification for suspend and resume

[Kamble, Sagar A]

Thanks for the updated patch. Minor comment below.

Thanks
Sagar

On 9/26/2015 12:16 AM, yu@intel.com wrote:

From: Alex Dai 

Add host2guc interfaces to nofigy GuC power state changes when
enter or resume from power saving state.

v2: Add GuC suspend/resume to runtime suspend/resume too

v1: Change to a more flexible way when fill host to GuC scratch
data in order to remove hard coding.

Signed-off-by: Alex Dai 
---
  drivers/gpu/drm/i915/i915_drv.c|  5 +++
  drivers/gpu/drm/i915/i915_gem.c|  2 ++
  drivers/gpu/drm/i915/i915_guc_submission.c | 50 ++
  drivers/gpu/drm/i915/intel_guc.h   |  2 ++
  drivers/gpu/drm/i915/intel_guc_fwif.h  |  8 +
  drivers/gpu/drm/i915/intel_guc_loader.c|  4 ++-
  6 files changed, 70 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e6d7a69..842eb13 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -737,6 +737,8 @@ static int i915_drm_resume(struct drm_device *dev)
}
mutex_unlock(>struct_mutex);
  
+	intel_guc_resume(dev);

+
intel_modeset_init_hw(dev);
  
  	spin_lock_irq(_priv->irq_lock);

@@ -1476,6 +1478,7 @@ static int intel_runtime_suspend(struct device *device)
i915_gem_release_all_mmaps(dev_priv);
mutex_unlock(>struct_mutex);
  
+	intel_guc_suspend(dev);

intel_suspend_gt_powersave(dev);
intel_runtime_pm_disable_interrupts(dev_priv);
  
@@ -1535,6 +1538,8 @@ static int intel_runtime_resume(struct device *device)

intel_opregion_notify_adapter(dev, PCI_D0);
dev_priv->pm.suspended = false;
  
+	intel_guc_resume(dev);

+
if (IS_GEN6(dev_priv))
intel_init_pch_refclk(dev);
  
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c

index bf5ef7a..679ed55 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4460,6 +4460,8 @@ i915_gem_suspend(struct drm_device *dev)
i915_gem_stop_ringbuffers(dev);
mutex_unlock(>struct_mutex);
  
+	intel_guc_suspend(dev);

+
Should this be called as part of i915_drm_suspend for consistency 
instead of i915_gem_suspend?

cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
cancel_delayed_work_sync(_priv->mm.retire_work);
flush_delayed_work(_priv->mm.idle_work);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 792d0b9..38b6ef4 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -914,3 +914,53 @@ void i915_guc_submission_fini(struct drm_device *dev)
gem_release_guc_obj(guc->ctx_pool_obj);
guc->ctx_pool_obj = NULL;
  }
+
+/**
+ * intel_guc_suspend() - notify GuC entering suspend state
+ * @dev:   drm device
+ */
+int intel_guc_suspend(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_guc *guc = _priv->guc;
+   struct intel_context *ctx;
+   u32 data[3];
+
+   if (!i915.enable_guc_submission)
+   return 0;
+
+   ctx = dev_priv->ring[RCS].default_context;
+
+   data[0] = HOST2GUC_ACTION_ENTER_S_STATE;
+   /* any value greater than GUC_POWER_D0 */
+   data[1] = GUC_POWER_D1;
+   /* first page is shared data with GuC */
+   data[2] = i915_gem_obj_ggtt_offset(ctx->engine[RCS].state);
+
+   return host2guc_action(guc, data, ARRAY_SIZE(data));
+}
+
+
+/**
+ * intel_guc_resume() - notify GuC resuming from suspend state
+ * @dev:   drm device
+ */
+int intel_guc_resume(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_guc *guc = _priv->guc;
+   struct intel_context *ctx;
+   u32 data[3];
+
+   if (!i915.enable_guc_submission)
+   return 0;
+
+   ctx = dev_priv->ring[RCS].default_context;
+
+   data[0] = HOST2GUC_ACTION_EXIT_S_STATE;
+   data[1] = GUC_POWER_D0;
+   /* first page is shared data with GuC */
+   data[2] = i915_gem_obj_ggtt_offset(ctx->engine[RCS].state);
+
+   return host2guc_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 55c9bf8..39cf460 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -116,6 +116,8 @@ extern void intel_guc_ucode_init(struct drm_device *dev);
  extern int intel_guc_ucode_load(struct drm_device *dev);
  extern void intel_guc_ucode_fini(struct drm_device *dev);
  extern const char *intel_guc_fw_status_repr(enum intel_guc_fw_status status);
+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_submission_init(struct drm_device *dev);
diff --git 

Re: [Intel-gfx] [PATCH v2 3/6] drm/i915/guc: Add host2guc notification for suspend and resume

[Kamble, Sagar A]

On 9/23/2015 2:18 AM, yu@intel.com wrote:

From: Alex Dai 

Add host2guc interfaces to nofigy GuC power state changes when

*notify

enter or resume from power saving state.

v1: Change to a more flexible way when fill host to GuC scratch
data in order to remove hard coding.

Signed-off-by: Alex Dai 
---
  drivers/gpu/drm/i915/i915_drv.c|  1 +
  drivers/gpu/drm/i915/i915_gem.c|  1 +
  drivers/gpu/drm/i915/i915_guc_submission.c | 50 ++
  drivers/gpu/drm/i915/intel_guc.h   |  2 ++
  drivers/gpu/drm/i915/intel_guc_fwif.h  |  8 +
  drivers/gpu/drm/i915/intel_guc_loader.c|  4 ++-
  6 files changed, 65 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e2bf9e2..8f2a139 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -735,6 +735,7 @@ static int i915_drm_resume(struct drm_device *dev)
DRM_ERROR("failed to re-initialize GPU, declaring wedged!\n");
atomic_or(I915_WEDGED, 
_priv->gpu_error.reset_counter);
}
+   intel_guc_resume(dev);

Need to call from intel_runtime_resume as well.

mutex_unlock(>struct_mutex);
  
  	intel_modeset_init_hw(dev);

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 46f0e83..92dd4ff 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4458,6 +4458,7 @@ i915_gem_suspend(struct drm_device *dev)
i915_gem_retire_requests(dev);
  
  	i915_gem_stop_ringbuffers(dev);

+   intel_guc_suspend(dev);

Should this be called as part of i915_drm_suspend for consistency?
Need to call from intel_runtime_suspend as well.

mutex_unlock(>struct_mutex);
  
  	cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 792d0b9..38b6ef4 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -914,3 +914,53 @@ void i915_guc_submission_fini(struct drm_device *dev)
gem_release_guc_obj(guc->ctx_pool_obj);
guc->ctx_pool_obj = NULL;
  }
+
+/**
+ * intel_guc_suspend() - notify GuC entering suspend state
+ * @dev:   drm device
+ */
+int intel_guc_suspend(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_guc *guc = _priv->guc;
+   struct intel_context *ctx;
+   u32 data[3];
+
+   if (!i915.enable_guc_submission)
+   return 0;
+
+   ctx = dev_priv->ring[RCS].default_context;
+
+   data[0] = HOST2GUC_ACTION_ENTER_S_STATE;
+   /* any value greater than GUC_POWER_D0 */
+   data[1] = GUC_POWER_D1;
+   /* first page is shared data with GuC */
+   data[2] = i915_gem_obj_ggtt_offset(ctx->engine[RCS].state);
+
+   return host2guc_action(guc, data, ARRAY_SIZE(data));
+}
+
+
+/**
+ * intel_guc_resume() - notify GuC resuming from suspend state
+ * @dev:   drm device
+ */
+int intel_guc_resume(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_guc *guc = _priv->guc;
+   struct intel_context *ctx;
+   u32 data[3];
+
+   if (!i915.enable_guc_submission)
+   return 0;
+
+   ctx = dev_priv->ring[RCS].default_context;
+
+   data[0] = HOST2GUC_ACTION_EXIT_S_STATE;
+   data[1] = GUC_POWER_D0;
+   /* first page is shared data with GuC */
+   data[2] = i915_gem_obj_ggtt_offset(ctx->engine[RCS].state);
+
+   return host2guc_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 e1389fc..e90c156 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -110,6 +110,8 @@ extern void intel_guc_ucode_init(struct drm_device *dev);
  extern int intel_guc_ucode_load(struct drm_device *dev);
  extern void intel_guc_ucode_fini(struct drm_device *dev);
  extern const char *intel_guc_fw_status_repr(enum intel_guc_fw_status status);
+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_submission_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 006dc0d..f6d0aa4 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -254,12 +254,20 @@ struct guc_context_desc {
u64 desc_private;
  } __packed;
  
+#define GUC_POWER_UNSPECIFIED	0

+#define GUC_POWER_D0   1
+#define GUC_POWER_D1   2
+#define GUC_POWER_D2   3
+#define GUC_POWER_D3   4
+
  /* This Action will be programmed in C180 - SOFT_SCRATCH_O_REG */
  enum host2guc_action {

Re: [Intel-gfx] [PATCH v2 7/7] drm/i915/bxt: WaGsvDisableTurbo

[Kamble, Sagar A]

Hi Alex,

Could you review and provide r-b tag for 3rd rev: 
http://lists.freedesktop.org/archives/intel-gfx/2015-September/076223.html


Thanks
Sagar


On 9/22/2015 12:20 AM, Yu Dai wrote:

Looks good to me.
Reviewed-by: Alex Dai 

On 09/11/2015 09:47 PM, Sagar Arun Kamble wrote:
Disable Turbo on steppings prior to B0 on BXT due to hangs seen 
during GT CPD exit.


Change-Id: I50c5c03f59f5ba092db19e17234951d89db42c6c
Signed-off-by: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/intel_pm.c | 10 ++
  1 file changed, 10 insertions(+)

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

index 6843a48..90d8834 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4473,6 +4473,10 @@ static void gen6_set_rps(struct drm_device 
*dev, u8 val)

  {
  struct drm_i915_private *dev_priv = dev->dev_private;
  +/* WaGsvDisableTurbo: Workaround to disable turbo on BXT A* */
+if (IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0))
+return;
+
  WARN_ON(!mutex_is_locked(_priv->rps.hw_lock));
  WARN_ON(val > dev_priv->rps.max_freq);
  WARN_ON(val < dev_priv->rps.min_freq);
@@ -4793,6 +4797,12 @@ static void gen9_enable_rps(struct drm_device 
*dev)

gen6_init_rps_frequencies(dev);
  +/* WaGsvDisableTurbo: Workaround to disable turbo on BXT A* */
+if (IS_BROXTON(dev) && (INTEL_REVID(dev) < BXT_REVID_B0)) {
+intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+return;
+}
+
  /* Program defaults and thresholds for RPS*/
  I915_WRITE(GEN6_RC_VIDEO_FREQ,
  GEN9_FREQUENCY(dev_priv->rps.rp1_freq));




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

Re: [Intel-gfx] [PATCH v2 3/7] drm/i915: WaRsUseTimeoutMode

[Kamble, Sagar A]

Thank you.
I am sending another change Tom wanted as part of this patch.
Kindly stash into the current patch.

Thanks
Sagar


On 9/23/2015 2:20 PM, Daniel Vetter wrote:

On Sat, Sep 12, 2015 at 10:17:52AM +0530, Sagar Arun Kamble wrote:

Enable TO mode for RC6 for SKL till D0 and BXT till A0.

Cc: Tom O'Rourke 
Cc: Akash Goel 
Signed-off-by: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/intel_pm.c | 13 ++---
  1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c93d3a7..6e4818d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4847,9 +4847,16 @@ static void gen9_enable_rc6(struct drm_device *dev)
rc6_mask = GEN6_RC_CTL_RC6_ENABLE;
DRM_INFO("RC6 %s\n", (rc6_mask & GEN6_RC_CTL_RC6_ENABLE) ?
"on" : "off");
-   I915_WRITE(GEN6_RC_CONTROL, GEN6_RC_CTL_HW_ENABLE |
-  GEN6_RC_CTL_EI_MODE(1) |
-  rc6_mask);
+
+   if ((IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_D0) ||
+   (IS_BROXTON(dev) && INTEL_REVID(dev) <= BXT_REVID_A0))

Again I fixed the continuation alignment here ...
-Daniel


+I915_WRITE(GEN6_RC_CONTROL, GEN6_RC_CTL_HW_ENABLE |
+GEN7_RC_CTL_TO_MODE |
+rc6_mask);
+else
+I915_WRITE(GEN6_RC_CONTROL, GEN6_RC_CTL_HW_ENABLE |
+GEN6_RC_CTL_EI_MODE(1) |
+rc6_mask);
  
  	/*

 * 3b: Enable Coarse Power Gating only when RC6 is enabled.
--
1.9.1

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


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

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915: Fix fb object's frontbuffer-bits

[Kamble, Sagar A]

On 9/23/2015 1:51 PM, Daniel Vetter wrote:

On Wed, Sep 16, 2015 at 12:46:24PM -0300, Paulo Zanoni wrote:

2015-09-14 14:16 GMT-03:00 Daniel Vetter :

On Mon, Sep 14, 2015 at 09:35:42PM +0530, Sagar Arun Kamble wrote:

Shared frontbuffer bits are causing warnings when same FB is displayed
in another plane without clearing the bits from previous plane.

v2: Removing coversion of fb bits to 64 bit as it is not needed for now. 
(Daniel)

Change-Id: Ic2df80747f314b82afd22f8326297c57d1e652c6
Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Kumar, Mahesh 
---
  drivers/gpu/drm/i915/i915_drv.h | 17 ++---
  drivers/gpu/drm/i915/intel_sprite.c |  2 +-
  2 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 16e604e..892aa78 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2014,25 +2014,28 @@ struct drm_i915_gem_object_ops {

  /*
   * Frontbuffer tracking bits. Set in obj->frontbuffer_bits while a gem bo is
- * considered to be the frontbuffer for the given plane interface-vise. This
+ * considered to be the frontbuffer for the given plane interface-wise. This
   * doesn't mean that the hw necessarily already scans it out, but that any
   * rendering (by the cpu or gpu) will land in the frontbuffer eventually.
   *
   * We have one bit per pipe and per scanout plane type.
   */
-#define INTEL_FRONTBUFFER_BITS_PER_PIPE 4
+#define INTEL_MAX_SPRITE_BITS_PER_PIPE 5
+#define INTEL_FRONTBUFFER_BITS_PER_PIPE 8
  #define INTEL_FRONTBUFFER_BITS \
   (INTEL_FRONTBUFFER_BITS_PER_PIPE * I915_MAX_PIPES)
  #define INTEL_FRONTBUFFER_PRIMARY(pipe) \
   (1 << (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
  #define INTEL_FRONTBUFFER_CURSOR(pipe) \
- (1 << (1 +(INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
-#define INTEL_FRONTBUFFER_SPRITE(pipe) \
- (1 << (2 +(INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
+ (1 << (1 + (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
+#define INTEL_FRONTBUFFER_SPRITE(pipe, plane) \
+ (1 << (2 + plane + (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
  #define INTEL_FRONTBUFFER_OVERLAY(pipe) \
- (1 << (3 +(INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
+ (1 << (2 + INTEL_MAX_SPRITE_BITS_PER_PIPE + 
(INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
  #define INTEL_FRONTBUFFER_ALL_MASK(pipe) \
- (0xf << (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
+ (0xff << (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
+#define INTEL_FRONTBUFFER_SPRITE_MASK(pipe) \
+ (0x7C << (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))

Patch was a bit confusing to read since tons of spurious whitespace
change. Anyway looks good once applied except for
INTEL_FRONTBUFFER_SPRITE_MASK which is unused and hence I removed it
again.

Queued for -next, thanks for the patch.

Maybe we could have an IGT test for this...

Excellent point. Sagar, can you please supply the missing igt for this
issue?

Yes. Will start preparing.

Thanks
Sagar



Thanks, Daniel


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