[Intel-gfx] [PATCH i-g-t 1/1] tools/intel_guc_logger: Send GuC log level in new i915 expected format

[Sagar Arun Kamble]

i915 expects GuC log level to be specified as:
0: disabled
1: enabled (verbosity level 0 = min)
2: enabled (verbosity level 1)
3: enabled (verbosity level 2)
4: enabled (verbosity level 3 = max)

Remove the earlier internal layout based logging control from
guc_log_control and send new expected values.

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
---
 tools/intel_guc_logger.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/tools/intel_guc_logger.c b/tools/intel_guc_logger.c
index 031fd84..e695497 100644
--- a/tools/intel_guc_logger.c
+++ b/tools/intel_guc_logger.c
@@ -51,18 +51,27 @@ uint32_t test_duration, max_filesize;
 pthread_cond_t underflow_cond, overflow_cond;
 bool stop_logging, discard_oldlogs, capturing_stopped;
 
-static void guc_log_control(bool enable_logging)
+static void guc_log_control(bool enable, uint32_t log_level)
 {
int control_fd;
char data[19];
-   uint64_t val;
+   uint64_t val = 0;
int ret;
 
+   /*
+* i915 expects GuC log level to be specified as:
+* 0: disabled
+* 1: enabled (verbosity level 0 = min)
+* 2: enabled (verbosity level 1)
+* 3: enabled (verbosity level 2)
+* 4: enabled (verbosity level 3 = max)
+*/
+   if (enable)
+   val = log_level + 1;
+
control_fd = igt_debugfs_open(-1, CONTROL_FILE_NAME, O_WRONLY);
igt_assert_f(control_fd >= 0, "couldn't open the guc log control 
file\n");
 
-   val = enable_logging ? ((verbosity_level << 4) | 0x1) : 0;
-
ret = snprintf(data, sizeof(data), "0x%" PRIx64, val);
igt_assert(ret > 2 && ret < sizeof(data));
 
@@ -288,7 +297,7 @@ static void init_main_thread(void)
/* Enable the logging, it may not have been enabled from boot and so
 * the relay file also wouldn't have been created.
 */
-   guc_log_control(true);
+   guc_log_control(true, verbosity_level);
 
open_relay_file();
open_output_file();
@@ -420,7 +429,7 @@ int main(int argc, char **argv)
} while (!stop_logging);
 
/* Pause logging on the GuC side */
-   guc_log_control(false);
+   guc_log_control(false, 0);
 
/* Signal flusher thread to make an exit */
capturing_stopped = 1;
-- 
1.9.1

___
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 series starting with [1/2] drm/i915/guc: Don't enable GuC when vGPU is active

[Du, Changbin]

On Fri, Jan 12, 2018 at 11:32:30AM +0530, Sagar Arun Kamble wrote:
> Is skl-gvtdvm not having vGPU active?
> 
> It has flag X86_FEATURE_HYPERVISOR set however it might be set on host too
> so relying intel_vgpu_active().
>
Do you mean flag X86_FEATURE_HYPERVISOR is set on host, too? This is weird 
since this
flag indicates the OS is running on a hypervisor.

> 
> On 1/11/2018 10:27 PM, Patchwork wrote:
> > == Series Details ==
> > 
> > Series: series starting with [1/2] drm/i915/guc: Don't enable GuC when vGPU 
> > is active
> > URL   : https://patchwork.freedesktop.org/series/36343/
> > State : failure
> > 
> > == Summary ==
> > 
> > Series 36343v1 series starting with [1/2] drm/i915/guc: Don't enable GuC 
> > when vGPU is active
> > https://patchwork.freedesktop.org/api/1.0/series/36343/revisions/1/mbox/
> > 
> > Test core_auth:
> >  Subgroup basic-auth:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> > Test core_prop_blob:
> >  Subgroup basic:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> > Test debugfs_test:
> >  Subgroup read_all_entries:
> >  dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> > Test drv_getparams_basic:
> >  Subgroup basic-eu-total:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> >  Subgroup basic-subslice-total:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> > Test drv_hangman:
> >  Subgroup error-state-basic:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> > Test gem_basic:
> >  Subgroup bad-close:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> >  Subgroup create-close:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> >  Subgroup create-fd-close:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> > Test gem_busy:
> >  Subgroup basic-busy-default:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> >  Subgroup basic-hang-default:
> >  pass   -> SKIP   (fi-skl-gvtdvm) fdo#104108 +2
> > Test gem_close_race:
> >  Subgroup basic-process:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> >  Subgroup basic-threads:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> > Test gem_cpu_reloc:
> >  Subgroup basic:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> > Test gem_cs_tlb:
> >  Subgroup basic-default:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> > Test gem_ctx_create:
> >  Subgroup basic:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> >  Subgroup basic-files:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> > Test gem_ctx_exec:
> >  Subgroup basic:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> > Test gem_ctx_param:
> >  Subgroup basic:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> >  Subgroup basic-default:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> > Test gem_ctx_switch:
> >  Subgroup basic-default:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> >  Subgroup basic-default-heavy:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> > Test gem_exec_basic:
> >  Subgroup basic-blt:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> >  Subgroup basic-bsd:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> >  Subgroup basic-bsd1:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> >  Subgroup basic-bsd2:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> >  Subgroup basic-default:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> >  Subgroup basic-render:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> >  Subgroup basic-vebox:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> >  Subgroup gtt-blt:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> >  Subgroup gtt-bsd:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> >  Subgroup gtt-bsd1:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> >  Subgroup gtt-bsd2:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> >  Subgroup gtt-default:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> >  Subgroup gtt-render:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> >  Subgroup gtt-vebox:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> >  Subgroup readonly-blt:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> >  Subgroup readonly-bsd:
> >  pass   -> SKIP   (fi-skl-gvtdvm)
> >  Subgroup readonly-bsd1:
> >

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/guc: Don't enable GuC when vGPU is active

[Sagar Arun Kamble]

Is skl-gvtdvm not having vGPU active?

It has flag X86_FEATURE_HYPERVISOR set however it might be set on host 
too so relying intel_vgpu_active().



On 1/11/2018 10:27 PM, Patchwork wrote:

== Series Details ==

Series: series starting with [1/2] drm/i915/guc: Don't enable GuC when vGPU is 
active
URL   : https://patchwork.freedesktop.org/series/36343/
State : failure

== Summary ==

Series 36343v1 series starting with [1/2] drm/i915/guc: Don't enable GuC when 
vGPU is active
https://patchwork.freedesktop.org/api/1.0/series/36343/revisions/1/mbox/

Test core_auth:
 Subgroup basic-auth:
 pass   -> SKIP   (fi-skl-gvtdvm)
Test core_prop_blob:
 Subgroup basic:
 pass   -> SKIP   (fi-skl-gvtdvm)
Test debugfs_test:
 Subgroup read_all_entries:
 dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
 pass   -> SKIP   (fi-skl-gvtdvm)
Test drv_getparams_basic:
 Subgroup basic-eu-total:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup basic-subslice-total:
 pass   -> SKIP   (fi-skl-gvtdvm)
Test drv_hangman:
 Subgroup error-state-basic:
 pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_basic:
 Subgroup bad-close:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup create-close:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup create-fd-close:
 pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_busy:
 Subgroup basic-busy-default:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup basic-hang-default:
 pass   -> SKIP   (fi-skl-gvtdvm) fdo#104108 +2
Test gem_close_race:
 Subgroup basic-process:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup basic-threads:
 pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_cpu_reloc:
 Subgroup basic:
 pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_cs_tlb:
 Subgroup basic-default:
 pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_create:
 Subgroup basic:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup basic-files:
 pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_exec:
 Subgroup basic:
 pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_param:
 Subgroup basic:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup basic-default:
 pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_switch:
 Subgroup basic-default:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup basic-default-heavy:
 pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_exec_basic:
 Subgroup basic-blt:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup basic-bsd:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup basic-bsd1:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup basic-bsd2:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup basic-default:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup basic-render:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup basic-vebox:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup gtt-blt:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup gtt-bsd:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup gtt-bsd1:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup gtt-bsd2:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup gtt-default:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup gtt-render:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup gtt-vebox:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup readonly-blt:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup readonly-bsd:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup readonly-bsd1:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup readonly-bsd2:
 pass   -> SKIP   (fi-skl-gvtdvm)
 Subgroup readonly-default:
WARNING: Long output truncated

da4321c7c088d01ad62b18d37dcfe5ef8d0b855d drm-tip: 2018y-01m-11d-14h-59m-37s UTC 
integration manifest
a0e8e84432b0 HAX: drm/i915/uc: Enable GuC/HuC for CI
973357da236a drm/i915/guc: Don't enable GuC when vGPU is active

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7651/issues.html


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/guc: Change values for i915_guc_log_control

[Sagar Arun Kamble]

On 1/11/2018 8:54 PM, Michal Wajdeczko wrote:

Today we have format mismatch between read/write operations
of i915_guc_log_control entry. For read we return (0, 1..4)
that represents disable/verbosity levels, but for write we
force user to follow internal structure format (0,1,9,11,13).

0x0, 0x1, 0x11, 0x21, 0x31

Let's hide internals from the user and accept same values
as we support for read and related guc_log_level modparam.

Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 

Reviewed-by: Sagar Arun Kamble 

---
  drivers/gpu/drm/i915/intel_guc_log.c | 27 +++
  1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index e6d59bf..1719f1e 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -58,11 +58,15 @@ static int guc_log_flush(struct intel_guc *guc)
return intel_guc_send(guc, action, ARRAY_SIZE(action));
  }
  
-static int guc_log_control(struct intel_guc *guc, u32 control_val)

