[Intel-gfx] [PATCH i-g-t v4] lib/i915/perf: Fix non-card0 processing

[Janusz Krzysztofik]

IGT i915/perf library functions now always operate on sysfs perf
attributes of card0 device node, no matter which DRM device fd a user
passes.  The intention was to always switch to primary device node if
a user passes a render device node fd, but that breaks handling of
non-card0 devices.

If a user passed a render device node fd, find a primary device node of
the same device and use it instead of forcibly using the primary device
with minor number 0 when opening the device sysfs area.

v2: Don't assume primary minor matches render minor with masked type.
v3: Reset sysfs dir fd if no match, consequently spell out error paths,
add a comment on convertion of renderD* to cardX (Lionel).
v4: Limit primary lookup to minors <64 (Chris)

Signed-off-by: Janusz Krzysztofik 
Reviewed-by: Lionel Landwerlin  # v3
Cc: Chris Wilson 
---
 lib/i915/perf.c | 35 ---
 1 file changed, 32 insertions(+), 3 deletions(-)

diff --git a/lib/i915/perf.c b/lib/i915/perf.c
index 56d5c0b3a..5644a3469 100644
--- a/lib/i915/perf.c
+++ b/lib/i915/perf.c
@@ -372,14 +372,43 @@ open_master_sysfs_dir(int drm_fd)
 {
char path[128];
struct stat st;
+   int sysfs;
 
if (fstat(drm_fd, &st) || !S_ISCHR(st.st_mode))
 return -1;
 
-snprintf(path, sizeof(path), "/sys/dev/char/%d:0",
- major(st.st_rdev));
+   snprintf(path, sizeof(path), "/sys/dev/char/%d:%d", major(st.st_rdev), 
minor(st.st_rdev));
+   sysfs = open(path, O_DIRECTORY);
+   if (sysfs < 0)
+   return sysfs;
 
-   return open(path, O_DIRECTORY);
+   if (minor(st.st_rdev) >= 128) {
+   /* If we were given a renderD* drm_fd, find it's associated 
cardX node. */
+   char device[100], cmp[100];
+   int device_len, cmp_len, i;
+
+   device_len = readlinkat(sysfs, "device", device, 
sizeof(device));
+   close(sysfs);
+   if (device_len < 0)
+   return device_len;
+
+   for (i = 0; i < 64; i++) {
+
+   snprintf(path, sizeof(path), "/sys/dev/char/%d:%d", 
major(st.st_rdev), i);
+   sysfs = open(path, O_DIRECTORY);
+   if (sysfs < 0)
+   continue;
+
+   cmp_len = readlinkat(sysfs, "device", cmp, sizeof(cmp));
+   if (cmp_len == device_len && !memcmp(cmp, device, 
cmp_len))
+   break;
+
+   close(sysfs);
+   sysfs = -1;
+   }
+   }
+
+   return sysfs;
 }
 
 struct intel_perf *
-- 
2.25.1

___
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/display: Disable PSR2 sel fetch in TGL pre-production

[Patchwork]

== Series Details ==

Series: drm/i915/display: Disable PSR2 sel fetch in TGL pre-production
URL   : https://patchwork.freedesktop.org/series/89825/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10050_full -> Patchwork_20074_full


Summary
---

  **SUCCESS**

  No regressions found.

  

New tests
-

  New tests have been introduced between CI_DRM_10050_full and 
Patchwork_20074_full:

### New Piglit tests (1) ###

  * spec@glsl-1.30@execution@tex-miplevel-selection texture(bias) 2d:
