Re: [Intel-gfx] [PATCH 2/2] drm/i915/adl_s: add missing PCI IDs

[Surendrakumar Upadhyay, TejaskumarX]

> -Original Message-
> From: Intel-gfx  On Behalf Of Lucas
> De Marchi
> Sent: 23 March 2021 01:58
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 2/2] drm/i915/adl_s: add missing PCI IDs
> 
> Synchronize our PCI IDs with the list in Bspec 53655.
> 
> Signed-off-by: Lucas De Marchi 
> ---
>  include/drm/i915_pciids.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index
> ebd0dd1c35b3..3be25768321d 100644
> --- a/include/drm/i915_pciids.h
> +++ b/include/drm/i915_pciids.h
> @@ -640,6 +640,8 @@
>   INTEL_VGA_DEVICE(0x4681, info), \
>   INTEL_VGA_DEVICE(0x4682, info), \
>   INTEL_VGA_DEVICE(0x4683, info), \
> + INTEL_VGA_DEVICE(0x4688, info), \
> + INTEL_VGA_DEVICE(0x4689, info), \

As per https://gfxspecs.intel.com/Predator/Home/Index/53655, these are still 
"Not ok to upstream". 

Thanks,
Tejas 
>   INTEL_VGA_DEVICE(0x4690, info), \
>   INTEL_VGA_DEVICE(0x4691, info), \
>   INTEL_VGA_DEVICE(0x4692, info), \
> --
> 2.31.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Add DISPLAY_VER() and related macros

[Lucas De Marchi]

On Fri, Mar 19, 2021 at 09:42:41PM -0700, Matt Roper wrote:

Although we've long referred to platforms by a single "GEN" number, the
hardware teams have recommended that we stop doing this since the
various component IP blocks are going to start using independent number
schemes with varying cadence.  To support this, hardware platforms a bit
down the road are going to start providing MMIO registers that the
driver can read to obtain the "graphics version," "media version," and
"display version" without needing to do a PCI ID -> platform -> version
translation.

Although our current platforms don't yet expose these registers (and the
next couple we release probably won't have them yet either), the
hardware teams would still like to see us move to this independent
numbering scheme now in preparation.  For i915 that means we should try
to eliminate all usage of INTEL_GEN() throughout our code and instead
replace it with separate GRAPHICS_VER(), MEDIA_VER(), and DISPLAY_VER()
constructs in the code.  For old platforms, these will all usually give
the same value for each IP block (aside from a few special cases like
GLK which we can no more accurately represent as graphics=9 +
display=10), but future platforms will have more flexibility to bump IP
version numbers independently.

The upcoming ADL-P platform will have a display version of 13 and a
graphics version of 12, so let's just the first step of breaking out
DISPLAY_VER(), but leaving the rest of INTEL_GEN() untouched for now.
For now we'll automatically derive the display version from the
platform's INTEL_GEN() value except in cases where an alternative
display version is explicitly provided in the device info structure.

We'll also add some helper macros IS_DISPLAY_VER(i915, ver) and


nit: future tense here gives the impression it's not done in this patch,
but in a later one, which is not the case.


IS_DISPLAY_RANGE(i915, from, until) that match the behavior of the
existing gen-based macros.  However unlike IS_GEN(), we will implement
those macros with direct comparisons rather than trying to maintain a
mask to help compiler optimization.  In practice the optimization winds
up not being used in very many places (since the vast majority of our
platform checks are of the form "gen >= x") so there is pretty minimal
size reduction in the final driver binary[1].  We're also likely going
to need to extend these version numbers to non-integer major.minor
values at some point in the future, so the mask approach won't work at
all once we get to platforms like that.

[1] The results before/after the next patch in this series, which
switches our code over to the new display macros:

   $ size i915.ko.{orig,new}
  textdata bss dec hex filename
   2940291  1029445384 3048619  2e84ab i915.ko.orig
   2940723  1029565384 3049063  2e8667 i915.ko.new

v2:
- Move version into device info's display sub-struct. (Jani)
- Add extra parentheses to macros.  (Jani)
- Note the lack of genmask optimization in the display-based macros and
  give size data.  (Lucas)

Cc: Jani Nikula 
Cc: Lucas De Marchi 
Signed-off-by: Matt Roper 



Reviewed-by: Lucas De Marchi 

Lucas De Marchi


---
drivers/gpu/drm/i915/i915_drv.h  | 5 +
drivers/gpu/drm/i915/i915_pci.c  | 2 +-
drivers/gpu/drm/i915/intel_device_info.h | 2 ++
3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1aca1274e698..89e8cb52647a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1241,6 +1241,11 @@ static inline struct drm_i915_private 
*pdev_to_i915(struct pci_dev *pdev)
#define INTEL_GEN(dev_priv) (INTEL_INFO(dev_priv)->gen)
#define INTEL_DEVID(dev_priv)   (RUNTIME_INFO(dev_priv)->device_id)

+#define DISPLAY_VER(i915)  (INTEL_INFO(i915)->display.version)
+#define IS_DISPLAY_RANGE(i915, from, until) \
+   (DISPLAY_VER(i915) >= (from) && DISPLAY_VER(i915) <= (until))
+#define IS_DISPLAY_VER(i915, v) (DISPLAY_VER(i915) == (v))
+
#define REVID_FOREVER   0xff
#define INTEL_REVID(dev_priv)   (to_pci_dev((dev_priv)->drm.dev)->revision)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index a9f24f2bda33..d327882d6d4b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -36,7 +36,7 @@
#include "i915_selftest.h"

#define PLATFORM(x) .platform = (x)
-#define GEN(x) .gen = (x), .gen_mask = BIT((x) - 1)
+#define GEN(x) .gen = (x), .gen_mask = BIT((x) - 1), .display.version = (x)

