Re: [Intel-gfx] [PULL] gvt-next

2020-11-23 Thread Zhenyu Wang 
On 2020.11.23 11:32:38 +0200, Joonas Lahtinen wrote:
> Quoting Zhenyu Wang (2020-11-23 11:05:17)
> > 
> > Hi,
> > 
> > Here's gvt next pull for v5.11. Mostly it's for host suspend/resume
> > fix with vGPU active and with some other enhancement as details below.
> > Note that this includes some minor i915 driver change to add gvt hook
> > in suspend/resume function which has been sent and reviewed on
> > intel-gfx list.
> > 
> > I just generated against drm-intel-next-queued-2020-11-03 which this
> > tree bases on now. Let me know if there's any issue in merge.
> 
> Sometimes GVT changes are paired with changes related the i915 side
> to adjust the running virtual clients. The changes are more often
> related to GT side, but there's also been display related changes.
> 
> Going forward, would we want to continue to apply gvt-next to
> drm-intel-next (-queued is planned to be deprecated) or
> should we use drm-intel-gt-next?
>

Is there any clear criteria on patches for -next or -gt-next now?
Something might be only gvt specific, e.g we'll have some enhancement patches
for guest context parse, this might be considered as 'gt' part? I'm not sure.
But yes, I hope we just stick with one, currently thinking drm-intel-next.

> Or should we always strictly apply the GVT changes to drm-intel-next,
> and then any related i915 changes to drm-intel-next or drm-intel-gt-next
> depending on which one they are related to?
>

How about basically we just apply to drm-intel-next, but there might be gvt
specific pull required for -gt-next e.g ww-lock fixes? I think we can do that 
way
now to see if there'll be any real issue popup.

Thanks

> 
> > Thanks
> > --
> > The following changes since commit 139caf7ca2866cd0a45814ff938cb0c33920a266:
> > 
> >   drm/i915: Update DRIVER_DATE to 20201103 (2020-11-03 14:21:25 +0200)
> > 
> > are available in the Git repository at:
> > 
> >   https://github.com/intel/gvt-linux tags/gvt-next-2020-11-23
> > 
> > for you to fetch changes up to 9a3a238b3de97b4210c6de66aa88b2d7021ac086:
> > 
> >   drm/i915/gvt: treat intel_gvt_mpt as const in gvt code (2020-11-23 
> > 17:14:20 +0800)
> > 
> > 
> > gvt-next-2020-11-23
> > 
> > - Fix host suspend/resume with vGPU (Colin)
> > - optimize idr init (Varma)
> > - Change intel_gvt_mpt as const (Julian)
> > - One comment error fix (Yan)
> > 
> > 
> > Colin Xu (3):
> >   drm/i915/gvt: Save/restore HW status to support GVT suspend/resume
> >   drm/i915: Add GVT resume routine to i915
> >   drm/i915/gvt: Fix virtual display setup for BXT/APL
> > 
> > Deepak R Varma (1):
> >   drm/i915/gvt: replace idr_init() by idr_init_base()
> > 
> > Julian Stecklina (1):
> >   drm/i915/gvt: treat intel_gvt_mpt as const in gvt code
> > 
> > Yan Zhao (1):
> >   drm/i915/gvt: correct a false comment of flag F_UNALIGN
> > 
> >  drivers/gpu/drm/i915/gvt/display.c  | 179 
> > 
> >  drivers/gpu/drm/i915/gvt/gtt.c  |  64 +
> >  drivers/gpu/drm/i915/gvt/gtt.h  |   4 +
> >  drivers/gpu/drm/i915/gvt/gvt.c  |  13 ++-
> >  drivers/gpu/drm/i915/gvt/gvt.h  |   7 +-
> >  drivers/gpu/drm/i915/gvt/handlers.c |  44 -
> >  drivers/gpu/drm/i915/gvt/kvmgt.c|   2 +-
> >  drivers/gpu/drm/i915/gvt/mmio.c |   5 +
> >  drivers/gpu/drm/i915/gvt/mmio.h |   4 +
> >  drivers/gpu/drm/i915/gvt/mpt.h  |   2 +-
> >  drivers/gpu/drm/i915/gvt/vgpu.c |   2 +-
> >  drivers/gpu/drm/i915/i915_drv.c |   2 +
> >  drivers/gpu/drm/i915/intel_gvt.c|  15 +++
> >  drivers/gpu/drm/i915/intel_gvt.h|   5 +
> >  14 files changed, 338 insertions(+), 10 deletions(-)
> > 
> > -- 
> > 
> > $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

-- 

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


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

Re: [Intel-gfx] [PATCH 03/21] drm/i915/adl_s: Add ADL-S platform info and PCI ids

