[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove unused "ret" variable.

[Patchwork]

== Series Details ==

Series: drm/i915: Remove unused "ret" variable.
URL   : https://patchwork.freedesktop.org/series/46904/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4517_full -> Patchwork_9724_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9724_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9724_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_9724_full:

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-vebox:
  shard-kbl:  PASS -> SKIP +1

igt@pm_rc6_residency@rc6-accuracy:
  shard-snb:  PASS -> SKIP


== Known issues ==

  Here are the changes found in Patchwork_9724_full that come from known issues:

  === IGT changes ===

 Possible fixes 

igt@kms_flip@2x-flip-vs-absolute-wf_vblank-interruptible:
  shard-glk:  FAIL (fdo#100368) -> PASS +1


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


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4517 -> Patchwork_9724

  CI_DRM_4517: 2a25e5014e7b215f4261b6479ac29dabc2633484 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4568: 86f7b724ef18986bc58d35558d22e1ed3f8df4f9 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9724: bce0d6bfd4ecb9f51511f73330253159a967f023 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

[Intel-gfx] Can recent i915 support more than 8192x8192 screen?

[Marcin Owsiany]

Hello,

*TL;DR*: how can I set a 8960x2880 screen (not display) size on a T580? A
patch for i915 that I found on the internets does not seem to work.

Full story:

I'm a rather happy user of ThinkPad T580 which comes with a
high-density 3840x2160 LCD, and the following graphics hardware.

00:02.0 VGA compatible controller: Intel Corporation Device 5917 (rev 07)
(prog-if 00 [VGA controller])
Subsystem: Lenovo Device 225a
Flags: bus master, fast devsel, latency 0, IRQ 142
Memory at e700 (64-bit, non-prefetchable) [size=16M]
Memory at c000 (64-bit, prefetchable) [size=256M]
I/O ports at e000 [size=64]
[virtual] Expansion ROM at 000c [disabled] [size=128K]
Capabilities: [40] Vendor Specific Information: Len=0c 
Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [100] Process Address Space ID (PASID)
Capabilities: [200] Address Translation Service (ATS)
Capabilities: [300] Page Request Interface (PRI)
Kernel driver in use: i915
Kernel modules: i915

Unfortunately attaching it to an external normal-density 2560x1440 display
means I need to apply scaling. Combined with the side-by-side arrangement
of monitors, this means I'd need to set screen size to 8960x2880. However
this does not work:

 $ xrandr --fb 8960x2880
 xrandr: screen cannot be larger than 8192x8192 (desired size 8960x2880)


I found this thread on reddit

 about the same problem, where a user posted a simple patch claimed to be
supplied by someone on #intel-gfx. Unfortunately it does not work (or at
least is not sufficient) - after applying it xrandr does claim
that 16384x16384 is possible, but actually trying to use more
than 8192x8192 fails with an error (unfortunately I lost the exact message).

My current workaround is to pretend that the displays are arranged
vertically, but even after a few months I'm sometimes having trouble
remembering that I need to move mouse cursor UP when I want to go to LEFT
display :-)

I wonder if someone could help me here. Even just getting a definite answer
on whether my hardware can in theory support this or not would be helpful,
since I found conflicting information.

FWIW I'm on Debian stable, Linux 4.9.8x.

regards,
Marcin
___
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/2] drm/i915/selftests: Use a full emulation of a user ppgtt context

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/selftests: Use a full emulation of 
a user ppgtt context
URL   : https://patchwork.freedesktop.org/series/46890/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4516_full -> Patchwork_9722_full =

== Summary - SUCCESS ==

  No regressions found.

  

