Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: ratelimit errors in display engine irq (rev2)

2022-12-15 Thread Yedireswarapu, SaiX Nandan
Hi,

Issue re-reported, https://patchwork.freedesktop.org/series/111951/


Thanks,
Y Sai Nandan


-Original Message-
From: De Marchi, Lucas  
Sent: Friday, December 16, 2022 5:55 AM
To: intel-gfx@lists.freedesktop.org
Cc: Yedireswarapu, SaiX Nandan 
Subject: Re: ✗ Fi.CI.BAT: failure for drm/i915: ratelimit errors in display 
engine irq (rev2)

On Thu, Dec 15, 2022 at 08:39:47PM +, Patchwork wrote:
>== Series Details ==
>
>Series: drm/i915: ratelimit errors in display engine irq (rev2)
>URL   : https://patchwork.freedesktop.org/series/111951/
>State : failure
>
>== Summary ==
>
>CI Bug Log - changes from CI_DRM_12511 -> Patchwork_111951v2 
>
>
>Summary
>---
>
>  **FAILURE**
>
>  Serious unknown changes coming with Patchwork_111951v2 absolutely 
> need to be  verified manually.
>
>  If you think the reported changes have nothing to do with the changes  
> introduced in Patchwork_111951v2, 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_111951v2/index.html
>
>Participating hosts (40 -> 40)
>--
>
>  No changes in participating hosts
>
>Possible new issues
>---
>
>  Here are the unknown changes that may have been introduced in 
> Patchwork_111951v2:
>
>### IGT changes ###
>
> Possible regressions 
>
>  * igt@kms_pipe_crc_basic@nonblocking-crc:
>- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][1]
>   [1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111951v2/fi-kbl-sor
> aka/igt@kms_pipe_crc_ba...@nonblocking-crc.html

Unrelated change

Lucas De Marchi

>
>
>Known issues
>
>
>  Here are the changes found in Patchwork_111951v2 that come from known issues:
>
>### IGT changes ###
>
> Issues hit 
>
>  * igt@kms_chamelium@common-hpd-after-suspend:
>- fi-pnv-d510:NOTRUN -> [SKIP][2] ([fdo#109271])
>   [2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111951v2/fi-pnv-d51
> 0/igt@kms_chamel...@common-hpd-after-suspend.html
>
>
> Possible fixes 
>
>  * igt@gem_exec_suspend@basic-s3@smem:
>- {bat-rpls-1}:   [DMESG-WARN][3] ([i915#6687]) -> [PASS][4]
>   [3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
>   [4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111951v2/bat-rpls-1
> /igt@gem_exec_suspend@basic...@smem.html
>
>  * igt@i915_selftest@live@gt_lrc:
>- {bat-adln-1}:   [INCOMPLETE][5] ([i915#4983] / [i915#7609]) -> 
> [PASS][6]
>   [5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/bat-adln-1/igt@i915_selftest@live@gt_lrc.html
>   [6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111951v2/bat-adln-1
> /igt@i915_selftest@live@gt_lrc.html
>
>  * igt@i915_selftest@live@slpc:
>- {bat-rpls-1}:   [DMESG-FAIL][7] ([i915#6367]) -> [PASS][8]
>   [7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/bat-rpls-1/igt@i915_selftest@l...@slpc.html
>   [8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111951v2/bat-rpls-1
> /igt@i915_selftest@l...@slpc.html
>
>
>  {name}: This element is suppressed. This means it is ignored when computing
>  the status of the difference (SUCCESS, WARNING, or FAILURE).
>
>  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
>  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
>  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
>  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
>  [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
>  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
>  [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
>  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
>  [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609
>
>
>Build changes
>-
>
>  * Linux: CI_DRM_12511 -> Patchwork_111951v2
>
>  CI-20190529: 20190529
>  CI_DRM_12511: 2f1afd3898412b8487d420921f34fb5340e15e5b @ 
> git://anongit.freedesktop.org/gfx-ci/linux
>  IGT_7095: 0d821bca4e1086c96bb8928a0d24e707396e9373 @ 
> https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
>  Patchwork_111951v2: 2f1afd3898412b8487d420921f34fb5340e15e5b @ 
> git://anongit.freedesktop.org/gfx-ci/linux
>
>
>### Linux commits
>
>f635e7ac7aa5 drm/i915: ratelimit errors in display engine irq
>
>== Logs ==
>
>For more details see: 
>https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111951v2/index.html


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: ratelimit errors in display engine irq (rev2)

2022-12-15 Thread Patchwork
== Series Details ==

Series: drm/i915: ratelimit errors in display engine irq (rev2)
URL   : https://patchwork.freedesktop.org/series/111951/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12511 -> Patchwork_111951v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 40)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-pnv-d510:NOTRUN -> [SKIP][1] ([fdo#109271])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111951v2/fi-pnv-d510/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@nonblocking-crc:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][2] ([i915#7705])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111951v2/fi-kbl-soraka/igt@kms_pipe_crc_ba...@nonblocking-crc.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- {bat-rpls-1}:   [DMESG-WARN][3] ([i915#6687]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111951v2/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@gt_lrc:
- {bat-adln-1}:   [INCOMPLETE][5] ([i915#4983] / [i915#7609]) -> 
[PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/bat-adln-1/igt@i915_selftest@live@gt_lrc.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111951v2/bat-adln-1/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@slpc:
- {bat-rpls-1}:   [DMESG-FAIL][7] ([i915#6367]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/bat-rpls-1/igt@i915_selftest@l...@slpc.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111951v2/bat-rpls-1/igt@i915_selftest@l...@slpc.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609
  [i915#7705]: https://gitlab.freedesktop.org/drm/intel/issues/7705


Build changes
-

  * Linux: CI_DRM_12511 -> Patchwork_111951v2

  CI-20190529: 20190529
  CI_DRM_12511: 2f1afd3898412b8487d420921f34fb5340e15e5b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7095: 0d821bca4e1086c96bb8928a0d24e707396e9373 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_111951v2: 2f1afd3898412b8487d420921f34fb5340e15e5b @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

f635e7ac7aa5 drm/i915: ratelimit errors in display engine irq

== Logs ==

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


Re: [Intel-gfx] [PATCH] drm/i915: improve the catch-all evict to handle lock contention

2022-12-15 Thread Mani Milani
This patch passed all my tests, some of which were failing before
applying the patch. Thanks.

Reviewed-by: Mani Milani 
Tested-by: Mani Milani 

On Thu, Dec 15, 2022 at 4:46 PM Mani Milani  wrote:
>
> Thanks for the explanations Matthew. It all makes sense now. I will
> now test this patch further and report back the results.
>
> There is just one comment block that needs to be updated I think. See below:
>
> On Wed, Dec 14, 2022 at 10:47 PM Matthew Auld  wrote:
> >
> ...
> > >> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
> > >> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > >> index 86956b902c97..e2ce1e4e9723 100644
> > >> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > >> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > >> @@ -745,25 +745,44 @@ static int eb_reserve(struct i915_execbuffer *eb)
> > >>   *
> > >>   * Defragmenting is skipped if all objects are pinned at a 
> > >> fixed location.
> > >>   */
> Could you please update the comment block above and add a little
> explanation for the new pass=3 you added?
>
> > >> -   for (pass = 0; pass <= 2; pass++) {
> > >> +   for (pass = 0; pass <= 3; pass++) {
> > >>  int pin_flags = PIN_USER | PIN_VALIDATE;
> > >>
> > >>  if (pass == 0)
> > >>  pin_flags |= PIN_NONBLOCK;
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
> > >> b/drivers/gpu/drm/i915/i915_gem_evict.c
> > >> index 4cfe36b0366b..c02ebd6900ae 100644
> > >> --- a/drivers/gpu/drm/i915/i915_gem_evict.c
> > >> +++ b/drivers/gpu/drm/i915/i915_gem_evict.c
> > >> @@ -441,6 +441,11 @@ int i915_gem_evict_for_node(struct 
> > >> i915_address_space *vm,
> > >>* @vm: Address space to cleanse
> > >>* @ww: An optional struct i915_gem_ww_ctx. If not NULL, 
> > >> i915_gem_evict_vm
> > >>* will be able to evict vma's locked by the ww as well.
> > >> + * @busy_bo: Optional pointer to struct drm_i915_gem_object. If not 
> > >> NULL, then
> > >> + * in the event i915_gem_evict_vm() is unable to trylock an object for 
> > >> eviction,
> > >> + * then @busy_bo will point to it. -EBUSY is also returned. The caller 
> > >> must drop
> > >> + * the vm->mutex, before trying again to acquire the contended lock. 
> > >> The caller
> > >> + * also owns a reference to the object.
> > >>*
> > >>* This function evicts all vmas from a vm.
> > >>*
> > >> @@ -450,7 +455,8 @@ int i915_gem_evict_for_node(struct 
> > >> i915_address_space *vm,
> > >>* To clarify: This is for freeing up virtual address space, not for 
> > >> freeing
> > >>* memory in e.g. the shrinker.
> > >>*/
> > >> -int i915_gem_evict_vm(struct i915_address_space *vm, struct 
> > >> i915_gem_ww_ctx *ww)
> > >> +int i915_gem_evict_vm(struct i915_address_space *vm, struct 
> > >> i915_gem_ww_ctx *ww,
> > >> + struct drm_i915_gem_object **busy_bo)
> > >>   {
> > >>  int ret = 0;
> > >>
> > >> @@ -482,15 +488,22 @@ int i915_gem_evict_vm(struct i915_address_space 
> > >> *vm, struct i915_gem_ww_ctx *ww)
> > >>   * the resv is shared among multiple objects, 
> > >> we still
> > >>   * need the object ref.
> > >>   */
> > >> -   if (dying_vma(vma) ||
> > >> +   if (!i915_gem_object_get_rcu(vma->obj) ||
> Oops, sorry, I had missed the one line change above. After you pointed
> that out, all the 'i915_gem_object_put()' calls now make perfect
> sense. Thanks.
>
> > >>  (ww && 
> > >> (dma_resv_locking_ctx(vma->obj->base.resv) == &ww->ctx))) {
> > >>  __i915_vma_pin(vma);
> > >>  list_add(&vma->evict_link, 
> > >> &locked_eviction_list);
> > >>  continue;
> > >>  }
> > >>
> > >> -   if (!i915_gem_object_trylock(vma->obj, ww))
> > >> +   if (!i915_gem_object_trylock(vma->obj, ww)) {
> > >> +   if (busy_bo) {
> > >> +   *busy_bo = vma->obj; /* holds 
> > >> ref */
> > >> +   ret = -EBUSY;
> > >> +   break;
> > >> +   }
> > >> +   i915_gem_object_put(vma->obj);
> > >>  continue;
> > >> +   }


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsb: DSB fixes/cleanups

2022-12-15 Thread Patchwork
== Series Details ==

Series: drm/i915/dsb: DSB fixes/cleanups
URL   : https://patchwork.freedesktop.org/series/111997/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12511 -> Patchwork_111997v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 40)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@hangcheck:
- {bat-rpls-1}:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/bat-rpls-1/igt@i915_selftest@l...@hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111997v1/bat-rpls-1/igt@i915_selftest@l...@hangcheck.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-pnv-d510:NOTRUN -> [SKIP][3] ([fdo#109271])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111997v1/fi-pnv-d510/igt@kms_chamel...@common-hpd-after-suspend.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_lrc:
- {bat-adln-1}:   [INCOMPLETE][4] ([i915#4983] / [i915#7609]) -> 
[PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/bat-adln-1/igt@i915_selftest@live@gt_lrc.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111997v1/bat-adln-1/igt@i915_selftest@live@gt_lrc.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609


Build changes
-

  * Linux: CI_DRM_12511 -> Patchwork_111997v1

  CI-20190529: 20190529
  CI_DRM_12511: 2f1afd3898412b8487d420921f34fb5340e15e5b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7095: 0d821bca4e1086c96bb8928a0d24e707396e9373 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_111997v1: 2f1afd3898412b8487d420921f34fb5340e15e5b @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

9a5f2a529c40 drm/i915/dsb: Pimp debug/error prints
47578b6c19c9 drm/i915/dsb: Define more DSB registers
fc587cdfac56 drm/i915/dsb: Add mode DSB opcodes
c1b5e1314e49 drm/i915/dsb: Allow the caller to pass in the DSB buffer size
e775c35d82b7 drm/i915/dsb: Introduce intel_dsb_align_tail()
824aa765834d drm/i915/dsb: Handle the indexed vs. not inside the DSB code
a48f1a28eb1e drm/i915/dsb: Improve the indexed reg write checks
20696eca8297 drm/i915/dsb: Extract intel_dsb_emit()
81d01046983e drm/i915/dsb: Extract assert_dsb_has_room()
46dc7a90e7f9 drm/i915/dsb: Fix DSB command buffer size checks
75b4f4a33e04 drm/i915/dsb: Align DSB register writes to 8 bytes
b7671e3b3f22 drm/i915/dsb: Inline DSB_CTRL writes into intel_dsb_commit()
0343d3b3a755 drm/i915/dsb: Stop with the RMW

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dsb: DSB fixes/cleanups

2022-12-15 Thread Patchwork
== Series Details ==

Series: drm/i915/dsb: DSB fixes/cleanups
URL   : https://patchwork.freedesktop.org/series/111997/
State : warning

== Summary ==

Error: dim checkpatch failed
5051d5d03037 drm/i915/dsb: Stop with the RMW
a5525d4aab22 drm/i915/dsb: Inline DSB_CTRL writes into intel_dsb_commit()
ecb9ca56c2fc drm/i915/dsb: Align DSB register writes to 8 bytes
bd96caebe2ba drm/i915/dsb: Fix DSB command buffer size checks
4106472e980c drm/i915/dsb: Extract assert_dsb_has_room()
8da6747f2c2f drm/i915/dsb: Extract intel_dsb_emit()
85956ab12e9a drm/i915/dsb: Improve the indexed reg write checks
3f0ff8f03ef7 drm/i915/dsb: Handle the indexed vs. not inside the DSB code
40a70b0d9cbb drm/i915/dsb: Introduce intel_dsb_align_tail()
dfb4ea142837 drm/i915/dsb: Allow the caller to pass in the DSB buffer size
3faa7075e220 drm/i915/dsb: Add mode DSB opcodes
551e52e82eb0 drm/i915/dsb: Define more DSB registers
-:62: WARNING:LONG_LINE_COMMENT: line length of 105 exceeds 100 columns
#62: FILE: drivers/gpu/drm/i915/i915_reg.h:8144:
+#define   DSB_RM_CLAIM_TIMEOUT_COUNT(x)
REG_FIELD_PREP(DSB_RM_CLAIM_TIMEOUT_COUNT_MASK, (x)) /* clocks */

total: 0 errors, 1 warnings, 0 checks, 56 lines checked
492da2cad714 drm/i915/dsb: Pimp debug/error prints




[Intel-gfx] [PATCH 12/13] drm/i915/dsb: Define more DSB registers

2022-12-15 Thread Ville Syrjala
From: Ville Syrjälä 

Add definitions for more DSB registers. Less annoying spec
trawling when working on the DSB code.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h | 50 +++--
 1 file changed, 48 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ed989e749635..3b0d07880c30 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8103,8 +8103,54 @@ enum skl_power_gate {
 #define DSB_HEAD(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x0)
 #define DSB_TAIL(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x4)
 #define DSB_CTRL(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x8)
-#define   DSB_ENABLE   (1 << 31)
-#define   DSB_STATUS_BUSY  (1 << 0)
+#define   DSB_ENABLE   REG_BIT(31)
+#define   DSB_BUF_REITERATEREG_BIT(29)
+#define   DSB_WAIT_FOR_VBLANK  REG_BIT(28)
+#define   DSB_WAIT_FOR_LINE_IN REG_BIT(27)
+#define   DSB_HALT REG_BIT(16)
+#define   DSB_NON_POSTED   REG_BIT(8)
+#define   DSB_STATUS_BUSY  REG_BIT(0)
+#define DSB_MMIOCTRL(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0xc)
+#define   DSB_MMIO_DEAD_CLOCKS_ENABLE  REG_BIT(31)
+#define   DSB_MMIO_DEAD_CLOCKS_COUNT_MASK  REG_GENMASK(15, 8)
+#define   DSB_MMIO_DEAD_CLOCKS_COUNT(x)
REG_FIELD_PREP(DSB_MMIO_DEAD_CLOCK_COUNT_MASK, (x))
+#define   DSB_MMIO_CYCLES_MASK REG_GENMASK(7, 0)
+#define   DSB_MMIO_CYCLES(x)   REG_FIELD_PREP(DSB_MMIO_CYCLES_MASK, 
(x))
+#define DSB_POLLFUNC(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x10)
+#define   DSB_POLL_ENABLE  REG_BIT(31)
+#define   DSB_POLL_WAIT_MASK   REG_GENMASK(30, 23)
+#define   DSB_POLL_WAIT(x) REG_FIELD_PREP(DSB_POLL_WAIT_MASK, (x)) 
/* usec */
+#define   DSB_POLL_COUNT_MASK  REG_GENMASK(22, 15)
+#define   DSB_POLL_COUNT(x)REG_FIELD_PREP(DSB_POLL_COUNT_MASK, (x))
+#define DSB_DEBUG(pipe, id)_MMIO(DSBSL_INSTANCE(pipe, id) + 0x14)
+#define DSB_POLLMASK(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x1c)
+#define DSB_STATUS(pipe, id)   _MMIO(DSBSL_INSTANCE(pipe, id) + 0x24)
+#define DSB_INTERRUPT(pipe, id)_MMIO(DSBSL_INSTANCE(pipe, id) 
+ 0x28)
+#define   DSB_ATS_FAULT_INT_EN REG_BIT(20)
+#define   DSB_GTT_FAULT_INT_EN REG_BIT(19)
+#define   DSB_RSPTIMEOUT_INT_ENREG_BIT(18)
+#define   DSB_POLL_ERR_INT_EN  REG_BIT(17)
+#define   DSB_PROG_INT_EN  REG_BIT(16)
+#define   DSB_ATS_FAULT_INT_STATUS REG_BIT(4)
+#define   DSB_GTT_FAULT_INT_STATUS REG_BIT(3)
+#define   DSB_RSPTIMEOUT_INT_STATUSREG_BIT(2)
+#define   DSB_POLL_ERR_INT_STATUS  REG_BIT(1)
+#define   DSB_PROG_INT_STATUS  REG_BIT(0)
+#define DSB_CURRENT_HEAD(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x2c)
+#define DSB_RM_TIMEOUT(pipe, id)   _MMIO(DSBSL_INSTANCE(pipe, id) + 0x30)
+#define   DSB_RM_CLAIM_TIMEOUT REG_BIT(31)
+#define   DSB_RM_READY_TIMEOUT REG_BIT(30)
+#define   DSB_RM_CLAIM_TIMEOUT_COUNT_MASK  REG_GENMASK(23, 16)
+#define   DSB_RM_CLAIM_TIMEOUT_COUNT(x)
REG_FIELD_PREP(DSB_RM_CLAIM_TIMEOUT_COUNT_MASK, (x)) /* clocks */
+#define   DSB_RM_READY_TIMEOUT_VALUE_MASK  REG_GENMASK(15, 0)
+#define   DSB_RM_READY_TIMEOUT_VALUE(x)
REG_FIELD_PREP(DSB_RM_READY_TIMEOUT_VALUE, (x)) /* usec */
+#define DSB_RMTIMEOUTREG_CAPTURE(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) 
+ 0x34)
+#define DSB_PMCTRL(pipe, id)   _MMIO(DSBSL_INSTANCE(pipe, id) + 0x38)
+#define DSB_PMCTRL_2(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x3c)
+#define DSB_PF_LN_LOWER(pipe, id)  _MMIO(DSBSL_INSTANCE(pipe, id) + 0x40)
+#define DSB_PF_LN_UPPER(pipe, id)  _MMIO(DSBSL_INSTANCE(pipe, id) + 0x44)
+#define DSB_BUFRPT_CNT(pipe, id)   _MMIO(DSBSL_INSTANCE(pipe, id) + 0x48)
+#define DSB_CHICKEN(pipe, id)  _MMIO(DSBSL_INSTANCE(pipe, id) + 0xf0)
 
 #define CLKREQ_POLICY  _MMIO(0x101038)
 #define  CLKREQ_POLICY_MEM_UP_OVRD REG_BIT(1)
-- 
2.37.4



[Intel-gfx] [PATCH 13/13] drm/i915/dsb: Pimp debug/error prints

2022-12-15 Thread Ville Syrjala
From: Ville Syrjälä 

Print the crtc/DSB id information to make it clear which DSB engine
we're talking about.

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

diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c 
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 96bc117fd6a0..f41146fc84d7 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -88,7 +88,8 @@ static bool assert_dsb_has_room(struct intel_dsb *dsb)
 
/* each instruction is 2 dwords */
return !drm_WARN(&i915->drm, dsb->free_pos > dsb->size - 2,
-"DSB buffer overflow\n");
+"[CRTC:%d:%s] DSB %d buffer overflow\n",
+crtc->base.base.id, crtc->base.name, dsb->id);
 }
 
 static bool is_dsb_busy(struct drm_i915_private *i915, enum pipe pipe,
@@ -232,7 +233,8 @@ void intel_dsb_commit(struct intel_dsb *dsb)
return;
 
if (is_dsb_busy(dev_priv, pipe, dsb->id)) {
-   drm_err(&dev_priv->drm, "DSB engine is busy.\n");
+   drm_err(&dev_priv->drm, "[CRTC:%d:%s] DSB %d is busy\n",
+   crtc->base.base.id, crtc->base.name, dsb->id);
goto reset;
}
 
@@ -250,7 +252,8 @@ void intel_dsb_commit(struct intel_dsb *dsb)
 
if (wait_for(!is_dsb_busy(dev_priv, pipe, dsb->id), 1))
drm_err(&dev_priv->drm,
-   "Timed out waiting for DSB workload completion.\n");
+   "[CRTC:%d:%s] DSB %d timed out waiting for idle\n",
+   crtc->base.base.id, crtc->base.name, dsb->id);
 
 reset:
dsb->free_pos = 0;
@@ -325,7 +328,8 @@ struct intel_dsb *intel_dsb_prepare(struct intel_crtc *crtc,
kfree(dsb);
 out:
drm_info_once(&i915->drm,
- "DSB queue setup failed, will fallback to MMIO for 
display HW programming\n");
+ "[CRTC:%d:%s] DSB %d queue setup failed, will fallback to 
MMIO for display HW programming\n",
+ crtc->base.base.id, crtc->base.name, DSB1);
 
return NULL;
 }
-- 
2.37.4



[Intel-gfx] [PATCH 05/13] drm/i915/dsb: Extract assert_dsb_has_room()

2022-12-15 Thread Ville Syrjala
From: Ville Syrjälä 

Pull the DSB command buffer size checks into a small helper so
we don't have repeat the same thing multiple times.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dsb.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c 
b/drivers/gpu/drm/i915/display/intel_dsb.c
index fbcbf9efd039..6fc7d087a7ca 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -70,6 +70,16 @@ struct intel_dsb {
 #define DSB_BYTE_EN_SHIFT  20
 #define DSB_REG_VALUE_MASK 0xf
 
+static bool assert_dsb_has_room(struct intel_dsb *dsb)
+{
+   struct intel_crtc *crtc = dsb->crtc;
+   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+
+   /* each instruction is 2 dwords */
+   return !drm_WARN(&i915->drm, ALIGN(dsb->free_pos, 2) > DSB_BUF_SIZE / 4 
- 2,
+"DSB buffer overflow\n");
+}
+
 static bool is_dsb_busy(struct drm_i915_private *i915, enum pipe pipe,
enum dsb_id id)
 {
@@ -92,15 +102,11 @@ static bool is_dsb_busy(struct drm_i915_private *i915, 
enum pipe pipe,
 void intel_dsb_indexed_reg_write(struct intel_dsb *dsb,
 i915_reg_t reg, u32 val)
 {
-   struct intel_crtc *crtc = dsb->crtc;
-   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
u32 *buf = dsb->cmd_buf;
u32 reg_val;
 
-   if (drm_WARN_ON(&dev_priv->drm, ALIGN(dsb->free_pos, 2) > DSB_BUF_SIZE 
/ 4 - 2)) {
-   drm_dbg_kms(&dev_priv->drm, "DSB buffer overflow\n");
+   if (!assert_dsb_has_room(dsb))
return;
-   }
 
/*
 * For example the buffer will look like below for 3 dwords for auto
@@ -163,14 +169,10 @@ void intel_dsb_indexed_reg_write(struct intel_dsb *dsb,
 void intel_dsb_reg_write(struct intel_dsb *dsb,
 i915_reg_t reg, u32 val)
 {
-   struct intel_crtc *crtc = dsb->crtc;
-   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
u32 *buf = dsb->cmd_buf;
 
-   if (drm_WARN_ON(&dev_priv->drm, ALIGN(dsb->free_pos, 2) > DSB_BUF_SIZE 
/ 4 - 2)) {
-   drm_dbg_kms(&dev_priv->drm, "DSB buffer overflow\n");
+   if (!assert_dsb_has_room(dsb))
return;
-   }
 
/* Every instruction should be 8 byte aligned. */
dsb->free_pos = ALIGN(dsb->free_pos, 2);
-- 
2.37.4



[Intel-gfx] [PATCH 11/13] drm/i915/dsb: Add mode DSB opcodes

2022-12-15 Thread Ville Syrjala
From: Ville Syrjälä 

Add all the know DSB instruction opcodes.

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

diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c 
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 7c593ec84d41..96bc117fd6a0 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -67,8 +67,16 @@ struct intel_dsb {
 
 /* DSB opcodes. */
 #define DSB_OPCODE_SHIFT   24
+#define DSB_OPCODE_NOOP0x0
 #define DSB_OPCODE_MMIO_WRITE  0x1
+#define DSB_OPCODE_WAIT_USEC   0x2
+#define DSB_OPCODE_WAIT_LINES  0x3
+#define DSB_OPCODE_WAIT_VBLANKS0x4
+#define DSB_OPCODE_WAIT_DSL_IN 0x5
+#define DSB_OPCODE_WAIT_DSL_OUT0x6
+#define DSB_OPCODE_INTERRUPT   0x7
 #define DSB_OPCODE_INDEXED_WRITE   0x9
+#define DSB_OPCODE_POLL0xA
 #define DSB_BYTE_EN0xF
 #define DSB_BYTE_EN_SHIFT  20
 #define DSB_REG_VALUE_MASK 0xf
-- 
2.37.4



[Intel-gfx] [PATCH 10/13] drm/i915/dsb: Allow the caller to pass in the DSB buffer size

2022-12-15 Thread Ville Syrjala
From: Ville Syrjälä 

The caller should more or less know how many DSB commands it
wants to emit into the command buffer, so allow it to specify
the size of the command buffer rather than having the low level
DSB code guess it.

Technically we can emit as many as 134+1033 (for adl+ degamma +
10bit gamma) register writes but thanks to the DSB indexed register
write command we get significant space savings so the current size
estimate of 8KiB (~1024 DSB commands) is sufficient for now.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_color.c |  2 +-
 drivers/gpu/drm/i915/display/intel_dsb.c   | 42 +-
 drivers/gpu/drm/i915/display/intel_dsb.h   |  3 +-
 3 files changed, 29 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 76603357252d..8d97c299e657 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1380,7 +1380,7 @@ void intel_color_prepare_commit(struct intel_crtc_state 
*crtc_state)
/* FIXME DSB has issues loading LUTs, disable it for now */
return;
 
-   crtc_state->dsb = intel_dsb_prepare(crtc);
+   crtc_state->dsb = intel_dsb_prepare(crtc, 1024);
 }
 
 void intel_color_cleanup_commit(struct intel_crtc_state *crtc_state)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c 
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 636c57767f97..7c593ec84d41 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -30,21 +30,24 @@ struct intel_dsb {
struct intel_crtc *crtc;
 
/*
-* free_pos will point the first free entry position
-* and help in calculating tail of command buffer.
+* maximum number of dwords the buffer will hold.
 */
-   int free_pos;
+   unsigned int size;
 
/*
-* ins_start_offset will help to store start address of the dsb
+* free_pos will point the first free dword and
+* help in calculating tail of command buffer.
+*/
+   unsigned int free_pos;
+
+   /*
+* ins_start_offset will help to store start dword of the dsb
 * instuction and help in identifying the batch of auto-increment
 * register.
 */
-   u32 ins_start_offset;
+   unsigned int ins_start_offset;
 };
 
-#define DSB_BUF_SIZE(2 * PAGE_SIZE)
-
 /**
  * DOC: DSB
  *
@@ -76,7 +79,7 @@ static bool assert_dsb_has_room(struct intel_dsb *dsb)
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
 
/* each instruction is 2 dwords */
-   return !drm_WARN(&i915->drm, ALIGN(dsb->free_pos, 2) > DSB_BUF_SIZE / 4 
- 2,
+   return !drm_WARN(&i915->drm, dsb->free_pos > dsb->size - 2,
 "DSB buffer overflow\n");
 }
 
@@ -168,7 +171,7 @@ void intel_dsb_reg_write(struct intel_dsb *dsb,
if (intel_dsb_prev_ins_is_mmio_write(dsb, reg)) {
u32 prev_val = buf[dsb->ins_start_offset + 0];
 
-   buf[dsb->ins_start_offset + 0] = 1; /* size */
+   buf[dsb->ins_start_offset + 0] = 1; /* count */
buf[dsb->ins_start_offset + 1] =
(DSB_OPCODE_INDEXED_WRITE << DSB_OPCODE_SHIFT) |
i915_mmio_reg_offset(reg);
@@ -178,7 +181,7 @@ void intel_dsb_reg_write(struct intel_dsb *dsb,
}
 
buf[dsb->free_pos++] = val;
-   /* Update the size. */
+   /* Update the count */
buf[dsb->ins_start_offset]++;
 
/* if number of data words is odd, then the last dword should 
be 0.*/
@@ -250,6 +253,7 @@ void intel_dsb_commit(struct intel_dsb *dsb)
 /**
  * intel_dsb_prepare() - Allocate, pin and map the DSB command buffer.
  * @crtc: the CRTC
+ * @max_cmds: number of commands we need to fit into command buffer
  *
  * This function prepare the command buffer which is used to store dsb
  * instructions with data.
@@ -257,25 +261,30 @@ void intel_dsb_commit(struct intel_dsb *dsb)
  * Returns:
  * DSB context, NULL on failure
  */
-struct intel_dsb *intel_dsb_prepare(struct intel_crtc *crtc)
+struct intel_dsb *intel_dsb_prepare(struct intel_crtc *crtc,
+   unsigned int max_cmds)
 {
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
-   struct intel_dsb *dsb;
struct drm_i915_gem_object *obj;
-   struct i915_vma *vma;
-   u32 *buf;
intel_wakeref_t wakeref;
+   struct intel_dsb *dsb;
+   struct i915_vma *vma;
+   unsigned int size;
+   u32 *buf;
 
if (!HAS_DSB(i915))
return NULL;
 
-   dsb = kmalloc(sizeof(*dsb), GFP_KERNEL);
+   dsb = kzalloc(sizeof(*dsb), GFP_KERNEL);
if (!dsb)
goto out;
 
wakeref = intel_runtime_pm_get(&i915->runtime_pm);
 
- 

[Intel-gfx] [PATCH 09/13] drm/i915/dsb: Introduce intel_dsb_align_tail()

2022-12-15 Thread Ville Syrjala
From: Ville Syrjälä 

Move the DSB tail cacheline alignment to a helper. No need to pollute
the caller with mundane details like this.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dsb.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c 
b/drivers/gpu/drm/i915/display/intel_dsb.c
index fa4b808a8134..636c57767f97 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -187,6 +187,22 @@ void intel_dsb_reg_write(struct intel_dsb *dsb,
}
 }
 
+static u32 intel_dsb_align_tail(struct intel_dsb *dsb)
+{
+   u32 aligned_tail, tail;
+
+   tail = dsb->free_pos * 4;
+   aligned_tail = ALIGN(tail, CACHELINE_BYTES);
+
+   if (aligned_tail > tail)
+   memset(&dsb->cmd_buf[dsb->free_pos], 0,
+  aligned_tail - tail);
+
+   dsb->free_pos = aligned_tail / 4;
+
+   return aligned_tail;
+}
+
 /**
  * intel_dsb_commit() - Trigger workload execution of DSB.
  * @dsb: DSB context
@@ -200,14 +216,10 @@ void intel_dsb_commit(struct intel_dsb *dsb)
enum pipe pipe = crtc->pipe;
u32 tail;
 
-   if (!(dsb && dsb->free_pos))
+   tail = intel_dsb_align_tail(dsb);
+   if (tail == 0)
return;
 
-   tail = ALIGN(dsb->free_pos * 4, CACHELINE_BYTES);
-   if (tail > dsb->free_pos * 4)
-   memset(&dsb->cmd_buf[dsb->free_pos], 0,
-  (tail - dsb->free_pos * 4));
-
if (is_dsb_busy(dev_priv, pipe, dsb->id)) {
drm_err(&dev_priv->drm, "DSB engine is busy.\n");
goto reset;
-- 
2.37.4



[Intel-gfx] [PATCH 08/13] drm/i915/dsb: Handle the indexed vs. not inside the DSB code

2022-12-15 Thread Ville Syrjala
From: Ville Syrjälä 

The DSB indexed register write insturction is purely an internal
DSB implementation detail, no reason why the caller should have to
know about it. So let's just have the caller emit blind register
writes let the DSB code convert things to an indexed write if/when
multiple writes occur to the same register offset in a row.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_color.c | 45 --
 drivers/gpu/drm/i915/display/intel_dsb.c   | 96 +-
 drivers/gpu/drm/i915/display/intel_dsb.h   |  2 -
 3 files changed, 54 insertions(+), 89 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index d57631b0bb9a..76603357252d 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -847,17 +847,6 @@ static void ilk_lut_write(const struct intel_crtc_state 
*crtc_state,
intel_de_write_fw(i915, reg, val);
 }
 
-static void ilk_lut_write_indexed(const struct intel_crtc_state *crtc_state,
- i915_reg_t reg, u32 val)
-{
-   struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
-
-   if (crtc_state->dsb)
-   intel_dsb_indexed_reg_write(crtc_state->dsb, reg, val);
-   else
-   intel_de_write_fw(i915, reg, val);
-}
-
 static void ilk_load_lut_8(const struct intel_crtc_state *crtc_state,
   const struct drm_property_blob *blob)
 {
@@ -962,8 +951,8 @@ static void bdw_load_lut_10(const struct intel_crtc_state 
*crtc_state,
  prec_index);
 
for (i = 0; i < lut_size; i++)
-   ilk_lut_write_indexed(crtc_state, PREC_PAL_DATA(pipe),
- ilk_lut_10(&lut[i]));
+   ilk_lut_write(crtc_state, PREC_PAL_DATA(pipe),
+ ilk_lut_10(&lut[i]));
 
/*
 * Reset the index, otherwise it prevents the legacy palette to be
@@ -1093,13 +1082,13 @@ static void glk_load_degamma_lut(const struct 
intel_crtc_state *crtc_state,
 * ToDo: Extend to max 7.0. Enable 32 bit input value
 * as compared to just 16 to achieve this.
 */
-   ilk_lut_write_indexed(crtc_state, PRE_CSC_GAMC_DATA(pipe),
- lut[i].green);
+   ilk_lut_write(crtc_state, PRE_CSC_GAMC_DATA(pipe),
+ lut[i].green);
}
 
/* Clamp values > 1.0. */
while (i++ < glk_degamma_lut_size(i915))
-   ilk_lut_write_indexed(crtc_state, PRE_CSC_GAMC_DATA(pipe), 1 << 
16);
+   ilk_lut_write(crtc_state, PRE_CSC_GAMC_DATA(pipe), 1 << 16);
 
ilk_lut_write(crtc_state, PRE_CSC_GAMC_INDEX(pipe), 0);
 }
@@ -1165,10 +1154,10 @@ icl_program_gamma_superfine_segment(const struct 
intel_crtc_state *crtc_state)
for (i = 0; i < 9; i++) {
const struct drm_color_lut *entry = &lut[i];
 
-   ilk_lut_write_indexed(crtc_state, PREC_PAL_MULTI_SEG_DATA(pipe),
- ilk_lut_12p4_ldw(entry));
-   ilk_lut_write_indexed(crtc_state, PREC_PAL_MULTI_SEG_DATA(pipe),
- ilk_lut_12p4_udw(entry));
+   ilk_lut_write(crtc_state, PREC_PAL_MULTI_SEG_DATA(pipe),
+ ilk_lut_12p4_ldw(entry));
+   ilk_lut_write(crtc_state, PREC_PAL_MULTI_SEG_DATA(pipe),
+ ilk_lut_12p4_udw(entry));
}
 
ilk_lut_write(crtc_state, PREC_PAL_MULTI_SEG_INDEX(pipe),
@@ -1204,10 +1193,10 @@ icl_program_gamma_multi_segment(const struct 
intel_crtc_state *crtc_state)
for (i = 1; i < 257; i++) {
entry = &lut[i * 8];
 
-   ilk_lut_write_indexed(crtc_state, PREC_PAL_DATA(pipe),
- ilk_lut_12p4_ldw(entry));
-   ilk_lut_write_indexed(crtc_state, PREC_PAL_DATA(pipe),
- ilk_lut_12p4_udw(entry));
+   ilk_lut_write(crtc_state, PREC_PAL_DATA(pipe),
+ ilk_lut_12p4_ldw(entry));
+   ilk_lut_write(crtc_state, PREC_PAL_DATA(pipe),
+ ilk_lut_12p4_udw(entry));
}
 
/*
@@ -1225,10 +1214,10 @@ icl_program_gamma_multi_segment(const struct 
intel_crtc_state *crtc_state)
for (i = 0; i < 256; i++) {
entry = &lut[i * 8 * 128];
 
-   ilk_lut_write_indexed(crtc_state, PREC_PAL_DATA(pipe),
- ilk_lut_12p4_ldw(entry));
-   ilk_lut_write_indexed(crtc_state, PREC_PAL_DATA(pipe),
- ilk_lut_12p4_udw(entry));
+   ilk_lut_write(crtc_state, PREC_PAL_DATA(pipe),
+ ilk_lut_12p4_ldw(entry));
+   ilk_lut_write(crtc_state, PRE

[Intel-gfx] [PATCH 06/13] drm/i915/dsb: Extract intel_dsb_emit()

2022-12-15 Thread Ville Syrjala
From: Ville Syrjälä 

Extract a small helper to emit a DSB intstruction. Should
become useful if/when we need to start emitting other
instructions besides register writes.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dsb.c | 30 
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c 
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 6fc7d087a7ca..fb20d9ee84a4 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -86,6 +86,22 @@ static bool is_dsb_busy(struct drm_i915_private *i915, enum 
pipe pipe,
return intel_de_read(i915, DSB_CTRL(pipe, id)) & DSB_STATUS_BUSY;
 }
 
+static void intel_dsb_emit(struct intel_dsb *dsb, u32 ldw, u32 udw)
+{
+   u32 *buf = dsb->cmd_buf;
+
+   if (!assert_dsb_has_room(dsb))
+   return;
+
+   /* Every instruction should be 8 byte aligned. */
+   dsb->free_pos = ALIGN(dsb->free_pos, 2);
+
+   dsb->ins_start_offset = dsb->free_pos;
+
+   buf[dsb->free_pos++] = ldw;
+   buf[dsb->free_pos++] = udw;
+}
+
 /**
  * intel_dsb_indexed_reg_write() -Write to the DSB context for auto
  * increment register.
@@ -169,19 +185,13 @@ void intel_dsb_indexed_reg_write(struct intel_dsb *dsb,
 void intel_dsb_reg_write(struct intel_dsb *dsb,
 i915_reg_t reg, u32 val)
 {
-   u32 *buf = dsb->cmd_buf;
-
if (!assert_dsb_has_room(dsb))
return;
 
-   /* Every instruction should be 8 byte aligned. */
-   dsb->free_pos = ALIGN(dsb->free_pos, 2);
-
-   dsb->ins_start_offset = dsb->free_pos;
-   buf[dsb->free_pos++] = val;
-   buf[dsb->free_pos++] = (DSB_OPCODE_MMIO_WRITE  << DSB_OPCODE_SHIFT) |
-  (DSB_BYTE_EN << DSB_BYTE_EN_SHIFT) |
-  i915_mmio_reg_offset(reg);
+   intel_dsb_emit(dsb, val,
+  (DSB_OPCODE_MMIO_WRITE << DSB_OPCODE_SHIFT) |
+  (DSB_BYTE_EN << DSB_BYTE_EN_SHIFT) |
+  i915_mmio_reg_offset(reg));
 }
 
 /**
-- 
2.37.4



[Intel-gfx] [PATCH 04/13] drm/i915/dsb: Fix DSB command buffer size checks

2022-12-15 Thread Ville Syrjala
From: Ville Syrjälä 

free_pos is in dwords, DSB_BUF_SIZE in bytes. Directly
comparing the two is nonsense. Fix it up, and make sure
we also account for the 8byte alignment requirement for
each instruction, and also assume that each instruction
normally eats two dwords.

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

diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c 
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 6abfd0fc541a..fbcbf9efd039 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -97,7 +97,7 @@ void intel_dsb_indexed_reg_write(struct intel_dsb *dsb,
u32 *buf = dsb->cmd_buf;
u32 reg_val;
 
-   if (drm_WARN_ON(&dev_priv->drm, dsb->free_pos >= DSB_BUF_SIZE)) {
+   if (drm_WARN_ON(&dev_priv->drm, ALIGN(dsb->free_pos, 2) > DSB_BUF_SIZE 
/ 4 - 2)) {
drm_dbg_kms(&dev_priv->drm, "DSB buffer overflow\n");
return;
}
@@ -167,7 +167,7 @@ void intel_dsb_reg_write(struct intel_dsb *dsb,
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
u32 *buf = dsb->cmd_buf;
 
-   if (drm_WARN_ON(&dev_priv->drm, dsb->free_pos >= DSB_BUF_SIZE)) {
+   if (drm_WARN_ON(&dev_priv->drm, ALIGN(dsb->free_pos, 2) > DSB_BUF_SIZE 
/ 4 - 2)) {
drm_dbg_kms(&dev_priv->drm, "DSB buffer overflow\n");
return;
}
-- 
2.37.4



[Intel-gfx] [PATCH 07/13] drm/i915/dsb: Improve the indexed reg write checks

2022-12-15 Thread Ville Syrjala
From: Ville Syrjälä 

Currently intel_dsb_indexed_reg_write() just assumes the previus
instructions is also an indexed register write, and thus only
checks the register offset. Make the check more robust by
actually checking the instruction opcode as well.

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

diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c 
b/drivers/gpu/drm/i915/display/intel_dsb.c
index fb20d9ee84a4..fcc3f49c5445 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -102,6 +102,23 @@ static void intel_dsb_emit(struct intel_dsb *dsb, u32 ldw, 
u32 udw)
buf[dsb->free_pos++] = udw;
 }
 
+static bool intel_dsb_prev_ins_is_write(struct intel_dsb *dsb,
+   u32 opcode, i915_reg_t reg)
+{
+   const u32 *buf = dsb->cmd_buf;
+   u32 prev_opcode, prev_reg;
+
+   prev_opcode = buf[dsb->ins_start_offset + 1] >> DSB_OPCODE_SHIFT;
+   prev_reg = buf[dsb->ins_start_offset + 1] & DSB_REG_VALUE_MASK;
+
+   return prev_opcode == opcode && prev_reg == i915_mmio_reg_offset(reg);
+}
+
+static bool intel_dsb_prev_ins_is_indexed_write(struct intel_dsb *dsb, 
i915_reg_t reg)
+{
+   return intel_dsb_prev_ins_is_write(dsb, DSB_OPCODE_INDEXED_WRITE, reg);
+}
+
 /**
  * intel_dsb_indexed_reg_write() -Write to the DSB context for auto
  * increment register.
@@ -119,7 +136,6 @@ void intel_dsb_indexed_reg_write(struct intel_dsb *dsb,
 i915_reg_t reg, u32 val)
 {
u32 *buf = dsb->cmd_buf;
-   u32 reg_val;
 
if (!assert_dsb_has_room(dsb))
return;
@@ -140,8 +156,7 @@ void intel_dsb_indexed_reg_write(struct intel_dsb *dsb,
 * we are writing odd no of dwords, Zeros will be added in the end for
 * padding.
 */
-   reg_val = buf[dsb->ins_start_offset + 1] & DSB_REG_VALUE_MASK;
-   if (reg_val != i915_mmio_reg_offset(reg)) {
+   if (!intel_dsb_prev_ins_is_indexed_write(dsb, reg)) {
/* Every instruction should be 8 byte aligned. */
dsb->free_pos = ALIGN(dsb->free_pos, 2);
 
-- 
2.37.4



[Intel-gfx] [PATCH 02/13] drm/i915/dsb: Inline DSB_CTRL writes into intel_dsb_commit()

2022-12-15 Thread Ville Syrjala
From: Ville Syrjälä 

No point in having these wrappers for a simple DSB_CTRL write.
Inline them into intel_dsb_commit().

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dsb.c | 62 ++--
 1 file changed, 14 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c 
b/drivers/gpu/drm/i915/display/intel_dsb.c
index ebebaf802dee..90a22af30aab 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -76,34 +76,6 @@ static bool is_dsb_busy(struct drm_i915_private *i915, enum 
pipe pipe,
return intel_de_read(i915, DSB_CTRL(pipe, id)) & DSB_STATUS_BUSY;
 }
 
-static bool intel_dsb_enable_engine(struct drm_i915_private *i915,
-   enum pipe pipe, enum dsb_id id)
-{
-   if (is_dsb_busy(i915, pipe, id)) {
-   drm_dbg_kms(&i915->drm, "DSB engine is busy.\n");
-   return false;
-   }
-
-   intel_de_write(i915, DSB_CTRL(pipe, id), DSB_ENABLE);
-   intel_de_posting_read(i915, DSB_CTRL(pipe, id));
-
-   return true;
-}
-
-static bool intel_dsb_disable_engine(struct drm_i915_private *i915,
-enum pipe pipe, enum dsb_id id)
-{
-   if (is_dsb_busy(i915, pipe, id)) {
-   drm_dbg_kms(&i915->drm, "DSB engine is busy.\n");
-   return false;
-   }
-
-   intel_de_write(i915, DSB_CTRL(pipe, id), 0);
-   intel_de_posting_read(i915, DSB_CTRL(pipe, id));
-
-   return true;
-}
-
 /**
  * intel_dsb_indexed_reg_write() -Write to the DSB context for auto
  * increment register.
@@ -223,42 +195,36 @@ void intel_dsb_commit(struct intel_dsb *dsb)
if (!(dsb && dsb->free_pos))
return;
 
-   if (!intel_dsb_enable_engine(dev_priv, pipe, dsb->id))
-   goto reset;
-
-   if (is_dsb_busy(dev_priv, pipe, dsb->id)) {
-   drm_err(&dev_priv->drm,
-   "HEAD_PTR write failed - dsb engine is busy.\n");
-   goto reset;
-   }
-   intel_de_write(dev_priv, DSB_HEAD(pipe, dsb->id),
-  i915_ggtt_offset(dsb->vma));
-
tail = ALIGN(dsb->free_pos * 4, CACHELINE_BYTES);
if (tail > dsb->free_pos * 4)
memset(&dsb->cmd_buf[dsb->free_pos], 0,
   (tail - dsb->free_pos * 4));
 
if (is_dsb_busy(dev_priv, pipe, dsb->id)) {
-   drm_err(&dev_priv->drm,
-   "TAIL_PTR write failed - dsb engine is busy.\n");
+   drm_err(&dev_priv->drm, "DSB engine is busy.\n");
goto reset;
}
-   drm_dbg_kms(&dev_priv->drm,
-   "DSB execution started - head 0x%x, tail 0x%x\n",
-   i915_ggtt_offset(dsb->vma), tail);
+
+   intel_de_write(dev_priv, DSB_CTRL(pipe, dsb->id),
+  DSB_ENABLE);
+   intel_de_write(dev_priv, DSB_HEAD(pipe, dsb->id),
+  i915_ggtt_offset(dsb->vma));
intel_de_write(dev_priv, DSB_TAIL(pipe, dsb->id),
   i915_ggtt_offset(dsb->vma) + tail);
-   if (wait_for(!is_dsb_busy(dev_priv, pipe, dsb->id), 1)) {
+
+   drm_dbg_kms(&dev_priv->drm,
+   "DSB execution started - head 0x%x, tail 0x%x\n",
+   i915_ggtt_offset(dsb->vma),
+   i915_ggtt_offset(dsb->vma) + tail);
+
+   if (wait_for(!is_dsb_busy(dev_priv, pipe, dsb->id), 1))
drm_err(&dev_priv->drm,
"Timed out waiting for DSB workload completion.\n");
-   goto reset;
-   }
 
 reset:
dsb->free_pos = 0;
dsb->ins_start_offset = 0;
-   intel_dsb_disable_engine(dev_priv, pipe, dsb->id);
+   intel_de_write(dev_priv, DSB_CTRL(pipe, dsb->id), 0);
 }
 
 /**
-- 
2.37.4



[Intel-gfx] [PATCH 03/13] drm/i915/dsb: Align DSB register writes to 8 bytes

2022-12-15 Thread Ville Syrjala
From: Ville Syrjälä 

Every DSB instruction has to be 8byte aligned. Make sure
that is the case for the non-indexed register writes as well.
The way this could end up unaligned is we emitted an odd
number of indexed register writes beforehand.

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

diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c 
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 90a22af30aab..6abfd0fc541a 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -172,6 +172,9 @@ void intel_dsb_reg_write(struct intel_dsb *dsb,
return;
}
 
+   /* Every instruction should be 8 byte aligned. */
+   dsb->free_pos = ALIGN(dsb->free_pos, 2);
+
dsb->ins_start_offset = dsb->free_pos;
buf[dsb->free_pos++] = val;
buf[dsb->free_pos++] = (DSB_OPCODE_MMIO_WRITE  << DSB_OPCODE_SHIFT) |
-- 
2.37.4



[Intel-gfx] [PATCH 01/13] drm/i915/dsb: Stop with the RMW

2022-12-15 Thread Ville Syrjala
From: Ville Syrjälä 

We don't want to keep random bits set in DSB_CTRL. Stop the
harmful RMW.

Also flip the reverse & around to appease my ocd.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dsb.c | 22 +++---
 drivers/gpu/drm/i915/i915_reg.h  |  2 +-
 2 files changed, 8 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c 
b/drivers/gpu/drm/i915/display/intel_dsb.c
index 3d63c1bf1e4f..ebebaf802dee 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -73,42 +73,34 @@ struct intel_dsb {
 static bool is_dsb_busy(struct drm_i915_private *i915, enum pipe pipe,
enum dsb_id id)
 {
-   return DSB_STATUS & intel_de_read(i915, DSB_CTRL(pipe, id));
+   return intel_de_read(i915, DSB_CTRL(pipe, id)) & DSB_STATUS_BUSY;
 }
 
 static bool intel_dsb_enable_engine(struct drm_i915_private *i915,
enum pipe pipe, enum dsb_id id)
 {
-   u32 dsb_ctrl;
-
-   dsb_ctrl = intel_de_read(i915, DSB_CTRL(pipe, id));
-   if (DSB_STATUS & dsb_ctrl) {
+   if (is_dsb_busy(i915, pipe, id)) {
drm_dbg_kms(&i915->drm, "DSB engine is busy.\n");
return false;
}
 
-   dsb_ctrl |= DSB_ENABLE;
-   intel_de_write(i915, DSB_CTRL(pipe, id), dsb_ctrl);
-
+   intel_de_write(i915, DSB_CTRL(pipe, id), DSB_ENABLE);
intel_de_posting_read(i915, DSB_CTRL(pipe, id));
+
return true;
 }
 
 static bool intel_dsb_disable_engine(struct drm_i915_private *i915,
 enum pipe pipe, enum dsb_id id)
 {
-   u32 dsb_ctrl;
-
-   dsb_ctrl = intel_de_read(i915, DSB_CTRL(pipe, id));
-   if (DSB_STATUS & dsb_ctrl) {
+   if (is_dsb_busy(i915, pipe, id)) {
drm_dbg_kms(&i915->drm, "DSB engine is busy.\n");
return false;
}
 
-   dsb_ctrl &= ~DSB_ENABLE;
-   intel_de_write(i915, DSB_CTRL(pipe, id), dsb_ctrl);
-
+   intel_de_write(i915, DSB_CTRL(pipe, id), 0);
intel_de_posting_read(i915, DSB_CTRL(pipe, id));
+
return true;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cef9418beec0..ed989e749635 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8104,7 +8104,7 @@ enum skl_power_gate {
 #define DSB_TAIL(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x4)
 #define DSB_CTRL(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x8)
 #define   DSB_ENABLE   (1 << 31)
-#define   DSB_STATUS   (1 << 0)
+#define   DSB_STATUS_BUSY  (1 << 0)
 
 #define CLKREQ_POLICY  _MMIO(0x101038)
 #define  CLKREQ_POLICY_MEM_UP_OVRD REG_BIT(1)
-- 
2.37.4



[Intel-gfx] [PATCH 00/13] drm/i915/dsb: DSB fixes/cleanups

2022-12-15 Thread Ville Syrjala
From: Ville Syrjälä 

Bunch of DSB related fixes/refactoring/etc.

Ville Syrjälä (13):
  drm/i915/dsb: Stop with the RMW
  drm/i915/dsb: Inline DSB_CTRL writes into intel_dsb_commit()
  drm/i915/dsb: Align DSB register writes to 8 bytes
  drm/i915/dsb: Fix DSB command buffer size checks
  drm/i915/dsb: Extract assert_dsb_has_room()
  drm/i915/dsb: Extract intel_dsb_emit()
  drm/i915/dsb: Improve the indexed reg write checks
  drm/i915/dsb: Handle the indexed vs. not inside the DSB code
  drm/i915/dsb: Introduce intel_dsb_align_tail()
  drm/i915/dsb: Allow the caller to pass in the DSB buffer size
  drm/i915/dsb: Add mode DSB opcodes
  drm/i915/dsb: Define more DSB registers
  drm/i915/dsb: Pimp debug/error prints

 drivers/gpu/drm/i915/display/intel_color.c |  47 ++--
 drivers/gpu/drm/i915/display/intel_dsb.c   | 268 ++---
 drivers/gpu/drm/i915/display/intel_dsb.h   |   5 +-
 drivers/gpu/drm/i915/i915_reg.h|  50 +++-
 4 files changed, 202 insertions(+), 168 deletions(-)

-- 
2.37.4



Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: ratelimit errors in display engine irq (rev2)

2022-12-15 Thread Lucas De Marchi

On Thu, Dec 15, 2022 at 08:39:47PM +, Patchwork wrote:

== Series Details ==

Series: drm/i915: ratelimit errors in display engine irq (rev2)
URL   : https://patchwork.freedesktop.org/series/111951/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12511 -> Patchwork_111951v2


Summary
---

 **FAILURE**

 Serious unknown changes coming with Patchwork_111951v2 absolutely need to be
 verified manually.

 If you think the reported changes have nothing to do with the changes
 introduced in Patchwork_111951v2, 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_111951v2/index.html

Participating hosts (40 -> 40)
--

 No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

 * igt@kms_pipe_crc_basic@nonblocking-crc:
   - fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][1]
  [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111951v2/fi-kbl-soraka/igt@kms_pipe_crc_ba...@nonblocking-crc.html


Unrelated change

Lucas De Marchi




Known issues


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

### IGT changes ###

 Issues hit 

 * igt@kms_chamelium@common-hpd-after-suspend:
   - fi-pnv-d510:NOTRUN -> [SKIP][2] ([fdo#109271])
  [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111951v2/fi-pnv-d510/igt@kms_chamel...@common-hpd-after-suspend.html


 Possible fixes 

 * igt@gem_exec_suspend@basic-s3@smem:
   - {bat-rpls-1}:   [DMESG-WARN][3] ([i915#6687]) -> [PASS][4]
  [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
  [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111951v2/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html

 * igt@i915_selftest@live@gt_lrc:
   - {bat-adln-1}:   [INCOMPLETE][5] ([i915#4983] / [i915#7609]) -> 
[PASS][6]
  [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/bat-adln-1/igt@i915_selftest@live@gt_lrc.html
  [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111951v2/bat-adln-1/igt@i915_selftest@live@gt_lrc.html

 * igt@i915_selftest@live@slpc:
   - {bat-rpls-1}:   [DMESG-FAIL][7] ([i915#6367]) -> [PASS][8]
  [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/bat-rpls-1/igt@i915_selftest@l...@slpc.html
  [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111951v2/bat-rpls-1/igt@i915_selftest@l...@slpc.html


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

 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
 [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
 [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
 [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
 [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
 [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
 [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609


Build changes
-

 * Linux: CI_DRM_12511 -> Patchwork_111951v2

 CI-20190529: 20190529
 CI_DRM_12511: 2f1afd3898412b8487d420921f34fb5340e15e5b @ 
git://anongit.freedesktop.org/gfx-ci/linux
 IGT_7095: 0d821bca4e1086c96bb8928a0d24e707396e9373 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
 Patchwork_111951v2: 2f1afd3898412b8487d420921f34fb5340e15e5b @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

f635e7ac7aa5 drm/i915: ratelimit errors in display engine irq

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: Add initial gt workarounds

2022-12-15 Thread Patchwork
== Series Details ==

Series: drm/i915/mtl: Add initial gt workarounds
URL   : https://patchwork.freedesktop.org/series/111994/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12511 -> Patchwork_111994v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 39)
--

  Missing(1): bat-atsm-1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[PASS][1] -> [FAIL][2] ([i915#7229])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111994v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html

  * igt@i915_selftest@live@workarounds:
- bat-adlp-4: [PASS][3] -> [INCOMPLETE][4] ([i915#4983])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/bat-adlp-4/igt@i915_selftest@l...@workarounds.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111994v1/bat-adlp-4/igt@i915_selftest@l...@workarounds.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-pnv-d510:NOTRUN -> [SKIP][5] ([fdo#109271])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111994v1/fi-pnv-d510/igt@kms_chamel...@common-hpd-after-suspend.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- {bat-rpls-1}:   [DMESG-WARN][6] ([i915#6687]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111994v1/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@gt_lrc:
- {bat-adln-1}:   [INCOMPLETE][8] ([i915#4983] / [i915#7609]) -> 
[PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/bat-adln-1/igt@i915_selftest@live@gt_lrc.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111994v1/bat-adln-1/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@requests:
- {bat-rpls-2}:   [INCOMPLETE][10] ([i915#4983] / [i915#6257]) -> 
[PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/bat-rpls-2/igt@i915_selftest@l...@requests.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111994v1/bat-rpls-2/igt@i915_selftest@l...@requests.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
  [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
  [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229
  [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609


Build changes
-

  * Linux: CI_DRM_12511 -> Patchwork_111994v1

  CI-20190529: 20190529
  CI_DRM_12511: 2f1afd3898412b8487d420921f34fb5340e15e5b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7095: 0d821bca4e1086c96bb8928a0d24e707396e9373 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_111994v1: 2f1afd3898412b8487d420921f34fb5340e15e5b @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

52546a64da53 drm/i915/mtl: Add initial gt workarounds

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/mtl: Add initial gt workarounds

2022-12-15 Thread Patchwork
== Series Details ==

Series: drm/i915/mtl: Add initial gt workarounds
URL   : https://patchwork.freedesktop.org/series/111994/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/mtl: Add initial gt workarounds

2022-12-15 Thread Patchwork
== Series Details ==

Series: drm/i915/mtl: Add initial gt workarounds
URL   : https://patchwork.freedesktop.org/series/111994/
State : warning

== Summary ==

Error: dim checkpatch failed
782c85c8339a drm/i915/mtl: Add initial gt workarounds
-:351: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__i915' - possible 
side-effects?
#351: FILE: drivers/gpu/drm/i915/i915_drv.h:738:
+#define IS_MTL_GRAPHICS_STEP(__i915, variant, since, until) \
+   (IS_SUBPLATFORM(__i915, INTEL_METEORLAKE, INTEL_SUBPLATFORM_##variant) 
&& \
+IS_GRAPHICS_STEP(__i915, since, until))

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




[Intel-gfx] [PATCH v2] drm/i915/mtl: Add initial gt workarounds

2022-12-15 Thread Matt Atwood
From: Matt Roper 

This patch introduces initial gt workarounds for the MTL platform.

v2: drop redundant/stale comments specifying wa platforms affected
(Lucas). Drop Wa_22011802037 for MTL.

Bspec: 66622

Signed-off-by: Matt Atwood 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |   6 +-
 .../drm/i915/gt/intel_execlists_submission.c  |   6 +-
 drivers/gpu/drm/i915/gt/intel_gt_mcr.c|  11 +-
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   5 +
 drivers/gpu/drm/i915/gt/intel_workarounds.c   | 115 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc.c|   9 +-
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c |   8 +-
 drivers/gpu/drm/i915/i915_drv.h   |   4 +
 drivers/gpu/drm/i915/intel_device_info.c  |   6 +
 9 files changed, 128 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 99c4b866addd..e3f30bdf7e61 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1494,10 +1494,12 @@ static int __intel_engine_stop_cs(struct 
intel_engine_cs *engine,
intel_uncore_write_fw(uncore, mode, _MASKED_BIT_ENABLE(STOP_RING));
 
/*
-* Wa_22011802037 : gen11, gen12, Prior to doing a reset, ensure CS is
+* Wa_22011802037 : Prior to doing a reset, ensure CS is
 * stopped, set ring stop bit and prefetch disable bit to halt CS
 */
-   if (IS_GRAPHICS_VER(engine->i915, 11, 12))
+   if (IS_MTL_GRAPHICS_STEP(engine->i915, M, STEP_A0, STEP_B0) ||
+   (GRAPHICS_VER(engine->i915) >= 11 &&
+   GRAPHICS_VER_FULL(engine->i915) < IP_VER(12, 70)))
intel_uncore_write_fw(uncore, RING_MODE_GEN7(engine->mmio_base),
  
_MASKED_BIT_ENABLE(GEN12_GFX_PREFETCH_DISABLE));
 
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 49a8f10d76c7..c14476c777cc 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -2989,10 +2989,12 @@ static void execlists_reset_prepare(struct 
intel_engine_cs *engine)
intel_engine_stop_cs(engine);
 
/*
-* Wa_22011802037:gen11/gen12: In addition to stopping the cs, we need
+* Wa_22011802037: In addition to stopping the cs, we need
 * to wait for any pending mi force wakeups
 */
-   if (IS_GRAPHICS_VER(engine->i915, 11, 12))
+   if (IS_MTL_GRAPHICS_STEP(engine->i915, M, STEP_A0, STEP_B0) ||
+   (GRAPHICS_VER(engine->i915) >= 11 &&
+   GRAPHICS_VER_FULL(engine->i915) < IP_VER(12, 70)))
intel_engine_wait_for_pending_mi_fw(engine);
 
engine->execlists.reset_ccid = active_ccid(engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c 
b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
index 41a237509dcf..4127830c33ca 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
@@ -164,8 +164,15 @@ void intel_gt_mcr_init(struct intel_gt *gt)
if (MEDIA_VER(i915) >= 13 && gt->type == GT_MEDIA) {
gt->steering_table[OADDRM] = xelpmp_oaddrm_steering_table;
} else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) {
-   fuse = REG_FIELD_GET(GT_L3_EXC_MASK,
-intel_uncore_read(gt->uncore, XEHP_FUSE4));
+   /* Wa_14016747170 */
+   if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
+   IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0))
+   fuse = REG_FIELD_GET(MTL_GT_L3_EXC_MASK,
+intel_uncore_read(gt->uncore,
+  
MTL_GT_ACTIVITY_FACTOR));
+   else
+   fuse = REG_FIELD_GET(GT_L3_EXC_MASK,
+intel_uncore_read(gt->uncore, 
XEHP_FUSE4));
 
/*
 * Despite the register field being named "exclude mask" the
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index f8eb807b56f9..470d6feb456a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -414,6 +414,7 @@
 #define   TBIMR_FAST_CLIP  REG_BIT(5)
 
 #define VFLSKPDMCR_REG(0x62a8)
+#define   VF_PREFETCH_TLB_DIS  REG_BIT(5)
 #define   DIS_OVER_FETCH_CACHE REG_BIT(1)
 #define   DIS_MULT_MISS_RD_SQUASH  REG_BIT(0)
 
@@ -1535,6 +1536,10 @@
 
 #define MTL_MEDIA_MC6  _MMIO(0x138048)
 
+/* Wa_14016747170:mtl-p[a0], mtl-m[a0] */
+#define MTL_GT_ACTIVITY_FACTOR _MMIO(0x138010)
+#define   MTL_GT_L3_EXC_MASK   REG_GENMASK(5,

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hwmon: Display clamped PL1 limit (rev2)

2022-12-15 Thread Patchwork
== Series Details ==

Series: drm/i915/hwmon: Display clamped PL1 limit (rev2)
URL   : https://patchwork.freedesktop.org/series/111981/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12511 -> Patchwork_111981v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 39)
--

  Missing(1): fi-rkl-11600 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[PASS][1] -> [FAIL][2] ([i915#7229])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111981v2/fi-pnv-d510/igt@gem_exec_gttf...@basic.html

  * igt@gem_exec_suspend@basic-s0@smem:
- fi-icl-u2:  [PASS][3] -> [DMESG-WARN][4] ([i915#2867]) +1 similar 
issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/fi-icl-u2/igt@gem_exec_suspend@basic...@smem.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111981v2/fi-icl-u2/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@execlists:
- fi-kbl-soraka:  [PASS][5] -> [INCOMPLETE][6] ([i915#7156])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111981v2/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka:  [PASS][7] -> [DMESG-FAIL][8] ([i915#5334])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111981v2/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-pnv-d510:NOTRUN -> [SKIP][9] ([fdo#109271])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111981v2/fi-pnv-d510/igt@kms_chamel...@common-hpd-after-suspend.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- {bat-rpls-1}:   [DMESG-WARN][10] ([i915#6687]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111981v2/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@gt_lrc:
- {bat-adln-1}:   [INCOMPLETE][12] ([i915#4983] / [i915#7609]) -> 
[PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/bat-adln-1/igt@i915_selftest@live@gt_lrc.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111981v2/bat-adln-1/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@requests:
- {bat-rpls-2}:   [INCOMPLETE][14] ([i915#4983] / [i915#6257]) -> 
[PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/bat-rpls-2/igt@i915_selftest@l...@requests.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111981v2/bat-rpls-2/igt@i915_selftest@l...@requests.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
  [i915#6794]: https://gitlab.freedesktop.org/drm/intel/issues/6794
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7156]: https://gitlab.freedesktop.org/drm/intel/issues/7156
  [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229
  [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609


Build changes
-

  * Linux: CI_DRM_12511 -> Patchwork_111981v2

  CI-20190529: 20190529
  CI_DRM_12511: 2f1afd3898412b8487d420921f34fb5340e15e5b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7095: 0d821bca4e1086c96bb8928a0d24e707396e9373 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_111981v2: 2f1afd3898412b8487d420921f34fb5340e15e5b @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

e686d391e016 dr

[Intel-gfx] ✗ Fi.CI.BUILD: failure for fix dell wyse 3040 poweroff

2022-12-15 Thread Patchwork
== Series Details ==

Series: fix dell wyse 3040 poweroff
URL   : https://patchwork.freedesktop.org/series/111987/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/111987/revisions/1/mbox/ not 
applied
Applying: fix dell wyse 3040 poweroff
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/display/intel_quirks.c
M   drivers/gpu/drm/i915/i915_driver.c
M   drivers/gpu/drm/i915/i915_drv.h
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/i915_drv.h
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_drv.h
Auto-merging drivers/gpu/drm/i915/i915_driver.c
Auto-merging drivers/gpu/drm/i915/display/intel_quirks.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 fix dell wyse 3040 poweroff
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".




[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: ratelimit errors in display engine irq (rev2)

2022-12-15 Thread Patchwork
== Series Details ==

Series: drm/i915: ratelimit errors in display engine irq (rev2)
URL   : https://patchwork.freedesktop.org/series/111951/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12511 -> Patchwork_111951v2


Summary
---

  **FAILURE**

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

Participating hosts (40 -> 40)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_pipe_crc_basic@nonblocking-crc:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111951v2/fi-kbl-soraka/igt@kms_pipe_crc_ba...@nonblocking-crc.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-pnv-d510:NOTRUN -> [SKIP][2] ([fdo#109271])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111951v2/fi-pnv-d510/igt@kms_chamel...@common-hpd-after-suspend.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- {bat-rpls-1}:   [DMESG-WARN][3] ([i915#6687]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111951v2/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@gt_lrc:
- {bat-adln-1}:   [INCOMPLETE][5] ([i915#4983] / [i915#7609]) -> 
[PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/bat-adln-1/igt@i915_selftest@live@gt_lrc.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111951v2/bat-adln-1/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@slpc:
- {bat-rpls-1}:   [DMESG-FAIL][7] ([i915#6367]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12511/bat-rpls-1/igt@i915_selftest@l...@slpc.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111951v2/bat-rpls-1/igt@i915_selftest@l...@slpc.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609


Build changes
-

  * Linux: CI_DRM_12511 -> Patchwork_111951v2

  CI-20190529: 20190529
  CI_DRM_12511: 2f1afd3898412b8487d420921f34fb5340e15e5b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7095: 0d821bca4e1086c96bb8928a0d24e707396e9373 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_111951v2: 2f1afd3898412b8487d420921f34fb5340e15e5b @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

f635e7ac7aa5 drm/i915: ratelimit errors in display engine irq

== Logs ==

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


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

2022-12-15 Thread Rodrigo Vivi
Hi Dave and Daniel,

In case you end up sending more stuff towards 6.2-rc1,
please consider sending these fixes below.

The migrate related fixes seems to be the most important
ones, but also I don't believe it looks so critical that
it couldn't wait for the -rc2.

Here goes drm-intel-next-fixes-2022-12-15:
- Documentation fixe (Matt, Miaoqian)
- OA-perf related fix (Umesh)
- VLV/CHV HDMI/DP audio fix (Ville)
- Display DDI/Transcoder fix (Khaled)
- Migrate fixes (Chris, Matt)

Thanks,
Rodrigo.

The following changes since commit 66efff515a6500d4b4976fbab3bee8b92a1137fb:

  Merge tag 'amd-drm-next-6.2-2022-12-07' of 
https://gitlab.freedesktop.org/agd5f/linux into drm-next (2022-12-09 12:08:33 
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/drm-intel-next-fixes-2022-12-15

for you to fetch changes up to ad0fca2dceeab8fdd8e1135f4b4ef2dc46c2ead9:

  drm/i915/ttm: consider CCS for backup objects (2022-12-14 12:56:58 -0500)


- Documentation fixe (Matt, Miaoqian)
- OA-perf related fix (Umesh)
- VLV/CHV HDMI/DP audio fix (Ville)
- Display DDI/Transcoder fix (Khaled)
- Migrate fixes (Chris, Matt)


Chris Wilson (1):
  drm/i915/migrate: Account for the reserved_space

Khaled Almahallawy (1):
  drm/i915/display: Don't disable DDI/Transcoder when setting phy test 
pattern

Matt Roper (1):
  drm/i915/gt: Correct kerneldoc for intel_gt_mcr_wait_for_reg()

Matthew Auld (2):
  drm/i915/migrate: fix corner case in CCS aux copying
  drm/i915/ttm: consider CCS for backup objects

Miaoqian Lin (1):
  drm/i915: Fix documentation for intel_uncore_forcewake_put__locked

Umesh Nerlige Ramappa (1):
  drm/i915/perf: Do not parse context image for HSW

Ville Syrjälä (1):
  drm/i915: Fix VLV/CHV HDMI/DP audio enable

 drivers/gpu/drm/i915/display/g4x_dp.c|  4 +-
 drivers/gpu/drm/i915/display/g4x_hdmi.c  | 25 +++---
 drivers/gpu/drm/i915/display/intel_dp.c  | 59 
 drivers/gpu/drm/i915/gem/i915_gem_object.c   |  3 ++
 drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 10 ++--
 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c   | 18 +++-
 drivers/gpu/drm/i915/gt/intel_gt_mcr.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_migrate.c  | 53 -
 drivers/gpu/drm/i915/i915_perf.c |  6 ++-
 drivers/gpu/drm/i915/intel_uncore.c  |  4 +-
 10 files changed, 96 insertions(+), 88 deletions(-)


[Intel-gfx] [PATCH RFC] fix dell wyse 3040 poweroff

2022-12-15 Thread Alexey Lukyanchuk
Dell wyse 3040 cat't poweroff aftet kernel 5.11.
It happens  because i915_driver_shutdown function.
Disabling of this function mitigate this problem.

Fixes: 440b354f3 ("drivers/gpu/drm:power off troubles on dell wyse 3040") 
Signed-off-by: Alexey Lukyanchuk  
---
There is trouble with i915_driver_shutdown function. After some diving I found 
that trouble looks like race condition in drm_atomic_get_connector_state 
function (drivers/gpu/drm/drm_atomic.c), maybe it linked to iterators. Now I 
fully exclude i915_driver_shutdown for wyse 3040 device.

Can any one comment on this one please ? 
---
 drivers/gpu/drm/i915/display/intel_quirks.c | 25 +
 drivers/gpu/drm/i915/i915_driver.c  |  3 +++
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 3 files changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c 
b/drivers/gpu/drm/i915/display/intel_quirks.c
index e415cd7c0..a6a549d48 100644
--- a/drivers/gpu/drm/i915/display/intel_quirks.c
+++ b/drivers/gpu/drm/i915/display/intel_quirks.c
@@ -60,6 +60,12 @@ static void quirk_no_pps_backlight_power_hook(struct 
drm_i915_private *i915)
drm_info(&i915->drm, "Applying no pps backlight power quirk\n");
 }
 
+static void quirk_wyse_3040_shutdown_fix(struct drm_i915_private *i915)
+{
+   i915->quirks |= QUIRK_WYSE_3040_SHUTDOWN_FIX;
+   drm_info(&i915->drm, "Applying wyse 3040 shutdown fix\n");
+}
+
 struct intel_quirk {
int device;
int subsystem_vendor;
@@ -85,6 +91,12 @@ static int intel_dmi_no_pps_backlight(const struct 
dmi_system_id *id)
return 1;
 }
 
+static int wyse_3040_shutdown_fix(const struct dmi_system_id *id)
+{
+   DRM_INFO("This device need help with poweroff %s\n", id->ident);
+   return 1;
+}
+
 static const struct intel_dmi_quirk intel_dmi_quirks[] = {
{
.dmi_id_list = &(const struct dmi_system_id[]) {
@@ -131,6 +143,19 @@ static const struct intel_dmi_quirk intel_dmi_quirks[] = {
},
.hook = quirk_no_pps_backlight_power_hook,
},
+   {
+   .dmi_id_list = &(const struct dmi_system_id[]) {
+   {
+   .callback = wyse_3040_shutdown_fix,
+   .ident = "Dell Inc. 0G56C0",
+   .matches = {DMI_EXACT_MATCH(DMI_BOARD_VENDOR, 
"Dell Inc."),
+   DMI_EXACT_MATCH(DMI_BOARD_NAME, 
"0G56C0"),
+   },
+   },
+   { }
+   },
+   .hook = quirk_wyse_3040_shutdown_fix,
+   },
 };
 
 static struct intel_quirk intel_quirks[] = {
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index deb8a8b76..af60fb79a 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1079,6 +1079,9 @@ static void intel_shutdown_encoders(struct 
drm_i915_private *dev_priv)
 
 void i915_driver_shutdown(struct drm_i915_private *i915)
 {
+   if (!(i915->quirks & QUIRK_WYSE_3040_SHUTDOWN_FIX))
+   return;
+
disable_rpm_wakeref_asserts(&i915->runtime_pm);
intel_runtime_pm_disable(&i915->runtime_pm);
intel_power_domains_disable(i915);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 086bbe894..fdd6866e7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -200,6 +200,7 @@ struct drm_i915_display_funcs {
 #define QUIRK_INCREASE_T12_DELAY (1<<6)
 #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
 #define QUIRK_NO_PPS_BACKLIGHT_POWER_HOOK (1<<8)
+#define QUIRK_WYSE_3040_SHUTDOWN_FIX (1<<9)
 
 struct i915_suspend_saved_registers {
u32 saveDSPARB;
-- 
2.25.1



[Intel-gfx] [PATCH 1/5] Renaming weak prng invocations - prandom_bytes_state, prandom_u32_state

2022-12-15 Thread david . keisarschm
From: David 

Since the two functions
 prandom_byte_state and prandom_u32_state
 use the weak prng prandom_u32,
 we added the prefix predictable_rng,
 to their signatures so it is clear they are weak.

Signed-off-by: David 
---
 arch/x86/mm/kaslr.c   |  2 +-
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |  2 +-
 .../i915/gem/selftests/i915_gem_client_blt.c  |  2 +-
 .../i915/gem/selftests/i915_gem_coherency.c   |  2 +-
 .../drm/i915/gem/selftests/i915_gem_context.c |  2 +-
 drivers/gpu/drm/i915/gt/selftest_lrc.c|  2 +-
 drivers/gpu/drm/i915/gt/selftest_migrate.c|  2 +-
 drivers/gpu/drm/i915/gt/selftest_timeline.c   |  4 +-
 drivers/gpu/drm/i915/selftests/i915_random.c  |  4 +-
 drivers/gpu/drm/i915/selftests/i915_random.h  |  4 +-
 drivers/gpu/drm/i915/selftests/i915_syncmap.c |  4 +-
 .../drm/i915/selftests/intel_memory_region.c  | 10 ++---
 drivers/gpu/drm/i915/selftests/scatterlist.c  |  4 +-
 drivers/gpu/drm/lib/drm_random.c  |  2 +-
 drivers/mtd/tests/oobtest.c   | 10 ++---
 drivers/mtd/tests/pagetest.c  | 12 +++---
 drivers/mtd/tests/subpagetest.c   | 12 +++---
 drivers/scsi/fcoe/fcoe_ctlr.c |  2 +-
 include/linux/prandom.h   |  6 +--
 kernel/bpf/core.c |  2 +-
 lib/interval_tree_test.c  |  6 +--
 lib/random32.c| 42 +--
 lib/rbtree_test.c |  4 +-
 lib/test_bpf.c|  2 +-
 lib/test_parman.c |  2 +-
 lib/test_scanf.c  |  8 ++--
 mm/slab.c |  2 +-
 mm/slab_common.c  |  2 +-
 28 files changed, 79 insertions(+), 79 deletions(-)

diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index 557f0fe25..66c17b449 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -123,7 +123,7 @@ void __init kernel_randomize_memory(void)
 * available.
 */
entropy = remain_entropy / (ARRAY_SIZE(kaslr_regions) - i);
-   prandom_bytes_state(&rand_state, &rand, sizeof(rand));
+   predictable_rng_prandom_bytes_state(&rand_state, &rand, 
sizeof(rand));
entropy = (rand % (entropy + 1)) & PUD_MASK;
vaddr += entropy;
*kaslr_regions[i].base = vaddr;
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c 
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index c570cf780..f698d58e4 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1294,7 +1294,7 @@ static u32 igt_random_size(struct rnd_state *prng,
GEM_BUG_ON(min_page_size > max_page_size);
 
mask = ((max_page_size << 1ULL) - 1) & PAGE_MASK;
-   size = prandom_u32_state(prng) & mask;
+   size = predictable_rng_prandom_u32_state(prng) & mask;
if (size < min_page_size)
size |= min_page_size;
 
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
index 9a6a6b5b7..039f17b6b 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
@@ -630,7 +630,7 @@ static int tiled_blits_prepare(struct tiled_blits *t,
 
/* Use scratch to fill objects */
for (i = 0; i < ARRAY_SIZE(t->buffers); i++) {
-   fill_scratch(t, map, prandom_u32_state(prng));
+   fill_scratch(t, map, predictable_rng_prandom_u32_state(prng));
GEM_BUG_ON(verify_buffer(t, &t->scratch, prng));
 
err = tiled_blit(t,
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
index a666d7e61..24cc7e6d4 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
@@ -371,7 +371,7 @@ static int igt_gem_coherency(void *arg)
 
i915_random_reorder(offsets, 
ncachelines, &prng);
for (n = 0; n < count; n++)
-   values[n] = 
prandom_u32_state(&prng);
+   values[n] = 
predictable_rng_prandom_u32_state(&prng);
 
for (n = 0; n < count; n++) {
err = over->set(&ctx, 
offsets[n], ~values[n]);
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index c6ad67b90..6e437a1d6 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -1407,7 +1407,7 @@ static int igt_

Re: [Intel-gfx] [PATCH 1/5] Renaming weak prng invocations - prandom_bytes_state, prandom_u32_state

2022-12-15 Thread Eric Dumazet
On Wed, Dec 14, 2022 at 1:34 PM Stanislaw Gruszka
 wrote:
>
> On Mon, Dec 12, 2022 at 03:35:20PM +0100, Jason A. Donenfeld wrote:
> > Please CC me on future revisions.
> >
> > As of 6.2, the prandom namespace is *only* for predictable randomness.
> > There's no need to rename anything. So nack on this patch 1/5.
>
> It is not obvious (for casual developers like me) that p in prandom
> stands for predictable. Some renaming would be useful IMHO.

Renaming makes backports more complicated, because stable teams will
have to 'undo' name changes.
Stable teams are already overwhelmed by the amount of backports, and
silly merge conflicts.

Take another example :

u64 timecounter_read(struct timecounter *tc)

You would think this function would read the timecounter, right ?

Well, it _updates_ many fields from @tc, so a 'better name' would also
be useful.

linux kernel is not for casual readers.


Re: [Intel-gfx] [PATCH 6/9] drm/qxl: stop using ttm_bo_wait

2022-12-15 Thread Dave Airlie
Acked-by: Dave Airlie 

On Fri, 16 Dec 2022 at 00:20, Christian König
 wrote:
>
> Am 25.11.22 um 11:21 schrieb Christian König:
> > TTM is just wrapping core DMA functionality here, remove the mid-layer.
> > No functional change.
>
> Any objections to this guys?
>
> I'm basically just following a suggestion from Daniel here and it
> already triggered a discussion about the timeout for i915.
>
> Thanks,
> Christian.
>
> >
> > Signed-off-by: Christian König 
> > ---
> >   drivers/gpu/drm/qxl/qxl_cmd.c | 16 ++--
> >   1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/qxl/qxl_cmd.c b/drivers/gpu/drm/qxl/qxl_cmd.c
> > index 63aa96a69752..281edab518cd 100644
> > --- a/drivers/gpu/drm/qxl/qxl_cmd.c
> > +++ b/drivers/gpu/drm/qxl/qxl_cmd.c
> > @@ -579,7 +579,7 @@ void qxl_surface_evict(struct qxl_device *qdev, struct 
> > qxl_bo *surf, bool do_upd
> >
> >   static int qxl_reap_surf(struct qxl_device *qdev, struct qxl_bo *surf, 
> > bool stall)
> >   {
> > - int ret;
> > + long ret;
> >
> >   ret = qxl_bo_reserve(surf);
> >   if (ret)
> > @@ -588,7 +588,19 @@ static int qxl_reap_surf(struct qxl_device *qdev, 
> > struct qxl_bo *surf, bool stal
> >   if (stall)
> >   mutex_unlock(&qdev->surf_evict_mutex);
> >
> > - ret = ttm_bo_wait(&surf->tbo, true, !stall);
> > + if (stall) {
> > + ret = dma_resv_wait_timeout(surf->tbo.base.resv,
> > + DMA_RESV_USAGE_BOOKKEEP, true,
> > + 15 * HZ);
> > + if (ret > 0)
> > + ret = 0;
> > + else if (ret == 0)
> > + ret = -EBUSY;
> > + } else {
> > + ret = dma_resv_test_signaled(surf->tbo.base.resv,
> > +  DMA_RESV_USAGE_BOOKKEEP);
> > + ret = ret ? -EBUSY : 0;
> > + }
> >
> >   if (stall)
> >   mutex_lock(&qdev->surf_evict_mutex);
>


Re: [Intel-gfx] [PATCH] drm/i915/gt: Reset twice

2022-12-15 Thread Rodrigo Vivi
On Wed, Dec 14, 2022 at 11:37:19PM +0100, Andi Shyti wrote:
> Hi Rodrigo,
> 
> On Tue, Dec 13, 2022 at 01:18:48PM +, Vivi, Rodrigo wrote:
> > On Tue, 2022-12-13 at 00:08 +0100, Andi Shyti wrote:
> > > Hi Rodrigo,
> > > 
> > > On Mon, Dec 12, 2022 at 11:55:10AM -0500, Rodrigo Vivi wrote:
> > > > On Mon, Dec 12, 2022 at 05:13:38PM +0100, Andi Shyti wrote:
> > > > > From: Chris Wilson 
> > > > > 
> > > > > After applying an engine reset, on some platforms like
> > > > > Jasperlake, we
> > > > > occasionally detect that the engine state is not cleared until
> > > > > shortly
> > > > > after the resume. As we try to resume the engine with volatile
> > > > > internal
> > > > > state, the first request fails with a spurious CS event (it looks
> > > > > like
> > > > > it reports a lite-restore to the hung context, instead of the
> > > > > expected
> > > > > idle->active context switch).
> > > > > 
> > > > > Signed-off-by: Chris Wilson 
> > > > 
> > > > There's a typo in the signature email I'm afraid...
> > > 
> > > oh yes, I forgot the 'C' :)
> > 
> > you forgot?
> > who signed it off?
> 
> Chris, but as I was copy/pasting SoB's I might have
> unintentionally removed the 'c'.
> 
> > > > Other than that, have we checked the possibility of using the
> > > > driver-initiated-flr bit
> > > > instead of this second loop? That should be the right way to
> > > > guarantee everything is
> > > > cleared on gen11+...
> > > 
> > > maybe I am misinterpreting it, but is FLR the same as resetting
> > > hardware domains individually?
> > 
> > No, it is bigger than that... almost the PCI FLR with some exceptions:
> > 
> > https://lists.freedesktop.org/archives/intel-gfx/2022-December/313956.html
> 
> yes, exactly... I would use FLR feedback if I was performing an
> FLR reset. But here I'm not doing that, here I'm simply gating
> off some power domains. It happens that those power domains turn
> on and off engines making them reset.

is this issue only seeing when this reset is called from the
sanitize functions at probe and resumes?
Or from any kind of gt reset?

I don't remember seeing any reference link to the bug in the patch,
hence I'm assuming this is happening in any kind of gt reset that
ends up in this function.

> 
> FLR doesn't have anything to do here, also because if you want to
> reset a single engine you go through this function, instead of
> resetting the whole GPU with whatever is annexed.

yeap. That might be to extreme depending on the case. But all that
I asked was if we were considering this option since this is the
recommended way of reseting our engines nowadays.

> 
> This patch is not fixing the "reset" concept of i915, but it's
> fixing a missing feedback that happens in one single platform
> when trying to gate on/off a domain.

But it is changing the reset concept and timeouts for all the reset
cases in all the platforms.

> 
> Maybe I am completely off track, but I don't see connection with
> FLR here.

The point is that if a reset is needed, for any reason,
the recommended way for Jasperlake, and any other newer platforms,
is to use the FLR rather than the engine reset. But we are using
the engine reset, and now twice, rather then attempt the recommended
way.

> 
> (besides FLR might not be present in all the platforms)

This issue is also not present in all the platforms and you are still
increasing the loops and delay for all the platforms.

> 
> Thanks a lot for your inputs,

have we looked to the Jasperlake workarounds to see if we are missing
anything there that could help us in this case instead of this extreme
approach of randomly increasing timeouts and attempts for all the
platforms?

> Andi
> 
> > > How am I supposed to use driver_initiated_flr() in this context?
> > 
> > Some drivers are not even using this gt reset anymore and going
> > directly with the driver-initiated FLR in case that guc reset failed.
> > 
> > I believe we can still keep the gt reset in our case as we currently
> > have, but instead of keep retrying it until it succeeds we probably
> > should go to the next level and do the driver initiated FLR when the GT
> > reset failed.
> > 
> > > 
> > > Thanks,
> > > Andi
> > > 
> > > > > Cc: sta...@vger.kernel.org
> > > > > Cc: Mika Kuoppala 
> > > > > Signed-off-by: Andi Shyti 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/gt/intel_reset.c | 34
> > > > > ++-
> > > > >  1 file changed, 28 insertions(+), 6 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
> > > > > b/drivers/gpu/drm/i915/gt/intel_reset.c
> > > > > index ffde89c5835a4..88dfc0c5316ff 100644
> > > > > --- a/drivers/gpu/drm/i915/gt/intel_reset.c
> > > > > +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
> > > > > @@ -268,6 +268,7 @@ static int ilk_do_reset(struct intel_gt *gt,
> > > > > intel_engine_mask_t engine_mask,
> > > > >  static int gen6_hw_domain_reset(struct intel_gt *gt, u32
> > > > > hw_domain_mask)
> > > > >  {
> > > > > struct intel_uncor

Re: [Intel-gfx] [PATCH v15 1/7] overflow: Introduce overflows_type() and castable_to_type()

2022-12-15 Thread Gwan-gyeong Mun




On 12/15/22 5:09 PM, Andrzej Hajda wrote:



On 15.12.2022 13:52, Gwan-gyeong Mun wrote:

From: Kees Cook 

Implement a robust overflows_type() macro to test if a variable or
constant value would overflow another variable or type. This can be
used as a constant expression for static_assert() (which requires a
constant expression[1][2]) when used on constant values. This must be
constructed manually, since __builtin_add_overflow() does not produce
a constant expression[3].

Additionally adds castable_to_type(), similar to __same_type(), but for
checking if a constant value would overflow if cast to a given type.

Add unit tests for overflows_type(), __same_type(), and 
castable_to_type()

to the existing KUnit "overflow" test:

[16:03:33] == overflow (21 subtests) ==
...
[16:03:33] [PASSED] overflows_type_test
[16:03:33] [PASSED] same_type_test
[16:03:33] [PASSED] castable_to_type_test
[16:03:33]  [PASSED] overflow =
[16:03:33] 
[16:03:33] Testing complete. Ran 21 tests: passed: 21
[16:03:33] Elapsed time: 24.022s total, 0.002s configuring, 22.598s 
building, 0.767s running


[1] https://en.cppreference.com/w/c/language/_Static_assert
[2] C11 standard (ISO/IEC 9899:2011): 6.7.10 Static assertions
[3] https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
 6.56 Built-in Functions to Perform Arithmetic with Overflow Checking
 Built-in Function: bool __builtin_add_overflow (type1 a, type2 b,

Cc: Luc Van Oostenryck 
Cc: Nathan Chancellor 
Cc: Nick Desaulniers 
Cc: Tom Rix 
Cc: Daniel Latypov 
Cc: Vitor Massaru Iha 
Cc: "Gustavo A. R. Silva" 
Cc: Jani Nikula 
Cc: Mauro Carvalho Chehab 
Cc: linux-harden...@vger.kernel.org
Cc: l...@lists.linux.dev
Co-developed-by: Gwan-gyeong Mun 
Signed-off-by: Gwan-gyeong Mun 
Signed-off-by: Kees Cook 
Link: 
https://lore.kernel.org/r/20221024201125.1416422-1-gwan-gyeong@intel.com 


---
  drivers/gpu/drm/i915/i915_user_extensions.c |   2 +-
  drivers/gpu/drm/i915/i915_utils.h   |   4 -
  include/linux/compiler.h    |   1 +
  include/linux/overflow.h    |  48 +++
  lib/Makefile    |   1 +
  lib/overflow_kunit.c    | 381 
  6 files changed, 432 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_user_extensions.c 
b/drivers/gpu/drm/i915/i915_user_extensions.c

index c822d0aafd2d..e3f808372c47 100644
--- a/drivers/gpu/drm/i915/i915_user_extensions.c
+++ b/drivers/gpu/drm/i915/i915_user_extensions.c
@@ -51,7 +51,7 @@ int i915_user_extensions(struct i915_user_extension 
__user *ext,

  return err;
  if (get_user(next, &ext->next_extension) ||
-    overflows_type(next, ext))
+    overflows_type(next, uintptr_t))
  return -EFAULT;
  ext = u64_to_user_ptr(next);
diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h

index b64192d9c7da..2c430c0c3bad 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -111,10 +111,6 @@ bool i915_error_injected(void);
  #define range_overflows_end_t(type, start, size, max) \
  range_overflows_end((type)(start), (type)(size), (type)(max))
-/* Note we don't consider signbits :| */
-#define overflows_type(x, T) \
-    (sizeof(x) > sizeof(T) && (x) >> BITS_PER_TYPE(T))
-
  #define ptr_mask_bits(ptr, n) ({    \
  unsigned long __v = (unsigned long)(ptr);    \
  (typeof(ptr))(__v & -BIT(n));    \
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 973a1bfd7ef5..947a60b801db 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -236,6 +236,7 @@ static inline void *offset_to_ptr(const int *off)
   * bool and also pointer types.
   */
  #define is_signed_type(type) (((type)(-1)) < (__force type)1)
+#define is_unsigned_type(type) (!is_signed_type(type))
  /*
   * This is needed in functions which generate the stack canary, see
diff --git a/include/linux/overflow.h b/include/linux/overflow.h
index 1d3be1a2204c..16ae8d912390 100644
--- a/include/linux/overflow.h
+++ b/include/linux/overflow.h
@@ -128,6 +128,54 @@ static inline bool __must_check 
__must_check_overflow(bool overflow)

  (*_d >> _to_shift) != _a);    \
  }))
+#define __overflows_type_constexpr(x, T) (    \
+    is_unsigned_type(typeof(x)) ?    \
+    (x) > type_max(typeof(T)) ? 1 : 0    \
+    : is_unsigned_type(typeof(T)) ?    \
+    (x) < 0 || (x) > type_max(typeof(T)) ? 1 : 0    \
+    : (x) < type_min(typeof(T)) ||    \
+  (x) > type_max(typeof(T)) ? 1 : 0)


Syntactically seems fine, but I am little bit lost with indentation. 
Shouldn't the last two lines be one tab to the left?  Up to you.
Btw, maybe extra helper in_range/bet

Re: [Intel-gfx] [PATCH v3 6/7] drm/i915/mtl: Add function to send command to GSC CS

2022-12-15 Thread Teres Alexis, Alan Previn


On Wed, 2022-12-14 at 14:37 +0530, Suraj Kandpal wrote:
> Add function that takes care of sending command to gsc cs. We start
> of with allocation of memory for our command intel_hdcp_gsc_message that
> contains gsc cs memory header as directed in specs followed by the
> actual payload hdcp message that we want to send.
> Spec states that we need to poll pending bit of response header around
> 20 times each try being 50ms apart hence adding that to current
> gsc_msg_send function
> Also we use the same function to take care of both sending and receiving
> hence no separate function to get the response.
> 
> Cc: Ankit Nautiyal 
> Cc: Daniele Ceraolo Spurio 
> Cc: Uma Shankar 
> Cc: Anshuman Gupta 
> Signed-off-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/Makefile |   1 +
>  drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 207 ++
>  drivers/gpu/drm/i915/display/intel_hdcp_gsc.h |  18 ++
>  drivers/gpu/drm/i915/gt/uc/intel_gsc_fwif.h   |   1 +
>  4 files changed, 227 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index f64a8bc73c89..9cae0c1598a7 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -251,6 +251,7 @@ i915-y += \
>   display/intel_frontbuffer.o \
>   display/intel_global_state.o \
>   display/intel_hdcp.o \
> + display/intel_hdcp_gsc.o \
>   display/intel_hotplug.o \
>   display/intel_hti.o \
>   display/intel_lpe_audio.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c 
> b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> new file mode 100644
> index ..6858b6219221
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> @@ -0,0 +1,207 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright 2021, Intel Corporation.
> + */
> +
> +#include "display/intel_hdcp_gsc.h"
> +#include "gem/i915_gem_region.h"
> +#include "gt/uc/intel_gsc_fw.h"
> +#include "gt/uc/intel_gsc_fwif.h"
> +#include "i915_drv.h"
> +#include "i915_utils.h"
> +
> +struct intel_hdcp_gsc_message {
> + struct drm_i915_gem_object *obj;
> + struct i915_vma *vma;
> + void *hdcp_cmd;
> +};
> 
Alan: see my last set of comments below.

Alan:[snip
> 
> 

> +static int intel_gsc_send_sync(struct drm_i915_private *i915,
> +struct intel_gsc_mtl_header *header, u64 addr,
> +size_t msg_out_len)
> +{
> + struct intel_gt *gt = i915->media_gt;
> + int ret;
> +
> + header->flags = 0;
> + ret = intel_gsc_fw_heci_send(>->uc.gsc, addr, header->message_size,
> +  addr, msg_out_len + sizeof(*header));
> + if (ret) {
> + drm_err(&i915->drm, "failed to send gsc HDCP msg (%d)\n", ret);
> + return ret;
> + }
> + /*
> +  * Checking validity marker for memory sanity
> +  */
> + if (header->validity_marker != GSC_HECI_VALIDITY_MARKER) {
> + drm_err(&i915->drm, "invalid validity marker\n");
> + return -EINVAL;
> + }
> +
> + if (header->status != 0) {
> + drm_err(&i915->drm, "header status indicates error %d\n",
> + header->status);
> + return -EINVAL;
> + }
> +
> + if (header->flags & INTEL_GSC_MSG_PENDING)
> + return -EAGAIN;
> +
> + return 0;
> +}
> +
Alan: As per my comment on patch #1 above function could go into the uc/gsc 
domain ... see the comment below for further elaboration.

> +/*
> + * This function can now be used for sending requests and will also handle
> + * receipt of reply messages hence no different function of message retrieval
> + * is required. We will initialize intel_hdcp_gsc_message structure then add
> + * gsc cs memory header as stated in specs after which the normal HDCP 
> payload
> + * will follow
> + */
> +ssize_t intel_hdcp_gsc_msg_send(struct drm_i915_private *i915, u8 *msg_in,
> + size_t msg_in_len, u8 *msg_out, size_t 
> msg_out_len)
> +{
> + struct intel_gt *gt = i915->media_gt;
> + struct intel_gsc_mtl_header *header;
> + const size_t max_msg_size = PAGE_SIZE - sizeof(*header);
> + struct intel_hdcp_gsc_message *hdcp_message;
> + u64 addr;
> + u32 reply_size;
> + int ret, tries = 0;
> +
> + if (!intel_uc_uses_gsc_uc(>->uc))
> + return -ENODEV;
> +
> + if (msg_in_len > max_msg_size || msg_out_len > max_msg_size)
> + return -ENOSPC;
> +
> + hdcp_message = kzalloc(sizeof(*hdcp_message), GFP_KERNEL);
> +
> + if (!hdcp_message)
> + return -ENOMEM;
> +
> + ret = intel_initialize_hdcp_gsc_message(i915, hdcp_message);
> +
> + if (ret) {
> + drm_err(&i915->drm,
> + "Could not initialize hdcp_message\n");
> +

Re: [Intel-gfx] [PATCH v3 1/7] drm/i915/gsc: Create GSC request submission mechanism

2022-12-15 Thread Teres Alexis, Alan Previn


On Wed, 2022-12-14 at 14:37 +0530, Kandpal, Suraj wrote:
> HDCP and PXP will require a common function to allow it to
> submit commands to the gsc cs. Also adding the gsc mtl header
> that needs to be added on to the existing payloads of HDCP
> and PXP.
> 
> Cc: Daniele Ceraolo Spurio 
> Cc: Alan Previn 
> Signed-off-by: Suraj Kandpal
> ---
>  drivers/gpu/drm/i915/gt/intel_gpu_commands.h |  2 +
>  drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c| 62 +++-
>  drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h|  3 +
>  drivers/gpu/drm/i915/gt/uc/intel_gsc_fwif.h  | 41 +
>  4 files changed, 105 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fwif.h
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
> b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> index 2af1ae3831df..454179884801 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> @@ -439,6 +439,8 @@
>  #define GSC_FW_LOAD GSC_INSTR(1, 0, 2)
>  #define   HECI1_FW_LIMIT_VALID (1 << 31)
>  
> +#define GSC_HECI_CMD_PKT GSC_INSTR(0, 0, 6)
> +
>  /*
>   * Used to convert any address to canonical form.
>   * Starting from gen8, some commands (e.g. STATE_BASE_ADDRESS,
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
> index e73d4440c5e8..f00e88fdb5d2 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
> @@ -30,6 +30,35 @@ bool intel_gsc_uc_fw_init_done(struct intel_gsc_uc *gsc)
>   return fw_status & GSC_FW_INIT_COMPLETE_BIT;
>  }
> 
Alan:[snip]


> @@ -49,7 +78,12 @@ static int emit_gsc_fw_load(struct i915_request *rq, 
> struct intel_gsc_uc *gsc)
>   return 0;
>  }
>  
> -static int gsc_fw_load(struct intel_gsc_uc *gsc)
> +/*
> + * Our submissions to GSC are going to be either a FW load or an heci pkt, 
> but
> + * all the request emission logic is the same so we can use a common func and
> + * just add the correct cmd
> + */
> +static int submit_to_gsc_fw(struct intel_gsc_uc *gsc, struct gsc_heci_pkt 
> *pkt)
>  {
>   struct intel_context *ce = gsc->ce;
>   struct i915_request *rq;
> @@ -68,7 +102,11 @@ static int gsc_fw_load(struct intel_gsc_uc *gsc)
>   goto out_rq;
>   }
>  
> - err = emit_gsc_fw_load(rq, gsc);
> + if (pkt)
> + err = emit_gsc_heci_pkt(rq, pkt);
> + else
> + err = emit_gsc_fw_load(rq, gsc);
> +
Alan: To be honest, code function names + responsibilities lack proper 
hierarchy -  doens't look quite right from my perspective for readability / 
scalability.
In my opinion, we create a separate functions for load_fw vs heci_packet. But 
have a common utility function for the actual sending to HW (engine->emit_flush)
and waiting with a timeout (i915_request_wait). We know heci_packet will in 
future be used by PXP and potentially across both concurrently.


Then we mirror the same thing for general heci load (thus also allowing 
differentiated debug messages):

intel_gsc_engine_send_loadfw
| (allocate the request, use the gsc-ce).
|---> emit_gsc_heci_pkt (fill up the send-heci-pkt cmd)
|---> submit_to_gsc_fw(req, ... timeout)

intel_gsc_engine_send_hecipkt
| (allocate the request, use the gsc-ce).
| (we could even potentially create the MTL CS HEADER here 
itself
|  since the GSC-CS memory header isnt an entity of the 
caller 
|  subsystem such as hdcp or pxp, but rather is the entity 
of the
|  (GSC) command-streamer param, so bring it into 
intel_gsc_fw file)
|---> emit_gsc_fw_load (fill up the fw load cmd)
|---> submit_to_gsc_fw(req, ... timeout)

  * intel_gsc_engine_send_hecipkt common to >1 caller-subsystems


Additionally, one last thing might be to move only sets of functions into 
separate files with common helpers:
intel_gsc_fw.c : all the firmware loading related functions
intel_gsc_heci.c : all the heci command packet sending related functions (here 
is where we can add the GSC-CS memory header population and in future, the 
host-session-id
allocation for PXP).
intel_gsc_cs_helper : for the submit_to_gsc_fw and other common functions to 
both fw-loading and heci-packet sending.


Alan:[snip]


> + u8 gsc_address;
> +#define HECI_MEADDRESS_PXP 17
> +#define HECI_MEADDRESS_HDCP 18
> +
> + u8 reserved1;
> +
> + u16 header_version;
> +#define MTL_GSC_HEADER_VERSION 1
> +
> + u64 host_session_handle;
> + u64 gsc_message_handle;
> +
> + u32 message_size; /* lower 20 bits only, upper 12 are reserved */
> +
> + /*
> +  * Flags mask:
> +  * Bit 0: Pending
> +  * Bit 1: Session Cleanup;
> +  * Bits 2-15: Flags
> +  * Bits 16-31: Extension Size
> +  */
> + u32 flags;
> +
>

[Intel-gfx] [PATCH] drm/i915/hwmon: Display clamped PL1 limit

2022-12-15 Thread Ashutosh Dixit
HW allows arbitrary PL1 limits to be set but silently clamps these values
to "typical but not guaranteed" min/max values in pkg_power_sku
register. Follow the same pattern for sysfs, allow arbitrary PL1 limits to
be set but display clamped values when read, so that users see PL1 limits
HW is likely using. Otherwise users think HW is using arbitrarily high/low
PL1 limits they might have set. The previous write/read I1 power1_crit
limit also follows the same clamping pattern.

v2: Explain "why" in commit message and include bug link (Jani Nikula)

Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/7704
Signed-off-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/i915_hwmon.c| 39 
 drivers/gpu/drm/i915/intel_mchbar_regs.h |  2 ++
 2 files changed, 35 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index cca7a4350ec8f..1225bc432f0d5 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -359,6 +359,38 @@ hwm_power_is_visible(const struct hwm_drvdata *ddat, u32 
attr, int chan)
}
 }
 
+/*
+ * HW allows arbitrary PL1 limits to be set but silently clamps these values to
+ * "typical but not guaranteed" min/max values in rg.pkg_power_sku. Follow the
+ * same pattern for sysfs, allow arbitrary PL1 limits to be set but display
+ * clamped values when read. Write/read I1 also follows the same pattern.
+ */
+static int
+hwm_power_max_read(struct hwm_drvdata *ddat, long *val)
+{
+   struct i915_hwmon *hwmon = ddat->hwmon;
+   intel_wakeref_t wakeref;
+   u64 r, min, max;
+
+   *val = hwm_field_read_and_scale(ddat,
+   hwmon->rg.pkg_rapl_limit,
+   PKG_PWR_LIM_1,
+   hwmon->scl_shift_power,
+   SF_POWER);
+
+   with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+   r = intel_uncore_read64(ddat->uncore, hwmon->rg.pkg_power_sku);
+   min = REG_FIELD_GET(PKG_MIN_PWR, r);
+   min = mul_u64_u32_shr(min, SF_POWER, hwmon->scl_shift_power);
+   max = REG_FIELD_GET(PKG_MAX_PWR, r);
+   max = mul_u64_u32_shr(max, SF_POWER, hwmon->scl_shift_power);
+
+   if (min && max)
+   *val = clamp_t(u64, *val, min, max);
+
+   return 0;
+}
+
 static int
 hwm_power_read(struct hwm_drvdata *ddat, u32 attr, int chan, long *val)
 {
@@ -368,12 +400,7 @@ hwm_power_read(struct hwm_drvdata *ddat, u32 attr, int 
chan, long *val)
 
switch (attr) {
case hwmon_power_max:
-   *val = hwm_field_read_and_scale(ddat,
-   hwmon->rg.pkg_rapl_limit,
-   PKG_PWR_LIM_1,
-   hwmon->scl_shift_power,
-   SF_POWER);
-   return 0;
+   return hwm_power_max_read(ddat, val);
case hwmon_power_rated_max:
*val = hwm_field_read_and_scale(ddat,
hwmon->rg.pkg_power_sku,
diff --git a/drivers/gpu/drm/i915/intel_mchbar_regs.h 
b/drivers/gpu/drm/i915/intel_mchbar_regs.h
index f93e9af43ac35..73900c098d591 100644
--- a/drivers/gpu/drm/i915/intel_mchbar_regs.h
+++ b/drivers/gpu/drm/i915/intel_mchbar_regs.h
@@ -194,6 +194,8 @@
  */
 #define PCU_PACKAGE_POWER_SKU  _MMIO(MCHBAR_MIRROR_BASE_SNB + 
0x5930)
 #define   PKG_PKG_TDP  GENMASK_ULL(14, 0)
+#define   PKG_MIN_PWR  GENMASK_ULL(30, 16)
+#define   PKG_MAX_PWR  GENMASK_ULL(46, 32)
 #define   PKG_MAX_WIN  GENMASK_ULL(54, 48)
 #define PKG_MAX_WIN_X  GENMASK_ULL(54, 53)
 #define PKG_MAX_WIN_Y  GENMASK_ULL(52, 48)
-- 
2.38.0



Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Display clamped PL1 limit

2022-12-15 Thread Jani Nikula
On Thu, 15 Dec 2022, Ashutosh Dixit  wrote:
> HW allows arbitrary PL1 limits to be set but silently clamps these values
> to "typical but not guaranteed" min/max values in pkg_power_sku
> register. Follow the same pattern for sysfs, allow arbitrary PL1 limits to
> be set but display clamped values when read.

The commit message lacks the most important thing: why?


BR,
Jani.

>
> Signed-off-by: Ashutosh Dixit 
> ---
>  drivers/gpu/drm/i915/i915_hwmon.c| 39 
>  drivers/gpu/drm/i915/intel_mchbar_regs.h |  2 ++
>  2 files changed, 35 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
> b/drivers/gpu/drm/i915/i915_hwmon.c
> index cca7a4350ec8f..1225bc432f0d5 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -359,6 +359,38 @@ hwm_power_is_visible(const struct hwm_drvdata *ddat, u32 
> attr, int chan)
>   }
>  }
>  
> +/*
> + * HW allows arbitrary PL1 limits to be set but silently clamps these values 
> to
> + * "typical but not guaranteed" min/max values in rg.pkg_power_sku. Follow 
> the
> + * same pattern for sysfs, allow arbitrary PL1 limits to be set but display
> + * clamped values when read. Write/read I1 also follows the same pattern.
> + */
> +static int
> +hwm_power_max_read(struct hwm_drvdata *ddat, long *val)
> +{
> + struct i915_hwmon *hwmon = ddat->hwmon;
> + intel_wakeref_t wakeref;
> + u64 r, min, max;
> +
> + *val = hwm_field_read_and_scale(ddat,
> + hwmon->rg.pkg_rapl_limit,
> + PKG_PWR_LIM_1,
> + hwmon->scl_shift_power,
> + SF_POWER);
> +
> + with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
> + r = intel_uncore_read64(ddat->uncore, hwmon->rg.pkg_power_sku);
> + min = REG_FIELD_GET(PKG_MIN_PWR, r);
> + min = mul_u64_u32_shr(min, SF_POWER, hwmon->scl_shift_power);
> + max = REG_FIELD_GET(PKG_MAX_PWR, r);
> + max = mul_u64_u32_shr(max, SF_POWER, hwmon->scl_shift_power);
> +
> + if (min && max)
> + *val = clamp_t(u64, *val, min, max);
> +
> + return 0;
> +}
> +
>  static int
>  hwm_power_read(struct hwm_drvdata *ddat, u32 attr, int chan, long *val)
>  {
> @@ -368,12 +400,7 @@ hwm_power_read(struct hwm_drvdata *ddat, u32 attr, int 
> chan, long *val)
>  
>   switch (attr) {
>   case hwmon_power_max:
> - *val = hwm_field_read_and_scale(ddat,
> - hwmon->rg.pkg_rapl_limit,
> - PKG_PWR_LIM_1,
> - hwmon->scl_shift_power,
> - SF_POWER);
> - return 0;
> + return hwm_power_max_read(ddat, val);
>   case hwmon_power_rated_max:
>   *val = hwm_field_read_and_scale(ddat,
>   hwmon->rg.pkg_power_sku,
> diff --git a/drivers/gpu/drm/i915/intel_mchbar_regs.h 
> b/drivers/gpu/drm/i915/intel_mchbar_regs.h
> index f93e9af43ac35..73900c098d591 100644
> --- a/drivers/gpu/drm/i915/intel_mchbar_regs.h
> +++ b/drivers/gpu/drm/i915/intel_mchbar_regs.h
> @@ -194,6 +194,8 @@
>   */
>  #define PCU_PACKAGE_POWER_SKU
> _MMIO(MCHBAR_MIRROR_BASE_SNB + 0x5930)
>  #define   PKG_PKG_TDPGENMASK_ULL(14, 0)
> +#define   PKG_MIN_PWRGENMASK_ULL(30, 16)
> +#define   PKG_MAX_PWRGENMASK_ULL(46, 32)
>  #define   PKG_MAX_WINGENMASK_ULL(54, 48)
>  #define PKG_MAX_WIN_XGENMASK_ULL(54, 53)
>  #define PKG_MAX_WIN_YGENMASK_ULL(52, 48)

-- 
Jani Nikula, Intel Open Source Graphics Center


[Intel-gfx] [PATCH] drm/i915/hwmon: Display clamped PL1 limit

2022-12-15 Thread Ashutosh Dixit
HW allows arbitrary PL1 limits to be set but silently clamps these values
to "typical but not guaranteed" min/max values in pkg_power_sku
register. Follow the same pattern for sysfs, allow arbitrary PL1 limits to
be set but display clamped values when read.

Signed-off-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/i915_hwmon.c| 39 
 drivers/gpu/drm/i915/intel_mchbar_regs.h |  2 ++
 2 files changed, 35 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index cca7a4350ec8f..1225bc432f0d5 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -359,6 +359,38 @@ hwm_power_is_visible(const struct hwm_drvdata *ddat, u32 
attr, int chan)
}
 }
 
+/*
+ * HW allows arbitrary PL1 limits to be set but silently clamps these values to
+ * "typical but not guaranteed" min/max values in rg.pkg_power_sku. Follow the
+ * same pattern for sysfs, allow arbitrary PL1 limits to be set but display
+ * clamped values when read. Write/read I1 also follows the same pattern.
+ */
+static int
+hwm_power_max_read(struct hwm_drvdata *ddat, long *val)
+{
+   struct i915_hwmon *hwmon = ddat->hwmon;
+   intel_wakeref_t wakeref;
+   u64 r, min, max;
+
+   *val = hwm_field_read_and_scale(ddat,
+   hwmon->rg.pkg_rapl_limit,
+   PKG_PWR_LIM_1,
+   hwmon->scl_shift_power,
+   SF_POWER);
+
+   with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+   r = intel_uncore_read64(ddat->uncore, hwmon->rg.pkg_power_sku);
+   min = REG_FIELD_GET(PKG_MIN_PWR, r);
+   min = mul_u64_u32_shr(min, SF_POWER, hwmon->scl_shift_power);
+   max = REG_FIELD_GET(PKG_MAX_PWR, r);
+   max = mul_u64_u32_shr(max, SF_POWER, hwmon->scl_shift_power);
+
+   if (min && max)
+   *val = clamp_t(u64, *val, min, max);
+
+   return 0;
+}
+
 static int
 hwm_power_read(struct hwm_drvdata *ddat, u32 attr, int chan, long *val)
 {
@@ -368,12 +400,7 @@ hwm_power_read(struct hwm_drvdata *ddat, u32 attr, int 
chan, long *val)
 
switch (attr) {
case hwmon_power_max:
-   *val = hwm_field_read_and_scale(ddat,
-   hwmon->rg.pkg_rapl_limit,
-   PKG_PWR_LIM_1,
-   hwmon->scl_shift_power,
-   SF_POWER);
-   return 0;
+   return hwm_power_max_read(ddat, val);
case hwmon_power_rated_max:
*val = hwm_field_read_and_scale(ddat,
hwmon->rg.pkg_power_sku,
diff --git a/drivers/gpu/drm/i915/intel_mchbar_regs.h 
b/drivers/gpu/drm/i915/intel_mchbar_regs.h
index f93e9af43ac35..73900c098d591 100644
--- a/drivers/gpu/drm/i915/intel_mchbar_regs.h
+++ b/drivers/gpu/drm/i915/intel_mchbar_regs.h
@@ -194,6 +194,8 @@
  */
 #define PCU_PACKAGE_POWER_SKU  _MMIO(MCHBAR_MIRROR_BASE_SNB + 
0x5930)
 #define   PKG_PKG_TDP  GENMASK_ULL(14, 0)
+#define   PKG_MIN_PWR  GENMASK_ULL(30, 16)
+#define   PKG_MAX_PWR  GENMASK_ULL(46, 32)
 #define   PKG_MAX_WIN  GENMASK_ULL(54, 48)
 #define PKG_MAX_WIN_X  GENMASK_ULL(54, 53)
 #define PKG_MAX_WIN_Y  GENMASK_ULL(52, 48)
-- 
2.38.0



Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dg2: Return Wa_22012654132 to just specific steppings

2022-12-15 Thread Matt Roper
On Thu, Dec 15, 2022 at 03:13:07AM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/dg2: Return Wa_22012654132 to just specific steppings
> URL   : https://patchwork.freedesktop.org/series/111912/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_12502_full -> Patchwork_111912v1_full
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_111912v1_full absolutely need 
> to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_111912v1_full, please notify your bug team to allow 
> them
>   to document this new failure mode, which will reduce false positives in CI.
> 
>   
> 
> Participating hosts (14 -> 14)
> --
> 
>   No changes in participating hosts
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_111912v1_full:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@gem_exec_fence@syncobj-timeline-multiple-ext-nodes:
> - shard-skl:  [PASS][1] -> [WARN][2]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-skl4/igt@gem_exec_fe...@syncobj-timeline-multiple-ext-nodes.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111912v1/shard-skl7/igt@gem_exec_fe...@syncobj-timeline-multiple-ext-nodes.html

SKL warning is not related to the DG2 tuning changes here.

Most likely this warning is the same as the one reported in
https://gitlab.freedesktop.org/drm/intel/-/issues/7541

Applied to drm-intel-gt-next.  Thanks MattA for the review.


Matt

> 
>   
>  Suppressed 
> 
>   The following results come from untrusted machines, tests, or statuses.
>   They do not affect the overall result.
> 
>   * igt@gem_eio@in-flight-external:
> - {shard-rkl}:[PASS][3] -> [DMESG-WARN][4]
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-rkl-1/igt@gem_...@in-flight-external.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111912v1/shard-rkl-4/igt@gem_...@in-flight-external.html
> 
>   * igt@kms_panel_fitting@atomic-fastset:
> - {shard-tglu-9}: NOTRUN -> [SKIP][5] +1 similar issue
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111912v1/shard-tglu-9/igt@kms_panel_fitt...@atomic-fastset.html
> 
>   
> Known issues
> 
> 
>   Here are the changes found in Patchwork_111912v1_full that come from known 
> issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@drm_mm@all:
> - shard-tglb: NOTRUN -> [SKIP][6] ([i915#6433])
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111912v1/shard-tglb6/igt@drm...@all.html
> 
>   * igt@gem_ctx_exec@basic-nohangcheck:
> - shard-tglb: [PASS][7] -> [FAIL][8] ([i915#6268])
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-tglb7/igt@gem_ctx_e...@basic-nohangcheck.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111912v1/shard-tglb2/igt@gem_ctx_e...@basic-nohangcheck.html
> 
>   * igt@gem_exec_balancer@parallel-bb-first:
> - shard-skl:  NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4525])
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111912v1/shard-skl7/igt@gem_exec_balan...@parallel-bb-first.html
> 
>   * igt@gem_exec_balancer@parallel-keep-submit-fence:
> - shard-iclb: [PASS][10] -> [SKIP][11] ([i915#4525]) +1 similar 
> issue
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-iclb1/igt@gem_exec_balan...@parallel-keep-submit-fence.html
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111912v1/shard-iclb8/igt@gem_exec_balan...@parallel-keep-submit-fence.html
> 
>   * igt@gem_exec_fair@basic-none-vip@rcs0:
> - shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842])
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-tglb6/igt@gem_exec_fair@basic-none-...@rcs0.html
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111912v1/shard-tglb5/igt@gem_exec_fair@basic-none-...@rcs0.html
> 
>   * igt@gem_pxp@display-protected-crc:
> - shard-tglb: NOTRUN -> [SKIP][14] ([i915#4270])
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111912v1/shard-tglb6/igt@gem_...@display-protected-crc.html
> 
>   * igt@gen7_exec_parse@basic-allocation:
> - shard-tglb: NOTRUN -> [SKIP][15] ([fdo#109289])
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111912v1/shard-tglb6/igt@gen7_exec_pa...@basic-allocation.html
> 
>   * igt@gen9_exec_parse@allowed-single:
> - shard-apl:  [PASS][16] -> [DMESG-WARN][17] ([i915#5566] / 
> [i915#716])
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl3/igt@gen9_exec_pa...@allowed-single.html
>[17]: 
> https://

Re: [Intel-gfx] [PATCH] drm/i915: Skip Bit12 fw domain reset for gen12+

2022-12-15 Thread Matt Roper
On Thu, Dec 15, 2022 at 05:38:22PM +, Tvrtko Ursulin wrote:
> 
> On 25/08/2022 18:49, Sripada, Radhakrishna wrote:
> > Hi G.G,
> > 
> > > -Original Message-
> > > From: Mun, Gwan-gyeong 
> > > Sent: Tuesday, August 23, 2022 11:14 PM
> > > To: Roper, Matthew D ; Sripada, Radhakrishna
> > > 
> > > Cc: intel-gfx@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Skip Bit12 fw domain reset for 
> > > gen12+
> > > 
> > > 
> > > 
> > > On 8/18/22 3:00 PM, Matt Roper wrote:
> > > > On Wed, Aug 17, 2022 at 03:43:04PM -0700, Radhakrishna Sripada wrote:
> > > > > Bit12 of the Forcewake request register should not be cleared post
> > > > > gen12. Do not touch this bit while clearing during fw domain reset.
> > > > > 
> > > > > Bspec: 52542
> > > > > 
> > > > > Signed-off-by: Sushma Venkatesh Reddy
> > > 
> > > > > Signed-off-by: Radhakrishna Sripada 
> > > > > ---
> > > > >drivers/gpu/drm/i915/intel_uncore.c | 5 -
> > > > >1 file changed, 4 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> > > b/drivers/gpu/drm/i915/intel_uncore.c
> > > > > index a852c471d1b3..c85e2b686c95 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_uncore.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_uncore.c
> > > > > @@ -113,7 +113,10 @@ fw_domain_reset(const struct
> > > intel_uncore_forcewake_domain *d)
> > > > >* off in ICL+), so no waiting for acks
> > > > >*/
> > > > >   /* WaRsClearFWBitsAtReset:bdw,skl */
> > > > 
> > > > While we're at it, let's remove the "bdw,skl" from this comment since
> > > > it's misleading and doesn't match the code.  We do still apply this
> > > > workaround on other pre-gen12 platforms than just those two.
> > > > 
> > > > Aside from the comment tweak,
> > > > 
> > > > Reviewed-by: Matt Roper 
> > > > 
> > > > > - fw_clear(d, 0x);
> > > > > + if (GRAPHICS_VER(d->uncore->i915) >= 12)
> > > Hi Radhakrishna Sripada,
> > > 
> > > In bspec 52542, there is an explanation that BIT12 should not be set for
> > > address 0xA188 corresponding to FORCEWAKE_MT/FORCEWAKE_GT_GEN9, but
> > > in
> > > bspec 52466, there is no explanation that BIT12 should not be set for
> > > address 0xA278, address of FORCEWAKE_RENDER_GEN9.
> > > 
> > > I ask if fw_domain_reset() should perform fw_clear() by comparing not
> > > only GRAPHICS_VER() >= 12 but also checking of FW_DOMAIN_ID_RENDER and
> > > FW_DOMAIN_ID_GT values.
> > Based on the note in 52542, all other WA notes are overridden by the 
> > comment. So unless stated
> > otherwise, it should apply to this register as well.
> > 
> > Created a bspec issue to request for additional clarification just to be 
> > safe. Will send an additional
> > patch if the comment contradicts our understanding.
> 
> How important was this patch - should it be sent to stable?

It shouldn't be needed for stable; clearing the bit isn't necessary from
gen12 onward, but as far as we know it doesn't cause any problems either
(except maybe on MTL, which is still under force_probe and not supported
on stable kernels).  So according to stable-kernel-rules.rst, this patch
would not qualify.


Matt

> 
> Regards,
> 
> Tvrtko

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation


Re: [Intel-gfx] [PATCH] drm/i915: Skip Bit12 fw domain reset for gen12+

2022-12-15 Thread Tvrtko Ursulin



On 25/08/2022 18:49, Sripada, Radhakrishna wrote:

Hi G.G,


-Original Message-
From: Mun, Gwan-gyeong 
Sent: Tuesday, August 23, 2022 11:14 PM
To: Roper, Matthew D ; Sripada, Radhakrishna

Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Skip Bit12 fw domain reset for gen12+



On 8/18/22 3:00 PM, Matt Roper wrote:

On Wed, Aug 17, 2022 at 03:43:04PM -0700, Radhakrishna Sripada wrote:

Bit12 of the Forcewake request register should not be cleared post
gen12. Do not touch this bit while clearing during fw domain reset.

Bspec: 52542

Signed-off-by: Sushma Venkatesh Reddy



Signed-off-by: Radhakrishna Sripada 
---
   drivers/gpu/drm/i915/intel_uncore.c | 5 -
   1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c

b/drivers/gpu/drm/i915/intel_uncore.c

index a852c471d1b3..c85e2b686c95 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -113,7 +113,10 @@ fw_domain_reset(const struct

intel_uncore_forcewake_domain *d)

 * off in ICL+), so no waiting for acks
 */
/* WaRsClearFWBitsAtReset:bdw,skl */


While we're at it, let's remove the "bdw,skl" from this comment since
it's misleading and doesn't match the code.  We do still apply this
workaround on other pre-gen12 platforms than just those two.

Aside from the comment tweak,

Reviewed-by: Matt Roper 


-   fw_clear(d, 0x);
+   if (GRAPHICS_VER(d->uncore->i915) >= 12)

Hi Radhakrishna Sripada,

In bspec 52542, there is an explanation that BIT12 should not be set for
address 0xA188 corresponding to FORCEWAKE_MT/FORCEWAKE_GT_GEN9, but
in
bspec 52466, there is no explanation that BIT12 should not be set for
address 0xA278, address of FORCEWAKE_RENDER_GEN9.

I ask if fw_domain_reset() should perform fw_clear() by comparing not
only GRAPHICS_VER() >= 12 but also checking of FW_DOMAIN_ID_RENDER and
FW_DOMAIN_ID_GT values.

Based on the note in 52542, all other WA notes are overridden by the comment. 
So unless stated
otherwise, it should apply to this register as well.

Created a bspec issue to request for additional clarification just to be safe. 
Will send an additional
patch if the comment contradicts our understanding.


How important was this patch - should it be sent to stable?

Regards,

Tvrtko


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/dp_mst: log when pulling CRTCs into atomic state

2022-12-15 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915/dp_mst: log when pulling CRTCs into 
atomic state
URL   : https://patchwork.freedesktop.org/series/111967/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12510 -> Patchwork_111967v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (19 -> 38)
--

  Additional (19): fi-kbl-soraka bat-dg1-6 bat-dg1-5 bat-adlp-6 bat-rpls-1 
fi-skl-6600u fi-bsw-n3050 bat-dg2-8 bat-adlm-1 bat-dg2-9 bat-adln-1 bat-jsl-3 
bat-rplp-1 bat-dg2-11 fi-bsw-nick bat-dg1-7 bat-kbl-2 bat-adlp-9 bat-adlp-4 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-adlp-4: NOTRUN -> [SKIP][1] ([i915#7456])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111967v1/bat-adlp-4/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_exec_gttfill@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][2] ([fdo#109271]) +7 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111967v1/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html

  * igt@gem_huc_copy@huc-copy:
- fi-skl-6600u:   NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111967v1/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111967v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111967v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-bsw-nick:NOTRUN -> [SKIP][6] ([fdo#109271]) +39 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111967v1/fi-bsw-nick/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_lmem_swapping@random-engines:
- fi-bsw-n3050:   NOTRUN -> [SKIP][7] ([fdo#109271]) +20 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111967v1/fi-bsw-n3050/igt@gem_lmem_swapp...@random-engines.html
- fi-skl-6600u:   NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111967v1/fi-skl-6600u/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_lmem_swapping@verify-random:
- bat-adlp-4: NOTRUN -> [SKIP][9] ([i915#4613]) +3 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111967v1/bat-adlp-4/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_mmap@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][10] ([i915#4083])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111967v1/bat-dg1-5/igt@gem_m...@basic.html
- bat-dg1-6:  NOTRUN -> [SKIP][11] ([i915#4083])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111967v1/bat-dg1-6/igt@gem_m...@basic.html

  * igt@gem_render_tiled_blits@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][12] ([i915#4079]) +1 similar issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111967v1/bat-dg1-6/igt@gem_render_tiled_bl...@basic.html

  * igt@gem_tiled_fence_blits@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][13] ([i915#4077]) +2 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111967v1/bat-dg1-6/igt@gem_tiled_fence_bl...@basic.html
- bat-dg1-5:  NOTRUN -> [SKIP][14] ([i915#4077]) +2 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111967v1/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-dg1-5:  NOTRUN -> [SKIP][15] ([i915#4079]) +1 similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111967v1/bat-dg1-5/igt@gem_tiled_pread_basic.html
- bat-adlp-4: NOTRUN -> [SKIP][16] ([i915#3282])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111967v1/bat-adlp-4/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- bat-dg1-6:  NOTRUN -> [SKIP][17] ([i915#7561])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111967v1/bat-dg1-6/igt@i915_pm_backli...@basic-brightness.html
- bat-dg1-5:  NOTRUN -> [SKIP][18] ([i915#7561])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111967v1/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_pm_rps@basic-api:
- bat-dg1-6:  NOTRUN -> [SKIP][19] ([i915#6621])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111967v1/bat-dg1-6/igt@i915_pm_...@basic-api.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display/fdi: use intel_de_rmw if possible

2022-12-15 Thread Patchwork
== Series Details ==

Series: drm/i915/display/fdi: use intel_de_rmw if possible
URL   : https://patchwork.freedesktop.org/series/111964/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12510 -> Patchwork_111964v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (19 -> 39)
--

  Additional (22): fi-kbl-soraka bat-dg1-6 bat-dg1-5 bat-adlp-6 bat-rpls-1 
bat-rpls-2 fi-skl-6600u fi-bsw-n3050 bat-dg2-8 bat-adlm-1 bat-dg2-9 fi-bwr-2160 
bat-adln-1 bat-atsm-1 bat-jsl-3 bat-rplp-1 bat-dg2-11 fi-bsw-nick bat-dg1-7 
bat-kbl-2 bat-adlp-9 bat-adlp-4 
  Missing(2): fi-hsw-4770 fi-rkl-guc 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-adlp-4: NOTRUN -> [SKIP][1] ([i915#7456])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111964v1/bat-adlp-4/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_exec_gttfill@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][2] ([fdo#109271]) +7 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111964v1/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html

  * igt@gem_huc_copy@huc-copy:
- fi-skl-6600u:   NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111964v1/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111964v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111964v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-bsw-nick:NOTRUN -> [SKIP][6] ([fdo#109271]) +39 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111964v1/fi-bsw-nick/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_lmem_swapping@random-engines:
- fi-bsw-n3050:   NOTRUN -> [SKIP][7] ([fdo#109271]) +20 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111964v1/fi-bsw-n3050/igt@gem_lmem_swapp...@random-engines.html
- fi-skl-6600u:   NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111964v1/fi-skl-6600u/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_lmem_swapping@verify-random:
- bat-adlp-4: NOTRUN -> [SKIP][9] ([i915#4613]) +3 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111964v1/bat-adlp-4/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_mmap@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][10] ([i915#4083])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111964v1/bat-dg1-5/igt@gem_m...@basic.html
- bat-dg1-6:  NOTRUN -> [SKIP][11] ([i915#4083])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111964v1/bat-dg1-6/igt@gem_m...@basic.html

  * igt@gem_render_tiled_blits@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][12] ([i915#4079]) +1 similar issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111964v1/bat-dg1-6/igt@gem_render_tiled_bl...@basic.html

  * igt@gem_tiled_fence_blits@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][13] ([i915#4077]) +2 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111964v1/bat-dg1-6/igt@gem_tiled_fence_bl...@basic.html
- bat-dg1-5:  NOTRUN -> [SKIP][14] ([i915#4077]) +2 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111964v1/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-dg1-5:  NOTRUN -> [SKIP][15] ([i915#4079]) +1 similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111964v1/bat-dg1-5/igt@gem_tiled_pread_basic.html
- bat-adlp-4: NOTRUN -> [SKIP][16] ([i915#3282])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111964v1/bat-adlp-4/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- bat-dg1-6:  NOTRUN -> [SKIP][17] ([i915#7561])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111964v1/bat-dg1-6/igt@i915_pm_backli...@basic-brightness.html
- bat-dg1-5:  NOTRUN -> [SKIP][18] ([i915#7561])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111964v1/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_pm_rps@basic-api:
- bat-dg1-6:  NOTRUN -> [SKIP][19] ([i915#6621])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111

[Intel-gfx] [PATCH 2/2] drm/i915/dp_mst: don't pull unregistered connectors into state

2022-12-15 Thread Simon Ser
In intel_dp_mst_atomic_master_trans_check(), we pull connectors
sharing the same DP-MST stream into the atomic state. However,
if the connector is unregistered, this later fails with:

[  559.425658] i915 :00:02.0: [drm:drm_atomic_helper_check_modeset] 
[CONNECTOR:378:DP-7] is not registered

Skip these unregistered connectors to allow user-space to turn them
off.

Fixes part of this wlroots issue:
https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3407

Signed-off-by: Simon Ser 
Cc: Ville Syrjälä 
Cc: Jani Nikula 
Cc: Lyude Paul 
---
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index f773e117ebc4..70859a927a9d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -280,7 +280,8 @@ intel_dp_mst_atomic_master_trans_check(struct 
intel_connector *connector,
struct intel_crtc *crtc;
 
if (connector_iter->mst_port != connector->mst_port ||
-   connector_iter == connector)
+   connector_iter == connector ||
+   connector_iter->base.registration_state == 
DRM_CONNECTOR_UNREGISTERED)
continue;
 
conn_iter_state = 
intel_atomic_get_digital_connector_state(state,
-- 
2.39.0




[Intel-gfx] [PATCH 1/2] drm/i915/dp_mst: log when pulling CRTCs into atomic state

2022-12-15 Thread Simon Ser
It can be surprising for user-space to see unrelated connectors,
CRTCs and planes being implicitly pulled into the atomic commit.
Log when that happens.

Signed-off-by: Simon Ser 
Cc: Ville Syrjälä 
Cc: Jani Nikula 
Cc: Lyude Paul 
---
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 4077a979a924..f773e117ebc4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -293,6 +293,10 @@ intel_dp_mst_atomic_master_trans_check(struct 
intel_connector *connector,
if (!conn_iter_state->base.crtc)
continue;
 
+   drm_dbg_kms(&dev_priv->drm,
+   "Adding [CONNECTOR:%d:%s] which shares the same 
DP-MST stream\n",
+   connector_iter->base.base.id, 
connector_iter->base.name);
+
crtc = to_intel_crtc(conn_iter_state->base.crtc);
crtc_state = intel_atomic_get_crtc_state(&state->base, crtc);
if (IS_ERR(crtc_state)) {
-- 
2.39.0




[Intel-gfx] ✓ Fi.CI.BAT: success for Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation

2022-12-15 Thread Patchwork
== Series Details ==

Series: Fixes integer overflow or integer truncation issues in page lookups, 
ttm place configuration and scatterlist creation
URL   : https://patchwork.freedesktop.org/series/111963/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12510 -> Patchwork_111963v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (19 -> 41)
--

  Additional (22): fi-kbl-soraka bat-dg1-6 bat-dg1-5 bat-adlp-6 bat-rpls-1 
bat-rpls-2 fi-skl-6600u fi-bsw-n3050 bat-dg2-8 bat-adlm-1 bat-dg2-9 fi-bwr-2160 
bat-adln-1 bat-atsm-1 bat-jsl-3 bat-rplp-1 bat-dg2-11 fi-bsw-nick bat-dg1-7 
bat-kbl-2 bat-adlp-9 bat-adlp-4 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@coherency:
- {bat-jsl-3}:NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111963v1/bat-jsl-3/igt@i915_selftest@l...@coherency.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-b-hdmi-a-1:
- {bat-rpls-2}:   NOTRUN -> [FAIL][2] +1 similar issue
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111963v1/bat-rpls-2/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-hdmi-a-1.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-adlp-4: NOTRUN -> [SKIP][3] ([i915#7456])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111963v1/bat-adlp-4/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_exec_gttfill@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][4] ([fdo#109271]) +7 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111963v1/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html

  * igt@gem_huc_copy@huc-copy:
- fi-skl-6600u:   NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111963v1/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111963v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111963v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-bsw-nick:NOTRUN -> [SKIP][8] ([fdo#109271]) +39 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111963v1/fi-bsw-nick/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_lmem_swapping@random-engines:
- fi-bsw-n3050:   NOTRUN -> [SKIP][9] ([fdo#109271]) +20 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111963v1/fi-bsw-n3050/igt@gem_lmem_swapp...@random-engines.html
- fi-skl-6600u:   NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111963v1/fi-skl-6600u/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_lmem_swapping@verify-random:
- bat-adlp-4: NOTRUN -> [SKIP][11] ([i915#4613]) +3 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111963v1/bat-adlp-4/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_mmap@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][12] ([i915#4083])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111963v1/bat-dg1-5/igt@gem_m...@basic.html
- bat-dg1-6:  NOTRUN -> [SKIP][13] ([i915#4083])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111963v1/bat-dg1-6/igt@gem_m...@basic.html

  * igt@gem_render_tiled_blits@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][14] ([i915#4079]) +1 similar issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111963v1/bat-dg1-6/igt@gem_render_tiled_bl...@basic.html

  * igt@gem_tiled_fence_blits@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][15] ([i915#4077]) +2 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111963v1/bat-dg1-6/igt@gem_tiled_fence_bl...@basic.html
- bat-dg1-5:  NOTRUN -> [SKIP][16] ([i915#4077]) +2 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111963v1/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-dg1-5:  NOTRUN -> [SKIP][17] ([i915#4079]) +1 similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11

Re: [Intel-gfx] [PATCH v15 1/7] overflow: Introduce overflows_type() and castable_to_type()

2022-12-15 Thread Andrzej Hajda




On 15.12.2022 13:52, Gwan-gyeong Mun wrote:

From: Kees Cook 

Implement a robust overflows_type() macro to test if a variable or
constant value would overflow another variable or type. This can be
used as a constant expression for static_assert() (which requires a
constant expression[1][2]) when used on constant values. This must be
constructed manually, since __builtin_add_overflow() does not produce
a constant expression[3].

Additionally adds castable_to_type(), similar to __same_type(), but for
checking if a constant value would overflow if cast to a given type.

Add unit tests for overflows_type(), __same_type(), and castable_to_type()
to the existing KUnit "overflow" test:

[16:03:33] == overflow (21 subtests) ==
...
[16:03:33] [PASSED] overflows_type_test
[16:03:33] [PASSED] same_type_test
[16:03:33] [PASSED] castable_to_type_test
[16:03:33]  [PASSED] overflow =
[16:03:33] 
[16:03:33] Testing complete. Ran 21 tests: passed: 21
[16:03:33] Elapsed time: 24.022s total, 0.002s configuring, 22.598s building, 
0.767s running

[1] https://en.cppreference.com/w/c/language/_Static_assert
[2] C11 standard (ISO/IEC 9899:2011): 6.7.10 Static assertions
[3] https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
 6.56 Built-in Functions to Perform Arithmetic with Overflow Checking
 Built-in Function: bool __builtin_add_overflow (type1 a, type2 b,

Cc: Luc Van Oostenryck 
Cc: Nathan Chancellor 
Cc: Nick Desaulniers 
Cc: Tom Rix 
Cc: Daniel Latypov 
Cc: Vitor Massaru Iha 
Cc: "Gustavo A. R. Silva" 
Cc: Jani Nikula 
Cc: Mauro Carvalho Chehab 
Cc: linux-harden...@vger.kernel.org
Cc: l...@lists.linux.dev
Co-developed-by: Gwan-gyeong Mun 
Signed-off-by: Gwan-gyeong Mun 
Signed-off-by: Kees Cook 
Link: 
https://lore.kernel.org/r/20221024201125.1416422-1-gwan-gyeong@intel.com
---
  drivers/gpu/drm/i915/i915_user_extensions.c |   2 +-
  drivers/gpu/drm/i915/i915_utils.h   |   4 -
  include/linux/compiler.h|   1 +
  include/linux/overflow.h|  48 +++
  lib/Makefile|   1 +
  lib/overflow_kunit.c| 381 
  6 files changed, 432 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_user_extensions.c 
b/drivers/gpu/drm/i915/i915_user_extensions.c
index c822d0aafd2d..e3f808372c47 100644
--- a/drivers/gpu/drm/i915/i915_user_extensions.c
+++ b/drivers/gpu/drm/i915/i915_user_extensions.c
@@ -51,7 +51,7 @@ int i915_user_extensions(struct i915_user_extension __user 
*ext,
return err;
  
  		if (get_user(next, &ext->next_extension) ||

-   overflows_type(next, ext))
+   overflows_type(next, uintptr_t))
return -EFAULT;
  
  		ext = u64_to_user_ptr(next);

diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
index b64192d9c7da..2c430c0c3bad 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -111,10 +111,6 @@ bool i915_error_injected(void);
  #define range_overflows_end_t(type, start, size, max) \
range_overflows_end((type)(start), (type)(size), (type)(max))
  
-/* Note we don't consider signbits :| */

-#define overflows_type(x, T) \
-   (sizeof(x) > sizeof(T) && (x) >> BITS_PER_TYPE(T))
-
  #define ptr_mask_bits(ptr, n) ({  \
unsigned long __v = (unsigned long)(ptr);   \
(typeof(ptr))(__v & -BIT(n));   \
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 973a1bfd7ef5..947a60b801db 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -236,6 +236,7 @@ static inline void *offset_to_ptr(const int *off)
   * bool and also pointer types.
   */
  #define is_signed_type(type) (((type)(-1)) < (__force type)1)
+#define is_unsigned_type(type) (!is_signed_type(type))
  
  /*

   * This is needed in functions which generate the stack canary, see
diff --git a/include/linux/overflow.h b/include/linux/overflow.h
index 1d3be1a2204c..16ae8d912390 100644
--- a/include/linux/overflow.h
+++ b/include/linux/overflow.h
@@ -128,6 +128,54 @@ static inline bool __must_check __must_check_overflow(bool 
overflow)
(*_d >> _to_shift) != _a);\
  }))
  
+#define __overflows_type_constexpr(x, T) (			\

+   is_unsigned_type(typeof(x)) ?   \
+   (x) > type_max(typeof(T)) ? 1 : 0\
+   : is_unsigned_type(typeof(T)) ? \
+   (x) < 0 || (x) > type_max(typeof(T)) ? 1 : 0  \
+   : (x) < type_min(typeof(T)) ||   \
+ (x) > type_max(typeof(T)) ? 1 : 0)


Syntactically seems fine, but I am little b

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation

2022-12-15 Thread Patchwork
== Series Details ==

Series: Fixes integer overflow or integer truncation issues in page lookups, 
ttm place configuration and scatterlist creation
URL   : https://patchwork.freedesktop.org/series/111963/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation

2022-12-15 Thread Patchwork
== Series Details ==

Series: Fixes integer overflow or integer truncation issues in page lookups, 
ttm place configuration and scatterlist creation
URL   : https://patchwork.freedesktop.org/series/111963/
State : warning

== Summary ==

Error: dim checkpatch failed
e789a2f6d47e overflow: Introduce overflows_type() and castable_to_type()
-:27: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#27: 
[16:03:33] Elapsed time: 24.022s total, 0.002s configuring, 22.598s building, 
0.767s running

-:99: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'x' - possible side-effects?
#99: FILE: include/linux/overflow.h:131:
+#define __overflows_type_constexpr(x, T) ( \
+   is_unsigned_type(typeof(x)) ?   \
+   (x) > type_max(typeof(T)) ? 1 : 0   \
+   : is_unsigned_type(typeof(T)) ? \
+   (x) < 0 || (x) > type_max(typeof(T)) ? 1 : 0\
+   : (x) < type_min(typeof(T)) ||  \
+ (x) > type_max(typeof(T)) ? 1 : 0)

-:100: CHECK:SPACING: No space is necessary after a cast
#100: FILE: include/linux/overflow.h:132:
+   is_unsigned_type(typeof(x)) ?   \

-:101: CHECK:SPACING: No space is necessary after a cast
#101: FILE: include/linux/overflow.h:133:
+   (x) > type_max(typeof(T)) ? 1 : 0   \

-:102: CHECK:SPACING: No space is necessary after a cast
#102: FILE: include/linux/overflow.h:134:
+   : is_unsigned_type(typeof(T)) ? \

-:103: CHECK:SPACING: No space is necessary after a cast
#103: FILE: include/linux/overflow.h:135:
+   (x) < 0 || (x) > type_max(typeof(T)) ? 1 : 0\

-:104: CHECK:SPACING: No space is necessary after a cast
#104: FILE: include/linux/overflow.h:136:
+   : (x) < type_min(typeof(T)) ||  \

-:105: CHECK:SPACING: No space is necessary after a cast
#105: FILE: include/linux/overflow.h:137:
+ (x) > type_max(typeof(T)) ? 1 : 0)

-:126: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'n' - possible side-effects?
#126: FILE: include/linux/overflow.h:158:
+#define overflows_type(n, T)   \
+   __builtin_choose_expr(__is_constexpr(n),\
+ __overflows_type_constexpr(n, T), \
+ __overflows_type(n, T))

-:126: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'T' - possible side-effects?
#126: FILE: include/linux/overflow.h:158:
+#define overflows_type(n, T)   \
+   __builtin_choose_expr(__is_constexpr(n),\
+ __overflows_type_constexpr(n, T), \
+ __overflows_type(n, T))

-:142: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'n' - possible side-effects?
#142: FILE: include/linux/overflow.h:174:
+#define castable_to_type(n, T) \
+   __builtin_choose_expr(__is_constexpr(n),\
+ !__overflows_type_constexpr(n, T),\
+ __same_type(n, T))

-:142: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'T' - possible side-effects?
#142: FILE: include/linux/overflow.h:174:
+#define castable_to_type(n, T) \
+   __builtin_choose_expr(__is_constexpr(n),\
+ !__overflows_type_constexpr(n, T),\
+ __same_type(n, T))

-:175: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'of' - possible side-effects?
#175: FILE: lib/overflow_kunit.c:744:
+#define __TEST_OVERFLOWS_TYPE(func, arg1, arg2, of)do {\
+   bool __of = func(arg1, arg2);   \
+   KUNIT_EXPECT_EQ_MSG(test, __of, of, \
+   "expected " #func "(" #arg1 ", " #arg2 " to%s overflow\n",\
+   of ? "" : " not");  \
+   count++;\
+} while (0)

-:184: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__t2' - possible 
side-effects?
#184: FILE: lib/overflow_kunit.c:753:
+#define TEST_OVERFLOWS_TYPE(__t1, __t2, v, of) do {\
+   __t1 t1 = (v);  \
+   __t2 t2;\
+   __TEST_OVERFLOWS_TYPE(__overflows_type, t1, t2, of);\
+   __TEST_OVERFLOWS_TYPE(__overflows_type, t1, __t2, of);  \
+   __TEST_OVERFLOWS_TYPE(__overflows_type_constexpr, t1, t2, of);  \
+   __TEST_OVERFLOWS_TYPE(__overflows_type_constexpr, t1, __t2, of);\
+} while (0)

-:184: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'of' - possible side-effects?
#184: FILE: lib/overflow_kunit.c:753:
+#d

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: wait on timeout before retry include sw delay (rev8)

2022-12-15 Thread Patchwork
== Series Details ==

Series: drm/i915/dp: wait on timeout before retry include sw delay (rev8)
URL   : https://patchwork.freedesktop.org/series/111303/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12510 -> Patchwork_111303v8


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (19 -> 40)
--

  Additional (21): fi-kbl-soraka bat-dg1-6 bat-dg1-5 bat-adlp-6 bat-rpls-1 
bat-rpls-2 fi-skl-6600u fi-bsw-n3050 bat-dg2-8 bat-adlm-1 bat-dg2-9 bat-adln-1 
bat-atsm-1 bat-jsl-3 bat-rplp-1 bat-dg2-11 fi-bsw-nick bat-dg1-7 bat-kbl-2 
bat-adlp-9 bat-adlp-4 

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-snb-2600:[PASS][1] -> [FAIL][2] ([i915#4338])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12510/fi-snb-2600/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v8/fi-snb-2600/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-adlp-4: NOTRUN -> [SKIP][3] ([i915#7456])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v8/bat-adlp-4/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_exec_gttfill@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][4] ([fdo#109271]) +7 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v8/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html
- fi-pnv-d510:[PASS][5] -> [FAIL][6] ([i915#7229])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12510/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v8/fi-pnv-d510/igt@gem_exec_gttf...@basic.html

  * igt@gem_huc_copy@huc-copy:
- fi-skl-6600u:   NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v8/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#2190])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v8/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v8/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-bsw-nick:NOTRUN -> [SKIP][10] ([fdo#109271]) +39 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v8/fi-bsw-nick/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_lmem_swapping@random-engines:
- fi-bsw-n3050:   NOTRUN -> [SKIP][11] ([fdo#109271]) +20 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v8/fi-bsw-n3050/igt@gem_lmem_swapp...@random-engines.html
- fi-skl-6600u:   NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v8/fi-skl-6600u/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_lmem_swapping@verify-random:
- bat-adlp-4: NOTRUN -> [SKIP][13] ([i915#4613]) +3 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v8/bat-adlp-4/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_mmap@basic:
- bat-dg1-5:  NOTRUN -> [SKIP][14] ([i915#4083])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v8/bat-dg1-5/igt@gem_m...@basic.html
- bat-dg1-6:  NOTRUN -> [SKIP][15] ([i915#4083])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v8/bat-dg1-6/igt@gem_m...@basic.html

  * igt@gem_render_tiled_blits@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][16] ([i915#4079]) +1 similar issue
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v8/bat-dg1-6/igt@gem_render_tiled_bl...@basic.html

  * igt@gem_tiled_fence_blits@basic:
- bat-dg1-6:  NOTRUN -> [SKIP][17] ([i915#4077]) +2 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v8/bat-dg1-6/igt@gem_tiled_fence_bl...@basic.html
- bat-dg1-5:  NOTRUN -> [SKIP][18] ([i915#4077]) +2 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v8/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-dg1-5:  NOTRUN -> [SKIP][19] ([i915#4079]) +1 similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v8/bat-dg1-5/igt@gem_tiled_pread_basic.html
- bat-adlp-4: NOTRUN -> [SKIP][20] ([i915#3282])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v8/bat-adlp-4/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlig

Re: [Intel-gfx] [PATCH 6/9] drm/qxl: stop using ttm_bo_wait

2022-12-15 Thread Christian König

Am 25.11.22 um 11:21 schrieb Christian König:

TTM is just wrapping core DMA functionality here, remove the mid-layer.
No functional change.


Any objections to this guys?

I'm basically just following a suggestion from Daniel here and it 
already triggered a discussion about the timeout for i915.


Thanks,
Christian.



Signed-off-by: Christian König 
---
  drivers/gpu/drm/qxl/qxl_cmd.c | 16 ++--
  1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_cmd.c b/drivers/gpu/drm/qxl/qxl_cmd.c
index 63aa96a69752..281edab518cd 100644
--- a/drivers/gpu/drm/qxl/qxl_cmd.c
+++ b/drivers/gpu/drm/qxl/qxl_cmd.c
@@ -579,7 +579,7 @@ void qxl_surface_evict(struct qxl_device *qdev, struct 
qxl_bo *surf, bool do_upd
  
  static int qxl_reap_surf(struct qxl_device *qdev, struct qxl_bo *surf, bool stall)

  {
-   int ret;
+   long ret;
  
  	ret = qxl_bo_reserve(surf);

if (ret)
@@ -588,7 +588,19 @@ static int qxl_reap_surf(struct qxl_device *qdev, struct 
qxl_bo *surf, bool stal
if (stall)
mutex_unlock(&qdev->surf_evict_mutex);
  
-	ret = ttm_bo_wait(&surf->tbo, true, !stall);

+   if (stall) {
+   ret = dma_resv_wait_timeout(surf->tbo.base.resv,
+   DMA_RESV_USAGE_BOOKKEEP, true,
+   15 * HZ);
+   if (ret > 0)
+   ret = 0;
+   else if (ret == 0)
+   ret = -EBUSY;
+   } else {
+   ret = dma_resv_test_signaled(surf->tbo.base.resv,
+DMA_RESV_USAGE_BOOKKEEP);
+   ret = ret ? -EBUSY : 0;
+   }
  
  	if (stall)

mutex_lock(&qdev->surf_evict_mutex);




[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/dp: wait on timeout before retry include sw delay (rev8)

2022-12-15 Thread Patchwork
== Series Details ==

Series: drm/i915/dp: wait on timeout before retry include sw delay (rev8)
URL   : https://patchwork.freedesktop.org/series/111303/
State : warning

== Summary ==

Error: make htmldocs had i915 warnings
./drivers/gpu/drm/i915/display/intel_dsb.c:201: warning: Excess function 
parameter 'crtc_state' description in 'intel_dsb_reg_write'
./drivers/gpu/drm/i915/display/intel_dsb.c:201: warning: Function parameter or 
member 'dsb' not described in 'intel_dsb_reg_write'
./drivers/gpu/drm/i915/display/intel_dsb.c:201: warning: Excess function 
parameter 'crtc_state' description in 'intel_dsb_reg_write'




Re: [Intel-gfx] [PATCH v3] drm/i915/gvt: fix double free bug in split_2MB_gtt_entry

2022-12-15 Thread Zheng Hacker
Hi Zhi,

Thanks for your reply and suggestion about fix. I am a little bit busy now.
I will review the code as soon as possible. Also thanks
Joonas for the reminding. We'll try to think out the new fix.

Best regards,
Zheng Wang


Re: [Intel-gfx] [PATCH v4] drm/i915/dsi: add support for ICL+ native MIPI GPIO sequence

2022-12-15 Thread Jani Nikula
On Wed, 14 Dec 2022, Ville Syrjälä  wrote:
> On Tue, Dec 13, 2022 at 11:59:24AM +0200, Jani Nikula wrote:
>> Starting from ICL, the default for MIPI GPIO sequences seems to be using
>> native GPIOs i.e. GPIOs available in the GPU. These native GPIOs reuse
>> many pins that quite frankly seem scary to poke based on the VBT
>> sequences. We pretty much have to trust that the board is configured
>> such that the relevant HPD, PP_CONTROL and GPIO bits aren't used for
>> anything else.
>> 
>> MIPI sequence v4 also adds a flag to fall back to non-native sequences.
>> 
>> v4:
>> - Wrap SHOTPLUG_CTL_DDI modification in spin_lock_irq() (Ville)
>> 
>> v3:
>> - Fix -Wbitwise-conditional-parentheses (kernel test robot )
>> 
>> v2:
>> - Fix HPD pin output set (impacts GPIOs 0 and 5)
>> - Fix GPIO data output direction set (impacts GPIOs 4 and 9)
>> - Reduce register accesses to single intel_de_rwm()
>> 
>> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6131
>> Cc: Ville Syrjälä 
>> Signed-off-by: Jani Nikula 
>> ---
>>  drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 94 +++-
>>  drivers/gpu/drm/i915/i915_reg.h  |  1 +
>>  2 files changed, 92 insertions(+), 3 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c 
>> b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
>> index fce69fa446d5..41f025f089d9 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
>> @@ -41,9 +41,11 @@
>>  
>>  #include "i915_drv.h"
>>  #include "i915_reg.h"
>> +#include "intel_de.h"
>>  #include "intel_display_types.h"
>>  #include "intel_dsi.h"
>>  #include "intel_dsi_vbt.h"
>> +#include "intel_gmbus_regs.h"
>>  #include "vlv_dsi.h"
>>  #include "vlv_dsi_regs.h"
>>  #include "vlv_sideband.h"
>> @@ -377,6 +379,85 @@ static void icl_exec_gpio(struct intel_connector 
>> *connector,
>>  drm_dbg_kms(&dev_priv->drm, "Skipping ICL GPIO element execution\n");
>>  }
>>  
>> +enum {
>> +MIPI_RESET_1 = 0,
>> +MIPI_AVDD_EN_1,
>> +MIPI_BKLT_EN_1,
>> +MIPI_AVEE_EN_1,
>> +MIPI_VIO_EN_1,
>> +MIPI_RESET_2,
>> +MIPI_AVDD_EN_2,
>> +MIPI_BKLT_EN_2,
>> +MIPI_AVEE_EN_2,
>> +MIPI_VIO_EN_2,
>> +};
>> +
>> +static void icl_native_gpio_set_value(struct drm_i915_private *dev_priv,
>> +  int gpio, bool value)
>> +{
>> +int index;
>> +
>> +if (drm_WARN_ON(&dev_priv->drm, DISPLAY_VER(dev_priv) == 11 && gpio >= 
>> MIPI_RESET_2))
>> +return;
>> +
>> +switch (gpio) {
>> +case MIPI_RESET_1:
>> +case MIPI_RESET_2:
>> +index = gpio == MIPI_RESET_1 ? HPD_PORT_A : HPD_PORT_B;
>> +
>> +/*
>> + * Disable HPD to set the pin to output, and set output
>> + * value. The HPD pin should not be enabled for DSI anyway,
>> + * assuming the board design and VBT are sane, and the pin isn't
>> + * used by a non-DSI encoder.
>> + *
>> + * The locking protects against concurrent SHOTPLUG_CTL_DDI
>> + * modifications in irq setup and handling.
>> + */
>
> The rmw in icp_irq_handler() doesn't seem to have the required locking.

Drat! I seem to have thought that's not necessary in the irq handler for
some reason.

spin_lock() there enough?

I'm wondering if the hpd stuff should be switched to a separate spin
lock. The irq lock seems like a too big hammer for this. But that's for
another series, another time.

BR,
Jani.


>
>> +spin_lock_irq(&dev_priv->irq_lock);
>> +intel_de_rmw(dev_priv, SHOTPLUG_CTL_DDI,
>> + SHOTPLUG_CTL_DDI_HPD_ENABLE(index) |
>> + SHOTPLUG_CTL_DDI_HPD_OUTPUT_DATA(index),
>> + value ? SHOTPLUG_CTL_DDI_HPD_OUTPUT_DATA(index) : 
>> 0);
>> +spin_unlock_irq(&dev_priv->irq_lock);
>> +break;
>> +case MIPI_AVDD_EN_1:
>> +case MIPI_AVDD_EN_2:
>> +index = gpio == MIPI_AVDD_EN_1 ? 0 : 1;
>> +
>> +intel_de_rmw(dev_priv, PP_CONTROL(index), PANEL_POWER_ON,
>> + value ? PANEL_POWER_ON : 0);
>> +break;
>> +case MIPI_BKLT_EN_1:
>> +case MIPI_BKLT_EN_2:
>> +index = gpio == MIPI_AVDD_EN_1 ? 0 : 1;
>> +
>> +intel_de_rmw(dev_priv, PP_CONTROL(index), EDP_BLC_ENABLE,
>> + value ? EDP_BLC_ENABLE : 0);
>> +break;
>> +case MIPI_AVEE_EN_1:
>> +case MIPI_AVEE_EN_2:
>> +index = gpio == MIPI_AVEE_EN_1 ? 1 : 2;
>> +
>> +intel_de_rmw(dev_priv, GPIO(dev_priv, index),
>> + GPIO_CLOCK_VAL_OUT,
>> + GPIO_CLOCK_DIR_MASK | GPIO_CLOCK_DIR_OUT |
>> + GPIO_CLOCK_VAL_MASK | (value ? GPIO_CLOCK_VAL_OUT 
>> : 0));
>> +break;
>> +case MIPI_VIO_EN_1:
>> +case MIPI_VIO_EN_2:
>> +index = gpio == MIPI

Re: [Intel-gfx] [PATCH] drm/i915/display/fdi: use intel_de_rmw if possible

2022-12-15 Thread Jani Nikula
On Thu, 15 Dec 2022, Andrzej Hajda  wrote:
> The helper makes the code more compact and readable.
>
> Signed-off-by: Andrzej Hajda 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/intel_fdi.c | 148 +++
>  1 file changed, 44 insertions(+), 104 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fdi.c 
> b/drivers/gpu/drm/i915/display/intel_fdi.c
> index 063f1da4f229cf..f62d9a9313498c 100644
> --- a/drivers/gpu/drm/i915/display/intel_fdi.c
> +++ b/drivers/gpu/drm/i915/display/intel_fdi.c
> @@ -439,19 +439,11 @@ static void ilk_fdi_link_train(struct intel_crtc *crtc,
>   drm_err(&dev_priv->drm, "FDI train 1 fail!\n");
>  
>   /* Train 2 */
> - reg = FDI_TX_CTL(pipe);
> - temp = intel_de_read(dev_priv, reg);
> - temp &= ~FDI_LINK_TRAIN_NONE;
> - temp |= FDI_LINK_TRAIN_PATTERN_2;
> - intel_de_write(dev_priv, reg, temp);
> -
> - reg = FDI_RX_CTL(pipe);
> - temp = intel_de_read(dev_priv, reg);
> - temp &= ~FDI_LINK_TRAIN_NONE;
> - temp |= FDI_LINK_TRAIN_PATTERN_2;
> - intel_de_write(dev_priv, reg, temp);
> -
> - intel_de_posting_read(dev_priv, reg);
> + intel_de_rmw(dev_priv, FDI_TX_CTL(pipe),
> +  FDI_LINK_TRAIN_NONE, FDI_LINK_TRAIN_PATTERN_2);
> + intel_de_rmw(dev_priv, FDI_RX_CTL(pipe),
> +  FDI_LINK_TRAIN_NONE, FDI_LINK_TRAIN_PATTERN_2);
> + intel_de_posting_read(dev_priv, FDI_RX_CTL(pipe));
>   udelay(150);
>  
>   reg = FDI_RX_IIR(pipe);
> @@ -538,13 +530,9 @@ static void gen6_fdi_link_train(struct intel_crtc *crtc,
>   udelay(150);
>  
>   for (i = 0; i < 4; i++) {
> - reg = FDI_TX_CTL(pipe);
> - temp = intel_de_read(dev_priv, reg);
> - temp &= ~FDI_LINK_TRAIN_VOL_EMP_MASK;
> - temp |= snb_b_fdi_train_param[i];
> - intel_de_write(dev_priv, reg, temp);
> -
> - intel_de_posting_read(dev_priv, reg);
> + intel_de_rmw(dev_priv, FDI_TX_CTL(pipe),
> +  FDI_LINK_TRAIN_VOL_EMP_MASK, 
> snb_b_fdi_train_param[i]);
> + intel_de_posting_read(dev_priv, FDI_TX_CTL(pipe));
>   udelay(500);
>  
>   for (retry = 0; retry < 5; retry++) {
> @@ -593,13 +581,9 @@ static void gen6_fdi_link_train(struct intel_crtc *crtc,
>   udelay(150);
>  
>   for (i = 0; i < 4; i++) {
> - reg = FDI_TX_CTL(pipe);
> - temp = intel_de_read(dev_priv, reg);
> - temp &= ~FDI_LINK_TRAIN_VOL_EMP_MASK;
> - temp |= snb_b_fdi_train_param[i];
> - intel_de_write(dev_priv, reg, temp);
> -
> - intel_de_posting_read(dev_priv, reg);
> + intel_de_rmw(dev_priv, FDI_TX_CTL(pipe),
> +  FDI_LINK_TRAIN_VOL_EMP_MASK, 
> snb_b_fdi_train_param[i]);
> + intel_de_posting_read(dev_priv, FDI_TX_CTL(pipe));
>   udelay(500);
>  
>   for (retry = 0; retry < 5; retry++) {
> @@ -719,19 +703,13 @@ static void ivb_manual_fdi_link_train(struct intel_crtc 
> *crtc,
>   }
>  
>   /* Train 2 */
> - reg = FDI_TX_CTL(pipe);
> - temp = intel_de_read(dev_priv, reg);
> - temp &= ~FDI_LINK_TRAIN_NONE_IVB;
> - temp |= FDI_LINK_TRAIN_PATTERN_2_IVB;
> - intel_de_write(dev_priv, reg, temp);
> -
> - reg = FDI_RX_CTL(pipe);
> - temp = intel_de_read(dev_priv, reg);
> - temp &= ~FDI_LINK_TRAIN_PATTERN_MASK_CPT;
> - temp |= FDI_LINK_TRAIN_PATTERN_2_CPT;
> - intel_de_write(dev_priv, reg, temp);
> -
> - intel_de_posting_read(dev_priv, reg);
> + intel_de_rmw(dev_priv, FDI_TX_CTL(pipe),
> +  FDI_LINK_TRAIN_NONE_IVB,
> +  FDI_LINK_TRAIN_PATTERN_2_IVB);
> + intel_de_rmw(dev_priv, FDI_RX_CTL(pipe),
> +  FDI_LINK_TRAIN_PATTERN_MASK_CPT,
> +  FDI_LINK_TRAIN_PATTERN_2_CPT);
> + intel_de_posting_read(dev_priv, FDI_RX_CTL(pipe));
>   udelay(2); /* should be 1.5us */
>  
>   for (i = 0; i < 4; i++) {
> @@ -837,9 +815,8 @@ void hsw_fdi_link_train(struct intel_encoder *encoder,
>   udelay(30);
>  
>   /* Unset FDI_RX_MISC pwrdn lanes */
> - temp = intel_de_read(dev_priv, FDI_RX_MISC(PIPE_A));
> - temp &= ~(FDI_RX_PWRDN_LANE1_MASK | FDI_RX_PWRDN_LANE0_MASK);
> - intel_de_write(dev_priv, FDI_RX_MISC(PIPE_A), temp);
> + intel_de_rmw(dev_priv, FDI_RX_MISC(PIPE_A),
> +  FDI_RX_PWRDN_LANE1_MASK | FDI_RX_PWRDN_LANE0_MASK, 
> 0);
>   intel_de_posting_read(dev_priv, FDI_RX_MISC(PIPE_A));
>  
>   /* Wait for FDI auto training time */
> @@ -865,25 +842,21 @@ void hsw_fdi_link_train(struct intel_encoder *encoder,
>   intel_de_write

Re: [Intel-gfx] [PATCH 3/4] drm/i915/mtl: Define new PTE encode for MTL

2022-12-15 Thread Das, Nirmoy

Hi Aravind,

On 12/6/2022 8:37 AM, Aravind Iddamsetty wrote:

Add a separate PTE encode function for MTL. The number of PAT registers
have increased to 16 on MTL. All 16 PAT registers are available for
PPGTT mapped pages, but only the lower 4 are available for GGTT mapped
pages.

BSPEC: 63884

Cc: Lucas De Marchi 
Cc: Matt Roper 
Co-developed-by: Fei Yang 
Signed-off-by: Fei Yang 
Signed-off-by: Aravind Iddamsetty 
---
  drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 33 +++-
  drivers/gpu/drm/i915/gt/gen8_ppgtt.h |  4 
  drivers/gpu/drm/i915/gt/intel_ggtt.c | 32 ++-
  drivers/gpu/drm/i915/gt/intel_gtt.h  | 13 +--
  4 files changed, 78 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 31e838eee2ef..4197b43150cc 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -55,6 +55,34 @@ static u64 gen8_pte_encode(dma_addr_t addr,
return pte;
  }
  
+static u64 mtl_pte_encode(dma_addr_t addr,

+ enum i915_cache_level level,
+ u32 flags)
+{
+   gen8_pte_t pte = addr | GEN8_PAGE_PRESENT | GEN8_PAGE_RW;
+
+   if (unlikely(flags & PTE_READ_ONLY))
+   pte &= ~GEN8_PAGE_RW;
+
+   if (flags & PTE_LM)


PTE_LM shouldn't be applicable for MTL, see below.


+   pte |= GEN12_PPGTT_PTE_LM | GEN12_PPGTT_PTE_NC;
+
+   switch (level) {
+   case I915_CACHE_NONE:
+   pte |= GEN12_PPGTT_PTE_PAT1;
+   break;
+   case I915_CACHE_LLC:
+   case I915_CACHE_L3_LLC:
+   pte |= GEN12_PPGTT_PTE_PAT0 | GEN12_PPGTT_PTE_PAT1;
+   break;
+   case I915_CACHE_WT:
+   pte |= GEN12_PPGTT_PTE_PAT0;
+   break;
+   }
+
+   return pte;
+}
+
  static void gen8_ppgtt_notify_vgt(struct i915_ppgtt *ppgtt, bool create)
  {
struct drm_i915_private *i915 = ppgtt->vm.i915;
@@ -963,7 +991,10 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt,
 */
ppgtt->vm.alloc_scratch_dma = alloc_pt_dma;
  
-	ppgtt->vm.pte_encode = gen8_pte_encode;

+   if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
+   ppgtt->vm.pte_encode = mtl_pte_encode;


mtl_pte_encode() seems very specific for MTL but I assume it will be use for 
other platforms.
Please rename this function to a suitable one.

Nirmoy


+   else
+   ppgtt->vm.pte_encode = gen8_pte_encode;
  
  	ppgtt->vm.bind_async_flags = I915_VMA_LOCAL_BIND;

ppgtt->vm.insert_entries = gen8_ppgtt_insert;
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.h 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.h
index f541d19264b4..c48f1fc32909 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.h
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.h
@@ -19,4 +19,8 @@ u64 gen8_ggtt_pte_encode(dma_addr_t addr,
 enum i915_cache_level level,
 u32 flags);
  
+u64 mtl_ggtt_pte_encode(dma_addr_t addr,

+   enum i915_cache_level level,
+   u32 flags);
+
  #endif
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 82203ad85b0e..3b6f1f6f780a 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -246,6 +246,33 @@ static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
}
  }
  
+u64 mtl_ggtt_pte_encode(dma_addr_t addr,

+   enum i915_cache_level level,
+   u32 flags)
+{
+   gen8_pte_t pte = addr | GEN8_PAGE_PRESENT;
+
+   GEM_BUG_ON(addr & ~GEN12_GGTT_PTE_ADDR_MASK);
+
+   if (flags & PTE_LM)
+   pte |= GEN12_GGTT_PTE_LM;
+
+   switch (level) {
+   case I915_CACHE_NONE:
+   pte |= MTL_GGTT_PTE_PAT1;
+   break;
+   case I915_CACHE_LLC:
+   case I915_CACHE_L3_LLC:
+   pte |= MTL_GGTT_PTE_PAT0 | MTL_GGTT_PTE_PAT1;
+   break;
+   case I915_CACHE_WT:
+   pte |= MTL_GGTT_PTE_PAT0;
+   break;
+   }
+
+   return pte;
+}
+
  u64 gen8_ggtt_pte_encode(dma_addr_t addr,
 enum i915_cache_level level,
 u32 flags)
@@ -993,7 +1020,10 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.vma_ops.bind_vma= intel_ggtt_bind_vma;
ggtt->vm.vma_ops.unbind_vma  = intel_ggtt_unbind_vma;
  
-	ggtt->vm.pte_encode = gen8_ggtt_pte_encode;

+   if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
+   ggtt->vm.pte_encode = mtl_ggtt_pte_encode;

same here.

+   else
+   ggtt->vm.pte_encode = gen8_ggtt_pte_encode;
  
  	return ggtt_probe_common(ggtt, size);

  }
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 8a3e0a6793dd..4bb7a4005452 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/driver

[Intel-gfx] [PATCH] drm/i915/display/fdi: use intel_de_rmw if possible

2022-12-15 Thread Andrzej Hajda
The helper makes the code more compact and readable.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/display/intel_fdi.c | 148 +++
 1 file changed, 44 insertions(+), 104 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fdi.c 
b/drivers/gpu/drm/i915/display/intel_fdi.c
index 063f1da4f229cf..f62d9a9313498c 100644
--- a/drivers/gpu/drm/i915/display/intel_fdi.c
+++ b/drivers/gpu/drm/i915/display/intel_fdi.c
@@ -439,19 +439,11 @@ static void ilk_fdi_link_train(struct intel_crtc *crtc,
drm_err(&dev_priv->drm, "FDI train 1 fail!\n");
 
/* Train 2 */
-   reg = FDI_TX_CTL(pipe);
-   temp = intel_de_read(dev_priv, reg);
-   temp &= ~FDI_LINK_TRAIN_NONE;
-   temp |= FDI_LINK_TRAIN_PATTERN_2;
-   intel_de_write(dev_priv, reg, temp);
-
-   reg = FDI_RX_CTL(pipe);
-   temp = intel_de_read(dev_priv, reg);
-   temp &= ~FDI_LINK_TRAIN_NONE;
-   temp |= FDI_LINK_TRAIN_PATTERN_2;
-   intel_de_write(dev_priv, reg, temp);
-
-   intel_de_posting_read(dev_priv, reg);
+   intel_de_rmw(dev_priv, FDI_TX_CTL(pipe),
+FDI_LINK_TRAIN_NONE, FDI_LINK_TRAIN_PATTERN_2);
+   intel_de_rmw(dev_priv, FDI_RX_CTL(pipe),
+FDI_LINK_TRAIN_NONE, FDI_LINK_TRAIN_PATTERN_2);
+   intel_de_posting_read(dev_priv, FDI_RX_CTL(pipe));
udelay(150);
 
reg = FDI_RX_IIR(pipe);
@@ -538,13 +530,9 @@ static void gen6_fdi_link_train(struct intel_crtc *crtc,
udelay(150);
 
for (i = 0; i < 4; i++) {
-   reg = FDI_TX_CTL(pipe);
-   temp = intel_de_read(dev_priv, reg);
-   temp &= ~FDI_LINK_TRAIN_VOL_EMP_MASK;
-   temp |= snb_b_fdi_train_param[i];
-   intel_de_write(dev_priv, reg, temp);
-
-   intel_de_posting_read(dev_priv, reg);
+   intel_de_rmw(dev_priv, FDI_TX_CTL(pipe),
+FDI_LINK_TRAIN_VOL_EMP_MASK, 
snb_b_fdi_train_param[i]);
+   intel_de_posting_read(dev_priv, FDI_TX_CTL(pipe));
udelay(500);
 
for (retry = 0; retry < 5; retry++) {
@@ -593,13 +581,9 @@ static void gen6_fdi_link_train(struct intel_crtc *crtc,
udelay(150);
 
for (i = 0; i < 4; i++) {
-   reg = FDI_TX_CTL(pipe);
-   temp = intel_de_read(dev_priv, reg);
-   temp &= ~FDI_LINK_TRAIN_VOL_EMP_MASK;
-   temp |= snb_b_fdi_train_param[i];
-   intel_de_write(dev_priv, reg, temp);
-
-   intel_de_posting_read(dev_priv, reg);
+   intel_de_rmw(dev_priv, FDI_TX_CTL(pipe),
+FDI_LINK_TRAIN_VOL_EMP_MASK, 
snb_b_fdi_train_param[i]);
+   intel_de_posting_read(dev_priv, FDI_TX_CTL(pipe));
udelay(500);
 
for (retry = 0; retry < 5; retry++) {
@@ -719,19 +703,13 @@ static void ivb_manual_fdi_link_train(struct intel_crtc 
*crtc,
}
 
/* Train 2 */
-   reg = FDI_TX_CTL(pipe);
-   temp = intel_de_read(dev_priv, reg);
-   temp &= ~FDI_LINK_TRAIN_NONE_IVB;
-   temp |= FDI_LINK_TRAIN_PATTERN_2_IVB;
-   intel_de_write(dev_priv, reg, temp);
-
-   reg = FDI_RX_CTL(pipe);
-   temp = intel_de_read(dev_priv, reg);
-   temp &= ~FDI_LINK_TRAIN_PATTERN_MASK_CPT;
-   temp |= FDI_LINK_TRAIN_PATTERN_2_CPT;
-   intel_de_write(dev_priv, reg, temp);
-
-   intel_de_posting_read(dev_priv, reg);
+   intel_de_rmw(dev_priv, FDI_TX_CTL(pipe),
+FDI_LINK_TRAIN_NONE_IVB,
+FDI_LINK_TRAIN_PATTERN_2_IVB);
+   intel_de_rmw(dev_priv, FDI_RX_CTL(pipe),
+FDI_LINK_TRAIN_PATTERN_MASK_CPT,
+FDI_LINK_TRAIN_PATTERN_2_CPT);
+   intel_de_posting_read(dev_priv, FDI_RX_CTL(pipe));
udelay(2); /* should be 1.5us */
 
for (i = 0; i < 4; i++) {
@@ -837,9 +815,8 @@ void hsw_fdi_link_train(struct intel_encoder *encoder,
udelay(30);
 
/* Unset FDI_RX_MISC pwrdn lanes */
-   temp = intel_de_read(dev_priv, FDI_RX_MISC(PIPE_A));
-   temp &= ~(FDI_RX_PWRDN_LANE1_MASK | FDI_RX_PWRDN_LANE0_MASK);
-   intel_de_write(dev_priv, FDI_RX_MISC(PIPE_A), temp);
+   intel_de_rmw(dev_priv, FDI_RX_MISC(PIPE_A),
+FDI_RX_PWRDN_LANE1_MASK | FDI_RX_PWRDN_LANE0_MASK, 
0);
intel_de_posting_read(dev_priv, FDI_RX_MISC(PIPE_A));
 
/* Wait for FDI auto training time */
@@ -865,25 +842,21 @@ void hsw_fdi_link_train(struct intel_encoder *encoder,
intel_de_write(dev_priv, FDI_RX_CTL(PIPE_A), rx_ctl_val);
intel_de_posting_read(dev_priv, FDI_RX_CTL(PIPE_A));
 
-   temp = intel_d

[Intel-gfx] [PATCH v15 7/7] drm/i915: Remove truncation warning for large objects

2022-12-15 Thread Gwan-gyeong Mun
From: Chris Wilson 

Having addressed the issues surrounding incorrect types for local
variables and potential integer truncation in using the scatterlist API,
we have closed all the loop holes we had previously identified with
dangerously large object creation. As such, we can eliminate the warning
put in place to remind us to complete the review.

Cc: Tvrtko Ursulin 
Cc: Brian Welty 
Cc: Matthew Auld 
Cc: Thomas Hellström 
Testcase: igt@gem_create@create-massive
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4991
Signed-off-by: Chris Wilson 
Signed-off-by: Gwan-gyeong Mun 
Reviewed-by: Nirmoy Das 
Reviewed-by: Mauro Carvalho Chehab 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.h | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index d7efcfc600e5..ed5d5d8da417 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -20,25 +20,10 @@
 
 enum intel_region_id;
 
-/*
- * XXX: There is a prevalence of the assumption that we fit the
- * object's page count inside a 32bit _signed_ variable. Let's document
- * this and catch if we ever need to fix it. In the meantime, if you do
- * spot such a local variable, please consider fixing!
- *
- * We can check for invalidly typed locals with typecheck(), see for example
- * i915_gem_object_get_sg().
- */
-#define GEM_CHECK_SIZE_OVERFLOW(sz) \
-   GEM_WARN_ON((sz) >> PAGE_SHIFT > INT_MAX)
-
 static inline bool i915_gem_object_size_2big(u64 size)
 {
struct drm_i915_gem_object *obj;
 
-   if (GEM_CHECK_SIZE_OVERFLOW(size))
-   return true;
-
if (overflows_type(size, obj->base.size))
return true;
 
-- 
2.37.1



[Intel-gfx] [PATCH v15 6/7] drm/i915: Use error code as -E2BIG when the size of gem ttm object is too large

2022-12-15 Thread Gwan-gyeong Mun
The ttm_bo_init_reserved() functions returns -ENOSPC if the size is too big
to add vma. The direct function that returns -ENOSPC is 
drm_mm_insert_node_in_range().
To handle the same error as other code returning -E2BIG when the size is
too large, it converts return value to -E2BIG.

Cc: Chris Wilson 
Cc: Matthew Auld 
Cc: Thomas Hellström 
Signed-off-by: Gwan-gyeong Mun 
Reviewed-by: Nirmoy Das 
Reviewed-by: Mauro Carvalho Chehab 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index ae10c7bdd509..8cfed1bef629 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1312,6 +1312,17 @@ int __i915_gem_ttm_object_init(struct 
intel_memory_region *mem,
ret = ttm_bo_init_reserved(&i915->bdev, i915_gem_to_ttm(obj), bo_type,
   &i915_sys_placement, page_size >> PAGE_SHIFT,
   &ctx, NULL, NULL, i915_ttm_bo_destroy);
+
+   /*
+* XXX: The ttm_bo_init_reserved() functions returns -ENOSPC if the size
+* is too big to add vma. The direct function that returns -ENOSPC is
+* drm_mm_insert_node_in_range(). To handle the same error as other code
+* that returns -E2BIG when the size is too large, it converts -ENOSPC 
to
+* -E2BIG.
+*/
+   if (size >> PAGE_SHIFT > INT_MAX && ret == -ENOSPC)
+   ret = -E2BIG;
+
if (ret)
return i915_ttm_err_to_gem(ret);
 
-- 
2.37.1



[Intel-gfx] [PATCH v15 4/7] drm/i915: Check for integer truncation on the configuration of ttm place

2022-12-15 Thread Gwan-gyeong Mun
There is an impedance mismatch between the first/last valid page
frame number of ttm place in unsigned and our memory/page accounting in
unsigned long.
As the object size is under the control of userspace, we have to be prudent
and catch the conversion errors.
To catch the implicit truncation as we switch from unsigned long to
unsigned, we use overflows_type check and report E2BIG or overflow_type
prior to the operation.

v3: Not to change execution inside a macro. (Mauro)
Add safe_conversion_gem_bug_on() macro and remove temporal
SAFE_CONVERSION() macro.
v4: Fix unhandled GEM_BUG_ON() macro call from safe_conversion_gem_bug_on()
v6: Fix to follow general use case for GEM_BUG_ON(). (Jani)
v7: Fix to use WARN_ON() macro where GEM_BUG_ON() macro was used. (Jani)
v8: Replace safe_conversion() with check_assign() (Kees)
v14: Split one macro of assignment with checking of overflow to two steps,
 first overflow check, and second assignment.

Cc: Chris Wilson 
Cc: Matthew Auld 
Cc: Thomas Hellström 
Cc: Jani Nikula 
Signed-off-by: Gwan-gyeong Mun 
Reviewed-by: Nirmoy Das  (v2)
Reviewed-by: Mauro Carvalho Chehab  (v3)
Reported-by: kernel test robot 
Reviewed-by: Andrzej Hajda  (v5)
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c |  3 +++
 drivers/gpu/drm/i915/intel_region_ttm.c | 14 ++
 2 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 244fca7c39f9..ae10c7bdd509 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -140,13 +140,16 @@ i915_ttm_place_from_region(const struct 
intel_memory_region *mr,
if (flags & I915_BO_ALLOC_CONTIGUOUS)
place->flags |= TTM_PL_FLAG_CONTIGUOUS;
if (offset != I915_BO_INVALID_OFFSET) {
+   WARN_ON(overflows_type(offset >> PAGE_SHIFT, place->fpfn));
place->fpfn = offset >> PAGE_SHIFT;
+   WARN_ON(overflows_type(place->fpfn + (size >> PAGE_SHIFT), 
place->lpfn));
place->lpfn = place->fpfn + (size >> PAGE_SHIFT);
} else if (mr->io_size && mr->io_size < mr->total) {
if (flags & I915_BO_ALLOC_GPU_ONLY) {
place->flags |= TTM_PL_FLAG_TOPDOWN;
} else {
place->fpfn = 0;
+   WARN_ON(overflows_type(mr->io_size >> PAGE_SHIFT, 
place->lpfn));
place->lpfn = mr->io_size >> PAGE_SHIFT;
}
}
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c 
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 4dc0702081b8..b7fbd5abb42a 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -208,13 +208,25 @@ intel_region_ttm_resource_alloc(struct 
intel_memory_region *mem,
if (flags & I915_BO_ALLOC_CONTIGUOUS)
place.flags |= TTM_PL_FLAG_CONTIGUOUS;
if (offset != I915_BO_INVALID_OFFSET) {
+   if (WARN_ON(overflows_type(offset >> PAGE_SHIFT, place.fpfn))) {
+   ret = -E2BIG;
+   goto out;
+   }
place.fpfn = offset >> PAGE_SHIFT;
+   if (WARN_ON(overflows_type(place.fpfn + (size >> PAGE_SHIFT), 
place.lpfn))) {
+   ret = -E2BIG;
+   goto out;
+   }
place.lpfn = place.fpfn + (size >> PAGE_SHIFT);
} else if (mem->io_size && mem->io_size < mem->total) {
if (flags & I915_BO_ALLOC_GPU_ONLY) {
place.flags |= TTM_PL_FLAG_TOPDOWN;
} else {
place.fpfn = 0;
+   if (WARN_ON(overflows_type(mem->io_size >> PAGE_SHIFT, 
place.lpfn))) {
+   ret = -E2BIG;
+   goto out;
+   }
place.lpfn = mem->io_size >> PAGE_SHIFT;
}
}
@@ -223,6 +235,8 @@ intel_region_ttm_resource_alloc(struct intel_memory_region 
*mem,
mock_bo.bdev = &mem->i915->bdev;
 
ret = man->func->alloc(man, &mock_bo, &place, &res);
+
+out:
if (ret == -ENOSPC)
ret = -ENXIO;
if (!ret)
-- 
2.37.1



[Intel-gfx] [PATCH v15 5/7] drm/i915: Check if the size is too big while creating shmem file

2022-12-15 Thread Gwan-gyeong Mun
The __shmem_file_setup() function returns -EINVAL if size is greater than
MAX_LFS_FILESIZE. To handle the same error as other code that returns
-E2BIG when the size is too large, it add a code that returns -E2BIG when
the size is larger than the size that can be handled.

v4: If BITS_PER_LONG is 32, size > MAX_LFS_FILESIZE is always false, so it
checks only when BITS_PER_LONG is 64.

Cc: Chris Wilson 
Cc: Matthew Auld 
Cc: Thomas Hellström 
Signed-off-by: Gwan-gyeong Mun 
Reviewed-by: Nirmoy Das 
Reviewed-by: Mauro Carvalho Chehab 
Reported-by: kernel test robot 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 28e857f8c169..e767791e40e0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -541,6 +541,20 @@ static int __create_shmem(struct drm_i915_private *i915,
 
drm_gem_private_object_init(&i915->drm, obj, size);
 
+   /* XXX: The __shmem_file_setup() function returns -EINVAL if size is
+* greater than MAX_LFS_FILESIZE.
+* To handle the same error as other code that returns -E2BIG when
+* the size is too large, we add a code that returns -E2BIG when the
+* size is larger than the size that can be handled.
+* If BITS_PER_LONG is 32, size > MAX_LFS_FILESIZE is always false,
+* so we only needs to check when BITS_PER_LONG is 64.
+* If BITS_PER_LONG is 32, E2BIG checks are processed when
+* i915_gem_object_size_2big() is called before init_object() callback
+* is called.
+*/
+   if (BITS_PER_LONG == 64 && size > MAX_LFS_FILESIZE)
+   return -E2BIG;
+
if (i915->mm.gemfs)
filp = shmem_file_setup_with_mnt(i915->mm.gemfs, "i915", size,
 flags);
-- 
2.37.1



[Intel-gfx] [PATCH v15 3/7] drm/i915: Check for integer truncation on scatterlist creation

2022-12-15 Thread Gwan-gyeong Mun
From: Chris Wilson 

There is an impedance mismatch between the scatterlist API using unsigned
int and our memory/page accounting in unsigned long. That is we may try
to create a scatterlist for a large object that overflows returning a
small table into which we try to fit very many pages. As the object size
is under the control of userspace, we have to be prudent and catch the
conversion errors.

To catch the implicit truncation we check before calling scattterlist
creation Apis. we use overflows_type check and report E2BIG if the
overflows may raise. When caller does not return errno, use WARN_ON to
report a problem.

This is already used in our create ioctls to indicate if the uABI request
is simply too large for the backing store. Failing that type check,
we have a second check at sg_alloc_table time to make sure the values
we are passing into the scatterlist API are not truncated.

v2: Move added i915_utils's macro into drm_util header (Jani N)
v5: Fix macros to be enclosed in parentheses for complex values
Fix too long line warning
v8: Replace safe_conversion() with check_assign() (Kees)
v14: Remove shadowing macros of scatterlist creation api and fix to
 explicitly overflow check where the scatterlist creation APIs are
 called. (Jani)
v15: Add missing returning of error code when the WARN_ON() has been
 detected. (Jani)

Cc: Tvrtko Ursulin 
Cc: Brian Welty 
Cc: Matthew Auld 
Cc: Thomas Hellström 
Co-developed-by: Gwan-gyeong Mun 
Signed-off-by: Chris Wilson 
Signed-off-by: Gwan-gyeong Mun 
Reviewed-by: Nirmoy Das 
Reviewed-by: Mauro Carvalho Chehab 
Reviewed-by: Andrzej Hajda 
Acked-by: Jani Nikula 
---
 drivers/gpu/drm/i915/gem/i915_gem_internal.c |  7 +--
 drivers/gpu/drm/i915/gem/i915_gem_object.h   |  3 ---
 drivers/gpu/drm/i915/gem/i915_gem_phys.c |  4 
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c|  9 ++---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c  |  4 
 drivers/gpu/drm/i915/gem/i915_gem_userptr.c  |  6 +-
 drivers/gpu/drm/i915/gem/selftests/huge_gem_object.c |  6 +-
 drivers/gpu/drm/i915/gem/selftests/huge_pages.c  |  8 
 drivers/gpu/drm/i915/gvt/dmabuf.c| 10 ++
 drivers/gpu/drm/i915/i915_scatterlist.c  |  9 +
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c|  4 
 drivers/gpu/drm/i915/selftests/scatterlist.c |  4 
 12 files changed, 60 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c 
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index f66bcefc09ec..6bc26b4b06b8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -35,11 +35,15 @@ static int i915_gem_object_get_pages_internal(struct 
drm_i915_gem_object *obj)
struct drm_i915_private *i915 = to_i915(obj->base.dev);
struct sg_table *st;
struct scatterlist *sg;
-   unsigned int npages;
+   unsigned int npages; /* restricted by sg_alloc_table */
int max_order = MAX_ORDER;
unsigned int max_segment;
gfp_t gfp;
 
+   if (overflows_type(obj->base.size >> PAGE_SHIFT, npages))
+   return -E2BIG;
+
+   npages = obj->base.size >> PAGE_SHIFT;
max_segment = i915_sg_segment_size(i915->drm.dev) >> PAGE_SHIFT;
max_order = min(max_order, get_order(max_segment));
 
@@ -55,7 +59,6 @@ static int i915_gem_object_get_pages_internal(struct 
drm_i915_gem_object *obj)
if (!st)
return -ENOMEM;
 
-   npages = obj->base.size / PAGE_SIZE;
if (sg_alloc_table(st, npages, GFP_KERNEL)) {
kfree(st);
return -ENOMEM;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 5a37545cc84c..d7efcfc600e5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -26,9 +26,6 @@ enum intel_region_id;
  * this and catch if we ever need to fix it. In the meantime, if you do
  * spot such a local variable, please consider fixing!
  *
- * Aside from our own locals (for which we have no excuse!):
- * - sg_table embeds unsigned int for nents
- *
  * We can check for invalidly typed locals with typecheck(), see for example
  * i915_gem_object_get_sg().
  */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_phys.c 
b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
index 68453572275b..76efe98eaa14 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
@@ -28,6 +28,10 @@ static int i915_gem_object_get_pages_phys(struct 
drm_i915_gem_object *obj)
void *dst;
int i;
 
+   /* Contiguous chunk, with a single scatterlist element */
+   if (overflows_type(obj->base.size, sg->length))
+   return -E2BIG;
+
if (GEM_WARN_ON(i915_gem_object_needs_bit17_swizzle(obj)))
return -EINVAL;

[Intel-gfx] [PATCH v15 2/7] drm/i915/gem: Typecheck page lookups

2022-12-15 Thread Gwan-gyeong Mun
From: Chris Wilson 

We need to check that we avoid integer overflows when looking up a page,
and so fix all the instances where we have mistakenly used a plain
integer instead of a more suitable long. Be pedantic and add integer
typechecking to the lookup so that we can be sure that we are safe.
And it also uses pgoff_t as our page lookups must remain compatible with
the page cache, pgoff_t is currently exactly unsigned long.

v2: Move added i915_utils's macro into drm_util header (Jani N)
v3: Make not use the same macro name on a function. (Mauro)
For kernel-doc, macros and functions are handled in the same namespace,
the same macro name on a function prevents ever adding documentation
for it.
v4: Add kernel-doc markups to the kAPI functions and macros (Mauoro)
v5: Fix an alignment to match open parenthesis
v6: Rebase
v10: Use assert_typable instead of exactly_pgoff_t() macro. (Kees)
v11: Change the use of assert_typable to assert_same_typable (G.G)
v12: Change to use static_assert(__castable_to_type(n ,T)) style since
 the assert_same_typable() macro has been dropped. (G.G)
v13: Change the use of __castable_to_type() to castable_to_type()
 Remove an unnecessary header include line. (G.G)

Cc: Tvrtko Ursulin 
Cc: Matthew Auld 
Cc: Thomas Hellström 
Cc: Kees Cook 
Co-developed-by: Gwan-gyeong Mun 
Signed-off-by: Chris Wilson 
Signed-off-by: Gwan-gyeong Mun 
Reviewed-by: Nirmoy Das  (v2)
Reviewed-by: Mauro Carvalho Chehab  (v3)
Reviewed-by: Andrzej Hajda  (v5)
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c|   7 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.h| 293 --
 drivers/gpu/drm/i915/gem/i915_gem_pages.c |  27 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |   2 +-
 .../drm/i915/gem/selftests/i915_gem_context.c |  12 +-
 .../drm/i915/gem/selftests/i915_gem_mman.c|   8 +-
 .../drm/i915/gem/selftests/i915_gem_object.c  |   8 +-
 drivers/gpu/drm/i915/i915_gem.c   |  18 +-
 drivers/gpu/drm/i915/i915_vma.c   |   8 +-
 9 files changed, 322 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 1a0886b8aaa1..e6d4efde4fc5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -427,10 +427,11 @@ void __i915_gem_object_invalidate_frontbuffer(struct 
drm_i915_gem_object *obj,
 static void
 i915_gem_object_read_from_page_kmap(struct drm_i915_gem_object *obj, u64 
offset, void *dst, int size)
 {
+   pgoff_t idx = offset >> PAGE_SHIFT;
void *src_map;
void *src_ptr;
 
-   src_map = kmap_atomic(i915_gem_object_get_page(obj, offset >> 
PAGE_SHIFT));
+   src_map = kmap_atomic(i915_gem_object_get_page(obj, idx));
 
src_ptr = src_map + offset_in_page(offset);
if (!(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_READ))
@@ -443,9 +444,10 @@ i915_gem_object_read_from_page_kmap(struct 
drm_i915_gem_object *obj, u64 offset,
 static void
 i915_gem_object_read_from_page_iomap(struct drm_i915_gem_object *obj, u64 
offset, void *dst, int size)
 {
+   pgoff_t idx = offset >> PAGE_SHIFT;
+   dma_addr_t dma = i915_gem_object_get_dma_address(obj, idx);
void __iomem *src_map;
void __iomem *src_ptr;
-   dma_addr_t dma = i915_gem_object_get_dma_address(obj, offset >> 
PAGE_SHIFT);
 
src_map = io_mapping_map_wc(&obj->mm.region->iomap,
dma - obj->mm.region->region.start,
@@ -484,6 +486,7 @@ static bool object_has_mappable_iomem(struct 
drm_i915_gem_object *obj)
  */
 int i915_gem_object_read_from_page(struct drm_i915_gem_object *obj, u64 
offset, void *dst, int size)
 {
+   GEM_BUG_ON(overflows_type(offset >> PAGE_SHIFT, pgoff_t));
GEM_BUG_ON(offset >= obj->base.size);
GEM_BUG_ON(offset_in_page(offset) > PAGE_SIZE - size);
GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 3db53769864c..5a37545cc84c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -27,8 +27,10 @@ enum intel_region_id;
  * spot such a local variable, please consider fixing!
  *
  * Aside from our own locals (for which we have no excuse!):
- * - sg_table embeds unsigned int for num_pages
- * - get_user_pages*() mixed ints with longs
+ * - sg_table embeds unsigned int for nents
+ *
+ * We can check for invalidly typed locals with typecheck(), see for example
+ * i915_gem_object_get_sg().
  */
 #define GEM_CHECK_SIZE_OVERFLOW(sz) \
GEM_WARN_ON((sz) >> PAGE_SHIFT > INT_MAX)
@@ -363,44 +365,289 @@ i915_gem_object_get_tile_row_size(const struct 
drm_i915_gem_object *obj)
 int i915_gem_object_set_tiling(struct drm_i915_gem_object *obj,
   unsigned int tiling, unsigned int stride);
 
+/**
+ * __i915_gem_object_page_iter_get_s

[Intel-gfx] [PATCH v15 1/7] overflow: Introduce overflows_type() and castable_to_type()

2022-12-15 Thread Gwan-gyeong Mun
From: Kees Cook 

Implement a robust overflows_type() macro to test if a variable or
constant value would overflow another variable or type. This can be
used as a constant expression for static_assert() (which requires a
constant expression[1][2]) when used on constant values. This must be
constructed manually, since __builtin_add_overflow() does not produce
a constant expression[3].

Additionally adds castable_to_type(), similar to __same_type(), but for
checking if a constant value would overflow if cast to a given type.

Add unit tests for overflows_type(), __same_type(), and castable_to_type()
to the existing KUnit "overflow" test:

[16:03:33] == overflow (21 subtests) ==
...
[16:03:33] [PASSED] overflows_type_test
[16:03:33] [PASSED] same_type_test
[16:03:33] [PASSED] castable_to_type_test
[16:03:33]  [PASSED] overflow =
[16:03:33] 
[16:03:33] Testing complete. Ran 21 tests: passed: 21
[16:03:33] Elapsed time: 24.022s total, 0.002s configuring, 22.598s building, 
0.767s running

[1] https://en.cppreference.com/w/c/language/_Static_assert
[2] C11 standard (ISO/IEC 9899:2011): 6.7.10 Static assertions
[3] https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
6.56 Built-in Functions to Perform Arithmetic with Overflow Checking
Built-in Function: bool __builtin_add_overflow (type1 a, type2 b,

Cc: Luc Van Oostenryck 
Cc: Nathan Chancellor 
Cc: Nick Desaulniers 
Cc: Tom Rix 
Cc: Daniel Latypov 
Cc: Vitor Massaru Iha 
Cc: "Gustavo A. R. Silva" 
Cc: Jani Nikula 
Cc: Mauro Carvalho Chehab 
Cc: linux-harden...@vger.kernel.org
Cc: l...@lists.linux.dev
Co-developed-by: Gwan-gyeong Mun 
Signed-off-by: Gwan-gyeong Mun 
Signed-off-by: Kees Cook 
Link: 
https://lore.kernel.org/r/20221024201125.1416422-1-gwan-gyeong@intel.com
---
 drivers/gpu/drm/i915/i915_user_extensions.c |   2 +-
 drivers/gpu/drm/i915/i915_utils.h   |   4 -
 include/linux/compiler.h|   1 +
 include/linux/overflow.h|  48 +++
 lib/Makefile|   1 +
 lib/overflow_kunit.c| 381 
 6 files changed, 432 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_user_extensions.c 
b/drivers/gpu/drm/i915/i915_user_extensions.c
index c822d0aafd2d..e3f808372c47 100644
--- a/drivers/gpu/drm/i915/i915_user_extensions.c
+++ b/drivers/gpu/drm/i915/i915_user_extensions.c
@@ -51,7 +51,7 @@ int i915_user_extensions(struct i915_user_extension __user 
*ext,
return err;
 
if (get_user(next, &ext->next_extension) ||
-   overflows_type(next, ext))
+   overflows_type(next, uintptr_t))
return -EFAULT;
 
ext = u64_to_user_ptr(next);
diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
index b64192d9c7da..2c430c0c3bad 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -111,10 +111,6 @@ bool i915_error_injected(void);
 #define range_overflows_end_t(type, start, size, max) \
range_overflows_end((type)(start), (type)(size), (type)(max))
 
-/* Note we don't consider signbits :| */
-#define overflows_type(x, T) \
-   (sizeof(x) > sizeof(T) && (x) >> BITS_PER_TYPE(T))
-
 #define ptr_mask_bits(ptr, n) ({   \
unsigned long __v = (unsigned long)(ptr);   \
(typeof(ptr))(__v & -BIT(n));   \
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 973a1bfd7ef5..947a60b801db 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -236,6 +236,7 @@ static inline void *offset_to_ptr(const int *off)
  * bool and also pointer types.
  */
 #define is_signed_type(type) (((type)(-1)) < (__force type)1)
+#define is_unsigned_type(type) (!is_signed_type(type))
 
 /*
  * This is needed in functions which generate the stack canary, see
diff --git a/include/linux/overflow.h b/include/linux/overflow.h
index 1d3be1a2204c..16ae8d912390 100644
--- a/include/linux/overflow.h
+++ b/include/linux/overflow.h
@@ -128,6 +128,54 @@ static inline bool __must_check __must_check_overflow(bool 
overflow)
(*_d >> _to_shift) != _a);  \
 }))
 
+#define __overflows_type_constexpr(x, T) ( \
+   is_unsigned_type(typeof(x)) ?   \
+   (x) > type_max(typeof(T)) ? 1 : 0   \
+   : is_unsigned_type(typeof(T)) ? \
+   (x) < 0 || (x) > type_max(typeof(T)) ? 1 : 0\
+   : (x) < type_min(typeof(T)) ||  \
+ (x) > type_max(typeof(T)) ? 1 : 0)
+
+#define __overflows_type(x, T) ({  \
+   typeof(T) v = 0;

[Intel-gfx] [PATCH v15 0/7] Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation

2022-12-15 Thread Gwan-gyeong Mun
This patch series fixes integer overflow or integer truncation issues in
page lookups, ttm place configuration and scatterlist creation, etc.
We need to check that we avoid integer overflows when looking up a page,
and so fix all the instances where we have mistakenly used a plain integer
instead of a more suitable long.
And there is an impedance mismatch between the scatterlist API using
unsigned int and our memory/page accounting in unsigned long. That is we
may try to create a scatterlist for a large object that overflows returning
a small table into which we try to fit very many pages. As the object size
is under the control of userspace, we have to be prudent and catch the
conversion errors. To catch the implicit truncation as we switch from
unsigned long into the scatterlist's unsigned int, we use improved
overflows_type check and report E2BIG prior to the operation. This is
already used in our create ioctls to indicate if the uABI request is simply
too large for the backing store. 
And ttm place also has the same problem with scatterlist creation,
and we fix the integer truncation problem with the way approached by
scatterlist creation.
And It corrects the error code to return -E2BIG when creating gem objects
using ttm or shmem, if the size is too large in each case.

This series includes a patch [1] merged into the linux-next tree. (it added
for testing of Intel-gfx CI)
This version fixes and updates the comments left in the v14 patch [2]. 

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=4b21d25bf519c9487935a664886956bb18f04f6d
[2] https://patchwork.freedesktop.org/patch/509528/?series=110413&rev=2

Chris Wilson (3):
  drm/i915/gem: Typecheck page lookups
  drm/i915: Check for integer truncation on scatterlist creation
  drm/i915: Remove truncation warning for large objects

Gwan-gyeong Mun (3):
  drm/i915: Check for integer truncation on the configuration of ttm
place
  drm/i915: Check if the size is too big while creating shmem file
  drm/i915: Use error code as -E2BIG when the size of gem ttm object is
too large

Kees Cook (1):
  overflow: Introduce overflows_type() and castable_to_type()

 drivers/gpu/drm/i915/gem/i915_gem_internal.c  |   7 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.c|   7 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.h| 303 --
 drivers/gpu/drm/i915/gem/i915_gem_pages.c |  27 +-
 drivers/gpu/drm/i915/gem/i915_gem_phys.c  |   4 +
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c |  23 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |  20 +-
 drivers/gpu/drm/i915/gem/i915_gem_userptr.c   |   6 +-
 .../drm/i915/gem/selftests/huge_gem_object.c  |   6 +-
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |   8 +
 .../drm/i915/gem/selftests/i915_gem_context.c |  12 +-
 .../drm/i915/gem/selftests/i915_gem_mman.c|   8 +-
 .../drm/i915/gem/selftests/i915_gem_object.c  |   8 +-
 drivers/gpu/drm/i915/gvt/dmabuf.c |  10 +-
 drivers/gpu/drm/i915/i915_gem.c   |  18 +-
 drivers/gpu/drm/i915/i915_scatterlist.c   |   9 +
 drivers/gpu/drm/i915/i915_user_extensions.c   |   2 +-
 drivers/gpu/drm/i915/i915_utils.h |   4 -
 drivers/gpu/drm/i915/i915_vma.c   |   8 +-
 drivers/gpu/drm/i915/intel_region_ttm.c   |  14 +
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |   4 +
 drivers/gpu/drm/i915/selftests/scatterlist.c  |   4 +
 include/linux/compiler.h  |   1 +
 include/linux/overflow.h  |  48 +++
 lib/Makefile  |   1 +
 lib/overflow_kunit.c  | 381 ++
 26 files changed, 852 insertions(+), 91 deletions(-)

-- 
2.37.1



[Intel-gfx] ✗ Fi.CI.IGT: failure for Enable HDCP2.x via GSC CS (rev3)

2022-12-15 Thread Patchwork
== Series Details ==

Series: Enable HDCP2.x via GSC CS (rev3)
URL   : https://patchwork.freedesktop.org/series/111876/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12502_full -> Patchwork_111876v3_full


Summary
---

  **FAILURE**

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

  

Participating hosts (14 -> 14)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_fence@syncobj-timeline-multiple-ext-nodes:
- shard-skl:  [PASS][1] -> [WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-skl4/igt@gem_exec_fe...@syncobj-timeline-multiple-ext-nodes.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v3/shard-skl6/igt@gem_exec_fe...@syncobj-timeline-multiple-ext-nodes.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@drm_mm@all:
- shard-tglb: NOTRUN -> [SKIP][3] ([i915#6433])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v3/shard-tglb5/igt@drm...@all.html

  * igt@gem_ctx_exec@basic-nohangcheck:
- shard-tglb: [PASS][4] -> [FAIL][5] ([i915#6268])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-tglb7/igt@gem_ctx_e...@basic-nohangcheck.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v3/shard-tglb2/igt@gem_ctx_e...@basic-nohangcheck.html

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-snb:  [PASS][6] -> [SKIP][7] ([fdo#109271])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-snb7/igt@gem_ctx_isolation@preservation...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v3/shard-snb5/igt@gem_ctx_isolation@preservation...@rcs0.html
- shard-skl:  [PASS][8] -> [INCOMPLETE][9] ([i915#4793])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-skl4/igt@gem_ctx_isolation@preservation...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v3/shard-skl6/igt@gem_ctx_isolation@preservation...@rcs0.html

  * igt@gem_exec_balancer@parallel-bb-first:
- shard-skl:  NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4525])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v3/shard-skl1/igt@gem_exec_balan...@parallel-bb-first.html

  * igt@gem_exec_balancer@parallel-out-fence:
- shard-iclb: [PASS][11] -> [SKIP][12] ([i915#4525])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-iclb2/igt@gem_exec_balan...@parallel-out-fence.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v3/shard-iclb8/igt@gem_exec_balan...@parallel-out-fence.html

  * igt@gem_exec_endless@dispatch@vcs0:
- shard-tglb: [PASS][13] -> [TIMEOUT][14] ([i915#3778])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-tglb5/igt@gem_exec_endless@dispa...@vcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v3/shard-tglb5/igt@gem_exec_endless@dispa...@vcs0.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-tglb: [PASS][15] -> [FAIL][16] ([i915#2842]) +1 similar 
issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-tglb6/igt@gem_exec_fair@basic-none-...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v3/shard-tglb7/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_pxp@display-protected-crc:
- shard-tglb: NOTRUN -> [SKIP][17] ([i915#4270])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v3/shard-tglb5/igt@gem_...@display-protected-crc.html

  * igt@gen7_exec_parse@basic-allocation:
- shard-tglb: NOTRUN -> [SKIP][18] ([fdo#109289])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v3/shard-tglb5/igt@gen7_exec_pa...@basic-allocation.html

  * igt@gen9_exec_parse@allowed-single:
- shard-apl:  [PASS][19] -> [DMESG-WARN][20] ([i915#5566] / 
[i915#716])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl3/igt@gen9_exec_pa...@allowed-single.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v3/shard-apl8/igt@gen9_exec_pa...@allowed-single.html

  * igt@gen9_exec_parse@cmd-crossing-page:
- shard-tglb: NOTRUN -> [SKIP][21] ([i915#2527] / [i915#2856])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip

Re: [Intel-gfx] [PATCH v3] drm/i915/gvt: fix double free bug in split_2MB_gtt_entry

2022-12-15 Thread Wang, Zhi A
On 12/15/2022 12:47 PM, Joonas Lahtinen wrote:
> (+ Tvrtko as FYI)
>
> Zhenyu, can you take a look at the patch ASAP.
>
> Regards, Joonas

Thanks so much for the reminding and patch.


Actually I don't think it is proper fix as:

split_2MB_gtt_entry() is going to allocate a new spt structure, which is 
a PTE page to hold

the mapping of the 2MB. It will map the sub 4k pages for DMA addrs, form 
them as PTE

entries, write the entries into the new PTE page,  and then link the 
page to the parent

table entry so that the GPU can reach it.


Now something wrong happens when mapping the sub 4K pages. What we need 
are 1) The

existing mappings of DMA addr need to be un-done and 2) the newly 
allocated spt structure

needs to be freed.  These can be handle by ppgtt_invalidate_spt() which 
will handle the 1)

and 2) based on the type of shadow page table, either recursively or 
not. i.e. in this case,

it's a PTE page.


I guess the code wrongly does 1) 2) on the parent page table when 
something error happens in

DMA mapping . You can fix it by releasing the newly allocated spt in the 
error case and put a

Fixes: b901b252b6cf ("drm/i915/gvt: Add 2M huge gtt support") in the 
patch comment.


BTW: For sending the patches, you can take a look on "git send-email". 
It will promise the correct

format and prevent quite some bumps. For email clients, if you feel mutt 
is hard to ramp up,

you can try the Claws Mail. More information can be found in 
Documentation/process/email-clients.rst


Thanks,

Zhi.

>
> Quoting Dave Airlie (2022-10-27 08:12:31)
>> On Thu, 27 Oct 2022 at 13:26, Zheng Hacker  wrote:
>>> Dave Airlie  于2022年10月27日周四 08:01写道:
 On Fri, 7 Oct 2022 at 11:38, Zheng Wang  wrote:
> If intel_gvt_dma_map_guest_page failed, it will call
> ppgtt_invalidate_spt, which will finally free the spt.
> But the caller does not notice that, it will free spt again in error path.
>
> Fix this by spliting invalidate and free in ppgtt_invalidate_spt.
> Only free spt when in good case.
>
> Reported-by: Zheng Wang 
> Signed-off-by: Zheng Wang 
 Has this landed in a tree yet, since it's a possible CVE, might be
 good to merge it somewhere.

 Dave.

>>> Hi Dave,
>>>
>>> This patched hasn't been merged yet. Could you please help with this?
>> I'll add some more people who can probably look at it.
>>
>> Dave.




Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/selftests: Remove hardcoded value with a macro

2022-12-15 Thread Das, Nirmoy


On 12/13/2022 1:38 PM, Patchwork wrote:

Project List - Patchwork *Patch Details*
*Series:*   drm/i915/selftests: Remove hardcoded value with a macro
*URL:*  https://patchwork.freedesktop.org/series/111891/
*State:*failure
*Details:* 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111891v1/index.html



  CI Bug Log - changes from CI_DRM_12501 -> Patchwork_111891v1


Summary

*FAILURE*

Serious unknown changes coming with Patchwork_111891v1 absolutely need 
to be

verified manually.



This is a bit stretch,  the patch didn't change any thing functional. We 
can ignore the failure.



Nirmoy



If you think the reported changes have nothing to do with the changes
introduced in Patchwork_111891v1, 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_111891v1/index.html



Participating hosts (38 -> 19)

ERROR: It appears as if the changes made in Patchwork_111891v1 
prevented too many machines from booting.


Additional (1): fi-skl-guc
Missing (20): fi-kbl-soraka bat-dg1-6 bat-dg1-5 bat-adlp-6 
fi-skl-6600u fi-bsw-n3050 bat-dg2-8 bat-adlm-1 bat-dg2-9 fi-bwr-2160 
bat-adln-1 bat-atsm-1 bat-jsl-3 bat-rplp-1 bat-dg2-11 fi-bsw-nick 
bat-dg1-7 bat-kbl-2 bat-adlp-9 bat-adlp-4



Known issues

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



  IGT changes


Issues hit

 *

igt@gem_lmem_swapping@basic:

  o fi-skl-guc: NOTRUN -> SKIP


(fdo#109271
 /
i915#4613
) +3
similar issues
 *

igt@i915_suspend@basic-s3-without-i915:

  o fi-rkl-11600: PASS


-> INCOMPLETE


(i915#4817 )
 *

igt@kms_chamelium@hdmi-crc-fast:

  o fi-skl-guc: NOTRUN -> SKIP


(fdo#109271
 /
fdo#111827
) +8
similar issues
 *

igt@kms_setmode@basic-clone-single-crtc:

  o fi-skl-guc: NOTRUN -> SKIP


(fdo#109271
) +9
similar issues


Possible fixes

  * igt@gem_exec_gttfill@basic:
  o fi-pnv-d510: FAIL


(i915#7229
) ->
PASS




Build changes

  * Linux: CI_DRM_12501 -> Patchwork_111891v1

CI-20190529: 20190529
CI_DRM_12501: 1b38b5a419ab3d838b6ac95d22f1fe057fc8889d @ 
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7091: b8015f920c9f469d3733854263cb878373c1df51 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_111891v1: 1b38b5a419ab3d838b6ac95d22f1fe057fc8889d @ 
git://anongit.freedesktop.org/gfx-ci/linux



  Linux commits

eaf43d121582 drm/i915/selftests: Remove hardcoded value with a macro


[Intel-gfx] [PATCHv6] drm/i915/dp: change aux_ctl reg read to polling read

2022-12-15 Thread Arun R Murthy
The busy timeout logic checks for the AUX BUSY, then waits for the
timeout period and then after timeout reads the register for BUSY or
Success.
Instead replace interrupt with polling so as to read the AUX CTL
register often before the timeout period. Looks like there might be some
issue with interrupt-on-read. Hence changing the logic to polling read.

v2: replace interrupt with polling read
v3: use usleep_rang instead of msleep, updated commit msg
v4: use intel_wait_for_regiter internal function
v5: use __intel_de_wait_for_register with 500us slow and 10ms fast timeout
v6: check return value of __intel_de_wait_for_register

Signed-off-by: Arun R Murthy 
---
 drivers/gpu/drm/i915/display/intel_dp_aux.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux.c
index 91c93c93e5fc..973dadecf712 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
@@ -41,20 +41,16 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp)
i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
const unsigned int timeout_ms = 10;
u32 status;
-   bool done;
-
-#define C (((status = intel_de_read_notrace(i915, ch_ctl)) & 
DP_AUX_CH_CTL_SEND_BUSY) == 0)
-   done = wait_event_timeout(i915->display.gmbus.wait_queue, C,
- msecs_to_jiffies_timeout(timeout_ms));
+   int ret;
 
-   /* just trace the final value */
-   trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
+   ret = __intel_de_wait_for_register(i915, ch_ctl,
+  DP_AUX_CH_CTL_SEND_BUSY, 0,
+  500, timeout_ms, &status);
 
-   if (!done)
+   if (ret == -ETIMEDOUT)
drm_err(&i915->drm,
"%s: did not complete or timeout within %ums (status 
0x%08x)\n",
intel_dp->aux.name, timeout_ms, status);
-#undef C
 
return status;
 }
-- 
2.25.1



Re: [Intel-gfx] [PATCH 2/7] drm/i915/display: move more scanline functions to intel_vblank.[ch]

2022-12-15 Thread Jani Nikula
On Thu, 15 Dec 2022, "Murthy, Arun R"  wrote:
>> -Original Message-
>> From: Nikula, Jani 
>> Sent: Thursday, December 15, 2022 3:50 PM
>> To: Murthy, Arun R ; intel-
>> g...@lists.freedesktop.org
>> Subject: RE: [Intel-gfx] [PATCH 2/7] drm/i915/display: move more scanline
>> functions to intel_vblank.[ch]
>>
>> On Thu, 15 Dec 2022, "Murthy, Arun R"  wrote:
>> >> >> And how would you propose to drop the wrapper? The wrappers are
>> >> >> all about readability in the caller side:
>> >> >>
>> >> > I didn’t mean to drop the wrapper, understand that wrapper is more
>> >> readable, what I meant is to replace
>> >> wait_for_pipe_scanline_moving/stopped with its function contents.
>> >>
>> >> Why should we duplicate the code?
>> >
>> > static void intel_wait_for_pipe_scanline_moving(struct intel_crtc *crtc) {
> Bool state can be added as a parameter to this function, on the other hand, 
> can have state = false as a magic value as well.

Then it boils down to what we already have?

Too much talk now, please send actual working code instead.

BR,
Jani.


>
> Thanks and Regards,
> Arun R Murthy
> ---
>> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> > enum pipe pipe = crtc->pipe
>> >
>> > /* Wait for the display line to settle/start moving */
>> > if (wait_for(pipe_scanline_is_moving(dev_priv, pipe) == state,
>> > 100))
>> >
>> > drm_err(&dev_priv->drm,
>> >   "pipe %c scanline %s wait timed out\n",
>> >  pipe_name(pipe), str_on_off(state)); }
>>
>> And the state variable comes from where?
>>
>> BR,
>> Jani.
>>
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center

-- 
Jani Nikula, Intel Open Source Graphics Center


Re: [Intel-gfx] [RFC 1/2] drm/connector: add connector list iteration with filtering

2022-12-15 Thread Daniel Vetter
On Wed, Oct 05, 2022 at 01:51:43PM +0300, Jani Nikula wrote:
> Add new function drm_connector_list_iter_filter_begin() to initialize
> connector list iterator with a filter function. Subsequent iteration on
> the list will only return connectors on which the filter function
> returns true.
> 
> Cc: Arun R Murthy 
> Cc: Suraj Kandpal 
> Cc: Ville Syrjälä 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_connector.c | 57 ++---
>  include/drm/drm_connector.h |  9 ++
>  2 files changed, 54 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index e3142c8142b3..d54b4b54cecb 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -762,6 +762,29 @@ static struct lockdep_map connector_list_iter_dep_map = {
>  };
>  #endif
>  
> +/**
> + * drm_connector_list_iter_filter_begin - initialize a connector_list 
> iterator with filter
> + * @dev: DRM device
> + * @iter: connector_list iterator
> + * @filter: connector filter function
> + * @filter_context: context to be passed to the filter function
> + *
> + * Same as drm_connector_list_iter_begin(), but sets up the iterator to only
> + * return connectors where filter(connector) returns true.
> + */
> +void drm_connector_list_iter_filter_begin(struct drm_device *dev,
> +   struct drm_connector_list_iter *iter,
> +   drm_connector_list_iter_filter_fn 
> filter,
> +   void *filter_context)
> +{
> + iter->dev = dev;
> + iter->conn = NULL;
> + iter->filter = filter;
> + iter->filter_context = filter_context;
> + lock_acquire_shared_recursive(&connector_list_iter_dep_map, 0, 1, NULL, 
> _RET_IP_);
> +}
> +EXPORT_SYMBOL(drm_connector_list_iter_filter_begin);

So maybe I'm missing the obvious, but can't we just put a for_each_fi
right after the for_each_connector_iter?

And then maybe provide a default filter to kick out connectors and maybe a
macro that does the filtered iteration? The iter_begin/next/end is already
fairly tricky pattern compared to plain for_each macro, I think we should
try hard to not complicate it further with lots of variants if that's not
absolutely necessary.
-Daniel


> +
>  /**
>   * drm_connector_list_iter_begin - initialize a connector_list iterator
>   * @dev: DRM device
> @@ -775,9 +798,7 @@ static struct lockdep_map connector_list_iter_dep_map = {
>  void drm_connector_list_iter_begin(struct drm_device *dev,
>  struct drm_connector_list_iter *iter)
>  {
> - iter->dev = dev;
> - iter->conn = NULL;
> - lock_acquire_shared_recursive(&connector_list_iter_dep_map, 0, 1, NULL, 
> _RET_IP_);
> + drm_connector_list_iter_filter_begin(dev, iter, NULL, NULL);
>  }
>  EXPORT_SYMBOL(drm_connector_list_iter_begin);
>  
> @@ -800,15 +821,8 @@ __drm_connector_put_safe(struct drm_connector *conn)
>   schedule_work(&config->connector_free_work);
>  }
>  
> -/**
> - * drm_connector_list_iter_next - return next connector
> - * @iter: connector_list iterator
> - *
> - * Returns: the next connector for @iter, or NULL when the list walk has
> - * completed.
> - */
> -struct drm_connector *
> -drm_connector_list_iter_next(struct drm_connector_list_iter *iter)
> +static struct drm_connector *
> +__drm_connector_list_iter_next(struct drm_connector_list_iter *iter)
>  {
>   struct drm_connector *old_conn = iter->conn;
>   struct drm_mode_config *config = &iter->dev->mode_config;
> @@ -836,6 +850,25 @@ drm_connector_list_iter_next(struct 
> drm_connector_list_iter *iter)
>  
>   return iter->conn;
>  }
> +
> +/**
> + * drm_connector_list_iter_next - return next connector
> + * @iter: connector_list iterator
> + *
> + * Returns: the next connector for @iter, or NULL when the list walk has
> + * completed.
> + */
> +struct drm_connector *
> +drm_connector_list_iter_next(struct drm_connector_list_iter *iter)
> +{
> + struct drm_connector *connector;
> +
> + while ((connector = __drm_connector_list_iter_next(iter)) &&
> +iter->filter && !iter->filter(connector, iter->filter_context))
> + ;
> +
> + return connector;
> +}
>  EXPORT_SYMBOL(drm_connector_list_iter_next);
>  
>  /**
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 56aee949c6fa..497b98197d3a 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1868,6 +1868,9 @@ struct drm_tile_group *drm_mode_get_tile_group(struct 
> drm_device *dev,
>  void drm_mode_put_tile_group(struct drm_device *dev,
>struct drm_tile_group *tg);
>  
> +typedef bool (*drm_connector_list_iter_filter_fn)(const struct drm_connector 
> *connector,
> +   void *filter_context);
> +
>  /**
>   * struct drm_connector_list_iter - connector_list iterato

Re: [Intel-gfx] [PATCH v3] drm/i915/gvt: fix double free bug in split_2MB_gtt_entry

2022-12-15 Thread Joonas Lahtinen
(+ Tvrtko as FYI)

Zhenyu, can you take a look at the patch ASAP.

Regards, Joonas

Quoting Dave Airlie (2022-10-27 08:12:31)
> On Thu, 27 Oct 2022 at 13:26, Zheng Hacker  wrote:
> >
> > Dave Airlie  于2022年10月27日周四 08:01写道:
> > >
> > > On Fri, 7 Oct 2022 at 11:38, Zheng Wang  wrote:
> > > >
> > > > If intel_gvt_dma_map_guest_page failed, it will call
> > > > ppgtt_invalidate_spt, which will finally free the spt.
> > > > But the caller does not notice that, it will free spt again in error 
> > > > path.
> > > >
> > > > Fix this by spliting invalidate and free in ppgtt_invalidate_spt.
> > > > Only free spt when in good case.
> > > >
> > > > Reported-by: Zheng Wang 
> > > > Signed-off-by: Zheng Wang 
> > >
> > > Has this landed in a tree yet, since it's a possible CVE, might be
> > > good to merge it somewhere.
> > >
> > > Dave.
> > >
> >
> > Hi Dave,
> >
> > This patched hasn't been merged yet. Could you please help with this?
> 
> I'll add some more people who can probably look at it.
> 
> Dave.


Re: [Intel-gfx] [PATCH 2/7] drm/i915/display: move more scanline functions to intel_vblank.[ch]

2022-12-15 Thread Murthy, Arun R
> -Original Message-
> From: Nikula, Jani 
> Sent: Thursday, December 15, 2022 3:50 PM
> To: Murthy, Arun R ; intel-
> g...@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH 2/7] drm/i915/display: move more scanline
> functions to intel_vblank.[ch]
> 
> On Thu, 15 Dec 2022, "Murthy, Arun R"  wrote:
> >> >> And how would you propose to drop the wrapper? The wrappers are
> >> >> all about readability in the caller side:
> >> >>
> >> > I didn’t mean to drop the wrapper, understand that wrapper is more
> >> readable, what I meant is to replace
> >> wait_for_pipe_scanline_moving/stopped with its function contents.
> >>
> >> Why should we duplicate the code?
> >
> > static void intel_wait_for_pipe_scanline_moving(struct intel_crtc *crtc) {
Bool state can be added as a parameter to this function, on the other hand, can 
have state = false as a magic value as well.

Thanks and Regards,
Arun R Murthy
---
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > enum pipe pipe = crtc->pipe
> >
> > /* Wait for the display line to settle/start moving */
> > if (wait_for(pipe_scanline_is_moving(dev_priv, pipe) == state,
> > 100))
> >
> > drm_err(&dev_priv->drm,
> >   "pipe %c scanline %s wait timed out\n",
> >  pipe_name(pipe), str_on_off(state)); }
> 
> And the state variable comes from where?
> 
> BR,
> Jani.
> 
> 
> --
> Jani Nikula, Intel Open Source Graphics Center


Re: [Intel-gfx] [PATCHv6] drm/i915/dp: change aux_ctl reg read to polling read

2022-12-15 Thread Murthy, Arun R
> -Original Message-
> From: Nikula, Jani 
> Sent: Thursday, December 15, 2022 4:00 PM
> To: Murthy, Arun R ; intel-
> g...@lists.freedesktop.org; ville.syrj...@linux.intel.com; Deak, Imre
> 
> Cc: Murthy, Arun R 
> Subject: Re: [PATCHv6] drm/i915/dp: change aux_ctl reg read to polling read
> 
> On Thu, 15 Dec 2022, Arun R Murthy  wrote:
> > The busy timeout logic checks for the AUX BUSY, then waits for the
> > timeout period and then after timeout reads the register for BUSY or
> > Success.
> > Instead replace interrupt with polling so as to read the AUX CTL
> > register often before the timeout period. Looks like there might be
> > some issue with interrupt-on-read. Hence changing the logic to polling
> read.
> >
> > v2: replace interrupt with polling read
> > v3: use usleep_rang instead of msleep, updated commit msg
> > v4: use intel_wait_for_regiter internal function
> > v5: use __intel_de_wait_for_register with 500us slow and 10ms fast
> > timeout
> > v6: check return value of __intel_de_wait_for_register
> >
> > Signed-off-by: Arun R Murthy 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp_aux.c | 15 +--
> >  1 file changed, 5 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > index 91c93c93e5fc..dec88f41380e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > @@ -40,21 +40,16 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp)
> > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
> > const unsigned int timeout_ms = 10;
> > -   u32 status;
> > -   bool done;
> > -
> > -#define C (((status = intel_de_read_notrace(i915, ch_ctl)) &
> DP_AUX_CH_CTL_SEND_BUSY) == 0)
> > -   done = wait_event_timeout(i915->display.gmbus.wait_queue, C,
> > - msecs_to_jiffies_timeout(timeout_ms));
> > +   u32 status, ret;
> >
> > -   /* just trace the final value */
> > -   trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
> > +   ret = __intel_de_wait_for_register(i915, ch_ctl,
> > +DP_AUX_CH_CTL_SEND_BUSY, 0,
> > +500, timeout_ms, &status);
> >
> > -   if (!done)
> > +   if (ret == -ETIMEDOUT)
> 
> What's wrong with this comparison? Although it probably does work by
> coincidence.
> 
If (ret)
dev_err();
Will also work, but for code readability using -ETIMEDOUT(sorry missed the 
declaration int ret;)

Thanks and Regards,
Arun R Murthy


> BR,
> Jani.
> 
> 
> > drm_err(&i915->drm,
> > "%s: did not complete or timeout within %ums
> (status 0x%08x)\n",
> > intel_dp->aux.name, timeout_ms, status); -#undef C
> >
> > return status;
> >  }
> 
> --
> Jani Nikula, Intel Open Source Graphics Center


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dp: wait on timeout before retry include sw delay (rev6)

2022-12-15 Thread Patchwork
== Series Details ==

Series: drm/i915/dp: wait on timeout before retry include sw delay (rev6)
URL   : https://patchwork.freedesktop.org/series/111303/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12508 -> Patchwork_111303v6


Summary
---

  **FAILURE**

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

Participating hosts (19 -> 19)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_suspend@basic-s2idle-without-i915:
- fi-snb-2600:[PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12508/fi-snb-2600/igt@i915_susp...@basic-s2idle-without-i915.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v6/fi-snb-2600/igt@i915_susp...@basic-s2idle-without-i915.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][3] ([i915#6179])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v6/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_softpin@allocator-basic:
- fi-ivb-3770:NOTRUN -> [SKIP][4] ([fdo#109271]) +18 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v6/fi-ivb-3770/igt@gem_soft...@allocator-basic.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-ivb-3770:NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v6/fi-ivb-3770/igt@kms_chamel...@common-hpd-after-suspend.html

  
 Warnings 

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   [INCOMPLETE][6] ([i915#4817]) -> [FAIL][7] 
([fdo#103375])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12508/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111303v6/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

  
  [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#4817]: https://gitlab.freedesktop.org/drm/intel/issues/4817
  [i915#6179]: https://gitlab.freedesktop.org/drm/intel/issues/6179


Build changes
-

  * Linux: CI_DRM_12508 -> Patchwork_111303v6

  CI-20190529: 20190529
  CI_DRM_12508: 50bbaf39d655c47685f84dd1fb0c2cb4fb7e5286 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7094: 1763071e9d50c5e992257c9197cb26f166de6fae @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_111303v6: 50bbaf39d655c47685f84dd1fb0c2cb4fb7e5286 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

a62c9c7447a9 drm/i915/dp: change aux_ctl reg read to polling read

== Logs ==

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


Re: [Intel-gfx] [PATCHv6] drm/i915/dp: change aux_ctl reg read to polling read

2022-12-15 Thread Jani Nikula
On Thu, 15 Dec 2022, Arun R Murthy  wrote:
> The busy timeout logic checks for the AUX BUSY, then waits for the
> timeout period and then after timeout reads the register for BUSY or
> Success.
> Instead replace interrupt with polling so as to read the AUX CTL
> register often before the timeout period. Looks like there might be some
> issue with interrupt-on-read. Hence changing the logic to polling read.
>
> v2: replace interrupt with polling read
> v3: use usleep_rang instead of msleep, updated commit msg
> v4: use intel_wait_for_regiter internal function
> v5: use __intel_de_wait_for_register with 500us slow and 10ms fast timeout
> v6: check return value of __intel_de_wait_for_register
>
> Signed-off-by: Arun R Murthy 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_aux.c | 15 +--
>  1 file changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c 
> b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> index 91c93c93e5fc..dec88f41380e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> @@ -40,21 +40,16 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp)
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>   i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
>   const unsigned int timeout_ms = 10;
> - u32 status;
> - bool done;
> -
> -#define C (((status = intel_de_read_notrace(i915, ch_ctl)) & 
> DP_AUX_CH_CTL_SEND_BUSY) == 0)
> - done = wait_event_timeout(i915->display.gmbus.wait_queue, C,
> -   msecs_to_jiffies_timeout(timeout_ms));
> + u32 status, ret;
>  
> - /* just trace the final value */
> - trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
> + ret = __intel_de_wait_for_register(i915, ch_ctl,
> +  DP_AUX_CH_CTL_SEND_BUSY, 0,
> +  500, timeout_ms, &status);
>  
> - if (!done)
> + if (ret == -ETIMEDOUT)

What's wrong with this comparison? Although it probably does work by
coincidence.

BR,
Jani.


>   drm_err(&i915->drm,
>   "%s: did not complete or timeout within %ums (status 
> 0x%08x)\n",
>   intel_dp->aux.name, timeout_ms, status);
> -#undef C
>  
>   return status;
>  }

-- 
Jani Nikula, Intel Open Source Graphics Center


Re: [Intel-gfx] [PATCH] drm/i915: fix TLB invalidation for Gen12.50 video and compute engines

2022-12-15 Thread Andi Shyti
On Wed, Dec 14, 2022 at 08:54:39AM +0100, Andrzej Hajda wrote:
> In case of Gen12.50 video and compute engines, TLB_INV registers are
> masked - to modify one bit, corresponding bit in upper half of the register
> must be enabled, otherwise nothing happens.
> 
> Fixes: 77fa9efc16a9 ("drm/i915/xehp: Create separate reg definitions for new 
> MCR registers")
> Signed-off-by: Andrzej Hajda 
> Reviewed-by: Tvrtko Ursulin 

Pushed to drm-intel-gt-next.

Thanks,
Andi

> ---
> Hi,
> 
> This patch was sent already to ML, but together with refactoring patch.
> Since it contains fix and should be merged ASAP it is sent separately
> to get CI test results.
> 
> Regards
> Andrzej
> ---
>  drivers/gpu/drm/i915/gt/intel_gt.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index 63f95c5f36146b..75a7cb33cb 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -1100,9 +1100,15 @@ static void mmio_invalidate_full(struct intel_gt *gt)
>   continue;
>  
>   if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
> + u32 val = BIT(engine->instance);
> +
> + if (engine->class == VIDEO_DECODE_CLASS ||
> + engine->class == VIDEO_ENHANCEMENT_CLASS ||
> + engine->class == COMPUTE_CLASS)
> + val = _MASKED_BIT_ENABLE(val);
>   intel_gt_mcr_multicast_write_fw(gt,
>   
> xehp_regs[engine->class],
> - BIT(engine->instance));
> + val);
>   } else {
>   rb = get_reg_and_bit(engine, regs == gen8_regs, regs, 
> num);
>   if (!i915_mmio_reg_offset(rb.reg))
> -- 
> 2.34.1


Re: [Intel-gfx] [PATCH 2/7] drm/i915/display: move more scanline functions to intel_vblank.[ch]

2022-12-15 Thread Jani Nikula
On Thu, 15 Dec 2022, "Murthy, Arun R"  wrote:
>> >> And how would you propose to drop the wrapper? The wrappers are all
>> >> about readability in the caller side:
>> >>
>> > I didn’t mean to drop the wrapper, understand that wrapper is more
>> readable, what I meant is to replace
>> wait_for_pipe_scanline_moving/stopped with its function contents.
>>
>> Why should we duplicate the code?
>
> static void intel_wait_for_pipe_scanline_moving(struct intel_crtc *crtc) {
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> enum pipe pipe = crtc->pipe
>
> /* Wait for the display line to settle/start moving */
> if (wait_for(pipe_scanline_is_moving(dev_priv, pipe) == state, 100))
>
> drm_err(&dev_priv->drm,
>   "pipe %c scanline %s wait timed out\n",
>  pipe_name(pipe), str_on_off(state));
> }

And the state variable comes from where?

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center


Re: [Intel-gfx] [PATCH 1/1] drm/i915: Implement workaround for CDCLK PLL disable/enable

2022-12-15 Thread Lisovskiy, Stanislav
On Wed, Dec 14, 2022 at 09:15:07PM +0200, Srivatsa, Anusha wrote:
> 
> 
> > -Original Message-
> > From: Lisovskiy, Stanislav 
> > Sent: Wednesday, December 14, 2022 2:31 AM
> > To: Srivatsa, Anusha 
> > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani 
> > Subject: Re: [Intel-gfx] [PATCH 1/1] drm/i915: Implement workaround for
> > CDCLK PLL disable/enable
> > 
> > On Tue, Nov 29, 2022 at 09:19:40PM +0200, Srivatsa, Anusha wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Intel-gfx  On Behalf
> > > > Of Stanislav Lisovskiy
> > > > Sent: Thursday, November 24, 2022 2:36 AM
> > > > To: intel-gfx@lists.freedesktop.org
> > > > Cc: Nikula, Jani 
> > > > Subject: [Intel-gfx] [PATCH 1/1] drm/i915: Implement workaround for
> > > > CDCLK PLL disable/enable
> > > >
> > > > It was reported that we might get a hung and loss of register access
> > > > in some cases when CDCLK PLL is disabled and then enabled, while
> > > > squashing is enabled.
> > > > As a workaround it was proposed by HW team that SW should disable
> > > > squashing when CDCLK PLL is being reenabled.
> > > >
> > > > Signed-off-by: Stanislav Lisovskiy 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_cdclk.c | 14 --
> > > >  1 file changed, 12 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > index 0c107a38f9d0..e338f288c9ac 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > @@ -1801,6 +1801,13 @@ static bool
> > > > cdclk_compute_crawl_and_squash_midpoint(struct drm_i915_private
> > *i91
> > > > return true;
> > > >  }
> > > >
> > > > +static bool pll_enable_wa_needed(struct drm_i915_private *dev_priv)
> > {
> > > > +   return ((IS_DG2(dev_priv) || IS_METEORLAKE(dev_priv))
> > > > +   && dev_priv->display.cdclk.hw.vco > 0
> > > > +   && HAS_CDCLK_SQUASH(dev_priv));
> > > Redundant check. If it is MTL or DG2, then it will have
> > HAS_CDCLK_SQUASH set to true always. Shouldn't vco be 0 instead of > 0.
> > The commit message says the hang can be observed when moving from 0 to
> > > 0 vco.
> > >
> > > Anusha
> > 
> > Idea was that we probably should bind more to the feature rather than
> > platform, I agree checking both "IS_DG2" and if platform has squashing is
> > redundant, because then we would have to add each new platform
> > manually, so I would leave HAS_CDCLK_SQUASH and then at some point
> > just cut off using some INTEL_GEN or other check all the new platforms
> > where this is fixed in HW.
> > 
> > Regarding vco, the icl_cdclk_pll_update func works as follows:
> > 
> > if (i915->display.cdclk.hw.vco != 0 &&
> > i915->display.cdclk.hw.vco != vco)
> > icl_cdclk_pll_disable(i915);
> > 
> > if (i915->display.cdclk.hw.vco != vco)
> > icl_cdclk_pll_enable(i915, vco);
> > 
> > 1) if vco changes from zero value(i915->display.cdclk.hw.vco) to non-zero
> > value(vco), that means
> >currently squashing is anyway disabled(if vco == 0, cdclk is set to 
> > "bypass"
> > and squash waveform
> >is 0), so the W/A is not needed.
> > 
> > 2) if vco changes from non-zero value in i915->display.cdclk.hw.vco to zero
> > value(vco), we are not
> >going to call icl_cdclk_pll_enable anyway so W/A is also not needed.
> > 
> > 3) if vco changes from some non-zero value in i915->display.cdclk.hw.vco to
> > other non-zero value(vco),
> >which can happen if CDCLK changes, then icl_cdclk_pll_disable(hw vco!=0
> > and vco!=0) and then
> >icl_cdclk_pll_enable would be called(hw vco is still not equal to vco)
> >So that disabling enabling in between is what we are interested and
> > where we should make sure
> >squashing is disabled.
> >BTW I have another question - is this code even correct? Shouldn't we
> > avoid disabling/enabling PLL if we have
> >squashing/crawling? As I understood the whole point of having
> > swuashing/crawling is avoiding swithing the PLL
> >on and off.
> > 
> Squashing works when we don't need to change the PLL ratio. We fix the PLL 
> ratio to say 307 (this can change from platform to platform). Then squashing 
> can be used to vary frequencies below this. So we set squasher to  it 
> will mean highest. We can use squasher to change frequency with squash 
> waveform, max being  and any value lower will take lower frequencies. 
> Cdclk Crawling is used when the PLL has to be changed. Eg higher than 307 
> then we need to update PLL. In that case we first program squashing to 
> (this will take to 307) n then use crawling to go up to the desired 
> frequency.

if (HAS_CDCLK_CRAWL(dev_priv) && dev_priv->display.cdclk.hw.vco > 0 && vco > 0 
&&
!cdclk_pll_is_unknown(dev_priv->display.cdclk.hw.vco)) {
if (dev_priv->display.cdclk.hw.vco != vco)
adlp_cdclk_pll_crawl(dev_priv, vco);
} else i

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dp: wait on timeout before retry include sw delay (rev6)

2022-12-15 Thread Patchwork
== Series Details ==

Series: drm/i915/dp: wait on timeout before retry include sw delay (rev6)
URL   : https://patchwork.freedesktop.org/series/111303/
State : warning

== Summary ==

Error: dim checkpatch failed
244c68782e95 drm/i915/dp: change aux_ctl reg read to polling read
-:40: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#40: FILE: drivers/gpu/drm/i915/display/intel_dp_aux.c:46:
+   ret = __intel_de_wait_for_register(i915, ch_ctl,
+DP_AUX_CH_CTL_SEND_BUSY, 0,

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




[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: fix TLB invalidation for Gen12.50 video and compute engines

2022-12-15 Thread Patchwork
== Series Details ==

Series: drm/i915: fix TLB invalidation for Gen12.50 video and compute engines
URL   : https://patchwork.freedesktop.org/series/111920/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12502_full -> Patchwork_111920v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (14 -> 9)
--

  Missing(5): shard-tglu shard-tglu-10 shard-tglu-9 shard-rkl shard-dg1 

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-apl:  ([PASS][1], [PASS][2], [PASS][3], [PASS][4], 
[PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], 
[PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], 
[PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], 
[PASS][24], [PASS][25]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], 
[PASS][30], [PASS][31], [FAIL][32], [PASS][33], [PASS][34], [PASS][35], 
[PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], 
[PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], 
[PASS][48], [PASS][49], [PASS][50]) ([i915#4386])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl2/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl8/boot.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl8/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl6/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl6/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl6/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl6/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl3/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl3/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl3/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl2/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl1/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl1/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl1/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl2/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl2/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl2/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl3/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl1/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl3/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl3/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl1/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl8/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl8/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12502/shard-apl8/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111920v1/shard-apl2/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111920v1/shard-apl8/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111920v1/shard-apl8/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111920v1/shard-apl8/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111920v1/shard-apl8/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111920v1/shard-apl6/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111920v1/shard-apl1/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111920v1/shard-apl6/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111920v1/shard-apl6/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111920v1/shard-apl1/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111920v1/shard-apl6/boot.html
   [37]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111920v1/shard-apl6/boot.html
   [38]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111920v1/shard-apl6/boot.html
   [39]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111920v1/shard-apl6/boot.html
   [40]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111920v1/shard-apl1/boot.html
   [41]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111920v1/shard-apl1/boot.html
   [42]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111920v1/shard-apl3/boot.html
   [43]: 
h

Re: [Intel-gfx] [PATCH 2/7] drm/i915/display: move more scanline functions to intel_vblank.[ch]

2022-12-15 Thread Murthy, Arun R
> -Original Message-
> From: Nikula, Jani 
> Sent: Thursday, December 15, 2022 2:43 PM
> To: Murthy, Arun R ; intel-
> g...@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH 2/7] drm/i915/display: move more scanline
> functions to intel_vblank.[ch]
> 
> On Thu, 15 Dec 2022, "Murthy, Arun R"  wrote:
> >> -Original Message-
> >> From: Nikula, Jani 
> >> Sent: Wednesday, December 14, 2022 2:45 PM
> >> To: Murthy, Arun R ; intel-
> >> g...@lists.freedesktop.org
> >> Subject: RE: [Intel-gfx] [PATCH 2/7] drm/i915/display: move more
> >> scanline functions to intel_vblank.[ch]
> >>
> >> On Wed, 14 Dec 2022, "Murthy, Arun R" 
> wrote:
> >> >> -Original Message-
> >> >> From: Intel-gfx  On
> >> >> Behalf Of Jani Nikula
> >> >> Sent: Monday, December 12, 2022 7:59 PM
> >> >> To: intel-gfx@lists.freedesktop.org
> >> >> Cc: Nikula, Jani 
> >> >> Subject: [Intel-gfx] [PATCH 2/7] drm/i915/display: move more
> >> >> scanline functions to intel_vblank.[ch]
> >> >>
> >> >> Reduce clutter in intel_display.c by moving the scanline
> >> >> moving/stopped wait functions to intel_vblank.[ch].
> >> >>
> >> >> Cc: Ville Syrjälä 
> >> >> Signed-off-by: Jani Nikula 
> >> >> ---
> >> >>  drivers/gpu/drm/i915/display/intel_display.c | 36
> >> >> +--- drivers/gpu/drm/i915/display/intel_vblank.c
> >> >> +|
> >> >> 35 +++
> drivers/gpu/drm/i915/display/intel_vblank.h
> >> >> |
> >> >> 2 ++
> >> >>  3 files changed, 38 insertions(+), 35 deletions(-)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> >> >> b/drivers/gpu/drm/i915/display/intel_display.c
> >> >> index 6cdfdae2c712..0cdb514d7ee0 100644
> >> >> --- a/drivers/gpu/drm/i915/display/intel_display.c
> >> >> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> >> >> @@ -115,6 +115,7 @@
> >> >>  #include "intel_quirks.h"
> >> >>  #include "intel_sprite.h"
> >> >>  #include "intel_tc.h"
> >> >> +#include "intel_vblank.h"
> >> >>  #include "intel_vga.h"
> >> >>  #include "i9xx_plane.h"
> >> >>  #include "skl_scaler.h"
> >> >> @@ -386,41 +387,6 @@ struct intel_crtc *intel_master_crtc(const
> >> >> struct intel_crtc_state *crtc_state)
> >> >>   return to_intel_crtc(crtc_state->uapi.crtc);
> >> >>  }
> >> >>
> >> >> -static bool pipe_scanline_is_moving(struct drm_i915_private
> *dev_priv,
> >> >> - enum pipe pipe)
> >> >> -{
> >> >> - i915_reg_t reg = PIPEDSL(pipe);
> >> >> - u32 line1, line2;
> >> >> -
> >> >> - line1 = intel_de_read(dev_priv, reg) & PIPEDSL_LINE_MASK;
> >> >> - msleep(5);
> >> >> - line2 = intel_de_read(dev_priv, reg) & PIPEDSL_LINE_MASK;
> >> >> -
> >> >> - return line1 != line2;
> >> >> -}
> >> >> -
> >> >> -static void wait_for_pipe_scanline_moving(struct intel_crtc
> >> >> *crtc, bool state) -{
> >> >> - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> >> >> - enum pipe pipe = crtc->pipe;
> >> >> -
> >> >> - /* Wait for the display line to settle/start moving */
> >> >> - if (wait_for(pipe_scanline_is_moving(dev_priv, pipe) == state, 
> >> >> 100))
> >> >> - drm_err(&dev_priv->drm,
> >> >> - "pipe %c scanline %s wait timed out\n",
> >> >> - pipe_name(pipe), str_on_off(state));
> >> >> -}
> >> >> -
> >> >> -static void intel_wait_for_pipe_scanline_stopped(struct intel_crtc
> *crtc) -{
> >> >> - wait_for_pipe_scanline_moving(crtc, false);
> >> >> -}
> >> >> -
> >> >> -static void intel_wait_for_pipe_scanline_moving(struct intel_crtc 
> >> >> *crtc)
> -{
> >> >> - wait_for_pipe_scanline_moving(crtc, true);
> >> >> -}
> >> >> -
> >> >>  static void
> >> >>  intel_wait_for_pipe_off(const struct intel_crtc_state
> >> >> *old_crtc_state)  { diff -- git
> >> >> a/drivers/gpu/drm/i915/display/intel_vblank.c
> >> >> b/drivers/gpu/drm/i915/display/intel_vblank.c
> >> >> index 78a579496ad1..f25ec643a0a3 100644
> >> >> --- a/drivers/gpu/drm/i915/display/intel_vblank.c
> >> >> +++ b/drivers/gpu/drm/i915/display/intel_vblank.c
> >> >> @@ -417,3 +417,38 @@ int intel_get_crtc_scanline(struct intel_crtc
> >> >> *crtc)
> >> >>
> >> >>   return position;
> >> >>  }
> >> >> +
> >> >> +static bool pipe_scanline_is_moving(struct drm_i915_private
> *dev_priv,
> >> >> + enum pipe pipe) {
> >> >> + i915_reg_t reg = PIPEDSL(pipe);
> >> >> + u32 line1, line2;
> >> >> +
> >> >> + line1 = intel_de_read(dev_priv, reg) & PIPEDSL_LINE_MASK;
> >> >> + msleep(5);
> >> >> + line2 = intel_de_read(dev_priv, reg) & PIPEDSL_LINE_MASK;
> >> >> +
> >> >> + return line1 != line2;
> >> >> +}
> >> >> +
> >> >> +static void wait_for_pipe_scanline_moving(struct intel_crtc
> >> >> +*crtc, bool
> >> >> +state) {
> >> >> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> >> >> + enum pipe pipe = crtc->pipe;
> >> >> +
> >> >> + /* Wait for the display line to settle/start moving */
> >> >> 

[Intel-gfx] [PATCHv6] drm/i915/dp: change aux_ctl reg read to polling read

2022-12-15 Thread Arun R Murthy
The busy timeout logic checks for the AUX BUSY, then waits for the
timeout period and then after timeout reads the register for BUSY or
Success.
Instead replace interrupt with polling so as to read the AUX CTL
register often before the timeout period. Looks like there might be some
issue with interrupt-on-read. Hence changing the logic to polling read.

v2: replace interrupt with polling read
v3: use usleep_rang instead of msleep, updated commit msg
v4: use intel_wait_for_regiter internal function
v5: use __intel_de_wait_for_register with 500us slow and 10ms fast timeout
v6: check return value of __intel_de_wait_for_register

Signed-off-by: Arun R Murthy 
---
 drivers/gpu/drm/i915/display/intel_dp_aux.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux.c
index 91c93c93e5fc..dec88f41380e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
@@ -40,21 +40,16 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp)
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
const unsigned int timeout_ms = 10;
-   u32 status;
-   bool done;
-
-#define C (((status = intel_de_read_notrace(i915, ch_ctl)) & 
DP_AUX_CH_CTL_SEND_BUSY) == 0)
-   done = wait_event_timeout(i915->display.gmbus.wait_queue, C,
- msecs_to_jiffies_timeout(timeout_ms));
+   u32 status, ret;
 
-   /* just trace the final value */
-   trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
+   ret = __intel_de_wait_for_register(i915, ch_ctl,
+DP_AUX_CH_CTL_SEND_BUSY, 0,
+500, timeout_ms, &status);
 
-   if (!done)
+   if (ret == -ETIMEDOUT)
drm_err(&i915->drm,
"%s: did not complete or timeout within %ums (status 
0x%08x)\n",
intel_dp->aux.name, timeout_ms, status);
-#undef C
 
return status;
 }
-- 
2.25.1



Re: [Intel-gfx] [PATCH 2/7] drm/i915/display: move more scanline functions to intel_vblank.[ch]

2022-12-15 Thread Jani Nikula
On Thu, 15 Dec 2022, "Murthy, Arun R"  wrote:
>> -Original Message-
>> From: Nikula, Jani 
>> Sent: Wednesday, December 14, 2022 2:45 PM
>> To: Murthy, Arun R ; intel-
>> g...@lists.freedesktop.org
>> Subject: RE: [Intel-gfx] [PATCH 2/7] drm/i915/display: move more scanline
>> functions to intel_vblank.[ch]
>>
>> On Wed, 14 Dec 2022, "Murthy, Arun R"  wrote:
>> >> -Original Message-
>> >> From: Intel-gfx  On Behalf
>> >> Of Jani Nikula
>> >> Sent: Monday, December 12, 2022 7:59 PM
>> >> To: intel-gfx@lists.freedesktop.org
>> >> Cc: Nikula, Jani 
>> >> Subject: [Intel-gfx] [PATCH 2/7] drm/i915/display: move more scanline
>> >> functions to intel_vblank.[ch]
>> >>
>> >> Reduce clutter in intel_display.c by moving the scanline
>> >> moving/stopped wait functions to intel_vblank.[ch].
>> >>
>> >> Cc: Ville Syrjälä 
>> >> Signed-off-by: Jani Nikula 
>> >> ---
>> >>  drivers/gpu/drm/i915/display/intel_display.c | 36
>> >> +--- drivers/gpu/drm/i915/display/intel_vblank.c  |
>> >> 35 +++ drivers/gpu/drm/i915/display/intel_vblank.h  |
>> >> 2 ++
>> >>  3 files changed, 38 insertions(+), 35 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>> >> b/drivers/gpu/drm/i915/display/intel_display.c
>> >> index 6cdfdae2c712..0cdb514d7ee0 100644
>> >> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> >> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> >> @@ -115,6 +115,7 @@
>> >>  #include "intel_quirks.h"
>> >>  #include "intel_sprite.h"
>> >>  #include "intel_tc.h"
>> >> +#include "intel_vblank.h"
>> >>  #include "intel_vga.h"
>> >>  #include "i9xx_plane.h"
>> >>  #include "skl_scaler.h"
>> >> @@ -386,41 +387,6 @@ struct intel_crtc *intel_master_crtc(const
>> >> struct intel_crtc_state *crtc_state)
>> >>   return to_intel_crtc(crtc_state->uapi.crtc);
>> >>  }
>> >>
>> >> -static bool pipe_scanline_is_moving(struct drm_i915_private *dev_priv,
>> >> - enum pipe pipe)
>> >> -{
>> >> - i915_reg_t reg = PIPEDSL(pipe);
>> >> - u32 line1, line2;
>> >> -
>> >> - line1 = intel_de_read(dev_priv, reg) & PIPEDSL_LINE_MASK;
>> >> - msleep(5);
>> >> - line2 = intel_de_read(dev_priv, reg) & PIPEDSL_LINE_MASK;
>> >> -
>> >> - return line1 != line2;
>> >> -}
>> >> -
>> >> -static void wait_for_pipe_scanline_moving(struct intel_crtc *crtc,
>> >> bool state) -{
>> >> - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> >> - enum pipe pipe = crtc->pipe;
>> >> -
>> >> - /* Wait for the display line to settle/start moving */
>> >> - if (wait_for(pipe_scanline_is_moving(dev_priv, pipe) == state, 100))
>> >> - drm_err(&dev_priv->drm,
>> >> - "pipe %c scanline %s wait timed out\n",
>> >> - pipe_name(pipe), str_on_off(state));
>> >> -}
>> >> -
>> >> -static void intel_wait_for_pipe_scanline_stopped(struct intel_crtc 
>> >> *crtc) -{
>> >> - wait_for_pipe_scanline_moving(crtc, false);
>> >> -}
>> >> -
>> >> -static void intel_wait_for_pipe_scanline_moving(struct intel_crtc *crtc) 
>> >> -{
>> >> - wait_for_pipe_scanline_moving(crtc, true);
>> >> -}
>> >> -
>> >>  static void
>> >>  intel_wait_for_pipe_off(const struct intel_crtc_state
>> >> *old_crtc_state)  { diff -- git
>> >> a/drivers/gpu/drm/i915/display/intel_vblank.c
>> >> b/drivers/gpu/drm/i915/display/intel_vblank.c
>> >> index 78a579496ad1..f25ec643a0a3 100644
>> >> --- a/drivers/gpu/drm/i915/display/intel_vblank.c
>> >> +++ b/drivers/gpu/drm/i915/display/intel_vblank.c
>> >> @@ -417,3 +417,38 @@ int intel_get_crtc_scanline(struct intel_crtc
>> >> *crtc)
>> >>
>> >>   return position;
>> >>  }
>> >> +
>> >> +static bool pipe_scanline_is_moving(struct drm_i915_private *dev_priv,
>> >> + enum pipe pipe) {
>> >> + i915_reg_t reg = PIPEDSL(pipe);
>> >> + u32 line1, line2;
>> >> +
>> >> + line1 = intel_de_read(dev_priv, reg) & PIPEDSL_LINE_MASK;
>> >> + msleep(5);
>> >> + line2 = intel_de_read(dev_priv, reg) & PIPEDSL_LINE_MASK;
>> >> +
>> >> + return line1 != line2;
>> >> +}
>> >> +
>> >> +static void wait_for_pipe_scanline_moving(struct intel_crtc *crtc,
>> >> +bool
>> >> +state) {
>> >> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> >> + enum pipe pipe = crtc->pipe;
>> >> +
>> >> + /* Wait for the display line to settle/start moving */
>> >> + if (wait_for(pipe_scanline_is_moving(dev_priv, pipe) == state, 100))
>> >> + drm_err(&dev_priv->drm,
>> >> + "pipe %c scanline %s wait timed out\n",
>> >> + pipe_name(pipe), str_on_off(state)); }
>> >> +
>> >> +void intel_wait_for_pipe_scanline_stopped(struct intel_crtc *crtc) {
>> >> + wait_for_pipe_scanline_moving(crtc, false); }
>> >> +
>> > Is this wrapper function required, since nothing else is being other
>> > than calling the function wait_for_pipe_scanli

Re: [Intel-gfx] [PATCHv5] drm/i915/dp: change aux_ctl reg read to polling read

2022-12-15 Thread Jani Nikula
On Wed, 14 Dec 2022, Arun R Murthy  wrote:
> The busy timeout logic checks for the AUX BUSY, then waits for the
> timeout period and then after timeout reads the register for BUSY or
> Success.
> Instead replace interrupt with polling so as to read the AUX CTL
> register often before the timeout period. Looks like there might be some
> issue with interrupt-on-read. Hence changing the logic to polling read.
>
> v2: replace interrupt with polling read
> v3: use usleep_rang instead of msleep, updated commit msg
> v4: use intel_wait_for_regiter internal function
> v5: use __intel_de_wait_for_register with 500us slow and 10ms fast timeout
>
> Signed-off-by: Arun R Murthy 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_aux.c | 35 ++---
>  1 file changed, 9 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c 
> b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> index 91c93c93e5fc..772da38b451f 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> @@ -34,31 +34,6 @@ static void intel_dp_aux_unpack(u32 src, u8 *dst, int 
> dst_bytes)
>   dst[i] = src >> ((3 - i) * 8);
>  }
>  
> -static u32
> -intel_dp_aux_wait_done(struct intel_dp *intel_dp)
> -{
> - struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> - i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
> - const unsigned int timeout_ms = 10;
> - u32 status;
> - bool done;
> -
> -#define C (((status = intel_de_read_notrace(i915, ch_ctl)) & 
> DP_AUX_CH_CTL_SEND_BUSY) == 0)
> - done = wait_event_timeout(i915->display.gmbus.wait_queue, C,
> -   msecs_to_jiffies_timeout(timeout_ms));
> -
> - /* just trace the final value */
> - trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
> -
> - if (!done)
> - drm_err(&i915->drm,
> - "%s: did not complete or timeout within %ums (status 
> 0x%08x)\n",
> - intel_dp->aux.name, timeout_ms, status);
> -#undef C
> -
> - return status;
> -}
> -

Please keep the function.

intel_dp_aux_xfer() is long enough as it is. It really doesn't need the
added lines, quite the opposite.

The intel_dp_aux_wait_done() also gives a name to what's being done.

>  static u32 g4x_get_aux_clock_divider(struct intel_dp *intel_dp, int index)
>  {
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> @@ -264,6 +239,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
>   }
>  
>   while ((aux_clock_divider = intel_dp->get_aux_clock_divider(intel_dp, 
> clock++))) {
> + u32 timeout_ms = 10;
>   u32 send_ctl = intel_dp->get_aux_send_ctl(intel_dp,
> send_bytes,
> aux_clock_divider);
> @@ -281,7 +257,14 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
>   /* Send the command and wait for it to complete */
>   intel_de_write(i915, ch_ctl, send_ctl);
>  
> - status = intel_dp_aux_wait_done(intel_dp);
> + __intel_de_wait_for_register(i915, ch_ctl,
> +  DP_AUX_CH_CTL_SEND_BUSY, 0,
> +  500, timeout_ms, &status);
> +
> + if ((status & DP_AUX_CH_CTL_SEND_BUSY) != 0)
> + drm_err(&i915->drm,
> + "%s: did not complete or timeout within 
> %ums (status 0x%08x)\n",
> + intel_dp->aux.name, timeout_ms, status);

Please use the return value of intel_de_wait_for_register() to determine
the timeout instead of duplicating the condition. (Feels like I said
this a few times already?)

BR,
Jani.

>  
>   /* Clear done status and any errors */
>   intel_de_write(i915, ch_ctl,

-- 
Jani Nikula, Intel Open Source Graphics Center


Re: [Intel-gfx] [PATCH] drm/i915: ratelimit errors in display engine irq

2022-12-15 Thread Jani Nikula
On Wed, 14 Dec 2022, Lucas De Marchi  wrote:
> While debugging page table faults it's useful not to kill the machine
> with thousands of error mesages. Ratelimit all errors in
> gen8_de_irq_handler().
>
> Signed-off-by: Lucas De Marchi 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/i915_irq.c | 28 ++--
>  1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index edfe363af838..7a43d1bb6f97 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2448,8 +2448,8 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
> u32 master_ctl)
>   ret = IRQ_HANDLED;
>   gen8_de_misc_irq_handler(dev_priv, iir);
>   } else {
> - drm_err(&dev_priv->drm,
> - "The master control interrupt lied (DE 
> MISC)!\n");
> + drm_err_ratelimited(&dev_priv->drm,
> + "The master control interrupt lied 
> (DE MISC)!\n");
>   }
>   }
>  
> @@ -2460,8 +2460,8 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
> u32 master_ctl)
>   ret = IRQ_HANDLED;
>   gen11_hpd_irq_handler(dev_priv, iir);
>   } else {
> - drm_err(&dev_priv->drm,
> - "The master control interrupt lied, (DE 
> HPD)!\n");
> + drm_err_ratelimited(&dev_priv->drm,
> + "The master control interrupt lied, 
> (DE HPD)!\n");
>   }
>   }
>  
> @@ -2510,12 +2510,12 @@ gen8_de_irq_handler(struct drm_i915_private 
> *dev_priv, u32 master_ctl)
>   }
>  
>   if (!found)
> - drm_err(&dev_priv->drm,
> - "Unexpected DE Port interrupt\n");
> + drm_err_ratelimited(&dev_priv->drm,
> + "Unexpected DE Port 
> interrupt\n");
>   }
>   else
> - drm_err(&dev_priv->drm,
> - "The master control interrupt lied (DE 
> PORT)!\n");
> + drm_err_ratelimited(&dev_priv->drm,
> + "The master control interrupt lied 
> (DE PORT)!\n");
>   }
>  
>   for_each_pipe(dev_priv, pipe) {
> @@ -2526,8 +2526,8 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
> u32 master_ctl)
>  
>   iir = intel_uncore_read(&dev_priv->uncore, 
> GEN8_DE_PIPE_IIR(pipe));
>   if (!iir) {
> - drm_err(&dev_priv->drm,
> - "The master control interrupt lied (DE 
> PIPE)!\n");
> + drm_err_ratelimited(&dev_priv->drm,
> + "The master control interrupt lied 
> (DE PIPE)!\n");
>   continue;
>   }
>  
> @@ -2548,10 +2548,10 @@ gen8_de_irq_handler(struct drm_i915_private 
> *dev_priv, u32 master_ctl)
>  
>   fault_errors = iir & gen8_de_pipe_fault_mask(dev_priv);
>   if (fault_errors)
> - drm_err(&dev_priv->drm,
> - "Fault errors on pipe %c: 0x%08x\n",
> - pipe_name(pipe),
> - fault_errors);
> + drm_err_ratelimited(&dev_priv->drm,
> + "Fault errors on pipe %c: 0x%08x\n",
> + pipe_name(pipe),
> + fault_errors);
>   }
>  
>   if (HAS_PCH_SPLIT(dev_priv) && !HAS_PCH_NOP(dev_priv) &&

-- 
Jani Nikula, Intel Open Source Graphics Center


Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/mtl/UAPI: Disable GET/SET_CACHING IOCTL for MTL+

2022-12-15 Thread Iddamsetty, Aravind



On 07-12-2022 05:19, Matt Roper wrote:
> On Tue, Dec 06, 2022 at 01:57:39PM +0530, Aravind Iddamsetty wrote:
>> From: Pallavi Mishra 
>>
>> It's a noop on all new platforms starting from MTL.
> 
> To me, saying "it's a noop" implies that the ioctl will succeed and
> silently do nothing, which isn't the case in this patch.  We're
> explicitly rejecting attempts by userspace to use these ioctls.
> 
>> Refer: (e7737b67ab46) drm/i915/uapi: reject caching ioctls for discrete
> 
> While killing set_caching/get_caching is the way we want to go, I think
> we need a lot more explanation of how cache behavior in general is
> supposed to work now.  I believe the plan is that userspace will supply
> the specific PAT index that corresponds to the behavior they want via a
> vm_bind extension?  I'm not familiar with the details of how that will
> work...does that mean that the caching behavior will also be tied to the
> specific mapping of an object in the GTT rather than being tied to the
> object itself?  I.e., you can map the same object twice with two
> different caching behaviors?
Like i mentioned in other email part of this series. The current plan
atleast is to set the caching for an object during creation time
depending on the platform so for MTL it would be UNCACHED. The PAT index
setting via VM_BIND is yet not planned.

Thanks,
Aravind.
> 
> Is there a uapi RFC document available yet that describes the high-level
> view of how all this stuff fits together now?  If so, a reference to
> that would be good to include.
> 
> 
> Matt
> 
>>
>> v2:
>> 1. block get caching ioctl
>> 2. return ENODEV similar to DGFX
>> 3. update the doc in i915_drm.h
>>
>> Cc: Lucas De Marchi 
>> Cc: Matt Roper 
>> Cc: Joonas Lahtinen 
>>
>> Signed-off-by: Pallavi Mishra 
>> Signed-off-by: Aravind Iddamsetty 
>> ---
>>  drivers/gpu/drm/i915/gem/i915_gem_domain.c | 4 ++--
>>  include/uapi/drm/i915_drm.h| 3 +++
>>  2 files changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
>> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>> index d44a152ce680..cf817ee0aa01 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
>> @@ -291,7 +291,7 @@ int i915_gem_get_caching_ioctl(struct drm_device *dev, 
>> void *data,
>>  struct drm_i915_gem_object *obj;
>>  int err = 0;
>>  
>> -if (IS_DGFX(to_i915(dev)))
>> +if (IS_DGFX(to_i915(dev)) || GRAPHICS_VER_FULL(to_i915(dev)) >= 
>> IP_VER(12, 70))
>>  return -ENODEV;
>>  
>>  rcu_read_lock();
>> @@ -329,7 +329,7 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, 
>> void *data,
>>  enum i915_cache_level level;
>>  int ret = 0;
>>  
>> -if (IS_DGFX(i915))
>> +if (IS_DGFX(i915) || GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
>>  return -ENODEV;
>>  
>>  switch (args->caching) {
>> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
>> index 8df261c5ab9b..3467fd879427 100644
>> --- a/include/uapi/drm/i915_drm.h
>> +++ b/include/uapi/drm/i915_drm.h
>> @@ -1626,6 +1626,9 @@ struct drm_i915_gem_busy {
>>   * - Everything else is always allocated and mapped as write-back, with 
>> the
>>   *   guarantee that everything is also coherent with the GPU.
>>   *
>> + * Starting from MTL even on integrated platforms set/get caching is no 
>> longer
>> + * supported and object will be mapped as write-combined only.
>> + *
>>   * Note that this is likely to change in the future again, where we might 
>> need
>>   * more flexibility on future devices, so making this all explicit as part 
>> of a
>>   * new &drm_i915_gem_create_ext extension is probable.
>> -- 
>> 2.25.1
>>
>