2020-11-23 Thread Aditya Swarup 
On 11/17/20 11:17 AM, Jani Nikula wrote:
> On Tue, 17 Nov 2020, Aditya Swarup  wrote:
>> From: Caz Yokoyama 
>>
>> - Add the initial platform information for Alderlake-S.
>> - Specify ppgtt_size value
>> - Add dma_mask_size
>> - Add ADLS REVIDs
>> - HW tracking(Selective Update Tracking Enable) has been
>>   removed from ADLS. Disable PSR2 till we enable software/
>>   manual tracking.
>>
>> v2:
>> - Add support for different ADLS SOC steppings to select
>>   correct GT/DISP stepping based on Bspec 53655 based on
>>   feedback from Matt Roper.(aswarup)
>>
>> Bspec: 53597
>> Bspec: 53648
>> Bspec: 53655
>> Bspec: 48028
>> Bspec: 53650
>> BSpec: 50422
>>
>> Cc: José Roberto de Souza 
>> Cc: Matt Roper 
>> Cc: Lucas De Marchi 
>> Cc: Anusha Srivatsa 
>> Cc: Jani Nikula 
>> Cc: Ville Syrjälä 
>> Cc: Imre Deak 
>> Signed-off-by: Caz Yokoyama 
>> Signed-off-by: Aditya Swarup 
>> ---
>>  drivers/gpu/drm/i915/gt/intel_workarounds.c |  8 
>>  drivers/gpu/drm/i915/i915_drv.h | 20 
>>  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 +
>>  include/drm/i915_pciids.h   | 13 +
>>  6 files changed, 55 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
>> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
>> index d756155d82ea..d88d3d60fb1c 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
>> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
>> @@ -83,6 +83,14 @@ const struct i915_rev_steppings tgl_revids[] = {
>>  [1] = { .gt_stepping = REVID_B0, .disp_stepping = REVID_D0 },
>>  };
>>  
>> +const struct i915_rev_steppings adls_revids[] = {
>> +[ADLS_REVID_A0] = { .gt_stepping = REVID_A0, .disp_stepping = REVID_A0 
>> },
>> +[ADLS_REVID_A2] = { .gt_stepping = REVID_A0, .disp_stepping = REVID_A2 
>> },
>> +[ADLS_REVID_B0] = { .gt_stepping = REVID_B0, .disp_stepping = REVID_B0 
>> },
>> +[ADLS_REVID_G0] = { .gt_stepping = REVID_C0, .disp_stepping = REVID_B0 
>> },
>> +[ADLS_REVID_C0] = { .gt_stepping = REVID_D0, .disp_stepping = REVID_C0 
>> },
>> +};
>> +
>>  static void wa_init_start(struct i915_wa_list *wal, const char *name, const 
>> char *engine_name)
>>  {
>>  wal->name = name;
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 437916aacaa6..817a5102b94f 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -1423,6 +1423,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>>  #define IS_TIGERLAKE(dev_priv)  IS_PLATFORM(dev_priv, INTEL_TIGERLAKE)
>>  #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_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
>>  (INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00)
>>  #define IS_BDW_ULT(dev_priv) \
>> @@ -1566,6 +1567,7 @@ extern const struct i915_rev_steppings kbl_revids[];
>>  
>>  enum {
>>  REVID_A0,
>> +REVID_A2,
> 
> Don't the numerical values matter?

This is an internal mapping for Display/GT steppings and hence the values don't 
matter as long as they are distinct. Value of SOC stepping matters which is 
declared
as a separate macro and used as an index to obtain the correct Display/GT 
stepping info,
to be used in conjunction 

> 
>>  REVID_B0,
>>  REVID_B1,
>>  REVID_C0,
>> @@ -1607,6 +1609,24 @@ tgl_revids_get(struct drm_i915_private *dev_priv)
>>  #define IS_DG1_REVID(p, since, until) \
>>  (IS_DG1(p) && IS_REVID(p, since, until))
>>  
>> +#define ADLS_REVID_A0   0x0
>> +#define ADLS_REVID_A2   0x1
>> +#define ADLS_REVID_B0   0x4
>> +#define ADLS_REVID_G0   0x8
>> +#define ADLS_REVID_C0   0xC /*Same as H0 ADLS SOC stepping*/
> 
> Why do we now have both macros and enums for this stuff?

Because SOC steppings and disp/GT steppings are not the same anymore for ADL-S 
from 
Bspec: 53655. What we get from drm revision id is the SOC stepping and then we 
need 
to map it internally for display/GT steppins(hence separate enums to deal with 
this
as it is an internal mapping for i915 driver to be used with application of WAs 
based
on display stepping info)

> 
>> +
>> +extern const struct i915_rev_steppings adls_revids[];
> 
> Yuck. Oh man, we really really should not have embarked on this path of
> adding array externs to begin with. It should have been better
> abstracted.

I agree but can you please accept this approach for ADLS as it is following 
similar
convention from KBL and TGL. I can address this approach in a later patch to 
not use externs
for all the platforms in question.

Aditya

> 
> BR,
> Jani.
> 
>> +
>> +#define

Re: [Intel-gfx] [PATCH 02/21] drm/i915/tgl: Fix macros for TGL SOC based WA

2020-11-23 Thread Aditya Swarup 
On 11/18/20 1:18 AM, Jani Nikula wrote:
> On Tue, 17 Nov 2020, Lucas De Marchi  wrote:
>> On Tue, Nov 17, 2020 at 10:50:10AM -0800, Aditya Swarup wrote:
>>> @@ -1579,9 +1579,9 @@ static inline const struct i915_rev_steppings *
>>> tgl_revids_get(struct drm_i915_private *dev_priv)
>>> {
>>> if (IS_TGL_U(dev_priv) || IS_TGL_Y(dev_priv))
>>> -   return tgl_uy_revids;
>>> +   return tgl_uy_revids + INTEL_REVID(dev_priv);
>>
>> oohh, no. You have to at least check you are not accessing out of
>> bounds. New HW running on old kernel should not access create invalid
>> accesses like this.
> 
> And this is just one reason why exposing arrays directly as an interface
> to the rest of the driver is a bad idea. Basically I look at *all*
> externs in the driver with suspicion, and they're all exceptions that
> should not be repeated. The revid arrays are a direct invitation to keep
> adding more and more extern arrays. And more ways to go out of bounds.

We definitely need an array table for the SOC -> Display, GT stepping mapping.
SOC steppings were usually the same as display steppings/GT steppings until TGL 
and therefore
didn't require special mapping cases. But from TGL onwards, we have different 
combinations of 
Disp and GT steppings per SOC stepping. Alderlake-S makes this direct mapping 
even more difficult
without the array requiring more macros to deal with SOC -> DISP/GT stepping 
differences.

Will fix the array bound checks but the possibility of SOC revision id from drm 
struct going 
out of bounds is minimal. Can only happen if we don't have support for latest 
SOC -> Disp/GT table
for TGL from Bspec and if we are picking up wrong revision id from drm struct 
that means the platform
information obtained itself is wrong which will be a general platform problem 
unrelated to Gfx driver.

> 
> I'd rather we seek for ways to either nuke the revid arrays altogether,
> or encapsulate them within a .c file with static scope.

I don't think we should nuke the revid arrays but I agree with finding a more 
appropriate place to 
parse the gt/display stepping info. This should be an exercise for a later 
patch that takes 
care of kbl,tgl and adl-s mappings.

> 
> And for that .c file... the arrays are now in gt/intel_workarounds.c
> which is a really weird place for stuff that's used for generic stepping
> info, and particularly for *display* stepping info.

I agree and we can change the approach with a different patch later.

> 
> BR,
> Jani.
> 
> 

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

Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread Joe Perches 
On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> it's not for me to prove that such patches don't affect code 
> generation. That's for the patch author and (unfortunately) for reviewers.

Ideally, that proof would be provided by the compilation system itself
and not patch authors nor reviewers nor maintainers.

Unfortunately gcc does not guarantee repeatability or deterministic output.
To my knowledge, neither does clang.


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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/framebuffer: Format modifier for Intel Gen 12 render compression with Clear Color

2020-11-23 Thread Patchwork 
== Series Details ==

Series: series starting with [1/2] drm/framebuffer: Format modifier for Intel 
Gen 12 render compression with Clear Color
URL   : https://patchwork.freedesktop.org/series/84183/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9378 -> Patchwork_18961


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_fence@basic-await@rcs0:
- fi-skl-lmem:[PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-skl-lmem/igt@gem_exec_fence@basic-aw...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/fi-skl-lmem/igt@gem_exec_fence@basic-aw...@rcs0.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u:   [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html

  
New tests
-

  New tests have been introduced between CI_DRM_9378 and Patchwork_18961:

### New CI tests (1) ###

  * boot:
- Statuses : 40 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_busy@basic@flip:
- fi-tgl-y:   [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +1 similar 
issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-tgl-y/igt@kms_busy@ba...@flip.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/fi-tgl-y/igt@kms_busy@ba...@flip.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2:  [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +1 similar 
issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

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

  
 Possible fixes 

  * igt@kms_busy@basic@modeset:
- fi-tgl-y:   [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] +1 
similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-tgl-y/igt@kms_busy@ba...@modeset.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/fi-tgl-y/igt@kms_busy@ba...@modeset.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900:   [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- {fi-kbl-7560u}: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-icl-u2:  [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18961/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/framebuffer: Format modifier for Intel Gen 12 render compression with Clear Color

2020-11-23 Thread Patchwork 
== Series Details ==

Series: series starting with [1/2] drm/framebuffer: Format modifier for Intel 
Gen 12 render compression with Clear Color
URL   : https://patchwork.freedesktop.org/series/84183/
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:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static 
assertion failed:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/framebuffer: Format modifier for Intel Gen 12 render compression with Clear Color

2020-11-23 Thread Patchwork 
== Series Details ==

Series: series starting with [1/2] drm/framebuffer: Format modifier for Intel 
Gen 12 render compression with Clear Color
URL   : https://patchwork.freedesktop.org/series/84183/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
a3b4d1336125 drm/framebuffer: Format modifier for Intel Gen 12 render 
compression with Clear Color
0dba847db9d2 drm/i915/tgl: Add Clear Color support for TGL Render Decompression
-:304: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible 
side-effects?
#304: FILE: drivers/gpu/drm/i915/i915_reg.h:7120:
+#define PLANE_CC_VAL(pipe, plane)  \
+   _MMIO_PLANE(plane, _PLANE_CC_VAL_1(pipe), _PLANE_CC_VAL_2(pipe))

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


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

Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread Mark Brown 
On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 
for-next

Thanks!

[1/1] regulator: as3722: Fix fall-through warnings for Clang
  commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

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

Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread James Bottomley 
On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
>  wrote:
> > Well, I used git.  It says that as of today in Linus' tree we have
> > 889 patches related to fall throughs and the first series went in
> > in october 2017 ... ignoring a couple of outliers back to February.
> 
> I can see ~10k insertions over ~1k commits and 15 years that mention
> a fallthrough in the entire repo. That is including some commits
> (like the biggest one, 960 insertions) that have nothing to do with C
> fallthrough. A single kernel release has an order of magnitude more
> changes than this...
> 
> But if we do the math, for an author, at even 1 minute per line
> change and assuming nothing can be automated at all, it would take 1
> month of work. For maintainers, a couple of trivial lines is noise
> compared to many other patches.

So you think a one line patch should take one minute to produce ... I
really don't think that's grounded in reality.  I suppose a one line
patch only takes a minute to merge with b4 if no-one reviews or tests
it, but that's not really desirable.

> In fact, this discussion probably took more time than the time it
> would take to review the 200 lines. :-)

I'm framing the discussion in terms of the whole series of changes we
have done for fall through, both what's in the tree currently (889
patches) both in terms of the produce and the consumer.  That's what I
used for my figures for cost.

> > We're also complaining about the inability to recruit maintainers:
> > 
> > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> > 
> > And burn out:
> > 
> > http://antirez.com/news/129
> 
> Accepting trivial and useful 1-line patches

Part of what I'm trying to measure is the "and useful" bit because
that's not a given.

> is not what makes a voluntary maintainer quit...

so the proverb "straw which broke the camel's back" uniquely doesn't
apply to maintainers

>  Thankless work with demanding deadlines is.

That's another potential reason, but it doesn't may other reasons less
valid.

> > The whole crux of your argument seems to be maintainers' time isn't
> > important so we should accept all trivial patches
> 
> I have not said that, at all. In fact, I am a voluntary one and I
> welcome patches like this. It takes very little effort on my side to
> review and it helps the kernel overall.

Well, you know, subsystems are very different in terms of the amount of
patches a maintainer has to process per release cycle of the kernel. 
If a maintainer is close to capacity, additional patches, however
trivial, become a problem.  If a maintainer has spare cycles, trivial
patches may look easy.

> Paid maintainers are the ones that can take care of big
> features/reviews.
> 
> > What I'm actually trying to articulate is a way of measuring value
> > of the patch vs cost ... it has nothing really to do with who foots
> > the actual bill.
> 
> I understand your point, but you were the one putting it in terms of
> a junior FTE.

No, I evaluated the producer side in terms of an FTE.  What we're
mostly arguing about here is the consumer side: the maintainers and
people who have to rework their patch sets. I estimated that at 100h.

>  In my view, 1 month-work (worst case) is very much worth
> removing a class of errors from a critical codebase.
> 
> > One thesis I'm actually starting to formulate is that this
> > continual devaluing of maintainers is why we have so much
> > difficulty keeping and recruiting them.
> 
> That may very well be true, but I don't feel anybody has devalued
> maintainers in this discussion.

You seem to be saying that because you find it easy to merge trivial
patches, everyone should.  I'm reminded of a friend long ago who
thought being a Tees River Pilot was a sinecure because he could
navigate the Tees blindfold.  What he forgot, of course, is that just
because it's easy with a trawler doesn't mean it's easy with an oil
tanker.  In fact it takes longer to qualify as a Tees River Pilot than
it does to get a PhD.

James


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

[Intel-gfx] ✗ Fi.CI.BAT: failure for relay: cleanup and const callbacks, take 2

2020-11-23 Thread Patchwork 
== Series Details ==

Series: relay: cleanup and const callbacks, take 2
URL   : https://patchwork.freedesktop.org/series/84182/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9378 -> Patchwork_18960


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_close_race@basic-threads:
- fi-skl-lmem:[PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-skl-lmem/igt@gem_close_r...@basic-threads.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18960/fi-skl-lmem/igt@gem_close_r...@basic-threads.html

  
New tests
-

  New tests have been introduced between CI_DRM_9378 and Patchwork_18960:

### New CI tests (1) ###

  * boot:
- Statuses : 40 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload:
- fi-bxt-dsi: [PASS][3] -> [DMESG-WARN][4] ([i915#1635] / 
[i915#1982])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-bxt-dsi/igt@i915_module_l...@reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18960/fi-bxt-dsi/igt@i915_module_l...@reload.html

  * igt@i915_selftest@live@execlists:
- fi-cml-u2:  [PASS][5] -> [INCOMPLETE][6] ([i915#1037])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-cml-u2/igt@i915_selftest@l...@execlists.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18960/fi-cml-u2/igt@i915_selftest@l...@execlists.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka:   [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18960/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2:  [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +1 
similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18960/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_psr@primary_page_flip:
- fi-tgl-y:   [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +1 
similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-tgl-y/igt@kms_psr@primary_page_flip.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18960/fi-tgl-y/igt@kms_psr@primary_page_flip.html

  * igt@prime_self_import@basic-with_one_bo:
- fi-tgl-y:   [PASS][13] -> [DMESG-WARN][14] ([i915#402])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-tgl-y/igt@prime_self_import@basic-with_one_bo.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18960/fi-tgl-y/igt@prime_self_import@basic-with_one_bo.html

  
 Possible fixes 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka:   [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18960/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@kms_busy@basic@modeset:
- fi-tgl-y:   [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] +1 
similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-tgl-y/igt@kms_busy@ba...@modeset.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18960/fi-tgl-y/igt@kms_busy@ba...@modeset.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900:   [DMESG-WARN][19] ([i915#1982]) -> [PASS][20] +1 
similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9378/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18960/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@prime_vgem@basic-write:
- fi-tgl-y:   [DMESG-WARN][21]

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Record the plane update times for debugging (rev2)

2020-11-23 Thread Patchwork 
== Series Details ==

Series: drm/i915/display: Record the plane update times for debugging (rev2)
URL   : https://patchwork.freedesktop.org/series/84174/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9376_full -> Patchwork_18959_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * {igt@kms_flip_tiling@flip-to-x-tiled@edp-1-pipe-c}:
- shard-skl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/shard-skl4/igt@kms_flip_tiling@flip-to-x-ti...@edp-1-pipe-c.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18959/shard-skl1/igt@kms_flip_tiling@flip-to-x-ti...@edp-1-pipe-c.html

  
New tests
-

  New tests have been introduced between CI_DRM_9376_full and 
Patchwork_18959_full:

### New CI tests (1) ###

  * boot:
- Statuses : 175 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_whisper@basic-contexts-priority-all:
- shard-glk:  [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/shard-glk8/igt@gem_exec_whis...@basic-contexts-priority-all.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18959/shard-glk2/igt@gem_exec_whis...@basic-contexts-priority-all.html

  * igt@gem_workarounds@suspend-resume-fd:
- shard-glk:  [PASS][5] -> [INCOMPLETE][6] ([i915#2199] / 
[i915#2405])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/shard-glk1/igt@gem_workarou...@suspend-resume-fd.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18959/shard-glk9/igt@gem_workarou...@suspend-resume-fd.html

  * igt@kms_cursor_crc@pipe-c-cursor-64x64-onscreen:
- shard-skl:  [PASS][7] -> [FAIL][8] ([i915#54])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/shard-skl5/igt@kms_cursor_...@pipe-c-cursor-64x64-onscreen.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18959/shard-skl10/igt@kms_cursor_...@pipe-c-cursor-64x64-onscreen.html

  * igt@kms_cursor_legacy@flip-vs-cursor-toggle:
- shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2346])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/shard-tglb3/igt@kms_cursor_leg...@flip-vs-cursor-toggle.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18959/shard-tglb6/igt@kms_cursor_leg...@flip-vs-cursor-toggle.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1:
- shard-skl:  [PASS][11] -> [FAIL][12] ([i915#79]) +1 similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/shard-skl9/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18959/shard-skl10/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html

  * igt@kms_flip@flip-vs-expired-vblank@a-edp1:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2598])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/shard-tglb6/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18959/shard-tglb8/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html

  * igt@kms_flip@flip-vs-suspend@b-dp1:
- shard-kbl:  [PASS][15] -> [DMESG-WARN][16] ([i915#180])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/shard-kbl1/igt@kms_flip@flip-vs-susp...@b-dp1.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18959/shard-kbl6/igt@kms_flip@flip-vs-susp...@b-dp1.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl:  [PASS][17] -> [FAIL][18] ([fdo#108145] / [i915#265]) 
+2 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18959/shard-skl5/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html

  * igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18959/shard-iclb7/igt@kms_psr@psr2_primary_page_flip.html

  * igt@kms_universal_plane@universal-plane-pipe-c-functional:
- shard-skl:  [PASS][21] -> [FAIL][22] ([i915#331])
   [21]:

[Intel-gfx] [PATCH i-g-t] i915/gem_request_retire: Switch from random blitter loads to dummy

2020-11-23 Thread Chris Wilson 
Use the spinners to provide exactly the right amount of background
busyness.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 lib/igt_dummyload.c |  13 +--
 lib/igt_dummyload.h |   1 +
 tests/i915/gem_request_retire.c | 169 
 3 files changed, 23 insertions(+), 160 deletions(-)

diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index d58f73108..8b2709e71 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -161,19 +161,10 @@ emit_recursive_batch(igt_spin_t *spin,
if (opts->dependency) {
igt_assert(!(opts->flags & IGT_SPIN_POLL_RUN));
 
-   r = [obj[BATCH].relocation_count++];
-
-   /* dummy write to dependency */
obj[SCRATCH].handle = opts->dependency;
obj[SCRATCH].offset = addr;
-   obj[SCRATCH].flags = EXEC_OBJECT_WRITE;
-
-   r->presumed_offset = obj[SCRATCH].offset;
-   r->target_handle = obj[SCRATCH].handle;
-   r->offset = sizeof(uint32_t) * 1020;
-   r->delta = 0;
-   r->read_domains = I915_GEM_DOMAIN_RENDER;
-   r->write_domain = I915_GEM_DOMAIN_RENDER;
+   if (!(opts->flags & IGT_SPIN_SOFTDEP))
+   obj[SCRATCH].flags = EXEC_OBJECT_WRITE;
 
execbuf->buffer_count++;
} else if (opts->flags & IGT_SPIN_POLL_RUN) {
diff --git a/lib/igt_dummyload.h b/lib/igt_dummyload.h
index 6d3e65ce2..b8baaa6b4 100644
--- a/lib/igt_dummyload.h
+++ b/lib/igt_dummyload.h
@@ -71,6 +71,7 @@ struct igt_spin_factory {
 #define IGT_SPIN_NO_PREEMPTION (1 << 4)
 #define IGT_SPIN_INVALID_CS(1 << 5)
 #define IGT_SPIN_USERPTR   (1 << 6)
+#define IGT_SPIN_SOFTDEP   (1 << 7)
 
 igt_spin_t *
 __igt_spin_factory(int fd, const struct igt_spin_factory *opts);
diff --git a/tests/i915/gem_request_retire.c b/tests/i915/gem_request_retire.c
index 31fb41987..d0e53d221 100644
--- a/tests/i915/gem_request_retire.c
+++ b/tests/i915/gem_request_retire.c
@@ -52,130 +52,6 @@
 IGT_TEST_DESCRIPTION("Collection of tests targeting request retirement code"
 " paths.");
 
-#define WIDTH 4096
-#define HEIGHT 4096
-#define BO_SIZE (WIDTH * HEIGHT * sizeof(uint32_t))
-
-static uint32_t
-blit(int fd, uint32_t dst, uint32_t src, uint32_t ctx_id)
-{
-   const unsigned int copies = 1000;
-   uint32_t batch[12 * copies + 5];
-   struct drm_i915_gem_relocation_entry reloc[2 * copies];
-   struct drm_i915_gem_exec_object2 obj[3];
-   struct drm_i915_gem_execbuffer2 exec;
-   uint32_t handle;
-   unsigned int i = 0, j, r = 0;
-
-   for (j = 0; j < copies; j++) {
-   reloc[r].target_handle = dst;
-   reloc[r].delta = 0;
-   reloc[r].offset = (i + 4) * sizeof(uint32_t);
-   reloc[r].presumed_offset = 0;
-   reloc[r].read_domains = I915_GEM_DOMAIN_RENDER;
-   reloc[r].write_domain = I915_GEM_DOMAIN_RENDER;
-
-   r++;
-
-   reloc[r].target_handle = src;
-   reloc[r].delta = 0;
-   reloc[r].offset = (i + 7) * sizeof(uint32_t);
-   if (intel_gen(intel_get_drm_devid(fd)) >= 8)
-   reloc[r].offset += sizeof(uint32_t);
-   reloc[r].presumed_offset = 0;
-   reloc[r].read_domains = I915_GEM_DOMAIN_RENDER;
-   reloc[r].write_domain = 0;
-
-   r++;
-
-   batch[i++] = XY_SRC_COPY_BLT_CMD |
-   XY_SRC_COPY_BLT_WRITE_ALPHA |
-   XY_SRC_COPY_BLT_WRITE_RGB;
-   if (intel_gen(intel_get_drm_devid(fd)) >= 8)
-   batch[i - 1] |= 8;
-   else
-   batch[i - 1] |= 6;
-
-   batch[i++] = (3 << 24) | /* 32 bits */
-   (0xcc << 16) | /* copy ROP */
-   WIDTH*4;
-   batch[i++] = 0; /* dst x1,y1 */
-   batch[i++] = (HEIGHT << 16) | WIDTH; /* dst x2,y2 */
-   batch[i++] = 0; /* dst reloc */
-   if (intel_gen(intel_get_drm_devid(fd)) >= 8)
-   batch[i++] = 0;
-   batch[i++] = 0; /* src x1,y1 */
-   batch[i++] = WIDTH*4;
-   batch[i++] = 0; /* src reloc */
-   if (intel_gen(intel_get_drm_devid(fd)) >= 8)
-   batch[i++] = 0;
-   }
-
-   batch[i++] = MI_BATCH_BUFFER_END;
-
-   while (i % 4)
-   batch[i++] = MI_NOOP;
-
-   handle = gem_create(fd, sizeof(batch));
-   gem_write(fd, handle, 0, batch, sizeof(batch));
-
-   memset(obj, 0, sizeof(obj));
-   memset(, 0, sizeof(exec));
-
-   obj[exec.buffer_count++].handle = dst;
-   if (src != dst)
-   obj[exec.buffer_count++].handle = src;
-   obj[exec.buffer_count].handle = handle;
-   obj[exec.buffer_count].relocation_count = 2 * copies;
-

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for relay: cleanup and const callbacks, take 2

2020-11-23 Thread Patchwork 
== Series Details ==

Series: relay: cleanup and const callbacks, take 2
URL   : https://patchwork.freedesktop.org/series/84182/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_reset.c:1312:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/selftest_reset.c:100:20:expected void *in
+drivers/gpu/drm/i915/gt/selftest_reset.c:100:20:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:100:20: warning: incorrect type in 
assignment (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:101:46:expected void const *src
+drivers/gpu/drm/i915/gt/selftest_reset.c:101:46:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:101:46: warning: incorrect type in 
argument 2 (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:136:20:expected void *in
+drivers/gpu/drm/i915/gt/selftest_reset.c:136:20:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:136:20: warning: incorrect type in 
assignment (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:137:46:expected void const *src
+drivers/gpu/drm/i915/gt/selftest_reset.c:137:46:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:137:46: warning: incorrect type in 
argument 2 (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:98:34:expected unsigned int 
[usertype] *s
+drivers/gpu/drm/i915/gt/selftest_reset.c:98:34:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:98:34: warning: incorrect type in 
argument 1 (different address spaces)
+drivers/gpu/drm/i915/gvt/mmio.c:290:23: warning: memcpy with byte count of 
279040
+drivers/gpu/drm/i915/i915_perf.c:1447:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1501:15: warning: memset with byte count of 
16777216
+./include/linux/seqlock.h:838:24: warning: trying to copy expression type 31
+./include/linux/seqlock.h:838:24: warning: trying to copy expression type 31
+./include/linux/seqlock.h:864:16: warning: trying to copy expression type 31
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context

Re: [Intel-gfx] [PATCH 0/9] relay: cleanup and const callbacks, take 2

2020-11-23 Thread Kalle Valo 
Jani Nikula  writes:

> This is v2 of [1], with a number of cleanups added first based on
> Christoph's feedback, making the actual constness patch much smaller and
> cleaner.
>
> I don't know who actually maintains relay, it's not in MAINTAINERS -
> Cc'd Andrew just in case.
>
> I'd think it would be simplest to queue patches 5-9 via whichever tree
> the relay patches get merged. They're all one-liners so neglible
> conflict potential.
>
> BR,
> Jani.
>
>
> [1] http://lore.kernel.org/r/20201118165320.26829-1-jani.nik...@intel.com
>
>
> Cc: linux-bl...@vger.kernel.org
> Cc: Jens Axboe 
> Cc: ath...@lists.infradead.org
> Cc: ath...@lists.infradead.org
> Cc: Kalle Valo 
> Cc: linux-wirel...@vger.kernel.org
> Cc: QCA ath9k Development 
> Cc: intel-gfx@lists.freedesktop.org
> Cc: Christoph Hellwig 
> Cc: Andrew Morton 
>
>
> Jani Nikula (9):
>   relay: remove unused buf_mapped and buf_unmapped callbacks
>   relay: require non-NULL callbacks in relay_open()
>   relay: make create_buf_file and remove_buf_file callbacks mandatory
>   relay: allow the use of const callback structs
>   drm/i915: make relay callbacks const
>   ath10k: make relay callbacks const
>   ath11k: make relay callbacks const
>   ath9k: make relay callbacks const
>   blktrace: make relay callbacks const

For ath9k, ath10k & ath11k:

Acked-by: Kalle Valo 

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread Miguel Ojeda 
On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
 wrote:
>
> Well, I used git.  It says that as of today in Linus' tree we have 889
> patches related to fall throughs and the first series went in in
> october 2017 ... ignoring a couple of outliers back to February.

I can see ~10k insertions over ~1k commits and 15 years that mention a
fallthrough in the entire repo. That is including some commits (like
the biggest one, 960 insertions) that have nothing to do with C
fallthrough. A single kernel release has an order of magnitude more
changes than this...

But if we do the math, for an author, at even 1 minute per line change
and assuming nothing can be automated at all, it would take 1 month of
work. For maintainers, a couple of trivial lines is noise compared to
many other patches.

In fact, this discussion probably took more time than the time it
would take to review the 200 lines. :-)

> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Accepting trivial and useful 1-line patches is not what makes a
voluntary maintainer quit... Thankless work with demanding deadlines is.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches

I have not said that, at all. In fact, I am a voluntary one and I
welcome patches like this. It takes very little effort on my side to
review and it helps the kernel overall. Paid maintainers are the ones
that can take care of big features/reviews.

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

I understand your point, but you were the one putting it in terms of a
junior FTE. In my view, 1 month-work (worst case) is very much worth
removing a class of errors from a critical codebase.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

That may very well be true, but I don't feel anybody has devalued
maintainers in this discussion.

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

[Intel-gfx] [PATCH 2/2] drm/i915/tgl: Add Clear Color support for TGL Render Decompression

2020-11-23 Thread Imre Deak 
From: Radhakrishna Sripada 

Render Decompression is supported with Y-Tiled main surface. The CCS is
linear and has 4 bits of data for each main surface cache line pair, a
ratio of 1:256. Additional Clear Color information is passed from the
user-space through an offset in the GEM BO. Add a new modifier to identify
and parse new Clear Color information and extend Gen12 render decompression
functionality to the newly added modifier.

v2: Fix has_alpha flag for modifiers, omit CC modifier during initial
plane config(Matt). Fix Lookup error.
v3: Fix the panic while running kms_cube
v4: Add alignment check and reuse the comments for ge12_ccs_formats(Matt)
v5: Fix typos and wrap comments(Matt)
v6:
- Use format block descriptors to get the subsampling calculations for
  the CCS surface right.
- Use helpers to convert between main and CCS surfaces.
- Prevent coordinate checks for the CC surface.
- Simplify reading CC value from surface map, add description of CC val
  layout.
- Remove redundant ccval variable from skl_program_plane().

Cc: Dhinakaran Pandiyan 
Cc: Ville Syrjala 
Cc: Shashank Sharma 
Cc: Rafael Antognolli 
Cc: Nanley G Chery 
Cc: Chris Wilson 
Reviewed-by: Matt Roper  (v5)
Signed-off-by: Radhakrishna Sripada 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_display.c  | 72 +--
 .../drm/i915/display/intel_display_types.h|  3 +
 drivers/gpu/drm/i915/display/intel_sprite.c   | 10 ++-
 drivers/gpu/drm/i915/i915_reg.h   |  9 +++
 4 files changed, 89 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 595183f7b60f..f190f6f4cdf5 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1968,8 +1968,8 @@ static bool is_ccs_plane(const struct drm_framebuffer 
*fb, int plane)
 static bool is_gen12_ccs_modifier(u64 modifier)
 {
return modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS ||
+  modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC ||
   modifier == I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS;
-
 }
 
 static bool is_gen12_ccs_plane(const struct drm_framebuffer *fb, int plane)
@@ -1977,6 +1977,12 @@ static bool is_gen12_ccs_plane(const struct 
drm_framebuffer *fb, int plane)
return is_gen12_ccs_modifier(fb->modifier) && is_ccs_plane(fb, plane);
 }
 
+static bool is_gen12_ccs_cc_plane(const struct drm_framebuffer *fb, int plane)
+{
+   return fb->modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC &&
+  plane == 2;
+}
+
 static bool is_aux_plane(const struct drm_framebuffer *fb, int plane)
 {
if (is_ccs_modifier(fb->modifier))
@@ -1998,6 +2004,9 @@ static int ccs_to_main_plane(const struct drm_framebuffer 
*fb, int ccs_plane)
drm_WARN_ON(fb->dev, !is_ccs_modifier(fb->modifier) ||
ccs_plane < fb->format->num_planes / 2);
 
+   if (is_gen12_ccs_cc_plane(fb, ccs_plane))
+   return 0;
+
return ccs_plane - fb->format->num_planes / 2;
 }
 
@@ -2048,6 +2057,7 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb, 
int color_plane)
return 128;
fallthrough;
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
+   case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
if (is_ccs_plane(fb, color_plane))
return 64;
@@ -2204,6 +2214,7 @@ static unsigned int intel_surf_alignment(const struct 
drm_framebuffer *fb,
return intel_tile_row_size(fb, color_plane);
fallthrough;
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
+   case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
return 16 * 1024;
case I915_FORMAT_MOD_Y_TILED_CCS:
case I915_FORMAT_MOD_Yf_TILED_CCS:
@@ -2608,6 +2619,7 @@ static unsigned int intel_fb_modifier_to_tiling(u64 
fb_modifier)
case I915_FORMAT_MOD_Y_TILED:
case I915_FORMAT_MOD_Y_TILED_CCS:
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
+   case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
return I915_TILING_Y;
default:
@@ -2686,6 +2698,25 @@ static const struct drm_format_info gen12_ccs_formats[] 
= {
  .hsub = 2, .vsub = 2, .is_yuv = true },
 };
 
+/*
+ * Same as gen12_ccs_formats[] above, but with additional surface used
+ * to pass Clear Color information in plane 2 with 64 bits of data.
+ */
+static const struct drm_format_info gen12_ccs_cc_formats[] = {
+   { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 3,
+ .char_per_block = { 4, 1, 0 }, .block_w = { 1, 2, 2 }, .block_h = { 
1, 1, 1 },
+ .hsub = 1, .vsub = 1, },
+   { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 3,
+ .char_per_block = { 4, 1, 0 }, .block_w = { 1, 2, 2 }, .block_h = {

[Intel-gfx] [PATCH 1/2] drm/framebuffer: Format modifier for Intel Gen 12 render compression with Clear Color

2020-11-23 Thread Imre Deak 
From: Radhakrishna Sripada 

Gen12 display can decompress surfaces compressed by render engine with
Clear Color, add a new modifier as the driver needs to know the surface
was compressed by render engine.

V2: Description changes as suggested by Rafael.
V3: Mention the Clear Color size of 64 bits in the comments(DK)
v4: Fix trailing whitespaces
v5: Explain Clear Color in the documentation.
v6: Documentation Nitpicks(Nanley)

Cc: Ville Syrjala 
Cc: Dhinakaran Pandiyan 
Cc: Kalyan Kondapally 
Cc: Rafael Antognolli 
Cc: Nanley Chery 
Signed-off-by: Radhakrishna Sripada 
Signed-off-by: Imre Deak 
---
 include/uapi/drm/drm_fourcc.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index ca48ed0e6bc1..0a1b2c4c4bee 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -527,6 +527,25 @@ extern "C" {
  */
 #define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS fourcc_mod_code(INTEL, 7)
 
+/*
+ * Intel Color Control Surface with Clear Color (CCS) for Gen-12 render
+ * compression.
+ *
+ * The main surface is Y-tiled and is at plane index 0 whereas CCS is linear
+ * and at index 1. The clear color is stored at index 2, and the pitch should
+ * be ignored. The clear color structure is 256 bits. The first 128 bits
+ * represents Raw Clear Color Red, Green, Blue and Alpha color each represented
+ * by 32 bits. The raw clear color is consumed by the 3d engine and generates
+ * the converted clear color of size 64 bits. The first 32 bits store the Lower
+ * Converted Clear Color value and the next 32 bits store the Higher Converted
+ * Clear Color value when applicable. The Converted Clear Color values are
+ * consumed by the DE. The last 64 bits are used to store Color Discard Enable
+ * and Depth Clear Value Valid which are ignored by the DE. A CCS cache line
+ * corresponds to an area of 4x1 tiles in the main surface. The main surface
+ * pitch is required to be a multiple of 4 tile widths.
+ */
+#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC fourcc_mod_code(INTEL, 8)
+
 /*
  * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
  *
-- 
2.25.1

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

Re: [Intel-gfx] [PATCH 1/6] relay: allow the use of const callback structs

2020-11-23 Thread Jani Nikula 
On Thu, 19 Nov 2020, Christoph Hellwig  wrote:
> But taking one step back:  All instances implement create_buf_file
> and remove_buf_file, which makes sense as that is the prime aim
> of these methods.  So there is no point in making those optional.
> subbuf_start_callback is overriden by two instances, so making that
> optional totally makes sense.  buf_mapped and buf_unmapped are
> never overriden, so they should be removed entirely.
>
> More importantly there is no case that passes a NULL rchan_callbacks,
> which makes complete sense as it wouldn't even create a file.  So
> remove that case as well and just replace it with a sanity check in
> relay_open().

Many thanks for the feedback; sent v2 [1].

BR,
Jani.


[1] http://lore.kernel.org/r/cover.1606153547.git.jani.nik...@intel.com


-- 
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 6/9] ath10k: make relay callbacks const

2020-11-23 Thread Jani Nikula 
Now that relay_open() accepts const callbacks, make relay callbacks
const.

Cc: Kalle Valo 
Cc: ath...@lists.infradead.org
Acked-by: Kalle Valo 
Signed-off-by: Jani Nikula 
---
 drivers/net/wireless/ath/ath10k/spectral.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/spectral.c 
b/drivers/net/wireless/ath/ath10k/spectral.c
index 5db6bff5193b..68254a967ccb 100644
--- a/drivers/net/wireless/ath/ath10k/spectral.c
+++ b/drivers/net/wireless/ath/ath10k/spectral.c
@@ -497,7 +497,7 @@ static int remove_buf_file_handler(struct dentry *dentry)
return 0;
 }
 
-static struct rchan_callbacks rfs_spec_scan_cb = {
+static const struct rchan_callbacks rfs_spec_scan_cb = {
.create_buf_file = create_buf_file_handler,
.remove_buf_file = remove_buf_file_handler,
 };
-- 
2.20.1

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

[Intel-gfx] [PATCH 9/9] blktrace: make relay callbacks const

2020-11-23 Thread Jani Nikula 
Now that relay_open() accepts const callbacks, make relay callbacks
const.

Cc: Jens Axboe 
Cc: linux-bl...@vger.kernel.org
Signed-off-by: Jani Nikula 
---
 kernel/trace/blktrace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
index f1022945e346..b5c4b9ade960 100644
--- a/kernel/trace/blktrace.c
+++ b/kernel/trace/blktrace.c
@@ -449,7 +449,7 @@ static struct dentry *blk_create_buf_file_callback(const 
char *filename,
_file_operations);
 }
 
-static struct rchan_callbacks blk_relay_callbacks = {
+static const struct rchan_callbacks blk_relay_callbacks = {
.subbuf_start   = blk_subbuf_start_callback,
.create_buf_file= blk_create_buf_file_callback,
.remove_buf_file= blk_remove_buf_file_callback,
-- 
2.20.1

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

[Intel-gfx] [PATCH 8/9] ath9k: make relay callbacks const

2020-11-23 Thread Jani Nikula 
Now that relay_open() accepts const callbacks, make relay callbacks
const.

Cc: Kalle Valo 
Cc: QCA ath9k Development 
Cc: linux-wirel...@vger.kernel.org
Acked-by: Kalle Valo 
Signed-off-by: Jani Nikula 
---
 drivers/net/wireless/ath/ath9k/common-spectral.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/common-spectral.c 
b/drivers/net/wireless/ath/ath9k/common-spectral.c
index 21191955a7c1..e055adfb5361 100644
--- a/drivers/net/wireless/ath/ath9k/common-spectral.c
+++ b/drivers/net/wireless/ath/ath9k/common-spectral.c
@@ -1053,7 +1053,7 @@ static int remove_buf_file_handler(struct dentry *dentry)
return 0;
 }
 
-static struct rchan_callbacks rfs_spec_scan_cb = {
+static const struct rchan_callbacks rfs_spec_scan_cb = {
.create_buf_file = create_buf_file_handler,
.remove_buf_file = remove_buf_file_handler,
 };
-- 
2.20.1

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

[Intel-gfx] [PATCH 7/9] ath11k: make relay callbacks const

2020-11-23 Thread Jani Nikula 
Now that relay_open() accepts const callbacks, make relay callbacks
const.

Cc: Kalle Valo 
Cc: ath...@lists.infradead.org
Signed-off-by: Jani Nikula 
---
 drivers/net/wireless/ath/ath11k/spectral.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath11k/spectral.c 
b/drivers/net/wireless/ath/ath11k/spectral.c
index ac2a8cfdc1c0..1afe67759659 100644
--- a/drivers/net/wireless/ath/ath11k/spectral.c
+++ b/drivers/net/wireless/ath/ath11k/spectral.c
@@ -148,7 +148,7 @@ static int remove_buf_file_handler(struct dentry *dentry)
return 0;
 }
 
-static struct rchan_callbacks rfs_scan_cb = {
+static const struct rchan_callbacks rfs_scan_cb = {
.create_buf_file = create_buf_file_handler,
.remove_buf_file = remove_buf_file_handler,
 };
-- 
2.20.1

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

[Intel-gfx] [PATCH 5/9] drm/i915: make relay callbacks const

2020-11-23 Thread Jani Nikula 
Now that relay_open() accepts const callbacks, make relay callbacks
const.

Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index 9bbe8a795cb8..c92f2c056db4 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -134,7 +134,7 @@ static int remove_buf_file_callback(struct dentry *dentry)
 }
 
 /* relay channel callbacks */
-static struct rchan_callbacks relay_callbacks = {
+static const struct rchan_callbacks relay_callbacks = {
.subbuf_start = subbuf_start_callback,
.create_buf_file = create_buf_file_callback,
.remove_buf_file = remove_buf_file_callback,
-- 
2.20.1

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

[Intel-gfx] [PATCH 4/9] relay: allow the use of const callback structs

2020-11-23 Thread Jani Nikula 
None of the relay users require the use of mutable structs for
callbacks, however the relay code does. Instead of assigning the default
callback for subbuf_start, add a wrapper to conditionally call the
client callback if available, and fall back to default behaviour
otherwise.

This lets all relay users make their struct rchan_callbacks const data.

Cc: linux-bl...@vger.kernel.org
Cc: Jens Axboe 
Cc: ath...@lists.infradead.org
Cc: ath...@lists.infradead.org
Cc: Kalle Valo 
Cc: linux-wirel...@vger.kernel.org
Cc: QCA ath9k Development 
Cc: intel-gfx@lists.freedesktop.org
Cc: Christoph Hellwig 
Signed-off-by: Jani Nikula 

---

v2: Simplify after nuking some callbacks and making some others
mandatory in previous patches, as per Christoph's review comments.

I thought about adding wrappers for the now-mandatory create_buf_file
and remove_buf_file as well, for consistency, but ended up leaving them
out.
---
 include/linux/relay.h |  4 ++--
 kernel/relay.c| 35 +++
 2 files changed, 13 insertions(+), 26 deletions(-)

diff --git a/include/linux/relay.h b/include/linux/relay.h
index 99d024475ba5..72b876dd5cb8 100644
--- a/include/linux/relay.h
+++ b/include/linux/relay.h
@@ -62,7 +62,7 @@ struct rchan
size_t subbuf_size; /* sub-buffer size */
size_t n_subbufs;   /* number of sub-buffers per buffer */
size_t alloc_size;  /* total buffer size allocated */
-   struct rchan_callbacks *cb; /* client callbacks */
+   const struct rchan_callbacks *cb; /* client callbacks */
struct kref kref;   /* channel refcount */
void *private_data; /* for user-defined data */
size_t last_toobig; /* tried to log event > subbuf size */
@@ -157,7 +157,7 @@ struct rchan *relay_open(const char *base_filename,
 struct dentry *parent,
 size_t subbuf_size,
 size_t n_subbufs,
-struct rchan_callbacks *cb,
+const struct rchan_callbacks *cb,
 void *private_data);
 extern int relay_late_setup_files(struct rchan *chan,
  const char *base_filename,
diff --git a/kernel/relay.c b/kernel/relay.c
index dd4ec4ec07f3..02bdba5372cb 100644
--- a/kernel/relay.c
+++ b/kernel/relay.c
@@ -252,19 +252,14 @@ EXPORT_SYMBOL_GPL(relay_buf_full);
  * High-level relay kernel API and associated functions.
  */
 
-/*
- * rchan_callback implementations defining default channel behavior.  Used
- * in place of corresponding NULL values in client callback struct.
- */
-
-/*
- * subbuf_start() default callback.  Does nothing.
- */
-static int subbuf_start_default_callback (struct rchan_buf *buf,
- void *subbuf,
- void *prev_subbuf,
- size_t prev_padding)
+/* subbuf_start callback wrapper */
+static int cb_subbuf_start(struct rchan_buf *buf, void *subbuf,
+  void *prev_subbuf, size_t prev_padding)
 {
+   if (buf->chan->cb->subbuf_start)
+   return buf->chan->cb->subbuf_start(buf, subbuf,
+  prev_subbuf, prev_padding);
+
if (relay_buf_full(buf))
return 0;
 
@@ -314,7 +309,7 @@ static void __relay_reset(struct rchan_buf *buf, unsigned 
int init)
for (i = 0; i < buf->chan->n_subbufs; i++)
buf->padding[i] = 0;
 
-   buf->chan->cb->subbuf_start(buf, buf->data, NULL, 0);
+   cb_subbuf_start(buf, buf->data, NULL, 0);
 }
 
 /**
@@ -442,14 +437,6 @@ static void relay_close_buf(struct rchan_buf *buf)
kref_put(>kref, relay_remove_buf);
 }
 
-static void setup_callbacks(struct rchan *chan,
-  struct rchan_callbacks *cb)
-{
-   if (!cb->subbuf_start)
-   cb->subbuf_start = subbuf_start_default_callback;
-   chan->cb = cb;
-}
-
 int relay_prepare_cpu(unsigned int cpu)
 {
struct rchan *chan;
@@ -495,7 +482,7 @@ struct rchan *relay_open(const char *base_filename,
 struct dentry *parent,
 size_t subbuf_size,
 size_t n_subbufs,
-struct rchan_callbacks *cb,
+const struct rchan_callbacks *cb,
 void *private_data)
 {
unsigned int i;
@@ -529,7 +516,7 @@ struct rchan *relay_open(const char *base_filename,
chan->has_base_filename = 1;
strlcpy(chan->base_filename, base_filename, NAME_MAX);
}
-   setup_callbacks(chan, cb);
+   chan->cb = cb;
kref_init(>kref);
 
mutex_lock(_channels_mutex);
@@ -712,7 +699,7 @@ size_t relay_switch_subbuf(struct rchan_buf *buf, size_t 
length)
new_subbuf = buf->subbufs_produced %

[Intel-gfx] [PATCH 3/9] relay: make create_buf_file and remove_buf_file callbacks mandatory

2020-11-23 Thread Jani Nikula 
All clients provide create_buf_file and remove_buf_file callbacks, and
they're required for relay to make sense. There is no point in them
being optional.

Also document whether each callback is mandatory/optional.

Suggested-by: Christoph Hellwig 
Cc: Christoph Hellwig 
Signed-off-by: Jani Nikula 
---
 include/linux/relay.h |  6 ++
 kernel/relay.c| 26 +-
 2 files changed, 7 insertions(+), 25 deletions(-)

diff --git a/include/linux/relay.h b/include/linux/relay.h
index b3c4f49f6951..99d024475ba5 100644
--- a/include/linux/relay.h
+++ b/include/linux/relay.h
@@ -89,6 +89,8 @@ struct rchan_callbacks
 * The client should return 1 to continue logging, 0 to stop
 * logging.
 *
+* This callback is optional.
+*
 * NOTE: subbuf_start will also be invoked when the buffer is
 *   created, so that the first sub-buffer can be initialized
 *   if necessary.  In this case, prev_subbuf will be NULL.
@@ -122,6 +124,8 @@ struct rchan_callbacks
 * cause relay_open() to create a single global buffer rather
 * than the default set of per-cpu buffers.
 *
+* This callback is mandatory.
+*
 * See Documentation/filesystems/relay.rst for more info.
 */
struct dentry *(*create_buf_file)(const char *filename,
@@ -139,6 +143,8 @@ struct rchan_callbacks
 * channel buffer.
 *
 * The callback should return 0 if successful, negative if not.
+*
+* This callback is mandatory.
 */
int (*remove_buf_file)(struct dentry *dentry);
 };
diff --git a/kernel/relay.c b/kernel/relay.c
index d9b8185161a8..dd4ec4ec07f3 100644
--- a/kernel/relay.c
+++ b/kernel/relay.c
@@ -271,26 +271,6 @@ static int subbuf_start_default_callback (struct rchan_buf 
*buf,
return 1;
 }
 
-/*
- * create_buf_file_create() default callback.  Does nothing.
- */
-static struct dentry *create_buf_file_default_callback(const char *filename,
-  struct dentry *parent,
-  umode_t mode,
-  struct rchan_buf *buf,
-  int *is_global)
-{
-   return NULL;
-}
-
-/*
- * remove_buf_file() default callback.  Does nothing.
- */
-static int remove_buf_file_default_callback(struct dentry *dentry)
-{
-   return -EINVAL;
-}
-
 /**
  * wakeup_readers - wake up readers waiting on a channel
  * @work: contains the channel buffer
@@ -467,10 +447,6 @@ static void setup_callbacks(struct rchan *chan,
 {
if (!cb->subbuf_start)
cb->subbuf_start = subbuf_start_default_callback;
-   if (!cb->create_buf_file)
-   cb->create_buf_file = create_buf_file_default_callback;
-   if (!cb->remove_buf_file)
-   cb->remove_buf_file = remove_buf_file_default_callback;
chan->cb = cb;
 }
 
@@ -530,7 +506,7 @@ struct rchan *relay_open(const char *base_filename,
return NULL;
if (subbuf_size > UINT_MAX / n_subbufs)
return NULL;
-   if (!cb)
+   if (!cb || !cb->create_buf_file || !cb->remove_buf_file)
return NULL;
 
chan = kzalloc(sizeof(struct rchan), GFP_KERNEL);
-- 
2.20.1

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

[Intel-gfx] [PATCH 2/9] relay: require non-NULL callbacks in relay_open()

2020-11-23 Thread Jani Nikula 
There are no clients passing NULL callbacks, which makes sense as it
wouldn't even create a file. Require non-NULL callbacks, and throw away
the handling for NULL callbacks.

Suggested-by: Christoph Hellwig 
Cc: Christoph Hellwig 
Signed-off-by: Jani Nikula 
---
 kernel/relay.c | 14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/kernel/relay.c b/kernel/relay.c
index b51343642bf4..d9b8185161a8 100644
--- a/kernel/relay.c
+++ b/kernel/relay.c
@@ -291,13 +291,6 @@ static int remove_buf_file_default_callback(struct dentry 
*dentry)
return -EINVAL;
 }
 
-/* relay channel default callbacks */
-static struct rchan_callbacks default_channel_callbacks = {
-   .subbuf_start = subbuf_start_default_callback,
-   .create_buf_file = create_buf_file_default_callback,
-   .remove_buf_file = remove_buf_file_default_callback,
-};
-
 /**
  * wakeup_readers - wake up readers waiting on a channel
  * @work: contains the channel buffer
@@ -472,11 +465,6 @@ static void relay_close_buf(struct rchan_buf *buf)
 static void setup_callbacks(struct rchan *chan,
   struct rchan_callbacks *cb)
 {
-   if (!cb) {
-   chan->cb = _channel_callbacks;
-   return;
-   }
-
if (!cb->subbuf_start)
cb->subbuf_start = subbuf_start_default_callback;
if (!cb->create_buf_file)
@@ -542,6 +530,8 @@ struct rchan *relay_open(const char *base_filename,
return NULL;
if (subbuf_size > UINT_MAX / n_subbufs)
return NULL;
+   if (!cb)
+   return NULL;
 
chan = kzalloc(sizeof(struct rchan), GFP_KERNEL);
if (!chan)
-- 
2.20.1

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

[Intel-gfx] [PATCH 1/9] relay: remove unused buf_mapped and buf_unmapped callbacks

2020-11-23 Thread Jani Nikula 
No relay client uses the buf_mapped or buf_unmapped callbacks. Remove
them. This makes relay's vm_operations_struct close callback a dummy,
remove it as well.

Suggested-by: Christoph Hellwig 
Cc: Christoph Hellwig 
Signed-off-by: Jani Nikula 
---
 include/linux/relay.h | 19 ---
 kernel/relay.c| 34 --
 2 files changed, 53 deletions(-)

diff --git a/include/linux/relay.h b/include/linux/relay.h
index e13a333e7c37..b3c4f49f6951 100644
--- a/include/linux/relay.h
+++ b/include/linux/relay.h
@@ -101,25 +101,6 @@ struct rchan_callbacks
 void *prev_subbuf,
 size_t prev_padding);
 
-   /*
-* buf_mapped - relay buffer mmap notification
-* @buf: the channel buffer
-* @filp: relay file pointer
-*
-* Called when a relay file is successfully mmapped
-*/
-void (*buf_mapped)(struct rchan_buf *buf,
-  struct file *filp);
-
-   /*
-* buf_unmapped - relay buffer unmap notification
-* @buf: the channel buffer
-* @filp: relay file pointer
-*
-* Called when a relay file is successfully unmapped
-*/
-void (*buf_unmapped)(struct rchan_buf *buf,
-struct file *filp);
/*
 * create_buf_file - create file to represent a relay channel buffer
 * @filename: the name of the file to create
diff --git a/kernel/relay.c b/kernel/relay.c
index b08d936d5fa7..b51343642bf4 100644
--- a/kernel/relay.c
+++ b/kernel/relay.c
@@ -27,15 +27,6 @@
 static DEFINE_MUTEX(relay_channels_mutex);
 static LIST_HEAD(relay_channels);
 
-/*
- * close() vm_op implementation for relay file mapping.
- */
-static void relay_file_mmap_close(struct vm_area_struct *vma)
-{
-   struct rchan_buf *buf = vma->vm_private_data;
-   buf->chan->cb->buf_unmapped(buf, vma->vm_file);
-}
-
 /*
  * fault() vm_op implementation for relay file mapping.
  */
@@ -62,7 +53,6 @@ static vm_fault_t relay_buf_fault(struct vm_fault *vmf)
  */
 static const struct vm_operations_struct relay_file_mmap_ops = {
.fault = relay_buf_fault,
-   .close = relay_file_mmap_close,
 };
 
 /*
@@ -96,7 +86,6 @@ static void relay_free_page_array(struct page **array)
 static int relay_mmap_buf(struct rchan_buf *buf, struct vm_area_struct *vma)
 {
unsigned long length = vma->vm_end - vma->vm_start;
-   struct file *filp = vma->vm_file;
 
if (!buf)
return -EBADF;
@@ -107,7 +96,6 @@ static int relay_mmap_buf(struct rchan_buf *buf, struct 
vm_area_struct *vma)
vma->vm_ops = _file_mmap_ops;
vma->vm_flags |= VM_DONTEXPAND;
vma->vm_private_data = buf;
-   buf->chan->cb->buf_mapped(buf, filp);
 
return 0;
 }
@@ -283,22 +271,6 @@ static int subbuf_start_default_callback (struct rchan_buf 
*buf,
return 1;
 }
 
-/*
- * buf_mapped() default callback.  Does nothing.
- */
-static void buf_mapped_default_callback(struct rchan_buf *buf,
-   struct file *filp)
-{
-}
-
-/*
- * buf_unmapped() default callback.  Does nothing.
- */
-static void buf_unmapped_default_callback(struct rchan_buf *buf,
- struct file *filp)
-{
-}
-
 /*
  * create_buf_file_create() default callback.  Does nothing.
  */
@@ -322,8 +294,6 @@ static int remove_buf_file_default_callback(struct dentry 
*dentry)
 /* relay channel default callbacks */
 static struct rchan_callbacks default_channel_callbacks = {
.subbuf_start = subbuf_start_default_callback,
-   .buf_mapped = buf_mapped_default_callback,
-   .buf_unmapped = buf_unmapped_default_callback,
.create_buf_file = create_buf_file_default_callback,
.remove_buf_file = remove_buf_file_default_callback,
 };
@@ -509,10 +479,6 @@ static void setup_callbacks(struct rchan *chan,
 
if (!cb->subbuf_start)
cb->subbuf_start = subbuf_start_default_callback;
-   if (!cb->buf_mapped)
-   cb->buf_mapped = buf_mapped_default_callback;
-   if (!cb->buf_unmapped)
-   cb->buf_unmapped = buf_unmapped_default_callback;
if (!cb->create_buf_file)
cb->create_buf_file = create_buf_file_default_callback;
if (!cb->remove_buf_file)
-- 
2.20.1

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

[Intel-gfx] [PATCH 0/9] relay: cleanup and const callbacks, take 2

2020-11-23 Thread Jani Nikula 
This is v2 of [1], with a number of cleanups added first based on
Christoph's feedback, making the actual constness patch much smaller and
cleaner.

I don't know who actually maintains relay, it's not in MAINTAINERS -
Cc'd Andrew just in case.

I'd think it would be simplest to queue patches 5-9 via whichever tree
the relay patches get merged. They're all one-liners so neglible
conflict potential.

BR,
Jani.


[1] http://lore.kernel.org/r/20201118165320.26829-1-jani.nik...@intel.com


Cc: linux-bl...@vger.kernel.org
Cc: Jens Axboe 
Cc: ath...@lists.infradead.org
Cc: ath...@lists.infradead.org
Cc: Kalle Valo 
Cc: linux-wirel...@vger.kernel.org
Cc: QCA ath9k Development 
Cc: intel-gfx@lists.freedesktop.org
Cc: Christoph Hellwig 
Cc: Andrew Morton 


Jani Nikula (9):
  relay: remove unused buf_mapped and buf_unmapped callbacks
  relay: require non-NULL callbacks in relay_open()
  relay: make create_buf_file and remove_buf_file callbacks mandatory
  relay: allow the use of const callback structs
  drm/i915: make relay callbacks const
  ath10k: make relay callbacks const
  ath11k: make relay callbacks const
  ath9k: make relay callbacks const
  blktrace: make relay callbacks const

 drivers/gpu/drm/i915/gt/uc/intel_guc_log.c|   2 +-
 drivers/net/wireless/ath/ath10k/spectral.c|   2 +-
 drivers/net/wireless/ath/ath11k/spectral.c|   2 +-
 .../net/wireless/ath/ath9k/common-spectral.c  |   2 +-
 include/linux/relay.h |  29 ++---
 kernel/relay.c| 107 +++---
 kernel/trace/blktrace.c   |   2 +-
 7 files changed, 26 insertions(+), 120 deletions(-)

-- 
2.20.1

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Record the plane update times for debugging (rev2)

2020-11-23 Thread Patchwork 
== Series Details ==

Series: drm/i915/display: Record the plane update times for debugging (rev2)
URL   : https://patchwork.freedesktop.org/series/84174/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9376 -> Patchwork_18959


Summary
---

  **SUCCESS**

  No regressions found.

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

New tests
-

  New tests have been introduced between CI_DRM_9376 and Patchwork_18959:

### New CI tests (1) ###

  * boot:
- Statuses : 39 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Possible fixes 

  * igt@debugfs_test@read_all_entries:
- fi-tgl-y:   [DMESG-WARN][1] ([i915#402]) -> [PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/fi-tgl-y/igt@debugfs_test@read_all_entries.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18959/fi-tgl-y/igt@debugfs_test@read_all_entries.html

  * igt@gem_exec_suspend@basic-s0:
- fi-cfl-8109u:   [DMESG-WARN][3] ([i915#165] / [i915#262]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18959/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-y:   [DMESG-WARN][5] ([i915#1982]) -> [PASS][6] +2 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/fi-tgl-y/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18959/fi-tgl-y/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-bsw-n3050:   [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18959/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-kbl-soraka:  [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/fi-kbl-soraka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18959/fi-kbl-soraka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-apl-guc: [DMESG-WARN][11] ([i915#1635] / [i915#1982]) -> 
[PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/fi-apl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18959/fi-apl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2:  [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] +2 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18959/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html

  
 Warnings 

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

  
  [i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
  [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
  [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (45 -> 39)
--

  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-bwr-2160 fi-bsw-kefka 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9376 -> Patchwork_18959

  CI-20190529: 20190529
  CI_DRM_9376: d08ea807a6466f311fe921872bc18cfc384ae281 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5865: 76b7d1ecf6a3c0a5a538146bb055d0eb5fe232d0 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_18959: 38fb4e810247fd191cdd433426981245e7d3c5df @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

38fb4e810247 drm/i915/display: Record the plane update times for debugging

== Logs ==

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

Re: [Intel-gfx] [RFC] MAINTAINERS tag for cleanup robot

2020-11-23 Thread Tom Rix 


On 11/22/20 10:22 AM, Joe Perches wrote:
> On Sun, 2020-11-22 at 08:33 -0800, Tom Rix wrote:
>> On 11/21/20 9:10 AM, Joe Perches wrote:
>>> On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
 A difficult part of automating commits is composing the subsystem
 preamble in the commit log.  For the ongoing effort of a fixer producing
 one or two fixes a release the use of 'treewide:' does not seem 
 appropriate.

 It would be better if the normal prefix was used.  Unfortunately normal is
 not consistent across the tree.

 So I am looking for comments for adding a new tag to the MAINTAINERS file

D: Commit subsystem prefix

 ex/ for FPGA DFL DRIVERS

D: fpga: dfl:
>>> I'm all for it.  Good luck with the effort.  It's not completely trivial.
>>>
>>> From a decade ago:
>>>
>>> https://lore.kernel.org/lkml/1289919077.28741.50.camel@Joe-Laptop/
>>>
>>> (and that thread started with extra semicolon patches too)
>> Reading the history, how about this.
>>
>> get_maintainer.pl outputs a single prefix, if multiple files have the
>> same prefix it works, if they don't its an error.
>>
>> Another script 'commit_one_file.sh' does the call to get_mainainter.pl
>> to get the prefix and be called by run-clang-tools.py to get the fixer
>> specific message.
> It's not whether the script used is get_maintainer or any other script,
> the question is really if the MAINTAINERS file is the appropriate place
> to store per-subsystem patch specific prefixes.
>
> It is.
>
> Then the question should be how are the forms described and what is the
> inheritance priority.  My preference would be to have a default of
> inherit the parent base and add basename(subsystem dirname).
>
> Commit history seems to have standardized on using colons as the separator
> between the commit prefix and the subject.
>
> A good mechanism to explore how various subsystems have uses prefixes in
> the past might be something like:
>
> $ git log --no-merges --pretty='%s' -  | \
>   perl -n -e 'print substr($_, 0, rindex($_, ":") + 1) . "\n";' | \
>   sort | uniq -c | sort -rn

Thanks, I have shamelessly stolen this line and limited the commits to the 
maintainer.

I will post something once the generation of the prefixes is done.

Tom

___
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/display: Record the plane update times for debugging (rev2)

2020-11-23 Thread Patchwork 
== Series Details ==

Series: drm/i915/display: Record the plane update times for debugging (rev2)
URL   : https://patchwork.freedesktop.org/series/84174/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
38fb4e810247 drm/i915/display: Record the plane update times for debugging
-:64: WARNING:PREFER_SEQ_PUTS: Prefer seq_puts to seq_printf
#64: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:900:
+   seq_printf(m, "\t1us (log)  1ms\n");

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


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

Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread Joe Perches 
On Mon, 2020-11-23 at 07:58 -0800, James Bottomley wrote:
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129

https://www.wired.com/story/open-source-coders-few-tired/

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

It's unclear how to measure value in consistency.

But one way that costs can be reduced is by automation and _not_
involving maintainers when the patch itself is provably correct.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

The linux kernel has something like 1500 different maintainers listed
in the MAINTAINERS file.  That's not a trivial number.

$ git grep '^M:' MAINTAINERS | sort | uniq -c | wc -l
1543
$ git grep '^M:' MAINTAINERS| cut -f1 -d'<' | sort | uniq -c | wc -l
1446

I think the question you are asking is about trust and how it
effects development.

And back to that wired story, the actual number of what you might
be considering to be maintainers is likely less than 10% of the
listed numbers above.


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

Re: [Intel-gfx] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread James Bottomley 
On Mon, 2020-11-23 at 07:03 -0600, Gustavo A. R. Silva wrote:
> On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > > Please tell me our reward for all this effort isn't a
> > > > > > single missing error print.
> > > > > 
> > > > > There were quite literally dozens of logical defects found
> > > > > by the fallthrough additions.  Very few were logging only.
> > > > 
> > > > So can you give us the best examples (or indeed all of them if
> > > > someone is keeping score)?  hopefully this isn't a US election
> > > > situation ...
> > > 
> > > Gustavo?  Are you running for congress now?
> > > 
> > > https://lwn.net/Articles/794944/
> > 
> > That's 21 reported fixes of which about 50% seem to produce no
> > change in code behaviour at all, a quarter seem to have no user
> > visible effect with the remaining quarter producing unexpected
> > errors on obscure configuration parameters, which is why no-one
> > really noticed them before.
> 
> The really important point here is the number of bugs this has
> prevented and will prevent in the future. See an example of this,
> below:
> 
> https://lore.kernel.org/linux-iio/20190813135802.gb27...@kroah.com/

I think this falls into the same category as the other six bugs: it
changes the output/input for parameters but no-one has really noticed,
usually because the command is obscure or the bias effect is minor.

> This work is still relevant, even if the total number of issues/bugs
> we find in the process is zero (which is not the case).

Really, no ... something which produces no improvement has no value at
all ... we really shouldn't be wasting maintainer time with it because
it has a cost to merge.  I'm not sure we understand where the balance
lies in value vs cost to merge but I am confident in the zero value
case.

> "The sucky thing about doing hard work to deploy hardening is that
> the result is totally invisible by definition (things not happening)
> [..]"
> - Dmitry Vyukov

Really, no.  Something that can't be measured at all doesn't exist.

And actually hardening is one of those things you can measure (which I
do have to admit isn't true for everything in the security space) ...
it's number of exploitable bugs found before you did it vs number of
exploitable bugs found after you did it.  Usually hardening eliminates
a class of bug, so the way I've measured hardening before is to go
through the CVE list for the last couple of years for product X, find
all the bugs that are of the class we're looking to eliminate and say
if we had hardened X against this class of bug we'd have eliminated Y%
of the exploits.  It can be quite impressive if Y is a suitably big
number.

James


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

[Intel-gfx] [PATCH v2] drm/i915/display: Record the plane update times for debugging

2020-11-23 Thread Chris Wilson 
Since we try and estimate how long we require to update the registers to
perform a plane update, it is of vital importance that we measure the
distribution of plane updates to better guide our estimate. If we
underestimate how long it takes to perform the plane update, we may
slip into the next scanout frame causing a tear. If we overestimate, we
may unnecessarily delay the update to the next frame, causing visible
jitter.

Replace the warning that we exceed some arbitrary threshold for the
vblank update with a histogram for debugfs.

Signed-off-by: Chris Wilson 
Cc: Jani Nikula 
Cc: Ville Syrjälä 
---
 .../drm/i915/display/intel_display_debugfs.c  | 46 +++
 .../drm/i915/display/intel_display_types.h|  7 +++
 drivers/gpu/drm/i915/display/intel_sprite.c   | 29 +---
 3 files changed, 75 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index ca41e8c00ad7..d4bcf4971558 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -865,6 +865,50 @@ static void intel_scaler_info(struct seq_file *m, struct 
intel_crtc *crtc)
}
 }
 
+#ifdef CONFIG_DRM_I915_DEBUG_VBLANK_EVADE
+static void crtc_vblank_info(struct seq_file *m, struct intel_crtc *crtc)
+{
+   char buf[ARRAY_SIZE(crtc->debug.vbl_times) + 1] = {};
+   int h, row, max;
+   u64 count;
+
+   max = 0;
+   count = 0;
+   for (h = 0; h < ARRAY_SIZE(crtc->debug.vbl_times); h++) {
+   if (crtc->debug.vbl_times[h] > max)
+   max = crtc->debug.vbl_times[h];
+   count += crtc->debug.vbl_times[h];
+   }
+   seq_printf(m, "\tUpdates: %llu\n", count);
+   if (!count)
+   return;
+
+   memset(buf, '-', sizeof(buf) - 1);
+   seq_printf(m, "\t  |%s|\n", buf);
+
+   for (row = ilog2(max) - 1; row; row--) {
+   memset(buf, ' ', sizeof(buf) - 1);
+   for (h = 0; h < ARRAY_SIZE(crtc->debug.vbl_times); h++) {
+   if (ilog2(crtc->debug.vbl_times[h]) >= row)
+   buf[h] = '*';
+   }
+   seq_printf(m, "\t  |%s|\n", buf);
+   }
+
+   memset(buf, '-', sizeof(buf) - 1);
+   seq_printf(m, "\t  |%s|\n", buf);
+   seq_printf(m, "\t1us (log)  1ms\n");
+
+   seq_printf(m, "\tMin update: %lluns\n", crtc->debug.min_vbl_time);
+   seq_printf(m, "\tMax update: %lluns\n", crtc->debug.max_vbl_time);
+   seq_printf(m, "\tAverage update: %lluns\n",
+  div64_u64(crtc->debug.sum_vbl_time,  count));
+   seq_printf(m, "\tOverflows: %lu\n", crtc->debug.over_vbl_time);
+}
+#else
+static void crtc_vblank_info(struct seq_file *m, struct intel_crtc *crtc) {}
+#endif
+
 static void intel_crtc_info(struct seq_file *m, struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -907,6 +951,8 @@ static void intel_crtc_info(struct seq_file *m, struct 
intel_crtc *crtc)
seq_printf(m, "\tunderrun reporting: cpu=%s pch=%s\n",
   yesno(!crtc->cpu_fifo_underrun_disabled),
   yesno(!crtc->pch_fifo_underrun_disabled));
+
+   crtc_vblank_info(m, crtc);
 }
 
 static int i915_display_info(struct seq_file *m, void *unused)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ce82d654d0f2..efbb7c61e6fb 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1186,6 +1186,13 @@ struct intel_crtc {
ktime_t start_vbl_time;
int min_vbl, max_vbl;
int scanline_start;
+#ifdef CONFIG_DRM_I915_DEBUG_VBLANK_EVADE
+   u64 min_vbl_time;
+   u64 max_vbl_time;
+   u64 sum_vbl_time;
+   unsigned int vbl_times[21]; /* [1us, 1ms] */
+   unsigned long over_vbl_time;
+#endif
} debug;
 
/* scalers available on this crtc */
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c 
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 019a2d6d807a..661cbaf4cc38 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -250,13 +250,28 @@ void intel_pipe_update_end(struct intel_crtc_state 
*new_crtc_state)
crtc->debug.scanline_start, scanline_end);
}
 #ifdef CONFIG_DRM_I915_DEBUG_VBLANK_EVADE
-   else if (ktime_us_delta(end_vbl_time, crtc->debug.start_vbl_time) >
-VBLANK_EVASION_TIME_US)
-   drm_warn(_priv->drm,
-"Atomic update on pipe (%c) took %lld us, max time 
under evasion is %u us\n",
-pipe_name(pipe),
-ktime_us_delta(end_vbl_time,

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display: Record the plane update times for debugging

2020-11-23 Thread Patchwork 
== Series Details ==

Series: drm/i915/display: Record the plane update times for debugging
URL   : https://patchwork.freedesktop.org/series/84174/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9376 -> Patchwork_18958


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@core_hotunplug@unbind-rebind:
- fi-kbl-7500u:   [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/fi-kbl-7500u/igt@core_hotunp...@unbind-rebind.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18958/fi-kbl-7500u/igt@core_hotunp...@unbind-rebind.html

  
New tests
-

  New tests have been introduced between CI_DRM_9376 and Patchwork_18958:

### New CI tests (1) ###

  * boot:
- Statuses : 39 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0:
- fi-apl-guc: [PASS][3] -> [DMESG-WARN][4] ([i915#1635] / 
[i915#62]) +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/fi-apl-guc/igt@gem_exec_susp...@basic-s0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18958/fi-apl-guc/igt@gem_exec_susp...@basic-s0.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0:
- fi-cfl-8109u:   [DMESG-WARN][5] ([i915#165] / [i915#262]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18958/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-y:   [DMESG-WARN][7] ([i915#1982]) -> [PASS][8] +2 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/fi-tgl-y/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18958/fi-tgl-y/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-bsw-n3050:   [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18958/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-kbl-soraka:  [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/fi-kbl-soraka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18958/fi-kbl-soraka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-apl-guc: [DMESG-WARN][13] ([i915#1635] / [i915#1982]) -> 
[PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/fi-apl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18958/fi-apl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2:  [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] +2 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18958/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html

  
 Warnings 

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

  
  [i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
  [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
  [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262
  [i915#402]:

Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread Rafael J. Wysocki 
On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
 wrote:
>
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> >  wrote:

[cut]

> >
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Right.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.
>
> > If some company does not want to pay for that, that's fine, but they
> > don't get to be maintainers and claim `Supported`.
>
> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.
>
> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

Absolutely.

This is just one of the factors involved, but a significant one IMV.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC-v2 00/26] Introduce Intel PXP component

2020-11-23 Thread Jani Nikula 
On Fri, 20 Nov 2020, "Huang, Sean Z"  wrote:
> PXP is an i915 componment, that helps user space to establish the
> hardware protected session and manage the status of each alive
> software session, as well as the life cycle of each session.

I seem to have replied to an old version of the series; please see if
the comments I made are still valid.

BR,
Jani.

>
> This ioctl is to allow user space driver to create, set, and
> destroy each session. It also provides the communication chanel to
> TEE (Trusted Execution Environment) for the protected hardware
> session creation.
>
> Anshuman Gupta (1):
>   drm/i915/pxp: Add plane decryption support
>
> Bommu Krishnaiah (2):
>   drm/i915/uapi: introduce drm_i915_gem_create_ext
>   drm/i915/pxp: User interface for Protected buffer
>
> Huang, Sean Z (22):
>   drm/i915/pxp: Introduce Intel PXP component
>   drm/i915/pxp: Enable PXP irq worker and callback stub
>   drm/i915/pxp: Add PXP context for logical hardware states.
>   drm/i915/pxp: set KCR reg init during the boot time
>   drm/i915/pxp: Implement ioctl action to set the user space context
>   drm/i915/pxp: Add PXP-related registers into allowlist
>   drm/i915/pxp: Read register to check hardware session state
>   drm/i915/pxp: Implement funcs to get/set PXP tag
>   drm/i915/pxp: Implement ioctl action to reserve session slot
>   drm/i915/pxp: Implement ioctl action to set session in play
>   drm/i915/pxp: Func to send hardware session termination
>   drm/i915/pxp: Implement ioctl action to terminate the session
>   drm/i915/pxp: Enable ioctl action to query PXP tag
>   drm/i915/pxp: Destroy all type0 sessions upon teardown
>   drm/i915/pxp: Termiante the session upon app crash
>   drm/i915/pxp: Enable PXP power management
>   drm/i915/pxp: Implement funcs to create the TEE channel
>   drm/i915/pxp: Implement ioctl action to send TEE commands
>   drm/i915/pxp: Create the arbitrary session after boot
>   drm/i915/pxp: Add i915 trace logs for PXP operations
>   drm/i915/pxp: Expose session state for display protection flip
>   drm/i915/pxp: Enable the PXP ioctl for protected session
>
> Vitaly Lubart (1):
>   mei: pxp: export pavp client to me client bus
>
>  drivers/gpu/drm/i915/Makefile |8 +
>  drivers/gpu/drm/i915/display/intel_sprite.c   |   21 +-
>  drivers/gpu/drm/i915/gem/i915_gem_context.c   |   15 +-
>  drivers/gpu/drm/i915/gem/i915_gem_context.h   |   10 +
>  .../gpu/drm/i915/gem/i915_gem_context_types.h |2 +-
>  .../gpu/drm/i915/gem/i915_gem_object_types.h  |5 +
>  drivers/gpu/drm/i915/gt/intel_gt_irq.c|4 +
>  drivers/gpu/drm/i915/i915_drv.c   |   18 +-
>  drivers/gpu/drm/i915/i915_drv.h   |   10 +
>  drivers/gpu/drm/i915/i915_gem.c   |   63 +-
>  drivers/gpu/drm/i915/i915_reg.h   |8 +
>  drivers/gpu/drm/i915/i915_trace.h |   44 +
>  drivers/gpu/drm/i915/intel_uncore.c   |   50 +-
>  drivers/gpu/drm/i915/pxp/intel_pxp.c  |  322 +
>  drivers/gpu/drm/i915/pxp/intel_pxp.h  |   73 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_context.c  |   69 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_context.h  |   47 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_pm.c   |   72 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_pm.h   |   16 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_sm.c   | 1180 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_sm.h   |  126 ++
>  drivers/gpu/drm/i915/pxp/intel_pxp_tee.c  |  216 +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_tee.h  |   25 +
>  drivers/misc/mei/Kconfig  |2 +
>  drivers/misc/mei/Makefile |1 +
>  drivers/misc/mei/pxp/Kconfig  |   13 +
>  drivers/misc/mei/pxp/Makefile |7 +
>  drivers/misc/mei/pxp/mei_pxp.c|  230 
>  drivers/misc/mei/pxp/mei_pxp.h|   18 +
>  include/drm/i915_component.h  |1 +
>  include/drm/i915_pxp_tee_interface.h  |   45 +
>  include/uapi/drm/i915_drm.h   |  141 ++
>  32 files changed, 2836 insertions(+), 26 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.h
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_context.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_context.h
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_sm.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_sm.h
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.h
>  create mode 100644 drivers/misc/mei/pxp/Kconfig
>  create mode 100644 drivers/misc/mei/pxp/Makefile
>  create mode 100644 drivers/misc/mei/pxp/mei_pxp.c
>  create mode 100644 drivers/misc/mei/pxp/mei_pxp.h
>  create mode 100644

Re: [Intel-gfx] Does the intel driver support faking a connected monitor?

2020-11-23 Thread Jani Nikula 
On Sat, 21 Nov 2020, Paul Gardiner  wrote:
> On 17/11/2020 14:52, Jani Nikula wrote:
>> On Thu, 29 Oct 2020, Paul Gardiner  wrote:
>>> I use an open source DVR called MythTV. I've just swapped from using
>>> nvidia graphics to intel graphics. Generally it's working great, but
>>> I've run into one thing I used to do with the old system that I cannot
>>> find out how to achieve with the new.
>>>
>>> MythTV doesn't currently entirely handle starting without a TV
>>> connected. With nvidia graphics I could specify, within the X config,
>>> the "ConnectMonitor" and "CustomEDID" options to fool MythTV into
>>> thinking there was a TV. With intel graphics I can load EDID, but so far
>>> I haven't discovered an equivalent of the "ConnectedMonitor" option.
>> 
>> Sorry for the delay, I seem to have missed this.
>> 
>> Please try a kernel command-line parameter to force enable the
>> connector.
>> 
>> video=TV-1:e
>> 
>> Assuming the connector name is "TV-1"; replace with whatever you have.
>
>
> Thanks for the reply. I gave that a try, in my case "video=HDMI1:e", but 
> saw no difference. That's KMS, right? Is there anything I might have 
> failed to install or enable that KMS relies on? Are there any logs I 
> should monitor?

I think it should probably be HDMI-1 with the hyphen; is that a typo
above or in the command line you used?

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] [RFC] MAINTAINERS tag for cleanup robot

2020-11-23 Thread Lukas Bulwahn 
On Mon, Nov 23, 2020 at 4:52 PM Jani Nikula  wrote:
>
> On Sat, 21 Nov 2020, James Bottomley  
> wrote:
> > On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
> >> A difficult part of automating commits is composing the subsystem
> >> preamble in the commit log.  For the ongoing effort of a fixer
> >> producing
> >> one or two fixes a release the use of 'treewide:' does not seem
> >> appropriate.
> >>
> >> It would be better if the normal prefix was used.  Unfortunately
> >> normal is
> >> not consistent across the tree.
> >>
> >>
> >>  D: Commit subsystem prefix
> >>
> >> ex/ for FPGA DFL DRIVERS
> >>
> >>  D: fpga: dfl:
> >>
> >
> > I've got to bet this is going to cause more issues than it solves.
>
> Agreed.
>

Tom, this a problem only kernel janitors encounter; all other
developers really do not have that issue. The time spent on creating
the patch is much larger than the amount saved if the commit log
header line prefix would be derived automatically. I believe Julia
Lawall, Arnd Bergmann and Nathan Chancellor as long-term
high-frequency janitors do have already scripted approaches to that
issue. Maybe they simply need to share these scripts with you and you
consolidate them and share with everyone?

Also, making clean-up patches cumbersome has a positive side as well;
maintainers are not swamped with fully automated patch submissions.
There have been some bad experiences with some submitters on that in
the past...

> > SCSI uses scsi: : for drivers but not every driver has a
> > MAINTAINERS entry.  We use either scsi: or scsi: core: for mid layer
> > things, but we're not consistent.  Block uses blk-: for all
> > of it's stuff but almost no s have a MAINTAINERS entry.  So
> > the next thing you're going to cause is an explosion of suggested
> > MAINTAINERs entries.
>
> On the one hand, adoption of new MAINTAINERS entries has been really
> slow. Look at B, C, or P, for instance. On the other hand, if this were
> to get adopted, you'll potentially get conflicting prefixes for patches
> touching multiple files. Then what?
>
> I'm guessing a script looking at git log could come up with better
> suggestions for prefixes via popularity contest than manually maintained
> MAINTAINERS entries. It might not always get it right, but then human
> outsiders aren't going to always get it right either.
>
> Now you'll only need Someone(tm) to write the script. ;)
>
> Something quick like this:
>
> git log --since={1year} --pretty=format:%s --  |\
> grep -v "^\(Merge\|Revert\)" |\
> sed 's/:[^:]*$//' |\
> sort | uniq -c | sort -rn | head -5
>
> already gives me results that really aren't worse than some of the
> prefixes invented by drive-by contributors.
>

I agree I do not see the need to introduce something in MAINTAINERS;
from my observations maintaining MAINTAINERS, there is sufficient work
on adoption and maintenance of the existing entries already without
such an yet another additional entry. Some entries are outdated or
wrong and the janitor task of cleaning those up is already enough work
for involved janitors and enough churn for involved maintainers. So a
machine-learned approach as above is probably good enough, but if you
think you need more complex rules try to learn them from the data at
hand... certainly a nice task to do with machine learning on commit
message prefixes.

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

Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread James Bottomley 
On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
>  wrote:
> > Well, it seems to be three years of someone's time plus the
> > maintainer review time and series disruption of nearly a thousand
> > patches.  Let's be conservative and assume the producer worked
> > about 30% on the series and it takes about 5-10 minutes per patch
> > to review, merge and for others to rework existing series.  So
> > let's say it's cost a person year of a relatively junior engineer
> > producing the patches and say 100h of review and application
> > time.  The latter is likely the big ticket item because it's what
> > we have in least supply in the kernel (even though it's 20x vs the
> > producer time).
> 
> How are you arriving at such numbers? It is a total of ~200 trivial
> lines.

Well, I used git.  It says that as of today in Linus' tree we have 889
patches related to fall throughs and the first series went in in
october 2017 ... ignoring a couple of outliers back to February.

> > It's not about the risk of the changes it's about the cost of
> > implementing them.  Even if you discount the producer time (which
> > someone gets to pay for, and if I were the engineering manager, I'd
> > be unhappy about), the review/merge/rework time is pretty
> > significant in exchange for six minor bug fixes.  Fine, when a new
> > compiler warning comes along it's certainly reasonable to see if we
> > can benefit from it and the fact that the compiler people think
> > it's worthwhile is enough evidence to assume this initially.  But
> > at some point you have to ask whether that assumption is supported
> > by the evidence we've accumulated over the time we've been using
> > it.  And if the evidence doesn't support it perhaps it is time to
> > stop the experiment.
> 
> Maintainers routinely review 1-line trivial patches, not to mention
> internal API changes, etc.

We're also complaining about the inability to recruit maintainers:

https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/

And burn out:

http://antirez.com/news/129

The whole crux of your argument seems to be maintainers' time isn't
important so we should accept all trivial patches ... I'm pushing back
on that assumption in two places, firstly the valulessness of the time
and secondly that all trivial patches are valuable.

> If some company does not want to pay for that, that's fine, but they
> don't get to be maintainers and claim `Supported`.

What I'm actually trying to articulate is a way of measuring value of
the patch vs cost ... it has nothing really to do with who foots the
actual bill.

One thesis I'm actually starting to formulate is that this continual
devaluing of maintainers is why we have so much difficulty keeping and
recruiting them.

James



___
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/display: Record the plane update times for debugging

2020-11-23 Thread Patchwork 
== Series Details ==

Series: drm/i915/display: Record the plane update times for debugging
URL   : https://patchwork.freedesktop.org/series/84174/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
b17790555707 drm/i915/display: Record the plane update times for debugging
-:65: WARNING:PREFER_SEQ_PUTS: Prefer seq_puts to seq_printf
#65: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:901:
+   seq_printf(m, "\t1us (log) 1ms\n");

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


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

Re: [Intel-gfx] [RFC] MAINTAINERS tag for cleanup robot

2020-11-23 Thread Jani Nikula 
On Sat, 21 Nov 2020, James Bottomley  
wrote:
> On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
>> A difficult part of automating commits is composing the subsystem
>> preamble in the commit log.  For the ongoing effort of a fixer
>> producing
>> one or two fixes a release the use of 'treewide:' does not seem
>> appropriate.
>> 
>> It would be better if the normal prefix was used.  Unfortunately
>> normal is
>> not consistent across the tree.
>> 
>> 
>>  D: Commit subsystem prefix
>> 
>> ex/ for FPGA DFL DRIVERS
>> 
>>  D: fpga: dfl:
>> 
>
> I've got to bet this is going to cause more issues than it solves.

Agreed.

> SCSI uses scsi: : for drivers but not every driver has a
> MAINTAINERS entry.  We use either scsi: or scsi: core: for mid layer
> things, but we're not consistent.  Block uses blk-: for all
> of it's stuff but almost no s have a MAINTAINERS entry.  So
> the next thing you're going to cause is an explosion of suggested
> MAINTAINERs entries.

On the one hand, adoption of new MAINTAINERS entries has been really
slow. Look at B, C, or P, for instance. On the other hand, if this were
to get adopted, you'll potentially get conflicting prefixes for patches
touching multiple files. Then what?

I'm guessing a script looking at git log could come up with better
suggestions for prefixes via popularity contest than manually maintained
MAINTAINERS entries. It might not always get it right, but then human
outsiders aren't going to always get it right either.

Now you'll only need Someone(tm) to write the script. ;)

Something quick like this:

git log --since={1year} --pretty=format:%s --  |\
grep -v "^\(Merge\|Revert\)" |\
sed 's/:[^:]*$//' |\
sort | uniq -c | sort -rn | head -5

already gives me results that really aren't worse than some of the
prefixes invented by drive-by contributors.

> Has anyone actually complained about treewide:?

As Joe said, I'd feel silly applying patches to drivers with that
prefix. If it gets applied by someone else higher up, literally
treewide, then no complaints.

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.IGT: success for series starting with [CI,1/4] drm/i915/gt: Defer enabling the breadcrumb interrupt to after submission

2020-11-23 Thread Patchwork 
== Series Details ==

Series: series starting with [CI,1/4] drm/i915/gt: Defer enabling the 
breadcrumb interrupt to after submission
URL   : https://patchwork.freedesktop.org/series/84165/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9376_full -> Patchwork_18957_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * {igt@kms_flip_tiling@flip-to-x-tiled@edp-1-pipe-c}:
- shard-skl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/shard-skl4/igt@kms_flip_tiling@flip-to-x-ti...@edp-1-pipe-c.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18957/shard-skl1/igt@kms_flip_tiling@flip-to-x-ti...@edp-1-pipe-c.html

  
New tests
-

  New tests have been introduced between CI_DRM_9376_full and 
Patchwork_18957_full:

### New CI tests (1) ###

  * boot:
- Statuses : 200 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_whisper@basic-contexts-priority-all:
- shard-glk:  [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/shard-glk8/igt@gem_exec_whis...@basic-contexts-priority-all.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18957/shard-glk2/igt@gem_exec_whis...@basic-contexts-priority-all.html

  * igt@kms_big_fb@y-tiled-16bpp-rotate-0:
- shard-glk:  [PASS][5] -> [FAIL][6] ([i915#1119])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/shard-glk4/igt@kms_big...@y-tiled-16bpp-rotate-0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18957/shard-glk5/igt@kms_big...@y-tiled-16bpp-rotate-0.html

  * igt@kms_cursor_crc@pipe-c-cursor-64x64-sliding:
- shard-skl:  [PASS][7] -> [FAIL][8] ([i915#54]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/shard-skl9/igt@kms_cursor_...@pipe-c-cursor-64x64-sliding.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18957/shard-skl7/igt@kms_cursor_...@pipe-c-cursor-64x64-sliding.html

  * igt@kms_cursor_edge_walk@pipe-b-128x128-bottom-edge:
- shard-glk:  [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +1 
similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/shard-glk2/igt@kms_cursor_edge_w...@pipe-b-128x128-bottom-edge.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18957/shard-glk7/igt@kms_cursor_edge_w...@pipe-b-128x128-bottom-edge.html

  * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic:
- shard-hsw:  [PASS][11] -> [FAIL][12] ([i915#96])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/shard-hsw2/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18957/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html

  * igt@kms_cursor_legacy@flip-vs-cursor-crc-atomic:
- shard-kbl:  [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/shard-kbl6/igt@kms_cursor_leg...@flip-vs-cursor-crc-atomic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18957/shard-kbl3/igt@kms_cursor_leg...@flip-vs-cursor-crc-atomic.html

  * igt@kms_cursor_legacy@flip-vs-cursor-toggle:
- shard-tglb: [PASS][15] -> [FAIL][16] ([i915#2346])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/shard-tglb3/igt@kms_cursor_leg...@flip-vs-cursor-toggle.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18957/shard-tglb2/igt@kms_cursor_leg...@flip-vs-cursor-toggle.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1:
- shard-skl:  [PASS][17] -> [FAIL][18] ([i915#79]) +1 similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/shard-skl9/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18957/shard-skl7/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html
- shard-tglb: [PASS][19] -> [FAIL][20] ([i915#2598])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/shard-tglb1/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18957/shard-tglb5/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html

  * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-gtt:
- shard-skl:  [PASS][21] -> [DMESG-WARN][22]

Re: [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [PXP,CLEAN,v06,01/27] drm/i915/pxp: Introduce Intel PXP component

2020-11-23 Thread Jani Nikula 
On Sat, 14 Nov 2020, Patchwork  wrote:
> == Series Details ==
>
> Series: series starting with [PXP,CLEAN,v06,01/27] drm/i915/pxp: Introduce 
> Intel PXP component
> URL   : https://patchwork.freedesktop.org/series/83843/
> State : failure
>
> == Summary ==
>
> CALLscripts/checksyscalls.sh
>   CALLscripts/atomic/check-atomics.sh
>   DESCEND  objtool
>   CHK include/generated/compile.h
>   HDRTEST drivers/gpu/drm/i915/pxp/intel_pxp_context.h
> In file included from :
> ./drivers/gpu/drm/i915/pxp/intel_pxp_context.h:14:15: error: field 
> ‘ctx_mutex’ has incomplete type
>   struct mutex ctx_mutex;
>^
> ./drivers/gpu/drm/i915/pxp/intel_pxp_context.h:21:28: error: 
> ‘MAX_TYPE0_SESSIONS’ undeclared here (not in a function)
>   u32 type0_session_pxp_tag[MAX_TYPE0_SESSIONS];
> ^~
> ./drivers/gpu/drm/i915/pxp/intel_pxp_context.h:22:28: error: 
> ‘MAX_TYPE1_SESSIONS’ undeclared here (not in a function)
>   u32 type1_session_pxp_tag[MAX_TYPE1_SESSIONS];
> ^~
> ./drivers/gpu/drm/i915/pxp/intel_pxp_context.h:39:51: error: ‘struct 
> drm_i915_private’ declared inside parameter list will not be visible outside 
> of this definition or declaration [-Werror]
>  struct pxp_context *intel_pxp_create_r0ctx(struct drm_i915_private *i915);
>^~~~
> ./drivers/gpu/drm/i915/pxp/intel_pxp_context.h:40:37: error: ‘struct 
> drm_i915_private’ declared inside parameter list will not be visible outside 
> of this definition or declaration [-Werror]
>  void intel_pxp_destroy_r0ctx(struct drm_i915_private *i915);
>  ^~~~
> ./drivers/gpu/drm/i915/pxp/intel_pxp_context.h:42:32: error: ‘struct 
> drm_i915_private’ declared inside parameter list will not be visible outside 
> of this definition or declaration [-Werror]
>  int intel_pxp_set_r3ctx(struct drm_i915_private *i915, u32 r3ctx);
> ^~~~
> ./drivers/gpu/drm/i915/pxp/intel_pxp_context.h:43:42: error: ‘struct 
> drm_i915_private’ declared inside parameter list will not be visible outside 
> of this definition or declaration [-Werror]
>  void intel_pxp_destroy_r3ctx_list(struct drm_i915_private *i915);
>   ^~~~
> cc1: all warnings being treated as errors
> drivers/gpu/drm/i915/Makefile:312: recipe for target 
> 'drivers/gpu/drm/i915/pxp/intel_pxp_context.hdrtest' failed
> make[4]: *** [drivers/gpu/drm/i915/pxp/intel_pxp_context.hdrtest] Error 1
> scripts/Makefile.build:500: recipe for target 'drivers/gpu/drm/i915' failed
> make[3]: *** [drivers/gpu/drm/i915] Error 2
> scripts/Makefile.build:500: recipe for target 'drivers/gpu/drm' failed
> make[2]: *** [drivers/gpu/drm] Error 2
> scripts/Makefile.build:500: recipe for target 'drivers/gpu' failed
> make[1]: *** [drivers/gpu] Error 2
> Makefile:1799: recipe for target 'drivers' failed
> make: *** [drivers] Error 2

Please enable DRM_I915_WERROR=y locally, and fix this stuff.

BR,
Jani.


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

-- 
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] [PXP CLEAN PATCH v06 17/27] drm/i915/pxp: Enable PXP power management

2020-11-23 Thread Jani Nikula 
On Fri, 13 Nov 2020, Sean Z Huang  wrote:
> From: "Huang, Sean Z" 
>
> During the power event S3+ sleep/resume, hardware will lose all the
> encryption keys for every hardware session, even though the
> software session state was marked as alive after resume. So to
> handle such case, ring0 PXP should terminate all the hardware
> sessions and cleanup all the software states after the power cycle.
>
> Signed-off-by: Huang, Sean Z 
> ---
>  drivers/gpu/drm/i915/Makefile   |  3 +-
>  drivers/gpu/drm/i915/i915_drv.c |  8 +++
>  drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 83 +
>  drivers/gpu/drm/i915/pxp/intel_pxp_pm.h | 14 +
>  4 files changed, 107 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
>  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 81432a9f44d6..6858392c1ef2 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -258,7 +258,8 @@ i915-y += i915_perf.o
>  i915-y += \
>   pxp/intel_pxp.o \
>   pxp/intel_pxp_context.o \
> - pxp/intel_pxp_sm.o
> + pxp/intel_pxp_sm.o \
> + pxp/intel_pxp_pm.o

Alphabetical order, please.

>  
>  # Post-mortem debug and GPU hang state capture
>  i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index e61ffce52e3e..830708414f92 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -68,6 +68,8 @@
>  #include "gt/intel_gt_pm.h"
>  #include "gt/intel_rc6.h"
>  
> +#include "pxp/intel_pxp_pm.h"
> +
>  #include "i915_debugfs.h"
>  #include "i915_drv.h"
>  #include "i915_ioc32.h"
> @@ -1094,6 +1096,8 @@ static int i915_drm_prepare(struct drm_device *dev)
>*/
>   i915_gem_suspend(i915);
>  
> + intel_pxp_pm_prepare_suspend(i915);
> +
>   return 0;
>  }
>  
> @@ -1277,6 +1281,8 @@ static int i915_drm_resume(struct drm_device *dev)
>  
>   intel_power_domains_enable(dev_priv);
>  
> + intel_pxp_pm_resume(dev_priv);
> +
>   enable_rpm_wakeref_asserts(_priv->runtime_pm);
>  
>   return 0;
> @@ -1348,6 +1354,8 @@ static int i915_drm_resume_early(struct drm_device *dev)
>  
>   intel_power_domains_resume(dev_priv);
>  
> + intel_pxp_pm_resume_early(dev_priv);
> +
>   enable_rpm_wakeref_asserts(_priv->runtime_pm);
>  
>   return ret;
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c 
> b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> new file mode 100644
> index ..18d33efca9d9
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> @@ -0,0 +1,83 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright(c) 2020 Intel Corporation.
> + */
> +
> +#include "i915_drv.h"
> +#include "intel_pxp_context.h"
> +#include "intel_pxp_sm.h"
> +#include "intel_pxp_pm.h"
> +
> +void intel_pxp_pm_prepare_suspend(struct drm_i915_private *i915)
> +{
> + drm_dbg(>drm, ">>> %s\n", __func__);
> +
> + if (!i915->pxp.r0ctx)
> + return;
> +
> + mutex_lock(>pxp.r0ctx->ctx_mutex);
> +
> + /* Disable PXP-IOCTLs */
> + i915->pxp.r0ctx->global_state_in_suspend = true;
> +
> + mutex_unlock(>pxp.r0ctx->ctx_mutex);
> +
> + drm_dbg(>drm, "<<< %s\n", __func__);
> +}
> +
> +void intel_pxp_pm_resume_early(struct drm_i915_private *i915)
> +{
> + drm_dbg(>drm, ">>> %s\n", __func__);
> +
> + if (!i915->pxp.r0ctx)
> + return;
> +
> + mutex_lock(>pxp.r0ctx->ctx_mutex);
> +
> + if (i915->pxp.r0ctx->global_state_in_suspend) {
> + /* reset the attacked flag even there was a pending */
> + i915->pxp.r0ctx->global_state_attacked = false;
> +
> + i915->pxp.r0ctx->flag_display_hm_surface_keys = false;
> + }
> +
> + mutex_unlock(>pxp.r0ctx->ctx_mutex);
> + drm_dbg(>drm, "<<< %s\n", __func__);
> +}
> +
> +int intel_pxp_pm_resume(struct drm_i915_private *i915)
> +{
> + int ret = 0;
> +
> + drm_dbg(>drm, ">>> %s\n", __func__);
> +
> + if (!i915->pxp.r0ctx)
> + return 0;
> +
> + mutex_lock(>pxp.r0ctx->ctx_mutex);
> +
> + /* Re-enable PXP-IOCTLs */
> + if (i915->pxp.r0ctx->global_state_in_suspend) {
> + intel_pxp_destroy_r3ctx_list(i915);
> +
> + ret = intel_pxp_sm_terminate_all_active_sessions(i915, 
> SESSION_TYPE_TYPE0);
> + if (ret) {
> + drm_dbg(>drm, "Failed to 
> intel_pxp_sm_terminate_all_active_sessions with type0\n");
> + goto end;
> + }
> +
> + ret = intel_pxp_sm_terminate_all_active_sessions(i915, 
> SESSION_TYPE_TYPE1);
> + if (ret) {
> + drm_dbg(>drm, "Failed to 
> intel_pxp_sm_terminate_all_active_sessions with type1\n");
> + goto end;
> + }
> +
> +

Re: [Intel-gfx] [PXP CLEAN PATCH v06 07/27] drm/i915/pxp: Add PXP-related registers into allowlist

2020-11-23 Thread Jani Nikula 
On Fri, 13 Nov 2020, Sean Z Huang  wrote:
> From: "Huang, Sean Z" 
>
> Add several PXP-related reg into allowlist to allow
> ring3 driver to read the those register values.
>
> Signed-off-by: Huang, Sean Z 
> ---
>  drivers/gpu/drm/i915/i915_reg.h |  8 
>  drivers/gpu/drm/i915/intel_uncore.c | 57 +
>  2 files changed, 50 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index faf6b06145fa..5c51c9df8b28 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -12419,4 +12419,12 @@ enum skl_power_gate {
>  #define TGL_ROOT_DEVICE_SKU_ULX  0x2
>  #define TGL_ROOT_DEVICE_SKU_ULT  0x4
>  
> +/* Registers for passlist check */

allowlist

> +#define PXP_REG_01_LOWERBOUND_MMIO(0x32260)
> +#define PXP_REG_01_UPPERBOUND_MMIO(0x32268)
> +#define PXP_REG_02_LOWERBOUND_MMIO(0x32670)
> +#define PXP_REG_02_UPPERBOUND_MMIO(0x32678)
> +#define PXP_REG_03_LOWERBOUND_MMIO(0x32860)
> +#define PXP_REG_03_UPPERBOUND_MMIO(0x32c7c)
> +
>  #endif /* _I915_REG_H_ */
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index c9ef0025c60e..670856e095c4 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1990,16 +1990,41 @@ void intel_uncore_fini_mmio(struct intel_uncore 
> *uncore)
>  }
>  
>  static const struct reg_allowlist {
> - i915_reg_t offset_ldw;
> + i915_reg_t offset_ldw_lowerbound;
> + i915_reg_t offset_ldw_upperbound;
>   i915_reg_t offset_udw;
>   u16 gen_mask;
>   u8 size;
> -} reg_read_allowlist[] = { {
> - .offset_ldw = RING_TIMESTAMP(RENDER_RING_BASE),
> +} reg_read_allowlist[] = {
> + {
> + .offset_ldw_lowerbound = RING_TIMESTAMP(RENDER_RING_BASE),
> + .offset_ldw_upperbound = RING_TIMESTAMP(RENDER_RING_BASE),
>   .offset_udw = RING_TIMESTAMP_UDW(RENDER_RING_BASE),
>   .gen_mask = INTEL_GEN_MASK(4, 12),
>   .size = 8
> -} };
> + },
> + {
> + .offset_ldw_lowerbound = PXP_REG_01_LOWERBOUND,
> + .offset_ldw_upperbound = PXP_REG_01_UPPERBOUND,
> + .offset_udw = {0},
> + .gen_mask = INTEL_GEN_MASK(4, 12),
> + .size = 4
> + },
> + {
> + .offset_ldw_lowerbound = PXP_REG_02_LOWERBOUND,
> + .offset_ldw_upperbound = PXP_REG_02_UPPERBOUND,
> + .offset_udw = {0},
> + .gen_mask = INTEL_GEN_MASK(4, 12),
> + .size = 4
> + },
> + {
> + .offset_ldw_lowerbound = PXP_REG_03_LOWERBOUND,
> + .offset_ldw_upperbound = PXP_REG_03_UPPERBOUND,
> + .offset_udw = {0},
> + .gen_mask = INTEL_GEN_MASK(4, 12),
> + .size = 4
> + }
> +};
>  
>  int i915_reg_read_ioctl(struct drm_device *dev,
>   void *data, struct drm_file *file)
> @@ -2012,18 +2037,22 @@ int i915_reg_read_ioctl(struct drm_device *dev,
>   unsigned int flags;
>   int remain;
>   int ret = 0;
> + i915_reg_t offset_ldw;
>  
>   entry = reg_read_allowlist;
>   remain = ARRAY_SIZE(reg_read_allowlist);
>   while (remain) {
> - u32 entry_offset = i915_mmio_reg_offset(entry->offset_ldw);
> + u32 entry_offset_lb = 
> i915_mmio_reg_offset(entry->offset_ldw_lowerbound);
> + u32 entry_offset_ub = 
> i915_mmio_reg_offset(entry->offset_ldw_upperbound);
>  
>   GEM_BUG_ON(!is_power_of_2(entry->size));
>   GEM_BUG_ON(entry->size > 8);
> - GEM_BUG_ON(entry_offset & (entry->size - 1));
> + GEM_BUG_ON(entry_offset_lb & (entry->size - 1));
> + GEM_BUG_ON(entry_offset_ub & (entry->size - 1));
>  
>   if (INTEL_INFO(i915)->gen_mask & entry->gen_mask &&
> - entry_offset == (reg->offset & -entry->size))
> + entry_offset_lb <= (reg->offset & -entry->size) &&
> + (reg->offset & -entry->size) <= entry_offset_ub)
>   break;
>   entry++;
>   remain--;
> @@ -2033,23 +2062,21 @@ int i915_reg_read_ioctl(struct drm_device *dev,
>   return -EINVAL;
>  
>   flags = reg->offset & (entry->size - 1);
> + offset_ldw = _MMIO(reg->offset - flags);
>  
>   with_intel_runtime_pm(>runtime_pm, wakeref) {
>   if (entry->size == 8 && flags == I915_REG_READ_8B_WA)
>   reg->val = intel_uncore_read64_2x32(uncore,
> - entry->offset_ldw,
> + offset_ldw,
>   entry->offset_udw);
>   else if (entry->size == 8 && flags == 0)
> - reg->val = intel_uncore_read64(uncore,
> -entry->offset_ldw);
> +

Re: [Intel-gfx] [PXP CLEAN PATCH v06 06/27] drm/i915: Rename the whitelist to allowlist

2020-11-23 Thread Jani Nikula 
On Fri, 13 Nov 2020, Sean Z Huang  wrote:
> From: "Huang, Sean Z" 
>
> Rename the whitelist to allowlist as suggested

Please post this separately and we can merge this while the rest of the
series is still being reviewed.

BR,
Jani.

>
> Signed-off-by: Huang, Sean Z 
> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 1c14a07eba7d..c9ef0025c60e 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1989,12 +1989,12 @@ void intel_uncore_fini_mmio(struct intel_uncore 
> *uncore)
>   uncore_mmio_cleanup(uncore);
>  }
>  
> -static const struct reg_whitelist {
> +static const struct reg_allowlist {
>   i915_reg_t offset_ldw;
>   i915_reg_t offset_udw;
>   u16 gen_mask;
>   u8 size;
> -} reg_read_whitelist[] = { {
> +} reg_read_allowlist[] = { {
>   .offset_ldw = RING_TIMESTAMP(RENDER_RING_BASE),
>   .offset_udw = RING_TIMESTAMP_UDW(RENDER_RING_BASE),
>   .gen_mask = INTEL_GEN_MASK(4, 12),
> @@ -2007,14 +2007,14 @@ int i915_reg_read_ioctl(struct drm_device *dev,
>   struct drm_i915_private *i915 = to_i915(dev);
>   struct intel_uncore *uncore = >uncore;
>   struct drm_i915_reg_read *reg = data;
> - struct reg_whitelist const *entry;
> + struct reg_allowlist const *entry;
>   intel_wakeref_t wakeref;
>   unsigned int flags;
>   int remain;
>   int ret = 0;
>  
> - entry = reg_read_whitelist;
> - remain = ARRAY_SIZE(reg_read_whitelist);
> + entry = reg_read_allowlist;
> + remain = ARRAY_SIZE(reg_read_allowlist);
>   while (remain) {
>   u32 entry_offset = i915_mmio_reg_offset(entry->offset_ldw);

-- 
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] [PXP CLEAN PATCH v06 02/27] drm/i915/pxp: Enable PXP irq worker and callback stub

2020-11-23 Thread Jani Nikula 
On Mon, 16 Nov 2020, "Souza, Jose"  wrote:
> On Fri, 2020-11-13 at 16:36 -0800, Sean Z Huang wrote:
>> From: "Huang, Sean Z" 
>> 
>> Create the irq worker that serves as callback handler, those
>> callback stubs should be called while the hardware key teardown
>> occurs.
>> 
>> Signed-off-by: Huang, Sean Z 
>> ---
>>  drivers/gpu/drm/i915/gt/intel_gt_irq.c |  4 ++
>>  drivers/gpu/drm/i915/i915_reg.h|  1 +
>>  drivers/gpu/drm/i915/pxp/intel_pxp.c   | 95 ++
>>  drivers/gpu/drm/i915/pxp/intel_pxp.h   | 22 ++
>>  4 files changed, 122 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c 
>> b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
>> index 257063a57101..d64013d0afb5 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
>> +++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
>> @@ -13,6 +13,7 @@
>>  #include "intel_gt_irq.h"
>>  #include "intel_uncore.h"
>>  #include "intel_rps.h"
>> +#include "pxp/intel_pxp.h"
>>  
>> 
>> 
>> 
>>  static void guc_irq_handler(struct intel_guc *guc, u16 iir)
>>  {
>> @@ -106,6 +107,9 @@ gen11_other_irq_handler(struct intel_gt *gt, const u8 
>> instance,
>>  if (instance == OTHER_GTPM_INSTANCE)
>>  return gen11_rps_irq_handler(>rps, iir);
>>  
>> 
>> 
>> 
>> +if (instance == OTHER_KCR_INSTANCE)
>> +return intel_pxp_irq_handler(gt, iir);
>> +
>>  WARN_ONCE(1, "unhandled other interrupt instance=0x%x, iir=0x%x\n",
>>    instance, iir);
>>  }
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 7ea70b7ffcc6..faf6b06145fa 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -7941,6 +7941,7 @@ enum {
>>  /* irq instances for OTHER_CLASS */
>>  #define OTHER_GUC_INSTANCE  0
>>  #define OTHER_GTPM_INSTANCE 1
>> +#define OTHER_KCR_INSTANCE  4
>>  
>> 
>> 
>> 
>>  #define GEN11_INTR_IDENTITY_REG(x)  _MMIO(0x190060 + ((x) * 4))
>>  
>> 
>> 
>> 
>> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
>> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
>> index a469c55e3e54..d98bff4a0fde 100644
>> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
>> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
>> @@ -6,15 +6,110 @@
>>  #include "i915_drv.h"
>>  #include "intel_pxp.h"
>>  
>> 
>> 
>> 
>> +static void intel_pxp_write_irq_mask_reg(struct drm_i915_private *i915, u32 
>> mask)
>> +{
>> +WARN_ON(INTEL_GEN(i915) < 11);
>
>
> should be drm_warn_on(), also I don't see any value in this warning.
>
>> +
>> +/* crypto mask is in bit31-16 (Engine1 Interrupt Mask) */
>> +intel_uncore_write(>uncore, GEN11_CRYPTO_RSVD_INTR_MASK, mask << 
>> 16);
>> +}
>> +
>> +static void intel_pxp_unmask_irq(struct intel_gt *gt)
>> +{
>> +lockdep_assert_held(>irq_lock);
>> +
>> +intel_pxp_write_irq_mask_reg(gt->i915, 0);
>> +}
>> +
>> +static void intel_pxp_mask_irq(struct intel_gt *gt, u32 mask)
>> +{
>> +lockdep_assert_held(>irq_lock);
>> +
>> +intel_pxp_write_irq_mask_reg(gt->i915, mask);
>> +}
>> +
>> +static int intel_pxp_teardown_required_callback(struct drm_i915_private 
>> *i915)
>> +{
>> +drm_dbg(>drm, "%s was called\n", __func__);
>
> Looks like something used for debug, should not be in the upstream version.
> Saw a lot more of debug like this that should be removed.

Absolutely!

>
>> +
>> +return 0;
>> +}
>> +
>> +static int intel_pxp_global_terminate_complete_callback(struct 
>> drm_i915_private *i915)
>> +{
>> +drm_dbg(>drm, ">>> %s\n", __func__);
>> +
>> +return 0;
>> +}
>> +
>> +static void intel_pxp_irq_work(struct work_struct *work)
>> +{
>> +struct intel_pxp *pxp_ptr = container_of(work, typeof(*pxp_ptr), 
>> irq_work);
>> +struct drm_i915_private *i915 = container_of(pxp_ptr, typeof(*i915), 
>> pxp);
>> +u32 events = 0;
>> +
>> +spin_lock_irq(>gt.irq_lock);
>> +events = fetch_and_zero(_ptr->current_events);
>> +spin_unlock_irq(>gt.irq_lock);
>> +
>> +drm_dbg(>drm, "%s was called with events=[%d]\n", __func__, 
>> events);
>> +
>> +if (events & PXP_IRQ_VECTOR_DISPLAY_PXP_STATE_TERMINATED ||
>> +events & PXP_IRQ_VECTOR_DISPLAY_APP_TERM_PER_FW_REQ)
>> +intel_pxp_teardown_required_callback(i915);
>> +
>> +if (events & PXP_IRQ_VECTOR_PXP_DISP_STATE_RESET_COMPLETE)
>> +intel_pxp_global_terminate_complete_callback(i915);
>> +
>> +spin_lock_irq(>gt.irq_lock);
>> +intel_pxp_unmask_irq(>gt);
>> +spin_unlock_irq(>gt.irq_lock);
>> +}
>> +
>>  int intel_pxp_init(struct drm_i915_private *i915)
>>  {
>>  int ret;
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  drm_info(>drm, "i915_pxp_init\n");
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> +INIT_WORK(>pxp.irq_work, intel_pxp_irq_work);
>> +
>> +i915->pxp.handled_irr = (PXP_IRQ_VECTOR_DISPLAY_PXP_STATE_TERMINATED |
>> + PXP_IRQ_VECTOR_DISPLAY_APP_TERM_PER_FW_REQ |
>> + PXP_IRQ_VECTOR_PXP_DISP_STATE_RESET_COMPLETE);
>> +
>>  return ret;

[Intel-gfx] [PATCH] drm/i915/display: Record the plane update times for debugging

2020-11-23 Thread Chris Wilson 
Since we try and estimate how long we require to update the registers to
perform a plane update, it is of vital importance that we measure the
distribution of plane updates to better guide our estimate. If we
underestimate how long it takes to perform the plane update, we may
slip into the next scanout frame causing a tear. If we overestimate, we
may unnecessarily delay the update to the next frame, causing visible
jitter.

Replace the warning that we exceed some arbitrary threshold for the
vblank update with a histogram for debugfs.

Signed-off-by: Chris Wilson 
Cc: Jani Nikula 
Cc: Ville Syrjälä 
---
 .../drm/i915/display/intel_display_debugfs.c  | 46 +++
 .../drm/i915/display/intel_display_types.h|  6 +++
 drivers/gpu/drm/i915/display/intel_sprite.c   | 26 ---
 3 files changed, 71 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index ca41e8c00ad7..aa7a2a679138 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -865,6 +865,50 @@ static void intel_scaler_info(struct seq_file *m, struct 
intel_crtc *crtc)
}
 }
 
+#ifdef CONFIG_DRM_I915_DEBUG_VBLANK_EVADE
+static void crtc_vblank_info(struct seq_file *m, struct intel_crtc *crtc)
+{
+   char buf[ARRAY_SIZE(crtc->debug.vbl_times) + 1] = {};
+   int h, row, max;
+   u64 count;
+
+   max = 0;
+   count = 0;
+   for (h = 0; h < ARRAY_SIZE(crtc->debug.vbl_times); h++) {
+   if (crtc->debug.vbl_times[h] > max)
+   max = crtc->debug.vbl_times[h];
+   count += crtc->debug.vbl_times[h];
+   }
+   seq_printf(m, "\tUpdates: %llu\n", count);
+   if (!count)
+   return;
+
+   memset(buf, '-', sizeof(buf) - 1);
+   seq_printf(m, "\t  |%s|\n", buf);
+
+   max = ilog2(max);
+   for (row = max - 1; row--; ) {
+   memset(buf, ' ', sizeof(buf) - 1);
+   for (h = 0; h < ARRAY_SIZE(crtc->debug.vbl_times); h++) {
+   if (ilog2(crtc->debug.vbl_times[h]) >= row)
+   buf[h] = '*';
+   }
+   seq_printf(m, "\t  |%s|\n", buf);
+   }
+
+   memset(buf, '-', sizeof(buf) - 1);
+   seq_printf(m, "\t  |%s|\n", buf);
+   seq_printf(m, "\t1us (log) 1ms\n");
+
+   seq_printf(m, "\tMin update: %lluns\n", crtc->debug.min_vbl_time);
+   seq_printf(m, "\tMax update: %lluns\n", crtc->debug.max_vbl_time);
+   seq_printf(m, "\tAverage update: %lluns\n",
+  div64_u64(crtc->debug.sum_vbl_time,  count));
+}
+#else
+static void crtc_vblank_info(struct seq_file *m, struct intel_crtc *crtc) {}
+#endif
+
 static void intel_crtc_info(struct seq_file *m, struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -907,6 +951,8 @@ static void intel_crtc_info(struct seq_file *m, struct 
intel_crtc *crtc)
seq_printf(m, "\tunderrun reporting: cpu=%s pch=%s\n",
   yesno(!crtc->cpu_fifo_underrun_disabled),
   yesno(!crtc->pch_fifo_underrun_disabled));
+
+   crtc_vblank_info(m, crtc);
 }
 
 static int i915_display_info(struct seq_file *m, void *unused)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ce82d654d0f2..01214636be56 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1186,6 +1186,12 @@ struct intel_crtc {
ktime_t start_vbl_time;
int min_vbl, max_vbl;
int scanline_start;
+#ifdef CONFIG_DRM_I915_DEBUG_VBLANK_EVADE
+   u64 min_vbl_time;
+   u64 max_vbl_time;
+   u64 sum_vbl_time;
+   unsigned int vbl_times[20]; /* [1us, 1ms] */
+#endif
} debug;
 
/* scalers available on this crtc */
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c 
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 019a2d6d807a..fdb54a569224 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -250,13 +250,25 @@ void intel_pipe_update_end(struct intel_crtc_state 
*new_crtc_state)
crtc->debug.scanline_start, scanline_end);
}
 #ifdef CONFIG_DRM_I915_DEBUG_VBLANK_EVADE
-   else if (ktime_us_delta(end_vbl_time, crtc->debug.start_vbl_time) >
-VBLANK_EVASION_TIME_US)
-   drm_warn(_priv->drm,
-"Atomic update on pipe (%c) took %lld us, max time 
under evasion is %u us\n",
-pipe_name(pipe),
-ktime_us_delta(end_vbl_time, 
crtc->debug.start_vbl_time),
-VBLANK_EVASION_TIME_US);
+   {
+   unsigned int h;
+

Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread Miguel Ojeda 
On Sun, Nov 22, 2020 at 11:54 PM Finn Thain  wrote:
>
> We should also take into account optimisim about future improvements in
> tooling.

Not sure what you mean here. There is no reliable way to guess what
the intention was with a missing fallthrough, even if you parsed
whitespace and indentation.

> It is if you want to spin it that way.

How is that a "spin"? It is a fact that we won't get *implicit*
fallthrough mistakes anymore (in particular if we make it a hard
error).

> But what we inevitably get is changes like this:
>
>  case 3:
> this();
> +   break;
>  case 4:
> hmmm();
>
> Why? Mainly to silence the compiler. Also because the patch author argued
> successfully that they had found a theoretical bug, often in mature code.

If someone changes control flow, that is on them. Every kernel
developer knows what `break` does.

> But is anyone keeping score of the regressions? If unreported bugs count,
> what about unreported regressions?

Introducing `fallthrough` does not change semantics. If you are really
keen, you can always compare the objects because the generated code
shouldn't change.

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

Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread Miguel Ojeda 
On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
 wrote:
>
> Well, it seems to be three years of someone's time plus the maintainer
> review time and series disruption of nearly a thousand patches.  Let's
> be conservative and assume the producer worked about 30% on the series
> and it takes about 5-10 minutes per patch to review, merge and for
> others to rework existing series.  So let's say it's cost a person year
> of a relatively junior engineer producing the patches and say 100h of
> review and application time.  The latter is likely the big ticket item
> because it's what we have in least supply in the kernel (even though
> it's 20x vs the producer time).

How are you arriving at such numbers? It is a total of ~200 trivial lines.

> It's not about the risk of the changes it's about the cost of
> implementing them.  Even if you discount the producer time (which
> someone gets to pay for, and if I were the engineering manager, I'd be
> unhappy about), the review/merge/rework time is pretty significant in
> exchange for six minor bug fixes.  Fine, when a new compiler warning
> comes along it's certainly reasonable to see if we can benefit from it
> and the fact that the compiler people think it's worthwhile is enough
> evidence to assume this initially.  But at some point you have to ask
> whether that assumption is supported by the evidence we've accumulated
> over the time we've been using it.  And if the evidence doesn't support
> it perhaps it is time to stop the experiment.

Maintainers routinely review 1-line trivial patches, not to mention
internal API changes, etc.

If some company does not want to pay for that, that's fine, but they
don't get to be maintainers and claim `Supported`.

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

Re: [Intel-gfx] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread Gustavo A. R. Silva 
On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > Please tell me our reward for all this effort isn't a single
> > > > > missing error print.
> > > > 
> > > > There were quite literally dozens of logical defects found
> > > > by the fallthrough additions.  Very few were logging only.
> > > 
> > > So can you give us the best examples (or indeed all of them if
> > > someone is keeping score)?  hopefully this isn't a US election
> > > situation ...
> > 
> > Gustavo?  Are you running for congress now?
> > 
> > https://lwn.net/Articles/794944/
> 
> That's 21 reported fixes of which about 50% seem to produce no change
> in code behaviour at all, a quarter seem to have no user visible effect
> with the remaining quarter producing unexpected errors on obscure
> configuration parameters, which is why no-one really noticed them
> before.

The really important point here is the number of bugs this has prevented
and will prevent in the future. See an example of this, below:

https://lore.kernel.org/linux-iio/20190813135802.gb27...@kroah.com/

This work is still relevant, even if the total number of issues/bugs
we find in the process is zero (which is not the case).

"The sucky thing about doing hard work to deploy hardening is that the
result is totally invisible by definition (things not happening) [..]"
- Dmitry Vyukov

Thanks
--
Gustavo





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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915/gt: Defer enabling the breadcrumb interrupt to after submission

2020-11-23 Thread Patchwork 
== Series Details ==

Series: series starting with [CI,1/4] drm/i915/gt: Defer enabling the 
breadcrumb interrupt to after submission
URL   : https://patchwork.freedesktop.org/series/84165/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9376 -> Patchwork_18957


Summary
---

  **SUCCESS**

  No regressions found.

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

New tests
-

  New tests have been introduced between CI_DRM_9376 and Patchwork_18957:

### New CI tests (1) ###

  * boot:
- Statuses : 39 pass(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-tgl-u2:  [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/fi-tgl-u2/igt@core_hotunp...@unbind-rebind.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18957/fi-tgl-u2/igt@core_hotunp...@unbind-rebind.html

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

  * igt@kms_busy@basic@flip:
- fi-kbl-soraka:  [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/fi-kbl-soraka/igt@kms_busy@ba...@flip.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18957/fi-kbl-soraka/igt@kms_busy@ba...@flip.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900:   [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18957/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2:  [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +1 
similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18957/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0:
- fi-cfl-8109u:   [DMESG-WARN][11] ([i915#165] / [i915#262]) -> 
[PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18957/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2:  [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9376/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18957/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html

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

  [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262
  [k.org#205379]: https://bugzilla.kernel.org/show_bug.cgi?id=205379


Participating hosts (45 -> 39)
--

  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-bwr-2160 fi-tgl-y 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9376 -> Patchwork_18957

  CI-20190529: 20190529
  CI_DRM_9376: d08ea807a6466f311fe921872bc18cfc384ae281 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5865: 76b7d1ecf6a3c0a5a538146bb055d0eb5fe232d0 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_18957: 08f2b48a679e0a3f678fe9e70ff1c2e053200e90 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

08f2b48a679e drm/i915/gt: Free stale request on destroying the virtual engine
f4ac9f8b911f drm/i915/gt: Don't cancel the interrupt shadow too early
6592f2a0e6df drm/i915/gt: Track signaled breadcrumbs outside of the breadcrumb 
spinlock
247beb5e494c drm/i915/gt: Defer enabling the breadcrumb interrupt to after 
submission

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/4] drm/i915/gt: Defer enabling the breadcrumb interrupt to after submission

2020-11-23 Thread Patchwork 
== Series Details ==

Series: series starting with [CI,1/4] drm/i915/gt: Defer enabling the 
breadcrumb interrupt to after submission
URL   : https://patchwork.freedesktop.org/series/84165/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_reset.c:1312:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/selftest_reset.c:100:20:expected void *in
+drivers/gpu/drm/i915/gt/selftest_reset.c:100:20:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:100:20: warning: incorrect type in 
assignment (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:101:46:expected void const *src
+drivers/gpu/drm/i915/gt/selftest_reset.c:101:46:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:101:46: warning: incorrect type in 
argument 2 (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:136:20:expected void *in
+drivers/gpu/drm/i915/gt/selftest_reset.c:136:20:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:136:20: warning: incorrect type in 
assignment (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:137:46:expected void const *src
+drivers/gpu/drm/i915/gt/selftest_reset.c:137:46:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:137:46: warning: incorrect type in 
argument 2 (different address spaces)
+drivers/gpu/drm/i915/gt/selftest_reset.c:98:34:expected unsigned int 
[usertype] *s
+drivers/gpu/drm/i915/gt/selftest_reset.c:98:34:got void [noderef] __iomem 
*[assigned] s
+drivers/gpu/drm/i915/gt/selftest_reset.c:98:34: warning: incorrect type in 
argument 1 (different address spaces)
+drivers/gpu/drm/i915/gvt/mmio.c:290:23: warning: memcpy with byte count of 
279040
+drivers/gpu/drm/i915/i915_perf.c:1447:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1501:15: warning: memset with byte count of 
16777216
+./include/linux/seqlock.h:838:24: warning: trying to copy expression type 31
+./include/linux/seqlock.h:838:24: warning: trying to copy expression type 31
+./include/linux/seqlock.h:864:16: warning: trying to copy expression type 31
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block

[Intel-gfx] [CI 3/4] drm/i915/gt: Don't cancel the interrupt shadow too early

2020-11-23 Thread Chris Wilson 
We currently want to keep the interrupt enabled until the interrupt after
which we have no more work to do. This heuristic was broken by us
kicking the irq-work on adding a completed request without attaching a
signaler -- hence it appearing to the irq-worker that an interrupt had
fired when we were idle.

Fixes: bda4d4db6dd6 ("drm/i915/gt: Replace 
intel_engine_transfer_stale_breadcrumbs")
Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 43cfabb102ea..cf6e05ea4d8f 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -229,7 +229,7 @@ static void signal_irq_work(struct irq_work *work)
 * interrupt draw less ire from other users of the system and tools
 * like powertop.
 */
-   if (b->irq_armed && list_empty(>signalers))
+   if (!signal && b->irq_armed && list_empty(>signalers))
__intel_breadcrumbs_disarm_irq(b);
 
list_for_each_entry_safe(ce, cn, >signalers, signal_link) {
-- 
2.20.1

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

[Intel-gfx] [CI 2/4] drm/i915/gt: Track signaled breadcrumbs outside of the breadcrumb spinlock

2020-11-23 Thread Chris Wilson 
Make b->signaled_requests a lockless-list so that we can manipulate it
outside of the b->irq_lock.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_breadcrumbs.c   | 34 ---
 .../gpu/drm/i915/gt/intel_breadcrumbs_types.h |  2 +-
 drivers/gpu/drm/i915/i915_request.h   |  6 +++-
 3 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 8d85683314e1..43cfabb102ea 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -173,26 +173,34 @@ static void add_retire(struct intel_breadcrumbs *b, 
struct intel_timeline *tl)
intel_engine_add_retire(b->irq_engine, tl);
 }
 
-static bool __signal_request(struct i915_request *rq, struct list_head 
*signals)
+static bool __signal_request(struct i915_request *rq)
 {
-   clear_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags);
-
if (!__dma_fence_signal(>fence)) {
i915_request_put(rq);
return false;
}
 
-   list_add_tail(>signal_link, signals);
return true;
 }
 
+static struct llist_node *
+slist_add(struct llist_node *node, struct llist_node *head)
+{
+   node->next = head;
+   return node;
+}
+
 static void signal_irq_work(struct irq_work *work)
 {
struct intel_breadcrumbs *b = container_of(work, typeof(*b), irq_work);
const ktime_t timestamp = ktime_get();
+   struct llist_node *signal, *sn;
struct intel_context *ce, *cn;
struct list_head *pos, *next;
-   LIST_HEAD(signal);
+
+   signal = NULL;
+   if (unlikely(!llist_empty(>signaled_requests)))
+   signal = llist_del_all(>signaled_requests);
 
spin_lock(>irq_lock);
 
@@ -224,8 +232,6 @@ static void signal_irq_work(struct irq_work *work)
if (b->irq_armed && list_empty(>signalers))
__intel_breadcrumbs_disarm_irq(b);
 
-   list_splice_init(>signaled_requests, );
-
list_for_each_entry_safe(ce, cn, >signalers, signal_link) {
GEM_BUG_ON(list_empty(>signals));
 
@@ -242,7 +248,10 @@ static void signal_irq_work(struct irq_work *work)
 * spinlock as the callback chain may end up adding
 * more signalers to the same context or engine.
 */
-   __signal_request(rq, );
+   clear_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags);
+   if (__signal_request(rq))
+   /* We own signal_node now, xfer to local list */
+   signal = slist_add(>signal_node, signal);
}
 
/*
@@ -262,9 +271,9 @@ static void signal_irq_work(struct irq_work *work)
 
spin_unlock(>irq_lock);
 
-   list_for_each_safe(pos, next, ) {
+   llist_for_each_safe(signal, sn, signal) {
struct i915_request *rq =
-   list_entry(pos, typeof(*rq), signal_link);
+   llist_entry(signal, typeof(*rq), signal_node);
struct list_head cb_list;
 
spin_lock(>lock);
@@ -291,7 +300,7 @@ intel_breadcrumbs_create(struct intel_engine_cs *irq_engine)
 
spin_lock_init(>irq_lock);
INIT_LIST_HEAD(>signalers);
-   INIT_LIST_HEAD(>signaled_requests);
+   init_llist_head(>signaled_requests);
 
init_irq_work(>irq_work, signal_irq_work);
 
@@ -355,7 +364,8 @@ static void insert_breadcrumb(struct i915_request *rq,
 * its signal completion.
 */
if (__request_completed(rq)) {
-   if (__signal_request(rq, >signaled_requests))
+   if (__signal_request(rq) &&
+   llist_add(>signal_node, >signaled_requests))
irq_work_queue(>irq_work);
return;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h 
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
index 8e53b9942695..3fa19820b37a 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
@@ -35,7 +35,7 @@ struct intel_breadcrumbs {
struct intel_engine_cs *irq_engine;
 
struct list_head signalers;
-   struct list_head signaled_requests;
+   struct llist_head signaled_requests;
 
struct irq_work irq_work; /* for use from inside irq_lock */
 
diff --git a/drivers/gpu/drm/i915/i915_request.h 
b/drivers/gpu/drm/i915/i915_request.h
index 8f6173b1c3df..b222f7b46e9c 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -177,7 +177,11 @@ struct i915_request {
struct intel_context *context;
struct intel_ring *ring;
struct intel_timeline __rcu *timeline;
-   struct list_head signal_link;
+
+   union {
+   struct

[Intel-gfx] [CI 1/4] drm/i915/gt: Defer enabling the breadcrumb interrupt to after submission

2020-11-23 Thread Chris Wilson 
Move the register slow register write and readback from out of the
critical path for execlists submission and delay it until the following
worker, shaving off around 200us. Note that the same signal_irq_work() is
allowed to run concurrently on each CPU (but it will only be queued once,
once running though it can be requeued and reexecuted) so we have to
remember to lock the global interactions as we cannot rely on the
signal_irq_work() itself providing the serialisation (in constrast to a
tasklet).

By pushing the arm/disarm into the central signaling worker we can close
the race for disarming the interrupt (and dropping its associated
GT wakeref) on parking the engine. If we loose the race, that GT wakeref
may be held indefinitely, preventing the machine from sleeping while
the GPU is ostensibly idle.

v2: Move the self-arming parking of the signal_irq_work to a flush of
the irq-work from intel_breadcrumbs_park().

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2271
Fixes: dfeba1ae34c8 ("drm/i915/gt: Hold context/request reference while 
breadcrumbs are active")
Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 109 +---
 1 file changed, 70 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index d8b206e53660..8d85683314e1 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -30,18 +30,21 @@
 #include "i915_trace.h"
 #include "intel_breadcrumbs.h"
 #include "intel_context.h"
+#include "intel_engine_pm.h"
 #include "intel_gt_pm.h"
 #include "intel_gt_requests.h"
 
-static void irq_enable(struct intel_engine_cs *engine)
+static bool irq_enable(struct intel_engine_cs *engine)
 {
if (!engine->irq_enable)
-   return;
+   return false;
 
/* Caller disables interrupts */
spin_lock(>gt->irq_lock);
engine->irq_enable(engine);
spin_unlock(>gt->irq_lock);
+
+   return true;
 }
 
 static void irq_disable(struct intel_engine_cs *engine)
@@ -57,12 +60,11 @@ static void irq_disable(struct intel_engine_cs *engine)
 
 static void __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
 {
-   lockdep_assert_held(>irq_lock);
-
-   if (!b->irq_engine || b->irq_armed)
-   return;
-
-   if (!intel_gt_pm_get_if_awake(b->irq_engine->gt))
+   /*
+* Since we are waiting on a request, the GPU should be busy
+* and should have its own rpm reference.
+*/
+   if (GEM_WARN_ON(!intel_gt_pm_get_if_awake(b->irq_engine->gt)))
return;
 
/*
@@ -73,25 +75,24 @@ static void __intel_breadcrumbs_arm_irq(struct 
intel_breadcrumbs *b)
 */
WRITE_ONCE(b->irq_armed, true);
 
-   /*
-* Since we are waiting on a request, the GPU should be busy
-* and should have its own rpm reference. This is tracked
-* by i915->gt.awake, we can forgo holding our own wakref
-* for the interrupt as before i915->gt.awake is released (when
-* the driver is idle) we disarm the breadcrumbs.
-*/
-
-   if (!b->irq_enabled++)
-   irq_enable(b->irq_engine);
+   /* Requests may have completed before we could enable the interrupt. */
+   if (!b->irq_enabled++ && irq_enable(b->irq_engine))
+   irq_work_queue(>irq_work);
 }
 
-static void __intel_breadcrumbs_disarm_irq(struct intel_breadcrumbs *b)
+static void intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
 {
-   lockdep_assert_held(>irq_lock);
-
-   if (!b->irq_engine || !b->irq_armed)
+   if (!b->irq_engine)
return;
 
+   spin_lock(>irq_lock);
+   if (!b->irq_armed)
+   __intel_breadcrumbs_arm_irq(b);
+   spin_unlock(>irq_lock);
+}
+
+static void __intel_breadcrumbs_disarm_irq(struct intel_breadcrumbs *b)
+{
GEM_BUG_ON(!b->irq_enabled);
if (!--b->irq_enabled)
irq_disable(b->irq_engine);
@@ -105,8 +106,6 @@ static void add_signaling_context(struct intel_breadcrumbs 
*b,
 {
intel_context_get(ce);
list_add_tail(>signal_link, >signalers);
-   if (list_is_first(>signal_link, >signalers))
-   __intel_breadcrumbs_arm_irq(b);
 }
 
 static void remove_signaling_context(struct intel_breadcrumbs *b,
@@ -197,7 +196,32 @@ static void signal_irq_work(struct irq_work *work)
 
spin_lock(>irq_lock);
 
-   if (list_empty(>signalers))
+   /*
+* Keep the irq armed until the interrupt after all listeners are gone.
+*
+* Enabling/disabling the interrupt is rather costly, roughly a couple
+* of hundred microseconds. If we are proactive and enable/disable
+* the interrupt around every request that wants a breadcrumb, we
+* quickly drown in the extra orders of magnitude of latency imposed
+

[Intel-gfx] [CI 4/4] drm/i915/gt: Free stale request on destroying the virtual engine

2020-11-23 Thread Chris Wilson 
Since preempt-to-busy, we may unsubmit a request while it is still on
the HW and completes asynchronously. That means it may be retired and in
the process destroy the virtual engine (as the user has closed their
context), but that engine may still be holding onto the unsubmitted
compelted request. Therefore we need to potentially cleanup the old
request on destroying the virtual engine. We also have to keep the
virtual_engine alive until after the sibling's execlists_dequeue() have
finished peeking into the virtual engines, for which we serialise with
RCU.

v2: Be paranoid and flush the tasklet as well.
v3: And flush the tasklet before the engines, as the tasklet may
re-attach an rb_node after our removal from the siblings.

Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_lrc.c | 60 +
 1 file changed, 53 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 30759e95da0e..c7a25abec5d0 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -182,6 +182,7 @@
 struct virtual_engine {
struct intel_engine_cs base;
struct intel_context context;
+   struct rcu_work rcu;
 
/*
 * We allow only a single request through the virtual engine at a time
@@ -5470,33 +5471,57 @@ static struct list_head *virtual_queue(struct 
virtual_engine *ve)
return >base.execlists.default_priolist.requests[0];
 }
 
-static void virtual_context_destroy(struct kref *kref)
+static void rcu_virtual_context_destroy(struct work_struct *wrk)
 {
struct virtual_engine *ve =
-   container_of(kref, typeof(*ve), context.ref);
+   container_of(wrk, typeof(*ve), rcu.work);
unsigned int n;
 
-   GEM_BUG_ON(!list_empty(virtual_queue(ve)));
-   GEM_BUG_ON(ve->request);
GEM_BUG_ON(ve->context.inflight);
 
+   /* Preempt-to-busy may leave a stale request behind. */
+   if (unlikely(ve->request)) {
+   struct i915_request *old;
+
+   spin_lock_irq(>base.active.lock);
+
+   old = fetch_and_zero(>request);
+   if (old) {
+   GEM_BUG_ON(!i915_request_completed(old));
+   __i915_request_submit(old);
+   i915_request_put(old);
+   }
+
+   spin_unlock_irq(>base.active.lock);
+   }
+
+   /*
+* Flush the tasklet in case it is still running on another core.
+*
+* This needs to be done before we remove ourselves from the siblings'
+* rbtrees as in the case it is running in parallel, it may reinsert
+* the rb_node into a sibling.
+*/
+   tasklet_kill(>base.execlists.tasklet);
+
+   /* Decouple ourselves from the siblings, no more access allowed. */
for (n = 0; n < ve->num_siblings; n++) {
struct intel_engine_cs *sibling = ve->siblings[n];
struct rb_node *node = >nodes[sibling->id].rb;
-   unsigned long flags;
 
if (RB_EMPTY_NODE(node))
continue;
 
-   spin_lock_irqsave(>active.lock, flags);
+   spin_lock_irq(>active.lock);
 
/* Detachment is lazily performed in the execlists tasklet */
if (!RB_EMPTY_NODE(node))
rb_erase_cached(node, >execlists.virtual);
 
-   spin_unlock_irqrestore(>active.lock, flags);
+   spin_unlock_irq(>active.lock);
}
GEM_BUG_ON(__tasklet_is_scheduled(>base.execlists.tasklet));
+   GEM_BUG_ON(!list_empty(virtual_queue(ve)));
 
if (ve->context.state)
__execlists_context_fini(>context);
@@ -5509,6 +5534,27 @@ static void virtual_context_destroy(struct kref *kref)
kfree(ve);
 }
 
+static void virtual_context_destroy(struct kref *kref)
+{
+   struct virtual_engine *ve =
+   container_of(kref, typeof(*ve), context.ref);
+
+   GEM_BUG_ON(!list_empty(>context.signals));
+
+   /*
+* When destroying the virtual engine, we have to be aware that
+* it may still be in use from an hardirq/softirq context causing
+* the resubmission of a completed request (background completion
+* due to preempt-to-busy). Before we can free the engine, we need
+* to flush the submission code and tasklets that are still potentially
+* accessing the engine. Flushing the tasklets require process context,
+* and since we can guard the resubmit onto the engine with an RCU read
+* lock, we can delegate the free of the engine to an RCU worker.
+*/
+   INIT_RCU_WORK(>rcu, rcu_virtual_context_destroy);
+   queue_rcu_work(system_wq, >rcu);
+}
+
 static void

Re: [Intel-gfx] [PULL] gvt-next

2020-11-23 Thread Joonas Lahtinen 
Quoting Zhenyu Wang (2020-11-23 11:05:17)
> 
> Hi,
> 
> Here's gvt next pull for v5.11. Mostly it's for host suspend/resume
> fix with vGPU active and with some other enhancement as details below.
> Note that this includes some minor i915 driver change to add gvt hook
> in suspend/resume function which has been sent and reviewed on
> intel-gfx list.
> 
> I just generated against drm-intel-next-queued-2020-11-03 which this
> tree bases on now. Let me know if there's any issue in merge.

Sometimes GVT changes are paired with changes related the i915 side
to adjust the running virtual clients. The changes are more often
related to GT side, but there's also been display related changes.

Going forward, would we want to continue to apply gvt-next to
drm-intel-next (-queued is planned to be deprecated) or
should we use drm-intel-gt-next?

Or should we always strictly apply the GVT changes to drm-intel-next,
and then any related i915 changes to drm-intel-next or drm-intel-gt-next
depending on which one they are related to?

Regards, Joonas

> Thanks
> --
> The following changes since commit 139caf7ca2866cd0a45814ff938cb0c33920a266:
> 
>   drm/i915: Update DRIVER_DATE to 20201103 (2020-11-03 14:21:25 +0200)
> 
> are available in the Git repository at:
> 
>   https://github.com/intel/gvt-linux tags/gvt-next-2020-11-23
> 
> for you to fetch changes up to 9a3a238b3de97b4210c6de66aa88b2d7021ac086:
> 
>   drm/i915/gvt: treat intel_gvt_mpt as const in gvt code (2020-11-23 17:14:20 
> +0800)
> 
> 
> gvt-next-2020-11-23
> 
> - Fix host suspend/resume with vGPU (Colin)
> - optimize idr init (Varma)
> - Change intel_gvt_mpt as const (Julian)
> - One comment error fix (Yan)
> 
> 
> Colin Xu (3):
>   drm/i915/gvt: Save/restore HW status to support GVT suspend/resume
>   drm/i915: Add GVT resume routine to i915
>   drm/i915/gvt: Fix virtual display setup for BXT/APL
> 
> Deepak R Varma (1):
>   drm/i915/gvt: replace idr_init() by idr_init_base()
> 
> Julian Stecklina (1):
>   drm/i915/gvt: treat intel_gvt_mpt as const in gvt code
> 
> Yan Zhao (1):
>   drm/i915/gvt: correct a false comment of flag F_UNALIGN
> 
>  drivers/gpu/drm/i915/gvt/display.c  | 179 
> 
>  drivers/gpu/drm/i915/gvt/gtt.c  |  64 +
>  drivers/gpu/drm/i915/gvt/gtt.h  |   4 +
>  drivers/gpu/drm/i915/gvt/gvt.c  |  13 ++-
>  drivers/gpu/drm/i915/gvt/gvt.h  |   7 +-
>  drivers/gpu/drm/i915/gvt/handlers.c |  44 -
>  drivers/gpu/drm/i915/gvt/kvmgt.c|   2 +-
>  drivers/gpu/drm/i915/gvt/mmio.c |   5 +
>  drivers/gpu/drm/i915/gvt/mmio.h |   4 +
>  drivers/gpu/drm/i915/gvt/mpt.h  |   2 +-
>  drivers/gpu/drm/i915/gvt/vgpu.c |   2 +-
>  drivers/gpu/drm/i915/i915_drv.c |   2 +
>  drivers/gpu/drm/i915/intel_gvt.c|  15 +++
>  drivers/gpu/drm/i915/intel_gvt.h|   5 +
>  14 files changed, 338 insertions(+), 10 deletions(-)
> 
> -- 
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] gvt-next

2020-11-23 Thread Zhenyu Wang 

Hi,

Here's gvt next pull for v5.11. Mostly it's for host suspend/resume
fix with vGPU active and with some other enhancement as details below.
Note that this includes some minor i915 driver change to add gvt hook
in suspend/resume function which has been sent and reviewed on
intel-gfx list.

I just generated against drm-intel-next-queued-2020-11-03 which this
tree bases on now. Let me know if there's any issue in merge.

Thanks
--
The following changes since commit 139caf7ca2866cd0a45814ff938cb0c33920a266:

  drm/i915: Update DRIVER_DATE to 20201103 (2020-11-03 14:21:25 +0200)

are available in the Git repository at:

  https://github.com/intel/gvt-linux tags/gvt-next-2020-11-23

for you to fetch changes up to 9a3a238b3de97b4210c6de66aa88b2d7021ac086:

  drm/i915/gvt: treat intel_gvt_mpt as const in gvt code (2020-11-23 17:14:20 
+0800)


gvt-next-2020-11-23

- Fix host suspend/resume with vGPU (Colin)
- optimize idr init (Varma)
- Change intel_gvt_mpt as const (Julian)
- One comment error fix (Yan)


Colin Xu (3):
  drm/i915/gvt: Save/restore HW status to support GVT suspend/resume
  drm/i915: Add GVT resume routine to i915
  drm/i915/gvt: Fix virtual display setup for BXT/APL

Deepak R Varma (1):
  drm/i915/gvt: replace idr_init() by idr_init_base()

Julian Stecklina (1):
  drm/i915/gvt: treat intel_gvt_mpt as const in gvt code

Yan Zhao (1):
  drm/i915/gvt: correct a false comment of flag F_UNALIGN

 drivers/gpu/drm/i915/gvt/display.c  | 179 
 drivers/gpu/drm/i915/gvt/gtt.c  |  64 +
 drivers/gpu/drm/i915/gvt/gtt.h  |   4 +
 drivers/gpu/drm/i915/gvt/gvt.c  |  13 ++-
 drivers/gpu/drm/i915/gvt/gvt.h  |   7 +-
 drivers/gpu/drm/i915/gvt/handlers.c |  44 -
 drivers/gpu/drm/i915/gvt/kvmgt.c|   2 +-
 drivers/gpu/drm/i915/gvt/mmio.c |   5 +
 drivers/gpu/drm/i915/gvt/mmio.h |   4 +
 drivers/gpu/drm/i915/gvt/mpt.h  |   2 +-
 drivers/gpu/drm/i915/gvt/vgpu.c |   2 +-
 drivers/gpu/drm/i915/i915_drv.c |   2 +
 drivers/gpu/drm/i915/intel_gvt.c|  15 +++
 drivers/gpu/drm/i915/intel_gvt.h|   5 +
 14 files changed, 338 insertions(+), 10 deletions(-)

-- 

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


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