[Intel-gfx] i915/kexec: warning at drivers/gpu/drm/i915/display/intel_psr.c:782 intel_psr_activate+0x3c6/0x440
Hi, This warning exists for long time, I did not find time to report, here is the latest kernel logs, can you please to have a look? hardware: Thinkpad T480s lspci: 00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07) -- [0.00] Linux version 5.8.0-rc1+ (dyo...@dhcp-128-65.nay.redhat.com) (gcc (GCC) 10.0.1 20200328 (Red Hat 10.0.1-0.11), GNU ld version 2.34-2.fc32) #179 SMP Wed Jun 17 14:12:27 CST 2020 [0.00] Command line: ramoops.mem_address=0x2000 ramoops.mem_size=0x40 hung_task_panic=1 softlockup_panic=1 panic=6 root=/dev/nvme0n1p9 ro rd.lvm.lv=rhel/swap LANG=zh_CN.UTF-8 audit=0 selinux=0 no_console_suspend crashkernel=160M printk.devkmsg=off usbcore.autosuspend=-1 [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' [0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64 [0.00] x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64 [0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format. [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x00057fff] usable [0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved [0.00] BIOS-e820: [mem 0x00059000-0x0009cfff] usable [0.00] BIOS-e820: [mem 0x0009d000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x3fff] usable [0.00] BIOS-e820: [mem 0x4000-0x403f] reserved [0.00] BIOS-e820: [mem 0x4040-0x7b4b2fff] usable [0.00] BIOS-e820: [mem 0x7b4b3000-0x7b4b4fff] reserved [0.00] BIOS-e820: [mem 0x7b4b5000-0x7b51cfff] usable [0.00] BIOS-e820: [mem 0x7b51d000-0x7b51dfff] reserved [0.00] BIOS-e820: [mem 0x7b51e000-0xad334fff] usable [0.00] BIOS-e820: [mem 0xad335000-0xad335fff] ACPI NVS [0.00] BIOS-e820: [mem 0xad336000-0xad336fff] reserved [0.00] BIOS-e820: [mem 0xad337000-0xba3e9fff] usable [0.00] BIOS-e820: [mem 0xba3ea000-0xbb535fff] reserved [0.00] BIOS-e820: [mem 0xbb536000-0xbb599fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbb59a000-0xbb5fefff] ACPI data [0.00] BIOS-e820: [mem 0xbb5ff000-0xbb5f] usable [0.00] BIOS-e820: [mem 0xbb60-0xbf7f] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfe01-0xfe010fff] reserved [0.00] BIOS-e820: [mem 0x0001-0x00043e7f] usable [0.00] NX (Execute Disable) protection: active [0.00] e820: update [mem 0x00050270-0x000502df] usable ==> usable [0.00] extended physical RAM map: [0.00] reserve setup_data: [mem 0x-0x0005026f] usable [0.00] reserve setup_data: [mem 0x00050270-0x000502df] usable [0.00] reserve setup_data: [mem 0x000502e0-0x00057fff] usable [0.00] reserve setup_data: [mem 0x00058000-0x00058fff] reserved [0.00] reserve setup_data: [mem 0x00059000-0x0009cfff] usable [0.00] reserve setup_data: [mem 0x0009d000-0x000f] reserved [0.00] reserve setup_data: [mem 0x0010-0x3fff] usable [0.00] reserve setup_data: [mem 0x4000-0x403f] reserved [0.00] reserve setup_data: [mem 0x4040-0x7b4b2fff] usable [0.00] reserve setup_data: [mem 0x7b4b3000-0x7b4b4fff] reserved [0.00] reserve setup_data: [mem 0x7b4b5000-0x7b51cfff] usable [0.00] reserve setup_data: [mem 0x7b51d000-0x7b51dfff] reserved [0.00] reserve setup_data: [mem 0x7b51e000-0xad334fff] usable [0.00] reserve setup_data: [mem 0xad335000-0xad335fff] ACPI NVS [0.00] reserve setup_data: [mem 0xad336000-0xad336fff] reserved [0.00] reserve setup_data: [mem 0xad337000-0xba3e9fff] usable [0.00] reserve setup_data: [mem 0xba3ea000-0xbb535fff] reserved [0.00] reserve setup
Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 04/18] dma-fence: prime lockdep annotations
On Tue, Jun 16, 2020 at 2:07 PM Daniel Vetter wrote: > > Hi Jason, > > Somehow this got stuck somewhere in the mail queues, only popped up just > now ... > > On Thu, Jun 11, 2020 at 11:15:15AM -0300, Jason Gunthorpe wrote: > > On Thu, Jun 11, 2020 at 10:34:30AM +0200, Daniel Vetter wrote: > > > > I still have my doubts about allowing fence waiting from within > > > > shrinkers. > > > > IMO ideally they should use a trywait approach, in order to allow memory > > > > allocation during command submission for drivers that > > > > publish fences before command submission. (Since early reservation > > > > object > > > > release requires that). > > > > > > Yeah it is a bit annoying, e.g. for drm/scheduler I think we'll end up > > > with a mempool to make sure it can handle it's allocations. > > > > > > > But since drivers are already waiting from within shrinkers and I take > > > > your > > > > word for HMM requiring this, > > > > > > Yeah the big trouble is HMM and mmu notifiers. That's the really awkward > > > one, the shrinker one is a lot less established. > > > > I really question if HW that needs something like DMA fence should > > even be using mmu notifiers - the best use is HW that can fence the > > DMA directly without having to get involved with some command stream > > processing. > > > > Or at the very least it should not be a generic DMA fence but a > > narrowed completion tied only into the same GPU driver's command > > completion processing which should be able to progress without > > blocking. > > The problem with gpus is that these completions leak across the board like > mad. Both internally within memory managers (made a lot worse with p2p > direct access to vram), and through uapi. > > Many gpus still have a very hard time preempting, so doing an overall > switch in drivers/gpu to a memory management model where that is required > is not a very realistic option. And minimally you need either preempt > (still takes a while, but a lot faster generally than waiting for work to > complete) or hw faults (just a bunch of tlb flushes plus virtual indexed > caches, so just the caveat of that for a gpu, which has lots and big tlbs > and caches). So preventing the completion leaks within the kernel is I > think unrealistic, except if we just say "well sorry, run on windows, > mkay" for many gpu workloads. Or more realistic "well sorry, run on the > nvidia blob with nvidia hw". > > The userspace side we can somewhat isolate, at least for pure compute > workloads. But the thing is drivers/gpu is a continum from tiny socs > (where dma_fence is a very nice model) to huge compute stuff (where it's > maybe not the nicest, but hey hw sucks so still neeeded). Doing full on > break in uapi somewhere in there is at least a bit awkward, e.g. some of > the media codec code on intel runs all the way from the smallest intel soc > to the big transcode servers. > > So the current status quo is "total mess, every driver defines their own > rules". All I'm trying to do is some common rules here, do make this mess > slightly more manageable and overall reviewable and testable. > > I have no illusions that this is fundamentally pretty horrible, and the > leftover wiggle room for writing memory manager is barely more than a > hairline. Just not seeing how other options are better. So bad news is that gpu's are horrible, but I think if you don't have to review gpu drivers it's substantially better. If you do have hw with full device page fault support, then there's no need to ever install a dma_fence. Punching out device ptes and flushing caches is all that's needed. That is also the plan we have, for the workloads and devices where that's possible. Now my understanding for rdma is that if you don't have hw page fault support, then the only other object is to more or less permanently pin the memory. So again, dma_fence are completely useless, since it's entirely up to userspace when a given piece of registered memory isn't needed anymore, and the entire problem boils down to how much do we allow random userspace to just pin (system or device) memory. Or at least I don't really see any other solution. On the other end we have simpler devices like video input/output. Those always need pinned memory, but through hw design it's limited in how much you can pin (generally max resolution times a limited set of buffers to cycle through). Just including that memory pinning allowance as part of device access makes sense. It's only gpus (I think) which are in this awkward in-between spot where dynamic memory management really is much wanted, but the hw kinda sucks. Aside, about 10+ years ago we had a similar problem with gpu hw, but for security: Many gpu didn't have any kinds of page tables to isolate different clients from each another. drivers/gpu fixed this by parsing&validating what userspace submitted to make sure it's only every accessing its own buffers. Most gpus have become reasonable nowadays and do have proper per-
[Intel-gfx] ✗ Fi.CI.IGT: failure for linux-next: build failure after merge of the drm-misc tree
== Series Details == Series: linux-next: build failure after merge of the drm-misc tree URL : https://patchwork.freedesktop.org/series/78444/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8638_full -> Patchwork_17974_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17974_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17974_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_17974_full: ### IGT changes ### Possible regressions * igt@kms_flip@basic-plain-flip@c-hdmi-a1: - shard-hsw: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8638/shard-hsw6/igt@kms_flip@basic-plain-f...@c-hdmi-a1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17974/shard-hsw2/igt@kms_flip@basic-plain-f...@c-hdmi-a1.html Known issues Here are the changes found in Patchwork_17974_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@bcs0: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8638/shard-kbl4/igt@gem_ctx_isolation@preservation...@bcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17974/shard-kbl4/igt@gem_ctx_isolation@preservation...@bcs0.html * igt@gem_ctx_persistence@engines-mixed-process@rcs0: - shard-apl: [PASS][5] -> [FAIL][6] ([i915#1528]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8638/shard-apl3/igt@gem_ctx_persistence@engines-mixed-proc...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17974/shard-apl6/igt@gem_ctx_persistence@engines-mixed-proc...@rcs0.html * igt@gem_ctx_persistence@engines-mixed-process@vcs0: - shard-skl: [PASS][7] -> [FAIL][8] ([i915#1528]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8638/shard-skl5/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17974/shard-skl5/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html * igt@gem_exec_schedule@implicit-write-read@rcs0: - shard-snb: [PASS][9] -> [INCOMPLETE][10] ([i915#82]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8638/shard-snb4/igt@gem_exec_schedule@implicit-write-r...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17974/shard-snb2/igt@gem_exec_schedule@implicit-write-r...@rcs0.html * igt@gem_exec_whisper@basic-contexts-priority-all: - shard-glk: [PASS][11] -> [DMESG-WARN][12] ([i915#118] / [i915#95]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8638/shard-glk2/igt@gem_exec_whis...@basic-contexts-priority-all.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17974/shard-glk2/igt@gem_exec_whis...@basic-contexts-priority-all.html * igt@gem_userptr_blits@userfault: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#93] / [i915#95]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8638/shard-kbl2/igt@gem_userptr_bl...@userfault.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17974/shard-kbl7/igt@gem_userptr_bl...@userfault.html * igt@i915_suspend@forcewake: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([i915#636] / [i915#69]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8638/shard-skl7/igt@i915_susp...@forcewake.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17974/shard-skl5/igt@i915_susp...@forcewake.html * igt@kms_ccs@pipe-b-missing-ccs-buffer: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#165]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8638/shard-kbl3/igt@kms_...@pipe-b-missing-ccs-buffer.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17974/shard-kbl2/igt@kms_...@pipe-b-missing-ccs-buffer.html * igt@kms_flip_tiling@flip-changes-tiling: - shard-skl: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +8 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8638/shard-skl4/igt@kms_flip_til...@flip-changes-tiling.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17974/shard-skl6/igt@kms_flip_til...@flip-changes-tiling.html * igt@kms_flip_tiling@flip-changes-tiling-y: - shard-apl: [PASS][21] -> [DMESG-FAIL][22] ([i915#95]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8638/shard-apl6/igt@kms_flip_til...@flip-changes-tiling-y.html [22]: https://intel-gfx-ci.01.org/tree/drm-ti
Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree
Hi
Am 17.06.20 um 02:59 schrieb Stephen Rothwell:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c: In function
> 'amdgpu_amdkfd_gpuvm_free_memory_of_gpu':
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:1357:2: error: implicit
> declaration of function 'drm_gem_object_put_unlocked'; did you mean
> 'drm_gem_object_put_locked'? [-Werror=implicit-function-declaration]
> 1357 | drm_gem_object_put_unlocked(&mem->bo->tbo.base);
> | ^~~
> | drm_gem_object_put_locked
>
> Caused by commit
>
> ab15d56e27be ("drm: remove transient drm_gem_object_put_unlocked()")
>
> interacting with commit
>
> fd9a9f8801de ("drm/amdgpu: Use GEM obj reference for KFD BOs")
>
> from Linus' tree.
>
> I have applied the following merge fix up patch for today.
>
> From: Stephen Rothwell
> Date: Wed, 17 Jun 2020 10:55:32 +1000
> Subject: [PATCH] drm/amdgpu: remove stray drm_gem_object_put_unlocked
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> index b91b5171270f..9015c7b76d60 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> @@ -1354,7 +1354,7 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
> }
>
> /* Free the BO*/
> - drm_gem_object_put_unlocked(&mem->bo->tbo.base);
> + drm_gem_object_put(&mem->bo->tbo.base);
We recently dropped the _unlock() suffix from drm_gem_object_put(). This
patch should be ok.
Best regards
Thomas
> mutex_destroy(&mem->lock);
> kfree(mem);
>
>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
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: failure for drm/i915/gvt: query if vgpu is active via GETPARAM IOCTL (rev2)
== Series Details == Series: drm/i915/gvt: query if vgpu is active via GETPARAM IOCTL (rev2) URL : https://patchwork.freedesktop.org/series/78409/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/i915_getparam.o drivers/gpu/drm/i915/i915_getparam.c: In function ‘i915_getparam_ioctl’: drivers/gpu/drm/i915/i915_getparam.c:165:11: error: implicit declaration of function ‘intel_vgpu_active’; did you mean ‘intel_vtd_active’? [-Werror=implicit-function-declaration] value = intel_vgpu_active(i915); ^ intel_vtd_active cc1: all warnings being treated as errors scripts/Makefile.build:280: recipe for target 'drivers/gpu/drm/i915/i915_getparam.o' failed make[4]: *** [drivers/gpu/drm/i915/i915_getparam.o] Error 1 scripts/Makefile.build:497: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:497: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:497: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1764: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gvt: query if vgpu is active via GETPARAM IOCTL
[Why]
Query if vgpu is active, it is useful to the user.
Currently, only the primary plane is usable when vgpu is active.
The value of vgpu active is useful for user to determine
how many planes can be used. also useful for user to
determine different behaviors according to vgpu is active or not.
[How]
Add a switch-case in the IOCTL 'i915_getparam_ioctl' to
return 'intel_vgpu_active'
Signed-off-by: Shaofeng Tang
---
drivers/gpu/drm/i915/i915_getparam.c | 3 +++
include/uapi/drm/i915_drm.h | 6 ++
tools/include/uapi/drm/i915_drm.h| 6 ++
3 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_getparam.c
b/drivers/gpu/drm/i915/i915_getparam.c
index d042644..c50555b 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -161,6 +161,9 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
case I915_PARAM_PERF_REVISION:
value = i915_perf_ioctl_version();
break;
+ case I915_PARAM_IS_GVT:
+ value = intel_vgpu_active(i915);
+ break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 14b67cd..74f06e2 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -619,6 +619,12 @@ typedef struct drm_i915_irq_wait {
*/
#define I915_PARAM_PERF_REVISION 54
+/*
+ * Query whether GVT is active. The value returned helps userspace application
+ * to determine what KMS resources are workable.
+ */
+#define I915_PARAM_IS_GVT 55
+
/* Must be kept compact -- no holes and well documented */
typedef struct drm_i915_getparam {
diff --git a/tools/include/uapi/drm/i915_drm.h
b/tools/include/uapi/drm/i915_drm.h
index 2813e57..ecaad82 100644
--- a/tools/include/uapi/drm/i915_drm.h
+++ b/tools/include/uapi/drm/i915_drm.h
@@ -619,6 +619,12 @@ typedef struct drm_i915_irq_wait {
*/
#define I915_PARAM_PERF_REVISION 54
+/*
+ * Query whether GVT is active. The value returned helps userspace application
+ * to determine what KMS resources are workable.
+ */
+#define I915_PARAM_IS_GVT 55
+
/* Must be kept compact -- no holes and well documented */
typedef struct drm_i915_getparam {
--
2.9.2
base-commit: 999bc17a2471df17a3af3001d094cf6d5d4849b0
___
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/selftests: Check preemption rollback of different ring queue depths (rev2)
== Series Details == Series: drm/i915/selftests: Check preemption rollback of different ring queue depths (rev2) URL : https://patchwork.freedesktop.org/series/78411/ State : success == Summary == CI Bug Log - changes from CI_DRM_8637_full -> Patchwork_17972_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17972_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/shard-kbl1/igt@gem_ctx_isolation@preservation...@rcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17972/shard-kbl2/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@gem_exec_schedule@implicit-read-write@rcs0: - shard-snb: [PASS][3] -> [INCOMPLETE][4] ([i915#82]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/shard-snb6/igt@gem_exec_schedule@implicit-read-wr...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17972/shard-snb1/igt@gem_exec_schedule@implicit-read-wr...@rcs0.html * igt@gem_exec_whisper@basic-queues-priority: - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/shard-glk5/igt@gem_exec_whis...@basic-queues-priority.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17972/shard-glk7/igt@gem_exec_whis...@basic-queues-priority.html * igt@kms_big_fb@linear-64bpp-rotate-180: - shard-glk: [PASS][7] -> [DMESG-FAIL][8] ([i915#118] / [i915#95]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/shard-glk2/igt@kms_big...@linear-64bpp-rotate-180.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17972/shard-glk8/igt@kms_big...@linear-64bpp-rotate-180.html * igt@kms_fence_pin_leak: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#93] / [i915#95]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/shard-kbl6/igt@kms_fence_pin_leak.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17972/shard-kbl7/igt@kms_fence_pin_leak.html * igt@kms_flip@flip-vs-suspend-interruptible@b-edp1: - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([i915#198]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/shard-skl4/igt@kms_flip@flip-vs-suspend-interrupti...@b-edp1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17972/shard-skl1/igt@kms_flip@flip-vs-suspend-interrupti...@b-edp1.html * igt@kms_flip_tiling@flip-changes-tiling-y: - shard-apl: [PASS][13] -> [DMESG-FAIL][14] ([i915#95]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/shard-apl8/igt@kms_flip_til...@flip-changes-tiling-y.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17972/shard-apl3/igt@kms_flip_til...@flip-changes-tiling-y.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-move: - shard-tglb: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/shard-tglb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-move.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17972/shard-tglb1/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-move.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145] / [i915#265]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/shard-skl9/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17972/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_plane_scaling@pipe-a-scaler-with-clipping-clamping: - shard-iclb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/shard-iclb1/igt@kms_plane_scal...@pipe-a-scaler-with-clipping-clamping.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17972/shard-iclb3/igt@kms_plane_scal...@pipe-a-scaler-with-clipping-clamping.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17972/shard-iclb7/igt@kms_psr@psr2_sprite_mmap_gtt.html * igt@kms_psr@suspend: - shard-skl: [PASS][23] -> [DMESG-WARN][24] ([i915#1982]) +10 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/shard-skl4/igt@kms_...@suspend.html [24]
[Intel-gfx] [PULL] gvt-fixes
Hi, This contains misc fixes for gvt. Two MMIO handler fixes on SKL/CFL, one mask register bit checking fix exposed in suspend/resume path and one lockdep error fix for debugfs entry access. Thanks. -- The following changes since commit 8e68c6340d5833077b3753eabedab40755571383: drm/i915/display: Fix the encoder type check (2020-06-16 11:34:24 +0300) are available in the Git repository at: https://github.com/intel/gvt-linux tags/gvt-fixes-2020-06-17 for you to fetch changes up to a291e4fba259a56a6a274c1989997acb6f0bb03a: drm/i915/gvt: Use GFP_ATOMIC instead of GFP_KERNEL in atomic context (2020-06-17 12:36:19 +0800) gvt-fixes-2020-06-17 - Two missed MMIO handler fixes for SKL/CFL (Colin) - Fix mask register bits check (Colin) - Fix one lockdep error for debugfs entry access (Colin) Colin Xu (4): drm/i915/gvt: Add one missing MMIO handler for D_SKL_PLUS drm/i915/gvt: Fix two CFL MMIO handling caused by regression. drm/i915/gvt: Fix incorrect check of enabled bits in mask registers drm/i915/gvt: Use GFP_ATOMIC instead of GFP_KERNEL in atomic context drivers/gpu/drm/i915/gvt/debugfs.c | 2 +- drivers/gpu/drm/i915/gvt/handlers.c | 24 +--- drivers/gpu/drm/i915/gvt/mmio_context.h | 6 +++--- drivers/gpu/drm/i915/gvt/reg.h | 5 + 4 files changed, 22 insertions(+), 15 deletions(-) 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.BAT: failure for Remaining RKL patches (rev6)
== Series Details ==
Series: Remaining RKL patches (rev6)
URL : https://patchwork.freedesktop.org/series/77971/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8638 -> Patchwork_17975
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17975 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17975, 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_17975/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17975:
### IGT changes ###
Possible regressions
* igt@runner@aborted:
- fi-tgl-u2: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17975/fi-tgl-u2/igt@run...@aborted.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@runner@aborted:
- {fi-tgl-dsi}: NOTRUN -> [FAIL][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17975/fi-tgl-dsi/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_17975 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-apl-guc: [PASS][3] -> [INCOMPLETE][4] ([i915#1242])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8638/fi-apl-guc/igt@gem_exec_susp...@basic-s0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17975/fi-apl-guc/igt@gem_exec_susp...@basic-s0.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1242]: https://gitlab.freedesktop.org/drm/intel/issues/1242
[i915#1569]: https://gitlab.freedesktop.org/drm/intel/issues/1569
[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#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
Participating hosts (47 -> 10)
--
ERROR: It appears as if the changes made in Patchwork_17975 prevented too
many machines from booting.
Missing(37): fi-icl-u2 fi-skl-lmem fi-blb-e6850 fi-byt-n2820 fi-skl-6600u
fi-snb-2600 fi-cml-u2 fi-bxt-dsi fi-bdw-5557u fi-cml-s fi-bsw-n3050
fi-byt-j1900 fi-glk-dsi fi-bwr-2160 fi-ilk-650 fi-kbl-7500u fi-hsw-4770
fi-gdg-551 fi-ivb-3770 fi-elk-e7500 fi-bsw-nick fi-skl-6700k2 fi-kbl-r
fi-ilk-m540 fi-ehl-1 fi-skl-guc fi-cfl-8700k fi-byt-squawks fi-bsw-cyan
fi-cfl-guc fi-kbl-guc fi-whl-u fi-kbl-x1275 fi-cfl-8109u fi-bsw-kefka
fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8638 -> Patchwork_17975
CI-20190529: 20190529
CI_DRM_8638: 83818e4910cac8b84d8f915c773ab3f55fa30365 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5711: 90611a0c90afa4a46496c78a4faf9638a1538ac3 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17975: a03fa5993eeac9c31bbf8ab3b6c79ac7f4b6e4d7 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a03fa5993eea drm/i915/rkl: Add Wa_14011224835 for PHY B initialization
0b4911dd9a47 drm/i915/rkl: Add initial workarounds
1f13cd3654fb drm/i915/rkl: Handle HTI
c8d0aab47fb8 drm/i915/rkl: Add DPLL4 support
bf41347d51b5 drm/i915/rkl: Handle new DPCLKA_CFGCR0 layout
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17975/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 5/5] drm/i915/rkl: Add Wa_14011224835 for PHY B initialization
After doing normal PHY-B initialization on Rocket Lake, we need to
manually copy some additional PHY-A register values into PHY-B
registers.
Note that the bspec's combo phy page doesn't specify that this
workaround is restricted to specific platform steppings (and doesn't
even do a very good job of specifying that RKL is the only platform this
is needed on), but the RKL workaround page lists this as relevant only
for A and B steppings, so I'm trusting that information for now.
v2: Make rkl_combo_phy_b_init_wa() static
Bspec: 49291
Bspec: 53273
Signed-off-by: Matt Roper
---
.../gpu/drm/i915/display/intel_combo_phy.c| 26 +++
drivers/gpu/drm/i915/i915_reg.h | 13 +-
2 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
b/drivers/gpu/drm/i915/display/intel_combo_phy.c
index 77b04bb3ec62..d5d95e2746c2 100644
--- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
@@ -338,6 +338,27 @@ void intel_combo_phy_power_up_lanes(struct
drm_i915_private *dev_priv,
intel_de_write(dev_priv, ICL_PORT_CL_DW10(phy), val);
}
+static void rkl_combo_phy_b_init_wa(struct drm_i915_private *i915)
+{
+ u32 grccode, grccode_ldo;
+ u32 iref_rcal_ord, rcompcode_ld_cap_ov;
+
+ intel_de_wait_for_register(i915, ICL_PORT_COMP_DW3(PHY_A),
+ FIRST_COMP_DONE, FIRST_COMP_DONE, 100);
+
+ grccode = REG_FIELD_GET(GRCCODE,
+ intel_de_read(i915, ICL_PORT_COMP_DW6(PHY_A)));
+ iref_rcal_ord = REG_FIELD_PREP(IREF_RCAL_ORD, grccode);
+ intel_de_rmw(i915, ICL_PORT_COMP_DW2(PHY_B), IREF_RCAL_ORD,
+iref_rcal_ord | IREF_RCAL_ORD_EN);
+
+ grccode_ldo = REG_FIELD_GET(GRCCODE_LDO,
+ intel_de_read(i915,
ICL_PORT_COMP_DW0(PHY_A)));
+ rcompcode_ld_cap_ov = REG_FIELD_PREP(RCOMPCODE_LD_CAP_OV, grccode_ldo);
+ intel_de_rmw(i915, ICL_PORT_COMP_DW6(PHY_B), RCOMPCODE_LD_CAP_OV,
+rcompcode_ld_cap_ov | RCOMPCODEOVEN_LDO_SYNC);
+}
+
static void icl_combo_phys_init(struct drm_i915_private *dev_priv)
{
enum phy phy;
@@ -390,6 +411,11 @@ static void icl_combo_phys_init(struct drm_i915_private
*dev_priv)
val = intel_de_read(dev_priv, ICL_PORT_CL_DW5(phy));
val |= CL_POWER_DOWN_ENABLE;
intel_de_write(dev_priv, ICL_PORT_CL_DW5(phy), val);
+
+ if (IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_B0) &&
+ phy == PHY_B)
+ /* Wa_14011224835:rkl[a0..c0] */
+ rkl_combo_phy_b_init_wa(dev_priv);
}
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 34b2ec04ccd8..10f6e46523b6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1908,11 +1908,16 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define CNL_PORT_COMP_DW0 _MMIO(0x162100)
#define ICL_PORT_COMP_DW0(phy) _MMIO(_ICL_PORT_COMP_DW(0, phy))
-#define COMP_INIT(1 << 31)
+#define COMP_INITREG_BIT(31)
+#define GRCCODE_LDO REG_GENMASK(7, 0)
#define CNL_PORT_COMP_DW1 _MMIO(0x162104)
#define ICL_PORT_COMP_DW1(phy) _MMIO(_ICL_PORT_COMP_DW(1, phy))
+#define ICL_PORT_COMP_DW2(phy) _MMIO(_ICL_PORT_COMP_DW(2, phy))
+#define IREF_RCAL_ORD_EN REG_BIT(7)
+#define IREF_RCAL_ORDREG_GENMASK(6, 0)
+
#define CNL_PORT_COMP_DW3 _MMIO(0x16210c)
#define ICL_PORT_COMP_DW3(phy) _MMIO(_ICL_PORT_COMP_DW(3, phy))
#define PROCESS_INFO_DOT_0 (0 << 26)
@@ -1925,6 +1930,12 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define VOLTAGE_INFO_1_05V (2 << 24)
#define VOLTAGE_INFO_MASK(3 << 24)
#define VOLTAGE_INFO_SHIFT 24
+#define FIRST_COMP_DONE REG_BIT(22)
+
+#define ICL_PORT_COMP_DW6(phy) _MMIO(_ICL_PORT_COMP_DW(6, phy))
+#define GRCCODE REG_GENMASK(30, 24)
+#define RCOMPCODEOVEN_LDO_SYNC REG_BIT(23)
+#define RCOMPCODE_LD_CAP_OV REG_GENMASK(22, 16)
#define ICL_PORT_COMP_DW8(phy) _MMIO(_ICL_PORT_COMP_DW(8, phy))
#define IREFGEN (1 << 24)
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 4/5] drm/i915/rkl: Add initial workarounds
RKL and TGL share some general gen12 workarounds, but each platform also
has its own platform-specific workarounds.
v2:
- Add Wa_1604555607 for RKL. This makes RKL's ctx WA list identical to
TGL's, so we'll have both functions call the tgl_ function for now;
this workaround isn't listed for DG1 so we don't want to add it to
the general gen12_ function.
Cc: Matt Atwood
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_sprite.c | 5 +-
drivers/gpu/drm/i915/gt/intel_workarounds.c | 88 +
2 files changed, 59 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 3cd461bf9131..63ac79f88fa2 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -2842,8 +2842,9 @@ static bool skl_plane_format_mod_supported(struct
drm_plane *_plane,
static bool gen12_plane_supports_mc_ccs(struct drm_i915_private *dev_priv,
enum plane_id plane_id)
{
- /* Wa_14010477008:tgl[a0..c0] */
- if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_C0))
+ /* Wa_14010477008:tgl[a0..c0],rkl[all] */
+ if (IS_ROCKETLAKE(dev_priv) ||
+ IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_C0))
return false;
return plane_id < PLANE_SPRITE4;
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 2da366821dda..741710ca2b9a 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -596,8 +596,8 @@ static void icl_ctx_workarounds_init(struct intel_engine_cs
*engine,
wa_masked_en(wal, GEN9_ROW_CHICKEN4, GEN11_DIS_PICK_2ND_EU);
}
-static void tgl_ctx_workarounds_init(struct intel_engine_cs *engine,
-struct i915_wa_list *wal)
+static void gen12_ctx_workarounds_init(struct intel_engine_cs *engine,
+ struct i915_wa_list *wal)
{
/*
* Wa_1409142259:tgl
@@ -607,12 +607,28 @@ static void tgl_ctx_workarounds_init(struct
intel_engine_cs *engine,
* Wa_1409207793:tgl
* Wa_1409178076:tgl
* Wa_1408979724:tgl
+* Wa_14010443199:rkl
+* Wa_14010698770:rkl
*/
WA_SET_BIT_MASKED(GEN11_COMMON_SLICE_CHICKEN3,
GEN12_DISABLE_CPS_AWARE_COLOR_PIPE);
+ /* WaDisableGPGPUMidThreadPreemption:gen12 */
+ WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1,
+ GEN9_PREEMPT_GPGPU_LEVEL_MASK,
+ GEN9_PREEMPT_GPGPU_THREAD_GROUP_LEVEL);
+}
+
+static void tgl_ctx_workarounds_init(struct intel_engine_cs *engine,
+struct i915_wa_list *wal)
+{
+ gen12_ctx_workarounds_init(engine, wal);
+
/*
-* Wa_1604555607:gen12 and Wa_1608008084:gen12
+* Wa_1604555607:tgl,rkl
+*
+* Note that the implementation of this workaround is further modified
+* according to the FF_MODE2 guidance given by Wa_1608008084:gen12.
* FF_MODE2 register will return the wrong value when read. The default
* value for this register is zero for all fields and there are no bit
* masks. So instead of doing a RMW we should just write the GS Timer
@@ -623,11 +639,6 @@ static void tgl_ctx_workarounds_init(struct
intel_engine_cs *engine,
FF_MODE2_GS_TIMER_MASK | FF_MODE2_TDS_TIMER_MASK,
FF_MODE2_GS_TIMER_224 | FF_MODE2_TDS_TIMER_128,
0);
-
- /* WaDisableGPGPUMidThreadPreemption:tgl */
- WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1,
- GEN9_PREEMPT_GPGPU_LEVEL_MASK,
- GEN9_PREEMPT_GPGPU_THREAD_GROUP_LEVEL);
}
static void
@@ -642,8 +653,10 @@ __intel_engine_init_ctx_wa(struct intel_engine_cs *engine,
wa_init_start(wal, name, engine->name);
- if (IS_GEN(i915, 12))
+ if (IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915))
tgl_ctx_workarounds_init(engine, wal);
+ else if (IS_GEN(i915, 12))
+ gen12_ctx_workarounds_init(engine, wal);
else if (IS_GEN(i915, 11))
icl_ctx_workarounds_init(engine, wal);
else if (IS_CANNONLAKE(i915))
@@ -1176,9 +1189,16 @@ icl_gt_workarounds_init(struct drm_i915_private *i915,
struct i915_wa_list *wal)
}
static void
-tgl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
+gen12_gt_workarounds_init(struct drm_i915_private *i915,
+ struct i915_wa_list *wal)
{
wa_init_mcr(i915, wal);
+}
+
+static void
+tgl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
+{
+ gen12_gt_workarounds_init(i915, wal);
/* Wa_1409420604:tgl */
if (IS_TGL_REVID(i915, TGL_REVID_A0, TGL_REVID_A0))
@@ -1196,8
[Intel-gfx] [PATCH v7 2/5] drm/i915/rkl: Add DPLL4 support
Rocket Lake has a third DPLL (called 'DPLL4') that must be used to
enable a third display. Unlike EHL's variant of DPLL4, the RKL variant
behaves the same as DPLL0/1. And despite its name, the DPLL4 registers
are offset as if it were DPLL2.
To allow the TGL register selectors like TGL_DPLL_CFGCR0 to be used
seamlessly on all gen12 platforms, we set the non-MG PLL ID's to match
how the registers are laid out: DPLL0, DPLL1, DPLL4 (RKL-only), TBT.
This means just renumbering TBT to be ID '3' rather than being another
ID '2' like DPLL4. With this change, we can build our register
selectors with _MMIO_PLL rather than _MMIO_PLL3 since the register
offsets are evenly-spaced. MGPLL's don't need any specific ID's
(they're just used to translate back to a tc_port), so we let them float
at the top of the enum.
v2:
- Add new .update_ref_clks() hook.
v3:
- Renumber TBT PLL to '3' and switch _MMIO_PLL3 to _MMIO_PLL (Lucas)
Bspec: 49202
Bspec: 49443
Bspec: 50288
Bspec: 50289
Cc: Lucas De Marchi
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 29 +--
drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 14 -
drivers/gpu/drm/i915/i915_reg.h | 15 +++---
3 files changed, 37 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index b45185b80bec..b5f4d4cef682 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -3506,13 +3506,19 @@ static bool icl_get_combo_phy_dpll(struct
intel_atomic_state *state,
return false;
}
- if (IS_ELKHARTLAKE(dev_priv) && port != PORT_A)
+ if (IS_ROCKETLAKE(dev_priv)) {
dpll_mask =
BIT(DPLL_ID_EHL_DPLL4) |
BIT(DPLL_ID_ICL_DPLL1) |
BIT(DPLL_ID_ICL_DPLL0);
- else
+ } else if (IS_ELKHARTLAKE(dev_priv) && port != PORT_A) {
+ dpll_mask =
+ BIT(DPLL_ID_EHL_DPLL4) |
+ BIT(DPLL_ID_ICL_DPLL1) |
+ BIT(DPLL_ID_ICL_DPLL0);
+ } else {
dpll_mask = BIT(DPLL_ID_ICL_DPLL1) | BIT(DPLL_ID_ICL_DPLL0);
+ }
port_dpll->pll = intel_find_shared_dpll(state, crtc,
&port_dpll->hw_state,
@@ -4275,6 +4281,21 @@ static const struct intel_dpll_mgr tgl_pll_mgr = {
.dump_hw_state = icl_dump_hw_state,
};
+static const struct dpll_info rkl_plls[] = {
+ { "DPLL 0", &combo_pll_funcs, DPLL_ID_ICL_DPLL0, 0 },
+ { "DPLL 1", &combo_pll_funcs, DPLL_ID_ICL_DPLL1, 0 },
+ { "DPLL 4", &combo_pll_funcs, DPLL_ID_EHL_DPLL4, 0 },
+ { },
+};
+
+static const struct intel_dpll_mgr rkl_pll_mgr = {
+ .dpll_info = rkl_plls,
+ .get_dplls = icl_get_dplls,
+ .put_dplls = icl_put_dplls,
+ .update_ref_clks = icl_update_dpll_ref_clks,
+ .dump_hw_state = icl_dump_hw_state,
+};
+
/**
* intel_shared_dpll_init - Initialize shared DPLLs
* @dev: drm device
@@ -4288,7 +4309,9 @@ void intel_shared_dpll_init(struct drm_device *dev)
const struct dpll_info *dpll_info;
int i;
- if (INTEL_GEN(dev_priv) >= 12)
+ if (IS_ROCKETLAKE(dev_priv))
+ dpll_mgr = &rkl_pll_mgr;
+ else if (INTEL_GEN(dev_priv) >= 12)
dpll_mgr = &tgl_pll_mgr;
else if (IS_ELKHARTLAKE(dev_priv))
dpll_mgr = &ehl_pll_mgr;
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
index 5d9a2bc371e7..49367847bfb5 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
@@ -125,35 +125,35 @@ enum intel_dpll_id {
/**
* @DPLL_ID_ICL_TBTPLL: ICL/TGL TBT PLL
*/
- DPLL_ID_ICL_TBTPLL = 2,
+ DPLL_ID_ICL_TBTPLL = 3,
/**
* @DPLL_ID_ICL_MGPLL1: ICL MG PLL 1 port 1 (C),
* TGL TC PLL 1 port 1 (TC1)
*/
- DPLL_ID_ICL_MGPLL1 = 3,
+ DPLL_ID_ICL_MGPLL1,
/**
* @DPLL_ID_ICL_MGPLL2: ICL MG PLL 1 port 2 (D)
* TGL TC PLL 1 port 2 (TC2)
*/
- DPLL_ID_ICL_MGPLL2 = 4,
+ DPLL_ID_ICL_MGPLL2,
/**
* @DPLL_ID_ICL_MGPLL3: ICL MG PLL 1 port 3 (E)
* TGL TC PLL 1 port 3 (TC3)
*/
- DPLL_ID_ICL_MGPLL3 = 5,
+ DPLL_ID_ICL_MGPLL3,
/**
* @DPLL_ID_ICL_MGPLL4: ICL MG PLL 1 port 4 (F)
* TGL TC PLL 1 port 4 (TC4)
*/
- DPLL_ID_ICL_MGPLL4 = 6,
+ DPLL_ID_ICL_MGPLL4,
/**
* @DPLL_ID_TGL_MGPLL5: TGL TC PLL port 5 (TC5)
*/
- DPLL_ID_TGL_MGPLL5 = 7,
+ DPLL_ID_TGL_MGPLL5,
/**
* @DPLL_ID_TGL_MGPLL6: TGL TC PLL port 6 (TC6)
[Intel-gfx] [PATCH v7 1/5] drm/i915/rkl: Handle new DPCLKA_CFGCR0 layout
RKL uses a slightly different bit layout for the DPCLKA_CFGCR0 register.
v2:
- Fix inverted mask application when updating ICL_DPCLKA_CFGCR0
- Checkpatch style fixes
Bspec: 50287
Cc: Aditya Swarup
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_ddi.c | 18 +++---
drivers/gpu/drm/i915/display/intel_display.c | 15 ---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
3 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index ca7bb2294d2b..8790f221dc77 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2770,7 +2770,9 @@ hsw_set_signal_levels(struct intel_dp *intel_dp)
static u32 icl_dpclka_cfgcr0_clk_off(struct drm_i915_private *dev_priv,
enum phy phy)
{
- if (intel_phy_is_combo(dev_priv, phy)) {
+ if (IS_ROCKETLAKE(dev_priv)) {
+ return RKL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
+ } else if (intel_phy_is_combo(dev_priv, phy)) {
return ICL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
} else if (intel_phy_is_tc(dev_priv, phy)) {
enum tc_port tc_port = intel_port_to_tc(dev_priv,
@@ -2797,6 +2799,16 @@ static void icl_map_plls_to_ports(struct intel_encoder
*encoder,
(val & icl_dpclka_cfgcr0_clk_off(dev_priv, phy)) == 0);
if (intel_phy_is_combo(dev_priv, phy)) {
+ u32 mask, sel;
+
+ if (IS_ROCKETLAKE(dev_priv)) {
+ mask = RKL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
+ sel = RKL_DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, phy);
+ } else {
+ mask = ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
+ sel = ICL_DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, phy);
+ }
+
/*
* Even though this register references DDIs, note that we
* want to pass the PHY rather than the port (DDI). For
@@ -2807,8 +2819,8 @@ static void icl_map_plls_to_ports(struct intel_encoder
*encoder,
* Clock Select chooses the PLL for both DDIA and DDID and
* drives port A in all cases."
*/
- val &= ~ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
- val |= ICL_DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, phy);
+ val &= ~mask;
+ val |= sel;
intel_de_write(dev_priv, ICL_DPCLKA_CFGCR0, val);
intel_de_posting_read(dev_priv, ICL_DPCLKA_CFGCR0);
}
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 7457813ef273..6c2bb3354b86 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10785,9 +10785,18 @@ static void icl_get_ddi_pll(struct drm_i915_private
*dev_priv, enum port port,
u32 temp;
if (intel_phy_is_combo(dev_priv, phy)) {
- temp = intel_de_read(dev_priv, ICL_DPCLKA_CFGCR0) &
- ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
- id = temp >> ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy);
+ u32 mask, shift;
+
+ if (IS_ROCKETLAKE(dev_priv)) {
+ mask = RKL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
+ shift = RKL_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy);
+ } else {
+ mask = ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
+ shift = ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy);
+ }
+
+ temp = intel_de_read(dev_priv, ICL_DPCLKA_CFGCR0) & mask;
+ id = temp >> shift;
port_dpll_id = ICL_PORT_DPLL_DEFAULT;
} else if (intel_phy_is_tc(dev_priv, phy)) {
u32 clk_sel = intel_de_read(dev_priv, DDI_CLK_SEL(port)) &
DDI_CLK_SEL_MASK;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f09120cac89a..45bda5819abd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10195,12 +10195,18 @@ enum skl_power_gate {
#define ICL_DPCLKA_CFGCR0 _MMIO(0x164280)
#define ICL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy)(1 << _PICK(phy, 10, 11, 24))
+#define RKL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy)REG_BIT((phy) + 10)
#define ICL_DPCLKA_CFGCR0_TC_CLK_OFF(tc_port) (1 << ((tc_port) < PORT_TC4 ? \
(tc_port) + 12 : \
(tc_port) - PORT_TC4 +
21))
#define ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy) ((phy) * 2)
#define ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy) (3 <<
ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy))
#define ICL_DPCLKA_CFGCR0_DDI_CLK_SEL(pll, phy) ((pll) <<
ICL_DPCLKA_CFGCR0_DDI_CLK_SEL
[Intel-gfx] [PATCH v7 3/5] drm/i915/rkl: Handle HTI
If HTI (also sometimes called HDPORT) is enabled at startup, it may be
using some of the PHYs and DPLLs making them unavailable for general
usage. Let's read out the HDPORT_STATE register and avoid making use of
resources that HTI is already using.
v2:
- Fix minor checkpatch warnings
Bspec: 49189
Bspec: 53707
Cc: Lucas De Marchi
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_display.c | 30 ---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 21 +
drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 1 +
drivers/gpu/drm/i915/i915_drv.h | 3 ++
drivers/gpu/drm/i915/i915_reg.h | 6
5 files changed, 57 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 6c2bb3354b86..f16512eddc58 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -46,6 +46,7 @@
#include "display/intel_ddi.h"
#include "display/intel_dp.h"
#include "display/intel_dp_mst.h"
+#include "display/intel_dpll_mgr.h"
#include "display/intel_dsi.h"
#include "display/intel_dvo.h"
#include "display/intel_gmbus.h"
@@ -16814,6 +16815,13 @@ static void intel_pps_init(struct drm_i915_private
*dev_priv)
intel_pps_unlock_regs_wa(dev_priv);
}
+static bool hti_uses_phy(u32 hdport_state, enum phy phy)
+{
+ return hdport_state & HDPORT_ENABLED &&
+ (hdport_state & HDPORT_PHY_USED_DP(phy) ||
+hdport_state & HDPORT_PHY_USED_HDMI(phy));
+}
+
static void intel_setup_outputs(struct drm_i915_private *dev_priv)
{
struct intel_encoder *encoder;
@@ -16825,10 +16833,22 @@ static void intel_setup_outputs(struct
drm_i915_private *dev_priv)
return;
if (IS_ROCKETLAKE(dev_priv)) {
- intel_ddi_init(dev_priv, PORT_A);
- intel_ddi_init(dev_priv, PORT_B);
- intel_ddi_init(dev_priv, PORT_D); /* DDI TC1 */
- intel_ddi_init(dev_priv, PORT_E); /* DDI TC2 */
+ /*
+* If HTI (aka HDPORT) is enabled at boot, it may have taken
+* over some of the PHYs and made them unavailable to the
+* driver. In that case we should skip initializing the
+* corresponding outputs.
+*/
+ u32 hdport_state = intel_de_read(dev_priv, HDPORT_STATE);
+
+ if (!hti_uses_phy(hdport_state, PHY_A))
+ intel_ddi_init(dev_priv, PORT_A);
+ if (!hti_uses_phy(hdport_state, PHY_B))
+ intel_ddi_init(dev_priv, PORT_B);
+ if (!hti_uses_phy(hdport_state, PHY_C))
+ intel_ddi_init(dev_priv, PORT_D); /* DDI TC1 */
+ if (!hti_uses_phy(hdport_state, PHY_D))
+ intel_ddi_init(dev_priv, PORT_E); /* DDI TC2 */
} else if (INTEL_GEN(dev_priv) >= 12) {
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_B);
@@ -18376,6 +18396,8 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
intel_dpll_readout_hw_state(dev_priv);
+ dev_priv->hti_pll_mask = intel_get_hti_plls(dev_priv);
+
for_each_intel_encoder(dev, encoder) {
pipe = 0;
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index b5f4d4cef682..6f59f9ec453b 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -265,6 +265,24 @@ void intel_disable_shared_dpll(const struct
intel_crtc_state *crtc_state)
mutex_unlock(&dev_priv->dpll.lock);
}
+/*
+ * HTI (aka HDPORT) may be using some of the platform's PLL's, making them
+ * unavailable for use.
+ */
+u32 intel_get_hti_plls(struct drm_i915_private *dev_priv)
+{
+ u32 hdport_state;
+
+ if (!IS_ROCKETLAKE(dev_priv))
+ return 0;
+
+ hdport_state = intel_de_read(dev_priv, HDPORT_STATE);
+ if (!(hdport_state & HDPORT_ENABLED))
+ return 0;
+
+ return REG_FIELD_GET(HDPORT_DPLL_USED_MASK, hdport_state);
+}
+
static struct intel_shared_dpll *
intel_find_shared_dpll(struct intel_atomic_state *state,
const struct intel_crtc *crtc,
@@ -280,6 +298,9 @@ intel_find_shared_dpll(struct intel_atomic_state *state,
drm_WARN_ON(&dev_priv->drm, dpll_mask & ~(BIT(I915_NUM_PLLS) - 1));
+ /* Eliminate DPLLs from consideration if reserved by HTI */
+ dpll_mask &= ~dev_priv->hti_pll_mask;
+
for_each_set_bit(i, &dpll_mask, I915_NUM_PLLS) {
pll = &dev_priv->dpll.shared_dplls[i];
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
index 49367847bfb5..edcc43f4670f 100644
--- a/drivers/gpu/drm/i915/display/in
[Intel-gfx] [PATCH v7 0/5] Remaining RKL patches
Changes since v6: - Renumber TGL's TBT PLL so that the same TGL PLL selector macros can be used seamlessly on all gen12 platforms. (Lucas) - Make the PHY initialization WA function static Matt Roper (5): drm/i915/rkl: Handle new DPCLKA_CFGCR0 layout drm/i915/rkl: Add DPLL4 support drm/i915/rkl: Handle HTI drm/i915/rkl: Add initial workarounds drm/i915/rkl: Add Wa_14011224835 for PHY B initialization .../gpu/drm/i915/display/intel_combo_phy.c| 26 ++ drivers/gpu/drm/i915/display/intel_ddi.c | 18 +++- drivers/gpu/drm/i915/display/intel_display.c | 45 -- drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 50 ++- drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 15 ++-- drivers/gpu/drm/i915/display/intel_sprite.c | 5 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 88 --- drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/i915_reg.h | 40 ++--- 9 files changed, 224 insertions(+), 66 deletions(-) -- 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 linux-next: build failure after merge of the drm-misc tree
== Series Details ==
Series: linux-next: build failure after merge of the drm-misc tree
URL : https://patchwork.freedesktop.org/series/78444/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8638 -> Patchwork_17974
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17974/index.html
Known issues
Here are the changes found in Patchwork_17974 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8638/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17974/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-tgl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#402])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8638/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17974/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
Possible fixes
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [DMESG-WARN][5] ([i915#95]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8638/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17974/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@active:
- fi-icl-y: [DMESG-FAIL][7] ([i915#765]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8638/fi-icl-y/igt@i915_selftest@l...@active.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17974/fi-icl-y/igt@i915_selftest@l...@active.html
* igt@i915_selftest@live@gt_lrc:
- fi-tgl-u2: [DMESG-FAIL][9] ([i915#1233]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8638/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17974/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][12] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8638/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17974/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [SKIP][13] ([fdo#109271]) -> [DMESG-FAIL][14]
([i915#62])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8638/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17974/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92]) ->
[DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8638/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17974/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-modeset@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +3 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8638/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17974/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.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#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#1569]: https://gitlab.freedesktop.org/drm/intel/issues/1569
[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#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#765]: https://gitlab.freedesktop.org/drm/intel/issues/765
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issue
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for linux-next: build failure after merge of the drm-misc tree
== Series Details ==
Series: linux-next: build failure after merge of the drm-misc tree
URL : https://patchwork.freedesktop.org/series/78444/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5bf216c35bb2 linux-next: build failure after merge of the drm-misc tree
-:19: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit ab15d56e27be ("drm: remove
transient drm_gem_object_put_unlocked()")'
#19:
ab15d56e27be ("drm: remove transient drm_gem_object_put_unlocked()")
-:23: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit fd9a9f8801de ("drm/amdgpu: Use
GEM obj reference for KFD BOs")'
#23:
fd9a9f8801de ("drm/amdgpu: Use GEM obj reference for KFD BOs")
total: 2 errors, 0 warnings, 0 checks, 8 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 Remaining RKL patches (rev5)
== Series Details == Series: Remaining RKL patches (rev5) URL : https://patchwork.freedesktop.org/series/77971/ State : success == Summary == CI Bug Log - changes from CI_DRM_8637 -> Patchwork_17973 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17973/index.html Known issues Here are the changes found in Patchwork_17973 that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@reload: - fi-byt-j1900: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/fi-byt-j1900/igt@i915_module_l...@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17973/fi-byt-j1900/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17973/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html * igt@kms_busy@basic@flip: - fi-kbl-x1275: [PASS][5] -> [DMESG-WARN][6] ([i915#62] / [i915#92] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/fi-kbl-x1275/igt@kms_busy@ba...@flip.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17973/fi-kbl-x1275/igt@kms_busy@ba...@flip.html * igt@kms_cursor_legacy@basic-flip-after-cursor-legacy: - fi-icl-guc: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/fi-icl-guc/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17973/fi-icl-guc/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1: - fi-icl-u2: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17973/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html Possible fixes * igt@gem_exec_suspend@basic-s0: - fi-tgl-u2: [FAIL][11] ([i915#1888]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17973/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html * igt@i915_pm_rpm@module-reload: - fi-glk-dsi: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/fi-glk-dsi/igt@i915_pm_...@module-reload.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17973/fi-glk-dsi/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@execlists: - fi-icl-y: [INCOMPLETE][15] -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/fi-icl-y/igt@i915_selftest@l...@execlists.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17973/fi-icl-y/igt@i915_selftest@l...@execlists.html * igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1: - fi-icl-u2: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17973/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [SKIP][19] ([fdo#109271]) -> [DMESG-FAIL][20] ([i915#62]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17973/fi-kbl-x1275/igt@i915_pm_...@module-reload.html * igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size: - fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92]) -> [DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17973/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html * igt@kms_force_connector_basic@force-edid: - fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][24] ([i915#62] / [i915#92]) +6 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17973/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [fdo#109271]:
Re: [Intel-gfx] [PATCH v6 2/5] drm/i915/rkl: Add DPLL4 support
On Tue, Jun 16, 2020 at 04:58:07PM -0700, Matt Roper wrote:
Rocket Lake has a third DPLL (called 'DPLL4') that must be used to
enable a third display. Unlike EHL's variant of DPLL4, the RKL variant
behaves the same as DPLL0/1. And despite its name, the DPLL4 registers
are offset as if it were DPLL2, so no extra offset handling is needed
either.
v2:
- Add new .update_ref_clks() hook.
Bspec: 49202
Bspec: 49443
Bspec: 50288
Bspec: 50289
Cc: Lucas De Marchi
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 29 +--
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index b45185b80bec..b5f4d4cef682 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -3506,13 +3506,19 @@ static bool icl_get_combo_phy_dpll(struct
intel_atomic_state *state,
return false;
}
- if (IS_ELKHARTLAKE(dev_priv) && port != PORT_A)
+ if (IS_ROCKETLAKE(dev_priv)) {
dpll_mask =
BIT(DPLL_ID_EHL_DPLL4) |
BIT(DPLL_ID_ICL_DPLL1) |
BIT(DPLL_ID_ICL_DPLL0);
I don't think that is sufficient. As you said in the commit message,
here DPLL4 are much like DPLL0, DPLL1 rather than the special treatment
it has in EHL.
That means we need to update the places making use of it. Example:
TGL_DPLL_CFGCR0()
TGL_DPLL_CFGCR1()
The way it is now, it would basically be using the address
0x16429C / 0x1642A0 that are actually for TBT
Looking at bspec 50288, it seems we should reorder the IDs to be
DPLL0, DPLL1, DPLL4, TBTPLL. Then we can go back and use _MMIO_PLL()
rather than _MMIO_PLL3(). There is even a "TODO" in the right place in
the source code for that, although I don't remember if in TGL it has any
special. I think we never added it for TGL just because with 2 combo
ports you will never need 3 PLLs.
Lucas De Marchi
- else
+ } else if (IS_ELKHARTLAKE(dev_priv) && port != PORT_A) {
+ dpll_mask =
+ BIT(DPLL_ID_EHL_DPLL4) |
+ BIT(DPLL_ID_ICL_DPLL1) |
+ BIT(DPLL_ID_ICL_DPLL0);
+ } else {
dpll_mask = BIT(DPLL_ID_ICL_DPLL1) | BIT(DPLL_ID_ICL_DPLL0);
+ }
port_dpll->pll = intel_find_shared_dpll(state, crtc,
&port_dpll->hw_state,
@@ -4275,6 +4281,21 @@ static const struct intel_dpll_mgr tgl_pll_mgr = {
.dump_hw_state = icl_dump_hw_state,
};
+static const struct dpll_info rkl_plls[] = {
+ { "DPLL 0", &combo_pll_funcs, DPLL_ID_ICL_DPLL0, 0 },
+ { "DPLL 1", &combo_pll_funcs, DPLL_ID_ICL_DPLL1, 0 },
+ { "DPLL 4", &combo_pll_funcs, DPLL_ID_EHL_DPLL4, 0 },
+ { },
+};
+
+static const struct intel_dpll_mgr rkl_pll_mgr = {
+ .dpll_info = rkl_plls,
+ .get_dplls = icl_get_dplls,
+ .put_dplls = icl_put_dplls,
+ .update_ref_clks = icl_update_dpll_ref_clks,
+ .dump_hw_state = icl_dump_hw_state,
+};
+
/**
* intel_shared_dpll_init - Initialize shared DPLLs
* @dev: drm device
@@ -4288,7 +4309,9 @@ void intel_shared_dpll_init(struct drm_device *dev)
const struct dpll_info *dpll_info;
int i;
- if (INTEL_GEN(dev_priv) >= 12)
+ if (IS_ROCKETLAKE(dev_priv))
+ dpll_mgr = &rkl_pll_mgr;
+ else if (INTEL_GEN(dev_priv) >= 12)
dpll_mgr = &tgl_pll_mgr;
else if (IS_ELKHARTLAKE(dev_priv))
dpll_mgr = &ehl_pll_mgr;
--
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] linux-next: build failure after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c: In function
'amdgpu_amdkfd_gpuvm_free_memory_of_gpu':
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:1357:2: error: implicit
declaration of function 'drm_gem_object_put_unlocked'; did you mean
'drm_gem_object_put_locked'? [-Werror=implicit-function-declaration]
1357 | drm_gem_object_put_unlocked(&mem->bo->tbo.base);
| ^~~
| drm_gem_object_put_locked
Caused by commit
ab15d56e27be ("drm: remove transient drm_gem_object_put_unlocked()")
interacting with commit
fd9a9f8801de ("drm/amdgpu: Use GEM obj reference for KFD BOs")
from Linus' tree.
I have applied the following merge fix up patch for today.
From: Stephen Rothwell
Date: Wed, 17 Jun 2020 10:55:32 +1000
Subject: [PATCH] drm/amdgpu: remove stray drm_gem_object_put_unlocked
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index b91b5171270f..9015c7b76d60 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1354,7 +1354,7 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
}
/* Free the BO*/
- drm_gem_object_put_unlocked(&mem->bo->tbo.base);
+ drm_gem_object_put(&mem->bo->tbo.base);
mutex_destroy(&mem->lock);
kfree(mem);
--
2.26.2
--
Cheers,
Stephen Rothwell
pgp3Ygr2S8ELT.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.SPARSE: warning for Remaining RKL patches (rev5)
== Series Details == Series: Remaining RKL patches (rev5) URL : https://patchwork.freedesktop.org/series/77971/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. +drivers/gpu/drm/i915/display/intel_combo_phy.c:341:6: warning: symbol 'rkl_combo_phy_b_init_wa' was not declared. Should it be static? ___ 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/selftests: Check preemption rollback of different ring queue depths (rev2)
== Series Details == Series: drm/i915/selftests: Check preemption rollback of different ring queue depths (rev2) URL : https://patchwork.freedesktop.org/series/78411/ State : success == Summary == CI Bug Log - changes from CI_DRM_8637 -> Patchwork_17972 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17972/index.html Known issues Here are the changes found in Patchwork_17972 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@basic-pci-d3-state: - fi-byt-n2820: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/fi-byt-n2820/igt@i915_pm_...@basic-pci-d3-state.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17972/fi-byt-n2820/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_pm_rpm@module-reload: - fi-apl-guc: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/fi-apl-guc/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17972/fi-apl-guc/igt@i915_pm_...@module-reload.html * igt@kms_cursor_legacy@basic-flip-before-cursor-legacy: - fi-icl-guc: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/fi-icl-guc/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17972/fi-icl-guc/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html Possible fixes * igt@i915_pm_rpm@module-reload: - fi-bsw-n3050: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/fi-bsw-n3050/igt@i915_pm_...@module-reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17972/fi-bsw-n3050/igt@i915_pm_...@module-reload.html - fi-glk-dsi: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/fi-glk-dsi/igt@i915_pm_...@module-reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17972/fi-glk-dsi/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@execlists: - fi-icl-y: [INCOMPLETE][11] -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/fi-icl-y/igt@i915_selftest@l...@execlists.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17972/fi-icl-y/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gt_lrc: - fi-tgl-u2: [DMESG-FAIL][13] ([i915#1233]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17972/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-icl-guc: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/fi-icl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17972/fi-icl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1: - fi-icl-u2: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17972/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) -> [DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +5 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17972/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [SKIP][21] ([fdo#109271]) -> [DMESG-FAIL][22] ([i915#62]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17972/fi-kbl-x1275/igt@i915_pm_...@module-reload.html * igt@kms_force_connector_basic@force-edid: - fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][24] ([i915#62] / [i915#92]) +5 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8637/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17972/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [fdo#109271]:
[Intel-gfx] linux-next: manual merge of the drm-misc tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/nouveau/nouveau_display.c
between commit:
183405879255 ("drm/nouveau/kms: Remove field nvbo from struct
nouveau_framebuffer")
from Linus' tree and commit:
cdc194cebd71 ("drm/nouveau: remove _unlocked suffix in
drm_gem_object_put_unlocked")
from the drm-misc tree.
I fixed it up (the former just removed one of the functions modified
by the latter) 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
pgpa_qPGIu8OS.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 1/5] drm/i915/rkl: Handle new DPCLKA_CFGCR0 layout
RKL uses a slightly different bit layout for the DPCLKA_CFGCR0 register.
v2:
- Fix inverted mask application when updating ICL_DPCLKA_CFGCR0
- Checkpatch style fixes
Bspec: 50287
Cc: Aditya Swarup
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_ddi.c | 18 +++---
drivers/gpu/drm/i915/display/intel_display.c | 15 ---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
3 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index ca7bb2294d2b..8790f221dc77 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2770,7 +2770,9 @@ hsw_set_signal_levels(struct intel_dp *intel_dp)
static u32 icl_dpclka_cfgcr0_clk_off(struct drm_i915_private *dev_priv,
enum phy phy)
{
- if (intel_phy_is_combo(dev_priv, phy)) {
+ if (IS_ROCKETLAKE(dev_priv)) {
+ return RKL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
+ } else if (intel_phy_is_combo(dev_priv, phy)) {
return ICL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
} else if (intel_phy_is_tc(dev_priv, phy)) {
enum tc_port tc_port = intel_port_to_tc(dev_priv,
@@ -2797,6 +2799,16 @@ static void icl_map_plls_to_ports(struct intel_encoder
*encoder,
(val & icl_dpclka_cfgcr0_clk_off(dev_priv, phy)) == 0);
if (intel_phy_is_combo(dev_priv, phy)) {
+ u32 mask, sel;
+
+ if (IS_ROCKETLAKE(dev_priv)) {
+ mask = RKL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
+ sel = RKL_DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, phy);
+ } else {
+ mask = ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
+ sel = ICL_DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, phy);
+ }
+
/*
* Even though this register references DDIs, note that we
* want to pass the PHY rather than the port (DDI). For
@@ -2807,8 +2819,8 @@ static void icl_map_plls_to_ports(struct intel_encoder
*encoder,
* Clock Select chooses the PLL for both DDIA and DDID and
* drives port A in all cases."
*/
- val &= ~ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
- val |= ICL_DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, phy);
+ val &= ~mask;
+ val |= sel;
intel_de_write(dev_priv, ICL_DPCLKA_CFGCR0, val);
intel_de_posting_read(dev_priv, ICL_DPCLKA_CFGCR0);
}
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 7457813ef273..6c2bb3354b86 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10785,9 +10785,18 @@ static void icl_get_ddi_pll(struct drm_i915_private
*dev_priv, enum port port,
u32 temp;
if (intel_phy_is_combo(dev_priv, phy)) {
- temp = intel_de_read(dev_priv, ICL_DPCLKA_CFGCR0) &
- ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
- id = temp >> ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy);
+ u32 mask, shift;
+
+ if (IS_ROCKETLAKE(dev_priv)) {
+ mask = RKL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
+ shift = RKL_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy);
+ } else {
+ mask = ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
+ shift = ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy);
+ }
+
+ temp = intel_de_read(dev_priv, ICL_DPCLKA_CFGCR0) & mask;
+ id = temp >> shift;
port_dpll_id = ICL_PORT_DPLL_DEFAULT;
} else if (intel_phy_is_tc(dev_priv, phy)) {
u32 clk_sel = intel_de_read(dev_priv, DDI_CLK_SEL(port)) &
DDI_CLK_SEL_MASK;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f09120cac89a..45bda5819abd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10195,12 +10195,18 @@ enum skl_power_gate {
#define ICL_DPCLKA_CFGCR0 _MMIO(0x164280)
#define ICL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy)(1 << _PICK(phy, 10, 11, 24))
+#define RKL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy)REG_BIT((phy) + 10)
#define ICL_DPCLKA_CFGCR0_TC_CLK_OFF(tc_port) (1 << ((tc_port) < PORT_TC4 ? \
(tc_port) + 12 : \
(tc_port) - PORT_TC4 +
21))
#define ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy) ((phy) * 2)
#define ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy) (3 <<
ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy))
#define ICL_DPCLKA_CFGCR0_DDI_CLK_SEL(pll, phy) ((pll) <<
ICL_DPCLKA_CFGCR0_DDI_CLK_SEL
[Intel-gfx] [PATCH v6 5/5] drm/i915/rkl: Add Wa_14011224835 for PHY B initialization
After doing normal PHY-B initialization on Rocket Lake, we need to
manually copy some additional PHY-A register values into PHY-B
registers.
Note that the bspec's combo phy page doesn't specify that this
workaround is restricted to specific platform steppings (and doesn't
even do a very good job of specifying that RKL is the only platform this
is needed on), but the RKL workaround page lists this as relevant only
for A and B steppings, so I'm trusting that information for now.
Bspec: 49291
Bspec: 53273
Signed-off-by: Matt Roper
---
.../gpu/drm/i915/display/intel_combo_phy.c| 26 +++
drivers/gpu/drm/i915/i915_reg.h | 13 +-
2 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
b/drivers/gpu/drm/i915/display/intel_combo_phy.c
index 77b04bb3ec62..53a1b49e305a 100644
--- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
@@ -338,6 +338,27 @@ void intel_combo_phy_power_up_lanes(struct
drm_i915_private *dev_priv,
intel_de_write(dev_priv, ICL_PORT_CL_DW10(phy), val);
}
+void rkl_combo_phy_b_init_wa(struct drm_i915_private *i915)
+{
+ u32 grccode, grccode_ldo;
+ u32 iref_rcal_ord, rcompcode_ld_cap_ov;
+
+ intel_de_wait_for_register(i915, ICL_PORT_COMP_DW3(PHY_A),
+ FIRST_COMP_DONE, FIRST_COMP_DONE, 100);
+
+ grccode = REG_FIELD_GET(GRCCODE,
+ intel_de_read(i915, ICL_PORT_COMP_DW6(PHY_A)));
+ iref_rcal_ord = REG_FIELD_PREP(IREF_RCAL_ORD, grccode);
+ intel_de_rmw(i915, ICL_PORT_COMP_DW2(PHY_B), IREF_RCAL_ORD,
+iref_rcal_ord | IREF_RCAL_ORD_EN);
+
+ grccode_ldo = REG_FIELD_GET(GRCCODE_LDO,
+ intel_de_read(i915,
ICL_PORT_COMP_DW0(PHY_A)));
+ rcompcode_ld_cap_ov = REG_FIELD_PREP(RCOMPCODE_LD_CAP_OV, grccode_ldo);
+ intel_de_rmw(i915, ICL_PORT_COMP_DW6(PHY_B), RCOMPCODE_LD_CAP_OV,
+rcompcode_ld_cap_ov | RCOMPCODEOVEN_LDO_SYNC);
+}
+
static void icl_combo_phys_init(struct drm_i915_private *dev_priv)
{
enum phy phy;
@@ -390,6 +411,11 @@ static void icl_combo_phys_init(struct drm_i915_private
*dev_priv)
val = intel_de_read(dev_priv, ICL_PORT_CL_DW5(phy));
val |= CL_POWER_DOWN_ENABLE;
intel_de_write(dev_priv, ICL_PORT_CL_DW5(phy), val);
+
+ if (IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_B0) &&
+ phy == PHY_B)
+ /* Wa_14011224835:rkl[a0..c0] */
+ rkl_combo_phy_b_init_wa(dev_priv);
}
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 90f11517f656..9c0d0ca14664 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1909,11 +1909,16 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define CNL_PORT_COMP_DW0 _MMIO(0x162100)
#define ICL_PORT_COMP_DW0(phy) _MMIO(_ICL_PORT_COMP_DW(0, phy))
-#define COMP_INIT(1 << 31)
+#define COMP_INITREG_BIT(31)
+#define GRCCODE_LDO REG_GENMASK(7, 0)
#define CNL_PORT_COMP_DW1 _MMIO(0x162104)
#define ICL_PORT_COMP_DW1(phy) _MMIO(_ICL_PORT_COMP_DW(1, phy))
+#define ICL_PORT_COMP_DW2(phy) _MMIO(_ICL_PORT_COMP_DW(2, phy))
+#define IREF_RCAL_ORD_EN REG_BIT(7)
+#define IREF_RCAL_ORDREG_GENMASK(6, 0)
+
#define CNL_PORT_COMP_DW3 _MMIO(0x16210c)
#define ICL_PORT_COMP_DW3(phy) _MMIO(_ICL_PORT_COMP_DW(3, phy))
#define PROCESS_INFO_DOT_0 (0 << 26)
@@ -1926,6 +1931,12 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define VOLTAGE_INFO_1_05V (2 << 24)
#define VOLTAGE_INFO_MASK(3 << 24)
#define VOLTAGE_INFO_SHIFT 24
+#define FIRST_COMP_DONE REG_BIT(22)
+
+#define ICL_PORT_COMP_DW6(phy) _MMIO(_ICL_PORT_COMP_DW(6, phy))
+#define GRCCODE REG_GENMASK(30, 24)
+#define RCOMPCODEOVEN_LDO_SYNC REG_BIT(23)
+#define RCOMPCODE_LD_CAP_OV REG_GENMASK(22, 16)
#define ICL_PORT_COMP_DW8(phy) _MMIO(_ICL_PORT_COMP_DW(8, phy))
#define IREFGEN (1 << 24)
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 2/5] drm/i915/rkl: Add DPLL4 support
Rocket Lake has a third DPLL (called 'DPLL4') that must be used to
enable a third display. Unlike EHL's variant of DPLL4, the RKL variant
behaves the same as DPLL0/1. And despite its name, the DPLL4 registers
are offset as if it were DPLL2, so no extra offset handling is needed
either.
v2:
- Add new .update_ref_clks() hook.
Bspec: 49202
Bspec: 49443
Bspec: 50288
Bspec: 50289
Cc: Lucas De Marchi
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 29 +--
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index b45185b80bec..b5f4d4cef682 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -3506,13 +3506,19 @@ static bool icl_get_combo_phy_dpll(struct
intel_atomic_state *state,
return false;
}
- if (IS_ELKHARTLAKE(dev_priv) && port != PORT_A)
+ if (IS_ROCKETLAKE(dev_priv)) {
dpll_mask =
BIT(DPLL_ID_EHL_DPLL4) |
BIT(DPLL_ID_ICL_DPLL1) |
BIT(DPLL_ID_ICL_DPLL0);
- else
+ } else if (IS_ELKHARTLAKE(dev_priv) && port != PORT_A) {
+ dpll_mask =
+ BIT(DPLL_ID_EHL_DPLL4) |
+ BIT(DPLL_ID_ICL_DPLL1) |
+ BIT(DPLL_ID_ICL_DPLL0);
+ } else {
dpll_mask = BIT(DPLL_ID_ICL_DPLL1) | BIT(DPLL_ID_ICL_DPLL0);
+ }
port_dpll->pll = intel_find_shared_dpll(state, crtc,
&port_dpll->hw_state,
@@ -4275,6 +4281,21 @@ static const struct intel_dpll_mgr tgl_pll_mgr = {
.dump_hw_state = icl_dump_hw_state,
};
+static const struct dpll_info rkl_plls[] = {
+ { "DPLL 0", &combo_pll_funcs, DPLL_ID_ICL_DPLL0, 0 },
+ { "DPLL 1", &combo_pll_funcs, DPLL_ID_ICL_DPLL1, 0 },
+ { "DPLL 4", &combo_pll_funcs, DPLL_ID_EHL_DPLL4, 0 },
+ { },
+};
+
+static const struct intel_dpll_mgr rkl_pll_mgr = {
+ .dpll_info = rkl_plls,
+ .get_dplls = icl_get_dplls,
+ .put_dplls = icl_put_dplls,
+ .update_ref_clks = icl_update_dpll_ref_clks,
+ .dump_hw_state = icl_dump_hw_state,
+};
+
/**
* intel_shared_dpll_init - Initialize shared DPLLs
* @dev: drm device
@@ -4288,7 +4309,9 @@ void intel_shared_dpll_init(struct drm_device *dev)
const struct dpll_info *dpll_info;
int i;
- if (INTEL_GEN(dev_priv) >= 12)
+ if (IS_ROCKETLAKE(dev_priv))
+ dpll_mgr = &rkl_pll_mgr;
+ else if (INTEL_GEN(dev_priv) >= 12)
dpll_mgr = &tgl_pll_mgr;
else if (IS_ELKHARTLAKE(dev_priv))
dpll_mgr = &ehl_pll_mgr;
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 0/5] Remaining RKL patches
Pretty much the same as v5 (and v4). The only changes are: * Extend Wa_1604555607 to RKL in patch #4. * Add display Wa_14011224835 as a new patch #5. Matt Roper (5): drm/i915/rkl: Handle new DPCLKA_CFGCR0 layout drm/i915/rkl: Add DPLL4 support drm/i915/rkl: Handle HTI drm/i915/rkl: Add initial workarounds drm/i915/rkl: Add Wa_14011224835 for PHY B initialization .../gpu/drm/i915/display/intel_combo_phy.c| 26 ++ drivers/gpu/drm/i915/display/intel_ddi.c | 18 +++- drivers/gpu/drm/i915/display/intel_display.c | 45 -- drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 50 ++- drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 1 + drivers/gpu/drm/i915/display/intel_sprite.c | 5 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 88 --- drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/i915_reg.h | 25 +- 9 files changed, 213 insertions(+), 48 deletions(-) -- 2.24.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 3/5] drm/i915/rkl: Handle HTI
If HTI (also sometimes called HDPORT) is enabled at startup, it may be
using some of the PHYs and DPLLs making them unavailable for general
usage. Let's read out the HDPORT_STATE register and avoid making use of
resources that HTI is already using.
v2:
- Fix minor checkpatch warnings
Bspec: 49189
Bspec: 53707
Cc: Lucas De Marchi
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_display.c | 30 ---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 21 +
drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 1 +
drivers/gpu/drm/i915/i915_drv.h | 3 ++
drivers/gpu/drm/i915/i915_reg.h | 6
5 files changed, 57 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 6c2bb3354b86..f16512eddc58 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -46,6 +46,7 @@
#include "display/intel_ddi.h"
#include "display/intel_dp.h"
#include "display/intel_dp_mst.h"
+#include "display/intel_dpll_mgr.h"
#include "display/intel_dsi.h"
#include "display/intel_dvo.h"
#include "display/intel_gmbus.h"
@@ -16814,6 +16815,13 @@ static void intel_pps_init(struct drm_i915_private
*dev_priv)
intel_pps_unlock_regs_wa(dev_priv);
}
+static bool hti_uses_phy(u32 hdport_state, enum phy phy)
+{
+ return hdport_state & HDPORT_ENABLED &&
+ (hdport_state & HDPORT_PHY_USED_DP(phy) ||
+hdport_state & HDPORT_PHY_USED_HDMI(phy));
+}
+
static void intel_setup_outputs(struct drm_i915_private *dev_priv)
{
struct intel_encoder *encoder;
@@ -16825,10 +16833,22 @@ static void intel_setup_outputs(struct
drm_i915_private *dev_priv)
return;
if (IS_ROCKETLAKE(dev_priv)) {
- intel_ddi_init(dev_priv, PORT_A);
- intel_ddi_init(dev_priv, PORT_B);
- intel_ddi_init(dev_priv, PORT_D); /* DDI TC1 */
- intel_ddi_init(dev_priv, PORT_E); /* DDI TC2 */
+ /*
+* If HTI (aka HDPORT) is enabled at boot, it may have taken
+* over some of the PHYs and made them unavailable to the
+* driver. In that case we should skip initializing the
+* corresponding outputs.
+*/
+ u32 hdport_state = intel_de_read(dev_priv, HDPORT_STATE);
+
+ if (!hti_uses_phy(hdport_state, PHY_A))
+ intel_ddi_init(dev_priv, PORT_A);
+ if (!hti_uses_phy(hdport_state, PHY_B))
+ intel_ddi_init(dev_priv, PORT_B);
+ if (!hti_uses_phy(hdport_state, PHY_C))
+ intel_ddi_init(dev_priv, PORT_D); /* DDI TC1 */
+ if (!hti_uses_phy(hdport_state, PHY_D))
+ intel_ddi_init(dev_priv, PORT_E); /* DDI TC2 */
} else if (INTEL_GEN(dev_priv) >= 12) {
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_B);
@@ -18376,6 +18396,8 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
intel_dpll_readout_hw_state(dev_priv);
+ dev_priv->hti_pll_mask = intel_get_hti_plls(dev_priv);
+
for_each_intel_encoder(dev, encoder) {
pipe = 0;
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index b5f4d4cef682..6f59f9ec453b 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -265,6 +265,24 @@ void intel_disable_shared_dpll(const struct
intel_crtc_state *crtc_state)
mutex_unlock(&dev_priv->dpll.lock);
}
+/*
+ * HTI (aka HDPORT) may be using some of the platform's PLL's, making them
+ * unavailable for use.
+ */
+u32 intel_get_hti_plls(struct drm_i915_private *dev_priv)
+{
+ u32 hdport_state;
+
+ if (!IS_ROCKETLAKE(dev_priv))
+ return 0;
+
+ hdport_state = intel_de_read(dev_priv, HDPORT_STATE);
+ if (!(hdport_state & HDPORT_ENABLED))
+ return 0;
+
+ return REG_FIELD_GET(HDPORT_DPLL_USED_MASK, hdport_state);
+}
+
static struct intel_shared_dpll *
intel_find_shared_dpll(struct intel_atomic_state *state,
const struct intel_crtc *crtc,
@@ -280,6 +298,9 @@ intel_find_shared_dpll(struct intel_atomic_state *state,
drm_WARN_ON(&dev_priv->drm, dpll_mask & ~(BIT(I915_NUM_PLLS) - 1));
+ /* Eliminate DPLLs from consideration if reserved by HTI */
+ dpll_mask &= ~dev_priv->hti_pll_mask;
+
for_each_set_bit(i, &dpll_mask, I915_NUM_PLLS) {
pll = &dev_priv->dpll.shared_dplls[i];
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
index 5d9a2bc371e7..ac2238646fe7 100644
--- a/drivers/gpu/drm/i915/display/in
[Intel-gfx] [PATCH v6 4/5] drm/i915/rkl: Add initial workarounds
RKL and TGL share some general gen12 workarounds, but each platform also
has its own platform-specific workarounds.
v2:
- Add Wa_1604555607 for RKL. This makes RKL's ctx WA list identical to
TGL's, so we'll have both functions call the tgl_ function for now;
this workaround isn't listed for DG1 so we don't want to add it to
the general gen12_ function.
Cc: Matt Atwood
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_sprite.c | 5 +-
drivers/gpu/drm/i915/gt/intel_workarounds.c | 88 +
2 files changed, 59 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 3cd461bf9131..63ac79f88fa2 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -2842,8 +2842,9 @@ static bool skl_plane_format_mod_supported(struct
drm_plane *_plane,
static bool gen12_plane_supports_mc_ccs(struct drm_i915_private *dev_priv,
enum plane_id plane_id)
{
- /* Wa_14010477008:tgl[a0..c0] */
- if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_C0))
+ /* Wa_14010477008:tgl[a0..c0],rkl[all] */
+ if (IS_ROCKETLAKE(dev_priv) ||
+ IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_C0))
return false;
return plane_id < PLANE_SPRITE4;
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 2da366821dda..741710ca2b9a 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -596,8 +596,8 @@ static void icl_ctx_workarounds_init(struct intel_engine_cs
*engine,
wa_masked_en(wal, GEN9_ROW_CHICKEN4, GEN11_DIS_PICK_2ND_EU);
}
-static void tgl_ctx_workarounds_init(struct intel_engine_cs *engine,
-struct i915_wa_list *wal)
+static void gen12_ctx_workarounds_init(struct intel_engine_cs *engine,
+ struct i915_wa_list *wal)
{
/*
* Wa_1409142259:tgl
@@ -607,12 +607,28 @@ static void tgl_ctx_workarounds_init(struct
intel_engine_cs *engine,
* Wa_1409207793:tgl
* Wa_1409178076:tgl
* Wa_1408979724:tgl
+* Wa_14010443199:rkl
+* Wa_14010698770:rkl
*/
WA_SET_BIT_MASKED(GEN11_COMMON_SLICE_CHICKEN3,
GEN12_DISABLE_CPS_AWARE_COLOR_PIPE);
+ /* WaDisableGPGPUMidThreadPreemption:gen12 */
+ WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1,
+ GEN9_PREEMPT_GPGPU_LEVEL_MASK,
+ GEN9_PREEMPT_GPGPU_THREAD_GROUP_LEVEL);
+}
+
+static void tgl_ctx_workarounds_init(struct intel_engine_cs *engine,
+struct i915_wa_list *wal)
+{
+ gen12_ctx_workarounds_init(engine, wal);
+
/*
-* Wa_1604555607:gen12 and Wa_1608008084:gen12
+* Wa_1604555607:tgl,rkl
+*
+* Note that the implementation of this workaround is further modified
+* according to the FF_MODE2 guidance given by Wa_1608008084:gen12.
* FF_MODE2 register will return the wrong value when read. The default
* value for this register is zero for all fields and there are no bit
* masks. So instead of doing a RMW we should just write the GS Timer
@@ -623,11 +639,6 @@ static void tgl_ctx_workarounds_init(struct
intel_engine_cs *engine,
FF_MODE2_GS_TIMER_MASK | FF_MODE2_TDS_TIMER_MASK,
FF_MODE2_GS_TIMER_224 | FF_MODE2_TDS_TIMER_128,
0);
-
- /* WaDisableGPGPUMidThreadPreemption:tgl */
- WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1,
- GEN9_PREEMPT_GPGPU_LEVEL_MASK,
- GEN9_PREEMPT_GPGPU_THREAD_GROUP_LEVEL);
}
static void
@@ -642,8 +653,10 @@ __intel_engine_init_ctx_wa(struct intel_engine_cs *engine,
wa_init_start(wal, name, engine->name);
- if (IS_GEN(i915, 12))
+ if (IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915))
tgl_ctx_workarounds_init(engine, wal);
+ else if (IS_GEN(i915, 12))
+ gen12_ctx_workarounds_init(engine, wal);
else if (IS_GEN(i915, 11))
icl_ctx_workarounds_init(engine, wal);
else if (IS_CANNONLAKE(i915))
@@ -1176,9 +1189,16 @@ icl_gt_workarounds_init(struct drm_i915_private *i915,
struct i915_wa_list *wal)
}
static void
-tgl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
+gen12_gt_workarounds_init(struct drm_i915_private *i915,
+ struct i915_wa_list *wal)
{
wa_init_mcr(i915, wal);
+}
+
+static void
+tgl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
+{
+ gen12_gt_workarounds_init(i915, wal);
/* Wa_1409420604:tgl */
if (IS_TGL_REVID(i915, TGL_REVID_A0, TGL_REVID_A0))
@@ -1196,8
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Apply Wa_14011264657:gen11+
== Series Details == Series: drm/i915: Apply Wa_14011264657:gen11+ URL : https://patchwork.freedesktop.org/series/78430/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8635_full -> Patchwork_17966_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17966_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17966_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_17966_full: ### IGT changes ### Possible regressions * igt@gem_exec_balancer@bonded-early: - shard-kbl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-kbl6/igt@gem_exec_balan...@bonded-early.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17966/shard-kbl7/igt@gem_exec_balan...@bonded-early.html * igt@kms_plane_scaling@pipe-b-scaler-with-pixel-format: - shard-tglb: [PASS][3] -> [FAIL][4] +6 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-tglb7/igt@kms_plane_scal...@pipe-b-scaler-with-pixel-format.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17966/shard-tglb1/igt@kms_plane_scal...@pipe-b-scaler-with-pixel-format.html * igt@kms_plane_scaling@pipe-d-scaler-with-pixel-format: - shard-tglb: NOTRUN -> [FAIL][5] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17966/shard-tglb2/igt@kms_plane_scal...@pipe-d-scaler-with-pixel-format.html Known issues Here are the changes found in Patchwork_17966_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@engines-mixed-process@rcs0: - shard-skl: [PASS][6] -> [FAIL][7] ([i915#1528]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-skl7/igt@gem_ctx_persistence@engines-mixed-proc...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17966/shard-skl3/igt@gem_ctx_persistence@engines-mixed-proc...@rcs0.html * igt@gem_exec_flush@basic-wb-rw-before-default: - shard-apl: [PASS][8] -> [DMESG-WARN][9] ([i915#95]) +17 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-apl8/igt@gem_exec_fl...@basic-wb-rw-before-default.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17966/shard-apl4/igt@gem_exec_fl...@basic-wb-rw-before-default.html * igt@gem_exec_whisper@basic-contexts-priority-all: - shard-glk: [PASS][10] -> [DMESG-WARN][11] ([i915#118] / [i915#95]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-glk4/igt@gem_exec_whis...@basic-contexts-priority-all.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17966/shard-glk4/igt@gem_exec_whis...@basic-contexts-priority-all.html * igt@gem_shrink@reclaim: - shard-hsw: [PASS][12] -> [SKIP][13] ([fdo#109271]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-hsw5/igt@gem_shr...@reclaim.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17966/shard-hsw1/igt@gem_shr...@reclaim.html * igt@kms_big_fb@linear-64bpp-rotate-180: - shard-glk: [PASS][14] -> [DMESG-FAIL][15] ([i915#118] / [i915#95]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-glk1/igt@kms_big...@linear-64bpp-rotate-180.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17966/shard-glk8/igt@kms_big...@linear-64bpp-rotate-180.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@c-dp1: - shard-apl: [PASS][16] -> [FAIL][17] ([i915#79]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-apl6/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-dp1.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17966/shard-apl4/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-dp1.html * igt@kms_flip@flip-vs-suspend@a-dp1: - shard-kbl: [PASS][18] -> [DMESG-WARN][19] ([i915#180]) +5 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-kbl3/igt@kms_flip@flip-vs-susp...@a-dp1.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17966/shard-kbl4/igt@kms_flip@flip-vs-susp...@a-dp1.html * igt@kms_flip_tiling@flip-changes-tiling: - shard-skl: [PASS][20] -> [DMESG-WARN][21] ([i915#1982]) +7 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-skl8/igt@kms_flip_til...@flip-changes-tiling.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17966/shard-skl10/igt@kms_flip_til...@flip-changes-tiling.html * igt@kms_flip_tiling@flip-changes-tiling-y: - shard-apl:
[Intel-gfx] [CI] drm/i915/selftests: Check preemption rollback of different ring queue depths
Like live_unlite_ring, but instead of simply looking at the impact of
intel_ring_direction(), check that preemption more generally works with
different depths of queued requests in the ring.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 163 +
1 file changed, 163 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index b8b7b91019f4..4f3758a1cbcf 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -2758,6 +2758,168 @@ static int create_gang(struct intel_engine_cs *engine,
return err;
}
+static int __live_preempt_ring(struct intel_engine_cs *engine,
+ struct igt_spinner *spin,
+ int queue_sz, int ring_sz)
+{
+ struct intel_context *ce[2] = {};
+ struct i915_request *rq;
+ struct igt_live_test t;
+ int err = 0;
+ int n;
+
+ if (igt_live_test_begin(&t, engine->i915, __func__, engine->name))
+ return -EIO;
+
+ for (n = 0; n < ARRAY_SIZE(ce); n++) {
+ struct intel_context *tmp;
+
+ tmp = intel_context_create(engine);
+ if (IS_ERR(tmp)) {
+ err = PTR_ERR(tmp);
+ goto err_ce;
+ }
+
+ tmp->ring = __intel_context_ring_size(ring_sz);
+
+ err = intel_context_pin(tmp);
+ if (err) {
+ intel_context_put(tmp);
+ goto err_ce;
+ }
+
+ memset32(tmp->ring->vaddr,
+0xdeadbeef, /* trigger a hang if executed */
+tmp->ring->vma->size / sizeof(u32));
+
+ ce[n] = tmp;
+ }
+
+ rq = igt_spinner_create_request(spin, ce[0], MI_ARB_CHECK);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err_ce;
+ }
+
+ i915_request_get(rq);
+ rq->sched.attr.priority = I915_PRIORITY_BARRIER;
+ i915_request_add(rq);
+
+ if (!igt_wait_for_spinner(spin, rq)) {
+ intel_gt_set_wedged(engine->gt);
+ i915_request_put(rq);
+ err = -ETIME;
+ goto err_ce;
+ }
+
+ /* Fill the ring, until we will cause a wrap */
+ n = 0;
+ while (ce[0]->ring->tail - rq->wa_tail <= queue_sz) {
+ struct i915_request *tmp;
+
+ tmp = intel_context_create_request(ce[0]);
+ if (IS_ERR(tmp)) {
+ err = PTR_ERR(tmp);
+ i915_request_put(rq);
+ goto err_ce;
+ }
+
+ i915_request_add(tmp);
+ intel_engine_flush_submission(engine);
+ n++;
+ }
+ intel_engine_flush_submission(engine);
+ pr_debug("%s: Filled %d with %d nop tails {size:%x, tail:%x, emit:%x,
rq.tail:%x}\n",
+engine->name, queue_sz, n,
+ce[0]->ring->size,
+ce[0]->ring->tail,
+ce[0]->ring->emit,
+rq->tail);
+ i915_request_put(rq);
+
+ /* Create a second request to preempt the first ring */
+ rq = intel_context_create_request(ce[1]);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err_ce;
+ }
+
+ rq->sched.attr.priority = I915_PRIORITY_BARRIER;
+ i915_request_get(rq);
+ i915_request_add(rq);
+
+ err = wait_for_submit(engine, rq, HZ / 2);
+ i915_request_put(rq);
+ if (err) {
+ pr_err("%s: preemption request was not submited\n",
+ engine->name);
+ err = -ETIME;
+ }
+
+ pr_debug("%s: ring[0]:{ tail:%x, emit:%x }, ring[1]:{ tail:%x, emit:%x
}\n",
+engine->name,
+ce[0]->ring->tail, ce[0]->ring->emit,
+ce[1]->ring->tail, ce[1]->ring->emit);
+
+err_ce:
+ intel_engine_flush_submission(engine);
+ igt_spinner_end(spin);
+ for (n = 0; n < ARRAY_SIZE(ce); n++) {
+ if (IS_ERR_OR_NULL(ce[n]))
+ break;
+
+ intel_context_unpin(ce[n]);
+ intel_context_put(ce[n]);
+ }
+ if (igt_live_test_end(&t))
+ err = -EIO;
+ return err;
+}
+
+static int live_preempt_ring(void *arg)
+{
+ struct intel_gt *gt = arg;
+ struct intel_engine_cs *engine;
+ struct igt_spinner spin;
+ enum intel_engine_id id;
+ int err = 0;
+
+ /*
+* Check that we rollback large chunks of a ring in order to do a
+* preemption event. Similar to live_unlite_ring, but looking at
+* ring size rather than the impact of intel_ring_direction().
+*/
+
+ if (igt_spinner_init(&spin, gt))
+ return -ENOMEM;
+
+ for_each_eng
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/6] drm/i915/tgl+: Use the correct DP_TP_* register instances in MST encoders (rev4)
== Series Details ==
Series: series starting with [v2,1/6] drm/i915/tgl+: Use the correct DP_TP_*
register instances in MST encoders (rev4)
URL : https://patchwork.freedesktop.org/series/78423/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8636 -> Patchwork_17971
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17971/index.html
Known issues
Here are the changes found in Patchwork_17971 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17971/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_chamelium@dp-crc-fast:
- fi-icl-u2: [PASS][3] -> [FAIL][4] ([i915#262])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17971/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-guc: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-icl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17971/fi-icl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17971/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
Possible fixes
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [DMESG-WARN][9] ([i915#95]) -> [PASS][10] +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17971/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17971/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][13] ([i915#227]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17971/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17971/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@i915_pm_rpm@basic-rte:
- fi-kbl-guc: [FAIL][17] ([i915#665] / [i915#704]) -> [SKIP][18]
([fdo#109271])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17971/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) ->
[DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17971/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
* igt@kms_flip@basic-flip-vs-wf_vblank@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][22] ([i915#62] / [i915#92]) +2 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp1.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17971/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, W
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Poll for DDI Idle status to be 0 after enabling DDI Buf
== Series Details ==
Series: drm/i915/dp: Poll for DDI Idle status to be 0 after enabling DDI Buf
URL : https://patchwork.freedesktop.org/series/78435/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8636 -> Patchwork_17970
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17970/index.html
Known issues
Here are the changes found in Patchwork_17970 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17970/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17970/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17970/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][7] ([i915#227]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17970/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17970/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][12] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17970/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@gem_exec_suspend@basic-s3:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) ->
[DMESG-WARN][14] ([i915#62] / [i915#92] / [i915#95])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17970/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
* igt@i915_pm_rpm@basic-rte:
- fi-kbl-guc: [FAIL][15] ([i915#665] / [i915#704]) -> [SKIP][16]
([fdo#109271])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17970/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
* igt@kms_flip@basic-flip-vs-modeset@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +4 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17970/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.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#1569]: https://gitlab.freedesktop.org/drm/intel/issues/1569
[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#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
[i915#227]: https://gitlab.freedesktop.org/drm/intel/issues/227
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#665]: https://gitlab.freedesktop.org/drm/intel/issues/665
[i915#704]: https://gitlab.freedesktop.org/drm/intel/issues/704
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: fix inconsistent IS_ERR and PTR_ERR (rev2)
== Series Details == Series: drm/i915/selftests: fix inconsistent IS_ERR and PTR_ERR (rev2) URL : https://patchwork.freedesktop.org/series/38366/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8635_full -> Patchwork_17965_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17965_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17965_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_17965_full: ### IGT changes ### Possible regressions * igt@gem_ctx_persistence@engines-mixed@vecs0: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-skl1/igt@gem_ctx_persistence@engines-mi...@vecs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17965/shard-skl3/igt@gem_ctx_persistence@engines-mi...@vecs0.html * igt@gem_exec_balancer@bonded-early: - shard-tglb: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-tglb6/igt@gem_exec_balan...@bonded-early.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17965/shard-tglb2/igt@gem_exec_balan...@bonded-early.html * igt@gem_exec_whisper@basic-normal: - shard-hsw: [PASS][5] -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-hsw2/igt@gem_exec_whis...@basic-normal.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17965/shard-hsw4/igt@gem_exec_whis...@basic-normal.html Known issues Here are the changes found in Patchwork_17965_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox: - shard-tglb: [PASS][7] -> [FAIL][8] ([i915#1528]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-tglb3/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17965/shard-tglb7/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html * igt@gem_ctx_persistence@process: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#93] / [i915#95]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-kbl4/igt@gem_ctx_persiste...@process.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17965/shard-kbl7/igt@gem_ctx_persiste...@process.html * igt@gem_exec_flush@basic-wb-rw-before-default: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#95]) +19 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-apl8/igt@gem_exec_fl...@basic-wb-rw-before-default.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17965/shard-apl7/igt@gem_exec_fl...@basic-wb-rw-before-default.html * igt@gem_exec_whisper@basic-normal-all: - shard-glk: [PASS][13] -> [DMESG-WARN][14] ([i915#118] / [i915#95]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-glk6/igt@gem_exec_whis...@basic-normal-all.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17965/shard-glk4/igt@gem_exec_whis...@basic-normal-all.html * igt@gem_shrink@reclaim: - shard-hsw: [PASS][15] -> [SKIP][16] ([fdo#109271]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-hsw5/igt@gem_shr...@reclaim.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17965/shard-hsw2/igt@gem_shr...@reclaim.html * igt@kms_big_fb@linear-64bpp-rotate-0: - shard-glk: [PASS][17] -> [DMESG-FAIL][18] ([i915#118] / [i915#95]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-glk6/igt@kms_big...@linear-64bpp-rotate-0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17965/shard-glk8/igt@kms_big...@linear-64bpp-rotate-0.html * igt@kms_flip@2x-flip-vs-wf_vblank-interruptible@ab-vga1-hdmi-a1: - shard-hsw: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-hsw8/igt@kms_flip@2x-flip-vs-wf_vblank-interrupti...@ab-vga1-hdmi-a1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17965/shard-hsw6/igt@kms_flip@2x-flip-vs-wf_vblank-interrupti...@ab-vga1-hdmi-a1.html * igt@kms_flip@flip-vs-expired-vblank@c-edp1: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#79]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-skl1/igt@kms_flip@flip-vs-expired-vbl...@c-edp1.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17965/shard-skl9/igt@kms_flip@flip-vs-expired-vbl...@c-ed
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Decouple completed requests on unwind
== Series Details ==
Series: drm/i915/gt: Decouple completed requests on unwind
URL : https://patchwork.freedesktop.org/series/78434/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8636 -> Patchwork_17969
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17969/index.html
Known issues
Here are the changes found in Patchwork_17969 that come from known issues:
### IGT changes ###
Possible fixes
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [FAIL][1] ([i915#1888]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17969/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [DMESG-WARN][3] ([i915#1982]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17969/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][5] ([i915#227]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17969/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17969/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-tgl-u2: [DMESG-WARN][9] ([i915#402]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17969/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
Warnings
* igt@debugfs_test@read_all_entries:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92]) ->
[DMESG-WARN][12] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-kbl-x1275/igt@debugfs_test@read_all_entries.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17969/fi-kbl-x1275/igt@debugfs_test@read_all_entries.html
* igt@i915_pm_rpm@basic-rte:
- fi-kbl-guc: [FAIL][13] ([i915#665] / [i915#704]) -> [SKIP][14]
([fdo#109271])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17969/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
* igt@kms_flip@basic-flip-vs-modeset@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][16] ([i915#62] / [i915#92]) +4 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17969/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.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#1569]: https://gitlab.freedesktop.org/drm/intel/issues/1569
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[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#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
[i915#227]: https://gitlab.freedesktop.org/drm/intel/issues/227
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#665]: https://gitlab.freedesktop.org/drm/intel/issues/665
[i915#704]: https://gitlab.freedesktop.org/drm/intel/issues/704
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (47 -> 42)
--
Missing(5): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-byt-clapper
fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8636 -> Patchwork_17969
CI-20190529: 20190529
CI_DRM_8636: dd73f1f0cf1ea35520ff8
Re: [Intel-gfx] [PATCH v2 1/6] drm/i915/tgl+: Use the correct DP_TP_* register instances in MST encoders
On Wed, 2020-06-17 at 00:11 +0300, Imre Deak wrote:
> MST encoders must use the master MST transcoder's DP_TP_STATUS and
> DP_TP_CONTROL registers. Atm, during the HW readout of an MST encoder
> connected to a slave transcoder we reset these register addresses in
> intel_dp::regs.dp_tp_* to the slave transcoder's DP_TP_* register
> addresses incorrectly; fix this.
>
> One example where the above overwite happens is the encoder HW state
> validation after enabling multiple streams; see
> intel_dp_mst_enc_get_config(). After that during disabling any stream
> we'll get a
>
> 'Timed out waiting for ACT sent when disabling'
>
> error, due to reading from the incorrect DP_TP_STATUS register.
>
> This change replaces
> https://patchwork.freedesktop.org/patch/369577/?series=78193&rev=1
> which just papered over the problem.
>
> v2:
> - Correct the failure scenario in the commit log. (José)
>
Reviewed-by: José Roberto de Souza
> Cc: Ville Syrjälä
> Cc: José Roberto de Souza
> Signed-off-by: Imre Deak
> Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index ca7bb2294d2b..73d6cc29291a 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4193,11 +4193,6 @@ void intel_ddi_get_config(struct intel_encoder
> *encoder,
> if (drm_WARN_ON(&dev_priv->drm, transcoder_is_dsi(cpu_transcoder)))
> return;
>
> - if (INTEL_GEN(dev_priv) >= 12) {
> - intel_dp->regs.dp_tp_ctl = TGL_DP_TP_CTL(cpu_transcoder);
> - intel_dp->regs.dp_tp_status = TGL_DP_TP_STATUS(cpu_transcoder);
> - }
> -
> intel_dsc_get_config(encoder, pipe_config);
>
> temp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
> @@ -4299,6 +4294,16 @@ void intel_ddi_get_config(struct intel_encoder
> *encoder,
> break;
> }
>
> + if (INTEL_GEN(dev_priv) >= 12) {
> + enum transcoder transcoder =
> + intel_dp_mst_is_slave_trans(pipe_config) ?
> + pipe_config->mst_master_transcoder :
> + pipe_config->cpu_transcoder;
> +
> + intel_dp->regs.dp_tp_ctl = TGL_DP_TP_CTL(transcoder);
> + intel_dp->regs.dp_tp_status = TGL_DP_TP_STATUS(transcoder);
> + }
> +
> pipe_config->has_audio =
> intel_ddi_is_audio_enabled(dev_priv, cpu_transcoder);
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/2] drm/i915/selftests: Exercise far preemption rollbacks
== Series Details == Series: series starting with [CI,1/2] drm/i915/selftests: Exercise far preemption rollbacks URL : https://patchwork.freedesktop.org/series/78433/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8636 -> Patchwork_17968 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17968 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17968, 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_17968/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17968: ### IGT changes ### Possible regressions * igt@i915_selftest@live@gt_pm: - fi-icl-y: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-icl-y/igt@i915_selftest@live@gt_pm.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17968/fi-icl-y/igt@i915_selftest@live@gt_pm.html Known issues Here are the changes found in Patchwork_17968 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [PASS][3] -> [FAIL][4] ([i915#1888]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17968/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17968/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-byt-n2820: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-byt-n2820/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17968/fi-byt-n2820/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-icl-guc: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-icl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17968/fi-icl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1: - fi-icl-u2: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17968/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html Possible fixes * igt@gem_exec_suspend@basic-s0: - fi-tgl-u2: [FAIL][13] ([i915#1888]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17968/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html * igt@i915_pm_backlight@basic-brightness: - fi-whl-u: [DMESG-WARN][15] ([i915#95]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17968/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rpm@module-reload: - fi-glk-dsi: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-glk-dsi/igt@i915_pm_...@module-reload.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17968/fi-glk-dsi/igt@i915_pm_...@module-reload.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][19] ([i915#227]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17968/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-tgl-u2: [DMESG-WARN][21] ([i915#402]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17968/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-p
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/6] drm/i915/tgl+: Use the correct DP_TP_* register instances in MST encoders
== Series Details == Series: series starting with [1/6] drm/i915/tgl+: Use the correct DP_TP_* register instances in MST encoders URL : https://patchwork.freedesktop.org/series/78423/ State : success == Summary == CI Bug Log - changes from CI_DRM_8635_full -> Patchwork_17964_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17964_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@engines-mixed-process@vcs0: - shard-apl: [PASS][1] -> [FAIL][2] ([i915#1528]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-apl7/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17964/shard-apl1/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html * igt@gem_ctx_persistence@process: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#93] / [i915#95]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-kbl4/igt@gem_ctx_persiste...@process.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17964/shard-kbl7/igt@gem_ctx_persiste...@process.html * igt@gem_exec_whisper@basic-contexts-priority-all: - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-glk4/igt@gem_exec_whis...@basic-contexts-priority-all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17964/shard-glk1/igt@gem_exec_whis...@basic-contexts-priority-all.html * igt@gem_workarounds@basic-read: - shard-tglb: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-tglb3/igt@gem_workarou...@basic-read.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17964/shard-tglb7/igt@gem_workarou...@basic-read.html * igt@i915_pm_rps@waitboost: - shard-glk: [PASS][9] -> [FAIL][10] ([i915#39]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-glk7/igt@i915_pm_...@waitboost.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17964/shard-glk6/igt@i915_pm_...@waitboost.html * igt@kms_big_fb@x-tiled-64bpp-rotate-180: - shard-glk: [PASS][11] -> [DMESG-FAIL][12] ([i915#118] / [i915#95]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-glk2/igt@kms_big...@x-tiled-64bpp-rotate-180.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17964/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-180.html * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-xtiled: - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-apl1/igt@kms_draw_...@draw-method-xrgb2101010-mmap-gtt-xtiled.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17964/shard-apl4/igt@kms_draw_...@draw-method-xrgb2101010-mmap-gtt-xtiled.html * igt@kms_flip@flip-vs-blocking-wf-vblank@b-edp1: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#1928]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-skl1/igt@kms_flip@flip-vs-blocking-wf-vbl...@b-edp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17964/shard-skl2/igt@kms_flip@flip-vs-blocking-wf-vbl...@b-edp1.html * igt@kms_flip_tiling@flip-changes-tiling: - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +10 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-skl8/igt@kms_flip_til...@flip-changes-tiling.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17964/shard-skl2/igt@kms_flip_til...@flip-changes-tiling.html * igt@kms_flip_tiling@flip-changes-tiling-y: - shard-apl: [PASS][19] -> [DMESG-FAIL][20] ([i915#95]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-apl2/igt@kms_flip_til...@flip-changes-tiling-y.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17964/shard-apl2/igt@kms_flip_til...@flip-changes-tiling-y.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-pwrite: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#95]) +10 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-apl8/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-pwrite.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17964/shard-apl7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-pwrite.html * igt@kms_frontbuffer_tracking@psr-farfromfence: - shard-tglb: [PASS][23] -> [SKIP][24] ([i915#668]) +5 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-tglb3/igt@kms_frontbuffer_track...@psr-farfromfence.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchw
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/2] drm/i915/selftests: Exercise far preemption rollbacks
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/selftests: Exercise far
preemption rollbacks
URL : https://patchwork.freedesktop.org/series/78433/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
97ec6b6737a1 drm/i915/selftests: Exercise far preemption rollbacks
-:19: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit e36ba817fa96 ("drm/i915/gt:
Incrementally check for rewinding")'
#19:
References: e36ba817fa96 ("drm/i915/gt: Incrementally check for rewinding")
total: 1 errors, 0 warnings, 0 checks, 163 lines checked
f00bbf1a4c7f drm/i915/selftests: Use friendly request names for
live_timeslice_rewind
___
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: Mark up inline getters as taking a const i915_request
== Series Details == Series: drm/i915: Mark up inline getters as taking a const i915_request URL : https://patchwork.freedesktop.org/series/78432/ State : success == Summary == CI Bug Log - changes from CI_DRM_8636 -> Patchwork_17967 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17967/index.html Known issues Here are the changes found in Patchwork_17967 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17967/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html * igt@kms_chamelium@dp-crc-fast: - fi-icl-u2: [PASS][3] -> [FAIL][4] ([i915#262]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17967/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html * igt@kms_cursor_legacy@basic-flip-before-cursor-atomic: - fi-icl-guc: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-icl-guc/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17967/fi-icl-guc/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html Possible fixes * igt@gem_exec_suspend@basic-s0: - fi-tgl-u2: [FAIL][7] ([i915#1888]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17967/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][9] ([i915#227]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17967/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-icl-u2: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17967/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][14] ([i915#62] / [i915#92]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17967/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html * igt@gem_exec_suspend@basic-s3: - fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92]) -> [DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17967/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html * igt@i915_pm_rpm@basic-rte: - fi-kbl-guc: [FAIL][17] ([i915#665] / [i915#704]) -> [SKIP][18] ([fdo#109271]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8636/fi-kbl-guc/igt@i915_pm_...@basic-rte.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17967/fi-kbl-guc/igt@i915_pm_...@basic-rte.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#227]: https://gitlab.freedesktop.org/drm/intel/issues/227 [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#665]: https://gitlab.freedesktop.org/drm/intel/issues/665 [i915#704]: https://gitlab.freedesktop.org/drm/intel/issues/704 [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (47 -> 42) -- Missing(5): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8636 -> Patchwork_17967 CI-20190529: 20190529 CI_DRM_8636: dd73f1f0cf1ea35520ff8267e59159be8c884e23 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5711: 90611a0c90afa4a46496c78a4faf9638a1538ac3 @ git://anon
Re: [Intel-gfx] [PATCH] drm/i915/dp: Poll for DDI Idle status to be 0 after enabling DDI Buf
On Tue, Jun 16, 2020 at 11:22:32PM +0300, Ville Syrjälä wrote: > On Tue, Jun 16, 2020 at 12:30:56PM -0700, Manasi Navare wrote: > > The Bspec sequence expects us to poll for DDI Idle status > > to be 0 (not idle) with a timeout of 600usecs after enabling the > > DDI BUF CTL. But currently in the driver we just wait for 600usecs > > without polling so add that. > > > > Cc: Ville Syrjälä > > Cc: Imre Deak > > Signed-off-by: Manasi Navare > > --- > > drivers/gpu/drm/i915/display/intel_ddi.c | 6 +- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c > > b/drivers/gpu/drm/i915/display/intel_ddi.c > > index ca7bb2294d2b..de7e15de0bc5 100644 > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c > > @@ -4023,7 +4023,11 @@ static void intel_ddi_prepare_link_retrain(struct > > intel_dp *intel_dp) > > intel_de_write(dev_priv, DDI_BUF_CTL(port), intel_dp->DP); > > intel_de_posting_read(dev_priv, DDI_BUF_CTL(port)); > > > > - udelay(600); > > + if (wait_for_us(!(intel_de_read(dev_priv, DDI_BUF_CTL(port)) & > > + DDI_BUF_IS_IDLE), > > + 600)) > > + drm_err(&dev_priv->drm, "DDI port:%c buffer idle\n", > > + port_name(port)); > > Another thing I just noticed is that icl+ need this for HDMI as well. > The slightly odd thing is that glk is documented to need this for > DP but not HDMI. But I'm thinking doing it also for glk HDMI should > be fine. > > So I guess to line up with the spec we should: > - fixed >518us enable delay for pre-glk (not sure if polling > would be ok for hsw/bdw/skl) > - poll for enable on glk+ > - fixed 16us disable delay for bxt > - poll for disable on !bxt > > And do it for both DP and HDMI for consistency. So since its different one each platform, should we create a per platform hook like wait_for_non_idle_status or something per platform? Manasi > > > > } > > > > static void intel_ddi_set_link_train(struct intel_dp *intel_dp, > > -- > > 2.19.1 > > -- > Ville Syrjälä > Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Decouple completed requests on unwind
Quoting Abodunrin, Akeem G (2020-06-16 22:31:45)
>
>
> > -Original Message-
> > From: Intel-gfx On Behalf Of Chris
> > Wilson
> > Sent: Tuesday, June 16, 2020 12:02 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Chris Wilson
> > Subject: [Intel-gfx] [PATCH] drm/i915/gt: Decouple completed requests on
> > unwind
> >
> > Since the introduction of preempt-to-busy, requests can complete in the
> > background, even while they are not on the engine->active.requests list.
> > As such, the engine->active.request list itself is not in strict retirement
> > order,
> > and we have to scan the entire list while unwinding to not miss any.
> > However, if the request is completed we currently leave it on the list
> > [until
> > retirement], but we could just as simply remove it and stop treating it as
> > active. We would only have to then traverse it once while unwinding in quick
> > succession.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index e866b8d721ed..4eb397b0e14d 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -1114,8 +1114,10 @@ __unwind_incomplete_requests(struct
> > intel_engine_cs *engine)
> > list_for_each_entry_safe_reverse(rq, rn,
> >&engine->active.requests,
> >sched.link) {
> > - if (i915_request_completed(rq))
> > - continue; /* XXX */
> > + if (i915_request_completed(rq)) {
> > + list_del_init(&rq->sched.link);
>
> Albeit this seems like a valid approach to resolve inconsistence in the list
> of requests that are active or retired, but we can't just delete completed
> requests from the list until full retirement is done - otherwise we stand the
> risk of out-of-the-order list, and could lead to inconsistence (which is the
> original problem you intend to resolve). Have you thought about locking
> mechanism?
The list is always in execution [context] order. Within a context it is
in retirement order. It is irrelevant whether it is removed here or in
remove_from_engine().
-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/display: fix missing null check on allocated dsb object
== Series Details ==
Series: drm/i915/display: fix missing null check on allocated dsb object
URL : https://patchwork.freedesktop.org/series/78414/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8635_full -> Patchwork_17962_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_17962_full:
### Piglit changes ###
Possible regressions
*
spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-double_dmat2x4_array3-position-double_double
(NEW):
- {pig-icl-1065g7}: NOTRUN -> [INCOMPLETE][1] +2 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17962/pig-icl-1065g7/spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-double_dmat2x4_array3-position-double_double.html
*
spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-double_dvec3_array3-double_dmat2x4_array2-position
(NEW):
- {pig-icl-1065g7}: NOTRUN -> [CRASH][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17962/pig-icl-1065g7/spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-double_dvec3_array3-double_dmat2x4_array2-position.html
New tests
-
New tests have been introduced between CI_DRM_8635_full and
Patchwork_17962_full:
### New Piglit tests (4) ###
*
spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-double_dmat2x4_array3-position-double_double:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-double_dvec3_array3-double_dmat2x4_array2-position:
- Statuses : 1 crash(s)
- Exec time: [0.44] s
*
spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-position-double_dmat3x2_array5-float_vec4:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-position-float_vec4_array3-double_dmat3x4:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_17962_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +5 similar
issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-kbl6/igt@gem_ctx_isolation@preservation...@vcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17962/shard-kbl1/igt@gem_ctx_isolation@preservation...@vcs0.html
* igt@gem_exec_whisper@basic-contexts-priority-all:
- shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-glk4/igt@gem_exec_whis...@basic-contexts-priority-all.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17962/shard-glk1/igt@gem_exec_whis...@basic-contexts-priority-all.html
* igt@gem_mmap_wc@write-cpu-read-wc:
- shard-apl: [PASS][7] -> [DMESG-WARN][8] ([i915#95]) +15 similar
issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-apl2/igt@gem_mmap...@write-cpu-read-wc.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17962/shard-apl1/igt@gem_mmap...@write-cpu-read-wc.html
* igt@gem_shrink@reclaim:
- shard-hsw: [PASS][9] -> [SKIP][10] ([fdo#109271])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-hsw5/igt@gem_shr...@reclaim.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17962/shard-hsw1/igt@gem_shr...@reclaim.html
* igt@kms_cursor_edge_walk@pipe-c-256x256-bottom-edge:
- shard-glk: [PASS][11] -> [DMESG-WARN][12] ([i915#1982])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-glk4/igt@kms_cursor_edge_w...@pipe-c-256x256-bottom-edge.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17962/shard-glk5/igt@kms_cursor_edge_w...@pipe-c-256x256-bottom-edge.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic:
- shard-hsw: [PASS][13] -> [FAIL][14] ([IGT#5])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-hsw1/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17962/shard-hsw6/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html
* igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a1:
- shard-glk: [PASS][15] -> [FAIL][16] ([i915#79])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-glk7/igt@kms_flip@flip-vs-expired-vbl...@b-hdmi-a1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17962/shard-glk4/igt@kms_flip@flip-vs-expired-vbl...@b-hdmi-a1.html
* igt@kms_flip@flip-vs-wf_vblank-interruptible@a-dp1:
- shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-kbl7/igt@kms_flip@flip
Re: [Intel-gfx] [PATCH] drm/i915/gt: Decouple completed requests on unwind
> -Original Message-
> From: Intel-gfx On Behalf Of Chris
> Wilson
> Sent: Tuesday, June 16, 2020 12:02 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson
> Subject: [Intel-gfx] [PATCH] drm/i915/gt: Decouple completed requests on
> unwind
>
> Since the introduction of preempt-to-busy, requests can complete in the
> background, even while they are not on the engine->active.requests list.
> As such, the engine->active.request list itself is not in strict retirement
> order,
> and we have to scan the entire list while unwinding to not miss any.
> However, if the request is completed we currently leave it on the list [until
> retirement], but we could just as simply remove it and stop treating it as
> active. We would only have to then traverse it once while unwinding in quick
> succession.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index e866b8d721ed..4eb397b0e14d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -1114,8 +1114,10 @@ __unwind_incomplete_requests(struct
> intel_engine_cs *engine)
> list_for_each_entry_safe_reverse(rq, rn,
>&engine->active.requests,
>sched.link) {
> - if (i915_request_completed(rq))
> - continue; /* XXX */
> + if (i915_request_completed(rq)) {
> + list_del_init(&rq->sched.link);
Albeit this seems like a valid approach to resolve inconsistence in the list of
requests that are active or retired, but we can't just delete completed
requests from the list until full retirement is done - otherwise we stand the
risk of out-of-the-order list, and could lead to inconsistence (which is the
original problem you intend to resolve). Have you thought about locking
mechanism?
Regards,
~Akeem
> + continue;
> + }
>
> __i915_request_unsubmit(rq);
>
> --
> 2.20.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] [PATCH v2 6/6] drm/i915/dp_mst: Ensure the DPCD ACT sent flag is cleared before waiting for it
Atm, we clear the ACT sent flag in the sink's DPCD before updating the
sink's payload table, along clearing the payload table updated flag.
The sink is supposed to set this flag once it detects that the source
has completed the ACT sequence (after detecting the 4 required ACT MTPH
symbols sent by the source). As opposed to this 2 DELL monitors I have
set the flag already along the payload table updated flag, which is not
quite correct.
To be sure that the sink has detected the ACT MTPH symbols before
continuing enabling the encoder, clear the ACT sent flag before enabling
or disabling the transcoder VC payload allocation (which is what starts
the ACT sequence).
v2 (Ville):
- Use the correct bit to clear the flags.
- Add code comment explaining the clearing semantics of the ACT handled
flag.
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_dp_mst_topology.c | 38 +++--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 ++
include/drm/drm_dp_mst_helper.h | 2 ++
3 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index b2f5a84b4cfb..1f5d14128c1a 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -4377,6 +4377,41 @@ void drm_dp_mst_deallocate_vcpi(struct
drm_dp_mst_topology_mgr *mgr,
}
EXPORT_SYMBOL(drm_dp_mst_deallocate_vcpi);
+/**
+ * drm_dp_clear_payload_status() - Clears the payload table status flags
+ * @mgr: manager to use
+ *
+ * Clears the payload table ACT handled and table updated flags in the MST
hub's
+ * DPCD. This function must be called before updating the payload table or
+ * starting the ACT sequence and waiting for the corresponding flags to get
+ * set by the hub.
+ *
+ * Returns:
+ * 0 if the flags got cleared successfully, otherwise a negative error code.
+ */
+int drm_dp_clear_payload_status(struct drm_dp_mst_topology_mgr *mgr)
+{
+ int ret;
+
+ /*
+* Note that the following is based on the DP Standard stating that
+* writing the DP_PAYLOAD_TABLE_UPDATED bit alone will clear both the
+* DP_PAYLOAD_TABLE_UPDATED and the DP_PAYLOAD_ACT_HANDLED flags. This
+* seems to be also the only way to clear DP_PAYLOAD_ACT_HANDLED.
+*/
+ ret = drm_dp_dpcd_writeb(mgr->aux, DP_PAYLOAD_TABLE_UPDATE_STATUS,
+DP_PAYLOAD_TABLE_UPDATED);
+ if (ret < 0) {
+ DRM_DEBUG_DRIVER("Can't clear the ACT handled/table updated
flags (%d)\n",
+ret);
+ return ret;
+ }
+ WARN_ON(ret != 1);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_clear_payload_status);
+
static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr,
int id, struct drm_dp_payload *payload)
{
@@ -4384,8 +4419,7 @@ static int drm_dp_dpcd_write_payload(struct
drm_dp_mst_topology_mgr *mgr,
int ret;
int retries = 0;
- drm_dp_dpcd_writeb(mgr->aux, DP_PAYLOAD_TABLE_UPDATE_STATUS,
- DP_PAYLOAD_TABLE_UPDATED);
+ drm_dp_clear_payload_status(mgr);
payload_alloc[0] = id;
payload_alloc[1] = payload->start_slot;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 9308b5920780..3c4b0fb10d8b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -323,6 +323,8 @@ static void clear_act_sent(struct intel_dp *intel_dp)
intel_de_write(i915, intel_dp->regs.dp_tp_status,
DP_TP_STATUS_ACT_SENT);
+
+ drm_dp_clear_payload_status(&intel_dp->mst_mgr);
}
static void wait_for_act_sent(struct intel_dp *intel_dp)
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 8b9eb4db3381..2facb87624bf 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -763,6 +763,8 @@ int drm_dp_find_vcpi_slots(struct drm_dp_mst_topology_mgr
*mgr,
int pbn);
+int drm_dp_clear_payload_status(struct drm_dp_mst_topology_mgr *mgr);
+
int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr);
--
2.23.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/6] drm/i915/dp_mst: Disable link training fallback on MST links
During the initial probing of an MST sink, MST core will determine the
sink's link bandwidth based on its own version of the sink link
rate/lane count caps it reads from the DPCD. At a later point (after
probing and 1 or more modesets) i915 may limit the link parameters wrt.
the original source/sink common caps above due to link training failures
during a modeset and the resulting link training fallback logic.
Based on the above a modeset following another modeset with a link
training error will compute the i915 HW specific and DP protocol timing
parameters (data/link M/N and MST TU values) taking into account only
the unlimited source/sink common caps, but not taking into account the
fallback limits. This will also let DRM core oversubscribe the actual
link bandwidth during the MST payload allocation.
Prevent the above problem by disabling the link training fallback on MST
links for now, until the MST probe time initialization and the MST
compute config logic can deal with changing link parameters.
The misconfigured timings lead at least to a
'Timed out waiting for DP idle patterns'
error.
v2: (Ville)
- Print link training error message on the MST path too.
- Clarify the problem in the commit log.
Cc: Ville Syrjälä
Cc: Manasi Navare
Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 27 ++---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 42589cae766d..66d9ee94cdd0 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -468,6 +468,15 @@ int intel_dp_get_link_train_fallback_values(struct
intel_dp *intel_dp,
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
int index;
+ /*
+* TODO: Enable fallback on MST links once MST link compute can handle
+* the fallback params.
+*/
+ if (intel_dp->is_mst) {
+ drm_err(&i915->drm, "Link Training Unsuccessful\n");
+ return -1;
+ }
+
index = intel_dp_rate_index(intel_dp->common_rates,
intel_dp->num_common_rates,
link_rate);
@@ -6163,7 +6172,17 @@ intel_dp_detect(struct drm_connector *connector,
goto out;
}
- if (intel_dp->reset_link_params) {
+ /* Read DP Sink DSC Cap DPCD regs for DP v1.4 */
+ if (INTEL_GEN(dev_priv) >= 11)
+ intel_dp_get_dsc_sink_cap(intel_dp);
+
+ intel_dp_configure_mst(intel_dp);
+
+ /*
+* TODO: Reset link params when switching to MST mode, until MST
+* supports link training fallback params.
+*/
+ if (intel_dp->reset_link_params || intel_dp->is_mst) {
/* Initial max link lane count */
intel_dp->max_link_lane_count =
intel_dp_max_common_lane_count(intel_dp);
@@ -6175,12 +6194,6 @@ intel_dp_detect(struct drm_connector *connector,
intel_dp_print_rates(intel_dp);
- /* Read DP Sink DSC Cap DPCD regs for DP v1.4 */
- if (INTEL_GEN(dev_priv) >= 11)
- intel_dp_get_dsc_sink_cap(intel_dp);
-
- intel_dp_configure_mst(intel_dp);
-
if (intel_dp->is_mst) {
/*
* If we are in MST mode then this connector
--
2.23.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/6] drm/i915/tgl+: Use the correct DP_TP_* register instances in MST encoders
MST encoders must use the master MST transcoder's DP_TP_STATUS and
DP_TP_CONTROL registers. Atm, during the HW readout of an MST encoder
connected to a slave transcoder we reset these register addresses in
intel_dp::regs.dp_tp_* to the slave transcoder's DP_TP_* register
addresses incorrectly; fix this.
One example where the above overwite happens is the encoder HW state
validation after enabling multiple streams; see
intel_dp_mst_enc_get_config(). After that during disabling any stream
we'll get a
'Timed out waiting for ACT sent when disabling'
error, due to reading from the incorrect DP_TP_STATUS register.
This change replaces
https://patchwork.freedesktop.org/patch/369577/?series=78193&rev=1
which just papered over the problem.
v2:
- Correct the failure scenario in the commit log. (José)
Cc: Ville Syrjälä
Cc: José Roberto de Souza
Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index ca7bb2294d2b..73d6cc29291a 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4193,11 +4193,6 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
if (drm_WARN_ON(&dev_priv->drm, transcoder_is_dsi(cpu_transcoder)))
return;
- if (INTEL_GEN(dev_priv) >= 12) {
- intel_dp->regs.dp_tp_ctl = TGL_DP_TP_CTL(cpu_transcoder);
- intel_dp->regs.dp_tp_status = TGL_DP_TP_STATUS(cpu_transcoder);
- }
-
intel_dsc_get_config(encoder, pipe_config);
temp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
@@ -4299,6 +4294,16 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
break;
}
+ if (INTEL_GEN(dev_priv) >= 12) {
+ enum transcoder transcoder =
+ intel_dp_mst_is_slave_trans(pipe_config) ?
+ pipe_config->mst_master_transcoder :
+ pipe_config->cpu_transcoder;
+
+ intel_dp->regs.dp_tp_ctl = TGL_DP_TP_CTL(transcoder);
+ intel_dp->regs.dp_tp_status = TGL_DP_TP_STATUS(transcoder);
+ }
+
pipe_config->has_audio =
intel_ddi_is_audio_enabled(dev_priv, cpu_transcoder);
--
2.23.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Implement PSR2 selective fetch
On Tue, 2020-06-16 at 21:33 +0100, Mun, Gwan-gyeong wrote:
> On Tue, 2020-06-16 at 10:29 -0700, Souza, Jose wrote:
> > On Tue, 2020-06-16 at 16:16 +0100, Mun, Gwan-gyeong wrote:
> > > On Mon, 2020-06-15 at 19:40 +0300, Ville Syrjälä wrote:
> > > > On Fri, Jun 12, 2020 at 08:33:31PM +, Souza, Jose wrote:
> > > > > On Fri, 2020-06-12 at 19:30 +0300, Ville Syrjälä wrote:
> > > > > > On Tue, May 26, 2020 at 03:14:46PM -0700, José Roberto de
> > > > > > Souza
> > > > > > wrote:
> > > > > > > All GEN12 platforms supports PSR2 selective fetch but not
> > > > > > > all
> > > > > > > GEN12
> > > > > > > platforms supports PSR2 hardware tracking(aka RKL).
> > > > > > >
> > > > > > > This feature consists in software program registers with
> > > > > > > the
> > > > > > > damaged
> > > > > > > area of each plane this way hardware will only fetch from
> > > > > > > memory those
> > > > > > > areas and sent the PSR2 selective update blocks to panel,
> > > > > > > saving even
> > > > > > > more power but to it actually happen userspace needs to
> > > > > > > send
> > > > > > > the
> > > > > > > damaged areas otherwise it will still fetch the whole plane
> > > > > > > as
> > > > > > > fallback.
> > > > > > > As today Gnome3 do not send damaged areas and the only
> > > > > > > compositor that
> > > > > > > I'm aware that sets the damaged areas is Weston.
> > > > > > > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/17
> > > > > > >
> > > > > > > So here implementing page flip part, it is still completely
> > > > > > > missing
> > > > > > > frontbuffer modifications, that is why the
> > > > > > > enable_psr2_sel_fetch
> > > > > > > parameter was added.
> > > > > > >
> > > > > > > The plan is to switch all GEN12 platforms to selective
> > > > > > > fetch
> > > > > > > when
> > > > > > > ready, it will also depend in add some tests sending
> > > > > > > damaged
> > > > > > > areas.
> > > > > > > I have a hacked version of kms_psr2_su with 3 planes that I
> > > > > > > can
> > > > > > > cleanup and send in a few days(99% of PSR2 selective fetch
> > > > > > > changes was
> > > > > > > done during my free time while bored during quarantine
> > > > > > > rainy
> > > > > > > days).
> > > > > > >
> > > > > > > BSpec: 55229
> > > > > > > Cc: Ville Syrjälä
> > > > > > > Cc: Imre Deak
> > > > > > > Cc: Gwan-gyeong Mun
> > > > > > > Cc: Rodrigo Vivi
> > > > > > > Cc: Dhinakaran Pandiyan
> > > > > > > Signed-off-by: José Roberto de Souza
> > > > > > > ---
> > > > > > > drivers/gpu/drm/i915/display/intel_display.c | 5 +
> > > > > > > .../drm/i915/display/intel_display_debugfs.c | 3 +
> > > > > > > .../drm/i915/display/intel_display_types.h| 10 +
> > > > > > > drivers/gpu/drm/i915/display/intel_psr.c | 329
> > > > > > > +-
> > > > > > > drivers/gpu/drm/i915/display/intel_psr.h | 10 +
> > > > > > > drivers/gpu/drm/i915/display/intel_sprite.c | 2 +
> > > > > > > drivers/gpu/drm/i915/i915_drv.h | 2 +
> > > > > > > drivers/gpu/drm/i915/i915_params.c| 5 +
> > > > > > > drivers/gpu/drm/i915/i915_params.h| 1 +
> > > > > > > 9 files changed, 352 insertions(+), 15 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > > index b69878334040..984809208c29 100644
> > > > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > > @@ -11729,6 +11729,8 @@ static void
> > > > > > > i9xx_update_cursor(struct
> > > > > > > intel_plane *plane,
> > > > > > > if (INTEL_GEN(dev_priv) >= 9)
> > > > > > > skl_write_cursor_wm(plane, crtc_state);
> > > > > > >
> > > > > > > + intel_psr2_program_plane_sel_fetch(plane, crtc_state,
> > > > > > > plane_state);
> > > > > > > +
> > > > > > > if (plane->cursor.base != base ||
> > > > > > > plane->cursor.size != fbc_ctl ||
> > > > > > > plane->cursor.cntl != cntl) {
> > > > > > > @@ -15115,6 +15117,8 @@ static void
> > > > > > > commit_pipe_config(struct
> > > > > > > intel_atomic_state *state,
> > > > > > >
> > > > > > > if (new_crtc_state->update_pipe)
> > > > > > > intel_pipe_fastset(old_crtc_state,
> > > > > > > new_crtc_state);
> > > > > > > +
> > > > > > > + intel_psr2_program_trans_man_trk_ctl(new_crtc_s
> > > > > > > tate);
> > > > > > > }
> > > > > > >
> > > > > > > if (dev_priv->display.atomic_update_watermarks)
> > > > > > > @@ -15156,6 +15160,7 @@ static void
> > > > > > > intel_update_crtc(struct
> > > > > > > intel_atomic_state *state,
> > > > > > > intel_color_load_luts(new_crtc_state);
> > > > > > >
> > > > > > > intel_pre_plane_update(state, crtc);
> > > > > > > + intel_psr2_sel_fetch_update(state, crtc);
> > > > > > >
> > > > > > > if (new_crtc_state->update_pipe)
> > > >
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: Check preemption rollback of different ring queue depths
== Series Details == Series: drm/i915/selftests: Check preemption rollback of different ring queue depths URL : https://patchwork.freedesktop.org/series/78411/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8635_full -> Patchwork_17961_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17961_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17961_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_17961_full: ### IGT changes ### Possible regressions * igt@gem_exec_whisper@basic-normal: - shard-hsw: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-hsw2/igt@gem_exec_whis...@basic-normal.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17961/shard-hsw4/igt@gem_exec_whis...@basic-normal.html Known issues Here are the changes found in Patchwork_17961_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@process: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#93] / [i915#95]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-kbl4/igt@gem_ctx_persiste...@process.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17961/shard-kbl6/igt@gem_ctx_persiste...@process.html * igt@gem_exec_gttfill@all: - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-glk6/igt@gem_exec_gttf...@all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17961/shard-glk2/igt@gem_exec_gttf...@all.html * igt@gem_exec_schedule@implicit-boths@bcs0: - shard-snb: [PASS][7] -> [INCOMPLETE][8] ([i915#82]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-snb6/igt@gem_exec_schedule@implicit-bo...@bcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17961/shard-snb6/igt@gem_exec_schedule@implicit-bo...@bcs0.html * igt@kms_big_fb@linear-64bpp-rotate-180: - shard-glk: [PASS][9] -> [DMESG-FAIL][10] ([i915#118] / [i915#95]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-glk1/igt@kms_big...@linear-64bpp-rotate-180.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17961/shard-glk8/igt@kms_big...@linear-64bpp-rotate-180.html * igt@kms_cursor_crc@pipe-a-cursor-64x21-random: - shard-skl: [PASS][11] -> [FAIL][12] ([i915#54]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-skl7/igt@kms_cursor_...@pipe-a-cursor-64x21-random.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17961/shard-skl4/igt@kms_cursor_...@pipe-a-cursor-64x21-random.html * igt@kms_cursor_legacy@cursor-vs-flip-toggle: - shard-hsw: [PASS][13] -> [FAIL][14] ([i915#57]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-hsw1/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17961/shard-hsw6/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html * igt@kms_cursor_legacy@cursorb-vs-flipb-varying-size: - shard-hsw: [PASS][15] -> [SKIP][16] ([fdo#109271]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-hsw2/igt@kms_cursor_leg...@cursorb-vs-flipb-varying-size.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17961/shard-hsw5/igt@kms_cursor_leg...@cursorb-vs-flipb-varying-size.html * igt@kms_flip@plain-flip-ts-check-interruptible@a-edp1: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#1928]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-skl5/igt@kms_flip@plain-flip-ts-check-interrupti...@a-edp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17961/shard-skl9/igt@kms_flip@plain-flip-ts-check-interrupti...@a-edp1.html * igt@kms_flip_tiling@flip-changes-tiling: - shard-skl: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +7 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-skl8/igt@kms_flip_til...@flip-changes-tiling.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17961/shard-skl8/igt@kms_flip_til...@flip-changes-tiling.html * igt@kms_flip_tiling@flip-changes-tiling-y: - shard-apl: [PASS][21] -> [DMESG-FAIL][22] ([i915#95]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/shard-apl2/igt@kms_flip_til...@flip-changes-tiling-y.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17961/shard-apl2/igt@kms_flip_ti
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Apply Wa_14011264657:gen11+
== Series Details ==
Series: drm/i915: Apply Wa_14011264657:gen11+
URL : https://patchwork.freedesktop.org/series/78430/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8635 -> Patchwork_17966
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17966/index.html
Known issues
Here are the changes found in Patchwork_17966 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-icl-guc: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-icl-guc/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17966/fi-icl-guc/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17966/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@active:
- fi-skl-6600u: [PASS][5] -> [DMESG-FAIL][6] ([i915#666])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-skl-6600u/igt@i915_selftest@l...@active.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17966/fi-skl-6600u/igt@i915_selftest@l...@active.html
* igt@i915_selftest@live@coherency:
- fi-gdg-551: [PASS][7] -> [DMESG-FAIL][8] ([i915#1748])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-gdg-551/igt@i915_selftest@l...@coherency.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17966/fi-gdg-551/igt@i915_selftest@l...@coherency.html
* igt@i915_selftest@live@gem_contexts:
- fi-tgl-u2: [PASS][9] -> [INCOMPLETE][10] ([i915#1932])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17966/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-icl-u2: [PASS][11] -> [DMESG-WARN][12] ([i915#1982])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17966/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-tgl-u2: [PASS][13] -> [DMESG-WARN][14] ([i915#402])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17966/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
Possible fixes
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17966/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17966/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-guc: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-icl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17966/fi-icl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][22] ([i915#62] / [i915#92]) +3 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17966/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) ->
[DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17966/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
{name}
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Implement PSR2 selective fetch
On Tue, 2020-06-16 at 10:29 -0700, Souza, Jose wrote:
> On Tue, 2020-06-16 at 16:16 +0100, Mun, Gwan-gyeong wrote:
> > On Mon, 2020-06-15 at 19:40 +0300, Ville Syrjälä wrote:
> > > On Fri, Jun 12, 2020 at 08:33:31PM +, Souza, Jose wrote:
> > > > On Fri, 2020-06-12 at 19:30 +0300, Ville Syrjälä wrote:
> > > > > On Tue, May 26, 2020 at 03:14:46PM -0700, José Roberto de
> > > > > Souza
> > > > > wrote:
> > > > > > All GEN12 platforms supports PSR2 selective fetch but not
> > > > > > all
> > > > > > GEN12
> > > > > > platforms supports PSR2 hardware tracking(aka RKL).
> > > > > >
> > > > > > This feature consists in software program registers with
> > > > > > the
> > > > > > damaged
> > > > > > area of each plane this way hardware will only fetch from
> > > > > > memory those
> > > > > > areas and sent the PSR2 selective update blocks to panel,
> > > > > > saving even
> > > > > > more power but to it actually happen userspace needs to
> > > > > > send
> > > > > > the
> > > > > > damaged areas otherwise it will still fetch the whole plane
> > > > > > as
> > > > > > fallback.
> > > > > > As today Gnome3 do not send damaged areas and the only
> > > > > > compositor that
> > > > > > I'm aware that sets the damaged areas is Weston.
> > > > > > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/17
> > > > > >
> > > > > > So here implementing page flip part, it is still completely
> > > > > > missing
> > > > > > frontbuffer modifications, that is why the
> > > > > > enable_psr2_sel_fetch
> > > > > > parameter was added.
> > > > > >
> > > > > > The plan is to switch all GEN12 platforms to selective
> > > > > > fetch
> > > > > > when
> > > > > > ready, it will also depend in add some tests sending
> > > > > > damaged
> > > > > > areas.
> > > > > > I have a hacked version of kms_psr2_su with 3 planes that I
> > > > > > can
> > > > > > cleanup and send in a few days(99% of PSR2 selective fetch
> > > > > > changes was
> > > > > > done during my free time while bored during quarantine
> > > > > > rainy
> > > > > > days).
> > > > > >
> > > > > > BSpec: 55229
> > > > > > Cc: Ville Syrjälä
> > > > > > Cc: Imre Deak
> > > > > > Cc: Gwan-gyeong Mun
> > > > > > Cc: Rodrigo Vivi
> > > > > > Cc: Dhinakaran Pandiyan
> > > > > > Signed-off-by: José Roberto de Souza
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/display/intel_display.c | 5 +
> > > > > > .../drm/i915/display/intel_display_debugfs.c | 3 +
> > > > > > .../drm/i915/display/intel_display_types.h| 10 +
> > > > > > drivers/gpu/drm/i915/display/intel_psr.c | 329
> > > > > > +-
> > > > > > drivers/gpu/drm/i915/display/intel_psr.h | 10 +
> > > > > > drivers/gpu/drm/i915/display/intel_sprite.c | 2 +
> > > > > > drivers/gpu/drm/i915/i915_drv.h | 2 +
> > > > > > drivers/gpu/drm/i915/i915_params.c| 5 +
> > > > > > drivers/gpu/drm/i915/i915_params.h| 1 +
> > > > > > 9 files changed, 352 insertions(+), 15 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > index b69878334040..984809208c29 100644
> > > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > @@ -11729,6 +11729,8 @@ static void
> > > > > > i9xx_update_cursor(struct
> > > > > > intel_plane *plane,
> > > > > > if (INTEL_GEN(dev_priv) >= 9)
> > > > > > skl_write_cursor_wm(plane, crtc_state);
> > > > > >
> > > > > > + intel_psr2_program_plane_sel_fetch(plane, crtc_state,
> > > > > > plane_state);
> > > > > > +
> > > > > > if (plane->cursor.base != base ||
> > > > > > plane->cursor.size != fbc_ctl ||
> > > > > > plane->cursor.cntl != cntl) {
> > > > > > @@ -15115,6 +15117,8 @@ static void
> > > > > > commit_pipe_config(struct
> > > > > > intel_atomic_state *state,
> > > > > >
> > > > > > if (new_crtc_state->update_pipe)
> > > > > > intel_pipe_fastset(old_crtc_state,
> > > > > > new_crtc_state);
> > > > > > +
> > > > > > + intel_psr2_program_trans_man_trk_ctl(new_crtc_s
> > > > > > tate);
> > > > > > }
> > > > > >
> > > > > > if (dev_priv->display.atomic_update_watermarks)
> > > > > > @@ -15156,6 +15160,7 @@ static void
> > > > > > intel_update_crtc(struct
> > > > > > intel_atomic_state *state,
> > > > > > intel_color_load_luts(new_crtc_state);
> > > > > >
> > > > > > intel_pre_plane_update(state, crtc);
> > > > > > + intel_psr2_sel_fetch_update(state, crtc);
> > > > > >
> > > > > > if (new_crtc_state->update_pipe)
> > > > > > intel_encoders_update_pipe(state,
> > > > > > crtc);
> > > > > > diff --git
> > > > > > a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > > > > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > > > > in
Re: [Intel-gfx] [PATCH] drm/i915/dp: Poll for DDI Idle status to be 0 after enabling DDI Buf
On Tue, Jun 16, 2020 at 12:30:56PM -0700, Manasi Navare wrote: > The Bspec sequence expects us to poll for DDI Idle status > to be 0 (not idle) with a timeout of 600usecs after enabling the > DDI BUF CTL. But currently in the driver we just wait for 600usecs > without polling so add that. > > Cc: Ville Syrjälä > Cc: Imre Deak > Signed-off-by: Manasi Navare > --- > drivers/gpu/drm/i915/display/intel_ddi.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c > b/drivers/gpu/drm/i915/display/intel_ddi.c > index ca7bb2294d2b..de7e15de0bc5 100644 > --- a/drivers/gpu/drm/i915/display/intel_ddi.c > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c > @@ -4023,7 +4023,11 @@ static void intel_ddi_prepare_link_retrain(struct > intel_dp *intel_dp) > intel_de_write(dev_priv, DDI_BUF_CTL(port), intel_dp->DP); > intel_de_posting_read(dev_priv, DDI_BUF_CTL(port)); > > - udelay(600); > + if (wait_for_us(!(intel_de_read(dev_priv, DDI_BUF_CTL(port)) & > + DDI_BUF_IS_IDLE), > + 600)) > + drm_err(&dev_priv->drm, "DDI port:%c buffer idle\n", > + port_name(port)); Another thing I just noticed is that icl+ need this for HDMI as well. The slightly odd thing is that glk is documented to need this for DP but not HDMI. But I'm thinking doing it also for glk HDMI should be fine. So I guess to line up with the spec we should: - fixed >518us enable delay for pre-glk (not sure if polling would be ok for hsw/bdw/skl) - poll for enable on glk+ - fixed 16us disable delay for bxt - poll for disable on !bxt And do it for both DP and HDMI for consistency. > } > > static void intel_ddi_set_link_train(struct intel_dp *intel_dp, > -- > 2.19.1 -- Ville Syrjälä Intel ___ 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: Apply Wa_14011264657:gen11+
== Series Details ==
Series: drm/i915: Apply Wa_14011264657:gen11+
URL : https://patchwork.freedesktop.org/series/78430/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
71e1726c303a drm/i915: Apply Wa_14011264657:gen11+
-:19: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#19: FILE: drivers/gpu/drm/i915/display/intel_display.c:3764:
+static int icl_min_plane_width(struct drm_i915_private *dev_priv,
+const struct drm_framebuffer *fb)
-:74: CHECK:BRACES: braces {} should be used on all arms of this statement
#74: FILE: drivers/gpu/drm/i915/display/intel_display.c:3878:
+ if (INTEL_GEN(dev_priv) >= 11) {
[...]
else if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
[...]
total: 0 errors, 0 warnings, 2 checks, 78 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/selftests: fix inconsistent IS_ERR and PTR_ERR (rev2)
== Series Details == Series: drm/i915/selftests: fix inconsistent IS_ERR and PTR_ERR (rev2) URL : https://patchwork.freedesktop.org/series/38366/ State : success == Summary == CI Bug Log - changes from CI_DRM_8635 -> Patchwork_17965 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17965/index.html Known issues Here are the changes found in Patchwork_17965 that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@reload: - fi-tgl-u2: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-tgl-u2/igt@i915_module_l...@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17965/fi-tgl-u2/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@module-reload: - fi-glk-dsi: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-glk-dsi/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17965/fi-glk-dsi/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@coherency: - fi-gdg-551: [PASS][5] -> [DMESG-FAIL][6] ([i915#1748]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-gdg-551/igt@i915_selftest@l...@coherency.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17965/fi-gdg-551/igt@i915_selftest@l...@coherency.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-icl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17965/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html Possible fixes * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-icl-guc: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-icl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17965/fi-icl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html Warnings * igt@i915_module_load@reload: - fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][12] ([i915#62] / [i915#92]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-kbl-x1275/igt@i915_module_l...@reload.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17965/fi-kbl-x1275/igt@i915_module_l...@reload.html * igt@kms_force_connector_basic@force-edid: - fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) -> [DMESG-WARN][14] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17965/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [i915#1748]: https://gitlab.freedesktop.org/drm/intel/issues/1748 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (47 -> 42) -- Missing(5): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8635 -> Patchwork_17965 CI-20190529: 20190529 CI_DRM_8635: f9acdb898773f94ac1bcb9a8826596f88412a53b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5711: 90611a0c90afa4a46496c78a4faf9638a1538ac3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17965: c02b027d9362eea5bc00596c8d3ba31dc4a9aac5 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c02b027d9362 drm/i915/selftests: Fix inconsistent IS_ERR and PTR_ERR == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17965/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Check preemption rollback of different ring queue depths
Chris Wilson writes:
> Like live_unlite_ring, but instead of simply looking at the impact of
> intel_ring_direction(), check that preemption more generally works with
> different depths of queued requests in the ring.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Pondering about the sizes of try but I can't make up anything
better.
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/selftest_lrc.c | 163 +
> 1 file changed, 163 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> index 3d088116a055..530718797848 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> @@ -2756,6 +2756,168 @@ static int create_gang(struct intel_engine_cs *engine,
> return err;
> }
>
> +static int __live_preempt_ring(struct intel_engine_cs *engine,
> +struct igt_spinner *spin,
> +int sz)
> +{
> + struct intel_context *ce[2] = {};
> + struct i915_request *rq;
> + struct igt_live_test t;
> + int err = 0;
> + int n;
> +
> + if (igt_live_test_begin(&t, engine->i915, __func__, engine->name))
> + return -EIO;
> +
> + for (n = 0; n < ARRAY_SIZE(ce); n++) {
> + struct intel_context *tmp;
> +
> + tmp = intel_context_create(engine);
> + if (IS_ERR(tmp)) {
> + err = PTR_ERR(tmp);
> + goto err_ce;
> + }
> +
> + err = intel_context_pin(tmp);
> + if (err) {
> + intel_context_put(tmp);
> + goto err_ce;
> + }
> +
> + memset32(tmp->ring->vaddr,
> + 0xdeadbeef, /* trigger a hang if executed */
> + tmp->ring->vma->size / sizeof(u32));
> +
> + ce[n] = tmp;
> + }
> +
> + rq = igt_spinner_create_request(spin, ce[0], MI_ARB_CHECK);
> + if (IS_ERR(rq)) {
> + err = PTR_ERR(rq);
> + goto err_ce;
> + }
> +
> + i915_request_get(rq);
> + rq->sched.attr.priority = I915_PRIORITY_BARRIER;
> + i915_request_add(rq);
> +
> + if (!igt_wait_for_spinner(spin, rq)) {
> + intel_gt_set_wedged(engine->gt);
> + i915_request_put(rq);
> + err = -ETIME;
> + goto err_ce;
> + }
> +
> + /* Fill the ring, until we will cause a wrap */
> + n = 0;
> + while (ce[0]->ring->tail - rq->wa_tail <= sz) {
> + struct i915_request *tmp;
> +
> + tmp = intel_context_create_request(ce[0]);
> + if (IS_ERR(tmp)) {
> + err = PTR_ERR(tmp);
> + i915_request_put(rq);
> + goto err_ce;
> + }
> +
> + i915_request_add(tmp);
> + intel_engine_flush_submission(engine);
> + n++;
> + }
> + intel_engine_flush_submission(engine);
> + pr_debug("%s: Filled %d with %d nop tails {size:%x, tail:%x, emit:%x,
> rq.tail:%x}\n",
> + engine->name, sz, n,
> + ce[0]->ring->size,
> + ce[0]->ring->tail,
> + ce[0]->ring->emit,
> + rq->tail);
> + GEM_BUG_ON(intel_ring_direction(ce[0]->ring,
> + rq->tail,
> + ce[0]->ring->tail) <= 0);
> + i915_request_put(rq);
> +
> + /* Create a second request to preempt the first ring */
> + rq = intel_context_create_request(ce[1]);
> + if (IS_ERR(rq)) {
> + err = PTR_ERR(rq);
> + goto err_ce;
> + }
> +
> + rq->sched.attr.priority = I915_PRIORITY_BARRIER;
> + i915_request_get(rq);
> + i915_request_add(rq);
> +
> + err = wait_for_submit(engine, rq, HZ / 2);
> + i915_request_put(rq);
> + if (err) {
> + pr_err("%s: preemption request was not submited\n",
> +engine->name);
> + err = -ETIME;
> + }
> +
> + pr_debug("%s: ring[0]:{ tail:%x, emit:%x }, ring[1]:{ tail:%x, emit:%x
> }\n",
> + engine->name,
> + ce[0]->ring->tail, ce[0]->ring->emit,
> + ce[1]->ring->tail, ce[1]->ring->emit);
> +
> +err_ce:
> + intel_engine_flush_submission(engine);
> + igt_spinner_end(spin);
> + for (n = 0; n < ARRAY_SIZE(ce); n++) {
> + if (IS_ERR_OR_NULL(ce[n]))
> + break;
> +
> + intel_context_unpin(ce[n]);
> + intel_context_put(ce[n]);
> + }
> + if (igt_live_test_end(&t))
> + err = -EIO;
> + return err;
> +}
> +
> +static int live_preempt_ring(void *arg)
> +{
> + struct intel_gt *gt = arg;
> + struct intel_engine_cs *engine;
> + struct igt_spinner spin;
> + enum intel_engine_id id;
> + int err = 0;
> +
> + /*
> + * Check that we rollback large c
Re: [Intel-gfx] [PATCH] drm/i915: Mark up inline getters as taking a const i915_request
Chris Wilson writes:
> Since these inline routines only return from the i915_request to return
only return desired pointer from i915_request
> the desired pointer (after checking the preconditions for acquiring said
> pointer), they can be const.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_request.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_request.h
> b/drivers/gpu/drm/i915/i915_request.h
> index 118ab6650d1f..590762820761 100644
> --- a/drivers/gpu/drm/i915/i915_request.h
> +++ b/drivers/gpu/drm/i915/i915_request.h
> @@ -561,7 +561,7 @@ static inline void i915_request_clear_hold(struct
> i915_request *rq)
> }
>
> static inline struct intel_timeline *
> -i915_request_timeline(struct i915_request *rq)
> +i915_request_timeline(const struct i915_request *rq)
> {
> /* Valid only while the request is being constructed (or retired). */
> return rcu_dereference_protected(rq->timeline,
> @@ -569,14 +569,14 @@ i915_request_timeline(struct i915_request *rq)
> }
>
> static inline struct i915_gem_context *
> -i915_request_gem_context(struct i915_request *rq)
> +i915_request_gem_context(const struct i915_request *rq)
> {
> /* Valid only while the request is being constructed (or retired). */
> return rcu_dereference_protected(rq->context->gem_context, true);
> }
>
> static inline struct intel_timeline *
> -i915_request_active_timeline(struct i915_request *rq)
> +i915_request_active_timeline(const struct i915_request *rq)
> {
> /*
>* When in use during submission, we are protected by a guarantee that
> --
> 2.20.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
Re: [Intel-gfx] [PATCH] drm/i915/dp: Poll for DDI Idle status to be 0 after enabling DDI Buf
On Tue, Jun 16, 2020 at 10:54:22PM +0300, Ville Syrjälä wrote: > On Tue, Jun 16, 2020 at 10:42:44PM +0300, Ville Syrjälä wrote: > > On Tue, Jun 16, 2020 at 12:30:56PM -0700, Manasi Navare wrote: > > > The Bspec sequence expects us to poll for DDI Idle status > > > to be 0 (not idle) with a timeout of 600usecs after enabling the > > > DDI BUF CTL. > > > > It only says that for newer platforms. We need to either keep > > the fixed delay before starting to poll, or someone needs confirm > > how the idle bit really behaves on the older platforms. > > In fact it says not to use this bit at all on BXT. So even our disable > sequence is potentially borked on BXT. Unfortunately the spec doesn't > say which way the bit is broken, so not clear if that's the case or > not. > I double checked on Gen 9, it is > 518 usecs timeout and Gen 10+ it is 500usecs and then gen 12, it is 600 usecs timeout. Should we add this max timeout for Gen >=10, we def need this for platforms starting Gen 10+ Manasi > > > > > But currently in the driver we just wait for 600usecs > > > without polling so add that. > > > > > > Cc: Ville Syrjälä > > > Cc: Imre Deak > > > Signed-off-by: Manasi Navare > > > --- > > > drivers/gpu/drm/i915/display/intel_ddi.c | 6 +- > > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c > > > b/drivers/gpu/drm/i915/display/intel_ddi.c > > > index ca7bb2294d2b..de7e15de0bc5 100644 > > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c > > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c > > > @@ -4023,7 +4023,11 @@ static void intel_ddi_prepare_link_retrain(struct > > > intel_dp *intel_dp) > > > intel_de_write(dev_priv, DDI_BUF_CTL(port), intel_dp->DP); > > > intel_de_posting_read(dev_priv, DDI_BUF_CTL(port)); > > > > > > - udelay(600); > > > + if (wait_for_us(!(intel_de_read(dev_priv, DDI_BUF_CTL(port)) & > > > + DDI_BUF_IS_IDLE), > > > + 600)) > > > + drm_err(&dev_priv->drm, "DDI port:%c buffer idle\n", > > > + port_name(port)); > > > } > > > > > > static void intel_ddi_set_link_train(struct intel_dp *intel_dp, > > > -- > > > 2.19.1 > > > > -- > > Ville Syrjälä > > Intel > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Ville Syrjälä > Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Poll for DDI Idle status to be 0 after enabling DDI Buf
On Tue, Jun 16, 2020 at 10:42:44PM +0300, Ville Syrjälä wrote: > On Tue, Jun 16, 2020 at 12:30:56PM -0700, Manasi Navare wrote: > > The Bspec sequence expects us to poll for DDI Idle status > > to be 0 (not idle) with a timeout of 600usecs after enabling the > > DDI BUF CTL. > > It only says that for newer platforms. We need to either keep > the fixed delay before starting to poll, or someone needs confirm > how the idle bit really behaves on the older platforms. In fact it says not to use this bit at all on BXT. So even our disable sequence is potentially borked on BXT. Unfortunately the spec doesn't say which way the bit is broken, so not clear if that's the case or not. > > > But currently in the driver we just wait for 600usecs > > without polling so add that. > > > > Cc: Ville Syrjälä > > Cc: Imre Deak > > Signed-off-by: Manasi Navare > > --- > > drivers/gpu/drm/i915/display/intel_ddi.c | 6 +- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c > > b/drivers/gpu/drm/i915/display/intel_ddi.c > > index ca7bb2294d2b..de7e15de0bc5 100644 > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c > > @@ -4023,7 +4023,11 @@ static void intel_ddi_prepare_link_retrain(struct > > intel_dp *intel_dp) > > intel_de_write(dev_priv, DDI_BUF_CTL(port), intel_dp->DP); > > intel_de_posting_read(dev_priv, DDI_BUF_CTL(port)); > > > > - udelay(600); > > + if (wait_for_us(!(intel_de_read(dev_priv, DDI_BUF_CTL(port)) & > > + DDI_BUF_IS_IDLE), > > + 600)) > > + drm_err(&dev_priv->drm, "DDI port:%c buffer idle\n", > > + port_name(port)); > > } > > > > static void intel_ddi_set_link_train(struct intel_dp *intel_dp, > > -- > > 2.19.1 > > -- > Ville Syrjälä > Intel > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel ___ 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/6] drm/i915/tgl+: Use the correct DP_TP_* register instances in MST encoders
== Series Details ==
Series: series starting with [1/6] drm/i915/tgl+: Use the correct DP_TP_*
register instances in MST encoders
URL : https://patchwork.freedesktop.org/series/78423/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8635 -> Patchwork_17964
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17964/index.html
Known issues
Here are the changes found in Patchwork_17964 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-guc: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-icl-guc/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17964/fi-icl-guc/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17964/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
Possible fixes
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][5] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17964/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-guc: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-icl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17964/fi-icl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
Warnings
* igt@i915_module_load@reload:
- fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][10] ([i915#62] / [i915#92])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-kbl-x1275/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17964/fi-kbl-x1275/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-rte:
- fi-kbl-guc: [SKIP][11] ([fdo#109271]) -> [FAIL][12] ([i915#665] /
[i915#704])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17964/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) ->
[DMESG-WARN][14] ([i915#62] / [i915#92] / [i915#95])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17964/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.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#1569]: https://gitlab.freedesktop.org/drm/intel/issues/1569
[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#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#665]: https://gitlab.freedesktop.org/drm/intel/issues/665
[i915#704]: https://gitlab.freedesktop.org/drm/intel/issues/704
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (47 -> 42)
--
Missing(5): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-byt-clapper
fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8635 -> Patchwork_17964
CI-20190529: 20190529
CI_DRM_8635: f9acdb898773f94ac1bcb9a8826596f88412a53b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5711: 90611a0c90afa4a46496c78a4faf9638a1538ac3 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17964: d302e0a23522a808ab7073bf458e7b70df70def3 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
d302e0a23522 drm/i915/dp_mst: Ensure the DPCD ACT sent flag is cleared before
waiting for it
005be72f6fe4 drm/i915/dp_mst: Clear the ACT sent flag during encoder disabl
Re: [Intel-gfx] [PATCH] drm/i915/dp: Poll for DDI Idle status to be 0 after enabling DDI Buf
On Tue, Jun 16, 2020 at 12:30:56PM -0700, Manasi Navare wrote: > The Bspec sequence expects us to poll for DDI Idle status > to be 0 (not idle) with a timeout of 600usecs after enabling the > DDI BUF CTL. It only says that for newer platforms. We need to either keep the fixed delay before starting to poll, or someone needs confirm how the idle bit really behaves on the older platforms. > But currently in the driver we just wait for 600usecs > without polling so add that. > > Cc: Ville Syrjälä > Cc: Imre Deak > Signed-off-by: Manasi Navare > --- > drivers/gpu/drm/i915/display/intel_ddi.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c > b/drivers/gpu/drm/i915/display/intel_ddi.c > index ca7bb2294d2b..de7e15de0bc5 100644 > --- a/drivers/gpu/drm/i915/display/intel_ddi.c > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c > @@ -4023,7 +4023,11 @@ static void intel_ddi_prepare_link_retrain(struct > intel_dp *intel_dp) > intel_de_write(dev_priv, DDI_BUF_CTL(port), intel_dp->DP); > intel_de_posting_read(dev_priv, DDI_BUF_CTL(port)); > > - udelay(600); > + if (wait_for_us(!(intel_de_read(dev_priv, DDI_BUF_CTL(port)) & > + DDI_BUF_IS_IDLE), > + 600)) > + drm_err(&dev_priv->drm, "DDI port:%c buffer idle\n", > + port_name(port)); > } > > static void intel_ddi_set_link_train(struct intel_dp *intel_dp, > -- > 2.19.1 -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/dp: Poll for DDI Idle status to be 0 after enabling DDI Buf
The Bspec sequence expects us to poll for DDI Idle status to be 0 (not idle) with a timeout of 600usecs after enabling the DDI BUF CTL. But currently in the driver we just wait for 600usecs without polling so add that. Cc: Ville Syrjälä Cc: Imre Deak Signed-off-by: Manasi Navare --- drivers/gpu/drm/i915/display/intel_ddi.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index ca7bb2294d2b..de7e15de0bc5 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -4023,7 +4023,11 @@ static void intel_ddi_prepare_link_retrain(struct intel_dp *intel_dp) intel_de_write(dev_priv, DDI_BUF_CTL(port), intel_dp->DP); intel_de_posting_read(dev_priv, DDI_BUF_CTL(port)); - udelay(600); + if (wait_for_us(!(intel_de_read(dev_priv, DDI_BUF_CTL(port)) & + DDI_BUF_IS_IDLE), + 600)) + drm_err(&dev_priv->drm, "DDI port:%c buffer idle\n", + port_name(port)); } static void intel_ddi_set_link_train(struct intel_dp *intel_dp, -- 2.19.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: fix missing null check on allocated dsb object
== Series Details ==
Series: drm/i915/display: fix missing null check on allocated dsb object
URL : https://patchwork.freedesktop.org/series/78414/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8635 -> Patchwork_17962
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17962/index.html
Known issues
Here are the changes found in Patchwork_17962 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-apl-guc: [PASS][1] -> [INCOMPLETE][2] ([i915#1242])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-apl-guc/igt@gem_exec_susp...@basic-s0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17962/fi-apl-guc/igt@gem_exec_susp...@basic-s0.html
- fi-tgl-u2: [PASS][3] -> [FAIL][4] ([i915#1888])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17962/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17962/fi-glk-dsi/igt@i915_pm_...@module-reload.html
Possible fixes
* igt@i915_pm_rpm@basic-pci-d3-state:
- {fi-tgl-dsi}: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17962/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
- fi-bsw-kefka: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17962/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17962/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-guc: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-icl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17962/fi-icl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
Warnings
* igt@kms_flip@basic-flip-vs-dpms@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][16] ([i915#62] / [i915#92])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-d...@a-dp1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17962/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-d...@a-dp1.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92]) ->
[DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95]) +5 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17962/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1242]: https://gitlab.freedesktop.org/drm/intel/issues/1242
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (47 -> 41)
--
Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-whl-u
fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8635 -> Patchwork_17962
CI-20190529: 20190529
CI_DRM_8635: f9acdb898773f94ac1bcb9a8826596f88412a53b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5711: 90611a0c90afa4a46496c78a4faf9638a1538ac3 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17962: f48c185da47b189fee405b28a4e607332d5b200d @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
f48c185da47b drm/i915/display: fix
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/shmem-helper: Only dma-buf imports are private obj
== Series Details == Series: drm/shmem-helper: Only dma-buf imports are private obj URL : https://patchwork.freedesktop.org/series/78416/ State : failure == Summary == Applying: drm/shmem-helper: Only dma-buf imports are private obj Using index info to reconstruct a base tree... M drivers/gpu/drm/drm_gem_shmem_helper.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/drm_gem_shmem_helper.c No changes -- Patch already applied. ___ 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 a couple of spelling mistakes in kernel parameter help text
== Series Details == Series: drm/i915: fix a couple of spelling mistakes in kernel parameter help text URL : https://patchwork.freedesktop.org/series/78407/ State : success == Summary == CI Bug Log - changes from CI_DRM_8634_full -> Patchwork_17958_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17958_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@vcs0: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8634/shard-kbl2/igt@gem_ctx_isolation@preservation...@vcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17958/shard-kbl3/igt@gem_ctx_isolation@preservation...@vcs0.html * igt@gem_exec_schedule@smoketest-all: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8634/shard-glk4/igt@gem_exec_sched...@smoketest-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17958/shard-glk2/igt@gem_exec_sched...@smoketest-all.html * igt@gem_workarounds@suspend-resume-fd: - shard-snb: [PASS][5] -> [DMESG-WARN][6] ([i915#42]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8634/shard-snb6/igt@gem_workarou...@suspend-resume-fd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17958/shard-snb5/igt@gem_workarou...@suspend-resume-fd.html * igt@i915_module_load@reload: - shard-tglb: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8634/shard-tglb6/igt@i915_module_l...@reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17958/shard-tglb3/igt@i915_module_l...@reload.html * igt@kms_cursor_crc@pipe-a-cursor-128x128-onscreen: - shard-skl: [PASS][9] -> [FAIL][10] ([i915#54]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8634/shard-skl10/igt@kms_cursor_...@pipe-a-cursor-128x128-onscreen.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17958/shard-skl2/igt@kms_cursor_...@pipe-a-cursor-128x128-onscreen.html * igt@kms_cursor_edge_walk@pipe-c-256x256-bottom-edge: - shard-glk: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8634/shard-glk7/igt@kms_cursor_edge_w...@pipe-c-256x256-bottom-edge.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17958/shard-glk1/igt@kms_cursor_edge_w...@pipe-c-256x256-bottom-edge.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ab-hdmi-a1-hdmi-a2: - shard-glk: [PASS][13] -> [FAIL][14] ([i915#79]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8634/shard-glk8/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ab-hdmi-a1-hdmi-a2.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17958/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ab-hdmi-a1-hdmi-a2.html * igt@kms_flip@flip-vs-expired-vblank@a-edp1: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#79]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8634/shard-skl5/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17958/shard-skl10/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html * igt@kms_flip@plain-flip-fb-recreate-interruptible@b-edp1: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#1928]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8634/shard-skl2/igt@kms_flip@plain-flip-fb-recreate-interrupti...@b-edp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17958/shard-skl1/igt@kms_flip@plain-flip-fb-recreate-interrupti...@b-edp1.html * igt@kms_flip_tiling@flip-changes-tiling-y: - shard-apl: [PASS][19] -> [DMESG-FAIL][20] ([i915#95]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8634/shard-apl1/igt@kms_flip_til...@flip-changes-tiling-y.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17958/shard-apl7/igt@kms_flip_til...@flip-changes-tiling-y.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8634/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-pwrite.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17958/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-pwrite.html * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-wc: - shard-tglb: [PASS][23] -> [DMESG-WARN][24] ([i915#1982]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8634/shard-tglb1/ig
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: fix missing null check on allocated dsb object
== Series Details ==
Series: drm/i915/display: fix missing null check on allocated dsb object
URL : https://patchwork.freedesktop.org/series/78414/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f48c185da47b drm/i915/display: fix missing null check on allocated dsb object
-:27: WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message
#27: FILE: drivers/gpu/drm/i915/display/intel_dsb.c:275:
+ if (!dsb) {
+ drm_err(&i915->drm, "DSB object creation failed\n");
total: 0 errors, 1 warnings, 0 checks, 10 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Decouple completed requests on unwind
Since the introduction of preempt-to-busy, requests can complete in the
background, even while they are not on the engine->active.requests list.
As such, the engine->active.request list itself is not in strict
retirement order, and we have to scan the entire list while unwinding to
not miss any. However, if the request is completed we currently leave it
on the list [until retirement], but we could just as simply remove it
and stop treating it as active. We would only have to then traverse it
once while unwinding in quick succession.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e866b8d721ed..4eb397b0e14d 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1114,8 +1114,10 @@ __unwind_incomplete_requests(struct intel_engine_cs
*engine)
list_for_each_entry_safe_reverse(rq, rn,
&engine->active.requests,
sched.link) {
- if (i915_request_completed(rq))
- continue; /* XXX */
+ if (i915_request_completed(rq)) {
+ list_del_init(&rq->sched.link);
+ continue;
+ }
__i915_request_unsubmit(rq);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Check preemption rollback of different ring queue depths
== Series Details == Series: drm/i915/selftests: Check preemption rollback of different ring queue depths URL : https://patchwork.freedesktop.org/series/78411/ State : success == Summary == CI Bug Log - changes from CI_DRM_8635 -> Patchwork_17961 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17961/index.html Known issues Here are the changes found in Patchwork_17961 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0: - fi-apl-guc: [PASS][1] -> [INCOMPLETE][2] ([i915#1242]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-apl-guc/igt@gem_exec_susp...@basic-s0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17961/fi-apl-guc/igt@gem_exec_susp...@basic-s0.html - fi-tgl-u2: [PASS][3] -> [FAIL][4] ([i915#1888]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17961/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html Possible fixes * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17961/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html * igt@kms_busy@basic@flip: - fi-kbl-x1275: [DMESG-WARN][7] ([i915#62] / [i915#92] / [i915#95]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-kbl-x1275/igt@kms_busy@ba...@flip.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17961/fi-kbl-x1275/igt@kms_busy@ba...@flip.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-icl-guc: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-icl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17961/fi-icl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html Warnings * igt@i915_module_load@reload: - fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][12] ([i915#62] / [i915#92]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-kbl-x1275/igt@i915_module_l...@reload.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17961/fi-kbl-x1275/igt@i915_module_l...@reload.html * igt@kms_force_connector_basic@force-edid: - fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) -> [DMESG-WARN][14] ([i915#62] / [i915#92] / [i915#95]) +5 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17961/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [i915#1242]: https://gitlab.freedesktop.org/drm/intel/issues/1242 [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (47 -> 41) -- Missing(6): fi-ilk-m540 fi-byt-squawks fi-glk-dsi fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8635 -> Patchwork_17961 CI-20190529: 20190529 CI_DRM_8635: f9acdb898773f94ac1bcb9a8826596f88412a53b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5711: 90611a0c90afa4a46496c78a4faf9638a1538ac3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17961: 6fd85c27f831221e7c9b2339ff44f835f8ca19da @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 6fd85c27f831 drm/i915/selftests: Check preemption rollback of different ring queue depths == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17961/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/2] drm/i915/selftests: Use friendly request names for live_timeslice_rewind
Rather than mixing [012] and (A1, A2, B2) for the request indices, use
the enums throughout.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 5c5900443c52..e709361c139e 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -1177,18 +1177,18 @@ static int live_timeslice_rewind(void *arg)
goto err;
}
- rq[0] = create_rewinder(ce, NULL, slot, X);
- if (IS_ERR(rq[0])) {
+ rq[A1] = create_rewinder(ce, NULL, slot, X);
+ if (IS_ERR(rq[A1])) {
intel_context_put(ce);
goto err;
}
- rq[1] = create_rewinder(ce, NULL, slot, Y);
+ rq[A2] = create_rewinder(ce, NULL, slot, Y);
intel_context_put(ce);
- if (IS_ERR(rq[1]))
+ if (IS_ERR(rq[A2]))
goto err;
- err = wait_for_submit(engine, rq[1], HZ / 2);
+ err = wait_for_submit(engine, rq[A2], HZ / 2);
if (err) {
pr_err("%s: failed to submit first context\n",
engine->name);
@@ -1201,12 +1201,12 @@ static int live_timeslice_rewind(void *arg)
goto err;
}
- rq[2] = create_rewinder(ce, rq[0], slot, Z);
+ rq[B1] = create_rewinder(ce, rq[A1], slot, Z);
intel_context_put(ce);
if (IS_ERR(rq[2]))
goto err;
- err = wait_for_submit(engine, rq[2], HZ / 2);
+ err = wait_for_submit(engine, rq[B1], HZ / 2);
if (err) {
pr_err("%s: failed to submit second context\n",
engine->name);
@@ -1214,6 +1214,7 @@ static int live_timeslice_rewind(void *arg)
}
/* ELSP[] = { { A:rq1, A:rq2 }, { B:rq1 } } */
+ ENGINE_TRACE(engine, "forcing tasklet for rewind\n");
if (i915_request_is_active(rq[A2])) { /* semaphore yielded! */
/* Wait for the timeslice to kick in */
del_timer(&engine->execlists.timer);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/2] drm/i915/selftests: Exercise far preemption rollbacks
Not too long ago, we realised we had issues with a rolling back a
context so far for a preemption request we considered the resubmit not
to be a rollback but a forward roll. This means we would issue a lite
restore instead of forcing a full restore, continuing execution of the
old requests rather than causing a preemption. Add a selftest to
exercise such a far rollback, such that if we were to skip the full
restore, we would execute invalid instructions in the ring and hang.
Note that while I was able to confirm that this causes us to do a
lite-restore preemption rollback (with commit e36ba817fa96 ("drm/i915/gt:
Incrementally check for rewinding") disabled), it did not trick the HW
into rolling past the old RING_TAIL. Myybe on other HW.
References: e36ba817fa96 ("drm/i915/gt: Incrementally check for rewinding")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 151 +
1 file changed, 151 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 91543494f595..5c5900443c52 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -363,6 +363,156 @@ static int live_unlite_preempt(void *arg)
return live_unlite_restore(arg, I915_USER_PRIORITY(I915_PRIORITY_MAX));
}
+static int live_unlite_ring(void *arg)
+{
+ struct intel_gt *gt = arg;
+ struct intel_engine_cs *engine;
+ struct igt_spinner spin;
+ enum intel_engine_id id;
+ int err = 0;
+
+ /*
+* Setup a preemption event that will cause almost the entire ring
+* to be unwound, potentially fooling our intel_ring_direction()
+* into emitting a forward lite-restore instead of the rollback.
+*/
+
+ if (igt_spinner_init(&spin, gt))
+ return -ENOMEM;
+
+ for_each_engine(engine, gt, id) {
+ struct intel_context *ce[2] = {};
+ struct i915_request *rq;
+ struct igt_live_test t;
+ int n;
+
+ if (!intel_engine_has_preemption(engine))
+ continue;
+
+ if (!intel_engine_can_store_dword(engine))
+ continue;
+
+ if (igt_live_test_begin(&t, gt->i915, __func__, engine->name)) {
+ err = -EIO;
+ break;
+ }
+ engine_heartbeat_disable(engine);
+
+ for (n = 0; n < ARRAY_SIZE(ce); n++) {
+ struct intel_context *tmp;
+
+ tmp = intel_context_create(engine);
+ if (IS_ERR(tmp)) {
+ err = PTR_ERR(tmp);
+ goto err_ce;
+ }
+
+ err = intel_context_pin(tmp);
+ if (err) {
+ intel_context_put(tmp);
+ goto err_ce;
+ }
+
+ memset32(tmp->ring->vaddr,
+0xdeadbeef, /* trigger a hang if executed */
+tmp->ring->vma->size / sizeof(u32));
+
+ ce[n] = tmp;
+ }
+
+ /* Create max prio spinner, followed by N low prio nops */
+ rq = igt_spinner_create_request(&spin, ce[0], MI_ARB_CHECK);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err_ce;
+ }
+
+ i915_request_get(rq);
+ rq->sched.attr.priority = I915_PRIORITY_BARRIER;
+ i915_request_add(rq);
+
+ if (!igt_wait_for_spinner(&spin, rq)) {
+ intel_gt_set_wedged(gt);
+ i915_request_put(rq);
+ err = -ETIME;
+ goto err_ce;
+ }
+
+ /* Fill the ring, until we will cause a wrap */
+ n = 0;
+ while (intel_ring_direction(ce[0]->ring,
+ rq->wa_tail,
+ ce[0]->ring->tail) <= 0) {
+ struct i915_request *tmp;
+
+ tmp = intel_context_create_request(ce[0]);
+ if (IS_ERR(tmp)) {
+ err = PTR_ERR(tmp);
+ i915_request_put(rq);
+ goto err_ce;
+ }
+
+ i915_request_add(tmp);
+ intel_engine_flush_submission(engine);
+ n++;
+ }
+ intel_engine_flush_submission(engine);
+ pr_debug("%s: Filled ring with %d nop tails {size:%x, tail:%x,
emit:%x, rq.tail:%x}\n",
+engine->name, n,
+
Re: [Intel-gfx] [PATCH] drm/i915/gvt: query if vgpu is active via GETPARAM IOCTL
Quoting Shaofeng Tang (2020-06-16 09:29:20) > [Why] > Query if vgpu is active, it is useful to the user. > Currently, only the primary plane is usable when vgpu is active. > The value of vgpu active is useful for user to determine > how many planes can be used. also useful for user to > determine different behaviors according to vgpu is active or not. The number of planes must be queried via kms, and all such kernel capabilities should be declared via the appropriate interface. I am not saying that there is not potentially good reason to let the user to know it's a virtual gpu, but hardcoding api limits in the client based on the parameter is a bad idea. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/9] drm/i915/selftests: Exercise far preemption rollbacks
== Series Details ==
Series: series starting with [1/9] drm/i915/selftests: Exercise far preemption
rollbacks
URL : https://patchwork.freedesktop.org/series/78410/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8635 -> Patchwork_17960
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17960 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17960, 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_17960/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17960:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@gt_engines:
- fi-kbl-soraka: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-kbl-soraka/igt@i915_selftest@live@gt_engines.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17960/fi-kbl-soraka/igt@i915_selftest@live@gt_engines.html
- fi-icl-y: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-icl-y/igt@i915_selftest@live@gt_engines.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17960/fi-icl-y/igt@i915_selftest@live@gt_engines.html
- fi-bsw-n3050: [PASS][5] -> [FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-bsw-n3050/igt@i915_selftest@live@gt_engines.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17960/fi-bsw-n3050/igt@i915_selftest@live@gt_engines.html
- fi-cml-s: [PASS][7] -> [FAIL][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-cml-s/igt@i915_selftest@live@gt_engines.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17960/fi-cml-s/igt@i915_selftest@live@gt_engines.html
- fi-skl-6600u: [PASS][9] -> [FAIL][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-skl-6600u/igt@i915_selftest@live@gt_engines.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17960/fi-skl-6600u/igt@i915_selftest@live@gt_engines.html
- fi-bsw-kefka: [PASS][11] -> [FAIL][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-bsw-kefka/igt@i915_selftest@live@gt_engines.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17960/fi-bsw-kefka/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@hangcheck:
- fi-tgl-u2: [PASS][13] -> [INCOMPLETE][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-tgl-u2/igt@i915_selftest@l...@hangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17960/fi-tgl-u2/igt@i915_selftest@l...@hangcheck.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gt_engines:
- {fi-tgl-dsi}: [PASS][15] -> [FAIL][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-tgl-dsi/igt@i915_selftest@live@gt_engines.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17960/fi-tgl-dsi/igt@i915_selftest@live@gt_engines.html
Known issues
Here are the changes found in Patchwork_17960 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-kbl-soraka: [PASS][17] -> [DMESG-WARN][18] ([i915#1982])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-kbl-soraka/igt@i915_pm_...@module-reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17960/fi-kbl-soraka/igt@i915_pm_...@module-reload.html
- fi-apl-guc: [PASS][19] -> [DMESG-WARN][20] ([i915#1982])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-apl-guc/igt@i915_pm_...@module-reload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17960/fi-apl-guc/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@hangcheck:
- fi-glk-dsi: [PASS][21] -> [INCOMPLETE][22] ([i915#58] /
[k.org#198133])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-glk-dsi/igt@i915_selftest@l...@hangcheck.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17960/fi-glk-dsi/igt@i915_selftest@l...@hangcheck.html
Possible fixes
* igt@i915_pm_rpm@basic-pci-d3-state:
- {fi-tgl-dsi}: [DMESG-WARN][23] ([i915#1982]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8635/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17960/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMES
[Intel-gfx] [PATCH] drm/i915: Mark up inline getters as taking a const i915_request
Since these inline routines only return from the i915_request to return
the desired pointer (after checking the preconditions for acquiring said
pointer), they can be const.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index 118ab6650d1f..590762820761 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -561,7 +561,7 @@ static inline void i915_request_clear_hold(struct
i915_request *rq)
}
static inline struct intel_timeline *
-i915_request_timeline(struct i915_request *rq)
+i915_request_timeline(const struct i915_request *rq)
{
/* Valid only while the request is being constructed (or retired). */
return rcu_dereference_protected(rq->timeline,
@@ -569,14 +569,14 @@ i915_request_timeline(struct i915_request *rq)
}
static inline struct i915_gem_context *
-i915_request_gem_context(struct i915_request *rq)
+i915_request_gem_context(const struct i915_request *rq)
{
/* Valid only while the request is being constructed (or retired). */
return rcu_dereference_protected(rq->context->gem_context, true);
}
static inline struct intel_timeline *
-i915_request_active_timeline(struct i915_request *rq)
+i915_request_active_timeline(const struct i915_request *rq)
{
/*
* When in use during submission, we are protected by a guarantee that
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/9] drm/i915/selftests: Exercise far preemption rollbacks
== Series Details ==
Series: series starting with [1/9] drm/i915/selftests: Exercise far preemption
rollbacks
URL : https://patchwork.freedesktop.org/series/78410/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
49d66c60e62f drm/i915/selftests: Exercise far preemption rollbacks
-:19: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit e36ba817fa96 ("drm/i915/gt:
Incrementally check for rewinding")'
#19:
References: e36ba817fa96 ("drm/i915/gt: Incrementally check for rewinding")
total: 1 errors, 0 warnings, 0 checks, 162 lines checked
c6088929414a drm/i915/selftests: Use friendly request names for
live_timeslice_rewind
110ee4d71849 drm/i915/selftests: Enable selftesting of busy-stats
-:58: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.rst
#58: FILE: drivers/gpu/drm/i915/gt/selftest_engine_pm.c:48:
+ udelay(100);
-:89: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.rst
#89: FILE: drivers/gpu/drm/i915/gt/selftest_engine_pm.c:79:
+ udelay(100);
total: 0 errors, 0 warnings, 2 checks, 117 lines checked
16284702446a drm/i915/execlists: Replace direct submit with direct call to
tasklet
81ca04a94781 drm/i915/execlists: Defer schedule_out until after the next dequeue
-:117: CHECK:SPACING: spaces preferred around that '*' (ctx:ExV)
#117: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:2441:
+ *execlists->inactive++ = *port;
^
total: 0 errors, 0 warnings, 1 checks, 179 lines checked
499dd7003551 drm/i915/gt: ce->inflight updates are now serialised
2f30d63c06b7 drm/i915/gt: Drop atomic for engine->fw_active tracking
ef92526598ab drm/i915/gt: Extract busy-stats for ring-scheduler
-:12: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#12:
new file mode 100644
total: 0 errors, 1 warnings, 0 checks, 95 lines checked
480f3ff83a82 drm/i915/gt: Convert stats.active to plain unsigned int
___
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/gvt: query if vgpu is active via GETPARAM IOCTL
== Series Details == Series: drm/i915/gvt: query if vgpu is active via GETPARAM IOCTL URL : https://patchwork.freedesktop.org/series/78409/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/i915_getparam.o drivers/gpu/drm/i915/i915_getparam.c: In function ‘i915_getparam_ioctl’: drivers/gpu/drm/i915/i915_getparam.c:165:11: error: implicit declaration of function ‘intel_vgpu_active’; did you mean ‘intel_vtd_active’? [-Werror=implicit-function-declaration] value = intel_vgpu_active(i915); ^ intel_vtd_active cc1: all warnings being treated as errors scripts/Makefile.build:280: recipe for target 'drivers/gpu/drm/i915/i915_getparam.o' failed make[4]: *** [drivers/gpu/drm/i915/i915_getparam.o] Error 1 scripts/Makefile.build:497: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:497: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:497: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1764: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Apply Wa_14011264657:gen11+
On Tue, Jun 16, 2020 at 09:34:06AM -0700, Matt Atwood wrote:
> Add minimum width to planes, variable with specific formats, for gen11+.
>
> Signed-off-by: Matt Atwood
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 55 +---
> 1 file changed, 47 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 7457813ef273..d4fdad6cb3b1 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -3760,6 +3760,45 @@ static int glk_max_plane_width(const struct
> drm_framebuffer *fb,
> }
> }
>
> +static int icl_min_plane_width(struct drm_i915_private *dev_priv,
> + const struct drm_framebuffer *fb)
> +{
> + /* Wa_14011264657, Wa_14011050563 */
> + switch (fb->format->format) {
> + case DRM_FORMAT_C8:
> + return 18;
> + case DRM_FORMAT_RGB565:
> + return 10;
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_ABGR:
> + case DRM_FORMAT_XRGB2101010:
> + case DRM_FORMAT_XBGR2101010:
> + case DRM_FORMAT_ARGB2101010:
> + case DRM_FORMAT_ABGR2101010:
> + case DRM_FORMAT_XVYU2101010:
> + case DRM_FORMAT_Y212:
> + case DRM_FORMAT_Y216:
> + return 6;
> + case DRM_FORMAT_NV12:
> + return 20;
> + case DRM_FORMAT_P010:
> + case DRM_FORMAT_P012:
> + case DRM_FORMAT_P016:
> + return 12;
> + case DRM_FORMAT_XRGB16161616F:
> + case DRM_FORMAT_XBGR16161616F:
> + case DRM_FORMAT_ARGB16161616F:
> + case DRM_FORMAT_ABGR16161616F:
> + case DRM_FORMAT_XVYU12_16161616:
> + case DRM_FORMAT_XVYU16161616:
> + return 4;
> + default:
> + return 1;
> + }
if (semiplanar) {
switch (cpp[0]) {
case 1:
return 20;
case 2:
return 12;
}
} else {
switch (cpp[0]) {
case 1:
return 18;
case 2:
return 10;
case 4:
return 6;
case 8:
return 4;
}
}
Actually if we fully reverse engineer this we are left with just:
if (semiplanar)
return 16/cpp[0] + 4;
else
return 16/cpp[0] + 2;
I'd much prefer calculating this since then it's fully divorced from
defining new pixel formats. Can we get a confirmation from the hw
folks if that is in fact the formula (or if there's a different formula
how they came up with these magic numbers)?
> +}
> +
> static int icl_max_plane_width(const struct drm_framebuffer *fb,
> int color_plane,
> unsigned int rotation)
> @@ -3831,15 +3870,15 @@ static int skl_check_main_surface(struct
> intel_plane_state *plane_state)
> int y = plane_state->uapi.src.y1 >> 16;
> int w = drm_rect_width(&plane_state->uapi.src) >> 16;
> int h = drm_rect_height(&plane_state->uapi.src) >> 16;
> - int max_width;
> - int max_height;
> - u32 alignment;
> - u32 offset;
> + int max_width, min_width = 1, max_height;
> + u32 alignment, offset;
> int aux_plane = intel_main_to_aux_plane(fb, 0);
> u32 aux_offset = plane_state->color_plane[aux_plane].offset;
>
> - if (INTEL_GEN(dev_priv) >= 11)
> + if (INTEL_GEN(dev_priv) >= 11) {
> max_width = icl_max_plane_width(fb, 0, rotation);
> + min_width = icl_min_plane_width(dev_priv, fb);
> + }
> else if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
Missing curly braces on all the branches. Feels like dejavu...
I'd also do the min_width=1 assignment in each branch to make it
clear what's what.
> max_width = glk_max_plane_width(fb, 0, rotation);
> else
> @@ -3850,10 +3889,10 @@ static int skl_check_main_surface(struct
> intel_plane_state *plane_state)
> else
> max_height = skl_max_plane_height();
>
> - if (w > max_width || h > max_height) {
> + if (w > max_width || w < min_width || h > max_height) {
> drm_dbg_kms(&dev_priv->drm,
> - "requested Y/RGB source size %dx%d too big (limit
> %dx%d)\n",
> - w, h, max_width, max_height);
> + "requested Y/RGB source size %dx%d outside limits
> (min: %dx1 max: %dx%d)\n",
> + w, h, min_width, max_width, max_height);
> return -EINVAL;
> }
>
> --
> 2.21.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo
Re: [Intel-gfx] [PATCH 1/6] drm/i915/tgl+: Use the correct DP_TP_* register instances in MST encoders
On Tue, Jun 16, 2020 at 08:02:10PM +0300, Souza, Jose wrote:
> On Tue, 2020-06-16 at 19:42 +0300, Imre Deak wrote:
> > On Tue, Jun 16, 2020 at 07:32:46PM +0300, Souza, Jose wrote:
> > > On Tue, 2020-06-16 at 17:18 +0300, Imre Deak wrote:
> > > > MST encoders must use the master MST transcoder's DP_TP_STATUS and
> > > > DP_TP_CONTROL registers. Atm, during the HW readout of a slave
> > > > transcoder's CRTC state we reset these register addresses in
> > > > intel_dp::regs.dp_tp_* to the slave transcoder's DP_TP_* register
> > > > addresses incorrectly; fix this.
> > > >
> > > > This issue led at least to
> > > > 'Timed out waiting for ACT sent when disabling'
> > > > errors during output disabling in a multiple MST stream config.
> > >
> > > Can you point to place where dp_tp_ctl is used and cause this? All
> > > the MST code paths uses the dp_tp_ctl of the main intel_dp(the one
> > > that is not a mst connector).
> >
> > During a slave stream disabling when waiting for the ACT sent flag for
> > that stream.
> >
> > > > This change replaces
> > > > https://patchwork.freedesktop.org/patch/369577/?series=78193&rev=1
> > > > which just papered over the problem.
> > > >
> > > > Cc: Ville Syrjälä
> > > > Cc: José Roberto de Souza
> > > > Signed-off-by: Imre Deak
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_ddi.c | 15 ++-
> > > > 1 file changed, 10 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > index ca7bb2294d2b..73d6cc29291a 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > @@ -4193,11 +4193,6 @@ void intel_ddi_get_config(struct intel_encoder
> > > > *encoder,
> > > > if (drm_WARN_ON(&dev_priv->drm,
> > > > transcoder_is_dsi(cpu_transcoder)))
> > > > return;
> > > >
> > > > - if (INTEL_GEN(dev_priv) >= 12) {
> > > > - intel_dp->regs.dp_tp_ctl =
> > > > TGL_DP_TP_CTL(cpu_transcoder);
> > > > - intel_dp->regs.dp_tp_status =
> > > > TGL_DP_TP_STATUS(cpu_transcoder);
> > > > - }
> > > > -
> > > > intel_dsc_get_config(encoder, pipe_config);
> > > >
> > > > temp = intel_de_read(dev_priv,
> > > > TRANS_DDI_FUNC_CTL(cpu_transcoder));
> > > > @@ -4299,6 +4294,16 @@ void intel_ddi_get_config(struct intel_encoder
> > > > *encoder,
> > > > break;
> > > > }
> > > >
> > > > + if (INTEL_GEN(dev_priv) >= 12) {
> > > > + enum transcoder transcoder =
> > > > + intel_dp_mst_is_slave_trans(pipe_config) ?
> > > > + pipe_config->mst_master_transcoder :
> > > > + pipe_config->cpu_transcoder;
> > > > +
> > > > + intel_dp->regs.dp_tp_ctl = TGL_DP_TP_CTL(transcoder);
> > > > + intel_dp->regs.dp_tp_status =
> > > > TGL_DP_TP_STATUS(transcoder);
> > > > + }
> > >
> > > Also not sure how change only in the config readout would fix the issue,
> >
> > After a modeset we'll verify the HW state. The readout for a slave
> > stream CRTC (get_pipe_config) running after the master CRTC's readout
> > will overwrite the dp_tp reg addresses. The other instance of dp_tp
> > register address init (in tgl_ddi_pre_enable_dp()) is correct.
>
> intel_mst_post_disable_dp()
> struct intel_digital_port *intel_dig_port = intel_mst->primary;
> struct intel_dp *intel_dp = &intel_dig_port->dp;
>
> ...
>
> if (intel_de_wait_for_set(dev_priv, intel_dp->regs.dp_tp_status,
> DP_TP_STATUS_ACT_SENT, 1))
> drm_err(&dev_priv->drm, "Timed out waiting for ACT sent when
> disabling\n");
>
>
> Until here is right, but yeah bellow is the problem:
>
> static void intel_dp_mst_enc_get_config(struct intel_encoder *encoder,
> struct intel_crtc_state *pipe_config)
> {
> struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
> struct intel_digital_port *intel_dig_port = intel_mst->primary;
>
> intel_ddi_get_config(&intel_dig_port->base, pipe_config);
> }
>
>
> It will be overwritten with the transcoder of the last crtc read.Would
> suggest to add something about intel_dp_mst_enc_get_config() to the
> commit description but the change looks good now.
Hm yea, it's the encoder not the CRTC readout where the overwrite
happens. Will update this in the commit log.
> > > IFWI don't enable MST so when i915 takes over a full modeset will
> > > happen to enable MST and only dp_tp_ctl of the main intel_dp(the one
> > > that is not a mst connector) will be set, check
> > > tgl_ddi_pre_enable_dp().
> > >
> > > > +
> > > > pipe_config->has_audio =
> > > > intel_ddi_is_audio_enabled(dev_priv, cpu_transcoder);
> > > >
___
Inte
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: fix a couple of spelling mistakes in kernel parameter help text
== Series Details ==
Series: drm/i915: fix a couple of spelling mistakes in kernel parameter help
text
URL : https://patchwork.freedesktop.org/series/78407/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8634 -> Patchwork_17958
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17958/index.html
Known issues
Here are the changes found in Patchwork_17958 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8634/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17958/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@i915_module_load@reload:
- fi-byt-j1900: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8634/fi-byt-j1900/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17958/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][5] -> [DMESG-WARN][6] ([i915#62] / [i915#92] /
[i915#95])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8634/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17958/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
Possible fixes
* igt@i915_module_load@reload:
- fi-tgl-u2: [DMESG-WARN][7] ([i915#402]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8634/fi-tgl-u2/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17958/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8634/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17958/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@gt_lrc:
- fi-tgl-u2: [DMESG-FAIL][11] ([i915#1233]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8634/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17958/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
Warnings
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][14] ([i915#62] / [i915#92]) +2 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8634/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17958/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92]) ->
[DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8634/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17958/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#1569]: https://gitlab.freedesktop.org/drm/intel/issues/1569
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[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#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (48 -> 42)
--
Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-tgl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8634 -> Patchwork_17958
CI-20190529: 20190529
CI_DRM_8634: 72c556b3627adef8cef3b7a47c32987b96e7f1c2 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5711: 90611a0c90afa4a46496c78a4faf9638a1538ac3 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17958: b463d0076902a926d54ec11be3d6131cf2416156 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commi
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Implement PSR2 selective fetch
On Tue, 2020-06-16 at 16:16 +0100, Mun, Gwan-gyeong wrote:
> On Mon, 2020-06-15 at 19:40 +0300, Ville Syrjälä wrote:
> > On Fri, Jun 12, 2020 at 08:33:31PM +, Souza, Jose wrote:
> > > On Fri, 2020-06-12 at 19:30 +0300, Ville Syrjälä wrote:
> > > > On Tue, May 26, 2020 at 03:14:46PM -0700, José Roberto de Souza
> > > > wrote:
> > > > > All GEN12 platforms supports PSR2 selective fetch but not all
> > > > > GEN12
> > > > > platforms supports PSR2 hardware tracking(aka RKL).
> > > > >
> > > > > This feature consists in software program registers with the
> > > > > damaged
> > > > > area of each plane this way hardware will only fetch from
> > > > > memory those
> > > > > areas and sent the PSR2 selective update blocks to panel,
> > > > > saving even
> > > > > more power but to it actually happen userspace needs to send
> > > > > the
> > > > > damaged areas otherwise it will still fetch the whole plane as
> > > > > fallback.
> > > > > As today Gnome3 do not send damaged areas and the only
> > > > > compositor that
> > > > > I'm aware that sets the damaged areas is Weston.
> > > > > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/17
> > > > >
> > > > > So here implementing page flip part, it is still completely
> > > > > missing
> > > > > frontbuffer modifications, that is why the
> > > > > enable_psr2_sel_fetch
> > > > > parameter was added.
> > > > >
> > > > > The plan is to switch all GEN12 platforms to selective fetch
> > > > > when
> > > > > ready, it will also depend in add some tests sending damaged
> > > > > areas.
> > > > > I have a hacked version of kms_psr2_su with 3 planes that I can
> > > > > cleanup and send in a few days(99% of PSR2 selective fetch
> > > > > changes was
> > > > > done during my free time while bored during quarantine rainy
> > > > > days).
> > > > >
> > > > > BSpec: 55229
> > > > > Cc: Ville Syrjälä
> > > > > Cc: Imre Deak
> > > > > Cc: Gwan-gyeong Mun
> > > > > Cc: Rodrigo Vivi
> > > > > Cc: Dhinakaran Pandiyan
> > > > > Signed-off-by: José Roberto de Souza
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_display.c | 5 +
> > > > > .../drm/i915/display/intel_display_debugfs.c | 3 +
> > > > > .../drm/i915/display/intel_display_types.h| 10 +
> > > > > drivers/gpu/drm/i915/display/intel_psr.c | 329
> > > > > +-
> > > > > drivers/gpu/drm/i915/display/intel_psr.h | 10 +
> > > > > drivers/gpu/drm/i915/display/intel_sprite.c | 2 +
> > > > > drivers/gpu/drm/i915/i915_drv.h | 2 +
> > > > > drivers/gpu/drm/i915/i915_params.c| 5 +
> > > > > drivers/gpu/drm/i915/i915_params.h| 1 +
> > > > > 9 files changed, 352 insertions(+), 15 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > index b69878334040..984809208c29 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > @@ -11729,6 +11729,8 @@ static void i9xx_update_cursor(struct
> > > > > intel_plane *plane,
> > > > > if (INTEL_GEN(dev_priv) >= 9)
> > > > > skl_write_cursor_wm(plane, crtc_state);
> > > > >
> > > > > + intel_psr2_program_plane_sel_fetch(plane, crtc_state,
> > > > > plane_state);
> > > > > +
> > > > > if (plane->cursor.base != base ||
> > > > > plane->cursor.size != fbc_ctl ||
> > > > > plane->cursor.cntl != cntl) {
> > > > > @@ -15115,6 +15117,8 @@ static void commit_pipe_config(struct
> > > > > intel_atomic_state *state,
> > > > >
> > > > > if (new_crtc_state->update_pipe)
> > > > > intel_pipe_fastset(old_crtc_state,
> > > > > new_crtc_state);
> > > > > +
> > > > > + intel_psr2_program_trans_man_trk_ctl(new_crtc_s
> > > > > tate);
> > > > > }
> > > > >
> > > > > if (dev_priv->display.atomic_update_watermarks)
> > > > > @@ -15156,6 +15160,7 @@ static void intel_update_crtc(struct
> > > > > intel_atomic_state *state,
> > > > > intel_color_load_luts(new_crtc_state);
> > > > >
> > > > > intel_pre_plane_update(state, crtc);
> > > > > + intel_psr2_sel_fetch_update(state, crtc);
> > > > >
> > > > > if (new_crtc_state->update_pipe)
> > > > > intel_encoders_update_pipe(state,
> > > > > crtc);
> > > > > diff --git
> > > > > a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > > > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > > > index 70525623bcdf..0f600974462b 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > > > @@ -417,6 +417,9 @@ static int i915_edp_psr_status(struct
> > > > > seq_file *m, void *data)
> > > > > su_blocks = su_blocks >>
> > > > > PSR2_SU_STATUS_SHIFT(fra
Re: [Intel-gfx] [PATCH 7/8] drm/mipi-dbi: Remove ->enabled
On Tue, Jun 16, 2020 at 3:57 PM Emil Velikov wrote: > > On Tue, 16 Jun 2020 at 07:50, Daniel Vetter wrote: > > > > On Mon, Jun 15, 2020 at 11:35 PM Emil Velikov > > wrote: > > > > > > Hi Daniel, > > > > > > On Fri, 12 Jun 2020 at 17:01, Daniel Vetter > > > wrote: > > > > > > > > The atomic helpers try really hard to not lose track of things, > > > > duplicating enabled tracking in the driver is at best confusing. > > > > Double-enabling or disabling is a bug in atomic helpers. > > > > > > > > In the fb_dirty function we can just assume that the fb always exists, > > > > simple display pipe helpers guarantee that the crtc is only enabled > > > > together with the output, so we always have a primary plane around. > > > > > > > > Now in the update function we need to be a notch more careful, since > > > > that can also get called when the crtc is off. And we don't want to > > > > upload frames when that's the case, so filter that out too. > > > > > > > > Signed-off-by: Daniel Vetter > > > > Cc: Maarten Lankhorst > > > > Cc: Maxime Ripard > > > > Cc: Thomas Zimmermann > > > > Cc: David Airlie > > > > Cc: Daniel Vetter > > > > Cc: David Lechner > > > > --- > > > > drivers/gpu/drm/drm_mipi_dbi.c | 16 ++-- > > > > drivers/gpu/drm/tiny/ili9225.c | 12 +++- > > > > drivers/gpu/drm/tiny/st7586.c | 11 +++ > > > > include/drm/drm_mipi_dbi.h | 5 - > > > > 4 files changed, 12 insertions(+), 32 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/drm_mipi_dbi.c > > > > b/drivers/gpu/drm/drm_mipi_dbi.c > > > > index fd8d672972a9..79532b9a324a 100644 > > > > --- a/drivers/gpu/drm/drm_mipi_dbi.c > > > > +++ b/drivers/gpu/drm/drm_mipi_dbi.c > > > > @@ -268,7 +268,7 @@ static void mipi_dbi_fb_dirty(struct > > > > drm_framebuffer *fb, struct drm_rect *rect) > > > > bool full; > > > > void *tr; > > > > > > > > - if (!dbidev->enabled) > > > > + if (WARN_ON(!fb)) > > > > return; > > > > > > > AFAICT no other driver has such WARN_ON. Let's drop that - it is > > > pretty confusing and misleading as-is. > > > > Yeah, this is a helper library which might be used wrongly by drivers. > > That's why I put it in - if you don't put all the various calls > > together correctly, this should at least catch one case. So really > > would like to keep this, can I convince you? > > There are plenty of similar places where a drm library/helper can be > misused, lacking a WARN. Nevertheless - sure feel free to keep it. Yeah I agree, we can't check for everything. Personally I think a check is warranted in two conditions: - drivers got it wrong, and the WARNING helps catch driver-bugs we've seen in the wild. Not really the case here - drivers do check something as defensive programming, but it's an invariant enforced by higher levels or helpers. Those I like to convert to WARNING so that other driver authors learn that this should never happen. This is such a case imo, I removed a bunch of fb checks from drivers here. But yeah I think we should only add WARNING checks if this is actually something people have gotten wrong, otherwise there's just too many of them, distracting from the code. -Daniel -- 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
Re: [Intel-gfx] [PATCH] drm/shmem-helper: Only dma-buf imports are private obj
On Tue, Jun 16, 2020 at 02:06:24PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 16.06.20 um 13:47 schrieb Daniel Vetter:
> > I broke that in my refactoring:
> >
> > commit 7d2cd72a9aa3df3604cafd169a2d4a525afb68ca
> > Author: Daniel Vetter
> > Date: Fri May 29 16:05:42 2020 +0200
> >
> > drm/shmem-helpers: Simplify dma-buf importing
> >
> > I'm not entirely sure of the history here, but I suspect that in one
> > of the rebases or when applying the patch I moved the hunk from
> > drm_gem_shmem_prime_import_sg_table(), where it should be, to
> > drm_gem_shmem_create_with_handle(), which is totally wrong.
> >
> > Remedy this.
> >
> > Thanks for Thomas for the crucual hint in debugging this.
> >
> > Reported-by: Thomas Zimmermann
> > Fixes: 7d2cd72a9aa3 ("drm/shmem-helpers: Simplify dma-buf importing")
> > Cc: Boris Brezillon
> > Cc: Thomas Zimmermann
> > Cc: Gerd Hoffmann
> > Cc: Rob Herring
> > Cc: Noralf Trønnes
> > Signed-off-by: Daniel Vetter
>
> Tested-by: Thomas Zimmermann
> Reviewed-by: Thomas Zimmermann
Now also merged, thanks a lot for your help.
-Daniel
>
> > ---
> > drivers/gpu/drm/drm_gem_shmem_helper.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > index 0a7e3b664bc2..837e0840990c 100644
> > --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > @@ -377,7 +377,7 @@ drm_gem_shmem_create_with_handle(struct drm_file
> > *file_priv,
> > struct drm_gem_shmem_object *shmem;
> > int ret;
> >
> > - shmem = __drm_gem_shmem_create(dev, size, true);
> > + shmem = drm_gem_shmem_create(dev, size);
> > if (IS_ERR(shmem))
> > return shmem;
> >
> > @@ -730,7 +730,7 @@ drm_gem_shmem_prime_import_sg_table(struct drm_device
> > *dev,
> > size_t size = PAGE_ALIGN(attach->dmabuf->size);
> > struct drm_gem_shmem_object *shmem;
> >
> > - shmem = drm_gem_shmem_create(dev, size);
> > + shmem = __drm_gem_shmem_create(dev, size, true);
> > if (IS_ERR(shmem))
> > return ERR_CAST(shmem);
> >
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
--
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
Re: [Intel-gfx] [PATCH] drm/shmem-helper: Fix obj->filp derefence
On Tue, Jun 16, 2020 at 02:10:10PM +0200, Thomas Zimmermann wrote:
> Hi,
>
> as discussed on IRC, we still need this patch.
>
> Am 15.06.20 um 17:10 schrieb Daniel Vetter:
> > I broke that in my refactoring:
> >
> > commit 7d2cd72a9aa3df3604cafd169a2d4a525afb68ca
> > Author: Daniel Vetter
> > Date: Fri May 29 16:05:42 2020 +0200
> >
> > drm/shmem-helpers: Simplify dma-buf importing
> >
> > Reported-by: Thomas Zimmermann
> > Fixes: 7d2cd72a9aa3 ("drm/shmem-helpers: Simplify dma-buf importing")
> > Cc: Boris Brezillon
> > Cc: Thomas Zimmermann
> > Cc: Gerd Hoffmann
> > Cc: Rob Herring
> > Cc: Noralf Trønnes
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_gem_shmem_helper.c | 20 +++-
> > 1 file changed, 11 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > index 0a7e3b664bc2..3e7ee407a17c 100644
> > --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > @@ -70,15 +70,17 @@ __drm_gem_shmem_create(struct drm_device *dev, size_t
> > size, bool private)
> > mutex_init(&shmem->vmap_lock);
> > INIT_LIST_HEAD(&shmem->madv_list);
> >
> > - /*
> > -* Our buffers are kept pinned, so allocating them
> > -* from the MOVABLE zone is a really bad idea, and
> > -* conflicts with CMA. See comments above new_inode()
> > -* why this is required _and_ expected if you're
> > -* going to pin these pages.
> > -*/
> > - mapping_set_gfp_mask(obj->filp->f_mapping, GFP_HIGHUSER |
> > -__GFP_RETRY_MAYFAIL | __GFP_NOWARN);
> > + if (!private) {
>
> I would test for (obj->filp) here, because it's what the branch depends
> on. Your choice. In any case
I was pondering this too, on one hand it's the thing we're using, otoh
it's a direct consequence of the private flag, and the private flag has a
bit the clearer control flow I think - the obj->filp is clear that it's a
NULL check, but it's a lot less clear _why_ it is ok to have obj->filp ==
NULL. Checking for private makes this a bit clearer imo.
But yeah I considered both options. Maybe we should improve the comment in
a follow-up patch? I want to land the bugfix meanwhile, to close the
regression.
> Tested-by: Thomas Zimmermann
> Reviewed-by: Thomas Zimmermann
Thanks for testing and reviewing!
-Daniel
>
>
> > + /*
> > +* Our buffers are kept pinned, so allocating them
> > +* from the MOVABLE zone is a really bad idea, and
> > +* conflicts with CMA. See comments above new_inode()
> > +* why this is required _and_ expected if you're
> > +* going to pin these pages.
> > +*/
> > + mapping_set_gfp_mask(obj->filp->f_mapping, GFP_HIGHUSER |
> > +__GFP_RETRY_MAYFAIL | __GFP_NOWARN);
> > + }
> >
> > return shmem;
> >
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
--
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.CHECKPATCH: warning for drm/i915: fix a couple of spelling mistakes in kernel parameter help text
== Series Details == Series: drm/i915: fix a couple of spelling mistakes in kernel parameter help text URL : https://patchwork.freedesktop.org/series/78407/ State : warning == Summary == $ dim checkpatch origin/drm-tip b463d0076902 drm/i915: fix a couple of spelling mistakes in kernel parameter help text -:8: WARNING:TYPO_SPELLING: 'helpfull' may be misspelled - perhaps 'helpful'? #8: namely "helpfull" and "paramters". Fix them. -:8: WARNING:TYPO_SPELLING: 'paramters' may be misspelled - perhaps 'parameters'? #8: namely "helpfull" and "paramters". Fix them. total: 0 errors, 2 warnings, 0 checks, 10 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Apply Wa_14011264657:gen11+
On Tue, Jun 16, 2020 at 10:01:40AM -0700, Matt Atwood wrote:
> On Tue, Jun 16, 2020 at 07:39:09PM +0300, Ville Syrjälä wrote:
> > On Tue, Jun 16, 2020 at 09:34:06AM -0700, Matt Atwood wrote:
> > > Add minimum width to planes, variable with specific formats, for gen11+.
> >
> > How did this suddenly become gen11+? Wasn't it rkl only before?
> gen11 platforms were currently in pending, that has changed.
What does "in pending" mean?
> >
> > >
> > > Signed-off-by: Matt Atwood
> > > ---
> > > drivers/gpu/drm/i915/display/intel_display.c | 55 +---
> > > 1 file changed, 47 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 7457813ef273..d4fdad6cb3b1 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -3760,6 +3760,45 @@ static int glk_max_plane_width(const struct
> > > drm_framebuffer *fb,
> > > }
> > > }
> > >
> > > +static int icl_min_plane_width(struct drm_i915_private *dev_priv,
> > > + const struct drm_framebuffer *fb)
> > > +{
> > > + /* Wa_14011264657, Wa_14011050563 */
> > > + switch (fb->format->format) {
> > > + case DRM_FORMAT_C8:
> > > + return 18;
> > > + case DRM_FORMAT_RGB565:
> > > + return 10;
> > > + case DRM_FORMAT_XRGB:
> > > + case DRM_FORMAT_XBGR:
> > > + case DRM_FORMAT_ARGB:
> > > + case DRM_FORMAT_ABGR:
> > > + case DRM_FORMAT_XRGB2101010:
> > > + case DRM_FORMAT_XBGR2101010:
> > > + case DRM_FORMAT_ARGB2101010:
> > > + case DRM_FORMAT_ABGR2101010:
> > > + case DRM_FORMAT_XVYU2101010:
> > > + case DRM_FORMAT_Y212:
> > > + case DRM_FORMAT_Y216:
> > > + return 6;
> > > + case DRM_FORMAT_NV12:
> > > + return 20;
> > > + case DRM_FORMAT_P010:
> > > + case DRM_FORMAT_P012:
> > > + case DRM_FORMAT_P016:
> > > + return 12;
> > > + case DRM_FORMAT_XRGB16161616F:
> > > + case DRM_FORMAT_XBGR16161616F:
> > > + case DRM_FORMAT_ARGB16161616F:
> > > + case DRM_FORMAT_ABGR16161616F:
> > > + case DRM_FORMAT_XVYU12_16161616:
> > > + case DRM_FORMAT_XVYU16161616:
> > > + return 4;
> > > + default:
> > > + return 1;
> > > + }
> > > +}
> > > +
> > > static int icl_max_plane_width(const struct drm_framebuffer *fb,
> > > int color_plane,
> > > unsigned int rotation)
> > > @@ -3831,15 +3870,15 @@ static int skl_check_main_surface(struct
> > > intel_plane_state *plane_state)
> > > int y = plane_state->uapi.src.y1 >> 16;
> > > int w = drm_rect_width(&plane_state->uapi.src) >> 16;
> > > int h = drm_rect_height(&plane_state->uapi.src) >> 16;
> > > - int max_width;
> > > - int max_height;
> > > - u32 alignment;
> > > - u32 offset;
> > > + int max_width, min_width = 1, max_height;
> > > + u32 alignment, offset;
> > > int aux_plane = intel_main_to_aux_plane(fb, 0);
> > > u32 aux_offset = plane_state->color_plane[aux_plane].offset;
> > >
> > > - if (INTEL_GEN(dev_priv) >= 11)
> > > + if (INTEL_GEN(dev_priv) >= 11) {
> > > max_width = icl_max_plane_width(fb, 0, rotation);
> > > + min_width = icl_min_plane_width(dev_priv, fb);
> > > + }
> > > else if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > > max_width = glk_max_plane_width(fb, 0, rotation);
> > > else
> > > @@ -3850,10 +3889,10 @@ static int skl_check_main_surface(struct
> > > intel_plane_state *plane_state)
> > > else
> > > max_height = skl_max_plane_height();
> > >
> > > - if (w > max_width || h > max_height) {
> > > + if (w > max_width || w < min_width || h > max_height) {
> > > drm_dbg_kms(&dev_priv->drm,
> > > - "requested Y/RGB source size %dx%d too big (limit
> > > %dx%d)\n",
> > > - w, h, max_width, max_height);
> > > + "requested Y/RGB source size %dx%d outside limits
> > > (min: %dx1 max: %dx%d)\n",
> > > + w, h, min_width, max_width, max_height);
> > > return -EINVAL;
> > > }
> > >
> > > --
> > > 2.21.3
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> > --
> > Ville Syrjälä
> > Intel
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Apply Wa_14011264657:gen11+
On Tue, Jun 16, 2020 at 07:39:09PM +0300, Ville Syrjälä wrote:
> On Tue, Jun 16, 2020 at 09:34:06AM -0700, Matt Atwood wrote:
> > Add minimum width to planes, variable with specific formats, for gen11+.
>
> How did this suddenly become gen11+? Wasn't it rkl only before?
gen11 platforms were currently in pending, that has changed.
>
> >
> > Signed-off-by: Matt Atwood
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 55 +---
> > 1 file changed, 47 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 7457813ef273..d4fdad6cb3b1 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -3760,6 +3760,45 @@ static int glk_max_plane_width(const struct
> > drm_framebuffer *fb,
> > }
> > }
> >
> > +static int icl_min_plane_width(struct drm_i915_private *dev_priv,
> > +const struct drm_framebuffer *fb)
> > +{
> > + /* Wa_14011264657, Wa_14011050563 */
> > + switch (fb->format->format) {
> > + case DRM_FORMAT_C8:
> > + return 18;
> > + case DRM_FORMAT_RGB565:
> > + return 10;
> > + case DRM_FORMAT_XRGB:
> > + case DRM_FORMAT_XBGR:
> > + case DRM_FORMAT_ARGB:
> > + case DRM_FORMAT_ABGR:
> > + case DRM_FORMAT_XRGB2101010:
> > + case DRM_FORMAT_XBGR2101010:
> > + case DRM_FORMAT_ARGB2101010:
> > + case DRM_FORMAT_ABGR2101010:
> > + case DRM_FORMAT_XVYU2101010:
> > + case DRM_FORMAT_Y212:
> > + case DRM_FORMAT_Y216:
> > + return 6;
> > + case DRM_FORMAT_NV12:
> > + return 20;
> > + case DRM_FORMAT_P010:
> > + case DRM_FORMAT_P012:
> > + case DRM_FORMAT_P016:
> > + return 12;
> > + case DRM_FORMAT_XRGB16161616F:
> > + case DRM_FORMAT_XBGR16161616F:
> > + case DRM_FORMAT_ARGB16161616F:
> > + case DRM_FORMAT_ABGR16161616F:
> > + case DRM_FORMAT_XVYU12_16161616:
> > + case DRM_FORMAT_XVYU16161616:
> > + return 4;
> > + default:
> > + return 1;
> > + }
> > +}
> > +
> > static int icl_max_plane_width(const struct drm_framebuffer *fb,
> >int color_plane,
> >unsigned int rotation)
> > @@ -3831,15 +3870,15 @@ static int skl_check_main_surface(struct
> > intel_plane_state *plane_state)
> > int y = plane_state->uapi.src.y1 >> 16;
> > int w = drm_rect_width(&plane_state->uapi.src) >> 16;
> > int h = drm_rect_height(&plane_state->uapi.src) >> 16;
> > - int max_width;
> > - int max_height;
> > - u32 alignment;
> > - u32 offset;
> > + int max_width, min_width = 1, max_height;
> > + u32 alignment, offset;
> > int aux_plane = intel_main_to_aux_plane(fb, 0);
> > u32 aux_offset = plane_state->color_plane[aux_plane].offset;
> >
> > - if (INTEL_GEN(dev_priv) >= 11)
> > + if (INTEL_GEN(dev_priv) >= 11) {
> > max_width = icl_max_plane_width(fb, 0, rotation);
> > + min_width = icl_min_plane_width(dev_priv, fb);
> > + }
> > else if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > max_width = glk_max_plane_width(fb, 0, rotation);
> > else
> > @@ -3850,10 +3889,10 @@ static int skl_check_main_surface(struct
> > intel_plane_state *plane_state)
> > else
> > max_height = skl_max_plane_height();
> >
> > - if (w > max_width || h > max_height) {
> > + if (w > max_width || w < min_width || h > max_height) {
> > drm_dbg_kms(&dev_priv->drm,
> > - "requested Y/RGB source size %dx%d too big (limit
> > %dx%d)\n",
> > - w, h, max_width, max_height);
> > + "requested Y/RGB source size %dx%d outside limits
> > (min: %dx1 max: %dx%d)\n",
> > + w, h, min_width, max_width, max_height);
> > return -EINVAL;
> > }
> >
> > --
> > 2.21.3
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915/tgl+: Use the correct DP_TP_* register instances in MST encoders
On Tue, 2020-06-16 at 19:42 +0300, Imre Deak wrote:
> On Tue, Jun 16, 2020 at 07:32:46PM +0300, Souza, Jose wrote:
> > On Tue, 2020-06-16 at 17:18 +0300, Imre Deak wrote:
> > > MST encoders must use the master MST transcoder's DP_TP_STATUS and
> > > DP_TP_CONTROL registers. Atm, during the HW readout of a slave
> > > transcoder's CRTC state we reset these register addresses in
> > > intel_dp::regs.dp_tp_* to the slave transcoder's DP_TP_* register
> > > addresses incorrectly; fix this.
> > >
> > > This issue led at least to
> > > 'Timed out waiting for ACT sent when disabling'
> > > errors during output disabling in a multiple MST stream config.
> >
> > Can you point to place where dp_tp_ctl is used and cause this? All
> > the MST code paths uses the dp_tp_ctl of the main intel_dp(the one
> > that is not a mst connector).
>
> During a slave stream disabling when waiting for the ACT sent flag for
> that stream.
>
> > > This change replaces
> > > https://patchwork.freedesktop.org/patch/369577/?series=78193&rev=1
> > > which just papered over the problem.
> > >
> > > Cc: Ville Syrjälä
> > > Cc: José Roberto de Souza
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/gpu/drm/i915/display/intel_ddi.c | 15 ++-
> > > 1 file changed, 10 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > index ca7bb2294d2b..73d6cc29291a 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > @@ -4193,11 +4193,6 @@ void intel_ddi_get_config(struct intel_encoder
> > > *encoder,
> > > if (drm_WARN_ON(&dev_priv->drm, transcoder_is_dsi(cpu_transcoder)))
> > > return;
> > >
> > > - if (INTEL_GEN(dev_priv) >= 12) {
> > > - intel_dp->regs.dp_tp_ctl = TGL_DP_TP_CTL(cpu_transcoder);
> > > - intel_dp->regs.dp_tp_status = TGL_DP_TP_STATUS(cpu_transcoder);
> > > - }
> > > -
> > > intel_dsc_get_config(encoder, pipe_config);
> > >
> > > temp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
> > > @@ -4299,6 +4294,16 @@ void intel_ddi_get_config(struct intel_encoder
> > > *encoder,
> > > break;
> > > }
> > >
> > > + if (INTEL_GEN(dev_priv) >= 12) {
> > > + enum transcoder transcoder =
> > > + intel_dp_mst_is_slave_trans(pipe_config) ?
> > > + pipe_config->mst_master_transcoder :
> > > + pipe_config->cpu_transcoder;
> > > +
> > > + intel_dp->regs.dp_tp_ctl = TGL_DP_TP_CTL(transcoder);
> > > + intel_dp->regs.dp_tp_status = TGL_DP_TP_STATUS(transcoder);
> > > + }
> >
> > Also not sure how change only in the config readout would fix the issue,
>
> After a modeset we'll verify the HW state. The readout for a slave
> stream CRTC (get_pipe_config) running after the master CRTC's readout
> will overwrite the dp_tp reg addresses. The other instance of dp_tp
> register address init (in tgl_ddi_pre_enable_dp()) is correct.
intel_mst_post_disable_dp()
struct intel_digital_port *intel_dig_port = intel_mst->primary;
struct intel_dp *intel_dp = &intel_dig_port->dp;
...
if (intel_de_wait_for_set(dev_priv, intel_dp->regs.dp_tp_status,
DP_TP_STATUS_ACT_SENT, 1))
drm_err(&dev_priv->drm, "Timed out waiting for ACT sent when
disabling\n");
Until here is right, but yeah bellow is the problem:
static void intel_dp_mst_enc_get_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config)
{
struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
struct intel_digital_port *intel_dig_port = intel_mst->primary;
intel_ddi_get_config(&intel_dig_port->base, pipe_config);
}
It will be overwritten with the transcoder of the last crtc read.Would suggest
to add something about intel_dp_mst_enc_get_config() to the commit
description but the change looks good now.
>
> > IFWI don't enable MST so when i915 takes over a full modeset will
> > happen to enable MST and only dp_tp_ctl of the main intel_dp(the one
> > that is not a mst connector) will be set, check
> > tgl_ddi_pre_enable_dp().
> >
> > > +
> > > pipe_config->has_audio =
> > > intel_ddi_is_audio_enabled(dev_priv, cpu_transcoder);
> > >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915/dp_mst: Ensure the DPCD ACT sent flag is cleared before waiting for it
On Tue, Jun 16, 2020 at 07:40:47PM +0300, Ville Syrjälä wrote:
> On Tue, Jun 16, 2020 at 07:23:21PM +0300, Ville Syrjälä wrote:
> > On Tue, Jun 16, 2020 at 06:54:41PM +0300, Imre Deak wrote:
> > > On Tue, Jun 16, 2020 at 06:45:46PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Jun 16, 2020 at 05:18:55PM +0300, Imre Deak wrote:
> > > > > Atm, we clear the ACT sent flag in the sink's DPCD before updating the
> > > > > sink's payload table, along clearing the payload table updated flag.
> > > > > The sink is supposed to set this flag once it detects that the source
> > > > > has completed the ACT sequence (after detecting the 4 required ACT
> > > > > MTPH
> > > > > symbols sent by the source). As opposed to this 2 DELL monitors I have
> > > > > set the flag already along the payload table updated flag, which is
> > > > > not
> > > > > quite correct.
> > > > >
> > > > > To be sure that the sink has detected the ACT MTPH symbols before
> > > > > continuing enabling the encoder, clear the ACT sent flag before
> > > > > enabling
> > > > > or disabling the transcoder VC payload allocation (which is what
> > > > > starts
> > > > > the ACT sequence).
> > > > >
> > > > > Cc: Lyude Paul
> > > > > Cc: Ville Syrjälä
> > > > > Cc: dri-de...@lists.freedesktop.org
> > > > > Signed-off-by: Imre Deak
> > > > > ---
> > > > > drivers/gpu/drm/drm_dp_mst_topology.c | 31
> > > > > +++--
> > > > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 ++
> > > > > include/drm/drm_dp_mst_helper.h | 2 ++
> > > > > 3 files changed, 33 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > index b2f5a84b4cfb..e3bf8c9c8267 100644
> > > > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > @@ -4377,6 +4377,34 @@ void drm_dp_mst_deallocate_vcpi(struct
> > > > > drm_dp_mst_topology_mgr *mgr,
> > > > > }
> > > > > EXPORT_SYMBOL(drm_dp_mst_deallocate_vcpi);
> > > > >
> > > > > +/**
> > > > > + * drm_dp_clear_payload_status() - Clears the payload table status
> > > > > flags
> > > > > + * @mgr: manager to use
> > > > > + *
> > > > > + * Clears the payload table ACT handled and table updated flags in
> > > > > the MST hub's
> > > > > + * DPCD. This function must be called before updating the payload
> > > > > table or
> > > > > + * starting the ACT sequence and waiting for the corresponding flags
> > > > > to get
> > > > > + * set by the hub.
> > > > > + *
> > > > > + * Returns:
> > > > > + * 0 if the flag got cleared successfully, otherwise a negative
> > > > > error code.
> > > > > + */
> > > > > +int drm_dp_clear_payload_status(struct drm_dp_mst_topology_mgr *mgr)
> > > > > +{
> > > > > + int ret;
> > > > > +
> > > > > + ret = drm_dp_dpcd_writeb(mgr->aux,
> > > > > DP_PAYLOAD_TABLE_UPDATE_STATUS,
> > > > > + DP_PAYLOAD_ACT_HANDLED);
> > > > > + if (ret < 0) {
> > > > > + DRM_DEBUG_DRIVER("Can't clear the ACT sent flag
> > > > > (%d)\n", ret);
> > > > > + return ret;
> > > > > + }
> > > > > + WARN_ON(ret != 1);
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +EXPORT_SYMBOL(drm_dp_clear_payload_status);
> > > > > +
> > > > > static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr
> > > > > *mgr,
> > > > >int id, struct drm_dp_payload
> > > > > *payload)
> > > > > {
> > > > > @@ -4384,8 +4412,7 @@ static int drm_dp_dpcd_write_payload(struct
> > > > > drm_dp_mst_topology_mgr *mgr,
> > > > > int ret;
> > > > > int retries = 0;
> > > > >
> > > > > - drm_dp_dpcd_writeb(mgr->aux, DP_PAYLOAD_TABLE_UPDATE_STATUS,
> > > > > -DP_PAYLOAD_TABLE_UPDATED);
> > > >
> > > > We used to clear DP_PAYLOAD_TABLE_UPDATED but now we clear
> > > > DP_PAYLOAD_ACT_HANDLED ?
> > >
> > > Eek. We should write DP_PAYLOAD_TABLE_UPDATED which is the only way to
> > > clear both the act-handled and the table-updated flags.
> >
> > Huh. That's a bit crazy. But it is what the spec says.
>
> In fact, I'd suggest adding a comment explaining this crazyness
> so that the next person doesn't have to wonder why we're never
> clearing the ACT bit.
Ok.
>
> >
> > > I tested things
> > > that way but managed to send an old version. Thanks for catching it.
> > >
> > > >
> > > > > + drm_dp_clear_payload_status(mgr);
> > > > >
> > > > > payload_alloc[0] = id;
> > > > > payload_alloc[1] = payload->start_slot;
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > > index 9308b5920780..3c4b0fb10d8b 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > > @@ -323,6 +323,8 @@ static void clear_act_sent(struct intel_dp
Re: [Intel-gfx] [PATCH 1/6] drm/i915/tgl+: Use the correct DP_TP_* register instances in MST encoders
On Tue, Jun 16, 2020 at 07:32:46PM +0300, Souza, Jose wrote:
> On Tue, 2020-06-16 at 17:18 +0300, Imre Deak wrote:
> > MST encoders must use the master MST transcoder's DP_TP_STATUS and
> > DP_TP_CONTROL registers. Atm, during the HW readout of a slave
> > transcoder's CRTC state we reset these register addresses in
> > intel_dp::regs.dp_tp_* to the slave transcoder's DP_TP_* register
> > addresses incorrectly; fix this.
> >
> > This issue led at least to
> > 'Timed out waiting for ACT sent when disabling'
> > errors during output disabling in a multiple MST stream config.
>
> Can you point to place where dp_tp_ctl is used and cause this? All
> the MST code paths uses the dp_tp_ctl of the main intel_dp(the one
> that is not a mst connector).
During a slave stream disabling when waiting for the ACT sent flag for
that stream.
>
> >
> > This change replaces
> > https://patchwork.freedesktop.org/patch/369577/?series=78193&rev=1
> > which just papered over the problem.
> >
> > Cc: Ville Syrjälä
> > Cc: José Roberto de Souza
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 15 ++-
> > 1 file changed, 10 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index ca7bb2294d2b..73d6cc29291a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -4193,11 +4193,6 @@ void intel_ddi_get_config(struct intel_encoder
> > *encoder,
> > if (drm_WARN_ON(&dev_priv->drm, transcoder_is_dsi(cpu_transcoder)))
> > return;
> >
> > - if (INTEL_GEN(dev_priv) >= 12) {
> > - intel_dp->regs.dp_tp_ctl = TGL_DP_TP_CTL(cpu_transcoder);
> > - intel_dp->regs.dp_tp_status = TGL_DP_TP_STATUS(cpu_transcoder);
> > - }
> > -
> > intel_dsc_get_config(encoder, pipe_config);
> >
> > temp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
> > @@ -4299,6 +4294,16 @@ void intel_ddi_get_config(struct intel_encoder
> > *encoder,
> > break;
> > }
> >
> > + if (INTEL_GEN(dev_priv) >= 12) {
> > + enum transcoder transcoder =
> > + intel_dp_mst_is_slave_trans(pipe_config) ?
> > + pipe_config->mst_master_transcoder :
> > + pipe_config->cpu_transcoder;
> > +
> > + intel_dp->regs.dp_tp_ctl = TGL_DP_TP_CTL(transcoder);
> > + intel_dp->regs.dp_tp_status = TGL_DP_TP_STATUS(transcoder);
> > + }
>
> Also not sure how change only in the config readout would fix the issue,
After a modeset we'll verify the HW state. The readout for a slave
stream CRTC (get_pipe_config) running after the master CRTC's readout
will overwrite the dp_tp reg addresses. The other instance of dp_tp
register address init (in tgl_ddi_pre_enable_dp()) is correct.
> IFWI don't enable MST so when i915 takes over a full modeset will
> happen to enable MST and only dp_tp_ctl of the main intel_dp(the one
> that is not a mst connector) will be set, check
> tgl_ddi_pre_enable_dp().
>
> > +
> > pipe_config->has_audio =
> > intel_ddi_is_audio_enabled(dev_priv, cpu_transcoder);
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915/dp_mst: Ensure the DPCD ACT sent flag is cleared before waiting for it
On Tue, Jun 16, 2020 at 07:23:21PM +0300, Ville Syrjälä wrote:
> On Tue, Jun 16, 2020 at 06:54:41PM +0300, Imre Deak wrote:
> > On Tue, Jun 16, 2020 at 06:45:46PM +0300, Ville Syrjälä wrote:
> > > On Tue, Jun 16, 2020 at 05:18:55PM +0300, Imre Deak wrote:
> > > > Atm, we clear the ACT sent flag in the sink's DPCD before updating the
> > > > sink's payload table, along clearing the payload table updated flag.
> > > > The sink is supposed to set this flag once it detects that the source
> > > > has completed the ACT sequence (after detecting the 4 required ACT MTPH
> > > > symbols sent by the source). As opposed to this 2 DELL monitors I have
> > > > set the flag already along the payload table updated flag, which is not
> > > > quite correct.
> > > >
> > > > To be sure that the sink has detected the ACT MTPH symbols before
> > > > continuing enabling the encoder, clear the ACT sent flag before enabling
> > > > or disabling the transcoder VC payload allocation (which is what starts
> > > > the ACT sequence).
> > > >
> > > > Cc: Lyude Paul
> > > > Cc: Ville Syrjälä
> > > > Cc: dri-de...@lists.freedesktop.org
> > > > Signed-off-by: Imre Deak
> > > > ---
> > > > drivers/gpu/drm/drm_dp_mst_topology.c | 31 +++--
> > > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 ++
> > > > include/drm/drm_dp_mst_helper.h | 2 ++
> > > > 3 files changed, 33 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > index b2f5a84b4cfb..e3bf8c9c8267 100644
> > > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > @@ -4377,6 +4377,34 @@ void drm_dp_mst_deallocate_vcpi(struct
> > > > drm_dp_mst_topology_mgr *mgr,
> > > > }
> > > > EXPORT_SYMBOL(drm_dp_mst_deallocate_vcpi);
> > > >
> > > > +/**
> > > > + * drm_dp_clear_payload_status() - Clears the payload table status
> > > > flags
> > > > + * @mgr: manager to use
> > > > + *
> > > > + * Clears the payload table ACT handled and table updated flags in the
> > > > MST hub's
> > > > + * DPCD. This function must be called before updating the payload
> > > > table or
> > > > + * starting the ACT sequence and waiting for the corresponding flags
> > > > to get
> > > > + * set by the hub.
> > > > + *
> > > > + * Returns:
> > > > + * 0 if the flag got cleared successfully, otherwise a negative error
> > > > code.
> > > > + */
> > > > +int drm_dp_clear_payload_status(struct drm_dp_mst_topology_mgr *mgr)
> > > > +{
> > > > + int ret;
> > > > +
> > > > + ret = drm_dp_dpcd_writeb(mgr->aux,
> > > > DP_PAYLOAD_TABLE_UPDATE_STATUS,
> > > > +DP_PAYLOAD_ACT_HANDLED);
> > > > + if (ret < 0) {
> > > > + DRM_DEBUG_DRIVER("Can't clear the ACT sent flag
> > > > (%d)\n", ret);
> > > > + return ret;
> > > > + }
> > > > + WARN_ON(ret != 1);
> > > > +
> > > > + return 0;
> > > > +}
> > > > +EXPORT_SYMBOL(drm_dp_clear_payload_status);
> > > > +
> > > > static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr
> > > > *mgr,
> > > > int id, struct drm_dp_payload
> > > > *payload)
> > > > {
> > > > @@ -4384,8 +4412,7 @@ static int drm_dp_dpcd_write_payload(struct
> > > > drm_dp_mst_topology_mgr *mgr,
> > > > int ret;
> > > > int retries = 0;
> > > >
> > > > - drm_dp_dpcd_writeb(mgr->aux, DP_PAYLOAD_TABLE_UPDATE_STATUS,
> > > > - DP_PAYLOAD_TABLE_UPDATED);
> > >
> > > We used to clear DP_PAYLOAD_TABLE_UPDATED but now we clear
> > > DP_PAYLOAD_ACT_HANDLED ?
> >
> > Eek. We should write DP_PAYLOAD_TABLE_UPDATED which is the only way to
> > clear both the act-handled and the table-updated flags.
>
> Huh. That's a bit crazy. But it is what the spec says.
In fact, I'd suggest adding a comment explaining this crazyness
so that the next person doesn't have to wonder why we're never
clearing the ACT bit.
>
> > I tested things
> > that way but managed to send an old version. Thanks for catching it.
> >
> > >
> > > > + drm_dp_clear_payload_status(mgr);
> > > >
> > > > payload_alloc[0] = id;
> > > > payload_alloc[1] = payload->start_slot;
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > index 9308b5920780..3c4b0fb10d8b 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > @@ -323,6 +323,8 @@ static void clear_act_sent(struct intel_dp
> > > > *intel_dp)
> > > >
> > > > intel_de_write(i915, intel_dp->regs.dp_tp_status,
> > > >DP_TP_STATUS_ACT_SENT);
> > > > +
> > > > + drm_dp_clear_payload_status(&intel_dp->mst_mgr);
> > > > }
> > > >
> > > > static void wait_for_act_sent(struct intel_dp *intel_dp)
>
Re: [Intel-gfx] [PATCH] drm/i915: Apply Wa_14011264657:gen11+
On Tue, Jun 16, 2020 at 09:34:06AM -0700, Matt Atwood wrote:
> Add minimum width to planes, variable with specific formats, for gen11+.
How did this suddenly become gen11+? Wasn't it rkl only before?
>
> Signed-off-by: Matt Atwood
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 55 +---
> 1 file changed, 47 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 7457813ef273..d4fdad6cb3b1 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -3760,6 +3760,45 @@ static int glk_max_plane_width(const struct
> drm_framebuffer *fb,
> }
> }
>
> +static int icl_min_plane_width(struct drm_i915_private *dev_priv,
> + const struct drm_framebuffer *fb)
> +{
> + /* Wa_14011264657, Wa_14011050563 */
> + switch (fb->format->format) {
> + case DRM_FORMAT_C8:
> + return 18;
> + case DRM_FORMAT_RGB565:
> + return 10;
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_ABGR:
> + case DRM_FORMAT_XRGB2101010:
> + case DRM_FORMAT_XBGR2101010:
> + case DRM_FORMAT_ARGB2101010:
> + case DRM_FORMAT_ABGR2101010:
> + case DRM_FORMAT_XVYU2101010:
> + case DRM_FORMAT_Y212:
> + case DRM_FORMAT_Y216:
> + return 6;
> + case DRM_FORMAT_NV12:
> + return 20;
> + case DRM_FORMAT_P010:
> + case DRM_FORMAT_P012:
> + case DRM_FORMAT_P016:
> + return 12;
> + case DRM_FORMAT_XRGB16161616F:
> + case DRM_FORMAT_XBGR16161616F:
> + case DRM_FORMAT_ARGB16161616F:
> + case DRM_FORMAT_ABGR16161616F:
> + case DRM_FORMAT_XVYU12_16161616:
> + case DRM_FORMAT_XVYU16161616:
> + return 4;
> + default:
> + return 1;
> + }
> +}
> +
> static int icl_max_plane_width(const struct drm_framebuffer *fb,
> int color_plane,
> unsigned int rotation)
> @@ -3831,15 +3870,15 @@ static int skl_check_main_surface(struct
> intel_plane_state *plane_state)
> int y = plane_state->uapi.src.y1 >> 16;
> int w = drm_rect_width(&plane_state->uapi.src) >> 16;
> int h = drm_rect_height(&plane_state->uapi.src) >> 16;
> - int max_width;
> - int max_height;
> - u32 alignment;
> - u32 offset;
> + int max_width, min_width = 1, max_height;
> + u32 alignment, offset;
> int aux_plane = intel_main_to_aux_plane(fb, 0);
> u32 aux_offset = plane_state->color_plane[aux_plane].offset;
>
> - if (INTEL_GEN(dev_priv) >= 11)
> + if (INTEL_GEN(dev_priv) >= 11) {
> max_width = icl_max_plane_width(fb, 0, rotation);
> + min_width = icl_min_plane_width(dev_priv, fb);
> + }
> else if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> max_width = glk_max_plane_width(fb, 0, rotation);
> else
> @@ -3850,10 +3889,10 @@ static int skl_check_main_surface(struct
> intel_plane_state *plane_state)
> else
> max_height = skl_max_plane_height();
>
> - if (w > max_width || h > max_height) {
> + if (w > max_width || w < min_width || h > max_height) {
> drm_dbg_kms(&dev_priv->drm,
> - "requested Y/RGB source size %dx%d too big (limit
> %dx%d)\n",
> - w, h, max_width, max_height);
> + "requested Y/RGB source size %dx%d outside limits
> (min: %dx1 max: %dx%d)\n",
> + w, h, min_width, max_width, max_height);
> return -EINVAL;
> }
>
> --
> 2.21.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gvt: query if vgpu is active via GETPARAM IOCTL
Hi Shaofeng,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip linus/master v5.8-rc1 next-20200616]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Shaofeng-Tang/drm-i915-gvt-query-if-vgpu-is-active-via-GETPARAM-IOCTL/20200616-162408
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-debian-10.3 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
reproduce (this is a W=1 build):
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>, old ones prefixed by <<):
drivers/gpu/drm/i915/i915_getparam.c: In function 'i915_getparam_ioctl':
>> drivers/gpu/drm/i915/i915_getparam.c:165:11: error: implicit declaration of
>> function 'intel_vgpu_active'; did you mean 'intel_vtd_active'?
>> [-Werror=implicit-function-declaration]
165 | value = intel_vgpu_active(i915);
| ^
| intel_vtd_active
cc1: some warnings being treated as errors
vim +165 drivers/gpu/drm/i915/i915_getparam.c
10
11 int i915_getparam_ioctl(struct drm_device *dev, void *data,
12 struct drm_file *file_priv)
13 {
14 struct drm_i915_private *i915 = to_i915(dev);
15 const struct sseu_dev_info *sseu = &RUNTIME_INFO(i915)->sseu;
16 drm_i915_getparam_t *param = data;
17 int value;
18
19 switch (param->param) {
20 case I915_PARAM_IRQ_ACTIVE:
21 case I915_PARAM_ALLOW_BATCHBUFFER:
22 case I915_PARAM_LAST_DISPATCH:
23 case I915_PARAM_HAS_EXEC_CONSTANTS:
24 /* Reject all old ums/dri params. */
25 return -ENODEV;
26 case I915_PARAM_CHIPSET_ID:
27 value = i915->drm.pdev->device;
28 break;
29 case I915_PARAM_REVISION:
30 value = i915->drm.pdev->revision;
31 break;
32 case I915_PARAM_NUM_FENCES_AVAIL:
33 value = i915->ggtt.num_fences;
34 break;
35 case I915_PARAM_HAS_OVERLAY:
36 value = !!i915->overlay;
37 break;
38 case I915_PARAM_HAS_BSD:
39 value = !!intel_engine_lookup_user(i915,
40
I915_ENGINE_CLASS_VIDEO, 0);
41 break;
42 case I915_PARAM_HAS_BLT:
43 value = !!intel_engine_lookup_user(i915,
44
I915_ENGINE_CLASS_COPY, 0);
45 break;
46 case I915_PARAM_HAS_VEBOX:
47 value = !!intel_engine_lookup_user(i915,
48
I915_ENGINE_CLASS_VIDEO_ENHANCE, 0);
49 break;
50 case I915_PARAM_HAS_BSD2:
51 value = !!intel_engine_lookup_user(i915,
52
I915_ENGINE_CLASS_VIDEO, 1);
53 break;
54 case I915_PARAM_HAS_LLC:
55 value = HAS_LLC(i915);
56 break;
57 case I915_PARAM_HAS_WT:
58 value = HAS_WT(i915);
59 break;
60 case I915_PARAM_HAS_ALIASING_PPGTT:
61 value = INTEL_PPGTT(i915);
62 break;
63 case I915_PARAM_HAS_SEMAPHORES:
64 value = !!(i915->caps.scheduler &
I915_SCHEDULER_CAP_SEMAPHORES);
65 break;
66 case I915_PARAM_HAS_SECURE_BATCHES:
67 value = HAS_SECURE_BATCHES(i915) &&
capable(CAP_SYS_ADMIN);
68 break;
69 case I915_PARAM_CMD_PARSER_VERSION:
70 value = i915_cmd_parser_get_version(i915);
71 break;
72 case I915_PARAM_SUBSLICE_TOTAL:
73 value = intel_sseu_subslice_total(sseu);
74 if (!value)
75 return -ENODEV;
76 break;
77 case I915_PARAM_EU_TOTAL:
78 value = sseu->eu_total;
79 if (!value)
80 return
[Intel-gfx] [PATCH] drm/i915: Apply Wa_14011264657:gen11+
Add minimum width to planes, variable with specific formats, for gen11+.
Signed-off-by: Matt Atwood
---
drivers/gpu/drm/i915/display/intel_display.c | 55 +---
1 file changed, 47 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 7457813ef273..d4fdad6cb3b1 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3760,6 +3760,45 @@ static int glk_max_plane_width(const struct
drm_framebuffer *fb,
}
}
+static int icl_min_plane_width(struct drm_i915_private *dev_priv,
+const struct drm_framebuffer *fb)
+{
+ /* Wa_14011264657, Wa_14011050563 */
+ switch (fb->format->format) {
+ case DRM_FORMAT_C8:
+ return 18;
+ case DRM_FORMAT_RGB565:
+ return 10;
+ case DRM_FORMAT_XRGB:
+ case DRM_FORMAT_XBGR:
+ case DRM_FORMAT_ARGB:
+ case DRM_FORMAT_ABGR:
+ case DRM_FORMAT_XRGB2101010:
+ case DRM_FORMAT_XBGR2101010:
+ case DRM_FORMAT_ARGB2101010:
+ case DRM_FORMAT_ABGR2101010:
+ case DRM_FORMAT_XVYU2101010:
+ case DRM_FORMAT_Y212:
+ case DRM_FORMAT_Y216:
+ return 6;
+ case DRM_FORMAT_NV12:
+ return 20;
+ case DRM_FORMAT_P010:
+ case DRM_FORMAT_P012:
+ case DRM_FORMAT_P016:
+ return 12;
+ case DRM_FORMAT_XRGB16161616F:
+ case DRM_FORMAT_XBGR16161616F:
+ case DRM_FORMAT_ARGB16161616F:
+ case DRM_FORMAT_ABGR16161616F:
+ case DRM_FORMAT_XVYU12_16161616:
+ case DRM_FORMAT_XVYU16161616:
+ return 4;
+ default:
+ return 1;
+ }
+}
+
static int icl_max_plane_width(const struct drm_framebuffer *fb,
int color_plane,
unsigned int rotation)
@@ -3831,15 +3870,15 @@ static int skl_check_main_surface(struct
intel_plane_state *plane_state)
int y = plane_state->uapi.src.y1 >> 16;
int w = drm_rect_width(&plane_state->uapi.src) >> 16;
int h = drm_rect_height(&plane_state->uapi.src) >> 16;
- int max_width;
- int max_height;
- u32 alignment;
- u32 offset;
+ int max_width, min_width = 1, max_height;
+ u32 alignment, offset;
int aux_plane = intel_main_to_aux_plane(fb, 0);
u32 aux_offset = plane_state->color_plane[aux_plane].offset;
- if (INTEL_GEN(dev_priv) >= 11)
+ if (INTEL_GEN(dev_priv) >= 11) {
max_width = icl_max_plane_width(fb, 0, rotation);
+ min_width = icl_min_plane_width(dev_priv, fb);
+ }
else if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
max_width = glk_max_plane_width(fb, 0, rotation);
else
@@ -3850,10 +3889,10 @@ static int skl_check_main_surface(struct
intel_plane_state *plane_state)
else
max_height = skl_max_plane_height();
- if (w > max_width || h > max_height) {
+ if (w > max_width || w < min_width || h > max_height) {
drm_dbg_kms(&dev_priv->drm,
- "requested Y/RGB source size %dx%d too big (limit
%dx%d)\n",
- w, h, max_width, max_height);
+ "requested Y/RGB source size %dx%d outside limits
(min: %dx1 max: %dx%d)\n",
+ w, h, min_width, max_width, max_height);
return -EINVAL;
}
--
2.21.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915/tgl+: Use the correct DP_TP_* register instances in MST encoders
On Tue, 2020-06-16 at 17:18 +0300, Imre Deak wrote:
> MST encoders must use the master MST transcoder's DP_TP_STATUS and
> DP_TP_CONTROL registers. Atm, during the HW readout of a slave
> transcoder's CRTC state we reset these register addresses in
> intel_dp::regs.dp_tp_* to the slave transcoder's DP_TP_* register
> addresses incorrectly; fix this.
>
> This issue led at least to
> 'Timed out waiting for ACT sent when disabling'
> errors during output disabling in a multiple MST stream config.
Can you point to place where dp_tp_ctl is used and cause this?
All the MST code paths uses the dp_tp_ctl of the main intel_dp(the one that is
not a mst connector).
>
> This change replaces
> https://patchwork.freedesktop.org/patch/369577/?series=78193&rev=1
> which just papered over the problem.
>
> Cc: Ville Syrjälä
> Cc: José Roberto de Souza
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index ca7bb2294d2b..73d6cc29291a 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4193,11 +4193,6 @@ void intel_ddi_get_config(struct intel_encoder
> *encoder,
> if (drm_WARN_ON(&dev_priv->drm, transcoder_is_dsi(cpu_transcoder)))
> return;
>
> - if (INTEL_GEN(dev_priv) >= 12) {
> - intel_dp->regs.dp_tp_ctl = TGL_DP_TP_CTL(cpu_transcoder);
> - intel_dp->regs.dp_tp_status = TGL_DP_TP_STATUS(cpu_transcoder);
> - }
> -
> intel_dsc_get_config(encoder, pipe_config);
>
> temp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
> @@ -4299,6 +4294,16 @@ void intel_ddi_get_config(struct intel_encoder
> *encoder,
> break;
> }
>
> + if (INTEL_GEN(dev_priv) >= 12) {
> + enum transcoder transcoder =
> + intel_dp_mst_is_slave_trans(pipe_config) ?
> + pipe_config->mst_master_transcoder :
> + pipe_config->cpu_transcoder;
> +
> + intel_dp->regs.dp_tp_ctl = TGL_DP_TP_CTL(transcoder);
> + intel_dp->regs.dp_tp_status = TGL_DP_TP_STATUS(transcoder);
> + }
Also not sure how change only in the config readout would fix the issue, IFWI
don't enable MST so when i915 takes over a full modeset will happen to
enable MST and only dp_tp_ctl of the main intel_dp(the one that is not a mst
connector) will be set, check tgl_ddi_pre_enable_dp().
> +
> pipe_config->has_audio =
> intel_ddi_is_audio_enabled(dev_priv, cpu_transcoder);
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915/dp_mst: Ensure the DPCD ACT sent flag is cleared before waiting for it
On Tue, Jun 16, 2020 at 06:54:41PM +0300, Imre Deak wrote:
> On Tue, Jun 16, 2020 at 06:45:46PM +0300, Ville Syrjälä wrote:
> > On Tue, Jun 16, 2020 at 05:18:55PM +0300, Imre Deak wrote:
> > > Atm, we clear the ACT sent flag in the sink's DPCD before updating the
> > > sink's payload table, along clearing the payload table updated flag.
> > > The sink is supposed to set this flag once it detects that the source
> > > has completed the ACT sequence (after detecting the 4 required ACT MTPH
> > > symbols sent by the source). As opposed to this 2 DELL monitors I have
> > > set the flag already along the payload table updated flag, which is not
> > > quite correct.
> > >
> > > To be sure that the sink has detected the ACT MTPH symbols before
> > > continuing enabling the encoder, clear the ACT sent flag before enabling
> > > or disabling the transcoder VC payload allocation (which is what starts
> > > the ACT sequence).
> > >
> > > Cc: Lyude Paul
> > > Cc: Ville Syrjälä
> > > Cc: dri-de...@lists.freedesktop.org
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/gpu/drm/drm_dp_mst_topology.c | 31 +++--
> > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 ++
> > > include/drm/drm_dp_mst_helper.h | 2 ++
> > > 3 files changed, 33 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > index b2f5a84b4cfb..e3bf8c9c8267 100644
> > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > @@ -4377,6 +4377,34 @@ void drm_dp_mst_deallocate_vcpi(struct
> > > drm_dp_mst_topology_mgr *mgr,
> > > }
> > > EXPORT_SYMBOL(drm_dp_mst_deallocate_vcpi);
> > >
> > > +/**
> > > + * drm_dp_clear_payload_status() - Clears the payload table status flags
> > > + * @mgr: manager to use
> > > + *
> > > + * Clears the payload table ACT handled and table updated flags in the
> > > MST hub's
> > > + * DPCD. This function must be called before updating the payload table
> > > or
> > > + * starting the ACT sequence and waiting for the corresponding flags to
> > > get
> > > + * set by the hub.
> > > + *
> > > + * Returns:
> > > + * 0 if the flag got cleared successfully, otherwise a negative error
> > > code.
> > > + */
> > > +int drm_dp_clear_payload_status(struct drm_dp_mst_topology_mgr *mgr)
> > > +{
> > > + int ret;
> > > +
> > > + ret = drm_dp_dpcd_writeb(mgr->aux, DP_PAYLOAD_TABLE_UPDATE_STATUS,
> > > + DP_PAYLOAD_ACT_HANDLED);
> > > + if (ret < 0) {
> > > + DRM_DEBUG_DRIVER("Can't clear the ACT sent flag (%d)\n", ret);
> > > + return ret;
> > > + }
> > > + WARN_ON(ret != 1);
> > > +
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL(drm_dp_clear_payload_status);
> > > +
> > > static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr,
> > >int id, struct drm_dp_payload *payload)
> > > {
> > > @@ -4384,8 +4412,7 @@ static int drm_dp_dpcd_write_payload(struct
> > > drm_dp_mst_topology_mgr *mgr,
> > > int ret;
> > > int retries = 0;
> > >
> > > - drm_dp_dpcd_writeb(mgr->aux, DP_PAYLOAD_TABLE_UPDATE_STATUS,
> > > -DP_PAYLOAD_TABLE_UPDATED);
> >
> > We used to clear DP_PAYLOAD_TABLE_UPDATED but now we clear
> > DP_PAYLOAD_ACT_HANDLED ?
>
> Eek. We should write DP_PAYLOAD_TABLE_UPDATED which is the only way to
> clear both the act-handled and the table-updated flags.
Huh. That's a bit crazy. But it is what the spec says.
> I tested things
> that way but managed to send an old version. Thanks for catching it.
>
> >
> > > + drm_dp_clear_payload_status(mgr);
> > >
> > > payload_alloc[0] = id;
> > > payload_alloc[1] = payload->start_slot;
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > index 9308b5920780..3c4b0fb10d8b 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > @@ -323,6 +323,8 @@ static void clear_act_sent(struct intel_dp *intel_dp)
> > >
> > > intel_de_write(i915, intel_dp->regs.dp_tp_status,
> > > DP_TP_STATUS_ACT_SENT);
> > > +
> > > + drm_dp_clear_payload_status(&intel_dp->mst_mgr);
> > > }
> > >
> > > static void wait_for_act_sent(struct intel_dp *intel_dp)
> > > diff --git a/include/drm/drm_dp_mst_helper.h
> > > b/include/drm/drm_dp_mst_helper.h
> > > index 8b9eb4db3381..2facb87624bf 100644
> > > --- a/include/drm/drm_dp_mst_helper.h
> > > +++ b/include/drm/drm_dp_mst_helper.h
> > > @@ -763,6 +763,8 @@ int drm_dp_find_vcpi_slots(struct
> > > drm_dp_mst_topology_mgr *mgr,
> > > int pbn);
> > >
> > >
> > > +int drm_dp_clear_payload_status(struct drm_dp_mst_topology_mgr *mgr);
> > > +
> > > int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr);
> > >
> > >
> > > --
> > > 2.23.1
> >
> > --
> > Ville Syrjälä
Re: [Intel-gfx] [PATCH 2/6] drm/i915/dp_mst: Disable link training fallback on MST links
On Tue, Jun 16, 2020 at 06:49:20PM +0300, Imre Deak wrote:
> On Tue, Jun 16, 2020 at 06:39:30PM +0300, Ville Syrjälä wrote:
> > On Tue, Jun 16, 2020 at 06:30:55PM +0300, Imre Deak wrote:
> > > On Tue, Jun 16, 2020 at 06:22:51PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Jun 16, 2020 at 05:18:51PM +0300, Imre Deak wrote:
> > > > > We calculate the MST available bandwidth using the link's maximum rate
> > > > > and lane count. This bandwidth won't be recalculated in response to a
> > > >
> > > > Thw wording here is a bit ambiguousr as to who "we" is, and what exactly
> > > > "link's maximum rate and lane count". I would try to clarify a bit that
> > > > it's drm_dp_mst_topology.c who is mostly in error here by directly
> > > > interpreting the max data rate/lanes from the DPCD.
> > > >
> > > > Althoguh the i915 code is not wihtout faults, as it lacks any logic
> > > > to modeset all the MST streams for this link when the link params
> > > > change (except on tgl+ where the master/slave stuff should force
> > > > all streams to do a modeset anyway).
> > > >
> > > > > link training error and fallback setting, so modesets following a link
> > > > > training error will calculate incorrect timing parameters (like the
> > > > > transcoder's data M/N params or the number of MST TUs).
> > > > >
> > > > > Prevent the above problem by disabling the link training fallback on
> > > > > MST
> > > > > links for now, until the MST compute config can deal with changing
> > > > > link
> > > > > parameters.
> > > > >
> > > > > The misconfigured timing lead at least to a
> > > > > 'Timed out waiting for DP idle patterns'
> > > > > error.
> > > > >
> > > > > Cc: Ville Syrjälä
> > > > > Cc: Manasi Navare
> > > > > Signed-off-by: Imre Deak
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_dp.c | 25
> > > > > ++---
> > > > > 1 file changed, 18 insertions(+), 7 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > index 42589cae766d..c585b002783a 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > @@ -468,6 +468,13 @@ int
> > > > > intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> > > > > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > > int index;
> > > > >
> > > > > + /*
> > > > > + * TODO: Enable fallback on MST links once MST link compute can
> > > > > handle
> > > > > + * the fallback params.
> > > > > + */
> > > > > + if (intel_dp->is_mst)
> > > > > + return -1;
> > > >
> > > > Should we duplicate the drm_error() from the other path here maybe?
> > >
> > > Yes, will add it.
> > >
> > > >
> > > > > +
> > > > > index = intel_dp_rate_index(intel_dp->common_rates,
> > > > > intel_dp->num_common_rates,
> > > > > link_rate);
> > > > > @@ -6163,7 +6170,17 @@ intel_dp_detect(struct drm_connector
> > > > > *connector,
> > > > > goto out;
> > > > > }
> > > > >
> > > > > - if (intel_dp->reset_link_params) {
> > > > > + /* Read DP Sink DSC Cap DPCD regs for DP v1.4 */
> > > > > + if (INTEL_GEN(dev_priv) >= 11)
> > > > > + intel_dp_get_dsc_sink_cap(intel_dp);
> > > > > +
> > > > > + intel_dp_configure_mst(intel_dp);
> > > > > +
> > > > > + /*
> > > > > + * TODO: Reset link params when switching to MST mode, until MST
> > > > > + * supports link training fallback params.
> > > > > + */
> > > > > + if (intel_dp->reset_link_params || intel_dp->is_mst) {
> > > >
> > > > /me confused. Why do we need to touch this code?
> > >
> > > It's possible to switch to MST mode after the link rate/lane count got
> > > reduced by a link training error in SST mode.
> >
> > But then we should have a long hpd and reset_link_params should be set
> > anyway no?
>
> I meant switching the mode for the same sink as it would change its
> DP_MST_CAP. I'm not sure if a long HPD is required in that case.
I would expect so. I don't think there's a requirement in the spec to
re-evaluate this sort of stuff for a short hpd.
> Also if
> we had a long HPD after a mode change couldn't a modeset run before the
> next intel_dp_detect() call could reset the link params?
This is detect() we're talking about here, so I guess you mean
detect() running before the hpd gets to flag reset_link_params=true ?
Not sure I'd worry about that, but I guess there should be no harm
in reordering these things a bit.
Reviewed-by: Ville Syrjälä
>
> > >
> > > > > /* Initial max link lane count */
> > > > > intel_dp->max_link_lane_count =
> > > > > intel_dp_max_common_lane_count(intel_dp);
> > > > >
> > > > > @@ -6175,12 +6192,6 @@ intel_dp_detect(struct drm_connector
> > > > > *connector,
> > > > >
> > > >
Re: [Intel-gfx] [PATCH 6/6] drm/i915/dp_mst: Ensure the DPCD ACT sent flag is cleared before waiting for it
On Tue, Jun 16, 2020 at 06:45:46PM +0300, Ville Syrjälä wrote:
> On Tue, Jun 16, 2020 at 05:18:55PM +0300, Imre Deak wrote:
> > Atm, we clear the ACT sent flag in the sink's DPCD before updating the
> > sink's payload table, along clearing the payload table updated flag.
> > The sink is supposed to set this flag once it detects that the source
> > has completed the ACT sequence (after detecting the 4 required ACT MTPH
> > symbols sent by the source). As opposed to this 2 DELL monitors I have
> > set the flag already along the payload table updated flag, which is not
> > quite correct.
> >
> > To be sure that the sink has detected the ACT MTPH symbols before
> > continuing enabling the encoder, clear the ACT sent flag before enabling
> > or disabling the transcoder VC payload allocation (which is what starts
> > the ACT sequence).
> >
> > Cc: Lyude Paul
> > Cc: Ville Syrjälä
> > Cc: dri-de...@lists.freedesktop.org
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 31 +++--
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 ++
> > include/drm/drm_dp_mst_helper.h | 2 ++
> > 3 files changed, 33 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index b2f5a84b4cfb..e3bf8c9c8267 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -4377,6 +4377,34 @@ void drm_dp_mst_deallocate_vcpi(struct
> > drm_dp_mst_topology_mgr *mgr,
> > }
> > EXPORT_SYMBOL(drm_dp_mst_deallocate_vcpi);
> >
> > +/**
> > + * drm_dp_clear_payload_status() - Clears the payload table status flags
> > + * @mgr: manager to use
> > + *
> > + * Clears the payload table ACT handled and table updated flags in the MST
> > hub's
> > + * DPCD. This function must be called before updating the payload table or
> > + * starting the ACT sequence and waiting for the corresponding flags to get
> > + * set by the hub.
> > + *
> > + * Returns:
> > + * 0 if the flag got cleared successfully, otherwise a negative error code.
> > + */
> > +int drm_dp_clear_payload_status(struct drm_dp_mst_topology_mgr *mgr)
> > +{
> > + int ret;
> > +
> > + ret = drm_dp_dpcd_writeb(mgr->aux, DP_PAYLOAD_TABLE_UPDATE_STATUS,
> > +DP_PAYLOAD_ACT_HANDLED);
> > + if (ret < 0) {
> > + DRM_DEBUG_DRIVER("Can't clear the ACT sent flag (%d)\n", ret);
> > + return ret;
> > + }
> > + WARN_ON(ret != 1);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(drm_dp_clear_payload_status);
> > +
> > static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr,
> > int id, struct drm_dp_payload *payload)
> > {
> > @@ -4384,8 +4412,7 @@ static int drm_dp_dpcd_write_payload(struct
> > drm_dp_mst_topology_mgr *mgr,
> > int ret;
> > int retries = 0;
> >
> > - drm_dp_dpcd_writeb(mgr->aux, DP_PAYLOAD_TABLE_UPDATE_STATUS,
> > - DP_PAYLOAD_TABLE_UPDATED);
>
> We used to clear DP_PAYLOAD_TABLE_UPDATED but now we clear
> DP_PAYLOAD_ACT_HANDLED ?
Eek. We should write DP_PAYLOAD_TABLE_UPDATED which is the only way to
clear both the act-handled and the table-updated flags. I tested things
that way but managed to send an old version. Thanks for catching it.
>
> > + drm_dp_clear_payload_status(mgr);
> >
> > payload_alloc[0] = id;
> > payload_alloc[1] = payload->start_slot;
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index 9308b5920780..3c4b0fb10d8b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -323,6 +323,8 @@ static void clear_act_sent(struct intel_dp *intel_dp)
> >
> > intel_de_write(i915, intel_dp->regs.dp_tp_status,
> >DP_TP_STATUS_ACT_SENT);
> > +
> > + drm_dp_clear_payload_status(&intel_dp->mst_mgr);
> > }
> >
> > static void wait_for_act_sent(struct intel_dp *intel_dp)
> > diff --git a/include/drm/drm_dp_mst_helper.h
> > b/include/drm/drm_dp_mst_helper.h
> > index 8b9eb4db3381..2facb87624bf 100644
> > --- a/include/drm/drm_dp_mst_helper.h
> > +++ b/include/drm/drm_dp_mst_helper.h
> > @@ -763,6 +763,8 @@ int drm_dp_find_vcpi_slots(struct
> > drm_dp_mst_topology_mgr *mgr,
> >int pbn);
> >
> >
> > +int drm_dp_clear_payload_status(struct drm_dp_mst_topology_mgr *mgr);
> > +
> > int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr);
> >
> >
> > --
> > 2.23.1
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915/dp_mst: Disable link training fallback on MST links
On Tue, Jun 16, 2020 at 06:39:30PM +0300, Ville Syrjälä wrote:
> On Tue, Jun 16, 2020 at 06:30:55PM +0300, Imre Deak wrote:
> > On Tue, Jun 16, 2020 at 06:22:51PM +0300, Ville Syrjälä wrote:
> > > On Tue, Jun 16, 2020 at 05:18:51PM +0300, Imre Deak wrote:
> > > > We calculate the MST available bandwidth using the link's maximum rate
> > > > and lane count. This bandwidth won't be recalculated in response to a
> > >
> > > Thw wording here is a bit ambiguousr as to who "we" is, and what exactly
> > > "link's maximum rate and lane count". I would try to clarify a bit that
> > > it's drm_dp_mst_topology.c who is mostly in error here by directly
> > > interpreting the max data rate/lanes from the DPCD.
> > >
> > > Althoguh the i915 code is not wihtout faults, as it lacks any logic
> > > to modeset all the MST streams for this link when the link params
> > > change (except on tgl+ where the master/slave stuff should force
> > > all streams to do a modeset anyway).
> > >
> > > > link training error and fallback setting, so modesets following a link
> > > > training error will calculate incorrect timing parameters (like the
> > > > transcoder's data M/N params or the number of MST TUs).
> > > >
> > > > Prevent the above problem by disabling the link training fallback on MST
> > > > links for now, until the MST compute config can deal with changing link
> > > > parameters.
> > > >
> > > > The misconfigured timing lead at least to a
> > > > 'Timed out waiting for DP idle patterns'
> > > > error.
> > > >
> > > > Cc: Ville Syrjälä
> > > > Cc: Manasi Navare
> > > > Signed-off-by: Imre Deak
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_dp.c | 25 ++---
> > > > 1 file changed, 18 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > index 42589cae766d..c585b002783a 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > @@ -468,6 +468,13 @@ int intel_dp_get_link_train_fallback_values(struct
> > > > intel_dp *intel_dp,
> > > > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > int index;
> > > >
> > > > + /*
> > > > +* TODO: Enable fallback on MST links once MST link compute can
> > > > handle
> > > > +* the fallback params.
> > > > +*/
> > > > + if (intel_dp->is_mst)
> > > > + return -1;
> > >
> > > Should we duplicate the drm_error() from the other path here maybe?
> >
> > Yes, will add it.
> >
> > >
> > > > +
> > > > index = intel_dp_rate_index(intel_dp->common_rates,
> > > > intel_dp->num_common_rates,
> > > > link_rate);
> > > > @@ -6163,7 +6170,17 @@ intel_dp_detect(struct drm_connector *connector,
> > > > goto out;
> > > > }
> > > >
> > > > - if (intel_dp->reset_link_params) {
> > > > + /* Read DP Sink DSC Cap DPCD regs for DP v1.4 */
> > > > + if (INTEL_GEN(dev_priv) >= 11)
> > > > + intel_dp_get_dsc_sink_cap(intel_dp);
> > > > +
> > > > + intel_dp_configure_mst(intel_dp);
> > > > +
> > > > + /*
> > > > +* TODO: Reset link params when switching to MST mode, until MST
> > > > +* supports link training fallback params.
> > > > +*/
> > > > + if (intel_dp->reset_link_params || intel_dp->is_mst) {
> > >
> > > /me confused. Why do we need to touch this code?
> >
> > It's possible to switch to MST mode after the link rate/lane count got
> > reduced by a link training error in SST mode.
>
> But then we should have a long hpd and reset_link_params should be set
> anyway no?
I meant switching the mode for the same sink as it would change its
DP_MST_CAP. I'm not sure if a long HPD is required in that case. Also if
we had a long HPD after a mode change couldn't a modeset run before the
next intel_dp_detect() call could reset the link params?
> >
> > > > /* Initial max link lane count */
> > > > intel_dp->max_link_lane_count =
> > > > intel_dp_max_common_lane_count(intel_dp);
> > > >
> > > > @@ -6175,12 +6192,6 @@ intel_dp_detect(struct drm_connector *connector,
> > > >
> > > > intel_dp_print_rates(intel_dp);
> > > >
> > > > - /* Read DP Sink DSC Cap DPCD regs for DP v1.4 */
> > > > - if (INTEL_GEN(dev_priv) >= 11)
> > > > - intel_dp_get_dsc_sink_cap(intel_dp);
> > > > -
> > > > - intel_dp_configure_mst(intel_dp);
> > > > -
> > > > if (intel_dp->is_mst) {
> > > > /*
> > > > * If we are in MST mode then this connector
> > > > --
> > > > 2.23.1
> > >
> > > --
> > > Ville Syrjälä
> > > Intel
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lis
Re: [Intel-gfx] [PATCH 4/6] drm/i915/dp_mst: Clear only the ACT sent flag from DP_TP_STATUS
On Tue, Jun 16, 2020 at 05:18:53PM +0300, Imre Deak wrote: > It's not clear if the DP_TP_STATUS flags other than the ACT sent flag > have some side-effect, so don't clear those; we don't depend on the > state of these flags anyway. > > Suggested-by: Ville Syrjälä > Cc: Ville Syrjälä > Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c > b/drivers/gpu/drm/i915/display/intel_dp_mst.c > index 3977ee4f7176..b66b56a070e5 100644 > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c > @@ -322,7 +322,7 @@ static void clear_act_sent(struct intel_dp *intel_dp) > struct drm_i915_private *i915 = dp_to_i915(intel_dp); > > intel_de_write(i915, intel_dp->regs.dp_tp_status, > -intel_de_read(i915, intel_dp->regs.dp_tp_status)); > +DP_TP_STATUS_ACT_SENT); > } > > static void wait_for_act_sent(struct intel_dp *intel_dp) > -- > 2.23.1 -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915/dp_mst: Clear the ACT sent flag during encoder disabling too
On Tue, Jun 16, 2020 at 05:18:54PM +0300, Imre Deak wrote: > During encoder enabling we clear the flag before starting the ACT > sequence and wait for the flag, but the clearing is missing during > encoder disabling, add it there too. Since nothing cleared the flag > automatically we could've run subsequent disabling steps too early. > > Cc: Ville Syrjälä > Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c > b/drivers/gpu/drm/i915/display/intel_dp_mst.c > index b66b56a070e5..9308b5920780 100644 > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c > @@ -389,6 +389,8 @@ static void intel_mst_post_disable_dp(struct > intel_atomic_state *state, > > drm_dp_update_payload_part2(&intel_dp->mst_mgr); > > + clear_act_sent(intel_dp); > + > val = intel_de_read(dev_priv, > TRANS_DDI_FUNC_CTL(old_crtc_state->cpu_transcoder)); > val &= ~TRANS_DDI_DP_VC_PAYLOAD_ALLOC; > -- > 2.23.1 -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915/tgl+: Use the correct DP_TP_* register instances in MST encoders
On Tue, Jun 16, 2020 at 05:18:50PM +0300, Imre Deak wrote:
> MST encoders must use the master MST transcoder's DP_TP_STATUS and
> DP_TP_CONTROL registers. Atm, during the HW readout of a slave
> transcoder's CRTC state we reset these register addresses in
> intel_dp::regs.dp_tp_* to the slave transcoder's DP_TP_* register
> addresses incorrectly; fix this.
>
> This issue led at least to
> 'Timed out waiting for ACT sent when disabling'
> errors during output disabling in a multiple MST stream config.
>
> This change replaces
> https://patchwork.freedesktop.org/patch/369577/?series=78193&rev=1
> which just papered over the problem.
>
> Cc: Ville Syrjälä
> Cc: José Roberto de Souza
> Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index ca7bb2294d2b..73d6cc29291a 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4193,11 +4193,6 @@ void intel_ddi_get_config(struct intel_encoder
> *encoder,
> if (drm_WARN_ON(&dev_priv->drm, transcoder_is_dsi(cpu_transcoder)))
> return;
>
> - if (INTEL_GEN(dev_priv) >= 12) {
> - intel_dp->regs.dp_tp_ctl = TGL_DP_TP_CTL(cpu_transcoder);
> - intel_dp->regs.dp_tp_status = TGL_DP_TP_STATUS(cpu_transcoder);
> - }
> -
> intel_dsc_get_config(encoder, pipe_config);
>
> temp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
> @@ -4299,6 +4294,16 @@ void intel_ddi_get_config(struct intel_encoder
> *encoder,
> break;
> }
>
> + if (INTEL_GEN(dev_priv) >= 12) {
> + enum transcoder transcoder =
> + intel_dp_mst_is_slave_trans(pipe_config) ?
> + pipe_config->mst_master_transcoder :
> + pipe_config->cpu_transcoder;
> +
> + intel_dp->regs.dp_tp_ctl = TGL_DP_TP_CTL(transcoder);
> + intel_dp->regs.dp_tp_status = TGL_DP_TP_STATUS(transcoder);
> + }
> +
> pipe_config->has_audio =
> intel_ddi_is_audio_enabled(dev_priv, cpu_transcoder);
>
> --
> 2.23.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915/dp_mst: Move clearing the ACT sent flag closer to its polling
On Tue, Jun 16, 2020 at 05:18:52PM +0300, Imre Deak wrote:
> During transcoder enabling we'll configure the transcoder in MST mode
> and enable the VC payload allocation, which will start the ACT sequence.
> Before waiting for the ACT sequence completion, we need to clear the ACT
> sent flag, but based on the above we can do this right before enabling
> the transcoder.
>
> For clarity, move the flag clearing closer to where we wait for it.
>
> While at it also factor out some common code.
>
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 36 +
> 1 file changed, 23 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 2e6c6375a23b..3977ee4f7176 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -317,6 +317,25 @@ intel_dp_mst_atomic_check(struct drm_connector
> *connector,
> return ret;
> }
>
> +static void clear_act_sent(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> +
> + intel_de_write(i915, intel_dp->regs.dp_tp_status,
> +intel_de_read(i915, intel_dp->regs.dp_tp_status));
> +}
> +
> +static void wait_for_act_sent(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> +
> + if (intel_de_wait_for_set(i915, intel_dp->regs.dp_tp_status,
> + DP_TP_STATUS_ACT_SENT, 1))
> + drm_err(&i915->drm, "Timed out waiting for ACT sent\n");
> +
> + drm_dp_check_act_status(&intel_dp->mst_mgr);
> +}
> +
> static void intel_mst_disable_dp(struct intel_atomic_state *state,
>struct intel_encoder *encoder,
>const struct intel_crtc_state *old_crtc_state,
> @@ -377,11 +396,7 @@ static void intel_mst_post_disable_dp(struct
> intel_atomic_state *state,
> TRANS_DDI_FUNC_CTL(old_crtc_state->cpu_transcoder),
> val);
>
> - if (intel_de_wait_for_set(dev_priv, intel_dp->regs.dp_tp_status,
> - DP_TP_STATUS_ACT_SENT, 1))
> - drm_err(&dev_priv->drm,
> - "Timed out waiting for ACT sent when disabling\n");
> - drm_dp_check_act_status(&intel_dp->mst_mgr);
> + wait_for_act_sent(intel_dp);
>
> drm_dp_mst_deallocate_vcpi(&intel_dp->mst_mgr, connector->port);
>
> @@ -452,7 +467,6 @@ static void intel_mst_pre_enable_dp(struct
> intel_atomic_state *state,
> struct intel_connector *connector =
> to_intel_connector(conn_state->connector);
> int ret;
> - u32 temp;
> bool first_mst_stream;
>
> /* MST encoders are bound to a crtc, not to a connector,
> @@ -485,8 +499,6 @@ static void intel_mst_pre_enable_dp(struct
> intel_atomic_state *state,
> drm_err(&dev_priv->drm, "failed to allocate vcpi\n");
>
> intel_dp->active_mst_links++;
> - temp = intel_de_read(dev_priv, intel_dp->regs.dp_tp_status);
> - intel_de_write(dev_priv, intel_dp->regs.dp_tp_status, temp);
>
> ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
>
> @@ -517,16 +529,14 @@ static void intel_mst_enable_dp(struct
> intel_atomic_state *state,
>
> drm_WARN_ON(&dev_priv->drm, pipe_config->has_pch_encoder);
>
> + clear_act_sent(intel_dp);
> +
> intel_ddi_enable_transcoder_func(encoder, pipe_config);
>
> drm_dbg_kms(&dev_priv->drm, "active links %d\n",
> intel_dp->active_mst_links);
>
> - if (intel_de_wait_for_set(dev_priv, intel_dp->regs.dp_tp_status,
> - DP_TP_STATUS_ACT_SENT, 1))
> - drm_err(&dev_priv->drm, "Timed out waiting for ACT sent\n");
> -
> - drm_dp_check_act_status(&intel_dp->mst_mgr);
> + wait_for_act_sent(intel_dp);
>
> drm_dp_update_payload_part2(&intel_dp->mst_mgr);
>
> --
> 2.23.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
