Re: [Intel-gfx] [PATCH 2/2] drm/i915/mst: Use MST sideband message transaction for dpms

[Stefan Assmann]

On 2017-09-05 18:26, Dhinakaran Pandiyan wrote:
> Use the POWER_DOWN_PHY and POWER_UP_PHY sideband message trasactions to
> set power states for downstream sinks. Apart from giving us the ability
> to set power state for individual sinks, this fixes the below test for
> me
> 
> $ xrandr --display :0 --output DP-2-2-8 --off
> $ xrandr --display :0 --output DP-2-2-1 --off
> $ xrandr --display :0 --output DP-2-2-8 --auto #Black screen
> $ xrandr --display :0 --output DP-2-2-1 --auto
> 
> Cc: Ville Syrjälä 
> Cc: Lyude 
> Signed-off-by: Dhinakaran Pandiyan 

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

Re: [Intel-gfx] [PATCH 1/2] drm/dp/mst: Sideband message transaction to power up/down nodes

[Stefan Assmann]

On 2017-09-05 18:26, Dhinakaran Pandiyan wrote:
> The POWER_DOWN_PHY and POWER_UP_PHY sideband message transactions allow
> the source to reqest any node in a mst path or a whole path to be
> powered down or up. This allows drivers to target a specific sink in the
> MST topology, an improvement over just power managing the imediate
> downstream device. Secondly, since the request-reply protocol waits for an
> ACK, we can be sure that a downstream sink has enough time to respond to a
> power up/down request.
> 
> Cc: Lyude 
> Cc: Ville Syrjälä 
> Cc: Harry Wentland 
> Signed-off-by: Dhinakaran Pandiyan 

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/cnl: WaThrottleEUPerfToAvoidTDBackPressure:cnl(pre-prod)

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: WaThrottleEUPerfToAvoidTDBackPressure:cnl(pre-prod)
URL   : https://patchwork.freedesktop.org/series/29909/
State : success

== Summary ==

Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-hsw) fdo#100047
Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_atomic_transition:
Subgroup plane-use-after-nonblocking-unbind:
incomplete -> FAIL   (shard-hsw) fdo#101847

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

shard-hswtotal:2265 pass:1233 dwarn:0   dfail:0   fail:15  skip:1016 
time:9634s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5600/shards.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 Experimental Revert "drm/i915: Re-enable per-engine reset for Broxton"

[Patchwork]

== Series Details ==

Series: Experimental Revert "drm/i915: Re-enable per-engine reset for Broxton"
URL   : https://patchwork.freedesktop.org/series/29905/
State : failure

== Summary ==

Test kms_busy:
Subgroup basic-flip-C:
pass   -> SKIP   (shard-hsw)
Test kms_draw_crc:
Subgroup fill-fb:
pass   -> SKIP   (shard-hsw)
Test pm_rpm:
Subgroup legacy-planes:
pass   -> SKIP   (shard-hsw)
Test kms_atomic_transition:
Subgroup 1x-modeset-transitions-fencing:
pass   -> SKIP   (shard-hsw)
Subgroup plane-use-after-nonblocking-unbind:
fail   -> INCOMPLETE (shard-hsw) fdo#101847
Test kms_flip:
Subgroup dpms-vs-vblank-race:
pass   -> FAIL   (shard-hsw)
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-hsw) fdo#100047
Test kms_vblank:
Subgroup accuracy-idle:
fail   -> PASS   (shard-hsw)

fdo#101847 https://bugs.freedesktop.org/show_bug.cgi?id=101847
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-hswtotal: pass:1201 dwarn:0   dfail:0   fail:16  skip:1004 
time:9502s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5598/shards.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 series starting with [1/2] drm/i915/guc: Add GuC Load time to debugfs

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/guc: Add GuC Load time to debugfs
URL   : https://patchwork.freedesktop.org/series/29921/
State : failure

== Summary ==

  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CHK include/generated/bounds.h
  CHK include/generated/timeconst.h
  CHK include/generated/asm-offsets.h
  CALLscripts/checksyscalls.sh
  CHK scripts/mod/devicetable-offsets.h
  CHK include/generated/compile.h
  CHK kernel/config_data.h
  CC [M]  drivers/gpu/drm/i915/i915_debugfs.o
