Re: [Intel-gfx] [PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()

2020-01-15 Thread Chris Wilson
Quoting Daniel Vetter (2020-01-16 06:52:42)
> On Wed, Jan 15, 2020 at 08:52:45PM +, Chris Wilson wrote:
> > Since we may try and flush the cachelines associated with large buffers
> > (an 8K framebuffer is about 128MiB, even before we try HDR), this leads
> > to unacceptably long latencies (when using a voluntary CONFIG_PREEMPT).
> > If we call cond_resched() between each sg chunk, that it about every 128
> > pages, we have a natural break point in which to check if the process
> > needs to be rescheduled. Naturally, this means that drm_clflush_sg() can
> > only be called from process context -- which is true at the moment. The
> > other clflush routines remain usable from atomic context.
> > 
> > Even though flushing large objects takes a demonstrable amount to time
> > to flush all the cachelines, clflush is still preferred over a
> > system-wide wbinvd as the latter has unpredictable latencies affecting
> > the whole system not just the local task.
> > 
> > Reported-by: David Laight 
> > Signed-off-by: Chris Wilson 
> > Cc: David Laight 
> 
> The original bug report is complaining about latencies for SCHED_RT
> threads, on a system that doesn't even use CONFIG_PREEMPT. I'm not sure
> it's terribly valid to cater to that use-case - all the desktop distros
> seem a lot more reasonable. So firmly *shrug* from my side ...

Yeah, I had the same immediate response to the complaint), but otoh we've
inserted cond_resched() before when it looks like may consume entire
jiffies inside a loop. At the very minimum, we should have a
might_sleep() here and a reminder that this can be very slow (remember
byt?).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()

2020-01-15 Thread Daniel Vetter
On Wed, Jan 15, 2020 at 08:52:45PM +, Chris Wilson wrote:
> Since we may try and flush the cachelines associated with large buffers
> (an 8K framebuffer is about 128MiB, even before we try HDR), this leads
> to unacceptably long latencies (when using a voluntary CONFIG_PREEMPT).
> If we call cond_resched() between each sg chunk, that it about every 128
> pages, we have a natural break point in which to check if the process
> needs to be rescheduled. Naturally, this means that drm_clflush_sg() can
> only be called from process context -- which is true at the moment. The
> other clflush routines remain usable from atomic context.
> 
> Even though flushing large objects takes a demonstrable amount to time
> to flush all the cachelines, clflush is still preferred over a
> system-wide wbinvd as the latter has unpredictable latencies affecting
> the whole system not just the local task.
> 
> Reported-by: David Laight 
> Signed-off-by: Chris Wilson 
> Cc: David Laight 

The original bug report is complaining about latencies for SCHED_RT
threads, on a system that doesn't even use CONFIG_PREEMPT. I'm not sure
it's terribly valid to cater to that use-case - all the desktop distros
seem a lot more reasonable. So firmly *shrug* from my side ...

Patch itself looks correct, just not seeing the point.
-Daniel


