✗ Fi.CI.IGT: failure for drm/mm: Allow CONFIG_DRM_MM_DEBUG with DRM=m (rev2)

[Patchwork]

== Series Details ==

Series: drm/mm: Allow CONFIG_DRM_MM_DEBUG with DRM=m (rev2)
URL   : https://patchwork.freedesktop.org/series/127871/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_14033_full -> Patchwork_127871v2_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_127871v2_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_127871v2_full, please notify your bug team 
(i915-ci-in...@lists.freedesktop.org) 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_127871v2/index.html

Participating hosts (9 -> 8)
--

  Missing(1): shard-snb-0 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip@flip-vs-panning-vs-hang@b-vga1:
- shard-snb:  [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/shard-snb4/igt@kms_flip@flip-vs-panning-vs-h...@b-vga1.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127871v2/shard-snb2/igt@kms_flip@flip-vs-panning-vs-h...@b-vga1.html

  
 Warnings 

  * igt@i915_pm_rps@engine-order:
- shard-snb:  [INCOMPLETE][3] ([i915#9847]) -> [INCOMPLETE][4] +1 
other test incomplete
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/shard-snb2/igt@i915_pm_...@engine-order.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127871v2/shard-snb6/igt@i915_pm_...@engine-order.html

  
New tests
-

  New tests have been introduced between CI_DRM_14033_full and 
Patchwork_127871v2_full:

### New IGT tests (3) ###

  * igt@gem_ctx_engines@independent@all-engines:
- Statuses : 6 pass(s)
- Exec time: [0.09, 1.59] s

  * igt@gem_exec_gttfill@all-engines:
- Statuses : 7 pass(s)
- Exec time: [22.74, 29.84] s

  * igt@gem_wait@write-wait@all-engines:
- Statuses : 1 pass(s)
- Exec time: [1.13] s

  

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-rkl:  ([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], [PASS][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], 
[FAIL][51], [PASS][52], [PASS][53]) ([i915#8293])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/shard-rkl-1/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/shard-rkl-1/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/shard-rkl-1/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/shard-rkl-1/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/shard-rkl-1/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/shard-rkl-7/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/shard-rkl-7/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/shard-rkl-7/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/shard-rkl-7/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/shard-rkl-6/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/shard-rkl-6/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/shard-rkl-5/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/shard-rkl-5/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/shard-rkl-5/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/shard-rkl-5/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/shard-rkl-5/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/shard-rkl-5/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/shard-rkl-4/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/shard-rkl-4/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/shard-rkl-4/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/shard-rkl-4/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/shard-rkl-4/boot.html
   [27]: 

✓ Fi.CI.BAT: success for drm/mm: Allow CONFIG_DRM_MM_DEBUG with DRM=m (rev2)

[Patchwork]

== Series Details ==

Series: drm/mm: Allow CONFIG_DRM_MM_DEBUG with DRM=m (rev2)
URL   : https://patchwork.freedesktop.org/series/127871/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14033 -> Patchwork_127871v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (38 -> 35)
--

  Missing(3): bat-rpls-2 bat-kbl-2 fi-snb-2520m 

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-bsw-n3050:   [PASS][1] -> [FAIL][2] ([i915#8293])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/fi-bsw-n3050/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127871v2/fi-bsw-n3050/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@hugepages:
- bat-adlm-1: [PASS][3] -> [INCOMPLETE][4] ([i915#9527])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/bat-adlm-1/igt@i915_selftest@l...@hugepages.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127871v2/bat-adlm-1/igt@i915_selftest@l...@hugepages.html

  * igt@kms_pipe_crc_basic@nonblocking-crc:
- bat-adlp-9: NOTRUN -> [SKIP][5] ([i915#9826])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127871v2/bat-adlp-9/igt@kms_pipe_crc_ba...@nonblocking-crc.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- fi-ivb-3770:NOTRUN -> [SKIP][6] ([fdo#109271])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127871v2/fi-ivb-3770/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293
  [i915#9527]: https://gitlab.freedesktop.org/drm/intel/issues/9527
  [i915#9826]: https://gitlab.freedesktop.org/drm/intel/issues/9826


Build changes
-

  * Linux: CI_DRM_14033 -> Patchwork_127871v2

  CI-20190529: 20190529
  CI_DRM_14033: e6580f88bbde08a04d0cb7bb591c38e7b9f0076d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7643: ced22f8bf4263ff395dc852c86b682e62a7a1c1b @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_127871v2: e6580f88bbde08a04d0cb7bb591c38e7b9f0076d @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

ac024e106245 drm/mm: Allow CONFIG_DRM_MM_DEBUG with DRM=m

== Logs ==

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

Re: [PATCH 3/4] drm/ttm: improve idle/busy handling

[kernel test robot]

Hi Christian,

kernel test robot noticed the following build warnings:

[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-intel/for-linux-next 
drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.7-rc5 
next-20231215]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Christian-K-nig/drm-ttm-replace-busy-placement-with-flags-v3/20231213-224456
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20231213144222.1871-3-christian.koenig%40amd.com
patch subject: [PATCH 3/4] drm/ttm: improve idle/busy handling
config: x86_64-defconfig 
(https://download.01.org/0day-ci/archive/20231216/202312160809.nvmibwrj-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-12) 11.3.0
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20231216/202312160809.nvmibwrj-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202312160809.nvmibwrj-...@intel.com/

All warnings (new ones prefixed by >>):

>> scripts/kernel-doc: drivers/gpu/drm/ttm/ttm_resource.c:301: warning: 
>> Function parameter or struct member 'busy' not described in 
>> 'ttm_resource_compatible'

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH v3 1/2] drm/i915/display: Add support for darskscreen detection

[Matt Roper]

On Wed, Dec 13, 2023 at 02:36:40PM +0530, Nemesa Garg wrote:
> Darkscreen detection checks if all the pixels of the frame are less then
> or equal to the comparision value. The comparision value is set to 256
> i.e black. So upon getting black pixels from the pipe, the dark screen
> detect bit is set and an error message will be printed.

As others have noted, you seem to be mixing two different designs here
in a way that doesn't really make sense.  At the hardware level, it's
possible to request a check for a dark screen[*] and then get a yes/no
response back shortly.  But how that functionality gets utilized and
exposed to users is something that can be approached in different ways.
I can think of a couple options for how this could be handled:

  Option 1:  The simplest option is to create a debugfs that tells me
  whether the screen is dark *right now*.  I.e., "cat /darkscreen"
  returns an immediate "yes" or "no" answer.  Every time I re-cat it, I
  get a new answer; there's no concept of enable/disable at the API
  level.  I can see this being very useful in some IGT tests like
  testdisplay (make sure the output isn't blank after switching to a
  mode) or kms_plane (make sure the output _is_ blank at certain points
  when all planes are supposed to be off).
  
  Option 2:  A more complicated option is to create an interface with
  start/stop behavior that indicates whether the screen ever went dark
  between two points in time.  I'm sure there are ways this could be
  used, although it's a little harder to figure out where we'd utilize
  it to our benefit in the IGT tests we have today.

The code you have in these patches seems to be trying to expose an
enable/disable debugfs interface, but only does its checking a single
time right at the 'enable' point.  There's no reason to actually leave
the hardware setting enabled after that point because you never go back
and check again.  And the current implementation also doesn't return the
status to the user in any way, it just prints out a log message, so that
pretty much kills the ability to use this in something like IGT.

So as others have said, you need to figure out what the goal is here.
I.e., who do you expect to use this and how?  Based on the answer to
that, you can figure out what kind of user-facing interface is
appropriate, and then provide corresponding changes to some userspace
software (probably IGT for a debug-specific facility like this) that
utilizes the new capability.


[*] BTW, it's also worth noting that no matter what this interface can't
detect all cases where the display is blank.  The hardware support for
this appears to be at the end of the pipe, so if the monitor is blank
due to mistakes in the programming of the DSC, transcoder, DDI, or phy,
the darkscreen detection won't notice.  However it will be useful for
catching certain mistakes in the programming of planes, scalers, or
color management.


> 
> v2: Addressed review comments [Jani]
> v3: Addressed review comments [Arun]

Changelogs like this are pretty useless; without digging through mailing
list history, nobody (often including the original reviewers) remembers
exactly what the review comments were.  It's hard to tell which parts of
your patch have been reworked from the previous revision, or to
determine whether you saw and handled all of the feedback or just part
of it.  It's better to give a brief description of what actually changed
in the new version.  E.g.,

  v2:
- Added foo check.  (Jani)
- Reordered bar and baz.  (Jani)
  v3:
- Added locking to xyz.  (Arun)
- Drop unnecessary abc check.  (Arun)


Matt

> 
> Signed-off-by: Nemesa Garg 
> ---
>  drivers/gpu/drm/i915/Makefile |  1 +
>  .../gpu/drm/i915/display/intel_darkscreen.c   | 95 +++
>  .../gpu/drm/i915/display/intel_darkscreen.h   | 26 +
>  .../drm/i915/display/intel_display_types.h|  2 +
>  drivers/gpu/drm/i915/i915_reg.h   |  8 ++
>  drivers/gpu/drm/xe/Makefile   |  1 +
>  6 files changed, 133 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/display/intel_darkscreen.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_darkscreen.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index dc2469a4ead7..0322105a4c05 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -244,6 +244,7 @@ i915-y += \
>   display/intel_crtc.o \
>   display/intel_crtc_state_dump.o \
>   display/intel_cursor.o \
> + display/intel_darkscreen.o \
>   display/intel_display.o \
>   display/intel_display_driver.o \
>   display/intel_display_irq.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_darkscreen.c 
> b/drivers/gpu/drm/i915/display/intel_darkscreen.c
> new file mode 100644
> index ..7c42988af354
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_darkscreen.c
> @@ -0,0 +1,95 @@
> +// 

✗ Fi.CI.IGT: failure for drm/i915: Eaerly ggtt pinning stuff

[Patchwork]

== Series Details ==

Series: drm/i915: Eaerly ggtt pinning stuff
URL   : https://patchwork.freedesktop.org/series/127870/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_14030_full -> Patchwork_127870v1_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_127870v1_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_127870v1_full, please notify your bug team 
(i915-ci-in...@lists.freedesktop.org) to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Participating hosts (8 -> 8)
--

  Additional (1): shard-glk-0 
  Missing(1): shard-snb-0 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_pipe_stress@stress-xrgb-untiled:
- shard-snb:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-snb7/igt@i915_pipe_str...@stress-xrgb-untiled.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127870v1/shard-snb1/igt@i915_pipe_str...@stress-xrgb-untiled.html

  
 Warnings 

  * igt@gem_ctx_freq@sysfs@gt0:
- shard-rkl:  [ABORT][3] ([i915#9847]) -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-rkl-6/igt@gem_ctx_freq@sy...@gt0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127870v1/shard-rkl-7/igt@gem_ctx_freq@sy...@gt0.html

  * igt@i915_pm_rps@engine-order:
- shard-dg1:  [ABORT][5] ([i915#9847]) -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-dg1-13/igt@i915_pm_...@engine-order.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127870v1/shard-dg1-16/igt@i915_pm_...@engine-order.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-glk:  ([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]) -> ([PASS][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], [FAIL][45], [PASS][46], 
[PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52], 
[PASS][53], [PASS][54], [PASS][55], [PASS][56]) ([i915#8293])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk9/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk9/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk8/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk8/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk8/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk7/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk7/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk7/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk6/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk6/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk6/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk6/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk4/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk4/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk4/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk3/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk3/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk3/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk3/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk2/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk2/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk2/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk1/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk1/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/shard-glk1/boot.html
   [32]: 

✓ Fi.CI.IGT: success for drm/i915/display: C20 clock state verification

[Patchwork]

== Series Details ==

Series: drm/i915/display: C20 clock state verification
URL   : https://patchwork.freedesktop.org/series/127858/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14027_full -> Patchwork_127858v1_full


Summary
---

  **WARNING**

  Minor unknown changes coming with Patchwork_127858v1_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_127858v1_full, please notify your bug team 
(i915-ci-in...@lists.freedesktop.org) to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Participating hosts (8 -> 8)
--

  Additional (1): shard-snb-0 
  Missing(1): shard-glk-0 

Possible new issues
---

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

### IGT changes ###

 Warnings 

  * igt@gem_ctx_freq@sysfs@gt0:
- shard-glk:  [ABORT][1] ([i915#9847]) -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk1/igt@gem_ctx_freq@sy...@gt0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127858v1/shard-glk8/igt@gem_ctx_freq@sy...@gt0.html

  * igt@i915_pm_rps@engine-order:
- shard-snb:  [INCOMPLETE][3] ([i915#9847]) -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-snb7/igt@i915_pm_...@engine-order.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127858v1/shard-snb4/igt@i915_pm_...@engine-order.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- shard-glk:  ([PASS][5], [PASS][6], [PASS][7], [PASS][8], 
[PASS][9], [PASS][10], [FAIL][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]) ([i915#8293]) -> ([PASS][30], [PASS][31], 
[PASS][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], [PASS][51], [PASS][52], [PASS][53], [PASS][54])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk9/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk9/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk9/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk9/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk8/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk8/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk7/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk6/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk6/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk5/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk4/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk4/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk4/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk4/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk3/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk3/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk3/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk3/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk2/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk2/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk2/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk2/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk1/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk1/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/shard-glk1/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127858v1/shard-glk9/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127858v1/shard-glk9/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127858v1/shard-glk8/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127858v1/shard-glk8/boot.html
   [34]: 

✗ Fi.CI.IGT: failure for drm/edid: prefer forward declarations over includes in drm_edid.h

[Patchwork]

== Series Details ==

Series: drm/edid: prefer forward declarations over includes in drm_edid.h
URL   : https://patchwork.freedesktop.org/series/127695/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_14010_full -> Patchwork_127695v1_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_127695v1_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_127695v1_full, please notify your bug team 
(i915-ci-in...@lists.freedesktop.org) to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Participating hosts (8 -> 8)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_suspend@basic-s0@smem:
- shard-dg2:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-dg2-2/igt@gem_exec_suspend@basic...@smem.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/shard-dg2-5/igt@gem_exec_suspend@basic...@smem.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- shard-glk:  ([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], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], 
[PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [FAIL][42], 
[PASS][43], [PASS][44], [FAIL][45], [PASS][46], [PASS][47], [PASS][48], 
[PASS][49], [PASS][50], [PASS][51]) ([i915#8293])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-glk9/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-glk9/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-glk9/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-glk8/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-glk8/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-glk8/boot.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-glk7/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-glk7/boot.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-glk7/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-glk6/boot.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-glk6/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-glk5/boot.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-glk4/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-glk4/boot.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-glk4/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-glk3/boot.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-glk3/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-glk3/boot.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-glk2/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-glk2/boot.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-glk2/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-glk1/boot.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-glk1/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/shard-glk1/boot.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/shard-glk9/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/shard-glk9/boot.html
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/shard-glk1/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/shard-glk1/boot.html
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/shard-glk1/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/shard-glk1/boot.html
   [33]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/shard-glk2/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/shard-glk2/boot.html
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/shard-glk3/boot.html
 

✓ Fi.CI.BAT: success for perf: Fix perf_event_validate_size() lockdep splat

[Patchwork]

== Series Details ==

Series: perf: Fix perf_event_validate_size() lockdep splat
URL   : https://patchwork.freedesktop.org/series/127883/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14033 -> Patchwork_127883v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (38 -> 37)
--

  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [PASS][1] -> [ABORT][2] ([i915#8668])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127883v1/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html

  
 Possible fixes 

  * igt@kms_pm_rpm@basic-rte:
- bat-rpls-2: [ABORT][3] ([i915#8668]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/bat-rpls-2/igt@kms_pm_...@basic-rte.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127883v1/bat-rpls-2/igt@kms_pm_...@basic-rte.html

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

  [i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668


Build changes
-

  * Linux: CI_DRM_14033 -> Patchwork_127883v1

  CI-20190529: 20190529
  CI_DRM_14033: e6580f88bbde08a04d0cb7bb591c38e7b9f0076d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7643: ced22f8bf4263ff395dc852c86b682e62a7a1c1b @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_127883v1: e6580f88bbde08a04d0cb7bb591c38e7b9f0076d @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

7030b20077d7 perf: Fix perf_event_validate_size() lockdep splat

== Logs ==

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

RE: [PATCH v2 04/15] drm/i915: Bypass LMEMBAR/GTTMMADR for MTL stolen memory access

[Sripada, Radhakrishna]

> -Original Message-
> From: Ville Syrjala 
> Sent: Friday, December 15, 2023 2:59 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Paz Zcharya ; Das, Nirmoy ;
> Sripada, Radhakrishna ; Joonas Lahtinen
> 
> Subject: [PATCH v2 04/15] drm/i915: Bypass LMEMBAR/GTTMMADR for MTL
> stolen memory access
> 
> From: Ville Syrjälä 
> 
> On MTL accessing stolen memory via the BARs is somehow borked,
> and it can hang the machine. As a workaround let's bypass the
> BARs and just go straight to DSMBASE/GSMBASE instead.
> 
> Note that on every other platform this itself would hang the
> machine, but on MTL the system firmware is expected to relax
> the access permission guarding stolen memory to enable this
> workaround, and thus direct CPU accesses should be fine.
> 
> TODO: add w/a numbers and whatnot
Wa_22018444074 is more appropriate here.

With that,
Reviewed-by: Radhakrishna Sripada 

> 
> Cc: Paz Zcharya 
> Cc: Nirmoy Das 
> Cc: Radhakrishna Sripada 
> Cc: Joonas Lahtinen 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 11 ++-
>  drivers/gpu/drm/i915/gt/intel_ggtt.c   | 13 -
>  2 files changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index ee237043c302..252fe5cd6ede 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> @@ -941,7 +941,16 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private
> *i915, u16 type,
>   dsm_size = ALIGN_DOWN(lmem_size - dsm_base, SZ_1M);
>   }
> 
> - if (pci_resource_len(pdev, GEN12_LMEM_BAR) < lmem_size) {
> + if (IS_METEORLAKE(i915)) {
> + /*
> +  * Workaround: access via BAR can hang MTL, go directly to
> DSM.
> +  *
> +  * Normally this would not work but on MTL the system
> firmware
> +  * should have relaxed the access permissions sufficiently.
> +  */
> + io_start = intel_uncore_read64(uncore, GEN12_DSMBASE) &
> GEN12_BDSM_MASK;
> + io_size = dsm_size;
> + } else if (pci_resource_len(pdev, GEN12_LMEM_BAR) < lmem_size) {
>   io_start = 0;
>   io_size = 0;
>   } else {
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index 21a7e3191c18..ab71d74ec426 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -24,6 +24,7 @@
>  #include "intel_ring.h"
>  #include "i915_drv.h"
>  #include "i915_pci.h"
> +#include "i915_reg.h"
>  #include "i915_request.h"
>  #include "i915_scatterlist.h"
>  #include "i915_utils.h"
> @@ -1152,13 +1153,23 @@ static unsigned int gen6_gttadr_offset(struct
> drm_i915_private *i915)
>  static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 size)
>  {
>   struct drm_i915_private *i915 = ggtt->vm.i915;
> + struct intel_uncore *uncore = ggtt->vm.gt->uncore;
>   struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
>   phys_addr_t phys_addr;
>   u32 pte_flags;
>   int ret;
> 
>   GEM_WARN_ON(pci_resource_len(pdev, GEN4_GTTMMADR_BAR) !=
> gen6_gttmmadr_size(i915));
> - phys_addr = pci_resource_start(pdev, GEN4_GTTMMADR_BAR) +
> gen6_gttadr_offset(i915);
> + /*
> +  * Workaround: access via BAR can hang MTL, go directly to GSM.
> +  *
> +  * Normally this would not work but on MTL the system firmware
> +  * should have relaxed the access permissions sufficiently.
> +  */
> + if (IS_METEORLAKE(i915))
> + phys_addr = intel_uncore_read64(uncore, GEN12_GSMBASE) &
> GEN12_BDSM_MASK;
> + else
> + phys_addr = pci_resource_start(pdev, GEN4_GTTMMADR_BAR)
> + gen6_gttadr_offset(i915);
> 
>   if (needs_wc_ggtt_mapping(i915))
>   ggtt->gsm = ioremap_wc(phys_addr, size);
> --
> 2.41.0

✗ Fi.CI.CHECKPATCH: warning for perf: Fix perf_event_validate_size() lockdep splat

[Patchwork]

== Series Details ==

Series: perf: Fix perf_event_validate_size() lockdep splat
URL   : https://patchwork.freedesktop.org/series/127883/
State : warning

== Summary ==

Error: dim checkpatch failed
ae4af2d14505 perf: Fix perf_event_validate_size() lockdep splat
-:23: WARNING:BAD_FIXES_TAG: Please use correct Fixes: style 'Fixes: <12 chars 
of sha1> ("")' - ie: 'Fixes: 382c27f4ed28 ("perf: Fix 
perf_event_validate_size()")'
#23: 
Fixes: 382c27f4ed28f803 ("perf: Fix perf_event_validate_size()")

-:26: WARNING:BAD_REPORTED_BY_LINK: Reported-by: should be immediately followed 
by Closes: with a URL to the report
#26: 
Reported-by: Lucas De Marchi 
Reported-by: Pengfei Xu 

-:27: WARNING:BAD_REPORTED_BY_LINK: Reported-by: should be immediately followed 
by Closes: with a URL to the report
#27: 
Reported-by: Pengfei Xu 
Signed-off-by: Mark Rutland 

total: 0 errors, 3 warnings, 0 checks, 16 lines checked

✗ Fi.CI.BAT: failure for Revert "drm/i915/gt: Temporarily disable CPU caching into DMA for MTL" (rev2)

[Patchwork]

== Series Details ==

Series: Revert "drm/i915/gt: Temporarily disable CPU caching into DMA for MTL" 
(rev2)
URL   : https://patchwork.freedesktop.org/series/127763/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_14033 -> Patchwork_127763v2


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_127763v2 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_127763v2, please notify your bug team 
(i915-ci-in...@lists.freedesktop.org) 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_127763v2/index.html

Participating hosts (38 -> 36)
--

  Missing(2): bat-rpls-2 fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_suspend@basic-s2idle-without-i915:
- bat-atsm-1: [PASS][1] -> [WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/bat-atsm-1/igt@i915_susp...@basic-s2idle-without-i915.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127763v2/bat-atsm-1/igt@i915_susp...@basic-s2idle-without-i915.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@execlists:
- fi-bsw-n3050:   [PASS][3] -> [ABORT][4] ([i915#7911])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127763v2/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@hangcheck:
- fi-skl-guc: [PASS][5] -> [DMESG-FAIL][6] ([i915#9549])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127763v2/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [PASS][7] -> [ABORT][8] ([i915#8668])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14033/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127763v2/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html

  
  [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
  [i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668
  [i915#9549]: https://gitlab.freedesktop.org/drm/intel/issues/9549


Build changes
-

  * Linux: CI_DRM_14033 -> Patchwork_127763v2

  CI-20190529: 20190529
  CI_DRM_14033: e6580f88bbde08a04d0cb7bb591c38e7b9f0076d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7643: ced22f8bf4263ff395dc852c86b682e62a7a1c1b @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_127763v2: e6580f88bbde08a04d0cb7bb591c38e7b9f0076d @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

3c057e21e8ca Revert "drm/i915/gt: Temporarily disable CPU caching into DMA for 
MTL"

== Logs ==

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

✗ Fi.CI.BAT: failure for drm/mm: Allow CONFIG_DRM_MM_DEBUG with DRM=m

[Patchwork]

== Series Details ==

Series: drm/mm: Allow CONFIG_DRM_MM_DEBUG with DRM=m
URL   : https://patchwork.freedesktop.org/series/127871/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_14033 -> Patchwork_127871v1


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_127871v1 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_127871v1, please notify your bug team 
(i915-ci-in...@lists.freedesktop.org) 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_127871v1/index.html

Participating hosts (38 -> 16)
--

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

  Missing(22): fi-rkl-11600 fi-apl-guc fi-snb-2520m bat-rpls-3 fi-pnv-d510 
fi-bsw-n3050 bat-adlm-1 bat-dg2-9 fi-ilk-650 bat-adln-1 fi-ivb-3770 bat-rplp-1 
bat-dg2-11 fi-bsw-nick bat-dg1-7 bat-kbl-2 bat-adlp-9 bat-jsl-1 fi-tgl-1115g4 
fi-cfl-guc fi-kbl-x1275 bat-dg2-14 


Changes
---

  No changes found


Build changes
-

  * Linux: CI_DRM_14033 -> Patchwork_127871v1

  CI-20190529: 20190529
  CI_DRM_14033: e6580f88bbde08a04d0cb7bb591c38e7b9f0076d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7643: ced22f8bf4263ff395dc852c86b682e62a7a1c1b @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_127871v1: e6580f88bbde08a04d0cb7bb591c38e7b9f0076d @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

cfa4968c1902 drm/mm: Allow CONFIG_DRM_MM_DEBUG with DRM=m

== Logs ==

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

Re: [PATCH 5/7] drm/i915/display: Ignore only psr specific part of vsc sdp

[Rodrigo Vivi]

On Thu, Dec 14, 2023 at 01:48:36PM +0200, Jouni Högander wrote:
> Pipe config check is currently ignoring vsc sdp changes completely
> if psr is enabled. We want to ignore only PSR part of it as there
> might be changes in colorimetry data. Also read back vsc_sdp when psr is
> used.
> 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 9 ++---
>  drivers/gpu/drm/i915/display/intel_dp.c  | 4 
>  2 files changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index f1e58163277d..0faf84d3680a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4764,7 +4764,11 @@ static bool
>  intel_compare_dp_vsc_sdp(const struct drm_dp_vsc_sdp *a,
>const struct drm_dp_vsc_sdp *b)
>  {
> - return memcmp(a, b, sizeof(*a)) == 0;
> + return a->pixelformat == b->pixelformat &&
> + a->colorimetry == b->colorimetry &&
> + a->bpc == b->bpc &&
> + a->dynamic_range == b->dynamic_range &&
> + a->content_type == b->content_type;
>  }
>  
>  static bool
> @@ -5045,8 +5049,7 @@ intel_pipe_config_compare(const struct intel_crtc_state 
> *current_config,
>  } while (0)
>  
>  #define PIPE_CONF_CHECK_DP_VSC_SDP(name) do { \
> - if (!current_config->has_psr && !pipe_config->has_psr && \
> - !intel_compare_dp_vsc_sdp(_config->infoframes.name, \
> + if (!intel_compare_dp_vsc_sdp(_config->infoframes.name, \
> _config->infoframes.name)) { \
>   pipe_config_dp_vsc_sdp_mismatch(dev_priv, fastset, 
> __stringify(name), \
>   
> _config->infoframes.name, \
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 635790ec2fb7..b7e9b6eb6f66 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4425,10 +4425,6 @@ static void intel_read_dp_vsc_sdp(struct intel_encoder 
> *encoder,
>   struct dp_sdp sdp = {};
>   int ret;
>  
> - /* When PSR is enabled, VSC SDP is handled by PSR routine */
> - if (crtc_state->has_psr)
> - return;

I almost got confused by this one, but checking the patch 3 again,
it makes total sense.

Reviewed-by: Rodrigo Vivi 

> -
>   if ((crtc_state->infoframes.enable &
>intel_hdmi_infoframe_enable(type)) == 0)
>   return;
> -- 
> 2.34.1
> 

Re: [PATCH 7/7] drm/i915/display: Take care of VSC select field in video dip ctl register

[Rodrigo Vivi]

On Thu, Dec 14, 2023 at 01:48:38PM +0200, Jouni Högander wrote:
> We need to configure VSC Select field in video dip ctl if we want to have
> e.g. colorimetry date in our VSC SDP.
> 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_hdmi.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 39e4f5f7c817..eedef8121ff7 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -523,10 +523,12 @@ void hsw_write_infoframe(struct intel_encoder *encoder,
>  0);
>  
>   /* Wa_14013475917 */

For a moment I thought that your change in the logic below would bypass this 
w/a.
But then I read its description and notice that it is only about the bit 20, 
while
your new case below you set bit 26. So we should be good.

I even wonder if we shouldn't move this w/a below. let us to calculate the 
bits, but
then if wa condition val &= ~VIDEO_DIP_ENABLE_VSC_HSW;

> - if (IS_DISPLAY_VER(dev_priv, 13, 14) && crtc_state->has_psr && type == 
> DP_SDP_VSC)
> - return;
> + if (!(IS_DISPLAY_VER(dev_priv, 13, 14) && crtc_state->has_psr && type 
> == DP_SDP_VSC))
> + val |= hsw_infoframe_enable(type);
> +
> + if (type == DP_SDP_VSC)
> + val |= VSC_DIP_HW_DATA_SW_HEA;

for the part of need to set this bit 26 I confess that I'm not 100% sure.
What register this is in the spec?

but if someone else check these bits, I have nothing against this patch:

Acked-by: Rodrigo Vivi 

>  
> - val |= hsw_infoframe_enable(type);
>   intel_de_write(dev_priv, ctl_reg, val);
>   intel_de_posting_read(dev_priv, ctl_reg);
>  }
> -- 
> 2.34.1
> 

✓ Fi.CI.BAT: success for drm/i915: Eaerly ggtt pinning stuff

[Patchwork]

== Series Details ==

Series: drm/i915: Eaerly ggtt pinning stuff
URL   : https://patchwork.freedesktop.org/series/127870/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14030 -> Patchwork_127870v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (35 -> 37)
--

  Additional (3): bat-rpls-2 bat-kbl-2 bat-dg2-9 
  Missing(1): fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-nv12@pipe-d-dp-2:
- {bat-rpls-3}:   [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/bat-rpls-3/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-d-dp-2.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127870v1/bat-rpls-3/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-d-dp-2.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- bat-jsl-1:  [FAIL][3] ([i915#8293]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/bat-jsl-1/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127870v1/bat-jsl-1/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-rpls-2: NOTRUN -> [SKIP][5] ([i915#9318])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127870v1/bat-rpls-2/igt@debugfs_t...@basic-hwmon.html
- bat-jsl-1:  NOTRUN -> [SKIP][6] ([i915#9318])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127870v1/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html

  * igt@fbdev@info:
- bat-kbl-2:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1849])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127870v1/bat-kbl-2/igt@fb...@info.html

  * igt@gem_huc_copy@huc-copy:
- bat-jsl-1:  NOTRUN -> [SKIP][8] ([i915#2190])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127870v1/bat-jsl-1/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- bat-kbl-2:  NOTRUN -> [SKIP][9] ([fdo#109271]) +36 other tests 
skip
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127870v1/bat-kbl-2/igt@gem_lmem_swapp...@parallel-random-engines.html
- bat-jsl-1:  NOTRUN -> [SKIP][10] ([i915#4613]) +3 other tests skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127870v1/bat-jsl-1/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_lmem_swapping@verify-random:
- bat-mtlp-6: NOTRUN -> [SKIP][11] ([i915#4613]) +3 other tests skip
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127870v1/bat-mtlp-6/igt@gem_lmem_swapp...@verify-random.html

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

  * igt@gem_mmap_gtt@basic:
- bat-dg2-9:  NOTRUN -> [SKIP][13] ([i915#4077]) +2 other tests skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127870v1/bat-dg2-9/igt@gem_mmap_...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-dg2-9:  NOTRUN -> [SKIP][14] ([i915#4079]) +1 other test skip
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127870v1/bat-dg2-9/igt@gem_tiled_pread_basic.html
- bat-rpls-2: NOTRUN -> [SKIP][15] ([i915#3282])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127870v1/bat-rpls-2/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_rps@basic-api:
- bat-dg2-9:  NOTRUN -> [SKIP][16] ([i915#6621])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127870v1/bat-dg2-9/igt@i915_pm_...@basic-api.html
- bat-mtlp-6: NOTRUN -> [SKIP][17] ([i915#6621])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127870v1/bat-mtlp-6/igt@i915_pm_...@basic-api.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][18] -> [ABORT][19] ([i915#7911])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127870v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-mtlp-6: NOTRUN -> [SKIP][20] ([i915#6645])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127870v1/bat-mtlp-6/igt@i915_susp...@basic-s3-without-i915.html

  * 

Re: [PATCH 6/7] drm/i915/display: Read PSR configuration before VSC SDP

[Rodrigo Vivi]

On Thu, Dec 14, 2023 at 01:48:37PM +0200, Jouni Högander wrote:
> VSC SDP sending is taken care by PSR HW and it's not enabled in
> VIDEO_DIP_CTL when PSR is enabled. Readback of VSC SDP is depending on
> VSC_SDP being set in intel_crtc_state->infoframes.enabled. In case of PSR
> setting this flag is taken care by PSR code -> read back PSR configuration
> before reading VSC SDP otherwise we get pipeconfig mismatch error.
> 
> Signed-off-by: Jouni Högander 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 12a29363e5df..2746655bcb26 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3941,11 +3941,11 @@ static void intel_ddi_get_config(struct intel_encoder 
> *encoder,
>   if (DISPLAY_VER(dev_priv) >= 8)
>   bdw_get_trans_port_sync_config(pipe_config);
>  
> + intel_psr_get_config(encoder, pipe_config);
> +
>   intel_read_dp_sdp(encoder, pipe_config, 
> HDMI_PACKET_TYPE_GAMUT_METADATA);
>   intel_read_dp_sdp(encoder, pipe_config, DP_SDP_VSC);
>  
> - intel_psr_get_config(encoder, pipe_config);
> -
>   intel_audio_codec_get_config(encoder, pipe_config);
>  }
>  
> -- 
> 2.34.1
> 

Re: [PATCH 4/7] drm/i915/display: Fix vsc_sdp computation

[Rodrigo Vivi]

On Thu, Dec 14, 2023 at 01:48:35PM +0200, Jouni Högander wrote:
> Currently colorimetry data is not added for psr1 or non-psr case.
> Fix this by adding it as needed.
> 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 48 ++---
>  1 file changed, 19 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 3550cebb44f2..635790ec2fb7 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2628,36 +2628,26 @@ static void intel_dp_compute_vsc_sdp(struct intel_dp 
> *intel_dp,
>   crtc_state->infoframes.enable |= 
> intel_hdmi_infoframe_enable(DP_SDP_VSC);
>   vsc->sdp_type = DP_SDP_VSC;
>  
> - if (crtc_state->has_psr2) {
> - if (intel_dp->colorimetry_support &&
> - intel_dp_needs_vsc_sdp(crtc_state, conn_state)) {
> - /* [PSR2, +Colorimetry] */
> - intel_dp_compute_vsc_colorimetry(crtc_state, conn_state,
> -  vsc);
> - } else {
> - /*
> -  * [PSR2, -Colorimetry]

could we please spell this out like below...
I got confused for a while thinking that - was a typo or a hyphen, not a minus.
only after checking the table in spec and vsc->revision = 5 inside
intel_dp_compute_vsc_colorimetry then I understood that this is for
'PSR2 without colorimetry'.

with that changed or at least clarified:

Reviewed-by: Rodrigo Vivi 


> -  * Prepare VSC Header for SU as per eDP 1.4 spec, Table 
> 6-11
> -  * 3D stereo + PSR/PSR2 + Y-coordinate.
> -  */
> - vsc->revision = 0x4;
> - vsc->length = 0xe;
> - }
> + /* Needs colorimetry */
> + if (intel_dp_needs_vsc_sdp(crtc_state, conn_state)) {
> + intel_dp_compute_vsc_colorimetry(crtc_state, conn_state,
> +  vsc);
> + } else if (crtc_state->has_psr2) {
> + /*
> +  * [PSR2, -Colorimetry]
> +  * Prepare VSC Header for SU as per eDP 1.4 spec, Table 6-11
> +  * 3D stereo + PSR/PSR2 + Y-coordinate.
> +  */
> + vsc->revision = 0x4;
> + vsc->length = 0xe;
>   } else if (crtc_state->has_panel_replay) {
> - if (intel_dp->colorimetry_support &&
> - intel_dp_needs_vsc_sdp(crtc_state, conn_state)) {
> - /* [Panel Replay with colorimetry info] */
> - intel_dp_compute_vsc_colorimetry(crtc_state, conn_state,
> -  vsc);
> - } else {
> - /*
> -  * [Panel Replay without colorimetry info]
> -  * Prepare VSC Header for SU as per DP 2.0 spec, Table 
> 2-223
> -  * VSC SDP supporting 3D stereo + Panel Replay.
> -  */
> - vsc->revision = 0x6;
> - vsc->length = 0x10;
> - }
> + /*
> +  * [Panel Replay without colorimetry info]
> +  * Prepare VSC Header for SU as per DP 2.0 spec, Table 2-223
> +  * VSC SDP supporting 3D stereo + Panel Replay.
> +  */
> + vsc->revision = 0x6;
> + vsc->length = 0x10;
>   } else {
>   /*
>* [PSR1]
> -- 
> 2.34.1
> 

Re: [PATCH 3/7] drm/i915/display: Unify VSC SPD preparation

[Rodrigo Vivi]

On Thu, Dec 14, 2023 at 01:48:34PM +0200, Jouni Högander wrote:
> There is no specific reason to prepare VSC SDP for PSR case somehow
> differently. Unify PSR and non-PSR preparation.
> 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c  | 43 
>  drivers/gpu/drm/i915/display/intel_dp.h  |  7 
>  drivers/gpu/drm/i915/display/intel_psr.c |  6 
>  3 files changed, 6 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 08c48a58aa4d..3550cebb44f2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2616,28 +2616,17 @@ static void intel_dp_compute_vsc_sdp(struct intel_dp 
> *intel_dp,
>struct intel_crtc_state *crtc_state,
>const struct drm_connector_state 
> *conn_state)
>  {
> - struct drm_dp_vsc_sdp *vsc = _state->infoframes.vsc;
> + struct drm_dp_vsc_sdp *vsc;
>  
> - /* When a crtc state has PSR, VSC SDP will be handled by PSR routine */
> - if (crtc_state->has_psr)
> + if ((!intel_dp->colorimetry_support ||
> + !intel_dp_needs_vsc_sdp(crtc_state, conn_state)) &&
> + !crtc_state->has_psr)
>   return;
>  
> - if (!intel_dp->colorimetry_support ||
> - !intel_dp_needs_vsc_sdp(crtc_state, conn_state))
> - return;
> + vsc = _state->infoframes.vsc;
>  
>   crtc_state->infoframes.enable |= 
> intel_hdmi_infoframe_enable(DP_SDP_VSC);
>   vsc->sdp_type = DP_SDP_VSC;
> - intel_dp_compute_vsc_colorimetry(crtc_state, conn_state,
> -  _state->infoframes.vsc);
> -}
> -
> -void intel_dp_compute_psr_vsc_sdp(struct intel_dp *intel_dp,
> -   const struct intel_crtc_state *crtc_state,
> -   const struct drm_connector_state *conn_state,
> -   struct drm_dp_vsc_sdp *vsc)
> -{
> - vsc->sdp_type = DP_SDP_VSC;
>  
>   if (crtc_state->has_psr2) {

sorry for the delay here... yesterday I started wondering if we were
sure if we could reach this point in the unified flow, but after
checking the compute config path and seeing that this is only true
if has_psr is also true, then I'm comfortable with this good unification.

Reviewed-by: Rodrigo Vivi 

>   if (intel_dp->colorimetry_support &&
> @@ -4289,24 +4278,6 @@ static void intel_write_dp_sdp(struct intel_encoder 
> *encoder,
>   dig_port->write_infoframe(encoder, crtc_state, type, , len);
>  }
>  
> -void intel_write_dp_vsc_sdp(struct intel_encoder *encoder,
> - const struct intel_crtc_state *crtc_state,
> - const struct drm_dp_vsc_sdp *vsc)
> -{
> - struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - struct dp_sdp sdp = {};
> - ssize_t len;
> -
> - len = intel_dp_vsc_sdp_pack(vsc, , sizeof(sdp));
> -
> - if (drm_WARN_ON(_priv->drm, len < 0))
> - return;
> -
> - dig_port->write_infoframe(encoder, crtc_state, DP_SDP_VSC,
> - , len);
> -}
> -
>  void intel_dp_set_infoframes(struct intel_encoder *encoder,
>bool enable,
>const struct intel_crtc_state *crtc_state,
> @@ -4333,9 +4304,7 @@ void intel_dp_set_infoframes(struct intel_encoder 
> *encoder,
>   if (!enable)
>   return;
>  
> - /* When PSR is enabled, VSC SDP is handled by PSR routine */
> - if (!crtc_state->has_psr)
> - intel_write_dp_sdp(encoder, crtc_state, DP_SDP_VSC);
> + intel_write_dp_sdp(encoder, crtc_state, DP_SDP_VSC);
>  
>   intel_write_dp_sdp(encoder, crtc_state, 
> HDMI_PACKET_TYPE_GAMUT_METADATA);
>  }
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index 05db46b111f2..b911706d2e95 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -109,13 +109,6 @@ int intel_dp_max_data_rate(int max_link_rate, int 
> max_lanes);
>  bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp);
>  bool intel_dp_needs_vsc_sdp(const struct intel_crtc_state *crtc_state,
>   const struct drm_connector_state *conn_state);
> -void intel_dp_compute_psr_vsc_sdp(struct intel_dp *intel_dp,
> -   const struct intel_crtc_state *crtc_state,
> -   const struct drm_connector_state *conn_state,
> -   struct drm_dp_vsc_sdp *vsc);
> -void intel_write_dp_vsc_sdp(struct intel_encoder *encoder,
> - const struct intel_crtc_state *crtc_state,
> - const struct drm_dp_vsc_sdp *vsc);
>  void 

✗ Fi.CI.SPARSE: warning for drm/i915: Eaerly ggtt pinning stuff

[Patchwork]

== Series Details ==

Series: drm/i915: Eaerly ggtt pinning stuff
URL   : https://patchwork.freedesktop.org/series/127870/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:155:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:155:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:155:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:155:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:173:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:173:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:175:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:175:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:179:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:179:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:181:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:181:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:181:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:181:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:185:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:185:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:187:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:187:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:191:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:191:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:194:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:194:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:194:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:194:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:236:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:236:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:238:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:238:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced 
symbol 'old'

✗ Fi.CI.CHECKPATCH: warning for drm/i915: Eaerly ggtt pinning stuff

[Patchwork]

== Series Details ==

Series: drm/i915: Eaerly ggtt pinning stuff
URL   : https://patchwork.freedesktop.org/series/127870/
State : warning

== Summary ==

Error: dim checkpatch failed
bb26a9048f2e drm/i915/hdcp: Do intel_hdcp_component_init() much later during 
init
-:14: WARNING:REPEATED_WORD: Possible repeated word: 'the'
#14: 
ggtt PTEs that need to be preserved until the the BIOS fb takover

total: 0 errors, 1 warnings, 0 checks, 21 lines checked
442e16c2b7f9 drm/i915/hdcp: Pin the hdcp gsc message high in ggtt
3ad12ae18ce8 drm/i915: Pin error_capture to high end of mappable
-:14: WARNING:REPEATED_WORD: Possible repeated word: 'then'
#14: 
displays connected at boot). We are then then left with a

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

Re: [PATCH topic/core-for-CI] perf: Fix perf_event_validate_size() lockdep splat

[Rodrigo Vivi]

On Fri, Dec 15, 2023 at 08:22:17AM -0800, Lucas De Marchi wrote:
> From: Mark Rutland 
> 
> When lockdep is enabled, the for_each_sibling_event(sibling, event)
> macro checks that event->ctx->mutex is held. When creating a new group
> leader event, we call perf_event_validate_size() on a partially
> initialized event where event->ctx is NULL, and so when
> for_each_sibling_event() attempts to check event->ctx->mutex, we get a
> splat, as reported by Lucas De Marchi:
> 
>   WARNING: CPU: 8 PID: 1471 at kernel/events/core.c:1950 
> __do_sys_perf_event_open+0xf37/0x1080
> 
> This only happens for a new event which is its own group_leader, and in
> this case there cannot be any sibling events. Thus it's safe to skip the
> check for siblings, which avoids having to make invasive and ugly
> changes to for_each_sibling_event().
> 
> Avoid the splat by bailing out early when the new event is its own
> group_leader.
> 
> Fixes: 382c27f4ed28f803 ("perf: Fix perf_event_validate_size()")
> Closes: 
> https://lore.kernel.org/lkml/20231214000620.3081018-1-lucas.demar...@intel.com/
> Closes: https://lore.kernel.org/lkml/zxpm6gq%2fd59jg...@xpf.sh.intel.com/
> Reported-by: Lucas De Marchi 
> Reported-by: Pengfei Xu 
> Signed-off-by: Mark Rutland 
> Signed-off-by: Peter Zijlstra (Intel) 
> Link: https://lkml.kernel.org/r/20231215112450.3972309-1-mark.rutl...@arm.com
> [ cherry pick from tip/urgent heading to 6.7-rc6 ]
> Signed-off-by: Lucas De Marchi 

Acked-by: Rodrigo Vivi 

> ---
>  kernel/events/core.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index acfc5a569818..a64165af45c1 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -1947,6 +1947,16 @@ static bool perf_event_validate_size(struct perf_event 
> *event)
>  group_leader->nr_siblings + 1) > 16*1024)
>   return false;
>  
> + /*
> +  * When creating a new group leader, group_leader->ctx is initialized
> +  * after the size has been validated, but we cannot safely use
> +  * for_each_sibling_event() until group_leader->ctx is set. A new group
> +  * leader cannot have any siblings yet, so we can safely skip checking
> +  * the non-existent siblings.
> +  */
> + if (event == group_leader)
> + return true;
> +
>   for_each_sibling_event(sibling, group_leader) {
>   if (__perf_event_read_size(sibling->attr.read_format,
>  group_leader->nr_siblings + 1) > 
> 16*1024)
> -- 
> 2.40.1
> 

[PATCH topic/core-for-CI] perf: Fix perf_event_validate_size() lockdep splat

[Lucas De Marchi]

From: Mark Rutland 

When lockdep is enabled, the for_each_sibling_event(sibling, event)
macro checks that event->ctx->mutex is held. When creating a new group
leader event, we call perf_event_validate_size() on a partially
initialized event where event->ctx is NULL, and so when
for_each_sibling_event() attempts to check event->ctx->mutex, we get a
splat, as reported by Lucas De Marchi:

  WARNING: CPU: 8 PID: 1471 at kernel/events/core.c:1950 
__do_sys_perf_event_open+0xf37/0x1080

This only happens for a new event which is its own group_leader, and in
this case there cannot be any sibling events. Thus it's safe to skip the
check for siblings, which avoids having to make invasive and ugly
changes to for_each_sibling_event().

Avoid the splat by bailing out early when the new event is its own
group_leader.

Fixes: 382c27f4ed28f803 ("perf: Fix perf_event_validate_size()")
Closes: 
https://lore.kernel.org/lkml/20231214000620.3081018-1-lucas.demar...@intel.com/
Closes: https://lore.kernel.org/lkml/zxpm6gq%2fd59jg...@xpf.sh.intel.com/
Reported-by: Lucas De Marchi 
Reported-by: Pengfei Xu 
Signed-off-by: Mark Rutland 
Signed-off-by: Peter Zijlstra (Intel) 
Link: https://lkml.kernel.org/r/20231215112450.3972309-1-mark.rutl...@arm.com
[ cherry pick from tip/urgent heading to 6.7-rc6 ]
Signed-off-by: Lucas De Marchi 
---
 kernel/events/core.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index acfc5a569818..a64165af45c1 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -1947,6 +1947,16 @@ static bool perf_event_validate_size(struct perf_event 
*event)
   group_leader->nr_siblings + 1) > 16*1024)
return false;
 
+   /*
+* When creating a new group leader, group_leader->ctx is initialized
+* after the size has been validated, but we cannot safely use
+* for_each_sibling_event() until group_leader->ctx is set. A new group
+* leader cannot have any siblings yet, so we can safely skip checking
+* the non-existent siblings.
+*/
+   if (event == group_leader)
+   return true;
+
for_each_sibling_event(sibling, group_leader) {
if (__perf_event_read_size(sibling->attr.read_format,
   group_leader->nr_siblings + 1) > 
16*1024)
-- 
2.40.1

✗ Fi.CI.BAT: failure for drm/i915: (stolen) memory region related fixes (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: (stolen) memory region related fixes (rev3)
URL   : https://patchwork.freedesktop.org/series/127721/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_14030 -> Patchwork_127721v3


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_127721v3 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_127721v3, please notify your bug team 
(i915-ci-in...@lists.freedesktop.org) 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_127721v3/index.html

Participating hosts (35 -> 36)
--

  Additional (2): bat-dg2-8 bat-dg2-9 
  Missing(1): fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@load:
- bat-dg2-9:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127721v3/bat-dg2-9/igt@i915_module_l...@load.html
- bat-dg2-8:  NOTRUN -> [INCOMPLETE][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127721v3/bat-dg2-8/igt@i915_module_l...@load.html

  
 Suppressed 

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

  * igt@i915_module_load@load:
- {bat-dg2-14}:   [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/bat-dg2-14/igt@i915_module_l...@load.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127721v3/bat-dg2-14/igt@i915_module_l...@load.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- bat-jsl-1:  [FAIL][5] ([i915#8293]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14030/bat-jsl-1/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127721v3/bat-jsl-1/boot.html

  

### IGT changes ###

 Issues hit 

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

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-jsl-1:  NOTRUN -> [INCOMPLETE][8] ([i915#9883])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127721v3/bat-jsl-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_huc_copy@huc-copy:
- bat-jsl-1:  NOTRUN -> [SKIP][9] ([i915#2190])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127721v3/bat-jsl-1/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- bat-jsl-1:  NOTRUN -> [SKIP][10] ([i915#4613]) +3 other tests skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127721v3/bat-jsl-1/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_lmem_swapping@verify-random:
- bat-mtlp-6: NOTRUN -> [SKIP][11] ([i915#4613]) +3 other tests skip
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127721v3/bat-mtlp-6/igt@gem_lmem_swapp...@verify-random.html

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

  * igt@i915_suspend@basic-s3-without-i915:
- bat-mtlp-6: NOTRUN -> [SKIP][13] ([i915#6645])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127721v3/bat-mtlp-6/igt@i915_susp...@basic-s3-without-i915.html
- bat-jsl-1:  NOTRUN -> [FAIL][14] ([fdo#103375])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127721v3/bat-jsl-1/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_addfb_basic@addfb25-x-tiled-legacy:
- bat-mtlp-6: NOTRUN -> [SKIP][15] ([i915#4212] / [i915#9792]) +8 
other tests skip
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127721v3/bat-mtlp-6/igt@kms_addfb_ba...@addfb25-x-tiled-legacy.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- bat-mtlp-6: NOTRUN -> [SKIP][16] ([i915#5190] / [i915#9792])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127721v3/bat-mtlp-6/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-jsl-1:  NOTRUN -> [SKIP][17] ([i915#4103]) +1 other test skip
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127721v3/bat-jsl-1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
 

✗ Fi.CI.SPARSE: warning for drm/i915: (stolen) memory region related fixes (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: (stolen) memory region related fixes (rev3)
URL   : https://patchwork.freedesktop.org/series/127721/
State : warning

== Summary ==

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

✗ Fi.CI.CHECKPATCH: warning for drm/i915: (stolen) memory region related fixes (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: (stolen) memory region related fixes (rev3)
URL   : https://patchwork.freedesktop.org/series/127721/
State : warning

== Summary ==

Error: dim checkpatch failed
e7cbf4e3592e drm/i915: Use struct resource for memory region IO as well
-:387: WARNING:LONG_LINE: line length of 105 exceeds 100 columns
#387: FILE: drivers/gpu/drm/i915/intel_region_ttm.c:227:
+   if (WARN_ON(overflows_type(resource_size(>io) >> 
PAGE_SHIFT, place.lpfn))) {

total: 0 errors, 1 warnings, 0 checks, 281 lines checked
df163a6b67b8 drm/i915: Print memory region info during probe
8540d04636d8 drm/i915: Remove ad-hoc lmem/stolen debugs
637857991a67 drm/i915: Bypass LMEMBAR/GTTMMADR for MTL stolen memory access
2649d131b38a drm/i915: Disable the "binder"
749426fcecc3 drm/i915: Rename the DSM/GSM registers
1f69f5e7e84f drm/i915: Fix PTE decode during initial plane readout
b3638bff7e4d drm/i915: Fix region start during initial plane readout
ab68b29bbf82 drm/i915: Fix MTL initial plane readout
272c9d024ff4 drm/i915: s/phys_base/dma_addr/
0ed9217df0c0 drm/i915: Split the smem and lmem plane readout apart
2d6d2559660c drm/i915: Simplify intel_initial_plane_config() calling convention
cdeb9cc51bbc drm/i915/fbdev: Fix smem_start for LMEMBAR stolen objects
06c1a2465e13 drm/i915: Tweak BIOS fb reuse check
644c9f50b0ba drm/i915: Try to relocate the BIOS fb to the start of ggtt
-:100: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#100: FILE: drivers/gpu/drm/i915/display/i9xx_plane.h:51:
 }
+static inline bool i9xx_fixup_initial_plane_config(struct intel_crtc *crtc,

-:101: WARNING:LONG_LINE: line length of 105 exceeds 100 columns
#101: FILE: drivers/gpu/drm/i915/display/i9xx_plane.h:52:
+  const struct 
intel_initial_plane_config *plane_config)

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

RE: [PATCH] drm/i915/display: C20 clock state verification

[Jani Nikula]

On Fri, 15 Dec 2023, "Kahola, Mika"  wrote:
>> -Original Message-
>> From: Deak, Imre 
>> Sent: Friday, December 15, 2023 11:02 AM
>> To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
>> Subject: Re: [PATCH] drm/i915/display: C20 clock state verification
>> 
>> On Fri, Dec 15, 2023 at 10:53:36AM +0200, Imre Deak wrote:
>> > On Fri, Dec 15, 2023 at 10:00:57AM +0200, Mika Kahola wrote:
>> > > Add clock state verification for C20. Since we are usign either A or
>> > > B contexts, which are selected based on clock rate, we first need to
>> > > calculate hw clock and use that clock to select which context we are
>> > > using.
>> >
>> > Could the description be clearer that the patch _fixes_ the context
>> > selection? (Also the subject line should always say _what_ the patch
>> > does.)
> OK, should I add the fixes tag as well? I will reword the commit message to 
> better describe what's going on in this patch.
>
>> >
>> > >
>> > > Signed-off-by: Mika Kahola 
>> > > ---
>> > >  drivers/gpu/drm/i915/display/intel_cx0_phy.c | 8 +++-
>> > >  1 file changed, 7 insertions(+), 1 deletion(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>> > > b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>> > > index 775c1c4a8978..6757e9f941e4 100644
>> > > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>> > > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>> > > @@ -3079,8 +3079,9 @@ static void intel_c20pll_state_verify(const struct 
>> > > intel_crtc_state *state,
>> > >  const struct intel_c20pll_state *mpll_sw_state = 
>> > > >cx0pll_state.c20;
>> > >  bool use_mplla;
>> > >  int i;
>> > > +int hw_clock = intel_c20pll_calc_port_clock(encoder,
>> > > +mpll_hw_state);
>> > >
>> > > -use_mplla = intel_c20_use_mplla(mpll_hw_state->clock);
>> > > +use_mplla = intel_c20_use_mplla(hw_clock);
>> >
>> > It's mpll_hw_state->tx[0] C20_PHY_USE_MPLLB which tells the HW which
>> > context to use, so I think it's better to use the same condition here.
>
> Maybe I will ditch the use_mplla completely and go directly with
>
> if (mpll_hw_state->tx]0] & C20_PHY_USE_MPLLB) { .. }
>
> instead?

You should first verify that the hw and sw states for use_mplla agree.

If they don't, it doesn't matter which one you use.

BR,
Jani.


>
>> 
>> You could also add a check intel_c20_use_mplla(clock) matches the above flag.
>> 
>> >
>> > >  if (use_mplla) {
>> > >  for (i = 0; i < ARRAY_SIZE(mpll_sw_state->mplla); i++) {
>> > >  I915_STATE_WARN(i915, mpll_hw_state->mplla[i] !=
>> > > mpll_sw_state->mplla[i], @@ -3110,6 +3111,11 @@ static void 
>> > > intel_c20pll_state_verify(const struct intel_crtc_state *state,
>> > >  crtc->base.base.id, crtc->base.name, i,
>> > >  mpll_sw_state->cmn[i], 
>> > > mpll_hw_state->cmn[i]);
>> > >  }
>> > > +
>> > > +I915_STATE_WARN(i915, hw_clock != mpll_sw_state->clock,
>> > > +"[CRTC:%d:%s] mismatch in C20: Register CLOCK 
>> > > (expected %d, found %d)",
>> > > +crtc->base.base.id, crtc->base.name,
>> > > +mpll_sw_state->clock, hw_clock);
>> >
>> > I think the intel_crtc_state::port_clock SW/HW state verification is
>> > equivalent to the above, but it's good to verify it here as well. I
>> > would store hw_clock to mpll_hw_state->clock in
>> > intel_c20pll_readout_hw_state() though.
> Well, clock is part of pll structure anyway, so it might as well be checked 
> here too.
>
> I will store hw clock too in intel_c20pll_readout_hw_state()
>
> Thanks!
> Mika  
>
>> >
>> > >  }
>> > >
>> > >  void intel_cx0pll_state_verify(struct intel_atomic_state *state,
>> > > --
>> > > 2.34.1
>> > >

-- 
Jani Nikula, Intel

RE: [PATCH] drm/i915/display: C20 clock state verification

[Kahola, Mika]

> -Original Message-
> From: Deak, Imre 
> Sent: Friday, December 15, 2023 11:02 AM
> To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/i915/display: C20 clock state verification
> 
> On Fri, Dec 15, 2023 at 10:53:36AM +0200, Imre Deak wrote:
> > On Fri, Dec 15, 2023 at 10:00:57AM +0200, Mika Kahola wrote:
> > > Add clock state verification for C20. Since we are usign either A or
> > > B contexts, which are selected based on clock rate, we first need to
> > > calculate hw clock and use that clock to select which context we are
> > > using.
> >
> > Could the description be clearer that the patch _fixes_ the context
> > selection? (Also the subject line should always say _what_ the patch
> > does.)
OK, should I add the fixes tag as well? I will reword the commit message to 
better describe what's going on in this patch.

> >
> > >
> > > Signed-off-by: Mika Kahola 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_cx0_phy.c | 8 +++-
> > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > index 775c1c4a8978..6757e9f941e4 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > @@ -3079,8 +3079,9 @@ static void intel_c20pll_state_verify(const struct 
> > > intel_crtc_state *state,
> > >   const struct intel_c20pll_state *mpll_sw_state = 
> > > >cx0pll_state.c20;
> > >   bool use_mplla;
> > >   int i;
> > > + int hw_clock = intel_c20pll_calc_port_clock(encoder,
> > > +mpll_hw_state);
> > >
> > > - use_mplla = intel_c20_use_mplla(mpll_hw_state->clock);
> > > + use_mplla = intel_c20_use_mplla(hw_clock);
> >
> > It's mpll_hw_state->tx[0] C20_PHY_USE_MPLLB which tells the HW which
> > context to use, so I think it's better to use the same condition here.

Maybe I will ditch the use_mplla completely and go directly with

if (mpll_hw_state->tx]0] & C20_PHY_USE_MPLLB) { .. }

instead?

> 
> You could also add a check intel_c20_use_mplla(clock) matches the above flag.
> 
> >
> > >   if (use_mplla) {
> > >   for (i = 0; i < ARRAY_SIZE(mpll_sw_state->mplla); i++) {
> > >   I915_STATE_WARN(i915, mpll_hw_state->mplla[i] !=
> > > mpll_sw_state->mplla[i], @@ -3110,6 +3111,11 @@ static void 
> > > intel_c20pll_state_verify(const struct intel_crtc_state *state,
> > >   crtc->base.base.id, crtc->base.name, i,
> > >   mpll_sw_state->cmn[i], mpll_hw_state->cmn[i]);
> > >   }
> > > +
> > > + I915_STATE_WARN(i915, hw_clock != mpll_sw_state->clock,
> > > + "[CRTC:%d:%s] mismatch in C20: Register CLOCK (expected 
> > > %d, found %d)",
> > > + crtc->base.base.id, crtc->base.name,
> > > + mpll_sw_state->clock, hw_clock);
> >
> > I think the intel_crtc_state::port_clock SW/HW state verification is
> > equivalent to the above, but it's good to verify it here as well. I
> > would store hw_clock to mpll_hw_state->clock in
> > intel_c20pll_readout_hw_state() though.
Well, clock is part of pll structure anyway, so it might as well be checked 
here too.

I will store hw clock too in intel_c20pll_readout_hw_state()

Thanks!
Mika  

> >
> > >  }
> > >
> > >  void intel_cx0pll_state_verify(struct intel_atomic_state *state,
> > > --
> > > 2.34.1
> > >

Re: [PATCH v2 06/15] drm/i915: Rename the DSM/GSM registers

[Andrzej Hajda]

On 15.12.2023 11:59, Ville Syrjala wrote:

From: Ville Syrjälä 

0x108100 and 0x1080c0 have been around since snb. Rename the
defines appropriately.

Cc: Paz Zcharya 
Signed-off-by: Ville Syrjälä 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej


---
  drivers/gpu/drm/i915/gem/i915_gem_stolen.c  | 4 ++--
  drivers/gpu/drm/i915/gt/intel_ggtt.c| 2 +-
  drivers/gpu/drm/i915/gt/intel_region_lmem.c | 2 +-
  drivers/gpu/drm/i915/i915_reg.h | 7 ---
  4 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 252fe5cd6ede..6185a5f73a48 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -935,7 +935,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, 
u16 type,
GEM_BUG_ON((dsm_base + dsm_size) > lmem_size);
} else {
/* Use DSM base address instead for stolen memory */
-   dsm_base = intel_uncore_read64(uncore, GEN12_DSMBASE) & 
GEN12_BDSM_MASK;
+   dsm_base = intel_uncore_read64(uncore, GEN6_DSMBASE) & 
GEN11_BDSM_MASK;
if (WARN_ON(lmem_size < dsm_base))
return ERR_PTR(-ENODEV);
dsm_size = ALIGN_DOWN(lmem_size - dsm_base, SZ_1M);
@@ -948,7 +948,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, 
u16 type,
 * Normally this would not work but on MTL the system firmware
 * should have relaxed the access permissions sufficiently.
 */
-   io_start = intel_uncore_read64(uncore, GEN12_DSMBASE) & 
GEN12_BDSM_MASK;
+   io_start = intel_uncore_read64(uncore, GEN6_DSMBASE) & 
GEN11_BDSM_MASK;
io_size = dsm_size;
} else if (pci_resource_len(pdev, GEN12_LMEM_BAR) < lmem_size) {
io_start = 0;
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index ab71d74ec426..05c5525e7e2d 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -1167,7 +1167,7 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 
size)
 * should have relaxed the access permissions sufficiently.
 */
if (IS_METEORLAKE(i915))
-   phys_addr = intel_uncore_read64(uncore, GEN12_GSMBASE) & 
GEN12_BDSM_MASK;
+   phys_addr = intel_uncore_read64(uncore, GEN6_GSMBASE) & 
GEN11_BDSM_MASK;
else
phys_addr = pci_resource_start(pdev, GEN4_GTTMMADR_BAR) + 
gen6_gttadr_offset(i915);
  
diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c b/drivers/gpu/drm/i915/gt/intel_region_lmem.c

index af357089da6e..51bb27e10a4f 100644
--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
@@ -240,7 +240,7 @@ static struct intel_memory_region *setup_lmem(struct 
intel_gt *gt)
lmem_size -= tile_stolen;
} else {
/* Stolen starts from GSMBASE without CCS */
-   lmem_size = intel_uncore_read64(>uncore, GEN12_GSMBASE);
+   lmem_size = intel_uncore_read64(>uncore, GEN6_GSMBASE);
}
  
  	i915_resize_lmem_bar(i915, lmem_size);

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 27dc903f0553..b54d62952a53 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6314,9 +6314,10 @@ enum skl_power_gate {
  #define   GMS_MASKREG_GENMASK(15, 8)
  #define   GGMS_MASK   REG_GENMASK(7, 6)
  
-#define GEN12_GSMBASE			_MMIO(0x108100)

-#define GEN12_DSMBASE  _MMIO(0x1080C0)
-#define   GEN12_BDSM_MASK  REG_GENMASK64(63, 20)
+#define GEN6_GSMBASE   _MMIO(0x108100)
+#define GEN6_DSMBASE   _MMIO(0x1080C0)
+#define   GEN6_BDSM_MASK   REG_GENMASK64(31, 20)
+#define   GEN11_BDSM_MASK  REG_GENMASK64(63, 20)
  
  #define XEHP_CLOCK_GATE_DIS		_MMIO(0x101014)

  #define   SGSI_SIDECLK_DISREG_BIT(17)

✗ Fi.CI.BAT: failure for drm/i915/hdcp: Fail Repeater authentication if Type1 device not present (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/hdcp: Fail Repeater authentication if Type1 device not present 
(rev4)
URL   : https://patchwork.freedesktop.org/series/127414/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_14027 -> Patchwork_127414v4


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_127414v4 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_127414v4, please notify your bug team 
(i915-ci-in...@lists.freedesktop.org) 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_127414v4/index.html

Participating hosts (37 -> 17)
--

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

  Missing(20): fi-apl-guc fi-snb-2520m fi-skl-6600u fi-bsw-n3050 fi-ilk-650 
fi-elk-e7500 bat-jsl-3 bat-dg2-11 bat-kbl-2 bat-adlp-9 fi-cfl-8700k 
fi-glk-j4005 bat-jsl-1 bat-mtlp-6 fi-tgl-1115g4 fi-cfl-guc fi-kbl-guc 
fi-kbl-x1275 bat-dg2-14 bat-dg2-13 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@coherency:
- bat-adlm-1: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/bat-adlm-1/igt@i915_selftest@l...@coherency.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127414v4/bat-adlm-1/igt@i915_selftest@l...@coherency.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_pm_rpm@basic-rte:
- bat-rpls-2: [PASS][3] -> [ABORT][4] ([i915#8668])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/bat-rpls-2/igt@kms_pm_...@basic-rte.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127414v4/bat-rpls-2/igt@kms_pm_...@basic-rte.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- {bat-rpls-3}:   [DMESG-WARN][5] ([i915#5591]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/bat-rpls-3/igt@i915_selftest@l...@hangcheck.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127414v4/bat-rpls-3/igt@i915_selftest@l...@hangcheck.html

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

  [i915#5591]: https://gitlab.freedesktop.org/drm/intel/issues/5591
  [i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668


Build changes
-

  * Linux: CI_DRM_14027 -> Patchwork_127414v4

  CI-20190529: 20190529
  CI_DRM_14027: 961ef418705ac5808345e883acd91f8ce167e00b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7643: ced22f8bf4263ff395dc852c86b682e62a7a1c1b @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_127414v4: 961ef418705ac5808345e883acd91f8ce167e00b @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

378f4e3febca drm/i915/hdcp: Fail Repeater authentication if Type1 device not 
present

== Logs ==

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

✓ Fi.CI.BAT: success for drm/i915/display: C20 clock state verification

[Patchwork]

== Series Details ==

Series: drm/i915/display: C20 clock state verification
URL   : https://patchwork.freedesktop.org/series/127858/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14027 -> Patchwork_127858v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (37 -> 36)
--

  Additional (1): bat-adlp-11 
  Missing(2): fi-snb-2520m fi-pnv-d510 

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- bat-adlp-11:NOTRUN -> [FAIL][1] ([i915#8293])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127858v1/bat-adlp-11/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][2] -> [ABORT][3] ([i915#7911])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127858v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@workarounds:
- bat-adlm-1: [PASS][4] -> [INCOMPLETE][5] ([i915#9413])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/bat-adlm-1/igt@i915_selftest@l...@workarounds.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127858v1/bat-adlm-1/igt@i915_selftest@l...@workarounds.html

  * igt@kms_pm_rpm@basic-rte:
- bat-rpls-2: [PASS][6] -> [ABORT][7] ([i915#8668])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14027/bat-rpls-2/igt@kms_pm_...@basic-rte.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127858v1/bat-rpls-2/igt@kms_pm_...@basic-rte.html

  
  [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
  [i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293
  [i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668
  [i915#9413]: https://gitlab.freedesktop.org/drm/intel/issues/9413


Build changes
-

  * Linux: CI_DRM_14027 -> Patchwork_127858v1

  CI-20190529: 20190529
  CI_DRM_14027: 961ef418705ac5808345e883acd91f8ce167e00b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7643: ced22f8bf4263ff395dc852c86b682e62a7a1c1b @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_127858v1: 961ef418705ac5808345e883acd91f8ce167e00b @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

80be4c9afed8 drm/i915/display: C20 clock state verification

== Logs ==

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

[PULL] drm-intel-gt-next

[Joonas Lahtinen]

Hi Dave & Sima,

Final drm-intel-gt-next PR for v6.8.

Elimination of kmap_atomic() from the driver to allow kernel wide
cleanup. One new DG2 W/A and static checker/spelling fixes.

Best Regards,
Joonas

***

drm-intel-gt-next-2023-12-15:

Driver Changes:

- Eliminate use of kmap_atomic() in i915 (Zhao)
- Add Wa_14019877138 for DG2 (Haridhar)

- Static checker and spelling fixes (Colin, Karthik, Randy)
-

The following changes since commit be5bcc4be9d9d3ae294072441a66fe39b74e5bba:

  drm/i915/guc: Create the guc_to_i915() wrapper (2023-12-08 12:31:01 +0100)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2023-12-15

for you to fetch changes up to 31accc37eaee98a90b25809ed58c6ee4956ab642:

  drm/i915: Use kmap_local_page() in gem/i915_gem_execbuffer.c (2023-12-15 
09:34:31 +)


Driver Changes:

- Eliminate use of kmap_atomic() in i915 (Zhao)
- Add Wa_14019877138 for DG2 (Haridhar)

- Static checker and spelling fixes (Colin, Karthik, Randy)
-


Colin Ian King (1):
  drm/i915/selftests: Fix spelling mistake "initialiased" -> "initialised"

Haridhar Kalvala (1):
  drm/i915: Add Wa_14019877138

Karthik Poosa (1):
  drm/i915/hwmon: Fix static analysis tool reported issues

Randy Dunlap (1):
  drm/i915/uapi: fix typos/spellos and punctuation

Zhao Liu (9):
  drm/i915: Use kmap_local_page() in gem/i915_gem_object.c
  drm/i915: Use memcpy_[from/to]_page() in gem/i915_gem_pyhs.c
  drm/i915: Use kmap_local_page() in gem/i915_gem_shmem.c
  drm/i915: Use kmap_local_page() in gem/selftests/huge_pages.c
  drm/i915: Use kmap_local_page() in gem/selftests/i915_gem_coherency.c
  drm/i915: Use kmap_local_page() in gem/selftests/i915_gem_context.c
  drm/i915: Use memcpy_from_page() in gt/uc/intel_uc_fw.c
  drm/i915: Use kmap_local_page() in i915_cmd_parser.c
  drm/i915: Use kmap_local_page() in gem/i915_gem_execbuffer.c

 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c  | 10 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.c  |  8 +++-
 drivers/gpu/drm/i915/gem/i915_gem_phys.c| 10 ++
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c   |  6 --
 drivers/gpu/drm/i915/gem/selftests/huge_pages.c |  6 +++---
 drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c | 12 
 drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c   |  8 
 drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c|  2 +-
 drivers/gpu/drm/i915/gt/intel_gt_regs.h |  3 +++
 drivers/gpu/drm/i915/gt/intel_workarounds.c |  3 +++
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c|  5 +
 drivers/gpu/drm/i915/i915_cmd_parser.c  |  4 ++--
 drivers/gpu/drm/i915/i915_hwmon.c   |  4 ++--
 include/uapi/drm/i915_drm.h | 12 ++--
 14 files changed, 43 insertions(+), 50 deletions(-)

Re: [PATCH] drm/mm: Allow CONFIG_DRM_MM_DEBUG with DRM=m

[Javier Martinez Canillas]

Ville Syrjala  writes:

Hello Ville,

> From: Ville Syrjälä 
>
> The original rationale for
> commit cd456f8d06d2 ("drm: Restrict stackdepot usage to builtin drm.ko")
> was that depot_save_stack() (which is what we used back then)
> wasn't exported. stack_depot_save() (which is what we use now) is
> exported however, so relax the dependency allow CONFIG_DRM_MM_DEBUG
> with DRM=m.
>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 31cfe2c2a2af..4b8b8f8a0e72 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -42,7 +42,7 @@ config DRM_MIPI_DSI
>  config DRM_DEBUG_MM
>   bool "Insert extra checks and debug info into the DRM range managers"
>   default n
> - depends on DRM=y
> + depends on DRM
>   depends on STACKTRACE_SUPPORT
>   select STACKDEPOT
>   help
> -- 

Acked-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [PATCH] drm/i915: Reject async flips with bigjoiner

[Ville Syrjälä]

On Wed, Dec 13, 2023 at 08:36:49PM +0200, Lisovskiy, Stanislav wrote:
> On Mon, Dec 11, 2023 at 10:11:34AM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Currently async flips are busted when bigjoiner is in use.
> > As a short term fix simply reject async flips in that case.
> > 
> > Cc: sta...@vger.kernel.org
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9769
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c | 11 +++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index d955957b7d18..61053c19f4cc 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -5926,6 +5926,17 @@ static int intel_async_flip_check_uapi(struct 
> > intel_atomic_state *state,
> > return -EINVAL;
> > }
> >  
> > +   /*
> > +* FIXME: Bigjoiner+async flip is busted currently.
> > +* Remove this check once the issues are fixed.
> > +*/
> > +   if (new_crtc_state->bigjoiner_pipes) {
> > +   drm_dbg_kms(>drm,
> > +   "[CRTC:%d:%s] async flip disallowed with 
> > bigjoiner\n",
> > +   crtc->base.base.id, crtc->base.name);
> > +   return -EINVAL;
> > +   }
> > +
> 
> Was recently wondering, whether should we add some kind of helper
> func for that check to look more readable, i.e instead of just
> checking if crtc_state->bigjoiner_pipes != 0, call smth like
> is_bigjoiner_used(new_crtc_state)..

I suppose we could have something like that. We do have something
along those lines for eg. port sync. The difference being that
port sync has a bit more state than a single bitmask, so it's
more useful there.

> 
> Reviewed-by: Stanislav Lisovskiy 
>

Thanks.

> > for_each_oldnew_intel_plane_in_state(state, plane, old_plane_state,
> >  new_plane_state, i) {
> > if (plane->pipe != crtc->pipe)
> > -- 
> > 2.41.0
> > 

-- 
Ville Syrjälä
Intel

Re: [PATCH 9/9] Revert "drm/i915/xe2lpd: Treat cursor plane as regular plane for DDB allocation"

[Ville Syrjälä]

On Wed, Dec 13, 2023 at 05:29:12PM +0200, Ville Syrjälä wrote:
> On Wed, Dec 13, 2023 at 05:15:06PM +0200, Ville Syrjälä wrote:
> > On Wed, Dec 13, 2023 at 01:28:15PM +0200, Lisovskiy, Stanislav wrote:
> > > On Wed, Dec 13, 2023 at 12:25:19PM +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä 
> > > > 
> > > > This reverts commit cfeff354f70bb1d0deb0279506e3f7989bc16e28.
> > > > 
> > > > A core design consideration with legacy cursor updates is that the
> > > > cursor must not touch any other plane, even if we were to force it
> > > > to take the slow path. That is the real reason why the cursor uses
> > > > a fixed ddb allocation, not because bspec says so.
> > > > 
> > > > Treating cursors as any other plane during ddb allocation
> > > > violates that, which means we can now pull other planes into
> > > > fully unsynced legacy cursor mailbox commits. That is
> > > > definitely not something we've ever considered when designing
> > > > the rest of the code. The noarm+arm register write split in
> > > > particular makes that dangerous as previous updates can get
> > > > disarmed pretty much at any random time, and not necessarily
> > > > in an order that is actually safe (eg. against ddb overlaps).
> > > > 
> > > > So if we were to do this then:
> > > > - someone needs to expend the appropriate amount of brain
> > > >   cells thinking through all the tricky details
> > > 
> > > So question is how can we avoid pulling other planes to the commit?..
> > 
> > By preallocating the ddb, as we do already.
> 
> I guess one thing we could consider is allcating the cursor ddb
> based on the cursors real size (as opposed to always allocating for
> 256x256 cursor), and not doing a mailbox update when changing size.
> But as we learn in https://gitlab.freedesktop.org/drm/intel/-/issues/7687:
> - current userspace always uses 256x256 until the PLANE_SIZE_HINTS
>   stuff (or something similar) lands, so there is no point
> - it would lead to worse power consumption with smaller cursors
>   as there isn't enough extra ddb. The fact that we currently 
>   allocate the minimum for 256x256 means smallers cursor sizes
>   are more efficient. Some tests I did also indicated that the
>   current code does not give optimal values even if we let it
>   fully calculate the extra ddb like in the reverted commit here.
>   We really need someone to take a proper look at how to tune
>   the ddb allocation for optimal power consumption...

Oh, and another random idea I keep having occasionally would
be to by default assume that legacy cursor uapi wouldn't be
used, and then massage stuff sufficiently when the first use
appears to make it work well from that point onwards. That 
way we could try to be a bit more optimal with ddb/other
stuff for userspace that never uses the legacy cursor uapi.
But haven't really thought through the details on this one.

-- 
Ville Syrjälä
Intel

[PATCH] drm/mm: Allow CONFIG_DRM_MM_DEBUG with DRM=m

[Ville Syrjala]

From: Ville Syrjälä 

The original rationale for
commit cd456f8d06d2 ("drm: Restrict stackdepot usage to builtin drm.ko")
was that depot_save_stack() (which is what we used back then)
wasn't exported. stack_depot_save() (which is what we use now) is
exported however, so relax the dependency allow CONFIG_DRM_MM_DEBUG
with DRM=m.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 31cfe2c2a2af..4b8b8f8a0e72 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -42,7 +42,7 @@ config DRM_MIPI_DSI
 config DRM_DEBUG_MM
bool "Insert extra checks and debug info into the DRM range managers"
default n
-   depends on DRM=y
+   depends on DRM
depends on STACKTRACE_SUPPORT
select STACKDEPOT
help
-- 
2.41.0

[PATCH 3/3] drm/i915: Pin error_capture to high end of mappable

[Ville Syrjala]

From: Ville Syrjälä 

If we fail to pin error_capture to the start of ggtt (which
is likely given the BIOS fb is usually there), we currently
fall back to pinning it at the next available low address.
This seems somewhat sub-optimal to me in case we later discard
the BIOS fb (fairly likely if there are multiple different sized
displays connected at boot). We are then then left with a
permanenly pinned object somewhere in the middle of the mappable
range of ggtt. It seems more sensible to pin the error capture
object to the end of mappable as a fallback, so even if we discard
the BIOS fb we are left with the mappable region mostly in one
piece (potentially allowing for more/larger objects to be pinned
there later).

Though I suppose we are chopping the ggtt address space as a
whole into two chunks in a slightly different way. Essentially
reducing the size of the second (larger) chunk a bit. So perhaps
pinning truly massive objects (which don't strictly need to
be mappable) could become a bit more difficult.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 21a7e3191c18..f62008962eb5 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -876,7 +876,7 @@ static int init_ggtt(struct i915_ggtt *ggtt)
ggtt->error_capture.size, 0,
ggtt->error_capture.color,
0, ggtt->mappable_end,
-   DRM_MM_INSERT_LOW);
+   DRM_MM_INSERT_HIGH);
}
if (drm_mm_node_allocated(>error_capture)) {
u64 start = ggtt->error_capture.start;
-- 
2.41.0

[PATCH 2/3] drm/i915/hdcp: Pin the hdcp gsc message high in ggtt

[Ville Syrjala]

From: Ville Syrjälä 

AFAICS there is no hardware restriction on where in ggtt
the hdcp gsc message object needs to be bound. And as it's
a regular shmem object we don't need it be in the mappabe
range either. So pin it high to make avoid needlessly
wasting the precious mappable range for it.

Cc: Suraj Kandpal 
Cc: Alan Previn 
Cc: Uma Shankar 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c 
b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
index 18117b789b16..302bff75b06c 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
@@ -65,7 +65,7 @@ static int intel_hdcp_gsc_initialize_message(struct 
drm_i915_private *i915,
goto out_unmap;
}
 
-   err = i915_vma_pin(vma, 0, 0, PIN_GLOBAL);
+   err = i915_vma_pin(vma, 0, 0, PIN_GLOBAL | PIN_HIGH);
if (err)
goto out_unmap;
 
-- 
2.41.0

[PATCH 1/3] drm/i915/hdcp: Do intel_hdcp_component_init() much later during init

[Ville Syrjala]

From: Ville Syrjälä 

intel_hdcp_component_init()->...->intel_hdcp_gsc_initialize_message()
will allocate ggtt address space for some hdcp gsc message thing.
That is currently being done way too early as we haven't even
taken over the BIOS fb yet. So this has the potential of corrupting
ggtt PTEs that need to be preserved until the the BIOS fb takover
is done.

Only call intel_hdcp_component_init() once all the BIOS fb takeover,
and full ggtt init (which currently also needs to reserve very
specific ranges of ggtt, thus assuming that no one else has stolen
them yet) is done.

Cc: Suraj Kandpal 
Cc: Alan Previn 
Cc: Uma Shankar 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display_driver.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c 
b/drivers/gpu/drm/i915/display/intel_display_driver.c
index 62f7b10484be..b71338b4d793 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.c
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
@@ -319,8 +319,6 @@ int intel_display_driver_probe_nogem(struct 
drm_i915_private *i915)
intel_display_driver_init_hw(i915);
intel_dpll_update_ref_clks(i915);
 
-   intel_hdcp_component_init(i915);
-
if (i915->display.cdclk.max_cdclk_freq == 0)
intel_update_max_cdclk(i915);
 
@@ -360,6 +358,13 @@ int intel_display_driver_probe(struct drm_i915_private 
*i915)
if (!HAS_DISPLAY(i915))
return 0;
 
+   /*
+* This will bind stuff into ggtt, so it needs to be done after
+* the BIOS fb takeover and whatever else magic ggtt reservations
+* happen during gem/ggtt init.
+*/
+   intel_hdcp_component_init(i915);
+
/*
 * Force all active planes to recompute their states. So that on
 * mode_setcrtc after probe, all the intel_plane_state variables
-- 
2.41.0

[PATCH 0/3] drm/i915: Eaerly ggtt pinning stuff

[Ville Syrjala]

From: Ville Syrjälä 

Fix up an order issue with HDCP code that tries to clobber the
ggtt way too early. And try to optimize where in the ggtt we
place permanently pinned stuff.

Ville Syrjälä (3):
  drm/i915/hdcp: Do intel_hdcp_component_init() much later during init
  drm/i915/hdcp: Pin the hdcp gsc message high in ggtt
  drm/i915: Pin error_capture to high end of mappable

 drivers/gpu/drm/i915/display/intel_display_driver.c | 9 +++--
 drivers/gpu/drm/i915/display/intel_hdcp_gsc.c   | 2 +-
 drivers/gpu/drm/i915/gt/intel_ggtt.c| 2 +-
 3 files changed, 9 insertions(+), 4 deletions(-)

-- 
2.41.0

[PATCH v2 15/15] drm/i915: Try to relocate the BIOS fb to the start of ggtt

[Ville Syrjala]

From: Ville Syrjälä 

On MTL the GOP (for whatever reason) likes to bind its framebuffer
high up in the ggtt address space. This can conflict with whatever
ggtt_reserve_guc_top() is trying to do, and the result is that
ggtt_reserve_guc_top() fails and then we proceed to explode when
trying to tear down the driver. Thus far I haven't analyzed what
causes the actual fireworks, but it's not super important as even
if it didn't explode we'd still fail the driver load and the user
would be left with an unusable GPU.

To remedy this (without having to figure out exactly what
ggtt_reserve_guc_top() is trying to achieve) we can attempt to
relocate the BIOS framebuffer to a lower ggtt address. We can do
this at this early point in driver init because nothing else is
supposed to be clobbering the ggtt yet. So we simply change where
in the ggtt we pin the vma, the original PTEs will be left as is,
and the new PTEs will get written with the same dma addresses.
The plane will keep on scanning out from the original PTEs until
we are done with the whole process, and at that point we rewrite
the plane's surface address register to point at the new ggtt
address.

Since we don't need a specific ggtt address for the plane
(apart from needing it to land in the mappable region for
normal stolen objects) we'll just try to pin it without a fixed
offset first. It should end up at the lowest available address
(which really should be 0 at this point in the driver init).
If that fails we'll fall back to just pinning it exactly to the
origianal address.

To make sure we don't accidentlally pin it partially over the
original ggtt range (as that would corrupt the original PTEs)
we reserve the original range temporarily during this process.

Cc: Paz Zcharya 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/i9xx_plane.c | 30 ++
 drivers/gpu/drm/i915/display/i9xx_plane.h |  7 +++
 drivers/gpu/drm/i915/display/intel_display.c  |  5 ++
 .../gpu/drm/i915/display/intel_display_core.h |  2 +
 .../drm/i915/display/intel_plane_initial.c| 57 ++-
 .../drm/i915/display/skl_universal_plane.c| 28 +
 .../drm/i915/display/skl_universal_plane.h|  2 +
 7 files changed, 128 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c 
b/drivers/gpu/drm/i915/display/i9xx_plane.c
index 91f2bc405cba..0279c8aabdd1 100644
--- a/drivers/gpu/drm/i915/display/i9xx_plane.c
+++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
@@ -1060,3 +1060,33 @@ i9xx_get_initial_plane_config(struct intel_crtc *crtc,
 
plane_config->fb = intel_fb;
 }
+
+bool i9xx_fixup_initial_plane_config(struct intel_crtc *crtc,
+const struct intel_initial_plane_config 
*plane_config)
+{
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   struct intel_plane *plane = to_intel_plane(crtc->base.primary);
+   const struct intel_plane_state *plane_state =
+   to_intel_plane_state(plane->base.state);
+   enum i9xx_plane_id i9xx_plane = plane->i9xx_plane;
+   u32 base;
+
+   if (!plane_state->uapi.visible)
+   return false;
+
+   base = intel_plane_ggtt_offset(plane_state);
+
+   /*
+* We may have moved the surface to a different
+* part of ggtt, make the plane aware of that.
+*/
+   if (plane_config->base == base)
+   return false;
+
+   if (DISPLAY_VER(dev_priv) >= 4)
+   intel_de_write(dev_priv, DSPSURF(i9xx_plane), base);
+   else
+   intel_de_write(dev_priv, DSPADDR(i9xx_plane), base);
+
+   return true;
+}
diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.h 
b/drivers/gpu/drm/i915/display/i9xx_plane.h
index b3d724a144cb..0ca12d1e6839 100644
--- a/drivers/gpu/drm/i915/display/i9xx_plane.h
+++ b/drivers/gpu/drm/i915/display/i9xx_plane.h
@@ -26,6 +26,8 @@ intel_primary_plane_create(struct drm_i915_private *dev_priv, 
enum pipe pipe);
 
 void i9xx_get_initial_plane_config(struct intel_crtc *crtc,
   struct intel_initial_plane_config 
*plane_config);
+bool i9xx_fixup_initial_plane_config(struct intel_crtc *crtc,
+const struct intel_initial_plane_config 
*plane_config);
 #else
 static inline unsigned int i965_plane_max_stride(struct intel_plane *plane,
 u32 pixel_format, u64 modifier,
@@ -46,6 +48,11 @@ static inline void i9xx_get_initial_plane_config(struct 
intel_crtc *crtc,
 struct 
intel_initial_plane_config *plane_config)
 {
 }
+static inline bool i9xx_fixup_initial_plane_config(struct intel_crtc *crtc,
+  const struct 
intel_initial_plane_config *plane_config)
+{
+   return false;
+}
 #endif
 
 #endif
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c

[PATCH v2 14/15] drm/i915: Tweak BIOS fb reuse check

[Ville Syrjala]

From: Ville Syrjälä 

Currently we assume that we bind the BIOS fb exactly into the same
ggtt address where the BIOS left it. That is about to change, and
in order to keep intel_reuse_initial_plane_obj() working as intended
we need to compare the original ggtt offset (called 'base' here)
as opposed ot the actual vma ggtt offset we selected. Otherwise
the first plane could change the ggtt offset, and then subsequent
planes would no longer notice that they are in fact using the same
ggtt offset that the first plane was already using. Thus the reuse
check will fail and we proceed to turn off these subsequent planes.

TODO: would probably make more sense to do the pure readout first
for all the planes, then check for fb reuse, and only then proceed
to pin the object into the final location in the ggtt...

Cc: Paz Zcharya 
Signed-off-by: Ville Syrjälä 
---
 .../drm/i915/display/intel_plane_initial.c| 34 +++
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c 
b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index b7e12b60d68b..82ab98985a09 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -13,20 +13,21 @@
 #include "intel_plane_initial.h"
 
 static bool
-intel_reuse_initial_plane_obj(struct drm_i915_private *i915,
- const struct intel_initial_plane_config 
*plane_config,
+intel_reuse_initial_plane_obj(struct intel_crtc *this,
+ const struct intel_initial_plane_config 
plane_configs[],
  struct drm_framebuffer **fb,
  struct i915_vma **vma)
 {
+   struct drm_i915_private *i915 = to_i915(this->base.dev);
struct intel_crtc *crtc;
 
for_each_intel_crtc(>drm, crtc) {
-   struct intel_crtc_state *crtc_state =
-   to_intel_crtc_state(crtc->base.state);
-   struct intel_plane *plane =
+   const struct intel_plane *plane =
to_intel_plane(crtc->base.primary);
-   struct intel_plane_state *plane_state =
+   const struct intel_plane_state *plane_state =
to_intel_plane_state(plane->base.state);
+   const struct intel_crtc_state *crtc_state =
+   to_intel_crtc_state(crtc->base.state);
 
if (!crtc_state->uapi.active)
continue;
@@ -34,7 +35,7 @@ intel_reuse_initial_plane_obj(struct drm_i915_private *i915,
if (!plane_state->ggtt_vma)
continue;
 
-   if (intel_plane_ggtt_offset(plane_state) == plane_config->base) 
{
+   if (plane_configs[this->pipe].base == 
plane_configs[crtc->pipe].base) {
*fb = plane_state->hw.fb;
*vma = plane_state->ggtt_vma;
return true;
@@ -265,10 +266,11 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
 
 static void
 intel_find_initial_plane_obj(struct intel_crtc *crtc,
-struct intel_initial_plane_config *plane_config)
+struct intel_initial_plane_config plane_configs[])
 {
-   struct drm_device *dev = crtc->base.dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   struct intel_initial_plane_config *plane_config =
+   _configs[crtc->pipe];
struct intel_plane *plane =
to_intel_plane(crtc->base.primary);
struct intel_plane_state *plane_state =
@@ -294,7 +296,7 @@ intel_find_initial_plane_obj(struct intel_crtc *crtc,
 * Failed to alloc the obj, check to see if we should share
 * an fb with another CRTC instead
 */
-   if (intel_reuse_initial_plane_obj(dev_priv, plane_config, , ))
+   if (intel_reuse_initial_plane_obj(crtc, plane_configs, , ))
goto valid_fb;
 
/*
@@ -359,10 +361,12 @@ static void plane_config_fini(struct 
intel_initial_plane_config *plane_config)
 
 void intel_initial_plane_config(struct drm_i915_private *i915)
 {
+   struct intel_initial_plane_config plane_configs[I915_MAX_PIPES] = {};
struct intel_crtc *crtc;
 
for_each_intel_crtc(>drm, crtc) {
-   struct intel_initial_plane_config plane_config = {};
+   struct intel_initial_plane_config *plane_config =
+   _configs[crtc->pipe];
 
if (!to_intel_crtc_state(crtc->base.state)->uapi.active)
continue;
@@ -374,14 +378,14 @@ void intel_initial_plane_config(struct drm_i915_private 
*i915)
 * can even allow for smooth boot transitions if the BIOS
 * fb is large enough for the active pipe configuration.
 */
-   

[PATCH v2 13/15] drm/i915/fbdev: Fix smem_start for LMEMBAR stolen objects

[Ville Syrjala]

From: Ville Syrjälä 

The "io" address of an object is its dma address minus the
region.start. Subtract the latter to make smem_start correct.
The current code happens to work for genuine LMEM objects
as LMEM region.start==0, but for LMEMBAR stolen objects
region.start!=0.

TODO: perhaps just set smem_start=0 always as our .fb_mmap()
implementation no longer depends on it? Need to double check
it's not needed for anything else...

Cc: Paz Zcharya 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_fbdev_fb.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev_fb.c 
b/drivers/gpu/drm/i915/display/intel_fbdev_fb.c
index 1ac05d90b2e8..0665f943f65f 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev_fb.c
@@ -79,7 +79,8 @@ int intel_fbdev_fb_fill_info(struct drm_i915_private *i915, 
struct fb_info *info
/* Use fbdev's framebuffer from lmem for discrete */
info->fix.smem_start =
(unsigned long)(mem->io.start +
-   i915_gem_object_get_dma_address(obj, 
0));
+   i915_gem_object_get_dma_address(obj, 0) 
-
+   mem->region.start);
info->fix.smem_len = obj->base.size;
} else {
struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
-- 
2.41.0

[PATCH v2 12/15] drm/i915: Simplify intel_initial_plane_config() calling convention

[Ville Syrjala]

From: Ville Syrjälä 

There's no reason the caller of intel_initial_plane_config() should
have to loop over the CRTCs. Pull the loop into the function to
make life simpler for the caller.

Cc: Paz Zcharya 
Signed-off-by: Ville Syrjälä 
---
 .../drm/i915/display/intel_display_driver.c   |  7 +---
 .../drm/i915/display/intel_plane_initial.c| 40 +++
 .../drm/i915/display/intel_plane_initial.h|  4 +-
 3 files changed, 26 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c 
b/drivers/gpu/drm/i915/display/intel_display_driver.c
index 62f7b10484be..2fe0f4ad359c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.c
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
@@ -285,7 +285,6 @@ int intel_display_driver_probe_nogem(struct 
drm_i915_private *i915)
 {
struct drm_device *dev = >drm;
enum pipe pipe;
-   struct intel_crtc *crtc;
int ret;
 
if (!HAS_DISPLAY(i915))
@@ -335,11 +334,7 @@ int intel_display_driver_probe_nogem(struct 
drm_i915_private *i915)
intel_acpi_assign_connector_fwnodes(i915);
drm_modeset_unlock_all(dev);
 
-   for_each_intel_crtc(dev, crtc) {
-   if (!to_intel_crtc_state(crtc->base.state)->uapi.active)
-   continue;
-   intel_crtc_initial_plane_config(crtc);
-   }
+   intel_initial_plane_config(i915);
 
/*
 * Make sure hardware watermarks really match the state we read out.
diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c 
b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index 78bff6181ceb..b7e12b60d68b 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -357,25 +357,31 @@ static void plane_config_fini(struct 
intel_initial_plane_config *plane_config)
i915_vma_put(plane_config->vma);
 }
 
-void intel_crtc_initial_plane_config(struct intel_crtc *crtc)
+void intel_initial_plane_config(struct drm_i915_private *i915)
 {
-   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   struct intel_initial_plane_config plane_config = {};
+   struct intel_crtc *crtc;
 
-   /*
-* Note that reserving the BIOS fb up front prevents us
-* from stuffing other stolen allocations like the ring
-* on top.  This prevents some ugliness at boot time, and
-* can even allow for smooth boot transitions if the BIOS
-* fb is large enough for the active pipe configuration.
-*/
-   dev_priv->display.funcs.display->get_initial_plane_config(crtc, 
_config);
+   for_each_intel_crtc(>drm, crtc) {
+   struct intel_initial_plane_config plane_config = {};
 
-   /*
-* If the fb is shared between multiple heads, we'll
-* just get the first one.
-*/
-   intel_find_initial_plane_obj(crtc, _config);
+   if (!to_intel_crtc_state(crtc->base.state)->uapi.active)
+   continue;
 
-   plane_config_fini(_config);
+   /*
+* Note that reserving the BIOS fb up front prevents us
+* from stuffing other stolen allocations like the ring
+* on top.  This prevents some ugliness at boot time, and
+* can even allow for smooth boot transitions if the BIOS
+* fb is large enough for the active pipe configuration.
+*/
+   i915->display.funcs.display->get_initial_plane_config(crtc, 
_config);
+
+   /*
+* If the fb is shared between multiple heads, we'll
+* just get the first one.
+*/
+   intel_find_initial_plane_obj(crtc, _config);
+
+   plane_config_fini(_config);
+   }
 }
diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.h 
b/drivers/gpu/drm/i915/display/intel_plane_initial.h
index c7e35ab3182b..64ab95239cd4 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.h
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.h
@@ -6,8 +6,8 @@
 #ifndef __INTEL_PLANE_INITIAL_H__
 #define __INTEL_PLANE_INITIAL_H__
 
-struct intel_crtc;
+struct drm_i915_private;
 
-void intel_crtc_initial_plane_config(struct intel_crtc *crtc);
+void intel_initial_plane_config(struct drm_i915_private *i915);
 
 #endif
-- 
2.41.0

[PATCH v2 11/15] drm/i915: Split the smem and lmem plane readout apart

[Ville Syrjala]

From: Ville Syrjälä 

Declutter initial_plane_vma() a bit by pulling the lmem and smem
readout paths into their own functions.

TODO: the smem path should still be fixed to get and validate
  the dma address from the pte as well

Cc: Paz Zcharya 
Signed-off-by: Ville Syrjälä 
---
 .../drm/i915/display/intel_display_types.h|   2 +
 .../drm/i915/display/intel_plane_initial.c| 145 +++---
 2 files changed, 95 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 341d80c2b9de..d2b0cc754667 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -782,6 +782,8 @@ struct intel_plane_state {
 
 struct intel_initial_plane_config {
struct intel_framebuffer *fb;
+   struct intel_memory_region *mem;
+   resource_size_t phys_base;
struct i915_vma *vma;
unsigned int tiling;
int size;
diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c 
b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index 48b74319f45c..78bff6181ceb 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -44,6 +44,93 @@ intel_reuse_initial_plane_obj(struct drm_i915_private *i915,
return false;
 }
 
+static bool
+initial_plane_phys_lmem(struct drm_i915_private *i915,
+   struct intel_initial_plane_config *plane_config)
+{
+   gen8_pte_t __iomem *gte = to_gt(i915)->ggtt->gsm;
+   struct intel_memory_region *mem;
+   dma_addr_t dma_addr;
+   gen8_pte_t pte;
+   u32 base;
+
+   base = round_down(plane_config->base, I915_GTT_MIN_ALIGNMENT);
+
+   gte += base / I915_GTT_PAGE_SIZE;
+
+   pte = ioread64(gte);
+   if (!(pte & GEN12_GGTT_PTE_LM)) {
+   drm_err(>drm,
+   "Initial plane programming missing PTE_LM bit\n");
+   return false;
+   }
+
+   dma_addr = pte & GEN12_GGTT_PTE_ADDR_MASK;
+
+   if (IS_DGFX(i915))
+   mem = i915->mm.regions[INTEL_REGION_LMEM_0];
+   else
+   mem = i915->mm.stolen_region;
+   if (!mem) {
+   drm_dbg_kms(>drm,
+   "Initial plane memory region not initialized\n");
+   return false;
+   }
+
+   /*
+* On lmem we don't currently expect this to
+* ever be placed in the stolen portion.
+*/
+   if (dma_addr < mem->region.start || dma_addr > mem->region.end) {
+   drm_err(>drm,
+   "Initial plane programming using invalid range, 
dma_addr=%pa (%s [%pa-%pa])\n",
+   _addr, mem->region.name, >region.start, 
>region.end);
+   return false;
+   }
+
+   drm_dbg(>drm,
+   "Using dma_addr=%pa, based on initial plane programming\n",
+   _addr);
+
+   plane_config->phys_base = dma_addr - mem->region.start;
+   plane_config->mem = mem;
+
+   return true;
+}
+
+static bool
+initial_plane_phys_smem(struct drm_i915_private *i915,
+   struct intel_initial_plane_config *plane_config)
+{
+   struct intel_memory_region *mem;
+   u32 base;
+
+   base = round_down(plane_config->base, I915_GTT_MIN_ALIGNMENT);
+
+   mem = i915->mm.stolen_region;
+   if (!mem) {
+   drm_dbg_kms(>drm,
+   "Initial plane memory region not initialized\n");
+   return false;
+   }
+
+   /* FIXME get and validate the dma_addr from the PTE */
+   plane_config->phys_base = base;
+   plane_config->mem = mem;
+
+   return true;
+}
+
+static bool
+initial_plane_phys(struct drm_i915_private *i915,
+  struct intel_initial_plane_config *plane_config)
+{
+   if (IS_DGFX(i915) || HAS_LMEMBAR_SMEM_STOLEN(i915))
+   return initial_plane_phys_lmem(i915, plane_config);
+   else
+   return initial_plane_phys_smem(i915, plane_config);
+}
+
 static struct i915_vma *
 initial_plane_vma(struct drm_i915_private *i915,
  struct intel_initial_plane_config *plane_config)
@@ -58,59 +145,13 @@ initial_plane_vma(struct drm_i915_private *i915,
if (plane_config->size == 0)
return NULL;
 
+   if (!initial_plane_phys(i915, plane_config))
+   return NULL;
+
+   phys_base = plane_config->phys_base;
+   mem = plane_config->mem;
+
base = round_down(plane_config->base, I915_GTT_MIN_ALIGNMENT);
-   if (IS_DGFX(i915) || HAS_LMEMBAR_SMEM_STOLEN(i915)) {
-   gen8_pte_t __iomem *gte = to_gt(i915)->ggtt->gsm;
-   dma_addr_t dma_addr;
-   gen8_pte_t pte;
-
-   gte += base / I915_GTT_PAGE_SIZE;
-
-   pte = ioread64(gte);
-   if (!(pte & GEN12_GGTT_PTE_LM)) {
- 

[PATCH v2 10/15] drm/i915: s/phys_base/dma_addr/

[Ville Syrjala]

From: Ville Syrjälä 

The address we read from the PTE is a dma address, not a physical
address. Rename the variable to say so.

Cc: Paz Zcharya 
Signed-off-by: Ville Syrjälä 
---
 .../gpu/drm/i915/display/intel_plane_initial.c| 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c 
b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index c72d4cacf631..48b74319f45c 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -61,6 +61,7 @@ initial_plane_vma(struct drm_i915_private *i915,
base = round_down(plane_config->base, I915_GTT_MIN_ALIGNMENT);
if (IS_DGFX(i915) || HAS_LMEMBAR_SMEM_STOLEN(i915)) {
gen8_pte_t __iomem *gte = to_gt(i915)->ggtt->gsm;
+   dma_addr_t dma_addr;
gen8_pte_t pte;
 
gte += base / I915_GTT_PAGE_SIZE;
@@ -72,7 +73,7 @@ initial_plane_vma(struct drm_i915_private *i915,
return NULL;
}
 
-   phys_base = pte & GEN12_GGTT_PTE_ADDR_MASK;
+   dma_addr = pte & GEN12_GGTT_PTE_ADDR_MASK;
 
if (IS_DGFX(i915))
mem = i915->mm.regions[INTEL_REGION_LMEM_0];
@@ -88,18 +89,18 @@ initial_plane_vma(struct drm_i915_private *i915,
 * On lmem we don't currently expect this to
 * ever be placed in the stolen portion.
 */
-   if (phys_base < mem->region.start || phys_base > 
mem->region.end) {
+   if (dma_addr < mem->region.start || dma_addr > mem->region.end) 
{
drm_err(>drm,
-   "Initial plane programming using invalid range, 
phys_base=%pa (%s [%pa-%pa])\n",
-   _base, mem->region.name, 
>region.start, >region.end);
+   "Initial plane programming using invalid range, 
dma_addr=%pa (%s [%pa-%pa])\n",
+   _addr, mem->region.name, 
>region.start, >region.end);
return NULL;
}
 
drm_dbg(>drm,
-   "Using phys_base=%pa, based on initial plane 
programming\n",
-   _base);
+   "Using dma_addr=%pa, based on initial plane 
programming\n",
+   _addr);
 
-   phys_base -= mem->region.start;
+   phys_base = dma_addr - mem->region.start;
} else {
phys_base = base;
mem = i915->mm.stolen_region;
-- 
2.41.0

[PATCH v2 09/15] drm/i915: Fix MTL initial plane readout

[Ville Syrjala]

From: Ville Syrjälä 

MTL stolen memory looks more like local memory, so use the
(now fixed) lmem path when doing the initial plane readout.

Cc: Paz Zcharya 
Signed-off-by: Ville Syrjälä 
---
 .../drm/i915/display/intel_plane_initial.c| 25 +--
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c 
b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index db594ccf0323..c72d4cacf631 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -59,7 +59,7 @@ initial_plane_vma(struct drm_i915_private *i915,
return NULL;
 
base = round_down(plane_config->base, I915_GTT_MIN_ALIGNMENT);
-   if (IS_DGFX(i915)) {
+   if (IS_DGFX(i915) || HAS_LMEMBAR_SMEM_STOLEN(i915)) {
gen8_pte_t __iomem *gte = to_gt(i915)->ggtt->gsm;
gen8_pte_t pte;
 
@@ -73,11 +73,20 @@ initial_plane_vma(struct drm_i915_private *i915,
}
 
phys_base = pte & GEN12_GGTT_PTE_ADDR_MASK;
-   mem = i915->mm.regions[INTEL_REGION_LMEM_0];
+
+   if (IS_DGFX(i915))
+   mem = i915->mm.regions[INTEL_REGION_LMEM_0];
+   else
+   mem = i915->mm.stolen_region;
+   if (!mem) {
+   drm_dbg_kms(>drm,
+   "Initial plane memory region not 
initialized\n");
+   return NULL;
+   }
 
/*
-* We don't currently expect this to ever be placed in the
-* stolen portion.
+* On lmem we don't currently expect this to
+* ever be placed in the stolen portion.
 */
if (phys_base < mem->region.start || phys_base > 
mem->region.end) {
drm_err(>drm,
@@ -94,11 +103,13 @@ initial_plane_vma(struct drm_i915_private *i915,
} else {
phys_base = base;
mem = i915->mm.stolen_region;
+   if (!mem) {
+   drm_dbg_kms(>drm,
+   "Initial plane memory region not 
initialized\n");
+   return NULL;
+   }
}
 
-   if (!mem)
-   return NULL;
-
size = round_up(plane_config->base + plane_config->size,
mem->min_page_size);
size -= base;
-- 
2.41.0

[PATCH v2 08/15] drm/i915: Fix region start during initial plane readout

[Ville Syrjala]

From: Ville Syrjälä 

On MTL the stolen region starts at offset 8MiB from the start of
LMEMBAR. The dma addresses are thus also offset by 8MiB. However the
mm_node/etc. is zero based, and i915_pages_create_for_stolen() will
add the appropriate region.start into the sg dma address. So when
we do the readout we need to convert the dma address read from
the PTE to be zero based as well.

Note that currently we don't take this path on MTL, but we should
and thus this needs to be fixed. For lmem this works correctly
already as the lmem region.start==0.

While at it let's also make sure the address points to somewhere within
the memory region. We don't need to check the size as
i915_gem_object_create_region_at() should later fail if the object size
exceeds the region size.

Cc: Paz Zcharya 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_plane_initial.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c 
b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index ffc92b18fcf5..db594ccf0323 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -79,16 +79,18 @@ initial_plane_vma(struct drm_i915_private *i915,
 * We don't currently expect this to ever be placed in the
 * stolen portion.
 */
-   if (phys_base >= resource_size(>region)) {
+   if (phys_base < mem->region.start || phys_base > 
mem->region.end) {
drm_err(>drm,
-   "Initial plane programming using invalid range, 
phys_base=%pa\n",
-   _base);
+   "Initial plane programming using invalid range, 
phys_base=%pa (%s [%pa-%pa])\n",
+   _base, mem->region.name, 
>region.start, >region.end);
return NULL;
}
 
drm_dbg(>drm,
"Using phys_base=%pa, based on initial plane 
programming\n",
_base);
+
+   phys_base -= mem->region.start;
} else {
phys_base = base;
mem = i915->mm.stolen_region;
-- 
2.41.0

[PATCH v2 07/15] drm/i915: Fix PTE decode during initial plane readout

[Ville Syrjala]

From: Ville Syrjälä 

When multiple pipes are enabled by the BIOS we try to read out each
in turn. But we do the readout for the second only after the inherited
vma for the first has been rebound into its original place (and thus
the PTEs have been rewritten). Unlike the BIOS we set some high caching
bits in the PTE on MTL which confuses the readout for the second plane.
Filter out the non-address bits from the PTE value appropriately to
fix this.

I suppose it might also be possible that the BIOS would already set
some caching bits as well, in which case we'd run into this same
issue already for the first plane.

TODO:
- should abstract the PTE decoding to avoid details leaking all over
- should probably do the readout for all the planes before
  we touch anything (including the PTEs) so that we truly read
  out the BIOS state

Cc: Paz Zcharya 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_plane_initial.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c 
b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index a55c09cbd0e4..ffc92b18fcf5 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -72,7 +72,7 @@ initial_plane_vma(struct drm_i915_private *i915,
return NULL;
}
 
-   phys_base = pte & I915_GTT_PAGE_MASK;
+   phys_base = pte & GEN12_GGTT_PTE_ADDR_MASK;
mem = i915->mm.regions[INTEL_REGION_LMEM_0];
 
/*
-- 
2.41.0

[PATCH v2 06/15] drm/i915: Rename the DSM/GSM registers

[Ville Syrjala]

From: Ville Syrjälä 

0x108100 and 0x1080c0 have been around since snb. Rename the
defines appropriately.

Cc: Paz Zcharya 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c  | 4 ++--
 drivers/gpu/drm/i915/gt/intel_ggtt.c| 2 +-
 drivers/gpu/drm/i915/gt/intel_region_lmem.c | 2 +-
 drivers/gpu/drm/i915/i915_reg.h | 7 ---
 4 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 252fe5cd6ede..6185a5f73a48 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -935,7 +935,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, 
u16 type,
GEM_BUG_ON((dsm_base + dsm_size) > lmem_size);
} else {
/* Use DSM base address instead for stolen memory */
-   dsm_base = intel_uncore_read64(uncore, GEN12_DSMBASE) & 
GEN12_BDSM_MASK;
+   dsm_base = intel_uncore_read64(uncore, GEN6_DSMBASE) & 
GEN11_BDSM_MASK;
if (WARN_ON(lmem_size < dsm_base))
return ERR_PTR(-ENODEV);
dsm_size = ALIGN_DOWN(lmem_size - dsm_base, SZ_1M);
@@ -948,7 +948,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, 
u16 type,
 * Normally this would not work but on MTL the system firmware
 * should have relaxed the access permissions sufficiently.
 */
-   io_start = intel_uncore_read64(uncore, GEN12_DSMBASE) & 
GEN12_BDSM_MASK;
+   io_start = intel_uncore_read64(uncore, GEN6_DSMBASE) & 
GEN11_BDSM_MASK;
io_size = dsm_size;
} else if (pci_resource_len(pdev, GEN12_LMEM_BAR) < lmem_size) {
io_start = 0;
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index ab71d74ec426..05c5525e7e2d 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -1167,7 +1167,7 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 
size)
 * should have relaxed the access permissions sufficiently.
 */
if (IS_METEORLAKE(i915))
-   phys_addr = intel_uncore_read64(uncore, GEN12_GSMBASE) & 
GEN12_BDSM_MASK;
+   phys_addr = intel_uncore_read64(uncore, GEN6_GSMBASE) & 
GEN11_BDSM_MASK;
else
phys_addr = pci_resource_start(pdev, GEN4_GTTMMADR_BAR) + 
gen6_gttadr_offset(i915);
 
diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c 
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index af357089da6e..51bb27e10a4f 100644
--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
@@ -240,7 +240,7 @@ static struct intel_memory_region *setup_lmem(struct 
intel_gt *gt)
lmem_size -= tile_stolen;
} else {
/* Stolen starts from GSMBASE without CCS */
-   lmem_size = intel_uncore_read64(>uncore, GEN12_GSMBASE);
+   lmem_size = intel_uncore_read64(>uncore, GEN6_GSMBASE);
}
 
i915_resize_lmem_bar(i915, lmem_size);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 27dc903f0553..b54d62952a53 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6314,9 +6314,10 @@ enum skl_power_gate {
 #define   GMS_MASK REG_GENMASK(15, 8)
 #define   GGMS_MASKREG_GENMASK(7, 6)
 
-#define GEN12_GSMBASE  _MMIO(0x108100)
-#define GEN12_DSMBASE  _MMIO(0x1080C0)
-#define   GEN12_BDSM_MASK  REG_GENMASK64(63, 20)
+#define GEN6_GSMBASE   _MMIO(0x108100)
+#define GEN6_DSMBASE   _MMIO(0x1080C0)
+#define   GEN6_BDSM_MASK   REG_GENMASK64(31, 20)
+#define   GEN11_BDSM_MASK  REG_GENMASK64(63, 20)
 
 #define XEHP_CLOCK_GATE_DIS_MMIO(0x101014)
 #define   SGSI_SIDECLK_DIS REG_BIT(17)
-- 
2.41.0

[PATCH v2 05/15] drm/i915: Disable the "binder"

[Ville Syrjala]

From: Ville Syrjälä 

Now that the GGTT PTE updates go straight to GSMBASE (bypassing
GTTMMADR) there should be no more risk of system hangs? So the
"binder" (ie. update the PTEs via MI_UPDATE_GTT) is no longer
necessary, disable it.

TODO: MI_UPDATE_GTT might be interesting as an optimization
though, so perhaps someone should look into always using it
(assuming the GPU is alive and well)?

Cc: Paz Zcharya 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/gt/intel_gtt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 86f73fe558ca..5bc7a4fb7485 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -24,7 +24,7 @@
 bool i915_ggtt_require_binder(struct drm_i915_private *i915)
 {
/* Wa_13010847436 & Wa_14019519902 */
-   return MEDIA_VER_FULL(i915) == IP_VER(13, 0);
+   return false && MEDIA_VER_FULL(i915) == IP_VER(13, 0);
 }
 
 static bool intel_ggtt_update_needs_vtd_wa(struct drm_i915_private *i915)
-- 
2.41.0

[PATCH v2 04/15] drm/i915: Bypass LMEMBAR/GTTMMADR for MTL stolen memory access

[Ville Syrjala]

From: Ville Syrjälä 

On MTL accessing stolen memory via the BARs is somehow borked,
and it can hang the machine. As a workaround let's bypass the
BARs and just go straight to DSMBASE/GSMBASE instead.

Note that on every other platform this itself would hang the
machine, but on MTL the system firmware is expected to relax
the access permission guarding stolen memory to enable this
workaround, and thus direct CPU accesses should be fine.

TODO: add w/a numbers and whatnot

Cc: Paz Zcharya 
Cc: Nirmoy Das 
Cc: Radhakrishna Sripada 
Cc: Joonas Lahtinen 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 11 ++-
 drivers/gpu/drm/i915/gt/intel_ggtt.c   | 13 -
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index ee237043c302..252fe5cd6ede 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -941,7 +941,16 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, 
u16 type,
dsm_size = ALIGN_DOWN(lmem_size - dsm_base, SZ_1M);
}
 
-   if (pci_resource_len(pdev, GEN12_LMEM_BAR) < lmem_size) {
+   if (IS_METEORLAKE(i915)) {
+   /*
+* Workaround: access via BAR can hang MTL, go directly to DSM.
+*
+* Normally this would not work but on MTL the system firmware
+* should have relaxed the access permissions sufficiently.
+*/
+   io_start = intel_uncore_read64(uncore, GEN12_DSMBASE) & 
GEN12_BDSM_MASK;
+   io_size = dsm_size;
+   } else if (pci_resource_len(pdev, GEN12_LMEM_BAR) < lmem_size) {
io_start = 0;
io_size = 0;
} else {
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 21a7e3191c18..ab71d74ec426 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -24,6 +24,7 @@
 #include "intel_ring.h"
 #include "i915_drv.h"
 #include "i915_pci.h"
+#include "i915_reg.h"
 #include "i915_request.h"
 #include "i915_scatterlist.h"
 #include "i915_utils.h"
@@ -1152,13 +1153,23 @@ static unsigned int gen6_gttadr_offset(struct 
drm_i915_private *i915)
 static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 size)
 {
struct drm_i915_private *i915 = ggtt->vm.i915;
+   struct intel_uncore *uncore = ggtt->vm.gt->uncore;
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
phys_addr_t phys_addr;
u32 pte_flags;
int ret;
 
GEM_WARN_ON(pci_resource_len(pdev, GEN4_GTTMMADR_BAR) != 
gen6_gttmmadr_size(i915));
-   phys_addr = pci_resource_start(pdev, GEN4_GTTMMADR_BAR) + 
gen6_gttadr_offset(i915);
+   /*
+* Workaround: access via BAR can hang MTL, go directly to GSM.
+*
+* Normally this would not work but on MTL the system firmware
+* should have relaxed the access permissions sufficiently.
+*/
+   if (IS_METEORLAKE(i915))
+   phys_addr = intel_uncore_read64(uncore, GEN12_GSMBASE) & 
GEN12_BDSM_MASK;
+   else
+   phys_addr = pci_resource_start(pdev, GEN4_GTTMMADR_BAR) + 
gen6_gttadr_offset(i915);
 
if (needs_wc_ggtt_mapping(i915))
ggtt->gsm = ioremap_wc(phys_addr, size);
-- 
2.41.0

[PATCH v2 03/15] drm/i915: Remove ad-hoc lmem/stolen debugs

[Ville Syrjala]

From: Ville Syrjälä 

Now that intel_memory_regions_hw_probe() prints out each and every
memory region there's no reason to have ad-hoc debugs to do similar
things elsewhere.

Cc: Paz Zcharya 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c  | 4 
 drivers/gpu/drm/i915/gt/intel_region_lmem.c | 3 ---
 2 files changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index d2440c793f84..ee237043c302 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -828,7 +828,6 @@ static const struct intel_memory_region_ops 
i915_region_stolen_smem_ops = {
 
 static int init_stolen_lmem(struct intel_memory_region *mem)
 {
-   struct drm_i915_private *i915 = mem->i915;
int err;
 
if (GEM_WARN_ON(resource_size(>region) == 0))
@@ -844,9 +843,6 @@ static int init_stolen_lmem(struct intel_memory_region *mem)
!io_mapping_init_wc(>iomap, mem->io.start, 
resource_size(>io)))
goto err_cleanup;
 
-   drm_dbg(>drm, "Stolen Local DSM: %pR\n", >region);
-   drm_dbg(>drm, "Stolen Local memory IO: %pR\n", >io);
-
return 0;
 
 err_cleanup:
diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c 
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index 6f96a6b70601..af357089da6e 100644
--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
@@ -273,9 +273,6 @@ static struct intel_memory_region *setup_lmem(struct 
intel_gt *gt)
if (err)
goto err_region_put;
 
-   drm_dbg(>drm, "Local memory: %pR\n", >region);
-   drm_dbg(>drm, "Local memory IO: %pR\n", >io);
-
if (io_size < lmem_size)
drm_info(>drm, "Using a reduced BAR size of %lluMiB. 
Consider enabling 'Resizable BAR' or similar, if available in the BIOS.\n",
 (u64)io_size >> 20);
-- 
2.41.0

[PATCH v2 02/15] drm/i915: Print memory region info during probe

[Ville Syrjala]

From: Ville Syrjälä 

Dump the details about every memory region into dmesg at probe time.
Avoids having to dig those out from random places when debugging stuff.

Cc: Paz Zcharya 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_memory_region.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_memory_region.c 
b/drivers/gpu/drm/i915/intel_memory_region.c
index b2708f8cac2a..52d998e5c21a 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -372,6 +372,24 @@ int intel_memory_regions_hw_probe(struct drm_i915_private 
*i915)
i915->mm.regions[i] = mem;
}
 
+   for (i = 0; i < ARRAY_SIZE(i915->mm.regions); i++) {
+   struct intel_memory_region *mem = i915->mm.regions[i];
+   u64 region_size, io_size;
+
+   if (!mem)
+   continue;
+
+   region_size = resource_size(>region) >> 20;
+   io_size = resource_size(>io) >> 20;
+
+   if (resource_size(>io))
+   drm_dbg(>drm, "Memory region(%d): %s: %llu MiB 
%pR, io: %llu MiB %pR\n",
+   mem->id, mem->name, region_size, >region, 
io_size, >io);
+   else
+   drm_dbg(>drm, "Memory region(%d): %s: %llu MiB 
%pR, io: n/a\n",
+   mem->id, mem->name, region_size, >region);
+   }
+
return 0;
 
 out_cleanup:
-- 
2.41.0

[PATCH v2 01/15] drm/i915: Use struct resource for memory region IO as well

[Ville Syrjala]

From: Ville Syrjälä 

mem->region is a struct resource, but mem->io_start and
mem->io_size are not for whatever reason. Let's unify this
and convert the io stuff into a struct resource as well.
Should make life a little less annoying when you don't have
juggle between two different approaches all the time.

Mostly done using cocci (with manual tweaks at all the
places where we mutate io_size by hand):
@@
struct intel_memory_region *M;
expression START, SIZE;
@@
- M->io_start = START;
- M->io_size = SIZE;
+ M->io = DEFINE_RES_MEM(START, SIZE);

@@
struct intel_memory_region *M;
@@
- M->io_start
+ M->io.start

@@
struct intel_memory_region M;
@@
- M.io_start
+ M.io.start

@@
expression M;
@@
- M->io_size
+ resource_size(>io)

@@
expression M;
@@
- M.io_size
+ resource_size()

Cc: Paz Zcharya 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_fbdev_fb.c  |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_region.c |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 17 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c|  8 
 .../gpu/drm/i915/gem/selftests/i915_gem_mman.c | 18 +-
 drivers/gpu/drm/i915/gt/intel_region_lmem.c| 11 +++
 drivers/gpu/drm/i915/gt/selftest_tlb.c |  4 ++--
 drivers/gpu/drm/i915/i915_gpu_error.c  |  2 +-
 drivers/gpu/drm/i915/i915_query.c  |  2 +-
 drivers/gpu/drm/i915/intel_memory_region.c | 15 +++
 drivers/gpu/drm/i915/intel_memory_region.h |  3 +--
 drivers/gpu/drm/i915/intel_region_ttm.c|  8 
 .../drm/i915/selftests/intel_memory_region.c   |  4 ++--
 13 files changed, 45 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev_fb.c 
b/drivers/gpu/drm/i915/display/intel_fbdev_fb.c
index 717c3a3237c4..1ac05d90b2e8 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev_fb.c
@@ -78,7 +78,7 @@ int intel_fbdev_fb_fill_info(struct drm_i915_private *i915, 
struct fb_info *info
 
/* Use fbdev's framebuffer from lmem for discrete */
info->fix.smem_start =
-   (unsigned long)(mem->io_start +
+   (unsigned long)(mem->io.start +
i915_gem_object_get_dma_address(obj, 
0));
info->fix.smem_len = obj->base.size;
} else {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c 
b/drivers/gpu/drm/i915/gem/i915_gem_region.c
index a4fb577eceb4..b09b74a2448b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
@@ -129,7 +129,7 @@ i915_gem_object_create_region_at(struct intel_memory_region 
*mem,
return ERR_PTR(-EINVAL);
 
if (!(flags & I915_BO_ALLOC_GPU_ONLY) &&
-   offset + size > mem->io_size &&
+   offset + size > resource_size(>io) &&
!i915_ggtt_has_aperture(to_gt(mem->i915)->ggtt))
return ERR_PTR(-ENOSPC);
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 8c88075eeab2..d2440c793f84 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -541,7 +541,9 @@ static int i915_gem_init_stolen(struct intel_memory_region 
*mem)
 
/* Exclude the reserved region from driver use */
mem->region.end = i915->dsm.reserved.start - 1;
-   mem->io_size = min(mem->io_size, resource_size(>region));
+   mem->io = DEFINE_RES_MEM(mem->io.start,
+min(resource_size(>io),
+resource_size(>region)));
 
i915->dsm.usable_size = resource_size(>region);
 
@@ -752,7 +754,7 @@ static int _i915_gem_object_stolen_init(struct 
intel_memory_region *mem,
 * With discrete devices, where we lack a mappable aperture there is no
 * possible way to ever access this memory on the CPU side.
 */
-   if (mem->type == INTEL_MEMORY_STOLEN_LOCAL && !mem->io_size &&
+   if (mem->type == INTEL_MEMORY_STOLEN_LOCAL && !resource_size(>io) 
&&
!(flags & I915_BO_ALLOC_GPU_ONLY))
return -ENOSPC;
 
@@ -838,13 +840,12 @@ static int init_stolen_lmem(struct intel_memory_region 
*mem)
return 0;
}
 
-   if (mem->io_size &&
-   !io_mapping_init_wc(>iomap, mem->io_start, mem->io_size))
+   if (resource_size(>io) &&
+   !io_mapping_init_wc(>iomap, mem->io.start, 
resource_size(>io)))
goto err_cleanup;
 
-   drm_dbg(>drm, "Stolen Local memory IO start: %pa\n",
-   >io_start);
-   drm_dbg(>drm, "Stolen Local DSM base: %pa\n", >region.start);
+   drm_dbg(>drm, "Stolen Local DSM: %pR\n", >region);
+   drm_dbg(>drm, "Stolen Local memory IO: %pR\n", >io);
 
return 0;
 
@@ -855,7 +856,7 @@ static int 

[PATCH v2 00/15] drm/i915: (stolen) memory region related fixes

[Ville Syrjala]

From: Ville Syrjälä 

Attempt to fix the mess around stolen memory, especially on MTL
with it's special (and apparenly broken) not-actually-lmem stolen.

The series is made up of roughtly three parts:
1. General refactoring/debug improvement for mem regions
2. Deal with the broken BAR stuff on MTL
3. Fix initial display plane readout for MTL

v2: Try to relocate the BIOS fb to start of ggtt to make
space for the GuC stuff at the top end of ggtt

Cc: Paz Zcharya 

Ville Syrjälä (15):
  drm/i915: Use struct resource for memory region IO as well
  drm/i915: Print memory region info during probe
  drm/i915: Remove ad-hoc lmem/stolen debugs
  drm/i915: Bypass LMEMBAR/GTTMMADR for MTL stolen memory access
  drm/i915: Disable the "binder"
  drm/i915: Rename the DSM/GSM registers
  drm/i915: Fix PTE decode during initial plane readout
  drm/i915: Fix region start during initial plane readout
  drm/i915: Fix MTL initial plane readout
  drm/i915: s/phys_base/dma_addr/
  drm/i915: Split the smem and lmem plane readout apart
  drm/i915: Simplify intel_initial_plane_config() calling convention
  drm/i915/fbdev: Fix smem_start for LMEMBAR stolen objects
  drm/i915: Tweak BIOS fb reuse check
  drm/i915: Try to relocate the BIOS fb to the start of ggtt

 drivers/gpu/drm/i915/display/i9xx_plane.c |  30 +++
 drivers/gpu/drm/i915/display/i9xx_plane.h |   7 +
 drivers/gpu/drm/i915/display/intel_display.c  |   5 +
 .../gpu/drm/i915/display/intel_display_core.h |   2 +
 .../drm/i915/display/intel_display_driver.c   |   7 +-
 .../drm/i915/display/intel_display_types.h|   2 +
 drivers/gpu/drm/i915/display/intel_fbdev_fb.c |   5 +-
 .../drm/i915/display/intel_plane_initial.c| 252 +-
 .../drm/i915/display/intel_plane_initial.h|   4 +-
 .../drm/i915/display/skl_universal_plane.c|  28 ++
 .../drm/i915/display/skl_universal_plane.h|   2 +
 drivers/gpu/drm/i915/gem/i915_gem_region.c|   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c|  30 ++-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |   8 +-
 .../drm/i915/gem/selftests/i915_gem_mman.c|  18 +-
 drivers/gpu/drm/i915/gt/intel_ggtt.c  |  13 +-
 drivers/gpu/drm/i915/gt/intel_gtt.c   |   2 +-
 drivers/gpu/drm/i915/gt/intel_region_lmem.c   |  14 +-
 drivers/gpu/drm/i915/gt/selftest_tlb.c|   4 +-
 drivers/gpu/drm/i915/i915_gpu_error.c |   2 +-
 drivers/gpu/drm/i915/i915_query.c |   2 +-
 drivers/gpu/drm/i915/i915_reg.h   |   7 +-
 drivers/gpu/drm/i915/intel_memory_region.c|  33 ++-
 drivers/gpu/drm/i915/intel_memory_region.h|   3 +-
 drivers/gpu/drm/i915/intel_region_ttm.c   |   8 +-
 .../drm/i915/selftests/intel_memory_region.c  |   4 +-
 26 files changed, 354 insertions(+), 140 deletions(-)

-- 
2.41.0

RE: ✗ Fi.CI.BAT: failure for drm/edid: prefer forward declarations over includes in drm_edid.h

[Illipilli, TejasreeX]

Hi,

https://patchwork.freedesktop.org/series/127695/ - Re-reported.

Thanks,
Tejasree

-Original Message-
From: I915-ci-infra  On Behalf Of 
Jani Nikula
Sent: Friday, December 15, 2023 2:23 PM
To: i915-ci-in...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: ✗ Fi.CI.BAT: failure for drm/edid: prefer forward declarations 
over includes in drm_edid.h

On Tue, 12 Dec 2023, Patchwork  wrote:
> == Series Details ==
>
> Series: drm/edid: prefer forward declarations over includes in drm_edid.h
> URL   : https://patchwork.freedesktop.org/series/127695/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_14010 -> Patchwork_127695v1 
> 
>
> Summary
> ---
>
>   **FAILURE**
>
>   Serious unknown changes coming with Patchwork_127695v1 absolutely need to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_127695v1, please notify your bug team 
> (i915-ci-in...@lists.freedesktop.org) 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_127695v1/index.html
>
> Participating hosts (31 -> 34)
> --
>
>   Additional (4): bat-kbl-2 bat-dg2-9 bat-mtlp-8 fi-pnv-d510 
>   Missing(1): fi-snb-2520m 
>
> Possible new issues
> ---
>
>   Here are the unknown changes that may have been introduced in 
> Patchwork_127695v1:
>
> ### IGT changes ###
>
>  Possible regressions 
>
>   * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
> - bat-adlp-11:[PASS][1] -> [SKIP][2] +5 other tests skip
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/bat-adlp-11/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-adlp-1
> 1/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
>
>   * igt@kms_pipe_crc_basic@read-crc:
> - bat-adlp-11:NOTRUN -> [SKIP][3] +8 other tests skip
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-adlp-1
> 1/igt@kms_pipe_crc_ba...@read-crc.html

Unrelated, please re-report.

Also, how about putting i915-ci-in...@lists.freedesktop.org in the
Reply-to: header of the mails, so there's no need to copy-paste that from the 
message body, please?

Better yet, how about adding a button next to "test revision 1 again" in the 
web UI to "re-report", please?


BR,
Jani.



>
>   
>  Warnings 
>
>   * igt@kms_dsc@dsc-basic:
> - bat-adlp-11:[SKIP][4] ([i915#3555] / [i915#3840]) -> [SKIP][5]
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/bat-adlp-11/igt@kms_...@dsc-basic.html
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-adlp-1
> 1/igt@kms_...@dsc-basic.html
>
>   
> Known issues
> 
>
>   Here are the changes found in Patchwork_127695v1 that come from known 
> issues:
>
> ### IGT changes ###
>
>  Issues hit 
>
>   * igt@debugfs_test@basic-hwmon:
> - bat-mtlp-8: NOTRUN -> [SKIP][6] ([i915#9318])
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-mtlp-8
> /igt@debugfs_t...@basic-hwmon.html
>
>   * igt@fbdev@info:
> - bat-adlp-11:[PASS][7] -> [SKIP][8] ([i915#1849] / [i915#2582])
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/bat-adlp-11/igt@fb...@info.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-adlp-11/igt@fb...@info.html
> - bat-kbl-2:  NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#1849])
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-kbl-2/
> igt@fb...@info.html
>
>   * igt@fbdev@nullptr:
> - bat-adlp-11:[PASS][10] -> [SKIP][11] ([i915#2582]) +3 other 
> tests skip
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/bat-adlp-11/igt@fb...@nullptr.html
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-adlp-1
> 1/igt@fb...@nullptr.html
>
>   * igt@gem_lmem_swapping@basic:
> - fi-pnv-d510:NOTRUN -> [SKIP][12] ([fdo#109271]) +28 other tests 
> skip
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/fi-pnv-d51
> 0/igt@gem_lmem_swapp...@basic.html
>
>   * igt@gem_lmem_swapping@parallel-random-engines:
> - bat-kbl-2:  NOTRUN -> [SKIP][13] ([fdo#109271]) +36 other tests 
> skip
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-kbl-2/
> igt@gem_lmem_swapp...@parallel-random-engines.html
>
>   * igt@gem_lmem_swapping@verify-random:
> - bat-adlp-11:NOTRUN -> [SKIP][14] ([i915#4613]) +3 other tests 
> skip
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-adlp-11/igt@gem_lmem_swapp...@verify-random.html
> - bat-mtlp-8: NOTRUN -> 

✓ Fi.CI.BAT: success for drm/edid: prefer forward declarations over includes in drm_edid.h

[Patchwork]

== Series Details ==

Series: drm/edid: prefer forward declarations over includes in drm_edid.h
URL   : https://patchwork.freedesktop.org/series/127695/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_14010 -> Patchwork_127695v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (31 -> 34)
--

  Additional (4): bat-kbl-2 bat-dg2-9 bat-mtlp-8 fi-pnv-d510 
  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@fbdev@info:
- bat-adlp-11:[PASS][2] -> [SKIP][3] ([i915#1849] / [i915#2582])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/bat-adlp-11/igt@fb...@info.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-adlp-11/igt@fb...@info.html
- bat-kbl-2:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1849])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-kbl-2/igt@fb...@info.html

  * igt@fbdev@nullptr:
- bat-adlp-11:[PASS][5] -> [SKIP][6] ([i915#2582]) +3 other tests 
skip
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/bat-adlp-11/igt@fb...@nullptr.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-adlp-11/igt@fb...@nullptr.html

  * igt@gem_lmem_swapping@basic:
- fi-pnv-d510:NOTRUN -> [SKIP][7] ([fdo#109271]) +28 other tests 
skip
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/fi-pnv-d510/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- bat-kbl-2:  NOTRUN -> [SKIP][8] ([fdo#109271]) +36 other tests 
skip
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-kbl-2/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_lmem_swapping@verify-random:
- bat-adlp-11:NOTRUN -> [SKIP][9] ([i915#4613]) +3 other tests skip
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-adlp-11/igt@gem_lmem_swapp...@verify-random.html
- bat-mtlp-8: NOTRUN -> [SKIP][10] ([i915#4613]) +3 other tests skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-mtlp-8/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_mmap@basic:
- bat-dg2-9:  NOTRUN -> [SKIP][11] ([i915#4083])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-dg2-9/igt@gem_m...@basic.html
- bat-mtlp-8: NOTRUN -> [SKIP][12] ([i915#4083])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-mtlp-8/igt@gem_m...@basic.html

  * igt@gem_mmap_gtt@basic:
- bat-dg2-9:  NOTRUN -> [SKIP][13] ([i915#4077]) +2 other tests skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-dg2-9/igt@gem_mmap_...@basic.html
- bat-mtlp-8: NOTRUN -> [SKIP][14] ([i915#4077]) +2 other tests skip
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-mtlp-8/igt@gem_mmap_...@basic.html

  * igt@gem_render_tiled_blits@basic:
- bat-dg2-9:  NOTRUN -> [SKIP][15] ([i915#4079]) +1 other test skip
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-dg2-9/igt@gem_render_tiled_bl...@basic.html
- bat-mtlp-8: NOTRUN -> [SKIP][16] ([i915#4079]) +1 other test skip
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-mtlp-8/igt@gem_render_tiled_bl...@basic.html

  * igt@i915_pm_rps@basic-api:
- bat-dg2-9:  NOTRUN -> [SKIP][17] ([i915#6621])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-dg2-9/igt@i915_pm_...@basic-api.html
- bat-adlp-11:NOTRUN -> [SKIP][18] ([i915#6621])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-adlp-11/igt@i915_pm_...@basic-api.html
- bat-mtlp-8: NOTRUN -> [SKIP][19] ([i915#6621])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-mtlp-8/igt@i915_pm_...@basic-api.html

  * igt@i915_selftest@live@gt_mocs:
- bat-mtlp-6: [PASS][20] -> [DMESG-WARN][21] ([i915#9715])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/bat-mtlp-6/igt@i915_selftest@live@gt_mocs.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-mtlp-6/igt@i915_selftest@live@gt_mocs.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-mtlp-8: NOTRUN -> [SKIP][22] ([i915#6645])
   [22]: 

Re: [PATCH 04/12] drm/i915: Bypass LMEMBAR/GTTMMADR for MTL stolen memory access

[Ville Syrjälä]

On Thu, Dec 14, 2023 at 09:06:03PM +, Sripada, Radhakrishna wrote:
> HI Ville,
> 
> > -Original Message-
> > From: Ville Syrjälä 
> > Sent: Wednesday, December 13, 2023 6:03 PM
> > To: Sripada, Radhakrishna 
> > Cc: Joonas Lahtinen ; Das, Nirmoy
> > ; intel-gfx@lists.freedesktop.org
> > Subject: Re: [PATCH 04/12] drm/i915: Bypass LMEMBAR/GTTMMADR for MTL
> > stolen memory access
> > 
> > On Wed, Dec 13, 2023 at 08:18:15PM +, Sripada, Radhakrishna wrote:
> > > Hi Ville,
> > >
> > > +Nirmoy
> > >
> > > > -Original Message-
> > > > From: Ville Syrjälä 
> > > > Sent: Wednesday, December 13, 2023 1:30 AM
> > > > To: Joonas Lahtinen 
> > > > Cc: intel-gfx@lists.freedesktop.org; Sripada, Radhakrishna
> > > > 
> > > > Subject: Re: [PATCH 04/12] drm/i915: Bypass LMEMBAR/GTTMMADR for MTL
> > > > stolen memory access
> > > >
> > > > On Wed, Dec 13, 2023 at 11:09:38AM +0200, Joonas Lahtinen wrote:
> > > > > Quoting Ville Syrjala (2023-12-13 02:42:29)
> > > > > > From: Ville Syrjälä 
> > > > > >
> > > > > > On MTL accessing stolen memory via the BARs is somehow borked,
> > > > > > and it can hang the machine. As a workaround let's bypass the
> > > > > > BARs and just go straight to DSMBASE/GSMBASE instead.
> > > > > >
> > > > > > Note that on every other platform this itself would hang the
> > > > > > machine, but on MTL the system firmware is expected to relax
> > > > > > the access permission guarding stolen memory to enable this
> > > > > > workaround, and thus direct CPU accesses should be fine.
> > > > >
> > > > > Shouldn't this have a proper workaround number assigned?
> > > >
> > > > I think there are various numbers, half of which I couldn't even
> > > > find in any database, and the other half I couldn't access for
> > > > whatever reason. So dunno what situation really is apart from
> > > > the firmware clearly implemening its part (since I can poke
> > > > DSM/GSM directly without killing the machine).
> > > >
> > > > RK do you know what we should call this?
> > > Nirmoy previously used Wa_22018444074 in [1].
> > >
> > > There were some associated issues Wa_13010847436 and Wa_14019519902
> > > which Nirmoy quoted in [2].
> > >
> > > Wa_22018529850 is derived from Wa_22018444074, is targeting the latest Gop
> > > driver change which is installed in bat-mtlp-8 hopefully it should help 
> > > debug the
> > issue further.
> > >
> > >
> > > Regarding the patch itself,
> > > Do we need to carve out the range from e820 the area around DSM if we can
> > directly access the range from CPU
> > > without the bar?
> > 
> > IIRC we dropped the early quirks on new platforms under the
> > assumption that the BIOS no longer forgets to mark the DSM
> > as not-RAM/whatever. I don't think anything should change
> > there even when we are allowed direct CPU access.
> > 
> > But I don't recall if I double checked the e820 listing on
> > the MTL I was using. I was able to direct access to both DSM
> > and GSM for sure, and the address the GOP handed over to efifb
> > also pointed directly to DSM.
> 
> Up until adl-p/rpl, the PCI config space had the mirror registers for the 
> stolen memory
> base and size, since the stolen meory is carved out of the available physical 
> ram. Starting MTL
> this was removed from pci config space due to the introduction of stolen lmem 
> which should not
> be cpu addressable aperture.
> 
> With the new gop driver allocating the FB memory in dram, should the e820 
> mark the FB area
> as reserved for the system use? Do we still preserve the efifb after doing a 
> memtest before loading the driver?

While the LMEMBAR is a new thing, nothing else should really 
have changed in the way the BIOS carves out the DSM/GSM
from physical RAM.

On one MTL I see:
[0.000896] e820: update [mem 0x7a00-0x] usable ==> reserved
[0.036542] [mem 0x7e80-0xfed1] available for PCI devices
[i915]] Memory region(6): stolen-local: 60 MiB [mem 0x0080-0x043f], io: 
60 MiB [mem 0x7a80-0x7e3f]

So we have
 0x7a00-0x7a80 GSM
 0x7a80-0x7e40 DSM
both are marked as reserved and neither overlaps with that
PCI window. So looks all right to me.

We should probably also dump the GSM range to dmesg just to
have all the information available in one place...

> 
> Thanks,
> Radhakrishna(RK) Sripada 
> > 
> > >
> > >
> > > Thanks,
> > > Radhakrishna(RK) Sripada
> > > 1. https://patchwork.freedesktop.org/series/120683/
> > > 2. https://patchwork.freedesktop.org/series/123329/
> > >
> > > >
> > > > >
> > > > > Regards, Joonas
> > > > >
> > > > > >
> > > > > > Signed-off-by: Ville Syrjälä 
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 11 ++-
> > > > > >  drivers/gpu/drm/i915/gt/intel_ggtt.c   | 13 -
> > > > > >  2 files changed, 22 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> > > > b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> > > > > > 

Re: [PATCH v3 0/9] drm/i915: Replace kmap_atomic() with kmap_local_page()

[Tvrtko Ursulin]

On 14/12/2023 15:04, Zhao Liu wrote:

On Thu, Dec 14, 2023 at 02:35:26PM +, Tvrtko Ursulin wrote:

Date: Thu, 14 Dec 2023 14:35:26 +
From: Tvrtko Ursulin 
Subject: Re: [PATCH v3 0/9] drm/i915: Replace kmap_atomic() with
  kmap_local_page()


On 14/12/2023 13:45, Tvrtko Ursulin wrote:


Hi Zhao,

On 14/12/2023 13:19, Zhao Liu wrote:

Hi maintainers,

Just kindly ping.
May I ask if this refresh version could be merged into the next tree of
the i915?


I certainly spotted your series last week or so but then it slipped my
mind to go through it. Should be able to go through it today or
tomorrow.


It all looks good to me. I only needed to queue a re-test in our CI since v3
failed BAT, but pretty sure it wasn't at fault. Once I am satisfied with the
results I will merge the series. Thanks for the cleanups and your patience!

Regards,

Tvrtko



Thanks for your review!


Pushed to drm-intel-gt-next, thanks again!

Regards,

Tvrtko

RE: ✗ Fi.CI.BAT: failure for drm/edid: prefer forward declarations over includes in drm_edid.h

[Musial, Ewelina]

Hi Jani,

I believe that re-reporting should be an exception, not a regular activity. 
Currently we do have delays in bug filing and multiple regressions active but 
in general, we should work to have stable environment and reduce need of 
re-report and then, information in results email about our mailing list should 
be enough. "Test revision again" is releasing new rev and it is totally new 
builds to be added to queue and everything is handled by automation. 
Rereporting require manual review of bugs by someone from bug filing, 
submitting bugs for not covered failures and then manual re-report so it cannot 
be done via one button and sending such request via email makes submitters more 
aware of the impact.

Regards,
Ewelina 

-Original Message-
From: I915-ci-infra  On Behalf Of 
Jani Nikula
Sent: Friday, December 15, 2023 9:53 AM
To: i915-ci-in...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: ✗ Fi.CI.BAT: failure for drm/edid: prefer forward declarations 
over includes in drm_edid.h

On Tue, 12 Dec 2023, Patchwork  wrote:
> == Series Details ==
>
> Series: drm/edid: prefer forward declarations over includes in drm_edid.h
> URL   : https://patchwork.freedesktop.org/series/127695/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_14010 -> Patchwork_127695v1 
> 
>
> Summary
> ---
>
>   **FAILURE**
>
>   Serious unknown changes coming with Patchwork_127695v1 absolutely need to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_127695v1, please notify your bug team 
> (i915-ci-in...@lists.freedesktop.org) 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_127695v1/index.html
>
> Participating hosts (31 -> 34)
> --
>
>   Additional (4): bat-kbl-2 bat-dg2-9 bat-mtlp-8 fi-pnv-d510 
>   Missing(1): fi-snb-2520m 
>
> Possible new issues
> ---
>
>   Here are the unknown changes that may have been introduced in 
> Patchwork_127695v1:
>
> ### IGT changes ###
>
>  Possible regressions 
>
>   * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
> - bat-adlp-11:[PASS][1] -> [SKIP][2] +5 other tests skip
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/bat-adlp-11/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-adlp-1
> 1/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
>
>   * igt@kms_pipe_crc_basic@read-crc:
> - bat-adlp-11:NOTRUN -> [SKIP][3] +8 other tests skip
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-adlp-1
> 1/igt@kms_pipe_crc_ba...@read-crc.html

Unrelated, please re-report.

Also, how about putting i915-ci-in...@lists.freedesktop.org in the
Reply-to: header of the mails, so there's no need to copy-paste that from the 
message body, please?

Better yet, how about adding a button next to "test revision 1 again" in the 
web UI to "re-report", please?


BR,
Jani.



>
>   
>  Warnings 
>
>   * igt@kms_dsc@dsc-basic:
> - bat-adlp-11:[SKIP][4] ([i915#3555] / [i915#3840]) -> [SKIP][5]
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/bat-adlp-11/igt@kms_...@dsc-basic.html
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-adlp-1
> 1/igt@kms_...@dsc-basic.html
>
>   
> Known issues
> 
>
>   Here are the changes found in Patchwork_127695v1 that come from known 
> issues:
>
> ### IGT changes ###
>
>  Issues hit 
>
>   * igt@debugfs_test@basic-hwmon:
> - bat-mtlp-8: NOTRUN -> [SKIP][6] ([i915#9318])
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-mtlp-8
> /igt@debugfs_t...@basic-hwmon.html
>
>   * igt@fbdev@info:
> - bat-adlp-11:[PASS][7] -> [SKIP][8] ([i915#1849] / [i915#2582])
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/bat-adlp-11/igt@fb...@info.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-adlp-11/igt@fb...@info.html
> - bat-kbl-2:  NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#1849])
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-kbl-2/
> igt@fb...@info.html
>
>   * igt@fbdev@nullptr:
> - bat-adlp-11:[PASS][10] -> [SKIP][11] ([i915#2582]) +3 other 
> tests skip
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/bat-adlp-11/igt@fb...@nullptr.html
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-adlp-1
> 1/igt@fb...@nullptr.html
>
>   * igt@gem_lmem_swapping@basic:
> - fi-pnv-d510:NOTRUN -> [SKIP][12] ([fdo#109271]) +28 other tests 
> skip
>[12]: 
> 

Re: [PATCH] drm/i915/display: C20 clock state verification

[Imre Deak]

On Fri, Dec 15, 2023 at 11:10:52AM +0200, Ville Syrjälä wrote:
> On Fri, Dec 15, 2023 at 10:53:31AM +0200, Imre Deak wrote:
> > On Fri, Dec 15, 2023 at 10:00:57AM +0200, Mika Kahola wrote:
> > > Add clock state verification for C20. Since we
> > > are usign either A or B contexts, which are
> > > selected based on clock rate, we first need to
> > > calculate hw clock and use that clock to select
> > > which context we are using.
> > 
> > Could the description be clearer that the patch _fixes_ the context
> > selection? (Also the subject line should always say _what_ the patch
> > does.)
> > 
> > > 
> > > Signed-off-by: Mika Kahola 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_cx0_phy.c | 8 +++-
> > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
> > > b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > index 775c1c4a8978..6757e9f941e4 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > @@ -3079,8 +3079,9 @@ static void intel_c20pll_state_verify(const struct 
> > > intel_crtc_state *state,
> > >   const struct intel_c20pll_state *mpll_sw_state = 
> > > >cx0pll_state.c20;
> > >   bool use_mplla;
> > >   int i;
> > > + int hw_clock = intel_c20pll_calc_port_clock(encoder, mpll_hw_state);
> > >  
> > > - use_mplla = intel_c20_use_mplla(mpll_hw_state->clock);
> > > + use_mplla = intel_c20_use_mplla(hw_clock);
> > 
> > It's mpll_hw_state->tx[0] C20_PHY_USE_MPLLB which tells the HW which
> > context to use, so I think it's better to use the same condition here.
> 
> Yes, one should never assume anything about how the register values
> were calculated/etc. That would pretty much defeat the whole purpose
> of doing readout and state check.
> 
> BTW I don't see even being set anywhere C20_PHY_USE_MPLLB.
> Do we not use it or is it encoded in that ugly hex soup in
> intel_c20_compute_hdmi_tmds_pll()? 

Yes, the pll_state->tx[0] line there. For DP, it's in the
intel_c20pll_state predefined tables.

> Instead of repeating the mistakes of the VLV PHY code someone should
> convert that into human readable form...
> 
> > 
> > >   if (use_mplla) {
> > >   for (i = 0; i < ARRAY_SIZE(mpll_sw_state->mplla); i++) {
> > >   I915_STATE_WARN(i915, mpll_hw_state->mplla[i] != 
> > > mpll_sw_state->mplla[i],
> > > @@ -3110,6 +3111,11 @@ static void intel_c20pll_state_verify(const struct 
> > > intel_crtc_state *state,
> > >   crtc->base.base.id, crtc->base.name, i,
> > >   mpll_sw_state->cmn[i], mpll_hw_state->cmn[i]);
> > >   }
> > > +
> > > + I915_STATE_WARN(i915, hw_clock != mpll_sw_state->clock,
> > > + "[CRTC:%d:%s] mismatch in C20: Register CLOCK (expected 
> > > %d, found %d)",
> > > + crtc->base.base.id, crtc->base.name,
> > > + mpll_sw_state->clock, hw_clock);
> > 
> > I think the intel_crtc_state::port_clock SW/HW state verification is
> > equivalent to the above, but it's good to verify it here as well. I
> > would store hw_clock to mpll_hw_state->clock in
> > intel_c20pll_readout_hw_state() though.
> > 
> > >  }
> > >  
> > >  void intel_cx0pll_state_verify(struct intel_atomic_state *state,
> > > -- 
> > > 2.34.1
> > > 
> 
> -- 
> Ville Syrjälä
> Intel

Re: [PATCH] drm/i915/display: C20 clock state verification

[Ville Syrjälä]

On Fri, Dec 15, 2023 at 10:53:31AM +0200, Imre Deak wrote:
> On Fri, Dec 15, 2023 at 10:00:57AM +0200, Mika Kahola wrote:
> > Add clock state verification for C20. Since we
> > are usign either A or B contexts, which are
> > selected based on clock rate, we first need to
> > calculate hw clock and use that clock to select
> > which context we are using.
> 
> Could the description be clearer that the patch _fixes_ the context
> selection? (Also the subject line should always say _what_ the patch
> does.)
> 
> > 
> > Signed-off-by: Mika Kahola 
> > ---
> >  drivers/gpu/drm/i915/display/intel_cx0_phy.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
> > b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > index 775c1c4a8978..6757e9f941e4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > @@ -3079,8 +3079,9 @@ static void intel_c20pll_state_verify(const struct 
> > intel_crtc_state *state,
> > const struct intel_c20pll_state *mpll_sw_state = 
> > >cx0pll_state.c20;
> > bool use_mplla;
> > int i;
> > +   int hw_clock = intel_c20pll_calc_port_clock(encoder, mpll_hw_state);
> >  
> > -   use_mplla = intel_c20_use_mplla(mpll_hw_state->clock);
> > +   use_mplla = intel_c20_use_mplla(hw_clock);
> 
> It's mpll_hw_state->tx[0] C20_PHY_USE_MPLLB which tells the HW which
> context to use, so I think it's better to use the same condition here.

Yes, one should never assume anything about how the register values
were calculated/etc. That would pretty much defeat the whole purpose
of doing readout and state check.

BTW I don't see even being set anywhere C20_PHY_USE_MPLLB.
Do we not use it or is it encoded in that ugly hex soup in
intel_c20_compute_hdmi_tmds_pll()? Instead of repeating the
mistakes of the VLV PHY code someone should convert that into
human readable form...

> 
> > if (use_mplla) {
> > for (i = 0; i < ARRAY_SIZE(mpll_sw_state->mplla); i++) {
> > I915_STATE_WARN(i915, mpll_hw_state->mplla[i] != 
> > mpll_sw_state->mplla[i],
> > @@ -3110,6 +3111,11 @@ static void intel_c20pll_state_verify(const struct 
> > intel_crtc_state *state,
> > crtc->base.base.id, crtc->base.name, i,
> > mpll_sw_state->cmn[i], mpll_hw_state->cmn[i]);
> > }
> > +
> > +   I915_STATE_WARN(i915, hw_clock != mpll_sw_state->clock,
> > +   "[CRTC:%d:%s] mismatch in C20: Register CLOCK (expected 
> > %d, found %d)",
> > +   crtc->base.base.id, crtc->base.name,
> > +   mpll_sw_state->clock, hw_clock);
> 
> I think the intel_crtc_state::port_clock SW/HW state verification is
> equivalent to the above, but it's good to verify it here as well. I
> would store hw_clock to mpll_hw_state->clock in
> intel_c20pll_readout_hw_state() though.
> 
> >  }
> >  
> >  void intel_cx0pll_state_verify(struct intel_atomic_state *state,
> > -- 
> > 2.34.1
> > 

-- 
Ville Syrjälä
Intel

Re: [PATCH] drm/i915/display: C20 clock state verification

[Imre Deak]

On Fri, Dec 15, 2023 at 10:53:36AM +0200, Imre Deak wrote:
> On Fri, Dec 15, 2023 at 10:00:57AM +0200, Mika Kahola wrote:
> > Add clock state verification for C20. Since we
> > are usign either A or B contexts, which are
> > selected based on clock rate, we first need to
> > calculate hw clock and use that clock to select
> > which context we are using.
> 
> Could the description be clearer that the patch _fixes_ the context
> selection? (Also the subject line should always say _what_ the patch
> does.)
> 
> > 
> > Signed-off-by: Mika Kahola 
> > ---
> >  drivers/gpu/drm/i915/display/intel_cx0_phy.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
> > b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > index 775c1c4a8978..6757e9f941e4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > @@ -3079,8 +3079,9 @@ static void intel_c20pll_state_verify(const struct 
> > intel_crtc_state *state,
> > const struct intel_c20pll_state *mpll_sw_state = 
> > >cx0pll_state.c20;
> > bool use_mplla;
> > int i;
> > +   int hw_clock = intel_c20pll_calc_port_clock(encoder, mpll_hw_state);
> >  
> > -   use_mplla = intel_c20_use_mplla(mpll_hw_state->clock);
> > +   use_mplla = intel_c20_use_mplla(hw_clock);
> 
> It's mpll_hw_state->tx[0] C20_PHY_USE_MPLLB which tells the HW which
> context to use, so I think it's better to use the same condition here.

You could also add a check intel_c20_use_mplla(clock) matches the above
flag.

> 
> > if (use_mplla) {
> > for (i = 0; i < ARRAY_SIZE(mpll_sw_state->mplla); i++) {
> > I915_STATE_WARN(i915, mpll_hw_state->mplla[i] != 
> > mpll_sw_state->mplla[i],
> > @@ -3110,6 +3111,11 @@ static void intel_c20pll_state_verify(const struct 
> > intel_crtc_state *state,
> > crtc->base.base.id, crtc->base.name, i,
> > mpll_sw_state->cmn[i], mpll_hw_state->cmn[i]);
> > }
> > +
> > +   I915_STATE_WARN(i915, hw_clock != mpll_sw_state->clock,
> > +   "[CRTC:%d:%s] mismatch in C20: Register CLOCK (expected 
> > %d, found %d)",
> > +   crtc->base.base.id, crtc->base.name,
> > +   mpll_sw_state->clock, hw_clock);
> 
> I think the intel_crtc_state::port_clock SW/HW state verification is
> equivalent to the above, but it's good to verify it here as well. I
> would store hw_clock to mpll_hw_state->clock in
> intel_c20pll_readout_hw_state() though.
> 
> >  }
> >  
> >  void intel_cx0pll_state_verify(struct intel_atomic_state *state,
> > -- 
> > 2.34.1
> > 

Re: [PATCH] drm/i915/display: C20 clock state verification

[Imre Deak]

On Fri, Dec 15, 2023 at 10:00:57AM +0200, Mika Kahola wrote:
> Add clock state verification for C20. Since we
> are usign either A or B contexts, which are
> selected based on clock rate, we first need to
> calculate hw clock and use that clock to select
> which context we are using.

Could the description be clearer that the patch _fixes_ the context
selection? (Also the subject line should always say _what_ the patch
does.)

> 
> Signed-off-by: Mika Kahola 
> ---
>  drivers/gpu/drm/i915/display/intel_cx0_phy.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index 775c1c4a8978..6757e9f941e4 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -3079,8 +3079,9 @@ static void intel_c20pll_state_verify(const struct 
> intel_crtc_state *state,
>   const struct intel_c20pll_state *mpll_sw_state = 
> >cx0pll_state.c20;
>   bool use_mplla;
>   int i;
> + int hw_clock = intel_c20pll_calc_port_clock(encoder, mpll_hw_state);
>  
> - use_mplla = intel_c20_use_mplla(mpll_hw_state->clock);
> + use_mplla = intel_c20_use_mplla(hw_clock);

It's mpll_hw_state->tx[0] C20_PHY_USE_MPLLB which tells the HW which
context to use, so I think it's better to use the same condition here.

>   if (use_mplla) {
>   for (i = 0; i < ARRAY_SIZE(mpll_sw_state->mplla); i++) {
>   I915_STATE_WARN(i915, mpll_hw_state->mplla[i] != 
> mpll_sw_state->mplla[i],
> @@ -3110,6 +3111,11 @@ static void intel_c20pll_state_verify(const struct 
> intel_crtc_state *state,
>   crtc->base.base.id, crtc->base.name, i,
>   mpll_sw_state->cmn[i], mpll_hw_state->cmn[i]);
>   }
> +
> + I915_STATE_WARN(i915, hw_clock != mpll_sw_state->clock,
> + "[CRTC:%d:%s] mismatch in C20: Register CLOCK (expected 
> %d, found %d)",
> + crtc->base.base.id, crtc->base.name,
> + mpll_sw_state->clock, hw_clock);

I think the intel_crtc_state::port_clock SW/HW state verification is
equivalent to the above, but it's good to verify it here as well. I
would store hw_clock to mpll_hw_state->clock in
intel_c20pll_readout_hw_state() though.

>  }
>  
>  void intel_cx0pll_state_verify(struct intel_atomic_state *state,
> -- 
> 2.34.1
> 

Re: ✗ Fi.CI.BAT: failure for drm/edid: prefer forward declarations over includes in drm_edid.h

[Jani Nikula]

On Tue, 12 Dec 2023, Patchwork  wrote:
> == Series Details ==
>
> Series: drm/edid: prefer forward declarations over includes in drm_edid.h
> URL   : https://patchwork.freedesktop.org/series/127695/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_14010 -> Patchwork_127695v1
> 
>
> Summary
> ---
>
>   **FAILURE**
>
>   Serious unknown changes coming with Patchwork_127695v1 absolutely need to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_127695v1, please notify your bug team 
> (i915-ci-in...@lists.freedesktop.org) 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_127695v1/index.html
>
> Participating hosts (31 -> 34)
> --
>
>   Additional (4): bat-kbl-2 bat-dg2-9 bat-mtlp-8 fi-pnv-d510 
>   Missing(1): fi-snb-2520m 
>
> Possible new issues
> ---
>
>   Here are the unknown changes that may have been introduced in 
> Patchwork_127695v1:
>
> ### IGT changes ###
>
>  Possible regressions 
>
>   * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
> - bat-adlp-11:[PASS][1] -> [SKIP][2] +5 other tests skip
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/bat-adlp-11/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-adlp-11/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
>
>   * igt@kms_pipe_crc_basic@read-crc:
> - bat-adlp-11:NOTRUN -> [SKIP][3] +8 other tests skip
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-adlp-11/igt@kms_pipe_crc_ba...@read-crc.html

Unrelated, please re-report.

Also, how about putting i915-ci-in...@lists.freedesktop.org in the
Reply-to: header of the mails, so there's no need to copy-paste that
from the message body, please?

Better yet, how about adding a button next to "test revision 1 again" in
the web UI to "re-report", please?


BR,
Jani.



>
>   
>  Warnings 
>
>   * igt@kms_dsc@dsc-basic:
> - bat-adlp-11:[SKIP][4] ([i915#3555] / [i915#3840]) -> [SKIP][5]
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/bat-adlp-11/igt@kms_...@dsc-basic.html
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-adlp-11/igt@kms_...@dsc-basic.html
>
>   
> Known issues
> 
>
>   Here are the changes found in Patchwork_127695v1 that come from known 
> issues:
>
> ### IGT changes ###
>
>  Issues hit 
>
>   * igt@debugfs_test@basic-hwmon:
> - bat-mtlp-8: NOTRUN -> [SKIP][6] ([i915#9318])
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-mtlp-8/igt@debugfs_t...@basic-hwmon.html
>
>   * igt@fbdev@info:
> - bat-adlp-11:[PASS][7] -> [SKIP][8] ([i915#1849] / [i915#2582])
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/bat-adlp-11/igt@fb...@info.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-adlp-11/igt@fb...@info.html
> - bat-kbl-2:  NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#1849])
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-kbl-2/igt@fb...@info.html
>
>   * igt@fbdev@nullptr:
> - bat-adlp-11:[PASS][10] -> [SKIP][11] ([i915#2582]) +3 other 
> tests skip
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14010/bat-adlp-11/igt@fb...@nullptr.html
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-adlp-11/igt@fb...@nullptr.html
>
>   * igt@gem_lmem_swapping@basic:
> - fi-pnv-d510:NOTRUN -> [SKIP][12] ([fdo#109271]) +28 other tests 
> skip
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/fi-pnv-d510/igt@gem_lmem_swapp...@basic.html
>
>   * igt@gem_lmem_swapping@parallel-random-engines:
> - bat-kbl-2:  NOTRUN -> [SKIP][13] ([fdo#109271]) +36 other tests 
> skip
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-kbl-2/igt@gem_lmem_swapp...@parallel-random-engines.html
>
>   * igt@gem_lmem_swapping@verify-random:
> - bat-adlp-11:NOTRUN -> [SKIP][14] ([i915#4613]) +3 other tests 
> skip
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-adlp-11/igt@gem_lmem_swapp...@verify-random.html
> - bat-mtlp-8: NOTRUN -> [SKIP][15] ([i915#4613]) +3 other tests 
> skip
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-mtlp-8/igt@gem_lmem_swapp...@verify-random.html
>
>   * igt@gem_mmap@basic:
> - bat-dg2-9:  NOTRUN -> [SKIP][16] ([i915#4083])
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127695v1/bat-dg2-9/igt@gem_m...@basic.html
> - bat-mtlp-8: NOTRUN -> 

Re: â Fi.CI.BAT: failure for drm/i915: (stolen) memory region related fixes

[Ville Syrjälä]

On Fri, Dec 15, 2023 at 01:01:39AM +0200, Ville Syrjälä wrote:
> On Thu, Dec 14, 2023 at 12:06:58PM +0100, Andrzej Hajda wrote:
> > 
> > 
> > On 13.12.2023 17:13, Andrzej Hajda wrote:
> > > On 13.12.2023 02:37, Patchwork wrote:
> > >> *Patch Details*
> > >> *Series:*    drm/i915: (stolen) memory region related fixes
> > >> *URL:*    https://patchwork.freedesktop.org/series/127721/ 
> > >> 
> > >> *State:*    failure
> > >> *Details:* 
> > >> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127721v1/index.html 
> > >> 
> > >>
> > >>
> > >>   CI Bug Log - changes from CI_DRM_14010 -> Patchwork_127721v1
> > >>
> > >>
> > >>     Summary
> > >>
> > >> *FAILURE*
> > >>
> > >> Serious unknown changes coming with Patchwork_127721v1 absolutely need 
> > >> to be
> > >> verified manually.
> > >>
> > >> If you think the reported changes have nothing to do with the changes
> > >> introduced in Patchwork_127721v1, please notify your bug team 
> > >> (i915-ci-in...@lists.freedesktop.org) 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_127721v1/index.html
> > >>
> > >>
> > >>     Participating hosts (31 -> 33)
> > >>
> > >> Additional (4): bat-dg2-8 bat-dg2-9 bat-mtlp-8 fi-pnv-d510
> > >> Missing (2): bat-adlp-11 fi-snb-2520m
> > >>
> > >>
> > >>     Possible new issues
> > >>
> > >> Here are the unknown changes that may have been introduced in 
> > >> Patchwork_127721v1:
> > >>
> > >>
> > >>   IGT changes
> > >>
> > >>
> > >>     Possible regressions
> > >>
> > >>   *
> > >>
> > >>     igt@i915_module_load@load:
> > >>
> > >>   o bat-mtlp-8: NOTRUN -> INCOMPLETE
> > >> 
> > >> 
> > > 
> > > 
> > > This is due to overlapping initial fb's vma with GuC reserved area on 
> > > MTL, see ggtt_reserve_guc_top.
> > > 
> > > My dirty quick_fix proposed:
> > > @@ -143,6 +143,9 @@ initial_plane_vma(struct drm_i915_private *i915,
> > >      if (IS_ERR(vma))
> > >      goto err_obj;
> > > 
> > > +   if (base + size > GUC_GGTT_TOP)
> > > +   base = min(base, GUC_GGTT_TOP) - size;
> > > +
> > >      pinctl = PIN_GLOBAL | PIN_OFFSET_FIXED | base;
> > >      if (HAS_GMCH(i915))
> > >      pinctl |= PIN_MAPPABLE;
> > 
> > 
> > Copy/Paste Ville response for this proposition from another thread:
> > 
> > On 13.12.2023 17:03, Ville Syrjälä wrote:
> >  >
> >  > This is not a solution. The correct fix is either:
> >  > 1. fix the guc code to not insist on a fixed chunk of the ggtt
> >  >and instead allocate it normally like a good boy. It could
> >  >still try to allocate as high as possible to ideally
> >  >land in the GUC_GGTT_TOP range
> > 
> > This would be the best solution from initial plane PoV for sure, I am 
> > not sure about GuC PoV.
> 
> I was going to submit a patch to simply change this to insert(PIN_HIGH)
> as that is all that is needed from the GuC FW POV. And whether the
> GOP framebuffer or the GuC FW lives there doesn't matter one bit,
> both fit the bill of not needing to be accessed by the GuC.
> 
> But I suspect this function might be serving a double duty, despite
> not saying so anywhere. Basically I think it's perhaps used as
> a quick and dirty way to restrict everything below GUC_GGTT_TOP,
> presumably because we don't otherwise restrict allocations
> below that even if the GuC needs to access them.
> 
> So the insert(PIN_HIGH) approach could result in some troubles
> iff the GOP framebuffer is preventing the uc_fw to be placed at
> GUC_GGTT_TOP and we later free the GOP framebuffer (happens if
> we find it unsuitable due to one reason or another). This opens
> up a hole above GUC_GGTT_TOP again and something else could
> get bound there.
> 
> Is my assumption about ggtt_reserve_guc_top() correct? And
> if so do we know what are all the things the GuC needs to access
> so that we could properly restrict those below GUC_GGTT_TOP
> and get rid of this weird way of achieving that same result?
> 
> > 
> >  >
> >  > 2. relocate the display vma to a different part of the ggtt
> > 
> > I think this point is what I have proposed.
> > 
> >  >
> >  >
> >  > 1. should be far simpler by the looks of it, as 2. would involve:
> >  > a) pinning the same object into two places in the ggtt simultanously
> >  >I don't think we have support for that except for special ggtt views,
> >  >and xe doesn't have even that (should we need this trick there as 
> > well)
> > 
> > AFAIU the fb is not yet pinned in terms of kernel structures, so it 
> > doesn't seems to be an issue.
> 
> Hmm. Yeah, I suppose we don't really care where in the ggtt the thing
> is bound as we rewrite the PTEs 

[PATCH] drm/i915/display: C20 clock state verification

[Mika Kahola]

Add clock state verification for C20. Since we
are usign either A or B contexts, which are
selected based on clock rate, we first need to
calculate hw clock and use that clock to select
which context we are using.

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 775c1c4a8978..6757e9f941e4 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -3079,8 +3079,9 @@ static void intel_c20pll_state_verify(const struct 
intel_crtc_state *state,
const struct intel_c20pll_state *mpll_sw_state = 
>cx0pll_state.c20;
bool use_mplla;
int i;
+   int hw_clock = intel_c20pll_calc_port_clock(encoder, mpll_hw_state);
 
-   use_mplla = intel_c20_use_mplla(mpll_hw_state->clock);
+   use_mplla = intel_c20_use_mplla(hw_clock);
if (use_mplla) {
for (i = 0; i < ARRAY_SIZE(mpll_sw_state->mplla); i++) {
I915_STATE_WARN(i915, mpll_hw_state->mplla[i] != 
mpll_sw_state->mplla[i],
@@ -3110,6 +3111,11 @@ static void intel_c20pll_state_verify(const struct 
intel_crtc_state *state,
crtc->base.base.id, crtc->base.name, i,
mpll_sw_state->cmn[i], mpll_hw_state->cmn[i]);
}
+
+   I915_STATE_WARN(i915, hw_clock != mpll_sw_state->clock,
+   "[CRTC:%d:%s] mismatch in C20: Register CLOCK (expected 
%d, found %d)",
+   crtc->base.base.id, crtc->base.name,
+   mpll_sw_state->clock, hw_clock);
 }
 
 void intel_cx0pll_state_verify(struct intel_atomic_state *state,
-- 
2.34.1