[Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm tree

2021-03-31 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/display/intel_display.c

between commit:

  1b321026e213 ("drm/i915: Pass ww ctx to intel_pin_to_display_plane")

from the drm tree and commit:

  61169987c4d9 ("drm/i915: Unify the FB and plane state view information into 
one struct")

from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/display/intel_display.c
index aa524eff20e1,bdb2adb4d748..
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@@ -1185,13 -1094,13 +1112,13 @@@ retry
 * mode that matches the user configuration.
 */
ret = i915_vma_pin_fence(vma);
-   if (ret != 0 && INTEL_GEN(dev_priv) < 4) {
+   if (ret != 0 && DISPLAY_VER(dev_priv) < 4) {
i915_vma_unpin(vma);
 -  vma = ERR_PTR(ret);
 -  goto err;
 +  goto err_unpin;
}
 +  ret = 0;
  
 -  if (ret == 0 && vma->fence)
 +  if (vma->fence)
*out_flags |= PLANE_HAS_FENCE;
}
  
@@@ -11363,12 -10508,20 +10536,12 @@@ int intel_plane_pin_fb(struct intel_pla
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
struct drm_framebuffer *fb = plane_state->hw.fb;
struct i915_vma *vma;
 +  bool phys_cursor =
 +  plane->id == PLANE_CURSOR &&
 +  INTEL_INFO(dev_priv)->display.cursor_needs_physical;
  
 -  if (plane->id == PLANE_CURSOR &&
 -  INTEL_INFO(dev_priv)->display.cursor_needs_physical) {
 -  struct drm_i915_gem_object *obj = intel_fb_obj(fb);
 -  const int align = intel_cursor_alignment(dev_priv);
 -  int err;
 -
 -  err = i915_gem_object_attach_phys(obj, align);
 -  if (err)
 -  return err;
 -  }
 -
 -  vma = intel_pin_and_fence_fb_obj(fb,
 +  vma = intel_pin_and_fence_fb_obj(fb, phys_cursor,
-&plane_state->view,
+&plane_state->view.gtt,
 intel_plane_uses_fence(plane_state),
 &plane_state->flags);
if (IS_ERR(vma))


pgp3kDl8rYgYa.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/adl_s: ADL-S platform Update PCI ids for Mobile BGA

2021-03-31 Thread Aditya Swarup
On 2/3/21 1:10 AM, Anand Moon wrote:
> As per Bspec: 53655 Update PCI ids for Mobile BGA.
> 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Signed-off-by: Anand Moon 

Reviewed-by: Aditya Swarup 

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

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


Re: [Intel-gfx] [PATCH] drm/i915: Uninit the DMC FW loader state during shutdown

2021-03-31 Thread Ed Baker
On 3/11/21 7:45 AM, Imre Deak wrote:
> We need to wait for the DMC FW loader work to complete during shutdown,
> even if it's unlikely to be still pending by that time, fix this.
> 
> This also fixes the wakeref tracking WARN during shutdown about the
> leaked reference we hold due to a missing DMC firmware.
> 
> While at it add a TODO comment about unifying the shutdown and PM
> power-off sequences and later these sequences with the driver remove and
> system/runtime suspend sequences.
> 
> Cc: Ville Syrjälä 
> References: 
> https://lore.kernel.org/lkml/20210303055517.GB2708@xsang-OptiPlex-9020
> Reported-by: kernel test robot 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 3edd5e47ad68..4a0e491e9692 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1038,10 +1038,18 @@ void i915_driver_shutdown(struct drm_i915_private 
> *i915)
>   intel_suspend_encoders(i915);
>   intel_shutdown_encoders(i915);
>  
> + intel_csr_ucode_suspend(i915);
> +
>   /*
>* The only requirement is to reboot with display DC states disabled,
>* for now leaving all display power wells in the INIT power domain
> -  * enabled matching the driver reload sequence.
> +  * enabled.
> +  *
> +  * TODO:
> +  * - unify the pci_driver::shutdown sequence here with the
> +  *   pci_driver.driver.pm.poweroff,poweroff_late sequence.
> +  * - unify the driver remove and system/runtime suspend sequences with
> +  *   the above unified shutdown/poweroff sequence.
>*/
>   intel_power_domains_driver_remove(i915);
>   enable_rpm_wakeref_asserts(&i915->runtime_pm);
> 

Verified on a TGL i5 system. This patch was applied on top of Google's 5.4 
kernel for Chrome OS 
(https://chromium.googlesource.com/chromiumos/third_party/kernel/+/62a7016219 
specifically).

Tested-by: Edward Baker 
___
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/pmu: Check actual RC6 status

2021-03-31 Thread Patchwork
== Series Details ==

Series: drm/i915/pmu: Check actual RC6 status
URL   : https://patchwork.freedesktop.org/series/88608/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9918_full -> Patchwork_19884_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_19884_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_19884_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_19884_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- shard-glk:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9918/shard-glk9/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19884/shard-glk7/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_exec_fair@basic-deadline:
- shard-kbl:  NOTRUN -> [FAIL][5] ([i915#2846])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19884/shard-kbl7/igt@gem_exec_f...@basic-deadline.html
- shard-apl:  NOTRUN -> [FAIL][6] ([i915#2846])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19884/shard-apl3/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9918/shard-tglb8/igt@gem_exec_fair@basic-f...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19884/shard-tglb8/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-kbl:  [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9918/shard-kbl4/igt@gem_exec_fair@basic-none-...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19884/shard-kbl4/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk:  [PASS][11] -> [FAIL][12] ([i915#2842]) +2 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9918/shard-glk8/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19884/shard-glk8/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_reloc@basic-many-active@vcs0:
- shard-kbl:  NOTRUN -> [FAIL][13] ([i915#2389]) +4 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19884/shard-kbl1/igt@gem_exec_reloc@basic-many-act...@vcs0.html

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

  * igt@gem_exec_schedule@semaphore-codependency:
- shard-snb:  NOTRUN -> [SKIP][15] ([fdo#109271]) +260 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19884/shard-snb2/igt@gem_exec_sched...@semaphore-codependency.html

  * igt@gem_exec_whisper@basic-fds-priority:
- shard-glk:  [PASS][16] -> [DMESG-WARN][17] ([i915#118] / 
[i915#95])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9918/shard-glk9/igt@gem_exec_whis...@basic-fds-priority.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19884/shard-glk7/igt@gem_exec_whis...@basic-fds-priority.html

  * igt@gem_mmap_gtt@cpuset-big-copy-xy:
- shard-iclb: [PASS][18] -> [FAIL][19] ([i915#307])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9918/shard-iclb2/igt@gem_mmap_...@cpuset-big-copy-xy.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19884/shard-iclb5/igt@gem_mmap_...@cpuset-big-copy-xy.html

  * igt@gem_softpin@noreloc-s3:
- shard-skl:  NOTRUN -> [INCOMPLETE][20] ([i915#146] / [i915#198] / 
[i915#2405])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19884/shard-skl9/igt@gem_soft...@noreloc-s3.html

  * igt@g

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Check actual RC6 status

2021-03-31 Thread Patchwork
== Series Details ==

Series: drm/i915/pmu: Check actual RC6 status
URL   : https://patchwork.freedesktop.org/series/88608/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9918 -> Patchwork_19884


Summary
---

  **SUCCESS**

  No regressions found.

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

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@gt_pm:
- {fi-tgl-dsi}:   [DMESG-FAIL][1] ([i915#1759]) -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9918/fi-tgl-dsi/igt@i915_selftest@live@gt_pm.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19884/fi-tgl-dsi/igt@i915_selftest@live@gt_pm.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_flink_basic@flink-lifetime:
- fi-tgl-y:   [PASS][5] -> [DMESG-WARN][6] ([i915#402])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9918/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19884/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html

  * igt@runner@aborted:
- fi-bdw-5557u:   NOTRUN -> [FAIL][7] ([i915#1602] / [i915#2029])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19884/fi-bdw-5557u/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_close_race@basic-threads:
- fi-tgl-y:   [DMESG-WARN][8] ([i915#402]) -> [PASS][9] +1 similar 
issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9918/fi-tgl-y/igt@gem_close_r...@basic-threads.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19884/fi-tgl-y/igt@gem_close_r...@basic-threads.html

  
 Warnings 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-glk-dsi: [DMESG-WARN][10] ([i915#3143]) -> [DMESG-WARN][11] 
([i915#1982] / [i915#3143]) +1 similar issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9918/fi-glk-dsi/igt@i915_pm_...@basic-pci-d3-state.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19884/fi-glk-dsi/igt@i915_pm_...@basic-pci-d3-state.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#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
  [i915#1759]: https://gitlab.freedesktop.org/drm/intel/issues/1759
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
  [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
  [i915#2966]: https://gitlab.freedesktop.org/drm/intel/issues/2966
  [i915#3143]: https://gitlab.freedesktop.org/drm/intel/issues/3143
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (46 -> 41)
--

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


Build changes
-

  * Linux: CI_DRM_9918 -> Patchwork_19884

  CI-20190529: 20190529
  CI_DRM_9918: 0db277f29b11285812180862d5a2dd33fedf99b1 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6051: 59becc29a9adc35b991cf5d3e221cd133bf0221b @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_19884: 2fe92710c5d753ddf416b40542e7190238eb3cf2 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

2fe92710c5d7 drm/i915/pmu: Check actual RC6 status

== Logs ==

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


Re: [Intel-gfx] [PATCH v2 0/8] drm/edid: overhaul displayid iterator

2021-03-31 Thread Jani Nikula
On Mon, 29 Mar 2021, Jani Nikula  wrote:
> v2 of [1], addressing Ville's review comments, and adding a couple of
> extra patches on top.
>
> BR,
> Jani.
>
> [1] https://patchwork.freedesktop.org/series/87802/

Pushed to drm-misc-next, with Ville's review and Maxime's IRC nod of
approval. Thanks. :)

BR,
Jani.

>
>
> Jani Nikula (8):
>   drm/edid: make a number of functions, parameters and variables const
>   drm/displayid: add separate drm_displayid.c
>   drm/displayid: add new displayid section/block iterators
>   drm/edid: use the new displayid iterator for detailed modes
>   drm/edid: use the new displayid iterator for finding CEA extension
>   drm/edid: use the new displayid iterator for tile info
>   drm/displayid: allow data blocks with 0 payload length
>   drm/displayid: rename displayid_hdr to displayid_header
>
>  drivers/gpu/drm/Makefile|   2 +-
>  drivers/gpu/drm/drm_displayid.c | 132 
>  drivers/gpu/drm/drm_edid.c  | 171 +++-
>  include/drm/drm_displayid.h |  30 --
>  include/drm/drm_edid.h  |   3 +
>  5 files changed, 196 insertions(+), 142 deletions(-)
>  create mode 100644 drivers/gpu/drm/drm_displayid.c

-- 
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.DOCS: warning for drm/i915/pmu: Check actual RC6 status

2021-03-31 Thread Patchwork
== Series Details ==

Series: drm/i915/pmu: Check actual RC6 status
URL   : https://patchwork.freedesktop.org/series/88608/
State : warning

== Summary ==

$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter 
or member 'ww' not described in 'i915_gem_shrink'
./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function 
parameter 'trampoline' description in 'intel_engine_cmd_parser'
./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or 
member 'jump_whitelist' not described in 'intel_engine_cmd_parser'
./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or 
member 'shadow_map' not described in 'intel_engine_cmd_parser'
./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or 
member 'batch_map' not described in 'intel_engine_cmd_parser'
./drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function 
parameter 'trampoline' description in 'intel_engine_cmd_parser'


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


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

2021-03-31 Thread Michal Koutný
On Tue, Mar 30, 2021 at 11:00:36AM +0200, Arnd Bergmann  wrote:
> Would it be possible to enclose most or all of kernel/cgroup/cgroup.c
> in an #ifdef CGROUP_SUBSYS_COUNT block?
Even without any controllers, there can still be named hierarchies (v1)
or the default hierarchy (v2) (for instance) for process tracking
purposes. So only parts of kernel/cgroup/cgroup.c could be ifdef'd.

Beware that CGROUP_SUBSYS_COUNT is not known at preprocessing stage (you
could have a macro alternative though).

> I didn't try that myself, but this might be a way to guarantee that
> there cannot be any callers (it would cause a link error).
Such a guarantee would be nicer, I agree. I tried a bit but anandoned it
when I saw macros proliferate (which I found less readable than your
current variant). But YMMV.

Michal


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


Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/hdcp: Add DP HDCP2.2 timeout to read entire msg

2021-03-31 Thread Jani Nikula
On Thu, 25 Mar 2021, "Nautiyal, Ankit K"  wrote:
> LGTM.
>
> Reviewed-by: Ankit Nautiyal 

Both patches pushed to drm-intel-next with Maxime's irc ack.

BR,
Jani.


>
> On 3/24/2021 5:00 PM, Anshuman Gupta wrote:
>> As documented in HDCP 2.2 DP Errata spec transmitter should abort the
>> authentication protocol in case transmitter has not received the
>> entire {AKE_Send_Cert, AKE_Send_H_prime, AKE_Send_Paring_Info} msg
>> within {110,7,5} miliseconds.
>>
>> Adding above msg timeout values and aborting the HDCP authentication
>> in case it timedout to read entire msg.
>>
>> https://www.digital-cp.com/sites/default/files/HDCP%202_2_DisplayPort_Errata_v3_0.pdf
>>
>> v2:
>> - Removed redundant variable msg_can_timedout. [Ankit]
>>
>> Cc: Ramalingam C 
>> Signed-off-by: Anshuman Gupta 
>> ---
>>   drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 45 ++--
>>   include/drm/drm_hdcp.h   |  3 ++
>>   2 files changed, 35 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c 
>> b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
>> index 40c516e90193..8bad4b3d34dd 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
>> @@ -294,37 +294,39 @@ struct hdcp2_dp_msg_data {
>>  bool msg_detectable;
>>  u32 timeout;
>>  u32 timeout2; /* Added for non_paired situation */
>> +/* Timeout to read entire msg */
>> +u32 msg_read_timeout;
>>   };
>>   
>>   static const struct hdcp2_dp_msg_data hdcp2_dp_msg_data[] = {
>> -{ HDCP_2_2_AKE_INIT, DP_HDCP_2_2_AKE_INIT_OFFSET, false, 0, 0 },
>> +{ HDCP_2_2_AKE_INIT, DP_HDCP_2_2_AKE_INIT_OFFSET, false, 0, 0, 0},
>>  { HDCP_2_2_AKE_SEND_CERT, DP_HDCP_2_2_AKE_SEND_CERT_OFFSET,
>> -  false, HDCP_2_2_CERT_TIMEOUT_MS, 0 },
>> +  false, HDCP_2_2_CERT_TIMEOUT_MS, 0, HDCP_2_2_DP_CERT_READ_TIMEOUT_MS},
>>  { HDCP_2_2_AKE_NO_STORED_KM, DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET,
>> -  false, 0, 0 },
>> +  false, 0, 0, 0 },
>>  { HDCP_2_2_AKE_STORED_KM, DP_HDCP_2_2_AKE_STORED_KM_OFFSET,
>> -  false, 0, 0 },
>> +  false, 0, 0, 0 },
>>  { HDCP_2_2_AKE_SEND_HPRIME, DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET,
>>true, HDCP_2_2_HPRIME_PAIRED_TIMEOUT_MS,
>> -  HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS },
>> +  HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS, 
>> HDCP_2_2_DP_HPRIME_READ_TIMEOUT_MS},
>>  { HDCP_2_2_AKE_SEND_PAIRING_INFO,
>>DP_HDCP_2_2_AKE_SEND_PAIRING_INFO_OFFSET, true,
>> -  HDCP_2_2_PAIRING_TIMEOUT_MS, 0 },
>> -{ HDCP_2_2_LC_INIT, DP_HDCP_2_2_LC_INIT_OFFSET, false, 0, 0 },
>> +  HDCP_2_2_PAIRING_TIMEOUT_MS, 0, HDCP_2_2_DP_PAIRING_READ_TIMEOUT_MS },
>> +{ HDCP_2_2_LC_INIT, DP_HDCP_2_2_LC_INIT_OFFSET, false, 0, 0, 0 },
>>  { HDCP_2_2_LC_SEND_LPRIME, DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET,
>> -  false, HDCP_2_2_DP_LPRIME_TIMEOUT_MS, 0 },
>> +  false, HDCP_2_2_DP_LPRIME_TIMEOUT_MS, 0, 0 },
>>  { HDCP_2_2_SKE_SEND_EKS, DP_HDCP_2_2_SKE_SEND_EKS_OFFSET, false,
>> -  0, 0 },
>> +  0, 0, 0 },
>>  { HDCP_2_2_REP_SEND_RECVID_LIST,
>>DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET, true,
>> -  HDCP_2_2_RECVID_LIST_TIMEOUT_MS, 0 },
>> +  HDCP_2_2_RECVID_LIST_TIMEOUT_MS, 0, 0 },
>>  { HDCP_2_2_REP_SEND_ACK, DP_HDCP_2_2_REP_SEND_ACK_OFFSET, false,
>> -  0, 0 },
>> +  0, 0, 0 },
>>  { HDCP_2_2_REP_STREAM_MANAGE,
>>DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET, false,
>> -  0, 0 },
>> +  0, 0, 0},
>>  { HDCP_2_2_REP_STREAM_READY, DP_HDCP_2_2_REP_STREAM_READY_OFFSET,
>> -  false, HDCP_2_2_STREAM_READY_TIMEOUT_MS, 0 },
>> +  false, HDCP_2_2_STREAM_READY_TIMEOUT_MS, 0, 0 },
>>   /* local define to shovel this through the write_2_2 interface */
>>   #define HDCP_2_2_ERRATA_DP_STREAM_TYPE 50
>>  { HDCP_2_2_ERRATA_DP_STREAM_TYPE,
>> @@ -513,6 +515,8 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port 
>> *dig_port,
>>  u8 *byte = buf;
>>  ssize_t ret, bytes_to_recv, len;
>>  const struct hdcp2_dp_msg_data *hdcp2_msg_data;
>> +ktime_t msg_end;
>> +bool msg_expired;
>>   
>>  hdcp2_msg_data = get_hdcp2_dp_msg_data(msg_id);
>>  if (!hdcp2_msg_data)
>> @@ -539,6 +543,11 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port 
>> *dig_port,
>>  len = bytes_to_recv > DP_AUX_MAX_PAYLOAD_BYTES ?
>>DP_AUX_MAX_PAYLOAD_BYTES : bytes_to_recv;
>>   
>> +/* Entire msg read timeout since initiate of msg read */
>> +if (bytes_to_recv == size - 1 && 
>> hdcp2_msg_data->msg_read_timeout > 0)
>> +msg_end = ktime_add_ms(ktime_get_raw(),
>> +   
>> hdcp2_msg_data->msg_read_timeout);
>> +
>>  ret = drm_dp_dpcd_read(&dig_port->dp.aux, offset,
>> (void *)byte, len);
>>  if (ret < 0) {
>> @@ -551,6 +560,16 @@ int intel_dp_hdcp2_read_msg(struct inte

[Intel-gfx] [PATCH i-g-t 2/3] tests/i915: Default fence expiry test

2021-03-31 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Basic test to check that default fence expiry works as expected.

Relies on the modparam to run quicker.

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Matthew Auld 
---
 tests/Makefile.sources|   3 +
 tests/i915/gem_watchdog.c | 376 ++
 tests/meson.build |   1 +
 3 files changed, 380 insertions(+)
 create mode 100644 tests/i915/gem_watchdog.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 4f24fb3a15a5..e992285fedc5 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -463,6 +463,9 @@ gem_userptr_blits_SOURCES = i915/gem_userptr_blits.c
 TESTS_progs += gem_wait
 gem_wait_SOURCES = i915/gem_wait.c
 
+TESTS_progs += gem_watchdog
+gem_exec_watchdog_SOURCES = i915/gem_watchdog.c
+
 TESTS_progs += gem_workarounds
 gem_workarounds_SOURCES = i915/gem_workarounds.c
 
diff --git a/tests/i915/gem_watchdog.c b/tests/i915/gem_watchdog.c
new file mode 100644
index ..f86d3d4c7437
--- /dev/null
+++ b/tests/i915/gem_watchdog.c
@@ -0,0 +1,376 @@
+/*
+ * Copyright © 2021 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "config.h"
+
+#include 
+#include 
+#include 
+
+#include "i915/gem.h"
+#include "igt.h"
+#include "igt_params.h"
+#include "sw_sync.h"
+
+#define EWATCHDOG EINTR
+
+static struct drm_i915_query_engine_info *__engines__;
+
+static int __i915_query(int fd, struct drm_i915_query *q)
+{
+   if (igt_ioctl(fd, DRM_IOCTL_I915_QUERY, q))
+   return -errno;
+   return 0;
+}
+
+static int
+__i915_query_items(int fd, struct drm_i915_query_item *items, uint32_t n_items)
+{
+   struct drm_i915_query q = {
+   .num_items = n_items,
+   .items_ptr = to_user_pointer(items),
+   };
+   return __i915_query(fd, &q);
+}
+
+#define i915_query_items(fd, items, n_items) do { \
+   igt_assert_eq(__i915_query_items(fd, items, n_items), 0); \
+   errno = 0; \
+   } while (0)
+
+static unsigned int default_timeout_wait_s;
+static const unsigned int watchdog_us = 500 * 1000;
+
+static unsigned int
+wait_timeout(int i915, igt_spin_t **spin, unsigned int num_engines,
+unsigned int wait_us, unsigned int expect)
+{
+   unsigned int count_idle = 0, count_fence = 0, count_started = 0, i;
+   bool started[num_engines];
+
+   memset(started, 0, sizeof(started));
+
+   while (count_started < num_engines) {
+   for (i = 0; i < num_engines; i++) {
+   if (started[i])
+   continue;
+
+   if (igt_spin_has_started(spin[i])) {
+   started[i] = true;
+   count_started++;
+   }
+   }
+   }
+
+   igt_until_timeout(DIV_ROUND_UP(wait_us, USEC_PER_SEC)) {
+   usleep(watchdog_us / 2);
+
+   for (i = 0, count_idle = 0; i < num_engines; i++) {
+   if (!gem_bo_busy(i915, spin[i]->handle))
+   count_idle++;
+   }
+
+   for (i = 0, count_fence = 0; i < num_engines; i++) {
+   if (sync_fence_status(spin[i]->out_fence))
+   count_fence++;
+   }
+
+   if (count_idle == num_engines)
+   break;
+   }
+
+   if (count_idle < expect) {
+   for (i = 0; i < num_engines; i++) {
+   if (gem_bo_busy(i915, spin[i]->handle))
+   igt_warn("Request %u/%u not cancelled!\n",
+i + 1, num_engines);
+   }
+   }
+
+   if (count_fence < expect) {
+   for (i = 0; i < num_engines; i++) {
+   if (!sync_fence_status(spin[i]->out_fence))
+

[Intel-gfx] [PATCH i-g-t 3/3] tests/i915/gem_watchdog: Exercise long rendering chains

2021-03-31 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Test to demonstrate a problem with the proposed default fence expiry
semantics where long rendering chain get silently broken.

If we had fence error propagation (no clear agreement whether to do it or
not) maybe userspace would see if, assuming fence status is looked at, but
overall potential rendering corruption is the story in any case.

Note that this is not a single long batch but just a long queue of work
which could be viewed as heavy system load as well (like virtualisation
or other types of resource sharing).

v2:
 * Fix commit message.
 * Blacklist the test which is expected to fail for now.

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Matthew Auld 
---
 tests/i915/gem_watchdog.c| 310 +++
 tests/intel-ci/blacklist.txt |   1 +
 2 files changed, 311 insertions(+)

diff --git a/tests/i915/gem_watchdog.c b/tests/i915/gem_watchdog.c
index f86d3d4c7437..8f9fb17750fb 100644
--- a/tests/i915/gem_watchdog.c
+++ b/tests/i915/gem_watchdog.c
@@ -23,6 +23,8 @@
 
 #include "config.h"
 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -321,8 +323,309 @@ static void virtual(int i915)
igt_assert_eq(count, expect);
 }
 
+#define MI_INSTR(opcode, flags) (((opcode) << 23) | (flags))
+
+#define MI_MATH(x)  MI_INSTR(0x1a, (x) - 1)
+#define MI_MATH_INSTR(opcode, op1, op2) ((opcode) << 20 | (op1) << 10 | (op2))
+/* Opcodes for MI_MATH_INSTR */
+#define   MI_MATH_NOOP  MI_MATH_INSTR(0x000, 0x0, 0x0)
+#define   MI_MATH_LOAD(op1, op2)MI_MATH_INSTR(0x080, op1, op2)
+#define   MI_MATH_LOADINV(op1, op2) MI_MATH_INSTR(0x480, op1, op2)
+#define   MI_MATH_LOAD0(op1)MI_MATH_INSTR(0x081, op1)
+#define   MI_MATH_LOAD1(op1)MI_MATH_INSTR(0x481, op1)
+#define   MI_MATH_ADD   MI_MATH_INSTR(0x100, 0x0, 0x0)
+#define   MI_MATH_SUB   MI_MATH_INSTR(0x101, 0x0, 0x0)
+#define   MI_MATH_AND   MI_MATH_INSTR(0x102, 0x0, 0x0)
+#define   MI_MATH_ORMI_MATH_INSTR(0x103, 0x0, 0x0)
+#define   MI_MATH_XOR   MI_MATH_INSTR(0x104, 0x0, 0x0)
+#define   MI_MATH_STORE(op1, op2)   MI_MATH_INSTR(0x180, op1, op2)
+#define   MI_MATH_STOREINV(op1, op2)MI_MATH_INSTR(0x580, op1, op2)
+/* Registers used as operands in MI_MATH_INSTR */
+#define   MI_MATH_REG(x)(x)
+#define   MI_MATH_REG_SRCA  0x20
+#define   MI_MATH_REG_SRCB  0x21
+#define   MI_MATH_REG_ACCU  0x31
+#define   MI_MATH_REG_ZF0x32
+#define   MI_MATH_REG_CF0x33
+
+#define MI_LOAD_REGISTER_REGMI_INSTR(0x2A, 1)
+
+static unsigned int offset_in_page(void *addr)
+{
+   return (uintptr_t)addr & 4095;
+}
+
+static uint64_t div64_u64_round_up(uint64_t x, uint64_t y)
+{
+   return (x + y - 1) / y;
+}
+
+static int read_timestamp_frequency(int i915)
+{
+   int value = 0;
+   drm_i915_getparam_t gp = {
+   .value = &value,
+   .param = I915_PARAM_CS_TIMESTAMP_FREQUENCY,
+   };
+   ioctl(i915, DRM_IOCTL_I915_GETPARAM, &gp);
+   return value;
+}
+
+static uint64_t ns_to_ticks(int i915, uint64_t ns)
+{
+   return div64_u64_round_up(ns * read_timestamp_frequency(i915),
+ NSEC_PER_SEC);
+}
+
+static uint32_t __batch_create(int i915, uint32_t offset)
+{
+   const uint32_t bbe = MI_BATCH_BUFFER_END;
+   uint32_t handle;
+
+   handle = gem_create(i915, ALIGN(offset + 4, 4096));
+   gem_write(i915, handle, offset, &bbe, sizeof(bbe));
+
+   return handle;
+}
+
+static uint32_t batch_create(int i915)
+{
+   return __batch_create(i915, 0);
+}
+
+static void delay(int i915,
+ const struct intel_execution_engine2 *e,
+ uint32_t handle,
+ uint64_t addr,
+ uint64_t ns)
+{
+   const int use_64b = intel_gen(intel_get_drm_devid(i915)) >= 8;
+   const uint32_t base = gem_engine_mmio_base(i915, e->name);
+#define CS_GPR(x) (base + 0x600 + 8 * (x))
+#define RUNTIME (base + 0x3a8)
+   enum { START_TS, NOW_TS };
+   uint32_t *map, *cs, *jmp;
+
+   igt_require(base);
+
+   /* Loop until CTX_TIMESTAMP - initial > @ns */
+
+   cs = map = gem_mmap__device_coherent(i915, handle, 0, 4096, PROT_WRITE);
+
+   *cs++ = MI_LOAD_REGISTER_IMM;
+   *cs++ = CS_GPR(START_TS) + 4;
+   *cs++ = 0;
+   *cs++ = MI_LOAD_REGISTER_REG;
+   *cs++ = RUNTIME;
+   *cs++ = CS_GPR(START_TS);
+
+   while (offset_in_page(cs) & 63)
+   *cs++ = 0;
+   jmp = cs;
+
+   *cs++ = 0x5 << 23; /* MI_ARB_CHECK */
+
+   *cs++ = MI_LOAD_REGISTER_IMM;
+   *cs++ = CS_GPR(NOW_TS) + 4;
+   *cs++ = 0;
+   *cs++ = MI_LOAD_REGISTER_REG;
+   *cs++ = RUNTIME;
+   *cs++ = CS_GPR(NOW_TS);
+
+   /* delta = now - start; inverted to match COND_BBE */
+   *cs++ = MI_MATH(4);
+   *cs++ = MI_MA

[Intel-gfx] [PATCH i-g-t 1/3] lib: Add helper for reading modparam values

2021-03-31 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Add __igt_params_get for simple reading of modparams.

v2:
 * Fix kerneldoc. (Matt)

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Matthew Auld 
---
 lib/igt_params.c | 26 ++
 lib/igt_params.h |  2 ++
 2 files changed, 28 insertions(+)

diff --git a/lib/igt_params.c b/lib/igt_params.c
index c06416988baa..3dad317a56b2 100644
--- a/lib/igt_params.c
+++ b/lib/igt_params.c
@@ -156,6 +156,32 @@ int igt_params_open(int device)
return params;
 }
 
+/**
+ * __igt_params_get:
+ * @device: fd of the device
+ * @parameter: the name of the parameter to get
+ *
+ * This reads the value of the modparam.
+ *
+ * Returns:
+ * A nul-terminated string, must be freed by caller after use, or NULL
+ * on failure.
+ */
+char *__igt_params_get(int device, const char *parameter)
+{
+   char *str;
+   int dir;
+
+   dir = igt_params_open(device);
+   if (dir < 0)
+   return NULL;
+
+   str = igt_sysfs_get(dir, parameter);
+   close(dir);
+
+   return str;
+}
+
 __attribute__((format(printf, 3, 0)))
 static bool __igt_params_set(int device, const char *parameter,
 const char *fmt, va_list ap, bool save)
diff --git a/lib/igt_params.h b/lib/igt_params.h
index bbd6f3ee6582..6494786f0696 100644
--- a/lib/igt_params.h
+++ b/lib/igt_params.h
@@ -28,6 +28,8 @@
 
 int igt_params_open(int device);
 
+char *__igt_params_get(int device, const char *parameter);
+
 __attribute__((format(printf, 3, 4)))
 bool igt_params_set(int device, const char *parameter, const char *fmt, ...);
 
-- 
2.27.0

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


Re: [Intel-gfx] [PATCH v2 0/2] HDCP 2.2 DP errata

2021-03-31 Thread Jani Nikula
On Thu, 25 Mar 2021, Jani Nikula  wrote:
> On Wed, 24 Mar 2021, Anshuman Gupta  wrote:
>> HDCP DP 2.2 errata is part of HDCP DP 2.3 specs
>> as well. 
>>
>> Anshuman Gupta (2):
>>   drm/i915/hdcp: Add DP HDCP2.2 timeout to read entire msg
>>   drm/hdcp: DP HDCP2.2 errata LC_Send_L_Prime=16
>>
>>  drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 45 ++--
>>  include/drm/drm_hdcp.h   |  5 ++-
>>  2 files changed, 36 insertions(+), 14 deletions(-)
>
> Maarten, Maxime, Thomas -
>
> Can I get an ack for merging this via drm-intel-next, please?

Ping! :)

BR,
Jani.


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


Re: [Intel-gfx] [PATCH v5 1/2] drm/dp_helper: Define options for FRL training for HDMI2.1 PCON

2021-03-31 Thread Jani Nikula
On Fri, 26 Mar 2021, Maxime Ripard  wrote:
> Hi,
>
> On Fri, Mar 26, 2021 at 11:47:58AM +0200, Jani Nikula wrote:
>> On Tue, 23 Mar 2021, Ankit Nautiyal  wrote:
>> > Currently the FRL training mode (Concurrent, Sequential) and
>> > training type (Normal, Extended) are not defined properly and
>> > are passed as bool values in drm_helpers for pcon
>> > configuration for FRL training.
>> >
>> > This patch:
>> > -Add register masks for Sequential and Normal FRL training options.
>> > -Fixes the drm_helpers for FRL Training configuration to use the
>> >  appropriate masks.
>> > -Modifies the calls to the above drm_helpers in i915/intel_dp as per
>> >  the above change.
>> >
>> > v2: Re-used the register masks for these options, instead of enum. (Ville)
>> >
>> > Signed-off-by: Ankit Nautiyal 
>> > Reviewed-by: Ville Syrjälä 
>> 
>> Maarten, Maxime, Thomas -
>> 
>> Can I get an ack for merging this via drm-intel-next, please?
>
> I was hoping that someone with either i915 or DP knowledge would
> comment, but the patch looks fine to me, you can go ahead I guess :)

Thanks for the patch, review, and ack, pushed the lot to drm-intel-next.

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] [PATCH] drm/i915/pmu: Check actual RC6 status

2021-03-31 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

RC6 support cannot be simply established by looking at the static device
HAS_RC6() flag. There are cases which disable RC6 at driver load time so
use the status of those check when deciding whether to enumerate the rc6
counter.

Signed-off-by: Tvrtko Ursulin 
Reported-by: Eero T Tamminen 
---
 drivers/gpu/drm/i915/i915_pmu.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 41651ac255fa..a75cd1db320b 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -476,6 +476,8 @@ engine_event_status(struct intel_engine_cs *engine,
 static int
 config_status(struct drm_i915_private *i915, u64 config)
 {
+   struct intel_gt *gt = &i915->gt;
+
switch (config) {
case I915_PMU_ACTUAL_FREQUENCY:
if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
@@ -489,7 +491,7 @@ config_status(struct drm_i915_private *i915, u64 config)
case I915_PMU_INTERRUPTS:
break;
case I915_PMU_RC6_RESIDENCY:
-   if (!HAS_RC6(i915))
+   if (!gt->rc6.supported)
return -ENODEV;
break;
case I915_PMU_SOFTWARE_GT_AWAKE_TIME:
-- 
2.27.0

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


Re: [Intel-gfx] [PATCH v2 19/20] drm/dp_mst: Drop DRM_ERROR() on kzalloc() fail in drm_dp_mst_handle_up_req()

2021-03-31 Thread Robert Foss
Hey Lyude,

This patch looks good to me.

Reviewed-by: Robert Foss 

On Fri, 26 Mar 2021 at 21:40, Lyude Paul  wrote:
>
> Checkpatch was complaining about this - there's no need for us to print
> errors when kzalloc() fails, as kzalloc() will already WARN for us. So,
> let's fix that before converting things to make checkpatch happy.
>
> Signed-off-by: Lyude Paul 
> Cc: Robert Foss 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index ec2285595c33..74c420f5f204 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -4113,10 +4113,9 @@ static int drm_dp_mst_handle_up_req(struct 
> drm_dp_mst_topology_mgr *mgr)
> return 0;
>
> up_req = kzalloc(sizeof(*up_req), GFP_KERNEL);
> -   if (!up_req) {
> -   DRM_ERROR("Not enough memory to process MST up req\n");
> +   if (!up_req)
> return -ENOMEM;
> -   }
> +
> INIT_LIST_HEAD(&up_req->next);
>
> drm_dp_sideband_parse_req(&mgr->up_req_recv, &up_req->msg);
> --
> 2.30.2
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

2021-03-31 Thread Arnd Bergmann
On Tue, Mar 30, 2021 at 10:41 AM Michal Koutný  wrote:
>
> On Mon, Mar 22, 2021 at 05:02:44PM +0100, Arnd Bergmann  
> wrote:
> > I'm not sure what is expected to happen for such a configuration,
> > presumably these functions are never calls in that case.
> Yes, the functions you patched would only be called from subsystems or
> there should be no way to obtain a struct cgroup_subsys reference
> anyway (hence it's ok to always branch as if ss==NULL).
>
> I'd prefer a variant that wouldn't compile the affected codepaths when
> there are no subsystems registered, however, I couldn't come up with a
> way how to do it without some preprocessor ugliness.

Would it be possible to enclose most or all of kernel/cgroup/cgroup.c
in an #ifdef CGROUP_SUBSYS_COUNT block? I didn't try that
myself, but this might be a way to guarantee that there cannot
be any callers (it would cause a link error).

> Reviewed-by: Michal Koutný 

Thanks

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


Re: [Intel-gfx] [PATCH v2 07/20] drm/print: Fixup DRM_DEBUG_KMS_RATELIMITED()

2021-03-31 Thread Robert Foss
Hey Lyude,

I'm seeing no issues with this patch and the reasoning behind the
patch is sound to me.

Reviewed-by: Robert Foss 

On Fri, 26 Mar 2021 at 21:39, Lyude Paul  wrote:
>
> Since we're about to move drm_dp_helper.c over to drm_dbg_*(), we'll want
> to make sure that we can also add ratelimited versions of these macros in
> order to retain some of the previous debugging output behavior we had.
>
> However, as I was preparing to do this I noticed that the current
> rate limited macros we have are kind of bogus. It looks like when I wrote
> these, I didn't notice that we'd always be calling __ratelimit() even if
> the debugging message we'd be printing would normally be filtered out due
> to the relevant DRM debugging category being disabled.
>
> So, let's fix this by making sure to check drm_debug_enabled() in our
> ratelimited macros before calling __ratelimit(), and start using
> drm_dev_printk() in order to print debugging messages since that will save
> us from doing a redundant drm_debug_enabled() check. And while we're at it,
> let's move the code for this into another macro that we can reuse for
> defining new ratelimited DRM debug macros more easily.
>
> v2:
> * Make sure to use tabs where possible in __DRM_DEFINE_DBG_RATELIMITED()
>
> Signed-off-by: Lyude Paul 
> Cc: Robert Foss 
> ---
>  include/drm/drm_print.h | 20 
>  1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index f32d179e139d..a3c58c941bdc 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -524,16 +524,20 @@ void __drm_err(const char *format, ...);
>  #define DRM_DEBUG_DP(fmt, ...) \
> __drm_dbg(DRM_UT_DP, fmt, ## __VA_ARGS__)
>
> -
> -#define DRM_DEBUG_KMS_RATELIMITED(fmt, ...)\
> -({ \
> -   static DEFINE_RATELIMIT_STATE(_rs,  \
> - DEFAULT_RATELIMIT_INTERVAL,   \
> - DEFAULT_RATELIMIT_BURST); \
> -   if (__ratelimit(&_rs))  \
> -   drm_dev_dbg(NULL, DRM_UT_KMS, fmt, ##__VA_ARGS__);  \
> +#define __DRM_DEFINE_DBG_RATELIMITED(category, drm, fmt, ...)
>   \
> +({   
>   \
> +   static DEFINE_RATELIMIT_STATE(rs_, DEFAULT_RATELIMIT_INTERVAL, 
> DEFAULT_RATELIMIT_BURST);\
> +   const struct drm_device *drm_ = (drm);
>   \
> + 
>   \
> +   if (drm_debug_enabled(DRM_UT_ ## category) && __ratelimit(&rs_))  
>   \
> +   drm_dev_printk(drm_ ? drm_->dev : NULL, KERN_DEBUG, fmt, ## 
> __VA_ARGS__);   \
>  })
>
> +#define drm_dbg_kms_ratelimited(drm, fmt, ...) \
> +   __DRM_DEFINE_DBG_RATELIMITED(KMS, drm, fmt, ## __VA_ARGS__)
> +
> +#define DRM_DEBUG_KMS_RATELIMITED(fmt, ...) drm_dbg_kms_ratelimited(NULL, 
> fmt, ## __VA_ARGS__)
> +
>  /*
>   * struct drm_device based WARNs
>   *
> --
> 2.30.2
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 20/20] drm/dp_mst: Convert drm_dp_mst_topology.c to drm_err()/drm_dbg*()

2021-03-31 Thread Robert Foss
Hey Lyude,

This patch looks good, but I have one question below. With it
addressed, feel free to add my r-b.

Reviewed-by: Robert Foss 

>
> -static bool drm_dp_sideband_parse_req(struct drm_dp_sideband_msg_rx *raw,
> +static bool drm_dp_sideband_parse_req(const struct drm_dp_mst_topology_mgr 
> *mgr,
> + struct drm_dp_sideband_msg_rx *raw,
>   struct drm_dp_sideband_msg_req_body 
> *msg)
>  {
> memset(msg, 0, sizeof(*msg));
> @@ -1117,12 +1125,12 @@ static bool drm_dp_sideband_parse_req(struct 
> drm_dp_sideband_msg_rx *raw,
>
> switch (msg->req_type) {
> case DP_CONNECTION_STATUS_NOTIFY:
> -   return drm_dp_sideband_parse_connection_status_notify(raw, 
> msg);
> +   return drm_dp_sideband_parse_connection_status_notify(mgr, 
> raw, msg);
> case DP_RESOURCE_STATUS_NOTIFY:
> -   return drm_dp_sideband_parse_resource_status_notify(raw, msg);
> +   return drm_dp_sideband_parse_resource_status_notify(mgr, raw, 
> msg);
> default:
> -   DRM_ERROR("Got unknown request 0x%02x (%s)\n", msg->req_type,
> - drm_dp_mst_req_type_str(msg->req_type));
> +   drm_err(mgr->dev, "Got unknown request 0x%02x (%s)\n",
> +   msg->req_type, 
> drm_dp_mst_req_type_str(msg->req_type));
> return false;
> }
>  }
>

.. snip ..

> @@ -4118,12 +4121,12 @@ static int drm_dp_mst_handle_up_req(struct 
> drm_dp_mst_topology_mgr *mgr)
>
> INIT_LIST_HEAD(&up_req->next);
>
> -   drm_dp_sideband_parse_req(&mgr->up_req_recv, &up_req->msg);
> +   drm_dp_sideband_parse_req(mgr, &mgr->up_req_recv, &up_req->msg);

drm_dp_sideband_parse_req() is only called here, and the function
arguments could probably stand to have `&mgr->up_req_recv` removed
(here and in the func. declaration) since the same data structure is
accessible through the `mgr` pointer inside of
drm_dp_sideband_parse_req(). I guess this is a matter of taste, so
feel free to do what you want with this.

>
> if (up_req->msg.req_type != DP_CONNECTION_STATUS_NOTIFY &&
> up_req->msg.req_type != DP_RESOURCE_STATUS_NOTIFY) {
> -   DRM_DEBUG_KMS("Received unknown up req type, ignoring: %x\n",
> - up_req->msg.req_type);
> +   drm_dbg_kms(mgr->dev, "Received unknown up req type, 
> ignoring: %x\n",
> +   up_req->msg.req_type);
> kfree(up_req);
> goto out;
> }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 17/20] drm/dp: Convert drm_dp_helper.c to using drm_err/drm_dbg_*()

2021-03-31 Thread Robert Foss
Hey Lyude,

Looks good to me.

Reviewed-by: Robert Foss 


On Fri, 26 Mar 2021 at 21:40, Lyude Paul  wrote:
>
> Now that we've added a back-pointer to drm_device to drm_dp_aux, made
> drm_dp_aux available to any functions in drm_dp_helper.c which need to
> print to the kernel log, and ensured all of our logging uses a consistent
> format, let's do the final step of the conversion and actually move
> everything over to using drm_err() and drm_dbg_*().
>
> This was done by using the following cocci script:
>
>   @@
>   expression list expr;
>   @@
>
>   (
>   - DRM_DEBUG_KMS(expr);
>   + drm_dbg_kms(aux->drm_dev, expr);
>   |
>   - DRM_DEBUG_DP(expr);
>   + drm_dbg_dp(aux->drm_dev, expr);
>   |
>   - DRM_DEBUG_ATOMIC(expr);
>   + drm_dbg_atomic(aux->drm_dev, expr);
>   |
>   - DRM_DEBUG_KMS_RATELIMITED(expr);
>   + drm_dbg_kms_ratelimited(aux->drm_dev, expr);
>   |
>   - DRM_ERROR(expr);
>   + drm_err(aux->drm_dev, expr);
>   )
>
> Followed by correcting the resulting line-wrapping in the results by hand.
>
> v2:
> * Fix indenting in drm_dp_dump_access
>
> Signed-off-by: Lyude Paul 
> Cc: Robert Foss 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 121 
>  1 file changed, 59 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 54e19d7b9c51..4940db0bcaae 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -139,8 +139,8 @@ void drm_dp_link_train_clock_recovery_delay(const struct 
> drm_dp_aux *aux,
>  DP_TRAINING_AUX_RD_MASK;
>
> if (rd_interval > 4)
> -   DRM_DEBUG_KMS("%s: AUX interval %lu, out of range (max 4)\n",
> - aux->name, rd_interval);
> +   drm_dbg_kms(aux->drm_dev, "%s: AUX interval %lu, out of range 
> (max 4)\n",
> +   aux->name, rd_interval);
>
> if (rd_interval == 0 || dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
> rd_interval = 100;
> @@ -155,8 +155,8 @@ static void __drm_dp_link_train_channel_eq_delay(const 
> struct drm_dp_aux *aux,
>  unsigned long rd_interval)
>  {
> if (rd_interval > 4)
> -   DRM_DEBUG_KMS("%s: AUX interval %lu, out of range (max 4)\n",
> - aux->name, rd_interval);
> +   drm_dbg_kms(aux->drm_dev, "%s: AUX interval %lu, out of range 
> (max 4)\n",
> +   aux->name, rd_interval);
>
> if (rd_interval == 0)
> rd_interval = 400;
> @@ -220,11 +220,11 @@ drm_dp_dump_access(const struct drm_dp_aux *aux,
> const char *arrow = request == DP_AUX_NATIVE_READ ? "->" : "<-";
>
> if (ret > 0)
> -   DRM_DEBUG_DP("%s: 0x%05x AUX %s (ret=%3d) %*ph\n",
> -aux->name, offset, arrow, ret, min(ret, 20), 
> buffer);
> +   drm_dbg_dp(aux->drm_dev, "%s: 0x%05x AUX %s (ret=%3d) %*ph\n",
> +  aux->name, offset, arrow, ret, min(ret, 20), 
> buffer);
> else
> -   DRM_DEBUG_DP("%s: 0x%05x AUX %s (ret=%3d)\n",
> -aux->name, offset, arrow, ret);
> +   drm_dbg_dp(aux->drm_dev, "%s: 0x%05x AUX %s (ret=%3d)\n",
> +  aux->name, offset, arrow, ret);
>  }
>
>  /**
> @@ -287,8 +287,8 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
> request,
> err = ret;
> }
>
> -   DRM_DEBUG_KMS("%s: Too many retries, giving up. First error: %d\n",
> - aux->name, err);
> +   drm_dbg_kms(aux->drm_dev, "%s: Too many retries, giving up. First 
> error: %d\n",
> +   aux->name, err);
> ret = err;
>
>  unlock:
> @@ -524,44 +524,44 @@ bool drm_dp_send_real_edid_checksum(struct drm_dp_aux 
> *aux,
>
> if (drm_dp_dpcd_read(aux, DP_DEVICE_SERVICE_IRQ_VECTOR,
>  &auto_test_req, 1) < 1) {
> -   DRM_ERROR("%s: DPCD failed read at register 0x%x\n",
> - aux->name, DP_DEVICE_SERVICE_IRQ_VECTOR);
> +   drm_err(aux->drm_dev, "%s: DPCD failed read at register 
> 0x%x\n",
> +   aux->name, DP_DEVICE_SERVICE_IRQ_VECTOR);
> return false;
> }
> auto_test_req &= DP_AUTOMATED_TEST_REQUEST;
>
> if (drm_dp_dpcd_read(aux, DP_TEST_REQUEST, &link_edid_read, 1) < 1) {
> -   DRM_ERROR("%s: DPCD failed read at register 0x%x\n",
> - aux->name, DP_TEST_REQUEST);
> +   drm_err(aux->drm_dev, "%s: DPCD failed read at register 
> 0x%x\n",
> +   aux->name, DP_TEST_REQUEST);
> return false;
> }
> link_edid_read &= DP_TEST_LINK_EDID_READ;
>
> if (!auto_test_req || !link_edid_read) {
> -   DRM_DEBUG_KMS("%s: Source DUT d

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] intel_gpu_top: Document how to use JSON output

2021-03-31 Thread Tvrtko Ursulin




On 31/03/2021 10:12, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Put a note on how to use JSON output into the man page.

Signed-off-by: Tvrtko Ursulin 
References: https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/100
---
  man/intel_gpu_top.rst | 5 +
  1 file changed, 5 insertions(+)

diff --git a/man/intel_gpu_top.rst b/man/intel_gpu_top.rst
index f6d74852558b..94fdc6520fd3 100644
--- a/man/intel_gpu_top.rst
+++ b/man/intel_gpu_top.rst
@@ -81,6 +81,11 @@ Filter types: ::
  pci  pci:[vendor=%04x/name][,device=%04x][,card=%d]
   vendor is hex number or vendor name
  
+JSON OUTPUT

+===
+
+To parse the JSON as output by the tool the consumer should wrap its entirety into 
square brackets ([ ]). This will make each sample point an JSON array element and will 
avoid "Multiple root elements" JSON validation error.
+


Or as an alternative we make the tool do this, but it'd need a signal 
handler to print the closing bracket at which point I thought it could 
be a complication too far. Could be convinced either way I guess.


Regards,

Tvrtko


  LIMITATIONS
  ===
  


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


[Intel-gfx] [PATCH i-g-t] intel_gpu_top: Document how to use JSON output

2021-03-31 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Put a note on how to use JSON output into the man page.

Signed-off-by: Tvrtko Ursulin 
References: https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/100
---
 man/intel_gpu_top.rst | 5 +
 1 file changed, 5 insertions(+)

diff --git a/man/intel_gpu_top.rst b/man/intel_gpu_top.rst
index f6d74852558b..94fdc6520fd3 100644
--- a/man/intel_gpu_top.rst
+++ b/man/intel_gpu_top.rst
@@ -81,6 +81,11 @@ Filter types: ::
 pci  pci:[vendor=%04x/name][,device=%04x][,card=%d]
  vendor is hex number or vendor name
 
+JSON OUTPUT
+===
+
+To parse the JSON as output by the tool the consumer should wrap its entirety 
into square brackets ([ ]). This will make each sample point an JSON array 
element and will avoid "Multiple root elements" JSON validation error.
+
 LIMITATIONS
 ===
 
-- 
2.27.0

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


[Intel-gfx] [PATCH i-g-t] intel_gpu_top: Do not print client header if no client stats

2021-03-31 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Add a check if client stats are present to init_clients() so that the
returned clients data can be null from the start. This prevents the client
stats header to be printed on old kernels.

Signed-off-by: Tvrtko Ursulin 
---
 tools/intel_gpu_top.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index e22e3bedacbe..7311038a39f4 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -671,9 +671,14 @@ struct clients {
 
 static struct clients *init_clients(const char *drm_card)
 {
-   struct clients *clients = malloc(sizeof(*clients));
+   struct clients *clients;
const char *slash;
ssize_t ret;
+   int dir;
+
+   clients = malloc(sizeof(*clients));
+   if (!clients)
+   return NULL;
 
memset(clients, 0, sizeof(*clients));
 
@@ -688,6 +693,14 @@ static struct clients *init_clients(const char *drm_card)
   "/sys/class/drm/%s/clients/", slash);
assert(ret > 0 && ret < sizeof(clients->sysfs_root));
 
+   dir = open(clients->sysfs_root, O_DIRECTORY | O_RDONLY);
+   if (dir < 0) {
+   free(clients);
+   clients = NULL;
+   } else {
+   close(dir);
+   }
+
return clients;
 }
 
@@ -2519,8 +2532,10 @@ int main(int argc, char **argv)
 
clients = init_clients(card.pci_slot_name[0] ? card.card : NULL);
init_engine_classes(engines);
-   clients->num_classes = engines->num_classes;
-   clients->class = engines->class;
+   if (clients) {
+   clients->num_classes = engines->num_classes;
+   clients->class = engines->class;
+   }
 
pmu_sample(engines);
scan_clients(clients);
-- 
2.27.0

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