[Intel-gfx] [PATCH] Forward Error Correction is supported on DP 1.4. This patch adds corresponding DPCD register definitions.

[Anusha Srivatsa]

v2: Add dri-devel mailing list to the CC list(Jani)

v3: Change names, add missing masks (Manasi)

v4: Add missing shifts to mask (Manasi)

v5: Arrange the definitions in ascending order
of the address (Jani)

Cc: dri-de...@lists.freedesktop.org
Cc: Ville Syrjala 
Cc: Jani Nikula 
Cc: Manasi Navare 
Signed-off-by: Anusha Srivatsa 
---
 include/drm/drm_dp_helper.h | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c239e6e..a19d6fb 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -329,6 +329,13 @@
 # define DP_DS_12BPC   2
 # define DP_DS_16BPC   3
 
+/* DP Forward error Correction Registers */
+#define DP_FEC_CAPABILITY  (0x090)
+# define DP_FEC_CAPABLE(1 << 0)
+# define DP_FEC_UNCORR_BLK_ERROR_COUNT_CAP  (1 << 1)
+# define DP_FEC_CORR_BLK_ERROR_COUNT_CAP(1 << 2)
+# define DP_FEC_BIT_ERROR_COUNT_CAP(1 << 3)
+
 /* link configuration */
 #defineDP_LINK_BW_SET  0x100
 # define DP_LINK_RATE_TABLE0x00/* eDP 1.4 */
@@ -445,6 +452,18 @@
 #define DP_UPSTREAM_DEVICE_DP_PWR_NEED 0x118   /* 1.2 */
 # define DP_PWR_NOT_NEEDED (1 << 0)
 
+#define DP_FEC_CONFIGURATION   0x120
+# define DP_FEC_READY  (1 << 0)
+# define DP_FEC_ERR_COUNT_DIS  (0 << 1)
+# define DP_FEC_UNCORR_BLK_ERROR_COUNT (1 << 1)
+# define DP_FEC_CORR_BLK_ERROR_COUNT   (2 << 1)
+# define DP_FEC_BIT_ERROR_COUNT(3 << 1)
+# define DP_FEC_ERR_COUNT_SEL_MASK (0xff << 4)
+# define DP_FEC_LANE_0_SELECT  (0 << 4)
+# define DP_FEC_LANE_1_SELECT  (1 << 4)
+# define DP_FEC_LANE_2_SELECT  (2 << 4)
+# define DP_FEC_LANE_3_SELECT  (3 << 4)
+
 #define DP_AUX_FRAME_SYNC_VALUE0x15c   /* eDP 1.4 */
 # define DP_AUX_FRAME_SYNC_VALID   (1 << 0)
 
@@ -620,6 +639,17 @@
 #define DP_TEST_SINK   0x270
 # define DP_TEST_SINK_START(1 << 0)
 
+#define DP_FEC_STATUS  0x280
+# define DP_FEC_DECODE_EN_DETECTED (1 << 0)
+# define DP_FEC_DECODE_DIS_DETECTED(1 << 1)
+
+#define DP_FEC_ERROR_COUNT_LSB 0x0281
+
+#define DP_FEC_ERROR_COUNT_MSB 0x0282
+# define DP_FEC_ERROR_COUNT_MASK   0x7F
+# define DP_FEC_ERR_COUNT_SHIFT8
+# define DP_FEC_ERR_COUNT_VALID(1 << 7)
+
 #define DP_PAYLOAD_TABLE_UPDATE_STATUS  0x2c0   /* 1.2 MST */
 # define DP_PAYLOAD_TABLE_UPDATED   (1 << 0)
 # define DP_PAYLOAD_ACT_HANDLED (1 << 1)
-- 
2.7.4

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

[Intel-gfx] [PATCH v2] drm: Allow determining if current task is output poll worker

[Lukas Wunner]

Introduce a helper to determine if the current task is an output poll
worker.

This allows us to fix a long-standing deadlock in several DRM drivers
wherein the ->runtime_suspend callback waits for the output poll worker
to finish and the worker in turn calls a ->detect callback which waits
for runtime suspend to finish.  The ->detect callback is invoked from
multiple call sites and waiting for runtime suspend to finish is the
correct thing to do except if it's executing in the context of the
worker.

v2: Expand kerneldoc to specifically mention deadlock between
output poll worker and autosuspend worker as use case. (Lyude)

Cc: Dave Airlie 
Cc: Ben Skeggs 
Cc: Alex Deucher 
Reviewed-by: Lyude Paul 
Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/drm_probe_helper.c | 20 
 include/drm/drm_crtc_helper.h  |  1 +
 2 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 6dc2dde5b672..7a6b2dc08913 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -654,6 +654,26 @@ static void output_poll_execute(struct work_struct *work)
schedule_delayed_work(delayed_work, DRM_OUTPUT_POLL_PERIOD);
 }
 
+/**
+ * drm_kms_helper_is_poll_worker - is %current task an output poll worker?
+ *
+ * Determine if %current task is an output poll worker.  This can be used
+ * to select distinct code paths for output polling versus other contexts.
+ *
+ * One use case is to avoid a deadlock between the output poll worker and
+ * the autosuspend worker wherein the latter waits for polling to finish
+ * upon calling drm_kms_helper_poll_disable(), while the former waits for
+ * runtime suspend to finish upon calling pm_runtime_get_sync() in a
+ * connector ->detect hook.
+ */
+bool drm_kms_helper_is_poll_worker(void)
+{
+   struct work_struct *work = current_work();
+
+   return work && work->func == output_poll_execute;
+}
+EXPORT_SYMBOL(drm_kms_helper_is_poll_worker);
+
 /**
  * drm_kms_helper_poll_disable - disable output polling
  * @dev: drm_device
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index 76e237bd989b..6914633037a5 100644
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h
@@ -77,5 +77,6 @@ void drm_kms_helper_hotplug_event(struct drm_device *dev);
 
 void drm_kms_helper_poll_disable(struct drm_device *dev);
 void drm_kms_helper_poll_enable(struct drm_device *dev);
+bool drm_kms_helper_is_poll_worker(void);
 
 #endif
-- 
2.15.1

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

Re: [Intel-gfx] [PATCH 1/5] drm/i915: add and enable DP AUX CH mutex

[Jani Nikula]

On Tue, 13 Feb 2018, José Roberto de Souza  wrote:
> When PSR/PSR2 is enabled hardware can do AUX transactions by it self, so
> lets use the mutex register that is available in gen9+ to avoid concurrent
> access by hardware and driver.
>
> Reference: 
> https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol12-display.pdf
> Page 198 - AUX programming sequence
>
> As gen < 9 don't have the mutex PSR needs to be disabled, that is why the
> 'else TODO' was added. This is also backed by spec:

And proves the patches weren't compiled not to mention tested. :(

BR,
Jani.



> "DDI A AUX channel transactions must not be sent while SRD is enabled.
> SRD must be completely disabled before a DDI A AUX channel transaction can
> be sent." BSpec: 7530
>
> Cc: Rodrigo Vivi 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  9 
>  drivers/gpu/drm/i915/intel_dp.c  | 48 
> 
>  drivers/gpu/drm/i915/intel_drv.h |  1 +
>  drivers/gpu/drm/i915/intel_psr.c |  6 +
>  4 files changed, 64 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index f6afa5e5e7c1..5d7736117cb9 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5318,6 +5318,7 @@ enum {
>  #define _DPA_AUX_CH_DATA3(dev_priv->info.display_mmio_offset + 0x6401c)
>  #define _DPA_AUX_CH_DATA4(dev_priv->info.display_mmio_offset + 0x64020)
>  #define _DPA_AUX_CH_DATA5(dev_priv->info.display_mmio_offset + 0x64024)
> +#define _DPA_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6402C)
>  
>  #define _DPB_AUX_CH_CTL  (dev_priv->info.display_mmio_offset + 
> 0x64110)
>  #define _DPB_AUX_CH_DATA1(dev_priv->info.display_mmio_offset + 0x64114)
> @@ -5325,6 +5326,7 @@ enum {
>  #define _DPB_AUX_CH_DATA3(dev_priv->info.display_mmio_offset + 0x6411c)
>  #define _DPB_AUX_CH_DATA4(dev_priv->info.display_mmio_offset + 0x64120)
>  #define _DPB_AUX_CH_DATA5(dev_priv->info.display_mmio_offset + 0x64124)
> +#define _DPB_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6412C)
>  
>  #define _DPC_AUX_CH_CTL  (dev_priv->info.display_mmio_offset + 
> 0x64210)
>  #define _DPC_AUX_CH_DATA1(dev_priv->info.display_mmio_offset + 0x64214)
> @@ -5332,6 +5334,7 @@ enum {
>  #define _DPC_AUX_CH_DATA3(dev_priv->info.display_mmio_offset + 0x6421c)
>  #define _DPC_AUX_CH_DATA4(dev_priv->info.display_mmio_offset + 0x64220)
>  #define _DPC_AUX_CH_DATA5(dev_priv->info.display_mmio_offset + 0x64224)
> +#define _DPC_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6422C)
>  
>  #define _DPD_AUX_CH_CTL  (dev_priv->info.display_mmio_offset + 
> 0x64310)
>  #define _DPD_AUX_CH_DATA1(dev_priv->info.display_mmio_offset + 0x64314)
> @@ -5339,6 +5342,7 @@ enum {
>  #define _DPD_AUX_CH_DATA3(dev_priv->info.display_mmio_offset + 0x6431c)
>  #define _DPD_AUX_CH_DATA4(dev_priv->info.display_mmio_offset + 0x64320)
>  #define _DPD_AUX_CH_DATA5(dev_priv->info.display_mmio_offset + 0x64324)
> +#define _DPD_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6432C)
>  
>  #define _DPF_AUX_CH_CTL  (dev_priv->info.display_mmio_offset + 
> 0x64510)
>  #define _DPF_AUX_CH_DATA1(dev_priv->info.display_mmio_offset + 0x64514)
> @@ -5346,9 +5350,11 @@ enum {
>  #define _DPF_AUX_CH_DATA3(dev_priv->info.display_mmio_offset + 0x6451c)
>  #define _DPF_AUX_CH_DATA4(dev_priv->info.display_mmio_offset + 0x64520)
>  #define _DPF_AUX_CH_DATA5(dev_priv->info.display_mmio_offset + 0x64524)
> +#define _DPF_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6452C)
>  
>  #define DP_AUX_CH_CTL(port)  _MMIO_PORT(port, _DPA_AUX_CH_CTL, 
> _DPB_AUX_CH_CTL)
>  #define DP_AUX_CH_DATA(port, i)  _MMIO(_PORT(port, _DPA_AUX_CH_DATA1, 
> _DPB_AUX_CH_DATA1) + (i) * 4) /* 5 registers */
> +#define DP_AUX_CH_MUTEX(port)_MMIO_PORT(port, _DPA_AUX_CH_MUTEX, 
> _DPB_AUX_CH_MUTEX)
>  
>  #define   DP_AUX_CH_CTL_SEND_BUSY(1 << 31)
>  #define   DP_AUX_CH_CTL_DONE (1 << 30)
> @@ -5378,6 +5384,9 @@ enum {
>  #define   DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(c) (((c) - 1) << 5)
>  #define   DP_AUX_CH_CTL_SYNC_PULSE_SKL(c)   ((c) - 1)
>  
> +#define   DP_AUX_CH_MUTEX_ENABLE (1 << 31)
> +#define   DP_AUX_CH_MUTEX_STATUS (1 << 30)
> +
>  /*
>   * Computing GMCH M and N values for the Display Port link
>   *
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index f20b25f98e5a..bd5f1bb730ff 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1081,6 +1081,28 @@ static uint32_t intel_dp_get_aux_send_ctl(struct 
> intel_dp *intel_dp,
>   aux_clock_divider);
>  }
>  
> +static bool intel_dp_aux_get(struct 

[Intel-gfx] ✗ Fi.CI.BAT: failure for Adding NV12 support (rev10)

[Patchwork]

== Series Details ==

Series: Adding NV12 support (rev10)
URL   : https://patchwork.freedesktop.org/series/28103/
State : failure

== Summary ==

Series 28103v10 Adding NV12 support
https://patchwork.freedesktop.org/api/1.0/series/28103/revisions/10/mbox/

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-cnl-y3) fdo#105058
Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> FAIL   (fi-ilk-650) fdo#104008
pass   -> FAIL   (fi-byt-j1900)

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#105058 https://bugs.freedesktop.org/show_bug.cgi?id=105058
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008

fi-bdw-5557u total:288  pass:265  dwarn:0   dfail:0   fail:2   skip:21  
time:440s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:427s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:378s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:505s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:290s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:487s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:493s
fi-byt-j1900 total:288  pass:252  dwarn:0   dfail:0   fail:1   skip:35  
time:475s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:460s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:570s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:581s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:415s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:286s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:518s
fi-hsw-4770  total:288  pass:259  dwarn:0   dfail:0   fail:2   skip:27  
time:412s
fi-ilk-650   total:288  pass:227  dwarn:0   dfail:0   fail:1   skip:60  
time:415s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:453s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:415s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:458s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:499s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:588s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:430s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:509s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:530s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:487s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:488s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:415s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:429s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:403s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:179  dwarn:1   dfail:4   fail:0   skip:104 
time:770s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:455s

e404d341ffdd255f9a7d8e4461170694edcb3e25 drm-tip: 2018y-02m-14d-01h-12m-17s UTC 
integration manifest
bac1533d3799 drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg
202c444f5119 drm/i915: Add NV12 support to intel_framebuffer_init
f4d627003336 drm/i915: Add NV12 as supported format for sprite plane
8db281883112 drm/i915: Add NV12 as supported format for primary plane
2874a9ba97dd drm/i915: Upscale scaler max scale for NV12
7f1c808ee544 drm/i915: Update format_is_yuv() to include NV12
d4b570fb0893 drm/i915: Set scaler mode for NV12
36bfc5f50a6e drm/i915/skl: split skl_compute_ddb function
06783624255b drm/i915/skl+: nv12 workaround disable WM level 1-7
e33de151b777 drm/i915/skl+: make sure higher latency level has higher wm value
b9bab8ca6a9b drm/i915/skl+: pass skl_wm_level struct to wm compute func
397ec133feb7 drm/i915/skl+: NV12 related changes for WM
08d914614bee drm/i915/skl+: support verification of DDB HW state for NV12
503a7a63f12b drm/i915/skl+: add NV12 in skl_format_to_fourcc
7f00f60fcd67 drm/i915/skl+: refactor WM calculation for NV12
a232d90783ac drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values

== Logs ==

For more details see: 

[Intel-gfx] [PULL] git-fixes for 4.16-rc2

[Zhenyu Wang]

Hi, here's current gvt-fixes pull for 4.16-rc2, as it is close for
chinese new year, team would take one week off at least, so like to
send this out before vacation. This has one to fix GTT mmio 8b access
from guest and two simple ones for mmio switch and typo fix. And sorry
that patchwork link is still not there yet, using dim to pull should
be ok but might need direct push to skip dim push check for now.

thanks
--
The following changes since commit 4b8b41d15d9db54703958fbd2928a2fd319563f6:

  drm/i915/pmu: Fix building without CONFIG_PM (2018-02-13 16:56:06 -0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-fixes-2018-02-14

for you to fetch changes up to 3cc7644e4af179e79153b1fd60f9dd937ee32684:

  drm/i915/gvt: fix one typo of render_mmio trace (2018-02-14 10:35:00 +0800)


gvt-fixes-2018-02-14

- gtt mmio 8b access fix (Tina)
- one KBL required mmio reg for switch (Weinan)
- one trace log typo fix (Weinan)


Tina Zhang (1):
  drm/i915/gvt: Support BAR0 8-byte reads/writes

Weinan Li (2):
  drm/i915/gvt: add 0xe4f0 into gen9 render list
  drm/i915/gvt: fix one typo of render_mmio trace

 drivers/gpu/drm/i915/gvt/kvmgt.c| 51 +++--
 drivers/gpu/drm/i915/gvt/mmio_context.c |  1 +
 drivers/gpu/drm/i915/gvt/trace.h|  2 +-
 3 files changed, 51 insertions(+), 3 deletions(-)

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] Revert "ALSA: hda: Make use of core codec functions to sync power state"

[Patchwork]

== Series Details ==

Series: series starting with [1/3] Revert "ALSA: hda: Make use of core codec 
functions to sync power state"
URL   : https://patchwork.freedesktop.org/series/38212/
State : success

== Summary ==

Test pm_rpm:
Subgroup gem-mmap-cpu:
fail   -> PASS   (shard-hsw) fdo#105069 +38
Subgroup system-suspend-execbuf:
fail   -> PASS   (shard-hsw) fdo#103375 +1
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047
Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
skip   -> PASS   (shard-snb) fdo#102365
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-pri-shrfb-draw-blt:
dmesg-fail -> PASS   (shard-apl) fdo#101623
Subgroup fbc-1p-shrfb-fliptrack:
fail   -> PASS   (shard-apl) fdo#103167
Test pm_lpsp:
Subgroup screens-disabled:
fail   -> PASS   (shard-hsw) fdo#104941
Test perf_pmu:
Subgroup rc6-runtime-pm:
skip   -> PASS   (shard-hsw) fdo#105010 +1

fdo#105069 https://bugs.freedesktop.org/show_bug.cgi?id=105069
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941
fdo#105010 https://bugs.freedesktop.org/show_bug.cgi?id=105010

shard-apltotal:3344 pass:1729 dwarn:1   dfail:0   fail:21  skip:1591 
time:13896s
shard-hswtotal:3427 pass:1759 dwarn:1   dfail:0   fail:10  skip:1656 
time:14711s
shard-snbtotal:3427 pass:1349 dwarn:1   dfail:0   fail:10  skip:2067 
time:7678s
Blacklisted hosts:
shard-kbltotal:3370 pass:1849 dwarn:27  dfail:0   fail:20  skip:1473 
time:10926s

== Logs ==

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

Re: [Intel-gfx] [PATCH 00/16] Adding NV12 support

[Kristian Høgsberg]

On Tue, Feb 13, 2018 at 8:59 PM Vidya Srinivas 
wrote:

> This patch series is adding NV12 support for Broxton display after
rebasing on
> latest drm-tip.
> Initial series of the patches can be found here:
> https://lists.freedesktop.org/archives/intel-gfx/2015-May/066786.html

I still don't see support for advertising modifiers in this patch set. The
series should handle NV12 in the supported_modifiers function to indicate
which tiling and/or compression modifiers are supported for NV12
framebuffers.

Kristian




> Previous revision history:
> The first version of patches were reviewed when floated by Chandra in 2015
> but currently there was a design change with respect to
> - the way fb offset is handled
> - the way rotation is handled
> Current NV12 patch series has been ported as per the
> current changes on drm-tip

> Review comments from Ville (12th June 2017) have been addressed Review
> comments from Clinton A Taylor (7th July 2017) have been addressed

> Review comments from Clinton A Taylor (10th July 2017)
>  have been addressed. Had missed out tested-by/reviewed-by in the
patches.

>  Fixed that error in this series.
>  Review comments from Ville (11th July 2017) addressed.
>  Review comments from Paauwe, Bob (29th July 2017) addressed.

> Update from rev 28 Aug 2017
>  Rebased the series.
>  Tested with IGT for rotation, sprite and tiling combinations.
>  IGT Links:
>  https://patchwork.kernel.org/patch/9995943/
>  https://patchwork.kernel.org/patch/9995945/
>  Review comments by Maarten are addressed in this series.
>  NV12 enabled for Gen10.
>  Review comments from Shashank Sharma are addressed.

> Update from last rev:
>  IGT debug_fs test failure fixed.

> Chandra Konduru (6):
>drm/i915: Set scaler mode for NV12
>drm/i915: Update format_is_yuv() to include NV12
>drm/i915: Upscale scaler max scale for NV12
>drm/i915: Add NV12 as supported format for primary plane
>drm/i915: Add NV12 as supported format for sprite plane
>drm/i915: Add NV12 support to intel_framebuffer_init

> Mahesh Kumar (9):
>drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values
>drm/i915/skl+: refactor WM calculation for NV12
>drm/i915/skl+: add NV12 in skl_format_to_fourcc
>drm/i915/skl+: support verification of DDB HW state for NV12
>drm/i915/skl+: NV12 related changes for WM
>drm/i915/skl+: pass skl_wm_level struct to wm compute func
>drm/i915/skl+: make sure higher latency level has higher wm value
>drm/i915/skl+: nv12 workaround disable WM level 1-7
>drm/i915/skl: split skl_compute_ddb function

> Vidya Srinivas (1):
>drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg

>   drivers/gpu/drm/i915/i915_drv.h  |  10 +-
>   drivers/gpu/drm/i915/i915_reg.h  |   7 +
>   drivers/gpu/drm/i915/intel_atomic.c  |   8 +-
>   drivers/gpu/drm/i915/intel_display.c |  59 -
>   drivers/gpu/drm/i915/intel_drv.h |   9 +-
>   drivers/gpu/drm/i915/intel_pm.c  | 433
++-
>   drivers/gpu/drm/i915/intel_sprite.c  |  18 +-
>   7 files changed, 357 insertions(+), 187 deletions(-)

> --
> 2.7.4

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

[Intel-gfx] [PATCH 14/16] drm/i915: Add NV12 as supported format for sprite plane

[Vidya Srinivas]

From: Chandra Konduru 

This patch adds NV12 to list of supported formats for sprite plane.

v2: Rebased (me)

v3: Review comments by Ville addressed
- Removed skl_plane_formats_with_nv12 and added
NV12 case in existing skl_plane_formats
- Added the 10bpc RGB formats

v4: Addressed review comments from Clinton A Taylor
"Why are we adding 10 bit RGB formats with the NV12 series patches?
Trying to set XR30 or AB30 results in error returned even though
the modes are advertised for the planes"
- Removed 10bit RGB formats added previously with NV12 series

v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
Addressed review comments from Clinton A Taylor
"Why are we adding 10 bit RGB formats with the NV12 series patches?
Trying to set XR30 or AB30 results in error returned even though
the modes are advertised for the planes"
- Previous version has 10bit RGB format removed from VLV formats
by mistake. Fixing that in this version.
Removed 10bit RGB formats added previously with NV12 series
for SKL.

v6: Addressed review comments by Ville
Restricting the NV12 to BXT and PIPE A and B

v7: Rebased (me)

v8: Rebased (me)
Restricting NV12 changes to BXT and KBL
Restricting NV12 changes for plane 0 (overlay)

v9: Rebased (me)

v10: Addressed review comments from Maarten.
Adding NV12 to skl_plane_formats itself.

v11: Addressed review comments from Shashank Sharma

Tested-by: Clinton Taylor 
Reviewed-by: Clinton Taylor 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_sprite.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 77a5433..4290a23 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1171,6 +1171,7 @@ static uint32_t skl_plane_formats[] = {
DRM_FORMAT_YVYU,
DRM_FORMAT_UYVY,
DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12,
 };
 
 static const uint64_t skl_plane_format_modifiers_noccs[] = {
@@ -1369,6 +1370,12 @@ intel_sprite_plane_create(struct drm_i915_private 
*dev_priv,
plane_formats = skl_plane_formats;
num_plane_formats = ARRAY_SIZE(skl_plane_formats);
 
+   if ((INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv) &&
+   (plane != 0 || pipe == PIPE_C)) ||
+   ((INTEL_GEN(dev_priv) == 10 ||
+   IS_GEMINILAKE(dev_priv)) && plane != 0))
+   num_plane_formats -= 1;
+
if (skl_plane_has_ccs(dev_priv, pipe, PLANE_SPRITE0 + plane))
modifiers = skl_plane_format_modifiers_ccs;
else
-- 
2.7.4

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

[Intel-gfx] [PATCH 15/16] drm/i915: Add NV12 support to intel_framebuffer_init

[Vidya Srinivas]

From: Chandra Konduru 

This patch adds NV12 as supported format
to intel_framebuffer_init and performs various checks.

v2:
-Fix an issue in checks added (Chandra Konduru)

v3: rebased (me)

v4: Review comments by Ville addressed
Added platform check for NV12 in intel_framebuffer_init
Removed offset checks for NV12 case

v5: Addressed review comments by Clinton A Taylor
This NV12 support only correctly works on SKL.
Plane color space conversion is different on GLK and later platforms
causing the colors to display incorrectly.
Ville's plane color space property patch series
in review will fix this issue.
- Restricted the NV12 case in intel_framebuffer_init to
SKL and BXT only.

v6: Rebased (me)

v7: Addressed review comments by Ville
Restricting the NV12 to BXT for now.

v8: Rebased (me)
Restricting the NV12 changes to BXT and KBL for now.

v9: Rebased (me)

v10: NV12 supported by all GEN >= 9.
Making this change in intel_framebuffer_init. This is
part of addressing Maarten's review comments.
Comment under v8 no longer applicable

v11: Addressed review comments from Shashank Sharma

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 | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 6f43d72..42ec089 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14063,6 +14063,14 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
goto err;
}
break;
+   case DRM_FORMAT_NV12:
+   if (INTEL_GEN(dev_priv) < 9) {
+   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
+ 
drm_get_format_name(mode_cmd->pixel_format,
+ _name));
+   goto err;
+   }
+   break;
default:
DRM_DEBUG_KMS("unsupported pixel format: %s\n",
  drm_get_format_name(mode_cmd->pixel_format, 
_name));
-- 
2.7.4

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

[Intel-gfx] [PATCH 16/16] drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg

[Vidya Srinivas]

If the fb format is YUV, enable the plane CSC mode bits
for the conversion.

Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/i915_reg.h  | 6 ++
 drivers/gpu/drm/i915/intel_display.c | 2 ++
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 10edacc..baf197b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6453,6 +6453,12 @@ enum {
 #define _PLANE_COLOR_CTL_3_A   0x703CC /* GLK+ */
 #define   PLANE_COLOR_PIPE_GAMMA_ENABLE(1 << 30)
 #define   PLANE_COLOR_PIPE_CSC_ENABLE  (1 << 23)
+#define PLANE_COLOR_CSC_MASK   (0x7 << 17)
+#define PLANE_COLOR_CSC_MODE_BYPASS(0 << 17)
+#define PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709  (1 << 17)
+#define PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709  (2 << 17)
+#define PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020(3 << 17)
+#define PLANE_COLOR_CSC_MODE_RGB709_TO_RGB2020 (4 << 17)
 #define   PLANE_COLOR_PLANE_GAMMA_DISABLE  (1 << 13)
 #define   PLANE_COLOR_ALPHA_MASK   (0x3 << 4)
 #define   PLANE_COLOR_ALPHA_DISABLE(0 << 4)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 42ec089..6c43eef 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3577,6 +3577,8 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state 
*crtc_state,
plane_color_ctl |= PLANE_COLOR_PIPE_CSC_ENABLE;
plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
plane_color_ctl |= glk_plane_color_ctl_alpha(fb->format->format);
+   if (fb && intel_format_is_yuv(fb->format->format))
+   plane_color_ctl |= PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
 
return plane_color_ctl;
 }
-- 
2.7.4

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

[Intel-gfx] [PATCH 13/16] drm/i915: Add NV12 as supported format for primary plane

[Vidya Srinivas]

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)
Modified restricting the NV12 support for both BXT and KBL.

v9: Rebased (me)

v10: Addressed review comments from Maarten.
Adding NV12 inside skl_primary_formats itself.