#define I845_PIPE_OFFSETS \
.pipe_offsets = { \
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index d44f64b57b7a..90acbaf800d5 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -187,6 +187,8 @@ struct intel_device_info {
#undef DEFINE_FLAG

struct {
+   u8 vers

[Intel-gfx] ✓ Fi.CI.BAT: success for Disassociate display version from INTEL_GEN() (rev5)

[Patchwork]

== Series Details ==

Series: Disassociate display version from INTEL_GEN() (rev5)
URL   : https://patchwork.freedesktop.org/series/88198/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9882 -> Patchwork_19836


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/index.html

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_flink_basic@bad-open:
- fi-tgl-y:   [PASS][1] -> [DMESG-WARN][2] ([i915#402])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-tgl-y/igt@gem_flink_ba...@bad-open.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/fi-tgl-y/igt@gem_flink_ba...@bad-open.html

  * igt@gem_huc_copy@huc-copy:
- fi-byt-j1900:   NOTRUN -> [SKIP][3] ([fdo#109271]) +27 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/fi-byt-j1900/igt@gem_huc_c...@huc-copy.html

  * igt@gem_linear_blits@basic:
- fi-kbl-8809g:   [PASS][4] -> [TIMEOUT][5] ([i915#2502] / [i915#3145])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-kbl-8809g/igt@gem_linear_bl...@basic.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/fi-kbl-8809g/igt@gem_linear_bl...@basic.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-byt-j1900:   NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/fi-byt-j1900/igt@kms_chamel...@hdmi-crc-fast.html

  
 Possible fixes 

  * igt@gem_mmap_gtt@basic:
- fi-tgl-y:   [DMESG-WARN][7] ([i915#402]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-tgl-y/igt@gem_mmap_...@basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19836/fi-tgl-y/igt@gem_mmap_...@basic.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1222]: https://gitlab.freedesktop.org/drm/intel/issues/1222
  [i915#2502]: https://gitlab.freedesktop.org/drm/intel/issues/2502
  [i915#3145]: https://gitlab.freedesktop.org/drm/intel/issues/3145
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (47 -> 42)
--

  Additional (1): fi-byt-j1900 
  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-icl-y 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9882 -> Patchwork_19836

  CI-20190529: 20190529
  CI_DRM_9882: 34f82d5853a3c6467ccf71e055e3432d2b12ecb9 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6040: 69b578b6ab0a36750f0d23c223a3487fc88fb6a7 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19836: c1d5003cdc8e44be6c97002a3925ea4814148e9e @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

c1d5003cdc8e drm/i915/display: Simplify GLK display version tests
9483991f662f drm/i915: Convert INTEL_GEN() to DISPLAY_VER() as appropriate in 
i915_irq.c
3a21e8a872da drm/i915: Convert INTEL_GEN() to DISPLAY_VER() as appropriate in 
intel_pm.c
8179128a529d drm/i915/display: Eliminate most usage of INTEL_GEN()
b23b2ac9f456 drm/i915: Add DISPLAY_VER() and related macros
590f81d89285 drm/i915/display: Convert gen5/gen6 tests to 
IS_IRONLAKE/IS_SANDYBRIDGE

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Disassociate display version from INTEL_GEN() (rev5)

[Patchwork]

== Series Details ==

Series: Disassociate display version from INTEL_GEN() (rev5)
URL   : https://patchwork.freedesktop.org/series/88198/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_reset.c:1323:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gvt/mmio.c:295:23: warning: memcpy with byte count of 
279040
+drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 
16777216
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - 
different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' 
- different lock contexts for basic block


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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Disassociate display version from INTEL_GEN() (rev5)

[Patchwork]

== Series Details ==

Series: Disassociate display version from INTEL_GEN() (rev5)
URL   : https://patchwork.freedesktop.org/series/88198/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
590f81d89285 drm/i915/display: Convert gen5/gen6 tests to 
IS_IRONLAKE/IS_SANDYBRIDGE
-:130: CHECK:CAMELCASE: Avoid CamelCase: 
#130: FILE: drivers/gpu/drm/i915/display/intel_display.c:11604:
+   if (IS_IRONLAKE(dev_priv) && (intel_de_read(dev_priv, FUSE_STRAP) & 
ILK_eDP_A_DISABLE))

total: 0 errors, 0 warnings, 1 checks, 216 lines checked
b23b2ac9f456 drm/i915: Add DISPLAY_VER() and related macros
-:73: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible 
side-effects?
#73: FILE: drivers/gpu/drm/i915/i915_drv.h:1245:
+#define IS_DISPLAY_RANGE(i915, from, until) \
+   (DISPLAY_VER(i915) >= (from) && DISPLAY_VER(i915) <= (until))

-:89: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'x' - possible side-effects?
#89: FILE: drivers/gpu/drm/i915/i915_pci.c:39:
+#define GEN(x) .gen = (x), .gen_mask = BIT((x) - 1), .display.version = (x)

total: 0 errors, 0 warnings, 2 checks, 27 lines checked
8179128a529d drm/i915/display: Eliminate most usage of INTEL_GEN()
-:2043: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 'port == 
PORT_E'
#2043: FILE: drivers/gpu/drm/i915/display/intel_display.c:6717:
+   if (DISPLAY_VER(dev_priv) < 9 &&
(port == PORT_E) && intel_de_read(dev_priv, LPT_TRANSCONF) & 
TRANS_ENABLE) {

-:2631: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional 
statements (8, 63)
#2631: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:153:
+   if (DISPLAY_VER(dev_priv) >= 9)
/* no global SR status; inspect per-plane WM */;

-:4188: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 
'intel_dp->psr_dpcd[0] == DP_PSR2_WITH_Y_COORD_IS_SUPPORTED'
#4188: FILE: drivers/gpu/drm/i915/display/intel_psr.c:324:
+   if (DISPLAY_VER(dev_priv) >= 9 &&
(intel_dp->psr_dpcd[0] == DP_PSR2_WITH_Y_COORD_IS_SUPPORTED)) {

total: 0 errors, 1 warnings, 2 checks, 4216 lines checked
3a21e8a872da drm/i915: Convert INTEL_GEN() to DISPLAY_VER() as appropriate in 
intel_pm.c
9483991f662f drm/i915: Convert INTEL_GEN() to DISPLAY_VER() as appropriate in 
i915_irq.c
c1d5003cdc8e drm/i915/display: Simplify GLK display version tests
-:77: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#77: 
- (IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_DISPLAY_VER(dev_priv, 10))

-:388: WARNING:LONG_LINE: line length of 235 exceeds 100 columns
#388: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2419:
+   if ((DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && 
((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort && 
!to_intel_connector(connector)->mst_port) || connector->connector_type == 
DRM_MODE_CONNECTOR_eDP))

-:574: WARNING:LONG_LINE: line length of 195 exceeds 100 columns
#574: FILE: drivers/gpu/drm/i915/display/intel_vdsc.c:349:
+   if ((DISPLAY_VER(i915) >= 11 || IS_CANNONLAKE(i915)) && (pipe != PIPE_A 
|| (cpu_transcoder == TRANSCODER_EDP || cpu_transcoder == TRANSCODER_DSI_0 || 
cpu_transcoder == TRANSCODER_DSI_1)))

-:741: WARNING:LONG_LINE: line length of 104 exceeds 100 columns
#741: FILE: drivers/gpu/drm/i915/display/skl_universal_plane.c:2230:
+   if ((DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && val & 
PLANE_CTL_FLIP_HORIZONTAL)

total: 0 errors, 4 warnings, 0 checks, 574 lines checked


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

[Intel-gfx] ✗ Fi.CI.BAT: failure for Disassociate display version from INTEL_GEN() (rev4)

[Patchwork]

== Series Details ==

Series: Disassociate display version from INTEL_GEN() (rev4)
URL   : https://patchwork.freedesktop.org/series/88198/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9882 -> Patchwork_19835


Summary
---

  **FAILURE**

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

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19835/index.html

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19835/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@read_all_entries:
- fi-tgl-y:   [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +2 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-tgl-y/igt@debugfs_test@read_all_entries.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19835/fi-tgl-y/igt@debugfs_test@read_all_entries.html

  * igt@gem_huc_copy@huc-copy:
- fi-byt-j1900:   NOTRUN -> [SKIP][5] ([fdo#109271]) +27 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19835/fi-byt-j1900/igt@gem_huc_c...@huc-copy.html

  * igt@gem_tiled_fence_blits@basic:
- fi-kbl-8809g:   [PASS][6] -> [TIMEOUT][7] ([i915#3145])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-kbl-8809g/igt@gem_tiled_fence_bl...@basic.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19835/fi-kbl-8809g/igt@gem_tiled_fence_bl...@basic.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-byt-j1900:   NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19835/fi-byt-j1900/igt@kms_chamel...@hdmi-crc-fast.html

  
 Possible fixes 

  * igt@gem_mmap_gtt@basic:
- fi-tgl-y:   [DMESG-WARN][9] ([i915#402]) -> [PASS][10] +1 similar 
issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-tgl-y/igt@gem_mmap_...@basic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19835/fi-tgl-y/igt@gem_mmap_...@basic.html

  * igt@gem_tiled_blits@basic:
- fi-kbl-8809g:   [TIMEOUT][11] ([i915#2502] / [i915#3145]) -> 
[PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-kbl-8809g/igt@gem_tiled_bl...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19835/fi-kbl-8809g/igt@gem_tiled_bl...@basic.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1222]: https://gitlab.freedesktop.org/drm/intel/issues/1222
  [i915#2502]: https://gitlab.freedesktop.org/drm/intel/issues/2502
  [i915#3145]: https://gitlab.freedesktop.org/drm/intel/issues/3145
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (47 -> 43)
--

  Additional (1): fi-byt-j1900 
  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9882 -> Patchwork_19835

  CI-20190529: 20190529
  CI_DRM_9882: 34f82d5853a3c6467ccf71e055e3432d2b12ecb9 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6040: 69b578b6ab0a36750f0d23c223a3487fc88fb6a7 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19835: fa2c5874debdec2166d91778f8bc32f05dfad45c @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

fa2c5874debd drm/i915/display: Simplify GLK display version tests
d729e75a5f02 drm/i915: Convert INTEL_GEN() to DISPLAY_VER() as appropriate in 
i915_irq.c
915c0e51a3f4 drm/i915: Convert INTEL_GEN() to DISPLAY_VER() as appropriate in 
intel_pm.c
188b76a17daf drm/i915/display: Eliminate most usage of INTEL_GEN()
6297fd1b97dd drm/i915: Add DISPLAY_VER() and related macros
c81a8f093d82 drm/i915/display: Convert gen5/gen6 tests to 
IS_IRONLAKE/IS_SANDYBRIDGE

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19835/index.html
___
Intel-

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Disassociate display version from INTEL_GEN() (rev4)

[Patchwork]

== Series Details ==

Series: Disassociate display version from INTEL_GEN() (rev4)
URL   : https://patchwork.freedesktop.org/series/88198/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_reset.c:1323:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gvt/mmio.c:295:23: warning: memcpy with byte count of 
279040
+drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 
16777216
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - 
different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' 
- different lock contexts for basic block


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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Disassociate display version from INTEL_GEN() (rev4)

[Patchwork]

== Series Details ==

Series: Disassociate display version from INTEL_GEN() (rev4)
URL   : https://patchwork.freedesktop.org/series/88198/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
c81a8f093d82 drm/i915/display: Convert gen5/gen6 tests to 
IS_IRONLAKE/IS_SANDYBRIDGE
-:130: CHECK:CAMELCASE: Avoid CamelCase: 
#130: FILE: drivers/gpu/drm/i915/display/intel_display.c:11604:
+   if (IS_IRONLAKE(dev_priv) && (intel_de_read(dev_priv, FUSE_STRAP) & 
ILK_eDP_A_DISABLE))

total: 0 errors, 0 warnings, 1 checks, 216 lines checked
6297fd1b97dd drm/i915: Add DISPLAY_VER() and related macros
-:73: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible 
side-effects?
#73: FILE: drivers/gpu/drm/i915/i915_drv.h:1245:
+#define IS_DISPLAY_RANGE(i915, from, until) \
+   (DISPLAY_VER(i915) >= (from) && DISPLAY_VER(i915) <= (until))

-:89: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'x' - possible side-effects?
#89: FILE: drivers/gpu/drm/i915/i915_pci.c:39:
+#define GEN(x) .gen = (x), .gen_mask = BIT((x) - 1), .display.version = (x)

total: 0 errors, 0 warnings, 2 checks, 27 lines checked
188b76a17daf drm/i915/display: Eliminate most usage of INTEL_GEN()
-:2043: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 'port == 
PORT_E'
#2043: FILE: drivers/gpu/drm/i915/display/intel_display.c:6717:
+   if (DISPLAY_VER(dev_priv) < 9 &&
(port == PORT_E) && intel_de_read(dev_priv, LPT_TRANSCONF) & 
TRANS_ENABLE) {

-:2631: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional 
statements (8, 63)
#2631: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:153:
+   if (DISPLAY_VER(dev_priv) >= 9)
/* no global SR status; inspect per-plane WM */;

-:4188: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 
'intel_dp->psr_dpcd[0] == DP_PSR2_WITH_Y_COORD_IS_SUPPORTED'
#4188: FILE: drivers/gpu/drm/i915/display/intel_psr.c:324:
+   if (DISPLAY_VER(dev_priv) >= 9 &&
(intel_dp->psr_dpcd[0] == DP_PSR2_WITH_Y_COORD_IS_SUPPORTED)) {

total: 0 errors, 1 warnings, 2 checks, 4216 lines checked
915c0e51a3f4 drm/i915: Convert INTEL_GEN() to DISPLAY_VER() as appropriate in 
intel_pm.c
d729e75a5f02 drm/i915: Convert INTEL_GEN() to DISPLAY_VER() as appropriate in 
i915_irq.c
fa2c5874debd drm/i915/display: Simplify GLK display version tests
-:77: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#77: 
- (IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_DISPLAY_VER(dev_priv, 10))

-:388: WARNING:LONG_LINE: line length of 235 exceeds 100 columns
#388: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2419:
+   if ((DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && 
((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort && 
!to_intel_connector(connector)->mst_port) || connector->connector_type == 
DRM_MODE_CONNECTOR_eDP))

-:574: WARNING:LONG_LINE: line length of 195 exceeds 100 columns
#574: FILE: drivers/gpu/drm/i915/display/intel_vdsc.c:349:
+   if ((DISPLAY_VER(i915) >= 11 || IS_CANNONLAKE(i915)) && (pipe != PIPE_A 
|| (cpu_transcoder == TRANSCODER_EDP || cpu_transcoder == TRANSCODER_DSI_0 || 
cpu_transcoder == TRANSCODER_DSI_1)))

-:741: WARNING:LONG_LINE: line length of 104 exceeds 100 columns
#741: FILE: drivers/gpu/drm/i915/display/skl_universal_plane.c:2230:
+   if ((DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && val & 
PLANE_CTL_FLIP_HORIZONTAL)

total: 0 errors, 4 warnings, 0 checks, 574 lines checked


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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915: Skip display interruption setup when display is not available

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/3] drm/i915: Skip display interruption setup 
when display is not available
URL   : https://patchwork.freedesktop.org/series/88301/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9882 -> Patchwork_19834


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/index.html

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@read:
- fi-tgl-y:   [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar 
issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-tgl-y/igt@fb...@read.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/fi-tgl-y/igt@fb...@read.html

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2:  [PASS][3] -> [FAIL][4] ([i915#1888])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_huc_copy@huc-copy:
- fi-byt-j1900:   NOTRUN -> [SKIP][5] ([fdo#109271]) +27 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/fi-byt-j1900/igt@gem_huc_c...@huc-copy.html

  * igt@gem_linear_blits@basic:
- fi-kbl-8809g:   [PASS][6] -> [TIMEOUT][7] ([i915#2502] / [i915#3145])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-kbl-8809g/igt@gem_linear_bl...@basic.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/fi-kbl-8809g/igt@gem_linear_bl...@basic.html

  * igt@i915_selftest@live@client:
- fi-glk-dsi: [PASS][8] -> [DMESG-FAIL][9] ([i915#3047])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-glk-dsi/igt@i915_selftest@l...@client.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/fi-glk-dsi/igt@i915_selftest@l...@client.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-byt-j1900:   NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/fi-byt-j1900/igt@kms_chamel...@hdmi-crc-fast.html

  
 Possible fixes 

  * igt@gem_mmap_gtt@basic:
- fi-tgl-y:   [DMESG-WARN][11] ([i915#402]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-tgl-y/igt@gem_mmap_...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/fi-tgl-y/igt@gem_mmap_...@basic.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1222]: https://gitlab.freedesktop.org/drm/intel/issues/1222
  [i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2502]: https://gitlab.freedesktop.org/drm/intel/issues/2502
  [i915#3047]: https://gitlab.freedesktop.org/drm/intel/issues/3047
  [i915#3145]: https://gitlab.freedesktop.org/drm/intel/issues/3145
  [i915#3180]: https://gitlab.freedesktop.org/drm/intel/issues/3180
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (47 -> 43)
--

  Additional (1): fi-byt-j1900 
  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9882 -> Patchwork_19834

  CI-20190529: 20190529
  CI_DRM_9882: 34f82d5853a3c6467ccf71e055e3432d2b12ecb9 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6040: 69b578b6ab0a36750f0d23c223a3487fc88fb6a7 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19834: 192712508adae53af4b804e7a0c7df04eac67f43 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

192712508ada drm/i915: skip display initialization when there is no display
ed8df63b1958 drm/i915: Do not set any power wells when there is no display
79eb0c71120c drm/i915: Skip display interruption setup when display is not 
available

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19834/index.html
___
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: Fix the GT fence revocation runtime PM logic

[Patchwork]

== Series Details ==

Series: drm/i915: Fix the GT fence revocation runtime PM logic
URL   : https://patchwork.freedesktop.org/series/88300/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9882 -> Patchwork_19833


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/index.html

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-y:   [PASS][1] -> [DMESG-WARN][2] ([i915#2411] / 
[i915#402])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_huc_copy@huc-copy:
- fi-byt-j1900:   NOTRUN -> [SKIP][3] ([fdo#109271]) +27 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/fi-byt-j1900/igt@gem_huc_c...@huc-copy.html

  * igt@gem_linear_blits@basic:
- fi-kbl-8809g:   [PASS][4] -> [TIMEOUT][5] ([i915#2502] / [i915#3145])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-kbl-8809g/igt@gem_linear_bl...@basic.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/fi-kbl-8809g/igt@gem_linear_bl...@basic.html

  * igt@gem_render_tiled_blits@basic:
- fi-tgl-y:   [PASS][6] -> [DMESG-WARN][7] ([i915#402])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-tgl-y/igt@gem_render_tiled_bl...@basic.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/fi-tgl-y/igt@gem_render_tiled_bl...@basic.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-byt-j1900:   NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/fi-byt-j1900/igt@kms_chamel...@hdmi-crc-fast.html

  
 Possible fixes 

  * igt@gem_mmap_gtt@basic:
- fi-tgl-y:   [DMESG-WARN][9] ([i915#402]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-tgl-y/igt@gem_mmap_...@basic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/fi-tgl-y/igt@gem_mmap_...@basic.html

  * igt@gem_tiled_blits@basic:
- fi-kbl-8809g:   [TIMEOUT][11] ([i915#2502] / [i915#3145]) -> 
[PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-kbl-8809g/igt@gem_tiled_bl...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/fi-kbl-8809g/igt@gem_tiled_bl...@basic.html

  * igt@gem_wait@busy@all:
- fi-bsw-nick:[FAIL][13] ([i915#3177]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-bsw-nick/igt@gem_wait@b...@all.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/fi-bsw-nick/igt@gem_wait@b...@all.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-kbl-soraka:  [FAIL][15] ([i915#2546] / [i915#49]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-kbl-soraka/igt@kms_frontbuffer_track...@basic.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/fi-kbl-soraka/igt@kms_frontbuffer_track...@basic.html
- fi-cml-u2:  [FAIL][17] ([i915#2546] / [i915#49]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19833/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1222]: https://gitlab.freedesktop.org/drm/intel/issues/1222
  [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
  [i915#2502]: https://gitlab.freedesktop.org/drm/intel/issues/2502
  [i915#2546]: https://gitlab.freedesktop.org/drm/intel/issues/2546
  [i915#3145]: https://gitlab.freedesktop.org/drm/intel/issues/3145
  [i915#3177]: https://gitlab.freedesktop.org/drm/intel/issues/3177
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49


Participating hosts (47 -> 42)
--

  Additional (1): fi-byt-j1900 
  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-icl-y 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9882 -> Patchwork_19833

  CI-20190529: 20190529
  CI_DRM_9882: 34f82d5853a3c6467ccf71e055e3432d2b12ecb9 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6040: 69b578b6ab0a36750f0d23c223a3487fc88fb6a7 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Pa

[Intel-gfx] [PATCH v3 6/6] drm/i915/display: Simplify GLK display version tests

[Matt Roper]

GLK has always been a bit of a special case since it reports INTEL_GEN()
as 9, but has version 10 display IP.  Now we can properly represent the
display version as 10 and simplify the display generation tests
throughout the display code.

Aside from manually adding the version to the glk_info structure, the
rest of this patch is generated with a Coccinelle semantic patch.  Note
that we also need to switch any code that matches gen10 today but *not*
GLK to be CNL-specific:

@@ expression dev_priv; @@
- DISPLAY_VER(dev_priv) > 9
+ DISPLAY_VER(dev_priv) >= 10

@@ expression dev_priv, E; @@
(
- DISPLAY_VER(dev_priv) >= 10 && E
+ (DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && E
|
- DISPLAY_VER(dev_priv) >= 10
+ DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)
|
- IS_DISPLAY_RANGE(dev_priv, 10, E)
+ IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_CANNONLAKE(dev_priv)
)

@@ expression dev_priv, E, E2; @@
(
- (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
+ IS_DISPLAY_VER(dev_priv, 10)
|
- E || IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)
+ E || IS_DISPLAY_VER(dev_priv, 10)
|
- (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv))
+ IS_DISPLAY_VER(dev_priv, 10)
|
- IS_GEMINILAKE(dev_priv) || E || IS_CANNONLAKE(dev_priv)
+ E || IS_DISPLAY_VER(dev_priv, 10)
|
- E || IS_GEMINILAKE(dev_priv) || E2 || IS_CANNONLAKE(dev_priv)
+ E || E2 || IS_DISPLAY_VER(dev_priv, 10)
|
- (IS_DISPLAY_VER(dev_priv, 10) || IS_GEMINILAKE(dev_priv))
+ IS_DISPLAY_VER(dev_priv, 10)
|
- (IS_GEMINILAKE(dev_priv) || IS_DISPLAY_VER(dev_priv, 10))
+ IS_DISPLAY_VER(dev_priv, 10)
)

@@ expression dev_priv; @@
- (IS_DISPLAY_VER(dev_priv, 9) && !IS_GEMINILAKE(dev_priv))
+ IS_DISPLAY_VER(dev_priv, 9)

@@ expression dev_priv; @@
(
- !(DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10))
+ DISPLAY_VER(dev_priv) < 10
|
- (DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10))
+ DISPLAY_VER(dev_priv) >= 10
)

@@ expression dev_priv, E; @@
- E || DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)
+ E || DISPLAY_VER(dev_priv) >= 10

@@ expression dev_priv, E; @@
- (IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_DISPLAY_VER(dev_priv, 10))
+ IS_DISPLAY_RANGE(dev_priv, 10, E)

@@ expression dev_priv; @@
(
- DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) || 
IS_GEN9_LP(dev_priv)
+ DISPLAY_VER(dev_priv) >= 10 || IS_GEN9_LP(dev_priv)
|
- IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 11 || 
IS_CANNONLAKE(dev_priv)
+ IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 10
)

@@ expression dev_priv, E; @@
- !(DISPLAY_VER(dev_priv) >= E)
+ DISPLAY_VER(dev_priv) < E

v2:
 - Convert gen10 conditions that don't include GLK into CNL conditions.
   (Ville)

v3:
 - Rework coccinelle rules so that "ver>=10" turns into "ver>=11||is_cnl." 
(Ville)

v3.1:
 - Manually re-add the ".display.version = 10" to glk_info after
   regenerating patch via Coccinelle.

v4:
 - Also apply cocci rules to intel_pm.c and i915_irq.c!  (CI)

Cc: Ville Syrjälä 
Signed-off-by: Matt Roper 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_atomic.c   |  7 ++--
 drivers/gpu/drm/i915/display/intel_audio.c|  2 +-
 drivers/gpu/drm/i915/display/intel_bios.c |  3 +-
 drivers/gpu/drm/i915/display/intel_cdclk.c| 26 +++--
 drivers/gpu/drm/i915/display/intel_color.c|  8 ++--
 drivers/gpu/drm/i915/display/intel_crtc.c |  2 +-
 drivers/gpu/drm/i915/display/intel_display.c  |  9 ++---
 .../drm/i915/display/intel_display_debugfs.c  |  5 +--
 .../drm/i915/display/intel_display_power.c|  2 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |  6 +--
 drivers/gpu/drm/i915/display/intel_fbc.c  |  4 +-
 drivers/gpu/drm/i915/display/intel_hdcp.c |  1 -
 drivers/gpu/drm/i915/display/intel_hdmi.c | 13 +++
 drivers/gpu/drm/i915/display/intel_psr.c  |  7 ++--
 drivers/gpu/drm/i915/display/intel_vdsc.c |  6 +--
 .../drm/i915/display/skl_universal_plane.c| 37 +--
 drivers/gpu/drm/i915/i915_pci.c   |  1 +
 drivers/gpu/drm/i915/intel_pm.c   | 16 
 18 files changed, 71 insertions(+), 84 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 2b928795755e..4fa389fce8cb 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -332,8 +332,7 @@ static void intel_atomic_setup_scaler(struct 
intel_crtc_scaler_state *scaler_sta
pl

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915: Fix the GT fence revocation runtime PM logic

[Patchwork]

== Series Details ==

Series: drm/i915: Fix the GT fence revocation runtime PM logic
URL   : https://patchwork.freedesktop.org/series/88300/
State : warning

== Summary ==

$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/intel_runtime_pm.c:430: warning: expecting prototype for 
intel_runtime_pm_get_if_in_use(). Prototype was for 
__intel_runtime_pm_get_if_active() instead
./drivers/gpu/drm/i915/intel_runtime_pm.c:430: warning: Function parameter or 
member 'ignore_usecount' not described in '__intel_runtime_pm_get_if_active'
./drivers/gpu/drm/i915/intel_runtime_pm.c:430: warning: expecting prototype for 
intel_runtime_pm_get_if_in_use(). Prototype was for 
__intel_runtime_pm_get_if_active() instead


___
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: Fix the GT fence revocation runtime PM logic

[Patchwork]

== Series Details ==

Series: drm/i915: Fix the GT fence revocation runtime PM logic
URL   : https://patchwork.freedesktop.org/series/88300/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
85e423a9bccf drm/i915: Fix the GT fence revocation runtime PM logic
-:90: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'rpm' - possible side-effects?
#90: FILE: drivers/gpu/drm/i915/intel_runtime_pm.h:192:
+#define with_intel_runtime_pm_if_active(rpm, wf) \
+   for ((wf) = intel_runtime_pm_get_if_active(rpm); (wf); \
+intel_runtime_pm_put((rpm), (wf)), (wf) = 0)

-:90: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'wf' - possible side-effects?
#90: FILE: drivers/gpu/drm/i915/intel_runtime_pm.h:192:
+#define with_intel_runtime_pm_if_active(rpm, wf) \
+   for ((wf) = intel_runtime_pm_get_if_active(rpm); (wf); \
+intel_runtime_pm_put((rpm), (wf)), (wf) = 0)

total: 0 errors, 0 warnings, 2 checks, 58 lines checked


___
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: settle on "adl-s" vs "adl_s" in WA comments

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: settle on "adl-s" vs "adl_s" in WA 
comments
URL   : https://patchwork.freedesktop.org/series/88299/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9882 -> Patchwork_19832


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/index.html

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0:
- fi-bsw-kefka:   [PASS][1] -> [INCOMPLETE][2] ([i915#2539])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-bsw-kefka/igt@gem_exec_susp...@basic-s0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/fi-bsw-kefka/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_huc_copy@huc-copy:
- fi-byt-j1900:   NOTRUN -> [SKIP][3] ([fdo#109271]) +27 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/fi-byt-j1900/igt@gem_huc_c...@huc-copy.html

  * igt@gem_linear_blits@basic:
- fi-kbl-8809g:   [PASS][4] -> [TIMEOUT][5] ([i915#2502] / [i915#3145])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-kbl-8809g/igt@gem_linear_bl...@basic.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/fi-kbl-8809g/igt@gem_linear_bl...@basic.html

  * igt@i915_selftest@live@client:
- fi-glk-dsi: [PASS][6] -> [DMESG-FAIL][7] ([i915#3047])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-glk-dsi/igt@i915_selftest@l...@client.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/fi-glk-dsi/igt@i915_selftest@l...@client.html

  * igt@kms_addfb_basic@bad-pitch-63:
- fi-tgl-y:   [PASS][8] -> [DMESG-WARN][9] ([i915#402])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-tgl-y/igt@kms_addfb_ba...@bad-pitch-63.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/fi-tgl-y/igt@kms_addfb_ba...@bad-pitch-63.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-byt-j1900:   NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/fi-byt-j1900/igt@kms_chamel...@hdmi-crc-fast.html

  
 Possible fixes 

  * igt@gem_mmap_gtt@basic:
- fi-tgl-y:   [DMESG-WARN][11] ([i915#402]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-tgl-y/igt@gem_mmap_...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/fi-tgl-y/igt@gem_mmap_...@basic.html

  * igt@gem_tiled_blits@basic:
- fi-kbl-8809g:   [TIMEOUT][13] ([i915#2502] / [i915#3145]) -> 
[PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-kbl-8809g/igt@gem_tiled_bl...@basic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19832/fi-kbl-8809g/igt@gem_tiled_bl...@basic.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1222]: https://gitlab.freedesktop.org/drm/intel/issues/1222
  [i915#2502]: https://gitlab.freedesktop.org/drm/intel/issues/2502
  [i915#2539]: https://gitlab.freedesktop.org/drm/intel/issues/2539
  [i915#3047]: https://gitlab.freedesktop.org/drm/intel/issues/3047
  [i915#3145]: https://gitlab.freedesktop.org/drm/intel/issues/3145
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (47 -> 43)
--

  Additional (1): fi-byt-j1900 
  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9882 -> Patchwork_19832

  CI-20190529: 20190529
  CI_DRM_9882: 34f82d5853a3c6467ccf71e055e3432d2b12ecb9 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6040: 69b578b6ab0a36750f0d23c223a3487fc88fb6a7 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19832: 4589b5d472f0d560c1fb9c86dfd7c785dc1767cb @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

4589b5d472f0 drm/i915/adl_s: add missing PCI IDs
33f10ab2431d drm/i915: settle on "adl-s" vs "adl_s" in WA comments

== Logs ==

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

Re: [Intel-gfx] [PATCH 02/11] x86: tboot: avoid Wstringop-overread-warning

[Ingo Molnar]

* Martin Sebor  wrote:

> > I.e. the real workaround might be to turn off the 
> > -Wstringop-overread-warning,
> > until GCC-11 gets fixed?
> 
> In GCC 10 -Wstringop-overread is a subset of -Wstringop-overflow.
> GCC 11 breaks it out as a separate warning to make it easier to
> control.  Both warnings have caught some real bugs but they both
> have a nonzero rate of false positives.  Other than bug reports
> we don't have enough data to say what their S/N ratio might be
> but my sense is that it's fairly high in general.
> 
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=wstringop-overread
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=wstringop-overflow
> 
> In GCC 11, all access warnings expect objects to be either declared
> or allocated.  Pointers with constant values are taken to point to
> nothing valid (as Arnd mentioned above, this is to detect invalid
> accesses to members of structs at address zero).
> 
> One possible solution to the known address problem is to extend GCC
> attributes address and io that pin an object to a hardwired address
> to all targets (at the moment they're supported on just one or two
> targets).  I'm not sure this can still happen before GCC 11 releases
> sometime in April or May.
> 
> Until then, another workaround is to convert the fixed address to
> a volatile pointer before using it for the access, along the lines
> below.  It should have only a negligible effect on efficiency.

Thank you for the detailed answer!

I think I'll go with Arnd's original patch - which makes the code a 
slightly bit cleaner by separating out the check_tboot_version() check 
into a standalone function.

The only ugly aspect is the global nature of the 'tboot' pointer - but 
that's a self-inflicted wound.

I'd also guess that the S/N ratio somewhat unfairly penalizes this 
warning right now, because the kernel had a decade of growing real 
fixes via other efforts such as static and dynamic instrumentation as 
well.

So the probability of false positive remaining is in fact higher, and 
going forward we should see a better S/N ratio of this warning. Most 
of which will never be seen by upstream maintainers, as the mishaps 
will stay at the individual developer level. :-)

Thanks,

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for Disassociate display version from INTEL_GEN() (rev3)

[Patchwork]

== Series Details ==

Series: Disassociate display version from INTEL_GEN() (rev3)
URL   : https://patchwork.freedesktop.org/series/88198/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9882 -> Patchwork_19831


Summary
---

  **FAILURE**

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

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19831/index.html

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_addfb_basic@invalid-set-prop-any:
- fi-glk-dsi: [PASS][1] -> [DMESG-WARN][2] +155 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-glk-dsi/igt@kms_addfb_ba...@invalid-set-prop-any.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19831/fi-glk-dsi/igt@kms_addfb_ba...@invalid-set-prop-any.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_flink_basic@bad-flink:
- fi-tgl-y:   [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +1 similar 
issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19831/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html

  * igt@gem_huc_copy@huc-copy:
- fi-byt-j1900:   NOTRUN -> [SKIP][5] ([fdo#109271]) +27 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19831/fi-byt-j1900/igt@gem_huc_c...@huc-copy.html

  * igt@i915_selftest@live@client:
- fi-glk-dsi: [PASS][6] -> [DMESG-FAIL][7] ([i915#3047])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-glk-dsi/igt@i915_selftest@l...@client.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19831/fi-glk-dsi/igt@i915_selftest@l...@client.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-byt-j1900:   NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19831/fi-byt-j1900/igt@kms_chamel...@hdmi-crc-fast.html

  
 Possible fixes 

  * igt@gem_exec_gttfill@basic:
- fi-kbl-8809g:   [TIMEOUT][9] ([i915#3145]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-kbl-8809g/igt@gem_exec_gttf...@basic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19831/fi-kbl-8809g/igt@gem_exec_gttf...@basic.html

  * igt@gem_mmap_gtt@basic:
- fi-tgl-y:   [DMESG-WARN][11] ([i915#402]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-tgl-y/igt@gem_mmap_...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19831/fi-tgl-y/igt@gem_mmap_...@basic.html

  
 Warnings 

  * igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [DMESG-WARN][13] ([i915#1982] / [i915#3143]) -> 
[DMESG-WARN][14] ([i915#3143])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9882/fi-glk-dsi/igt@i915_pm_...@module-reload.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19831/fi-glk-dsi/igt@i915_pm_...@module-reload.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1222]: https://gitlab.freedesktop.org/drm/intel/issues/1222
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#3047]: https://gitlab.freedesktop.org/drm/intel/issues/3047
  [i915#3143]: https://gitlab.freedesktop.org/drm/intel/issues/3143
  [i915#3145]: https://gitlab.freedesktop.org/drm/intel/issues/3145
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (47 -> 43)
--

  Additional (1): fi-byt-j1900 
  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9882 -> Patchwork_19831

  CI-20190529: 20190529
  CI_DRM_9882: 34f82d5853a3c6467ccf71e055e3432d2b12ecb9 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6040: 69b578b6ab0a36750f0d23c223a3487fc88fb6a7 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19831: ade0f920fa2677db912cc8bbdd8cee10c9a6c4ed @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

ade0f920fa26 drm/i915/display: Simplify GLK display version tests
d1ad1ea5e307 drm/i915: Conver

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Disassociate display version from INTEL_GEN() (rev3)

[Patchwork]

== Series Details ==

Series: Disassociate display version from INTEL_GEN() (rev3)
URL   : https://patchwork.freedesktop.org/series/88198/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_reset.c:1323:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gvt/mmio.c:295:23: warning: memcpy with byte count of 
279040
+drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 
16777216
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - 
different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' 
- different lock contexts for basic block


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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Disassociate display version from INTEL_GEN() (rev3)

[Patchwork]

== Series Details ==

Series: Disassociate display version from INTEL_GEN() (rev3)
URL   : https://patchwork.freedesktop.org/series/88198/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
88dec695fe5e drm/i915/display: Convert gen5/gen6 tests to 
IS_IRONLAKE/IS_SANDYBRIDGE
-:130: CHECK:CAMELCASE: Avoid CamelCase: 
#130: FILE: drivers/gpu/drm/i915/display/intel_display.c:11604:
+   if (IS_IRONLAKE(dev_priv) && (intel_de_read(dev_priv, FUSE_STRAP) & 
ILK_eDP_A_DISABLE))

total: 0 errors, 0 warnings, 1 checks, 216 lines checked
da1427ec09b6 drm/i915: Add DISPLAY_VER() and related macros
-:73: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible 
side-effects?
#73: FILE: drivers/gpu/drm/i915/i915_drv.h:1245:
+#define IS_DISPLAY_RANGE(i915, from, until) \
+   (DISPLAY_VER(i915) >= (from) && DISPLAY_VER(i915) <= (until))

-:89: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'x' - possible side-effects?
#89: FILE: drivers/gpu/drm/i915/i915_pci.c:39:
+#define GEN(x) .gen = (x), .gen_mask = BIT((x) - 1), .display.version = (x)

total: 0 errors, 0 warnings, 2 checks, 27 lines checked
3626652248c9 drm/i915/display: Eliminate most usage of INTEL_GEN()
-:2043: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 'port == 
PORT_E'
#2043: FILE: drivers/gpu/drm/i915/display/intel_display.c:6717:
+   if (DISPLAY_VER(dev_priv) < 9 &&
(port == PORT_E) && intel_de_read(dev_priv, LPT_TRANSCONF) & 
TRANS_ENABLE) {

-:2631: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional 
statements (8, 63)
#2631: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:153:
+   if (DISPLAY_VER(dev_priv) >= 9)
/* no global SR status; inspect per-plane WM */;

-:4188: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 
'intel_dp->psr_dpcd[0] == DP_PSR2_WITH_Y_COORD_IS_SUPPORTED'
#4188: FILE: drivers/gpu/drm/i915/display/intel_psr.c:324:
+   if (DISPLAY_VER(dev_priv) >= 9 &&
(intel_dp->psr_dpcd[0] == DP_PSR2_WITH_Y_COORD_IS_SUPPORTED)) {

total: 0 errors, 1 warnings, 2 checks, 4216 lines checked
1f487fdbb53e drm/i915: Convert INTEL_GEN() to DISPLAY_VER() as appropriate in 
intel_pm.c
d1ad1ea5e307 drm/i915: Convert INTEL_GEN() to DISPLAY_VER() as appropriate in 
i915_irq.c
ade0f920fa26 drm/i915/display: Simplify GLK display version tests
-:77: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#77: 
- (IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_DISPLAY_VER(dev_priv, 10))

-:385: WARNING:LONG_LINE: line length of 235 exceeds 100 columns
#385: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2419:
+   if ((DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && 
((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort && 
!to_intel_connector(connector)->mst_port) || connector->connector_type == 
DRM_MODE_CONNECTOR_eDP))

-:571: WARNING:LONG_LINE: line length of 195 exceeds 100 columns
#571: FILE: drivers/gpu/drm/i915/display/intel_vdsc.c:349:
+   if ((DISPLAY_VER(i915) >= 11 || IS_CANNONLAKE(i915)) && (pipe != PIPE_A 
|| (cpu_transcoder == TRANSCODER_EDP || cpu_transcoder == TRANSCODER_DSI_0 || 
cpu_transcoder == TRANSCODER_DSI_1)))

-:738: WARNING:LONG_LINE: line length of 104 exceeds 100 columns
#738: FILE: drivers/gpu/drm/i915/display/skl_universal_plane.c:2230:
+   if ((DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && val & 
PLANE_CTL_FLIP_HORIZONTAL)

total: 0 errors, 4 warnings, 0 checks, 516 lines checked


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

Re: [Intel-gfx] [PATCH] drm/i915/display/vlv_dsi: Do no shut down displays on reboot if a DSI panel is used

[Ville Syrjälä]

On Mon, Mar 22, 2021 at 10:28:06PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 3/22/21 9:59 PM, Ville Syrjälä wrote:
> > On Mon, Mar 22, 2021 at 04:51:47PM -0400, Rodrigo Vivi wrote:
> >> On Fri, Mar 19, 2021 at 04:45:32PM +0100, Hans de Goede wrote:
> >>> Hi,
> >>>
> >>> On 3/1/21 4:43 PM, Hans de Goede wrote:
>  After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
>  displays gracefully on reboot"), the DSI panel on a Cherry Trail based
>  Predia Basic tablet would no longer properly light up after reboot.
> 
>  The backlight still turns back on after reboot, but the LCD shows an
>  all black display. The display is also all black during the time that
>  EFI / the GOP is managing it, so e.g. the grub menu also is not visible.
> 
>  In this scenario the panel is initialized so that it appears to be 
>  working
>  and the fastboot code skips doing a modeset. Forcing a modeset by doing a
>  chvt to a text-console over ssh followed by echo-ing 1 and then 0 to
>  /sys/class/graphics/fb0/blank causes the panel to work again.
> 
>  Add a QUIRK_SKIP_SHUTDOWN quirk which turns i915_driver_shutdown() into
>  a no-op when set; and set this on vlv/chv devices when a DSI panel is
>  detected, to work around this.
> 
>  Admittedly this is a bit of a big hammer, but these platforms have been
>  around for quite some time now and they have always worked fine without
>  the new behavior to shutdown everything on shutdown/reboot. This approach
>  simply disables the recently introduced new shutdown behavior in this
>  specific case where it is known to cause problems. Which is a nice and
>  simple way to deal with this.
> 
>  Signed-off-by: Hans de Goede 
> >>>
> >>> Ping? Since sending this patch I've been seeing the issue addressed by
> >>> this on variour other CHT based devices too.
> >>>
> >>> So we have various devices suffering from a black screen after reboot
> >>> now. This is pretty serious usability regression.
> >>>
> >>> As such it would be good to get this reviewed, or another fix proposed.
> >>
> >> For the quirks we try to limit them to very specific vendor and model ids,
> >> so I wonder if it would be possible to get this information in here instead
> >> to all the vlv with dsi...
> >>
> >> Or avoid the quirk "infra" and skip to all vlv with active dsi?!
> >>
> >> Jani?
> >> Ville?
> > 
> > We need to figure out why the panel doesn't start up again.
> 
> Note it is the GOP which fails to light it up again. I think we turn something
> off, which after a power-on-reset is on, so the GOP expects it to be on.

Hmm. Do any of the reboot=warm|cold|whatever knobs make a difference?
Are there any fast vs. slow boot settings in the BIOS setup?

-- 
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.1 6/6] drm/i915/display: Simplify GLK display version tests

[Ville Syrjälä]

On Mon, Mar 22, 2021 at 02:25:12PM -0700, Matt Roper wrote:
> On Mon, Mar 22, 2021 at 11:16:28PM +0200, Ville Syrjälä wrote:
> > On Mon, Mar 22, 2021 at 12:50:17PM -0700, Matt Roper wrote:
> > > GLK has always been a bit of a special case since it reports INTEL_GEN()
> > > as 9, but has version 10 display IP.  Now we can properly represent the
> > > display version as 10 and simplify the display generation tests
> > > throughout the display code.
> > > 
> > > Aside from manually adding the version to the glk_info structure, the
> > > rest of this patch is generated with a Coccinelle semantic patch.  Note
> > > that we also need to switch any code that matches gen10 today but *not*
> > > GLK to be CNL-specific:
> > > 
> > > @@ expression dev_priv; @@
> > > - DISPLAY_VER(dev_priv) > 9
> > > + DISPLAY_VER(dev_priv) >= 10
> > > 
> > > @@ expression dev_priv, E; @@
> > > (
> > > - DISPLAY_VER(dev_priv) >= 10 && E
> > > + (DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && E
> > > |
> > > - DISPLAY_VER(dev_priv) >= 10
> > > + DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)
> > > |
> > > - IS_DISPLAY_RANGE(dev_priv, 10, E)
> > > + IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_CANNONLAKE(dev_priv)
> > > )
> > > 
> > > @@ expression dev_priv, E, E2; @@
> > > (
> > > - (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
> > > + IS_DISPLAY_VER(dev_priv, 10)
> > > |
> > > - E || IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)
> > > + E || IS_DISPLAY_VER(dev_priv, 10)
> > > |
> > > - (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv))
> > > + IS_DISPLAY_VER(dev_priv, 10)
> > > |
> > > - IS_GEMINILAKE(dev_priv) || E || IS_CANNONLAKE(dev_priv)
> > > + E || IS_DISPLAY_VER(dev_priv, 10)
> > > |
> > > - E || IS_GEMINILAKE(dev_priv) || E2 || IS_CANNONLAKE(dev_priv)
> > > + E || E2 || IS_DISPLAY_VER(dev_priv, 10)
> > 
> > Sometimes I really wish cocci would have a way to say "these things can
> > go in any order" :/
> 
> Coccinelle has support for user-defined isomorphisms that I think are
> supposed to be able to do this.  I tried to create some isomorphisms
> like:
> 
> Expression
> @ dv_no_sideeffects @
> expression dev_priv;
> int i;
> binary operator OP;
> @@
> DISPLAY_VER(dev_priv) OP i || E <=> E || DISPLAY_VER(dev_priv) OP i
> 
> for the various IS_* and DISPLAY_VER() macros so that it would allow
> them in any order (since we know these macros have no side effects), but
> I must have been doing it wrong, or passing the iso file to coccinelle
> incorrectly, since they didn't seem to be working.

Ah, thanks for pointing this out. Need to give that a try
at some point.

-- 
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] drm/i915/display/vlv_dsi: Do no shut down displays on reboot if a DSI panel is used

[Hans de Goede]

Hi,

On 3/22/21 9:59 PM, Ville Syrjälä wrote:
> On Mon, Mar 22, 2021 at 04:51:47PM -0400, Rodrigo Vivi wrote:
>> On Fri, Mar 19, 2021 at 04:45:32PM +0100, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 3/1/21 4:43 PM, Hans de Goede wrote:
 After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
 displays gracefully on reboot"), the DSI panel on a Cherry Trail based
 Predia Basic tablet would no longer properly light up after reboot.

 The backlight still turns back on after reboot, but the LCD shows an
 all black display. The display is also all black during the time that
 EFI / the GOP is managing it, so e.g. the grub menu also is not visible.

 In this scenario the panel is initialized so that it appears to be working
 and the fastboot code skips doing a modeset. Forcing a modeset by doing a
 chvt to a text-console over ssh followed by echo-ing 1 and then 0 to
 /sys/class/graphics/fb0/blank causes the panel to work again.

 Add a QUIRK_SKIP_SHUTDOWN quirk which turns i915_driver_shutdown() into
 a no-op when set; and set this on vlv/chv devices when a DSI panel is
 detected, to work around this.

 Admittedly this is a bit of a big hammer, but these platforms have been
 around for quite some time now and they have always worked fine without
 the new behavior to shutdown everything on shutdown/reboot. This approach
 simply disables the recently introduced new shutdown behavior in this
 specific case where it is known to cause problems. Which is a nice and
 simple way to deal with this.

 Signed-off-by: Hans de Goede 
>>>
>>> Ping? Since sending this patch I've been seeing the issue addressed by
>>> this on variour other CHT based devices too.
>>>
>>> So we have various devices suffering from a black screen after reboot
>>> now. This is pretty serious usability regression.
>>>
>>> As such it would be good to get this reviewed, or another fix proposed.
>>
>> For the quirks we try to limit them to very specific vendor and model ids,
>> so I wonder if it would be possible to get this information in here instead
>> to all the vlv with dsi...
>>
>> Or avoid the quirk "infra" and skip to all vlv with active dsi?!
>>
>> Jani?
>> Ville?
> 
> We need to figure out why the panel doesn't start up again.

Note it is the GOP which fails to light it up again. I think we turn something
off, which after a power-on-reset is on, so the GOP expects it to be on.

> If it has
> problems with this then surely it also fails if we just happen to reboot
> with the panel already off?

I would assume so, yes, but that only happens on say a "reboot --force"
over ssh, while the screen is off. Which are rather exceptional circumstances.

Where as just a regular reboot is quite normal and now results in a black
screen. And recovery of this condition by a normal user involves a
power-cycle by pressing the power-button for 10 seconds (these are tablets
so the force-power-off time is quite long), which most users don't even know
they can do...

> Oh a modeset fixes it? Then I guess it's just fastboot fail due to DSI
> code being crap?

This is not a fastboot issue, if I make the grub menu show every boot,
the grub-menu is also all black, as the GOP fails to properly initialize
the panel when this happens fastboot just inherits this condition.

Assuming that we want to have the EFI gfx/console work on reboot
(for say the grub menu), then disabling fastboot is not going to help.

Also note that the Windows boot-splash with the circling dots uses the
efifb, so rebooting into Windows also leads to a blackscreen at least
until Windows has booted all the way. Note I have not tried Windows,
so I don't know if Windows will recover from the black screen once
its gfx driver loads, or if it stays black then too.

> If no one is willing to fix it then I guess we just
> need to disable fastboot for DSI somehow.

See above, this is a GOP issue, so there is nothing for us to fix,
what we need to do is stop leaving the hw in a state which the GOP
cannot deal with. Which leads me to believe that we just need to disable
the "graceful shutdown" on the combination of DSI + BYT/CHT.

Regards,

Hans

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

Re: [Intel-gfx] [PATCH v2.1 6/6] drm/i915/display: Simplify GLK display version tests

[Matt Roper]

On Mon, Mar 22, 2021 at 11:16:28PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 22, 2021 at 12:50:17PM -0700, Matt Roper wrote:
> > GLK has always been a bit of a special case since it reports INTEL_GEN()
> > as 9, but has version 10 display IP.  Now we can properly represent the
> > display version as 10 and simplify the display generation tests
> > throughout the display code.
> > 
> > Aside from manually adding the version to the glk_info structure, the
> > rest of this patch is generated with a Coccinelle semantic patch.  Note
> > that we also need to switch any code that matches gen10 today but *not*
> > GLK to be CNL-specific:
> > 
> > @@ expression dev_priv; @@
> > - DISPLAY_VER(dev_priv) > 9
> > + DISPLAY_VER(dev_priv) >= 10
> > 
> > @@ expression dev_priv, E; @@
> > (
> > - DISPLAY_VER(dev_priv) >= 10 && E
> > + (DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && E
> > |
> > - DISPLAY_VER(dev_priv) >= 10
> > + DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)
> > |
> > - IS_DISPLAY_RANGE(dev_priv, 10, E)
> > + IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_CANNONLAKE(dev_priv)
> > )
> > 
> > @@ expression dev_priv, E, E2; @@
> > (
> > - (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
> > + IS_DISPLAY_VER(dev_priv, 10)
> > |
> > - E || IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)
> > + E || IS_DISPLAY_VER(dev_priv, 10)
> > |
> > - (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv))
> > + IS_DISPLAY_VER(dev_priv, 10)
> > |
> > - IS_GEMINILAKE(dev_priv) || E || IS_CANNONLAKE(dev_priv)
> > + E || IS_DISPLAY_VER(dev_priv, 10)
> > |
> > - E || IS_GEMINILAKE(dev_priv) || E2 || IS_CANNONLAKE(dev_priv)
> > + E || E2 || IS_DISPLAY_VER(dev_priv, 10)
> 
> Sometimes I really wish cocci would have a way to say "these things can
> go in any order" :/

Coccinelle has support for user-defined isomorphisms that I think are
supposed to be able to do this.  I tried to create some isomorphisms
like:

Expression
@ dv_no_sideeffects @
expression dev_priv;
int i;
binary operator OP;
@@
DISPLAY_VER(dev_priv) OP i || E <=> E || DISPLAY_VER(dev_priv) OP i

for the various IS_* and DISPLAY_VER() macros so that it would allow
them in any order (since we know these macros have no side effects), but
I must have been doing it wrong, or passing the iso file to coccinelle
incorrectly, since they didn't seem to be working.


Matt

> 
> Browsed through the resulting diff and it all looks correct to me now.
> 
> Reviewed-by: Ville Syrjälä 
> 
> Now I just need to teach myself that glk == display 10...
> 
> > |
> > - (IS_DISPLAY_VER(dev_priv, 10) || IS_GEMINILAKE(dev_priv))
> > + IS_DISPLAY_VER(dev_priv, 10)
> > |
> > - (IS_GEMINILAKE(dev_priv) || IS_DISPLAY_VER(dev_priv, 10))
> > + IS_DISPLAY_VER(dev_priv, 10)
> > )
> > 
> > @@ expression dev_priv; @@
> > - (IS_DISPLAY_VER(dev_priv, 9) && !IS_GEMINILAKE(dev_priv))
> > + IS_DISPLAY_VER(dev_priv, 9)
> > 
> > @@ expression dev_priv; @@
> > (
> > - !(DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10))
> > + DISPLAY_VER(dev_priv) < 10
> > |
> > - (DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10))
> > + DISPLAY_VER(dev_priv) >= 10
> > )
> > 
> > @@ expression dev_priv, E; @@
> > - E || DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)
> > + E || DISPLAY_VER(dev_priv) >= 10
> > 
> > @@ expression dev_priv, E; @@
> > - (IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_DISPLAY_VER(dev_priv, 
> > 10))
> > + IS_DISPLAY_RANGE(dev_priv, 10, E)
> > 
> > @@ expression dev_priv; @@
> > (
> > - DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) || 
> > IS_GEN9_LP(dev_priv)
> > + DISPLAY_VER(dev_priv) >= 10 || IS_GEN9_LP(dev_priv)
> > |
> > - IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 11 || 
> > IS_CANNONLAKE(dev_priv)
> > + IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 10
> > )
> > 
> > @@ expression dev_priv, E; @@
> > - !(DISPLAY_VER(dev_priv) >= E)
> > + DISPLAY_VER(dev_priv) < E
> > 
> > v2:
> >  - Convert gen10 conditions that don't include GLK into CNL conditions.
> >(Ville)
> > 
> > v3:
> >  - Rework coccinelle rules so that "ver>=10" turns into "ver>=11||is_cnl." 
> > (Ville)
> > 
> > v3.1:
> >  - Manually re-add the ".display.version = 10" to glk_info after
> >regenerating patch via Coccinelle.
> > 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Matt Roper 
> > ---
> >  drivers/gpu/drm/i915/display/intel_atomic.c   |  7 ++--
> >  drivers/gpu/drm/i915/display/intel_audio.c

Re: [Intel-gfx] [PATCH v2.1 6/6] drm/i915/display: Simplify GLK display version tests

[Ville Syrjälä]

On Mon, Mar 22, 2021 at 12:50:17PM -0700, Matt Roper wrote:
> GLK has always been a bit of a special case since it reports INTEL_GEN()
> as 9, but has version 10 display IP.  Now we can properly represent the
> display version as 10 and simplify the display generation tests
> throughout the display code.
> 
> Aside from manually adding the version to the glk_info structure, the
> rest of this patch is generated with a Coccinelle semantic patch.  Note
> that we also need to switch any code that matches gen10 today but *not*
> GLK to be CNL-specific:
> 
> @@ expression dev_priv; @@
> - DISPLAY_VER(dev_priv) > 9
> + DISPLAY_VER(dev_priv) >= 10
> 
> @@ expression dev_priv, E; @@
> (
> - DISPLAY_VER(dev_priv) >= 10 && E
> + (DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && E
> |
> - DISPLAY_VER(dev_priv) >= 10
> + DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)
> |
> - IS_DISPLAY_RANGE(dev_priv, 10, E)
> + IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_CANNONLAKE(dev_priv)
> )
> 
> @@ expression dev_priv, E, E2; @@
> (
> - (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
> + IS_DISPLAY_VER(dev_priv, 10)
> |
> - E || IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)
> + E || IS_DISPLAY_VER(dev_priv, 10)
> |
> - (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv))
> + IS_DISPLAY_VER(dev_priv, 10)
> |
> - IS_GEMINILAKE(dev_priv) || E || IS_CANNONLAKE(dev_priv)
> + E || IS_DISPLAY_VER(dev_priv, 10)
> |
> - E || IS_GEMINILAKE(dev_priv) || E2 || IS_CANNONLAKE(dev_priv)
> + E || E2 || IS_DISPLAY_VER(dev_priv, 10)

Sometimes I really wish cocci would have a way to say "these things can
go in any order" :/

Browsed through the resulting diff and it all looks correct to me now.

Reviewed-by: Ville Syrjälä 

Now I just need to teach myself that glk == display 10...

> |
> - (IS_DISPLAY_VER(dev_priv, 10) || IS_GEMINILAKE(dev_priv))
> + IS_DISPLAY_VER(dev_priv, 10)
> |
> - (IS_GEMINILAKE(dev_priv) || IS_DISPLAY_VER(dev_priv, 10))
> + IS_DISPLAY_VER(dev_priv, 10)
> )
> 
> @@ expression dev_priv; @@
> - (IS_DISPLAY_VER(dev_priv, 9) && !IS_GEMINILAKE(dev_priv))
> + IS_DISPLAY_VER(dev_priv, 9)
> 
> @@ expression dev_priv; @@
> (
> - !(DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10))
> + DISPLAY_VER(dev_priv) < 10
> |
> - (DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10))
> + DISPLAY_VER(dev_priv) >= 10
> )
> 
> @@ expression dev_priv, E; @@
> - E || DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)
> + E || DISPLAY_VER(dev_priv) >= 10
> 
> @@ expression dev_priv, E; @@
> - (IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_DISPLAY_VER(dev_priv, 10))
> + IS_DISPLAY_RANGE(dev_priv, 10, E)
> 
> @@ expression dev_priv; @@
> (
> - DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) || 
> IS_GEN9_LP(dev_priv)
> + DISPLAY_VER(dev_priv) >= 10 || IS_GEN9_LP(dev_priv)
> |
> - IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 11 || 
> IS_CANNONLAKE(dev_priv)
> + IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 10
> )
> 
> @@ expression dev_priv, E; @@
> - !(DISPLAY_VER(dev_priv) >= E)
> + DISPLAY_VER(dev_priv) < E
> 
> v2:
>  - Convert gen10 conditions that don't include GLK into CNL conditions.
>(Ville)
> 
> v3:
>  - Rework coccinelle rules so that "ver>=10" turns into "ver>=11||is_cnl." 
> (Ville)
> 
> v3.1:
>  - Manually re-add the ".display.version = 10" to glk_info after
>regenerating patch via Coccinelle.
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/i915/display/intel_atomic.c   |  7 ++--
>  drivers/gpu/drm/i915/display/intel_audio.c|  2 +-
>  drivers/gpu/drm/i915/display/intel_bios.c |  3 +-
>  drivers/gpu/drm/i915/display/intel_cdclk.c| 26 +++--
>  drivers/gpu/drm/i915/display/intel_color.c|  8 ++--
>  drivers/gpu/drm/i915/display/intel_crtc.c |  2 +-
>  drivers/gpu/drm/i915/display/intel_display.c  |  9 ++---
>  .../drm/i915/display/intel_display_debugfs.c  |  5 +--
>  .../drm/i915/display/intel_display_power.c|  2 +-
>  drivers/gpu/drm/i915/display/intel_dp.c   |  6 +--
>  drivers/gpu/drm/i915/display/intel_fbc.c  |  4 +-
>  drivers/gpu/drm/i915/display/intel_hdcp.c |  1 -
>  drivers/gpu/drm/i915/display/intel_hdmi.c | 13 +++
>  drivers/gpu/drm/i915/display/intel_psr.c  |  7 ++--
>  drivers/gpu/drm/i915/display/intel_vdsc.c |  6 +--
>  .../drm/i915/display/skl_universal_plane.c| 37 +--
>  drivers/gpu/drm/i915/i915_pci.c   |  1 +
>  17 files changed,

Re: [Intel-gfx] [PATCH] drm/i915/display/vlv_dsi: Do no shut down displays on reboot if a DSI panel is used

[Ville Syrjälä]

On Mon, Mar 22, 2021 at 04:51:47PM -0400, Rodrigo Vivi wrote:
> On Fri, Mar 19, 2021 at 04:45:32PM +0100, Hans de Goede wrote:
> > Hi,
> > 
> > On 3/1/21 4:43 PM, Hans de Goede wrote:
> > > After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
> > > displays gracefully on reboot"), the DSI panel on a Cherry Trail based
> > > Predia Basic tablet would no longer properly light up after reboot.
> > > 
> > > The backlight still turns back on after reboot, but the LCD shows an
> > > all black display. The display is also all black during the time that
> > > EFI / the GOP is managing it, so e.g. the grub menu also is not visible.
> > > 
> > > In this scenario the panel is initialized so that it appears to be working
> > > and the fastboot code skips doing a modeset. Forcing a modeset by doing a
> > > chvt to a text-console over ssh followed by echo-ing 1 and then 0 to
> > > /sys/class/graphics/fb0/blank causes the panel to work again.
> > > 
> > > Add a QUIRK_SKIP_SHUTDOWN quirk which turns i915_driver_shutdown() into
> > > a no-op when set; and set this on vlv/chv devices when a DSI panel is
> > > detected, to work around this.
> > > 
> > > Admittedly this is a bit of a big hammer, but these platforms have been
> > > around for quite some time now and they have always worked fine without
> > > the new behavior to shutdown everything on shutdown/reboot. This approach
> > > simply disables the recently introduced new shutdown behavior in this
> > > specific case where it is known to cause problems. Which is a nice and
> > > simple way to deal with this.
> > > 
> > > Signed-off-by: Hans de Goede 
> > 
> > Ping? Since sending this patch I've been seeing the issue addressed by
> > this on variour other CHT based devices too.
> > 
> > So we have various devices suffering from a black screen after reboot
> > now. This is pretty serious usability regression.
> > 
> > As such it would be good to get this reviewed, or another fix proposed.
> 
> For the quirks we try to limit them to very specific vendor and model ids,
> so I wonder if it would be possible to get this information in here instead
> to all the vlv with dsi...
> 
> Or avoid the quirk "infra" and skip to all vlv with active dsi?!
> 
> Jani?
> Ville?

We need to figure out why the panel doesn't start up again. If it has
problems with this then surely it also fails if we just happen to reboot
with the panel already off?

Oh a modeset fixes it? Then I guess it's just fastboot fail due to DSI
code being crap? If no one is willing to fix it then I guess we just
need to disable fastboot for DSI somehow.

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

[Intel-gfx] [PATCH v2 2/3] drm/i915: Do not set any power wells when there is no display

[José Roberto de Souza]

Power wells are only part of display block and not necessary when
running a headless driver.

Cc: Lucas De Marchi 
Signed-off-by: José Roberto de Souza 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_display_power.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 7e0eaa872350..e6a3b3e6b1f7 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -4673,7 +4673,10 @@ int intel_power_domains_init(struct drm_i915_private 
*dev_priv)
 * The enabling order will be from lower to higher indexed wells,
 * the disabling order is reversed.
 */
-   if (IS_ALDERLAKE_S(dev_priv) || IS_DG1(dev_priv)) {
+   if (!HAS_DISPLAY(dev_priv)) {
+   power_domains->power_well_count = 0;
+   err = 0;
+   } else if (IS_ALDERLAKE_S(dev_priv) || IS_DG1(dev_priv)) {
err = set_power_wells_mask(power_domains, tgl_power_wells,
   BIT_ULL(TGL_DISP_PW_TC_COLD_OFF));
} else if (IS_ROCKETLAKE(dev_priv)) {
-- 
2.31.0

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

[Intel-gfx] [PATCH v2 3/3] drm/i915: skip display initialization when there is no display

[José Roberto de Souza]

Display features should not be initialized or de-initialized when there
is no display. Skip modeset initialization, output setup, plane, crtc,
encoder, connector registration, display cdclk and rawclk
initialization, display core initialization, etc.

Skip the functionality at as high level as possible, and remove any
redundant checks. If the functionality is conditional to *other* display
checks, do not add more. If the un-initialization has checks for
initialization, do not add more.

We explicitly do not care about any GMCH/VLV/CHV code paths, as they've
always had and will have display.

Cc: Lucas De Marchi 
Signed-off-by: José Roberto de Souza 
Signed-off-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c  | 44 +++
 .../drm/i915/display/intel_display_power.c| 36 +++
 drivers/gpu/drm/i915/display/intel_dp.c   |  6 +++
 drivers/gpu/drm/i915/display/intel_gmbus.c|  3 --
 drivers/gpu/drm/i915/display/intel_hotplug.c  | 12 +
 drivers/gpu/drm/i915/display/intel_pps.c  |  5 ++-
 drivers/gpu/drm/i915/i915_drv.c   | 28 +---
 drivers/gpu/drm/i915/i915_suspend.c   |  6 +++
 8 files changed, 120 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 7b38b9a38b85..b10bf7e06ee7 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1613,6 +1613,9 @@ u32 intel_plane_fb_max_stride(struct drm_i915_private 
*dev_priv,
struct intel_crtc *crtc;
struct intel_plane *plane;
 
+   if (!HAS_DISPLAY(dev_priv))
+   return 0;
+
/*
 * We assume the primary plane for pipe A has
 * the highest stride limits of them all,
@@ -4629,6 +4632,9 @@ int intel_display_suspend(struct drm_device *dev)
struct drm_atomic_state *state;
int ret;
 
+   if (!HAS_DISPLAY(dev_priv))
+   return 0;
+
state = drm_atomic_helper_suspend(dev);
ret = PTR_ERR_OR_ZERO(state);
if (ret)
@@ -12239,6 +12245,9 @@ static const struct drm_mode_config_funcs 
intel_mode_funcs = {
  */
 void intel_init_display_hooks(struct drm_i915_private *dev_priv)
 {
+   if (!HAS_DISPLAY(dev_priv))
+   return;
+
intel_init_cdclk_hooks(dev_priv);
intel_init_audio_hooks(dev_priv);
 
@@ -12281,8 +12290,12 @@ void intel_init_display_hooks(struct drm_i915_private 
*dev_priv)
 
 void intel_modeset_init_hw(struct drm_i915_private *i915)
 {
-   struct intel_cdclk_state *cdclk_state =
-   to_intel_cdclk_state(i915->cdclk.obj.state);
+   struct intel_cdclk_state *cdclk_state;
+
+   if (!HAS_DISPLAY(i915))
+   return;
+
+   cdclk_state = to_intel_cdclk_state(i915->cdclk.obj.state);
 
intel_update_cdclk(i915);
intel_dump_cdclk_config(&i915->cdclk.hw, "Current CDCLK");
@@ -12598,6 +12611,9 @@ int intel_modeset_init_noirq(struct drm_i915_private 
*i915)
/* FIXME: completely on the wrong abstraction layer */
intel_power_domains_init_hw(i915, false);
 
+   if (!HAS_DISPLAY(i915))
+   return 0;
+
intel_csr_ucode_init(i915);
 
i915->modeset_wq = alloc_ordered_workqueue("i915_modeset", 0);
@@ -12648,6 +12664,9 @@ int intel_modeset_init_nogem(struct drm_i915_private 
*i915)
struct intel_crtc *crtc;
int ret;
 
+   if (!HAS_DISPLAY(i915))
+   return 0;
+
intel_init_pm(i915);
 
intel_panel_sanitize_ssc(i915);
@@ -12660,13 +12679,11 @@ int intel_modeset_init_nogem(struct drm_i915_private 
*i915)
INTEL_NUM_PIPES(i915),
INTEL_NUM_PIPES(i915) > 1 ? "s" : "");
 
-   if (HAS_DISPLAY(i915)) {
-   for_each_pipe(i915, pipe) {
-   ret = intel_crtc_init(i915, pipe);
-   if (ret) {
-   intel_mode_config_cleanup(i915);
-   return ret;
-   }
+   for_each_pipe(i915, pipe) {
+   ret = intel_crtc_init(i915, pipe);
+   if (ret) {
+   intel_mode_config_cleanup(i915);
+   return ret;
}
}
 
@@ -13602,6 +13619,9 @@ void intel_display_resume(struct drm_device *dev)
struct drm_modeset_acquire_ctx ctx;
int ret;
 
+   if (!HAS_DISPLAY(dev_priv))
+   return;
+
dev_priv->modeset_restore_state = NULL;
if (state)
state->acquire_ctx = &ctx;
@@ -13651,6 +13671,9 @@ static void intel_hpd_poll_fini(struct drm_i915_private 
*i915)
 /* part #1: call before irq uninstall */
 void intel_modeset_driver_remove(struct drm_i915_private *i915)
 {
+   if (!HAS_DISPLAY(i915))
+   return;
+
flush_workqueue(i915->flip_wq);
flush_workqueue(i915-

[Intel-gfx] [PATCH v2 1/3] drm/i915: Skip display interruption setup when display is not available

[José Roberto de Souza]

Return ealier in the functions doing interruption setup for GEN8+ also
adding a warning in gen8_de_irq_handler() to let us know that
something else is still missing.

Cc: Ville Syrjälä 
Cc: Lucas De Marchi 
Signed-off-by: José Roberto de Souza 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_irq.c | 39 +++--
 1 file changed, 32 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 44aed4cbf894..875829f8a190 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2421,6 +2421,8 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
u32 master_ctl)
u32 iir;
enum pipe pipe;
 
+   drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_DISPLAY(dev_priv));
+
if (master_ctl & GEN8_DE_MISC_IRQ) {
iir = intel_uncore_read(&dev_priv->uncore, GEN8_DE_MISC_IIR);
if (iir) {
@@ -3058,14 +3060,13 @@ static void cnp_display_clock_wa(struct 
drm_i915_private *dev_priv)
}
 }
 
-static void gen8_irq_reset(struct drm_i915_private *dev_priv)
+static void gen8_display_irq_reset(struct drm_i915_private *dev_priv)
 {
struct intel_uncore *uncore = &dev_priv->uncore;
enum pipe pipe;
 
-   gen8_master_intr_disable(dev_priv->uncore.regs);
-
-   gen8_gt_irq_reset(&dev_priv->gt);
+   if (!HAS_DISPLAY(dev_priv))
+   return;
 
intel_uncore_write(uncore, EDP_PSR_IMR, 0x);
intel_uncore_write(uncore, EDP_PSR_IIR, 0x);
@@ -3077,6 +3078,16 @@ static void gen8_irq_reset(struct drm_i915_private 
*dev_priv)
 
GEN3_IRQ_RESET(uncore, GEN8_DE_PORT_);
GEN3_IRQ_RESET(uncore, GEN8_DE_MISC_);
+}
+
+static void gen8_irq_reset(struct drm_i915_private *dev_priv)
+{
+   struct intel_uncore *uncore = &dev_priv->uncore;
+
+   gen8_master_intr_disable(dev_priv->uncore.regs);
+
+   gen8_gt_irq_reset(&dev_priv->gt);
+   gen8_display_irq_reset(dev_priv);
GEN3_IRQ_RESET(uncore, GEN8_PCU_);
 
if (HAS_PCH_SPLIT(dev_priv))
@@ -3092,6 +3103,9 @@ static void gen11_display_irq_reset(struct 
drm_i915_private *dev_priv)
u32 trans_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) |
BIT(TRANSCODER_C) | BIT(TRANSCODER_D);
 
+   if (!HAS_DISPLAY(dev_priv))
+   return;
+
intel_uncore_write(uncore, GEN11_DISPLAY_INT_CTL, 0);
 
if (INTEL_GEN(dev_priv) >= 12) {
@@ -3714,6 +3728,9 @@ static void gen8_de_irq_postinstall(struct 
drm_i915_private *dev_priv)
BIT(TRANSCODER_C) | BIT(TRANSCODER_D);
enum pipe pipe;
 
+   if (!HAS_DISPLAY(dev_priv))
+   return;
+
if (INTEL_GEN(dev_priv) <= 10)
de_misc_masked |= GEN8_DE_MISC_GSE;
 
@@ -3797,6 +3814,16 @@ static void gen8_irq_postinstall(struct drm_i915_private 
*dev_priv)
gen8_master_intr_enable(dev_priv->uncore.regs);
 }
 
+static void gen11_de_irq_postinstall(struct drm_i915_private *dev_priv)
+{
+   if (!HAS_DISPLAY(dev_priv))
+   return;
+
+   gen8_de_irq_postinstall(dev_priv);
+
+   intel_uncore_write(&dev_priv->uncore, GEN11_DISPLAY_INT_CTL,
+  GEN11_DISPLAY_IRQ_ENABLE);
+}
 
 static void gen11_irq_postinstall(struct drm_i915_private *dev_priv)
 {
@@ -3807,12 +3834,10 @@ static void gen11_irq_postinstall(struct 
drm_i915_private *dev_priv)
icp_irq_postinstall(dev_priv);
 
gen11_gt_irq_postinstall(&dev_priv->gt);
-   gen8_de_irq_postinstall(dev_priv);
+   gen11_de_irq_postinstall(dev_priv);
 
GEN3_IRQ_INIT(uncore, GEN11_GU_MISC_, ~gu_misc_masked, gu_misc_masked);
 
-   intel_uncore_write(&dev_priv->uncore, GEN11_DISPLAY_INT_CTL, 
GEN11_DISPLAY_IRQ_ENABLE);
-
if (HAS_MASTER_UNIT_IRQ(dev_priv)) {
dg1_master_intr_enable(uncore->regs);
intel_uncore_posting_read(&dev_priv->uncore, 
DG1_MSTR_UNIT_INTR);
-- 
2.31.0

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

Re: [Intel-gfx] [PATCH] drm/i915/display/vlv_dsi: Do no shut down displays on reboot if a DSI panel is used

[Rodrigo Vivi]

On Fri, Mar 19, 2021 at 04:45:32PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 3/1/21 4:43 PM, Hans de Goede wrote:
> > After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
> > displays gracefully on reboot"), the DSI panel on a Cherry Trail based
> > Predia Basic tablet would no longer properly light up after reboot.
> > 
> > The backlight still turns back on after reboot, but the LCD shows an
> > all black display. The display is also all black during the time that
> > EFI / the GOP is managing it, so e.g. the grub menu also is not visible.
> > 
> > In this scenario the panel is initialized so that it appears to be working
> > and the fastboot code skips doing a modeset. Forcing a modeset by doing a
> > chvt to a text-console over ssh followed by echo-ing 1 and then 0 to
> > /sys/class/graphics/fb0/blank causes the panel to work again.
> > 
> > Add a QUIRK_SKIP_SHUTDOWN quirk which turns i915_driver_shutdown() into
> > a no-op when set; and set this on vlv/chv devices when a DSI panel is
> > detected, to work around this.
> > 
> > Admittedly this is a bit of a big hammer, but these platforms have been
> > around for quite some time now and they have always worked fine without
> > the new behavior to shutdown everything on shutdown/reboot. This approach
> > simply disables the recently introduced new shutdown behavior in this
> > specific case where it is known to cause problems. Which is a nice and
> > simple way to deal with this.
> > 
> > Signed-off-by: Hans de Goede 
> 
> Ping? Since sending this patch I've been seeing the issue addressed by
> this on variour other CHT based devices too.
> 
> So we have various devices suffering from a black screen after reboot
> now. This is pretty serious usability regression.
> 
> As such it would be good to get this reviewed, or another fix proposed.

For the quirks we try to limit them to very specific vendor and model ids,
so I wonder if it would be possible to get this information in here instead
to all the vlv with dsi...

Or avoid the quirk "infra" and skip to all vlv with active dsi?!

Jani?
Ville?

> 
> Regards,
> 
> Hans
> 
> 
> 
> > ---
> >  drivers/gpu/drm/i915/display/vlv_dsi.c | 3 +++
> >  drivers/gpu/drm/i915/i915_drv.c| 3 +++
> >  drivers/gpu/drm/i915/i915_drv.h| 1 +
> >  3 files changed, 7 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c 
> > b/drivers/gpu/drm/i915/display/vlv_dsi.c
> > index f94025ec603a..792ef868b6af 100644
> > --- a/drivers/gpu/drm/i915/display/vlv_dsi.c
> > +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
> > @@ -1949,6 +1949,9 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
> >  
> > vlv_dsi_add_properties(intel_connector);
> >  
> > +   /* Some BIOS-es fail to re-init the DSI panel on reboot if we turn it 
> > off */
> > +   dev_priv->quirks |= QUIRK_SKIP_SHUTDOWN;
> > +
> > return;
> >  
> >  err_cleanup_connector:
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 8e9cb44e66e5..92f2af55af6d 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1048,6 +1048,9 @@ static void intel_shutdown_encoders(struct 
> > drm_i915_private *dev_priv)
> >  
> >  void i915_driver_shutdown(struct drm_i915_private *i915)
> >  {
> > +   if (i915->quirks & QUIRK_SKIP_SHUTDOWN)
> > +   return;
> > +
> > disable_rpm_wakeref_asserts(&i915->runtime_pm);
> >  
> > i915_gem_suspend(i915);
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 26d69d06aa6d..272cd7cb22d4 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -517,6 +517,7 @@ struct i915_psr {
> >  #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> >  #define QUIRK_INCREASE_T12_DELAY (1<<6)
> >  #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
> > +#define QUIRK_SKIP_SHUTDOWN (1<<8)
> >  
> >  struct intel_fbdev;
> >  struct intel_fbc_work;
> > 
> 
> ___
> 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 the GT fence revocation runtime PM logic

[Imre Deak]

To optimize some task deferring it until runtime resume unless someone
holds a runtime PM reference (because in this case the task can be done
w/o the overhead of runtime resume), we have to use the runtime PM
get-if-active logic: If the runtime PM usage count is 0 (and so
get-if-in-use would return false) the runtime suspend handler is not
necessarily called yet (it could be just pending), so the device is not
necessarily powered down, and so the runtime resume handler is not
guaranteed to be called.

The fence revocation depends on the above deferral, so add a
get-if-active helper and use it during fence revocation.

Cc: Chris Wilson 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c |  2 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c  | 15 +--
 drivers/gpu/drm/i915/intel_runtime_pm.h  |  5 +
 3 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index e891552611d5a..f81bc7df83a38 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -298,7 +298,7 @@ void i915_vma_revoke_fence(struct i915_vma *vma)
WRITE_ONCE(fence->vma, NULL);
vma->fence = NULL;
 
-   with_intel_runtime_pm_if_in_use(fence_to_uncore(fence)->rpm, wakeref)
+   with_intel_runtime_pm_if_active(fence_to_uncore(fence)->rpm, wakeref)
fence_write(fence);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 4970ef0843dcd..404e99078cc49 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -425,7 +425,8 @@ intel_wakeref_t intel_runtime_pm_get(struct 
intel_runtime_pm *rpm)
  * Returns: the wakeref cookie to pass to intel_runtime_pm_put(), evaluates
  * as True if the wakeref was acquired, or False otherwise.
  */
-intel_wakeref_t intel_runtime_pm_get_if_in_use(struct intel_runtime_pm *rpm)
+static intel_wakeref_t __intel_runtime_pm_get_if_active(struct 
intel_runtime_pm *rpm,
+   bool ignore_usecount)
 {
if (IS_ENABLED(CONFIG_PM)) {
/*
@@ -434,7 +435,7 @@ intel_wakeref_t intel_runtime_pm_get_if_in_use(struct 
intel_runtime_pm *rpm)
 * function, since the power state is undefined. This applies
 * atm to the late/early system suspend/resume handlers.
 */
-   if (pm_runtime_get_if_in_use(rpm->kdev) <= 0)
+   if (pm_runtime_get_if_active(rpm->kdev, ignore_usecount) <= 0)
return 0;
}
 
@@ -443,6 +444,16 @@ intel_wakeref_t intel_runtime_pm_get_if_in_use(struct 
intel_runtime_pm *rpm)
return track_intel_runtime_pm_wakeref(rpm);
 }
 
+intel_wakeref_t intel_runtime_pm_get_if_in_use(struct intel_runtime_pm *rpm)
+{
+   return __intel_runtime_pm_get_if_active(rpm, false);
+}
+
+intel_wakeref_t intel_runtime_pm_get_if_active(struct intel_runtime_pm *rpm)
+{
+   return __intel_runtime_pm_get_if_active(rpm, true);
+}
+
 /**
  * intel_runtime_pm_get_noresume - grab a runtime pm reference
  * @rpm: the intel_runtime_pm structure
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.h 
b/drivers/gpu/drm/i915/intel_runtime_pm.h
index ae64ff14c6425..1e4ddd11c12bb 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.h
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.h
@@ -177,6 +177,7 @@ void intel_runtime_pm_driver_release(struct 
intel_runtime_pm *rpm);
 
 intel_wakeref_t intel_runtime_pm_get(struct intel_runtime_pm *rpm);
 intel_wakeref_t intel_runtime_pm_get_if_in_use(struct intel_runtime_pm *rpm);
+intel_wakeref_t intel_runtime_pm_get_if_active(struct intel_runtime_pm *rpm);
 intel_wakeref_t intel_runtime_pm_get_noresume(struct intel_runtime_pm *rpm);
 intel_wakeref_t intel_runtime_pm_get_raw(struct intel_runtime_pm *rpm);
 
@@ -188,6 +189,10 @@ intel_wakeref_t intel_runtime_pm_get_raw(struct 
intel_runtime_pm *rpm);
for ((wf) = intel_runtime_pm_get_if_in_use(rpm); (wf); \
 intel_runtime_pm_put((rpm), (wf)), (wf) = 0)
 
+#define with_intel_runtime_pm_if_active(rpm, wf) \
+   for ((wf) = intel_runtime_pm_get_if_active(rpm); (wf); \
+intel_runtime_pm_put((rpm), (wf)), (wf) = 0)
+
 void intel_runtime_pm_put_unchecked(struct intel_runtime_pm *rpm);
 #if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
 void intel_runtime_pm_put(struct intel_runtime_pm *rpm, intel_wakeref_t wref);
-- 
2.25.1

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

Re: [Intel-gfx] [PATCH 02/11] x86: tboot: avoid Wstringop-overread-warning

[Ingo Molnar]

* Arnd Bergmann  wrote:

> From: Arnd Bergmann 
> 
> gcc-11 warns about using string operations on pointers that are
> defined at compile time as offsets from a NULL pointer. Unfortunately
> that also happens on the result of fix_to_virt(), which is a
> compile-time constant for a constantn input:
> 
> arch/x86/kernel/tboot.c: In function 'tboot_probe':
> arch/x86/kernel/tboot.c:70:13: error: '__builtin_memcmp_eq' specified bound 
> 16 exceeds source size 0 [-Werror=stringop-overread]
>70 | if (memcmp(&tboot_uuid, &tboot->uuid, sizeof(tboot->uuid))) {
>   | ^~
> 
> I hope this can get addressed in gcc-11 before the release.
> 
> As a workaround, split up the tboot_probe() function in two halves
> to separate the pointer generation from the usage. This is a bit
> ugly, and hopefully gcc understands that the code is actually correct
> before it learns to peek into the noinline function.
> 
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
> Signed-off-by: Arnd Bergmann 
> ---
>  arch/x86/kernel/tboot.c | 44 -
>  1 file changed, 26 insertions(+), 18 deletions(-)
> 
> diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c
> index 4c09ba110204..f9af561c3cd4 100644
> --- a/arch/x86/kernel/tboot.c
> +++ b/arch/x86/kernel/tboot.c
> @@ -49,6 +49,30 @@ bool tboot_enabled(void)
>   return tboot != NULL;
>  }
>  
> +/* noinline to prevent gcc from warning about dereferencing constant fixaddr 
> */
> +static noinline __init bool check_tboot_version(void)
> +{
> + if (memcmp(&tboot_uuid, &tboot->uuid, sizeof(tboot->uuid))) {
> + pr_warn("tboot at 0x%llx is invalid\n", boot_params.tboot_addr);
> + return false;
> + }
> +
> + if (tboot->version < 5) {
> + pr_warn("tboot version is invalid: %u\n", tboot->version);
> + return false;
> + }
> +
> + pr_info("found shared page at phys addr 0x%llx:\n",
> + boot_params.tboot_addr);
> + pr_debug("version: %d\n", tboot->version);
> + pr_debug("log_addr: 0x%08x\n", tboot->log_addr);
> + pr_debug("shutdown_entry: 0x%x\n", tboot->shutdown_entry);
> + pr_debug("tboot_base: 0x%08x\n", tboot->tboot_base);
> + pr_debug("tboot_size: 0x%x\n", tboot->tboot_size);
> +
> + return true;
> +}
> +
>  void __init tboot_probe(void)
>  {
>   /* Look for valid page-aligned address for shared page. */
> @@ -66,25 +90,9 @@ void __init tboot_probe(void)
>  
>   /* Map and check for tboot UUID. */
>   set_fixmap(FIX_TBOOT_BASE, boot_params.tboot_addr);
> - tboot = (struct tboot *)fix_to_virt(FIX_TBOOT_BASE);
> - if (memcmp(&tboot_uuid, &tboot->uuid, sizeof(tboot->uuid))) {
> - pr_warn("tboot at 0x%llx is invalid\n", boot_params.tboot_addr);
> + tboot = (void *)fix_to_virt(FIX_TBOOT_BASE);
> + if (!check_tboot_version())
>   tboot = NULL;
> - return;
> - }
> - if (tboot->version < 5) {
> - pr_warn("tboot version is invalid: %u\n", tboot->version);
> - tboot = NULL;
> - return;
> - }
> -
> - pr_info("found shared page at phys addr 0x%llx:\n",
> - boot_params.tboot_addr);
> - pr_debug("version: %d\n", tboot->version);
> - pr_debug("log_addr: 0x%08x\n", tboot->log_addr);
> - pr_debug("shutdown_entry: 0x%x\n", tboot->shutdown_entry);
> - pr_debug("tboot_base: 0x%08x\n", tboot->tboot_base);
> - pr_debug("tboot_size: 0x%x\n", tboot->tboot_size);

This is indeed rather ugly - and the other patch that removes a debug 
check seems counterproductive as well.

Do we know how many genuine bugs -Wstringop-overread-warning has 
caught or is about to catch?

I.e. the real workaround might be to turn off the -Wstringop-overread-warning,
until GCC-11 gets fixed?

Thanks,

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

[Intel-gfx] [PATCH 2/2] drm/i915/adl_s: add missing PCI IDs

[Lucas De Marchi]

Synchronize our PCI IDs with the list in Bspec 53655.

Signed-off-by: Lucas De Marchi 
---
 include/drm/i915_pciids.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index ebd0dd1c35b3..3be25768321d 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -640,6 +640,8 @@
INTEL_VGA_DEVICE(0x4681, info), \
INTEL_VGA_DEVICE(0x4682, info), \
INTEL_VGA_DEVICE(0x4683, info), \
+   INTEL_VGA_DEVICE(0x4688, info), \
+   INTEL_VGA_DEVICE(0x4689, info), \
INTEL_VGA_DEVICE(0x4690, info), \
INTEL_VGA_DEVICE(0x4691, info), \
INTEL_VGA_DEVICE(0x4692, info), \
-- 
2.31.0

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

[Intel-gfx] [PATCH 1/2] drm/i915: settle on "adl-s" vs "adl_s" in WA comments

[Lucas De Marchi]

Everywhere else we use "adl-s" to Refer to a WA for Alder Lake-S. So
avoid mixing dashes with underscores.

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/intel_pm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4c07745a6fdb..14156f55e07c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7131,7 +7131,7 @@ static void icl_init_clock_gating(struct drm_i915_private 
*dev_priv)
 
 static void gen12lp_init_clock_gating(struct drm_i915_private *dev_priv)
 {
-   /* Wa_1409120013:tgl,rkl,adl_s,dg1 */
+   /* Wa_1409120013:tgl,rkl,adl-s,dg1 */
intel_uncore_write(&dev_priv->uncore, ILK_DPFC_CHICKEN,
   ILK_DPFC_CHICKEN_COMP_DUMMY_PIXEL);
 
@@ -7140,7 +7140,7 @@ static void gen12lp_init_clock_gating(struct 
drm_i915_private *dev_priv)
intel_uncore_write(&dev_priv->uncore, GEN9_CLKGATE_DIS_3, 
intel_uncore_read(&dev_priv->uncore, GEN9_CLKGATE_DIS_3) |
   TGL_VRH_GATING_DIS);
 
-   /* Wa_14011059788:tgl,rkl,adl_s,dg1 */
+   /* Wa_14011059788:tgl,rkl,adl-s,dg1 */
intel_uncore_rmw(&dev_priv->uncore, GEN10_DFR_RATIO_EN_AND_CHICKEN,
 0, DFR_DISABLE);
 }
-- 
2.31.0

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

[Intel-gfx] [PATCH v2.1 6/6] drm/i915/display: Simplify GLK display version tests

[Matt Roper]

GLK has always been a bit of a special case since it reports INTEL_GEN()
as 9, but has version 10 display IP.  Now we can properly represent the
display version as 10 and simplify the display generation tests
throughout the display code.

Aside from manually adding the version to the glk_info structure, the
rest of this patch is generated with a Coccinelle semantic patch.  Note
that we also need to switch any code that matches gen10 today but *not*
GLK to be CNL-specific:

@@ expression dev_priv; @@
- DISPLAY_VER(dev_priv) > 9
+ DISPLAY_VER(dev_priv) >= 10

@@ expression dev_priv, E; @@
(
- DISPLAY_VER(dev_priv) >= 10 && E
+ (DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && E
|
- DISPLAY_VER(dev_priv) >= 10
+ DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)
|
- IS_DISPLAY_RANGE(dev_priv, 10, E)
+ IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_CANNONLAKE(dev_priv)
)

@@ expression dev_priv, E, E2; @@
(
- (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
+ IS_DISPLAY_VER(dev_priv, 10)
|
- E || IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)
+ E || IS_DISPLAY_VER(dev_priv, 10)
|
- (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv))
+ IS_DISPLAY_VER(dev_priv, 10)
|
- IS_GEMINILAKE(dev_priv) || E || IS_CANNONLAKE(dev_priv)
+ E || IS_DISPLAY_VER(dev_priv, 10)
|
- E || IS_GEMINILAKE(dev_priv) || E2 || IS_CANNONLAKE(dev_priv)
+ E || E2 || IS_DISPLAY_VER(dev_priv, 10)
|
- (IS_DISPLAY_VER(dev_priv, 10) || IS_GEMINILAKE(dev_priv))
+ IS_DISPLAY_VER(dev_priv, 10)
|
- (IS_GEMINILAKE(dev_priv) || IS_DISPLAY_VER(dev_priv, 10))
+ IS_DISPLAY_VER(dev_priv, 10)
)

@@ expression dev_priv; @@
- (IS_DISPLAY_VER(dev_priv, 9) && !IS_GEMINILAKE(dev_priv))
+ IS_DISPLAY_VER(dev_priv, 9)

@@ expression dev_priv; @@
(
- !(DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10))
+ DISPLAY_VER(dev_priv) < 10
|
- (DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10))
+ DISPLAY_VER(dev_priv) >= 10
)

@@ expression dev_priv, E; @@
- E || DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)
+ E || DISPLAY_VER(dev_priv) >= 10

@@ expression dev_priv, E; @@
- (IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_DISPLAY_VER(dev_priv, 10))
+ IS_DISPLAY_RANGE(dev_priv, 10, E)

@@ expression dev_priv; @@
(
- DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) || 
IS_GEN9_LP(dev_priv)
+ DISPLAY_VER(dev_priv) >= 10 || IS_GEN9_LP(dev_priv)
|
- IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 11 || 
IS_CANNONLAKE(dev_priv)
+ IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 10
)

@@ expression dev_priv, E; @@
- !(DISPLAY_VER(dev_priv) >= E)
+ DISPLAY_VER(dev_priv) < E

v2:
 - Convert gen10 conditions that don't include GLK into CNL conditions.
   (Ville)

v3:
 - Rework coccinelle rules so that "ver>=10" turns into "ver>=11||is_cnl." 
(Ville)

v3.1:
 - Manually re-add the ".display.version = 10" to glk_info after
   regenerating patch via Coccinelle.

Cc: Ville Syrjälä 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/display/intel_atomic.c   |  7 ++--
 drivers/gpu/drm/i915/display/intel_audio.c|  2 +-
 drivers/gpu/drm/i915/display/intel_bios.c |  3 +-
 drivers/gpu/drm/i915/display/intel_cdclk.c| 26 +++--
 drivers/gpu/drm/i915/display/intel_color.c|  8 ++--
 drivers/gpu/drm/i915/display/intel_crtc.c |  2 +-
 drivers/gpu/drm/i915/display/intel_display.c  |  9 ++---
 .../drm/i915/display/intel_display_debugfs.c  |  5 +--
 .../drm/i915/display/intel_display_power.c|  2 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |  6 +--
 drivers/gpu/drm/i915/display/intel_fbc.c  |  4 +-
 drivers/gpu/drm/i915/display/intel_hdcp.c |  1 -
 drivers/gpu/drm/i915/display/intel_hdmi.c | 13 +++
 drivers/gpu/drm/i915/display/intel_psr.c  |  7 ++--
 drivers/gpu/drm/i915/display/intel_vdsc.c |  6 +--
 .../drm/i915/display/skl_universal_plane.c| 37 +--
 drivers/gpu/drm/i915/i915_pci.c   |  1 +
 17 files changed, 64 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 2b928795755e..4fa389fce8cb 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -332,8 +332,7 @@ static void intel_atomic_setup_scaler(struct 
intel_crtc_scaler_state *scaler_sta
plane_state->hw.fb->format->is_yuv &&
plane_state->hw.fb->format->num_planes > 1) {
struct intel_plane *plane = 
to_intel_plane(pl

[Intel-gfx] [PATCH v2 6/6] drm/i915/display: Simplify GLK display version tests

[Matt Roper]

GLK has always been a bit of a special case since it reports INTEL_GEN()
as 9, but has version 10 display IP.  Now we can properly represent the
display version as 10 and simplify the display generation tests
throughout the display code.

Aside from manually adding the version to the glk_info structure, the
rest of this patch is generated with a Coccinelle semantic patch.  Note
that we also need to switch any code that matches gen10 today but *not*
GLK to be CNL-specific:

@@ expression dev_priv; @@
- DISPLAY_VER(dev_priv) > 9
+ DISPLAY_VER(dev_priv) >= 10

@@ expression dev_priv, E; @@
(
- DISPLAY_VER(dev_priv) >= 10 && E
+ (DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && E
|
- DISPLAY_VER(dev_priv) >= 10
+ DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)
|
- IS_DISPLAY_RANGE(dev_priv, 10, E)
+ IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_CANNONLAKE(dev_priv)
)

@@ expression dev_priv, E, E2; @@
(
- (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
+ IS_DISPLAY_VER(dev_priv, 10)
|
- E || IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)
+ E || IS_DISPLAY_VER(dev_priv, 10)
|
- (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv))
+ IS_DISPLAY_VER(dev_priv, 10)
|
- IS_GEMINILAKE(dev_priv) || E || IS_CANNONLAKE(dev_priv)
+ E || IS_DISPLAY_VER(dev_priv, 10)
|
- E || IS_GEMINILAKE(dev_priv) || E2 || IS_CANNONLAKE(dev_priv)
+ E || E2 || IS_DISPLAY_VER(dev_priv, 10)
|
- (IS_DISPLAY_VER(dev_priv, 10) || IS_GEMINILAKE(dev_priv))
+ IS_DISPLAY_VER(dev_priv, 10)
|
- (IS_GEMINILAKE(dev_priv) || IS_DISPLAY_VER(dev_priv, 10))
+ IS_DISPLAY_VER(dev_priv, 10)
)

@@ expression dev_priv; @@
- (IS_DISPLAY_VER(dev_priv, 9) && !IS_GEMINILAKE(dev_priv))
+ IS_DISPLAY_VER(dev_priv, 9)

@@ expression dev_priv; @@
(
- !(DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10))
+ DISPLAY_VER(dev_priv) < 10
|
- (DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10))
+ DISPLAY_VER(dev_priv) >= 10
)

@@ expression dev_priv, E; @@
- E || DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)
+ E || DISPLAY_VER(dev_priv) >= 10

@@ expression dev_priv, E; @@
- (IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_DISPLAY_VER(dev_priv, 10))
+ IS_DISPLAY_RANGE(dev_priv, 10, E)

@@ expression dev_priv; @@
(
- DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) || 
IS_GEN9_LP(dev_priv)
+ DISPLAY_VER(dev_priv) >= 10 || IS_GEN9_LP(dev_priv)
|
- IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 11 || 
IS_CANNONLAKE(dev_priv)
+ IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 10
)

@@ expression dev_priv, E; @@
- !(DISPLAY_VER(dev_priv) >= E)
+ DISPLAY_VER(dev_priv) < E

v2:
 - Convert gen10 conditions that don't include GLK into CNL conditions.
   (Ville)

v3:
 - Rework coccinelle rules so that "ver>=10" turns into "ver>=11||is_cnl." 
(Ville)

Cc: Ville Syrjälä 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/display/intel_atomic.c   |  7 ++--
 drivers/gpu/drm/i915/display/intel_audio.c|  2 +-
 drivers/gpu/drm/i915/display/intel_bios.c |  3 +-
 drivers/gpu/drm/i915/display/intel_cdclk.c| 26 +++--
 drivers/gpu/drm/i915/display/intel_color.c|  8 ++--
 drivers/gpu/drm/i915/display/intel_crtc.c |  2 +-
 drivers/gpu/drm/i915/display/intel_display.c  |  9 ++---
 .../drm/i915/display/intel_display_debugfs.c  |  5 +--
 .../drm/i915/display/intel_display_power.c|  2 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |  6 +--
 drivers/gpu/drm/i915/display/intel_fbc.c  |  4 +-
 drivers/gpu/drm/i915/display/intel_hdcp.c |  1 -
 drivers/gpu/drm/i915/display/intel_hdmi.c | 13 +++
 drivers/gpu/drm/i915/display/intel_psr.c  |  7 ++--
 drivers/gpu/drm/i915/display/intel_vdsc.c |  6 +--
 .../drm/i915/display/skl_universal_plane.c| 37 +--
 16 files changed, 63 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 2b928795755e..4fa389fce8cb 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -332,8 +332,7 @@ static void intel_atomic_setup_scaler(struct 
intel_crtc_scaler_state *scaler_sta
plane_state->hw.fb->format->is_yuv &&
plane_state->hw.fb->format->num_planes > 1) {
struct intel_plane *plane = 
to_intel_plane(plane_state->uapi.plane);
-   if (IS_DISPLAY_VER(dev_priv, 9) &&
-   !IS_GEMINILAKE(dev_priv)) {
+   if (IS_DISPLAY_VER(dev_pr

[Intel-gfx] ✓ Fi.CI.BAT: success for treewide: address gcc-11 -Wstringop-overread warnings

[Patchwork]

== Series Details ==

Series: treewide: address gcc-11 -Wstringop-overread warnings
URL   : https://patchwork.freedesktop.org/series/88295/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9880 -> Patchwork_19830


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19830/index.html

Possible new issues
---

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

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_exec_fence@nb-await@vcs0:
- {fi-rkl-11500t}:NOTRUN -> [FAIL][1] +38 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19830/fi-rkl-11500t/igt@gem_exec_fence@nb-aw...@vcs0.html

  * igt@prime_vgem@basic-read:
- {fi-rkl-11500t}:NOTRUN -> [SKIP][2] +3 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19830/fi-rkl-11500t/igt@prime_v...@basic-read.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-y:   NOTRUN -> [SKIP][3] ([fdo#109315])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19830/fi-tgl-y/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_basic@semaphore:
- fi-icl-y:   NOTRUN -> [SKIP][4] ([fdo#109315]) +17 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19830/fi-icl-y/igt@amdgpu/amd_ba...@semaphore.html

  * igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-tgl-y:   NOTRUN -> [SKIP][5] ([fdo#109315] / [i915#2575]) +16 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19830/fi-tgl-y/igt@amdgpu/amd_cs_...@fork-gfx0.html

  * igt@debugfs_test@read_all_entries:
- fi-tgl-y:   NOTRUN -> [DMESG-WARN][6] ([i915#402]) +2 similar 
issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19830/fi-tgl-y/igt@debugfs_test@read_all_entries.html

  * igt@gem_exec_suspend@basic-s0:
- fi-kbl-soraka:  [PASS][7] -> [INCOMPLETE][8] ([i915#155])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19830/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_huc_copy@huc-copy:
- fi-glk-dsi: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#2190])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19830/fi-glk-dsi/igt@gem_huc_c...@huc-copy.html
- fi-tgl-y:   NOTRUN -> [SKIP][10] ([i915#2190])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19830/fi-tgl-y/igt@gem_huc_c...@huc-copy.html
- fi-icl-y:   NOTRUN -> [SKIP][11] ([i915#2190])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19830/fi-icl-y/igt@gem_huc_c...@huc-copy.html

  * igt@gem_tiled_fence_blits@basic:
- fi-kbl-8809g:   [PASS][12] -> [TIMEOUT][13] ([i915#3145])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/fi-kbl-8809g/igt@gem_tiled_fence_bl...@basic.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19830/fi-kbl-8809g/igt@gem_tiled_fence_bl...@basic.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-glk-dsi: NOTRUN -> [DMESG-WARN][14] ([i915#3143]) +26 similar 
issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19830/fi-glk-dsi/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: NOTRUN -> [DMESG-WARN][15] ([i915#1982] / [i915#3143])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19830/fi-glk-dsi/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-kefka:   [PASS][16] -> [INCOMPLETE][17] ([i915#2782] / 
[i915#2940])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19830/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-icl-y:   NOTRUN -> [DMESG-FAIL][18] ([i915#2291] / [i915#541])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19830/fi-icl-y/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@gt_lrc:
- fi-tgl-y:   NOTRUN -> [DMESG-FAIL][19] ([i915#2373])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19830/fi-tgl-y/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@gt_pm:
- fi-tgl-y:   NOTRUN -> [DMESG-FAIL][20] ([i915#1759])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19830/fi-tgl-y/igt@i915_selftest@live@gt_pm.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-icl-y:   NOTRUN -> [SK

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Implement SINGLE_TIMELINE with a syncobj

[Jason Ekstrand]

On Mon, Mar 22, 2021 at 11:59 AM Daniel Vetter  wrote:
>
> On Fri, Mar 19, 2021 at 05:38:56PM -0500, Jason Ekstrand wrote:
> > I'd love to delete the SINGLE_TIMELINE API because it leaks an
> > implementation detail of contexts through to the API and is something
> > that userspace can do itself, trivially.  Unfortunately, it's used by
> > the media driver so we can't do that.  We can, however, do the next-best
> > thing which is to embed a syncobj in the context and do exactly what
> > we'd expect from userspace internally.
> >
> > This has a couple of advantages.  One is that we're no longer leaking a
> > detail of the current execlist scheduler which will be problematic when
> > we try to add GuC scheduling.  Second is that, together with deleting
> > the CLONE_CONTEXT API, we should now have a 1:1 mapping between
> > intel_context and intel_timeline which should make some of our locking
> > mess a bit easier.
> >
> > Signed-off-by: Jason Ekstrand 
> > Cc: Maarten Lankhorst 
> > Cc: Matthew Brost 
> > ---
> >  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 47 ---
> >  .../gpu/drm/i915/gem/i915_gem_context_types.h |  8 +++-
> >  .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 15 ++
> >  3 files changed, 32 insertions(+), 38 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index f88bac19333ec..e094f4a1ca4cd 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -67,6 +67,8 @@
> >  #include 
> >  #include 
> >
> > +#include 
> > +
> >  #include "gt/gen6_ppgtt.h"
> >  #include "gt/intel_context.h"
> >  #include "gt/intel_engine_heartbeat.h"
> > @@ -224,10 +226,6 @@ static void intel_context_set_gem(struct intel_context 
> > *ce,
> >   ce->vm = vm;
> >   }
> >
> > - GEM_BUG_ON(ce->timeline);
> > - if (ctx->timeline)
> > - ce->timeline = intel_timeline_get(ctx->timeline);
> > -
> >   if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
> >   intel_engine_has_timeslices(ce->engine))
> >   __set_bit(CONTEXT_USE_SEMAPHORES, &ce->flags);
> > @@ -344,8 +342,8 @@ void i915_gem_context_release(struct kref *ref)
> >   mutex_destroy(&ctx->engines_mutex);
> >   mutex_destroy(&ctx->lut_mutex);
> >
> > - if (ctx->timeline)
> > - intel_timeline_put(ctx->timeline);
> > + if (ctx->syncobj)
> > + drm_syncobj_put(ctx->syncobj);
> >
> >   put_pid(ctx->pid);
> >   mutex_destroy(&ctx->mutex);
> > @@ -790,33 +788,11 @@ static void __assign_ppgtt(struct i915_gem_context 
> > *ctx,
> >   i915_vm_close(vm);
> >  }
> >
> > -static void __set_timeline(struct intel_timeline **dst,
> > -struct intel_timeline *src)
> > -{
> > - struct intel_timeline *old = *dst;
> > -
> > - *dst = src ? intel_timeline_get(src) : NULL;
> > -
> > - if (old)
> > - intel_timeline_put(old);
> > -}
> > -
> > -static void __apply_timeline(struct intel_context *ce, void *timeline)
> > -{
> > - __set_timeline(&ce->timeline, timeline);
> > -}
> > -
> > -static void __assign_timeline(struct i915_gem_context *ctx,
> > -   struct intel_timeline *timeline)
> > -{
> > - __set_timeline(&ctx->timeline, timeline);
> > - context_apply_all(ctx, __apply_timeline, timeline);
> > -}
> > -
> >  static struct i915_gem_context *
> >  i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
> >  {
> >   struct i915_gem_context *ctx;
> > + int ret;
> >
> >   if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&
> >   !HAS_EXECLISTS(i915))
> > @@ -845,16 +821,13 @@ i915_gem_create_context(struct drm_i915_private 
> > *i915, unsigned int flags)
> >   }
> >
> >   if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
> > - struct intel_timeline *timeline;
> > -
> > - timeline = intel_timeline_create(&i915->gt);
> > - if (IS_ERR(timeline)) {
> > + ret = drm_syncobj_create(&ctx->syncobj,
> > +  DRM_SYNCOBJ_CREATE_SIGNALED,
> > +  NULL);
> > + if (ret) {
> >   context_close(ctx);
> > - return ERR_CAST(timeline);
> > + return ERR_PTR(ret);
> >   }
> > -
> > - __assign_timeline(ctx, timeline);
> > - intel_timeline_put(timeline);
> >   }
> >
> >   trace_i915_context_create(ctx);
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h 
> > b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > index 676592e27e7d2..8a5fdd163b79d 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > @@ -83,7 +83,13 @@ struct i915_gem_context {
> >   struct i915_gem_engin

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for treewide: address gcc-11 -Wstringop-overread warnings

[Patchwork]

== Series Details ==

Series: treewide: address gcc-11 -Wstringop-overread warnings
URL   : https://patchwork.freedesktop.org/series/88295/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_reset.c:1323:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gvt/mmio.c:295:23: warning: memcpy with byte count of 
279040
+drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 
16777216
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - 
different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' 
- different lock contexts for basic block


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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for treewide: address gcc-11 -Wstringop-overread warnings

[Patchwork]

== Series Details ==

Series: treewide: address gcc-11 -Wstringop-overread warnings
URL   : https://patchwork.freedesktop.org/series/88295/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
8b23b18b19c9 x86: compressed: avoid gcc-11 -Wstringop-overread warning
-:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#15: 
inlined from ‘extract_kernel’ at arch/x86/boot/compressed/misc.c:442:2:

total: 0 errors, 1 warnings, 0 checks, 8 lines checked
6128f7213e8c x86: tboot: avoid Wstringop-overread-warning
-:13: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#13: 
   70 | if (memcmp(&tboot_uuid, &tboot->uuid, sizeof(tboot->uuid))) {

total: 0 errors, 1 warnings, 0 checks, 57 lines checked
86478fbc483a security: commoncap: fix -Wstringop-overread warning
-:13: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#13: 
  440 | memcpy(&nscap->data, &cap->data, 
sizeof(__le32) * 2 * VFS_CAP_U32);

total: 0 errors, 1 warnings, 0 checks, 8 lines checked
5dbb709eb530 ath11: Wstringop-overread warning
-:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#10: 
inlined from 'ath11k_peer_assoc_prepare' at 
drivers/net/wireless/ath/ath11k/mac.c:1632:2:

total: 0 errors, 1 warnings, 0 checks, 8 lines checked
85a87603017e qnx: avoid -Wstringop-overread warning
c20cb7a6e190 cgroup: fix -Wzero-length-bounds warnings
-:22: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#22: 
  422 | struct cgroup_subsys_state __rcu *subsys[CGROUP_SUBSYS_COUNT];

-:40: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 
'CGROUP_SUBSYS_COUNT > 0'
#40: FILE: kernel/cgroup/cgroup.c:459:
+   if (ss && (CGROUP_SUBSYS_COUNT > 0))

total: 0 errors, 1 warnings, 1 checks, 51 lines checked
a23dcecdfe93 ARM: sharpsl_param: work around -Wstringop-overread warning
-:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#15: 
   43 | memcpy(&sharpsl_param, param_start(PARAM_BASE), sizeof(struct 
sharpsl_param_info));

total: 0 errors, 1 warnings, 0 checks, 10 lines checked
ce0bcacc57ff atmel: avoid gcc -Wstringop-overflow warning
-:12: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#12: 
cc1: error: writing 4 bytes into a region of size between 18446744073709551613 
and 2 [-Werror=stringop-overflow=]

-:44: WARNING:NETWORKING_BLOCK_COMMENT_STYLE: networking block comments don't 
use an empty /* line, use /* Comment...
#44: FILE: drivers/net/wireless/atmel/atmel.c:2885:
+   /*
+* nothing after here directly accessible:

total: 0 errors, 2 warnings, 0 checks, 41 lines checked
f449f33af4a3 scsi: lpfc: fix gcc -Wstringop-overread warning
-:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#11: 
  518 | strnlen(LPFC_NVME_INFO_MORE_STR, PAGE_SIZE - 1)

-:33: WARNING:STRLCPY: Prefer strscpy over strlcpy - see: 
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
#33: FILE: drivers/scsi/lpfc/lpfc_attr.c:515:
+   strlcpy(buf + PAGE_SIZE - 1 - sizeof(LPFC_NVME_INFO_MORE_STR),

total: 0 errors, 2 warnings, 0 checks, 13 lines checked
e77df84376b1 drm/i915: avoid stringop-overread warning on pri_latency
-:12: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#12: 
inlined from ‘ilk_setup_wm_latency’ at 
drivers/gpu/drm/i915/intel_pm.c:3108:3:

total: 0 errors, 1 warnings, 0 checks, 14 lines checked
e9066fbd700e drm/i915/dp: fix array overflow warning
-:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#15: 
 4556 | !drm_dp_channel_eq_ok(&esi[10], 
intel_dp->lane_count)) {

total: 0 errors, 1 warnings, 0 checks, 8 lines checked


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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Warn when display irq functions are called without display

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915: Warn when display irq functions 
are called without display
URL   : https://patchwork.freedesktop.org/series/88294/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9880 -> Patchwork_19829


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/index.html

Possible new issues
---

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

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_exec_fence@nb-await@vcs0:
- {fi-rkl-11500t}:NOTRUN -> [FAIL][1] +38 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/fi-rkl-11500t/igt@gem_exec_fence@nb-aw...@vcs0.html

  * igt@i915_selftest@live@evict:
- {fi-ehl-1}: [PASS][2] -> [DMESG-WARN][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/fi-ehl-1/igt@i915_selftest@l...@evict.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/fi-ehl-1/igt@i915_selftest@l...@evict.html

  * igt@prime_vgem@basic-read:
- {fi-rkl-11500t}:NOTRUN -> [SKIP][4] +3 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/fi-rkl-11500t/igt@prime_v...@basic-read.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-y:   NOTRUN -> [SKIP][5] ([fdo#109315])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/fi-tgl-y/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-tgl-y:   NOTRUN -> [SKIP][6] ([fdo#109315] / [i915#2575]) +16 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/fi-tgl-y/igt@amdgpu/amd_cs_...@fork-gfx0.html

  * igt@gem_huc_copy@huc-copy:
- fi-glk-dsi: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/fi-glk-dsi/igt@gem_huc_c...@huc-copy.html
- fi-tgl-y:   NOTRUN -> [SKIP][8] ([i915#2190])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/fi-tgl-y/igt@gem_huc_c...@huc-copy.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-glk-dsi: NOTRUN -> [DMESG-WARN][9] ([i915#3143]) +26 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/fi-glk-dsi/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: NOTRUN -> [DMESG-WARN][10] ([i915#1982] / [i915#3143])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/fi-glk-dsi/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@gt_lrc:
- fi-tgl-y:   NOTRUN -> [DMESG-FAIL][11] ([i915#2373])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/fi-tgl-y/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@gt_pm:
- fi-tgl-y:   NOTRUN -> [DMESG-FAIL][12] ([i915#1759])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/fi-tgl-y/igt@i915_selftest@live@gt_pm.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-glk-dsi: NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/fi-glk-dsi/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_chamelium@vga-edid-read:
- fi-tgl-y:   NOTRUN -> [SKIP][14] ([fdo#111827]) +8 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/fi-tgl-y/igt@kms_chamel...@vga-edid-read.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-y:   NOTRUN -> [SKIP][15] ([fdo#109285])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/fi-tgl-y/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-glk-dsi: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#533])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/fi-glk-dsi/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_psr@primary_page_flip:
- fi-glk-dsi: NOTRUN -> [SKIP][17] ([fdo#109271]) +27 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/fi-glk-dsi/igt@kms_psr@primary_page_flip.html

  * igt@prime_vgem@basic-read:
- fi-tgl-y:   NOTRUN -> [DMESG-WARN][18] ([i915#402]) +1 similar 
issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19829/fi-tgl-y/igt@prime_v...@basic-read.html

  
 Possible fixes 

  * igt@gem_linear_blits@basic:
- fi-kbl-8809g:   [TIMEOUT][19] ([i915#2502] / [i915#3145]) -> 
[PASS][20] +1 similar issue
   [19]: 
https:

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Warn when display irq functions are called without display

[Ville Syrjälä]

On Mon, Mar 22, 2021 at 11:10:53AM -0700, José Roberto de Souza wrote:
> With previous changes none of those warnings will be printed but let's
> add them so CI can caught regressions.
> 
> Cc: Lucas De Marchi 
> Signed-off-by: José Roberto de Souza 
> Signed-off-by: Jani Nikula 
> ---
>  .../gpu/drm/i915/display/intel_fifo_underrun.c  |  2 ++
>  drivers/gpu/drm/i915/display/intel_hotplug.c|  2 ++
>  drivers/gpu/drm/i915/i915_irq.c | 17 +
>  3 files changed, 21 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_fifo_underrun.c 
> b/drivers/gpu/drm/i915/display/intel_fifo_underrun.c
> index 813a4f7033e1..f3631e319e5d 100644
> --- a/drivers/gpu/drm/i915/display/intel_fifo_underrun.c
> +++ b/drivers/gpu/drm/i915/display/intel_fifo_underrun.c
> @@ -373,6 +373,8 @@ void intel_cpu_fifo_underrun_irq_handler(struct 
> drm_i915_private *dev_priv,
>  {
>   struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
>  
> + drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_DISPLAY(dev_priv));
> +

Sprinkling these everywhere isn't great. Would be better to stick them
into just the top level display irq handlers.

>   /* We may be called too early in init, thanks BIOS! */
>   if (crtc == NULL)
>   return;
> diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c 
> b/drivers/gpu/drm/i915/display/intel_hotplug.c
> index f46a1b7190b8..77ce4a54a137 100644
> --- a/drivers/gpu/drm/i915/display/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
> @@ -478,6 +478,8 @@ void intel_hpd_irq_handler(struct drm_i915_private 
> *dev_priv,
>   if (!pin_mask)
>   return;
>  
> + drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_DISPLAY(dev_priv));
> +
>   spin_lock(&dev_priv->irq_lock);
>  
>   /*
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 44aed4cbf894..cbb2aae4fc13 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -519,6 +519,8 @@ void i915_enable_pipestat(struct drm_i915_private 
> *dev_priv,
>   i915_reg_t reg = PIPESTAT(pipe);
>   u32 enable_mask;
>  
> + drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_DISPLAY(dev_priv));
> +

Not much point in adding these to any gmch code. It's never
going to trip.

>   drm_WARN_ONCE(&dev_priv->drm, status_mask & ~PIPESTAT_INT_STATUS_MASK,
> "pipe %c: status_mask=0x%x\n",
> pipe_name(pipe), status_mask);
> @@ -1273,6 +1275,7 @@ static u32 intel_hpd_hotplug_enables(struct 
> drm_i915_private *i915,
>  
>  static void gmbus_irq_handler(struct drm_i915_private *dev_priv)
>  {
> + drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_DISPLAY(dev_priv));
>   wake_up_all(&dev_priv->gmbus_wait_queue);
>  }
>  
> @@ -1366,6 +1369,8 @@ static void i9xx_pipe_crc_irq_handler(struct 
> drm_i915_private *dev_priv,
>  {
>   u32 res1, res2;
>  
> + drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_DISPLAY(dev_priv));
> +
>   if (INTEL_GEN(dev_priv) >= 3)
>   res1 = intel_uncore_read(&dev_priv->uncore, 
> PIPE_CRC_RES_RES1_I915(pipe));
>   else
> @@ -1558,6 +1563,8 @@ static u32 i9xx_hpd_irq_ack(struct drm_i915_private 
> *dev_priv)
>   u32 hotplug_status = 0, hotplug_status_mask;
>   int i;
>  
> + drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_DISPLAY(dev_priv));
> +
>   if (IS_G4X(dev_priv) ||
>   IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
>   hotplug_status_mask = HOTPLUG_INT_STATUS_G4X |
> @@ -1597,6 +1604,8 @@ static void i9xx_hpd_irq_handler(struct 
> drm_i915_private *dev_priv,
>   u32 pin_mask = 0, long_mask = 0;
>   u32 hotplug_trigger;
>  
> + drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_DISPLAY(dev_priv));
> +
>   if (IS_G4X(dev_priv) ||
>   IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
>   hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_G4X;
> @@ -2038,6 +2047,8 @@ static void ilk_display_irq_handler(struct 
> drm_i915_private *dev_priv,
>   enum pipe pipe;
>   u32 hotplug_trigger = de_iir & DE_DP_A_HOTPLUG;
>  
> + drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_DISPLAY(dev_priv));
> +
>   if (hotplug_trigger)
>   ilk_hpd_irq_handler(dev_priv, hotplug_trigger);
>  
> @@ -2087,6 +2098,8 @@ static void ivb_display_irq_handler(struct 
> drm_i915_private *dev_priv,
>   enum pipe pipe;
>   u32 hotplug_trigger = de_iir & DE_DP_A_HOTPLUG_IVB;
>  
> + drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_DISPLAY(dev_priv));
> +
>   if (hotplug_trigger)
>   ilk_hpd_irq_handler(dev_priv, hotplug_trigger);
>  
> @@ -2421,6 +2434,8 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
> u32 master_ctl)
>   u32 iir;
>   enum pipe pipe;
>  
> + drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_DISPLAY(dev_priv));
> +
>   if (master_ctl & GEN8_DE_MISC_IRQ) {
>   iir = intel_uncore_read(&dev_priv->uncore, GEN8_DE_MISC_IIR);
>  

Re: [Intel-gfx] [bug report] drm/i915: Computer does not shutdown,

[Ville Syrjälä]

On Mon, Mar 22, 2021 at 07:00:38PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 3/22/21 5:00 PM, Ville Syrjälä wrote:
> > On Mon, Mar 22, 2021 at 04:51:26PM +0100, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 3/22/21 3:53 PM, Ville Syrjälä wrote:
> >>> On Mon, Mar 22, 2021 at 11:45:39AM +0100, Hans de Goede wrote:
>  Hi,
> 
>  On 3/14/21 11:30 AM, Mario Hüttel wrote:
> > Hello,
> >
> > It seems, like the mailing list, didn't accept my email. So I'll send
> > it again:
> >
> > I want to report a bug. I have a PC with Intel i7-6700K processor (with
> > integrated graphics) and an AsRock Fatal1ty Z170 Gaming K6 mainboard. I
> > use the CPU's integrated graphics.
> > My system is Archlinux with Kernel v5.11.6.
> >
> > Using this setup, my PC works normally. However, when I shut it down,
> > the power is not cut. Fans keep spinning and LEDs stay on. I couldn't
> > detect any other problem when shutting down. Drives etc. stop as
> > expected and the video is blank. Even after waiting several hours, the
> > system doesn't power down.
> >
> > Restarts work normally.
> >
> > I haven't yet found any other people on the internet that have the same
> > bug.
> >
> > I used git bisect to find the commit that causes this behavior on my
> > machine.
> 
>  Thank you for doing a bisect that is always very helpful.
> 
> > The result is: fe0f1e3bfdfeb53e18f1206aea4f40b9bd1f291c is the
> > first bad commit.
> 
>  To save others the trouble of having to look up the hasj, that is:
> 
>  "drm/i915: Shut down displays gracefully on reboot"
> 
>  Which is the same commit as which I've reported is causing issues
>  with DSI panels not lighting up on reboots on some BYT/CHT devices.
> 
>  Since this seems to mostly be intended to fix issues surrounding
>  DP MST stuff, maybe the graceful shutdown should only be done when
>  MST is in use?
> >>>
> >>> No. It also fixes Windows, lols.
> >>
> >> Ok, can you at least take a look at my patch which fixes (works-around)
> >> the issues for DSI panel on BYT/CHT DSI devices:
> >>
> >> https://patchwork.freedesktop.org/patch/422481/
> >>
> >> ?
> > 
> > Never reached my inbox.
> 
> Yes I'm seeing a lot of bounces from the linux.intel.com mailserver lately
> (and only from that mail server and not from any other mailservers).
> 
> You should have also received a copy through the intel-gfx lists though.

Nope. Didn't come through the list either.

> 
> Or you can grab a raw copy from patchwork.
> 
> Regardless of the mail-issue a review would be much appreciated.
> 
> Regards,
> 
> Hans
> 
> 
> p.s.
> 
> While on the subjects of bouncing emails, did you see Jani's reply to:
> https://patchwork.freedesktop.org/patch/422669/
> 
> Where he asks for a second opinion on that patch from you ?

I did reply to that patch.

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

[Intel-gfx] [PATCH 10/11] drm/i915: avoid stringop-overread warning on pri_latency

[Arnd Bergmann]

From: Arnd Bergmann 

gcc-11 warns about what appears to be an out-of-range array access:

In function ‘snb_wm_latency_quirk’,
inlined from ‘ilk_setup_wm_latency’ at 
drivers/gpu/drm/i915/intel_pm.c:3108:3:
drivers/gpu/drm/i915/intel_pm.c:3057:9: error: ‘intel_print_wm_latency’ reading 
16 bytes from a region of size 10 [-Werror=stringop-overread]
 3057 | intel_print_wm_latency(dev_priv, "Primary", 
dev_priv->wm.pri_latency);
  | 
^
drivers/gpu/drm/i915/intel_pm.c: In function ‘ilk_setup_wm_latency’:
drivers/gpu/drm/i915/intel_pm.c:3057:9: note: referencing argument 3 of type 
‘const u16 *’ {aka ‘const short unsigned int *’}
drivers/gpu/drm/i915/intel_pm.c:2994:13: note: in a call to function 
‘intel_print_wm_latency’
 2994 | static void intel_print_wm_latency(struct drm_i915_private *dev_priv,
  | ^~

My guess is that this code is actually safe because the size of the
array depends on the hardware generation, and the function checks for
that, but at the same time I would not expect the compiler to work it
out correctly, and the code seems a little fragile with regards to
future changes. Simply increasing the size of the array should help.

Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/i915/i915_drv.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 26d69d06aa6d..3567602e0a35 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1095,11 +1095,11 @@ struct drm_i915_private {
 * in 0.5us units for WM1+.
 */
/* primary */
-   u16 pri_latency[5];
+   u16 pri_latency[8];
/* sprite */
-   u16 spr_latency[5];
+   u16 spr_latency[8];
/* cursor */
-   u16 cur_latency[5];
+   u16 cur_latency[8];
/*
 * Raw watermark memory latency values
 * for SKL for all 8 levels
-- 
2.29.2

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

[Intel-gfx] [PATCH 01/11] x86: compressed: avoid gcc-11 -Wstringop-overread warning

[Arnd Bergmann]

From: Arnd Bergmann 

gcc gets confused by the comparison of a pointer to an integer listeral,
with the assumption that this is an offset from a NULL pointer and that
dereferencing it is invalid:

In file included from arch/x86/boot/compressed/misc.c:18:
In function ‘parse_elf’,
inlined from ‘extract_kernel’ at arch/x86/boot/compressed/misc.c:442:2:
arch/x86/boot/compressed/../string.h:15:23: error: ‘__builtin_memcpy’ reading 
64 bytes from a region of size 0 [-Werror=stringop-overread]
   15 | #define memcpy(d,s,l) __builtin_memcpy(d,s,l)
  |   ^~~
arch/x86/boot/compressed/misc.c:283:9: note: in expansion of macro ‘memcpy’
  283 | memcpy(&ehdr, output, sizeof(ehdr));
  | ^~

I could not find any good workaround for this, but as this is only
a warning for a failure during early boot, removing the line entirely
works around the warning.

This should probably get addressed in gcc instead, before 11.1 gets
released.

Signed-off-by: Arnd Bergmann 
---
 arch/x86/boot/compressed/misc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 3a214cc3239f..9ada64e66cb7 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -430,8 +430,6 @@ asmlinkage __visible void *extract_kernel(void *rmode, 
memptr heap,
error("Destination address too large");
 #endif
 #ifndef CONFIG_RELOCATABLE
-   if ((unsigned long)output != LOAD_PHYSICAL_ADDR)
-   error("Destination address does not match LOAD_PHYSICAL_ADDR");
if (virt_addr != LOAD_PHYSICAL_ADDR)
error("Destination virtual address changed when not 
relocatable");
 #endif
-- 
2.29.2

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

[Intel-gfx] [PATCH 02/11] x86: tboot: avoid Wstringop-overread-warning

[Arnd Bergmann]

From: Arnd Bergmann 

gcc-11 warns about using string operations on pointers that are
defined at compile time as offsets from a NULL pointer. Unfortunately
that also happens on the result of fix_to_virt(), which is a
compile-time constant for a constantn input:

arch/x86/kernel/tboot.c: In function 'tboot_probe':
arch/x86/kernel/tboot.c:70:13: error: '__builtin_memcmp_eq' specified bound 16 
exceeds source size 0 [-Werror=stringop-overread]
   70 | if (memcmp(&tboot_uuid, &tboot->uuid, sizeof(tboot->uuid))) {
  | ^~

I hope this can get addressed in gcc-11 before the release.

As a workaround, split up the tboot_probe() function in two halves
to separate the pointer generation from the usage. This is a bit
ugly, and hopefully gcc understands that the code is actually correct
before it learns to peek into the noinline function.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
Signed-off-by: Arnd Bergmann 
---
 arch/x86/kernel/tboot.c | 44 -
 1 file changed, 26 insertions(+), 18 deletions(-)

diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c
index 4c09ba110204..f9af561c3cd4 100644
--- a/arch/x86/kernel/tboot.c
+++ b/arch/x86/kernel/tboot.c
@@ -49,6 +49,30 @@ bool tboot_enabled(void)
return tboot != NULL;
 }
 
+/* noinline to prevent gcc from warning about dereferencing constant fixaddr */
+static noinline __init bool check_tboot_version(void)
+{
+   if (memcmp(&tboot_uuid, &tboot->uuid, sizeof(tboot->uuid))) {
+   pr_warn("tboot at 0x%llx is invalid\n", boot_params.tboot_addr);
+   return false;
+   }
+
+   if (tboot->version < 5) {
+   pr_warn("tboot version is invalid: %u\n", tboot->version);
+   return false;
+   }
+
+   pr_info("found shared page at phys addr 0x%llx:\n",
+   boot_params.tboot_addr);
+   pr_debug("version: %d\n", tboot->version);
+   pr_debug("log_addr: 0x%08x\n", tboot->log_addr);
+   pr_debug("shutdown_entry: 0x%x\n", tboot->shutdown_entry);
+   pr_debug("tboot_base: 0x%08x\n", tboot->tboot_base);
+   pr_debug("tboot_size: 0x%x\n", tboot->tboot_size);
+
+   return true;
+}
+
 void __init tboot_probe(void)
 {
/* Look for valid page-aligned address for shared page. */
@@ -66,25 +90,9 @@ void __init tboot_probe(void)
 
/* Map and check for tboot UUID. */
set_fixmap(FIX_TBOOT_BASE, boot_params.tboot_addr);
-   tboot = (struct tboot *)fix_to_virt(FIX_TBOOT_BASE);
-   if (memcmp(&tboot_uuid, &tboot->uuid, sizeof(tboot->uuid))) {
-   pr_warn("tboot at 0x%llx is invalid\n", boot_params.tboot_addr);
+   tboot = (void *)fix_to_virt(FIX_TBOOT_BASE);
+   if (!check_tboot_version())
tboot = NULL;
-   return;
-   }
-   if (tboot->version < 5) {
-   pr_warn("tboot version is invalid: %u\n", tboot->version);
-   tboot = NULL;
-   return;
-   }
-
-   pr_info("found shared page at phys addr 0x%llx:\n",
-   boot_params.tboot_addr);
-   pr_debug("version: %d\n", tboot->version);
-   pr_debug("log_addr: 0x%08x\n", tboot->log_addr);
-   pr_debug("shutdown_entry: 0x%x\n", tboot->shutdown_entry);
-   pr_debug("tboot_base: 0x%08x\n", tboot->tboot_base);
-   pr_debug("tboot_size: 0x%x\n", tboot->tboot_size);
 }
 
 static pgd_t *tboot_pg_dir;
-- 
2.29.2

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

[Intel-gfx] [PATCH 08/11] atmel: avoid gcc -Wstringop-overflow warning

[Arnd Bergmann]

From: Arnd Bergmann 

gcc-11 notices that the fields as defined in the ass_req_format
structure do not match the actual use of that structure:

cc1: error: writing 4 bytes into a region of size between 18446744073709551613 
and 2 [-Werror=stringop-overflow=]
drivers/net/wireless/atmel/atmel.c:2884:20: note: at offset [4, 6] into 
destination object ‘ap’ of size 6
 2884 | u8 ap[ETH_ALEN]; /* nothing after here directly 
accessible */
  |^~
drivers/net/wireless/atmel/atmel.c:2885:20: note: at offset [4, 6] into 
destination object ‘ssid_el_id’ of size 1
 2885 | u8 ssid_el_id;
  |^~

This is expected here because the actual structure layout is variable.
As the code does not actually access the individual fields, replace
them with a comment and fixed-length array so prevent gcc from
complaining about it.

Signed-off-by: Arnd Bergmann 
---
 drivers/net/wireless/atmel/atmel.c | 25 +++--
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/atmel/atmel.c 
b/drivers/net/wireless/atmel/atmel.c
index 707fe66727f8..ff9152d600e1 100644
--- a/drivers/net/wireless/atmel/atmel.c
+++ b/drivers/net/wireless/atmel/atmel.c
@@ -2881,13 +2881,18 @@ static void send_association_request(struct 
atmel_private *priv, int is_reassoc)
struct ass_req_format {
__le16 capability;
__le16 listen_interval;
-   u8 ap[ETH_ALEN]; /* nothing after here directly accessible */
-   u8 ssid_el_id;
-   u8 ssid_len;
-   u8 ssid[MAX_SSID_LENGTH];
-   u8 sup_rates_el_id;
-   u8 sup_rates_len;
-   u8 rates[4];
+   u8 ssid_el[ETH_ALEN + 2 + MAX_SSID_LENGTH + 2 + 4];
+   /*
+* nothing after here directly accessible:
+*
+* u8 ap[ETH_ALEN];
+* u8 ssid_el_id;
+* u8 ssid_len;
+* u8 ssid[MAX_SSID_LENGTH];
+* u8 sup_rates_el_id;
+* u8 sup_rates_len;
+* u8 rates[4];
+*/
} body;
 
header.frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT |
@@ -2907,13 +2912,13 @@ static void send_association_request(struct 
atmel_private *priv, int is_reassoc)
 
body.listen_interval = cpu_to_le16(priv->listen_interval * 
priv->beacon_period);
 
+   ssid_el_p = body.ssid_el;
/* current AP address - only in reassoc frame */
if (is_reassoc) {
-   memcpy(body.ap, priv->CurrentBSSID, ETH_ALEN);
-   ssid_el_p = &body.ssid_el_id;
+   memcpy(ssid_el_p, priv->CurrentBSSID, ETH_ALEN);
+   ssid_el_p += ETH_ALEN;
bodysize = 18 + priv->SSID_size;
} else {
-   ssid_el_p = &body.ap[0];
bodysize = 12 + priv->SSID_size;
}
 
-- 
2.29.2

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

[Intel-gfx] [PATCH 11/11] [RFC] drm/i915/dp: fix array overflow warning

[Arnd Bergmann]

From: Arnd Bergmann 

gcc-11 warns that intel_dp_check_mst_status() has a local array of
fourteen bytes and passes the last four bytes into a function that
expects a six-byte array:

drivers/gpu/drm/i915/display/intel_dp.c: In function 
‘intel_dp_check_mst_status’:
drivers/gpu/drm/i915/display/intel_dp.c:4556:22: error: ‘drm_dp_channel_eq_ok’ 
reading 6 bytes from a region of size 4 [-Werror=stringop-overread]
 4556 | !drm_dp_channel_eq_ok(&esi[10], 
intel_dp->lane_count)) {
  |  
^~~~
drivers/gpu/drm/i915/display/intel_dp.c:4556:22: note: referencing argument 1 
of type ‘const u8 *’ {aka ‘const unsigned char *’}
In file included from drivers/gpu/drm/i915/display/intel_dp.c:38:
include/drm/drm_dp_helper.h:1459:6: note: in a call to function 
‘drm_dp_channel_eq_ok’
 1459 | bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
  |  ^~~~

Clearly something is wrong here, but I can't quite figure out what.
Changing the array size to 16 bytes avoids the warning, but is
probably the wrong solution here.

Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 8c12d5375607..830e2515f119 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -65,7 +65,7 @@
 #include "intel_vdsc.h"
 #include "intel_vrr.h"
 
-#define DP_DPRX_ESI_LEN 14
+#define DP_DPRX_ESI_LEN 16
 
 /* DP DSC throughput values used for slice count calculations KPixels/s */
 #define DP_DSC_PEAK_PIXEL_RATE 272
-- 
2.29.2

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

[Intel-gfx] [PATCH 07/11] ARM: sharpsl_param: work around -Wstringop-overread warning

[Arnd Bergmann]

From: Arnd Bergmann 

gcc warns that accessing a pointer based on a numeric constant may
be an offset into a NULL pointer, and would therefore has zero
accessible bytes:

arch/arm/common/sharpsl_param.c: In function ‘sharpsl_save_param’:
arch/arm/common/sharpsl_param.c:43:9: error: ‘memcpy’ reading 64 bytes from a 
region of size 0 [-Werror=stringop-overread]
   43 | memcpy(&sharpsl_param, param_start(PARAM_BASE), sizeof(struct 
sharpsl_param_info));
  | 
^~

In this particular case, the warning is bogus since this is the actual
pointer, not an offset on a NULL pointer. Add a local variable to shut
up the warning and hope it doesn't come back.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
Signed-off-by: Arnd Bergmann 
---
 arch/arm/common/sharpsl_param.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/common/sharpsl_param.c b/arch/arm/common/sharpsl_param.c
index efeb5724d9e9..6237ede2f0c7 100644
--- a/arch/arm/common/sharpsl_param.c
+++ b/arch/arm/common/sharpsl_param.c
@@ -40,7 +40,9 @@ EXPORT_SYMBOL(sharpsl_param);
 
 void sharpsl_save_param(void)
 {
-   memcpy(&sharpsl_param, param_start(PARAM_BASE), sizeof(struct 
sharpsl_param_info));
+   struct sharpsl_param_info *params = param_start(PARAM_BASE);
+
+   memcpy(&sharpsl_param, params, sizeof(*params));
 
if (sharpsl_param.comadj_keyword != COMADJ_MAGIC)
sharpsl_param.comadj=-1;
-- 
2.29.2

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

[Intel-gfx] [PATCH 03/11] security: commoncap: fix -Wstringop-overread warning

[Arnd Bergmann]

From: Arnd Bergmann 

gcc-11 introdces a harmless warning for cap_inode_getsecurity:

security/commoncap.c: In function ‘cap_inode_getsecurity’:
security/commoncap.c:440:33: error: ‘memcpy’ reading 16 bytes from a region of 
size 0 [-Werror=stringop-overread]
  440 | memcpy(&nscap->data, &cap->data, 
sizeof(__le32) * 2 * VFS_CAP_U32);
  | 
^~

The problem here is that tmpbuf is initialized to NULL, so gcc assumes
it is not accessible unless it gets set by vfs_getxattr_alloc().  This is
a legitimate warning as far as I can tell, but the code is correct since
it correctly handles the error when that function fails.

Add a separate NULL check to tell gcc about it as well.

Signed-off-by: Arnd Bergmann 
---
 security/commoncap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/commoncap.c b/security/commoncap.c
index 28f4d25480df..9a36ed6dd737 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -400,7 +400,7 @@ int cap_inode_getsecurity(struct user_namespace *mnt_userns,
  &tmpbuf, size, GFP_NOFS);
dput(dentry);
 
-   if (ret < 0)
+   if (ret < 0 || !tmpbuf)
return ret;
 
fs_ns = inode->i_sb->s_user_ns;
-- 
2.29.2

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

[Intel-gfx] [PATCH 09/11] scsi: lpfc: fix gcc -Wstringop-overread warning

[Arnd Bergmann]

From: Arnd Bergmann 

gcc-11 warns about an strnlen with a length larger than the size of the
passed buffer:

drivers/scsi/lpfc/lpfc_attr.c: In function 'lpfc_nvme_info_show':
drivers/scsi/lpfc/lpfc_attr.c:518:25: error: 'strnlen' specified bound 4095 
exceeds source size 24 [-Werror=stringop-overread]
  518 | strnlen(LPFC_NVME_INFO_MORE_STR, PAGE_SIZE - 1)
  | ^~~

In this case, the code is entirely valid, as the string is properly
terminated, and the size argument is only there out of extra caution
in case it exceeds a page.

This cannot really happen here, so just simplify it to a sizeof().

Fixes: afff0d2321ea ("scsi: lpfc: Add Buffer overflow check, when nvme_info 
larger than PAGE_SIZE")
Signed-off-by: Arnd Bergmann 
---
 drivers/scsi/lpfc/lpfc_attr.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
index bdd9a29f4201..f6d886f9dfb3 100644
--- a/drivers/scsi/lpfc/lpfc_attr.c
+++ b/drivers/scsi/lpfc/lpfc_attr.c
@@ -512,11 +512,9 @@ lpfc_nvme_info_show(struct device *dev, struct 
device_attribute *attr,
"6314 Catching potential buffer "
"overflow > PAGE_SIZE = %lu bytes\n",
PAGE_SIZE);
-   strlcpy(buf + PAGE_SIZE - 1 -
-   strnlen(LPFC_NVME_INFO_MORE_STR, PAGE_SIZE - 1),
+   strlcpy(buf + PAGE_SIZE - 1 - sizeof(LPFC_NVME_INFO_MORE_STR),
LPFC_NVME_INFO_MORE_STR,
-   strnlen(LPFC_NVME_INFO_MORE_STR, PAGE_SIZE - 1)
-   + 1);
+   sizeof(LPFC_NVME_INFO_MORE_STR) + 1);
}
 
return len;
-- 
2.29.2

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

Re: [Intel-gfx] [PATCH 03/11] security: commoncap: fix -Wstringop-overread warning

[Christian Brauner]

On Mon, Mar 22, 2021 at 05:02:41PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> gcc-11 introdces a harmless warning for cap_inode_getsecurity:
> 
> security/commoncap.c: In function ‘cap_inode_getsecurity’:
> security/commoncap.c:440:33: error: ‘memcpy’ reading 16 bytes from a region 
> of size 0 [-Werror=stringop-overread]
>   440 | memcpy(&nscap->data, &cap->data, 
> sizeof(__le32) * 2 * VFS_CAP_U32);
>   | 
> ^~
> 
> The problem here is that tmpbuf is initialized to NULL, so gcc assumes
> it is not accessible unless it gets set by vfs_getxattr_alloc().  This is
> a legitimate warning as far as I can tell, but the code is correct since
> it correctly handles the error when that function fails.
> 
> Add a separate NULL check to tell gcc about it as well.
> 
> Signed-off-by: Arnd Bergmann 
> ---

Seems reasonable,
Acked-by: Christian Brauner 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 04/11] ath11: Wstringop-overread warning

[Arnd Bergmann]

From: Arnd Bergmann 

gcc-11 with the kernel address sanitizer prints a warning for this
driver:

In function 'ath11k_peer_assoc_h_vht',
inlined from 'ath11k_peer_assoc_prepare' at 
drivers/net/wireless/ath/ath11k/mac.c:1632:2:
drivers/net/wireless/ath/ath11k/mac.c:1164:13: error: 
'ath11k_peer_assoc_h_vht_masked' reading 16 bytes from a region of size 4 
[-Werror=stringop-overread]
 1164 | if (ath11k_peer_assoc_h_vht_masked(vht_mcs_mask))
  | ^~~~
drivers/net/wireless/ath/ath11k/mac.c: In function 'ath11k_peer_assoc_prepare':
drivers/net/wireless/ath/ath11k/mac.c:1164:13: note: referencing argument 1 of 
type 'const u16 *' {aka 'const short unsigned int *'}
drivers/net/wireless/ath/ath11k/mac.c:969:1: note: in a call to function 
'ath11k_peer_assoc_h_vht_masked'
  969 | ath11k_peer_assoc_h_vht_masked(const u16 
vht_mcs_mask[NL80211_VHT_NSS_MAX])
  | ^~

According to analysis from gcc developers, this is a glitch in the
way gcc tracks the size of struct members. This should really get
fixed in gcc, but it's also easy to work around this instance
by changing the function prototype to no include the length of
the array.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99673
Signed-off-by: Arnd Bergmann 
---
 drivers/net/wireless/ath/ath11k/mac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath11k/mac.c 
b/drivers/net/wireless/ath/ath11k/mac.c
index b391169576e2..5cb7ed53f3c4 100644
--- a/drivers/net/wireless/ath/ath11k/mac.c
+++ b/drivers/net/wireless/ath/ath11k/mac.c
@@ -966,7 +966,7 @@ ath11k_peer_assoc_h_ht_masked(const u8 
ht_mcs_mask[IEEE80211_HT_MCS_MASK_LEN])
 }
 
 static bool
-ath11k_peer_assoc_h_vht_masked(const u16 vht_mcs_mask[NL80211_VHT_NSS_MAX])
+ath11k_peer_assoc_h_vht_masked(const u16 vht_mcs_mask[])
 {
int nss;
 
-- 
2.29.2

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

[Intel-gfx] [PATCH 05/11] qnx: avoid -Wstringop-overread warning

[Arnd Bergmann]

From: Arnd Bergmann 

gcc-11 warns that the size of the link name is longer than the di_fname
field:

fs/qnx4/dir.c: In function ‘qnx4_readdir’:
fs/qnx4/dir.c:51:32: error: ‘strnlen’ specified bound 48 exceeds source size 16 
[-Werror=stringop-overread]
   51 | size = strnlen(de->di_fname, size);
  |^~~
In file included from fs/qnx4/qnx4.h:3,
 from fs/qnx4/dir.c:16:
include/uapi/linux/qnx4_fs.h:45:25: note: source object declared here
   45 | chardi_fname[QNX4_SHORT_NAME_MAX];

The problem here is that we access the same pointer using two different
structure layouts, but gcc determines the object size based on
whatever it encounters first.

Change the strnlen to use the correct field size in each case, and
change the first access to be on the longer field.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
Signed-off-by: Arnd Bergmann 
---
 fs/qnx4/dir.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/fs/qnx4/dir.c b/fs/qnx4/dir.c
index a6ee23aadd28..68046450e543 100644
--- a/fs/qnx4/dir.c
+++ b/fs/qnx4/dir.c
@@ -39,21 +39,20 @@ static int qnx4_readdir(struct file *file, struct 
dir_context *ctx)
ix = (ctx->pos >> QNX4_DIR_ENTRY_SIZE_BITS) % 
QNX4_INODES_PER_BLOCK;
for (; ix < QNX4_INODES_PER_BLOCK; ix++, ctx->pos += 
QNX4_DIR_ENTRY_SIZE) {
offset = ix * QNX4_DIR_ENTRY_SIZE;
-   de = (struct qnx4_inode_entry *) (bh->b_data + offset);
-   if (!de->di_fname[0])
+   le = (struct qnx4_link_info *)(bh->b_data + offset);
+   de = (struct qnx4_inode_entry *)(bh->b_data + offset);
+   if (!le->dl_fname[0])
continue;
if (!(de->di_status & (QNX4_FILE_USED|QNX4_FILE_LINK)))
continue;
if (!(de->di_status & QNX4_FILE_LINK))
-   size = QNX4_SHORT_NAME_MAX;
+   size = strnlen(de->di_fname, 
sizeof(de->di_fname));
else
-   size = QNX4_NAME_MAX;
-   size = strnlen(de->di_fname, size);
+   size = strnlen(le->dl_fname, 
sizeof(le->dl_fname));
QNX4DEBUG((KERN_INFO "qnx4_readdir:%.*s\n", size, 
de->di_fname));
if (!(de->di_status & QNX4_FILE_LINK))
ino = blknum * QNX4_INODES_PER_BLOCK + ix - 1;
else {
-   le  = (struct qnx4_link_info*)de;
ino = ( le32_to_cpu(le->dl_inode_blk) - 1 ) *
QNX4_INODES_PER_BLOCK +
le->dl_inode_ndx;
-- 
2.29.2

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

[Intel-gfx] [PATCH 06/11] cgroup: fix -Wzero-length-bounds warnings

[Arnd Bergmann]

From: Arnd Bergmann 

When cgroups are enabled, but every single subsystem is turned off,
CGROUP_SUBSYS_COUNT is zero, and the cgrp->subsys[] array has no
members.

gcc-11 points out that this leads to an invalid access in any function
that might access this array:

kernel/cgroup/cgroup.c: In function 'cgroup_addrm_files':
kernel/cgroup/cgroup.c:460:58: warning: array subscript '' is outside 
the bounds of an interior zero-length array 'struct cgroup_subsys_state *[0]' 
[-Wzero-length-bounds]
kernel/cgroup/cgroup.c:460:24: note: in expansion of macro 
'rcu_dereference_check'
  460 | return rcu_dereference_check(cgrp->subsys[ss->id],
  |^
In file included from include/linux/cgroup.h:28,
 from kernel/cgroup/cgroup-internal.h:5,
 from kernel/cgroup/cgroup.c:31:
include/linux/cgroup-defs.h:422:43: note: while referencing 'subsys'
  422 | struct cgroup_subsys_state __rcu *subsys[CGROUP_SUBSYS_COUNT];

I'm not sure what is expected to happen for such a configuration,
presumably these functions are never calls in that case. Adding a
sanity check in each function we get the warning for manages to shut
up the warnings and do nothing instead.

Signed-off-by: Arnd Bergmann 
---
I'm grouping this together with the -Wstringop-overread warnings,
since the underlying logic in gcc seems to be the same.
---
 kernel/cgroup/cgroup.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 9153b20e5cc6..3477f1dc7872 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -456,7 +456,7 @@ static u16 cgroup_ss_mask(struct cgroup *cgrp)
 static struct cgroup_subsys_state *cgroup_css(struct cgroup *cgrp,
  struct cgroup_subsys *ss)
 {
-   if (ss)
+   if (ss && (CGROUP_SUBSYS_COUNT > 0))
return rcu_dereference_check(cgrp->subsys[ss->id],
lockdep_is_held(&cgroup_mutex));
else
@@ -534,6 +534,9 @@ struct cgroup_subsys_state *cgroup_e_css(struct cgroup 
*cgrp,
 {
struct cgroup_subsys_state *css;
 
+   if (CGROUP_SUBSYS_COUNT == 0)
+   return NULL;
+
do {
css = cgroup_css(cgrp, ss);
 
@@ -561,6 +564,9 @@ struct cgroup_subsys_state *cgroup_get_e_css(struct cgroup 
*cgrp,
 {
struct cgroup_subsys_state *css;
 
+   if (CGROUP_SUBSYS_COUNT == 0)
+   return NULL;
+
rcu_read_lock();
 
do {
@@ -630,7 +636,7 @@ struct cgroup_subsys_state *of_css(struct kernfs_open_file 
*of)
 * the matching css from the cgroup's subsys table is guaranteed to
 * be and stay valid until the enclosing operation is complete.
 */
-   if (cft->ss)
+   if (cft->ss && CGROUP_SUBSYS_COUNT > 0)
return rcu_dereference_raw(cgrp->subsys[cft->ss->id]);
else
return &cgrp->self;
@@ -2343,6 +2349,9 @@ struct task_struct *cgroup_taskset_next(struct 
cgroup_taskset *tset,
struct css_set *cset = tset->cur_cset;
struct task_struct *task = tset->cur_task;
 
+   if (CGROUP_SUBSYS_COUNT == 0)
+   return NULL;
+
while (&cset->mg_node != tset->csets) {
if (!task)
task = list_first_entry(&cset->mg_tasks,
@@ -4523,7 +4532,7 @@ void css_task_iter_start(struct cgroup_subsys_state *css, 
unsigned int flags,
it->ss = css->ss;
it->flags = flags;
 
-   if (it->ss)
+   if (it->ss && CGROUP_SUBSYS_COUNT > 0)
it->cset_pos = &css->cgroup->e_csets[css->ss->id];
else
it->cset_pos = &css->cgroup->cset_links;
-- 
2.29.2

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

[Intel-gfx] [PATCH 00/11] treewide: address gcc-11 -Wstringop-overread warnings

[Arnd Bergmann]

From: Arnd Bergmann 

The coming gcc release introduces a new warning for string operations
reading beyond the end of a fixed-length object. After testing
randconfig kernels for a while, think I have patches for any such
warnings that came up on x86, arm and arm64.

Most of these warnings are false-positive ones, either gcc warning
about something that is entirely correct, or about something that
looks suspicious but turns out to be correct after all.

The two patches for the i915 driver look like something that might
be actual bugs, but I am not sure about those either.

We probably want some combination of workaround like the ones I
post here and changes to gcc to have fewer false positives in the
release. I'm posting the entire set of workaround that give me
a cleanly building kernel for reference here.

Arnd

Arnd Bergmann (11):
  x86: compressed: avoid gcc-11 -Wstringop-overread warning
  x86: tboot: avoid Wstringop-overread-warning
  security: commoncap: fix -Wstringop-overread warning
  ath11: Wstringop-overread warning
  qnx: avoid -Wstringop-overread warning
  cgroup: fix -Wzero-length-bounds warnings
  ARM: sharpsl_param: work around -Wstringop-overread warning
  atmel: avoid gcc -Wstringop-overflow warning
  scsi: lpfc: fix gcc -Wstringop-overread warning
  drm/i915: avoid stringop-overread warning on pri_latency
  [RFC] drm/i915/dp: fix array overflow warning

 arch/arm/common/sharpsl_param.c |  4 ++-
 arch/x86/boot/compressed/misc.c |  2 --
 arch/x86/kernel/tboot.c | 44 +++--
 drivers/gpu/drm/i915/display/intel_dp.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.h |  6 ++--
 drivers/net/wireless/ath/ath11k/mac.c   |  2 +-
 drivers/net/wireless/atmel/atmel.c  | 25 --
 drivers/scsi/lpfc/lpfc_attr.c   |  6 ++--
 fs/qnx4/dir.c   | 11 +++
 kernel/cgroup/cgroup.c  | 15 +++--
 security/commoncap.c|  2 +-
 11 files changed, 69 insertions(+), 50 deletions(-)

Cc: x...@kernel.org
Cc: Ning Sun 
Cc: Jani Nikula 
Cc: Kalle Valo 
Cc: Simon Kelley 
Cc: James Smart 
Cc: "James E.J. Bottomley" 
Cc: Anders Larsen 
Cc: Tejun Heo 
Cc: Serge Hallyn 
Cc: Imre Deak 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: tboot-de...@lists.sourceforge.net
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Cc: ath...@lists.infradead.org
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-s...@vger.kernel.org
Cc: cgro...@vger.kernel.org
Cc: linux-security-mod...@vger.kernel.org


-- 
2.29.2

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

[Intel-gfx] [PATCH 3/3] drm/i915: skip display initialization when there is no display

[José Roberto de Souza]

Display features should not be initialized or de-initialized when there
is no display. Skip modeset initialization, output setup, plane, crtc,
encoder, connector registration, display cdclk and rawclk
initialization, display core initialization, etc.

Skip the functionality at as high level as possible, and remove any
redundant checks. If the functionality is conditional to *other* display
checks, do not add more. If the un-initialization has checks for
initialization, do not add more.

We explicitly do not care about any GMCH/VLV/CHV code paths, as they've
always had and will have display.

Cc: Lucas De Marchi 
Signed-off-by: José Roberto de Souza 
Signed-off-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c  | 44 +++
 .../drm/i915/display/intel_display_power.c| 36 +++
 drivers/gpu/drm/i915/display/intel_dp.c   |  6 +++
 drivers/gpu/drm/i915/display/intel_gmbus.c|  3 --
 drivers/gpu/drm/i915/display/intel_hotplug.c  | 12 +
 drivers/gpu/drm/i915/display/intel_pps.c  |  5 ++-
 drivers/gpu/drm/i915/i915_drv.c   | 28 +---
 drivers/gpu/drm/i915/i915_suspend.c   |  6 +++
 8 files changed, 120 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 7b38b9a38b85..b10bf7e06ee7 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1613,6 +1613,9 @@ u32 intel_plane_fb_max_stride(struct drm_i915_private 
*dev_priv,
struct intel_crtc *crtc;
struct intel_plane *plane;
 
+   if (!HAS_DISPLAY(dev_priv))
+   return 0;
+
/*
 * We assume the primary plane for pipe A has
 * the highest stride limits of them all,
@@ -4629,6 +4632,9 @@ int intel_display_suspend(struct drm_device *dev)
struct drm_atomic_state *state;
int ret;
 
+   if (!HAS_DISPLAY(dev_priv))
+   return 0;
+
state = drm_atomic_helper_suspend(dev);
ret = PTR_ERR_OR_ZERO(state);
if (ret)
@@ -12239,6 +12245,9 @@ static const struct drm_mode_config_funcs 
intel_mode_funcs = {
  */
 void intel_init_display_hooks(struct drm_i915_private *dev_priv)
 {
+   if (!HAS_DISPLAY(dev_priv))
+   return;
+
intel_init_cdclk_hooks(dev_priv);
intel_init_audio_hooks(dev_priv);
 
@@ -12281,8 +12290,12 @@ void intel_init_display_hooks(struct drm_i915_private 
*dev_priv)
 
 void intel_modeset_init_hw(struct drm_i915_private *i915)
 {
-   struct intel_cdclk_state *cdclk_state =
-   to_intel_cdclk_state(i915->cdclk.obj.state);
+   struct intel_cdclk_state *cdclk_state;
+
+   if (!HAS_DISPLAY(i915))
+   return;
+
+   cdclk_state = to_intel_cdclk_state(i915->cdclk.obj.state);
 
intel_update_cdclk(i915);
intel_dump_cdclk_config(&i915->cdclk.hw, "Current CDCLK");
@@ -12598,6 +12611,9 @@ int intel_modeset_init_noirq(struct drm_i915_private 
*i915)
/* FIXME: completely on the wrong abstraction layer */
intel_power_domains_init_hw(i915, false);
 
+   if (!HAS_DISPLAY(i915))
+   return 0;
+
intel_csr_ucode_init(i915);
 
i915->modeset_wq = alloc_ordered_workqueue("i915_modeset", 0);
@@ -12648,6 +12664,9 @@ int intel_modeset_init_nogem(struct drm_i915_private 
*i915)
struct intel_crtc *crtc;
int ret;
 
+   if (!HAS_DISPLAY(i915))
+   return 0;
+
intel_init_pm(i915);
 
intel_panel_sanitize_ssc(i915);
@@ -12660,13 +12679,11 @@ int intel_modeset_init_nogem(struct drm_i915_private 
*i915)
INTEL_NUM_PIPES(i915),
INTEL_NUM_PIPES(i915) > 1 ? "s" : "");
 
-   if (HAS_DISPLAY(i915)) {
-   for_each_pipe(i915, pipe) {
-   ret = intel_crtc_init(i915, pipe);
-   if (ret) {
-   intel_mode_config_cleanup(i915);
-   return ret;
-   }
+   for_each_pipe(i915, pipe) {
+   ret = intel_crtc_init(i915, pipe);
+   if (ret) {
+   intel_mode_config_cleanup(i915);
+   return ret;
}
}
 
@@ -13602,6 +13619,9 @@ void intel_display_resume(struct drm_device *dev)
struct drm_modeset_acquire_ctx ctx;
int ret;
 
+   if (!HAS_DISPLAY(dev_priv))
+   return;
+
dev_priv->modeset_restore_state = NULL;
if (state)
state->acquire_ctx = &ctx;
@@ -13651,6 +13671,9 @@ static void intel_hpd_poll_fini(struct drm_i915_private 
*i915)
 /* part #1: call before irq uninstall */
 void intel_modeset_driver_remove(struct drm_i915_private *i915)
 {
+   if (!HAS_DISPLAY(i915))
+   return;
+
flush_workqueue(i915->flip_wq);
flush_workqueue(i915-

[Intel-gfx] [PATCH 2/3] drm/i915: Do not set any power wells when there is no display

[José Roberto de Souza]

Power wells are only part of display block and not necessary when
running a headless driver.

Cc: Lucas De Marchi 
Signed-off-by: José Roberto de Souza 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_display_power.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 7e0eaa872350..e6a3b3e6b1f7 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -4673,7 +4673,10 @@ int intel_power_domains_init(struct drm_i915_private 
*dev_priv)
 * The enabling order will be from lower to higher indexed wells,
 * the disabling order is reversed.
 */
-   if (IS_ALDERLAKE_S(dev_priv) || IS_DG1(dev_priv)) {
+   if (!HAS_DISPLAY(dev_priv)) {
+   power_domains->power_well_count = 0;
+   err = 0;
+   } else if (IS_ALDERLAKE_S(dev_priv) || IS_DG1(dev_priv)) {
err = set_power_wells_mask(power_domains, tgl_power_wells,
   BIT_ULL(TGL_DISP_PW_TC_COLD_OFF));
} else if (IS_ROCKETLAKE(dev_priv)) {
-- 
2.31.0

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

[Intel-gfx] [PATCH 1/3] drm/i915: Warn when display irq functions are called without display

[José Roberto de Souza]

With previous changes none of those warnings will be printed but let's
add them so CI can caught regressions.

Cc: Lucas De Marchi 
Signed-off-by: José Roberto de Souza 
Signed-off-by: Jani Nikula 
---
 .../gpu/drm/i915/display/intel_fifo_underrun.c  |  2 ++
 drivers/gpu/drm/i915/display/intel_hotplug.c|  2 ++
 drivers/gpu/drm/i915/i915_irq.c | 17 +
 3 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_fifo_underrun.c 
b/drivers/gpu/drm/i915/display/intel_fifo_underrun.c
index 813a4f7033e1..f3631e319e5d 100644
--- a/drivers/gpu/drm/i915/display/intel_fifo_underrun.c
+++ b/drivers/gpu/drm/i915/display/intel_fifo_underrun.c
@@ -373,6 +373,8 @@ void intel_cpu_fifo_underrun_irq_handler(struct 
drm_i915_private *dev_priv,
 {
struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
 
+   drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_DISPLAY(dev_priv));
+
/* We may be called too early in init, thanks BIOS! */
if (crtc == NULL)
return;
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c 
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index f46a1b7190b8..77ce4a54a137 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -478,6 +478,8 @@ void intel_hpd_irq_handler(struct drm_i915_private 
*dev_priv,
if (!pin_mask)
return;
 
+   drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_DISPLAY(dev_priv));
+
spin_lock(&dev_priv->irq_lock);
 
/*
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 44aed4cbf894..cbb2aae4fc13 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -519,6 +519,8 @@ void i915_enable_pipestat(struct drm_i915_private *dev_priv,
i915_reg_t reg = PIPESTAT(pipe);
u32 enable_mask;
 
+   drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_DISPLAY(dev_priv));
+
drm_WARN_ONCE(&dev_priv->drm, status_mask & ~PIPESTAT_INT_STATUS_MASK,
  "pipe %c: status_mask=0x%x\n",
  pipe_name(pipe), status_mask);
@@ -1273,6 +1275,7 @@ static u32 intel_hpd_hotplug_enables(struct 
drm_i915_private *i915,
 
 static void gmbus_irq_handler(struct drm_i915_private *dev_priv)
 {
+   drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_DISPLAY(dev_priv));
wake_up_all(&dev_priv->gmbus_wait_queue);
 }
 
@@ -1366,6 +1369,8 @@ static void i9xx_pipe_crc_irq_handler(struct 
drm_i915_private *dev_priv,
 {
u32 res1, res2;
 
+   drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_DISPLAY(dev_priv));
+
if (INTEL_GEN(dev_priv) >= 3)
res1 = intel_uncore_read(&dev_priv->uncore, 
PIPE_CRC_RES_RES1_I915(pipe));
else
@@ -1558,6 +1563,8 @@ static u32 i9xx_hpd_irq_ack(struct drm_i915_private 
*dev_priv)
u32 hotplug_status = 0, hotplug_status_mask;
int i;
 
+   drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_DISPLAY(dev_priv));
+
if (IS_G4X(dev_priv) ||
IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
hotplug_status_mask = HOTPLUG_INT_STATUS_G4X |
@@ -1597,6 +1604,8 @@ static void i9xx_hpd_irq_handler(struct drm_i915_private 
*dev_priv,
u32 pin_mask = 0, long_mask = 0;
u32 hotplug_trigger;
 
+   drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_DISPLAY(dev_priv));
+
if (IS_G4X(dev_priv) ||
IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_G4X;
@@ -2038,6 +2047,8 @@ static void ilk_display_irq_handler(struct 
drm_i915_private *dev_priv,
enum pipe pipe;
u32 hotplug_trigger = de_iir & DE_DP_A_HOTPLUG;
 
+   drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_DISPLAY(dev_priv));
+
if (hotplug_trigger)
ilk_hpd_irq_handler(dev_priv, hotplug_trigger);
 
@@ -2087,6 +2098,8 @@ static void ivb_display_irq_handler(struct 
drm_i915_private *dev_priv,
enum pipe pipe;
u32 hotplug_trigger = de_iir & DE_DP_A_HOTPLUG_IVB;
 
+   drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_DISPLAY(dev_priv));
+
if (hotplug_trigger)
ilk_hpd_irq_handler(dev_priv, hotplug_trigger);
 
@@ -2421,6 +2434,8 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
u32 master_ctl)
u32 iir;
enum pipe pipe;
 
+   drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_DISPLAY(dev_priv));
+
if (master_ctl & GEN8_DE_MISC_IRQ) {
iir = intel_uncore_read(&dev_priv->uncore, GEN8_DE_MISC_IIR);
if (iir) {
@@ -3477,6 +3492,8 @@ static void spt_hpd_irq_setup(struct drm_i915_private 
*dev_priv)
 {
u32 hotplug_irqs, enabled_irqs;
 
+   drm_WARN_ON_ONCE(&dev_priv->drm, !HAS_DISPLAY(dev_priv));
+
if (INTEL_PCH_TYPE(dev_priv) >= PCH_CNP)
intel_uncore_write(&dev_priv->uncore, SHPD_FILTER_CNT, 
SHPD_FILTER_CNT_500_ADJ);
 
-- 
2.31.0

Re: [Intel-gfx] [bug report] drm/i915: Computer does not shutdown,

[Hans de Goede]

Hi,

On 3/22/21 5:00 PM, Ville Syrjälä wrote:
> On Mon, Mar 22, 2021 at 04:51:26PM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 3/22/21 3:53 PM, Ville Syrjälä wrote:
>>> On Mon, Mar 22, 2021 at 11:45:39AM +0100, Hans de Goede wrote:
 Hi,

 On 3/14/21 11:30 AM, Mario Hüttel wrote:
> Hello,
>
> It seems, like the mailing list, didn't accept my email. So I'll send
> it again:
>
> I want to report a bug. I have a PC with Intel i7-6700K processor (with
> integrated graphics) and an AsRock Fatal1ty Z170 Gaming K6 mainboard. I
> use the CPU's integrated graphics.
> My system is Archlinux with Kernel v5.11.6.
>
> Using this setup, my PC works normally. However, when I shut it down,
> the power is not cut. Fans keep spinning and LEDs stay on. I couldn't
> detect any other problem when shutting down. Drives etc. stop as
> expected and the video is blank. Even after waiting several hours, the
> system doesn't power down.
>
> Restarts work normally.
>
> I haven't yet found any other people on the internet that have the same
> bug.
>
> I used git bisect to find the commit that causes this behavior on my
> machine.

 Thank you for doing a bisect that is always very helpful.

> The result is: fe0f1e3bfdfeb53e18f1206aea4f40b9bd1f291c is the
> first bad commit.

 To save others the trouble of having to look up the hasj, that is:

 "drm/i915: Shut down displays gracefully on reboot"

 Which is the same commit as which I've reported is causing issues
 with DSI panels not lighting up on reboots on some BYT/CHT devices.

 Since this seems to mostly be intended to fix issues surrounding
 DP MST stuff, maybe the graceful shutdown should only be done when
 MST is in use?
>>>
>>> No. It also fixes Windows, lols.
>>
>> Ok, can you at least take a look at my patch which fixes (works-around)
>> the issues for DSI panel on BYT/CHT DSI devices:
>>
>> https://patchwork.freedesktop.org/patch/422481/
>>
>> ?
> 
> Never reached my inbox.

Yes I'm seeing a lot of bounces from the linux.intel.com mailserver lately
(and only from that mail server and not from any other mailservers).

You should have also received a copy through the intel-gfx lists though.

Or you can grab a raw copy from patchwork.

Regardless of the mail-issue a review would be much appreciated.

Regards,

Hans


p.s.

While on the subjects of bouncing emails, did you see Jani's reply to:
https://patchwork.freedesktop.org/patch/422669/

Where he asks for a second opinion on that patch from you ?

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

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Restrict sentinel requests further

[Matthew Auld]

On Thu, 18 Mar 2021 at 17:04, Tvrtko Ursulin
 wrote:
>
> From: Tvrtko Ursulin 
>
> Disallow sentinel requests follow previous sentinels to make request
> cancellation work better when faced with a chain of requests which have
> all been marked as in error.

Could you elaborate some more on why this makes request cancellation
work better?

>
> Signed-off-by: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index 4c2acb5a6c0a..4b870eca9693 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -896,7 +896,7 @@ static bool can_merge_rq(const struct i915_request *prev,
> if (__i915_request_is_complete(next))
> return true;
>
> -   if (unlikely((i915_request_flags(prev) ^ i915_request_flags(next)) &
> +   if (unlikely((i915_request_flags(prev) | i915_request_flags(next)) &
>  (BIT(I915_FENCE_FLAG_NOPREEMPT) |
>   BIT(I915_FENCE_FLAG_SENTINEL
> return false;
> --
> 2.27.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Implement SINGLE_TIMELINE with a syncobj

[Daniel Vetter]

On Fri, Mar 19, 2021 at 05:38:56PM -0500, Jason Ekstrand wrote:
> I'd love to delete the SINGLE_TIMELINE API because it leaks an
> implementation detail of contexts through to the API and is something
> that userspace can do itself, trivially.  Unfortunately, it's used by
> the media driver so we can't do that.  We can, however, do the next-best
> thing which is to embed a syncobj in the context and do exactly what
> we'd expect from userspace internally.
> 
> This has a couple of advantages.  One is that we're no longer leaking a
> detail of the current execlist scheduler which will be problematic when
> we try to add GuC scheduling.  Second is that, together with deleting
> the CLONE_CONTEXT API, we should now have a 1:1 mapping between
> intel_context and intel_timeline which should make some of our locking
> mess a bit easier.
> 
> Signed-off-by: Jason Ekstrand 
> Cc: Maarten Lankhorst 
> Cc: Matthew Brost 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 47 ---
>  .../gpu/drm/i915/gem/i915_gem_context_types.h |  8 +++-
>  .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 15 ++
>  3 files changed, 32 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index f88bac19333ec..e094f4a1ca4cd 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -67,6 +67,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #include "gt/gen6_ppgtt.h"
>  #include "gt/intel_context.h"
>  #include "gt/intel_engine_heartbeat.h"
> @@ -224,10 +226,6 @@ static void intel_context_set_gem(struct intel_context 
> *ce,
>   ce->vm = vm;
>   }
>  
> - GEM_BUG_ON(ce->timeline);
> - if (ctx->timeline)
> - ce->timeline = intel_timeline_get(ctx->timeline);
> -
>   if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
>   intel_engine_has_timeslices(ce->engine))
>   __set_bit(CONTEXT_USE_SEMAPHORES, &ce->flags);
> @@ -344,8 +342,8 @@ void i915_gem_context_release(struct kref *ref)
>   mutex_destroy(&ctx->engines_mutex);
>   mutex_destroy(&ctx->lut_mutex);
>  
> - if (ctx->timeline)
> - intel_timeline_put(ctx->timeline);
> + if (ctx->syncobj)
> + drm_syncobj_put(ctx->syncobj);
>  
>   put_pid(ctx->pid);
>   mutex_destroy(&ctx->mutex);
> @@ -790,33 +788,11 @@ static void __assign_ppgtt(struct i915_gem_context *ctx,
>   i915_vm_close(vm);
>  }
>  
> -static void __set_timeline(struct intel_timeline **dst,
> -struct intel_timeline *src)
> -{
> - struct intel_timeline *old = *dst;
> -
> - *dst = src ? intel_timeline_get(src) : NULL;
> -
> - if (old)
> - intel_timeline_put(old);
> -}
> -
> -static void __apply_timeline(struct intel_context *ce, void *timeline)
> -{
> - __set_timeline(&ce->timeline, timeline);
> -}
> -
> -static void __assign_timeline(struct i915_gem_context *ctx,
> -   struct intel_timeline *timeline)
> -{
> - __set_timeline(&ctx->timeline, timeline);
> - context_apply_all(ctx, __apply_timeline, timeline);
> -}
> -
>  static struct i915_gem_context *
>  i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
>  {
>   struct i915_gem_context *ctx;
> + int ret;
>  
>   if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&
>   !HAS_EXECLISTS(i915))
> @@ -845,16 +821,13 @@ i915_gem_create_context(struct drm_i915_private *i915, 
> unsigned int flags)
>   }
>  
>   if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
> - struct intel_timeline *timeline;
> -
> - timeline = intel_timeline_create(&i915->gt);
> - if (IS_ERR(timeline)) {
> + ret = drm_syncobj_create(&ctx->syncobj,
> +  DRM_SYNCOBJ_CREATE_SIGNALED,
> +  NULL);
> + if (ret) {
>   context_close(ctx);
> - return ERR_CAST(timeline);
> + return ERR_PTR(ret);
>   }
> -
> - __assign_timeline(ctx, timeline);
> - intel_timeline_put(timeline);
>   }
>  
>   trace_i915_context_create(ctx);
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h 
> b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> index 676592e27e7d2..8a5fdd163b79d 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> @@ -83,7 +83,13 @@ struct i915_gem_context {
>   struct i915_gem_engines __rcu *engines;
>   struct mutex engines_mutex; /* guards writes to engines */
>  
> - struct intel_timeline *timeline;
> + /**
> +  * @syncobj: Shared timeline syncobj
> +  *
> +  * When the SHARED_TIMELINE flag is set on context creation, this
> +  * provides au

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Drop the CONTEXT_CLONE API

[Daniel Vetter]

On Mon, Mar 22, 2021 at 4:31 PM Tvrtko Ursulin
 wrote:
>
>
> On 22/03/2021 14:57, Daniel Vetter wrote:
> > On Mon, Mar 22, 2021 at 3:33 PM Tvrtko Ursulin
> >  wrote:
> >>
> >>
> >> On 22/03/2021 14:09, Daniel Vetter wrote:
> >>> On Mon, Mar 22, 2021 at 11:22:01AM +, Tvrtko Ursulin wrote:
> 
>  On 19/03/2021 22:38, Jason Ekstrand wrote:
> > This API allows one context to grab bits out of another context upon
> > creation.  It can be used as a short-cut for setparam(getparam()) for
> > things like I915_CONTEXT_PARAM_VM.  However, it's never been used by any
> > real userspace.  It's used by a few IGT tests and that's it.  Since it
> > doesn't add any real value (most of the stuff you can CLONE you can copy
> > in other ways), drop it.
> 
>  No complaints to remove if it ended up unused outside IGT. Latter is a 
>  _big_
>  problem though, since it is much more that a few IGT tests. So I really
>  think there really needs to be an evaluation and a plan for that (we 
>  don't
>  want to lose 50% of the coverage over night).
> 
> > There is one thing that this API allows you to clone which you cannot
> > clone via getparam/setparam: timelines.  However, timelines are an
> > implementation detail of i915 and not really something that needs to be
> 
>  Not really true timelines are i915 implementation detail. They are in 
>  fact a
>  dma-fence context:seqno concept, nothing more that than. I think you are
>  probably confusing struct intel_timeline with the timeline wording in the
>  uapi. Former is i915 implementation detail, but context:seqno are truly
>  userspace timelines.
> >>>
> >>> I think you're both saying the same thing and talking a bit past each
> >>> another.
> >>>
> >>> Yes the timeline is just a string of dma_fence, that's correct. Now
> >>> usually if you submit batches with execbuf, we have 3 ways to synchronize
> >>> concurrent submission: implicit sync, sync_file and drm_syncob. They all
> >>> map to different needs in different protocols/render apis.
> >>>
> >>> Now in one additional case the kernel makes sure that batchbuffers are
> >>> ordered, and that's when you submit them to the same hw ctx. Because
> >>> there's only 1 hw context and you really can't have batchbuffers run on
> >>> that single hw context out of order. That's what the timeline object we
> >>> talk about here is. But that largely is an internal implementation detail,
> >>> which happens to also use most/all the same infrastructure as the
> >>> dma_fence uapi pieces above.
> >>>
> >>> Now the internal implementation detail leaking here is that we exposed
> >>> this to userspace, without there being any need for this. What Jason
> >>> implements with syncobj in the next patch is essentially what userspace
> >>> should have been using for cross-engine sync. media userspace doesn't care
> >>> about interop with winsys/client apis, so they equally could have used
> >>> implicit sync or sync_file here (which I think is the solution now for the
> >>> new uapi prepped internally), since they all are about equally powerful
> >>> for stringing batchbuffers together.
> >>
> >> Are you saying we exposed a single timeline of execution per hw context
> >> via the single timeline flag?!
> >
> > Nope.
> >
> >> Timelines of execution were always exposed. Any "engine" (ring
> >> previously) in I915_EXEC_RING_MASK was a single timeline of execution.
> >> It is completely the same with engine map engines, which are also
> >> different indices into I915_EXEC_RING_MASK space.
> >>
> >> Userspace was aware of these timelines forever as well. Media was
> >> creating multiple contexts to have multiple timelines (so parallelism).
> >> Everyone knew that engine-hopping submissions needs to be either
> >> implicitly or explicitly synchronised, etc.
> >
> > Yup, I think we're saying the same thing here.
> >
> >> So I really don't see that we have leaked timelines as a concept *now*.
> >> What the patch has exposed to userspace is a new way to sync between
> >> timelines and nothing more.
> >
> > We've leaked it as something you can now share across hw context.
>
> Okay so we agree on most things but apparently have different
> definitions of what it means to leak internal implementation details.
>
> While at the same time proof that we haven't leaked the internal
> implementation details is that Jason was able to implement the single
> timeline flag with a drm syncobj at the execbuf top level. (Well mostly,
> ignoring the probably inconsequential difference of one vs multiple
> fence contexts.)

It's not a matching implementation. It's only good enough for what
media needs, and essentially what media should have done to begin
with.

There's substantially different behaviour between SINGLE_TIMELINE and
what Jason has done here when you race concurrent execbuf calls:
Former guarantees total ordering, the latter doesn't even try. They
are not the

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE

[Daniel Vetter]

On Mon, Mar 22, 2021 at 5:01 PM Jason Ekstrand  wrote:
>
> On Mon, Mar 22, 2021 at 7:01 AM Jani Nikula  
> wrote:
> >
> > On Sat, 20 Mar 2021, Jason Ekstrand  wrote:
> > > This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a.  This 
> > > API
> >
> > Small nit, I think it would be useful to reference commits with the
> > citation style:
> >
> > 88be76cdafc7 ("drm/i915: Allow userspace to specify ringsize on 
> > construction")
>
> Done.
>
> >
> > I use this monster in my .gitconfig:
> >
> > [alias]
> > cite = "!f() { git log -1 '--pretty=format:%H (\"%s\")%n' $1 | sed 
> > -e 's/\\([0-f]\\{12\\}\\)[0-f]*/\\1/'; }; f"
>
> Thanks for the tip!

dim script from maintainer-tools has a bunch of these helpers
(andother one is dim fixes for generating Cc: lists) which should work
even without commit rights and all that set up:

https://gitlab.freedesktop.org/drm/maintainer-tools/-/blob/master/dim

Cheers, Daniel

>
> > With that, 'git cite ' will give you the nice reference with
> > 12 chars of sha1 regardless of core.abbrev config.
> >
> >
> > BR,
> > Jani.
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Drop the CONTEXT_CLONE API

[Jason Ekstrand]

Ugh... timezones.

On Mon, Mar 22, 2021 at 10:31 AM Tvrtko Ursulin
 wrote:
>
>
> On 22/03/2021 14:57, Daniel Vetter wrote:
> > On Mon, Mar 22, 2021 at 3:33 PM Tvrtko Ursulin
> >  wrote:
> >>
> >>
> >> On 22/03/2021 14:09, Daniel Vetter wrote:
> >>> On Mon, Mar 22, 2021 at 11:22:01AM +, Tvrtko Ursulin wrote:
> 
>  On 19/03/2021 22:38, Jason Ekstrand wrote:
> > This API allows one context to grab bits out of another context upon
> > creation.  It can be used as a short-cut for setparam(getparam()) for
> > things like I915_CONTEXT_PARAM_VM.  However, it's never been used by any
> > real userspace.  It's used by a few IGT tests and that's it.  Since it
> > doesn't add any real value (most of the stuff you can CLONE you can copy
> > in other ways), drop it.
> 
>  No complaints to remove if it ended up unused outside IGT. Latter is a 
>  _big_
>  problem though, since it is much more that a few IGT tests. So I really
>  think there really needs to be an evaluation and a plan for that (we 
>  don't
>  want to lose 50% of the coverage over night).

You should look at my IGT patch set.  I'm not deleting any tests
except those that explicitly test the clone API.  All the other tests
which use cloning to save a few lines when constructing new contexts
are updated to not require the cloning API.

> > There is one thing that this API allows you to clone which you cannot
> > clone via getparam/setparam: timelines.  However, timelines are an
> > implementation detail of i915 and not really something that needs to be
> 
>  Not really true timelines are i915 implementation detail. They are in 
>  fact a
>  dma-fence context:seqno concept, nothing more that than. I think you are
>  probably confusing struct intel_timeline with the timeline wording in the
>  uapi. Former is i915 implementation detail, but context:seqno are truly
>  userspace timelines.
> >>>
> >>> I think you're both saying the same thing and talking a bit past each
> >>> another.
> >>>
> >>> Yes the timeline is just a string of dma_fence, that's correct. Now
> >>> usually if you submit batches with execbuf, we have 3 ways to synchronize
> >>> concurrent submission: implicit sync, sync_file and drm_syncob. They all
> >>> map to different needs in different protocols/render apis.

Right.  We've always had the concept that everything submitted to
given HW context happens in-order.  As Daniel said below, allowing
out-of-order execution on a single HW context would be a bit nuts
because HW contexts are, by definition, stateful.  What this API adds
is a way to do in-order synchronization across multiple HW contexts
which is both new and unnecessary given the other primitives
available.

> >>> Now in one additional case the kernel makes sure that batchbuffers are
> >>> ordered, and that's when you submit them to the same hw ctx. Because
> >>> there's only 1 hw context and you really can't have batchbuffers run on
> >>> that single hw context out of order. That's what the timeline object we
> >>> talk about here is. But that largely is an internal implementation detail,
> >>> which happens to also use most/all the same infrastructure as the
> >>> dma_fence uapi pieces above.
> >>>
> >>> Now the internal implementation detail leaking here is that we exposed
> >>> this to userspace, without there being any need for this. What Jason
> >>> implements with syncobj in the next patch is essentially what userspace
> >>> should have been using for cross-engine sync. media userspace doesn't care
> >>> about interop with winsys/client apis, so they equally could have used
> >>> implicit sync or sync_file here (which I think is the solution now for the
> >>> new uapi prepped internally), since they all are about equally powerful
> >>> for stringing batchbuffers together.
> >>
> >> Are you saying we exposed a single timeline of execution per hw context
> >> via the single timeline flag?!
> >
> > Nope.
> >
> >> Timelines of execution were always exposed. Any "engine" (ring
> >> previously) in I915_EXEC_RING_MASK was a single timeline of execution.
> >> It is completely the same with engine map engines, which are also
> >> different indices into I915_EXEC_RING_MASK space.
> >>
> >> Userspace was aware of these timelines forever as well. Media was
> >> creating multiple contexts to have multiple timelines (so parallelism).
> >> Everyone knew that engine-hopping submissions needs to be either
> >> implicitly or explicitly synchronised, etc.
> >
> > Yup, I think we're saying the same thing here.
> >
> >> So I really don't see that we have leaked timelines as a concept *now*.
> >> What the patch has exposed to userspace is a new way to sync between
> >> timelines and nothing more.
> >
> > We've leaked it as something you can now share across hw context.
>
> Okay so we agree on most things but apparently have different
> definitions of what it means to leak internal implementation d

Re: [Intel-gfx] [PATCH 5/7] drm/i915/display: Extract ilk_read_csc()

[Ville Syrjälä]

On Mon, Mar 22, 2021 at 08:00:06PM +0530, Bhanuprakash Modem wrote:
> For ilk+, add hw read out to create hw blob of ctm coeff values.

We need an explanation why this is safe given display w/a 1184...

> 
> Cc: Swati Sharma 
> Cc: Uma Shankar 
> Signed-off-by: Bhanuprakash Modem 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 52 ++
>  1 file changed, 52 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 15f97fbb77b3..877833f294bb 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -321,6 +321,54 @@ static void ilk_load_csc_matrix(const struct 
> intel_crtc_state *crtc_state)
>  crtc_state->csc_mode);
>  }
>  
> +static struct drm_property_blob *ilk_read_csc_matrix(struct intel_crtc *crtc)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe pipe = crtc->pipe;
> + struct drm_property_blob *blob;
> + struct drm_color_ctm *ctm;
> + u32 temp;
> +
> + blob = drm_property_create_blob(&dev_priv->drm,
> + sizeof(struct drm_color_ctm),
> + NULL);
> + if (IS_ERR(blob))
> + return NULL;
> +
> + ctm = blob->data;
> +
> + temp = intel_de_read(dev_priv, PIPE_CSC_COEFF_RY_GY(pipe));
> + ctm->matrix[0] = (temp >> 16) & 0x;
> + ctm->matrix[1] = temp & 0x;
> +
> + temp = intel_de_read(dev_priv, PIPE_CSC_COEFF_BY(pipe));
> + ctm->matrix[2] = (temp >> 16) & 0x;
> +
> + temp = intel_de_read(dev_priv, PIPE_CSC_COEFF_RU_GU(pipe));
> + ctm->matrix[3] = (temp >> 16) & 0x;
> + ctm->matrix[4] = temp & 0x;
> +
> + temp = intel_de_read(dev_priv, PIPE_CSC_COEFF_BU(pipe));
> + ctm->matrix[5] = (temp >> 16) & 0x;
> +
> + temp = intel_de_read(dev_priv, PIPE_CSC_COEFF_RV_GV(pipe));
> + ctm->matrix[6] = (temp >> 16) & 0x;
> + ctm->matrix[7] = temp & 0x;
> +
> + temp = intel_de_read(dev_priv, PIPE_CSC_COEFF_BV(pipe));
> + ctm->matrix[8] = (temp >> 16) & 0x;
> +
> + return blob;
> +}
> +
> +static void ilk_read_csc(struct intel_crtc_state *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> +
> + if (crtc_state->csc_enable)
> + crtc_state->hw.ctm = ilk_read_csc_matrix(crtc);
> +}
> +
>  static void icl_load_csc_matrix(const struct intel_crtc_state *crtc_state)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> @@ -2226,13 +2274,17 @@ void intel_color_init(struct intel_crtc *crtc)
>   } else if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) {
>   dev_priv->display.load_luts = glk_load_luts;
>   dev_priv->display.read_luts = glk_read_luts;
> + dev_priv->display.read_csc = ilk_read_csc;
>   } else if (INTEL_GEN(dev_priv) >= 8) {
>   dev_priv->display.load_luts = bdw_load_luts;
> + dev_priv->display.read_csc = ilk_read_csc;
>   } else if (INTEL_GEN(dev_priv) >= 7) {
>   dev_priv->display.load_luts = ivb_load_luts;
> + dev_priv->display.read_csc = ilk_read_csc;
>   } else {
>   dev_priv->display.load_luts = ilk_load_luts;
>   dev_priv->display.read_luts = ilk_read_luts;
> + dev_priv->display.read_csc = ilk_read_csc;
>   }
>   }
>  
> -- 
> 2.20.1
> 
> ___
> 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 0/7] drm/i915: Add state checker for CSC coeff values

[Ville Syrjälä]

On Mon, Mar 22, 2021 at 08:00:01PM +0530, Bhanuprakash Modem wrote:
> In this patch series, added state checker to validate CSC. This reads
> hardware state, and compares the originally requested state(s/w). This
> is done for chv, ilk, glk and their variant platforms. Rest of
> the platforms will be enabled on top of this later.
> 
> Signed-off-by: Bhanuprakash Modem 
> 
> Bhanuprakash Modem (7):
>   drm/i915/display: Introduce vfunc read_csc() to create hw ctm
>   drm/i915/display: Add func to compare hw/sw CSC matrix
>   drm/i915/display: Add macro to compare hw/sw CSC matrix
>   drm/i915/display: Extract chv_read_csc()
>   drm/i915/display: Extract ilk_read_csc()
>   drm/i915/display: Extract icl_read_csc()

The patch subjects are confusing me. You're not extracting any code
AFAICS?

>   FOR_TESTING_ONLY: Print coeffs of hw and sw CTM
> 
>  drivers/gpu/drm/i915/display/intel_color.c   | 209 ++-
>  drivers/gpu/drm/i915/display/intel_color.h   |   3 +
>  drivers/gpu/drm/i915/display/intel_display.c |  31 +++
>  drivers/gpu/drm/i915/i915_drv.h  |   1 +
>  4 files changed, 239 insertions(+), 5 deletions(-)
> 
> --
> 2.20.1
> 
> ___
> 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 4/7] drm/i915/display: Extract chv_read_csc()

[Ville Syrjälä]

On Mon, Mar 22, 2021 at 08:00:05PM +0530, Bhanuprakash Modem wrote:
> For Cherryview, add hw read out to create hw blob of ctm coeff
> values.
> 
> Cc: Swati Sharma 
> Cc: Uma Shankar 
> Signed-off-by: Bhanuprakash Modem 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 47 ++
>  1 file changed, 47 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 54dfd3523272..15f97fbb77b3 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1943,6 +1943,52 @@ static void chv_read_luts(struct intel_crtc_state 
> *crtc_state)
>   i965_read_luts(crtc_state);
>  }
>  
> +static struct drm_property_blob *chv_read_cgm_ctm(struct intel_crtc *crtc)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe pipe = crtc->pipe;
> + struct drm_property_blob *blob;
> + struct drm_color_ctm *ctm;
> + u32 temp;
> +
> + blob = drm_property_create_blob(&dev_priv->drm,
> + sizeof(struct drm_color_ctm),
> + NULL);
> + if (IS_ERR(blob))
> + return NULL;
> +
> + ctm = blob->data;
> +
> + temp = intel_de_read(dev_priv, CGM_PIPE_CSC_COEFF01(pipe));
> + ctm->matrix[0] = (temp >> 16) & 0x;
> + ctm->matrix[1] = temp & 0x;

We can't store hardware specific junk into the ctm. It needs to get
converted to the proper format.

Would also be a good time to fix the CHV CSC programming to handle
negative values correct, and should probably extend the test cases
to actually catch that particular failure...

> +
> + temp = intel_de_read(dev_priv, CGM_PIPE_CSC_COEFF23(pipe));
> + ctm->matrix[2] = (temp >> 16) & 0x;
> + ctm->matrix[3] = temp & 0x;
> +
> + temp = intel_de_read(dev_priv, CGM_PIPE_CSC_COEFF45(pipe));
> + ctm->matrix[4] = (temp >> 16) & 0x;
> + ctm->matrix[5] = temp & 0x;
> +
> + temp = intel_de_read(dev_priv, CGM_PIPE_CSC_COEFF67(pipe));
> + ctm->matrix[6] = (temp >> 16) & 0x;
> + ctm->matrix[7] = temp & 0x;
> +
> + temp = intel_de_read(dev_priv, CGM_PIPE_CSC_COEFF8(pipe));
> + ctm->matrix[8] = (temp >> 16) & 0x;
> +
> + return blob;
> +}
> +
> +static void chv_read_csc(struct intel_crtc_state *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> +
> + if (crtc_state->cgm_mode & CGM_PIPE_MODE_CSC)
> + crtc_state->hw.ctm = chv_read_cgm_ctm(crtc);
> +}
> +
>  static struct drm_property_blob *ilk_read_lut_8(struct intel_crtc *crtc)
>  {
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> @@ -2145,6 +2191,7 @@ void intel_color_init(struct intel_crtc *crtc)
>   dev_priv->display.color_commit = i9xx_color_commit;
>   dev_priv->display.load_luts = chv_load_luts;
>   dev_priv->display.read_luts = chv_read_luts;
> + dev_priv->display.read_csc = chv_read_csc;
>   } else if (INTEL_GEN(dev_priv) >= 4) {
>   dev_priv->display.color_check = i9xx_color_check;
>   dev_priv->display.color_commit = i9xx_color_commit;
> -- 
> 2.20.1
> 
> ___
> 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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/hdcp: mst streams type1 capability check (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/hdcp: mst streams type1 capability check (rev2)
URL   : https://patchwork.freedesktop.org/series/86345/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9874_full -> Patchwork_19809_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Possible new issues
---

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

### Piglit changes ###

 Possible regressions 

  * 
spec@glsl-4.20@execution@vs_in@vs-input-double_dmat3-uint_uvec3_array3-position 
(NEW):
- {pig-icl-1065g7}:   NOTRUN -> [CRASH][1] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19809/pig-icl-1065g7/spec@glsl-4.20@execution@vs_in@vs-input-double_dmat3-uint_uvec3_array3-position.html

  * 
spec@glsl-4.20@execution@vs_in@vs-input-ubyte_uvec4-short_ivec4-position-double_dmat3
 (NEW):
- {pig-icl-1065g7}:   NOTRUN -> [INCOMPLETE][2] +3 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19809/pig-icl-1065g7/spec@glsl-4.20@execution@vs_in@vs-input-ubyte_uvec4-short_ivec4-position-double_dmat3.html

  
New tests
-

  New tests have been introduced between CI_DRM_9874_full and 
Patchwork_19809_full:

### New Piglit tests (6) ###

  * 
spec@glsl-4.20@execution@vs_in@vs-input-double_dmat2x3-position-double_dvec3:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * 
spec@glsl-4.20@execution@vs_in@vs-input-double_dmat3-uint_uvec3_array3-position:
- Statuses : 1 crash(s)
- Exec time: [1.02] s

  * spec@glsl-4.20@execution@vs_in@vs-input-float_float-position-double_dvec3:
- Statuses : 1 crash(s)
- Exec time: [1.06] s

  * 
spec@glsl-4.20@execution@vs_in@vs-input-position-int_ivec4_array3-double_dvec2_array2:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * 
spec@glsl-4.20@execution@vs_in@vs-input-ubyte_uvec3-short_int-position-double_dvec4:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * 
spec@glsl-4.20@execution@vs_in@vs-input-ubyte_uvec4-short_ivec4-position-double_dmat3:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@chamelium:
- shard-iclb: NOTRUN -> [SKIP][3] ([fdo#111827])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19809/shard-iclb5/igt@feature_discov...@chamelium.html

  * igt@gem_create@create-massive:
- shard-kbl:  NOTRUN -> [DMESG-WARN][4] ([i915#3002])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19809/shard-kbl2/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_persistence@clone:
- shard-snb:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +6 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19809/shard-snb5/igt@gem_ctx_persiste...@clone.html

  * igt@gem_ctx_sseu@mmap-args:
- shard-kbl:  NOTRUN -> [SKIP][6] ([fdo#109271]) +11 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19809/shard-kbl2/igt@gem_ctx_s...@mmap-args.html

  * igt@gem_eio@in-flight-contexts-10ms:
- shard-tglb: [PASS][7] -> [TIMEOUT][8] ([i915#3063])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9874/shard-tglb7/igt@gem_...@in-flight-contexts-10ms.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19809/shard-tglb1/igt@gem_...@in-flight-contexts-10ms.html

  * igt@gem_exec_fair@basic-deadline:
- shard-skl:  NOTRUN -> [FAIL][9] ([i915#2846])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19809/shard-skl7/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9874/shard-tglb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19809/shard-tglb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar 
issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9874/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19809/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk:  NOTRUN -> [FAIL][14] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19809/shard-glk6/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_params@no-vebox:
- shard-iclb: NOTRUN -> [SKIP][15] ([fdo#109283])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19809/shard-iclb5/igt@gem_exec_par...@no-vebox.html

  * igt@gem_exec_params@secure-no

Re: [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: uAPI clean-ups part 2

[Jason Ekstrand]

On Mon, Mar 22, 2021 at 6:55 AM Jani Nikula  wrote:
>
> On Fri, 19 Mar 2021, Patchwork  wrote:
> > == Series Details ==
> >
> > Series: drm/i915: uAPI clean-ups part 2
> > URL   : https://patchwork.freedesktop.org/series/88196/
> > State : failure
> >
> > == Summary ==
> >
> > Applying: drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE
> > Applying: drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP
> > Applying: drm/i915: Drop the CONTEXT_CLONE API
> > Applying: drm/i915: Implement SINGLE_TIMELINE with a syncobj
> > error: sha1 information is lacking or useless 
> > (drivers/gpu/drm/i915/gem/i915_gem_context.c).
> > error: could not build fake ancestor
> > hint: Use 'git am --show-current-patch=diff' to see the failed patch
> > Patch failed at 0004 drm/i915: Implement SINGLE_TIMELINE with a syncobj
> > 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".
>
> CI runs on top of drm-tip branch. What's this based on?

drm/topic/i915-gem-next

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

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Implement SINGLE_TIMELINE with a syncobj

[Jason Ekstrand]

On Mon, Mar 22, 2021 at 7:28 AM Tvrtko Ursulin
 wrote:
>
>
> On 19/03/2021 22:38, Jason Ekstrand wrote:
> > I'd love to delete the SINGLE_TIMELINE API because it leaks an
> > implementation detail of contexts through to the API and is something
> > that userspace can do itself, trivially.  Unfortunately, it's used by
> > the media driver so we can't do that.  We can, however, do the next-best
> > thing which is to embed a syncobj in the context and do exactly what
> > we'd expect from userspace internally.
> >
> > This has a couple of advantages.  One is that we're no longer leaking a
> > detail of the current execlist scheduler which will be problematic when
> > we try to add GuC scheduling.  Second is that, together with deleting
>
> Narrative needs to be corrected as with the previous patch.
>
> > the CLONE_CONTEXT API, we should now have a 1:1 mapping between
> > intel_context and intel_timeline which should make some of our locking
> > mess a bit easier.
>
> Mess or complexity? Could you expand with some details so it's easier to
> understand? (I am thinking what gets easier, how and why, if this is done.)

Both?  I guess "complexity" is a less abrasive way of stating it.
I've not dug into the actual refactor yet but we should be able to
drop the whole RCU business on intel_timeline that we have right now
just to facilitate sharing like this.  Fewer objects that are shared
deep inside i915 with their own locks and RCUs seems like an advantage
to me.  Especially when we already have nice generic infrastructure
for this.

> >
> > Signed-off-by: Jason Ekstrand 
> > Cc: Maarten Lankhorst 
> > Cc: Matthew Brost 
> > ---
> >   drivers/gpu/drm/i915/gem/i915_gem_context.c   | 47 ---
> >   .../gpu/drm/i915/gem/i915_gem_context_types.h |  8 +++-
> >   .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 15 ++
> >   3 files changed, 32 insertions(+), 38 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index f88bac19333ec..e094f4a1ca4cd 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -67,6 +67,8 @@
> >   #include 
> >   #include 
> >
> > +#include 
> > +
> >   #include "gt/gen6_ppgtt.h"
> >   #include "gt/intel_context.h"
> >   #include "gt/intel_engine_heartbeat.h"
> > @@ -224,10 +226,6 @@ static void intel_context_set_gem(struct intel_context 
> > *ce,
> >   ce->vm = vm;
> >   }
> >
> > - GEM_BUG_ON(ce->timeline);
> > - if (ctx->timeline)
> > - ce->timeline = intel_timeline_get(ctx->timeline);
> > -
> >   if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
> >   intel_engine_has_timeslices(ce->engine))
> >   __set_bit(CONTEXT_USE_SEMAPHORES, &ce->flags);
> > @@ -344,8 +342,8 @@ void i915_gem_context_release(struct kref *ref)
> >   mutex_destroy(&ctx->engines_mutex);
> >   mutex_destroy(&ctx->lut_mutex);
> >
> > - if (ctx->timeline)
> > - intel_timeline_put(ctx->timeline);
> > + if (ctx->syncobj)
> > + drm_syncobj_put(ctx->syncobj);
> >
> >   put_pid(ctx->pid);
> >   mutex_destroy(&ctx->mutex);
> > @@ -790,33 +788,11 @@ static void __assign_ppgtt(struct i915_gem_context 
> > *ctx,
> >   i915_vm_close(vm);
> >   }
> >
> > -static void __set_timeline(struct intel_timeline **dst,
> > -struct intel_timeline *src)
> > -{
> > - struct intel_timeline *old = *dst;
> > -
> > - *dst = src ? intel_timeline_get(src) : NULL;
> > -
> > - if (old)
> > - intel_timeline_put(old);
> > -}
> > -
> > -static void __apply_timeline(struct intel_context *ce, void *timeline)
> > -{
> > - __set_timeline(&ce->timeline, timeline);
> > -}
> > -
> > -static void __assign_timeline(struct i915_gem_context *ctx,
> > -   struct intel_timeline *timeline)
> > -{
> > - __set_timeline(&ctx->timeline, timeline);
> > - context_apply_all(ctx, __apply_timeline, timeline);
> > -}
> > -
> >   static struct i915_gem_context *
> >   i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
> >   {
> >   struct i915_gem_context *ctx;
> > + int ret;
> >
> >   if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&
> >   !HAS_EXECLISTS(i915))
> > @@ -845,16 +821,13 @@ i915_gem_create_context(struct drm_i915_private 
> > *i915, unsigned int flags)
> >   }
> >
> >   if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
>
> If removal works out I would suggest deprecating the flag starting from
> some future platform. Maybe for GT gen greater than 12 you could already
> start rejecting in order to future proof.
>
> > - struct intel_timeline *timeline;
> > -
> > - timeline = intel_timeline_create(&i915->gt);
> > - if (IS_ERR(timeline)) {
> > + ret = drm_syncobj_create(&ctx->syncobj,
> > +

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE

[Jason Ekstrand]

On Mon, Mar 22, 2021 at 7:01 AM Jani Nikula  wrote:
>
> On Sat, 20 Mar 2021, Jason Ekstrand  wrote:
> > This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a.  This API
>
> Small nit, I think it would be useful to reference commits with the
> citation style:
>
> 88be76cdafc7 ("drm/i915: Allow userspace to specify ringsize on construction")

Done.

>
> I use this monster in my .gitconfig:
>
> [alias]
> cite = "!f() { git log -1 '--pretty=format:%H (\"%s\")%n' $1 | sed -e 
> 's/\\([0-f]\\{12\\}\\)[0-f]*/\\1/'; }; f"

Thanks for the tip!

> With that, 'git cite ' will give you the nice reference with
> 12 chars of sha1 regardless of core.abbrev config.
>
>
> BR,
> Jani.
>
> --
> Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [bug report] drm/i915: Computer does not shutdown,

[Ville Syrjälä]

On Mon, Mar 22, 2021 at 04:51:26PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 3/22/21 3:53 PM, Ville Syrjälä wrote:
> > On Mon, Mar 22, 2021 at 11:45:39AM +0100, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 3/14/21 11:30 AM, Mario Hüttel wrote:
> >>> Hello,
> >>>
> >>> It seems, like the mailing list, didn't accept my email. So I'll send
> >>> it again:
> >>>
> >>> I want to report a bug. I have a PC with Intel i7-6700K processor (with
> >>> integrated graphics) and an AsRock Fatal1ty Z170 Gaming K6 mainboard. I
> >>> use the CPU's integrated graphics.
> >>> My system is Archlinux with Kernel v5.11.6.
> >>>
> >>> Using this setup, my PC works normally. However, when I shut it down,
> >>> the power is not cut. Fans keep spinning and LEDs stay on. I couldn't
> >>> detect any other problem when shutting down. Drives etc. stop as
> >>> expected and the video is blank. Even after waiting several hours, the
> >>> system doesn't power down.
> >>>
> >>> Restarts work normally.
> >>>
> >>> I haven't yet found any other people on the internet that have the same
> >>> bug.
> >>>
> >>> I used git bisect to find the commit that causes this behavior on my
> >>> machine.
> >>
> >> Thank you for doing a bisect that is always very helpful.
> >>
> >>> The result is: fe0f1e3bfdfeb53e18f1206aea4f40b9bd1f291c is the
> >>> first bad commit.
> >>
> >> To save others the trouble of having to look up the hasj, that is:
> >>
> >> "drm/i915: Shut down displays gracefully on reboot"
> >>
> >> Which is the same commit as which I've reported is causing issues
> >> with DSI panels not lighting up on reboots on some BYT/CHT devices.
> >>
> >> Since this seems to mostly be intended to fix issues surrounding
> >> DP MST stuff, maybe the graceful shutdown should only be done when
> >> MST is in use?
> > 
> > No. It also fixes Windows, lols.
> 
> Ok, can you at least take a look at my patch which fixes (works-around)
> the issues for DSI panel on BYT/CHT DSI devices:
> 
> https://patchwork.freedesktop.org/patch/422481/
> 
> ?

Never reached my inbox.

> 
> In that case the display stays black after reboot in the BIOS / in apps
> using the EFI fb/console such as the grub menu and when using fastboot
> it also stays black under Linux (I did not test Windows) only after forcing
> a modeset under Linux the DSI LCD panel works again.
> 
> As I mention in the commit msg given the age of the platforms involved
> I think that a simple workaround as I suggest there is best.
> 
> Regards,
> 
> Hans

-- 
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/4] drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE

[Jason Ekstrand]

On Mon, Mar 22, 2021 at 5:52 AM Matthew Auld
 wrote:
>
> On Sat, 20 Mar 2021 at 14:48, Jason Ekstrand  wrote:
> >
> > On Fri, Mar 19, 2021 at 5:39 PM Jason Ekstrand  wrote:
> > >
> > > This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a.  This API
> > > has never been used by any real userspace.
> >
> > After further digging, there is a compute-runtime PR for this.  I
> > still think we should drop it and I've updated the commit message
> > locally with the following rationale:
> >
> > This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a.  This API
> > was originally added for OpenCL but the compute-runtime PR has sat open
> > for a year without action so we can still pull it out if we want.  I
> > argue we should drop it for three reasons:
> >
> >  1. If the compute-runtime PR has sat open for a year, this clearly
> > isn't that important.
> >
> >  2. It's a very leaky API.  Ring size is an implementation detail of the
> > current execlist scheduler and really only makes sense there.  It
> > can't apply to the older ring-buffer scheduler on pre-execlist
> > hardware because that's shared across all contexts and it won't
> > apply to the GuC scheduler that's in the pipeline.
>
> Just a drive-by-comment. I thought the lrc model was shared between
> execlists and the GuC, so in both cases we get something like a ring
> per engine per context which the driver can emit commands into. Why
> doesn't ring size still apply with the GuC scheduler?

Even if they both have a ring in some sense, the number of bytes which
correspond to a single request is going to be different and that
difference isn't visible to userspace so bytes is the wrong unit.

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

Re: [Intel-gfx] [bug report] drm/i915: Computer does not shutdown,

[Hans de Goede]

Hi,

On 3/22/21 3:53 PM, Ville Syrjälä wrote:
> On Mon, Mar 22, 2021 at 11:45:39AM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 3/14/21 11:30 AM, Mario Hüttel wrote:
>>> Hello,
>>>
>>> It seems, like the mailing list, didn't accept my email. So I'll send
>>> it again:
>>>
>>> I want to report a bug. I have a PC with Intel i7-6700K processor (with
>>> integrated graphics) and an AsRock Fatal1ty Z170 Gaming K6 mainboard. I
>>> use the CPU's integrated graphics.
>>> My system is Archlinux with Kernel v5.11.6.
>>>
>>> Using this setup, my PC works normally. However, when I shut it down,
>>> the power is not cut. Fans keep spinning and LEDs stay on. I couldn't
>>> detect any other problem when shutting down. Drives etc. stop as
>>> expected and the video is blank. Even after waiting several hours, the
>>> system doesn't power down.
>>>
>>> Restarts work normally.
>>>
>>> I haven't yet found any other people on the internet that have the same
>>> bug.
>>>
>>> I used git bisect to find the commit that causes this behavior on my
>>> machine.
>>
>> Thank you for doing a bisect that is always very helpful.
>>
>>> The result is: fe0f1e3bfdfeb53e18f1206aea4f40b9bd1f291c is the
>>> first bad commit.
>>
>> To save others the trouble of having to look up the hasj, that is:
>>
>> "drm/i915: Shut down displays gracefully on reboot"
>>
>> Which is the same commit as which I've reported is causing issues
>> with DSI panels not lighting up on reboots on some BYT/CHT devices.
>>
>> Since this seems to mostly be intended to fix issues surrounding
>> DP MST stuff, maybe the graceful shutdown should only be done when
>> MST is in use?
> 
> No. It also fixes Windows, lols.

Ok, can you at least take a look at my patch which fixes (works-around)
the issues for DSI panel on BYT/CHT DSI devices:

https://patchwork.freedesktop.org/patch/422481/

?

In that case the display stays black after reboot in the BIOS / in apps
using the EFI fb/console such as the grub menu and when using fastboot
it also stays black under Linux (I did not test Windows) only after forcing
a modeset under Linux the DSI LCD panel works again.

As I mention in the commit msg given the age of the platforms involved
I think that a simple workaround as I suggest there is best.

Regards,

Hans

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

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enable TPS3/4 on all platforms that support them

[Ville Syrjälä]

On Fri, Mar 19, 2021 at 07:08:40PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Enable TPS3/4 on all platforms that support them
> URL   : https://patchwork.freedesktop.org/series/88186/
> State : success
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_9877 -> Patchwork_19815
> 
> 
> Summary
> ---
> 
>   **SUCCESS**

That's a bit odd considering the link training still fails with this.
Did we convert some erorrs to debugs perhaps, or maybe this never
got flagged as an error?

<7>[8.235008] i915 :00:02.0: [drm:intel_dp_start_link_train [i915]] 
Using LINK_RATE_SET value 03
<7>[8.236203] i915 :00:02.0: [drm:intel_dp_set_signal_levels [i915]] 
Using vswing level 0, pre-emphasis level 0, at DPRX
<7>[8.236341] i915 :00:02.0: 
[drm:intel_dp_program_link_training_pattern [i915]] [ENCODER:307:DDI A/PHY A] 
Using DP training pattern TPS1
<7>[8.237373] i915 :00:02.0: [drm:intel_dp_link_train_phy [i915]] clock 
recovery OK
<7>[8.237460] i915 :00:02.0: 
[drm:intel_dp_program_link_training_pattern [i915]] [ENCODER:307:DDI A/PHY A] 
Using DP training pattern TPS4
<7>[8.239054] i915 :00:02.0: [drm:intel_dp_dump_link_status.isra.4 
[i915]] ln0_1:0x0 ln2_3:0x0 align:0x80 sink:0x0 adj_req0_1:0x0 adj_req2_3:0x0
<7>[8.239135] i915 :00:02.0: [drm:intel_dp_link_train_phy [i915]] Clock 
recovery check failed, cannot continue channel equalization
<7>[8.239218] i915 :00:02.0: [drm:intel_dp_link_train_phy [i915]] 
[CONNECTOR:308:eDP-1] Link Training failed at link rate = 27, lane count = 
2, at DPRX

So CR lock is lost as soon as we switch to TPS4. I really wonder if the sink
actually even implements TPS4, and maybe when we write TPS4 to the DPCD reg
it starts to expect some other pattern? Should be semi-easy to confirm
I guess...

One thing I was pondering is whether we're detecting TPS4 vs. TPS3 differently
that eg. Windows. Based on some trawling it looks to me that for some reason
Windows uses the EDP_DPCD_REV>=0x4 check rather than DPCD_REV>=0x14 on eDP
panels when checking for TPS4 suppport. Unfortunately following that
convention here wouldn't help us:

<7>[6.835706] i915 :00:02.0: [drm:intel_dp_init_connector [i915]] eDP 
DPCD: 04 fb ff
<7>[8.234921] [drm:drm_dp_read_dpcd_caps] AUX A/DDI A/PHY A: Base DPCD: 14 
0a 82 41 00 00 01 c0 02 00 00 00 0f 09 80
<7>[8.234943] [drm:drm_dp_read_dpcd_caps] AUX A/DDI A/PHY A: DPCD: 14 0a 82 
c1 00 00 01 c0 02 00 00 00 0f 09 80

-- 
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/6] drm/i915: Individual request cancellation

[Matthew Auld]

On Thu, 18 Mar 2021 at 17:04, Tvrtko Ursulin
 wrote:
>
> From: Chris Wilson 
>
> Currently, we cancel outstanding requests within a context when the
> context is closed. We may also want to cancel individual requests using
> the same graceful preemption mechanism.
>
> v2 (Tvrtko):
>  * Cancel waiters carefully considering no timeline lock and RCU.
>  * Fixed selftests.
>
> v3 (Tvrtko):
>  * Remove error propagation to waiters for now.
>
> Signed-off-by: Chris Wilson 
> Signed-off-by: Tvrtko Ursulin 
> ---
>  .../gpu/drm/i915/gt/intel_engine_heartbeat.c  |   1 +
>  .../drm/i915/gt/intel_execlists_submission.c  |   9 +-
>  drivers/gpu/drm/i915/i915_request.c   |  52 -
>  drivers/gpu/drm/i915/i915_request.h   |   4 +-
>  drivers/gpu/drm/i915/selftests/i915_request.c | 201 ++
>  5 files changed, 261 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> index 0b062fad1837..e2fb3ae2aaf3 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> @@ -314,6 +314,7 @@ int intel_engine_pulse(struct intel_engine_cs *engine)
> mutex_unlock(&ce->timeline->mutex);
> }
>
> +   intel_engine_flush_scheduler(engine);
> intel_engine_pm_put(engine);
> return err;
>  }
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index 85ff5fe861b4..4c2acb5a6c0a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -421,6 +421,11 @@ static void reset_active(struct i915_request *rq,
> ce->lrc.lrca = lrc_update_regs(ce, engine, head);
>  }
>
> +static bool bad_request(const struct i915_request *rq)
> +{
> +   return rq->fence.error && i915_request_started(rq);
> +}
> +
>  static struct intel_engine_cs *
>  __execlists_schedule_in(struct i915_request *rq)
>  {
> @@ -433,7 +438,7 @@ __execlists_schedule_in(struct i915_request *rq)
>  !intel_engine_has_heartbeat(engine)))
> intel_context_set_banned(ce);
>
> -   if (unlikely(intel_context_is_banned(ce)))
> +   if (unlikely(intel_context_is_banned(ce) || bad_request(rq)))
> reset_active(rq, engine);
>
> if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
> @@ -1112,7 +1117,7 @@ static unsigned long active_preempt_timeout(struct 
> intel_engine_cs *engine,
> return 0;
>
> /* Force a fast reset for terminated contexts (ignoring sysfs!) */
> -   if (unlikely(intel_context_is_banned(rq->context)))
> +   if (unlikely(intel_context_is_banned(rq->context) || bad_request(rq)))
> return 1;
>
> return READ_ONCE(engine->props.preempt_timeout_ms);
> diff --git a/drivers/gpu/drm/i915/i915_request.c 
> b/drivers/gpu/drm/i915/i915_request.c
> index e7b4c4bc41a6..b4511ac05e9a 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -33,7 +33,10 @@
>  #include "gem/i915_gem_context.h"
>  #include "gt/intel_breadcrumbs.h"
>  #include "gt/intel_context.h"
> +#include "gt/intel_engine.h"
> +#include "gt/intel_engine_heartbeat.h"
>  #include "gt/intel_gpu_commands.h"
> +#include "gt/intel_reset.h"
>  #include "gt/intel_ring.h"
>  #include "gt/intel_rps.h"
>
> @@ -429,20 +432,22 @@ void __i915_request_skip(struct i915_request *rq)
> rq->infix = rq->postfix;
>  }
>
> -void i915_request_set_error_once(struct i915_request *rq, int error)
> +bool i915_request_set_error_once(struct i915_request *rq, int error)
>  {
> int old;
>
> GEM_BUG_ON(!IS_ERR_VALUE((long)error));
>
> if (i915_request_signaled(rq))
> -   return;
> +   return false;
>
> old = READ_ONCE(rq->fence.error);
> do {
> if (fatal_error(old))
> -   return;
> +   return false;
> } while (!try_cmpxchg(&rq->fence.error, &old, error));
> +
> +   return true;
>  }
>
>  struct i915_request *i915_request_mark_eio(struct i915_request *rq)
> @@ -609,6 +614,47 @@ void i915_request_unsubmit(struct i915_request *request)
> spin_unlock_irqrestore(&se->lock, flags);
>  }
>
> +static struct intel_engine_cs *active_engine(struct i915_request *rq)
> +{
> +   struct intel_engine_cs *engine, *locked;
> +
> +   locked = READ_ONCE(rq->engine);
> +   spin_lock_irq(&locked->sched.lock);
> +   while (unlikely(locked != (engine = READ_ONCE(rq->engine {
> +   spin_unlock(&locked->sched.lock);
> +   locked = engine;
> +   spin_lock(&locked->sched.lock);
> +   }
> +
> +   engine = NULL;
> +   if (i915_request_is_active(rq) && !__i915_request_is_complete(rq))
> +   engine = locked;
> +
> +   spin_unlock

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Drop the CONTEXT_CLONE API

[Tvrtko Ursulin]

On 22/03/2021 14:57, Daniel Vetter wrote:

On Mon, Mar 22, 2021 at 3:33 PM Tvrtko Ursulin
 wrote:



On 22/03/2021 14:09, Daniel Vetter wrote:

On Mon, Mar 22, 2021 at 11:22:01AM +, Tvrtko Ursulin wrote:


On 19/03/2021 22:38, Jason Ekstrand wrote:

This API allows one context to grab bits out of another context upon
creation.  It can be used as a short-cut for setparam(getparam()) for
things like I915_CONTEXT_PARAM_VM.  However, it's never been used by any
real userspace.  It's used by a few IGT tests and that's it.  Since it
doesn't add any real value (most of the stuff you can CLONE you can copy
in other ways), drop it.


No complaints to remove if it ended up unused outside IGT. Latter is a _big_
problem though, since it is much more that a few IGT tests. So I really
think there really needs to be an evaluation and a plan for that (we don't
want to lose 50% of the coverage over night).


There is one thing that this API allows you to clone which you cannot
clone via getparam/setparam: timelines.  However, timelines are an
implementation detail of i915 and not really something that needs to be


Not really true timelines are i915 implementation detail. They are in fact a
dma-fence context:seqno concept, nothing more that than. I think you are
probably confusing struct intel_timeline with the timeline wording in the
uapi. Former is i915 implementation detail, but context:seqno are truly
userspace timelines.


I think you're both saying the same thing and talking a bit past each
another.

Yes the timeline is just a string of dma_fence, that's correct. Now
usually if you submit batches with execbuf, we have 3 ways to synchronize
concurrent submission: implicit sync, sync_file and drm_syncob. They all
map to different needs in different protocols/render apis.

Now in one additional case the kernel makes sure that batchbuffers are
ordered, and that's when you submit them to the same hw ctx. Because
there's only 1 hw context and you really can't have batchbuffers run on
that single hw context out of order. That's what the timeline object we
talk about here is. But that largely is an internal implementation detail,
which happens to also use most/all the same infrastructure as the
dma_fence uapi pieces above.

Now the internal implementation detail leaking here is that we exposed
this to userspace, without there being any need for this. What Jason
implements with syncobj in the next patch is essentially what userspace
should have been using for cross-engine sync. media userspace doesn't care
about interop with winsys/client apis, so they equally could have used
implicit sync or sync_file here (which I think is the solution now for the
new uapi prepped internally), since they all are about equally powerful
for stringing batchbuffers together.


Are you saying we exposed a single timeline of execution per hw context
via the single timeline flag?!


Nope.


Timelines of execution were always exposed. Any "engine" (ring
previously) in I915_EXEC_RING_MASK was a single timeline of execution.
It is completely the same with engine map engines, which are also
different indices into I915_EXEC_RING_MASK space.

Userspace was aware of these timelines forever as well. Media was
creating multiple contexts to have multiple timelines (so parallelism).
Everyone knew that engine-hopping submissions needs to be either
implicitly or explicitly synchronised, etc.


Yup, I think we're saying the same thing here.


So I really don't see that we have leaked timelines as a concept *now*.
What the patch has exposed to userspace is a new way to sync between
timelines and nothing more.


We've leaked it as something you can now share across hw context.


Okay so we agree on most things but apparently have different 
definitions of what it means to leak internal implementation details.


While at the same time proof that we haven't leaked the internal 
implementation details is that Jason was able to implement the single 
timeline flag with a drm syncobj at the execbuf top level. (Well mostly, 
ignoring the probably inconsequential difference of one vs multiple 
fence contexts.)



Which is possible because of how it's internally implemented (I think
load balancer relies on that), but not really a synchronization


Virtual engine is a single timeline by definition and it is still that 
regardless of the implementation details (execlists or GuC, in both 
cases it is a single hardware context and a single timeline).



primitive we want to export as such to userspace. We have other
interfaces and concepts for that.


Yes, that is the only point to argue IMO. We can say it wasn't needed 
and should have been avoided, but I still maintain we can't really say 
we leaked anything backend specific to userspace via it.


Regards,

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

Re: [Intel-gfx] [PATCH 6/6] drm/i915/display: Simplify GLK display version tests

[Ville Syrjälä]

On Fri, Mar 19, 2021 at 09:42:45PM -0700, Matt Roper wrote:
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 4be848d0d156..eb1121e05c0d 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1433,7 +1433,7 @@ static void bxt_get_cdclk(struct drm_i915_private 
> *dev_priv,
>   break;
>   case BXT_CDCLK_CD2X_DIV_SEL_1_5:
>   drm_WARN(&dev_priv->drm,
> -  IS_GEMINILAKE(dev_priv) || DISPLAY_VER(dev_priv) >= 10,
> +  DISPLAY_VER(dev_priv) >= 10,
>"Unsupported divider\n");
>   div = 3;
>   break;
> @@ -1591,7 +1591,7 @@ static void bxt_set_cdclk(struct drm_i915_private 
> *dev_priv,
>   break;
>   case 3:
>   drm_WARN(&dev_priv->drm,
> -  IS_GEMINILAKE(dev_priv) || DISPLAY_VER(dev_priv) >= 10,
> +  DISPLAY_VER(dev_priv) >= 10,
>"Unsupported divider\n");
>   divider = BXT_CDCLK_CD2X_DIV_SEL_1_5;
>   break;

Looks like you still end up with the wrong thing here for the case 8?
Atm it has a gen>=10 check, after this it should have gen>=11||is_cnl.

The approach I was thinking should work for this would be somehting
along the lines of:
gen>9 -> gen>=10
gen>=10 -> gen>=11||is_cnl
is_cnl||is_glk -> gen10
gen>=11||gen10 -> gen>=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] [bug report] drm/i915: Computer does not shutdown,

[Ville Syrjälä]

On Sun, Mar 14, 2021 at 11:30:12AM +0100, Mario Hüttel wrote:
> Hello,
> 
> It seems, like the mailing list, didn't accept my email. So I'll send
> it again:
> 
> I want to report a bug. I have a PC with Intel i7-6700K processor (with
> integrated graphics) and an AsRock Fatal1ty Z170 Gaming K6 mainboard. I
> use the CPU's integrated graphics.
> My system is Archlinux with Kernel v5.11.6.
> 
> Using this setup, my PC works normally. However, when I shut it down,
> the power is not cut. Fans keep spinning and LEDs stay on. I couldn't
> detect any other problem when shutting down. Drives etc. stop as
> expected and the video is blank. Even after waiting several hours, the
> system doesn't power down.
> 
> Restarts work normally.

As in 'reboot' ?

That's a bit odd then. Hmm. What could be the difference between
shutdown and reboot?

Does the same thing happen with a working kernel if you try to
shut down the machine when all displays are blanked?

Hmm. Wonder if we can get logs from this with either netconsole
or serial or would those be shut down already...

> 
> I haven't yet found any other people on the internet that have the same
> bug.
> 
> I used git bisect to find the commit that causes this behavior on my
> machine. The result is: fe0f1e3bfdfeb53e18f1206aea4f40b9bd1f291c is the
> first bad commit.
> 
> I hope this is the correct mailing list for this issue.
> 
> Let me know if you need more information or someone to test it.
> 
> Thanks
> 
> Mario
> 
> ___
> 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 3/4] drm/i915: Drop the CONTEXT_CLONE API

[Daniel Vetter]

On Mon, Mar 22, 2021 at 3:33 PM Tvrtko Ursulin
 wrote:
>
>
> On 22/03/2021 14:09, Daniel Vetter wrote:
> > On Mon, Mar 22, 2021 at 11:22:01AM +, Tvrtko Ursulin wrote:
> >>
> >> On 19/03/2021 22:38, Jason Ekstrand wrote:
> >>> This API allows one context to grab bits out of another context upon
> >>> creation.  It can be used as a short-cut for setparam(getparam()) for
> >>> things like I915_CONTEXT_PARAM_VM.  However, it's never been used by any
> >>> real userspace.  It's used by a few IGT tests and that's it.  Since it
> >>> doesn't add any real value (most of the stuff you can CLONE you can copy
> >>> in other ways), drop it.
> >>
> >> No complaints to remove if it ended up unused outside IGT. Latter is a 
> >> _big_
> >> problem though, since it is much more that a few IGT tests. So I really
> >> think there really needs to be an evaluation and a plan for that (we don't
> >> want to lose 50% of the coverage over night).
> >>
> >>> There is one thing that this API allows you to clone which you cannot
> >>> clone via getparam/setparam: timelines.  However, timelines are an
> >>> implementation detail of i915 and not really something that needs to be
> >>
> >> Not really true timelines are i915 implementation detail. They are in fact 
> >> a
> >> dma-fence context:seqno concept, nothing more that than. I think you are
> >> probably confusing struct intel_timeline with the timeline wording in the
> >> uapi. Former is i915 implementation detail, but context:seqno are truly
> >> userspace timelines.
> >
> > I think you're both saying the same thing and talking a bit past each
> > another.
> >
> > Yes the timeline is just a string of dma_fence, that's correct. Now
> > usually if you submit batches with execbuf, we have 3 ways to synchronize
> > concurrent submission: implicit sync, sync_file and drm_syncob. They all
> > map to different needs in different protocols/render apis.
> >
> > Now in one additional case the kernel makes sure that batchbuffers are
> > ordered, and that's when you submit them to the same hw ctx. Because
> > there's only 1 hw context and you really can't have batchbuffers run on
> > that single hw context out of order. That's what the timeline object we
> > talk about here is. But that largely is an internal implementation detail,
> > which happens to also use most/all the same infrastructure as the
> > dma_fence uapi pieces above.
> >
> > Now the internal implementation detail leaking here is that we exposed
> > this to userspace, without there being any need for this. What Jason
> > implements with syncobj in the next patch is essentially what userspace
> > should have been using for cross-engine sync. media userspace doesn't care
> > about interop with winsys/client apis, so they equally could have used
> > implicit sync or sync_file here (which I think is the solution now for the
> > new uapi prepped internally), since they all are about equally powerful
> > for stringing batchbuffers together.
>
> Are you saying we exposed a single timeline of execution per hw context
> via the single timeline flag?!

Nope.

> Timelines of execution were always exposed. Any "engine" (ring
> previously) in I915_EXEC_RING_MASK was a single timeline of execution.
> It is completely the same with engine map engines, which are also
> different indices into I915_EXEC_RING_MASK space.
>
> Userspace was aware of these timelines forever as well. Media was
> creating multiple contexts to have multiple timelines (so parallelism).
> Everyone knew that engine-hopping submissions needs to be either
> implicitly or explicitly synchronised, etc.

Yup, I think we're saying the same thing here.

> So I really don't see that we have leaked timelines as a concept *now*.
> What the patch has exposed to userspace is a new way to sync between
> timelines and nothing more.

We've leaked it as something you can now share across hw context.
Which is possible because of how it's internally implemented (I think
load balancer relies on that), but not really a synchronization
primitive we want to export as such to userspace. We have other
interfaces and concepts for that.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [bug report] drm/i915: Computer does not shutdown,

[Ville Syrjälä]

On Mon, Mar 22, 2021 at 11:45:39AM +0100, Hans de Goede wrote:
> Hi,
> 
> On 3/14/21 11:30 AM, Mario Hüttel wrote:
> > Hello,
> > 
> > It seems, like the mailing list, didn't accept my email. So I'll send
> > it again:
> > 
> > I want to report a bug. I have a PC with Intel i7-6700K processor (with
> > integrated graphics) and an AsRock Fatal1ty Z170 Gaming K6 mainboard. I
> > use the CPU's integrated graphics.
> > My system is Archlinux with Kernel v5.11.6.
> > 
> > Using this setup, my PC works normally. However, when I shut it down,
> > the power is not cut. Fans keep spinning and LEDs stay on. I couldn't
> > detect any other problem when shutting down. Drives etc. stop as
> > expected and the video is blank. Even after waiting several hours, the
> > system doesn't power down.
> > 
> > Restarts work normally.
> > 
> > I haven't yet found any other people on the internet that have the same
> > bug.
> > 
> > I used git bisect to find the commit that causes this behavior on my
> > machine.
> 
> Thank you for doing a bisect that is always very helpful.
> 
> > The result is: fe0f1e3bfdfeb53e18f1206aea4f40b9bd1f291c is the
> > first bad commit.
> 
> To save others the trouble of having to look up the hasj, that is:
> 
> "drm/i915: Shut down displays gracefully on reboot"
> 
> Which is the same commit as which I've reported is causing issues
> with DSI panels not lighting up on reboots on some BYT/CHT devices.
> 
> Since this seems to mostly be intended to fix issues surrounding
> DP MST stuff, maybe the graceful shutdown should only be done when
> MST is in use?

No. It also fixes Windows, lols.

-- 
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] drm/i915: Avoid div-by-zero on gen2

[Ville Syrjälä]

On Sun, Mar 21, 2021 at 04:30:32PM +, Chris Wilson wrote:
> Quoting Chris Wilson (2021-03-21 16:28:07)
> > Quoting Ville Syrjala (2021-03-21 16:10:38)
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
> > > b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > index ec28a6cde49b..0b2434e29d00 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > @@ -189,7 +189,7 @@ compute_partial_view(const struct drm_i915_gem_object 
> > > *obj,
> > > struct i915_ggtt_view view;
> > >  
> > > if (i915_gem_object_is_tiled(obj))
> > > -   chunk = roundup(chunk, tile_row_pages(obj));
> > > +   chunk = roundup(chunk, tile_row_pages(obj) ?: 1);
> > 
> > I was thinking the answer would be to align to the next page, and hey
> > presto!
> 
> Wait, the tile row cannot be a single page. Something else is zero that
> should not be.

How come? At least i915_tiling_ok() doesn't enforce any
bigger lower bound.

-- 
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: failure for Default request/fence expiry + watchdog (rev4)

[Patchwork]

== Series Details ==

Series: Default request/fence expiry + watchdog (rev4)
URL   : https://patchwork.freedesktop.org/series/87930/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9880 -> Patchwork_19828


Summary
---

  **FAILURE**

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

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19828/index.html

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@client:
- fi-icl-y:   NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19828/fi-icl-y/igt@i915_selftest@l...@client.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_exec_fence@nb-await@vcs0:
- {fi-rkl-11500t}:NOTRUN -> [FAIL][2] +38 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19828/fi-rkl-11500t/igt@gem_exec_fence@nb-aw...@vcs0.html

  * igt@prime_vgem@basic-read:
- {fi-rkl-11500t}:NOTRUN -> [SKIP][3] +3 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19828/fi-rkl-11500t/igt@prime_v...@basic-read.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-y:   NOTRUN -> [SKIP][4] ([fdo#109315])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19828/fi-tgl-y/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-tgl-y:   NOTRUN -> [SKIP][5] ([fdo#109315] / [i915#2575]) +16 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19828/fi-tgl-y/igt@amdgpu/amd_cs_...@fork-gfx0.html

  * igt@gem_exec_gttfill@basic:
- fi-kbl-8809g:   [PASS][6] -> [TIMEOUT][7] ([i915#3145]) +1 similar 
issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/fi-kbl-8809g/igt@gem_exec_gttf...@basic.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19828/fi-kbl-8809g/igt@gem_exec_gttf...@basic.html

  * igt@gem_exec_suspend@basic-s0:
- fi-kbl-soraka:  [PASS][8] -> [INCOMPLETE][9] ([i915#155])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19828/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_exec_suspend@basic-s3:
- fi-skl-6600u:   [PASS][10] -> [INCOMPLETE][11] ([i915#198])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19828/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_huc_copy@huc-copy:
- fi-glk-dsi: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#2190])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19828/fi-glk-dsi/igt@gem_huc_c...@huc-copy.html
- fi-tgl-y:   NOTRUN -> [SKIP][13] ([i915#2190])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19828/fi-tgl-y/igt@gem_huc_c...@huc-copy.html
- fi-icl-y:   NOTRUN -> [SKIP][14] ([i915#2190])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19828/fi-icl-y/igt@gem_huc_c...@huc-copy.html

  * igt@i915_module_load@reload:
- fi-glk-dsi: NOTRUN -> [DMESG-WARN][15] ([i915#1982] / 
[i915#3143]) +1 similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19828/fi-glk-dsi/igt@i915_module_l...@reload.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-glk-dsi: NOTRUN -> [DMESG-WARN][16] ([i915#3143]) +25 similar 
issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19828/fi-glk-dsi/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_selftest@live@client:
- fi-glk-dsi: NOTRUN -> [DMESG-FAIL][17] ([i915#3047])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19828/fi-glk-dsi/igt@i915_selftest@l...@client.html

  * igt@i915_selftest@live@gt_lrc:
- fi-tgl-y:   NOTRUN -> [DMESG-FAIL][18] ([i915#2373])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19828/fi-tgl-y/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@gt_pm:
- fi-tgl-y:   NOTRUN -> [DMESG-FAIL][19] ([i915#1759])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19828/fi-tgl-y/igt@i915_selftest@live@gt_pm.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-icl-y:  

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Drop the CONTEXT_CLONE API

[Tvrtko Ursulin]

On 22/03/2021 14:09, Daniel Vetter wrote:

On Mon, Mar 22, 2021 at 11:22:01AM +, Tvrtko Ursulin wrote:


On 19/03/2021 22:38, Jason Ekstrand wrote:

This API allows one context to grab bits out of another context upon
creation.  It can be used as a short-cut for setparam(getparam()) for
things like I915_CONTEXT_PARAM_VM.  However, it's never been used by any
real userspace.  It's used by a few IGT tests and that's it.  Since it
doesn't add any real value (most of the stuff you can CLONE you can copy
in other ways), drop it.


No complaints to remove if it ended up unused outside IGT. Latter is a _big_
problem though, since it is much more that a few IGT tests. So I really
think there really needs to be an evaluation and a plan for that (we don't
want to lose 50% of the coverage over night).


There is one thing that this API allows you to clone which you cannot
clone via getparam/setparam: timelines.  However, timelines are an
implementation detail of i915 and not really something that needs to be


Not really true timelines are i915 implementation detail. They are in fact a
dma-fence context:seqno concept, nothing more that than. I think you are
probably confusing struct intel_timeline with the timeline wording in the
uapi. Former is i915 implementation detail, but context:seqno are truly
userspace timelines.


I think you're both saying the same thing and talking a bit past each
another.

Yes the timeline is just a string of dma_fence, that's correct. Now
usually if you submit batches with execbuf, we have 3 ways to synchronize
concurrent submission: implicit sync, sync_file and drm_syncob. They all
map to different needs in different protocols/render apis.

Now in one additional case the kernel makes sure that batchbuffers are
ordered, and that's when you submit them to the same hw ctx. Because
there's only 1 hw context and you really can't have batchbuffers run on
that single hw context out of order. That's what the timeline object we
talk about here is. But that largely is an internal implementation detail,
which happens to also use most/all the same infrastructure as the
dma_fence uapi pieces above.

Now the internal implementation detail leaking here is that we exposed
this to userspace, without there being any need for this. What Jason
implements with syncobj in the next patch is essentially what userspace
should have been using for cross-engine sync. media userspace doesn't care
about interop with winsys/client apis, so they equally could have used
implicit sync or sync_file here (which I think is the solution now for the
new uapi prepped internally), since they all are about equally powerful
for stringing batchbuffers together.


Are you saying we exposed a single timeline of execution per hw context 
via the single timeline flag?!


Timelines of execution were always exposed. Any "engine" (ring 
previously) in I915_EXEC_RING_MASK was a single timeline of execution. 
It is completely the same with engine map engines, which are also 
different indices into I915_EXEC_RING_MASK space.


Userspace was aware of these timelines forever as well. Media was 
creating multiple contexts to have multiple timelines (so parallelism). 
Everyone knew that engine-hopping submissions needs to be either 
implicitly or explicitly synchronised, etc.


So I really don't see that we have leaked timelines as a concept *now*. 
What the patch has exposed to userspace is a new way to sync between 
timelines and nothing more.


Regards,

Tvrtko


So I do think the assessment is accurate, albeit a bit on the terse side.
Maybe we could quote just the entire thing here in the commit message.



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

[Intel-gfx] [PATCH i-g-t] scripts/trace.pl: Remove the tool

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Tool has been broken for a while after changes to tracepoint format an
behaviour. Although I have patches somewhere to mostly fix it, it seems
that it has outlived its usefulness and could be deleted just as well.

Signed-off-by: Tvrtko Ursulin 
---
 scripts/Makefile.am |2 +-
 scripts/trace.pl| 1486 ---
 2 files changed, 1 insertion(+), 1487 deletions(-)
 delete mode 100755 scripts/trace.pl

diff --git a/scripts/Makefile.am b/scripts/Makefile.am
index 641715294936..85d4a5cf4e5c 100644
--- a/scripts/Makefile.am
+++ b/scripts/Makefile.am
@@ -1,2 +1,2 @@
-dist_noinst_SCRIPTS = intel-gfx-trybot who.sh run-tests.sh trace.pl
+dist_noinst_SCRIPTS = intel-gfx-trybot who.sh run-tests.sh
 noinst_PYTHON = throttle.py
diff --git a/scripts/trace.pl b/scripts/trace.pl
deleted file mode 100755
index 77587f24197a..
--- a/scripts/trace.pl
+++ /dev/null
@@ -1,1486 +0,0 @@
-#! /usr/bin/perl
-#
-# Copyright © 2017 Intel Corporation
-#
-# Permission is hereby granted, free of charge, to any person obtaining a
-# copy of this software and associated documentation files (the "Software"),
-# to deal in the Software without restriction, including without limitation
-# the rights to use, copy, modify, merge, publish, distribute, sublicense,
-# and/or sell copies of the Software, and to permit persons to whom the
-# Software is furnished to do so, subject to the following conditions:
-#
-# The above copyright notice and this permission notice (including the next
-# paragraph) shall be included in all copies or substantial portions of the
-# Software.
-#
-# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
-# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
-# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
-# IN THE SOFTWARE.
-#
-
-use strict;
-use warnings;
-use 5.010;
-
-my $gid = 0;
-my (%db, %vdb, %queue, %submit, %notify, %rings, %ctxdb, %ringmap, %reqwait,
-%ctxtimelines);
-my (%cids, %ctxmap);
-my $cid = 0;
-my %queues;
-my @freqs;
-
-use constant VENG => '255:254';
-
-my $max_requests = 1000;
-my $width_us = 32000;
-my $correct_durations = 0;
-my %ignore_ring;
-my %skip_box;
-my $html = 0;
-my $trace = 0;
-my $avg_delay_stats = 0;
-my $gpu_timeline = 0;
-my $colour_contexts = 0;
-
-my @args;
-
-sub arg_help
-{
-   return unless scalar(@_);
-
-   if ($_[0] eq '--help' or $_[0] eq '-h') {
-   shift @_;
-print 

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Drop the CONTEXT_CLONE API

[Daniel Vetter]

On Mon, Mar 22, 2021 at 11:22:01AM +, Tvrtko Ursulin wrote:
> 
> On 19/03/2021 22:38, Jason Ekstrand wrote:
> > This API allows one context to grab bits out of another context upon
> > creation.  It can be used as a short-cut for setparam(getparam()) for
> > things like I915_CONTEXT_PARAM_VM.  However, it's never been used by any
> > real userspace.  It's used by a few IGT tests and that's it.  Since it
> > doesn't add any real value (most of the stuff you can CLONE you can copy
> > in other ways), drop it.
> 
> No complaints to remove if it ended up unused outside IGT. Latter is a _big_
> problem though, since it is much more that a few IGT tests. So I really
> think there really needs to be an evaluation and a plan for that (we don't
> want to lose 50% of the coverage over night).
> 
> > There is one thing that this API allows you to clone which you cannot
> > clone via getparam/setparam: timelines.  However, timelines are an
> > implementation detail of i915 and not really something that needs to be
> 
> Not really true timelines are i915 implementation detail. They are in fact a
> dma-fence context:seqno concept, nothing more that than. I think you are
> probably confusing struct intel_timeline with the timeline wording in the
> uapi. Former is i915 implementation detail, but context:seqno are truly
> userspace timelines.

I think you're both saying the same thing and talking a bit past each
another.

Yes the timeline is just a string of dma_fence, that's correct. Now
usually if you submit batches with execbuf, we have 3 ways to synchronize
concurrent submission: implicit sync, sync_file and drm_syncob. They all
map to different needs in different protocols/render apis.

Now in one additional case the kernel makes sure that batchbuffers are
ordered, and that's when you submit them to the same hw ctx. Because
there's only 1 hw context and you really can't have batchbuffers run on
that single hw context out of order. That's what the timeline object we
talk about here is. But that largely is an internal implementation detail,
which happens to also use most/all the same infrastructure as the
dma_fence uapi pieces above.

Now the internal implementation detail leaking here is that we exposed
this to userspace, without there being any need for this. What Jason
implements with syncobj in the next patch is essentially what userspace
should have been using for cross-engine sync. media userspace doesn't care
about interop with winsys/client apis, so they equally could have used
implicit sync or sync_file here (which I think is the solution now for the
new uapi prepped internally), since they all are about equally powerful
for stringing batchbuffers together.

So I do think the assessment is accurate, albeit a bit on the terse side.
Maybe we could quote just the entire thing here in the commit message.
-Danile

> 
> But again, no objection to removing unused uapi in principle. Narrative has
> to be accurate and test coverage not lost though.
> 
> Regards,
> 
> Tvrtko
> 
> > exposed to userspace.  Also, sharing timelines between contexts isn't
> > obviously useful and supporting it has the potential to complicate i915
> > internally.  It also doesn't add any functionality that the client can't
> > get in other ways.  If a client really wants a shared timeline, they can
> > use a syncobj and set it as an in and out fence on every submit.
> > 
> > Signed-off-by: Jason Ekstrand 
> > Cc: Tvrtko Ursulin 
> > ---
> >   drivers/gpu/drm/i915/gem/i915_gem_context.c | 199 +---
> >   include/uapi/drm/i915_drm.h |  16 +-
> >   2 files changed, 6 insertions(+), 209 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index d28ac79de7573..f88bac19333ec 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -1983,207 +1983,14 @@ static int create_setparam(struct 
> > i915_user_extension __user *ext, void *data)
> > return ctx_setparam(arg->fpriv, arg->ctx, &local.param);
> >   }
> > -static int clone_engines(struct i915_gem_context *dst,
> > -struct i915_gem_context *src)
> > +static int invalid_ext(struct i915_user_extension __user *ext, void *data)
> >   {
> > -   struct i915_gem_engines *clone, *e;
> > -   bool user_engines;
> > -   unsigned long n;
> > -
> > -   e = __context_engines_await(src, &user_engines);
> > -   if (!e)
> > -   return -ENOENT;
> > -
> > -   clone = alloc_engines(e->num_engines);
> > -   if (!clone)
> > -   goto err_unlock;
> > -
> > -   for (n = 0; n < e->num_engines; n++) {
> > -   struct intel_engine_cs *engine;
> > -
> > -   if (!e->engines[n]) {
> > -   clone->engines[n] = NULL;
> > -   continue;
> > -   }
> > -   engine = e->engines[n]->engine;
> > -
> > -   /*
> > -* Virtual engines are singlet

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Default request/fence expiry + watchdog (rev4)

[Patchwork]

== Series Details ==

Series: Default request/fence expiry + watchdog (rev4)
URL   : https://patchwork.freedesktop.org/series/87930/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
0dab5b547041 drm/i915: Individual request cancellation
877af4e8c3a0 drm/i915: Restrict sentinel requests further
fa67080f1163 drm/i915: Handle async cancellation in sentinel assert
461b1ef96a0b drm/i915: Request watchdog infrastructure
c0d164c95655 drm/i915: Fail too long user submissions by default
-:18: WARNING:TYPO_SPELLING: 'becuase' may be misspelled - perhaps 'because'?
#18: 
And becuase of lack of agreement on usefulness and safety of fence error
^^^

total: 0 errors, 1 warnings, 0 checks, 102 lines checked
61c74b67bbd6 drm/i915: Allow configuring default request expiry via modparam


___
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/display: Disable PSR2 on Gen12/12+

[Patchwork]

== Series Details ==

Series: drm/i915/display: Disable PSR2 on Gen12/12+
URL   : https://patchwork.freedesktop.org/series/88264/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9880 -> Patchwork_19827


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19827/index.html

Possible new issues
---

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

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_exec_fence@nb-await@vcs0:
- {fi-rkl-11500t}:NOTRUN -> [FAIL][1] +38 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19827/fi-rkl-11500t/igt@gem_exec_fence@nb-aw...@vcs0.html

  * igt@prime_vgem@basic-read:
- {fi-rkl-11500t}:NOTRUN -> [SKIP][2] +3 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19827/fi-rkl-11500t/igt@prime_v...@basic-read.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-y:   NOTRUN -> [SKIP][3] ([fdo#109315])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19827/fi-tgl-y/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_basic@semaphore:
- fi-icl-y:   NOTRUN -> [SKIP][4] ([fdo#109315]) +17 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19827/fi-icl-y/igt@amdgpu/amd_ba...@semaphore.html

  * igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-tgl-y:   NOTRUN -> [SKIP][5] ([fdo#109315] / [i915#2575]) +16 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19827/fi-tgl-y/igt@amdgpu/amd_cs_...@fork-gfx0.html

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-y:   NOTRUN -> [DMESG-WARN][6] ([i915#2411] / [i915#402])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19827/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_flink_basic@bad-flink:
- fi-tgl-y:   NOTRUN -> [DMESG-WARN][7] ([i915#402]) +1 similar 
issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19827/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html

  * igt@gem_huc_copy@huc-copy:
- fi-glk-dsi: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#2190])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19827/fi-glk-dsi/igt@gem_huc_c...@huc-copy.html
- fi-tgl-y:   NOTRUN -> [SKIP][9] ([i915#2190])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19827/fi-tgl-y/igt@gem_huc_c...@huc-copy.html
- fi-icl-y:   NOTRUN -> [SKIP][10] ([i915#2190])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19827/fi-icl-y/igt@gem_huc_c...@huc-copy.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-glk-dsi: NOTRUN -> [DMESG-WARN][11] ([i915#3143]) +26 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19827/fi-glk-dsi/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: NOTRUN -> [DMESG-WARN][12] ([i915#1982] / [i915#3143])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19827/fi-glk-dsi/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@client:
- fi-glk-dsi: NOTRUN -> [DMESG-FAIL][13] ([i915#3047])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19827/fi-glk-dsi/igt@i915_selftest@l...@client.html

  * igt@i915_selftest@live@gt_lrc:
- fi-tgl-y:   NOTRUN -> [DMESG-FAIL][14] ([i915#2373])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19827/fi-tgl-y/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@gt_pm:
- fi-tgl-y:   NOTRUN -> [DMESG-FAIL][15] ([i915#1759])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19827/fi-tgl-y/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@requests:
- fi-icl-u2:  [PASS][16] -> [INCOMPLETE][17] ([i915#2759] / 
[i915#2782])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/fi-icl-u2/igt@i915_selftest@l...@requests.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19827/fi-icl-u2/igt@i915_selftest@l...@requests.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [PASS][18] -> [FAIL][19] ([i915#1372])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19827/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
- fi-icl-y:   NOTRUN -> [SKIP][20] ([fdo#109284] / [fdo#111827]) +8 
similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19827/fi-icl-y/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_chamelium@hdmi-hpd-fas

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Default request/fence expiry + watchdog (rev3)

[Daniel Vetter]

On Mon, Mar 22, 2021 at 01:37:58PM +, Tvrtko Ursulin wrote:
> 
> On 19/03/2021 01:17, Patchwork wrote:
> 
> Okay with 20s default expiration the hangcheck tests on Tigerlake pass and
> we are left with these failures:
> 
> >   IGT changes
> > 
> > 
> > Possible regressions
> > 
> >   *
> > 
> > igt@gem_ctx_ringsize@idle@bcs0:
> > 
> >   o shard-skl: PASS
> > 
> > 
> > -> INCOMPLETE
> > 
> > 
> 
> Too many runnable requests on a slow Skylake SKU with command parsing
> active. Too many to finish withing the 20s default expiration that is. This
> is actually the same root cause as the below tests tries to explicitly
> demonstrate:
> 
> >   *
> > 
> > {igt@gem_watchdog@far-fence@bcs0} (NEW):
> > 
> >   o shard-glk: NOTRUN -> FAIL
> > 
> > 
> >   *
> > 
> > {igt@gem_watchdog@far-fence@vcs0} (NEW):
> > 
> >   o shard-apl: NOTRUN -> FAIL
> > 
> > 
> > +2 similar issues
> >   *
> > 
> > {igt@gem_watchdog@far-fence@vecs0} (NEW):
> > 
> >   o shard-kbl: NOTRUN -> FAIL
> > 
> > 
> > +2 similar issues
> 
> The vulnerability default expiration adds compared to the current state is
> applicable to heaviliy loaded systems where GPU is shared between multiple
> clients.
> 
> Otherwise series seems to work. Failing tests can be blacklisted going
> forward. Ack to merge and merge itself, after review, I leave to maintainers
> since personally I am not supportive of this mechanism.

Yeah I think we have some leftovers to look at after this has landed on
igt side, since with 20s we're rather long on the timeout side, and some
of the tests need to be resurrected with the preempt-ctx execbuf mode I
think.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/display: Not to try to re-enable PSR after being raised an irq aux error

[Souza, Jose]

On Wed, 2021-03-17 at 23:26 +0200, Gwan-gyeong Mun wrote:
> If an irq aux error happens, it does not need to wait for PSR "IDLE state"
> for re-enabling PSR. And it should not try to re-enable PSR.
> 
> The PSR interrupt handler sets irq_aux_error when the PSR error happens.
> And it schedules the inter_psr_work(). but the current intel_psr_work() can
> be scheduled by another PSR internal routine.
> Therefore, we should not re-enable PSR after handing irq_aux_error in
> intel_psr_work().
> 
> v2: Address Jose's review comment.
>  - Handling the closing function in the check routine of irq_aux_error.
>  - Add a detailed commit message for the scenario.

Reviewed-by: José Roberto de Souza 

> 
> Cc: José Roberto de Souza 
> Signed-off-by: Gwan-gyeong Mun 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index cd434285e3b7..aba15846e78e 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1683,8 +1683,10 @@ static void intel_psr_work(struct work_struct *work)
>   if (!intel_dp->psr.enabled)
>   goto unlock;
>  
> 
> 
> 
> - if (READ_ONCE(intel_dp->psr.irq_aux_error))
> + if (READ_ONCE(intel_dp->psr.irq_aux_error)) {
>   intel_psr_handle_irq(intel_dp);
> + goto unlock;
> + }
>  
> 
> 
> 
>   /*
>    * We have to make sure PSR is ready for re-enable

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

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Default request/fence expiry + watchdog (rev3)

[Tvrtko Ursulin]

On 19/03/2021 01:17, Patchwork wrote:

Okay with 20s default expiration the hangcheck tests on Tigerlake pass 
and we are left with these failures:



  IGT changes


Possible regressions

  *

igt@gem_ctx_ringsize@idle@bcs0:

  o shard-skl: PASS


-> INCOMPLETE




Too many runnable requests on a slow Skylake SKU with command parsing 
active. Too many to finish withing the 20s default expiration that is. 
This is actually the same root cause as the below tests tries to 
explicitly demonstrate:



  *

{igt@gem_watchdog@far-fence@bcs0} (NEW):

  o shard-glk: NOTRUN -> FAIL


  *

{igt@gem_watchdog@far-fence@vcs0} (NEW):

  o shard-apl: NOTRUN -> FAIL


+2 similar issues
  *

{igt@gem_watchdog@far-fence@vecs0} (NEW):

  o shard-kbl: NOTRUN -> FAIL


+2 similar issues


The vulnerability default expiration adds compared to the current state 
is applicable to heaviliy loaded systems where GPU is shared between 
multiple clients.


Otherwise series seems to work. Failing tests can be blacklisted going 
forward. Ack to merge and merge itself, after review, I leave to 
maintainers since personally I am not supportive of this mechanism.


Regards,

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

[Intel-gfx] [PATCH v3 4/6] drm/i915: Request watchdog infrastructure

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Prepares the plumbing for setting request/fence expiration time. All code
is put in place but is never activeted due yet missing ability to actually
configure the timer.

Outline of the basic operation:

A timer is started when request is ready for execution. If the request
completes (retires) before the timer fires, timer is cancelled and nothing
further happens.

If the timer fires request is added to a lockless list and worker queued.
Purpose of this is twofold: a) It allows request cancellation from a more
friendly context and b) coalesces multiple expirations into a single event
of consuming the list.

Worker locklessly consumes the list of expired requests and cancels them
all using previous added i915_request_cancel().

Associated timeout value is stored in rq->context.watchdog.timeout_us.

v2:
 * Log expiration.

v3:
 * Include more information about user timeline in the log message.

Signed-off-by: Tvrtko Ursulin 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/gt/intel_context_types.h |  4 ++
 .../drm/i915/gt/intel_execlists_submission.h  |  2 +
 drivers/gpu/drm/i915/gt/intel_gt.c|  3 +
 drivers/gpu/drm/i915/gt/intel_gt.h|  2 +
 drivers/gpu/drm/i915/gt/intel_gt_requests.c   | 28 ++
 drivers/gpu/drm/i915/gt/intel_gt_types.h  |  7 +++
 drivers/gpu/drm/i915/i915_request.c   | 56 +++
 drivers/gpu/drm/i915/i915_request.h   |  8 +++
 8 files changed, 110 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 0ea18c9e2aca..65a5730a4f5b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -99,6 +99,10 @@ struct intel_context {
 #define CONTEXT_FORCE_SINGLE_SUBMISSION7
 #define CONTEXT_NOPREEMPT  8
 
+   struct {
+   u64 timeout_us;
+   } watchdog;
+
u32 *lrc_reg_state;
union {
struct {
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.h 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
index f7bd3fccfee8..4ca9b475e252 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
@@ -6,6 +6,7 @@
 #ifndef __INTEL_EXECLISTS_SUBMISSION_H__
 #define __INTEL_EXECLISTS_SUBMISSION_H__
 
+#include 
 #include 
 
 struct drm_printer;
@@ -13,6 +14,7 @@ struct drm_printer;
 struct i915_request;
 struct intel_context;
 struct intel_engine_cs;
+struct intel_gt;
 
 enum {
INTEL_CONTEXT_SCHEDULE_IN = 0,
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index ca76f93bc03d..8d77dcbad059 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -31,6 +31,9 @@ void intel_gt_init_early(struct intel_gt *gt, struct 
drm_i915_private *i915)
INIT_LIST_HEAD(>->closed_vma);
spin_lock_init(>->closed_lock);
 
+   init_llist_head(>->watchdog.list);
+   INIT_WORK(>->watchdog.work, intel_gt_watchdog_work);
+
intel_gt_init_buffer_pool(gt);
intel_gt_init_reset(gt);
intel_gt_init_requests(gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h
index a17bd8b3195f..7ec395cace69 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -78,4 +78,6 @@ static inline bool intel_gt_is_wedged(const struct intel_gt 
*gt)
 void intel_gt_info_print(const struct intel_gt_info *info,
 struct drm_printer *p);
 
+void intel_gt_watchdog_work(struct work_struct *work);
+
 #endif /* __INTEL_GT_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c 
b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
index 36ec97f79174..fbfd19b2e5f2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -8,6 +8,7 @@
 #include "i915_drv.h" /* for_each_engine() */
 #include "i915_request.h"
 #include "intel_engine_heartbeat.h"
+#include "intel_execlists_submission.h"
 #include "intel_gt.h"
 #include "intel_gt_pm.h"
 #include "intel_gt_requests.h"
@@ -242,4 +243,31 @@ void intel_gt_fini_requests(struct intel_gt *gt)
 {
/* Wait until the work is marked as finished before unloading! */
cancel_delayed_work_sync(>->requests.retire_work);
+
+   flush_work(>->watchdog.work);
+}
+
+void intel_gt_watchdog_work(struct work_struct *work)
+{
+   struct intel_gt *gt =
+   container_of(work, typeof(*gt), watchdog.work);
+   struct i915_request *rq, *rn;
+   struct llist_node *first;
+
+   first = llist_del_all(>->watchdog.list);
+   if (!first)
+   return;
+
+   llist_for_each_entry_safe(rq, rn, first, watchdog.link) {
+   if (!i915_request_completed(rq)) {
+   struct dma_fence *f = &rq->fence;
+
+   pr_notice("Fence expiration ti

Re: [Intel-gfx] drm/i915/ilk-glk: Fix link training on links with LTTPRs

[Santiago Zarate]

Tested-By: Santiago Zarate 

Tested with kernel built in obs, see
https://apibugzilla.suse.com/show_bug.cgi?id=1183294#c19 for more
details

Regards, 

Santiago

On Tue, 2021-03-16 at 18:54 +0200, Imre Deak wrote:
> The spec requires to use at least 3.2ms for the AUX timeout period if
> there are LT-tunable PHY Repeaters on the link (2.11.2). An upcoming
> spec update makes this more specific, by requiring a 3.2ms minimum
> timeout period for the LTTPR detection reading the 0xF-0xF0007
> range (3.6.5.1).
> 
> Accordingly disable LTTPR detection until GLK, where the maximum
> timeout
> we can set is only 1.6ms.
> 
> Link training in the non-transparent mode is known to fail at least on
> some SKL systems with a WD19 dock on the link, which exposes an LTTPR
> (see the References below). While this could have different reasons
> besides the too short AUX timeout used, not detecting LTTPRs (and so
> not
> using the non-transparent LT mode) fixes link training on these
> systems.
> 
> While at it add a code comment about the platform specific maximum
> timeout values.
> 
> Reported-by: Takashi Iwai 
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/3166
> Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode
> link training")
> Cc:  # v5.11
> Cc: Takashi Iwai 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_aux.c   | 7 +++
>  drivers/gpu/drm/i915/display/intel_dp_link_training.c | 8 
>  2 files changed, 15 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> index eaebf123310a..b581e8acce07 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> @@ -133,6 +133,7 @@ static u32 g4x_get_aux_send_ctl(struct intel_dp
> *intel_dp,
> else
> precharge = 5;
>  
> +   /* Max timeout value on ILK-BDW: 1.6ms */
> if (IS_BROADWELL(dev_priv))
> timeout = DP_AUX_CH_CTL_TIME_OUT_600us;
> else
> @@ -159,6 +160,12 @@ static u32 skl_get_aux_send_ctl(struct intel_dp
> *intel_dp,
> enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
> u32 ret;
>  
> +   /*
> +    * Max timeout values:
> +    * SKL-GLK: 1.6ms
> +    * CNL: 3.2ms
> +    * ICL+: 4ms
> +    */
> ret = DP_AUX_CH_CTL_SEND_BUSY |
>   DP_AUX_CH_CTL_DONE |
>   DP_AUX_CH_CTL_INTERRUPT |
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index 19ba7c7cbaab..de6d70a29b47 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -123,10 +123,18 @@ intel_dp_set_lttpr_transparent_mode(struct
> intel_dp *intel_dp, bool enable)
>   */
>  int intel_dp_lttpr_init(struct intel_dp *intel_dp)
>  {
> +   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> int lttpr_count;
> bool ret;
> int i;
>  
> +   /*
> +    * Detecting LTTPRs must be avoided on platforms with an AUX
> timeout
> +    * period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1).
> +    */
> +   if (INTEL_GEN(i915) < 10)
> +   return 0;
> +
> if (intel_dp_is_edp(intel_dp))
> return 0;
>  


___
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/display: Disable PSR2 on ADLS

[Patchwork]

== Series Details ==

Series: drm/i915/display: Disable PSR2 on ADLS
URL   : https://patchwork.freedesktop.org/series/88261/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9880 -> Patchwork_19826


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19826/index.html

Possible new issues
---

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

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_exec_fence@nb-await@vcs0:
- {fi-rkl-11500t}:NOTRUN -> [FAIL][1] +38 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19826/fi-rkl-11500t/igt@gem_exec_fence@nb-aw...@vcs0.html

  * igt@prime_vgem@basic-read:
- {fi-rkl-11500t}:NOTRUN -> [SKIP][2] +3 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19826/fi-rkl-11500t/igt@prime_v...@basic-read.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-tgl-y:   NOTRUN -> [SKIP][3] ([fdo#109315])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19826/fi-tgl-y/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_basic@semaphore:
- fi-icl-y:   NOTRUN -> [SKIP][4] ([fdo#109315]) +17 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19826/fi-icl-y/igt@amdgpu/amd_ba...@semaphore.html

  * igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-tgl-y:   NOTRUN -> [SKIP][5] ([fdo#109315] / [i915#2575]) +16 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19826/fi-tgl-y/igt@amdgpu/amd_cs_...@fork-gfx0.html

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][6] ([fdo#109271]) +17 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19826/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@gem_exec_gttfill@basic:
- fi-kbl-8809g:   [PASS][7] -> [TIMEOUT][8] ([i915#3145]) +1 similar 
issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/fi-kbl-8809g/igt@gem_exec_gttf...@basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19826/fi-kbl-8809g/igt@gem_exec_gttf...@basic.html

  * igt@gem_huc_copy@huc-copy:
- fi-glk-dsi: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#2190])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19826/fi-glk-dsi/igt@gem_huc_c...@huc-copy.html
- fi-tgl-y:   NOTRUN -> [SKIP][10] ([i915#2190])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19826/fi-tgl-y/igt@gem_huc_c...@huc-copy.html
- fi-icl-y:   NOTRUN -> [SKIP][11] ([i915#2190])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19826/fi-icl-y/igt@gem_huc_c...@huc-copy.html

  * igt@gem_mmap_gtt@basic:
- fi-tgl-y:   NOTRUN -> [DMESG-WARN][12] ([i915#402]) +2 similar 
issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19826/fi-tgl-y/igt@gem_mmap_...@basic.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-glk-dsi: NOTRUN -> [DMESG-WARN][13] ([i915#3143]) +26 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19826/fi-glk-dsi/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: NOTRUN -> [DMESG-WARN][14] ([i915#1982] / [i915#3143])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19826/fi-glk-dsi/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@client:
- fi-glk-dsi: NOTRUN -> [DMESG-FAIL][15] ([i915#3047])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19826/fi-glk-dsi/igt@i915_selftest@l...@client.html

  * igt@i915_selftest@live@gt_lrc:
- fi-tgl-y:   NOTRUN -> [DMESG-FAIL][16] ([i915#2373])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19826/fi-tgl-y/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@gt_pm:
- fi-tgl-y:   NOTRUN -> [DMESG-FAIL][17] ([i915#1759])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19826/fi-tgl-y/igt@i915_selftest@live@gt_pm.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-icl-y:   NOTRUN -> [SKIP][18] ([fdo#109284] / [fdo#111827]) +8 
similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19826/fi-icl-y/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-glk-dsi: NOTRUN -> [SKIP][19] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19826/fi-glk-dsi/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_chamelium@vga-edid-read:
- fi-tgl-y:   NOTRUN -> [SKI

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Disable PSR2 on ADLS

[Patchwork]

== Series Details ==

Series: drm/i915/display: Disable PSR2 on ADLS
URL   : https://patchwork.freedesktop.org/series/88261/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
a24808990721 drm/i915/display: Disable PSR2 on ADLS
-:7: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#7: 
to disable PSR2 by default in driver,  starting with gfx-driver-ci-master-7517.

total: 0 errors, 1 warnings, 0 checks, 8 lines checked


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

[Intel-gfx] ✓ Fi.CI.BAT: success for display: Fix typo issue

[Patchwork]

== Series Details ==

Series: display: Fix typo issue
URL   : https://patchwork.freedesktop.org/series/88257/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9880 -> Patchwork_19825


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19825/index.html

Possible new issues
---

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

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_exec_fence@nb-await@vcs0:
- {fi-rkl-11500t}:NOTRUN -> [FAIL][1] +37 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19825/fi-rkl-11500t/igt@gem_exec_fence@nb-aw...@vcs0.html

  * igt@prime_vgem@basic-read:
- {fi-rkl-11500t}:NOTRUN -> [SKIP][2] +3 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19825/fi-rkl-11500t/igt@prime_v...@basic-read.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@semaphore:
- fi-icl-y:   NOTRUN -> [SKIP][3] ([fdo#109315]) +17 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19825/fi-icl-y/igt@amdgpu/amd_ba...@semaphore.html

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][4] ([fdo#109271]) +17 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19825/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@gem_exec_gttfill@basic:
- fi-kbl-8809g:   [PASS][5] -> [TIMEOUT][6] ([i915#3145]) +1 similar 
issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/fi-kbl-8809g/igt@gem_exec_gttf...@basic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19825/fi-kbl-8809g/igt@gem_exec_gttf...@basic.html

  * igt@gem_exec_suspend@basic-s0:
- fi-kbl-soraka:  [PASS][7] -> [INCOMPLETE][8] ([i915#155])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19825/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_huc_copy@huc-copy:
- fi-glk-dsi: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#2190])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19825/fi-glk-dsi/igt@gem_huc_c...@huc-copy.html
- fi-icl-y:   NOTRUN -> [SKIP][10] ([i915#2190])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19825/fi-icl-y/igt@gem_huc_c...@huc-copy.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-glk-dsi: NOTRUN -> [DMESG-WARN][11] ([i915#3143]) +26 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19825/fi-glk-dsi/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: NOTRUN -> [DMESG-WARN][12] ([i915#1982] / [i915#3143])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19825/fi-glk-dsi/igt@i915_pm_...@module-reload.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-icl-y:   NOTRUN -> [SKIP][13] ([fdo#109284] / [fdo#111827]) +8 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19825/fi-icl-y/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-glk-dsi: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19825/fi-glk-dsi/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-icl-y:   NOTRUN -> [SKIP][15] ([fdo#109285])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19825/fi-icl-y/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-glk-dsi: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#533])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19825/fi-glk-dsi/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-icl-y:   NOTRUN -> [SKIP][17] ([fdo#109278])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19825/fi-icl-y/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_psr@primary_mmap_gtt:
- fi-icl-y:   NOTRUN -> [SKIP][18] ([fdo#110189]) +3 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19825/fi-icl-y/igt@kms_psr@primary_mmap_gtt.html

  * igt@kms_psr@primary_page_flip:
- fi-glk-dsi: NOTRUN -> [SKIP][19] ([fdo#109271]) +27 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19825/fi-glk-dsi/igt@kms_psr@primary_page_flip.html

  
 Possible fixes 

  * igt@gem_linear_blits@basic:
- fi-kbl-880

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Implement SINGLE_TIMELINE with a syncobj

[Tvrtko Ursulin]

On 19/03/2021 22:38, Jason Ekstrand wrote:

I'd love to delete the SINGLE_TIMELINE API because it leaks an
implementation detail of contexts through to the API and is something
that userspace can do itself, trivially.  Unfortunately, it's used by
the media driver so we can't do that.  We can, however, do the next-best
thing which is to embed a syncobj in the context and do exactly what
we'd expect from userspace internally.

This has a couple of advantages.  One is that we're no longer leaking a
detail of the current execlist scheduler which will be problematic when
we try to add GuC scheduling.  Second is that, together with deleting


Narrative needs to be corrected as with the previous patch.


the CLONE_CONTEXT API, we should now have a 1:1 mapping between
intel_context and intel_timeline which should make some of our locking
mess a bit easier.


Mess or complexity? Could you expand with some details so it's easier to 
understand? (I am thinking what gets easier, how and why, if this is done.)




Signed-off-by: Jason Ekstrand 
Cc: Maarten Lankhorst 
Cc: Matthew Brost 
---
  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 47 ---
  .../gpu/drm/i915/gem/i915_gem_context_types.h |  8 +++-
  .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 15 ++
  3 files changed, 32 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index f88bac19333ec..e094f4a1ca4cd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -67,6 +67,8 @@
  #include 
  #include 
  
+#include 

+
  #include "gt/gen6_ppgtt.h"
  #include "gt/intel_context.h"
  #include "gt/intel_engine_heartbeat.h"
@@ -224,10 +226,6 @@ static void intel_context_set_gem(struct intel_context *ce,
ce->vm = vm;
}
  
-	GEM_BUG_ON(ce->timeline);

-   if (ctx->timeline)
-   ce->timeline = intel_timeline_get(ctx->timeline);
-
if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
intel_engine_has_timeslices(ce->engine))
__set_bit(CONTEXT_USE_SEMAPHORES, &ce->flags);
@@ -344,8 +342,8 @@ void i915_gem_context_release(struct kref *ref)
mutex_destroy(&ctx->engines_mutex);
mutex_destroy(&ctx->lut_mutex);
  
-	if (ctx->timeline)

-   intel_timeline_put(ctx->timeline);
+   if (ctx->syncobj)
+   drm_syncobj_put(ctx->syncobj);
  
  	put_pid(ctx->pid);

mutex_destroy(&ctx->mutex);
@@ -790,33 +788,11 @@ static void __assign_ppgtt(struct i915_gem_context *ctx,
i915_vm_close(vm);
  }
  
-static void __set_timeline(struct intel_timeline **dst,

-  struct intel_timeline *src)
-{
-   struct intel_timeline *old = *dst;
-
-   *dst = src ? intel_timeline_get(src) : NULL;
-
-   if (old)
-   intel_timeline_put(old);
-}
-
-static void __apply_timeline(struct intel_context *ce, void *timeline)
-{
-   __set_timeline(&ce->timeline, timeline);
-}
-
-static void __assign_timeline(struct i915_gem_context *ctx,
- struct intel_timeline *timeline)
-{
-   __set_timeline(&ctx->timeline, timeline);
-   context_apply_all(ctx, __apply_timeline, timeline);
-}
-
  static struct i915_gem_context *
  i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
  {
struct i915_gem_context *ctx;
+   int ret;
  
  	if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&

!HAS_EXECLISTS(i915))
@@ -845,16 +821,13 @@ i915_gem_create_context(struct drm_i915_private *i915, 
unsigned int flags)
}
  
  	if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {


If removal works out I would suggest deprecating the flag starting from 
some future platform. Maybe for GT gen greater than 12 you could already 
start rejecting in order to future proof.



-   struct intel_timeline *timeline;
-
-   timeline = intel_timeline_create(&i915->gt);
-   if (IS_ERR(timeline)) {
+   ret = drm_syncobj_create(&ctx->syncobj,
+DRM_SYNCOBJ_CREATE_SIGNALED,
+NULL);
+   if (ret) {
context_close(ctx);
-   return ERR_CAST(timeline);
+   return ERR_PTR(ret);
}
-
-   __assign_timeline(ctx, timeline);
-   intel_timeline_put(timeline);
}
  
  	trace_i915_context_create(ctx);

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 676592e27e7d2..8a5fdd163b79d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -83,7 +83,13 @@ struct i915_gem_context {
struct i915_gem_engines __rcu *engines;
struct mutex engines_mutex; /* 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for display: Fix typo issue

[Patchwork]

== Series Details ==

Series: display: Fix typo issue
URL   : https://patchwork.freedesktop.org/series/88257/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
c0f358be8b75 display: Fix typo issue
-:19: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a 
separate line
#19: FILE: drivers/gpu/drm/i915/display/vlv_dsi.c:850:
+* recommendation, port should be enabled before plane & pipe */

total: 0 errors, 1 warnings, 0 checks, 8 lines checked


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

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE

[Jani Nikula]

On Sat, 20 Mar 2021, Jason Ekstrand  wrote:
> This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a.  This API

Small nit, I think it would be useful to reference commits with the
citation style:

88be76cdafc7 ("drm/i915: Allow userspace to specify ringsize on construction")

I use this monster in my .gitconfig:

[alias]
cite = "!f() { git log -1 '--pretty=format:%H (\"%s\")%n' $1 | sed -e 
's/\\([0-f]\\{12\\}\\)[0-f]*/\\1/'; }; f"

With that, 'git cite ' will give you the nice reference with
12 chars of sha1 regardless of core.abbrev config.


BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center
___
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/gt: A typo fix

[Patchwork]

== Series Details ==

Series: drm/i915/gt: A typo fix
URL   : https://patchwork.freedesktop.org/series/88256/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9880 -> Patchwork_19824


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19824/index.html

Possible new issues
---

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

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_exec_fence@nb-await@vcs0:
- {fi-rkl-11500t}:NOTRUN -> [FAIL][1] +38 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19824/fi-rkl-11500t/igt@gem_exec_fence@nb-aw...@vcs0.html

  * igt@prime_vgem@basic-read:
- {fi-rkl-11500t}:NOTRUN -> [SKIP][2] +3 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19824/fi-rkl-11500t/igt@prime_v...@basic-read.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0:
- fi-kbl-soraka:  [PASS][3] -> [INCOMPLETE][4] ([i915#155])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19824/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_tiled_fence_blits@basic:
- fi-kbl-8809g:   [PASS][5] -> [TIMEOUT][6] ([i915#3145])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/fi-kbl-8809g/igt@gem_tiled_fence_bl...@basic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19824/fi-kbl-8809g/igt@gem_tiled_fence_bl...@basic.html

  
 Possible fixes 

  * igt@gem_linear_blits@basic:
- fi-kbl-8809g:   [TIMEOUT][7] ([i915#2502] / [i915#3145]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/fi-kbl-8809g/igt@gem_linear_bl...@basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19824/fi-kbl-8809g/igt@gem_linear_bl...@basic.html

  * igt@i915_selftest@live@execlists:
- fi-cfl-8109u:   [DMESG-WARN][9] -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19824/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@late_gt_pm:
- fi-cfl-8109u:   [DMESG-WARN][11] ([i915#203]) -> [PASS][12] +2 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/fi-cfl-8109u/igt@i915_selftest@live@late_gt_pm.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19824/fi-cfl-8109u/igt@i915_selftest@live@late_gt_pm.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- {fi-tgl-dsi}:   [DMESG-WARN][13] ([i915#402]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9880/fi-tgl-dsi/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19824/fi-tgl-dsi/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html

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

  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
  [i915#203]: https://gitlab.freedesktop.org/drm/intel/issues/203
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2502]: https://gitlab.freedesktop.org/drm/intel/issues/2502
  [i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
  [i915#3145]: https://gitlab.freedesktop.org/drm/intel/issues/3145
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Participating hosts (42 -> 40)
--

  Additional (1): fi-rkl-11500t 
  Missing(3): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9880 -> Patchwork_19824

  CI-20190529: 20190529
  CI_DRM_9880: ec7a4e63b83999b055ba61da41bdd0ce656485d4 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6040: 69b578b6ab0a36750f0d23c223a3487fc88fb6a7 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19824: bf6c84b00ab0daea8b07b6de313204329b0db265 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

bf6c84b00ab0 drm/i915/gt: A typo fix

== Logs ==

For more details see: 
ht

Re: [Intel-gfx] [PATCH] drm/i915/audio: set HDA link parameters in driver

[Kai Vehmanen]

Hi,

On Fri, 12 Feb 2021, Kai Vehmanen wrote:

> Update logic to program AUD_FREQ_CNTRL register based on new guidance.
> Earlier this register was configured by BIOS and driver discovered the
> value at init. This is no longer recommended and instead driver should
> set the values based on the hardware revision.

any chance to get this merged? This has a reviewed-by already and all
tests pass:

https://patchwork.freedesktop.org/series/87040/

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