== Known issues ==

  Here are the changes found in Patchwork_9722_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_exec_schedule@pi-ringfull-vebox:
  shard-apl:  NOTRUN -> FAIL (fdo#103158)

igt@kms_flip@2x-dpms-vs-vblank-race-interruptible:
  shard-glk:  PASS -> FAIL (fdo#103060)

igt@kms_setmode@basic:
  shard-apl:  PASS -> FAIL (fdo#99912)


 Possible fixes 

igt@drv_selftest@mock_sanitycheck:
  shard-snb:  INCOMPLETE (fdo#105411) -> PASS

igt@drv_suspend@shrink:
  shard-apl:  INCOMPLETE (fdo#103927, fdo#106886) -> PASS

igt@kms_flip@flip-vs-expired-vblank:
  shard-glk:  FAIL (fdo#102887, fdo#105363) -> PASS

igt@kms_flip@wf_vblank-ts-check-interruptible:
  shard-glk:  FAIL (fdo#100368) -> PASS

igt@kms_rotation_crc@cursor-rotation-180:
  shard-hsw:  FAIL (fdo#103925) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158
  fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
  fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4516 -> Patchwork_9722

  CI_DRM_4516: c8b4bb2d3541b7780a5125d09a21610f3440baef @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4568: 86f7b724ef18986bc58d35558d22e1ed3f8df4f9 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9722: 64c38cb15e4096f095021c901d8e0c036d7c52fa @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/selftests: Use a full emulation of a user ppgtt context

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/selftests: Use a full emulation of 
a user ppgtt context
URL   : https://patchwork.freedesktop.org/series/46890/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4515_full -> Patchwork_9721_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9721_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9721_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_9721_full:

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-bsd1:
  shard-kbl:  PASS -> SKIP +1


== Known issues ==

  Here are the changes found in Patchwork_9721_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions-varying-size:
  shard-hsw:  PASS -> FAIL (fdo#103355)

igt@kms_flip@plain-flip-fb-recreate:
  shard-glk:  PASS -> FAIL (fdo#100368)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  shard-snb:  PASS -> INCOMPLETE (fdo#105411)


 Possible fixes 

igt@drv_suspend@shrink:
  shard-apl:  FAIL (fdo#106886) -> PASS

igt@kms_rotation_crc@sprite-rotation-180:
  shard-hsw:  FAIL (fdo#103925) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355
  fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
  fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
  fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4515 -> Patchwork_9721

  CI_DRM_4515: 7d965fa499d11f7547066a827b3ae420f9e26f39 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4568: 86f7b724ef18986bc58d35558d22e1ed3f8df4f9 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9721: dd1dfc0b200245d46cf302f57a196deb5510a926 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix psr sink status report. (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix psr sink status report. (rev3)
URL   : https://patchwork.freedesktop.org/series/46831/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4518 -> Patchwork_9726 =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_9726 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9726, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/46831/revisions/3/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_9726:

  === IGT changes ===

 Possible regressions 

igt@drv_selftest@live_requests:
  fi-bsw-n3050:   PASS -> INCOMPLETE


== Known issues ==

  Here are the changes found in Patchwork_9726 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_coherency:
  fi-gdg-551: PASS -> DMESG-FAIL (fdo#107164)

igt@drv_selftest@live_hangcheck:
  fi-kbl-7567u:   PASS -> DMESG-FAIL (fdo#106947, fdo#106560)

igt@drv_selftest@live_workarounds:
  fi-bsw-n3050:   PASS -> DMESG-FAIL (fdo#107292)


 Possible fixes 

igt@drv_selftest@live_workarounds:
  {fi-cfl-8109u}: DMESG-FAIL (fdo#107292) -> PASS


  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
  fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
  fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164
  fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292


== Participating hosts (47 -> 41) ==

  Missing(6): fi-ilk-m540 fi-bxt-dsi fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-ctg-p8600 


== Build changes ==

* Linux: CI_DRM_4518 -> Patchwork_9726

  CI_DRM_4518: 85bdcb875339b30f7beecbc7cba6bc2041cdd28b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4569: bf70728a951cd3c08dd9bbc9310e16aaa252164f @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9726: 1593ca0bae97db5945ea3b294655b4d4e540a3ca @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

1593ca0bae97 drm/i915: Fix psr sink status report.

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/4] i915/dp/dsc: Add DSC PPS register definitions

[Manasi Navare]

Anusha,

This is not the correct latest patch. This still doesnt have _MMIO for DSCA_
and DSCC registers.

On Tue, Jul 17, 2018 at 02:10:59PM -0700, Anusha Srivatsa wrote:
> From: "Srivatsa, Anusha" 
> 
> Display Stream Compression(DSC) has a set of Picture
> Parameter Set(PPS) components that the encoder must
> communicate to the decoder.
> 
> This patch adds register definitions to
> the PPS parameters for eDP/MIPI case and Display Port.
> 
> v2:
> - Use _MMIO_PIPE instead of _MMIO(_PICK()). (Manasi)
> - Use DSC constants as arguments. (Manasi)
> 
> Cc: Lucas De Marchi 
> Cc: Ville Syrjala 
> Cc: Manasi Navare 
> Signed-off-by: Anusha Srivatsa 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 255 
> 
>  1 file changed, 255 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 23e70a4..e8687b0 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -10244,4 +10244,259 @@ enum skl_power_gate {
>_ICL_PHY_MISC_B)
>  #define  ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN(1 << 23)
>  
> +/* Icelake Display Stream Compression Registers */
> +#define DSCA_PICTURE_PARAMETER_SET_0 0x6B200

This should be _MMIO() for the reg value
and same for below

Manasi

> +#define DSCC_PICTURE_PARAMETER_SET_0 0x6BA00
> +#define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PB 0x78270
> +#define _ICL_DSC1_PICTURE_PARAMETER_SET_0_PB 0x78370
> +#define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PC 0x78470
> +#define _ICL_DSC1_PICTURE_PARAMETER_SET_0_PC 0x78570
> +#define ICL_DSC0_PICTURE_PARAMETER_SET_0(pipe)   _MMIO_PIPE((pipe) - 
> PIPE_B, \
> +
> _ICL_DSC0_PICTURE_PARAMETER_SET_0_PB, \
> +
> _ICL_DSC0_PICTURE_PARAMETER_SET_0_PC)
> +#define ICL_DSC1_PICTURE_PARAMETER_SET_0(pipe)   _MMIO_PIPE((pipe) - 
> PIPE_B, \
> +
> _ICL_DSC1_PICTURE_PARAMETER_SET_0_PB, \
> +
> _ICL_DSC1_PICTURE_PARAMETER_SET_0_PC)
> +#define  DSC_VBR_ENABLE  (1 << 19)
> +#define  DSC_422_ENABLE  (1 << 18)
> +#define  DSC_COLOR_SPACE_CONVERSION  (1 << 17)
> +#define  DSC_BLOCK_PREDICTION(1 << 16)
> +#define  DSC_LINE_BUF_DEPTH_SHIFT12
> +#define  DSC_BPC_SHIFT   8
> +#define  DSC_VER_MIN_SHIFT   4
> +#define  DSC_VER_MAJ (0x1 << 0)
> +
> +#define DSCA_PICTURE_PARAMETER_SET_1 0x6B204
> +#define DSCC_PICTURE_PARAMETER_SET_1 0x6BA04
> +#define _ICL_DSC0_PICTURE_PARAMETER_SET_1_PB 0x78274
> +#define _ICL_DSC1_PICTURE_PARAMETER_SET_1_PB 0x78374
> +#define _ICL_DSC0_PICTURE_PARAMETER_SET_1_PC 0x78474
> +#define _ICL_DSC1_PICTURE_PARAMETER_SET_1_PC 0x78574
> +#define ICL_DSC0_PICTURE_PARAMETER_SET_1(pipe)   _MMIO_PIPE((pipe) - 
> PIPE_B, \
> +
> _ICL_DSC0_PICTURE_PARAMETER_SET_1_PB, \
> +
> _ICL_DSC0_PICTURE_PARAMETER_SET_1_PC)
> +#define ICL_DSC1_PICTURE_PARAMETER_SET_1(pipe)   _MMIO_PIPE((pipe) - 
> PIPE_B, \
> +
> _ICL_DSC1_PICTURE_PARAMETER_SET_1_PB, \
> +
> _ICL_DSC1_PICTURE_PARAMETER_SET_1_PC)
> +#define  DSC_BPP(bpp)((bpp) << 0)
> +
> +#define DSCA_PICTURE_PARAMETER_SET_2 0x6B208
> +#define DSCC_PICTURE_PARAMETER_SET_2 0x6BA08
> +#define _ICL_DSC0_PICTURE_PARAMETER_SET_2_PB 0x78278
> +#define _ICL_DSC1_PICTURE_PARAMETER_SET_2_PB 0x78378
> +#define _ICL_DSC0_PICTURE_PARAMETER_SET_2_PC 0x78478
> +#define _ICL_DSC1_PICTURE_PARAMETER_SET_2_PC 0x78578
> +#define ICL_DSC0_PICTURE_PARAMETER_SET_2(pipe)   _MMIO_PIPE((pipe) - 
> PIPE_B, \
> +
> _ICL_DSC0_PICTURE_PARAMETER_SET_2_PB, \
> +
> _ICL_DSC0_PICTURE_PARAMETER_SET_2_PC)
> +#define ICL_DSC1_PICTURE_PARAMETER_SET_2(pipe)   _MMIO_PIPE((pipe) - 
> PIPE_B, \
> + 
> _ICL_DSC1_PICTURE_PARAMETER_SET_2_PB, \
> + 
> _ICL_DSC1_PICTURE_PARAMETER_SET_2_PC)
> +#define  DSC_PIC_WIDTH(pic_width)((pic_width) << 16)
> +#define  DSC_PIC_HEIGHT(pic_height)  ((pic_height) << 0)
> +
> +#define DSCA_PICTURE_PARAMETER_SET_3 0x6B20C
> +#define DSCC_PICTURE_PARAMETER_SET_3 0x6BA0C
> +#define _ICL_DSC0_PICTURE_PARAMETER_SET_3_PB 0x7827C
> +#define _ICL_DSC1_PICTURE_PARAMETER_SET_3_PB 0x7837C
> +#define _ICL_DSC0_PICTURE_PARAMETER_SET_3_PC 0x7847C
> +#define _ICL_DSC1_PICTURE_PARAMETER_SET_3_PC 0x7857C
> +#define ICL_DSC0_PICTURE_PARAMETER_SET_3(pip

Re: [Intel-gfx] [PATCH] drm/i915: Fix psr sink status report.

[Dhinakaran Pandiyan]

On Thu, 2018-07-19 at 17:31 -0700, Rodrigo Vivi wrote:
> First of all don't try to read dpcd if PSR is not even supported.
> 
> But also, if read failed return -EIO instead of reporting via a
> backchannel.
> 
> v2: fix dev_priv: At this level m->private is the connector. (CI/DK)
> don't convert dpcd read errors to EIO. (DK)
> 
> Fixes: 5b7b30864d1d ("drm/i915/psr: Split sink status into a separate
> debugfs node")
> Cc: Chris Wilson 
> Cc: Dhinakaran Pandiyan 
> Cc: José Roberto de Souza 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index b3aefd623557..59dc0610ea44 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2606,13 +2606,22 @@ static int i915_psr_sink_status_show(struct
> seq_file *m, void *data)
>   "sink internal error",
>   };
>   struct drm_connector *connector = m->private;
> + struct drm_i915_private *dev_priv = to_i915(connector->dev);
>   struct intel_dp *intel_dp =
>   enc_to_intel_dp(&intel_attached_encoder(connector)-
> >base);
> + int ret;
> +
> + if (!CAN_PSR(dev_priv)) {
> + seq_puts(m, "PSR Unsupported\n");
> + return -ENODEV;
> + }
>  
>   if (connector->status != connector_status_connected)
>   return -ENODEV;
>  
> - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_PSR_STATUS, &val)
> == 1) {
> + ret = drm_dp_dpcd_readb(&intel_dp->aux, DP_PSR_STATUS,
> &val);
> +
> + if (ret == 1) {
>   const char *str = "unknown";
>  
>   val &= DP_PSR_SINK_STATE_MASK;
> @@ -2620,7 +2629,7 @@ static int i915_psr_sink_status_show(struct
> seq_file *m, void *data)
>   str = sink_status[val];
>   seq_printf(m, "Sink PSR status: 0x%x [%s]\n", val,
> str);
>   } else {

dpcd_readb() is not expected to return anything other than 1 or a
negative error code, so this looks good.
Reviewed-by: Dhinakaran Pandiyan 


Are you also sending a similar fix for i915_dpcd_show()? That function
also prints a DRM_ERROR() for failed aux transactions.

> - DRM_ERROR("dpcd read (at %u) failed\n",
> DP_PSR_STATUS);
> + return ret;
>   }
>  
>   return 0;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Remove unused "ret" variable.

[Nathan Ciobanu]

On Thu, Jul 19, 2018 at 05:16:03PM -0700, Nathan Ciobanu wrote:
> On Thu, Jul 19, 2018 at 04:42:17PM -0700, Rodrigo Vivi wrote:
> > Just a small clean-up with no functional change, only
> > removing a variable that is never actually used.
> > 
> > Cc: Dhinakaran Pandiyan 
> > Signed-off-by: Rodrigo Vivi 
> Nice one :)
> Reviewed-by: 
Reviewed-by: Nathan Ciobanu 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_mst.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index 7e3e01607643..18c65f8e4fe8 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -263,7 +263,6 @@ static void intel_mst_enable_dp(struct intel_encoder 
> > *encoder,
> > struct intel_dp *intel_dp = &intel_dig_port->dp;
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > enum port port = intel_dig_port->base.port;
> > -   int ret;
> >  
> > DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
> >  
> > @@ -274,9 +273,9 @@ static void intel_mst_enable_dp(struct intel_encoder 
> > *encoder,
> > 1))
> > DRM_ERROR("Timed out waiting for ACT sent\n");
> >  
> > -   ret = drm_dp_check_act_status(&intel_dp->mst_mgr);
> > +   drm_dp_check_act_status(&intel_dp->mst_mgr);
> >  
> > -   ret = drm_dp_update_payload_part2(&intel_dp->mst_mgr);
> > +   drm_dp_update_payload_part2(&intel_dp->mst_mgr);
> > if (pipe_config->has_audio)
> > intel_audio_codec_enable(encoder, pipe_config, conn_state);
> >  }
> > -- 
> > 2.17.1
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Fix psr sink status report.

[Rodrigo Vivi]

First of all don't try to read dpcd if PSR is not even supported.

But also, if read failed return -EIO instead of reporting via a
backchannel.

v2: fix dev_priv: At this level m->private is the connector. (CI/DK)
don't convert dpcd read errors to EIO. (DK)

Fixes: 5b7b30864d1d ("drm/i915/psr: Split sink status into a separate debugfs 
node")
Cc: Chris Wilson 
Cc: Dhinakaran Pandiyan 
Cc: José Roberto de Souza 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index b3aefd623557..59dc0610ea44 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2606,13 +2606,22 @@ static int i915_psr_sink_status_show(struct seq_file 
*m, void *data)
"sink internal error",
};
struct drm_connector *connector = m->private;
+   struct drm_i915_private *dev_priv = to_i915(connector->dev);
struct intel_dp *intel_dp =
enc_to_intel_dp(&intel_attached_encoder(connector)->base);
+   int ret;
+
+   if (!CAN_PSR(dev_priv)) {
+   seq_puts(m, "PSR Unsupported\n");
+   return -ENODEV;
+   }
 
if (connector->status != connector_status_connected)
return -ENODEV;
 
-   if (drm_dp_dpcd_readb(&intel_dp->aux, DP_PSR_STATUS, &val) == 1) {
+   ret = drm_dp_dpcd_readb(&intel_dp->aux, DP_PSR_STATUS, &val);
+
+   if (ret == 1) {
const char *str = "unknown";
 
val &= DP_PSR_SINK_STATE_MASK;
@@ -2620,7 +2629,7 @@ static int i915_psr_sink_status_show(struct seq_file *m, 
void *data)
str = sink_status[val];
seq_printf(m, "Sink PSR status: 0x%x [%s]\n", val, str);
} else {
-   DRM_ERROR("dpcd read (at %u) failed\n", DP_PSR_STATUS);
+   return ret;
}
 
return 0;
-- 
2.17.1

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v5,2/2] drm/i915/dp: Refactor mav_vswing_tries variable (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [v5,2/2] drm/i915/dp: Refactor mav_vswing_tries 
variable (rev2)
URL   : https://patchwork.freedesktop.org/series/46897/
State : failure

== Summary ==

Applying: drm/i915/dp: Refactor mav_vswing_tries variable
error: sha1 information is lacking or useless 
(drivers/gpu/drm/i915/intel_dp_link_training.c).
error: could not build fake ancestor
Patch failed at 0001 drm/i915/dp: Refactor mav_vswing_tries variable
Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

Re: [Intel-gfx] [PATCH] drm/i915: Remove unused "ret" variable.

[Nathan Ciobanu]

On Thu, Jul 19, 2018 at 04:42:17PM -0700, Rodrigo Vivi wrote:
> Just a small clean-up with no functional change, only
> removing a variable that is never actually used.
> 
> Cc: Dhinakaran Pandiyan 
> Signed-off-by: Rodrigo Vivi 
Nice one :)
Reviewed-by: 
> ---
>  drivers/gpu/drm/i915/intel_dp_mst.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 7e3e01607643..18c65f8e4fe8 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -263,7 +263,6 @@ static void intel_mst_enable_dp(struct intel_encoder 
> *encoder,
>   struct intel_dp *intel_dp = &intel_dig_port->dp;
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   enum port port = intel_dig_port->base.port;
> - int ret;
>  
>   DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
>  
> @@ -274,9 +273,9 @@ static void intel_mst_enable_dp(struct intel_encoder 
> *encoder,
>   1))
>   DRM_ERROR("Timed out waiting for ACT sent\n");
>  
> - ret = drm_dp_check_act_status(&intel_dp->mst_mgr);
> + drm_dp_check_act_status(&intel_dp->mst_mgr);
>  
> - ret = drm_dp_update_payload_part2(&intel_dp->mst_mgr);
> + drm_dp_update_payload_part2(&intel_dp->mst_mgr);
>   if (pipe_config->has_audio)
>   intel_audio_codec_enable(encoder, pipe_config, conn_state);
>  }
> -- 
> 2.17.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v5] drm/i915/dp: Refactor max_vswing_tries variable

[Nathan Ciobanu]

Changes the type and renames the max_vswing_tries variable
which was declared as an integer but used as a boolean
making it easy to be confused with a counter.

Changes in v2:
- updated the title and commit message
- left the loop exit point in place

v3: fix typo in title

Cc: Dhinakaran Pandiyan 
Cc: Rodrigo Vivi 
Cc: Marc Herbert 
Signed-off-by: Nathan Ciobanu 
---
 drivers/gpu/drm/i915/intel_dp_link_training.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 7903de7a54c9..ec5f2bb55c9a 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -129,7 +129,8 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
 intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
 {
uint8_t voltage;
-   int voltage_tries, max_vswing_tries, cr_tries, max_cr_tries;
+   int voltage_tries, cr_tries, max_cr_tries;
+   bool max_vswing = false;
uint8_t link_config[2];
uint8_t link_bw, rate_select;
 
@@ -181,7 +182,6 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
max_cr_tries = 80;
 
voltage_tries = 1;
-   max_vswing_tries = 0;
for (cr_tries = 0; cr_tries < max_cr_tries; ++cr_tries) {
uint8_t link_status[DP_LINK_STATUS_SIZE];
 
@@ -202,7 +202,7 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
return false;
}
 
-   if (max_vswing_tries == 1) {
+   if (max_vswing) {
DRM_DEBUG_KMS("Max Voltage Swing reached\n");
return false;
}
@@ -223,7 +223,7 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
voltage_tries = 1;
 
if (intel_dp_link_max_vswing_reached(intel_dp))
-   ++max_vswing_tries;
+   max_vswing = true;
 
}
DRM_ERROR("Failed clock recovery %d times, giving up!\n", max_cr_tries);
-- 
1.9.1

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove unused "ret" variable.

[Patchwork]

== Series Details ==

Series: drm/i915: Remove unused "ret" variable.
URL   : https://patchwork.freedesktop.org/series/46904/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4517 -> Patchwork_9724 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/46904/revisions/1/mbox/

== Known issues ==

  Here are the changes found in Patchwork_9724 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@drv_module_reload@basic-reload:
  fi-glk-j4005:   PASS -> DMESG-WARN (fdo#106248, fdo#106725)

igt@drv_selftest@live_hangcheck:
  fi-kbl-7560u:   PASS -> DMESG-FAIL (fdo#106560, fdo#106947)

igt@drv_selftest@live_workarounds:
  {fi-cfl-8109u}: PASS -> DMESG-FAIL (fdo#107292)

igt@prime_vgem@basic-fence-flip:
  fi-cfl-8700k:   PASS -> FAIL (fdo#104008)


  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
  fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248
  fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
  fdo#106725 https://bugs.freedesktop.org/show_bug.cgi?id=106725
  fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
  fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292


== Participating hosts (47 -> 42) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4517 -> Patchwork_9724

  CI_DRM_4517: 2a25e5014e7b215f4261b6479ac29dabc2633484 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4568: 86f7b724ef18986bc58d35558d22e1ed3f8df4f9 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9724: bce0d6bfd4ecb9f51511f73330253159a967f023 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

bce0d6bfd4ec drm/i915: Remove unused "ret" variable.

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: GTT remapping for display

[Patchwork]

== Series Details ==

Series: drm/i915: GTT remapping for display
URL   : https://patchwork.freedesktop.org/series/46886/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4515_full -> Patchwork_9720_full =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_9720_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9720_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_9720_full:

  === IGT changes ===

 Possible regressions 

igt@kms_chv_cursor_fail@pipe-a-128x128-bottom-edge:
  shard-glk:  PASS -> FAIL +40

igt@kms_chv_cursor_fail@pipe-b-256x256-top-edge:
  shard-hsw:  PASS -> FAIL +42

igt@kms_cursor_legacy@all-pipes-forked-move:
  shard-snb:  PASS -> FAIL +33

igt@kms_cursor_legacy@long-nonblocking-modeset-vs-cursor-atomic:
  shard-apl:  PASS -> FAIL +48

igt@kms_cursor_legacy@pipe-c-single-bo:
  shard-kbl:  PASS -> FAIL +47


== Known issues ==

  Here are the changes found in Patchwork_9720_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@drv_suspend@shrink:
  shard-glk:  PASS -> INCOMPLETE (fdo#106886, fdo#103359, 
k.org#198133)

igt@kms_cursor_legacy@nonblocking-modeset-vs-cursor-atomic:
  shard-kbl:  PASS -> FAIL (fdo#106026) +1


 Possible fixes 

igt@drv_suspend@shrink:
  shard-apl:  FAIL (fdo#106886) -> PASS

igt@kms_rotation_crc@sprite-rotation-180:
  shard-hsw:  FAIL (fdo#103925) -> PASS


  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
  fdo#106026 https://bugs.freedesktop.org/show_bug.cgi?id=106026
  fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4515 -> Patchwork_9720

  CI_DRM_4515: 7d965fa499d11f7547066a827b3ae420f9e26f39 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4568: 86f7b724ef18986bc58d35558d22e1ed3f8df4f9 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9720: b6b0962ca4811bf575148132f299fd0b14bbf8f4 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Remove unused "ret" variable.

[Rodrigo Vivi]

Just a small clean-up with no functional change, only
removing a variable that is never actually used.

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

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 7e3e01607643..18c65f8e4fe8 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -263,7 +263,6 @@ static void intel_mst_enable_dp(struct intel_encoder 
*encoder,
struct intel_dp *intel_dp = &intel_dig_port->dp;
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum port port = intel_dig_port->base.port;
-   int ret;
 
DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
 
@@ -274,9 +273,9 @@ static void intel_mst_enable_dp(struct intel_encoder 
*encoder,
1))
DRM_ERROR("Timed out waiting for ACT sent\n");
 
-   ret = drm_dp_check_act_status(&intel_dp->mst_mgr);
+   drm_dp_check_act_status(&intel_dp->mst_mgr);
 
-   ret = drm_dp_update_payload_part2(&intel_dp->mst_mgr);
+   drm_dp_update_payload_part2(&intel_dp->mst_mgr);
if (pipe_config->has_audio)
intel_audio_codec_enable(encoder, pipe_config, conn_state);
 }
-- 
2.17.1

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

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/mst: Continue state updates even if AUX writes fail.

[Rodrigo Vivi]

On Thu, Jul 19, 2018 at 11:51:40AM -0700, Dhinakaran Pandiyan wrote:
> On Wed, 2018-07-18 at 22:43 -0700, Rodrigo Vivi wrote:
> > On Wed, Jul 18, 2018 at 10:19:43AM -0700, Dhinakaran Pandiyan wrote:
> > > 
> > > We are too late in the enabling sequence to back out cleanly, not
> > > updating
> > > state tracking variables, like intel_dp->active_mst_links in this
> > > instance, results in incorrect behaviour further along.
> > I agree with you, although I'm not fully convinced that we need to
> > call the
> > update payload if vcpi allocation failed...
> 
> But there is more payload update code in intel_mst_enable_dp(),

oh... the part2 indeed...

> that
> would get executed regardless of this diff below. We'll have to rewrite
> pre_enable, enable, disable and post_disable if the idea is avoid sink
> transactions after the first failure. It does make sense to do all of
> that as it avoids printing error messages in dmesg when we very well
> know the branch device is disconnected, but this should be a separate
> change.

fair enough...

> My idea was to bring pre_enable/enable in line with
> disable/post_disable.

makes sense... I just saw it is similar on payload update failure.

Reviewed-by: Rodrigo Vivi 

> 
> 
> > 
> > so imho this entire function should be reworked to be like this:
> > 
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -217,7 +217,6 @@ static void intel_mst_pre_enable_dp(struct
> > intel_encoder *encoder,
> > enum port port = intel_dig_port->base.port;
> > struct intel_connector *connector =
> > to_intel_connector(conn_state->connector);
> > -   int ret;
> > uint32_t temp;
> >  
> > /* MST encoders are bound to a crtc, not to a connector,
> > @@ -233,25 +232,15 @@ static void intel_mst_pre_enable_dp(struct
> > intel_encoder *encoder,
> >  
> > drm_dp_send_power_updown_phy(&intel_dp->mst_mgr, connector-
> > >port, true);
> >  
> > -   if (intel_dp->active_mst_links == 0)
> > +   if (intel_dp->active_mst_links++ == 0)
> > intel_dig_port->base.pre_enable(&intel_dig_port-
> > >base,
> > pipe_config, NULL);
> >  
> > -   ret = drm_dp_mst_allocate_vcpi(&intel_dp->mst_mgr,
> > -  connector->port,
> > -  pipe_config->pbn,
> > -  pipe_config->dp_m_n.tu);
> > -   if (ret == false) {
> > +   if (drm_dp_mst_allocate_vcpi(&intel_dp->mst_mgr, connector-
> > >port,
> > +pipe_config->pbn, pipe_config-
> > >dp_m_n.tu))
> > +   drm_dp_update_payload_part1(&intel_dp->mst_mgr);
> > +   else
> > DRM_ERROR("failed to allocate vcpi\n");
> > -   return;
> > -   }
> > -
> > -
> > -   intel_dp->active_mst_links++;
> > -   temp = I915_READ(DP_TP_STATUS(port));
> > -   I915_WRITE(DP_TP_STATUS(port), temp);
> > -
> > -   ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
> > 
> > 
> > probably with
> > -   temp = I915_READ(DP_TP_STATUS(port));
> > -   I915_WRITE(DP_TP_STATUS(port), temp);
> > 
> > in a separated patch. No idea why we read this staus reg and write
> > back.
> It is clearing the ACT status bit by writing a 1. Bspec has this
> under DP_TP_STATUS:24
> 
> -DK
> 
> > I didn't see on spec any indication that this cleans it or that we
> > need that
> > for cleaning or anything else.
> > 
> > > 
> > > 
> > > v2: Fixed int v/s bool comparison
> > > 
> > > Cc: Ville Syrjälä 
> > > Cc: Rodrigo Vivi 
> > > Cc: Nathan Ciobanu 
> > > Signed-off-by: Dhinakaran Pandiyan 
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp_mst.c | 5 +
> > >  1 file changed, 1 insertion(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > index 7e3e01607643..110e7ff22ef7 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > @@ -241,11 +241,8 @@ static void intel_mst_pre_enable_dp(struct
> > > intel_encoder *encoder,
> > >      connector->port,
> > >      pipe_config->pbn,
> > >      pipe_config->dp_m_n.tu);
> > > - if (ret == false) {
> > > + if (!ret)
> > >   DRM_ERROR("failed to allocate vcpi\n");
> > > - return;
> > > - }
> > > -
> > >  
> > >   intel_dp->active_mst_links++;
> > >   temp = I915_READ(DP_TP_STATUS(port));
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [alsa-devel] [PATCH v2 0/3] Make the audio component binding more generic

[Pierre-Louis Bossart]

On 7/19/18 1:56 PM, Takashi Iwai wrote:

On Thu, 19 Jul 2018 15:05:45 +0200,
Pierre-Louis Bossart wrote:


On 7/19/18 12:50 AM, Takashi Iwai wrote:

On Wed, 18 Jul 2018 22:54:35 +0200,
Pierre-Louis Bossart wrote:




On 07/17/2018 04:26 AM, Takashi Iwai wrote:

Hi,

this is a preliminiary patch set to convert the existing i915 /
HD-audio component binding to be applicable to other drivers like
radeon / amdgpu.  This patchset itself doesn't change the
functionality but only renames and split to a new drm_audio_component
stuff from i915_audio_component.

The actual usage of the new API will follow once after this one gets
reviewed / accepted.  The whole patches (including this patchset) are
found in topic/hda-acomp branch of sound.git tree.

BTW, since the whole stuff is about the audio binding, I suppose these
will go through sound git tree.  Let me know if anyone has concerns.

No objections but a slight concern that this will conflict with the
HDAudio+DSP patches that I was about to resubmit on top of your
topic/hda-core-intel branch. the two series touch the same files so
it'd be a miracle if there is no issue.
How do you want to deal with this?


Does it conflict severely?  If it's trivial, it can be resolved at
merge time, too.  The changes in my patchset are fairly trivial, so it
shouldn't be too hard.


I was able to make things work by taking your topic/hda-core-intel,
merge it on Mark's for-next, then add my additional changes and these
DRM changes. The last two can be done in any order. But I am getting
some conflicts if I try to apply these DRM changes first, not sure why
git is complaining though, the changes look trivial enough.
So yes it looks possible to deal with the two series in parallel, will
send my update later today.


OK, since my changes are relatively trivial to deal with, I merge the
changes to for-next branch now.

If your patches can be respinned, maybe it's easier to be rebased on
top of these merges.


I was planning to resend them tomorrow after internal reviews (mostly 
changes in the detection/enablement of the HDaudio+DSP case). If you 
want to take a look in the mean time the patches are here: 
https://github.com/plbossart/sound/commits/upstream/hda2


I can rebase them as needed, no big deal.
Thanks
-Pierre



Mark, could you merge topic/drm_audio_component branch into yours, if
Pierre's patchset won't go in immediately?  It's an immutable branch,
including already topic/hda-core-intel in itself.


thanks,

Takashi



___
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 [v3,1/2] drm/i915/icl: move has_resource_streamer to GEN11_FEATURES

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/2] drm/i915/icl: move has_resource_streamer 
to GEN11_FEATURES
URL   : https://patchwork.freedesktop.org/series/46884/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4514_full -> Patchwork_9719_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9719_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9719_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_9719_full:

  === IGT changes ===

 Warnings 

igt@kms_chv_cursor_fail@pipe-b-128x128-top-edge:
  shard-snb:  SKIP -> PASS +1


== Known issues ==

  Here are the changes found in Patchwork_9719_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_flip@2x-modeset-vs-vblank-race-interruptible:
  shard-glk:  PASS -> FAIL (fdo#103060)


 Possible fixes 

igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic:
  shard-hsw:  FAIL (fdo#105767) -> PASS

igt@kms_setmode@basic:
  shard-apl:  FAIL (fdo#99912) -> PASS


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


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4514 -> Patchwork_9719

  CI_DRM_4514: 4aa8b84189887647612154ca9eda06cfc9a587df @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4568: 86f7b724ef18986bc58d35558d22e1ed3f8df4f9 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9719: fc42f78a7aa4ea7c840510cdec07cc9c13727c10 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT

[Rodrigo Vivi]

On Thu, Jul 19, 2018 at 02:47:59PM -0700, Atwood, Matthew S wrote:
> On Thu, 2018-07-19 at 14:07 -0700, Rodrigo Vivi wrote:
> > On Thu, Jul 19, 2018 at 01:35:49PM -0700, matthew.s.atw...@intel.com
> > wrote:
> > > From: Matt Atwood 
> > > 
> > > According to DP spec (2.9.3.1 of DP 1.4) if
> > > EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in
> > > DPCD
> > > 02200h through 0220Fh shall contain the DPRX's true capability.
> > > These
> > > values will match 0h through Fh, except for DPCD_REV,
> > > MAX_LINK_RATE, DOWN_STREAM_PORT_PRESENT.
> > > 
> > > Read from DPCD once for all 3 values as this is an expensive
> > > operation.
> > > Spec mentions that all of address space 02200h through 0220Fh
> > > should
> > > contain the right information however currently only 3 values can
> > > differ.
> > > 
> > > There is no address space in the intel_dp->dpcd struct for
> > > addresses
> > > 02200h through 0220Fh, and since so much of the data is a
> > > identical,
> > > simply overwrite the values stored in 0h through Fh with
> > > the
> > > values that can be overwritten from addresses 02200h through
> > > 0220Fh.
> > > 
> > > This patch helps with backward compatibility for devices pre DP1.3.
> > > 
> > > v2: read only dpcd values which can be affected, remove incorrect
> > > check,
> > > split into drm include changes into separate patch, commit message,
> > > verbose debugging statements during overwrite.
> > > 
> > > v3: white space fixes
> > > 
> > > Signed-off-by: Matt Atwood 
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c | 37
> > > +
> > >  1 file changed, 37 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index dde92e4af5d3..a31fbbbd7954 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -3738,6 +3738,43 @@ intel_dp_read_dpcd(struct intel_dp
> > > *intel_dp)
> > >sizeof(intel_dp->dpcd)) < 0)
> > >   return false; /* aux transfer failed */
> > >  
> > 
> > We never know what vendors can do with reserved bits. We should never
> > assume
> > they are zero. So we shouldn't do any of below unless it is newer
> > than DP 1.3.
> I think you mean newer than DP1.2?

yeap, sorry..

>= DP1.3

> > 
> > > + if (intel_dp->dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> > > + DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT) {
> > > + uint8_t dpcd_ext[6];
> > > +
> > > + DRM_DEBUG_KMS("DPCD: Extended Receiver Capability
> > > Field Present, accessing 02200h through 022FFh\n");
> > > +
> > > + if (drm_dp_dpcd_read(&intel_dp->aux,
> > > DP_DP13_DPCD_REV,
> > > +  &dpcd_ext, sizeof(dpcd_ext))
> > > < 0)
> > > + return false; /* aux transfer failed */
> > > +
> > > + if (memcmp(&intel_dp->dpcd[DP_DPCD_REV],
> > > &dpcd_ext[DP_DPCD_REV],
> > > +sizeof(u8))) {
> > > + DRM_DEBUG_KMS("DPCD: new value for DPCD
> > > Revision previous value %2x new value %2x\n",
> > > +   intel_dp->dpcd[DP_DPCD_REV],
> > > +   dpcd_ext[DP_DPCD_REV]);
> > > + memcpy(&intel_dp->dpcd[DP_DPCD_REV],
> > > +&dpcd_ext[DP_DPCD_REV],
> > > +sizeof(u8));
> > > + }
> > > + if (memcmp(&intel_dp->dpcd[DP_MAX_LINK_RATE],
> > > +&dpcd_ext[DP_MAX_LINK_RATE],
> > > sizeof(u8))) {
> > > + DRM_DEBUG_KMS("DPCD: new value for DPCD
> > > Max Link Rate previous value %2x new value %2x\n",
> > > +   intel_dp-
> > > >dpcd[DP_MAX_LINK_RATE],
> > > +   dpcd_ext[DP_MAX_LINK_RATE]);
> > > + memcpy(&intel_dp->dpcd[DP_MAX_LINK_RATE],
> > > +&dpcd_ext[DP_MAX_LINK_RATE],
> > > sizeof(u8));
> > > + }
> > > + if (memcmp(&intel_dp-
> > > >dpcd[DP_DOWNSTREAMPORT_PRESENT],
> > > +&dpcd_ext[DP_DOWNSTREAMPORT_PRESENT],
> > > sizeof(u8))) {
> > > + DRM_DEBUG_KMS("DPCD: new value for DPCD
> > > Downstream Port Present  previous value %2x new value %2x\n",
> > > +   intel_dp-
> > > >dpcd[DP_DOWNSTREAMPORT_PRESENT],
> > > +   dpcd_ext[DP_DOWNSTREAMPORT_P
> > > RESENT]);
> > > + memcpy(&intel_dp-
> > > >dpcd[DP_DOWNSTREAMPORT_PRESENT],
> > > +&dpcd_ext[DP_DOWNSTREAMPORT_PRESENT
> > > ],
> > > +sizeof(u8));
> > > + }
> > > + }
> > >   DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp-
> > > >dpcd), intel_dp->dpcd);
> > >  
> > >   return intel_dp->dpcd[DP_DPCD_REV] != 0;
> > > -- 
> > > 2.17.1
> > > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mail

[Intel-gfx] [PATCH v5 2/2] drm/i915/dp: Refactor mav_vswing_tries variable

[Nathan Ciobanu]

Changes the type and renames the max_vswing_tries variable
which was declared as an integer but used as a boolean
making it easy to be confused with a counter.

Changes in v2:
- updated the title and commit message
- left the loop exit point in place

Cc: Dhinakaran Pandiyan 
Cc: Rodrigo Vivi 
Cc: Marc Herbert 
Signed-off-by: Nathan Ciobanu 
---
 drivers/gpu/drm/i915/intel_dp_link_training.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 7903de7a54c9..ec5f2bb55c9a 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -129,7 +129,8 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
 intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
 {
uint8_t voltage;
-   int voltage_tries, max_vswing_tries, cr_tries, max_cr_tries;
+   int voltage_tries, cr_tries, max_cr_tries;
+   bool max_vswing = false;
uint8_t link_config[2];
uint8_t link_bw, rate_select;
 
@@ -181,7 +182,6 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
max_cr_tries = 80;
 
voltage_tries = 1;
-   max_vswing_tries = 0;
for (cr_tries = 0; cr_tries < max_cr_tries; ++cr_tries) {
uint8_t link_status[DP_LINK_STATUS_SIZE];
 
@@ -202,7 +202,7 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
return false;
}
 
-   if (max_vswing_tries == 1) {
+   if (max_vswing) {
DRM_DEBUG_KMS("Max Voltage Swing reached\n");
return false;
}
@@ -223,7 +223,7 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
voltage_tries = 1;
 
if (intel_dp_link_max_vswing_reached(intel_dp))
-   ++max_vswing_tries;
+   max_vswing = true;
 
}
DRM_ERROR("Failed clock recovery %d times, giving up!\n", max_cr_tries);
-- 
1.9.1

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

[Intel-gfx] [PATCH v5 1/2] drm/i915/dp: Limit link training clock recovery loop

[Nathan Ciobanu]

Limit the link training clock recovery loop to 10 attempts at
LANEx_CR_DONE per DP 1.4 spec section 3.5.1.2.2 and 80 attempts for
pre-DP 1.4 (4 voltage levels x 4 preemphasis levels x
x 5 identical voltages tries). Some faulty USB-C MST hubs can
cause us to get stuck in this loop indefinitely requesting something
like:

voltage swing: 0, pre-emphasis level: 2
voltage swing: 1, pre-emphasis level: 2
voltage swing: 0, pre-emphasis level: 3

over and over so max_vswing would never be reached,
drm_dp_clock_recovery_ok() would never return true and voltage_tries
would always get reset to 1. The driver sends those values to the hub
but the hub keeps requesting new values every time.

Changes in v2:
- updated commit message (DK, Manasi)
- defined DP_DP14_MAX_CR_TRIES (Marc)
- made the loop iterate for max 10 times (Rodrigo, Marc)

Changes in v3:
- changed error message to use DP_DP14_MAX_CR_TRIES

Changes in v4:
- Updated the title to reflect the change
- Updated the commit message
- Added 80 attempts for pre-DP 1.4 devices

Changes in v5:
- Removed DP_DP14_MAX_CR_TRIES from drm

Cc: Dhinakaran Pandiyan 
Cc: Rodrigo Vivi 
Cc: Marc Herbert 
Cc: Manasi Navare 
Signed-off-by: Nathan Ciobanu 
---
 drivers/gpu/drm/i915/intel_dp_link_training.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 4da6e33c7fa1..7903de7a54c9 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -129,7 +129,7 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
 intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
 {
uint8_t voltage;
-   int voltage_tries, max_vswing_tries;
+   int voltage_tries, max_vswing_tries, cr_tries, max_cr_tries;
uint8_t link_config[2];
uint8_t link_bw, rate_select;
 
@@ -170,9 +170,19 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
return false;
}
 
+   /* DP 1.4 spec clock recovery retries defined but
+* for devices pre-DP 1.4 we set the retry limit
+* to 4 (voltage levels) x 4 (preemphasis levels) x
+* x 5 (same voltage retries) = 80 (max iterations)
+*/
+   if (intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
+   max_cr_tries = 10;
+   else
+   max_cr_tries = 80;
+
voltage_tries = 1;
max_vswing_tries = 0;
-   for (;;) {
+   for (cr_tries = 0; cr_tries < max_cr_tries; ++cr_tries) {
uint8_t link_status[DP_LINK_STATUS_SIZE];
 
drm_dp_link_train_clock_recovery_delay(intel_dp->dpcd);
@@ -216,6 +226,8 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
++max_vswing_tries;
 
}
+   DRM_ERROR("Failed clock recovery %d times, giving up!\n", max_cr_tries);
+   return false;
 }
 
 /*
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT

[Atwood, Matthew S]

On Thu, 2018-07-19 at 14:07 -0700, Rodrigo Vivi wrote:
> On Thu, Jul 19, 2018 at 01:35:49PM -0700, matthew.s.atw...@intel.com
> wrote:
> > From: Matt Atwood 
> > 
> > According to DP spec (2.9.3.1 of DP 1.4) if
> > EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in
> > DPCD
> > 02200h through 0220Fh shall contain the DPRX's true capability.
> > These
> > values will match 0h through Fh, except for DPCD_REV,
> > MAX_LINK_RATE, DOWN_STREAM_PORT_PRESENT.
> > 
> > Read from DPCD once for all 3 values as this is an expensive
> > operation.
> > Spec mentions that all of address space 02200h through 0220Fh
> > should
> > contain the right information however currently only 3 values can
> > differ.
> > 
> > There is no address space in the intel_dp->dpcd struct for
> > addresses
> > 02200h through 0220Fh, and since so much of the data is a
> > identical,
> > simply overwrite the values stored in 0h through Fh with
> > the
> > values that can be overwritten from addresses 02200h through
> > 0220Fh.
> > 
> > This patch helps with backward compatibility for devices pre DP1.3.
> > 
> > v2: read only dpcd values which can be affected, remove incorrect
> > check,
> > split into drm include changes into separate patch, commit message,
> > verbose debugging statements during overwrite.
> > 
> > v3: white space fixes
> > 
> > Signed-off-by: Matt Atwood 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 37
> > +
> >  1 file changed, 37 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index dde92e4af5d3..a31fbbbd7954 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3738,6 +3738,43 @@ intel_dp_read_dpcd(struct intel_dp
> > *intel_dp)
> >  sizeof(intel_dp->dpcd)) < 0)
> > return false; /* aux transfer failed */
> >  
> 
> We never know what vendors can do with reserved bits. We should never
> assume
> they are zero. So we shouldn't do any of below unless it is newer
> than DP 1.3.
I think you mean newer than DP1.2?
> 
> > +   if (intel_dp->dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> > +   DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT) {
> > +   uint8_t dpcd_ext[6];
> > +
> > +   DRM_DEBUG_KMS("DPCD: Extended Receiver Capability
> > Field Present, accessing 02200h through 022FFh\n");
> > +
> > +   if (drm_dp_dpcd_read(&intel_dp->aux,
> > DP_DP13_DPCD_REV,
> > +&dpcd_ext, sizeof(dpcd_ext))
> > < 0)
> > +   return false; /* aux transfer failed */
> > +
> > +   if (memcmp(&intel_dp->dpcd[DP_DPCD_REV],
> > &dpcd_ext[DP_DPCD_REV],
> > +  sizeof(u8))) {
> > +   DRM_DEBUG_KMS("DPCD: new value for DPCD
> > Revision previous value %2x new value %2x\n",
> > + intel_dp->dpcd[DP_DPCD_REV],
> > + dpcd_ext[DP_DPCD_REV]);
> > +   memcpy(&intel_dp->dpcd[DP_DPCD_REV],
> > +  &dpcd_ext[DP_DPCD_REV],
> > +  sizeof(u8));
> > +   }
> > +   if (memcmp(&intel_dp->dpcd[DP_MAX_LINK_RATE],
> > +  &dpcd_ext[DP_MAX_LINK_RATE],
> > sizeof(u8))) {
> > +   DRM_DEBUG_KMS("DPCD: new value for DPCD
> > Max Link Rate previous value %2x new value %2x\n",
> > + intel_dp-
> > >dpcd[DP_MAX_LINK_RATE],
> > + dpcd_ext[DP_MAX_LINK_RATE]);
> > +   memcpy(&intel_dp->dpcd[DP_MAX_LINK_RATE],
> > +  &dpcd_ext[DP_MAX_LINK_RATE],
> > sizeof(u8));
> > +   }
> > +   if (memcmp(&intel_dp-
> > >dpcd[DP_DOWNSTREAMPORT_PRESENT],
> > +  &dpcd_ext[DP_DOWNSTREAMPORT_PRESENT],
> > sizeof(u8))) {
> > +   DRM_DEBUG_KMS("DPCD: new value for DPCD
> > Downstream Port Present  previous value %2x new value %2x\n",
> > + intel_dp-
> > >dpcd[DP_DOWNSTREAMPORT_PRESENT],
> > + dpcd_ext[DP_DOWNSTREAMPORT_P
> > RESENT]);
> > +   memcpy(&intel_dp-
> > >dpcd[DP_DOWNSTREAMPORT_PRESENT],
> > +  &dpcd_ext[DP_DOWNSTREAMPORT_PRESENT
> > ],
> > +  sizeof(u8));
> > +   }
> > +   }
> > DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp-
> > >dpcd), intel_dp->dpcd);
> >  
> > return intel_dp->dpcd[DP_DPCD_REV] != 0;
> > -- 
> > 2.17.1
> > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/dp: add extended receiver capability field present bit (rev3)

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/dp: add extended receiver capability 
field present bit (rev3)
URL   : https://patchwork.freedesktop.org/series/46743/
State : failure

== Summary ==

Applying: drm/dp: add extended receiver capability field present bit
Applying: drm/dp: add extended receiver capability field present bit
Using index info to reconstruct a base tree...
M   include/drm/drm_dp_helper.h
Falling back to patching base and 3-way merge...
Auto-merging include/drm/drm_dp_helper.h
CONFLICT (content): Merge conflict in include/drm/drm_dp_helper.h
error: Failed to merge in the changes.
Patch failed at 0002 drm/dp: add extended receiver capability field present bit
Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/selftests: Use a full emulation of a user ppgtt context

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/selftests: Use a full emulation of 
a user ppgtt context
URL   : https://patchwork.freedesktop.org/series/46890/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4516 -> Patchwork_9722 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/46890/revisions/1/mbox/

== Known issues ==

  Here are the changes found in Patchwork_9722 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_workarounds:
  {fi-cfl-8109u}: NOTRUN -> DMESG-FAIL (fdo#107292)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927)


 Possible fixes 

igt@debugfs_test@read_all_entries:
  fi-snb-2520m:   INCOMPLETE (fdo#103713) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  {fi-cfl-8109u}: INCOMPLETE (fdo#106070) -> PASS


  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#106070 https://bugs.freedesktop.org/show_bug.cgi?id=106070
  fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292


== Participating hosts (47 -> 42) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4516 -> Patchwork_9722

  CI_DRM_4516: c8b4bb2d3541b7780a5125d09a21610f3440baef @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4568: 86f7b724ef18986bc58d35558d22e1ed3f8df4f9 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9722: 64c38cb15e4096f095021c901d8e0c036d7c52fa @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

64c38cb15e40 drm/i915/selftests: Exercise resetting in the middle of a 
wait-on-fence
4d8e5baa6a03 drm/i915/selftests: Use a full emulation of a user ppgtt context

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Cache the error string (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Cache the error string (rev4)
URL   : https://patchwork.freedesktop.org/series/46777/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4513_full -> Patchwork_9718_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9718_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9718_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_9718_full:

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-bsd2:
  shard-kbl:  PASS -> SKIP +1

igt@gem_exec_schedule@deep-vebox:
  shard-kbl:  SKIP -> PASS


== Known issues ==

  Here are the changes found in Patchwork_9718_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
  shard-glk:  PASS -> FAIL (fdo#105363)

igt@kms_flip@plain-flip-fb-recreate:
  shard-glk:  PASS -> FAIL (fdo#100368) +1

igt@kms_setmode@basic:
  shard-glk:  PASS -> FAIL (fdo#99912)

igt@perf@blocking:
  shard-hsw:  PASS -> FAIL (fdo#102252)


 Possible fixes 

igt@kms_flip@2x-wf_vblank-ts-check-interruptible:
  shard-glk:  FAIL (fdo#100368) -> PASS

igt@kms_rotation_crc@sprite-rotation-180:
  shard-hsw:  FAIL (fdo#103925) -> PASS


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


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4513 -> Patchwork_9718

  CI_DRM_4513: d592f2da0236d6d7ce4d4cccb40441c54dce5d91 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4568: 86f7b724ef18986bc58d35558d22e1ed3f8df4f9 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9718: f146b4a83eece6f2d42b30911d9fc6a922dff824 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT

[Rodrigo Vivi]

On Thu, Jul 19, 2018 at 01:35:49PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
> 
> According to DP spec (2.9.3.1 of DP 1.4) if
> EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in DPCD
> 02200h through 0220Fh shall contain the DPRX's true capability. These
> values will match 0h through Fh, except for DPCD_REV,
> MAX_LINK_RATE, DOWN_STREAM_PORT_PRESENT.
> 
> Read from DPCD once for all 3 values as this is an expensive operation.
> Spec mentions that all of address space 02200h through 0220Fh should
> contain the right information however currently only 3 values can
> differ.
> 
> There is no address space in the intel_dp->dpcd struct for addresses
> 02200h through 0220Fh, and since so much of the data is a identical,
> simply overwrite the values stored in 0h through Fh with the
> values that can be overwritten from addresses 02200h through 0220Fh.
> 
> This patch helps with backward compatibility for devices pre DP1.3.
> 
> v2: read only dpcd values which can be affected, remove incorrect check,
> split into drm include changes into separate patch, commit message,
> verbose debugging statements during overwrite.
> 
> v3: white space fixes
> 
> Signed-off-by: Matt Atwood 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 37 +
>  1 file changed, 37 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index dde92e4af5d3..a31fbbbd7954 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3738,6 +3738,43 @@ intel_dp_read_dpcd(struct intel_dp *intel_dp)
>sizeof(intel_dp->dpcd)) < 0)
>   return false; /* aux transfer failed */
>  

We never know what vendors can do with reserved bits. We should never assume
they are zero. So we shouldn't do any of below unless it is newer than DP 1.3.

> + if (intel_dp->dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> + DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT) {
> + uint8_t dpcd_ext[6];
> +
> + DRM_DEBUG_KMS("DPCD: Extended Receiver Capability Field 
> Present, accessing 02200h through 022FFh\n");
> +
> + if (drm_dp_dpcd_read(&intel_dp->aux, DP_DP13_DPCD_REV,
> +  &dpcd_ext, sizeof(dpcd_ext)) < 0)
> + return false; /* aux transfer failed */
> +
> + if (memcmp(&intel_dp->dpcd[DP_DPCD_REV], &dpcd_ext[DP_DPCD_REV],
> +sizeof(u8))) {
> + DRM_DEBUG_KMS("DPCD: new value for DPCD Revision 
> previous value %2x new value %2x\n",
> +   intel_dp->dpcd[DP_DPCD_REV],
> +   dpcd_ext[DP_DPCD_REV]);
> + memcpy(&intel_dp->dpcd[DP_DPCD_REV],
> +&dpcd_ext[DP_DPCD_REV],
> +sizeof(u8));
> + }
> + if (memcmp(&intel_dp->dpcd[DP_MAX_LINK_RATE],
> +&dpcd_ext[DP_MAX_LINK_RATE], sizeof(u8))) {
> + DRM_DEBUG_KMS("DPCD: new value for DPCD Max Link Rate 
> previous value %2x new value %2x\n",
> +   intel_dp->dpcd[DP_MAX_LINK_RATE],
> +   dpcd_ext[DP_MAX_LINK_RATE]);
> + memcpy(&intel_dp->dpcd[DP_MAX_LINK_RATE],
> +&dpcd_ext[DP_MAX_LINK_RATE], sizeof(u8));
> + }
> + if (memcmp(&intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
> +&dpcd_ext[DP_DOWNSTREAMPORT_PRESENT], sizeof(u8))) {
> + DRM_DEBUG_KMS("DPCD: new value for DPCD Downstream Port 
> Present  previous value %2x new value %2x\n",
> +   intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
> +   dpcd_ext[DP_DOWNSTREAMPORT_PRESENT]);
> + memcpy(&intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
> +&dpcd_ext[DP_DOWNSTREAMPORT_PRESENT],
> +sizeof(u8));
> + }
> + }
>   DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd), 
> intel_dp->dpcd);
>  
>   return intel_dp->dpcd[DP_DPCD_REV] != 0;
> -- 
> 2.17.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/dp: add extended receiver capability field present bit

[Rodrigo Vivi]

On Thu, Jul 19, 2018 at 01:35:48PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
> 
> This bit was added to DP Training Aux RD interval sometime between DP
> 1.2 and DP 1.3.

I understand that some 1.2 version that I had here that caused
all the trouble around XXX 1.2, but since one of the requests
from Jani was to clarify and remove the 1.2 I went there to check
again and that version that I had here doesn't work anymore.

So I went to VESA site and checked and it is not there on latest
official 1.2a.
It is there on 1.3.

This message should be updated now.

> Via description of the spec this field indicates the
> panels true capabilities are described in DPCD address space 02200h
> through 022FFh.
> 
> v2: version comment update
> 
> Signed-off-by: Matt Atwood 
> ---
>  include/drm/drm_dp_helper.h | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index c01564991a9f..28061c69136b 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -123,8 +123,9 @@
>  # define DP_FRAMING_CHANGE_CAP   (1 << 1)
>  # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher 
> */
>  
> -#define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
> -# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2? */
> +#define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
> +# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.3? */
> +# define DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT (1 << 7)/* XXX 1.3? */

Since that is the official and clear thing we should now remove XXX
and add /* DP 1.3 */

I believe that during 1.2 times we might had seen a lot of those
bizare cases when one version has it and another doesn't, and probably
that was the cause of many /* XXX 1.2? */ we have on the driver.

But please note that there is no XXX for 1.3 and 1.4, since things
are very clear and organized.

>  
>  #define DP_ADAPTER_CAP   0x00f   /* 1.2 */
>  # define DP_FORCE_LOAD_SENSE_CAP (1 << 0)
> -- 
> 2.17.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/dp: add extended receiver capability field present bit

[matthew . s . atwood]

From: Matt Atwood 

This bit was added to DP Training Aux RD interval sometime between DP
1.2 and DP 1.3. Via description of the spec this field indicates the
panels true capabilities are described in DPCD address space 02200h
through 022FFh.

v2: version comment update

Signed-off-by: Matt Atwood 
---
 include/drm/drm_dp_helper.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c01564991a9f..28061c69136b 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -123,8 +123,9 @@
 # define DP_FRAMING_CHANGE_CAP (1 << 1)
 # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher */
 
-#define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
-# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2? */
+#define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
+# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.3? */
+# define DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT (1 << 7)/* XXX 1.3? */
 
 #define DP_ADAPTER_CAP 0x00f   /* 1.2 */
 # define DP_FORCE_LOAD_SENSE_CAP   (1 << 0)
-- 
2.17.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: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT

[matthew . s . atwood]

From: Matt Atwood 

According to DP spec (2.9.3.1 of DP 1.4) if
EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in DPCD
02200h through 0220Fh shall contain the DPRX's true capability. These
values will match 0h through Fh, except for DPCD_REV,
MAX_LINK_RATE, DOWN_STREAM_PORT_PRESENT.

Read from DPCD once for all 3 values as this is an expensive operation.
Spec mentions that all of address space 02200h through 0220Fh should
contain the right information however currently only 3 values can
differ.

There is no address space in the intel_dp->dpcd struct for addresses
02200h through 0220Fh, and since so much of the data is a identical,
simply overwrite the values stored in 0h through Fh with the
values that can be overwritten from addresses 02200h through 0220Fh.

This patch helps with backward compatibility for devices pre DP1.3.

v2: read only dpcd values which can be affected, remove incorrect check,
split into drm include changes into separate patch, commit message,
verbose debugging statements during overwrite.

v3: white space fixes

Signed-off-by: Matt Atwood 
---
 drivers/gpu/drm/i915/intel_dp.c | 37 +
 1 file changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index dde92e4af5d3..a31fbbbd7954 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3738,6 +3738,43 @@ intel_dp_read_dpcd(struct intel_dp *intel_dp)
 sizeof(intel_dp->dpcd)) < 0)
return false; /* aux transfer failed */
 
+   if (intel_dp->dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+   DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT) {
+   uint8_t dpcd_ext[6];
+
+   DRM_DEBUG_KMS("DPCD: Extended Receiver Capability Field 
Present, accessing 02200h through 022FFh\n");
+
+   if (drm_dp_dpcd_read(&intel_dp->aux, DP_DP13_DPCD_REV,
+&dpcd_ext, sizeof(dpcd_ext)) < 0)
+   return false; /* aux transfer failed */
+
+   if (memcmp(&intel_dp->dpcd[DP_DPCD_REV], &dpcd_ext[DP_DPCD_REV],
+  sizeof(u8))) {
+   DRM_DEBUG_KMS("DPCD: new value for DPCD Revision 
previous value %2x new value %2x\n",
+ intel_dp->dpcd[DP_DPCD_REV],
+ dpcd_ext[DP_DPCD_REV]);
+   memcpy(&intel_dp->dpcd[DP_DPCD_REV],
+  &dpcd_ext[DP_DPCD_REV],
+  sizeof(u8));
+   }
+   if (memcmp(&intel_dp->dpcd[DP_MAX_LINK_RATE],
+  &dpcd_ext[DP_MAX_LINK_RATE], sizeof(u8))) {
+   DRM_DEBUG_KMS("DPCD: new value for DPCD Max Link Rate 
previous value %2x new value %2x\n",
+ intel_dp->dpcd[DP_MAX_LINK_RATE],
+ dpcd_ext[DP_MAX_LINK_RATE]);
+   memcpy(&intel_dp->dpcd[DP_MAX_LINK_RATE],
+  &dpcd_ext[DP_MAX_LINK_RATE], sizeof(u8));
+   }
+   if (memcmp(&intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
+  &dpcd_ext[DP_DOWNSTREAMPORT_PRESENT], sizeof(u8))) {
+   DRM_DEBUG_KMS("DPCD: new value for DPCD Downstream Port 
Present  previous value %2x new value %2x\n",
+ intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
+ dpcd_ext[DP_DOWNSTREAMPORT_PRESENT]);
+   memcpy(&intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
+  &dpcd_ext[DP_DOWNSTREAMPORT_PRESENT],
+  sizeof(u8));
+   }
+   }
DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd), 
intel_dp->dpcd);
 
return intel_dp->dpcd[DP_DPCD_REV] != 0;
-- 
2.17.1

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

Re: [Intel-gfx] [PATCH 15/18] drm/i915: Add a new "remapped" gtt_view

[Chris Wilson]

Quoting Ville Syrjälä (2018-07-19 21:16:20)
> > > > > +} __packed;
> > > > > +
> > > > > +static inline void assert_intel_remapped_info_is_packed(void)
> > > > > +{
> > > > > +   BUILD_BUG_ON(sizeof(struct intel_remapped_info) != 
> > > > > 10*sizeof(unsigned int));
> 
> Hmm. These assert inlines don't seem to be doing their job. Clearly
> my struct size was 9 ints not 10.

gcc is getting overly smart. Pull all the asserts into one
assert_i915_gem_gtt_types() and then call that from i915_vma_compare().
-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/2] drm/i915/selftests: Use a full emulation of a user ppgtt context

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/selftests: Use a full emulation of 
a user ppgtt context
URL   : https://patchwork.freedesktop.org/series/46890/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4515 -> Patchwork_9721 =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_9721 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9721, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/46890/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_9721:

  === IGT changes ===

 Possible regressions 

igt@drv_selftest@live_hangcheck:
  fi-cfl-guc: PASS -> DMESG-FAIL


 Warnings 

igt@drv_selftest@live_execlists:
  {fi-cfl-8109u}: SKIP -> PASS +1


== Known issues ==

  Here are the changes found in Patchwork_9721 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_hangcheck:
  fi-skl-guc: PASS -> DMESG-FAIL (fdo#107174)
  {fi-skl-iommu}: PASS -> DMESG-FAIL (fdo#106560, fdo#107174)


 Possible fixes 

igt@drv_selftest@live_hangcheck:
  {fi-cfl-8109u}: DMESG-FAIL -> PASS

igt@gem_exec_suspend@basic-s4-devices:
  fi-kbl-7500u:   DMESG-WARN (fdo#105128, fdo#107139) -> PASS

igt@kms_flip@basic-flip-vs-dpms:
  fi-skl-6700hq:  DMESG-WARN (fdo#105998) -> PASS


 Warnings 

igt@gem_exec_suspend@basic-s4-devices:
  {fi-kbl-8809g}: DMESG-WARN (fdo#107139) -> INCOMPLETE (fdo#103665, 
fdo#107139)


  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128
  fdo#105998 https://bugs.freedesktop.org/show_bug.cgi?id=105998
  fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
  fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139
  fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174


== Participating hosts (47 -> 42) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4515 -> Patchwork_9721

  CI_DRM_4515: 7d965fa499d11f7547066a827b3ae420f9e26f39 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4568: 86f7b724ef18986bc58d35558d22e1ed3f8df4f9 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9721: dd1dfc0b200245d46cf302f57a196deb5510a926 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

dd1dfc0b2002 drm/i915/selftests: Exercise resetting in the middle of a 
wait-on-fence
02691ccd8fc9 drm/i915/selftests: Use a full emulation of a user ppgtt context

== Logs ==

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

Re: [Intel-gfx] [PATCH v8] drm/i915: Fix assert_plane() warning on bootup with external display

[Ville Syrjälä]

On Thu, Jul 19, 2018 at 08:03:42PM +, Shaikh, Azhar wrote:
> 
> 
> >-Original Message-
> >From: Shaikh, Azhar
> >Sent: Friday, July 6, 2018 11:38 AM
> >To: intel-gfx@lists.freedesktop.org
> >Cc: ville.syrj...@linux.intel.com; Navare, Manasi D
> >; Shaikh, Azhar 
> >Subject: [PATCH v8] drm/i915: Fix assert_plane() warning on bootup with
> >external display
> >
> >On KBL, WHL RVPs, booting up with an external display connected, triggers
> >below warning, when the BiOS brings up the external display too.
> >This warning is not seen during hotplug.
> >
> >[3.615226] [ cut here ]
> >[3.619829] plane 1A assertion failure (expected on, current off)
> >[3.632039] WARNING: CPU: 2 PID: 354 at
> >drivers/gpu/drm/i915/intel_display.c:1294 assert_plane+0x71/0xbb
> >[3.633920] iwlwifi :00:14.3: loaded firmware version 38.c0e03d94.0
> >op_mode iwlmvm
> >[3.647157] Modules linked in: iwlwifi cfg80211 btusb btrtl btbcm btintel
> >bluetooth ecdh_generic
> >[3.647163] CPU: 2 PID: 354 Comm: frecon Not tainted 4.17.0-rc7-50176-
> >g655af12d39c2 #3
> >[3.647165] Hardware name: Intel Corporation CoffeeLake Client
> >Platform/WhiskeyLake U DDR4 ERB, BIOS
> >CNLSFWR1.R00.X140.B00.1804040304 04/04/2018
> >[3.684509] RIP: 0010:assert_plane+0x71/0xbb
> >[3.764451] Call Trace:
> >[3.766888]  intel_atomic_commit_tail+0xa97/0xb77
> >[3.771569]  intel_atomic_commit+0x26a/0x279
> >[3.771572]  drm_atomic_helper_set_config+0x5c/0x76
> >[3.780670]  __drm_mode_set_config_internal+0x66/0x109
> >[3.780672]  drm_mode_setcrtc+0x4c9/0x5cc
> >[3.780674]  ? drm_mode_getcrtc+0x162/0x162
> >[3.789774]  ? drm_mode_getcrtc+0x162/0x162
> >[3.798108]  drm_ioctl_kernel+0x8d/0xe4
> >[3.801926]  drm_ioctl+0x27d/0x368
> >[3.805311]  ? drm_mode_getcrtc+0x162/0x162
> >[3.805314]  ? selinux_file_ioctl+0x14e/0x199
> >[3.805317]  vfs_ioctl+0x21/0x2f
> >[3.813812]  do_vfs_ioctl+0x491/0x4b4
> >[3.813813]  ? security_file_ioctl+0x37/0x4b
> >[3.813816]  ksys_ioctl+0x55/0x75
> >[3.820672]  __x64_sys_ioctl+0x1a/0x1e
> >[3.820674]  do_syscall_64+0x51/0x5f
> >[3.820678]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >[3.828221] RIP: 0033:0x7b5e04953967
> >[3.835504] RSP: 002b:7fff2eafb6f8 EFLAGS: 0246 ORIG_RAX:
> >0010
> >[3.835505] RAX: ffda RBX: 0002 RCX:
> >7b5e04953967
> >[3.835505] RDX: 7fff2eafb730 RSI: c06864a2 RDI:
> >000f
> >[3.835506] RBP: 7fff2eafb720 R08:  R09:
> >
> >[3.835507] R10: 0070 R11: 0246 R12:
> >000f
> >[3.879988] R13: 56bc9dd7d210 R14: 7fff2eafb730 R15:
> >c06864a2
> >[3.887081] Code: 48 c7 c7 06 71 a5 be 84 c0 48 c7 c2 06 fd a3 be 48 89 
> >f9 48 0f
> >44 ca 84 db 48 0f 45 d7 48 c7 c7 df d3 a4 be 31 c0 e8 af a0 c0 ff <0f> 0b eb 
> >2b 48
> >c7 c7 06 fd a3 be 84 c0 48 c7 c2 06 71 a5 be 48
> >[3.905845] WARNING: CPU: 2 PID: 354 at
> >drivers/gpu/drm/i915/intel_display.c:1294 assert_plane+0x71/0xbb
> >[3.920964] ---[ end trace dac692f4ac46391a ]---
> >
> >The warning is seen when mode_setcrtc() is called for pipeB during bootup
> >and before we get a mode_setcrtc() for pipeA, while doing update_crtcs() in
> >intel_atomic_commit_tail().
> >Now since, plane1A is still active after commit, update_crtcs() is done for
> >pipeA and eventually update_plane() for plane1A.
> >
> >intel_plane_state->ctl for plane1A is not updated since set_modecrtc() is
> >called for pipeB. So intel_plane_state->ctl for plane 1A will be 0x0.
> >So doing an update_plane() for plane1A, will result in clearing
> >PLANE_CTL_ENABLE bit, and hence the warning.
> >
> >To fix this warning, force all active planes to recompute their states in 
> >probe.
> >
> >Changes in v8:
> >- Actually add Reviewed-by: Ville Syrjälä 
> >
> >Changes in v7:
> >- Move call to intel_initial_commit() after sanitize_watermarks()
> >  Otherwise the plane update will still consult potentially bogus
> >  watermarks we read out from the hardware. (Ville)
> >- Carry Reviewed-by: Ville Syrjälä 
> >  from v6
> >
> >Changes in v6:
> >- Handle EDEADLK for drm_atomic_get_crtc_state() and
> >  drm_atomic_add_affected_planes()
> >- Remove optimization of calling intel_initial_commit()
> >  only when there is more than one active pipe in probe.
> >- Avoid using intel_ types.
> >
> >Changes in v5:
> >- Drop drm_modeset_lock_all_ctx() since locks will be taken later.
> >
> >Changes in v4:
> >- Handle locking in intel_initial_commit()
> >- Move the for loop inside intel_initial_commit() so that
> >  drm_atomic_commit() is called only once
> >- Call intel_initial_commit() only for more than one active crtc on boot.
> >- Save the return value of intel_initial_commit() and print a message in
> >  case of an error
> >
> >Changes in v3:
> >- Add comments
> >
> >Changes in v2:
> >- Force 

Re: [Intel-gfx] [PATCH 15/18] drm/i915: Add a new "remapped" gtt_view

[Ville Syrjälä]

On Thu, Jul 19, 2018 at 08:46:54PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-07-19 20:33:57)
> > On Thu, Jul 19, 2018 at 07:59:33PM +0100, Chris Wilson wrote:
> > > Quoting Ville Syrjala (2018-07-19 19:22:11)
> > > > +static struct scatterlist *
> > > > +remap_pages(const dma_addr_t *in, unsigned int offset,
> > > > +   unsigned int width, unsigned int height,
> > > > +   unsigned int stride,
> > > > +   struct sg_table *st, struct scatterlist *sg)
> > > > +{
> > > > +   unsigned int column, row;
> > > > +
> > > > +   for (row = 0; row < height; row++) {
> > > > +   for (column = 0; column < width; column++) {
> > > > +   st->nents++;
> > > > +   /* We don't need the pages, but need to 
> > > > initialize
> > > > +* the entries so the sg list can be happily 
> > > > traversed.
> > > > +* The only thing we need are DMA addresses.
> > > > +*/
> > > > +   sg_set_page(sg, NULL, PAGE_SIZE, 0);
> > > > +   sg_dma_address(sg) = in[offset + column];
> > > > +   sg_dma_len(sg) = PAGE_SIZE;
> > > > +   sg = sg_next(sg);
> > > 
> > > Ok. But should be I915_GTT_PAGE_SIZE?
> > 
> > I suppose. And now I wonder what would happen on gen2 with its
> > 2KiB gtt pages. Probably nothing good.
> 
> Pffifle. We call it 4KiB. It's just about the semantics, and here we
> should be splitting the dma addresses by GTT_PAGE_SIZE rather than
> system page size.
> 
> > > > +struct intel_remapped_info {
> > > > +   struct intel_remapped_plane_info {
> > > > +   /* tiles */
> > > > +   unsigned int width, height, stride, offset;
> > > > +   } plane[2];
> > > > +   unsigned int unused;
> > > 
> > > Tag it as mbz, since we do use it inside the compare. Hmm, I wonder if
> > > it actually is better if it doesn't exist if it isn't used, then it
> > > should be zero.. Hmm, not sure if that's defined at all, might have to
> > > say memset and don't rely on {} zeroing?
> > > 
> > > Should work fine as a memcmp key for the rbtree.
> > 
> > This whole thing is a bit questionale the way I did it. When populating
> > the gtt_view I just poke at view->rotated and rely on matching layout
> > for view->remapped. To make it less magic maybe I should embed one
> > inside the other?
> 
> Hmm. If it's intentionally the same layout, then we should just use the
> same struct for both. remapped/remap_info is generic enough to cover
> rotation as well.
> 
> > > > +} __packed;
> > > > +
> > > > +static inline void assert_intel_remapped_info_is_packed(void)
> > > > +{
> > > > +   BUILD_BUG_ON(sizeof(struct intel_remapped_info) != 
> > > > 10*sizeof(unsigned int));

Hmm. These assert inlines don't seem to be doing their job. Clearly
my struct size was 9 ints not 10.

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

Re: [Intel-gfx] [PATCH v8] drm/i915: Fix assert_plane() warning on bootup with external display

[Shaikh, Azhar]

>-Original Message-
>From: Shaikh, Azhar
>Sent: Friday, July 6, 2018 11:38 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: ville.syrj...@linux.intel.com; Navare, Manasi D
>; Shaikh, Azhar 
>Subject: [PATCH v8] drm/i915: Fix assert_plane() warning on bootup with
>external display
>
>On KBL, WHL RVPs, booting up with an external display connected, triggers
>below warning, when the BiOS brings up the external display too.
>This warning is not seen during hotplug.
>
>[3.615226] [ cut here ]
>[3.619829] plane 1A assertion failure (expected on, current off)
>[3.632039] WARNING: CPU: 2 PID: 354 at
>drivers/gpu/drm/i915/intel_display.c:1294 assert_plane+0x71/0xbb
>[3.633920] iwlwifi :00:14.3: loaded firmware version 38.c0e03d94.0
>op_mode iwlmvm
>[3.647157] Modules linked in: iwlwifi cfg80211 btusb btrtl btbcm btintel
>bluetooth ecdh_generic
>[3.647163] CPU: 2 PID: 354 Comm: frecon Not tainted 4.17.0-rc7-50176-
>g655af12d39c2 #3
>[3.647165] Hardware name: Intel Corporation CoffeeLake Client
>Platform/WhiskeyLake U DDR4 ERB, BIOS
>CNLSFWR1.R00.X140.B00.1804040304 04/04/2018
>[3.684509] RIP: 0010:assert_plane+0x71/0xbb
>[3.764451] Call Trace:
>[3.766888]  intel_atomic_commit_tail+0xa97/0xb77
>[3.771569]  intel_atomic_commit+0x26a/0x279
>[3.771572]  drm_atomic_helper_set_config+0x5c/0x76
>[3.780670]  __drm_mode_set_config_internal+0x66/0x109
>[3.780672]  drm_mode_setcrtc+0x4c9/0x5cc
>[3.780674]  ? drm_mode_getcrtc+0x162/0x162
>[3.789774]  ? drm_mode_getcrtc+0x162/0x162
>[3.798108]  drm_ioctl_kernel+0x8d/0xe4
>[3.801926]  drm_ioctl+0x27d/0x368
>[3.805311]  ? drm_mode_getcrtc+0x162/0x162
>[3.805314]  ? selinux_file_ioctl+0x14e/0x199
>[3.805317]  vfs_ioctl+0x21/0x2f
>[3.813812]  do_vfs_ioctl+0x491/0x4b4
>[3.813813]  ? security_file_ioctl+0x37/0x4b
>[3.813816]  ksys_ioctl+0x55/0x75
>[3.820672]  __x64_sys_ioctl+0x1a/0x1e
>[3.820674]  do_syscall_64+0x51/0x5f
>[3.820678]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
>[3.828221] RIP: 0033:0x7b5e04953967
>[3.835504] RSP: 002b:7fff2eafb6f8 EFLAGS: 0246 ORIG_RAX:
>0010
>[3.835505] RAX: ffda RBX: 0002 RCX:
>7b5e04953967
>[3.835505] RDX: 7fff2eafb730 RSI: c06864a2 RDI:
>000f
>[3.835506] RBP: 7fff2eafb720 R08:  R09:
>
>[3.835507] R10: 0070 R11: 0246 R12:
>000f
>[3.879988] R13: 56bc9dd7d210 R14: 7fff2eafb730 R15:
>c06864a2
>[3.887081] Code: 48 c7 c7 06 71 a5 be 84 c0 48 c7 c2 06 fd a3 be 48 89 f9 
>48 0f
>44 ca 84 db 48 0f 45 d7 48 c7 c7 df d3 a4 be 31 c0 e8 af a0 c0 ff <0f> 0b eb 
>2b 48
>c7 c7 06 fd a3 be 84 c0 48 c7 c2 06 71 a5 be 48
>[3.905845] WARNING: CPU: 2 PID: 354 at
>drivers/gpu/drm/i915/intel_display.c:1294 assert_plane+0x71/0xbb
>[3.920964] ---[ end trace dac692f4ac46391a ]---
>
>The warning is seen when mode_setcrtc() is called for pipeB during bootup
>and before we get a mode_setcrtc() for pipeA, while doing update_crtcs() in
>intel_atomic_commit_tail().
>Now since, plane1A is still active after commit, update_crtcs() is done for
>pipeA and eventually update_plane() for plane1A.
>
>intel_plane_state->ctl for plane1A is not updated since set_modecrtc() is
>called for pipeB. So intel_plane_state->ctl for plane 1A will be 0x0.
>So doing an update_plane() for plane1A, will result in clearing
>PLANE_CTL_ENABLE bit, and hence the warning.
>
>To fix this warning, force all active planes to recompute their states in 
>probe.
>
>Changes in v8:
>- Actually add Reviewed-by: Ville Syrjälä 
>
>Changes in v7:
>- Move call to intel_initial_commit() after sanitize_watermarks()
>  Otherwise the plane update will still consult potentially bogus
>  watermarks we read out from the hardware. (Ville)
>- Carry Reviewed-by: Ville Syrjälä 
>  from v6
>
>Changes in v6:
>- Handle EDEADLK for drm_atomic_get_crtc_state() and
>  drm_atomic_add_affected_planes()
>- Remove optimization of calling intel_initial_commit()
>  only when there is more than one active pipe in probe.
>- Avoid using intel_ types.
>
>Changes in v5:
>- Drop drm_modeset_lock_all_ctx() since locks will be taken later.
>
>Changes in v4:
>- Handle locking in intel_initial_commit()
>- Move the for loop inside intel_initial_commit() so that
>  drm_atomic_commit() is called only once
>- Call intel_initial_commit() only for more than one active crtc on boot.
>- Save the return value of intel_initial_commit() and print a message in
>  case of an error
>
>Changes in v3:
>- Add comments
>
>Changes in v2:
>- Force all planes to recompute their states.(Ville Syrjälä)
>- Update the commit message
>
>Signed-off-by: Azhar Shaikh 
>Reviewed-by: Ville Syrjälä 
>---

Can someone please merge/push this change?


> drivers/gpu/drm/i915/intel_display.c | 61
>++--
> 1 file changed, 59 

Re: [Intel-gfx] [PATCH 15/18] drm/i915: Add a new "remapped" gtt_view

[Ville Syrjälä]

On Thu, Jul 19, 2018 at 08:46:54PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-07-19 20:33:57)
> > On Thu, Jul 19, 2018 at 07:59:33PM +0100, Chris Wilson wrote:
> > > Quoting Ville Syrjala (2018-07-19 19:22:11)
> > > > +static struct scatterlist *
> > > > +remap_pages(const dma_addr_t *in, unsigned int offset,
> > > > +   unsigned int width, unsigned int height,
> > > > +   unsigned int stride,
> > > > +   struct sg_table *st, struct scatterlist *sg)
> > > > +{
> > > > +   unsigned int column, row;
> > > > +
> > > > +   for (row = 0; row < height; row++) {
> > > > +   for (column = 0; column < width; column++) {
> > > > +   st->nents++;
> > > > +   /* We don't need the pages, but need to 
> > > > initialize
> > > > +* the entries so the sg list can be happily 
> > > > traversed.
> > > > +* The only thing we need are DMA addresses.
> > > > +*/
> > > > +   sg_set_page(sg, NULL, PAGE_SIZE, 0);
> > > > +   sg_dma_address(sg) = in[offset + column];
> > > > +   sg_dma_len(sg) = PAGE_SIZE;
> > > > +   sg = sg_next(sg);
> > > 
> > > Ok. But should be I915_GTT_PAGE_SIZE?
> > 
> > I suppose. And now I wonder what would happen on gen2 with its
> > 2KiB gtt pages. Probably nothing good.
> 
> Pffifle. We call it 4KiB. It's just about the semantics, and here we
> should be splitting the dma addresses by GTT_PAGE_SIZE rather than
> system page size.
> 
> > > > +struct intel_remapped_info {
> > > > +   struct intel_remapped_plane_info {
> > > > +   /* tiles */
> > > > +   unsigned int width, height, stride, offset;
> > > > +   } plane[2];
> > > > +   unsigned int unused;
> > > 
> > > Tag it as mbz, since we do use it inside the compare. Hmm, I wonder if
> > > it actually is better if it doesn't exist if it isn't used, then it
> > > should be zero.. Hmm, not sure if that's defined at all, might have to
> > > say memset and don't rely on {} zeroing?
> > > 
> > > Should work fine as a memcmp key for the rbtree.
> > 
> > This whole thing is a bit questionale the way I did it. When populating
> > the gtt_view I just poke at view->rotated and rely on matching layout
> > for view->remapped. To make it less magic maybe I should embed one
> > inside the other?
> 
> Hmm. If it's intentionally the same layout, then we should just use the
> same struct for both. remapped/remap_info is generic enough to cover
> rotation as well.
> 
> > > > +} __packed;
> > > > +
> > > > +static inline void assert_intel_remapped_info_is_packed(void)
> > > > +{
> > > > +   BUILD_BUG_ON(sizeof(struct intel_remapped_info) != 
> > > > 10*sizeof(unsigned int));
> > > > +}
> > > > +
> > > >  struct intel_rotation_info {
> > > > struct intel_rotation_plane_info {
> > > > /* tiles */
> > > > @@ -186,6 +199,7 @@ enum i915_ggtt_view_type {
> > > > I915_GGTT_VIEW_NORMAL = 0,
> > > > I915_GGTT_VIEW_ROTATED = sizeof(struct intel_rotation_info),
> > > > I915_GGTT_VIEW_PARTIAL = sizeof(struct intel_partial_info),
> > > > +   I915_GGTT_VIEW_REMAPPED = sizeof(struct intel_remapped_info),
> 
> Oh, forgot about that trick. Yeah, they do need to differ in structs.
> 
> Hmm, so I think keep the remap_plane_info and reuse that?
> 
> struct intel_remapped_info {
>struct intel_remapped_plane_info {
>/* tiles */
>unsigned int width, height, stride, offset;
>} plane[2];
>int unused_mbz; 
> };
> 
> 
> struct intel_rotation_info {
>   struct intel_remmaped_plane_info plane[2];
> };
> 
> static inline void assert_intel_rotation_matches_remapped_info(void)
> {
>   /* Check that rotation/remapped shares offsets for simplicity */
>   BUILD_BUG_ON(offsetof(struct intel_remapped_info, plane[0]) !=
>offsetof(struct intel_rotation_info, plane[0]));
>   BUILD_BUG_ON(offsetofend(struct intel_remapped_info, plane[1]) !=
>offsetofend(struct intel_rotation_info, plane[1]));
> }

Yeah, something like that could work.

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

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915: kill resource streamer

[Rodrigo Vivi]

On Thu, Jul 19, 2018 at 12:12:08PM -0700, Lucas De Marchi wrote:
> On Thu, Jul 19, 2018 at 10:18 AM Rodrigo Vivi  wrote:
> >
> > On Thu, Jul 19, 2018 at 10:05:57AM -0700, Lucas De Marchi wrote:
> > > After disabling resource streamer on ICL (due to it actually not
> > > existing there), I got feedback that there have been some experimental
> > > patches for mesa to use RS years ago, but nothing ever landed or shipped
> > > because there was no performance improvement.
> > >
> > > This removes it from kernel keeping the uapi defines around for
> > > compatibility.
> > >
> > > v2: - re-add the inadvertent removal of CTX_CTRL_INHIBIT_SYN_CTX_SWITCH
> > > - don't bother trying to document removed params on uapi header:
> > >   applications should know that from the query.
> > >   (from Chris)
> > >
> > > v3: - disable CTX_CTRL_RS_CTX_ENABLE istead of removing it
> > > - reword commit message after Daniele confirmed no performance
> > >   regression on his machine
> > > - reword commit message to make clear RS is being removed due to
> > >   never been used
> >
> > thanks
> >
> > >
> > > Signed-off-by: Lucas De Marchi 
> > > Acked-by: Daniele Ceraolo Spurio 
> >
> > Reviewed-by: Rodrigo Vivi 
> >
> > (I will wait CI and then I will push)
> 
> there's also the i-g-t patch, otherwise there will be some tests failing.

ok, so we wait the igt to land and trigger re-test on this when that happens
and when CI is happy we push it.

> 
> Lucas De Marchi
> 
> >
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.c|  2 +-
> > >  drivers/gpu/drm/i915/i915_drv.h|  2 --
> > >  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 15 ++-
> > >  drivers/gpu/drm/i915/i915_pci.c|  4 
> > >  drivers/gpu/drm/i915/intel_device_info.h   |  1 -
> > >  drivers/gpu/drm/i915/intel_lrc.c   | 10 --
> > >  drivers/gpu/drm/i915/intel_ringbuffer.c|  4 +---
> > >  drivers/gpu/drm/i915/intel_ringbuffer.h|  1 -
> > >  8 files changed, 8 insertions(+), 31 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > > b/drivers/gpu/drm/i915/i915_drv.c
> > > index 3834bd758a2e..b4b43402cc0c 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -373,7 +373,7 @@ static int i915_getparam_ioctl(struct drm_device 
> > > *dev, void *data,
> > >   value = 2;
> > >   break;
> > >   case I915_PARAM_HAS_RESOURCE_STREAMER:
> > > - value = HAS_RESOURCE_STREAMER(dev_priv);
> > > + value = 0;
> > >   break;
> > >   case I915_PARAM_HAS_POOLED_EU:
> > >   value = HAS_POOLED_EU(dev_priv);
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 4fb937399440..0b22ca0b24a8 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -2612,8 +2612,6 @@ intel_info(const struct drm_i915_private *dev_priv)
> > >  #define USES_GUC_SUBMISSION(dev_priv)
> > > intel_uc_is_using_guc_submission()
> > >  #define USES_HUC(dev_priv)   intel_uc_is_using_huc()
> > >
> > > -#define HAS_RESOURCE_STREAMER(dev_priv) 
> > > ((dev_priv)->info.has_resource_streamer)
> > > -
> > >  #define HAS_POOLED_EU(dev_priv)  ((dev_priv)->info.has_pooled_eu)
> > >
> > >  #define INTEL_PCH_DEVICE_ID_MASK 0xff80
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> > > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > > index 1932bc227942..ca21a08b2be9 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > > @@ -2221,19 +2221,8 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> > >   if (!eb.engine)
> > >   return -EINVAL;
> > >
> > > - if (args->flags & I915_EXEC_RESOURCE_STREAMER) {
> > > - if (!HAS_RESOURCE_STREAMER(eb.i915)) {
> > > - DRM_DEBUG("RS is only allowed for Haswell and Gen8 
> > > - Gen10\n");
> > > - return -EINVAL;
> > > - }
> > > - if (eb.engine->id != RCS) {
> > > - DRM_DEBUG("RS is not available on %s\n",
> > > -  eb.engine->name);
> > > - return -EINVAL;
> > > - }
> > > -
> > > - eb.batch_flags |= I915_DISPATCH_RS;
> > > - }
> > > + if (args->flags & I915_EXEC_RESOURCE_STREAMER)
> > > + return -EINVAL;
> > >
> > >   if (args->flags & I915_EXEC_FENCE_IN) {
> > >   in_fence = sync_file_get_fence(lower_32_bits(args->rsvd2));
> > > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> > > b/drivers/gpu/drm/i915/i915_pci.c
> > > index 3a4bb017d676..7b570ba90d9f 100644
> > > --- a/drivers/gpu/drm/i915/i915_pci.c
> > > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > > @@ -360,7 +360,6 @@ static const struct intel_device_info 
> > > intel_valleyvie

[Intel-gfx] [PATCH 2/2] drm/i915/selftests: Exercise resetting in the middle of a wait-on-fence

[Chris Wilson]

On older HW, gen2/3, fence registers are used for detiling GPU commands
and as such changing those registers requires serialisation with the
requests on the GPU. Anything running on the GPU is subject to a hang,
and so we must be able to recover cleanly in the middle of a stuck wait
on a fence register.

We can simulate using the fence on the GPU simply by marking the fence
as active on the request for this vma, the interface being common to all
gen, thus broadening the test.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 .../gpu/drm/i915/selftests/intel_hangcheck.c  | 85 +--
 1 file changed, 77 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index b2d6d15f025a..db378226ac10 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -1018,8 +1018,41 @@ static int evict_vma(void *data)
return err;
 }
 
+static int evict_fence(void *data)
+{
+   struct evict_vma *arg = data;
+   struct drm_i915_private *i915 = arg->vma->vm->i915;
+   int err;
+
+   complete(&arg->completion);
+
+   mutex_lock(&i915->drm.struct_mutex);
+
+   /* Mark the fence register as dirty to force the mmio update. */
+   err = i915_gem_object_set_tiling(arg->vma->obj, I915_TILING_Y, 512);
+   if (err) {
+   pr_err("Invalid Y-tiling settings; err:%d\n", err);
+   goto out_unlock;
+   }
+
+   err = i915_vma_pin_fence(arg->vma);
+   if (err) {
+   pr_err("Unable to pin Y-tiled fence; err:%d\n", err);
+   goto out_unlock;
+   }
+
+   i915_vma_unpin_fence(arg->vma);
+
+out_unlock:
+   mutex_unlock(&i915->drm.struct_mutex);
+
+   return err;
+}
+
 static int __igt_reset_evict_vma(struct drm_i915_private *i915,
-struct i915_address_space *vm)
+struct i915_address_space *vm,
+int (*fn)(void *),
+unsigned int flags)
 {
struct drm_i915_gem_object *obj;
struct task_struct *tsk = NULL;
@@ -1040,12 +1073,20 @@ static int __igt_reset_evict_vma(struct 
drm_i915_private *i915,
if (err)
goto unlock;
 
-   obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
+   obj = i915_gem_object_create_internal(i915, SZ_1M);
if (IS_ERR(obj)) {
err = PTR_ERR(obj);
goto fini;
}
 
+   if (flags & EXEC_OBJECT_NEEDS_FENCE) {
+   err = i915_gem_object_set_tiling(obj, I915_TILING_X, 512);
+   if (err) {
+   pr_err("Invalid X-tiling settings; err:%d\n", err);
+   goto out_obj;
+   }
+   }
+
arg.vma = i915_vma_instance(obj, vm, NULL);
if (IS_ERR(arg.vma)) {
err = PTR_ERR(arg.vma);
@@ -1059,11 +1100,28 @@ static int __igt_reset_evict_vma(struct 
drm_i915_private *i915,
}
 
err = i915_vma_pin(arg.vma, 0, 0,
-  i915_vma_is_ggtt(arg.vma) ? PIN_GLOBAL : PIN_USER);
-   if (err)
+  i915_vma_is_ggtt(arg.vma) ?
+  PIN_GLOBAL | PIN_MAPPABLE :
+  PIN_USER);
+   if (err) {
+   i915_request_add(rq);
goto out_obj;
+   }
+
+   if (flags & EXEC_OBJECT_NEEDS_FENCE) {
+   err = i915_vma_pin_fence(arg.vma);
+   if (err) {
+   pr_err("Unable to pin X-tiled fence; err:%d\n", err);
+   i915_vma_unpin(arg.vma);
+   i915_request_add(rq);
+   goto out_obj;
+   }
+   }
 
-   err = i915_vma_move_to_active(arg.vma, rq, EXEC_OBJECT_WRITE);
+   err = i915_vma_move_to_active(arg.vma, rq, flags);
+
+   if (flags & EXEC_OBJECT_NEEDS_FENCE)
+   i915_vma_unpin_fence(arg.vma);
i915_vma_unpin(arg.vma);
 
i915_request_get(rq);
@@ -1086,7 +1144,7 @@ static int __igt_reset_evict_vma(struct drm_i915_private 
*i915,
 
init_completion(&arg.completion);
 
-   tsk = kthread_run(evict_vma, &arg, "igt/evict_vma");
+   tsk = kthread_run(fn, &arg, "igt/evict_vma");
if (IS_ERR(tsk)) {
err = PTR_ERR(tsk);
tsk = NULL;
@@ -1137,7 +1195,8 @@ static int igt_reset_evict_ggtt(void *arg)
 {
struct drm_i915_private *i915 = arg;
 
-   return __igt_reset_evict_vma(i915, &i915->ggtt.vm);
+   return __igt_reset_evict_vma(i915, &i915->ggtt.vm,
+evict_vma, EXEC_OBJECT_WRITE);
 }
 
 static int igt_reset_evict_ppgtt(void *arg)
@@ -1161,13 +1220,22 @@ static int igt_reset_evict_ppgtt(void *arg)
 
err = 0;
if (ctx->ppgtt) /* aliasing == global gtt locking, covered above */
- 

[Intel-gfx] [PATCH 1/2] drm/i915/selftests: Use a full emulation of a user ppgtt context

[Chris Wilson]

To test eviction from a ppgtt, we just want a ppgtt i.e. something other
than the Global GTT which is shared and used by the kernel for HW
features like fencing and scanout. However, we also need it to pass
!i915_is_ggtt() and the simplest way is to emulate a full user context
rather than the internal kernel context that is used for the GGTT.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index 65d66cdedd26..b2d6d15f025a 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -1144,19 +1144,27 @@ static int igt_reset_evict_ppgtt(void *arg)
 {
struct drm_i915_private *i915 = arg;
struct i915_gem_context *ctx;
+   struct drm_file *file;
int err;
 
+   file = mock_file(i915);
+   if (IS_ERR(file))
+   return PTR_ERR(file);
+
mutex_lock(&i915->drm.struct_mutex);
-   ctx = kernel_context(i915);
+   ctx = live_context(i915, file);
mutex_unlock(&i915->drm.struct_mutex);
-   if (IS_ERR(ctx))
-   return PTR_ERR(ctx);
+   if (IS_ERR(ctx)) {
+   err = PTR_ERR(ctx);
+   goto out;
+   }
 
err = 0;
if (ctx->ppgtt) /* aliasing == global gtt locking, covered above */
err = __igt_reset_evict_vma(i915, &ctx->ppgtt->vm);
 
-   kernel_context_close(ctx);
+out:
+   mock_file_free(i915, file);
return err;
 }
 
-- 
2.18.0

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

Re: [Intel-gfx] [PATCH 15/18] drm/i915: Add a new "remapped" gtt_view

[Chris Wilson]

Quoting Ville Syrjälä (2018-07-19 20:33:57)
> On Thu, Jul 19, 2018 at 07:59:33PM +0100, Chris Wilson wrote:
> > Quoting Ville Syrjala (2018-07-19 19:22:11)
> > > +static struct scatterlist *
> > > +remap_pages(const dma_addr_t *in, unsigned int offset,
> > > +   unsigned int width, unsigned int height,
> > > +   unsigned int stride,
> > > +   struct sg_table *st, struct scatterlist *sg)
> > > +{
> > > +   unsigned int column, row;
> > > +
> > > +   for (row = 0; row < height; row++) {
> > > +   for (column = 0; column < width; column++) {
> > > +   st->nents++;
> > > +   /* We don't need the pages, but need to initialize
> > > +* the entries so the sg list can be happily 
> > > traversed.
> > > +* The only thing we need are DMA addresses.
> > > +*/
> > > +   sg_set_page(sg, NULL, PAGE_SIZE, 0);
> > > +   sg_dma_address(sg) = in[offset + column];
> > > +   sg_dma_len(sg) = PAGE_SIZE;
> > > +   sg = sg_next(sg);
> > 
> > Ok. But should be I915_GTT_PAGE_SIZE?
> 
> I suppose. And now I wonder what would happen on gen2 with its
> 2KiB gtt pages. Probably nothing good.

Pffifle. We call it 4KiB. It's just about the semantics, and here we
should be splitting the dma addresses by GTT_PAGE_SIZE rather than
system page size.

> > > +struct intel_remapped_info {
> > > +   struct intel_remapped_plane_info {
> > > +   /* tiles */
> > > +   unsigned int width, height, stride, offset;
> > > +   } plane[2];
> > > +   unsigned int unused;
> > 
> > Tag it as mbz, since we do use it inside the compare. Hmm, I wonder if
> > it actually is better if it doesn't exist if it isn't used, then it
> > should be zero.. Hmm, not sure if that's defined at all, might have to
> > say memset and don't rely on {} zeroing?
> > 
> > Should work fine as a memcmp key for the rbtree.
> 
> This whole thing is a bit questionale the way I did it. When populating
> the gtt_view I just poke at view->rotated and rely on matching layout
> for view->remapped. To make it less magic maybe I should embed one
> inside the other?

Hmm. If it's intentionally the same layout, then we should just use the
same struct for both. remapped/remap_info is generic enough to cover
rotation as well.

> > > +} __packed;
> > > +
> > > +static inline void assert_intel_remapped_info_is_packed(void)
> > > +{
> > > +   BUILD_BUG_ON(sizeof(struct intel_remapped_info) != 
> > > 10*sizeof(unsigned int));
> > > +}
> > > +
> > >  struct intel_rotation_info {
> > > struct intel_rotation_plane_info {
> > > /* tiles */
> > > @@ -186,6 +199,7 @@ enum i915_ggtt_view_type {
> > > I915_GGTT_VIEW_NORMAL = 0,
> > > I915_GGTT_VIEW_ROTATED = sizeof(struct intel_rotation_info),
> > > I915_GGTT_VIEW_PARTIAL = sizeof(struct intel_partial_info),
> > > +   I915_GGTT_VIEW_REMAPPED = sizeof(struct intel_remapped_info),

Oh, forgot about that trick. Yeah, they do need to differ in structs.

Hmm, so I think keep the remap_plane_info and reuse that?

struct intel_remapped_info {
   struct intel_remapped_plane_info {
   /* tiles */
   unsigned int width, height, stride, offset;
   } plane[2];
   int unused_mbz; 
};


struct intel_rotation_info {
struct intel_remmaped_plane_info plane[2];
};

static inline void assert_intel_rotation_matches_remapped_info(void)
{
/* Check that rotation/remapped shares offsets for simplicity */
BUILD_BUG_ON(offsetof(struct intel_remapped_info, plane[0]) !=
 offsetof(struct intel_rotation_info, plane[0]));
BUILD_BUG_ON(offsetofend(struct intel_remapped_info, plane[1]) !=
 offsetofend(struct intel_rotation_info, plane[1]));
}
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 15/18] drm/i915: Add a new "remapped" gtt_view

[Ville Syrjälä]

On Thu, Jul 19, 2018 at 07:59:33PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2018-07-19 19:22:11)
> > +static struct scatterlist *
> > +remap_pages(const dma_addr_t *in, unsigned int offset,
> > +   unsigned int width, unsigned int height,
> > +   unsigned int stride,
> > +   struct sg_table *st, struct scatterlist *sg)
> > +{
> > +   unsigned int column, row;
> > +
> > +   for (row = 0; row < height; row++) {
> > +   for (column = 0; column < width; column++) {
> > +   st->nents++;
> > +   /* We don't need the pages, but need to initialize
> > +* the entries so the sg list can be happily 
> > traversed.
> > +* The only thing we need are DMA addresses.
> > +*/
> > +   sg_set_page(sg, NULL, PAGE_SIZE, 0);
> > +   sg_dma_address(sg) = in[offset + column];
> > +   sg_dma_len(sg) = PAGE_SIZE;
> > +   sg = sg_next(sg);
> 
> Ok. But should be I915_GTT_PAGE_SIZE?

I suppose. And now I wonder what would happen on gen2 with its
2KiB gtt pages. Probably nothing good.

> 
> And yes, following that argument looks like rotation should be converted.
> 
> > +   }
> > +   offset += stride;
> > +   }
> > +
> > +   return sg;
> > +}
> > +
> > +static noinline struct sg_table *
> > +intel_remap_pages(struct intel_remapped_info *rem_info,
> > + struct drm_i915_gem_object *obj)
> > +{
> > +   const unsigned long n_pages = obj->base.size / PAGE_SIZE;
> > +   unsigned int size = intel_remapped_info_size(rem_info);
> > +   struct sgt_iter sgt_iter;
> > +   dma_addr_t dma_addr;
> > +   unsigned long i;
> > +   dma_addr_t *page_addr_list;
> > +   struct sg_table *st;
> > +   struct scatterlist *sg;
> > +   int ret = -ENOMEM;
> > +
> > +   /* Allocate a temporary list of source pages for random access. */
> > +   page_addr_list = kvmalloc_array(n_pages,
> > +   sizeof(dma_addr_t),
> > +   GFP_KERNEL);
> > +   if (!page_addr_list)
> > +   return ERR_PTR(ret);
> > +
> > +   /* Allocate target SG list. */
> > +   st = kmalloc(sizeof(*st), GFP_KERNEL);
> > +   if (!st)
> > +   goto err_st_alloc;
> > +
> > +   ret = sg_alloc_table(st, size, GFP_KERNEL);
> > +   if (ret)
> > +   goto err_sg_alloc;
> > +
> > +   /* Populate source page list from the object. */
> > +   i = 0;
> > +   for_each_sgt_dma(dma_addr, sgt_iter, obj->mm.pages)
> > +   page_addr_list[i++] = dma_addr;
> 
> You could use the i915_gem_object_get_dma_address() for this. We
> definitely will reuse the index (as the one object will likely be
> remapped into each CRTC). (Avoids having a temporary vmalloc here.)
> 
> > +
> > +   GEM_BUG_ON(i != n_pages);
> > +   st->nents = 0;
> > +   sg = st->sgl;
> > +
> > +   for (i = 0 ; i < ARRAY_SIZE(rem_info->plane); i++) {
> > +   sg = remap_pages(page_addr_list, rem_info->plane[i].offset,
> > +rem_info->plane[i].width, 
> > rem_info->plane[i].height,
> > +rem_info->plane[i].stride, st, sg);
> > +   }
> 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
> > b/drivers/gpu/drm/i915/i915_gem_gtt.h
> > index 2a116a91420b..e15ac9f64c36 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> > @@ -160,6 +160,19 @@ typedef u64 gen8_ppgtt_pml4e_t;
> >  
> >  struct sg_table;
> >  
> > +struct intel_remapped_info {
> > +   struct intel_remapped_plane_info {
> > +   /* tiles */
> > +   unsigned int width, height, stride, offset;
> > +   } plane[2];
> > +   unsigned int unused;
> 
> Tag it as mbz, since we do use it inside the compare. Hmm, I wonder if
> it actually is better if it doesn't exist if it isn't used, then it
> should be zero.. Hmm, not sure if that's defined at all, might have to
> say memset and don't rely on {} zeroing?
> 
> Should work fine as a memcmp key for the rbtree.

This whole thing is a bit questionale the way I did it. When populating
the gtt_view I just poke at view->rotated and rely on matching layout
for view->remapped. To make it less magic maybe I should embed one
inside the other?

> 
> > +} __packed;
> > +
> > +static inline void assert_intel_remapped_info_is_packed(void)
> > +{
> > +   BUILD_BUG_ON(sizeof(struct intel_remapped_info) != 
> > 10*sizeof(unsigned int));
> > +}
> > +
> >  struct intel_rotation_info {
> > struct intel_rotation_plane_info {
> > /* tiles */
> > @@ -186,6 +199,7 @@ enum i915_ggtt_view_type {
> > I915_GGTT_VIEW_NORMAL = 0,
> > I915_GGTT_VIEW_ROTATED = sizeof(struct intel_rotation_inf

Re: [Intel-gfx] [PATCH 16/18] drm/i915: Overcome display engine stride limits via GTT remapping

[Ville Syrjälä]

On Thu, Jul 19, 2018 at 08:01:12PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2018-07-19 19:22:12)
> > From: Ville Syrjälä 
> > 
> > The display engine stride limits are getting in our way. On SKL+
> > we are limited to 8k pixels, which is easily exceeded with three
> > 4k displays. To overcome this limitation we can remap the pages
> > in the GTT to provide the display engine with a view of memory
> > with a smaller stride.
> > 
> > The code is mostly already there as We already play tricks with
> > the plane surface address and x/y offsets.
> > 
> > A few caveats apply:
> > * linear buffers need the fb stride to be page aligned, as
> >   otherwise the remapped lines wouldn't start at the same
> >   spot
> > * compressed buffers can't be remapped due to the new
> >   ccs hash mode causing the virtual address of the pages
> >   to affect the interpretation of the compressed data. IIRC
> >   the old hash was limited to the low 12 bits so if we were
> >   using that mode we could remap. As it stands we just refuse
> >   to remapp with compressed fbs.
> > * no remapping gen2/3 as we'd need a fence for the remapped
> >   vma, which we currently don't have
> 
> But... you just forbade us getting a fence, there's nothing that
> actually would stop the fence register assignment from working?

Hmm. I thought we still had some kind of fence==object relationship.
Or maybe I'm just thinking about the uapi. I should probably read the
actual code instead of relying on ancient/invalid knowledge :)

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: GTT remapping for display

[Patchwork]

== Series Details ==

Series: drm/i915: GTT remapping for display
URL   : https://patchwork.freedesktop.org/series/46886/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4515 -> Patchwork_9720 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/46886/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_9720:

  === IGT changes ===

 Warnings 

igt@drv_selftest@live_execlists:
  {fi-cfl-8109u}: SKIP -> PASS +1


== Known issues ==

  Here are the changes found in Patchwork_9720 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_hangcheck:
  fi-kbl-7560u:   PASS -> DMESG-FAIL (fdo#106560, fdo#106947)
  fi-skl-6600u:   PASS -> DMESG-FAIL (fdo#106560, fdo#107174)

igt@drv_selftest@live_workarounds:
  {fi-cfl-8109u}: PASS -> DMESG-FAIL (fdo#107292)

igt@gem_ringfill@basic-default:
  {fi-kbl-8809g}: PASS -> DMESG-WARN (fdo#107221)


 Possible fixes 

igt@drv_selftest@live_hangcheck:
  {fi-cfl-8109u}: DMESG-FAIL -> PASS

igt@gem_exec_suspend@basic-s4-devices:
  fi-kbl-7500u:   DMESG-WARN (fdo#107139, fdo#105128) -> PASS

igt@gem_render_tiled_blits@basic:
  {fi-kbl-8809g}: DMESG-WARN (fdo#107221) -> PASS


  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128
  fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
  fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
  fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139
  fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
  fdo#107221 https://bugs.freedesktop.org/show_bug.cgi?id=107221
  fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292


== Participating hosts (47 -> 42) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4515 -> Patchwork_9720

  CI_DRM_4515: 7d965fa499d11f7547066a827b3ae420f9e26f39 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4568: 86f7b724ef18986bc58d35558d22e1ed3f8df4f9 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9720: b6b0962ca4811bf575148132f299fd0b14bbf8f4 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

b6b0962ca481 drm/i915: Bump gen4+ fb size limits to 32kx32k
57b7b6f7429b drm/i915: Bump gen4+ fb stride limit to 256KiB
9ff0fb075794 drm/i915: Overcome display engine stride limits via GTT remapping
f0c079c521ab drm/i915: Add a new "remapped" gtt_view
ad9b29709a6c drm/i915: Extract intel_cursor_check_surface()
6d2816cc9e13 drm/i915: Move chv rotation checks to plane->check()
05adce059f5c drm/i915: Move display w/a #1175
eea47ec1a126 drm/i915: Move skl plane fb related checks into a better place
416335e1c500 drm/i915: Extract per-platform plane->check() functions
05b220464c98 drm/i915: Nuke plane->can_scale/min_downscale
efc25030f9e0 drm/i915: s/int plane/int color_plane/
2f03e86953a0 drm/i915: Store ggtt_view in plane_state
22a29833142d drm/i915: Store the final plane stride in plane_state
466e9b94ef6b drm/i915: Rename the plane_state->main/aux to 
plane_state->color_plane[]
1081f1cd3907 drm/i915: Use pipe A primary plane .max_stride() as the global 
stride limit
020d82fa9ed9 drm/i915: Add .max_stride() plane hook
c95e166cfd63 drm/i915: s/tile_offset/aligned_offset/
0655c1625b0a drm/i915: Fix glk/cnl display w/a #1175

== Logs ==

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

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915: kill resource streamer

[Lucas De Marchi]

On Thu, Jul 19, 2018 at 10:18 AM Rodrigo Vivi  wrote:
>
> On Thu, Jul 19, 2018 at 10:05:57AM -0700, Lucas De Marchi wrote:
> > After disabling resource streamer on ICL (due to it actually not
> > existing there), I got feedback that there have been some experimental
> > patches for mesa to use RS years ago, but nothing ever landed or shipped
> > because there was no performance improvement.
> >
> > This removes it from kernel keeping the uapi defines around for
> > compatibility.
> >
> > v2: - re-add the inadvertent removal of CTX_CTRL_INHIBIT_SYN_CTX_SWITCH
> > - don't bother trying to document removed params on uapi header:
> >   applications should know that from the query.
> >   (from Chris)
> >
> > v3: - disable CTX_CTRL_RS_CTX_ENABLE istead of removing it
> > - reword commit message after Daniele confirmed no performance
> >   regression on his machine
> > - reword commit message to make clear RS is being removed due to
> >   never been used
>
> thanks
>
> >
> > Signed-off-by: Lucas De Marchi 
> > Acked-by: Daniele Ceraolo Spurio 
>
> Reviewed-by: Rodrigo Vivi 
>
> (I will wait CI and then I will push)

there's also the i-g-t patch, otherwise there will be some tests failing.

Lucas De Marchi

>
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c|  2 +-
> >  drivers/gpu/drm/i915/i915_drv.h|  2 --
> >  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 15 ++-
> >  drivers/gpu/drm/i915/i915_pci.c|  4 
> >  drivers/gpu/drm/i915/intel_device_info.h   |  1 -
> >  drivers/gpu/drm/i915/intel_lrc.c   | 10 --
> >  drivers/gpu/drm/i915/intel_ringbuffer.c|  4 +---
> >  drivers/gpu/drm/i915/intel_ringbuffer.h|  1 -
> >  8 files changed, 8 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 3834bd758a2e..b4b43402cc0c 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -373,7 +373,7 @@ static int i915_getparam_ioctl(struct drm_device *dev, 
> > void *data,
> >   value = 2;
> >   break;
> >   case I915_PARAM_HAS_RESOURCE_STREAMER:
> > - value = HAS_RESOURCE_STREAMER(dev_priv);
> > + value = 0;
> >   break;
> >   case I915_PARAM_HAS_POOLED_EU:
> >   value = HAS_POOLED_EU(dev_priv);
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 4fb937399440..0b22ca0b24a8 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2612,8 +2612,6 @@ intel_info(const struct drm_i915_private *dev_priv)
> >  #define USES_GUC_SUBMISSION(dev_priv)
> > intel_uc_is_using_guc_submission()
> >  #define USES_HUC(dev_priv)   intel_uc_is_using_huc()
> >
> > -#define HAS_RESOURCE_STREAMER(dev_priv) 
> > ((dev_priv)->info.has_resource_streamer)
> > -
> >  #define HAS_POOLED_EU(dev_priv)  ((dev_priv)->info.has_pooled_eu)
> >
> >  #define INTEL_PCH_DEVICE_ID_MASK 0xff80
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index 1932bc227942..ca21a08b2be9 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -2221,19 +2221,8 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> >   if (!eb.engine)
> >   return -EINVAL;
> >
> > - if (args->flags & I915_EXEC_RESOURCE_STREAMER) {
> > - if (!HAS_RESOURCE_STREAMER(eb.i915)) {
> > - DRM_DEBUG("RS is only allowed for Haswell and Gen8 - 
> > Gen10\n");
> > - return -EINVAL;
> > - }
> > - if (eb.engine->id != RCS) {
> > - DRM_DEBUG("RS is not available on %s\n",
> > -  eb.engine->name);
> > - return -EINVAL;
> > - }
> > -
> > - eb.batch_flags |= I915_DISPATCH_RS;
> > - }
> > + if (args->flags & I915_EXEC_RESOURCE_STREAMER)
> > + return -EINVAL;
> >
> >   if (args->flags & I915_EXEC_FENCE_IN) {
> >   in_fence = sync_file_get_fence(lower_32_bits(args->rsvd2));
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> > b/drivers/gpu/drm/i915/i915_pci.c
> > index 3a4bb017d676..7b570ba90d9f 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -360,7 +360,6 @@ static const struct intel_device_info 
> > intel_valleyview_info = {
> >   .has_ddi = 1, \
> >   .has_fpga_dbg = 1, \
> >   .has_psr = 1, \
> > - .has_resource_streamer = 1, \
> >   .has_dp_mst = 1, \
> >   .has_rc6p = 0 /* RC6p removed-by HSW */, \
> >   .has_runtime_pm = 1
> > @@ -433,7 +432,6 @@ static const struct intel_device_info 
> > intel_cherryview_info = {
> >   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_R

Re: [Intel-gfx] [PATCH 16/18] drm/i915: Overcome display engine stride limits via GTT remapping

[Chris Wilson]

Quoting Ville Syrjala (2018-07-19 19:22:12)
> From: Ville Syrjälä 
> 
> The display engine stride limits are getting in our way. On SKL+
> we are limited to 8k pixels, which is easily exceeded with three
> 4k displays. To overcome this limitation we can remap the pages
> in the GTT to provide the display engine with a view of memory
> with a smaller stride.
> 
> The code is mostly already there as We already play tricks with
> the plane surface address and x/y offsets.
> 
> A few caveats apply:
> * linear buffers need the fb stride to be page aligned, as
>   otherwise the remapped lines wouldn't start at the same
>   spot
> * compressed buffers can't be remapped due to the new
>   ccs hash mode causing the virtual address of the pages
>   to affect the interpretation of the compressed data. IIRC
>   the old hash was limited to the low 12 bits so if we were
>   using that mode we could remap. As it stands we just refuse
>   to remapp with compressed fbs.
> * no remapping gen2/3 as we'd need a fence for the remapped
>   vma, which we currently don't have

But... you just forbade us getting a fence, there's nothing that
actually would stop the fence register assignment from working?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: GTT remapping for display

[Patchwork]

== Series Details ==

Series: drm/i915: GTT remapping for display
URL   : https://patchwork.freedesktop.org/series/46886/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915: Fix glk/cnl display w/a #1175
Okay!

Commit: drm/i915: s/tile_offset/aligned_offset/
Okay!

Commit: drm/i915: Add .max_stride() plane hook
+drivers/gpu/drm/i915/intel_sprite.c:243:24: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_sprite.c:245:24: warning: expression using 
sizeof(void)

Commit: drm/i915: Use pipe A primary plane .max_stride() as the global stride 
limit
-O:drivers/gpu/drm/i915/intel_display.c:14410:24: warning: expression using 
sizeof(void)

Commit: drm/i915: Rename the plane_state->main/aux to plane_state->color_plane[]
Okay!

Commit: drm/i915: Store the final plane stride in plane_state
Okay!

Commit: drm/i915: Store ggtt_view in plane_state
Okay!

Commit: drm/i915: s/int plane/int color_plane/
Okay!

Commit: drm/i915: Nuke plane->can_scale/min_downscale
Okay!

Commit: drm/i915: Extract per-platform plane->check() functions
Okay!

Commit: drm/i915: Move skl plane fb related checks into a better place
Okay!

Commit: drm/i915: Move display w/a #1175
Okay!

Commit: drm/i915: Move chv rotation checks to plane->check()
Okay!

Commit: drm/i915: Extract intel_cursor_check_surface()
Okay!

Commit: drm/i915: Add a new "remapped" gtt_view
+./include/linux/mm.h:572:13: error: not a function 

Commit: drm/i915: Overcome display engine stride limits via GTT remapping
Okay!

Commit: drm/i915: Bump gen4+ fb stride limit to 256KiB
Okay!

Commit: drm/i915: Bump gen4+ fb size limits to 32kx32k
Okay!

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

Re: [Intel-gfx] [PATCH 15/18] drm/i915: Add a new "remapped" gtt_view

[Chris Wilson]

Quoting Ville Syrjala (2018-07-19 19:22:11)
> +static struct scatterlist *
> +remap_pages(const dma_addr_t *in, unsigned int offset,
> +   unsigned int width, unsigned int height,
> +   unsigned int stride,
> +   struct sg_table *st, struct scatterlist *sg)
> +{
> +   unsigned int column, row;
> +
> +   for (row = 0; row < height; row++) {
> +   for (column = 0; column < width; column++) {
> +   st->nents++;
> +   /* We don't need the pages, but need to initialize
> +* the entries so the sg list can be happily 
> traversed.
> +* The only thing we need are DMA addresses.
> +*/
> +   sg_set_page(sg, NULL, PAGE_SIZE, 0);
> +   sg_dma_address(sg) = in[offset + column];
> +   sg_dma_len(sg) = PAGE_SIZE;
> +   sg = sg_next(sg);

Ok. But should be I915_GTT_PAGE_SIZE?

And yes, following that argument looks like rotation should be converted.

> +   }
> +   offset += stride;
> +   }
> +
> +   return sg;
> +}
> +
> +static noinline struct sg_table *
> +intel_remap_pages(struct intel_remapped_info *rem_info,
> + struct drm_i915_gem_object *obj)
> +{
> +   const unsigned long n_pages = obj->base.size / PAGE_SIZE;
> +   unsigned int size = intel_remapped_info_size(rem_info);
> +   struct sgt_iter sgt_iter;
> +   dma_addr_t dma_addr;
> +   unsigned long i;
> +   dma_addr_t *page_addr_list;
> +   struct sg_table *st;
> +   struct scatterlist *sg;
> +   int ret = -ENOMEM;
> +
> +   /* Allocate a temporary list of source pages for random access. */
> +   page_addr_list = kvmalloc_array(n_pages,
> +   sizeof(dma_addr_t),
> +   GFP_KERNEL);
> +   if (!page_addr_list)
> +   return ERR_PTR(ret);
> +
> +   /* Allocate target SG list. */
> +   st = kmalloc(sizeof(*st), GFP_KERNEL);
> +   if (!st)
> +   goto err_st_alloc;
> +
> +   ret = sg_alloc_table(st, size, GFP_KERNEL);
> +   if (ret)
> +   goto err_sg_alloc;
> +
> +   /* Populate source page list from the object. */
> +   i = 0;
> +   for_each_sgt_dma(dma_addr, sgt_iter, obj->mm.pages)
> +   page_addr_list[i++] = dma_addr;

You could use the i915_gem_object_get_dma_address() for this. We
definitely will reuse the index (as the one object will likely be
remapped into each CRTC). (Avoids having a temporary vmalloc here.)

> +
> +   GEM_BUG_ON(i != n_pages);
> +   st->nents = 0;
> +   sg = st->sgl;
> +
> +   for (i = 0 ; i < ARRAY_SIZE(rem_info->plane); i++) {
> +   sg = remap_pages(page_addr_list, rem_info->plane[i].offset,
> +rem_info->plane[i].width, 
> rem_info->plane[i].height,
> +rem_info->plane[i].stride, st, sg);
> +   }

> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
> b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index 2a116a91420b..e15ac9f64c36 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -160,6 +160,19 @@ typedef u64 gen8_ppgtt_pml4e_t;
>  
>  struct sg_table;
>  
> +struct intel_remapped_info {
> +   struct intel_remapped_plane_info {
> +   /* tiles */
> +   unsigned int width, height, stride, offset;
> +   } plane[2];
> +   unsigned int unused;

Tag it as mbz, since we do use it inside the compare. Hmm, I wonder if
it actually is better if it doesn't exist if it isn't used, then it
should be zero.. Hmm, not sure if that's defined at all, might have to
say memset and don't rely on {} zeroing?

Should work fine as a memcmp key for the rbtree.

> +} __packed;
> +
> +static inline void assert_intel_remapped_info_is_packed(void)
> +{
> +   BUILD_BUG_ON(sizeof(struct intel_remapped_info) != 10*sizeof(unsigned 
> int));
> +}
> +
>  struct intel_rotation_info {
> struct intel_rotation_plane_info {
> /* tiles */
> @@ -186,6 +199,7 @@ enum i915_ggtt_view_type {
> I915_GGTT_VIEW_NORMAL = 0,
> I915_GGTT_VIEW_ROTATED = sizeof(struct intel_rotation_info),
> I915_GGTT_VIEW_PARTIAL = sizeof(struct intel_partial_info),
> +   I915_GGTT_VIEW_REMAPPED = sizeof(struct intel_remapped_info),
>  };
>  
>  static inline void assert_i915_ggtt_view_type_is_unique(void)
> @@ -197,6 +211,7 @@ static inline void 
> assert_i915_ggtt_view_type_is_unique(void)
> case I915_GGTT_VIEW_NORMAL:
> case I915_GGTT_VIEW_PARTIAL:
> case I915_GGTT_VIEW_ROTATED:
> +   case I915_GGTT_VIEW_REMAPPED:
> /* gcc complains if these are identical cases */
> break;
> }
> @@ -208,6 +223,7 @@ struct i915_ggtt_view {
> /* Me

Re: [Intel-gfx] [alsa-devel] [PATCH v2 0/3] Make the audio component binding more generic

[Takashi Iwai]

On Thu, 19 Jul 2018 15:05:45 +0200,
Pierre-Louis Bossart wrote:
> 
> On 7/19/18 12:50 AM, Takashi Iwai wrote:
> > On Wed, 18 Jul 2018 22:54:35 +0200,
> > Pierre-Louis Bossart wrote:
> >>
> >>
> >>
> >> On 07/17/2018 04:26 AM, Takashi Iwai wrote:
> >>> Hi,
> >>>
> >>> this is a preliminiary patch set to convert the existing i915 /
> >>> HD-audio component binding to be applicable to other drivers like
> >>> radeon / amdgpu.  This patchset itself doesn't change the
> >>> functionality but only renames and split to a new drm_audio_component
> >>> stuff from i915_audio_component.
> >>>
> >>> The actual usage of the new API will follow once after this one gets
> >>> reviewed / accepted.  The whole patches (including this patchset) are
> >>> found in topic/hda-acomp branch of sound.git tree.
> >>>
> >>> BTW, since the whole stuff is about the audio binding, I suppose these
> >>> will go through sound git tree.  Let me know if anyone has concerns.
> >> No objections but a slight concern that this will conflict with the
> >> HDAudio+DSP patches that I was about to resubmit on top of your
> >> topic/hda-core-intel branch. the two series touch the same files so
> >> it'd be a miracle if there is no issue.
> >> How do you want to deal with this?
> >
> > Does it conflict severely?  If it's trivial, it can be resolved at
> > merge time, too.  The changes in my patchset are fairly trivial, so it
> > shouldn't be too hard.
> 
> I was able to make things work by taking your topic/hda-core-intel,
> merge it on Mark's for-next, then add my additional changes and these
> DRM changes. The last two can be done in any order. But I am getting
> some conflicts if I try to apply these DRM changes first, not sure why
> git is complaining though, the changes look trivial enough.
> So yes it looks possible to deal with the two series in parallel, will
> send my update later today.

OK, since my changes are relatively trivial to deal with, I merge the
changes to for-next branch now.

If your patches can be respinned, maybe it's easier to be rebased on
top of these merges.

Mark, could you merge topic/drm_audio_component branch into yours, if
Pierre's patchset won't go in immediately?  It's an immutable branch,
including already topic/hda-core-intel in itself.


thanks,

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: GTT remapping for display

[Patchwork]

== Series Details ==

Series: drm/i915: GTT remapping for display
URL   : https://patchwork.freedesktop.org/series/46886/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
0655c1625b0a drm/i915: Fix glk/cnl display w/a #1175
c95e166cfd63 drm/i915: s/tile_offset/aligned_offset/
020d82fa9ed9 drm/i915: Add .max_stride() plane hook
-:33: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#33: FILE: drivers/gpu/drm/i915/intel_display.c:3222:
+   return 16*1024;
 ^

-:35: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#35: FILE: drivers/gpu/drm/i915/intel_display.c:3224:
+   return 32*1024;
 ^

-:38: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#38: FILE: drivers/gpu/drm/i915/intel_display.c:3227:
+   return 8*1024;
^

-:40: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#40: FILE: drivers/gpu/drm/i915/intel_display.c:3229:
+   return 16*1024;
 ^

-:43: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#43: FILE: drivers/gpu/drm/i915/intel_display.c:3232:
+   return 4*1024;
^

-:45: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#45: FILE: drivers/gpu/drm/i915/intel_display.c:3234:
+   return 8*1024;
^

total: 0 errors, 0 warnings, 6 checks, 203 lines checked
1081f1cd3907 drm/i915: Use pipe A primary plane .max_stride() as the global 
stride limit
466e9b94ef6b drm/i915: Rename the plane_state->main/aux to 
plane_state->color_plane[]
22a29833142d drm/i915: Store the final plane stride in plane_state
2f03e86953a0 drm/i915: Store ggtt_view in plane_state
efc25030f9e0 drm/i915: s/int plane/int color_plane/
05b220464c98 drm/i915: Nuke plane->can_scale/min_downscale
416335e1c500 drm/i915: Extract per-platform plane->check() functions
eea47ec1a126 drm/i915: Move skl plane fb related checks into a better place
05adce059f5c drm/i915: Move display w/a #1175
6d2816cc9e13 drm/i915: Move chv rotation checks to plane->check()
ad9b29709a6c drm/i915: Extract intel_cursor_check_surface()
f0c079c521ab drm/i915: Add a new "remapped" gtt_view
-:165: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#165: FILE: drivers/gpu/drm/i915/i915_gem_gtt.h:173:
+   BUILD_BUG_ON(sizeof(struct intel_remapped_info) != 10*sizeof(unsigned 
int));
 ^

total: 0 errors, 0 warnings, 1 checks, 215 lines checked
9ff0fb075794 drm/i915: Overcome display engine stride limits via GTT remapping
57b7b6f7429b drm/i915: Bump gen4+ fb stride limit to 256KiB
-:38: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#38: FILE: drivers/gpu/drm/i915/intel_display.c:2519:
+   return 256*1024;
  ^

total: 0 errors, 0 warnings, 1 checks, 19 lines checked
b6b0962ca481 drm/i915: Bump gen4+ fb size limits to 32kx32k

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

Re: [Intel-gfx] [PATCH v3] drm/i915/dp: Give up link training clock recovery after 10 failed attempts

[Nathan Ciobanu]

On Thu, Jul 19, 2018 at 10:01:41AM -0700, Rodrigo Vivi wrote:
> On Tue, Jul 17, 2018 at 06:05:51PM -0700, Nathan Ciobanu wrote:
> > On Tue, Jul 17, 2018 at 03:21:17PM -0700, Dhinakaran Pandiyan wrote:
> > > On Mon, 2018-07-16 at 16:51 -0700, Marc Herbert wrote:
> > > > > 
> > > > > > 
> > > > > > I think the bug is with this infinite loop which is at the mercy
> > > > > > of an external device
> > > > > > and in my case I have this MST hub which appears to be DP 1.2
> > > > > > that triggers the
> > > > > > infinite loop case. We have to limit the number of iterations and
> > > > > > DP 1.4 spec happened to fix this issue. I'm a newbie in this area
> > > > > > but in this case
> > > > > > shouldn't we apply the same counter to all <= "DP 1.4" devices?
> > > > > ok, the infinite loop situation is really bad... but I don't
> > > > > believe
> > > > > we are going with the right fix...
> > > > > and a good indication is that your fix is for DP-1.4 while your bug
> > > > > is seeing on DP-1.2
> > > > I thought the only reason the infinite loop fix isn't in 1.2 is just
> > > > because there's
> > > > no 1.2.1 spec... (plus the naive assumption that buggy sinks don't
> > > > exist)
> > > > 
> > > Irrespective of whether the sink is DP1.2 or 1.4, if there are sinks
> > > out there that keep toggling between two values there should be an
> > > overall limit to how many times this loop gets executed. Even if this
> > > isn't right fix for the issue at hand, the loop has to break.
> > > 
> > > Then there's the question of what the limit should be. We could use the
> > > DP1.4 limit as a reference and apply it widely. But there's a problem
> > > here, we have 4 vswing values and 4 pre-emphasis values. If the sink
> > > progressively changes one variable at a time, we'll need at least 16
> > > iterations. Nathan's patch here will prematurely error out and that
> > > doesn't sound reasonable to impose on non DP1.4 sinks.
> > 
> > I think it would be a max of 13 iterations since one of the vswing
> > values will be max_vswing and the loop will terminate at that point
> > without trying the other 3 preemph values for that voltage, correct?
> 
> I was talking to DK yesterday and he suggested that we should go with
> a huge number for DP_1.2 and with the spec for DP_1.4. According to DK
> 80 was covering all combinations few times.
> 
> So you get your patch and create some max_cr_tries = dp_1.4 ? spec : 80;
> 
> or something like that.
> 
> I think I like that because infinite loop situation here is so bad
> and we should avoid even if it was something else that got really wrong.
I just sent v4 to do that. Thanks!
-Nathan
> 
> Thanks,
> Rodrigo.
> 
> > 
> > -Nathan
> > > 
> > > -DK
> > > 
> > > 
> > > > 
> > > > 
> > > > ___
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4 2/2] drm/i915/dp: Remove unneeded mav_vswing_tries variable

[Nathan Ciobanu]

max_vswing_tries variable was declared as an int but
used as a bool and not even needed because we can
just check the return of intel_dp_link_max_vswing_reached.

Cc: Dhinakaran Pandiyan 
Cc: Rodrigo Vivi 
Cc: Marc Herbert 
Signed-off-by: Nathan Ciobanu 
---
 drivers/gpu/drm/i915/intel_dp_link_training.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 05f209f6d73f..ddfdd5d05168 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -129,7 +129,7 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
 intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
 {
uint8_t voltage;
-   int voltage_tries, max_vswing_tries, cr_tries, max_cr_tries;
+   int voltage_tries, cr_tries, max_cr_tries;
uint8_t link_config[2];
uint8_t link_bw, rate_select;
 
@@ -181,7 +181,6 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
max_cr_tries = 80;
 
voltage_tries = 1;
-   max_vswing_tries = 0;
for (cr_tries = 0; cr_tries < max_cr_tries; ++cr_tries) {
uint8_t link_status[DP_LINK_STATUS_SIZE];
 
@@ -202,11 +201,6 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
return false;
}
 
-   if (max_vswing_tries == 1) {
-   DRM_DEBUG_KMS("Max Voltage Swing reached\n");
-   return false;
-   }
-
voltage = intel_dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK;
 
/* Update training set as requested by target */
@@ -222,8 +216,10 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
else
voltage_tries = 1;
 
-   if (intel_dp_link_max_vswing_reached(intel_dp))
-   ++max_vswing_tries;
+   if (intel_dp_link_max_vswing_reached(intel_dp)) {
+   DRM_DEBUG_KMS("Max Voltage Swing reached\n");
+   return false;
+   }
 
}
DRM_ERROR("Failed clock recovery %d times, giving up!\n", max_cr_tries);
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 1/2] drm/i915/dp: Limit link training clock recovery loop

[Nathan Ciobanu]

Limit the link training clock recovery loop to 10 attempts at
LANEx_CR_DONE per DP 1.4 spec section 3.5.1.2.2 and 80 attempts for
pre-DP 1.4 (4 voltage levels x 4 preemphasis levels x
x 5 identical voltages tries). Some faulty USB-C MST hubs can
cause us to get stuck in this loop indefinitely requesting something
like:

voltage swing: 0, pre-emphasis level: 2
voltage swing: 1, pre-emphasis level: 2
voltage swing: 0, pre-emphasis level: 3

over and over so max_vswing would never be reached,
drm_dp_clock_recovery_ok() would never return true and voltage_tries
would always get reset to 1. The driver sends those values to the hub
but the hub keeps requesting new values every time.

Changes in v2:
- updated commit message (DK, Manasi)
- defined DP_DP14_MAX_CR_TRIES (Marc)
- made the loop iterate for max 10 times (Rodrigo, Marc)

Changes in v3:
- changed error message to use DP_DP14_MAX_CR_TRIES

Changes in v4:
- Updated the title to reflect the change
- Updated the commit message
- Added 80 attempts for pre-DP 1.4 devices

Cc: Dhinakaran Pandiyan 
Cc: Rodrigo Vivi 
Cc: Marc Herbert 
Cc: Manasi Navare 
Signed-off-by: Nathan Ciobanu 
---
 drivers/gpu/drm/i915/intel_dp_link_training.c | 16 ++--
 include/drm/drm_dp_helper.h   |  1 +
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 4da6e33c7fa1..05f209f6d73f 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -129,7 +129,7 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
 intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
 {
uint8_t voltage;
-   int voltage_tries, max_vswing_tries;
+   int voltage_tries, max_vswing_tries, cr_tries, max_cr_tries;
uint8_t link_config[2];
uint8_t link_bw, rate_select;
 
@@ -170,9 +170,19 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
return false;
}
 
+   /* DP 1.4 spec clock recovery retries defined but
+* for devices pre-DP 1.4 we set the retry limit
+* to 4 (voltage levels) x 4 (preemphasis levels) x
+* x 5 (same voltage retries) = 80 (max iterations)
+*/
+   if (intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
+   max_cr_tries = DP_DP14_MAX_CR_TRIES;
+   else
+   max_cr_tries = 80;
+
voltage_tries = 1;
max_vswing_tries = 0;
-   for (;;) {
+   for (cr_tries = 0; cr_tries < max_cr_tries; ++cr_tries) {
uint8_t link_status[DP_LINK_STATUS_SIZE];
 
drm_dp_link_train_clock_recovery_delay(intel_dp->dpcd);
@@ -216,6 +226,8 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
++max_vswing_tries;
 
}
+   DRM_ERROR("Failed clock recovery %d times, giving up!\n", max_cr_tries);
+   return false;
 }
 
 /*
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 05cc31b5db16..2c9cee8731ce 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -820,6 +820,7 @@
 
 #define DP_DP13_DPCD_REV0x2200
 #define DP_DP13_MAX_LINK_RATE   0x2201
+#define DP_DP14_MAX_CR_TRIES10
 
 #define DP_DPRX_FEATURE_ENUMERATION_LIST0x2210  /* DP 1.3 */
 # define DP_GTC_CAP(1 << 0)  /* DP 1.3 */
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH v5 01/13] drm/i915/icl: Configure lane sequencing of combo phy transmitter

[Chauhan, Madhav]

> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Thursday, July 19, 2018 9:42 PM
> To: Chauhan, Madhav 
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani ;
> Zanoni, Paulo R ; Vivi, Rodrigo
> 
> Subject: Re: [Intel-gfx] [PATCH v5 01/13] drm/i915/icl: Configure lane
> sequencing of combo phy transmitter
> 
> On Tue, Jul 10, 2018 at 03:10:02PM +0530, Madhav Chauhan wrote:
> > This patch set the loadgen select and latency optimization for aux and
> > transmit lanes of combo phy transmitters. It will be used for MIPI DSI
> > HS operations.

Thanks for reviewing DSI patches.

> >
> > v2: Rebase
> >
> > Signed-off-by: Madhav Chauhan 
> > ---
> >  drivers/gpu/drm/i915/icl_dsi.c | 38
> > ++
> >  1 file changed, 38 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/icl_dsi.c
> > b/drivers/gpu/drm/i915/icl_dsi.c index 13830e4..a571339 100644
> > --- a/drivers/gpu/drm/i915/icl_dsi.c
> > +++ b/drivers/gpu/drm/i915/icl_dsi.c
> > @@ -105,10 +105,48 @@ static void gen11_dsi_power_up_lanes(struct
> intel_encoder *encoder)
> > }
> >  }
> >
> > +static void gen11_dsi_config_phy_lanes_sequence(struct intel_encoder
> > +*encoder) {
> > +   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > +   struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
> > +   enum port port;
> > +   u32 tmp;
> > +   int lane;
> 
> tmp/lane could be moved to into the loops.
> 
> Same in other patches.

Agree, make sense.

> 
> > +
> > +   /* Step 4b(i) set loadgen select for transmit and aux lanes */
> > +   for_each_dsi_port(port, intel_dsi->ports) {
> > +   tmp = I915_READ(ICL_PORT_TX_DW4_AUX(port));
> > +   tmp &= ~LOADGEN_SELECT;
> > +   I915_WRITE(ICL_PORT_TX_DW4_AUX(port), tmp);
> > +   for (lane = 0; lane <= 3; lane++) {
> > +   tmp = I915_READ(ICL_PORT_TX_DW4_LN(port,
> lane));
> > +   tmp &= ~LOADGEN_SELECT;
> > +   if (lane != 2)
> > +   tmp |= LOADGEN_SELECT;
> > +   I915_WRITE(ICL_PORT_TX_DW4_LN(port, lane),
> tmp);
> > +   }
> > +   }
> > +
> > +   /* Step 4b(ii) set latency optimization for transmit and aux lanes */
> > +   for_each_dsi_port(port, intel_dsi->ports) {
> > +   tmp = I915_READ(ICL_PORT_TX_DW2_AUX(port));
> > +   tmp &= ~FRC_LATENCY_OPTIM_MASK;
> > +   tmp |= FRC_LATENCY_OPTIM_VAL(0x5);
> > +   I915_WRITE(ICL_PORT_TX_DW2_AUX(port), tmp);
> > +   tmp = I915_READ(ICL_PORT_TX_DW2_LN0(port));
> > +   tmp &= ~FRC_LATENCY_OPTIM_MASK;
> > +   tmp |= FRC_LATENCY_OPTIM_VAL(0x5);
> > +   I915_WRITE(ICL_PORT_TX_DW2_GRP(port), tmp);
> > +   }
> 
> An empty line here and there would make this a bit more legible.
> 
> Same in other patches.

Ok.  Thought this will be additional line, multiple
Places in code use this :)

Regards,
Madhav

> 
> > +}
> > +
> >  static void gen11_dsi_enable_port_and_phy(struct intel_encoder
> > *encoder)  {
> > /* step 4a: power up all lanes of the DDI used by DSI */
> > gen11_dsi_power_up_lanes(encoder);
> > +
> > +   /* step 4b: configure lane sequencing of the Combo-PHY transmitters
> */
> > +   gen11_dsi_config_phy_lanes_sequence(encoder);
> >  }
> >
> >  static void __attribute__((unused))
> > --
> > 2.7.4
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/mst: Continue state updates even if AUX writes fail.

[Dhinakaran Pandiyan]

On Wed, 2018-07-18 at 22:43 -0700, Rodrigo Vivi wrote:
> On Wed, Jul 18, 2018 at 10:19:43AM -0700, Dhinakaran Pandiyan wrote:
> > 
> > We are too late in the enabling sequence to back out cleanly, not
> > updating
> > state tracking variables, like intel_dp->active_mst_links in this
> > instance, results in incorrect behaviour further along.
> I agree with you, although I'm not fully convinced that we need to
> call the
> update payload if vcpi allocation failed...

But there is more payload update code in intel_mst_enable_dp(), that
would get executed regardless of this diff below. We'll have to rewrite
pre_enable, enable, disable and post_disable if the idea is avoid sink
transactions after the first failure. It does make sense to do all of
that as it avoids printing error messages in dmesg when we very well
know the branch device is disconnected, but this should be a separate
change. My idea was to bring pre_enable/enable in line with
disable/post_disable.


> 
> so imho this entire function should be reworked to be like this:
> 
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -217,7 +217,6 @@ static void intel_mst_pre_enable_dp(struct
> intel_encoder *encoder,
> enum port port = intel_dig_port->base.port;
> struct intel_connector *connector =
> to_intel_connector(conn_state->connector);
> -   int ret;
> uint32_t temp;
>  
> /* MST encoders are bound to a crtc, not to a connector,
> @@ -233,25 +232,15 @@ static void intel_mst_pre_enable_dp(struct
> intel_encoder *encoder,
>  
> drm_dp_send_power_updown_phy(&intel_dp->mst_mgr, connector-
> >port, true);
>  
> -   if (intel_dp->active_mst_links == 0)
> +   if (intel_dp->active_mst_links++ == 0)
> intel_dig_port->base.pre_enable(&intel_dig_port-
> >base,
> pipe_config, NULL);
>  
> -   ret = drm_dp_mst_allocate_vcpi(&intel_dp->mst_mgr,
> -  connector->port,
> -  pipe_config->pbn,
> -  pipe_config->dp_m_n.tu);
> -   if (ret == false) {
> +   if (drm_dp_mst_allocate_vcpi(&intel_dp->mst_mgr, connector-
> >port,
> +pipe_config->pbn, pipe_config-
> >dp_m_n.tu))
> +   drm_dp_update_payload_part1(&intel_dp->mst_mgr);
> +   else
> DRM_ERROR("failed to allocate vcpi\n");
> -   return;
> -   }
> -
> -
> -   intel_dp->active_mst_links++;
> -   temp = I915_READ(DP_TP_STATUS(port));
> -   I915_WRITE(DP_TP_STATUS(port), temp);
> -
> -   ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
> 
> 
> probably with
> -   temp = I915_READ(DP_TP_STATUS(port));
> -   I915_WRITE(DP_TP_STATUS(port), temp);
> 
> in a separated patch. No idea why we read this staus reg and write
> back.
It is clearing the ACT status bit by writing a 1. Bspec has this
under DP_TP_STATUS:24

-DK

> I didn't see on spec any indication that this cleans it or that we
> need that
> for cleaning or anything else.
> 
> > 
> > 
> > v2: Fixed int v/s bool comparison
> > 
> > Cc: Ville Syrjälä 
> > Cc: Rodrigo Vivi 
> > Cc: Nathan Ciobanu 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_mst.c | 5 +
> >  1 file changed, 1 insertion(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index 7e3e01607643..110e7ff22ef7 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -241,11 +241,8 @@ static void intel_mst_pre_enable_dp(struct
> > intel_encoder *encoder,
> >        connector->port,
> >        pipe_config->pbn,
> >        pipe_config->dp_m_n.tu);
> > -   if (ret == false) {
> > +   if (!ret)
> >     DRM_ERROR("failed to allocate vcpi\n");
> > -   return;
> > -   }
> > -
> >  
> >     intel_dp->active_mst_links++;
> >     temp = I915_READ(DP_TP_STATUS(port));
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 12/18] drm/i915: Move display w/a #1175

[Ville Syrjala]

From: Ville Syrjälä 

Move the display w/a #1175 to a better place. That place
being the new skl+ specific plane->check() hook. This leaves
the skl_check_plane_surface() stuff to deal with the gtt offset
and src coordinate stuff as originally envisioned.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 36 +---
 drivers/gpu/drm/i915/intel_drv.h |  3 +--
 drivers/gpu/drm/i915/intel_sprite.c  | 36 +++-
 3 files changed, 41 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 2381b762d109..dbcc9a23eefa 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2986,20 +2986,14 @@ static bool skl_check_main_ccs_coordinates(struct 
intel_plane_state *plane_state
return true;
 }
 
-static int skl_check_main_surface(const struct intel_crtc_state *crtc_state,
- struct intel_plane_state *plane_state)
+static int skl_check_main_surface(struct intel_plane_state *plane_state)
 {
-   struct drm_i915_private *dev_priv =
-   to_i915(plane_state->base.plane->dev);
const struct drm_framebuffer *fb = plane_state->base.fb;
unsigned int rotation = plane_state->base.rotation;
int x = plane_state->base.src.x1 >> 16;
int y = plane_state->base.src.y1 >> 16;
int w = drm_rect_width(&plane_state->base.src) >> 16;
int h = drm_rect_height(&plane_state->base.src) >> 16;
-   int dst_x = plane_state->base.dst.x1;
-   int dst_w = drm_rect_width(&plane_state->base.dst);
-   int pipe_src_w = crtc_state->pipe_src_w;
int max_width = skl_max_plane_width(fb, 0, rotation);
int max_height = 4096;
u32 alignment, offset, aux_offset = plane_state->color_plane[1].offset;
@@ -3010,24 +3004,6 @@ static int skl_check_main_surface(const struct 
intel_crtc_state *crtc_state,
return -EINVAL;
}
 
-   /*
-* Display WA #1175: cnl,glk
-* Planes other than the cursor may cause FIFO underflow and display
-* corruption if starting less than 4 pixels from the right edge of
-* the screen.
-* Besides the above WA fix the similar problem, where planes other
-* than the cursor ending less than 4 pixels from the left edge of the
-* screen may cause FIFO underflow and display corruption.
-*/
-   if ((IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) &&
-   (dst_x + dst_w < 4 || dst_x > pipe_src_w - 4)) {
-   DRM_DEBUG_KMS("requested plane X %s position %d invalid (valid 
range %d-%d)\n",
- dst_x + dst_w < 4 ? "end" : "start",
- dst_x + dst_w < 4 ? dst_x + dst_w : dst_x,
- 4, pipe_src_w - 4);
-   return -ERANGE;
-   }
-
intel_add_fb_offsets(&x, &y, plane_state, 0);
offset = intel_plane_compute_aligned_offset(&x, &y, plane_state, 0);
alignment = intel_surf_alignment(fb, 0);
@@ -3089,8 +3065,7 @@ static int skl_check_main_surface(const struct 
intel_crtc_state *crtc_state,
 }
 
 static int
-skl_check_nv12_surface(const struct intel_crtc_state *crtc_state,
-  struct intel_plane_state *plane_state)
+skl_check_nv12_surface(struct intel_plane_state *plane_state)
 {
/* Display WA #1106 */
if (plane_state->base.rotation !=
@@ -3161,8 +3136,7 @@ static int skl_check_ccs_aux_surface(struct 
intel_plane_state *plane_state)
return 0;
 }
 
-int skl_check_plane_surface(const struct intel_crtc_state *crtc_state,
-   struct intel_plane_state *plane_state)
+int skl_check_plane_surface(struct intel_plane_state *plane_state)
 {
const struct drm_framebuffer *fb = plane_state->base.fb;
unsigned int rotation = plane_state->base.rotation;
@@ -3186,7 +3160,7 @@ int skl_check_plane_surface(const struct intel_crtc_state 
*crtc_state,
 * the main surface setup depends on it.
 */
if (fb->format->format == DRM_FORMAT_NV12) {
-   ret = skl_check_nv12_surface(crtc_state, plane_state);
+   ret = skl_check_nv12_surface(plane_state);
if (ret)
return ret;
ret = skl_check_nv12_aux_surface(plane_state);
@@ -3203,7 +3177,7 @@ int skl_check_plane_surface(const struct intel_crtc_state 
*crtc_state,
plane_state->color_plane[1].y = 0;
}
 
-   ret = skl_check_main_surface(crtc_state, plane_state);
+   ret = skl_check_main_surface(plane_state);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 6d57c6a508d4..55f3537ba8f8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1651,8 +1651,7 @@ u32 skl_plane_

[Intel-gfx] [PATCH 09/18] drm/i915: Nuke plane->can_scale/min_downscale

[Ville Syrjala]

From: Ville Syrjälä 

We can easily calculate the plane can_scale/min_downscale on demand.
And later on we'll probably want to start calculating these dynamically
based on the cdclk just as skl already does.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c |  8 +---
 drivers/gpu/drm/i915/intel_drv.h |  2 --
 drivers/gpu/drm/i915/intel_sprite.c  | 38 
 3 files changed, 13 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index bc2a712311ba..fdc5bedc5135 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13708,12 +13708,8 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
 
primary->base.state = &state->base;
 
-   primary->can_scale = false;
-   primary->max_downscale = 1;
-   if (INTEL_GEN(dev_priv) >= 9) {
-   primary->can_scale = true;
+   if (INTEL_GEN(dev_priv) >= 9)
state->scaler_id = -1;
-   }
primary->pipe = pipe;
/*
 * On gen2/3 only plane A can do FBC, but the panel fitter and LVDS
@@ -13881,8 +13877,6 @@ intel_cursor_plane_create(struct drm_i915_private 
*dev_priv,
 
cursor->base.state = &state->base;
 
-   cursor->can_scale = false;
-   cursor->max_downscale = 1;
cursor->pipe = pipe;
cursor->i9xx_plane = (enum i9xx_plane_id) pipe;
cursor->id = PLANE_CURSOR;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cc381f680338..c6c782e14897 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -950,10 +950,8 @@ struct intel_plane {
enum i9xx_plane_id i9xx_plane;
enum plane_id id;
enum pipe pipe;
-   bool can_scale;
bool has_fbc;
bool has_ccs;
-   int max_downscale;
uint32_t frontbuffer_bit;
 
struct {
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index a07d951afbf9..0d3931b8a981 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -765,7 +765,7 @@ ivb_update_plane(struct intel_plane *plane,
I915_WRITE_FW(SPRLINOFF(pipe), linear_offset);
 
I915_WRITE_FW(SPRSIZE(pipe), (crtc_h << 16) | crtc_w);
-   if (plane->can_scale)
+   if (IS_IVYBRIDGE(dev_priv))
I915_WRITE_FW(SPRSCALE(pipe), sprscale);
I915_WRITE_FW(SPRCTL(pipe), sprctl);
I915_WRITE_FW(SPRSURF(pipe),
@@ -786,7 +786,7 @@ ivb_disable_plane(struct intel_plane *plane, struct 
intel_crtc *crtc)
 
I915_WRITE_FW(SPRCTL(pipe), 0);
/* Can't leave the scaler enabled... */
-   if (plane->can_scale)
+   if (IS_IVYBRIDGE(dev_priv))
I915_WRITE_FW(SPRSCALE(pipe), 0);
 
I915_WRITE_FW(SPRSURF(pipe), 0);
@@ -991,7 +991,6 @@ intel_check_sprite_plane(struct intel_plane *plane,
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_framebuffer *fb = state->base.fb;
int max_scale, min_scale;
-   bool can_scale;
int ret;
uint32_t pixel_format = 0;
 
@@ -1014,25 +1013,29 @@ intel_check_sprite_plane(struct intel_plane *plane,
return -EINVAL;
}
 
-   /* setup can_scale, min_scale, max_scale */
if (INTEL_GEN(dev_priv) >= 9) {
if (state->base.fb)
pixel_format = state->base.fb->format->format;
/* use scaler when colorkey is not required */
if (!state->ckey.flags) {
-   can_scale = 1;
min_scale = 1;
max_scale =
skl_max_scale(crtc, crtc_state, pixel_format);
} else {
-   can_scale = 0;
min_scale = DRM_PLANE_HELPER_NO_SCALING;
max_scale = DRM_PLANE_HELPER_NO_SCALING;
}
} else {
-   can_scale = plane->can_scale;
-   max_scale = plane->max_downscale << 16;
-   min_scale = plane->can_scale ? 1 : (1 << 16);
+   if (INTEL_GEN(dev_priv) < 7) {
+   min_scale = 1;
+   max_scale = 16 << 16;
+   } else if (IS_IVYBRIDGE(dev_priv)) {
+   min_scale = 1;
+   max_scale = 2 << 16;
+   } else {
+   min_scale = DRM_PLANE_HELPER_NO_SCALING;
+   max_scale = DRM_PLANE_HELPER_NO_SCALING;
+   }
}
 
ret = drm_atomic_helper_check_plane_state(&state->base,
@@ -1078,8 +1081,6 @@ intel_check_sprite_plane(struct intel_plane *plane,
unsigned int width_bytes;
int cpp = fb->format->cpp[0];
 
-   WARN_ON

[Intel-gfx] [PATCH 02/18] drm/i915: s/tile_offset/aligned_offset/

[Ville Syrjala]

From: Ville Syrjälä 

Rename some of the tile_offset() functions to aligned_offset() since
they operate on both linear and tiled functions. And we'll include
_plane_ in the name of all the variants that take a plane state.
Should make it more clear which function to use where.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 123 ++-
 drivers/gpu/drm/i915/intel_drv.h |   2 -
 2 files changed, 63 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8efff0c56920..5f8304a11482 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2229,13 +2229,13 @@ void intel_add_fb_offsets(int *x, int *y,
}
 }
 
-static u32 __intel_adjust_tile_offset(int *x, int *y,
- unsigned int tile_width,
- unsigned int tile_height,
- unsigned int tile_size,
- unsigned int pitch_tiles,
- u32 old_offset,
- u32 new_offset)
+static u32 intel_adjust_tile_offset(int *x, int *y,
+   unsigned int tile_width,
+   unsigned int tile_height,
+   unsigned int tile_size,
+   unsigned int pitch_tiles,
+   u32 old_offset,
+   u32 new_offset)
 {
unsigned int pitch_pixels = pitch_tiles * tile_width;
unsigned int tiles;
@@ -2256,12 +2256,12 @@ static u32 __intel_adjust_tile_offset(int *x, int *y,
return new_offset;
 }
 
-static u32 _intel_adjust_tile_offset(int *x, int *y,
-const struct drm_framebuffer *fb, int 
plane,
-unsigned int rotation,
-u32 old_offset, u32 new_offset)
+static u32 intel_adjust_aligned_offset(int *x, int *y,
+  const struct drm_framebuffer *fb, int 
plane,
+  unsigned int rotation,
+  u32 old_offset, u32 new_offset)
 {
-   const struct drm_i915_private *dev_priv = to_i915(fb->dev);
+   struct drm_i915_private *dev_priv = to_i915(fb->dev);
unsigned int cpp = fb->format->cpp[plane];
unsigned int pitch = intel_fb_pitch(fb, plane, rotation);
 
@@ -2281,9 +2281,9 @@ static u32 _intel_adjust_tile_offset(int *x, int *y,
pitch_tiles = pitch / (tile_width * cpp);
}
 
-   __intel_adjust_tile_offset(x, y, tile_width, tile_height,
-  tile_size, pitch_tiles,
-  old_offset, new_offset);
+   intel_adjust_tile_offset(x, y, tile_width, tile_height,
+tile_size, pitch_tiles,
+old_offset, new_offset);
} else {
old_offset += *y * pitch + *x * cpp;
 
@@ -2298,17 +2298,18 @@ static u32 _intel_adjust_tile_offset(int *x, int *y,
  * Adjust the tile offset by moving the difference into
  * the x/y offsets.
  */
-static u32 intel_adjust_tile_offset(int *x, int *y,
-   const struct intel_plane_state *state, int 
plane,
-   u32 old_offset, u32 new_offset)
+static u32 intel_plane_adjust_aligned_offset(int *x, int *y,
+const struct intel_plane_state 
*state,
+int plane,
+u32 old_offset, u32 new_offset)
 {
-   return _intel_adjust_tile_offset(x, y, state->base.fb, plane,
-state->base.rotation,
-old_offset, new_offset);
+   return intel_adjust_aligned_offset(x, y, state->base.fb, plane,
+  state->base.rotation,
+  old_offset, new_offset);
 }
 
 /*
- * Computes the linear offset to the base tile and adjusts
+ * Computes the aligned offset to the base tile and adjusts
  * x, y. bytes per pixel is assumed to be a power-of-two.
  *
  * In the 90/270 rotated case, x and y are assumed
@@ -2321,12 +2322,12 @@ static u32 intel_adjust_tile_offset(int *x, int *y,
  * used. This is why the user has to pass in the pitch since it
  * is specified in the rotated orientation.
  */
-static u32 _intel_compute_tile_offset(const struct drm_i915_private *dev_priv,
- int *x, int *y,
- const struct drm_framebuffer *fb, int 
plane,
- unsig

[Intel-gfx] [PATCH 13/18] drm/i915: Move chv rotation checks to plane->check()

[Ville Syrjala]

From: Ville Syrjälä 

Move the chv rotation vs. reflections checks to the plane->check() hook,
away from the (now) platform agnostic
intel_plane_atomic_check_with_state().

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c |  9 -
 drivers/gpu/drm/i915/intel_display.c  |  4 
 drivers/gpu/drm/i915/intel_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_sprite.c   | 21 +
 4 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 7c0873060934..aabebe0d2e9b 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -113,7 +113,6 @@ int intel_plane_atomic_check_with_state(const struct 
intel_crtc_state *old_crtc_
struct intel_plane_state *intel_state)
 {
struct drm_plane *plane = intel_state->base.plane;
-   struct drm_i915_private *dev_priv = to_i915(plane->dev);
struct drm_plane_state *state = &intel_state->base;
struct intel_plane *intel_plane = to_intel_plane(plane);
int ret;
@@ -121,14 +120,6 @@ int intel_plane_atomic_check_with_state(const struct 
intel_crtc_state *old_crtc_
if (!intel_state->base.crtc && !old_plane_state->base.crtc)
return 0;
 
-   /* CHV ignores the mirror bit when the rotate bit is set :( */
-   if (IS_CHERRYVIEW(dev_priv) &&
-   state->rotation & DRM_MODE_ROTATE_180 &&
-   state->rotation & DRM_MODE_REFLECT_X) {
-   DRM_DEBUG_KMS("Cannot rotate and reflect at the same time\n");
-   return -EINVAL;
-   }
-
intel_state->base.visible = false;
ret = intel_plane->check_plane(crtc_state, intel_state);
if (ret)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index dbcc9a23eefa..b0e39dcf2fb8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3318,6 +3318,10 @@ i9xx_plane_check(struct intel_crtc_state *crtc_state,
 {
int ret;
 
+   ret = chv_plane_check_rotation(plane_state);
+   if (ret)
+   return ret;
+
ret = drm_atomic_helper_check_plane_state(&plane_state->base,
  &crtc_state->base,
  DRM_PLANE_HELPER_NO_SCALING,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 55f3537ba8f8..91b7fb6a07e1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2113,6 +2113,7 @@ unsigned int skl_plane_max_stride(struct intel_plane 
*plane,
 int skl_plane_check(struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state);
 int intel_plane_check_src_coordinates(struct intel_plane_state *plane_state);
+int chv_plane_check_rotation(const struct intel_plane_state *plane_state);
 
 /* 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 f43884f76212..93aa355f00e3 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1126,12 +1126,33 @@ g4x_sprite_check(struct intel_crtc_state *crtc_state,
return 0;
 }
 
+int chv_plane_check_rotation(const struct intel_plane_state *plane_state)
+{
+   struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
+   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+   unsigned int rotation = plane_state->base.rotation;
+
+   /* CHV ignores the mirror bit when the rotate bit is set :( */
+   if (IS_CHERRYVIEW(dev_priv) &&
+   rotation & DRM_MODE_ROTATE_180 &&
+   rotation & DRM_MODE_REFLECT_X) {
+   DRM_DEBUG_KMS("Cannot rotate and reflect at the same time\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 static int
 vlv_sprite_check(struct intel_crtc_state *crtc_state,
 struct intel_plane_state *plane_state)
 {
int ret;
 
+   ret = chv_plane_check_rotation(plane_state);
+   if (ret)
+   return ret;
+
ret = drm_atomic_helper_check_plane_state(&plane_state->base,
  &crtc_state->base,
  DRM_PLANE_HELPER_NO_SCALING,
-- 
2.16.4

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

[Intel-gfx] [PATCH 17/18] drm/i915: Bump gen4+ fb stride limit to 256KiB

[Ville Syrjala]

From: Ville Syrjälä 

With gtt remapping plugged in we can simply raise the stride
limit on gen4+. Let's just arbitraily pick 256 KiB as the limit.

No remapping CCS because the virtual address of each page actually
matters due to the new hash mode
(WaCompressedResourceDisplayNewHashMode:skl,kbl etc.), and no remapping
on gen2/3 due to lack of fence on the remapped vma.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8fb78214b4be..fa199f469e81 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2505,6 +2505,19 @@ static
 u32 intel_fb_max_stride(struct drm_i915_private *dev_priv,
u32 pixel_format, u64 modifier)
 {
+   /*
+* Arbitrary limit for gen4+. We can deal with any page
+* aligned stride via GTT remapping. Gen2/3 need a fence
+* for tiled scanout which the remapped vma won't have,
+* so we don't allow remapping on those platforms.
+*
+* Also the new hash mode we use for CCS isn't compatible
+* with remapping as the virtual address of the pages
+* affects the compressed data.
+*/
+   if (INTEL_GEN(dev_priv) >= 4 && !intel_modifier_has_ccs(modifier))
+   return 256*1024;
+
return intel_plane_fb_max_stride(dev_priv, pixel_format, modifier);
 }
 
-- 
2.16.4

___
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 [v3,1/2] drm/i915/icl: move has_resource_streamer to GEN11_FEATURES

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/2] drm/i915/icl: move has_resource_streamer 
to GEN11_FEATURES
URL   : https://patchwork.freedesktop.org/series/46884/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4514 -> Patchwork_9719 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/46884/revisions/1/mbox/

== Known issues ==

  Here are the changes found in Patchwork_9719 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@debugfs_test@read_all_entries:
  fi-snb-2520m:   PASS -> INCOMPLETE (fdo#103713)

igt@drv_selftest@live_hangcheck:
  fi-kbl-7567u:   PASS -> DMESG-FAIL (fdo#106560, fdo#106947)

igt@drv_selftest@live_workarounds:
  fi-bxt-j4205:   PASS -> DMESG-FAIL (fdo#107292)

igt@gem_exec_suspend@basic-s4-devices:
  fi-kbl-7500u:   PASS -> DMESG-WARN (fdo#107139, fdo#105128)

igt@kms_flip@basic-flip-vs-dpms:
  fi-skl-6700hq:  PASS -> DMESG-WARN (fdo#105998)


 Possible fixes 

igt@drv_selftest@live_workarounds:
  {fi-cfl-8109u}: DMESG-FAIL (fdo#107292) -> PASS


  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
  fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128
  fdo#105998 https://bugs.freedesktop.org/show_bug.cgi?id=105998
  fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
  fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
  fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139
  fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292


== Participating hosts (47 -> 41) ==

  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-byt-squawks 
fi-bsw-cyan fi-ctg-p8600 


== Build changes ==

* Linux: CI_DRM_4514 -> Patchwork_9719

  CI_DRM_4514: 4aa8b84189887647612154ca9eda06cfc9a587df @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4568: 86f7b724ef18986bc58d35558d22e1ed3f8df4f9 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9719: fc42f78a7aa4ea7c840510cdec07cc9c13727c10 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

fc42f78a7aa4 drm/i915: kill resource streamer
f8b519e3fed7 drm/i915/icl: move has_resource_streamer to GEN11_FEATURES

== Logs ==

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

[Intel-gfx] [PATCH 18/18] drm/i915: Bump gen4+ fb size limits to 32kx32k

[Ville Syrjala]

From: Ville Syrjälä 

With gtt remapping in place we can use arbitraily large framebuffers.
Let's bump the limits as high as we can (32k-1). Going beyond that
would require switching out s16.16 src coordinate representation to
something with more spare bits.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index fa199f469e81..8aa2a61d2943 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15429,8 +15429,8 @@ int intel_modeset_init(struct drm_device *dev)
dev->mode_config.max_width = 4096;
dev->mode_config.max_height = 4096;
} else {
-   dev->mode_config.max_width = 8192;
-   dev->mode_config.max_height = 8192;
+   dev->mode_config.max_width = 32767;
+   dev->mode_config.max_height = 32767;
}
 
if (IS_I845G(dev_priv) || IS_I865G(dev_priv)) {
-- 
2.16.4

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

[Intel-gfx] [PATCH 15/18] drm/i915: Add a new "remapped" gtt_view

[Ville Syrjala]

From: Ville Syrjälä 

To overcome display engine stride limits we'll want to remap the
pages in the GTT. To that end we need a new gtt_view type which
is just like the "rotated" type except not rotated.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 12 +
 drivers/gpu/drm/i915/i915_gem_gtt.c  | 91 
 drivers/gpu/drm/i915/i915_gem_gtt.h  | 16 +++
 drivers/gpu/drm/i915/i915_vma.c  |  6 ++-
 drivers/gpu/drm/i915/i915_vma.h  |  5 +-
 drivers/gpu/drm/i915/intel_display.c | 11 +
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 7 files changed, 140 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index b3aefd623557..82b2984eabee 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -196,6 +196,18 @@ describe_obj(struct seq_file *m, struct 
drm_i915_gem_object *obj)
   
vma->ggtt_view.rotated.plane[1].offset);
break;
 
+   case I915_GGTT_VIEW_REMAPPED:
+   seq_printf(m, ", remapped [(%ux%u, stride=%u, 
offset=%u), (%ux%u, stride=%u, offset=%u)]",
+  
vma->ggtt_view.remapped.plane[0].width,
+  
vma->ggtt_view.remapped.plane[0].height,
+  
vma->ggtt_view.remapped.plane[0].stride,
+  
vma->ggtt_view.remapped.plane[0].offset,
+  
vma->ggtt_view.remapped.plane[1].width,
+  
vma->ggtt_view.remapped.plane[1].height,
+  
vma->ggtt_view.remapped.plane[1].stride,
+  
vma->ggtt_view.remapped.plane[1].offset);
+   break;
+
default:
MISSING_CASE(vma->ggtt_view.type);
break;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index f00c7fbef79e..29b16f564225 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3800,6 +3800,92 @@ intel_rotate_pages(struct intel_rotation_info *rot_info,
return ERR_PTR(ret);
 }
 
+static struct scatterlist *
+remap_pages(const dma_addr_t *in, unsigned int offset,
+   unsigned int width, unsigned int height,
+   unsigned int stride,
+   struct sg_table *st, struct scatterlist *sg)
+{
+   unsigned int column, row;
+
+   for (row = 0; row < height; row++) {
+   for (column = 0; column < width; column++) {
+   st->nents++;
+   /* We don't need the pages, but need to initialize
+* the entries so the sg list can be happily traversed.
+* The only thing we need are DMA addresses.
+*/
+   sg_set_page(sg, NULL, PAGE_SIZE, 0);
+   sg_dma_address(sg) = in[offset + column];
+   sg_dma_len(sg) = PAGE_SIZE;
+   sg = sg_next(sg);
+   }
+   offset += stride;
+   }
+
+   return sg;
+}
+
+static noinline struct sg_table *
+intel_remap_pages(struct intel_remapped_info *rem_info,
+ struct drm_i915_gem_object *obj)
+{
+   const unsigned long n_pages = obj->base.size / PAGE_SIZE;
+   unsigned int size = intel_remapped_info_size(rem_info);
+   struct sgt_iter sgt_iter;
+   dma_addr_t dma_addr;
+   unsigned long i;
+   dma_addr_t *page_addr_list;
+   struct sg_table *st;
+   struct scatterlist *sg;
+   int ret = -ENOMEM;
+
+   /* Allocate a temporary list of source pages for random access. */
+   page_addr_list = kvmalloc_array(n_pages,
+   sizeof(dma_addr_t),
+   GFP_KERNEL);
+   if (!page_addr_list)
+   return ERR_PTR(ret);
+
+   /* Allocate target SG list. */
+   st = kmalloc(sizeof(*st), GFP_KERNEL);
+   if (!st)
+   goto err_st_alloc;
+
+   ret = sg_alloc_table(st, size, GFP_KERNEL);
+   if (ret)
+   goto err_sg_alloc;
+
+   /* Populate source page list from the object. */
+   i = 0;
+   for_each_sgt_dma(dma_addr, sgt_iter, obj->mm.pages)
+   page_addr_list[i++] = dma_addr;
+
+   GEM_BUG_ON(i != n_pages);
+   st->nents = 0;
+   sg = st->sgl;
+
+   for (i = 0 ; i < ARRAY_SIZE(rem_info->plane); i++) {
+   sg = remap_pages(page_addr_list, rem_info->plane[i].offset,
+rem_info->plane[i].width, 
rem_info->plane[i].height,
+rem_info->plane[i].s

[Intel-gfx] [PATCH 16/18] drm/i915: Overcome display engine stride limits via GTT remapping

[Ville Syrjala]

From: Ville Syrjälä 

The display engine stride limits are getting in our way. On SKL+
we are limited to 8k pixels, which is easily exceeded with three
4k displays. To overcome this limitation we can remap the pages
in the GTT to provide the display engine with a view of memory
with a smaller stride.

The code is mostly already there as We already play tricks with
the plane surface address and x/y offsets.

A few caveats apply:
* linear buffers need the fb stride to be page aligned, as
  otherwise the remapped lines wouldn't start at the same
  spot
* compressed buffers can't be remapped due to the new
  ccs hash mode causing the virtual address of the pages
  to affect the interpretation of the compressed data. IIRC
  the old hash was limited to the low 12 bits so if we were
  using that mode we could remap. As it stands we just refuse
  to remapp with compressed fbs.
* no remapping gen2/3 as we'd need a fence for the remapped
  vma, which we currently don't have

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 387 ---
 1 file changed, 311 insertions(+), 76 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e6f48fab65de..8fb78214b4be 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1923,7 +1923,7 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb, 
int color_plane)
 
switch (fb->modifier) {
case DRM_FORMAT_MOD_LINEAR:
-   return cpp;
+   return intel_tile_size(dev_priv);
case I915_FORMAT_MOD_X_TILED:
if (IS_GEN2(dev_priv))
return 128;
@@ -1966,11 +1966,8 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb, 
int color_plane)
 static unsigned int
 intel_tile_height(const struct drm_framebuffer *fb, int color_plane)
 {
-   if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
-   return 1;
-   else
-   return intel_tile_size(to_i915(fb->dev)) /
-   intel_tile_width_bytes(fb, color_plane);
+   return intel_tile_size(to_i915(fb->dev)) /
+   intel_tile_width_bytes(fb, color_plane);
 }
 
 /* Return the tile dimensions in pixel units */
@@ -2225,16 +,8 @@ void intel_add_fb_offsets(int *x, int *y,
  int color_plane)
 
 {
-   const struct intel_framebuffer *intel_fb = 
to_intel_framebuffer(state->base.fb);
-   unsigned int rotation = state->base.rotation;
-
-   if (drm_rotation_90_or_270(rotation)) {
-   *x += intel_fb->rotated[color_plane].x;
-   *y += intel_fb->rotated[color_plane].y;
-   } else {
-   *x += intel_fb->normal[color_plane].x;
-   *y += intel_fb->normal[color_plane].y;
-   }
+   *x += state->color_plane[color_plane].x;
+   *y += state->color_plane[color_plane].y;
 }
 
 static u32 intel_adjust_tile_offset(int *x, int *y,
@@ -2488,6 +2477,111 @@ intel_get_format_info(const struct drm_mode_fb_cmd2 
*cmd)
}
 }
 
+static bool intel_modifier_has_ccs(u64 modifier)
+{
+   return modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
+   modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
+}
+
+static
+u32 intel_plane_fb_max_stride(struct drm_i915_private *dev_priv,
+ u32 pixel_format, u64 modifier)
+{
+   struct intel_crtc *crtc;
+   struct intel_plane *plane;
+
+   /*
+* We assume the primary plane for pipe A has
+* the highest stride limits of them all.
+*/
+   crtc = intel_get_crtc_for_pipe(dev_priv, PIPE_A);
+   plane = to_intel_plane(crtc->base.primary);
+
+   return plane->max_stride(plane, pixel_format, modifier,
+DRM_MODE_ROTATE_0);
+}
+
+static
+u32 intel_fb_max_stride(struct drm_i915_private *dev_priv,
+   u32 pixel_format, u64 modifier)
+{
+   return intel_plane_fb_max_stride(dev_priv, pixel_format, modifier);
+}
+
+static u32
+intel_fb_stride_alignment(const struct drm_framebuffer *fb, int color_plane)
+{
+   struct drm_i915_private *dev_priv = to_i915(fb->dev);
+
+   if (fb->modifier == DRM_FORMAT_MOD_LINEAR) {
+   u32 max_stride = intel_plane_fb_max_stride(dev_priv,
+  fb->format->format,
+  fb->modifier);
+
+   /*
+* To make remapping with linear generally feasible
+* we need the stride to be page aligned.
+*/
+   if (fb->pitches[color_plane] > max_stride)
+   return intel_tile_size(dev_priv);
+   else
+   return 64;
+   } else {
+   return intel_tile_width_bytes(fb, color_plane);
+   }
+}
+
+static int
+intel_plane_check_stride(const struct intel_plane_state *plane_stat

[Intel-gfx] [PATCH 14/18] drm/i915: Extract intel_cursor_check_surface()

[Ville Syrjala]

From: Ville Syrjälä 

Extract intel_cursor_check_surface() to better match the code layout
of the other plane types.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 47 ++--
 1 file changed, 29 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b0e39dcf2fb8..b39c941b4791 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9667,13 +9667,37 @@ static bool intel_cursor_size_ok(const struct 
intel_plane_state *plane_state)
height > 0 && height <= config->cursor_height;
 }
 
-static int intel_check_cursor(struct intel_crtc_state *crtc_state,
- struct intel_plane_state *plane_state)
+static int intel_cursor_check_surface(struct intel_plane_state *plane_state)
 {
const struct drm_framebuffer *fb = plane_state->base.fb;
unsigned int rotation = plane_state->base.rotation;
int src_x, src_y;
u32 offset;
+
+   intel_fill_fb_ggtt_view(&plane_state->view, fb, rotation);
+   plane_state->color_plane[0].stride = intel_fb_pitch(fb, 0, rotation);
+
+   src_x = plane_state->base.src_x >> 16;
+   src_y = plane_state->base.src_y >> 16;
+
+   intel_add_fb_offsets(&src_x, &src_y, plane_state, 0);
+   offset = intel_plane_compute_aligned_offset(&src_x, &src_y,
+   plane_state, 0);
+
+   if (src_x != 0 || src_y != 0) {
+   DRM_DEBUG_KMS("Arbitrary cursor panning not supported\n");
+   return -EINVAL;
+   }
+
+   plane_state->color_plane[0].offset = offset;
+
+   return 0;
+}
+
+static int intel_check_cursor(struct intel_crtc_state *crtc_state,
+ struct intel_plane_state *plane_state)
+{
+   const struct drm_framebuffer *fb = plane_state->base.fb;
int ret;
 
if (fb && fb->modifier != DRM_FORMAT_MOD_LINEAR) {
@@ -9696,22 +9720,9 @@ static int intel_check_cursor(struct intel_crtc_state 
*crtc_state,
if (ret)
return ret;
 
-   intel_fill_fb_ggtt_view(&plane_state->view, fb, rotation);
-   plane_state->color_plane[0].stride = intel_fb_pitch(fb, 0, rotation);
-
-   src_x = plane_state->base.src_x >> 16;
-   src_y = plane_state->base.src_y >> 16;
-
-   intel_add_fb_offsets(&src_x, &src_y, plane_state, 0);
-   offset = intel_plane_compute_aligned_offset(&src_x, &src_y,
-   plane_state, 0);
-
-   if (src_x != 0 || src_y != 0) {
-   DRM_DEBUG_KMS("Arbitrary cursor panning not supported\n");
-   return -EINVAL;
-   }
-
-   plane_state->color_plane[0].offset = offset;
+   ret = intel_cursor_check_surface(plane_state);
+   if (ret)
+   return ret;
 
return 0;
 }
-- 
2.16.4

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

[Intel-gfx] [PATCH 07/18] drm/i915: Store ggtt_view in plane_state

[Ville Syrjala]

From: Ville Syrjälä 

Stash the gtt_view structure into the plane state. This will become
useful when we do GTT remapping as the gtt_view will not come directly
from the fb anymore.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 16 +---
 drivers/gpu/drm/i915/intel_drv.h |  3 ++-
 drivers/gpu/drm/i915/intel_fbdev.c   |  6 --
 3 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index eadb8b20d504..e6cb8238f257 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2079,14 +2079,13 @@ static bool intel_plane_uses_fence(const struct 
intel_plane_state *plane_state)
 
 struct i915_vma *
 intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
-  unsigned int rotation,
+  const struct i915_ggtt_view *view,
   bool uses_fence,
   unsigned long *out_flags)
 {
struct drm_device *dev = fb->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
-   struct i915_ggtt_view view;
struct i915_vma *vma;
unsigned int pinctl;
u32 alignment;
@@ -2095,8 +2094,6 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
 
alignment = intel_surf_alignment(fb, 0);
 
-   intel_fill_fb_ggtt_view(&view, fb, rotation);
-
/* Note that the w/a also requires 64 PTE of padding following the
 * bo. We currently fill all unused PTE with the shadow page and so
 * we should always have valid PTE following the scanout preventing
@@ -2129,7 +2126,7 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
pinctl |= PIN_MAPPABLE;
 
vma = i915_gem_object_pin_to_display_plane(obj,
-  alignment, &view, pinctl);
+  alignment, view, pinctl);
if (IS_ERR(vma))
goto err;
 
@@ -2851,13 +2848,15 @@ intel_find_initial_plane_obj(struct intel_crtc 
*intel_crtc,
return;
 
 valid_fb:
+   intel_fill_fb_ggtt_view(&intel_state->view, fb,
+   intel_state->base.rotation);
intel_state->color_plane[0].stride =
intel_fb_pitch(fb, 0, intel_state->base.rotation);
 
mutex_lock(&dev->struct_mutex);
intel_state->vma =
intel_pin_and_fence_fb_obj(fb,
-  primary->state->rotation,
+  &intel_state->view,
   intel_plane_uses_fence(intel_state),
   &intel_state->flags);
mutex_unlock(&dev->struct_mutex);
@@ -3171,6 +3170,7 @@ int skl_check_plane_surface(const struct intel_crtc_state 
*crtc_state,
unsigned int rotation = plane_state->base.rotation;
int ret;
 
+   intel_fill_fb_ggtt_view(&plane_state->view, fb, rotation);
plane_state->color_plane[0].stride = intel_fb_pitch(fb, 0, rotation);
plane_state->color_plane[1].stride = intel_fb_pitch(fb, 1, rotation);
 
@@ -3315,6 +3315,7 @@ int i9xx_check_plane_surface(struct intel_plane_state 
*plane_state)
int src_y = plane_state->base.src.y1 >> 16;
u32 offset;
 
+   intel_fill_fb_ggtt_view(&plane_state->view, fb, rotation);
plane_state->color_plane[0].stride = intel_fb_pitch(fb, 0, rotation);
 
intel_add_fb_offsets(&src_x, &src_y, plane_state, 0);
@@ -9691,6 +9692,7 @@ static int intel_check_cursor(struct intel_crtc_state 
*crtc_state,
return -EINVAL;
}
 
+   intel_fill_fb_ggtt_view(&plane_state->view, fb, rotation);
plane_state->color_plane[0].stride = intel_fb_pitch(fb, 0, rotation);
 
src_x = plane_state->base.src_x >> 16;
@@ -13029,7 +13031,7 @@ static int intel_plane_pin_fb(struct intel_plane_state 
*plane_state)
}
 
vma = intel_pin_and_fence_fb_obj(fb,
-plane_state->base.rotation,
+&plane_state->view,
 intel_plane_uses_fence(plane_state),
 &plane_state->flags);
if (IS_ERR(vma))
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f647f9e1f671..d70276ff3d0e 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -494,6 +494,7 @@ struct intel_atomic_state {
 
 struct intel_plane_state {
struct drm_plane_state base;
+   struct i915_ggtt_view view;
struct i915_vma *vma;
unsigned long flags;
 #define PLANE_HAS_FENCE BIT(0)
@@ -1560,7 +1561,7 @@ void intel_release_load_detect_pipe(struct drm_connector 
*connector,
  

[Intel-gfx] [PATCH 00/18] drm/i915: GTT remapping for display

[Ville Syrjala]

From: Ville Syrjälä 

The display engine has unfortunately low stride limits when compared to
modern display resolutions. 2x4k is about as big as we can go currently.
This series aims to overcome that by shuffling the pages in the GTT to
provide the display engine with a view of memory with a smaller stride.

We pretty much had all the code already on account of rotation and
whatnot, just had to massage the surroundings a bit. Strictly speaking
I could probably drop most of the plane check() refactoring patches from
this without affecting the outcome, but things kept bugging me all the
time so naturally I had to change them.

Entire series is available here:
git://github.com/vsyrjala/linux.git fb_vma_remap_6

Ville Syrjälä (18):
  drm/i915: Fix glk/cnl display w/a #1175
  drm/i915: s/tile_offset/aligned_offset/
  drm/i915: Add .max_stride() plane hook
  drm/i915: Use pipe A primary plane .max_stride() as the global stride
limit
  drm/i915: Rename the plane_state->main/aux to
plane_state->color_plane[]
  drm/i915: Store the final plane stride in plane_state
  drm/i915: Store ggtt_view in plane_state
  drm/i915: s/int plane/int color_plane/
  drm/i915: Nuke plane->can_scale/min_downscale
  drm/i915: Extract per-platform plane->check() functions
  drm/i915: Move skl plane fb related checks into a better place
  drm/i915: Move display w/a #1175
  drm/i915: Move chv rotation checks to plane->check()
  drm/i915: Extract intel_cursor_check_surface()
  drm/i915: Add a new "remapped" gtt_view
  drm/i915: Overcome display engine stride limits via GTT remapping
  drm/i915: Bump gen4+ fb stride limit to 256KiB
  drm/i915: Bump gen4+ fb size limits to 32kx32k

 drivers/gpu/drm/i915/i915_debugfs.c   |  12 +
 drivers/gpu/drm/i915/i915_gem_gtt.c   |  91 +++
 drivers/gpu/drm/i915/i915_gem_gtt.h   |  16 +
 drivers/gpu/drm/i915/i915_vma.c   |   6 +-
 drivers/gpu/drm/i915/i915_vma.h   |   5 +-
 drivers/gpu/drm/i915/intel_atomic_plane.c |  53 +-
 drivers/gpu/drm/i915/intel_display.c  | 969 +++---
 drivers/gpu/drm/i915/intel_drv.h  |  51 +-
 drivers/gpu/drm/i915/intel_fbc.c  |   4 +-
 drivers/gpu/drm/i915/intel_fbdev.c|   6 +-
 drivers/gpu/drm/i915/intel_sprite.c   | 495 ++-
 11 files changed, 1138 insertions(+), 570 deletions(-)

-- 
2.16.4

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

[Intel-gfx] [PATCH 11/18] drm/i915: Move skl plane fb related checks into a better place

[Ville Syrjala]

From: Ville Syrjälä 

Move the skl+ specific framebuffer related checks from
intel_plane_atomic_check_with_state() into a new function
(skl_plane_check_fb()) which we'll simply call from the skl
plane->check() hook.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c | 42 
 drivers/gpu/drm/i915/intel_display.c  | 12 --
 drivers/gpu/drm/i915/intel_sprite.c   | 66 +++
 3 files changed, 66 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index eddcdd6e4b3b..7c0873060934 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -116,40 +116,11 @@ int intel_plane_atomic_check_with_state(const struct 
intel_crtc_state *old_crtc_
struct drm_i915_private *dev_priv = to_i915(plane->dev);
struct drm_plane_state *state = &intel_state->base;
struct intel_plane *intel_plane = to_intel_plane(plane);
-   const struct drm_display_mode *adjusted_mode =
-   &crtc_state->base.adjusted_mode;
int ret;
 
if (!intel_state->base.crtc && !old_plane_state->base.crtc)
return 0;
 
-   if (state->fb && drm_rotation_90_or_270(state->rotation)) {
-   struct drm_format_name_buf format_name;
-
-   if (state->fb->modifier != I915_FORMAT_MOD_Y_TILED &&
-   state->fb->modifier != I915_FORMAT_MOD_Yf_TILED) {
-   DRM_DEBUG_KMS("Y/Yf tiling required for 90/270!\n");
-   return -EINVAL;
-   }
-
-   /*
-* 90/270 is not allowed with RGB64 16:16:16:16,
-* RGB 16-bit 5:6:5, and Indexed 8-bit.
-* TBD: Add RGB64 case once its added in supported format list.
-*/
-   switch (state->fb->format->format) {
-   case DRM_FORMAT_C8:
-   case DRM_FORMAT_RGB565:
-   DRM_DEBUG_KMS("Unsupported pixel format %s for 
90/270!\n",
- 
drm_get_format_name(state->fb->format->format,
- &format_name));
-   return -EINVAL;
-
-   default:
-   break;
-   }
-   }
-
/* CHV ignores the mirror bit when the rotate bit is set :( */
if (IS_CHERRYVIEW(dev_priv) &&
state->rotation & DRM_MODE_ROTATE_180 &&
@@ -163,19 +134,6 @@ int intel_plane_atomic_check_with_state(const struct 
intel_crtc_state *old_crtc_
if (ret)
return ret;
 
-   /*
-* Y-tiling is not supported in IF-ID Interlace mode in
-* GEN9 and above.
-*/
-   if (state->fb && INTEL_GEN(dev_priv) >= 9 && crtc_state->base.enable &&
-   adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) {
-   if (state->fb->modifier == I915_FORMAT_MOD_Y_TILED ||
-   state->fb->modifier == I915_FORMAT_MOD_Yf_TILED) {
-   DRM_DEBUG_KMS("Y/Yf tiling not supported in IF-ID 
mode\n");
-   return -EINVAL;
-   }
-   }
-
/* FIXME pre-g4x don't work like this */
if (state->visible)
crtc_state->active_planes |= BIT(intel_plane->id);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9b9eaeda15dd..2381b762d109 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3151,12 +3151,6 @@ static int skl_check_ccs_aux_surface(struct 
intel_plane_state *plane_state)
int y = src_y / vsub;
u32 offset;
 
-   if (plane_state->base.rotation & ~(DRM_MODE_ROTATE_0 | 
DRM_MODE_ROTATE_180)) {
-   DRM_DEBUG_KMS("RC support only with 0/180 degree rotation %x\n",
- plane_state->base.rotation);
-   return -EINVAL;
-   }
-
intel_add_fb_offsets(&x, &y, plane_state, 1);
offset = intel_plane_compute_aligned_offset(&x, &y, plane_state, 1);
 
@@ -3178,12 +3172,6 @@ int skl_check_plane_surface(const struct 
intel_crtc_state *crtc_state,
plane_state->color_plane[0].stride = intel_fb_pitch(fb, 0, rotation);
plane_state->color_plane[1].stride = intel_fb_pitch(fb, 1, rotation);
 
-   if (rotation & DRM_MODE_REFLECT_X &&
-   fb->modifier == DRM_FORMAT_MOD_LINEAR) {
-   DRM_DEBUG_KMS("horizontal flip is not supported with linear 
surface formats\n");
-   return -EINVAL;
-   }
-
if (!plane_state->base.visible)
return 0;
 
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 36e150885897..041b8921f4fe 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1156,6 +1156,68 @@ vlv_sprite_check(st

[Intel-gfx] [PATCH 01/18] drm/i915: Fix glk/cnl display w/a #1175

[Ville Syrjala]

From: Ville Syrjälä 

The workaround was supposed to look at the plane destination
coordinates. Currently it's looking at some mixture of src
and dst coordinates that doesn't make sense. Fix it up.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 87e4cfbfd096..8efff0c56920 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2988,6 +2988,7 @@ static int skl_check_main_surface(const struct 
intel_crtc_state *crtc_state,
int w = drm_rect_width(&plane_state->base.src) >> 16;
int h = drm_rect_height(&plane_state->base.src) >> 16;
int dst_x = plane_state->base.dst.x1;
+   int dst_w = drm_rect_width(&plane_state->base.dst);
int pipe_src_w = crtc_state->pipe_src_w;
int max_width = skl_max_plane_width(fb, 0, rotation);
int max_height = 4096;
@@ -3009,10 +3010,10 @@ static int skl_check_main_surface(const struct 
intel_crtc_state *crtc_state,
 * screen may cause FIFO underflow and display corruption.
 */
if ((IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) &&
-   (dst_x + w < 4 || dst_x > pipe_src_w - 4)) {
+   (dst_x + dst_w < 4 || dst_x > pipe_src_w - 4)) {
DRM_DEBUG_KMS("requested plane X %s position %d invalid (valid 
range %d-%d)\n",
- dst_x + w < 4 ? "end" : "start",
- dst_x + w < 4 ? dst_x + w : dst_x,
+ dst_x + dst_w < 4 ? "end" : "start",
+ dst_x + dst_w < 4 ? dst_x + dst_w : dst_x,
  4, pipe_src_w - 4);
return -ERANGE;
}
-- 
2.16.4

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

[Intel-gfx] [PATCH 08/18] drm/i915: s/int plane/int color_plane/

[Ville Syrjala]

From: Ville Syrjälä 

To reduce the confusion between a drm plane and the planes of
framebuffers let's desiginate the latter as "color plane".

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 106 ++-
 drivers/gpu/drm/i915/intel_drv.h |   2 +-
 2 files changed, 56 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e6cb8238f257..bc2a712311ba 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1916,10 +1916,10 @@ static unsigned int intel_tile_size(const struct 
drm_i915_private *dev_priv)
 }
 
 static unsigned int
-intel_tile_width_bytes(const struct drm_framebuffer *fb, int plane)
+intel_tile_width_bytes(const struct drm_framebuffer *fb, int color_plane)
 {
struct drm_i915_private *dev_priv = to_i915(fb->dev);
-   unsigned int cpp = fb->format->cpp[plane];
+   unsigned int cpp = fb->format->cpp[color_plane];
 
switch (fb->modifier) {
case DRM_FORMAT_MOD_LINEAR:
@@ -1930,7 +1930,7 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb, 
int plane)
else
return 512;
case I915_FORMAT_MOD_Y_TILED_CCS:
-   if (plane == 1)
+   if (color_plane == 1)
return 128;
/* fall through */
case I915_FORMAT_MOD_Y_TILED:
@@ -1939,7 +1939,7 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb, 
int plane)
else
return 512;
case I915_FORMAT_MOD_Yf_TILED_CCS:
-   if (plane == 1)
+   if (color_plane == 1)
return 128;
/* fall through */
case I915_FORMAT_MOD_Yf_TILED:
@@ -1964,22 +1964,22 @@ intel_tile_width_bytes(const struct drm_framebuffer 
*fb, int plane)
 }
 
 static unsigned int
-intel_tile_height(const struct drm_framebuffer *fb, int plane)
+intel_tile_height(const struct drm_framebuffer *fb, int color_plane)
 {
if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
return 1;
else
return intel_tile_size(to_i915(fb->dev)) /
-   intel_tile_width_bytes(fb, plane);
+   intel_tile_width_bytes(fb, color_plane);
 }
 
 /* Return the tile dimensions in pixel units */
-static void intel_tile_dims(const struct drm_framebuffer *fb, int plane,
+static void intel_tile_dims(const struct drm_framebuffer *fb, int color_plane,
unsigned int *tile_width,
unsigned int *tile_height)
 {
-   unsigned int tile_width_bytes = intel_tile_width_bytes(fb, plane);
-   unsigned int cpp = fb->format->cpp[plane];
+   unsigned int tile_width_bytes = intel_tile_width_bytes(fb, color_plane);
+   unsigned int cpp = fb->format->cpp[color_plane];
 
*tile_width = tile_width_bytes / cpp;
*tile_height = intel_tile_size(to_i915(fb->dev)) / tile_width_bytes;
@@ -1987,9 +1987,9 @@ static void intel_tile_dims(const struct drm_framebuffer 
*fb, int plane,
 
 unsigned int
 intel_fb_align_height(const struct drm_framebuffer *fb,
- int plane, unsigned int height)
+ int color_plane, unsigned int height)
 {
-   unsigned int tile_height = intel_tile_height(fb, plane);
+   unsigned int tile_height = intel_tile_height(fb, color_plane);
 
return ALIGN(height, tile_height);
 }
@@ -2043,12 +2043,12 @@ static unsigned int intel_linear_alignment(const struct 
drm_i915_private *dev_pr
 }
 
 static unsigned int intel_surf_alignment(const struct drm_framebuffer *fb,
-int plane)
+int color_plane)
 {
struct drm_i915_private *dev_priv = to_i915(fb->dev);
 
/* AUX_DIST needs only 4K alignment */
-   if (plane == 1)
+   if (color_plane == 1)
return 4096;
 
switch (fb->modifier) {
@@ -2178,13 +2178,13 @@ void intel_unpin_fb_vma(struct i915_vma *vma, unsigned 
long flags)
i915_vma_put(vma);
 }
 
-static int intel_fb_pitch(const struct drm_framebuffer *fb, int plane,
+static int intel_fb_pitch(const struct drm_framebuffer *fb, int color_plane,
  unsigned int rotation)
 {
if (drm_rotation_90_or_270(rotation))
-   return to_intel_framebuffer(fb)->rotated[plane].pitch;
+   return to_intel_framebuffer(fb)->rotated[color_plane].pitch;
else
-   return fb->pitches[plane];
+   return fb->pitches[color_plane];
 }
 
 /*
@@ -2195,11 +2195,11 @@ static int intel_fb_pitch(const struct drm_framebuffer 
*fb, int plane,
  */
 u32 intel_fb_xy_to_linear(int x, int y,
  const struct intel_plane_state *state,
- int plane)
+ int color_plane)
 {
co

[Intel-gfx] [PATCH 10/18] drm/i915: Extract per-platform plane->check() functions

[Ville Syrjala]

From: Ville Syrjälä 

Split up intel_check_primary_plane() and intel_check_sprite_plane()
into per-platform variants. This way we can get a unified behaviour
between the SKL universal planes, and we stop checking for non-SKL
specific scaling limits for the "sprite" planes. And we now get
a natural place where to add more plarform specific checks.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c |   2 +-
 drivers/gpu/drm/i915/intel_display.c  | 123 +---
 drivers/gpu/drm/i915/intel_drv.h  |  13 +-
 drivers/gpu/drm/i915/intel_sprite.c   | 303 +++---
 4 files changed, 249 insertions(+), 192 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index dcba645cabb8..eddcdd6e4b3b 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -159,7 +159,7 @@ int intel_plane_atomic_check_with_state(const struct 
intel_crtc_state *old_crtc_
}
 
intel_state->base.visible = false;
-   ret = intel_plane->check_plane(intel_plane, crtc_state, intel_state);
+   ret = intel_plane->check_plane(crtc_state, intel_state);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index fdc5bedc5135..9b9eaeda15dd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3350,6 +3350,36 @@ int i9xx_check_plane_surface(struct intel_plane_state 
*plane_state)
return 0;
 }
 
+static int
+i9xx_plane_check(struct intel_crtc_state *crtc_state,
+struct intel_plane_state *plane_state)
+{
+   int ret;
+
+   ret = drm_atomic_helper_check_plane_state(&plane_state->base,
+ &crtc_state->base,
+ DRM_PLANE_HELPER_NO_SCALING,
+ DRM_PLANE_HELPER_NO_SCALING,
+ false, true);
+   if (ret)
+   return ret;
+
+   if (!plane_state->base.visible)
+   return 0;
+
+   ret = intel_plane_check_src_coordinates(plane_state);
+   if (ret)
+   return ret;
+
+   ret = i9xx_check_plane_surface(plane_state);
+   if (ret)
+   return ret;
+
+   plane_state->ctl = i9xx_plane_ctl(crtc_state, plane_state);
+
+   return 0;
+}
+
 static void i9xx_update_plane(struct intel_plane *plane,
  const struct intel_crtc_state *crtc_state,
  const struct intel_plane_state *plane_state)
@@ -9680,6 +9710,11 @@ static int intel_check_cursor(struct intel_crtc_state 
*crtc_state,
u32 offset;
int ret;
 
+   if (fb && fb->modifier != DRM_FORMAT_MOD_LINEAR) {
+   DRM_DEBUG_KMS("cursor cannot be tiled\n");
+   return -EINVAL;
+   }
+
ret = drm_atomic_helper_check_plane_state(&plane_state->base,
  &crtc_state->base,
  DRM_PLANE_HELPER_NO_SCALING,
@@ -9688,13 +9723,12 @@ static int intel_check_cursor(struct intel_crtc_state 
*crtc_state,
if (ret)
return ret;
 
-   if (!fb)
+   if (!plane_state->base.visible)
return 0;
 
-   if (fb->modifier != DRM_FORMAT_MOD_LINEAR) {
-   DRM_DEBUG_KMS("cursor cannot be tiled\n");
-   return -EINVAL;
-   }
+   ret = intel_plane_check_src_coordinates(plane_state);
+   if (ret)
+   return ret;
 
intel_fill_fb_ggtt_view(&plane_state->view, fb, rotation);
plane_state->color_plane[0].stride = intel_fb_pitch(fb, 0, rotation);
@@ -9744,8 +9778,7 @@ static bool i845_cursor_size_ok(const struct 
intel_plane_state *plane_state)
return intel_cursor_size_ok(plane_state) && IS_ALIGNED(width, 64);
 }
 
-static int i845_check_cursor(struct intel_plane *plane,
-struct intel_crtc_state *crtc_state,
+static int i845_check_cursor(struct intel_crtc_state *crtc_state,
 struct intel_plane_state *plane_state)
 {
const struct drm_framebuffer *fb = plane_state->base.fb;
@@ -9943,10 +9976,10 @@ static bool i9xx_cursor_size_ok(const struct 
intel_plane_state *plane_state)
return true;
 }
 
-static int i9xx_check_cursor(struct intel_plane *plane,
-struct intel_crtc_state *crtc_state,
+static int i9xx_check_cursor(struct intel_crtc_state *crtc_state,
 struct intel_plane_state *plane_state)
 {
+   struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
const struct drm_framebuffer *fb = plane_state->base.fb;
enum pipe pipe

[Intel-gfx] [PATCH 04/18] drm/i915: Use pipe A primary plane .max_stride() as the global stride limit

[Ville Syrjala]

From: Ville Syrjälä 

Let's assume that the primary plane for pipe A has the highest max
stride of all planes, and we'll use that as the global limit when
creating a new framebuffer.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 33 ++---
 1 file changed, 10 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a09e11e0596f..994685230b97 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14399,31 +14399,18 @@ static
 u32 intel_fb_pitch_limit(struct drm_i915_private *dev_priv,
 uint64_t fb_modifier, uint32_t pixel_format)
 {
-   u32 gen = INTEL_GEN(dev_priv);
+   struct intel_crtc *crtc;
+   struct intel_plane *plane;
 
-   if (gen >= 9) {
-   int cpp = drm_format_plane_cpp(pixel_format, 0);
+   /*
+* We assume the primary plane for pipe A has
+* the highest stride limits of them all.
+*/
+   crtc = intel_get_crtc_for_pipe(dev_priv, PIPE_A);
+   plane = to_intel_plane(crtc->base.primary);
 
-   /* "The stride in bytes must not exceed the of the size of 8K
-*  pixels and 32K bytes."
-*/
-   return min(8192 * cpp, 32768);
-   } else if (gen >= 5 && !HAS_GMCH_DISPLAY(dev_priv)) {
-   return 32*1024;
-   } else if (gen >= 4) {
-   if (fb_modifier == I915_FORMAT_MOD_X_TILED)
-   return 16*1024;
-   else
-   return 32*1024;
-   } else if (gen >= 3) {
-   if (fb_modifier == I915_FORMAT_MOD_X_TILED)
-   return 8*1024;
-   else
-   return 16*1024;
-   } else {
-   /* XXX DSPC is limited to 4k tiled */
-   return 8*1024;
-   }
+   return plane->max_stride(plane, pixel_format, fb_modifier,
+DRM_MODE_ROTATE_0);
 }
 
 static int intel_framebuffer_init(struct intel_framebuffer *intel_fb,
-- 
2.16.4

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

[Intel-gfx] [PATCH 05/18] drm/i915: Rename the plane_state->main/aux to plane_state->color_plane[]

[Ville Syrjala]

From: Ville Syrjälä 

Make the main/aux surface stuff a bit more generic by using an array
of structures. This will allow us to deal with both the main and aux
surfaces with common code.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 56 ++--
 drivers/gpu/drm/i915/intel_drv.h |  6 +---
 drivers/gpu/drm/i915/intel_fbc.c |  4 +--
 drivers/gpu/drm/i915/intel_sprite.c  | 29 ++-
 4 files changed, 46 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 994685230b97..3aec789657b1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2946,9 +2946,9 @@ static bool skl_check_main_ccs_coordinates(struct 
intel_plane_state *plane_state
const struct drm_framebuffer *fb = plane_state->base.fb;
int hsub = fb->format->hsub;
int vsub = fb->format->vsub;
-   int aux_x = plane_state->aux.x;
-   int aux_y = plane_state->aux.y;
-   u32 aux_offset = plane_state->aux.offset;
+   int aux_x = plane_state->color_plane[1].x;
+   int aux_y = plane_state->color_plane[1].y;
+   u32 aux_offset = plane_state->color_plane[1].offset;
u32 alignment = intel_surf_alignment(fb, 1);
 
while (aux_offset >= main_offset && aux_y <= main_y) {
@@ -2971,9 +2971,9 @@ static bool skl_check_main_ccs_coordinates(struct 
intel_plane_state *plane_state
if (aux_x != main_x || aux_y != main_y)
return false;
 
-   plane_state->aux.offset = aux_offset;
-   plane_state->aux.x = aux_x;
-   plane_state->aux.y = aux_y;
+   plane_state->color_plane[1].offset = aux_offset;
+   plane_state->color_plane[1].x = aux_x;
+   plane_state->color_plane[1].y = aux_y;
 
return true;
 }
@@ -2994,7 +2994,7 @@ static int skl_check_main_surface(const struct 
intel_crtc_state *crtc_state,
int pipe_src_w = crtc_state->pipe_src_w;
int max_width = skl_max_plane_width(fb, 0, rotation);
int max_height = 4096;
-   u32 alignment, offset, aux_offset = plane_state->aux.offset;
+   u32 alignment, offset, aux_offset = plane_state->color_plane[1].offset;
 
if (w > max_width || h > max_height) {
DRM_DEBUG_KMS("requested Y/RGB source size %dx%d too big (limit 
%dx%d)\n",
@@ -3067,15 +3067,15 @@ static int skl_check_main_surface(const struct 
intel_crtc_state *crtc_state,
   offset, 
offset - alignment);
}
 
-   if (x != plane_state->aux.x || y != plane_state->aux.y) {
+   if (x != plane_state->color_plane[1].x || y != 
plane_state->color_plane[1].y) {
DRM_DEBUG_KMS("Unable to find suitable display surface 
offset due to CCS\n");
return -EINVAL;
}
}
 
-   plane_state->main.offset = offset;
-   plane_state->main.x = x;
-   plane_state->main.y = y;
+   plane_state->color_plane[0].offset = offset;
+   plane_state->color_plane[0].x = x;
+   plane_state->color_plane[0].y = y;
 
return 0;
 }
@@ -3125,9 +3125,9 @@ static int skl_check_nv12_aux_surface(struct 
intel_plane_state *plane_state)
return -EINVAL;
}
 
-   plane_state->aux.offset = offset;
-   plane_state->aux.x = x;
-   plane_state->aux.y = y;
+   plane_state->color_plane[1].offset = offset;
+   plane_state->color_plane[1].x = x;
+   plane_state->color_plane[1].y = y;
 
return 0;
 }
@@ -3152,9 +3152,9 @@ static int skl_check_ccs_aux_surface(struct 
intel_plane_state *plane_state)
intel_add_fb_offsets(&x, &y, plane_state, 1);
offset = intel_plane_compute_aligned_offset(&x, &y, plane_state, 1);
 
-   plane_state->aux.offset = offset;
-   plane_state->aux.x = x * hsub + src_x % hsub;
-   plane_state->aux.y = y * vsub + src_y % vsub;
+   plane_state->color_plane[1].offset = offset;
+   plane_state->color_plane[1].x = x * hsub + src_x % hsub;
+   plane_state->color_plane[1].y = y * vsub + src_y % vsub;
 
return 0;
 }
@@ -3198,9 +3198,9 @@ int skl_check_plane_surface(const struct intel_crtc_state 
*crtc_state,
if (ret)
return ret;
} else {
-   plane_state->aux.offset = ~0xfff;
-   plane_state->aux.x = 0;
-   plane_state->aux.y = 0;
+   plane_state->color_plane[1].offset = ~0xfff;
+   plane_state->color_plane[1].x = 0;
+   plane_state->color_plane[1].y = 0;
}
 
ret = skl_check_main_surface(crtc_state, plane_state);
@@ -3327,9 +3327,9 @@ int i9xx_check_plane_surface(struct intel_plane_state 
*plane_state)
}
}
 
-   plane_state->main.offset = offset;
-   plane_state->main.x = src_x;
-   plane_state->main.y = 

[Intel-gfx] [PATCH 06/18] drm/i915: Store the final plane stride in plane_state

[Ville Syrjala]

From: Ville Syrjälä 

Let's store the final plane stride in the plane state. This avoids
having to pick betwen the normal vs. rotated stride during hardware
programming. And once we get GTT remapping the plane stride will
no longer match the fb stride so we'll need a place to store it
anyway.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 49 +++-
 drivers/gpu/drm/i915/intel_drv.h | 10 ++--
 drivers/gpu/drm/i915/intel_sprite.c  | 12 -
 3 files changed, 45 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3aec789657b1..eadb8b20d504 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2202,7 +2202,7 @@ u32 intel_fb_xy_to_linear(int x, int y,
 {
const struct drm_framebuffer *fb = state->base.fb;
unsigned int cpp = fb->format->cpp[plane];
-   unsigned int pitch = fb->pitches[plane];
+   unsigned int pitch = state->color_plane[plane].stride;
 
return y * pitch + x * cpp;
 }
@@ -2259,11 +2259,11 @@ static u32 intel_adjust_tile_offset(int *x, int *y,
 static u32 intel_adjust_aligned_offset(int *x, int *y,
   const struct drm_framebuffer *fb, int 
plane,
   unsigned int rotation,
+  unsigned int pitch,
   u32 old_offset, u32 new_offset)
 {
struct drm_i915_private *dev_priv = to_i915(fb->dev);
unsigned int cpp = fb->format->cpp[plane];
-   unsigned int pitch = intel_fb_pitch(fb, plane, rotation);
 
WARN_ON(new_offset > old_offset);
 
@@ -2305,6 +2305,7 @@ static u32 intel_plane_adjust_aligned_offset(int *x, int 
*y,
 {
return intel_adjust_aligned_offset(x, y, state->base.fb, plane,
   state->base.rotation,
+  state->color_plane[plane].stride,
   old_offset, new_offset);
 }
 
@@ -2381,7 +2382,7 @@ static u32 intel_plane_compute_aligned_offset(int *x, int 
*y,
struct drm_i915_private *dev_priv = to_i915(intel_plane->base.dev);
const struct drm_framebuffer *fb = state->base.fb;
unsigned int rotation = state->base.rotation;
-   int pitch = intel_fb_pitch(fb, plane, rotation);
+   int pitch = state->color_plane[plane].stride;
u32 alignment;
 
if (intel_plane->id == PLANE_CURSOR)
@@ -2408,6 +2409,7 @@ static int intel_fb_offset_to_xy(int *x, int *y,
 
intel_adjust_aligned_offset(x, y,
fb, plane, DRM_MODE_ROTATE_0,
+   fb->pitches[0],
fb->offsets[plane], 0);
 
return 0;
@@ -2849,6 +2851,9 @@ intel_find_initial_plane_obj(struct intel_crtc 
*intel_crtc,
return;
 
 valid_fb:
+   intel_state->color_plane[0].stride =
+   intel_fb_pitch(fb, 0, intel_state->base.rotation);
+
mutex_lock(&dev->struct_mutex);
intel_state->vma =
intel_pin_and_fence_fb_obj(fb,
@@ -3166,6 +3171,9 @@ int skl_check_plane_surface(const struct intel_crtc_state 
*crtc_state,
unsigned int rotation = plane_state->base.rotation;
int ret;
 
+   plane_state->color_plane[0].stride = intel_fb_pitch(fb, 0, rotation);
+   plane_state->color_plane[1].stride = intel_fb_pitch(fb, 1, rotation);
+
if (rotation & DRM_MODE_REFLECT_X &&
fb->modifier == DRM_FORMAT_MOD_LINEAR) {
DRM_DEBUG_KMS("horizontal flip is not supported with linear 
surface formats\n");
@@ -3301,10 +3309,14 @@ int i9xx_check_plane_surface(struct intel_plane_state 
*plane_state)
 {
struct drm_i915_private *dev_priv =
to_i915(plane_state->base.plane->dev);
+   const struct drm_framebuffer *fb = plane_state->base.fb;
+   unsigned int rotation = plane_state->base.rotation;
int src_x = plane_state->base.src.x1 >> 16;
int src_y = plane_state->base.src.y1 >> 16;
u32 offset;
 
+   plane_state->color_plane[0].stride = intel_fb_pitch(fb, 0, rotation);
+
intel_add_fb_offsets(&src_x, &src_y, plane_state, 0);
 
if (INTEL_GEN(dev_priv) >= 4)
@@ -3315,7 +3327,6 @@ int i9xx_check_plane_surface(struct intel_plane_state 
*plane_state)
 
/* HSW/BDW do this automagically in hardware */
if (!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv)) {
-   unsigned int rotation = plane_state->base.rotation;
int src_w = drm_rect_width(&plane_state->base.src) >> 16;
int src_h = drm_rect_height(&plane_state->base.src) >> 16;
 
@@ -3339,7 +3350,6 @@ static void i9xx_update_plane(struct intel_plane *plane,
  const struct intel_plane_state *plane_state)
 {
struct drm_i915_p

[Intel-gfx] [PATCH 03/18] drm/i915: Add .max_stride() plane hook

[Ville Syrjala]

From: Ville Syrjälä 

Each plane may have different stride limitations. Let's add a new
plane function to retutn the maximum stride for each plane. There's
going to be some use for this outside the .atomic_check() stuff hence
the separate hook.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 46 
 drivers/gpu/drm/i915/intel_drv.h | 10 
 drivers/gpu/drm/i915/intel_sprite.c  | 34 --
 3 files changed, 88 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5f8304a11482..a09e11e0596f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3210,6 +3210,31 @@ int skl_check_plane_surface(const struct 
intel_crtc_state *crtc_state,
return 0;
 }
 
+unsigned int
+i9xx_plane_max_stride(struct intel_plane *plane,
+ u32 pixel_format, u64 modifier,
+ unsigned int rotation)
+{
+   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+
+   if (INTEL_GEN(dev_priv) >= 4) {
+   if (modifier == I915_FORMAT_MOD_X_TILED)
+   return 16*1024;
+   else
+   return 32*1024;
+   } else if (INTEL_GEN(dev_priv) >= 3) {
+   if (modifier == I915_FORMAT_MOD_X_TILED)
+   return 8*1024;
+   else
+   return 16*1024;
+   } else {
+   if (plane->i9xx_plane == PLANE_C)
+   return 4*1024;
+   else
+   return 8*1024;
+   }
+}
+
 static u32 i9xx_plane_ctl(const struct intel_crtc_state *crtc_state,
  const struct intel_plane_state *plane_state)
 {
@@ -9672,6 +9697,14 @@ static int intel_check_cursor(struct intel_crtc_state 
*crtc_state,
return 0;
 }
 
+static unsigned int
+i845_cursor_max_stride(struct intel_plane *plane,
+  u32 pixel_format, u64 modifier,
+  unsigned int rotation)
+{
+   return 2048;
+}
+
 static u32 i845_cursor_ctl(const struct intel_crtc_state *crtc_state,
   const struct intel_plane_state *plane_state)
 {
@@ -9805,6 +9838,14 @@ static bool i845_cursor_get_hw_state(struct intel_plane 
*plane,
return ret;
 }
 
+static unsigned int
+i9xx_cursor_max_stride(struct intel_plane *plane,
+  u32 pixel_format, u64 modifier,
+  unsigned int rotation)
+{
+   return plane->base.dev->mode_config.cursor_width * 4;
+}
+
 static u32 i9xx_cursor_ctl(const struct intel_crtc_state *crtc_state,
   const struct intel_plane_state *plane_state)
 {
@@ -13699,6 +13740,7 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
else
modifiers = skl_format_modifiers_noccs;
 
+   primary->max_stride = skl_plane_max_stride;
primary->update_plane = skl_update_plane;
primary->disable_plane = skl_disable_plane;
primary->get_hw_state = skl_plane_get_hw_state;
@@ -13709,6 +13751,7 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
num_formats = ARRAY_SIZE(i965_primary_formats);
modifiers = i9xx_format_modifiers;
 
+   primary->max_stride = i9xx_plane_max_stride;
primary->update_plane = i9xx_update_plane;
primary->disable_plane = i9xx_disable_plane;
primary->get_hw_state = i9xx_plane_get_hw_state;
@@ -13719,6 +13762,7 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
num_formats = ARRAY_SIZE(i8xx_primary_formats);
modifiers = i9xx_format_modifiers;
 
+   primary->max_stride = i9xx_plane_max_stride;
primary->update_plane = i9xx_update_plane;
primary->disable_plane = i9xx_disable_plane;
primary->get_hw_state = i9xx_plane_get_hw_state;
@@ -13826,11 +13870,13 @@ intel_cursor_plane_create(struct drm_i915_private 
*dev_priv,
cursor->frontbuffer_bit = INTEL_FRONTBUFFER(pipe, cursor->id);
 
if (IS_I845G(dev_priv) || IS_I865G(dev_priv)) {
+   cursor->max_stride = i845_cursor_max_stride;
cursor->update_plane = i845_update_cursor;
cursor->disable_plane = i845_disable_cursor;
cursor->get_hw_state = i845_cursor_get_hw_state;
cursor->check_plane = i845_check_cursor;
} else {
+   cursor->max_stride = i9xx_cursor_max_stride;
cursor->update_plane = i9xx_update_cursor;
cursor->disable_plane = i9xx_disable_cursor;
cursor->get_hw_state = i9xx_cursor_get_hw_state;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v3,1/2] drm/i915/icl: move has_resource_streamer to GEN11_FEATURES

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/2] drm/i915/icl: move has_resource_streamer 
to GEN11_FEATURES
URL   : https://patchwork.freedesktop.org/series/46884/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915/icl: move has_resource_streamer to GEN11_FEATURES
Okay!

Commit: drm/i915: kill resource streamer
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3645:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3643:16: warning: expression 
using sizeof(void)

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Cache the error string (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Cache the error string (rev4)
URL   : https://patchwork.freedesktop.org/series/46777/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4513 -> Patchwork_9718 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/46777/revisions/4/mbox/

== Known issues ==

  Here are the changes found in Patchwork_9718 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_coherency:
  fi-gdg-551: PASS -> DMESG-FAIL (fdo#107164)

igt@drv_selftest@live_hangcheck:
  fi-skl-guc: PASS -> DMESG-FAIL (fdo#107174)

igt@drv_selftest@live_workarounds:
  {fi-cfl-8109u}: PASS -> DMESG-FAIL (fdo#107292)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927)


 Possible fixes 

igt@kms_frontbuffer_tracking@basic:
  fi-hsw-peppy:   DMESG-FAIL (fdo#106103, fdo#102614) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-snb-2520m:   INCOMPLETE (fdo#103713) -> PASS


  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
  fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103
  fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164
  fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
  fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292


== Participating hosts (47 -> 42) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4513 -> Patchwork_9718

  CI_DRM_4513: d592f2da0236d6d7ce4d4cccb40441c54dce5d91 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4568: 86f7b724ef18986bc58d35558d22e1ed3f8df4f9 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9718: f146b4a83eece6f2d42b30911d9fc6a922dff824 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

f146b4a83eec drm/i915: Cache the error string

== Logs ==

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

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: remove confusing GPIO vs PCH_GPIO

[De Marchi, Lucas]

CC'ing gvt maintainers (and fixing Jani's address in CC).

See below

On Wed, 2018-07-18 at 13:01 +0300, Ville Syrjälä wrote:
> On Tue, Jul 17, 2018 at 03:16:53PM -0700, Lucas De Marchi wrote:
> > On Fri, Jul 13, 2018 at 9:10 AM Ville Syrjälä
> >  wrote:
> > > 
> > > On Fri, Jul 13, 2018 at 08:42:11AM -0700, Lucas De Marchi wrote:
> > > > Instead of defining all registers twice, define just a PCH_GPIO_BASE
> > > > that has the same address as PCH_GPIO_A and use that to calculate all
> > > > the others. This also brings VLV and !HAS_GMCH_DISPLAY in line, doing
> > > > the same thing.
> > > > 
> > > > v2: Fix GMBUS registers to be relative to gpio base; create GPIO()
> > > > macro to return a particular gpio address and move the enum out of
> > > > i915_reg.h (suggested by Jani)
> > > > 
> > > > v3: Move base offset inside the GPIO() macro so the GMBUS defines
> > > > don't
> > > > actually need to be changed (suggested by Daniel/Ville)
> > > > 
> > > > Signed-off-by: Lucas De Marchi 
> > > > ---
> > > >  drivers/gpu/drm/i915/gvt/handlers.c |  2 +-
> > > >  drivers/gpu/drm/i915/i915_drv.h |  3 ++-
> > > >  drivers/gpu/drm/i915/i915_reg.h | 24 +---
> > > >  drivers/gpu/drm/i915/intel_drv.h| 16 
> > > >  drivers/gpu/drm/i915/intel_i2c.c| 12 
> > > >  5 files changed, 28 insertions(+), 29 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
> > > > b/drivers/gpu/drm/i915/gvt/handlers.c
> > > > index 7a58ca555197..ecff866bbbf1 100644
> > > > --- a/drivers/gpu/drm/i915/gvt/handlers.c
> > > > +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> > > > @@ -2118,7 +2118,7 @@ static int init_generic_mmio_info(struct
> > > > intel_gvt *gvt)
> > > > 
> > > >   MMIO_F(PCH_GMBUS0, 4 * 4, 0, 0, 0, D_ALL, gmbus_mmio_read,
> > > >   gmbus_mmio_write);
> > > > - MMIO_F(PCH_GPIOA, 6 * 4, F_UNALIGN, 0, 0, D_ALL, NULL, NULL);
> > > > + MMIO_F(GPIO(GPIOA), 6 * 4, F_UNALIGN, 0, 0, D_ALL, NULL, NULL);
> > > 
> > > I have no idea of gpio_mmio_base is populated correctly at this point
> > > for gvt, and I'm too lazy to find out.
> > 
> > humn, unfortunately it is not
> > 
> > i915_driver_load() -> i915_load_modeset_init() -> intel_setup_gmbus()
> > -> dev_priv->gpio_mmio_base = ...
> > i915_driver_load() -> i915_driver_init_hw() -> intel_gvt_init() ->
> > intel_gvt_init_device() -> intel_gvt_setup_mmio_info() ->
> > init_generic_mmio_info()
> > 
> > Is adding a single PCH_GPIO_BASE that doesn't depend on dev_priv being
> > populated for use on gvt an option?
> 
> IIRC gvt already has some local register defines (possibly due to this
> same reason?). Could add a few more I suppose. +cc the gvt folks to get
> their input.

Summary to gvt maintainers: I want to get rid of the multiple GPIO vs PCH_GPIO
defines we have today. For that I created the GPIO() macro, but it depends on
dev_priv being populated with the gpio's block offset already which is not
true while initializing gvt.

I can define a PCH_GPIO_BASE as above in i915_reg.h that is the same as
PCH_GPIOA today. Or define it in a private gvt header. Do you have another
option/suggestion?

thanks
Lucas De Marchi


> 
> > 
> > Lucas De Marchi
> > 
> > > 
> > > >   MMIO_F(_MMIO(0xe4f00), 0x28, 0, 0, 0, D_ALL, NULL, NULL);
> > > > 
> > > >   MMIO_F(_MMIO(_PCH_DPB_AUX_CH_CTL), 6 * 4, 0, 0, 0, D_PRE_SKL,
> > > > NULL,
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index b31d48cf7a69..596e734a874f 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -1611,7 +1611,8 @@ struct drm_i915_private {
> > > >   struct mutex gmbus_mutex;
> > > > 
> > > >   /**
> > > > -  * Base address of the gmbus and gpio block.
> > > > +  * Base address of where the gmbus and gpio blocks are located
> > > > (either
> > > > +  * on PCH or on SoC for platforms without PCH).
> > > >*/
> > > >   uint32_t gpio_mmio_base;
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > index 1f222af0324d..5e3ba9898f4e 100644
> > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > @@ -3089,18 +3089,9 @@ enum i915_power_well_id {
> > > >  /*
> > > >   * GPIO regs
> > > >   */
> > > > -#define GPIOA_MMIO(0x5010)
> > > > -#define GPIOB_MMIO(0x5014)
> > > > -#define GPIOC_MMIO(0x5018)
> > > > -#define GPIOD_MMIO(0x501c)
> > > > -#define GPIOE_MMIO(0x5020)
> > > > -#define GPIOF_MMIO(0x5024)
> > > > -#define GPIOG_MMIO(0x5028)
> > > > -#define GPIOH_MMIO(0x502c)
> > > > -#define GPIOJ_MMIO(0x5034)
> > > > -#define GPIOK_MMIO(0x5038)

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915: kill resource streamer

[Rodrigo Vivi]

On Thu, Jul 19, 2018 at 10:05:57AM -0700, Lucas De Marchi wrote:
> After disabling resource streamer on ICL (due to it actually not
> existing there), I got feedback that there have been some experimental
> patches for mesa to use RS years ago, but nothing ever landed or shipped
> because there was no performance improvement.
> 
> This removes it from kernel keeping the uapi defines around for
> compatibility.
> 
> v2: - re-add the inadvertent removal of CTX_CTRL_INHIBIT_SYN_CTX_SWITCH
> - don't bother trying to document removed params on uapi header:
>   applications should know that from the query.
>   (from Chris)
> 
> v3: - disable CTX_CTRL_RS_CTX_ENABLE istead of removing it
> - reword commit message after Daniele confirmed no performance
>   regression on his machine
> - reword commit message to make clear RS is being removed due to
>   never been used

thanks

> 
> Signed-off-by: Lucas De Marchi 
> Acked-by: Daniele Ceraolo Spurio 

Reviewed-by: Rodrigo Vivi 

(I will wait CI and then I will push)

> ---
>  drivers/gpu/drm/i915/i915_drv.c|  2 +-
>  drivers/gpu/drm/i915/i915_drv.h|  2 --
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 15 ++-
>  drivers/gpu/drm/i915/i915_pci.c|  4 
>  drivers/gpu/drm/i915/intel_device_info.h   |  1 -
>  drivers/gpu/drm/i915/intel_lrc.c   | 10 --
>  drivers/gpu/drm/i915/intel_ringbuffer.c|  4 +---
>  drivers/gpu/drm/i915/intel_ringbuffer.h|  1 -
>  8 files changed, 8 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 3834bd758a2e..b4b43402cc0c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -373,7 +373,7 @@ static int i915_getparam_ioctl(struct drm_device *dev, 
> void *data,
>   value = 2;
>   break;
>   case I915_PARAM_HAS_RESOURCE_STREAMER:
> - value = HAS_RESOURCE_STREAMER(dev_priv);
> + value = 0;
>   break;
>   case I915_PARAM_HAS_POOLED_EU:
>   value = HAS_POOLED_EU(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 4fb937399440..0b22ca0b24a8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2612,8 +2612,6 @@ intel_info(const struct drm_i915_private *dev_priv)
>  #define USES_GUC_SUBMISSION(dev_priv)
> intel_uc_is_using_guc_submission()
>  #define USES_HUC(dev_priv)   intel_uc_is_using_huc()
>  
> -#define HAS_RESOURCE_STREAMER(dev_priv) 
> ((dev_priv)->info.has_resource_streamer)
> -
>  #define HAS_POOLED_EU(dev_priv)  ((dev_priv)->info.has_pooled_eu)
>  
>  #define INTEL_PCH_DEVICE_ID_MASK 0xff80
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 1932bc227942..ca21a08b2be9 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -2221,19 +2221,8 @@ i915_gem_do_execbuffer(struct drm_device *dev,
>   if (!eb.engine)
>   return -EINVAL;
>  
> - if (args->flags & I915_EXEC_RESOURCE_STREAMER) {
> - if (!HAS_RESOURCE_STREAMER(eb.i915)) {
> - DRM_DEBUG("RS is only allowed for Haswell and Gen8 - 
> Gen10\n");
> - return -EINVAL;
> - }
> - if (eb.engine->id != RCS) {
> - DRM_DEBUG("RS is not available on %s\n",
> -  eb.engine->name);
> - return -EINVAL;
> - }
> -
> - eb.batch_flags |= I915_DISPATCH_RS;
> - }
> + if (args->flags & I915_EXEC_RESOURCE_STREAMER)
> + return -EINVAL;
>  
>   if (args->flags & I915_EXEC_FENCE_IN) {
>   in_fence = sync_file_get_fence(lower_32_bits(args->rsvd2));
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 3a4bb017d676..7b570ba90d9f 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -360,7 +360,6 @@ static const struct intel_device_info 
> intel_valleyview_info = {
>   .has_ddi = 1, \
>   .has_fpga_dbg = 1, \
>   .has_psr = 1, \
> - .has_resource_streamer = 1, \
>   .has_dp_mst = 1, \
>   .has_rc6p = 0 /* RC6p removed-by HSW */, \
>   .has_runtime_pm = 1
> @@ -433,7 +432,6 @@ static const struct intel_device_info 
> intel_cherryview_info = {
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
>   .has_64bit_reloc = 1,
>   .has_runtime_pm = 1,
> - .has_resource_streamer = 1,
>   .has_rc6 = 1,
>   .has_logical_ring_contexts = 1,
>   .has_gmch_display = 1,
> @@ -506,7 +504,6 @@ static const struct intel_device_info 
> intel_skylake_gt4_info = {
>   .has_runtime_pm = 1, \
>   .has_pooled_eu = 0, \
>   .has_csr = 1, \
> -   

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

[Rodrigo Vivi]

Hi Dave,

This is our final pull request for 4.19.

I was waiting some gvt pull that I had nacked for lack of review,
but that didn't came on time and it will have to wait for next-fixes
or later.

Here goes drm-intel-next-2018-07-19:
On GEM side:

- GuC related fixes (Chris, Michal)
- GTT read-only pages support (Jon, Chris)
- More selftests fixes (Chris)
- More GPU reset improvements (Chris)
- Flush caches after GGTT writes (Chris)
- Handle recursive shrinker for vma->last_active allocation (Chris)
- Other execlists fixes (Chris)

On Display side:

- GLK HDMI fix (Clint)
- Rework and cleanup around HPD pin (Ville)
- Preparation work for Display Stream Compression support coming on ICL (Anusha)
- Nuke LVDS lid notification (Ville)
- Assume eDP is always connected (Ville)
- Kill intel panel detection (Ville)

drm-intel-next-2018-07-12:
On GVT there's the addition of vGPU huge page support for guest,
with one BXT fix and gvt dependency handling.

On Display side there's:
- More PSR clean up and fixes (Rodrigo, DK and Tarun)
- GMBUS improvements for HDCP2.2 compliance (Ram)
- Fix strncpy truncation on intel_tv (Dominique)
- Cleanup modesetting on load-error path (Chris)

On GEM side:
- Gem init hw fix (Michal)
- More selftests fixes (Michal, Chris)
- Execlists optimizations (Chris)
- Introduce i915_address_space.mutex (Chris)
- Stolen memory support for Ice Lake (Paulo)
- Unwind HW init after GVT setup failure (Chris)
- Other fixes for gpu parking, gem_suspend, and handcheck reset (Chris)

Thanks,
Rodrigo.

The following changes since commit 82edc7e8b8c06151bdc653935bc13b83e2f0fcfa:

  drm/i915: Update DRIVER_DATE to 20180709 (2018-07-09 15:39:27 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2018-07-19

for you to fetch changes up to ef821e3f14e868779505bf08f96afb4eade53652:

  drm/i915: Update DRIVER_DATE to 20180719 (2018-07-19 08:47:59 -0700)


On GEM side:

- GuC related fixes (Chris, Michal)
- GTT read-only pages support (Jon, Chris)
- More selftests fixes (Chris)
- More GPU reset improvements (Chris)
- Flush caches after GGTT writes (Chris)
- Handle recursive shrinker for vma->last_active allocation (Chris)
- Other execlists fixes (Chris)

On Display side:

- GLK HDMI fix (Clint)
- Rework and cleanup around HPD pin (Ville)
- Preparation work for Display Stream Compression support coming on ICL (Anusha)
- Nuke LVDS lid notification (Ville)
- Assume eDP is always connected (Ville)
- Kill intel panel detection (Ville)


Anusha Srivatsa (4):
  drm/i915/icl: Add VIDEO_DIP registers
  i915/dp/dsc: Add DSC PPS register definitions
  i915/dp/dsc: Add Rate Control Buffer Threshold Registers
  i915/dp/dsc: Add Rate Control Range Parameter Registers

Changbin Du (14):
  drm/i915/gvt: Add new 64K entry type
  drm/i915/gvt: Add PTE IPS bit operations
  drm/i915/gvt: Handle MMIO GEN8_GAMW_ECO_DEV_RW_IA for 64K GTT
  drm/i915/gvt: Detect 64K gtt entry by IPS bit of PDE
  drm/i915/gvt: Add software PTE flag to mark special 64K splited entry
  drm/i915/gvt: Add GTT clear_pse operation
  drm/i915/gvt: Split ppgtt_alloc_spt into two parts
  drm/i915/gvt: Make PTE iterator 64K entry aware
  drm/i915/gvt: Add 64K huge gtt support
  drm/i915/kvmgt: Support setting dma map for huge pages
  drm/i915/gvt: Add 2M huge gtt support
  drm/i915/gvt: Handle special sequence on PDE IPS bit
  drm/i915/gvt: Fix error handling in ppgtt_populate_spt_by_guest_entry
  drm/i915: Enable platform support for vGPU huge gtt pages

Chris Wilson (34):
  drm/i915: Remove function details from device error messages
  drm/i915/selftests: Constrain mock_gtt tests to fit within RAM
  drm/i915/selftests: Filter out both physical address swizzles
  drm/i915: Only reset hangcheck at the start of an activity cycle
  drm/i915: Tidy i915_gem_suspend()
  drm/i915: Flush the residual parking on emergency shutdown
  drm/i915: Cleanup modesetting on load-error path
  drm/i915: Unwind HW init after GVT setup failure
  drm/i915: Introduce i915_address_space.mutex
  drm/i915/selftests: Add a safety net to live_workarounds
  drm/i915/execlists: Switch to rb_root_cached
  drm/i915: Silence warning for no vlv powercontext
  drm/i915/guc: Skip cleaning up the doorbells on error-before-allocate
  drm/i915/guc: Protect against NULL client dereference in error path
  drm/i915/gtt: Disable read-only support under GVT
  drm/i915: Prevent writing into a read-only object via a GGTT mmap
  drm/i915: Reject attempted pwrites into a read-only object
  drm/i915/userptr: Enable read-only support on gen8+
  drm/i915/guc: Protect against no desc-pool on premature shutdown
  drm/i915/selftests: Include the start of ea

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Cache the error string (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Cache the error string (rev4)
URL   : https://patchwork.freedesktop.org/series/46777/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915: Cache the error string
+drivers/gpu/drm/i915/i915_gpu_error.c:846:25: warning: Using plain integer as 
NULL pointer
+drivers/gpu/drm/i915/i915_gpu_error.c:910:23: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/i915_gpu_error.c:910:23: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/i915_sysfs.c:531:23: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/i915_sysfs.c:531:23: warning: expression using 
sizeof(void)

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

[Intel-gfx] [PATCH v3 2/2] drm/i915: kill resource streamer

[Lucas De Marchi]

After disabling resource streamer on ICL (due to it actually not
existing there), I got feedback that there have been some experimental
patches for mesa to use RS years ago, but nothing ever landed or shipped
because there was no performance improvement.

This removes it from kernel keeping the uapi defines around for
compatibility.

v2: - re-add the inadvertent removal of CTX_CTRL_INHIBIT_SYN_CTX_SWITCH
- don't bother trying to document removed params on uapi header:
  applications should know that from the query.
  (from Chris)

v3: - disable CTX_CTRL_RS_CTX_ENABLE istead of removing it
- reword commit message after Daniele confirmed no performance
  regression on his machine
- reword commit message to make clear RS is being removed due to
  never been used

Signed-off-by: Lucas De Marchi 
Acked-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_drv.c|  2 +-
 drivers/gpu/drm/i915/i915_drv.h|  2 --
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 15 ++-
 drivers/gpu/drm/i915/i915_pci.c|  4 
 drivers/gpu/drm/i915/intel_device_info.h   |  1 -
 drivers/gpu/drm/i915/intel_lrc.c   | 10 --
 drivers/gpu/drm/i915/intel_ringbuffer.c|  4 +---
 drivers/gpu/drm/i915/intel_ringbuffer.h|  1 -
 8 files changed, 8 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3834bd758a2e..b4b43402cc0c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -373,7 +373,7 @@ static int i915_getparam_ioctl(struct drm_device *dev, void 
*data,
value = 2;
break;
case I915_PARAM_HAS_RESOURCE_STREAMER:
-   value = HAS_RESOURCE_STREAMER(dev_priv);
+   value = 0;
break;
case I915_PARAM_HAS_POOLED_EU:
value = HAS_POOLED_EU(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4fb937399440..0b22ca0b24a8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2612,8 +2612,6 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define USES_GUC_SUBMISSION(dev_priv)  intel_uc_is_using_guc_submission()
 #define USES_HUC(dev_priv) intel_uc_is_using_huc()
 
-#define HAS_RESOURCE_STREAMER(dev_priv) 
((dev_priv)->info.has_resource_streamer)
-
 #define HAS_POOLED_EU(dev_priv)((dev_priv)->info.has_pooled_eu)
 
 #define INTEL_PCH_DEVICE_ID_MASK   0xff80
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 1932bc227942..ca21a08b2be9 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -2221,19 +2221,8 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (!eb.engine)
return -EINVAL;
 
-   if (args->flags & I915_EXEC_RESOURCE_STREAMER) {
-   if (!HAS_RESOURCE_STREAMER(eb.i915)) {
-   DRM_DEBUG("RS is only allowed for Haswell and Gen8 - 
Gen10\n");
-   return -EINVAL;
-   }
-   if (eb.engine->id != RCS) {
-   DRM_DEBUG("RS is not available on %s\n",
-eb.engine->name);
-   return -EINVAL;
-   }
-
-   eb.batch_flags |= I915_DISPATCH_RS;
-   }
+   if (args->flags & I915_EXEC_RESOURCE_STREAMER)
+   return -EINVAL;
 
if (args->flags & I915_EXEC_FENCE_IN) {
in_fence = sync_file_get_fence(lower_32_bits(args->rsvd2));
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 3a4bb017d676..7b570ba90d9f 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -360,7 +360,6 @@ static const struct intel_device_info intel_valleyview_info 
= {
.has_ddi = 1, \
.has_fpga_dbg = 1, \
.has_psr = 1, \
-   .has_resource_streamer = 1, \
.has_dp_mst = 1, \
.has_rc6p = 0 /* RC6p removed-by HSW */, \
.has_runtime_pm = 1
@@ -433,7 +432,6 @@ static const struct intel_device_info intel_cherryview_info 
= {
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.has_64bit_reloc = 1,
.has_runtime_pm = 1,
-   .has_resource_streamer = 1,
.has_rc6 = 1,
.has_logical_ring_contexts = 1,
.has_gmch_display = 1,
@@ -506,7 +504,6 @@ static const struct intel_device_info 
intel_skylake_gt4_info = {
.has_runtime_pm = 1, \
.has_pooled_eu = 0, \
.has_csr = 1, \
-   .has_resource_streamer = 1, \
.has_rc6 = 1, \
.has_dp_mst = 1, \
.has_logical_ring_contexts = 1, \
@@ -593,7 +590,6 @@ static const struct intel_device_info intel_cannonlake_info 
= {
GEN(11), \
.ddb_size = 2048, \
.has_csr = 0, \
-   

[Intel-gfx] [PATCH v3 1/2] drm/i915/icl: move has_resource_streamer to GEN11_FEATURES

[Lucas De Marchi]

Resource streamer has been removed on GEN11 so move it to the FEATURES
macro.

Signed-off-by: Lucas De Marchi 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
 drivers/gpu/drm/i915/i915_pci.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 3f0c612d42e7..1932bc227942 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -2223,7 +2223,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
 
if (args->flags & I915_EXEC_RESOURCE_STREAMER) {
if (!HAS_RESOURCE_STREAMER(eb.i915)) {
-   DRM_DEBUG("RS is only allowed for Haswell, Gen8 and 
above\n");
+   DRM_DEBUG("RS is only allowed for Haswell and Gen8 - 
Gen10\n");
return -EINVAL;
}
if (eb.engine->id != RCS) {
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 6a4d1388ad2d..3a4bb017d676 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -593,13 +593,13 @@ static const struct intel_device_info 
intel_cannonlake_info = {
GEN(11), \
.ddb_size = 2048, \
.has_csr = 0, \
+   .has_resource_streamer = 0, \
.has_logical_ring_elsq = 1
 
 static const struct intel_device_info intel_icelake_11_info = {
GEN11_FEATURES,
PLATFORM(INTEL_ICELAKE),
.is_alpha_support = 1,
-   .has_resource_streamer = 0,
.ring_mask = RENDER_RING | BLT_RING | VEBOX_RING | BSD_RING | BSD3_RING,
 };
 
-- 
2.17.1

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

Re: [Intel-gfx] [PATCH v3] drm/i915/dp: Give up link training clock recovery after 10 failed attempts

[Rodrigo Vivi]

On Tue, Jul 17, 2018 at 06:05:51PM -0700, Nathan Ciobanu wrote:
> On Tue, Jul 17, 2018 at 03:21:17PM -0700, Dhinakaran Pandiyan wrote:
> > On Mon, 2018-07-16 at 16:51 -0700, Marc Herbert wrote:
> > > > 
> > > > > 
> > > > > I think the bug is with this infinite loop which is at the mercy
> > > > > of an external device
> > > > > and in my case I have this MST hub which appears to be DP 1.2
> > > > > that triggers the
> > > > > infinite loop case. We have to limit the number of iterations and
> > > > > DP 1.4 spec happened to fix this issue. I'm a newbie in this area
> > > > > but in this case
> > > > > shouldn't we apply the same counter to all <= "DP 1.4" devices?
> > > > ok, the infinite loop situation is really bad... but I don't
> > > > believe
> > > > we are going with the right fix...
> > > > and a good indication is that your fix is for DP-1.4 while your bug
> > > > is seeing on DP-1.2
> > > I thought the only reason the infinite loop fix isn't in 1.2 is just
> > > because there's
> > > no 1.2.1 spec... (plus the naive assumption that buggy sinks don't
> > > exist)
> > > 
> > Irrespective of whether the sink is DP1.2 or 1.4, if there are sinks
> > out there that keep toggling between two values there should be an
> > overall limit to how many times this loop gets executed. Even if this
> > isn't right fix for the issue at hand, the loop has to break.
> > 
> > Then there's the question of what the limit should be. We could use the
> > DP1.4 limit as a reference and apply it widely. But there's a problem
> > here, we have 4 vswing values and 4 pre-emphasis values. If the sink
> > progressively changes one variable at a time, we'll need at least 16
> > iterations. Nathan's patch here will prematurely error out and that
> > doesn't sound reasonable to impose on non DP1.4 sinks.
> 
> I think it would be a max of 13 iterations since one of the vswing
> values will be max_vswing and the loop will terminate at that point
> without trying the other 3 preemph values for that voltage, correct?

I was talking to DK yesterday and he suggested that we should go with
a huge number for DP_1.2 and with the spec for DP_1.4. According to DK
80 was covering all combinations few times.

So you get your patch and create some max_cr_tries = dp_1.4 ? spec : 80;

or something like that.

I think I like that because infinite loop situation here is so bad
and we should avoid even if it was something else that got really wrong.

Thanks,
Rodrigo.

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

[Intel-gfx] [PATCH v4] drm/i915: Cache the error string

[Chris Wilson]

Currently, we convert the error state into a string every time we read
from sysfs (and sysfs reads in page size (4KiB) chunks). We do try to
window the string and only capture the portion that is being read, but
that means that we must always convert up to the window to find the
start. For a very large error state bordering on EXEC_OBJECT_CAPTURE
abuse, this is noticeable as it degrades to O(N^2)!

As we do not have a convenient hook for sysfs open(), and we would like
to keep the lazy conversion into a string, do the conversion of the
whole string on the first read and keep the string until the error state
is freed.

v2: Don't double advance simple_read_from_buffer
v3: Due to extreme pain of lack of vrealloc, use a scatterlist
v4: Keep the forward iterator loosely cached

Reported-by: Jason Ekstrand 
Testcase: igt/gem_exec_capture/many*
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Jason Ekstrand 
---
 drivers/gpu/drm/i915/i915_debugfs.c   |  32 +-
 drivers/gpu/drm/i915/i915_gpu_error.c | 402 +++---
 drivers/gpu/drm/i915/i915_gpu_error.h |  28 +-
 drivers/gpu/drm/i915/i915_sysfs.c |  27 +-
 4 files changed, 273 insertions(+), 216 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index b3aefd623557..543ac6bfb08a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -943,30 +943,28 @@ static int i915_gem_fence_regs_info(struct seq_file *m, 
void *data)
 static ssize_t gpu_state_read(struct file *file, char __user *ubuf,
  size_t count, loff_t *pos)
 {
-   struct i915_gpu_state *error = file->private_data;
-   struct drm_i915_error_state_buf str;
+   struct i915_gpu_state *error;
ssize_t ret;
-   loff_t tmp;
+   void *buf;
 
+   error = file->private_data;
if (!error)
return 0;
 
-   ret = i915_error_state_buf_init(&str, error->i915, count, *pos);
-   if (ret)
-   return ret;
-
-   ret = i915_error_state_to_str(&str, error);
-   if (ret)
-   goto out;
+   /* Bounce buffer required because of kernfs __user API convenience. */
+   buf = kmalloc(count, GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
 
-   tmp = 0;
-   ret = simple_read_from_buffer(ubuf, count, &tmp, str.buf, str.bytes);
-   if (ret < 0)
-   goto out;
+   ret = i915_gpu_state_copy_to_buffer(error, buf, *pos, count);
+   if (ret > 0) {
+   if (!copy_to_user(ubuf, buf, ret))
+   *pos += ret;
+   else
+   ret = -EFAULT;
+   }
 
-   *pos = str.start + ret;
-out:
-   i915_error_state_buf_release(&str);
+   kfree(buf);
return ret;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 8c81cf3aa182..b23416826598 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -28,6 +28,8 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -76,112 +78,110 @@ static const char *purgeable_flag(int purgeable)
return purgeable ? " purgeable" : "";
 }
 
-static bool __i915_error_ok(struct drm_i915_error_state_buf *e)
+static void __sg_set_buf(struct scatterlist *sg,
+void *addr, unsigned int len, loff_t it)
 {
-
-   if (!e->err && WARN(e->bytes > (e->size - 1), "overflow")) {
-   e->err = -ENOSPC;
-   return false;
-   }
-
-   if (e->bytes == e->size - 1 || e->err)
-   return false;
-
-   return true;
+   sg->page_link = (unsigned long)virt_to_page(addr);
+   sg->offset = offset_in_page(addr);
+   sg->length = len;
+   sg->dma_address = it;
 }
 
-static bool __i915_error_seek(struct drm_i915_error_state_buf *e,
- unsigned len)
+static bool __i915_error_grow(struct drm_i915_error_state_buf *e, size_t len)
 {
-   if (e->pos + len <= e->start) {
-   e->pos += len;
+   if (!len)
return false;
-   }
 
-   /* First vsnprintf needs to fit in its entirety for memmove */
-   if (len >= e->size) {
-   e->err = -EIO;
-   return false;
-   }
+   if (e->bytes + len + 1 > e->size) {
+   if (e->bytes) {
+   __sg_set_buf(e->cur++, e->buf, e->bytes, e->iter);
+   e->iter += e->bytes;
+   e->buf = NULL;
+   e->bytes = 0;
+   }
 
-   return true;
-}
+   if (e->cur == e->end) {
+   struct scatterlist *sgl;
 
-static void __i915_error_advance(struct drm_i915_error_state_buf *e,
-unsigned len)
-{
-   /* If this is first printf in this window, adjust it so that
-* start position matches start of the buffer
- 

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/perf_pmu: Restore runtime PM at subtest exit

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-07-19 17:37:56)
> From: Tvrtko Ursulin 
> 
> Restore runtime PM state (via a newly added library function) when the
> test which sets it up exit. This was we avoid running all subsequent sub-
> tests in the aggressive runtime PM mode.
> 
> Signed-off-by: Tvrtko Ursulin 
> ---
>  lib/igt_pm.c | 13 -
>  lib/igt_pm.h |  1 +
>  tests/perf_pmu.c |  3 +++
>  3 files changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/igt_pm.c b/lib/igt_pm.c
> index 8ac132269d79..2e2eea5d3b2d 100644
> --- a/lib/igt_pm.c
> +++ b/lib/igt_pm.c
> @@ -297,7 +297,13 @@ int pm_status_fd = -1;
>  static char __igt_pm_runtime_autosuspend[64];
>  static char __igt_pm_runtime_control[64];
>  
> -static void __igt_pm_runtime_exit_handler(int sig)
> +/**
> + * igt_restore_runtime_pm:
> + *
> + * Restores the runtime PM configuration as it was before the call to
> + * igt_setup_runtime_pm.
> + */
> +void igt_restore_runtime_pm(void)
>  {
> int fd;

Should we eat __igt_pm_runtime_autosuspend so we only apply it once for
each igt_setup_runtime_pm?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] tests/perf_pmu: Restore runtime PM at subtest exit

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Restore runtime PM state (via a newly added library function) when the
test which sets it up exit. This was we avoid running all subsequent sub-
tests in the aggressive runtime PM mode.

Signed-off-by: Tvrtko Ursulin 
---
 lib/igt_pm.c | 13 -
 lib/igt_pm.h |  1 +
 tests/perf_pmu.c |  3 +++
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/lib/igt_pm.c b/lib/igt_pm.c
index 8ac132269d79..2e2eea5d3b2d 100644
--- a/lib/igt_pm.c
+++ b/lib/igt_pm.c
@@ -297,7 +297,13 @@ int pm_status_fd = -1;
 static char __igt_pm_runtime_autosuspend[64];
 static char __igt_pm_runtime_control[64];
 
-static void __igt_pm_runtime_exit_handler(int sig)
+/**
+ * igt_restore_runtime_pm:
+ *
+ * Restores the runtime PM configuration as it was before the call to
+ * igt_setup_runtime_pm.
+ */
+void igt_restore_runtime_pm(void)
 {
int fd;
 
@@ -326,6 +332,11 @@ static void __igt_pm_runtime_exit_handler(int sig)
close(fd);
 }
 
+static void __igt_pm_runtime_exit_handler(int sig)
+{
+   igt_restore_runtime_pm();
+}
+
 /**
  * igt_setup_runtime_pm:
  *
diff --git a/lib/igt_pm.h b/lib/igt_pm.h
index eced39f8801a..10cc6794e4e7 100644
--- a/lib/igt_pm.h
+++ b/lib/igt_pm.h
@@ -47,6 +47,7 @@ enum igt_runtime_pm_status {
 };
 
 bool igt_setup_runtime_pm(void);
+void igt_restore_runtime_pm(void);
 enum igt_runtime_pm_status igt_get_runtime_pm_status(void);
 bool igt_wait_for_pm_status(enum igt_runtime_pm_status status);
 
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index a1d36ac4fa9d..9a20abb6b95c 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -1441,6 +1441,9 @@ test_rc6(int gem_fd, unsigned int flags)
close(fw);
close(fd);
 
+   if (flags & TEST_RUNTIME_PM)
+   igt_restore_runtime_pm();
+
assert_within_epsilon(busy - prev, 0.0, tolerance);
 }
 
-- 
2.17.1

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

Re: [Intel-gfx] [PATCH v5 11/13] drm/i915/icl: Add macros for MMIO of DSI transcoder registers

[Ville Syrjälä]

On Tue, Jul 10, 2018 at 03:10:12PM +0530, Madhav Chauhan wrote:
> This patch adds _MMIO_DSI and _DSI_TRANS macros for accessing
> DSI transcoder registers.
> 
> Credits-to: Jani N
> 
> Cc: Jani Nikula 
> Signed-off-by: Madhav Chauhan 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 1d13ba9..62bc76e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9576,6 +9576,11 @@ enum skl_power_gate {
>  #define _MIPI_PORT(port, a, c)   (((port) == PORT_A) ? a : c)/* 
> ports A and C only */
>  #define _MMIO_MIPI(port, a, c)   _MMIO(_MIPI_PORT(port, a, c))
>  
> +/* gen11 DSI */
> +#define _DSI_TRANS(tc, dsi0, dsi1)   (((tc) == TRANSCODER_DSI_0) ?   \
> +  (dsi0) : (dsi1))

_PIPE() etc. should result in slughtly better code IIRC.

> +#define _MMIO_DSI(tc, dsi0, dsi1)_MMIO(_DSI_TRANS(tc, dsi0, dsi1))
> +
>  #define MIPIO_TXESC_CLK_DIV1 _MMIO(0x160004)
>  #define  GLK_TX_ESC_CLK_DIV1_MASK0x3FF
>  #define MIPIO_TXESC_CLK_DIV2 _MMIO(0x160008)
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH v5 09/13] drm/i915/icl: Program TA_TIMING_PARAM registers

[Ville Syrjälä]

On Tue, Jul 10, 2018 at 03:10:10PM +0530, Madhav Chauhan wrote:
> This patch programs D-PHY timing parameters for the
> bus turn around flow(in escape clocks) only if dsi link
> frequency <=800 MHz using DPHY_TA_TIMING_PARAM and its
> identical register DSI_TA_TIMING_PARAM (inside DSI
> Controller within the Display Core).
> 
> Signed-off-by: Madhav Chauhan 
> ---
>  drivers/gpu/drm/i915/icl_dsi.c   | 21 +
>  drivers/gpu/drm/i915/intel_dsi.h |  1 +
>  drivers/gpu/drm/i915/intel_dsi_vbt.c |  1 +
>  3 files changed, 23 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
> index 832772d..8fd5284 100644
> --- a/drivers/gpu/drm/i915/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/icl_dsi.c
> @@ -302,6 +302,27 @@ static void gen11_dsi_setup_dphy_timings(struct 
> intel_encoder *encoder)
>   I915_WRITE(DSI_DATA_TIMING_PARAM(port),
>  intel_dsi->dphy_data_lane_reg);
>   }
> +
> + /*
> +  * If DSI link operating at or below an 800 MHz,
> +  * TA_SURE should be override and programmed to
> +  * a value '0' inside TA_PARAM_REGISTERS otherwise
> +  * leave all fields at HW default values.
> +  */
> + if (intel_dsi->bitrate_khz <= KHz(800)) {

The KHz(800) confuses me. My brain thinks this value is 800 kHz when
it's not. So I'd write it without the KHz() macro.

> + for_each_dsi_port(port, intel_dsi->ports) {
> + tmp = I915_READ(DPHY_TA_TIMING_PARAM(port));
> + tmp &= ~TA_SURE_TIME_MASK;
> + tmp |= (TA_SURE_OVERRIDE | TA_SURE_TIME(0));
> + I915_WRITE(DPHY_TA_TIMING_PARAM(port), tmp);
> +
> + /* shadow register inside display core */
> + tmp = I915_READ(DSI_TA_TIMING_PARAM(port));
> + tmp &= ~TA_SURE_TIME_MASK;
> + tmp |= (TA_SURE_OVERRIDE | TA_SURE_TIME(0));
> + I915_WRITE(DSI_TA_TIMING_PARAM(port), tmp);
> + }
> + }
>  }
>  
>  static void gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder)
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h 
> b/drivers/gpu/drm/i915/intel_dsi.h
> index 9fd8526..25e7396 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -101,6 +101,7 @@ struct intel_dsi {
>  
>   u16 init_count;
>   u32 pclk;
> + u32 bitrate_khz;
>   u16 burst_mode_ratio;
>  
>   /* all delays in ms */
> diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_vbt.c
> index 428290d..a9a98a4 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
> @@ -589,6 +589,7 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 
> panel_id)
>   intel_dsi->pclk = pclk;
>  
>   bitrate = (pclk * bpp) / intel_dsi->lane_count;
> + intel_dsi->bitrate_khz = bitrate;
>  
>   switch (intel_dsi->escape_clk_div) {
>   case 0:
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH v5 07/13] drm/i915/icl: Program DSI clock and data lane timing params

[Ville Syrjälä]

On Tue, Jul 10, 2018 at 03:10:08PM +0530, Madhav Chauhan wrote:
> This patch programs D-PHY timing parameters for the
> clock and data lane (in escape clocks) of DSI
> controller (DSI port 0 and 1).
> These programmed timings would be used by DSI Controller
> to calculate link transition latencies of the data and
> clock lanes.
> 
> Signed-off-by: Madhav Chauhan 
> ---
>  drivers/gpu/drm/i915/icl_dsi.c   |  18 
>  drivers/gpu/drm/i915/intel_dsi.h |   3 +
>  drivers/gpu/drm/i915/intel_dsi_vbt.c | 200 
> +--
>  3 files changed, 165 insertions(+), 56 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
> index bc27e34..832772d 100644
> --- a/drivers/gpu/drm/i915/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/icl_dsi.c
> @@ -284,6 +284,24 @@ static void gen11_dsi_setup_dphy_timings(struct 
> intel_encoder *encoder)
>   tmp |= intel_dsi->init_count;
>   I915_WRITE(ICL_DSI_T_INIT_MASTER(port), tmp);
>   }
> +
> + /* Program DPHY clock lanes timings */
> + for_each_dsi_port(port, intel_dsi->ports) {
> + I915_WRITE(DPHY_CLK_TIMING_PARAM(port), intel_dsi->dphy_reg);
> +
> + /* shadow register inside display core */
> + I915_WRITE(DSI_CLK_TIMING_PARAM(port), intel_dsi->dphy_reg);
> + }
> +
> + /* Program DPHY data lanes timings */
> + for_each_dsi_port(port, intel_dsi->ports) {
> + I915_WRITE(DPHY_DATA_TIMING_PARAM(port),
> +intel_dsi->dphy_data_lane_reg);
> +
> + /* shadow register inside display core */
> + I915_WRITE(DSI_DATA_TIMING_PARAM(port),
> +intel_dsi->dphy_data_lane_reg);
> + }
>  }
>  
>  static void gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder)
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h 
> b/drivers/gpu/drm/i915/intel_dsi.h
> index ad7c1cb..9fd8526 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -85,6 +85,9 @@ struct intel_dsi {
>   u32 port_bits;
>   u32 bw_timer;
>   u32 dphy_reg;
> +
> + /* data lanes dphy timing */
> + u32 dphy_data_lane_reg;
>   u32 video_frmt_cfg_bits;
>   u16 lp_byte_clk;
>  
> diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_vbt.c
> index ac83d6b..428290d 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
> @@ -509,7 +509,9 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 
> panel_id)
>   u32 bpp;
>   u32 tlpx_ns, extra_byte_count, bitrate, tlpx_ui;
>   u32 ui_num, ui_den;
> - u32 prepare_cnt, exit_zero_cnt, clk_zero_cnt, trail_cnt;
> + u32 prepare_cnt, exit_zero_cnt, clk_zero_cnt, trail_cnt, hs_zero_cnt;
> + u32 tclk_pre_cnt, tclk_post_cnt;
> + u32 tclk_pre_ns, tclk_post_ns;
>   u32 ths_prepare_ns, tclk_trail_ns;
>   u32 tclk_prepare_clkzero, ths_prepare_hszero;
>   u32 lp_to_hs_switch, hs_to_lp_switch;
> @@ -624,76 +626,157 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, 
> u16 panel_id)
>  
>   tclk_prepare_clkzero = mipi_config->tclk_prepare_clkzero;
>   ths_prepare_hszero = mipi_config->ths_prepare_hszero;
> -
> + tclk_trail_ns = max(mipi_config->tclk_trail, mipi_config->ths_trail);
> + ths_prepare_ns = max(mipi_config->ths_prepare,
> + mipi_config->tclk_prepare);
>   /*
>* B060
>* LP byte clock = TLPX/ (8UI)
>*/
>   intel_dsi->lp_byte_clk = DIV_ROUND_UP(tlpx_ns * ui_den, 8 * ui_num);
>  
> - /* DDR clock period = 2 * UI
> -  * UI(sec) = 1/(bitrate * 10^3) (bitrate is in KHZ)
> -  * UI(nsec) = 10^6 / bitrate
> -  * DDR clock period (nsec) = 2 * UI = (2 * 10^6)/ bitrate
> -  * DDR clock count  = ns_value / DDR clock period
> -  *
> + /*
>* For GEMINILAKE dphy_param_reg will be programmed in terms of
>* HS byte clock count for other platform in HS ddr clock count
>*/
>   mul = IS_GEMINILAKE(dev_priv) ? 8 : 2;
> - ths_prepare_ns = max(mipi_config->ths_prepare,
> -  mipi_config->tclk_prepare);
>  
> - /* prepare count */
> - prepare_cnt = DIV_ROUND_UP(ths_prepare_ns * ui_den, ui_num * mul);
> + if (IS_ICELAKE(dev_priv)) {

I'd suggest extracting the icl vs. old things into separate functions.

> + /*
> +  * prepare cnt in escape clocks
> +  * this field represents a hexadecimal value with a precision
> +  * of 1.2 – i.e. the most significant bit is the integer
> +  * and the least significant 2 bits are fraction bits.
> +  * so, the field can represent a range of 0.25 to 1.75
> +  */
> + prepare_cnt = DIV_ROUND_UP(ths_prepare_ns * 4, tlpx_ns);
> +
> + /* clk zero count in escape clocks */
> + clk_zero_cnt = DIV_ROU

Re: [Intel-gfx] [PATCH v5 01/13] drm/i915/icl: Configure lane sequencing of combo phy transmitter

[Ville Syrjälä]

On Tue, Jul 10, 2018 at 03:10:02PM +0530, Madhav Chauhan wrote:
> This patch set the loadgen select and latency optimization for
> aux and transmit lanes of combo phy transmitters. It will be
> used for MIPI DSI HS operations.
> 
> v2: Rebase
> 
> Signed-off-by: Madhav Chauhan 
> ---
>  drivers/gpu/drm/i915/icl_dsi.c | 38 ++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
> index 13830e4..a571339 100644
> --- a/drivers/gpu/drm/i915/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/icl_dsi.c
> @@ -105,10 +105,48 @@ static void gen11_dsi_power_up_lanes(struct 
> intel_encoder *encoder)
>   }
>  }
>  
> +static void gen11_dsi_config_phy_lanes_sequence(struct intel_encoder 
> *encoder)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
> + enum port port;
> + u32 tmp;
> + int lane;

tmp/lane could be moved to into the loops.

Same in other patches.

> +
> + /* Step 4b(i) set loadgen select for transmit and aux lanes */
> + for_each_dsi_port(port, intel_dsi->ports) {
> + tmp = I915_READ(ICL_PORT_TX_DW4_AUX(port));
> + tmp &= ~LOADGEN_SELECT;
> + I915_WRITE(ICL_PORT_TX_DW4_AUX(port), tmp);
> + for (lane = 0; lane <= 3; lane++) {
> + tmp = I915_READ(ICL_PORT_TX_DW4_LN(port, lane));
> + tmp &= ~LOADGEN_SELECT;
> + if (lane != 2)
> + tmp |= LOADGEN_SELECT;
> + I915_WRITE(ICL_PORT_TX_DW4_LN(port, lane), tmp);
> + }
> + }
> +
> + /* Step 4b(ii) set latency optimization for transmit and aux lanes */
> + for_each_dsi_port(port, intel_dsi->ports) {
> + tmp = I915_READ(ICL_PORT_TX_DW2_AUX(port));
> + tmp &= ~FRC_LATENCY_OPTIM_MASK;
> + tmp |= FRC_LATENCY_OPTIM_VAL(0x5);
> + I915_WRITE(ICL_PORT_TX_DW2_AUX(port), tmp);
> + tmp = I915_READ(ICL_PORT_TX_DW2_LN0(port));
> + tmp &= ~FRC_LATENCY_OPTIM_MASK;
> + tmp |= FRC_LATENCY_OPTIM_VAL(0x5);
> + I915_WRITE(ICL_PORT_TX_DW2_GRP(port), tmp);
> + }

An empty line here and there would make this a bit more legible.

Same in other patches.

> +}
> +
>  static void gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder)
>  {
>   /* step 4a: power up all lanes of the DDI used by DSI */
>   gen11_dsi_power_up_lanes(encoder);
> +
> + /* step 4b: configure lane sequencing of the Combo-PHY transmitters */
> + gen11_dsi_config_phy_lanes_sequence(encoder);
>  }
>  
>  static void __attribute__((unused))
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gtt: Enable full-ppgtt by default everywhere

[Chris Wilson]

Quoting Kenneth Graunke (2018-07-17 21:02:33)
> On Tuesday, July 17, 2018 2:57:50 AM PDT Chris Wilson wrote:
> > We should we have all the kinks worked out and full-ppgtt now works
> > reliably on gen7 (Ivybridge, Valleyview/Baytrail and Haswell). If we can
> > let userspace have full control over their own ppgtt, it makes softpinning
> > far more effective, in turn making GPU dispatch far more efficient by
> > virtue of better mm segregation.  On the other hand, switching over to a
> > different GTT for every client does incur noticeable overhead, but only
> > for very lightweight tasks.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Joonas Lahtinen 
> > Cc: Mika Kuoppala 
> > Cc: Matthew Auld 
> > Reviewed-by: Joonas Lahtinen 
> > Cc: Jason Ekstrand 
> > Cc: Kenneth Graunke 
> > ---
> >  drivers/gpu/drm/i915/i915_gem_gtt.c | 10 --
> >  1 file changed, 4 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index f00c7fbef79e..9bad73332ce7 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -179,13 +179,11 @@ int intel_sanitize_enable_ppgtt(struct 
> > drm_i915_private *dev_priv,
> >   return 0;
> >   }
> >  
> > - if (HAS_LOGICAL_RING_CONTEXTS(dev_priv)) {
> > - if (has_full_48bit_ppgtt)
> > - return 3;
> > + if (has_full_48bit_ppgtt)
> > + return 3;
> >  
> > - if (has_full_ppgtt)
> > - return 2;
> > - }
> > + if (has_full_ppgtt)
> > + return 2;
> >  
> >   return 1;
> >  }
> > 
> 
> I'm very glad to see this land, PPGTT is really important for security.
> It may also enable us to do more interesting things on Gen7.x.
> 
> Acked-by: Kenneth Graunke 

Plonked in. If I timed it right, it should have just missed the 4.19
cutoff, so we have the best part of 6 months to detect any damage.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6] drm/i915: Add IOCTL Param to control data port coherency.

[Lis, Tomasz]

On 2018-07-19 09:12, Joonas Lahtinen wrote:

Quoting Lis, Tomasz (2018-07-18 18:28:32)

On 2018-07-18 16:42, Tvrtko Ursulin wrote:

On 18/07/2018 14:24, Joonas Lahtinen wrote:

Quoting Tomasz Lis (2018-07-16 16:07:16)




+++ b/include/uapi/drm/i915_drm.h
@@ -1456,6 +1456,13 @@ struct drm_i915_gem_context_param {
   #define   I915_CONTEXT_MAX_USER_PRIORITY   1023 /* inclusive */
   #define   I915_CONTEXT_DEFAULT_PRIORITY    0
   #define   I915_CONTEXT_MIN_USER_PRIORITY   -1023 /* inclusive */
+/*
+ * When data port level coherency is enabled, the GPU will update
memory
+ * buffers shared with CPU, by forcing internal cache units to send
memory
+ * writes to higher level caches faster. Enabling data port
coherency has
+ * a performance cost.
+ */

I was under impression this is enabled by default and it can be disabled
for a performance optimization?

This is true, coherency is kept by default. We disable it as a
workaround: performance-related for gen11, and due to minor hardware
issue on previous platforms. See WaForceEnableNonCoherent.

Ok, then you definitely want to rephrase the comment to bake that
information in it. Now it sounds like it needs to be turned on to have
coherency.

I'm not sure if I understand what you're asking for.
Should I emphasize that the feature is disabled unless the flag is set? 
This seem obvious...
Or should I provide the reason why it is disabled on specific platforms? 
This should probably be done within workaround setup, not in user api 
definition. Or maybe it's enough to have it in Bspec? Bspec links are 
provided in the patch.

Or should I just mention the workaround name?
-Tomasz

Regards, Joonas


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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Move the assertion we have the rpm wakeref down

[Patchwork]

== Series Details ==

Series: drm/i915/execlists: Move the assertion we have the rpm wakeref down
URL   : https://patchwork.freedesktop.org/series/46837/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4509_full -> Patchwork_9716_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9716_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9716_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_9716_full:

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-bsd2:
  shard-kbl:  PASS -> SKIP +2

igt@gem_exec_schedule@deep-vebox:
  shard-kbl:  SKIP -> PASS


== Known issues ==

  Here are the changes found in Patchwork_9716_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_hangcheck:
  shard-kbl:  PASS -> DMESG-FAIL (fdo#106947, fdo#106560)

igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
  shard-glk:  PASS -> FAIL (fdo#105363)


 Possible fixes 

igt@kms_setmode@basic:
  shard-kbl:  FAIL (fdo#99912) -> PASS


  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
  fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4509 -> Patchwork_9716

  CI_DRM_4509: e84aa0b47beed78a5a12db93e76fb00eab5db160 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4567: 7f85adc4050182f490c7a5c48db3d57cdb00af4e @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9716: 6347bf8a6dc3e4205b7cf39cb93f3c5590270c11 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

Re: [Intel-gfx] [alsa-devel] [PATCH v2 0/3] Make the audio component binding more generic

[Pierre-Louis Bossart]

On 7/19/18 12:50 AM, Takashi Iwai wrote:

On Wed, 18 Jul 2018 22:54:35 +0200,
Pierre-Louis Bossart wrote:




On 07/17/2018 04:26 AM, Takashi Iwai wrote:

Hi,

this is a preliminiary patch set to convert the existing i915 /
HD-audio component binding to be applicable to other drivers like
radeon / amdgpu.  This patchset itself doesn't change the
functionality but only renames and split to a new drm_audio_component
stuff from i915_audio_component.

The actual usage of the new API will follow once after this one gets
reviewed / accepted.  The whole patches (including this patchset) are
found in topic/hda-acomp branch of sound.git tree.

BTW, since the whole stuff is about the audio binding, I suppose these
will go through sound git tree.  Let me know if anyone has concerns.

No objections but a slight concern that this will conflict with the
HDAudio+DSP patches that I was about to resubmit on top of your
topic/hda-core-intel branch. the two series touch the same files so
it'd be a miracle if there is no issue.
How do you want to deal with this?


Does it conflict severely?  If it's trivial, it can be resolved at
merge time, too.  The changes in my patchset are fairly trivial, so it
shouldn't be too hard.


I was able to make things work by taking your topic/hda-core-intel, 
merge it on Mark's for-next, then add my additional changes and these 
DRM changes. The last two can be done in any order. But I am getting 
some conflicts if I try to apply these DRM changes first, not sure why 
git is complaining though, the changes look trivial enough.
So yes it looks possible to deal with the two series in parallel, will 
send my update later today.

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/kvmgt: fix an error code in gvt_dma_map_page()

[Patchwork]

== Series Details ==

Series: drm/i915/kvmgt: fix an error code in gvt_dma_map_page()
URL   : https://patchwork.freedesktop.org/series/46842/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4508_full -> Patchwork_9715_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9715_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9715_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_9715_full:

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-render:
  shard-kbl:  PASS -> SKIP

igt@perf_pmu@rc6:
  shard-kbl:  SKIP -> PASS


== Known issues ==

  Here are the changes found in Patchwork_9715_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@drv_suspend@shrink:
  shard-apl:  PASS -> INCOMPLETE (fdo#106886, fdo#103927)

igt@gem_ppgtt@blt-vs-render-ctx0:
  shard-kbl:  PASS -> INCOMPLETE (fdo#103665, fdo#106023)

igt@kms_flip@2x-flip-vs-expired-vblank:
  shard-glk:  PASS -> FAIL (fdo#105189)

igt@kms_flip@flip-vs-expired-vblank-interruptible:
  shard-glk:  PASS -> FAIL (fdo#102887, fdo#105363)


 Possible fixes 

igt@kms_flip@plain-flip-fb-recreate:
  shard-glk:  FAIL (fdo#100368) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
  fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4508 -> Patchwork_9715

  CI_DRM_4508: 4bc82527792ee034b77349b5027b90121c93ad49 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4567: 7f85adc4050182f490c7a5c48db3d57cdb00af4e @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9715: d9c44f344a040452ea91ebe6c60d33afc69ac4f0 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,1/5] drm/i915/guc: Fix GuC pin bias and WOPCM initialization order

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/5] drm/i915/guc: Fix GuC pin bias and WOPCM 
initialization order
URL   : https://patchwork.freedesktop.org/series/46843/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4510 -> Patchwork_9717 =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_9717 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9717, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/46843/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_9717:

  === IGT changes ===

 Possible regressions 

igt@drv_selftest@live_guc:
  fi-kbl-7567u:   PASS -> DMESG-WARN
  fi-skl-gvtdvm:  PASS -> DMESG-WARN
  fi-bxt-dsi: NOTRUN -> DMESG-WARN
  fi-whl-u:   PASS -> DMESG-WARN
  fi-kbl-7560u:   PASS -> DMESG-WARN
  fi-kbl-r:   PASS -> DMESG-WARN
  fi-kbl-x1275:   PASS -> DMESG-WARN
  fi-bxt-j4205:   PASS -> DMESG-WARN
  fi-cfl-s3:  PASS -> DMESG-WARN
  {fi-cfl-8109u}: PASS -> DMESG-WARN
  fi-kbl-7500u:   PASS -> DMESG-WARN
  fi-cfl-8700k:   PASS -> DMESG-WARN

igt@drv_selftest@live_hangcheck:
  fi-skl-gvtdvm:  PASS -> DMESG-FAIL
  fi-cfl-s3:  PASS -> DMESG-FAIL
  fi-bxt-dsi: NOTRUN -> DMESG-FAIL
  fi-bxt-j4205:   PASS -> DMESG-FAIL
  {fi-skl-iommu}: PASS -> DMESG-FAIL +1


 Warnings 

igt@drv_selftest@live_guc:
  {fi-skl-iommu}: PASS -> SKIP +1


== Known issues ==

  Here are the changes found in Patchwork_9717 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_guc:
  fi-skl-6600u:   PASS -> DMESG-WARN (fdo#107175)
  fi-skl-6260u:   PASS -> DMESG-WARN (fdo#107175)
  fi-skl-6700k2:  PASS -> DMESG-WARN (fdo#107175)
  fi-skl-6770hq:  PASS -> DMESG-WARN (fdo#107175)
  fi-skl-6700hq:  PASS -> DMESG-WARN (fdo#107175)

igt@drv_selftest@live_hangcheck:
  fi-skl-6770hq:  PASS -> DMESG-FAIL (fdo#107174)


 Possible fixes 

igt@debugfs_test@read_all_entries:
  fi-snb-2520m:   INCOMPLETE (fdo#103713) -> PASS

igt@drv_selftest@live_workarounds:
  fi-bdw-5557u:   DMESG-FAIL -> PASS
  fi-skl-6700hq:  DMESG-FAIL -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS


  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
  fdo#107175 https://bugs.freedesktop.org/show_bug.cgi?id=107175


== Participating hosts (47 -> 42) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4510 -> Patchwork_9717

  CI_DRM_4510: 31b9b285a571eda0db7a8fd5206d48fcdd0190b3 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4568: 86f7b724ef18986bc58d35558d22e1ed3f8df4f9 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9717: 2306b20a6dea3a4f224d21c00f312f89d216e426 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

2306b20a6dea HAX enable GuC for CI
0fa25edf61e9 drm/i915: Add a fault injection point after WOPCM init
eb5bfd46972b drm/i915: Remove unnecessary ggtt_offset_bias from i915_gem_context
e9dda8797e50 drm/i915/guc: Move the pin bias value from GuC to GGTT
5b24a0eaa5b5 drm/i915/guc: Fix GuC pin bias and WOPCM initialization order

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Move the assertion we have the rpm wakeref down

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-07-19 13:14:38)
> 
> On 19/07/2018 12:59, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-07-19 12:49:13)
> >>
> >> On 19/07/2018 08:50, Chris Wilson wrote:
> >>> There's a race between idling the engine and finishing off the last
> >>> tasklet (as we may kick the tasklets after declaring an individual
> >>> engine idle). However, since we do not need to access the device until
> >>> we try to submit to the ELSP register (processing the CSB just requires
> >>> normal CPU access to the HWSP, and when idle we should not need to
> >>> submit!) we can defer the assertion unto that point. The assertion is
> >>> still useful as it does verify that we do hold the longterm GT wakeref
> >>> taken from request allocation until request completion.
> >>>
> >>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107274
> >>> Fixes: 9512f985c32d ("drm/i915/execlists: Direct submission of new 
> >>> requests (avoid tasklet/ksoftirqd)")
> >>> Signed-off-by: Chris Wilson 
> >>> Cc: Tvrtko Ursulin 
> >>> ---
> >>>drivers/gpu/drm/i915/intel_lrc.c | 25 +++--
> >>>1 file changed, 11 insertions(+), 14 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> >>> b/drivers/gpu/drm/i915/intel_lrc.c
> >>> index db5351e6a3a5..9d693e61536c 100644
> >>> --- a/drivers/gpu/drm/i915/intel_lrc.c
> >>> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> >>> @@ -452,6 +452,16 @@ static void execlists_submit_ports(struct 
> >>> intel_engine_cs *engine)
> >>>struct execlist_port *port = execlists->port;
> >>>unsigned int n;
> >>>
> >>> + /*
> >>> +  * We can skip acquiring intel_runtime_pm_get() here as it was taken
> >>> +  * on our behalf by the request (see i915_gem_mark_busy()) and it 
> >>> will
> >>> +  * not be relinquished until the device is idle (see
> >>> +  * i915_gem_idle_work_handler()). As a precaution, we make sure
> >>> +  * that all ELSP are drained i.e. we have processed the CSB,
> >>> +  * before allowing ourselves to idle and calling 
> >>> intel_runtime_pm_put().
> >>> +  */
> >>> + GEM_BUG_ON(!engine->i915->gt.awake);
> >>> +
> >>>/*
> >>> * ELSQ note: the submit queue is not cleared after being submitted
> >>> * to the HW so we need to make sure we always clean it up. This is
> >>> @@ -1043,16 +1053,6 @@ static void __execlists_submission_tasklet(struct 
> >>> intel_engine_cs *const engine)
> >>>{
> >>>lockdep_assert_held(&engine->timeline.lock);
> >>>
> >>> - /*
> >>> -  * We can skip acquiring intel_runtime_pm_get() here as it was taken
> >>> -  * on our behalf by the request (see i915_gem_mark_busy()) and it 
> >>> will
> >>> -  * not be relinquished until the device is idle (see
> >>> -  * i915_gem_idle_work_handler()). As a precaution, we make sure
> >>> -  * that all ELSP are drained i.e. we have processed the CSB,
> >>> -  * before allowing ourselves to idle and calling 
> >>> intel_runtime_pm_put().
> >>> -  */
> >>> - GEM_BUG_ON(!engine->i915->gt.awake);
> >>> -
> >>>process_csb(engine);
> >>>if (!execlists_is_active(&engine->execlists, 
> >>> EXECLISTS_ACTIVE_PREEMPT))
> >>>execlists_dequeue(engine);
> >>> @@ -1073,10 +1073,7 @@ static void execlists_submission_tasklet(unsigned 
> >>> long data)
> >>>  engine->execlists.active);
> >>>
> >>>spin_lock_irqsave(&engine->timeline.lock, flags);
> >>> -
> >>> - if (engine->i915->gt.awake) /* we may be delayed until after we 
> >>> idle! */
> >>> - __execlists_submission_tasklet(engine);
> >>> -
> >>> + __execlists_submission_tasklet(engine);
> >>>spin_unlock_irqrestore(&engine->timeline.lock, flags);
> >>>}
> >>>
> >>>
> >>
> >> Why we won't hit the assert on the elsp submit side now? AFAIR the
> >> discussion about this particular line concluded that direct tasklet call
> >> can race with busy->idle transition. So even is process_csb doens't need
> >> the assert, that part I get, the part about the race now again bothers
> >> me. Perhaps I just forgot what I thought I understood back then.. :(
> > 
> > Same race, I just didn't think it through that it could change within
> > the space of a couple of lines. :|
> > 
> >> Should this call process_csb only if !gt.awake? But sounds terribly
> >> dodgy.. Why would execlists.active be set if we are not awake..
> > 
> > Have to remember it's i915->gt.awake no execlists->active (that's what I
> > briefly hoped for...) I looked at ways we might decouple the tasklet (we
> > can't just use tasklet_disable) but that looks overkill, and I can't see
> > any way we can guarantee that we won't randomly kick it later.
> > 
> > I did consider reordering the final wait_for(engine_is_idle()) and
> > tasklet_flush, but I couldn't convince myself that was enough to
> > guarantee we wouldn't get an even later interrupt to kick the tasklet.
> > 

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Move the assertion we have the rpm wakeref down

[Tvrtko Ursulin]

On 19/07/2018 12:59, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-07-19 12:49:13)


On 19/07/2018 08:50, Chris Wilson wrote:

There's a race between idling the engine and finishing off the last
tasklet (as we may kick the tasklets after declaring an individual
engine idle). However, since we do not need to access the device until
we try to submit to the ELSP register (processing the CSB just requires
normal CPU access to the HWSP, and when idle we should not need to
submit!) we can defer the assertion unto that point. The assertion is
still useful as it does verify that we do hold the longterm GT wakeref
taken from request allocation until request completion.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107274
Fixes: 9512f985c32d ("drm/i915/execlists: Direct submission of new requests (avoid 
tasklet/ksoftirqd)")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
   drivers/gpu/drm/i915/intel_lrc.c | 25 +++--
   1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index db5351e6a3a5..9d693e61536c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -452,6 +452,16 @@ static void execlists_submit_ports(struct intel_engine_cs 
*engine)
   struct execlist_port *port = execlists->port;
   unsigned int n;
   
+ /*

+  * We can skip acquiring intel_runtime_pm_get() here as it was taken
+  * on our behalf by the request (see i915_gem_mark_busy()) and it will
+  * not be relinquished until the device is idle (see
+  * i915_gem_idle_work_handler()). As a precaution, we make sure
+  * that all ELSP are drained i.e. we have processed the CSB,
+  * before allowing ourselves to idle and calling intel_runtime_pm_put().
+  */
+ GEM_BUG_ON(!engine->i915->gt.awake);
+
   /*
* ELSQ note: the submit queue is not cleared after being submitted
* to the HW so we need to make sure we always clean it up. This is
@@ -1043,16 +1053,6 @@ static void __execlists_submission_tasklet(struct 
intel_engine_cs *const engine)
   {
   lockdep_assert_held(&engine->timeline.lock);
   
- /*

-  * We can skip acquiring intel_runtime_pm_get() here as it was taken
-  * on our behalf by the request (see i915_gem_mark_busy()) and it will
-  * not be relinquished until the device is idle (see
-  * i915_gem_idle_work_handler()). As a precaution, we make sure
-  * that all ELSP are drained i.e. we have processed the CSB,
-  * before allowing ourselves to idle and calling intel_runtime_pm_put().
-  */
- GEM_BUG_ON(!engine->i915->gt.awake);
-
   process_csb(engine);
   if (!execlists_is_active(&engine->execlists, EXECLISTS_ACTIVE_PREEMPT))
   execlists_dequeue(engine);
@@ -1073,10 +1073,7 @@ static void execlists_submission_tasklet(unsigned long 
data)
 engine->execlists.active);
   
   spin_lock_irqsave(&engine->timeline.lock, flags);

-
- if (engine->i915->gt.awake) /* we may be delayed until after we idle! */
- __execlists_submission_tasklet(engine);
-
+ __execlists_submission_tasklet(engine);
   spin_unlock_irqrestore(&engine->timeline.lock, flags);
   }
   



Why we won't hit the assert on the elsp submit side now? AFAIR the
discussion about this particular line concluded that direct tasklet call
can race with busy->idle transition. So even is process_csb doens't need
the assert, that part I get, the part about the race now again bothers
me. Perhaps I just forgot what I thought I understood back then.. :(


Same race, I just didn't think it through that it could change within
the space of a couple of lines. :|


Should this call process_csb only if !gt.awake? But sounds terribly
dodgy.. Why would execlists.active be set if we are not awake..


Have to remember it's i915->gt.awake no execlists->active (that's what I
briefly hoped for...) I looked at ways we might decouple the tasklet (we
can't just use tasklet_disable) but that looks overkill, and I can't see
any way we can guarantee that we won't randomly kick it later.

I did consider reordering the final wait_for(engine_is_idle()) and
tasklet_flush, but I couldn't convince myself that was enough to
guarantee we wouldn't get an even later interrupt to kick the tasklet.

So left it at just using the CSB to filter out the spurious call, and
relying on that we are idle to avoid the submit. The assertion still
plays the same role as it always has done, making sure the actual
register access is covered by our wakeref.


So the thing I am thinking of, and you tell me if it is not the one:

1. Idle work handler runs
2. Goes to idle the engines
3. New request comes in from a separate thread
4. intel_engine_is_idle sees execlist.active is set
5. Calls the tasklet

But gt.awake is true at this point, so assert does not fire.

If the status of execlists.active changes from true to false be

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v3,1/5] drm/i915/guc: Fix GuC pin bias and WOPCM initialization order

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/5] drm/i915/guc: Fix GuC pin bias and WOPCM 
initialization order
URL   : https://patchwork.freedesktop.org/series/46843/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915/guc: Fix GuC pin bias and WOPCM initialization order
Okay!

Commit: drm/i915/guc: Move the pin bias value from GuC to GGTT
+drivers/gpu/drm/i915/i915_gem_gtt.c:2948:34: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/i915_gem_gtt.c:2948:34: warning: expression using 
sizeof(void)

Commit: drm/i915: Remove unnecessary ggtt_offset_bias from i915_gem_context
Okay!

Commit: drm/i915: Add a fault injection point after WOPCM init
Okay!

Commit: HAX enable GuC for CI
Okay!

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

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Move the assertion we have the rpm wakeref down

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-07-19 12:49:13)
> 
> On 19/07/2018 08:50, Chris Wilson wrote:
> > There's a race between idling the engine and finishing off the last
> > tasklet (as we may kick the tasklets after declaring an individual
> > engine idle). However, since we do not need to access the device until
> > we try to submit to the ELSP register (processing the CSB just requires
> > normal CPU access to the HWSP, and when idle we should not need to
> > submit!) we can defer the assertion unto that point. The assertion is
> > still useful as it does verify that we do hold the longterm GT wakeref
> > taken from request allocation until request completion.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107274
> > Fixes: 9512f985c32d ("drm/i915/execlists: Direct submission of new requests 
> > (avoid tasklet/ksoftirqd)")
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > ---
> >   drivers/gpu/drm/i915/intel_lrc.c | 25 +++--
> >   1 file changed, 11 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index db5351e6a3a5..9d693e61536c 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -452,6 +452,16 @@ static void execlists_submit_ports(struct 
> > intel_engine_cs *engine)
> >   struct execlist_port *port = execlists->port;
> >   unsigned int n;
> >   
> > + /*
> > +  * We can skip acquiring intel_runtime_pm_get() here as it was taken
> > +  * on our behalf by the request (see i915_gem_mark_busy()) and it will
> > +  * not be relinquished until the device is idle (see
> > +  * i915_gem_idle_work_handler()). As a precaution, we make sure
> > +  * that all ELSP are drained i.e. we have processed the CSB,
> > +  * before allowing ourselves to idle and calling 
> > intel_runtime_pm_put().
> > +  */
> > + GEM_BUG_ON(!engine->i915->gt.awake);
> > +
> >   /*
> >* ELSQ note: the submit queue is not cleared after being submitted
> >* to the HW so we need to make sure we always clean it up. This is
> > @@ -1043,16 +1053,6 @@ static void __execlists_submission_tasklet(struct 
> > intel_engine_cs *const engine)
> >   {
> >   lockdep_assert_held(&engine->timeline.lock);
> >   
> > - /*
> > -  * We can skip acquiring intel_runtime_pm_get() here as it was taken
> > -  * on our behalf by the request (see i915_gem_mark_busy()) and it will
> > -  * not be relinquished until the device is idle (see
> > -  * i915_gem_idle_work_handler()). As a precaution, we make sure
> > -  * that all ELSP are drained i.e. we have processed the CSB,
> > -  * before allowing ourselves to idle and calling 
> > intel_runtime_pm_put().
> > -  */
> > - GEM_BUG_ON(!engine->i915->gt.awake);
> > -
> >   process_csb(engine);
> >   if (!execlists_is_active(&engine->execlists, 
> > EXECLISTS_ACTIVE_PREEMPT))
> >   execlists_dequeue(engine);
> > @@ -1073,10 +1073,7 @@ static void execlists_submission_tasklet(unsigned 
> > long data)
> > engine->execlists.active);
> >   
> >   spin_lock_irqsave(&engine->timeline.lock, flags);
> > -
> > - if (engine->i915->gt.awake) /* we may be delayed until after we idle! 
> > */
> > - __execlists_submission_tasklet(engine);
> > -
> > + __execlists_submission_tasklet(engine);
> >   spin_unlock_irqrestore(&engine->timeline.lock, flags);
> >   }
> >   
> > 
> 
> Why we won't hit the assert on the elsp submit side now? AFAIR the 
> discussion about this particular line concluded that direct tasklet call 
> can race with busy->idle transition. So even is process_csb doens't need 
> the assert, that part I get, the part about the race now again bothers 
> me. Perhaps I just forgot what I thought I understood back then.. :(

Same race, I just didn't think it through that it could change within
the space of a couple of lines. :|

> Should this call process_csb only if !gt.awake? But sounds terribly 
> dodgy.. Why would execlists.active be set if we are not awake..

Have to remember it's i915->gt.awake no execlists->active (that's what I
briefly hoped for...) I looked at ways we might decouple the tasklet (we
can't just use tasklet_disable) but that looks overkill, and I can't see
any way we can guarantee that we won't randomly kick it later.

I did consider reordering the final wait_for(engine_is_idle()) and
tasklet_flush, but I couldn't convince myself that was enough to
guarantee we wouldn't get an even later interrupt to kick the tasklet.

So left it at just using the CSB to filter out the spurious call, and
relying on that we are idle to avoid the submit. The assertion still
plays the same role as it always has done, making sure the actual
register access is covered by our wakeref.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
h

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Move the assertion we have the rpm wakeref down

[Tvrtko Ursulin]

On 19/07/2018 08:50, Chris Wilson wrote:

There's a race between idling the engine and finishing off the last
tasklet (as we may kick the tasklets after declaring an individual
engine idle). However, since we do not need to access the device until
we try to submit to the ELSP register (processing the CSB just requires
normal CPU access to the HWSP, and when idle we should not need to
submit!) we can defer the assertion unto that point. The assertion is
still useful as it does verify that we do hold the longterm GT wakeref
taken from request allocation until request completion.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107274
Fixes: 9512f985c32d ("drm/i915/execlists: Direct submission of new requests (avoid 
tasklet/ksoftirqd)")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/intel_lrc.c | 25 +++--
  1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index db5351e6a3a5..9d693e61536c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -452,6 +452,16 @@ static void execlists_submit_ports(struct intel_engine_cs 
*engine)
struct execlist_port *port = execlists->port;
unsigned int n;
  
+	/*

+* We can skip acquiring intel_runtime_pm_get() here as it was taken
+* on our behalf by the request (see i915_gem_mark_busy()) and it will
+* not be relinquished until the device is idle (see
+* i915_gem_idle_work_handler()). As a precaution, we make sure
+* that all ELSP are drained i.e. we have processed the CSB,
+* before allowing ourselves to idle and calling intel_runtime_pm_put().
+*/
+   GEM_BUG_ON(!engine->i915->gt.awake);
+
/*
 * ELSQ note: the submit queue is not cleared after being submitted
 * to the HW so we need to make sure we always clean it up. This is
@@ -1043,16 +1053,6 @@ static void __execlists_submission_tasklet(struct 
intel_engine_cs *const engine)
  {
lockdep_assert_held(&engine->timeline.lock);
  
-	/*

-* We can skip acquiring intel_runtime_pm_get() here as it was taken
-* on our behalf by the request (see i915_gem_mark_busy()) and it will
-* not be relinquished until the device is idle (see
-* i915_gem_idle_work_handler()). As a precaution, we make sure
-* that all ELSP are drained i.e. we have processed the CSB,
-* before allowing ourselves to idle and calling intel_runtime_pm_put().
-*/
-   GEM_BUG_ON(!engine->i915->gt.awake);
-
process_csb(engine);
if (!execlists_is_active(&engine->execlists, EXECLISTS_ACTIVE_PREEMPT))
execlists_dequeue(engine);
@@ -1073,10 +1073,7 @@ static void execlists_submission_tasklet(unsigned long 
data)
  engine->execlists.active);
  
  	spin_lock_irqsave(&engine->timeline.lock, flags);

-
-   if (engine->i915->gt.awake) /* we may be delayed until after we idle! */
-   __execlists_submission_tasklet(engine);
-
+   __execlists_submission_tasklet(engine);
spin_unlock_irqrestore(&engine->timeline.lock, flags);
  }
  



Why we won't hit the assert on the elsp submit side now? AFAIR the 
discussion about this particular line concluded that direct tasklet call 
can race with busy->idle transition. So even is process_csb doens't need 
the assert, that part I get, the part about the race now again bothers 
me. Perhaps I just forgot what I thought I understood back then.. :(


Should this call process_csb only if !gt.awake? But sounds terribly 
dodgy.. Why would execlists.active be set if we are not awake..


Regards,

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