+static int guc_log_control(struct intel_guc *guc, bool enable, u32 verbosity)
  {
+   union guc_log_control control_val = { .logging_enabled = enable,
+ .reserved1 = 0,
+ .verbosity = verbosity,
+ .reserved2 = 0 };
u32 action[] = {
INTEL_GUC_ACTION_UK_LOG_ENABLE_LOGGING,
-   control_val
+   control_val.value
};
  
  	return intel_guc_send(guc, action, ARRAY_SIZE(action));

@@ -567,28 +571,27 @@ 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;
+   bool enable_logging = control_val > 0;
+   u32 verbosity;
int ret;
  
-	log_param.value = control_val;

-
-   if (log_param.verbosity < GUC_LOG_VERBOSITY_MIN ||
-   log_param.verbosity > GUC_LOG_VERBOSITY_MAX)
+   BUILD_BUG_ON(GUC_LOG_VERBOSITY_MIN);
+   if (control_val > 1 + GUC_LOG_VERBOSITY_MAX)
return -EINVAL;
  
  	/* This combination doesn't make sense & won't have any effect */

-   if (!log_param.logging_enabled && !i915_modparams.guc_log_level)
+   if (!enable_logging && !i915_modparams.guc_log_level)
return 0;
  
-	ret = guc_log_control(guc, log_param.value);

+   verbosity = enable_logging ? control_val - 1 : 0;
+   ret = guc_log_control(guc, enable_logging, verbosity);
if (ret < 0) {
DRM_DEBUG_DRIVER("guc_logging_control action failed %d\n", ret);
return ret;
}
  
-	if (log_param.logging_enabled) {

-   i915_modparams.guc_log_level = 1 + log_param.verbosity;
+   if (enable_logging) {
+   i915_modparams.guc_log_level = 1 + verbosity;
  
  		/*

 * If log was disabled at boot time, then the relay channel file


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

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/guc: Redefine guc_log_level modparam values

[Sagar Arun Kamble]

On 1/11/2018 8:54 PM, Michal Wajdeczko wrote:

We used value -1 to indicate "disabled" and values 0..3 to
indicate "enabled", but most of our other modparams are using
-1 for "auto" mode and 0 for "disable". For consistency let's
change our log level values to:

-1: auto (depends on platform and Kconfig.debug settings)
  0: disabled
  1: enabled (severity level 0 = min)
  2: enabled (severity level 1)
  3: enabled (severity level 2)
  4: enabled (severity level 3 = max)

v2: fix commit message (Sagar)
 display sanitized modparam value (Sagar)
 unify sanitize messages (Sagar/Michal)

Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 

Reviewed-by: Sagar Arun Kamble 

---
  drivers/gpu/drm/i915/i915_params.c   |  3 +-
  drivers/gpu/drm/i915/intel_guc.c | 21 -
  drivers/gpu/drm/i915/intel_guc_log.c | 47 +---
  drivers/gpu/drm/i915/intel_uc.c  | 60 
  4 files changed, 92 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index b5f3eb4..0b553a8 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -155,7 +155,8 @@ struct i915_params i915_modparams __read_mostly = {
"(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)");
  
  i915_param_named(guc_log_level, int, 0400,

-   "GuC firmware logging level (-1:disabled (default), 0-3:enabled)");
+   "GuC firmware logging level. Requires GuC to be loaded. "
+   "(-1=auto [default], 0=disable, 1..4=enable with verbosity min..max)");
  
  i915_param_named_unsafe(guc_firmware_path, charp, 0400,

"GuC firmware path to use instead of the default one");
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 50b4725..4681537 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -215,6 +215,18 @@ static u32 get_core_family(struct drm_i915_private 
*dev_priv)
}
  }
  
+static u32 get_log_verbosity_flags(void)

+{
+   if (i915_modparams.guc_log_level > 0) {
+   u32 verbosity = i915_modparams.guc_log_level - 1;
+
+   GEM_BUG_ON(verbosity > GUC_LOG_VERBOSITY_MAX);
+   return verbosity << GUC_LOG_VERBOSITY_SHIFT;
+   }
+   GEM_BUG_ON(i915_modparams.enable_guc < 0);
+   return GUC_LOG_DISABLED;
+}
+
  /*
   * Initialise the GuC parameter block before starting the firmware
   * transfer. These parameters are read by the firmware on startup
@@ -247,12 +259,7 @@ void intel_guc_init_params(struct intel_guc *guc)
  
  	params[GUC_CTL_LOG_PARAMS] = guc->log.flags;
  
-	if (i915_modparams.guc_log_level >= 0) {

-   params[GUC_CTL_DEBUG] =
-   i915_modparams.guc_log_level << GUC_LOG_VERBOSITY_SHIFT;
-   } else {
-   params[GUC_CTL_DEBUG] = GUC_LOG_DISABLED;
-   }
+   params[GUC_CTL_DEBUG] = get_log_verbosity_flags();
  
  	/* If GuC submission is enabled, set up additional parameters here */

if (USES_GUC_SUBMISSION(dev_priv)) {
@@ -445,7 +452,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
  
-	if (i915_modparams.guc_log_level >= 0)

+   if (i915_modparams.guc_log_level)
gen9_enable_guc_interrupts(dev_priv);
  
  	data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index eaedd63..e6d59bf 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -33,11 +33,10 @@
  /**
   * DOC: GuC firmware log
   *
- * Firmware log is enabled by setting i915.guc_log_level to non-negative level.
+ * Firmware log is enabled by setting i915.guc_log_level to the positive level.
   * Log data is printed out via reading debugfs i915_guc_log_dump. Reading from
   * i915_guc_load_status will print out firmware loading status and scratch
   * registers value.
- *
   */
  
  static int guc_log_flush_complete(struct intel_guc *guc)

@@ -147,7 +146,7 @@ static int guc_log_relay_file_create(struct intel_guc *guc)
struct dentry *log_dir;
int ret;
  
-	if (i915_modparams.guc_log_level < 0)

+   if (!i915_modparams.guc_log_level)
return 0;
  
  	/* For now create the log file in /sys/kernel/debug/dri/0 dir */

@@ -423,8 +422,8 @@ static void guc_log_runtime_destroy(struct intel_guc *guc)
  {
/*
 * It's possible that the runtime stuff was never allocated because
-* guc_log_level was < 0 at the time
-**/
+* GuC log 

Re: [Intel-gfx] [PATCH 1/8] drm/i915: Add a comment exlaining CCS hsub/vsub

[Jason Ekstrand]

On Wed, Jan 10, 2018 at 9:48 AM, Ville Syrjälä <
ville.syrj...@linux.intel.com> wrote:

> On Wed, Jan 10, 2018 at 09:03:14AM -0800, Jason Ekstrand wrote:
> > On Fri, Dec 22, 2017 at 11:22 AM, Ville Syrjala <
> > ville.syrj...@linux.intel.com> wrote:
> >
> > > From: Ville Syrjälä 
> > >
> > > Let's document why we claim hsub==8,vsub==16 for CCS even though the
> > > memory layout would suggest that we use 16x8 instead.
> > >
> > > Cc: Daniel Vetter 
> > > Cc: Ben Widawsky 
> > > Cc: Jason Ekstrand 
> > > Cc: Daniel Stone 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 7 +++
> > >  1 file changed, 7 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 0cd355978ab4..83aec68537b4 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -2387,6 +2387,13 @@ static unsigned int intel_fb_modifier_to_tiling(
> uint64_t
> > > fb_modifier)
> > > }
> > >  }
> > >
> > > +/*
> > > + * 1 byte of CCS actually corresponds to 16x8 pixels on the main
> > > + * surface, and the memory layout for the CCS tile is 64x64 bytes.
> > > + * But since we're pretending the CCS tile is 128 bytes wide we
> > > + * adjust hsub/vsub here accordingly to 8x16 so that the
> > > + * bytes<->x/y conversions come out correct.
> > >
> >
> > I'm not particularly happy with this comment as I think it pushes the
> > mental model for these calculations in the wrong direction.  The PRM
> says:
> >
> > The Color Control Surface (CCS) contains the compression status of the
> > cache-line pairs. The
> > compression state of the cache-line pair is specified by 2 bits in the
> CCS.
> > Each CCS cache-line represents
> > an area on the main surface of 16 x16 sets of 128 byte Y-tiled
> > cache-line-pairs. CCS is always Y tiled.
> >
> > If you understand that a "cache line pair" in the main surface is a
> > horizontally adjacent cache line pair (cl1_addr = cl0_addr + 512) and you
> > just accept the statement about Y-tiling, this is the correct
> calculation.
> > Calculating these things in terms of pixels is occasionally useful but is
> > the wrong mental model.  The cache line statement above both accurately
> > describes the layout of the CCS (at the cache line granularity) and
> scales
> > to other pixel formats which are not 32-bit.
> >
> > I know that Ville and I have disagreed on this in the past but I don't
> > think adding comments about how we're "pretending the CCS tile is 128
> bytes
> > wide" is making anything more clear.
>
> I don't really see how talk about cachelines is going to help explain
> the hsub/vsub values we use here.
>
> But I don't really care that much. We could just leave them as magic
> numbers if no one can come up with a clear explanation for them.
>

How about a comment like this:

/*From the Sky Lake PRM:
 *
 *The Color Control Surface (CCS) contains the compression status of
the cache-line pairs. The
 *compression state of the cache-line pair is specified by 2 bits in
the CCS. Each CCS cache-line represents
 *an area on the main surface of 16 x16 sets of 128 byte Y-tiled
cache-line-pairs. CCS is always Y tiled.
 *
 * Since cache line pairs refers to horizontally adjacent cache lines, each
cache line in the CCS
 * corresponds to an area of 32x16 cache lines on the main surface.  Since
each pixel is 4 bytes,
 * this gives us a ratio of one byte in the CCS for each 8x16 pixels in the
main surface.
 */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2 v4] drm/i915/icl: Gen11 render context size

[Daniele Ceraolo Spurio]

On 11/01/18 14:55, Oscar Mateo wrote:

From: Tvrtko Ursulin 

Gen11 removes the Resource Streamer, which frees up a big chunk of
the context image. BSpec indicates 12538 DWORDs (13 pages), plus
one page for PPHWSP.



This is actually 12544 dwords according to the specs (I've already 
confirmed it with Oscar via IM). Still 13 pages anyway.


Reviewed-by: Daniele Ceraolo Spurio 

Thanks,
Daniele


Please notice that, when looking at the BSpec context image table,
the right filter has to be applied as some rows are excluded for
specific GENs. Also, some rows apply per-subslice (for the
calculation above, we have supposed I915_MAX_SUBSLICES = 8).

v2: Rebase.
v3: Use the right size as per the BSpec.
v4:
   - Rebased on top of the default context size (Rodrigo)
   - Clarify in the commit message where the subslice calculation
 comes from.

BSpec: 18907

Acked-by: Ben Widawsky 
Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Oscar Mateo 
Cc: Rodrigo Vivi 
Cc: Daniele Ceraolo Spurio 
---
  drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index db758c5..1e7bf40 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -42,6 +42,7 @@
  #define GEN8_LR_CONTEXT_RENDER_SIZE   (20 * PAGE_SIZE)
  #define GEN9_LR_CONTEXT_RENDER_SIZE   (22 * PAGE_SIZE)
  #define GEN10_LR_CONTEXT_RENDER_SIZE  (18 * PAGE_SIZE)
+#define GEN11_LR_CONTEXT_RENDER_SIZE   (14 * PAGE_SIZE)
  
  #define GEN8_LR_CONTEXT_OTHER_SIZE	( 2 * PAGE_SIZE)
  
@@ -183,6 +184,8 @@ struct engine_info {

default:
MISSING_CASE(INTEL_GEN(dev_priv));
return DEFAULT_LR_CONTEXT_RENDER_SIZE;
+   case 11:
+   return GEN11_LR_CONTEXT_RENDER_SIZE;
case 10:
return GEN10_LR_CONTEXT_RENDER_SIZE;
case 9:


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

Re: [Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for ICP

[Rodrigo Vivi]

On Thu, Jan 11, 2018 at 09:48:57PM +, James Ausmus wrote:
> On Thu, Jan 11, 2018 at 04:00:08PM -0200, Paulo Zanoni wrote:
> > From: Anusha Srivatsa 
> >
> > ICP has two backlight controllers - similar to previous platforms like
> > BXT.
> >
> > v2: Remove the usage of ICP_SECOND_PPS_BACKLIGHT register.(Jani)
> > Reuse BXT code since it is very similar.(Ville)
> >
> > v3 (from Paulo): Rebase.
> >
> > Cc: Jani Nikula 
> > Cc: Ville Syrjala 
> > Reviewed-by: Paulo Zanoni 
> > Signed-off-by: Anusha Srivatsa 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/intel_panel.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> > b/drivers/gpu/drm/i915/intel_panel.c
> > index fa6831f8c004..ad80cca8c110 100644
> > --- a/drivers/gpu/drm/i915/intel_panel.c
> > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > @@ -1865,7 +1865,7 @@ intel_panel_init_backlight_funcs(struct intel_panel 
> > *panel)
> > panel->backlight.set = bxt_set_backlight;
> > panel->backlight.get = bxt_get_backlight;
> > panel->backlight.hz_to_pwm = bxt_hz_to_pwm;
> > -   } else if (HAS_PCH_CNP(dev_priv)) {
> > +   } else if (HAS_PCH_CNP(dev_priv) || HAS_PCH_ICP(dev_priv)) {
>
> The commit message says reuse BXT, but the code says reuse CNP - which
> one should it be?

well,
CNP is like BXT, but with only one controller.
ICP is like BXT, including 2 controllers.

I don't know if it makes more sense re-use the cnp or bxt functions

But one way or another we have to address these lines from cnp_setup:

 /*
 * CNP has the BXT implementation of backlight, but with only
 * one controller. Future platforms could have multiple controll\
ers
 * so let's make this extensible and prepared for the future.
 */
panel->backlight.controller = 0;

>
> > panel->backlight.setup = cnp_setup_backlight;
> > panel->backlight.enable = cnp_enable_backlight;
> > panel->backlight.disable = cnp_disable_backlight;
> > --
> > 2.14.3
> >
> > ___
> > 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 20/27] drm/i915/icl: Make use of the SW counter field in the new context descriptor

[Daniele Ceraolo Spurio]

On 11/01/18 14:37, Oscar Mateo wrote:



On 01/11/2018 01:10 PM, Daniele Ceraolo Spurio wrote:
This could potentially be squashed with patch 15, as it doesn't make 
much sense to add a TODO there and solve it here. We might also want 
to update the comment above intel_lr_context_descriptor_update to 
remove the implication that SW context ID == ctx->hw_id (which is 
still technically true after this patch but we're preparing for it not 
to be anymore).




I was actually thinking of a different fate for this patch: leave patch 
15 as is (maybe make the TODO more open, like "TODO: decide what to do 
with sw_counter"), slap a "drm/i915/icl/guc" prefix on this one and 
consider it together with the rest of the GuC patches. At least in the 
meantime, while  we decide how to go about sw_counter (CCing Tvrtko). 
What do you think?




Sounds good to me, this patch doesn't really impact the !GuC path anyway 
since the number of IDs stays the same. I'll wait to see if there is any 
more feedback and if no one complains I'll send a new revision of patch 15.




Thanks,
Daniele

On 09/01/18 15:28, Paulo Zanoni wrote:

From: Oscar Mateo 

The new context descriptor format in Gen11 contains two assignable 
fields: the
SW Context ID (technically 11 bits, but practically limited to 2032 
entries due
to some being reserved for future use by the GuC) and the SW Counter 
(6 bits).


We don't want to limit ourselves too much in the maximum number of 
concurrent
contexts we want to allow, so ideally we want to employ every 
possible bit
available. Unfortunately, a further limitation in the interface with 
the GuC
means the combination of SW Context ID + SW Counter has to be unique 
within the

same engine class (as we use the SW Context ID to index in the GuC stage
descriptor pool, and the Engine Class + SW Counter to index in the 
2-dimensional
lrc array). This essentially means we need to somehow encode the 
engine instance.


Since the BSpec allows 6 bits for engine instance, we use the whole 
SW counter
for this task. If the limitation of 2032 maximum simultaneous 
contexts is too
restrictive, we can always squeeze things a bit more (3 extras bits 
for hw_id,
3 bits for instance) and things will still work (Gen11 does not 
instance more

than 8 engines of any class).

Another alternative would be to generate the hw_id per HW context 
instead of per
GEM context, but that has other problems (e.g. maximum number of 
user-created
contexts would be variable, no relationship between a GuC principal 
descriptor

and the proxy descriptor it uses, etc...).

Bspec: 12254

v2:
   - Squashed with parts of "Interface changes for GuC fw 22.108" 
(Daniele)
   - Do not apply the 16 reserved entries limitation to the non-GuC 
path (Joonas)

v3: Rebased by Rodrigo.
v4: Rebased 
(s/i915_modparams.enable_guc_submission/USES_GUC_SUBMISSION(dev_priv))


Cc: Daniele Ceraolo Spurio 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
Cc: Michel Thierry 
Signed-off-by: Oscar Mateo 
Signed-off-by: Rodrigo Vivi 
---
  drivers/gpu/drm/i915/i915_drv.h | 11 ---
  drivers/gpu/drm/i915/i915_gem_context.c |  9 ++---
  drivers/gpu/drm/i915/i915_gem_context.h |  2 ++
  drivers/gpu/drm/i915/i915_reg.h |  2 ++
  drivers/gpu/drm/i915/intel_lrc.c    | 15 ---
  5 files changed, 26 insertions(+), 13 deletions(-)

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

index aa4f2b178d97..3f1d8c0d2b0a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2079,11 +2079,16 @@ struct drm_i915_private {
    /* The hw wants to have a stable context identifier for the
   * lifetime of the context (for OA, PASID, faults, etc).
- * This is limited in execlists to 21 bits.
+ * This is limited in execlists to 21 bits. In enhanced 
execlist
+ * (GEN11+) this is limited to 11 bits (the SW Context ID 
field)

+ * but GuC limits it a bit further (11 bits - 16) due to some
+ * entries being reserved for future use (so the firmware only
+ * supports a GuC stage descriptor pool of 2032 entries).
   */
  struct ida hw_ida;
-#define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */
-#define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */
+#define MAX_CONTEXT_HW_ID    (1<<21) /* exclusive */
+#define GEN11_MAX_CONTEXT_HW_ID    (1<<11) /* exclusive */
+#define GEN11_MAX_CONTEXT_HW_ID_WITH_GUC GEN11_MAX_CONTEXT_HW_ID - 16
  } contexts;
    u32 fdi_rx_config;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c

index dbc50b9e18c9..bb5d070083f5 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -213,9 +213,12 @@ 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Return a default RCS context size

[Daniele Ceraolo Spurio]

On 11/01/18 14:55, Oscar Mateo wrote:

Instead of returning whatever size the latest GEN used. This is because
context sizes for new GENs can go up or down, but the only safe thing to
do for missing cases is to use the largest known one, whatever that is.

Suggested-by: Rodrigo Vivi 
Signed-off-by: Oscar Mateo 
Cc: Daniele Ceraolo Spurio 
---
  drivers/gpu/drm/i915/intel_engine_cs.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index e88b2fd..db758c5 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -38,6 +38,7 @@
   */
  #define HSW_CXT_TOTAL_SIZE(17 * PAGE_SIZE)
  


Could use a comment here with the explanation in the commit message, but 
it is relatively clear anyway, so:


Reviewed-by: Daniele Ceraolo Spurio 

Thanks,
Daniele


+#define DEFAULT_LR_CONTEXT_RENDER_SIZE (22 * PAGE_SIZE)
  #define GEN8_LR_CONTEXT_RENDER_SIZE   (20 * PAGE_SIZE)
  #define GEN9_LR_CONTEXT_RENDER_SIZE   (22 * PAGE_SIZE)
  #define GEN10_LR_CONTEXT_RENDER_SIZE  (18 * PAGE_SIZE)
@@ -181,6 +182,7 @@ struct engine_info {
switch (INTEL_GEN(dev_priv)) {
default:
MISSING_CASE(INTEL_GEN(dev_priv));
+   return DEFAULT_LR_CONTEXT_RENDER_SIZE;
case 10:
return GEN10_LR_CONTEXT_RENDER_SIZE;
case 9:


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

[Intel-gfx] [PATCH 1/2] drm/i915: Return a default RCS context size

[Oscar Mateo]

Instead of returning whatever size the latest GEN used. This is because
context sizes for new GENs can go up or down, but the only safe thing to
do for missing cases is to use the largest known one, whatever that is.

Suggested-by: Rodrigo Vivi 
Signed-off-by: Oscar Mateo 
Cc: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index e88b2fd..db758c5 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -38,6 +38,7 @@
  */
 #define HSW_CXT_TOTAL_SIZE (17 * PAGE_SIZE)
 
+#define DEFAULT_LR_CONTEXT_RENDER_SIZE (22 * PAGE_SIZE)
 #define GEN8_LR_CONTEXT_RENDER_SIZE(20 * PAGE_SIZE)
 #define GEN9_LR_CONTEXT_RENDER_SIZE(22 * PAGE_SIZE)
 #define GEN10_LR_CONTEXT_RENDER_SIZE   (18 * PAGE_SIZE)
@@ -181,6 +182,7 @@ struct engine_info {
switch (INTEL_GEN(dev_priv)) {
default:
MISSING_CASE(INTEL_GEN(dev_priv));
+   return DEFAULT_LR_CONTEXT_RENDER_SIZE;
case 10:
return GEN10_LR_CONTEXT_RENDER_SIZE;
case 9:
-- 
1.9.1

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

[Intel-gfx] [PATCH 2/2 v4] drm/i915/icl: Gen11 render context size

[Oscar Mateo]

From: Tvrtko Ursulin 

Gen11 removes the Resource Streamer, which frees up a big chunk of
the context image. BSpec indicates 12538 DWORDs (13 pages), plus
one page for PPHWSP.

Please notice that, when looking at the BSpec context image table,
the right filter has to be applied as some rows are excluded for
specific GENs. Also, some rows apply per-subslice (for the
calculation above, we have supposed I915_MAX_SUBSLICES = 8).

v2: Rebase.
v3: Use the right size as per the BSpec.
v4:
  - Rebased on top of the default context size (Rodrigo)
  - Clarify in the commit message where the subslice calculation
comes from.

BSpec: 18907

Acked-by: Ben Widawsky 
Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Oscar Mateo 
Cc: Rodrigo Vivi 
Cc: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index db758c5..1e7bf40 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -42,6 +42,7 @@
 #define GEN8_LR_CONTEXT_RENDER_SIZE(20 * PAGE_SIZE)
 #define GEN9_LR_CONTEXT_RENDER_SIZE(22 * PAGE_SIZE)
 #define GEN10_LR_CONTEXT_RENDER_SIZE   (18 * PAGE_SIZE)
+#define GEN11_LR_CONTEXT_RENDER_SIZE   (14 * PAGE_SIZE)
 
 #define GEN8_LR_CONTEXT_OTHER_SIZE ( 2 * PAGE_SIZE)
 
@@ -183,6 +184,8 @@ struct engine_info {
default:
MISSING_CASE(INTEL_GEN(dev_priv));
return DEFAULT_LR_CONTEXT_RENDER_SIZE;
+   case 11:
+   return GEN11_LR_CONTEXT_RENDER_SIZE;
case 10:
return GEN10_LR_CONTEXT_RENDER_SIZE;
case 9:
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH v3] drm/i915/icl: Gen11 render context size

[Oscar Mateo]

On 01/11/2018 11:40 AM, Rodrigo Vivi wrote:

On Thu, Jan 11, 2018 at 06:23:20PM +, Oscar Mateo wrote:

From: Tvrtko Ursulin 

Gen11 removes the Resource Streamer, which frees up a big chunk of
the context image. BSpec indicates 12538 DWORDs (13 pages), plus
one page for PPHWSP.

Please notice that, when looking at the BSpec context image table,
the right filter has to be applied (e.g. "IcelakeLP") as some rows
are excluded for specific GENs. Also, some rows apply per-subslice
(for the calculation above, we have supposed 8 subslices which is
the maximum SKU we expect).

v2: Rebase.
v3: Use the right size as per the BSpec.

BSpec: 18907

Acked-by: Ben Widawsky 
Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Oscar Mateo 
---
  drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index e88b2fd..79b7d36 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -41,6 +41,7 @@
  #define GEN8_LR_CONTEXT_RENDER_SIZE   (20 * PAGE_SIZE)
  #define GEN9_LR_CONTEXT_RENDER_SIZE   (22 * PAGE_SIZE)
  #define GEN10_LR_CONTEXT_RENDER_SIZE  (18 * PAGE_SIZE)
+#define GEN11_LR_CONTEXT_RENDER_SIZE   (14 * PAGE_SIZE)
  
  #define GEN8_LR_CONTEXT_OTHER_SIZE	( 2 * PAGE_SIZE)
  
@@ -181,6 +182,8 @@ struct engine_info {

switch (INTEL_GEN(dev_priv)) {
default:
MISSING_CASE(INTEL_GEN(dev_priv));

I believe this default is getting danger as we decrease the size here.
I believe the safest one for missing case is the largest one whatever that is.


That's a very sensible idea. I don't know to put the default case in the 
middle of the other ones or change the numerical order, so I'll create a 
new define for the default case...

+   case 11:
+   return GEN11_LR_CONTEXT_RENDER_SIZE;
case 10:
return GEN10_LR_CONTEXT_RENDER_SIZE;
case 9:
--
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 20/27] drm/i915/icl: Make use of the SW counter field in the new context descriptor

[Oscar Mateo]

On 01/11/2018 01:10 PM, Daniele Ceraolo Spurio wrote:
This could potentially be squashed with patch 15, as it doesn't make 
much sense to add a TODO there and solve it here. We might also want 
to update the comment above intel_lr_context_descriptor_update to 
remove the implication that SW context ID == ctx->hw_id (which is 
still technically true after this patch but we're preparing for it not 
to be anymore).




I was actually thinking of a different fate for this patch: leave patch 
15 as is (maybe make the TODO more open, like "TODO: decide what to do 
with sw_counter"), slap a "drm/i915/icl/guc" prefix on this one and 
consider it together with the rest of the GuC patches. At least in the 
meantime, while  we decide how to go about sw_counter (CCing Tvrtko). 
What do you think?



Thanks,
Daniele

On 09/01/18 15:28, Paulo Zanoni wrote:

From: Oscar Mateo 

The new context descriptor format in Gen11 contains two assignable 
fields: the
SW Context ID (technically 11 bits, but practically limited to 2032 
entries due
to some being reserved for future use by the GuC) and the SW Counter 
(6 bits).


We don't want to limit ourselves too much in the maximum number of 
concurrent
contexts we want to allow, so ideally we want to employ every 
possible bit
available. Unfortunately, a further limitation in the interface with 
the GuC
means the combination of SW Context ID + SW Counter has to be unique 
within the

same engine class (as we use the SW Context ID to index in the GuC stage
descriptor pool, and the Engine Class + SW Counter to index in the 
2-dimensional
lrc array). This essentially means we need to somehow encode the 
engine instance.


Since the BSpec allows 6 bits for engine instance, we use the whole 
SW counter
for this task. If the limitation of 2032 maximum simultaneous 
contexts is too
restrictive, we can always squeeze things a bit more (3 extras bits 
for hw_id,
3 bits for instance) and things will still work (Gen11 does not 
instance more

than 8 engines of any class).

Another alternative would be to generate the hw_id per HW context 
instead of per
GEM context, but that has other problems (e.g. maximum number of 
user-created
contexts would be variable, no relationship between a GuC principal 
descriptor

and the proxy descriptor it uses, etc...).

Bspec: 12254

v2:
   - Squashed with parts of "Interface changes for GuC fw 22.108" 
(Daniele)
   - Do not apply the 16 reserved entries limitation to the non-GuC 
path (Joonas)

v3: Rebased by Rodrigo.
v4: Rebased 
(s/i915_modparams.enable_guc_submission/USES_GUC_SUBMISSION(dev_priv))


Cc: Daniele Ceraolo Spurio 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
Cc: Michel Thierry 
Signed-off-by: Oscar Mateo 
Signed-off-by: Rodrigo Vivi 
---
  drivers/gpu/drm/i915/i915_drv.h | 11 ---
  drivers/gpu/drm/i915/i915_gem_context.c |  9 ++---
  drivers/gpu/drm/i915/i915_gem_context.h |  2 ++
  drivers/gpu/drm/i915/i915_reg.h |  2 ++
  drivers/gpu/drm/i915/intel_lrc.c    | 15 ---
  5 files changed, 26 insertions(+), 13 deletions(-)

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

index aa4f2b178d97..3f1d8c0d2b0a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2079,11 +2079,16 @@ struct drm_i915_private {
    /* The hw wants to have a stable context identifier for the
   * lifetime of the context (for OA, PASID, faults, etc).
- * This is limited in execlists to 21 bits.
+ * This is limited in execlists to 21 bits. In enhanced 
execlist
+ * (GEN11+) this is limited to 11 bits (the SW Context ID 
field)

+ * but GuC limits it a bit further (11 bits - 16) due to some
+ * entries being reserved for future use (so the firmware only
+ * supports a GuC stage descriptor pool of 2032 entries).
   */
  struct ida hw_ida;
-#define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */
-#define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */
+#define MAX_CONTEXT_HW_ID    (1<<21) /* exclusive */
+#define GEN11_MAX_CONTEXT_HW_ID    (1<<11) /* exclusive */
+#define GEN11_MAX_CONTEXT_HW_ID_WITH_GUC GEN11_MAX_CONTEXT_HW_ID - 16
  } contexts;
    u32 fdi_rx_config;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c

index dbc50b9e18c9..bb5d070083f5 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -213,9 +213,12 @@ static int assign_hw_id(struct drm_i915_private 
*dev_priv, unsigned *out)

  int ret;
  unsigned int max;
  -    if (INTEL_GEN(dev_priv) >= 11)
-    max = GEN11_MAX_CONTEXT_HW_ID;
-    else
+    if (INTEL_GEN(dev_priv) >= 11) {
+    if 

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Disable preemption and sleeping while using the punit sideband

[Hans de Goede]

Hi,

On 11-01-18 22:42, Hans de Goede wrote:

Hi,

On 11-01-18 22:17, Ville Syrjälä wrote:

On Thu, Jan 11, 2018 at 08:53:42PM +, Chris Wilson wrote:

Quoting Ville Syrjälä (2018-01-11 20:10:45)

On Wed, Jan 10, 2018 at 12:55:05PM +, Chris Wilson wrote:

While we talk to the punit over its sideband, we need to prevent the cpu
from sleeping in order to prevent a potential machine hang.

Note that by itself, it appears that pm_qos_update_request (via
intel_idle) doesn't provide a sufficient barrier to ensure that all core
are indeed awake (out of Cstate) and that the package is awake. To do so,
we need to supplement the pm_qos with a manual ping on_each_cpu.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109051
References: https://bugs.freedesktop.org/show_bug.cgi?id=102657
References: https://bugzilla.kernel.org/show_bug.cgi?id=195255
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Hans de Goede 
---
  drivers/gpu/drm/i915/i915_drv.c   |  6 
  drivers/gpu/drm/i915/i915_drv.h   |  1 +
  drivers/gpu/drm/i915/intel_sideband.c | 61 ---
  3 files changed, 50 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6c8da9d20c33..d4b90cc0130b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -902,6 +902,9 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
   spin_lock_init(_priv->uncore.lock);
   mutex_init(_priv->sb_lock);
+ pm_qos_add_request(_priv->sb_qos,
+    PM_QOS_CPU_DMA_LATENCY, PM_QOS_DEFAULT_VALUE);
+
   mutex_init(_priv->modeset_restore_lock);
   mutex_init(_priv->av_mutex);
   mutex_init(_priv->wm.wm_mutex);
@@ -953,6 +956,9 @@ static void i915_driver_cleanup_early(struct 
drm_i915_private *dev_priv)
   intel_irq_fini(dev_priv);
   i915_workqueues_cleanup(dev_priv);
   i915_engines_cleanup(dev_priv);
+
+ pm_qos_remove_request(_priv->sb_qos);
+ mutex_destroy(_priv->sb_lock);
  }
  static int i915_mmio_setup(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a689396d0ff6..ff3f9effc0bb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1887,6 +1887,7 @@ struct drm_i915_private {
   /* Sideband mailbox protection */
   struct mutex sb_lock;
+ struct pm_qos_request sb_qos;
   /** Cached value of IMR to avoid reads in updating the bitfield */
   union {
diff --git a/drivers/gpu/drm/i915/intel_sideband.c 
b/drivers/gpu/drm/i915/intel_sideband.c
index 75c872bb8cc9..02bdd2e2cef6 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -22,6 +22,8 @@
   *
   */
+#include 
+
  #include "i915_drv.h"
  #include "intel_drv.h"
@@ -39,18 +41,20 @@
  /* Private register write, double-word addressing, non-posted */
  #define SB_CRWRDA_NP 0x07
-static int vlv_sideband_rw(struct drm_i915_private *dev_priv, u32 devfn,
-    u32 port, u32 opcode, u32 addr, u32 *val)
+static void ping(void *info)
  {
- u32 cmd, be = 0xf, bar = 0;
- bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP);
+}
- cmd = (devfn << IOSF_DEVFN_SHIFT) | (opcode << IOSF_OPCODE_SHIFT) |
- (port << IOSF_PORT_SHIFT) | (be << IOSF_BYTE_ENABLES_SHIFT) |
- (bar << IOSF_BAR_SHIFT);
+static int vlv_sideband_rw(struct drm_i915_private *dev_priv,
+    u32 devfn, u32 port, u32 opcode,
+    u32 addr, u32 *val)
+{
+ const bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP);
+ int err;
- WARN_ON(!mutex_is_locked(_priv->sb_lock));
+ lockdep_assert_held(_priv->sb_lock);
+ /* Flush the previous comms, just in case it failed last time. */
   if (intel_wait_for_register(dev_priv,
   VLV_IOSF_DOORBELL_REQ, IOSF_SB_BUSY, 0,
   5)) {
@@ -59,22 +63,43 @@ static int vlv_sideband_rw(struct drm_i915_private 
*dev_priv, u32 devfn,
   return -EAGAIN;
   }
- I915_WRITE(VLV_IOSF_ADDR, addr);
- I915_WRITE(VLV_IOSF_DATA, is_read ? 0 : *val);
- I915_WRITE(VLV_IOSF_DOORBELL_REQ, cmd);
+ iosf_mbi_punit_acquire();
- if (intel_wait_for_register(dev_priv,
- VLV_IOSF_DOORBELL_REQ, IOSF_SB_BUSY, 0,
- 5)) {
+ /*
+  * Prevent the cpu from sleeping while we use this sideband, otherwise
+  * the punit may cause a machine hang.
+  */
+ pm_qos_update_request(_priv->sb_qos, 0);
+ on_each_cpu(ping, NULL, 1);


pm_qos_update_request() doesn't wake up the cpus on its own? I wonder
kind of latency guarantees it can actually give without doing that.


intel_idle plugs into the update to wake up idle 

Re: [Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for ICP

[James Ausmus]

On Thu, Jan 11, 2018 at 04:00:08PM -0200, Paulo Zanoni wrote:
> From: Anusha Srivatsa 
> 
> ICP has two backlight controllers - similar to previous platforms like
> BXT.
> 
> v2: Remove the usage of ICP_SECOND_PPS_BACKLIGHT register.(Jani)
> Reuse BXT code since it is very similar.(Ville)
> 
> v3 (from Paulo): Rebase.
> 
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> Reviewed-by: Paulo Zanoni 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_panel.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> b/drivers/gpu/drm/i915/intel_panel.c
> index fa6831f8c004..ad80cca8c110 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -1865,7 +1865,7 @@ intel_panel_init_backlight_funcs(struct intel_panel 
> *panel)
>   panel->backlight.set = bxt_set_backlight;
>   panel->backlight.get = bxt_get_backlight;
>   panel->backlight.hz_to_pwm = bxt_hz_to_pwm;
> - } else if (HAS_PCH_CNP(dev_priv)) {
> + } else if (HAS_PCH_CNP(dev_priv) || HAS_PCH_ICP(dev_priv)) {

The commit message says reuse BXT, but the code says reuse CNP - which
one should it be?

>   panel->backlight.setup = cnp_setup_backlight;
>   panel->backlight.enable = cnp_enable_backlight;
>   panel->backlight.disable = cnp_disable_backlight;
> -- 
> 2.14.3
> 
> ___
> 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/7] drm/i915: Disable preemption and sleeping while using the punit sideband

[Hans de Goede]

Hi,

On 11-01-18 22:17, Ville Syrjälä wrote:

On Thu, Jan 11, 2018 at 08:53:42PM +, Chris Wilson wrote:

Quoting Ville Syrjälä (2018-01-11 20:10:45)

On Wed, Jan 10, 2018 at 12:55:05PM +, Chris Wilson wrote:

While we talk to the punit over its sideband, we need to prevent the cpu
from sleeping in order to prevent a potential machine hang.

Note that by itself, it appears that pm_qos_update_request (via
intel_idle) doesn't provide a sufficient barrier to ensure that all core
are indeed awake (out of Cstate) and that the package is awake. To do so,
we need to supplement the pm_qos with a manual ping on_each_cpu.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109051
References: https://bugs.freedesktop.org/show_bug.cgi?id=102657
References: https://bugzilla.kernel.org/show_bug.cgi?id=195255
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Hans de Goede 
---
  drivers/gpu/drm/i915/i915_drv.c   |  6 
  drivers/gpu/drm/i915/i915_drv.h   |  1 +
  drivers/gpu/drm/i915/intel_sideband.c | 61 ---
  3 files changed, 50 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6c8da9d20c33..d4b90cc0130b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -902,6 +902,9 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
   spin_lock_init(_priv->uncore.lock);
  
   mutex_init(_priv->sb_lock);

+ pm_qos_add_request(_priv->sb_qos,
+PM_QOS_CPU_DMA_LATENCY, PM_QOS_DEFAULT_VALUE);
+
   mutex_init(_priv->modeset_restore_lock);
   mutex_init(_priv->av_mutex);
   mutex_init(_priv->wm.wm_mutex);
@@ -953,6 +956,9 @@ static void i915_driver_cleanup_early(struct 
drm_i915_private *dev_priv)
   intel_irq_fini(dev_priv);
   i915_workqueues_cleanup(dev_priv);
   i915_engines_cleanup(dev_priv);
+
+ pm_qos_remove_request(_priv->sb_qos);
+ mutex_destroy(_priv->sb_lock);
  }
  
  static int i915_mmio_setup(struct drm_i915_private *dev_priv)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a689396d0ff6..ff3f9effc0bb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1887,6 +1887,7 @@ struct drm_i915_private {
  
   /* Sideband mailbox protection */

   struct mutex sb_lock;
+ struct pm_qos_request sb_qos;
  
   /** Cached value of IMR to avoid reads in updating the bitfield */

   union {
diff --git a/drivers/gpu/drm/i915/intel_sideband.c 
b/drivers/gpu/drm/i915/intel_sideband.c
index 75c872bb8cc9..02bdd2e2cef6 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -22,6 +22,8 @@
   *
   */
  
+#include 

+
  #include "i915_drv.h"
  #include "intel_drv.h"
  
@@ -39,18 +41,20 @@

  /* Private register write, double-word addressing, non-posted */
  #define SB_CRWRDA_NP 0x07
  
-static int vlv_sideband_rw(struct drm_i915_private *dev_priv, u32 devfn,

-u32 port, u32 opcode, u32 addr, u32 *val)
+static void ping(void *info)
  {
- u32 cmd, be = 0xf, bar = 0;
- bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP);
+}
  
- cmd = (devfn << IOSF_DEVFN_SHIFT) | (opcode << IOSF_OPCODE_SHIFT) |

- (port << IOSF_PORT_SHIFT) | (be << IOSF_BYTE_ENABLES_SHIFT) |
- (bar << IOSF_BAR_SHIFT);
+static int vlv_sideband_rw(struct drm_i915_private *dev_priv,
+u32 devfn, u32 port, u32 opcode,
+u32 addr, u32 *val)
+{
+ const bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP);
+ int err;
  
- WARN_ON(!mutex_is_locked(_priv->sb_lock));

+ lockdep_assert_held(_priv->sb_lock);
  
+ /* Flush the previous comms, just in case it failed last time. */

   if (intel_wait_for_register(dev_priv,
   VLV_IOSF_DOORBELL_REQ, IOSF_SB_BUSY, 0,
   5)) {
@@ -59,22 +63,43 @@ static int vlv_sideband_rw(struct drm_i915_private 
*dev_priv, u32 devfn,
   return -EAGAIN;
   }
  
- I915_WRITE(VLV_IOSF_ADDR, addr);

- I915_WRITE(VLV_IOSF_DATA, is_read ? 0 : *val);
- I915_WRITE(VLV_IOSF_DOORBELL_REQ, cmd);
+ iosf_mbi_punit_acquire();
  
- if (intel_wait_for_register(dev_priv,

- VLV_IOSF_DOORBELL_REQ, IOSF_SB_BUSY, 0,
- 5)) {
+ /*
+  * Prevent the cpu from sleeping while we use this sideband, otherwise
+  * the punit may cause a machine hang.
+  */
+ pm_qos_update_request(_priv->sb_qos, 0);
+ on_each_cpu(ping, NULL, 1);


pm_qos_update_request() doesn't wake up the cpus on its own? I wonder
kind of latency guarantees it can actually give without doing that.


intel_idle plugs into the update to wake up 

Re: [Intel-gfx] [PATCH 14/27] drm/i915/icl: Set graphics mode register for gen11

[Daniele Ceraolo Spurio]

On 09/01/18 15:28, Paulo Zanoni wrote:

From: kgardine 

This patch clears a single bit. The bit is 0 by default but expected not to be
set. Explicitly clearing the bit in this patch is intended to indicate some
thinking has occurred, and that we want this bit cleared and we are not just
excepting the default value.

v2 (from Paulo): fix indentation.
v3 (from Paulo): rebase.

Signed-off-by: kgardine 
Signed-off-by: Paulo Zanoni 
---
  drivers/gpu/drm/i915/i915_reg.h  |  2 ++
  drivers/gpu/drm/i915/intel_lrc.c | 10 --
  2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f383ee5cc592..a16a8a2b17b4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2597,6 +2597,8 @@ enum i915_power_well_id {
  #define   GFX_FORWARD_VBLANK_ALWAYS   (1<<5)
  #define   GFX_FORWARD_VBLANK_COND (2<<5)
  
+#define   GEN11_GFX_DISABLE_LEGACY_MODE	(1<<3)

+
  #define VLV_DISPLAY_BASE 0x18
  #define VLV_MIPI_BASE VLV_DISPLAY_BASE
  #define BXT_MIPI_BASE 0x6
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index dab988f20833..d435a9982d0b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1500,8 +1500,14 @@ static void enable_execlists(struct intel_engine_cs 
*engine)
struct drm_i915_private *dev_priv = engine->i915;
  
  	I915_WRITE(RING_HWSTAM(engine->mmio_base), 0x);

-   I915_WRITE(RING_MODE_GEN7(engine),
-  _MASKED_BIT_ENABLE(GFX_RUN_LIST_ENABLE));
+
+   if (IS_GEN11(dev_priv))


INTEL_GEN >= 11? I'd expect this to be valid going forward instead of 
flipping back to the old value settings. Also we could use a comment,

because the bit name is not very clear. Something like:

/*
 * Make sure we're not enabling the new 12-deep CSB
 * FIFO as that requires a slightly updated handling
 * in the ctx switch irq. Since we're currently only
 * using only 2 elements of the enhanced execlists the
 * deeper FIFO it's not needed and it's not worth adding
 * more statements to the irq handler to support it.
 */

Daniele


+   I915_WRITE(RING_MODE_GEN7(engine),
+  _MASKED_BIT_DISABLE(GEN11_GFX_DISABLE_LEGACY_MODE));
+   else
+   I915_WRITE(RING_MODE_GEN7(engine),
+  _MASKED_BIT_ENABLE(GFX_RUN_LIST_ENABLE));
+
I915_WRITE(RING_HWS_PGA(engine->mmio_base),
   engine->status_page.ggtt_offset);
POSTING_READ(RING_HWS_PGA(engine->mmio_base));


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

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Disable preemption and sleeping while using the punit sideband

[Ville Syrjälä]

On Thu, Jan 11, 2018 at 08:53:42PM +, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-01-11 20:10:45)
> > On Wed, Jan 10, 2018 at 12:55:05PM +, Chris Wilson wrote:
> > > While we talk to the punit over its sideband, we need to prevent the cpu
> > > from sleeping in order to prevent a potential machine hang.
> > > 
> > > Note that by itself, it appears that pm_qos_update_request (via
> > > intel_idle) doesn't provide a sufficient barrier to ensure that all core
> > > are indeed awake (out of Cstate) and that the package is awake. To do so,
> > > we need to supplement the pm_qos with a manual ping on_each_cpu.
> > > 
> > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109051
> > > References: https://bugs.freedesktop.org/show_bug.cgi?id=102657
> > > References: https://bugzilla.kernel.org/show_bug.cgi?id=195255
> > > Signed-off-by: Chris Wilson 
> > > Cc: Mika Kuoppala 
> > > Cc: Hans de Goede 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.c   |  6 
> > >  drivers/gpu/drm/i915/i915_drv.h   |  1 +
> > >  drivers/gpu/drm/i915/intel_sideband.c | 61 
> > > ---
> > >  3 files changed, 50 insertions(+), 18 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > > b/drivers/gpu/drm/i915/i915_drv.c
> > > index 6c8da9d20c33..d4b90cc0130b 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -902,6 +902,9 @@ static int i915_driver_init_early(struct 
> > > drm_i915_private *dev_priv,
> > >   spin_lock_init(_priv->uncore.lock);
> > >  
> > >   mutex_init(_priv->sb_lock);
> > > + pm_qos_add_request(_priv->sb_qos,
> > > +PM_QOS_CPU_DMA_LATENCY, PM_QOS_DEFAULT_VALUE);
> > > +
> > >   mutex_init(_priv->modeset_restore_lock);
> > >   mutex_init(_priv->av_mutex);
> > >   mutex_init(_priv->wm.wm_mutex);
> > > @@ -953,6 +956,9 @@ static void i915_driver_cleanup_early(struct 
> > > drm_i915_private *dev_priv)
> > >   intel_irq_fini(dev_priv);
> > >   i915_workqueues_cleanup(dev_priv);
> > >   i915_engines_cleanup(dev_priv);
> > > +
> > > + pm_qos_remove_request(_priv->sb_qos);
> > > + mutex_destroy(_priv->sb_lock);
> > >  }
> > >  
> > >  static int i915_mmio_setup(struct drm_i915_private *dev_priv)
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index a689396d0ff6..ff3f9effc0bb 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -1887,6 +1887,7 @@ struct drm_i915_private {
> > >  
> > >   /* Sideband mailbox protection */
> > >   struct mutex sb_lock;
> > > + struct pm_qos_request sb_qos;
> > >  
> > >   /** Cached value of IMR to avoid reads in updating the bitfield */
> > >   union {
> > > diff --git a/drivers/gpu/drm/i915/intel_sideband.c 
> > > b/drivers/gpu/drm/i915/intel_sideband.c
> > > index 75c872bb8cc9..02bdd2e2cef6 100644
> > > --- a/drivers/gpu/drm/i915/intel_sideband.c
> > > +++ b/drivers/gpu/drm/i915/intel_sideband.c
> > > @@ -22,6 +22,8 @@
> > >   *
> > >   */
> > >  
> > > +#include 
> > > +
> > >  #include "i915_drv.h"
> > >  #include "intel_drv.h"
> > >  
> > > @@ -39,18 +41,20 @@
> > >  /* Private register write, double-word addressing, non-posted */
> > >  #define SB_CRWRDA_NP 0x07
> > >  
> > > -static int vlv_sideband_rw(struct drm_i915_private *dev_priv, u32 devfn,
> > > -u32 port, u32 opcode, u32 addr, u32 *val)
> > > +static void ping(void *info)
> > >  {
> > > - u32 cmd, be = 0xf, bar = 0;
> > > - bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP);
> > > +}
> > >  
> > > - cmd = (devfn << IOSF_DEVFN_SHIFT) | (opcode << IOSF_OPCODE_SHIFT) |
> > > - (port << IOSF_PORT_SHIFT) | (be << IOSF_BYTE_ENABLES_SHIFT) 
> > > |
> > > - (bar << IOSF_BAR_SHIFT);
> > > +static int vlv_sideband_rw(struct drm_i915_private *dev_priv,
> > > +u32 devfn, u32 port, u32 opcode,
> > > +u32 addr, u32 *val)
> > > +{
> > > + const bool is_read = (opcode == SB_MRD_NP || opcode == 
> > > SB_CRRDDA_NP);
> > > + int err;
> > >  
> > > - WARN_ON(!mutex_is_locked(_priv->sb_lock));
> > > + lockdep_assert_held(_priv->sb_lock);
> > >  
> > > + /* Flush the previous comms, just in case it failed last time. */
> > >   if (intel_wait_for_register(dev_priv,
> > >   VLV_IOSF_DOORBELL_REQ, IOSF_SB_BUSY, 0,
> > >   5)) {
> > > @@ -59,22 +63,43 @@ static int vlv_sideband_rw(struct drm_i915_private 
> > > *dev_priv, u32 devfn,
> > >   return -EAGAIN;
> > >   }
> > >  
> > > - I915_WRITE(VLV_IOSF_ADDR, addr);
> > > - I915_WRITE(VLV_IOSF_DATA, is_read ? 0 : *val);
> > > - I915_WRITE(VLV_IOSF_DOORBELL_REQ, cmd);
> > > + 

Re: [Intel-gfx] [PATCH 20/27] drm/i915/icl: Make use of the SW counter field in the new context descriptor

[Daniele Ceraolo Spurio]

This could potentially be squashed with patch 15, as it doesn't make 
much sense to add a TODO there and solve it here. We might also want to 
update the comment above intel_lr_context_descriptor_update to remove 
the implication that SW context ID == ctx->hw_id (which is still 
technically true after this patch but we're preparing for it not to be 
anymore).


Thanks,
Daniele

On 09/01/18 15:28, Paulo Zanoni wrote:

From: Oscar Mateo 

The new context descriptor format in Gen11 contains two assignable fields: the
SW Context ID (technically 11 bits, but practically limited to 2032 entries due
to some being reserved for future use by the GuC) and the SW Counter (6 bits).

We don't want to limit ourselves too much in the maximum number of concurrent
contexts we want to allow, so ideally we want to employ every possible bit
available. Unfortunately, a further limitation in the interface with the GuC
means the combination of SW Context ID + SW Counter has to be unique within the
same engine class (as we use the SW Context ID to index in the GuC stage
descriptor pool, and the Engine Class + SW Counter to index in the 2-dimensional
lrc array). This essentially means we need to somehow encode the engine 
instance.

Since the BSpec allows 6 bits for engine instance, we use the whole SW counter
for this task. If the limitation of 2032 maximum simultaneous contexts is too
restrictive, we can always squeeze things a bit more (3 extras bits for hw_id,
3 bits for instance) and things will still work (Gen11 does not instance more
than 8 engines of any class).

Another alternative would be to generate the hw_id per HW context instead of per
GEM context, but that has other problems (e.g. maximum number of user-created
contexts would be variable, no relationship between a GuC principal descriptor
and the proxy descriptor it uses, etc...).

Bspec: 12254

v2:
   - Squashed with parts of "Interface changes for GuC fw 22.108" (Daniele)
   - Do not apply the 16 reserved entries limitation to the non-GuC path 
(Joonas)
v3: Rebased by Rodrigo.
v4: Rebased 
(s/i915_modparams.enable_guc_submission/USES_GUC_SUBMISSION(dev_priv))

Cc: Daniele Ceraolo Spurio 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
Cc: Michel Thierry 
Signed-off-by: Oscar Mateo 
Signed-off-by: Rodrigo Vivi 
---
  drivers/gpu/drm/i915/i915_drv.h | 11 ---
  drivers/gpu/drm/i915/i915_gem_context.c |  9 ++---
  drivers/gpu/drm/i915/i915_gem_context.h |  2 ++
  drivers/gpu/drm/i915/i915_reg.h |  2 ++
  drivers/gpu/drm/i915/intel_lrc.c| 15 ---
  5 files changed, 26 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index aa4f2b178d97..3f1d8c0d2b0a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2079,11 +2079,16 @@ struct drm_i915_private {
  
  		/* The hw wants to have a stable context identifier for the

 * lifetime of the context (for OA, PASID, faults, etc).
-* This is limited in execlists to 21 bits.
+* This is limited in execlists to 21 bits. In enhanced execlist
+* (GEN11+) this is limited to 11 bits (the SW Context ID field)
+* but GuC limits it a bit further (11 bits - 16) due to some
+* entries being reserved for future use (so the firmware only
+* supports a GuC stage descriptor pool of 2032 entries).
 */
struct ida hw_ida;
-#define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */
-#define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */
+#define MAX_CONTEXT_HW_ID  (1<<21) /* exclusive */
+#define GEN11_MAX_CONTEXT_HW_ID(1<<11) /* exclusive */
+#define GEN11_MAX_CONTEXT_HW_ID_WITH_GUC   GEN11_MAX_CONTEXT_HW_ID - 16
} contexts;
  
  	u32 fdi_rx_config;

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index dbc50b9e18c9..bb5d070083f5 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -213,9 +213,12 @@ static int assign_hw_id(struct drm_i915_private *dev_priv, 
unsigned *out)
int ret;
unsigned int max;
  
-	if (INTEL_GEN(dev_priv) >= 11)

-   max = GEN11_MAX_CONTEXT_HW_ID;
-   else
+   if (INTEL_GEN(dev_priv) >= 11) {
+   if (USES_GUC_SUBMISSION(dev_priv))
+   max = GEN11_MAX_CONTEXT_HW_ID_WITH_GUC;
+   else
+   max = GEN11_MAX_CONTEXT_HW_ID;
+   } else
max = MAX_CONTEXT_HW_ID;
  
  	ret = ida_simple_get(_priv->contexts.hw_ida,

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

Re: [Intel-gfx] [PATCH 10/27] drm/i915/icl: Enhanced execution list support

[Daniele Ceraolo Spurio]

The review from Chris had ended up in my spam folder and I missed it, 
apologies for duplicating some of the comments.


Daniele

On 11/01/18 11:55, Daniele Ceraolo Spurio wrote:



On 09/01/18 15:28, Paulo Zanoni wrote:

From: Thomas Daniel 

Supports two-element submission using the new enhanced execlist mechanism



This could use a few lines to describe enhanced execlist. Something like:

"Enhanced Execlists is an upgraded version of execlists which supports 
up to 8 ports. The lrcs to be submitted are written to a submit queue, 
which is then loaded on the HW. When writing to the ELSP register, the 
lrcs are written cyclically in the queue from position 0 to position 7. 
Alternatively, it is possible to write directly in the individual 
positions of the queue using the ELSQ registers. To be able to re-use 
all the existing code we're using the latter method and we're currently 
limiting ourself to only using 2 elements"



v2: Rebase.
v3: Switch from !IS_GEN11 to GEN < 11 (Daniele Ceraolo Spurio).
v4: Use the elsq registers instead of elsp. (Daniele Ceraolo Spurio)

Signed-off-by: Thomas Daniel 
Signed-off-by: Rodrigo Vivi 
---
  drivers/gpu/drm/i915/intel_lrc.c | 21 -
  drivers/gpu/drm/i915/intel_lrc.h |  3 +++
  2 files changed, 23 insertions(+), 1 deletion(-)

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

index de41ad2d5fbc..3c6f587fa903 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -430,9 +430,18 @@ static inline void elsp_write(u64 desc, u32 
__iomem *elsp)

  static void execlists_submit_ports(struct intel_engine_cs *engine)
  {
+    struct drm_i915_private *dev_priv = engine->i915;
  struct execlist_port *port = engine->execlists.port;
+    u32 __iomem *elsq =
+    engine->i915->regs + i915_mmio_reg_offset(RING_ELSQ(engine));


Should we cache this, like we do for execlists.elsp?


  unsigned int n;
+    /*
+ * Gen11+ note: the submit queue is not cleared after being 
submitted

+ * to the HW so we need to make sure we always clean it up. This is
+ * currently ensured by the fact that we always write the same 
number
+ * of elsq entries, keep this in mind before changing the loop 
below.

+ */
  for (n = execlists_num_ports(>execlists); n--; ) {
  struct drm_i915_gem_request *rq;
  unsigned int count;
@@ -456,8 +465,18 @@ static void execlists_submit_ports(struct 
intel_engine_cs *engine)

  desc = 0;
  }
-    elsp_write(desc, engine->execlists.elsp);
+    if (INTEL_GEN(engine->i915) >= 11) {
+    writel(lower_32_bits(desc), elsq + n * 2);
+    writel(upper_32_bits(desc), elsq + n * 2 + 1);
+    } else {
+    elsp_write(desc, engine->execlists.elsp);
+    }
  }
+
+    /* for gen11+ we need to manually load the submit queue */
+    if (INTEL_GEN(engine->i915) >= 11)
+    I915_WRITE_FW(RING_ELCR(engine), ELCR_LOAD);
+
  execlists_clear_active(>execlists, EXECLISTS_ACTIVE_HWACK);
  }
diff --git a/drivers/gpu/drm/i915/intel_lrc.h 
b/drivers/gpu/drm/i915/intel_lrc.h

index 6d4f9b995a11..cb00e1dd6ed2 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -38,6 +38,9 @@
  #define  CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT    (1 << 0)
  #define   CTX_CTRL_RS_CTX_ENABLE    (1 << 1)
  #define RING_CONTEXT_STATUS_BUF_BASE(engine)
_MMIO((engine)->mmio_base + 0x370)

+#define RING_ELSQ(engine)    _MMIO((engine)->mmio_base + 0x510)
+#define RING_ELCR(engine)    _MMIO((engine)->mmio_base + 0x550)


Do we need to add the new regs to the forcewake domain identification in 
logical_ring_setup? They should be in the same well as ELSP so maybe 
just that one is enough.


+#define  ELCR_LOAD    (1 << 0) >   #define 
RING_CONTEXT_STATUS_BUF_LO(engine, i) 

_MMIO((engine)->mmio_base + 0x370 + (i) * 8)
  #define RING_CONTEXT_STATUS_BUF_HI(engine, i)
_MMIO((engine)->mmio_base + 0x370 + (i) * 8 + 4)
  #define RING_CONTEXT_STATUS_PTR(engine)
_MMIO((engine)->mmio_base + 0x3a0)




Side note, we do have pre-emption enabled in the features but this patch 
does not update inject_preempt_context to use the new way to submit to 
the HW, so I guess that's probably break.


Daniele
___
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/7] drm/i915: Disable preemption and sleeping while using the punit sideband

[Chris Wilson]

Quoting Ville Syrjälä (2018-01-11 20:10:45)
> On Wed, Jan 10, 2018 at 12:55:05PM +, Chris Wilson wrote:
> > While we talk to the punit over its sideband, we need to prevent the cpu
> > from sleeping in order to prevent a potential machine hang.
> > 
> > Note that by itself, it appears that pm_qos_update_request (via
> > intel_idle) doesn't provide a sufficient barrier to ensure that all core
> > are indeed awake (out of Cstate) and that the package is awake. To do so,
> > we need to supplement the pm_qos with a manual ping on_each_cpu.
> > 
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109051
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=102657
> > References: https://bugzilla.kernel.org/show_bug.cgi?id=195255
> > Signed-off-by: Chris Wilson 
> > Cc: Mika Kuoppala 
> > Cc: Hans de Goede 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c   |  6 
> >  drivers/gpu/drm/i915/i915_drv.h   |  1 +
> >  drivers/gpu/drm/i915/intel_sideband.c | 61 
> > ---
> >  3 files changed, 50 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 6c8da9d20c33..d4b90cc0130b 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -902,6 +902,9 @@ static int i915_driver_init_early(struct 
> > drm_i915_private *dev_priv,
> >   spin_lock_init(_priv->uncore.lock);
> >  
> >   mutex_init(_priv->sb_lock);
> > + pm_qos_add_request(_priv->sb_qos,
> > +PM_QOS_CPU_DMA_LATENCY, PM_QOS_DEFAULT_VALUE);
> > +
> >   mutex_init(_priv->modeset_restore_lock);
> >   mutex_init(_priv->av_mutex);
> >   mutex_init(_priv->wm.wm_mutex);
> > @@ -953,6 +956,9 @@ static void i915_driver_cleanup_early(struct 
> > drm_i915_private *dev_priv)
> >   intel_irq_fini(dev_priv);
> >   i915_workqueues_cleanup(dev_priv);
> >   i915_engines_cleanup(dev_priv);
> > +
> > + pm_qos_remove_request(_priv->sb_qos);
> > + mutex_destroy(_priv->sb_lock);
> >  }
> >  
> >  static int i915_mmio_setup(struct drm_i915_private *dev_priv)
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index a689396d0ff6..ff3f9effc0bb 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1887,6 +1887,7 @@ struct drm_i915_private {
> >  
> >   /* Sideband mailbox protection */
> >   struct mutex sb_lock;
> > + struct pm_qos_request sb_qos;
> >  
> >   /** Cached value of IMR to avoid reads in updating the bitfield */
> >   union {
> > diff --git a/drivers/gpu/drm/i915/intel_sideband.c 
> > b/drivers/gpu/drm/i915/intel_sideband.c
> > index 75c872bb8cc9..02bdd2e2cef6 100644
> > --- a/drivers/gpu/drm/i915/intel_sideband.c
> > +++ b/drivers/gpu/drm/i915/intel_sideband.c
> > @@ -22,6 +22,8 @@
> >   *
> >   */
> >  
> > +#include 
> > +
> >  #include "i915_drv.h"
> >  #include "intel_drv.h"
> >  
> > @@ -39,18 +41,20 @@
> >  /* Private register write, double-word addressing, non-posted */
> >  #define SB_CRWRDA_NP 0x07
> >  
> > -static int vlv_sideband_rw(struct drm_i915_private *dev_priv, u32 devfn,
> > -u32 port, u32 opcode, u32 addr, u32 *val)
> > +static void ping(void *info)
> >  {
> > - u32 cmd, be = 0xf, bar = 0;
> > - bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP);
> > +}
> >  
> > - cmd = (devfn << IOSF_DEVFN_SHIFT) | (opcode << IOSF_OPCODE_SHIFT) |
> > - (port << IOSF_PORT_SHIFT) | (be << IOSF_BYTE_ENABLES_SHIFT) |
> > - (bar << IOSF_BAR_SHIFT);
> > +static int vlv_sideband_rw(struct drm_i915_private *dev_priv,
> > +u32 devfn, u32 port, u32 opcode,
> > +u32 addr, u32 *val)
> > +{
> > + const bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP);
> > + int err;
> >  
> > - WARN_ON(!mutex_is_locked(_priv->sb_lock));
> > + lockdep_assert_held(_priv->sb_lock);
> >  
> > + /* Flush the previous comms, just in case it failed last time. */
> >   if (intel_wait_for_register(dev_priv,
> >   VLV_IOSF_DOORBELL_REQ, IOSF_SB_BUSY, 0,
> >   5)) {
> > @@ -59,22 +63,43 @@ static int vlv_sideband_rw(struct drm_i915_private 
> > *dev_priv, u32 devfn,
> >   return -EAGAIN;
> >   }
> >  
> > - I915_WRITE(VLV_IOSF_ADDR, addr);
> > - I915_WRITE(VLV_IOSF_DATA, is_read ? 0 : *val);
> > - I915_WRITE(VLV_IOSF_DOORBELL_REQ, cmd);
> > + iosf_mbi_punit_acquire();
> >  
> > - if (intel_wait_for_register(dev_priv,
> > - VLV_IOSF_DOORBELL_REQ, IOSF_SB_BUSY, 0,
> > - 5)) {
> > + /*
> > +  * Prevent the cpu from sleeping while we use this sideband, otherwise
> > +  

Re: [Intel-gfx] [PATCH 1/8] drm/i915/cnl: Add Port F definition.

[Rodrigo Vivi]

On Thu, Jan 11, 2018 at 06:00:03PM +, Paulo Zanoni wrote:
> From: Rodrigo Vivi 
> 
> Some Cannonlake SKUs will come with a full split between
> port A and port E. This will be called port F although it
> is not a 6th port, but only a split.
> 
> Note this patch alone is not sufficient for port F enabling,
> it's just the first step.
> 
> v2: Fix size of dvo_ports found by Ander.
> v3: Adding missing cases from intel_bios.c for Port_F
> v4: Adding other missing cases and fix the commit message.
> v5: Rebase on top of display headers rework.

> v6 (from Paulo): improve commit message, bikeshed bit definitions.
Acked-by: Rodrigo Vivi 
Thanks

> 
> Cc: Lucas De Marchi 
> Cc: Manasi Navare 
> Reviewed-by: Paulo Zanoni 
> Signed-off-by: Rodrigo Vivi 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_bios.c | 9 +
>  drivers/gpu/drm/i915/intel_display.h  | 1 +
>  drivers/gpu/drm/i915/intel_dp.c   | 2 ++
>  drivers/gpu/drm/i915/intel_vbt_defs.h | 2 ++
>  include/drm/i915_component.h  | 3 +--
>  5 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index 51108ffc28d1..59a150e2adce 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1140,6 +1140,7 @@ static void parse_ddi_port(struct drm_i915_private 
> *dev_priv, enum port port,
>   {DVO_PORT_HDMIC, DVO_PORT_DPC, -1},
>   {DVO_PORT_HDMID, DVO_PORT_DPD, -1},
>   {DVO_PORT_CRT, DVO_PORT_HDMIE, DVO_PORT_DPE},
> + {DVO_PORT_HDMIF, DVO_PORT_DPF, -1},
>   };
>  
>   /*
> @@ -1688,6 +1689,7 @@ bool intel_bios_is_port_present(struct drm_i915_private 
> *dev_priv, enum port por
>   [PORT_C] = { DVO_PORT_DPC, DVO_PORT_HDMIC, },
>   [PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, },
>   [PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, },
> + [PORT_F] = { DVO_PORT_DPF, DVO_PORT_HDMIF, },
>   };
>   int i;
>  
> @@ -1726,6 +1728,7 @@ bool intel_bios_is_port_edp(struct drm_i915_private 
> *dev_priv, enum port port)
>   [PORT_C] = DVO_PORT_DPC,
>   [PORT_D] = DVO_PORT_DPD,
>   [PORT_E] = DVO_PORT_DPE,
> + [PORT_F] = DVO_PORT_DPF,
>   };
>   int i;
>  
> @@ -1761,6 +1764,7 @@ static bool child_dev_is_dp_dual_mode(const struct 
> child_device_config *child,
>   [PORT_C] = { DVO_PORT_DPC, DVO_PORT_HDMIC, },
>   [PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, },
>   [PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, },
> + [PORT_F] = { DVO_PORT_DPF, DVO_PORT_HDMIF, },
>   };
>  
>   if (port == PORT_A || port >= ARRAY_SIZE(port_mapping))
> @@ -1927,6 +1931,11 @@ intel_bios_is_lspcon_present(struct drm_i915_private 
> *dev_priv,
>   if (port == PORT_D)
>   return true;
>   break;
> + case DVO_PORT_DPF:
> + case DVO_PORT_HDMIF:
> + if (port == PORT_F)
> + return true;
> + break;
>   default:
>   break;
>   }
> diff --git a/drivers/gpu/drm/i915/intel_display.h 
> b/drivers/gpu/drm/i915/intel_display.h
> index a0d2b6169361..e47638931b51 100644
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/intel_display.h
> @@ -119,6 +119,7 @@ enum port {
>   PORT_C,
>   PORT_D,
>   PORT_E,
> + PORT_F,
>  
>   I915_MAX_PORTS
>  };
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 68229f53d5b8..46937a8c48cc 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1402,6 +1402,7 @@ static i915_reg_t skl_aux_ctl_reg(struct 
> drm_i915_private *dev_priv,
>   case PORT_B:
>   case PORT_C:
>   case PORT_D:
> + case PORT_F:
>   return DP_AUX_CH_CTL(port);
>   default:
>   MISSING_CASE(port);
> @@ -1417,6 +1418,7 @@ static i915_reg_t skl_aux_data_reg(struct 
> drm_i915_private *dev_priv,
>   case PORT_B:
>   case PORT_C:
>   case PORT_D:
> + case PORT_F:
>   return DP_AUX_CH_DATA(port, index);
>   default:
>   MISSING_CASE(port);
> diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h 
> b/drivers/gpu/drm/i915/intel_vbt_defs.h
> index e3d7745a9151..b5d2341f932c 100644
> --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
> @@ -299,6 +299,8 @@ struct bdb_general_features {
>  #define DVO_PORT_DPA 10
>  #define DVO_PORT_DPE 11  /* 193 */
>  #define DVO_PORT_HDMIE   12   

[Intel-gfx] [PATCH v2 0/6] drm/i915: expose RCS topology to userspace

[Lionel Landwerlin]

Hi all,

Tvrtko found a few bugs in the previous iteration of this series and
also made quite a few recommendations on the stored internal state as
well uapi, so here is an update. Details in the patches.

Thanks a lot,

Lionel Landwerlin (6):
  drm/i915: store all subslice masks
  drm/i915/debugfs: reuse max slice/subslices already stored in sseu
  drm/i915/debugfs: add rcs topology entry
  drm/i915: add rcs topology to error state
  drm/i915: add query uAPI
  drm/i915: expose rcs topology through query uAPI

 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/i915_debugfs.c  |  94 +++
 drivers/gpu/drm/i915/i915_drv.c  |   3 +-
 drivers/gpu/drm/i915/i915_drv.h  |   3 +
 drivers/gpu/drm/i915/i915_gpu_error.c|  40 +++
 drivers/gpu/drm/i915/i915_query.c| 184 +
 drivers/gpu/drm/i915/intel_device_info.c | 196 +++
 drivers/gpu/drm/i915/intel_device_info.h |  36 +-
 drivers/gpu/drm/i915/intel_lrc.c |   2 +-
 drivers/gpu/drm/i915/intel_query_info.c  |  88 ++
 drivers/gpu/drm/i915/intel_ringbuffer.h  |   2 +-
 include/uapi/drm/i915_drm.h  |  82 +
 12 files changed, 652 insertions(+), 79 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_query.c
 create mode 100644 drivers/gpu/drm/i915/intel_query_info.c

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

Re: [Intel-gfx] [PATCH i-g-t v13] tests/kms_frontbuffer_tracking: Including DRRS test coverage

[Rodrigo Vivi]

On Thu, Jan 11, 2018 at 05:27:52AM +, Ramalingam C wrote:
> 
> 
> On Wednesday 10 January 2018 11:45 PM, Rodrigo Vivi wrote:
> 
> On Wed, Jan 10, 2018 at 02:47:00PM +, Lohith BS wrote:
> 
> Dynamic Refresh Rate Switch(DRRS) is used to switch the panel's
> refresh rate to the lowest vrefresh supported by panel, when frame is
> not flipped for more than a Sec.
> 
> In kernel, DRRS uses the front buffer tracking infrastructure.
> Hence DRRS test coverage is added along with other frontbuffer 
> tracking
> based features such as FBC and PSR tests.
> 
> Here, we are testing DRRS with other features in all possible
> combinations, in all required test cases, to capture any possible
> regression.
> 
> v2: Addressed the comments and suggestions from Vlad, Marius.
> The signoff details from the earlier work are also included.
> 
> v3: Modified vblank rate calculation by using reply-sequence,
> provided by drmWaitVBlank, as suggested by Chris Wilson.
> 
> v4: As suggested from Chris Wilson and Daniel Vetter
> 1) Avoided using pthread for calculating vblank refresh rate,
>instead used drmWaitVBlank reply sequence.
> 2) Avoided using kernel-specific info like transitional delays,
>instead polling mechanism with timeout is used.
> 3) Included edp-DRRS as a subtest in kms_frontbuffer_tracking.c,
>instead of having a separate test.
> 
> v5: This patch adds DRRS as a new feature in the
> kms_frontbuffer_tracking IGT.
> DRRS switch to lower vrefresh rate is tested at slow-draw subtest.
> 
> Note:
> 1) Currently kernel doesn't have support to enable and disable
>the DRRS feature dynamically(as in case of PSR). Hence if the
>panel supports DRRS it will be enabled by default.
> 
> This is in continuation of last patch
> "https://patchwork.freedesktop.org/patch/162726/;
> 
> v6: This patch adds runtime enable and disable feature for testing 
> DRRS
> 
> v7: This patch adds runtime enable and disable feature for testing 
> DRRS
> through debugfs entry "i915_drrs_ctl".
> 
> v8: Commit message is updated to reflect current implementation.
> 
> v9: Addressed Paulo Zanoni comments.
> Check for DRRS_LOW at tests with OFFSCREEN + FBS_INDIVIDUAL.
> 
> v10: Corrected DRRS state expectation in suspend related subtests.
> 
> v11: Removing the global flag is_psr_drrs_combo [Rodrigo].
> 
> v12: Rewriting the DRRS inactive deduction [Rodrigo].
> 
> v13: En/Dis-able DRRS only when DRRS is capable on the setup.
> 
> Signed-off-by: Lohith BS 
> Signed-off-by: aknautiy 
> ---
>  tests/kms_frontbuffer_tracking.c | 172 
> +--
>  1 file changed, 164 insertions(+), 8 deletions(-)
> 
> diff --git a/tests/kms_frontbuffer_tracking.c 
> b/tests/kms_frontbuffer_tracking.c
> index 1601cab..6b2299b 100644
> --- a/tests/kms_frontbuffer_tracking.c
> +++ b/tests/kms_frontbuffer_tracking.c
> @@ -34,7 +34,7 @@
> 
> 
>  IGT_TEST_DESCRIPTION("Test the Kernel's frontbuffer tracking 
> mechanism and "
> -"its related features: FBC and PSR");
> +"its related features: FBC, PSR and DRRS");
> 
>  /*
>   * One of the aspects of this test is that, for every subtest, we 
> try different
> @@ -105,8 +105,9 @@ struct test_mode {
> FEATURE_NONE  = 0,
> FEATURE_FBC   = 1,
> FEATURE_PSR   = 2,
> -   FEATURE_COUNT = 4,
> -   FEATURE_DEFAULT = 4,
> +   FEATURE_DRRS  = 4,
> +   FEATURE_COUNT = 8,
> +   FEATURE_DEFAULT = 8,
> } feature;
> 
> /* Possible pixel formats. We just use FORMAT_DEFAULT for 
> most tests and
> @@ -182,6 +183,13 @@ struct {
> .can_test = false,
>  };
> 
> +#define MAX_DRRS_STATUS_BUF_LEN 256
> +
> +struct {
> +   bool can_test;
> +} drrs = {
> +   .can_test = false,
> +};
> 
>  #define SINK_CRC_SIZE 12
>  typedef struct {
> @@ -790,7 +798,14 @@ static void __debugfs_read(const char *param, 
> char *buf, int len)
> buf[len] = '\0';
>  }
> 
> +static void __debugfs_write(const char *param, char *buf, int len)
> +{
> +   igt_assert_eq(igt_sysfs_write(drm.debugfs, param, buf, len - 
> 1),
> + len - 1);

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Disable preemption and sleeping while using the punit sideband

[Ville Syrjälä]

On Wed, Jan 10, 2018 at 12:55:05PM +, Chris Wilson wrote:
> While we talk to the punit over its sideband, we need to prevent the cpu
> from sleeping in order to prevent a potential machine hang.
> 
> Note that by itself, it appears that pm_qos_update_request (via
> intel_idle) doesn't provide a sufficient barrier to ensure that all core
> are indeed awake (out of Cstate) and that the package is awake. To do so,
> we need to supplement the pm_qos with a manual ping on_each_cpu.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109051
> References: https://bugs.freedesktop.org/show_bug.cgi?id=102657
> References: https://bugzilla.kernel.org/show_bug.cgi?id=195255
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Hans de Goede 
> ---
>  drivers/gpu/drm/i915/i915_drv.c   |  6 
>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>  drivers/gpu/drm/i915/intel_sideband.c | 61 
> ---
>  3 files changed, 50 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 6c8da9d20c33..d4b90cc0130b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -902,6 +902,9 @@ static int i915_driver_init_early(struct drm_i915_private 
> *dev_priv,
>   spin_lock_init(_priv->uncore.lock);
>  
>   mutex_init(_priv->sb_lock);
> + pm_qos_add_request(_priv->sb_qos,
> +PM_QOS_CPU_DMA_LATENCY, PM_QOS_DEFAULT_VALUE);
> +
>   mutex_init(_priv->modeset_restore_lock);
>   mutex_init(_priv->av_mutex);
>   mutex_init(_priv->wm.wm_mutex);
> @@ -953,6 +956,9 @@ static void i915_driver_cleanup_early(struct 
> drm_i915_private *dev_priv)
>   intel_irq_fini(dev_priv);
>   i915_workqueues_cleanup(dev_priv);
>   i915_engines_cleanup(dev_priv);
> +
> + pm_qos_remove_request(_priv->sb_qos);
> + mutex_destroy(_priv->sb_lock);
>  }
>  
>  static int i915_mmio_setup(struct drm_i915_private *dev_priv)
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a689396d0ff6..ff3f9effc0bb 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1887,6 +1887,7 @@ struct drm_i915_private {
>  
>   /* Sideband mailbox protection */
>   struct mutex sb_lock;
> + struct pm_qos_request sb_qos;
>  
>   /** Cached value of IMR to avoid reads in updating the bitfield */
>   union {
> diff --git a/drivers/gpu/drm/i915/intel_sideband.c 
> b/drivers/gpu/drm/i915/intel_sideband.c
> index 75c872bb8cc9..02bdd2e2cef6 100644
> --- a/drivers/gpu/drm/i915/intel_sideband.c
> +++ b/drivers/gpu/drm/i915/intel_sideband.c
> @@ -22,6 +22,8 @@
>   *
>   */
>  
> +#include 
> +
>  #include "i915_drv.h"
>  #include "intel_drv.h"
>  
> @@ -39,18 +41,20 @@
>  /* Private register write, double-word addressing, non-posted */
>  #define SB_CRWRDA_NP 0x07
>  
> -static int vlv_sideband_rw(struct drm_i915_private *dev_priv, u32 devfn,
> -u32 port, u32 opcode, u32 addr, u32 *val)
> +static void ping(void *info)
>  {
> - u32 cmd, be = 0xf, bar = 0;
> - bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP);
> +}
>  
> - cmd = (devfn << IOSF_DEVFN_SHIFT) | (opcode << IOSF_OPCODE_SHIFT) |
> - (port << IOSF_PORT_SHIFT) | (be << IOSF_BYTE_ENABLES_SHIFT) |
> - (bar << IOSF_BAR_SHIFT);
> +static int vlv_sideband_rw(struct drm_i915_private *dev_priv,
> +u32 devfn, u32 port, u32 opcode,
> +u32 addr, u32 *val)
> +{
> + const bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP);
> + int err;
>  
> - WARN_ON(!mutex_is_locked(_priv->sb_lock));
> + lockdep_assert_held(_priv->sb_lock);
>  
> + /* Flush the previous comms, just in case it failed last time. */
>   if (intel_wait_for_register(dev_priv,
>   VLV_IOSF_DOORBELL_REQ, IOSF_SB_BUSY, 0,
>   5)) {
> @@ -59,22 +63,43 @@ static int vlv_sideband_rw(struct drm_i915_private 
> *dev_priv, u32 devfn,
>   return -EAGAIN;
>   }
>  
> - I915_WRITE(VLV_IOSF_ADDR, addr);
> - I915_WRITE(VLV_IOSF_DATA, is_read ? 0 : *val);
> - I915_WRITE(VLV_IOSF_DOORBELL_REQ, cmd);
> + iosf_mbi_punit_acquire();
>  
> - if (intel_wait_for_register(dev_priv,
> - VLV_IOSF_DOORBELL_REQ, IOSF_SB_BUSY, 0,
> - 5)) {
> + /*
> +  * Prevent the cpu from sleeping while we use this sideband, otherwise
> +  * the punit may cause a machine hang.
> +  */
> + pm_qos_update_request(_priv->sb_qos, 0);
> + on_each_cpu(ping, NULL, 1);

pm_qos_update_request() doesn't wake up the cpus on its own? I wonder
kind of latency guarantees it can actually give without doing that.

Shouldn't we 

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Disable preemption and sleeping while using the punit sideband

[Hans de Goede]

Hi,

On 10-01-18 14:18, Hans de Goede wrote:

Hi,

On 10-01-18 13:55, Chris Wilson wrote:

While we talk to the punit over its sideband, we need to prevent the cpu
from sleeping in order to prevent a potential machine hang.

Note that by itself, it appears that pm_qos_update_request (via
intel_idle) doesn't provide a sufficient barrier to ensure that all core
are indeed awake (out of Cstate) and that the package is awake. To do so,
we need to supplement the pm_qos with a manual ping on_each_cpu.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109051
References: https://bugs.freedesktop.org/show_bug.cgi?id=102657
References: https://bugzilla.kernel.org/show_bug.cgi?id=195255
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Hans de Goede 


Interesting, I've added similar pm_qos code in
drivers/i2c/busses/i2c-designware-baytrail.c quite a while ago because
the CPU transitioning to higher C-state while accessing the i2c bus to
the pmic (if it is shared) also causes the SoC to hang.

I could reproduce this quite easily by doing "i2cdump" on the pmic,
usually the system would hang in one or 2 i2cdump calls.

Note IIRC this was on CHT.

I see that you also block any pmic-i2c bus accesses while doing
punit access by calling iosf_mbi_punit_acquire();

Maybe we need to move the pm_qos stuff out of
drivers/i2c/busses/i2c-designware-baytrail.c

And into iosf_mbi_punit_acquire? The i2c-designware-baytrail.c
does its own pm_qos dance directly after calling
iosf_mbi_punit_acquire / before calling iosf_mbi_punit_release();


I just remembered that the i915 code also call iosf_mbi_punit_acquire()
from drivers/gpu/drm/i915/intel_uncore.c and does it for non VLV/CHT
boards there too. Currently that is not an issue because
iosf_mbi_punit_acquire() currently is a nop for non VLV/CHT, but if
we move the pm_qos stuff there then it no longer is a nop, so it is
probably best to keep separate pm_qos code in intel_sideband.c and
i2c-designware-baytrail.c, iow move ahead with this patch as as,
except for maybe moving the ping stuff to the intel_idle.c code.

Regards,

Hans




---
  drivers/gpu/drm/i915/i915_drv.c   |  6 
  drivers/gpu/drm/i915/i915_drv.h   |  1 +
  drivers/gpu/drm/i915/intel_sideband.c | 61 ---
  3 files changed, 50 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6c8da9d20c33..d4b90cc0130b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -902,6 +902,9 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
  spin_lock_init(_priv->uncore.lock);
  mutex_init(_priv->sb_lock);
+    pm_qos_add_request(_priv->sb_qos,
+   PM_QOS_CPU_DMA_LATENCY, PM_QOS_DEFAULT_VALUE);
+
  mutex_init(_priv->modeset_restore_lock);
  mutex_init(_priv->av_mutex);
  mutex_init(_priv->wm.wm_mutex);
@@ -953,6 +956,9 @@ static void i915_driver_cleanup_early(struct 
drm_i915_private *dev_priv)
  intel_irq_fini(dev_priv);
  i915_workqueues_cleanup(dev_priv);
  i915_engines_cleanup(dev_priv);
+
+    pm_qos_remove_request(_priv->sb_qos);
+    mutex_destroy(_priv->sb_lock);
  }
  static int i915_mmio_setup(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a689396d0ff6..ff3f9effc0bb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1887,6 +1887,7 @@ struct drm_i915_private {
  /* Sideband mailbox protection */
  struct mutex sb_lock;
+    struct pm_qos_request sb_qos;
  /** Cached value of IMR to avoid reads in updating the bitfield */
  union {
diff --git a/drivers/gpu/drm/i915/intel_sideband.c 
b/drivers/gpu/drm/i915/intel_sideband.c
index 75c872bb8cc9..02bdd2e2cef6 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -22,6 +22,8 @@
   *
   */
+#include 
+
  #include "i915_drv.h"
  #include "intel_drv.h"
@@ -39,18 +41,20 @@
  /* Private register write, double-word addressing, non-posted */
  #define SB_CRWRDA_NP    0x07
-static int vlv_sideband_rw(struct drm_i915_private *dev_priv, u32 devfn,
-   u32 port, u32 opcode, u32 addr, u32 *val)
+static void ping(void *info)
  {
-    u32 cmd, be = 0xf, bar = 0;
-    bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP);
+}
-    cmd = (devfn << IOSF_DEVFN_SHIFT) | (opcode << IOSF_OPCODE_SHIFT) |
-    (port << IOSF_PORT_SHIFT) | (be << IOSF_BYTE_ENABLES_SHIFT) |
-    (bar << IOSF_BAR_SHIFT);
+static int vlv_sideband_rw(struct drm_i915_private *dev_priv,
+   u32 devfn, u32 port, u32 opcode,
+   u32 addr, u32 *val)
+{
+    const bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP);
+    int err;
-    WARN_ON(!mutex_is_locked(_priv->sb_lock));
+    lockdep_assert_held(_priv->sb_lock);
+    

[Intel-gfx] [PATCH v2 2/6] drm/i915/debugfs: reuse max slice/subslices already stored in sseu

[Lionel Landwerlin]

Now that we have that information in topology fields, let's just reused it.

v2: Style tweaks (Tvrtko)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 27 +++
 1 file changed, 11 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 463029f72a0b..2d1c9cce5fe4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4300,11 +4300,11 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 struct sseu_dev_info *sseu)
 {
const struct intel_device_info *info = INTEL_INFO(dev_priv);
-   int s_max = 6, ss_max = 4;
int s, ss;
-   u32 s_reg[s_max], eu_reg[2 * s_max], eu_mask[2];
+   u32 s_reg[info->sseu.max_slices];
+   u32 eu_reg[2 * info->sseu.max_subslices], eu_mask[2];
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
/*
 * FIXME: Valid SS Mask respects the spec and read
 * only valid bits for those registers, excluding reserverd
@@ -4326,7 +4326,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 GEN9_PGCTL_SSB_EU210_ACK |
 GEN9_PGCTL_SSB_EU311_ACK;
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
/* skip disabled slice */
continue;
@@ -4334,7 +4334,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask |= BIT(s);
sseu->subslice_mask[s] = info->sseu.subslice_mask[s];
 
-   for (ss = 0; ss < ss_max; ss++) {
+   for (ss = 0; ss < info->sseu.max_subslices; ss++) {
unsigned int eu_cnt;
 
if (!(s_reg[s] & (GEN9_PGCTL_SS_ACK(ss
@@ -4354,17 +4354,12 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 static void gen9_sseu_device_status(struct drm_i915_private *dev_priv,
struct sseu_dev_info *sseu)
 {
-   int s_max = 3, ss_max = 4;
+   const struct intel_device_info *info = INTEL_INFO(dev_priv);
int s, ss;
-   u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
-
-   /* BXT has a single slice and at most 3 subslices. */
-   if (IS_GEN9_LP(dev_priv)) {
-   s_max = 1;
-   ss_max = 3;
-   }
+   u32 s_reg[info->sseu.max_slices];
+   u32 eu_reg[2 * info->sseu.max_subslices], eu_mask[2];
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
s_reg[s] = I915_READ(GEN9_SLICE_PGCTL_ACK(s));
eu_reg[2*s] = I915_READ(GEN9_SS01_EU_PGCTL_ACK(s));
eu_reg[2*s + 1] = I915_READ(GEN9_SS23_EU_PGCTL_ACK(s));
@@ -4379,7 +4374,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
 GEN9_PGCTL_SSB_EU210_ACK |
 GEN9_PGCTL_SSB_EU311_ACK;
 
-   for (s = 0; s < s_max; s++) {
+   for (s = 0; s < info->sseu.max_slices; s++) {
if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
/* skip disabled slice */
continue;
@@ -4390,7 +4385,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->subslice_mask[s] =
INTEL_INFO(dev_priv)->sseu.subslice_mask[s];
 
-   for (ss = 0; ss < ss_max; ss++) {
+   for (ss = 0; ss < info->sseu.max_subslices; ss++) {
unsigned int eu_cnt;
 
if (IS_GEN9_LP(dev_priv)) {
-- 
2.15.1

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

[Intel-gfx] [PATCH v2 4/6] drm/i915: add rcs topology to error state

[Lionel Landwerlin]

This might be useful information for developers looking at an error
state.

v2: Place topology towards the end of the error state (Chris)

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 40 +++
 1 file changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 944059322daa..cc7f53cc9a77 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -605,6 +605,45 @@ static void err_print_uc(struct drm_i915_error_state_buf 
*m,
print_error_obj(m, NULL, "GuC log buffer", error_uc->guc_log);
 }
 
+static void err_print_rcs_topology(struct drm_i915_error_state_buf *m,
+  const struct sseu_dev_info *sseu)
+{
+   int s, ss;
+   int subslice_stride =
+   DIV_ROUND_UP(sseu->max_eus_per_subslice, BITS_PER_BYTE);
+
+   /* Unavailable prior to Gen 8. */
+   if (sseu->max_slices == 0)
+   return;
+
+   err_printf(m, "RCS topology:\n");
+
+   for (s = 0; s < sseu->max_slices; s++) {
+   err_printf(m, "  slice%i %u subslice(s) (0x%hhx):\n",
+  s, hweight8(sseu->subslice_mask[s]),
+  sseu->subslice_mask[s]);
+
+   for (ss = 0; ss < sseu->max_subslices; ss++) {
+   int eu_group, n_subslice_eus = 0;
+
+   for (eu_group = 0; eu_group < subslice_stride; 
eu_group++) {
+   n_subslice_eus +=
+   hweight8(sseu_eu_mask(sseu, s, ss, 
eu_group));
+   }
+
+   err_printf(m, "subslice%i: %u EUs (", ss, 
n_subslice_eus);
+   for (eu_group = 0;
+eu_group < max(0, subslice_stride - 1);
+eu_group++) {
+   u8 val = sseu_eu_mask(sseu, s, ss, eu_group);
+   err_printf(m, " 0x%hhx", val);
+   }
+   err_printf(m, "0x%hhx)\n",
+  sseu_eu_mask(sseu, s, ss, subslice_stride - 
1));
+   }
+   }
+}
+
 int i915_error_state_to_str(struct drm_i915_error_state_buf *m,
const struct i915_gpu_state *error)
 {
@@ -787,6 +826,7 @@ int i915_error_state_to_str(struct drm_i915_error_state_buf 
*m,
intel_display_print_error_state(m, error->display);
 
err_print_capabilities(m, >device_info);
+   err_print_rcs_topology(m, _INFO(dev_priv)->sseu);
err_print_params(m, >params);
err_print_uc(m, >uc);
 
-- 
2.15.1

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

[Intel-gfx] [PATCH v2 1/6] drm/i915: store all subslice masks

[Lionel Landwerlin]

Up to now, subslice mask was assumed to be uniform across slices. But
starting with Cannonlake, slices can be asymmetric (for example slice0
has different number of subslices as slice1+). This change stores all
subslices masks for all slices rather than having a single mask that
applies to all slices.

v2: Rework how we store total numbers in sseu_dev_info (Tvrtko)
Fix CHV eu masks, was reading disabled as enabled (Tvrtko)
Readability changes (Tvrtko)
Add EU index helper (Tvrtko)

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  25 ++--
 drivers/gpu/drm/i915/i915_drv.c  |   2 +-
 drivers/gpu/drm/i915/intel_device_info.c | 196 +++
 drivers/gpu/drm/i915/intel_device_info.h |  36 +-
 drivers/gpu/drm/i915/intel_lrc.c |   2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |   2 +-
 6 files changed, 200 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2bb63073d73f..463029f72a0b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4285,7 +4285,7 @@ static void cherryview_sseu_device_status(struct 
drm_i915_private *dev_priv,
continue;
 
sseu->slice_mask = BIT(0);
-   sseu->subslice_mask |= BIT(ss);
+   sseu->subslice_mask[0] |= BIT(ss);
eu_cnt = ((sig1[ss] & CHV_EU08_PG_ENABLE) ? 0 : 2) +
 ((sig1[ss] & CHV_EU19_PG_ENABLE) ? 0 : 2) +
 ((sig1[ss] & CHV_EU210_PG_ENABLE) ? 0 : 2) +
@@ -4332,7 +4332,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
continue;
 
sseu->slice_mask |= BIT(s);
-   sseu->subslice_mask = info->sseu.subslice_mask;
+   sseu->subslice_mask[s] = info->sseu.subslice_mask[s];
 
for (ss = 0; ss < ss_max; ss++) {
unsigned int eu_cnt;
@@ -4387,8 +4387,8 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask |= BIT(s);
 
if (IS_GEN9_BC(dev_priv))
-   sseu->subslice_mask =
-   INTEL_INFO(dev_priv)->sseu.subslice_mask;
+   sseu->subslice_mask[s] =
+   INTEL_INFO(dev_priv)->sseu.subslice_mask[s];
 
for (ss = 0; ss < ss_max; ss++) {
unsigned int eu_cnt;
@@ -4398,7 +4398,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
/* skip disabled subslice */
continue;
 
-   sseu->subslice_mask |= BIT(ss);
+   sseu->subslice_mask[s] |= BIT(ss);
}
 
eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] &
@@ -4420,9 +4420,12 @@ static void broadwell_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask = slice_info & GEN8_LSLICESTAT_MASK;
 
if (sseu->slice_mask) {
-   sseu->subslice_mask = INTEL_INFO(dev_priv)->sseu.subslice_mask;
sseu->eu_per_subslice =
INTEL_INFO(dev_priv)->sseu.eu_per_subslice;
+   for (s = 0; s < fls(sseu->slice_mask); s++) {
+   sseu->subslice_mask[s] =
+   INTEL_INFO(dev_priv)->sseu.subslice_mask[s];
+   }
sseu->eu_total = sseu->eu_per_subslice *
 sseu_subslice_total(sseu);
 
@@ -4441,6 +,7 @@ static void i915_print_sseu_info(struct seq_file *m, bool 
is_available_info,
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
const char *type = is_available_info ? "Available" : "Enabled";
+   int s;
 
seq_printf(m, "  %s Slice Mask: %04x\n", type,
   sseu->slice_mask);
@@ -4448,10 +4452,11 @@ static void i915_print_sseu_info(struct seq_file *m, 
bool is_available_info,
   hweight8(sseu->slice_mask));
seq_printf(m, "  %s Subslice Total: %u\n", type,
   sseu_subslice_total(sseu));
-   seq_printf(m, "  %s Subslice Mask: %04x\n", type,
-  sseu->subslice_mask);
-   seq_printf(m, "  %s Subslice Per Slice: %u\n", type,
-  hweight8(sseu->subslice_mask));
+   for (s = 0; s < fls(sseu->slice_mask); s++) {
+   seq_printf(m, "  %s Slice%i %u subslices, mask=%04x\n", type,
+  s, hweight8(sseu->subslice_mask[s]),
+  sseu->subslice_mask[s]);
+   }
seq_printf(m, "  %s EU Total: %u\n", type,
   sseu->eu_total);
seq_printf(m, "  %s EU Per Subslice: %u\n", type,
diff --git 

Re: [Intel-gfx] [PATCH 10/27] drm/i915/icl: Enhanced execution list support

[Daniele Ceraolo Spurio]

On 09/01/18 15:28, Paulo Zanoni wrote:

From: Thomas Daniel 

Supports two-element submission using the new enhanced execlist mechanism



This could use a few lines to describe enhanced execlist. Something like:

"Enhanced Execlists is an upgraded version of execlists which supports 
up to 8 ports. The lrcs to be submitted are written to a submit queue, 
which is then loaded on the HW. When writing to the ELSP register, the 
lrcs are written cyclically in the queue from position 0 to position 7. 
Alternatively, it is possible to write directly in the individual 
positions of the queue using the ELSQ registers. To be able to re-use 
all the existing code we're using the latter method and we're currently 
limiting ourself to only using 2 elements"



v2: Rebase.
v3: Switch from !IS_GEN11 to GEN < 11 (Daniele Ceraolo Spurio).
v4: Use the elsq registers instead of elsp. (Daniele Ceraolo Spurio)

Signed-off-by: Thomas Daniel 
Signed-off-by: Rodrigo Vivi 
---
  drivers/gpu/drm/i915/intel_lrc.c | 21 -
  drivers/gpu/drm/i915/intel_lrc.h |  3 +++
  2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index de41ad2d5fbc..3c6f587fa903 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -430,9 +430,18 @@ static inline void elsp_write(u64 desc, u32 __iomem *elsp)
  
  static void execlists_submit_ports(struct intel_engine_cs *engine)

  {
+   struct drm_i915_private *dev_priv = engine->i915;
struct execlist_port *port = engine->execlists.port;
+   u32 __iomem *elsq =
+   engine->i915->regs + i915_mmio_reg_offset(RING_ELSQ(engine));


Should we cache this, like we do for execlists.elsp?


unsigned int n;
  
+	/*

+* Gen11+ note: the submit queue is not cleared after being submitted
+* to the HW so we need to make sure we always clean it up. This is
+* currently ensured by the fact that we always write the same number
+* of elsq entries, keep this in mind before changing the loop below.
+*/
for (n = execlists_num_ports(>execlists); n--; ) {
struct drm_i915_gem_request *rq;
unsigned int count;
@@ -456,8 +465,18 @@ static void execlists_submit_ports(struct intel_engine_cs 
*engine)
desc = 0;
}
  
-		elsp_write(desc, engine->execlists.elsp);

+   if (INTEL_GEN(engine->i915) >= 11) {
+   writel(lower_32_bits(desc), elsq + n * 2);
+   writel(upper_32_bits(desc), elsq + n * 2 + 1);
+   } else {
+   elsp_write(desc, engine->execlists.elsp);
+   }
}
+
+   /* for gen11+ we need to manually load the submit queue */
+   if (INTEL_GEN(engine->i915) >= 11)
+   I915_WRITE_FW(RING_ELCR(engine), ELCR_LOAD);
+
execlists_clear_active(>execlists, EXECLISTS_ACTIVE_HWACK);
  }
  
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h

index 6d4f9b995a11..cb00e1dd6ed2 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -38,6 +38,9 @@
  #define CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT   (1 << 0)
  #define   CTX_CTRL_RS_CTX_ENABLE(1 << 1)
  #define RING_CONTEXT_STATUS_BUF_BASE(engine)  _MMIO((engine)->mmio_base + 
0x370)
+#define RING_ELSQ(engine)  _MMIO((engine)->mmio_base + 
0x510)
+#define RING_ELCR(engine)  _MMIO((engine)->mmio_base + 
0x550)


Do we need to add the new regs to the forcewake domain identification in 
logical_ring_setup? They should be in the same well as ELSP so maybe 
just that one is enough.


+#define	  ELCR_LOAD(1 << 0) >   #define RING_CONTEXT_STATUS_BUF_LO(engine, i) 

_MMIO((engine)->mmio_base + 0x370 + (i) * 8)

  #define RING_CONTEXT_STATUS_BUF_HI(engine, i) _MMIO((engine)->mmio_base + 
0x370 + (i) * 8 + 4)
  #define RING_CONTEXT_STATUS_PTR(engine)   
_MMIO((engine)->mmio_base + 0x3a0)



Side note, we do have pre-emption enabled in the features but this patch 
does not update inject_preempt_context to use the new way to submit to 
the HW, so I guess that's probably break.


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

Re: [Intel-gfx] [PATCH v3] drm/i915/icl: Gen11 render context size

[Rodrigo Vivi]

On Thu, Jan 11, 2018 at 06:23:20PM +, Oscar Mateo wrote:
> From: Tvrtko Ursulin 
> 
> Gen11 removes the Resource Streamer, which frees up a big chunk of
> the context image. BSpec indicates 12538 DWORDs (13 pages), plus
> one page for PPHWSP.
> 
> Please notice that, when looking at the BSpec context image table,
> the right filter has to be applied (e.g. "IcelakeLP") as some rows
> are excluded for specific GENs. Also, some rows apply per-subslice
> (for the calculation above, we have supposed 8 subslices which is
> the maximum SKU we expect).
> 
> v2: Rebase.
> v3: Use the right size as per the BSpec.
> 
> BSpec: 18907
> 
> Acked-by: Ben Widawsky 
> Signed-off-by: Tvrtko Ursulin 
> Signed-off-by: Oscar Mateo 
> ---
>  drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index e88b2fd..79b7d36 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -41,6 +41,7 @@
>  #define GEN8_LR_CONTEXT_RENDER_SIZE  (20 * PAGE_SIZE)
>  #define GEN9_LR_CONTEXT_RENDER_SIZE  (22 * PAGE_SIZE)
>  #define GEN10_LR_CONTEXT_RENDER_SIZE (18 * PAGE_SIZE)
> +#define GEN11_LR_CONTEXT_RENDER_SIZE (14 * PAGE_SIZE)
>  
>  #define GEN8_LR_CONTEXT_OTHER_SIZE   ( 2 * PAGE_SIZE)
>  
> @@ -181,6 +182,8 @@ struct engine_info {
>   switch (INTEL_GEN(dev_priv)) {
>   default:
>   MISSING_CASE(INTEL_GEN(dev_priv));

I believe this default is getting danger as we decrease the size here.
I believe the safest one for missing case is the largest one whatever that is.

> + case 11:
> + return GEN11_LR_CONTEXT_RENDER_SIZE;
>   case 10:
>   return GEN10_LR_CONTEXT_RENDER_SIZE;
>   case 9:
> -- 
> 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

[Intel-gfx] [PATCH v2 3/6] drm/i915/debugfs: add rcs topology entry

[Lionel Landwerlin]

While the end goal is to make this information available to userspace
through a new ioctl, there is no reason we can't display it in a human
readable fashion through debugfs.

slice0: 3 subslice(s) (0x7):
subslice0: 8 EUs (0xff)
subslice1: 8 EUs (0xff)
subslice2: 8 EUs (0xff)
subslice3: 0 EUs (0x0)
slice1: 3 subslice(s) (0x7):
subslice0: 8 EUs (0xff)
subslice1: 8 EUs (0xff)
subslice2: 8 EUs (0xff)
subslice3: 0 EUs (0x0)
slice2: 3 subslice(s) (0x7):
subslice0: 8 EUs (0xff)
subslice1: 8 EUs (0xff)
subslice2: 8 EUs (0xff)
subslice3: 0 EUs (0x0)

v2: Reformat debugfs printing (Tvrtko)
Use the new EU mask helper (Tvrtko)

Suggested-by: Chris Wilson 
Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 42 +
 1 file changed, 42 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2d1c9cce5fe4..83af1029b907 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3162,6 +3162,47 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
return 0;
 }
 
+static int i915_rcs_topology(struct seq_file *m, void *unused)
+{
+   struct drm_i915_private *dev_priv = node_to_i915(m->private);
+   const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+   int s, ss;
+   int subslice_stride =
+   DIV_ROUND_UP(sseu->max_eus_per_subslice, BITS_PER_BYTE);
+
+   if (sseu->max_slices == 0) {
+   seq_printf(m, "Unavailable\n");
+   return 0;
+   }
+
+   for (s = 0; s < sseu->max_slices; s++) {
+   seq_printf(m, "slice%i: %u subslice(s) (0x%hhx):\n",
+  s, hweight8(sseu->subslice_mask[s]),
+  sseu->subslice_mask[s]);
+
+   for (ss = 0; ss < sseu->max_subslices; ss++) {
+   int eu_group, n_subslice_eus = 0;
+
+   for (eu_group = 0; eu_group < subslice_stride; 
eu_group++) {
+   n_subslice_eus +=
+   hweight8(sseu_eu_mask(sseu, s, ss, 
eu_group));
+   }
+
+   seq_printf(m, "\tsubslice%i: %u EUs (", ss, 
n_subslice_eus);
+   for (eu_group = 0;
+eu_group < max(0, subslice_stride - 1);
+eu_group++) {
+   u8 val = sseu_eu_mask(sseu, s, ss, eu_group);
+   seq_printf(m, "0x%hhx, ", val);
+   }
+   seq_printf(m, "0x%hhx)\n",
+  sseu_eu_mask(sseu, s, ss, subslice_stride - 
1));
+   }
+   }
+
+   return 0;
+}
+
 static int i915_shrinker_info(struct seq_file *m, void *unused)
 {
struct drm_i915_private *i915 = node_to_i915(m->private);
@@ -4692,6 +4733,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_dmc_info", i915_dmc_info, 0},
{"i915_display_info", i915_display_info, 0},
{"i915_engine_info", i915_engine_info, 0},
+   {"i915_rcs_topology", i915_rcs_topology, 0},
{"i915_shrinker_info", i915_shrinker_info, 0},
{"i915_shared_dplls_info", i915_shared_dplls_info, 0},
{"i915_dp_mst_info", i915_dp_mst_info, 0},
-- 
2.15.1

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

[Intel-gfx] [PATCH v2 5/6] drm/i915: add query uAPI

[Lionel Landwerlin]

There are a number of information that are readable from hardware
registers and that we would like to make accessible to userspace. One
particular example is the topology of the execution units (how are
execution units grouped in subslices and slices and also which ones
have been fused off for die recovery).

At the moment the GET_PARAM ioctl covers some basic needs, but
generally is only able to return a single value for each defined
parameter. This is a bit problematic with topology descriptions which
are array/maps of available units.

This change introduces a new ioctl that can deal with requests to fill
structures of potentially variable lengths. The user is expected fill
a query with length fields set at 0 on the first call, the kernel then
sets the length fields to the their expected values. A second call to
the kernel with length fields at their expected values will trigger a
copy of the data to the pointed memory locations.

The scope of this uAPI is only to provide information to userspace,
not to allow configuration of the device.

v2: Simplify dispatcher code iteration (Tvrtko)
Tweak uapi drm_i915_query_item structure (Tvrtko)

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/Makefile |  1 +
 drivers/gpu/drm/i915/i915_drv.c   |  1 +
 drivers/gpu/drm/i915/i915_drv.h   |  3 +++
 drivers/gpu/drm/i915/i915_query.c | 51 +++
 include/uapi/drm/i915_drm.h   | 31 
 5 files changed, 87 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/i915_query.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 3bddd8a06806..b0415a3e2d59 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -69,6 +69,7 @@ i915-y += i915_cmd_parser.o \
  i915_gem_timeline.o \
  i915_gem_userptr.o \
  i915_gemfs.o \
+ i915_query.o \
  i915_trace_points.o \
  i915_vma.o \
  intel_breadcrumbs.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 969835d3cbcd..d92e1b7236fc 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2824,6 +2824,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, i915_perf_add_config_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG, 
i915_perf_remove_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_QUERY, i915_query_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
 };
 
 static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a689396d0ff6..de0eb6ce2fcd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3623,6 +3623,9 @@ 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_query.c */
+int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file 
*file);
+
 /* 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_query.c 
b/drivers/gpu/drm/i915/i915_query.c
new file mode 100644
index ..5694cfea4553
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -0,0 +1,51 @@
+/*
+ * 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"
+#include 
+
+int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file *file)
+{
+   struct drm_i915_query *args = data;
+   struct 

[Intel-gfx] [PATCH v2 6/6] drm/i915: expose rcs topology through query uAPI

[Lionel Landwerlin]

With the introduction of asymmetric slices in CNL, we cannot rely on
the previous SUBSLICE_MASK getparam to tell userspace what subslices
are available. Here we introduce a more detailed way of querying the
Gen's GPU topology that doesn't aggregate numbers.

This is essential for monitoring parts of the GPU with the OA unit,
because counters need to be normalized to the number of
EUs/subslices/slices. The current aggregated numbers like EU_TOTAL do
not gives us sufficient information.

As a bonus we can draw representations of the GPU :

https://imgur.com/a/vuqpa

v2: Rename uapi struct s/_mask/_info/ (Tvrtko)
Report max_slice/subslice/eus_per_subslice rather than strides (Tvrtko)
Add uapi macros to read data from *_info structs (Tvrtko)

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_query.c   | 133 
 drivers/gpu/drm/i915/intel_query_info.c |  88 +
 include/uapi/drm/i915_drm.h |  51 
 3 files changed, 272 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/intel_query_info.c

diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c
index 5694cfea4553..1d9f5a15323c 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -25,8 +25,128 @@
 #include "i915_drv.h"
 #include 
 
+static int query_slices_info(struct drm_i915_private *dev_priv,
+struct drm_i915_query_item *query_item)
+{
+   const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+   struct drm_i915_query_slices_info slices_info;
+   u32 data_length, length;
+
+   if (sseu->max_slices == 0)
+   return -ENODEV;
+
+   data_length = sizeof(u8);
+   length = sizeof(slices_info) + data_length;
+
+   /*
+* If we ever change the internal slice mask data type, we'll need to
+* update this function.
+*/
+   BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask));
+
+   if (query_item->length == 0) {
+   query_item->length = length;
+   return 0;
+   }
+
+   if (query_item->length != length)
+   return -EINVAL;
+
+   memset(_info, 0, sizeof(slices_info));
+   slices_info.max_slices = sseu->max_slices;
+
+   if (copy_to_user(u64_to_user_ptr(query_item->data_ptr), _info,
+sizeof(slices_info)))
+   return -EFAULT;
+
+   if (copy_to_user(u64_to_user_ptr(query_item->data_ptr +
+offsetof(struct 
drm_i915_query_slices_info, data)),
+>slice_mask, data_length))
+   return -EFAULT;
+
+   return 0;
+}
+
+static int query_subslices_info(struct drm_i915_private *dev_priv,
+   struct drm_i915_query_item *query_item)
+{
+   const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+   struct drm_i915_query_subslices_info subslices_info;
+   u32 data_length, length;
+
+   if (sseu->max_slices == 0)
+   return -ENODEV;
+
+   memset(_info, 0, sizeof(subslices_info));
+   subslices_info.max_slices = sseu->max_slices;
+   subslices_info.max_subslices = sseu->max_subslices;
+
+   data_length = subslices_info.max_slices *
+   DIV_ROUND_UP(subslices_info.max_subslices, BITS_PER_BYTE);
+   length = sizeof(subslices_info) + data_length;
+
+   if (query_item->length == 0) {
+   query_item->length = length;
+   return 0;
+   }
+
+   if (query_item->length != length)
+   return -EINVAL;
+
+   if (copy_to_user(u64_to_user_ptr(query_item->data_ptr), _info,
+sizeof(subslices_info)))
+   return -EFAULT;
+
+   if (copy_to_user(u64_to_user_ptr(query_item->data_ptr +
+offsetof(struct 
drm_i915_query_subslices_info, data)),
+sseu->subslice_mask, data_length))
+   return -EFAULT;
+
+   return 0;
+}
+
+static int query_eus_info(struct drm_i915_private *dev_priv,
+ struct drm_i915_query_item *query_item)
+{
+   const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+   struct drm_i915_query_eus_info eus_info;
+   u32 data_length, length;
+
+   if (sseu->max_slices == 0)
+   return -ENODEV;
+
+   memset(_info, 0, sizeof(eus_info));
+   eus_info.max_slices = sseu->max_slices;
+   eus_info.max_subslices = sseu->max_subslices;
+   eus_info.max_eus_per_subslice = sseu->max_eus_per_subslice;
+
+   data_length = eus_info.max_slices * eus_info.max_subslices *
+   DIV_ROUND_UP(eus_info.max_eus_per_subslice, BITS_PER_BYTE);
+   length = sizeof(eus_info) + data_length;
+
+   if (query_item->length == 0) {
+   query_item->length = length;
+   return 0;
+   

Re: [Intel-gfx] [PATCH 08/27] drm/i915/icl: Ringbuffer interrupt handling

[Daniele Ceraolo Spurio]

On 10/01/18 02:12, Chris Wilson wrote:

Quoting Paulo Zanoni (2018-01-09 23:23:17)

From: Tvrtko Ursulin 

Since it is not possible to mask individual engine instances
and they are all permanently unmasked we do not need to do
anything for engine interrupt management.


This scares me as we will more than double our interrupt generation rate
as we have a breadcrumb interrupt after every request, just in case we
need to synchronize with the request. We've been relying on the ability
to mask those interrupts off, as historically we have been able to
saturate cpus with the amount of interrupts we could generate.
-Chris


We do have masks per instance, but they're in gunit and not in the CS. 
they're defined in patch 4 of this series:


+#define GEN11_RCS0_RSVD_INTR_MASK  _MMIO(0x190090)
+#define GEN11_BCS_RSVD_INTR_MASK   _MMIO(0x1900a0)
+#define GEN11_VCS0_VCS1_INTR_MASK  _MMIO(0x1900a8)
+#define GEN11_VCS2_VCS3_INTR_MASK  _MMIO(0x1900ac)
+#define GEN11_VECS0_VECS1_INTR_MASK_MMIO(0x1900d0)

Each instance gets half of a register for a 16 bits vector. I think 
there was some gotcha with the masks being in gunit but can't remember 
exactly what. Tvrtko, do you remember anything on this?


Thanks,
Daniele


___
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

[Intel-gfx] ✓ Fi.CI.IGT: success for ICP initial support

[Patchwork]

== Series Details ==

Series: ICP initial support
URL   : https://patchwork.freedesktop.org/series/36350/
State : success

== Summary ==

Test kms_atomic_transition:
Subgroup plane-all-modeset-transition-fencing:
dmesg-warn -> PASS   (shard-hsw) fdo#102614 +1
Test gem_tiled_swapping:
Subgroup non-threaded:
pass   -> INCOMPLETE (shard-snb) fdo#104218 +1
Test kms_flip:
Subgroup flip-vs-panning-vs-hang:
dmesg-warn -> PASS   (shard-snb) fdo#103821
Test gem_eio:
Subgroup in-flight:
dmesg-warn -> PASS   (shard-snb) fdo#104058

fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218
fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821
fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058

shard-hswtotal:2643 pass:1497 dwarn:2   dfail:0   fail:6   skip:1137 
time:8871s
shard-snbtotal:2643 pass:1273 dwarn:1   dfail:0   fail:8   skip:1360 
time:7722s
Blacklisted hosts:
shard-apltotal:2691 pass:1664 dwarn:1   dfail:0   fail:23  skip:1001 
time:13133s
shard-kbltotal:2709 pass:1807 dwarn:1   dfail:0   fail:23  skip:877 
time:10316s

== Logs ==

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

Re: [Intel-gfx] [PATCH libdrm] intel: Add more Coffeelake PCI IDs

[Anuj Phogat]

On Thu, Jan 11, 2018 at 10:31 AM, Rodrigo Vivi  wrote:
> On Thu, Jan 11, 2018 at 06:20:53PM +, Anuj Phogat wrote:
>> Rodrigo, Can you push it upstream for me?
>
> I just pushed the libdrm.
>
> Do I also need to push the mesa one?
>
No, I've pushed the mesa patch. Thanks.

> Thanks,
> Rodrigo.
>
>>
>> Thanks
>> Anuj
>>
>> On Wed, Jan 10, 2018 at 4:50 PM, Rodrigo Vivi  wrote:
>> > On Wed, Jan 10, 2018 at 11:51:02PM +, Anuj Phogat wrote:
>> >> Cc: Rodrigo Vivi 
>> >> Cc: Anusha Srivatsa 
>> >> Signed-off-by: Anuj Phogat 
>> >
>> > Reviewed-by: Rodrigo Vivi 
>> >
>> >> ---
>> >>  intel/intel_chipset.h | 30 +++---
>> >>  1 file changed, 23 insertions(+), 7 deletions(-)
>> >>
>> >> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
>> >> index d81b1646..3818e71e 100644
>> >> --- a/intel/intel_chipset.h
>> >> +++ b/intel/intel_chipset.h
>> >> @@ -223,15 +223,23 @@
>> >>
>> >>  #define PCI_CHIP_COFFEELAKE_S_GT1_1 0x3E90
>> >>  #define PCI_CHIP_COFFEELAKE_S_GT1_2 0x3E93
>> >> +#define PCI_CHIP_COFFEELAKE_S_GT1_3 0x3E99
>> >>  #define PCI_CHIP_COFFEELAKE_S_GT2_1 0x3E91
>> >>  #define PCI_CHIP_COFFEELAKE_S_GT2_2 0x3E92
>> >>  #define PCI_CHIP_COFFEELAKE_S_GT2_3 0x3E96
>> >> +#define PCI_CHIP_COFFEELAKE_S_GT2_4 0x3E9A
>> >>  #define PCI_CHIP_COFFEELAKE_H_GT2_1 0x3E9B
>> >>  #define PCI_CHIP_COFFEELAKE_H_GT2_2 0x3E94
>> >> -#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA5
>> >> -#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA6
>> >> -#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA7
>> >> -#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA8
>> >> +#define PCI_CHIP_COFFEELAKE_U_GT1_1 0x3EA1
>> >> +#define PCI_CHIP_COFFEELAKE_U_GT1_2 0x3EA4
>> >> +#define PCI_CHIP_COFFEELAKE_U_GT2_1 0x3EA0
>> >> +#define PCI_CHIP_COFFEELAKE_U_GT2_2 0x3EA3
>> >> +#define PCI_CHIP_COFFEELAKE_U_GT2_3 0x3EA9
>> >> +#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA2
>> >> +#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA5
>> >> +#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA6
>> >> +#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA7
>> >> +#define PCI_CHIP_COFFEELAKE_U_GT3_5 0x3EA8
>> >>
>> >>  #define PCI_CHIP_CANNONLAKE_U_GT2_0  0x5A52
>> >>  #define PCI_CHIP_CANNONLAKE_U_GT2_1  0x5A5A
>> >> @@ -477,17 +485,25 @@
>> >>
>> >>  #define IS_CFL_S(devid) ((devid) == PCI_CHIP_COFFEELAKE_S_GT1_1 
>> >> || \
>> >>   (devid) == PCI_CHIP_COFFEELAKE_S_GT1_2 
>> >> || \
>> >> + (devid) == PCI_CHIP_COFFEELAKE_S_GT1_3 
>> >> || \
>> >>   (devid) == PCI_CHIP_COFFEELAKE_S_GT2_1 
>> >> || \
>> >>   (devid) == PCI_CHIP_COFFEELAKE_S_GT2_2 
>> >> || \
>> >> - (devid) == PCI_CHIP_COFFEELAKE_S_GT2_3)
>> >> + (devid) == PCI_CHIP_COFFEELAKE_S_GT2_3 
>> >> || \
>> >> + (devid) == PCI_CHIP_COFFEELAKE_S_GT2_4)
>> >>
>> >>  #define IS_CFL_H(devid) ((devid) == PCI_CHIP_COFFEELAKE_H_GT2_1 
>> >> || \
>> >>   (devid) == PCI_CHIP_COFFEELAKE_H_GT2_2)
>> >>
>> >> -#define IS_CFL_U(devid) ((devid) == PCI_CHIP_COFFEELAKE_U_GT3_1 
>> >> || \
>> >> +#define IS_CFL_U(devid) ((devid) == PCI_CHIP_COFFEELAKE_U_GT1_1 
>> >> || \
>> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT1_2 
>> >> || \
>> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_1 
>> >> || \
>> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_2 
>> >> || \
>> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_3 
>> >> || \
>> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_1 
>> >> || \
>> >>   (devid) == PCI_CHIP_COFFEELAKE_U_GT3_2 
>> >> || \
>> >>   (devid) == PCI_CHIP_COFFEELAKE_U_GT3_3 
>> >> || \
>> >> - (devid) == PCI_CHIP_COFFEELAKE_U_GT3_4)
>> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_4 
>> >> || \
>> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_5)
>> >>
>> >>  #define IS_COFFEELAKE(devid)   (IS_CFL_S(devid) || \
>> >>   IS_CFL_H(devid) || \
>> >> --
>> >> 2.13.6
>> >>
___
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: expose rcs topology through query uAPI

[Lionel Landwerlin]

On 11/01/18 12:45, Tvrtko Ursulin wrote:


On 18/12/2017 15:35, Lionel Landwerlin wrote:

With the introduction of asymetric slices in CNL, we cannot rely on


asymmetric


Check ;)




the previous SUBSLICE_MASK getparam to tell userspace what subslices
are available. Here we introduce a more detailed way of querying the
Gen's GPU topology that doesn't aggregate numbers.

This is essential for monitoring parts of the GPU with the OA unit,
because counters need to be normalized to the number of
EUs/subslices/slices. The current aggregated numbers like EU_TOTAL do
not gives us sufficient information.

As a bonus we can draw representations of the GPU :

 https://imgur.com/a/vuqpa

Signed-off-by: Lionel Landwerlin 
---
  drivers/gpu/drm/i915/i915_query.c   | 134 


  drivers/gpu/drm/i915/intel_query_info.c |  88 +
  include/uapi/drm/i915_drm.h |  45 +++
  3 files changed, 267 insertions(+)
  create mode 100644 drivers/gpu/drm/i915/intel_query_info.c

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

index 227a28978190..7c0eb09d3aac 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -25,24 +25,158 @@
  #include "i915_drv.h"
  #include 
  +static int query_slices_mask(struct drm_i915_private *dev_priv,
+ struct drm_i915_query_item *query_item)
+{
+    const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+    struct drm_i915_query_slices_mask slices_info;
+    u32 data_length, length;
+
+    if (sseu->max_slices == 0)
+    return -ENODEV;


Do you need to handle this explicitly or just return all zeros? I 
guess I don't know which GPUs have zero slices.


Again, this is < gen8. I rather not care about those and return ENODEV.




+
+    memset(_info, 0, sizeof(slices_info));


Is this needed since a) you will write to the only field just below, 
and b) it won't clear the tail data array anyway?


I don't know.
It's just being careful, this struct lives on the stack and I don't want 
to leak any data to userspace.





+
+    slices_info.n_slices = sseu->max_slices;

Move to after the query_item->length checks.


Done.




+
+    data_length = sizeof(u8);


Size is dependant on number of slices? DIV_ROUND_UP(n_slices, 
BITS_PER_BYTE) ?


Done.




+    length = sizeof(struct drm_i915_query_slices_mask) + data_length;


sizeof(slices_info)


Done.




+
+    /*
+ * If we ever change the internal slice mask data type, we'll 
need to

+ * update this function.
+ */
+    BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask));


Hm a bit weak since it is not only about size but also data 
representation. But I don't have any better ideas.



+
+    if (query_item->length == 0) {
+    query_item->length = length;
+    return 0;
+    }
+
+    if (query_item->length != length)
+    return -EINVAL;
+
+    if (copy_to_user(u64_to_user_ptr(query_item->data_ptr), 
_info,

+ sizeof(slices_info)))
+    return -EFAULT;
+
+    if (copy_to_user(u64_to_user_ptr(query_item->data_ptr +
+ offsetof(struct drm_i915_query_slices_mask, 
data)),

+ >slice_mask, data_length))
+    return -EFAULT;
+
+    return 0;
+}


Some of the above comments also apply to the other two query functions 
below.



+static int query_subslices_mask(struct drm_i915_private *dev_priv,
+    struct drm_i915_query_item *query_item)
+{
+    const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+    struct drm_i915_query_subslices_mask subslices_info;
+    u32 data_length, length;
+
+    if (sseu->max_slices == 0)
+    return -ENODEV;
+
+    memset(_info, 0, sizeof(subslices_info));
+
+    subslices_info.n_slices = sseu->max_slices;
+    subslices_info.slice_stride = ALIGN(sseu->max_subslices, 8) / 8;
+
+    data_length = subslices_info.n_slices * 
subslices_info.slice_stride;
+    length = sizeof(struct drm_i915_query_subslices_mask) + 
data_length;

+
+    if (query_item->length == 0) {
+    query_item->length = length;
+    return 0;
+    }
+
+    if (query_item->length != length)
+    return -EINVAL;
+
+    if (copy_to_user(u64_to_user_ptr(query_item->data_ptr), 
_info,

+ sizeof(subslices_info)))
+    return -EFAULT;
+
+    if (copy_to_user(u64_to_user_ptr(query_item->data_ptr +
+ offsetof(struct drm_i915_query_subslices_mask, 
data)),

+ sseu->subslices_mask, data_length))
+    return -EFAULT;
+
+    return 0;
+}
+
+static int query_eus_mask(struct drm_i915_private *dev_priv,
+  struct drm_i915_query_item *query_item)
+{
+    const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+    struct drm_i915_query_eus_mask eus_info;
+    u32 data_length, length;
+
+    if (sseu->max_slices == 0)
+    return -ENODEV;
+
+    memset(_info, 0, sizeof(eus_info));
+
+    

Re: [Intel-gfx] [PATCH libdrm] intel: Add more Coffeelake PCI IDs

[Rodrigo Vivi]

On Thu, Jan 11, 2018 at 06:20:53PM +, Anuj Phogat wrote:
> Rodrigo, Can you push it upstream for me?

I just pushed the libdrm.

Do I also need to push the mesa one?

Thanks,
Rodrigo.

> 
> Thanks
> Anuj
> 
> On Wed, Jan 10, 2018 at 4:50 PM, Rodrigo Vivi  wrote:
> > On Wed, Jan 10, 2018 at 11:51:02PM +, Anuj Phogat wrote:
> >> Cc: Rodrigo Vivi 
> >> Cc: Anusha Srivatsa 
> >> Signed-off-by: Anuj Phogat 
> >
> > Reviewed-by: Rodrigo Vivi 
> >
> >> ---
> >>  intel/intel_chipset.h | 30 +++---
> >>  1 file changed, 23 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> >> index d81b1646..3818e71e 100644
> >> --- a/intel/intel_chipset.h
> >> +++ b/intel/intel_chipset.h
> >> @@ -223,15 +223,23 @@
> >>
> >>  #define PCI_CHIP_COFFEELAKE_S_GT1_1 0x3E90
> >>  #define PCI_CHIP_COFFEELAKE_S_GT1_2 0x3E93
> >> +#define PCI_CHIP_COFFEELAKE_S_GT1_3 0x3E99
> >>  #define PCI_CHIP_COFFEELAKE_S_GT2_1 0x3E91
> >>  #define PCI_CHIP_COFFEELAKE_S_GT2_2 0x3E92
> >>  #define PCI_CHIP_COFFEELAKE_S_GT2_3 0x3E96
> >> +#define PCI_CHIP_COFFEELAKE_S_GT2_4 0x3E9A
> >>  #define PCI_CHIP_COFFEELAKE_H_GT2_1 0x3E9B
> >>  #define PCI_CHIP_COFFEELAKE_H_GT2_2 0x3E94
> >> -#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA5
> >> -#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA6
> >> -#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA7
> >> -#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA8
> >> +#define PCI_CHIP_COFFEELAKE_U_GT1_1 0x3EA1
> >> +#define PCI_CHIP_COFFEELAKE_U_GT1_2 0x3EA4
> >> +#define PCI_CHIP_COFFEELAKE_U_GT2_1 0x3EA0
> >> +#define PCI_CHIP_COFFEELAKE_U_GT2_2 0x3EA3
> >> +#define PCI_CHIP_COFFEELAKE_U_GT2_3 0x3EA9
> >> +#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA2
> >> +#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA5
> >> +#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA6
> >> +#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA7
> >> +#define PCI_CHIP_COFFEELAKE_U_GT3_5 0x3EA8
> >>
> >>  #define PCI_CHIP_CANNONLAKE_U_GT2_0  0x5A52
> >>  #define PCI_CHIP_CANNONLAKE_U_GT2_1  0x5A5A
> >> @@ -477,17 +485,25 @@
> >>
> >>  #define IS_CFL_S(devid) ((devid) == PCI_CHIP_COFFEELAKE_S_GT1_1 
> >> || \
> >>   (devid) == PCI_CHIP_COFFEELAKE_S_GT1_2 
> >> || \
> >> + (devid) == PCI_CHIP_COFFEELAKE_S_GT1_3 
> >> || \
> >>   (devid) == PCI_CHIP_COFFEELAKE_S_GT2_1 
> >> || \
> >>   (devid) == PCI_CHIP_COFFEELAKE_S_GT2_2 
> >> || \
> >> - (devid) == PCI_CHIP_COFFEELAKE_S_GT2_3)
> >> + (devid) == PCI_CHIP_COFFEELAKE_S_GT2_3 
> >> || \
> >> + (devid) == PCI_CHIP_COFFEELAKE_S_GT2_4)
> >>
> >>  #define IS_CFL_H(devid) ((devid) == PCI_CHIP_COFFEELAKE_H_GT2_1 
> >> || \
> >>   (devid) == PCI_CHIP_COFFEELAKE_H_GT2_2)
> >>
> >> -#define IS_CFL_U(devid) ((devid) == PCI_CHIP_COFFEELAKE_U_GT3_1 
> >> || \
> >> +#define IS_CFL_U(devid) ((devid) == PCI_CHIP_COFFEELAKE_U_GT1_1 
> >> || \
> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT1_2 
> >> || \
> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_1 
> >> || \
> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_2 
> >> || \
> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_3 
> >> || \
> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_1 
> >> || \
> >>   (devid) == PCI_CHIP_COFFEELAKE_U_GT3_2 
> >> || \
> >>   (devid) == PCI_CHIP_COFFEELAKE_U_GT3_3 
> >> || \
> >> - (devid) == PCI_CHIP_COFFEELAKE_U_GT3_4)
> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_4 
> >> || \
> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_5)
> >>
> >>  #define IS_COFFEELAKE(devid)   (IS_CFL_S(devid) || \
> >>   IS_CFL_H(devid) || \
> >> --
> >> 2.13.6
> >>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915/icl: Update subslice define for ICL 11

[Oscar Mateo]

From: Kelvin Gardiner 

ICL 11 has a greater number of maximum subslices. This patch
reflects this.

v2: GEN11 updates to MCR_SELECTOR (Oscar)

Bspec: 21139
BSpec: 21108

Reviewed-by: Daniele Ceraolo Spurio  (v1)
Signed-off-by: Kelvin Gardiner 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/i915_reg.h |  4 
 drivers/gpu/drm/i915/intel_engine_cs.c  | 22 ++
 drivers/gpu/drm/i915/intel_ringbuffer.h |  2 +-
 3 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c9b6250..c79ca5b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2444,6 +2444,10 @@ enum i915_power_well_id {
 #define   GEN8_MCR_SLICE_MASK  GEN8_MCR_SLICE(3)
 #define   GEN8_MCR_SUBSLICE(subslice)  (((subslice) & 3) << 24)
 #define   GEN8_MCR_SUBSLICE_MASK   GEN8_MCR_SUBSLICE(3)
+#define   GEN11_MCR_SLICE(slice)   (((slice) & 0xf) << 27)
+#define   GEN11_MCR_SLICE_MASK GEN8_MCR_SLICE(0xf)
+#define   GEN11_MCR_SUBSLICE(subslice) (((subslice) & 0x7) << 24)
+#define   GEN11_MCR_SUBSLICE_MASK  GEN8_MCR_SUBSLICE(0x7)
 #define RING_IPEIR(base)   _MMIO((base)+0x64)
 #define RING_IPEHR(base)   _MMIO((base)+0x68)
 /*
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a373bcb..8c0da94 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -775,10 +775,24 @@ const char *i915_cache_level_str(struct drm_i915_private 
*i915, int type)
 read_subslice_reg(struct drm_i915_private *dev_priv, int slice,
  int subslice, i915_reg_t reg)
 {
+   uint32_t mcr_slice_subslice_mask;
+   uint32_t mcr_slice_subslice_select;
uint32_t mcr;
uint32_t ret;
enum forcewake_domains fw_domains;
 
+   if (INTEL_GEN(dev_priv) >= 11) {
+   mcr_slice_subslice_mask = GEN11_MCR_SLICE_MASK |
+ GEN11_MCR_SUBSLICE_MASK;
+   mcr_slice_subslice_select = GEN11_MCR_SLICE(slice) |
+   GEN11_MCR_SUBSLICE(subslice);
+   } else {
+   mcr_slice_subslice_mask = GEN8_MCR_SLICE_MASK |
+ GEN8_MCR_SUBSLICE_MASK;
+   mcr_slice_subslice_select = GEN8_MCR_SLICE(slice) |
+   GEN8_MCR_SUBSLICE(subslice);
+   }
+
fw_domains = intel_uncore_forcewake_for_reg(dev_priv, reg,
FW_REG_READ);
fw_domains |= intel_uncore_forcewake_for_reg(dev_priv,
@@ -793,14 +807,14 @@ const char *i915_cache_level_str(struct drm_i915_private 
*i915, int type)
 * The HW expects the slice and sublice selectors to be reset to 0
 * after reading out the registers.
 */
-   WARN_ON_ONCE(mcr & (GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK));
-   mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
-   mcr |= GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice);
+   WARN_ON_ONCE(mcr & mcr_slice_subslice_mask);
+   mcr &= ~mcr_slice_subslice_mask;
+   mcr |= mcr_slice_subslice_select;
I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
 
ret = I915_READ_FW(reg);
 
-   mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK);
+   mcr &= ~mcr_slice_subslice_mask;
I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr);
 
intel_uncore_forcewake_put__locked(dev_priv, fw_domains);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 2a88231..029093a 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -82,7 +82,7 @@ enum intel_engine_hangcheck_action {
 }
 
 #define I915_MAX_SLICES3
-#define I915_MAX_SUBSLICES 3
+#define I915_MAX_SUBSLICES 8
 
 #define instdone_slice_mask(dev_priv__) \
(INTEL_GEN(dev_priv__) == 7 ? \
-- 
1.9.1

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

[Intel-gfx] ✓ Fi.CI.BAT: success for ICP initial support

[Patchwork]

== Series Details ==

Series: ICP initial support
URL   : https://patchwork.freedesktop.org/series/36350/
State : success

== Summary ==

Series 36350v1 ICP initial support
https://patchwork.freedesktop.org/api/1.0/series/36350/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
fail   -> PASS   (fi-elk-e7500) fdo#103989
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:419s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:491s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:481s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:466s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:452s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:271s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:513s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:390s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:401s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:460s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:467s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:499s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:451s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:503s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:581s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:429s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:532s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:494s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:480s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:432s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:530s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:395s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:568s
fi-glk-dsi   total:288  pass:257  dwarn:0   dfail:0   fail:1   skip:30  
time:487s
fi-cnl-y2 failed to collect. IGT log at Patchwork_7652/fi-cnl-y2/igt.log

dbc7615897f6cbe121a316b4209b278407cb2eb4 drm-tip: 2018y-01m-11d-16h-49m-38s UTC 
integration manifest
2fe9e815bb0b drm/i915/icp: Add the ID for ICL PCH - ICP
a44a57cf52df drm/i915/icp: add ICP gmbus and gpio support
5c79b9a3856e drm/i915/icp: Add backlight Support for ICP
8dd9bdee33e6 drm/i915/icp: Add Panel Power Sequencing Support
4b221f1e5a65 drm/i915/icp: Get/set proper Raw clock frequency on ICP
05c7311d391a drm/i915/icp: Introduce Ice Lake PCH
09ae110fc4bb drm/i915/icl: Add initial Icelake definitions.
71e6a3f6aa93 drm/i915/cnl: Add Port F definition.

== Logs ==

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

[Intel-gfx] [PATCH v3] drm/i915/icl: Gen11 render context size

[Oscar Mateo]

From: Tvrtko Ursulin 

Gen11 removes the Resource Streamer, which frees up a big chunk of
the context image. BSpec indicates 12538 DWORDs (13 pages), plus
one page for PPHWSP.

Please notice that, when looking at the BSpec context image table,
the right filter has to be applied (e.g. "IcelakeLP") as some rows
are excluded for specific GENs. Also, some rows apply per-subslice
(for the calculation above, we have supposed 8 subslices which is
the maximum SKU we expect).

v2: Rebase.
v3: Use the right size as per the BSpec.

BSpec: 18907

Acked-by: Ben Widawsky 
Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index e88b2fd..79b7d36 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -41,6 +41,7 @@
 #define GEN8_LR_CONTEXT_RENDER_SIZE(20 * PAGE_SIZE)
 #define GEN9_LR_CONTEXT_RENDER_SIZE(22 * PAGE_SIZE)
 #define GEN10_LR_CONTEXT_RENDER_SIZE   (18 * PAGE_SIZE)
+#define GEN11_LR_CONTEXT_RENDER_SIZE   (14 * PAGE_SIZE)
 
 #define GEN8_LR_CONTEXT_OTHER_SIZE ( 2 * PAGE_SIZE)
 
@@ -181,6 +182,8 @@ struct engine_info {
switch (INTEL_GEN(dev_priv)) {
default:
MISSING_CASE(INTEL_GEN(dev_priv));
+   case 11:
+   return GEN11_LR_CONTEXT_RENDER_SIZE;
case 10:
return GEN10_LR_CONTEXT_RENDER_SIZE;
case 9:
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH libdrm] intel: Add more Coffeelake PCI IDs

[Anuj Phogat]

Rodrigo, Can you push it upstream for me?

Thanks
Anuj

On Wed, Jan 10, 2018 at 4:50 PM, Rodrigo Vivi  wrote:
> On Wed, Jan 10, 2018 at 11:51:02PM +, Anuj Phogat wrote:
>> Cc: Rodrigo Vivi 
>> Cc: Anusha Srivatsa 
>> Signed-off-by: Anuj Phogat 
>
> Reviewed-by: Rodrigo Vivi 
>
>> ---
>>  intel/intel_chipset.h | 30 +++---
>>  1 file changed, 23 insertions(+), 7 deletions(-)
>>
>> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
>> index d81b1646..3818e71e 100644
>> --- a/intel/intel_chipset.h
>> +++ b/intel/intel_chipset.h
>> @@ -223,15 +223,23 @@
>>
>>  #define PCI_CHIP_COFFEELAKE_S_GT1_1 0x3E90
>>  #define PCI_CHIP_COFFEELAKE_S_GT1_2 0x3E93
>> +#define PCI_CHIP_COFFEELAKE_S_GT1_3 0x3E99
>>  #define PCI_CHIP_COFFEELAKE_S_GT2_1 0x3E91
>>  #define PCI_CHIP_COFFEELAKE_S_GT2_2 0x3E92
>>  #define PCI_CHIP_COFFEELAKE_S_GT2_3 0x3E96
>> +#define PCI_CHIP_COFFEELAKE_S_GT2_4 0x3E9A
>>  #define PCI_CHIP_COFFEELAKE_H_GT2_1 0x3E9B
>>  #define PCI_CHIP_COFFEELAKE_H_GT2_2 0x3E94
>> -#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA5
>> -#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA6
>> -#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA7
>> -#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA8
>> +#define PCI_CHIP_COFFEELAKE_U_GT1_1 0x3EA1
>> +#define PCI_CHIP_COFFEELAKE_U_GT1_2 0x3EA4
>> +#define PCI_CHIP_COFFEELAKE_U_GT2_1 0x3EA0
>> +#define PCI_CHIP_COFFEELAKE_U_GT2_2 0x3EA3
>> +#define PCI_CHIP_COFFEELAKE_U_GT2_3 0x3EA9
>> +#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA2
>> +#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA5
>> +#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA6
>> +#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA7
>> +#define PCI_CHIP_COFFEELAKE_U_GT3_5 0x3EA8
>>
>>  #define PCI_CHIP_CANNONLAKE_U_GT2_0  0x5A52
>>  #define PCI_CHIP_CANNONLAKE_U_GT2_1  0x5A5A
>> @@ -477,17 +485,25 @@
>>
>>  #define IS_CFL_S(devid) ((devid) == PCI_CHIP_COFFEELAKE_S_GT1_1 || \
>>   (devid) == PCI_CHIP_COFFEELAKE_S_GT1_2 || \
>> + (devid) == PCI_CHIP_COFFEELAKE_S_GT1_3 || \
>>   (devid) == PCI_CHIP_COFFEELAKE_S_GT2_1 || \
>>   (devid) == PCI_CHIP_COFFEELAKE_S_GT2_2 || \
>> - (devid) == PCI_CHIP_COFFEELAKE_S_GT2_3)
>> + (devid) == PCI_CHIP_COFFEELAKE_S_GT2_3 || \
>> + (devid) == PCI_CHIP_COFFEELAKE_S_GT2_4)
>>
>>  #define IS_CFL_H(devid) ((devid) == PCI_CHIP_COFFEELAKE_H_GT2_1 || \
>>   (devid) == PCI_CHIP_COFFEELAKE_H_GT2_2)
>>
>> -#define IS_CFL_U(devid) ((devid) == PCI_CHIP_COFFEELAKE_U_GT3_1 || \
>> +#define IS_CFL_U(devid) ((devid) == PCI_CHIP_COFFEELAKE_U_GT1_1 || \
>> + (devid) == PCI_CHIP_COFFEELAKE_U_GT1_2 || \
>> + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_1 || \
>> + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_2 || \
>> + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_3 || \
>> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_1 || \
>>   (devid) == PCI_CHIP_COFFEELAKE_U_GT3_2 || \
>>   (devid) == PCI_CHIP_COFFEELAKE_U_GT3_3 || \
>> - (devid) == PCI_CHIP_COFFEELAKE_U_GT3_4)
>> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_4 || \
>> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_5)
>>
>>  #define IS_COFFEELAKE(devid)   (IS_CFL_S(devid) || \
>>   IS_CFL_H(devid) || \
>> --
>> 2.13.6
>>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 11/27] drm/i915/icl: Gen11 render context size

[Oscar Mateo]

On 01/10/2018 05:21 PM, Rodrigo Vivi wrote:

On Tue, Jan 09, 2018 at 11:28:19PM +, Paulo Zanoni wrote:

From: Tvrtko Ursulin 

The current size may be bigger than the correct one, this needs to be
revisited later.

I don't believe this is true anymore. When this was written initially CNL had a 
higher value.

Higher values are ok, but smaller can be problematic if I understood correctly.

So we might need to check the accurate number.

Oscar has a good method for that if iirc ;)


My method says 14 pages. Seems a bit low, so I went ahead and tested it. 
Everything seems to work fine, so I'll send a new patch.



v2: Rebase.

Acked-by: Ben Widawsky 
Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Rodrigo Vivi 
---
  drivers/gpu/drm/i915/intel_engine_cs.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index e88b2fd44724..a373bcbd85d8 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -181,6 +181,8 @@ __intel_engine_context_size(struct drm_i915_private 
*dev_priv, u8 class)
switch (INTEL_GEN(dev_priv)) {
default:
MISSING_CASE(INTEL_GEN(dev_priv));
+   case 11:
+   /* TODO: Make sure this is correct. */
case 10:
return GEN10_LR_CONTEXT_RENDER_SIZE;
case 9:
--
2.14.3



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

[Intel-gfx] [PATCH 4/8] drm/i915/icp: Get/set proper Raw clock frequency on ICP

[Paulo Zanoni]

From: Anusha Srivatsa 

Add register definitions for setting the rawclock.
Set the numerator,denominator and divider values.

v2: Simplify the commit message. Simplify the math.
Add  register bits for numerator. (Paulo)
v3 (from Paulo): coding style bikesheds.

Reviewed-by: Paulo Zanoni 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_reg.h|  2 ++
 drivers/gpu/drm/i915/intel_cdclk.c | 29 +++--
 2 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c0a4fc356145..f756512041c6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7352,6 +7352,8 @@ enum {
 #define  CNP_RAWCLK_DIV(div)   ((div) << 16)
 #define  CNP_RAWCLK_FRAC_MASK  (0xf << 26)
 #define  CNP_RAWCLK_FRAC(frac) ((frac) << 26)
+#define  ICP_RAWCLK_DEN(den)   ((den) << 26)
+#define  ICP_RAWCLK_NUM(num)   ((num) << 11)
 
 #define PCH_DPLL_TMR_CFG_MMIO(0xc6208)
 
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index ca36321eafac..4f921fd331fd 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -2342,6 +2342,30 @@ static int cnp_rawclk(struct drm_i915_private *dev_priv)
return divider + fraction;
 }
 
+static int icp_rawclk(struct drm_i915_private *dev_priv)
+{
+   u32 rawclk;
+   int divider, numerator, denominator, frequency;
+
+   if (I915_READ(SFUSE_STRAP) & SFUSE_STRAP_RAW_FREQUENCY) {
+   frequency = 24000;
+   divider = 23;
+   numerator = 0;
+   denominator = 0;
+   } else {
+   frequency = 19200;
+   divider = 18;
+   numerator = 1;
+   denominator = 4;
+   }
+
+   rawclk = CNP_RAWCLK_DIV(divider) | ICP_RAWCLK_NUM(numerator) |
+ICP_RAWCLK_DEN(denominator);
+
+   I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
+   return frequency;
+}
+
 static int pch_rawclk(struct drm_i915_private *dev_priv)
 {
return (I915_READ(PCH_RAWCLK_FREQ) & RAWCLK_FREQ_MASK) * 1000;
@@ -2389,8 +2413,9 @@ static int g4x_hrawclk(struct drm_i915_private *dev_priv)
  */
 void intel_update_rawclk(struct drm_i915_private *dev_priv)
 {
-
-   if (HAS_PCH_CNP(dev_priv))
+   if (HAS_PCH_ICP(dev_priv))
+   dev_priv->rawclk_freq = icp_rawclk(dev_priv);
+   else if (HAS_PCH_CNP(dev_priv))
dev_priv->rawclk_freq = cnp_rawclk(dev_priv);
else if (HAS_PCH_SPLIT(dev_priv))
dev_priv->rawclk_freq = pch_rawclk(dev_priv);
-- 
2.14.3

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

[Intel-gfx] [PATCH 5/8] drm/i915/icp: Add Panel Power Sequencing Support

[Paulo Zanoni]

From: Anusha Srivatsa 

ICP, like BXT, has has two panel power sequencers.

v2: Simplify the code. Remove unwanted register definitions.
Make code as close to BXT style as possible. (Ville)
Also, remove the use of ICP_SECOND_PPS_BACKLIGHT for now.
Moving forward, if we are sure we need to set this register,
we can access it.

v3: Use INTEL_GEN(dev_priv), make code more readeable. (Ville)

v4 (from Paulo):
 - Coding style fixes.
 - Add a missing HAS_PCH_CNP -> gen10+ check.
 - Rebase.

v5: Use per platform checks rather than INTEL_GEN().
v4 of this patch breaks on CoffeeLake, since CFL uses
CNP and per platform check makes sense in that case.

v6 (from Paulo):
 - v5 was a patch on top of v4, not a new version. Now v6 is correctly
   a new version of the original patch.

Cc: Ville Syrjala 
Reviewed-by: Paulo Zanoni 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_dp.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 46937a8c48cc..cdfdacf27939 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -796,7 +796,8 @@ static void intel_pps_get_registers(struct intel_dp 
*intel_dp,
regs->pp_stat = PP_STATUS(pps_idx);
regs->pp_on = PP_ON_DELAYS(pps_idx);
regs->pp_off = PP_OFF_DELAYS(pps_idx);
-   if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv))
+   if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv) &&
+   !HAS_PCH_ICP(dev_priv))
regs->pp_div = PP_DIVISOR(pps_idx);
 }
 
@@ -5453,7 +5454,8 @@ intel_pps_readout_hw_state(struct intel_dp *intel_dp, 
struct edp_power_seq *seq)
 
pp_on = I915_READ(regs.pp_on);
pp_off = I915_READ(regs.pp_off);
-   if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv)) {
+   if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv) &&
+   !HAS_PCH_ICP(dev_priv)) {
I915_WRITE(regs.pp_ctrl, pp_ctl);
pp_div = I915_READ(regs.pp_div);
}
@@ -5471,7 +5473,8 @@ intel_pps_readout_hw_state(struct intel_dp *intel_dp, 
struct edp_power_seq *seq)
seq->t10 = (pp_off & PANEL_POWER_DOWN_DELAY_MASK) >>
   PANEL_POWER_DOWN_DELAY_SHIFT;
 
-   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv) ||
+   HAS_PCH_ICP(dev_priv)) {
seq->t11_t12 = ((pp_ctl & BXT_POWER_CYCLE_DELAY_MASK) >>
BXT_POWER_CYCLE_DELAY_SHIFT) * 1000;
} else {
@@ -5642,7 +5645,8 @@ intel_dp_init_panel_power_sequencer_registers(struct 
intel_dp *intel_dp,
 (seq->t10 << PANEL_POWER_DOWN_DELAY_SHIFT);
/* Compute the divisor for the pp clock, simply match the Bspec
 * formula. */
-   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv) ||
+   HAS_PCH_ICP(dev_priv)) {
pp_div = I915_READ(regs.pp_ctrl);
pp_div &= ~BXT_POWER_CYCLE_DELAY_MASK;
pp_div |= (DIV_ROUND_UP(seq->t11_t12, 1000)
@@ -5668,7 +5672,8 @@ intel_dp_init_panel_power_sequencer_registers(struct 
intel_dp *intel_dp,
 
I915_WRITE(regs.pp_on, pp_on);
I915_WRITE(regs.pp_off, pp_off);
-   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv) ||
+   HAS_PCH_ICP(dev_priv))
I915_WRITE(regs.pp_ctrl, pp_div);
else
I915_WRITE(regs.pp_div, pp_div);
@@ -5676,7 +5681,8 @@ intel_dp_init_panel_power_sequencer_registers(struct 
intel_dp *intel_dp,
DRM_DEBUG_KMS("panel power sequencer register settings: PP_ON %#x, 
PP_OFF %#x, PP_DIV %#x\n",
  I915_READ(regs.pp_on),
  I915_READ(regs.pp_off),
- (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) ?
+ (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)  ||
+  HAS_PCH_ICP(dev_priv)) ?
  (I915_READ(regs.pp_ctrl) & BXT_POWER_CYCLE_DELAY_MASK) :
  I915_READ(regs.pp_div));
 }
-- 
2.14.3

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

[Intel-gfx] [PATCH 7/8] drm/i915/icp: add ICP gmbus and gpio support

[Paulo Zanoni]

From: Anusha Srivatsa 

In ICP, there are three TC ports and 3 DDI ports.

v2:
 - Correct Pin mapping.
v3:
 - Update pin mapping into per platform implementation
   rather than previous approach of port wise mapping.
v4:
 - Update GMBUS_NUM_PINS (Paulo)
v5:
 - rebase.
v6:
 - Update function name, GMBUS_PIN_NUM (Paulo)
v7 (from Paulo):
 - Make it apply.
v8 (from Paulo):
 - Maintain consistent if ladder ordering.

Suggested by: Ville Syrjala 
Cc: Jani Nikula 
Reviewed-by: Paulo Zanoni 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_reg.h   |  7 ++-
 drivers/gpu/drm/i915/intel_hdmi.c | 33 +
 drivers/gpu/drm/i915/intel_i2c.c  | 17 +++--
 3 files changed, 54 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f756512041c6..698e1649f287 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3064,7 +3064,12 @@ enum i915_power_well_id {
 #define   GMBUS_PIN_2_BXT  2
 #define   GMBUS_PIN_3_BXT  3
 #define   GMBUS_PIN_4_CNP  4
-#define   GMBUS_NUM_PINS   7 /* including 0 */
+#define   GMBUS_PIN_9_TC1_ICP  9
+#define   GMBUS_PIN_10_TC2_ICP 10
+#define   GMBUS_PIN_11_TC3_ICP 11
+#define   GMBUS_PIN_12_TC4_ICP 12
+
+#define   GMBUS_NUM_PINS   13 /* including 0 */
 #define GMBUS1 _MMIO(dev_priv->gpio_mmio_base + 0x5104) /* 
command/status */
 #define   GMBUS_SW_CLR_INT (1<<31)
 #define   GMBUS_SW_RDY (1<<30)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 691f15b59124..d3212afe1eba 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2183,6 +2183,37 @@ static u8 cnp_port_to_ddc_pin(struct drm_i915_private 
*dev_priv,
return ddc_pin;
 }
 
+static u8 icl_port_to_ddc_pin(struct drm_i915_private *dev_priv, enum port 
port)
+{
+   u8 ddc_pin;
+
+   switch (port) {
+   case PORT_A:
+   ddc_pin = GMBUS_PIN_1_BXT;
+   break;
+   case PORT_B:
+   ddc_pin = GMBUS_PIN_2_BXT;
+   break;
+   case PORT_C:
+   ddc_pin = GMBUS_PIN_9_TC1_ICP;
+   break;
+   case PORT_D:
+   ddc_pin = GMBUS_PIN_10_TC2_ICP;
+   break;
+   case PORT_E:
+   ddc_pin = GMBUS_PIN_11_TC3_ICP;
+   break;
+   case PORT_F:
+   ddc_pin = GMBUS_PIN_12_TC4_ICP;
+   break;
+   default:
+   MISSING_CASE(port);
+   ddc_pin = GMBUS_PIN_2_BXT;
+   break;
+   }
+   return ddc_pin;
+}
+
 static u8 g4x_port_to_ddc_pin(struct drm_i915_private *dev_priv,
  enum port port)
 {
@@ -2225,6 +2256,8 @@ static u8 intel_hdmi_ddc_pin(struct drm_i915_private 
*dev_priv,
ddc_pin = bxt_port_to_ddc_pin(dev_priv, port);
else if (HAS_PCH_CNP(dev_priv))
ddc_pin = cnp_port_to_ddc_pin(dev_priv, port);
+   else if (IS_ICELAKE(dev_priv))
+   ddc_pin = icl_port_to_ddc_pin(dev_priv, port);
else
ddc_pin = g4x_port_to_ddc_pin(dev_priv, port);
 
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 6f7ef4e225ee..e6875509bcd9 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -76,11 +76,22 @@ static const struct gmbus_pin gmbus_pins_cnp[] = {
[GMBUS_PIN_4_CNP] = { "dpd", GPIOE },
 };
 
+static const struct gmbus_pin gmbus_pins_icp[] = {
+   [GMBUS_PIN_1_BXT] = { "dpa", GPIOA },
+   [GMBUS_PIN_2_BXT] = { "dpb", GPIOB },
+   [GMBUS_PIN_9_TC1_ICP] = { "tc1", GPIOC },
+   [GMBUS_PIN_10_TC2_ICP] = { "tc2", GPIOD },
+   [GMBUS_PIN_11_TC3_ICP] = { "tc3", GPIOE },
+   [GMBUS_PIN_12_TC4_ICP] = { "tc4", GPIOF },
+};
+
 /* pin is expected to be valid */
 static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private *dev_priv,
 unsigned int pin)
 {
-   if (HAS_PCH_CNP(dev_priv))
+   if (HAS_PCH_ICP(dev_priv))
+   return _pins_icp[pin];
+   else if (HAS_PCH_CNP(dev_priv))
return _pins_cnp[pin];
else if (IS_GEN9_LP(dev_priv))
return _pins_bxt[pin];
@@ -97,7 +108,9 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private 
*dev_priv,
 {
unsigned int size;
 
-   if (HAS_PCH_CNP(dev_priv))
+   if (HAS_PCH_ICP(dev_priv))
+   size = ARRAY_SIZE(gmbus_pins_icp);
+   else if (HAS_PCH_CNP(dev_priv))
size = ARRAY_SIZE(gmbus_pins_cnp);
else if (IS_GEN9_LP(dev_priv))
size = ARRAY_SIZE(gmbus_pins_bxt);
-- 
2.14.3

[Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for ICP

[Paulo Zanoni]

From: Anusha Srivatsa 

ICP has two backlight controllers - similar to previous platforms like
BXT.

v2: Remove the usage of ICP_SECOND_PPS_BACKLIGHT register.(Jani)
Reuse BXT code since it is very similar.(Ville)

v3 (from Paulo): Rebase.

Cc: Jani Nikula 
Cc: Ville Syrjala 
Reviewed-by: Paulo Zanoni 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_panel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index fa6831f8c004..ad80cca8c110 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -1865,7 +1865,7 @@ intel_panel_init_backlight_funcs(struct intel_panel 
*panel)
panel->backlight.set = bxt_set_backlight;
panel->backlight.get = bxt_get_backlight;
panel->backlight.hz_to_pwm = bxt_hz_to_pwm;
-   } else if (HAS_PCH_CNP(dev_priv)) {
+   } else if (HAS_PCH_CNP(dev_priv) || HAS_PCH_ICP(dev_priv)) {
panel->backlight.setup = cnp_setup_backlight;
panel->backlight.enable = cnp_enable_backlight;
panel->backlight.disable = cnp_disable_backlight;
-- 
2.14.3

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

[Intel-gfx] [PATCH 8/8] drm/i915/icp: Add the ID for ICL PCH - ICP

[Paulo Zanoni]

From: Anusha Srivatsa 

Add the PCI ID for the ICL PCH - ICP.

v2: rebased.
v3: rebased.
v4: fix ICP name.
v5: fix the ID mask (Fei Li).
v6 (from Paulo): bikesheds.

Cc: Li, Fei 
Reviewed-by: Paulo Zanoni 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.c | 4 
 drivers/gpu/drm/i915/i915_drv.h | 1 +
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6c8da9d20c33..95071a1e875b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -252,6 +252,10 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
DRM_DEBUG_KMS("Found Cannon Lake LP PCH 
(CNP-LP)\n");
WARN_ON(!IS_CANNONLAKE(dev_priv) &&
!IS_COFFEELAKE(dev_priv));
+   } else if (id == INTEL_PCH_ICP_DEVICE_ID_TYPE) {
+   dev_priv->pch_type = PCH_ICP;
+   DRM_DEBUG_KMS("Found Ice Lake PCH\n");
+   WARN_ON(!IS_ICELAKE(dev_priv));
} else if (id == INTEL_PCH_P2X_DEVICE_ID_TYPE ||
   id == INTEL_PCH_P3X_DEVICE_ID_TYPE ||
   (id == INTEL_PCH_QEMU_DEVICE_ID_TYPE &&
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 482517af58f6..e0c6f1f4bafd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2846,6 +2846,7 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define INTEL_PCH_KBP_DEVICE_ID_TYPE   0xA280
 #define INTEL_PCH_CNP_DEVICE_ID_TYPE   0xA300
 #define INTEL_PCH_CNP_LP_DEVICE_ID_TYPE0x9D80
+#define INTEL_PCH_ICP_DEVICE_ID_TYPE   0x3480
 #define INTEL_PCH_P2X_DEVICE_ID_TYPE   0x7100
 #define INTEL_PCH_P3X_DEVICE_ID_TYPE   0x7000
 #define INTEL_PCH_QEMU_DEVICE_ID_TYPE  0x2900 /* qemu q35 has 2918 */
-- 
2.14.3

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

[Intel-gfx] [PATCH 1/8] drm/i915/cnl: Add Port F definition.

[Paulo Zanoni]

From: Rodrigo Vivi 

Some Cannonlake SKUs will come with a full split between
port A and port E. This will be called port F although it
is not a 6th port, but only a split.

Note this patch alone is not sufficient for port F enabling,
it's just the first step.

v2: Fix size of dvo_ports found by Ander.
v3: Adding missing cases from intel_bios.c for Port_F
v4: Adding other missing cases and fix the commit message.
v5: Rebase on top of display headers rework.
v6 (from Paulo): improve commit message, bikeshed bit definitions.

Cc: Lucas De Marchi 
Cc: Manasi Navare 
Reviewed-by: Paulo Zanoni 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_bios.c | 9 +
 drivers/gpu/drm/i915/intel_display.h  | 1 +
 drivers/gpu/drm/i915/intel_dp.c   | 2 ++
 drivers/gpu/drm/i915/intel_vbt_defs.h | 2 ++
 include/drm/i915_component.h  | 3 +--
 5 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 51108ffc28d1..59a150e2adce 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1140,6 +1140,7 @@ static void parse_ddi_port(struct drm_i915_private 
*dev_priv, enum port port,
{DVO_PORT_HDMIC, DVO_PORT_DPC, -1},
{DVO_PORT_HDMID, DVO_PORT_DPD, -1},
{DVO_PORT_CRT, DVO_PORT_HDMIE, DVO_PORT_DPE},
+   {DVO_PORT_HDMIF, DVO_PORT_DPF, -1},
};
 
/*
@@ -1688,6 +1689,7 @@ bool intel_bios_is_port_present(struct drm_i915_private 
*dev_priv, enum port por
[PORT_C] = { DVO_PORT_DPC, DVO_PORT_HDMIC, },
[PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, },
[PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, },
+   [PORT_F] = { DVO_PORT_DPF, DVO_PORT_HDMIF, },
};
int i;
 
@@ -1726,6 +1728,7 @@ bool intel_bios_is_port_edp(struct drm_i915_private 
*dev_priv, enum port port)
[PORT_C] = DVO_PORT_DPC,
[PORT_D] = DVO_PORT_DPD,
[PORT_E] = DVO_PORT_DPE,
+   [PORT_F] = DVO_PORT_DPF,
};
int i;
 
@@ -1761,6 +1764,7 @@ static bool child_dev_is_dp_dual_mode(const struct 
child_device_config *child,
[PORT_C] = { DVO_PORT_DPC, DVO_PORT_HDMIC, },
[PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, },
[PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, },
+   [PORT_F] = { DVO_PORT_DPF, DVO_PORT_HDMIF, },
};
 
if (port == PORT_A || port >= ARRAY_SIZE(port_mapping))
@@ -1927,6 +1931,11 @@ intel_bios_is_lspcon_present(struct drm_i915_private 
*dev_priv,
if (port == PORT_D)
return true;
break;
+   case DVO_PORT_DPF:
+   case DVO_PORT_HDMIF:
+   if (port == PORT_F)
+   return true;
+   break;
default:
break;
}
diff --git a/drivers/gpu/drm/i915/intel_display.h 
b/drivers/gpu/drm/i915/intel_display.h
index a0d2b6169361..e47638931b51 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -119,6 +119,7 @@ enum port {
PORT_C,
PORT_D,
PORT_E,
+   PORT_F,
 
I915_MAX_PORTS
 };
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 68229f53d5b8..46937a8c48cc 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1402,6 +1402,7 @@ static i915_reg_t skl_aux_ctl_reg(struct drm_i915_private 
*dev_priv,
case PORT_B:
case PORT_C:
case PORT_D:
+   case PORT_F:
return DP_AUX_CH_CTL(port);
default:
MISSING_CASE(port);
@@ -1417,6 +1418,7 @@ static i915_reg_t skl_aux_data_reg(struct 
drm_i915_private *dev_priv,
case PORT_B:
case PORT_C:
case PORT_D:
+   case PORT_F:
return DP_AUX_CH_DATA(port, index);
default:
MISSING_CASE(port);
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h 
b/drivers/gpu/drm/i915/intel_vbt_defs.h
index e3d7745a9151..b5d2341f932c 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -299,6 +299,8 @@ struct bdb_general_features {
 #define DVO_PORT_DPA   10
 #define DVO_PORT_DPE   11  /* 193 */
 #define DVO_PORT_HDMIE 12  /* 193 */
+#define DVO_PORT_DPF   13  /* N/A */
+#define DVO_PORT_HDMIF 14  /* N/A */
 #define DVO_PORT_MIPIA 21  /* 171 */
 #define 

[Intel-gfx] [PATCH 3/8] drm/i915/icp: Introduce Ice Lake PCH

[Paulo Zanoni]

From: Anusha Srivatsa 

Add the enum additions to ICP PCH.

v2 (from Paulo): don't set any platforms to it yet since ICP support is
incomplete.
v3 (from Rodrigo): Fix ICP name.

Reviewed-by: Paulo Zanoni 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 016920f58ae6..482517af58f6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -783,6 +783,7 @@ enum intel_pch {
PCH_SPT,/* Sunrisepoint PCH */
PCH_KBP,/* Kaby Lake PCH */
PCH_CNP,/* Cannon Lake PCH */
+   PCH_ICP,/* Ice Lake PCH */
PCH_NOP,
 };
 
@@ -2850,6 +2851,7 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define INTEL_PCH_QEMU_DEVICE_ID_TYPE  0x2900 /* qemu q35 has 2918 */
 
 #define INTEL_PCH_TYPE(dev_priv) ((dev_priv)->pch_type)
+#define HAS_PCH_ICP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_ICP)
 #define HAS_PCH_CNP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_CNP)
 #define HAS_PCH_CNP_LP(dev_priv) \
((dev_priv)->pch_id == INTEL_PCH_CNP_LP_DEVICE_ID_TYPE)
-- 
2.14.3

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

[Intel-gfx] [PATCH 2/8] drm/i915/icl: Add initial Icelake definitions.

[Paulo Zanoni]

From: Rodrigo Vivi 

Icelake is an Intel® Processor containing an Intel® Graphics
Controller.

This is just an initial Icelake definition. PCI IDs, Icelake support
and new features coming in following patches.

v2: Add .ddb_size and .has_guc (Michal Wajdeczko).
v3: Add the ICL_FEATURES macro (Kelvin Gardiner).
v4 (from Paulo): Add missing __initconst (Paulo) and say "graphics
controller" instead of something that looks like an official marketing
name but isn't (Chris).

Reviewed-by: Rodrigo Vivi 
Reviewed-by: Paulo Zanoni 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 ++
 drivers/gpu/drm/i915/i915_pci.c  | 13 +
 drivers/gpu/drm/i915/intel_device_info.c |  1 +
 drivers/gpu/drm/i915/intel_device_info.h |  2 ++
 4 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a689396d0ff6..016920f58ae6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2595,6 +2595,7 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define IS_GEMINILAKE(dev_priv)IS_PLATFORM(dev_priv, INTEL_GEMINILAKE)
 #define IS_COFFEELAKE(dev_priv)IS_PLATFORM(dev_priv, INTEL_COFFEELAKE)
 #define IS_CANNONLAKE(dev_priv)IS_PLATFORM(dev_priv, INTEL_CANNONLAKE)
+#define IS_ICELAKE(dev_priv)   IS_PLATFORM(dev_priv, INTEL_ICELAKE)
 #define IS_MOBILE(dev_priv)((dev_priv)->info.is_mobile)
 #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
(INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00)
@@ -2706,6 +2707,7 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define IS_GEN8(dev_priv)  (!!((dev_priv)->info.gen_mask & BIT(7)))
 #define IS_GEN9(dev_priv)  (!!((dev_priv)->info.gen_mask & BIT(8)))
 #define IS_GEN10(dev_priv) (!!((dev_priv)->info.gen_mask & BIT(9)))
+#define IS_GEN11(dev_priv) (!!((dev_priv)->info.gen_mask & BIT(10)))
 
 #define IS_LP(dev_priv)(INTEL_INFO(dev_priv)->is_lp)
 #define IS_GEN9_LP(dev_priv)   (IS_GEN9(dev_priv) && IS_LP(dev_priv))
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 36d48422b475..f28c165fc49d 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -579,6 +579,19 @@ static const struct intel_device_info 
intel_cannonlake_gt2_info __initconst = {
.gt = 2,
 };
 
+#define GEN11_FEATURES \
+   GEN10_FEATURES, \
+   .gen = 11, \
+   .ddb_size = 2048, \
+   .has_csr = 0
+
+static const struct intel_device_info intel_icelake_11_info __initconst = {
+   GEN11_FEATURES,
+   .platform = INTEL_ICELAKE,
+   .is_alpha_support = 1,
+   .has_resource_streamer = 0,
+};
+
 /*
  * Make sure any device matches here are from most specific to most
  * general.  For example, since the Quanta match is based on the subsystem
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index d28592e43512..a2c16140169f 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -56,6 +56,7 @@ static const char * const platform_names[] = {
PLATFORM_NAME(GEMINILAKE),
PLATFORM_NAME(COFFEELAKE),
PLATFORM_NAME(CANNONLAKE),
+   PLATFORM_NAME(ICELAKE),
 };
 #undef PLATFORM_NAME
 
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 49cb27bd04c1..9542018d11d0 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -69,6 +69,8 @@ enum intel_platform {
INTEL_COFFEELAKE,
/* gen10 */
INTEL_CANNONLAKE,
+   /* gen11 */
+   INTEL_ICELAKE,
INTEL_MAX_PLATFORMS
 };
 
-- 
2.14.3

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

[Intel-gfx] [PATCH 0/8] ICP initial support

[Paulo Zanoni]

Hi

This series adds the initial support for ICP. No conflicts with the other
series. Patches 1 and 2 are parts of other series that we've already been
discussing on this mailing list, but I put them here so CI can do the right
thing.

I have just re-reviewed all of Anusha's patches and my reviewed-by tags still
stand, which means every patch on this series has a r-b tag. I'll let the series
sit on the mailing list for a while before merging, just in case someone else
has something to say.

The one thing missing for complete ICP support is the patch that adds the
interrupts, but that requires code from other series (including the GEM one
currently under review), so it will be sent later.

Thanks,
Paulo

Anusha Srivatsa (6):
  drm/i915/icp: Introduce Ice Lake PCH
  drm/i915/icp: Get/set proper Raw clock frequency on ICP
  drm/i915/icp: Add Panel Power Sequencing Support
  drm/i915/icp: Add backlight Support for ICP
  drm/i915/icp: add ICP gmbus and gpio support
  drm/i915/icp: Add the ID for ICL PCH - ICP

Rodrigo Vivi (2):
  drm/i915/cnl: Add Port F definition.
  drm/i915/icl: Add initial Icelake definitions.

 drivers/gpu/drm/i915/i915_drv.c  |  4 
 drivers/gpu/drm/i915/i915_drv.h  |  5 +
 drivers/gpu/drm/i915/i915_pci.c  | 13 +
 drivers/gpu/drm/i915/i915_reg.h  |  9 -
 drivers/gpu/drm/i915/intel_bios.c|  9 +
 drivers/gpu/drm/i915/intel_cdclk.c   | 29 ++--
 drivers/gpu/drm/i915/intel_device_info.c |  1 +
 drivers/gpu/drm/i915/intel_device_info.h |  2 ++
 drivers/gpu/drm/i915/intel_display.h |  1 +
 drivers/gpu/drm/i915/intel_dp.c  | 20 +--
 drivers/gpu/drm/i915/intel_hdmi.c| 33 
 drivers/gpu/drm/i915/intel_i2c.c | 17 ++--
 drivers/gpu/drm/i915/intel_panel.c   |  2 +-
 drivers/gpu/drm/i915/intel_vbt_defs.h|  2 ++
 include/drm/i915_component.h |  3 +--
 15 files changed, 136 insertions(+), 14 deletions(-)

-- 
2.14.3

___
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: add query uAPI

[Lionel Landwerlin]

Applied all of your comments here.

On 11/01/18 12:19, Tvrtko Ursulin wrote:


On 18/12/2017 15:35, Lionel Landwerlin wrote:

There are a number of information that are readable from hardware
registers and that we would like to make accessible to userspace. One
particular example is the topology of the execution units (how are
execution units grouped in subslices and slices and also which ones
have been fused off for die recovery).

At the moment the GET_PARAM ioctl covers some basic needs, but
generally is only able to return a single value for each defined
parameter. This is a bit problematic with topology descriptions which
are array/maps of available units.

This change introduces a new ioctl that can deal with requests to fill
structures of potentially variable lengths. The user is expected fill
a query with length fields set at 0 on the first call, the kernel then
sets the length fields to the their expected values. A second call to
the kernel with length fields at their expected values will trigger a
copy of the data to the pointed memory locations.

The scope of this uAPI is only to provide information to userspace,
not to allow configuration of the device.

Signed-off-by: Lionel Landwerlin 
---
  drivers/gpu/drm/i915/Makefile |  1 +
  drivers/gpu/drm/i915/i915_drv.c   |  1 +
  drivers/gpu/drm/i915/i915_drv.h   |  3 +++
  drivers/gpu/drm/i915/i915_query.c | 52 
+++

  include/uapi/drm/i915_drm.h   | 31 +++
  5 files changed, 88 insertions(+)
  create mode 100644 drivers/gpu/drm/i915/i915_query.c

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

index 091aef281963..9627e7e309dc 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -69,6 +69,7 @@ i915-y += i915_cmd_parser.o \
    i915_gem_timeline.o \
    i915_gem_userptr.o \
    i915_gemfs.o \
+  i915_query.o \
    i915_trace_points.o \
    i915_vma.o \
    intel_breadcrumbs.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.c 
b/drivers/gpu/drm/i915/i915_drv.c

index 8b99e415c345..a90ed9f2b759 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2814,6 +2814,7 @@ static const struct drm_ioctl_desc 
i915_ioctls[] = {
  DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
DRM_RENDER_ALLOW),
  DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, 
i915_perf_add_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
  DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG, 
i915_perf_remove_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
+    DRM_IOCTL_DEF_DRV(I915_QUERY, i915_query_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),

  };
    static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h 
b/drivers/gpu/drm/i915/i915_drv.h

index 82fc59078c6a..3415a3d2399c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4084,6 +4084,9 @@ 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_query.c */
+int i915_query_ioctl(struct drm_device *dev, void *data, struct 
drm_file *file);

+
  /* 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_query.c 
b/drivers/gpu/drm/i915/i915_query.c

new file mode 100644
index ..227a28978190
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -0,0 +1,52 @@
+/*
+ * 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"
+#include 
+
+int i915_query_ioctl(struct drm_device *dev, void *data, struct 
drm_file *file)

+{
+    struct 

Re: [Intel-gfx] [PATCH 3/6] drm/i915/debugfs: add rcs topology entry

[Lionel Landwerlin]

On 11/01/18 11:31, Tvrtko Ursulin wrote:


On 18/12/2017 15:35, Lionel Landwerlin wrote:

While the end goal is to make this information available to userspace
through a new ioctl, there is no reason we can't display it in a human
readable fashion through debugfs.

slice0 (subslice_mask=0x7):


I'd add a subslice count while at it, since the eu lines have counts.

Bike-shedding on whether counts or masks are typically more important?

Slice0: 3 slices (0x7):
Subslice 0: 8 EUs (0xff)
Subslice 1: 8 EUs (0xff)
...

?


Yeah, sure.




subslice0:
    eu_mask: 0xff (8)
subslice1:
    eu_mask: 0xff (8)
subslice2:
    eu_mask: 0xff (8)
subslice3:
    eu_mask: 0x0 (0)
slice1 (subslice_mask=0x7):
subslice0:
    eu_mask: 0xff (8)
subslice1:
    eu_mask: 0xff (8)
subslice2:
    eu_mask: 0xff (8)
subslice3:
    eu_mask: 0x0 (0)
slice2 (subslice_mask=0x7):
subslice0:
    eu_mask: 0xff (8)
subslice1:
    eu_mask: 0xff (8)
subslice2:
    eu_mask: 0xff (8)
subslice3:
    eu_mask: 0x0 (0)

Suggested-by: Chris Wilson 
Signed-off-by: Lionel Landwerlin 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 37 
+

  1 file changed, 37 insertions(+)

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

index 6ec7543e698f..79ca6e9f9ec9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3173,6 +3173,42 @@ static int i915_engine_info(struct seq_file 
*m, void *unused)

  return 0;
  }
  +static int i915_rcs_topology(struct seq_file *m, void *unused)
+{
+    struct drm_i915_private *dev_priv = node_to_i915(m->private);
+    const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+    int s, ss;
+    int subslice_stride = ALIGN(sseu->max_eus_per_subslice, 8) / 8;
+    int slice_stride = sseu->max_subslices * subslice_stride;


Another case for the before mentioned helper for indexing into eu_mask 
array?


Done.




+
+    if (sseu->max_slices == 0) {
+    seq_printf(m, "Unavailable\n");
+    return 0;
+    }


Is this possible?


Yeah, there are no registers to read on anything < gen8.
I've decided not to generate data there. Most userspaces already has the 
numbers from a table by pci-id.





+
+    for (s = 0; s < sseu->max_slices; s++) {
+    seq_printf(m, "slice%i (subslice_mask=0x%x):\n",


%i always confuses me. Googling shows it is equivalent to %d for 
printing? Or is it something different in kernel space? If it is 
equivalent I would go with a more standard one. And I would even 
change to unsigned variables for iterators but I realize some people 
have a different opinion so up to you.


Yeah, I'm always using %i, but I must be the only one.
It's been easier to remember int -> %i.




+   s, sseu->subslices_mask[s]);
+
+    for (ss = 0; ss < slice_stride / subslice_stride; ss++) {


With the indexing helpers hopefully it would be possible to simply 
iterate to hweight8(sseu->sublice_mask[s]) ?


Actually I should use sseu->max_subslices.




+    int eu, n_subslice_eus = 0;
+
+    seq_printf(m, "\tsubslice%i:\n", ss);
+
+    seq_printf(m, "\t\teu_mask:");
+    for (eu = 0; eu < subslice_stride; eu++) {
+    u8 val = sseu->eu_mask[s * slice_stride +
+   ss * subslice_stride + eu];
+    seq_printf(m, " 0x%x", val);
+    n_subslice_eus += hweight8(val);
+    }
+    seq_printf(m, " (%i)\n", n_subslice_eus);
+    }
+    }
+
+    return 0;
+}
+
  static int i915_shrinker_info(struct seq_file *m, void *unused)
  {
  struct drm_i915_private *i915 = node_to_i915(m->private);
@@ -4658,6 +4694,7 @@ static const struct drm_info_list 
i915_debugfs_list[] = {

  {"i915_dmc_info", i915_dmc_info, 0},
  {"i915_display_info", i915_display_info, 0},
  {"i915_engine_info", i915_engine_info, 0},
+    {"i915_rcs_topology", i915_rcs_topology, 0},
  {"i915_shrinker_info", i915_shrinker_info, 0},
  {"i915_shared_dplls_info", i915_shared_dplls_info, 0},
  {"i915_dp_mst_info", i915_dp_mst_info, 0},



Regards,

Tvrtko



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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/guc: Don't enable GuC when vGPU is active

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/guc: Don't enable GuC when vGPU is 
active
URL   : https://patchwork.freedesktop.org/series/36343/
State : failure

== Summary ==

Series 36343v1 series starting with [1/2] drm/i915/guc: Don't enable GuC when 
vGPU is active
https://patchwork.freedesktop.org/api/1.0/series/36343/revisions/1/mbox/

Test core_auth:
Subgroup basic-auth:
pass   -> SKIP   (fi-skl-gvtdvm)
Test core_prop_blob:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
pass   -> SKIP   (fi-skl-gvtdvm)
Test drv_getparams_basic:
Subgroup basic-eu-total:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-subslice-total:
pass   -> SKIP   (fi-skl-gvtdvm)
Test drv_hangman:
Subgroup error-state-basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_basic:
Subgroup bad-close:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup create-close:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup create-fd-close:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_busy:
Subgroup basic-busy-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-hang-default:
pass   -> SKIP   (fi-skl-gvtdvm) fdo#104108 +2
Test gem_close_race:
Subgroup basic-process:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-threads:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_cpu_reloc:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_cs_tlb:
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_create:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-files:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_exec:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_param:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_switch:
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-default-heavy:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_exec_basic:
Subgroup basic-blt:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-bsd:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-bsd1:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-bsd2:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-render:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-vebox:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-blt:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-bsd:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-bsd1:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-bsd2:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-render:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-vebox:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup readonly-blt:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup readonly-bsd:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup readonly-bsd1:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup readonly-bsd2:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup readonly-default:
WARNING: Long output truncated

da4321c7c088d01ad62b18d37dcfe5ef8d0b855d drm-tip: 2018y-01m-11d-14h-59m-37s UTC 
integration manifest
a0e8e84432b0 HAX: drm/i915/uc: Enable GuC/HuC for CI
973357da236a drm/i915/guc: Don't enable GuC when vGPU is active

== Logs ==

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

[Intel-gfx] [PATCH 2/2] HAX: drm/i915/uc: Enable GuC/HuC for CI

[Sagar Arun Kamble]

Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_params.c | 2 +-
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index b5f3eb4..a9cc03a 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -152,7 +152,7 @@ struct i915_params i915_modparams __read_mostly = {
 i915_param_named_unsafe(enable_guc, int, 0400,
"Enable GuC load for GuC submission and/or HuC load. "
"Required functionality can be selected using bitmask values. "
-   "(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)");
+   "(-1=auto [default], 0=disable, 1=GuC submission, 2=HuC load)");
 
 i915_param_named(guc_log_level, int, 0400,
"GuC firmware logging level (-1:disabled (default), 0-3:enabled)");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index c963603..53037b5 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \
param(int, guc_log_level, -1) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
-- 
1.9.1

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

[Intel-gfx] [PATCH 1/2] drm/i915/guc: Don't enable GuC when vGPU is active

[Sagar Arun Kamble]

In GVT-g, if GuC is to be used it is to be loaded by Host and not by
VM/vGPU. Currently, GVT-g host is not supported with GuC submission.
Also currently vGPU is to be not supported with GuC submission AFAIK.
CI BAT highlighted GuC init issue on skl-gvtdvm due to lack of movntdqa
needed for logging with below warning:

 WARN_ON(!i915_memcpy_from_wc(((void *)0), ((void *)0), 0))
 WARNING: CPU: 0 PID: 216 at drivers/gpu/drm/i915/intel_guc_log.c:383

This patch disables GuC when vGPU is active.

Signed-off-by: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Joonas Lahtinen 
Cc: Changbin Du 
---
 drivers/gpu/drm/i915/intel_uc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index d82ca0f..a836cf8 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -61,6 +61,8 @@ static int __get_platform_enable_guc(struct drm_i915_private 
*dev_priv)
enable_guc |= ENABLE_GUC_LOAD_HUC;
 
/* Any platform specific fine-tuning can be done here */
+   if (intel_vgpu_active(dev_priv))
+   enable_guc = 0;
 
return enable_guc;
 }
-- 
1.9.1

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/guc: Redefine guc_log_level modparam values

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/2] drm/i915/guc: Redefine guc_log_level 
modparam values
URL   : https://patchwork.freedesktop.org/series/36341/
State : success

== Summary ==

Series 36341v1 series starting with [v2,1/2] drm/i915/guc: Redefine 
guc_log_level modparam values
https://patchwork.freedesktop.org/api/1.0/series/36341/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-bdw-5557u) fdo#104162
fail   -> PASS   (fi-skl-6700k2) fdo#103191

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104162 https://bugs.freedesktop.org/show_bug.cgi?id=104162
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191

fi-bdw-5557u total:245  pass:227  dwarn:0   dfail:0   fail:0   skip:17 
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:375s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:485s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:484s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:483s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:475s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:454s
fi-cnl-y2total:288  pass:258  dwarn:3   dfail:0   fail:0   skip:27  
time:543s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:275s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:511s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:393s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:403s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:459s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:413s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:468s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:500s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:504s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:579s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:430s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:512s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:529s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:494s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:478s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:394s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:568s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:472s
fi-bdw-gvtdvm failed to collect. IGT log at Patchwork_7650/fi-bdw-gvtdvm/igt.log

da4321c7c088d01ad62b18d37dcfe5ef8d0b855d drm-tip: 2018y-01m-11d-14h-59m-37s UTC 
integration manifest
6623668a0fee drm/i915/guc: Change values for i915_guc_log_control
a7d4778bb579 drm/i915/guc: Redefine guc_log_level modparam values

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/pmu: Initialise our dynamic sysfs attributes for use with lockdep

[Patchwork]

== Series Details ==

Series: drm/i915/pmu: Initialise our dynamic sysfs attributes for use with 
lockdep
URL   : https://patchwork.freedesktop.org/series/36337/
State : failure

== Summary ==

Test kms_plane_multiple:
Subgroup atomic-pipe-a-tiling-none:
pass   -> SKIP   (shard-hsw)
Subgroup legacy-pipe-b-tiling-none:
incomplete -> PASS   (shard-hsw)
Test kms_busy:
Subgroup basic-modeset-a:
pass   -> SKIP   (shard-snb)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
skip   -> PASS   (shard-hsw) fdo#101623 +2
Test kms_flip:
Subgroup vblank-vs-hang-interruptible:
pass   -> INCOMPLETE (shard-hsw)
Test drv_suspend:
Subgroup fence-restore-untiled-hibernate:
skip   -> FAIL   (shard-hsw) fdo#103375
Test perf:
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252

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

shard-hswtotal:2605 pass:1474 dwarn:1   dfail:0   fail:9   skip:1119 
time:8494s
shard-snbtotal:2713 pass:1309 dwarn:1   dfail:0   fail:11  skip:1392 
time:7878s
Blacklisted hosts:
shard-apltotal:2547 pass:1584 dwarn:1   dfail:0   fail:26  skip:934 
time:11842s
shard-kbltotal:2609 pass:1725 dwarn:14  dfail:0   fail:28  skip:839 
time:8865s

== Logs ==

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

Re: [Intel-gfx] [PATCH 1/6] drm/i915: store all subslice masks

[Lionel Landwerlin]

On 11/01/18 11:12, Tvrtko Ursulin wrote:

*/
+    eu_en = ~I915_READ(GEN8_EU_DISABLE0);
+    for (ss = 0; ss < sseu->max_subslices; ss++)
+    sseu->eu_mask[ss] = (eu_en >> (8 * ss)) & eu_mask;
+    /* Slice1 */
+    sseu->eu_mask[sseu->max_subslices] = (eu_en >> 24) & 
eu_mask;

+    eu_en = ~I915_READ(GEN8_EU_DISABLE1);
+    sseu->eu_mask[sseu->max_subslices + 1] = eu_en & eu_mask;


I suggest a helper to index into sse->eu_mask, like 
sseu->eu_mask[_eu_mask_idx(slice, subslice)] or something, so it is 
more readable what is happening here. Or even:


 _eu_mask(sseu, slice, subslice) = mask;

Doable? I am not 100% I picked up exactly on the layout of the eu_mask 
array.. each element is one subslice? Consecutive for slice0, 
subslice0..N, slice1... sliceN ? 

Oops, I misread that part.
I thought you wanted a helper for accessing the registers.
I'll add a helper for what you would like.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/6] drm/i915: store all subslice masks

[Tvrtko Ursulin]

On 11/01/2018 15:48, Lionel Landwerlin wrote:

On 11/01/18 11:12, Tvrtko Ursulin wrote:


On 18/12/2017 15:35, Lionel Landwerlin wrote:

Up to now, subslice mask was assumed to be uniform across slices. But
starting with Cannonlake, slices can be asymetric (for example slice0


asymmetric, thanks auto spell checker. :)


Done, thanks.




has different number of subslices as slice1+). This change stores all
subslices masks for all slices rather than having a single mask that
applies to all slices.

Signed-off-by: Lionel Landwerlin 
---
  drivers/gpu/drm/i915/i915_debugfs.c  |  24 +++--
  drivers/gpu/drm/i915/i915_drv.c  |   2 +-
  drivers/gpu/drm/i915/i915_drv.h  |  23 -
  drivers/gpu/drm/i915/intel_device_info.c | 169 
++-

  drivers/gpu/drm/i915/intel_lrc.c |   2 +-
  drivers/gpu/drm/i915/intel_ringbuffer.h  |   2 +-
  6 files changed, 161 insertions(+), 61 deletions(-)

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

index 0ddce72552bf..0c7890b695c5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4293,7 +4293,7 @@ static void 
cherryview_sseu_device_status(struct drm_i915_private *dev_priv,

  continue;
    sseu->slice_mask = BIT(0);
-    sseu->subslice_mask |= BIT(ss);
+    sseu->subslices_mask[0] |= BIT(ss);
  eu_cnt = ((sig1[ss] & CHV_EU08_PG_ENABLE) ? 0 : 2) +
   ((sig1[ss] & CHV_EU19_PG_ENABLE) ? 0 : 2) +
   ((sig1[ss] & CHV_EU210_PG_ENABLE) ? 0 : 2) +
@@ -4340,7 +4340,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,

  continue;
    sseu->slice_mask |= BIT(s);
-    sseu->subslice_mask = info->sseu.subslice_mask;
+    sseu->subslices_mask[s] = info->sseu.subslices_mask[s];
    for (ss = 0; ss < ss_max; ss++) {
  unsigned int eu_cnt;
@@ -4395,8 +4395,8 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,

  sseu->slice_mask |= BIT(s);
    if (IS_GEN9_BC(dev_priv))
-    sseu->subslice_mask =
-    INTEL_INFO(dev_priv)->sseu.subslice_mask;
+    sseu->subslices_mask[s] =
+ INTEL_INFO(dev_priv)->sseu.subslices_mask[s];
    for (ss = 0; ss < ss_max; ss++) {
  unsigned int eu_cnt;
@@ -4406,7 +4406,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,

  /* skip disabled subslice */
  continue;
  -    sseu->subslice_mask |= BIT(ss);
+    sseu->subslices_mask[s] |= BIT(ss);
  }
    eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] &
@@ -4428,9 +4428,12 @@ static void 
broadwell_sseu_device_status(struct drm_i915_private *dev_priv,

  sseu->slice_mask = slice_info & GEN8_LSLICESTAT_MASK;
    if (sseu->slice_mask) {
-    sseu->subslice_mask = INTEL_INFO(dev_priv)->sseu.subslice_mask;
  sseu->eu_per_subslice =
  INTEL_INFO(dev_priv)->sseu.eu_per_subslice;
+    for (s = 0; s < fls(sseu->slice_mask); s++) {
+    sseu->subslices_mask[s] =
+ INTEL_INFO(dev_priv)->sseu.subslices_mask[s];
+    }
  sseu->eu_total = sseu->eu_per_subslice *
   sseu_subslice_total(sseu);
  @@ -4449,6 +4452,7 @@ static void i915_print_sseu_info(struct 
seq_file *m, bool is_available_info,

  {
  struct drm_i915_private *dev_priv = node_to_i915(m->private);
  const char *type = is_available_info ? "Available" : "Enabled";
+    int s;
    seq_printf(m, "  %s Slice Mask: %04x\n", type,
 sseu->slice_mask);
@@ -4456,10 +4460,10 @@ static void i915_print_sseu_info(struct 
seq_file *m, bool is_available_info,

 hweight8(sseu->slice_mask));
  seq_printf(m, "  %s Subslice Total: %u\n", type,
 sseu_subslice_total(sseu));
-    seq_printf(m, "  %s Subslice Mask: %04x\n", type,
-   sseu->subslice_mask);
-    seq_printf(m, "  %s Subslice Per Slice: %u\n", type,
-   hweight8(sseu->subslice_mask));
+    for (s = 0; s < fls(sseu->slice_mask); s++) {


Slice mask is always contiguous bits?


I have a 2x6 BXT on my desk where the subslice0 appears to be fused-off.
I assumed same could be true for slices.
fls() should make us iterate through all the slices (even the fused off 
ones).


Do you then want to skip printing the fused off ones? Just asking, don't 
think it matters hugely.





+    seq_printf(m, "  %s Slice%i Subslice Mask: %04x\n", type,
+   s, sseu->subslices_mask[s]);


Don't want to keep printing the count? Like maybe " %s Slice%u %u 
sublices, mask=%04x\n" ?


Sure, done.




+    }
  seq_printf(m, "  %s EU Total: %u\n", type,
 sseu->eu_total);
  seq_printf(m, "  %s EU Per Subslice: %u\n", type,
diff --git a/drivers/gpu/drm/i915/i915_drv.c 

[Intel-gfx] [PATCH v2 2/2] drm/i915/guc: Change values for i915_guc_log_control

[Michal Wajdeczko]

Today we have format mismatch between read/write operations
of i915_guc_log_control entry. For read we return (0, 1..4)
that represents disable/verbosity levels, but for write we
force user to follow internal structure format (0,1,9,11,13).
Let's hide internals from the user and accept same values
as we support for read and related guc_log_level modparam.

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

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index e6d59bf..1719f1e 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -58,11 +58,15 @@ static int guc_log_flush(struct intel_guc *guc)
return intel_guc_send(guc, action, ARRAY_SIZE(action));
 }
 
-static int guc_log_control(struct intel_guc *guc, u32 control_val)
+static int guc_log_control(struct intel_guc *guc, bool enable, u32 verbosity)
 {
+   union guc_log_control control_val = { .logging_enabled = enable,
+ .reserved1 = 0,
+ .verbosity = verbosity,
+ .reserved2 = 0 };
u32 action[] = {
INTEL_GUC_ACTION_UK_LOG_ENABLE_LOGGING,
-   control_val
+   control_val.value
};
 
return intel_guc_send(guc, action, ARRAY_SIZE(action));
@@ -567,28 +571,27 @@ 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;
+   bool enable_logging = control_val > 0;
+   u32 verbosity;
int ret;
 
-   log_param.value = control_val;
-
-   if (log_param.verbosity < GUC_LOG_VERBOSITY_MIN ||
-   log_param.verbosity > GUC_LOG_VERBOSITY_MAX)
+   BUILD_BUG_ON(GUC_LOG_VERBOSITY_MIN);
+   if (control_val > 1 + GUC_LOG_VERBOSITY_MAX)
return -EINVAL;
 
/* This combination doesn't make sense & won't have any effect */
-   if (!log_param.logging_enabled && !i915_modparams.guc_log_level)
+   if (!enable_logging && !i915_modparams.guc_log_level)
return 0;
 
-   ret = guc_log_control(guc, log_param.value);
+   verbosity = enable_logging ? control_val - 1 : 0;
+   ret = guc_log_control(guc, enable_logging, verbosity);
if (ret < 0) {
DRM_DEBUG_DRIVER("guc_logging_control action failed %d\n", ret);
return ret;
}
 
-   if (log_param.logging_enabled) {
-   i915_modparams.guc_log_level = 1 + log_param.verbosity;
+   if (enable_logging) {
+   i915_modparams.guc_log_level = 1 + verbosity;
 
/*
 * If log was disabled at boot time, then the relay channel file
-- 
1.9.1

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

[Intel-gfx] [PATCH v2 1/2] drm/i915/guc: Redefine guc_log_level modparam values

[Michal Wajdeczko]

We used value -1 to indicate "disabled" and values 0..3 to
indicate "enabled", but most of our other modparams are using
-1 for "auto" mode and 0 for "disable". For consistency let's
change our log level values to:

-1: auto (depends on platform and Kconfig.debug settings)
 0: disabled
 1: enabled (severity level 0 = min)
 2: enabled (severity level 1)
 3: enabled (severity level 2)
 4: enabled (severity level 3 = max)

v2: fix commit message (Sagar)
display sanitized modparam value (Sagar)
unify sanitize messages (Sagar/Michal)

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

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index b5f3eb4..0b553a8 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -155,7 +155,8 @@ struct i915_params i915_modparams __read_mostly = {
"(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)");
 
 i915_param_named(guc_log_level, int, 0400,
-   "GuC firmware logging level (-1:disabled (default), 0-3:enabled)");
+   "GuC firmware logging level. Requires GuC to be loaded. "
+   "(-1=auto [default], 0=disable, 1..4=enable with verbosity min..max)");
 
 i915_param_named_unsafe(guc_firmware_path, charp, 0400,
"GuC firmware path to use instead of the default one");
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 50b4725..4681537 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -215,6 +215,18 @@ static u32 get_core_family(struct drm_i915_private 
*dev_priv)
}
 }
 
+static u32 get_log_verbosity_flags(void)
+{
+   if (i915_modparams.guc_log_level > 0) {
+   u32 verbosity = i915_modparams.guc_log_level - 1;
+
+   GEM_BUG_ON(verbosity > GUC_LOG_VERBOSITY_MAX);
+   return verbosity << GUC_LOG_VERBOSITY_SHIFT;
+   }
+   GEM_BUG_ON(i915_modparams.enable_guc < 0);
+   return GUC_LOG_DISABLED;
+}
+
 /*
  * Initialise the GuC parameter block before starting the firmware
  * transfer. These parameters are read by the firmware on startup
@@ -247,12 +259,7 @@ void intel_guc_init_params(struct intel_guc *guc)
 
params[GUC_CTL_LOG_PARAMS] = guc->log.flags;
 
-   if (i915_modparams.guc_log_level >= 0) {
-   params[GUC_CTL_DEBUG] =
-   i915_modparams.guc_log_level << GUC_LOG_VERBOSITY_SHIFT;
-   } else {
-   params[GUC_CTL_DEBUG] = GUC_LOG_DISABLED;
-   }
+   params[GUC_CTL_DEBUG] = get_log_verbosity_flags();
 
/* If GuC submission is enabled, set up additional parameters here */
if (USES_GUC_SUBMISSION(dev_priv)) {
@@ -445,7 +452,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
 
-   if (i915_modparams.guc_log_level >= 0)
+   if (i915_modparams.guc_log_level)
gen9_enable_guc_interrupts(dev_priv);
 
data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index eaedd63..e6d59bf 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -33,11 +33,10 @@
 /**
  * DOC: GuC firmware log
  *
- * Firmware log is enabled by setting i915.guc_log_level to non-negative level.
+ * Firmware log is enabled by setting i915.guc_log_level to the positive level.
  * Log data is printed out via reading debugfs i915_guc_log_dump. Reading from
  * i915_guc_load_status will print out firmware loading status and scratch
  * registers value.
- *
  */
 
 static int guc_log_flush_complete(struct intel_guc *guc)
@@ -147,7 +146,7 @@ static int guc_log_relay_file_create(struct intel_guc *guc)
struct dentry *log_dir;
int ret;
 
-   if (i915_modparams.guc_log_level < 0)
+   if (!i915_modparams.guc_log_level)
return 0;
 
/* For now create the log file in /sys/kernel/debug/dri/0 dir */
@@ -423,8 +422,8 @@ static void guc_log_runtime_destroy(struct intel_guc *guc)
 {
/*
 * It's possible that the runtime stuff was never allocated because
-* guc_log_level was < 0 at the time
-**/
+* GuC log was disabled at the boot time.
+*/
if (!guc_log_has_runtime(guc))
return;
 
@@ -441,9 

Re: [Intel-gfx] [PATCH 2/6] drm/i915/debugfs: reuse max slice/subslices already stored in sseu

[Lionel Landwerlin]

On 11/01/18 11:21, Tvrtko Ursulin wrote:


On 18/12/2017 15:35, Lionel Landwerlin wrote:
Now that we have that information in topology fields, let's just 
reused it.


Signed-off-by: Lionel Landwerlin 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 26 ++
  1 file changed, 10 insertions(+), 16 deletions(-)

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

index 0c7890b695c5..6ec7543e698f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4308,11 +4308,11 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,

   struct sseu_dev_info *sseu)
  {
  const struct intel_device_info *info = INTEL_INFO(dev_priv);
-    int s_max = 6, ss_max = 4;
  int s, ss;
-    u32 s_reg[s_max], eu_reg[2 * s_max], eu_mask[2];
+    u32 s_reg[info->sseu.max_slices],
+    eu_reg[2 * info->sseu.max_subslices], eu_mask[2];


This is a bit unusual style, perhaps split into separate declarations.


Done.




  -    for (s = 0; s < s_max; s++) {
+    for (s = 0; s < info->sseu.max_slices; s++) {
  /*
   * FIXME: Valid SS Mask respects the spec and read
   * only valid bits for those registers, excluding reserverd
@@ -4334,7 +4334,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,

   GEN9_PGCTL_SSB_EU210_ACK |
   GEN9_PGCTL_SSB_EU311_ACK;
  -    for (s = 0; s < s_max; s++) {
+    for (s = 0; s < info->sseu.max_slices; s++) {
  if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
  /* skip disabled slice */
  continue;
@@ -4342,7 +4342,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,

  sseu->slice_mask |= BIT(s);
  sseu->subslices_mask[s] = info->sseu.subslices_mask[s];
  -    for (ss = 0; ss < ss_max; ss++) {
+    for (ss = 0; ss < info->sseu.max_subslices; ss++) {
  unsigned int eu_cnt;
    if (!(s_reg[s] & (GEN9_PGCTL_SS_ACK(ss
@@ -4362,17 +4362,11 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,

  static void gen9_sseu_device_status(struct drm_i915_private *dev_priv,
  struct sseu_dev_info *sseu)
  {
-    int s_max = 3, ss_max = 4;
+    const struct intel_device_info *info = INTEL_INFO(dev_priv);
  int s, ss;
-    u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
-
-    /* BXT has a single slice and at most 3 subslices. */
-    if (IS_GEN9_LP(dev_priv)) {
-    s_max = 1;
-    ss_max = 3;
-    }
+    u32 s_reg[info->sseu.max_slices], 
eu_reg[2*info->sseu.max_subslices], eu_mask[2];


Spaces around operators are preferred.


Done.




  -    for (s = 0; s < s_max; s++) {
+    for (s = 0; s < info->sseu.max_slices; s++) {
  s_reg[s] = I915_READ(GEN9_SLICE_PGCTL_ACK(s));
  eu_reg[2*s] = I915_READ(GEN9_SS01_EU_PGCTL_ACK(s));
  eu_reg[2*s + 1] = I915_READ(GEN9_SS23_EU_PGCTL_ACK(s));
@@ -4387,7 +4381,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,

   GEN9_PGCTL_SSB_EU210_ACK |
   GEN9_PGCTL_SSB_EU311_ACK;
  -    for (s = 0; s < s_max; s++) {
+    for (s = 0; s < info->sseu.max_slices; s++) {
  if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
  /* skip disabled slice */
  continue;
@@ -4398,7 +4392,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,

  sseu->subslices_mask[s] =
INTEL_INFO(dev_priv)->sseu.subslices_mask[s];
  -    for (ss = 0; ss < ss_max; ss++) {
+    for (ss = 0; ss < info->sseu.max_subslices; ss++) {
  unsigned int eu_cnt;
    if (IS_GEN9_LP(dev_priv)) {



With the formatting tweaks,

Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko



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

Re: [Intel-gfx] [PATCH 1/6] drm/i915: store all subslice masks

[Lionel Landwerlin]

On 11/01/18 11:12, Tvrtko Ursulin wrote:


On 18/12/2017 15:35, Lionel Landwerlin wrote:

Up to now, subslice mask was assumed to be uniform across slices. But
starting with Cannonlake, slices can be asymetric (for example slice0


asymmetric, thanks auto spell checker. :)


Done, thanks.




has different number of subslices as slice1+). This change stores all
subslices masks for all slices rather than having a single mask that
applies to all slices.

Signed-off-by: Lionel Landwerlin 
---
  drivers/gpu/drm/i915/i915_debugfs.c  |  24 +++--
  drivers/gpu/drm/i915/i915_drv.c  |   2 +-
  drivers/gpu/drm/i915/i915_drv.h  |  23 -
  drivers/gpu/drm/i915/intel_device_info.c | 169 
++-

  drivers/gpu/drm/i915/intel_lrc.c |   2 +-
  drivers/gpu/drm/i915/intel_ringbuffer.h  |   2 +-
  6 files changed, 161 insertions(+), 61 deletions(-)

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

index 0ddce72552bf..0c7890b695c5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4293,7 +4293,7 @@ static void 
cherryview_sseu_device_status(struct drm_i915_private *dev_priv,

  continue;
    sseu->slice_mask = BIT(0);
-    sseu->subslice_mask |= BIT(ss);
+    sseu->subslices_mask[0] |= BIT(ss);
  eu_cnt = ((sig1[ss] & CHV_EU08_PG_ENABLE) ? 0 : 2) +
   ((sig1[ss] & CHV_EU19_PG_ENABLE) ? 0 : 2) +
   ((sig1[ss] & CHV_EU210_PG_ENABLE) ? 0 : 2) +
@@ -4340,7 +4340,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,

  continue;
    sseu->slice_mask |= BIT(s);
-    sseu->subslice_mask = info->sseu.subslice_mask;
+    sseu->subslices_mask[s] = info->sseu.subslices_mask[s];
    for (ss = 0; ss < ss_max; ss++) {
  unsigned int eu_cnt;
@@ -4395,8 +4395,8 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,

  sseu->slice_mask |= BIT(s);
    if (IS_GEN9_BC(dev_priv))
-    sseu->subslice_mask =
-    INTEL_INFO(dev_priv)->sseu.subslice_mask;
+    sseu->subslices_mask[s] =
+ INTEL_INFO(dev_priv)->sseu.subslices_mask[s];
    for (ss = 0; ss < ss_max; ss++) {
  unsigned int eu_cnt;
@@ -4406,7 +4406,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,

  /* skip disabled subslice */
  continue;
  -    sseu->subslice_mask |= BIT(ss);
+    sseu->subslices_mask[s] |= BIT(ss);
  }
    eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] &
@@ -4428,9 +4428,12 @@ static void 
broadwell_sseu_device_status(struct drm_i915_private *dev_priv,

  sseu->slice_mask = slice_info & GEN8_LSLICESTAT_MASK;
    if (sseu->slice_mask) {
-    sseu->subslice_mask = INTEL_INFO(dev_priv)->sseu.subslice_mask;
  sseu->eu_per_subslice =
  INTEL_INFO(dev_priv)->sseu.eu_per_subslice;
+    for (s = 0; s < fls(sseu->slice_mask); s++) {
+    sseu->subslices_mask[s] =
+ INTEL_INFO(dev_priv)->sseu.subslices_mask[s];
+    }
  sseu->eu_total = sseu->eu_per_subslice *
   sseu_subslice_total(sseu);
  @@ -4449,6 +4452,7 @@ static void i915_print_sseu_info(struct 
seq_file *m, bool is_available_info,

  {
  struct drm_i915_private *dev_priv = node_to_i915(m->private);
  const char *type = is_available_info ? "Available" : "Enabled";
+    int s;
    seq_printf(m, "  %s Slice Mask: %04x\n", type,
 sseu->slice_mask);
@@ -4456,10 +4460,10 @@ static void i915_print_sseu_info(struct 
seq_file *m, bool is_available_info,

 hweight8(sseu->slice_mask));
  seq_printf(m, "  %s Subslice Total: %u\n", type,
 sseu_subslice_total(sseu));
-    seq_printf(m, "  %s Subslice Mask: %04x\n", type,
-   sseu->subslice_mask);
-    seq_printf(m, "  %s Subslice Per Slice: %u\n", type,
-   hweight8(sseu->subslice_mask));
+    for (s = 0; s < fls(sseu->slice_mask); s++) {


Slice mask is always contiguous bits?


I have a 2x6 BXT on my desk where the subslice0 appears to be fused-off.
I assumed same could be true for slices.
fls() should make us iterate through all the slices (even the fused off 
ones).





+    seq_printf(m, "  %s Slice%i Subslice Mask: %04x\n", type,
+   s, sseu->subslices_mask[s]);


Don't want to keep printing the count? Like maybe " %s Slice%u %u 
sublices, mask=%04x\n" ?


Sure, done.




+    }
  seq_printf(m, "  %s EU Total: %u\n", type,
 sseu->eu_total);
  seq_printf(m, "  %s EU Per Subslice: %u\n", type,
diff --git a/drivers/gpu/drm/i915/i915_drv.c 
b/drivers/gpu/drm/i915/i915_drv.c

index 72bea281edb7..8b99e415c345 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -414,7 +414,7 @@ 

[Intel-gfx] [PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave -

Hopefully final drm/i915 fixes for v4.15:
- Fix a KASAN reported use after free
- Whitelist a register to avoid hangs
- GVT fixes

BR,
Jani.

The following changes since commit b2cd1df66037e7c4697c7e40496bf7e4a5e16a2d:

  Linux 4.15-rc7 (2018-01-07 14:22:41 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-01-11-1

for you to fetch changes up to 5005c8514285ae4f28e862f8d91faaa2015e03a3:

  drm/i915: Don't adjust priority on an already signaled fence (2018-01-11 
11:42:53 +0200)


Hopefully final drm/i915 fixes for v4.15:
- Fix a KASAN reported use after free
- Whitelist a register to avoid hangs
- GVT fixes


Changbin Du (1):
  drm/i915/gvt: Fix stack-out-of-bounds bug in cmd parser

Chris Wilson (1):
  drm/i915: Don't adjust priority on an already signaled fence

Jani Nikula (1):
  Merge tag 'gvt-fixes-2018-01-08' of https://github.com/intel/gvt-linux 
into drm-intel-fixes

Kenneth Graunke (1):
  drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake.

Zhi Wang (1):
  drm/i915/gvt: Clear the shadow page table entry after post-sync

 drivers/gpu/drm/i915/gvt/cmd_parser.c  | 4 ++--
 drivers/gpu/drm/i915/gvt/gtt.c | 5 -
 drivers/gpu/drm/i915/i915_gem.c| 2 +-
 drivers/gpu/drm/i915/i915_reg.h| 2 ++
 drivers/gpu/drm/i915/intel_engine_cs.c | 5 +
 drivers/gpu/drm/i915/intel_lrc.c   | 3 +++
 6 files changed, 17 insertions(+), 4 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/pmu: Initialise our dynamic sysfs attributes for use with lockdep

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-01-11 14:12:38)
> You beat me to it, after I noticed the report on IRC and started 
> digging, just to find sysfs_attr_init, your fix arrived. Thanks!
> 
> It looks like a standard way of silencing lockdep for this case, 
> although I am not sure what exactly is the purpose of lock class keys in 
> sysfs attributes, and what this kind of defeat could also imply.
> 
> I planned to do it another loop, iterating the attr array, but I don't 
> see how it matters. It would be one static key versus the two. :?

It shouldn't as far as I'm aware. I'm conscious that each static attr
has its own lockclass, but dynamic users tend to have a shared
lockclass. It shouldn't matter unless we nest the sysfs operations?
-Chris
___
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 drm/i915/pmu: Initialise our dynamic sysfs attributes for use with lockdep

[Chris Wilson]

Quoting Patchwork (2018-01-11 14:39:43)
> == Series Details ==
> 
> Series: drm/i915/pmu: Initialise our dynamic sysfs attributes for use with 
> lockdep
> URL   : https://patchwork.freedesktop.org/series/36337/
> State : success
> 
> == Logs ==
> 
> For more details see: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7649/issues.html

Looks like it did the job. Thanks for double checking, and pushed,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] 282dbf9b "drm/i915: Pass intel_plane and intel_crtc to plane hooks" breaks i945GM in 4.13 and above

[Karl-Johan Karlsson]

Hello,

I have an old Lenovo Thinkpad X60 laptop with a Core 2 Duo T7200 CPU and 
i945GM integrated graphics whose graphics broke when I tried to update the 
kernel to get the Meltdown fixes.

GRUB2 shows a graphical boot menu, and Linux displays the Tux boot logos 
correctly at first. However, almost immediately after displaying the Tuxes, 
the actively scrolling area of the display shifts about two text lines 
downward, so that two decapitated penguin heads are left at the top of the 
screen and new text appears below the lower edge of the screen. When X starts, 
it too is shifted down the same amount, and only shows a black screen with a 
(working) mouse cursor. My display manager (SDDM) never shows up. Sometimes, 
while X is running, random pixels appear in the non-active area at the top of 
the screen containing the decapitated penguin heads.

My hardware is:

$ grep name /proc/cpuinfo
model name  : Intel(R) Core(TM)2 CPU T7200  @ 2.00GHz
model name  : Intel(R) Core(TM)2 CPU T7200  @ 2.00GHz

# lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 
943/940GML Express Integrated Graphics Controller (rev 03)

# grep Chipset: /var/log/Xorg.0.log
[33.085] (--) intel(0): Integrated Graphics Chipset: Intel(R) 945GM

$ xrandr | grep primary
LVDS1 connected primary 1024x768+0+0 (normal left inverted right x axis y 
axis) 250mm x 180mm

Kernel 4.12.14 does not have the bug. 4.13 and 4.14.11 have the bug in console 
and X mode. 4.15-rc7 has the bug in console mode, but crashes (completely 
black screen, Magic SysRq to reboot is the only thing that works) when 
starting X.

Bisecting from 4.12 to 4.13 pointed to this as the first bad commit:

commit 282dbf9b017bc6d5fdaeadf14e534c2fe22fee2d
Author: Ville Syrjälä 
Date:   Mon Mar 27 21:55:33 2017 +0300

drm/i915: Pass intel_plane and intel_crtc to plane hooks

But I know nothing about the driver internals to explain why.

-- 
Karl-Johan Karlsson

signature.asc
Description: This is a digitally signed message part.
___
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 drm/i915: Ignore TMDS clock limit for DP++ when EDID override is set (rev2)

[Saarinen, Jani]

HI, 
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Petri Latvala
> Sent: torstai 11. tammikuuta 2018 12.02
> To: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Ignore TMDS clock
> limit for DP++ when EDID override is set (rev2)
> 
> On Thu, Jan 11, 2018 at 09:54:02AM +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915: Ignore TMDS clock limit for DP++ when EDID override is
> set (rev2)
> > URL   : https://patchwork.freedesktop.org/series/35338/
> > State : failure
> >
> > == Summary ==
> >
> > Warning: bzip CI_DRM_3609/shard-glkb6/results32.json.bz2 wasn't in
> > correct JSON format Test kms_cursor_crc:
> > Subgroup cursor-64x21-onscreen:
> > skip   -> PASS   (shard-hsw)
> > Subgroup cursor-64x64-suspend:
> > skip   -> PASS   (shard-snb) fdo#102365
> > skip   -> PASS   (shard-hsw) fdo#103540
> > Test drv_suspend:
> > Subgroup debugfs-reader:
> > pass   -> SKIP   (shard-snb)
> > Test kms_frontbuffer_tracking:
> > Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
> > fail   -> PASS   (shard-snb) fdo#101623
> > Test kms_flip:
> > Subgroup vblank-vs-modeset-suspend:
> > pass   -> INCOMPLETE (shard-hsw)
> >
> > fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
> > fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
> > fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
> >
> > shard-hswtotal:2681 pass:1521 dwarn:1   dfail:0   fail:10  skip:1148
> time:8681s
> > shard-snbtotal:2713 pass:1310 dwarn:1   dfail:0   fail:10  skip:1392
> time:7926s
> > Blacklisted hosts:
> > shard-apltotal:2713 pass:1684 dwarn:1   dfail:0   fail:25  skip:1002
> time:13555s
> > shard-kbltotal:2713 pass:1808 dwarn:1   dfail:0   fail:24  skip:880
> time:10569s
> >
> > == Logs ==
> >
> > For more details see:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7628/shards.html
> 
> kbl results now shown in the text diff but this page shows:
> 
> igt@kms_hdmi_inject@inject-4k  fail -> PASS
This was expected here. Jani N, how do you patch in general?

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Initialise our dynamic sysfs attributes for use with lockdep

[Patchwork]

== Series Details ==

Series: drm/i915/pmu: Initialise our dynamic sysfs attributes for use with 
lockdep
URL   : https://patchwork.freedesktop.org/series/36337/
State : success

== Summary ==

Series 36337v1 drm/i915/pmu: Initialise our dynamic sysfs attributes for use 
with lockdep
https://patchwork.freedesktop.org/api/1.0/series/36337/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
Test kms_chamelium:
Subgroup dp-edid-read:
dmesg-warn -> PASS   (fi-kbl-7500u) fdo#102505
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-kbl-r) fdo#104172 +1

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#102505 https://bugs.freedesktop.org/show_bug.cgi?id=102505
fdo#104172 https://bugs.freedesktop.org/show_bug.cgi?id=104172

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:422s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:485s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:487s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:469s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:458s
fi-cnl-y2total:288  pass:258  dwarn:3   dfail:0   fail:0   skip:27  
time:535s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:274s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:514s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:390s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:400s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:459s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:414s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:465s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:499s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:457s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:505s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:579s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:425s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:532s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:493s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:473s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:527s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:395s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:571s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:471s

d9bbaa0c520357cb67793548f2817ab4de55089b drm-tip: 2018y-01m-11d-12h-31m-18s UTC 
integration manifest
c79818971e71 drm/i915/pmu: Initialise our dynamic sysfs attributes for use with 
lockdep

== Logs ==

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

Re: [Intel-gfx] [PATCH 02/11] drm/i915/cnl: Add Port F definition.

[Paulo Zanoni]

Em Sex, 2017-12-22 às 15:18 -0800, Rodrigo Vivi escreveu:
> Some Cannonlake SKUs will come with a full split between
> port A and port E. This will be called port F although it
> is not a 6th port, but only a split.

I think that a small comment explaining that port F support is still
not complete even with this patch would help.

One more comment below.

> 
> v2: Fix size of dvo_ports found by Ander.
> v3: Adding missing cases from intel_bios.c for Port_F
> v4: Adding other missing cases and fix the commit message.
> v5: Rebase on top of display headers rework.
> 
> Cc: Lucas De Marchi 
> Cc: Manasi Navare 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_bios.c | 9 +
>  drivers/gpu/drm/i915/intel_display.h  | 1 +
>  drivers/gpu/drm/i915/intel_dp.c   | 2 ++
>  drivers/gpu/drm/i915/intel_vbt_defs.h | 2 ++
>  include/drm/i915_component.h  | 3 +--
>  5 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 51108ffc28d1..59a150e2adce 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1140,6 +1140,7 @@ static void parse_ddi_port(struct
> drm_i915_private *dev_priv, enum port port,
>   {DVO_PORT_HDMIC, DVO_PORT_DPC, -1},
>   {DVO_PORT_HDMID, DVO_PORT_DPD, -1},
>   {DVO_PORT_CRT, DVO_PORT_HDMIE, DVO_PORT_DPE},
> + {DVO_PORT_HDMIF, DVO_PORT_DPF, -1},
>   };
>  
>   /*
> @@ -1688,6 +1689,7 @@ bool intel_bios_is_port_present(struct
> drm_i915_private *dev_priv, enum port por
>   [PORT_C] = { DVO_PORT_DPC, DVO_PORT_HDMIC, },
>   [PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, },
>   [PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, },
> + [PORT_F] = { DVO_PORT_DPF, DVO_PORT_HDMIF, },
>   };
>   int i;
>  
> @@ -1726,6 +1728,7 @@ bool intel_bios_is_port_edp(struct
> drm_i915_private *dev_priv, enum port port)
>   [PORT_C] = DVO_PORT_DPC,
>   [PORT_D] = DVO_PORT_DPD,
>   [PORT_E] = DVO_PORT_DPE,
> + [PORT_F] = DVO_PORT_DPF,
>   };
>   int i;
>  
> @@ -1761,6 +1764,7 @@ static bool child_dev_is_dp_dual_mode(const
> struct child_device_config *child,
>   [PORT_C] = { DVO_PORT_DPC, DVO_PORT_HDMIC, },
>   [PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, },
>   [PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, },
> + [PORT_F] = { DVO_PORT_DPF, DVO_PORT_HDMIF, },
>   };
>  
>   if (port == PORT_A || port >= ARRAY_SIZE(port_mapping))
> @@ -1927,6 +1931,11 @@ intel_bios_is_lspcon_present(struct
> drm_i915_private *dev_priv,
>   if (port == PORT_D)
>   return true;
>   break;
> + case DVO_PORT_DPF:
> + case DVO_PORT_HDMIF:
> + if (port == PORT_F)
> + return true;
> + break;
>   default:
>   break;
>   }
> diff --git a/drivers/gpu/drm/i915/intel_display.h
> b/drivers/gpu/drm/i915/intel_display.h
> index a0d2b6169361..e47638931b51 100644
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/intel_display.h
> @@ -119,6 +119,7 @@ enum port {
>   PORT_C,
>   PORT_D,
>   PORT_E,
> + PORT_F,
>  
>   I915_MAX_PORTS
>  };
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index 35c5299feab6..71721de39e6b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1378,6 +1378,7 @@ static i915_reg_t skl_aux_ctl_reg(struct
> drm_i915_private *dev_priv,
>   case PORT_B:
>   case PORT_C:
>   case PORT_D:
> + case PORT_F:
>   return DP_AUX_CH_CTL(port);
>   default:
>   MISSING_CASE(port);
> @@ -1393,6 +1394,7 @@ static i915_reg_t skl_aux_data_reg(struct
> drm_i915_private *dev_priv,
>   case PORT_B:
>   case PORT_C:
>   case PORT_D:
> + case PORT_F:
>   return DP_AUX_CH_DATA(port, index);
>   default:
>   MISSING_CASE(port);
> diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/intel_vbt_defs.h
> index e3d7745a9151..8713e8295957 100644
> --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
> @@ -299,6 +299,8 @@ struct bdb_general_features {
>  #define DVO_PORT_DPA 10
>  #define DVO_PORT_DPE 11  
> /* 193 */
>  #define DVO_PORT_HDMIE   12  
> /* 193 */
> +#define DVO_PORT_DPF 13
> +#define DVO_PORT_HDMIF   14

Needs ones more tab before the number. Besides, I suppose we could "/*
N/A */" or /* Missing from spec */ or something that clarifies that
it's not 

Re: [Intel-gfx] [PATCH 06/11] drm/i915/cnl: Add right GMBUS pin number for HDMI on Port F.

[Paulo Zanoni]

Em Sex, 2017-12-22 às 15:18 -0800, Rodrigo Vivi escreveu:
> On CNP Pin 3 is for misc of Port F usage depending on the
> configuration. For CNL that uses Port F, pin 3 is the one.
> 
> v2: Make it more generic and update commit message.

Reviewed-by: Paulo Zanoni 

> 
> Cc: Anusha Srivatsa 
> Cc: Lucas De Marchi 
> Cc: Manasi Navare 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_hdmi.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index bced7b954d93..6f460c4534fa 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1924,6 +1924,9 @@ static u8 cnp_port_to_ddc_pin(struct
> drm_i915_private *dev_priv,
>   case PORT_D:
>   ddc_pin = GMBUS_PIN_4_CNP;
>   break;
> + case PORT_F:
> + ddc_pin = GMBUS_PIN_3_BXT;
> + break;
>   default:
>   MISSING_CASE(port);
>   ddc_pin = GMBUS_PIN_1_BXT;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/pmu: Initialise our dynamic sysfs attributes for use with lockdep

[Tvrtko Ursulin]

On 11/01/2018 14:04, Chris Wilson wrote:

As we kmalloc our dynamic sysfs attributes, we have to give them an
external static lock_class_key for them to use with lockdep.

Fixes: 109ec558370f ("drm/i915/pmu: Only enumerate available counters in sysfs")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_pmu.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 9139bc8df82b..95ab5e28f5be 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -719,6 +719,7 @@ static const struct attribute_group *i915_pmu_attr_groups[] 
= {
  static struct i915_ext_attribute *
  add_i915_attr(struct i915_ext_attribute *attr, const char *name, u64 config)
  {
+   sysfs_attr_init(>attr.attr);
attr->attr.attr.name = name;
attr->attr.attr.mode = 0444;
attr->attr.show = i915_pmu_event_show;
@@ -731,6 +732,7 @@ static struct perf_pmu_events_attr *
  add_pmu_attr(struct perf_pmu_events_attr *attr, const char *name,
 const char *str)
  {
+   sysfs_attr_init(>attr.attr);
attr->attr.attr.name = name;
attr->attr.attr.mode = 0444;
attr->attr.show = perf_event_sysfs_show;



You beat me to it, after I noticed the report on IRC and started 
digging, just to find sysfs_attr_init, your fix arrived. Thanks!


It looks like a standard way of silencing lockdep for this case, 
although I am not sure what exactly is the purpose of lock class keys in 
sysfs attributes, and what this kind of defeat could also imply.


I planned to do it another loop, iterating the attr array, but I don't 
see how it matters. It would be one static key versus the two. :?


Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [RFC v2 6/8] drm: Handle fbdev emulation in core

[Noralf Trønnes]

Den 11.01.2018 08.45, skrev Daniel Vetter:

On Wed, Jan 10, 2018 at 06:02:38PM +0100, Noralf Trønnes wrote:

Den 09.01.2018 11.38, skrev Daniel Vetter:

On Wed, Jan 03, 2018 at 11:21:08PM +0100, Noralf Trønnes wrote:

Prepare for generic fbdev emulation by letting DRM core work directly
with the fbdev compatibility layer. This is done by adding new fbdev
helper vtable callbacks for restore, hotplug_event, unregister and
release.

Signed-off-by: Noralf Trønnes 

No clue whether my idea is any good, but inspired by the bootsplash
discussion, and the prospect that we might get other in-kernel drm/kms
clients I'm wondering whether we should make this a bit more generic and
tie it to drm_file?

The idea would be to have a list of internal drm clients by putting all
the internal drm_files onto a list (same way we do with the userspace
ones). Then we'd just walk that list and call ->hotplug, ->unregister and
->release at the right places.

->restore would be a bit different, I guess for that we'd only call the
->restore callback of the very first kernel-internal client.

With that we could then add/remove kernel-internal drm clients like normal
userspace clients, which should make integration of emergency consoles,
boot splashes and whatever else real easy. And I think it would be a lot
cleaner than leaking fb_helper knowledge into the drm core, which feels a
rather backwards.

Otoh that feels a bit overengineered (but at least it shouldn't be a lot
more code really). If the list is too much work we could start with 1
drm_file * pointer for internal stuff (but would still need locking, so
list_head is probably easier).

Thoughts?

I prefer to have a proper in-kernel client API from the get go, instead
of fixing it up later. The reason I skipped spending time on it in this
RFC, was that I didn't know if I was on the right track at the right time
to get the necessary attention to make this dumb_buffer idea happen.

With a drm_file centric approach, are you thinking something like this:

  struct drm_device {
+    struct list_head filelist_internal;
  };

+struct drm_file_funcs {
+    int (*restore)(struct drm_file *file);
+    void (*hotplug)(struct drm_file *file);
+    void (*unregister)(struct drm_file *file);

I guess we still need a cleanup callback here? For the usual two-stage
driver unload sequence of 1. unregister 2. cleanup.


There's no need for a cleanup callback in this scenario.
The client holds a ref on drm_device through drm_internal_open() and if
it can't release the drm_file on .unregister, there won't be any cleanup.
When the client is in a position to release drm_file (fb_close), it will
do so and the ref is dropped.

If for some reason we can't take a ref, then we need to use
drm_device.open_count to avoid drm_device going away in drm_dev_unplug().

Noralf.




+};

  struct drm_file {
+    struct drm_device *dev;
+    const struct drm_file_funcs *funcs;
  };

  struct drm_file *drm_file_alloc(struct drm_minor *minor)
  {
+    file->dev = dev;
  }

struct drm_file* drm_internal_open(struct drm_device *dev,
                    const struct drm_file_funcs *funcs)
     struct drm_file *file;
     int ret;

     if (!try_module_get(dev->driver->fops->owner))
         return ERR_PTR(-ENODEV);

     drm_dev_ref(dev);

     file = drm_file_alloc(dev);
     if (IS_ERR(file)) {
         drm_dev_unref(dev);
         module_put(dev->driver->fops->owner);
         return file;
     }

     file->funcs = funcs;

     mutex_lock(>filelist_mutex);
     list_add(>lhead, >filelist_internal);
     mutex_unlock(>filelist_mutex);

     return file;
}

void drm_internal_release(struct drm_file *file)
{
     struct drm_device *dev = file->dev;

     mutex_lock(>filelist_mutex);
     list_del(>lhead);
     mutex_unlock(>filelist_mutex);

     drm_file_free(file);
     drm_dev_unref(dev);
     module_put(dev->driver->fops->owner);
}

  void drm_lastclose(struct drm_device *dev)
  {

+    mutex_lock(>filelist_mutex);
+    list_for_each_entry(file, >filelist_internal, lhead) {
+        if (file->funcs && file->funcs->restore &&
+            !file->funcs->restore(file))
+                break;
+    mutex_unlock(>filelist_mutex);
  }

  void drm_kms_helper_hotplug_event(struct drm_device *dev)
  {

+    mutex_lock(>filelist_mutex);
+    list_for_each_entry(file, >filelist_internal, lhead) {
+        if (file->funcs && file->funcs->hotplug)
+            file->funcs->hotplug(file);
+    mutex_unlock(>filelist_mutex);
  }

How is locking done when .unregister will call into drm_internal_release()?

  void drm_dev_unregister(struct drm_device *dev)
  {

+    list_for_each_entry(file, >filelist_internal, lhead) {
+        if (file->funcs && file->funcs->unregister)
+            file->funcs->unregister(file);
  }

There is also the case where .unregister can't release the drm_file
because userspace has mmap'ed the buffer (fbdev). The client holds a ref
on drm_device so cleanup is stalled but that requires 

[Intel-gfx] [PATCH] drm/i915/pmu: Initialise our dynamic sysfs attributes for use with lockdep

[Chris Wilson]

As we kmalloc our dynamic sysfs attributes, we have to give them an
external static lock_class_key for them to use with lockdep.

Fixes: 109ec558370f ("drm/i915/pmu: Only enumerate available counters in sysfs")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_pmu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 9139bc8df82b..95ab5e28f5be 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -719,6 +719,7 @@ static const struct attribute_group *i915_pmu_attr_groups[] 
= {
 static struct i915_ext_attribute *
 add_i915_attr(struct i915_ext_attribute *attr, const char *name, u64 config)
 {
+   sysfs_attr_init(>attr.attr);
attr->attr.attr.name = name;
attr->attr.attr.mode = 0444;
attr->attr.show = i915_pmu_event_show;
@@ -731,6 +732,7 @@ static struct perf_pmu_events_attr *
 add_pmu_attr(struct perf_pmu_events_attr *attr, const char *name,
 const char *str)
 {
+   sysfs_attr_init(>attr.attr);
attr->attr.attr.name = name;
attr->attr.attr.mode = 0444;
attr->attr.show = perf_event_sysfs_show;
-- 
2.15.1

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/1] tools: Update .gitignore

[Patchwork]

== Series Details ==

Series: series starting with [1/1] tools: Update .gitignore
URL   : https://patchwork.freedesktop.org/series/36322/
State : failure

== Summary ==

IGT patchset tested on top of latest successful build
d37369c7146a2ceb332592297d311d501c1c748e Revert "build: make meson more 
official" damage

with latest DRM-Tip kernel build CI_DRM_3621
d9bbaa0c5203 drm-tip: 2018y-01m-11d-12h-31m-18s UTC integration manifest

No testlist changes.

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test gem_exec_flush:
Subgroup basic-uc-pro-default:
pass   -> INCOMPLETE (fi-cnl-y2)
Test kms_chamelium:
Subgroup dp-edid-read:
dmesg-warn -> PASS   (fi-kbl-7500u) fdo#102505
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-kbl-r) fdo#104172 +1

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#102505 https://bugs.freedesktop.org/show_bug.cgi?id=102505
fdo#104172 https://bugs.freedesktop.org/show_bug.cgi?id=104172

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:411s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:361s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:444s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:260s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:463s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:464s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:430s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:427s
fi-cnl-y2total:53   pass:45   dwarn:0   dfail:0   fail:0   skip:7  
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:247s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:496s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:383s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:392s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:403s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:448s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:401s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:456s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:498s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:442s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:490s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:422s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:516s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:465s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:419s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:387s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:557s
fi-glk-dsi   total:288  pass:257  dwarn:0   dfail:0   fail:1   skip:30  
time:453s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for build: make meson more official

[Patchwork]

== Series Details ==

Series: build: make meson more official
URL   : https://patchwork.freedesktop.org/series/36320/
State : failure

== Summary ==

Applying: build: make meson more official
Using index info to reconstruct a base tree...
M   CONTRIBUTING
M   NEWS
M   README
M   meson.sh
Falling back to patching base and 3-way merge...
Auto-merging README
CONFLICT (content): Merge conflict in README
Auto-merging CONTRIBUTING
CONFLICT (content): Merge conflict in CONTRIBUTING
Patch failed at 0001 build: make meson more official
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] tests/perf_pmu: Verify busyness when PMU is enabled after engine got busy (rev3)

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/2] tests/perf_pmu: Verify busyness when PMU 
is enabled after engine got busy (rev3)
URL   : https://patchwork.freedesktop.org/series/36201/
State : failure

== Summary ==

IGT patchset tested on top of latest successful build
d37369c7146a2ceb332592297d311d501c1c748e Revert "build: make meson more 
official" damage

with latest DRM-Tip kernel build CI_DRM_3621
d9bbaa0c5203 drm-tip: 2018y-01m-11d-12h-31m-18s UTC integration manifest

Testlist changes:
+igt@perf_pmu@busy-double-start-bcs0
+igt@perf_pmu@busy-double-start-rcs0
+igt@perf_pmu@busy-double-start-vcs0
+igt@perf_pmu@busy-double-start-vcs1
+igt@perf_pmu@busy-double-start-vecs0
+igt@perf_pmu@busy-start-bcs0
+igt@perf_pmu@busy-start-rcs0
+igt@perf_pmu@busy-start-vcs0
+igt@perf_pmu@busy-start-vcs1
+igt@perf_pmu@busy-start-vecs0

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test gem_ringfill:
Subgroup basic-default:
pass   -> INCOMPLETE (fi-cnl-y2)
Test kms_chamelium:
Subgroup dp-edid-read:
dmesg-warn -> PASS   (fi-kbl-7500u) fdo#102505

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#102505 https://bugs.freedesktop.org/show_bug.cgi?id=102505

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:410s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:414s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:359s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:451s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:262s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:461s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:469s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:432s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:423s
fi-cnl-y2total:142  pass:130  dwarn:0   dfail:0   fail:0   skip:11 
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:245s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:501s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:382s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:392s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:404s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:449s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:403s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:458s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:492s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:443s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:494s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:488s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:414s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:497s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:519s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:465s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:423s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:526s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:391s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:563s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:452s

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Reinitialize sink scrambling/TMDS clock ratio on HPD

[Sharma, Shashank]

Regards

Shashank


On 1/10/2018 9:53 PM, Ville Syrjälä wrote:

On Wed, Jan 10, 2018 at 10:07:43AM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 1/9/2018 11:31 PM, Ville Syrjälä wrote:

On Thu, Dec 28, 2017 at 08:32:05PM +0530, Sharma, Shashank wrote:

On 12/22/2017 11:58 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

The LG 4k TV I have doesn't deassert HPD when I turn the TV off, but
when I turn it back on it will pulse the HPD line. By that time it has
forgotten everything we told it about scrambling and the clock ratio.
Hence if we want to get a picture out if it again we have to tell it
whether we're currently sending scrambled data or not. Implement
that via the encoder->post_hotplug() hook.

I am not sure if I understood the problem statement correctly. Even if
the TV triggers HPD line while turning it back, I would expect:
- EDID read for TV's detection, which will refresh SCDC and scrambling
capabilities
- A new modeset will be triggered, which will program the scrambling and
high tmds clock ratio again
- Once HDMI controller is programmed, it will generate scrambled signals
till next modeset / disable.

So why do we need to do this ? I might be missing something, but lets
discus about it.

The EDID is readable even when the HPD gets deasserted for a short
perios, hence we never consider the sink as being disconnected. Hence
there will be no modeset triggered by userspace.

This is a bigger problem then, in that case, the pipe/port would be
enabled, and IMHO I don't think fixing just the scrambling status is
right thing to do.

Hmm. The spec does say "the Source shall not begin transmission of a
scrambled video signal before writing a 1 to the Scrambling_Enable bit".
So I guess you're right. We can't follow that rule 100% though because
we can't detect that the the sink has been turned off.

If we checked the live hpd status during hpd processing we should be
able to detect that the sink was logically disconnected for a short
period, but as we know the live hpd status is not exactly reliable
for HDMI. Also that would still be racy on account of hpd processing
delays.
Agree. This inaccuracy of Live status HW has been a nightmare for us 
since a long time,

it really cripples proper hotplug handling.


When talking about the TMDS clock ratio the spec says that we have to
suspend TMDS clock/data transmission when we change the TMDS clock ratio
setting in the sink.

So I guess what we could do is force a full modeset if and when the sink
has become confused about these settings. Or if we want to optimize
things a bit I suppose we could just turn off DDI_BUF_CTL around the
operation. But probably no point in optimizing that part since it's a
rare event.
Agree, again. Also it would be difficult to detect exactly when do we 
have a genuine confusion :-)


- Shashank



Also, is this the right behavior from the monitor ? I am also worried if
we are trying to fix the monitor's fault in our driver.

I don't think that's specified anywhere. Also doesn't matter because we
have to fix sink specific issues in the driver all the time. Otherwise
a lot of sinks would just fail to work.



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

Re: [Intel-gfx] [PATCH v2] x86/gpu: add CFL to early quirks

[Timo Aaltonen]

On 15.12.2017 23:19, Rodrigo Vivi wrote:
> On Fri, Dec 15, 2017 at 04:39:25PM +, Ingo Molnar wrote:
>>
>> * Lucas De Marchi  wrote:
>>
>>> CFL was missing from intel_early_ids[]. The PCI ID needs to be there to
>>> allow the memory region to be stolen, otherwise we could have RAM being
>>> arbitrarily overwritten if for example we keep using the UEFI framebuffer,
>>> depending on how BIOS has set up the e820 map.
>>>
>>> Fixes: b056f8f3d6b9 ("drm/i915/cfl: Add Coffee Lake PCI IDs for S Skus.")
>>> Signed-off-by: Lucas De Marchi 
>>> Cc: Rodrigo Vivi 
>>> Cc: Anusha Srivatsa 
>>> Cc: Jani Nikula 
>>> Cc: Joonas Lahtinen 
>>> Cc: David Airlie 
>>> Cc: intel-gfx@lists.freedesktop.org
>>> Cc: dri-de...@lists.freedesktop.org
>>> Cc: Ingo Molnar 
>>> Cc: H. Peter Anvin 
>>> Cc: Thomas Gleixner 
>>> Cc: x...@kernel.org
>>> Cc:  # v4.13+ 0890540e21cf drm/i915: add GT number 
>>> to intel_device_info
>>> Cc:  # v4.13+ 41693fd52373 drm/i915/kbl: Change a 
>>> KBL pci id to GT2 from GT1.5
>>> Cc:  # v4.13+
>>> Reviewed-by: Rodrigo Vivi 
>>> ---
>>>
>>> v2: improve commit message, add Fixes tag and CC stable
>>>
>>>  arch/x86/kernel/early-quirks.c | 1 +
>>>  include/drm/i915_pciids.h  | 6 ++
>>>  2 files changed, 7 insertions(+)
>>
>> Acked-by: Ingo Molnar 
> 
> Merged to drm-intel-next-queued.
> Thanks for the patches, suggestions and acks.

Shouldn't this go to v4.15 as well, because CFL is enabled there? I
don't see it in rc8.

___
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: expose rcs topology through query uAPI

[Tvrtko Ursulin]

On 18/12/2017 15:35, Lionel Landwerlin wrote:

With the introduction of asymetric slices in CNL, we cannot rely on


asymmetric


the previous SUBSLICE_MASK getparam to tell userspace what subslices
are available. Here we introduce a more detailed way of querying the
Gen's GPU topology that doesn't aggregate numbers.

This is essential for monitoring parts of the GPU with the OA unit,
because counters need to be normalized to the number of
EUs/subslices/slices. The current aggregated numbers like EU_TOTAL do
not gives us sufficient information.

As a bonus we can draw representations of the GPU :

 https://imgur.com/a/vuqpa

Signed-off-by: Lionel Landwerlin 
---
  drivers/gpu/drm/i915/i915_query.c   | 134 
  drivers/gpu/drm/i915/intel_query_info.c |  88 +
  include/uapi/drm/i915_drm.h |  45 +++
  3 files changed, 267 insertions(+)
  create mode 100644 drivers/gpu/drm/i915/intel_query_info.c

diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c
index 227a28978190..7c0eb09d3aac 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -25,24 +25,158 @@
  #include "i915_drv.h"
  #include 
  
+static int query_slices_mask(struct drm_i915_private *dev_priv,

+struct drm_i915_query_item *query_item)
+{
+   const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+   struct drm_i915_query_slices_mask slices_info;
+   u32 data_length, length;
+
+   if (sseu->max_slices == 0)
+   return -ENODEV;


Do you need to handle this explicitly or just return all zeros? I guess 
I don't know which GPUs have zero slices.



+
+   memset(_info, 0, sizeof(slices_info));


Is this needed since a) you will write to the only field just below, and 
b) it won't clear the tail data array anyway?



+
+   slices_info.n_slices = sseu->max_slices;

Move to after the query_item->length checks.


+
+   data_length = sizeof(u8);


Size is dependant on number of slices? DIV_ROUND_UP(n_slices, 
BITS_PER_BYTE) ?



+   length = sizeof(struct drm_i915_query_slices_mask) + data_length;


sizeof(slices_info)


+
+   /*
+* If we ever change the internal slice mask data type, we'll need to
+* update this function.
+*/
+   BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask));


Hm a bit weak since it is not only about size but also data 
representation. But I don't have any better ideas.



+
+   if (query_item->length == 0) {
+   query_item->length = length;
+   return 0;
+   }
+
+   if (query_item->length != length)
+   return -EINVAL;
+
+   if (copy_to_user(u64_to_user_ptr(query_item->data_ptr), _info,
+sizeof(slices_info)))
+   return -EFAULT;
+
+   if (copy_to_user(u64_to_user_ptr(query_item->data_ptr +
+offsetof(struct 
drm_i915_query_slices_mask, data)),
+>slice_mask, data_length))
+   return -EFAULT;
+
+   return 0;
+}


Some of the above comments also apply to the other two query functions 
below.



+static int query_subslices_mask(struct drm_i915_private *dev_priv,
+   struct drm_i915_query_item *query_item)
+{
+   const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+   struct drm_i915_query_subslices_mask subslices_info;
+   u32 data_length, length;
+
+   if (sseu->max_slices == 0)
+   return -ENODEV;
+
+   memset(_info, 0, sizeof(subslices_info));
+
+   subslices_info.n_slices = sseu->max_slices;
+   subslices_info.slice_stride = ALIGN(sseu->max_subslices, 8) / 8;
+
+   data_length = subslices_info.n_slices * subslices_info.slice_stride;
+   length = sizeof(struct drm_i915_query_subslices_mask) + data_length;
+
+   if (query_item->length == 0) {
+   query_item->length = length;
+   return 0;
+   }
+
+   if (query_item->length != length)
+   return -EINVAL;
+
+   if (copy_to_user(u64_to_user_ptr(query_item->data_ptr), _info,
+sizeof(subslices_info)))
+   return -EFAULT;
+
+   if (copy_to_user(u64_to_user_ptr(query_item->data_ptr +
+offsetof(struct 
drm_i915_query_subslices_mask, data)),
+sseu->subslices_mask, data_length))
+   return -EFAULT;
+
+   return 0;
+}
+
+static int query_eus_mask(struct drm_i915_private *dev_priv,
+ struct drm_i915_query_item *query_item)
+{
+   const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+   struct drm_i915_query_eus_mask eus_info;
+   u32 data_length, length;
+
+   if (sseu->max_slices == 0)
+   return -ENODEV;
+
+   memset(_info, 0, 

Re: [Intel-gfx] [PATCH 5/6] drm/i915: add query uAPI

[Tvrtko Ursulin]

On 18/12/2017 15:35, Lionel Landwerlin wrote:

There are a number of information that are readable from hardware
registers and that we would like to make accessible to userspace. One
particular example is the topology of the execution units (how are
execution units grouped in subslices and slices and also which ones
have been fused off for die recovery).

At the moment the GET_PARAM ioctl covers some basic needs, but
generally is only able to return a single value for each defined
parameter. This is a bit problematic with topology descriptions which
are array/maps of available units.

This change introduces a new ioctl that can deal with requests to fill
structures of potentially variable lengths. The user is expected fill
a query with length fields set at 0 on the first call, the kernel then
sets the length fields to the their expected values. A second call to
the kernel with length fields at their expected values will trigger a
copy of the data to the pointed memory locations.

The scope of this uAPI is only to provide information to userspace,
not to allow configuration of the device.

Signed-off-by: Lionel Landwerlin 
---
  drivers/gpu/drm/i915/Makefile |  1 +
  drivers/gpu/drm/i915/i915_drv.c   |  1 +
  drivers/gpu/drm/i915/i915_drv.h   |  3 +++
  drivers/gpu/drm/i915/i915_query.c | 52 +++
  include/uapi/drm/i915_drm.h   | 31 +++
  5 files changed, 88 insertions(+)
  create mode 100644 drivers/gpu/drm/i915/i915_query.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 091aef281963..9627e7e309dc 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -69,6 +69,7 @@ i915-y += i915_cmd_parser.o \
  i915_gem_timeline.o \
  i915_gem_userptr.o \
  i915_gemfs.o \
+ i915_query.o \
  i915_trace_points.o \
  i915_vma.o \
  intel_breadcrumbs.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8b99e415c345..a90ed9f2b759 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2814,6 +2814,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, i915_perf_add_config_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG, 
i915_perf_remove_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_QUERY, i915_query_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
  };
  
  static struct drm_driver driver = {

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 82fc59078c6a..3415a3d2399c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4084,6 +4084,9 @@ 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_query.c */

+int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file 
*file);
+
  /* 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_query.c 
b/drivers/gpu/drm/i915/i915_query.c
new file mode 100644
index ..227a28978190
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -0,0 +1,52 @@
+/*
+ * 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"
+#include 
+
+int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file *file)
+{
+   struct drm_i915_query *args = data;


An alternative I think could be:

struct 

Re: [Intel-gfx] [PATCH i-g-t 1/2] test/gem_ctx_param - Use the last I915_CONTEXT_PARAM+1 for invalid tests

[Lofstedt, Marta]

> -Original Message-
> From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
> Sent: Thursday, January 11, 2018 1:46 PM
> To: Lofstedt, Marta ; intel-
> g...@lists.freedesktop.org
> Cc: Chris Wilson 
> Subject: Re: [Intel-gfx] [PATCH i-g-t 1/2] test/gem_ctx_param - Use the last
> I915_CONTEXT_PARAM+1 for invalid tests
> 
> 
> On 11/01/2018 11:38, Marta Lofstedt wrote:
> > The invalid-param-[get|set] exploits the last I915_CONTEXT_PARAM + 1,
> > to check for ABI extentsions. However, the last param was set to
> > I915_CONTEXT_PARAM_BANNABLE, so when
> I915_CONTEXT_PARAM_PRIORITY was
> > added to the next enum, the test started failing.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103107
> > Signed-off-by: Marta Lofstedt 
> > ---
> >   tests/gem_ctx_param.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tests/gem_ctx_param.c b/tests/gem_ctx_param.c index
> > c20ae1ee..75d2a20f 100644
> > --- a/tests/gem_ctx_param.c
> > +++ b/tests/gem_ctx_param.c
> > @@ -140,7 +140,7 @@ igt_main
> >  * to catch ABI extensions. Don't "fix" this testcase without
> adding all
> >  * the tests for the new param first.
> >  */
> > -   arg.param = I915_CONTEXT_PARAM_BANNABLE + 1;
> > +   arg.param = I915_CONTEXT_PARAM_PRIORITY + 1;
> >
> > igt_subtest("invalid-param-get") {
> > arg.ctx_id = ctx;
> >
> 
> We tried before, last time AFAIR
> https://patchwork.freedesktop.org/patch/187073/, but again AFAIR I think
> Chris objected and would rather remove negative tests in general. Shrug, an
> impasse. :I
> 
Well, then maybe V2 will be to remove these test ;)

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

Re: [Intel-gfx] [PATCH i-g-t 1/2] test/gem_ctx_param - Use the last I915_CONTEXT_PARAM+1 for invalid tests

[Tvrtko Ursulin]

On 11/01/2018 11:38, Marta Lofstedt wrote:

The invalid-param-[get|set] exploits the last I915_CONTEXT_PARAM + 1,
to check for ABI extentsions. However, the last param was set to
I915_CONTEXT_PARAM_BANNABLE, so when I915_CONTEXT_PARAM_PRIORITY was
added to the next enum, the test started failing.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103107
Signed-off-by: Marta Lofstedt 
---
  tests/gem_ctx_param.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/gem_ctx_param.c b/tests/gem_ctx_param.c
index c20ae1ee..75d2a20f 100644
--- a/tests/gem_ctx_param.c
+++ b/tests/gem_ctx_param.c
@@ -140,7 +140,7 @@ igt_main
 * to catch ABI extensions. Don't "fix" this testcase without adding all
 * the tests for the new param first.
 */
-   arg.param = I915_CONTEXT_PARAM_BANNABLE + 1;
+   arg.param = I915_CONTEXT_PARAM_PRIORITY + 1;
  
  	igt_subtest("invalid-param-get") {

arg.ctx_id = ctx;



We tried before, last time AFAIR 
https://patchwork.freedesktop.org/patch/187073/, but again AFAIR I think 
Chris objected and would rather remove negative tests in general. Shrug, 
an impasse. :I


Regards,

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

[Intel-gfx] [PATCH i-g-t 1/2] test/gem_ctx_param - Use the last I915_CONTEXT_PARAM+1 for invalid tests

[Marta Lofstedt]

The invalid-param-[get|set] exploits the last I915_CONTEXT_PARAM + 1,
to check for ABI extentsions. However, the last param was set to
I915_CONTEXT_PARAM_BANNABLE, so when I915_CONTEXT_PARAM_PRIORITY was
added to the next enum, the test started failing.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103107
Signed-off-by: Marta Lofstedt 
---
 tests/gem_ctx_param.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/gem_ctx_param.c b/tests/gem_ctx_param.c
index c20ae1ee..75d2a20f 100644
--- a/tests/gem_ctx_param.c
+++ b/tests/gem_ctx_param.c
@@ -140,7 +140,7 @@ igt_main
 * to catch ABI extensions. Don't "fix" this testcase without adding all
 * the tests for the new param first.
 */
-   arg.param = I915_CONTEXT_PARAM_BANNABLE + 1;
+   arg.param = I915_CONTEXT_PARAM_PRIORITY + 1;
 
igt_subtest("invalid-param-get") {
arg.ctx_id = ctx;
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH 3/6] drm/i915/debugfs: add rcs topology entry

[Tvrtko Ursulin]

On 18/12/2017 15:35, Lionel Landwerlin wrote:

While the end goal is to make this information available to userspace
through a new ioctl, there is no reason we can't display it in a human
readable fashion through debugfs.

slice0 (subslice_mask=0x7):


I'd add a subslice count while at it, since the eu lines have counts.

Bike-shedding on whether counts or masks are typically more important?

Slice0: 3 slices (0x7):
Subslice 0: 8 EUs (0xff)
Subslice 1: 8 EUs (0xff)
...

?


subslice0:
eu_mask: 0xff (8)
subslice1:
eu_mask: 0xff (8)
subslice2:
eu_mask: 0xff (8)
subslice3:
eu_mask: 0x0 (0)
slice1 (subslice_mask=0x7):
subslice0:
eu_mask: 0xff (8)
subslice1:
eu_mask: 0xff (8)
subslice2:
eu_mask: 0xff (8)
subslice3:
eu_mask: 0x0 (0)
slice2 (subslice_mask=0x7):
subslice0:
eu_mask: 0xff (8)
subslice1:
eu_mask: 0xff (8)
subslice2:
eu_mask: 0xff (8)
subslice3:
eu_mask: 0x0 (0)

Suggested-by: Chris Wilson 
Signed-off-by: Lionel Landwerlin 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 37 +
  1 file changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6ec7543e698f..79ca6e9f9ec9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3173,6 +3173,42 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
return 0;
  }
  
+static int i915_rcs_topology(struct seq_file *m, void *unused)

+{
+   struct drm_i915_private *dev_priv = node_to_i915(m->private);
+   const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
+   int s, ss;
+   int subslice_stride = ALIGN(sseu->max_eus_per_subslice, 8) / 8;
+   int slice_stride = sseu->max_subslices * subslice_stride;


Another case for the before mentioned helper for indexing into eu_mask 
array?



+
+   if (sseu->max_slices == 0) {
+   seq_printf(m, "Unavailable\n");
+   return 0;
+   }


Is this possible?


+
+   for (s = 0; s < sseu->max_slices; s++) {
+   seq_printf(m, "slice%i (subslice_mask=0x%x):\n",


%i always confuses me. Googling shows it is equivalent to %d for 
printing? Or is it something different in kernel space? If it is 
equivalent I would go with a more standard one. And I would even change 
to unsigned variables for iterators but I realize some people have a 
different opinion so up to you.



+  s, sseu->subslices_mask[s]);
+
+   for (ss = 0; ss < slice_stride / subslice_stride; ss++) {


With the indexing helpers hopefully it would be possible to simply 
iterate to hweight8(sseu->sublice_mask[s]) ?



+   int eu, n_subslice_eus = 0;
+
+   seq_printf(m, "\tsubslice%i:\n", ss);
+
+   seq_printf(m, "\t\teu_mask:");
+   for (eu = 0; eu < subslice_stride; eu++) {
+   u8 val = sseu->eu_mask[s * slice_stride +
+  ss * subslice_stride + 
eu];
+   seq_printf(m, " 0x%x", val);
+   n_subslice_eus += hweight8(val);
+   }
+   seq_printf(m, " (%i)\n", n_subslice_eus);
+   }
+   }
+
+   return 0;
+}
+
  static int i915_shrinker_info(struct seq_file *m, void *unused)
  {
struct drm_i915_private *i915 = node_to_i915(m->private);
@@ -4658,6 +4694,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_dmc_info", i915_dmc_info, 0},
{"i915_display_info", i915_display_info, 0},
{"i915_engine_info", i915_engine_info, 0},
+   {"i915_rcs_topology", i915_rcs_topology, 0},
{"i915_shrinker_info", i915_shrinker_info, 0},
{"i915_shared_dplls_info", i915_shared_dplls_info, 0},
{"i915_dp_mst_info", i915_dp_mst_info, 0},



Regards,

Tvrtko
___
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/debugfs: reuse max slice/subslices already stored in sseu

[Tvrtko Ursulin]

On 18/12/2017 15:35, Lionel Landwerlin wrote:

Now that we have that information in topology fields, let's just reused it.

Signed-off-by: Lionel Landwerlin 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 26 ++
  1 file changed, 10 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0c7890b695c5..6ec7543e698f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4308,11 +4308,11 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 struct sseu_dev_info *sseu)
  {
const struct intel_device_info *info = INTEL_INFO(dev_priv);
-   int s_max = 6, ss_max = 4;
int s, ss;
-   u32 s_reg[s_max], eu_reg[2 * s_max], eu_mask[2];
+   u32 s_reg[info->sseu.max_slices],
+   eu_reg[2 * info->sseu.max_subslices], eu_mask[2];


This is a bit unusual style, perhaps split into separate declarations.

  
-	for (s = 0; s < s_max; s++) {

+   for (s = 0; s < info->sseu.max_slices; s++) {
/*
 * FIXME: Valid SS Mask respects the spec and read
 * only valid bits for those registers, excluding reserverd
@@ -4334,7 +4334,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
 GEN9_PGCTL_SSB_EU210_ACK |
 GEN9_PGCTL_SSB_EU311_ACK;
  
-	for (s = 0; s < s_max; s++) {

+   for (s = 0; s < info->sseu.max_slices; s++) {
if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
/* skip disabled slice */
continue;
@@ -4342,7 +4342,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask |= BIT(s);
sseu->subslices_mask[s] = info->sseu.subslices_mask[s];
  
-		for (ss = 0; ss < ss_max; ss++) {

+   for (ss = 0; ss < info->sseu.max_subslices; ss++) {
unsigned int eu_cnt;
  
  			if (!(s_reg[s] & (GEN9_PGCTL_SS_ACK(ss

@@ -4362,17 +4362,11 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
  static void gen9_sseu_device_status(struct drm_i915_private *dev_priv,
struct sseu_dev_info *sseu)
  {
-   int s_max = 3, ss_max = 4;
+   const struct intel_device_info *info = INTEL_INFO(dev_priv);
int s, ss;
-   u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
-
-   /* BXT has a single slice and at most 3 subslices. */
-   if (IS_GEN9_LP(dev_priv)) {
-   s_max = 1;
-   ss_max = 3;
-   }
+   u32 s_reg[info->sseu.max_slices], eu_reg[2*info->sseu.max_subslices], 
eu_mask[2];


Spaces around operators are preferred.

  
-	for (s = 0; s < s_max; s++) {

+   for (s = 0; s < info->sseu.max_slices; s++) {
s_reg[s] = I915_READ(GEN9_SLICE_PGCTL_ACK(s));
eu_reg[2*s] = I915_READ(GEN9_SS01_EU_PGCTL_ACK(s));
eu_reg[2*s + 1] = I915_READ(GEN9_SS23_EU_PGCTL_ACK(s));
@@ -4387,7 +4381,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
 GEN9_PGCTL_SSB_EU210_ACK |
 GEN9_PGCTL_SSB_EU311_ACK;
  
-	for (s = 0; s < s_max; s++) {

+   for (s = 0; s < info->sseu.max_slices; s++) {
if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
/* skip disabled slice */
continue;
@@ -4398,7 +4392,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->subslices_mask[s] =
INTEL_INFO(dev_priv)->sseu.subslices_mask[s];
  
-		for (ss = 0; ss < ss_max; ss++) {

+   for (ss = 0; ss < info->sseu.max_subslices; ss++) {
unsigned int eu_cnt;
  
  			if (IS_GEN9_LP(dev_priv)) {




With the formatting tweaks,

Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [PATCH 1/6] drm/i915: store all subslice masks

[Tvrtko Ursulin]

On 18/12/2017 15:35, Lionel Landwerlin wrote:

Up to now, subslice mask was assumed to be uniform across slices. But
starting with Cannonlake, slices can be asymetric (for example slice0


asymmetric, thanks auto spell checker. :)


has different number of subslices as slice1+). This change stores all
subslices masks for all slices rather than having a single mask that
applies to all slices.

Signed-off-by: Lionel Landwerlin 
---
  drivers/gpu/drm/i915/i915_debugfs.c  |  24 +++--
  drivers/gpu/drm/i915/i915_drv.c  |   2 +-
  drivers/gpu/drm/i915/i915_drv.h  |  23 -
  drivers/gpu/drm/i915/intel_device_info.c | 169 ++-
  drivers/gpu/drm/i915/intel_lrc.c |   2 +-
  drivers/gpu/drm/i915/intel_ringbuffer.h  |   2 +-
  6 files changed, 161 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0ddce72552bf..0c7890b695c5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4293,7 +4293,7 @@ static void cherryview_sseu_device_status(struct 
drm_i915_private *dev_priv,
continue;
  
  		sseu->slice_mask = BIT(0);

-   sseu->subslice_mask |= BIT(ss);
+   sseu->subslices_mask[0] |= BIT(ss);
eu_cnt = ((sig1[ss] & CHV_EU08_PG_ENABLE) ? 0 : 2) +
 ((sig1[ss] & CHV_EU19_PG_ENABLE) ? 0 : 2) +
 ((sig1[ss] & CHV_EU210_PG_ENABLE) ? 0 : 2) +
@@ -4340,7 +4340,7 @@ static void gen10_sseu_device_status(struct 
drm_i915_private *dev_priv,
continue;
  
  		sseu->slice_mask |= BIT(s);

-   sseu->subslice_mask = info->sseu.subslice_mask;
+   sseu->subslices_mask[s] = info->sseu.subslices_mask[s];
  
  		for (ss = 0; ss < ss_max; ss++) {

unsigned int eu_cnt;
@@ -4395,8 +4395,8 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask |= BIT(s);
  
  		if (IS_GEN9_BC(dev_priv))

-   sseu->subslice_mask =
-   INTEL_INFO(dev_priv)->sseu.subslice_mask;
+   sseu->subslices_mask[s] =
+   INTEL_INFO(dev_priv)->sseu.subslices_mask[s];
  
  		for (ss = 0; ss < ss_max; ss++) {

unsigned int eu_cnt;
@@ -4406,7 +4406,7 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
/* skip disabled subslice */
continue;
  
-sseu->subslice_mask |= BIT(ss);

+   sseu->subslices_mask[s] |= BIT(ss);
}
  
  			eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] &

@@ -4428,9 +4428,12 @@ static void broadwell_sseu_device_status(struct 
drm_i915_private *dev_priv,
sseu->slice_mask = slice_info & GEN8_LSLICESTAT_MASK;
  
  	if (sseu->slice_mask) {

-   sseu->subslice_mask = INTEL_INFO(dev_priv)->sseu.subslice_mask;
sseu->eu_per_subslice =
INTEL_INFO(dev_priv)->sseu.eu_per_subslice;
+   for (s = 0; s < fls(sseu->slice_mask); s++) {
+   sseu->subslices_mask[s] =
+   INTEL_INFO(dev_priv)->sseu.subslices_mask[s];
+   }
sseu->eu_total = sseu->eu_per_subslice *
 sseu_subslice_total(sseu);
  
@@ -4449,6 +4452,7 @@ static void i915_print_sseu_info(struct seq_file *m, bool is_available_info,

  {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
const char *type = is_available_info ? "Available" : "Enabled";
+   int s;
  
  	seq_printf(m, "  %s Slice Mask: %04x\n", type,

   sseu->slice_mask);
@@ -4456,10 +4460,10 @@ static void i915_print_sseu_info(struct seq_file *m, 
bool is_available_info,
   hweight8(sseu->slice_mask));
seq_printf(m, "  %s Subslice Total: %u\n", type,
   sseu_subslice_total(sseu));
-   seq_printf(m, "  %s Subslice Mask: %04x\n", type,
-  sseu->subslice_mask);
-   seq_printf(m, "  %s Subslice Per Slice: %u\n", type,
-  hweight8(sseu->subslice_mask));
+   for (s = 0; s < fls(sseu->slice_mask); s++) {


Slice mask is always contiguous bits?


+   seq_printf(m, "  %s Slice%i Subslice Mask: %04x\n", type,
+  s, sseu->subslices_mask[s]);


Don't want to keep printing the count? Like maybe " %s Slice%u %u 
sublices, mask=%04x\n" ?



+   }
seq_printf(m, "  %s EU Total: %u\n", type,
   sseu->eu_total);
seq_printf(m, "  %s EU Per Subslice: %u\n", type,
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 72bea281edb7..8b99e415c345 100644
--- 

Re: [Intel-gfx] [PATCH i-g-t] build: make meson more official

[Daniel Vetter]

On Thu, Jan 11, 2018 at 9:58 AM, Petri Latvala  wrote:
> On Thu, Jan 11, 2018 at 09:51:40AM +0100, Daniel Vetter wrote:
>> I also noticed that meson.sh doesn't set the prefix for patch
>> submission. Fix that (even thought hopefully real soon igt will move
>> to its own list).
>>
>> Cc: Petri Latvala 
>> Cc: Arkadiusz Hiler 
>> Signed-off-by: Daniel Vetter 
>> ---
>>  CONTRIBUTING |  2 +-
>>  NEWS |  6 ++
>>  README   | 17 -
>>  meson.sh |  2 ++
>>  4 files changed, 21 insertions(+), 6 deletions(-)
>>
>> diff --git a/CONTRIBUTING b/CONTRIBUTING
>> index 561c5dd80bba..0d70346526d3 100644
>> --- a/CONTRIBUTING
>> +++ b/CONTRIBUTING
>> @@ -12,7 +12,7 @@ A short list of contribution guidelines:
>>
>>Please use --subject-prefix="PATCH i-g-t" so that i-g-t patches are easily
>>identified in the massive amount mails on intel-gfx. To ensure this is 
>> always
>> -  done, autogen.sh will run:
>> +  done, meson.sh will run:
>
>
> We still support both build systems, so mention both autogen.sh and
> meson.sh here.
>
>
>>
>>  git config format.subjectprefix "PATCH i-g-t"
>>
>> diff --git a/NEWS b/NEWS
>> index b6d0958228ab..885c1baf3691 100644
>> --- a/NEWS
>> +++ b/NEWS
>> @@ -1,3 +1,9 @@
>> +Release 1.21
>> +
>> +
>> +- Upgrade meson to official production status, automake is still kept 
>> around for
>> +  now.
>> +
>
> Building up the release notes as-we-go, wonderful. But I wonder if the
> upcoming stuff should be placed elsewhere while 1.21 doesn't yet
> exist, to avoid confusion.
>
> Maybe have the title of the section be:
>
> Release 1.21 (not yet released)

In the past I think we've used (-XX-XX) for that. And yes I've
always tried to build up the release notes as we go, and encouraging
people to help out by creating the new title right after the release
is tagged. See git log NEWS :-)

Will fix the other two and push.
-Daniel

>
> or so?
>
>
>>  Release 1.20 (2017-10-03)
>>  -
>>
>> diff --git a/README b/README
>> index e0f829defb51..5b4a59e9ac24 100644
>> --- a/README
>> +++ b/README
>> @@ -167,11 +167,11 @@ The following dependencies are requires for building 
>> audio support
>>   libasound2-dev
>>   libgsl-dev
>>
>> -Experimental meson build system support
>> 
>> +Meson build system support
>> +--
>>
>> -Right now this is just a preview for developers, automake is still used by 
>> CI
>> -and needs to keep working. One-liner howto:
>> +Currently we support both meson and automake as build systems, but meson is 
>> the
>> +recommened choice. Oneliner to get started:
>
>
> Typo: recommended
>
>
>
> Otherwise:
> Reviewed-by: Petri Latvala 



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Only enumerate available counters in sysfs (rev3)

[Tvrtko Ursulin]

On 11/01/2018 09:09, Patchwork wrote:

== Series Details ==

Series: drm/i915/pmu: Only enumerate available counters in sysfs (rev3)
URL   : https://patchwork.freedesktop.org/series/35689/
State : success

== Summary ==

Series 35689v3 drm/i915/pmu: Only enumerate available counters in sysfs
https://patchwork.freedesktop.org/api/1.0/series/35689/revisions/3/mbox/

Test debugfs_test:
 Subgroup read_all_entries:
 dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989 +1
Test kms_pipe_crc_basic:
 Subgroup suspend-read-crc-pipe-a:
 pass   -> DMESG-WARN (fi-kbl-r) fdo#104172 +1
 Subgroup suspend-read-crc-pipe-b:
 pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#104172 https://bugs.freedesktop.org/show_bug.cgi?id=104172
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:414s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:413s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:357s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:444s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:262s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:463s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:464s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:426s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:421s
fi-cnl-y2total:288  pass:258  dwarn:3   dfail:0   fail:0   skip:27  
time:556s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:247s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:493s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:379s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:388s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:395s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:445s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:408s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:459s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:490s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:441s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:492s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:481s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:415s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:517s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:478s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:465s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:419s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:386s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:554s
fi-glk-dsi   total:288  pass:189  dwarn:1   dfail:4   fail:0   skip:94  
time:382s

7b72161536aa58d5d20f7d1e15d24884374f5d10 drm-tip: 2018y-01m-10d-19h-08m-42s UTC 
integration manifest
0d4c6f0e843e drm/i915/pmu: Only enumerate available counters in sysfs


Pushed, thanks for the review!

Regards,

Tvrtko

___
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 drm/i915: Apply headless DMC workaround for CNL

[Tvrtko Ursulin]

On 11/01/2018 08:45, Patchwork wrote:

== Series Details ==

Series: drm/i915: Apply headless DMC workaround for CNL
URL   : https://patchwork.freedesktop.org/series/36317/
State : success

== Summary ==

Series 36317v1 drm/i915: Apply headless DMC workaround for CNL
https://patchwork.freedesktop.org/api/1.0/series/36317/revisions/1/mbox/

Test kms_frontbuffer_tracking:
 Subgroup basic:
 skip   -> INCOMPLETE (fi-elk-e7500) fdo#103989
Test kms_pipe_crc_basic:
 Subgroup suspend-read-crc-pipe-a:
 pass   -> DMESG-WARN (fi-kbl-r) fdo#104172 +1

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:418s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:488s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:485s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:487s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:469s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:458s
fi-cnl-y2total:288  pass:258  dwarn:3   dfail:0   fail:0   skip:27  
time:541s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:272s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:513s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:390s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:402s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:451s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:412s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:465s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:497s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:512s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:583s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:428s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:513s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:528s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:494s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:482s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:523s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:400s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:573s
fi-glk-dsi   total:288  pass:152  dwarn:1   dfail:4   fail:0   skip:131 
time:276s
fi-bdw-gvtdvm failed to collect. IGT log at Patchwork_7647/fi-bdw-gvtdvm/igt.log

7b72161536aa58d5d20f7d1e15d24884374f5d10 drm-tip: 2018y-01m-10d-19h-08m-42s UTC 
integration manifest
bece3c28fe29 drm/i915: Apply headless DMC workaround for CNL


Pushed, thanks for the review!

Regards,

Tvrtko

___
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 drm/i915: Ignore TMDS clock limit for DP++ when EDID override is set (rev2)

[Petri Latvala]

On Thu, Jan 11, 2018 at 09:54:02AM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Ignore TMDS clock limit for DP++ when EDID override is set 
> (rev2)
> URL   : https://patchwork.freedesktop.org/series/35338/
> State : failure
> 
> == Summary ==
> 
> Warning: bzip CI_DRM_3609/shard-glkb6/results32.json.bz2 wasn't in correct 
> JSON format
> Test kms_cursor_crc:
> Subgroup cursor-64x21-onscreen:
> skip   -> PASS   (shard-hsw)
> Subgroup cursor-64x64-suspend:
> skip   -> PASS   (shard-snb) fdo#102365
> skip   -> PASS   (shard-hsw) fdo#103540
> Test drv_suspend:
> Subgroup debugfs-reader:
> pass   -> SKIP   (shard-snb)
> Test kms_frontbuffer_tracking:
> Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
> fail   -> PASS   (shard-snb) fdo#101623
> Test kms_flip:
> Subgroup vblank-vs-modeset-suspend:
> pass   -> INCOMPLETE (shard-hsw)
> 
> fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
> fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
> fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
> 
> shard-hswtotal:2681 pass:1521 dwarn:1   dfail:0   fail:10  skip:1148 
> time:8681s
> shard-snbtotal:2713 pass:1310 dwarn:1   dfail:0   fail:10  skip:1392 
> time:7926s
> Blacklisted hosts:
> shard-apltotal:2713 pass:1684 dwarn:1   dfail:0   fail:25  skip:1002 
> time:13555s
> shard-kbltotal:2713 pass:1808 dwarn:1   dfail:0   fail:24  skip:880 
> time:10569s
> 
> == Logs ==
> 
> For more details see: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7628/shards.html

kbl results now shown in the text diff but this page shows:

igt@kms_hdmi_inject@inject-4k  fail -> PASS


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

Re: [Intel-gfx] [PATCH 14/15] drm/i915: Add NV12 as supported format for sprite plane

[Srinivas, Vidya]

> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Tuesday, January 9, 2018 3:32 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 14/15] drm/i915: Add NV12 as supported
> format for sprite plane
> 
> Op 09-01-18 om 03:19 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Monday, January 8, 2018 6:04 PM
> >> To: Srinivas, Vidya ; intel-
> >> g...@lists.freedesktop.org
> >> Subject: Re: [Intel-gfx] [PATCH 14/15] drm/i915: Add NV12 as
> >> supported format for sprite plane
> >>
> >> Op 07-01-18 om 10:59 schreef Vidya Srinivas:
> >>> From: Chandra Konduru 
> >>>
> >>> This patch adds NV12 to list of supported formats for sprite plane.
> >>>
> >>> v2: Rebased (me)
> >>>
> >>> v3: Review comments by Ville addressed
> >>> - Removed skl_plane_formats_with_nv12 and added
> >>> NV12 case in existing skl_plane_formats
> >>> - Added the 10bpc RGB formats
> >>>
> >>> v4: Addressed review comments from Clinton A Taylor "Why are we
> >> adding
> >>> 10 bit RGB formats with the NV12 series patches?
> >>> Trying to set XR30 or AB30 results in error returned even though the
> >>> modes are advertised for the planes"
> >>> - Removed 10bit RGB formats added previously with NV12 series
> >>>
> >>> v5: Missed the Tested-by/Reviewed-by in the previous series Adding
> >>> the same to commit message in this version.
> >>> Addressed review comments from Clinton A Taylor "Why are we adding
> >>> 10 bit RGB formats with the NV12 series patches?
> >>> Trying to set XR30 or AB30 results in error returned even though the
> >>> modes are advertised for the planes"
> >>> - Previous version has 10bit RGB format removed from VLV formats by
> >>> mistake. Fixing that in this version.
> >>> Removed 10bit RGB formats added previously with NV12 series for SKL.
> >>>
> >>> v6: Addressed review comments by Ville Restricting the NV12 to BXT
> >>> and PIPE A and B
> >>>
> >>> v7: Rebased (me)
> >>>
> >>> v8: Rebased (me)
> >>> Restricting NV12 changes to BXT and KBL Restricting NV12 changes for
> >>> plane 0 (overlay)
> >>>
> >>> v9: Rebased (me)
> >>>
> >>> Tested-by: Clinton Taylor 
> >>> Reviewed-by: Clinton Taylor 
> >>> Signed-off-by: Chandra Konduru 
> >>> Signed-off-by: Nabendu Maiti 
> >>> Signed-off-by: Vidya Srinivas 
> >>> ---
> >>>  drivers/gpu/drm/i915/intel_sprite.c | 24 +---
> >>>  1 file changed, 21 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> >>> b/drivers/gpu/drm/i915/intel_sprite.c
> >>> index 09732ae..1d35a18 100644
> >>> --- a/drivers/gpu/drm/i915/intel_sprite.c
> >>> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> >>> @@ -1279,6 +1279,19 @@ static const struct drm_plane_funcs
> >> intel_sprite_plane_funcs = {
> >>>  .format_mod_supported =
> >>> intel_sprite_plane_format_mod_supported,
> >>>  };
> >>>
> >>> +static uint32_t nv12_plane_formats[] = {
> >>> + DRM_FORMAT_RGB565,
> >>> + DRM_FORMAT_ABGR,
> >>> + DRM_FORMAT_ARGB,
> >>> + DRM_FORMAT_XBGR,
> >>> + DRM_FORMAT_XRGB,
> >>> + DRM_FORMAT_YUYV,
> >>> + DRM_FORMAT_YVYU,
> >>> + DRM_FORMAT_UYVY,
> >>> + DRM_FORMAT_VYUY,
> >>> + DRM_FORMAT_NV12,
> >>> +};
> >>> +
> >>>  struct intel_plane *
> >>>  intel_sprite_plane_create(struct drm_i915_private *dev_priv,
> >>> enum pipe pipe, int plane)
> >>> @@ -1323,9 +1336,14 @@ intel_sprite_plane_create(struct
> >> drm_i915_private *dev_priv,
> >>>   intel_plane->update_plane = skl_update_plane;
> >>>   intel_plane->disable_plane = skl_disable_plane;
> >>>   intel_plane->get_hw_state = skl_plane_get_hw_state;
> >>> -
> >>> - plane_formats = skl_plane_formats;
> >>> - num_plane_formats = ARRAY_SIZE(skl_plane_formats);
> >>> + if ((IS_BROXTON(dev_priv) || IS_KABYLAKE(dev_priv)) &&
> >>> + (pipe == PIPE_A || pipe == PIPE_B) && plane == 0) {
> >>> + plane_formats = nv12_plane_formats;
> >>> + num_plane_formats =
> >> ARRAY_SIZE(nv12_plane_formats);
> >>> + } else {
> >>> + plane_formats = skl_plane_formats;
> >>> + num_plane_formats =
> >> ARRAY_SIZE(skl_plane_formats);
> >>> + }
> >> I understand we don't have enough scalers, but is there something
> >> wrong with allowing nv12 on any plane?
> >>
> > On BXT (Gen9), NV12 is supported only on primary and sprite 0.
> Ah ok, nm that comment then. :)
> 
> Same comment applies as for the other patch that adds it to the primary
> plane, would be better to have a single array and tinker with
> num_plane_formats, should gen10 also have NV12 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Ignore TMDS clock limit for DP++ when EDID override is set (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Ignore TMDS clock limit for DP++ when EDID override is set 
(rev2)
URL   : https://patchwork.freedesktop.org/series/35338/
State : failure

== Summary ==

Warning: bzip CI_DRM_3609/shard-glkb6/results32.json.bz2 wasn't in correct JSON 
format
Test kms_cursor_crc:
Subgroup cursor-64x21-onscreen:
skip   -> PASS   (shard-hsw)
Subgroup cursor-64x64-suspend:
skip   -> PASS   (shard-snb) fdo#102365
skip   -> PASS   (shard-hsw) fdo#103540
Test drv_suspend:
Subgroup debugfs-reader:
pass   -> SKIP   (shard-snb)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
fail   -> PASS   (shard-snb) fdo#101623
Test kms_flip:
Subgroup vblank-vs-modeset-suspend:
pass   -> INCOMPLETE (shard-hsw)

fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623

shard-hswtotal:2681 pass:1521 dwarn:1   dfail:0   fail:10  skip:1148 
time:8681s
shard-snbtotal:2713 pass:1310 dwarn:1   dfail:0   fail:10  skip:1392 
time:7926s
Blacklisted hosts:
shard-apltotal:2713 pass:1684 dwarn:1   dfail:0   fail:25  skip:1002 
time:13555s
shard-kbltotal:2713 pass:1808 dwarn:1   dfail:0   fail:24  skip:880 
time:10569s

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/scheduler: Assert that we do not have a dep cycle back to request

[Michał Winiarski]

On Fri, Jan 05, 2018 at 02:13:22PM +, Chris Wilson wrote:
> When reprioritising a request, we build a list of its dependencies in
> topological order. This should leave our origin request as the first
> element in our list, if it moves we have a dependency cycle and severe
> breakage. Assert that it doesn't move.
> 
> Complete, but expensive checking is done by swfence, this assert is more
> about documenting the topologically ordered list.
> 
> Signed-off-by: Chris Wilson 
> Cc: Michał Winiarski 

Reviewed-by: Michał Winiarski 

-Michał

> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 4e150b095a11..42705e3875cd 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1050,6 +1050,13 @@ static void execlists_schedule(struct 
> drm_i915_gem_request *request, int prio)
>   }
>   }
>  
> + /*
> +  * We should never have a dep cycle back to ourselves, leaving
> +  * the original request as the origin of our topologically sorted
> +  * list.
> +  */
> + GEM_BUG_ON(list_first_entry(, typeof(stack), dfs_link) != );
> +
>   /*
>* If we didn't need to bump any existing priorities, and we haven't
>* yet submitted this request (i.e. there is no potential race with
> -- 
> 2.15.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/guc: Redefine guc_log_level modparam values

[Sagar Arun Kamble]

On 1/11/2018 2:54 PM, Michal Wajdeczko wrote:
On Thu, 11 Jan 2018 06:52:18 +0100, Sagar Arun Kamble 
 wrote:





On 1/10/2018 9:35 PM, Michal Wajdeczko wrote:

We used value -1 to indicate "disabled" and values 0..3 to
indicate "enabled", but most of our other modparams are using
-1 for "auto" mode and 0 for "disable". For consistency let's
change our log level values to:

-1: auto (depends on USES_GUC and DRM_I915_DEBUG)

"depends on HAS_GUC, USES_GUC, DRM_I915_DEBUG and DRM_I915_DEBUG_GEM"


I should write "(depends on platform and Kconfig.debug settings)" as
actual condition may change in the near feature.


Yes

s/intel_uc_is_using_guc()/USES_GUC
seeing some more intel_uc_is_using_* instead of macro usage USES_*


It was by design, as in intel_uc_sanitize_options() function we are
using only HAS_xxx macros and instead of USES_xxx we call intel_uc_is_xxx
helpers directly.


Got it

  0: disabled
  1: enabled (severity level 0 = min)
  2: enabled (severity level 1)
  3: enabled (severity level 2)
  4: enabled (severity level 3 = max)

Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_params.c   |  3 ++-
  drivers/gpu/drm/i915/intel_guc.c | 21 ++-
  drivers/gpu/drm/i915/intel_guc_log.c | 47 
-
  drivers/gpu/drm/i915/intel_uc.c  | 51 
++--

  4 files changed, 87 insertions(+), 35 deletions(-)

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

index b5f3eb4..0b553a8 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -155,7 +155,8 @@ struct i915_params i915_modparams __read_mostly = {
  "(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)");
    i915_param_named(guc_log_level, int, 0400,
-    "GuC firmware logging level (-1:disabled (default), 
0-3:enabled)");

+    "GuC firmware logging level. Requires GuC to be loaded. "
+    "(-1=auto [default], 0=disable, 1..4=enable with verbosity 
min..max)");

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

index 50b4725..2227236 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -215,6 +215,18 @@ static u32 get_core_family(struct 
drm_i915_private *dev_priv)

  }
  }
  +static u32 get_log_verbosity_flags(void)
+{

making this inline would be good i guess.


No need to do so. Compiler will take care of it as needed (as this
function is already marked as static)


+    if (i915_modparams.guc_log_level > 0) {
+    u32 verbosity = i915_modparams.guc_log_level - 1;
+
+    GEM_BUG_ON(verbosity > GUC_LOG_VERBOSITY_MAX);
+    return verbosity << GUC_LOG_VERBOSITY_SHIFT;
+    }
+    GEM_BUG_ON(i915_modparams.enable_guc < 0);
+    return GUC_LOG_DISABLED;
+}
+
  /*
   * Initialise the GuC parameter block before starting the firmware
   * transfer. These parameters are read by the firmware on startup
@@ -247,12 +259,7 @@ void intel_guc_init_params(struct intel_guc *guc)
    params[GUC_CTL_LOG_PARAMS] = guc->log.flags;
  -    if (i915_modparams.guc_log_level >= 0) {
-    params[GUC_CTL_DEBUG] =
-    i915_modparams.guc_log_level << GUC_LOG_VERBOSITY_SHIFT;
-    } else {
-    params[GUC_CTL_DEBUG] = GUC_LOG_DISABLED;
-    }
+    params[GUC_CTL_DEBUG] = get_log_verbosity_flags();
    /* If GuC submission is enabled, set up additional 
parameters here */

  if (USES_GUC_SUBMISSION(dev_priv)) {
@@ -445,7 +452,7 @@ int intel_guc_resume(struct drm_i915_private 
*dev_priv)

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

if (i915_modparams.guc_log_level)

gen9_enable_guc_interrupts(dev_priv);
    data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c

index eaedd63..e6d59bf 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c


  @@ -582,7 +578,7 @@ int i915_guc_log_control(struct 
drm_i915_private *dev_priv, u64 control_val)

  return -EINVAL;
    /* This combination doesn't make sense & won't have any 
effect */
-    if (!log_param.logging_enabled && (i915_modparams.guc_log_level 
< 0))

+    if (!log_param.logging_enabled && !i915_modparams.guc_log_level)
  return 0;
    ret = guc_log_control(guc, log_param.value);
@@ -592,11 +588,12 @@ int i915_guc_log_control(struct 
drm_i915_private *dev_priv, 

Re: [Intel-gfx] [PATCH i-g-t 1/1] tools: Update .gitignore

[Mika Kahola]

On Thu, 2018-01-11 at 11:27 +0200, Petri Latvala wrote:
> Fixes: 834321a5d76a ("tools: Cannonlake port clock programming")

Reviewed-by: Mika Kahola 

> Signed-off-by: Petri Latvala 
> Cc: Mika Kahola 
> ---
>  tools/.gitignore | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/.gitignore b/tools/.gitignore
> index 2e16cb26..2de665a3 100644
> --- a/tools/.gitignore
> +++ b/tools/.gitignore
> @@ -1,4 +1,5 @@
>  # Please keep sorted alphabetically
> +cnl_compute_wrpll
>  hsw_compute_wrpll
>  igt_stats
>  intel_aubdump
-- 
Mika Kahola - Intel OTC

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