- Statuses : 1 fail(s)
- Exec time: [6.92] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@engines-mixed-process:
- shard-snb:  NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) +4 
similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20074/shard-snb2/igt@gem_ctx_persiste...@engines-mixed-process.html

  * igt@gem_ctx_ringsize@idle@bcs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][2] ([i915#3316])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20074/shard-skl6/igt@gem_ctx_ringsize@i...@bcs0.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][3] -> [TIMEOUT][4] ([i915#2369] / [i915#3063])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-tglb7/igt@gem_...@unwedge-stress.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20074/shard-tglb7/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-glk:  [PASS][5] -> [FAIL][6] ([i915#2842])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-glk5/igt@gem_exec_fair@basic-none-...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20074/shard-glk8/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][7] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20074/shard-iclb2/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-kbl:  [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-kbl1/igt@gem_exec_fair@basic-n...@vecs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20074/shard-kbl7/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace@bcs0:
- shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842]) +2 similar 
issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-tglb7/igt@gem_exec_fair@basic-p...@bcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20074/shard-tglb7/igt@gem_exec_fair@basic-p...@bcs0.html

  * igt@gem_exec_reloc@basic-wide-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][12] ([i915#2389])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20074/shard-iclb4/igt@gem_exec_reloc@basic-wide-act...@vcs1.html

  * igt@gem_exec_whisper@basic-forked:
- shard-glk:  [PASS][13] -> [DMESG-WARN][14] ([i915#118] / 
[i915#95])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-glk3/igt@gem_exec_whis...@basic-forked.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20074/shard-glk6/igt@gem_exec_whis...@basic-forked.html

  * igt@gem_mmap_gtt@cpuset-big-copy-xy:
- shard-iclb: [PASS][15] -> [FAIL][16] ([i915#307])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-iclb2/igt@gem_mmap_...@cpuset-big-copy-xy.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20074/shard-iclb7/igt@gem_mmap_...@cpuset-big-copy-xy.html

  * igt@gem_mmap_gtt@cpuset-medium-copy:
- shard-glk:  [PASS][17] -> [FAIL][18] ([i915#307])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-glk6/igt@gem_mmap_...@cpuset-medium-copy.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20074/shard-glk8/igt@gem_mmap_...@cpuset-medium-copy.html

  * igt@gem_pread@exhaustion:
- shard-skl:  NOTRUN -> [WARN][19] ([i915#2658])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20074/shard-skl8/igt@gem_pr...@exhaustion.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-iclb: NOTRUN -> [WARN][20] ([i915#2658])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20074/shard-iclb1/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_render_copy@yf-tiled-to-vebox-linear:
- shard-iclb: NOTRUN -> [SKIP][21] ([i915#768])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20074/shard-iclb1/igt@gem_render_c...@yf-tiled-to-vebox-linear.html

  * igt@gem_userptr_blits@access-control:
- shard-iclb: NOTRUN -> [SKIP][22] ([i915#3297])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20074/shard-iclb1/igt@gem_userptr_bl...@access-con

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove redundant DIRTYFB frontbuffer flushes

[Patchwork]

== Series Details ==

Series: drm/i915: Remove redundant DIRTYFB frontbuffer flushes
URL   : https://patchwork.freedesktop.org/series/89824/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10050_full -> Patchwork_20073_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@legacy-engines-mixed:
- shard-snb:  NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) +4 
similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20073/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-mixed.html

  * igt@gem_ctx_ringsize@idle@bcs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][2] ([i915#3316])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20073/shard-skl8/igt@gem_ctx_ringsize@i...@bcs0.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-glk:  [PASS][3] -> [FAIL][4] ([i915#2842]) +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-glk5/igt@gem_exec_fair@basic-none-...@rcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20073/shard-glk2/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-pace@bcs0:
- shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842]) +2 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-tglb7/igt@gem_exec_fair@basic-p...@bcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20073/shard-tglb5/igt@gem_exec_fair@basic-p...@bcs0.html

  * igt@gem_exec_whisper@basic-forked:
- shard-glk:  [PASS][7] -> [DMESG-WARN][8] ([i915#118] / [i915#95])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-glk3/igt@gem_exec_whis...@basic-forked.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20073/shard-glk3/igt@gem_exec_whis...@basic-forked.html

  * igt@gem_mmap_gtt@big-copy:
- shard-skl:  [PASS][9] -> [FAIL][10] ([i915#307])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-skl6/igt@gem_mmap_...@big-copy.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20073/shard-skl7/igt@gem_mmap_...@big-copy.html

  * igt@gem_mmap_gtt@big-copy-xy:
- shard-glk:  [PASS][11] -> [FAIL][12] ([i915#307])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-glk9/igt@gem_mmap_...@big-copy-xy.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20073/shard-glk5/igt@gem_mmap_...@big-copy-xy.html

  * igt@gem_mmap_offset@clear:
- shard-iclb: [PASS][13] -> [FAIL][14] ([i915#3160])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-iclb7/igt@gem_mmap_off...@clear.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20073/shard-iclb7/igt@gem_mmap_off...@clear.html

  * igt@gem_pread@exhaustion:
- shard-skl:  NOTRUN -> [WARN][15] ([i915#2658])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20073/shard-skl6/igt@gem_pr...@exhaustion.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-iclb: NOTRUN -> [WARN][16] ([i915#2658])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20073/shard-iclb4/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_render_copy@yf-tiled-to-vebox-linear:
- shard-iclb: NOTRUN -> [SKIP][17] ([i915#768])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20073/shard-iclb4/igt@gem_render_c...@yf-tiled-to-vebox-linear.html

  * igt@gem_userptr_blits@access-control:
- shard-iclb: NOTRUN -> [SKIP][18] ([i915#3297])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20073/shard-iclb4/igt@gem_userptr_bl...@access-control.html

  * igt@gem_userptr_blits@set-cache-level:
- shard-iclb: NOTRUN -> [FAIL][19] ([i915#3324])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20073/shard-iclb4/igt@gem_userptr_bl...@set-cache-level.html

  * igt@gem_userptr_blits@vma-merge:
- shard-snb:  NOTRUN -> [FAIL][20] ([i915#2724])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20073/shard-snb2/igt@gem_userptr_bl...@vma-merge.html
- shard-apl:  NOTRUN -> [FAIL][21] ([i915#3318])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20073/shard-apl7/igt@gem_userptr_bl...@vma-merge.html

  * igt@gem_vm_create@destroy-race:
- shard-tglb: [PASS][22] -> [TIMEOUT][23] ([i915#2795])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-tglb3/igt@gem_vm_cre...@destroy-race.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20073/shard-tglb7/igt@gem_vm_cre...@destroy-race.html

  * igt@gen7_exec_parse@basic-offset:
- shard-apl:  NOTRUN -> [SKIP][24] ([fdo#109271]) +145 similar 
issues
   [24]: 
https://intel-gfx-ci.01.org/tree/drm

Re: [Intel-gfx] [PATCH 02/11] drm/i915/xelpd: add XE_LPD display characteristics

[Souza, Jose]

On Wed, 2021-04-14 at 18:51 +0300, Imre Deak wrote:
> From: Matt Roper 
> 
> Let's start preparing for upcoming platforms that will use an XE_LPD
> design.
> 
> v2:
>  - Use the now-preferred "XE_LPD" term to refer to this design
>  - Utilize DISPLAY_VER() rather than a feature flag
>  - Drop unused mbus_size field (Lucas)

Reviewed-by: José Roberto de Souza 

> 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/i915/i915_pci.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 44e7b94db63dc..40b58a6dc3193 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -939,6 +939,16 @@ static const struct intel_device_info adl_s_info = {
>   .dma_mask_size = 46,
>  };
>  
> +#define XE_LPD_FEATURES \
> + .display.ver = 13,  \
> + .display.has_psr_hw_tracking = 0,   \
> + .abox_mask = GENMASK(1, 0), \
> + .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | BIT(PIPE_D), \
> + .cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) |  \
> + BIT(TRANSCODER_C) | BIT(TRANSCODER_D),  \
> + .ddb_size = 4096,   \
> + .num_supported_dbuf_slices = 4
> +
>  #undef GEN
>  #undef PLATFORM
>  

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

Re: [Intel-gfx] [PATCH 04/11] drm/i915/adl_p: ADL_P device info enabling

[Souza, Jose]

On Wed, 2021-04-14 at 18:52 +0300, Imre Deak wrote:
> From: Clinton Taylor 
> 
> Add ADL-P to the device_info table and support MACROS.

Reviewed-by: José Roberto de Souza 

> 
> Bspec: 49185, 55372, 55373
> Cc: Matt Atwood 
> Cc: Matt Roper 
> Signed-off-by: Clinton Taylor 
> Signed-off-by: Matt Roper 
> ---
>  arch/x86/kernel/early-quirks.c   |  1 +
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/i915_pci.c  | 12 
>  drivers/gpu/drm/i915/intel_device_info.c |  1 +
>  drivers/gpu/drm/i915/intel_device_info.h |  1 +
>  5 files changed, 16 insertions(+)
> 
> diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
> index 6edd1e2ee8afa..b553ffe9b9851 100644
> --- a/arch/x86/kernel/early-quirks.c
> +++ b/arch/x86/kernel/early-quirks.c
> @@ -552,6 +552,7 @@ static const struct pci_device_id intel_early_ids[] 
> __initconst = {
>   INTEL_TGL_12_IDS(&gen11_early_ops),
>   INTEL_RKL_IDS(&gen11_early_ops),
>   INTEL_ADLS_IDS(&gen11_early_ops),
> + INTEL_ADLP_IDS(&gen11_early_ops),
>  };
>  
>  struct resource intel_graphics_stolen_res __ro_after_init = 
> DEFINE_RES_MEM(0, 0);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e20294e9227a4..e5513e19beb5c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1392,6 +1392,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>  #define IS_ROCKETLAKE(dev_priv)  IS_PLATFORM(dev_priv, INTEL_ROCKETLAKE)
>  #define IS_DG1(dev_priv)IS_PLATFORM(dev_priv, INTEL_DG1)
>  #define IS_ALDERLAKE_S(dev_priv) IS_PLATFORM(dev_priv, INTEL_ALDERLAKE_S)
> +#define IS_ALDERLAKE_P(dev_priv) IS_PLATFORM(dev_priv, INTEL_ALDERLAKE_P)
>  #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
>   (INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00)
>  #define IS_BDW_ULT(dev_priv) \
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 40b58a6dc3193..2384198e41f85 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -949,6 +949,17 @@ static const struct intel_device_info adl_s_info = {
>   .ddb_size = 4096,   \
>   .num_supported_dbuf_slices = 4
>  
> +static const struct intel_device_info adl_p_info = {
> + GEN12_FEATURES,
> + XE_LPD_FEATURES,
> + PLATFORM(INTEL_ALDERLAKE_P),
> + .require_force_probe = 1,
> + .platform_engine_mask =
> + BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2),
> + .ppgtt_size = 48,
> + .dma_mask_size = 39,
> +};
> +
>  #undef GEN
>  #undef PLATFORM
>  
> @@ -1026,6 +1037,7 @@ static const struct pci_device_id pciidlist[] = {
>   INTEL_TGL_12_IDS(&tgl_info),
>   INTEL_RKL_IDS(&rkl_info),
>   INTEL_ADLS_IDS(&adl_s_info),
> + INTEL_ADLP_IDS(&adl_p_info),
>   {0, 0, 0}
>  };
>  MODULE_DEVICE_TABLE(pci, pciidlist);
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
> b/drivers/gpu/drm/i915/intel_device_info.c
> index 6a351a7094174..3b975ce1ff591 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -67,6 +67,7 @@ static const char * const platform_names[] = {
>   PLATFORM_NAME(ROCKETLAKE),
>   PLATFORM_NAME(DG1),
>   PLATFORM_NAME(ALDERLAKE_S),
> + PLATFORM_NAME(ALDERLAKE_P),
>  };
>  #undef PLATFORM_NAME
>  
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
> b/drivers/gpu/drm/i915/intel_device_info.h
> index 8ab4fa6c7fdd7..edf68244be2bc 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -87,6 +87,7 @@ enum intel_platform {
>   INTEL_ROCKETLAKE,
>   INTEL_DG1,
>   INTEL_ALDERLAKE_S,
> + INTEL_ALDERLAKE_P,
>   INTEL_MAX_PLATFORMS
>  };
>  

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/fbc: Don't nuke manually around flips

[Patchwork]

== Series Details ==

Series: drm/i915/fbc: Don't nuke manually around flips
URL   : https://patchwork.freedesktop.org/series/89823/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10050_full -> Patchwork_20072_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip_tiling@flip-to-y-tiled@edp-1-pipe-a:
- shard-iclb: [PASS][1] -> [FAIL][2] +2 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-iclb8/igt@kms_flip_tiling@flip-to-y-ti...@edp-1-pipe-a.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20072/shard-iclb4/igt@kms_flip_tiling@flip-to-y-ti...@edp-1-pipe-a.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-skl:  [PASS][3] -> [INCOMPLETE][4] ([i915#198])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-skl9/igt@gem_ctx_isolation@preservation...@rcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20072/shard-skl5/igt@gem_ctx_isolation@preservation...@rcs0.html

  * igt@gem_ctx_persistence@legacy-engines-mixed:
- shard-snb:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +4 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20072/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-mixed.html

  * igt@gem_ctx_ringsize@idle@bcs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][6] ([i915#3316])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20072/shard-skl4/igt@gem_ctx_ringsize@i...@bcs0.html

  * igt@gem_exec_create@forked:
- shard-glk:  [PASS][7] -> [DMESG-WARN][8] ([i915#118] / [i915#95])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-glk6/igt@gem_exec_cre...@forked.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20072/shard-glk3/igt@gem_exec_cre...@forked.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-iclb4/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20072/shard-iclb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-kbl:  [PASS][11] -> [FAIL][12] ([i915#2842]) +2 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-kbl1/igt@gem_exec_fair@basic-n...@vecs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20072/shard-kbl7/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace@bcs0:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) +2 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-tglb7/igt@gem_exec_fair@basic-p...@bcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20072/shard-tglb2/igt@gem_exec_fair@basic-p...@bcs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-glk:  [PASS][15] -> [FAIL][16] ([i915#2842]) +1 similar 
issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-glk4/igt@gem_exec_fair@basic-p...@vcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20072/shard-glk5/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][17] ([i915#2842]) +1 similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20072/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_mmap_gtt@big-copy-xy:
- shard-glk:  [PASS][18] -> [FAIL][19] ([i915#307])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-glk9/igt@gem_mmap_...@big-copy-xy.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20072/shard-glk1/igt@gem_mmap_...@big-copy-xy.html

  * igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-apl:  [PASS][20] -> [FAIL][21] ([i915#644])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-apl2/igt@gem_pp...@flink-and-close-vma-leak.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20072/shard-apl8/igt@gem_pp...@flink-and-close-vma-leak.html

  * igt@gem_pread@exhaustion:
- shard-skl:  NOTRUN -> [WARN][22] ([i915#2658])
   [22]: 
https://

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Disable PSR2 sel fetch in TGL pre-production

[Patchwork]

== Series Details ==

Series: drm/i915/display: Disable PSR2 sel fetch in TGL pre-production
URL   : https://patchwork.freedesktop.org/series/89825/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10050 -> Patchwork_20074


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_prime@amd-to-i915:
- fi-tgl-y:   NOTRUN -> [SKIP][1] ([fdo#109315] / [i915#2575])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20074/fi-tgl-y/igt@amdgpu/amd_pr...@amd-to-i915.html

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

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

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- fi-bsw-kefka:   [INCOMPLETE][5] ([i915#2782]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/fi-bsw-kefka/igt@i915_selftest@l...@hangcheck.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20074/fi-bsw-kefka/igt@i915_selftest@l...@hangcheck.html

  
 Warnings 

  * igt@runner@aborted:
- fi-bsw-kefka:   [FAIL][7] ([i915#1436]) -> [FAIL][8] ([i915#1436] / 
[i915#2722])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/fi-bsw-kefka/igt@run...@aborted.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20074/fi-bsw-kefka/igt@run...@aborted.html

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

  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
  [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [k.org#205379]: https://bugzilla.kernel.org/show_bug.cgi?id=205379


Participating hosts (44 -> 40)
--

  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_10050 -> Patchwork_20074

  CI-20190529: 20190529
  CI_DRM_10050: ae46d9d790a148ab7b293cad67c770c0221e2c83 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6079: c77c1e9d716481aa44d713e8c91873aa679547ac @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_20074: be0e87e55654b11b8cadcaf986371c43defcbd54 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

be0e87e55654 drm/i915/display: Disable PSR2 sel fetch in TGL pre-production

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20074/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: Remove redundant DIRTYFB frontbuffer flushes

[Patchwork]

== Series Details ==

Series: drm/i915: Remove redundant DIRTYFB frontbuffer flushes
URL   : https://patchwork.freedesktop.org/series/89824/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10050 -> Patchwork_20073


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-bsw-kefka:   NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20073/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_prime@amd-to-i915:
- fi-tgl-y:   NOTRUN -> [SKIP][2] ([fdo#109315] / [i915#2575])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20073/fi-tgl-y/igt@amdgpu/amd_pr...@amd-to-i915.html

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-soraka:  [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/fi-kbl-soraka/igt@i915_pm_...@module-reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20073/fi-kbl-soraka/igt@i915_pm_...@module-reload.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- fi-bsw-kefka:   [INCOMPLETE][5] ([i915#2782]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/fi-bsw-kefka/igt@i915_selftest@l...@hangcheck.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20073/fi-bsw-kefka/igt@i915_selftest@l...@hangcheck.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#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#1222]: https://gitlab.freedesktop.org/drm/intel/issues/1222
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
  [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782


Participating hosts (44 -> 40)
--

  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_10050 -> Patchwork_20073

  CI-20190529: 20190529
  CI_DRM_10050: ae46d9d790a148ab7b293cad67c770c0221e2c83 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6079: c77c1e9d716481aa44d713e8c91873aa679547ac @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_20073: f0e01aeaa14cf0073c007d760a0836982794c825 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

f0e01aeaa14c drm/i915: Remove redundant DIRTYFB frontbuffer flushes

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Nuke display error state

[Patchwork]

== Series Details ==

Series: drm/i915: Nuke display error state
URL   : https://patchwork.freedesktop.org/series/89822/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10050_full -> Patchwork_20071_full


Summary
---

  **WARNING**

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

  

Possible new issues
---

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

### IGT changes ###

 Warnings 

  * igt@gem_exec_reloc@basic-wide-active@vecs0:
- shard-kbl:  [FAIL][1] ([i915#2389]) -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-kbl2/igt@gem_exec_reloc@basic-wide-act...@vecs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20071/shard-kbl6/igt@gem_exec_reloc@basic-wide-act...@vecs0.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@legacy-engines-mixed:
- shard-snb:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +4 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20071/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-mixed.html

  * igt@gem_ctx_ringsize@idle@bcs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][4] ([i915#3316])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20071/shard-skl10/igt@gem_ctx_ringsize@i...@bcs0.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][5] -> [TIMEOUT][6] ([i915#2369] / [i915#3063])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-tglb7/igt@gem_...@unwedge-stress.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20071/shard-tglb2/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][7] -> [FAIL][8] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-iclb4/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20071/shard-iclb4/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-glk:  [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-glk5/igt@gem_exec_fair@basic-none-...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20071/shard-glk9/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-pace@bcs0:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) +2 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-tglb7/igt@gem_exec_fair@basic-p...@bcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20071/shard-tglb2/igt@gem_exec_fair@basic-p...@bcs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][13] ([i915#2842]) +1 similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20071/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-kbl:  [PASS][14] -> [FAIL][15] ([i915#2842]) +1 similar 
issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-kbl1/igt@gem_exec_fair@basic-throt...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20071/shard-kbl4/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_mmap_gtt@big-copy:
- shard-skl:  [PASS][16] -> [FAIL][17] ([i915#307])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/shard-skl6/igt@gem_mmap_...@big-copy.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20071/shard-skl2/igt@gem_mmap_...@big-copy.html

  * igt@gem_pread@exhaustion:
- shard-skl:  NOTRUN -> [WARN][18] ([i915#2658])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20071/shard-skl4/igt@gem_pr...@exhaustion.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-snb:  NOTRUN -> [WARN][19] ([i915#2658])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20071/shard-snb6/igt@gem_pwr...@basic-exhaustion.html
- shard-iclb: NOTRUN -> [WARN][20] ([i915#2658])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20071/shard-iclb2/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_render_copy@yf-tiled-to-vebox-linear:
- shard-iclb: NOTRUN -> [SKIP][21] ([i915#768])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20071/shard-iclb2/igt@gem_render_c...@yf-tiled-to-vebox-linear.html

  * igt@gem_userptr_blits@access-control:
- shard-i

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/fbc: Don't nuke manually around flips

[Patchwork]

== Series Details ==

Series: drm/i915/fbc: Don't nuke manually around flips
URL   : https://patchwork.freedesktop.org/series/89823/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10050 -> Patchwork_20072


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-bsw-kefka:   NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20072/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html

  * igt@i915_module_load@reload:
- fi-tgl-y:   [PASS][2] -> [DMESG-WARN][3] ([i915#1982] / 
[k.org#205379])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/fi-tgl-y/igt@i915_module_l...@reload.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20072/fi-tgl-y/igt@i915_module_l...@reload.html

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [PASS][4] -> [SKIP][5] ([fdo#109271])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/fi-kbl-guc/igt@i915_pm_...@module-reload.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20072/fi-kbl-guc/igt@i915_pm_...@module-reload.html

  * igt@runner@aborted:
- fi-kbl-r:   NOTRUN -> [FAIL][6] ([i915#1569] / [i915#192] / 
[i915#193] / [i915#194] / [i915#3363])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20072/fi-kbl-r/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- fi-bsw-kefka:   [INCOMPLETE][7] ([i915#2782]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/fi-bsw-kefka/igt@i915_selftest@l...@hangcheck.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20072/fi-bsw-kefka/igt@i915_selftest@l...@hangcheck.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
  [i915#1569]: https://gitlab.freedesktop.org/drm/intel/issues/1569
  [i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
  [i915#192]: https://gitlab.freedesktop.org/drm/intel/issues/192
  [i915#193]: https://gitlab.freedesktop.org/drm/intel/issues/193
  [i915#194]: https://gitlab.freedesktop.org/drm/intel/issues/194
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
  [i915#3180]: https://gitlab.freedesktop.org/drm/intel/issues/3180
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [k.org#205379]: https://bugzilla.kernel.org/show_bug.cgi?id=205379


Participating hosts (44 -> 40)
--

  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_10050 -> Patchwork_20072

  CI-20190529: 20190529
  CI_DRM_10050: ae46d9d790a148ab7b293cad67c770c0221e2c83 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6079: c77c1e9d716481aa44d713e8c91873aa679547ac @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_20072: dd1d012765cd0fb5a63d67d7e73507526de496f9 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

dd1d012765cd drm/i915/fbc: Don't nuke manually around flips

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915/display: Disable PSR2 sel fetch in TGL pre-production

[José Roberto de Souza]

The implementation of two workarounds are missing causing failures
in CI with pre-production HW.

Cc: Gwan-gyeong Mun 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index e3c30dcadcd1..406ba9a712a8 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -720,6 +720,13 @@ static bool intel_psr2_sel_fetch_config_valid(struct 
intel_dp *intel_dp,
}
}
 
+   /* Wa_14010254185 Wa_14010103792 */
+   if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B1)) {
+   drm_dbg_kms(&dev_priv->drm,
+   "PSR2 sel fetch not enabled, missing the 
implementation of WAs\n");
+   return false;
+   }
+
return crtc_state->enable_psr2_sel_fetch = true;
 }
 
-- 
2.31.1

___
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/fbc: Don't nuke manually around flips

[Patchwork]

== Series Details ==

Series: drm/i915/fbc: Don't nuke manually around flips
URL   : https://patchwork.freedesktop.org/series/89823/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
dd1d012765cd drm/i915/fbc: Don't nuke manually around flips
-:82: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)

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


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

[Intel-gfx] [PATCH] drm/i915: Remove redundant DIRTYFB frontbuffer flushes

[Ville Syrjala]

From: Ville Syrjälä 

The frontbuffer tracking code is supposed to handle plane
updates via ORIGIN_FLIP. Right now we're also doing internal
ORIGIN_DIRTYFB flushed as well. Can't see the point so get rid
of them.

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

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index fcd8123ede8e..1fe85a6ea90a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1732,8 +1732,6 @@ intel_find_initial_plane_obj(struct intel_crtc 
*intel_crtc,
intel_plane_copy_uapi_to_hw_state(intel_state, intel_state,
  intel_crtc);
 
-   intel_frontbuffer_flush(to_intel_frontbuffer(fb), ORIGIN_DIRTYFB);
-
atomic_or(to_intel_plane(primary)->frontbuffer_bit,
  &to_intel_frontbuffer(fb)->bits);
 }
@@ -10647,7 +10645,6 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
return ret;
 
i915_gem_object_wait_priority(obj, 0, &attr);
-   i915_gem_object_flush_frontbuffer(obj, ORIGIN_DIRTYFB);
 
if (!new_plane_state->uapi.fence) { /* implicit fencing */
struct dma_fence *fence;
-- 
2.26.3

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

[Intel-gfx] [PATCH] drm/i915/fbc: Don't nuke manually around flips

[Ville Syrjala]

From: Ville Syrjälä 

Apparently we have discovered another way to hit the dreaded
top of screen FBC corruption on GLK. Previously we thought it
was limited to some combination of FBC nuke+disable+plane update
during the same frame, for which we have the extra vblank wait
as a workaround. But looks like it can somehow be hit even
without the FBC disable.

Skipping the extra manual nuke immediately after page flips seems
to cure this. The manual nuke shouldn't be needed anyway since the
flip itself will already cause a nuke. I suppose this means it might
still be possible to hit this if you mix page flips and frontbuffer
rendering in clever ways, but at least it's a bit less likely now.
---
 drivers/gpu/drm/i915/display/intel_fbc.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index b2f3ac846f5b..3251403b521f 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -233,7 +233,8 @@ static void intel_fbc_recompress(struct drm_i915_private 
*dev_priv)
 
 static void ilk_fbc_activate(struct drm_i915_private *dev_priv)
 {
-   struct intel_fbc_reg_params *params = &dev_priv->fbc.params;
+   struct intel_fbc *fbc = &dev_priv->fbc;
+   struct intel_fbc_reg_params *params = &fbc->params;
u32 dpfc_ctl;
int threshold = dev_priv->fbc.threshold;
 
@@ -276,7 +277,8 @@ static void ilk_fbc_activate(struct drm_i915_private 
*dev_priv)
/* enable it... */
intel_de_write(dev_priv, ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN);
 
-   intel_fbc_recompress(dev_priv);
+   if (!fbc->active)
+   intel_fbc_recompress(dev_priv);
 }
 
 static void ilk_fbc_deactivate(struct drm_i915_private *dev_priv)
@@ -298,7 +300,8 @@ static bool ilk_fbc_is_active(struct drm_i915_private 
*dev_priv)
 
 static void gen7_fbc_activate(struct drm_i915_private *dev_priv)
 {
-   struct intel_fbc_reg_params *params = &dev_priv->fbc.params;
+   struct intel_fbc *fbc = &dev_priv->fbc;
+   struct intel_fbc_reg_params *params = &fbc->params;
u32 dpfc_ctl;
int threshold = dev_priv->fbc.threshold;
 
@@ -350,7 +353,8 @@ static void gen7_fbc_activate(struct drm_i915_private 
*dev_priv)
 
intel_de_write(dev_priv, ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN);
 
-   intel_fbc_recompress(dev_priv);
+   if (!fbc->active)
+   intel_fbc_recompress(dev_priv);
 }
 
 static bool intel_fbc_hw_is_active(struct drm_i915_private *dev_priv)
@@ -369,9 +373,6 @@ static void intel_fbc_hw_activate(struct drm_i915_private 
*dev_priv)
 
trace_intel_fbc_activate(fbc->crtc);
 
-   fbc->active = true;
-   fbc->activated = true;
-
if (DISPLAY_VER(dev_priv) >= 7)
gen7_fbc_activate(dev_priv);
else if (DISPLAY_VER(dev_priv) >= 5)
@@ -380,6 +381,9 @@ static void intel_fbc_hw_activate(struct drm_i915_private 
*dev_priv)
g4x_fbc_activate(dev_priv);
else
i8xx_fbc_activate(dev_priv);
+
+   fbc->active = true;
+   fbc->activated = true;
 }
 
 static void intel_fbc_hw_deactivate(struct drm_i915_private *dev_priv)
-- 
2.26.3

___
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: Nuke display error state

[Patchwork]

== Series Details ==

Series: drm/i915: Nuke display error state
URL   : https://patchwork.freedesktop.org/series/89822/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10050 -> Patchwork_20071


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_prime@amd-to-i915:
- fi-tgl-y:   NOTRUN -> [SKIP][1] ([fdo#109315] / [i915#2575])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20071/fi-tgl-y/igt@amdgpu/amd_pr...@amd-to-i915.html

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

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [PASS][3] -> [FAIL][4] ([i915#1372])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20071/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- fi-bsw-kefka:   [INCOMPLETE][5] ([i915#2782]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10050/fi-bsw-kefka/igt@i915_selftest@l...@hangcheck.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20071/fi-bsw-kefka/igt@i915_selftest@l...@hangcheck.html

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

  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
  [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
  [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940


Participating hosts (44 -> 40)
--

  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_10050 -> Patchwork_20071

  CI-20190529: 20190529
  CI_DRM_10050: ae46d9d790a148ab7b293cad67c770c0221e2c83 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6079: c77c1e9d716481aa44d713e8c91873aa679547ac @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_20071: 3148222c14b42e78832afce1e860d37712714c14 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

3148222c14b4 drm/i915: Nuke display error state

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/3] Restructure output format computation for better expandability

[kernel test robot]

Hi Werner,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20210505]
[cannot apply to v5.12]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Werner-Sembach/New-function-to-avoid-duplicate-code-in-upcomming-commits/20210505-231103
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-a012-20210505 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 
8f5a2a5836cc8e4c1def2bdeb022e7b496623439)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# 
https://github.com/0day-ci/linux/commit/66df58af8a9f5c112690fc80f77271b9f6567765
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Werner-Sembach/New-function-to-avoid-duplicate-code-in-upcomming-commits/20210505-231103
git checkout 66df58af8a9f5c112690fc80f77271b9f6567765
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/i915/display/intel_hdmi.c:2166:6: error: use of undeclared 
>> identifier 'crtc_state'
   if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) {
   ^
   1 error generated.


vim +/crtc_state +2166 drivers/gpu/drm/i915/display/intel_hdmi.c

  2131  
  2132  int intel_hdmi_compute_config(struct intel_encoder *encoder,
  2133struct intel_crtc_state *pipe_config,
  2134struct drm_connector_state *conn_state)
  2135  {
  2136  struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
  2137  struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
  2138  struct drm_display_mode *adjusted_mode = 
&pipe_config->hw.adjusted_mode;
  2139  struct drm_connector *connector = conn_state->connector;
  2140  struct drm_scdc *scdc = &connector->display_info.hdmi.scdc;
  2141  int ret;
  2142  
  2143  if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
  2144  return -EINVAL;
  2145  
  2146  pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
  2147  pipe_config->has_hdmi_sink = intel_has_hdmi_sink(intel_hdmi,
  2148   conn_state);
  2149  
  2150  if (pipe_config->has_hdmi_sink)
  2151  pipe_config->has_infoframe = true;
  2152  
  2153  if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
  2154  pipe_config->pixel_multiplier = 2;
  2155  
  2156  if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv))
  2157  pipe_config->has_pch_encoder = true;
  2158  
  2159  pipe_config->has_audio =
  2160  intel_hdmi_has_audio(encoder, pipe_config, conn_state);
  2161  
  2162  ret = intel_hdmi_compute_output_format(encoder, pipe_config, 
conn_state);
  2163  if (ret)
  2164  return ret;
  2165  
> 2166  if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) {
  2167  ret = intel_pch_panel_fitting(pipe_config, conn_state);
  2168  if (ret)
  2169  return ret;
  2170  }
  2171  
  2172  pipe_config->limited_color_range =
  2173  intel_hdmi_limited_color_range(pipe_config, conn_state);
  2174  
  2175  if (conn_state->picture_aspect_ratio)
  2176  adjusted_mode->picture_aspect_ratio =
  2177  conn_state->picture_aspect_ratio;
  2178  
  2179  pipe_config->lane_count = 4;
  2180  
  2181  if (scdc->scrambling.supported && DISPLAY_VER(dev_priv) >= 10) {
  2182  if (scdc->scrambling.low_rates)
  2183  pipe_config->hdmi_scrambling = true;
  2184  
  2185  if (pipe_config->port_clock > 34) {
  2186  pipe_config->hdmi_scrambling = true;
  2187  pipe_config->hdmi_high_tmds_clock_ratio = true;
  2188  }
  2189  }
  2190  
  2191  intel_hdmi_compute_gcp_infoframe(encoder, p

Re: [Intel-gfx] [PATCH 8/8] drm/modifiers: Enforce consistency between the cap an IN_FORMATS

[Daniel Vetter]

On Tue, Apr 27, 2021 at 11:20 AM Daniel Vetter  wrote:
>
> It's very confusing for userspace to have to deal with inconsistencies
> here, and some drivers screwed this up a bit. Most just ommitted the
> format list when they meant to say that only linear modifier is
> allowed, but some also meant that only implied modifiers are
> acceptable (because actually none of the planes registered supported
> modifiers).
>
> Now that this is all done consistently across all drivers, document
> the rules and enforce it in the drm core.
>
> v2:
> - Make the capability a link (Simon)
> - Note that all is lost before 5.1.
>
> Acked-by: Maxime Ripard 
> Cc: Simon Ser 
> Reviewed-by: Lucas Stach 
> Cc: Pekka Paalanen 
> Signed-off-by: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: David Airlie 
> Cc: Daniel Vetter 

Lyude's irc review:

 btw danvet (sorry I didn't reply in-line, for some reason I
can't actually seem to find the emails for your allow_fb_modifiers
series in my email client), I just looked over your allow_fb_modifiers
series and everything looks fine with one comment:
https://lore.kernel.org/dri-devel/20210427092018.832258-8-daniel.vet...@ffwll.ch/
we should probably use drm_WARN_ON() here instead
 with that fixed: Reviewed-by: Lyude Paul 

I'll merge the driver patches and respin this one afterwards.
-Daniel

> ---
>  drivers/gpu/drm/drm_plane.c   | 18 +-
>  include/drm/drm_mode_config.h |  2 ++
>  2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 0dd43882fe7c..20c7a1665414 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -128,6 +128,13 @@
>   * pairs supported by this plane. The blob is a struct
>   * drm_format_modifier_blob. Without this property the plane doesn't
>   * support buffers with modifiers. Userspace cannot change this property.
> + *
> + * Note that userspace can check the &DRM_CAP_ADDFB2_MODIFIERS driver
> + * capability for general modifier support. If this flag is set then 
> every
> + * plane will have the IN_FORMATS property, even when it only supports
> + * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there have 
> been
> + * various bugs in this area with inconsistencies between the capability
> + * flag and per-plane properties.
>   */
>
>  static unsigned int drm_num_planes(struct drm_device *dev)
> @@ -277,8 +284,14 @@ static int __drm_universal_plane_init(struct drm_device 
> *dev,
> format_modifier_count++;
> }
>
> -   if (format_modifier_count)
> +   /* autoset the cap and check for consistency across all planes */
> +   if (format_modifier_count) {
> +   WARN_ON(!config->allow_fb_modifiers &&
> +   !list_empty(&config->plane_list));
> config->allow_fb_modifiers = true;
> +   } else {
> +   WARN_ON(config->allow_fb_modifiers);
> +   }
>
> plane->modifier_count = format_modifier_count;
> plane->modifiers = kmalloc_array(format_modifier_count,
> @@ -360,6 +373,9 @@ static int __drm_universal_plane_init(struct drm_device 
> *dev,
>   * drm_universal_plane_init() to let the DRM managed resource infrastructure
>   * take care of cleanup and deallocation.
>   *
> + * Drivers supporting modifiers must set @format_modifiers on all their 
> planes,
> + * even those that only support DRM_FORMAT_MOD_LINEAR.
> + *
>   * Returns:
>   * Zero on success, error code on failure.
>   */
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index ab424ddd7665..1ddf7783fdf7 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -909,6 +909,8 @@ struct drm_mode_config {
>  * @allow_fb_modifiers:
>  *
>  * Whether the driver supports fb modifiers in the ADDFB2.1 ioctl 
> call.
> +* Note that drivers should not set this directly, it is automatically
> +* set in drm_universal_plane_init().
>  *
>  * IMPORTANT:
>  *
> --
> 2.31.0
>


-- 
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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm + usb-type-c: Add support for out-of-band hotplug notification (rev3)

[Patchwork]

== Series Details ==

Series: drm + usb-type-c: Add support for out-of-band hotplug notification 
(rev3)
URL   : https://patchwork.freedesktop.org/series/89604/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10049_full -> Patchwork_20068_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_schedule@pi-ringfull@vecs0:
- shard-skl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10049/shard-skl4/igt@gem_exec_schedule@pi-ringf...@vecs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20068/shard-skl2/igt@gem_exec_schedule@pi-ringf...@vecs0.html

  

### Piglit changes ###

 Possible regressions 

  * shaders@glsl-fs-texturecube-2 (NEW):
- pig-skl-6260u:  NOTRUN -> [INCOMPLETE][3] +4 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20068/pig-skl-6260u/shad...@glsl-fs-texturecube-2.html

  
New tests
-

  New tests have been introduced between CI_DRM_10049_full and 
Patchwork_20068_full:

### New Piglit tests (5) ###

  * security@initialized-texmemory:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * shaders@glsl-empty-vs-no-fs:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * shaders@glsl-fs-texturecube-2:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * shaders@glsl-useprogram-displaylist:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * shaders@glsl-vs-raytrace-bug26691:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_ctx_isolation@preservation-s3@vecs0:
- shard-skl:  [PASS][5] -> [INCOMPLETE][6] ([i915#198])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10049/shard-skl7/igt@gem_ctx_isolation@preservation...@vecs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20068/shard-skl1/igt@gem_ctx_isolation@preservation...@vecs0.html

  * igt@gem_ctx_persistence@idempotent:
- shard-snb:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1099]) +3 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20068/shard-snb6/igt@gem_ctx_persiste...@idempotent.html

  * igt@gem_eio@unwedge-stress:
- shard-snb:  NOTRUN -> [FAIL][8] ([i915#3354])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20068/shard-snb5/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842]) +2 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10049/shard-tglb8/igt@gem_exec_fair@basic-f...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20068/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10049/shard-iclb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20068/shard-iclb4/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl:  NOTRUN -> [FAIL][13] ([i915#2842])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20068/shard-kbl6/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][14] -> [FAIL][15] ([i915#2842]) +2 similar 
issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10049/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20068/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][16] ([i915#2842])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20068/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk:  [PASS][17] -> [FAIL][18] ([i915#2842]) +2 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI

[Intel-gfx] [PATCH] drm/i915: Nuke display error state

[Ville Syrjala]

From: Ville Syrjälä 

I doubt anyone has used the display error state since CS flips
went the way of the dodo. Just nuke it.

It might be semi interesting to have something like this for
FIFO underruns and the like, but as it stands this wouldn't
provide a sufficient amount of information. So would need
an extensive rewrite anyway.

The lockless power well handling is also racy, so this could
just be contributing noise to test results if we end up
accessing something with the relevant power well already
disabled.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 204 ---
 drivers/gpu/drm/i915/display/intel_display.h |   6 -
 drivers/gpu/drm/i915/i915_gpu_error.c|   6 -
 drivers/gpu/drm/i915/i915_gpu_error.h|   2 -
 4 files changed, 218 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index fcd8123ede8e..2ae31c47b2a9 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -12988,207 +12988,3 @@ void intel_display_driver_unregister(struct 
drm_i915_private *i915)
acpi_video_unregister();
intel_opregion_unregister(i915);
 }
-
-#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
-
-struct intel_display_error_state {
-
-   u32 power_well_driver;
-
-   struct intel_cursor_error_state {
-   u32 control;
-   u32 position;
-   u32 base;
-   u32 size;
-   } cursor[I915_MAX_PIPES];
-
-   struct intel_pipe_error_state {
-   bool power_domain_on;
-   u32 source;
-   u32 stat;
-   } pipe[I915_MAX_PIPES];
-
-   struct intel_plane_error_state {
-   u32 control;
-   u32 stride;
-   u32 size;
-   u32 pos;
-   u32 addr;
-   u32 surface;
-   u32 tile_offset;
-   } plane[I915_MAX_PIPES];
-
-   struct intel_transcoder_error_state {
-   bool available;
-   bool power_domain_on;
-   enum transcoder cpu_transcoder;
-
-   u32 conf;
-
-   u32 htotal;
-   u32 hblank;
-   u32 hsync;
-   u32 vtotal;
-   u32 vblank;
-   u32 vsync;
-   } transcoder[5];
-};
-
-struct intel_display_error_state *
-intel_display_capture_error_state(struct drm_i915_private *dev_priv)
-{
-   struct intel_display_error_state *error;
-   int transcoders[] = {
-   TRANSCODER_A,
-   TRANSCODER_B,
-   TRANSCODER_C,
-   TRANSCODER_D,
-   TRANSCODER_EDP,
-   };
-   int i;
-
-   BUILD_BUG_ON(ARRAY_SIZE(transcoders) != ARRAY_SIZE(error->transcoder));
-
-   if (!HAS_DISPLAY(dev_priv))
-   return NULL;
-
-   error = kzalloc(sizeof(*error), GFP_ATOMIC);
-   if (error == NULL)
-   return NULL;
-
-   if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
-   error->power_well_driver = intel_de_read(dev_priv,
-HSW_PWR_WELL_CTL2);
-
-   for_each_pipe(dev_priv, i) {
-   error->pipe[i].power_domain_on =
-   __intel_display_power_is_enabled(dev_priv,
-POWER_DOMAIN_PIPE(i));
-   if (!error->pipe[i].power_domain_on)
-   continue;
-
-   error->cursor[i].control = intel_de_read(dev_priv, CURCNTR(i));
-   error->cursor[i].position = intel_de_read(dev_priv, CURPOS(i));
-   error->cursor[i].base = intel_de_read(dev_priv, CURBASE(i));
-
-   error->plane[i].control = intel_de_read(dev_priv, DSPCNTR(i));
-   error->plane[i].stride = intel_de_read(dev_priv, DSPSTRIDE(i));
-   if (DISPLAY_VER(dev_priv) <= 3) {
-   error->plane[i].size = intel_de_read(dev_priv,
-DSPSIZE(i));
-   error->plane[i].pos = intel_de_read(dev_priv,
-   DSPPOS(i));
-   }
-   if (DISPLAY_VER(dev_priv) <= 7 && !IS_HASWELL(dev_priv))
-   error->plane[i].addr = intel_de_read(dev_priv,
-DSPADDR(i));
-   if (DISPLAY_VER(dev_priv) >= 4) {
-   error->plane[i].surface = intel_de_read(dev_priv,
-   DSPSURF(i));
-   error->plane[i].tile_offset = intel_de_read(dev_priv,
-   
DSPTILEOFF(i));
-   }
-
-   error->pipe[i].source = intel_de_read(dev_priv, PIPESRC(i));
-
-   if (HAS_G

Re: [Intel-gfx] [PATCH 2/3] Restructure output format computation for better expandability

[kernel test robot]

Hi Werner,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20210505]
[cannot apply to v5.12]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Werner-Sembach/New-function-to-avoid-duplicate-code-in-upcomming-commits/20210505-231103
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-defconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/66df58af8a9f5c112690fc80f77271b9f6567765
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Werner-Sembach/New-function-to-avoid-duplicate-code-in-upcomming-commits/20210505-231103
git checkout 66df58af8a9f5c112690fc80f77271b9f6567765
# save the attached .config to linux build tree
make W=1 W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/display/intel_hdmi.c: In function 
'intel_hdmi_compute_config':
>> drivers/gpu/drm/i915/display/intel_hdmi.c:2166:6: error: 'crtc_state' 
>> undeclared (first use in this function); did you mean 'ctx_state'?
2166 |  if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) {
 |  ^~
 |  ctx_state
   drivers/gpu/drm/i915/display/intel_hdmi.c:2166:6: note: each undeclared 
identifier is reported only once for each function it appears in


vim +2166 drivers/gpu/drm/i915/display/intel_hdmi.c

  2131  
  2132  int intel_hdmi_compute_config(struct intel_encoder *encoder,
  2133struct intel_crtc_state *pipe_config,
  2134struct drm_connector_state *conn_state)
  2135  {
  2136  struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
  2137  struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
  2138  struct drm_display_mode *adjusted_mode = 
&pipe_config->hw.adjusted_mode;
  2139  struct drm_connector *connector = conn_state->connector;
  2140  struct drm_scdc *scdc = &connector->display_info.hdmi.scdc;
  2141  int ret;
  2142  
  2143  if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
  2144  return -EINVAL;
  2145  
  2146  pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
  2147  pipe_config->has_hdmi_sink = intel_has_hdmi_sink(intel_hdmi,
  2148   conn_state);
  2149  
  2150  if (pipe_config->has_hdmi_sink)
  2151  pipe_config->has_infoframe = true;
  2152  
  2153  if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
  2154  pipe_config->pixel_multiplier = 2;
  2155  
  2156  if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv))
  2157  pipe_config->has_pch_encoder = true;
  2158  
  2159  pipe_config->has_audio =
  2160  intel_hdmi_has_audio(encoder, pipe_config, conn_state);
  2161  
  2162  ret = intel_hdmi_compute_output_format(encoder, pipe_config, 
conn_state);
  2163  if (ret)
  2164  return ret;
  2165  
> 2166  if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) {
  2167  ret = intel_pch_panel_fitting(pipe_config, conn_state);
  2168  if (ret)
  2169  return ret;
  2170  }
  2171  
  2172  pipe_config->limited_color_range =
  2173  intel_hdmi_limited_color_range(pipe_config, conn_state);
  2174  
  2175  if (conn_state->picture_aspect_ratio)
  2176  adjusted_mode->picture_aspect_ratio =
  2177  conn_state->picture_aspect_ratio;
  2178  
  2179  pipe_config->lane_count = 4;
  2180  
  2181  if (scdc->scrambling.supported && DISPLAY_VER(dev_priv) >= 10) {
  2182  if (scdc->scrambling.low_rates)
  2183  pipe_config->hdmi_scrambling = true;
  2184  
  2185  if (pipe_config->port_clock > 34) {
  2186  pipe_config->hdmi_scrambling = true;
  2187  pipe_config->hdmi_high_tmds_clock_ratio = true;
  2188  }
  2189  }
  2190  
  2191  intel_hdmi_compute_gcp_infoframe(encoder, pipe_config,
  2192   conn_state);
  2193  
  2194  if (!

Re: [Intel-gfx] [PATCH 0/3] Pipe DMC Prep patches

[Srivatsa, Anusha]

> -Original Message-
> From: Jani Nikula 
> Sent: Tuesday, May 4, 2021 11:41 PM
> To: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 0/3] Pipe DMC Prep patches
> 
> On Mon, 03 May 2021, Jani Nikula  wrote:
> > On Wed, 28 Apr 2021, Anusha Srivatsa 
> wrote:
> >> This series adds the prep work needed before the actual Pipe DMC
> >> implementation.
> >
> > When should we rename csr to dmc all over the place?
> 
> To elaborate, I think it's pretty confusing that we use both CSR and DMC
> acronyms in code. There may be a distinction, but we don't respect that in
> the usage. Sure, the spec mentions both, but I don't think we follow the
> naming there either.
> 
> I think we should just rename all CSR references to DMC, including the file
> name and the function and struct names.
>
Just eyeballing the source file, it looks like it is a good way to go. We have 
function names like parse_csr_fw_dmc which can be changed to just 
parse_dmc_fw_header or something on those lines...

> I wonder if it would be better to do the renames first before starting to 
> build
> a lot of changes on top.

Yes. The renames will affect some things that this series touches as well.

Anusha
> 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.BUILD: failure for drm/i915/display Try YCbCr420 color when RGB fails

[Patchwork]

== Series Details ==

Series: drm/i915/display Try YCbCr420 color when RGB fails
URL   : https://patchwork.freedesktop.org/series/89815/
State : failure

== Summary ==

Applying: New function to avoid duplicate code in upcomming commits
error: unrecognized input
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 New function to avoid duplicate code in upcomming commits
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


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

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/display Try YCbCr420 color when RGB fails

[Patchwork]

== Series Details ==

Series: drm/i915/display Try YCbCr420 color when RGB fails
URL   : https://patchwork.freedesktop.org/series/89814/
State : failure

== Summary ==

Applying: New function to avoid duplicate code in upcomming commits
error: unrecognized input
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 New function to avoid duplicate code in upcomming commits
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


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

[Intel-gfx] [PATCH 0/3] drm/i915/display Try YCbCr420 color when RGB fails

[Werner Sembach]

When encoder validation of a display mode fails, retry with less bandwidth
heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
to support 4k60Hz output, which previously failed silently.

AMDGPU had nearly the exact same issue. This problem description is
therefore copied from my commit message of the AMDGPU patch.

On some setups, while the monitor and the gpu support display modes with
pixel clocks of up to 600MHz, the link encoder might not. This prevents
YCbCr444 and RGB encoding for 4k60Hz, but YCbCr420 encoding might still be
possible. However, which color mode is used is decided before the link
encoder capabilities are checked. This patch fixes the problem by retrying
to find a display mode with YCbCr420 enforced and using it, if it is
valid.

This patchset is revision 5. Only change to 4 is a small whitespace error fix.


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

[Intel-gfx] [PATCH 3/3] Use YCbCr420 as fallback when RGB fails

[Werner Sembach]

When encoder validation of a display mode fails, retry with less bandwidth
heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
to support 4k60Hz output, which previously failed silently.

AMDGPU had nearly the exact same issue. This problem description is
therefore copied from my commit message of the AMDGPU patch.

On some setups, while the monitor and the gpu support display modes with
pixel clocks of up to 600MHz, the link encoder might not. This prevents
YCbCr444 and RGB encoding for 4k60Hz, but YCbCr420 encoding might still be
possible. However, which color mode is used is decided before the link
encoder capabilities are checked. This patch fixes the problem by retrying
to find a display mode with YCbCr420 enforced and using it, if it is
valid.

Signed-off-by: Werner Sembach 
---
Now with the suggestes change as it does makes a difference ^^

>From ce3092930bca37468c6122a7704202f9e3b39e81 Mon Sep 17 00:00:00 2001
From: Werner Sembach 
Date: Mon, 3 May 2021 16:23:17 +0200
Subject: [PATCH 3/3] Use YCbCr420 as fallback when RGB fails

---
 drivers/gpu/drm/i915/display/intel_hdmi.c | 23 ---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index b0201d4f27eb..7815569267e3 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1897,6 +1897,7 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
int clock = mode->clock;
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
bool has_hdmi_sink = intel_has_hdmi_sink(hdmi, connector->state);
+   bool ycbcr_420_only;
 
if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
return MODE_NO_DBLESCAN;
@@ -1913,12 +1914,20 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
clock *= 2;
}
 
-   if (drm_mode_is_420_only(&connector->display_info, mode))
+   ycbcr_420_only = drm_mode_is_420_only(&connector->display_info, mode);
+   if (ycbcr_420_only)
clock /= 2;
 
status = intel_hdmi_mode_clock_valid(hdmi, clock, has_hdmi_sink);
-   if (status != MODE_OK)
-   return status;
+   if (status != MODE_OK) {
+   if (ycbcr_420_only || !connector->ycbcr_420_allowed || 
!drm_mode_is_420_also(&connector->display_info, mode))
+   return status;
+
+   clock /= 2;
+   status = intel_hdmi_mode_clock_valid(hdmi, clock, 
has_hdmi_sink);
+   if (status != MODE_OK)
+   return status;
+   }
 
return intel_mode_valid_max_plane_size(dev_priv, mode, false);
 }
@@ -2125,6 +2134,14 @@ static int intel_hdmi_compute_output_format(struct 
intel_encoder *encoder,
}
 
ret = intel_hdmi_compute_clock(encoder, crtc_state);
+   if (ret) {
+   if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420 &&
+   connector->ycbcr_420_allowed &&
+   drm_mode_is_420_also(&connector->display_info, 
adjusted_mode)) {
+   crtc_state->output_format = 
INTEL_OUTPUT_FORMAT_YCBCR420;
+   ret = intel_hdmi_compute_clock(encoder, crtc_state);
+   }
+   }
 
return ret;
 }
-- 
2.25.1

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

[Intel-gfx] [PATCH 2/3] Restructure output format computation for better expandability

[Werner Sembach]

Couples the decission between RGB and YCbCr420 mode and the check if the port
clock can archive the required frequency. Other checks and configuration steps
that where previously done in between can also be done before or after.

This allows for are cleaner implementation of retrying different color
encodings.

Slight change in behaviour: If YCbCr420 is not allowed but display is YCbCr420
only it no longer fails, but just prints an error and tries to fallback on RGB.

Signed-off-by: Werner Sembach 
---
Imho an error message in when YCbCR420 not allowed meets YCbCr420 only can be
a usefull bugfinding tool for cases of blackscreen on exotic configurations.

I'm unsure if this should be a warning instead.

>From 883678ef703b6bb15cd2883eb2c5ce27d07911d3 Mon Sep 17 00:00:00 2001
From: Werner Sembach 
Date: Mon, 3 May 2021 15:30:40 +0200
Subject: [PATCH 2/3] Restructure output format computation for better
 expandability

---
 drivers/gpu/drm/i915/display/intel_hdmi.c | 65 ---
 1 file changed, 34 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 576d3d910d06..b0201d4f27eb 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1999,29 +1999,6 @@ static bool hdmi_deep_color_possible(const struct 
intel_crtc_state *crtc_state,
  INTEL_OUTPUT_FORMAT_YCBCR420);
 }
 
-static int
-intel_hdmi_ycbcr420_config(struct intel_crtc_state *crtc_state,
-  const struct drm_connector_state *conn_state)
-{
-   struct drm_connector *connector = conn_state->connector;
-   struct drm_i915_private *i915 = to_i915(connector->dev);
-   const struct drm_display_mode *adjusted_mode =
-   &crtc_state->hw.adjusted_mode;
-
-   if (!drm_mode_is_420_only(&connector->display_info, adjusted_mode))
-   return 0;
-
-   if (!connector->ycbcr_420_allowed) {
-   drm_err(&i915->drm,
-   "Platform doesn't support YCBCR420 output\n");
-   return -EINVAL;
-   }
-
-   crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
-
-   return intel_pch_panel_fitting(crtc_state, conn_state);
-}
-
 static int intel_hdmi_compute_bpc(struct intel_encoder *encoder,
  struct intel_crtc_state *crtc_state,
  int clock)
@@ -2128,6 +2105,30 @@ static bool intel_hdmi_has_audio(struct intel_encoder 
*encoder,
return intel_conn_state->force_audio == HDMI_AUDIO_ON;
 }
 
+static int intel_hdmi_compute_output_format(struct intel_encoder *encoder,
+struct intel_crtc_state *crtc_state,
+const struct drm_connector_state 
*conn_state)
+{
+   struct drm_connector *connector = conn_state->connector;
+   struct drm_i915_private *i915 = to_i915(connector->dev);
+   const struct drm_display_mode *adjusted_mode = 
&crtc_state->hw.adjusted_mode;
+   int ret;
+   bool ycbcr_420_only;
+
+   ycbcr_420_only = drm_mode_is_420_only(&connector->display_info, 
adjusted_mode);
+   if (connector->ycbcr_420_allowed && ycbcr_420_only)
+   crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
+   else {
+   if (!connector->ycbcr_420_allowed && ycbcr_420_only)
+   drm_err(&i915->drm, "Display only supports YCbCr420 
output, but connector does not allow it. Fallback to RGB, but this will likely 
fail.\n");
+   crtc_state->output_format = INTEL_OUTPUT_FORMAT_RGB;
+   }
+
+   ret = intel_hdmi_compute_clock(encoder, crtc_state);
+
+   return ret;
+}
+
 int intel_hdmi_compute_config(struct intel_encoder *encoder,
  struct intel_crtc_state *pipe_config,
  struct drm_connector_state *conn_state)
@@ -2152,23 +2153,25 @@ int intel_hdmi_compute_config(struct intel_encoder 
*encoder,
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
pipe_config->pixel_multiplier = 2;
 
-   ret = intel_hdmi_ycbcr420_config(pipe_config, conn_state);
-   if (ret)
-   return ret;
-
-   pipe_config->limited_color_range =
-   intel_hdmi_limited_color_range(pipe_config, conn_state);
-
if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv))
pipe_config->has_pch_encoder = true;
 
pipe_config->has_audio =
intel_hdmi_has_audio(encoder, pipe_config, conn_state);
 
-   ret = intel_hdmi_compute_clock(encoder, pipe_config);
+   ret = intel_hdmi_compute_output_format(encoder, pipe_config, 
conn_state);
if (ret)
return ret;
 
+   if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) {
+   ret = intel_pch_panel_fitting(pipe_config, conn_state);
+   

[Intel-gfx] [PATCH 1/3] New function to avoid duplicate code in upcomming commits

[Werner Sembach]

Moves some checks that later will be performed 2 times to an own fuction. This
avoids duplicate code later on.

Signed-off-by: Werner Sembach 
---

>From 42a4a3a7d9ea9948b4071f406e7fcae23bfa0bdf Mon Sep 17 00:00:00 2001
From: Werner Sembach 
Date: Mon, 3 May 2021 14:35:39 +0200
Subject: [PATCH 1/3] New function to avoid duplicate code in upcomming commits

---
 drivers/gpu/drm/i915/display/intel_hdmi.c | 41 ++-
 1 file changed, 26 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 46de56af33db..576d3d910d06 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1861,6 +1861,31 @@ static int intel_hdmi_port_clock(int clock, int bpc)
return clock * bpc / 8;
 }
 
+static enum drm_mode_status
+intel_hdmi_mode_clock_valid(struct intel_hdmi *hdmi, int clock, bool 
has_hdmi_sink)
+{
+   struct drm_device *dev = intel_hdmi_to_dev(hdmi);
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   enum drm_mode_status status;
+
+   /* check if we can do 8bpc */
+   status = hdmi_port_clock_valid(hdmi, clock, true, has_hdmi_sink);
+
+   if (has_hdmi_sink) {
+   /* if we can't do 8bpc we may still be able to do 12bpc */
+   if (status != MODE_OK && !HAS_GMCH(dev_priv))
+   status = hdmi_port_clock_valid(hdmi, clock * 3 / 2,
+  true, has_hdmi_sink);
+
+   /* if we can't do 8,12bpc we may still be able to do 10bpc */
+   if (status != MODE_OK && INTEL_GEN(dev_priv) >= 11)
+   status = hdmi_port_clock_valid(hdmi, clock * 5 / 4,
+  true, has_hdmi_sink);
+   }
+
+   return status;
+}
+
 static enum drm_mode_status
 intel_hdmi_mode_valid(struct drm_connector *connector,
  struct drm_display_mode *mode)
@@ -1891,21 +1916,7 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
if (drm_mode_is_420_only(&connector->display_info, mode))
clock /= 2;
 
-   /* check if we can do 8bpc */
-   status = hdmi_port_clock_valid(hdmi, intel_hdmi_port_clock(clock, 8),
-  true, has_hdmi_sink);
-
-   if (has_hdmi_sink) {
-   /* if we can't do 8bpc we may still be able to do 12bpc */
-   if (status != MODE_OK && !HAS_GMCH(dev_priv))
-   status = hdmi_port_clock_valid(hdmi, 
intel_hdmi_port_clock(clock, 12),
-  true, has_hdmi_sink);
-
-   /* if we can't do 8,12bpc we may still be able to do 10bpc */
-   if (status != MODE_OK && DISPLAY_VER(dev_priv) >= 11)
-   status = hdmi_port_clock_valid(hdmi, 
intel_hdmi_port_clock(clock, 10),
-  true, has_hdmi_sink);
-   }
+   status = intel_hdmi_mode_clock_valid(hdmi, clock, has_hdmi_sink);
if (status != MODE_OK)
return status;
 
-- 
2.25.1

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

[Intel-gfx] [PATCH 0/3] drm/i915/display Try YCbCr420 color when RGB fails

[Werner Sembach]

When encoder validation of a display mode fails, retry with less bandwidth
heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
to support 4k60Hz output, which previously failed silently.

AMDGPU had nearly the exact same issue. This problem description is
therefore copied from my commit message of the AMDGPU patch.

On some setups, while the monitor and the gpu support display modes with
pixel clocks of up to 600MHz, the link encoder might not. This prevents
YCbCr444 and RGB encoding for 4k60Hz, but YCbCr420 encoding might still be
possible. However, which color mode is used is decided before the link
encoder capabilities are checked. This patch fixes the problem by retrying
to find a display mode with YCbCr420 enforced and using it, if it is
valid.

This patchset is revision 4. After getting clarification on questions ask
on the mailing list.


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

[Intel-gfx] [PATCH 2/3] Restructure output format computation for better expandability

[Werner Sembach]

Couples the decission between RGB and YCbCr420 mode and the check if the port
clock can archive the required frequency. Other checks and configuration steps
that where previously done in between can also be done before or after.

This allows for are cleaner implementation of retrying different color
encodings.

Slight change in behaviour: If YCbCr420 is not allowed but display is YCbCr420
only it no longer fails, but just prints an error and tries to fallback on RGB.

Signed-off-by: Werner Sembach 
---
Imho an error message in when YCbCR420 not allowed meets YCbCr420 only can be
a usefull bugfinding tool for cases of blackscreen on exotic configurations.

I'm unsure if this should be a warning instead.

>From 883678ef703b6bb15cd2883eb2c5ce27d07911d3 Mon Sep 17 00:00:00 2001
From: Werner Sembach 
Date: Mon, 3 May 2021 15:30:40 +0200
Subject: [PATCH 2/3] Restructure output format computation for better
 expandability

---
 drivers/gpu/drm/i915/display/intel_hdmi.c | 65 ---
 1 file changed, 34 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 576d3d910d06..b0201d4f27eb 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1999,29 +1999,6 @@ static bool hdmi_deep_color_possible(const struct 
intel_crtc_state *crtc_state,
  INTEL_OUTPUT_FORMAT_YCBCR420);
 }
 
-static int
-intel_hdmi_ycbcr420_config(struct intel_crtc_state *crtc_state,
-  const struct drm_connector_state *conn_state)
-{
-   struct drm_connector *connector = conn_state->connector;
-   struct drm_i915_private *i915 = to_i915(connector->dev);
-   const struct drm_display_mode *adjusted_mode =
-   &crtc_state->hw.adjusted_mode;
-
-   if (!drm_mode_is_420_only(&connector->display_info, adjusted_mode))
-   return 0;
-
-   if (!connector->ycbcr_420_allowed) {
-   drm_err(&i915->drm,
-   "Platform doesn't support YCBCR420 output\n");
-   return -EINVAL;
-   }
-
-   crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
-
-   return intel_pch_panel_fitting(crtc_state, conn_state);
-}
-
 static int intel_hdmi_compute_bpc(struct intel_encoder *encoder,
  struct intel_crtc_state *crtc_state,
  int clock)
@@ -2128,6 +2105,30 @@ static bool intel_hdmi_has_audio(struct intel_encoder 
*encoder,
return intel_conn_state->force_audio == HDMI_AUDIO_ON;
 }
 
+static int intel_hdmi_compute_output_format(struct intel_encoder *encoder,
+struct intel_crtc_state *crtc_state,
+const struct drm_connector_state 
*conn_state)
+{
+   struct drm_connector *connector = conn_state->connector;
+   struct drm_i915_private *i915 = to_i915(connector->dev);
+   const struct drm_display_mode *adjusted_mode = 
&crtc_state->hw.adjusted_mode;
+   int ret;
+   bool ycbcr_420_only;
+
+   ycbcr_420_only = drm_mode_is_420_only(&connector->display_info, 
adjusted_mode);
+   if (connector->ycbcr_420_allowed && ycbcr_420_only)
+   crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
+   else {
+   if (!connector->ycbcr_420_allowed && ycbcr_420_only)
+   drm_err(&i915->drm, "Display only supports YCbCr420 
output, but connector does not allow it. Fallback to RGB, but this will likely 
fail.\n");
+   crtc_state->output_format = INTEL_OUTPUT_FORMAT_RGB;
+   }
+
+   ret = intel_hdmi_compute_clock(encoder, crtc_state);
+
+   return ret;
+}
+
 int intel_hdmi_compute_config(struct intel_encoder *encoder,
  struct intel_crtc_state *pipe_config,
  struct drm_connector_state *conn_state)
@@ -2152,23 +2153,25 @@ int intel_hdmi_compute_config(struct intel_encoder 
*encoder,
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
pipe_config->pixel_multiplier = 2;
 
-   ret = intel_hdmi_ycbcr420_config(pipe_config, conn_state);
-   if (ret)
-   return ret;
-
-   pipe_config->limited_color_range =
-   intel_hdmi_limited_color_range(pipe_config, conn_state);
-
if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv))
pipe_config->has_pch_encoder = true;
 
pipe_config->has_audio =
intel_hdmi_has_audio(encoder, pipe_config, conn_state);
 
-   ret = intel_hdmi_compute_clock(encoder, pipe_config);
+   ret = intel_hdmi_compute_output_format(encoder, pipe_config, 
conn_state);
if (ret)
return ret;
 
+   if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) {
+   ret = intel_pch_panel_fitting(pipe_config, conn_state);
+   

[Intel-gfx] [PATCH 3/3] Use YCbCr420 as fallback when RGB fails

[Werner Sembach]

When encoder validation of a display mode fails, retry with less bandwidth
heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
to support 4k60Hz output, which previously failed silently.

AMDGPU had nearly the exact same issue. This problem description is
therefore copied from my commit message of the AMDGPU patch.

On some setups, while the monitor and the gpu support display modes with
pixel clocks of up to 600MHz, the link encoder might not. This prevents
YCbCr444 and RGB encoding for 4k60Hz, but YCbCr420 encoding might still be
possible. However, which color mode is used is decided before the link
encoder capabilities are checked. This patch fixes the problem by retrying
to find a display mode with YCbCr420 enforced and using it, if it is
valid.

Signed-off-by: Werner Sembach 
---
Now with the suggestes change as it does makes a difference ^^

>From dc2fb79273f2c75a08b76bf912949ff3e433056b Mon Sep 17 00:00:00 2001
From: Werner Sembach 
Date: Mon, 3 May 2021 16:23:17 +0200
Subject: [PATCH 3/3] Use YCbCr420 as fallback when RGB fails

---
 drivers/gpu/drm/i915/display/intel_hdmi.c | 23 ---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index b0201d4f27eb..5af6aef0acbf 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1897,6 +1897,7 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
int clock = mode->clock;
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
bool has_hdmi_sink = intel_has_hdmi_sink(hdmi, connector->state);
+bool ycbcr_420_only;
 
if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
return MODE_NO_DBLESCAN;
@@ -1913,12 +1914,20 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
clock *= 2;
}
 
-   if (drm_mode_is_420_only(&connector->display_info, mode))
+   ycbcr_420_only = drm_mode_is_420_only(&connector->display_info, mode);
+   if (ycbcr_420_only)
clock /= 2;
 
status = intel_hdmi_mode_clock_valid(hdmi, clock, has_hdmi_sink);
-   if (status != MODE_OK)
-   return status;
+   if (status != MODE_OK) {
+   if (ycbcr_420_only || !connector->ycbcr_420_allowed || 
!drm_mode_is_420_also(&connector->display_info, mode))
+   return status;
+
+   clock /= 2;
+   status = intel_hdmi_mode_clock_valid(hdmi, clock, 
has_hdmi_sink);
+   if (status != MODE_OK)
+   return status;
+   }
 
return intel_mode_valid_max_plane_size(dev_priv, mode, false);
 }
@@ -2125,6 +2134,14 @@ static int intel_hdmi_compute_output_format(struct 
intel_encoder *encoder,
}
 
ret = intel_hdmi_compute_clock(encoder, crtc_state);
+   if (ret) {
+   if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420 &&
+   connector->ycbcr_420_allowed &&
+   drm_mode_is_420_also(&connector->display_info, 
adjusted_mode)) {
+   crtc_state->output_format = 
INTEL_OUTPUT_FORMAT_YCBCR420;
+   ret = intel_hdmi_compute_clock(encoder, crtc_state);
+   }
+   }
 
return ret;
 }
-- 
2.25.1

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

[Intel-gfx] [PATCH 1/3] New function to avoid duplicate code in upcomming commits

[Werner Sembach]

Moves some checks that later will be performed 2 times to an own fuction. This
avoids duplicate code later on.

Signed-off-by: Werner Sembach 
---

>From 42a4a3a7d9ea9948b4071f406e7fcae23bfa0bdf Mon Sep 17 00:00:00 2001
From: Werner Sembach 
Date: Mon, 3 May 2021 14:35:39 +0200
Subject: [PATCH 1/3] New function to avoid duplicate code in upcomming commits

---
 drivers/gpu/drm/i915/display/intel_hdmi.c | 41 ++-
 1 file changed, 26 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 46de56af33db..576d3d910d06 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1861,6 +1861,31 @@ static int intel_hdmi_port_clock(int clock, int bpc)
return clock * bpc / 8;
 }
 
+static enum drm_mode_status
+intel_hdmi_mode_clock_valid(struct intel_hdmi *hdmi, int clock, bool 
has_hdmi_sink)
+{
+   struct drm_device *dev = intel_hdmi_to_dev(hdmi);
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   enum drm_mode_status status;
+
+   /* check if we can do 8bpc */
+   status = hdmi_port_clock_valid(hdmi, clock, true, has_hdmi_sink);
+
+   if (has_hdmi_sink) {
+   /* if we can't do 8bpc we may still be able to do 12bpc */
+   if (status != MODE_OK && !HAS_GMCH(dev_priv))
+   status = hdmi_port_clock_valid(hdmi, clock * 3 / 2,
+  true, has_hdmi_sink);
+
+   /* if we can't do 8,12bpc we may still be able to do 10bpc */
+   if (status != MODE_OK && INTEL_GEN(dev_priv) >= 11)
+   status = hdmi_port_clock_valid(hdmi, clock * 5 / 4,
+  true, has_hdmi_sink);
+   }
+
+   return status;
+}
+
 static enum drm_mode_status
 intel_hdmi_mode_valid(struct drm_connector *connector,
  struct drm_display_mode *mode)
@@ -1891,21 +1916,7 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
if (drm_mode_is_420_only(&connector->display_info, mode))
clock /= 2;
 
-   /* check if we can do 8bpc */
-   status = hdmi_port_clock_valid(hdmi, intel_hdmi_port_clock(clock, 8),
-  true, has_hdmi_sink);
-
-   if (has_hdmi_sink) {
-   /* if we can't do 8bpc we may still be able to do 12bpc */
-   if (status != MODE_OK && !HAS_GMCH(dev_priv))
-   status = hdmi_port_clock_valid(hdmi, 
intel_hdmi_port_clock(clock, 12),
-  true, has_hdmi_sink);
-
-   /* if we can't do 8,12bpc we may still be able to do 10bpc */
-   if (status != MODE_OK && DISPLAY_VER(dev_priv) >= 11)
-   status = hdmi_port_clock_valid(hdmi, 
intel_hdmi_port_clock(clock, 10),
-  true, has_hdmi_sink);
-   }
+   status = intel_hdmi_mode_clock_valid(hdmi, clock, has_hdmi_sink);
if (status != MODE_OK)
return status;
 
-- 
2.25.1

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm + usb-type-c: Add support for out-of-band hotplug notification (rev3)

[Patchwork]

== Series Details ==

Series: drm + usb-type-c: Add support for out-of-band hotplug notification 
(rev3)
URL   : https://patchwork.freedesktop.org/series/89604/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10049 -> Patchwork_20068


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@semaphore:
- fi-bdw-5557u:   NOTRUN -> [SKIP][1] ([fdo#109271]) +23 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20068/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html

  * igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u:   NOTRUN -> [WARN][2] ([i915#2283])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20068/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.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
  [i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
  [i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283
  [i915#3180]: https://gitlab.freedesktop.org/drm/intel/issues/3180
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (44 -> 40)
--

  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_10049 -> Patchwork_20068

  CI-20190529: 20190529
  CI_DRM_10049: fe703280e0c2a546e3069f305a14e35d826dc445 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6079: c77c1e9d716481aa44d713e8c91873aa679547ac @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_20068: e7296766bbc897c89f8f7e8e02fb8ba104a9ea6f @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

e7296766bbc8 usb: typec: altmodes/displayport: Notify drm subsys of hotplug 
events
22689857296c usb: typec: altmodes/displayport: Make dp_altmode_notify() more 
generic
b34f32b5c921 drm/i915/dp: Add support for out-of-bound hotplug events
25e2d6a48b06 drm/i915: Associate ACPI connector nodes with connector entries 
(v2)
cab18742ace5 drm/connector: Add support for out-of-band hotplug notification 
(v3)
fe6483992ee9 drm/connector: Add drm_connector_find_by_fwnode() function (v2)
960a3855750f drm/connector: Add a fwnode pointer to drm_connector and register 
with ACPI (v2)
458ce084c841 drm/connector: Give connector sysfs devices there own device_type

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20068/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 drm + usb-type-c: Add support for out-of-band hotplug notification (rev3)

[Patchwork]

== Series Details ==

Series: drm + usb-type-c: Add support for out-of-band hotplug notification 
(rev3)
URL   : https://patchwork.freedesktop.org/series/89604/
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/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:

[Intel-gfx] [PATCH 4/8] drm/connector: Add support for out-of-band hotplug notification (v3)

[Hans de Goede]

Add a new drm_connector_oob_hotplug_event() function and
oob_hotplug_event drm_connector_funcs member.

On some hardware a hotplug event notification may come from outside the
display driver / device. An example of this is some USB Type-C setups
where the hardware muxes the DisplayPort data and aux-lines but does
not pass the altmode HPD status bit to the GPU's DP HPD pin.

In cases like this the new drm_connector_oob_hotplug_event() function can
be used to report these out-of-band events.

Changes in v2:
- Make drm_connector_oob_hotplug_event() take a fwnode as argument and
  have it call drm_connector_find_by_fwnode() internally. This allows
  making drm_connector_find_by_fwnode() a drm-internal function and
  avoids code outside the drm subsystem potentially holding on the
  a drm_connector reference for a longer period.

Changes in v3:
- Drop the data argument to the drm_connector_oob_hotplug_event
  function since it is not used atm. This can be re-added later when
  a use for it actually arises.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_connector.c | 27 +++
 include/drm/drm_connector.h |  9 +
 2 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 70aa50ea7b8b..462a5752e994 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2523,6 +2523,33 @@ struct drm_connector 
*drm_connector_find_by_fwnode(struct fwnode_handle *fwnode)
return found;
 }
 
+/**
+ * drm_connector_oob_hotplug_event - Report out-of-band hotplug event to 
connector
+ * @connector: connector to report the event on
+ *
+ * On some hardware a hotplug event notification may come from outside the 
display
+ * driver / device. An example of this is some USB Type-C setups where the 
hardware
+ * muxes the DisplayPort data and aux-lines but does not pass the altmode HPD
+ * status bit to the GPU's DP HPD pin.
+ *
+ * This function can be used to report these out-of-band events after obtaining
+ * a drm_connector reference through calling drm_connector_find_by_fwnode().
+ */
+void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode)
+{
+   struct drm_connector *connector;
+
+   connector = drm_connector_find_by_fwnode(connector_fwnode);
+   if (IS_ERR(connector))
+   return;
+
+   if (connector->funcs->oob_hotplug_event)
+   connector->funcs->oob_hotplug_event(connector);
+
+   drm_connector_put(connector);
+}
+EXPORT_SYMBOL(drm_connector_oob_hotplug_event);
+
 
 /**
  * DOC: Tile group
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 8ae5dbe3d4ae..9150b8967366 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1079,6 +1079,14 @@ struct drm_connector_funcs {
 */
void (*atomic_print_state)(struct drm_printer *p,
   const struct drm_connector_state *state);
+
+   /**
+* @oob_hotplug_event:
+*
+* This will get called when a hotplug-event for a drm-connector
+* has been received from a source outside the display driver / device.
+*/
+   void (*oob_hotplug_event)(struct drm_connector *connector);
 };
 
 /**
@@ -1661,6 +1669,7 @@ drm_connector_is_unregistered(struct drm_connector 
*connector)
DRM_CONNECTOR_UNREGISTERED;
 }
 
+void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode);
 const char *drm_get_connector_type_name(unsigned int connector_type);
 const char *drm_get_connector_status_name(enum drm_connector_status status);
 const char *drm_get_subpixel_order_name(enum subpixel_order order);
-- 
2.31.1

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

[Intel-gfx] [PATCH 8/8] usb: typec: altmodes/displayport: Notify drm subsys of hotplug events

[Hans de Goede]

Use the new drm_connector_oob_hotplug_event() functions to let drm/kms
drivers know about DisplayPort over Type-C hotplug events.

Signed-off-by: Hans de Goede 
---
Changes in v3:
- Only call drm_connector_oob_hotplug_event() on hpd status bit change
- Adjust for drm_connector_oob_hotplug_event() no longer having a data
  argument

Changes in v2:
- Add missing depends on DRM to TYPEC_DP_ALTMODE Kconfig entry
---
 drivers/usb/typec/altmodes/Kconfig   |  1 +
 drivers/usb/typec/altmodes/displayport.c | 23 +++
 2 files changed, 24 insertions(+)

diff --git a/drivers/usb/typec/altmodes/Kconfig 
b/drivers/usb/typec/altmodes/Kconfig
index 60d375e9c3c7..1a6b5e872b0d 100644
--- a/drivers/usb/typec/altmodes/Kconfig
+++ b/drivers/usb/typec/altmodes/Kconfig
@@ -4,6 +4,7 @@ menu "USB Type-C Alternate Mode drivers"
 
 config TYPEC_DP_ALTMODE
tristate "DisplayPort Alternate Mode driver"
+   depends on DRM
help
  DisplayPort USB Type-C Alternate Mode allows DisplayPort
  displays and adapters to be attached to the USB Type-C
diff --git a/drivers/usb/typec/altmodes/displayport.c 
b/drivers/usb/typec/altmodes/displayport.c
index aa669b9cf70e..c1d8c23baa39 100644
--- a/drivers/usb/typec/altmodes/displayport.c
+++ b/drivers/usb/typec/altmodes/displayport.c
@@ -11,8 +11,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include "displayport.h"
 
 #define DP_HEADER(_dp, ver, cmd)   (VDO((_dp)->alt->svid, 1, ver, cmd) 
\
@@ -57,11 +59,13 @@ struct dp_altmode {
struct typec_displayport_data data;
 
enum dp_state state;
+   bool hpd;
 
struct mutex lock; /* device lock */
struct work_struct work;
struct typec_altmode *alt;
const struct typec_altmode *port;
+   struct fwnode_handle *connector_fwnode;
 };
 
 static int dp_altmode_notify(struct dp_altmode *dp)
@@ -125,6 +129,7 @@ static int dp_altmode_configure(struct dp_altmode *dp, u8 
con)
 static int dp_altmode_status_update(struct dp_altmode *dp)
 {
bool configured = !!DP_CONF_GET_PIN_ASSIGN(dp->data.conf);
+   bool hpd = !!(dp->data.status & DP_STATUS_HPD_STATE);
u8 con = DP_STATUS_CONNECTION(dp->data.status);
int ret = 0;
 
@@ -137,6 +142,11 @@ static int dp_altmode_status_update(struct dp_altmode *dp)
ret = dp_altmode_configure(dp, con);
if (!ret)
dp->state = DP_STATE_CONFIGURE;
+   } else {
+   if (dp->hpd != hpd) {
+   drm_connector_oob_hotplug_event(dp->connector_fwnode);
+   dp->hpd = hpd;
+   }
}
 
return ret;
@@ -512,6 +522,7 @@ static const struct attribute_group dp_altmode_group = {
 int dp_altmode_probe(struct typec_altmode *alt)
 {
const struct typec_altmode *port = typec_altmode_get_partner(alt);
+   struct fwnode_handle *fwnode;
struct dp_altmode *dp;
int ret;
 
@@ -540,6 +551,11 @@ int dp_altmode_probe(struct typec_altmode *alt)
alt->desc = "DisplayPort";
alt->ops = &dp_altmode_ops;
 
+   fwnode = dev_fwnode(alt->dev.parent->parent); /* typec_port fwnode */
+   dp->connector_fwnode = fwnode_find_reference(fwnode, "displayport", 0);
+   if (IS_ERR(dp->connector_fwnode))
+   dp->connector_fwnode = NULL;
+
typec_altmode_set_drvdata(alt, dp);
 
dp->state = DP_STATE_ENTER;
@@ -555,6 +571,13 @@ void dp_altmode_remove(struct typec_altmode *alt)
 
sysfs_remove_group(&alt->dev.kobj, &dp_altmode_group);
cancel_work_sync(&dp->work);
+
+   if (dp->connector_fwnode) {
+   if (dp->hpd)
+   drm_connector_oob_hotplug_event(dp->connector_fwnode);
+
+   fwnode_handle_put(dp->connector_fwnode);
+   }
 }
 EXPORT_SYMBOL_GPL(dp_altmode_remove);
 
-- 
2.31.1

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

[Intel-gfx] [PATCH 7/8] usb: typec: altmodes/displayport: Make dp_altmode_notify() more generic

[Hans de Goede]

Make dp_altmode_notify() handle the dp->data.conf == 0 case too,
rather then having separate code-paths for this in various places
which call it.

Signed-off-by: Hans de Goede 
---
 drivers/usb/typec/altmodes/displayport.c | 35 +---
 1 file changed, 13 insertions(+), 22 deletions(-)

diff --git a/drivers/usb/typec/altmodes/displayport.c 
b/drivers/usb/typec/altmodes/displayport.c
index b7f094435b00..aa669b9cf70e 100644
--- a/drivers/usb/typec/altmodes/displayport.c
+++ b/drivers/usb/typec/altmodes/displayport.c
@@ -66,10 +66,17 @@ struct dp_altmode {
 
 static int dp_altmode_notify(struct dp_altmode *dp)
 {
-   u8 state = get_count_order(DP_CONF_GET_PIN_ASSIGN(dp->data.conf));
+   unsigned long conf;
+   u8 state;
+
+   if (dp->data.conf) {
+   state = get_count_order(DP_CONF_GET_PIN_ASSIGN(dp->data.conf));
+   conf = TYPEC_MODAL_STATE(state);
+   } else {
+   conf = TYPEC_STATE_USB;
+   }
 
-   return typec_altmode_notify(dp->alt, TYPEC_MODAL_STATE(state),
-  &dp->data);
+   return typec_altmode_notify(dp->alt, conf, &dp->data);
 }
 
 static int dp_altmode_configure(struct dp_altmode *dp, u8 con)
@@ -137,21 +144,10 @@ static int dp_altmode_status_update(struct dp_altmode *dp)
 
 static int dp_altmode_configured(struct dp_altmode *dp)
 {
-   int ret;
-
sysfs_notify(&dp->alt->dev.kobj, "displayport", "configuration");
-
-   if (!dp->data.conf)
-   return typec_altmode_notify(dp->alt, TYPEC_STATE_USB,
-   &dp->data);
-
-   ret = dp_altmode_notify(dp);
-   if (ret)
-   return ret;
-
sysfs_notify(&dp->alt->dev.kobj, "displayport", "pin_assignment");
 
-   return 0;
+   return dp_altmode_notify(dp);
 }
 
 static int dp_altmode_configure_vdm(struct dp_altmode *dp, u32 conf)
@@ -172,13 +168,8 @@ static int dp_altmode_configure_vdm(struct dp_altmode *dp, 
u32 conf)
}
 
ret = typec_altmode_vdm(dp->alt, header, &conf, 2);
-   if (ret) {
-   if (DP_CONF_GET_PIN_ASSIGN(dp->data.conf))
-   dp_altmode_notify(dp);
-   else
-   typec_altmode_notify(dp->alt, TYPEC_STATE_USB,
-&dp->data);
-   }
+   if (ret)
+   dp_altmode_notify(dp);
 
return ret;
 }
-- 
2.31.1

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

[Intel-gfx] [PATCH 6/8] drm/i915/dp: Add support for out-of-bound hotplug events

[Hans de Goede]

On some Cherry Trail devices, DisplayPort over Type-C is supported through
a USB-PD microcontroller (e.g. a fusb302) + a mux to switch the superspeed
datalines between USB-3 and DP (e.g. a pi3usb30532). The kernel in this
case does the PD/alt-mode negotiation itself, rather then everything being
handled in firmware.

So the kernel itself picks an alt-mode, tells the Type-C "dongle" to switch
to DP mode and sets the mux accordingly. In this setup the HPD pin is not
connected, so the i915 driver needs to respond to a software event and scan
the DP port for changes manually.

This commit adds support for this. Together with the recent addition of
DP alt-mode support to the Type-C subsystem this makes DP over Type-C
work on these devices.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index dfa7da928ae5..554090e6ab7d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4571,6 +4571,17 @@ static int intel_dp_connector_atomic_check(struct 
drm_connector *conn,
return intel_modeset_synced_crtcs(state, conn);
 }
 
+static void intel_dp_oob_hotplug_event(struct drm_connector *connector)
+{
+   struct intel_encoder *encoder = 
intel_attached_encoder(to_intel_connector(connector));
+   struct drm_i915_private *i915 = to_i915(connector->dev);
+
+   spin_lock_irq(&i915->irq_lock);
+   i915->hotplug.event_bits |= BIT(encoder->hpd_pin);
+   spin_unlock_irq(&i915->irq_lock);
+   queue_delayed_work(system_wq, &i915->hotplug.hotplug_work, 0);
+}
+
 static const struct drm_connector_funcs intel_dp_connector_funcs = {
.force = intel_dp_force,
.fill_modes = drm_helper_probe_single_connector_modes,
@@ -4581,6 +4592,7 @@ static const struct drm_connector_funcs 
intel_dp_connector_funcs = {
.destroy = intel_connector_destroy,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.atomic_duplicate_state = intel_digital_connector_duplicate_state,
+   .oob_hotplug_event = intel_dp_oob_hotplug_event,
 };
 
 static const struct drm_connector_helper_funcs intel_dp_connector_helper_funcs 
= {
-- 
2.31.1

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

[Intel-gfx] [PATCH 5/8] drm/i915: Associate ACPI connector nodes with connector entries (v2)

[Hans de Goede]

From: Heikki Krogerus 

On Intel platforms we know that the ACPI connector device
node order will follow the order the driver (i915) decides.
The decision is made using the custom Intel ACPI OpRegion
(intel_opregion.c), though the driver does not actually know
that the values it sends to ACPI there are used for
associating a device node for the connectors, and assigning
address for them.

In reality that custom Intel ACPI OpRegion actually violates
ACPI specification (we supply dynamic information to objects
that are defined static, for example _ADR), however, it
makes assigning correct connector node for a connector entry
straightforward (it's one-on-one mapping).

Changes in v2 (Hans de goede):
- Take a reference on the fwnode which we assign to the connector,
  for ACPI nodes this is a no-op but in the future we may see
  software-fwnodes assigned to connectors which are ref-counted.

Signed-off-by: Heikki Krogerus 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/intel_acpi.c| 46 
 drivers/gpu/drm/i915/display/intel_acpi.h|  3 ++
 drivers/gpu/drm/i915/display/intel_display.c |  1 +
 3 files changed, 50 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c 
b/drivers/gpu/drm/i915/display/intel_acpi.c
index 833d0c1be4f1..37077b19cf58 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.c
+++ b/drivers/gpu/drm/i915/display/intel_acpi.c
@@ -263,3 +263,49 @@ void intel_acpi_device_id_update(struct drm_i915_private 
*dev_priv)
}
drm_connector_list_iter_end(&conn_iter);
 }
+
+/* NOTE: The connector order must be final before this is called. */
+void intel_acpi_assign_connector_fwnodes(struct drm_i915_private *i915)
+{
+   struct drm_connector_list_iter conn_iter;
+   struct drm_device *drm_dev = &i915->drm;
+   struct fwnode_handle *fwnode = NULL;
+   struct drm_connector *connector;
+   struct acpi_device *adev;
+
+   drm_connector_list_iter_begin(drm_dev, &conn_iter);
+   drm_for_each_connector_iter(connector, &conn_iter) {
+   /* Always getting the next, even when the last was not used. */
+   fwnode = device_get_next_child_node(drm_dev->dev, fwnode);
+   if (!fwnode)
+   break;
+
+   switch (connector->connector_type) {
+   case DRM_MODE_CONNECTOR_LVDS:
+   case DRM_MODE_CONNECTOR_eDP:
+   case DRM_MODE_CONNECTOR_DSI:
+   /*
+* Integrated displays have a specific address 0x1f on
+* most Intel platforms, but not on all of them.
+*/
+   adev = 
acpi_find_child_device(ACPI_COMPANION(drm_dev->dev),
+ 0x1f, 0);
+   if (adev) {
+   connector->fwnode =
+   
fwnode_handle_get(acpi_fwnode_handle(adev));
+   break;
+   }
+   fallthrough;
+   default:
+   connector->fwnode = fwnode_handle_get(fwnode);
+   break;
+   }
+   }
+   drm_connector_list_iter_end(&conn_iter);
+   /*
+* device_get_next_child_node() takes a reference on the fwnode, if
+* we stopped iterating because we are out of connectors we need to
+* put this, otherwise fwnode is NULL and the put is a no-op.
+*/
+   fwnode_handle_put(fwnode);
+}
diff --git a/drivers/gpu/drm/i915/display/intel_acpi.h 
b/drivers/gpu/drm/i915/display/intel_acpi.h
index e8b068661d22..d2435691f4b5 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.h
+++ b/drivers/gpu/drm/i915/display/intel_acpi.h
@@ -12,11 +12,14 @@ struct drm_i915_private;
 void intel_register_dsm_handler(void);
 void intel_unregister_dsm_handler(void);
 void intel_acpi_device_id_update(struct drm_i915_private *i915);
+void intel_acpi_assign_connector_fwnodes(struct drm_i915_private *i915);
 #else
 static inline void intel_register_dsm_handler(void) { return; }
 static inline void intel_unregister_dsm_handler(void) { return; }
 static inline
 void intel_acpi_device_id_update(struct drm_i915_private *i915) { return; }
+static inline
+void intel_acpi_assign_connector_fwnodes(struct drm_i915_private *i915) { 
return; }
 #endif /* CONFIG_ACPI */
 
 #endif /* __INTEL_ACPI_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index f8320ab7592e..5294eb25c623 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11912,6 +11912,7 @@ int intel_modeset_init_nogem(struct drm_i915_private 
*i915)
 
drm_modeset_lock_all(dev);
intel_modeset_setup_hw_state(dev, dev->mode_config.acquire_ctx);
+   intel_acpi_assign_connector_fwnodes(i915);
drm_modeset_unlock

[Intel-gfx] [PATCH 3/8] drm/connector: Add drm_connector_find_by_fwnode() function (v2)

[Hans de Goede]

Add a function to find a connector based on a fwnode.

This will be used by the new drm_connector_oob_hotplug_event()
function which is added by the next patch in this patch-set.

Changes in v2:
- Complete rewrite to use a global connector list in drm_connector.c
  rather then using a class-dev-iter in drm_sysfs.c

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_connector.c | 50 +
 drivers/gpu/drm/drm_crtc_internal.h |  1 +
 include/drm/drm_connector.h |  8 +
 3 files changed, 59 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 6b5b4762c434..70aa50ea7b8b 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -65,6 +65,14 @@
  * support can instead use e.g. drm_helper_hpd_irq_event().
  */
 
+/*
+ * Global connector list for drm_connector_find_by_fwnode().
+ * Note drm_connector_[un]register() first take connector->lock and then
+ * take the connector_list_lock.
+ */
+static DEFINE_MUTEX(connector_list_lock);
+static LIST_HEAD(connector_list);
+
 struct drm_conn_prop_enum_list {
int type;
const char *name;
@@ -267,6 +275,7 @@ int drm_connector_init(struct drm_device *dev,
goto out_put_type_id;
}
 
+   INIT_LIST_HEAD(&connector->global_connector_list_entry);
INIT_LIST_HEAD(&connector->probed_modes);
INIT_LIST_HEAD(&connector->modes);
mutex_init(&connector->mutex);
@@ -534,6 +543,9 @@ int drm_connector_register(struct drm_connector *connector)
/* Let userspace know we have a new connector */
drm_sysfs_hotplug_event(connector->dev);
 
+   mutex_lock(&connector_list_lock);
+   list_add_tail(&connector->global_connector_list_entry, &connector_list);
+   mutex_unlock(&connector_list_lock);
goto unlock;
 
 err_debugfs:
@@ -562,6 +574,10 @@ void drm_connector_unregister(struct drm_connector 
*connector)
return;
}
 
+   mutex_lock(&connector_list_lock);
+   list_del_init(&connector->global_connector_list_entry);
+   mutex_unlock(&connector_list_lock);
+
if (connector->funcs->early_unregister)
connector->funcs->early_unregister(connector);
 
@@ -2473,6 +2489,40 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
return ret;
 }
 
+/**
+ * drm_connector_find_by_fwnode - Find a connector based on the associated 
fwnode
+ * @fwnode: fwnode for which to find the matching drm_connector
+ *
+ * This functions looks up a drm_connector based on its associated fwnode. When
+ * a connector is found a reference to the connector is returned. The caller 
must
+ * call drm_connector_put() to release this reference when it is done with the
+ * connector.
+ *
+ * Returns: A reference to the found connector or an ERR_PTR().
+ */
+struct drm_connector *drm_connector_find_by_fwnode(struct fwnode_handle 
*fwnode)
+{
+   struct drm_connector *connector, *found = ERR_PTR(-ENODEV);
+
+   if (!fwnode)
+   return ERR_PTR(-ENODEV);
+
+   mutex_lock(&connector_list_lock);
+
+   list_for_each_entry(connector, &connector_list, 
global_connector_list_entry) {
+   if (connector->fwnode == fwnode ||
+   (connector->fwnode && connector->fwnode->secondary == 
fwnode)) {
+   drm_connector_get(connector);
+   found = connector;
+   break;
+   }
+   }
+
+   mutex_unlock(&connector_list_lock);
+
+   return found;
+}
+
 
 /**
  * DOC: Tile group
diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
b/drivers/gpu/drm/drm_crtc_internal.h
index 54d4cf1233e9..6e28fc00a740 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -185,6 +185,7 @@ int drm_connector_set_obj_prop(struct drm_mode_object *obj,
 int drm_connector_create_standard_properties(struct drm_device *dev);
 const char *drm_get_connector_force_name(enum drm_connector_force force);
 void drm_connector_free_work_fn(struct work_struct *work);
+struct drm_connector *drm_connector_find_by_fwnode(struct fwnode_handle 
*fwnode);
 
 /* IOCTL */
 int drm_connector_property_set_ioctl(struct drm_device *dev,
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 2c4cbc686a22..8ae5dbe3d4ae 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1242,6 +1242,14 @@ struct drm_connector {
 */
struct list_head head;
 
+   /**
+* @global_connector_list_entry:
+*
+* Connector entry in the global connector-list, used by
+* drm_connector_find_by_fwnode().
+*/
+   struct list_head global_connector_list_entry;
+
/** @base: base KMS object */
struct drm_mode_object base;
 
-- 
2.31.1

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

[Intel-gfx] [PATCH 2/8] drm/connector: Add a fwnode pointer to drm_connector and register with ACPI (v2)

[Hans de Goede]

Add a fwnode pointer to struct drm_connector and register an acpi_bus_type
for the connectors with the ACPI subsystem (when CONFIG_ACPI is enabled).

The adding of the fwnode pointer allows drivers to associate a fwnode
that represents a connector with that connector.

When the new fwnode pointer points to an ACPI-companion, then the new
acpi_bus_type will cause the ACPI subsys to bind the device instantiated
for the connector with the fwnode by calling acpi_bind_one(). This will
result in a firmware_node symlink under /sys/class/card#-/
which helps to verify that the fwnode-s and connectors are properly
matched.

Changes in v2:
- Make drm_connector_cleanup() call fwnode_handle_put() on
  connector->fwnode and document this

Co-developed-by: Heikki Krogerus 
Signed-off-by: Heikki Krogerus 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_connector.c |  2 ++
 drivers/gpu/drm/drm_sysfs.c | 37 +
 include/drm/drm_connector.h |  8 +++
 3 files changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 9de145351546..6b5b4762c434 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -474,6 +474,8 @@ void drm_connector_cleanup(struct drm_connector *connector)
drm_mode_object_unregister(dev, &connector->base);
kfree(connector->name);
connector->name = NULL;
+   fwnode_handle_put(connector->fwnode);
+   connector->fwnode = NULL;
spin_lock_irq(&dev->mode_config.connector_list_lock);
list_del(&connector->head);
dev->mode_config.num_connector--;
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index f9d92bbb1f98..bf9edce8e2d1 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -10,6 +10,7 @@
  * Copyright (c) 2003-2004 IBM Corp.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -56,6 +57,39 @@ static struct device_type drm_sysfs_device_connector = {
 
 struct class *drm_class;
 
+#ifdef CONFIG_ACPI
+static bool drm_connector_acpi_bus_match(struct device *dev)
+{
+   return dev->type == &drm_sysfs_device_connector;
+}
+
+static struct acpi_device *drm_connector_acpi_find_companion(struct device 
*dev)
+{
+   struct drm_connector *connector = to_drm_connector(dev);
+
+   return to_acpi_device_node(connector->fwnode);
+}
+
+static struct acpi_bus_type drm_connector_acpi_bus = {
+   .name = "drm_connector",
+   .match = drm_connector_acpi_bus_match,
+   .find_companion = drm_connector_acpi_find_companion,
+};
+
+static void drm_sysfs_acpi_register(void)
+{
+   register_acpi_bus_type(&drm_connector_acpi_bus);
+}
+
+static void drm_sysfs_acpi_unregister(void)
+{
+   unregister_acpi_bus_type(&drm_connector_acpi_bus);
+}
+#else
+static void drm_sysfs_acpi_register(void) { }
+static void drm_sysfs_acpi_unregister(void) { }
+#endif
+
 static char *drm_devnode(struct device *dev, umode_t *mode)
 {
return kasprintf(GFP_KERNEL, "dri/%s", dev_name(dev));
@@ -89,6 +123,8 @@ int drm_sysfs_init(void)
}
 
drm_class->devnode = drm_devnode;
+
+   drm_sysfs_acpi_register();
return 0;
 }
 
@@ -101,6 +137,7 @@ void drm_sysfs_destroy(void)
 {
if (IS_ERR_OR_NULL(drm_class))
return;
+   drm_sysfs_acpi_unregister();
class_remove_file(drm_class, &class_attr_version.attr);
class_destroy(drm_class);
drm_class = NULL;
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 1922b278ffad..2c4cbc686a22 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1223,6 +1223,14 @@ struct drm_connector {
struct device *kdev;
/** @attr: sysfs attributes */
struct device_attribute *attr;
+   /**
+* @fwnode: associated fwnode supplied by platform firmware
+*
+* Drivers can set this to associate a fwnode with a connector, drivers
+* are expected to get a reference on the fwnode when setting this.
+* drm_connector_cleanup() will call fwnode_handle_put() on this.
+*/
+   struct fwnode_handle *fwnode;
 
/**
 * @head:
-- 
2.31.1

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

[Intel-gfx] [PATCH 1/8] drm/connector: Give connector sysfs devices there own device_type

[Hans de Goede]

Give connector sysfs devices there own device_type, this allows us to
check if a device passed to functions dealing with generic devices is
a drm_connector or not.

A check like this is necessary in the drm_connector_acpi_bus_match()
function added in the next patch in this series.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_sysfs.c | 50 +++--
 1 file changed, 37 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 968a9560b4aa..f9d92bbb1f98 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -50,6 +50,10 @@ static struct device_type drm_sysfs_device_minor = {
.name = "drm_minor"
 };
 
+static struct device_type drm_sysfs_device_connector = {
+   .name = "drm_connector",
+};
+
 struct class *drm_class;
 
 static char *drm_devnode(struct device *dev, umode_t *mode)
@@ -102,6 +106,11 @@ void drm_sysfs_destroy(void)
drm_class = NULL;
 }
 
+static void drm_sysfs_release(struct device *dev)
+{
+   kfree(dev);
+}
+
 /*
  * Connector properties
  */
@@ -273,27 +282,47 @@ static const struct attribute_group 
*connector_dev_groups[] = {
 int drm_sysfs_connector_add(struct drm_connector *connector)
 {
struct drm_device *dev = connector->dev;
+   struct device *kdev;
+   int r;
 
if (connector->kdev)
return 0;
 
-   connector->kdev =
-   device_create_with_groups(drm_class, dev->primary->kdev, 0,
- connector, connector_dev_groups,
- "card%d-%s", dev->primary->index,
- connector->name);
+   kdev = kzalloc(sizeof(*kdev), GFP_KERNEL);
+   if (!kdev)
+   return -ENOMEM;
+
+   device_initialize(kdev);
+   kdev->class = drm_class;
+   kdev->type = &drm_sysfs_device_connector;
+   kdev->parent = dev->primary->kdev;
+   kdev->groups = connector_dev_groups;
+   kdev->release = drm_sysfs_release;
+   dev_set_drvdata(kdev, connector);
+
+   r = dev_set_name(kdev, "card%d-%s", dev->primary->index, 
connector->name);
+   if (r)
+   goto err_free;
+
DRM_DEBUG("adding \"%s\" to sysfs\n",
  connector->name);
 
-   if (IS_ERR(connector->kdev)) {
-   DRM_ERROR("failed to register connector device: %ld\n", 
PTR_ERR(connector->kdev));
-   return PTR_ERR(connector->kdev);
+   r = device_add(kdev);
+   if (r) {
+   DRM_ERROR("failed to register connector device: %d\n", r);
+   goto err_free;
}
 
+   connector->kdev = kdev;
+
if (connector->ddc)
return sysfs_create_link(&connector->kdev->kobj,
 &connector->ddc->dev.kobj, "ddc");
return 0;
+
+err_free:
+   put_device(kdev);
+   return r;
 }
 
 void drm_sysfs_connector_remove(struct drm_connector *connector)
@@ -374,11 +403,6 @@ void drm_sysfs_connector_status_event(struct drm_connector 
*connector,
 }
 EXPORT_SYMBOL(drm_sysfs_connector_status_event);
 
-static void drm_sysfs_release(struct device *dev)
-{
-   kfree(dev);
-}
-
 struct device *drm_sysfs_minor_alloc(struct drm_minor *minor)
 {
const char *minor_str;
-- 
2.31.1

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

[Intel-gfx] [PATCH 0/8] drm + usb-type-c: Add support for out-of-band hotplug notification (v3)

[Hans de Goede]

Hi All,

Here is v3 of my patchset making DP over Type-C work on devices where the
Type-C controller does not drive the HPD pin on the GPU, but instead
we need to forward HPD events from the Type-C controller to the DRM driver.

Changes in v3:
- Base on top of latest drm-tip, which should fix the CI being unable to
  apply (and thus to test) the patches
- Make intel_acpi_assign_connector_fwnodes() take a ref on the fwnode
  it stores in connector->fwnode and have drm_connector_cleanup() put
  this reference
- Drop data argument from drm_connector_oob_hotplug_event()
- Make the Type-C DP altmode code only call drm_connector_oob_hotplug_event()
  when the HPD bit in the status vdo changes
- Drop the platform/x86/intel_cht_int33fe: Correct "displayport" fwnode
  reference patch, this will be merged independently through the pdx86 tree

Changes in v2:
- Replace the bogus "drm/connector: Make the drm_sysfs connector->kdev
  device hold a reference to the connector" patch with:
  "drm/connector: Give connector sysfs devices there own device_type"
  the new patch is a dep for patch 2/9 see the patches

- Stop using a class-dev-iter, instead at a global connector list
  to drm_connector.c and use that to find the connector by the fwnode,
  similar to how we already do this in drm_panel.c and drm_bridge.c

- Make drm_connector_oob_hotplug_event() take a fwnode pointer as
  argument, rather then a drm_connector pointer and let it do the
  lookup itself. This allows making drm_connector_find_by_fwnode() a
  drm-internal function and avoids code outside the drm subsystem
  potentially holding on the a drm_connector reference for a longer
  period.

This series not only touches drm subsys files but it also touches
drivers/usb/typec/altmodes/typec_displayport.c, that file usually
does not see a whole lot of changes. So I believe it would be best
to just merge the entire series through drm-misc, Assuming we can
get an ack from Greg for merging the typec_displayport.c changes
this way.

Regards,

Hans


Hans de Goede (7):
  drm/connector: Give connector sysfs devices there own device_type
  drm/connector: Add a fwnode pointer to drm_connector and register with
ACPI (v2)
  drm/connector: Add drm_connector_find_by_fwnode() function (v2)
  drm/connector: Add support for out-of-band hotplug notification (v3)
  drm/i915/dp: Add support for out-of-bound hotplug events
  usb: typec: altmodes/displayport: Make dp_altmode_notify() more
generic
  usb: typec: altmodes/displayport: Notify drm subsys of hotplug events

Heikki Krogerus (1):
  drm/i915: Associate ACPI connector nodes with connector entries (v2)

 drivers/gpu/drm/drm_connector.c  | 79 ++
 drivers/gpu/drm/drm_crtc_internal.h  |  1 +
 drivers/gpu/drm/drm_sysfs.c  | 87 +---
 drivers/gpu/drm/i915/display/intel_acpi.c| 46 +++
 drivers/gpu/drm/i915/display/intel_acpi.h|  3 +
 drivers/gpu/drm/i915/display/intel_display.c |  1 +
 drivers/gpu/drm/i915/display/intel_dp.c  | 12 +++
 drivers/usb/typec/altmodes/Kconfig   |  1 +
 drivers/usb/typec/altmodes/displayport.c | 58 -
 include/drm/drm_connector.h  | 25 ++
 10 files changed, 278 insertions(+), 35 deletions(-)

-- 
2.31.1

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

Re: [Intel-gfx] Enabling sample_c optimization for Broadwell GPUs

[Kenneth Graunke]

Hello,

Yes, that bit only exists on Haswell.  On Haswell, sample_c operations
were processed at 1 pixel/clock unless you set that bit, in which case
they get processed at 4 pixels/clock.  The downside is that it breaks
some obscure media feature that apparently no one used.

Broadwell and later alway process sample_c operations at the fast speed,
and there is no bit to control it.  I would say that downstream patch is
incorrect.

--Ken

On Tuesday, May 4, 2021 4:07:14 PM PDT André Almeida wrote:
> Hi there,
> 
> While browsing an old downstream kernel, I found a patch[0] that enables 
> sample_c optimizations at Broadwell GPUs. The message from the upstream 
> commit that enables it for Haswell[1] (and presumably where the code 
> at[0] was copied from) states that "[..] later platforms remove this 
> bit, and apparently always enable the optimization".
> 
> Could you confirm that Broadwell and following architectures enable this 
> optimization by default (and thus, patch[0] is a no-op), or should I 
> upstream it?
> 
> Thanks,
>   André
> 
> [0] 
> https://github.com/ValveSoftware/steamos_kernel/commit/198990f13e1d9429864c177d9441a6559771c5e2
> 
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=944115934436b1ff6cf773a9e9123858ea9ef3da
> 



signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t v3] lib/i915/perf: Fix non-card0 processing

[Janusz Krzysztofik]

IGT i915/perf library functions now always operate on sysfs perf
attributes of card0 device node, no matter which DRM device fd a user
passes.  The intention was to always switch to primary device node if
a user passes a render device node fd, but that breaks handling of
non-card0 devices.

If a user passed a render device node fd, find a primary device node of
the same device and use it instead of forcibly using the primary device
with minor number 0 when opening the device sysfs area.

v2: Don't assume primary minor matches render minor with masked type.
v3: Reset sysfs dir fd if no match, consequently spell out error paths,
add a comment on convertion of renderD* to cardX (Lionel).

Signed-off-by: Janusz Krzysztofik 
Reviewed-by: Lionel Landwerlin 
---
 lib/i915/perf.c | 35 ---
 1 file changed, 32 insertions(+), 3 deletions(-)

diff --git a/lib/i915/perf.c b/lib/i915/perf.c
index 56d5c0b3a..b9e10519e 100644
--- a/lib/i915/perf.c
+++ b/lib/i915/perf.c
@@ -372,14 +372,43 @@ open_master_sysfs_dir(int drm_fd)
 {
char path[128];
struct stat st;
+   int sysfs;
 
if (fstat(drm_fd, &st) || !S_ISCHR(st.st_mode))
 return -1;
 
-snprintf(path, sizeof(path), "/sys/dev/char/%d:0",
- major(st.st_rdev));
+   snprintf(path, sizeof(path), "/sys/dev/char/%d:%d", major(st.st_rdev), 
minor(st.st_rdev));
+   sysfs = open(path, O_DIRECTORY);
+   if (sysfs < 0)
+   return sysfs;
 
-   return open(path, O_DIRECTORY);
+   if (minor(st.st_rdev) >= 128) {
+   /* If we were given a renderD* drm_fd, find it's associated 
cardX node. */
+   char device[100], cmp[100];
+   int device_len, cmp_len, i;
+
+   device_len = readlinkat(sysfs, "device", device, 
sizeof(device));
+   close(sysfs);
+   if (device_len < 0)
+   return device_len;
+
+   for (i = 0; i < 128; i++) {
+
+   snprintf(path, sizeof(path), "/sys/dev/char/%d:%d", 
major(st.st_rdev), i);
+   sysfs = open(path, O_DIRECTORY);
+   if (sysfs < 0)
+   continue;
+
+   cmp_len = readlinkat(sysfs, "device", cmp, sizeof(cmp));
+   if (cmp_len == device_len && !memcmp(cmp, device, 
cmp_len))
+   break;
+
+   close(sysfs);
+   sysfs = -1;
+   }
+   }
+
+   return sysfs;
 }
 
 struct intel_perf *
-- 
2.25.1

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

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/display Try YCbCr420 color when RGB fails

[Patchwork]

== Series Details ==

Series: drm/i915/display Try YCbCr420 color when RGB fails
URL   : https://patchwork.freedesktop.org/series/89808/
State : failure

== Summary ==

Applying: New function to avoid duplicate code in upcomming commits
error: unrecognized input
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 New function to avoid duplicate code in upcomming commits
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


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

Re: [Intel-gfx] [PATCH] i915: Increase *_latency array size

[Ville Syrjälä]

On Wed, May 05, 2021 at 07:18:30AM -0700, Andi Kleen wrote:
> > > Increase all the latency fields to 8 members, which is enough for SKL.
> > >
> > > I don't know if they are correctly initialized upto 8, but dev_priv
> > > should start out as zero, so presumably they will be zero.
> > 
> > Thanks, the warning should be fixed by commit
> > 
> > c6deb5e97ded ("drm/i915/pm: Make the wm parameter of print_wm_latency a 
> > pointer")
> > 
> > in drm-intel-next.
> 
> That's just hiding the problem.
> 
> > 
> > There doesn't actually seem to be a bug here,
> 
> Can you explain that please?
> 
> This is the loop in question
> 
>  max_level = ilk_wm_max_level(dev_priv);
> 
> for (level = 0; level <= max_level; level++) {
> unsigned int latency = wm[level];
> 
> if (latency == 0) {
> drm_dbg_kms(&dev_priv->drm,
> "%s WM%d latency not provided\n",
> name, level);
> continue;
> }
> 
>   ...
>   }
> 
> (no other loop termination condition)
> 
> and ilk_wm_max_level is
> 
> int ilk_wm_max_level(const struct drm_i915_private *dev_priv)
> {
> /* how many WM levels are we expecting */
> if (INTEL_GEN(dev_priv) >= 9)
> return 7;
> else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> return 4;
> else if (INTEL_GEN(dev_priv) >= 6)
> return 3;
> else
> return 2;
> }
> 
> There is no loop termination in the loop above, it will always read
> every member through the max level reported. And on GEN>=9 it will be 7, while
> the input array for several of the cases has only 5 members.
> 
> So it will read beyond the array and gcc is correct in complaining.
> 
> What do I miss when you say there is no bug?

We always use dev_priv->wm.skl_latency[] for gen9+. See
{pri,spr,cur}_wm_latency_show(), skl_setup_wm_latency(), etc.

-- 
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] i915: Increase *_latency array size

[Andi Kleen]

> > Increase all the latency fields to 8 members, which is enough for SKL.
> >
> > I don't know if they are correctly initialized upto 8, but dev_priv
> > should start out as zero, so presumably they will be zero.
> 
> Thanks, the warning should be fixed by commit
> 
> c6deb5e97ded ("drm/i915/pm: Make the wm parameter of print_wm_latency a 
> pointer")
> 
> in drm-intel-next.

That's just hiding the problem.

> 
> There doesn't actually seem to be a bug here,

Can you explain that please?

This is the loop in question

 max_level = ilk_wm_max_level(dev_priv);

for (level = 0; level <= max_level; level++) {
unsigned int latency = wm[level];

if (latency == 0) {
drm_dbg_kms(&dev_priv->drm,
"%s WM%d latency not provided\n",
name, level);
continue;
}

...
}

(no other loop termination condition)

and ilk_wm_max_level is

int ilk_wm_max_level(const struct drm_i915_private *dev_priv)
{
/* how many WM levels are we expecting */
if (INTEL_GEN(dev_priv) >= 9)
return 7;
else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
return 4;
else if (INTEL_GEN(dev_priv) >= 6)
return 3;
else
return 2;
}

There is no loop termination in the loop above, it will always read
every member through the max level reported. And on GEN>=9 it will be 7, while
the input array for several of the cases has only 5 members.

So it will read beyond the array and gcc is correct in complaining.

What do I miss when you say there is no bug?

-Andi

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

[Intel-gfx] [PATCH 3/3] Use YCbCr420 as fallback when RGB fails

[Werner Sembach]

When encoder validation of a display mode fails, retry with less bandwidth
heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
to support 4k60Hz output, which previously failed silently.

AMDGPU had nearly the exact same issue. This problem description is
therefore copied from my commit message of the AMDGPU patch.

On some setups, while the monitor and the gpu support display modes with
pixel clocks of up to 600MHz, the link encoder might not. This prevents
YCbCr444 and RGB encoding for 4k60Hz, but YCbCr420 encoding might still be
possible. However, which color mode is used is decided before the link
encoder capabilities are checked. This patch fixes the problem by retrying
to find a display mode with YCbCr420 enforced and using it, if it is
valid.

Signed-off-by: Werner Sembach 
---
I did not include the suggested change at intel_hdmi_mode_valid, because as
far as I can tell it doesn't make a difference.

>From 882afbfd5de6858c01bcef9580305082ce811701 Mon Sep 17 00:00:00 2001
From: Werner Sembach 
Date: Mon, 3 May 2021 16:23:17 +0200
Subject: [PATCH 3/3] Use YCbCr420 as fallback when RGB fails

---
 drivers/gpu/drm/i915/display/intel_hdmi.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 2c3b545d5f24..3770ea00930f 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1913,7 +1913,7 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
clock *= 2;
}
 
-   if (drm_mode_is_420_only(&connector->display_info, mode))
+   if (connector->ycbcr_420_allowed && 
drm_mode_is_420(&connector->display_info, mode))
clock /= 2;
 
status = intel_hdmi_mode_clock_valid(hdmi, clock, has_hdmi_sink);
@@ -2125,6 +2125,14 @@ static int intel_hdmi_compute_output_format(struct 
intel_encoder *encoder,
}
 
ret = intel_hdmi_compute_clock(encoder, crtc_state);
+   if (ret) {
+   if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420 &&
+   connector->ycbcr_420_allowed &&
+   drm_mode_is_420_also(&connector->display_info, 
adjusted_mode)) {
+   crtc_state->output_format = 
INTEL_OUTPUT_FORMAT_YCBCR420;
+   ret = intel_hdmi_compute_clock(encoder, crtc_state);
+   }
+   }
 
return ret;
 }
-- 
2.25.1

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

[Intel-gfx] [PATCH 2/3] Restructure output format computation for better expandability

[Werner Sembach]

Couples the decission between RGB and YCbCr420 mode and the check if the port
clock can archive the required frequency. Other checks and configuration steps
that where previously done in between can also be done before or after.

This allows for are cleaner implementation of retrying different color
encodings.

Slight change in behaviour: If YCbCr420 is not allowed but display is YCbCr420
only it no longer fails, but just prints an error and tries to fallback on RGB.

Signed-off-by: Werner Sembach 
---
Imho an error message in when YCbCR420 not allowed meets YCbCr420 only can be
a usefull bugfinding tool for cases of blackscreen on exotic configurations.

I'm unsure if this should be a warning instead.

>From 50f0f396c3363dc05291d8a0873a9c9f23fa5b4b Mon Sep 17 00:00:00 2001
From: Werner Sembach 
Date: Mon, 3 May 2021 15:30:40 +0200
Subject: [PATCH 2/3] Restructure output format computation for better
 expandability

---
 drivers/gpu/drm/i915/display/intel_hdmi.c | 65 ---
 1 file changed, 34 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 576d3d910d06..2c3b545d5f24 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1999,29 +1999,6 @@ static bool hdmi_deep_color_possible(const struct 
intel_crtc_state *crtc_state,
  INTEL_OUTPUT_FORMAT_YCBCR420);
 }
 
-static int
-intel_hdmi_ycbcr420_config(struct intel_crtc_state *crtc_state,
-  const struct drm_connector_state *conn_state)
-{
-   struct drm_connector *connector = conn_state->connector;
-   struct drm_i915_private *i915 = to_i915(connector->dev);
-   const struct drm_display_mode *adjusted_mode =
-   &crtc_state->hw.adjusted_mode;
-
-   if (!drm_mode_is_420_only(&connector->display_info, adjusted_mode))
-   return 0;
-
-   if (!connector->ycbcr_420_allowed) {
-   drm_err(&i915->drm,
-   "Platform doesn't support YCBCR420 output\n");
-   return -EINVAL;
-   }
-
-   crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
-
-   return intel_pch_panel_fitting(crtc_state, conn_state);
-}
-
 static int intel_hdmi_compute_bpc(struct intel_encoder *encoder,
  struct intel_crtc_state *crtc_state,
  int clock)
@@ -2128,6 +2105,30 @@ static bool intel_hdmi_has_audio(struct intel_encoder 
*encoder,
return intel_conn_state->force_audio == HDMI_AUDIO_ON;
 }
 
+static int intel_hdmi_compute_output_format(struct intel_encoder *encoder,
+struct intel_crtc_state *crtc_state,
+const struct drm_connector_state 
*conn_state)
+{
+   struct drm_connector *connector = conn_state->connector;
+   struct drm_i915_private *i915 = to_i915(connector->dev);
+   const struct drm_display_mode *adjusted_mode = 
&crtc_state->hw.adjusted_mode;
+   int ret;
+   bool ycbcr_420_only;
+
+   ycbcr_420_only = drm_mode_is_420_only(&connector->display_info, 
adjusted_mode);
+   if (connector->ycbcr_420_allowed && ycbcr_420_only)
+   crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
+   else {
+   if (!connector->ycbcr_420_allowed && ycbcr_420_only)
+   drm_err(&i915->drm, "Display only supports YCbCr420 
output, but connector does not allow it. Fallback to RGB, but this will likely 
fail.\n");
+   crtc_state->output_format = INTEL_OUTPUT_FORMAT_RGB;
+   }
+
+   ret = intel_hdmi_compute_clock(encoder, crtc_state);
+
+   return ret;
+}
+
 int intel_hdmi_compute_config(struct intel_encoder *encoder,
  struct intel_crtc_state *pipe_config,
  struct drm_connector_state *conn_state)
@@ -2152,23 +2153,25 @@ int intel_hdmi_compute_config(struct intel_encoder 
*encoder,
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
pipe_config->pixel_multiplier = 2;
 
-   ret = intel_hdmi_ycbcr420_config(pipe_config, conn_state);
-   if (ret)
-   return ret;
-
-   pipe_config->limited_color_range =
-   intel_hdmi_limited_color_range(pipe_config, conn_state);
-
if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv))
pipe_config->has_pch_encoder = true;
 
pipe_config->has_audio =
intel_hdmi_has_audio(encoder, pipe_config, conn_state);
 
-   ret = intel_hdmi_compute_clock(encoder, pipe_config);
+   ret = intel_hdmi_compute_output_format(encoder, pipe_config, 
conn_state);
if (ret)
return ret;
 
+   if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) {
+   ret = intel_pch_panel_fitting(pipe_config, conn_state);
+   i

[Intel-gfx] [PATCH 1/3] New function to avoid duplicate code in upcomming commits

[Werner Sembach]

Moves some checks that later will be performed 2 times to an own fuction. This
avoids duplicate code later on.

Signed-off-by: Werner Sembach 
---
PS.: I have no idea why git send-email is messing up this timestamp in "From" 
below.

>From 42a4a3a7d9ea9948b4071f406e7fcae23bfa0bdf Mon Sep 17 00:00:00 2001
From: Werner Sembach 
Date: Mon, 3 May 2021 14:35:39 +0200
Subject: [PATCH 1/3] New function to avoid duplicate code in upcomming commits

---
 drivers/gpu/drm/i915/display/intel_hdmi.c | 41 ++-
 1 file changed, 26 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 46de56af33db..576d3d910d06 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1861,6 +1861,31 @@ static int intel_hdmi_port_clock(int clock, int bpc)
return clock * bpc / 8;
 }
 
+static enum drm_mode_status
+intel_hdmi_mode_clock_valid(struct intel_hdmi *hdmi, int clock, bool 
has_hdmi_sink)
+{
+   struct drm_device *dev = intel_hdmi_to_dev(hdmi);
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   enum drm_mode_status status;
+
+   /* check if we can do 8bpc */
+   status = hdmi_port_clock_valid(hdmi, clock, true, has_hdmi_sink);
+
+   if (has_hdmi_sink) {
+   /* if we can't do 8bpc we may still be able to do 12bpc */
+   if (status != MODE_OK && !HAS_GMCH(dev_priv))
+   status = hdmi_port_clock_valid(hdmi, clock * 3 / 2,
+  true, has_hdmi_sink);
+
+   /* if we can't do 8,12bpc we may still be able to do 10bpc */
+   if (status != MODE_OK && INTEL_GEN(dev_priv) >= 11)
+   status = hdmi_port_clock_valid(hdmi, clock * 5 / 4,
+  true, has_hdmi_sink);
+   }
+
+   return status;
+}
+
 static enum drm_mode_status
 intel_hdmi_mode_valid(struct drm_connector *connector,
  struct drm_display_mode *mode)
@@ -1891,21 +1916,7 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
if (drm_mode_is_420_only(&connector->display_info, mode))
clock /= 2;
 
-   /* check if we can do 8bpc */
-   status = hdmi_port_clock_valid(hdmi, intel_hdmi_port_clock(clock, 8),
-  true, has_hdmi_sink);
-
-   if (has_hdmi_sink) {
-   /* if we can't do 8bpc we may still be able to do 12bpc */
-   if (status != MODE_OK && !HAS_GMCH(dev_priv))
-   status = hdmi_port_clock_valid(hdmi, 
intel_hdmi_port_clock(clock, 12),
-  true, has_hdmi_sink);
-
-   /* if we can't do 8,12bpc we may still be able to do 10bpc */
-   if (status != MODE_OK && DISPLAY_VER(dev_priv) >= 11)
-   status = hdmi_port_clock_valid(hdmi, 
intel_hdmi_port_clock(clock, 10),
-  true, has_hdmi_sink);
-   }
+   status = intel_hdmi_mode_clock_valid(hdmi, clock, has_hdmi_sink);
if (status != MODE_OK)
return status;
 
-- 
2.25.1

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

[Intel-gfx] [PATCH 0/4] drm/i915/display Try YCbCr420 color when RGB fails

[Werner Sembach]

When encoder validation of a display mode fails, retry with less bandwidth
heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
to support 4k60Hz output, which previously failed silently.

AMDGPU had nearly the exact same issue. This problem description is
therefore copied from my commit message of the AMDGPU patch.

On some setups, while the monitor and the gpu support display modes with
pixel clocks of up to 600MHz, the link encoder might not. This prevents
YCbCr444 and RGB encoding for 4k60Hz, but YCbCr420 encoding might still be
possible. However, which color mode is used is decided before the link
encoder capabilities are checked. This patch fixes the problem by retrying
to find a display mode with YCbCr420 enforced and using it, if it is
valid.

This patchset is revision 3. I did not (yet) include all suggested changes
as I'm waiting for some clarification. See my last emails.


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

Re: [Intel-gfx] [PATCH 3/4] Restructure output format computation for better expandability

[Ville Syrjälä]

On Wed, May 05, 2021 at 03:02:53PM +0200, Werner Sembach wrote:
> 
> Am 05.05.21 um 14:15 schrieb Ville Syrjälä:
> > On Wed, May 05, 2021 at 11:54:35AM +0200, Werner Sembach wrote:
> >> Am 04.05.21 um 11:54 schrieb Ville Syrjälä:
> >>
> >>> On Mon, May 03, 2021 at 08:21:47PM +0200, Werner Sembach wrote:
>  Couples the decission between RGB and YCbCr420 mode and the check if the 
>  port
>  clock can archive the required frequency. Other checks and configuration 
>  steps
>  that where previously done in between can also be done before or after.
> 
>  This allows for are cleaner implementation of retrying different color
>  encodings.
> 
>  Signed-off-by: Werner Sembach 
>  ---
> 
>  >From 57e42ec6e34ac32da29eb7bc3c691cbeb2534396 Mon Sep 17 00:00:00 2001
>  From: Werner Sembach 
>  Date: Mon, 3 May 2021 15:30:40 +0200
>  Subject: [PATCH 3/4] Restructure output format computation for better
>   expandability
> 
>  ---
>   drivers/gpu/drm/i915/display/intel_hdmi.c | 57 +++
>   1 file changed, 26 insertions(+), 31 deletions(-)
> 
>  diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
>  b/drivers/gpu/drm/i915/display/intel_hdmi.c
>  index ce165ef28e88..e2553ac6fd13 100644
>  --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
>  +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
>  @@ -1999,29 +1999,6 @@ static bool hdmi_deep_color_possible(const struct 
>  intel_crtc_state *crtc_state,
> 
>  INTEL_OUTPUT_FORMAT_YCBCR420);
>   }
>   
>  -static int
>  -intel_hdmi_ycbcr420_config(struct intel_crtc_state *crtc_state,
>  -   const struct drm_connector_state *conn_state)
>  -{
>  -struct drm_connector *connector = conn_state->connector;
>  -struct drm_i915_private *i915 = to_i915(connector->dev);
>  -const struct drm_display_mode *adjusted_mode =
>  -&crtc_state->hw.adjusted_mode;
>  -
>  -if (!drm_mode_is_420_only(&connector->display_info, 
>  adjusted_mode))
>  -return 0;
>  -
>  -if (!connector->ycbcr_420_allowed) {
>  -drm_err(&i915->drm,
>  -"Platform doesn't support YCBCR420 output\n");
>  -return -EINVAL;
>  -}
>  -
>  -crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
>  -
>  -return intel_pch_panel_fitting(crtc_state, conn_state);
>  -}
>  -
>   static int intel_hdmi_compute_bpc(struct intel_encoder *encoder,
> struct intel_crtc_state *crtc_state,
> int clock)
>  @@ -2128,6 +2105,24 @@ static bool intel_hdmi_has_audio(struct 
>  intel_encoder *encoder,
>   return intel_conn_state->force_audio == HDMI_AUDIO_ON;
>   }
>   
>  +int intel_hdmi_compute_output_format(struct intel_encoder *encoder,
>  + struct intel_crtc_state 
>  *crtc_state,
>  + const struct drm_connector_state 
>  *conn_state)
>  +{
>  +const struct drm_connector *connector = conn_state->connector;
>  +const struct drm_display_mode *adjusted_mode = 
>  &crtc_state->hw.adjusted_mode;
>  +int ret;
>  +
>  +if (connector->ycbcr_420_allowed && 
>  drm_mode_is_420_only(&connector->display_info, adjusted_mode))
>  +crtc_state->output_format = 
>  INTEL_OUTPUT_FORMAT_YCBCR420;
>  +else
>  +crtc_state->output_format = INTEL_OUTPUT_FORMAT_RGB;
> >>> Slight change in behaviour here since we used to reject 420_only modes
> >>> if ycbcr_420_allowed wasn't set. But I think this should be OK, and in
> >>> fact I believe the DP counterpart code always used an RGB fallback
> >>> rather than failing. So this lines up better with that.
> >> That was actually an oversight on my side and not intended. Does a RGB 
> >> fallback make sense?
> >>
> >> Now that I think of it get to 2 scenarios:
> >>
> >> - The screen is really 420_only, which causes a silent fail and a black 
> >> screen I guess? Where before at least a log message was written.
> >>
> >> - The screen falsely reports as 420_only and using RGB regardless makes it 
> >> magically work
> >>
> >> I think at least warning should be printed to the logs. Something along 
> >> the lines of: "Display reports as 420 only, but port does not support 420, 
> >> try forcing RGB, but this is likely to fail."
> > I would just put it into the "user has decided to override the mode and
> > gets to keep both pieces if it breaks". Typical users would not hit that
> > since they will only use modes reported by the connector as

Re: [Intel-gfx] [PATCH i-g-t v2] lib/i915/perf: Fix non-card0 processing

[Lionel Landwerlin]

On 05/05/2021 15:41, Janusz Krzysztofik wrote:

IGT i915/perf library functions now always operate on sysfs perf
attributes of card0 device node, no matter which DRM device fd a user
passes.  The intention was to always switch to primary device node if
a user passes a render device node fd, but that breaks handling of
non-card0 devices.

If a user passed a render device node fd, find a primary device node of
the same device and use it instead of forcibly using the primary device
with minor number 0 when opening the device sysfs area.

v2: Don't assume primary minor matches render minor with masked type.

Signed-off-by: Janusz Krzysztofik 
Cc: Lionel Landwerlin 
---
  lib/i915/perf.c | 31 ---
  1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/lib/i915/perf.c b/lib/i915/perf.c
index 56d5c0b3a..d7768468e 100644
--- a/lib/i915/perf.c
+++ b/lib/i915/perf.c
@@ -372,14 +372,39 @@ open_master_sysfs_dir(int drm_fd)
  {
char path[128];
struct stat st;
+   int sysfs;
  
  	if (fstat(drm_fd, &st) || !S_ISCHR(st.st_mode))

  return -1;
  
-snprintf(path, sizeof(path), "/sys/dev/char/%d:0",

- major(st.st_rdev));
+   snprintf(path, sizeof(path), "/sys/dev/char/%d:%d", major(st.st_rdev), 
minor(st.st_rdev));
+   sysfs = open(path, O_DIRECTORY);


Just to spell out the error paths :


if (sysfs < 0)

    return sysfs;


  
-	return open(path, O_DIRECTORY);

+   if (sysfs >= 0 && minor(st.st_rdev) >= 128) {



Then just if (minor(st.st_rdev) >= 128) { ...

Maybe add a comment above this is : /* If we were given a renderD* 
drm_fd, find it's associated cardX node. */




+   char device[100], cmp[100];
+   int device_len, cmp_len, i;
+
+   device_len = readlinkat(sysfs, "device", device, 
sizeof(device));
+   close(sysfs);
+   if (device_len < 0)
+   return device_len;
+
+   for (i = 0; i < 128; i++) {
+
+   snprintf(path, sizeof(path), "/sys/dev/char/%d:%d", 
major(st.st_rdev), i);
+   sysfs = open(path, O_DIRECTORY);
+   if (sysfs < 0)
+   continue;
+
+   cmp_len = readlinkat(sysfs, "device", cmp, sizeof(cmp));
+   if (cmp_len == device_len && !memcmp(cmp, device, 
cmp_len))
+   break;
+
+   close(sysfs);
You might want to set sysfs = -1 here just in the unlikely case this is 
never found.

+   }
+   }
+
+   return sysfs;
  }
  
  struct intel_perf *



With the proposed changes :

Reviewed-by: Lionel Landwerlin 

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

Re: [Intel-gfx] [PATCH 4/4] Use YCbCr420 as fallback when RGB fails

[Werner Sembach]

Am 04.05.21 um 12:08 schrieb Ville Syrjälä:
> On Mon, May 03, 2021 at 08:21:48PM +0200, Werner Sembach wrote:
>> When encoder validation of a display mode fails, retry with less bandwidth
>> heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
>> to support 4k60Hz output, which previously failed silently.
>>
>> AMDGPU had nearly the exact same issue. This problem description is
>> therefore copied from my commit message of the AMDGPU patch.
>>
>> On some setups, while the monitor and the gpu support display modes with
>> pixel clocks of up to 600MHz, the link encoder might not. This prevents
>> YCbCr444 and RGB encoding for 4k60Hz, but YCbCr420 encoding might still be
>> possible. However, which color mode is used is decided before the link
>> encoder capabilities are checked. This patch fixes the problem by retrying
>> to find a display mode with YCbCr420 enforced and using it, if it is
>> valid.
>>
>> Signed-off-by: Werner Sembach 
>> ---
>>
>> >From 4ea0c8839b47e846d46c613e38af475231994f0f Mon Sep 17 00:00:00 2001
>> From: Werner Sembach 
>> Date: Mon, 3 May 2021 16:23:17 +0200
>> Subject: [PATCH 4/4] Use YCbCr420 as fallback when RGB fails
>>
>> ---
>>  drivers/gpu/drm/i915/display/intel_hdmi.c | 10 +-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
>> b/drivers/gpu/drm/i915/display/intel_hdmi.c
>> index e2553ac6fd13..20c800f2ed60 100644
>> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
>> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
>> @@ -1913,7 +1913,7 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
>>  clock *= 2;
>>  }
>>  
>> -if (connector->ycbcr_420_allowed && 
>> drm_mode_is_420_only(&connector->display_info, mode))
>> +if (connector->ycbcr_420_allowed && 
>> drm_mode_is_420(&connector->display_info, mode))
>>  clock /= 2;
> This is too early. We want to keep clock as is for checking whether RGB
> output is possible with 420_also modes.
>
> So the structure you had in your original patch was the correct way to
> go about it. Which I think was something along the lines of:
>
> if (420_only)
>   clock /= 2;
>
> status = intel_hdmi_mode_clock_valid()
> if (status != OK) {
>   if (420_only || !420_also || !420_allowed)
>   return status;
>   
>   clock /= 2;
>   status = intel_hdmi_mode_clock_valid()
> }
Does it make a difference?

In case !420_allowed only rgb is ever tested
In case 420_allowed && 420_only only 420 is ever tested
In case 420_allowed && 420_also the return value of the rgb test is discarded 
anyways
>
>>  
>>  status = intel_hdmi_mode_clock_valid(hdmi, clock, has_hdmi_sink);
>> @@ -2119,6 +2119,14 @@ int intel_hdmi_compute_output_format(struct 
>> intel_encoder *encoder,
>>  crtc_state->output_format = INTEL_OUTPUT_FORMAT_RGB;
>>  
>>  ret = intel_hdmi_compute_clock(encoder, crtc_state);
>> +if (ret) {
>> +if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420 ||
>> +connector->ycbcr_420_allowed ||
>> +drm_mode_is_420_also(&connector->display_info, 
>> adjusted_mode)) {
> That needs s/||/&&/ or we flip the conditions around to:
>
> if (ret) {
>   if (output_format == 420 || !420_allowed || !420_also)
>   return ret;
>
>   output_format = 420;
>   ...
> }
>
> which would have the benefit of avoiding the extra indent level.
>
>> +crtc_state->output_format = 
>> INTEL_OUTPUT_FORMAT_YCBCR420;
>> +ret = intel_hdmi_compute_clock(encoder, crtc_state);
>> +}
>> +}
>>  
>>  return ret;
>>  }
>> -- 
>> 2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/4] Restructure output format computation for better expandability

[Werner Sembach]

Am 05.05.21 um 14:15 schrieb Ville Syrjälä:
> On Wed, May 05, 2021 at 11:54:35AM +0200, Werner Sembach wrote:
>> Am 04.05.21 um 11:54 schrieb Ville Syrjälä:
>>
>>> On Mon, May 03, 2021 at 08:21:47PM +0200, Werner Sembach wrote:
 Couples the decission between RGB and YCbCr420 mode and the check if the 
 port
 clock can archive the required frequency. Other checks and configuration 
 steps
 that where previously done in between can also be done before or after.

 This allows for are cleaner implementation of retrying different color
 encodings.

 Signed-off-by: Werner Sembach 
 ---

 >From 57e42ec6e34ac32da29eb7bc3c691cbeb2534396 Mon Sep 17 00:00:00 2001
 From: Werner Sembach 
 Date: Mon, 3 May 2021 15:30:40 +0200
 Subject: [PATCH 3/4] Restructure output format computation for better
  expandability

 ---
  drivers/gpu/drm/i915/display/intel_hdmi.c | 57 +++
  1 file changed, 26 insertions(+), 31 deletions(-)

 diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
 b/drivers/gpu/drm/i915/display/intel_hdmi.c
 index ce165ef28e88..e2553ac6fd13 100644
 --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
 +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
 @@ -1999,29 +1999,6 @@ static bool hdmi_deep_color_possible(const struct 
 intel_crtc_state *crtc_state,
  INTEL_OUTPUT_FORMAT_YCBCR420);
  }
  
 -static int
 -intel_hdmi_ycbcr420_config(struct intel_crtc_state *crtc_state,
 - const struct drm_connector_state *conn_state)
 -{
 -  struct drm_connector *connector = conn_state->connector;
 -  struct drm_i915_private *i915 = to_i915(connector->dev);
 -  const struct drm_display_mode *adjusted_mode =
 -  &crtc_state->hw.adjusted_mode;
 -
 -  if (!drm_mode_is_420_only(&connector->display_info, adjusted_mode))
 -  return 0;
 -
 -  if (!connector->ycbcr_420_allowed) {
 -  drm_err(&i915->drm,
 -  "Platform doesn't support YCBCR420 output\n");
 -  return -EINVAL;
 -  }
 -
 -  crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
 -
 -  return intel_pch_panel_fitting(crtc_state, conn_state);
 -}
 -
  static int intel_hdmi_compute_bpc(struct intel_encoder *encoder,
  struct intel_crtc_state *crtc_state,
  int clock)
 @@ -2128,6 +2105,24 @@ static bool intel_hdmi_has_audio(struct 
 intel_encoder *encoder,
return intel_conn_state->force_audio == HDMI_AUDIO_ON;
  }
  
 +int intel_hdmi_compute_output_format(struct intel_encoder *encoder,
 +   struct intel_crtc_state *crtc_state,
 +   const struct drm_connector_state 
 *conn_state)
 +{
 +  const struct drm_connector *connector = conn_state->connector;
 +  const struct drm_display_mode *adjusted_mode = 
 &crtc_state->hw.adjusted_mode;
 +  int ret;
 +
 +  if (connector->ycbcr_420_allowed && 
 drm_mode_is_420_only(&connector->display_info, adjusted_mode))
 +  crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
 +  else
 +  crtc_state->output_format = INTEL_OUTPUT_FORMAT_RGB;
>>> Slight change in behaviour here since we used to reject 420_only modes
>>> if ycbcr_420_allowed wasn't set. But I think this should be OK, and in
>>> fact I believe the DP counterpart code always used an RGB fallback
>>> rather than failing. So this lines up better with that.
>> That was actually an oversight on my side and not intended. Does a RGB 
>> fallback make sense?
>>
>> Now that I think of it get to 2 scenarios:
>>
>> - The screen is really 420_only, which causes a silent fail and a black 
>> screen I guess? Where before at least a log message was written.
>>
>> - The screen falsely reports as 420_only and using RGB regardless makes it 
>> magically work
>>
>> I think at least warning should be printed to the logs. Something along the 
>> lines of: "Display reports as 420 only, but port does not support 420, try 
>> forcing RGB, but this is likely to fail."
> I would just put it into the "user has decided to override the mode and
> gets to keep both pieces if it breaks". Typical users would not hit that
> since they will only use modes reported by the connector as supported.
>
> So I think the RGB fallback is totally in line with existing behaviour
> of the driver. We have other cases where we just ignore the reported
> limits of the display if the user overrides the mode manually.
>
Did I get you right that "connector->ycbcr_420_allowed" is a user setting and 
not automatically filled configuration depending on hardware capabilities?
___
Intel-gfx mailing list
Intel-gfx@lists.fr

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Associate ACPI connector nodes with connector entries

[Andy Shevchenko]

On Wed, May 5, 2021 at 1:30 PM Hans de Goede  wrote:
> On 5/5/21 12:02 PM, Andy Shevchenko wrote:

...

> But we do really need to document the behavior better here
> in the kdoc for fwnode_get_next_child_node() and
> device_get_next_child_node().

Totally agree!

> of_get_next_child has this bit, which applies to those too:
>
>  *  Returns a node pointer with refcount incremented, use of_node_put() on
>  *  it when done. Returns NULL when prev is the last child. Decrements the
>  *  refcount of prev.
>
> I'll prepare a patch to add this to the kdoc for fwnode_get_next_child_node()
> and device_get_next_child_node() once I'm done with readying v3 of this 
> series.

Thanks!

-- 
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t v2] lib/i915/perf: Fix non-card0 processing

[Janusz Krzysztofik]

IGT i915/perf library functions now always operate on sysfs perf
attributes of card0 device node, no matter which DRM device fd a user
passes.  The intention was to always switch to primary device node if
a user passes a render device node fd, but that breaks handling of
non-card0 devices.

If a user passed a render device node fd, find a primary device node of
the same device and use it instead of forcibly using the primary device
with minor number 0 when opening the device sysfs area.

v2: Don't assume primary minor matches render minor with masked type.

Signed-off-by: Janusz Krzysztofik 
Cc: Lionel Landwerlin 
---
 lib/i915/perf.c | 31 ---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/lib/i915/perf.c b/lib/i915/perf.c
index 56d5c0b3a..d7768468e 100644
--- a/lib/i915/perf.c
+++ b/lib/i915/perf.c
@@ -372,14 +372,39 @@ open_master_sysfs_dir(int drm_fd)
 {
char path[128];
struct stat st;
+   int sysfs;
 
if (fstat(drm_fd, &st) || !S_ISCHR(st.st_mode))
 return -1;
 
-snprintf(path, sizeof(path), "/sys/dev/char/%d:0",
- major(st.st_rdev));
+   snprintf(path, sizeof(path), "/sys/dev/char/%d:%d", major(st.st_rdev), 
minor(st.st_rdev));
+   sysfs = open(path, O_DIRECTORY);
 
-   return open(path, O_DIRECTORY);
+   if (sysfs >= 0 && minor(st.st_rdev) >= 128) {
+   char device[100], cmp[100];
+   int device_len, cmp_len, i;
+
+   device_len = readlinkat(sysfs, "device", device, 
sizeof(device));
+   close(sysfs);
+   if (device_len < 0)
+   return device_len;
+
+   for (i = 0; i < 128; i++) {
+
+   snprintf(path, sizeof(path), "/sys/dev/char/%d:%d", 
major(st.st_rdev), i);
+   sysfs = open(path, O_DIRECTORY);
+   if (sysfs < 0)
+   continue;
+
+   cmp_len = readlinkat(sysfs, "device", cmp, sizeof(cmp));
+   if (cmp_len == device_len && !memcmp(cmp, device, 
cmp_len))
+   break;
+
+   close(sysfs);
+   }
+   }
+
+   return sysfs;
 }
 
 struct intel_perf *
-- 
2.25.1

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

Re: [Intel-gfx] [PATCH 3/4] Restructure output format computation for better expandability

[Ville Syrjälä]

On Wed, May 05, 2021 at 11:54:35AM +0200, Werner Sembach wrote:
> Am 04.05.21 um 11:54 schrieb Ville Syrjälä:
> 
> > On Mon, May 03, 2021 at 08:21:47PM +0200, Werner Sembach wrote:
> >> Couples the decission between RGB and YCbCr420 mode and the check if the 
> >> port
> >> clock can archive the required frequency. Other checks and configuration 
> >> steps
> >> that where previously done in between can also be done before or after.
> >>
> >> This allows for are cleaner implementation of retrying different color
> >> encodings.
> >>
> >> Signed-off-by: Werner Sembach 
> >> ---
> >>
> >> >From 57e42ec6e34ac32da29eb7bc3c691cbeb2534396 Mon Sep 17 00:00:00 2001
> >> From: Werner Sembach 
> >> Date: Mon, 3 May 2021 15:30:40 +0200
> >> Subject: [PATCH 3/4] Restructure output format computation for better
> >>  expandability
> >>
> >> ---
> >>  drivers/gpu/drm/i915/display/intel_hdmi.c | 57 +++
> >>  1 file changed, 26 insertions(+), 31 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> >> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> >> index ce165ef28e88..e2553ac6fd13 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> >> @@ -1999,29 +1999,6 @@ static bool hdmi_deep_color_possible(const struct 
> >> intel_crtc_state *crtc_state,
> >>  INTEL_OUTPUT_FORMAT_YCBCR420);
> >>  }
> >>  
> >> -static int
> >> -intel_hdmi_ycbcr420_config(struct intel_crtc_state *crtc_state,
> >> - const struct drm_connector_state *conn_state)
> >> -{
> >> -  struct drm_connector *connector = conn_state->connector;
> >> -  struct drm_i915_private *i915 = to_i915(connector->dev);
> >> -  const struct drm_display_mode *adjusted_mode =
> >> -  &crtc_state->hw.adjusted_mode;
> >> -
> >> -  if (!drm_mode_is_420_only(&connector->display_info, adjusted_mode))
> >> -  return 0;
> >> -
> >> -  if (!connector->ycbcr_420_allowed) {
> >> -  drm_err(&i915->drm,
> >> -  "Platform doesn't support YCBCR420 output\n");
> >> -  return -EINVAL;
> >> -  }
> >> -
> >> -  crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
> >> -
> >> -  return intel_pch_panel_fitting(crtc_state, conn_state);
> >> -}
> >> -
> >>  static int intel_hdmi_compute_bpc(struct intel_encoder *encoder,
> >>  struct intel_crtc_state *crtc_state,
> >>  int clock)
> >> @@ -2128,6 +2105,24 @@ static bool intel_hdmi_has_audio(struct 
> >> intel_encoder *encoder,
> >>return intel_conn_state->force_audio == HDMI_AUDIO_ON;
> >>  }
> >>  
> >> +int intel_hdmi_compute_output_format(struct intel_encoder *encoder,
> >> +   struct intel_crtc_state *crtc_state,
> >> +   const struct drm_connector_state 
> >> *conn_state)
> >> +{
> >> +  const struct drm_connector *connector = conn_state->connector;
> >> +  const struct drm_display_mode *adjusted_mode = 
> >> &crtc_state->hw.adjusted_mode;
> >> +  int ret;
> >> +
> >> +  if (connector->ycbcr_420_allowed && 
> >> drm_mode_is_420_only(&connector->display_info, adjusted_mode))
> >> +  crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
> >> +  else
> >> +  crtc_state->output_format = INTEL_OUTPUT_FORMAT_RGB;
> > Slight change in behaviour here since we used to reject 420_only modes
> > if ycbcr_420_allowed wasn't set. But I think this should be OK, and in
> > fact I believe the DP counterpart code always used an RGB fallback
> > rather than failing. So this lines up better with that.
> 
> That was actually an oversight on my side and not intended. Does a RGB 
> fallback make sense?
> 
> Now that I think of it get to 2 scenarios:
> 
> - The screen is really 420_only, which causes a silent fail and a black 
> screen I guess? Where before at least a log message was written.
> 
> - The screen falsely reports as 420_only and using RGB regardless makes it 
> magically work
> 
> I think at least warning should be printed to the logs. Something along the 
> lines of: "Display reports as 420 only, but port does not support 420, try 
> forcing RGB, but this is likely to fail."

I would just put it into the "user has decided to override the mode and
gets to keep both pieces if it breaks". Typical users would not hit that
since they will only use modes reported by the connector as supported.

So I think the RGB fallback is totally in line with existing behaviour
of the driver. We have other cases where we just ignore the reported
limits of the display if the user overrides the mode manually.

-- 
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: drop the __i915_active_call pointer packing (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: drop the __i915_active_call pointer packing (rev2)
URL   : https://patchwork.freedesktop.org/series/89783/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10047_full -> Patchwork_20066_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-glk:  NOTRUN -> [DMESG-WARN][1] ([i915#3002])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20066/shard-glk3/igt@gem_cre...@create-massive.html
- shard-apl:  NOTRUN -> [DMESG-WARN][2] ([i915#3002])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20066/shard-apl6/igt@gem_cre...@create-massive.html

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

  * igt@gem_ctx_persistence@legacy-engines-hostile@render:
- shard-iclb: [PASS][4] -> [FAIL][5] ([i915#2410])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10047/shard-iclb3/igt@gem_ctx_persistence@legacy-engines-host...@render.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20066/shard-iclb2/igt@gem_ctx_persistence@legacy-engines-host...@render.html

  * igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][6] -> [TIMEOUT][7] ([i915#2369] / [i915#2481] 
/ [i915#3070])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10047/shard-iclb1/igt@gem_...@unwedge-stress.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20066/shard-iclb6/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl:  [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10047/shard-kbl4/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20066/shard-kbl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10047/shard-tglb8/igt@gem_exec_fair@basic-p...@vcs1.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20066/shard-tglb6/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk:  [PASS][12] -> [FAIL][13] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10047/shard-glk1/igt@gem_exec_fair@basic-throt...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20066/shard-glk2/igt@gem_exec_fair@basic-throt...@rcs0.html
- shard-iclb: [PASS][14] -> [FAIL][15] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10047/shard-iclb7/igt@gem_exec_fair@basic-throt...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20066/shard-iclb2/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_reloc@basic-wide-active@bcs0:
- shard-apl:  NOTRUN -> [FAIL][16] ([i915#2389]) +3 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20066/shard-apl7/igt@gem_exec_reloc@basic-wide-act...@bcs0.html

  * igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk:  [PASS][17] -> [FAIL][18] ([i915#644])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10047/shard-glk3/igt@gem_pp...@flink-and-close-vma-leak.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20066/shard-glk6/igt@gem_pp...@flink-and-close-vma-leak.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-snb:  NOTRUN -> [WARN][19] ([i915#2658])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20066/shard-snb2/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-apl:  NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#3323])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20066/shard-apl7/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@i915_pm_rpm@modeset-pc8-residency-stress:
- shard-apl:  NOTRUN -> [SKIP][21] ([fdo#109271]) +118 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20066/shard-apl7/igt@i915_pm_...@modeset-pc8-residency-stress.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
- shard-kbl:  [PASS][22] -> [DMESG-WARN][23] ([i915#180]) +2 
similar issues
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10047/shard-kbl3/igt@i915_susp...@fence-restore-tiled2untiled.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20066/shard-kbl7/igt@i915_susp...@fence-restore-tiled2untiled.html

  * igt@kms_big_fb@y-tiled-64bpp-rotate-270:
- shard-glk:  

Re: [Intel-gfx] [PATCH 8/9] usb: typec: altmodes/displayport: Notify drm subsys of hotplug events

[Hans de Goede]

Hi Heikki,

On 5/5/21 12:17 PM, Heikki Krogerus wrote:
> Hi Hans,
> 
> On Mon, May 03, 2021 at 05:46:46PM +0200, Hans de Goede wrote:
>> Use the new drm_connector_find_by_fwnode() and
>> drm_connector_oob_hotplug_event() functions to let drm/kms drivers
>> know about DisplayPort over Type-C hotplug events.
>>
>> Signed-off-by: Hans de Goede 
>> ---
>> Changes in v2:
>> - Add missing depends on DRM to TYPEC_DP_ALTMODE Kconfig entry
>> ---
>>  drivers/usb/typec/altmodes/Kconfig   |  1 +
>>  drivers/usb/typec/altmodes/displayport.c | 40 +++-
>>  2 files changed, 40 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/typec/altmodes/Kconfig 
>> b/drivers/usb/typec/altmodes/Kconfig
>> index 60d375e9c3c7..1a6b5e872b0d 100644
>> --- a/drivers/usb/typec/altmodes/Kconfig
>> +++ b/drivers/usb/typec/altmodes/Kconfig
>> @@ -4,6 +4,7 @@ menu "USB Type-C Alternate Mode drivers"
>>  
>>  config TYPEC_DP_ALTMODE
>>  tristate "DisplayPort Alternate Mode driver"
>> +depends on DRM
>>  help
>>DisplayPort USB Type-C Alternate Mode allows DisplayPort
>>displays and adapters to be attached to the USB Type-C
>> diff --git a/drivers/usb/typec/altmodes/displayport.c 
>> b/drivers/usb/typec/altmodes/displayport.c
>> index aa669b9cf70e..f00dfc5c14b6 100644
>> --- a/drivers/usb/typec/altmodes/displayport.c
>> +++ b/drivers/usb/typec/altmodes/displayport.c
>> @@ -11,8 +11,10 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>> +#include 
>>  #include "displayport.h"
>>  
>>  #define DP_HEADER(_dp, ver, cmd)(VDO((_dp)->alt->svid, 1, ver, cmd) 
>> \
>> @@ -62,12 +64,30 @@ struct dp_altmode {
>>  struct work_struct work;
>>  struct typec_altmode *alt;
>>  const struct typec_altmode *port;
>> +struct fwnode_handle *connector_fwnode;
>>  };
>>  
>> +static void dp_altmode_notify_connector(struct dp_altmode *dp)
>> +{
>> +struct drm_connector_oob_hotplug_event_data data = { };
>> +u8 pin_assign = DP_CONF_GET_PIN_ASSIGN(dp->data.conf);
>> +
>> +data.connected = dp->data.status & DP_STATUS_HPD_STATE;
>> +data.orientation = typec_altmode_get_orientation(dp->alt);
>> +
>> +if (pin_assign & DP_PIN_ASSIGN_DP_ONLY_MASK)
>> +data.dp_lanes = 4;
>> +else if (pin_assign & DP_PIN_ASSIGN_MULTI_FUNC_MASK)
>> +data.dp_lanes = 2;
>> +
>> +drm_connector_oob_hotplug_event(dp->connector_fwnode, &data);
>> +}
>> +
>>  static int dp_altmode_notify(struct dp_altmode *dp)
>>  {
>>  unsigned long conf;
>>  u8 state;
>> +int ret;
>>  
>>  if (dp->data.conf) {
>>  state = get_count_order(DP_CONF_GET_PIN_ASSIGN(dp->data.conf));
>> @@ -76,7 +96,12 @@ static int dp_altmode_notify(struct dp_altmode *dp)
>>  conf = TYPEC_STATE_USB;
>>  }
>>  
>> -return typec_altmode_notify(dp->alt, conf, &dp->data);
>> +ret = typec_altmode_notify(dp->alt, conf, &dp->data);
>> +if (ret)
>> +return ret;
>> +
>> +dp_altmode_notify_connector(dp);
> 
> That is now going to be always called after configuration, right? The
> HPD is not necessarily issued at that point.
> 
> I think that should be called from dp_altmode_status_update(), and
> probable only if there really is HPD IRQ or HPD State changes... I
> think?

I did see this triggering a bit more often then necessary on the initial
plugin of a DP-altmode capable Type-C "dongle", so what you are suggesting
makes sense. I'll come up with a better approach for the next version.

Regards,

Hans

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

Re: [Intel-gfx] [PATCH 4/9] drm/connector: Add support for out-of-band hotplug notification (v2)

[Hans de Goede]

Hi,

On 5/5/21 11:50 AM, Heikki Krogerus wrote:
> On Tue, May 04, 2021 at 05:35:49PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 5/4/21 5:10 PM, Heikki Krogerus wrote:
 +/**
 + * drm_connector_oob_hotplug_event - Report out-of-band hotplug event to 
 connector
 + * @connector: connector to report the event on
 + * @data: data related to the event
 + *
 + * On some hardware a hotplug event notification may come from outside 
 the display
 + * driver / device. An example of this is some USB Type-C setups where 
 the hardware
 + * muxes the DisplayPort data and aux-lines but does not pass the altmode 
 HPD
 + * status bit to the GPU's DP HPD pin.
 + *
 + * This function can be used to report these out-of-band events after 
 obtaining
 + * a drm_connector reference through calling 
 drm_connector_find_by_fwnode().
 + */
 +void drm_connector_oob_hotplug_event(struct fwnode_handle 
 *connector_fwnode,
 +   struct 
 drm_connector_oob_hotplug_event_data *data)
 +{
 +  struct drm_connector *connector;
 +
 +  connector = drm_connector_find_by_fwnode(connector_fwnode);
 +  if (IS_ERR(connector))
 +  return;
 +
 +  if (connector->funcs->oob_hotplug_event)
 +  connector->funcs->oob_hotplug_event(connector, data);
 +
 +  drm_connector_put(connector);
 +}
 +EXPORT_SYMBOL(drm_connector_oob_hotplug_event);
>>>
>>> So it does looks like the "data" parameter is not needed at all:
>>
>> Well Imre did indicate that having the number of lanes is useful, so
>> for the next version I'll drop the orientation but I plan to keep
>> the number of lanes if that is ok with you.
>>
>> Not having passing along this info was one of the reasons why my
>> previous attempt at this was nacked, so dropping it all together
>> feels wrong.
> 
> If you need to pass any information to the function, then you need to
> pass all the information that we have. Don't start with abstraction.
> First create a dedicated API, and then, only if we really have another
> user for it, we can add an abstraction layer that both users can use.
> All cases are going to be different. We don't know how the abstraction
> / generalisation should look like before we have at least two real
> users (ideally more than two, actually). Right now we can not even say
> for sure that generalising the API is even possible.
> 
> I would not make a huge deal out of this unless I wasn't myself being
> told by guys like Greg KH in the past to drop my attempts to
> "generalize" things from the beginning when I only had a single user.
> By doing so you'll not only force all ends, the source of the data
> (the typec drivers in this case) as well as the consumer (i915), to be
> always changed together, it will also confuse things. We are not
> always going to be able to tell the lane count for example like we can
> with USB Type-C, so i915 can't really rely on that information.
> 
> Right now we also don't know what exact details i915 (or what ever GPU
> driver) needs. We can only say for sure that some details are going to
> be needed. Trying to guess and cherry-pick the details now does not
> makes sense because of that reason too.
> 
> So just make this API USB Type-C DP Alt Mode specific API first, and
> supply it everything we have.

Hmm, ok I'll just drop the data argument all together for now (as you
already suggested); and then we can see what is best once an actual user
for the info shows up.

Regards,

Hans

___
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: drop the __i915_active_call pointer packing (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: drop the __i915_active_call pointer packing (rev2)
URL   : https://patchwork.freedesktop.org/series/89783/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10047 -> Patchwork_20066


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@semaphore:
- fi-bsw-nick:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20066/fi-bsw-nick/igt@amdgpu/amd_ba...@semaphore.html

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

  * igt@gem_exec_gttfill@basic:
- fi-bsw-n3050:   NOTRUN -> [SKIP][3] ([fdo#109271])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20066/fi-bsw-n3050/igt@gem_exec_gttf...@basic.html

  * igt@gem_exec_suspend@basic-s3:
- fi-bsw-n3050:   NOTRUN -> [INCOMPLETE][4] ([i915#3159])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20066/fi-bsw-n3050/igt@gem_exec_susp...@basic-s3.html

  
 Possible fixes 

  * igt@i915_pm_rpm@basic-rte:
- {fi-tgl-1115g4}:[DMESG-WARN][5] ([i915#402]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10047/fi-tgl-1115g4/igt@i915_pm_...@basic-rte.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20066/fi-tgl-1115g4/igt@i915_pm_...@basic-rte.html

  * igt@i915_pm_rpm@module-reload:
- {fi-tgl-1115g4}:[DMESG-WARN][7] ([k.org#205379]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10047/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20066/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@late_gt_pm:
- fi-bsw-nick:[DMESG-FAIL][9] ([i915#2927]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10047/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20066/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.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#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
  [i915#2927]: https://gitlab.freedesktop.org/drm/intel/issues/2927
  [i915#3159]: https://gitlab.freedesktop.org/drm/intel/issues/3159
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [k.org#205379]: https://bugzilla.kernel.org/show_bug.cgi?id=205379


Participating hosts (43 -> 40)
--

  Additional (1): fi-bsw-n3050 
  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_10047 -> Patchwork_20066

  CI-20190529: 20190529
  CI_DRM_10047: 6bc6aeb4870cfb28f24523f42157cf9a86be80d7 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6077: 126a3f6fc0e97786e2819085efc84e741093aed5 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_20066: 41c6393f0704d539d4341104591b342650e3f6eb @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

41c6393f0704 drm/i915: drop the __i915_active_call pointer packing

== Logs ==

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

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Associate ACPI connector nodes with connector entries

[Hans de Goede]

Hi,

On 5/5/21 12:02 PM, Andy Shevchenko wrote:
> On Wed, May 5, 2021 at 12:28 PM Hans de Goede  wrote:
>> On 5/5/21 11:17 AM, Andy Shevchenko wrote:
>>> On Wed, May 5, 2021 at 12:07 PM Hans de Goede  wrote:
 On 5/4/21 9:52 AM, Andy Shevchenko wrote:
> On Monday, May 3, 2021, Hans de Goede  > wrote:
>>>
>>> ...
>>>
> +   fwnode = device_get_next_child_node(kdev, fwnode);
>>>
> Who is dropping reference counting on fwnode ?

 We are dealing with ACPI fwnode-s here and those are not ref-counted, they
 are embedded inside a struct acpi_device and their lifetime is tied to
 that struct. They should probably still be ref-counted (with the count
 never dropping to 0) so that the generic fwnode functions behave the same
 anywhere but atm the ACPI nodes are not refcounted, see: 
 acpi_get_next_subnode()
 in drivers/acpi/property.c which is the get_next_child_node() 
 implementation
 for ACPI fwnode-s.
>>>
>>> Yes, ACPI currently is exceptional, but fwnode API is not.
>>> If you may guarantee that this case won't ever be outside of ACPI
>>
>> Yes I can guarantee that currently this code (which is for the i915
>> driver only) only deals with ACPI fwnodes.
>>
>>> and
>>> even though if ACPI won't ever gain a reference counting for fwnodes,
>>> we can leave it as is.
>>
>> Would it not be better to add fake ref-counting to the ACPI fwnode
>> next_child_node() op though. I believe just getting a reference
>> on the return value there should work fine; and then all fwnode
>> implementations would be consistent ?
> 
> But it's already there by absent put/get callbacks.

Ah, I completely missed that the put/get-s are actually done
through function pointers in fwnode_operations. I assumed that there
was a kref embedded inside the fwnode_handle struct and that they
operated directly on that.

So this whole discussion is entirely based on that misunderstanding,
my bad, sorry.

So yes you are right, things are already consistent thanks to the
absent put/get callbacks.

But we do really need to document the behavior better here
in the kdoc for fwnode_get_next_child_node() and
device_get_next_child_node().

of_get_next_child has this bit, which applies to those too:

 *  Returns a node pointer with refcount incremented, use of_node_put() on
 *  it when done. Returns NULL when prev is the last child. Decrements the
 *  refcount of prev.

I'll prepare a patch to add this to the kdoc for fwnode_get_next_child_node()
and device_get_next_child_node() once I'm done with readying v3 of this series.

Regards,

Hans

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

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Associate ACPI connector nodes with connector entries

[Sakari Ailus]

Hi Andy, Hans,

On Wed, May 05, 2021 at 12:17:14PM +0300, Andy Shevchenko wrote:
> On Wed, May 5, 2021 at 12:07 PM Hans de Goede  wrote:
> > On 5/4/21 9:52 AM, Andy Shevchenko wrote:
> > > On Monday, May 3, 2021, Hans de Goede  > > > wrote:
> 
> ...
> 
> > > +   fwnode = device_get_next_child_node(kdev, fwnode);
> 
> > > Who is dropping reference counting on fwnode ?
> >
> > We are dealing with ACPI fwnode-s here and those are not ref-counted, they
> > are embedded inside a struct acpi_device and their lifetime is tied to
> > that struct. They should probably still be ref-counted (with the count
> > never dropping to 0) so that the generic fwnode functions behave the same
> > anywhere but atm the ACPI nodes are not refcounted, see: 
> > acpi_get_next_subnode()
> > in drivers/acpi/property.c which is the get_next_child_node() implementation
> > for ACPI fwnode-s.
> 
> Yes, ACPI currently is exceptional, but fwnode API is not.
> If you may guarantee that this case won't ever be outside of ACPI and
> even though if ACPI won't ever gain a reference counting for fwnodes,
> we can leave it as is.
> 
> > > I’m in the middle of a pile of fixes for fwnode refcounting when
> > > for_each_child or get_next_child is used. So, please double check you
> > > drop a reference.
> >
> > The kdoc comments on device_get_next_child_node() / 
> > fwnode_get_next_child_node()
> > do not mention anything about these functions returning a reference.
> 
> It's possible. I dunno if it had to be done earlier. Sakari?

The fwnode API has worked with references for a long time, looks like from
the very beginning of it, as in patch
8a0662d9ed2968e1186208336a8e1fab3fdfea63 .

If you're expecting an fwnode family of function returning another node,
then that function has to have taken a reference to that node before
returning it. Otherwise there's no guarantee that node is still there when
it is returned.

It may be this is not documented for every function doing so. That should
probably be added.

-- 
Kind regards,

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

Re: [Intel-gfx] [PATCH 8/9] usb: typec: altmodes/displayport: Notify drm subsys of hotplug events

[Heikki Krogerus]

Hi Hans,

On Mon, May 03, 2021 at 05:46:46PM +0200, Hans de Goede wrote:
> Use the new drm_connector_find_by_fwnode() and
> drm_connector_oob_hotplug_event() functions to let drm/kms drivers
> know about DisplayPort over Type-C hotplug events.
> 
> Signed-off-by: Hans de Goede 
> ---
> Changes in v2:
> - Add missing depends on DRM to TYPEC_DP_ALTMODE Kconfig entry
> ---
>  drivers/usb/typec/altmodes/Kconfig   |  1 +
>  drivers/usb/typec/altmodes/displayport.c | 40 +++-
>  2 files changed, 40 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/typec/altmodes/Kconfig 
> b/drivers/usb/typec/altmodes/Kconfig
> index 60d375e9c3c7..1a6b5e872b0d 100644
> --- a/drivers/usb/typec/altmodes/Kconfig
> +++ b/drivers/usb/typec/altmodes/Kconfig
> @@ -4,6 +4,7 @@ menu "USB Type-C Alternate Mode drivers"
>  
>  config TYPEC_DP_ALTMODE
>   tristate "DisplayPort Alternate Mode driver"
> + depends on DRM
>   help
> DisplayPort USB Type-C Alternate Mode allows DisplayPort
> displays and adapters to be attached to the USB Type-C
> diff --git a/drivers/usb/typec/altmodes/displayport.c 
> b/drivers/usb/typec/altmodes/displayport.c
> index aa669b9cf70e..f00dfc5c14b6 100644
> --- a/drivers/usb/typec/altmodes/displayport.c
> +++ b/drivers/usb/typec/altmodes/displayport.c
> @@ -11,8 +11,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  #include "displayport.h"
>  
>  #define DP_HEADER(_dp, ver, cmd) (VDO((_dp)->alt->svid, 1, ver, cmd) 
> \
> @@ -62,12 +64,30 @@ struct dp_altmode {
>   struct work_struct work;
>   struct typec_altmode *alt;
>   const struct typec_altmode *port;
> + struct fwnode_handle *connector_fwnode;
>  };
>  
> +static void dp_altmode_notify_connector(struct dp_altmode *dp)
> +{
> + struct drm_connector_oob_hotplug_event_data data = { };
> + u8 pin_assign = DP_CONF_GET_PIN_ASSIGN(dp->data.conf);
> +
> + data.connected = dp->data.status & DP_STATUS_HPD_STATE;
> + data.orientation = typec_altmode_get_orientation(dp->alt);
> +
> + if (pin_assign & DP_PIN_ASSIGN_DP_ONLY_MASK)
> + data.dp_lanes = 4;
> + else if (pin_assign & DP_PIN_ASSIGN_MULTI_FUNC_MASK)
> + data.dp_lanes = 2;
> +
> + drm_connector_oob_hotplug_event(dp->connector_fwnode, &data);
> +}
> +
>  static int dp_altmode_notify(struct dp_altmode *dp)
>  {
>   unsigned long conf;
>   u8 state;
> + int ret;
>  
>   if (dp->data.conf) {
>   state = get_count_order(DP_CONF_GET_PIN_ASSIGN(dp->data.conf));
> @@ -76,7 +96,12 @@ static int dp_altmode_notify(struct dp_altmode *dp)
>   conf = TYPEC_STATE_USB;
>   }
>  
> - return typec_altmode_notify(dp->alt, conf, &dp->data);
> + ret = typec_altmode_notify(dp->alt, conf, &dp->data);
> + if (ret)
> + return ret;
> +
> + dp_altmode_notify_connector(dp);

That is now going to be always called after configuration, right? The
HPD is not necessarily issued at that point.

I think that should be called from dp_altmode_status_update(), and
probable only if there really is HPD IRQ or HPD State changes... I
think?

> + return 0;
>  }

thanks,

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

Re: [Intel-gfx] [PATCH] drm/i915: drop the __i915_active_call pointer packing

[Daniel Vetter]

On Tue, May 04, 2021 at 05:41:36PM +0100, Matthew Auld wrote:
> We use some of the lower bits of the retire function pointer for
> potential flags, which is quite thorny, since the caller needs to
> remember to give the function the correct alignment with
> __i915_active_call, otherwise we might incorrectly unpack the pointer
> and jump to some garbage address later. Instead of all this let's just
> pass the flags along as a separate parameter.
> 
> Suggested-by: Ville Syrjälä 
> Suggested-by: Daniel Vetter 
> References: ca419f407b43 ("drm/i915: Fix crash in auto_retire")
> References: d8e44e4dd221 ("drm/i915/overlay: Fix active retire callback 
> alignment")
> References: fd5f262db118 ("drm/i915/selftests: Fix active retire callback 
> alignment")
> Signed-off-by: Matthew Auld 

Thanks for doing this quickly.

Acked-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/display/intel_frontbuffer.c   |  4 ++--
>  drivers/gpu/drm/i915/display/intel_overlay.c   |  5 ++---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c|  3 +--
>  drivers/gpu/drm/i915/gt/gen6_ppgtt.c   |  2 +-
>  drivers/gpu/drm/i915/gt/intel_context.c|  3 +--
>  drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c   |  2 +-
>  drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c |  3 +--
>  drivers/gpu/drm/i915/gt/intel_timeline.c   |  4 ++--
>  drivers/gpu/drm/i915/gt/mock_engine.c  |  2 +-
>  .../gpu/drm/i915/gt/selftest_engine_heartbeat.c|  4 ++--
>  drivers/gpu/drm/i915/i915_active.c | 14 +-
>  drivers/gpu/drm/i915/i915_active.h | 11 ++-
>  drivers/gpu/drm/i915/i915_active_types.h   |  5 -
>  drivers/gpu/drm/i915/i915_vma.c|  3 +--
>  drivers/gpu/drm/i915/selftests/i915_active.c   |  4 ++--
>  15 files changed, 28 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c 
> b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
> index 8161d49e78ba..8e75debcce1a 100644
> --- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
> +++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
> @@ -211,7 +211,6 @@ static int frontbuffer_active(struct i915_active *ref)
>   return 0;
>  }
>  
> -__i915_active_call
>  static void frontbuffer_retire(struct i915_active *ref)
>  {
>   struct intel_frontbuffer *front =
> @@ -266,7 +265,8 @@ intel_frontbuffer_get(struct drm_i915_gem_object *obj)
>   atomic_set(&front->bits, 0);
>   i915_active_init(&front->write,
>frontbuffer_active,
> -  i915_active_may_sleep(frontbuffer_retire));
> +  frontbuffer_retire,
> +  I915_ACTIVE_RETIRE_SLEEPS);
>  
>   spin_lock(&i915->fb_tracking.lock);
>   if (rcu_access_pointer(obj->frontbuffer)) {
> diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c 
> b/drivers/gpu/drm/i915/display/intel_overlay.c
> index 428819ba18dd..f1e04c1535c7 100644
> --- a/drivers/gpu/drm/i915/display/intel_overlay.c
> +++ b/drivers/gpu/drm/i915/display/intel_overlay.c
> @@ -383,8 +383,7 @@ static void intel_overlay_off_tail(struct intel_overlay 
> *overlay)
>   i830_overlay_clock_gating(dev_priv, true);
>  }
>  
> -__i915_active_call static void
> -intel_overlay_last_flip_retire(struct i915_active *active)
> +static void intel_overlay_last_flip_retire(struct i915_active *active)
>  {
>   struct intel_overlay *overlay =
>   container_of(active, typeof(*overlay), last_flip);
> @@ -1401,7 +1400,7 @@ void intel_overlay_setup(struct drm_i915_private 
> *dev_priv)
>   overlay->saturation = 146;
>  
>   i915_active_init(&overlay->last_flip,
> -  NULL, intel_overlay_last_flip_retire);
> +  NULL, intel_overlay_last_flip_retire, 0);
>  
>   ret = get_registers(overlay, OVERLAY_NEEDS_PHYSICAL(dev_priv));
>   if (ret)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index fd8ee52e17a4..188dee13e017 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -1046,7 +1046,6 @@ struct context_barrier_task {
>   void *data;
>  };
>  
> -__i915_active_call
>  static void cb_retire(struct i915_active *base)
>  {
>   struct context_barrier_task *cb = container_of(base, typeof(*cb), base);
> @@ -1080,7 +1079,7 @@ static int context_barrier_task(struct i915_gem_context 
> *ctx,
>   if (!cb)
>   return -ENOMEM;
>  
> - i915_active_init(&cb->base, NULL, cb_retire);
> + i915_active_init(&cb->base, NULL, cb_retire, 0);
>   err = i915_active_acquire(&cb->base);
>   if (err) {
>   kfree(cb);
> diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c 
> b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
> index 21b1085769be..1aee5e6b1b23 100644
> --- a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
> +++ b/drivers/gpu/drm/i91

Re: [Intel-gfx] Enabling sample_c optimization for Broadwell GPUs

[Rodrigo Vivi]

Hi Andre,

I'm not familiar with the sample c message optimization.
Probably Ken can comment.

However I could check the internal spec here and I saw this bit
only exists with this meaning in Haswell.

For all the other platforms, including Broadwell it got re-purposed with
a different meaning and a programming note:
"This bit should be programmed to zero (0h) at all times."

Also, I could not find any workaround documented anywhere recommending
this bit to be set.

So, I would not recommend to use it in any product, even downstream.
Regardless the state of sample c message optimization in later platforms.

Thanks,
Rodrigo.

On Tue, May 04, 2021 at 08:07:14PM -0300, André Almeida wrote:
> Hi there,
> 
> While browsing an old downstream kernel, I found a patch[0] that enables
> sample_c optimizations at Broadwell GPUs. The message from the upstream
> commit that enables it for Haswell[1] (and presumably where the code at[0]
> was copied from) states that "[..] later platforms remove this bit, and
> apparently always enable the optimization".
> 
> Could you confirm that Broadwell and following architectures enable this
> optimization by default (and thus, patch[0] is a no-op), or should I
> upstream it?
> 
> Thanks,
>   André
> 
> [0] 
> https://github.com/ValveSoftware/steamos_kernel/commit/198990f13e1d9429864c177d9441a6559771c5e2
> 
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=944115934436b1ff6cf773a9e9123858ea9ef3da
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 16/27] drm/i915/gem: Add an intermediate proto_context struct

[Tvrtko Ursulin]

On 03/05/2021 16:57, Jason Ekstrand wrote:

The current context uAPI allows for two methods of setting context
parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM.  The
former is allowed to be called at any time while the later happens as
part of GEM_CONTEXT_CREATE.  Currently, everything settable via one is
settable via the other.  While some params are fairly simple and setting
them on a live context is harmless such the context priority, others are
far trickier such as the VM or the set of engines.  In order to swap out
the VM, for instance, we have to delay until all current in-flight work
is complete, swap in the new VM, and then continue.  This leads to a
plethora of potential race conditions we'd really rather avoid.

Unfortunately, both methods of setting the VM and engine set are in
active use today so we can't simply disallow setting the VM or engine
set vial SET_CONTEXT_PARAM.  In order to work around this wart, this
commit adds a proto-context struct which contains all the context create
parameters.


The detailed commentary from "drm/i915/gem: Delay context creation" 
would be useful at this point in the series so it is known what this 
patch tries to do.


For the record, again, my opinion is that from here in the series 
onwards (mostly), there is a negative cost-benefit ratio and most 
certainly isn't something which should be rammed quickly in without a 
consensus.


Regards,

Tvrtko



Signed-off-by: Jason Ekstrand 
---
  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 145 ++
  .../gpu/drm/i915/gem/i915_gem_context_types.h |  22 +++
  .../gpu/drm/i915/gem/selftests/mock_context.c |  16 +-
  3 files changed, 153 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 4835991898ac9..10bd1b6dd1774 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -191,6 +191,97 @@ static int validate_priority(struct drm_i915_private *i915,
return 0;
  }
  
+static void proto_context_close(struct i915_gem_proto_context *pc)

+{
+   if (pc->vm)
+   i915_vm_put(pc->vm);
+   kfree(pc);
+}
+
+static int proto_context_set_persistence(struct drm_i915_private *i915,
+struct i915_gem_proto_context *pc,
+bool persist)
+{
+   if (persist) {
+   /*
+* Only contexts that are short-lived [that will expire or be
+* reset] are allowed to survive past termination. We require
+* hangcheck to ensure that the persistent requests are healthy.
+*/
+   if (!i915->params.enable_hangcheck)
+   return -EINVAL;
+
+   __set_bit(UCONTEXT_PERSISTENCE, &pc->user_flags);
+   } else {
+   /* To cancel a context we use "preempt-to-idle" */
+   if (!(i915->caps.scheduler & I915_SCHEDULER_CAP_PREEMPTION))
+   return -ENODEV;
+
+   /*
+* If the cancel fails, we then need to reset, cleanly!
+*
+* If the per-engine reset fails, all hope is lost! We resort
+* to a full GPU reset in that unlikely case, but realistically
+* if the engine could not reset, the full reset does not fare
+* much better. The damage has been done.
+*
+* However, if we cannot reset an engine by itself, we cannot
+* cleanup a hanging persistent context without causing
+* colateral damage, and we should not pretend we can by
+* exposing the interface.
+*/
+   if (!intel_has_reset_engine(&i915->gt))
+   return -ENODEV;
+
+   __clear_bit(UCONTEXT_PERSISTENCE, &pc->user_flags);
+   }
+
+   return 0;
+}
+
+static struct i915_gem_proto_context *
+proto_context_create(struct drm_i915_private *i915, unsigned int flags)
+{
+   struct i915_gem_proto_context *pc, *err;
+
+   pc = kzalloc(sizeof(*pc), GFP_KERNEL);
+   if (!pc)
+   return ERR_PTR(-ENOMEM);
+
+   if (HAS_FULL_PPGTT(i915)) {
+   struct i915_ppgtt *ppgtt;
+
+   ppgtt = i915_ppgtt_create(&i915->gt);
+   if (IS_ERR(ppgtt)) {
+   drm_dbg(&i915->drm, "PPGTT setup failed (%ld)\n",
+   PTR_ERR(ppgtt));
+   err = ERR_CAST(ppgtt);
+   goto proto_close;
+   }
+   pc->vm = &ppgtt->vm;
+   }
+
+   pc->user_flags = 0;
+   __set_bit(UCONTEXT_BANNABLE, &pc->user_flags);
+   __set_bit(UCONTEXT_RECOVERABLE, &pc->user_flags);
+   proto_context_set_persistence(i915, pc, true);
+   pc->sched.priority = I915_PRIORITY_NORMAL;
+
+   if (flags & I91

Re: [Intel-gfx] [PATCH 27/27] drm/i915/gem: Roll all of context creation together

[Daniel Vetter]

On Mon, May 03, 2021 at 10:57:48AM -0500, Jason Ekstrand wrote:
> Now that we have the whole engine set and VM at context creation time,
> we can just assign those fields instead of creating first and handling
> the VM and engines later.  This lets us avoid creating useless VMs and
> engine sets and lets us get rid of the complex VM setting code.
> 
> Signed-off-by: Jason Ekstrand 

Ok here comes the cleanup around engine setup control flow and locking and
all that.

Reviewed-by: Daniel Vetter 

So one thing I noticed that's still in the uapi bucket is that we now
still have all the ctx->user_flags as mutable. I think especially
persistence has a big impact on ctx cleanup, so would be nice if we can
make that one invariant. Recoverable/no_error_capture less so, and
bannable is kinda meh.

Did you look into how much it would be to lock these down too? We could
then split the muttable ones out into a ctx->mutable_user_flags or so and
only use atomic bitops for these.

Anyway the big items are the vm and engines, and that's taken care of now.
-Daniel

> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 159 ++
>  .../gpu/drm/i915/gem/selftests/mock_context.c |  33 ++--
>  2 files changed, 64 insertions(+), 128 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 6e5828fe1a792..6bffb0e579b4e 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -1302,56 +1302,6 @@ static int __context_set_persistence(struct 
> i915_gem_context *ctx, bool state)
>   return 0;
>  }
>  
> -static struct i915_gem_context *
> -__create_context(struct drm_i915_private *i915,
> -  const struct i915_gem_proto_context *pc)
> -{
> - struct i915_gem_context *ctx;
> - struct i915_gem_engines *e;
> - int err;
> - int i;
> -
> - ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> - if (!ctx)
> - return ERR_PTR(-ENOMEM);
> -
> - kref_init(&ctx->ref);
> - ctx->i915 = i915;
> - ctx->sched = pc->sched;
> - mutex_init(&ctx->mutex);
> - INIT_LIST_HEAD(&ctx->link);
> -
> - spin_lock_init(&ctx->stale.lock);
> - INIT_LIST_HEAD(&ctx->stale.engines);
> -
> - mutex_init(&ctx->engines_mutex);
> - e = default_engines(ctx, pc->legacy_rcs_sseu);
> - if (IS_ERR(e)) {
> - err = PTR_ERR(e);
> - goto err_free;
> - }
> - RCU_INIT_POINTER(ctx->engines, e);
> -
> - INIT_RADIX_TREE(&ctx->handles_vma, GFP_KERNEL);
> - mutex_init(&ctx->lut_mutex);
> -
> - /* NB: Mark all slices as needing a remap so that when the context first
> -  * loads it will restore whatever remap state already exists. If there
> -  * is no remap info, it will be a NOP. */
> - ctx->remap_slice = ALL_L3_SLICES(i915);
> -
> - ctx->user_flags = pc->user_flags;
> -
> - for (i = 0; i < ARRAY_SIZE(ctx->hang_timestamp); i++)
> - ctx->hang_timestamp[i] = jiffies - CONTEXT_FAST_HANG_JIFFIES;
> -
> - return ctx;
> -
> -err_free:
> - kfree(ctx);
> - return ERR_PTR(err);
> -}
> -
>  static inline struct i915_gem_engines *
>  __context_engines_await(const struct i915_gem_context *ctx,
>   bool *user_engines)
> @@ -1395,86 +1345,77 @@ context_apply_all(struct i915_gem_context *ctx,
>   i915_sw_fence_complete(&e->fence);
>  }
>  
> -static void __apply_ppgtt(struct intel_context *ce, void *vm)
> -{
> - i915_vm_put(ce->vm);
> - ce->vm = i915_vm_get(vm);
> -}
> -
> -static struct i915_address_space *
> -__set_ppgtt(struct i915_gem_context *ctx, struct i915_address_space *vm)
> -{
> - struct i915_address_space *old;
> -
> - old = rcu_replace_pointer(ctx->vm,
> -   i915_vm_open(vm),
> -   lockdep_is_held(&ctx->mutex));
> - GEM_BUG_ON(old && i915_vm_is_4lvl(vm) != i915_vm_is_4lvl(old));
> -
> - context_apply_all(ctx, __apply_ppgtt, vm);
> -
> - return old;
> -}
> -
> -static void __assign_ppgtt(struct i915_gem_context *ctx,
> -struct i915_address_space *vm)
> -{
> - if (vm == rcu_access_pointer(ctx->vm))
> - return;
> -
> - vm = __set_ppgtt(ctx, vm);
> - if (vm)
> - i915_vm_close(vm);
> -}
> -
>  static struct i915_gem_context *
>  i915_gem_create_context(struct drm_i915_private *i915,
>   const struct i915_gem_proto_context *pc)
>  {
>   struct i915_gem_context *ctx;
> - int ret;
> + struct i915_gem_engines *e;
> + int err;
> + int i;
>  
> - ctx = __create_context(i915, pc);
> - if (IS_ERR(ctx))
> - return ctx;
> + ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> + if (!ctx)
> + return ERR_PTR(-ENOMEM);
>  
> - if (pc->vm) {
> - mutex_lock(&ctx->mutex);
> - __assign_ppgtt(ctx, pc->vm);
> - mutex_unlock(&ctx->

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: drop the __i915_active_call pointer packing (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: drop the __i915_active_call pointer packing (rev2)
URL   : https://patchwork.freedesktop.org/series/89783/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
41c6393f0704 drm/i915: drop the __i915_active_call pointer packing
-:18: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit ca419f407b43 ("drm/i915: Fix 
crash in auto_retire")'
#18: 
References: ca419f407b43 ("drm/i915: Fix crash in auto_retire")

-:19: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#19: 
References: d8e44e4dd221 ("drm/i915/overlay: Fix active retire callback 
alignment")

-:19: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit d8e44e4dd221 ("drm/i915/overlay: 
Fix active retire callback alignment")'
#19: 
References: d8e44e4dd221 ("drm/i915/overlay: Fix active retire callback 
alignment")

-:20: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit fd5f262db118 
("drm/i915/selftests: Fix active retire callback alignment")'
#20: 
References: fd5f262db118 ("drm/i915/selftests: Fix active retire callback 
alignment")

total: 3 errors, 1 warnings, 0 checks, 235 lines checked


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

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Associate ACPI connector nodes with connector entries

[Andy Shevchenko]

On Wed, May 5, 2021 at 12:28 PM Hans de Goede  wrote:
> On 5/5/21 11:17 AM, Andy Shevchenko wrote:
> > On Wed, May 5, 2021 at 12:07 PM Hans de Goede  wrote:
> >> On 5/4/21 9:52 AM, Andy Shevchenko wrote:
> >>> On Monday, May 3, 2021, Hans de Goede  >>> > wrote:
> >
> > ...
> >
> >>> +   fwnode = device_get_next_child_node(kdev, fwnode);
> >
> >>> Who is dropping reference counting on fwnode ?
> >>
> >> We are dealing with ACPI fwnode-s here and those are not ref-counted, they
> >> are embedded inside a struct acpi_device and their lifetime is tied to
> >> that struct. They should probably still be ref-counted (with the count
> >> never dropping to 0) so that the generic fwnode functions behave the same
> >> anywhere but atm the ACPI nodes are not refcounted, see: 
> >> acpi_get_next_subnode()
> >> in drivers/acpi/property.c which is the get_next_child_node() 
> >> implementation
> >> for ACPI fwnode-s.
> >
> > Yes, ACPI currently is exceptional, but fwnode API is not.
> > If you may guarantee that this case won't ever be outside of ACPI
>
> Yes I can guarantee that currently this code (which is for the i915
> driver only) only deals with ACPI fwnodes.
>
> > and
> > even though if ACPI won't ever gain a reference counting for fwnodes,
> > we can leave it as is.
>
> Would it not be better to add fake ref-counting to the ACPI fwnode
> next_child_node() op though. I believe just getting a reference
> on the return value there should work fine; and then all fwnode
> implementations would be consistent ?

But it's already there by absent put/get callbacks. On fwnode level it
is like you described. So, talking for a good pattern we have to call
the fwnode_handle_put() independently and always for for_each_child
and get_next_child usages.

> (note I did not check that the of and swnode code do return
> a reference but I would assume so).

Yes, it's only ACPI that survives w/o reference counting.

> >>> I’m in the middle of a pile of fixes for fwnode refcounting when 
> >>> for_each_child or get_next_child is used. So, please double check you 
> >>> drop a reference.
> >>
> >> The kdoc comments on device_get_next_child_node() / 
> >> fwnode_get_next_child_node()
> >> do not mention anything about these functions returning a reference.
> >
> > It's possible. I dunno if it had to be done earlier. Sakari?
> >
> >> So I think we need to first make up our mind here how we want this all to
> >> work and then fix the actual implementation and docs before fixing callers.
> >
> > We have already issues, so I prefer not to wait for a documentation
> > update, because for old kernels it will still be an issue.
>
> I wonder if we really have issues though, in practice fwnodes are
> generated from an devicetree or ACPI tables (or by platform codes
> adding swnodes) and then these pretty much stick around for ever.

Overlays. Not for ever.

> IOW the initial refcount of 1 is never dropped at least for of-nodes
> and ACPI nodes.

>  I know there are some exceptions like device-tree
> overlays which I guess may also be dynamically removed again, but those
> exceptions are not widely used.

ACPI overlays are quite used (at least by two people I know and a few
more that asked questions about them here and there), but luckily it
doesn't require refcounting (yet?).

> And if we forget to drop a reference in the worst case we have a small
> non-re-occuring (so not growing) memleak.

And is it good to provoke all kinds of tools (kmemleak, *SANs, etc)? I
do not think so. If we are writing good code it should be good enough.

> Where as if we start adding
> put() calls everywhere we may end up freeing things which are still
> in use; or dropping refcounts below 0 triggering WARNs in various
> places (IIRC).

Which is good. Then we will discover real issues.

> So it seems the cure is potentially worse then the disease in this
> case.

I tend to disagree with you. How in this case we can go below 0 in
case we know that we took a counter? If somewhere else the code will
do that, it is a problem that has to be fixed on case-by-case basis.

> So if you want to work on this, then IMHO it would be best to first make
> sure that all the fwnode implementations behave in the same way wrt
> ref-counting, before adding the missing put() calls in various
> places.
>
> And once the behavior is consistent

It's consistent now independently of the beneath layer from fwnode API p.o.v.

> then we can also document this
> properly making it easier for other people to do the right thing
> when using these functions.



-- 
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH i-g-t] lib/i915/perf: Fix non-card0 processing

[Janusz Krzysztofik]

Hi Lionel,

On poniedziałek, 3 maja 2021 09:07:09 CEST Lionel Landwerlin wrote:
> On 30/04/2021 19:18, Janusz Krzysztofik wrote:
> > IGT i915/perf library functions now always operate on sysfs perf
> > attributes of card0 device node, no matter which DRM device fd a user
> > passes.  The intention was to always switch to primary device node if
> > a user passes a render device node fd, but that breaks handling of
> > non-card0 devices.
> >
> > Instead of forcibly using DRM device minor number 0 when opening a
> > device sysfs area, convert device minor number of a user passed device
> > fd to the minor number of respective primary (cardX) device node.
> >
> > Signed-off-by: Janusz Krzysztofik 
> > ---
> >   lib/i915/perf.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/i915/perf.c b/lib/i915/perf.c
> > index 56d5c0b3a..336824df7 100644
> > --- a/lib/i915/perf.c
> > +++ b/lib/i915/perf.c
> > @@ -376,8 +376,8 @@ open_master_sysfs_dir(int drm_fd)
> > if (fstat(drm_fd, &st) || !S_ISCHR(st.st_mode))
> >   return -1;
> >   
> > -snprintf(path, sizeof(path), "/sys/dev/char/%d:0",
> > - major(st.st_rdev));
> > +snprintf(path, sizeof(path), "/sys/dev/char/%d:%d",
> > + major(st.st_rdev), minor(st.st_rdev) & ~128);
> 
> 
> Isn't it minor(st.st_rdev) & 0xff ? 

Did you mean 0x7f?

> or even 0x3f ?
> 
> Looks like /dev/dri/controlD64 can exist too.

Not any longer, see commit 0d49f303e8a7 ("drm: remove all control node code").

However, my approach of applying a mask is oversimplified.  Minor numbers for 
different node types (primary and render) are handled separately.  I'm going 
to propose a method similar to that implemented in igt_debugfs_path().

Thanks,
Janusz


> 
> 
> -Lionel
> 
> 
> >   
> > return open(path, O_DIRECTORY);
> >   }
> 
> 
> 




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

Re: [Intel-gfx] [PATCH 12/27] drm/i915/gem: Disallow creating contexts with too many engines

[Tvrtko Ursulin]

On 03/05/2021 16:57, Jason Ekstrand wrote:

There's no sense in allowing userspace to create more engines than it
can possibly access via execbuf.

Signed-off-by: Jason Ekstrand 
Reviewed-by: Daniel Vetter 


FWIW, again for the record, my advice is not to land this one. It makes 
no sense and it is actively disruptive for no benefit.


Regards,

Tvrtko


---
  drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index be42dc918ef6f..8e254d83d65f2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1640,11 +1640,11 @@ set_engines(struct i915_gem_context *ctx,
return -EINVAL;
}
  
-	/*

-* Note that I915_EXEC_RING_MASK limits execbuf to only using the
-* first 64 engines defined here.
-*/
num_engines = (args->size - sizeof(*user)) / sizeof(*user->engines);
+   /* RING_MASK has no shift so we can use it directly here */
+   if (num_engines > I915_EXEC_RING_MASK + 1)
+   return -EINVAL;
+
set.engines = alloc_engines(num_engines);
if (!set.engines)
return -ENOMEM;


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

Re: [Intel-gfx] [PATCH 3/4] Restructure output format computation for better expandability

[Werner Sembach]

Am 04.05.21 um 11:54 schrieb Ville Syrjälä:

> On Mon, May 03, 2021 at 08:21:47PM +0200, Werner Sembach wrote:
>> Couples the decission between RGB and YCbCr420 mode and the check if the port
>> clock can archive the required frequency. Other checks and configuration 
>> steps
>> that where previously done in between can also be done before or after.
>>
>> This allows for are cleaner implementation of retrying different color
>> encodings.
>>
>> Signed-off-by: Werner Sembach 
>> ---
>>
>> >From 57e42ec6e34ac32da29eb7bc3c691cbeb2534396 Mon Sep 17 00:00:00 2001
>> From: Werner Sembach 
>> Date: Mon, 3 May 2021 15:30:40 +0200
>> Subject: [PATCH 3/4] Restructure output format computation for better
>>  expandability
>>
>> ---
>>  drivers/gpu/drm/i915/display/intel_hdmi.c | 57 +++
>>  1 file changed, 26 insertions(+), 31 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
>> b/drivers/gpu/drm/i915/display/intel_hdmi.c
>> index ce165ef28e88..e2553ac6fd13 100644
>> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
>> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
>> @@ -1999,29 +1999,6 @@ static bool hdmi_deep_color_possible(const struct 
>> intel_crtc_state *crtc_state,
>>INTEL_OUTPUT_FORMAT_YCBCR420);
>>  }
>>  
>> -static int
>> -intel_hdmi_ycbcr420_config(struct intel_crtc_state *crtc_state,
>> -   const struct drm_connector_state *conn_state)
>> -{
>> -struct drm_connector *connector = conn_state->connector;
>> -struct drm_i915_private *i915 = to_i915(connector->dev);
>> -const struct drm_display_mode *adjusted_mode =
>> -&crtc_state->hw.adjusted_mode;
>> -
>> -if (!drm_mode_is_420_only(&connector->display_info, adjusted_mode))
>> -return 0;
>> -
>> -if (!connector->ycbcr_420_allowed) {
>> -drm_err(&i915->drm,
>> -"Platform doesn't support YCBCR420 output\n");
>> -return -EINVAL;
>> -}
>> -
>> -crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
>> -
>> -return intel_pch_panel_fitting(crtc_state, conn_state);
>> -}
>> -
>>  static int intel_hdmi_compute_bpc(struct intel_encoder *encoder,
>>struct intel_crtc_state *crtc_state,
>>int clock)
>> @@ -2128,6 +2105,24 @@ static bool intel_hdmi_has_audio(struct intel_encoder 
>> *encoder,
>>  return intel_conn_state->force_audio == HDMI_AUDIO_ON;
>>  }
>>  
>> +int intel_hdmi_compute_output_format(struct intel_encoder *encoder,
>> + struct intel_crtc_state *crtc_state,
>> + const struct drm_connector_state 
>> *conn_state)
>> +{
>> +const struct drm_connector *connector = conn_state->connector;
>> +const struct drm_display_mode *adjusted_mode = 
>> &crtc_state->hw.adjusted_mode;
>> +int ret;
>> +
>> +if (connector->ycbcr_420_allowed && 
>> drm_mode_is_420_only(&connector->display_info, adjusted_mode))
>> +crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
>> +else
>> +crtc_state->output_format = INTEL_OUTPUT_FORMAT_RGB;
> Slight change in behaviour here since we used to reject 420_only modes
> if ycbcr_420_allowed wasn't set. But I think this should be OK, and in
> fact I believe the DP counterpart code always used an RGB fallback
> rather than failing. So this lines up better with that.

That was actually an oversight on my side and not intended. Does a RGB fallback 
make sense?

Now that I think of it get to 2 scenarios:

- The screen is really 420_only, which causes a silent fail and a black screen 
I guess? Where before at least a log message was written.

- The screen falsely reports as 420_only and using RGB regardless makes it 
magically work

I think at least warning should be printed to the logs. Something along the 
lines of: "Display reports as 420 only, but port does not support 420, try 
forcing RGB, but this is likely to fail."
> Needs at least a note in the commit message to indicate that
> there is a functional change buried within. Though it would be
> better to split this functional change into a separate prep patch.
>
>> +
>> +ret = intel_hdmi_compute_clock(encoder, crtc_state);
>> +
>> +return ret;
>> +}
>> +
>>  int intel_hdmi_compute_config(struct intel_encoder *encoder,
>>struct intel_crtc_state *pipe_config,
>>struct drm_connector_state *conn_state)
>> @@ -2152,23 +2147,23 @@ int intel_hdmi_compute_config(struct intel_encoder 
>> *encoder,
>>  if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
>>  pipe_config->pixel_multiplier = 2;
>>  
>> -ret = intel_hdmi_ycbcr420_config(pipe_config, conn_state);
>> -if (ret)
>> -return ret;
>> -
>> -pipe_config->limited_color_range =
>> -intel_hdmi_limited_color_range(pipe_config, conn_state);
>> -

Re: [Intel-gfx] [PATCH 26/27] i915/gem/selftests: Assign the VM at context creation in igt_shared_ctx_exec

[Daniel Vetter]

On Mon, May 03, 2021 at 10:57:47AM -0500, Jason Ekstrand wrote:
> We want to delete __assign_ppgtt and, generally, stop setting the VM
> after context creation.  This is the one place I could find in the
> selftests where we set a VM after the fact.
> 
> Signed-off-by: Jason Ekstrand 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
> index 76029d7143f6c..76dd5cfe11b3c 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
> @@ -813,16 +813,12 @@ static int igt_shared_ctx_exec(void *arg)
>   struct i915_gem_context *ctx;
>   struct intel_context *ce;
>  
> - ctx = kernel_context(i915, NULL);
> + ctx = kernel_context(i915, ctx_vm(parent));
>   if (IS_ERR(ctx)) {
>   err = PTR_ERR(ctx);
>   goto out_test;
>   }
>  
> - mutex_lock(&ctx->mutex);
> - __assign_ppgtt(ctx, ctx_vm(parent));
> - mutex_unlock(&ctx->mutex);
> -
>   ce = i915_gem_context_get_engine(ctx, 
> engine->legacy_idx);
>   GEM_BUG_ON(IS_ERR(ce));
>  
> -- 
> 2.31.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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 18/27] drm/i915/gem: Optionally set SSEU in intel_context_set_gem

[Tvrtko Ursulin]

On 05/05/2021 10:47, Daniel Vetter wrote:

On Wed, May 05, 2021 at 10:28:59AM +0100, Tvrtko Ursulin wrote:


On 04/05/2021 20:00, Daniel Vetter wrote:

On Mon, May 03, 2021 at 10:57:39AM -0500, Jason Ekstrand wrote:

For now this is a no-op because everyone passes in a null SSEU but it
lets us get some of the error handling and selftest refactoring plumbed
through.

Signed-off-by: Jason Ekstrand 


it is a bit icky that intel_context_set_gem also sets the sseu, feels a
bit like a layering violation, but welp I couldn't come up with a better
idea either.

Reviewed-by: Daniel Vetter 


It is actually quite horrible. As you say it breaks separation of duties and
open codes stuff all over the place without transferring over the commentary
about why.


I didn't really see lost commentary anywhere? Can you pls point out what
got lost?


I glanced over two new places which check for RENDER_CLASS without any 
commentary while the existing code helpfully says:


/* Only render engine supports RPCS configuration. */
if (ce->engine->class != RENDER_CLASS) {
ret = -ENODEV;
goto out_ce;
}

But really that is really just a symptom how mixed up the flows end up 
with this patch. In other words I am not suggesting those two new sites 
should have the same comment, just highlighting that the design is not good.


Regards,

Tvrtko

 -Daniel




Regards,

Tvrtko


---
   drivers/gpu/drm/i915/gem/i915_gem_context.c   | 41 +++
   .../gpu/drm/i915/gem/selftests/mock_context.c |  6 ++-
   2 files changed, 36 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ce729e640bbf7..6dd50d669c5b9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -320,9 +320,12 @@ context_get_vm_rcu(struct i915_gem_context *ctx)
} while (1);
   }
-static void intel_context_set_gem(struct intel_context *ce,
- struct i915_gem_context *ctx)
+static int intel_context_set_gem(struct intel_context *ce,
+struct i915_gem_context *ctx,
+struct intel_sseu sseu)
   {
+   int ret = 0;
+
GEM_BUG_ON(rcu_access_pointer(ce->gem_context));
RCU_INIT_POINTER(ce->gem_context, ctx);
@@ -349,6 +352,12 @@ static void intel_context_set_gem(struct intel_context *ce,
intel_context_set_watchdog_us(ce, (u64)timeout_ms * 1000);
}
+
+   /* A valid SSEU has no zero fields */
+   if (sseu.slice_mask && !WARN_ON(ce->engine->class != RENDER_CLASS))
+   ret = intel_context_reconfigure_sseu(ce, sseu);
+
+   return ret;
   }
   static void __free_engines(struct i915_gem_engines *e, unsigned int count)
@@ -416,7 +425,8 @@ static struct i915_gem_engines *alloc_engines(unsigned int 
count)
return e;
   }
-static struct i915_gem_engines *default_engines(struct i915_gem_context *ctx)
+static struct i915_gem_engines *default_engines(struct i915_gem_context *ctx,
+   struct intel_sseu rcs_sseu)
   {
const struct intel_gt *gt = &ctx->i915->gt;
struct intel_engine_cs *engine;
@@ -429,6 +439,8 @@ static struct i915_gem_engines *default_engines(struct 
i915_gem_context *ctx)
for_each_engine(engine, gt, id) {
struct intel_context *ce;
+   struct intel_sseu sseu = {};
+   int ret;
if (engine->legacy_idx == INVALID_ENGINE)
continue;
@@ -442,10 +454,18 @@ static struct i915_gem_engines *default_engines(struct 
i915_gem_context *ctx)
goto free_engines;
}
-   intel_context_set_gem(ce, ctx);
-
e->engines[engine->legacy_idx] = ce;
e->num_engines = max(e->num_engines, engine->legacy_idx + 1);
+
+   if (engine->class == RENDER_CLASS)
+   sseu = rcs_sseu;
+
+   ret = intel_context_set_gem(ce, ctx, sseu);
+   if (ret) {
+   err = ERR_PTR(ret);
+   goto free_engines;
+   }
+
}
return e;
@@ -759,6 +779,7 @@ __create_context(struct drm_i915_private *i915,
   {
struct i915_gem_context *ctx;
struct i915_gem_engines *e;
+   struct intel_sseu null_sseu = {};
int err;
int i;
@@ -776,7 +797,7 @@ __create_context(struct drm_i915_private *i915,
INIT_LIST_HEAD(&ctx->stale.engines);
mutex_init(&ctx->engines_mutex);
-   e = default_engines(ctx);
+   e = default_engines(ctx, null_sseu);
if (IS_ERR(e)) {
err = PTR_ERR(e);
goto err_free;
@@ -1544,6 +1565,7 @@ set_engines__load_balance(struct i915_user_extension 
__user *base, void *data)
struct intel_engine_cs *stack[16];
  

Re: [Intel-gfx] [PATCH 4/9] drm/connector: Add support for out-of-band hotplug notification (v2)

[Heikki Krogerus]

On Tue, May 04, 2021 at 05:35:49PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 5/4/21 5:10 PM, Heikki Krogerus wrote:
> >> +/**
> >> + * drm_connector_oob_hotplug_event - Report out-of-band hotplug event to 
> >> connector
> >> + * @connector: connector to report the event on
> >> + * @data: data related to the event
> >> + *
> >> + * On some hardware a hotplug event notification may come from outside 
> >> the display
> >> + * driver / device. An example of this is some USB Type-C setups where 
> >> the hardware
> >> + * muxes the DisplayPort data and aux-lines but does not pass the altmode 
> >> HPD
> >> + * status bit to the GPU's DP HPD pin.
> >> + *
> >> + * This function can be used to report these out-of-band events after 
> >> obtaining
> >> + * a drm_connector reference through calling 
> >> drm_connector_find_by_fwnode().
> >> + */
> >> +void drm_connector_oob_hotplug_event(struct fwnode_handle 
> >> *connector_fwnode,
> >> +   struct 
> >> drm_connector_oob_hotplug_event_data *data)
> >> +{
> >> +  struct drm_connector *connector;
> >> +
> >> +  connector = drm_connector_find_by_fwnode(connector_fwnode);
> >> +  if (IS_ERR(connector))
> >> +  return;
> >> +
> >> +  if (connector->funcs->oob_hotplug_event)
> >> +  connector->funcs->oob_hotplug_event(connector, data);
> >> +
> >> +  drm_connector_put(connector);
> >> +}
> >> +EXPORT_SYMBOL(drm_connector_oob_hotplug_event);
> > 
> > So it does looks like the "data" parameter is not needed at all:
> 
> Well Imre did indicate that having the number of lanes is useful, so
> for the next version I'll drop the orientation but I plan to keep
> the number of lanes if that is ok with you.
> 
> Not having passing along this info was one of the reasons why my
> previous attempt at this was nacked, so dropping it all together
> feels wrong.

If you need to pass any information to the function, then you need to
pass all the information that we have. Don't start with abstraction.
First create a dedicated API, and then, only if we really have another
user for it, we can add an abstraction layer that both users can use.
All cases are going to be different. We don't know how the abstraction
/ generalisation should look like before we have at least two real
users (ideally more than two, actually). Right now we can not even say
for sure that generalising the API is even possible.

I would not make a huge deal out of this unless I wasn't myself being
told by guys like Greg KH in the past to drop my attempts to
"generalize" things from the beginning when I only had a single user.
By doing so you'll not only force all ends, the source of the data
(the typec drivers in this case) as well as the consumer (i915), to be
always changed together, it will also confuse things. We are not
always going to be able to tell the lane count for example like we can
with USB Type-C, so i915 can't really rely on that information.

Right now we also don't know what exact details i915 (or what ever GPU
driver) needs. We can only say for sure that some details are going to
be needed. Trying to guess and cherry-pick the details now does not
makes sense because of that reason too.

So just make this API USB Type-C DP Alt Mode specific API first, and
supply it everything we have.


thanks,

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

Re: [Intel-gfx] [PATCH 25/27] drm/i915/selftests: Take a VM in kernel_context()

[Daniel Vetter]

On Mon, May 03, 2021 at 10:57:46AM -0500, Jason Ekstrand wrote:
> This better models where we want to go with contexts in general where
> things like the VM and engine set are create parameters instead of being
> set after the fact.
> 
> Signed-off-by: Jason Ekstrand 

Looks reasonable.

Reviewed-by: Daniel Vetter 

> ---
>  .../drm/i915/gem/selftests/i915_gem_context.c |  4 ++--
>  .../gpu/drm/i915/gem/selftests/mock_context.c |  9 -
>  .../gpu/drm/i915/gem/selftests/mock_context.h |  4 +++-
>  drivers/gpu/drm/i915/gt/selftest_execlists.c  | 20 +--
>  drivers/gpu/drm/i915/gt/selftest_hangcheck.c  |  2 +-
>  5 files changed, 24 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
> index 16ff64ab34a1b..76029d7143f6c 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
> @@ -680,7 +680,7 @@ static int igt_ctx_exec(void *arg)
>   struct i915_gem_context *ctx;
>   struct intel_context *ce;
>  
> - ctx = kernel_context(i915);
> + ctx = kernel_context(i915, NULL);
>   if (IS_ERR(ctx)) {
>   err = PTR_ERR(ctx);
>   goto out_file;
> @@ -813,7 +813,7 @@ static int igt_shared_ctx_exec(void *arg)
>   struct i915_gem_context *ctx;
>   struct intel_context *ce;
>  
> - ctx = kernel_context(i915);
> + ctx = kernel_context(i915, NULL);
>   if (IS_ERR(ctx)) {
>   err = PTR_ERR(ctx);
>   goto out_test;
> diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_context.c 
> b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> index 61aaac4a334cf..500ef27ba4771 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> @@ -150,7 +150,8 @@ live_context_for_engine(struct intel_engine_cs *engine, 
> struct file *file)
>  }
>  
>  struct i915_gem_context *
> -kernel_context(struct drm_i915_private *i915)
> +kernel_context(struct drm_i915_private *i915,
> +struct i915_address_space *vm)
>  {
>   struct i915_gem_context *ctx;
>   struct i915_gem_proto_context *pc;
> @@ -159,6 +160,12 @@ kernel_context(struct drm_i915_private *i915)
>   if (IS_ERR(pc))
>   return ERR_CAST(pc);
>  
> + if (vm) {
> + if (pc->vm)
> + i915_vm_put(pc->vm);
> + pc->vm = i915_vm_get(vm);
> + }
> +
>   ctx = i915_gem_create_context(i915, pc);
>   proto_context_close(pc);
>   if (IS_ERR(ctx))
> diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_context.h 
> b/drivers/gpu/drm/i915/gem/selftests/mock_context.h
> index 2a6121d33352d..7a02fd9b5866a 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/mock_context.h
> +++ b/drivers/gpu/drm/i915/gem/selftests/mock_context.h
> @@ -10,6 +10,7 @@
>  struct file;
>  struct drm_i915_private;
>  struct intel_engine_cs;
> +struct i915_address_space;
>  
>  void mock_init_contexts(struct drm_i915_private *i915);
>  
> @@ -25,7 +26,8 @@ live_context(struct drm_i915_private *i915, struct file 
> *file);
>  struct i915_gem_context *
>  live_context_for_engine(struct intel_engine_cs *engine, struct file *file);
>  
> -struct i915_gem_context *kernel_context(struct drm_i915_private *i915);
> +struct i915_gem_context *kernel_context(struct drm_i915_private *i915,
> + struct i915_address_space *vm);
>  void kernel_context_close(struct i915_gem_context *ctx);
>  
>  #endif /* !__MOCK_CONTEXT_H */
> diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c 
> b/drivers/gpu/drm/i915/gt/selftest_execlists.c
> index a0e75b71a3374..0989e024f7a03 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_execlists.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_execlists.c
> @@ -1522,12 +1522,12 @@ static int live_busywait_preempt(void *arg)
>* preempt the busywaits used to synchronise between rings.
>*/
>  
> - ctx_hi = kernel_context(gt->i915);
> + ctx_hi = kernel_context(gt->i915, NULL);
>   if (!ctx_hi)
>   return -ENOMEM;
>   ctx_hi->sched.priority = I915_CONTEXT_MAX_USER_PRIORITY;
>  
> - ctx_lo = kernel_context(gt->i915);
> + ctx_lo = kernel_context(gt->i915, NULL);
>   if (!ctx_lo)
>   goto err_ctx_hi;
>   ctx_lo->sched.priority = I915_CONTEXT_MIN_USER_PRIORITY;
> @@ -1724,12 +1724,12 @@ static int live_preempt(void *arg)
>   if (igt_spinner_init(&spin_lo, gt))
>   goto err_spin_hi;
>  
> - ctx_hi = kernel_context(gt->i915);
> + ctx_hi = kernel_context(gt->i915, NULL);
>   if (!ctx_hi)
>   goto err_spin_lo;
>   ctx_hi->s

Re: [Intel-gfx] [PATCH 24/27] drm/i915/gem: Don't allow changing the engine set on running contexts

[Daniel Vetter]

On Mon, May 03, 2021 at 10:57:45AM -0500, Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand 

Again needs some commit message, with that:

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c | 304 
>  1 file changed, 304 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index ad6e98d8a4fbd..6e5828fe1a792 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -1823,306 +1823,6 @@ static int set_sseu(struct i915_gem_context *ctx,
>   return ret;
>  }
>  
> -struct set_engines {
> - struct i915_gem_context *ctx;
> - struct i915_gem_engines *engines;
> -};
> -
> -static int
> -set_engines__load_balance(struct i915_user_extension __user *base, void 
> *data)
> -{
> - struct i915_context_engines_load_balance __user *ext =
> - container_of_user(base, typeof(*ext), base);
> - const struct set_engines *set = data;
> - struct drm_i915_private *i915 = set->ctx->i915;
> - struct intel_engine_cs *stack[16];
> - struct intel_engine_cs **siblings;
> - struct intel_context *ce;
> - struct intel_sseu null_sseu = {};
> - u16 num_siblings, idx;
> - unsigned int n;
> - int err;
> -
> - if (!HAS_EXECLISTS(i915))
> - return -ENODEV;
> -
> - if (intel_uc_uses_guc_submission(&i915->gt.uc))
> - return -ENODEV; /* not implement yet */
> -
> - if (get_user(idx, &ext->engine_index))
> - return -EFAULT;
> -
> - if (idx >= set->engines->num_engines) {
> - drm_dbg(&i915->drm, "Invalid placement value, %d >= %d\n",
> - idx, set->engines->num_engines);
> - return -EINVAL;
> - }
> -
> - idx = array_index_nospec(idx, set->engines->num_engines);
> - if (set->engines->engines[idx]) {
> - drm_dbg(&i915->drm,
> - "Invalid placement[%d], already occupied\n", idx);
> - return -EEXIST;
> - }
> -
> - if (get_user(num_siblings, &ext->num_siblings))
> - return -EFAULT;
> -
> - err = check_user_mbz(&ext->flags);
> - if (err)
> - return err;
> -
> - err = check_user_mbz(&ext->mbz64);
> - if (err)
> - return err;
> -
> - siblings = stack;
> - if (num_siblings > ARRAY_SIZE(stack)) {
> - siblings = kmalloc_array(num_siblings,
> -  sizeof(*siblings),
> -  GFP_KERNEL);
> - if (!siblings)
> - return -ENOMEM;
> - }
> -
> - for (n = 0; n < num_siblings; n++) {
> - struct i915_engine_class_instance ci;
> -
> - if (copy_from_user(&ci, &ext->engines[n], sizeof(ci))) {
> - err = -EFAULT;
> - goto out_siblings;
> - }
> -
> - siblings[n] = intel_engine_lookup_user(i915,
> -ci.engine_class,
> -ci.engine_instance);
> - if (!siblings[n]) {
> - drm_dbg(&i915->drm,
> - "Invalid sibling[%d]: { class:%d, inst:%d }\n",
> - n, ci.engine_class, ci.engine_instance);
> - err = -EINVAL;
> - goto out_siblings;
> - }
> - }
> -
> - ce = intel_execlists_create_virtual(siblings, n);
> - if (IS_ERR(ce)) {
> - err = PTR_ERR(ce);
> - goto out_siblings;
> - }
> -
> - intel_context_set_gem(ce, set->ctx, null_sseu);
> -
> - if (cmpxchg(&set->engines->engines[idx], NULL, ce)) {
> - intel_context_put(ce);
> - err = -EEXIST;
> - goto out_siblings;
> - }
> -
> -out_siblings:
> - if (siblings != stack)
> - kfree(siblings);
> -
> - return err;
> -}
> -
> -static int
> -set_engines__bond(struct i915_user_extension __user *base, void *data)
> -{
> - struct i915_context_engines_bond __user *ext =
> - container_of_user(base, typeof(*ext), base);
> - const struct set_engines *set = data;
> - struct drm_i915_private *i915 = set->ctx->i915;
> - struct i915_engine_class_instance ci;
> - struct intel_engine_cs *virtual;
> - struct intel_engine_cs *master;
> - u16 idx, num_bonds;
> - int err, n;
> -
> - if (get_user(idx, &ext->virtual_index))
> - return -EFAULT;
> -
> - if (idx >= set->engines->num_engines) {
> - drm_dbg(&i915->drm,
> - "Invalid index for virtual engine: %d >= %d\n",
> - idx, set->engines->num_engines);
> - return -EINVAL;
> - }
> -
> - idx = array_index_nospec(idx, set->engines->num_engines);
> - if (!set->engines->engines[idx]) {

Re: [Intel-gfx] [PATCH 18/27] drm/i915/gem: Optionally set SSEU in intel_context_set_gem

[Daniel Vetter]

On Wed, May 05, 2021 at 10:28:59AM +0100, Tvrtko Ursulin wrote:
> 
> On 04/05/2021 20:00, Daniel Vetter wrote:
> > On Mon, May 03, 2021 at 10:57:39AM -0500, Jason Ekstrand wrote:
> > > For now this is a no-op because everyone passes in a null SSEU but it
> > > lets us get some of the error handling and selftest refactoring plumbed
> > > through.
> > > 
> > > Signed-off-by: Jason Ekstrand 
> > 
> > it is a bit icky that intel_context_set_gem also sets the sseu, feels a
> > bit like a layering violation, but welp I couldn't come up with a better
> > idea either.
> > 
> > Reviewed-by: Daniel Vetter 
> 
> It is actually quite horrible. As you say it breaks separation of duties and
> open codes stuff all over the place without transferring over the commentary
> about why.

I didn't really see lost commentary anywhere? Can you pls point out what
got lost?
-Daniel

> 
> Regards,
> 
> Tvrtko
> 
> > > ---
> > >   drivers/gpu/drm/i915/gem/i915_gem_context.c   | 41 +++
> > >   .../gpu/drm/i915/gem/selftests/mock_context.c |  6 ++-
> > >   2 files changed, 36 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> > > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > > index ce729e640bbf7..6dd50d669c5b9 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > > @@ -320,9 +320,12 @@ context_get_vm_rcu(struct i915_gem_context *ctx)
> > >   } while (1);
> > >   }
> > > -static void intel_context_set_gem(struct intel_context *ce,
> > > -   struct i915_gem_context *ctx)
> > > +static int intel_context_set_gem(struct intel_context *ce,
> > > +  struct i915_gem_context *ctx,
> > > +  struct intel_sseu sseu)
> > >   {
> > > + int ret = 0;
> > > +
> > >   GEM_BUG_ON(rcu_access_pointer(ce->gem_context));
> > >   RCU_INIT_POINTER(ce->gem_context, ctx);
> > > @@ -349,6 +352,12 @@ static void intel_context_set_gem(struct 
> > > intel_context *ce,
> > >   intel_context_set_watchdog_us(ce, (u64)timeout_ms * 
> > > 1000);
> > >   }
> > > +
> > > + /* A valid SSEU has no zero fields */
> > > + if (sseu.slice_mask && !WARN_ON(ce->engine->class != RENDER_CLASS))
> > > + ret = intel_context_reconfigure_sseu(ce, sseu);
> > > +
> > > + return ret;
> > >   }
> > >   static void __free_engines(struct i915_gem_engines *e, unsigned int 
> > > count)
> > > @@ -416,7 +425,8 @@ static struct i915_gem_engines 
> > > *alloc_engines(unsigned int count)
> > >   return e;
> > >   }
> > > -static struct i915_gem_engines *default_engines(struct i915_gem_context 
> > > *ctx)
> > > +static struct i915_gem_engines *default_engines(struct i915_gem_context 
> > > *ctx,
> > > + struct intel_sseu rcs_sseu)
> > >   {
> > >   const struct intel_gt *gt = &ctx->i915->gt;
> > >   struct intel_engine_cs *engine;
> > > @@ -429,6 +439,8 @@ static struct i915_gem_engines 
> > > *default_engines(struct i915_gem_context *ctx)
> > >   for_each_engine(engine, gt, id) {
> > >   struct intel_context *ce;
> > > + struct intel_sseu sseu = {};
> > > + int ret;
> > >   if (engine->legacy_idx == INVALID_ENGINE)
> > >   continue;
> > > @@ -442,10 +454,18 @@ static struct i915_gem_engines 
> > > *default_engines(struct i915_gem_context *ctx)
> > >   goto free_engines;
> > >   }
> > > - intel_context_set_gem(ce, ctx);
> > > -
> > >   e->engines[engine->legacy_idx] = ce;
> > >   e->num_engines = max(e->num_engines, engine->legacy_idx 
> > > + 1);
> > > +
> > > + if (engine->class == RENDER_CLASS)
> > > + sseu = rcs_sseu;
> > > +
> > > + ret = intel_context_set_gem(ce, ctx, sseu);
> > > + if (ret) {
> > > + err = ERR_PTR(ret);
> > > + goto free_engines;
> > > + }
> > > +
> > >   }
> > >   return e;
> > > @@ -759,6 +779,7 @@ __create_context(struct drm_i915_private *i915,
> > >   {
> > >   struct i915_gem_context *ctx;
> > >   struct i915_gem_engines *e;
> > > + struct intel_sseu null_sseu = {};
> > >   int err;
> > >   int i;
> > > @@ -776,7 +797,7 @@ __create_context(struct drm_i915_private *i915,
> > >   INIT_LIST_HEAD(&ctx->stale.engines);
> > >   mutex_init(&ctx->engines_mutex);
> > > - e = default_engines(ctx);
> > > + e = default_engines(ctx, null_sseu);
> > >   if (IS_ERR(e)) {
> > >   err = PTR_ERR(e);
> > >   goto err_free;
> > > @@ -1544,6 +1565,7 @@ set_engines__load_balance(struct 
> > > i915_user_extension __user *base, void *data)
> > >   struct intel_engine_cs *stack[16];
> > >   struct intel_engine_c

Re: [Intel-gfx] [PATCH 2/4] Add missing check

[Werner Sembach]

Am 04.05.21 um 11:41 schrieb Ville Syrjälä:

> On Mon, May 03, 2021 at 08:21:46PM +0200, Werner Sembach wrote:
>> Add a missing check that could potentially lead to an unarchivable mode being
>> validated.
>>
>> Signed-off-by: Werner Sembach 
>> ---
>>
>> >From 54fa706f0a5f260a32af5d18b9622ceebb94c12e Mon Sep 17 00:00:00 2001
>> From: Werner Sembach 
>> Date: Mon, 3 May 2021 14:42:36 +0200
>> Subject: [PATCH 2/4] Add missing check
> I guess you did something a bit wonky with git format-patch/send-mail?
I have no idea how that timestamp happened, I will check when sending my next 
patch ^^.
>> ---
>>  drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
>> b/drivers/gpu/drm/i915/display/intel_hdmi.c
>> index 576d3d910d06..ce165ef28e88 100644
>> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
>> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
>> @@ -1913,7 +1913,7 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
>>  clock *= 2;
>>  }
>>  
>> -if (drm_mode_is_420_only(&connector->display_info, mode))
>> +if (connector->ycbcr_420_allowed && 
>> drm_mode_is_420_only(&connector->display_info, mode))
> This one shouldn't be necessary. drm_mode_validate_ycbcr420() has
> already checked it for us.
I wasn't aware of drm_mode_validate_ycbcr420, thanks for the hint. In the 
"420_also"-patch I change drm_mode_is_420_only to drm_mode_is_420 (helper 
function: _only + _also), which is not checked by drm_mode_validate_ycbcr420. I 
can add this check to that patch, since its only required then.
>>  clock /= 2;
>>  
>>  status = intel_hdmi_mode_clock_valid(hdmi, clock, has_hdmi_sink);
>> -- 
>> 2.25.1

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

Re: [Intel-gfx] [PATCH 18/27] drm/i915/gem: Optionally set SSEU in intel_context_set_gem

[Tvrtko Ursulin]

On 04/05/2021 20:00, Daniel Vetter wrote:

On Mon, May 03, 2021 at 10:57:39AM -0500, Jason Ekstrand wrote:

For now this is a no-op because everyone passes in a null SSEU but it
lets us get some of the error handling and selftest refactoring plumbed
through.

Signed-off-by: Jason Ekstrand 


it is a bit icky that intel_context_set_gem also sets the sseu, feels a
bit like a layering violation, but welp I couldn't come up with a better
idea either.

Reviewed-by: Daniel Vetter 


It is actually quite horrible. As you say it breaks separation of duties 
and open codes stuff all over the place without transferring over the 
commentary about why.


Regards,

Tvrtko


---
  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 41 +++
  .../gpu/drm/i915/gem/selftests/mock_context.c |  6 ++-
  2 files changed, 36 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ce729e640bbf7..6dd50d669c5b9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -320,9 +320,12 @@ context_get_vm_rcu(struct i915_gem_context *ctx)
} while (1);
  }
  
-static void intel_context_set_gem(struct intel_context *ce,

- struct i915_gem_context *ctx)
+static int intel_context_set_gem(struct intel_context *ce,
+struct i915_gem_context *ctx,
+struct intel_sseu sseu)
  {
+   int ret = 0;
+
GEM_BUG_ON(rcu_access_pointer(ce->gem_context));
RCU_INIT_POINTER(ce->gem_context, ctx);
  
@@ -349,6 +352,12 @@ static void intel_context_set_gem(struct intel_context *ce,
  
  		intel_context_set_watchdog_us(ce, (u64)timeout_ms * 1000);

}
+
+   /* A valid SSEU has no zero fields */
+   if (sseu.slice_mask && !WARN_ON(ce->engine->class != RENDER_CLASS))
+   ret = intel_context_reconfigure_sseu(ce, sseu);
+
+   return ret;
  }
  
  static void __free_engines(struct i915_gem_engines *e, unsigned int count)

@@ -416,7 +425,8 @@ static struct i915_gem_engines *alloc_engines(unsigned int 
count)
return e;
  }
  
-static struct i915_gem_engines *default_engines(struct i915_gem_context *ctx)

+static struct i915_gem_engines *default_engines(struct i915_gem_context *ctx,
+   struct intel_sseu rcs_sseu)
  {
const struct intel_gt *gt = &ctx->i915->gt;
struct intel_engine_cs *engine;
@@ -429,6 +439,8 @@ static struct i915_gem_engines *default_engines(struct 
i915_gem_context *ctx)
  
  	for_each_engine(engine, gt, id) {

struct intel_context *ce;
+   struct intel_sseu sseu = {};
+   int ret;
  
  		if (engine->legacy_idx == INVALID_ENGINE)

continue;
@@ -442,10 +454,18 @@ static struct i915_gem_engines *default_engines(struct 
i915_gem_context *ctx)
goto free_engines;
}
  
-		intel_context_set_gem(ce, ctx);

-
e->engines[engine->legacy_idx] = ce;
e->num_engines = max(e->num_engines, engine->legacy_idx + 1);
+
+   if (engine->class == RENDER_CLASS)
+   sseu = rcs_sseu;
+
+   ret = intel_context_set_gem(ce, ctx, sseu);
+   if (ret) {
+   err = ERR_PTR(ret);
+   goto free_engines;
+   }
+
}
  
  	return e;

@@ -759,6 +779,7 @@ __create_context(struct drm_i915_private *i915,
  {
struct i915_gem_context *ctx;
struct i915_gem_engines *e;
+   struct intel_sseu null_sseu = {};
int err;
int i;
  
@@ -776,7 +797,7 @@ __create_context(struct drm_i915_private *i915,

INIT_LIST_HEAD(&ctx->stale.engines);
  
  	mutex_init(&ctx->engines_mutex);

-   e = default_engines(ctx);
+   e = default_engines(ctx, null_sseu);
if (IS_ERR(e)) {
err = PTR_ERR(e);
goto err_free;
@@ -1544,6 +1565,7 @@ set_engines__load_balance(struct i915_user_extension 
__user *base, void *data)
struct intel_engine_cs *stack[16];
struct intel_engine_cs **siblings;
struct intel_context *ce;
+   struct intel_sseu null_sseu = {};
u16 num_siblings, idx;
unsigned int n;
int err;
@@ -1616,7 +1638,7 @@ set_engines__load_balance(struct i915_user_extension 
__user *base, void *data)
goto out_siblings;
}
  
-	intel_context_set_gem(ce, set->ctx);

+   intel_context_set_gem(ce, set->ctx, null_sseu);
  
  	if (cmpxchg(&set->engines->engines[idx], NULL, ce)) {

intel_context_put(ce);
@@ -1724,6 +1746,7 @@ set_engines(struct i915_gem_context *ctx,
struct drm_i915_private *i915 = ctx->i915;
struct i915_context_param_engines __user *user =
u64_to_user_ptr(args->value);
+   struct intel_sse

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Associate ACPI connector nodes with connector entries

[Hans de Goede]

Hi,

On 5/5/21 11:17 AM, Andy Shevchenko wrote:
> On Wed, May 5, 2021 at 12:07 PM Hans de Goede  wrote:
>> On 5/4/21 9:52 AM, Andy Shevchenko wrote:
>>> On Monday, May 3, 2021, Hans de Goede >> > wrote:
> 
> ...
> 
>>> +   fwnode = device_get_next_child_node(kdev, fwnode);
> 
>>> Who is dropping reference counting on fwnode ?
>>
>> We are dealing with ACPI fwnode-s here and those are not ref-counted, they
>> are embedded inside a struct acpi_device and their lifetime is tied to
>> that struct. They should probably still be ref-counted (with the count
>> never dropping to 0) so that the generic fwnode functions behave the same
>> anywhere but atm the ACPI nodes are not refcounted, see: 
>> acpi_get_next_subnode()
>> in drivers/acpi/property.c which is the get_next_child_node() implementation
>> for ACPI fwnode-s.
> 
> Yes, ACPI currently is exceptional, but fwnode API is not.
> If you may guarantee that this case won't ever be outside of ACPI

Yes I can guarantee that currently this code (which is for the i915
driver only) only deals with ACPI fwnodes.

> and
> even though if ACPI won't ever gain a reference counting for fwnodes,
> we can leave it as is.

Would it not be better to add fake ref-counting to the ACPI fwnode
next_child_node() op though. I believe just getting a reference
on the return value there should work fine; and then all fwnode
implementations would be consistent ?

(note I did not check that the of and swnode code do return
a reference but I would assume so).

>>> I’m in the middle of a pile of fixes for fwnode refcounting when 
>>> for_each_child or get_next_child is used. So, please double check you drop 
>>> a reference.
>>
>> The kdoc comments on device_get_next_child_node() / 
>> fwnode_get_next_child_node()
>> do not mention anything about these functions returning a reference.
> 
> It's possible. I dunno if it had to be done earlier. Sakari?
> 
>> So I think we need to first make up our mind here how we want this all to
>> work and then fix the actual implementation and docs before fixing callers.
> 
> We have already issues, so I prefer not to wait for a documentation
> update, because for old kernels it will still be an issue.

I wonder if we really have issues though, in practice fwnodes are
generated from an devicetree or ACPI tables (or by platform codes
adding swnodes) and then these pretty much stick around for ever.

IOW the initial refcount of 1 is never dropped at least for of-nodes
and ACPI nodes.  I know there are some exceptions like device-tree
overlays which I guess may also be dynamically removed again, but those
exceptions are not widely used.

And if we forget to drop a reference in the worst case we have a small
non-re-occuring (so not growing) memleak. Where as if we start adding
put() calls everywhere we may end up freeing things which are still
in use; or dropping refcounts below 0 triggering WARNs in various
places (IIRC).

So it seems the cure is potentially worse then the disease in this
case.

So if you want to work on this, then IMHO it would be best to first make
sure that all the fwnode implementations behave in the same way wrt
ref-counting, before adding the missing put() calls in various
places.

And once the behavior is consistent then we can also document this
properly making it easier for other people to do the right thing
when using these functions.

Regards,

Hans

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

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Associate ACPI connector nodes with connector entries

[Andy Shevchenko]

On Wed, May 5, 2021 at 12:07 PM Hans de Goede  wrote:
> On 5/4/21 9:52 AM, Andy Shevchenko wrote:
> > On Monday, May 3, 2021, Hans de Goede  > > wrote:

...

> > +   fwnode = device_get_next_child_node(kdev, fwnode);

> > Who is dropping reference counting on fwnode ?
>
> We are dealing with ACPI fwnode-s here and those are not ref-counted, they
> are embedded inside a struct acpi_device and their lifetime is tied to
> that struct. They should probably still be ref-counted (with the count
> never dropping to 0) so that the generic fwnode functions behave the same
> anywhere but atm the ACPI nodes are not refcounted, see: 
> acpi_get_next_subnode()
> in drivers/acpi/property.c which is the get_next_child_node() implementation
> for ACPI fwnode-s.

Yes, ACPI currently is exceptional, but fwnode API is not.
If you may guarantee that this case won't ever be outside of ACPI and
even though if ACPI won't ever gain a reference counting for fwnodes,
we can leave it as is.

> > I’m in the middle of a pile of fixes for fwnode refcounting when 
> > for_each_child or get_next_child is used. So, please double check you drop 
> > a reference.
>
> The kdoc comments on device_get_next_child_node() / 
> fwnode_get_next_child_node()
> do not mention anything about these functions returning a reference.

It's possible. I dunno if it had to be done earlier. Sakari?

> So I think we need to first make up our mind here how we want this all to
> work and then fix the actual implementation and docs before fixing callers.

We have already issues, so I prefer not to wait for a documentation
update, because for old kernels it will still be an issue.

In any case most of my fixes are against LED subsystem (drivers) and
they are valid due to use in the OF environment.

-- 
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Associate ACPI connector nodes with connector entries

[Hans de Goede]

Hi,

On 5/4/21 9:52 AM, Andy Shevchenko wrote:
> 
> 
> On Monday, May 3, 2021, Hans de Goede  > wrote:
> 
> From: Heikki Krogerus  >
> 
> On Intel platforms we know that the ACPI connector device
> node order will follow the order the driver (i915) decides.
> The decision is made using the custom Intel ACPI OpRegion
> (intel_opregion.c), though the driver does not actually know
> that the values it sends to ACPI there are used for
> associating a device node for the connectors, and assigning
> address for them.
> 
> In reality that custom Intel ACPI OpRegion actually violates
> ACPI specification (we supply dynamic information to objects
> that are defined static, for example _ADR), however, it
> makes assigning correct connector node for a connector entry
> straightforward (it's one-on-one mapping).
> 
> Signed-off-by: Heikki Krogerus  >
> [hdego...@redhat.com : Move 
> intel_acpi_assign_connector_fwnodes() to
>  intel_acpi.c]
> Signed-off-by: Hans de Goede  >
> ---
>  drivers/gpu/drm/i915/display/intel_acpi.c    | 40 
>  drivers/gpu/drm/i915/display/intel_acpi.h    |  3 ++
>  drivers/gpu/drm/i915/display/intel_display.c |  1 +
>  3 files changed, 44 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c 
> b/drivers/gpu/drm/i915/display/intel_acpi.c
> index 833d0c1be4f1..9f266dfda7dd 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> @@ -263,3 +263,43 @@ void intel_acpi_device_id_update(struct 
> drm_i915_private *dev_priv)
>         }
>         drm_connector_list_iter_end(&conn_iter);
>  }
> +
> +/* NOTE: The connector order must be final before this is called. */
> +void intel_acpi_assign_connector_fwnodes(struct drm_i915_private *i915)
> +{
> +       struct drm_connector_list_iter conn_iter;
> +       struct drm_device *drm_dev = &i915->drm;
> +       struct device *kdev = &drm_dev->pdev->dev;
> +       struct fwnode_handle *fwnode = NULL;
> +       struct drm_connector *connector;
> +       struct acpi_device *adev;
> +
> +       drm_connector_list_iter_begin(drm_dev, &conn_iter);
> +       drm_for_each_connector_iter(connector, &conn_iter) {
> +               /* Always getting the next, even when the last was not 
> used. */
> +               fwnode = device_get_next_child_node(kdev, fwnode);
> +               if (!fwnode)
> +                       break;
> 
> 
> 
> Who is dropping reference counting on fwnode ?

We are dealing with ACPI fwnode-s here and those are not ref-counted, they
are embedded inside a struct acpi_device and their lifetime is tied to
that struct. They should probably still be ref-counted (with the count
never dropping to 0) so that the generic fwnode functions behave the same
anywhere but atm the ACPI nodes are not refcounted, see: acpi_get_next_subnode()
in drivers/acpi/property.c which is the get_next_child_node() implementation
for ACPI fwnode-s.

> I’m in the middle of a pile of fixes for fwnode refcounting when 
> for_each_child or get_next_child is used. So, please double check you drop a 
> reference.

The kdoc comments on device_get_next_child_node() / fwnode_get_next_child_node()
do not mention anything about these functions returning a reference.

So I think we need to first make up our mind here how we want this all to
work and then fix the actual implementation and docs before fixing callers.

Regards,

Hans




>  
> 
> +
> +               switch (connector->connector_type) {
> +               case DRM_MODE_CONNECTOR_LVDS:
> +               case DRM_MODE_CONNECTOR_eDP:
> +               case DRM_MODE_CONNECTOR_DSI:
> +                       /*
> +                        * Integrated displays have a specific address 
> 0x1f on
> +                        * most Intel platforms, but not on all of them.
> +                        */
> +                       adev = 
> acpi_find_child_device(ACPI_COMPANION(kdev),
> +                                                     0x1f, 0);
> +                       if (adev) {
> +                               connector->fwnode = 
> acpi_fwnode_handle(adev);
> +                               break;
> +                       }
> +                       fallthrough;
> +               default:
> +                       connector->fwnode = fwnode;
> +                       break;
> +               }
> +       }
> +       drm_connector_list_iter_end(&conn_iter);
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_acpi.h 
> b/drivers/gpu/drm/i915/display/intel_acpi.h
> index e8b068661d22..d24356

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Use correct downstream caps for check Src-Ctl mode for PCON (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Use correct downstream caps for check Src-Ctl mode for PCON 
(rev2)
URL   : https://patchwork.freedesktop.org/series/89639/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10047 -> Patchwork_20065


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_20065 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_20065, 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_20065/index.html

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-tgl-y:   [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10047/fi-tgl-y/igt@i915_selftest@live@gt_heartbeat.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20065/fi-tgl-y/igt@i915_selftest@live@gt_heartbeat.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@semaphore:
- fi-bsw-nick:NOTRUN -> [SKIP][3] ([fdo#109271]) +17 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20065/fi-bsw-nick/igt@amdgpu/amd_ba...@semaphore.html

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

  * igt@gem_exec_gttfill@basic:
- fi-bsw-n3050:   NOTRUN -> [SKIP][5] ([fdo#109271])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20065/fi-bsw-n3050/igt@gem_exec_gttf...@basic.html

  * igt@gem_exec_suspend@basic-s3:
- fi-bsw-n3050:   NOTRUN -> [INCOMPLETE][6] ([i915#3159])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20065/fi-bsw-n3050/igt@gem_exec_susp...@basic-s3.html

  
 Possible fixes 

  * igt@i915_pm_rpm@basic-rte:
- {fi-tgl-1115g4}:[DMESG-WARN][7] ([i915#402]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10047/fi-tgl-1115g4/igt@i915_pm_...@basic-rte.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20065/fi-tgl-1115g4/igt@i915_pm_...@basic-rte.html

  * igt@i915_pm_rpm@module-reload:
- {fi-tgl-1115g4}:[DMESG-WARN][9] ([k.org#205379]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10047/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20065/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@late_gt_pm:
- fi-bsw-nick:[DMESG-FAIL][11] ([i915#2927]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10047/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20065/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.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#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
  [i915#2927]: https://gitlab.freedesktop.org/drm/intel/issues/2927
  [i915#3159]: https://gitlab.freedesktop.org/drm/intel/issues/3159
  [i915#3277]: https://gitlab.freedesktop.org/drm/intel/issues/3277
  [i915#3283]: https://gitlab.freedesktop.org/drm/intel/issues/3283
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [k.org#205379]: https://bugzilla.kernel.org/show_bug.cgi?id=205379


Participating hosts (43 -> 40)
--

  Additional (1): fi-bsw-n3050 
  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_10047 -> Patchwork_20065

  CI-20190529: 20190529
  CI_DRM_10047: 6bc6aeb4870cfb28f24523f42157cf9a86be80d7 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6077: 126a3f6fc0e97786e2819085efc84e741093aed5 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_20065: 9065f5d90df031d6e8a262a19ee067456b09d263 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

9065f5d90df0 drm/i915: Use correct downstream caps for check Src-Ctl mode for 
PCON

== Logs ==

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

[Intel-gfx] [PATCH v2] drm/i915: Use correct downstream caps for check Src-Ctl mode for PCON

[Ankit Nautiyal]

Fix the typo in DPCD caps used for checking SRC CTL mode of
HDMI2.1 PCON

v2: Corrected Fixes tag (Jani Nikula).

Fixes: 04b6603d13be ("drm/i915/display: Configure HDMI2.1 Pcon for FRL
only if Src-Ctl mode is available")
Cc: Ankit Nautiyal 
Cc: Uma Shankar 
Cc: Jani Nikula 
Cc: "Ville Syrj_l_" 
Cc: Imre Deak 
Cc: Manasi Navare 
Cc: Gwan-gyeong Mun 
Cc: Lucas De Marchi 
Cc: Sean Paul 

Signed-off-by: Ankit Nautiyal 
---
 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 dfa7da928ae5..b3e82aa8b4f8 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2112,7 +2112,7 @@ void intel_dp_check_frl_training(struct intel_dp 
*intel_dp)
 * -PCON supports SRC_CTL_MODE (VESA DP2.0-HDMI2.1 PCON Spec Draft-1 
Sec-7)
 * -sink is HDMI2.1
 */
-   if (!(intel_dp->dpcd[2] & DP_PCON_SOURCE_CTL_MODE) ||
+   if (!(intel_dp->downstream_ports[2] & DP_PCON_SOURCE_CTL_MODE) ||
!intel_dp_is_hdmi_2_1_sink(intel_dp) ||
intel_dp->frl.is_trained)
return;
-- 
2.29.2

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

Re: [Intel-gfx] [PATCH] drm/i915: Use correct downstream caps for check Src-Ctl mode for PCON

[Nautiyal, Ankit K]

On 5/3/2021 11:03 PM, Jani Nikula wrote:

On Thu, 29 Apr 2021, Ankit Nautiyal  wrote:

Fix the typo in DPCD caps used for checking SRC CTL mode of
HDMI2.1 PCON

Fixes: 04b6603d13be (drm/i915/display: Configure HDMI2.1 Pcon for FRL
only if Src-Ctl mode is available)

Correct format for Fixes: is this:

Fixes: 04b6603d13be ("drm/i915/display: Configure HDMI2.1 Pcon for FRL only if 
Src-Ctl mode is available")

You'll get it with 'dim fixes ', along with some suggested Cc's.

BR,
Jani.



Thanks Jani for pointing this out. I Will use dim fixes as suggested and 
send updated version.


Regards,

Ankit





Signed-off-by: Ankit Nautiyal 
---
  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 dfa7da928ae5..b3e82aa8b4f8 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2112,7 +2112,7 @@ void intel_dp_check_frl_training(struct intel_dp 
*intel_dp)
 * -PCON supports SRC_CTL_MODE (VESA DP2.0-HDMI2.1 PCON Spec Draft-1 
Sec-7)
 * -sink is HDMI2.1
 */
-   if (!(intel_dp->dpcd[2] & DP_PCON_SOURCE_CTL_MODE) ||
+   if (!(intel_dp->downstream_ports[2] & DP_PCON_SOURCE_CTL_MODE) ||
!intel_dp_is_hdmi_2_1_sink(intel_dp) ||
intel_dp->frl.is_trained)
return;

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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm/i915: Don't include intel_de.h from intel_display_types.h (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/2] drm/i915: Don't include intel_de.h from 
intel_display_types.h (rev2)
URL   : https://patchwork.freedesktop.org/series/89698/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10039_full -> Patchwork_20053_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@legacy-engines-hostile@bsd2:
- shard-tglb: [PASS][1] -> [FAIL][2] ([i915#2410])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10039/shard-tglb7/igt@gem_ctx_persistence@legacy-engines-host...@bsd2.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20053/shard-tglb6/igt@gem_ctx_persistence@legacy-engines-host...@bsd2.html

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

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

  * igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk:  [PASS][5] -> [FAIL][6] ([i915#2842])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10039/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20053/shard-glk8/igt@gem_exec_fair@basic-none-r...@rcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10039/shard-tglb2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20053/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10039/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20053/shard-iclb2/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar 
issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10039/shard-kbl3/igt@gem_exec_fair@basic-p...@vecs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20053/shard-kbl3/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][13] -> [FAIL][14] ([i915#2849])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10039/shard-iclb7/igt@gem_exec_fair@basic-throt...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20053/shard-iclb1/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_huc_copy@huc-copy:
- shard-apl:  NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#2190])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20053/shard-apl8/igt@gem_huc_c...@huc-copy.html

  * igt@gem_mmap_gtt@cpuset-medium-copy-odd:
- shard-skl:  [PASS][16] -> [FAIL][17] ([i915#307])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10039/shard-skl4/igt@gem_mmap_...@cpuset-medium-copy-odd.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20053/shard-skl10/igt@gem_mmap_...@cpuset-medium-copy-odd.html

  * igt@gem_userptr_blits@input-checking:
- shard-skl:  NOTRUN -> [DMESG-WARN][18] ([i915#3002])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20053/shard-skl5/igt@gem_userptr_bl...@input-checking.html

  * igt@gem_userptr_blits@set-cache-level:
- shard-snb:  NOTRUN -> [FAIL][19] ([i915#3324])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20053/shard-snb7/igt@gem_userptr_bl...@set-cache-level.html

  * igt@gem_userptr_blits@vma-merge:
- shard-skl:  NOTRUN -> [FAIL][20] ([i915#3318])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20053/shard-skl7/igt@gem_userptr_bl...@vma-merge.html

  * igt@kms_big_fb@yf-tiled-addfb:
- shard-tglb: NOTRUN -> [SKIP][21] ([fdo#111615])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20053/shard-tglb3/igt@kms_big...@yf-tiled-addfb.html

  * igt@kms_color@pipe-c-ctm-max:
- shard-skl:  [PASS][22] -> [DMESG-WARN][23] ([i915#1982])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10039/shard-skl7/igt@kms_co...@pipe-c-ctm-max.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20053/shard-skl2/igt@kms_co...@pipe-c-ctm-max.html

  * igt@kms_color_chamelium@pipe-a-ctm-limited