Tested-by: Clinton Taylor 
Reviewed-by: Clinton Taylor 
Reviewed-by: Shashank Sharma 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ac8279a..6f43d72 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -86,6 +86,7 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_YVYU,
DRM_FORMAT_UYVY,
DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12,
 };
 
 static const uint64_t skl_format_modifiers_noccs[] = {
@@ -13255,6 +13256,10 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
intel_primary_formats = skl_primary_formats;
num_formats = ARRAY_SIZE(skl_primary_formats);
 
+   if ((INTEL_GEN(dev_priv) == 9 && (pipe == PIPE_C)) &&
+   !IS_GEMINILAKE(dev_priv))
+   num_formats -= 1;
+
if (skl_plane_has_ccs(dev_priv, pipe, PLANE_PRIMARY))
modifiers = skl_format_modifiers_ccs;
else
-- 
2.7.4

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

[Intel-gfx] [PATCH 11/16] drm/i915: Update format_is_yuv() to include NV12

[Vidya Srinivas]

From: Chandra Konduru 

This patch adds NV12 to format_is_yuv() function
for sprite planes.

v2:
-Use intel_ prefix for format_is_yuv (Ville)

v3: Rebased (me)

v4: Rebased and addressed review comments from Clinton A Taylor.
"static function in intel_sprite.c is not available
to the primary plane functions".
Changed commit message - function modified for
sprite planes.

v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.

v6: Rebased (me)

v7: Rebased (me)

v8: Rebased (me)

v9: Rebased (me)

v10: Changed intel_format_is_yuv function from
static to non-static. We need to use it later from
other files for check.

Tested-by: Clinton Taylor 
Reviewed-by: Clinton Taylor 
Reviewed-by: Shashank Sharma 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_drv.h| 1 +
 drivers/gpu/drm/i915/intel_sprite.c | 8 
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 6402d6d..8d4988b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2034,6 +2034,7 @@ void skl_disable_plane(struct intel_plane *plane, struct 
intel_crtc *crtc);
 bool skl_plane_get_hw_state(struct intel_plane *plane);
 bool skl_plane_has_ccs(struct drm_i915_private *dev_priv,
   enum pipe pipe, enum plane_id plane_id);
+bool intel_format_is_yuv(uint32_t format);
 
 /* intel_tv.c */
 void intel_tv_init(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index e098e4b..2c51d8a 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -41,14 +41,14 @@
 #include 
 #include "i915_drv.h"
 
-static bool
-format_is_yuv(uint32_t format)
+bool intel_format_is_yuv(uint32_t format)
 {
switch (format) {
case DRM_FORMAT_YUYV:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_YVYU:
+   case DRM_FORMAT_NV12:
return true;
default:
return false;
@@ -352,7 +352,7 @@ chv_update_csc(struct intel_plane *plane, uint32_t format)
enum plane_id plane_id = plane->id;
 
/* Seems RGB data bypasses the CSC always */
-   if (!format_is_yuv(format))
+   if (!intel_format_is_yuv(format))
return;
 
/*
@@ -979,7 +979,7 @@ intel_check_sprite_plane(struct intel_plane *plane,
src_y = src->y1 >> 16;
src_h = drm_rect_height(src) >> 16;
 
-   if (format_is_yuv(fb->format->format)) {
+   if (intel_format_is_yuv(fb->format->format)) {
src_x &= ~1;
src_w &= ~1;
 
-- 
2.7.4

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

[Intel-gfx] [PATCH 02/16] drm/i915/skl+: refactor WM calculation for NV12

[Vidya Srinivas]

From: Mahesh Kumar 

Current code calculates DDB for planar formats in such a way that we
store DDB of plane-0 in plane 1 & vice-versa.
In order to make this clean this patch refactors WM/DDB calculation for
NV12 planar formats.

v2: Addressed review comments by Maarten

v3: Rebased and addressed review comments by Maarten

Reviewed-by: Maarten Lankhorst 
Signed-off-by: Mahesh Kumar 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/i915_drv.h  |   5 +-
 drivers/gpu/drm/i915/intel_drv.h |   1 +
 drivers/gpu/drm/i915/intel_pm.c  | 121 ---
 3 files changed, 66 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 564a364..b9914bb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1443,8 +1443,9 @@ static inline bool skl_ddb_entry_equal(const struct 
skl_ddb_entry *e1,
 }
 
 struct skl_ddb_allocation {
-   struct skl_ddb_entry plane[I915_MAX_PIPES][I915_MAX_PLANES]; /* 
packed/uv */
-   struct skl_ddb_entry y_plane[I915_MAX_PIPES][I915_MAX_PLANES];
+   /* packed/y */
+   struct skl_ddb_entry plane[I915_MAX_PIPES][I915_MAX_PLANES];
+   struct skl_ddb_entry uv_plane[I915_MAX_PIPES][I915_MAX_PLANES];
 };
 
 struct skl_ddb_values {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e74efb4..70447c6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -595,6 +595,7 @@ struct intel_pipe_wm {
 struct skl_plane_wm {
struct skl_wm_level wm[8];
struct skl_wm_level trans_wm;
+   bool is_planar;
 };
 
 struct skl_pipe_wm {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6fec748..0537567 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4012,9 +4012,9 @@ int skl_check_pipe_max_pixel_rate(struct intel_crtc 
*intel_crtc,
 static unsigned int
 skl_plane_relative_data_rate(const struct intel_crtc_state *cstate,
 const struct drm_plane_state *pstate,
-int y)
+const int plane)
 {
-   struct intel_plane *plane = to_intel_plane(pstate->plane);
+   struct intel_plane *intel_plane = to_intel_plane(pstate->plane);
struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
uint32_t data_rate;
uint32_t width = 0, height = 0;
@@ -4028,9 +4028,9 @@ skl_plane_relative_data_rate(const struct 
intel_crtc_state *cstate,
fb = pstate->fb;
format = fb->format->format;
 
-   if (plane->id == PLANE_CURSOR)
+   if (intel_plane->id == PLANE_CURSOR)
return 0;
-   if (y && format != DRM_FORMAT_NV12)
+   if (plane == 1 && format != DRM_FORMAT_NV12)
return 0;
 
/*
@@ -4041,19 +4041,14 @@ skl_plane_relative_data_rate(const struct 
intel_crtc_state *cstate,
width = drm_rect_width(_pstate->base.src) >> 16;
height = drm_rect_height(_pstate->base.src) >> 16;
 
-   /* for planar format */
-   if (format == DRM_FORMAT_NV12) {
-   if (y)  /* y-plane data rate */
-   data_rate = width * height *
-   fb->format->cpp[0];
-   else/* uv-plane data rate */
-   data_rate = (width / 2) * (height / 2) *
-   fb->format->cpp[1];
-   } else {
-   /* for packed formats */
-   data_rate = width * height * fb->format->cpp[0];
+   /* UV plane does 1/2 pixel sub-sampling */
+   if (plane == 1 && format == DRM_FORMAT_NV12) {
+   width /= 2;
+   height /= 2;
}
 
+   data_rate = width * height * fb->format->cpp[plane];
+
down_scale_amount = skl_plane_downscale_amount(cstate, intel_pstate);
 
return mul_round_up_u32_fixed16(data_rate, down_scale_amount);
@@ -4066,8 +4061,8 @@ skl_plane_relative_data_rate(const struct 
intel_crtc_state *cstate,
  */
 static unsigned int
 skl_get_total_relative_data_rate(struct intel_crtc_state *intel_cstate,
-unsigned *plane_data_rate,
-unsigned *plane_y_data_rate)
+unsigned int *plane_data_rate,
+unsigned int *uv_plane_data_rate)
 {
struct drm_crtc_state *cstate = _cstate->base;
struct drm_atomic_state *state = cstate->state;
@@ -4083,17 +4078,17 @@ skl_get_total_relative_data_rate(struct 
intel_crtc_state *intel_cstate,
enum plane_id plane_id = to_intel_plane(plane)->id;
unsigned int rate;
 
-   /* packed/uv */
+   /* packed/y */
rate = 

[Intel-gfx] [PATCH 01/16] drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values

[Vidya Srinivas]

From: Mahesh Kumar 

skl_wm_values struct contains values of pipe/plane DDB only.
so rename it for better readability of code. Similarly
skl_copy_wm_for_pipe copies DDB values.

s/skl_wm_values/skl_ddb_values
s/skl_copy_wm_for_pipe/skl_copy_ddb_for_pipe

Changes since V1:
 - also change name of skl_copy_wm_for_pipe

Reviewed-by: Maarten Lankhorst 
Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/i915_drv.h  |  4 ++--
 drivers/gpu/drm/i915/intel_drv.h |  2 +-
 drivers/gpu/drm/i915/intel_pm.c  | 14 +++---
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c06d412..564a364 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1447,7 +1447,7 @@ struct skl_ddb_allocation {
struct skl_ddb_entry y_plane[I915_MAX_PIPES][I915_MAX_PLANES];
 };
 
-struct skl_wm_values {
+struct skl_ddb_values {
unsigned dirty_pipes;
struct skl_ddb_allocation ddb;
 };
@@ -2143,7 +2143,7 @@ struct drm_i915_private {
/* current hardware state */
union {
struct ilk_wm_values hw;
-   struct skl_wm_values skl_hw;
+   struct skl_ddb_values skl_hw;
struct vlv_wm_values vlv;
struct g4x_wm_values g4x;
};
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 898064e..e74efb4 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -480,7 +480,7 @@ struct intel_atomic_state {
bool skip_intermediate_wm;
 
/* Gen9+ only */
-   struct skl_wm_values wm_results;
+   struct skl_ddb_values wm_results;
 
struct i915_sw_fence commit_ready;
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7e15b26..6fec748 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5044,8 +5044,8 @@ skl_compute_ddb(struct drm_atomic_state *state)
 }
 
 static void
-skl_copy_wm_for_pipe(struct skl_wm_values *dst,
-struct skl_wm_values *src,
+skl_copy_ddb_for_pipe(struct skl_ddb_values *dst,
+struct skl_ddb_values *src,
 enum pipe pipe)
 {
memcpy(dst->ddb.y_plane[pipe], src->ddb.y_plane[pipe],
@@ -5097,7 +5097,7 @@ skl_compute_wm(struct drm_atomic_state *state)
struct drm_crtc *crtc;
struct drm_crtc_state *cstate;
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
-   struct skl_wm_values *results = _state->wm_results;
+   struct skl_ddb_values *results = _state->wm_results;
struct drm_device *dev = state->dev;
struct skl_pipe_wm *pipe_wm;
bool changed = false;
@@ -5199,8 +5199,8 @@ static void skl_initial_wm(struct intel_atomic_state 
*state,
struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
struct drm_device *dev = intel_crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct skl_wm_values *results = >wm_results;
-   struct skl_wm_values *hw_vals = _priv->wm.skl_hw;
+   struct skl_ddb_values *results = >wm_results;
+   struct skl_ddb_values *hw_vals = _priv->wm.skl_hw;
enum pipe pipe = intel_crtc->pipe;
 
if ((results->dirty_pipes & drm_crtc_mask(_crtc->base)) == 0)
@@ -5211,7 +5211,7 @@ static void skl_initial_wm(struct intel_atomic_state 
*state,
if (cstate->base.active_changed)
skl_atomic_update_crtc_wm(state, cstate);
 
-   skl_copy_wm_for_pipe(hw_vals, results, pipe);
+   skl_copy_ddb_for_pipe(hw_vals, results, pipe);
 
mutex_unlock(_priv->wm.wm_mutex);
 }
@@ -5343,7 +5343,7 @@ void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc,
 void skl_wm_get_hw_state(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct skl_wm_values *hw = _priv->wm.skl_hw;
+   struct skl_ddb_values *hw = _priv->wm.skl_hw;
struct skl_ddb_allocation *ddb = _priv->wm.skl_hw.ddb;
struct drm_crtc *crtc;
struct intel_crtc *intel_crtc;
-- 
2.7.4

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

[Intel-gfx] [PATCH 00/16] Adding NV12 support

[Vidya Srinivas]

This patch series is adding NV12 support for Broxton display after rebasing on
latest drm-tip.
Initial series of the patches can be found here:
https://lists.freedesktop.org/archives/intel-gfx/2015-May/066786.html

Previous revision history:
The first version of patches were reviewed when floated by Chandra in 2015
but currently there was a design change with respect to
- the way fb offset is handled
- the way rotation is handled
Current NV12 patch series has been ported as per the
current changes on drm-tip

Review comments from Ville (12th June 2017) have been addressed Review
comments from Clinton A Taylor (7th July 2017) have been addressed

Review comments from Clinton A Taylor (10th July 2017)
have been addressed. Had missed out tested-by/reviewed-by in the 
patches.

Fixed that error in this series.
Review comments from Ville (11th July 2017) addressed.
Review comments from Paauwe, Bob (29th July 2017) addressed.

Update from rev 28 Aug 2017
Rebased the series.
Tested with IGT for rotation, sprite and tiling combinations.
IGT Links:
https://patchwork.kernel.org/patch/9995943/
https://patchwork.kernel.org/patch/9995945/
Review comments by Maarten are addressed in this series.
NV12 enabled for Gen10.
Review comments from Shashank Sharma are addressed.

Update from last rev:
IGT debug_fs test failure fixed.

Chandra Konduru (6):
  drm/i915: Set scaler mode for NV12
  drm/i915: Update format_is_yuv() to include NV12
  drm/i915: Upscale scaler max scale for NV12
  drm/i915: Add NV12 as supported format for primary plane
  drm/i915: Add NV12 as supported format for sprite plane
  drm/i915: Add NV12 support to intel_framebuffer_init

Mahesh Kumar (9):
  drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values
  drm/i915/skl+: refactor WM calculation for NV12
  drm/i915/skl+: add NV12 in skl_format_to_fourcc
  drm/i915/skl+: support verification of DDB HW state for NV12
  drm/i915/skl+: NV12 related changes for WM
  drm/i915/skl+: pass skl_wm_level struct to wm compute func
  drm/i915/skl+: make sure higher latency level has higher wm value
  drm/i915/skl+: nv12 workaround disable WM level 1-7
  drm/i915/skl: split skl_compute_ddb function

Vidya Srinivas (1):
  drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg

 drivers/gpu/drm/i915/i915_drv.h  |  10 +-
 drivers/gpu/drm/i915/i915_reg.h  |   7 +
 drivers/gpu/drm/i915/intel_atomic.c  |   8 +-
 drivers/gpu/drm/i915/intel_display.c |  59 -
 drivers/gpu/drm/i915/intel_drv.h |   9 +-
 drivers/gpu/drm/i915/intel_pm.c  | 433 ++-
 drivers/gpu/drm/i915/intel_sprite.c  |  18 +-
 7 files changed, 357 insertions(+), 187 deletions(-)

-- 
2.7.4

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

[Intel-gfx] [PATCH 12/16] drm/i915: Upscale scaler max scale for NV12

[Vidya Srinivas]

From: Chandra Konduru 

This patch updates scaler max limit support for NV12

v2: Rebased (me)

v3: Rebased (me)

v4: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.

v5: Addressed review comments from Ville and rebased
- calculation of max_scale to be made
less convoluted by splitting it up a bit
- Indentation errors to be fixed in the series

v6: Rebased (me)
Fixed review comments from Paauwe, Bob J
Previous version, where a split of calculation
was done, was wrong. Fixed that issue here.

v7: Rebased (me)

v8: Rebased (me)

v9: Rebased (me)

v10: Rebased (me)

v11: Addressed review comments from Shashank Sharma

v12: Fixed failure in IGT debugfs_test.
fb is NULL in skl_update_scaler_plane
Due to this, accessing fb->format caused failure.
Patch checks fb before using.

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 | 40 ++--
 drivers/gpu/drm/i915/intel_drv.h |  3 ++-
 drivers/gpu/drm/i915/intel_sprite.c  |  3 ++-
 3 files changed, 33 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 971bd04..ac8279a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3435,6 +3435,8 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_UYVY;
case DRM_FORMAT_VYUY:
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
+   case DRM_FORMAT_NV12:
+   return PLANE_CTL_FORMAT_NV12;
default:
MISSING_CASE(pixel_format);
}
@@ -4658,7 +4660,9 @@ static void cpt_verify_modeset(struct drm_device *dev, 
int pipe)
 static int
 skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
  unsigned int scaler_user, int *scaler_id,
- int src_w, int src_h, int dst_w, int dst_h)
+ int src_w, int src_h, int dst_w, int dst_h,
+ bool plane_scaler_check,
+ uint32_t pixel_format)
 {
struct intel_crtc_scaler_state *scaler_state =
_state->scaler_state;
@@ -4676,6 +4680,9 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
 */
need_scaling = src_w != dst_w || src_h != dst_h;
 
+   if (plane_scaler_check)
+   need_scaling = pixel_format == DRM_FORMAT_NV12;
+
if (crtc_state->ycbcr420 && scaler_user == SKL_CRTC_INDEX)
need_scaling = true;
 
@@ -4751,9 +4758,10 @@ int skl_update_scaler_crtc(struct intel_crtc_state 
*state)
const struct drm_display_mode *adjusted_mode = 
>base.adjusted_mode;
 
return skl_update_scaler(state, !state->base.active, SKL_CRTC_INDEX,
-   >scaler_state.scaler_id,
-   state->pipe_src_w, state->pipe_src_h,
-   adjusted_mode->crtc_hdisplay, adjusted_mode->crtc_vdisplay);
+>scaler_state.scaler_id,
+state->pipe_src_w, state->pipe_src_h,
+adjusted_mode->crtc_hdisplay,
+adjusted_mode->crtc_vdisplay, false, 0);
 }
 
 /**
@@ -4783,7 +4791,8 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
drm_rect_width(_state->base.src) >> 16,
drm_rect_height(_state->base.src) >> 16,
drm_rect_width(_state->base.dst),
-   drm_rect_height(_state->base.dst));
+   drm_rect_height(_state->base.dst),
+   fb ? true : false, fb ? fb->format->format : 0);
 
if (ret || plane_state->scaler_id < 0)
return ret;
@@ -4809,6 +4818,7 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
+   case DRM_FORMAT_NV12:
break;
default:
DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d unsupported scaling format 
0x%x\n",
@@ -12775,11 +12785,13 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
 }
 
 int
-skl_max_scale(struct intel_crtc *intel_crtc, struct intel_crtc_state 
*crtc_state)
+skl_max_scale(struct intel_crtc *intel_crtc,
+ struct intel_crtc_state *crtc_state,
+ uint32_t pixel_format)
 {
struct drm_i915_private *dev_priv;
-   int max_scale;
-   int crtc_clock, max_dotclk;
+   int max_scale, mult;
+   int crtc_clock, 

[Intel-gfx] [PATCH 08/16] drm/i915/skl+: nv12 workaround disable WM level 1-7

[Vidya Srinivas]

From: Mahesh Kumar 

Display Workaround #0826 (SKL:ALL BXT:ALL) & #1059(CNL:A)
Hardware sometimes fails to wake memory from pkg C states fetching the
last few lines of planar YUV 420 (NV12) planes. This causes
intermittent underflow and corruption.
WA: Disable package C states or do not enable latency levels 1 through 7
(WM1 - WM7) on NV12 planes.

v2: Addressed review comments by Maarten.

Reviewed-by: Maarten Lankhorst 
Signed-off-by: Mahesh Kumar 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_pm.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d617fee..d9f6563 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4656,6 +4656,17 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
}
}
 
+   /*
+* Display WA #826 (SKL:ALL, BXT:ALL) & #1059 (CNL:A)
+* disable wm level 1-7 on NV12 planes
+*/
+   if (wp->is_planar && (level >= 1) &&
+   (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv) ||
+IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_A0))) {
+   result->plane_en = false;
+   return 0;
+   }
+
/* The number of lines are ignored for the level 0 watermark. */
result->plane_res_b = res_blocks;
result->plane_res_l = res_lines;
-- 
2.7.4

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

[Intel-gfx] [PATCH 03/16] drm/i915/skl+: add NV12 in skl_format_to_fourcc

[Vidya Srinivas]

From: Mahesh Kumar 

Add support of recognizing DRM_FORMAT_NV12 from plane_format
register value.

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/intel_display.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 30e38cb..1617692 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2626,6 +2626,8 @@ static int skl_format_to_fourcc(int format, bool 
rgb_order, bool alpha)
switch (format) {
case PLANE_CTL_FORMAT_RGB_565:
return DRM_FORMAT_RGB565;
+   case PLANE_CTL_FORMAT_NV12:
+   return DRM_FORMAT_NV12;
default:
case PLANE_CTL_FORMAT_XRGB_:
if (rgb_order) {
-- 
2.7.4

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

[Intel-gfx] [PATCH 05/16] drm/i915/skl+: NV12 related changes for WM

[Vidya Srinivas]

From: Mahesh Kumar 

NV12 requires WM calculation for UV plane as well.
UV plane WM should also fulfill all the WM related restrictions.

v2: Addressed review comments from Shashank Sharma.

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c  | 55 +++-
 3 files changed, 45 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b9914bb..9a9a645 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1463,6 +1463,7 @@ struct skl_wm_level {
 struct skl_wm_params {
bool x_tiled, y_tiled;
bool rc_surface;
+   bool is_planar;
uint32_t width;
uint8_t cpp;
uint32_t plane_pixel_rate;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f13decc..6402d6d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -594,6 +594,7 @@ struct intel_pipe_wm {
 
 struct skl_plane_wm {
struct skl_wm_level wm[8];
+   struct skl_wm_level uv_wm[8];
struct skl_wm_level trans_wm;
bool is_planar;
 };
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index bc0e2bf..2a0cc0b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4422,7 +4422,7 @@ static int
 skl_compute_plane_wm_params(const struct drm_i915_private *dev_priv,
struct intel_crtc_state *cstate,
const struct intel_plane_state *intel_pstate,
-   struct skl_wm_params *wp)
+   struct skl_wm_params *wp, int plane_num)
 {
struct intel_plane *plane = to_intel_plane(intel_pstate->base.plane);
const struct drm_plane_state *pstate = _pstate->base;
@@ -4435,6 +4435,12 @@ skl_compute_plane_wm_params(const struct 
drm_i915_private *dev_priv,
if (!intel_wm_plane_visible(cstate, intel_pstate))
return 0;
 
+   /* only NV12 format has two planes */
+   if (plane_num == 1 && fb->format->format != DRM_FORMAT_NV12) {
+   DRM_DEBUG_KMS("Non NV12 format have single plane\n");
+   return -EINVAL;
+   }
+
wp->y_tiled = fb->modifier == I915_FORMAT_MOD_Y_TILED ||
  fb->modifier == I915_FORMAT_MOD_Yf_TILED ||
  fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
@@ -4442,6 +4448,7 @@ skl_compute_plane_wm_params(const struct drm_i915_private 
*dev_priv,
wp->x_tiled = fb->modifier == I915_FORMAT_MOD_X_TILED;
wp->rc_surface = fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
 fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
+   wp->is_planar = fb->format->format == DRM_FORMAT_NV12;
 
if (plane->id == PLANE_CURSOR) {
wp->width = intel_pstate->base.crtc_w;
@@ -4454,7 +4461,10 @@ skl_compute_plane_wm_params(const struct 
drm_i915_private *dev_priv,
wp->width = drm_rect_width(_pstate->base.src) >> 16;
}
 
-   wp->cpp = fb->format->cpp[0];
+   if (plane_num == 1 && wp->is_planar)
+   wp->width /= 2;
+
+   wp->cpp = fb->format->cpp[plane_num];
wp->plane_pixel_rate = skl_adjusted_plane_pixel_rate(cstate,
 intel_pstate);
 
@@ -4652,7 +4662,8 @@ skl_compute_wm_levels(const struct drm_i915_private 
*dev_priv,
  struct intel_crtc_state *cstate,
  const struct intel_plane_state *intel_pstate,
  const struct skl_wm_params *wm_params,
- struct skl_plane_wm *wm)
+ struct skl_plane_wm *wm,
+ int plane_num)
 {
struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
struct drm_plane *plane = intel_pstate->base.plane;
@@ -4660,15 +4671,19 @@ skl_compute_wm_levels(const struct drm_i915_private 
*dev_priv,
uint16_t ddb_blocks;
enum pipe pipe = intel_crtc->pipe;
int level, max_level = ilk_wm_max_level(dev_priv);
+   enum plane_id plane_id = intel_plane->id;
int ret;
 
if (WARN_ON(!intel_pstate->base.fb))
return -EINVAL;
 
-   ddb_blocks = skl_ddb_entry_size(>plane[pipe][intel_plane->id]);
+   ddb_blocks = plane_num ?
+skl_ddb_entry_size(>uv_plane[pipe][plane_id]) :
+skl_ddb_entry_size(>plane[pipe][plane_id]);
 
for (level = 0; level <= max_level; level++) {
-   struct skl_wm_level *result = >wm[level];
+   struct skl_wm_level *result = plane_num ? >uv_wm[level] :
+ >wm[level];
 
ret = skl_compute_plane_wm(dev_priv,

[Intel-gfx] [PATCH 07/16] drm/i915/skl+: make sure higher latency level has higher wm value

[Vidya Srinivas]

From: Mahesh Kumar 

DDB allocation optimization algorithm requires/assumes ddb allocation for
any memory C-state level DDB value to be as high as level below the
current level. Render decompression requires level WM to be as high as
wm level-0. This patch fulfils both the requirements.

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/intel_pm.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f6ad1bf..d617fee 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4532,6 +4532,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
uint16_t ddb_allocation,
int level,
const struct skl_wm_params *wp,
+   const struct skl_wm_level *result_prev,
struct skl_wm_level *result /* out */)
 {
const struct drm_plane_state *pstate = _pstate->base;
@@ -4599,6 +4600,15 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
} else {
res_blocks++;
}
+
+   /*
+* Make sure result blocks for higher latency levels are atleast
+* as high as level below the current level.
+* Assumption in DDB algorithm optimization for special cases.
+* Also covers Display WA #1125 for RC.
+*/
+   if (result_prev->plane_res_b > res_blocks)
+   res_blocks = result_prev->plane_res_b;
}
 
if (INTEL_GEN(dev_priv) >= 11) {
@@ -4682,6 +4692,13 @@ skl_compute_wm_levels(const struct drm_i915_private 
*dev_priv,
for (level = 0; level <= max_level; level++) {
struct skl_wm_level *result = plane_num ? >uv_wm[level] :
  >wm[level];
+   struct skl_wm_level *result_prev;
+
+   if (level)
+   result_prev = plane_num ? >uv_wm[level - 1] :
+ >wm[level - 1];
+   else
+   result_prev = plane_num ? >uv_wm[0] : >wm[0];
 
ret = skl_compute_plane_wm(dev_priv,
   cstate,
@@ -4689,6 +4706,7 @@ skl_compute_wm_levels(const struct drm_i915_private 
*dev_priv,
   ddb_blocks,
   level,
   wm_params,
+  result_prev,
   result);
if (ret)
return ret;
-- 
2.7.4

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

[Intel-gfx] [PATCH 09/16] drm/i915/skl: split skl_compute_ddb function

[Vidya Srinivas]

From: Mahesh Kumar 

This patch splits skl_compute_wm/ddb functions into two parts.
One adds all affected pipes after the commit to atomic_state structure
and second part does compute the DDB.

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/intel_pm.c | 157 ++--
 1 file changed, 88 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d9f6563..ca3a783 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5058,69 +5058,16 @@ skl_ddb_add_affected_planes(struct intel_crtc_state 
*cstate)
 static int
 skl_compute_ddb(struct drm_atomic_state *state)
 {
-   struct drm_device *dev = state->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
+   const struct drm_i915_private *dev_priv = to_i915(state->dev);
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
-   struct intel_crtc *intel_crtc;
struct skl_ddb_allocation *ddb = _state->wm_results.ddb;
-   uint32_t realloc_pipes = pipes_modified(state);
-   int ret;
-
-   /*
-* If this is our first atomic update following hardware readout,
-* we can't trust the DDB that the BIOS programmed for us.  Let's
-* pretend that all pipes switched active status so that we'll
-* ensure a full DDB recompute.
-*/
-   if (dev_priv->wm.distrust_bios_wm) {
-   ret = drm_modeset_lock(>mode_config.connection_mutex,
-  state->acquire_ctx);
-   if (ret)
-   return ret;
-
-   intel_state->active_pipe_changes = ~0;
-
-   /*
-* We usually only initialize intel_state->active_crtcs if we
-* we're doing a modeset; make sure this field is always
-* initialized during the sanitization process that happens
-* on the first commit too.
-*/
-   if (!intel_state->modeset)
-   intel_state->active_crtcs = dev_priv->active_crtcs;
-   }
-
-   /*
-* If the modeset changes which CRTC's are active, we need to
-* recompute the DDB allocation for *all* active pipes, even
-* those that weren't otherwise being modified in any way by this
-* atomic commit.  Due to the shrinking of the per-pipe allocations
-* when new active CRTC's are added, it's possible for a pipe that
-* we were already using and aren't changing at all here to suddenly
-* become invalid if its DDB needs exceeds its new allocation.
-*
-* Note that if we wind up doing a full DDB recompute, we can't let
-* any other display updates race with this transaction, so we need
-* to grab the lock on *all* CRTC's.
-*/
-   if (intel_state->active_pipe_changes) {
-   realloc_pipes = ~0;
-   intel_state->wm_results.dirty_pipes = ~0;
-   }
+   struct intel_crtc *crtc;
+   struct intel_crtc_state *cstate;
+   int ret, i;
 
-   /*
-* We're not recomputing for the pipes not included in the commit, so
-* make sure we start with the current state.
-*/
memcpy(ddb, _priv->wm.skl_hw.ddb, sizeof(*ddb));
 
-   for_each_intel_crtc_mask(dev, intel_crtc, realloc_pipes) {
-   struct intel_crtc_state *cstate;
-
-   cstate = intel_atomic_get_crtc_state(state, intel_crtc);
-   if (IS_ERR(cstate))
-   return PTR_ERR(cstate);
-
+   for_each_new_intel_crtc_in_state(intel_state, crtc, cstate, i) {
ret = skl_allocate_pipe_ddb(cstate, ddb);
if (ret)
return ret;
@@ -5182,23 +5129,23 @@ skl_print_wm_changes(const struct drm_atomic_state 
*state)
 }
 
 static int
-skl_compute_wm(struct drm_atomic_state *state)
+skl_ddb_add_affected_pipes(struct drm_atomic_state *state, bool *changed)
 {
-   struct drm_crtc *crtc;
-   struct drm_crtc_state *cstate;
-   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
-   struct skl_ddb_values *results = _state->wm_results;
struct drm_device *dev = state->dev;
-   struct skl_pipe_wm *pipe_wm;
-   bool changed = false;
+   const struct drm_i915_private *dev_priv = to_i915(dev);
+   const struct drm_crtc *crtc;
+   const struct drm_crtc_state *cstate;
+   struct intel_crtc *intel_crtc;
+   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+   uint32_t realloc_pipes = pipes_modified(state);
int ret, i;
 
/*
 * When we distrust bios wm we always need to recompute to set the
 * expected DDB allocations for each CRTC.
 */
-   if (to_i915(dev)->wm.distrust_bios_wm)
-   changed = true;
+   if 

[Intel-gfx] [PATCH 10/16] drm/i915: Set scaler mode for NV12

[Vidya Srinivas]

From: Chandra Konduru 

This patch sets appropriate scaler mode for NV12 format.
In this mode, skylake scaler does either chroma-upsampling or
chroma-upsampling and resolution scaling

v2: Review comments from Ville addressed
NV12 case to be checked first for setting
the scaler

v3: Rebased (me)

v4: Rebased (me)

v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.

v6: Rebased (me)

v7: Rebased (me)

v8: Rebased (me)
Restricting the NV12 change for scaler to BXT and KBL
in this series.

v9: Rebased (me)

v10: As of now, NV12 has been tested on Gen9 and Gen10. However,
code is applicable to all GEN >= 9. Hence making
that change to keep it generic.
Comments under v8 is not valid anymore.

v11: Addressed review comments by Shashank Sharma.
For Gen10+, the scaler mode to be set it planar or normal
(single bit). Changed the code to be applicable to all
Gen.

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/i915_reg.h | 1 +
 drivers/gpu/drm/i915/intel_atomic.c | 8 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f6afa5e..10edacc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6732,6 +6732,7 @@ enum {
 #define PS_SCALER_MODE_MASK (3 << 28)
 #define PS_SCALER_MODE_DYN  (0 << 28)
 #define PS_SCALER_MODE_HQ  (1 << 28)
+#define PS_SCALER_MODE_PLANAR (1 << 29)
 #define PS_PLANE_SEL_MASK  (7 << 25)
 #define PS_PLANE_SEL(plane) (((plane) + 1) << 25)
 #define PS_FILTER_MASK (3 << 23)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index d452c32..7ae4f48 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -327,8 +327,12 @@ int intel_atomic_setup_scalers(struct drm_i915_private 
*dev_priv,
}
 
/* set scaler mode */
-   if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
-   scaler_state->scalers[*scaler_id].mode = 0;
+   if ((INTEL_GEN(dev_priv) >= 9) &&
+   plane_state && plane_state->base.fb &&
+   plane_state->base.fb->format->format ==
+   DRM_FORMAT_NV12) {
+   scaler_state->scalers[*scaler_id].mode =
+   PS_SCALER_MODE_PLANAR;
} else if (num_scalers_need == 1 && intel_crtc->pipe != PIPE_C) 
{
/*
 * when only 1 scaler is in use on either pipe A or B,
-- 
2.7.4

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

[Intel-gfx] [PATCH 06/16] drm/i915/skl+: pass skl_wm_level struct to wm compute func

[Vidya Srinivas]

From: Mahesh Kumar 

This patch passes skl_wm_level structure itself to watermark
computation function skl_compute_plane_wm function (instead
of its internal parameters). It reduces number of arguments
required to be passed.

v2: Addressed review comments by Shashank Sharma

Reviewed-by: Shashank Sharma 
Signed-off-by: Mahesh Kumar 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_pm.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2a0cc0b..f6ad1bf 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4532,9 +4532,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
uint16_t ddb_allocation,
int level,
const struct skl_wm_params *wp,
-   uint16_t *out_blocks, /* out */
-   uint8_t *out_lines, /* out */
-   bool *enabled /* out */)
+   struct skl_wm_level *result /* out */)
 {
const struct drm_plane_state *pstate = _pstate->base;
uint32_t latency = dev_priv->wm.skl_latency[level];
@@ -4548,7 +4546,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
 
if (latency == 0 ||
!intel_wm_plane_visible(cstate, intel_pstate)) {
-   *enabled = false;
+   result->plane_en = false;
return 0;
}
 
@@ -4629,7 +4627,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
if ((level > 0 && res_lines > 31) ||
res_blocks >= ddb_allocation ||
min_disp_buf_needed >= ddb_allocation) {
-   *enabled = false;
+   result->plane_en = false;
 
/*
 * If there are no valid level 0 watermarks, then we can't
@@ -4649,9 +4647,9 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
}
 
/* The number of lines are ignored for the level 0 watermark. */
-   *out_lines = level ? res_lines : 0;
-   *out_blocks = res_blocks;
-   *enabled = true;
+   result->plane_res_b = res_blocks;
+   result->plane_res_l = res_lines;
+   result->plane_en = true;
 
return 0;
 }
@@ -4691,9 +4689,7 @@ skl_compute_wm_levels(const struct drm_i915_private 
*dev_priv,
   ddb_blocks,
   level,
   wm_params,
-  >plane_res_b,
-  >plane_res_l,
-  >plane_en);
+  result);
if (ret)
return ret;
}
-- 
2.7.4

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

[Intel-gfx] [PATCH 04/16] drm/i915/skl+: support verification of DDB HW state for NV12

[Vidya Srinivas]

From: Mahesh Kumar 

For YUV 420 Planar formats like NV12,
buffer allocation is done for Y and UV surfaces separately.
For NV12 plane formats, the UV buffer
allocation must be programmed in the Plane Buffer Config register
and the Y buffer allocation must be programmed in the
Plane NV12 Buffer Config register. Both register values
should be verified during verify_wm_state.

v2: Addressed review comments by Maarten.

v2: Addressed review comments by Shashank Sharma.

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/intel_display.c |  2 +-
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c  | 51 +---
 3 files changed, 43 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 1617692..971bd04 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2621,7 +2621,7 @@ static int i9xx_format_to_fourcc(int format)
}
 }
 
-static int skl_format_to_fourcc(int format, bool rgb_order, bool alpha)
+int skl_format_to_fourcc(int format, bool rgb_order, bool alpha)
 {
switch (format) {
case PLANE_CTL_FORMAT_RGB_565:
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 70447c6..f13decc 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1597,6 +1597,7 @@ u32 skl_plane_stride(const struct drm_framebuffer *fb, 
int plane,
 int skl_check_plane_surface(const struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state);
 int i9xx_check_plane_surface(struct intel_plane_state *plane_state);
+int skl_format_to_fourcc(int format, bool rgb_order, bool alpha);
 
 /* intel_csr.c */
 void intel_csr_ucode_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0537567..bc0e2bf 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3828,6 +3828,44 @@ static void skl_ddb_entry_init_from_hw(struct 
skl_ddb_entry *entry, u32 reg)
entry->end += 1;
 }
 
+static void
+skl_ddb_get_hw_plane_state(struct drm_i915_private *dev_priv,
+  const enum pipe pipe,
+  const enum plane_id plane_id,
+  struct skl_ddb_allocation *ddb /* out */)
+{
+   u32 val, val2 = 0;
+   int fourcc, pixel_format;
+
+   /* Cursor doesn't support NV12/planar, so no extra calculation needed */
+   if (plane_id == PLANE_CURSOR) {
+   val = I915_READ(CUR_BUF_CFG(pipe));
+   skl_ddb_entry_init_from_hw(>plane[pipe][plane_id], val);
+   return;
+   }
+
+   val = I915_READ(PLANE_CTL(pipe, plane_id));
+
+   /* No DDB allocated for disabled planes */
+   if (!(val & PLANE_CTL_ENABLE))
+   return;
+
+   pixel_format = val & PLANE_CTL_FORMAT_MASK;
+   fourcc = skl_format_to_fourcc(pixel_format,
+ val & PLANE_CTL_ORDER_RGBX,
+ val & PLANE_CTL_ALPHA_MASK);
+
+   val = I915_READ(PLANE_BUF_CFG(pipe, plane_id));
+   val2 = I915_READ(PLANE_NV12_BUF_CFG(pipe, plane_id));
+
+   if (fourcc == DRM_FORMAT_NV12) {
+   skl_ddb_entry_init_from_hw(>plane[pipe][plane_id], val2);
+   skl_ddb_entry_init_from_hw(>uv_plane[pipe][plane_id], val);
+   } else {
+   skl_ddb_entry_init_from_hw(>plane[pipe][plane_id], val);
+   }
+}
+
 void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
  struct skl_ddb_allocation *ddb /* out */)
 {
@@ -3844,16 +3882,9 @@ void skl_ddb_get_hw_state(struct drm_i915_private 
*dev_priv,
if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
continue;
 
-   for_each_plane_id_on_crtc(crtc, plane_id) {
-   u32 val;
-
-   if (plane_id != PLANE_CURSOR)
-   val = I915_READ(PLANE_BUF_CFG(pipe, plane_id));
-   else
-   val = I915_READ(CUR_BUF_CFG(pipe));
-
-   skl_ddb_entry_init_from_hw(>plane[pipe][plane_id], 
val);
-   }
+   for_each_plane_id_on_crtc(crtc, plane_id)
+   skl_ddb_get_hw_plane_state(dev_priv, pipe,
+  plane_id, ddb);
 
intel_display_power_put(dev_priv, power_domain);
}
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 3/3] just some guess work to findout the culprit. If this breaks then we know what do.

[Kumar, Abhijeet]

On 2/14/2018 9:36 AM, abhijeet.ku...@intel.com wrote:

From: Abhijeet Kumar 

---
  sound/pci/hda/hda_codec.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 8c1b07e300a8..377d5719b4cd 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -2714,7 +2714,7 @@ static unsigned int hda_sync_power_state(struct hda_codec 
*codec,
int count;
  
  	for (count = 0;count < 500; count++) {

-   state = snd_hda_codec_read(codec, fg, 0,
+   state = snd_hdac_codec_read(>core, fg, 0,
   AC_VERB_GET_POWER_STATE, 0);
if (state & AC_PWRST_ERROR){
msleep(20);


Both tests are passing on hsw and bdw devices.I can conclude that none 
of my changes
in "ALSA: hda: Make use of core codec functions to sync power state" is 
"*directly*" causing the regression.
As this patch series changes the previously defined sync function 
similar to the latest one (the one defined

in the defaulter patch).

Sidenote- Sorry for the missing commit message, it was just a HACK patch. :)

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] Revert "ALSA: hda: Make use of core codec functions to sync power state"

[Patchwork]

== Series Details ==

Series: series starting with [1/3] Revert "ALSA: hda: Make use of core codec 
functions to sync power state"
URL   : https://patchwork.freedesktop.org/series/38212/
State : success

== Summary ==

Series 38212v1 series starting with [1/3] Revert "ALSA: hda: Make use of core 
codec functions to sync power state"
https://patchwork.freedesktop.org/api/1.0/series/38212/revisions/1/mbox/

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-cnl-y3) fdo#105058
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test pm_rpm:
Subgroup basic-pci-d3-state:
fail   -> PASS   (fi-hsw-4770) fdo#105069 +3

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:428s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:436s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:382s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:492s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:290s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:484s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:491s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:473s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:461s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:573s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:582s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:418s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:284s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:513s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:392s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:417s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:468s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:416s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:462s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:497s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:500s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:595s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:439s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:507s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:528s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:494s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:482s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:415s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:434s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:528s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:399s
Blacklisted hosts:
fi-glk-dsi   total:117  pass:104  dwarn:0   dfail:0   fail:0   skip:12 
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:454s

e404d341ffdd255f9a7d8e4461170694edcb3e25 drm-tip: 2018y-02m-14d-01h-12m-17s UTC 
integration manifest
2ee32574fbfc just some guess work to findout the culprit. If this breaks then 
we know what do.
90c5eef4d5b8 redo
78ff10b72263 Revert "ALSA: hda: Make use of core codec functions to sync power 
state"

== Logs ==

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

[Intel-gfx] [PATCH 2/3] redo

[abhijeet . kumar]

From: Abhijeet Kumar 

---
 sound/pci/hda/hda_codec.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index e018ecbf78a8..8c1b07e300a8 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -2711,12 +2711,15 @@ static unsigned int hda_sync_power_state(struct 
hda_codec *codec,
 {
unsigned long end_time = jiffies + msecs_to_jiffies(500);
unsigned int state, actual_state;
+   int count;
 
-   for (;;) {
+   for (count = 0;count < 500; count++) {
state = snd_hda_codec_read(codec, fg, 0,
   AC_VERB_GET_POWER_STATE, 0);
-   if (state & AC_PWRST_ERROR)
+   if (state & AC_PWRST_ERROR){
+   msleep(20);
break;
+   }
actual_state = (state >> 4) & 0x0f;
if (actual_state == power_state)
break;
-- 
1.9.1

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

[Intel-gfx] [PATCH 1/3] Revert "ALSA: hda: Make use of core codec functions to sync power state"

[abhijeet . kumar]

From: Abhijeet Kumar 

This reverts commit 3b5b899ca67db07a4c4825911072221f99e157e2.
---
 sound/pci/hda/hda_codec.c | 28 +++-
 sound/pci/hda/hda_local.h |  6 +-
 2 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 5bc3a7468e17..e018ecbf78a8 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -2702,6 +2702,32 @@ void snd_hda_codec_set_power_to_all(struct hda_codec 
*codec, hda_nid_t fg,
 }
 EXPORT_SYMBOL_GPL(snd_hda_codec_set_power_to_all);
 
+/*
+ * wait until the state is reached, returns the current state
+ */
+static unsigned int hda_sync_power_state(struct hda_codec *codec,
+hda_nid_t fg,
+unsigned int power_state)
+{
+   unsigned long end_time = jiffies + msecs_to_jiffies(500);
+   unsigned int state, actual_state;
+
+   for (;;) {
+   state = snd_hda_codec_read(codec, fg, 0,
+  AC_VERB_GET_POWER_STATE, 0);
+   if (state & AC_PWRST_ERROR)
+   break;
+   actual_state = (state >> 4) & 0x0f;
+   if (actual_state == power_state)
+   break;
+   if (time_after_eq(jiffies, end_time))
+   break;
+   /* wait until the codec reachs to the target state */
+   msleep(1);
+   }
+   return state;
+}
+
 /**
  * snd_hda_codec_eapd_power_filter - A power filter callback for EAPD
  * @codec: the HDA codec
@@ -2764,7 +2790,7 @@ static unsigned int hda_set_power_state(struct hda_codec 
*codec,
   state);
snd_hda_codec_set_power_to_all(codec, fg, power_state);
}
-   state = snd_hda_sync_power_state(codec, fg, power_state);
+   state = hda_sync_power_state(codec, fg, power_state);
if (!(state & AC_PWRST_ERROR))
break;
}
diff --git a/sound/pci/hda/hda_local.h b/sound/pci/hda/hda_local.h
index 321e78baa63c..5b5c324c99b9 100644
--- a/sound/pci/hda/hda_local.h
+++ b/sound/pci/hda/hda_local.h
@@ -622,11 +622,7 @@ int snd_hda_check_amp_list_power(struct hda_codec *codec,
 {
return snd_hdac_check_power_state(>core, nid, target_state);
 }
-static inline bool snd_hda_sync_power_state(struct hda_codec *codec,
-  hda_nid_t nid, unsigned int target_state)
-{
-   return snd_hdac_sync_power_state(>core, nid, target_state);
-}
+
 unsigned int snd_hda_codec_eapd_power_filter(struct hda_codec *codec,
 hda_nid_t nid,
 unsigned int power_state);
-- 
1.9.1

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

[Intel-gfx] [PATCH 3/3] just some guess work to findout the culprit. If this breaks then we know what do.

[abhijeet . kumar]

From: Abhijeet Kumar 

---
 sound/pci/hda/hda_codec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 8c1b07e300a8..377d5719b4cd 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -2714,7 +2714,7 @@ static unsigned int hda_sync_power_state(struct hda_codec 
*codec,
int count;
 
for (count = 0;count < 500; count++) {
-   state = snd_hda_codec_read(codec, fg, 0,
+   state = snd_hdac_codec_read(>core, fg, 0,
   AC_VERB_GET_POWER_STATE, 0);
if (state & AC_PWRST_ERROR){
msleep(20);
-- 
1.9.1

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

[Intel-gfx] [PATCH 2/3] redo

[abhijeet . kumar]

From: Abhijeet Kumar 

---
 sound/pci/hda/hda_codec.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index e018ecbf78a8..8c1b07e300a8 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -2711,12 +2711,15 @@ static unsigned int hda_sync_power_state(struct 
hda_codec *codec,
 {
unsigned long end_time = jiffies + msecs_to_jiffies(500);
unsigned int state, actual_state;
+   int count;
 
-   for (;;) {
+   for (count = 0;count < 500; count++) {
state = snd_hda_codec_read(codec, fg, 0,
   AC_VERB_GET_POWER_STATE, 0);
-   if (state & AC_PWRST_ERROR)
+   if (state & AC_PWRST_ERROR){
+   msleep(20);
break;
+   }
actual_state = (state >> 4) & 0x0f;
if (actual_state == power_state)
break;
-- 
1.9.1

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

[Intel-gfx] [PATCH 3/3] just some guess work to findout the culprit. If this breaks then we know what do.

[abhijeet . kumar]

From: Abhijeet Kumar 

---
 sound/pci/hda/hda_codec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 8c1b07e300a8..377d5719b4cd 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -2714,7 +2714,7 @@ static unsigned int hda_sync_power_state(struct hda_codec 
*codec,
int count;
 
for (count = 0;count < 500; count++) {
-   state = snd_hda_codec_read(codec, fg, 0,
+   state = snd_hdac_codec_read(>core, fg, 0,
   AC_VERB_GET_POWER_STATE, 0);
if (state & AC_PWRST_ERROR){
msleep(20);
-- 
1.9.1

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

[Intel-gfx] [PATCH 1/3] Revert "ALSA: hda: Make use of core codec functions to sync power state"

[abhijeet . kumar]

From: Abhijeet Kumar 

This reverts commit 3b5b899ca67db07a4c4825911072221f99e157e2.
---
 sound/pci/hda/hda_codec.c | 28 +++-
 sound/pci/hda/hda_local.h |  6 +-
 2 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 5bc3a7468e17..e018ecbf78a8 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -2702,6 +2702,32 @@ void snd_hda_codec_set_power_to_all(struct hda_codec 
*codec, hda_nid_t fg,
 }
 EXPORT_SYMBOL_GPL(snd_hda_codec_set_power_to_all);
 
+/*
+ * wait until the state is reached, returns the current state
+ */
+static unsigned int hda_sync_power_state(struct hda_codec *codec,
+hda_nid_t fg,
+unsigned int power_state)
+{
+   unsigned long end_time = jiffies + msecs_to_jiffies(500);
+   unsigned int state, actual_state;
+
+   for (;;) {
+   state = snd_hda_codec_read(codec, fg, 0,
+  AC_VERB_GET_POWER_STATE, 0);
+   if (state & AC_PWRST_ERROR)
+   break;
+   actual_state = (state >> 4) & 0x0f;
+   if (actual_state == power_state)
+   break;
+   if (time_after_eq(jiffies, end_time))
+   break;
+   /* wait until the codec reachs to the target state */
+   msleep(1);
+   }
+   return state;
+}
+
 /**
  * snd_hda_codec_eapd_power_filter - A power filter callback for EAPD
  * @codec: the HDA codec
@@ -2764,7 +2790,7 @@ static unsigned int hda_set_power_state(struct hda_codec 
*codec,
   state);
snd_hda_codec_set_power_to_all(codec, fg, power_state);
}
-   state = snd_hda_sync_power_state(codec, fg, power_state);
+   state = hda_sync_power_state(codec, fg, power_state);
if (!(state & AC_PWRST_ERROR))
break;
}
diff --git a/sound/pci/hda/hda_local.h b/sound/pci/hda/hda_local.h
index 321e78baa63c..5b5c324c99b9 100644
--- a/sound/pci/hda/hda_local.h
+++ b/sound/pci/hda/hda_local.h
@@ -622,11 +622,7 @@ int snd_hda_check_amp_list_power(struct hda_codec *codec,
 {
return snd_hdac_check_power_state(>core, nid, target_state);
 }
-static inline bool snd_hda_sync_power_state(struct hda_codec *codec,
-  hda_nid_t nid, unsigned int target_state)
-{
-   return snd_hdac_sync_power_state(>core, nid, target_state);
-}
+
 unsigned int snd_hda_codec_eapd_power_filter(struct hda_codec *codec,
 hda_nid_t nid,
 unsigned int power_state);
-- 
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/bxt: Enable VBT based BL control for DP (v2)

[Mustaffa, Mustamin B]

Hi Jani, 

I able to figure out using intel_dp structure instead of dev_priv. 

Should I continue using dev_priv or intel_dp?

-   int backlight_controller = dev_priv->vbt.backlight.controller;
+   int backlight_controller = 
intel_dp->attached_connector->panel.backlight.controller;

Best regard 

Mustamin

-Original Message-
From: Jani Nikula [mailto:jani.nik...@linux.intel.com] 
Sent: Tuesday, February 13, 2018 11:53 PM
To: Mustaffa, Mustamin B ; 
intel-gfx@lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH] drm/i915/bxt: Enable VBT based BL control for 
DP (v2)

On Fri, 09 Feb 2018, "Mustaffa, Mustamin B"  
wrote:
> May I know why the need to use connector as connector wasn't 
> initialized in parent function ' intel_pps_get_registers'?

Oh, right, I overlooked that.

> While ' dev_priv' already initialized which also already initialized 
> to the VBT value. So it make sense to me to use 'dev_priv' structure 
> to read the VBT value instead of connector.

Okay, I think the right thing to do in the long run is to refactor the code to 
initialize the value in the connector earlier. We'll want to use the VBT only 
for initialization once. But for now, I think this is fine. Please rebase the 
patch against current upstream so we get fresh CI results, and resend.

Thanks,
Jani.


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

Re: [Intel-gfx] [PATCH 1/5] drm/i915: add and enable DP AUX CH mutex

[Souza, Jose]

On Tue, 2018-02-13 at 17:30 -0800, Rodrigo Vivi wrote:
> José Roberto de Souza  writes:
> 
> > When PSR/PSR2 is enabled hardware can do AUX transactions by it
> > self, so
> > lets use the mutex register that is available in gen9+ to avoid
> > concurrent
> > access by hardware and driver.
> > 
> > Reference: https://01.org/sites/default/files/documentation/intel-g
> > fx-prm-osrc-skl-vol12-display.pdf
> > Page 198 - AUX programming sequence
> > 
> > As gen < 9 don't have the mutex PSR needs to be disabled, that is
> > why the
> > 'else TODO' was added. This is also backed by spec:
> > "DDI A AUX channel transactions must not be sent while SRD is
> > enabled.
> > SRD must be completely disabled before a DDI A AUX channel
> > transaction can
> > be sent." BSpec: 7530
> > 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h  |  9 
> >  drivers/gpu/drm/i915/intel_dp.c  | 48
> > 
> >  drivers/gpu/drm/i915/intel_drv.h |  1 +
> >  drivers/gpu/drm/i915/intel_psr.c |  6 +
> >  4 files changed, 64 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index f6afa5e5e7c1..5d7736117cb9 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -5318,6 +5318,7 @@ enum {
> >  #define _DPA_AUX_CH_DATA3  (dev_priv-
> > >info.display_mmio_offset + 0x6401c)
> >  #define _DPA_AUX_CH_DATA4  (dev_priv-
> > >info.display_mmio_offset + 0x64020)
> >  #define _DPA_AUX_CH_DATA5  (dev_priv-
> > >info.display_mmio_offset + 0x64024)
> > +#define _DPA_AUX_CH_MUTEX  (dev_priv-
> > >info.display_mmio_offset + 0x6402C)
> >  
> >  #define _DPB_AUX_CH_CTL(dev_priv-
> > >info.display_mmio_offset + 0x64110)
> >  #define _DPB_AUX_CH_DATA1  (dev_priv-
> > >info.display_mmio_offset + 0x64114)
> > @@ -5325,6 +5326,7 @@ enum {
> >  #define _DPB_AUX_CH_DATA3  (dev_priv-
> > >info.display_mmio_offset + 0x6411c)
> >  #define _DPB_AUX_CH_DATA4  (dev_priv-
> > >info.display_mmio_offset + 0x64120)
> >  #define _DPB_AUX_CH_DATA5  (dev_priv-
> > >info.display_mmio_offset + 0x64124)
> > +#define _DPB_AUX_CH_MUTEX  (dev_priv-
> > >info.display_mmio_offset + 0x6412C)
> >  
> >  #define _DPC_AUX_CH_CTL(dev_priv-
> > >info.display_mmio_offset + 0x64210)
> >  #define _DPC_AUX_CH_DATA1  (dev_priv-
> > >info.display_mmio_offset + 0x64214)
> > @@ -5332,6 +5334,7 @@ enum {
> >  #define _DPC_AUX_CH_DATA3  (dev_priv-
> > >info.display_mmio_offset + 0x6421c)
> >  #define _DPC_AUX_CH_DATA4  (dev_priv-
> > >info.display_mmio_offset + 0x64220)
> >  #define _DPC_AUX_CH_DATA5  (dev_priv-
> > >info.display_mmio_offset + 0x64224)
> > +#define _DPC_AUX_CH_MUTEX  (dev_priv-
> > >info.display_mmio_offset + 0x6422C)
> >  
> >  #define _DPD_AUX_CH_CTL(dev_priv-
> > >info.display_mmio_offset + 0x64310)
> >  #define _DPD_AUX_CH_DATA1  (dev_priv-
> > >info.display_mmio_offset + 0x64314)
> > @@ -5339,6 +5342,7 @@ enum {
> >  #define _DPD_AUX_CH_DATA3  (dev_priv-
> > >info.display_mmio_offset + 0x6431c)
> >  #define _DPD_AUX_CH_DATA4  (dev_priv-
> > >info.display_mmio_offset + 0x64320)
> >  #define _DPD_AUX_CH_DATA5  (dev_priv-
> > >info.display_mmio_offset + 0x64324)
> > +#define _DPD_AUX_CH_MUTEX  (dev_priv-
> > >info.display_mmio_offset + 0x6432C)
> >  
> >  #define _DPF_AUX_CH_CTL(dev_priv-
> > >info.display_mmio_offset + 0x64510)
> >  #define _DPF_AUX_CH_DATA1  (dev_priv-
> > >info.display_mmio_offset + 0x64514)
> > @@ -5346,9 +5350,11 @@ enum {
> >  #define _DPF_AUX_CH_DATA3  (dev_priv-
> > >info.display_mmio_offset + 0x6451c)
> >  #define _DPF_AUX_CH_DATA4  (dev_priv-
> > >info.display_mmio_offset + 0x64520)
> >  #define _DPF_AUX_CH_DATA5  (dev_priv-
> > >info.display_mmio_offset + 0x64524)
> > +#define _DPF_AUX_CH_MUTEX  (dev_priv-
> > >info.display_mmio_offset + 0x6452C)
> >  
> >  #define DP_AUX_CH_CTL(port)_MMIO_PORT(port,
> > _DPA_AUX_CH_CTL, _DPB_AUX_CH_CTL)
> >  #define DP_AUX_CH_DATA(port, i)_MMIO(_PORT(port,
> > _DPA_AUX_CH_DATA1, _DPB_AUX_CH_DATA1) + (i) * 4) /* 5 registers */
> > +#define DP_AUX_CH_MUTEX(port)  _MMIO_PORT(port,
> > _DPA_AUX_CH_MUTEX, _DPB_AUX_CH_MUTEX)
> >  
> >  #define   DP_AUX_CH_CTL_SEND_BUSY  (1 << 31)
> >  #define   DP_AUX_CH_CTL_DONE   (1 << 30)
> > @@ -5378,6 +5384,9 @@ enum {
> >  #define   DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(c) (((c) - 1) << 5)
> >  #define   DP_AUX_CH_CTL_SYNC_PULSE_SKL(c)   ((c) - 1)
> >  
> > +#define   DP_AUX_CH_MUTEX_ENABLE   (1 << 31)
> > +#define   DP_AUX_CH_MUTEX_STATUS   (1 << 30)
> > +
> >  /*
> >   * Computing GMCH M and N values for the Display Port link
> >   *
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index f20b25f98e5a..bd5f1bb730ff 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ 

Re: [Intel-gfx] [PATCH v10 3/7] drm/i915/guc: Implement dynamic GuC WOPCM offset and size

[Yaodong Li]

On 02/13/2018 07:56 AM, Michal Wajdeczko wrote:


Also, comparing again your drawing with the spec I think it
should look like this:

   + ++ <== WOPCM top
  /|\    | HW RESERVED    |
   | +--- +
   | |    |
   | +-- ++ <== GuC WOPCM top
   |    /|\  |    |
   | |   |    |
   |    GuC  |    |
   |   WOPCM |    GuC firmware    |
   |    size |    |
 WOPCM   |   ++
  size  \|/  |    GuC reserved    |
   | +-- ++ <== GuC WOPCM base (offset from 
WOPCM base)

   | |   WOPCM RESERVED   |
   | ++
  \|/    |    HuC firmware    |
   + ++ <== WOPCM base



+
+/* GUC WOPCM offset needs to be 16KB aligned. */
+#define GUC_WOPCM_OFFSET_ALIGNMENT    (16 << 10)
+/* 16KB reserved at the beginning of GuC WOPCM. */
+#define GUC_WOPCM_RESERVED    (16 << 10)
+/* 8KB from GUC_WOPCM_RESERVED is reserved for GuC stack. */
+#define GUC_WOPCM_STACK_RESERVED    (8 << 10)
+/* 24KB at the end of GuC WOPCM is reserved for RC6 CTX on BXT. */
+#define BXT_GUC_WOPCM_RC6_CTX_RESERVED    (24 << 10)


Hmm, I'm still not convinced that we correctly attach it to "GuC WOPCM".

In the result, maybe we should stop focusing on "intel_guc_wopcm" and 
define

everything as "intel_wopcm" as it was earlier suggested by Joonas.

Then we can define our struct to match diagram above as

struct intel_wopcm {
u32 size;
struct {
    u32 base;
    u32 size;
} guc;
};

u32 intel_wopcm_guc_top(struct intel_wopcm *wopcm)
{
return wopcm->guc.base + wopcm->guc.size;
}

More comments about the *top*:-)

The *top* we used in driver code to verify where the non-wopcm guc memory
allocation starts is the offset value from guc.base to WOPCM_TOP. so we 
don't need to

add the guc.base to it.

From GuC point of view the *top* (boundary between wopcm and non-wopcm 
memory)

is like:
+--+ <=== GuC memory end

   Non WOPCM

+--+ <=== *top* (This is actually in top of the whole WOPCM)
 CTX Rsvd
+--+ <=== *__top*  (wopcm->guc.size)
  WOPCM
+--+ <=== guc base (wopcm->guc.base)

actually, we had a discussion whether we should set the guc wopcm and 
non-wopcm
boundary to *__top* but the suggestion we got is to stick to the spec 
description which

says to allocate "non-wopcm memory starts from WOPCM TOP"(even if it seems
we could use *__top* as the boundary:-)). and it's because of this 
reason we called the

wopcm from guc_base to *top* as GuC WOPCM since we count the wopcm between
*__top* to *top* as a part of GuC address space while trying to allocate 
non-wopcm

for GuC (even though GuC won't access CTX Rsvd at allO:-)).

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

Re: [Intel-gfx] [PATCH 1/5] drm/i915: add and enable DP AUX CH mutex

[Rodrigo Vivi]

José Roberto de Souza  writes:

> When PSR/PSR2 is enabled hardware can do AUX transactions by it self, so
> lets use the mutex register that is available in gen9+ to avoid concurrent
> access by hardware and driver.
>
> Reference: 
> https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol12-display.pdf
> Page 198 - AUX programming sequence
>
> As gen < 9 don't have the mutex PSR needs to be disabled, that is why the
> 'else TODO' was added. This is also backed by spec:
> "DDI A AUX channel transactions must not be sent while SRD is enabled.
> SRD must be completely disabled before a DDI A AUX channel transaction can
> be sent." BSpec: 7530
>
> Cc: Rodrigo Vivi 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  9 
>  drivers/gpu/drm/i915/intel_dp.c  | 48 
> 
>  drivers/gpu/drm/i915/intel_drv.h |  1 +
>  drivers/gpu/drm/i915/intel_psr.c |  6 +
>  4 files changed, 64 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index f6afa5e5e7c1..5d7736117cb9 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5318,6 +5318,7 @@ enum {
>  #define _DPA_AUX_CH_DATA3(dev_priv->info.display_mmio_offset + 0x6401c)
>  #define _DPA_AUX_CH_DATA4(dev_priv->info.display_mmio_offset + 0x64020)
>  #define _DPA_AUX_CH_DATA5(dev_priv->info.display_mmio_offset + 0x64024)
> +#define _DPA_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6402C)
>  
>  #define _DPB_AUX_CH_CTL  (dev_priv->info.display_mmio_offset + 
> 0x64110)
>  #define _DPB_AUX_CH_DATA1(dev_priv->info.display_mmio_offset + 0x64114)
> @@ -5325,6 +5326,7 @@ enum {
>  #define _DPB_AUX_CH_DATA3(dev_priv->info.display_mmio_offset + 0x6411c)
>  #define _DPB_AUX_CH_DATA4(dev_priv->info.display_mmio_offset + 0x64120)
>  #define _DPB_AUX_CH_DATA5(dev_priv->info.display_mmio_offset + 0x64124)
> +#define _DPB_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6412C)
>  
>  #define _DPC_AUX_CH_CTL  (dev_priv->info.display_mmio_offset + 
> 0x64210)
>  #define _DPC_AUX_CH_DATA1(dev_priv->info.display_mmio_offset + 0x64214)
> @@ -5332,6 +5334,7 @@ enum {
>  #define _DPC_AUX_CH_DATA3(dev_priv->info.display_mmio_offset + 0x6421c)
>  #define _DPC_AUX_CH_DATA4(dev_priv->info.display_mmio_offset + 0x64220)
>  #define _DPC_AUX_CH_DATA5(dev_priv->info.display_mmio_offset + 0x64224)
> +#define _DPC_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6422C)
>  
>  #define _DPD_AUX_CH_CTL  (dev_priv->info.display_mmio_offset + 
> 0x64310)
>  #define _DPD_AUX_CH_DATA1(dev_priv->info.display_mmio_offset + 0x64314)
> @@ -5339,6 +5342,7 @@ enum {
>  #define _DPD_AUX_CH_DATA3(dev_priv->info.display_mmio_offset + 0x6431c)
>  #define _DPD_AUX_CH_DATA4(dev_priv->info.display_mmio_offset + 0x64320)
>  #define _DPD_AUX_CH_DATA5(dev_priv->info.display_mmio_offset + 0x64324)
> +#define _DPD_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6432C)
>  
>  #define _DPF_AUX_CH_CTL  (dev_priv->info.display_mmio_offset + 
> 0x64510)
>  #define _DPF_AUX_CH_DATA1(dev_priv->info.display_mmio_offset + 0x64514)
> @@ -5346,9 +5350,11 @@ enum {
>  #define _DPF_AUX_CH_DATA3(dev_priv->info.display_mmio_offset + 0x6451c)
>  #define _DPF_AUX_CH_DATA4(dev_priv->info.display_mmio_offset + 0x64520)
>  #define _DPF_AUX_CH_DATA5(dev_priv->info.display_mmio_offset + 0x64524)
> +#define _DPF_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6452C)
>  
>  #define DP_AUX_CH_CTL(port)  _MMIO_PORT(port, _DPA_AUX_CH_CTL, 
> _DPB_AUX_CH_CTL)
>  #define DP_AUX_CH_DATA(port, i)  _MMIO(_PORT(port, _DPA_AUX_CH_DATA1, 
> _DPB_AUX_CH_DATA1) + (i) * 4) /* 5 registers */
> +#define DP_AUX_CH_MUTEX(port)_MMIO_PORT(port, _DPA_AUX_CH_MUTEX, 
> _DPB_AUX_CH_MUTEX)
>  
>  #define   DP_AUX_CH_CTL_SEND_BUSY(1 << 31)
>  #define   DP_AUX_CH_CTL_DONE (1 << 30)
> @@ -5378,6 +5384,9 @@ enum {
>  #define   DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(c) (((c) - 1) << 5)
>  #define   DP_AUX_CH_CTL_SYNC_PULSE_SKL(c)   ((c) - 1)
>  
> +#define   DP_AUX_CH_MUTEX_ENABLE (1 << 31)
> +#define   DP_AUX_CH_MUTEX_STATUS (1 << 30)
> +
>  /*
>   * Computing GMCH M and N values for the Display Port link
>   *
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index f20b25f98e5a..bd5f1bb730ff 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1081,6 +1081,28 @@ static uint32_t intel_dp_get_aux_send_ctl(struct 
> intel_dp *intel_dp,
>   aux_clock_divider);
>  }
>  
> +static bool intel_dp_aux_get(struct drm_i915_private *dev_priv,
> +  struct intel_dp *intel_dp)
> +{
> + int 

Re: [Intel-gfx] [PATCH v10 6/7] drm/i915/guc: Check the locking status of GuC WOPCM registers

[Yaodong Li]

On 02/13/2018 09:39 AM, Michal Wajdeczko wrote:


+
+static inline u32 lockable_reg_read(struct lockable_reg *lreg)
+{
+    struct drm_i915_private *dev_priv = guc_to_i915(lreg->guc);
+
+    lreg->reg_val = I915_READ(lreg->reg);
+
+    return lreg->reg_val;
+}
+
+static inline bool lockable_reg_validate(struct lockable_reg *lreg, 
u32 new_val)

+{
+    GEM_BUG_ON(!lreg->validate);
+
+    return lreg->validate(lreg, lreg->reg_val, new_val);
+}
+
+static inline bool lockable_reg_locked(struct lockable_reg *lreg)
+{
+    u32 reg_val = lockable_reg_read(lreg);
+
+    return reg_val & lreg->lock_bit;
+}
+
+static inline bool lockable_reg_locked_and_valid(struct lockable_reg 
*lreg,

+ u32 new_val)
+{
+    if (lockable_reg_locked(lreg)) {
+    if (lockable_reg_validate(lreg, new_val))
+    return true;
+
+    return false;
+    }
+
+    return false;
+}
+
+static inline bool lockable_reg_write(struct lockable_reg *lreg, u32 
val)

+{
+    struct drm_i915_private *dev_priv = guc_to_i915(lreg->guc);
+
+    /*
+ * Write-once register was locked which may happen with either a 
faulty
+ * BIOS code or driver module reloading. We should still return 
success

+ * for the write if the register was locked with a valid value.
+ */
+    if (lockable_reg_locked(lreg)) {
+    if (lockable_reg_validate(lreg, val))
+    goto out;
+
+    DRM_DEBUG_DRIVER("Register %s was locked with invalid value\n",
+ lreg->name);
+
+    return false;
+    }
+
+    I915_WRITE(lreg->reg, val);
+
+    if (!lockable_reg_locked_and_valid(lreg, val)) {
+    DRM_DEBUG_DRIVER("Failed to lock Register %s\n", lreg->name);
+    return false;
+    }


As we acknowledge that there are scenarios where registers can be already
locked, do we really need to make our code so complex ? Maybe

int write_and_verify(struct drm_i915_private *dev_priv,
 i915_reg_t reg, u32 value, u32 locked_bit)
{
I915_WRITE(reg, value);

return I915_READ(reg) != (value | locked_bit) ? -EIO : 0;
}


Yes, I agree it's too complex at least for the validation part. Thanks!

My intention was trying to avoid extra write once we found the reg
was locked and to distinguish between faulty SW behavior and
hardware locking error? but now I feel it's not worth it.:-(

+
+
+#define DEFINE_LOCKABLE_REG(var, rg, lb, func)    \
+    struct lockable_reg var = {    \
+    .name = #rg,    \
+    .guc = guc_wopcm_to_guc(guc_wopcm),    \


btw, implicit macro params are evil...

Agree. but seems we always use similar approach in
I915_READ/WRITE().O:-)

+    .reg = rg,    \
+    .reg_val = 0,    \
+    .lock_bit = lb,    \
+    .validate = func,    \


...and macro names should be always wrapped into ()


Thanks!
diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.h 
b/drivers/gpu/drm/i915/intel_guc_wopcm.h

index 13fcab6..89dd44c 100644
--- a/drivers/gpu/drm/i915/intel_guc_wopcm.h
+++ b/drivers/gpu/drm/i915/intel_guc_wopcm.h
@@ -66,7 +66,8 @@ struct intel_guc;
  * @offset: GuC WOPCM offset from the WOPCM base.
  * @size: size of GuC WOPCM for GuC firmware.
  * @top: start of the non-GuC WOPCM memory.
- * @valid: whether this structure contains valid (1-valid, 
0-invalid) info.

+ * @valid: whether the values in this struct are valid.
+ * @load_huc_fw: whether need to configure GuC to load HuC firmware.


I'm not sure that we need to track this flag inside structure.
It is just a parameter for doing partitioning and final check.


I think it's related to actual reg configuration. Any suggestions since
we do need it in hw_init to setup offset reg?

As mentioned before, we can avoid this flag and "valid" flag if do
partitioning and validation *before* writing final results to the
struct.
In current code, we do verify the ggtt offset against wopcm top in our 
current code which means
current code won't trust the fact that ggtt offset would never be used 
after uc/guc init failed.
This is the reason for this valid bit (which clearly suggests the struct 
is ready to use) - I won't
assume the ggtt_offset would never be called even if the uc/guc_init 
returned failure.



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

Re: [Intel-gfx] [PATCH 2/5] drm/i915: keep AUX powered while PSR is enabled

[Rodrigo Vivi]

José Roberto de Souza  writes:

> Hardware can send AUX transactions by it self when PSR is enabled and it
> expects that AUX is kept powered up.
>
> From spec:
>
> "Each DisplayPort Aux channel has an Aux IO Power Request. If an Aux
> channel will not be used, it does not need to be powered up.
>
> PSR spontaneously sends Aux transactions.  If PSR is enabled on a port,
> then the associated Aux IO must be kept powered up."
>
> BSpec: 4230
> BSpec: 17722

It seems here this is only needed for AUX IO PWs.
So maybe for that we would need some thing like POWER_DOMAIN_PSR_AUX_* that is
part of {GLK,CNL}_DISPLAY_AUX_*_POWER_DOMAINS

So here we would get and put the specific PSR_AUX ones instead of the
whole dp aux. We don't need to keep the entire well up apparently.
At least I hope we don't.

>
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/intel_psr.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 8b456e4e1b47..225fde979e57 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -516,6 +516,12 @@ void intel_psr_enable(struct intel_dp *intel_dp,
>   goto unlock;
>   }
>  
> + /*
> +  * hardware can send AUX transactions by it self when PSR is enabled,
> +  * and it expects that AUX is kept powered up.
> +  */
> + intel_display_power_get(dev_priv, intel_dp->aux_power_domain);
> +
>   dev_priv->psr.psr2_support = crtc_state->has_psr2;
>   dev_priv->psr.busy_frontbuffer_bits = 0;
>  
> @@ -656,6 +662,8 @@ void intel_psr_disable(struct intel_dp *intel_dp,
>   /* Disable PSR on Sink */
>   drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, 0);
>  
> + intel_display_power_put(dev_priv, intel_dp->aux_power_domain);
> +
>   dev_priv->psr.enabled = NULL;
>   mutex_unlock(_priv->psr.lock);
>  
> -- 
> 2.16.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/breadcrumbs: Ignore unsubmitted signalers

[Rodrigo Vivi]

On Tue, Feb 13, 2018 at 09:01:54AM +, Chris Wilson wrote:
> When a request is preempted, it is unsubmitted from the HW queue and
> removed from the active list of breadcrumbs. In the process, this
> however triggers the signaler and it may see the clear rbtree with the
> old, and still valid, seqno, or it may match the cleared seqno with the
> now zero rq->global_seqno. This confuses the signaler into action and
> signaling the fence.
> 
> Fixes: d6a2289d9d6b ("drm/i915: Remove the preempted request from the 
> execution queue")
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Joonas Lahtinen 
> Cc:  # v4.12+
> Reviewed-by: Tvrtko Ursulin 
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20180206094633.30181-1-ch...@chris-wilson.co.uk
> (cherry picked from commit fd10e2ce9905030d922e179a8047a4d50daffd8e)

applied to fixes. Thanks

> ---
>  drivers/gpu/drm/i915/intel_breadcrumbs.c | 29 ++---
>  1 file changed, 10 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
> b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> index bd40fea16b4f..f54ddda9fdad 100644
> --- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
> +++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> @@ -594,29 +594,16 @@ void intel_engine_remove_wait(struct intel_engine_cs 
> *engine,
>   spin_unlock_irq(>rb_lock);
>  }
>  
> -static bool signal_valid(const struct drm_i915_gem_request *request)
> -{
> - return intel_wait_check_request(>signaling.wait, request);
> -}
> -
>  static bool signal_complete(const struct drm_i915_gem_request *request)
>  {
>   if (!request)
>   return false;
>  
> - /* If another process served as the bottom-half it may have already
> -  * signalled that this wait is already completed.
> -  */
> - if (intel_wait_complete(>signaling.wait))
> - return signal_valid(request);
> -
> - /* Carefully check if the request is complete, giving time for the
> + /*
> +  * Carefully check if the request is complete, giving time for the
>* seqno to be visible or if the GPU hung.
>*/
> - if (__i915_request_irq_complete(request))
> - return true;
> -
> - return false;
> + return __i915_request_irq_complete(request);
>  }
>  
>  static struct drm_i915_gem_request *to_signaler(struct rb_node *rb)
> @@ -659,9 +646,13 @@ static int intel_breadcrumbs_signaler(void *arg)
>   request = i915_gem_request_get_rcu(request);
>   rcu_read_unlock();
>   if (signal_complete(request)) {
> - local_bh_disable();
> - dma_fence_signal(>fence);
> - local_bh_enable(); /* kick start the tasklets */
> + if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
> +   >fence.flags)) {
> + local_bh_disable();
> + dma_fence_signal(>fence);
> + 
> GEM_BUG_ON(!i915_gem_request_completed(request));
> + local_bh_enable(); /* kick start the tasklets */
> + }
>  
>   spin_lock_irq(>rb_lock);
>  
> -- 
> 2.16.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] drm/i915/pmu: Fix building without CONFIG_PM

[Rodrigo Vivi]

On Tue, Feb 13, 2018 at 09:57:47AM +, Tvrtko Ursulin wrote:
> From: Chris Wilson 
> 
> As we peek inside struct device to query members guarded by CONFIG_PM,
> so must be the code.
> 
> Reported-by: kbuild test robot 
> Fixes: 1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Reviewed-by: Tvrtko Ursulin 
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20180207160428.17015-1-ch...@chris-wilson.co.uk
> (cherry picked from commit 05273c950a3c93c5f96be8807eaf24f2cc9f1c1e)

All 4 patches applied to fixes.
Thanks for backporting and for adding cherry-picked message.

> ---
>  drivers/gpu/drm/i915/i915_pmu.c | 33 +++--
>  1 file changed, 23 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index e13859aaa2a3..0e9b98c32b62 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -409,22 +409,32 @@ static int i915_pmu_event_init(struct perf_event *event)
>   return 0;
>  }
>  
> -static u64 get_rc6(struct drm_i915_private *i915, bool locked)
> +static u64 __get_rc6(struct drm_i915_private *i915)
>  {
> - unsigned long flags;
>   u64 val;
>  
> - if (intel_runtime_pm_get_if_in_use(i915)) {
> - val = intel_rc6_residency_ns(i915, IS_VALLEYVIEW(i915) ?
> -VLV_GT_RENDER_RC6 :
> -GEN6_GT_GFX_RC6);
> + val = intel_rc6_residency_ns(i915,
> +  IS_VALLEYVIEW(i915) ?
> +  VLV_GT_RENDER_RC6 :
> +  GEN6_GT_GFX_RC6);
>  
> - if (HAS_RC6p(i915))
> - val += intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6p);
> + if (HAS_RC6p(i915))
> + val += intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6p);
> +
> + if (HAS_RC6pp(i915))
> + val += intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6pp);
> +
> + return val;
> +}
>  
> - if (HAS_RC6pp(i915))
> - val += intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6pp);
> +static u64 get_rc6(struct drm_i915_private *i915, bool locked)
> +{
> +#if IS_ENABLED(CONFIG_PM)
> + unsigned long flags;
> + u64 val;
>  
> + if (intel_runtime_pm_get_if_in_use(i915)) {
> + val = __get_rc6(i915);
>   intel_runtime_pm_put(i915);
>  
>   /*
> @@ -481,6 +491,9 @@ static u64 get_rc6(struct drm_i915_private *i915, bool 
> locked)
>   }
>  
>   return val;
> +#else
> + return __get_rc6(i915);
> +#endif
>  }
>  
>  static u64 __i915_pmu_event_read(struct perf_event *event, bool locked)
> -- 
> 2.14.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v10 5/7] drm/i915/guc: Add HuC firmware size related restriction for Gen9 and CNL A0

[Yaodong Li]

On 02/13/2018 02:59 PM, Michal Wajdeczko wrote:
Hmm, that only proves that current partitioning code is too 
complicated :)

If you look at diagram it should be possible to implement it as

current calculation tries to set the maximum available WOPCM to avoid
Gen9 limitations. that the reason I didn't use guc_fw_size + 
GUC_WOPCM_RESERVED

for size calculation.:-)


guc_base = ALIGN(huc_fw_size + WOPCM_RESERVED, KiB(16));

the same as current calculation.

guc_size = ALIGN(guc_fw_size + GUC_WOPCM_RESERVED, KiB(4))

it's sample but likely run into gen9 gaps HW restriction.:-)

reserved = context_reserved_size(i915);

if (guc_base + guc_size + reserved > WOPCM_DEFAULT_SIZE)
return -E2BIG;

(E)



@@ -121,7 +139,7 @@ int intel_guc_wopcm_init(struct intel_guc_wopcm 
*guc_wopcm, u32 guc_fw_size,

 guc->wopcm.size = size;
 guc->wopcm.top = top;
-    err = guc_wopcm_size_check(guc);
+    err = guc_wopcm_size_check(guc, huc_fw_size);
 if (err) {
 DRM_DEBUG_DRIVER("GuC WOPCM size check failed.\n");
 return err;


I'm more and more convinced that we should use "intel_wopcm" to make
partition and all these checks

These are all GuC wopcm related, it only checks guc wopcm size. so I 
am wondering whether
I am still misunderstanding anything here?since the purpose of these 
calculation and checks are
clearly all GuC related. To be more precisely GuC DMA related. The 
driver's responsibility is to
calculate the GuC DMA offset and GuC wopcm size values based on 
guc/huc fw sizes and

all these checks are all for the correctness for the GuC  wopcm size.
I don't see any reason why these should be a part of global 
intel_wopcm even if we really
want to keep something like wopcm_regions for both guc/huc(though I 
still don't know what
the benefit real is to keep something like HuC wopcm region except 
for sth like debugfs output?).
even in this case, we still at least keep these as a part of GuC 
since we really need it to setup
GuC HW :- Or do you mean we should create an intel_wopcm to carry 
info such as
global WOPCM size,guc_fw_size and huc_fw_size? Sorry I am really a 
little bit confused here:-(


struct intel_wopcm should carry only results of WOPCM partitioning 
between

all agents including GuC. There is no need to carry fw sizes as those are
only needed as input for calculations.

I understand the point. but what I am trying to explain is that we can 
only focus on GuC WOPCM setting since there's no
need to keep tracking other regions since they are just results of 
setting of GuC WOPCM registers (what we are
trying to do is to figure out a window on the WOPCM for GuC, and we 
don't need to keep tracking info such as
HuC WOPCM size, CTX reserved WOPCM size because KMD driver won't use 
these info anymore).


If you do think it's clearer to have something like 
intel_uc_wopcm.h/intel_uc_wopcm.c I can sure make these changes,
but what I am saying is we won't need to keep likely unused info data in 
KMD. And we always can treat the other parts
of WOPCM as reserved for other HW use. and only take care of what KMD 
needs to do. Please let me know if you

still think we should have something like uc_wopcm. I will work it out.

Regards,
-Jackie






___
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/5] drm/i915: add and enable DP AUX CH mutex

[Patchwork]

== Series Details ==

Series: series starting with [1/5] drm/i915: add and enable DP AUX CH mutex
URL   : https://patchwork.freedesktop.org/series/38201/
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
  DESCEND  objtool
  CHK scripts/mod/devicetable-offsets.h
  CHK include/generated/compile.h
  CHK kernel/config_data.h
  CC [M]  drivers/gpu/drm/i915/intel_dp.o
drivers/gpu/drm/i915/intel_dp.c: In function ‘intel_dp_aux_ch’:
drivers/gpu/drm/i915/intel_dp.c:1290:2: error: expected expression before ‘}’ 
token
  }
  ^
scripts/Makefile.build:316: recipe for target 'drivers/gpu/drm/i915/intel_dp.o' 
failed
make[4]: *** [drivers/gpu/drm/i915/intel_dp.o] Error 1
scripts/Makefile.build:575: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:575: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:575: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1048: 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/2] drm/i915/psr2: Fix max resolution supported.

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/psr2: Fix max resolution supported.
URL   : https://patchwork.freedesktop.org/series/38200/
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
  DESCEND  objtool
  CHK scripts/mod/devicetable-offsets.h
  CHK include/generated/compile.h
  CHK kernel/config_data.h
  CC [M]  drivers/gpu/drm/i915/intel_psr.o
drivers/gpu/drm/i915/intel_psr.c: In function ‘intel_psr_compute_config’:
drivers/gpu/drm/i915/intel_psr.c:432:23: error: void value not ignored as it 
ought to be
  crtc_state->has_psr2 = intel_psr2_conditions(intel_dp, crtc_state);
   ^
scripts/Makefile.build:316: recipe for target 
'drivers/gpu/drm/i915/intel_psr.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_psr.o] Error 1
scripts/Makefile.build:575: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:575: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:575: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1048: 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] [PATCH 3/5] drm/i915: Share PSR and PSR2 VSC setup

[José Roberto de Souza]

Just share the common code in PSR and PSR2.

Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_psr.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 225fde979e57..60ca39d3b226 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -88,11 +88,12 @@ static void hsw_psr_setup_vsc(struct intel_dp *intel_dp,
struct drm_i915_private *dev_priv = 
to_i915(intel_dig_port->base.base.dev);
struct edp_vsc_psr psr_vsc;
 
+   memset(_vsc, 0, sizeof(psr_vsc));
+   psr_vsc.sdp_header.HB0 = 0;
+   psr_vsc.sdp_header.HB1 = 0x7;
+
if (dev_priv->psr.psr2_support) {
/* Prepare VSC Header for SU as per EDP 1.4 spec, Table 6.11 */
-   memset(_vsc, 0, sizeof(psr_vsc));
-   psr_vsc.sdp_header.HB0 = 0;
-   psr_vsc.sdp_header.HB1 = 0x7;
if (dev_priv->psr.colorimetry_support &&
dev_priv->psr.y_cord_support) {
psr_vsc.sdp_header.HB2 = 0x5;
@@ -106,9 +107,6 @@ static void hsw_psr_setup_vsc(struct intel_dp *intel_dp,
}
} else {
/* Prepare VSC packet as per EDP 1.3 spec, Table 3.10 */
-   memset(_vsc, 0, sizeof(psr_vsc));
-   psr_vsc.sdp_header.HB0 = 0;
-   psr_vsc.sdp_header.HB1 = 0x7;
psr_vsc.sdp_header.HB2 = 0x2;
psr_vsc.sdp_header.HB3 = 0x8;
}
-- 
2.16.1

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

[Intel-gfx] [PATCH 1/5] drm/i915: add and enable DP AUX CH mutex

[José Roberto de Souza]

When PSR/PSR2 is enabled hardware can do AUX transactions by it self, so
lets use the mutex register that is available in gen9+ to avoid concurrent
access by hardware and driver.

Reference: 
https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol12-display.pdf
Page 198 - AUX programming sequence

As gen < 9 don't have the mutex PSR needs to be disabled, that is why the
'else TODO' was added. This is also backed by spec:
"DDI A AUX channel transactions must not be sent while SRD is enabled.
SRD must be completely disabled before a DDI A AUX channel transaction can
be sent." BSpec: 7530

Cc: Rodrigo Vivi 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_reg.h  |  9 
 drivers/gpu/drm/i915/intel_dp.c  | 48 
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_psr.c |  6 +
 4 files changed, 64 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f6afa5e5e7c1..5d7736117cb9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5318,6 +5318,7 @@ enum {
 #define _DPA_AUX_CH_DATA3  (dev_priv->info.display_mmio_offset + 0x6401c)
 #define _DPA_AUX_CH_DATA4  (dev_priv->info.display_mmio_offset + 0x64020)
 #define _DPA_AUX_CH_DATA5  (dev_priv->info.display_mmio_offset + 0x64024)
+#define _DPA_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6402C)
 
 #define _DPB_AUX_CH_CTL(dev_priv->info.display_mmio_offset + 
0x64110)
 #define _DPB_AUX_CH_DATA1  (dev_priv->info.display_mmio_offset + 0x64114)
@@ -5325,6 +5326,7 @@ enum {
 #define _DPB_AUX_CH_DATA3  (dev_priv->info.display_mmio_offset + 0x6411c)
 #define _DPB_AUX_CH_DATA4  (dev_priv->info.display_mmio_offset + 0x64120)
 #define _DPB_AUX_CH_DATA5  (dev_priv->info.display_mmio_offset + 0x64124)
+#define _DPB_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6412C)
 
 #define _DPC_AUX_CH_CTL(dev_priv->info.display_mmio_offset + 
0x64210)
 #define _DPC_AUX_CH_DATA1  (dev_priv->info.display_mmio_offset + 0x64214)
@@ -5332,6 +5334,7 @@ enum {
 #define _DPC_AUX_CH_DATA3  (dev_priv->info.display_mmio_offset + 0x6421c)
 #define _DPC_AUX_CH_DATA4  (dev_priv->info.display_mmio_offset + 0x64220)
 #define _DPC_AUX_CH_DATA5  (dev_priv->info.display_mmio_offset + 0x64224)
+#define _DPC_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6422C)
 
 #define _DPD_AUX_CH_CTL(dev_priv->info.display_mmio_offset + 
0x64310)
 #define _DPD_AUX_CH_DATA1  (dev_priv->info.display_mmio_offset + 0x64314)
@@ -5339,6 +5342,7 @@ enum {
 #define _DPD_AUX_CH_DATA3  (dev_priv->info.display_mmio_offset + 0x6431c)
 #define _DPD_AUX_CH_DATA4  (dev_priv->info.display_mmio_offset + 0x64320)
 #define _DPD_AUX_CH_DATA5  (dev_priv->info.display_mmio_offset + 0x64324)
+#define _DPD_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6432C)
 
 #define _DPF_AUX_CH_CTL(dev_priv->info.display_mmio_offset + 
0x64510)
 #define _DPF_AUX_CH_DATA1  (dev_priv->info.display_mmio_offset + 0x64514)
@@ -5346,9 +5350,11 @@ enum {
 #define _DPF_AUX_CH_DATA3  (dev_priv->info.display_mmio_offset + 0x6451c)
 #define _DPF_AUX_CH_DATA4  (dev_priv->info.display_mmio_offset + 0x64520)
 #define _DPF_AUX_CH_DATA5  (dev_priv->info.display_mmio_offset + 0x64524)
+#define _DPF_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6452C)
 
 #define DP_AUX_CH_CTL(port)_MMIO_PORT(port, _DPA_AUX_CH_CTL, 
_DPB_AUX_CH_CTL)
 #define DP_AUX_CH_DATA(port, i)_MMIO(_PORT(port, _DPA_AUX_CH_DATA1, 
_DPB_AUX_CH_DATA1) + (i) * 4) /* 5 registers */
+#define DP_AUX_CH_MUTEX(port)  _MMIO_PORT(port, _DPA_AUX_CH_MUTEX, 
_DPB_AUX_CH_MUTEX)
 
 #define   DP_AUX_CH_CTL_SEND_BUSY  (1 << 31)
 #define   DP_AUX_CH_CTL_DONE   (1 << 30)
@@ -5378,6 +5384,9 @@ enum {
 #define   DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(c) (((c) - 1) << 5)
 #define   DP_AUX_CH_CTL_SYNC_PULSE_SKL(c)   ((c) - 1)
 
+#define   DP_AUX_CH_MUTEX_ENABLE   (1 << 31)
+#define   DP_AUX_CH_MUTEX_STATUS   (1 << 30)
+
 /*
  * Computing GMCH M and N values for the Display Port link
  *
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f20b25f98e5a..bd5f1bb730ff 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1081,6 +1081,28 @@ static uint32_t intel_dp_get_aux_send_ctl(struct 
intel_dp *intel_dp,
aux_clock_divider);
 }
 
+static bool intel_dp_aux_get(struct drm_i915_private *dev_priv,
+struct intel_dp *intel_dp)
+{
+   int try, ret;
+
+   for (try = 0, ret = -1; try < 3 && ret; try++)
+   ret = wait_for(!(I915_READ_NOTRACE(intel_dp->aux_ch_mutex_reg)
+& 

[Intel-gfx] [PATCH 2/5] drm/i915: keep AUX powered while PSR is enabled

[José Roberto de Souza]

Hardware can send AUX transactions by it self when PSR is enabled and it
expects that AUX is kept powered up.

From spec:

"Each DisplayPort Aux channel has an Aux IO Power Request. If an Aux
channel will not be used, it does not need to be powered up.

PSR spontaneously sends Aux transactions.  If PSR is enabled on a port,
then the associated Aux IO must be kept powered up."

BSpec: 4230
BSpec: 17722

Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_psr.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 8b456e4e1b47..225fde979e57 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -516,6 +516,12 @@ void intel_psr_enable(struct intel_dp *intel_dp,
goto unlock;
}
 
+   /*
+* hardware can send AUX transactions by it self when PSR is enabled,
+* and it expects that AUX is kept powered up.
+*/
+   intel_display_power_get(dev_priv, intel_dp->aux_power_domain);
+
dev_priv->psr.psr2_support = crtc_state->has_psr2;
dev_priv->psr.busy_frontbuffer_bits = 0;
 
@@ -656,6 +662,8 @@ void intel_psr_disable(struct intel_dp *intel_dp,
/* Disable PSR on Sink */
drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, 0);
 
+   intel_display_power_put(dev_priv, intel_dp->aux_power_domain);
+
dev_priv->psr.enabled = NULL;
mutex_unlock(_priv->psr.lock);
 
-- 
2.16.1

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

[Intel-gfx] [PATCH 5/5] drm/i915: Make use of unused variable in hsw_write_infoframe()

[José Roberto de Souza]

data_reg was not being used but it can be used to reduce the number of
calls to hsw_dip_data_reg() and just increment the reg by the size of
uint32.

Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index f5d7bfb43006..ef258eac8ae8 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -393,15 +393,11 @@ static void hsw_write_infoframe(struct drm_encoder 
*encoder,
I915_WRITE(ctl_reg, val);
 
mmiowb();
-   for (i = 0; i < len; i += 4) {
-   I915_WRITE(hsw_dip_data_reg(dev_priv, cpu_transcoder,
-   type, i >> 2), *data);
-   data++;
-   }
+   for (i = 0; i < len; i += 4, data++, data_reg.reg += 4)
+   I915_WRITE(data_reg, *data);
/* Write every possible data byte to force correct ECC calculation. */
-   for (; i < data_size; i += 4)
-   I915_WRITE(hsw_dip_data_reg(dev_priv, cpu_transcoder,
-   type, i >> 2), 0);
+   for (; i < data_size; i += 4, data_reg.reg += 4)
+   I915_WRITE(data_reg, 0);
mmiowb();
 
val |= hsw_infoframe_enable(type);
-- 
2.16.1

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

[Intel-gfx] [PATCH 4/5] drm/i915: Replace magic number with macro defined by drm

[José Roberto de Souza]

Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_psr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 60ca39d3b226..c24afc73e30b 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -90,7 +90,7 @@ static void hsw_psr_setup_vsc(struct intel_dp *intel_dp,
 
memset(_vsc, 0, sizeof(psr_vsc));
psr_vsc.sdp_header.HB0 = 0;
-   psr_vsc.sdp_header.HB1 = 0x7;
+   psr_vsc.sdp_header.HB1 = DP_SDP_VSC;
 
if (dev_priv->psr.psr2_support) {
/* Prepare VSC Header for SU as per EDP 1.4 spec, Table 6.11 */
-- 
2.16.1

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

[Intel-gfx] [PATCH 2/2] drm/i915/psr: Don't avoid PSR when PSR2 conditions are not met.

[Rodrigo Vivi]

We can still use PSR1 when PSR2 conditions are not met.

So, let's split the check in a way that we make sure has_psr
gets set independently of PSR2 criteria.

Cc: Dhinakaran Pandiyan 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_psr.c | 53 
 1 file changed, 26 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 3d341a44e720..626d62d7d567 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -341,6 +341,31 @@ static void hsw_psr_activate(struct intel_dp *intel_dp)
hsw_activate_psr1(intel_dp);
 }
 
+static void intel_psr2_conditions(struct intel_dp *intel_dp,
+ struct intel_crtc_state *crtc_state)
+{
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
+   const struct drm_display_mode *adjusted_mode =
+   _state->base.adjusted_mode;
+
+   /* PSR2 is restricted to work with panel resolutions up to 3640x2304 */
+   if (adjusted_mode->crtc_hdisplay > 3640 ||
+   adjusted_mode->crtc_vdisplay > 2304) {
+   DRM_DEBUG_KMS("PSR2 disabled, panel resolution too big\n");
+   return;
+   }
+
+   /*
+* FIXME:enable psr2 only for y-cordinate psr2 panels
+* After gtc implementation , remove this restriction.
+*/
+   if (!dev_priv->psr.y_cord_support) {
+   DRM_DEBUG_KMS("PSR2 disabled, panel does not support Y 
coordinate\n");
+   return;
+   }
+}
+
 void intel_psr_compute_config(struct intel_dp *intel_dp,
  struct intel_crtc_state *crtc_state)
 {
@@ -403,34 +428,8 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
return;
}
 
-   /*
-* FIXME psr2_support is messed up. It's both computed
-* dynamically during PSR enable, and extracted from sink
-* caps during eDP detection.
-*/
-   if (!dev_priv->psr.psr2_support) {
-   crtc_state->has_psr = true;
-   return;
-   }
-
-   /* PSR2 is restricted to work with panel resolutions up to 3640x2304 */
-   if (adjusted_mode->crtc_hdisplay > 3640 ||
-   adjusted_mode->crtc_vdisplay > 2304) {
-   DRM_DEBUG_KMS("PSR2 disabled, panel resolution too big\n");
-   return;
-   }
-
-   /*
-* FIXME:enable psr2 only for y-cordinate psr2 panels
-* After gtc implementation , remove this restriction.
-*/
-   if (!dev_priv->psr.y_cord_support) {
-   DRM_DEBUG_KMS("PSR2 disabled, panel does not support Y 
coordinate\n");
-   return;
-   }
-
crtc_state->has_psr = true;
-   crtc_state->has_psr2 = true;
+   crtc_state->has_psr2 = intel_psr2_conditions(intel_dp, crtc_state);
 }
 
 static void intel_psr_activate(struct intel_dp *intel_dp)
-- 
2.13.6

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

[Intel-gfx] [PATCH 1/2] drm/i915/psr2: Fix max resolution supported.

[Rodrigo Vivi]

According to spec:
"PSR2 is supported for pipe active sizes up to
3640 pixels wide and 2304 lines tall."

BSpec: 7713

Cc: Dhinakaran Pandiyan 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_psr.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 7cd4b82c6a75..3d341a44e720 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -413,9 +413,9 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
return;
}
 
-   /* PSR2 is restricted to work with panel resolutions upto 3200x2000 */
-   if (adjusted_mode->crtc_hdisplay > 3200 ||
-   adjusted_mode->crtc_vdisplay > 2000) {
+   /* PSR2 is restricted to work with panel resolutions up to 3640x2304 */
+   if (adjusted_mode->crtc_hdisplay > 3640 ||
+   adjusted_mode->crtc_vdisplay > 2304) {
DRM_DEBUG_KMS("PSR2 disabled, panel resolution too big\n");
return;
}
-- 
2.13.6

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

Re: [Intel-gfx] [PATCH v2] drm/i915/psr: HW tracking for cursor moves to fix lags.

[Pandiyan, Dhinakaran]

On Tue, 2018-02-13 at 22:59 +, Chris Wilson wrote:
> Quoting Pandiyan, Dhinakaran (2018-02-13 22:45:55)
> > 
> > 
> > 
> > On Tue, 2018-02-13 at 22:15 +, Chris Wilson wrote:
> > > Quoting Pandiyan, Dhinakaran (2018-02-13 22:10:48)
> > > > 
> > > > 
> > > > 
> > > > On Tue, 2018-02-13 at 21:54 +, Chris Wilson wrote:
> > > > > Quoting Dhinakaran Pandiyan (2018-02-13 21:46:13)
> > > > > > DRM_IOCTL_MODE_CURSOR results in a frontbuffer flush before the 
> > > > > > cursor
> > > > > > plane MMIOs are written to. But this flush is not necessary for PSR 
> > > > > > as
> > > > > > hardware tracking takes care of exiting PSR when the MMIO's are 
> > > > > > written.
> > > > > > 
> > > > > > Introduce a new fb_op_origin enum to differentiate flushes due to a 
> > > > > > BO
> > > > > > being pinned from those originating due to a dirty fbdev buffer. 
> > > > > > Now, this
> > > > > > enum can be ignored in psr_flush and psr_invalidate.
> > > > > > 
> > > > > > v2: Update comment in i915_gem_object_pin_to_display_plane. (Chris)
> > > > > > 
> > > > > > Cc: Rodrigo Vivi 
> > > > > > Cc: Ville Syrjälä 
> > > > > > Cc: Chris Wilson 
> > > > > > Signed-off-by: Dhinakaran Pandiyan 
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/i915_drv.h  |  1 +
> > > > > >  drivers/gpu/drm/i915/i915_gem.c  | 11 +--
> > > > > >  drivers/gpu/drm/i915/intel_psr.c |  6 --
> > > > > >  3 files changed, 14 insertions(+), 4 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > index 81886b74c750..3bf6c6ec0509 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > @@ -637,6 +637,7 @@ enum fb_op_origin {
> > > > > > ORIGIN_CS,
> > > > > > ORIGIN_FLIP,
> > > > > > ORIGIN_DIRTYFB,
> > > > > > +   ORIGIN_PINNEDFB,
> > > > > >  };
> > > > > >  
> > > > > >  struct intel_fbc {
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > > > > > b/drivers/gpu/drm/i915/i915_gem.c
> > > > > > index fc68b35854df..405acf3562de 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > > > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > > > > @@ -4139,9 +4139,16 @@ i915_gem_object_pin_to_display_plane(struct 
> > > > > > drm_i915_gem_object *obj,
> > > > > >  
> > > > > > vma->display_alignment = max_t(u64, vma->display_alignment, 
> > > > > > alignment);
> > > > > >  
> > > > > > -   /* Treat this as an end-of-frame, like 
> > > > > > intel_user_framebuffer_dirty() */
> > > > > > +   /* Treat this as an end-of-frame, like 
> > > > > > intel_user_framebuffer_dirty() to
> > > > > > +* flush the caches.
> > > > > > +*/
> > > > > > __i915_gem_object_flush_for_display(obj);
> > > > > > -   intel_fb_obj_flush(obj, ORIGIN_DIRTYFB);
> > > > > > +
> > > > > > +   /* Features like PSR might want to rely on HW to do the 
> > > > > > frontbuffer
> > > > > > +* flush, pass origin as ORIGIN_PINNEDFB rather than 
> > > > > > ORIGIN_DIRTYFB
> > > > > > +* so that their flush implementations can handle it 
> > > > > > accordingly.
> > > > > > +*/
> > > > > 
> > > > > So why it is different? Why can't the dirtyfb ioctl benefit from HW, 
> > > > > which the
> > > > > application is meant to call every frame to *all* dirty framebuffers
> > > > > (which include cursors in atomic)?
> > > > > 
> > > > 
> > > > Because the hardware requires a write to one of the pipe registers. When
> > > > applications write to the buffer via fbdev, it doesn't lead to pipe MMIO
> > > > write and hence does not benefit from HW triggered PSR exit.
> > > 
> > > Somewhere you have to have that explanation, that you rely on a
> > > subsequent mmioflip of the framebuffer to trigger the frontbuffer flush.
> > 
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 405acf3562de..c669fef5d388 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -4071,9 +4071,13 @@ int i915_gem_set_caching_ioctl(struct drm_device
> > *dev, void *data,
> >  }
> > 
> >  /*
> > - * Prepare buffer for display plane (scanout, cursors, etc).
> > - * Can be called from an uninterruptible phase (modesetting) and allows
> > - * any flushes to be pipelined (for pageflips).
> > + * Prepare buffer for display plane (scanout, cursors, etc). Can be
> > called from
> > + * an uninterruptible phase (modesetting) and allows any flushes to be
> > pipelined
> > + * (for pageflips). We only flush the caches while preparing the buffer
> > for
> > + * display and this may not lead to the buffer being scanned out if
> > + * intel_fb_obj_flush() consumers ignore ORIGIN_PINNEDFB. This is
> > useful because
> > + * features like PSR can delegate the flush to HW, 

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Improve PSR activation timing

[Pandiyan, Dhinakaran]

On Tue, 2018-02-13 at 15:26 -0800, Rodrigo Vivi wrote:
> From: Andy Lutomirski 
> 
> The current PSR code has a two call sites that each schedule delayed
> work to activate PSR.  As far as I can tell, each call site intends
> to keep PSR inactive for the given amount of time and then allow it
> to be activated.
> 
> The call sites are:
> 
>  - intel_psr_enable(), which explicitly states in a comment that
>it's trying to keep PSR off a short time after the dispay is
>initialized as a workaround.
> 
>  - intel_psr_flush().  There isn't an explcit explanation, but the
>intent is presumably to keep PSR off until the display has been
>idle for 100ms.
> 
> The current code doesn't actually accomplish either of these goals.
> Rather than keeping PSR inactive for the given amount of time, it
> will schedule PSR for activation after the given time, with the
> earliest target time in such a request winning.
> 
> In other words, if intel_psr_enable() is immediately followed by
> intel_psr_flush(), then PSR will be activated after 100ms even if
> intel_psr_enable() wanted a longer delay.  And, if the screen is
> being constantly updated so that intel_psr_flush() is called once
> per frame at 60Hz, PSR will still be activated once every 100ms.
> 
> Rewrite the code so that it does what was intended.  This adds
> a new function intel_psr_schedule(), which will enable PSR after
> the requested time but no sooner.
> 
> Signed-off-by: Andy Lutomirski 
> Tested-by: Rodrigo Vivi 
> Acked-by: Rodrigo Vivi 
> Signed-off-by: Rodrigo Vivi 
> 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |  8 +++--
>  drivers/gpu/drm/i915/i915_drv.h |  3 +-
>  drivers/gpu/drm/i915/intel_psr.c| 66 
> -
>  3 files changed, 66 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 960302668649..da80ee16a3cf 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2521,8 +2521,12 @@ static int i915_edp_psr_status(struct seq_file *m, 
> void *data)
>   seq_printf(m, "Active: %s\n", yesno(dev_priv->psr.active));
>   seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
>  dev_priv->psr.busy_frontbuffer_bits);
> - seq_printf(m, "Re-enable work scheduled: %s\n",
> -yesno(work_busy(_priv->psr.work.work)));
> +
> + if (timer_pending(_priv->psr.activate_timer))
> + seq_printf(m, "Activate scheduled: yes, in %dms\n",
> +
> jiffies_to_msecs(dev_priv->psr.activate_timer.expires - jiffies));
> + else
> + seq_printf(m, "Activate scheduled: no\n");
>  
>   if (HAS_DDI(dev_priv)) {
>   if (dev_priv->psr.psr2_support)
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index c06d4126c447..2afa5c05a79b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -762,7 +762,8 @@ struct i915_psr {
>   bool sink_support;
>   struct intel_dp *enabled;
>   bool active;
> - struct delayed_work work;
> + struct timer_list activate_timer;
> + struct work_struct activate_work;
>   unsigned busy_frontbuffer_bits;
>   bool psr2_support;
>   bool aux_frame_sync;
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 2ef374f936b9..826b480841ac 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -450,6 +450,28 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
>   dev_priv->psr.active = true;
>  }
>  
> +static void intel_psr_schedule(struct drm_i915_private *i915,
> +unsigned long min_wait_ms)
> +{
> + unsigned long next;
> +
> + lockdep_assert_held(>psr.lock);
> +
> + /*
> +  * We update next enable and call mod_timer() because it's
> +  * possible that intel_psr_wrk() has already been called and is
> +  * waiting for psr.lock. If that's the case, we don't want it
> +  * to immediately enable PSR.
> +  *
> +  * We also need to make sure that PSR is never activated earlier
> +  * than requested to avoid breaking intel_psr_enable()'s workaround
> +  * for pre-gen9 hardware.
> +  */
> + next = jiffies + msecs_to_jiffies(min_wait_ms);
> + if (time_after(next, i915->psr.activate_timer.expires))

.expires is an internal member, does not seem like a good idea to read
it outside of the exported interfaces.


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

Re: [Intel-gfx] [igt-dev] [PATCH igt] igt/gem_exec_schedule: Trim max number of contexts used

[Antonio Argenziano]

On 13/02/18 15:10, Chris Wilson wrote:

Quoting Antonio Argenziano (2018-02-13 22:47:35)



On 13/02/18 01:26, Chris Wilson wrote:

icl offers a much reduced context space, and in its simplest setup we
cannot allocate one context per priority level, so trim the number and
reuse the same context for multiple priority requests.

Signed-off-by: Chris Wilson 
---
   tests/gem_exec_schedule.c | 38 +++---
   1 file changed, 23 insertions(+), 15 deletions(-)

diff --git a/tests/gem_exec_schedule.c b/tests/gem_exec_schedule.c
index 05f7ae38..ec02d994 100644
--- a/tests/gem_exec_schedule.c
+++ b/tests/gem_exec_schedule.c
@@ -43,6 +43,8 @@
   #define BUSY_QLEN 8
   #define MAX_ELSP_QLEN 16
   
+#define MAX_CONTEXTS 256

+
   IGT_TEST_DESCRIPTION("Check that we can control the order of execution");
   
   static void store_dword(int fd, uint32_t ctx, unsigned ring,

@@ -556,8 +558,8 @@ static void preemptive_hang(int fd, unsigned ring)
   static void deep(int fd, unsigned ring)
   {
   #define XS 8
- const unsigned int nctx = MAX_PRIO - MIN_PRIO;
- const unsigned size = ALIGN(4*nctx, 4096);
+ const unsigned int nreq = MAX_PRIO - MIN_PRIO;
+ const unsigned size = ALIGN(4*nreq, 4096);
   struct timespec tv = {};
   struct cork cork;
   uint32_t result, dep[XS];
@@ -565,10 +567,9 @@ static void deep(int fd, unsigned ring)
   uint32_t *ptr;
   uint32_t *ctx;
   
- ctx = malloc(sizeof(*ctx) * nctx);

- for (int n = 0; n < nctx; n++) {
+ ctx = malloc(sizeof(*ctx) * MAX_CONTEXTS);
+ for (int n = 0; n < MAX_CONTEXTS; n++) {
   ctx[n] = gem_context_create(fd);
- gem_context_set_priority(fd, ctx[n], MAX_PRIO - nctx + n);
   }
   
   result = gem_create(fd, size);

@@ -592,7 +593,7 @@ static void deep(int fd, unsigned ring)
   execbuf.buffers_ptr = to_user_pointer(obj);
   execbuf.buffer_count = XS + 2;
   execbuf.flags = ring;
- for (int n = 0; n < nctx; n++) {
+ for (int n = 0; n < MAX_CONTEXTS; n++) {
   execbuf.rsvd1 = ctx[n];
   gem_execbuf(fd, );
   }
@@ -603,22 +604,29 @@ static void deep(int fd, unsigned ring)
   plug(fd, );
   
   /* Create a deep dependency chain, with a few branches */

- for (int n = 0; n < nctx && igt_seconds_elapsed() < 8; n++)
+ for (int n = 0; n < nreq && igt_seconds_elapsed() < 8; n++) {
+ uint32_t context = ctx[n % MAX_CONTEXTS];


Doesn't this introduce some intra-context dependency we didn't have
before? Do we care?


Yes, it reduces the re-ordering possibilities (it will also exercise
priority inversion within the context as well). We have to reduce the
test somehow, and this preserves the essence in that the kernel has to
manage the same long dependencies chains, just now with a few more
branches.


OK.

Acked-by: Antonio Argenziano 

Thanks,
Antonio


-Chris


___
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/5] drm/i915: Improve PSR activation timing

[Patchwork]

== Series Details ==

Series: series starting with [1/5] drm/i915: Improve PSR activation timing
URL   : https://patchwork.freedesktop.org/series/38199/
State : failure

== Summary ==

Series 38199v1 series starting with [1/5] drm/i915: Improve PSR activation 
timing
https://patchwork.freedesktop.org/api/1.0/series/38199/revisions/1/mbox/

Test gem_ctx_switch:
Subgroup basic-default-heavy:
pass   -> INCOMPLETE (fi-cnl-y3)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> INCOMPLETE (fi-bxt-dsi)
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (fi-skl-6600u)
pass   -> DMESG-WARN (fi-skl-6700hq) fdo#101144
pass   -> DMESG-WARN (fi-kbl-7560u)
pass   -> DMESG-WARN (fi-kbl-r)
pass   -> DMESG-WARN (fi-glk-1)
pass   -> DMESG-WARN (fi-cfl-s2)

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

fi-bdw-5557u total:288  pass:265  dwarn:0   dfail:0   fail:2   skip:21  
time:438s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:430s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:376s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:494s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:290s
fi-bxt-dsi   total:246  pass:219  dwarn:0   dfail:0   fail:0   skip:26 
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:489s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:473s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:462s
fi-cfl-s2total:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:574s
fi-cnl-y3total:22   pass:21   dwarn:0   dfail:0   fail:0   skip:0  
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:424s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:285s
fi-glk-1 total:288  pass:259  dwarn:1   dfail:0   fail:0   skip:28  
time:511s
fi-hsw-4770  total:288  pass:259  dwarn:0   dfail:0   fail:2   skip:27  
time:413s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:413s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:465s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:416s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:458s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:499s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:499s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:591s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:430s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:508s
fi-skl-6700hqtotal:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:526s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:495s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:485s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:421s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:432s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:527s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:398s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:181  dwarn:1   dfail:4   fail:0   skip:102 
time:769s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:451s

55dfdd18a566b5c632cbb34086b2a03410e810fb drm-tip: 2018y-02m-13d-18h-37m-11s UTC 
integration manifest
fa066f8ebd80 drm/i915/psr: Display WA #1130: bxt, glk
9fea4988f6f6 drm/i915/psr: Display WA #1110
68bcf8babd26 drm/i915/psr: Display WA 0884 applied broadly for more HW tracking.
51fd4ce038af drm/i915/psr: Kill scheduled work for Core platforms.
4175f54e54b7 drm/i915: Improve PSR activation timing

== Logs ==

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

[Intel-gfx] [PATCH 4/5] drm/i915/psr: Display WA #1110

[Rodrigo Vivi]

Missing flips when FBC is enabled with PSR
link off/PSR2 deep sleep scenarios.

WA: When FBC is enabled with PSR/PSR2,
set bit 30 of MMIO register 0x420CC to 1b.

Cc: Dhinakaran Pandiyan 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_reg.h  | 1 +
 drivers/gpu/drm/i915/intel_psr.c | 8 +++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ac09d17cd835..0f423cd52983 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7153,6 +7153,7 @@ enum {
 #define CHICKEN_TRANS_A 0x420c0
 #define CHICKEN_TRANS_B 0x420c4
 #define CHICKEN_TRANS(trans) _MMIO_TRANS(trans, CHICKEN_TRANS_A, 
CHICKEN_TRANS_B)
+#define  DDI_MASK_INTERRUPTS_PSR   (1<<30)
 #define  DDI_TRAINING_OVERRIDE_ENABLE  (1<<19)
 #define  DDI_TRAINING_OVERRIDE_VALUE   (1<<18)
 #define  DDIE_TRAINING_OVERRIDE_ENABLE (1<<17) /* CHICKEN_TRANS_A only */
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 49554036ffb8..43c702b70519 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -481,7 +481,7 @@ static void hsw_psr_enable_source(struct intel_dp *intel_dp,
struct drm_device *dev = dig_port->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
-   u32 chicken;
+   u32 chicken = I915_READ(CHICKEN_TRANS(cpu_transcoder));
 
if (dev_priv->psr.psr2_support) {
chicken = PSR2_VSC_ENABLE_PROG_HEADER;
@@ -508,6 +508,12 @@ static void hsw_psr_enable_source(struct intel_dp 
*intel_dp,
   EDP_PSR_DEBUG_MASK_HPD |
   EDP_PSR_DEBUG_MASK_LPSP);
}
+
+   /* Display WA #1110: skl,kbl,cfl,bxt */
+   if (IS_GEN9_BC(dev_priv) || IS_BROXTON(dev_priv)) {
+   chicken |= DDI_MASK_INTERRUPTS_PSR;
+   I915_WRITE(CHICKEN_TRANS(cpu_transcoder), chicken);
+   }
 }
 
 /**
-- 
2.13.6

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

[Intel-gfx] [PATCH 2/5] drm/i915/psr: Kill scheduled work for Core platforms.

[Rodrigo Vivi]

It is a fact that scheduled work is now improved.

But it is also a fact that on core platforms that shouldn't
be needed. We only need to actually wait on VLV/CHV.

The immediate enabling is actually not an issue for the
HW perspective for core platforms that have HW tracking.
HW will wait few identical idle frames before transitioning
to actual psr active anyways.

Note that this patch also remove the delayed activation
on HSW and BDW introduced by commit 'd0ac896a477d
("drm/i915: Delay first PSR activation.")'. This was
introduced to fix a blank screen on VLV/CHV and also
masked some frozen screens on other core platforms.
Probably the same that we are now properly hunting and fixing.

Furthermore, if we stop using delayed activation on core
platforms we will be able, on following up patches,
to use available workarounds to make HW tracking properly
exit PSR instead of the big nuke of disabling psr and
re-enable on exit and activate respectively.
At least on few reliable cases.

Cc: Dhinakaran Pandiyan 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 14 +++---
 drivers/gpu/drm/i915/intel_psr.c| 27 +++
 2 files changed, 26 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index da80ee16a3cf..541290c307c7 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2522,18 +2522,18 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
   dev_priv->psr.busy_frontbuffer_bits);
 
-   if (timer_pending(_priv->psr.activate_timer))
-   seq_printf(m, "Activate scheduled: yes, in %dms\n",
-  
jiffies_to_msecs(dev_priv->psr.activate_timer.expires - jiffies));
-   else
-   seq_printf(m, "Activate scheduled: no\n");
-
-   if (HAS_DDI(dev_priv)) {
+   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
if (dev_priv->psr.psr2_support)
enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
else
enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
} else {
+   if (timer_pending(_priv->psr.activate_timer))
+   seq_printf(m, "Activate scheduled: yes, in %dms\n",
+  
jiffies_to_msecs(dev_priv->psr.activate_timer.expires - jiffies));
+   else
+   seq_printf(m, "Activate scheduled: no\n");
+
for_each_pipe(dev_priv, pipe) {
enum transcoder cpu_transcoder =
intel_pipe_to_cpu_transcoder(dev_priv, pipe);
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 826b480841ac..13409c6301e8 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -455,6 +455,8 @@ static void intel_psr_schedule(struct drm_i915_private 
*i915,
 {
unsigned long next;
 
+   WARN_ON(!IS_VALLEYVIEW(i915) && !IS_CHERRYVIEW(i915));
+
lockdep_assert_held(>psr.lock);
 
/*
@@ -543,7 +545,7 @@ void intel_psr_enable(struct intel_dp *intel_dp,
dev_priv->psr.enable_source(intel_dp, crtc_state);
dev_priv->psr.enabled = intel_dp;
 
-   if (INTEL_GEN(dev_priv) >= 9) {
+   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
intel_psr_activate(intel_dp);
} else {
/*
@@ -553,8 +555,6 @@ void intel_psr_enable(struct intel_dp *intel_dp,
 * However on some platforms we face issues when first
 * activation follows a modeset so quickly.
 * - On VLV/CHV we get bank screen on first activation
-* - On HSW/BDW we get a recoverable frozen screen until
-*   next exit-activate sequence.
 */
intel_psr_schedule(dev_priv,
   intel_dp->panel_power_cycle_delay * 5);
@@ -687,6 +687,8 @@ static void intel_psr_work(struct work_struct *work)
struct drm_crtc *crtc = dp_to_dig_port(intel_dp)->base.base.crtc;
enum pipe pipe = to_intel_crtc(crtc)->pipe;
 
+   WARN_ON(!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv));
+
/* We have to make sure PSR is ready for re-enable
 * otherwise it keeps disabled until next full enable/disable cycle.
 * PSR might take some time to get fully disabled
@@ -757,6 +759,8 @@ static void intel_psr_timer_fn(struct timer_list *timer)
struct drm_i915_private *i915 =
from_timer(i915, timer, psr.activate_timer);
 
+   WARN_ON(!IS_VALLEYVIEW(i915) && !IS_CHERRYVIEW(i915));
+
/*
 * We need a non-atomic context to activate PSR.  Using
 * 

[Intel-gfx] [PATCH 3/5] drm/i915/psr: Display WA 0884 applied broadly for more HW tracking.

[Rodrigo Vivi]

WA 0884:bxt:all,cnl:*:A - "When FBC is enabled with eDP PSR,
the CPU host modify writes may not get updated on the Display
as expected.
WA: Write 0x to CUR_SURFLIVE_A with every CPU
host modify write to trigger PSR exit."

We can also find on spec other cases where they describe
bogus writes to cursor registers to force PSR exit with
HW tracking. And it was confirmed by HW engineers that
this Wa can be safely applied for any frontbuffer activity.

So let's use this more and more here instead of forcibly
disable and re-enable PSR everytime that we have a simple
reliable flush case.

Other commits improve the fbcon/fbdev use a lot, but this
approach is the only when where we can get a fully reliable
console with no slowness or missed frames and PSR still
enabled and active.

Cc: Dhinakaran Pandiyan 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_reg.h  |  3 +++
 drivers/gpu/drm/i915/intel_psr.c | 15 +--
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f6afa5e5e7c1..ac09d17cd835 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6007,6 +6007,9 @@ enum {
 #define IVB_CURSOR_B_OFFSET 0x71080
 #define IVB_CURSOR_C_OFFSET 0x72080
 
+#define _CUR_SURLIVE   0x700AC
+#define CUR_SURLIVE(pipe)  _CURSOR2(pipe, _CUR_SURLIVE)
+
 /* Display A control */
 #define _DSPACNTR  0x70180
 #define   DISPLAY_PLANE_ENABLE (1<<31)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 13409c6301e8..49554036ffb8 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -946,8 +946,19 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
dev_priv->psr.busy_frontbuffer_bits &= ~frontbuffer_bits;
 
/* By definition flush = invalidate + flush */
-   if (frontbuffer_bits)
-   intel_psr_exit(dev_priv);
+   if (frontbuffer_bits) {
+   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
+   intel_psr_exit(dev_priv);
+   } else {
+   /*
+* Display WA #0884: all
+* This documented WA for bxt can be safely applied
+* broadly so we can force HW tracking to exit PSR
+* instead of disabling and re-enabling.
+*/
+   I915_WRITE(CUR_SURLIVE(pipe), 0);
+   }
+   }
 
if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits) {
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
-- 
2.13.6

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

[Intel-gfx] [PATCH 1/5] drm/i915: Improve PSR activation timing

[Rodrigo Vivi]

From: Andy Lutomirski 

The current PSR code has a two call sites that each schedule delayed
work to activate PSR.  As far as I can tell, each call site intends
to keep PSR inactive for the given amount of time and then allow it
to be activated.

The call sites are:

 - intel_psr_enable(), which explicitly states in a comment that
   it's trying to keep PSR off a short time after the dispay is
   initialized as a workaround.

 - intel_psr_flush().  There isn't an explcit explanation, but the
   intent is presumably to keep PSR off until the display has been
   idle for 100ms.

The current code doesn't actually accomplish either of these goals.
Rather than keeping PSR inactive for the given amount of time, it
will schedule PSR for activation after the given time, with the
earliest target time in such a request winning.

In other words, if intel_psr_enable() is immediately followed by
intel_psr_flush(), then PSR will be activated after 100ms even if
intel_psr_enable() wanted a longer delay.  And, if the screen is
being constantly updated so that intel_psr_flush() is called once
per frame at 60Hz, PSR will still be activated once every 100ms.

Rewrite the code so that it does what was intended.  This adds
a new function intel_psr_schedule(), which will enable PSR after
the requested time but no sooner.

Signed-off-by: Andy Lutomirski 
Tested-by: Rodrigo Vivi 
Acked-by: Rodrigo Vivi 
Signed-off-by: Rodrigo Vivi 

---
 drivers/gpu/drm/i915/i915_debugfs.c |  8 +++--
 drivers/gpu/drm/i915/i915_drv.h |  3 +-
 drivers/gpu/drm/i915/intel_psr.c| 66 -
 3 files changed, 66 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 960302668649..da80ee16a3cf 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2521,8 +2521,12 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
seq_printf(m, "Active: %s\n", yesno(dev_priv->psr.active));
seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
   dev_priv->psr.busy_frontbuffer_bits);
-   seq_printf(m, "Re-enable work scheduled: %s\n",
-  yesno(work_busy(_priv->psr.work.work)));
+
+   if (timer_pending(_priv->psr.activate_timer))
+   seq_printf(m, "Activate scheduled: yes, in %dms\n",
+  
jiffies_to_msecs(dev_priv->psr.activate_timer.expires - jiffies));
+   else
+   seq_printf(m, "Activate scheduled: no\n");
 
if (HAS_DDI(dev_priv)) {
if (dev_priv->psr.psr2_support)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c06d4126c447..2afa5c05a79b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -762,7 +762,8 @@ struct i915_psr {
bool sink_support;
struct intel_dp *enabled;
bool active;
-   struct delayed_work work;
+   struct timer_list activate_timer;
+   struct work_struct activate_work;
unsigned busy_frontbuffer_bits;
bool psr2_support;
bool aux_frame_sync;
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 2ef374f936b9..826b480841ac 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -450,6 +450,28 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
dev_priv->psr.active = true;
 }
 
+static void intel_psr_schedule(struct drm_i915_private *i915,
+  unsigned long min_wait_ms)
+{
+   unsigned long next;
+
+   lockdep_assert_held(>psr.lock);
+
+   /*
+* We update next enable and call mod_timer() because it's
+* possible that intel_psr_wrk() has already been called and is
+* waiting for psr.lock. If that's the case, we don't want it
+* to immediately enable PSR.
+*
+* We also need to make sure that PSR is never activated earlier
+* than requested to avoid breaking intel_psr_enable()'s workaround
+* for pre-gen9 hardware.
+*/
+   next = jiffies + msecs_to_jiffies(min_wait_ms);
+   if (time_after(next, i915->psr.activate_timer.expires))
+   mod_timer(>psr.activate_timer, next);
+}
+
 static void hsw_psr_enable_source(struct intel_dp *intel_dp,
  const struct intel_crtc_state *crtc_state)
 {
@@ -534,8 +556,8 @@ void intel_psr_enable(struct intel_dp *intel_dp,
 * - On HSW/BDW we get a recoverable frozen screen until
 *   next exit-activate sequence.
 */
-   schedule_delayed_work(_priv->psr.work,
- 
msecs_to_jiffies(intel_dp->panel_power_cycle_delay * 5));
+   intel_psr_schedule(dev_priv,
+   

[Intel-gfx] [PATCH 5/5] drm/i915/psr: Display WA #1130: bxt, glk

[Rodrigo Vivi]

Host/Render modifications do not trigger PSR exit
or Wireless quick capture exit correctly.

WA: Set MMIO register 0x4653C bit 31 = 1b.

Cc: Dhinakaran Pandiyan 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_reg.h | 1 +
 drivers/gpu/drm/i915/intel_pm.c | 7 +++
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0f423cd52983..8a4cd8b4bd7c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3924,6 +3924,7 @@ enum {
 #define   PWM1_GATING_DIS  (1 << 13)
 
 #define GEN9_CLKGATE_DIS_4 _MMIO(0x4653C)
+#define   BXT_DCIPH_GATING_DIS (1 << 31)
 #define   BXT_GMBUS_GATING_DIS (1 << 14)
 
 #define _CLKGATE_DIS_PSL_A 0x46520
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7e15b261821d..a0a6b4b7c47b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -114,6 +114,10 @@ static void bxt_init_clock_gating(struct drm_i915_private 
*dev_priv)
 */
I915_WRITE(GEN9_CLKGATE_DIS_0, I915_READ(GEN9_CLKGATE_DIS_0) |
   PWM1_GATING_DIS | PWM2_GATING_DIS);
+
+   /* Display WA #1130:bxt */
+   I915_WRITE(GEN9_CLKGATE_DIS_4, I915_READ(GEN9_CLKGATE_DIS_4) |
+  BXT_DCIPH_GATING_DIS);
 }
 
 static void glk_init_clock_gating(struct drm_i915_private *dev_priv)
@@ -137,6 +141,9 @@ static void glk_init_clock_gating(struct drm_i915_private 
*dev_priv)
I915_WRITE(CHICKEN_MISC_2, val);
}
 
+   /* Display WA #1130:glk */
+   I915_WRITE(GEN9_CLKGATE_DIS_4, I915_READ(GEN9_CLKGATE_DIS_4) |
+  BXT_DCIPH_GATING_DIS);
 }
 
 static void i915_pineview_get_mem_freq(struct drm_i915_private *dev_priv)
-- 
2.13.6

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

Re: [Intel-gfx] [PATCH] drm/i915: Improve PSR activation timing

[Rodrigo Vivi]

Rodrigo Vivi  writes:

> On Sat, Feb 10, 2018 at 09:43:59AM +, Chris Wilson wrote:
>> Quoting Andy Lutomirski (2018-02-09 17:55:38)
>> > On Fri, Feb 9, 2018 at 7:39 AM, Rodrigo Vivi  
>> > wrote:
>> > > Rodrigo Vivi  writes:
>> > > So, I move the hacked scheduled to 10s and forced psr_activate 10ms
>> > > after that and the result is this:
>> > >
>> > >
>> > > [   11.757909] [drm:intel_psr_enable [i915]] *ERROR* I915-DEBUG:
>> > > Scheduling 10s
>> > > [   11.778586] [drm:intel_psr_flush [i915]] *ERROR* I915-DEBUG: Work 
>> > > busy!
>> > > ...
>> > > a bunch more of Work busy
>> > > ...
>> > > [   21.980643] [drm:intel_psr_flush [i915]] *ERROR* I915-DEBUG: Work 
>> > > busy!
>> > 
>> > This like ("Work busy!") is intel_psr_flush() noticing that
>> > work_busy() returns true (which it does indeed do when the work is
>> > scheduled for the future).  But this means that intel_psr_flush()
>> > wants to keep PSR off for a little bit (10s with your patch applied)
>> > because the screen isn't idle.
>> > 
>> > > [   21.983060] [drm:intel_psr_work [i915]] *ERROR* I915-DEBUG: Work 
>> > > running
>> > 
>> > And here's intel_psr_work() turning PSR back on 3ms later.
>> > 
>> > So I think you're seeing exactly the bug I described.
>
> Well, not in the way you described though.
>
> As we can see on the log work running get executed only 10 seconds after
> intel_psr_enable wanted. None of the thousand flushes happening there will
> trigger psr activate before the wanted 10s.
>
> So the hack indeed work as expected.
>
> Given that description I proved that it works as expected and move away.
> But since you insisted I step back and re-read your patch like if you had
> never mentioned the hack on intel_psr_enable ever, but only focusing
> on the regular calls from intel_psr_flush and you are right,
> we do have a bug that would affect VLV/CHV here.
>
> In the current code the psr_activate can happen any moment from 0ms to 100ms
> after the flush.
>
> This 100ms would just reduce the amount of fast exit-activate cases,
> but not eliminate the possibility of enabling before 100ms.
>
> On core platforms it shouldn't be any problem because HW tracking would
> take care of waiting the extra idle frames.
>
> This could be a particular problem for VLV/CHV platforms where I believe
> we should wait few frames before really activating it back.
>
> So, probably we can go ahead with your patch so we get this covered for
> VLV/CHV, but I'd like a version without mentioning the intel_psr_enable
> case that is already proven work as expected.
>
> But meanwhile I will check back on the hack and see if we can already
> remove that since many things got fixed and improved around eDP link training
> and psr itself.
>
> Also I will discuss with DK and check the possibility of a immediate activate
> on platforms with HW tracking. Specially now that we are moving towards more
> use of HW tracking.
>
> In this case we would reduce this scheduled/timer based solution only for 
> VLV/CHV.
>
> And then on VLV/CHV front there are even more issues to sync with VBLANK etc 
> in
> a platform that probably went to the market without any single unit with PSR 
> panels
> that was to expensive when those platforms got released.
>
> I even consider totally removing VLV/CHV code completely.
>
>> 
>> It's also evident in the tests that PSR isn't being disabled as
>> often/quick as we need for frontbuffer updates to be seen.
>
> Yeap, it is evident we have many bugs there, but I'm afraid this is not
> the answer for the lag.
> DK found some promising ones...

Ok. I was wrong. This also explains and fixes some cases here like
fbcon/fbdev... So:

Tested-by: Rodrigo Vivi 

I'd still want a version without mention to the schedule case at
intel_psr_enable to avoid confusion here. But since I'm now
basing my patches on top of this:

Acked-by: Rodrigo Vivi 

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

Re: [Intel-gfx] [igt-dev] [PATCH igt] igt/gem_exec_schedule: Trim max number of contexts used

[Chris Wilson]

Quoting Antonio Argenziano (2018-02-13 22:47:35)
> 
> 
> On 13/02/18 01:26, Chris Wilson wrote:
> > icl offers a much reduced context space, and in its simplest setup we
> > cannot allocate one context per priority level, so trim the number and
> > reuse the same context for multiple priority requests.
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> >   tests/gem_exec_schedule.c | 38 +++---
> >   1 file changed, 23 insertions(+), 15 deletions(-)
> > 
> > diff --git a/tests/gem_exec_schedule.c b/tests/gem_exec_schedule.c
> > index 05f7ae38..ec02d994 100644
> > --- a/tests/gem_exec_schedule.c
> > +++ b/tests/gem_exec_schedule.c
> > @@ -43,6 +43,8 @@
> >   #define BUSY_QLEN 8
> >   #define MAX_ELSP_QLEN 16
> >   
> > +#define MAX_CONTEXTS 256
> > +
> >   IGT_TEST_DESCRIPTION("Check that we can control the order of execution");
> >   
> >   static void store_dword(int fd, uint32_t ctx, unsigned ring,
> > @@ -556,8 +558,8 @@ static void preemptive_hang(int fd, unsigned ring)
> >   static void deep(int fd, unsigned ring)
> >   {
> >   #define XS 8
> > - const unsigned int nctx = MAX_PRIO - MIN_PRIO;
> > - const unsigned size = ALIGN(4*nctx, 4096);
> > + const unsigned int nreq = MAX_PRIO - MIN_PRIO;
> > + const unsigned size = ALIGN(4*nreq, 4096);
> >   struct timespec tv = {};
> >   struct cork cork;
> >   uint32_t result, dep[XS];
> > @@ -565,10 +567,9 @@ static void deep(int fd, unsigned ring)
> >   uint32_t *ptr;
> >   uint32_t *ctx;
> >   
> > - ctx = malloc(sizeof(*ctx) * nctx);
> > - for (int n = 0; n < nctx; n++) {
> > + ctx = malloc(sizeof(*ctx) * MAX_CONTEXTS);
> > + for (int n = 0; n < MAX_CONTEXTS; n++) {
> >   ctx[n] = gem_context_create(fd);
> > - gem_context_set_priority(fd, ctx[n], MAX_PRIO - nctx + n);
> >   }
> >   
> >   result = gem_create(fd, size);
> > @@ -592,7 +593,7 @@ static void deep(int fd, unsigned ring)
> >   execbuf.buffers_ptr = to_user_pointer(obj);
> >   execbuf.buffer_count = XS + 2;
> >   execbuf.flags = ring;
> > - for (int n = 0; n < nctx; n++) {
> > + for (int n = 0; n < MAX_CONTEXTS; n++) {
> >   execbuf.rsvd1 = ctx[n];
> >   gem_execbuf(fd, );
> >   }
> > @@ -603,22 +604,29 @@ static void deep(int fd, unsigned ring)
> >   plug(fd, );
> >   
> >   /* Create a deep dependency chain, with a few branches */
> > - for (int n = 0; n < nctx && igt_seconds_elapsed() < 8; n++)
> > + for (int n = 0; n < nreq && igt_seconds_elapsed() < 8; n++) {
> > + uint32_t context = ctx[n % MAX_CONTEXTS];
> 
> Doesn't this introduce some intra-context dependency we didn't have 
> before? Do we care?

Yes, it reduces the re-ordering possibilities (it will also exercise
priority inversion within the context as well). We have to reduce the
test somehow, and this preserves the essence in that the kernel has to
manage the same long dependencies chains, just now with a few more
branches.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v10 5/7] drm/i915/guc: Add HuC firmware size related restriction for Gen9 and CNL A0

[Michal Wajdeczko]

On Tue, 13 Feb 2018 22:50:53 +0100, Yaodong Li   
wrote:



On 02/13/2018 08:06 AM, Michal Wajdeczko wrote:

+static inline int check_huc_fw_fits(struct intel_guc_wopcm *guc_wopcm,

+u32 huc_fw_size)
+{
+/*
+ * On Gen9 & CNL A0, hardware requires the total available GuC  
WOPCM
+ * size to be larger than or equal to HuC firmware size.  
Otherwise,

+ * firmware uploading would fail.
+ */
+if (guc_wopcm->size - GUC_WOPCM_RESERVED < huc_fw_size)


What if guc_wopcm->size < GUC_WOPCM_RESERVED ?


we've already had following check before this. which had guaranteed
guc_wopcm->size >= guc_fw_size + reserved, thus,
guc_wopcm->size > GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED
so, guc_wopcm->size > GUC_WOPCM_RESERVED:-)

 reserved = GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
 if ((guc_fw_size + reserved) > guc_wopcm->size) {
 DRM_DEBUG_DRIVER("No enough GuC WOPCM for GuC firmware.\n");
 return -E2BIG;
 }


Hmm, that only proves that current partitioning code is too complicated :)
If you look at diagram it should be possible to implement it as

guc_base = ALIGN(huc_fw_size + WOPCM_RESERVED, KiB(16));
guc_size = ALIGN(guc_fw_size + GUC_WOPCM_RESERVED, KiB(4))
reserved = context_reserved_size(i915);

if (guc_base + guc_size + reserved > WOPCM_DEFAULT_SIZE)
return -E2BIG;

(E)


+return -E2BIG;
+
+return 0;
+}
+
 static inline int gen9_check_dword_gap(struct intel_guc_wopcm  
*guc_wopcm)

 {
 u32 guc_wopcm_start;
@@ -40,15 +54,19 @@ static inline int gen9_check_dword_gap(struct  
intel_guc_wopcm *guc_wopcm)

 return 0;
 }
-static inline int guc_wopcm_size_check(struct intel_guc *guc)
+static inline int guc_wopcm_size_check(struct intel_guc *guc, u32  
huc_fw_size)

 {
 struct drm_i915_private *i915 = guc_to_i915(guc);
 struct intel_guc_wopcm *guc_wopcm = >wopcm;
+int err = 0;
if (IS_GEN9(i915))
-return gen9_check_dword_gap(guc_wopcm);
+err = gen9_check_dword_gap(guc_wopcm);
-return 0;
+if (IS_GEN9(i915) || IS_CNL_REVID(i915, CNL_REVID_A0,  
CNL_REVID_A0))

+err = check_huc_fw_fits(guc_wopcm, huc_fw_size);


Hmm, what if gen9_check_dword_gap() fails but check_huc_fw_fits()  
passes ?



oops! will fix this.:-)

+
+return err;
 }
/**
@@ -121,7 +139,7 @@ int intel_guc_wopcm_init(struct intel_guc_wopcm  
*guc_wopcm, u32 guc_fw_size,

 guc->wopcm.size = size;
 guc->wopcm.top = top;
-err = guc_wopcm_size_check(guc);
+err = guc_wopcm_size_check(guc, huc_fw_size);
 if (err) {
 DRM_DEBUG_DRIVER("GuC WOPCM size check failed.\n");
 return err;


I'm more and more convinced that we should use "intel_wopcm" to make
partition and all these checks

These are all GuC wopcm related, it only checks guc wopcm size. so I am  
wondering whether
I am still misunderstanding anything here?since the purpose of these  
calculation and checks are
clearly all GuC related. To be more precisely GuC DMA related. The  
driver's responsibility is to
calculate the GuC DMA offset and GuC wopcm size values based on guc/huc  
fw sizes and

all these checks are all for the correctness for the GuC  wopcm size.
I don't see any reason why these should be a part of global intel_wopcm  
even if we really
want to keep something like wopcm_regions for both guc/huc(though I  
still don't know what
the benefit real is to keep something like HuC wopcm region except for  
sth like debugfs output?).
even in this case, we still at least keep these as a part of  GuC since  
we really need it to setup
GuC HW :- Or do you mean we should create an intel_wopcm to carry info  
such as
global WOPCM size,guc_fw_size and huc_fw_size? Sorry I am really a  
little bit confused here:-(


struct intel_wopcm should carry only results of WOPCM partitioning between
all agents including GuC. There is no need to carry fw sizes as those are
only needed as input for calculations.

You can still program GuC region from uc code.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/psr: HW tracking for cursor moves to fix lags.

[Chris Wilson]

Quoting Pandiyan, Dhinakaran (2018-02-13 22:45:55)
> 
> 
> 
> On Tue, 2018-02-13 at 22:15 +, Chris Wilson wrote:
> > Quoting Pandiyan, Dhinakaran (2018-02-13 22:10:48)
> > > 
> > > 
> > > 
> > > On Tue, 2018-02-13 at 21:54 +, Chris Wilson wrote:
> > > > Quoting Dhinakaran Pandiyan (2018-02-13 21:46:13)
> > > > > DRM_IOCTL_MODE_CURSOR results in a frontbuffer flush before the cursor
> > > > > plane MMIOs are written to. But this flush is not necessary for PSR as
> > > > > hardware tracking takes care of exiting PSR when the MMIO's are 
> > > > > written.
> > > > > 
> > > > > Introduce a new fb_op_origin enum to differentiate flushes due to a BO
> > > > > being pinned from those originating due to a dirty fbdev buffer. Now, 
> > > > > this
> > > > > enum can be ignored in psr_flush and psr_invalidate.
> > > > > 
> > > > > v2: Update comment in i915_gem_object_pin_to_display_plane. (Chris)
> > > > > 
> > > > > Cc: Rodrigo Vivi 
> > > > > Cc: Ville Syrjälä 
> > > > > Cc: Chris Wilson 
> > > > > Signed-off-by: Dhinakaran Pandiyan 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/i915_drv.h  |  1 +
> > > > >  drivers/gpu/drm/i915/i915_gem.c  | 11 +--
> > > > >  drivers/gpu/drm/i915/intel_psr.c |  6 --
> > > > >  3 files changed, 14 insertions(+), 4 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > index 81886b74c750..3bf6c6ec0509 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > @@ -637,6 +637,7 @@ enum fb_op_origin {
> > > > > ORIGIN_CS,
> > > > > ORIGIN_FLIP,
> > > > > ORIGIN_DIRTYFB,
> > > > > +   ORIGIN_PINNEDFB,
> > > > >  };
> > > > >  
> > > > >  struct intel_fbc {
> > > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > > > > b/drivers/gpu/drm/i915/i915_gem.c
> > > > > index fc68b35854df..405acf3562de 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > > > @@ -4139,9 +4139,16 @@ i915_gem_object_pin_to_display_plane(struct 
> > > > > drm_i915_gem_object *obj,
> > > > >  
> > > > > vma->display_alignment = max_t(u64, vma->display_alignment, 
> > > > > alignment);
> > > > >  
> > > > > -   /* Treat this as an end-of-frame, like 
> > > > > intel_user_framebuffer_dirty() */
> > > > > +   /* Treat this as an end-of-frame, like 
> > > > > intel_user_framebuffer_dirty() to
> > > > > +* flush the caches.
> > > > > +*/
> > > > > __i915_gem_object_flush_for_display(obj);
> > > > > -   intel_fb_obj_flush(obj, ORIGIN_DIRTYFB);
> > > > > +
> > > > > +   /* Features like PSR might want to rely on HW to do the 
> > > > > frontbuffer
> > > > > +* flush, pass origin as ORIGIN_PINNEDFB rather than 
> > > > > ORIGIN_DIRTYFB
> > > > > +* so that their flush implementations can handle it 
> > > > > accordingly.
> > > > > +*/
> > > > 
> > > > So why it is different? Why can't the dirtyfb ioctl benefit from HW, 
> > > > which the
> > > > application is meant to call every frame to *all* dirty framebuffers
> > > > (which include cursors in atomic)?
> > > > 
> > > 
> > > Because the hardware requires a write to one of the pipe registers. When
> > > applications write to the buffer via fbdev, it doesn't lead to pipe MMIO
> > > write and hence does not benefit from HW triggered PSR exit.
> > 
> > Somewhere you have to have that explanation, that you rely on a
> > subsequent mmioflip of the framebuffer to trigger the frontbuffer flush.
> 
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c
> index 405acf3562de..c669fef5d388 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4071,9 +4071,13 @@ int i915_gem_set_caching_ioctl(struct drm_device
> *dev, void *data,
>  }
> 
>  /*
> - * Prepare buffer for display plane (scanout, cursors, etc).
> - * Can be called from an uninterruptible phase (modesetting) and allows
> - * any flushes to be pipelined (for pageflips).
> + * Prepare buffer for display plane (scanout, cursors, etc). Can be
> called from
> + * an uninterruptible phase (modesetting) and allows any flushes to be
> pipelined
> + * (for pageflips). We only flush the caches while preparing the buffer
> for
> + * display and this may not lead to the buffer being scanned out if
> + * intel_fb_obj_flush() consumers ignore ORIGIN_PINNEDFB. This is
> useful because
> + * features like PSR can delegate the flush to HW, which gets triggered
> when
> + * flip or cursor move MMIO's are written to.
>   */
>  struct i915_vma *
>  i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj,
> 
> 
> Like this?
> 
> 
> 
> > That probably also deserves lifting out of pin_to_display_plane as
> > currently there's no requirement that 

Re: [Intel-gfx] [PATCH v10 3/7] drm/i915/guc: Implement dynamic GuC WOPCM offset and size

[Michal Wajdeczko]

On Tue, 13 Feb 2018 21:01:04 +0100, Yaodong Li   
wrote:



On 02/13/2018 07:56 AM, Michal Wajdeczko wrote:

+
+/* GUC WOPCM offset needs to be 16KB aligned. */
+#define GUC_WOPCM_OFFSET_ALIGNMENT(16 << 10)
+/* 16KB reserved at the beginning of GuC WOPCM. */
+#define GUC_WOPCM_RESERVED(16 << 10)
+/* 8KB from GUC_WOPCM_RESERVED is reserved for GuC stack. */
+#define GUC_WOPCM_STACK_RESERVED(8 << 10)
+/* 24KB at the end of GuC WOPCM is reserved for RC6 CTX on BXT. */
+#define BXT_GUC_WOPCM_RC6_CTX_RESERVED(24 << 10)


Hmm, I'm still not convinced that we correctly attach it to "GuC WOPCM".

Can you explain the reason and more about your concerns?


Spec says that CTX reserved region is separate from GuC region and is
calculated "against the address of the top of WOPCM".



In the result, maybe we should stop focusing on "intel_guc_wopcm" and  
define

everything as "intel_wopcm" as it was earlier suggested by Joonas.

Then we can define our struct to match diagram above as

struct intel_wopcm {
u32 size;
struct {
u32 base;
u32 size;
} guc;
};


Thanks Michal! but I don't think this is quite clean design. two reason:
0) I agree there should be something like intel_wopcm to describe
 the overall wopcm info, that what I did in my v1 patch series.
 the question is whether we really need it even if we are using
 only static wopcm size value?


Are you sure that WOPCM size is same for all platforms ?


I think it should be more clear to
 introduce intel_wopcm as  a part of a patch that supports dynamic
 wopcm size calculation.


This is exactly what I'm suggesting. Note that spec uses "arbiter" term,
and we can use struct intel_wopcm as placeholder for the partitioning  
results.



2) the wopcm region (a.k.a partition) is definitely a concept that should
 exist at least in uc layer.


I'm not so sure. But definitely it should not be guc only concept.


if we chose not to init uc/guc, it would be
 nonsense to init these partitions/info in an intel_wopcm which  
attached to
 drm_i915_private and we have initialized a part of this struct  
(e.g. size).


Why nonsense? Since WOPCM is used/needed by several entities (agents)
then it is obvious that to properly partition wopcm into regions that
will satisfy all agents, arbiter need to know their specific requirements
(like fw sizes in case of HuC or GuC).

 to make it clean I will insist to have the guc wopcm region (or  
maybe

 the other region info) kept in uc level.


It will not be clean if you make calculation in one place and keep partial
results in other places. We can at most setup hw from uc code.

As I said the purpose of this series is to enable dynamic GuC WOPCM  
offset

and size calculation.


Sure. but and all I want is to do it in a right place.


it's not targeting any code refactoring and only serves
as a new feature enabling patch. The design principle of this series was  
to

provide clear new feature enabling by:
1) align with current code design and implementation.
2) provide correct hardware abstraction.
3) faultlessly enabled these new features. (e.g. dynamic size/offset  
calculation)

I think this series is now in a good shape to meet all above targets.



So we need arbiter :)

On the other hand, I do agree there always is some room to make our  
current

code clearer, but what we are talking about is further code refactoring.
Actually, I've already had some ideas of this. e.g. we could have some  
new

abstractions such as:

struct intel_wopcm {
 u32 size;
 /*any other global wopcm info*/
}

struct wopcm_region {
 u32 reserved; // reserved size in each region
 u32 offset; // offset of each region
 u32 size; // size of each region
};

struct intel_uc {
 struct wopcm_regions regions[];
 struct intel_uc_fw fws[];
 struct intel_guc guc;
 ...
}

struct intel_guc_dma {
 u32 fw_domains;
 lockable_reg size;
 lockable_reg offset;
 u32 flags; // e.g. loading HuC.
}

guc_dma_init()
guc_dma_hw_init()
guc_dma_xfer()

struct intel_guc {
 struct intel_guc_dma guc_dma;
 /*other guc objects*/
}

This would provide better software layer abstraction. but what I learned
from the 10 versions code submission is we need make things clear enough  
to
move forward. The lack of uc level abstraction is probably the reason  
why we

felt so frustrating about this part of code.


Yep. struct intel_uc will likely make few things cleaner.



Can we just move forward by aligning to the current code implementation?
since what we need now is enable this new features. and we definitely can
provide more code refactoring patches based on these changes later.


This is question to the maintainers.



Regards,
-Jackie

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

Re: [Intel-gfx] [igt-dev] [PATCH igt] igt/gem_exec_schedule: Trim max number of contexts used

[Antonio Argenziano]

On 13/02/18 01:26, Chris Wilson wrote:

icl offers a much reduced context space, and in its simplest setup we
cannot allocate one context per priority level, so trim the number and
reuse the same context for multiple priority requests.

Signed-off-by: Chris Wilson 
---
  tests/gem_exec_schedule.c | 38 +++---
  1 file changed, 23 insertions(+), 15 deletions(-)

diff --git a/tests/gem_exec_schedule.c b/tests/gem_exec_schedule.c
index 05f7ae38..ec02d994 100644
--- a/tests/gem_exec_schedule.c
+++ b/tests/gem_exec_schedule.c
@@ -43,6 +43,8 @@
  #define BUSY_QLEN 8
  #define MAX_ELSP_QLEN 16
  
+#define MAX_CONTEXTS 256

+
  IGT_TEST_DESCRIPTION("Check that we can control the order of execution");
  
  static void store_dword(int fd, uint32_t ctx, unsigned ring,

@@ -556,8 +558,8 @@ static void preemptive_hang(int fd, unsigned ring)
  static void deep(int fd, unsigned ring)
  {
  #define XS 8
-   const unsigned int nctx = MAX_PRIO - MIN_PRIO;
-   const unsigned size = ALIGN(4*nctx, 4096);
+   const unsigned int nreq = MAX_PRIO - MIN_PRIO;
+   const unsigned size = ALIGN(4*nreq, 4096);
struct timespec tv = {};
struct cork cork;
uint32_t result, dep[XS];
@@ -565,10 +567,9 @@ static void deep(int fd, unsigned ring)
uint32_t *ptr;
uint32_t *ctx;
  
-	ctx = malloc(sizeof(*ctx) * nctx);

-   for (int n = 0; n < nctx; n++) {
+   ctx = malloc(sizeof(*ctx) * MAX_CONTEXTS);
+   for (int n = 0; n < MAX_CONTEXTS; n++) {
ctx[n] = gem_context_create(fd);
-   gem_context_set_priority(fd, ctx[n], MAX_PRIO - nctx + n);
}
  
  	result = gem_create(fd, size);

@@ -592,7 +593,7 @@ static void deep(int fd, unsigned ring)
execbuf.buffers_ptr = to_user_pointer(obj);
execbuf.buffer_count = XS + 2;
execbuf.flags = ring;
-   for (int n = 0; n < nctx; n++) {
+   for (int n = 0; n < MAX_CONTEXTS; n++) {
execbuf.rsvd1 = ctx[n];
gem_execbuf(fd, );
}
@@ -603,22 +604,29 @@ static void deep(int fd, unsigned ring)
plug(fd, );
  
  	/* Create a deep dependency chain, with a few branches */

-   for (int n = 0; n < nctx && igt_seconds_elapsed() < 8; n++)
+   for (int n = 0; n < nreq && igt_seconds_elapsed() < 8; n++) {
+   uint32_t context = ctx[n % MAX_CONTEXTS];


Doesn't this introduce some intra-context dependency we didn't have 
before? Do we care?


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

Re: [Intel-gfx] [PATCH v2] drm/i915/psr: HW tracking for cursor moves to fix lags.

[Pandiyan, Dhinakaran]

On Tue, 2018-02-13 at 22:15 +, Chris Wilson wrote:
> Quoting Pandiyan, Dhinakaran (2018-02-13 22:10:48)
> > 
> > 
> > 
> > On Tue, 2018-02-13 at 21:54 +, Chris Wilson wrote:
> > > Quoting Dhinakaran Pandiyan (2018-02-13 21:46:13)
> > > > DRM_IOCTL_MODE_CURSOR results in a frontbuffer flush before the cursor
> > > > plane MMIOs are written to. But this flush is not necessary for PSR as
> > > > hardware tracking takes care of exiting PSR when the MMIO's are written.
> > > > 
> > > > Introduce a new fb_op_origin enum to differentiate flushes due to a BO
> > > > being pinned from those originating due to a dirty fbdev buffer. Now, 
> > > > this
> > > > enum can be ignored in psr_flush and psr_invalidate.
> > > > 
> > > > v2: Update comment in i915_gem_object_pin_to_display_plane. (Chris)
> > > > 
> > > > Cc: Rodrigo Vivi 
> > > > Cc: Ville Syrjälä 
> > > > Cc: Chris Wilson 
> > > > Signed-off-by: Dhinakaran Pandiyan 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.h  |  1 +
> > > >  drivers/gpu/drm/i915/i915_gem.c  | 11 +--
> > > >  drivers/gpu/drm/i915/intel_psr.c |  6 --
> > > >  3 files changed, 14 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 81886b74c750..3bf6c6ec0509 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -637,6 +637,7 @@ enum fb_op_origin {
> > > > ORIGIN_CS,
> > > > ORIGIN_FLIP,
> > > > ORIGIN_DIRTYFB,
> > > > +   ORIGIN_PINNEDFB,
> > > >  };
> > > >  
> > > >  struct intel_fbc {
> > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > > > b/drivers/gpu/drm/i915/i915_gem.c
> > > > index fc68b35854df..405acf3562de 100644
> > > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > > @@ -4139,9 +4139,16 @@ i915_gem_object_pin_to_display_plane(struct 
> > > > drm_i915_gem_object *obj,
> > > >  
> > > > vma->display_alignment = max_t(u64, vma->display_alignment, 
> > > > alignment);
> > > >  
> > > > -   /* Treat this as an end-of-frame, like 
> > > > intel_user_framebuffer_dirty() */
> > > > +   /* Treat this as an end-of-frame, like 
> > > > intel_user_framebuffer_dirty() to
> > > > +* flush the caches.
> > > > +*/
> > > > __i915_gem_object_flush_for_display(obj);
> > > > -   intel_fb_obj_flush(obj, ORIGIN_DIRTYFB);
> > > > +
> > > > +   /* Features like PSR might want to rely on HW to do the 
> > > > frontbuffer
> > > > +* flush, pass origin as ORIGIN_PINNEDFB rather than 
> > > > ORIGIN_DIRTYFB
> > > > +* so that their flush implementations can handle it 
> > > > accordingly.
> > > > +*/
> > > 
> > > So why it is different? Why can't the dirtyfb ioctl benefit from HW, 
> > > which the
> > > application is meant to call every frame to *all* dirty framebuffers
> > > (which include cursors in atomic)?
> > > 
> > 
> > Because the hardware requires a write to one of the pipe registers. When
> > applications write to the buffer via fbdev, it doesn't lead to pipe MMIO
> > write and hence does not benefit from HW triggered PSR exit.
> 
> Somewhere you have to have that explanation, that you rely on a
> subsequent mmioflip of the framebuffer to trigger the frontbuffer flush.


diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index 405acf3562de..c669fef5d388 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4071,9 +4071,13 @@ int i915_gem_set_caching_ioctl(struct drm_device
*dev, void *data,
 }

 /*
- * Prepare buffer for display plane (scanout, cursors, etc).
- * Can be called from an uninterruptible phase (modesetting) and allows
- * any flushes to be pipelined (for pageflips).
+ * Prepare buffer for display plane (scanout, cursors, etc). Can be
called from
+ * an uninterruptible phase (modesetting) and allows any flushes to be
pipelined
+ * (for pageflips). We only flush the caches while preparing the buffer
for
+ * display and this may not lead to the buffer being scanned out if
+ * intel_fb_obj_flush() consumers ignore ORIGIN_PINNEDFB. This is
useful because
+ * features like PSR can delegate the flush to HW, which gets triggered
when
+ * flip or cursor move MMIO's are written to.
  */
 struct i915_vma *
 i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj,


Like this?



> That probably also deserves lifting out of pin_to_display_plane as
> currently there's no requirement that pin_to_display is followed by a
> flip.

Does pin_to_display imply ready to scan out? And I didn't get the part
about "lifting out of pin_to_display_plane"



-DK


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

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/icl: new context descriptor support

[Daniele Ceraolo Spurio]

On 10/02/18 00:55, Chris Wilson wrote:

Quoting Oscar Mateo (2018-02-09 23:48:38)



On 02/09/2018 03:28 PM, Daniele Ceraolo Spurio wrote:

From: "Ceraolo Spurio, Daniele" 

Starting from Gen11 the context descriptor format has been updated in
the HW. The hw_id field has been considerably reduced in size and engine
class and instance fields have been added.

There is a slight name clashing issue because the field that we call
hw_id is actually called SW Context ID in the specs for Gen11+.

With the current size of the hw_id field we can have a maximum of 2k
contexts at any time, but we could use the sw_counter field (which is sw
defined) to increase that because the HW requirement is that
engine_id + sw id + sw_counter is a unique number.
GuC uses a similar method to support more contexts but does its tracking
at lrc level. To avoid doing an implementation that will need to be
reworked once GuC support lands, defer it for now and mark it as TODO.

v2: rebased, add documentation, fix GEN11_ENGINE_INSTANCE_SHIFT
v3: rebased, bring back lost code from i915_gem_context.c
v4: make TODO comment more generic

Cc: Oscar Mateo 
Signed-off-by: Daniele Ceraolo Spurio 


Reviewed-by: Oscar Mateo 


---
   drivers/gpu/drm/i915/i915_drv.h |  1 +
   drivers/gpu/drm/i915/i915_gem_context.c | 11 +--
   drivers/gpu/drm/i915/i915_reg.h |  4 
   drivers/gpu/drm/i915/intel_lrc.c| 28 +++-
   4 files changed, 41 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7db3557b945c..acaa63f8237d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2093,6 +2093,7 @@ struct drm_i915_private {
*/
   struct ida hw_ida;
   #define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */
+#define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */
   } contexts;
   
   u32 fdi_rx_config;

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 3d75f484f6e5..45b0b78aca3f 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -211,9 +211,15 @@ static void context_close(struct i915_gem_context *ctx)
   static int assign_hw_id(struct drm_i915_private *dev_priv, unsigned *out)
   {
   int ret;
+ unsigned int max;
+
+ if (INTEL_GEN(dev_priv) >= 11)
+ max = GEN11_MAX_CONTEXT_HW_ID;
+ else
+ max = MAX_CONTEXT_HW_ID;
   
   ret = ida_simple_get(_priv->contexts.hw_ida,

-  0, MAX_CONTEXT_HW_ID, GFP_KERNEL);
+  0, max, GFP_KERNEL);
   if (ret < 0) {
   /* Contexts are only released when no longer active.
* Flush any pending retires to hopefully release some
@@ -221,7 +227,7 @@ static int assign_hw_id(struct drm_i915_private *dev_priv, 
unsigned *out)
*/
   i915_gem_retire_requests(dev_priv);
   ret = ida_simple_get(_priv->contexts.hw_ida,
-  0, MAX_CONTEXT_HW_ID, GFP_KERNEL);
+  0, max, GFP_KERNEL);
   if (ret < 0)
   return ret;
   }
@@ -463,6 +469,7 @@ int i915_gem_contexts_init(struct drm_i915_private 
*dev_priv)
   
   /* Using the simple ida interface, the max is limited by sizeof(int) */

   BUILD_BUG_ON(MAX_CONTEXT_HW_ID > INT_MAX);
+ BUILD_BUG_ON(GEN11_MAX_CONTEXT_HW_ID > INT_MAX);
   ida_init(_priv->contexts.hw_ida);
   
   /* lowest priority; idle task */

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e9c79b560823..bd84e29d5399 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3869,6 +3869,10 @@ enum {
   
   #define GEN8_CTX_ID_SHIFT 32

   #define GEN8_CTX_ID_WIDTH 21
+#define GEN11_SW_CTX_ID_SHIFT 37
+#define GEN11_SW_CTX_ID_WIDTH 11
+#define GEN11_ENGINE_CLASS_SHIFT 61
+#define GEN11_ENGINE_INSTANCE_SHIFT 48
   
   #define CHV_CLK_CTL1_MMIO(0x101100)

   #define VLV_CLK_CTL2_MMIO(0x101104)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c2c8380a0121..3305fbba65e9 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -187,6 +187,18 @@ static void execlists_init_reg_state(u32 *reg_state,
*  bits 32-52:ctx ID, a globally unique tag
*  bits 53-54:mbz, reserved for use by hardware
*  bits 55-63:group ID, currently unused and set to 0
+ *
+ * Starting from Gen11, the upper dword of the descriptor has a new format:
+ *
+ *  bits 32-36:reserved
+ *  bits 37-47:SW context ID
+ *  bits 48:53:engine instance
+ *  bit 54:mbz, 

[Intel-gfx] ✗ Fi.CI.BAT: failure for PSR lag fixes (rev2)

[Patchwork]

== Series Details ==

Series: PSR lag fixes (rev2)
URL   : https://patchwork.freedesktop.org/series/38067/
State : failure

== Summary ==

Series 38067v2 PSR lag fixes
https://patchwork.freedesktop.org/api/1.0/series/38067/revisions/2/mbox/

Test kms_busy:
Subgroup basic-flip-b:
pass   -> INCOMPLETE (fi-cnl-y3)

fi-bdw-5557u total:288  pass:265  dwarn:0   dfail:0   fail:2   skip:21  
time:441s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:430s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:378s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:491s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:293s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:486s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:474s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:461s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:569s
fi-cnl-y3total:197  pass:185  dwarn:0   dfail:0   fail:0   skip:11 
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:424s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:296s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:513s
fi-hsw-4770  total:288  pass:259  dwarn:0   dfail:0   fail:2   skip:27  
time:411s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:413s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:461s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:415s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:462s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:496s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:601s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:430s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:506s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:528s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:495s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:483s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:418s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:433s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:541s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:400s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:469s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:457s

55dfdd18a566b5c632cbb34086b2a03410e810fb drm-tip: 2018y-02m-13d-18h-37m-11s UTC 
integration manifest
558a92e3776e drm/i915/psr: Wait for PSR transition to complete before exiting.
9d920a6e7906 drm/i915/psr: HW tracking for cursor moves to fix lags.
085f2a67eebd drm/i915/psr: Use more PSR HW tracking.

== Logs ==

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

Re: [Intel-gfx] [PATCH v2] drm/i915/psr: HW tracking for cursor moves to fix lags.

[Chris Wilson]

Quoting Pandiyan, Dhinakaran (2018-02-13 22:10:48)
> 
> 
> 
> On Tue, 2018-02-13 at 21:54 +, Chris Wilson wrote:
> > Quoting Dhinakaran Pandiyan (2018-02-13 21:46:13)
> > > DRM_IOCTL_MODE_CURSOR results in a frontbuffer flush before the cursor
> > > plane MMIOs are written to. But this flush is not necessary for PSR as
> > > hardware tracking takes care of exiting PSR when the MMIO's are written.
> > > 
> > > Introduce a new fb_op_origin enum to differentiate flushes due to a BO
> > > being pinned from those originating due to a dirty fbdev buffer. Now, this
> > > enum can be ignored in psr_flush and psr_invalidate.
> > > 
> > > v2: Update comment in i915_gem_object_pin_to_display_plane. (Chris)
> > > 
> > > Cc: Rodrigo Vivi 
> > > Cc: Ville Syrjälä 
> > > Cc: Chris Wilson 
> > > Signed-off-by: Dhinakaran Pandiyan 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h  |  1 +
> > >  drivers/gpu/drm/i915/i915_gem.c  | 11 +--
> > >  drivers/gpu/drm/i915/intel_psr.c |  6 --
> > >  3 files changed, 14 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 81886b74c750..3bf6c6ec0509 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -637,6 +637,7 @@ enum fb_op_origin {
> > > ORIGIN_CS,
> > > ORIGIN_FLIP,
> > > ORIGIN_DIRTYFB,
> > > +   ORIGIN_PINNEDFB,
> > >  };
> > >  
> > >  struct intel_fbc {
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > > b/drivers/gpu/drm/i915/i915_gem.c
> > > index fc68b35854df..405acf3562de 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -4139,9 +4139,16 @@ i915_gem_object_pin_to_display_plane(struct 
> > > drm_i915_gem_object *obj,
> > >  
> > > vma->display_alignment = max_t(u64, vma->display_alignment, 
> > > alignment);
> > >  
> > > -   /* Treat this as an end-of-frame, like 
> > > intel_user_framebuffer_dirty() */
> > > +   /* Treat this as an end-of-frame, like 
> > > intel_user_framebuffer_dirty() to
> > > +* flush the caches.
> > > +*/
> > > __i915_gem_object_flush_for_display(obj);
> > > -   intel_fb_obj_flush(obj, ORIGIN_DIRTYFB);
> > > +
> > > +   /* Features like PSR might want to rely on HW to do the 
> > > frontbuffer
> > > +* flush, pass origin as ORIGIN_PINNEDFB rather than 
> > > ORIGIN_DIRTYFB
> > > +* so that their flush implementations can handle it accordingly.
> > > +*/
> > 
> > So why it is different? Why can't the dirtyfb ioctl benefit from HW, which 
> > the
> > application is meant to call every frame to *all* dirty framebuffers
> > (which include cursors in atomic)?
> > 
> 
> Because the hardware requires a write to one of the pipe registers. When
> applications write to the buffer via fbdev, it doesn't lead to pipe MMIO
> write and hence does not benefit from HW triggered PSR exit.

Somewhere you have to have that explanation, that you rely on a
subsequent mmioflip of the framebuffer to trigger the frontbuffer flush.
That probably also deserves lifting out of pin_to_display_plane as
currently there's no requirement that pin_to_display is followed by a
flip.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/psr: HW tracking for cursor moves to fix lags.

[Pandiyan, Dhinakaran]

On Tue, 2018-02-13 at 21:54 +, Chris Wilson wrote:
> Quoting Dhinakaran Pandiyan (2018-02-13 21:46:13)
> > DRM_IOCTL_MODE_CURSOR results in a frontbuffer flush before the cursor
> > plane MMIOs are written to. But this flush is not necessary for PSR as
> > hardware tracking takes care of exiting PSR when the MMIO's are written.
> > 
> > Introduce a new fb_op_origin enum to differentiate flushes due to a BO
> > being pinned from those originating due to a dirty fbdev buffer. Now, this
> > enum can be ignored in psr_flush and psr_invalidate.
> > 
> > v2: Update comment in i915_gem_object_pin_to_display_plane. (Chris)
> > 
> > Cc: Rodrigo Vivi 
> > Cc: Ville Syrjälä 
> > Cc: Chris Wilson 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |  1 +
> >  drivers/gpu/drm/i915/i915_gem.c  | 11 +--
> >  drivers/gpu/drm/i915/intel_psr.c |  6 --
> >  3 files changed, 14 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 81886b74c750..3bf6c6ec0509 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -637,6 +637,7 @@ enum fb_op_origin {
> > ORIGIN_CS,
> > ORIGIN_FLIP,
> > ORIGIN_DIRTYFB,
> > +   ORIGIN_PINNEDFB,
> >  };
> >  
> >  struct intel_fbc {
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index fc68b35854df..405acf3562de 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -4139,9 +4139,16 @@ i915_gem_object_pin_to_display_plane(struct 
> > drm_i915_gem_object *obj,
> >  
> > vma->display_alignment = max_t(u64, vma->display_alignment, 
> > alignment);
> >  
> > -   /* Treat this as an end-of-frame, like 
> > intel_user_framebuffer_dirty() */
> > +   /* Treat this as an end-of-frame, like 
> > intel_user_framebuffer_dirty() to
> > +* flush the caches.
> > +*/
> > __i915_gem_object_flush_for_display(obj);
> > -   intel_fb_obj_flush(obj, ORIGIN_DIRTYFB);
> > +
> > +   /* Features like PSR might want to rely on HW to do the frontbuffer
> > +* flush, pass origin as ORIGIN_PINNEDFB rather than ORIGIN_DIRTYFB
> > +* so that their flush implementations can handle it accordingly.
> > +*/
> 
> So why it is different? Why can't the dirtyfb ioctl benefit from HW, which the
> application is meant to call every frame to *all* dirty framebuffers
> (which include cursors in atomic)?
> 

Because the hardware requires a write to one of the pipe registers. When
applications write to the buffer via fbdev, it doesn't lead to pipe MMIO
write and hence does not benefit from HW triggered PSR exit.




> > +   intel_fb_obj_flush(obj, ORIGIN_PINNEDFB);
> ___
> 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 05/20] drm/i915/icl: Interrupt handling

[Chris Wilson]

Quoting Oscar Mateo (2018-02-13 21:56:32)
> 
> 
> On 02/13/2018 11:18 AM, Daniele Ceraolo Spurio wrote:
> >
> >
> > On 13/02/18 08:37, Mika Kuoppala wrote:
> >> From: Tvrtko Ursulin 
> >> +static irqreturn_t
> >> +gen11_gt_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)
> >> +{
> >> +    irqreturn_t ret = IRQ_NONE;
> >> +    u16 irq[2][32];
> >> +    u32 dw, ident;
> >> +    unsigned long tmp;
> >> +    unsigned int bank, bit, engine;
> >> +    unsigned long wait_start, wait_end;
> >> +
> >> +    memset(irq, 0, sizeof(irq));
> >> +
> >> +    for (bank = 0; bank < 2; bank++) {
> >> +    if (master_ctl & GEN11_GT_DW_IRQ(bank)) {
> >> +    dw = I915_READ_FW(GEN11_GT_INTR_DW(bank));
> >> +    if (!dw)
> >> +    DRM_ERROR("GT_INTR_DW%u blank!\n", bank);
> >> +    tmp = dw;
> >> +    for_each_set_bit(bit, , 32) {
> >> +    I915_WRITE_FW(GEN11_IIR_REG_SELECTOR(bank), 1 << bit);
> >> +    wait_start = local_clock() >> 10;
> >> +    /* NB: Specs do not specify how long to spin wait.
> >> + * Taking 100us as an educated guess */
> >> +    wait_end = wait_start + 100;
> >> +    do {
> >> +    ident = 
> >> I915_READ_FW(GEN11_INTR_IDENTITY_REG(bank));
> >> +    } while (!(ident & GEN11_INTR_DATA_VALID) &&
> >> + !time_after((unsigned long)local_clock() >> 10, 
> >> wait_end));
> >
> > Patch 18/20 changes this to time_after64 and wait_end to u64, which 
> > looks like the correct way to handle this. Since splitting part of 
> > this loop out also helps making things cleaner, would it make sense to 
> > squash patch 18/20 into this one?
> >
> 
> Makes sense to me. Tvrtko, what do you think?

The squash should be made, but time_after64 is no more correct since the
native 32b/64b wrapped arithmetic is accurate. So what can be done here
is remove the casts and use time_after32() if we truly cared.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 05/20] drm/i915/icl: Interrupt handling

[Oscar Mateo]

On 02/13/2018 11:18 AM, Daniele Ceraolo Spurio wrote:



On 13/02/18 08:37, Mika Kuoppala wrote:

From: Tvrtko Ursulin 

v2: Rebase.

v3:
   * Remove DPF, it has been removed from SKL+.
   * Fix -internal rebase wrt. execlists interrupt handling.

v4: Rebase.

v5:
   * Updated for POR changes. (Daniele Ceraolo Spurio)
   * Merged with irq handling fixes by Daniele Ceraolo Spurio:
   * Simplify the code by using gen8_cs_irq_handler.
   * Fix interrupt handling for the upstream kernel.

v6:
   * Remove early bringup debug messages (Tvrtko)
   * Add NB about arbitrary spin wait timeout (Tvrtko)

v7 (from Paulo):
   * Don't try to write RO bits to registers.
   * Don't check for PCH types that don't exist. PCH interrupts are not
 here yet.

Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Oscar Mateo 
Signed-off-by: Paulo Zanoni 
---
  drivers/gpu/drm/i915/i915_irq.c | 210 


  drivers/gpu/drm/i915/intel_pm.c |   7 +-
  2 files changed, 216 insertions(+), 1 deletion(-)

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

index b886bd459acc..3a1de4e2a941 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -415,6 +415,9 @@ void gen6_enable_rps_interrupts(struct 
drm_i915_private *dev_priv)

  if (READ_ONCE(rps->interrupts_enabled))
  return;
  +    if (WARN_ON_ONCE(IS_GEN11(dev_priv)))
+    return;
+
  spin_lock_irq(_priv->irq_lock);
  WARN_ON_ONCE(rps->pm_iir);
  WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) & 
dev_priv->pm_rps_events);
@@ -431,6 +434,9 @@ void gen6_disable_rps_interrupts(struct 
drm_i915_private *dev_priv)

  if (!READ_ONCE(rps->interrupts_enabled))
  return;
  +    if (WARN_ON_ONCE(IS_GEN11(dev_priv)))
+    return;
+
  spin_lock_irq(_priv->irq_lock);
  rps->interrupts_enabled = false;
  @@ -2746,6 +2752,131 @@ static void __fini_wedge(struct wedge_me *w)
   (W)->i915;    \
   __fini_wedge((W)))
  +static __always_inline void
+gen11_cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
+{
+    gen8_cs_irq_handler(engine, iir, 0);
+}
+
+static irqreturn_t
+gen11_gt_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)
+{
+    irqreturn_t ret = IRQ_NONE;
+    u16 irq[2][32];
+    u32 dw, ident;
+    unsigned long tmp;
+    unsigned int bank, bit, engine;
+    unsigned long wait_start, wait_end;
+
+    memset(irq, 0, sizeof(irq));
+
+    for (bank = 0; bank < 2; bank++) {
+    if (master_ctl & GEN11_GT_DW_IRQ(bank)) {
+    dw = I915_READ_FW(GEN11_GT_INTR_DW(bank));
+    if (!dw)
+    DRM_ERROR("GT_INTR_DW%u blank!\n", bank);
+    tmp = dw;
+    for_each_set_bit(bit, , 32) {
+    I915_WRITE_FW(GEN11_IIR_REG_SELECTOR(bank), 1 << bit);
+    wait_start = local_clock() >> 10;
+    /* NB: Specs do not specify how long to spin wait.
+ * Taking 100us as an educated guess */
+    wait_end = wait_start + 100;
+    do {
+    ident = 
I915_READ_FW(GEN11_INTR_IDENTITY_REG(bank));

+    } while (!(ident & GEN11_INTR_DATA_VALID) &&
+ !time_after((unsigned long)local_clock() >> 10, 
wait_end));


Patch 18/20 changes this to time_after64 and wait_end to u64, which 
looks like the correct way to handle this. Since splitting part of 
this loop out also helps making things cleaner, would it make sense to 
squash patch 18/20 into this one?




Makes sense to me. Tvrtko, what do you think?


+
+    if (!(ident & GEN11_INTR_DATA_VALID))
+    DRM_ERROR("INTR_IDENTITY_REG%u:%u timed out!\n",
+  bank, bit);


If the data is not valid we should probably skip writing it to the 
irq[bank][bit] field as we might be writing an incorrect value.



+
+    irq[bank][bit] = ident & GEN11_INTR_ENGINE_MASK;
+    if (!irq[bank][bit])
+    DRM_ERROR("INTR_IDENTITY_REG%u:%u blank!\n",
+  bank, bit);


As mentioned on the previous review, I believe it is actually possible 
to get a blank identity register due to double buffering of interrupts 
if a second interrupt arrives between reading GT_INTR_DW and reading 
GEN11_INTR_IDENTITY, as both interrupts will be serviced on the first 
iteration but GT_INTR_DW will still report the second interrupt after 
being cleared once. We can just drop the error here as nothing bas 
should happen afterwards



+ I915_WRITE_FW(GEN11_INTR_IDENTITY_REG(bank), ident);
+    }
+    I915_WRITE_FW(GEN11_GT_INTR_DW(bank), dw);
+    }
+    }
+
+    if (irq[0][GEN11_RCS0]) 

Re: [Intel-gfx] [PATCH v2] drm/i915/psr: HW tracking for cursor moves to fix lags.

[Chris Wilson]

Quoting Dhinakaran Pandiyan (2018-02-13 21:46:13)
> DRM_IOCTL_MODE_CURSOR results in a frontbuffer flush before the cursor
> plane MMIOs are written to. But this flush is not necessary for PSR as
> hardware tracking takes care of exiting PSR when the MMIO's are written.
> 
> Introduce a new fb_op_origin enum to differentiate flushes due to a BO
> being pinned from those originating due to a dirty fbdev buffer. Now, this
> enum can be ignored in psr_flush and psr_invalidate.
> 
> v2: Update comment in i915_gem_object_pin_to_display_plane. (Chris)
> 
> Cc: Rodrigo Vivi 
> Cc: Ville Syrjälä 
> Cc: Chris Wilson 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/i915_gem.c  | 11 +--
>  drivers/gpu/drm/i915/intel_psr.c |  6 --
>  3 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 81886b74c750..3bf6c6ec0509 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -637,6 +637,7 @@ enum fb_op_origin {
> ORIGIN_CS,
> ORIGIN_FLIP,
> ORIGIN_DIRTYFB,
> +   ORIGIN_PINNEDFB,
>  };
>  
>  struct intel_fbc {
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index fc68b35854df..405acf3562de 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4139,9 +4139,16 @@ i915_gem_object_pin_to_display_plane(struct 
> drm_i915_gem_object *obj,
>  
> vma->display_alignment = max_t(u64, vma->display_alignment, 
> alignment);
>  
> -   /* Treat this as an end-of-frame, like intel_user_framebuffer_dirty() 
> */
> +   /* Treat this as an end-of-frame, like intel_user_framebuffer_dirty() 
> to
> +* flush the caches.
> +*/
> __i915_gem_object_flush_for_display(obj);
> -   intel_fb_obj_flush(obj, ORIGIN_DIRTYFB);
> +
> +   /* Features like PSR might want to rely on HW to do the frontbuffer
> +* flush, pass origin as ORIGIN_PINNEDFB rather than ORIGIN_DIRTYFB
> +* so that their flush implementations can handle it accordingly.
> +*/

So why it is different? Why can't the dirtyfb ioctl benefit from HW, which the
application is meant to call every frame to *all* dirty framebuffers
(which include cursors in atomic)?

> +   intel_fb_obj_flush(obj, ORIGIN_PINNEDFB);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v10 5/7] drm/i915/guc: Add HuC firmware size related restriction for Gen9 and CNL A0

[Yaodong Li]

On 02/13/2018 08:06 AM, Michal Wajdeczko wrote:

+static inline int check_huc_fw_fits(struct intel_guc_wopcm *guc_wopcm,

+    u32 huc_fw_size)
+{
+    /*
+ * On Gen9 & CNL A0, hardware requires the total available GuC 
WOPCM

+ * size to be larger than or equal to HuC firmware size. Otherwise,
+ * firmware uploading would fail.
+ */
+    if (guc_wopcm->size - GUC_WOPCM_RESERVED < huc_fw_size)


What if guc_wopcm->size < GUC_WOPCM_RESERVED ?


we've already had following check before this. which had guaranteed
guc_wopcm->size >= guc_fw_size + reserved, thus,
guc_wopcm->size > GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED
so, guc_wopcm->size > GUC_WOPCM_RESERVED:-)

    reserved = GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
    if ((guc_fw_size + reserved) > guc_wopcm->size) {
        DRM_DEBUG_DRIVER("No enough GuC WOPCM for GuC firmware.\n");
        return -E2BIG;
    }

+    return -E2BIG;
+
+    return 0;
+}
+
 static inline int gen9_check_dword_gap(struct intel_guc_wopcm 
*guc_wopcm)

 {
 u32 guc_wopcm_start;
@@ -40,15 +54,19 @@ static inline int gen9_check_dword_gap(struct 
intel_guc_wopcm *guc_wopcm)

 return 0;
 }
-static inline int guc_wopcm_size_check(struct intel_guc *guc)
+static inline int guc_wopcm_size_check(struct intel_guc *guc, u32 
huc_fw_size)

 {
 struct drm_i915_private *i915 = guc_to_i915(guc);
 struct intel_guc_wopcm *guc_wopcm = >wopcm;
+    int err = 0;
if (IS_GEN9(i915))
-    return gen9_check_dword_gap(guc_wopcm);
+    err = gen9_check_dword_gap(guc_wopcm);
-    return 0;
+    if (IS_GEN9(i915) || IS_CNL_REVID(i915, CNL_REVID_A0, 
CNL_REVID_A0))

+    err = check_huc_fw_fits(guc_wopcm, huc_fw_size);


Hmm, what if gen9_check_dword_gap() fails but check_huc_fw_fits() 
passes ?



oops! will fix this.:-)

+
+    return err;
 }
/**
@@ -121,7 +139,7 @@ int intel_guc_wopcm_init(struct intel_guc_wopcm 
*guc_wopcm, u32 guc_fw_size,

 guc->wopcm.size = size;
 guc->wopcm.top = top;
-    err = guc_wopcm_size_check(guc);
+    err = guc_wopcm_size_check(guc, huc_fw_size);
 if (err) {
 DRM_DEBUG_DRIVER("GuC WOPCM size check failed.\n");
 return err;


I'm more and more convinced that we should use "intel_wopcm" to make
partition and all these checks

These are all GuC wopcm related, it only checks guc wopcm size. so I am 
wondering whether
I am still misunderstanding anything here?since the purpose of these 
calculation and checks are
clearly all GuC related. To be more precisely GuC DMA related. The 
driver's responsibility is to
calculate the GuC DMA offset and GuC wopcm size values based on guc/huc 
fw sizes and

all these checks are all for the correctness for the GuC  wopcm size.
I don't see any reason why these should be a part of global intel_wopcm 
even if we really
want to keep something like wopcm_regions for both guc/huc(though I 
still don't know what
the benefit real is to keep something like HuC wopcm region except for 
sth like debugfs output?).
even in this case, we still at least keep these as a part of  GuC since 
we really need it to setup
GuC HW :- Or do you mean we should create an intel_wopcm to carry info 
such as
global WOPCM size,guc_fw_size and huc_fw_size? Sorry I am really a 
little bit confused here:-(

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

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Split out functions for different kinds of workarounds

[Chris Wilson]

Quoting Oscar Mateo (2018-02-13 21:36:34)
> 
> 
> On 2/13/2018 12:54 PM, Chris Wilson wrote:
> > Quoting Oscar Mateo (2018-02-13 19:13:29)
> >> There are different kind of workarounds (those that modify registers that
> >> live in the context image, those that modify global registers, those that
> >> whitelist registers, etc...) and they have different requirements in terms
> >> of where they are applied and how. Also, by splitting them apart, it should
> >> be easier to decide where a new workaround should go.
> >>
> >> v2:
> >>- Add multiple MISSING_CASE
> >>- Rebased
> >>
> >> v3:
> >>- Rename mmio_workarounds to gt_workarounds (Chris, Mika)
> >>- Create empty placeholders for BDW and CHV GT WAs
> >>- Rebased
> >>
> >> v4: Rebased
> >>
> >> Signed-off-by: Oscar Mateo 
> >> Cc: Chris Wilson 
> >> Cc: Mika Kuoppala 
> >> Cc: Ville Syrjälä 
> >> ---
> >>   drivers/gpu/drm/i915/i915_gem.c  |   3 +
> >>   drivers/gpu/drm/i915/i915_gem_context.c  |   6 +
> >>   drivers/gpu/drm/i915/intel_lrc.c |  10 +-
> >>   drivers/gpu/drm/i915/intel_ringbuffer.c  |   4 +-
> >>   drivers/gpu/drm/i915/intel_workarounds.c | 627 
> >> +++
> >>   drivers/gpu/drm/i915/intel_workarounds.h |   8 +-
> >>   6 files changed, 414 insertions(+), 244 deletions(-)
> >>
> >> @@ -452,11 +453,16 @@ static bool needs_preempt_context(struct 
> >> drm_i915_private *i915)
> >>   int i915_gem_contexts_init(struct drm_i915_private *dev_priv)
> >>   {
> >>  struct i915_gem_context *ctx;
> >> +   int ret;
> >>   
> >>  /* Reassure ourselves we are only called once */
> >>  GEM_BUG_ON(dev_priv->kernel_context);
> >>  GEM_BUG_ON(dev_priv->preempt_context);
> >>   
> >> +   ret = intel_ctx_workarounds_init(dev_priv);
> >> +   if (ret)
> >> +   return ret;
> >> +
> >>  INIT_LIST_HEAD(_priv->contexts.list);
> >>  INIT_WORK(_priv->contexts.free_work, contexts_free_worker);
> >>  init_llist_head(_priv->contexts.free_list);
> >>   static void reset_irq(struct intel_engine_cs *engine)
> >> @@ -1904,7 +1908,7 @@ static int gen8_init_rcs_context(struct 
> >> drm_i915_gem_request *req)
> >>   {
> >>  int ret;
> >>   
> >> -   ret = intel_ring_workarounds_emit(req);
> >> +   ret = intel_ctx_workarounds_emit(req);
> >>  if (ret)
> >>  return ret;
> >>   
> >> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> >> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> >> index ec580f5..0b6c20f 100644
> >> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> >> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> >> @@ -600,7 +600,7 @@ static int intel_rcs_ctx_init(struct 
> >> drm_i915_gem_request *req)
> >>   {
> >>  int ret;
> >>   
> >> -   ret = intel_ring_workarounds_emit(req);
> >> +   ret = intel_ctx_workarounds_emit(req);
> >>  if (ret != 0)
> >>  return ret;
> > Since the context w/a are only used once, is it worth separating the
> > init and emit any more?
> > -Chris
> 
> Probably not. In fact, as I mentioned in another message, it probably 
> doesn't make sense to "emit" these workarounds anymore (they could be 
> applied directly to the HW as MMIO writes and they should stick to the 
> golden context). Thoughts?

The ctx_wa are the ones we use LRI for, right? And we use LRI to be sure
the context is loaded (and HW powered)  before the mmio.

I'm happy for whatever is the simplest we can do to achieve working hw
:)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915/psr: HW tracking for cursor moves to fix lags.

[Dhinakaran Pandiyan]

DRM_IOCTL_MODE_CURSOR results in a frontbuffer flush before the cursor
plane MMIOs are written to. But this flush is not necessary for PSR as
hardware tracking takes care of exiting PSR when the MMIO's are written.

Introduce a new fb_op_origin enum to differentiate flushes due to a BO
being pinned from those originating due to a dirty fbdev buffer. Now, this
enum can be ignored in psr_flush and psr_invalidate.

v2: Update comment in i915_gem_object_pin_to_display_plane. (Chris)

Cc: Rodrigo Vivi 
Cc: Ville Syrjälä 
Cc: Chris Wilson 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_gem.c  | 11 +--
 drivers/gpu/drm/i915/intel_psr.c |  6 --
 3 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 81886b74c750..3bf6c6ec0509 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -637,6 +637,7 @@ enum fb_op_origin {
ORIGIN_CS,
ORIGIN_FLIP,
ORIGIN_DIRTYFB,
+   ORIGIN_PINNEDFB,
 };
 
 struct intel_fbc {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fc68b35854df..405acf3562de 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4139,9 +4139,16 @@ i915_gem_object_pin_to_display_plane(struct 
drm_i915_gem_object *obj,
 
vma->display_alignment = max_t(u64, vma->display_alignment, alignment);
 
-   /* Treat this as an end-of-frame, like intel_user_framebuffer_dirty() */
+   /* Treat this as an end-of-frame, like intel_user_framebuffer_dirty() to
+* flush the caches.
+*/
__i915_gem_object_flush_for_display(obj);
-   intel_fb_obj_flush(obj, ORIGIN_DIRTYFB);
+
+   /* Features like PSR might want to rely on HW to do the frontbuffer
+* flush, pass origin as ORIGIN_PINNEDFB rather than ORIGIN_DIRTYFB
+* so that their flush implementations can handle it accordingly.
+*/
+   intel_fb_obj_flush(obj, ORIGIN_PINNEDFB);
 
/* It should now be out of any other write domains, and we can update
 * the domain values for our changes.
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 2a31c7cbdb41..ddfabdff3dea 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -842,7 +842,8 @@ void intel_psr_invalidate(struct drm_i915_private *dev_priv,
if (!CAN_PSR(dev_priv))
return;
 
-   if (dev_priv->psr.has_hw_tracking && origin == ORIGIN_FLIP)
+   if (dev_priv->psr.has_hw_tracking &&
+   (origin == ORIGIN_FLIP || origin == ORIGIN_PINNEDFB))
return;
 
mutex_lock(_priv->psr.lock);
@@ -885,7 +886,8 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
if (!CAN_PSR(dev_priv))
return;
 
-   if (dev_priv->psr.has_hw_tracking && origin == ORIGIN_FLIP)
+   if (dev_priv->psr.has_hw_tracking &&
+   (origin == ORIGIN_FLIP || origin == ORIGIN_PINNEDFB))
return;
 
mutex_lock(_priv->psr.lock);
-- 
2.14.1

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for ICL GEM enabling (v2)

[Patchwork]

== Series Details ==

Series: ICL GEM enabling (v2)
URL   : https://patchwork.freedesktop.org/series/38174/
State : failure

== Summary ==

Test drv_module_reload:
Subgroup basic-reload:
pass   -> DMESG-FAIL (shard-snb)
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank-interruptible:
fail   -> PASS   (shard-hsw) fdo#102887 +1
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
skip   -> PASS   (shard-snb) fdo#102365

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

shard-apltotal:3344 pass:1730 dwarn:1   dfail:0   fail:20  skip:1591 
time:13824s
shard-hswtotal:3427 pass:1720 dwarn:1   dfail:0   fail:51  skip:1654 
time:14731s
shard-snbtotal:3330 pass:1312 dwarn:1   dfail:1   fail:9   skip:2007 
time:7352s
Blacklisted hosts:
shard-kbltotal:3370 pass:1877 dwarn:1   dfail:0   fail:21  skip:1470 
time:10942s

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Split out functions for different kinds of workarounds

[Oscar Mateo]

On 2/13/2018 12:54 PM, Chris Wilson wrote:

Quoting Oscar Mateo (2018-02-13 19:13:29)

There are different kind of workarounds (those that modify registers that
live in the context image, those that modify global registers, those that
whitelist registers, etc...) and they have different requirements in terms
of where they are applied and how. Also, by splitting them apart, it should
be easier to decide where a new workaround should go.

v2:
   - Add multiple MISSING_CASE
   - Rebased

v3:
   - Rename mmio_workarounds to gt_workarounds (Chris, Mika)
   - Create empty placeholders for BDW and CHV GT WAs
   - Rebased

v4: Rebased

Signed-off-by: Oscar Mateo 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Ville Syrjälä 
---
  drivers/gpu/drm/i915/i915_gem.c  |   3 +
  drivers/gpu/drm/i915/i915_gem_context.c  |   6 +
  drivers/gpu/drm/i915/intel_lrc.c |  10 +-
  drivers/gpu/drm/i915/intel_ringbuffer.c  |   4 +-
  drivers/gpu/drm/i915/intel_workarounds.c | 627 +++
  drivers/gpu/drm/i915/intel_workarounds.h |   8 +-
  6 files changed, 414 insertions(+), 244 deletions(-)

@@ -452,11 +453,16 @@ static bool needs_preempt_context(struct drm_i915_private 
*i915)
  int i915_gem_contexts_init(struct drm_i915_private *dev_priv)
  {
 struct i915_gem_context *ctx;
+   int ret;
  
 /* Reassure ourselves we are only called once */

 GEM_BUG_ON(dev_priv->kernel_context);
 GEM_BUG_ON(dev_priv->preempt_context);
  
+   ret = intel_ctx_workarounds_init(dev_priv);

+   if (ret)
+   return ret;
+
 INIT_LIST_HEAD(_priv->contexts.list);
 INIT_WORK(_priv->contexts.free_work, contexts_free_worker);
 init_llist_head(_priv->contexts.free_list);
  static void reset_irq(struct intel_engine_cs *engine)
@@ -1904,7 +1908,7 @@ static int gen8_init_rcs_context(struct 
drm_i915_gem_request *req)
  {
 int ret;
  
-   ret = intel_ring_workarounds_emit(req);

+   ret = intel_ctx_workarounds_emit(req);
 if (ret)
 return ret;
  
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c

index ec580f5..0b6c20f 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -600,7 +600,7 @@ static int intel_rcs_ctx_init(struct drm_i915_gem_request 
*req)
  {
 int ret;
  
-   ret = intel_ring_workarounds_emit(req);

+   ret = intel_ctx_workarounds_emit(req);
 if (ret != 0)
 return ret;

Since the context w/a are only used once, is it worth separating the
init and emit any more?
-Chris


Probably not. In fact, as I mentioned in another message, it probably 
doesn't make sense to "emit" these workarounds anymore (they could be 
applied directly to the HW as MMIO writes and they should stick to the 
golden context). Thoughts?

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

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Create a new category of display WAs

[Oscar Mateo]

On 2/13/2018 12:50 PM, Chris Wilson wrote:

Quoting Jani Nikula (2018-02-13 20:02:55)

On Tue, 13 Feb 2018, Oscar Mateo  wrote:

@@ -8979,6 +8701,7 @@ static void i830_init_clock_gating(struct 
drm_i915_private *dev_priv)
  void intel_init_clock_gating(struct drm_i915_private *dev_priv)
  {
   dev_priv->display.init_clock_gating(dev_priv);
+ intel_disp_workarounds_apply(dev_priv);

Please don't abbreviate display to disp, use the full word instead,
throughout the series. Rationale:

And in general, use the full name for global functions and data. They
are written infrequently so not overburdensome, but the clarity is a
good reward. Locals by contrast quite often are more readable when using
(consistent) shorthand, or at least I think so.
-Chris


Sure, makes sense. I'll rename a few things and resend.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] drm-misc-next for 4.17

[Sean Paul]

Hi Dave,
This is the last spam from me today. Here's the -misc-next pull for the past
couple of months. Given how long 4.15 took to get out the door, it's not
all that big, probably offset by the holidays.

Anyways, lots of good stuff in here for you.


drm-misc-next-2018-02-13:
drm-misc-next for 4.17:

UAPI Changes:
- drm/vc4: Expose performance counters to userspace (Boris)

Cross-subsystem Changes:
- MAINTAINERS: Linus to maintain panel-arm-versatile in -misc (Linus)

Core Changes:
- Only use swiotlb when necessary (Chunming)

Driver Changes:
- drm/panel: Add support for ARM Versatile panels (Linus)
- pl111: Improvements around versatile panel support (Linus)


Tagged on 2018-02-06:
drm-misc-next for 4.17:

UAPI Changes:
- Validate mode flags + type (Ville)
- Deprecate unused mode flags PIXMUX, BCAST (Ville)
- Deprecate unused mode types BUILTIN, CRTC_C, CLOCK_C, DEFAULT (Ville)

Cross-subsystem Changes:
- MAINTAINERS: s/Daniel/Maarten/ for drm-misc (Daniel)

Core Changes:
- gem: Export gem functions for drivers to use (Samuel)
- bridge: Introduce bridge timings in drm_bridge (Linus)
- dma-buf: Allow exclusive fence to be bundled in fence array when
   calling reservation_object_get_fences_rcu (Christian)
- dp: Add training pattern 4 and HBR3 support to dp helpers (Manasi)
- fourcc: Add alpha bit to formats to avoid driver format LUTs (Maxime)
- mode: Various cleanups + add new device-wide .mode_valid hook (Ville)
- atomic: Fix state leak when non-blocking commits fail (Leo)
  NOTE: IIRC, this was cross-picked to -fixes so it might fall out
- crc: Allow polling on the data fd (Maarten)

Driver Changes:
- bridge/vga-dac: Add THS8134* support (Linus)
- tinydrm: Various MIPI DBI improvements/cleanups (Noralf)
- bridge/dw-mipi-dsi: Cleanups + use create_packet helper (Brian)
- drm/sun4i: Add Display Engine frontend support (Maxime)
- drm/sun4i: Add zpos support + increase num planes from 2 to 4 (Maxime)
- various: Use drm_mode_get_hv_timing() to fill plane clip rectangle (Ville)
- stm: Add 8-bit clut support, add dsi phy v1.31 support, +fixes (Phillipe)

Cc: Boris Brezillon 
Cc: Chunming Zhou 
Cc: Samuel Li 
Cc: Linus Walleij 
Cc: Noralf Trønnes 
Cc: Brian Norris 
Cc: Maxime Ripard 
Cc: Ville Syrjala 
Cc: Christian König 
Cc: Manasi Navare 
Cc: Philippe Cornu 
Cc: Leo (Sunpeng) Li 
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 

Cheers, Sean


The following changes since commit 4a6cc7a44e98a0460bd094b68c75f0705fdc450a:

  BackMerge tag 'v4.15-rc8' into drm-next (2018-01-18 09:32:15 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-02-13

for you to fetch changes up to 1bc3d3cce8c3b44c2b5ac6cee98c830bb40e6b0f:

  drm/radeon: only enable swiotlb path when need v2 (2018-02-13 13:35:14 -0500)


drm-misc-next for 4.17:

UAPI Changes:
- drm/vc4: Expose performance counters to userspace (Boris)

Cross-subsystem Changes:
- MAINTAINERS: Linus to maintain panel-arm-versatile in -misc (Linus)

Core Changes:
- Only use swiotlb when necessary (Chunming)

Driver Changes:
- drm/panel: Add support for ARM Versatile panels (Linus)
- pl111: Improvements around versatile panel support (Linus)


Tagged on 2018-02-06:
drm-misc-next for 4.17:

UAPI Changes:
- Validate mode flags + type (Ville)
- Deprecate unused mode flags PIXMUX, BCAST (Ville)
- Deprecate unused mode types BUILTIN, CRTC_C, CLOCK_C, DEFAULT (Ville)

Cross-subsystem Changes:
- MAINTAINERS: s/Daniel/Maarten/ for drm-misc (Daniel)

Core Changes:
- gem: Export gem functions for drivers to use (Samuel)
- bridge: Introduce bridge timings in drm_bridge (Linus)
- dma-buf: Allow exclusive fence to be bundled in fence array when
   calling reservation_object_get_fences_rcu (Christian)
- dp: Add training pattern 4 and HBR3 support to dp helpers (Manasi)
- fourcc: Add alpha bit to formats to avoid driver format LUTs (Maxime)
- mode: Various cleanups + add new device-wide .mode_valid hook (Ville)
- atomic: Fix state leak when non-blocking commits fail (Leo)
  NOTE: IIRC, this was cross-picked to -fixes so it might fall out
- crc: Allow polling on the data fd (Maarten)

Driver Changes:
- bridge/vga-dac: Add THS8134* support (Linus)
- tinydrm: Various MIPI DBI improvements/cleanups (Noralf)
- bridge/dw-mipi-dsi: Cleanups + use create_packet helper (Brian)
- drm/sun4i: Add Display Engine frontend support (Maxime)
- drm/sun4i: Add zpos support + increase num planes from 2 to 4 

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Split out functions for different kinds of workarounds

[Chris Wilson]

Quoting Oscar Mateo (2018-02-13 19:13:29)
> There are different kind of workarounds (those that modify registers that
> live in the context image, those that modify global registers, those that
> whitelist registers, etc...) and they have different requirements in terms
> of where they are applied and how. Also, by splitting them apart, it should
> be easier to decide where a new workaround should go.
> 
> v2:
>   - Add multiple MISSING_CASE
>   - Rebased
> 
> v3:
>   - Rename mmio_workarounds to gt_workarounds (Chris, Mika)
>   - Create empty placeholders for BDW and CHV GT WAs
>   - Rebased
> 
> v4: Rebased
> 
> Signed-off-by: Oscar Mateo 
> Cc: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_gem.c  |   3 +
>  drivers/gpu/drm/i915/i915_gem_context.c  |   6 +
>  drivers/gpu/drm/i915/intel_lrc.c |  10 +-
>  drivers/gpu/drm/i915/intel_ringbuffer.c  |   4 +-
>  drivers/gpu/drm/i915/intel_workarounds.c | 627 
> +++
>  drivers/gpu/drm/i915/intel_workarounds.h |   8 +-
>  6 files changed, 414 insertions(+), 244 deletions(-)
> 
> @@ -452,11 +453,16 @@ static bool needs_preempt_context(struct 
> drm_i915_private *i915)
>  int i915_gem_contexts_init(struct drm_i915_private *dev_priv)
>  {
> struct i915_gem_context *ctx;
> +   int ret;
>  
> /* Reassure ourselves we are only called once */
> GEM_BUG_ON(dev_priv->kernel_context);
> GEM_BUG_ON(dev_priv->preempt_context);
>  
> +   ret = intel_ctx_workarounds_init(dev_priv);
> +   if (ret)
> +   return ret;
> +
> INIT_LIST_HEAD(_priv->contexts.list);
> INIT_WORK(_priv->contexts.free_work, contexts_free_worker);
> init_llist_head(_priv->contexts.free_list);

>  static void reset_irq(struct intel_engine_cs *engine)
> @@ -1904,7 +1908,7 @@ static int gen8_init_rcs_context(struct 
> drm_i915_gem_request *req)
>  {
> int ret;
>  
> -   ret = intel_ring_workarounds_emit(req);
> +   ret = intel_ctx_workarounds_emit(req);
> if (ret)
> return ret;
>  
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index ec580f5..0b6c20f 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -600,7 +600,7 @@ static int intel_rcs_ctx_init(struct drm_i915_gem_request 
> *req)
>  {
> int ret;
>  
> -   ret = intel_ring_workarounds_emit(req);
> +   ret = intel_ctx_workarounds_emit(req);
> if (ret != 0)
> return ret;

Since the context w/a are only used once, is it worth separating the
init and emit any more?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Create a new category of display WAs

[Chris Wilson]

Quoting Jani Nikula (2018-02-13 20:02:55)
> On Tue, 13 Feb 2018, Oscar Mateo  wrote:
> > @@ -8979,6 +8701,7 @@ static void i830_init_clock_gating(struct 
> > drm_i915_private *dev_priv)
> >  void intel_init_clock_gating(struct drm_i915_private *dev_priv)
> >  {
> >   dev_priv->display.init_clock_gating(dev_priv);
> > + intel_disp_workarounds_apply(dev_priv);
> 
> Please don't abbreviate display to disp, use the full word instead,
> throughout the series. Rationale:

And in general, use the full name for global functions and data. They
are written infrequently so not overburdensome, but the clarity is a
good reward. Locals by contrast quite often are more readable when using
(consistent) shorthand, or at least I think so.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] redo

[Chris Wilson]

Quoting Chris Wilson (2018-02-13 19:29:18)
> ---
>  sound/pci/hda/hda_codec.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
> index e018ecbf78a8..afa5f5155220 100644
> --- a/sound/pci/hda/hda_codec.c
> +++ b/sound/pci/hda/hda_codec.c
> @@ -2711,12 +2711,15 @@ static unsigned int hda_sync_power_state(struct 
> hda_codec *codec,
>  {
> unsigned long end_time = jiffies + msecs_to_jiffies(500);
> unsigned int state, actual_state;
> +   int count;
>  
> -   for (;;) {
> +   for (count = 0; count < 500; count++) {
> state = snd_hda_codec_read(codec, fg, 0,
>AC_VERB_GET_POWER_STATE, 0);
> -   if (state & AC_PWRST_ERROR)
> +   if (state & AC_PWRST_ERROR) {
> +   msleep(20);
> break;
> +   }

This was just to demonstrate that applying the obvious functional
changes from the common routine to hda_codec.c didn't break it.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] drm/i915: Add HDCP support to i915

[Sean Paul]

Hi Dave,
Here's the pull request for HDCP. Hopefully no surprises since it's been baking
in drm-tip for a while now.

topic/hdcp-2018-02-13:
Add HDCP support to i915 drm driver.

Cheers, Sean


The following changes since commit b0caa1333b6d2d928a00304e9fb6674526c37b79:

  Merge tag 'imx-drm-next-2018-01-02' of git://git.pengutronix.de/git/pza/linux 
into drm-next (2018-01-05 11:33:24 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/topic/hdcp-2018-02-13

for you to fetch changes up to 2834d9dfaf0276e197158be6af8e1a1d59e58289:

  drm/i915: fix misalignment in HDCP register def (2018-02-05 12:59:29 -0500)


Add HDCP support to i915 drm driver.


Chris Wilson (1):
  drm/i915/dp: Fix compilation of intel_dp_hdcp_check_link

Ramalingam C (12):
  drm/i915: Extending HDCP for HSW, BDW and BXT+
  drm/i915: II stage HDCP auth for repeater only
  drm/i915: Start repeater auth on READY/CP_IRQ
  drm/i915: Check for downstream topology errors
  drm/i915: Handle failure from 2nd stage HDCP auth
  drm/i915: Stop encryption for repeater with no sink
  drm/i915: Connector info in HDCP debug msgs
  drm/i915: Retry HDCP bksv read
  drm/i915: Optimize HDCP key load
  drm/i915: Detect panel's hdcp capability
  drm/i915: Reauthenticate HDCP on failure
  drm/i915: fix misalignment in HDCP register def

Sean Paul (13):
  drm: Fix link-status kerneldoc line lengths
  drm/i915: Add more control to wait_for routines
  drm: Add Content Protection property
  drm: Add some HDCP related #defines
  drm/i915: Add HDCP framework + base implementation
  drm/i915: Make use of indexed write GMBUS feature
  drm/i915: Add function to output Aksv over GMBUS
  drm/i915: Implement HDCP for HDMI
  drm/i915: Implement HDCP for DisplayPort
  drm/i915: Don't allow HDCP on PORT E/F
  drm/i915: Only disable HDCP when it's active
  drm/i915: Restore HDCP DRM_INFO when with no downstream
  drm/i915: Downgrade hdcp logs from INFO to DEBUG_KMS

 drivers/gpu/drm/drm_atomic.c |   8 +
 drivers/gpu/drm/drm_connector.c  |  87 +++-
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/i915_drv.h  |   1 +
 drivers/gpu/drm/i915/i915_reg.h  |  86 
 drivers/gpu/drm/i915/intel_atomic.c  |   2 +
 drivers/gpu/drm/i915/intel_ddi.c |  36 ++
 drivers/gpu/drm/i915/intel_display.c |   4 +
 drivers/gpu/drm/i915/intel_dp.c  | 277 +++-
 drivers/gpu/drm/i915/intel_drv.h | 109 -
 drivers/gpu/drm/i915/intel_hdcp.c| 807 +++
 drivers/gpu/drm/i915/intel_hdmi.c| 250 +++
 drivers/gpu/drm/i915/intel_i2c.c |  81 +++-
 drivers/gpu/drm/i915/intel_uncore.c  |  23 +-
 drivers/gpu/drm/i915/intel_uncore.h  |  14 +-
 include/drm/drm_connector.h  |  16 +
 include/drm/drm_dp_helper.h  |  17 +
 include/drm/drm_hdcp.h   |  41 ++
 include/uapi/drm/drm_mode.h  |   4 +
 19 files changed, 1821 insertions(+), 43 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
 create mode 100644 include/drm/drm_hdcp.h

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Create a new category of display WAs

[Jani Nikula]

On Tue, 13 Feb 2018, Oscar Mateo  wrote:
> @@ -8979,6 +8701,7 @@ static void i830_init_clock_gating(struct 
> drm_i915_private *dev_priv)
>  void intel_init_clock_gating(struct drm_i915_private *dev_priv)
>  {
>   dev_priv->display.init_clock_gating(dev_priv);
> + intel_disp_workarounds_apply(dev_priv);

Please don't abbreviate display to disp, use the full word instead,
throughout the series. Rationale:

$ git grep disp_ -- drivers/gpu/drm/i915 | wc -l
8

$ git grep display_ -- drivers/gpu/drm/i915 | wc -l
752

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

> +static void bdw_disp_workarounds_apply(struct drm_i915_private *dev_priv)

If you want to shorten the names within intel_workarounds.c please
abbreviate workarounds to wa instead. I think it should be obvious
within that file. But I don't mind longer names here. It's the long
names that are used throughout the driver that I'd avoid.


BR,
Jani.

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

Re: [Intel-gfx] [PATCH v10 3/7] drm/i915/guc: Implement dynamic GuC WOPCM offset and size

[Yaodong Li]

On 02/13/2018 07:56 AM, Michal Wajdeczko wrote:

+
+/* GUC WOPCM offset needs to be 16KB aligned. */
+#define GUC_WOPCM_OFFSET_ALIGNMENT    (16 << 10)
+/* 16KB reserved at the beginning of GuC WOPCM. */
+#define GUC_WOPCM_RESERVED    (16 << 10)
+/* 8KB from GUC_WOPCM_RESERVED is reserved for GuC stack. */
+#define GUC_WOPCM_STACK_RESERVED    (8 << 10)
+/* 24KB at the end of GuC WOPCM is reserved for RC6 CTX on BXT. */
+#define BXT_GUC_WOPCM_RC6_CTX_RESERVED    (24 << 10)


Hmm, I'm still not convinced that we correctly attach it to "GuC WOPCM".

Can you explain the reason and more about your concerns?


In the result, maybe we should stop focusing on "intel_guc_wopcm" and 
define

everything as "intel_wopcm" as it was earlier suggested by Joonas.

Then we can define our struct to match diagram above as

struct intel_wopcm {
u32 size;
struct {
    u32 base;
    u32 size;
} guc;
};


Thanks Michal! but I don't think this is quite clean design. two reason:
0) I agree there should be something like intel_wopcm to describe
    the overall wopcm info, that what I did in my v1 patch series.
    the question is whether we really need it even if we are using
    only static wopcm size value? I think it should be more clear to
    introduce intel_wopcm as  a part of a patch that supports dynamic
    wopcm size calculation.
2) the wopcm region (a.k.a partition) is definitely a concept that should
    exist at least in uc layer. if we chose not to init uc/guc, it would be
    nonsense to init these partitions/info in an intel_wopcm which 
attached to
    drm_i915_private and we have initialized a part of this struct 
(e.g. size).

    to make it clean I will insist to have the guc wopcm region (or maybe
    the other region info) kept in uc level.
As I said the purpose of this series is to enable dynamic GuC WOPCM offset
and size calculation. it's not targeting any code refactoring and only 
serves

as a new feature enabling patch. The design principle of this series was to
provide clear new feature enabling by:
1) align with current code design and implementation.
2) provide correct hardware abstraction.
3) faultlessly enabled these new features. (e.g. dynamic size/offset 
calculation)

I think this series is now in a good shape to meet all above targets.

On the other hand, I do agree there always is some room to make our current
code clearer, but what we are talking about is further code refactoring.
Actually, I've already had some ideas of this. e.g. we could have some new
abstractions such as:

struct intel_wopcm {
    u32 size;
    /*any other global wopcm info*/
}

struct wopcm_region {
    u32 reserved; // reserved size in each region
    u32 offset; // offset of each region
    u32 size; // size of each region
};

struct intel_uc {
    struct wopcm_regions regions[];
    struct intel_uc_fw fws[];
    struct intel_guc guc;
    ...
}

struct intel_guc_dma {
    u32 fw_domains;
    lockable_reg size;
    lockable_reg offset;
    u32 flags; // e.g. loading HuC.
}

guc_dma_init()
guc_dma_hw_init()
guc_dma_xfer()

struct intel_guc {
    struct intel_guc_dma guc_dma;
    /*other guc objects*/
}

This would provide better software layer abstraction. but what I learned
from the 10 versions code submission is we need make things clear enough to
move forward. The lack of uc level abstraction is probably the reason why we
felt so frustrating about this part of code.

Can we just move forward by aligning to the current code implementation?
since what we need now is enable this new features. and we definitely can
provide more code refactoring patches based on these changes later.

Regards,
-Jackie
___
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] AWOOGA: Revert "ALSA: hda: Make use of core codec functions to sync power state"

[Patchwork]

== Series Details ==

Series: series starting with [1/2] AWOOGA: Revert "ALSA: hda: Make use of core 
codec functions to sync power state"
URL   : https://patchwork.freedesktop.org/series/38188/
State : failure

== Summary ==

Series 38188v1 series starting with [1/2] AWOOGA: Revert "ALSA: hda: Make use 
of core codec functions to sync power state"
https://patchwork.freedesktop.org/api/1.0/series/38188/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-cnl-y3) fdo#105058
Subgroup suspend-read-crc-pipe-c:
pass   -> INCOMPLETE (fi-bxt-dsi)
Test pm_rpm:
Subgroup basic-pci-d3-state:
fail   -> PASS   (fi-hsw-4770) fdo#105069 +3

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#105058 https://bugs.freedesktop.org/show_bug.cgi?id=105058
fdo#105069 https://bugs.freedesktop.org/show_bug.cgi?id=105069

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:420s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:375s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:485s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:288s
fi-bxt-dsi   total:246  pass:219  dwarn:0   dfail:0   fail:0   skip:26 
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:480s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:468s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:460s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:575s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:414s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:281s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:510s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:391s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:459s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:413s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:457s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:498s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:588s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:431s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:530s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:493s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:472s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:414s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:433s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:402s
Blacklisted hosts:
fi-glk-dsi   total:117  pass:105  dwarn:0   dfail:0   fail:0   skip:12 
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:453s

55dfdd18a566b5c632cbb34086b2a03410e810fb drm-tip: 2018y-02m-13d-18h-37m-11s UTC 
integration manifest
bd0e703cb15e redo
306b5cc96ff5 AWOOGA: Revert "ALSA: hda: Make use of core codec functions to 
sync power state"

== Logs ==

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

Re: [Intel-gfx] [PATCH 03/20] drm/i915/icl: Show interrupt registers in debugfs

[Daniele Ceraolo Spurio]

On 13/02/18 08:37, Mika Kuoppala wrote:

From: Tvrtko Ursulin 

v2: Update for POR changes. (Daniele Ceraolo Spurio)

Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Rodrigo Vivi 
Cc: Ceraolo Spurio, Daniele 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 82 -
  1 file changed, 81 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 960302668649..49d5bed87798 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -703,6 +703,64 @@ static int i915_interrupt_info(struct seq_file *m, void 
*data)
   i, I915_READ(GEN8_GT_IER(i)));
}
  
+		seq_printf(m, "PCU interrupt mask:\t%08x\n",

+  I915_READ(GEN8_PCU_IMR));
+   seq_printf(m, "PCU interrupt identity:\t%08x\n",
+  I915_READ(GEN8_PCU_IIR));
+   seq_printf(m, "PCU interrupt enable:\t%08x\n",
+  I915_READ(GEN8_PCU_IER));
+   } else if (INTEL_GEN(dev_priv) >= 11) {
+   seq_printf(m, "Master Interrupt Control:  %08x\n",
+  I915_READ(GEN11_GFX_MSTR_IRQ));
+
+   seq_printf(m, "Render/Copy Intr Enable:   %08x\n",
+  I915_READ(GEN11_RENDER_COPY_INTR_ENABLE));
+   seq_printf(m, "VCS/VECS Intr Enable:  %08x\n",
+  I915_READ(GEN11_VCS_VECS_INTR_ENABLE));
+   seq_printf(m, "GUC/SG Intr Enable:\t   %08x\n",
+  I915_READ(GEN11_GUC_SG_INTR_ENABLE));
+   seq_printf(m, "GPM/WGBOXPERF Intr Enable: %08x\n",
+  I915_READ(GEN11_GPM_WGBOXPERF_INTR_ENABLE));
+   seq_printf(m, "Crypto Intr Enable:\t   %08x\n",
+  I915_READ(GEN11_CRYPTO_RSVD_INTR_ENABLE));
+   seq_printf(m, "GUnit/CSME Intr Enable:\t   %08x\n",
+  I915_READ(GEN11_GUNIT_CSME_INTR_ENABLE));
+
+   seq_printf(m, "Display Interrupt Control:\t%08x\n",
+  I915_READ(GEN11_DISPLAY_INT_CTL));


From here onwards the code in this statement is almost identical to the 
one in the GEN8 case, apart from a small difference which I believe can 
be removed (see comment below), so it'd probably be cleaner to move it 
to a common function.



+
+   for_each_pipe(dev_priv, pipe) {
+   if (!intel_display_power_is_enabled(dev_priv,
+   POWER_DOMAIN_PIPE(pipe))) {


The Gen8 code uses intel_display_power_get_if_enabled(), any reason not 
to do the same here?


Daniele


+   seq_printf(m, "Pipe %c power disabled\n",
+  pipe_name(pipe));
+   continue;
+   }
+   seq_printf(m, "Pipe %c IMR:\t%08x\n",
+  pipe_name(pipe),
+  I915_READ(GEN8_DE_PIPE_IMR(pipe)));
+   seq_printf(m, "Pipe %c IIR:\t%08x\n",
+  pipe_name(pipe),
+  I915_READ(GEN8_DE_PIPE_IIR(pipe)));
+   seq_printf(m, "Pipe %c IER:\t%08x\n",
+  pipe_name(pipe),
+  I915_READ(GEN8_DE_PIPE_IER(pipe)));
+   }
+
+   seq_printf(m, "Display Engine port interrupt mask:\t%08x\n",
+  I915_READ(GEN8_DE_PORT_IMR));
+   seq_printf(m, "Display Engine port interrupt identity:\t%08x\n",
+  I915_READ(GEN8_DE_PORT_IIR));
+   seq_printf(m, "Display Engine port interrupt enable:\t%08x\n",
+  I915_READ(GEN8_DE_PORT_IER));
+
+   seq_printf(m, "Display Engine misc interrupt mask:\t%08x\n",
+  I915_READ(GEN8_DE_MISC_IMR));
+   seq_printf(m, "Display Engine misc interrupt identity:\t%08x\n",
+  I915_READ(GEN8_DE_MISC_IIR));
+   seq_printf(m, "Display Engine misc interrupt enable:\t%08x\n",
+  I915_READ(GEN8_DE_MISC_IER));
+
seq_printf(m, "PCU interrupt mask:\t%08x\n",
   I915_READ(GEN8_PCU_IMR));
seq_printf(m, "PCU interrupt identity:\t%08x\n",
@@ -846,13 +904,35 @@ static int i915_interrupt_info(struct seq_file *m, void 
*data)
seq_printf(m, "Graphics Interrupt mask:%08x\n",
   I915_READ(GTIMR));
}
-   if (INTEL_GEN(dev_priv) >= 6) {
+
+   if (INTEL_GEN(dev_priv) >= 11) {
+   seq_printf(m, "RCS Intr Mask:\t %08x\n",
+ 

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Move a bunch of workaround-related code to its own file

[Patchwork]

== Series Details ==

Series: series starting with [1/5] drm/i915: Move a bunch of workaround-related 
code to its own file
URL   : https://patchwork.freedesktop.org/series/38185/
State : failure

== Summary ==

Series 38185v1 series starting with [1/5] drm/i915: Move a bunch of 
workaround-related code to its own file
https://patchwork.freedesktop.org/api/1.0/series/38185/revisions/1/mbox/

Test kms_chamelium:
Subgroup common-hpd-after-suspend:
pass   -> DMESG-WARN (fi-skl-6700k2) fdo#104108
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a:
pass   -> INCOMPLETE (fi-elk-e7500)
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-cnl-y3) fdo#105058
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108
fdo#105058 https://bugs.freedesktop.org/show_bug.cgi?id=105058
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:288  pass:265  dwarn:0   dfail:0   fail:2   skip:21  
time:439s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:432s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:375s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:493s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:286s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:477s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:481s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:469s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:457s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:568s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:580s
fi-elk-e7500 total:232  pass:184  dwarn:0   dfail:0   fail:0   skip:47 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:284s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:517s
fi-hsw-4770  total:288  pass:259  dwarn:0   dfail:0   fail:2   skip:27  
time:420s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:458s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:416s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:457s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:496s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:500s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:589s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:430s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:505s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:526s
fi-skl-6700k2total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:494s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:482s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:416s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:427s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:396s
Blacklisted hosts:
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:470s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:452s

55dfdd18a566b5c632cbb34086b2a03410e810fb drm-tip: 2018y-02m-13d-18h-37m-11s UTC 
integration manifest
6ce8d2a167eb drm/i915: Classify GT & Display WAs correctly
be6ab53f9495 drm/i915: Create a new category of display WAs
8ac2a8421092 drm/i915: Move WA BB stuff to the workarounds file as well
5763441421d8 drm/i915: Split out functions for different kinds of workarounds
45ed903d0a7c drm/i915: Move a bunch of workaround-related code to its own file

== Logs ==

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

[Intel-gfx] [PATCH 1/2] AWOOGA: Revert "ALSA: hda: Make use of core codec functions to sync power state"

[Chris Wilson]

This reverts commit 3b5b899ca67db07a4c4825911072221f99e157e2.

Fixes: 3b5b899ca67d ("ALSA: hda: Make use of core codec functions to sync power 
state")
Cc: Abhijeet Kumar 
Cc: Takashi Iwai 
---
 sound/pci/hda/hda_codec.c | 28 +++-
 sound/pci/hda/hda_local.h |  6 +-
 2 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 5bc3a7468e17..e018ecbf78a8 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -2702,6 +2702,32 @@ void snd_hda_codec_set_power_to_all(struct hda_codec 
*codec, hda_nid_t fg,
 }
 EXPORT_SYMBOL_GPL(snd_hda_codec_set_power_to_all);
 
+/*
+ * wait until the state is reached, returns the current state
+ */
+static unsigned int hda_sync_power_state(struct hda_codec *codec,
+hda_nid_t fg,
+unsigned int power_state)
+{
+   unsigned long end_time = jiffies + msecs_to_jiffies(500);
+   unsigned int state, actual_state;
+
+   for (;;) {
+   state = snd_hda_codec_read(codec, fg, 0,
+  AC_VERB_GET_POWER_STATE, 0);
+   if (state & AC_PWRST_ERROR)
+   break;
+   actual_state = (state >> 4) & 0x0f;
+   if (actual_state == power_state)
+   break;
+   if (time_after_eq(jiffies, end_time))
+   break;
+   /* wait until the codec reachs to the target state */
+   msleep(1);
+   }
+   return state;
+}
+
 /**
  * snd_hda_codec_eapd_power_filter - A power filter callback for EAPD
  * @codec: the HDA codec
@@ -2764,7 +2790,7 @@ static unsigned int hda_set_power_state(struct hda_codec 
*codec,
   state);
snd_hda_codec_set_power_to_all(codec, fg, power_state);
}
-   state = snd_hda_sync_power_state(codec, fg, power_state);
+   state = hda_sync_power_state(codec, fg, power_state);
if (!(state & AC_PWRST_ERROR))
break;
}
diff --git a/sound/pci/hda/hda_local.h b/sound/pci/hda/hda_local.h
index 321e78baa63c..5b5c324c99b9 100644
--- a/sound/pci/hda/hda_local.h
+++ b/sound/pci/hda/hda_local.h
@@ -622,11 +622,7 @@ snd_hda_check_power_state(struct hda_codec *codec, 
hda_nid_t nid,
 {
return snd_hdac_check_power_state(>core, nid, target_state);
 }
-static inline bool snd_hda_sync_power_state(struct hda_codec *codec,
-  hda_nid_t nid, unsigned int target_state)
-{
-   return snd_hdac_sync_power_state(>core, nid, target_state);
-}
+
 unsigned int snd_hda_codec_eapd_power_filter(struct hda_codec *codec,
 hda_nid_t nid,
 unsigned int power_state);
-- 
2.16.1

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

[Intel-gfx] [PATCH 2/2] redo

[Chris Wilson]

---
 sound/pci/hda/hda_codec.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index e018ecbf78a8..afa5f5155220 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -2711,12 +2711,15 @@ static unsigned int hda_sync_power_state(struct 
hda_codec *codec,
 {
unsigned long end_time = jiffies + msecs_to_jiffies(500);
unsigned int state, actual_state;
+   int count;
 
-   for (;;) {
+   for (count = 0; count < 500; count++) {
state = snd_hda_codec_read(codec, fg, 0,
   AC_VERB_GET_POWER_STATE, 0);
-   if (state & AC_PWRST_ERROR)
+   if (state & AC_PWRST_ERROR) {
+   msleep(20);
break;
+   }
actual_state = (state >> 4) & 0x0f;
if (actual_state == power_state)
break;
-- 
2.16.1

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

Re: [Intel-gfx] [PATCH 05/20] drm/i915/icl: Interrupt handling

[Daniele Ceraolo Spurio]

On 13/02/18 08:37, Mika Kuoppala wrote:

From: Tvrtko Ursulin 

v2: Rebase.

v3:
   * Remove DPF, it has been removed from SKL+.
   * Fix -internal rebase wrt. execlists interrupt handling.

v4: Rebase.

v5:
   * Updated for POR changes. (Daniele Ceraolo Spurio)
   * Merged with irq handling fixes by Daniele Ceraolo Spurio:
   * Simplify the code by using gen8_cs_irq_handler.
   * Fix interrupt handling for the upstream kernel.

v6:
   * Remove early bringup debug messages (Tvrtko)
   * Add NB about arbitrary spin wait timeout (Tvrtko)

v7 (from Paulo):
   * Don't try to write RO bits to registers.
   * Don't check for PCH types that don't exist. PCH interrupts are not
 here yet.

Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Oscar Mateo 
Signed-off-by: Paulo Zanoni 
---
  drivers/gpu/drm/i915/i915_irq.c | 210 
  drivers/gpu/drm/i915/intel_pm.c |   7 +-
  2 files changed, 216 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b886bd459acc..3a1de4e2a941 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -415,6 +415,9 @@ void gen6_enable_rps_interrupts(struct drm_i915_private 
*dev_priv)
if (READ_ONCE(rps->interrupts_enabled))
return;
  
+	if (WARN_ON_ONCE(IS_GEN11(dev_priv)))

+   return;
+
spin_lock_irq(_priv->irq_lock);
WARN_ON_ONCE(rps->pm_iir);
WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) & 
dev_priv->pm_rps_events);
@@ -431,6 +434,9 @@ void gen6_disable_rps_interrupts(struct drm_i915_private 
*dev_priv)
if (!READ_ONCE(rps->interrupts_enabled))
return;
  
+	if (WARN_ON_ONCE(IS_GEN11(dev_priv)))

+   return;
+
spin_lock_irq(_priv->irq_lock);
rps->interrupts_enabled = false;
  
@@ -2746,6 +2752,131 @@ static void __fini_wedge(struct wedge_me *w)

 (W)->i915;  \
 __fini_wedge((W)))
  
+static __always_inline void

+gen11_cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
+{
+   gen8_cs_irq_handler(engine, iir, 0);
+}
+
+static irqreturn_t
+gen11_gt_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)
+{
+   irqreturn_t ret = IRQ_NONE;
+   u16 irq[2][32];
+   u32 dw, ident;
+   unsigned long tmp;
+   unsigned int bank, bit, engine;
+   unsigned long wait_start, wait_end;
+
+   memset(irq, 0, sizeof(irq));
+
+   for (bank = 0; bank < 2; bank++) {
+   if (master_ctl & GEN11_GT_DW_IRQ(bank)) {
+   dw = I915_READ_FW(GEN11_GT_INTR_DW(bank));
+   if (!dw)
+   DRM_ERROR("GT_INTR_DW%u blank!\n", bank);
+   tmp = dw;
+   for_each_set_bit(bit, , 32) {
+   I915_WRITE_FW(GEN11_IIR_REG_SELECTOR(bank), 1 
<< bit);
+   wait_start = local_clock() >> 10;
+   /* NB: Specs do not specify how long to spin 
wait.
+* Taking 100us as an educated guess */
+   wait_end = wait_start + 100;
+   do {
+   ident = 
I915_READ_FW(GEN11_INTR_IDENTITY_REG(bank));
+   } while (!(ident & GEN11_INTR_DATA_VALID) &&
+!time_after((unsigned long)local_clock() 
>> 10, wait_end));


Patch 18/20 changes this to time_after64 and wait_end to u64, which 
looks like the correct way to handle this. Since splitting part of this 
loop out also helps making things cleaner, would it make sense to squash 
patch 18/20 into this one?



+
+   if (!(ident & GEN11_INTR_DATA_VALID))
+   DRM_ERROR("INTR_IDENTITY_REG%u:%u timed 
out!\n",
+ bank, bit);


If the data is not valid we should probably skip writing it to the 
irq[bank][bit] field as we might be writing an incorrect value.



+
+   irq[bank][bit] = ident & GEN11_INTR_ENGINE_MASK;
+   if (!irq[bank][bit])
+   DRM_ERROR("INTR_IDENTITY_REG%u:%u 
blank!\n",
+ bank, bit);


As mentioned on the previous review, I believe it is actually possible 
to get a blank identity register due to double buffering of interrupts 
if a second interrupt arrives between reading GT_INTR_DW and reading 
GEN11_INTR_IDENTITY, as both interrupts will be serviced on the first 
iteration but 

[Intel-gfx] [PATCH 3/5] drm/i915: Move WA BB stuff to the workarounds file as well

[Oscar Mateo]

Since we are trying to put all WA stuff together, do not forget about the BB 
WAs.

v2: s/intel_bb_workarounds_init/intel_engine_init_bb_workarounds (Chris)
v3: Rebased to before the WAs are stored
v4: Rebased

Reviewed-by: Chris Wilson  (v2)
Signed-off-by: Oscar Mateo 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_lrc.c | 290 +-
 drivers/gpu/drm/i915/intel_workarounds.c | 291 +++
 drivers/gpu/drm/i915/intel_workarounds.h |   3 +
 3 files changed, 296 insertions(+), 288 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 39d43bb..fea1b48 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1181,292 +1181,6 @@ static int execlists_request_alloc(struct 
drm_i915_gem_request *request)
return 0;
 }
 
-/*
- * In this WA we need to set GEN8_L3SQCREG4[21:21] and reset it after
- * PIPE_CONTROL instruction. This is required for the flush to happen correctly
- * but there is a slight complication as this is applied in WA batch where the
- * values are only initialized once so we cannot take register value at the
- * beginning and reuse it further; hence we save its value to memory, upload a
- * constant value with bit21 set and then we restore it back with the saved 
value.
- * To simplify the WA, a constant value is formed by using the default value
- * of this register. This shouldn't be a problem because we are only modifying
- * it for a short period and this batch in non-premptible. We can ofcourse
- * use additional instructions that read the actual value of the register
- * at that time and set our bit of interest but it makes the WA complicated.
- *
- * This WA is also required for Gen9 so extracting as a function avoids
- * code duplication.
- */
-static u32 *
-gen8_emit_flush_coherentl3_wa(struct intel_engine_cs *engine, u32 *batch)
-{
-   *batch++ = MI_STORE_REGISTER_MEM_GEN8 | MI_SRM_LRM_GLOBAL_GTT;
-   *batch++ = i915_mmio_reg_offset(GEN8_L3SQCREG4);
-   *batch++ = i915_ggtt_offset(engine->scratch) + 256;
-   *batch++ = 0;
-
-   *batch++ = MI_LOAD_REGISTER_IMM(1);
-   *batch++ = i915_mmio_reg_offset(GEN8_L3SQCREG4);
-   *batch++ = 0x4040 | GEN8_LQSC_FLUSH_COHERENT_LINES;
-
-   batch = gen8_emit_pipe_control(batch,
-  PIPE_CONTROL_CS_STALL |
-  PIPE_CONTROL_DC_FLUSH_ENABLE,
-  0);
-
-   *batch++ = MI_LOAD_REGISTER_MEM_GEN8 | MI_SRM_LRM_GLOBAL_GTT;
-   *batch++ = i915_mmio_reg_offset(GEN8_L3SQCREG4);
-   *batch++ = i915_ggtt_offset(engine->scratch) + 256;
-   *batch++ = 0;
-
-   return batch;
-}
-
-/*
- * Typically we only have one indirect_ctx and per_ctx batch buffer which are
- * initialized at the beginning and shared across all contexts but this field
- * helps us to have multiple batches at different offsets and select them based
- * on a criteria. At the moment this batch always start at the beginning of 
the page
- * and at this point we don't have multiple wa_ctx batch buffers.
- *
- * The number of WA applied are not known at the beginning; we use this field
- * to return the no of DWORDS written.
- *
- * It is to be noted that this batch does not contain MI_BATCH_BUFFER_END
- * so it adds NOOPs as padding to make it cacheline aligned.
- * MI_BATCH_BUFFER_END will be added to perctx batch and both of them together
- * makes a complete batch buffer.
- */
-static u32 *gen8_init_indirectctx_bb(struct intel_engine_cs *engine, u32 
*batch)
-{
-   /* WaDisableCtxRestoreArbitration:bdw,chv */
-   *batch++ = MI_ARB_ON_OFF | MI_ARB_DISABLE;
-
-   /* WaFlushCoherentL3CacheLinesAtContextSwitch:bdw */
-   if (IS_BROADWELL(engine->i915))
-   batch = gen8_emit_flush_coherentl3_wa(engine, batch);
-
-   /* WaClearSlmSpaceAtContextSwitch:bdw,chv */
-   /* Actual scratch location is at 128 bytes offset */
-   batch = gen8_emit_pipe_control(batch,
-  PIPE_CONTROL_FLUSH_L3 |
-  PIPE_CONTROL_GLOBAL_GTT_IVB |
-  PIPE_CONTROL_CS_STALL |
-  PIPE_CONTROL_QW_WRITE,
-  i915_ggtt_offset(engine->scratch) +
-  2 * CACHELINE_BYTES);
-
-   *batch++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
-
-   /* Pad to end of cacheline */
-   while ((unsigned long)batch % CACHELINE_BYTES)
-   *batch++ = MI_NOOP;
-
-   /*
-* MI_BATCH_BUFFER_END is not required in Indirect ctx BB because
-* execution depends on the length specified in terms of cache lines
-* in the register CTX_RCS_INDIRECT_CTX
-*/
-
-   return batch;
-}
-
-static u32 

[Intel-gfx] [PATCH 2/5] drm/i915: Split out functions for different kinds of workarounds

[Oscar Mateo]

There are different kind of workarounds (those that modify registers that
live in the context image, those that modify global registers, those that
whitelist registers, etc...) and they have different requirements in terms
of where they are applied and how. Also, by splitting them apart, it should
be easier to decide where a new workaround should go.

v2:
  - Add multiple MISSING_CASE
  - Rebased

v3:
  - Rename mmio_workarounds to gt_workarounds (Chris, Mika)
  - Create empty placeholders for BDW and CHV GT WAs
  - Rebased

v4: Rebased

Signed-off-by: Oscar Mateo 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_gem.c  |   3 +
 drivers/gpu/drm/i915/i915_gem_context.c  |   6 +
 drivers/gpu/drm/i915/intel_lrc.c |  10 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c  |   4 +-
 drivers/gpu/drm/i915/intel_workarounds.c | 627 +++
 drivers/gpu/drm/i915/intel_workarounds.h |   8 +-
 6 files changed, 414 insertions(+), 244 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fc68b35..94707c2 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -35,6 +35,7 @@
 #include "intel_drv.h"
 #include "intel_frontbuffer.h"
 #include "intel_mocs.h"
+#include "intel_workarounds.h"
 #include "i915_gemfs.h"
 #include 
 #include 
@@ -5107,6 +5108,8 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
}
}
 
+   intel_gt_workarounds_apply(dev_priv);
+
i915_gem_init_swizzling(dev_priv);
 
/*
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 3d75f48..a5ada99 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -90,6 +90,7 @@
 #include 
 #include "i915_drv.h"
 #include "i915_trace.h"
+#include "intel_workarounds.h"
 
 #define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
 
@@ -452,11 +453,16 @@ static bool needs_preempt_context(struct drm_i915_private 
*i915)
 int i915_gem_contexts_init(struct drm_i915_private *dev_priv)
 {
struct i915_gem_context *ctx;
+   int ret;
 
/* Reassure ourselves we are only called once */
GEM_BUG_ON(dev_priv->kernel_context);
GEM_BUG_ON(dev_priv->preempt_context);
 
+   ret = intel_ctx_workarounds_init(dev_priv);
+   if (ret)
+   return ret;
+
INIT_LIST_HEAD(_priv->contexts.list);
INIT_WORK(_priv->contexts.free_work, contexts_free_worker);
init_llist_head(_priv->contexts.free_list);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 62de613..39d43bb 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1544,7 +1544,7 @@ static int gen8_init_render_ring(struct intel_engine_cs 
*engine)
 
I915_WRITE(INSTPM, _MASKED_BIT_ENABLE(INSTPM_FORCE_ORDERING));
 
-   return init_workarounds_ring(engine);
+   return 0;
 }
 
 static int gen9_init_render_ring(struct intel_engine_cs *engine)
@@ -1555,7 +1555,11 @@ static int gen9_init_render_ring(struct intel_engine_cs 
*engine)
if (ret)
return ret;
 
-   return init_workarounds_ring(engine);
+   ret = intel_whitelist_workarounds_apply(engine);
+   if (ret)
+   return ret;
+
+   return 0;
 }
 
 static void reset_irq(struct intel_engine_cs *engine)
@@ -1904,7 +1908,7 @@ static int gen8_init_rcs_context(struct 
drm_i915_gem_request *req)
 {
int ret;
 
-   ret = intel_ring_workarounds_emit(req);
+   ret = intel_ctx_workarounds_emit(req);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index ec580f5..0b6c20f 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -600,7 +600,7 @@ static int intel_rcs_ctx_init(struct drm_i915_gem_request 
*req)
 {
int ret;
 
-   ret = intel_ring_workarounds_emit(req);
+   ret = intel_ctx_workarounds_emit(req);
if (ret != 0)
return ret;
 
@@ -659,7 +659,7 @@ static int init_render_ring(struct intel_engine_cs *engine)
if (INTEL_GEN(dev_priv) >= 6)
I915_WRITE_IMR(engine, ~engine->irq_keep_mask);
 
-   return init_workarounds_ring(engine);
+   return 0;
 }
 
 static u32 *gen6_signal(struct drm_i915_gem_request *req, u32 *cs)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c 
b/drivers/gpu/drm/i915/intel_workarounds.c
index 56a1152..9e8c6d4 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -40,27 +40,8 @@ static int wa_add(struct drm_i915_private *dev_priv,
 #define WA_SET_FIELD_MASKED(addr, mask, value) \
WA_REG(addr, mask, 

[Intel-gfx] [PATCH 5/5] drm/i915: Classify GT & Display WAs correctly

[Oscar Mateo]

Move GT WAs appropiately from the current xxx_disp_workarounds_apply
function to the corresponding xxx_gt_workarounds_apply one.

FIXME: It looks like Chris has found some WAs that actually live in
the context image. We need to move these to their rightful
xxx_workarounds_init function.

v2: Rebased

Signed-off-by: Oscar Mateo 
Cc: Mika Kuoppala 
Cc: Rodrigo Vivi 
Cc: Chris Wilson 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_workarounds.c | 203 +++
 1 file changed, 101 insertions(+), 102 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_workarounds.c 
b/drivers/gpu/drm/i915/intel_workarounds.c
index 8a27c13..ac1f8bc 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -468,12 +468,95 @@ int intel_ctx_workarounds_emit(struct 
drm_i915_gem_request *req)
return 0;
 }
 
+static void gen8_set_l3sqc_credits(struct drm_i915_private *dev_priv,
+  int general_prio_credits,
+  int high_prio_credits)
+{
+   u32 misccpctl;
+   u32 val;
+
+   /* WaTempDisableDOPClkGating:bdw */
+   misccpctl = I915_READ(GEN7_MISCCPCTL);
+   I915_WRITE(GEN7_MISCCPCTL, misccpctl & ~GEN7_DOP_CLOCK_GATE_ENABLE);
+
+   val = I915_READ(GEN8_L3SQCREG1);
+   val &= ~L3_PRIO_CREDITS_MASK;
+   val |= L3_GENERAL_PRIO_CREDITS(general_prio_credits);
+   val |= L3_HIGH_PRIO_CREDITS(high_prio_credits);
+   I915_WRITE(GEN8_L3SQCREG1, val);
+
+   /*
+* Wait at least 100 clocks before re-enabling clock gating.
+* See the definition of L3SQCREG1 in BSpec.
+*/
+   POSTING_READ(GEN8_L3SQCREG1);
+   udelay(1);
+   I915_WRITE(GEN7_MISCCPCTL, misccpctl);
+}
+
 static void bdw_gt_workarounds_apply(struct drm_i915_private *dev_priv)
 {
+   /* The GTT cache must be disabled if the system is using 2M pages. */
+   bool can_use_gtt_cache = !HAS_PAGE_SIZES(dev_priv,
+I915_GTT_PAGE_SIZE_2M);
+   /* WaSwitchSolVfFArbitrationPriority:bdw */
+   I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL);
+
+   /* WaVSRefCountFullforceMissDisable:bdw */
+   /* WaDSRefCountFullforceMissDisable:bdw */
+   I915_WRITE(GEN7_FF_THREAD_MODE,
+  I915_READ(GEN7_FF_THREAD_MODE) &
+  ~(GEN8_FF_DS_REF_CNT_FFME | GEN7_FF_VS_REF_CNT_FFME));
+
+
+   I915_WRITE(GEN6_RC_SLEEP_PSMI_CONTROL,
+  _MASKED_BIT_ENABLE(GEN8_RC_SEMA_IDLE_MSG_DISABLE));
+
+
+   /* WaDisableSDEUnitClockGating:bdw */
+   I915_WRITE(GEN8_UCGCTL6, I915_READ(GEN8_UCGCTL6) |
+  GEN8_SDEUNIT_CLOCK_GATE_DISABLE);
+
+
+   /* WaProgramL3SqcReg1Default:bdw */
+   gen8_set_l3sqc_credits(dev_priv, 30, 2);
+
+   /* WaGttCachingOffByDefault:bdw */
+   I915_WRITE(HSW_GTT_CACHE_EN, can_use_gtt_cache ? GTT_CACHE_EN_ALL : 0);
 }
 
 static void chv_gt_workarounds_apply(struct drm_i915_private *dev_priv)
 {
+   /* WaVSRefCountFullforceMissDisable:chv */
+   /* WaDSRefCountFullforceMissDisable:chv */
+   I915_WRITE(GEN7_FF_THREAD_MODE,
+  I915_READ(GEN7_FF_THREAD_MODE) &
+  ~(GEN8_FF_DS_REF_CNT_FFME | GEN7_FF_VS_REF_CNT_FFME));
+
+   /* WaDisableSemaphoreAndSyncFlipWait:chv */
+   I915_WRITE(GEN6_RC_SLEEP_PSMI_CONTROL,
+  _MASKED_BIT_ENABLE(GEN8_RC_SEMA_IDLE_MSG_DISABLE));
+
+   /* WaDisableCSUnitClockGating:chv */
+   I915_WRITE(GEN6_UCGCTL1, I915_READ(GEN6_UCGCTL1) |
+  GEN6_CSUNIT_CLOCK_GATE_DISABLE);
+
+   /* WaDisableSDEUnitClockGating:chv */
+   I915_WRITE(GEN8_UCGCTL6, I915_READ(GEN8_UCGCTL6) |
+  GEN8_SDEUNIT_CLOCK_GATE_DISABLE);
+
+   /*
+* WaProgramL3SqcReg1Default:chv
+* See gfxspecs/Related Documents/Performance Guide/
+* LSQC Setting Recommendations.
+*/
+   gen8_set_l3sqc_credits(dev_priv, 38, 2);
+
+   /*
+* GTT cache may not work with big pages, so if those
+* are ever enabled GTT cache may need to be disabled.
+*/
+   I915_WRITE(HSW_GTT_CACHE_EN, GTT_CACHE_EN_ALL);
 }
 
 static void gen9_gt_workarounds_apply(struct drm_i915_private *dev_priv)
@@ -556,6 +639,10 @@ static void bxt_gt_workarounds_apply(struct 
drm_i915_private *dev_priv)
I915_WRITE(GEN9_GAMT_ECO_REG_RW_IA,
   (I915_READ(GEN9_GAMT_ECO_REG_RW_IA) |
GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS));
+
+   /* WaDisableSDEUnitClockGating:bxt */
+   I915_WRITE(GEN8_UCGCTL6, (I915_READ(GEN8_UCGCTL6) |
+ GEN8_SDEUNIT_CLOCK_GATE_DISABLE));
 }
 
 static void kbl_gt_workarounds_apply(struct drm_i915_private *dev_priv)
@@ -580,6 +667,16 @@ static void 

[Intel-gfx] [PATCH 1/5] drm/i915: Move a bunch of workaround-related code to its own file

[Oscar Mateo]

This has grown to be a sizable amount of code, so move it to
its own file before we try to refactor anything. For the moment,
we are leaving behind the WA BB code and the WAs that get applied
(incorrectly) in init_clock_gating, but we will deal with it later.

v2: Use intel_ prefix for code that deals with the hardware (Chris)
v3: Rebased
v4:
  - Rebased
  - New license header

Signed-off-by: Oscar Mateo 
Cc: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/Makefile|   3 +-
 drivers/gpu/drm/i915/intel_engine_cs.c   | 634 --
 drivers/gpu/drm/i915/intel_lrc.c |   1 +
 drivers/gpu/drm/i915/intel_ringbuffer.c  |   1 +
 drivers/gpu/drm/i915/intel_ringbuffer.h  |   3 -
 drivers/gpu/drm/i915/intel_workarounds.c | 642 +++
 drivers/gpu/drm/i915/intel_workarounds.h |  13 +
 7 files changed, 659 insertions(+), 638 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_workarounds.c
 create mode 100644 drivers/gpu/drm/i915/intel_workarounds.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index f55cc02..424f09d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -43,7 +43,8 @@ i915-y := i915_drv.o \
  intel_csr.o \
  intel_device_info.o \
  intel_pm.o \
- intel_runtime_pm.o
+ intel_runtime_pm.o \
+ intel_workarounds.o
 
 i915-$(CONFIG_COMPAT)   += i915_ioc32.o
 i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o intel_pipe_crc.o
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index f3c5100..73fb488 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -825,640 +825,6 @@ void intel_engine_get_instdone(struct intel_engine_cs 
*engine,
}
 }
 
-static int wa_add(struct drm_i915_private *dev_priv,
- i915_reg_t addr,
- const u32 mask, const u32 val)
-{
-   const u32 idx = dev_priv->workarounds.count;
-
-   if (WARN_ON(idx >= I915_MAX_WA_REGS))
-   return -ENOSPC;
-
-   dev_priv->workarounds.reg[idx].addr = addr;
-   dev_priv->workarounds.reg[idx].value = val;
-   dev_priv->workarounds.reg[idx].mask = mask;
-
-   dev_priv->workarounds.count++;
-
-   return 0;
-}
-
-#define WA_REG(addr, mask, val) do { \
-   const int r = wa_add(dev_priv, (addr), (mask), (val)); \
-   if (r) \
-   return r; \
-   } while (0)
-
-#define WA_SET_BIT_MASKED(addr, mask) \
-   WA_REG(addr, (mask), _MASKED_BIT_ENABLE(mask))
-
-#define WA_CLR_BIT_MASKED(addr, mask) \
-   WA_REG(addr, (mask), _MASKED_BIT_DISABLE(mask))
-
-#define WA_SET_FIELD_MASKED(addr, mask, value) \
-   WA_REG(addr, mask, _MASKED_FIELD(mask, value))
-
-static int wa_ring_whitelist_reg(struct intel_engine_cs *engine,
-i915_reg_t reg)
-{
-   struct drm_i915_private *dev_priv = engine->i915;
-   struct i915_workarounds *wa = _priv->workarounds;
-   const uint32_t index = wa->hw_whitelist_count[engine->id];
-
-   if (WARN_ON(index >= RING_MAX_NONPRIV_SLOTS))
-   return -EINVAL;
-
-   I915_WRITE(RING_FORCE_TO_NONPRIV(engine->mmio_base, index),
-  i915_mmio_reg_offset(reg));
-   wa->hw_whitelist_count[engine->id]++;
-
-   return 0;
-}
-
-static int gen8_init_workarounds(struct intel_engine_cs *engine)
-{
-   struct drm_i915_private *dev_priv = engine->i915;
-
-   WA_SET_BIT_MASKED(INSTPM, INSTPM_FORCE_ORDERING);
-
-   /* WaDisableAsyncFlipPerfMode:bdw,chv */
-   WA_SET_BIT_MASKED(MI_MODE, ASYNC_FLIP_PERF_DISABLE);
-
-   /* WaDisablePartialInstShootdown:bdw,chv */
-   WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN,
- PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE);
-
-   /* Use Force Non-Coherent whenever executing a 3D context. This is a
-* workaround for for a possible hang in the unlikely event a TLB
-* invalidation occurs during a PSD flush.
-*/
-   /* WaForceEnableNonCoherent:bdw,chv */
-   /* WaHdcDisableFetchWhenMasked:bdw,chv */
-   WA_SET_BIT_MASKED(HDC_CHICKEN0,
- HDC_DONOT_FETCH_MEM_WHEN_MASKED |
- HDC_FORCE_NON_COHERENT);
-
-   /* From the Haswell PRM, Command Reference: Registers, CACHE_MODE_0:
-* "The Hierarchical Z RAW Stall Optimization allows non-overlapping
-*  polygons in the same 8x4 pixel/sample area to be processed without
-*  stalling waiting for the earlier ones to write to Hierarchical Z
-*  buffer."
-*
-* This optimization is off by default for BDW and CHV; turn it on.
-*/
-   WA_CLR_BIT_MASKED(CACHE_MODE_0_GEN7, HIZ_RAW_STALL_OPT_DISABLE);
-
-   /* Wa4x4STCOptimizationDisable:bdw,chv */
-   

[Intel-gfx] [PATCH 4/5] drm/i915: Create a new category of display WAs

[Oscar Mateo]

Display workarounds do not need to be re-applied on a GPU reset
(this is, in Ville's words: "at the very least wasted effort [...]
and could even be actively harmful in case we end up clobbering
something the current display configuration depends on"). Therefore,
they have to be applied in a different place that GT ones so they
deserve their own category.

Initially, populate this with the WAs that were being applied in
init_clock_gating. Actually discriminating which of these WAS is
a real display WA, a GT WA or a context WA is left for the next
patch (as it requires a good deal of careful review).

v2: Rebased to carry the init_early nomenclature over (Chris)
v3:
  - Rebased to before the WAs are stored
  - Initially populate with all WAs in init_clock_gating
v4: Rebased

Suggested-by: Ville Syrjälä 
Reviewed-by: Chris Wilson  (v2)
Signed-off-by: Oscar Mateo 
Cc: Mika Kuoppala 
Cc: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_pm.c  | 304 +-
 drivers/gpu/drm/i915/intel_workarounds.c | 309 +++
 drivers/gpu/drm/i915/intel_workarounds.h |   2 +
 3 files changed, 319 insertions(+), 296 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b026b02..6917a9d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -29,6 +29,7 @@
 #include 
 #include "i915_drv.h"
 #include "intel_drv.h"
+#include "intel_workarounds.h"
 #include "../../../platform/x86/intel_ips.h"
 #include 
 #include 
@@ -53,92 +54,6 @@
  * require higher latency to switch to and wake up.
  */
 
-static void gen9_init_clock_gating(struct drm_i915_private *dev_priv)
-{
-   if (HAS_LLC(dev_priv)) {
-   /*
-* WaCompressedResourceDisplayNewHashMode:skl,kbl
-* Display WA #0390: skl,kbl
-*
-* Must match Sampler, Pixel Back End, and Media. See
-* WaCompressedResourceSamplerPbeMediaNewHashMode.
-*/
-   I915_WRITE(CHICKEN_PAR1_1,
-  I915_READ(CHICKEN_PAR1_1) |
-  SKL_DE_COMPRESSED_HASH_MODE);
-   }
-
-   /* See Bspec note for PSR2_CTL bit 31, Wa#828:skl,bxt,kbl,cfl */
-   I915_WRITE(CHICKEN_PAR1_1,
-  I915_READ(CHICKEN_PAR1_1) | SKL_EDP_PSR_FIX_RDWRAP);
-
-   /* WaEnableChickenDCPR:skl,bxt,kbl,glk,cfl */
-   I915_WRITE(GEN8_CHICKEN_DCPR_1,
-  I915_READ(GEN8_CHICKEN_DCPR_1) | MASK_WAKEMEM);
-
-   /* WaFbcTurnOffFbcWatermark:skl,bxt,kbl,cfl */
-   /* WaFbcWakeMemOn:skl,bxt,kbl,glk,cfl */
-   I915_WRITE(DISP_ARB_CTL, I915_READ(DISP_ARB_CTL) |
-  DISP_FBC_WM_DIS |
-  DISP_FBC_MEMORY_WAKE);
-
-   /* WaFbcHighMemBwCorruptionAvoidance:skl,bxt,kbl,cfl */
-   I915_WRITE(ILK_DPFC_CHICKEN, I915_READ(ILK_DPFC_CHICKEN) |
-  ILK_DPFC_DISABLE_DUMMY0);
-
-   if (IS_SKYLAKE(dev_priv)) {
-   /* WaDisableDopClockGating */
-   I915_WRITE(GEN7_MISCCPCTL, I915_READ(GEN7_MISCCPCTL)
-  & ~GEN7_DOP_CLOCK_GATE_ENABLE);
-   }
-}
-
-static void bxt_init_clock_gating(struct drm_i915_private *dev_priv)
-{
-   gen9_init_clock_gating(dev_priv);
-
-   /* WaDisableSDEUnitClockGating:bxt */
-   I915_WRITE(GEN8_UCGCTL6, I915_READ(GEN8_UCGCTL6) |
-  GEN8_SDEUNIT_CLOCK_GATE_DISABLE);
-
-   /*
-* FIXME:
-* GEN8_HDCUNIT_CLOCK_GATE_DISABLE_HDCREQ applies on 3x6 GT SKUs only.
-*/
-   I915_WRITE(GEN8_UCGCTL6, I915_READ(GEN8_UCGCTL6) |
-  GEN8_HDCUNIT_CLOCK_GATE_DISABLE_HDCREQ);
-
-   /*
-* Wa: Backlight PWM may stop in the asserted state, causing backlight
-* to stay fully on.
-*/
-   I915_WRITE(GEN9_CLKGATE_DIS_0, I915_READ(GEN9_CLKGATE_DIS_0) |
-  PWM1_GATING_DIS | PWM2_GATING_DIS);
-}
-
-static void glk_init_clock_gating(struct drm_i915_private *dev_priv)
-{
-   gen9_init_clock_gating(dev_priv);
-
-   /*
-* WaDisablePWMClockGating:glk
-* Backlight PWM may stop in the asserted state, causing backlight
-* to stay fully on.
-*/
-   I915_WRITE(GEN9_CLKGATE_DIS_0, I915_READ(GEN9_CLKGATE_DIS_0) |
-  PWM1_GATING_DIS | PWM2_GATING_DIS);
-
-   /* WaDDIIOTimeout:glk */
-   if (IS_GLK_REVID(dev_priv, 0, GLK_REVID_A1)) {
-   u32 val = I915_READ(CHICKEN_MISC_2);
-   val &= ~(GLK_CL0_PWR_DOWN |
-GLK_CL1_PWR_DOWN |
-GLK_CL2_PWR_DOWN);
-   I915_WRITE(CHICKEN_MISC_2, val);
-   }
-
-}
-
 static void i915_pineview_get_mem_freq(struct drm_i915_private *dev_priv)
 {
u32 tmp;
@@ -8457,168 +8372,9 @@ static void 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix i915_gem_context.h header

[Patchwork]

== Series Details ==

Series: drm/i915: Fix i915_gem_context.h header
URL   : https://patchwork.freedesktop.org/series/38164/
State : failure

== Summary ==

Test kms_rotation_crc:
Subgroup primary-rotation-180:
pass   -> FAIL   (shard-hsw)
Test kms_flip:
Subgroup modeset-vs-vblank-race-interruptible:
fail   -> PASS   (shard-apl) fdo#103060
Subgroup flip-vs-panning-vs-hang-interruptible:
dmesg-warn -> PASS   (shard-snb) fdo#103821
Test kms_plane_lowres:
Subgroup pipe-a-tiling-x:
fail   -> PASS   (shard-apl)
Test kms_frontbuffer_tracking:
Subgroup fbc-stridechange:
skip   -> PASS   (shard-snb) fdo#101623
Test kms_cursor_crc:
Subgroup cursor-256x256-offscreen:
skip   -> PASS   (shard-snb)
Test kms_draw_crc:
Subgroup draw-method-rgb565-pwrite-xtiled:
skip   -> PASS   (shard-snb)
Test perf:
Subgroup oa-exponents:
fail   -> PASS   (shard-apl) fdo#102254

fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254

shard-apltotal:3344 pass:1730 dwarn:1   dfail:0   fail:20  skip:1591 
time:13847s
shard-hswtotal:3427 pass:1719 dwarn:1   dfail:0   fail:52  skip:1654 
time:14795s
shard-snbtotal:3427 pass:1348 dwarn:1   dfail:0   fail:10  skip:2068 
time:7566s

== Logs ==

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

Re: [Intel-gfx] [PATCH 06/20] drm/i915/icl: Ringbuffer interrupt handling

[Daniele Ceraolo Spurio]

On 13/02/18 08:37, Mika Kuoppala wrote:

From: Tvrtko Ursulin 

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

v2: Rebase.
v3: Remove gen 11 extra check in logical_render_ring_init.
v4: Rebase fixes.
v5: Rebase/refactor.
v6: Rebase.
v7: Rebase.

Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Rodrigo Vivi 
Cc: Daniele Ceraolo Spurio 
---
  drivers/gpu/drm/i915/intel_breadcrumbs.c | 20 
  drivers/gpu/drm/i915/intel_lrc.c | 11 +--
  drivers/gpu/drm/i915/intel_ringbuffer.h  |  5 +
  3 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index b955f7d7bd0f..69c727f97eb5 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -167,18 +167,22 @@ static void irq_enable(struct intel_engine_cs *engine)
 */
set_bit(ENGINE_IRQ_BREADCRUMB, >irq_posted);
  
-	/* Caller disables interrupts */

-   spin_lock(>i915->irq_lock);
-   engine->irq_enable(engine);
-   spin_unlock(>i915->irq_lock);
+   if (engine->irq_enable) {
+   /* Caller disables interrupts */
+   spin_lock(>i915->irq_lock);
+   engine->irq_enable(engine);
+   spin_unlock(>i915->irq_lock);
+   }
  }
  
  static void irq_disable(struct intel_engine_cs *engine)

  {
-   /* Caller disables interrupts */
-   spin_lock(>i915->irq_lock);
-   engine->irq_disable(engine);
-   spin_unlock(>i915->irq_lock);
+   if (engine->irq_disable) {
+   /* Caller disables interrupts */
+   spin_lock(>i915->irq_lock);
+   engine->irq_disable(engine);
+   spin_unlock(>i915->irq_lock);
+   }
  }
  
  void __intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c2c8380a0121..da396c46b345 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1989,8 +1989,15 @@ logical_ring_default_vfuncs(struct intel_engine_cs 
*engine)
  
  	engine->set_default_submission = execlists_set_default_submission;
  
-	engine->irq_enable = gen8_logical_ring_enable_irq;

-   engine->irq_disable = gen8_logical_ring_disable_irq;
+   if (INTEL_GEN(engine->i915) < 11) {
+   engine->irq_enable = gen8_logical_ring_enable_irq;
+   engine->irq_disable = gen8_logical_ring_disable_irq;
+   } else {
+   /*
+* On Gen11 interrupts are permanently unmasked and there
+* are no per-engine instance mask bits.
+*/


As mentioned on the previous review, the masks exist but we can't use 
them easily, because according to the docs we need to clear them to 
allow C6 entry. My guess is that it is actually the possible pending 
interrupts behind the mask that can keep the device awake more than the 
masks value themselves, but the docs just say to clear the registers. 
Maybe a possible solution would be to track idleness per-engine and 
unmask the interrupts once all requests have completed on the specific 
engine? Anyway, while we're still in early enabling I'd just update this 
comment and the commit message to reflect that we don't use the mask to 
allow C6 entry and we can eventually come back to refine this at a later 
point if we see that we're generating too many interrupts.


With the updated comment and commit message:

Reviewed-by: Daniele Ceraolo Spurio 

Daniele


+   }
engine->emit_bb_start = gen8_emit_bb_start;
  }
  
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h

index f743351c441f..caed64bb02da 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -393,6 +393,11 @@ struct intel_engine_cs {
  
  	u32 irq_keep_mask; /* always keep these interrupts */

u32 irq_enable_mask; /* bitmask to enable ring interrupt */
+
+   /*
+* irq_enable and irq_disable do not have to be provided for
+* an engine. In other words they can be NULL.
+*/
void(*irq_enable)(struct intel_engine_cs *engine);
void(*irq_disable)(struct intel_engine_cs *engine);
  


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

Re: [Intel-gfx] [PATCH 01/20] drm/i915/icl: Add the ICL PCI IDs

[Anuj Phogat]

On Tue, Feb 13, 2018 at 8:37 AM, Mika Kuoppala <
mika.kuopp...@linux.intel.com> wrote:

> From: Paulo Zanoni 
>
> This is the current PCI ID list in our documentation.
>
> Let's leave the _gt#_ part out for now since our current documentation
> is not 100% clear and we don't need this info now anyway.
>
> v2: Use the new ICL_11 naming (Kelvin Gardiner).
> v3: Latest IDs as per BSpec (Oscar).
> v4: Make it compile (Paulo).
> v5: Remove comments (Lucas).
> v6: Multile rebases (Paulo).
> v7: Rebase (Mika)
>
> Reviewed-by: Anuj Phogat  (v1)
> Signed-off-by: Paulo Zanoni 
> Signed-off-by: Oscar Mateo 
> Signed-off-by: Lucas De Marchi 
> Signed-off-by: Rodrigo Vivi 
> Signed-off-by: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_pci.c |  1 +
>  include/drm/i915_pciids.h   | 12 
>  2 files changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c
> b/drivers/gpu/drm/i915/i915_pci.c
> index 4e7a10c89782..c94a76bef763 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -650,6 +650,7 @@ static const struct pci_device_id pciidlist[] = {
> INTEL_CFL_U_GT2_IDS(_coffeelake_gt2_info),
> INTEL_CFL_U_GT3_IDS(_coffeelake_gt3_info),
> INTEL_CNL_IDS(_cannonlake_info),
> +   INTEL_ICL_11_IDS(_icelake_11_info),
> {0, 0, 0}
>  };
>  MODULE_DEVICE_TABLE(pci, pciidlist);
> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> index 9e1fe6634424..4afcdb4492f1 100644
> --- a/include/drm/i915_pciids.h
> +++ b/include/drm/i915_pciids.h
> @@ -430,4 +430,16 @@
> INTEL_VGA_DEVICE(0x5A5C, info), \
> INTEL_VGA_DEVICE(0x5A44, info)
>
> +/* ICL */
> +#define INTEL_ICL_11_IDS(info) \
> +   INTEL_VGA_DEVICE(0x8A50, info), \
> +   INTEL_VGA_DEVICE(0x8A51, info), \
> +   INTEL_VGA_DEVICE(0x8A5C, info), \
> +   INTEL_VGA_DEVICE(0x8A5D, info), \
> +   INTEL_VGA_DEVICE(0x8A52, info), \
> +   INTEL_VGA_DEVICE(0x8A5A, info), \
> +   INTEL_VGA_DEVICE(0x8A5B, info), \
> +   INTEL_VGA_DEVICE(0x8A71, info), \
> +   INTEL_VGA_DEVICE(0x8A70, info)
>
​Why do we need a GT0 pci id in there?​


> +
>  #endif /* _I915_PCIIDS_H */
> --
> 2.14.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx