[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/phy: Quieten state loss across suspend

[Patchwork]

== Series Details ==

Series: drm/i915/phy: Quieten state loss across suspend
URL   : https://patchwork.freedesktop.org/series/83980/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9350_full -> Patchwork_18926_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_eio@kms:
- shard-snb:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-snb4/igt@gem_...@kms.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18926/shard-snb4/igt@gem_...@kms.html

  * igt@gen7_exec_parse@chained-batch:
- shard-hsw:  [PASS][3] -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-hsw6/igt@gen7_exec_pa...@chained-batch.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18926/shard-hsw2/igt@gen7_exec_pa...@chained-batch.html

  
 Warnings 

  * igt@gem_eio@kms:
- shard-hsw:  [INCOMPLETE][5] ([i915#1888] / [i915#2244]) -> 
[TIMEOUT][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-hsw2/igt@gem_...@kms.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18926/shard-hsw1/igt@gem_...@kms.html

  
New tests
-

  New tests have been introduced between CI_DRM_9350_full and 
Patchwork_18926_full:

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

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

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@bcs0:
- shard-kbl:  [PASS][7] -> [DMESG-WARN][8] ([i915#180])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-kbl4/igt@gem_ctx_isolation@preservation...@bcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18926/shard-kbl3/igt@gem_ctx_isolation@preservation...@bcs0.html

  * igt@gem_exec_reloc@basic-many-active@rcs0:
- shard-hsw:  [PASS][9] -> [FAIL][10] ([i915#2389])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-hsw8/igt@gem_exec_reloc@basic-many-act...@rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18926/shard-hsw2/igt@gem_exec_reloc@basic-many-act...@rcs0.html

  * igt@gem_exec_whisper@basic-fds-forked-all:
- shard-glk:  [PASS][11] -> [DMESG-WARN][12] ([i915#118] / 
[i915#95])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-glk9/igt@gem_exec_whis...@basic-fds-forked-all.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18926/shard-glk6/igt@gem_exec_whis...@basic-fds-forked-all.html

  * igt@gem_partial_pwrite_pread@write-display:
- shard-hsw:  [PASS][13] -> [FAIL][14] ([i915#1888]) +2 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-hsw2/igt@gem_partial_pwrite_pr...@write-display.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18926/shard-hsw1/igt@gem_partial_pwrite_pr...@write-display.html

  * igt@gem_workarounds@suspend-resume:
- shard-apl:  [PASS][15] -> [INCOMPLETE][16] ([i915#1635])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-apl3/igt@gem_workarou...@suspend-resume.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18926/shard-apl6/igt@gem_workarou...@suspend-resume.html

  * igt@i915_module_load@reload:
- shard-skl:  [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +4 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-skl5/igt@i915_module_l...@reload.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18926/shard-skl4/igt@i915_module_l...@reload.html

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-skl:  [PASS][19] -> [DMESG-WARN][20] ([i915#1982] / 
[i915#2295]) +1 similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-skl4/igt@kms_cursor_...@pipe-a-cursor-suspend.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18926/shard-skl5/igt@kms_cursor_...@pipe-a-cursor-suspend.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-skl:  [PASS][21] -> [FAIL][22] ([i915#2346])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-skl8/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18926/sha

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

[Jani Nikula]

On Tue, 17 Nov 2020, Lucas De Marchi  wrote:
> On Tue, Nov 17, 2020 at 10:50:10AM -0800, Aditya Swarup wrote:
>>@@ -1579,9 +1579,9 @@ static inline const struct i915_rev_steppings *
>> tgl_revids_get(struct drm_i915_private *dev_priv)
>> {
>>  if (IS_TGL_U(dev_priv) || IS_TGL_Y(dev_priv))
>>- return tgl_uy_revids;
>>+ return tgl_uy_revids + INTEL_REVID(dev_priv);
>
> oohh, no. You have to at least check you are not accessing out of
> bounds. New HW running on old kernel should not access create invalid
> accesses like this.

And this is just one reason why exposing arrays directly as an interface
to the rest of the driver is a bad idea. Basically I look at *all*
externs in the driver with suspicion, and they're all exceptions that
should not be repeated. The revid arrays are a direct invitation to keep
adding more and more extern arrays. And more ways to go out of bounds.

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

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

BR,
Jani.


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

Re: [Intel-gfx] [PATCH] fbcon: Disable accelerated scrolling

[Geert Uytterhoeven]

Hi Daniel,

Replying "early" (see below), as this was applied to
drm-misc/for-linux-next.

On Sat, Oct 31, 2020 at 3:17 PM Daniel Vetter  wrote:
> On Sat, Oct 31, 2020 at 11:28 AM Geert Uytterhoeven
>  wrote:
> > On Thu, 29 Oct 2020, Daniel Vetter wrote:
> > > So ever since syzbot discovered fbcon, we have solid proof that it's
> > > full of bugs. And often the solution is to just delete code and remove
> > > features, e.g.  50145474f6ef ("fbcon: remove soft scrollback code").
> > >
> > > Now the problem is that most modern-ish drivers really only treat
> > > fbcon as an dumb kernel console until userspace takes over, and Oops
> > > printer for some emergencies. Looking at drm drivers and the basic
> > > vesa/efi fbdev drivers shows that only 3 drivers support any kind of
> > > acceleration:
> > >
> > > - nouveau, seems to be enabled by default
> > > - omapdrm, when a DMM remapper exists using remapper rewriting for
> > >  y/xpanning
> > > - gma500, but that is getting deleted now for the GTT remapper trick,
> > >  and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA
> > >  flag, so unused (and could be deleted already I think).
> > >
> > > No other driver supportes accelerated fbcon. And fbcon is the only
> > > user of this accel code (it's not exposed as uapi through ioctls),
> > > which means we could garbage collect fairly enormous amounts of code
> > > if we kill this.
> >
> > "git grep FBINFO_HWACCEL_COPYAREA" shows me there are 32 more drivers
> > using acceleration under drivers/video/fbdev/.
> >
> > > Plus because syzbot only runs on virtual hardware, and none of the
> > > drivers for that have acceleration, we'd remove a huge gap in testing.
> > > And there's no other even remotely comprehensive testing aside from
> > > syzbot.
> >
> > That sounds like a great argument to remove all hardware drivers from
> > the kernel ;-)
>
> fbdev is unmaintained, has no one volunteering to put in the work (and
> there's huge amounts of work needed), and there's no test suite. No,
> fbtest.c doesn't can't, that's not even close. We're not going to
> delete everything in the kernel, but slowly sunsetting stuff that's
> just costing and not bringing in up is a good idea.

The fbcon acceleration code is indeed not tested by fbset, and it is
purely in-kernel acceleration for the console.

> > Seriously, how hard can it be to add "software-accelerated" acceleration
> > hooks to drivers/video/fbdev/vfb.c, to enable syzbot to exercise the
> > core acceleration code paths?
>
> Just this one is 5 combinations, which means I'd need to convince
> syzbot to test 5 different machine setups.

Why 5 combinations?
Enable vfb (which can be a module) and be done with it?

> Plus we're still lacking a test suite, and judging from how much time
> it took to get something basic going for kms, that's about 2 engineer
> years of effort that no one is even close to willing to spend.

Sure, writing test suites is hard, and takes time.

> > > This patch here just disables the acceleration code by always
> > > redrawing when scrolling. The plan is that once this has been merged
> > > for well over a year in released kernels, we can start to go around
> > > and delete a lot of code.
> >
> > Have you benchmarked the performance impact on traditional fbdev
> > drivers?
>
> There's still some acceleration if you have an image blit engine for
> redrawing the screen. But the complexity is contained in the old
> drivers that no one cares about.
>
> For anything I have access to the difference is 0.

Sure, you're doing DRM drivers ;-)

> Reality is that fbdev is just there nowadays for Oops printing and
> emergency usage, and it's plenty good enough for that. If there's

That's true for systems that are supported by a DRM driver.

> anyone who cares beyond that, they're most definitely not able to put
> in time for upstream work.

There exist actual products using out-of-tree fbdev drivers that never
got the chance of being merged upstream due to the moratorium on new
fbdev drivers.

BTW, I'm trying to convert an old fbdev driver to DRM, but don't have it
working yet. I had hoped to get something working before replying to
this email, so I could provide more detailed feedback.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for Rebased remaining big joiner series

[Patchwork]

== Series Details ==

Series: Rebased remaining big joiner series
URL   : https://patchwork.freedesktop.org/series/83990/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9350_full -> Patchwork_18928_full


Summary
---

  **FAILURE**

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

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_caching@read-writes:
- shard-snb:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-snb4/igt@gem_cach...@read-writes.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18928/shard-snb4/igt@gem_cach...@read-writes.html

  * igt@gem_cs_tlb@engines@vecs0:
- shard-glk:  [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-glk4/igt@gem_cs_tlb@engi...@vecs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18928/shard-glk2/igt@gem_cs_tlb@engi...@vecs0.html

  
New tests
-

  New tests have been introduced between CI_DRM_9350_full and 
Patchwork_18928_full:

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

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

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- shard-hsw:  [PASS][5] -> [FAIL][6] ([i915#1888])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-hsw2/igt@gem_exec_susp...@basic-s3.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18928/shard-hsw2/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_exec_whisper@basic-contexts-forked:
- shard-hsw:  [PASS][7] -> [TIMEOUT][8] ([i915#2502])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-hsw2/igt@gem_exec_whis...@basic-contexts-forked.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18928/shard-hsw2/igt@gem_exec_whis...@basic-contexts-forked.html

  * igt@gem_exec_whisper@basic-normal-all:
- shard-glk:  [PASS][9] -> [DMESG-WARN][10] ([i915#118] / [i915#95])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-glk7/igt@gem_exec_whis...@basic-normal-all.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18928/shard-glk3/igt@gem_exec_whis...@basic-normal-all.html

  * igt@i915_module_load@reload-with-fault-injection:
- shard-skl:  [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +7 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-skl5/igt@i915_module_l...@reload-with-fault-injection.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18928/shard-skl10/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@kms_cursor_crc@pipe-a-cursor-256x85-onscreen:
- shard-skl:  [PASS][13] -> [FAIL][14] ([i915#54]) +1 similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-skl10/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18928/shard-skl3/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html

  * igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions:
- shard-skl:  [PASS][15] -> [DMESG-WARN][16] ([i915#1982] / 
[i915#2295])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-skl7/igt@kms_cursor_leg...@cursor-vs-flip-atomic-transitions.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18928/shard-skl2/igt@kms_cursor_leg...@cursor-vs-flip-atomic-transitions.html

  * igt@kms_cursor_legacy@flip-vs-cursor-legacy:
- shard-tglb: [PASS][17] -> [FAIL][18] ([i915#2346])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-tglb5/igt@kms_cursor_leg...@flip-vs-cursor-legacy.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18928/shard-tglb7/igt@kms_cursor_leg...@flip-vs-cursor-legacy.html

  * igt@kms_flip@2x-plain-flip-ts-check-interruptible@ac-hdmi-a1-hdmi-a2:
- shard-glk:  [PASS][19] -> [FAIL][20] ([i915#2122])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-glk1/igt@kms_flip@2x-plain-flip-ts-check-interrupti...@ac-hdmi-a1-hdmi-a2.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18928/shard-glk8/igt@kms_flip@2x-plain-flip-ts-check-interrupti...@ac-hdmi-a1-hdmi-a2.html

  * igt@kms_flip@flip-vs-expired-vblank-int

Re: [Intel-gfx] [PATCH] i915/gem_flink_race: Fix error in buffer usage

[Chris Wilson]

Quoting Hampson, Steven T (2020-11-17 23:45:23)
> 
> 
> Sent from my iPhone
> 
> > On Nov 17, 2020, at 2:28 PM, Chris Wilson  wrote:
> > 
> > Quoting Steve Hampson (2020-11-17 22:23:08)
> >> A buffer in function test_flink_name was both too small and never
> >> checked for overflow.  Both errors are fixed.
> > 
> > That many numbers is not interesting. Show the range and median instead.
> > -Chris
> 
> I don’t understand what you are talking about.  

The reason I printed the individual numbers was so that we could see the
distribution in case one thread was being starved or not. That is fine
for a few numbers, but beyond that we can summarise with statistics.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [CI 3/3] drm/i915/gt: Move pm debug files into a gt aware debugfs

[Chris Wilson]

Quoting Lucas De Marchi (2020-11-18 01:32:16)
> On Wed, Nov 04, 2020 at 10:11:53AM +, Chris Wilson wrote:
> >Quoting Joonas Lahtinen (2020-11-04 10:05:32)
> >> Quoting Chris Wilson (2019-12-22 16:40:46)
> >> > From: Andi Shyti 
> >> >
> >> > The GT system is becoming more and more a stand-alone system in
> >> > i915 and it's fair to assign it its own debugfs directory.
> >> >
> >> > rc6, rps and llc debugfs files are gt related, move them into the
> >> > gt debugfs directory.
> >> >
> >> > Signed-off-by: Andi Shyti 
> >> > Reviewed-by: Chris Wilson 
> >> > Signed-off-by: Chris Wilson 
> >> > ---
> >> >  drivers/gpu/drm/i915/Makefile |   3 +
> >> >  drivers/gpu/drm/i915/gt/debugfs_engines.c |  36 ++
> >> >  drivers/gpu/drm/i915/gt/debugfs_engines.h |  15 +
> >> >  drivers/gpu/drm/i915/gt/debugfs_gt.c  |  42 ++
> >> >  drivers/gpu/drm/i915/gt/debugfs_gt.h  |  39 ++
> >> >  drivers/gpu/drm/i915/gt/debugfs_gt_pm.c   | 601 ++
> >> >  drivers/gpu/drm/i915/gt/debugfs_gt_pm.h   |  14 +
> >> >  drivers/gpu/drm/i915/gt/intel_gt.c|   3 +
> >> >  8 files changed, 753 insertions(+)
> >> >  create mode 100644 drivers/gpu/drm/i915/gt/debugfs_engines.c
> >> >  create mode 100644 drivers/gpu/drm/i915/gt/debugfs_engines.h
> >> >  create mode 100644 drivers/gpu/drm/i915/gt/debugfs_gt.c
> >> >  create mode 100644 drivers/gpu/drm/i915/gt/debugfs_gt.h
> >> >  create mode 100644 drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
> >> >  create mode 100644 drivers/gpu/drm/i915/gt/debugfs_gt_pm.h
> >>
> >> This patch seems to actually copy the code, forgetting to remove the old
> >> code. Let's have a follow-up patch that eliminates the duplication.
> >
> >We couldn't remove the old code without making changes to igt to work
> >out what the appropriate GT directory would be for the test. That is
> >still unknowable from userspace... So as a matter of convenience we kept
> >the old entry point so that we could dump everything under the device.
> 
> couldn't it be replaced by a symlink? The below works for me and afaics
> would be a better temporary solution than the duplicate code:

No. One is system, the other is gt. They are not equivalent.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 14/28] drm/i915/gt: Free stale request on destroying the virtual engine

[Tvrtko Ursulin]

On 17/11/2020 11:30, Chris Wilson wrote:

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

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

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/gt/intel_lrc.c | 61 +
  1 file changed, 54 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 17cb7060eb29..c11433884cf6 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -182,6 +182,7 @@
  struct virtual_engine {
struct intel_engine_cs base;
struct intel_context context;
+   struct rcu_work rcu;
  
  	/*

 * We allow only a single request through the virtual engine at a time
@@ -5470,44 +5471,90 @@ static struct list_head *virtual_queue(struct 
virtual_engine *ve)
return &ve->base.execlists.default_priolist.requests[0];
  }
  
-static void virtual_context_destroy(struct kref *kref)

+static void rcu_virtual_context_destroy(struct work_struct *wrk)
  {
struct virtual_engine *ve =
-   container_of(kref, typeof(*ve), context.ref);
+   container_of(wrk, typeof(*ve), rcu.work);
unsigned int n;
  
-	GEM_BUG_ON(!list_empty(virtual_queue(ve)));

-   GEM_BUG_ON(ve->request);
GEM_BUG_ON(ve->context.inflight);
  
+	/* Preempt-to-busy may leave a stale request behind. */

+   if (unlikely(ve->request)) {
+   struct i915_request *old;
+
+   spin_lock_irq(&ve->base.active.lock);
+
+   old = fetch_and_zero(&ve->request);
+   if (old) {
+   GEM_BUG_ON(!i915_request_completed(old));
+   __i915_request_submit(old);
+   i915_request_put(old);
+   }
+
+   spin_unlock_irq(&ve->base.active.lock);
+   }
+
+   /*
+* Flush the tasklet in case it is still running on another core.
+*
+* This needs to be done before we remove ourselves from the siblings'
+* rbtrees as in the case it is running in parallel, it may reinsert
+* the rb_node into a sibling.
+*/
+   tasklet_kill(&ve->base.execlists.tasklet);


Can it still be running after an RCU period?


+
+   /* Decouple ourselves from the siblings, no more access allowed. */
for (n = 0; n < ve->num_siblings; n++) {
struct intel_engine_cs *sibling = ve->siblings[n];
struct rb_node *node = &ve->nodes[sibling->id].rb;
-   unsigned long flags;
  
  		if (RB_EMPTY_NODE(node))

continue;
  
-		spin_lock_irqsave(&sibling->active.lock, flags);

+   spin_lock_irq(&sibling->active.lock);
  
  		/* Detachment is lazily performed in the execlists tasklet */

if (!RB_EMPTY_NODE(node))
rb_erase_cached(node, &sibling->execlists.virtual);
  
-		spin_unlock_irqrestore(&sibling->active.lock, flags);

+   spin_unlock_irq(&sibling->active.lock);
}
GEM_BUG_ON(__tasklet_is_scheduled(&ve->base.execlists.tasklet));
+   GEM_BUG_ON(!list_empty(virtual_queue(ve)));
  
  	if (ve->context.state)

__execlists_context_fini(&ve->context);
intel_context_fini(&ve->context);
  
  	intel_engine_free_request_pool(&ve->base);

+   intel_breadcrumbs_free(ve->base.breadcrumbs);


This looks to belong to some other patch.

Regards,

Tvrtko

  
  	kfree(ve->bonds);

kfree(ve);
  }
  
+static void virtual_context_destroy(struct kref *kref)

+{
+   struct virtual_engine *ve =
+   container_of(kref, typeof(*ve), context.ref);
+
+   GEM_BUG_ON(!list_empty(&ve->context.signals));
+
+   /*
+* When destroying the virtual engine, we have to be aware that
+* it may still be in use from an hardirq/softirq context causing
+* the resubmission of a completed request (background completion
+* due to preempt-to-busy). Before we can free the engine, we need
+* to flush the submission code and tasklets that are still potentially
+* accessing the engine. Flushing the tasklets require process context,
+* and since we can guard the resubmit onto the engine with an RCU read
+* lock, we can delegate the 

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915/display: Support Multiple Transcoders' PSR status on debugfs

[Jani Nikula]

On Fri, 06 Nov 2020, Gwan-gyeong Mun  wrote:
> In order to support the PSR state of each transcoder, it adds
> i915_psr_status to sub-directory of each transcoder.
>
> v2: Change using of Symbolic permissions 'S_IRUGO' to using of octal
> permissions '0444'
>
> Signed-off-by: Gwan-gyeong Mun 
> Cc: José Roberto de Souza 
> ---
>  .../drm/i915/display/intel_display_debugfs.c  | 23 +++
>  1 file changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 8402e6ac9f76..37805615a221 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -2093,6 +2093,23 @@ static int i915_hdcp_sink_capability_show(struct 
> seq_file *m, void *data)
>  }
>  DEFINE_SHOW_ATTRIBUTE(i915_hdcp_sink_capability);
>  
> +static int i915_psr_status_show(struct seq_file *m, void *data)
> +{
> + struct drm_connector *connector = m->private;
> + struct intel_dp *intel_dp =
> + intel_attached_dp(to_intel_connector(connector));
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> +
> + if (connector->status != connector_status_connected)
> + return -ENODEV;
> +
> + if (!HAS_PSR(dev_priv))
> + return -ENODEV;
> +
> + return intel_psr_status(m, intel_dp);
> +}
> +DEFINE_SHOW_ATTRIBUTE(i915_psr_status);
> +
>  #define LPSP_CAPABLE(COND) (COND ? seq_puts(m, "LPSP: capable\n") : \
>   seq_puts(m, "LPSP: incapable\n"))
>  
> @@ -2268,6 +2285,12 @@ int intel_connector_debugfs_add(struct drm_connector 
> *connector)
>   connector, &i915_psr_sink_status_fops);
>   }
>  
> + if (INTEL_GEN(dev_priv) >= 12 &&

I'd add this for all generations to unify the debugfs, and eventually
phase out the non connector specific debugfs file.

And I'd add HAS_PSR() check here to not create the file if it's not
possible instead of having the check in i915_psr_status_show().

BR,
Jani.

> + connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
> + debugfs_create_file("i915_psr_status", 0444, root,
> + connector, &i915_psr_status_fops);
> + }
> +
>   if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
>   connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
>   connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {

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

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915/display: Support Multiple Transcoders' PSR status on debugfs

[Jani Nikula]

On Fri, 06 Nov 2020, Gwan-gyeong Mun  wrote:
> In order to support the PSR state of each transcoder, it adds
> i915_psr_status to sub-directory of each transcoder.
>
> v2: Change using of Symbolic permissions 'S_IRUGO' to using of octal
> permissions '0444'
>
> Signed-off-by: Gwan-gyeong Mun 
> Cc: José Roberto de Souza 
> ---
>  .../drm/i915/display/intel_display_debugfs.c  | 23 +++
>  1 file changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 8402e6ac9f76..37805615a221 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -2093,6 +2093,23 @@ static int i915_hdcp_sink_capability_show(struct 
> seq_file *m, void *data)
>  }
>  DEFINE_SHOW_ATTRIBUTE(i915_hdcp_sink_capability);
>  
> +static int i915_psr_status_show(struct seq_file *m, void *data)
> +{
> + struct drm_connector *connector = m->private;
> + struct intel_dp *intel_dp =
> + intel_attached_dp(to_intel_connector(connector));
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> +
> + if (connector->status != connector_status_connected)

How's this possible for eDP, btw?

BR,
Jani.

> + return -ENODEV;
> +
> + if (!HAS_PSR(dev_priv))
> + return -ENODEV;
> +
> + return intel_psr_status(m, intel_dp);
> +}
> +DEFINE_SHOW_ATTRIBUTE(i915_psr_status);
> +
>  #define LPSP_CAPABLE(COND) (COND ? seq_puts(m, "LPSP: capable\n") : \
>   seq_puts(m, "LPSP: incapable\n"))
>  
> @@ -2268,6 +2285,12 @@ int intel_connector_debugfs_add(struct drm_connector 
> *connector)
>   connector, &i915_psr_sink_status_fops);
>   }
>  
> + if (INTEL_GEN(dev_priv) >= 12 &&
> + connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
> + debugfs_create_file("i915_psr_status", 0444, root,
> + connector, &i915_psr_status_fops);
> + }
> +
>   if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
>   connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
>   connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {

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

Re: [Intel-gfx] [PATCH 14/28] drm/i915/gt: Free stale request on destroying the virtual engine

[Chris Wilson]

Quoting Tvrtko Ursulin (2020-11-18 11:05:24)
> 
> On 17/11/2020 11:30, Chris Wilson wrote:
> > Since preempt-to-busy, we may unsubmit a request while it is still on
> > the HW and completes asynchronously. That means it may be retired and in
> > the process destroy the virtual engine (as the user has closed their
> > context), but that engine may still be holding onto the unsubmitted
> > compelted request. Therefore we need to potentially cleanup the old
> > request on destroying the virtual engine. We also have to keep the
> > virtual_engine alive until after the sibling's execlists_dequeue() have
> > finished peeking into the virtual engines, for which we serialise with
> > RCU.
> > 
> > v2: Be paranoid and flush the tasklet as well.
> > v3: And flush the tasklet before the engines, as the tasklet may
> > re-attach an rb_node after our removal from the siblings.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > ---
> >   drivers/gpu/drm/i915/gt/intel_lrc.c | 61 +
> >   1 file changed, 54 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index 17cb7060eb29..c11433884cf6 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -182,6 +182,7 @@
> >   struct virtual_engine {
> >   struct intel_engine_cs base;
> >   struct intel_context context;
> > + struct rcu_work rcu;
> >   
> >   /*
> >* We allow only a single request through the virtual engine at a time
> > @@ -5470,44 +5471,90 @@ static struct list_head *virtual_queue(struct 
> > virtual_engine *ve)
> >   return &ve->base.execlists.default_priolist.requests[0];
> >   }
> >   
> > -static void virtual_context_destroy(struct kref *kref)
> > +static void rcu_virtual_context_destroy(struct work_struct *wrk)
> >   {
> >   struct virtual_engine *ve =
> > - container_of(kref, typeof(*ve), context.ref);
> > + container_of(wrk, typeof(*ve), rcu.work);
> >   unsigned int n;
> >   
> > - GEM_BUG_ON(!list_empty(virtual_queue(ve)));
> > - GEM_BUG_ON(ve->request);
> >   GEM_BUG_ON(ve->context.inflight);
> >   
> > + /* Preempt-to-busy may leave a stale request behind. */
> > + if (unlikely(ve->request)) {
> > + struct i915_request *old;
> > +
> > + spin_lock_irq(&ve->base.active.lock);
> > +
> > + old = fetch_and_zero(&ve->request);
> > + if (old) {
> > + GEM_BUG_ON(!i915_request_completed(old));
> > + __i915_request_submit(old);
> > + i915_request_put(old);
> > + }
> > +
> > + spin_unlock_irq(&ve->base.active.lock);
> > + }
> > +
> > + /*
> > +  * Flush the tasklet in case it is still running on another core.
> > +  *
> > +  * This needs to be done before we remove ourselves from the siblings'
> > +  * rbtrees as in the case it is running in parallel, it may reinsert
> > +  * the rb_node into a sibling.
> > +  */
> > + tasklet_kill(&ve->base.execlists.tasklet);
> 
> Can it still be running after an RCU period?

I think there is a window between checking to see if the request is
completed and kicking the tasklet, that is not under the rcu lock and
opportunity for the request to be retired, and barrier flushed to drop
the context references.

I observed the leaked ve->request, but the tasklet_kill, iirc, is
speculation about possible windows. Admittedly all long test runs have
been with this patch in place for most of the last year.

> > + /* Decouple ourselves from the siblings, no more access allowed. */
> >   for (n = 0; n < ve->num_siblings; n++) {
> >   struct intel_engine_cs *sibling = ve->siblings[n];
> >   struct rb_node *node = &ve->nodes[sibling->id].rb;
> > - unsigned long flags;
> >   
> >   if (RB_EMPTY_NODE(node))
> >   continue;
> >   
> > - spin_lock_irqsave(&sibling->active.lock, flags);
> > + spin_lock_irq(&sibling->active.lock);
> >   
> >   /* Detachment is lazily performed in the execlists tasklet */
> >   if (!RB_EMPTY_NODE(node))
> >   rb_erase_cached(node, &sibling->execlists.virtual);
> >   
> > - spin_unlock_irqrestore(&sibling->active.lock, flags);
> > + spin_unlock_irq(&sibling->active.lock);
> >   }
> >   GEM_BUG_ON(__tasklet_is_scheduled(&ve->base.execlists.tasklet));
> > + GEM_BUG_ON(!list_empty(virtual_queue(ve)));
> >   
> >   if (ve->context.state)
> >   __execlists_context_fini(&ve->context);
> >   intel_context_fini(&ve->context);
> >   
> >   intel_engine_free_request_pool(&ve->base);
> > + intel_breadcrumbs_free(ve->base.breadcrumbs);
> 
> This looks to belong to some other patch.

Some might say I was fixin

Re: [Intel-gfx] [PATCH 16/28] drm/i915/gt: Split the breadcrumb spinlock between global and contexts

[Tvrtko Ursulin]

On 17/11/2020 11:30, Chris Wilson wrote:

As we funnel more and more contexts into the breadcrumbs on an engine,
the hold time of b->irq_lock grows. As we may then contend with the
b->irq_lock during request submission, this increases the burden upon
the engine->active.lock and so directly impacts both our execution
latency and client latency. If we split the b->irq_lock by introducing a
per-context spinlock to manage the signalers within a context, we then
only need the b->irq_lock for enabling/disabling the interrupt and can
avoid taking the lock for walking the list of contexts within the signal
worker. Even with the current setup, this greatly reduces the number of
times we have to take and fight for b->irq_lock.

Furthermore, this closes the race between enabling the signaling context
while it is in the process of being signaled and removed:

<4>[  416.208555] list_add corruption. prev->next should be next 
(8881951d5910), but was dead0100. (prev=8882781bb870).
<4>[  416.208573] WARNING: CPU: 7 PID: 0 at lib/list_debug.c:28 
__list_add_valid+0x4d/0x70
<4>[  416.208575] Modules linked in: i915(+) vgem snd_hda_codec_hdmi 
snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio mei_hdcp 
x86_pkg_temp_thermal coretemp ax88179_178a usbnet mii crct10dif_pclmul 
snd_intel_dspcfg crc32_pclmul snd_hda_codec snd_hwdep ghash_clmulni_intel 
snd_hda_core e1000e snd_pcm ptp pps_core mei_me mei prime_numbers intel_lpss_pci 
[last unloaded: i915]
<4>[  416.208611] CPU: 7 PID: 0 Comm: swapper/7 Tainted: G U
5.8.0-CI-CI_DRM_8852+ #1
<4>[  416.208614] Hardware name: Intel Corporation Ice Lake Client 
Platform/IceLake Y LPDDR4x T4 RVP TLC, BIOS ICLSFWR1.R00.3212.A00.1905212112 
05/21/2019
<4>[  416.208627] RIP: 0010:__list_add_valid+0x4d/0x70
<4>[  416.208631] Code: c3 48 89 d1 48 c7 c7 60 18 33 82 48 89 c2 e8 ea e0 b6 ff 0f 
0b 31 c0 c3 48 89 c1 4c 89 c6 48 c7 c7 b0 18 33 82 e8 d3 e0 b6 ff <0f> 0b 31 c0 c3 48 
89 f2 4c 89 c1 48 89 fe 48 c7 c7 00 19 33 82 e8
<4>[  416.208633] RSP: 0018:c9280e18 EFLAGS: 00010086
<4>[  416.208636] RAX:  RBX: 888250a44880 RCX: 
0105
<4>[  416.208639] RDX: 0105 RSI: 82320c5b RDI: 

<4>[  416.208641] RBP: 8882781bb870 R08:  R09: 
0001
<4>[  416.208643] R10: 054d2957 R11: 6abbd991 R12: 
8881951d58c8
<4>[  416.208646] R13: 888286073880 R14: 888286073848 R15: 
8881951d5910
<4>[  416.208669] FS:  () GS:88829c18() 
knlGS:
<4>[  416.208671] CS:  0010 DS:  ES:  CR0: 80050033
<4>[  416.208673] CR2: 556231326c48 CR3: 05610001 CR4: 
00760ee0
<4>[  416.208675] PKRU: 5554
<4>[  416.208677] Call Trace:
<4>[  416.208679]  
<4>[  416.208751]  i915_request_enable_breadcrumb+0x278/0x400 [i915]
<4>[  416.208839]  __i915_request_submit+0xca/0x2a0 [i915]
<4>[  416.208892]  __execlists_submission_tasklet+0x480/0x1830 [i915]
<4>[  416.208942]  execlists_submission_tasklet+0xc4/0x130 [i915]
<4>[  416.208947]  tasklet_action_common.isra.17+0x6c/0x1c0
<4>[  416.208954]  __do_softirq+0xdf/0x498
<4>[  416.208960]  ? handle_fasteoi_irq+0x150/0x150
<4>[  416.208964]  asm_call_on_stack+0xf/0x20
<4>[  416.208966]  
<4>[  416.208969]  do_softirq_own_stack+0xa1/0xc0
<4>[  416.208972]  irq_exit_rcu+0xb5/0xc0
<4>[  416.208976]  common_interrupt+0xf7/0x260
<4>[  416.208980]  asm_common_interrupt+0x1e/0x40
<4>[  416.208985] RIP: 0010:cpuidle_enter_state+0xb6/0x410
<4>[  416.208987] Code: 00 31 ff e8 9c 3e 89 ff 80 7c 24 0b 00 74 12 9c 58 f6 c4 02 
0f 85 31 03 00 00 31 ff e8 e3 6c 90 ff e8 fe a4 94 ff fb 45 85 ed <0f> 88 c7 02 00 00 
49 63 c5 4c 2b 24 24 48 8d 14 40 48 8d 14 90 48
<4>[  416.208989] RSP: 0018:c9143e70 EFLAGS: 0206
<4>[  416.208991] RAX: 0007 RBX: e8da8070 RCX: 

<4>[  416.208993] RDX:  RSI: 8238b4ee RDI: 
8233184f
<4>[  416.208995] RBP: 826b4e00 R08:  R09: 

<4>[  416.208997] R10: 0001 R11:  R12: 
0060e7f24a8f
<4>[  416.208998] R13: 0003 R14: 0003 R15: 
0003
<4>[  416.209012]  cpuidle_enter+0x24/0x40
<4>[  416.209016]  do_idle+0x22f/0x2d0
<4>[  416.209022]  cpu_startup_entry+0x14/0x20
<4>[  416.209025]  start_secondary+0x158/0x1a0
<4>[  416.209030]  secondary_startup_64+0xa4/0xb0
<4>[  416.209039] irq event stamp: 10186977
<4>[  416.209042] hardirqs last  enabled at (10186976): [] 
tasklet_action_common.isra.17+0xe3/0x1c0
<4>[  416.209044] hardirqs last disabled at (10186977): [] 
_raw_spin_lock_irqsave+0xd/0x50
<4>[  416.209047] softirqs last  enabled at (10186968): [] 
irq_enter_rcu+0x6a/0x70
<4>[  416.209049] softirqs last disabled at (10186969): [] 
asm_call_on_stack+0xf/0x20

<4>[  416.209317] list_del corruption, 8882781bb870->next is LIST_POISON1 
(dead00

Re: [Intel-gfx] [PATCH 15/28] drm/i915/gt: Protect context lifetime with RCU

[Tvrtko Ursulin]

On 17/11/2020 11:30, Chris Wilson wrote:

Allow a brief period for continued access to a dead intel_context by
deferring the release of the struct until after an RCU grace period.
As we are using a dedicated slab cache for the contexts, we can defer
the release of the slab pages via RCU, with the caveat that individual
structs may be reused from the freelist within an RCU grace period. To
handle that, we have to avoid clearing members of the zombie struct.

This is required for a later patch to handle locking around virtual
requests in the signaler, as those requests may want to move between
engines and be destroyed while we are holding b->irq_lock on a physical
engine.

v2: Drop mutex_reinit(), if we never mark the mutex as destroyed we
don't need to reset the debug code, at the loss of having the mutex
debug code spot us attempting to destroy a locked mutex.
v3: As the intended use will remain strongly referenced counted, with
very little inflight access across reuse, drop the ctor.
v4: Drop the unrequired change to remove the temporary reference around
dropping the active context, and add back some more missing ctor
operations.
v5: The ctor is back. Tvrtko spotted that ce->signal_lock [introduced
later] maybe accessed under RCU and so needs special care not to be
reinitialised.
v6: Don't mix SLAB_TYPESAFE_BY_RCU and RCU list iteration.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/gt/intel_context.c   | 12 +---
  drivers/gpu/drm/i915/gt/intel_context_types.h | 11 ++-
  2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 92a3f25c4006..d3a835212167 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -25,11 +25,18 @@ static struct intel_context *intel_context_alloc(void)
return kmem_cache_zalloc(global.slab_ce, GFP_KERNEL);
  }
  
-void intel_context_free(struct intel_context *ce)

+static void rcu_context_free(struct rcu_head *rcu)
  {
+   struct intel_context *ce = container_of(rcu, typeof(*ce), rcu);
+
kmem_cache_free(global.slab_ce, ce);
  }
  
+void intel_context_free(struct intel_context *ce)

+{
+   call_rcu(&ce->rcu, rcu_context_free);
+}
+
  struct intel_context *
  intel_context_create(struct intel_engine_cs *engine)
  {
@@ -356,8 +363,7 @@ static int __intel_context_active(struct i915_active 
*active)
  }
  
  void

-intel_context_init(struct intel_context *ce,
-  struct intel_engine_cs *engine)
+intel_context_init(struct intel_context *ce, struct intel_engine_cs *engine)
  {
GEM_BUG_ON(!engine->cops);
GEM_BUG_ON(!engine->gt->vm);
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 552cb57a2e8c..20cb5835d1c3 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -44,7 +44,16 @@ struct intel_context_ops {
  };
  
  struct intel_context {

-   struct kref ref;
+   /*
+* Note: Some fields may be accessed under RCU.
+*
+* Unless otherwise noted a field can safely be assumed to be protected
+* by strong reference counting.
+*/
+   union {
+   struct kref ref; /* no kref_get_unless_zero()! */
+   struct rcu_head rcu;
+   };
  
  	struct intel_engine_cs *engine;

struct intel_engine_cs *inflight;



Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [PATCH 14/28] drm/i915/gt: Free stale request on destroying the virtual engine

[Tvrtko Ursulin]

On 18/11/2020 11:24, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2020-11-18 11:05:24)


On 17/11/2020 11:30, Chris Wilson wrote:

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

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

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
   drivers/gpu/drm/i915/gt/intel_lrc.c | 61 +
   1 file changed, 54 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 17cb7060eb29..c11433884cf6 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -182,6 +182,7 @@
   struct virtual_engine {
   struct intel_engine_cs base;
   struct intel_context context;
+ struct rcu_work rcu;
   
   /*

* We allow only a single request through the virtual engine at a time
@@ -5470,44 +5471,90 @@ static struct list_head *virtual_queue(struct 
virtual_engine *ve)
   return &ve->base.execlists.default_priolist.requests[0];
   }
   
-static void virtual_context_destroy(struct kref *kref)

+static void rcu_virtual_context_destroy(struct work_struct *wrk)
   {
   struct virtual_engine *ve =
- container_of(kref, typeof(*ve), context.ref);
+ container_of(wrk, typeof(*ve), rcu.work);
   unsigned int n;
   
- GEM_BUG_ON(!list_empty(virtual_queue(ve)));

- GEM_BUG_ON(ve->request);
   GEM_BUG_ON(ve->context.inflight);
   
+ /* Preempt-to-busy may leave a stale request behind. */

+ if (unlikely(ve->request)) {
+ struct i915_request *old;
+
+ spin_lock_irq(&ve->base.active.lock);
+
+ old = fetch_and_zero(&ve->request);
+ if (old) {
+ GEM_BUG_ON(!i915_request_completed(old));
+ __i915_request_submit(old);
+ i915_request_put(old);
+ }
+
+ spin_unlock_irq(&ve->base.active.lock);
+ }
+
+ /*
+  * Flush the tasklet in case it is still running on another core.
+  *
+  * This needs to be done before we remove ourselves from the siblings'
+  * rbtrees as in the case it is running in parallel, it may reinsert
+  * the rb_node into a sibling.
+  */
+ tasklet_kill(&ve->base.execlists.tasklet);


Can it still be running after an RCU period?


I think there is a window between checking to see if the request is
completed and kicking the tasklet, that is not under the rcu lock and
opportunity for the request to be retired, and barrier flushed to drop
the context references.


From where would that check come?


I observed the leaked ve->request, but the tasklet_kill, iirc, is
speculation about possible windows. Admittedly all long test runs have
been with this patch in place for most of the last year.


+ /* Decouple ourselves from the siblings, no more access allowed. */
   for (n = 0; n < ve->num_siblings; n++) {
   struct intel_engine_cs *sibling = ve->siblings[n];
   struct rb_node *node = &ve->nodes[sibling->id].rb;
- unsigned long flags;
   
   if (RB_EMPTY_NODE(node))

   continue;
   
- spin_lock_irqsave(&sibling->active.lock, flags);

+ spin_lock_irq(&sibling->active.lock);
   
   /* Detachment is lazily performed in the execlists tasklet */

   if (!RB_EMPTY_NODE(node))
   rb_erase_cached(node, &sibling->execlists.virtual);
   
- spin_unlock_irqrestore(&sibling->active.lock, flags);

+ spin_unlock_irq(&sibling->active.lock);
   }
   GEM_BUG_ON(__tasklet_is_scheduled(&ve->base.execlists.tasklet));
+ GEM_BUG_ON(!list_empty(virtual_queue(ve)));
   
   if (ve->context.state)

   __execlists_context_fini(&ve->context);
   intel_context_fini(&ve->context);
   
   intel_engine_free_request_pool(&ve->base);

+ intel_breadcrumbs_free(ve->base.breadcrumbs);


This looks to belong to some other patch.


Some might say I was fixing up an earlier oversight.


Separate patch would be good, with Fixes: probably since it is a memory 
leak and one liner.


Regards,

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

Re: [Intel-gfx] [PATCH 8/8] drm/i915/perf: Map OA buffer to user space for gen12 performance query

[Joonas Lahtinen]

+ Umesh, Lionel

Do we have a link to the userspace changes and IGT tests? Those are
absolutely needed before we can do a final review and merge.

We should really test and review the kernel and userspace changes
together to make sure that we're coming up with a solid uAPI.

Regards, Joonas

Quoting Chris Wilson (2020-11-17 13:01:32)
> From: Umesh Nerlige Ramappa 
> 
> i915 used to support time based sampling mode which is good for overall
> system monitoring, but is not enough for query mode used to measure a
> single draw call or dispatch. Gen9-Gen11 are using current i915 perf
> implementation for query, but Gen12+ requires a new approach for query
> based on triggered reports within oa buffer.
> 
> Triggering reports into the OA buffer is achieved by writing into a
> a trigger register. Optionally an unused counter/register is set with a
> marker value such that a triggered report can be identified in the OA
> buffer. Reports are usually triggered at the start and end of work that
> is measured.
> 
> Since OA buffer is large and queries can be frequent, an efficient way
> to look for triggered reports is required. By knowing the current head
> and tail offsets into the OA buffer, it is easier to determine the
> locality of the reports of interest.
> 
> Current perf OA interface does not expose head/tail information to the
> user and it filters out invalid reports before sending data to user.
> Also considering limited size of user buffer used during a query,
> creating a 1:1 copy of the OA buffer at the user space added undesired
> complexity.
> 
> The solution was to map the OA buffer to user space provided
> 
> (1) that it is accessed from a privileged user.
> (2) OA report filtering is not used.
> 
> These 2 conditions would satisfy the safety criteria that the current
> perf interface addresses.
> 
> To enable the query:
> - Add an ioctl to expose head and tail to the user
> - Add an ioctl to return size and offset of the OA buffer
> - Map the OA buffer to the user space
> 
> v2:
> - Improve commit message (Chris)
> - Do not mmap based on gem object filp. Instead, use perf_fd and support
>   mmap syscall (Chris)
> - Pass non-zero offset in mmap to enforce the right object is
>   mapped (Chris)
> - Do not expose gpu_address (Chris)
> - Verify start and length of vma for page alignment (Lionel)
> - Move SQNTL config out (Lionel)
> 
> v3: (Chris)
> - Omit redundant checks
> - Return VM_FAULT_SIGBUS is old stream is closed
> - Maintain reference counts to stream in vm_open and vm_close
> - Use switch to identify object to be mapped
> 
> v4: Call kref_put on closing perf fd (Chris)
> v5:
> - Strip access to OA buffer from unprivileged child of a privileged
>   parent. Use VM_DONTCOPY
> - Enforce MAP_PRIVATE by checking for VM_MAYSHARE
> 
> v6:
> (Chris)
> - Use len of -1 in unmap_mapping_range
> - Don't use stream->oa_buffer.vma->obj in vm_fault_oa
> - Use kernel block comment style
> - do_mmap gets a reference to the file and puts it in do_munmap, so
>   no need to maintain a reference to i915_perf_stream. Hence, remove
>   vm_open/vm_close and stream->closed hooks/checks.
> (Umesh)
> - Do not allow mmap if SAMPLE_OA_REPORT is not set during
>   i915_perf_open_ioctl.
> - Drop ioctl returning head/tail since this information is already
>   whitelisted. Remove hooks to read head register.
> 
> v7: (Chris)
> - unmap before destroy
> - change ioctl argument struct
> 
> v8: Documentation and more checks (Chris)
> 
> Signed-off-by: Piotr Maciejewski 
> Signed-off-by: Umesh Nerlige Ramappa 
> Reviewed-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_mman.c |   2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_mman.h |   2 +
>  drivers/gpu/drm/i915/i915_perf.c | 126 ++-
>  include/uapi/drm/i915_drm.h  |  33 ++
>  4 files changed, 161 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index 3d69e51f3e4d..2ab08b152b9d 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -204,7 +204,7 @@ compute_partial_view(const struct drm_i915_gem_object 
> *obj,
> return view;
>  }
>  
> -static vm_fault_t i915_error_to_vmf_fault(int err)
> +vm_fault_t i915_error_to_vmf_fault(int err)
>  {
> switch (err) {
> default:
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.h 
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
> index efee9e0d2508..1190a3a228ea 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
> @@ -29,4 +29,6 @@ void i915_gem_object_release_mmap_gtt(struct 
> drm_i915_gem_object *obj);
>  
>  void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj);
>  
> +vm_fault_t i915_error_to_vmf_fault(int err);
> +
>  #endif
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> index c91f2da84189..6fd669b520d8 100

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: nuke remaining legacy reg helpers (I915_READ/WRITE etc.) (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: nuke remaining legacy reg helpers (I915_READ/WRITE etc.) 
(rev3)
URL   : https://patchwork.freedesktop.org/series/83762/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
a12a7e1ea3de drm/i915/debugfs: remove RPS autotuning details from 
i915_rps_boost_info
419ca697fab7 drm/i915: remove last traces of I915_READ_FW() and I915_WRITE_FW()
c8a3444ee6ab drm/i915/cdclk: prefer intel_de_write() over I915_WRITE()
f19ef5c3dbac drm/i915/debugfs: remove the i915_cache_sharing debugfs file
25c9265e2821 drm/i915/debugfs: replace I915_READ() with intel_uncore_read()
-:381: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#381: FILE: drivers/gpu/drm/i915/i915_debugfs.c:879:
+   rpupei = intel_uncore_read(&dev_priv->uncore, 
GEN6_RP_CUR_UP_EI) & GEN6_CURICONT_MASK;

-:382: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#382: FILE: drivers/gpu/drm/i915/i915_debugfs.c:880:
+   rpcurup = intel_uncore_read(&dev_priv->uncore, GEN6_RP_CUR_UP) 
& GEN6_CURBSYTAVG_MASK;

-:383: WARNING:LONG_LINE: line length of 104 exceeds 100 columns
#383: FILE: drivers/gpu/drm/i915/i915_debugfs.c:881:
+   rpprevup = intel_uncore_read(&dev_priv->uncore, 
GEN6_RP_PREV_UP) & GEN6_CURBSYTAVG_MASK;

-:384: WARNING:LONG_LINE: line length of 105 exceeds 100 columns
#384: FILE: drivers/gpu/drm/i915/i915_debugfs.c:882:
+   rpdownei = intel_uncore_read(&dev_priv->uncore, 
GEN6_RP_CUR_DOWN_EI) & GEN6_CURIAVG_MASK;

-:385: WARNING:LONG_LINE: line length of 106 exceeds 100 columns
#385: FILE: drivers/gpu/drm/i915/i915_debugfs.c:883:
+   rpcurdown = intel_uncore_read(&dev_priv->uncore, 
GEN6_RP_CUR_DOWN) & GEN6_CURBSYTAVG_MASK;

-:386: WARNING:LONG_LINE: line length of 108 exceeds 100 columns
#386: FILE: drivers/gpu/drm/i915/i915_debugfs.c:884:
+   rpprevdown = intel_uncore_read(&dev_priv->uncore, 
GEN6_RP_PREV_DOWN) & GEN6_CURBSYTAVG_MASK;

-:394: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#394: FILE: drivers/gpu/drm/i915/i915_debugfs.c:890:
+   pm_ier = intel_uncore_read(&dev_priv->uncore, 
GEN11_GPM_WGBOXPERF_INTR_ENABLE);

-:395: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#395: FILE: drivers/gpu/drm/i915/i915_debugfs.c:891:
+   pm_imr = intel_uncore_read(&dev_priv->uncore, 
GEN11_GPM_WGBOXPERF_INTR_MASK);

total: 0 errors, 8 warnings, 0 checks, 397 lines checked
3e4c818848a6 drm/i915/suspend: replace I915_READ()/WRITE() with 
intel_de_read()/write()
-:30: CHECK:CAMELCASE: Avoid CamelCase: 
#30: FILE: drivers/gpu/drm/i915/i915_suspend.c:43:
+   dev_priv->regfile.saveSWF0[i] = intel_de_read(dev_priv, 
SWF0(i));

-:31: CHECK:CAMELCASE: Avoid CamelCase: 
#31: FILE: drivers/gpu/drm/i915/i915_suspend.c:44:
+   dev_priv->regfile.saveSWF1[i] = intel_de_read(dev_priv, 
SWF1(i));

-:35: CHECK:CAMELCASE: Avoid CamelCase: 
#35: FILE: drivers/gpu/drm/i915/i915_suspend.c:47:
+   dev_priv->regfile.saveSWF3[i] = intel_de_read(dev_priv, 
SWF3(i));

-:87: CHECK:CAMELCASE: Avoid CamelCase: 
#87: FILE: drivers/gpu/drm/i915/i915_suspend.c:92:
+   dev_priv->regfile.saveDSPARB = intel_de_read(dev_priv, DSPARB);

total: 0 errors, 0 warnings, 4 checks, 79 lines checked
23ca221bb2db drm/i915/pm: replace I915_READ()/WRITE() with 
intel_uncore_read()/write()
-:26: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#26: FILE: drivers/gpu/drm/i915/intel_pm.c:86:
+   intel_uncore_write(&dev_priv->uncore, CHICKEN_PAR1_1,
+  intel_uncore_read(&dev_priv->uncore, CHICKEN_PAR1_1) 
|

-:34: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#34: FILE: drivers/gpu/drm/i915/intel_pm.c:92:
+   intel_uncore_write(&dev_priv->uncore, CHICKEN_PAR1_1,
+  intel_uncore_read(&dev_priv->uncore, CHICKEN_PAR1_1) | 
SKL_EDP_PSR_FIX_RDWRAP);

-:40: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#40: FILE: drivers/gpu/drm/i915/intel_pm.c:96:
+   intel_uncore_write(&dev_priv->uncore, GEN8_CHICKEN_DCPR_1,
+  intel_uncore_read(&dev_priv->uncore, GEN8_CHICKEN_DCPR_1) | 
MASK_WAKEMEM);

-:47: WARNING:LONG_LINE: line length of 112 exceeds 100 columns
#47: FILE: drivers/gpu/drm/i915/intel_pm.c:102:
+   intel_uncore_write(&dev_priv->uncore, DISP_ARB_CTL, 
intel_uncore_read(&dev_priv->uncore, DISP_ARB_CTL) |

-:56: WARNING:LONG_LINE: line length of 112 exceeds 100 columns
#56: FILE: drivers/gpu/drm/i915/intel_pm.c:111:
+   intel_uncore_write(&dev_priv->uncore, GEN8_UCGCTL6, 
intel_uncore_read(&dev_priv->uncore, GEN8_UCGCTL6) |

-:64: WARNING:LONG_LINE: line length of 112 exceeds 100 columns
#64: FILE: drivers/gpu/drm/i915/intel_pm.c:118:
+   intel_uncore_write(&dev_priv->uncore, GEN8_UCGCTL6, 
intel_uncore_read(&dev_priv->uncore, GEN8_UCGCTL6) |

-:72: WARNING:LONG_LINE: line length of 124 e

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/lspcon: enter standby mode to enhance power saving (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/lspcon: enter standby mode to enhance power saving (rev2)
URL   : https://patchwork.freedesktop.org/series/83886/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9350_full -> Patchwork_18931_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_caching@read-writes:
- shard-hsw:  [PASS][1] -> [FAIL][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-hsw2/igt@gem_cach...@read-writes.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18931/shard-hsw5/igt@gem_cach...@read-writes.html

  * igt@gem_exec_schedule@manyslice@rcs0:
- shard-skl:  [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-skl1/igt@gem_exec_schedule@manysl...@rcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18931/shard-skl8/igt@gem_exec_schedule@manysl...@rcs0.html

  
New tests
-

  New tests have been introduced between CI_DRM_9350_full and 
Patchwork_18931_full:

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

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

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- shard-hsw:  [PASS][5] -> [FAIL][6] ([i915#1888])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-hsw2/igt@gem_exec_susp...@basic-s3.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18931/shard-hsw5/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_workarounds@suspend-resume:
- shard-apl:  [PASS][7] -> [INCOMPLETE][8] ([i915#1635])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-apl3/igt@gem_workarou...@suspend-resume.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18931/shard-apl3/igt@gem_workarou...@suspend-resume.html

  * igt@kms_cursor_crc@pipe-c-cursor-128x42-random:
- shard-skl:  [PASS][9] -> [FAIL][10] ([i915#54]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-skl5/igt@kms_cursor_...@pipe-c-cursor-128x42-random.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18931/shard-skl5/igt@kms_cursor_...@pipe-c-cursor-128x42-random.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-skl:  [PASS][11] -> [INCOMPLETE][12] ([i915#300])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-skl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18931/shard-skl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html

  * igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions:
- shard-skl:  [PASS][13] -> [DMESG-WARN][14] ([i915#1982] / 
[i915#2295])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-skl7/igt@kms_cursor_leg...@cursor-vs-flip-atomic-transitions.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18931/shard-skl1/igt@kms_cursor_leg...@cursor-vs-flip-atomic-transitions.html

  * igt@kms_cursor_legacy@flip-vs-cursor-legacy:
- shard-tglb: [PASS][15] -> [FAIL][16] ([i915#2346])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-tglb5/igt@kms_cursor_leg...@flip-vs-cursor-legacy.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18931/shard-tglb7/igt@kms_cursor_leg...@flip-vs-cursor-legacy.html

  * igt@kms_draw_crc@draw-method-rgb565-pwrite-untiled:
- shard-skl:  [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +4 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-skl7/igt@kms_draw_...@draw-method-rgb565-pwrite-untiled.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18931/shard-skl2/igt@kms_draw_...@draw-method-rgb565-pwrite-untiled.html

  * igt@kms_flip@2x-plain-flip-ts-check-interruptible@ab-vga1-hdmi-a1:
- shard-hsw:  [PASS][19] -> [DMESG-WARN][20] ([i915#1982])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-hsw7/igt@kms_flip@2x-plain-flip-ts-check-interrupti...@ab-vga1-hdmi-a1.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18931/shard-hsw1/igt@kms_flip@2x-plain-flip-ts-check-interrupti...@ab-vga1-hdmi-a1.html

  * igt@kms_flip@flip-vs-blocking-wf-vblank@c-edp1:
- shard-skl:  [PASS][21]

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2] gem_wsim: Implement device selection

[Tvrtko Ursulin]

On 17/11/2020 14:06, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2020-11-17 13:59:18)

From: Tvrtko Ursulin 

-L and -D  on the command line.

With no device specified tool tries to find i915 discrete or integrated in
that order.

v2:
  * Fix error handling and support render devices.

Signed-off-by: Tvrtko Ursulin 

Reviewed-by: Chris Wilson 

Hmm, optarg should be a pointer into the argv, so is the copy necessary?


I don't remember if I tried, and I don't see that getopt(3) explains 
optarg from that angle, so probably safest to keep as is. Too lazy to 
try.. Or maybe presence of strdup suggests I did already try and that 
optarg is indeed temporary copy managed by getopt.


Regards,

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

Re: [Intel-gfx] [PATCH 8/8] drm/i915/perf: Map OA buffer to user space for gen12 performance query

[Lionel Landwerlin]

Tests are on the IGT ml : 
https://patchwork.freedesktop.org/series/82352/ 



This feature was requested by the metrics-discovery team.
Pretty sure this was tested with it, maybe a branch can be shared by Piotr?

Cheers,

-Lionel

On 18/11/2020 13:41, Joonas Lahtinen wrote:

+ Umesh, Lionel

Do we have a link to the userspace changes and IGT tests? Those are
absolutely needed before we can do a final review and merge.

We should really test and review the kernel and userspace changes
together to make sure that we're coming up with a solid uAPI.

Regards, Joonas

Quoting Chris Wilson (2020-11-17 13:01:32)

From: Umesh Nerlige Ramappa 

i915 used to support time based sampling mode which is good for overall
system monitoring, but is not enough for query mode used to measure a
single draw call or dispatch. Gen9-Gen11 are using current i915 perf
implementation for query, but Gen12+ requires a new approach for query
based on triggered reports within oa buffer.

Triggering reports into the OA buffer is achieved by writing into a
a trigger register. Optionally an unused counter/register is set with a
marker value such that a triggered report can be identified in the OA
buffer. Reports are usually triggered at the start and end of work that
is measured.

Since OA buffer is large and queries can be frequent, an efficient way
to look for triggered reports is required. By knowing the current head
and tail offsets into the OA buffer, it is easier to determine the
locality of the reports of interest.

Current perf OA interface does not expose head/tail information to the
user and it filters out invalid reports before sending data to user.
Also considering limited size of user buffer used during a query,
creating a 1:1 copy of the OA buffer at the user space added undesired
complexity.

The solution was to map the OA buffer to user space provided

(1) that it is accessed from a privileged user.
(2) OA report filtering is not used.

These 2 conditions would satisfy the safety criteria that the current
perf interface addresses.

To enable the query:
- Add an ioctl to expose head and tail to the user
- Add an ioctl to return size and offset of the OA buffer
- Map the OA buffer to the user space

v2:
- Improve commit message (Chris)
- Do not mmap based on gem object filp. Instead, use perf_fd and support
   mmap syscall (Chris)
- Pass non-zero offset in mmap to enforce the right object is
   mapped (Chris)
- Do not expose gpu_address (Chris)
- Verify start and length of vma for page alignment (Lionel)
- Move SQNTL config out (Lionel)

v3: (Chris)
- Omit redundant checks
- Return VM_FAULT_SIGBUS is old stream is closed
- Maintain reference counts to stream in vm_open and vm_close
- Use switch to identify object to be mapped

v4: Call kref_put on closing perf fd (Chris)
v5:
- Strip access to OA buffer from unprivileged child of a privileged
   parent. Use VM_DONTCOPY
- Enforce MAP_PRIVATE by checking for VM_MAYSHARE

v6:
(Chris)
- Use len of -1 in unmap_mapping_range
- Don't use stream->oa_buffer.vma->obj in vm_fault_oa
- Use kernel block comment style
- do_mmap gets a reference to the file and puts it in do_munmap, so
   no need to maintain a reference to i915_perf_stream. Hence, remove
   vm_open/vm_close and stream->closed hooks/checks.
(Umesh)
- Do not allow mmap if SAMPLE_OA_REPORT is not set during
   i915_perf_open_ioctl.
- Drop ioctl returning head/tail since this information is already
   whitelisted. Remove hooks to read head register.

v7: (Chris)
- unmap before destroy
- change ioctl argument struct

v8: Documentation and more checks (Chris)

Signed-off-by: Piotr Maciejewski 
Signed-off-by: Umesh Nerlige Ramappa 
Reviewed-by: Chris Wilson 
---
  drivers/gpu/drm/i915/gem/i915_gem_mman.c |   2 +-
  drivers/gpu/drm/i915/gem/i915_gem_mman.h |   2 +
  drivers/gpu/drm/i915/i915_perf.c | 126 ++-
  include/uapi/drm/i915_drm.h  |  33 ++
  4 files changed, 161 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 3d69e51f3e4d..2ab08b152b9d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -204,7 +204,7 @@ compute_partial_view(const struct drm_i915_gem_object *obj,
 return view;
  }
  
-static vm_fault_t i915_error_to_vmf_fault(int err)

+vm_fault_t i915_error_to_vmf_fault(int err)
  {
 switch (err) {
 default:
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.h 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
index efee9e0d2508..1190a3a228ea 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
@@ -29,4 +29,6 @@ void i915_gem_object_release_mmap_gtt(struct 
drm_i915_gem_object *obj);
  
  void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj);
  
+vm_fault_t i915_error_to_vmf_fault(int err);

+
  #endif
diff --git

Re: [Intel-gfx] [PATCH 14/28] drm/i915/gt: Free stale request on destroying the virtual engine

[Chris Wilson]

Quoting Tvrtko Ursulin (2020-11-18 11:38:43)
> 
> On 18/11/2020 11:24, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-11-18 11:05:24)
> >>
> >> On 17/11/2020 11:30, Chris Wilson wrote:
> >>> Since preempt-to-busy, we may unsubmit a request while it is still on
> >>> the HW and completes asynchronously. That means it may be retired and in
> >>> the process destroy the virtual engine (as the user has closed their
> >>> context), but that engine may still be holding onto the unsubmitted
> >>> compelted request. Therefore we need to potentially cleanup the old
> >>> request on destroying the virtual engine. We also have to keep the
> >>> virtual_engine alive until after the sibling's execlists_dequeue() have
> >>> finished peeking into the virtual engines, for which we serialise with
> >>> RCU.
> >>>
> >>> v2: Be paranoid and flush the tasklet as well.
> >>> v3: And flush the tasklet before the engines, as the tasklet may
> >>> re-attach an rb_node after our removal from the siblings.
> >>>
> >>> Signed-off-by: Chris Wilson 
> >>> Cc: Tvrtko Ursulin 
> >>> ---
> >>>drivers/gpu/drm/i915/gt/intel_lrc.c | 61 +
> >>>1 file changed, 54 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
> >>> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> index 17cb7060eb29..c11433884cf6 100644
> >>> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> @@ -182,6 +182,7 @@
> >>>struct virtual_engine {
> >>>struct intel_engine_cs base;
> >>>struct intel_context context;
> >>> + struct rcu_work rcu;
> >>>
> >>>/*
> >>> * We allow only a single request through the virtual engine at a 
> >>> time
> >>> @@ -5470,44 +5471,90 @@ static struct list_head *virtual_queue(struct 
> >>> virtual_engine *ve)
> >>>return &ve->base.execlists.default_priolist.requests[0];
> >>>}
> >>>
> >>> -static void virtual_context_destroy(struct kref *kref)
> >>> +static void rcu_virtual_context_destroy(struct work_struct *wrk)
> >>>{
> >>>struct virtual_engine *ve =
> >>> - container_of(kref, typeof(*ve), context.ref);
> >>> + container_of(wrk, typeof(*ve), rcu.work);
> >>>unsigned int n;
> >>>
> >>> - GEM_BUG_ON(!list_empty(virtual_queue(ve)));
> >>> - GEM_BUG_ON(ve->request);
> >>>GEM_BUG_ON(ve->context.inflight);
> >>>
> >>> + /* Preempt-to-busy may leave a stale request behind. */
> >>> + if (unlikely(ve->request)) {
> >>> + struct i915_request *old;
> >>> +
> >>> + spin_lock_irq(&ve->base.active.lock);
> >>> +
> >>> + old = fetch_and_zero(&ve->request);
> >>> + if (old) {
> >>> + GEM_BUG_ON(!i915_request_completed(old));
> >>> + __i915_request_submit(old);
> >>> + i915_request_put(old);
> >>> + }
> >>> +
> >>> + spin_unlock_irq(&ve->base.active.lock);
> >>> + }
> >>> +
> >>> + /*
> >>> +  * Flush the tasklet in case it is still running on another core.
> >>> +  *
> >>> +  * This needs to be done before we remove ourselves from the 
> >>> siblings'
> >>> +  * rbtrees as in the case it is running in parallel, it may reinsert
> >>> +  * the rb_node into a sibling.
> >>> +  */
> >>> + tasklet_kill(&ve->base.execlists.tasklet);
> >>
> >> Can it still be running after an RCU period?
> > 
> > I think there is a window between checking to see if the request is
> > completed and kicking the tasklet, that is not under the rcu lock and
> > opportunity for the request to be retired, and barrier flushed to drop
> > the context references.
> 
>  From where would that check come?

The window of opportunity extends all the way from the
i915_request_completed check during unsubmit right until the virtual
engine tasklet is executed -- we do not hold a reference to the virtual
engine for the tasklet, and that request may be retired in the
background, and along with it the virtual engine destroyed.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: nuke remaining legacy reg helpers (I915_READ/WRITE etc.) (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: nuke remaining legacy reg helpers (I915_READ/WRITE etc.) 
(rev3)
URL   : https://patchwork.freedesktop.org/series/83762/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9351 -> Patchwork_18932


Summary
---

  **SUCCESS**

  No regressions found.

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

New tests
-

  New tests have been introduced between CI_DRM_9351 and Patchwork_18932:

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

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

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_sync@basic-each:
- fi-tgl-y:   [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +2 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/fi-tgl-y/igt@gem_s...@basic-each.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18932/fi-tgl-y/igt@gem_s...@basic-each.html

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2:  [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18932/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-tgl-y:   [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +1 similar 
issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18932/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html

  
 Possible fixes 

  * igt@i915_getparams_basic@basic-subslice-total:
- fi-tgl-y:   [DMESG-WARN][9] ([i915#402]) -> [PASS][10] +2 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18932/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka:  [INCOMPLETE][11] -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18932/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [FAIL][13] ([i915#1161] / [i915#262]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18932/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

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

  
 Warnings 

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

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-tgl-y:   [DMESG-WARN][19] ([i915#1982] / [i915#2411]) -> 
[DMESG-WARN][20] ([i915#2411])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18932/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html

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


Participating hosts (41 -> 39)
--

  Additional (3): fi-hsw-4770 fi-blb-e6850 fi-tgl-u2 
  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-

[Intel-gfx] [PULL] drm-misc-next

[Thomas Zimmermann]

Hi Dave and Daniel,

here's this week's PR for drm-misc-next. It's fairly large, but most of
the patches fix kernel build warnings. The rest is the usual mixture of
cleanups and small fixes. The panel code gained support for new devices.

Best regards
Thomas

drm-misc-next-2020-11-18:
drm-misc-next for 5.11:

UAPI Changes:

 * media: Add MEDIA_BUS_FMT_RGB888_3X8_DELTA format

Cross-subsystem Changes:

 * console: Remove unused functions; Store characters-per-font in font-
   descriptor structure instead of hard-coding
 * DT: Add vendor prefix for ShenZhen Asia Better Technology Ltd. (ABT)

Core Changes:

 * Fix build warnings
 * Update debug logging to new interfaces, plus fixes
 * Add error messages for ioctls;
 * Fix kernel docs
 * doc: Fix kernel docs
 * fbcon: Remove accelerated scrolling
 * selftests: Fix build warnings
 * ttm: Fix missing NULL check in new page pool; Fix build warnings
 * video: Fix kernel docs

Driver Changes:

 * armada: Fix build warnings
 * atmel-hlcdc: Fix build warnings
 * exynos: Fix build warnings
 * gma500: Remove 2d framebuffer acceleration
 * lima: Fix build warnings; Cleanups
 * mediatek: Fix build warnings
 * meson: Module removal fixes; Fix build warnings
 * nouveau: Fix build warnings
 * omap: Fix return values
 * panel: Fix build warnings; Add support and DT bindings for OnePlus 6/T; Add
   support and DT bindings for ABT Y030XX067A
 * panel/s6e63m0: Add/improve SPi reading/writing; Support 3WIRE protocol; Set
   connector display info; Add more comments
 * panfrost: Move GPU reset into separate worker, avoid race conditions
 * pl111: Fix build warnings
 * qxl: Cleanup fbcon acceleration
 * rockchip: Fix build warnings
 * savage: Fix build warnings
 * sti: Fix build warnings
 * udl: Fix missing error code in udl_handle_damage()
 * v3d: Fix build warnings
 * vc4: Fix build warnings
 * via: Fix build warnings
 * virtio: Make dma-buf ops static
The following changes since commit 05481f072787e96d08cc304cda0c10e0d02cdadc:

  drm/kmb: fix spelling mistakes in drm_info and drm_dbg messages (2020-11-11 
22:00:05 +0100)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2020-11-18

for you to fetch changes up to fa388231fec99b60346319d56495ae531b666275:

  drm/docs: Fix todo.rst (2020-11-18 11:51:58 +0100)


drm-misc-next for 5.11:

UAPI Changes:

 * media: Add MEDIA_BUS_FMT_RGB888_3X8_DELTA format

Cross-subsystem Changes:

 * console: Remove unused functions; Store characters-per-font in font-
   descriptor structure instead of hard-coding
 * DT: Add vendor prefix for ShenZhen Asia Better Technology Ltd. (ABT)

Core Changes:

 * Fix build warnings
 * Update debug logging to new interfaces, plus fixes
 * Add error messages for ioctls;
 * Fix kernel docs
 * doc: Fix kernel docs
 * fbcon: Remove accelerated scrolling
 * selftests: Fix build warnings
 * ttm: Fix missing NULL check in new page pool; Fix build warnings
 * video: Fix kernel docs

Driver Changes:

 * armada: Fix build warnings
 * atmel-hlcdc: Fix build warnings
 * exynos: Fix build warnings
 * gma500: Remove 2d framebuffer acceleration
 * lima: Fix build warnings; Cleanups
 * mediatek: Fix build warnings
 * meson: Module removal fixes; Fix build warnings
 * nouveau: Fix build warnings
 * omap: Fix return values
 * panel: Fix build warnings; Add support and DT bindings for OnePlus 6/T; Add
   support and DT bindings for ABT Y030XX067A
 * panel/s6e63m0: Add/improve SPi reading/writing; Support 3WIRE protocol; Set
   connector display info; Add more comments
 * panfrost: Move GPU reset into separate worker, avoid race conditions
 * pl111: Fix build warnings
 * qxl: Cleanup fbcon acceleration
 * rockchip: Fix build warnings
 * savage: Fix build warnings
 * sti: Fix build warnings
 * udl: Fix missing error code in udl_handle_damage()
 * v3d: Fix build warnings
 * vc4: Fix build warnings
 * via: Fix build warnings
 * virtio: Make dma-buf ops static


Boris Brezillon (1):
  drm/panfrost: Move the GPU reset bits outside the timeout handler

Caleb Connolly (2):
  dt-bindings: panel-simple-dsi: add samsung panels for OnePlus 6/T
  drm/panel/samsung-sofef00: Add panel for OnePlus 6/T devices

Christian König (1):
  drm/ttm: fix missing NULL check in the new page pool

Dan Carpenter (1):
  drm/udl: Fix missing error code in udl_handle_damage()

Daniel Vetter (4):
  fbcon: Disable accelerated scrolling
  fbcon: Drop EXPORT_SYMBOL
  drm/qxl: Remove fbcon acceleration leftovers
  drm/docs: Fix todo.rst

Lee Jones (44):
  drm/atmel-hlcdc/atmel_hlcdc_crtc: Apply correct formatting to struct docs
  drm/atmel-hlcdc/atmel_hlcdc_plane: Staticise local function 
'atmel_hlcdc_plane_setup_scaler()'
  drm/atmel-hlcdc/atmel_hlcdc_plane: Fix documentation formatting and add 
missing description
  drm/savage/sava

[Intel-gfx] [PATCH] drm/i915/dsi: Use unconditional msleep for the panel_on_delay when there is no reset-deassert MIPI-sequence

[Hans de Goede]

Commit 25b4620ee822 ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode")
added an intel_dsi_msleep() helper which skips sleeping if the
MIPI-sequences have a version of 3 or newer and the panel is in vid-mode;
and it moved a bunch of msleep-s over to this new helper.

This was based on my reading of the big comment around line 730 which
starts with "Panel enable/disable sequences from the VBT spec.",
where the "v3 video mode seq" column does not have any wait t# entries.

Given that this code has been used on a lot of different devices without
issues until now, it seems that my interpretation of the spec here is
mostly correct.

But now I have encountered one device, an Acer Aspire Switch 10 E
SW3-016, where the panel will not light up unless we do actually honor the
panel_on_delay after exexuting the MIPI_SEQ_PANEL_ON sequence.

What seems to set this model apart is that it is lacking a
MIPI_SEQ_DEASSERT_RESET sequence, which is where the power-on
delay usually happens.

Fix the panel not lighting up on this model by using an unconditional
msleep(panel_on_delay) instead of intel_dsi_msleep() when there is
no MIPI_SEQ_DEASSERT_RESET sequence.

Fixes: 25b4620ee822 ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode")
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/vlv_dsi.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c 
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index 194c239ab6b1..ef673277b36d 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -816,10 +816,14 @@ static void intel_dsi_pre_enable(struct 
intel_atomic_state *state,
intel_dsi_prepare(encoder, pipe_config);
 
intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
-   intel_dsi_msleep(intel_dsi, intel_dsi->panel_on_delay);
 
-   /* Deassert reset */
-   intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
+   if (dev_priv->vbt.dsi.sequence[MIPI_SEQ_DEASSERT_RESET]) {
+   intel_dsi_msleep(intel_dsi, intel_dsi->panel_on_delay);
+   /* Deassert reset */
+   intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
+   } else {
+   msleep(intel_dsi->panel_on_delay);
+   }
 
if (IS_GEMINILAKE(dev_priv)) {
glk_cold_boot = glk_dsi_enable_io(encoder);
-- 
2.28.0

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

[Intel-gfx] [PATCH v3] drm/i915/lspcon: enter standby mode to enhance power saving

[Lee Shawn C]

After system boot up, LSPCON will be configured as PCON mode.
But it never go into power saving state. Source driver can
do the following. Then LSPCON can enter standby mode
automatically to save more power.

1. At PCON mode, source driver write 0x2 to DPCD 600h.
2. At LS mode, try to disable DP_DUAL_MODE_TMDS_OEN.

v2: fix typo
v3: After turn main lin off, found particular monitor
trigger HPD to LSPCON. Then short HPD would forward
to source. If driver did not enable display output
when received this HPD. Source should request LSPCON to
enter standby mode again.

Cc: Ville Syrjälä 
Cc: Jani Nikula 
Cc: Uma Shankar 
Cc: Cooper Chiou 
Cc: Khaled Almahallawy 
Signed-off-by: Lee Shawn C 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 11 +++-
 drivers/gpu/drm/i915/display/intel_lspcon.c | 30 +
 drivers/gpu/drm/i915/display/intel_lspcon.h |  1 +
 3 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index ec8359f03aaf..7876d785b50f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6184,6 +6184,7 @@ static bool
 intel_dp_short_pulse(struct intel_dp *intel_dp)
 {
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+   struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
u8 old_sink_count = intel_dp->sink_count;
bool ret;
 
@@ -6211,6 +6212,9 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
/* Handle CEC interrupts, if any */
drm_dp_cec_irq(&intel_dp->aux);
 
+   if (lspcon && lspcon->active)
+   lspcon_standby(dp_to_dig_port(intel_dp));
+
/* defer to the hotplug work for link retraining if needed */
if (intel_dp_needs_link_retrain(intel_dp))
return false;
@@ -6536,6 +6540,7 @@ intel_dp_detect(struct drm_connector *connector,
struct drm_i915_private *dev_priv = to_i915(connector->dev);
struct intel_dp *intel_dp = 
intel_attached_dp(to_intel_connector(connector));
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
struct intel_encoder *encoder = &dig_port->base;
enum drm_connector_status status;
 
@@ -6632,9 +6637,13 @@ intel_dp_detect(struct drm_connector *connector,
intel_dp_check_service_irq(intel_dp);
 
 out:
-   if (status != connector_status_connected && !intel_dp->is_mst)
+   if (status != connector_status_connected && !intel_dp->is_mst) {
intel_dp_unset_edid(intel_dp);
 
+   if (lspcon && lspcon->active)
+   lspcon_standby(dp_to_dig_port(intel_dp));
+   }
+
/*
 * Make sure the refs for power wells enabled during detect are
 * dropped to avoid a new detect cycle triggered by HPD polling.
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index e37d45e531df..700f5604d9f6 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -550,6 +550,36 @@ static bool lspcon_init(struct intel_digital_port 
*dig_port)
return true;
 }
 
+void lspcon_standby(struct intel_digital_port *dig_port)
+{
+   struct intel_dp *dp = &dig_port->dp;
+   u8 align_status = 0xff, training_pattern = 0xff;
+
+   if (drm_dp_dpcd_readb(&dp->aux, DP_LANE_ALIGN_STATUS_UPDATED, 
&align_status) <= 0) {
+   DRM_ERROR("LSPCON failed to read align status\n");
+   return;
+   }
+
+   if (drm_dp_dpcd_readb(&dp->aux, DP_TRAINING_PATTERN_SET, 
&training_pattern) <= 0) {
+   DRM_ERROR("LSPCON failed to read training pattern set\n");
+   return;
+   }
+
+   /*
+* If link trainig is ongoing. Or sink updated link align status.
+* Source driver should not set LSPCON power state to D3.
+*/
+   if (align_status || training_pattern) {
+   DRM_DEBUG_KMS("LSPCON link training or display is working\n");
+   DRM_DEBUG_KMS("LSPCON DPCD register 0102h = %x, 0204h = 0x%x\n",
+ training_pattern, align_status);
+   return;
+   }
+
+   if (drm_dp_dpcd_writeb(&dp->aux, DP_SET_POWER, DP_SET_POWER_D3) <= 0)
+   DRM_DEBUG_KMS("LSPCON failed to write power state to D3\n");
+}
+
 void lspcon_resume(struct intel_digital_port *dig_port)
 {
struct intel_lspcon *lspcon = &dig_port->lspcon;
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.h 
b/drivers/gpu/drm/i915/display/intel_lspcon.h
index b03dcb7076d8..658a2e5b22db 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.h
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.h
@@ -16,6 +16,7 @@ struct intel_encoder;
 struct intel_lspcon;
 
 void lspcon_resume(struct intel_digital_port *dig_port);
+void lspcon_standby(struct intel_digital

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsi: Use unconditional msleep for the panel_on_delay when there is no reset-deassert MIPI-sequence

[Patchwork]

== Series Details ==

Series: drm/i915/dsi: Use unconditional msleep for the panel_on_delay when 
there is no reset-deassert MIPI-sequence
URL   : https://patchwork.freedesktop.org/series/84017/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9351 -> Patchwork_18933


Summary
---

  **SUCCESS**

  No regressions found.

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

New tests
-

  New tests have been introduced between CI_DRM_9351 and Patchwork_18933:

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

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

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_mmap_gtt@basic:
- fi-tgl-y:   [PASS][1] -> [DMESG-WARN][2] ([i915#402])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/fi-tgl-y/igt@gem_mmap_...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18933/fi-tgl-y/igt@gem_mmap_...@basic.html

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

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-n3050:   [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18933/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@module-reload:
- fi-byt-j1900:   [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/fi-byt-j1900/igt@i915_pm_...@module-reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18933/fi-byt-j1900/igt@i915_pm_...@module-reload.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- fi-icl-u2:  [PASS][11] -> [DMESG-WARN][12] ([i915#1982])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18933/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-tgl-y:   [PASS][13] -> [DMESG-WARN][14] ([i915#1982])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18933/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html

  
 Possible fixes 

  * igt@i915_getparams_basic@basic-subslice-total:
- fi-tgl-y:   [DMESG-WARN][15] ([i915#402]) -> [PASS][16] +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18933/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html

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

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [FAIL][19] ([i915#1161] / [i915#262]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18933/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

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

  
 Warnings 

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

[Intel-gfx] [PATCH] drm/i915/gt: Remember to free the virtual breadcrumbs

[Chris Wilson]

Since we allocate some breadcrumbs for the virtual engine, and the
virtual engine has a custom destructor, we also need to free the
breadcrumbs after use.

Fixes: b3786b29379c ("drm/i915/gt: Distinguish the virtual breadcrumbs from the 
irq breadcrumbs")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_lrc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 8a51c1c3a091..eaa0a9f38ae5 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -5512,6 +5512,7 @@ static void virtual_context_destroy(struct kref *kref)
__execlists_context_fini(&ve->context);
intel_context_fini(&ve->context);
 
+   intel_breadcrumbs_free(ve->base.breadcrumbs);
intel_engine_free_request_pool(&ve->base);
 
kfree(ve->bonds);
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH] drm/i915/gt: Remember to free the virtual breadcrumbs

[Tvrtko Ursulin]

On 18/11/2020 13:38, Chris Wilson wrote:

Since we allocate some breadcrumbs for the virtual engine, and the
virtual engine has a custom destructor, we also need to free the
breadcrumbs after use.

Fixes: b3786b29379c ("drm/i915/gt: Distinguish the virtual breadcrumbs from the irq 
breadcrumbs")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/gt/intel_lrc.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 8a51c1c3a091..eaa0a9f38ae5 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -5512,6 +5512,7 @@ static void virtual_context_destroy(struct kref *kref)
__execlists_context_fini(&ve->context);
intel_context_fini(&ve->context);
  
+	intel_breadcrumbs_free(ve->base.breadcrumbs);

intel_engine_free_request_pool(&ve->base);
  
  	kfree(ve->bonds);




Reviewed-by: Tvrtko Ursulin 

Regards,

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/lspcon: enter standby mode to enhance power saving (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/lspcon: enter standby mode to enhance power saving (rev3)
URL   : https://patchwork.freedesktop.org/series/83886/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9351 -> Patchwork_18934


Summary
---

  **FAILURE**

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

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u:   [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18934/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html

  
New tests
-

  New tests have been introduced between CI_DRM_9351 and Patchwork_18934:

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

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

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [PASS][3] -> [FAIL][4] ([i915#227])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18934/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

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

  * igt@kms_flip@basic-flip-vs-wf_vblank@b-dp1:
- fi-skl-lmem:[PASS][7] -> [FAIL][8] ([i915#2122])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/fi-skl-lmem/igt@kms_flip@basic-flip-vs-wf_vbl...@b-dp1.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18934/fi-skl-lmem/igt@kms_flip@basic-flip-vs-wf_vbl...@b-dp1.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka:  [INCOMPLETE][9] -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18934/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [FAIL][11] ([i915#1161] / [i915#262]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18934/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

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

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

  [i915#1161]: https://gitlab.freedesktop.org/drm/intel/issues/1161
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122
  [i915#227]: https://gitlab.freedesktop.org/drm/intel/issues/227
  [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
  [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262


Participating hosts (41 -> 38)
--

  Additional (3): fi-hsw-4770 fi-blb-e6850 fi-tgl-u2 
  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-tgl-y 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9351 -> Patchwork_18934

  CI-20190529: 20190529
  CI_DRM_9351: b676373b31de969a7296a8eaecc8ceab600dd655 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5856: d9b09131eaeed3f3bf5b68d8b5f18516b1659b1d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_18934: c7319b1722f19aabfed7cc24ebb5de9e4ca9d875 @ 
git://anongit.free

[Intel-gfx] ✗ Fi.CI.IGT: failure for Introduce Alderlake-S (rev2)

[Patchwork]

== Series Details ==

Series: Introduce Alderlake-S (rev2)
URL   : https://patchwork.freedesktop.org/series/82917/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9350_full -> Patchwork_18927_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_caching@read-writes:
- shard-hsw:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-hsw2/igt@gem_cach...@read-writes.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18927/shard-hsw4/igt@gem_cach...@read-writes.html

  
 Suppressed 

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

  * {igt@gem_userptr_blits@huge-split}:
- shard-hsw:  [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-hsw2/igt@gem_userptr_bl...@huge-split.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18927/shard-hsw4/igt@gem_userptr_bl...@huge-split.html

  
New tests
-

  New tests have been introduced between CI_DRM_9350_full and 
Patchwork_18927_full:

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

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

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_reloc@basic-many-active@rcs0:
- shard-hsw:  [PASS][5] -> [FAIL][6] ([i915#2389])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-hsw8/igt@gem_exec_reloc@basic-many-act...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18927/shard-hsw4/igt@gem_exec_reloc@basic-many-act...@rcs0.html

  * igt@gem_exec_suspend@basic-s3:
- shard-hsw:  [PASS][7] -> [FAIL][8] ([i915#1888])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-hsw2/igt@gem_exec_susp...@basic-s3.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18927/shard-hsw4/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_exec_whisper@basic-contexts-forked:
- shard-hsw:  [PASS][9] -> [TIMEOUT][10] ([i915#2502])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-hsw2/igt@gem_exec_whis...@basic-contexts-forked.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18927/shard-hsw4/igt@gem_exec_whis...@basic-contexts-forked.html

  * igt@gem_workarounds@suspend-resume:
- shard-apl:  [PASS][11] -> [INCOMPLETE][12] ([i915#1635])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-apl3/igt@gem_workarou...@suspend-resume.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18927/shard-apl1/igt@gem_workarou...@suspend-resume.html

  * igt@kms_cursor_crc@pipe-a-cursor-128x42-offscreen:
- shard-glk:  [PASS][13] -> [FAIL][14] ([i915#54])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-glk3/igt@kms_cursor_...@pipe-a-cursor-128x42-offscreen.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18927/shard-glk6/igt@kms_cursor_...@pipe-a-cursor-128x42-offscreen.html

  * igt@kms_cursor_crc@pipe-b-cursor-256x256-offscreen:
- shard-skl:  [PASS][15] -> [FAIL][16] ([i915#54])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-skl4/igt@kms_cursor_...@pipe-b-cursor-256x256-offscreen.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18927/shard-skl7/igt@kms_cursor_...@pipe-b-cursor-256x256-offscreen.html

  * igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-kbl:  [PASS][17] -> [DMESG-WARN][18] ([i915#180])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-kbl3/igt@kms_cursor_...@pipe-b-cursor-suspend.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18927/shard-kbl7/igt@kms_cursor_...@pipe-b-cursor-suspend.html

  * igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions:
- shard-skl:  [PASS][19] -> [DMESG-WARN][20] ([i915#1982] / 
[i915#2295])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9350/shard-skl7/igt@kms_cursor_leg...@cursor-vs-flip-atomic-transitions.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18927/shard-skl8/igt@kms_cursor_leg...@cursor-vs-flip-atomic-transitions.html

  * igt@kms_cursor_legacy@flip-vs-cursor-legacy:
- shard-tglb: [PASS][21] -> [FAIL][22] ([i915#2346])
   [21]: 
htt

Re: [Intel-gfx] [PATCH 08/28] drm/i915/gt: Show all active timelines for debugging

[Tvrtko Ursulin]

On 17/11/2020 13:25, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2020-11-17 12:59:44)


On 17/11/2020 11:30, Chris Wilson wrote:

+ if (show_request) {
+ list_for_each_entry_safe(rq, rn, &tl->requests, link)
+ show_request(m, rq,
+  i915_request_is_active(rq) ? "  E" :
+  i915_request_is_ready(rq) ? "  Q" :
+  "  U");


Can we get some consistency between the category counts and flags.

s/count/queued/ -> Q


Hmm, if you are sure. Q would then not match with the engine info.


Sure? Not really. What do we have there? You mean "!/*/+/-" flags? Or 
"E/Q/V" from intel_execlists_show_requests? Right, 'Q' there means 
runnable and it doesn't show queued at all. Yes, why not change everything.



Still favouring count over queued; I think count indicates more clearly
that it is the superset, but queued may imply it excludes ready and
definitely sounds like it should not include inflight.


I am okay with that.


ready -> R (also matches with term runnable)
active -> E ? hmmm E is consistent with the engine info dump.

Not ideal but perhaps every bit of more consistency is good.


Not sold yet, but not happy with the current flags either.

If we go with 'R' for ready, we should also update engine info.


Okay we seem to have plenty of options.

U or Q - queued/unready
R or Q - ready/queued (to backend) (Rv/Qv for virtual?)
E or R, or I - executing/running/in-flight

Q -> R -> E
U -> R -> E
U -> Q -> E/R/I
U -> R -> E/I

I don't know.. either one as long as all places use the same.

Regards,

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

[Intel-gfx] [PATCH i-g-t] intel_error_decode: Handle no decoding context

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

If decoding context couldn't be created, say the local libdrm does not
support the GPU which created the error state, it is much more handy to
at least decode and dump metadata and rings.

Signed-off-by: Tvrtko Ursulin 
---
 tools/intel_error_decode.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/tools/intel_error_decode.c b/tools/intel_error_decode.c
index 356ce37274f9..90a18a07ba17 100644
--- a/tools/intel_error_decode.c
+++ b/tools/intel_error_decode.c
@@ -465,7 +465,7 @@ static void decode(struct drm_intel_decode *ctx,
   (unsigned)((head_offset + gtt_offset) & 0x));
printf("\n");
 
-   if (decode) {
+   if (decode && ctx) {
drm_intel_decode_set_batch_pointer(ctx, data, gtt_offset,
   *count);
drm_intel_decode(ctx);
@@ -707,7 +707,10 @@ read_data_file(FILE *file)
matched = sscanf(line, "  ACTHD: 0x%08x\n", ®);
if (matched == 1) {
print_acthd(reg, ring_length);
-   drm_intel_decode_set_head_tail(decode_ctx, reg, 
0x);
+   if (decode_ctx)
+   
drm_intel_decode_set_head_tail(decode_ctx,
+  reg,
+  
0x);
}
 
matched = sscanf(line, "  PGTBL_ER: 0x%08x\n", ®);
-- 
2.25.1

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

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

[Jani Nikula]

None of the relay users require the use of mutable structs for
callbacks, however the relay code does. Instead of assigning default
callbacks when there is none, add callback wrappers to conditionally
call the client callbacks if available, and fall back to default
behaviour (typically no-op) otherwise.

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

Cc: linux-bl...@vger.kernel.org
Cc: Jens Axboe 
Cc: ath...@lists.infradead.org
Cc: ath...@lists.infradead.org
Cc: Kalle Valo 
Cc: linux-wirel...@vger.kernel.org
Cc: QCA ath9k Development 
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Jani Nikula 
---
 include/linux/relay.h |   4 +-
 kernel/relay.c| 182 +++---
 2 files changed, 86 insertions(+), 100 deletions(-)

diff --git a/include/linux/relay.h b/include/linux/relay.h
index e13a333e7c37..7333909df65a 100644
--- a/include/linux/relay.h
+++ b/include/linux/relay.h
@@ -62,7 +62,7 @@ struct rchan
size_t subbuf_size; /* sub-buffer size */
size_t n_subbufs;   /* number of sub-buffers per buffer */
size_t alloc_size;  /* total buffer size allocated */
-   struct rchan_callbacks *cb; /* client callbacks */
+   const struct rchan_callbacks *cb; /* client callbacks, may be NULL */
struct kref kref;   /* channel refcount */
void *private_data; /* for user-defined data */
size_t last_toobig; /* tried to log event > subbuf size */
@@ -170,7 +170,7 @@ struct rchan *relay_open(const char *base_filename,
 struct dentry *parent,
 size_t subbuf_size,
 size_t n_subbufs,
-struct rchan_callbacks *cb,
+const struct rchan_callbacks *cb,
 void *private_data);
 extern int relay_late_setup_files(struct rchan *chan,
  const char *base_filename,
diff --git a/kernel/relay.c b/kernel/relay.c
index b08d936d5fa7..c53676f2d10f 100644
--- a/kernel/relay.c
+++ b/kernel/relay.c
@@ -27,13 +27,86 @@
 static DEFINE_MUTEX(relay_channels_mutex);
 static LIST_HEAD(relay_channels);
 
+/*
+ * rchan_callback wrappers. Call the callbacks if available, otherwise fall 
back
+ * to default behaviour.
+ */
+
+/*
+ * subbuf_start() callback.
+ */
+static int cb_subbuf_start(const struct rchan_callbacks *cb,
+  struct rchan_buf *buf,
+  void *subbuf,
+  void *prev_subbuf,
+  size_t prev_padding)
+{
+   if (cb && cb->subbuf_start)
+   return cb->subbuf_start(buf, subbuf, prev_subbuf, prev_padding);
+
+   if (relay_buf_full(buf))
+   return 0;
+
+   return 1;
+}
+
+/*
+ * buf_mapped() callback.
+ */
+static void cb_buf_mapped(const struct rchan_callbacks *cb,
+ struct rchan_buf *buf,
+ struct file *filp)
+{
+   if (cb && cb->buf_mapped)
+   cb->buf_mapped(buf, filp);
+}
+
+/*
+ * buf_unmapped() callback.
+ */
+static void cb_buf_unmapped(const struct rchan_callbacks *cb,
+   struct rchan_buf *buf,
+   struct file *filp)
+{
+   if (cb && cb->buf_unmapped)
+   cb->buf_unmapped(buf, filp);
+}
+
+/*
+ * create_buf_file_create() callback.
+ */
+static struct dentry *cb_create_buf_file(const struct rchan_callbacks *cb,
+const char *filename,
+struct dentry *parent,
+umode_t mode,
+struct rchan_buf *buf,
+int *is_global)
+{
+   if (cb && cb->create_buf_file)
+   return cb->create_buf_file(filename, parent, mode, buf, 
is_global);
+
+   return NULL;
+}
+
+/*
+ * remove_buf_file() callback.
+ */
+static int cb_remove_buf_file(const struct rchan_callbacks *cb,
+ struct dentry *dentry)
+{
+   if (cb && cb->remove_buf_file)
+   return cb->remove_buf_file(dentry);
+
+   return -EINVAL;
+}
+
 /*
  * close() vm_op implementation for relay file mapping.
  */
 static void relay_file_mmap_close(struct vm_area_struct *vma)
 {
struct rchan_buf *buf = vma->vm_private_data;
-   buf->chan->cb->buf_unmapped(buf, vma->vm_file);
+   cb_buf_unmapped(buf->chan->cb, buf, vma->vm_file);
 }
 
 /*
@@ -107,7 +180,7 @@ static int relay_mmap_buf(struct rchan_buf *buf, struct 
vm_area_struct *vma)
vma->vm_ops = &relay_file_mmap_ops;
vma->vm_flags |= VM_DONTEXPAND;
vma->vm_private_data = buf;
-   buf->chan->cb->buf_mapped(buf, filp);
+   cb_buf_mapped(buf->chan->cb, buf, filp);
 
return 0;
 }
@@ -264,70 +337,6 @@ EXPORT_SYMBOL_GPL(relay_buf_full);
 

[Intel-gfx] [PATCH 2/6] drm/i915: make relay callbacks const

[Jani Nikula]

Now that relay_open() accepts const callbacks, make relay callbacks
const.

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

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

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

[Intel-gfx] [PATCH 3/6] ath10k: make relay callbacks const

[Jani Nikula]

Now that relay_open() accepts const callbacks, make relay callbacks
const.

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

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

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

[Intel-gfx] [PATCH 4/6] ath11k: make relay callbacks const

[Jani Nikula]

Now that relay_open() accepts const callbacks, make relay callbacks
const.

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

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

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

[Intel-gfx] [PATCH 5/6] ath9k: make relay callbacks const

[Jani Nikula]

Now that relay_open() accepts const callbacks, make relay callbacks
const.

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

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

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

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

[Jani Nikula]

Now that relay_open() accepts const callbacks, make relay callbacks
const.

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

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

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

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] intel_error_decode: Handle no decoding context

[Chris Wilson]

Quoting Tvrtko Ursulin (2020-11-18 16:38:09)
> From: Tvrtko Ursulin 
> 
> If decoding context couldn't be created, say the local libdrm does not
> support the GPU which created the error state, it is much more handy to
> at least decode and dump metadata and rings.
> 
> Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: nuke remaining legacy reg helpers (I915_READ/WRITE etc.) (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: nuke remaining legacy reg helpers (I915_READ/WRITE etc.) 
(rev3)
URL   : https://patchwork.freedesktop.org/series/83762/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9351_full -> Patchwork_18932_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip@2x-flip-vs-suspend-interruptible@ac-hdmi-a1-hdmi-a2:
- shard-glk:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18932/shard-glk4/igt@kms_flip@2x-flip-vs-suspend-interrupti...@ac-hdmi-a1-hdmi-a2.html

  
New tests
-

  New tests have been introduced between CI_DRM_9351_full and 
Patchwork_18932_full:

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

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

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gen9_exec_parse@allowed-single:
- shard-skl:  [PASS][2] -> [DMESG-WARN][3] ([i915#1436] / 
[i915#716])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/shard-skl1/igt@gen9_exec_pa...@allowed-single.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18932/shard-skl5/igt@gen9_exec_pa...@allowed-single.html

  * igt@i915_selftest@live@execlists:
- shard-skl:  [PASS][4] -> [INCOMPLETE][5] ([CI#80] / [i915#1037])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/shard-skl3/igt@i915_selftest@l...@execlists.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18932/shard-skl6/igt@i915_selftest@l...@execlists.html

  * igt@kms_color@pipe-b-degamma:
- shard-kbl:  [PASS][6] -> [FAIL][7] ([i915#71])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/shard-kbl7/igt@kms_co...@pipe-b-degamma.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18932/shard-kbl1/igt@kms_co...@pipe-b-degamma.html
- shard-apl:  [PASS][8] -> [FAIL][9] ([i915#1635] / [i915#71])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/shard-apl6/igt@kms_co...@pipe-b-degamma.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18932/shard-apl1/igt@kms_co...@pipe-b-degamma.html
- shard-skl:  [PASS][10] -> [FAIL][11] ([i915#71])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/shard-skl1/igt@kms_co...@pipe-b-degamma.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18932/shard-skl5/igt@kms_co...@pipe-b-degamma.html
- shard-glk:  [PASS][12] -> [FAIL][13] ([i915#71])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/shard-glk9/igt@kms_co...@pipe-b-degamma.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18932/shard-glk5/igt@kms_co...@pipe-b-degamma.html

  * igt@kms_cursor_crc@pipe-b-cursor-128x128-onscreen:
- shard-skl:  [PASS][14] -> [FAIL][15] ([i915#54])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/shard-skl5/igt@kms_cursor_...@pipe-b-cursor-128x128-onscreen.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18932/shard-skl10/igt@kms_cursor_...@pipe-b-cursor-128x128-onscreen.html

  * igt@kms_cursor_edge_walk@pipe-c-128x128-bottom-edge:
- shard-hsw:  [PASS][16] -> [DMESG-WARN][17] ([i915#1982])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/shard-hsw2/igt@kms_cursor_edge_w...@pipe-c-128x128-bottom-edge.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18932/shard-hsw1/igt@kms_cursor_edge_w...@pipe-c-128x128-bottom-edge.html

  * igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible@a-edp1:
- shard-iclb: [PASS][18] -> [DMESG-WARN][19] ([i915#1982])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/shard-iclb1/igt@kms_flip@flip-vs-absolute-wf_vblank-interrupti...@a-edp1.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18932/shard-iclb5/igt@kms_flip@flip-vs-absolute-wf_vblank-interrupti...@a-edp1.html

  * igt@kms_flip@flip-vs-expired-vblank@b-edp1:
- shard-skl:  [PASS][20] -> [FAIL][21] ([i915#79])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/shard-skl6/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18932/shard-skl3/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html

  * igt@kms_flip@flip-vs-fences@a-hdmi-a1:
- shard-glk:  [

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Remember to free the virtual breadcrumbs

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Remember to free the virtual breadcrumbs
URL   : https://patchwork.freedesktop.org/series/84021/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9354 -> Patchwork_18935


Summary
---

  **SUCCESS**

  No regressions found.

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

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@prime_self_import@basic-with_two_bos:
- {fi-dg1-1}: [SKIP][1] ([i915#2575]) -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/fi-dg1-1/igt@prime_self_import@basic-with_two_bos.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18935/fi-dg1-1/igt@prime_self_import@basic-with_two_bos.html

  * igt@runner@aborted:
- {fi-dg1-1}: [FAIL][3] ([i915#2292] / [i915#2439] / 
[k.org#204565]) -> [FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/fi-dg1-1/igt@run...@aborted.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18935/fi-dg1-1/igt@run...@aborted.html

  
New tests
-

  New tests have been introduced between CI_DRM_9354 and Patchwork_18935:

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

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

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-skl-lmem:[PASS][5] -> [DMESG-WARN][6] ([i915#2605])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/fi-skl-lmem/igt@core_hotunp...@unbind-rebind.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18935/fi-skl-lmem/igt@core_hotunp...@unbind-rebind.html

  * igt@gem_exec_create@basic:
- fi-tgl-y:   [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +2 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/fi-tgl-y/igt@gem_exec_cre...@basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18935/fi-tgl-y/igt@gem_exec_cre...@basic.html

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

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

  * igt@kms_chamelium@dp-crc-fast:
- fi-cml-u2:  [PASS][13] -> [DMESG-WARN][14] ([i915#1982])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18935/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0:
- fi-kbl-7500u:   [INCOMPLETE][15] ([i915#2473]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/fi-kbl-7500u/igt@gem_exec_susp...@basic-s0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18935/fi-kbl-7500u/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_module_load@reload:
- fi-byt-j1900:   [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/fi-byt-j1900/igt@i915_module_l...@reload.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18935/fi-byt-j1900/igt@i915_module_l...@reload.html

  * igt@i915_pm_rpm@module-reload:
- fi-bsw-kefka:   [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18935/fi-bsw-kefka/igt@i915_pm_...@module-reload.html

  * igt@kms_busy@basic@flip:
- {fi-tgl-dsi}:   [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18935/fi-tgl-dsi/igt@kms_busy@ba...@flip.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2:  [DMESG-WARN][23] ([i915#1982]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
   [24]: 
https://intel-gfx-ci.01.org/

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/6] relay: allow the use of const callback structs

[Patchwork]

== Series Details ==

Series: series starting with [1/6] relay: allow the use of const callback 
structs
URL   : https://patchwork.freedesktop.org/series/84030/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
76e9bf02701b relay: allow the use of const callback structs
-:235: WARNING:SYMBOLIC_PERMS: Symbolic permissions 'S_IRUSR' are not 
preferred. Consider using octal permissions '0400'.
#235: FILE: kernel/relay.c:439:
+   S_IRUSR, buf, &chan->is_global);

-:247: WARNING:SYMBOLIC_PERMS: Symbolic permissions 'S_IRUSR' are not 
preferred. Consider using octal permissions '0400'.
#247: FILE: kernel/relay.c:473:
+   S_IRUSR, buf, &chan->is_global);

total: 0 errors, 2 warnings, 0 checks, 267 lines checked
25fce26c36a2 drm/i915: make relay callbacks const
e087a43fd799 ath10k: make relay callbacks const
bd0a1edfcd78 ath11k: make relay callbacks const
ae80849da1c9 ath9k: make relay callbacks const
ac95f490fbc0 blktrace: make relay callbacks const


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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/6] relay: allow the use of const callback structs

[Patchwork]

== Series Details ==

Series: series starting with [1/6] relay: allow the use of const callback 
structs
URL   : https://patchwork.freedesktop.org/series/84030/
State : warning

== Summary ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] relay: allow the use of const callback structs

[Patchwork]

== Series Details ==

Series: series starting with [1/6] relay: allow the use of const callback 
structs
URL   : https://patchwork.freedesktop.org/series/84030/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9354 -> Patchwork_18936


Summary
---

  **SUCCESS**

  No regressions found.

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

New tests
-

  New tests have been introduced between CI_DRM_9354 and Patchwork_18936:

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

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

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_render_linear_blits@basic:
- fi-tgl-y:   [PASS][1] -> [DMESG-WARN][2] ([i915#402])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/fi-tgl-y/igt@gem_render_linear_bl...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18936/fi-tgl-y/igt@gem_render_linear_bl...@basic.html

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

  * igt@i915_pm_rpm@module-reload:
- fi-skl-lmem:[PASS][5] -> [DMESG-WARN][6] ([i915#2605])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/fi-skl-lmem/igt@i915_pm_...@module-reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18936/fi-skl-lmem/igt@i915_pm_...@module-reload.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2:  [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18936/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0:
- fi-kbl-7500u:   [INCOMPLETE][9] ([i915#2473]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/fi-kbl-7500u/igt@gem_exec_susp...@basic-s0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18936/fi-kbl-7500u/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_module_load@reload:
- fi-byt-j1900:   [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/fi-byt-j1900/igt@i915_module_l...@reload.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18936/fi-byt-j1900/igt@i915_module_l...@reload.html

  * igt@i915_pm_rpm@module-reload:
- fi-bsw-kefka:   [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18936/fi-bsw-kefka/igt@i915_pm_...@module-reload.html

  * igt@kms_busy@basic@flip:
- {fi-kbl-7560u}: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/fi-kbl-7560u/igt@kms_busy@ba...@flip.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18936/fi-kbl-7560u/igt@kms_busy@ba...@flip.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2:  [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] +1 
similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18936/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-tgl-y:   [DMESG-WARN][19] ([i915#1982]) -> [PASS][20] +2 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18936/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html

  * igt@vgem_basic@create:
- fi-tgl-y:   [DMESG-WARN][21] ([i915#402]) -> [PASS][22] +1 
similar issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/fi-tgl-y/igt@vgem_ba...@create.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18936/fi-tgl-y/igt@vgem_ba...@create.html

  
 Warnings 

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

  * igt@i915_pm_rpm@basic-

Re: [Intel-gfx] [PATCH 5/6] ath9k: make relay callbacks const

[Kalle Valo]

Kalle Valo  writes:

> Jani Nikula  writes:
>
>> Now that relay_open() accepts const callbacks, make relay callbacks
>> const.
>>
>> Cc: Kalle Valo 
>> Cc: QCA ath9k Development 
>> Cc: linux-wirel...@vger.kernel.org
>> Signed-off-by: Jani Nikula 
>
> Can I take this to my ath tree or what's the plan?

Ah, saw patch 1 only now. So I assume this goes via some other tree:

Acked-by: Kalle Valo 

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

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

Re: [Intel-gfx] [PATCH 5/6] ath9k: make relay callbacks const

[Kalle Valo]

Jani Nikula  writes:

> Now that relay_open() accepts const callbacks, make relay callbacks
> const.
>
> Cc: Kalle Valo 
> Cc: QCA ath9k Development 
> Cc: linux-wirel...@vger.kernel.org
> Signed-off-by: Jani Nikula 

Can I take this to my ath tree or what's the plan?

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

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

Re: [Intel-gfx] [PATCH 3/6] ath10k: make relay callbacks const

[Kalle Valo]

Jani Nikula  writes:

> Now that relay_open() accepts const callbacks, make relay callbacks
> const.
>
> Cc: Kalle Valo 
> Cc: ath...@lists.infradead.org
> Signed-off-by: Jani Nikula 

I assume this goes via some other tree:

Acked-by: Kalle Valo 

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

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

Re: [Intel-gfx] [CI 00/15] Rebased remaining big joiner series

[Navare, Manasi]

Series pushed to dinq

Manasi

On Tue, Nov 17, 2020 at 11:47:03AM -0800, Manasi Navare wrote:
> 
> 
> Maarten Lankhorst (4):
>   drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.
>   drm/i915: Try to make bigjoiner work in atomic check
>   drm/i915: Add bigjoiner aware plane clipping checks
>   drm/i915: Add debugfs dumping for bigjoiner, v3.
> 
> Manasi Navare (3):
>   drm/i915/dp: Modify VDSC helpers to configure DSC for Bigjoiner slave
>   drm/i915/dp: Master/Slave enable/disable sequence for bigjoiner
>   drm/i915: HW state readout for Bigjoiner case
> 
> Ville Syrjälä (8):
>   drm/i915: Copy the plane hw state directly for Y planes
>   drm/i915: Add crtcs affected by bigjoiner to the state
>   drm/i915: Add planes affected by bigjoiner to the state
>   drm/i915: Get the uapi state from the correct plane when bigjoiner is
> used
>   drm/i915: Disable legacy cursor fastpath for bigjoiner
>   drm/i915: Fix cursor src/dst rectangle with bigjoiner
>   drm/i915: Add bigjoiner state dump
>   drm/i915: Enable bigjoiner
> 
>  drivers/gpu/drm/i915/display/icl_dsi.c|   2 -
>  .../gpu/drm/i915/display/intel_atomic_plane.c | 131 +++-
>  .../gpu/drm/i915/display/intel_atomic_plane.h |   9 +-
>  drivers/gpu/drm/i915/display/intel_ddi.c  |  69 +-
>  drivers/gpu/drm/i915/display/intel_display.c  | 696 ++
>  drivers/gpu/drm/i915/display/intel_display.h  |   3 +-
>  .../drm/i915/display/intel_display_debugfs.c  |  25 +-
>  .../drm/i915/display/intel_display_types.h|  10 +
>  drivers/gpu/drm/i915/display/intel_dp.c   | 100 ++-
>  drivers/gpu/drm/i915/display/intel_dp.h   |   1 +
>  drivers/gpu/drm/i915/display/intel_dp_mst.c   |   2 +-
>  drivers/gpu/drm/i915/display/intel_dsi.c  |   2 +-
>  drivers/gpu/drm/i915/display/intel_hdmi.c |   2 +-
>  drivers/gpu/drm/i915/display/intel_sprite.c   |  21 +-
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 201 ++---
>  drivers/gpu/drm/i915/display/intel_vdsc.h |   6 +-
>  16 files changed, 953 insertions(+), 327 deletions(-)
> 
> -- 
> 2.19.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dsi: Use unconditional msleep for the panel_on_delay when there is no reset-deassert MIPI-sequence

[Patchwork]

== Series Details ==

Series: drm/i915/dsi: Use unconditional msleep for the panel_on_delay when 
there is no reset-deassert MIPI-sequence
URL   : https://patchwork.freedesktop.org/series/84017/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9351_full -> Patchwork_18933_full


Summary
---

  **SUCCESS**

  No regressions found.

  

New tests
-

  New tests have been introduced between CI_DRM_9351_full and 
Patchwork_18933_full:

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

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

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gen9_exec_parse@allowed-single:
- shard-skl:  [PASS][1] -> [DMESG-WARN][2] ([i915#1436] / 
[i915#716])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/shard-skl1/igt@gen9_exec_pa...@allowed-single.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18933/shard-skl4/igt@gen9_exec_pa...@allowed-single.html

  * igt@i915_selftest@live@execlists:
- shard-iclb: [PASS][3] -> [INCOMPLETE][4] ([i915#1037] / 
[i915#2089] / [i915#2276])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/shard-iclb5/igt@i915_selftest@l...@execlists.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18933/shard-iclb3/igt@i915_selftest@l...@execlists.html

  * igt@i915_suspend@forcewake:
- shard-kbl:  [PASS][5] -> [DMESG-WARN][6] ([i915#180])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/shard-kbl1/igt@i915_susp...@forcewake.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18933/shard-kbl4/igt@i915_susp...@forcewake.html

  * igt@kms_color@pipe-b-degamma:
- shard-kbl:  [PASS][7] -> [FAIL][8] ([i915#71])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/shard-kbl7/igt@kms_co...@pipe-b-degamma.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18933/shard-kbl2/igt@kms_co...@pipe-b-degamma.html
- shard-apl:  [PASS][9] -> [FAIL][10] ([i915#1635] / [i915#71])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/shard-apl6/igt@kms_co...@pipe-b-degamma.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18933/shard-apl7/igt@kms_co...@pipe-b-degamma.html
- shard-skl:  [PASS][11] -> [FAIL][12] ([i915#71])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/shard-skl1/igt@kms_co...@pipe-b-degamma.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18933/shard-skl5/igt@kms_co...@pipe-b-degamma.html
- shard-glk:  [PASS][13] -> [FAIL][14] ([i915#71])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/shard-glk9/igt@kms_co...@pipe-b-degamma.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18933/shard-glk1/igt@kms_co...@pipe-b-degamma.html

  * igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen:
- shard-skl:  [PASS][15] -> [FAIL][16] ([i915#54]) +1 similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/shard-skl8/igt@kms_cursor_...@pipe-a-cursor-256x85-offscreen.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18933/shard-skl6/igt@kms_cursor_...@pipe-a-cursor-256x85-offscreen.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-skl:  [PASS][17] -> [FAIL][18] ([i915#2346])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/shard-skl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18933/shard-skl1/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html

  * igt@kms_cursor_legacy@pipe-b-single-bo:
- shard-hsw:  [PASS][19] -> [DMESG-WARN][20] ([i915#1982])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/shard-hsw6/igt@kms_cursor_leg...@pipe-b-single-bo.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18933/shard-hsw1/igt@kms_cursor_leg...@pipe-b-single-bo.html

  * igt@kms_flip@blocking-absolute-wf_vblank-interruptible@a-dp1:
- shard-apl:  [PASS][21] -> [DMESG-WARN][22] ([i915#1635] / 
[i915#1982]) +1 similar issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/shard-apl1/igt@kms_flip@blocking-absolute-wf_vblank-interrupti...@a-dp1.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18933/shard-apl1/igt@kms_flip@blocking-absolute-wf_vblank-interrupti...@a-dp1.html

  * igt@kms_flip@dpms-vs-vblank-race-interruptible@a-hdmi-a1:
- shard-glk:  [PASS][23] -> [DMESG-WARN][24] ([i915#1982]) +2 
similar issues
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9351/shard-glk1/igt@kms_flip@dpms-vs-vblank-race-interrupti...@a-hdmi-a1.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18933/shard-glk4/igt@kms_flip@dpms-vs-vblank-race-interrupti...@a-h

Re: [Intel-gfx] [CI 00/15] Rebased remaining big joiner series

[Chris Wilson]

Quoting Navare, Manasi (2020-11-18 19:49:25)
> Series pushed to dinq

Oops on boot:

<1>[   44.315382] BUG: unable to handle page fault for address: c90049e02100
<1>[   44.315422] #PF: supervisor read access in kernel mode
<1>[   44.315442] #PF: error_code(0x) - not-present page
<6>[   44.315462] PGD 10067 P4D 10067 PUD 0
<4>[   44.315497] Oops:  [#1] PREEMPT SMP NOPTI
<4>[   44.315522] CPU: 7 PID: 276 Comm: systemd-udevd Tainted: G U  
  5.10.0-rc3-CI-CI_DRM_9355+ #1
<4>[   44.315552] Hardware name: Intel Corporation Tiger Lake Client 
Platform/TigerLake Y LPDDR4x T4 Crb, BIOS TGLSFWI1.R00.2527.A03.2001170231 
01/17/2020
<4>[   44.315981] RIP: 0010:gen12_fwtable_read32+0x6f/0x2f0 [i915]
<4>[   44.316016] Code: c6 48 8b 43 08 8b b0 98 0d 00 00 85 f6 0f 85 53 01 00 
00 89 ee 48 89 df e8 fe a6 ff ff 85 c0 0f 85 bc 00 00 00 89 e8 48 03 03 <44> 8b 
38 48 8b 43 08 8b 90 98 0d 00 00 85 d2 0f 85 a8 01 00 00 4c
16893]  hsw_crtc_enable+0x188/0x780 [i915]
<4>[   44.317423]  intel_enable_crtc+0x56/0x70 [i915]
<4>[   44.317931]  skl_commit_modeset_enables+0x34a/0x530 [i915]
<4>[   44.318444]  intel_atomic_commit_tail+0x3a0/0x1330 [i915]
<4>[   44.318488]  ? queue_work_on+0x5e/0x70
<4>[   44.318965]  intel_atomic_commit+0x371/0x3f0 [i915]
<4>[   44.319458]  intel_initial_commit+0x156/0x1e0 [i915]
<4>[   44.319949]  intel_modeset_init_nogem+0xb59/0x1c00 [i915]
<4>[   44.320336]  i915_driver_probe+0x79c/0xd90 [i915]
<4>[   44.320374]  ? __pm_runtime_resume+0x4f/0x80
<4>[   44.320741]  i915_pci_probe+0x43/0x1d0 [i915]
<4>[   44.320772]  ? _raw_spin_unlock_irqrestore+0x2f/0x50
<4>[   44.320804]  pci_device_probe+0x9e/0x110
<4>[   44.320830]  really_probe+0x1c4/0x430
<4>[   44.320852]  driver_probe_device+0xd9/0x140
<4>[   44.320875]  device_driver_attach+0x4a/0x50
<4>[   44.320897]  __driver_attach+0x83/0x140
<4>[   44.320917]  ? device_driver_attach+0x50/0x50
<4>[   44.320938]  ? device_driver_attach+0x50/0x50
89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 
0d 1f f6 2c 00 f7 d8 64 89 01 48
<4>[   44.321749] RSP: 002b:7ffda8ea9358 EFLAGS: 0246 ORIG_RAX: 
0139
<4>[   44.321782] RAX: ffda RBX: 56004d10ffc0 RCX: 
7fad885f5839
<4>[   44.321808] RDX:  RSI: 56004d0f5490 RDI: 
000f
<4>[   44.321834] RBP: 56004d0f5490 R08:  R09: 
7ffda8ea9470
<4>[   44.321859] R10: 000f R11: 0246 R12: 

<4>[   44.321884] R13: 56004d0f20c0 R14: 0002 R15: 

<4>[   44.321921] Modules linked in: i915(+) mei_hdcp x86_pkg_temp_thermal 
coretemp crct10dif_pclmul crc32_pclmul snd_hda_intel snd_intel_dspcfg 
ghash_clmulni_intel snd_hda_codec cdc_ether snd_hwdep usbnet snd_hda_core mii 
e1000e ptp snd_pcm pps_core mei_me mei prime_numbers intel_lpss_pci(+)
<4>[   44.322105] CR2: c90049e02100
<4>[   44.322130] ---[ end trace 87c6ef683da5ac08 ]---
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Remember to free the virtual breadcrumbs

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Remember to free the virtual breadcrumbs
URL   : https://patchwork.freedesktop.org/series/84021/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9354_full -> Patchwork_18935_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_whisper@basic-queues-priority:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/shard-iclb4/igt@gem_exec_whis...@basic-queues-priority.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18935/shard-iclb4/igt@gem_exec_whis...@basic-queues-priority.html

  
New tests
-

  New tests have been introduced between CI_DRM_9354_full and 
Patchwork_18935_full:

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

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

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- shard-skl:  [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +7 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/shard-skl8/igt@core_hotunp...@unbind-rebind.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18935/shard-skl9/igt@core_hotunp...@unbind-rebind.html

  * igt@gen9_exec_parse@allowed-single:
- shard-skl:  [PASS][5] -> [DMESG-WARN][6] ([i915#1436] / 
[i915#716])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/shard-skl4/igt@gen9_exec_pa...@allowed-single.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18935/shard-skl1/igt@gen9_exec_pa...@allowed-single.html

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-skl:  [PASS][7] -> [DMESG-WARN][8] ([i915#1982] / 
[i915#2295])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/shard-skl10/igt@kms_cursor_...@pipe-a-cursor-suspend.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18935/shard-skl8/igt@kms_cursor_...@pipe-a-cursor-suspend.html

  * igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-snb:  [PASS][9] -> [DMESG-WARN][10] ([i915#42])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/shard-snb6/igt@kms_cursor_...@pipe-b-cursor-suspend.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18935/shard-snb4/igt@kms_cursor_...@pipe-b-cursor-suspend.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-skl:  [PASS][11] -> [FAIL][12] ([i915#54]) +3 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/shard-skl4/igt@kms_cursor_...@pipe-c-cursor-suspend.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18935/shard-skl9/igt@kms_cursor_...@pipe-c-cursor-suspend.html

  * igt@kms_flip@blocking-absolute-wf_vblank@a-dp1:
- shard-apl:  [PASS][13] -> [DMESG-WARN][14] ([i915#1635] / 
[i915#1982]) +7 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/shard-apl3/igt@kms_flip@blocking-absolute-wf_vbl...@a-dp1.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18935/shard-apl7/igt@kms_flip@blocking-absolute-wf_vbl...@a-dp1.html

  * igt@kms_flip@flip-vs-expired-vblank@a-edp1:
- shard-skl:  [PASS][15] -> [FAIL][16] ([i915#2122]) +2 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/shard-skl1/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18935/shard-skl3/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-cpu:
- shard-glk:  [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +2 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/shard-glk1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-mmap-cpu.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18935/shard-glk2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-mmap-cpu.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-indfb-pgflip-blt:
- shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +2 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/shard-tglb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-indfb-pgflip-blt.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18935

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/6] relay: allow the use of const callback structs

[Patchwork]

== Series Details ==

Series: series starting with [1/6] relay: allow the use of const callback 
structs
URL   : https://patchwork.freedesktop.org/series/84030/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9354_full -> Patchwork_18936_full


Summary
---

  **SUCCESS**

  No regressions found.

  

New tests
-

  New tests have been introduced between CI_DRM_9354_full and 
Patchwork_18936_full:

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

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

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@legacy-engines-hostile@vebox:
- shard-iclb: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) +1 similar 
issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/shard-iclb3/igt@gem_ctx_persistence@legacy-engines-host...@vebox.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18936/shard-iclb2/igt@gem_ctx_persistence@legacy-engines-host...@vebox.html

  * igt@gem_exec_endless@dispatch@rcs0:
- shard-iclb: [PASS][3] -> [INCOMPLETE][4] ([i915#2502])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/shard-iclb5/igt@gem_exec_endless@dispa...@rcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18936/shard-iclb5/igt@gem_exec_endless@dispa...@rcs0.html

  * igt@gem_exec_reloc@basic-range:
- shard-glk:  [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +2 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/shard-glk9/igt@gem_exec_re...@basic-range.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18936/shard-glk2/igt@gem_exec_re...@basic-range.html

  * igt@kms_cursor_crc@pipe-b-cursor-128x128-random:
- shard-skl:  [PASS][7] -> [FAIL][8] ([i915#54]) +4 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/shard-skl8/igt@kms_cursor_...@pipe-b-cursor-128x128-random.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18936/shard-skl3/igt@kms_cursor_...@pipe-b-cursor-128x128-random.html

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

  * igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-ytiled:
- shard-skl:  [PASS][11] -> [FAIL][12] ([i915#52] / [i915#54]) +1 
similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/shard-skl10/igt@kms_draw_...@draw-method-xrgb2101010-pwrite-ytiled.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18936/shard-skl1/igt@kms_draw_...@draw-method-xrgb2101010-pwrite-ytiled.html

  * igt@kms_flip@blocking-absolute-wf_vblank@a-dp1:
- shard-apl:  [PASS][13] -> [DMESG-WARN][14] ([i915#1635] / 
[i915#1982]) +3 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/shard-apl3/igt@kms_flip@blocking-absolute-wf_vbl...@a-dp1.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18936/shard-apl1/igt@kms_flip@blocking-absolute-wf_vbl...@a-dp1.html

  * igt@kms_frontbuffer_tracking@psr-modesetfrombusy:
- shard-tglb: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/shard-tglb6/igt@kms_frontbuffer_track...@psr-modesetfrombusy.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18936/shard-tglb3/igt@kms_frontbuffer_track...@psr-modesetfrombusy.html

  * igt@kms_hdr@bpc-switch:
- shard-skl:  [PASS][17] -> [FAIL][18] ([i915#1188])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/shard-skl8/igt@kms_...@bpc-switch.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18936/shard-skl9/igt@kms_...@bpc-switch.html

  * igt@kms_psr2_su@frontbuffer:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109642] / [fdo#111068])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/shard-iclb2/igt@kms_psr2...@frontbuffer.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18936/shard-iclb8/igt@kms_psr2...@frontbuffer.html

  * igt@kms_psr@psr2_sprite_plane_move:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +2 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9354/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18936/shard-iclb3/igt@kms_psr@psr2_sprite_plane_move.html

  * igt@kms_universal_plane@universal-plane-gen9-features-pipe-a:
- shard-kbl:  [PASS][23] -> [DMESG-WARN][24] ([i915#1982]) +3 
similar issues
   [23]: 
ht

Re: [Intel-gfx] [CI 00/15] Rebased remaining big joiner series

[Navare, Manasi]

On Wed, Nov 18, 2020 at 11:49:25AM -0800, Navare, Manasi wrote:
> Series pushed to dinq
> 
> Manasi

By Chris Wilson:

Oops on boot:

<1>[   44.315382] BUG: unable to handle page fault for address: c90049e02100
<1>[   44.315422] #PF: supervisor read access in kernel mode
<1>[   44.315442] #PF: error_code(0x) - not-present page
<6>[   44.315462] PGD 10067 P4D 10067 PUD 0
<4>[   44.315497] Oops:  [#1] PREEMPT SMP NOPTI
<4>[   44.315522] CPU: 7 PID: 276 Comm: systemd-udevd Tainted: G U  
  5.10.0-rc3-CI-CI_DRM_9355+ #1
<4>[   44.315552] Hardware name: Intel Corporation Tiger Lake Client 
Platform/TigerLake Y LPDDR4x T4 Crb, BIOS TGLSFWI1.R00.2527.A03.2001170231 
01/17/2020
<4>[   44.315981] RIP: 0010:gen12_fwtable_read32+0x6f/0x2f0 [i915]
<4>[   44.316016] Code: c6 48 8b 43 08 8b b0 98 0d 00 00 85 f6 0f 85 53 01 00 
00 89 ee 48 89 df e8 fe a6 ff ff 85 c0 0f 85 bc 00 00 00 89 e8 48 03 03 <44> 8b 
38 48 8b 43 08 8b 90 98 0d 00 00 85 d2 0f 85 a8 01 00 00 4c
16893]  hsw_crtc_enable+0x188/0x780 [i915]
<4>[   44.317423]  intel_enable_crtc+0x56/0x70 [i915]
<4>[   44.317931]  skl_commit_modeset_enables+0x34a/0x530 [i915]
<4>[   44.318444]  intel_atomic_commit_tail+0x3a0/0x1330 [i915]
<4>[   44.318488]  ? queue_work_on+0x5e/0x70
<4>[   44.318965]  intel_atomic_commit+0x371/0x3f0 [i915]
<4>[   44.319458]  intel_initial_commit+0x156/0x1e0 [i915]
<4>[   44.319949]  intel_modeset_init_nogem+0xb59/0x1c00 [i915]
<4>[   44.320336]  i915_driver_probe+0x79c/0xd90 [i915]
<4>[   44.320374]  ? __pm_runtime_resume+0x4f/0x80
<4>[   44.320741]  i915_pci_probe+0x43/0x1d0 [i915]
<4>[   44.320772]  ? _raw_spin_unlock_irqrestore+0x2f/0x50
<4>[   44.320804]  pci_device_probe+0x9e/0x110
<4>[   44.320830]  really_probe+0x1c4/0x430
<4>[   44.320852]  driver_probe_device+0xd9/0x140
<4>[   44.320875]  device_driver_attach+0x4a/0x50
<4>[   44.320897]  __driver_attach+0x83/0x140
<4>[   44.320917]  ? device_driver_attach+0x50/0x50
<4>[   44.320938]  ? device_driver_attach+0x50/0x50
89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 
0d 1f f6 2c 00 f7 d8 64 89 01 48
<4>[   44.321749] RSP: 002b:7ffda8ea9358 EFLAGS: 0246 ORIG_RAX: 
0139
<4>[   44.321782] RAX: ffda RBX: 56004d10ffc0 RCX: 
7fad885f5839
<4>[   44.321808] RDX:  RSI: 56004d0f5490 RDI: 
000f
<4>[   44.321834] RBP: 56004d0f5490 R08:  R09: 
7ffda8ea9470
<4>[   44.321859] R10: 000f R11: 0246 R12: 

<4>[   44.321884] R13: 56004d0f20c0 R14: 0002 R15: 

<4>[   44.321921] Modules linked in: i915(+) mei_hdcp x86_pkg_temp_thermal 
coretemp crct10dif_pclmul crc32_pclmul snd_hda_intel snd_intel_dspcfg 
ghash_clmulni_intel snd_hda_codec cdc_ether snd_hwdep usbnet snd_hda_core mii 
e1000e ptp snd_pcm pps_core mei_me mei prime_numbers intel_lpss_pci(+)
<4>[   44.322105] CR2: c90049e02100
<4>[   44.322130] ---[ end trace 87c6ef683da5ac08 ]---


But Chris, we havent seen this on CI nor in our testing.

Manasi

> 
> On Tue, Nov 17, 2020 at 11:47:03AM -0800, Manasi Navare wrote:
> > 
> > 
> > Maarten Lankhorst (4):
> >   drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.
> >   drm/i915: Try to make bigjoiner work in atomic check
> >   drm/i915: Add bigjoiner aware plane clipping checks
> >   drm/i915: Add debugfs dumping for bigjoiner, v3.
> > 
> > Manasi Navare (3):
> >   drm/i915/dp: Modify VDSC helpers to configure DSC for Bigjoiner slave
> >   drm/i915/dp: Master/Slave enable/disable sequence for bigjoiner
> >   drm/i915: HW state readout for Bigjoiner case
> > 
> > Ville Syrjälä (8):
> >   drm/i915: Copy the plane hw state directly for Y planes
> >   drm/i915: Add crtcs affected by bigjoiner to the state
> >   drm/i915: Add planes affected by bigjoiner to the state
> >   drm/i915: Get the uapi state from the correct plane when bigjoiner is
> > used
> >   drm/i915: Disable legacy cursor fastpath for bigjoiner
> >   drm/i915: Fix cursor src/dst rectangle with bigjoiner
> >   drm/i915: Add bigjoiner state dump
> >   drm/i915: Enable bigjoiner
> > 
> >  drivers/gpu/drm/i915/display/icl_dsi.c|   2 -
> >  .../gpu/drm/i915/display/intel_atomic_plane.c | 131 +++-
> >  .../gpu/drm/i915/display/intel_atomic_plane.h |   9 +-
> >  drivers/gpu/drm/i915/display/intel_ddi.c  |  69 +-
> >  drivers/gpu/drm/i915/display/intel_display.c  | 696 ++
> >  drivers/gpu/drm/i915/display/intel_display.h  |   3 +-
> >  .../drm/i915/display/intel_display_debugfs.c  |  25 +-
> >  .../drm/i915/display/intel_display_types.h|  10 +
> >  drivers/gpu/drm/i915/display/intel_dp.c   | 100 ++-
> >  drivers/gpu/drm/i915/display/intel_dp.h   |   1 +
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c   |   2 +-
> >  drivers/gpu/drm/i915/display/intel_dsi.c  |   2 +-
> >  drivers/gpu/drm/i915/display/intel_hdmi.c |   2 +-
> >  drivers/gpu/drm/i915/di

Re: [Intel-gfx] [PATCH v2 01/13] drm/edid: Add additional HFVSDB fields for HDMI2.1

[Shankar, Uma]

> -Original Message-
> From: Nautiyal, Ankit K 
> Sent: Sunday, November 1, 2020 3:37 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2 
> Subject: [PATCH v2 01/13] drm/edid: Add additional HFVSDB fields for HDMI2.1
> 
> From: Swati Sharma 
> 
> The HDMI2.1 extends HFVSDB (HDMI Forum Vendor Specific Data block) to have
> fields related to newly defined methods of FRL (Fixed Rate Link) levels, 
> number
> of lanes supported, DSC Color bit depth, VRR min/max, FVA (Fast Vactive), ALLM
> etc.
> 
> This patch adds the new HFVSDB fields that are required for HDMI2.1.
> 
> v2: Minor fixes + consistent naming for DPCD register masks (Uma Shankar)

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Sharma, Swati2 
> Signed-off-by: Ankit Nautiyal 
> ---
>  include/drm/drm_edid.h | 30 ++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h index
> b27a0e2169c8..a6ca992e105d 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -229,6 +229,36 @@ struct detailed_timing {
>   DRM_EDID_YCBCR420_DC_36 | \
>   DRM_EDID_YCBCR420_DC_30)
> 
> +/* HDMI 2.1 additional fields */
> +#define DRM_EDID_MAX_FRL_RATE_MASK   0xf0
> +#define DRM_EDID_FAPA_START_LOCATION (1 << 0)
> +#define DRM_EDID_ALLM(1 << 1)
> +#define DRM_EDID_FVA (1 << 2)
> +
> +/* Deep Color specific */
> +#define DRM_EDID_DC_30BIT_420(1 << 0)
> +#define DRM_EDID_DC_36BIT_420(1 << 1)
> +#define DRM_EDID_DC_48BIT_420(1 << 2)
> +
> +/* VRR specific */
> +#define DRM_EDID_CNMVRR  (1 << 3)
> +#define DRM_EDID_CINEMA_VRR  (1 << 4)
> +#define DRM_EDID_MDELTA  (1 << 5)
> +#define DRM_EDID_VRR_MAX_UPPER_MASK  0xc0
> +#define DRM_EDID_VRR_MAX_LOWER_MASK  0xff
> +#define DRM_EDID_VRR_MIN_MASK0x3f
> +
> +/* DSC specific */
> +#define DRM_EDID_DSC_10BPC   (1 << 0)
> +#define DRM_EDID_DSC_12BPC   (1 << 1)
> +#define DRM_EDID_DSC_16BPC   (1 << 2)
> +#define DRM_EDID_DSC_ALL_BPP (1 << 3)
> +#define DRM_EDID_DSC_NATIVE_420  (1 << 6)
> +#define DRM_EDID_DSC_1P2 (1 << 7)
> +#define DRM_EDID_DSC_MAX_FRL_RATE_MASK   0xf0
> +#define DRM_EDID_DSC_MAX_SLICES  0xf
> +#define DRM_EDID_DSC_TOTAL_CHUNK_KBYTES  0x3f
> +
>  /* ELD Header Block */
>  #define DRM_ELD_HEADER_BLOCK_SIZE4
> 
> --
> 2.17.1

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

Re: [Intel-gfx] [PATCH v2 02/13] drm/edid: Parse MAX_FRL field from HFVSDB block

[Shankar, Uma]

> -Original Message-
> From: Nautiyal, Ankit K 
> Sent: Sunday, November 1, 2020 3:37 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2 
> Subject: [PATCH v2 02/13] drm/edid: Parse MAX_FRL field from HFVSDB block
> 
> From: Swati Sharma 
> 
> This patch parses MAX_FRL field to get the MAX rate in Gbps that the HDMI 2.1
> panel can support in FRL mode. Source need this field to determine the optimal
> rate between the source and sink during FRL training.
> 
> v2: Fixed minor bugs, and removed extra wrapper function (Uma Shankar)

Reviewed-by: Uma Shankar 

> Signed-off-by: Sharma, Swati2 
> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/drm_edid.c  | 44 +
>  include/drm/drm_connector.h |  6 +
>  2 files changed, 50 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
> 631125b46e04..26797868ea5b 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4849,6 +4849,41 @@ static void drm_parse_vcdb(struct drm_connector
> *connector, const u8 *db)
>   info->rgb_quant_range_selectable = true;  }
> 
> +static
> +void drm_get_max_frl_rate(int max_frl_rate, u8 *max_lanes, u8
> +*max_rate_per_lane) {
> + switch (max_frl_rate) {
> + case 1:
> + *max_lanes = 3;
> + *max_rate_per_lane = 3;
> + break;
> + case 2:
> + *max_lanes = 3;
> + *max_rate_per_lane = 6;
> + break;
> + case 3:
> + *max_lanes = 4;
> + *max_rate_per_lane = 6;
> + break;
> + case 4:
> + *max_lanes = 4;
> + *max_rate_per_lane = 8;
> + break;
> + case 5:
> + *max_lanes = 4;
> + *max_rate_per_lane = 10;
> + break;
> + case 6:
> + *max_lanes = 4;
> + *max_rate_per_lane = 12;
> + break;
> + case 0:
> + default:
> + *max_lanes = 0;
> + *max_rate_per_lane = 0;
> + }
> +}
> +
>  static void drm_parse_ycbcr420_deep_color_info(struct drm_connector
> *connector,
>  const u8 *db)
>  {
> @@ -4902,6 +4937,15 @@ static void drm_parse_hdmi_forum_vsdb(struct
> drm_connector *connector,
>   }
>   }
> 
> + if (hf_vsdb[7]) {
> + u8 max_frl_rate;
> +
> + DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
> + max_frl_rate = (hf_vsdb[7] & DRM_EDID_MAX_FRL_RATE_MASK)
> >> 4;
> + drm_get_max_frl_rate(max_frl_rate, &hdmi->max_lanes,
> + &hdmi->max_frl_rate_per_lane);
> + }
> +
>   drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);  }
> 
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h index
> 928136556174..f351bf10c076 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -207,6 +207,12 @@ struct drm_hdmi_info {
> 
>   /** @y420_dc_modes: bitmap of deep color support index */
>   u8 y420_dc_modes;
> +
> + /** @max_frl_rate_per_lane: support fixed rate link */
> + u8 max_frl_rate_per_lane;
> +
> + /** @max_lanes: supported by sink */
> + u8 max_lanes;
>  };
> 
>  /**
> --
> 2.17.1

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

Re: [Intel-gfx] [PATCH v2 03/13] drm/edid: Parse DSC1.2 cap fields from HFVSDB block

[Shankar, Uma]

> -Original Message-
> From: Nautiyal, Ankit K 
> Sent: Sunday, November 1, 2020 3:37 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2 
> Subject: [PATCH v2 03/13] drm/edid: Parse DSC1.2 cap fields from HFVSDB block
> 
> This patch parses HFVSDB fields for DSC1.2 capabilities of an
> HDMI2.1 sink. These fields are required by a source to understand the DSC
> capability of the sink, to set appropriate PPS parameters, before transmitting
> compressed data stream.
> 
> v2: Addressed following issues as suggested by Uma Shankar:
> -Added a new struct for hdmi dsc cap
> -Fixed bugs in macros usage.

Reviewed-by: Uma Shankar 

> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/drm_edid.c  | 59 +
>  include/drm/drm_connector.h | 43 +++
>  2 files changed, 102 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
> 26797868ea5b..feaf2d7659a4 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4939,11 +4939,70 @@ static void drm_parse_hdmi_forum_vsdb(struct
> drm_connector *connector,
> 
>   if (hf_vsdb[7]) {
>   u8 max_frl_rate;
> + u8 dsc_max_frl_rate;
> + u8 dsc_max_slices;
> + struct drm_hdmi_dsc_cap *hdmi_dsc = &hdmi->dsc_cap;
> 
>   DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
>   max_frl_rate = (hf_vsdb[7] & DRM_EDID_MAX_FRL_RATE_MASK)
> >> 4;
>   drm_get_max_frl_rate(max_frl_rate, &hdmi->max_lanes,
>   &hdmi->max_frl_rate_per_lane);
> + hdmi_dsc->v_1p2 = hf_vsdb[11] & DRM_EDID_DSC_1P2;
> +
> + if (hdmi_dsc->v_1p2) {
> + hdmi_dsc->native_420 = hf_vsdb[11] &
> DRM_EDID_DSC_NATIVE_420;
> + hdmi_dsc->all_bpp = hf_vsdb[11] &
> DRM_EDID_DSC_ALL_BPP;
> +
> + if (hf_vsdb[11] & DRM_EDID_DSC_16BPC)
> + hdmi_dsc->bpc_supported = 16;
> + else if (hf_vsdb[11] & DRM_EDID_DSC_12BPC)
> + hdmi_dsc->bpc_supported = 12;
> + else if (hf_vsdb[11] & DRM_EDID_DSC_10BPC)
> + hdmi_dsc->bpc_supported = 10;
> + else
> + hdmi_dsc->bpc_supported = 0;
> +
> + dsc_max_frl_rate = (hf_vsdb[12] &
> DRM_EDID_DSC_MAX_FRL_RATE_MASK) >> 4;
> + drm_get_max_frl_rate(dsc_max_frl_rate, &hdmi_dsc-
> >max_lanes,
> + &hdmi_dsc->max_frl_rate_per_lane);
> + hdmi_dsc->total_chunk_kbytes = hf_vsdb[13] &
> +DRM_EDID_DSC_TOTAL_CHUNK_KBYTES;
> +
> + dsc_max_slices = hf_vsdb[12] &
> DRM_EDID_DSC_MAX_SLICES;
> + switch (dsc_max_slices) {
> + case 1:
> + hdmi_dsc->max_slices = 1;
> + hdmi_dsc->clk_per_slice = 340;
> + break;
> + case 2:
> + hdmi_dsc->max_slices = 2;
> + hdmi_dsc->clk_per_slice = 340;
> + break;
> + case 3:
> + hdmi_dsc->max_slices = 4;
> + hdmi_dsc->clk_per_slice = 340;
> + break;
> + case 4:
> + hdmi_dsc->max_slices = 8;
> + hdmi_dsc->clk_per_slice = 340;
> + break;
> + case 5:
> + hdmi_dsc->max_slices = 8;
> + hdmi_dsc->clk_per_slice = 400;
> + break;
> + case 6:
> + hdmi_dsc->max_slices = 12;
> + hdmi_dsc->clk_per_slice = 400;
> + break;
> + case 7:
> + hdmi_dsc->max_slices = 16;
> + hdmi_dsc->clk_per_slice = 400;
> + break;
> + case 0:
> + default:
> + hdmi_dsc->max_slices = 0;
> + hdmi_dsc->clk_per_slice = 0;
> + }
> + }
>   }
> 
>   drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb); diff --git
> a/include/drm/drm_connector.h b/include/drm/drm_connector.h index
> f351bf10c076..06d24e36268e 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -175,6 +175,46 @@ struct drm_scdc {
>   struct drm_scrambling scrambling;
>  };
> 
> +/**
> + * struct drm_hdmi_dsc_cap - DSC capabilities of HDM

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

[Rodrigo Vivi]

On Tue, Nov 17, 2020 at 10:39:18AM +0800, Zhenyu Wang wrote:
> 
> Hi,
> 
> Here's more gvt fixes for 5.10. It temporarily disables VFIO edid
> feature on BXT/APL until its virtual display is really fixed to make
> it work properly. And fixes for DPCD 1.2 and error return in taking
> module reference.
> 
> Thanks
> --
> The following changes since commit 92010a97098c4c9fd777408cc98064d26b32695b:
> 
>   drm/i915/gvt: Fix mmio handler break on BXT/APL. (2020-10-30 11:50:06 +0800)
> 
> are available in the Git repository at:
> 
>   https://github.com/intel/gvt-linux tags/gvt-fixes-2020-11-17
> 
> for you to fetch changes up to 4ec2b69da5e1544dbadb30cddb49c8df60209b0c:
> 
>   drm/i915/gvt: return error when failing to take the module reference 
> (2020-11-13 12:16:52 +0800)
> 
> 
> gvt-fixes-2020-11-17
> 
> - Temporarily disable VFIO edid on BXT/APL (Colin)
> - Fix emulated DPCD for version 1.2 (Tina)
> - Fix error return when failing to take module reference (Xiongfeng)

pulled, thanks!

> 
> 
> Colin Xu (1):
>   drm/i915/gvt: Temporarily disable vfio_edid for BXT/APL
> 
> Tina Zhang (1):
>   drm/i915/gvt: Set ENHANCED_FRAME_CAP bit
> 
> Xiongfeng Wang (1):
>   drm/i915/gvt: return error when failing to take the module reference
> 
>  drivers/gpu/drm/i915/gvt/display.c | 2 +-
>  drivers/gpu/drm/i915/gvt/kvmgt.c   | 4 +++-
>  drivers/gpu/drm/i915/gvt/vgpu.c| 3 ++-
>  3 files changed, 6 insertions(+), 3 deletions(-)
> 
> -- 
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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

Re: [Intel-gfx] [drm/i915/gem] 59dd13ad31: phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second -54.0% regression

[Oliver Sang]

On Fri, Nov 13, 2020 at 04:27:13PM +0200, Joonas Lahtinen wrote:
> Hi,
> 
> Could you add intel-gfx@lists.freedesktop.org into reports going
> forward.
> 
> Quoting kernel test robot (2020-11-11 17:58:11)
> > 
> > Greeting,
> > 
> > FYI, we noticed a -54.0% regression of 
> > phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second
> >  due to commit:
> 
> How many runs are there on the bad version to ensure the bisect is
> repeatable?

test 4 times.
zxing@inn:/result/phoronix-test-suite/performance-true-Radial_Gradient_Paint-1024x1024-jxrendermark-1.2.4-ucode=0xd6-monitor=da39a3ee/lkp-cfl-d1/debian-x86_64-phoronix/x86_64-rhel-8.3/gcc-9/59dd13ad310793757e34afa489dd6fc8544fc3da$
 grep -r "operations_per_second" */stats.json
0/stats.json: 
"phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second":
 4133.487932,
1/stats.json: 
"phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second":
 4120.421503,
2/stats.json: 
"phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second":
 4188.414835,
3/stats.json: 
"phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second":
 4068.549514,

> 
> According to Chris test has various factors affecting why the result
> could fluctuate and has been known. Reverting the patch did not have
> an effect on the benchmark and was not expected to do so, either.
> 
> Is there some mechanism to queue a re-run?
> 
> Would it make sense to do further runs before sending out the e-mail
> to avoid false positives.
> 
> It could of course be also solved by sticking to tests that have less
> fluctuation in them.
> 
> Regards, Joonas
> 
> > 
> > 
> > commit: 59dd13ad310793757e34afa489dd6fc8544fc3da ("drm/i915/gem: Flush 
> > coherency domains on first set-domain-ioctl")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> > 
> > 
> > in testcase: phoronix-test-suite
> > on test machine: 12 threads Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz with 8G 
> > memory
> > with following parameters:
> > 
> > need_x: true
> > test: jxrendermark-1.2.4
> > option_a: Radial Gradient Paint
> > option_b: 1024x1024
> > cpufreq_governor: performance
> > ucode: 0xd6
> > 
> > test-description: The Phoronix Test Suite is the most comprehensive testing 
> > and benchmarking platform available that provides an extensible framework 
> > for which new tests can be easily added.
> > test-url: http://www.phoronix-test-suite.com/
> > 
> > 
> > 
> > If you fix the issue, kindly add following tag
> > Reported-by: kernel test robot 
> > 
> > 
> > Details are as below:
> > -->
> > 
> > 
> > To reproduce:
> > 
> > git clone https://github.com/intel/lkp-tests.git
> > cd lkp-tests
> > bin/lkp install job.yaml  # job file is attached in this email
> > bin/lkp run job.yaml
> > 
> > =
> > compiler/cpufreq_governor/kconfig/need_x/option_a/option_b/rootfs/tbox_group/test/testcase/ucode:
> >   gcc-9/performance/x86_64-rhel-8.3/true/Radial Gradient 
> > Paint/1024x1024/debian-x86_64-phoronix/lkp-cfl-d1/jxrendermark-1.2.4/phoronix-test-suite/0xd6
> > 
> > commit: 
> >   0dccdba51e ("Merge tag 'gvt-fixes-2020-10-30' of 
> > https://github.com/intel/gvt-linux into drm-intel-fixes")
> >   59dd13ad31 ("drm/i915/gem: Flush coherency domains on first 
> > set-domain-ioctl")
> > 
> > 0dccdba51e852271 59dd13ad310793757e34afa489d 
> >  --- 
> >  %stddev %change %stddev
> >  \  |\  
> >   8980 ±  2% -54.0%   4127
> > phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second
> >   9.00   +13.9%  10.25 ±  4%  
> > phoronix-test-suite.time.percent_of_cpu_this_job_got
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >   1 
> > +---+   
> > |   
> > |   
> >9000 |-+.+. .+.+.+.+.+.   .+. .+.   .+. .+.+. .+. .+.   .+. .+.+.   
> > .|   
> > |.+   +   +.+   +   +.+   + +.+.+   +   +.+   + +.+ 
> > |   
> > |   
> > |   
> >8000 |-+ 
> > |   
> > |   
> > |   
> >7000 |

[Intel-gfx] [PATCH] drm/i915: Do not call hsw_set_frame_start_delay for dsi

[Manasi Navare]

This should fix the boot oops for dsi

Fixes: 4e3cdb4535e7 ("drm/i915/dp: Master/Slave enable/disable sequence for 
bigjoiner")
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 5c07c74d4397..739be96e998d 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7211,7 +7211,7 @@ static void hsw_crtc_enable(struct intel_atomic_state 
*state,
if (INTEL_GEN(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
bdw_set_pipemisc(new_crtc_state);
 
-   if (!new_crtc_state->bigjoiner_slave || 
!transcoder_is_dsi(cpu_transcoder)) {
+   if (!new_crtc_state->bigjoiner_slave && 
!transcoder_is_dsi(cpu_transcoder)) {
if (!transcoder_is_dsi(cpu_transcoder))
intel_set_transcoder_timings(new_crtc_state);
 
@@ -7224,7 +7224,7 @@ static void hsw_crtc_enable(struct intel_atomic_state 
*state,
intel_cpu_transcoder_set_m_n(new_crtc_state,
 &new_crtc_state->fdi_m_n, 
NULL);
 
-   hsw_set_frame_start_delay(new_crtc_state);
+   hsw_set_frame_start_delay(new_crtc_state);
}
 
if (!transcoder_is_dsi(cpu_transcoder))
-- 
2.19.1

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

[Intel-gfx] [PATCH v4] drm/i915/lspcon: enter standby mode to enhance power saving

[Lee Shawn C]

After system boot up, LSPCON will be configured as PCON mode.
But it never go into power saving state. Source driver can
do the following. Then LSPCON can enter standby mode
automatically to save more power.

1. At PCON mode, source driver write 0x2 to DPCD 600h.
2. At LS mode, try to disable DP_DUAL_MODE_TMDS_OEN.

v2: fix typo
v3: Found particular monitor trigger HPD to LSPCON
after main link stopped. If driver did not enable
display output. Source should request LSPCON to
enter standby mode again.
v4: Before enter D3, make sure display output is not
active. And source/sink are not doing link training.

Cc: Ville Syrjälä 
Cc: Jani Nikula 
Cc: Uma Shankar 
Cc: Cooper Chiou 
Cc: Khaled Almahallawy 
Signed-off-by: Lee Shawn C 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 13 ++-
 drivers/gpu/drm/i915/display/intel_lspcon.c | 38 +
 drivers/gpu/drm/i915/display/intel_lspcon.h |  1 +
 3 files changed, 51 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index ec8359f03aaf..d2567dc3bc5e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6184,6 +6184,7 @@ static bool
 intel_dp_short_pulse(struct intel_dp *intel_dp)
 {
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+   struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
u8 old_sink_count = intel_dp->sink_count;
bool ret;
 
@@ -6211,6 +6212,11 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
/* Handle CEC interrupts, if any */
drm_dp_cec_irq(&intel_dp->aux);
 
+   /* If LSPCON connected, try to set lspcon power state to D3 */
+   if (lspcon && lspcon->active)
+   lspcon_standby(dp_to_dig_port(intel_dp),
+  
intel_digital_port_connected(&dp_to_dig_port(intel_dp)->base));
+
/* defer to the hotplug work for link retraining if needed */
if (intel_dp_needs_link_retrain(intel_dp))
return false;
@@ -6536,6 +6542,7 @@ intel_dp_detect(struct drm_connector *connector,
struct drm_i915_private *dev_priv = to_i915(connector->dev);
struct intel_dp *intel_dp = 
intel_attached_dp(to_intel_connector(connector));
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
struct intel_encoder *encoder = &dig_port->base;
enum drm_connector_status status;
 
@@ -6632,9 +6639,13 @@ intel_dp_detect(struct drm_connector *connector,
intel_dp_check_service_irq(intel_dp);
 
 out:
-   if (status != connector_status_connected && !intel_dp->is_mst)
+   if (status != connector_status_connected && !intel_dp->is_mst) {
intel_dp_unset_edid(intel_dp);
 
+   if (lspcon && lspcon->active)
+   lspcon_standby(dp_to_dig_port(intel_dp), false);
+   }
+
/*
 * Make sure the refs for power wells enabled during detect are
 * dropped to avoid a new detect cycle triggered by HPD polling.
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index e37d45e531df..99eb67272552 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -550,6 +550,44 @@ static bool lspcon_init(struct intel_digital_port 
*dig_port)
return true;
 }
 
+void lspcon_standby(struct intel_digital_port *dig_port, bool connected)
+{
+   struct intel_dp *dp = &dig_port->dp;
+   u8 align_status = 0, training_pattern = 0, i;
+
+   if (connected) {
+   for (i = 0; i < 3; i++) {
+   usleep_range(1, 11000);
+
+   if (drm_dp_dpcd_readb(&dp->aux, 
DP_LANE_ALIGN_STATUS_UPDATED,
+ &align_status) <= 0) {
+   DRM_DEBUG_KMS("LSPCON failed to read align 
status\n");
+   return;
+   }
+
+   if (drm_dp_dpcd_readb(&dp->aux, DP_TRAINING_PATTERN_SET,
+ &training_pattern) <= 0) {
+   DRM_DEBUG_KMS("LSPCON failed to read training 
pattern set\n");
+   return;
+   }
+
+   /*
+* If link trainig is ongoing. Or sink updated link 
align status.
+* Source driver should not set lspcon power state to 
D3.
+*/
+   if (align_status || training_pattern) {
+   DRM_DEBUG_KMS("LSPCON link training or display 
is working\n");
+   DRM_DEBUG_KMS("LSPCON DPCD register 0102h = %x, 
0204h = 0x%x\n",
+ training_pattern, align_status);
+ 

Re: [Intel-gfx] [PATCH v2 04/13] drm/dp_helper: Add Helpers for FRL Link Training support for DP-HDMI2.1 PCON

[Shankar, Uma]

> -Original Message-
> From: Nautiyal, Ankit K 
> Sent: Sunday, November 1, 2020 3:37 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2 
> Subject: [PATCH v2 04/13] drm/dp_helper: Add Helpers for FRL Link Training
> support for DP-HDMI2.1 PCON
> 
> This patch adds support for configuring a PCON device, connected as a DP
> branched device to enable FRL Link training with a HDMI2.1 + sink.
> 
> v2: Fixed typos and addressed other review comments from Uma Shankar.
> -changed the commit message for better clarity (Uma Shankar) -removed
> unnecessary argument supplied to a drm helper function.
> -fixed return value for max frl read from pcon.
> 
> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 302 
>  include/drm/drm_dp_helper.h |  81 +
>  2 files changed, 383 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c index 14ddf28ecac0..b67580294c4e 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -2591,3 +2591,305 @@ void drm_dp_vsc_sdp_log(const char *level, struct
> device *dev,  #undef DP_SDP_LOG  }  EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
> +
> +/**
> + * drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
> + * @dpcd: DisplayPort configuration data
> + * @port_cap: port capabilities
> + *
> + * Returns maximum frl bandwidth supported by PCON in GBPS,
> + * returns 0 if not supported.
> + **/
> +int drm_dp_get_pcon_max_frl_bw(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +const u8 port_cap[4])
> +{
> + int bw;
> + u8 buf;
> +
> + buf = port_cap[2];
> + bw = buf & DP_PCON_MAX_FRL_BW;
> +
> + switch (bw) {
> + case DP_PCON_MAX_9GBPS:
> + return 9;
> + case DP_PCON_MAX_18GBPS:
> + return 18;
> + case DP_PCON_MAX_24GBPS:
> + return 24;
> + case DP_PCON_MAX_32GBPS:
> + return 32;
> + case DP_PCON_MAX_40GBPS:
> + return 40;
> + case DP_PCON_MAX_48GBPS:
> + return 48;
> + case DP_PCON_MAX_0GBPS:
> + default:
> + return 0;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_get_pcon_max_frl_bw);
> +
> +/**
> + * drm_dp_get_hdmi_sink_max_frl_bw() - maximum frl supported by HDMI
> +Sink
> + * @aux: DisplayPort AUX channel
> + *
> + * Returns maximum frl bandwidth supported by HDMI in Gbps on success,
> + * returns 0, if not supported.
> + **/
> +int drm_dp_get_hdmi_sink_max_frl_bw(struct drm_dp_aux *aux) {
> + u8 buf;
> + int bw, ret;
> +
> + ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_SINK, &buf);
> + if (ret < 0)
> + return 0;
> + bw = buf & DP_HDMI_SINK_LINK_BW;
> +
> + switch (bw) {
> + case DP_HDMI_SINK_BW_9GBPS:
> + return 9;
> + case DP_HDMI_SINK_BW_18GBPS:
> + return 18;
> + case DP_HDMI_SINK_BW_24GBPS:
> + return 24;
> + case DP_HDMI_SINK_BW_32GBPS:
> + return 32;
> + case DP_HDMI_SINK_BW_40GBPS:
> + return 40;
> + case DP_HDMI_SINK_BW_48GBPS:
> + return 48;
> + case DP_HDMI_SINK_BW_0GBPS:
> + default:
> + return 0;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_get_hdmi_sink_max_frl_bw);
> +
> +/**
> + * drm_dp_pcon_frl_prepare() - Prepare PCON for FRL.
> + * @aux: DisplayPort AUX channel
> + *
> + * Returns 0 if success, else returns negative error code.
> + **/
> +int drm_dp_pcon_frl_prepare(struct drm_dp_aux *aux, bool
> +enable_frl_ready_hpd) {
> + int ret;
> + u8 buf = DP_PCON_ENABLE_SOURCE_CTL_MODE |
> +  DP_PCON_ENABLE_LINK_FRL_MODE;
> +
> + if (enable_frl_ready_hpd)
> + buf |= DP_PCON_ENABLE_HPD_READY;
> +
> + ret = drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_1, buf);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_dp_pcon_frl_prepare);
> +
> +/**
> + * drm_dp_pcon_is_frl_ready() - Is PCON ready for FRL
> + * @aux: DisplayPort AUX channel
> + *
> + * Returns true if success, else returns false.
> + **/
> +bool drm_dp_pcon_is_frl_ready(struct drm_dp_aux *aux) {
> + int ret;
> + u8 buf;
> +
> + ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_TX_LINK_STATUS, &buf);
> + if (ret < 0)
> + return false;
> +
> + if (buf & DP_PCON_FRL_READY)
> + return true;
> +
> + return false;
> +}
> +EXPORT_SYMBOL(drm_dp_pcon_is_frl_ready);
> +
> +/**
> + * drm_dp_pcon_frl_configure_1() - Set HDMI LINK Configuration-Step1
> + * @aux: DisplayPort AUX channel
> + * @max_frl_gbps: maximum frl bw to be configured between PCON and HDMI
> +sink
> + * @concurrent_mode: true if concurrent mode or operation is required,
> + * false otherwise.
> + *
> + * Returns 0 if success, else returns negative error code.
> + **/
> +
> +int drm_dp_pc

Re: [Intel-gfx] [PATCH v2 05/13] drm/dp_helper: Add support for link failure detection

[Shankar, Uma]

> -Original Message-
> From: Nautiyal, Ankit K 
> Sent: Sunday, November 1, 2020 3:37 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2 
> Subject: [PATCH v2 05/13] drm/dp_helper: Add support for link failure 
> detection
> 
> From: Swati Sharma 
> 
> There are specific DPCDs defined for detecting link failures between the PCON
> and HDMI sink and check the link status. In case of link failure, PCON will
> communicate the same using an IRQ_HPD to source.
> HDMI sink would have indicated the same to PCON using SCDC interrupt
> mechanism. While source can always read final HDMI sink's status using I2C 
> over
> AUX, it is easier and faster to read the PCONs already read HDMI sink status
> registers.
> 
> This patch adds the DPCDs required for link failure detection and provide a
> helper function for printing error count/lane which might help in debugging 
> the
> link failure issues.
> 
> v2: Addressed comments from Uma Shankar:
> -rephrased the commit message, as per the code.
> -fixed styling issues
> -added documentation for the helper function.

Reviewed-by: Uma Shankar 

> Signed-off-by: Swati Sharma 
> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 39 +
>  include/drm/drm_dp_helper.h | 17 ++
>  2 files changed, 56 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c index b67580294c4e..05782091e7e1 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -2893,3 +2893,42 @@ int drm_dp_pcon_hdmi_link_mode(struct
> drm_dp_aux *aux, u8 *frl_trained_mask)
>   return mode;
>  }
>  EXPORT_SYMBOL(drm_dp_pcon_hdmi_link_mode);
> +
> +/**
> + * drm_dp_pcon_hdmi_frl_link_error_count() - print the error count per
> +lane
> + * during link failure between PCON and HDMI sink
> + * @aux: DisplayPort AUX channel
> + * @connector: DRM connector
> + * code.
> + **/
> +
> +void drm_dp_pcon_hdmi_frl_link_error_count(struct drm_dp_aux *aux,
> +struct drm_connector *connector) {
> + u8 buf, error_count;
> + int i, num_error;
> + struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
> +
> + for (i = 0; i < hdmi->max_lanes; i++) {
> + if (drm_dp_dpcd_readb(aux,
> DP_PCON_HDMI_ERROR_STATUS_LN0 + i, &buf) < 0)
> + return;
> +
> + error_count = buf & DP_PCON_HDMI_ERROR_COUNT_MASK;
> + switch (error_count) {
> + case DP_PCON_HDMI_ERROR_COUNT_HUNDRED_PLUS:
> + num_error = 100;
> + break;
> + case DP_PCON_HDMI_ERROR_COUNT_TEN_PLUS:
> + num_error = 10;
> + break;
> + case DP_PCON_HDMI_ERROR_COUNT_THREE_PLUS:
> + num_error = 3;
> + break;
> + default:
> + num_error = 0;
> + }
> +
> + DRM_ERROR("More than %d errors since the last read for lane
> %d", num_error, i);
> + }
> +}
> +EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index
> e2ed6bfaae89..bdbe9bbdb244 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -946,6 +946,11 @@ struct drm_device;
>  # define DP_CEC_IRQ  (1 << 2)
> 
>  #define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005   /* 1.2 */
> +# define RX_CAP_CHANGED  (1 << 0)
> +# define LINK_STATUS_CHANGED (1 << 1)
> +# define STREAM_STATUS_CHANGED   (1 << 2)
> +# define HDMI_LINK_STATUS_CHANGED(1 << 3)
> +# define CONNECTED_OFF_ENTRY_REQUESTED   (1 << 4)
> 
>  #define DP_PSR_ERROR_STATUS 0x2006  /* XXX 1.2? */
>  # define DP_PSR_LINK_CRC_ERROR  (1 << 0)
> @@ -1130,6 +1135,16 @@ struct drm_device;
>  #define DP_PROTOCOL_CONVERTER_CONTROL_2  0x3052 /* DP 1.3
> */
>  # define DP_CONVERSION_TO_YCBCR422_ENABLE(1 << 0) /* DP 1.3 */
> 
> +/* PCON Downstream HDMI ERROR Status per Lane */
> +#define DP_PCON_HDMI_ERROR_STATUS_LN0  0x3037
> +#define DP_PCON_HDMI_ERROR_STATUS_LN1  0x3038
> +#define DP_PCON_HDMI_ERROR_STATUS_LN2  0x3039
> +#define DP_PCON_HDMI_ERROR_STATUS_LN3  0x303A
> +# define DP_PCON_HDMI_ERROR_COUNT_MASK (0x7 << 0)
> +# define DP_PCON_HDMI_ERROR_COUNT_THREE_PLUS   (1 << 0)
> +# define DP_PCON_HDMI_ERROR_COUNT_TEN_PLUS (1 << 1)
> +# define DP_PCON_HDMI_ERROR_COUNT_HUNDRED_PLUS (1 << 2)
> +
>  /* HDCP 1.3 and HDCP 2.2 */
>  #define DP_AUX_HDCP_BKSV 0x68000
>  #define DP_AUX_HDCP_RI_PRIME 0x68005
> @@ -2047,5 +2062,7 @@ int drm_dp_pcon_frl_enable(struct drm_dp_aux *aux);
> 
>  bool drm_dp_pcon_hdmi_link_acti