> ---
>  drivers/gpu/drm/drm_cache.c | 49 ++---
>  1 file changed, 45 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
> index 03e01b000f7a..fbd2bb644544 100644
> --- a/drivers/gpu/drm/drm_cache.c
> +++ b/drivers/gpu/drm/drm_cache.c
> @@ -112,23 +112,64 @@ drm_clflush_pages(struct page *pages[], unsigned long 
> num_pages)
>  }
>  EXPORT_SYMBOL(drm_clflush_pages);
>  
> +static __always_inline struct sgt_iter {
> + struct scatterlist *sgp;
> + unsigned long pfn;
> + unsigned int curr;
> + unsigned int max;
> +} __sgt_iter(struct scatterlist *sgl) {
> + struct sgt_iter s = { .sgp = sgl };
> +
> + if (s.sgp) {
> + s.max = s.curr = s.sgp->offset;
> + s.max += s.sgp->length;
> + s.pfn = page_to_pfn(sg_page(s.sgp));
> + }
> +
> + return s;
> +}
> +
> +static inline struct scatterlist *__sg_next_resched(struct scatterlist *sg)
> +{
> + if (sg_is_last(sg))
> + return NULL;
> +
> + ++sg;
> + if (unlikely(sg_is_chain(sg))) {
> + sg = sg_chain_ptr(sg);
> + cond_resched();
> + }
> + return sg;
> +}
> +
> +#define for_each_sgt_page(__pp, __iter, __sgt)   
> \
> + for ((__iter) = __sgt_iter((__sgt)->sgl);   \
> +  ((__pp) = (__iter).pfn == 0 ? NULL :   \
> +   pfn_to_page((__iter).pfn + ((__iter).curr >> PAGE_SHIFT))); \
> +  (((__iter).curr += PAGE_SIZE) >= (__iter).max) ?   \
> +  (__iter) = __sgt_iter(__sg_next_resched((__iter).sgp)), 0 : 0)
> +
>  /**
>   * drm_clflush_sg - Flush dcache lines pointing to a scather-gather.
>   * @st: struct sg_table.
>   *
>   * Flush every data cache line entry that points to an address in the
> - * sg.
> + * sg. This may schedule between scatterlist chunks, in order to keep
> + * the system preemption-latency down for large buffers.
>   */
>  void
>  drm_clflush_sg(struct sg_table *st)
>  {
> + might_sleep();
> +
>  #if defined(CONFIG_X86)
>   if (static_cpu_has(X86_FEATURE_CLFLUSH)) {
> - struct sg_page_iter sg_iter;
> + struct sgt_iter sg_iter;
> + struct page *page;
>  
>   mb(); /*CLFLUSH is ordered only by using memory barriers*/
> - for_each_sg_page(st->sgl, _iter, st->nents, 0)
> - drm_clflush_page(sg_page_iter_page(_iter));
> + for_each_sgt_page(page, sg_iter, st)
> + drm_clflush_page(page);
>   mb(); /*Make sure that all cache line entry is flushed*/
>  
>   return;
> -- 
> 2.25.0
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm: bugs.freedesktop.org is no longer accepting bugs

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm: bugs.freedesktop.org is no longer accepting bugs
URL   : https://patchwork.freedesktop.org/series/72098/
State : warning

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 122 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:93: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1282: recipe for target 'modules' failed
make: *** [modules] Error 2

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16125/build_32bit.log
___
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: bugs.freedesktop.org is no longer accepting bugs

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm: bugs.freedesktop.org is no longer accepting bugs
URL   : https://patchwork.freedesktop.org/series/72098/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7753 -> Patchwork_16125


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_blt:
- fi-ivb-3770:[PASS][1] -> [DMESG-FAIL][2] ([i915#725])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-ivb-3770/igt@i915_selftest@live_blt.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16125/fi-ivb-3770/igt@i915_selftest@live_blt.html

  * igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6770hq:  [PASS][3] -> [SKIP][4] ([fdo#109271]) +27 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16125/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html

  
 Possible fixes 

  * igt@gem_ctx_param@basic:
- {fi-ehl-1}: [INCOMPLETE][5] ([i915#937]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-ehl-1/igt@gem_ctx_pa...@basic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16125/fi-ehl-1/igt@gem_ctx_pa...@basic.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-skl-6700k2:  [DMESG-WARN][7] ([i915#889]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-skl-6700k2/igt@i915_module_l...@reload-with-fault-injection.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16125/fi-skl-6700k2/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6600u:   [DMESG-WARN][9] ([i915#889]) -> [PASS][10] +23 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-skl-6600u/igt@i915_pm_...@module-reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16125/fi-skl-6600u/igt@i915_pm_...@module-reload.html
- fi-skl-6770hq:  [FAIL][11] ([i915#178]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16125/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_gt_lrc:
- fi-skl-6600u:   [DMESG-FAIL][13] ([i915#889]) -> [PASS][14] +7 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-skl-6600u/igt@i915_selftest@live_gt_lrc.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16125/fi-skl-6600u/igt@i915_selftest@live_gt_lrc.html

  * igt@i915_selftest@live_hangcheck:
- fi-kbl-7500u:   [DMESG-FAIL][15] ([i915#889]) -> [PASS][16] +7 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-kbl-7500u/igt@i915_selftest@live_hangcheck.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16125/fi-kbl-7500u/igt@i915_selftest@live_hangcheck.html

  * igt@i915_selftest@live_vma:
- fi-kbl-7500u:   [DMESG-WARN][17] ([i915#889]) -> [PASS][18] +23 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-kbl-7500u/igt@i915_selftest@live_vma.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16125/fi-kbl-7500u/igt@i915_selftest@live_vma.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#178]: https://gitlab.freedesktop.org/drm/intel/issues/178
  [i915#725]: https://gitlab.freedesktop.org/drm/intel/issues/725
  [i915#889]: https://gitlab.freedesktop.org/drm/intel/issues/889
  [i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937


Participating hosts (51 -> 41)
--

  Additional (1): fi-tgl-y 
  Missing(11): fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy fi-byt-squawks 
fi-bsw-cyan fi-ilk-650 fi-whl-u fi-gdg-551 fi-elk-e7500 fi-skl-lmem 
fi-byt-clapper 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7753 -> Patchwork_16125

  CI-20190529: 20190529
  CI_DRM_7753: cef3a815e760485d4c011adb3dafb4d49bff9378 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5367: 94af6de4f07487b93c4f5008f3ed04b5fc045200 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16125: ed770364cac3127d6fbeb244a93049bcc62399fb @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Kernel 32bit build ==

Warning: Kernel 32bit buildtest failed:
https://intel-gfx-ci.01.org/Patchwork_16125/build_32bit.log

  CALL

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block (rev4)

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block 
(rev4)
URL   : https://patchwork.freedesktop.org/series/71581/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7737_full -> Patchwork_16086_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@rcs0-s3:
- shard-kbl:  [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +5 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7737/shard-kbl6/igt@gem_ctx_isolat...@rcs0-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16086/shard-kbl2/igt@gem_ctx_isolat...@rcs0-s3.html

  * igt@gem_ctx_persistence@vcs1-cleanup:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [fdo#112080])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7737/shard-iclb2/igt@gem_ctx_persiste...@vcs1-cleanup.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16086/shard-iclb6/igt@gem_ctx_persiste...@vcs1-cleanup.html

  * igt@gem_ctx_persistence@vcs1-mixed-process:
- shard-iclb: [PASS][5] -> [FAIL][6] ([i915#679])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7737/shard-iclb4/igt@gem_ctx_persiste...@vcs1-mixed-process.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16086/shard-iclb4/igt@gem_ctx_persiste...@vcs1-mixed-process.html

  * igt@gem_eio@in-flight-contexts-1us:
- shard-snb:  [PASS][7] -> [FAIL][8] ([i915#490])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7737/shard-snb2/igt@gem_...@in-flight-contexts-1us.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16086/shard-snb4/igt@gem_...@in-flight-contexts-1us.html

  * igt@gem_exec_balancer@nop:
- shard-tglb: [PASS][9] -> [INCOMPLETE][10] ([fdo#111736] / 
[i915#472])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7737/shard-tglb4/igt@gem_exec_balan...@nop.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16086/shard-tglb3/igt@gem_exec_balan...@nop.html

  * igt@gem_exec_nop@basic-series:
- shard-tglb: [PASS][11] -> [INCOMPLETE][12] ([i915#472])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7737/shard-tglb4/igt@gem_exec_...@basic-series.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16086/shard-tglb1/igt@gem_exec_...@basic-series.html

  * igt@gem_exec_parallel@vcs1-fds:
- shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#112080]) +8 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7737/shard-iclb1/igt@gem_exec_paral...@vcs1-fds.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16086/shard-iclb3/igt@gem_exec_paral...@vcs1-fds.html

  * igt@gem_exec_schedule@pi-shared-iova-bsd:
- shard-iclb: [PASS][15] -> [SKIP][16] ([i915#677]) +1 similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7737/shard-iclb5/igt@gem_exec_sched...@pi-shared-iova-bsd.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16086/shard-iclb2/igt@gem_exec_sched...@pi-shared-iova-bsd.html

  * igt@gem_exec_schedule@preemptive-hang-bsd:
- shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#112146]) +7 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7737/shard-iclb3/igt@gem_exec_sched...@preemptive-hang-bsd.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16086/shard-iclb1/igt@gem_exec_sched...@preemptive-hang-bsd.html

  * igt@gem_persistent_relocs@forked-interruptible-thrash-inactive:
- shard-apl:  [PASS][19] -> [TIMEOUT][20] ([fdo#112271] / 
[i915#530])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7737/shard-apl3/igt@gem_persistent_rel...@forked-interruptible-thrash-inactive.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16086/shard-apl2/igt@gem_persistent_rel...@forked-interruptible-thrash-inactive.html

  * igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk:  [PASS][21] -> [FAIL][22] ([i915#644])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7737/shard-glk7/igt@gem_pp...@flink-and-close-vma-leak.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16086/shard-glk5/igt@gem_pp...@flink-and-close-vma-leak.html

  * igt@gen9_exec_parse@allowed-all:
- shard-kbl:  [PASS][23] -> [DMESG-WARN][24] ([i915#716])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7737/shard-kbl1/igt@gen9_exec_pa...@allowed-all.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16086/shard-kbl1/igt@gen9_exec_pa...@allowed-all.html

  * igt@i915_pm_dc@dc6-dpms:
- shard-iclb: [PASS][25] -> [FAIL][26] ([i915#454]) +1 similar issue
   [25]: 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: bugs.freedesktop.org is no longer accepting bugs

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm: bugs.freedesktop.org is no longer accepting bugs
URL   : https://patchwork.freedesktop.org/series/72098/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
ed770364cac3 drm: bugs.freedesktop.org is no longer accepting bugs
-:23: WARNING:BAD_SIGN_OFF: Do not use whitespace before Signed-off-by:
#23: 
Signed-off-by: Christian Kujau 

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

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


[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: conversion to new drm logging macros.

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915: conversion to new drm logging macros.
URL   : https://patchwork.freedesktop.org/series/72096/
State : failure

== Summary ==

Applying: drm/i915/atomic: use new logging macros for debug
Applying: drm/i915/audio: convert to new drm logging macros.
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/display/intel_audio.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/display/intel_audio.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/display/intel_audio.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch' to see the failed patch
Patch failed at 0002 drm/i915/audio: convert to new drm logging macros.
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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


[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/audio: convert to using drm_dbg_kms()

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915/audio: convert to using drm_dbg_kms()
URL   : https://patchwork.freedesktop.org/series/72097/
State : failure

== Summary ==

Applying: drm/i915/audio: convert to using drm_dbg_kms()
error: sha1 information is lacking or useless 
(drivers/gpu/drm/i915/display/intel_audio.c).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch' to see the failed patch
Patch failed at 0001 drm/i915/audio: convert to using drm_dbg_kms()
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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


[Intel-gfx] [PATCH 4/5] drm/i915/bw: convert to new drm_device based logging macros.

2020-01-15 Thread Wambui Karuga
This replaces the printk based logging macros with the struct drm_based
macros in i915/display/intel_bw.c
This transformation was achieved by using the following coccinelle
script that matches based on the existence of a struct drm_i915_private
device in the functions:

@rule1@
identifier fn, T;
@@

fn(struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
)
...+>
}

@rule2@
identifier fn, T;
@@

fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
)
...+>
}

Resulting checkpatch warnings were addressed manually.

Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/i915/display/intel_bw.c | 29 +++--
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index b228671d5a5d..9c40ad52dd73 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -132,9 +132,10 @@ static int icl_get_qgv_points(struct drm_i915_private 
*dev_priv,
if (ret)
return ret;
 
-   DRM_DEBUG_KMS("QGV %d: DCLK=%d tRP=%d tRDPRE=%d tRAS=%d tRCD=%d 
tRC=%d\n",
- i, sp->dclk, sp->t_rp, sp->t_rdpre, sp->t_ras,
- sp->t_rcd, sp->t_rc);
+   drm_dbg_kms(_priv->drm,
+   "QGV %d: DCLK=%d tRP=%d tRDPRE=%d tRAS=%d tRCD=%d 
tRC=%d\n",
+   i, sp->dclk, sp->t_rp, sp->t_rdpre, sp->t_ras,
+   sp->t_rcd, sp->t_rc);
}
 
return 0;
@@ -187,7 +188,8 @@ static int icl_get_bw_info(struct drm_i915_private 
*dev_priv, const struct intel
 
ret = icl_get_qgv_points(dev_priv, );
if (ret) {
-   DRM_DEBUG_KMS("Failed to get memory subsystem information, 
ignoring bandwidth limits");
+   drm_dbg_kms(_priv->drm,
+   "Failed to get memory subsystem information, 
ignoring bandwidth limits");
return ret;
}
num_channels = qi.num_channels;
@@ -228,8 +230,9 @@ static int icl_get_bw_info(struct drm_i915_private 
*dev_priv, const struct intel
bi->deratedbw[j] = min(maxdebw,
   bw * 9 / 10); /* 90% */
 
-   DRM_DEBUG_KMS("BW%d / QGV %d: num_planes=%d 
deratedbw=%u\n",
- i, j, bi->num_planes, bi->deratedbw[j]);
+   drm_dbg_kms(_priv->drm,
+   "BW%d / QGV %d: num_planes=%d 
deratedbw=%u\n",
+   i, j, bi->num_planes, bi->deratedbw[j]);
}
 
if (bi->num_planes == 1)
@@ -424,10 +427,11 @@ int intel_bw_atomic_check(struct intel_atomic_state 
*state)
bw_state->data_rate[crtc->pipe] = new_data_rate;
bw_state->num_active_planes[crtc->pipe] = new_active_planes;
 
-   DRM_DEBUG_KMS("pipe %c data rate %u num active planes %u\n",
- pipe_name(crtc->pipe),
- bw_state->data_rate[crtc->pipe],
- bw_state->num_active_planes[crtc->pipe]);
+   drm_dbg_kms(_priv->drm,
+   "pipe %c data rate %u num active planes %u\n",
+   pipe_name(crtc->pipe),
+   bw_state->data_rate[crtc->pipe],
+   bw_state->num_active_planes[crtc->pipe]);
}
 
if (!bw_state)
@@ -441,8 +445,9 @@ int intel_bw_atomic_check(struct intel_atomic_state *state)
data_rate = DIV_ROUND_UP(data_rate, 1000);
 
if (data_rate > max_data_rate) {
-   DRM_DEBUG_KMS("Bandwidth %u MB/s exceeds max available %d MB/s 
(%d active planes)\n",
- data_rate, max_data_rate, num_active_planes);
+   drm_dbg_kms(_priv->drm,
+   "Bandwidth %u MB/s exceeds max available %d MB/s 
(%d active planes)\n",
+   data_rate, max_data_rate, num_active_planes);
return -EINVAL;
}
 
-- 
2.24.1

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


[Intel-gfx] [PATCH 2/5] drm/i915/audio: convert to new drm logging macros.

2020-01-15 Thread Wambui Karuga
Converts the printk based logging macros in i915/display/intel_audio.c
to the struct drm_device based logging macros.
This transformation was achieved using the following coccinelle script
that matches the existence of the struct drm_i915_private device:

@rule1@
identifier fn, T;
@@

fn(struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
)
...+>
}

@rule2@
identifier fn, T;
@@

fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
)
...+>
}

Checkpatch warnings were manually fixed.

Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/i915/display/intel_audio.c | 71 --
 1 file changed, 40 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
b/drivers/gpu/drm/i915/display/intel_audio.c
index e406719a6716..57208440bf6d 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -315,7 +315,7 @@ static void g4x_audio_codec_disable(struct intel_encoder 
*encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 eldv, tmp;
 
-   DRM_DEBUG_KMS("Disable audio codec\n");
+   drm_dbg_kms(_priv->drm, "Disable audio codec\n");
 
tmp = I915_READ(G4X_AUD_VID_DID);
if (tmp == INTEL_AUDIO_DEVBLC || tmp == INTEL_AUDIO_DEVCL)
@@ -340,7 +340,8 @@ static void g4x_audio_codec_enable(struct intel_encoder 
*encoder,
u32 tmp;
int len, i;
 
-   DRM_DEBUG_KMS("Enable audio codec, %u bytes ELD\n", drm_eld_size(eld));
+   drm_dbg_kms(_priv->drm, "Enable audio codec, %u bytes ELD\n",
+   drm_eld_size(eld));
 
tmp = I915_READ(G4X_AUD_VID_DID);
if (tmp == INTEL_AUDIO_DEVBLC || tmp == INTEL_AUDIO_DEVCL)
@@ -360,7 +361,7 @@ static void g4x_audio_codec_enable(struct intel_encoder 
*encoder,
I915_WRITE(G4X_AUD_CNTL_ST, tmp);
 
len = min(drm_eld_size(eld) / 4, len);
-   DRM_DEBUG_DRIVER("ELD size %d\n", len);
+   drm_dbg(_priv->drm, "ELD size %d\n", len);
for (i = 0; i < len; i++)
I915_WRITE(G4X_HDMIW_HDMIEDID, *((const u32 *)eld + i));
 
@@ -384,9 +385,10 @@ hsw_dp_audio_config_update(struct intel_encoder *encoder,
rate = acomp ? acomp->aud_sample_rate[port] : 0;
nm = audio_config_dp_get_n_m(crtc_state, rate);
if (nm)
-   DRM_DEBUG_KMS("using Maud %u, Naud %u\n", nm->m, nm->n);
+   drm_dbg_kms(_priv->drm, "using Maud %u, Naud %u\n", nm->m,
+   nm->n);
else
-   DRM_DEBUG_KMS("using automatic Maud, Naud\n");
+   drm_dbg_kms(_priv->drm, "using automatic Maud, Naud\n");
 
tmp = I915_READ(HSW_AUD_CFG(cpu_transcoder));
tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
@@ -437,13 +439,13 @@ hsw_hdmi_audio_config_update(struct intel_encoder 
*encoder,
 
n = audio_config_hdmi_get_n(crtc_state, rate);
if (n != 0) {
-   DRM_DEBUG_KMS("using N %d\n", n);
+   drm_dbg_kms(_priv->drm, "using N %d\n", n);
 
tmp &= ~AUD_CONFIG_N_MASK;
tmp |= AUD_CONFIG_N(n);
tmp |= AUD_CONFIG_N_PROG_ENABLE;
} else {
-   DRM_DEBUG_KMS("using automatic N\n");
+   drm_dbg_kms(_priv->drm, "using automatic N\n");
}
 
I915_WRITE(HSW_AUD_CFG(cpu_transcoder), tmp);
@@ -476,8 +478,8 @@ static void hsw_audio_codec_disable(struct intel_encoder 
*encoder,
enum transcoder cpu_transcoder = old_crtc_state->cpu_transcoder;
u32 tmp;
 
-   DRM_DEBUG_KMS("Disable audio codec on transcoder %s\n",
- transcoder_name(cpu_transcoder));
+   drm_dbg_kms(_priv->drm, "Disable audio codec on transcoder %s\n",
+   transcoder_name(cpu_transcoder));
 
mutex_lock(_priv->av_mutex);
 
@@ -511,8 +513,9 @@ static void hsw_audio_codec_enable(struct intel_encoder 
*encoder,
u32 tmp;
int len, i;
 
-   DRM_DEBUG_KMS("Enable audio codec on transcoder %s, %u bytes ELD\n",
- transcoder_name(cpu_transcoder), drm_eld_size(eld));
+   drm_dbg_kms(_priv->drm,
+   "Enable audio codec on transcoder %s, %u bytes ELD\n",
+transcoder_name(cpu_transcoder), drm_eld_size(eld));
 
mutex_lock(_priv->av_mutex);
 
@@ -561,9 +564,10 @@ static void ilk_audio_codec_disable(struct intel_encoder 
*encoder,
u32 tmp, eldv;
i915_reg_t aud_config, aud_cntrl_st2;
 
-   DRM_DEBUG_KMS("Disable audio codec on [ENCODER:%d:%s], pipe %c\n",
-

[Intel-gfx] [PATCH 5/5] drm/i915/cdclk: use new drm logging macros.

2020-01-15 Thread Wambui Karuga
Converts instances of the printk based debugging macros with the new
struct drm_device based logging macros in i915/display/intel_cdclk.c.
The conversion is achieved using the following coccinelle script that
transforms based on the existence of a struct drm_i915_private device in
the function:

@rule1@
identifier fn, T;
@@

fn(struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
)
...+>
}

@rule2@
identifier fn, T;
@@

fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
)
...+>
}

Resulting checkpatch warnings were fixed manually.

Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/i915/display/intel_cdclk.c | 109 -
 1 file changed, 64 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 7d1ab1e5b7c3..cce04a4b758e 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -242,9 +242,10 @@ static unsigned int intel_hpll_vco(struct drm_i915_private 
*dev_priv)
 
vco = vco_table[tmp & 0x7];
if (vco == 0)
-   DRM_ERROR("Bad HPLL VCO (HPLLVCO=0x%02x)\n", tmp);
+   drm_err(_priv->drm, "Bad HPLL VCO (HPLLVCO=0x%02x)\n",
+   tmp);
else
-   DRM_DEBUG_KMS("HPLL VCO %u kHz\n", vco);
+   drm_dbg_kms(_priv->drm, "HPLL VCO %u kHz\n", vco);
 
return vco;
 }
@@ -292,8 +293,9 @@ static void g33_get_cdclk(struct drm_i915_private *dev_priv,
return;
 
 fail:
-   DRM_ERROR("Unable to determine CDCLK. HPLL VCO=%u kHz, CFGC=0x%08x\n",
- cdclk_state->vco, tmp);
+   drm_err(_priv->drm,
+   "Unable to determine CDCLK. HPLL VCO=%u kHz, CFGC=0x%08x\n",
+   cdclk_state->vco, tmp);
cdclk_state->cdclk = 190476;
 }
 
@@ -319,7 +321,8 @@ static void pnv_get_cdclk(struct drm_i915_private *dev_priv,
cdclk_state->cdclk = 20;
break;
default:
-   DRM_ERROR("Unknown pnv display core clock 0x%04x\n", gcfgc);
+   drm_err(_priv->drm,
+   "Unknown pnv display core clock 0x%04x\n", gcfgc);
/* fall through */
case GC_DISPLAY_CLOCK_133_MHZ_PNV:
cdclk_state->cdclk = 13;
@@ -369,8 +372,9 @@ static void i965gm_get_cdclk(struct drm_i915_private 
*dev_priv,
return;
 
 fail:
-   DRM_ERROR("Unable to determine CDCLK. HPLL VCO=%u kHz, CFGC=0x%04x\n",
- cdclk_state->vco, tmp);
+   drm_err(_priv->drm,
+   "Unable to determine CDCLK. HPLL VCO=%u kHz, CFGC=0x%04x\n",
+   cdclk_state->vco, tmp);
cdclk_state->cdclk = 20;
 }
 
@@ -397,8 +401,9 @@ static void gm45_get_cdclk(struct drm_i915_private 
*dev_priv,
cdclk_state->cdclk = cdclk_sel ? 32 : 228571;
break;
default:
-   DRM_ERROR("Unable to determine CDCLK. HPLL VCO=%u, 
CFGC=0x%04x\n",
- cdclk_state->vco, tmp);
+   drm_err(_priv->drm,
+   "Unable to determine CDCLK. HPLL VCO=%u, CFGC=0x%04x\n",
+   cdclk_state->vco, tmp);
cdclk_state->cdclk = 22;
break;
}
@@ -563,7 +568,8 @@ static void vlv_set_cdclk(struct drm_i915_private *dev_priv,
if (wait_for((vlv_punit_read(dev_priv, PUNIT_REG_DSPSSPM) &
  DSPFREQSTAT_MASK) == (cmd << DSPFREQSTAT_SHIFT),
 50)) {
-   DRM_ERROR("timed out waiting for CDclk change\n");
+   drm_err(_priv->drm,
+   "timed out waiting for CDclk change\n");
}
 
if (cdclk == 40) {
@@ -581,7 +587,8 @@ static void vlv_set_cdclk(struct drm_i915_private *dev_priv,
if (wait_for((vlv_cck_read(dev_priv, CCK_DISPLAY_CLOCK_CONTROL) 
&
  CCK_FREQUENCY_STATUS) == (divider << 
CCK_FREQUENCY_STATUS_SHIFT),
 50))
-   DRM_ERROR("timed out waiting for CDclk change\n");
+   drm_err(_priv->drm,
+   "timed out waiting for CDclk change\n");
}
 
/* adjust self-refresh exit latency value */
@@ -645,7 +652,8 @@ static void chv_set_cdclk(struct drm_i915_private *dev_priv,
if (wait_for((vlv_punit_read(dev_priv, PUNIT_REG_DSPSSPM) &
  DSPFREQSTAT_MASK_CHV) == (cmd << DSPFREQSTAT_SHIFT_CHV),
 50)) {
-  

[Intel-gfx] [PATCH] drm: bugs.freedesktop.org is no longer accepting bugs

2020-01-15 Thread Christian Kujau
Hello,

this should apply cleanly to drm-tip.


drm: bugs.freedesktop.org is no longer accepting bugs.

freedesktop.org Bugzilla is no longer in use and new DRM bugs
should be reported to https://gitlab.freedesktop.org/drm/intel
instead. While we're at it, update some URLs of still-open bugs
that have been moved to the new bug tracker.

 drivers/gpu/drm/i915/Kconfig   | 3 +--
 drivers/gpu/drm/i915/i915_gpu_error.c  | 2 +-
 drivers/gpu/drm/i915/i915_utils.c  | 2 +-
 drivers/gpu/drm/radeon/radeon_device.c | 2 +-
 4 files changed, 4 insertions(+), 5 deletions(-)

Signed-off-by: Christian Kujau 

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index ba9595960bbe..f2f4bcaaa1d5 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -75,8 +75,7 @@ config DRM_I915_CAPTURE_ERROR
help
  This option enables capturing the GPU state when a hang is detected.
  This information is vital for triaging hangs and assists in debugging.
- Please report any hang to
-   https://bugs.freedesktop.org/enter_bug.cgi?product=DRI
+ Please report any hang to https://gitlab.freedesktop.org/drm/intel
  for triaging.
 
  If in doubt, say "Y".
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 4c1836f0a991..9fba5ac9020d 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1852,7 +1852,7 @@ void i915_error_state_store(struct i915_gpu_coredump 
*error)
if (!xchg(, true) &&
ktime_get_real_seconds() - DRIVER_TIMESTAMP < DAY_AS_SECONDS(180)) {
pr_info("GPU hangs can indicate a bug anywhere in the entire 
gfx stack, including userspace.\n");
-   pr_info("Please file a _new_ bug report on bugs.freedesktop.org 
against DRI -> DRM/Intel\n");
+   pr_info("Please file a new bug report on 
https://gitlab.freedesktop.org/drm/intel\n;);
pr_info("drm/i915 developers can then reassign to the right 
component if it's not a kernel issue.\n");
pr_info("The GPU crash dump is required to analyze GPU hangs, 
so please always attach it.\n");
pr_info("GPU crash dump saved to /sys/class/drm/card%d/error\n",
diff --git a/drivers/gpu/drm/i915/i915_utils.c 
b/drivers/gpu/drm/i915/i915_utils.c
index c47261ae86ea..f93a4c005d7a 100644
--- a/drivers/gpu/drm/i915/i915_utils.c
+++ b/drivers/gpu/drm/i915/i915_utils.c
@@ -8,7 +8,7 @@
 #include "i915_drv.h"
 #include "i915_utils.h"
 
-#define FDO_BUG_URL "https://bugs.freedesktop.org/enter_bug.cgi?product=DRI;
+#define FDO_BUG_URL "https://gitlab.freedesktop.org/drm/intel;
 #define FDO_BUG_MSG "Please file a bug at " FDO_BUG_URL " against DRM/Intel " \
"providing the dmesg log by booting with drm.debug=0xf"
 
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index a522e092038b..b044dd912239 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -144,7 +144,7 @@ static struct radeon_px_quirk radeon_px_quirk_list[] = {
 */
{ PCI_VENDOR_ID_ATI, 0x6840, 0x1043, 0x2122, RADEON_PX_QUIRK_DISABLE_PX 
},
/* Asus K53TK laptop with AMD A6-3420M APU and Radeon 7670m GPU
-* https://bugs.freedesktop.org/show_bug.cgi?id=101491
+* https://gitlab.freedesktop.org/drm/amd/issues/803
 */
{ PCI_VENDOR_ID_ATI, 0x6741, 0x1043, 0x2122, RADEON_PX_QUIRK_DISABLE_PX 
},
/* Asus K73TK laptop with AMD A6-3420M APU and Radeon 7670m GPU

-- 
BOFH excuse #397:

T-1's congested due to porn traffic to the news server.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v4 1/9] capabilities: introduce CAP_SYS_PERFMON to kernel and user space

2020-01-15 Thread Song Liu



> On Dec 18, 2019, at 1:24 AM, Alexey Budankov 
>  wrote:
> 
> 
> Introduce CAP_SYS_PERFMON capability devoted to secure system performance
> monitoring and observability operations so that CAP_SYS_PERFMON would
> assist CAP_SYS_ADMIN capability in its governing role for perf_events,
> i915_perf and other subsystems of the kernel.
> 
> CAP_SYS_PERFMON intends to harden system security and integrity during
> system performance monitoring and observability operations by decreasing
> attack surface that is available to CAP_SYS_ADMIN privileged processes.
> 
> CAP_SYS_PERFMON intends to take over CAP_SYS_ADMIN credentials related
> to system performance monitoring and observability operations and balance
> amount of CAP_SYS_ADMIN credentials in accordance with the recommendations
> provided in the man page for CAP_SYS_ADMIN [1]: "Note: this capability
> is overloaded; see Notes to kernel developers, below."
> 
> [1] 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__man7.org_linux_man-2Dpages_man7_capabilities.7.html=DwICaQ=5VD0RTtNlTh3ycd41b3MUw=dR8692q0_uaizy0jkrBJQM5k2hfm4CiFxYT8KaysFrg=L5qCuMRrTvYhyjR1rpgE9vEv4HppVlOXDIzKzoGL30c=FNJpET4buKFRuqktVHQphaY1qE7IsdFpU4iYwpCn4tY=
>  
> 
> Signed-off-by: Alexey Budankov 

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


[Intel-gfx] [PATCH 0/5] drm/i915: conversion to new drm logging macros.

2020-01-15 Thread Wambui Karuga
This series continues the conversion to the new struct drm_device based
logging macros in drm/i915. These patches were mostly achieved using
coccinelle:
@rule1@
identifier fn, T;
@@

fn(struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
)
...+>
}

@rule2@
identifier fn, T;
@@

fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
)
...+>
}

Wambui Karuga (5):
  drm/i915/atomic: use new logging macros for debug
  drm/i915/audio: convert to new drm logging macros.
  drm/i915/bios: convert to new drm logging macros.
  drm/i915/bw: convert to new drm_device based logging macros.
  drm/i915/cdclk: use new drm logging macros.

 drivers/gpu/drm/i915/display/intel_atomic_plane.c |   9 +-
 drivers/gpu/drm/i915/display/intel_audio.c|  71 ++--
 drivers/gpu/drm/i915/display/intel_bios.c | 357 +++---
 drivers/gpu/drm/i915/display/intel_bw.c   |  29 +-
 drivers/gpu/drm/i915/display/intel_cdclk.c| 109 +++---
 5 files changed, 337 insertions(+), 238 deletions(-)

-- 
2.24.1

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


Re: [Intel-gfx] [PATCH 2/5] drm/i915/audio: convert to new drm logging macros.

2020-01-15 Thread Wambui Karuga




On Tue, 14 Jan 2020, Jani Nikula wrote:


On Tue, 14 Jan 2020, Jani Nikula  wrote:

On Tue, 14 Jan 2020, Wambui Karuga  wrote:

Converts the printk based logging macros in i915/display/intel_audio.c
to the struct drm_device based logging macros.


Couple of comments inline.


PS. This is

Reviewed-by: Jani Nikula 

and I'm fine with the requested changes being applied as separate
patches as long as they happen.



Sure, I think a separate patch for those changes might be best.
I'll do that.

Thanks,
wambui.


BR,
Jani.



This transformation was achieved using the following coccinelle script
that matches the existence of the struct drm_i915_private device:

@rule1@
identifier fn, T;
@@

fn(struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
)
...+>
}

@rule2@
identifier fn, T;
@@

fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
)
...+>
}

Checkpatch warnings were manually fixed.

Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/i915/display/intel_audio.c | 71 --
 1 file changed, 40 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
b/drivers/gpu/drm/i915/display/intel_audio.c
index e406719a6716..57208440bf6d 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -315,7 +315,7 @@ static void g4x_audio_codec_disable(struct intel_encoder 
*encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 eldv, tmp;

-   DRM_DEBUG_KMS("Disable audio codec\n");
+   drm_dbg_kms(_priv->drm, "Disable audio codec\n");

tmp = I915_READ(G4X_AUD_VID_DID);
if (tmp == INTEL_AUDIO_DEVBLC || tmp == INTEL_AUDIO_DEVCL)
@@ -340,7 +340,8 @@ static void g4x_audio_codec_enable(struct intel_encoder 
*encoder,
u32 tmp;
int len, i;

-   DRM_DEBUG_KMS("Enable audio codec, %u bytes ELD\n", drm_eld_size(eld));
+   drm_dbg_kms(_priv->drm, "Enable audio codec, %u bytes ELD\n",
+   drm_eld_size(eld));

tmp = I915_READ(G4X_AUD_VID_DID);
if (tmp == INTEL_AUDIO_DEVBLC || tmp == INTEL_AUDIO_DEVCL)
@@ -360,7 +361,7 @@ static void g4x_audio_codec_enable(struct intel_encoder 
*encoder,
I915_WRITE(G4X_AUD_CNTL_ST, tmp);

len = min(drm_eld_size(eld) / 4, len);
-   DRM_DEBUG_DRIVER("ELD size %d\n", len);
+   drm_dbg(_priv->drm, "ELD size %d\n", len);


Please convert this to drm_dbg_kms() while at it.


for (i = 0; i < len; i++)
I915_WRITE(G4X_HDMIW_HDMIEDID, *((const u32 *)eld + i));

@@ -384,9 +385,10 @@ hsw_dp_audio_config_update(struct intel_encoder *encoder,
rate = acomp ? acomp->aud_sample_rate[port] : 0;
nm = audio_config_dp_get_n_m(crtc_state, rate);
if (nm)
-   DRM_DEBUG_KMS("using Maud %u, Naud %u\n", nm->m, nm->n);
+   drm_dbg_kms(_priv->drm, "using Maud %u, Naud %u\n", nm->m,
+   nm->n);
else
-   DRM_DEBUG_KMS("using automatic Maud, Naud\n");
+   drm_dbg_kms(_priv->drm, "using automatic Maud, Naud\n");

tmp = I915_READ(HSW_AUD_CFG(cpu_transcoder));
tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
@@ -437,13 +439,13 @@ hsw_hdmi_audio_config_update(struct intel_encoder 
*encoder,

n = audio_config_hdmi_get_n(crtc_state, rate);
if (n != 0) {
-   DRM_DEBUG_KMS("using N %d\n", n);
+   drm_dbg_kms(_priv->drm, "using N %d\n", n);

tmp &= ~AUD_CONFIG_N_MASK;
tmp |= AUD_CONFIG_N(n);
tmp |= AUD_CONFIG_N_PROG_ENABLE;
} else {
-   DRM_DEBUG_KMS("using automatic N\n");
+   drm_dbg_kms(_priv->drm, "using automatic N\n");
}

I915_WRITE(HSW_AUD_CFG(cpu_transcoder), tmp);
@@ -476,8 +478,8 @@ static void hsw_audio_codec_disable(struct intel_encoder 
*encoder,
enum transcoder cpu_transcoder = old_crtc_state->cpu_transcoder;
u32 tmp;

-   DRM_DEBUG_KMS("Disable audio codec on transcoder %s\n",
- transcoder_name(cpu_transcoder));
+   drm_dbg_kms(_priv->drm, "Disable audio codec on transcoder %s\n",
+   transcoder_name(cpu_transcoder));

mutex_lock(_priv->av_mutex);

@@ -511,8 +513,9 @@ static void hsw_audio_codec_enable(struct intel_encoder 
*encoder,
u32 tmp;
int len, i;

-   DRM_DEBUG_KMS("Enable audio codec on transcoder %s, %u bytes ELD\n",
- transcoder_name(cpu_transcoder), drm_eld_size(eld));
+   

[Intel-gfx] [PATCH 1/5] drm/i915/atomic: use new logging macros for debug

2020-01-15 Thread Wambui Karuga
Convert to the new struct drm_based logging macros to replace the printk
based macros in i915/display/intel_atomic_plane.c.

Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/i915/display/intel_atomic_plane.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 3e97af682b1b..8cbb29a860a3 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -183,10 +183,11 @@ bool intel_plane_calc_min_cdclk(struct intel_atomic_state 
*state,
 * must be true since we have crtc_state).
 */
if (crtc_state->min_cdclk[plane->id] > dev_priv->cdclk.logical.cdclk) {
-   DRM_DEBUG_KMS("[PLANE:%d:%s] min_cdclk (%d kHz) > logical cdclk 
(%d kHz)\n",
- plane->base.base.id, plane->base.name,
- crtc_state->min_cdclk[plane->id],
- dev_priv->cdclk.logical.cdclk);
+   drm_dbg_kms(_priv->drm,
+   "[PLANE:%d:%s] min_cdclk (%d kHz) > logical cdclk 
(%d kHz)\n",
+   plane->base.base.id, plane->base.name,
+   crtc_state->min_cdclk[plane->id],
+   dev_priv->cdclk.logical.cdclk);
return true;
}
 
-- 
2.24.1

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


[Intel-gfx] [PATCH 3/5] drm/i915/bios: convert to new drm logging macros.

2020-01-15 Thread Wambui Karuga
This replaces the printk based logging macros with the struct drm_device
based logging macros.
This conversion was achieved using the following coccinelle script that
transforms based on the existence of a struct drm_i915_private device:
@rule1@
identifier fn, T;
@@

fn(struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
)
...+>
}

@rule2@
identifier fn, T;
@@

fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
)
...+>
}

Formatting warnings by checkpatch are addressed manually.

Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/i915/display/intel_bios.c | 357 +-
 1 file changed, 211 insertions(+), 146 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 8beac06e3f10..0bfc59639db8 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -230,15 +230,18 @@ parse_panel_options(struct drm_i915_private *dev_priv,
if (ret >= 0) {
WARN_ON(ret > 0xf);
panel_type = ret;
-   DRM_DEBUG_KMS("Panel type: %d (OpRegion)\n", panel_type);
+   drm_dbg_kms(_priv->drm, "Panel type: %d (OpRegion)\n",
+   panel_type);
} else {
if (lvds_options->panel_type > 0xf) {
-   DRM_DEBUG_KMS("Invalid VBT panel type 0x%x\n",
- lvds_options->panel_type);
+   drm_dbg_kms(_priv->drm,
+   "Invalid VBT panel type 0x%x\n",
+   lvds_options->panel_type);
return;
}
panel_type = lvds_options->panel_type;
-   DRM_DEBUG_KMS("Panel type: %d (VBT)\n", panel_type);
+   drm_dbg_kms(_priv->drm, "Panel type: %d (VBT)\n",
+   panel_type);
}
 
dev_priv->vbt.panel_type = panel_type;
@@ -253,15 +256,17 @@ parse_panel_options(struct drm_i915_private *dev_priv,
switch (drrs_mode) {
case 0:
dev_priv->vbt.drrs_type = STATIC_DRRS_SUPPORT;
-   DRM_DEBUG_KMS("DRRS supported mode is static\n");
+   drm_dbg_kms(_priv->drm, "DRRS supported mode is static\n");
break;
case 2:
dev_priv->vbt.drrs_type = SEAMLESS_DRRS_SUPPORT;
-   DRM_DEBUG_KMS("DRRS supported mode is seamless\n");
+   drm_dbg_kms(_priv->drm,
+   "DRRS supported mode is seamless\n");
break;
default:
dev_priv->vbt.drrs_type = DRRS_NOT_SUPPORTED;
-   DRM_DEBUG_KMS("DRRS not supported (VBT input)\n");
+   drm_dbg_kms(_priv->drm,
+   "DRRS not supported (VBT input)\n");
break;
}
 }
@@ -298,7 +303,8 @@ parse_lfp_panel_dtd(struct drm_i915_private *dev_priv,
 
dev_priv->vbt.lfp_lvds_vbt_mode = panel_fixed_mode;
 
-   DRM_DEBUG_KMS("Found panel mode in BIOS VBT legacy lfp table:\n");
+   drm_dbg_kms(_priv->drm,
+   "Found panel mode in BIOS VBT legacy lfp table:\n");
drm_mode_debug_printmodeline(panel_fixed_mode);
 
fp_timing = get_lvds_fp_timing(bdb, lvds_lfp_data,
@@ -309,8 +315,9 @@ parse_lfp_panel_dtd(struct drm_i915_private *dev_priv,
if (fp_timing->x_res == panel_fixed_mode->hdisplay &&
fp_timing->y_res == panel_fixed_mode->vdisplay) {
dev_priv->vbt.bios_lvds_val = fp_timing->lvds_reg_val;
-   DRM_DEBUG_KMS("VBT initial LVDS value %x\n",
- dev_priv->vbt.bios_lvds_val);
+   drm_dbg_kms(_priv->drm,
+   "VBT initial LVDS value %x\n",
+   dev_priv->vbt.bios_lvds_val);
}
}
 }
@@ -329,20 +336,22 @@ parse_generic_dtd(struct drm_i915_private *dev_priv,
return;
 
if (generic_dtd->gdtd_size < sizeof(struct generic_dtd_entry)) {
-   DRM_ERROR("GDTD size %u is too small.\n",
- generic_dtd->gdtd_size);
+   drm_err(_priv->drm, "GDTD size %u is too small.\n",
+   generic_dtd->gdtd_size);
return;
} else if (generic_dtd->gdtd_size !=
   sizeof(struct generic_dtd_entry)) {
-   DRM_ERROR("Unexpected GDTD size %u\n", generic_dtd->gdtd_size);
+  

Re: [Intel-gfx] [PATCH v4 5/9] trace/bpf_trace: open access for CAP_SYS_PERFMON privileged process

2020-01-15 Thread Song Liu



> On Dec 18, 2019, at 1:28 AM, Alexey Budankov 
>  wrote:
> 
> 
> Open access to bpf_trace monitoring for CAP_SYS_PERFMON privileged
> processes. For backward compatibility reasons access to bpf_trace
> monitoring remains open for CAP_SYS_ADMIN privileged processes but
> CAP_SYS_ADMIN usage for secure bpf_trace monitoring is discouraged
> with respect to CAP_SYS_PERFMON capability.
> 
> Signed-off-by: Alexey Budankov 

Acked-by: Song Liu 

> ---
> kernel/trace/bpf_trace.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index 44bd08f2443b..bafe21ac6d92 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -1272,7 +1272,7 @@ int perf_event_query_prog_array(struct perf_event 
> *event, void __user *info)
>   u32 *ids, prog_cnt, ids_len;
>   int ret;
> 
> - if (!capable(CAP_SYS_ADMIN))
> + if (!perfmon_capable())
>   return -EPERM;
>   if (event->attr.type != PERF_TYPE_TRACEPOINT)
>   return -EINVAL;

I guess we need to fix this check for kprobe/uprobe created with 
perf_event_open()...

Thanks,
Song

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


Re: [Intel-gfx] [PATCH] drm/i915: convert to new logging macros based on struct intel_engine_cs.

2020-01-15 Thread Wambui Karuga




On Mon, 13 Jan 2020, Chris Wilson wrote:


Quoting Wambui Karuga (2020-01-13 11:10:25)

fn(...) {
...
struct intel_engine_cs *E = ...;
+struct drm_i915_private *dev_priv = E->i915;


No new dev_priv.

There should be no reason for drm_dbg here, as the rest of the debug is
behind ENGINE_TRACE and so the vestigial debug should be moved over, or
deleted as not being useful.

The error messages look unhelpful.
Hey Chris, could you please elaborate on the debugs that should be 
removed? These patches are for just converting the current debug 
instances, so removing them might need separate patches.


Thanks,
-wambui



if ((batch_end - cmd) < length) {
-   DRM_DEBUG("CMD: Command length exceeds batch length: 0x%08X 
length=%u batchlen=%td\n",
- *cmd,
- length,
- batch_end - cmd);
+   drm_dbg(_priv->drm,
+   "CMD: Command length exceeds batch length: 0x%08X 
length=%u batchlen=%td\n",


No. This is not driver debug. If anything this should be pr_debug, or
some over user centric channel.
-Chris


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


[Intel-gfx] [PATCH] drm/i915/audio: convert to using drm_dbg_kms()

2020-01-15 Thread Wambui Karuga
Convert from the drm_dbg() logging macro to the drm_dbg_kms() macro in
modesetting code.

Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/i915/display/intel_audio.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
b/drivers/gpu/drm/i915/display/intel_audio.c
index 57208440bf6d..771a677c905b 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -361,7 +361,7 @@ static void g4x_audio_codec_enable(struct intel_encoder 
*encoder,
I915_WRITE(G4X_AUD_CNTL_ST, tmp);
 
len = min(drm_eld_size(eld) / 4, len);
-   drm_dbg(_priv->drm, "ELD size %d\n", len);
+   drm_dbg_kms(_priv->drm, "ELD size %d\n", len);
for (i = 0; i < len; i++)
I915_WRITE(G4X_HDMIW_HDMIEDID, *((const u32 *)eld + i));
 
@@ -710,9 +710,10 @@ void intel_audio_codec_enable(struct intel_encoder 
*encoder,
"Bogus ELD on [CONNECTOR:%d:%s]\n",
connector->base.id, connector->name);
 
-   drm_dbg(_priv->drm, "ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
-   connector->base.id, connector->name,
-   connector->encoder->base.id, connector->encoder->name);
+   drm_dbg_kms(_priv->drm,
+   "ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
+   connector->base.id, connector->name,
+   connector->encoder->base.id, connector->encoder->name);
 
connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
 
-- 
2.24.1

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


[Intel-gfx] linux-next: manual merge of the generic-ioremap tree with the drm-misc tree

2020-01-15 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the generic-ioremap tree got a conflict in:

  drivers/video/fbdev/s1d13xxxfb.c

between commit:

  091be7245a03 ("fbdev: s1d13xxxfb: use resource_size")

from the drm-misc tree and commit:

  4bdc0d676a64 ("remove ioremap_nocache and devm_ioremap_nocache")

from the generic-ioremap tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/video/fbdev/s1d13xxxfb.c
index c23defa27036,8048499e398d..
--- a/drivers/video/fbdev/s1d13xxxfb.c
+++ b/drivers/video/fbdev/s1d13xxxfb.c
@@@ -809,8 -809,8 +809,8 @@@ static int s1d13xxxfb_probe(struct plat
  
platform_set_drvdata(pdev, info);
default_par = info->par;
-   default_par->regs = ioremap_nocache(pdev->resource[1].start,
-   resource_size(>resource[1]));
+   default_par->regs = ioremap(pdev->resource[1].start,
 -  pdev->resource[1].end - pdev->resource[1].start +1);
++  resource_size(>resource[1]));
if (!default_par->regs) {
printk(KERN_ERR PFX "unable to map registers\n");
ret = -ENOMEM;
@@@ -818,8 -818,9 +818,8 @@@
}
info->pseudo_palette = default_par->pseudo_palette;
  
-   info->screen_base = ioremap_nocache(pdev->resource[0].start,
-   resource_size(>resource[0]));
+   info->screen_base = ioremap(pdev->resource[0].start,
 -  pdev->resource[0].end - pdev->resource[0].start +1);
 -
++  resource_size(>resource[0]));
if (!info->screen_base) {
printk(KERN_ERR PFX "unable to map framebuffer\n");
ret = -ENOMEM;


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


[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915/hdcp: update HDCP CP property as per port authentication state (rev2)

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915/hdcp: update HDCP CP property as per port authentication state 
(rev2)
URL   : https://patchwork.freedesktop.org/series/71887/
State : warning

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 122 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:93: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1282: recipe for target 'modules' failed
make: *** [modules] Error 2

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16122/build_32bit.log
___
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/hdcp: update HDCP CP property as per port authentication state (rev2)

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915/hdcp: update HDCP CP property as per port authentication state 
(rev2)
URL   : https://patchwork.freedesktop.org/series/71887/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7753 -> Patchwork_16122


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload-with-fault-injection:
- fi-skl-6770hq:  [PASS][1] -> [DMESG-WARN][2] ([i915#889])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-skl-6770hq/igt@i915_module_l...@reload-with-fault-injection.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16122/fi-skl-6770hq/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_selftest@live_execlists:
- fi-icl-y:   [PASS][3] -> [INCOMPLETE][4] ([i915#140])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-icl-y/igt@i915_selftest@live_execlists.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16122/fi-icl-y/igt@i915_selftest@live_execlists.html

  * igt@i915_selftest@live_gem_contexts:
- fi-byt-j1900:   [PASS][5] -> [DMESG-FAIL][6] ([i915#722])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-byt-j1900/igt@i915_selftest@live_gem_contexts.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16122/fi-byt-j1900/igt@i915_selftest@live_gem_contexts.html

  * igt@kms_busy@basic-flip-pipe-a:
- fi-kbl-7500u:   [PASS][7] -> [SKIP][8] ([fdo#109271]) +3 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-kbl-7500u/igt@kms_b...@basic-flip-pipe-a.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16122/fi-kbl-7500u/igt@kms_b...@basic-flip-pipe-a.html

  * igt@kms_chamelium@dp-hpd-fast:
- fi-icl-u2:  [PASS][9] -> [DMESG-WARN][10] ([i915#289])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-icl-u2/igt@kms_chamel...@dp-hpd-fast.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16122/fi-icl-u2/igt@kms_chamel...@dp-hpd-fast.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [PASS][11] -> [FAIL][12] ([fdo#111096] / [i915#323])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16122/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  
 Possible fixes 

  * igt@gem_ctx_param@basic:
- {fi-ehl-1}: [INCOMPLETE][13] ([i915#937]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-ehl-1/igt@gem_ctx_pa...@basic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16122/fi-ehl-1/igt@gem_ctx_pa...@basic.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-skl-6700k2:  [DMESG-WARN][15] ([i915#889]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-skl-6700k2/igt@i915_module_l...@reload-with-fault-injection.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16122/fi-skl-6700k2/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6600u:   [DMESG-WARN][17] ([i915#889]) -> [PASS][18] +23 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-skl-6600u/igt@i915_pm_...@module-reload.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16122/fi-skl-6600u/igt@i915_pm_...@module-reload.html
- fi-skl-6770hq:  [FAIL][19] ([i915#178]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16122/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_gt_lrc:
- fi-skl-6600u:   [DMESG-FAIL][21] ([i915#889]) -> [PASS][22] +7 
similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-skl-6600u/igt@i915_selftest@live_gt_lrc.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16122/fi-skl-6600u/igt@i915_selftest@live_gt_lrc.html

  * igt@i915_selftest@live_hangcheck:
- fi-kbl-7500u:   [DMESG-FAIL][23] ([i915#889]) -> [PASS][24] +7 
similar issues
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-kbl-7500u/igt@i915_selftest@live_hangcheck.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16122/fi-kbl-7500u/igt@i915_selftest@live_hangcheck.html

  * igt@i915_selftest@live_vma:
- fi-kbl-7500u:   [DMESG-WARN][25] ([i915#889]) -> [PASS][26] +23 
similar issues
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-kbl-7500u/igt@i915_selftest@live_vma.html
   [26]: 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/psr: Share the computation of idle frames

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915/psr: Share the computation of idle frames
URL   : https://patchwork.freedesktop.org/series/71981/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7736_full -> Patchwork_16084_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@runner@aborted:
- shard-hsw:  NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16084/shard-hsw7/igt@run...@aborted.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_busy@extended-parallel-vcs1:
- shard-iclb: [PASS][2] -> [SKIP][3] ([fdo#112080]) +12 similar 
issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7736/shard-iclb4/igt@gem_b...@extended-parallel-vcs1.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16084/shard-iclb3/igt@gem_b...@extended-parallel-vcs1.html

  * igt@gem_ctx_isolation@bcs0-s3:
- shard-apl:  [PASS][4] -> [DMESG-WARN][5] ([i915#180])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7736/shard-apl1/igt@gem_ctx_isolat...@bcs0-s3.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16084/shard-apl4/igt@gem_ctx_isolat...@bcs0-s3.html

  * igt@gem_ctx_persistence@vcs0-mixed-process:
- shard-apl:  [PASS][6] -> [FAIL][7] ([i915#679])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7736/shard-apl1/igt@gem_ctx_persiste...@vcs0-mixed-process.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16084/shard-apl4/igt@gem_ctx_persiste...@vcs0-mixed-process.html

  * igt@gem_ctx_persistence@vcs1-queued:
- shard-iclb: [PASS][8] -> [SKIP][9] ([fdo#109276] / [fdo#112080]) 
+1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7736/shard-iclb1/igt@gem_ctx_persiste...@vcs1-queued.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16084/shard-iclb3/igt@gem_ctx_persiste...@vcs1-queued.html

  * igt@gem_ctx_shared@q-smoketest-bsd1:
- shard-tglb: [PASS][10] -> [INCOMPLETE][11] ([fdo#111735])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7736/shard-tglb8/igt@gem_ctx_sha...@q-smoketest-bsd1.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16084/shard-tglb4/igt@gem_ctx_sha...@q-smoketest-bsd1.html

  * igt@gem_exec_parallel@vcs0:
- shard-tglb: [PASS][12] -> [INCOMPLETE][13] ([fdo#111593] / 
[i915#472]) +1 similar issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7736/shard-tglb2/igt@gem_exec_paral...@vcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16084/shard-tglb8/igt@gem_exec_paral...@vcs0.html

  * igt@gem_exec_schedule@in-order-bsd:
- shard-iclb: [PASS][14] -> [SKIP][15] ([fdo#112146]) +2 similar 
issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7736/shard-iclb6/igt@gem_exec_sched...@in-order-bsd.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16084/shard-iclb1/igt@gem_exec_sched...@in-order-bsd.html

  * igt@gem_exec_schedule@independent-bsd2:
- shard-iclb: [PASS][16] -> [SKIP][17] ([fdo#109276]) +18 similar 
issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7736/shard-iclb1/igt@gem_exec_sched...@independent-bsd2.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16084/shard-iclb3/igt@gem_exec_sched...@independent-bsd2.html

  * igt@gem_exec_schedule@pi-distinct-iova-bsd:
- shard-iclb: [PASS][18] -> [SKIP][19] ([i915#677])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7736/shard-iclb6/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16084/shard-iclb2/igt@gem_exec_sched...@pi-distinct-iova-bsd.html

  * igt@gem_exec_schedule@preempt-queue-contexts-bsd1:
- shard-tglb: [PASS][20] -> [INCOMPLETE][21] ([fdo#111606] / 
[fdo#111677] / [i915#472])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7736/shard-tglb5/igt@gem_exec_sched...@preempt-queue-contexts-bsd1.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16084/shard-tglb6/igt@gem_exec_sched...@preempt-queue-contexts-bsd1.html

  * igt@gem_exec_suspend@basic-s4-devices:
- shard-tglb: [PASS][22] -> [INCOMPLETE][23] ([i915#460] / 
[i915#472])
   [22]: 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Always reset the timeslice after a context switch

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: Always reset the timeslice after a context switch
URL   : https://patchwork.freedesktop.org/series/71980/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7736_full -> Patchwork_16083_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@gem_persistent_relocs@forked-interruptible-faulting-reloc:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7736/shard-tglb1/igt@gem_persistent_rel...@forked-interruptible-faulting-reloc.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16083/shard-tglb6/igt@gem_persistent_rel...@forked-interruptible-faulting-reloc.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_busy@extended-parallel-vcs1:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +9 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7736/shard-iclb4/igt@gem_b...@extended-parallel-vcs1.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16083/shard-iclb8/igt@gem_b...@extended-parallel-vcs1.html

  * igt@gem_ctx_isolation@bcs0-s3:
- shard-apl:  [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +1 similar 
issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7736/shard-apl1/igt@gem_ctx_isolat...@bcs0-s3.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16083/shard-apl6/igt@gem_ctx_isolat...@bcs0-s3.html

  * igt@gem_ctx_persistence@vcs1-hostile-preempt:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276] / [fdo#112080]) 
+1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7736/shard-iclb1/igt@gem_ctx_persiste...@vcs1-hostile-preempt.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16083/shard-iclb8/igt@gem_ctx_persiste...@vcs1-hostile-preempt.html

  * igt@gem_exec_await@wide-contexts:
- shard-tglb: [PASS][9] -> [INCOMPLETE][10] ([fdo#111736] / 
[i915#472])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7736/shard-tglb3/igt@gem_exec_aw...@wide-contexts.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16083/shard-tglb3/igt@gem_exec_aw...@wide-contexts.html

  * igt@gem_exec_parallel@fds:
- shard-hsw:  [PASS][11] -> [INCOMPLETE][12] ([i915#61])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7736/shard-hsw5/igt@gem_exec_paral...@fds.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16083/shard-hsw5/igt@gem_exec_paral...@fds.html

  * igt@gem_exec_schedule@in-order-bsd:
- shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#112146]) +3 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7736/shard-iclb6/igt@gem_exec_sched...@in-order-bsd.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16083/shard-iclb1/igt@gem_exec_sched...@in-order-bsd.html

  * igt@gem_exec_schedule@independent-bsd2:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109276]) +18 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7736/shard-iclb1/igt@gem_exec_sched...@independent-bsd2.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16083/shard-iclb8/igt@gem_exec_sched...@independent-bsd2.html

  * igt@gem_exec_schedule@pi-common-bsd:
- shard-iclb: [PASS][17] -> [SKIP][18] ([i915#677])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7736/shard-iclb8/igt@gem_exec_sched...@pi-common-bsd.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16083/shard-iclb1/igt@gem_exec_sched...@pi-common-bsd.html

  * igt@gem_exec_schedule@preempt-queue-chain-render:
- shard-tglb: [PASS][19] -> [INCOMPLETE][20] ([fdo#111606] / 
[fdo#111677] / [i915#472])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7736/shard-tglb4/igt@gem_exec_sched...@preempt-queue-chain-render.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16083/shard-tglb8/igt@gem_exec_sched...@preempt-queue-chain-render.html

  * igt@gem_persistent_relocs@forked-interruptible-thrashing:
- shard-snb:  [PASS][21] -> [FAIL][22] ([i915#520])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7736/shard-snb1/igt@gem_persistent_rel...@forked-interruptible-thrashing.html
   [22]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl: Program MBUS_ABOX{1, 2}_CTL during display init

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915/tgl: Program MBUS_ABOX{1, 2}_CTL during display init
URL   : https://patchwork.freedesktop.org/series/72091/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7753 -> Patchwork_16121


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload-with-fault-injection:
- fi-skl-lmem:[PASS][1] -> [DMESG-WARN][2] ([i915#889])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-skl-lmem/igt@i915_module_l...@reload-with-fault-injection.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16121/fi-skl-lmem/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_selftest@live_blt:
- fi-hsw-4770r:   [PASS][3] -> [DMESG-FAIL][4] ([i915#725])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-hsw-4770r/igt@i915_selftest@live_blt.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16121/fi-hsw-4770r/igt@i915_selftest@live_blt.html

  * igt@i915_selftest@live_execlists:
- fi-kbl-soraka:  [PASS][5] -> [DMESG-FAIL][6] ([i915#656])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-kbl-soraka/igt@i915_selftest@live_execlists.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16121/fi-kbl-soraka/igt@i915_selftest@live_execlists.html

  * igt@kms_busy@basic-flip-pipe-a:
- fi-kbl-7500u:   [PASS][7] -> [SKIP][8] ([fdo#109271]) +3 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-kbl-7500u/igt@kms_b...@basic-flip-pipe-a.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16121/fi-kbl-7500u/igt@kms_b...@basic-flip-pipe-a.html

  * igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6770hq:  [PASS][9] -> [SKIP][10] ([fdo#109271]) +27 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16121/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html

  
 Possible fixes 

  * igt@i915_module_load@reload-with-fault-injection:
- fi-skl-6700k2:  [DMESG-WARN][11] ([i915#889]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-skl-6700k2/igt@i915_module_l...@reload-with-fault-injection.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16121/fi-skl-6700k2/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [FAIL][13] ([i915#178]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16121/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_blt:
- fi-hsw-4770:[DMESG-FAIL][15] ([i915#725]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-hsw-4770/igt@i915_selftest@live_blt.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16121/fi-hsw-4770/igt@i915_selftest@live_blt.html

  * igt@i915_selftest@live_hangcheck:
- fi-kbl-7500u:   [DMESG-FAIL][17] ([i915#889]) -> [PASS][18] +7 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-kbl-7500u/igt@i915_selftest@live_hangcheck.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16121/fi-kbl-7500u/igt@i915_selftest@live_hangcheck.html

  * igt@i915_selftest@live_vma:
- fi-kbl-7500u:   [DMESG-WARN][19] ([i915#889]) -> [PASS][20] +23 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7753/fi-kbl-7500u/igt@i915_selftest@live_vma.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16121/fi-kbl-7500u/igt@i915_selftest@live_vma.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#178]: https://gitlab.freedesktop.org/drm/intel/issues/178
  [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656
  [i915#725]: https://gitlab.freedesktop.org/drm/intel/issues/725
  [i915#889]: https://gitlab.freedesktop.org/drm/intel/issues/889


Participating hosts (51 -> 36)
--

  Additional (1): fi-tgl-y 
  Missing(16): fi-ilk-m540 fi-ehl-1 fi-bdw-5557u fi-bsw-n3050 fi-byt-j1900 
fi-hsw-4200u fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-snb-2520m fi-gdg-551 
fi-ivb-3770 fi-byt-n2820 fi-byt-clapper fi-bsw-nick fi-skl-6600u 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7753 -> Patchwork_16121

  CI-20190529: 20190529
  CI_DRM_7753: cef3a815e760485d4c011adb3dafb4d49bff9378 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5367: 

[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915/tgl: Program MBUS_ABOX{1, 2}_CTL during display init

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915/tgl: Program MBUS_ABOX{1, 2}_CTL during display init
URL   : https://patchwork.freedesktop.org/series/72091/
State : warning

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 122 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:93: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1282: recipe for target 'modules' failed
make: *** [modules] Error 2

== Logs ==

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


[Intel-gfx] [PATCH] drm/i915/tgl: Program MBUS_ABOX{1, 2}_CTL during display init

2020-01-15 Thread Matt Roper
On gen11 we only needed to program MBus credits into MBUS_ABOX_CTL
during display initialization, but on gen12 we're now supposed to
program the same values into MBUS_ABOX1_CTL and MBUS_ABOX2_CTL as well.

Bspec: 49213
Bspec: 50096
Cc: Stanislav Lisovskiy 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/display/intel_display_power.c | 4 
 drivers/gpu/drm/i915/i915_reg.h| 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 21561acfa3ac..761be9fcaf10 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -4474,6 +4474,10 @@ static void icl_mbus_init(struct drm_i915_private 
*dev_priv)
  MBUS_ABOX_BW_CREDIT(1);
 
I915_WRITE(MBUS_ABOX_CTL, val);
+   if (INTEL_GEN(dev_priv) >= 12) {
+   I915_WRITE(MBUS_ABOX1_CTL, val);
+   I915_WRITE(MBUS_ABOX2_CTL, val);
+   }
 }
 
 static void hsw_assert_cdclk(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5e5949edf2a8..ef191a0278ac 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2860,6 +2860,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define MI_ARB_STATE   _MMIO(0x20e4) /* 915+ only */
 
 #define MBUS_ABOX_CTL  _MMIO(0x45038)
+#define MBUS_ABOX1_CTL _MMIO(0x45048)
+#define MBUS_ABOX2_CTL _MMIO(0x4504C)
 #define MBUS_ABOX_BW_CREDIT_MASK   (3 << 20)
 #define MBUS_ABOX_BW_CREDIT(x) ((x) << 20)
 #define MBUS_ABOX_B_CREDIT_MASK(0xF << 16)
-- 
2.23.0

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


Re: [Intel-gfx] [PATCH v12 0/5] Enable second DBuf slice for ICL and TGL

2020-01-15 Thread Matt Roper
On Wed, Jan 15, 2020 at 11:45:51PM +0200, Stanislav Lisovskiy wrote:
> Those patch series, do some initial preparation DBuf manipulating code
> cleanups, i.e remove redundant structures/code, switch to mask
> based DBuf manupulation, get into use DBuf assignment according to
> BSpec rules.

I just noticed that bspec page 49213 indicates we should also be writing
a value of '8' to bits 23:19 on gen12.  We don't seem to handling that
yet.  We may need to add that change as an additional patch.


Matt

> 
> Stanislav Lisovskiy (5):
>   drm/i915: Remove skl_ddl_allocation struct
>   drm/i915: Move dbuf slice update to proper place
>   drm/i915: Manipulate DBuf slices properly
>   drm/i915: Introduce parameterized DBUF_CTL
>   drm/i915: Correctly map DBUF slices to pipes
> 
>  drivers/gpu/drm/i915/display/intel_display.c  |  52 +-
>  .../drm/i915/display/intel_display_power.c|  88 ++--
>  .../drm/i915/display/intel_display_power.h|   6 +
>  .../drm/i915/display/intel_display_types.h|   3 +
>  drivers/gpu/drm/i915/i915_drv.h   |   7 +-
>  drivers/gpu/drm/i915/i915_pci.c   |   5 +-
>  drivers/gpu/drm/i915/i915_reg.h   |  12 +-
>  drivers/gpu/drm/i915/intel_device_info.h  |   1 +
>  drivers/gpu/drm/i915/intel_pm.c   | 457 +++---
>  drivers/gpu/drm/i915/intel_pm.h   |   7 +-
>  10 files changed, 496 insertions(+), 142 deletions(-)
> 
> -- 
> 2.24.1.485.gad05a3d8e5
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 4/5] drm/i915: Use PIPE_CONF_CHECK_X() for sync_mode_slaves_mask

2020-01-15 Thread Manasi Navare
On Wed, Jan 15, 2020 at 09:08:12PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> sync_mode_slaves_mask is a bitmask so use PIPE_CONF_CHECK_X() for it
> so we get the mismatch printed in hex instead of decimal.
> 
> Signed-off-by: Ville Syrjälä 

Yes makes sense also tested this on the 8K tiled display,

Reviewed-by: Manasi Navare 
Tested-by: Manasi Navare 

Manasi

> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 64a377d61ce0..97cf8457c956 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -13695,7 +13695,7 @@ intel_pipe_config_compare(const struct 
> intel_crtc_state *current_config,
>   PIPE_CONF_CHECK_INFOFRAME(hdmi);
>   PIPE_CONF_CHECK_INFOFRAME(drm);
>  
> - PIPE_CONF_CHECK_I(sync_mode_slaves_mask);
> + PIPE_CONF_CHECK_X(sync_mode_slaves_mask);
>   PIPE_CONF_CHECK_I(master_transcoder);
>  
>   PIPE_CONF_CHECK_I(dsc.compression_enable);
> -- 
> 2.24.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
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: add Wa_14010594013: icl,ehl (rev2)

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915: add Wa_14010594013: icl,ehl (rev2)
URL   : https://patchwork.freedesktop.org/series/71858/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7735_full -> Patchwork_16082_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_busy@busy-vcs1:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +13 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb2/igt@gem_b...@busy-vcs1.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16082/shard-iclb6/igt@gem_b...@busy-vcs1.html

  * igt@gem_ctx_isolation@rcs0-s3:
- shard-kbl:  [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +5 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-kbl2/igt@gem_ctx_isolat...@rcs0-s3.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16082/shard-kbl7/igt@gem_ctx_isolat...@rcs0-s3.html

  * igt@gem_ctx_persistence@bcs0-mixed-process:
- shard-iclb: [PASS][5] -> [FAIL][6] ([i915#679])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb2/igt@gem_ctx_persiste...@bcs0-mixed-process.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16082/shard-iclb1/igt@gem_ctx_persiste...@bcs0-mixed-process.html

  * igt@gem_ctx_persistence@vcs1-queued:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276] / [fdo#112080]) 
+3 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb2/igt@gem_ctx_persiste...@vcs1-queued.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16082/shard-iclb6/igt@gem_ctx_persiste...@vcs1-queued.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][9] -> [INCOMPLETE][10] ([i915#469])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-tglb4/igt@gem_...@unwedge-stress.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16082/shard-tglb3/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_reloc@basic-active-bsd2:
- shard-tglb: [PASS][11] -> [INCOMPLETE][12] ([i915#472]) +1 
similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-tglb1/igt@gem_exec_re...@basic-active-bsd2.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16082/shard-tglb2/igt@gem_exec_re...@basic-active-bsd2.html

  * igt@gem_exec_schedule@independent-bsd2:
- shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109276]) +21 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb4/igt@gem_exec_sched...@independent-bsd2.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16082/shard-iclb8/igt@gem_exec_sched...@independent-bsd2.html

  * igt@gem_exec_schedule@pi-distinct-iova-bsd:
- shard-iclb: [PASS][15] -> [SKIP][16] ([i915#677]) +2 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb8/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16082/shard-iclb2/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
- shard-skl:  [PASS][17] -> [DMESG-WARN][18] ([i915#836])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-skl2/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16082/shard-skl2/igt@gem_exec_sched...@pi-distinct-iova-bsd.html

  * igt@gem_exec_schedule@reorder-wide-bsd:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#112146]) +3 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb3/igt@gem_exec_sched...@reorder-wide-bsd.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16082/shard-iclb4/igt@gem_exec_sched...@reorder-wide-bsd.html

  * igt@gem_exec_suspend@basic-s3:
- shard-tglb: [PASS][21] -> [INCOMPLETE][22] ([fdo#111736] / 
[i915#460] / [i915#472])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-tglb4/igt@gem_exec_susp...@basic-s3.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16082/shard-tglb3/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_persistent_relocs@forked-faulting-reloc-thrashing:
- shard-iclb: [PASS][23] -> [TIMEOUT][24] ([fdo#112271] / 
[i915#530])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb5/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16082/shard-iclb3/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html

  * igt@gem_persistent_relocs@forked-interruptible-thrashing:
- shard-iclb: [PASS][25] -> [FAIL][26] ([i915#520])
   [25]: 

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Move encoder variable to tighter scope

2020-01-15 Thread Souza, Jose
On Wed, 2020-01-15 at 21:08 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Let's not pollute the function scope with variables when they're
> only needed inside some loops.

Reviewed-by: José Roberto de Souza 

> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 97cf8457c956..76c17341df2b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -13070,7 +13070,6 @@ intel_modeset_pipe_config(struct
> intel_crtc_state *pipe_config)
>  {
>   struct drm_crtc *crtc = pipe_config->uapi.crtc;
>   struct drm_atomic_state *state = pipe_config->uapi.state;
> - struct intel_encoder *encoder;
>   struct drm_connector *connector;
>   struct drm_connector_state *connector_state;
>   int base_bpp, ret;
> @@ -13113,11 +13112,12 @@ intel_modeset_pipe_config(struct
> intel_crtc_state *pipe_config)
>  _config->pipe_src_h);
>  
>   for_each_new_connector_in_state(state, connector,
> connector_state, i) {
> + struct intel_encoder *encoder =
> + to_intel_encoder(connector_state-
> >best_encoder);
> +
>   if (connector_state->crtc != crtc)
>   continue;
>  
> - encoder = to_intel_encoder(connector_state-
> >best_encoder);
> -
>   if (!check_single_encoder_cloning(state,
> to_intel_crtc(crtc), encoder)) {
>   DRM_DEBUG_KMS("rejecting invalid cloning
> configuration\n");
>   return -EINVAL;
> @@ -13167,6 +13167,9 @@ intel_modeset_pipe_config(struct
> intel_crtc_state *pipe_config)
>* a chance to reject the mode entirely.
>*/
>   for_each_new_connector_in_state(state, connector,
> connector_state, i) {
> + struct intel_encoder *encoder =
> + to_intel_encoder(connector_state-
> >best_encoder);
> +
>   if (connector_state->crtc != crtc)
>   continue;
>  
> @@ -13178,7 +13181,6 @@ intel_modeset_pipe_config(struct
> intel_crtc_state *pipe_config)
>   return ret;
>   }
>  
> - encoder = to_intel_encoder(connector_state-
> >best_encoder);
>   ret = encoder->compute_config(encoder, pipe_config,
> connector_state);
>   if (ret < 0) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 4/5] drm/i915: Use PIPE_CONF_CHECK_X() for sync_mode_slaves_mask

2020-01-15 Thread Souza, Jose
On Wed, 2020-01-15 at 21:08 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> sync_mode_slaves_mask is a bitmask so use PIPE_CONF_CHECK_X() for it
> so we get the mismatch printed in hex instead of decimal.
> 

Reviewed-by: José Roberto de Souza 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 64a377d61ce0..97cf8457c956 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -13695,7 +13695,7 @@ intel_pipe_config_compare(const struct
> intel_crtc_state *current_config,
>   PIPE_CONF_CHECK_INFOFRAME(hdmi);
>   PIPE_CONF_CHECK_INFOFRAME(drm);
>  
> - PIPE_CONF_CHECK_I(sync_mode_slaves_mask);
> + PIPE_CONF_CHECK_X(sync_mode_slaves_mask);
>   PIPE_CONF_CHECK_I(master_transcoder);
>  
>   PIPE_CONF_CHECK_I(dsc.compression_enable);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 3/5] drm/i915: Prefer to use the pipe to index the ddb entries

2020-01-15 Thread Souza, Jose
On Wed, 2020-01-15 at 21:08 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Let's use the pipe rather than the silly 'i' iterator from
> for_each_oldnew_intel_crtc_in_state() for indexing the ddb
> entries array. Maybe one day we can assume c99 and hide the
> 'i' entirely from sight.
> 

Reviewed-by: José Roberto de Souza 


> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 20 +++---
> --
>  1 file changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index e68af024e13c..64a377d61ce0 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15106,15 +15106,17 @@ static void
> skl_commit_modeset_enables(struct intel_atomic_state *state)
>   int i;
>  
>   for_each_oldnew_intel_crtc_in_state(state, crtc,
> old_crtc_state, new_crtc_state, i) {
> + enum pipe pipe = crtc->pipe;
> +
>   if (!new_crtc_state->hw.active)
>   continue;
>  
>   /* ignore allocations for crtc's that have been turned
> off. */
>   if (!needs_modeset(new_crtc_state)) {
> - entries[i] = old_crtc_state->wm.skl.ddb;
> - update_pipes |= BIT(crtc->pipe);
> + entries[pipe] = old_crtc_state->wm.skl.ddb;
> + update_pipes |= BIT(pipe);
>   } else {
> - modeset_pipes |= BIT(crtc->pipe);
> + modeset_pipes |= BIT(pipe);
>   }
>   }
>  
> @@ -15140,10 +15142,10 @@ static void
> skl_commit_modeset_enables(struct intel_atomic_state *state)
>   continue;
>  
>   if
> (skl_ddb_allocation_overlaps(_crtc_state->wm.skl.ddb,
> - entries,
> num_pipes, i))
> + entries,
> num_pipes, pipe))
>   continue;
>  
> - entries[i] = new_crtc_state->wm.skl.ddb;
> + entries[pipe] = new_crtc_state->wm.skl.ddb;
>   update_pipes &= ~BIT(pipe);
>  
>   intel_update_crtc(crtc, state, old_crtc_state,
> @@ -15178,9 +15180,9 @@ static void skl_commit_modeset_enables(struct
> intel_atomic_state *state)
>   continue;
>  
>   WARN_ON(skl_ddb_allocation_overlaps(_crtc_state-
> >wm.skl.ddb,
> - entries, num_pipes,
> i));
> + entries, num_pipes,
> pipe));
>  
> - entries[i] = new_crtc_state->wm.skl.ddb;
> + entries[pipe] = new_crtc_state->wm.skl.ddb;
>   modeset_pipes &= ~BIT(pipe);
>  
>   if (is_trans_port_sync_mode(new_crtc_state)) {
> @@ -15213,9 +15215,9 @@ static void skl_commit_modeset_enables(struct
> intel_atomic_state *state)
>   continue;
>  
>   WARN_ON(skl_ddb_allocation_overlaps(_crtc_state-
> >wm.skl.ddb,
> - entries, num_pipes,
> i));
> + entries, num_pipes,
> pipe));
>  
> - entries[i] = new_crtc_state->wm.skl.ddb;
> + entries[pipe] = new_crtc_state->wm.skl.ddb;
>   modeset_pipes &= ~BIT(pipe);
>  
>   intel_update_crtc(crtc, state, old_crtc_state,
> new_crtc_state);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 2/5] drm/i915: Clear most of crtc state when disabling the crtc

2020-01-15 Thread Souza, Jose
On Wed, 2020-01-15 at 21:08 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Currently we don't call intel_crtc_prepare_cleared_state() for crtcs
> that are going to be entirely disabled (uapi.enable==false). That
> means such crtcs will leave state junk lying around in their states
> and we have to sprinkle hw.enable checks all over before we can
> look at the states. Let's change that a bit so that we aways do
> the state clearing, even for fully disabled crtcs.
> 
> Note that we still keep some parts of the old state (see
> intel_crtc_prepare_cleared_state() for the details) so probably
> can't trust things 100% when hw.enable==false. But at least there's
> less chance now that we end up looking at stale junk.
> 

Reviewed-by: José Roberto de Souza 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index b397816ce253..e68af024e13c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14607,15 +14607,13 @@ static int intel_atomic_check(struct
> drm_device *dev,
>   continue;
>   }
>  
> - if (!new_crtc_state->uapi.enable) {
> - intel_crtc_copy_uapi_to_hw_state(new_crtc_state
> );
> - continue;
> - }
> -
>   ret = intel_crtc_prepare_cleared_state(new_crtc_state);
>   if (ret)
>   goto fail;
>  
> + if (!new_crtc_state->hw.enable)
> + continue;
> +
>   ret = intel_modeset_pipe_config(new_crtc_state);
>   if (ret)
>   goto fail;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 1/5] drm/i915: Fix post-fastset modeset check for port sync

2020-01-15 Thread Souza, Jose
On Wed, 2020-01-15 at 21:08 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> The post-fastset "does anyone still need a full modeset?" for
> port sync looks busted. The outer loop bails out of a full modeset
> is still needed by the current crtc which, and then we skip forcing
> a full modeset on the related crtcs. That's totally the opposite
> of what we want.

Ops yeah, it is always doing a full modeset.

> 
> The MST path has the logic mostly the other way around so it
> looks correct. To fix the port sync case let's follow the MST
> logic for both. So, if the current crtc already needs a modeset
> we do nothing. otherwise we check if any of the related crtcs
> needs a modeset, and if so we force a full modeset for the
> current crtc.
> 
> And while at let's change the else if to a plain if to so
> we don't have needless coupling between the MST and port sync
> checks.
> 
> Cc: José Roberto de Souza 
> Cc: Manasi Navare 
> Fixes: 05a8e45136ca ("drm/i915/display: Use external dependency loop
> for port sync")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 43 
> 
>  1 file changed, 17 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index dd03987cc24f..b397816ce253 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14469,37 +14469,23 @@ static int intel_atomic_check_crtcs(struct
> intel_atomic_state *state)
>   return 0;
>  }
>  
> -static bool intel_cpu_transcoder_needs_modeset(struct
> intel_atomic_state *state,
> -enum transcoder
> transcoder)
> +static bool intel_cpu_transcoders_need_modeset(struct
> intel_atomic_state *state,
> +u8 transcoders)
>  {
> - struct intel_crtc_state *new_crtc_state;
> + const struct intel_crtc_state *new_crtc_state;
>   struct intel_crtc *crtc;
>   int i;
>  
> - for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state,
> i)
> - if (new_crtc_state->cpu_transcoder == transcoder)
> - return needs_modeset(new_crtc_state);
> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state,
> i) {
> + if (new_crtc_state->hw.enable &&

The intel_pipe_config_compare() will force a modeset for MST and port
sync but this hw.enable could skip modeset in future features when one
of the pipes are going from enabled to disabled.

Removing it:

Reviewed-by: José Roberto de Souza 

> + transcoders & BIT(new_crtc_state->cpu_transcoder)
> &&
> + needs_modeset(new_crtc_state))
> + return true;
> + }
>  
>   return false;
>  }
>  
> -static void
> -intel_modeset_synced_crtcs(struct intel_atomic_state *state,
> -u8 transcoders)
> -{
> - struct intel_crtc_state *new_crtc_state;
> - struct intel_crtc *crtc;
> - int i;
> -
> - for_each_new_intel_crtc_in_state(state, crtc,
> -  new_crtc_state, i) {
> - if (transcoders & BIT(new_crtc_state->cpu_transcoder))
> {
> - new_crtc_state->uapi.mode_changed = true;
> - new_crtc_state->update_pipe = false;
> - }
> - }
> -}
> -
>  static int
>  intel_modeset_all_tiles(struct intel_atomic_state *state, int
> tile_grp_id)
>  {
> @@ -14655,15 +14641,20 @@ static int intel_atomic_check(struct
> drm_device *dev,
>   if (intel_dp_mst_is_slave_trans(new_crtc_state)) {
>   enum transcoder master = new_crtc_state-
> >mst_master_transcoder;
>  
> - if (intel_cpu_transcoder_needs_modeset(state,
> master)) {
> + if (intel_cpu_transcoders_need_modeset(state,
> BIT(master))) {
>   new_crtc_state->uapi.mode_changed =
> true;
>   new_crtc_state->update_pipe = false;
>   }
> - } else if (is_trans_port_sync_mode(new_crtc_state)) {
> + }
> +
> + if (is_trans_port_sync_mode(new_crtc_state)) {
>   u8 trans = new_crtc_state-
> >sync_mode_slaves_mask |
>  BIT(new_crtc_state-
> >master_transcoder);
>  
> - intel_modeset_synced_crtcs(state, trans);
> + if (intel_cpu_transcoders_need_modeset(state,
> trans)) {
> + new_crtc_state->uapi.mode_changed =
> true;
> + new_crtc_state->update_pipe = false;
> + }
>   }
>   }
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BUILD: warning for Enable second DBuf slice for ICL and TGL (rev15)

2020-01-15 Thread Patchwork
== Series Details ==

Series: Enable second DBuf slice for ICL and TGL (rev15)
URL   : https://patchwork.freedesktop.org/series/70059/
State : warning

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 122 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:93: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1282: recipe for target 'modules' failed
make: *** [modules] Error 2

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable second DBuf slice for ICL and TGL (rev15)

2020-01-15 Thread Patchwork
== Series Details ==

Series: Enable second DBuf slice for ICL and TGL (rev15)
URL   : https://patchwork.freedesktop.org/series/70059/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7752 -> Patchwork_16120


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-icl-guc: [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7752/fi-icl-guc/igt@i915_pm_...@basic-pci-d3-state.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16120/fi-icl-guc/igt@i915_pm_...@basic-pci-d3-state.html
- fi-icl-u2:  [PASS][3] -> [DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7752/fi-icl-u2/igt@i915_pm_...@basic-pci-d3-state.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16120/fi-icl-u2/igt@i915_pm_...@basic-pci-d3-state.html
- fi-icl-u3:  [PASS][5] -> [DMESG-WARN][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7752/fi-icl-u3/igt@i915_pm_...@basic-pci-d3-state.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16120/fi-icl-u3/igt@i915_pm_...@basic-pci-d3-state.html
- fi-icl-y:   [PASS][7] -> [DMESG-WARN][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7752/fi-icl-y/igt@i915_pm_...@basic-pci-d3-state.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16120/fi-icl-y/igt@i915_pm_...@basic-pci-d3-state.html
- fi-tgl-y:   [PASS][9] -> [DMESG-WARN][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7752/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16120/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
- fi-icl-dsi: [PASS][11] -> [DMESG-WARN][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7752/fi-icl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16120/fi-icl-dsi/igt@i915_pm_...@basic-pci-d3-state.html

  
 Suppressed 

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

  * igt@i915_pm_rpm@basic-pci-d3-state:
- {fi-tgl-u}: [PASS][13] -> [DMESG-WARN][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7752/fi-tgl-u/igt@i915_pm_...@basic-pci-d3-state.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16120/fi-tgl-u/igt@i915_pm_...@basic-pci-d3-state.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [PASS][15] -> [FAIL][16] ([i915#579])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7752/fi-kbl-guc/igt@i915_pm_...@module-reload.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16120/fi-kbl-guc/igt@i915_pm_...@module-reload.html

  
 Possible fixes 

  * igt@i915_selftest@live_blt:
- fi-ivb-3770:[DMESG-FAIL][17] ([i915#770]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7752/fi-ivb-3770/igt@i915_selftest@live_blt.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16120/fi-ivb-3770/igt@i915_selftest@live_blt.html

  * igt@i915_selftest@live_gt_lrc:
- fi-skl-6600u:   [DMESG-FAIL][19] ([i915#889]) -> [PASS][20] +7 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7752/fi-skl-6600u/igt@i915_selftest@live_gt_lrc.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16120/fi-skl-6600u/igt@i915_selftest@live_gt_lrc.html

  * igt@i915_selftest@live_late_gt_pm:
- fi-skl-6600u:   [DMESG-WARN][21] ([i915#889]) -> [PASS][22] +23 
similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7752/fi-skl-6600u/igt@i915_selftest@live_late_gt_pm.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16120/fi-skl-6600u/igt@i915_selftest@live_late_gt_pm.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [FAIL][23] ([fdo#111096] / [i915#323]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7752/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16120/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  

Re: [Intel-gfx] [PATCH v2 5/5] drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen 4K AMOLED panel

2020-01-15 Thread Lyude Paul
sigh… so I just went through the correspondence with the vendor I mentioned
and unfortunately the answer is still unclear. It looks like that for some of
these panels there might actually be some bits in the EDID (!?!?) that are
supposed to correspond to the backlight interface. weird. on top of that I'm
not even sure if these EDID bits are actually standard. Interestingly enough
it seems like they're also intending for some of their panels to be able to be
used in both PWM and DPCD mode, and will eventually drop the PWM
compatibility.

Note this vendor isn't Lenovo, so I'm assuming that's probably why pwm mode
doesn't work at all on this X1 extreme.

That being said all I've seen are systems that don't specify this correctly in
the vbt but do in the dpcd, so I'm going to go ahead and change this patch
series over to using the dpcd by default instead. If this actually breaks any
systems out there we can change the default behavior later. I will do a respin
of the series asap (will have it on the list today or tommorrow, will merge
after CI gives the OK).

On Wed, 2020-01-15 at 10:32 +0200, Jani Nikula wrote:
> On Tue, 14 Jan 2020, Lyude Paul  wrote:
> > fwiw - I got some feedback from one of the vendors that we work with that
> > I
> > haven't gone through yet, but I'm hoping to figure out whether we want to
> > trust the vbt/dpcd based off that once I do. Once we've made up the
> > decision
> > on that (and I send out a reroll if needed), think this is good to merge?
> > (I
> > don't see any issues with any of the changes you've made, and they seem to
> > work fine on my machines)
> 
> Thanks, yes, my idea was that I'd merge this after CI says good to
> go. But do let me know if you get more information.
> 
> BR,
> Jani.
> 
> 
> > On Tue, 2020-01-14 at 16:01 +0200, Jani Nikula wrote:
> > > From: Lyude Paul 
> > > 
> > > Annoyingly, the VBT on the ThinkPad X1 Extreme 2nd Gen indicates that
> > > the system uses plain PWM based backlight controls, when in reality the
> > > only backlight controls that work are the standard VESA eDP DPCD
> > > backlight controls.
> > > 
> > > Honestly, this makes me wonder how many other systems have these issues
> > > or lie about this in their VBT. Not sure we have any good way of finding
> > > out until panels like this become more common place in the laptop
> > > market. For now, just add a DRM DP quirk to indicate that this panel is
> > > telling the truth and is being a good LCD.
> > > 
> > > v2 by Jani:
> > > - rebase
> > > 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112376
> > > Closes: https://gitlab.freedesktop.org/drm/intel/issues/642
> > > Tested-by: AceLan Kao 
> > > Signed-off-by: Lyude Paul 
> > > Signed-off-by: Jani Nikula 
> > > ---
> > >  drivers/gpu/drm/drm_dp_helper.c   | 4 
> > >  drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 8 ++--
> > >  include/drm/drm_dp_helper.h   | 8 
> > >  3 files changed, 18 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > > b/drivers/gpu/drm/drm_dp_helper.c
> > > index 5a103e9b3c86..90e122809fa4 100644
> > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > @@ -1179,6 +1179,10 @@ static const struct dpcd_quirk dpcd_quirk_list[]
> > > = {
> > >   { OUI(0x00, 0x00, 0x00), DEVICE_ID('C', 'H', '7', '5', '1', '1'),
> > > false, BIT(DP_DPCD_QUIRK_NO_SINK_COUNT) },
> > >   /* Synaptics DP1.4 MST hubs can support DSC without virtual DPCD */
> > >   { OUI(0x90, 0xCC, 0x24), DEVICE_ID_ANY, true,
> > > BIT(DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) },
> > > + /* Optional 4K AMOLED panel in the ThinkPad X1 Extreme 2nd Generation
> > > +  * only supports DPCD backlight controls, despite advertising
> > > otherwise
> > > +  */
> > > + { OUI(0xba, 0x41, 0x59), DEVICE_ID_ANY, false,
> > > BIT(DP_DPCD_QUIRK_FORCE_DPCD_BACKLIGHT) },
> > >  };
> > >  
> > >  #undef OUI
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > index 77a759361c5c..57774003e8c5 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > @@ -328,11 +328,15 @@ intel_dp_aux_display_control_capable(struct
> > > intel_connector *connector)
> > >  int intel_dp_aux_init_backlight_funcs(struct intel_connector
> > > *intel_connector)
> > >  {
> > >   struct intel_panel *panel = _connector->panel;
> > > - struct drm_i915_private *dev_priv = to_i915(intel_connector-
> > > > base.dev);
> > > + struct intel_dp *intel_dp = enc_to_intel_dp(intel_connector->encoder);
> > > + struct drm_i915_private *i915 = to_i915(intel_connector->base.dev);
> > >  
> > >   if (i915_modparams.enable_dpcd_backlight == 0 ||
> > >   (i915_modparams.enable_dpcd_backlight == -1 &&
> > > - dev_priv->vbt.backlight.type !=
> > > INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE))

Re: [Intel-gfx] [PATCH v2 19/21] drm/vkms: Convert to CRTC VBLANK callbacks

2020-01-15 Thread Rodrigo Siqueira
Hi,

Thanks for the patch, I reviewed and tested it. Everything looks fine
for VKMS.

Reviewed-by: Rodrigo Siqueira 
Tested-by: Rodrigo Siqueira 

On 01/15, Thomas Zimmermann wrote:
> VBLANK callbacks in struct drm_driver are deprecated in favor of
> their equivalents in struct drm_crtc_funcs. Convert vkms over.
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/vkms/vkms_crtc.c | 9 ++---
>  drivers/gpu/drm/vkms/vkms_drv.c  | 1 -
>  drivers/gpu/drm/vkms/vkms_drv.h  | 4 
>  3 files changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c 
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index 74f703b8d22a..ac85e17428f8 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -76,10 +76,12 @@ static void vkms_disable_vblank(struct drm_crtc *crtc)
>   hrtimer_cancel(>vblank_hrtimer);
>  }
>  
> -bool vkms_get_vblank_timestamp(struct drm_device *dev, unsigned int pipe,
> -int *max_error, ktime_t *vblank_time,
> -bool in_vblank_irq)
> +static bool vkms_get_vblank_timestamp(struct drm_crtc *crtc,
> +   int *max_error, ktime_t *vblank_time,
> +   bool in_vblank_irq)
>  {
> + struct drm_device *dev = crtc->dev;
> + unsigned int pipe = crtc->index;
>   struct vkms_device *vkmsdev = drm_device_to_vkms_device(dev);
>   struct vkms_output *output = >output;
>   struct drm_vblank_crtc *vblank = >vblank[pipe];
> @@ -154,6 +156,7 @@ static const struct drm_crtc_funcs vkms_crtc_funcs = {
>   .atomic_destroy_state   = vkms_atomic_crtc_destroy_state,
>   .enable_vblank  = vkms_enable_vblank,
>   .disable_vblank = vkms_disable_vblank,
> + .get_vblank_timestamp   = vkms_get_vblank_timestamp,
>   .get_crc_sources= vkms_get_crc_sources,
>   .set_crc_source = vkms_set_crc_source,
>   .verify_crc_source  = vkms_verify_crc_source,
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 25bd7519295f..860de052e820 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -103,7 +103,6 @@ static struct drm_driver vkms_driver = {
>   .dumb_create= vkms_dumb_create,
>   .gem_vm_ops = _gem_vm_ops,
>   .gem_free_object_unlocked = vkms_gem_free_object,
> - .get_vblank_timestamp   = vkms_get_vblank_timestamp,
>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
>   .gem_prime_import_sg_table = vkms_prime_import_sg_table,
>  
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 7d52e24564db..eda04ffba7b1 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -111,10 +111,6 @@ struct vkms_gem_object {
>  int vkms_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
>  struct drm_plane *primary, struct drm_plane *cursor);
>  
> -bool vkms_get_vblank_timestamp(struct drm_device *dev, unsigned int pipe,
> -int *max_error, ktime_t *vblank_time,
> -bool in_vblank_irq);
> -
>  int vkms_output_init(struct vkms_device *vkmsdev, int index);
>  
>  struct drm_plane *vkms_plane_init(struct vkms_device *vkmsdev,
> -- 
> 2.24.1
> 

-- 
Rodrigo Siqueira
Software Engineer, Advanced Micro Devices (AMD)
https://siqueira.tech


signature.asc
Description: PGP signature
___
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: Fix too few arguments to function i915_capture_error_state

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix too few arguments to function i915_capture_error_state
URL   : https://patchwork.freedesktop.org/series/71974/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7735_full -> Patchwork_16081_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@runner@aborted:
- shard-hsw:  NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16081/shard-hsw5/igt@run...@aborted.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@vecs0-s3:
- shard-skl:  [PASS][2] -> [INCOMPLETE][3] ([i915#69])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-skl6/igt@gem_ctx_isolat...@vecs0-s3.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16081/shard-skl6/igt@gem_ctx_isolat...@vecs0-s3.html

  * igt@gem_ctx_persistence@rcs0-mixed-process:
- shard-apl:  [PASS][4] -> [FAIL][5] ([i915#679])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-apl1/igt@gem_ctx_persiste...@rcs0-mixed-process.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16081/shard-apl7/igt@gem_ctx_persiste...@rcs0-mixed-process.html

  * igt@gem_ctx_persistence@vcs1-hostile-preempt:
- shard-iclb: [PASS][6] -> [SKIP][7] ([fdo#109276] / [fdo#112080])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb4/igt@gem_ctx_persiste...@vcs1-hostile-preempt.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16081/shard-iclb3/igt@gem_ctx_persiste...@vcs1-hostile-preempt.html

  * igt@gem_ctx_shared@q-smoketest-bsd1:
- shard-tglb: [PASS][8] -> [INCOMPLETE][9] ([fdo#111735]) +1 
similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-tglb2/igt@gem_ctx_sha...@q-smoketest-bsd1.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16081/shard-tglb4/igt@gem_ctx_sha...@q-smoketest-bsd1.html

  * igt@gem_eio@reset-stress:
- shard-snb:  [PASS][10] -> [FAIL][11] ([i915#232])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-snb5/igt@gem_...@reset-stress.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16081/shard-snb2/igt@gem_...@reset-stress.html

  * igt@gem_exec_reuse@single:
- shard-tglb: [PASS][12] -> [INCOMPLETE][13] ([i915#472])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-tglb9/igt@gem_exec_re...@single.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16081/shard-tglb3/igt@gem_exec_re...@single.html

  * igt@gem_exec_schedule@independent-bsd2:
- shard-iclb: [PASS][14] -> [SKIP][15] ([fdo#109276]) +10 similar 
issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb4/igt@gem_exec_sched...@independent-bsd2.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16081/shard-iclb3/igt@gem_exec_sched...@independent-bsd2.html

  * igt@gem_exec_schedule@pi-distinct-iova-bsd:
- shard-iclb: [PASS][16] -> [SKIP][17] ([i915#677])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb8/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16081/shard-iclb4/igt@gem_exec_sched...@pi-distinct-iova-bsd.html

  * igt@gem_exec_schedule@preempt-queue-contexts-chain-blt:
- shard-tglb: [PASS][18] -> [INCOMPLETE][19] ([fdo#111606] / 
[fdo#111677] / [i915#472])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-tglb8/igt@gem_exec_sched...@preempt-queue-contexts-chain-blt.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16081/shard-tglb3/igt@gem_exec_sched...@preempt-queue-contexts-chain-blt.html

  * igt@gem_exec_schedule@preempt-queue-contexts-chain-bsd:
- shard-iclb: [PASS][20] -> [SKIP][21] ([fdo#112146]) +1 similar 
issue
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb5/igt@gem_exec_sched...@preempt-queue-contexts-chain-bsd.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16081/shard-iclb1/igt@gem_exec_sched...@preempt-queue-contexts-chain-bsd.html

  * igt@gem_exec_suspend@basic-s3:
- shard-tglb: [PASS][22] -> [INCOMPLETE][23] ([fdo#111736] / 
[i915#460] / [i915#472])
   [22]: 

[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915/dsi: Lookup the i2c bus from ACPI NS only if CONFIG_ACPI=y (v2) (rev2)

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915/dsi: Lookup the i2c bus from ACPI NS only if CONFIG_ACPI=y 
(v2) (rev2)
URL   : https://patchwork.freedesktop.org/series/72030/
State : warning

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 122 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:93: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1282: recipe for target 'modules' failed
make: *** [modules] Error 2

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16119/build_32bit.log
___
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/dsi: Lookup the i2c bus from ACPI NS only if CONFIG_ACPI=y (v2) (rev2)

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915/dsi: Lookup the i2c bus from ACPI NS only if CONFIG_ACPI=y 
(v2) (rev2)
URL   : https://patchwork.freedesktop.org/series/72030/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7751 -> Patchwork_16119


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_parallel@basic:
- 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_7751/fi-tgl-y/igt@gem_exec_paral...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16119/fi-tgl-y/igt@gem_exec_paral...@basic.html

  * igt@gem_exec_suspend@basic-s3:
- fi-cml-s:   [PASS][3] -> [DMESG-WARN][4] ([fdo#111764])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-cml-s/igt@gem_exec_susp...@basic-s3.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16119/fi-cml-s/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_selftest@live_blt:
- fi-ivb-3770:[PASS][5] -> [DMESG-FAIL][6] ([i915#725])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-ivb-3770/igt@i915_selftest@live_blt.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16119/fi-ivb-3770/igt@i915_selftest@live_blt.html

  
 Possible fixes 

  * igt@gem_close_race@basic-threads:
- fi-byt-j1900:   [TIMEOUT][7] ([fdo#112271] / [i915#816]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16119/fi-byt-j1900/igt@gem_close_r...@basic-threads.html

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

  * igt@i915_module_load@reload-with-fault-injection:
- fi-cfl-8700k:   [DMESG-WARN][11] ([i915#889]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-cfl-8700k/igt@i915_module_l...@reload-with-fault-injection.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16119/fi-cfl-8700k/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_selftest@live_execlists:
- fi-kbl-soraka:  [DMESG-FAIL][13] ([i915#656]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-kbl-soraka/igt@i915_selftest@live_execlists.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16119/fi-kbl-soraka/igt@i915_selftest@live_execlists.html

  
 Warnings 

  * igt@i915_module_load@reload-with-fault-injection:
- fi-skl-6770hq:  [DMESG-WARN][15] ([i915#889]) -> [DMESG-WARN][16] 
([i915#88])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-skl-6770hq/igt@i915_module_l...@reload-with-fault-injection.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16119/fi-skl-6770hq/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [INCOMPLETE][17] ([i915#151]) -> [FAIL][18] 
([i915#178])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16119/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

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

  [fdo#111764]: https://bugs.freedesktop.org/show_bug.cgi?id=111764
  [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
  [i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151
  [i915#178]: https://gitlab.freedesktop.org/drm/intel/issues/178
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656
  [i915#725]: https://gitlab.freedesktop.org/drm/intel/issues/725
  [i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816
  [i915#88]: https://gitlab.freedesktop.org/drm/intel/issues/88
  [i915#889]: https://gitlab.freedesktop.org/drm/intel/issues/889
  [i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937


Participating hosts (46 -> 43)
--

  Additional (5): fi-hsw-4770r fi-hsw-peppy fi-snb-2520m fi-blb-e6850 
fi-byt-n2820 
  Missing(8): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-bwr-2160 
fi-bsw-kefka fi-byt-clapper fi-skl-6600u 

Re: [Intel-gfx] [PATCH v12 4/5] drm/i915: Introduce parameterized DBUF_CTL

2020-01-15 Thread Matt Roper
On Wed, Jan 15, 2020 at 11:45:55PM +0200, Stanislav Lisovskiy wrote:
> Now start using parameterized DBUF_CTL instead
> of hardcoded, this would allow shorter access
> functions when reading or storing entire state.
> 
> Tried to implement it in a MMIO_PIPE manner, however
> DBUF_CTL1 address is higher than DBUF_CTL2, which
> implies that we have to now subtract from base
> rather than add.
> 
> Signed-off-by: Stanislav Lisovskiy 
> ---
>  .../drm/i915/display/intel_display_power.c| 19 +++
>  drivers/gpu/drm/i915/i915_reg.h   | 12 +---
>  drivers/gpu/drm/i915/intel_pm.c   | 18 ++
>  3 files changed, 14 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 4503f5fab63d..806392fd97ea 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -4415,22 +4415,9 @@ void icl_dbuf_slices_update(struct drm_i915_private 
> *dev_priv,
>   DRM_DEBUG_KMS("Updating dbuf slices to 0x%x\n", req_slices);
>  
>   for (i = 0; i < max_slices; i++) {
> - u8 slice_set = req_slices & BIT(i);
> -
> - switch (i) {
> - case DBUF_S1:
> - intel_dbuf_slice_set(dev_priv,
> -  DBUF_CTL_S1,
> -  slice_set);
> - break;
> - case DBUF_S2:
> - intel_dbuf_slice_set(dev_priv,
> -  DBUF_CTL_S2,
> -  slice_set);
> - break;
> - default:
> - MISSING_CASE(i);
> - }
> + intel_dbuf_slice_set(dev_priv,
> +  DBUF_CTL_S(i),
> +  (req_slices & BIT(i)) != 0);
>   }
>  
>   dev_priv->enabled_dbuf_slices_mask = req_slices;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index e5071af4a3b3..5978592cd0e1 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7745,9 +7745,15 @@ enum {
>  #define DISP_ARB_CTL2_MMIO(0x45004)
>  #define  DISP_DATA_PARTITION_5_6 (1 << 6)
>  #define  DISP_IPC_ENABLE (1 << 3)
> -#define DBUF_CTL _MMIO(0x45008)
> -#define DBUF_CTL_S1  _MMIO(0x45008)
> -#define DBUF_CTL_S2  _MMIO(0x44FE8)
> +#define DBUF_CTL_ADDR1   0x45008
> +#define DBUF_CTL_ADDR2   0x44FE8
> +#define DBUF_CTL _MMIO(DBUF_CTL_ADDR1)
> +#define DBUF_CTL_S1  DBUF_CTL
> +#define DBUF_CTL_S2  _MMIO(DBUF_CTL_ADDR2)

These two are never used anywhere now afaics.  I'd also be inclined to
drop DBUF_CTL and just do DBUF_CTL_S(0) in gen9_dbuf_{enable,disable}
and the GVT code.

> +/* DBUF_CTL_ADDR2 is less than DBUF_CTL_ADDR1 */
> +#define DBUF_CTL_DIST(DBUF_CTL_ADDR1 - 
> DBUF_CTL_ADDR2)
> +#define DBUF_CTL_ADDR(X) (DBUF_CTL_ADDR1 - (DBUF_CTL_DIST * (X)))
> +#define DBUF_CTL_S(X)(_MMIO(DBUF_CTL_ADDR(X)))

Given that slice 2's register is below slice 1's register, it doesn't
seem likely that potential future platforms with more slices would use
the same distance between registers.  Probably best to just use a
_PICK() construct.  E.g.,

#define DBUF_CTL_S(X)   _MMIO(_PICK(X, DBUF_CTL_ADDR1, DBUF_CTL_ADDR2))

Aside from that,

Reviewed-by: Matt Roper 

>  #define  DBUF_POWER_REQUEST  (1 << 31)
>  #define  DBUF_POWER_STATE(1 << 30)
>  #define GEN7_MSG_CTL _MMIO(0x45010)
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 7bd48f71198a..e5b82264ca5f 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3655,22 +3655,8 @@ u8 intel_enabled_dbuf_slices_mask(struct 
> drm_i915_private *dev_priv)
>   return BIT(DBUF_S1);
>  
>   for (i = 0; i < max_slices; i++) {
> - u8 slice_bit = BIT(i);
> - bool res;
> -
> - switch (i) {
> - case DBUF_S1:
> - res = I915_READ(DBUF_CTL_S1) & DBUF_POWER_STATE;
> - break;
> - case DBUF_S2:
> - res = I915_READ(DBUF_CTL_S2) & DBUF_POWER_STATE;
> - break;
> - default:
> - MISSING_CASE(slice_bit);
> - }
> -
> - if (res)
> - enabled_slices_mask |= slice_bit;
> + if (I915_READ(DBUF_CTL_S(i)) & DBUF_POWER_STATE)
> + enabled_slices_mask |= BIT(i);
>   }
>  
>   return enabled_slices_mask;
> -- 
> 2.24.1.485.gad05a3d8e5
> 

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

Re: [Intel-gfx] [PATCH v11 3/5] drm/i915: Manipulate DBuf slices properly

2020-01-15 Thread Matt Roper
On Wed, Jan 15, 2020 at 11:50:52AM +0200, Stanislav Lisovskiy wrote:
> Start manipulating DBuf slices as a mask,
> but not as a total number, as current approach
> doesn't give us full control on all combinations
> of slices, which we might need(like enabling S2
> only can't enabled by setting enabled_slices=1).
> 
> Removed wrong code from intel_get_ddb_size as
> it doesn't match to BSpec. For now still just
> use DBuf slice until proper algorithm is implemented.
> 
> Other minor code refactoring to get prepared
> for major DBuf assignment changes landed:
> - As now enabled slices contain a mask
>   we still need some value which should
>   reflect how much DBuf slices are supported
>   by the platform, now device info contains
>   num_supported_dbuf_slices.
> - Removed unneeded assertion as we are now
>   manipulating slices in a more proper way.
> 
> v2: Start using enabled_slices in dev_priv
> 
> v3: "enabled_slices" is now "enabled_dbuf_slices_mask",
> as this now sits in dev_priv independently.
> 
> v4: - Fixed debug print formatting to hex(Matt Roper)
> - Optimized dbuf slice updates to be used only
>   if slice union is different from current conf(Matt Roper)
> - Fixed some functions to be static(Matt Roper)
> - Created a parameterized version for DBUF_CTL to
>   simplify DBuf programming cycle(Matt Roper)
> - Removed unrequred field from GEN10_FEATURES(Matt Roper)
> 
> v5: - Removed redundant programming dbuf slices helper(Ville Syrjälä)
> - Started to use parameterized loop for hw readout to get slices
>   (Ville Syrjälä)
> - Added back assertion checking amount of DBUF slices enabled
>   after DC states 5/6 transition, also added new assertion
>   as starting from ICL DMC seems to restore the last DBuf
>   power state set, rather than power up all dbuf slices
>   as assertion was previously expecting(Ville Syrjälä)
> 
> v6: - Now using enum for DBuf slices in this patch (Ville Syrjälä)
> - Removed gen11_assert_dbuf_enabled and put gen9_assert_dbuf_enabled
>   back, as we really need to have a single unified assert here
>   however currently enabling always slice 1 is enforced by BSpec,
>   so we will have to OR enabled slices mask with 1 in order
>   to be consistent with BSpec, that way we can unify that
>   assertion and against the actual state from the driver, but
>   not some hardcoded value.(concluded with Ville)
> - Remove parameterized DBUF_CTL version, to extract it to another
>   patch.(Ville Syrjälä)
> 
> Signed-off-by: Stanislav Lisovskiy 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c  | 23 ++---
>  .../drm/i915/display/intel_display_power.c| 95 +--
>  .../drm/i915/display/intel_display_power.h|  6 ++
>  .../drm/i915/display/intel_display_types.h|  2 +-
>  drivers/gpu/drm/i915/i915_drv.h   |  2 +-
>  drivers/gpu/drm/i915/i915_pci.c   |  5 +-
>  drivers/gpu/drm/i915/intel_device_info.h  |  1 +
>  drivers/gpu/drm/i915/intel_pm.c   | 66 ++---
>  drivers/gpu/drm/i915/intel_pm.h   |  2 +-
>  9 files changed, 99 insertions(+), 103 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 441bbf67bace..c2ff17358858 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -13769,12 +13769,12 @@ static void verify_wm_state(struct intel_crtc *crtc,
>  
>   skl_pipe_ddb_get_hw_state(crtc, hw->ddb_y, hw->ddb_uv);
>  
> - hw_enabled_slices = intel_enabled_dbuf_slices_num(dev_priv);
> + hw_enabled_slices = intel_enabled_dbuf_slices_mask(dev_priv);
>  
>   if (INTEL_GEN(dev_priv) >= 11 &&
> - hw_enabled_slices != dev_priv->enabled_dbuf_slices_num)
> - DRM_ERROR("mismatch in DBUF Slices (expected %u, got %u)\n",
> -   dev_priv->enabled_dbuf_slices_num,
> + hw_enabled_slices != dev_priv->enabled_dbuf_slices_mask)
> + DRM_ERROR("mismatch in DBUF Slices (expected 0x%x, got 0x%x)\n",
> +   dev_priv->enabled_dbuf_slices_mask,
> hw_enabled_slices);
>  
>   /* planes */
> @@ -15118,22 +15118,23 @@ static void 
> intel_update_trans_port_sync_crtcs(struct intel_crtc *crtc,
>  static void icl_dbuf_slice_pre_update(struct intel_atomic_state *state)
>  {
>   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> - u8 hw_enabled_slices = dev_priv->enabled_dbuf_slices_num;
> - u8 required_slices = state->enabled_dbuf_slices_num;
> + u8 hw_enabled_slices = dev_priv->enabled_dbuf_slices_mask;
> + u8 required_slices = state->enabled_dbuf_slices_mask;
> + u8 slices_union = hw_enabled_slices | required_slices;
>  
>   /* If 2nd DBuf slice required, enable it here */
> - if (INTEL_GEN(dev_priv) >= 11 && required_slices > 

[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm: Inject a cond_resched() into long drm_clflush_sg()

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm: Inject a cond_resched() into long drm_clflush_sg()
URL   : https://patchwork.freedesktop.org/series/72085/
State : warning

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 122 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:93: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1282: recipe for target 'modules' failed
make: *** [modules] Error 2

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16118/build_32bit.log
___
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: Inject a cond_resched() into long drm_clflush_sg()

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm: Inject a cond_resched() into long drm_clflush_sg()
URL   : https://patchwork.freedesktop.org/series/72085/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7751 -> Patchwork_16118


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_parallel@basic:
- 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_7751/fi-tgl-y/igt@gem_exec_paral...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16118/fi-tgl-y/igt@gem_exec_paral...@basic.html

  * igt@gem_exec_suspend@basic-s3:
- fi-cml-s:   [PASS][3] -> [DMESG-WARN][4] ([fdo#111764])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-cml-s/igt@gem_exec_susp...@basic-s3.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16118/fi-cml-s/igt@gem_exec_susp...@basic-s3.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-skl-6700k2:  [PASS][5] -> [INCOMPLETE][6] ([i915#69])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-skl-6700k2/igt@kms_chamel...@common-hpd-after-suspend.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16118/fi-skl-6700k2/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  [PASS][7] -> [FAIL][8] ([i915#217])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16118/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  
 Possible fixes 

  * igt@gem_close_race@basic-threads:
- fi-byt-j1900:   [TIMEOUT][9] ([fdo#112271] / [i915#816]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16118/fi-byt-j1900/igt@gem_close_r...@basic-threads.html

  * igt@gem_exec_gttfill@basic:
- {fi-ehl-1}: [INCOMPLETE][11] ([i915#937]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-ehl-1/igt@gem_exec_gttf...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16118/fi-ehl-1/igt@gem_exec_gttf...@basic.html

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

  * igt@i915_module_load@reload-with-fault-injection:
- fi-cfl-8700k:   [DMESG-WARN][15] ([i915#889]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-cfl-8700k/igt@i915_module_l...@reload-with-fault-injection.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16118/fi-cfl-8700k/igt@i915_module_l...@reload-with-fault-injection.html
- fi-skl-6770hq:  [DMESG-WARN][17] ([i915#889]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-skl-6770hq/igt@i915_module_l...@reload-with-fault-injection.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16118/fi-skl-6770hq/igt@i915_module_l...@reload-with-fault-injection.html
- fi-skl-6600u:   [DMESG-WARN][19] ([i915#889]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-skl-6600u/igt@i915_module_l...@reload-with-fault-injection.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16118/fi-skl-6600u/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [INCOMPLETE][21] ([i915#151]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16118/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_execlists:
- fi-kbl-soraka:  [DMESG-FAIL][23] ([i915#656]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-kbl-soraka/igt@i915_selftest@live_execlists.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16118/fi-kbl-soraka/igt@i915_selftest@live_execlists.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [FAIL][25] ([fdo#111096] / [i915#323]) -> [PASS][26]
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [26]: 

[Intel-gfx] [PATCH v12 1/5] drm/i915: Remove skl_ddl_allocation struct

2020-01-15 Thread Stanislav Lisovskiy
Current consensus that it is redundant as
we already have skl_ddb_values struct out there,
also this struct contains only single member
which makes it unnecessary.

v2: As dirty_pipes soon going to be nuked away
from skl_ddb_values, evacuating enabled_slices
to safer in dev_priv.

v3: Changed "enabled_slices" to be "enabled_dbuf_slices_num"
(Matt Roper)

v4: - Wrapped the line getting number of dbuf slices(Matt Roper)
- Removed indeed redundant skl_ddb_values declaration(Matt Roper)

Reviewed-by: Matt Roper 
Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/display/intel_display.c  | 16 +++
 .../drm/i915/display/intel_display_power.c|  8 ++--
 .../drm/i915/display/intel_display_types.h|  3 ++
 drivers/gpu/drm/i915/i915_drv.h   |  7 +--
 drivers/gpu/drm/i915/intel_pm.c   | 45 +--
 drivers/gpu/drm/i915/intel_pm.h   |  5 +--
 6 files changed, 39 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index aa0ece27186c..eee9e3d9c72d 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -13750,14 +13750,13 @@ static void verify_wm_state(struct intel_crtc *crtc,
struct skl_hw_state {
struct skl_ddb_entry ddb_y[I915_MAX_PLANES];
struct skl_ddb_entry ddb_uv[I915_MAX_PLANES];
-   struct skl_ddb_allocation ddb;
struct skl_pipe_wm wm;
} *hw;
-   struct skl_ddb_allocation *sw_ddb;
struct skl_pipe_wm *sw_wm;
struct skl_ddb_entry *hw_ddb_entry, *sw_ddb_entry;
const enum pipe pipe = crtc->pipe;
int plane, level, max_level = ilk_wm_max_level(dev_priv);
+   u8 hw_enabled_slices;
 
if (INTEL_GEN(dev_priv) < 9 || !new_crtc_state->hw.active)
return;
@@ -13771,14 +13770,13 @@ static void verify_wm_state(struct intel_crtc *crtc,
 
skl_pipe_ddb_get_hw_state(crtc, hw->ddb_y, hw->ddb_uv);
 
-   skl_ddb_get_hw_state(dev_priv, >ddb);
-   sw_ddb = _priv->wm.skl_hw.ddb;
+   hw_enabled_slices = intel_enabled_dbuf_slices_num(dev_priv);
 
if (INTEL_GEN(dev_priv) >= 11 &&
-   hw->ddb.enabled_slices != sw_ddb->enabled_slices)
+   hw_enabled_slices != dev_priv->enabled_dbuf_slices_num)
DRM_ERROR("mismatch in DBUF Slices (expected %u, got %u)\n",
- sw_ddb->enabled_slices,
- hw->ddb.enabled_slices);
+ dev_priv->enabled_dbuf_slices_num,
+ hw_enabled_slices);
 
/* planes */
for_each_universal_plane(dev_priv, pipe, plane) {
@@ -15123,8 +15121,8 @@ static void skl_commit_modeset_enables(struct 
intel_atomic_state *state)
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
struct intel_crtc *crtc;
struct intel_crtc_state *old_crtc_state, *new_crtc_state;
-   u8 hw_enabled_slices = dev_priv->wm.skl_hw.ddb.enabled_slices;
-   u8 required_slices = state->wm_results.ddb.enabled_slices;
+   u8 hw_enabled_slices = dev_priv->enabled_dbuf_slices_num;
+   u8 required_slices = state->enabled_dbuf_slices_num;
struct skl_ddb_entry entries[I915_MAX_PIPES] = {};
const u8 num_pipes = INTEL_NUM_PIPES(dev_priv);
u8 update_pipes = 0, modeset_pipes = 0;
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 21561acfa3ac..5e1c601f0f99 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -4406,7 +4406,7 @@ static u8 intel_dbuf_max_slices(struct drm_i915_private 
*dev_priv)
 void icl_dbuf_slices_update(struct drm_i915_private *dev_priv,
u8 req_slices)
 {
-   const u8 hw_enabled_slices = dev_priv->wm.skl_hw.ddb.enabled_slices;
+   const u8 hw_enabled_slices = dev_priv->enabled_dbuf_slices_num;
bool ret;
 
if (req_slices > intel_dbuf_max_slices(dev_priv)) {
@@ -4423,7 +4423,7 @@ void icl_dbuf_slices_update(struct drm_i915_private 
*dev_priv,
ret = intel_dbuf_slice_set(dev_priv, DBUF_CTL_S2, false);
 
if (ret)
-   dev_priv->wm.skl_hw.ddb.enabled_slices = req_slices;
+   dev_priv->enabled_dbuf_slices_num = req_slices;
 }
 
 static void icl_dbuf_enable(struct drm_i915_private *dev_priv)
@@ -4442,7 +4442,7 @@ static void icl_dbuf_enable(struct drm_i915_private 
*dev_priv)
 * FIXME: for now pretend that we only have 1 slice, see
 * intel_enabled_dbuf_slices_num().
 */
-   dev_priv->wm.skl_hw.ddb.enabled_slices = 1;
+   dev_priv->enabled_dbuf_slices_num = 1;
 }
 
 static void icl_dbuf_disable(struct drm_i915_private *dev_priv)
@@ -4461,7 +4461,7 @@ static void 

[Intel-gfx] [PATCH v12 3/5] drm/i915: Manipulate DBuf slices properly

2020-01-15 Thread Stanislav Lisovskiy
Start manipulating DBuf slices as a mask,
but not as a total number, as current approach
doesn't give us full control on all combinations
of slices, which we might need(like enabling S2
only can't enabled by setting enabled_slices=1).

Removed wrong code from intel_get_ddb_size as
it doesn't match to BSpec. For now still just
use DBuf slice until proper algorithm is implemented.

Other minor code refactoring to get prepared
for major DBuf assignment changes landed:
- As now enabled slices contain a mask
  we still need some value which should
  reflect how much DBuf slices are supported
  by the platform, now device info contains
  num_supported_dbuf_slices.
- Removed unneeded assertion as we are now
  manipulating slices in a more proper way.

v2: Start using enabled_slices in dev_priv

v3: "enabled_slices" is now "enabled_dbuf_slices_mask",
as this now sits in dev_priv independently.

v4: - Fixed debug print formatting to hex(Matt Roper)
- Optimized dbuf slice updates to be used only
  if slice union is different from current conf(Matt Roper)
- Fixed some functions to be static(Matt Roper)
- Created a parameterized version for DBUF_CTL to
  simplify DBuf programming cycle(Matt Roper)
- Removed unrequred field from GEN10_FEATURES(Matt Roper)

v5: - Removed redundant programming dbuf slices helper(Ville Syrjälä)
- Started to use parameterized loop for hw readout to get slices
  (Ville Syrjälä)
- Added back assertion checking amount of DBUF slices enabled
  after DC states 5/6 transition, also added new assertion
  as starting from ICL DMC seems to restore the last DBuf
  power state set, rather than power up all dbuf slices
  as assertion was previously expecting(Ville Syrjälä)

v6: - Now using enum for DBuf slices in this patch (Ville Syrjälä)
- Removed gen11_assert_dbuf_enabled and put gen9_assert_dbuf_enabled
  back, as we really need to have a single unified assert here
  however currently enabling always slice 1 is enforced by BSpec,
  so we will have to OR enabled slices mask with 1 in order
  to be consistent with BSpec, that way we can unify that
  assertion and against the actual state from the driver, but
  not some hardcoded value.(concluded with Ville)
- Remove parameterized DBUF_CTL version, to extract it to another
  patch.(Ville Syrjälä)

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/display/intel_display.c  | 23 ++---
 .../drm/i915/display/intel_display_power.c| 95 +--
 .../drm/i915/display/intel_display_power.h|  6 ++
 .../drm/i915/display/intel_display_types.h|  2 +-
 drivers/gpu/drm/i915/i915_drv.h   |  2 +-
 drivers/gpu/drm/i915/i915_pci.c   |  5 +-
 drivers/gpu/drm/i915/intel_device_info.h  |  1 +
 drivers/gpu/drm/i915/intel_pm.c   | 65 ++---
 drivers/gpu/drm/i915/intel_pm.h   |  2 +-
 9 files changed, 98 insertions(+), 103 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 8b06ef29693e..061de161b95b 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -13770,12 +13770,12 @@ static void verify_wm_state(struct intel_crtc *crtc,
 
skl_pipe_ddb_get_hw_state(crtc, hw->ddb_y, hw->ddb_uv);
 
-   hw_enabled_slices = intel_enabled_dbuf_slices_num(dev_priv);
+   hw_enabled_slices = intel_enabled_dbuf_slices_mask(dev_priv);
 
if (INTEL_GEN(dev_priv) >= 11 &&
-   hw_enabled_slices != dev_priv->enabled_dbuf_slices_num)
-   DRM_ERROR("mismatch in DBUF Slices (expected %u, got %u)\n",
- dev_priv->enabled_dbuf_slices_num,
+   hw_enabled_slices != dev_priv->enabled_dbuf_slices_mask)
+   DRM_ERROR("mismatch in DBUF Slices (expected 0x%x, got 0x%x)\n",
+ dev_priv->enabled_dbuf_slices_mask,
  hw_enabled_slices);
 
/* planes */
@@ -15119,22 +15119,23 @@ static void intel_update_trans_port_sync_crtcs(struct 
intel_crtc *crtc,
 static void icl_dbuf_slice_pre_update(struct intel_atomic_state *state)
 {
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
-   u8 hw_enabled_slices = dev_priv->enabled_dbuf_slices_num;
-   u8 required_slices = state->enabled_dbuf_slices_num;
+   u8 hw_enabled_slices = dev_priv->enabled_dbuf_slices_mask;
+   u8 required_slices = state->enabled_dbuf_slices_mask;
+   u8 slices_union = hw_enabled_slices | required_slices;
 
/* If 2nd DBuf slice required, enable it here */
-   if (INTEL_GEN(dev_priv) >= 11 && required_slices > hw_enabled_slices)
-   icl_dbuf_slices_update(dev_priv, required_slices);
+   if (INTEL_GEN(dev_priv) >= 11 && slices_union != hw_enabled_slices)
+   icl_dbuf_slices_update(dev_priv, slices_union);
 }
 
 static void 

[Intel-gfx] [PATCH v12 5/5] drm/i915: Correctly map DBUF slices to pipes

2020-01-15 Thread Stanislav Lisovskiy
Added proper DBuf slice mapping to correspondent
pipes, depending on pipe configuration as stated
in BSpec.

v2:
- Remove unneeded braces
- Stop using macro for DBuf assignments as
  it seems to reduce readability.

v3: Start using enabled slices mask in dev_priv

v4: Renamed "enabled_slices" used in dev_priv
to "enabled_dbuf_slices_mask"(Matt Roper)

v5: - Removed redundant parameters from
  intel_get_ddb_size function.(Matt Roper)
- Made i915_possible_dbuf_slices static(Matt Roper)
- Renamed total_width into total_width_in_range
  so that it now reflects that this is not
  a total pipe width but the one in current
  dbuf slice allowed range for pipe.(Matt Roper)
- Removed 4th pipe for ICL in DBuf assignment
  table(Matt Roper)
- Fixed wrong DBuf slice in DBuf table for TGL
  (Matt Roper)
- Added comment regarding why we currently not
  using pipe ratio for DBuf assignment for ICL

v6: - Changed u32 to unsigned int in
  icl_get_first_dbuf_slice_offset function signature
  (Ville Syrjälä)
- Changed also u32 to u8 in dbuf slice mask structure
  (Ville Syrjälä)
- Switched from DBUF_S1_BIT to enum + explicit
  BIT(DBUF_S1) access(Ville Syrjälä)
- Switched to named initializers in DBuf assignment
  arrays(Ville Syrjälä)
- DBuf assignment arrays now use autogeneration tool
  from
  https://patchwork.freedesktop.org/series/70493/
  to avoid typos.
- Renamed i915_find_pipe_conf to *_compute_dbuf_slices
  (Ville Syrjälä)
- Changed platforms ordering in skl_compute_dbuf_slices
  to be from newest to oldest(Ville Syrjälä)

v7: - Now ORing assigned DBuf slice config always with DBUF_S1
  because slice 1 has to be constantly powered on.
  (Ville Syrjälä)

Signed-off-by: Stanislav Lisovskiy 
---
 .../drm/i915/display/intel_display_power.c|  15 +-
 drivers/gpu/drm/i915/intel_pm.c   | 395 +-
 drivers/gpu/drm/i915/intel_pm.h   |   2 +
 3 files changed, 390 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 806392fd97ea..92c53c7ca49c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -1029,12 +1029,19 @@ static bool gen9_dc_off_power_well_enabled(struct 
drm_i915_private *dev_priv,
 
 static void gen9_assert_dbuf_enabled(struct drm_i915_private *dev_priv)
 {
-   u8 enabled_dbuf_slices = intel_enabled_dbuf_slices_mask(dev_priv);
+   u8 hw_enabled_dbuf_slices = intel_enabled_dbuf_slices_mask(dev_priv);
+   /*
+* Slice 1 is always enabled according to BSpec, we are ORing it
+* also during modeset, however we might not have had any modeset yet
+* so not to have this assertion during boot, ORing it here as well.
+*/
+   u8 enabled_dbuf_slices = dev_priv->enabled_dbuf_slices_mask |
+BIT(DBUF_S1);
 
-   WARN(enabled_dbuf_slices != dev_priv->enabled_dbuf_slices_mask,
+   WARN(hw_enabled_dbuf_slices != enabled_dbuf_slices,
 "Unexpected DBuf power power state (0x%08x, expected 0x%08x)\n",
-enabled_dbuf_slices,
-dev_priv->enabled_dbuf_slices_mask);
+hw_enabled_dbuf_slices,
+enabled_dbuf_slices);
 }
 
 static void gen9_disable_dc_states(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e5b82264ca5f..e18622630219 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3860,13 +3860,29 @@ bool intel_can_enable_sagv(struct intel_atomic_state 
*state)
return true;
 }
 
-static u16 intel_get_ddb_size(struct drm_i915_private *dev_priv,
- const struct intel_crtc_state *crtc_state,
- const u64 total_data_rate,
- const int num_active)
+/*
+ * Calculate initial DBuf slice offset, based on slice size
+ * and mask(i.e if slice size is 1024 and second slice is enabled
+ * offset would be 1024)
+ */
+static unsigned int
+icl_get_first_dbuf_slice_offset(u32 dbuf_slice_mask,
+   u32 slice_size,
+   u32 ddb_size)
+{
+   unsigned int offset = 0;
+
+   if (!dbuf_slice_mask)
+   return 0;
+
+   offset = (ffs(dbuf_slice_mask) - 1) * slice_size;
+
+   WARN_ON(offset >= ddb_size);
+   return offset;
+}
+
+static u16 intel_get_ddb_size(struct drm_i915_private *dev_priv)
 {
-   struct drm_atomic_state *state = crtc_state->uapi.state;
-   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
u16 ddb_size = INTEL_INFO(dev_priv)->ddb_size;
 
WARN_ON(ddb_size == 0);
@@ -3874,12 +3890,12 @@ static u16 intel_get_ddb_size(struct drm_i915_private 

[Intel-gfx] [PATCH v12 0/5] Enable second DBuf slice for ICL and TGL

2020-01-15 Thread Stanislav Lisovskiy
Those patch series, do some initial preparation DBuf manipulating code
cleanups, i.e remove redundant structures/code, switch to mask
based DBuf manupulation, get into use DBuf assignment according to
BSpec rules.

Stanislav Lisovskiy (5):
  drm/i915: Remove skl_ddl_allocation struct
  drm/i915: Move dbuf slice update to proper place
  drm/i915: Manipulate DBuf slices properly
  drm/i915: Introduce parameterized DBUF_CTL
  drm/i915: Correctly map DBUF slices to pipes

 drivers/gpu/drm/i915/display/intel_display.c  |  52 +-
 .../drm/i915/display/intel_display_power.c|  88 ++--
 .../drm/i915/display/intel_display_power.h|   6 +
 .../drm/i915/display/intel_display_types.h|   3 +
 drivers/gpu/drm/i915/i915_drv.h   |   7 +-
 drivers/gpu/drm/i915/i915_pci.c   |   5 +-
 drivers/gpu/drm/i915/i915_reg.h   |  12 +-
 drivers/gpu/drm/i915/intel_device_info.h  |   1 +
 drivers/gpu/drm/i915/intel_pm.c   | 457 +++---
 drivers/gpu/drm/i915/intel_pm.h   |   7 +-
 10 files changed, 496 insertions(+), 142 deletions(-)

-- 
2.24.1.485.gad05a3d8e5

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


[Intel-gfx] [PATCH v12 4/5] drm/i915: Introduce parameterized DBUF_CTL

2020-01-15 Thread Stanislav Lisovskiy
Now start using parameterized DBUF_CTL instead
of hardcoded, this would allow shorter access
functions when reading or storing entire state.

Tried to implement it in a MMIO_PIPE manner, however
DBUF_CTL1 address is higher than DBUF_CTL2, which
implies that we have to now subtract from base
rather than add.

Signed-off-by: Stanislav Lisovskiy 
---
 .../drm/i915/display/intel_display_power.c| 19 +++
 drivers/gpu/drm/i915/i915_reg.h   | 12 +---
 drivers/gpu/drm/i915/intel_pm.c   | 18 ++
 3 files changed, 14 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 4503f5fab63d..806392fd97ea 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -4415,22 +4415,9 @@ void icl_dbuf_slices_update(struct drm_i915_private 
*dev_priv,
DRM_DEBUG_KMS("Updating dbuf slices to 0x%x\n", req_slices);
 
for (i = 0; i < max_slices; i++) {
-   u8 slice_set = req_slices & BIT(i);
-
-   switch (i) {
-   case DBUF_S1:
-   intel_dbuf_slice_set(dev_priv,
-DBUF_CTL_S1,
-slice_set);
-   break;
-   case DBUF_S2:
-   intel_dbuf_slice_set(dev_priv,
-DBUF_CTL_S2,
-slice_set);
-   break;
-   default:
-   MISSING_CASE(i);
-   }
+   intel_dbuf_slice_set(dev_priv,
+DBUF_CTL_S(i),
+(req_slices & BIT(i)) != 0);
}
 
dev_priv->enabled_dbuf_slices_mask = req_slices;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e5071af4a3b3..5978592cd0e1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7745,9 +7745,15 @@ enum {
 #define DISP_ARB_CTL2  _MMIO(0x45004)
 #define  DISP_DATA_PARTITION_5_6   (1 << 6)
 #define  DISP_IPC_ENABLE   (1 << 3)
-#define DBUF_CTL   _MMIO(0x45008)
-#define DBUF_CTL_S1_MMIO(0x45008)
-#define DBUF_CTL_S2_MMIO(0x44FE8)
+#define DBUF_CTL_ADDR1 0x45008
+#define DBUF_CTL_ADDR2 0x44FE8
+#define DBUF_CTL   _MMIO(DBUF_CTL_ADDR1)
+#define DBUF_CTL_S1DBUF_CTL
+#define DBUF_CTL_S2_MMIO(DBUF_CTL_ADDR2)
+/* DBUF_CTL_ADDR2 is less than DBUF_CTL_ADDR1 */
+#define DBUF_CTL_DIST  (DBUF_CTL_ADDR1 - DBUF_CTL_ADDR2)
+#define DBUF_CTL_ADDR(X)   (DBUF_CTL_ADDR1 - (DBUF_CTL_DIST * (X)))
+#define DBUF_CTL_S(X)  (_MMIO(DBUF_CTL_ADDR(X)))
 #define  DBUF_POWER_REQUEST(1 << 31)
 #define  DBUF_POWER_STATE  (1 << 30)
 #define GEN7_MSG_CTL   _MMIO(0x45010)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7bd48f71198a..e5b82264ca5f 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3655,22 +3655,8 @@ u8 intel_enabled_dbuf_slices_mask(struct 
drm_i915_private *dev_priv)
return BIT(DBUF_S1);
 
for (i = 0; i < max_slices; i++) {
-   u8 slice_bit = BIT(i);
-   bool res;
-
-   switch (i) {
-   case DBUF_S1:
-   res = I915_READ(DBUF_CTL_S1) & DBUF_POWER_STATE;
-   break;
-   case DBUF_S2:
-   res = I915_READ(DBUF_CTL_S2) & DBUF_POWER_STATE;
-   break;
-   default:
-   MISSING_CASE(slice_bit);
-   }
-
-   if (res)
-   enabled_slices_mask |= slice_bit;
+   if (I915_READ(DBUF_CTL_S(i)) & DBUF_POWER_STATE)
+   enabled_slices_mask |= BIT(i);
}
 
return enabled_slices_mask;
-- 
2.24.1.485.gad05a3d8e5

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


[Intel-gfx] [PATCH v12 2/5] drm/i915: Move dbuf slice update to proper place

2020-01-15 Thread Stanislav Lisovskiy
Current DBuf slices update wasn't done in proper
place, especially its "post" part, which should
disable those only once vblank had passed and
all other changes are committed.

v2: Fix to use dev_priv and intel_atomic_state
instead of skl_ddb_values
(to be nuked in Villes patch)

v3: Renamed "enabled_slices" to "enabled_dbuf_slices_num"
(Matt Roper)

v4: - Rebase against drm-tip.
- Move post_update closer to optimize_watermarks,
  to prevent unneeded noise from underrun reporting
  (Ville Syrjälä)

Reviewed-by: Matt Roper 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/display/intel_display.c | 37 +++-
 1 file changed, 28 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index eee9e3d9c72d..8b06ef29693e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15116,13 +15116,33 @@ static void intel_update_trans_port_sync_crtcs(struct 
intel_crtc *crtc,
   state);
 }
 
+static void icl_dbuf_slice_pre_update(struct intel_atomic_state *state)
+{
+   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+   u8 hw_enabled_slices = dev_priv->enabled_dbuf_slices_num;
+   u8 required_slices = state->enabled_dbuf_slices_num;
+
+   /* If 2nd DBuf slice required, enable it here */
+   if (INTEL_GEN(dev_priv) >= 11 && required_slices > hw_enabled_slices)
+   icl_dbuf_slices_update(dev_priv, required_slices);
+}
+
+static void icl_dbuf_slice_post_update(struct intel_atomic_state *state)
+{
+   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+   u8 hw_enabled_slices = dev_priv->enabled_dbuf_slices_num;
+   u8 required_slices = state->enabled_dbuf_slices_num;
+
+   /* If 2nd DBuf slice is no more required disable it */
+   if (INTEL_GEN(dev_priv) >= 11 && required_slices < hw_enabled_slices)
+   icl_dbuf_slices_update(dev_priv, required_slices);
+}
+
 static void skl_commit_modeset_enables(struct intel_atomic_state *state)
 {
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
struct intel_crtc *crtc;
struct intel_crtc_state *old_crtc_state, *new_crtc_state;
-   u8 hw_enabled_slices = dev_priv->enabled_dbuf_slices_num;
-   u8 required_slices = state->enabled_dbuf_slices_num;
struct skl_ddb_entry entries[I915_MAX_PIPES] = {};
const u8 num_pipes = INTEL_NUM_PIPES(dev_priv);
u8 update_pipes = 0, modeset_pipes = 0;
@@ -15141,10 +15161,6 @@ static void skl_commit_modeset_enables(struct 
intel_atomic_state *state)
}
}
 
-   /* If 2nd DBuf slice required, enable it here */
-   if (INTEL_GEN(dev_priv) >= 11 && required_slices > hw_enabled_slices)
-   icl_dbuf_slices_update(dev_priv, required_slices);
-
/*
 * Whenever the number of active pipes changes, we need to make sure we
 * update the pipes in the right order so that their ddb allocations
@@ -15246,9 +15262,6 @@ static void skl_commit_modeset_enables(struct 
intel_atomic_state *state)
 
WARN_ON(modeset_pipes);
 
-   /* If 2nd DBuf slice is no more required disable it */
-   if (INTEL_GEN(dev_priv) >= 11 && required_slices < hw_enabled_slices)
-   icl_dbuf_slices_update(dev_priv, required_slices);
 }
 
 static void intel_atomic_helper_free_state(struct drm_i915_private *dev_priv)
@@ -15378,6 +15391,9 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)
if (state->modeset)
intel_encoders_update_prepare(state);
 
+   /* Enable all new slices, we might need */
+   icl_dbuf_slice_pre_update(state);
+
/* Now enable the clocks, plane, pipe, and connectors that we set up. */
dev_priv->display.commit_modeset_enables(state);
 
@@ -15434,6 +15450,9 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)
dev_priv->display.optimize_watermarks(state, crtc);
}
 
+   /* Disable all slices, we don't need */
+   icl_dbuf_slice_post_update(state);
+
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state, 
new_crtc_state, i) {
intel_post_plane_update(state, crtc);
 
-- 
2.24.1.485.gad05a3d8e5

___
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: Fix multiple definition of 'i915_vma_capture_finish'

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix multiple definition of 'i915_vma_capture_finish'
URL   : https://patchwork.freedesktop.org/series/71973/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7735_full -> Patchwork_16080_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@vcs1-queued:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276] / [fdo#112080]) 
+1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb2/igt@gem_ctx_persiste...@vcs1-queued.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16080/shard-iclb6/igt@gem_ctx_persiste...@vcs1-queued.html

  * igt@gem_ctx_persistence@vecs0-mixed-process:
- shard-glk:  [PASS][3] -> [FAIL][4] ([i915#679])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-glk4/igt@gem_ctx_persiste...@vecs0-mixed-process.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16080/shard-glk9/igt@gem_ctx_persiste...@vecs0-mixed-process.html

  * igt@gem_ctx_shared@q-smoketest-bsd1:
- shard-tglb: [PASS][5] -> [INCOMPLETE][6] ([fdo#111735])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-tglb2/igt@gem_ctx_sha...@q-smoketest-bsd1.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16080/shard-tglb3/igt@gem_ctx_sha...@q-smoketest-bsd1.html

  * igt@gem_ctx_shared@q-smoketest-bsd2:
- shard-tglb: [PASS][7] -> [INCOMPLETE][8] ([i915#461])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-tglb9/igt@gem_ctx_sha...@q-smoketest-bsd2.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16080/shard-tglb2/igt@gem_ctx_sha...@q-smoketest-bsd2.html

  * igt@gem_exec_async@concurrent-writes-bsd:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146]) +5 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb6/igt@gem_exec_as...@concurrent-writes-bsd.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16080/shard-iclb4/igt@gem_exec_as...@concurrent-writes-bsd.html

  * igt@gem_exec_parallel@basic:
- shard-tglb: [PASS][11] -> [INCOMPLETE][12] ([i915#472] / 
[i915#476])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-tglb8/igt@gem_exec_paral...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16080/shard-tglb8/igt@gem_exec_paral...@basic.html

  * igt@gem_exec_schedule@independent-bsd2:
- shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109276]) +14 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb4/igt@gem_exec_sched...@independent-bsd2.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16080/shard-iclb5/igt@gem_exec_sched...@independent-bsd2.html

  * igt@gem_exec_schedule@pi-common-bsd:
- shard-iclb: [PASS][15] -> [SKIP][16] ([i915#677]) +1 similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb6/igt@gem_exec_sched...@pi-common-bsd.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16080/shard-iclb4/igt@gem_exec_sched...@pi-common-bsd.html

  * igt@gem_exec_schedule@preempt-queue-contexts-chain-blt:
- shard-tglb: [PASS][17] -> [INCOMPLETE][18] ([fdo#111606] / 
[fdo#111677] / [i915#472])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-tglb8/igt@gem_exec_sched...@preempt-queue-contexts-chain-blt.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16080/shard-tglb6/igt@gem_exec_sched...@preempt-queue-contexts-chain-blt.html

  * igt@gem_exec_schedule@smoketest-blt:
- shard-tglb: [PASS][19] -> [INCOMPLETE][20] ([i915#470] / 
[i915#472])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-tglb4/igt@gem_exec_sched...@smoketest-blt.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16080/shard-tglb3/igt@gem_exec_sched...@smoketest-blt.html

  * igt@gem_exec_schedule@smoketest-bsd1:
- shard-tglb: [PASS][21] -> [INCOMPLETE][22] ([i915#463] / 
[i915#472])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-tglb5/igt@gem_exec_sched...@smoketest-bsd1.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16080/shard-tglb4/igt@gem_exec_sched...@smoketest-bsd1.html

  * igt@gem_persistent_relocs@forked-faulting-reloc-thrashing:
- shard-iclb: [PASS][23] -> [INCOMPLETE][24] ([i915#140] / 
[i915#530])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb5/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16080/shard-iclb3/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html

  * 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Inject a cond_resched() into long drm_clflush_sg()

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm: Inject a cond_resched() into long drm_clflush_sg()
URL   : https://patchwork.freedesktop.org/series/72085/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
f1c4f0dc10f6 drm: Inject a cond_resched() into long drm_clflush_sg()
-:41: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#41: FILE: drivers/gpu/drm/drm_cache.c:124:
+   s.max = s.curr = s.sgp->offset;

-:62: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__iter' - possible 
side-effects?
#62: FILE: drivers/gpu/drm/drm_cache.c:145:
+#define for_each_sgt_page(__pp, __iter, __sgt) \
+   for ((__iter) = __sgt_iter((__sgt)->sgl);   \
+((__pp) = (__iter).pfn == 0 ? NULL :   \
+ pfn_to_page((__iter).pfn + ((__iter).curr >> PAGE_SHIFT))); \
+(((__iter).curr += PAGE_SIZE) >= (__iter).max) ?   \
+(__iter) = __sgt_iter(__sg_next_resched((__iter).sgp)), 0 : 0)

total: 0 errors, 0 warnings, 2 checks, 68 lines checked

___
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/guc: Update to GuC FW v40 (rev2)

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915/guc: Update to GuC FW v40 (rev2)
URL   : https://patchwork.freedesktop.org/series/72032/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7751 -> Patchwork_16117


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_parallel@basic:
- fi-tgl-y:   [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar 
issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-tgl-y/igt@gem_exec_paral...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16117/fi-tgl-y/igt@gem_exec_paral...@basic.html

  * igt@gem_exec_suspend@basic-s3:
- fi-cml-s:   [PASS][3] -> [DMESG-WARN][4] ([fdo#111764])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-cml-s/igt@gem_exec_susp...@basic-s3.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16117/fi-cml-s/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_selftest@live_blt:
- fi-hsw-4770:[PASS][5] -> [DMESG-FAIL][6] ([i915#725])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-hsw-4770/igt@i915_selftest@live_blt.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16117/fi-hsw-4770/igt@i915_selftest@live_blt.html

  * igt@i915_selftest@live_execlists:
- fi-apl-guc: [PASS][7] -> [TIMEOUT][8] ([fdo#112271] / [i915#529])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-apl-guc/igt@i915_selftest@live_execlists.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16117/fi-apl-guc/igt@i915_selftest@live_execlists.html

  
 Possible fixes 

  * igt@gem_close_race@basic-threads:
- fi-byt-j1900:   [TIMEOUT][9] ([fdo#112271] / [i915#816]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16117/fi-byt-j1900/igt@gem_close_r...@basic-threads.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-cfl-8700k:   [DMESG-WARN][11] ([i915#889]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-cfl-8700k/igt@i915_module_l...@reload-with-fault-injection.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16117/fi-cfl-8700k/igt@i915_module_l...@reload-with-fault-injection.html
- fi-skl-6770hq:  [DMESG-WARN][13] ([i915#889]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-skl-6770hq/igt@i915_module_l...@reload-with-fault-injection.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16117/fi-skl-6770hq/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_selftest@live_execlists:
- fi-kbl-soraka:  [DMESG-FAIL][15] ([i915#656]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-kbl-soraka/igt@i915_selftest@live_execlists.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16117/fi-kbl-soraka/igt@i915_selftest@live_execlists.html

  * igt@prime_self_import@basic-llseek-size:
- fi-tgl-y:   [DMESG-WARN][17] ([i915#402]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-tgl-y/igt@prime_self_imp...@basic-llseek-size.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16117/fi-tgl-y/igt@prime_self_imp...@basic-llseek-size.html

  
 Warnings 

  * igt@i915_pm_rpm@basic-rte:
- fi-kbl-guc: [SKIP][19] ([fdo#109271]) -> [FAIL][20] ([i915#579])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16117/fi-kbl-guc/igt@i915_pm_...@basic-rte.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [INCOMPLETE][21] ([i915#151]) -> [FAIL][22] 
([i915#178])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16117/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111764]: https://bugs.freedesktop.org/show_bug.cgi?id=111764
  [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
  [i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151
  [i915#178]: https://gitlab.freedesktop.org/drm/intel/issues/178
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#529]: https://gitlab.freedesktop.org/drm/intel/issues/529
  

[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915/guc: Update to GuC FW v40 (rev2)

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915/guc: Update to GuC FW v40 (rev2)
URL   : https://patchwork.freedesktop.org/series/72032/
State : warning

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 122 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:93: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1282: recipe for target 'modules' failed
make: *** [modules] Error 2

== Logs ==

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


[Intel-gfx] [PATCH] drm/i915/dsi: Lookup the i2c bus from ACPI NS only if CONFIG_ACPI=y (v3)

2020-01-15 Thread Vivek Kasireddy
Perform the i2c bus/adapter lookup from ACPI Namespace only if
ACPI is enabled in the kernel config. If ACPI is not enabled or if
the lookup fails, we'll fallback to using the VBT for identiying
the i2c bus.

v2: Clearly identify the commit this patch is fixing (Jani)

v3: Remove the i2c_bus_num >= 0 check from the adapter lookup function
as this would prevent ACPI bus number override. This check was mainly
there to return early if the bus number has already been found but we
anyway return in the next line if the slave address does not match.

Fixes: 8cbf89db2941 ("drm/i915/dsi: Parse the I2C element from the VBT MIPI 
sequence block (v3)")
Cc: Hans de Goede 
Cc: Nabendu Maiti 
Cc: Matt Roper 
Cc: Bob Paauwe 
Cc: Ville Syrjälä 
Cc: Jani Nikula 
Cc: Zhang Xiaoxu 
Reported-by: Hulk Robot 
Signed-off-by: Vivek Kasireddy 
---
 drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 50 +---
 1 file changed, 32 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c 
b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
index 89fb0d90b694..04f953ba8f00 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
@@ -384,6 +384,7 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
return data;
 }
 
+#ifdef CONFIG_ACPI
 static int i2c_adapter_lookup(struct acpi_resource *ares, void *data)
 {
struct i2c_adapter_lookup *lookup = data;
@@ -393,8 +394,7 @@ static int i2c_adapter_lookup(struct acpi_resource *ares, 
void *data)
acpi_handle adapter_handle;
acpi_status status;
 
-   if (intel_dsi->i2c_bus_num >= 0 ||
-   !i2c_acpi_get_i2c_resource(ares, ))
+   if (!i2c_acpi_get_i2c_resource(ares, ))
return 1;
 
if (lookup->slave_addr != sb->slave_address)
@@ -413,14 +413,41 @@ static int i2c_adapter_lookup(struct acpi_resource *ares, 
void *data)
return 1;
 }
 
-static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, const u8 *data)
+static void i2c_acpi_find_adapter(struct intel_dsi *intel_dsi,
+ const u16 slave_addr)
 {
struct drm_device *drm_dev = intel_dsi->base.base.dev;
struct device *dev = _dev->pdev->dev;
-   struct i2c_adapter *adapter;
struct acpi_device *acpi_dev;
struct list_head resource_list;
struct i2c_adapter_lookup lookup;
+
+   acpi_dev = ACPI_COMPANION(dev);
+   if (acpi_dev) {
+   memset(, 0, sizeof(lookup));
+   lookup.slave_addr = slave_addr;
+   lookup.intel_dsi = intel_dsi;
+   lookup.dev_handle = acpi_device_handle(acpi_dev);
+
+   INIT_LIST_HEAD(_list);
+   acpi_dev_get_resources(acpi_dev, _list,
+  i2c_adapter_lookup,
+  );
+   acpi_dev_free_resource_list(_list);
+   }
+}
+#else
+static inline void i2c_acpi_find_adapter(struct intel_dsi *intel_dsi,
+const u16 slave_addr)
+{
+}
+#endif
+
+static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, const u8 *data)
+{
+   struct drm_device *drm_dev = intel_dsi->base.base.dev;
+   struct device *dev = _dev->pdev->dev;
+   struct i2c_adapter *adapter;
struct i2c_msg msg;
int ret;
u8 vbt_i2c_bus_num = *(data + 2);
@@ -431,20 +458,7 @@ static const u8 *mipi_exec_i2c(struct intel_dsi 
*intel_dsi, const u8 *data)
 
if (intel_dsi->i2c_bus_num < 0) {
intel_dsi->i2c_bus_num = vbt_i2c_bus_num;
-
-   acpi_dev = ACPI_COMPANION(dev);
-   if (acpi_dev) {
-   memset(, 0, sizeof(lookup));
-   lookup.slave_addr = slave_addr;
-   lookup.intel_dsi = intel_dsi;
-   lookup.dev_handle = acpi_device_handle(acpi_dev);
-
-   INIT_LIST_HEAD(_list);
-   acpi_dev_get_resources(acpi_dev, _list,
-  i2c_adapter_lookup,
-  );
-   acpi_dev_free_resource_list(_list);
-   }
+   i2c_acpi_find_adapter(intel_dsi, slave_addr);
}
 
adapter = i2c_get_adapter(intel_dsi->i2c_bus_num);
-- 
2.21.1

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


[Intel-gfx] [PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()

2020-01-15 Thread Chris Wilson
Since we may try and flush the cachelines associated with large buffers
(an 8K framebuffer is about 128MiB, even before we try HDR), this leads
to unacceptably long latencies (when using a voluntary CONFIG_PREEMPT).
If we call cond_resched() between each sg chunk, that it about every 128
pages, we have a natural break point in which to check if the process
needs to be rescheduled. Naturally, this means that drm_clflush_sg() can
only be called from process context -- which is true at the moment. The
other clflush routines remain usable from atomic context.

Even though flushing large objects takes a demonstrable amount to time
to flush all the cachelines, clflush is still preferred over a
system-wide wbinvd as the latter has unpredictable latencies affecting
the whole system not just the local task.

Reported-by: David Laight 
Signed-off-by: Chris Wilson 
Cc: David Laight 
---
 drivers/gpu/drm/drm_cache.c | 49 ++---
 1 file changed, 45 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 03e01b000f7a..fbd2bb644544 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -112,23 +112,64 @@ drm_clflush_pages(struct page *pages[], unsigned long 
num_pages)
 }
 EXPORT_SYMBOL(drm_clflush_pages);
 
+static __always_inline struct sgt_iter {
+   struct scatterlist *sgp;
+   unsigned long pfn;
+   unsigned int curr;
+   unsigned int max;
+} __sgt_iter(struct scatterlist *sgl) {
+   struct sgt_iter s = { .sgp = sgl };
+
+   if (s.sgp) {
+   s.max = s.curr = s.sgp->offset;
+   s.max += s.sgp->length;
+   s.pfn = page_to_pfn(sg_page(s.sgp));
+   }
+
+   return s;
+}
+
+static inline struct scatterlist *__sg_next_resched(struct scatterlist *sg)
+{
+   if (sg_is_last(sg))
+   return NULL;
+
+   ++sg;
+   if (unlikely(sg_is_chain(sg))) {
+   sg = sg_chain_ptr(sg);
+   cond_resched();
+   }
+   return sg;
+}
+
+#define for_each_sgt_page(__pp, __iter, __sgt) \
+   for ((__iter) = __sgt_iter((__sgt)->sgl);   \
+((__pp) = (__iter).pfn == 0 ? NULL :   \
+ pfn_to_page((__iter).pfn + ((__iter).curr >> PAGE_SHIFT))); \
+(((__iter).curr += PAGE_SIZE) >= (__iter).max) ?   \
+(__iter) = __sgt_iter(__sg_next_resched((__iter).sgp)), 0 : 0)
+
 /**
  * drm_clflush_sg - Flush dcache lines pointing to a scather-gather.
  * @st: struct sg_table.
  *
  * Flush every data cache line entry that points to an address in the
- * sg.
+ * sg. This may schedule between scatterlist chunks, in order to keep
+ * the system preemption-latency down for large buffers.
  */
 void
 drm_clflush_sg(struct sg_table *st)
 {
+   might_sleep();
+
 #if defined(CONFIG_X86)
if (static_cpu_has(X86_FEATURE_CLFLUSH)) {
-   struct sg_page_iter sg_iter;
+   struct sgt_iter sg_iter;
+   struct page *page;
 
mb(); /*CLFLUSH is ordered only by using memory barriers*/
-   for_each_sg_page(st->sgl, _iter, st->nents, 0)
-   drm_clflush_page(sg_page_iter_page(_iter));
+   for_each_sgt_page(page, sg_iter, st)
+   drm_clflush_page(page);
mb(); /*Make sure that all cache line entry is flushed*/
 
return;
-- 
2.25.0

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


Re: [Intel-gfx] [PATCH 0/7] Commit early to GuC

2020-01-15 Thread Daniele Ceraolo Spurio




On 1/15/20 8:18 AM, Chris Wilson wrote:

Quoting Daniele Ceraolo Spurio (2020-01-15 15:57:27)



On 1/15/2020 12:40 AM, Chris Wilson wrote:

Quoting Daniele Ceraolo Spurio (2020-01-15 01:31:36)

We currently wait until we attempt to load the GuC to confirm if we're
in GuC mode or not, at which point a lot of the engine setup has already
happened and needs to be updated for GuC submission. To allow us to get
the setup done directly into GuC mode, we need to commit to using GuC
as soon as possible.

I think this is the wrong direction; as I thought the goal was to allow
delayed loading of firmware, even going as far as allowing the system to
run a browser for the user to get the firmware first. I may be


We do indeed want to keep supporting execlists mode even as some HW
features move to the GuC to allow the user to get to the binaries, but
we don't want to switch between the 2 modes without a reboot. Switching
between the 2 modes is not a HW capability that we're committed to; the
guc->elsp transition is already not possible, while the elsp->guc one
still seems to work, but who knows for how long it will?

This series is also not really changing the commitment at the
implementation level, just making it "official" and acting based on
that. Even without these patches, if the blobs are on the system we will
attempt to get into GuC mode unless we get an allocation failure or
something similar, in which case it is extremely likely that the
fall-back to non-guc will not work either.


completely wrong about that, but imho I never want to have to build
firmware images into the kernel.


I do 100% agree with this statement, although I'm not sure how this
relates to the series. Are you planning to pull some of the engine setup
to an even earlier point?



The transition from execlists to guc could be just set-wedged; delete
old engines, build guc engines. [This should also work for guc -> guc.]
Throwing away context state is ugly, but simple enough.


As mentioned above, we can't switch between elsp and GuC modes so this
transition would have to be done before the first submission to HW. Why
not go directly in GuC mode then?


So the problem is if we can't freely switch (we can never power down the
guc, that seems unlikely?) then we can't make a decision on which mode


AFAIU it's not the GuC itself that's the issue, but some of the other 
units, some of which outside the GT, that can get locked in one mode 
without being resettable (like what happens for the WOPCM regs for example).



to run (and which engines to initialise) until userspace is active and
has committed to supplying or not supplying a fw image. Which puts us in
a catch-22 of wanting to register the driver with userspace before we
have finalized initialisation.


I think this is the bit I'm missing. Why do you want userspace to 
directly provide the firmware instead of fetching it from /lib/firmware 
like we do now? The distros should pack the correct firmware in their 
linux-firmware packages and it seems reasonable to me to expect the 
system to be rebooted after fetching a binary by hand. We can move the 
fetch to an earlier point in time if we need the info earlier, since it 
does not require the HW to be ready.




If the transition is impossible, it seems like you have no choice but to
require the fw image at initialisation. I do not understand why it has
to be that way, seems such a hindrance.


My understanding from the talk I had with the HW team when we realized 
that the guc->elsp transition was broken on gen11 is that the HW expects 
SW to pick a mode and stick to that. The elsp->guc transition seem to 
still work, but there is no guarantee it will keep doing so in the 
future and therefore it doesn't seem like a good idea to build on that.


Daniele


-Chris


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


[Intel-gfx] [PATCH v2] drm/i915/guc: Update to GuC FW v40

2020-01-15 Thread John . C . Harrison
From: Michal Wajdeczko 

The GuC major version has jumped from 35 to 40. This is because this
FW includes a significant re-write of the API that completely breaks
backwards compatibility for command submission. This patch is
sufficient to enable loading of the GuC and hence authentication of
the HuC. Support of command submission will follow in a much larger
patch series.

The changes required to load v40 FW are:
* An additional data structure and associated 'private_data' pointer
are now required to be setup by the driver. This is basically a
scratch area of memory that the GuC owns. The size is read from the
CSS header.

* A physical to logical engine mapping table is required to be
provided in the GuC additional data structure. This is initialized
with a 1 to 1 mapping.

* GUC_CTL_CTXINFO has been removed from the initialization params.

* The reg_state_buffer has been removed from the GuC ADS.

v2: Folded in removal of reg_state_buffer from Michal.

Signed-off-by: Matthew Brost 
Signed-off-by: John Harrison 
Signed-off-by: Michal Wajdeczko 
CC: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc.c   | 18 
 drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c   | 31 ++--
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h  | 24 +++
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 21 +++--
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h |  2 ++
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h |  6 +++-
 6 files changed, 58 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 5d00a3b2d914..e3ef742aac4a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -213,23 +213,6 @@ static u32 guc_ctl_feature_flags(struct intel_guc *guc)
return flags;
 }
 
-static u32 guc_ctl_ctxinfo_flags(struct intel_guc *guc)
-{
-   u32 flags = 0;
-
-   if (intel_guc_is_submission_supported(guc)) {
-   u32 ctxnum, base;
-
-   base = intel_guc_ggtt_offset(guc, guc->stage_desc_pool);
-   ctxnum = GUC_MAX_STAGE_DESCRIPTORS / 16;
-
-   base >>= PAGE_SHIFT;
-   flags |= (base << GUC_CTL_BASE_ADDR_SHIFT) |
-   (ctxnum << GUC_CTL_CTXNUM_IN16_SHIFT);
-   }
-   return flags;
-}
-
 static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
 {
u32 offset = intel_guc_ggtt_offset(guc, guc->log.vma) >> PAGE_SHIFT;
@@ -291,7 +274,6 @@ static void guc_init_params(struct intel_guc *guc)
 
BUILD_BUG_ON(sizeof(guc->params) != GUC_CTL_MAX_DWORDS * sizeof(u32));
 
-   params[GUC_CTL_CTXINFO] = guc_ctl_ctxinfo_flags(guc);
params[GUC_CTL_LOG_PARAMS] = guc_ctl_log_params_flags(guc);
params[GUC_CTL_FEATURE] = guc_ctl_feature_flags(guc);
params[GUC_CTL_DEBUG] = guc_ctl_debug_flags(guc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 101728006ae9..ba4cf89e6338 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -48,6 +48,20 @@ static void guc_ct_pool_entries_init(struct 
guc_ct_pool_entry *pool, u32 num)
memset(pool, 0, num * sizeof(*pool));
 }
 
+static void guc_mapping_table_init(struct guc_gt_system_info *system_info)
+{
+   unsigned int i, j;
+
+   /*
+* Initializing the physical to logical engine mapping table with a
+* 1 to 1 mapping. This allows the firmware to load on all platforms as
+* all engines are logical exposed to the user.
+*/
+   for (i = 0; i < GUC_MAX_ENGINE_CLASSES; ++i)
+   for (j = 0; j < GUC_MAX_INSTANCES_PER_CLASS; ++j)
+   system_info->mapping_table[i][j] = j;
+}
+
 /*
  * The first 80 dwords of the register state context, containing the
  * execlists and ppgtt registers.
@@ -62,7 +76,6 @@ struct __guc_ads_blob {
struct guc_gt_system_info system_info;
struct guc_clients_info clients_info;
struct guc_ct_pool_entry ct_pool[GUC_CT_POOL_SIZE];
-   u8 reg_state_buffer[GUC_S3_SAVE_SPACE_PAGES * PAGE_SIZE];
 } __packed;
 
 static void __guc_ads_init(struct intel_guc *guc)
@@ -107,6 +120,8 @@ static void __guc_ads_init(struct intel_guc *guc)
blob->system_info.vebox_enable_mask = VEBOX_MASK(dev_priv);
blob->system_info.vdbox_sfc_support_mask = 
RUNTIME_INFO(dev_priv)->vdbox_sfc_access;
 
+   guc_mapping_table_init(>system_info);
+
base = intel_guc_ggtt_offset(guc, guc->ads_vma);
 
/* Clients info  */
@@ -118,11 +133,14 @@ static void __guc_ads_init(struct intel_guc *guc)
 
/* ADS */
blob->ads.scheduler_policies = base + ptr_offset(blob, policies);
-   blob->ads.reg_state_buffer = base + ptr_offset(blob, reg_state_buffer);
blob->ads.reg_state_addr = base + ptr_offset(blob, reg_state);
blob->ads.gt_system_info = base + 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dsi: Fix implicit declaration of function 'acpi_dev*' in 'mipi_exec_i2c'

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915/dsi: Fix implicit declaration of function 'acpi_dev*' in 
'mipi_exec_i2c'
URL   : https://patchwork.freedesktop.org/series/71972/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7735_full -> Patchwork_16079_full


Summary
---

  **FAILURE**

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

### IGT changes ###

 Possible regressions 

  * igt@runner@aborted:
- shard-hsw:  NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16079/shard-hsw5/igt@run...@aborted.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_busy@busy-vcs1:
- shard-iclb: [PASS][2] -> [SKIP][3] ([fdo#112080]) +17 similar 
issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb2/igt@gem_b...@busy-vcs1.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16079/shard-iclb6/igt@gem_b...@busy-vcs1.html

  * igt@gem_ctx_persistence@vcs1-queued:
- shard-iclb: [PASS][4] -> [SKIP][5] ([fdo#109276] / [fdo#112080]) 
+2 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb2/igt@gem_ctx_persiste...@vcs1-queued.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16079/shard-iclb5/igt@gem_ctx_persiste...@vcs1-queued.html

  * igt@gem_exec_await@wide-contexts:
- shard-tglb: [PASS][6] -> [INCOMPLETE][7] ([fdo#111736] / 
[i915#472])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-tglb5/igt@gem_exec_aw...@wide-contexts.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16079/shard-tglb6/igt@gem_exec_aw...@wide-contexts.html

  * igt@gem_exec_parallel@basic:
- shard-tglb: [PASS][8] -> [INCOMPLETE][9] ([i915#472] / [i915#476])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-tglb8/igt@gem_exec_paral...@basic.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16079/shard-tglb9/igt@gem_exec_paral...@basic.html

  * igt@gem_exec_parallel@vcs0:
- shard-tglb: [PASS][10] -> [INCOMPLETE][11] ([fdo#111593] / 
[i915#472])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-tglb5/igt@gem_exec_paral...@vcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16079/shard-tglb4/igt@gem_exec_paral...@vcs0.html

  * igt@gem_exec_reloc@basic-wc-gtt-active:
- shard-skl:  [PASS][12] -> [DMESG-WARN][13] ([i915#109])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-skl7/igt@gem_exec_re...@basic-wc-gtt-active.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16079/shard-skl3/igt@gem_exec_re...@basic-wc-gtt-active.html

  * igt@gem_exec_schedule@pi-shared-iova-bsd:
- shard-iclb: [PASS][14] -> [SKIP][15] ([i915#677]) +1 similar issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb6/igt@gem_exec_sched...@pi-shared-iova-bsd.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16079/shard-iclb2/igt@gem_exec_sched...@pi-shared-iova-bsd.html

  * igt@gem_exec_schedule@reorder-wide-bsd:
- shard-iclb: [PASS][16] -> [SKIP][17] ([fdo#112146]) +5 similar 
issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb3/igt@gem_exec_sched...@reorder-wide-bsd.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16079/shard-iclb2/igt@gem_exec_sched...@reorder-wide-bsd.html

  * igt@gem_exec_schedule@smoketest-all:
- shard-tglb: [PASS][18] -> [INCOMPLETE][19] ([i915#463] / 
[i915#472])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-tglb5/igt@gem_exec_sched...@smoketest-all.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16079/shard-tglb8/igt@gem_exec_sched...@smoketest-all.html

  * igt@gem_exec_suspend@basic-s4-devices:
- shard-tglb: [PASS][20] -> [INCOMPLETE][21] ([i915#460] / 
[i915#472])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-tglb1/igt@gem_exec_susp...@basic-s4-devices.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16079/shard-tglb6/igt@gem_exec_susp...@basic-s4-devices.html

  * 
igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrash-inactive:
- shard-apl:  [PASS][22] -> [TIMEOUT][23] ([fdo#112271] / 
[i915#530])
   [22]: 

Re: [Intel-gfx] [PATCH CI] drm/i915/psr: Share the computation of idle frames

2020-01-15 Thread Matt Roper
On Mon, Jan 13, 2020 at 01:46:03PM -0800, José Roberto de Souza wrote:
> Both activate functions and the dc3co disable function were doing the
> same thing, so better move to a function and share.
> Also while at it adding a WARN_ON to catch invalid values.
> 
> Cc: Anshuman Gupta 
> Cc: Imre Deak 
> Reviewed-by: Anshuman Gupta 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 43 +++-
>  1 file changed, 19 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 89c9cf5f38d2..bd713ca8d5fc 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -454,22 +454,29 @@ static u32 intel_psr1_get_tp_time(struct intel_dp 
> *intel_dp)
>   return val;
>  }
>  
> -static void hsw_activate_psr1(struct intel_dp *intel_dp)
> +static u8 psr_compute_idle_frames(struct intel_dp *intel_dp)
>  {
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> - u32 max_sleep_time = 0x1f;
> - u32 val = EDP_PSR_ENABLE;
> + int idle_frames;
>  
>   /* Let's use 6 as the minimum to cover all known cases including the
>* off-by-one issue that HW has in some cases.
>*/
> - int idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> -
> - /* sink_sync_latency of 8 means source has to wait for more than 8
> -  * frames, we'll go with 9 frames for now
> -  */
> + idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
>   idle_frames = max(idle_frames, dev_priv->psr.sink_sync_latency + 1);
> - val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
> +
> + WARN_ON(idle_frames > 0xf);

Should we clamp the value if the VBT gives us something that's too large
to fit in the register bits?  Seems like

if (WARN_ON(idle_frames > 0xf))
idle_frames = 0xf;

might be better than letting the value spill over into unrelated
parts of the register?

Either way, the changes here maintain the code's current logic, so

Reviewed-by: Matt Roper 


Matt

> +
> + return idle_frames;
> +}
> +
> +static void hsw_activate_psr1(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> + u32 max_sleep_time = 0x1f;
> + u32 val = EDP_PSR_ENABLE;
> +
> + val |= psr_compute_idle_frames(intel_dp) << EDP_PSR_IDLE_FRAME_SHIFT;
>  
>   val |= max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT;
>   if (IS_HASWELL(dev_priv))
> @@ -493,13 +500,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>   u32 val;
>  
> - /* Let's use 6 as the minimum to cover all known cases including the
> -  * off-by-one issue that HW has in some cases.
> -  */
> - int idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> -
> - idle_frames = max(idle_frames, dev_priv->psr.sink_sync_latency + 1);
> - val = idle_frames << EDP_PSR2_IDLE_FRAME_SHIFT;
> + val = psr_compute_idle_frames(intel_dp) << EDP_PSR2_IDLE_FRAME_SHIFT;
>  
>   val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
>   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> @@ -566,16 +567,10 @@ static void tgl_psr2_enable_dc3co(struct 
> drm_i915_private *dev_priv)
>  
>  static void tgl_psr2_disable_dc3co(struct drm_i915_private *dev_priv)
>  {
> - int idle_frames;
> + struct intel_dp *intel_dp = dev_priv->psr.dp;
>  
>   intel_display_power_set_target_dc_state(dev_priv, DC_STATE_EN_UPTO_DC6);
> - /*
> -  * Restore PSR2 idle frame let's use 6 as the minimum to cover all known
> -  * cases including the off-by-one issue that HW has in some cases.
> -  */
> - idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> - idle_frames = max(idle_frames, dev_priv->psr.sink_sync_latency + 1);
> - psr2_program_idle_frames(dev_priv, idle_frames);
> + psr2_program_idle_frames(dev_priv, psr_compute_idle_frames(intel_dp));
>  }
>  
>  static void tgl_dc5_idle_thread(struct work_struct *work)
> -- 
> 2.24.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/guc: Update to GuC FW v40

2020-01-15 Thread John Harrison

On 1/15/2020 11:45, Daniele Ceraolo Spurio wrote:

On 1/14/20 6:40 PM, john.c.harri...@intel.com wrote:

From: Matthew Brost 

The GuC major version has jumped from 35 to 40. This is because this
FW includes a significant re-write of the API that completely breaks
backwards compatibility for command submission. This patch is
sufficient to enable loading of the GuC and hence authentication of
the HuC. Support of command submission will follow in a much larger
patch series.

The changes required to load v40 FW are:
* An additional data structure and associated 'private_data' pointer
are now required to be setup by the driver. This is basically a
scratch area of memory that the GuC owns. The size is read from the
CSS header.

* A physical to logical engine mapping table is required to be
provided in the GuC additional data structure. This is initialized
with a 1 to 1 mapping.

* GUC_CTL_CTXINFO has been removed from the initialization params.



You're missing the removal of ads.reg_state_buffer, which is several 
page of memory we can now save. Michal has floated a patch for that 
internally.


Daniele

Yes, I just noticed that a little earlier. Already in the process of 
squashing it in.


John.

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


[Intel-gfx] ✗ Fi.CI.BUILD: warning for series starting with [1/5] drm/i915: Fix post-fastset modeset check for port sync

2020-01-15 Thread Patchwork
== Series Details ==

Series: series starting with [1/5] drm/i915: Fix post-fastset modeset check for 
port sync
URL   : https://patchwork.freedesktop.org/series/72083/
State : warning

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 122 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:93: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1282: recipe for target 'modules' failed
make: *** [modules] Error 2

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Fix post-fastset modeset check for port sync

2020-01-15 Thread Patchwork
== Series Details ==

Series: series starting with [1/5] drm/i915: Fix post-fastset modeset check for 
port sync
URL   : https://patchwork.freedesktop.org/series/72083/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7751 -> Patchwork_16116


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_parallel@basic:
- 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_7751/fi-tgl-y/igt@gem_exec_paral...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16116/fi-tgl-y/igt@gem_exec_paral...@basic.html

  * igt@gem_exec_suspend@basic-s0:
- fi-cml-s:   [PASS][3] -> [FAIL][4] ([fdo#103375])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-cml-s/igt@gem_exec_susp...@basic-s0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16116/fi-cml-s/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-icl-guc: [PASS][5] -> [DMESG-WARN][6] ([i915#109])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-icl-guc/igt@i915_module_l...@reload-with-fault-injection.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16116/fi-icl-guc/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_selftest@live_blt:
- fi-ivb-3770:[PASS][7] -> [DMESG-FAIL][8] ([i915#563])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-ivb-3770/igt@i915_selftest@live_blt.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16116/fi-ivb-3770/igt@i915_selftest@live_blt.html

  * igt@i915_selftest@live_gem_contexts:
- fi-kbl-x1275:   [PASS][9] -> [INCOMPLETE][10] ([CI#80] / [i915#504])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-kbl-x1275/igt@i915_selftest@live_gem_contexts.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16116/fi-kbl-x1275/igt@i915_selftest@live_gem_contexts.html
- fi-cml-s:   [PASS][11] -> [DMESG-FAIL][12] ([i915#877])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16116/fi-cml-s/igt@i915_selftest@live_gem_contexts.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-dsi: [PASS][13] -> [DMESG-WARN][14] ([i915#109])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-icl-dsi/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16116/fi-icl-dsi/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html

  
 Possible fixes 

  * igt@gem_close_race@basic-threads:
- fi-byt-j1900:   [TIMEOUT][15] ([fdo#112271] / [i915#816]) -> 
[PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16116/fi-byt-j1900/igt@gem_close_r...@basic-threads.html

  * igt@gem_exec_gttfill@basic:
- {fi-ehl-1}: [INCOMPLETE][17] ([i915#937]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-ehl-1/igt@gem_exec_gttf...@basic.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16116/fi-ehl-1/igt@gem_exec_gttf...@basic.html

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

  * igt@i915_module_load@reload-with-fault-injection:
- fi-skl-6770hq:  [DMESG-WARN][21] ([i915#889]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-skl-6770hq/igt@i915_module_l...@reload-with-fault-injection.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16116/fi-skl-6770hq/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [INCOMPLETE][23] ([i915#151]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16116/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [FAIL][25] ([fdo#111096] / [i915#323]) -> [PASS][26]
   [25]: 

Re: [Intel-gfx] [PATCH] drm/i915/guc: Update to GuC FW v40

2020-01-15 Thread Daniele Ceraolo Spurio




On 1/14/20 6:40 PM, john.c.harri...@intel.com wrote:

From: Matthew Brost 

The GuC major version has jumped from 35 to 40. This is because this
FW includes a significant re-write of the API that completely breaks
backwards compatibility for command submission. This patch is
sufficient to enable loading of the GuC and hence authentication of
the HuC. Support of command submission will follow in a much larger
patch series.

The changes required to load v40 FW are:
* An additional data structure and associated 'private_data' pointer
are now required to be setup by the driver. This is basically a
scratch area of memory that the GuC owns. The size is read from the
CSS header.

* A physical to logical engine mapping table is required to be
provided in the GuC additional data structure. This is initialized
with a 1 to 1 mapping.

* GUC_CTL_CTXINFO has been removed from the initialization params.



You're missing the removal of ads.reg_state_buffer, which is several 
page of memory we can now save. Michal has floated a patch for that 
internally.


Daniele


Signed-off-by: Matthew Brost 
Signed-off-by: John Harrison 
CC: Daniele Ceraolo Spurio 
---
  drivers/gpu/drm/i915/gt/uc/intel_guc.c   | 18 
  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c   | 29 +++-
  drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h  | 22 +++
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 21 --
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h |  2 ++
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h |  6 +++-
  6 files changed, 57 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 5d00a3b2d914..e3ef742aac4a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -213,23 +213,6 @@ static u32 guc_ctl_feature_flags(struct intel_guc *guc)
return flags;
  }
  
-static u32 guc_ctl_ctxinfo_flags(struct intel_guc *guc)

-{
-   u32 flags = 0;
-
-   if (intel_guc_is_submission_supported(guc)) {
-   u32 ctxnum, base;
-
-   base = intel_guc_ggtt_offset(guc, guc->stage_desc_pool);
-   ctxnum = GUC_MAX_STAGE_DESCRIPTORS / 16;
-
-   base >>= PAGE_SHIFT;
-   flags |= (base << GUC_CTL_BASE_ADDR_SHIFT) |
-   (ctxnum << GUC_CTL_CTXNUM_IN16_SHIFT);
-   }
-   return flags;
-}
-
  static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
  {
u32 offset = intel_guc_ggtt_offset(guc, guc->log.vma) >> PAGE_SHIFT;
@@ -291,7 +274,6 @@ static void guc_init_params(struct intel_guc *guc)
  
  	BUILD_BUG_ON(sizeof(guc->params) != GUC_CTL_MAX_DWORDS * sizeof(u32));
  
-	params[GUC_CTL_CTXINFO] = guc_ctl_ctxinfo_flags(guc);

params[GUC_CTL_LOG_PARAMS] = guc_ctl_log_params_flags(guc);
params[GUC_CTL_FEATURE] = guc_ctl_feature_flags(guc);
params[GUC_CTL_DEBUG] = guc_ctl_debug_flags(guc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 101728006ae9..1d84cf1d8710 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -48,6 +48,20 @@ static void guc_ct_pool_entries_init(struct 
guc_ct_pool_entry *pool, u32 num)
memset(pool, 0, num * sizeof(*pool));
  }
  
+static void guc_mapping_table_init(struct guc_gt_system_info *system_info)

+{
+   unsigned int i, j;
+
+   /*
+* Initializing the physical to logical engine mapping table with a
+* 1 to 1 mapping. This allows the firmware to load on all platforms as
+* all engines are logical exposed to the user.
+*/
+   for (i = 0; i < GUC_MAX_ENGINE_CLASSES; ++i)
+   for (j = 0; j < GUC_MAX_INSTANCES_PER_CLASS; ++j)
+   system_info->mapping_table[i][j] = j;
+}
+
  /*
   * The first 80 dwords of the register state context, containing the
   * execlists and ppgtt registers.
@@ -107,6 +121,8 @@ static void __guc_ads_init(struct intel_guc *guc)
blob->system_info.vebox_enable_mask = VEBOX_MASK(dev_priv);
blob->system_info.vdbox_sfc_support_mask = 
RUNTIME_INFO(dev_priv)->vdbox_sfc_access;
  
+	guc_mapping_table_init(>system_info);

+
base = intel_guc_ggtt_offset(guc, guc->ads_vma);
  
  	/* Clients info  */

@@ -123,6 +139,10 @@ static void __guc_ads_init(struct intel_guc *guc)
blob->ads.gt_system_info = base + ptr_offset(blob, system_info);
blob->ads.clients_info = base + ptr_offset(blob, clients_info);
  
+	/* Private Data */

+   blob->ads.private_data = base +
+   PAGE_ALIGN(sizeof(struct __guc_ads_blob));
+
i915_gem_object_flush_map(guc->ads_vma->obj);
  }
  
@@ -135,11 +155,13 @@ static void __guc_ads_init(struct intel_guc *guc)

   */
  int intel_guc_ads_create(struct intel_guc *guc)
  {
-   const u32 size = PAGE_ALIGN(sizeof(struct __guc_ads_blob));
+   u32 size = 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: convert to new logging macros based on struct intel_engine_cs.

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915: convert to new logging macros based on struct intel_engine_cs.
URL   : https://patchwork.freedesktop.org/series/71971/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7735_full -> Patchwork_16078_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_busy@busy-vcs1:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +12 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb2/igt@gem_b...@busy-vcs1.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16078/shard-iclb6/igt@gem_b...@busy-vcs1.html

  * igt@gem_ctx_isolation@vecs0-s3:
- shard-iclb: [PASS][3] -> [DMESG-WARN][4] ([fdo#111764])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb4/igt@gem_ctx_isolat...@vecs0-s3.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16078/shard-iclb1/igt@gem_ctx_isolat...@vecs0-s3.html

  * igt@gem_ctx_persistence@vcs1-queued:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276] / [fdo#112080]) 
+2 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb2/igt@gem_ctx_persiste...@vcs1-queued.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16078/shard-iclb8/igt@gem_ctx_persiste...@vcs1-queued.html

  * igt@gem_ctx_shared@q-smoketest-bsd1:
- shard-tglb: [PASS][7] -> [INCOMPLETE][8] ([fdo#111735])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-tglb2/igt@gem_ctx_sha...@q-smoketest-bsd1.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16078/shard-tglb3/igt@gem_ctx_sha...@q-smoketest-bsd1.html

  * igt@gem_exec_await@wide-contexts:
- shard-tglb: [PASS][9] -> [INCOMPLETE][10] ([fdo#111736] / 
[i915#472])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-tglb5/igt@gem_exec_aw...@wide-contexts.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16078/shard-tglb6/igt@gem_exec_aw...@wide-contexts.html

  * igt@gem_exec_parallel@basic:
- shard-tglb: [PASS][11] -> [INCOMPLETE][12] ([i915#472] / 
[i915#476])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-tglb8/igt@gem_exec_paral...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16078/shard-tglb6/igt@gem_exec_paral...@basic.html

  * igt@gem_exec_reuse@single:
- shard-tglb: [PASS][13] -> [INCOMPLETE][14] ([i915#472])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-tglb9/igt@gem_exec_re...@single.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16078/shard-tglb3/igt@gem_exec_re...@single.html

  * igt@gem_exec_schedule@out-order-bsd2:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109276]) +21 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb1/igt@gem_exec_sched...@out-order-bsd2.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16078/shard-iclb6/igt@gem_exec_sched...@out-order-bsd2.html

  * igt@gem_exec_schedule@pi-common-bsd:
- shard-iclb: [PASS][17] -> [SKIP][18] ([i915#677]) +1 similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb6/igt@gem_exec_sched...@pi-common-bsd.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16078/shard-iclb4/igt@gem_exec_sched...@pi-common-bsd.html

  * igt@gem_exec_schedule@preempt-queue-contexts-chain-blt:
- shard-tglb: [PASS][19] -> [INCOMPLETE][20] ([fdo#111606] / 
[fdo#111677] / [i915#472])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-tglb8/igt@gem_exec_sched...@preempt-queue-contexts-chain-blt.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16078/shard-tglb8/igt@gem_exec_sched...@preempt-queue-contexts-chain-blt.html

  * igt@gem_exec_schedule@reorder-wide-bsd:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#112146]) +4 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-iclb3/igt@gem_exec_sched...@reorder-wide-bsd.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16078/shard-iclb2/igt@gem_exec_sched...@reorder-wide-bsd.html

  * igt@gem_exec_suspend@basic-s3:
- shard-tglb: [PASS][23] -> [INCOMPLETE][24] ([fdo#111736] / 
[i915#460] / [i915#472])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7735/shard-tglb4/igt@gem_exec_susp...@basic-s3.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16078/shard-tglb3/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-apl:  [PASS][25] -> [FAIL][26] ([i915#644])
   [25]: 

[Intel-gfx] [PATCH 5/5] drm/i915: Move encoder variable to tighter scope

2020-01-15 Thread Ville Syrjala
From: Ville Syrjälä 

Let's not pollute the function scope with variables when they're
only needed inside some loops.

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

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 97cf8457c956..76c17341df2b 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -13070,7 +13070,6 @@ intel_modeset_pipe_config(struct intel_crtc_state 
*pipe_config)
 {
struct drm_crtc *crtc = pipe_config->uapi.crtc;
struct drm_atomic_state *state = pipe_config->uapi.state;
-   struct intel_encoder *encoder;
struct drm_connector *connector;
struct drm_connector_state *connector_state;
int base_bpp, ret;
@@ -13113,11 +13112,12 @@ intel_modeset_pipe_config(struct intel_crtc_state 
*pipe_config)
   _config->pipe_src_h);
 
for_each_new_connector_in_state(state, connector, connector_state, i) {
+   struct intel_encoder *encoder =
+   to_intel_encoder(connector_state->best_encoder);
+
if (connector_state->crtc != crtc)
continue;
 
-   encoder = to_intel_encoder(connector_state->best_encoder);
-
if (!check_single_encoder_cloning(state, to_intel_crtc(crtc), 
encoder)) {
DRM_DEBUG_KMS("rejecting invalid cloning 
configuration\n");
return -EINVAL;
@@ -13167,6 +13167,9 @@ intel_modeset_pipe_config(struct intel_crtc_state 
*pipe_config)
 * a chance to reject the mode entirely.
 */
for_each_new_connector_in_state(state, connector, connector_state, i) {
+   struct intel_encoder *encoder =
+   to_intel_encoder(connector_state->best_encoder);
+
if (connector_state->crtc != crtc)
continue;
 
@@ -13178,7 +13181,6 @@ intel_modeset_pipe_config(struct intel_crtc_state 
*pipe_config)
return ret;
}
 
-   encoder = to_intel_encoder(connector_state->best_encoder);
ret = encoder->compute_config(encoder, pipe_config,
  connector_state);
if (ret < 0) {
-- 
2.24.1

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


[Intel-gfx] [PATCH 3/5] drm/i915: Prefer to use the pipe to index the ddb entries

2020-01-15 Thread Ville Syrjala
From: Ville Syrjälä 

Let's use the pipe rather than the silly 'i' iterator from
for_each_oldnew_intel_crtc_in_state() for indexing the ddb
entries array. Maybe one day we can assume c99 and hide the
'i' entirely from sight.

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

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index e68af024e13c..64a377d61ce0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15106,15 +15106,17 @@ static void skl_commit_modeset_enables(struct 
intel_atomic_state *state)
int i;
 
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state, 
new_crtc_state, i) {
+   enum pipe pipe = crtc->pipe;
+
if (!new_crtc_state->hw.active)
continue;
 
/* ignore allocations for crtc's that have been turned off. */
if (!needs_modeset(new_crtc_state)) {
-   entries[i] = old_crtc_state->wm.skl.ddb;
-   update_pipes |= BIT(crtc->pipe);
+   entries[pipe] = old_crtc_state->wm.skl.ddb;
+   update_pipes |= BIT(pipe);
} else {
-   modeset_pipes |= BIT(crtc->pipe);
+   modeset_pipes |= BIT(pipe);
}
}
 
@@ -15140,10 +15142,10 @@ static void skl_commit_modeset_enables(struct 
intel_atomic_state *state)
continue;
 
if 
(skl_ddb_allocation_overlaps(_crtc_state->wm.skl.ddb,
-   entries, num_pipes, i))
+   entries, num_pipes, 
pipe))
continue;
 
-   entries[i] = new_crtc_state->wm.skl.ddb;
+   entries[pipe] = new_crtc_state->wm.skl.ddb;
update_pipes &= ~BIT(pipe);
 
intel_update_crtc(crtc, state, old_crtc_state,
@@ -15178,9 +15180,9 @@ static void skl_commit_modeset_enables(struct 
intel_atomic_state *state)
continue;
 
WARN_ON(skl_ddb_allocation_overlaps(_crtc_state->wm.skl.ddb,
-   entries, num_pipes, i));
+   entries, num_pipes, pipe));
 
-   entries[i] = new_crtc_state->wm.skl.ddb;
+   entries[pipe] = new_crtc_state->wm.skl.ddb;
modeset_pipes &= ~BIT(pipe);
 
if (is_trans_port_sync_mode(new_crtc_state)) {
@@ -15213,9 +15215,9 @@ static void skl_commit_modeset_enables(struct 
intel_atomic_state *state)
continue;
 
WARN_ON(skl_ddb_allocation_overlaps(_crtc_state->wm.skl.ddb,
-   entries, num_pipes, i));
+   entries, num_pipes, pipe));
 
-   entries[i] = new_crtc_state->wm.skl.ddb;
+   entries[pipe] = new_crtc_state->wm.skl.ddb;
modeset_pipes &= ~BIT(pipe);
 
intel_update_crtc(crtc, state, old_crtc_state, new_crtc_state);
-- 
2.24.1

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


[Intel-gfx] [PATCH 1/5] drm/i915: Fix post-fastset modeset check for port sync

2020-01-15 Thread Ville Syrjala
From: Ville Syrjälä 

The post-fastset "does anyone still need a full modeset?" for
port sync looks busted. The outer loop bails out of a full modeset
is still needed by the current crtc which, and then we skip forcing
a full modeset on the related crtcs. That's totally the opposite
of what we want.

The MST path has the logic mostly the other way around so it
looks correct. To fix the port sync case let's follow the MST
logic for both. So, if the current crtc already needs a modeset
we do nothing. otherwise we check if any of the related crtcs
needs a modeset, and if so we force a full modeset for the
current crtc.

And while at let's change the else if to a plain if to so
we don't have needless coupling between the MST and port sync
checks.

Cc: José Roberto de Souza 
Cc: Manasi Navare 
Fixes: 05a8e45136ca ("drm/i915/display: Use external dependency loop for port 
sync")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 43 
 1 file changed, 17 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index dd03987cc24f..b397816ce253 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14469,37 +14469,23 @@ static int intel_atomic_check_crtcs(struct 
intel_atomic_state *state)
return 0;
 }
 
-static bool intel_cpu_transcoder_needs_modeset(struct intel_atomic_state 
*state,
-  enum transcoder transcoder)
+static bool intel_cpu_transcoders_need_modeset(struct intel_atomic_state 
*state,
+  u8 transcoders)
 {
-   struct intel_crtc_state *new_crtc_state;
+   const struct intel_crtc_state *new_crtc_state;
struct intel_crtc *crtc;
int i;
 
-   for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
-   if (new_crtc_state->cpu_transcoder == transcoder)
-   return needs_modeset(new_crtc_state);
+   for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
+   if (new_crtc_state->hw.enable &&
+   transcoders & BIT(new_crtc_state->cpu_transcoder) &&
+   needs_modeset(new_crtc_state))
+   return true;
+   }
 
return false;
 }
 
-static void
-intel_modeset_synced_crtcs(struct intel_atomic_state *state,
-  u8 transcoders)
-{
-   struct intel_crtc_state *new_crtc_state;
-   struct intel_crtc *crtc;
-   int i;
-
-   for_each_new_intel_crtc_in_state(state, crtc,
-new_crtc_state, i) {
-   if (transcoders & BIT(new_crtc_state->cpu_transcoder)) {
-   new_crtc_state->uapi.mode_changed = true;
-   new_crtc_state->update_pipe = false;
-   }
-   }
-}
-
 static int
 intel_modeset_all_tiles(struct intel_atomic_state *state, int tile_grp_id)
 {
@@ -14655,15 +14641,20 @@ static int intel_atomic_check(struct drm_device *dev,
if (intel_dp_mst_is_slave_trans(new_crtc_state)) {
enum transcoder master = 
new_crtc_state->mst_master_transcoder;
 
-   if (intel_cpu_transcoder_needs_modeset(state, master)) {
+   if (intel_cpu_transcoders_need_modeset(state, 
BIT(master))) {
new_crtc_state->uapi.mode_changed = true;
new_crtc_state->update_pipe = false;
}
-   } else if (is_trans_port_sync_mode(new_crtc_state)) {
+   }
+
+   if (is_trans_port_sync_mode(new_crtc_state)) {
u8 trans = new_crtc_state->sync_mode_slaves_mask |
   BIT(new_crtc_state->master_transcoder);
 
-   intel_modeset_synced_crtcs(state, trans);
+   if (intel_cpu_transcoders_need_modeset(state, trans)) {
+   new_crtc_state->uapi.mode_changed = true;
+   new_crtc_state->update_pipe = false;
+   }
}
}
 
-- 
2.24.1

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


[Intel-gfx] [PATCH 2/5] drm/i915: Clear most of crtc state when disabling the crtc

2020-01-15 Thread Ville Syrjala
From: Ville Syrjälä 

Currently we don't call intel_crtc_prepare_cleared_state() for crtcs
that are going to be entirely disabled (uapi.enable==false). That
means such crtcs will leave state junk lying around in their states
and we have to sprinkle hw.enable checks all over before we can
look at the states. Let's change that a bit so that we aways do
the state clearing, even for fully disabled crtcs.

Note that we still keep some parts of the old state (see
intel_crtc_prepare_cleared_state() for the details) so probably
can't trust things 100% when hw.enable==false. But at least there's
less chance now that we end up looking at stale junk.

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

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index b397816ce253..e68af024e13c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14607,15 +14607,13 @@ static int intel_atomic_check(struct drm_device *dev,
continue;
}
 
-   if (!new_crtc_state->uapi.enable) {
-   intel_crtc_copy_uapi_to_hw_state(new_crtc_state);
-   continue;
-   }
-
ret = intel_crtc_prepare_cleared_state(new_crtc_state);
if (ret)
goto fail;
 
+   if (!new_crtc_state->hw.enable)
+   continue;
+
ret = intel_modeset_pipe_config(new_crtc_state);
if (ret)
goto fail;
-- 
2.24.1

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


[Intel-gfx] [PATCH 4/5] drm/i915: Use PIPE_CONF_CHECK_X() for sync_mode_slaves_mask

2020-01-15 Thread Ville Syrjala
From: Ville Syrjälä 

sync_mode_slaves_mask is a bitmask so use PIPE_CONF_CHECK_X() for it
so we get the mismatch printed in hex instead of decimal.

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

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 64a377d61ce0..97cf8457c956 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -13695,7 +13695,7 @@ intel_pipe_config_compare(const struct intel_crtc_state 
*current_config,
PIPE_CONF_CHECK_INFOFRAME(hdmi);
PIPE_CONF_CHECK_INFOFRAME(drm);
 
-   PIPE_CONF_CHECK_I(sync_mode_slaves_mask);
+   PIPE_CONF_CHECK_X(sync_mode_slaves_mask);
PIPE_CONF_CHECK_I(master_transcoder);
 
PIPE_CONF_CHECK_I(dsc.compression_enable);
-- 
2.24.1

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Leave resetting ring to intel_ring

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915/execlists: Leave resetting ring to intel_ring
URL   : https://patchwork.freedesktop.org/series/72082/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7751 -> Patchwork_16115


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- fi-cml-s:   [PASS][1] -> [DMESG-WARN][2] ([fdo#111764])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-cml-s/igt@gem_exec_susp...@basic-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16115/fi-cml-s/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-skl-lmem:[PASS][3] -> [INCOMPLETE][4] ([i915#671])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-skl-lmem/igt@i915_module_l...@reload-with-fault-injection.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16115/fi-skl-lmem/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_selftest@live_blt:
- fi-hsw-4770:[PASS][5] -> [DMESG-FAIL][6] ([i915#725])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-hsw-4770/igt@i915_selftest@live_blt.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16115/fi-hsw-4770/igt@i915_selftest@live_blt.html

  * igt@i915_selftest@live_gt_heartbeat:
- fi-bsw-n3050:   [PASS][7] -> [DMESG-FAIL][8] ([i915#541])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-bsw-n3050/igt@i915_selftest@live_gt_heartbeat.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16115/fi-bsw-n3050/igt@i915_selftest@live_gt_heartbeat.html

  * igt@kms_addfb_basic@bad-pitch-32:
- fi-tgl-y:   [PASS][9] -> [DMESG-WARN][10] ([i915#402]) +1 similar 
issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-tgl-y/igt@kms_addfb_ba...@bad-pitch-32.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16115/fi-tgl-y/igt@kms_addfb_ba...@bad-pitch-32.html

  
 Possible fixes 

  * igt@gem_close_race@basic-threads:
- fi-byt-j1900:   [TIMEOUT][11] ([fdo#112271] / [i915#816]) -> 
[PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16115/fi-byt-j1900/igt@gem_close_r...@basic-threads.html

  * igt@gem_exec_gttfill@basic:
- {fi-ehl-1}: [INCOMPLETE][13] ([i915#937]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-ehl-1/igt@gem_exec_gttf...@basic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16115/fi-ehl-1/igt@gem_exec_gttf...@basic.html

  * 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_7751/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16115/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-cfl-8700k:   [DMESG-WARN][17] ([i915#889]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-cfl-8700k/igt@i915_module_l...@reload-with-fault-injection.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16115/fi-cfl-8700k/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [INCOMPLETE][19] ([i915#151]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16115/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live_execlists:
- fi-kbl-soraka:  [DMESG-FAIL][21] ([i915#656]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-kbl-soraka/igt@i915_selftest@live_execlists.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16115/fi-kbl-soraka/igt@i915_selftest@live_execlists.html

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

  [fdo#111764]: https://bugs.freedesktop.org/show_bug.cgi?id=111764
  [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
  [i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541
  [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656

[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915/execlists: Leave resetting ring to intel_ring

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915/execlists: Leave resetting ring to intel_ring
URL   : https://patchwork.freedesktop.org/series/72082/
State : warning

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 122 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:93: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1282: recipe for target 'modules' failed
make: *** [modules] Error 2

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/execlists: Leave resetting ring to intel_ring

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915/execlists: Leave resetting ring to intel_ring
URL   : https://patchwork.freedesktop.org/series/72082/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
d1f45157e453 drm/i915/execlists: Leave resetting ring to intel_ring
-:14: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#14: 
References: 0725d9a31869 ("drm/i915/gt: Make intel_ring_unpin() safe for 
concurrent pint")

-:14: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 0725d9a31869 ("drm/i915/gt: Make 
intel_ring_unpin() safe for concurrent pint")'
#14: 
References: 0725d9a31869 ("drm/i915/gt: Make intel_ring_unpin() safe for 
concurrent pint")

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

___
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: Align engine->uabi_class/instance with i915_drm.h

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915: Align engine->uabi_class/instance with i915_drm.h
URL   : https://patchwork.freedesktop.org/series/72078/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7751 -> Patchwork_16114


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_param@basic-default:
- 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_7751/fi-tgl-y/igt@gem_ctx_pa...@basic-default.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16114/fi-tgl-y/igt@gem_ctx_pa...@basic-default.html

  * igt@gem_exec_suspend@basic-s3:
- fi-cml-s:   [PASS][3] -> [DMESG-WARN][4] ([fdo#111764])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-cml-s/igt@gem_exec_susp...@basic-s3.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16114/fi-cml-s/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-glk-dsi: [PASS][5] -> [INCOMPLETE][6] ([i915#58] / 
[k.org#198133])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-glk-dsi/igt@i915_module_l...@reload-with-fault-injection.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16114/fi-glk-dsi/igt@i915_module_l...@reload-with-fault-injection.html

  
 Possible fixes 

  * igt@gem_exec_gttfill@basic:
- {fi-ehl-1}: [INCOMPLETE][7] ([i915#937]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-ehl-1/igt@gem_exec_gttf...@basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16114/fi-ehl-1/igt@gem_exec_gttf...@basic.html

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

  * igt@i915_module_load@reload-with-fault-injection:
- fi-cfl-8700k:   [DMESG-WARN][11] ([i915#889]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-cfl-8700k/igt@i915_module_l...@reload-with-fault-injection.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16114/fi-cfl-8700k/igt@i915_module_l...@reload-with-fault-injection.html
- fi-skl-6770hq:  [DMESG-WARN][13] ([i915#889]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-skl-6770hq/igt@i915_module_l...@reload-with-fault-injection.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16114/fi-skl-6770hq/igt@i915_module_l...@reload-with-fault-injection.html
- fi-skl-6600u:   [DMESG-WARN][15] ([i915#889]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-skl-6600u/igt@i915_module_l...@reload-with-fault-injection.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16114/fi-skl-6600u/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq:  [INCOMPLETE][17] ([i915#151]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16114/fi-skl-6770hq/igt@i915_pm_...@module-reload.html

  
 Warnings 

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-icl-u2:  [DMESG-WARN][19] ([IGT#4] / [i915#263]) -> [FAIL][20] 
([i915#217])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7751/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16114/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html

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

  [IGT#4]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/4
  [fdo#111764]: https://bugs.freedesktop.org/show_bug.cgi?id=111764
  [i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151
  [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
  [i915#263]: https://gitlab.freedesktop.org/drm/intel/issues/263
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#58]: https://gitlab.freedesktop.org/drm/intel/issues/58
  [i915#889]: https://gitlab.freedesktop.org/drm/intel/issues/889
  [i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937
  [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133



[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915: Align engine->uabi_class/instance with i915_drm.h

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915: Align engine->uabi_class/instance with i915_drm.h
URL   : https://patchwork.freedesktop.org/series/72078/
State : warning

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 122 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:93: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1282: recipe for target 'modules' failed
make: *** [modules] Error 2

== Logs ==

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


[Intel-gfx] [PATCH] drm/i915/execlists: Leave resetting ring to intel_ring

2020-01-15 Thread Chris Wilson
We need to allow concurrent intel_context_unpin, which means avoiding
doing destructive operations like intel_ring_reset(). This was already
fixed for intel_ring_unpin() in commit 0725d9a31869 ("drm/i915/gt: Make
intel_ring_unpin() safe for concurrent pint"), but I overlooked that
execlists_context_unpin() also made the same mistake.

Reported-by: Matthew Brost 
Fixes: 841350223816 ("drm/i915/gt: Drop mutex serialisation between context 
pin/unpin")
References: 0725d9a31869 ("drm/i915/gt: Make intel_ring_unpin() safe for 
concurrent pint")
Signed-off-by: Chris Wilson 
Cc: Matthew Brost 
Cc: Matthew Auld 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_lrc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index a8fe2f16c910..999fe82190da 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2532,7 +2532,6 @@ static void execlists_context_unpin(struct intel_context 
*ce)
  ce->engine);
 
i915_gem_object_unpin_map(ce->state->obj);
-   intel_ring_reset(ce->ring, ce->ring->tail);
 }
 
 static void
-- 
2.25.0

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


Re: [Intel-gfx] ✗ Fi.CI.BUILD: warning for Enable second DBuf slice for ICL and TGL (rev13)

2020-01-15 Thread Arkadiusz Hiler
On Wed, Jan 15, 2020 at 05:49:42PM +0200, Lisovskiy, Stanislav wrote:
> There is some kind of build failure happening with all recent series:
> 
> 
> CALLscripts/checksyscalls.sh
>   CALLscripts/atomic/check-atomics.sh
>   CHK include/generated/compile.h
> Kernel: arch/x86/boot/bzImage is ready  (#1)
>   Building modules, stage 2.
>   MODPOST 122 modules
> ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
> scripts/Makefile.modpost:93: recipe for target '__modpost' failed
> make[1]: *** [__modpost] Error 1
> Makefile:1282: recipe for target 'modules' failed
> make: *** [modules] Error 2
> 

this is just the 32bit build failing, fix already on the mailing list
and even probably in:

https://patchwork.freedesktop.org/series/71961/
___
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/tgl: Add Wa_1409825376 to tgl (rev3)

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915/tgl: Add Wa_1409825376 to tgl (rev3)
URL   : https://patchwork.freedesktop.org/series/71853/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7733_full -> Patchwork_16076_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@vcs1-dirty-create:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276] / [fdo#112080]) 
+3 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-iclb2/igt@gem_ctx_isolat...@vcs1-dirty-create.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16076/shard-iclb8/igt@gem_ctx_isolat...@vcs1-dirty-create.html

  * igt@gem_ctx_isolation@vecs0-s3:
- shard-iclb: [PASS][3] -> [DMESG-WARN][4] ([fdo#111764])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-iclb2/igt@gem_ctx_isolat...@vecs0-s3.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16076/shard-iclb8/igt@gem_ctx_isolat...@vecs0-s3.html

  * igt@gem_ctx_shared@q-smoketest-bsd:
- shard-tglb: [PASS][5] -> [INCOMPLETE][6] ([i915#461])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-tglb2/igt@gem_ctx_sha...@q-smoketest-bsd.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16076/shard-tglb6/igt@gem_ctx_sha...@q-smoketest-bsd.html

  * igt@gem_eio@in-flight-contexts-1us:
- shard-snb:  [PASS][7] -> [FAIL][8] ([i915#490])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-snb2/igt@gem_...@in-flight-contexts-1us.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16076/shard-snb2/igt@gem_...@in-flight-contexts-1us.html

  * igt@gem_exec_nop@basic-sequential:
- shard-tglb: [PASS][9] -> [INCOMPLETE][10] ([i915#472])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-tglb2/igt@gem_exec_...@basic-sequential.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16076/shard-tglb8/igt@gem_exec_...@basic-sequential.html

  * igt@gem_exec_reloc@basic-cpu-read-active:
- shard-skl:  [PASS][11] -> [DMESG-WARN][12] ([i915#109])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-skl7/igt@gem_exec_re...@basic-cpu-read-active.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16076/shard-skl10/igt@gem_exec_re...@basic-cpu-read-active.html

  * igt@gem_exec_schedule@pi-distinct-iova-bsd:
- shard-iclb: [PASS][13] -> [SKIP][14] ([i915#677])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-iclb8/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16076/shard-iclb1/igt@gem_exec_sched...@pi-distinct-iova-bsd.html

  * igt@gem_exec_schedule@pi-shared-iova-bsd2:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109276]) +17 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-iclb4/igt@gem_exec_sched...@pi-shared-iova-bsd2.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16076/shard-iclb5/igt@gem_exec_sched...@pi-shared-iova-bsd2.html

  * igt@gem_exec_schedule@preempt-queue-contexts-chain-bsd:
- shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#112146]) +2 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-iclb6/igt@gem_exec_sched...@preempt-queue-contexts-chain-bsd.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16076/shard-iclb4/igt@gem_exec_sched...@preempt-queue-contexts-chain-bsd.html

  * igt@gem_exec_schedule@smoketest-blt:
- shard-tglb: [PASS][19] -> [INCOMPLETE][20] ([i915#470] / 
[i915#472]) +1 similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-tglb5/igt@gem_exec_sched...@smoketest-blt.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16076/shard-tglb6/igt@gem_exec_sched...@smoketest-blt.html

  * igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing:
- shard-iclb: [PASS][21] -> [TIMEOUT][22] ([fdo#112271])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-iclb5/igt@gem_persistent_rel...@forked-interruptible-faulting-reloc-thrashing.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16076/shard-iclb3/igt@gem_persistent_rel...@forked-interruptible-faulting-reloc-thrashing.html

  * igt@gem_sync@basic-each:
- shard-tglb: [PASS][23] -> [INCOMPLETE][24] ([i915#472] / 
[i915#707])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-tglb7/igt@gem_s...@basic-each.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16076/shard-tglb7/igt@gem_s...@basic-each.html

  * igt@kms_busy@basic-flip-pipe-a:
- shard-kbl:  [PASS][25] -> 

[Intel-gfx] ✗ Fi.CI.BUILD: warning for Enable second DBuf slice for ICL and TGL (rev14)

2020-01-15 Thread Patchwork
== Series Details ==

Series: Enable second DBuf slice for ICL and TGL (rev14)
URL   : https://patchwork.freedesktop.org/series/70059/
State : warning

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 122 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:93: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1282: recipe for target 'modules' failed
make: *** [modules] Error 2

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable second DBuf slice for ICL and TGL (rev14)

2020-01-15 Thread Patchwork
== Series Details ==

Series: Enable second DBuf slice for ICL and TGL (rev14)
URL   : https://patchwork.freedesktop.org/series/70059/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7750 -> Patchwork_16113


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@runner@aborted:
- fi-whl-u:   NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16113/fi-whl-u/igt@run...@aborted.html
- fi-bxt-dsi: NOTRUN -> [FAIL][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16113/fi-bxt-dsi/igt@run...@aborted.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_close_race@basic-threads:
- fi-byt-j1900:   [PASS][3] -> [TIMEOUT][4] ([fdo#112271] / [i915#816])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7750/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16113/fi-byt-j1900/igt@gem_close_r...@basic-threads.html

  * igt@i915_selftest@live_blt:
- fi-hsw-4770:[PASS][5] -> [DMESG-FAIL][6] ([i915#553] / [i915#725])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7750/fi-hsw-4770/igt@i915_selftest@live_blt.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16113/fi-hsw-4770/igt@i915_selftest@live_blt.html

  * igt@vgem_basic@second-client:
- fi-tgl-y:   [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +1 similar 
issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7750/fi-tgl-y/igt@vgem_ba...@second-client.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16113/fi-tgl-y/igt@vgem_ba...@second-client.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0:
- {fi-ehl-1}: [INCOMPLETE][9] ([i915#937]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7750/fi-ehl-1/igt@gem_exec_susp...@basic-s0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16113/fi-ehl-1/igt@gem_exec_susp...@basic-s0.html

  * igt@kms_addfb_basic@clobberred-modifier:
- fi-tgl-y:   [DMESG-WARN][11] ([i915#402]) -> [PASS][12] +1 
similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7750/fi-tgl-y/igt@kms_addfb_ba...@clobberred-modifier.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16113/fi-tgl-y/igt@kms_addfb_ba...@clobberred-modifier.html

  
 Warnings 

  * igt@i915_selftest@live_blt:
- fi-hsw-4770r:   [DMESG-FAIL][13] ([i915#770]) -> [DMESG-FAIL][14] 
([i915#725])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7750/fi-hsw-4770r/igt@i915_selftest@live_blt.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16113/fi-hsw-4770r/igt@i915_selftest@live_blt.html

  * igt@runner@aborted:
- fi-cml-s:   [FAIL][15] ([fdo#111764] / [i915#577]) -> [FAIL][16] 
([i915#577])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7750/fi-cml-s/igt@run...@aborted.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16113/fi-cml-s/igt@run...@aborted.html
- fi-kbl-8809g:   [FAIL][17] ([i915#858]) -> [FAIL][18] ([i915#192] / 
[i915#193] / [i915#194])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7750/fi-kbl-8809g/igt@run...@aborted.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16113/fi-kbl-8809g/igt@run...@aborted.html

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

  [fdo#111764]: https://bugs.freedesktop.org/show_bug.cgi?id=111764
  [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
  [i915#192]: https://gitlab.freedesktop.org/drm/intel/issues/192
  [i915#193]: https://gitlab.freedesktop.org/drm/intel/issues/193
  [i915#194]: https://gitlab.freedesktop.org/drm/intel/issues/194
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#553]: https://gitlab.freedesktop.org/drm/intel/issues/553
  [i915#577]: https://gitlab.freedesktop.org/drm/intel/issues/577
  [i915#725]: https://gitlab.freedesktop.org/drm/intel/issues/725
  [i915#770]: https://gitlab.freedesktop.org/drm/intel/issues/770
  [i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816
  [i915#858]: 

Re: [Intel-gfx] [PATCH 02/23] drm/amdgpu: Convert to struct drm_crtc_helper_funcs.get_scanout_position()

2020-01-15 Thread Alex Deucher
On Wed, Jan 15, 2020 at 4:41 AM Thomas Zimmermann  wrote:
>
> Hi
>
> Am 13.01.20 um 19:52 schrieb Alex Deucher:
> > On Fri, Jan 10, 2020 at 4:21 AM Thomas Zimmermann  
> > wrote:
> >>
> >> The callback struct drm_driver.get_scanout_position() is deprecated in
> >> favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
> >> amdgpu over.
> >>
> >
> > I would prefer to just change the signature of
> > amdgpu_display_get_crtc_scanoutpos() to match the new API rather than
> > wrapping it again.
>
> While trying to adapt the siganture, I found that
> amdgpu_display_get_crtc_scanoutpos() requires a flags argument that is
> not mappable to the callback API. That wrapper function is necessary.
>

No worries.  We can clean them up later.  Wrapping is fine.

Alex

> Best regards
> Thomas
>
> >
> > Alex
> >
> >> Signed-off-by: Thomas Zimmermann 
> >> ---
> >>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   | 12 
> >>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   | 11 ---
> >>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |  5 +
> >>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  1 +
> >>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  1 +
> >>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |  1 +
> >>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  1 +
> >>  drivers/gpu/drm/amd/amdgpu/dce_virtual.c  |  1 +
> >>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  3 ++-
> >>  9 files changed, 24 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> >> index 4e699071d144..a1e769d4417d 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> >> @@ -914,3 +914,15 @@ int amdgpu_display_crtc_idx_to_irq_type(struct 
> >> amdgpu_device *adev, int crtc)
> >> return AMDGPU_CRTC_IRQ_NONE;
> >> }
> >>  }
> >> +
> >> +bool amdgpu_crtc_get_scanout_position(struct drm_crtc *crtc,
> >> +   bool in_vblank_irq, int *vpos,
> >> +   int *hpos, ktime_t *stime, ktime_t *etime,
> >> +   const struct drm_display_mode *mode)
> >> +{
> >> +   struct drm_device *dev = crtc->dev;
> >> +   unsigned int pipe = crtc->index;
> >> +
> >> +   return amdgpu_display_get_crtc_scanoutpos(dev, pipe, 0, vpos, hpos,
> >> + stime, etime, mode);
> >> +}
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> >> index 3f6f14ce1511..0749285dd1c7 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> >> @@ -1367,16 +1367,6 @@ int amdgpu_file_to_fpriv(struct file *filp, struct 
> >> amdgpu_fpriv **fpriv)
> >> return 0;
> >>  }
> >>
> >> -static bool
> >> -amdgpu_get_crtc_scanout_position(struct drm_device *dev, unsigned int 
> >> pipe,
> >> -bool in_vblank_irq, int *vpos, int *hpos,
> >> -ktime_t *stime, ktime_t *etime,
> >> -const struct drm_display_mode *mode)
> >> -{
> >> -   return amdgpu_display_get_crtc_scanoutpos(dev, pipe, 0, vpos, hpos,
> >> - stime, etime, mode);
> >> -}
> >> -
> >>  static struct drm_driver kms_driver = {
> >> .driver_features =
> >> DRIVER_USE_AGP | DRIVER_ATOMIC |
> >> @@ -1391,7 +1381,6 @@ static struct drm_driver kms_driver = {
> >> .enable_vblank = amdgpu_enable_vblank_kms,
> >> .disable_vblank = amdgpu_disable_vblank_kms,
> >> .get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
> >> -   .get_scanout_position = amdgpu_get_crtc_scanout_position,
> >> .irq_handler = amdgpu_irq_handler,
> >> .ioctls = amdgpu_ioctls_kms,
> >> .gem_free_object_unlocked = amdgpu_gem_object_free,
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h 
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> >> index eb9975f4decb..37ba07e2feb5 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> >> @@ -612,6 +612,11 @@ void amdgpu_panel_mode_fixup(struct drm_encoder 
> >> *encoder,
> >>  struct drm_display_mode *adjusted_mode);
> >>  int amdgpu_display_crtc_idx_to_irq_type(struct amdgpu_device *adev, int 
> >> crtc);
> >>
> >> +bool amdgpu_crtc_get_scanout_position(struct drm_crtc *crtc,
> >> +   bool in_vblank_irq, int *vpos,
> >> +   int *hpos, ktime_t *stime, ktime_t *etime,
> >> +   const struct drm_display_mode *mode);
> >> +
> >>  /* fbdev layer */
> >>  int amdgpu_fbdev_init(struct amdgpu_device *adev);
> >>  void amdgpu_fbdev_fini(struct amdgpu_device *adev);
> >> diff --git 

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl: Add Wa_1409825376 to tgl (rev2)

2020-01-15 Thread Matt Roper
On Wed, Jan 15, 2020 at 09:35:26AM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/tgl: Add Wa_1409825376 to tgl (rev2)
> URL   : https://patchwork.freedesktop.org/series/71853/
> State : success
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_7714_full -> Patchwork_16046_full
> 
> 
> Summary
> ---
> 
>   **SUCCESS**
> 
>   No regressions found.
> 

Applied to dinq.  Thanks for the patch.

It seems like this patch accidentally got added to the CI queue several
times so the CI system is probably going to spit out "rev3" and "rev5"
results eventually, but the patch itself never changed, so applying it
now based on the clean results here.


Matt

>   
> 
> Known issues
> 
> 
>   Here are the changes found in Patchwork_16046_full that come from known 
> issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@gem_ctx_isolation@rcs0-s3:
> - shard-kbl:  [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +4 
> similar issues
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7714/shard-kbl2/igt@gem_ctx_isolat...@rcs0-s3.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16046/shard-kbl2/igt@gem_ctx_isolat...@rcs0-s3.html
> 
>   * igt@gem_ctx_isolation@vecs0-s3:
> - shard-kbl:  [PASS][3] -> [INCOMPLETE][4] ([fdo#103665])
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7714/shard-kbl7/igt@gem_ctx_isolat...@vecs0-s3.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16046/shard-kbl4/igt@gem_ctx_isolat...@vecs0-s3.html
> 
>   * igt@gem_ctx_shared@q-smoketest-bsd2:
> - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276]) +17 similar 
> issues
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7714/shard-iclb2/igt@gem_ctx_sha...@q-smoketest-bsd2.html
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16046/shard-iclb5/igt@gem_ctx_sha...@q-smoketest-bsd2.html
> 
>   * igt@gem_ctx_shared@q-smoketest-vebox:
> - shard-tglb: [PASS][7] -> [INCOMPLETE][8] ([fdo#111735])
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7714/shard-tglb2/igt@gem_ctx_sha...@q-smoketest-vebox.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16046/shard-tglb4/igt@gem_ctx_sha...@q-smoketest-vebox.html
> 
>   * igt@gem_eio@kms:
> - shard-snb:  [PASS][9] -> [INCOMPLETE][10] ([i915#82])
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7714/shard-snb2/igt@gem_...@kms.html
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16046/shard-snb2/igt@gem_...@kms.html
> - shard-tglb: [PASS][11] -> [INCOMPLETE][12] ([i915#476])
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7714/shard-tglb4/igt@gem_...@kms.html
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16046/shard-tglb1/igt@gem_...@kms.html
> 
>   * igt@gem_exec_parallel@contexts:
> - shard-tglb: [PASS][13] -> [INCOMPLETE][14] ([i915#470] / 
> [i915#472])
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7714/shard-tglb1/igt@gem_exec_paral...@contexts.html
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16046/shard-tglb8/igt@gem_exec_paral...@contexts.html
> 
>   * igt@gem_exec_parallel@vcs1-fds:
> - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#112080]) +9 similar 
> issues
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7714/shard-iclb1/igt@gem_exec_paral...@vcs1-fds.html
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16046/shard-iclb8/igt@gem_exec_paral...@vcs1-fds.html
> 
>   * igt@gem_exec_schedule@in-order-bsd:
> - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#112146]) +4 similar 
> issues
>[17]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7714/shard-iclb7/igt@gem_exec_sched...@in-order-bsd.html
>[18]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16046/shard-iclb4/igt@gem_exec_sched...@in-order-bsd.html
> 
>   * igt@gem_exec_schedule@independent-bsd1:
> - shard-tglb: [PASS][19] -> [INCOMPLETE][20] ([i915#472])
>[19]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7714/shard-tglb6/igt@gem_exec_sched...@independent-bsd1.html
>[20]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16046/shard-tglb3/igt@gem_exec_sched...@independent-bsd1.html
> 
>   * igt@gem_exec_schedule@pi-distinct-iova-bsd:
> - shard-iclb: [PASS][21] -> [SKIP][22] ([i915#677])
>[21]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7714/shard-iclb8/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
>[22]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16046/shard-iclb4/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
> 
>   * igt@gem_exec_suspend@basic-s3:
> - shard-tglb: [PASS][23] -> [INCOMPLETE][24] ([fdo#111736] / 
> [i915#460] / [i915#472])
>[23]: 
> 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable second DBuf slice for ICL and TGL (rev14)

2020-01-15 Thread Patchwork
== Series Details ==

Series: Enable second DBuf slice for ICL and TGL (rev14)
URL   : https://patchwork.freedesktop.org/series/70059/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
3ae5ebdd596a drm/i915: Remove skl_ddl_allocation struct
b0a11bc83b40 drm/i915: Move dbuf slice update to proper place
8f1e0b214049 drm/i915: Manipulate DBuf slices properly
-:382: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#382: FILE: drivers/gpu/drm/i915/intel_pm.c:3662:
+   switch (i) {
+

total: 0 errors, 0 warnings, 1 checks, 352 lines checked
c95f56d70250 drm/i915: Introduce parameterized DBUF_CTL
70cfdb1a187e drm/i915: Correctly map DBUF slices to pipes

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


Re: [Intel-gfx] [PATCH] drm/i915: Align engine->uabi_class/instance with i915_drm.h

2020-01-15 Thread Tvrtko Ursulin



On 15/01/2020 15:35, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2020-01-15 15:28:19)


On 15/01/2020 15:24, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

In our ABI we have defined I915_ENGINE_CLASS_INVALID_NONE and
I915_ENGINE_CLASS_INVALID_VIRTUAL as negative values which creates
implicit coupling with type widths used in, also ABI, struct
i915_engine_class_instance.

When for instance we export engine->uabi_class
I915_ENGINE_CLASS_INVALID_VIRTUAL from our our tracepoints, because the
type of the former is u8 in contrast to u16 defined in the ABI, 254 will
be returned instead of 65534 which userspace would legitimately expect.

Therefore we need to align the type used to store engine ABI class and
instance.

I did not find any other user visible inconsistency apart from the
tracepoints so I think importance of the fix is low.


Alternatives:

1.
Embed struct i915_engine_class_instance in struct intel_engine_cs, but
downside is more churn.


Could do. It would seem to make sense.
  

2.
Only tweak the tracepoints to cast back and forth, but is it possible to
cast from unsigned to signed and get a negative number?

3.
Do nothing, does anyone cares?


It actually changes the value reported by GET_ENGINES for a virtual
engine, right?

engine->uabi_instance is u8, so u16 ci.engine_instance =
engine->uabi_instance is zero extended, not sign extended.

And we did say that is expected to be (u16)-2 already.

So cc:stable


You are correct, yep, was thinking about engine query where it doesn't 
apply but forgot about get_engines where it does.



Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 

Reviewed-by: Chris Wilson 


---
   drivers/gpu/drm/i915/gem/i915_gem_busy.c | 12 ++--
   drivers/gpu/drm/i915/gt/intel_engine_types.h |  4 ++--
   2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_busy.c 
b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
index 3d4f5775a4ba..25235ef630c1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
@@ -9,16 +9,16 @@
   #include "i915_gem_ioctls.h"
   #include "i915_gem_object.h"
   
-static __always_inline u32 __busy_read_flag(u8 id)

+static __always_inline u32 __busy_read_flag(u16 id)
   {
- if (id == (u8)I915_ENGINE_CLASS_INVALID)
+ if (id == (u16)I915_ENGINE_CLASS_INVALID)
   return 0xu;
   
   GEM_BUG_ON(id >= 16);

   return 0x1u << id;
   }
   
-static __always_inline u32 __busy_write_id(u8 id)

+static __always_inline u32 __busy_write_id(u16 id)
   {
   /*
* The uABI guarantees an active writer is also amongst the read
@@ -29,14 +29,14 @@ static __always_inline u32 __busy_write_id(u8 id)
* last_read - hence we always set both read and write busy for
* last_write.
*/
- if (id == (u8)I915_ENGINE_CLASS_INVALID)
+ if (id == (u16)I915_ENGINE_CLASS_INVALID)
   return 0xu;
   
   return (id + 1) | __busy_read_flag(id);

   }
   
   static __always_inline unsigned int

-__busy_set_if_active(const struct dma_fence *fence, u32 (*flag)(u8 id))
+__busy_set_if_active(const struct dma_fence *fence, u32 (*flag)(u16 id))
   {
   const struct i915_request *rq;
   
@@ -57,7 +57,7 @@ __busy_set_if_active(const struct dma_fence *fence, u32 (*flag)(u8 id))

   return 0;
   
   /* Beware type-expansion follies! */

- BUILD_BUG_ON(!typecheck(u8, rq->engine->uabi_class));
+ BUILD_BUG_ON(!typecheck(u16, rq->engine->uabi_class));
   return flag(rq->engine->uabi_class);
   }
   
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h b/drivers/gpu/drm/i915/gt/intel_engine_types.h

index 00287515e7af..350da59e605b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -278,8 +278,8 @@ struct intel_engine_cs {
   u8 class;
   u8 instance;
   
- u8 uabi_class;

- u8 uabi_instance;
+ u16 uabi_class;
+ u16 uabi_instance;


Bah, doesn't this leave us with a u16 hole!


I don't see anything to fill it with. Could expand class and instance to 
u16 as well and see if it has any negative effect on code size. But in a 
separate patch.


Regards,

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


Re: [Intel-gfx] [PATCH 0/7] Commit early to GuC

2020-01-15 Thread Chris Wilson
Quoting Daniele Ceraolo Spurio (2020-01-15 15:57:27)
> 
> 
> On 1/15/2020 12:40 AM, Chris Wilson wrote:
> > Quoting Daniele Ceraolo Spurio (2020-01-15 01:31:36)
> >> We currently wait until we attempt to load the GuC to confirm if we're
> >> in GuC mode or not, at which point a lot of the engine setup has already
> >> happened and needs to be updated for GuC submission. To allow us to get
> >> the setup done directly into GuC mode, we need to commit to using GuC
> >> as soon as possible.
> > I think this is the wrong direction; as I thought the goal was to allow
> > delayed loading of firmware, even going as far as allowing the system to
> > run a browser for the user to get the firmware first. I may be
> 
> We do indeed want to keep supporting execlists mode even as some HW 
> features move to the GuC to allow the user to get to the binaries, but 
> we don't want to switch between the 2 modes without a reboot. Switching 
> between the 2 modes is not a HW capability that we're committed to; the 
> guc->elsp transition is already not possible, while the elsp->guc one 
> still seems to work, but who knows for how long it will?
> 
> This series is also not really changing the commitment at the 
> implementation level, just making it "official" and acting based on 
> that. Even without these patches, if the blobs are on the system we will 
> attempt to get into GuC mode unless we get an allocation failure or 
> something similar, in which case it is extremely likely that the 
> fall-back to non-guc will not work either.
> 
> > completely wrong about that, but imho I never want to have to build
> > firmware images into the kernel.
> 
> I do 100% agree with this statement, although I'm not sure how this 
> relates to the series. Are you planning to pull some of the engine setup 
> to an even earlier point?
> 
> >
> > The transition from execlists to guc could be just set-wedged; delete
> > old engines, build guc engines. [This should also work for guc -> guc.]
> > Throwing away context state is ugly, but simple enough.
> 
> As mentioned above, we can't switch between elsp and GuC modes so this 
> transition would have to be done before the first submission to HW. Why 
> not go directly in GuC mode then?

So the problem is if we can't freely switch (we can never power down the
guc, that seems unlikely?) then we can't make a decision on which mode
to run (and which engines to initialise) until userspace is active and
has committed to supplying or not supplying a fw image. Which puts us in
a catch-22 of wanting to register the driver with userspace before we
have finalized initialisation.

If the transition is impossible, it seems like you have no choice but to
require the fw image at initialisation. I do not understand why it has
to be that way, seems such a hindrance.
-Chris
___
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/gem: Take local vma references for the parser

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915/gem: Take local vma references for the parser
URL   : https://patchwork.freedesktop.org/series/71968/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7733_full -> Patchwork_16074_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_busy@busy-vcs1:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +11 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-iclb1/igt@gem_b...@busy-vcs1.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16074/shard-iclb5/igt@gem_b...@busy-vcs1.html

  * igt@gem_ctx_isolation@vcs1-dirty-create:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [fdo#112080]) 
+3 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-iclb2/igt@gem_ctx_isolat...@vcs1-dirty-create.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16074/shard-iclb8/igt@gem_ctx_isolat...@vcs1-dirty-create.html

  * igt@gem_ctx_isolation@vecs0-s3:
- shard-apl:  [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +2 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-apl2/igt@gem_ctx_isolat...@vecs0-s3.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16074/shard-apl6/igt@gem_ctx_isolat...@vecs0-s3.html

  * igt@gem_ctx_persistence@vcs0-mixed-process:
- shard-tglb: [PASS][7] -> [FAIL][8] ([i915#679])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-tglb3/igt@gem_ctx_persiste...@vcs0-mixed-process.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16074/shard-tglb5/igt@gem_ctx_persiste...@vcs0-mixed-process.html

  * igt@gem_ctx_shared@q-smoketest-bsd:
- shard-tglb: [PASS][9] -> [INCOMPLETE][10] ([i915#461])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-tglb2/igt@gem_ctx_sha...@q-smoketest-bsd.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16074/shard-tglb4/igt@gem_ctx_sha...@q-smoketest-bsd.html

  * igt@gem_exec_await@wide-contexts:
- shard-tglb: [PASS][11] -> [INCOMPLETE][12] ([fdo#111736] / 
[i915#472])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-tglb1/igt@gem_exec_aw...@wide-contexts.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16074/shard-tglb3/igt@gem_exec_aw...@wide-contexts.html

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#110854])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-iclb4/igt@gem_exec_balan...@smoke.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16074/shard-iclb3/igt@gem_exec_balan...@smoke.html

  * igt@gem_exec_create@forked:
- shard-kbl:  [PASS][15] -> [TIMEOUT][16] ([fdo#112271] / 
[i915#940])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-kbl2/igt@gem_exec_cre...@forked.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16074/shard-kbl7/igt@gem_exec_cre...@forked.html

  * igt@gem_exec_nop@basic-sequential:
- shard-tglb: [PASS][17] -> [INCOMPLETE][18] ([i915#472])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-tglb2/igt@gem_exec_...@basic-sequential.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16074/shard-tglb2/igt@gem_exec_...@basic-sequential.html

  * igt@gem_exec_schedule@in-order-bsd:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#112146]) +3 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-iclb8/igt@gem_exec_sched...@in-order-bsd.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16074/shard-iclb1/igt@gem_exec_sched...@in-order-bsd.html

  * igt@gem_exec_schedule@pi-distinct-iova-bsd:
- shard-iclb: [PASS][21] -> [SKIP][22] ([i915#677])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-iclb8/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16074/shard-iclb2/igt@gem_exec_sched...@pi-distinct-iova-bsd.html

  * igt@gem_exec_schedule@preempt-queue-contexts-chain-bsd1:
- shard-tglb: [PASS][23] -> [INCOMPLETE][24] ([fdo#111677] / 
[i915#472]) +1 similar issue
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-tglb5/igt@gem_exec_sched...@preempt-queue-contexts-chain-bsd1.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16074/shard-tglb6/igt@gem_exec_sched...@preempt-queue-contexts-chain-bsd1.html

  * igt@gem_persistent_relocs@forked-faulting-reloc-thrash-inactive:
- shard-apl:  [PASS][25] -> [INCOMPLETE][26] ([fdo#103927] / 
[i915#530])
   [25]: 

Re: [Intel-gfx] [PATCH 0/7] Commit early to GuC

2020-01-15 Thread Daniele Ceraolo Spurio




On 1/15/2020 12:40 AM, Chris Wilson wrote:

Quoting Daniele Ceraolo Spurio (2020-01-15 01:31:36)

We currently wait until we attempt to load the GuC to confirm if we're
in GuC mode or not, at which point a lot of the engine setup has already
happened and needs to be updated for GuC submission. To allow us to get
the setup done directly into GuC mode, we need to commit to using GuC
as soon as possible.

I think this is the wrong direction; as I thought the goal was to allow
delayed loading of firmware, even going as far as allowing the system to
run a browser for the user to get the firmware first. I may be


We do indeed want to keep supporting execlists mode even as some HW 
features move to the GuC to allow the user to get to the binaries, but 
we don't want to switch between the 2 modes without a reboot. Switching 
between the 2 modes is not a HW capability that we're committed to; the 
guc->elsp transition is already not possible, while the elsp->guc one 
still seems to work, but who knows for how long it will?


This series is also not really changing the commitment at the 
implementation level, just making it "official" and acting based on 
that. Even without these patches, if the blobs are on the system we will 
attempt to get into GuC mode unless we get an allocation failure or 
something similar, in which case it is extremely likely that the 
fall-back to non-guc will not work either.



completely wrong about that, but imho I never want to have to build
firmware images into the kernel.


I do 100% agree with this statement, although I'm not sure how this 
relates to the series. Are you planning to pull some of the engine setup 
to an even earlier point?




The transition from execlists to guc could be just set-wedged; delete
old engines, build guc engines. [This should also work for guc -> guc.]
Throwing away context state is ugly, but simple enough.


As mentioned above, we can't switch between elsp and GuC modes so this 
transition would have to be done before the first submission to HW. Why 
not go directly in GuC mode then?


Daniele


-Chris


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


Re: [Intel-gfx] ✗ Fi.CI.BUILD: warning for Enable second DBuf slice for ICL and TGL (rev13)

2020-01-15 Thread Lisovskiy, Stanislav
There is some kind of build failure happening with all recent series:


CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 122 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:93: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1282: recipe for target 'modules' failed
make: *** [modules] Error 2



Best Regards,

Lisovskiy Stanislav

Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo

From: Patchwork 
Sent: Wednesday, January 15, 2020 12:33:22 PM
To: Lisovskiy, Stanislav
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.BUILD: warning for Enable second DBuf slice for ICL and TGL 
(rev13)

== Series Details ==

Series: Enable second DBuf slice for ICL and TGL (rev13)
URL   : https://patchwork.freedesktop.org/series/70059/
State : warning

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 122 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:93: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1282: recipe for target 'modules' failed
make: *** [modules] Error 2

== Logs ==

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


Re: [Intel-gfx] [PATCH] drm/i915: Align engine->uabi_class/instance with i915_drm.h

2020-01-15 Thread Chris Wilson
Quoting Tvrtko Ursulin (2020-01-15 15:28:19)
> 
> On 15/01/2020 15:24, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin 
> > 
> > In our ABI we have defined I915_ENGINE_CLASS_INVALID_NONE and
> > I915_ENGINE_CLASS_INVALID_VIRTUAL as negative values which creates
> > implicit coupling with type widths used in, also ABI, struct
> > i915_engine_class_instance.
> > 
> > When for instance we export engine->uabi_class
> > I915_ENGINE_CLASS_INVALID_VIRTUAL from our our tracepoints, because the
> > type of the former is u8 in contrast to u16 defined in the ABI, 254 will
> > be returned instead of 65534 which userspace would legitimately expect.
> > 
> > Therefore we need to align the type used to store engine ABI class and
> > instance.
> > 
> > I did not find any other user visible inconsistency apart from the
> > tracepoints so I think importance of the fix is low.
> 
> Alternatives:
> 
> 1.
> Embed struct i915_engine_class_instance in struct intel_engine_cs, but 
> downside is more churn.

Could do. It would seem to make sense.
 
> 2.
> Only tweak the tracepoints to cast back and forth, but is it possible to 
> cast from unsigned to signed and get a negative number?
> 
> 3.
> Do nothing, does anyone cares?

It actually changes the value reported by GET_ENGINES for a virtual
engine, right?

engine->uabi_instance is u8, so u16 ci.engine_instance =
engine->uabi_instance is zero extended, not sign extended.

And we did say that is expected to be (u16)-2 already.

So cc:stable

> > Signed-off-by: Tvrtko Ursulin 
> > Cc: Chris Wilson 
Reviewed-by: Chris Wilson 

> > ---
> >   drivers/gpu/drm/i915/gem/i915_gem_busy.c | 12 ++--
> >   drivers/gpu/drm/i915/gt/intel_engine_types.h |  4 ++--
> >   2 files changed, 8 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_busy.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
> > index 3d4f5775a4ba..25235ef630c1 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
> > @@ -9,16 +9,16 @@
> >   #include "i915_gem_ioctls.h"
> >   #include "i915_gem_object.h"
> >   
> > -static __always_inline u32 __busy_read_flag(u8 id)
> > +static __always_inline u32 __busy_read_flag(u16 id)
> >   {
> > - if (id == (u8)I915_ENGINE_CLASS_INVALID)
> > + if (id == (u16)I915_ENGINE_CLASS_INVALID)
> >   return 0xu;
> >   
> >   GEM_BUG_ON(id >= 16);
> >   return 0x1u << id;
> >   }
> >   
> > -static __always_inline u32 __busy_write_id(u8 id)
> > +static __always_inline u32 __busy_write_id(u16 id)
> >   {
> >   /*
> >* The uABI guarantees an active writer is also amongst the read
> > @@ -29,14 +29,14 @@ static __always_inline u32 __busy_write_id(u8 id)
> >* last_read - hence we always set both read and write busy for
> >* last_write.
> >*/
> > - if (id == (u8)I915_ENGINE_CLASS_INVALID)
> > + if (id == (u16)I915_ENGINE_CLASS_INVALID)
> >   return 0xu;
> >   
> >   return (id + 1) | __busy_read_flag(id);
> >   }
> >   
> >   static __always_inline unsigned int
> > -__busy_set_if_active(const struct dma_fence *fence, u32 (*flag)(u8 id))
> > +__busy_set_if_active(const struct dma_fence *fence, u32 (*flag)(u16 id))
> >   {
> >   const struct i915_request *rq;
> >   
> > @@ -57,7 +57,7 @@ __busy_set_if_active(const struct dma_fence *fence, u32 
> > (*flag)(u8 id))
> >   return 0;
> >   
> >   /* Beware type-expansion follies! */
> > - BUILD_BUG_ON(!typecheck(u8, rq->engine->uabi_class));
> > + BUILD_BUG_ON(!typecheck(u16, rq->engine->uabi_class));
> >   return flag(rq->engine->uabi_class);
> >   }
> >   
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
> > b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > index 00287515e7af..350da59e605b 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > @@ -278,8 +278,8 @@ struct intel_engine_cs {
> >   u8 class;
> >   u8 instance;
> >   
> > - u8 uabi_class;
> > - u8 uabi_instance;
> > + u16 uabi_class;
> > + u16 uabi_instance;

Bah, doesn't this leave us with a u16 hole!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Align engine->uabi_class/instance with i915_drm.h

2020-01-15 Thread Tvrtko Ursulin



On 15/01/2020 15:24, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

In our ABI we have defined I915_ENGINE_CLASS_INVALID_NONE and
I915_ENGINE_CLASS_INVALID_VIRTUAL as negative values which creates
implicit coupling with type widths used in, also ABI, struct
i915_engine_class_instance.

When for instance we export engine->uabi_class
I915_ENGINE_CLASS_INVALID_VIRTUAL from our our tracepoints, because the
type of the former is u8 in contrast to u16 defined in the ABI, 254 will
be returned instead of 65534 which userspace would legitimately expect.

Therefore we need to align the type used to store engine ABI class and
instance.

I did not find any other user visible inconsistency apart from the
tracepoints so I think importance of the fix is low.


Alternatives:

1.
Embed struct i915_engine_class_instance in struct intel_engine_cs, but 
downside is more churn.


2.
Only tweak the tracepoints to cast back and forth, but is it possible to 
cast from unsigned to signed and get a negative number?


3.
Do nothing, does anyone cares?

Regards,

Tvrtko


Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
---
  drivers/gpu/drm/i915/gem/i915_gem_busy.c | 12 ++--
  drivers/gpu/drm/i915/gt/intel_engine_types.h |  4 ++--
  2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_busy.c 
b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
index 3d4f5775a4ba..25235ef630c1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
@@ -9,16 +9,16 @@
  #include "i915_gem_ioctls.h"
  #include "i915_gem_object.h"
  
-static __always_inline u32 __busy_read_flag(u8 id)

+static __always_inline u32 __busy_read_flag(u16 id)
  {
-   if (id == (u8)I915_ENGINE_CLASS_INVALID)
+   if (id == (u16)I915_ENGINE_CLASS_INVALID)
return 0xu;
  
  	GEM_BUG_ON(id >= 16);

return 0x1u << id;
  }
  
-static __always_inline u32 __busy_write_id(u8 id)

+static __always_inline u32 __busy_write_id(u16 id)
  {
/*
 * The uABI guarantees an active writer is also amongst the read
@@ -29,14 +29,14 @@ static __always_inline u32 __busy_write_id(u8 id)
 * last_read - hence we always set both read and write busy for
 * last_write.
 */
-   if (id == (u8)I915_ENGINE_CLASS_INVALID)
+   if (id == (u16)I915_ENGINE_CLASS_INVALID)
return 0xu;
  
  	return (id + 1) | __busy_read_flag(id);

  }
  
  static __always_inline unsigned int

-__busy_set_if_active(const struct dma_fence *fence, u32 (*flag)(u8 id))
+__busy_set_if_active(const struct dma_fence *fence, u32 (*flag)(u16 id))
  {
const struct i915_request *rq;
  
@@ -57,7 +57,7 @@ __busy_set_if_active(const struct dma_fence *fence, u32 (*flag)(u8 id))

return 0;
  
  	/* Beware type-expansion follies! */

-   BUILD_BUG_ON(!typecheck(u8, rq->engine->uabi_class));
+   BUILD_BUG_ON(!typecheck(u16, rq->engine->uabi_class));
return flag(rq->engine->uabi_class);
  }
  
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h b/drivers/gpu/drm/i915/gt/intel_engine_types.h

index 00287515e7af..350da59e605b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -278,8 +278,8 @@ struct intel_engine_cs {
u8 class;
u8 instance;
  
-	u8 uabi_class;

-   u8 uabi_instance;
+   u16 uabi_class;
+   u16 uabi_instance;
  
  	u32 uabi_capabilities;

u32 context_size;


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


[Intel-gfx] [PATCH] drm/i915: Align engine->uabi_class/instance with i915_drm.h

2020-01-15 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

In our ABI we have defined I915_ENGINE_CLASS_INVALID_NONE and
I915_ENGINE_CLASS_INVALID_VIRTUAL as negative values which creates
implicit coupling with type widths used in, also ABI, struct
i915_engine_class_instance.

When for instance we export engine->uabi_class
I915_ENGINE_CLASS_INVALID_VIRTUAL from our our tracepoints, because the
type of the former is u8 in contrast to u16 defined in the ABI, 254 will
be returned instead of 65534 which userspace would legitimately expect.

Therefore we need to align the type used to store engine ABI class and
instance.

I did not find any other user visible inconsistency apart from the
tracepoints so I think importance of the fix is low.

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/i915_gem_busy.c | 12 ++--
 drivers/gpu/drm/i915/gt/intel_engine_types.h |  4 ++--
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_busy.c 
b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
index 3d4f5775a4ba..25235ef630c1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
@@ -9,16 +9,16 @@
 #include "i915_gem_ioctls.h"
 #include "i915_gem_object.h"
 
-static __always_inline u32 __busy_read_flag(u8 id)
+static __always_inline u32 __busy_read_flag(u16 id)
 {
-   if (id == (u8)I915_ENGINE_CLASS_INVALID)
+   if (id == (u16)I915_ENGINE_CLASS_INVALID)
return 0xu;
 
GEM_BUG_ON(id >= 16);
return 0x1u << id;
 }
 
-static __always_inline u32 __busy_write_id(u8 id)
+static __always_inline u32 __busy_write_id(u16 id)
 {
/*
 * The uABI guarantees an active writer is also amongst the read
@@ -29,14 +29,14 @@ static __always_inline u32 __busy_write_id(u8 id)
 * last_read - hence we always set both read and write busy for
 * last_write.
 */
-   if (id == (u8)I915_ENGINE_CLASS_INVALID)
+   if (id == (u16)I915_ENGINE_CLASS_INVALID)
return 0xu;
 
return (id + 1) | __busy_read_flag(id);
 }
 
 static __always_inline unsigned int
-__busy_set_if_active(const struct dma_fence *fence, u32 (*flag)(u8 id))
+__busy_set_if_active(const struct dma_fence *fence, u32 (*flag)(u16 id))
 {
const struct i915_request *rq;
 
@@ -57,7 +57,7 @@ __busy_set_if_active(const struct dma_fence *fence, u32 
(*flag)(u8 id))
return 0;
 
/* Beware type-expansion follies! */
-   BUILD_BUG_ON(!typecheck(u8, rq->engine->uabi_class));
+   BUILD_BUG_ON(!typecheck(u16, rq->engine->uabi_class));
return flag(rq->engine->uabi_class);
 }
 
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 00287515e7af..350da59e605b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -278,8 +278,8 @@ struct intel_engine_cs {
u8 class;
u8 instance;
 
-   u8 uabi_class;
-   u8 uabi_instance;
+   u16 uabi_class;
+   u16 uabi_instance;
 
u32 uabi_capabilities;
u32 context_size;
-- 
2.20.1

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


Re: [Intel-gfx] [PATCH v2 07/21] drm/i915: Convert to CRTC VBLANK callbacks

2020-01-15 Thread Ville Syrjälä
On Wed, Jan 15, 2020 at 01:16:38PM +0100, Thomas Zimmermann wrote:
> VBLANK callbacks in struct drm_driver are deprecated in favor of their
> equivalents in struct drm_crtc_funcs. Convert i915 over.
> 
> The callback struct drm_driver.get_scanout_position() is deprecated
> in favor of struct drm_crtc_helper_funcs.get_scanout_position().
> i915 doesn't use CRTC helpers. Instead pass i915's implementation of
> get_scanout_position() to DRM core's
> drm_crtc_vblank_helper_get_vblank_timestamp_internal().
> 
> v2:
>   * use DRM's implementation of get_vblank_timestamp()
>   * simplify function names
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c |  7 +++
>  drivers/gpu/drm/i915/i915_drv.c  |  3 ---
>  drivers/gpu/drm/i915/i915_irq.c  | 20 +++-
>  drivers/gpu/drm/i915/i915_irq.h  |  6 ++
>  4 files changed, 24 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 59c375879186..c8f1da845e7d 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -16336,6 +16336,7 @@ static const struct drm_crtc_funcs bdw_crtc_funcs = {
>   .get_vblank_counter = g4x_get_vblank_counter,
>   .enable_vblank = bdw_enable_vblank,
>   .disable_vblank = bdw_disable_vblank,
> + .get_vblank_timestamp = i915_crtc_get_vblank_timestamp,
>  };
>  
>  static const struct drm_crtc_funcs ilk_crtc_funcs = {
> @@ -16344,6 +16345,7 @@ static const struct drm_crtc_funcs ilk_crtc_funcs = {
>   .get_vblank_counter = g4x_get_vblank_counter,
>   .enable_vblank = ilk_enable_vblank,
>   .disable_vblank = ilk_disable_vblank,
> + .get_vblank_timestamp = i915_crtc_get_vblank_timestamp,
>  };
>  
>  static const struct drm_crtc_funcs g4x_crtc_funcs = {
> @@ -16352,6 +16354,7 @@ static const struct drm_crtc_funcs g4x_crtc_funcs = {
>   .get_vblank_counter = g4x_get_vblank_counter,
>   .enable_vblank = i965_enable_vblank,
>   .disable_vblank = i965_disable_vblank,
> + .get_vblank_timestamp = i915_crtc_get_vblank_timestamp,
>  };
>  
>  static const struct drm_crtc_funcs i965_crtc_funcs = {
> @@ -16360,6 +16363,7 @@ static const struct drm_crtc_funcs i965_crtc_funcs = {
>   .get_vblank_counter = i915_get_vblank_counter,
>   .enable_vblank = i965_enable_vblank,
>   .disable_vblank = i965_disable_vblank,
> + .get_vblank_timestamp = i915_crtc_get_vblank_timestamp,
>  };
>  
>  static const struct drm_crtc_funcs i915gm_crtc_funcs = {
> @@ -16368,6 +16372,7 @@ static const struct drm_crtc_funcs i915gm_crtc_funcs 
> = {
>   .get_vblank_counter = i915_get_vblank_counter,
>   .enable_vblank = i915gm_enable_vblank,
>   .disable_vblank = i915gm_disable_vblank,
> + .get_vblank_timestamp = i915_crtc_get_vblank_timestamp,
>  };
>  
>  static const struct drm_crtc_funcs i915_crtc_funcs = {
> @@ -16376,6 +16381,7 @@ static const struct drm_crtc_funcs i915_crtc_funcs = {
>   .get_vblank_counter = i915_get_vblank_counter,
>   .enable_vblank = i8xx_enable_vblank,
>   .disable_vblank = i8xx_disable_vblank,
> + .get_vblank_timestamp = i915_crtc_get_vblank_timestamp,
>  };
>  
>  static const struct drm_crtc_funcs i8xx_crtc_funcs = {
> @@ -16384,6 +16390,7 @@ static const struct drm_crtc_funcs i8xx_crtc_funcs = {
>   /* no hw vblank counter */
>   .enable_vblank = i8xx_enable_vblank,
>   .disable_vblank = i8xx_disable_vblank,
> + .get_vblank_timestamp = i915_crtc_get_vblank_timestamp,
>  };
>  
>  static struct intel_crtc *intel_crtc_alloc(void)
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f7385abdd74b..30b9ba136a81 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2769,9 +2769,6 @@ static struct drm_driver driver = {
>   .gem_prime_export = i915_gem_prime_export,
>   .gem_prime_import = i915_gem_prime_import,
>  
> - .get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
> - .get_scanout_position = i915_get_crtc_scanoutpos,
> -
>   .dumb_create = i915_gem_dumb_create,
>   .dumb_map_offset = i915_gem_dumb_mmap_offset,
>  
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index afc6aad9bf8c..c39e3ef6e4a2 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -762,13 +762,15 @@ static int __intel_get_crtc_scanline(struct intel_crtc 
> *crtc)
>   return (position + crtc->scanline_offset) % vtotal;
>  }
>  
> -bool i915_get_crtc_scanoutpos(struct drm_device *dev, unsigned int index,
> -   bool in_vblank_irq, int *vpos, int *hpos,
> -   ktime_t *stime, ktime_t *etime,
> -   const struct drm_display_mode *mode)
> +static bool 

Re: [Intel-gfx] [PATCH 5/6] drm/i915/fbc: Add fbc tracepoints

2020-01-15 Thread Imre Deak
On Fri, Dec 13, 2019 at 03:34:52PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Add tracepoints which let us know when fbc activates/deactivates/nukes.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/display/intel_fbc.c |  9 
>  drivers/gpu/drm/i915/i915_trace.h| 62 
>  2 files changed, 71 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 28adf4636800..88a9c2fea695 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -41,6 +41,7 @@
>  #include 
>  
>  #include "i915_drv.h"
> +#include "i915_trace.h"
>  #include "intel_display_types.h"
>  #include "intel_fbc.h"
>  #include "intel_frontbuffer.h"
> @@ -200,6 +201,10 @@ static bool g4x_fbc_is_active(struct drm_i915_private 
> *dev_priv)
>  /* This function forces a CFB recompression through the nuke operation. */
>  static void intel_fbc_recompress(struct drm_i915_private *dev_priv)
>  {
> + struct intel_fbc *fbc = _priv->fbc;
> +
> + trace_intel_fbc_nuke(fbc->crtc);
> +
>   I915_WRITE(MSG_FBC_REND_STATE, FBC_REND_NUKE);
>   POSTING_READ(MSG_FBC_REND_STATE);
>  }
> @@ -356,6 +361,8 @@ static void intel_fbc_hw_activate(struct drm_i915_private 
> *dev_priv)
>  {
>   struct intel_fbc *fbc = _priv->fbc;
>  
> + trace_intel_fbc_activate(fbc->crtc);
> +
>   fbc->active = true;
>   fbc->activated = true;
>  
> @@ -373,6 +380,8 @@ static void intel_fbc_hw_deactivate(struct 
> drm_i915_private *dev_priv)
>  {
>   struct intel_fbc *fbc = _priv->fbc;
>  
> + trace_intel_fbc_deactivate(fbc->crtc);
> +
>   fbc->active = false;
>  
>   if (INTEL_GEN(dev_priv) >= 5)
> diff --git a/drivers/gpu/drm/i915/i915_trace.h 
> b/drivers/gpu/drm/i915/i915_trace.h
> index 7ef7a1e1664c..66ff96303b95 100644
> --- a/drivers/gpu/drm/i915/i915_trace.h
> +++ b/drivers/gpu/drm/i915/i915_trace.h
> @@ -339,6 +339,68 @@ TRACE_EVENT(intel_disable_plane,
> __entry->frame, __entry->scanline)
>  );
>  
> +/* fbc */
> +
> +TRACE_EVENT(intel_fbc_activate,
> + TP_PROTO(struct intel_crtc *crtc),
> + TP_ARGS(crtc),
> +
> + TP_STRUCT__entry(
> +  __field(enum pipe, pipe)
> +  __field(u32, frame)
> +  __field(u32, scanline)
> +  ),
> +
> + TP_fast_assign(
> +__entry->pipe = crtc->pipe;
> +__entry->frame = intel_crtc_get_vblank_counter(crtc);
> +__entry->scanline = intel_get_crtc_scanline(crtc);
> +),
> +
> + TP_printk("pipe %c, frame=%u, scanline=%u",
> +   pipe_name(__entry->pipe), __entry->frame, 
> __entry->scanline)
> +);
> +
> +TRACE_EVENT(intel_fbc_deactivate,
> + TP_PROTO(struct intel_crtc *crtc),
> + TP_ARGS(crtc),
> +
> + TP_STRUCT__entry(
> +  __field(enum pipe, pipe)
> +  __field(u32, frame)
> +  __field(u32, scanline)
> +  ),
> +
> + TP_fast_assign(
> +__entry->pipe = crtc->pipe;
> +__entry->frame = intel_crtc_get_vblank_counter(crtc);
> +__entry->scanline = intel_get_crtc_scanline(crtc);
> +),
> +
> + TP_printk("pipe %c, frame=%u, scanline=%u",
> +   pipe_name(__entry->pipe), __entry->frame, 
> __entry->scanline)
> +);
> +
> +TRACE_EVENT(intel_fbc_nuke,
> + TP_PROTO(struct intel_crtc *crtc),
> + TP_ARGS(crtc),
> +
> + TP_STRUCT__entry(
> +  __field(enum pipe, pipe)
> +  __field(u32, frame)
> +  __field(u32, scanline)
> +  ),
> +
> + TP_fast_assign(
> +__entry->pipe = crtc->pipe;
> +__entry->frame = intel_crtc_get_vblank_counter(crtc);
> +__entry->scanline = intel_get_crtc_scanline(crtc);
> +),
> +
> + TP_printk("pipe %c, frame=%u, scanline=%u",
> +   pipe_name(__entry->pipe), __entry->frame, 
> __entry->scanline)
> +);
> +
>  /* pipe updates */
>  
>  TRACE_EVENT(i915_pipe_update_start,
> -- 
> 2.23.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
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: Preemptive timeline retirement (rev3)

2020-01-15 Thread Patchwork
== Series Details ==

Series: drm/i915: Preemptive timeline retirement (rev3)
URL   : https://patchwork.freedesktop.org/series/71958/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7733_full -> Patchwork_16072_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@rcs0-s3:
- shard-kbl:  [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +6 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-kbl1/igt@gem_ctx_isolat...@rcs0-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16072/shard-kbl3/igt@gem_ctx_isolat...@rcs0-s3.html

  * igt@gem_ctx_persistence@vcs1-mixed:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [fdo#112080]) 
+3 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-iclb1/igt@gem_ctx_persiste...@vcs1-mixed.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16072/shard-iclb8/igt@gem_ctx_persiste...@vcs1-mixed.html

  * igt@gem_ctx_persistence@vecs0-mixed-process:
- shard-apl:  [PASS][5] -> [FAIL][6] ([i915#679])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-apl3/igt@gem_ctx_persiste...@vecs0-mixed-process.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16072/shard-apl3/igt@gem_ctx_persiste...@vecs0-mixed-process.html

  * igt@gem_ctx_shared@q-smoketest-vebox:
- shard-tglb: [PASS][7] -> [INCOMPLETE][8] ([fdo#111735])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-tglb5/igt@gem_ctx_sha...@q-smoketest-vebox.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16072/shard-tglb9/igt@gem_ctx_sha...@q-smoketest-vebox.html

  * igt@gem_eio@in-flight-contexts-1us:
- shard-snb:  [PASS][9] -> [FAIL][10] ([i915#490])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-snb2/igt@gem_...@in-flight-contexts-1us.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16072/shard-snb5/igt@gem_...@in-flight-contexts-1us.html

  * igt@gem_exec_balancer@nop:
- shard-tglb: [PASS][11] -> [INCOMPLETE][12] ([fdo#111736] / 
[i915#472]) +1 similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-tglb4/igt@gem_exec_balan...@nop.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16072/shard-tglb1/igt@gem_exec_balan...@nop.html

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#110854])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-iclb4/igt@gem_exec_balan...@smoke.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16072/shard-iclb3/igt@gem_exec_balan...@smoke.html

  * igt@gem_exec_nop@basic-sequential:
- shard-tglb: [PASS][15] -> [INCOMPLETE][16] ([i915#472])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-tglb2/igt@gem_exec_...@basic-sequential.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16072/shard-tglb7/igt@gem_exec_...@basic-sequential.html

  * igt@gem_exec_schedule@in-order-bsd:
- shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#112146]) +6 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-iclb8/igt@gem_exec_sched...@in-order-bsd.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16072/shard-iclb1/igt@gem_exec_sched...@in-order-bsd.html

  * igt@gem_exec_schedule@pi-distinct-iova-bsd:
- shard-iclb: [PASS][19] -> [SKIP][20] ([i915#677]) +1 similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-iclb8/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16072/shard-iclb2/igt@gem_exec_sched...@pi-distinct-iova-bsd.html

  * igt@gem_exec_schedule@preempt-queue-chain-bsd2:
- shard-tglb: [PASS][21] -> [INCOMPLETE][22] ([fdo#111677] / 
[i915#472])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-tglb9/igt@gem_exec_sched...@preempt-queue-chain-bsd2.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16072/shard-tglb6/igt@gem_exec_sched...@preempt-queue-chain-bsd2.html

  * igt@gem_exec_schedule@preempt-queue-contexts-bsd2:
- shard-tglb: [PASS][23] -> [INCOMPLETE][24] ([fdo#111606] / 
[fdo#111677] / [i915#472]) +1 similar issue
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7733/shard-tglb5/igt@gem_exec_sched...@preempt-queue-contexts-bsd2.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16072/shard-tglb8/igt@gem_exec_sched...@preempt-queue-contexts-bsd2.html

  * igt@gem_persistent_relocs@forked-interruptible-thrashing:
- shard-kbl:  [PASS][25] -> [FAIL][26] ([i915#520])
   [25]: 

Re: [Intel-gfx] [PATCH 3/6] drm/i915/fbc: Move the plane state check into the fbc functions

2020-01-15 Thread Imre Deak
On Fri, Dec 13, 2019 at 03:34:50PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Instead of dealing with the presence/absence of the primary
> plane in the higher level pre/post plane update code let's
> move all that into the fbc code itself. Now the higher level
> code doesn't have to think about FBC details anymore.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 26 +++--
>  drivers/gpu/drm/i915/display/intel_fbc.c | 40 +++-
>  drivers/gpu/drm/i915/display/intel_fbc.h | 13 +++
>  3 files changed, 42 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 8f14352a2193..3e540fcca216 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6013,13 +6013,10 @@ static void intel_post_plane_update(struct 
> intel_atomic_state *state,
>   struct intel_crtc *crtc)
>  {
>   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> - struct intel_plane *primary = to_intel_plane(crtc->base.primary);
>   const struct intel_crtc_state *old_crtc_state =
>   intel_atomic_get_old_crtc_state(state, crtc);
>   const struct intel_crtc_state *new_crtc_state =
>   intel_atomic_get_new_crtc_state(state, crtc);
> - const struct intel_plane_state *new_primary_state =
> - intel_atomic_get_new_plane_state(state, primary);
>   enum pipe pipe = crtc->pipe;
>  
>   intel_frontbuffer_flip(dev_priv, new_crtc_state->fb_bits);
> @@ -6030,8 +6027,7 @@ static void intel_post_plane_update(struct 
> intel_atomic_state *state,
>   if (hsw_post_update_enable_ips(old_crtc_state, new_crtc_state))
>   hsw_enable_ips(new_crtc_state);
>  
> - if (new_primary_state)
> - intel_fbc_post_update(crtc);
> + intel_fbc_post_update(state, crtc);
>  
>   if (needs_nv12_wa(old_crtc_state) &&
>   !needs_nv12_wa(new_crtc_state))
> @@ -6046,20 +6042,16 @@ static void intel_pre_plane_update(struct 
> intel_atomic_state *state,
>  struct intel_crtc *crtc)
>  {
>   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> - struct intel_plane *primary = to_intel_plane(crtc->base.primary);
>   const struct intel_crtc_state *old_crtc_state =
>   intel_atomic_get_old_crtc_state(state, crtc);
>   const struct intel_crtc_state *new_crtc_state =
>   intel_atomic_get_new_crtc_state(state, crtc);
> - const struct intel_plane_state *new_primary_state =
> - intel_atomic_get_new_plane_state(state, primary);
>   enum pipe pipe = crtc->pipe;
>  
>   if (hsw_pre_update_disable_ips(old_crtc_state, new_crtc_state))
>   hsw_disable_ips(old_crtc_state);
>  
> - if (new_primary_state &&
> - intel_fbc_pre_update(crtc, new_crtc_state, new_primary_state))
> + if (intel_fbc_pre_update(state, crtc))
>   intel_wait_for_vblank(dev_priv, pipe);
>  
>   /* Display WA 827 */
> @@ -14289,9 +14281,6 @@ static void intel_update_crtc(struct intel_crtc *crtc,
>  {
>   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
>   bool modeset = needs_modeset(new_crtc_state);
> - struct intel_plane_state *new_plane_state =
> - intel_atomic_get_new_plane_state(state,
> -  
> to_intel_plane(crtc->base.primary));
>  
>   if (modeset) {
>   intel_crtc_update_active_timings(new_crtc_state);
> @@ -14314,8 +14303,8 @@ static void intel_update_crtc(struct intel_crtc *crtc,
>  
>   if (new_crtc_state->update_pipe && !new_crtc_state->enable_fbc)
>   intel_fbc_disable(crtc);
> - else if (new_plane_state)
> - intel_fbc_enable(crtc, new_crtc_state, new_plane_state);
> + else
> + intel_fbc_enable(state, crtc);
>  
>   /* Perform vblank evasion around commit operation */
>   intel_pipe_update_start(new_crtc_state);
> @@ -14472,15 +14461,12 @@ static void intel_post_crtc_enable_updates(struct 
> intel_crtc *crtc,
>   intel_atomic_get_new_crtc_state(state, crtc);
>   struct intel_crtc_state *old_crtc_state =
>   intel_atomic_get_old_crtc_state(state, crtc);
> - struct intel_plane_state *new_plane_state =
> - intel_atomic_get_new_plane_state(state,
> -  
> to_intel_plane(crtc->base.primary));
>   bool modeset = needs_modeset(new_crtc_state);
>  
>   if (new_crtc_state->update_pipe && !new_crtc_state->enable_fbc)
>   intel_fbc_disable(crtc);
> - else if (new_plane_state)
> - intel_fbc_enable(crtc, new_crtc_state, new_plane_state);
> + else
> + intel_fbc_enable(state, crtc);
>  
> 

[Intel-gfx] ✗ Fi.CI.BUILD: warning for Misc GuC CT improvements - part II

2020-01-15 Thread Patchwork
== Series Details ==

Series: Misc GuC CT improvements - part II
URL   : https://patchwork.freedesktop.org/series/72071/
State : warning

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 122 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:93: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1282: recipe for target 'modules' failed
make: *** [modules] Error 2

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for Misc GuC CT improvements - part II

2020-01-15 Thread Patchwork
== Series Details ==

Series: Misc GuC CT improvements - part II
URL   : https://patchwork.freedesktop.org/series/72071/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7748 -> Patchwork_16112


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload-with-fault-injection:
- fi-kbl-7500u:   [PASS][1] -> [INCOMPLETE][2] ([i915#879])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7748/fi-kbl-7500u/igt@i915_module_l...@reload-with-fault-injection.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16112/fi-kbl-7500u/igt@i915_module_l...@reload-with-fault-injection.html

  
 Possible fixes 

  * igt@gem_exec_gttfill@basic:
- fi-bsw-n3050:   [TIMEOUT][3] ([fdo#112271]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7748/fi-bsw-n3050/igt@gem_exec_gttf...@basic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16112/fi-bsw-n3050/igt@gem_exec_gttf...@basic.html

  * igt@gem_exec_parallel@basic:
- {fi-ehl-1}: [INCOMPLETE][5] ([i915#937]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7748/fi-ehl-1/igt@gem_exec_paral...@basic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16112/fi-ehl-1/igt@gem_exec_paral...@basic.html

  * igt@i915_module_load@reload-with-fault-injection:
- fi-skl-6700k2:  [INCOMPLETE][7] ([i915#671]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7748/fi-skl-6700k2/igt@i915_module_l...@reload-with-fault-injection.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16112/fi-skl-6700k2/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@i915_selftest@live_gem_contexts:
- fi-hsw-4770r:   [DMESG-FAIL][9] ([i915#722]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7748/fi-hsw-4770r/igt@i915_selftest@live_gem_contexts.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16112/fi-hsw-4770r/igt@i915_selftest@live_gem_contexts.html

  
 Warnings 

  * igt@i915_selftest@live_blt:
- fi-hsw-4770:[DMESG-FAIL][11] ([i915#563]) -> [DMESG-FAIL][12] 
([i915#770])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7748/fi-hsw-4770/igt@i915_selftest@live_blt.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16112/fi-hsw-4770/igt@i915_selftest@live_blt.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-icl-u2:  [FAIL][13] ([i915#217]) -> [DMESG-WARN][14] ([IGT#4] 
/ [i915#263])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7748/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16112/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html

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

  [IGT#4]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/4
  [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
  [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
  [i915#263]: https://gitlab.freedesktop.org/drm/intel/issues/263
  [i915#563]: https://gitlab.freedesktop.org/drm/intel/issues/563
  [i915#671]: https://gitlab.freedesktop.org/drm/intel/issues/671
  [i915#722]: https://gitlab.freedesktop.org/drm/intel/issues/722
  [i915#770]: https://gitlab.freedesktop.org/drm/intel/issues/770
  [i915#879]: https://gitlab.freedesktop.org/drm/intel/issues/879
  [i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937


Participating hosts (42 -> 42)
--

  Additional (5): fi-byt-j1900 fi-skl-lmem fi-blb-e6850 fi-byt-n2820 
fi-bsw-nick 
  Missing(5): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-kbl-r 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7748 -> Patchwork_16112

  CI-20190529: 20190529
  CI_DRM_7748: 1793de9a4215356790b87608fcfc9e99eeb6954d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5365: e9ec0ed63b25c86861ffac3c8601cc4d1b910b65 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16112: 17839d70f06ce689e099c749d06ed0f3cc43f778 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Kernel 32bit build ==

Warning: Kernel 32bit buildtest failed:
https://intel-gfx-ci.01.org/Patchwork_16112/build_32bit.log

  CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 122 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!

  1   2   >