drivers/gpu/drm/i915/i915_debugfs.c: In function ‘i915_huc_load_status_info’:
drivers/gpu/drm/i915/i915_debugfs.c:2352:38: error: format ‘%lu’ expects 
argument of type ‘long unsigned int’, but argument 3 has type ‘unsigned int’ 
[-Werror=format=]
  seq_printf(m, "\tHuC load time is %lu ms\n",
  ^
drivers/gpu/drm/i915/i915_debugfs.c: In function ‘i915_guc_load_status_info’:
drivers/gpu/drm/i915/i915_debugfs.c:2384:38: error: format ‘%lu’ expects 
argument of type ‘long unsigned int’, but argument 3 has type ‘unsigned int’ 
[-Werror=format=]
  seq_printf(m, "\tGuC Load time is %lu ms\n",
  ^
cc1: all warnings being treated as errors
scripts/Makefile.build:302: recipe for target 
'drivers/gpu/drm/i915/i915_debugfs.o' failed
make[4]: *** [drivers/gpu/drm/i915/i915_debugfs.o] Error 1
scripts/Makefile.build:561: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:561: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:561: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1019: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] drm/i915: Transform WaInPlaceDecompressionHang into a simple reg write

[Patchwork]

== Series Details ==

Series: series starting with [1/6] drm/i915: Transform 
WaInPlaceDecompressionHang into a simple reg write
URL   : https://patchwork.freedesktop.org/series/29920/
State : failure

== Summary ==

  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CHK include/generated/bounds.h
  CHK include/generated/timeconst.h
  CHK include/generated/asm-offsets.h
  CALLscripts/checksyscalls.sh
  CHK scripts/mod/devicetable-offsets.h
  CHK include/generated/compile.h
  CHK kernel/config_data.h
  CC [M]  drivers/gpu/drm/i915/intel_engine_cs.o
In file included from drivers/gpu/drm/i915/selftests/mock_engine.h:32:0,
 from drivers/gpu/drm/i915/selftests/mock_engine.c:25,
 from drivers/gpu/drm/i915/intel_engine_cs.c:1411:
drivers/gpu/drm/i915/selftests/../intel_ringbuffer.h: In function 
‘skl_init_workarounds’:
drivers/gpu/drm/i915/selftests/../intel_ringbuffer.h:740:0: error: unterminated 
argument list invoking macro "I915_WRITE"
 #endif /* _INTEL_RINGBUFFER_H_ */
 
drivers/gpu/drm/i915/intel_engine_cs.c:984:2: error: ‘I915_WRITE’ undeclared 
(first use in this function)
  I915_WRITE(GEN7_UCGCTL4, (I915_READ(GEN7_UCGCTL4) |
  ^~
drivers/gpu/drm/i915/intel_engine_cs.c:984:2: note: each undeclared identifier 
is reported only once for each function it appears in
In file included from drivers/gpu/drm/i915/selftests/mock_engine.c:25:0,
 from drivers/gpu/drm/i915/intel_engine_cs.c:1411:
drivers/gpu/drm/i915/selftests/mock_engine.h:34:1: error: expected ‘;’ before 
‘struct’
 struct mock_engine {
 ^~
drivers/gpu/drm/i915/selftests/mock_engine.h:42:1: error: ISO C90 forbids mixed 
declarations and code [-Werror=declaration-after-statement]
 struct intel_engine_cs *mock_engine(struct drm_i915_private *i915,
 ^~
drivers/gpu/drm/i915/selftests/mock_engine.h:49:20: error: invalid storage 
class for function ‘mock_seqno_advance’
 static inline void mock_seqno_advance(struct intel_engine_cs *engine, u32 
seqno)
^~
In file included from drivers/gpu/drm/i915/intel_engine_cs.c:1411:0:
drivers/gpu/drm/i915/selftests/mock_engine.c:28:50: error: ‘struct mock_engine’ 
declared inside parameter list will not be visible outside of this definition 
or declaration [-Werror]
 static struct mock_request *first_request(struct mock_engine *engine)
  ^~~
drivers/gpu/drm/i915/selftests/mock_engine.c:28:29: error: invalid storage 
class for function ‘first_request’
 static struct mock_request *first_request(struct mock_engine *engine)
 ^
In file included from ./include/linux/preempt.h:10:0,
 from ./include/linux/spinlock.h:50,
 from ./include/linux/mmzone.h:7,
 from ./include/linux/gfp.h:5,
 from ./include/linux/slab.h:14,
 from ./include/linux/io-mapping.h:22,
 from drivers/gpu/drm/i915/i915_drv.h:36,
 from drivers/gpu/drm/i915/intel_engine_cs.c:25:
drivers/gpu/drm/i915/selftests/mock_engine.c: In function ‘first_request’:
drivers/gpu/drm/i915/selftests/mock_engine.c:30:41: error: dereferencing 
pointer to incomplete type ‘struct mock_engine’
  return list_first_entry_or_null(>hw_queue,
 ^
./include/linux/list.h:398:30: note: in definition of macro 
‘list_first_entry_or_null’
  struct list_head *head__ = (ptr); \
  ^~~
In file included from drivers/gpu/drm/i915/intel_engine_cs.c:1411:0:
drivers/gpu/drm/i915/selftests/mock_engine.c: In function 
‘skl_init_workarounds’:
drivers/gpu/drm/i915/selftests/mock_engine.c:35:13: error: invalid storage 
class for function ‘hw_delay_complete’
 static void hw_delay_complete(unsigned long data)
 ^
drivers/gpu/drm/i915/selftests/mock_engine.c: In function ‘hw_delay_complete’:
drivers/gpu/drm/i915/selftests/mock_engine.c:40:19: error: dereferencing 
pointer to incomplete type ‘struct mock_engine’
  spin_lock(>hw_lock);
   ^~
drivers/gpu/drm/i915/selftests/mock_engine.c:42:26: error: passing argument 1 
of ‘first_request’ from incompatible pointer type 
[-Werror=incompatible-pointer-types]
  request = first_request(engine);
  ^~
drivers/gpu/drm/i915/selftests/mock_engine.c:28:29: note: expected ‘struct 
mock_engine *’ but argument is of type ‘struct mock_engine *’
 static struct mock_request *first_request(struct mock_engine *engine)
 ^
drivers/gpu/drm/i915/selftests/mock_engine.c:48:26: error: passing argument 1 
of ‘first_request’ from incompatible pointer type 
[-Werror=incompatible-pointer-types]
  request = first_request(engine);
  ^~

[Intel-gfx] [PATCH 2/2] drm/i915/huc: Add HuC Load time to debugfs

[Anusha Srivatsa]

This patch uses jiffies to calculate the huc
load time and add it as a field to debugfs.
This information can be useful for testing
to know how much time huc takes to load.

Cc: Sujaritha Sundaresan 
Cc: Oscar Mateo Lozano 
Cc: Michal Wajdeczko 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
 drivers/gpu/drm/i915/intel_huc.c| 8 
 drivers/gpu/drm/i915/intel_uc.h | 1 +
 3 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e0b99dbc6608..a8a8a210a97c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2349,6 +2349,8 @@ static int i915_huc_load_status_info(struct seq_file *m, 
void *data)
huc_fw->header_offset, huc_fw->header_size);
seq_printf(m, "\tuCode: offset is %d; size = %d\n",
huc_fw->ucode_offset, huc_fw->ucode_size);
+   seq_printf(m, "\tHuC load time is %lu ms\n",
+  jiffies_to_msecs(huc_fw->huc_load_time));
seq_printf(m, "\tRSA: offset is %d; size = %d\n",
huc_fw->rsa_offset, huc_fw->rsa_size);
 
diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index 6145fa0d6773..798dec9bd2c8 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -90,6 +90,7 @@ static int huc_ucode_xfer(struct drm_i915_private *dev_priv)
unsigned long offset = 0;
u32 size;
int ret;
+   unsigned long huc_start_load, huc_finish_load;
 
ret = i915_gem_object_set_to_gtt_domain(huc_fw->obj, false);
if (ret) {
@@ -121,11 +122,15 @@ static int huc_ucode_xfer(struct drm_i915_private 
*dev_priv)
I915_WRITE(DMA_COPY_SIZE, size);
 
/* Start the DMA */
+   huc_start_load = jiffies;
I915_WRITE(DMA_CTRL, _MASKED_BIT_ENABLE(HUC_UKERNEL | START_DMA));
 
/* Wait for DMA to finish */
ret = wait_for((I915_READ(DMA_CTRL) & START_DMA) == 0, 100);
 
+   huc_finish_load = jiffies;
+   huc_fw->huc_load_time = huc_finish_load - huc_start_load;
+
DRM_DEBUG_DRIVER("HuC DMA transfer wait over with ret %d\n", ret);
 
/* Disable the bits once DMA is over */
@@ -218,6 +223,9 @@ void intel_huc_init_hw(struct intel_huc *huc)
intel_uc_fw_status_repr(huc->fw.fetch_status),
intel_uc_fw_status_repr(huc->fw.load_status));
 
+   DRM_DEBUG_DRIVER("Time taken to load HuC %lu",
+huc->fw.huc_load_time);
+
if (huc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
DRM_ERROR("Failed to complete HuC uCode load with ret %d\n", 
err);
 
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 52aa05d13863..1ef685d7095e 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -155,6 +155,7 @@ struct intel_uc_fw {
uint32_t ucode_size;
uint32_t ucode_offset;
unsigned long guc_load_time;
+   unsigned long huc_load_time;
 };
 
 struct intel_guc_log {
-- 
2.11.0

___
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: Add GuC Load time to debugfs

[Anusha Srivatsa]

Calculate the time that GuC takes to load.
This information could be very useful in
determining if GuC is taking unreasonably long time
to load in a certain platforms.

v2: Calculate time before logs are collected.
Move the guc_load_time variable as a part of
intel_uc_fw struct. Store only final result
which is to be exported to debugfs. (Michal)
Add the load time in the print message as well.

Cc: Sujaritha Sundaresan 
Cc: Oscar Mateo 
Cc: Michal Wajdeczko 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
 drivers/gpu/drm/i915/intel_guc_loader.c | 8 
 drivers/gpu/drm/i915/intel_uc.h | 1 +
 3 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 48572b157222..e0b99dbc6608 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2379,6 +2379,9 @@ static int i915_guc_load_status_info(struct seq_file *m, 
void *data)
guc_fw->major_ver_wanted, guc_fw->minor_ver_wanted);
seq_printf(m, "\tversion found: %d.%d\n",
guc_fw->major_ver_found, guc_fw->minor_ver_found);
+   seq_printf(m, "\tGuC Load time is %lu ms\n",
+  jiffies_to_msecs(guc_fw->guc_load_time));
+
seq_printf(m, "\theader: offset is %d; size = %d\n",
guc_fw->header_offset, guc_fw->header_size);
seq_printf(m, "\tuCode: offset is %d; size = %d\n",
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 8b0ae7fce7f2..da917f84c471 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -199,6 +199,7 @@ static int guc_ucode_xfer_dma(struct drm_i915_private 
*dev_priv,
struct sg_table *sg = vma->pages;
u32 status, rsa[UOS_RSA_SCRATCH_MAX_COUNT];
int i, ret = 0;
+   unsigned long guc_start_load, guc_finish_load;
 
/* where RSA signature starts */
offset = guc_fw->rsa_offset;
@@ -226,6 +227,7 @@ static int guc_ucode_xfer_dma(struct drm_i915_private 
*dev_priv,
 
/* Finally start the DMA */
I915_WRITE(DMA_CTRL, _MASKED_BIT_ENABLE(UOS_MOVE | START_DMA));
+   guc_start_load = jiffies;
 
/*
 * Wait for the DMA to complete & the GuC to start up.
@@ -237,6 +239,9 @@ static int guc_ucode_xfer_dma(struct drm_i915_private 
*dev_priv,
 */
ret = wait_for(guc_ucode_response(dev_priv, ), 100);
 
+   guc_finish_load = jiffies;
+   guc_fw->guc_load_time = guc_finish_load - guc_start_load;
+
DRM_DEBUG_DRIVER("DMA status 0x%x, GuC status 0x%x\n",
I915_READ(DMA_CTRL), status);
 
@@ -372,6 +377,9 @@ int intel_guc_init_hw(struct intel_guc *guc)
 guc->fw.path,
 guc->fw.major_ver_found, guc->fw.minor_ver_found);
 
+   DRM_DEBUG_DRIVER("Time taken to load GuC is %lu\n",
+guc->fw.guc_load_time);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 22ae52b17b0f..52aa05d13863 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -154,6 +154,7 @@ struct intel_uc_fw {
uint32_t rsa_offset;
uint32_t ucode_size;
uint32_t ucode_offset;
+   unsigned long guc_load_time;
 };
 
 struct intel_guc_log {
-- 
2.11.0

___
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] drm/dp/mst: Sideband message transaction to power up/down nodes (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [v2] drm/dp/mst: Sideband message transaction to 
power up/down nodes (rev2)
URL   : https://patchwork.freedesktop.org/series/29853/
State : failure

== Summary ==

Series 29853v2 series starting with [v2] drm/dp/mst: Sideband message 
transaction to power up/down nodes
https://patchwork.freedesktop.org/api/1.0/series/29853/revisions/2/mbox/

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
fail   -> PASS   (fi-snb-2600) fdo#100215
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> SKIP   (fi-cfl-s) fdo#102294
Test drv_module_reload:
Subgroup basic-reload-inject:
pass   -> INCOMPLETE (fi-bwr-2160)

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:456s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:439s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:365s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:554s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:104
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:520s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:524s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:512s
fi-cfl-s total:289  pass:249  dwarn:4   dfail:0   fail:0   skip:36  
time:475s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:431s
fi-glk-2atotal:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:610s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:445s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:426s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:425s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:506s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:476s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:516s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:608s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:597s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:530s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:533s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:512s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:450s
fi-skl-x1585ltotal:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:489s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:558s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:410s

d987a6e6aed64b97877546c110149c16bca64804 drm-tip: 2017y-09m-06d-23h-36m-35s UTC 
integration manifest
86fb8d256f2b drm/i915/mst: Use MST sideband message transaction for dpms
f7f3476b4cfd drm/dp/mst: Sideband message transaction to power up/down nodes

== Logs ==

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

[Intel-gfx] [PATCH 5/6] drm/i915: Transform WaDisableDynamicCreditSharing into a simple register write

[Oscar Mateo]

GAMT_CHKN_BIT_REG does not live in the context image.

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Rodrigo Vivi 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a22a1d1..e2a605a 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1126,8 +1126,9 @@ static int kbl_init_workarounds(struct intel_engine_cs 
*engine)
 
/* WaDisableDynamicCreditSharing:kbl */
if (IS_KBL_REVID(dev_priv, 0, KBL_REVID_B0))
-   WA_SET_BIT(GAMT_CHKN_BIT_REG,
-  GAMT_CHKN_DISABLE_DYNAMIC_CREDIT_SHARING);
+   I915_WRITE(GAMT_CHKN_BIT_REG,
+  (I915_READ(GAMT_CHKN_BIT_REG) |
+   GAMT_CHKN_DISABLE_DYNAMIC_CREDIT_SHARING));
 
/* WaDisableFenceDestinationToSLM:kbl (pre-prod) */
if (IS_KBL_REVID(dev_priv, KBL_REVID_A0, KBL_REVID_A0))
-- 
1.9.1

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

[Intel-gfx] [PATCH 3/6] drm/i915: WaPushConstantDereferenceHoldDisable needs to modify a masked register

[Oscar Mateo]

So do it correctly.

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Rodrigo Vivi 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 7c384d5..cdd86ef 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1097,7 +1097,7 @@ static int cnl_init_workarounds(struct intel_engine_cs 
*engine)
GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS));
 
/* WaPushConstantDereferenceHoldDisable:cnl */
-   WA_SET_BIT(GEN7_ROW_CHICKEN2, PUSH_CONSTANT_DEREF_DISABLE);
+   WA_SET_BIT_MASKED(GEN7_ROW_CHICKEN2, PUSH_CONSTANT_DEREF_DISABLE);
 
/* FtrEnableFastAnisoL1BankingFix: cnl */
WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3, CNL_FAST_ANISO_L1_BANKING_FIX);
-- 
1.9.1

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

[Intel-gfx] [PATCH 6/6] drm/i915: Transform WaDisablePooledEuLoadBalancingFix into a simple register write

[Oscar Mateo]

FF_SLICE_CS_CHICKEN2 does not belong to the context image.

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Rodrigo Vivi 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index e2a605a..cacc6ad6c 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1024,8 +1024,8 @@ static int bxt_init_workarounds(struct intel_engine_cs 
*engine)
 
/* WaDisablePooledEuLoadBalancingFix:bxt */
if (IS_BXT_REVID(dev_priv, BXT_REVID_B0, REVID_FOREVER)) {
-   WA_SET_BIT_MASKED(FF_SLICE_CS_CHICKEN2,
- GEN9_POOLED_EU_LOAD_BALANCING_FIX_DISABLE);
+   I915_WRITE(FF_SLICE_CS_CHICKEN2,
+  
_MASKED_BIT_ENABLE(GEN9_POOLED_EU_LOAD_BALANCING_FIX_DISABLE));
}
 
/* WaDisableSbeCacheDispatchPortSharing:bxt */
-- 
1.9.1

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

[Intel-gfx] [PATCH 2/6] drm/i915: Transform WaDisableI2mCycleOnWRPort into a simple reg write

[Oscar Mateo]

GAMT_CHKN_BIT_REG does not live in the context.

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Rodrigo Vivi 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 4600325..7c384d5 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1072,10 +1072,11 @@ static int cnl_init_workarounds(struct intel_engine_cs 
*engine)
struct drm_i915_private *dev_priv = engine->i915;
int ret;
 
-   /* WaDisableI2mCycleOnWRPort: cnl (pre-prod) */
+   /* WaDisableI2mCycleOnWRPort:cnl (pre-prod) */
if (IS_CNL_REVID(dev_priv, CNL_REVID_B0, CNL_REVID_B0))
-   WA_SET_BIT(GAMT_CHKN_BIT_REG,
-  GAMT_CHKN_DISABLE_I2M_CYCLE_ON_WR_PORT);
+   I915_WRITE(GAMT_CHKN_BIT_REG,
+  (I915_READ(GAMT_CHKN_BIT_REG) |
+   GAMT_CHKN_DISABLE_I2M_CYCLE_ON_WR_PORT));
 
/* WaForceContextSaveRestoreNonCoherent:cnl */
WA_SET_BIT_MASKED(CNL_HDC_CHICKEN0,
-- 
1.9.1

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

[Intel-gfx] [PATCH 1/6] drm/i915: Transform WaInPlaceDecompressionHang into a simple reg write

[Oscar Mateo]

Afaict, GEN9_GAMT_ECO_REG_RW_IA does not live in the context, so writing
it on every context creation is overkill (and wrong).

v2: Missing end parenthesis

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Rodrigo Vivi 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 25 +++--
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 23812ec..4600325 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -985,8 +985,9 @@ static int skl_init_workarounds(struct intel_engine_cs 
*engine)
 
/* WaInPlaceDecompressionHang:skl */
if (IS_SKL_REVID(dev_priv, SKL_REVID_H0, REVID_FOREVER))
-   WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
-  GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
+   I915_WRITE(GEN9_GAMT_ECO_REG_RW_IA,
+  (I915_READ(GEN9_GAMT_ECO_REG_RW_IA) |
+   GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS));
 
/* WaDisableLSQCROPERFforOCL:skl */
ret = wa_ring_whitelist_reg(engine, GEN8_L3SQCREG4);
@@ -1059,8 +1060,9 @@ static int bxt_init_workarounds(struct intel_engine_cs 
*engine)
 
/* WaInPlaceDecompressionHang:bxt */
if (IS_BXT_REVID(dev_priv, BXT_REVID_C0, REVID_FOREVER))
-   WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
-  GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
+   I915_WRITE(GEN9_GAMT_ECO_REG_RW_IA,
+  (I915_READ(GEN9_GAMT_ECO_REG_RW_IA) |
+   GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS));
 
return 0;
 }
@@ -1089,8 +1091,9 @@ static int cnl_init_workarounds(struct intel_engine_cs 
*engine)
  GEN8_CSC2_SBE_VUE_CACHE_CONSERVATIVE);
 
/* WaInPlaceDecompressionHang:cnl */
-   WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
-  GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
+   I915_WRITE(GEN9_GAMT_ECO_REG_RW_IA,
+  (I915_READ(GEN9_GAMT_ECO_REG_RW_IA) |
+   GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS));
 
/* WaPushConstantDereferenceHoldDisable:cnl */
WA_SET_BIT(GEN7_ROW_CHICKEN2, PUSH_CONSTANT_DEREF_DISABLE);
@@ -1143,8 +1146,9 @@ static int kbl_init_workarounds(struct intel_engine_cs 
*engine)
GEN7_SBE_SS_CACHE_DISPATCH_PORT_SHARING_DISABLE);
 
/* WaInPlaceDecompressionHang:kbl */
-   WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
-  GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
+   I915_WRITE(GEN9_GAMT_ECO_REG_RW_IA,
+  (I915_READ(GEN9_GAMT_ECO_REG_RW_IA) |
+   GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS));
 
/* WaDisableLSQCROPERFforOCL:kbl */
ret = wa_ring_whitelist_reg(engine, GEN8_L3SQCREG4);
@@ -1196,8 +1200,9 @@ static int cfl_init_workarounds(struct intel_engine_cs 
*engine)
GEN7_SBE_SS_CACHE_DISPATCH_PORT_SHARING_DISABLE);
 
/* WaInPlaceDecompressionHang:cfl */
-   WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
-  GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
+   I915_WRITE(GEN9_GAMT_ECO_REG_RW_IA,
+  (I915_READ(GEN9_GAMT_ECO_REG_RW_IA) |
+   GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS));
 
return 0;
 }
-- 
1.9.1

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

[Intel-gfx] [PATCH v2] drm/dp/mst: Sideband message transaction to power up/down nodes

[Dhinakaran Pandiyan]

The POWER_DOWN_PHY and POWER_UP_PHY sideband message transactions allow
the source to reqest any node in a mst path or a whole path to be
powered down or up. This allows drivers to target a specific sink in the
MST topology, an improvement over just power managing the imediate
downstream device. Secondly, since the request-reply protocol waits for an
ACK, we can be sure that a downstream sink has enough time to respond to a
power up/down request.

v2: Fix memory leak (Lyude)
Cc: Lyude 
Cc: Ville Syrjälä 
Cc: Harry Wentland 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 75 +++
 include/drm/drm_dp_mst_helper.h   |  2 +
 2 files changed, 77 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 41b492f99955..9bc5049e7e59 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -294,6 +294,12 @@ static void drm_dp_encode_sideband_req(struct 
drm_dp_sideband_msg_req_body *req,
memcpy([idx], req->u.i2c_write.bytes, 
req->u.i2c_write.num_bytes);
idx += req->u.i2c_write.num_bytes;
break;
+
+   case DP_POWER_DOWN_PHY:
+   case DP_POWER_UP_PHY:
+   buf[idx] = (req->u.port_num.port_number & 0xf) << 4;
+   idx++;
+   break;
}
raw->cur_len = idx;
 }
@@ -538,6 +544,22 @@ static bool drm_dp_sideband_parse_query_payload_ack(struct 
drm_dp_sideband_msg_r
return false;
 }
 
+
+static bool drm_dp_sideband_parse_power_updown_phy_ack(struct 
drm_dp_sideband_msg_rx *raw,
+  struct 
drm_dp_sideband_msg_reply_body *repmsg)
+{
+   int idx = 1;
+
+   repmsg->u.port_number.port_number = (raw->msg[idx] >> 4) & 0xf;
+   idx++;
+   if (idx > raw->curlen) {
+   DRM_DEBUG_KMS("power up/down phy parse length fail %d %d\n",
+ idx, raw->curlen);
+   return false;
+   }
+   return true;
+}
+
 static bool drm_dp_sideband_parse_reply(struct drm_dp_sideband_msg_rx *raw,
struct drm_dp_sideband_msg_reply_body 
*msg)
 {
@@ -567,6 +589,9 @@ static bool drm_dp_sideband_parse_reply(struct 
drm_dp_sideband_msg_rx *raw,
return drm_dp_sideband_parse_enum_path_resources_ack(raw, msg);
case DP_ALLOCATE_PAYLOAD:
return drm_dp_sideband_parse_allocate_payload_ack(raw, msg);
+   case DP_POWER_DOWN_PHY:
+   case DP_POWER_UP_PHY:
+   return drm_dp_sideband_parse_power_updown_phy_ack(raw, msg);
default:
DRM_ERROR("Got unknown reply 0x%02x\n", msg->req_type);
return false;
@@ -693,6 +718,22 @@ static int build_allocate_payload(struct 
drm_dp_sideband_msg_tx *msg, int port_n
return 0;
 }
 
+static int build_power_updown_phy(struct drm_dp_sideband_msg_tx *msg,
+ int port_num, bool power_up)
+{
+   struct drm_dp_sideband_msg_req_body req;
+
+   if (power_up)
+   req.req_type = DP_POWER_UP_PHY;
+   else
+   req.req_type = DP_POWER_DOWN_PHY;
+
+   req.u.port_num.port_number = port_num;
+   drm_dp_encode_sideband_req(, msg);
+   msg->path_msg = true;
+   return 0;
+}
+
 static int drm_dp_mst_assign_payload_id(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_vcpi *vcpi)
 {
@@ -1724,6 +1765,40 @@ static int drm_dp_payload_send_msg(struct 
drm_dp_mst_topology_mgr *mgr,
return ret;
 }
 
+int drm_dp_send_power_updown_phy(struct drm_dp_mst_topology_mgr *mgr,
+struct drm_dp_mst_port *port, bool power_up)
+{
+   struct drm_dp_sideband_msg_tx *txmsg;
+   int len, ret;
+
+   port = drm_dp_get_validated_port_ref(mgr, port);
+   if (!port)
+   return -EINVAL;
+
+   txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
+   if (!txmsg) {
+   drm_dp_put_port(port);
+   return -ENOMEM;
+   }
+
+   txmsg->dst = port->parent;
+   len = build_power_updown_phy(txmsg, port->port_num, power_up);
+   drm_dp_queue_down_tx(mgr, txmsg);
+
+   ret = drm_dp_mst_wait_tx_reply(port->parent, txmsg);
+   if (ret > 0) {
+   if (txmsg->reply.reply_type == 1)
+   ret = -EINVAL;
+   else
+   ret = 0;
+   }
+   kfree(txmsg);
+   drm_dp_put_port(port);
+
+   return ret;
+}
+EXPORT_SYMBOL(drm_dp_send_power_updown_phy);
+
 static int drm_dp_create_payload_step1(struct drm_dp_mst_topology_mgr *mgr,
   int id,
   struct drm_dp_payload *payload)
diff --git 

[Intel-gfx] [PATCH 4/6] drm/i915: Transform WaDisableGafsUnitClkGating into a simple reg write

[Oscar Mateo]

GEN7_UCGCTL4 does not live in the context.

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Rodrigo Vivi 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index cdd86ef..a22a1d1 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -981,7 +981,8 @@ static int skl_init_workarounds(struct intel_engine_cs 
*engine)
   GEN9_GAPS_TSV_CREDIT_DISABLE));
 
/* WaDisableGafsUnitClkGating:skl */
-   WA_SET_BIT(GEN7_UCGCTL4, GEN8_EU_GAUNIT_CLOCK_GATE_DISABLE);
+   I915_WRITE(GEN7_UCGCTL4, (I915_READ(GEN7_UCGCTL4) |
+ GEN8_EU_GAUNIT_CLOCK_GATE_DISABLE);
 
/* WaInPlaceDecompressionHang:skl */
if (IS_SKL_REVID(dev_priv, SKL_REVID_H0, REVID_FOREVER))
@@ -1139,7 +1140,8 @@ static int kbl_init_workarounds(struct intel_engine_cs 
*engine)
  GEN8_SBE_DISABLE_REPLAY_BUF_OPTIMIZATION);
 
/* WaDisableGafsUnitClkGating:kbl */
-   WA_SET_BIT(GEN7_UCGCTL4, GEN8_EU_GAUNIT_CLOCK_GATE_DISABLE);
+   I915_WRITE(GEN7_UCGCTL4, (I915_READ(GEN7_UCGCTL4) |
+ GEN8_EU_GAUNIT_CLOCK_GATE_DISABLE);
 
/* WaDisableSbeCacheDispatchPortSharing:kbl */
WA_SET_BIT_MASKED(
@@ -1193,7 +1195,8 @@ static int cfl_init_workarounds(struct intel_engine_cs 
*engine)
  GEN8_SBE_DISABLE_REPLAY_BUF_OPTIMIZATION);
 
/* WaDisableGafsUnitClkGating:cfl */
-   WA_SET_BIT(GEN7_UCGCTL4, GEN8_EU_GAUNIT_CLOCK_GATE_DISABLE);
+   I915_WRITE(GEN7_UCGCTL4, (I915_READ(GEN7_UCGCTL4) |
+ GEN8_EU_GAUNIT_CLOCK_GATE_DISABLE));
 
/* WaDisableSbeCacheDispatchPortSharing:cfl */
WA_SET_BIT_MASKED(
-- 
1.9.1

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Kill GEN_RANGE in favor of INTEL_GEN.

[Patchwork]

== Series Details ==

Series: drm/i915: Kill GEN_RANGE in favor of INTEL_GEN.
URL   : https://patchwork.freedesktop.org/series/29903/
State : warning

== Summary ==

Test kms_busy:
Subgroup basic-modeset-C:
pass   -> SKIP   (shard-hsw)
Test kms_plane:
Subgroup plane-position-hole-dpms-pipe-B-planes:
pass   -> SKIP   (shard-hsw)
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-hsw) fdo#100047
Test kms_vblank:
Subgroup accuracy-idle:
fail   -> PASS   (shard-hsw)
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912

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

shard-hswtotal:2174 pass:1180 dwarn:0   dfail:0   fail:16  skip:978 
time:9268s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5597/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/cnl: WaThrottleEUPerfToAvoidTDBackPressure:cnl(pre-prod)

[Rodrigo Vivi]

On Wed, Sep 6, 2017 at 3:03 PM, Rodrigo Vivi  wrote:
> Wa for B-stepping only.
>
> A for a hang issue that requires throttling EU performace
> to 12.5% to avoid back pressure to thread dispatch
>
> v2: Rebased. No change from v1.
>
> Signed-off-by: Rodrigo Vivi 
> Reviewed-by: Oscar Mateo 

merged to dinq. thanks for reviewing it.

> ---
>  drivers/gpu/drm/i915/i915_reg.h| 1 +
>  drivers/gpu/drm/i915/intel_engine_cs.c | 4 
>  2 files changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 5651081ff789..8f3645cd8370 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8058,6 +8058,7 @@ enum {
>  #define   FLOW_CONTROL_ENABLE  (1<<15)
>  #define   PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE(1<<8)
>  #define   STALL_DOP_GATING_DISABLE (1<<5)
> +#define   THROTTLE_12_5(7<<2)
>
>  #define GEN7_ROW_CHICKEN2  _MMIO(0xe4f4)
>  #define GEN7_ROW_CHICKEN2_GT2  _MMIO(0xf4f4)
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 23812ec23969..b8e9a234af2d 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -1079,6 +1079,10 @@ static int cnl_init_workarounds(struct intel_engine_cs 
> *engine)
> WA_SET_BIT_MASKED(CNL_HDC_CHICKEN0,
>   HDC_FORCE_CONTEXT_SAVE_RESTORE_NON_COHERENT);
>
> +   /* WaThrottleEUPerfToAvoidTDBackPressure:cnl(pre-prod) */
> +   if (IS_CNL_REVID(dev_priv, CNL_REVID_B0, CNL_REVID_B0))
> +   WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN, THROTTLE_12_5);
> +
> /* WaDisableReplayBufferBankArbitrationOptimization:cnl */
> WA_SET_BIT_MASKED(COMMON_SLICE_CHICKEN2,
>   GEN8_SBE_DISABLE_REPLAY_BUF_OPTIMIZATION);
> --
> 2.13.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Disable snooping (userptr, set-cache-level) on gen4

[Patchwork]

== Series Details ==

Series: drm/i915: Disable snooping (userptr, set-cache-level) on gen4
URL   : https://patchwork.freedesktop.org/series/29901/
State : warning

== Summary ==

Test kms_atomic_transition:
Subgroup plane-use-after-nonblocking-unbind:
fail   -> INCOMPLETE (shard-hsw) fdo#101847
Test kms_vblank:
Subgroup accuracy-idle:
fail   -> PASS   (shard-hsw)
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-hsw) fdo#100047
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test kms_cursor_legacy:
Subgroup basic-flip-after-cursor-varying-size:
pass   -> SKIP   (shard-hsw)

fdo#101847 https://bugs.freedesktop.org/show_bug.cgi?id=101847
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912

shard-hswtotal: pass:1205 dwarn:0   dfail:0   fail:15  skip:1001 
time:9511s

== Logs ==

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

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Add NV12 as supported format for primary plane

[Kristian Høgsberg]

On Wed, Sep 6, 2017 at 3:02 PM, Matt Roper  wrote:
> On Wed, Sep 06, 2017 at 02:49:07PM -0700, Kristian Høgsberg wrote:
>> On Wed, Sep 6, 2017 at 1:17 PM, Matt Roper  wrote:
>> > On Wed, Sep 06, 2017 at 12:12:10PM -0700, Rodrigo Vivi wrote:
>> >> On Wed, Sep 06, 2017 at 09:36:27AM -0700, Matt Roper wrote:
>> >> > On Mon, Aug 28, 2017 at 04:22:20PM +0530, Vidya Srinivas wrote:
>> >> > > From: Chandra Konduru 
>> >> > >
>> >> > > This patch adds NV12 to list of supported formats for
>> >> > > primary plane
>> >> > >
>> >> > > v2: Rebased (Chandra Konduru)
>> >> > >
>> >> > > v3: Rebased (me)
>> >> > >
>> >> > > v4: Review comments by Ville addressed
>> >> > >   Removed the skl_primary_formats_with_nv12 and
>> >> > >   added NV12 case in existing skl_primary_formats
>> >> > >
>> >> > > v5: Rebased (me)
>> >> > >
>> >> > > v6: Missed the Tested-by/Reviewed-by in the previous series
>> >> > >   Adding the same to commit message in this version.
>> >> > >
>> >> > > v7: Review comments by Ville addressed
>> >> > >   Restricting the NV12 for BXT and on PIPE A and B
>> >> > >   Rebased (me)
>> >> > >
>> >> > > v8: 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_display.c | 26 --
>> >> > >  1 file changed, 24 insertions(+), 2 deletions(-)
>> >> > >
>> >> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> >> > > b/drivers/gpu/drm/i915/intel_display.c
>> >> > > index 4e73d88..6cf8806 100644
>> >> > > --- a/drivers/gpu/drm/i915/intel_display.c
>> >> > > +++ b/drivers/gpu/drm/i915/intel_display.c
>> >> > > @@ -106,6 +106,22 @@
>> >> > >   DRM_FORMAT_MOD_INVALID
>> >> > >  };
>> >> > >
>> >> > > +static const uint32_t nv12_primary_formats[] = {
>> >> > > + DRM_FORMAT_C8,
>> >> > > + DRM_FORMAT_RGB565,
>> >> > > + DRM_FORMAT_XRGB,
>> >> > > + DRM_FORMAT_XBGR,
>> >> > > + DRM_FORMAT_ARGB,
>> >> > > + DRM_FORMAT_ABGR,
>> >> > > + DRM_FORMAT_XRGB2101010,
>> >> > > + DRM_FORMAT_XBGR2101010,
>> >> > > + DRM_FORMAT_YUYV,
>> >> > > + DRM_FORMAT_YVYU,
>> >> > > + DRM_FORMAT_UYVY,
>> >> > > + DRM_FORMAT_VYUY,
>> >> > > + DRM_FORMAT_NV12,
>> >> > > +};
>> >> > > +
>> >> > >  /* Cursor formats */
>> >> > >  static const uint32_t intel_cursor_formats[] = {
>> >> > >   DRM_FORMAT_ARGB,
>> >> > > @@ -13280,8 +13296,14 @@ static bool 
>> >> > > intel_cursor_plane_format_mod_supported(struct drm_plane *plane,
>> >> > >   primary->update_plane = skylake_update_primary_plane;
>> >> > >   primary->disable_plane = skylake_disable_primary_plane;
>> >> > >   } else if (INTEL_GEN(dev_priv) >= 9) {
>> >> > > - intel_primary_formats = skl_primary_formats;
>> >> > > - num_formats = ARRAY_SIZE(skl_primary_formats);
>> >> > > + if (IS_BROXTON(dev_priv) &&
>> >> >
>> >> > I believe this needs to be
>> >> >
>> >> >if (IS_BXT_REVID(dev_priv, BXT_REVID_D0, BXT_REVID_FOREVER) ...
>> >>
>> >> We usually use this stepping information for Workarounds. So usually
>> >> blocks around this are the non-expected default behaviour.
>> >> So I'd handle that from A0 to C0 and else the default behaviour or at 
>> >> least
>> >> ![A0,C0]...
>> >>
>> >> >
>> >> > There were unavoidable flickering/underrun issues on the earlier
>> >> > steppings due to memory fetch issues for the second color plane.  Those
>> >> > issues were only fixed on the E0 SoC stepping (which incorporates the D0
>> >> > Display/GT).
>> >>
>> >> Also we usuallly use this steppings checking with a documented W/a.
>> >> Is there one? Anything that would justify this?
>> >
>> > Unfortunately the bspec WA database still hasn't been updated to
>> > indicate that *any* SKU of can properly support NV12.  So the workaround
>> > database still just gives a general "don't use NV12 at all" statement
>> > (entry 0870 in the display WA database which is listed for "BXT:ALL").
>
> Woops, this is actually 0826, not 0870 (0870 is a different NV12 entry
> specifically for y-tile).
>
>
>> > I tried unravel what the internal communication channels are for this
>> > kind of update a few months ago, but didn't make much headway.
>>
>> What about KBL support?
>>
>
> The only NV12 workaround I see for KBL is that KBL A-step and B-step
> shouldn't do NV12 + ytile.

But does this series actually enable KBL NV12 overlays? I only see
IS_BROXTON() in the conditional - that doesn't include KBL, does it?

> Matt
>
>
>> >>
>> >> But also, is there any team there still using anything older than D0? yet?
>> >
>> > Yes, definitely.  Pre-E0 SoC's (and thus pre-D0 graphics) is what a lot
>> > of 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: WaThrottleEUPerfToAvoidTDBackPressure:cnl(pre-prod)

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: WaThrottleEUPerfToAvoidTDBackPressure:cnl(pre-prod)
URL   : https://patchwork.freedesktop.org/series/29909/
State : success

== Summary ==

Series 29909v1 drm/i915/cnl: WaThrottleEUPerfToAvoidTDBackPressure:cnl(pre-prod)
https://patchwork.freedesktop.org/api/1.0/series/29909/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-snb-2600)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> FAIL   (fi-snb-2600) fdo#100215
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-byt-n2820) fdo#101705
Test pm_rpm:
Subgroup basic-pci-d3-state:
skip   -> PASS   (fi-cfl-s) fdo#102294

fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215
fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705
fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:455s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:444s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:363s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:561s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:254s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:527s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:517s
fi-cfl-s total:289  pass:250  dwarn:4   dfail:0   fail:0   skip:35  
time:460s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:437s
fi-glk-2atotal:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:609s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:444s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:422s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:428s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:499s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:474s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:512s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:600s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:601s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:532s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:473s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:529s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:517s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:440s
fi-skl-x1585ltotal:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:488s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:551s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:1   skip:39  
time:403s
fi-bxt-j4205 failed to connect after reboot

c61e26955263c5fda3f0ed20d669553ba4b9eee6 drm-tip: 2017y-09m-06d-21h-13m-23s UTC 
integration manifest
cdc970a9edc0 drm/i915/cnl: WaThrottleEUPerfToAvoidTDBackPressure:cnl(pre-prod)

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915/cnl: WaThrottleEUPerfToAvoidTDBackPressure:cnl(pre-prod)

[Rodrigo Vivi]

Wa for B-stepping only.

A for a hang issue that requires throttling EU performace
to 12.5% to avoid back pressure to thread dispatch

v2: Rebased. No change from v1.

Signed-off-by: Rodrigo Vivi 
Reviewed-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/i915_reg.h| 1 +
 drivers/gpu/drm/i915/intel_engine_cs.c | 4 
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5651081ff789..8f3645cd8370 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8058,6 +8058,7 @@ enum {
 #define   FLOW_CONTROL_ENABLE  (1<<15)
 #define   PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE(1<<8)
 #define   STALL_DOP_GATING_DISABLE (1<<5)
+#define   THROTTLE_12_5(7<<2)
 
 #define GEN7_ROW_CHICKEN2  _MMIO(0xe4f4)
 #define GEN7_ROW_CHICKEN2_GT2  _MMIO(0xf4f4)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 23812ec23969..b8e9a234af2d 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1079,6 +1079,10 @@ static int cnl_init_workarounds(struct intel_engine_cs 
*engine)
WA_SET_BIT_MASKED(CNL_HDC_CHICKEN0,
  HDC_FORCE_CONTEXT_SAVE_RESTORE_NON_COHERENT);
 
+   /* WaThrottleEUPerfToAvoidTDBackPressure:cnl(pre-prod) */
+   if (IS_CNL_REVID(dev_priv, CNL_REVID_B0, CNL_REVID_B0))
+   WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN, THROTTLE_12_5);
+
/* WaDisableReplayBufferBankArbitrationOptimization:cnl */
WA_SET_BIT_MASKED(COMMON_SLICE_CHICKEN2,
  GEN8_SBE_DISABLE_REPLAY_BUF_OPTIMIZATION);
-- 
2.13.2

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

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Add NV12 as supported format for primary plane

[Matt Roper]

On Wed, Sep 06, 2017 at 02:49:07PM -0700, Kristian Høgsberg wrote:
> On Wed, Sep 6, 2017 at 1:17 PM, Matt Roper  wrote:
> > On Wed, Sep 06, 2017 at 12:12:10PM -0700, Rodrigo Vivi wrote:
> >> On Wed, Sep 06, 2017 at 09:36:27AM -0700, Matt Roper wrote:
> >> > On Mon, Aug 28, 2017 at 04:22:20PM +0530, Vidya Srinivas wrote:
> >> > > From: Chandra Konduru 
> >> > >
> >> > > This patch adds NV12 to list of supported formats for
> >> > > primary plane
> >> > >
> >> > > v2: Rebased (Chandra Konduru)
> >> > >
> >> > > v3: Rebased (me)
> >> > >
> >> > > v4: Review comments by Ville addressed
> >> > >   Removed the skl_primary_formats_with_nv12 and
> >> > >   added NV12 case in existing skl_primary_formats
> >> > >
> >> > > v5: Rebased (me)
> >> > >
> >> > > v6: Missed the Tested-by/Reviewed-by in the previous series
> >> > >   Adding the same to commit message in this version.
> >> > >
> >> > > v7: Review comments by Ville addressed
> >> > >   Restricting the NV12 for BXT and on PIPE A and B
> >> > >   Rebased (me)
> >> > >
> >> > > v8: 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_display.c | 26 --
> >> > >  1 file changed, 24 insertions(+), 2 deletions(-)
> >> > >
> >> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >> > > b/drivers/gpu/drm/i915/intel_display.c
> >> > > index 4e73d88..6cf8806 100644
> >> > > --- a/drivers/gpu/drm/i915/intel_display.c
> >> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> >> > > @@ -106,6 +106,22 @@
> >> > >   DRM_FORMAT_MOD_INVALID
> >> > >  };
> >> > >
> >> > > +static const uint32_t nv12_primary_formats[] = {
> >> > > + DRM_FORMAT_C8,
> >> > > + DRM_FORMAT_RGB565,
> >> > > + DRM_FORMAT_XRGB,
> >> > > + DRM_FORMAT_XBGR,
> >> > > + DRM_FORMAT_ARGB,
> >> > > + DRM_FORMAT_ABGR,
> >> > > + DRM_FORMAT_XRGB2101010,
> >> > > + DRM_FORMAT_XBGR2101010,
> >> > > + DRM_FORMAT_YUYV,
> >> > > + DRM_FORMAT_YVYU,
> >> > > + DRM_FORMAT_UYVY,
> >> > > + DRM_FORMAT_VYUY,
> >> > > + DRM_FORMAT_NV12,
> >> > > +};
> >> > > +
> >> > >  /* Cursor formats */
> >> > >  static const uint32_t intel_cursor_formats[] = {
> >> > >   DRM_FORMAT_ARGB,
> >> > > @@ -13280,8 +13296,14 @@ static bool 
> >> > > intel_cursor_plane_format_mod_supported(struct drm_plane *plane,
> >> > >   primary->update_plane = skylake_update_primary_plane;
> >> > >   primary->disable_plane = skylake_disable_primary_plane;
> >> > >   } else if (INTEL_GEN(dev_priv) >= 9) {
> >> > > - intel_primary_formats = skl_primary_formats;
> >> > > - num_formats = ARRAY_SIZE(skl_primary_formats);
> >> > > + if (IS_BROXTON(dev_priv) &&
> >> >
> >> > I believe this needs to be
> >> >
> >> >if (IS_BXT_REVID(dev_priv, BXT_REVID_D0, BXT_REVID_FOREVER) ...
> >>
> >> We usually use this stepping information for Workarounds. So usually
> >> blocks around this are the non-expected default behaviour.
> >> So I'd handle that from A0 to C0 and else the default behaviour or at least
> >> ![A0,C0]...
> >>
> >> >
> >> > There were unavoidable flickering/underrun issues on the earlier
> >> > steppings due to memory fetch issues for the second color plane.  Those
> >> > issues were only fixed on the E0 SoC stepping (which incorporates the D0
> >> > Display/GT).
> >>
> >> Also we usuallly use this steppings checking with a documented W/a.
> >> Is there one? Anything that would justify this?
> >
> > Unfortunately the bspec WA database still hasn't been updated to
> > indicate that *any* SKU of can properly support NV12.  So the workaround
> > database still just gives a general "don't use NV12 at all" statement
> > (entry 0870 in the display WA database which is listed for "BXT:ALL").

Woops, this is actually 0826, not 0870 (0870 is a different NV12 entry
specifically for y-tile).


> > I tried unravel what the internal communication channels are for this
> > kind of update a few months ago, but didn't make much headway.
> 
> What about KBL support?
> 

The only NV12 workaround I see for KBL is that KBL A-step and B-step
shouldn't do NV12 + ytile.


Matt


> >>
> >> But also, is there any team there still using anything older than D0? yet?
> >
> > Yes, definitely.  Pre-E0 SoC's (and thus pre-D0 graphics) is what a lot
> > of our embedded customers have already gone to production with.
> >
> >
> > Matt
> >
> >
> >>
> >> If we don't know anyone probably pure IS_BROXTON is the best option.
> >>
> >> >
> >> > Same change for your sprite plane changes in the next patch.
> >> >
> >> >
> >> > Matt
> >> >
> >> > > + ((pipe == PIPE_A || pipe == PIPE_B))) {

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Transform WaInPlaceDecompressionHang to a simple reg write

[Patchwork]

== Series Details ==

Series: drm/i915: Transform WaInPlaceDecompressionHang to a simple reg write
URL   : https://patchwork.freedesktop.org/series/29906/
State : failure

== Summary ==

  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CHK include/generated/bounds.h
  CHK include/generated/timeconst.h
  CHK include/generated/asm-offsets.h
  CALLscripts/checksyscalls.sh
  CHK scripts/mod/devicetable-offsets.h
  CHK include/generated/compile.h
  CHK kernel/config_data.h
  CC [M]  drivers/gpu/drm/i915/intel_engine_cs.o
In file included from drivers/gpu/drm/i915/selftests/mock_engine.h:32:0,
 from drivers/gpu/drm/i915/selftests/mock_engine.c:25,
 from drivers/gpu/drm/i915/intel_engine_cs.c:1402:
drivers/gpu/drm/i915/selftests/../intel_ringbuffer.h: In function 
‘skl_init_workarounds’:
drivers/gpu/drm/i915/selftests/../intel_ringbuffer.h:740:0: error: unterminated 
argument list invoking macro "I915_WRITE"
 #endif /* _INTEL_RINGBUFFER_H_ */
 
drivers/gpu/drm/i915/intel_engine_cs.c:988:3: error: ‘I915_WRITE’ undeclared 
(first use in this function)
   I915_WRITE(GEN9_GAMT_ECO_REG_RW_IA,
   ^~
drivers/gpu/drm/i915/intel_engine_cs.c:988:3: note: each undeclared identifier 
is reported only once for each function it appears in
In file included from drivers/gpu/drm/i915/selftests/mock_engine.c:25:0,
 from drivers/gpu/drm/i915/intel_engine_cs.c:1402:
drivers/gpu/drm/i915/selftests/mock_engine.h:34:1: error: expected ‘;’ before 
‘struct’
 struct mock_engine {
 ^~
drivers/gpu/drm/i915/selftests/mock_engine.h:42:1: error: ISO C90 forbids mixed 
declarations and code [-Werror=declaration-after-statement]
 struct intel_engine_cs *mock_engine(struct drm_i915_private *i915,
 ^~
drivers/gpu/drm/i915/selftests/mock_engine.h:49:20: error: invalid storage 
class for function ‘mock_seqno_advance’
 static inline void mock_seqno_advance(struct intel_engine_cs *engine, u32 
seqno)
^~
In file included from drivers/gpu/drm/i915/intel_engine_cs.c:1402:0:
drivers/gpu/drm/i915/selftests/mock_engine.c:28:50: error: ‘struct mock_engine’ 
declared inside parameter list will not be visible outside of this definition 
or declaration [-Werror]
 static struct mock_request *first_request(struct mock_engine *engine)
  ^~~
drivers/gpu/drm/i915/selftests/mock_engine.c:28:29: error: invalid storage 
class for function ‘first_request’
 static struct mock_request *first_request(struct mock_engine *engine)
 ^
In file included from ./include/linux/preempt.h:10:0,
 from ./include/linux/spinlock.h:50,
 from ./include/linux/mmzone.h:7,
 from ./include/linux/gfp.h:5,
 from ./include/linux/slab.h:14,
 from ./include/linux/io-mapping.h:22,
 from drivers/gpu/drm/i915/i915_drv.h:36,
 from drivers/gpu/drm/i915/intel_engine_cs.c:25:
drivers/gpu/drm/i915/selftests/mock_engine.c: In function ‘first_request’:
drivers/gpu/drm/i915/selftests/mock_engine.c:30:41: error: dereferencing 
pointer to incomplete type ‘struct mock_engine’
  return list_first_entry_or_null(>hw_queue,
 ^
./include/linux/list.h:398:30: note: in definition of macro 
‘list_first_entry_or_null’
  struct list_head *head__ = (ptr); \
  ^~~
In file included from drivers/gpu/drm/i915/intel_engine_cs.c:1402:0:
drivers/gpu/drm/i915/selftests/mock_engine.c: In function 
‘skl_init_workarounds’:
drivers/gpu/drm/i915/selftests/mock_engine.c:35:13: error: invalid storage 
class for function ‘hw_delay_complete’
 static void hw_delay_complete(unsigned long data)
 ^
drivers/gpu/drm/i915/selftests/mock_engine.c: In function ‘hw_delay_complete’:
drivers/gpu/drm/i915/selftests/mock_engine.c:40:19: error: dereferencing 
pointer to incomplete type ‘struct mock_engine’
  spin_lock(>hw_lock);
   ^~
drivers/gpu/drm/i915/selftests/mock_engine.c:42:26: error: passing argument 1 
of ‘first_request’ from incompatible pointer type 
[-Werror=incompatible-pointer-types]
  request = first_request(engine);
  ^~
drivers/gpu/drm/i915/selftests/mock_engine.c:28:29: note: expected ‘struct 
mock_engine *’ but argument is of type ‘struct mock_engine *’
 static struct mock_request *first_request(struct mock_engine *engine)
 ^
drivers/gpu/drm/i915/selftests/mock_engine.c:48:26: error: passing argument 1 
of ‘first_request’ from incompatible pointer type 
[-Werror=incompatible-pointer-types]
  request = first_request(engine);
  ^~
drivers/gpu/drm/i915/selftests/mock_engine.c:28:29: note: expected ‘struct 
mock_engine *’ 

Re: [Intel-gfx] [PATCH] drm/i915: Clear local engine-needs-reset bit if in progress elsewhere

[Chris Wilson]

Quoting Jeff McGee (2017-08-29 18:01:47)
> On Tue, Aug 29, 2017 at 04:17:46PM +0100, Chris Wilson wrote:
> > Quoting Jeff McGee (2017-08-29 16:04:17)
> > > On Tue, Aug 29, 2017 at 10:07:18AM +0100, Chris Wilson wrote:
> > > > Quoting Jeff McGee (2017-08-28 21:18:44)
> > > > > On Mon, Aug 28, 2017 at 08:44:48PM +0100, Chris Wilson wrote:
> > > > > > Quoting jeff.mc...@intel.com (2017-08-28 20:25:30)
> > > > > > > From: Jeff McGee 
> > > > > > > 
> > > > > > > If someone else is resetting the engine we should clear our own 
> > > > > > > bit as
> > > > > > > part of skipping that engine. Otherwise we will later believe 
> > > > > > > that it
> > > > > > > has not been reset successfully and then trigger full gpu reset. 
> > > > > > > If the
> > > > > > > other guy's reset actually fails, he will trigger the full gpu 
> > > > > > > reset.
> > > > > > 
> > > > > > The reason we did continue on to the global reset was to serialise
> > > > > > i915_handle_error() with the other thread. Not a huge issue, but a
> > > > > > reasonable property to keep -- and we definitely want a to explain 
> > > > > > why
> > > > > > only one reset at a time is important.
> > > > > > 
> > > > > > bool intel_engine_lock_reset() {
> > > > > >   if (!test_and_set_bit(I915_RESET_ENGINE + engine->id,
> > > > > > >i915->gpu_error.flags))
> > > > > >   return true;
> > > > > > 
> > > > > >   intel_engine_wait_for_reset(engine);
> > > > > The current code doesn't wait for the other thread to finish the 
> > > > > reset, but
> > > > > this would add that wait. 
> > > > 
> > > > Pardon? If we can't reset the engine, we go to the full reset which is
> > > > serialised, both with individual engine resets and other globals.
> > > > 
> > > > > Did you intend that as an additional change to
> > > > > the current code? I don't think it is necessary. Each thread wants to
> > > > > reset some subset of engines, so it seems the thread can safely exit 
> > > > > as soon
> > > > > as it knows each of those engines has been reset or is being reset as 
> > > > > part
> > > > > of another thread that got the lock first. If any of the threads fail 
> > > > > to
> > > > > reset an engine they "own", then full gpu reset is assured.
> > > > 
> > > > It's unexpected for this function to return before the reset.
> > > > -Chris
> > > 
> > > I'm a bit confused, so let's go back to the original code that I was 
> > > trying
> > > to fix:
> > > 
> > > 
> > > /*
> > >  * Try engine reset when available. We fall back to full reset if
> > >  * single reset fails.
> > >  */
> > > if (intel_has_reset_engine(dev_priv)) {
> > > for_each_engine_masked(engine, dev_priv, engine_mask, 
> > > tmp) {
> > > BUILD_BUG_ON(I915_RESET_MODESET >= 
> > > I915_RESET_ENGINE);
> > > if (test_and_set_bit(I915_RESET_ENGINE + 
> > > engine->id,
> > >  _priv->gpu_error.flags))
> > > continue;
> > > 
> > > if (i915_reset_engine(engine, 0) == 0)
> > > engine_mask &= ~intel_engine_flag(engine);
> > > 
> > > clear_bit(I915_RESET_ENGINE + engine->id,
> > >   _priv->gpu_error.flags);
> > > wake_up_bit(_priv->gpu_error.flags,
> > > I915_RESET_ENGINE + engine->id);
> > > }
> > > }
> > > 
> > > if (!engine_mask)
> > > goto out;
> > > 
> > > /* Full reset needs the mutex, stop any other user trying to do 
> > > so. */
> > > 
> > > Let's say that 2 threads are here intending to reset render. #1 gets the 
> > > lock
> > > and starts the render engine-only reset. #2 fails to get the lock which 
> > > implies
> > > that someone else is in the process of resetting the render engine (with 
> > > single
> > > engine reset or full gpu reset). #2 continues on without waiting but 
> > > doesn't
> > > clear the render bit in engine_mask. So #2 will proceed to initiate a full
> > > gpu reset when it may not be necessary. That's the problem I was trying
> > > to address with my initial patch. Do you agree that #2 must clear this bit
> > > to avoid always triggering full gpu reset? If the engine-only reset done 
> > > by
> > > #1 fails, #1 will do the fallback to full gpu reset, so there is no risk 
> > > that
> > > we would miss the full gpu reset if it is really needed.
> > > 
> > > Then there is the question of whether #2 should wait around for the
> > > render engine reset by #1 to complete. It doesn't in current code and I 
> > > don't
> > > see why it needs to. But that can be a separate discussion from the above.
> > 
> > It very much does in the current code. If we can not do the per-engine
> > reset, it falls back to the global reset.

Re: [Intel-gfx] [PATCH 64/67] drm/i915/cnl: WaThrottleEUPerfToAvoidTDBackPressure:cnl(pre-prod)

[Oscar Mateo]

On 04/06/2017 12:16 PM, Rodrigo Vivi wrote:

Wa for B-stepping only.

A for a hang issue that requires throttling EU performace
to 12.5% to avoid back pressure to thread dispatch

Signed-off-by: Rodrigo Vivi 
---
  drivers/gpu/drm/i915/i915_reg.h| 1 +
  drivers/gpu/drm/i915/intel_engine_cs.c | 4 
  2 files changed, 5 insertions(+)


Reviewed-by: Oscar Mateo 


diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 67f306e..8b25119 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7839,6 +7839,7 @@ enum {
  #define   FLOW_CONTROL_ENABLE (1<<15)
  #define   PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE   (1<<8)
  #define   STALL_DOP_GATING_DISABLE(1<<5)
+#define   THROTTLE_12_5(7<<2)
  
  #define GEN7_ROW_CHICKEN2		_MMIO(0xe4f4)

  #define GEN7_ROW_CHICKEN2_GT2 _MMIO(0xf4f4)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index b5599fa..754b370 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -951,6 +951,10 @@ static int cnl_init_workarounds(struct intel_engine_cs 
*engine)
struct drm_i915_private *dev_priv = engine->i915;
int ret;
  
+	/* WaThrottleEUPerfToAvoidTDBackPressure:cnl(pre-prod) */

+   if (IS_CNL_REVID(dev_priv, CNL_REVID_B0, CNL_REVID_B0))
+   WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN, THROTTLE_12_5);
+
/* WaDisableReplayBufferBankArbitrationOptimization:cnl */
WA_SET_BIT_MASKED(COMMON_SLICE_CHICKEN2,
  GEN8_SBE_DISABLE_REPLAY_BUF_OPTIMIZATION);


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

Re: [Intel-gfx] [PATCH] drm/i915: Transform WaInPlaceDecompressionHang to a simple reg write

[Oscar Mateo]

On 09/06/2017 02:43 PM, Chris Wilson wrote:

Quoting Oscar Mateo (2017-09-06 22:27:47)


On 09/06/2017 02:19 PM, Chris Wilson wrote:

Quoting Oscar Mateo (2017-09-06 22:12:11)

Afaict, GEN9_GAMT_ECO_REG_RW_IA does not live in the context, so writing
it on every context creation is overkill (and wrong).

Cc: Mika Kuoppala 
Cc: Rodrigo Vivi 
Signed-off-by: Oscar Mateo 
---
   drivers/gpu/drm/i915/intel_engine_cs.c | 25 +++--
   1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 23812ec..9f01a5c 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -985,8 +985,9 @@ static int skl_init_workarounds(struct intel_engine_cs 
*engine)
   
  /* WaInPlaceDecompressionHang:skl */

  if (IS_SKL_REVID(dev_priv, SKL_REVID_H0, REVID_FOREVER))
-   WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
-  GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);

Anything using a precalculated RMW value for a ctx register is indeed
fishy. Whilst you are checking this register, can you check whether the
other users of WA_SET_BIT/WA_CLR_BIT are indeed context bound?
-Chris

Sure, I'll try to go through all of them (but I'd like to clarify first
if I should also be moving those I find to xxx_init_clock_gating).

The short answer is probably not, init_clock_gating we expect to be
targetting display w/a. There's not always a clear divide between GT and
display, but we keep on muttering that we should keep them them as
cleanly separated as possible so that we know where to look when
different IP blocks are updated. (And yes the name is one of those
things that we keep on waiting for someone else to fix.)
-Chris


It's not only the name, there is even a comment saying non-context, 
non-WABB GT workarounds go here:


/**
 * intel_init_clock_gating_hooks - setup the clock gating hooks
 * @dev_priv: device private
 *
 * Setup the hooks that configure which clocks of a given platform can be
 * gated and also apply various GT and display specific workarounds for 
these

 * platforms. Note that some GT specific workarounds are applied separately
 * when GPU contexts or batchbuffers start their execution.
 */


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

Re: [Intel-gfx] [GIT PULL] gvt fix for 4.14-rc1

[Vivi, Rodrigo]

On Wed, 2017-09-06 at 11:59 +0800, Zhenyu Wang wrote:
> Hi, here's one regression fix for 4.14-rc1 which made gvt init failed
> with latest linus master.

thanks.
pulled to drm-intel-next-fixes that will be sent to linus next soon.

> 
> Thanks.
> --
> The following changes since commit a42894ebb50d831ec0b7ee9bee7f5a5a37bad7e1:
> 
>   drm/i915: Update DRIVER_DATE to 20170818 (2017-08-18 22:40:45 +0200)
> 
> are available in the git repository at:
> 
>   https://github.com/01org/gvt-linux.git tags/gvt-fixes-2017-09-06
> 
> for you to fetch changes up to d02fd5f7709f1296bad5d92e7e8515ef1a05dec4:
> 
>   drm/i915/gvt: Remove one duplicated MMIO (2017-09-05 10:26:08 +0800)
> 
> 
> gvt-fixes-2017-09-06
> 
> - regression fix for gvt init failure from Jianjun
> 
> 
> Jian Jun Chen (1):
>   drm/i915/gvt: Remove one duplicated MMIO
> 
>  drivers/gpu/drm/i915/gvt/handlers.c | 1 -
>  1 file changed, 1 deletion(-)
> 

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

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Add NV12 as supported format for primary plane

[Kristian Høgsberg]

On Wed, Sep 6, 2017 at 1:17 PM, Matt Roper  wrote:
> On Wed, Sep 06, 2017 at 12:12:10PM -0700, Rodrigo Vivi wrote:
>> On Wed, Sep 06, 2017 at 09:36:27AM -0700, Matt Roper wrote:
>> > On Mon, Aug 28, 2017 at 04:22:20PM +0530, Vidya Srinivas wrote:
>> > > From: Chandra Konduru 
>> > >
>> > > This patch adds NV12 to list of supported formats for
>> > > primary plane
>> > >
>> > > v2: Rebased (Chandra Konduru)
>> > >
>> > > v3: Rebased (me)
>> > >
>> > > v4: Review comments by Ville addressed
>> > >   Removed the skl_primary_formats_with_nv12 and
>> > >   added NV12 case in existing skl_primary_formats
>> > >
>> > > v5: Rebased (me)
>> > >
>> > > v6: Missed the Tested-by/Reviewed-by in the previous series
>> > >   Adding the same to commit message in this version.
>> > >
>> > > v7: Review comments by Ville addressed
>> > >   Restricting the NV12 for BXT and on PIPE A and B
>> > >   Rebased (me)
>> > >
>> > > v8: 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_display.c | 26 --
>> > >  1 file changed, 24 insertions(+), 2 deletions(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> > > b/drivers/gpu/drm/i915/intel_display.c
>> > > index 4e73d88..6cf8806 100644
>> > > --- a/drivers/gpu/drm/i915/intel_display.c
>> > > +++ b/drivers/gpu/drm/i915/intel_display.c
>> > > @@ -106,6 +106,22 @@
>> > >   DRM_FORMAT_MOD_INVALID
>> > >  };
>> > >
>> > > +static const uint32_t nv12_primary_formats[] = {
>> > > + DRM_FORMAT_C8,
>> > > + DRM_FORMAT_RGB565,
>> > > + DRM_FORMAT_XRGB,
>> > > + DRM_FORMAT_XBGR,
>> > > + DRM_FORMAT_ARGB,
>> > > + DRM_FORMAT_ABGR,
>> > > + DRM_FORMAT_XRGB2101010,
>> > > + DRM_FORMAT_XBGR2101010,
>> > > + DRM_FORMAT_YUYV,
>> > > + DRM_FORMAT_YVYU,
>> > > + DRM_FORMAT_UYVY,
>> > > + DRM_FORMAT_VYUY,
>> > > + DRM_FORMAT_NV12,
>> > > +};
>> > > +
>> > >  /* Cursor formats */
>> > >  static const uint32_t intel_cursor_formats[] = {
>> > >   DRM_FORMAT_ARGB,
>> > > @@ -13280,8 +13296,14 @@ static bool 
>> > > intel_cursor_plane_format_mod_supported(struct drm_plane *plane,
>> > >   primary->update_plane = skylake_update_primary_plane;
>> > >   primary->disable_plane = skylake_disable_primary_plane;
>> > >   } else if (INTEL_GEN(dev_priv) >= 9) {
>> > > - intel_primary_formats = skl_primary_formats;
>> > > - num_formats = ARRAY_SIZE(skl_primary_formats);
>> > > + if (IS_BROXTON(dev_priv) &&
>> >
>> > I believe this needs to be
>> >
>> >if (IS_BXT_REVID(dev_priv, BXT_REVID_D0, BXT_REVID_FOREVER) ...
>>
>> We usually use this stepping information for Workarounds. So usually
>> blocks around this are the non-expected default behaviour.
>> So I'd handle that from A0 to C0 and else the default behaviour or at least
>> ![A0,C0]...
>>
>> >
>> > There were unavoidable flickering/underrun issues on the earlier
>> > steppings due to memory fetch issues for the second color plane.  Those
>> > issues were only fixed on the E0 SoC stepping (which incorporates the D0
>> > Display/GT).
>>
>> Also we usuallly use this steppings checking with a documented W/a.
>> Is there one? Anything that would justify this?
>
> Unfortunately the bspec WA database still hasn't been updated to
> indicate that *any* SKU of can properly support NV12.  So the workaround
> database still just gives a general "don't use NV12 at all" statement
> (entry 0870 in the display WA database which is listed for "BXT:ALL").
> I tried unravel what the internal communication channels are for this
> kind of update a few months ago, but didn't make much headway.

What about KBL support?

>>
>> But also, is there any team there still using anything older than D0? yet?
>
> Yes, definitely.  Pre-E0 SoC's (and thus pre-D0 graphics) is what a lot
> of our embedded customers have already gone to production with.
>
>
> Matt
>
>
>>
>> If we don't know anyone probably pure IS_BROXTON is the best option.
>>
>> >
>> > Same change for your sprite plane changes in the next patch.
>> >
>> >
>> > Matt
>> >
>> > > + ((pipe == PIPE_A || pipe == PIPE_B))) {
>> > > + intel_primary_formats = nv12_primary_formats;
>> > > + num_formats = ARRAY_SIZE(nv12_primary_formats);
>> > > + } else {
>> > > + intel_primary_formats = skl_primary_formats;
>> > > + num_formats = ARRAY_SIZE(skl_primary_formats);
>> > > + }
>> > >   if (pipe < PIPE_C)
>> > >   modifiers = skl_format_modifiers_ccs;
>> > >   else
>> > > --
>> > > 1.9.1
>> > >
>> > > 

Re: [Intel-gfx] [PATCH] drm/i915: Transform WaInPlaceDecompressionHang to a simple reg write

[Chris Wilson]

Quoting Oscar Mateo (2017-09-06 22:27:47)
> 
> 
> On 09/06/2017 02:19 PM, Chris Wilson wrote:
> > Quoting Oscar Mateo (2017-09-06 22:12:11)
> >> Afaict, GEN9_GAMT_ECO_REG_RW_IA does not live in the context, so writing
> >> it on every context creation is overkill (and wrong).
> >>
> >> Cc: Mika Kuoppala 
> >> Cc: Rodrigo Vivi 
> >> Signed-off-by: Oscar Mateo 
> >> ---
> >>   drivers/gpu/drm/i915/intel_engine_cs.c | 25 +++--
> >>   1 file changed, 15 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> >> b/drivers/gpu/drm/i915/intel_engine_cs.c
> >> index 23812ec..9f01a5c 100644
> >> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> >> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> >> @@ -985,8 +985,9 @@ static int skl_init_workarounds(struct intel_engine_cs 
> >> *engine)
> >>   
> >>  /* WaInPlaceDecompressionHang:skl */
> >>  if (IS_SKL_REVID(dev_priv, SKL_REVID_H0, REVID_FOREVER))
> >> -   WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
> >> -  GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
> > Anything using a precalculated RMW value for a ctx register is indeed
> > fishy. Whilst you are checking this register, can you check whether the
> > other users of WA_SET_BIT/WA_CLR_BIT are indeed context bound?
> > -Chris
> 
> Sure, I'll try to go through all of them (but I'd like to clarify first 
> if I should also be moving those I find to xxx_init_clock_gating).

The short answer is probably not, init_clock_gating we expect to be
targetting display w/a. There's not always a clear divide between GT and
display, but we keep on muttering that we should keep them them as
cleanly separated as possible so that we know where to look when
different IP blocks are updated. (And yes the name is one of those
things that we keep on waiting for someone else to fix.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Transform WaInPlaceDecompressionHang to a simple reg write

[Oscar Mateo]

On 09/06/2017 02:19 PM, Chris Wilson wrote:

Quoting Oscar Mateo (2017-09-06 22:12:11)

Afaict, GEN9_GAMT_ECO_REG_RW_IA does not live in the context, so writing
it on every context creation is overkill (and wrong).

Cc: Mika Kuoppala 
Cc: Rodrigo Vivi 
Signed-off-by: Oscar Mateo 
---
  drivers/gpu/drm/i915/intel_engine_cs.c | 25 +++--
  1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 23812ec..9f01a5c 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -985,8 +985,9 @@ static int skl_init_workarounds(struct intel_engine_cs 
*engine)
  
 /* WaInPlaceDecompressionHang:skl */

 if (IS_SKL_REVID(dev_priv, SKL_REVID_H0, REVID_FOREVER))
-   WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
-  GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);

Anything using a precalculated RMW value for a ctx register is indeed
fishy. Whilst you are checking this register, can you check whether the
other users of WA_SET_BIT/WA_CLR_BIT are indeed context bound?
-Chris


Sure, I'll try to go through all of them (but I'd like to clarify first 
if I should also be moving those I find to xxx_init_clock_gating).


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

Re: [Intel-gfx] [PATCH] drm/i915: Transform WaInPlaceDecompressionHang to a simple reg write

[Chris Wilson]

Quoting Oscar Mateo (2017-09-06 22:12:11)
> Afaict, GEN9_GAMT_ECO_REG_RW_IA does not live in the context, so writing
> it on every context creation is overkill (and wrong).
> 
> Cc: Mika Kuoppala 
> Cc: Rodrigo Vivi 
> Signed-off-by: Oscar Mateo 
> ---
>  drivers/gpu/drm/i915/intel_engine_cs.c | 25 +++--
>  1 file changed, 15 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 23812ec..9f01a5c 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -985,8 +985,9 @@ static int skl_init_workarounds(struct intel_engine_cs 
> *engine)
>  
> /* WaInPlaceDecompressionHang:skl */
> if (IS_SKL_REVID(dev_priv, SKL_REVID_H0, REVID_FOREVER))
> -   WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
> -  GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);

Anything using a precalculated RMW value for a ctx register is indeed
fishy. Whilst you are checking this register, can you check whether the
other users of WA_SET_BIT/WA_CLR_BIT are indeed context bound?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Transform WaInPlaceDecompressionHang to a simple reg write

[Oscar Mateo]

Hey Mika,

Regarding this patch: is there a consensus on where is the most 
appropriate place to apply workarounds? My understanding is that 
per-context workarounds (WAS_SET_BIT, etc...) go in 
xxx_init_workarounds, while those that are needed only during 
initialization (I915_WRITE) go in xxx_init_clock_gating. But it doesn't 
look like this general rule is being followed (probably because 
xxx_init_clock_gating is a very misleading name?).


This has probably been discussed before, so it would be good if we could 
document the answer somewhere (maybe it already is?).


Thanks,

Oscar



On 09/06/2017 02:12 PM, Oscar Mateo wrote:

Afaict, GEN9_GAMT_ECO_REG_RW_IA does not live in the context, so writing
it on every context creation is overkill (and wrong).

Cc: Mika Kuoppala 
Cc: Rodrigo Vivi 
Signed-off-by: Oscar Mateo 
---
  drivers/gpu/drm/i915/intel_engine_cs.c | 25 +++--
  1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 23812ec..9f01a5c 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -985,8 +985,9 @@ static int skl_init_workarounds(struct intel_engine_cs 
*engine)
  
  	/* WaInPlaceDecompressionHang:skl */

if (IS_SKL_REVID(dev_priv, SKL_REVID_H0, REVID_FOREVER))
-   WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
-  GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
+   I915_WRITE(GEN9_GAMT_ECO_REG_RW_IA,
+  (I915_READ(GEN9_GAMT_ECO_REG_RW_IA) |
+   GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
  
  	/* WaDisableLSQCROPERFforOCL:skl */

ret = wa_ring_whitelist_reg(engine, GEN8_L3SQCREG4);
@@ -1059,8 +1060,9 @@ static int bxt_init_workarounds(struct intel_engine_cs 
*engine)
  
  	/* WaInPlaceDecompressionHang:bxt */

if (IS_BXT_REVID(dev_priv, BXT_REVID_C0, REVID_FOREVER))
-   WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
-  GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
+   I915_WRITE(GEN9_GAMT_ECO_REG_RW_IA,
+  (I915_READ(GEN9_GAMT_ECO_REG_RW_IA) |
+   GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
  
  	return 0;

  }
@@ -1089,8 +1091,9 @@ static int cnl_init_workarounds(struct intel_engine_cs 
*engine)
  GEN8_CSC2_SBE_VUE_CACHE_CONSERVATIVE);
  
  	/* WaInPlaceDecompressionHang:cnl */

-   WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
-  GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
+   I915_WRITE(GEN9_GAMT_ECO_REG_RW_IA,
+  (I915_READ(GEN9_GAMT_ECO_REG_RW_IA) |
+   GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
  
  	/* WaPushConstantDereferenceHoldDisable:cnl */

WA_SET_BIT(GEN7_ROW_CHICKEN2, PUSH_CONSTANT_DEREF_DISABLE);
@@ -1143,8 +1146,9 @@ static int kbl_init_workarounds(struct intel_engine_cs 
*engine)
GEN7_SBE_SS_CACHE_DISPATCH_PORT_SHARING_DISABLE);
  
  	/* WaInPlaceDecompressionHang:kbl */

-   WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
-  GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
+   I915_WRITE(GEN9_GAMT_ECO_REG_RW_IA,
+  (I915_READ(GEN9_GAMT_ECO_REG_RW_IA) |
+   GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
  
  	/* WaDisableLSQCROPERFforOCL:kbl */

ret = wa_ring_whitelist_reg(engine, GEN8_L3SQCREG4);
@@ -1196,8 +1200,9 @@ static int cfl_init_workarounds(struct intel_engine_cs 
*engine)
GEN7_SBE_SS_CACHE_DISPATCH_PORT_SHARING_DISABLE);
  
  	/* WaInPlaceDecompressionHang:cfl */

-   WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
-  GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
+   I915_WRITE(GEN9_GAMT_ECO_REG_RW_IA,
+  (I915_READ(GEN9_GAMT_ECO_REG_RW_IA) |
+   GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
  
  	return 0;

  }


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

Re: [Intel-gfx] [PATCH] drm/i915: Lift has-pinned-pages to caller of ____i915_gem_object_get_pages

[Chris Wilson]

Quoting Matthew Auld (2017-09-06 21:45:38)
> On 6 September 2017 at 14:52, Chris Wilson  wrote:
> > i915_gem_object_attach_phys() is trying to swap out its shmemfs pages
> > for a new set of physically contiguous pages, but unfortunately triggers
> > an assert inside get-pages.
> >
> > Signed-off-by: Chris Wilson 
> Reviewed-by: Matthew Auld 

Ta, one more step towards testing gdg complete.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Transform WaInPlaceDecompressionHang to a simple reg write

[Oscar Mateo]

Afaict, GEN9_GAMT_ECO_REG_RW_IA does not live in the context, so writing
it on every context creation is overkill (and wrong).

Cc: Mika Kuoppala 
Cc: Rodrigo Vivi 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 25 +++--
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 23812ec..9f01a5c 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -985,8 +985,9 @@ static int skl_init_workarounds(struct intel_engine_cs 
*engine)
 
/* WaInPlaceDecompressionHang:skl */
if (IS_SKL_REVID(dev_priv, SKL_REVID_H0, REVID_FOREVER))
-   WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
-  GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
+   I915_WRITE(GEN9_GAMT_ECO_REG_RW_IA,
+  (I915_READ(GEN9_GAMT_ECO_REG_RW_IA) |
+   GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
 
/* WaDisableLSQCROPERFforOCL:skl */
ret = wa_ring_whitelist_reg(engine, GEN8_L3SQCREG4);
@@ -1059,8 +1060,9 @@ static int bxt_init_workarounds(struct intel_engine_cs 
*engine)
 
/* WaInPlaceDecompressionHang:bxt */
if (IS_BXT_REVID(dev_priv, BXT_REVID_C0, REVID_FOREVER))
-   WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
-  GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
+   I915_WRITE(GEN9_GAMT_ECO_REG_RW_IA,
+  (I915_READ(GEN9_GAMT_ECO_REG_RW_IA) |
+   GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
 
return 0;
 }
@@ -1089,8 +1091,9 @@ static int cnl_init_workarounds(struct intel_engine_cs 
*engine)
  GEN8_CSC2_SBE_VUE_CACHE_CONSERVATIVE);
 
/* WaInPlaceDecompressionHang:cnl */
-   WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
-  GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
+   I915_WRITE(GEN9_GAMT_ECO_REG_RW_IA,
+  (I915_READ(GEN9_GAMT_ECO_REG_RW_IA) |
+   GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
 
/* WaPushConstantDereferenceHoldDisable:cnl */
WA_SET_BIT(GEN7_ROW_CHICKEN2, PUSH_CONSTANT_DEREF_DISABLE);
@@ -1143,8 +1146,9 @@ static int kbl_init_workarounds(struct intel_engine_cs 
*engine)
GEN7_SBE_SS_CACHE_DISPATCH_PORT_SHARING_DISABLE);
 
/* WaInPlaceDecompressionHang:kbl */
-   WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
-  GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
+   I915_WRITE(GEN9_GAMT_ECO_REG_RW_IA,
+  (I915_READ(GEN9_GAMT_ECO_REG_RW_IA) |
+   GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
 
/* WaDisableLSQCROPERFforOCL:kbl */
ret = wa_ring_whitelist_reg(engine, GEN8_L3SQCREG4);
@@ -1196,8 +1200,9 @@ static int cfl_init_workarounds(struct intel_engine_cs 
*engine)
GEN7_SBE_SS_CACHE_DISPATCH_PORT_SHARING_DISABLE);
 
/* WaInPlaceDecompressionHang:cfl */
-   WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
-  GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
+   I915_WRITE(GEN9_GAMT_ECO_REG_RW_IA,
+  (I915_READ(GEN9_GAMT_ECO_REG_RW_IA) |
+   GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
 
return 0;
 }
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] drm/i915: Kill GEN_RANGE in favor of INTEL_GEN.

[Chris Wilson]

Quoting Vivi, Rodrigo (2017-09-06 21:13:07)
> On Wed, 2017-09-06 at 20:57 +0100, Chris Wilson wrote:
> > Quoting Rodrigo Vivi (2017-09-06 20:51:37)
> > > Instead of limiting the range with this unusual GEN_RANGE
> > > let's assume following platforms would use same scheme
> > > unless stated otherwise.
> > 
> > No. This is uabi that should indeed be checked before exposed and not
> > assumed that unprivileged access to a register of yesterday is still
> > safe tommorrow.
> 
> hm... makes sense..
> 
> can we at least move to 
> 
> INTEL_GEN >= 4 && INTEL_GEN <= 10
> 
> or some flag on platform definition?
> 
> I really don't like GEN_RANGE... 

Something along the lines of

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6020a94daf81..b43a20bf2f25 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2843,24 +2843,30 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define INTEL_REVID(dev_priv)  ((dev_priv)->drm.pdev->revision)
 
 #define GEN_FOREVER (0)
+
+#define __GEN_RANGE(S, E) \
+   GENMASK((E) == GEN_FOREVER ? BITS_PER_LONG - 1 : (E) - 1, \
+   (S) == GEN_FOREVER ? 0 : (S) - 1)
 /*
- * Returns true if Gen is in inclusive range [Start, End].
+ * Computes the generation mask for an inclusive range [Start, End]
  *
  * Use GEN_FOREVER for unbound start and or end.
  */
-#define IS_GEN(dev_priv, s, e) ({ \
-   unsigned int __s = (s), __e = (e); \
-   BUILD_BUG_ON(!__builtin_constant_p(s)); \
-   BUILD_BUG_ON(!__builtin_constant_p(e)); \
-   if ((__s) != GEN_FOREVER) \
-   __s = (s) - 1; \
-   if ((__e) == GEN_FOREVER) \
-   __e = BITS_PER_LONG - 1; \
-   else \
-   __e = (e) - 1; \
-   !!((dev_priv)->info.gen_mask & GENMASK((__e), (__s))); \
+#define GEN_RANGE(S, E) ({ \
+   BUILD_BUG_ON(!__builtin_constant_p(S)); \
+   BUILD_BUG_ON(!__builtin_constant_p(E)); \
+   __GEN_RANGE(S, E); \
 })
 
+#define __IS_GEN(dev_priv, mask) (!!((dev_priv)->info.gen_mask & (mask)))
+
+/*
+ * Returns true if Gen is in inclusive range [Start, End].
+ *
+ * Use GEN_FOREVER for unbound start and or end.
+ */
+#define IS_GEN(dev_priv, s, e) __IS_GEN(dev_priv, GEN_RANGE(s, e))
+
 /*
  * Return true if revision is in range [since,until] inclusive.
  *
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 1d7b879cc68c..5f66313d628a 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1241,8 +1241,6 @@ void intel_uncore_fini(struct drm_i915_private *dev_priv)
intel_uncore_forcewake_reset(dev_priv, false);
 }
 
-#define GEN_RANGE(l, h) GENMASK((h) - 1, (l) - 1)
-
 static const struct register_whitelist {
i915_reg_t offset_ldw, offset_udw;
uint32_t size;
@@ -1251,7 +1249,7 @@ static const struct register_whitelist {
 } whitelist[] = {
{ .offset_ldw = RING_TIMESTAMP(RENDER_RING_BASE),
  .offset_udw = RING_TIMESTAMP_UDW(RENDER_RING_BASE),
- .size = 8, .gen_bitmask = GEN_RANGE(4, 9) },
+ .size = 8, .gen_bitmask = __GEN_RANGE(4, 9) },
 };
 
 int i915_reg_read_ioctl(struct drm_device *dev,
@@ -1266,7 +1264,7 @@ int i915_reg_read_ioctl(struct drm_device *dev,
 
for (i = 0; i < ARRAY_SIZE(whitelist); i++, entry++) {
if (i915_mmio_reg_offset(entry->offset_ldw) == (reg->offset & 
-entry->size) &&
-   (INTEL_INFO(dev_priv)->gen_mask & entry->gen_bitmask))
+   __IS_GEN(dev_priv, entry->gen_bitmask))
break;
}
 

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

[Intel-gfx] ✓ Fi.CI.BAT: success for Experimental Revert "drm/i915: Re-enable per-engine reset for Broxton"

[Patchwork]

== Series Details ==

Series: Experimental Revert "drm/i915: Re-enable per-engine reset for Broxton"
URL   : https://patchwork.freedesktop.org/series/29905/
State : success

== Summary ==

Series 29905v1 Experimental Revert "drm/i915: Re-enable per-engine reset for 
Broxton"
https://patchwork.freedesktop.org/api/1.0/series/29905/revisions/1/mbox/

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:454s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:447s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:360s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:557s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:255s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:524s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:523s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:516s
fi-cfl-s total:289  pass:250  dwarn:4   dfail:0   fail:0   skip:35  
time:479s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:433s
fi-glk-2atotal:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:609s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:447s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:428s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:431s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:512s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:473s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:514s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:600s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:605s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:529s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:468s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:535s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:514s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:444s
fi-skl-x1585ltotal:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:480s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:555s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:1   skip:39  
time:408s

235edb916d56561e8e68ed0b119fb195c52eb25a drm-tip: 2017y-09m-06d-19h-31m-41s UTC 
integration manifest
28307ba2040a Experimental Revert "drm/i915: Re-enable per-engine reset for 
Broxton"

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Lift has-pinned-pages to caller of ____i915_gem_object_get_pages

[Matthew Auld]

On 6 September 2017 at 14:52, Chris Wilson  wrote:
> i915_gem_object_attach_phys() is trying to swap out its shmemfs pages
> for a new set of physically contiguous pages, but unfortunately triggers
> an assert inside get-pages.
>
> Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Display WA #1133 WaFbcSkipSegments:cnl, glk

[Rodrigo Vivi]

On Tue, Sep 05, 2017 at 12:30:13PM -0700, Rodrigo Vivi wrote:
> Skip compressing 1 segment at the end of the frame,
> avoid a pixel count mismatch nuke event when last active
> pixel and dummy pixel has same color for Odd Plane
> Width / Height.
> 
> For both platforms Gemini Lake and Cannon Lake.
> 
> v2: Use function-like macro and also use mask to clean
> to make sure bit 11 is 0. (Suggested by Paulo).
> v3: Add Display WA notation and also apply for GLK.
> Both Forgotten on v2.
> Using "GLK_" prefix since GLK came before CNL.
> v4: Forgot to "|=" when moving directly macro to masked
> val. (Noticed by Paulo.)
> v5: Rebased on top of 0a46ddd57c9e ("drm/i915/cnp: Wa 1181:
> Fix Backlight issue")
> 
> Cc: Imre Deak 
> Cc: Paulo Zanoni 
> Signed-off-by: Rodrigo Vivi 
> Reviewed-by: Paulo Zanoni 

merge to dinq. thanks for the review.

> ---
>  drivers/gpu/drm/i915/i915_reg.h |  3 +++
>  drivers/gpu/drm/i915/intel_pm.c | 13 +
>  2 files changed, 16 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 5651081ff789..1878c4967529 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2940,6 +2940,9 @@ enum i915_power_well_id {
>  #define ILK_DPFC_CHICKEN _MMIO(0x43224)
>  #define   ILK_DPFC_DISABLE_DUMMY0 (1<<8)
>  #define   ILK_DPFC_NUKE_ON_ANY_MODIFICATION  (1<<23)
> +#define   GLK_SKIP_SEG_EN(1<<12)
> +#define   GLK_SKIP_SEG_COUNT_MASK(3<<10)
> +#define   GLK_SKIP_SEG_COUNT(x)  ((x)<<10)
>  #define ILK_FBC_RT_BASE  _MMIO(0x2128)
>  #define   ILK_FBC_RT_VALID   (1<<0)
>  #define   SNB_FBC_FRONT_BUFFER   (1<<1)
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index f5d77b131b58..0201816a4229 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -125,6 +125,7 @@ static void bxt_init_clock_gating(struct drm_i915_private 
> *dev_priv)
>  
>  static void glk_init_clock_gating(struct drm_i915_private *dev_priv)
>  {
> + u32 val;
>   gen9_init_clock_gating(dev_priv);
>  
>   /*
> @@ -144,6 +145,11 @@ static void glk_init_clock_gating(struct 
> drm_i915_private *dev_priv)
>   I915_WRITE(CHICKEN_MISC_2, val);
>   }
>  
> + /* Display WA #1133: WaFbcSkipSegments:glk */
> + val = I915_READ(ILK_DPFC_CHICKEN);
> + val &= ~GLK_SKIP_SEG_COUNT_MASK;
> + val |= GLK_SKIP_SEG_EN | GLK_SKIP_SEG_COUNT(1);
> + I915_WRITE(ILK_DPFC_CHICKEN, val);
>  }
>  
>  static void i915_pineview_get_mem_freq(struct drm_i915_private *dev_priv)
> @@ -8275,6 +8281,7 @@ static void cnp_init_clock_gating(struct 
> drm_i915_private *dev_priv)
>  
>  static void cnl_init_clock_gating(struct drm_i915_private *dev_priv)
>  {
> + u32 val;
>   cnp_init_clock_gating(dev_priv);
>  
>   /* This is not an Wa. Enable for better image quality */
> @@ -8294,6 +8301,12 @@ static void cnl_init_clock_gating(struct 
> drm_i915_private *dev_priv)
>   I915_WRITE(SLICE_UNIT_LEVEL_CLKGATE,
>  I915_READ(SLICE_UNIT_LEVEL_CLKGATE) |
>  SARBUNIT_CLKGATE_DIS);
> +
> + /* Display WA #1133: WaFbcSkipSegments:cnl */
> + val = I915_READ(ILK_DPFC_CHICKEN);
> + val &= ~GLK_SKIP_SEG_COUNT_MASK;
> + val |= GLK_SKIP_SEG_EN | GLK_SKIP_SEG_COUNT(1);
> + I915_WRITE(ILK_DPFC_CHICKEN, val);
>  }
>  
>  static void cfl_init_clock_gating(struct drm_i915_private *dev_priv)
> -- 
> 2.13.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Kill GEN_RANGE in favor of INTEL_GEN.

[Patchwork]

== Series Details ==

Series: drm/i915: Kill GEN_RANGE in favor of INTEL_GEN.
URL   : https://patchwork.freedesktop.org/series/29903/
State : success

== Summary ==

Series 29903v1 drm/i915: Kill GEN_RANGE in favor of INTEL_GEN.
https://patchwork.freedesktop.org/api/1.0/series/29903/revisions/1/mbox/

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
pass   -> FAIL   (fi-snb-2600) fdo#100215 +1
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> SKIP   (fi-cfl-s) fdo#102294

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:459s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:442s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:365s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:552s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:255s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:524s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:519s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:515s
fi-cfl-s total:289  pass:249  dwarn:4   dfail:0   fail:0   skip:36  
time:476s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:438s
fi-glk-2atotal:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:613s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:446s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:426s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:423s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:506s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:479s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:513s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:602s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:604s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:526s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:474s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:535s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:515s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:446s
fi-skl-x1585ltotal:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:487s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:559s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:1   skip:39  
time:405s

235edb916d56561e8e68ed0b119fb195c52eb25a drm-tip: 2017y-09m-06d-19h-31m-41s UTC 
integration manifest
f0ccd3123386 drm/i915: Kill GEN_RANGE in favor of INTEL_GEN.

== Logs ==

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

[Intel-gfx] [PATCH] Experimental Revert "drm/i915: Re-enable per-engine reset for Broxton"

[Chris Wilson]

This reverts commit 41e61020e821487489526e50b8e2e223342b7b93.
---
 drivers/gpu/drm/i915/i915_pci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index f060536cc405..4672fc40de3c 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -491,6 +491,7 @@ static const struct intel_device_info intel_broxton_info 
__initconst = {
GEN9_LP_FEATURES,
.platform = INTEL_BROXTON,
.ddb_size = 512,
+   .has_reset_engine = false,
 };
 
 static const struct intel_device_info intel_geminilake_info __initconst = {
-- 
2.14.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 drm/i915: Disable snooping (userptr, set-cache-level) on gen4

[Patchwork]

== Series Details ==

Series: drm/i915: Disable snooping (userptr, set-cache-level) on gen4
URL   : https://patchwork.freedesktop.org/series/29901/
State : success

== Summary ==

Series 29901v1 drm/i915: Disable snooping (userptr, set-cache-level) on gen4
https://patchwork.freedesktop.org/api/1.0/series/29901/revisions/1/mbox/

Test kms_flip:
Subgroup basic-flip-vs-modeset:
skip   -> PASS   (fi-skl-x1585l) fdo#101781
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> SKIP   (fi-cfl-s) fdo#102294

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:455s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:443s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:364s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:555s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:255s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:518s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:525s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:526s
fi-cfl-s total:289  pass:249  dwarn:4   dfail:0   fail:0   skip:36  
time:464s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:441s
fi-glk-2atotal:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:609s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:445s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:426s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:422s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:498s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:473s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:517s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:600s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:603s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:539s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:467s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:536s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:519s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:446s
fi-skl-x1585ltotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:505s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:558s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:1   skip:39  
time:421s

235edb916d56561e8e68ed0b119fb195c52eb25a drm-tip: 2017y-09m-06d-19h-31m-41s UTC 
integration manifest
88ec53812c38 drm/i915: Disable snooping (userptr, set-cache-level) on gen4

== Logs ==

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

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Add NV12 as supported format for primary plane

[Matt Roper]

On Wed, Sep 06, 2017 at 12:12:10PM -0700, Rodrigo Vivi wrote:
> On Wed, Sep 06, 2017 at 09:36:27AM -0700, Matt Roper wrote:
> > On Mon, Aug 28, 2017 at 04:22:20PM +0530, Vidya Srinivas wrote:
> > > From: Chandra Konduru 
> > > 
> > > This patch adds NV12 to list of supported formats for
> > > primary plane
> > > 
> > > v2: Rebased (Chandra Konduru)
> > > 
> > > v3: Rebased (me)
> > > 
> > > v4: Review comments by Ville addressed
> > >   Removed the skl_primary_formats_with_nv12 and
> > >   added NV12 case in existing skl_primary_formats
> > > 
> > > v5: Rebased (me)
> > > 
> > > v6: Missed the Tested-by/Reviewed-by in the previous series
> > >   Adding the same to commit message in this version.
> > > 
> > > v7: Review comments by Ville addressed
> > >   Restricting the NV12 for BXT and on PIPE A and B
> > >   Rebased (me)
> > > 
> > > v8: 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_display.c | 26 --
> > >  1 file changed, 24 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 4e73d88..6cf8806 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -106,6 +106,22 @@
> > >   DRM_FORMAT_MOD_INVALID
> > >  };
> > >  
> > > +static const uint32_t nv12_primary_formats[] = {
> > > + DRM_FORMAT_C8,
> > > + DRM_FORMAT_RGB565,
> > > + DRM_FORMAT_XRGB,
> > > + DRM_FORMAT_XBGR,
> > > + DRM_FORMAT_ARGB,
> > > + DRM_FORMAT_ABGR,
> > > + DRM_FORMAT_XRGB2101010,
> > > + DRM_FORMAT_XBGR2101010,
> > > + DRM_FORMAT_YUYV,
> > > + DRM_FORMAT_YVYU,
> > > + DRM_FORMAT_UYVY,
> > > + DRM_FORMAT_VYUY,
> > > + DRM_FORMAT_NV12,
> > > +};
> > > +
> > >  /* Cursor formats */
> > >  static const uint32_t intel_cursor_formats[] = {
> > >   DRM_FORMAT_ARGB,
> > > @@ -13280,8 +13296,14 @@ static bool 
> > > intel_cursor_plane_format_mod_supported(struct drm_plane *plane,
> > >   primary->update_plane = skylake_update_primary_plane;
> > >   primary->disable_plane = skylake_disable_primary_plane;
> > >   } else if (INTEL_GEN(dev_priv) >= 9) {
> > > - intel_primary_formats = skl_primary_formats;
> > > - num_formats = ARRAY_SIZE(skl_primary_formats);
> > > + if (IS_BROXTON(dev_priv) &&
> > 
> > I believe this needs to be
> > 
> >if (IS_BXT_REVID(dev_priv, BXT_REVID_D0, BXT_REVID_FOREVER) ...
> 
> We usually use this stepping information for Workarounds. So usually
> blocks around this are the non-expected default behaviour.
> So I'd handle that from A0 to C0 and else the default behaviour or at least
> ![A0,C0]...
> 
> > 
> > There were unavoidable flickering/underrun issues on the earlier
> > steppings due to memory fetch issues for the second color plane.  Those
> > issues were only fixed on the E0 SoC stepping (which incorporates the D0
> > Display/GT).
> 
> Also we usuallly use this steppings checking with a documented W/a.
> Is there one? Anything that would justify this?

Unfortunately the bspec WA database still hasn't been updated to
indicate that *any* SKU of can properly support NV12.  So the workaround
database still just gives a general "don't use NV12 at all" statement
(entry 0870 in the display WA database which is listed for "BXT:ALL").
I tried unravel what the internal communication channels are for this
kind of update a few months ago, but didn't make much headway.

> 
> But also, is there any team there still using anything older than D0? yet?

Yes, definitely.  Pre-E0 SoC's (and thus pre-D0 graphics) is what a lot
of our embedded customers have already gone to production with.


Matt


> 
> If we don't know anyone probably pure IS_BROXTON is the best option.
> 
> > 
> > Same change for your sprite plane changes in the next patch.
> > 
> > 
> > Matt
> > 
> > > + ((pipe == PIPE_A || pipe == PIPE_B))) {
> > > + intel_primary_formats = nv12_primary_formats;
> > > + num_formats = ARRAY_SIZE(nv12_primary_formats);
> > > + } else {
> > > + intel_primary_formats = skl_primary_formats;
> > > + num_formats = ARRAY_SIZE(skl_primary_formats);
> > > + }
> > >   if (pipe < PIPE_C)
> > >   modifiers = skl_format_modifiers_ccs;
> > >   else
> > > -- 
> > > 1.9.1
> > > 
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> > -- 
> > Matt Roper
> > Graphics Software Engineer
> > 

Re: [Intel-gfx] [PATCH] drm/i915: Kill GEN_RANGE in favor of INTEL_GEN.

[Vivi, Rodrigo]

On Wed, 2017-09-06 at 20:57 +0100, Chris Wilson wrote:
> Quoting Rodrigo Vivi (2017-09-06 20:51:37)
> > Instead of limiting the range with this unusual GEN_RANGE
> > let's assume following platforms would use same scheme
> > unless stated otherwise.
> 
> No. This is uabi that should indeed be checked before exposed and not
> assumed that unprivileged access to a register of yesterday is still
> safe tommorrow.

hm... makes sense..

can we at least move to 

INTEL_GEN >= 4 && INTEL_GEN <= 10

or some flag on platform definition?

I really don't like GEN_RANGE... 

> -Chris

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

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Allow the reg_read ioctl to read the RCS TIMESTAMP register

[Nanley Chery]

On Wed, Sep 06, 2017 at 12:32:15PM -0700, Rodrigo Vivi wrote:
> On Wed, Sep 6, 2017 at 12:16 PM, Rodrigo Vivi  wrote:
> > On Wed, Sep 6, 2017 at 11:26 AM, Nanley Chery  wrote:
> >> On Tue, Sep 05, 2017 at 07:04:44PM +, Vivi, Rodrigo wrote:
> >>> On Tue, 2017-09-05 at 11:45 -0700, Nanley Chery wrote:
> >>> > From: Ben Widawsky 
> >>>
> >>> Do we have a signed-off by him?
> >>> Maybe go with you as author and suggested-by Ben?
> >>>
> >>
> >> He's good with the second option. Should I send a v2?
> >
> > usually I'd say yes, but since I had patch here applied already I just
> > changed it myself ;)
> > But since CI had a hiccup on the initial attempt I'm sending to try
> > bot before merging it.
> >
> > Since we don't have any gen10 on CI  and this change is really only
> > changing behaviour
> > of gen10 that failure was probably bogus, but I want to just double
> > check here...
> >
> 
> trybot is happy! merged to dinq. thanks for the patch.
> 

Great. Thanks again!

> >>
> >>> >
> >>> > This enables the Mesa driver to advertise support for ARB_timer_query, 
> >>> > and
> >>> > thus an OpenGL version higher than 3.2.
> >>> >
> >>>
> >>> I tried to check if this patch should be a "Fixes:" for a previous one,
> >>> but I didn't find anyone that this patch would fit. Just a forgotten
> >>> case.
> >>>
> >>> > Cc: Rodrigo Vivi 
> >>> > Signed-off-by: Nanley Chery 
> >>> > ---
> >>> >  drivers/gpu/drm/i915/intel_uncore.c | 2 +-
> >>> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >>> >
> >>> > diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> >>> > b/drivers/gpu/drm/i915/intel_uncore.c
> >>> > index 1d7b879cc68c..0529af7cfbb8 100644
> >>> > --- a/drivers/gpu/drm/i915/intel_uncore.c
> >>> > +++ b/drivers/gpu/drm/i915/intel_uncore.c
> >>> > @@ -1251,7 +1251,7 @@ static const struct register_whitelist {
> >>> >  } whitelist[] = {
> >>> > { .offset_ldw = RING_TIMESTAMP(RENDER_RING_BASE),
> >>> >   .offset_udw = RING_TIMESTAMP_UDW(RENDER_RING_BASE),
> >>> > - .size = 8, .gen_bitmask = GEN_RANGE(4, 9) },
> >>> > + .size = 8, .gen_bitmask = GEN_RANGE(4, 10) },
> >>>
> >>> Reviewed-by: Rodrigo Vivi 
> >>>
> >>
> >> Thanks!
> >>
> >>> I'd like to kill this GEN_RANGE since it is easy to forget when enabling
> >>> a new platform. But this is topic for a different patch.
> >>>
> >>>
> >>
> >> Agreed.
> >>
> >>> >  };
> >>> >
> >>> >  int i915_reg_read_ioctl(struct drm_device *dev,
> >>>
> >> ___
> >> Intel-gfx mailing list
> >> Intel-gfx@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> >
> >
> > --
> > Rodrigo Vivi
> > Blog: http://blog.vivi.eng.br
> 
> 
> 
> -- 
> Rodrigo Vivi
> Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Supporting Intel GPU tracing in gpuvis

[Pierre-Loup A. Griffais]

On 09/06/2017 12:45 PM, Michael Sartain wrote:

On Wed, Sep 6, 2017, at 03:09 AM, Chris Wilson wrote:

We already have those tracepoint equivs and a script to generate a
similar visualisation: intel-gpu-tools/scripts/trace.pl, but only
looking at the scheduling issue from the gpu pov. But it's really only a
dev toy atm, plugging the gap between userspace and the gpu has been on
the perennial wishlist.


Ah, cool. I'll take a look at the events in trace.pl and try doing some
captures with it on my intel laptop.


Yep, thanks, that's helpful; not sure why I got dropped there but Mike 
kindly re-added me (am not on intel-gfx).


Since you called out many more events than we were expecting, should we 
assume the situation is not quite as simple as amdgpu where we have a 
tracepoint for work getting queued on HW pipes, and a tracepoint for 
work finishing? With the tracepoint in the initial ioctl for work 
submission and the appropriate seqnos, just these three let us 
reconstruct the whole timeline for all HW pipes, and attribute it to a 
userspace process. I understand that last one does not yet exist for 
Intel, as you pointed out. If you had any pointers on where to add it, 
maybe we could prototype something, but not sure how much work we'll be 
able to do directly on Intel HW.


Thanks,
 - Pierre-Loup



Thanks for the pointer Chris.
  -Mike



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

Re: [Intel-gfx] [PATCH] drm/i915: Kill GEN_RANGE in favor of INTEL_GEN.

[Chris Wilson]

Quoting Rodrigo Vivi (2017-09-06 20:51:37)
> Instead of limiting the range with this unusual GEN_RANGE
> let's assume following platforms would use same scheme
> unless stated otherwise.

No. This is uabi that should indeed be checked before exposed and not
assumed that unprivileged access to a register of yesterday is still
safe tommorrow.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Kill GEN_RANGE in favor of INTEL_GEN.

[Rodrigo Vivi]

Instead of limiting the range with this unusual GEN_RANGE
let's assume following platforms would use same scheme
unless stated otherwise.

In our regular flow of platform enabling we check for
INTEL_GEN occurences, while GEN_RANGE had only this
specific usage and consequently got forgotten,
blocking userspace on CNL to read RCS Timestamps.

That case was later identified and fixed with:
f1294585d8e1 ("drm/i915/cnl: Allow the reg_read ioctl
to read the RCS TIMESTAMP register")

So this patch extend this a bit futher so we don't
end in similar situations in near future.

This patch reverts the last remaining usage of the
original patch where it was added: af76ae447d44 ("drm/i915:
Use a macro to express the range of valid gens for reg_read")

Cc: Ben Widawsky 
Cc: Nanley Chery 
Cc: Paulo Zanoni 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_uncore.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 0529af7cfbb8..5ff854b489a0 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1241,17 +1241,14 @@ void intel_uncore_fini(struct drm_i915_private 
*dev_priv)
intel_uncore_forcewake_reset(dev_priv, false);
 }
 
-#define GEN_RANGE(l, h) GENMASK((h) - 1, (l) - 1)
-
 static const struct register_whitelist {
i915_reg_t offset_ldw, offset_udw;
uint32_t size;
-   /* supported gens, 0x10 for 4, 0x30 for 4 and 5, etc. */
-   uint32_t gen_bitmask;
 } whitelist[] = {
{ .offset_ldw = RING_TIMESTAMP(RENDER_RING_BASE),
  .offset_udw = RING_TIMESTAMP_UDW(RENDER_RING_BASE),
- .size = 8, .gen_bitmask = GEN_RANGE(4, 10) },
+ .size = 8
+   },
 };
 
 int i915_reg_read_ioctl(struct drm_device *dev,
@@ -1266,7 +1263,7 @@ int i915_reg_read_ioctl(struct drm_device *dev,
 
for (i = 0; i < ARRAY_SIZE(whitelist); i++, entry++) {
if (i915_mmio_reg_offset(entry->offset_ldw) == (reg->offset & 
-entry->size) &&
-   (INTEL_INFO(dev_priv)->gen_mask & entry->gen_bitmask))
+   (INTEL_GEN(dev_priv) >= 4))
break;
}
 
-- 
2.13.2

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

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Allow the reg_read ioctl to read the RCS TIMESTAMP register

[Rodrigo Vivi]

On Wed, Sep 6, 2017 at 12:16 PM, Rodrigo Vivi  wrote:
> On Wed, Sep 6, 2017 at 11:26 AM, Nanley Chery  wrote:
>> On Tue, Sep 05, 2017 at 07:04:44PM +, Vivi, Rodrigo wrote:
>>> On Tue, 2017-09-05 at 11:45 -0700, Nanley Chery wrote:
>>> > From: Ben Widawsky 
>>>
>>> Do we have a signed-off by him?
>>> Maybe go with you as author and suggested-by Ben?
>>>
>>
>> He's good with the second option. Should I send a v2?
>
> usually I'd say yes, but since I had patch here applied already I just
> changed it myself ;)
> But since CI had a hiccup on the initial attempt I'm sending to try
> bot before merging it.
>
> Since we don't have any gen10 on CI  and this change is really only
> changing behaviour
> of gen10 that failure was probably bogus, but I want to just double
> check here...
>

trybot is happy! merged to dinq. thanks for the patch.

>>
>>> >
>>> > This enables the Mesa driver to advertise support for ARB_timer_query, and
>>> > thus an OpenGL version higher than 3.2.
>>> >
>>>
>>> I tried to check if this patch should be a "Fixes:" for a previous one,
>>> but I didn't find anyone that this patch would fit. Just a forgotten
>>> case.
>>>
>>> > Cc: Rodrigo Vivi 
>>> > Signed-off-by: Nanley Chery 
>>> > ---
>>> >  drivers/gpu/drm/i915/intel_uncore.c | 2 +-
>>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>>> >
>>> > diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
>>> > b/drivers/gpu/drm/i915/intel_uncore.c
>>> > index 1d7b879cc68c..0529af7cfbb8 100644
>>> > --- a/drivers/gpu/drm/i915/intel_uncore.c
>>> > +++ b/drivers/gpu/drm/i915/intel_uncore.c
>>> > @@ -1251,7 +1251,7 @@ static const struct register_whitelist {
>>> >  } whitelist[] = {
>>> > { .offset_ldw = RING_TIMESTAMP(RENDER_RING_BASE),
>>> >   .offset_udw = RING_TIMESTAMP_UDW(RENDER_RING_BASE),
>>> > - .size = 8, .gen_bitmask = GEN_RANGE(4, 9) },
>>> > + .size = 8, .gen_bitmask = GEN_RANGE(4, 10) },
>>>
>>> Reviewed-by: Rodrigo Vivi 
>>>
>>
>> Thanks!
>>
>>> I'd like to kill this GEN_RANGE since it is easy to forget when enabling
>>> a new platform. But this is topic for a different patch.
>>>
>>>
>>
>> Agreed.
>>
>>> >  };
>>> >
>>> >  int i915_reg_read_ioctl(struct drm_device *dev,
>>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> --
> Rodrigo Vivi
> Blog: http://blog.vivi.eng.br



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [CI] drm/i915: Disable snooping (userptr, set-cache-level) on gen4

[Chris Wilson]

The original gen4 has an issue where writes (both render and blt) into
snoopable pages are lost. We've previously worked around this in
userspace (ddx, igt) by simply not requesting snoopable buffers, but upon
rediscovering this problem for a third time, make the kernel reject such
requests with -ENODEV.

This disables snooping on userspace buffers for i965g and i965gm (original
gen4) machines.

Signed-off-by: Chris Wilson 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_pci.c  | 2 ++
 drivers/gpu/drm/i915/intel_device_info.c | 2 --
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 881b5d6708aa..e95baf3c4314 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -168,6 +168,7 @@ static const struct intel_device_info intel_i965g_info 
__initconst = {
.platform = INTEL_I965G,
.has_overlay = 1,
.hws_needs_physical = 1,
+   .has_snoop = false,
 };
 
 static const struct intel_device_info intel_i965gm_info __initconst = {
@@ -177,6 +178,7 @@ static const struct intel_device_info intel_i965gm_info 
__initconst = {
.has_overlay = 1,
.supports_tv = 1,
.hws_needs_physical = 1,
+   .has_snoop = false,
 };
 
 static const struct intel_device_info intel_g45_info __initconst = {
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index b17f7045c8f8..43831b09b47a 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -412,8 +412,6 @@ void intel_device_info_runtime_init(struct drm_i915_private 
*dev_priv)
else if (INTEL_INFO(dev_priv)->gen >= 9)
gen9_sseu_info_init(dev_priv);
 
-   WARN_ON(info->has_snoop != !info->has_llc);
-
DRM_DEBUG_DRIVER("slice mask: %04x\n", info->sseu.slice_mask);
DRM_DEBUG_DRIVER("slice total: %u\n", hweight8(info->sseu.slice_mask));
DRM_DEBUG_DRIVER("subslice total: %u\n",
-- 
2.14.1

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

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Allow the reg_read ioctl to read the RCS TIMESTAMP register

[Rodrigo Vivi]

On Wed, Sep 6, 2017 at 11:26 AM, Nanley Chery  wrote:
> On Tue, Sep 05, 2017 at 07:04:44PM +, Vivi, Rodrigo wrote:
>> On Tue, 2017-09-05 at 11:45 -0700, Nanley Chery wrote:
>> > From: Ben Widawsky 
>>
>> Do we have a signed-off by him?
>> Maybe go with you as author and suggested-by Ben?
>>
>
> He's good with the second option. Should I send a v2?

usually I'd say yes, but since I had patch here applied already I just
changed it myself ;)
But since CI had a hiccup on the initial attempt I'm sending to try
bot before merging it.

Since we don't have any gen10 on CI  and this change is really only
changing behaviour
of gen10 that failure was probably bogus, but I want to just double
check here...

>
>> >
>> > This enables the Mesa driver to advertise support for ARB_timer_query, and
>> > thus an OpenGL version higher than 3.2.
>> >
>>
>> I tried to check if this patch should be a "Fixes:" for a previous one,
>> but I didn't find anyone that this patch would fit. Just a forgotten
>> case.
>>
>> > Cc: Rodrigo Vivi 
>> > Signed-off-by: Nanley Chery 
>> > ---
>> >  drivers/gpu/drm/i915/intel_uncore.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
>> > b/drivers/gpu/drm/i915/intel_uncore.c
>> > index 1d7b879cc68c..0529af7cfbb8 100644
>> > --- a/drivers/gpu/drm/i915/intel_uncore.c
>> > +++ b/drivers/gpu/drm/i915/intel_uncore.c
>> > @@ -1251,7 +1251,7 @@ static const struct register_whitelist {
>> >  } whitelist[] = {
>> > { .offset_ldw = RING_TIMESTAMP(RENDER_RING_BASE),
>> >   .offset_udw = RING_TIMESTAMP_UDW(RENDER_RING_BASE),
>> > - .size = 8, .gen_bitmask = GEN_RANGE(4, 9) },
>> > + .size = 8, .gen_bitmask = GEN_RANGE(4, 10) },
>>
>> Reviewed-by: Rodrigo Vivi 
>>
>
> Thanks!
>
>> I'd like to kill this GEN_RANGE since it is easy to forget when enabling
>> a new platform. But this is topic for a different patch.
>>
>>
>
> Agreed.
>
>> >  };
>> >
>> >  int i915_reg_read_ioctl(struct drm_device *dev,
>>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Add NV12 as supported format for primary plane

[Rodrigo Vivi]

On Wed, Sep 06, 2017 at 09:36:27AM -0700, Matt Roper wrote:
> On Mon, Aug 28, 2017 at 04:22:20PM +0530, Vidya Srinivas wrote:
> > From: Chandra Konduru 
> > 
> > This patch adds NV12 to list of supported formats for
> > primary plane
> > 
> > v2: Rebased (Chandra Konduru)
> > 
> > v3: Rebased (me)
> > 
> > v4: Review comments by Ville addressed
> > Removed the skl_primary_formats_with_nv12 and
> > added NV12 case in existing skl_primary_formats
> > 
> > v5: Rebased (me)
> > 
> > v6: Missed the Tested-by/Reviewed-by in the previous series
> > Adding the same to commit message in this version.
> > 
> > v7: Review comments by Ville addressed
> > Restricting the NV12 for BXT and on PIPE A and B
> > Rebased (me)
> > 
> > v8: 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_display.c | 26 --
> >  1 file changed, 24 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 4e73d88..6cf8806 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -106,6 +106,22 @@
> > DRM_FORMAT_MOD_INVALID
> >  };
> >  
> > +static const uint32_t nv12_primary_formats[] = {
> > +   DRM_FORMAT_C8,
> > +   DRM_FORMAT_RGB565,
> > +   DRM_FORMAT_XRGB,
> > +   DRM_FORMAT_XBGR,
> > +   DRM_FORMAT_ARGB,
> > +   DRM_FORMAT_ABGR,
> > +   DRM_FORMAT_XRGB2101010,
> > +   DRM_FORMAT_XBGR2101010,
> > +   DRM_FORMAT_YUYV,
> > +   DRM_FORMAT_YVYU,
> > +   DRM_FORMAT_UYVY,
> > +   DRM_FORMAT_VYUY,
> > +   DRM_FORMAT_NV12,
> > +};
> > +
> >  /* Cursor formats */
> >  static const uint32_t intel_cursor_formats[] = {
> > DRM_FORMAT_ARGB,
> > @@ -13280,8 +13296,14 @@ static bool 
> > intel_cursor_plane_format_mod_supported(struct drm_plane *plane,
> > primary->update_plane = skylake_update_primary_plane;
> > primary->disable_plane = skylake_disable_primary_plane;
> > } else if (INTEL_GEN(dev_priv) >= 9) {
> > -   intel_primary_formats = skl_primary_formats;
> > -   num_formats = ARRAY_SIZE(skl_primary_formats);
> > +   if (IS_BROXTON(dev_priv) &&
> 
> I believe this needs to be
> 
>if (IS_BXT_REVID(dev_priv, BXT_REVID_D0, BXT_REVID_FOREVER) ...

We usually use this stepping information for Workarounds. So usually
blocks around this are the non-expected default behaviour.
So I'd handle that from A0 to C0 and else the default behaviour or at least
![A0,C0]...

> 
> There were unavoidable flickering/underrun issues on the earlier
> steppings due to memory fetch issues for the second color plane.  Those
> issues were only fixed on the E0 SoC stepping (which incorporates the D0
> Display/GT).

Also we usuallly use this steppings checking with a documented W/a.
Is there one? Anything that would justify this?

But also, is there any team there still using anything older than D0? yet?

If we don't know anyone probably pure IS_BROXTON is the best option.

> 
> Same change for your sprite plane changes in the next patch.
> 
> 
> Matt
> 
> > +   ((pipe == PIPE_A || pipe == PIPE_B))) {
> > +   intel_primary_formats = nv12_primary_formats;
> > +   num_formats = ARRAY_SIZE(nv12_primary_formats);
> > +   } else {
> > +   intel_primary_formats = skl_primary_formats;
> > +   num_formats = ARRAY_SIZE(skl_primary_formats);
> > +   }
> > if (pipe < PIPE_C)
> > modifiers = skl_format_modifiers_ccs;
> > else
> > -- 
> > 1.9.1
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Allow the reg_read ioctl to read the RCS TIMESTAMP register

[Nanley Chery]

On Tue, Sep 05, 2017 at 07:04:44PM +, Vivi, Rodrigo wrote:
> On Tue, 2017-09-05 at 11:45 -0700, Nanley Chery wrote:
> > From: Ben Widawsky 
> 
> Do we have a signed-off by him?
> Maybe go with you as author and suggested-by Ben?
> 

He's good with the second option. Should I send a v2?

> > 
> > This enables the Mesa driver to advertise support for ARB_timer_query, and
> > thus an OpenGL version higher than 3.2.
> > 
> 
> I tried to check if this patch should be a "Fixes:" for a previous one,
> but I didn't find anyone that this patch would fit. Just a forgotten
> case.
> 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: Nanley Chery 
> > ---
> >  drivers/gpu/drm/i915/intel_uncore.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> > b/drivers/gpu/drm/i915/intel_uncore.c
> > index 1d7b879cc68c..0529af7cfbb8 100644
> > --- a/drivers/gpu/drm/i915/intel_uncore.c
> > +++ b/drivers/gpu/drm/i915/intel_uncore.c
> > @@ -1251,7 +1251,7 @@ static const struct register_whitelist {
> >  } whitelist[] = {
> > { .offset_ldw = RING_TIMESTAMP(RENDER_RING_BASE),
> >   .offset_udw = RING_TIMESTAMP_UDW(RENDER_RING_BASE),
> > - .size = 8, .gen_bitmask = GEN_RANGE(4, 9) },
> > + .size = 8, .gen_bitmask = GEN_RANGE(4, 10) },
> 
> Reviewed-by: Rodrigo Vivi 
> 

Thanks!

> I'd like to kill this GEN_RANGE since it is easy to forget when enabling
> a new platform. But this is topic for a different patch.
> 
> 

Agreed.

> >  };
> >  
> >  int i915_reg_read_ioctl(struct drm_device *dev,
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Disable MI_STORE_DATA_IMM for i915g/i915gm (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Disable MI_STORE_DATA_IMM for i915g/i915gm (rev2)
URL   : https://patchwork.freedesktop.org/series/29890/
State : success

== Summary ==

Test kms_flip:
Subgroup plain-flip-fb-recreate:
fail   -> PASS   (shard-hsw) fdo#102504
Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252

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

shard-hswtotal:2265 pass:1233 dwarn:0   dfail:0   fail:16  skip:1016 
time:9545s

== Logs ==

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

Re: [Intel-gfx] [PATCH 1/2] drm/dp/mst: Sideband message transaction to power up/down nodes

[Pandiyan, Dhinakaran]

On Wed, 2017-09-06 at 11:40 -0400, Lyude Paul wrote:
> On Tue, 2017-09-05 at 18:26 -0700, Dhinakaran Pandiyan wrote:
> > The POWER_DOWN_PHY and POWER_UP_PHY sideband message transactions
> > allow
> > the source to reqest any node in a mst path or a whole path to be
> > powered down or up. This allows drivers to target a specific sink in
> > the
> > MST topology, an improvement over just power managing the imediate
> > downstream device. Secondly, since the request-reply protocol waits
> > for an
> > ACK, we can be sure that a downstream sink has enough time to respond
> > to a
> > power up/down request.
> > 
> > Cc: Lyude 
> > Cc: Ville Syrjälä 
> > Cc: Harry Wentland 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 73
> > +++
> >  include/drm/drm_dp_mst_helper.h   |  2 +
> >  2 files changed, 75 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 41b492f99955..a9f12708a046 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -294,6 +294,12 @@ static void drm_dp_encode_sideband_req(struct
> > drm_dp_sideband_msg_req_body *req,
> > memcpy([idx], req->u.i2c_write.bytes, req-
> > >u.i2c_write.num_bytes);
> > idx += req->u.i2c_write.num_bytes;
> > break;
> > +
> > +   case DP_POWER_DOWN_PHY:
> > +   case DP_POWER_UP_PHY:
> > +   buf[idx] = (req->u.port_num.port_number & 0xf) << 4;
> > +   idx++;
> > +   break;
> > }
> > raw->cur_len = idx;
> >  }
> > @@ -538,6 +544,22 @@ static bool
> > drm_dp_sideband_parse_query_payload_ack(struct drm_dp_sideband_msg_r
> > return false;
> >  }
> >  
> > +
> > +static bool drm_dp_sideband_parse_power_updown_phy_ack(struct
> > drm_dp_sideband_msg_rx *raw,
> > +  struct
> > drm_dp_sideband_msg_reply_body *repmsg)
> > +{
> > +   int idx = 1;
> > +
> > +   repmsg->u.port_number.port_number = (raw->msg[idx] >> 4) &
> > 0xf;
> > +   idx++;
> > +   if (idx > raw->curlen) {
> > +   DRM_DEBUG_KMS("power up/down phy parse length fail
> > %d %d\n",
> > + idx, raw->curlen);
> > +   return false;
> > +   }
> > +   return true;
> > +}
> > +
> >  static bool drm_dp_sideband_parse_reply(struct
> > drm_dp_sideband_msg_rx *raw,
> > struct
> > drm_dp_sideband_msg_reply_body *msg)
> >  {
> > @@ -567,6 +589,9 @@ static bool drm_dp_sideband_parse_reply(struct
> > drm_dp_sideband_msg_rx *raw,
> > return
> > drm_dp_sideband_parse_enum_path_resources_ack(raw, msg);
> > case DP_ALLOCATE_PAYLOAD:
> > return
> > drm_dp_sideband_parse_allocate_payload_ack(raw, msg);
> > +   case DP_POWER_DOWN_PHY:
> > +   case DP_POWER_UP_PHY:
> > +   return
> > drm_dp_sideband_parse_power_updown_phy_ack(raw, msg);
> > default:
> > DRM_ERROR("Got unknown reply 0x%02x\n", msg-
> > >req_type);
> > return false;
> > @@ -693,6 +718,22 @@ static int build_allocate_payload(struct
> > drm_dp_sideband_msg_tx *msg, int port_n
> > return 0;
> >  }
> >  
> > +static int build_power_updown_phy(struct drm_dp_sideband_msg_tx
> > *msg,
> > + int port_num, bool power_up)
> > +{
> > +   struct drm_dp_sideband_msg_req_body req;
> > +
> > +   if (power_up)
> > +   req.req_type = DP_POWER_UP_PHY;
> > +   else
> > +   req.req_type = DP_POWER_DOWN_PHY;
> > +
> > +   req.u.port_num.port_number = port_num;
> > +   drm_dp_encode_sideband_req(, msg);
> > +   msg->path_msg = true;
> > +   return 0;
> > +}
> > +
> >  static int drm_dp_mst_assign_payload_id(struct
> > drm_dp_mst_topology_mgr *mgr,
> > struct drm_dp_vcpi *vcpi)
> >  {
> > @@ -1724,6 +1765,38 @@ static int drm_dp_payload_send_msg(struct
> > drm_dp_mst_topology_mgr *mgr,
> > return ret;
> >  }
> >  
> > +int drm_dp_send_power_updown_phy(struct drm_dp_mst_topology_mgr
> > *mgr,
> > +struct drm_dp_mst_port *port, bool
> > power_up)
> > +{
> > +   struct drm_dp_sideband_msg_tx *txmsg;
> > +   int len, ret;
> > +
> > +   txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> > +   if (!txmsg)
> > +   return -ENOMEM;
> > +
> > +   port = drm_dp_get_validated_port_ref(mgr, port);
> > +   if (!port)
> > +   return -EINVAL;
> if (!port), then you leak memory by not freeing txmsg

Right, I'll fix that up in the next version. Thanks!

> > +
> > +   txmsg->dst = port->parent;
> > +   len = build_power_updown_phy(txmsg, port->port_num,
> > power_up);
> > +   drm_dp_queue_down_tx(mgr, txmsg);
> > +
> > +   ret = drm_dp_mst_wait_tx_reply(port->parent, txmsg);
> > +   if (ret > 0) {
> > +   if 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Disable MI_STORE_DATA_IMM for i915g/i915gm

[Patchwork]

== Series Details ==

Series: drm/i915: Disable MI_STORE_DATA_IMM for i915g/i915gm
URL   : https://patchwork.freedesktop.org/series/29890/
State : success

== Summary ==

Test kms_flip:
Subgroup plain-flip-fb-recreate:
fail   -> PASS   (shard-hsw) fdo#102504
Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252

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

shard-hswtotal:2265 pass:1233 dwarn:0   dfail:0   fail:16  skip:1016 
time:9603s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for lib: Disable MI_STORE_DATA_IMM for gen3 (i915g and i915gm)

[Patchwork]

== Series Details ==

Series: lib: Disable MI_STORE_DATA_IMM for gen3 (i915g and i915gm)
URL   : https://patchwork.freedesktop.org/series/29889/
State : warning

== Summary ==

Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252 +1
Test kms_flip:
Subgroup plain-flip-fb-recreate:
fail   -> PASS   (shard-hsw) fdo#102504
Test kms_draw_crc:
Subgroup draw-method-xrgb2101010-mmap-wc-xtiled:
pass   -> SKIP   (shard-hsw)
Test kms_cursor_legacy:
Subgroup cursor-vs-flip-varying-size:
pass   -> SKIP   (shard-hsw)

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

shard-hswtotal:2265 pass:1232 dwarn:0   dfail:0   fail:15  skip:1018 
time:9663s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for tests: Add kms_atomic_interruptible test, v2.

[Patchwork]

== Series Details ==

Series: tests: Add kms_atomic_interruptible test, v2.
URL   : https://patchwork.freedesktop.org/series/29877/
State : success

== Summary ==

Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_flip:
Subgroup plain-flip-fb-recreate:
fail   -> PASS   (shard-hsw) fdo#102504
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912

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

shard-hswtotal:2272 pass:1241 dwarn:0   dfail:0   fail:15  skip:1016 
time:9747s

== Logs ==

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

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Add NV12 as supported format for primary plane

[Matt Roper]

On Mon, Aug 28, 2017 at 04:22:20PM +0530, Vidya Srinivas wrote:
> From: Chandra Konduru 
> 
> This patch adds NV12 to list of supported formats for
> primary plane
> 
> v2: Rebased (Chandra Konduru)
> 
> v3: Rebased (me)
> 
> v4: Review comments by Ville addressed
>   Removed the skl_primary_formats_with_nv12 and
>   added NV12 case in existing skl_primary_formats
> 
> v5: Rebased (me)
> 
> v6: Missed the Tested-by/Reviewed-by in the previous series
>   Adding the same to commit message in this version.
> 
> v7: Review comments by Ville addressed
>   Restricting the NV12 for BXT and on PIPE A and B
>   Rebased (me)
> 
> v8: 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_display.c | 26 --
>  1 file changed, 24 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 4e73d88..6cf8806 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -106,6 +106,22 @@
>   DRM_FORMAT_MOD_INVALID
>  };
>  
> +static const uint32_t nv12_primary_formats[] = {
> + DRM_FORMAT_C8,
> + DRM_FORMAT_RGB565,
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_XBGR,
> + DRM_FORMAT_ARGB,
> + DRM_FORMAT_ABGR,
> + DRM_FORMAT_XRGB2101010,
> + DRM_FORMAT_XBGR2101010,
> + DRM_FORMAT_YUYV,
> + DRM_FORMAT_YVYU,
> + DRM_FORMAT_UYVY,
> + DRM_FORMAT_VYUY,
> + DRM_FORMAT_NV12,
> +};
> +
>  /* Cursor formats */
>  static const uint32_t intel_cursor_formats[] = {
>   DRM_FORMAT_ARGB,
> @@ -13280,8 +13296,14 @@ static bool 
> intel_cursor_plane_format_mod_supported(struct drm_plane *plane,
>   primary->update_plane = skylake_update_primary_plane;
>   primary->disable_plane = skylake_disable_primary_plane;
>   } else if (INTEL_GEN(dev_priv) >= 9) {
> - intel_primary_formats = skl_primary_formats;
> - num_formats = ARRAY_SIZE(skl_primary_formats);
> + if (IS_BROXTON(dev_priv) &&

I believe this needs to be

   if (IS_BXT_REVID(dev_priv, BXT_REVID_D0, BXT_REVID_FOREVER) ...

There were unavoidable flickering/underrun issues on the earlier
steppings due to memory fetch issues for the second color plane.  Those
issues were only fixed on the E0 SoC stepping (which incorporates the D0
Display/GT).

Same change for your sprite plane changes in the next patch.


Matt

> + ((pipe == PIPE_A || pipe == PIPE_B))) {
> + intel_primary_formats = nv12_primary_formats;
> + num_formats = ARRAY_SIZE(nv12_primary_formats);
> + } else {
> + intel_primary_formats = skl_primary_formats;
> + num_formats = ARRAY_SIZE(skl_primary_formats);
> + }
>   if (pipe < PIPE_C)
>   modifiers = skl_format_modifiers_ccs;
>   else
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Re-enable per-engine reset for Broxton

[Chris Wilson]

Quoting Michel Thierry (2017-09-06 16:25:06)
> On 05/09/17 06:57, Chris Wilson wrote:
> > Quoting Chris Wilson (2017-08-21 15:55:34)
> >> Quoting Michel Thierry (2017-08-18 18:23:42)
> >>> The corruption in CSB mmio reads we were seeing has been tracked down to
> >>> incorrectly touching forcewake of all domains, following an engine reset.
> >>> It is still a mistery why we only catched this in Broxton, since it
> >>> could happen in any platform.
> >>>
> >>> With that fix already merged, commit 4055dc75d6b5 ("drm/i915: Stop
> >>> touching forcewake following a gen6+ engine reset"), lets try to enable
> >>> per-engine resets in Broxton one more time.
> >>>
> >>> This reverts commit f188258bde0f ("drm/i915: Disable per-engine reset for
> >>> Broxton").
> >>>
> >>> Cc: Chris Wilson 
> >>> Signed-off-by: Michel Thierry 
> >>
> >> My bxt has survived about 72 hours of hang testing, which is far more
> >> than it was able to previously.
> >>
> >> Acked-by: Chris Wilson 
> >> Tested-by: Chris Wilson 
> > 
> > Uh oh, seemingly just hit it again...
> 
> Was it because the CSBs were 0's?
> 
> A couple of times I saw a spurious CSB event (0x12 - preempted & 
> complete), after an already 'complete' event. That was also hitting the 
> assert because the ctx-id would be 'wrong'. I think we could ignore the 
> 0x12 event and it will continue.

Hmm, that 0x12 event has never triggered the invalid ctx id yet for me
(but that's probably just a matter of workload), it always hits the
too-many-switches.  Sadly we can't just continue on after that as the hw
is completely out-of-sync with our submissions, and the only way to
recover appears to be a gpu reset.

Anyway, haven't yet dug back into the bang, just reaffirmed that
disabling per-engine resets gives me a
ickle@broxton:~$ uptime
 16:55:31 up 1 day,  2:01,  2 users,  load average: 3.66, 3.38, 3.3
so far of drv_selftest --r live_hanghceck
-Chris
___
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: Disable MI_STORE_DATA_IMM for i915g/i915gm (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Disable MI_STORE_DATA_IMM for i915g/i915gm (rev2)
URL   : https://patchwork.freedesktop.org/series/29890/
State : success

== Summary ==

Series 29890v2 drm/i915: Disable MI_STORE_DATA_IMM for i915g/i915gm
https://patchwork.freedesktop.org/api/1.0/series/29890/revisions/2/mbox/

Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> DMESG-WARN (fi-bdw-5557u) fdo#102473
Test pm_rpm:
Subgroup basic-pci-d3-state:
skip   -> PASS   (fi-cfl-s) fdo#102294

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

fi-bdw-5557u total:289  pass:267  dwarn:1   dfail:0   fail:0   skip:21  
time:455s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:440s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:364s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:557s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:256s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:523s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:527s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:519s
fi-cfl-s total:289  pass:250  dwarn:4   dfail:0   fail:0   skip:35  
time:472s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:440s
fi-glk-2atotal:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:613s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:446s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:426s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:425s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:501s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:473s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:517s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:609s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:601s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:528s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:539s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:516s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:446s
fi-skl-x1585ltotal:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:483s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:552s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:1   skip:39  
time:413s

c18a85fe008e41f342e47ff4296e55654ba4fa4b drm-tip: 2017y-09m-06d-13h-17m-59s UTC 
integration manifest
970f5b73f9ab drm/i915: Disable MI_STORE_DATA_IMM for i915g/i915gm

== Logs ==

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

Re: [Intel-gfx] [PATCH 1/2] drm/dp/mst: Sideband message transaction to power up/down nodes

[Lyude Paul]

On Tue, 2017-09-05 at 18:26 -0700, Dhinakaran Pandiyan wrote:
> The POWER_DOWN_PHY and POWER_UP_PHY sideband message transactions
> allow
> the source to reqest any node in a mst path or a whole path to be
> powered down or up. This allows drivers to target a specific sink in
> the
> MST topology, an improvement over just power managing the imediate
> downstream device. Secondly, since the request-reply protocol waits
> for an
> ACK, we can be sure that a downstream sink has enough time to respond
> to a
> power up/down request.
> 
> Cc: Lyude 
> Cc: Ville Syrjälä 
> Cc: Harry Wentland 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 73
> +++
>  include/drm/drm_dp_mst_helper.h   |  2 +
>  2 files changed, 75 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 41b492f99955..a9f12708a046 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -294,6 +294,12 @@ static void drm_dp_encode_sideband_req(struct
> drm_dp_sideband_msg_req_body *req,
>   memcpy([idx], req->u.i2c_write.bytes, req-
> >u.i2c_write.num_bytes);
>   idx += req->u.i2c_write.num_bytes;
>   break;
> +
> + case DP_POWER_DOWN_PHY:
> + case DP_POWER_UP_PHY:
> + buf[idx] = (req->u.port_num.port_number & 0xf) << 4;
> + idx++;
> + break;
>   }
>   raw->cur_len = idx;
>  }
> @@ -538,6 +544,22 @@ static bool
> drm_dp_sideband_parse_query_payload_ack(struct drm_dp_sideband_msg_r
>   return false;
>  }
>  
> +
> +static bool drm_dp_sideband_parse_power_updown_phy_ack(struct
> drm_dp_sideband_msg_rx *raw,
> +struct
> drm_dp_sideband_msg_reply_body *repmsg)
> +{
> + int idx = 1;
> +
> + repmsg->u.port_number.port_number = (raw->msg[idx] >> 4) &
> 0xf;
> + idx++;
> + if (idx > raw->curlen) {
> + DRM_DEBUG_KMS("power up/down phy parse length fail
> %d %d\n",
> +   idx, raw->curlen);
> + return false;
> + }
> + return true;
> +}
> +
>  static bool drm_dp_sideband_parse_reply(struct
> drm_dp_sideband_msg_rx *raw,
>   struct
> drm_dp_sideband_msg_reply_body *msg)
>  {
> @@ -567,6 +589,9 @@ static bool drm_dp_sideband_parse_reply(struct
> drm_dp_sideband_msg_rx *raw,
>   return
> drm_dp_sideband_parse_enum_path_resources_ack(raw, msg);
>   case DP_ALLOCATE_PAYLOAD:
>   return
> drm_dp_sideband_parse_allocate_payload_ack(raw, msg);
> + case DP_POWER_DOWN_PHY:
> + case DP_POWER_UP_PHY:
> + return
> drm_dp_sideband_parse_power_updown_phy_ack(raw, msg);
>   default:
>   DRM_ERROR("Got unknown reply 0x%02x\n", msg-
> >req_type);
>   return false;
> @@ -693,6 +718,22 @@ static int build_allocate_payload(struct
> drm_dp_sideband_msg_tx *msg, int port_n
>   return 0;
>  }
>  
> +static int build_power_updown_phy(struct drm_dp_sideband_msg_tx
> *msg,
> +   int port_num, bool power_up)
> +{
> + struct drm_dp_sideband_msg_req_body req;
> +
> + if (power_up)
> + req.req_type = DP_POWER_UP_PHY;
> + else
> + req.req_type = DP_POWER_DOWN_PHY;
> +
> + req.u.port_num.port_number = port_num;
> + drm_dp_encode_sideband_req(, msg);
> + msg->path_msg = true;
> + return 0;
> +}
> +
>  static int drm_dp_mst_assign_payload_id(struct
> drm_dp_mst_topology_mgr *mgr,
>   struct drm_dp_vcpi *vcpi)
>  {
> @@ -1724,6 +1765,38 @@ static int drm_dp_payload_send_msg(struct
> drm_dp_mst_topology_mgr *mgr,
>   return ret;
>  }
>  
> +int drm_dp_send_power_updown_phy(struct drm_dp_mst_topology_mgr
> *mgr,
> +  struct drm_dp_mst_port *port, bool
> power_up)
> +{
> + struct drm_dp_sideband_msg_tx *txmsg;
> + int len, ret;
> +
> + txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> + if (!txmsg)
> + return -ENOMEM;
> +
> + port = drm_dp_get_validated_port_ref(mgr, port);
> + if (!port)
> + return -EINVAL;
if (!port), then you leak memory by not freeing txmsg
> +
> + txmsg->dst = port->parent;
> + len = build_power_updown_phy(txmsg, port->port_num,
> power_up);
> + drm_dp_queue_down_tx(mgr, txmsg);
> +
> + ret = drm_dp_mst_wait_tx_reply(port->parent, txmsg);
> + if (ret > 0) {
> + if (txmsg->reply.reply_type == 1)
> + ret = -EINVAL;
> + else
> + ret = 0;
> + }
> + kfree(txmsg);
> + drm_dp_put_port(port);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_send_power_updown_phy);
> +
>  static int 

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/5] lib/scatterlist: Fix offset type in sg_alloc_table_from_pages (rev6)

[Patchwork]

== Series Details ==

Series: series starting with [1/5] lib/scatterlist: Fix offset type in 
sg_alloc_table_from_pages (rev6)
URL   : https://patchwork.freedesktop.org/series/28151/
State : failure

== Summary ==

Series 28151v6 series starting with [1/5] lib/scatterlist: Fix offset type in 
sg_alloc_table_from_pages
https://patchwork.freedesktop.org/api/1.0/series/28151/revisions/6/mbox/

Test drv_getparams_basic:
Subgroup basic-eu-total:
pass   -> INCOMPLETE (fi-hsw-4770r)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
fail   -> PASS   (fi-snb-2600) fdo#100215
Test pm_rpm:
Subgroup basic-pci-d3-state:
skip   -> PASS   (fi-cfl-s) fdo#102294

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:457s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:442s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:363s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:565s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:254s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:522s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:527s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:517s
fi-cfl-s total:289  pass:250  dwarn:4   dfail:0   fail:0   skip:35  
time:458s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:434s
fi-glk-2atotal:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:613s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:444s
fi-hsw-4770r total:289  pass:3dwarn:0   dfail:0   fail:0   skip:9  
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:422s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:513s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:470s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:516s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:604s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:603s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:528s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:468s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:537s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:513s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:445s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:554s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:401s

c18a85fe008e41f342e47ff4296e55654ba4fa4b drm-tip: 2017y-09m-06d-13h-17m-59s UTC 
integration manifest
d1c2da6c3b1a tools/testing/scatterlist: Test new __sg_alloc_table_from_pages
fd1a734e2da8 drm/i915: Use __sg_alloc_table_from_pages for userptr allocations
f0e8eb74ae34 lib/scatterlist: Introduce and export __sg_alloc_table_from_pages
7340decc6fb1 lib/scatterlist: Avoid potential scatterlist entry overflow
b41edc4d7966 lib/scatterlist: Fix offset type in sg_alloc_table_from_pages

== Logs ==

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

[Intel-gfx] [PATCH v2] drm/i915: Disable MI_STORE_DATA_IMM for i915g/i915gm

[Chris Wilson]

The early gen3 machines (i915g/Grantsdale and i915gm/Alviso) share a lot
of characteristics in their MI/GTT blocks with gen2, and in particular
can only use physical addresses in MI_STORE_DATA_IMM. This makes it
incompatible with our usage, so include those two machines in the
blacklist to prevent usage.

v2: Make it easy for gcc and rewrite it as a switch to save some space.

Signed-off-by: Chris Wilson 
Reviewed-by: Ville Syrjälä  #v1
---
 drivers/gpu/drm/i915/i915_drv.h|  7 ---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  7 ---
 drivers/gpu/drm/i915/intel_engine_cs.c | 15 +++
 drivers/gpu/drm/i915/intel_ringbuffer.h| 12 +---
 4 files changed, 20 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 789f7502cd1f..6020a94daf81 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4360,11 +4360,4 @@ int remap_io_mapping(struct vm_area_struct *vma,
 unsigned long addr, unsigned long pfn, unsigned long size,
 struct io_mapping *iomap);
 
-static inline bool
-intel_engine_can_store_dword(struct intel_engine_cs *engine)
-{
-   return __intel_engine_can_store_dword(INTEL_GEN(engine->i915),
- engine->class);
-}
-
 #endif
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 53718a245ded..7687483ff218 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1168,6 +1168,9 @@ static u32 *reloc_gpu(struct i915_execbuffer *eb,
if (eb_use_cmdparser(eb))
return ERR_PTR(-EWOULDBLOCK);
 
+   if (!intel_engine_can_store_dword(eb->engine))
+   return ERR_PTR(-ENODEV);
+
err = __reloc_gpu_alloc(eb, vma, len);
if (unlikely(err))
return ERR_PTR(err);
@@ -1192,9 +1195,7 @@ relocate_entry(struct i915_vma *vma,
 
if (!eb->reloc_cache.vaddr &&
(DBG_FORCE_RELOC == FORCE_GPU_RELOC ||
-!reservation_object_test_signaled_rcu(vma->resv, true)) &&
-   __intel_engine_can_store_dword(eb->reloc_cache.gen,
-  eb->engine->class)) {
+!reservation_object_test_signaled_rcu(vma->resv, true))) {
const unsigned int gen = eb->reloc_cache.gen;
unsigned int len;
u32 *batch;
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index ae668340620e..23812ec23969 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1378,6 +1378,21 @@ void intel_engines_mark_idle(struct drm_i915_private 
*i915)
}
 }
 
+bool intel_engine_can_store_dword(struct intel_engine_cs *engine)
+{
+   switch (INTEL_GEN(engine->i915)) {
+   case 2:
+   return false; /* uses physical not virtual addresses */
+   case 3:
+   /* maybe only uses physical not virtual addresses */
+   return !(IS_I915G(engine->i915) || IS_I915GM(engine->i915));
+   case 6:
+   return engine->class != VIDEO_DECODE_CLASS; /* b0rked */
+   default:
+   return true;
+   }
+}
+
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "selftests/mock_engine.c"
 #endif
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 02d8974bf9ab..79c0021f3700 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -735,16 +735,6 @@ bool intel_engines_are_idle(struct drm_i915_private 
*dev_priv);
 void intel_engines_mark_idle(struct drm_i915_private *i915);
 void intel_engines_reset_default_submission(struct drm_i915_private *i915);
 
-static inline bool
-__intel_engine_can_store_dword(unsigned int gen, unsigned int class)
-{
-   if (gen <= 2)
-   return false; /* uses physical not virtual addresses */
-
-   if (gen == 6 && class == VIDEO_DECODE_CLASS)
-   return false; /* b0rked */
-
-   return true;
-}
+bool intel_engine_can_store_dword(struct intel_engine_cs *engine);
 
 #endif /* _INTEL_RINGBUFFER_H_ */
-- 
2.14.1

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

Re: [Intel-gfx] [PATCH] drm/i915: Re-enable per-engine reset for Broxton

[Michel Thierry]

On 05/09/17 06:57, Chris Wilson wrote:

Quoting Chris Wilson (2017-08-21 15:55:34)

Quoting Michel Thierry (2017-08-18 18:23:42)

The corruption in CSB mmio reads we were seeing has been tracked down to
incorrectly touching forcewake of all domains, following an engine reset.
It is still a mistery why we only catched this in Broxton, since it
could happen in any platform.

With that fix already merged, commit 4055dc75d6b5 ("drm/i915: Stop
touching forcewake following a gen6+ engine reset"), lets try to enable
per-engine resets in Broxton one more time.

This reverts commit f188258bde0f ("drm/i915: Disable per-engine reset for
Broxton").

Cc: Chris Wilson 
Signed-off-by: Michel Thierry 


My bxt has survived about 72 hours of hang testing, which is far more
than it was able to previously.

Acked-by: Chris Wilson 
Tested-by: Chris Wilson 


Uh oh, seemingly just hit it again...


Was it because the CSBs were 0's?

A couple of times I saw a spurious CSB event (0x12 - preempted & 
complete), after an already 'complete' event. That was also hitting the 
assert because the ctx-id would be 'wrong'. I think we could ignore the 
0x12 event and it will continue.


___
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: Unify skylake plane update

[Ville Syrjälä]

On Tue, Aug 29, 2017 at 12:48:03PM +0300, Juha-Pekka Heikkila wrote:
> Don't handle skylake primary plane separately as it is similar
> plane as the others.
> 
> Signed-off-by: Juha-Pekka Heikkila 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 81 
> +---
>  drivers/gpu/drm/i915/intel_drv.h |  3 ++
>  drivers/gpu/drm/i915/intel_sprite.c  |  2 +-
>  3 files changed, 6 insertions(+), 80 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index f922e2f..9082a2c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3534,83 +3534,6 @@ u32 skl_plane_ctl(const struct intel_crtc_state 
> *crtc_state,
>   return plane_ctl;
>  }
>  
> -static void skylake_update_primary_plane(struct intel_plane *plane,
> -  const struct intel_crtc_state 
> *crtc_state,
> -  const struct intel_plane_state 
> *plane_state)
> -{
> - struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> - struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> - const struct drm_framebuffer *fb = plane_state->base.fb;
> - enum plane_id plane_id = plane->id;
> - enum pipe pipe = plane->pipe;
> - u32 plane_ctl = plane_state->ctl;
> - unsigned int rotation = plane_state->base.rotation;
> - u32 stride = skl_plane_stride(fb, 0, rotation);
> - u32 aux_stride = skl_plane_stride(fb, 1, rotation);
> - u32 surf_addr = plane_state->main.offset;
> - int scaler_id = plane_state->scaler_id;
> - int src_x = plane_state->main.x;
> - int src_y = plane_state->main.y;
> - int src_w = drm_rect_width(_state->base.src) >> 16;
> - int src_h = drm_rect_height(_state->base.src) >> 16;
> - int dst_x = plane_state->base.dst.x1;
> - int dst_y = plane_state->base.dst.y1;
> - int dst_w = drm_rect_width(_state->base.dst);
> - int dst_h = drm_rect_height(_state->base.dst);
> - unsigned long irqflags;
> -
> - /* Sizes are 0 based */
> - src_w--;
> - src_h--;
> - dst_w--;
> - dst_h--;
> -
> - crtc->dspaddr_offset = surf_addr;
> -
> - crtc->adjusted_x = src_x;
> - crtc->adjusted_y = src_y;

I think that's going to break FBC.

Probably the best thing to do is kill adjusted_x/y and instead replace
them with something better in the fbc code. That something being
essentially plane_state->main.x/y. Though I think they need to get
plumbed through the fbc state_cache, and I think we should kill off the
FBC crtc->base.y usage while we're at it. So maybe we can just compute
the final fence_y_offset in intel_fbc_update_state_cache() and stick
that into the state_cache. Cc:ing Paulo for his thoughts...

> -
> - spin_lock_irqsave(_priv->uncore.lock, irqflags);
> -
> - if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
> - I915_WRITE_FW(PLANE_COLOR_CTL(pipe, plane_id),
> -   PLANE_COLOR_PIPE_GAMMA_ENABLE |
> -   PLANE_COLOR_PIPE_CSC_ENABLE |
> -   PLANE_COLOR_PLANE_GAMMA_DISABLE);
> - }
> -
> - I915_WRITE_FW(PLANE_CTL(pipe, plane_id), plane_ctl);
> - I915_WRITE_FW(PLANE_OFFSET(pipe, plane_id), (src_y << 16) | src_x);
> - I915_WRITE_FW(PLANE_STRIDE(pipe, plane_id), stride);
> - I915_WRITE_FW(PLANE_SIZE(pipe, plane_id), (src_h << 16) | src_w);
> - I915_WRITE_FW(PLANE_AUX_DIST(pipe, plane_id),
> -   (plane_state->aux.offset - surf_addr) | aux_stride);
> - I915_WRITE_FW(PLANE_AUX_OFFSET(pipe, plane_id),
> -   (plane_state->aux.y << 16) | plane_state->aux.x);
> -
> - if (scaler_id >= 0) {
> - uint32_t ps_ctrl = 0;
> -
> - WARN_ON(!dst_w || !dst_h);
> - ps_ctrl = PS_SCALER_EN | PS_PLANE_SEL(plane_id) |
> - crtc_state->scaler_state.scalers[scaler_id].mode;
> - I915_WRITE_FW(SKL_PS_CTRL(pipe, scaler_id), ps_ctrl);
> - I915_WRITE_FW(SKL_PS_PWR_GATE(pipe, scaler_id), 0);
> - I915_WRITE_FW(SKL_PS_WIN_POS(pipe, scaler_id), (dst_x << 16) | 
> dst_y);
> - I915_WRITE_FW(SKL_PS_WIN_SZ(pipe, scaler_id), (dst_w << 16) | 
> dst_h);
> - I915_WRITE_FW(PLANE_POS(pipe, plane_id), 0);
> - } else {
> - I915_WRITE_FW(PLANE_POS(pipe, plane_id), (dst_y << 16) | dst_x);
> - }
> -
> - I915_WRITE_FW(PLANE_SURF(pipe, plane_id),
> -   intel_plane_ggtt_offset(plane_state) + surf_addr);
> -
> - POSTING_READ_FW(PLANE_SURF(pipe, plane_id));
> -
> - spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
> -}
> -
>  static void skylake_disable_primary_plane(struct intel_plane *primary,
> struct intel_crtc *crtc)
>  {
> @@ -13265,7 +13188,7 @@ intel_primary_plane_create(struct drm_i915_private 
> 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Disable MI_STORE_DATA_IMM for i915g/i915gm

[Patchwork]

== Series Details ==

Series: drm/i915: Disable MI_STORE_DATA_IMM for i915g/i915gm
URL   : https://patchwork.freedesktop.org/series/29890/
State : success

== Summary ==

Series 29890v1 drm/i915: Disable MI_STORE_DATA_IMM for i915g/i915gm
https://patchwork.freedesktop.org/api/1.0/series/29890/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-n2820) fdo#101705

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:459s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:451s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:365s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:555s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:254s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:525s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:526s
fi-byt-n2820 total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:525s
fi-cfl-s total:289  pass:249  dwarn:4   dfail:0   fail:0   skip:36  
time:464s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:449s
fi-glk-2atotal:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:612s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:453s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:427s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:424s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:506s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:476s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:514s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:603s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:600s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:533s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:470s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:541s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:517s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:442s
fi-skl-x1585ltotal:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:497s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:561s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:1   skip:39  
time:407s

c18a85fe008e41f342e47ff4296e55654ba4fa4b drm-tip: 2017y-09m-06d-13h-17m-59s UTC 
integration manifest
c5264cd08046 drm/i915: Disable MI_STORE_DATA_IMM for i915g/i915gm

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Disable MI_STORE_DATA_IMM for i915g/i915gm

[Chris Wilson]

Quoting Ville Syrjälä (2017-09-06 16:00:49)
> On Wed, Sep 06, 2017 at 03:40:08PM +0100, Chris Wilson wrote:
> > The early gen3 machines (i915g/Grantsdale and i915gm/Alviso) share a lot
> > of characteristics in their MI/GTT blocks with gen2, and in particular
> > can only use physical addresses in MI_STORE_DATA_IMM. This makes it
> > incompatible with our usage, so include those two machines in the
> > blacklist to prevent usage.
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h|  7 ---
> >  drivers/gpu/drm/i915/i915_gem_execbuffer.c |  7 ---
> >  drivers/gpu/drm/i915/intel_engine_cs.c | 16 
> >  drivers/gpu/drm/i915/intel_ringbuffer.h| 12 +---
> >  4 files changed, 21 insertions(+), 21 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 789f7502cd1f..6020a94daf81 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -4360,11 +4360,4 @@ int remap_io_mapping(struct vm_area_struct *vma,
> >unsigned long addr, unsigned long pfn, unsigned long 
> > size,
> >struct io_mapping *iomap);
> >  
> > -static inline bool
> > -intel_engine_can_store_dword(struct intel_engine_cs *engine)
> > -{
> > - return __intel_engine_can_store_dword(INTEL_GEN(engine->i915),
> > -   engine->class);
> > -}
> > -
> >  #endif
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index 53718a245ded..7687483ff218 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -1168,6 +1168,9 @@ static u32 *reloc_gpu(struct i915_execbuffer *eb,
> >   if (eb_use_cmdparser(eb))
> >   return ERR_PTR(-EWOULDBLOCK);
> >  
> > + if (!intel_engine_can_store_dword(eb->engine))
> > + return ERR_PTR(-ENODEV);
> > +
> >   err = __reloc_gpu_alloc(eb, vma, len);
> >   if (unlikely(err))
> >   return ERR_PTR(err);
> > @@ -1192,9 +1195,7 @@ relocate_entry(struct i915_vma *vma,
> >  
> >   if (!eb->reloc_cache.vaddr &&
> >   (DBG_FORCE_RELOC == FORCE_GPU_RELOC ||
> > -  !reservation_object_test_signaled_rcu(vma->resv, true)) &&
> > - __intel_engine_can_store_dword(eb->reloc_cache.gen,
> > -eb->engine->class)) {
> > +  !reservation_object_test_signaled_rcu(vma->resv, true))) {
> >   const unsigned int gen = eb->reloc_cache.gen;
> >   unsigned int len;
> >   u32 *batch;
> > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> > b/drivers/gpu/drm/i915/intel_engine_cs.c
> > index ae668340620e..ff56de4816cb 100644
> > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > @@ -1378,6 +1378,22 @@ void intel_engines_mark_idle(struct drm_i915_private 
> > *i915)
> >   }
> >  }
> >  
> > +bool intel_engine_can_store_dword(struct intel_engine_cs *engine)
> > +{
> > + int gen = INTEL_GEN(engine->i915);
> > +
> > + if (gen <= 2)
> > + return false; /* uses physical not virtual addresses */
> > +
> > + if (gen == 3 && (IS_I915G(engine->i915) || IS_I915GM(engine->i915)))
> > + return false; /* uses physical not virtual addresses */
> 
> nit: 'gen' check seems redundant.

I was optimistic that it would make gcc smarter. :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Disable MI_STORE_DATA_IMM for i915g/i915gm

[Ville Syrjälä]

On Wed, Sep 06, 2017 at 03:40:08PM +0100, Chris Wilson wrote:
> The early gen3 machines (i915g/Grantsdale and i915gm/Alviso) share a lot
> of characteristics in their MI/GTT blocks with gen2, and in particular
> can only use physical addresses in MI_STORE_DATA_IMM. This makes it
> incompatible with our usage, so include those two machines in the
> blacklist to prevent usage.
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_drv.h|  7 ---
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c |  7 ---
>  drivers/gpu/drm/i915/intel_engine_cs.c | 16 
>  drivers/gpu/drm/i915/intel_ringbuffer.h| 12 +---
>  4 files changed, 21 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 789f7502cd1f..6020a94daf81 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -4360,11 +4360,4 @@ int remap_io_mapping(struct vm_area_struct *vma,
>unsigned long addr, unsigned long pfn, unsigned long size,
>struct io_mapping *iomap);
>  
> -static inline bool
> -intel_engine_can_store_dword(struct intel_engine_cs *engine)
> -{
> - return __intel_engine_can_store_dword(INTEL_GEN(engine->i915),
> -   engine->class);
> -}
> -
>  #endif
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 53718a245ded..7687483ff218 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1168,6 +1168,9 @@ static u32 *reloc_gpu(struct i915_execbuffer *eb,
>   if (eb_use_cmdparser(eb))
>   return ERR_PTR(-EWOULDBLOCK);
>  
> + if (!intel_engine_can_store_dword(eb->engine))
> + return ERR_PTR(-ENODEV);
> +
>   err = __reloc_gpu_alloc(eb, vma, len);
>   if (unlikely(err))
>   return ERR_PTR(err);
> @@ -1192,9 +1195,7 @@ relocate_entry(struct i915_vma *vma,
>  
>   if (!eb->reloc_cache.vaddr &&
>   (DBG_FORCE_RELOC == FORCE_GPU_RELOC ||
> -  !reservation_object_test_signaled_rcu(vma->resv, true)) &&
> - __intel_engine_can_store_dword(eb->reloc_cache.gen,
> -eb->engine->class)) {
> +  !reservation_object_test_signaled_rcu(vma->resv, true))) {
>   const unsigned int gen = eb->reloc_cache.gen;
>   unsigned int len;
>   u32 *batch;
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index ae668340620e..ff56de4816cb 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -1378,6 +1378,22 @@ void intel_engines_mark_idle(struct drm_i915_private 
> *i915)
>   }
>  }
>  
> +bool intel_engine_can_store_dword(struct intel_engine_cs *engine)
> +{
> + int gen = INTEL_GEN(engine->i915);
> +
> + if (gen <= 2)
> + return false; /* uses physical not virtual addresses */
> +
> + if (gen == 3 && (IS_I915G(engine->i915) || IS_I915GM(engine->i915)))
> + return false; /* uses physical not virtual addresses */

nit: 'gen' check seems redundant.

I suppose trying to do the relocs using physical addresses would be
quite a bit of work for little gain.

Patch lgtm
Reviewed-by: Ville Syrjälä 

> +
> + if (gen == 6 && engine->class == VIDEO_DECODE_CLASS)
> + return false; /* b0rked */
> +
> + return true;
> +}
> +
>  #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
>  #include "selftests/mock_engine.c"
>  #endif
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
> b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index 02d8974bf9ab..79c0021f3700 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -735,16 +735,6 @@ bool intel_engines_are_idle(struct drm_i915_private 
> *dev_priv);
>  void intel_engines_mark_idle(struct drm_i915_private *i915);
>  void intel_engines_reset_default_submission(struct drm_i915_private *i915);
>  
> -static inline bool
> -__intel_engine_can_store_dword(unsigned int gen, unsigned int class)
> -{
> - if (gen <= 2)
> - return false; /* uses physical not virtual addresses */
> -
> - if (gen == 6 && class == VIDEO_DECODE_CLASS)
> - return false; /* b0rked */
> -
> - return true;
> -}
> +bool intel_engine_can_store_dword(struct intel_engine_cs *engine);
>  
>  #endif /* _INTEL_RINGBUFFER_H_ */
> -- 
> 2.14.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list

[Intel-gfx] ✓ Fi.CI.BAT: success for lib: Disable MI_STORE_DATA_IMM for gen3 (i915g and i915gm)

[Patchwork]

== Series Details ==

Series: lib: Disable MI_STORE_DATA_IMM for gen3 (i915g and i915gm)
URL   : https://patchwork.freedesktop.org/series/29889/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
918863f8e3e8f49235fd2e4a36e11f386c06c11c intel_display_poller: Fix truncation 
of a test name.

with latest DRM-Tip kernel build CI_DRM_3045
c18a85fe008e drm-tip: 2017y-09m-06d-13h-17m-59s UTC integration manifest

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:456s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:450s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:367s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:558s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:256s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:522s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:529s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:521s
fi-cfl-s total:289  pass:249  dwarn:4   dfail:0   fail:0   skip:36  
time:455s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:443s
fi-glk-2atotal:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:621s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:453s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:430s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:430s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:510s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:478s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:509s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:597s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:598s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:532s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:478s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:541s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:520s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:449s
fi-skl-x1585ltotal:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:500s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:568s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:1   skip:39  
time:405s

== Logs ==

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

[Intel-gfx] [PATCH v3 5/5] tools/testing/scatterlist: Test new __sg_alloc_table_from_pages

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Exercise the new __sg_alloc_table_from_pages API (and through
it also the old sg_alloc_table_from_pages), checking that the
created table has the expected number of segments depending on
the sequence of input pages and other conditions.

v2: Move to data driven for readability.
v3: Add some more testcases and -fsanitize=undefined. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: linux-ker...@vger.kernel.org
Reviewed-by: Chris Wilson 
---
 tools/testing/scatterlist/Makefile   |  30 +
 tools/testing/scatterlist/linux/mm.h | 125 +++
 tools/testing/scatterlist/main.c |  79 ++
 3 files changed, 234 insertions(+)
 create mode 100644 tools/testing/scatterlist/Makefile
 create mode 100644 tools/testing/scatterlist/linux/mm.h
 create mode 100644 tools/testing/scatterlist/main.c

diff --git a/tools/testing/scatterlist/Makefile 
b/tools/testing/scatterlist/Makefile
new file mode 100644
index ..933c3a6e4d77
--- /dev/null
+++ b/tools/testing/scatterlist/Makefile
@@ -0,0 +1,30 @@
+CFLAGS += -I. -I../../include -g -O2 -Wall -fsanitize=address
+LDFLAGS += -fsanitize=address -fsanitize=undefined
+TARGETS = main
+OFILES = main.o scatterlist.o
+
+ifeq ($(BUILD), 32)
+CFLAGS += -m32
+LDFLAGS += -m32
+endif
+
+targets: include $(TARGETS)
+
+main: $(OFILES)
+
+clean:
+   $(RM) $(TARGETS) $(OFILES) scatterlist.c linux/scatterlist.h 
linux/highmem.h linux/kmemleak.h asm/io.h
+   @rmdir asm
+
+scatterlist.c: ../../../lib/scatterlist.c
+   @sed -e 's/^static //' -e 's/__always_inline //' -e 's/inline //' < $< 
> $@
+
+.PHONY: include
+
+include: ../../../include/linux/scatterlist.h
+   @mkdir -p linux
+   @mkdir -p asm
+   @touch asm/io.h
+   @touch linux/highmem.h
+   @touch linux/kmemleak.h
+   @cp $< linux/scatterlist.h
diff --git a/tools/testing/scatterlist/linux/mm.h 
b/tools/testing/scatterlist/linux/mm.h
new file mode 100644
index ..ccbb248ebdc1
--- /dev/null
+++ b/tools/testing/scatterlist/linux/mm.h
@@ -0,0 +1,125 @@
+#ifndef _LINUX_MM_H
+#define _LINUX_MM_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+typedef unsigned long dma_addr_t;
+
+#define unlikely
+
+#define BUG_ON(x) assert(!(x))
+
+#define WARN_ON(condition) ({   \
+int __ret_warn_on = !!(condition);  \
+unlikely(__ret_warn_on);\
+})
+
+#define WARN_ON_ONCE(condition) ({  \
+int __ret_warn_on = !!(condition);  \
+if (unlikely(__ret_warn_on))\
+assert(0);  \
+unlikely(__ret_warn_on);\
+})
+
+#define PAGE_SIZE  (4096)
+#define PAGE_SHIFT (12)
+#define PAGE_MASK  (~(PAGE_SIZE-1))
+
+#define __ALIGN_KERNEL(x, a)__ALIGN_KERNEL_MASK(x, (typeof(x))(a) 
- 1)
+#define __ALIGN_KERNEL_MASK(x, mask)(((x) + (mask)) & ~(mask))
+#define ALIGN(x, a) __ALIGN_KERNEL((x), (a))
+
+#define PAGE_ALIGN(addr) ALIGN(addr, PAGE_SIZE)
+
+#define offset_in_page(p)  ((unsigned long)(p) & ~PAGE_MASK)
+
+#define virt_to_page(x)((void *)x)
+#define page_address(x)((void *)x)
+
+static inline unsigned long page_to_phys(struct page *page)
+{
+   assert(0);
+
+   return 0;
+}
+
+#define page_to_pfn(page) ((unsigned long)(page) / PAGE_SIZE)
+#define pfn_to_page(pfn) (void *)((pfn) * PAGE_SIZE)
+#define nth_page(page,n) pfn_to_page(page_to_pfn((page)) + (n))
+
+#define __min(t1, t2, min1, min2, x, y) ({  \
+t1 min1 = (x);  \
+t2 min2 = (y);  \
+(void) ( == );\
+min1 < min2 ? min1 : min2; })
+
+#define ___PASTE(a,b) a##b
+#define __PASTE(a,b) ___PASTE(a,b)
+
+#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
+
+#define min(x, y)   \
+__min(typeof(x), typeof(y), \
+  __UNIQUE_ID(min1_), __UNIQUE_ID(min2_),   \
+  x, y)
+
+#define min_t(type, x, y)   \
+__min(type, type,   \
+  __UNIQUE_ID(min1_), __UNIQUE_ID(min2_),   \
+  x, y)
+
+#define preemptible() (1)
+
+static inline void *kmap(struct page *page)
+{
+   assert(0);
+
+   return NULL;
+}
+
+static inline void *kmap_atomic(struct page *page)
+{
+   assert(0);
+
+   return NULL;
+}
+
+static inline void kunmap(void *addr)
+{
+   assert(0);
+}
+
+static inline void kunmap_atomic(void *addr)
+{
+   assert(0);
+}
+

Re: [Intel-gfx] [PATCH] drm/i915: Disable MI_STORE_DATA_IMM for i915g/i915gm

[Chris Wilson]

Quoting Chris Wilson (2017-09-06 15:40:08)
> The early gen3 machines (i915g/Grantsdale and i915gm/Alviso) share a lot
> of characteristics in their MI/GTT blocks with gen2, and in particular
> can only use physical addresses in MI_STORE_DATA_IMM. This makes it
> incompatible with our usage, so include those two machines in the
> blacklist to prevent usage.
 
Fixes: 7dd4f6729f92 ("drm/i915: Async GPU relocation processing")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102562
> Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt] lib: Disable MI_STORE_DATA_IMM for gen3 (i915g and i915gm)

[Ville Syrjälä]

On Wed, Sep 06, 2017 at 03:36:15PM +0100, Chris Wilson wrote:
> The early gen3 machines inherited the MI block and restrictions from
> gen2, and may only use physical addresses in conjunction with
> MI_STORE_DATA_IMM -- that makes it unusable for us from userspace, where
> we can only use virtual offsets.

Matches my docs.

Reviewed-by: Ville Syrjälä 

> 
> Signed-off-by: Chris Wilson 
> ---
>  lib/igt_gt.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/lib/igt_gt.c b/lib/igt_gt.c
> index d5e8b557..b3f3b380 100644
> --- a/lib/igt_gt.c
> +++ b/lib/igt_gt.c
> @@ -557,6 +557,9 @@ bool gem_can_store_dword(int fd, unsigned int engine)
>   if (gen <= 2) /* requires physical addresses */
>   return false;
>  
> + if (gen == 3 && (info->is_grantsdale || info->is_alviso))
> + return false; /* only supports physical addresses */
> +
>   if (gen == 6 && (engine & ~(3<<13)) == I915_EXEC_BSD)
>   return false; /* kills the machine! */
>  
> -- 
> 2.14.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Disable MI_STORE_DATA_IMM for i915g/i915gm

[Chris Wilson]

The early gen3 machines (i915g/Grantsdale and i915gm/Alviso) share a lot
of characteristics in their MI/GTT blocks with gen2, and in particular
can only use physical addresses in MI_STORE_DATA_IMM. This makes it
incompatible with our usage, so include those two machines in the
blacklist to prevent usage.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h|  7 ---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  7 ---
 drivers/gpu/drm/i915/intel_engine_cs.c | 16 
 drivers/gpu/drm/i915/intel_ringbuffer.h| 12 +---
 4 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 789f7502cd1f..6020a94daf81 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4360,11 +4360,4 @@ int remap_io_mapping(struct vm_area_struct *vma,
 unsigned long addr, unsigned long pfn, unsigned long size,
 struct io_mapping *iomap);
 
-static inline bool
-intel_engine_can_store_dword(struct intel_engine_cs *engine)
-{
-   return __intel_engine_can_store_dword(INTEL_GEN(engine->i915),
- engine->class);
-}
-
 #endif
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 53718a245ded..7687483ff218 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1168,6 +1168,9 @@ static u32 *reloc_gpu(struct i915_execbuffer *eb,
if (eb_use_cmdparser(eb))
return ERR_PTR(-EWOULDBLOCK);
 
+   if (!intel_engine_can_store_dword(eb->engine))
+   return ERR_PTR(-ENODEV);
+
err = __reloc_gpu_alloc(eb, vma, len);
if (unlikely(err))
return ERR_PTR(err);
@@ -1192,9 +1195,7 @@ relocate_entry(struct i915_vma *vma,
 
if (!eb->reloc_cache.vaddr &&
(DBG_FORCE_RELOC == FORCE_GPU_RELOC ||
-!reservation_object_test_signaled_rcu(vma->resv, true)) &&
-   __intel_engine_can_store_dword(eb->reloc_cache.gen,
-  eb->engine->class)) {
+!reservation_object_test_signaled_rcu(vma->resv, true))) {
const unsigned int gen = eb->reloc_cache.gen;
unsigned int len;
u32 *batch;
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index ae668340620e..ff56de4816cb 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1378,6 +1378,22 @@ void intel_engines_mark_idle(struct drm_i915_private 
*i915)
}
 }
 
+bool intel_engine_can_store_dword(struct intel_engine_cs *engine)
+{
+   int gen = INTEL_GEN(engine->i915);
+
+   if (gen <= 2)
+   return false; /* uses physical not virtual addresses */
+
+   if (gen == 3 && (IS_I915G(engine->i915) || IS_I915GM(engine->i915)))
+   return false; /* uses physical not virtual addresses */
+
+   if (gen == 6 && engine->class == VIDEO_DECODE_CLASS)
+   return false; /* b0rked */
+
+   return true;
+}
+
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "selftests/mock_engine.c"
 #endif
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 02d8974bf9ab..79c0021f3700 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -735,16 +735,6 @@ bool intel_engines_are_idle(struct drm_i915_private 
*dev_priv);
 void intel_engines_mark_idle(struct drm_i915_private *i915);
 void intel_engines_reset_default_submission(struct drm_i915_private *i915);
 
-static inline bool
-__intel_engine_can_store_dword(unsigned int gen, unsigned int class)
-{
-   if (gen <= 2)
-   return false; /* uses physical not virtual addresses */
-
-   if (gen == 6 && class == VIDEO_DECODE_CLASS)
-   return false; /* b0rked */
-
-   return true;
-}
+bool intel_engine_can_store_dword(struct intel_engine_cs *engine);
 
 #endif /* _INTEL_RINGBUFFER_H_ */
-- 
2.14.1

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

[Intel-gfx] [PATCH igt] lib: Disable MI_STORE_DATA_IMM for gen3 (i915g and i915gm)

[Chris Wilson]

The early gen3 machines inherited the MI block and restrictions from
gen2, and may only use physical addresses in conjunction with
MI_STORE_DATA_IMM -- that makes it unusable for us from userspace, where
we can only use virtual offsets.

Signed-off-by: Chris Wilson 
---
 lib/igt_gt.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/igt_gt.c b/lib/igt_gt.c
index d5e8b557..b3f3b380 100644
--- a/lib/igt_gt.c
+++ b/lib/igt_gt.c
@@ -557,6 +557,9 @@ bool gem_can_store_dword(int fd, unsigned int engine)
if (gen <= 2) /* requires physical addresses */
return false;
 
+   if (gen == 3 && (info->is_grantsdale || info->is_alviso))
+   return false; /* only supports physical addresses */
+
if (gen == 6 && (engine & ~(3<<13)) == I915_EXEC_BSD)
return false; /* kills the machine! */
 
-- 
2.14.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] lib/sysfs: Fix fbcon rebind

[Ville Syrjälä]

On Wed, Sep 06, 2017 at 03:08:40PM +0100, Chris Wilson wrote:
> Quoting ville.syrj...@linux.intel.com (2017-09-06 14:04:01)
> > From: Ville Syrjälä 
> > 
> > "echo 1 > vtconN/bind" doesn't actually do anything. Looks like the only
> > way to rebind fbcon is to unbind the current console.
> > 
> > I suppose the failure to rebind might be a kernel bug, but I can't be
> > bothered to decode the vt.c spaghetti so let's just try to handle this
> > in igt. For simplicity let's assume the currently bound console is the
> > dummy console and unbind that when we want to rebind fbcon. That works
> > for me.
> > 
> > With rebinding not working we can't really tell wich console is going
> > to get bound anyway, so there's no way to make this code really robust,
> > assuming we ever had more than these two console drivers involved.
> 
> Hmm, CONFIG_DUMMY_CONSOLE suggests that the dummy isn't universal
> either. If there is no dummy, can the last be unbound? I have no idea.

DUMMY_CONSOLE isn't user visible and default=y, so you can't actually
disable it, I think.

It does have some suspicious looking dependencies though:
 depends on VGA_CONSOLE!=y || SGI_NEWPORT_CONSOLE!=y 

So it gets disabled only if you have both VGA and SGI_NEWPORT enabled.
I suspect someone meant to say '&&' instead of '||'. But for us the '||'
works better since we don't allow rebinding vgacon after it's been
kicked out, and so having dummy+vga is good.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for lib/sysfs: Fix fbcon rebind

[Patchwork]

== Series Details ==

Series: lib/sysfs: Fix fbcon rebind
URL   : https://patchwork.freedesktop.org/series/29880/
State : success

== Summary ==

Test kms_flip:
Subgroup plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Test perf:
Subgroup blocking:
pass   -> FAIL   (shard-hsw) fdo#102252 +1
Test kms_atomic_transition:
Subgroup plane-use-after-nonblocking-unbind:
fail   -> INCOMPLETE (shard-hsw) fdo#101847

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

shard-hswtotal:2226 pass:1215 dwarn:0   dfail:0   fail:16  skip:994 
time:9337s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Lift has-pinned-pages to caller of ____i915_gem_object_get_pages

[Patchwork]

== Series Details ==

Series: drm/i915: Lift has-pinned-pages to caller of 
i915_gem_object_get_pages
URL   : https://patchwork.freedesktop.org/series/29885/
State : warning

== Summary ==

Series 29885v1 drm/i915: Lift has-pinned-pages to caller of 
i915_gem_object_get_pages
https://patchwork.freedesktop.org/api/1.0/series/29885/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
fail   -> PASS   (fi-snb-2600) fdo#100215
Subgroup basic-flip-after-cursor-atomic:
pass   -> DMESG-WARN (fi-glk-2a)
Test pm_rpm:
Subgroup basic-pci-d3-state:
skip   -> PASS   (fi-cfl-s) fdo#102294

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215
fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:458s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:439s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:365s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:572s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:254s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:530s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:536s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:521s
fi-cfl-s total:289  pass:250  dwarn:4   dfail:0   fail:0   skip:35  
time:467s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:444s
fi-glk-2atotal:289  pass:259  dwarn:1   dfail:0   fail:0   skip:29  
time:620s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:452s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:430s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:430s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:508s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:479s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:518s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:602s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:606s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:524s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:537s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:522s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:451s
fi-skl-x1585ltotal:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:497s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:558s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:1   skip:39  
time:410s
fi-skl-6260u failed to connect after reboot

c18a85fe008e41f342e47ff4296e55654ba4fa4b drm-tip: 2017y-09m-06d-13h-17m-59s UTC 
integration manifest
3089b5885c4c drm/i915: Lift has-pinned-pages to caller of 
i915_gem_object_get_pages

== Logs ==

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

Re: [Intel-gfx] [PATCH i-g-t] lib/sysfs: Fix fbcon rebind

[Chris Wilson]

Quoting ville.syrj...@linux.intel.com (2017-09-06 14:04:01)
> From: Ville Syrjälä 
> 
> "echo 1 > vtconN/bind" doesn't actually do anything. Looks like the only
> way to rebind fbcon is to unbind the current console.
> 
> I suppose the failure to rebind might be a kernel bug, but I can't be
> bothered to decode the vt.c spaghetti so let's just try to handle this
> in igt. For simplicity let's assume the currently bound console is the
> dummy console and unbind that when we want to rebind fbcon. That works
> for me.
> 
> With rebinding not working we can't really tell wich console is going
> to get bound anyway, so there's no way to make this code really robust,
> assuming we ever had more than these two console drivers involved.

Hmm, CONFIG_DUMMY_CONSOLE suggests that the dummy isn't universal
either. If there is no dummy, can the last be unbound? I have no idea.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 12/22] meson: basic build system support

[Jani Nikula]

On Tue, 05 Sep 2017, Daniel Vetter  wrote:
> Why?
>
> Because it's fast.

And that's not even the main reason from my perspective! ;)

Please find some comments inline. None of them are blockers.

BR,
Jani.

>
> Like really, really fast.
>
> Some data (from a snb laptop, so rather lower-powered):
>
> - Incremental build after $ touch lib/igt_core.c with meson: 0.6s
>   It notices that the symbol list of the libigt.so hasn't changed and
>   doesn't bother re-linking the almost 300 binaries we have. make -j 6
>   for the same scenario takes 44s.
>
> - Incremental build with nothing changed: make: 0.7s, meson: 0.2s This
>   means stuff like --disable-git-hash is entirely pointless with
>   meson, it's faster than a make ever can be (with 0.6s).
>
> - Reconfigure stage: ninja reconfigure 0.8s vs. ./configure 8.6s)
>
> - Running tests, after a full build: ninja test 6s vs. make check 24s
>
> - Full build (i.e. including ./autogen.sh respectively meson build),
>   including tests, from a pristine git checkout. automake 2m49s vs.
>   meson 44s.
>
> Cc: Ville Syrjälä 
> Cc: Eric Anholt 
> Cc: Daniel Stone 
> Signed-off-by: Daniel Vetter 
> ---
>  .gitignore   |   1 +
>  assembler/meson.build|  73 ++
>  benchmarks/meson.build   |  36 +
>  lib/meson.build  | 166 ++
>  lib/prepend_log_domain.sh|   8 ++
>  lib/tests/meson.build|  34 +
>  lib/version.h.in |   1 +
>  meson.build  | 105 ++
>  overlay/meson.build  |  59 
>  tests/generate_testlist.sh   |  10 ++
>  tests/meson.build| 290 
> +++
>  tools/meson.build|  59 
>  tools/null_state_gen/meson.build |  15 ++
>  13 files changed, 857 insertions(+)
>  create mode 100644 assembler/meson.build
>  create mode 100644 benchmarks/meson.build
>  create mode 100644 lib/meson.build
>  create mode 100755 lib/prepend_log_domain.sh
>  create mode 100644 lib/tests/meson.build
>  create mode 100644 lib/version.h.in
>  create mode 100644 meson.build
>  create mode 100644 overlay/meson.build
>  create mode 100755 tests/generate_testlist.sh
>  create mode 100644 tests/meson.build
>  create mode 100644 tools/meson.build
>  create mode 100644 tools/null_state_gen/meson.build
>
> diff --git a/.gitignore b/.gitignore
> index 6204965a0e32..e6919272d8b6 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -93,3 +93,4 @@ intel-gpu-tools-*/
>  
>  piglit
>  results
> +build
> diff --git a/assembler/meson.build b/assembler/meson.build
> new file mode 100644
> index ..b0e2db25
> --- /dev/null
> +++ b/assembler/meson.build
> @@ -0,0 +1,73 @@
> +lib_brw_src = [
> + 'brw_context.c',
> + 'brw_disasm.c',
> + 'brw_eu.c',
> + 'brw_eu_compact.c',
> + 'brw_eu_debug.c',
> + 'brw_eu_emit.c',
> + 'brw_eu_util.c',
> + 'gen8_disasm.c',
> + 'gen8_instruction.c',
> + 'ralloc.c',
> +]

FWIW I like this style of assigning lists.

> +
> +lib_brw = shared_library('brw', lib_brw_src,
> + dependencies : igt_deps)

The Emacs meson mode nicely indents the continuation lines after the
opening (. These seem off... all over the place.

> +
> +flex = find_program('flex')
> +bison = find_program('bison')
> +
> +lgen = generator(flex,
> + output : '@BASENAME@.c',
> + arguments : ['-o', '@OUTPUT@', '@INPUT@'])
> +
> +lfiles = lgen.process('lex.l')
> +
> +pgen = generator(bison,
> + output : ['@BASENAME@.c', '@BASENAME@.h'],
> + arguments : ['@INPUT@', '--defines=@OUTPUT1@', 
> '--output=@OUTPUT0@'])
> +
> +pfiles = pgen.process('gram.y')
> +
> +executable('intel-gen4asm', 'main.c', lfiles, pfiles, link_with : lib_brw)
> +
> +executable('intel-gen4disasm', 'disasm-main.c', link_with : lib_brw)
> +
> +gen4asm_testcases = [
> + 'test/mov',
> + 'test/frc',
> + 'test/rndd',
> + 'test/rndu',
> + 'test/rnde',
> + 'test/rnde-intsrc',
> + 'test/rndz',
> + 'test/lzd',
> + 'test/not',
> + 'test/immediate',
> +]
> +
> +# Those tests were already failing when the assembler was imported from
> +# the intel-gen4asm git repository:
> +#   http://cgit.freedesktop.org/xorg/app/intel-gen4asm/
> +# We disable them "for now" as a workaround to be able to release i-g-t
> +gen4asm_testcases_broken = [
> + 'test/declare',
> + 'test/jmpi',
> + 'test/if',
> + 'test/iff',
> + 'test/while',
> + 'test/else',
> + 'test/break',
> + 'test/cont',
> + 'test/halt',
> + 'test/wait',
> + 'test/endif',
> +]
> +
> +test_runner = find_program('test/run-test.sh')
> +foreach testcase : gen4asm_testcases
> + test('assembler: ' + testcase, test_runner,
> + args : testcase,
> +   

[Intel-gfx] ✓ Fi.CI.BAT: success for tests: Add kms_atomic_interruptible test, v2.

[Patchwork]

== Series Details ==

Series: tests: Add kms_atomic_interruptible test, v2.
URL   : https://patchwork.freedesktop.org/series/29877/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
918863f8e3e8f49235fd2e4a36e11f386c06c11c intel_display_poller: Fix truncation 
of a test name.

with latest DRM-Tip kernel build CI_DRM_3045
c18a85fe008e drm-tip: 2017y-09m-06d-13h-17m-59s UTC integration manifest

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
fail   -> PASS   (fi-snb-2600) fdo#100215
Test kms_flip:
Subgroup basic-flip-vs-modeset:
skip   -> PASS   (fi-skl-x1585l) fdo#101781
Test pm_rpm:
Subgroup basic-pci-d3-state:
skip   -> PASS   (fi-cfl-s) fdo#102294

fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215
fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781
fdo#102294 https://bugs.freedesktop.org/show_bug.cgi?id=102294

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:460s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:439s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:362s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:570s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:253s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:524s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:528s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:521s
fi-cfl-s total:289  pass:250  dwarn:4   dfail:0   fail:0   skip:35  
time:466s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:438s
fi-glk-2atotal:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:617s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:452s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:433s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:429s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:508s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:474s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:518s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:601s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:601s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:530s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:470s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:539s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:523s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:454s
fi-skl-x1585ltotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:513s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:418s

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Lift has-pinned-pages to caller of ____i915_gem_object_get_pages

[Chris Wilson]

i915_gem_object_attach_phys() is trying to swap out its shmemfs pages
for a new set of physically contiguous pages, but unfortunately triggers
an assert inside get-pages.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 72008e4c8c8f..1545a4ef09c4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2479,8 +2479,6 @@ static int i915_gem_object_get_pages(struct 
drm_i915_gem_object *obj)
 {
struct sg_table *pages;
 
-   GEM_BUG_ON(i915_gem_object_has_pinned_pages(obj));
-
if (unlikely(obj->mm.madv != I915_MADV_WILLNEED)) {
DRM_DEBUG("Attempting to obtain a purgeable object\n");
return -EFAULT;
@@ -2510,6 +2508,8 @@ int __i915_gem_object_get_pages(struct 
drm_i915_gem_object *obj)
return err;
 
if (unlikely(IS_ERR_OR_NULL(obj->mm.pages))) {
+   GEM_BUG_ON(i915_gem_object_has_pinned_pages(obj));
+
err = i915_gem_object_get_pages(obj);
if (err)
goto unlock;
@@ -2593,6 +2593,8 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object 
*obj,
 
if (!atomic_inc_not_zero(>mm.pages_pin_count)) {
if (unlikely(IS_ERR_OR_NULL(obj->mm.pages))) {
+   GEM_BUG_ON(i915_gem_object_has_pinned_pages(obj));
+
ret = i915_gem_object_get_pages(obj);
if (ret)
goto err_unlock;
-- 
2.14.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 lib/sysfs: Fix fbcon rebind

[Patchwork]

== Series Details ==

Series: lib/sysfs: Fix fbcon rebind
URL   : https://patchwork.freedesktop.org/series/29880/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
918863f8e3e8f49235fd2e4a36e11f386c06c11c intel_display_poller: Fix truncation 
of a test name.

with latest DRM-Tip kernel build CI_DRM_3044
0640ea73be26 drm-tip: 2017y-09m-06d-06h-41m-15s UTC integration manifest

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:443s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:381s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:543s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:269s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:510s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:509s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:508s
fi-cfl-s total:289  pass:250  dwarn:4   dfail:0   fail:0   skip:35  
time:451s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:451s
fi-glk-2atotal:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:598s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:430s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:409s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:440s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:493s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:464s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:495s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:573s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:593s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:553s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:473s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:530s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:507s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:458s
fi-skl-x1585ltotal:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:483s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:578s
fi-snb-2600  total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:428s

== Logs ==

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Re-enable GTT following a device reset (rev2)

[Chris Wilson]

Quoting Patchwork (2017-09-06 12:34:12)
> == Series Details ==
> 
> Series: drm/i915: Re-enable GTT following a device reset (rev2)
> URL   : https://patchwork.freedesktop.org/series/29845/
> State : warning
> 
> == Summary ==
> 
> Series 29845v2 drm/i915: Re-enable GTT following a device reset
> https://patchwork.freedesktop.org/api/1.0/series/29845/revisions/2/mbox/
> 
> Test kms_cursor_legacy:
> Subgroup basic-busy-flip-before-cursor-atomic:
> pass   -> FAIL   (fi-snb-2600) fdo#100215 +1
> Test pm_rpm:
> Subgroup basic-pci-d3-state:
> pass   -> SKIP   (fi-cfl-s)
> 
> fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215

Double checked that the reordering still fixes my i915gm; with CI
checking that we haven't broken hang recovery elsewhere.

Pushed, many thanks that after many deadends, on the world's slowest
netbook, we have this resolved.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] lib/sysfs: Fix fbcon rebind

[ville . syrjala]

From: Ville Syrjälä 

"echo 1 > vtconN/bind" doesn't actually do anything. Looks like the only
way to rebind fbcon is to unbind the current console.

I suppose the failure to rebind might be a kernel bug, but I can't be
bothered to decode the vt.c spaghetti so let's just try to handle this
in igt. For simplicity let's assume the currently bound console is the
dummy console and unbind that when we want to rebind fbcon. That works
for me.

With rebinding not working we can't really tell wich console is going
to get bound anyway, so there's no way to make this code really robust,
assuming we ever had more than these two console drivers involved.

Signed-off-by: Ville Syrjälä 
---
 lib/igt_sysfs.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/igt_sysfs.c b/lib/igt_sysfs.c
index 9227e374bf44..12be8a165c34 100644
--- a/lib/igt_sysfs.c
+++ b/lib/igt_sysfs.c
@@ -516,13 +516,14 @@ void kick_fbcon(bool enable)
if (len >= 0)
buf[len] = '\0';
 
-   if (!strstr(buf, "frame buffer device"))
+   if (!strstr(buf, enable ? "dummy device" :
+   "frame buffer device"))
continue;
 
sprintf(buf, "%s/%s/bind", path, de->d_name);
fd = open(buf, O_WRONLY);
if (fd != -1) {
-   igt_ignore_warn(write(fd, enable ? "1\n" : "0\n", 2));
+   igt_ignore_warn(write(fd, "0\n", 2));
close(fd);
}
}
-- 
2.13.5

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for tests: Add kms_atomic_interruptible test, v2.

[Patchwork]

== Series Details ==

Series: tests: Add kms_atomic_interruptible test, v2.
URL   : https://patchwork.freedesktop.org/series/29877/
State : warning

== Summary ==

IGT patchset tested on top of latest successful build
918863f8e3e8f49235fd2e4a36e11f386c06c11c intel_display_poller: Fix truncation 
of a test name.

with latest DRM-Tip kernel build CI_DRM_3044
0640ea73be26 drm-tip: 2017y-09m-06d-06h-41m-15s UTC integration manifest

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
pass   -> FAIL   (fi-snb-2600) fdo#100215
Test kms_flip:
Subgroup basic-flip-vs-modeset:
skip   -> PASS   (fi-skl-x1585l) fdo#101781
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> SKIP   (fi-cfl-s)

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:458s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:440s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:362s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:559s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:254s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:524s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:527s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:522s
fi-cfl-s total:289  pass:249  dwarn:4   dfail:0   fail:0   skip:36  
time:471s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:442s
fi-glk-2atotal:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:613s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:450s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:432s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:430s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:511s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:483s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:510s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:600s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:601s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:527s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:542s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:519s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:441s
fi-skl-x1585ltotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:518s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:561s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:1   skip:39  
time:406s

== Logs ==

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Re-enable GTT following a device reset

[Chris Wilson]

Quoting Ville Syrjälä (2017-09-06 13:13:05)
> On Wed, Sep 06, 2017 at 12:14:05PM +0100, Chris Wilson wrote:
> > Ville Syrjälä spotted that PGETBL_CTL was losing its enable bit upon a
> > reset. That was causing the display to show garbage on his 945gm. On my
> > i915gm the effect was far more severe; re-enabling the display following
> > the reset without PGETBL_CTL being enabled lead to an immediate hard
> > hang.
> > 
> > We do have a routine to re-enable PGETBL_CTL which is applicable to
> > gen2-4, although on gen4 it is documented that a graphics reset doesn't
> > alter the register (no such wording is given for gen3) and should be safe
> > to call to punch back in the enable bit. However, that leaves the question
> > of whether we need to completely re-initialise the register and the
> > rest of the GSM. For g33/pnv/gen4+, where we do have a configurable
> > page table, its contents do seem to be kept, and so we should be able to
> > recover without having to reinitialise the GTT from scratch (as prior to
> > g33, that register is configured by the BIOS and we leave alone except
> > for the enable bit).
> > 
> > This appears to have been broken by commit 5fbd0418eef2 ("drm/i915:
> > Re-enable GGTT earlier during resume on pre-gen6 platforms"), which
> > moved the intel_enable_gtt() from i915_gem_init_hw() (also used by
> > reset) to add it earlier during hw init and resume, missing the reset
> > path.
> > 
> > v2: Find the culprit, rearrange ggtt_enable to be before gem_init_hw to
> > match init/resume
> > 
> > Reported-by: Ville Syrjälä 
> > Fixes: 5fbd0418eef2 ("drm/i915: Re-enable GGTT earlier during resume on 
> > pre-gen6 platforms")
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101852
> > Signed-off-by: Chris Wilson 
> > Cc: Ville Syrjälä 
> > Cc: Daniel Vetter 
> > Reviewed-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 12 +---
> >  1 file changed, 9 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index f10a078e3a55..ff70fc45ba7c 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1892,9 +1892,15 @@ void i915_reset(struct drm_i915_private *i915, 
> > unsigned int flags)
> >  
> >   /*
> >* Everything depends on having the GTT running, so we need to start
> > -  * there.  Fortunately we don't need to do this unless we reset the
> > -  * chip at a PCI level.
> > -  *
> > +  * there.
> > +  */
> > + ret = i915_ggtt_enable_hw(i915);
> > + if (ret) {
> > + DRM_ERROR("Failed to re-enable GGTT following reset %d\n", 
> > ret);
> > + goto error;
> > + }
> 
> I do wonder a bit whether the hardware might object to the fact that
> we restore fences before the GGTT gets re-enabled. But I suppose it's
> possible there's no linkage between the two until someone actually
> accesses the GGTT...

That's a reasonable suggestion. The real challenge is finding a name for
each step ;)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 5/5] tools/testing/scatterlist: Test new __sg_alloc_table_from_pages

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-09-06 13:10:57)
> 
> On 06/09/2017 11:48, Chris Wilson wrote:
> > All ascending. Interesting challenge for 3,2,1,0; it can be coalesced,
> > we just don't. I wonder if we are missing some like that. But for the
> 
> Hm, how do you think descending pages could be coalesced? By 
> re-arranging the pages? But that would break everything, do I don't get it.

Wishful thinking; I wasn't considering the order inside the object, just
their physical addresses.
> 
> > moment, 0, 2, 1, would be a good addition to the above set.
> > 
> > Is there any value in checking overflows in this interface?
> 
> Overflows as in size > num_pages * PAGE_SIZE as passed in to 
> __sg_alloc_table_from_pages ? It is not checked in the implementation at 
> the moment and it looks it is harmless.

Just thinking aloud if there was a way to get a mult/add overflow. That
we do page size coalescing, the only avenue is from a buggy max_seg.

Going back to the makefile, perhaps add the magic for ubsan as well?
-fsanitize=address -fsanitize=undefined
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] tests: Add kms_atomic_interruptible test, v2.

[Maarten Lankhorst]

This tests the various parts of atomic that I want to make
interruptible. Running with --debug shows the stats from
__igt_sigiter_continue, which can be used to make sure that
we don't fall over.

The default igt kms helpers use drmIoctl, which is not intercepted
by igt_while_interruptible. Only igt_ioctl is. This means we have
to call the ioctls manually here.

Changes since v1:
- Implement interruptible DPMS checking too.
- Use igt_ioctl + igt_while_interruptible, instead of the signal helper
  shotgun.

Signed-off-by: Maarten Lankhorst 
Cc: Daniel Stone 
---
 lib/igt_kms.c|   3 +-
 lib/igt_kms.h|   1 +
 tests/Makefile.sources   |   1 +
 tests/kms_atomic_interruptible.c | 319 +++
 4 files changed, 323 insertions(+), 1 deletion(-)
 create mode 100644 tests/kms_atomic_interruptible.c

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 14e2701c3afd..1f57e8981347 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -186,7 +186,8 @@ const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
 
 const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
"scaling mode",
-   "CRTC_ID"
+   "CRTC_ID",
+   "DPMS"
 };
 
 /*
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index e5dc329b161e..3d1061fa08c8 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -114,6 +114,7 @@ extern const char *igt_crtc_prop_names[];
 enum igt_atomic_connector_properties {
IGT_CONNECTOR_SCALING_MODE = 0,
IGT_CONNECTOR_CRTC_ID,
+   IGT_CONNECTOR_DPMS,
IGT_NUM_CONNECTOR_PROPS
 };
 
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 0f4e39af10a1..cf542df181a8 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -172,6 +172,7 @@ TESTS_progs = \
kms_3d \
kms_addfb_basic \
kms_atomic \
+   kms_atomic_interruptible \
kms_atomic_transition \
kms_busy \
kms_ccs \
diff --git a/tests/kms_atomic_interruptible.c b/tests/kms_atomic_interruptible.c
new file mode 100644
index ..6ec7a666b995
--- /dev/null
+++ b/tests/kms_atomic_interruptible.c
@@ -0,0 +1,319 @@
+/*
+ * Copyright © 2016 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 "igt.h"
+#include "drmtest.h"
+#include "sw_sync.h"
+
+enum plane_test_type
+{
+   test_legacy_modeset,
+   test_atomic_modeset,
+   test_legacy_dpms,
+   test_setplane,
+   test_setcursor,
+   test_pageflip
+};
+
+static int block_plane(igt_display_t *display, igt_output_t *output, enum 
plane_test_type test_type, igt_plane_t *plane)
+{
+   int timeline = sw_sync_timeline_create();
+
+   igt_fork(child, 1) {
+   /* Ignore the signal helper, we need to block indefinitely on 
the fence. */
+   signal(SIGCONT, SIG_IGN);
+
+   if (test_type == test_legacy_modeset || test_type == 
test_atomic_modeset) {
+   igt_output_set_pipe(output, PIPE_NONE);
+   igt_plane_set_fb(plane, NULL);
+   }
+   igt_plane_set_fence_fd(plane, 
sw_sync_timeline_create_fence(timeline, 1));
+
+   igt_display_commit2(display, COMMIT_ATOMIC);
+   }
+
+   return timeline;
+}
+
+static void unblock(int block)
+{
+   sw_sync_timeline_inc(block, 1);
+   close(block);
+}
+
+static void ev_page_flip(int fd, unsigned seq, unsigned tv_sec, unsigned 
tv_usec, void *user_data)
+{
+   igt_debug("Retrieved vblank seq: %u on unk\n", seq);
+}
+
+static drmEventContext drm_events = {
+   .version = 2,
+   .page_flip_handler = ev_page_flip
+};
+
+static void run_plane_test(igt_display_t *display, enum pipe pipe, 
igt_output_t *output,
+  enum plane_test_type test_type, unsigned plane_type)
+{
+   

Re: [Intel-gfx] [PATCH v2] drm/i915: Re-enable GTT following a device reset

[Ville Syrjälä]

On Wed, Sep 06, 2017 at 12:14:05PM +0100, Chris Wilson wrote:
> Ville Syrjälä spotted that PGETBL_CTL was losing its enable bit upon a
> reset. That was causing the display to show garbage on his 945gm. On my
> i915gm the effect was far more severe; re-enabling the display following
> the reset without PGETBL_CTL being enabled lead to an immediate hard
> hang.
> 
> We do have a routine to re-enable PGETBL_CTL which is applicable to
> gen2-4, although on gen4 it is documented that a graphics reset doesn't
> alter the register (no such wording is given for gen3) and should be safe
> to call to punch back in the enable bit. However, that leaves the question
> of whether we need to completely re-initialise the register and the
> rest of the GSM. For g33/pnv/gen4+, where we do have a configurable
> page table, its contents do seem to be kept, and so we should be able to
> recover without having to reinitialise the GTT from scratch (as prior to
> g33, that register is configured by the BIOS and we leave alone except
> for the enable bit).
> 
> This appears to have been broken by commit 5fbd0418eef2 ("drm/i915:
> Re-enable GGTT earlier during resume on pre-gen6 platforms"), which
> moved the intel_enable_gtt() from i915_gem_init_hw() (also used by
> reset) to add it earlier during hw init and resume, missing the reset
> path.
> 
> v2: Find the culprit, rearrange ggtt_enable to be before gem_init_hw to
> match init/resume
> 
> Reported-by: Ville Syrjälä 
> Fixes: 5fbd0418eef2 ("drm/i915: Re-enable GGTT earlier during resume on 
> pre-gen6 platforms")

Ouch. So it was me that broke this. Sorry about that folks.

> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101852
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f10a078e3a55..ff70fc45ba7c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1892,9 +1892,15 @@ void i915_reset(struct drm_i915_private *i915, 
> unsigned int flags)
>  
>   /*
>* Everything depends on having the GTT running, so we need to start
> -  * there.  Fortunately we don't need to do this unless we reset the
> -  * chip at a PCI level.
> -  *
> +  * there.
> +  */
> + ret = i915_ggtt_enable_hw(i915);
> + if (ret) {
> + DRM_ERROR("Failed to re-enable GGTT following reset %d\n", ret);
> + goto error;
> + }
> +
> + /*
>* Next we need to restore the context, but we don't use those
>* yet either...
>*
> -- 
> 2.14.1

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Re-enable GTT following a device reset

[Ville Syrjälä]

On Wed, Sep 06, 2017 at 12:14:05PM +0100, Chris Wilson wrote:
> Ville Syrjälä spotted that PGETBL_CTL was losing its enable bit upon a
> reset. That was causing the display to show garbage on his 945gm. On my
> i915gm the effect was far more severe; re-enabling the display following
> the reset without PGETBL_CTL being enabled lead to an immediate hard
> hang.
> 
> We do have a routine to re-enable PGETBL_CTL which is applicable to
> gen2-4, although on gen4 it is documented that a graphics reset doesn't
> alter the register (no such wording is given for gen3) and should be safe
> to call to punch back in the enable bit. However, that leaves the question
> of whether we need to completely re-initialise the register and the
> rest of the GSM. For g33/pnv/gen4+, where we do have a configurable
> page table, its contents do seem to be kept, and so we should be able to
> recover without having to reinitialise the GTT from scratch (as prior to
> g33, that register is configured by the BIOS and we leave alone except
> for the enable bit).
> 
> This appears to have been broken by commit 5fbd0418eef2 ("drm/i915:
> Re-enable GGTT earlier during resume on pre-gen6 platforms"), which
> moved the intel_enable_gtt() from i915_gem_init_hw() (also used by
> reset) to add it earlier during hw init and resume, missing the reset
> path.
> 
> v2: Find the culprit, rearrange ggtt_enable to be before gem_init_hw to
> match init/resume
> 
> Reported-by: Ville Syrjälä 
> Fixes: 5fbd0418eef2 ("drm/i915: Re-enable GGTT earlier during resume on 
> pre-gen6 platforms")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101852
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f10a078e3a55..ff70fc45ba7c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1892,9 +1892,15 @@ void i915_reset(struct drm_i915_private *i915, 
> unsigned int flags)
>  
>   /*
>* Everything depends on having the GTT running, so we need to start
> -  * there.  Fortunately we don't need to do this unless we reset the
> -  * chip at a PCI level.
> -  *
> +  * there.
> +  */
> + ret = i915_ggtt_enable_hw(i915);
> + if (ret) {
> + DRM_ERROR("Failed to re-enable GGTT following reset %d\n", ret);
> + goto error;
> + }

I do wonder a bit whether the hardware might object to the fact that
we restore fences before the GGTT gets re-enabled. But I suppose it's
possible there's no linkage between the two until someone actually
accesses the GGTT...

CCID/PPGTT also seems to get re-enabled before this but since that's
gen6+ stuff it doesn't matter.

This does help my 945gm, so
Tested-by: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 

> +
> + /*
>* Next we need to restore the context, but we don't use those
>* yet either...
>*
> -- 
> 2.14.1

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 5/5] tools/testing/scatterlist: Test new __sg_alloc_table_from_pages

[Tvrtko Ursulin]

On 06/09/2017 11:48, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2017-09-05 11:24:03)

From: Tvrtko Ursulin 

Exercise the new __sg_alloc_table_from_pages API (and through
it also the old sg_alloc_table_from_pages), checking that the
created table has the expected number of segments depending on
the sequence of input pages and other conditions.

v2: Move to data driven for readability.

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: linux-ker...@vger.kernel.org
---
  tools/testing/scatterlist/Makefile   |  30 +
  tools/testing/scatterlist/linux/mm.h | 125 +++
  tools/testing/scatterlist/main.c |  74 +
  3 files changed, 229 insertions(+)
  create mode 100644 tools/testing/scatterlist/Makefile
  create mode 100644 tools/testing/scatterlist/linux/mm.h
  create mode 100644 tools/testing/scatterlist/main.c

diff --git a/tools/testing/scatterlist/Makefile 
b/tools/testing/scatterlist/Makefile
new file mode 100644
index ..0867e0ef32d6
--- /dev/null
+++ b/tools/testing/scatterlist/Makefile
@@ -0,0 +1,30 @@
+CFLAGS += -I. -I../../include -g -O2 -Wall -fsanitize=address
+LDFLAGS += -fsanitize=address
+TARGETS = main
+OFILES = main.o scatterlist.o
+
+ifeq ($(BUILD), 32)
+CFLAGS += -m32
+LDFLAGS += -m32
+endif


Hmm, are there no HOST_CFLAGS? No. I wonder how menuconfig/xconfig get
compiled.

HOSTCC, HOSTCFLAGS.

hostprogs-y := main
always := $(hostprogs-y)

But nothing else seems to use HOSTCC in testing/selftests


I lifted it frim an existing makefile. I think this means no one was 
interested in building tests while doing a cross compile.



+targets: include $(TARGETS)
+
+main: $(OFILES)
+
+clean:
+   $(RM) $(TARGETS) $(OFILES) scatterlist.c linux/scatterlist.h 
linux/highmem.h linux/kmemleak.h asm/io.h
+   @rmdir asm
+
+scatterlist.c: ../../../lib/scatterlist.c
+   @sed -e 's/^static //' -e 's/__always_inline //' -e 's/inline //' < $< 
> $@


I think I would have used

#define __always_inline inline
#include "../../../lib/scatterlist.c"


Again, I lifted the approach from one of the existing tests. It might be 
beneficial to have a local copy when debugging, but it is probably very 
marginal and both approaches look OK.



diff --git a/tools/testing/scatterlist/main.c b/tools/testing/scatterlist/main.c
new file mode 100644
index ..8ca5c8703eb7
--- /dev/null
+++ b/tools/testing/scatterlist/main.c
@@ -0,0 +1,74 @@
+#include 
+#include 
+
+#include 
+
+#define MAX_PAGES (64)
+
+static void set_pages(struct page **pages, const unsigned *array, unsigned num)
+{
+   unsigned int i;
+
+   assert(num < MAX_PAGES);
+   for (i = 0; i < num; i++)
+   pages[i] = (struct page *)(unsigned long)
+  ((1 + array[i]) * PAGE_SIZE);


pfn_to_page(PFN_BIAS + array[i]) ? Ah, that relies on headers. Ok.


+}
+
+#define pfn(...) (unsigned []){ __VA_ARGS__ }
+
+int main(void)
+{
+   const unsigned int sgmax = SCATTERLIST_MAX_SEGMENT;
+   struct test {
+   int alloc_ret;
+   unsigned num_pages;
+   unsigned *pfn;
+   unsigned size;
+   unsigned int max_seg;
+   unsigned int expected_segments;
+   } *test, tests[] = {
+   { -EINVAL, 1, pfn(0), PAGE_SIZE, PAGE_SIZE + 1, 1 },
+   { -EINVAL, 1, pfn(0), PAGE_SIZE, 0, 1 },
+   { -EINVAL, 1, pfn(0), PAGE_SIZE, sgmax + 1, 1 },
+   { 0, 1, pfn(0), PAGE_SIZE, sgmax, 1 },
+   { 0, 1, pfn(0), 1, sgmax, 1 },
+   { 0, 2, pfn(0, 1), 2 * PAGE_SIZE, sgmax, 1 },
+   { 0, 3, pfn(0, 1, 3), 3 * PAGE_SIZE, sgmax, 2 },
+   { 0, 4, pfn(0, 1, 3, 4), 4 * PAGE_SIZE, sgmax, 2 },
+   { 0, 5, pfn(0, 1, 3, 4, 5), 5 * PAGE_SIZE, sgmax, 2 },
+   { 0, 5, pfn(0, 1, 3, 4, 6), 5 * PAGE_SIZE, sgmax, 3 },
+   { 0, 5, pfn(0, 1, 2, 3, 4), 5 * PAGE_SIZE, sgmax, 1 },
+   { 0, 5, pfn(0, 1, 2, 3, 4), 5 * PAGE_SIZE, 2 * PAGE_SIZE, 3 },
+   { 0, 6, pfn(0, 1, 2, 3, 4, 5), 6 * PAGE_SIZE, 2 * PAGE_SIZE, 3 
},
+   { 0, 6, pfn(0, 2, 3, 4, 5, 6), 6 * PAGE_SIZE, 2 * PAGE_SIZE, 4 
},
+   { 0, 6, pfn(0, 1, 3, 4, 5, 6), 6 * PAGE_SIZE, 2 * PAGE_SIZE, 3 
},


All ascending. Interesting challenge for 3,2,1,0; it can be coalesced,
we just don't. I wonder if we are missing some like that. But for the


Hm, how do you think descending pages could be coalesced? By 
re-arranging the pages? But that would break everything, do I don't get it.



moment, 0, 2, 1, would be a good addition to the above set.

Is there any value in checking overflows in this interface?


Overflows as in size > num_pages * PAGE_SIZE as passed in to 
__sg_alloc_table_from_pages ? It is not checked in the implementation at 
the moment and it looks it is harmless.


There 

Re: [Intel-gfx] [PATCH i-g-t 07/22] lib: clean up header includes

[Chris Wilson]

Quoting Daniel Vetter (2017-09-05 13:36:09)
> diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
> index f2a94b5572ea..a2061ff6138e 100644
> --- a/lib/igt_dummyload.c
> +++ b/lib/igt_dummyload.c
> @@ -22,11 +22,18 @@
>   *
>   */
>  
> -#include "igt.h"
> -#include "igt_dummyload.h"
>  #include 
>  #include 
>  #include 
> +#include 

For PROT_*? It's using the gem_mmap/gem_munmap interfaces, should we not
then be defining PROT_* as part of that interface.

We don't need the raw syscall interface here.

> +
> +#include 
> +
> +#include "igt_dummyload.h"
> +#include "igt_gt.h"
> +#include "intel_batchbuffer.h"

What are we pulling in from batchbuffer.h? I think you mean intel_reg.h.
Both are inappropriate places for MI commands.

igt_core.h for igt_require

-#include "igt.h"
-#include "igt_dummyload.h"
 #include 
 #include 
-#include 
+
+#include 
+
+#include "igt_core.h"
+#include "igt_dummyload.h"
+#include "igt_gt.h"
+#include "intel_chipset.h"
+#include "intel_reg.h"
+#include "ioctl_wrappers.h"

plus the indirect sys/mman.h via ioctl_wrappers.h
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Re-enable GTT following a device reset (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Re-enable GTT following a device reset (rev2)
URL   : https://patchwork.freedesktop.org/series/29845/
State : warning

== Summary ==

Series 29845v2 drm/i915: Re-enable GTT following a device reset
https://patchwork.freedesktop.org/api/1.0/series/29845/revisions/2/mbox/

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
pass   -> FAIL   (fi-snb-2600) fdo#100215 +1
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> SKIP   (fi-cfl-s)

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:454s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:437s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:361s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:548s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:254s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:522s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:523s
fi-byt-n2820 total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  
time:514s
fi-cfl-s total:289  pass:249  dwarn:4   dfail:0   fail:0   skip:36  
time:462s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:440s
fi-glk-2atotal:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:615s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:444s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:424s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:424s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:508s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:475s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:515s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:599s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:600s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:524s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:468s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:534s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:520s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:446s
fi-skl-x1585ltotal:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:488s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:555s
fi-snb-2600  total:289  pass:248  dwarn:0   dfail:0   fail:2   skip:39  
time:420s

0640ea73be26f37458cfff3943bed7055536da84 drm-tip: 2017y-09m-06d-06h-41m-15s UTC 
integration manifest
3968667f8b19 drm/i915: Re-enable GTT following a device reset

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Move device_info.has_snoop into the static tables

[Patchwork]

== Series Details ==

Series: drm/i915: Move device_info.has_snoop into the static tables
URL   : https://patchwork.freedesktop.org/series/29870/
State : warning

== Summary ==

Series 29870v1 drm/i915: Move device_info.has_snoop into the static tables
https://patchwork.freedesktop.org/api/1.0/series/29870/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
pass   -> FAIL   (fi-snb-2600) fdo#100215 +1
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> SKIP   (fi-cfl-s)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-n2820) fdo#101705
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> SKIP   (fi-cfl-s)

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215
fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:456s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:441s
fi-blb-e6850 total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  
time:359s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:546s
fi-bwr-2160  total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 
time:255s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:526s
fi-byt-j1900 total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  
time:518s
fi-byt-n2820 total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:521s
fi-cfl-s total:289  pass:248  dwarn:4   dfail:0   fail:0   skip:37  
time:447s
fi-elk-e7500 total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  
time:439s
fi-glk-2atotal:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:614s
fi-hsw-4770  total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:445s
fi-hsw-4770r total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:425s
fi-ilk-650   total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:430s
fi-ivb-3520m total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:499s
fi-ivb-3770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:477s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:515s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:609s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:604s
fi-pnv-d510  total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:532s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:478s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:537s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:515s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:446s
fi-skl-x1585ltotal:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:490s
fi-snb-2520m total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  
time:564s
fi-snb-2600  total:289  pass:247  dwarn:0   dfail:0   fail:3   skip:39  
time:417s

0640ea73be26f37458cfff3943bed7055536da84 drm-tip: 2017y-09m-06d-06h-41m-15s UTC 
integration manifest
900ae341b031 drm/i915: Move device_info.has_snoop into the static tables

== Logs ==

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

[Intel-gfx] [PATCH v2] drm/i915: Re-enable GTT following a device reset

[Chris Wilson]

Ville Syrjälä spotted that PGETBL_CTL was losing its enable bit upon a
reset. That was causing the display to show garbage on his 945gm. On my
i915gm the effect was far more severe; re-enabling the display following
the reset without PGETBL_CTL being enabled lead to an immediate hard
hang.

We do have a routine to re-enable PGETBL_CTL which is applicable to
gen2-4, although on gen4 it is documented that a graphics reset doesn't
alter the register (no such wording is given for gen3) and should be safe
to call to punch back in the enable bit. However, that leaves the question
of whether we need to completely re-initialise the register and the
rest of the GSM. For g33/pnv/gen4+, where we do have a configurable
page table, its contents do seem to be kept, and so we should be able to
recover without having to reinitialise the GTT from scratch (as prior to
g33, that register is configured by the BIOS and we leave alone except
for the enable bit).

This appears to have been broken by commit 5fbd0418eef2 ("drm/i915:
Re-enable GGTT earlier during resume on pre-gen6 platforms"), which
moved the intel_enable_gtt() from i915_gem_init_hw() (also used by
reset) to add it earlier during hw init and resume, missing the reset
path.

v2: Find the culprit, rearrange ggtt_enable to be before gem_init_hw to
match init/resume

Reported-by: Ville Syrjälä 
Fixes: 5fbd0418eef2 ("drm/i915: Re-enable GGTT earlier during resume on 
pre-gen6 platforms")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101852
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drv.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f10a078e3a55..ff70fc45ba7c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1892,9 +1892,15 @@ void i915_reset(struct drm_i915_private *i915, unsigned 
int flags)
 
/*
 * Everything depends on having the GTT running, so we need to start
-* there.  Fortunately we don't need to do this unless we reset the
-* chip at a PCI level.
-*
+* there.
+*/
+   ret = i915_ggtt_enable_hw(i915);
+   if (ret) {
+   DRM_ERROR("Failed to re-enable GGTT following reset %d\n", ret);
+   goto error;
+   }
+
+   /*
 * Next we need to restore the context, but we don't use those
 * yet either...
 *
-- 
2.14.1

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

[Intel-gfx] [CI] drm/i915: Move device_info.has_snoop into the static tables

[Chris Wilson]

Currently we define any !llc machine as using snoop instead. However,
some platforms run into trouble using snoop that we would like to
disable, and to do so easily we want to be able to use the static
device_info tables.

v2: Leave the old snoop = !llc as a warning for the time being to check
that all stanzas are filled as either llc or snoop.

Signed-off-by: Chris Wilson 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_pci.c  | 7 +++
 drivers/gpu/drm/i915/intel_device_info.c | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index d05aab60c1fb..881b5d6708aa 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -63,6 +63,7 @@
.hws_needs_physical = 1, \
.unfenced_needs_alignment = 1, \
.ring_mask = RENDER_RING, \
+   .has_snoop = true, \
GEN_DEFAULT_PIPEOFFSETS, \
CURSOR_OFFSETS
 
@@ -95,6 +96,7 @@ static const struct intel_device_info intel_i865g_info 
__initconst = {
.gen = 3, .num_pipes = 2, \
.has_gmch_display = 1, \
.ring_mask = RENDER_RING, \
+   .has_snoop = true, \
GEN_DEFAULT_PIPEOFFSETS, \
CURSOR_OFFSETS
 
@@ -157,6 +159,7 @@ static const struct intel_device_info intel_pineview_info 
__initconst = {
.has_hotplug = 1, \
.has_gmch_display = 1, \
.ring_mask = RENDER_RING, \
+   .has_snoop = true, \
GEN_DEFAULT_PIPEOFFSETS, \
CURSOR_OFFSETS
 
@@ -197,6 +200,7 @@ static const struct intel_device_info intel_gm45_info 
__initconst = {
.has_hotplug = 1, \
.has_gmbus_irq = 1, \
.ring_mask = RENDER_RING | BSD_RING, \
+   .has_snoop = true, \
GEN_DEFAULT_PIPEOFFSETS, \
CURSOR_OFFSETS
 
@@ -320,6 +324,7 @@ static const struct intel_device_info intel_valleyview_info 
__initconst = {
.has_hotplug = 1,
.has_aliasing_ppgtt = 1,
.has_full_ppgtt = 1,
+   .has_snoop = true,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_DEFAULT_PIPEOFFSETS,
@@ -411,6 +416,7 @@ static const struct intel_device_info intel_cherryview_info 
__initconst = {
.has_aliasing_ppgtt = 1,
.has_full_ppgtt = 1,
.has_reset_engine = 1,
+   .has_snoop = true,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
@@ -473,6 +479,7 @@ static const struct intel_device_info 
intel_skylake_gt4_info __initconst = {
.has_full_ppgtt = 1, \
.has_full_48bit_ppgtt = 1, \
.has_reset_engine = 1, \
+   .has_snoop = true, \
GEN_DEFAULT_PIPEOFFSETS, \
IVB_CURSOR_OFFSETS, \
BDW_COLORS
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 5f91ddc78c7a..b17f7045c8f8 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -412,7 +412,7 @@ void intel_device_info_runtime_init(struct drm_i915_private 
*dev_priv)
else if (INTEL_INFO(dev_priv)->gen >= 9)
gen9_sseu_info_init(dev_priv);
 
-   info->has_snoop = !info->has_llc;
+   WARN_ON(info->has_snoop != !info->has_llc);
 
DRM_DEBUG_DRIVER("slice mask: %04x\n", info->sseu.slice_mask);
DRM_DEBUG_DRIVER("slice total: %u\n", hweight8(info->sseu.slice_mask));
-- 
2.14.1

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

Re: [Intel-gfx] [PATCH v2 5/5] tools/testing/scatterlist: Test new __sg_alloc_table_from_pages

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-09-05 11:24:03)
> From: Tvrtko Ursulin 
> 
> Exercise the new __sg_alloc_table_from_pages API (and through
> it also the old sg_alloc_table_from_pages), checking that the
> created table has the expected number of segments depending on
> the sequence of input pages and other conditions.
> 
> v2: Move to data driven for readability.
> 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Chris Wilson 
> Cc: linux-ker...@vger.kernel.org
> ---
>  tools/testing/scatterlist/Makefile   |  30 +
>  tools/testing/scatterlist/linux/mm.h | 125 
> +++
>  tools/testing/scatterlist/main.c |  74 +
>  3 files changed, 229 insertions(+)
>  create mode 100644 tools/testing/scatterlist/Makefile
>  create mode 100644 tools/testing/scatterlist/linux/mm.h
>  create mode 100644 tools/testing/scatterlist/main.c
> 
> diff --git a/tools/testing/scatterlist/Makefile 
> b/tools/testing/scatterlist/Makefile
> new file mode 100644
> index ..0867e0ef32d6
> --- /dev/null
> +++ b/tools/testing/scatterlist/Makefile
> @@ -0,0 +1,30 @@
> +CFLAGS += -I. -I../../include -g -O2 -Wall -fsanitize=address
> +LDFLAGS += -fsanitize=address
> +TARGETS = main
> +OFILES = main.o scatterlist.o
> +
> +ifeq ($(BUILD), 32)
> +CFLAGS += -m32
> +LDFLAGS += -m32
> +endif

Hmm, are there no HOST_CFLAGS? No. I wonder how menuconfig/xconfig get
compiled.

HOSTCC, HOSTCFLAGS.

hostprogs-y := main
always := $(hostprogs-y)

But nothing else seems to use HOSTCC in testing/selftests

> +targets: include $(TARGETS)
> +
> +main: $(OFILES)
> +
> +clean:
> +   $(RM) $(TARGETS) $(OFILES) scatterlist.c linux/scatterlist.h 
> linux/highmem.h linux/kmemleak.h asm/io.h
> +   @rmdir asm
> +
> +scatterlist.c: ../../../lib/scatterlist.c
> +   @sed -e 's/^static //' -e 's/__always_inline //' -e 's/inline //' < 
> $< > $@

I think I would have used

#define __always_inline inline
#include "../../../lib/scatterlist.c"

> diff --git a/tools/testing/scatterlist/main.c 
> b/tools/testing/scatterlist/main.c
> new file mode 100644
> index ..8ca5c8703eb7
> --- /dev/null
> +++ b/tools/testing/scatterlist/main.c
> @@ -0,0 +1,74 @@
> +#include 
> +#include 
> +
> +#include 
> +
> +#define MAX_PAGES (64)
> +
> +static void set_pages(struct page **pages, const unsigned *array, unsigned 
> num)
> +{
> +   unsigned int i;
> +
> +   assert(num < MAX_PAGES);
> +   for (i = 0; i < num; i++)
> +   pages[i] = (struct page *)(unsigned long)
> +  ((1 + array[i]) * PAGE_SIZE);

pfn_to_page(PFN_BIAS + array[i]) ? Ah, that relies on headers. Ok.

> +}
> +
> +#define pfn(...) (unsigned []){ __VA_ARGS__ }
> +
> +int main(void)
> +{
> +   const unsigned int sgmax = SCATTERLIST_MAX_SEGMENT;
> +   struct test {
> +   int alloc_ret;
> +   unsigned num_pages;
> +   unsigned *pfn;
> +   unsigned size;
> +   unsigned int max_seg;
> +   unsigned int expected_segments;
> +   } *test, tests[] = {
> +   { -EINVAL, 1, pfn(0), PAGE_SIZE, PAGE_SIZE + 1, 1 },
> +   { -EINVAL, 1, pfn(0), PAGE_SIZE, 0, 1 },
> +   { -EINVAL, 1, pfn(0), PAGE_SIZE, sgmax + 1, 1 },
> +   { 0, 1, pfn(0), PAGE_SIZE, sgmax, 1 },
> +   { 0, 1, pfn(0), 1, sgmax, 1 },
> +   { 0, 2, pfn(0, 1), 2 * PAGE_SIZE, sgmax, 1 },
> +   { 0, 3, pfn(0, 1, 3), 3 * PAGE_SIZE, sgmax, 2 },
> +   { 0, 4, pfn(0, 1, 3, 4), 4 * PAGE_SIZE, sgmax, 2 },
> +   { 0, 5, pfn(0, 1, 3, 4, 5), 5 * PAGE_SIZE, sgmax, 2 },
> +   { 0, 5, pfn(0, 1, 3, 4, 6), 5 * PAGE_SIZE, sgmax, 3 },
> +   { 0, 5, pfn(0, 1, 2, 3, 4), 5 * PAGE_SIZE, sgmax, 1 },
> +   { 0, 5, pfn(0, 1, 2, 3, 4), 5 * PAGE_SIZE, 2 * PAGE_SIZE, 3 },
> +   { 0, 6, pfn(0, 1, 2, 3, 4, 5), 6 * PAGE_SIZE, 2 * PAGE_SIZE, 
> 3 },
> +   { 0, 6, pfn(0, 2, 3, 4, 5, 6), 6 * PAGE_SIZE, 2 * PAGE_SIZE, 
> 4 },
> +   { 0, 6, pfn(0, 1, 3, 4, 5, 6), 6 * PAGE_SIZE, 2 * PAGE_SIZE, 
> 3 },

All ascending. Interesting challenge for 3,2,1,0; it can be coalesced,
we just don't. I wonder if we are missing some like that. But for the
moment, 0, 2, 1, would be a good addition to the above set.

Is there any value in checking overflows in this interface?

Lgtm, throw in a couple of inverted positions,
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/dsi: Silence atomic update failure with DSI panel

[Mika Kahola]

On Tue, 2017-09-05 at 18:11 +0200, Daniel Vetter wrote:
> On Tue, Sep 05, 2017 at 04:35:04PM +0300, Mika Kahola wrote:
> > 
> > It appears that we cannot trust scanline counters when MIPI/DSI
> > display is
> > connected. In CI system this appears as flickering errors that
> > randomly
> > appear in test cases. To avoid this flickering, let's just silence
> > atomic
> > update failure in case with DSI panel.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102403
> > Signed-off-by: Mika Kahola 
> This just changes a loud atomic failure to a silent atomic failure.
> What
> we instead need to do is actually fix the bug, not hide it.
> 
BSpec has a notion that (PIPE_SCANLINE) that is "Not supported with
MIPI DSI."

That's why I thought it might be ok to silence the error as the
computation that we try to accomplish wouldn't work anyway. Maybe this
way we could remove DSI from being blackllisted.

> This means DSI is atm blacklisted almost entirely, but well it's
> broken,
> so no harm in that.
> 
> Please no polishing of just results in CI, it needs to give us honest
> results.
> -Daniel
> > 
> > ---
> >  drivers/gpu/drm/i915/intel_sprite.c | 32 +--
> > -
> >  1 file changed, 17 insertions(+), 15 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index b0d6e3e..8511072 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -205,23 +205,25 @@ void intel_pipe_update_end(struct
> > intel_crtc_state *new_crtc_state)
> >     if (intel_vgpu_active(dev_priv))
> >     return;
> >  
> > -   if (crtc->debug.start_vbl_count &&
> > -   crtc->debug.start_vbl_count != end_vbl_count) {
> > -   DRM_ERROR("Atomic update failure on pipe %c
> > (start=%u end=%u) time %lld us, min %d, max %d, scanline start %d,
> > end %d\n",
> > -     pipe_name(pipe), crtc-
> > >debug.start_vbl_count,
> > -     end_vbl_count,
> > -     ktime_us_delta(end_vbl_time, crtc-
> > >debug.start_vbl_time),
> > -     crtc->debug.min_vbl, crtc-
> > >debug.max_vbl,
> > -     crtc->debug.scanline_start,
> > scanline_end);
> > -   }
> > +   if (!intel_crtc_has_type(new_crtc_state,
> > INTEL_OUTPUT_DSI)) {
> > +   if (crtc->debug.start_vbl_count &&
> > +   crtc->debug.start_vbl_count != end_vbl_count)
> > {
> > +   DRM_ERROR("Atomic update failure on pipe
> > %c (start=%u end=%u) time %lld us, min %d, max %d, scanline start
> > %d, end %d\n",
> > +     pipe_name(pipe), crtc-
> > >debug.start_vbl_count,
> > +     end_vbl_count,
> > +     ktime_us_delta(end_vbl_time,
> > crtc->debug.start_vbl_time),
> > +     crtc->debug.min_vbl, crtc-
> > >debug.max_vbl,
> > +     crtc->debug.scanline_start,
> > scanline_end);
> > +   }
> >  #ifdef CONFIG_DRM_I915_DEBUG_VBLANK_EVADE
> > -   else if (ktime_us_delta(end_vbl_time, crtc-
> > >debug.start_vbl_time) >
> > -    VBLANK_EVASION_TIME_US)
> > -   DRM_WARN("Atomic update on pipe (%c) took %lld us,
> > max time under evasion is %u us\n",
> > -    pipe_name(pipe),
> > -    ktime_us_delta(end_vbl_time, crtc-
> > >debug.start_vbl_time),
> > -    VBLANK_EVASION_TIME_US);
> > +   else if (ktime_us_delta(end_vbl_time, crtc-
> > >debug.start_vbl_time) >
> > +    VBLANK_EVASION_TIME_US)
> > +   DRM_WARN("Atomic update on pipe (%c) took
> > %lld us, max time under evasion is %u us\n",
> > +    pipe_name(pipe),
> > +    ktime_us_delta(end_vbl_time,
> > crtc->debug.start_vbl_time),
> > +    VBLANK_EVASION_TIME_US);
> >  #endif
> > +   }
> >  }
> >  
> >  static void
> > -- 
> > 2.7.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
-- 
Mika Kahola - Intel OTC

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

[Intel-gfx] ✓ Fi.CI.IGT: success for RFC: meson build system support (rev6)

[Patchwork]

== Series Details ==

Series: RFC: meson build system support (rev6)
URL   : https://patchwork.freedesktop.org/series/29823/
State : success

== Summary ==

Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-C:
pass   -> DMESG-WARN (shard-hsw) fdo#102249
Test perf:
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252 +1
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912

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

shard-hswtotal:2265 pass:1231 dwarn:1   dfail:0   fail:17  skip:1016 
time:9641s

== Logs ==

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