Re: [Intel-gfx] [patch 00/13] preempt: Make preempt count unconditional
On Mon, Sep 14, 2020 at 11:24 PM Herbert Xu wrote: > > On Tue, Sep 15, 2020 at 09:20:59AM +0300, Ard Biesheuvel wrote: > > > > The documentation of kmap_atomic() states the following: > > > > * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap > > * gives a more generic (and caching) interface. But kmap_atomic can > > * be used in IRQ contexts, so in some (very limited) cases we need > > * it. > > > > so if this is no longer accurate, perhaps we should fix it? > > This hasn't been accurate for at least ten years :) Yeah, that used to be true a long long time ago, but the comment is very stale. > > But another reason I tried to avoid kmap_atomic() is that it disables > > preemption unconditionally, even on 64-bit architectures where HIGHMEM > > is irrelevant. So using kmap_atomic() here means that the bulk of > > WireGuard packet encryption runs with preemption disabled, essentially > > for legacy reasons. > > Agreed. We should definitely fix that. Well, honestly, one big reason for that is debugging. The *semantics* of the kmap_atomic() is in the name - you can't sleep in between it and the kunmap_atomic(). On any sane architecture, kmap_atomic() ends up being a no-op from an implementation standpoint, and sleeping would work just fine. But we very much want to make sure that people don't then write code that doesn't work on the bad old 32-bit machines where it really needs that sequence to be safe from preemption. So it's mostly a debug thing. I say "mostly", because there might be small other details too, like shared code, and perhaps even a couple of users out in the wild that depend on the pagefault_disable() inherent in the current kmap_atomic(), who knows.. So no, the preemption disabling isn't inherent in the operation itself. But it does have some argument for it. Linus ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 00/13] preempt: Make preempt count unconditional
On Tue, Sep 15, 2020 at 09:20:59AM +0300, Ard Biesheuvel wrote: > > The documentation of kmap_atomic() states the following: > > * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap > * gives a more generic (and caching) interface. But kmap_atomic can > * be used in IRQ contexts, so in some (very limited) cases we need > * it. > > so if this is no longer accurate, perhaps we should fix it? This hasn't been accurate for at least ten years :) > But another reason I tried to avoid kmap_atomic() is that it disables > preemption unconditionally, even on 64-bit architectures where HIGHMEM > is irrelevant. So using kmap_atomic() here means that the bulk of > WireGuard packet encryption runs with preemption disabled, essentially > for legacy reasons. Agreed. We should definitely fix that. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ___ 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: Fix the race between the GEM close and debugfs (rev2)
== Series Details ==
Series: drm/i915: Fix the race between the GEM close and debugfs (rev2)
URL : https://patchwork.freedesktop.org/series/81646/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9008 -> Patchwork_18497
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18497/index.html
Known issues
Here are the changes found in Patchwork_18497 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18497/fi-byt-j1900/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@execlists:
- fi-icl-y: [PASS][3] -> [INCOMPLETE][4] ([i915#2276])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-icl-y/igt@i915_selftest@l...@execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18497/fi-icl-y/igt@i915_selftest@l...@execlists.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18497/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18497/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
* igt@vgem_basic@sysfs:
- fi-tgl-y: [PASS][9] -> [DMESG-WARN][10] ([i915#402]) +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-tgl-y/igt@vgem_ba...@sysfs.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18497/fi-tgl-y/igt@vgem_ba...@sysfs.html
Possible fixes
* {igt@core_hotunplug@unbind-rebind}:
- {fi-tgl-dsi}: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-tgl-dsi/igt@core_hotunp...@unbind-rebind.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18497/fi-tgl-dsi/igt@core_hotunp...@unbind-rebind.html
* igt@gem_flink_basic@double-flink:
- fi-tgl-y: [DMESG-WARN][13] ([i915#402]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18497/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
* igt@i915_module_load@reload:
- fi-byt-j1900: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-byt-j1900/igt@i915_module_l...@reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18497/fi-byt-j1900/igt@i915_module_l...@reload.html
- fi-tgl-u2: [DMESG-WARN][17] ([i915#1982] / [k.org#205379]) ->
[PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-tgl-u2/igt@i915_module_l...@reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18497/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18497/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22] +1
similar issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18497/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
* igt@vgem_basic@unload:
- fi-skl-guc: [DMESG-WARN][23] ([i915#2203]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-skl-guc/igt@vgem_ba...@unload.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18497/fi-skl-guc/igt@vgem_ba...@unload.html
- fi-kbl-x1275: [DMESG-WARN][25] ([i915#62] / [i915#92]) -> [PASS][26]
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-kbl-x1275/igt@vgem_ba...@unload.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18497/fi-kbl-x1275/igt@v
[Intel-gfx] [PATCH v2] drm/i915: Fix the race between the GEM close and debugfs
As we close GEM object and set file_priv to -EBADF which is protected
by ctx->mutex, populating the GEM debugfs info is not protected
and results in the crash shown below.
Make sure to protect the access to file_priv using ctx->mutex to avoid
race.
BUG: unable to handle page fault for address:
RIP: 0010:i915_gem_object_info+0x26b/0x3eb
Code: 89 44 24 48 48 89 44 24 40 48 89 44 24 38 48 89 44 24 30 48 89 44 24 28
48 89 44 24 20 49 8b 46 f0 48 89 44 24 20 49 8b 46 a0 <48> 8b 58 08 b9 0a 00 00
00 48 b8 aa aa aa aa aa aa aa aa 48 8d bc
RSP: 0018:ac81c14cfc30 EFLAGS: 00010246
RAX: fff7 RBX: 95094429c218 RCX: 95096756c740
RDX: RSI: 919b93ee RDI: 95094429c218
RBP: ac81c14cfd58 R08: 9509746fab80 R09:
R10: 0001 R11: R12: 9509753f8e80
R13: ac81c14cfc98 R14: 95094429c268 R15: ac81c14cfc88
FS: 7a1bdcd52900() GS:950977e0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: CR3: 00026b4e CR4: 00340ef0
Call Trace:
seq_read+0x162/0x3ca
full_proxy_read+0x5b/0x8d
__vfs_read+0x45/0x1b9
vfs_read+0xc9/0x15e
ksys_read+0x7e/0xde
do_syscall_64+0x54/0x7e
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7a1bdd34cf03
Signed-off-by: Nikunj A. Dadhania
Reviewed-by: Tvrtko Ursulin
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 784219962193..ea469168cd44 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -326,6 +326,7 @@ static void print_context_stats(struct seq_file *m,
}
i915_gem_context_unlock_engines(ctx);
+ mutex_lock(&ctx->mutex);
if (!IS_ERR_OR_NULL(ctx->file_priv)) {
struct file_stats stats = {
.vm = rcu_access_pointer(ctx->vm),
@@ -346,6 +347,7 @@ static void print_context_stats(struct seq_file *m,
print_file_stats(m, name, stats);
}
+ mutex_unlock(&ctx->mutex);
spin_lock(&i915->gem.contexts.lock);
list_safe_reset_next(ctx, cn, link);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] crypto: lib/chacha20poly1305 - Set SG_MITER_ATOMIC unconditionally
On Mon, Sep 14, 2020 at 03:37:49PM -0700, Linus Torvalds wrote: > > So it _looks_ like this code started using kmap() - probably back when > kmap_atomic() was so cumbersome to use - and was then converted > (conditionally) to kmap_atomic() rather than just changed whole-sale. > Is there actually something that wants to use those sg_miter functions > and sleep? I dug up the old zinc patch submissions and this wasn't present at all in the original. The original zinc code used blkcipher_walk which unconditinoally does kmap_atomic. So it's only the SG miter conversion that introduced this change, which appears to be a simple oversight (I think Ard was working on latency issues at that time, perhaps he was worried about keeping preemption off unnecessarily). ---8<--- There is no reason for the chacha20poly1305 SG miter code to use kmap instead of kmap_atomic as the critical section doesn't sleep anyway. So we can simply get rid of the preemptible check and set SG_MITER_ATOMIC unconditionally. Even if we need to reenable preemption to lower latency we should be doing that by interrupting the SG miter walk rather than using kmap. Reported-by: Linus Torvalds Signed-off-by: Herbert Xu diff --git a/lib/crypto/chacha20poly1305.c b/lib/crypto/chacha20poly1305.c index 431e04280332..5850f3b87359 100644 --- a/lib/crypto/chacha20poly1305.c +++ b/lib/crypto/chacha20poly1305.c @@ -251,9 +251,7 @@ bool chacha20poly1305_crypt_sg_inplace(struct scatterlist *src, poly1305_update(&poly1305_state, pad0, 0x10 - (ad_len & 0xf)); } - flags = SG_MITER_TO_SG; - if (!preemptible()) - flags |= SG_MITER_ATOMIC; + flags = SG_MITER_TO_SG | SG_MITER_ATOMIC; sg_miter_start(&miter, src, sg_nents(src), flags); -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/6] Convert the intel iommu driver to the dma-iommu api
Hi Tvrtko, On 9/14/20 4:04 PM, Tvrtko Ursulin wrote: Hi, On 12/09/2020 04:21, Lu Baolu wrote: Tom Murphy has almost done all the work. His latest patch series was posted here. https://lore.kernel.org/linux-iommu/20200903201839.7327-1-murph...@tcd.ie/ Thanks a lot! This series is a follow-up with below changes: 1. Add a quirk for the i915 driver issue described in Tom's cover letter. Last week I have copied you on an i915 series which appears to remove the need for this quirk. so if we get those i915 patches reviewed and merged, do you still want to pursue this quirk? It's up to the graphic guys. I don't know the details in i915 driver. I don't think my tests could cover all cases. 2. Fix several bugs in patch "iommu: Allow the dma-iommu api to use bounce buffers" to make the bounce buffer work for untrusted devices. 3. Several cleanups in iommu/vt-d driver after the conversion. With the previous version of the series I hit a problem on Ivybridge where apparently the dma engine width is not respected. At least that is my layman interpretation of the errors. From the older thread: <3> [209.526605] DMAR: intel_iommu_map: iommu width (39) is not sufficient for the mapped address (008000) Relevant iommu boot related messages are: <6>[0.184234] DMAR: Host address width 36 <6>[0.184245] DMAR: DRHD base: 0x00fed9 flags: 0x0 <6>[0.184288] DMAR: dmar0: reg_base_addr fed9 ver 1:0 cap c020e60262 ecap f0101a <6>[0.184308] DMAR: DRHD base: 0x00fed91000 flags: 0x1 <6>[0.184337] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap c9008020660262 ecap f0105a <6>[0.184357] DMAR: RMRR base: 0x00d8d28000 end: 0x00d8d46fff <6>[0.184377] DMAR: RMRR base: 0x00db00 end: 0x00df1f <6>[0.184398] DMAR-IR: IOAPIC id 2 under DRHD base 0xfed91000 IOMMU 1 <6>[0.184414] DMAR-IR: HPET id 0 under DRHD base 0xfed91000 <6>[0.184428] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping. <6>[0.185173] DMAR-IR: Enabled IRQ remapping in x2apic mode <6>[0.878934] DMAR: No ATSR found <6>[0.878966] DMAR: dmar0: Using Queued invalidation <6>[0.879007] DMAR: dmar1: Using Queued invalidation <6>[0.915032] DMAR: Intel(R) Virtualization Technology for Directed I/O <6>[0.915060] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) <6>[0.915084] software IO TLB: mapped [mem 0xc80d4000-0xcc0d4000] (64MB) (Full boot log at https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_7054/fi-ivb-3770/boot0.txt, failures at https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_7054/fi-ivb-3770/igt@i915_selftest@l...@blt.html.) Does this look familiar or at least plausible to you? Is this something your new series has fixed? This happens during attaching a domain to device. It has nothing to do with this patch series. I will look into this issue, but not in this email thread context. Best regards, baolu Regards, Tvrtko Please review and test. Best regards, baolu Lu Baolu (2): iommu: Add quirk for Intel graphic devices in map_sg iommu/vt-d: Cleanup after converting to dma-iommu ops Tom Murphy (4): iommu: Handle freelists when using deferred flushing in iommu drivers iommu: Add iommu_dma_free_cpu_cached_iovas() iommu: Allow the dma-iommu api to use bounce buffers iommu/vt-d: Convert intel iommu driver to the iommu ops .../admin-guide/kernel-parameters.txt | 5 - drivers/iommu/dma-iommu.c | 229 - drivers/iommu/intel/Kconfig | 1 + drivers/iommu/intel/iommu.c | 885 +++--- include/linux/dma-iommu.h | 8 + include/linux/iommu.h | 1 + 6 files changed, 323 insertions(+), 806 deletions(-) ___ 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/pll: Centralize PLL_ENABLE register lookup (rev5)
== Series Details == Series: drm/i915/pll: Centralize PLL_ENABLE register lookup (rev5) URL : https://patchwork.freedesktop.org/series/81150/ State : success == Summary == CI Bug Log - changes from CI_DRM_9007_full -> Patchwork_18494_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18494_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_whisper@basic-fds: - shard-glk: [PASS][1] -> [DMESG-WARN][2] ([i915#118] / [i915#95]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-glk7/igt@gem_exec_whis...@basic-fds.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/shard-glk9/igt@gem_exec_whis...@basic-fds.html * igt@gem_userptr_blits@unsync-unmap-cycles: - shard-skl: [PASS][3] -> [TIMEOUT][4] ([i915#1958]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-skl6/igt@gem_userptr_bl...@unsync-unmap-cycles.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/shard-skl1/igt@gem_userptr_bl...@unsync-unmap-cycles.html * igt@gen9_exec_parse@allowed-single: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#1436] / [i915#1635] / [i915#716]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-apl8/igt@gen9_exec_pa...@allowed-single.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/shard-apl2/igt@gen9_exec_pa...@allowed-single.html * igt@i915_selftest@mock@contexts: - shard-apl: [PASS][7] -> [INCOMPLETE][8] ([i915#1635] / [i915#2278]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-apl6/igt@i915_selftest@m...@contexts.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/shard-apl4/igt@i915_selftest@m...@contexts.html * igt@kms_big_fb@x-tiled-64bpp-rotate-180: - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-glk5/igt@kms_big...@x-tiled-64bpp-rotate-180.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/shard-glk2/igt@kms_big...@x-tiled-64bpp-rotate-180.html * igt@kms_cursor_legacy@basic-flip-before-cursor-atomic: - shard-tglb: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-tglb6/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/shard-tglb1/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#2346]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-skl10/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/shard-skl7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html * igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible@a-dp1: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#1635] / [i915#1982]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-apl3/igt@kms_flip@flip-vs-absolute-wf_vblank-interrupti...@a-dp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/shard-apl7/igt@kms_flip@flip-vs-absolute-wf_vblank-interrupti...@a-dp1.html - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-kbl7/igt@kms_flip@flip-vs-absolute-wf_vblank-interrupti...@a-dp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/shard-kbl6/igt@kms_flip@flip-vs-absolute-wf_vblank-interrupti...@a-dp1.html * igt@kms_flip@flip-vs-suspend@c-dp1: - shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +7 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-kbl4/igt@kms_flip@flip-vs-susp...@c-dp1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/shard-kbl1/igt@kms_flip@flip-vs-susp...@c-dp1.html * igt@kms_flip_tiling@flip-y-tiled: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#699]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-skl5/igt@kms_flip_til...@flip-y-tiled.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/shard-skl5/igt@kms_flip_til...@flip-y-tiled.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt: - shard-iclb: [PASS][23] -> [DMESG-WARN][24] ([i915#1982]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-pr
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Reduce INTEL_DISPLAY_ENABLED to just removing the outputs (rev4)
== Series Details == Series: series starting with [1/2] drm/i915: Reduce INTEL_DISPLAY_ENABLED to just removing the outputs (rev4) URL : https://patchwork.freedesktop.org/series/81507/ State : success == Summary == CI Bug Log - changes from CI_DRM_9007_full -> Patchwork_18492_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18492_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-mixed-process@bsd: - shard-skl: [PASS][1] -> [FAIL][2] ([i915#2374]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-skl6/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18492/shard-skl10/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd.html * igt@gem_exec_suspend@basic-s3: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([i915#198]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-skl5/igt@gem_exec_susp...@basic-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18492/shard-skl8/igt@gem_exec_susp...@basic-s3.html * igt@gem_exec_whisper@basic-queues-forked-all: - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-glk6/igt@gem_exec_whis...@basic-queues-forked-all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18492/shard-glk4/igt@gem_exec_whis...@basic-queues-forked-all.html * igt@gem_tiled_swapping@non-threaded: - shard-apl: [PASS][7] -> [TIMEOUT][8] ([i915#1521] / [i915#1635]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-apl7/igt@gem_tiled_swapp...@non-threaded.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18492/shard-apl2/igt@gem_tiled_swapp...@non-threaded.html * igt@gem_userptr_blits@unsync-unmap-cycles: - shard-skl: [PASS][9] -> [TIMEOUT][10] ([i915#1958]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-skl6/igt@gem_userptr_bl...@unsync-unmap-cycles.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18492/shard-skl10/igt@gem_userptr_bl...@unsync-unmap-cycles.html * igt@kms_cursor_edge_walk@pipe-b-64x64-right-edge: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +11 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-skl9/igt@kms_cursor_edge_w...@pipe-b-64x64-right-edge.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18492/shard-skl7/igt@kms_cursor_edge_w...@pipe-b-64x64-right-edge.html * igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible@a-dp1: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-kbl7/igt@kms_flip@flip-vs-absolute-wf_vblank-interrupti...@a-dp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18492/shard-kbl6/igt@kms_flip@flip-vs-absolute-wf_vblank-interrupti...@a-dp1.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#79]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-skl9/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18492/shard-skl7/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html * igt@kms_flip@flip-vs-suspend@c-dp1: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +8 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-kbl4/igt@kms_flip@flip-vs-susp...@c-dp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18492/shard-kbl7/igt@kms_flip@flip-vs-susp...@c-dp1.html * igt@kms_flip@plain-flip-ts-check@b-edp1: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#2122]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-skl8/igt@kms_flip@plain-flip-ts-ch...@b-edp1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18492/shard-skl8/igt@kms_flip@plain-flip-ts-ch...@b-edp1.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-indfb-plflip-blt: - shard-tglb: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-tglb7/igt@kms_frontbuffer_track...@psr-1p-primscrn-indfb-plflip-blt.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18492/shard-tglb8/igt@kms_frontbuffer_track...@psr-1p-primscrn-indfb-plflip-blt.html * igt@kms_hdr@bpc-switch-dpms: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#1188]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-skl7/igt@kms_...@bpc-switch-dpms.html [24]: h
[Intel-gfx] ✓ Fi.CI.IGT: success for Per client engine busyness
== Series Details == Series: Per client engine busyness URL : https://patchwork.freedesktop.org/series/81652/ State : success == Summary == CI Bug Log - changes from CI_DRM_9007_full -> Patchwork_18491_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18491_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]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-kbl7/igt@gem_ctx_isolation@preservation...@vcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/shard-kbl6/igt@gem_ctx_isolation@preservation...@vcs0.html * igt@gem_exec_whisper@basic-queues-forked-all: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-glk6/igt@gem_exec_whis...@basic-queues-forked-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/shard-glk9/igt@gem_exec_whis...@basic-queues-forked-all.html * igt@gem_workarounds@suspend-resume-fd: - shard-iclb: [PASS][5] -> [INCOMPLETE][6] ([i915#1185]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-iclb7/igt@gem_workarou...@suspend-resume-fd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/shard-iclb3/igt@gem_workarou...@suspend-resume-fd.html * igt@i915_suspend@debugfs-reader: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([i915#198]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-skl6/igt@i915_susp...@debugfs-reader.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/shard-skl3/igt@i915_susp...@debugfs-reader.html * igt@kms_cursor_legacy@short-flip-after-cursor-atomic-transitions: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#1635] / [i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-apl4/igt@kms_cursor_leg...@short-flip-after-cursor-atomic-transitions.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/shard-apl8/igt@kms_cursor_leg...@short-flip-after-cursor-atomic-transitions.html * igt@kms_flip@flip-vs-expired-vblank@b-edp1: - shard-skl: [PASS][11] -> [FAIL][12] ([i915#79]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-skl6/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/shard-skl5/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html * igt@kms_flip_tiling@flip-y-tiled: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#699]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-skl5/igt@kms_flip_til...@flip-y-tiled.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/shard-skl2/igt@kms_flip_til...@flip-y-tiled.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-render: - shard-tglb: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-tglb1/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-render.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/shard-tglb7/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-render.html * igt@kms_hdr@bpc-switch-dpms: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#1188]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-skl7/igt@kms_...@bpc-switch-dpms.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/shard-skl8/igt@kms_...@bpc-switch-dpms.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145] / [i915#265]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-skl5/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/shard-skl2/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html * igt@kms_psr@psr2_primary_mmap_cpu: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/shard-iclb8/igt@kms_psr@psr2_primary_mmap_cpu.html * igt@kms_setmode@basic: - shard-apl: [PASS][23] -> [FAIL][24] ([i915#1635] / [i915#31]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/shard-apl3/igt@kms_setm...@basic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/shard-apl3/igt@kms_setm...@basic.html * igt@perf@polling-small-buf: - shard-skl: [PASS][25] -> [DMESG-WARN][26] ([i915#1982])
Re: [Intel-gfx] [PATCH] drm/i915/tgl, rkl: Make Wa_1606700617/22010271021 permanent
> On Sep 14, 2020, at 1:05 PM, Vivi, Rodrigo wrote:
>
>
>
>> On Sep 11, 2020, at 9:00 PM, Dhanavanthri, Swathi
>> wrote:
>>
>> It is in the if statement: if (IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915)) {
>
> duh! sorry...
>
> more below:
>
>>
>> -Original Message-
>> From: Rodrigo Vivi
>> Sent: Friday, September 11, 2020 6:10 PM
>> To: Dhanavanthri, Swathi
>> Cc: intel-gfx@lists.freedesktop.org
>> Subject: Re: [Intel-gfx] [PATCH] drm/i915/tgl, rkl: Make
>> Wa_1606700617/22010271021 permanent
>>
>> On Fri, Sep 11, 2020 at 03:11:58PM -0700, Swathi Dhanavanthri wrote:
>>> This workaround applies to all TGL and RKL steppings.
>>>
>>> Signed-off-by: Swathi Dhanavanthri
>>> ---
>>> drivers/gpu/drm/i915/gt/intel_workarounds.c | 7 ---
>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
>>> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
>>> index 39817c5a7058..6c580d0d9ea8 100644
>>> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
>>> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
>>> @@ -1729,10 +1729,11 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
>>> struct i915_wa_list *wal)
>>> GEN6_RC_SLEEP_PSMI_CONTROL,
>>> GEN12_WAIT_FOR_EVENT_POWER_DOWN_DISABLE |
>>> GEN8_RC_SEMA_IDLE_MSG_DISABLE);
>>> - }
>
> now I noticed this ^ :)
>
>>>
>>> - if (IS_TGL_U(i915) || IS_TGL_Y(i915)) {
>>
>> please notice this function is called for other gens.
>> In case you need to extend this to other platforms, please add them to the
>> if instead of removing the if.
>>
>>> - /* Wa_1606700617:tgl */
>>> + /*
>>> +* Wa_1606700617:tgl
>>> +* Wa_22010271021:tgl,rkl
>
> 1. This HSD only mentions TGL-U. No mention to RKL.
> 2. No mention to anything related to this clock gate.
> 3. Actually no W/a description at all and no sw_impact at all. But It links
> to another entry 22010288313,
> which describes the w/a as a 3dstate ff one...
>
> What am I missing here?
missing that old bspec page of course. Thanks for pointing it out...
Reviewed-by: Rodrigo Vivi
>
> Thanks,
> Rodrigo.
>
>>> +*/
>>> wa_masked_en(wal,
>>> GEN9_CS_DEBUG_MODE1,
>>> FF_DOP_CLOCK_GATE_DISABLE);
>>> --
>>> 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 mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 00/13] preempt: Make preempt count unconditional
On Mon, Sep 14, 2020 at 3:24 PM Linus Torvalds
wrote:
>
> Ard and Herbert added to participants: see
> chacha20poly1305_crypt_sg_inplace(), which does
>
> flags = SG_MITER_TO_SG;
> if (!preemptible())
> flags |= SG_MITER_ATOMIC;
>
> introduced in commit d95312a3ccc0 ("crypto: lib/chacha20poly1305 -
> reimplement crypt_from_sg() routine").
As far as I can tell, the only reason for this all is to try to use
"kmap()" rather than "kmap_atomic()".
And kmap() actually has the much more complex "might_sleep()" tests,
and apparently the "preemptible()" check wasn't even the proper full
debug check, it was just a complete hack to catch the one that
triggered.
>From a quick look, that code should probably just get rid of
SG_MITER_ATOMIC entirely, and alwayse use kmap_atomic().
kmap_atomic() is actually the faster and proper interface to use
anyway (never mind that any of this matters on any sane hardware). The
old kmap() and kunmap() interfaces should generally be avoided like
the plague - yes, they allow sleeping in the middle and that is
sometimes required, but if you don't need that, you should never ever
use them.
We used to have a very nasty kmap_atomic() that required people to be
very careful and know exactly which atomic entry to use, and that was
admitedly quite nasty.
So it _looks_ like this code started using kmap() - probably back when
kmap_atomic() was so cumbersome to use - and was then converted
(conditionally) to kmap_atomic() rather than just changed whole-sale.
Is there actually something that wants to use those sg_miter functions
and sleep?
Because if there is, that choice should come from the outside, not
from inside lib/scatterlist.c trying to make some bad guess based on
the wrong thing entirely.
Linus
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 00/13] preempt: Make preempt count unconditional
On Mon, Sep 14, 2020 at 2:55 PM Thomas Gleixner wrote:
>
> Yes it does generate better code, but I tried hard to spot a difference
> in various metrics exposed by perf. It's all in the noise and I only
> can spot a difference when the actual preemption check after the
> decrement
I'm somewhat more worried about the small-device case.
That said, the diffstat certainly has its very clear charm, and I do
agree that it makes things simpler.
I'm just not convinced people should ever EVER do things like that "if
(preemptible())" garbage. It sounds like somebody is doing seriously
bad things.
The chacha20poly1305 code does look fundamentally broken. But no, the
fix is not to make "preemptible" work with spinlocks, the fix is to
not *do* that kind of broken things.
Those things would be broken even if you changed the semantics of
preemptible. There's no way that it's valid to say "use this debug
flag to decide if we should do atomic allocations or not".
It smells like "I got a debug failure, so I'm papering it over by
checking the thing the debug code checks for".
The debug check is to catch the obvious bad cases. It's not the _only_
bad cases, so copying the debug check test is just completely wrong.
Ard and Herbert added to participants: see
chacha20poly1305_crypt_sg_inplace(), which does
flags = SG_MITER_TO_SG;
if (!preemptible())
flags |= SG_MITER_ATOMIC;
introduced in commit d95312a3ccc0 ("crypto: lib/chacha20poly1305 -
reimplement crypt_from_sg() routine").
You *fundamentally* cannot do that. Seriously. It's completely wrong.
Pick one or the other, or have the caller *tell* you what the context
is.
Linus
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Enable HDR on MCA LSPCON based Gen9 devices (rev6)
== Series Details ==
Series: Enable HDR on MCA LSPCON based Gen9 devices (rev6)
URL : https://patchwork.freedesktop.org/series/68081/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9008 -> Patchwork_18495
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18495/index.html
Known issues
Here are the changes found in Patchwork_18495 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@execlists:
- fi-icl-y: [PASS][1] -> [INCOMPLETE][2] ([i915#2276])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-icl-y/igt@i915_selftest@l...@execlists.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18495/fi-icl-y/igt@i915_selftest@l...@execlists.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u: [PASS][3] -> [DMESG-WARN][4] ([i915#2203])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18495/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18495/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-bsw-kefka: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18495/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- fi-icl-u2: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18495/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
* igt@prime_vgem@basic-read:
- fi-tgl-y: [PASS][11] -> [DMESG-WARN][12] ([i915#402]) +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-tgl-y/igt@prime_v...@basic-read.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18495/fi-tgl-y/igt@prime_v...@basic-read.html
Possible fixes
* {igt@core_hotunplug@unbind-rebind}:
- {fi-tgl-dsi}: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-tgl-dsi/igt@core_hotunp...@unbind-rebind.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18495/fi-tgl-dsi/igt@core_hotunp...@unbind-rebind.html
* igt@gem_flink_basic@double-flink:
- fi-tgl-y: [DMESG-WARN][15] ([i915#402]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18495/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
* igt@i915_module_load@reload:
- fi-byt-j1900: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-byt-j1900/igt@i915_module_l...@reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18495/fi-byt-j1900/igt@i915_module_l...@reload.html
- fi-tgl-u2: [DMESG-WARN][19] ([i915#1982] / [k.org#205379]) ->
[PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-tgl-u2/igt@i915_module_l...@reload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18495/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18495/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][23] ([i915#1982]) -> [PASS][24] +1
similar issue
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18495/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
* igt@vgem_basic@unload:
- fi-skl-guc: [DMESG-WARN][25] ([i915#2203]) -> [PASS][26]
[25]:
https://intel-gfx-ci.01.org/tree/drm-ti
[Intel-gfx] ✗ Fi.CI.BUILD: failure for preempt: Make preempt count unconditional
== Series Details == Series: preempt: Make preempt count unconditional URL : https://patchwork.freedesktop.org/series/81661/ State : failure == Summary == Applying: lib/debug: Remove pointless ARCH_NO_PREEMPT dependencies Applying: preempt: Make preempt count unconditional Applying: preempt: Clenaup PREEMPT_COUNT leftovers Applying: lockdep: Clenaup PREEMPT_COUNT leftovers Applying: mm/pagemap: Clenaup PREEMPT_COUNT leftovers Applying: locking/bitspinlock: Clenaup PREEMPT_COUNT leftovers Applying: uaccess: Clenaup PREEMPT_COUNT leftovers Applying: sched: Clenaup PREEMPT_COUNT leftovers Applying: ARM: Clenaup PREEMPT_COUNT leftovers Applying: xtensa: Clenaup PREEMPT_COUNT leftovers Applying: drm/i915: Clenaup PREEMPT_COUNT leftovers error: sha1 information is lacking or useless (drivers/gpu/drm/i915/Kconfig.debug). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0011 drm/i915: Clenaup PREEMPT_COUNT leftovers When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 00/13] preempt: Make preempt count unconditional
On Mon, Sep 14 2020 at 13:59, Linus Torvalds wrote:
> On Mon, Sep 14, 2020 at 1:45 PM Thomas Gleixner wrote:
>>
>> Recently merged code does:
>>
>> gfp = preemptible() ? GFP_KERNEL : GFP_ATOMIC;
>>
>> Looks obviously correct, except for the fact that preemptible() is
>> unconditionally false for CONFIF_PREEMPT_COUNT=n, i.e. all allocations in
>> that code use GFP_ATOMIC on such kernels.
>
> I don't think this is a good reason to entirely get rid of the
> no-preempt thing.
I did not say that this is a good reason. It just illustrates the
problem.
> The above is just garbage. It's bogus. You can't do it.
>
> Blaming the no-preempt code for this bug is extremely unfair, imho.
I'm not blaming the no-preempt code. I'm blaming inconsistency and there
is no real good argument for inconsistent behaviour, TBH.
> And the no-preempt code does help make for much better code generation
> for simple spinlocks.
Yes it does generate better code, but I tried hard to spot a difference
in various metrics exposed by perf. It's all in the noise and I only
can spot a difference when the actual preemption check after the
decrement which still depends on CONFIG_PREEMPT is in place, but that's
not the case for PREEMPT_NONE or PREEMPT_VOLUNTARY kernels where the
decrement is just a decrement w/o any conditional behind it.
> Where is that horribly buggy recent code? It's not in that exact
> format, certainly, since 'grep' doesn't find it.
Bah, that was stuff in next which got dropped again.
But just look at any check which uses preemptible(), especially those
which check !preemptible():
In the X86 #GP handler we have:
/*
* To be potentially processing a kprobe fault and to trust the result
* from kprobe_running(), we have to be non-preemptible.
*/
if (!preemptible() &&
kprobe_running() &&
kprobe_fault_handler(regs, X86_TRAP_GP))
goto exit;
and a similar check in the S390 code in kprobe_exceptions_notify(). That
all magically 'works' because that code might have been actually tested
with lockdep enabled which enforces PREEMPT_COUNT...
The SG code has some interesting usage as well:
if (miter->__flags & SG_MITER_ATOMIC) {
WARN_ON_ONCE(preemptible());
kunmap_atomic(miter->addr);
How is that WARN_ON_ONCE() supposed to catch anything? Especially as
calling code does:
flags = SG_MITER_TO_SG;
if (!preemptible())
flags |= SG_MITER_ATOMIC;
which is equally useless on kernels which have PREEMPT_COUNT=n.
There are bugs which are related to in_atomic() or other in_***() usage
all over the place as well.
Inconsistency at the core level is a clear recipe for disaster and at
some point we have to bite the bullet and accept that consistency is
more important than the non measurable 3 cycles?
Thanks,
tglx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enable HDR on MCA LSPCON based Gen9 devices (rev6)
== Series Details == Series: Enable HDR on MCA LSPCON based Gen9 devices (rev6) URL : https://patchwork.freedesktop.org/series/68081/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_reset.c:1311:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' - different lock contexts for basic block ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 00/13] preempt: Make preempt count unconditional
On Mon, Sep 14, 2020 at 1:45 PM Thomas Gleixner wrote: > > Recently merged code does: > > gfp = preemptible() ? GFP_KERNEL : GFP_ATOMIC; > > Looks obviously correct, except for the fact that preemptible() is > unconditionally false for CONFIF_PREEMPT_COUNT=n, i.e. all allocations in > that code use GFP_ATOMIC on such kernels. I don't think this is a good reason to entirely get rid of the no-preempt thing. The above is just garbage. It's bogus. You can't do it. Blaming the no-preempt code for this bug is extremely unfair, imho. And the no-preempt code does help make for much better code generation for simple spinlocks. Where is that horribly buggy recent code? It's not in that exact format, certainly, since 'grep' doesn't find it. Linus ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915/display: Fix state of PSR2 sub features
On Mon, 2020-09-14 at 23:30 +0300, Ville Syrjälä wrote:
> On Mon, Sep 14, 2020 at 07:57:34PM +, Souza, Jose wrote:
> > On Mon, 2020-09-14 at 17:24 +0300, Ville Syrjälä wrote:
> > > On Mon, Aug 31, 2020 at 06:09:22PM -0700, José Roberto de Souza wrote:
> > > > In case PSR2 is disabled by debugfs dc3co_enabled and
> > > > psr2_sel_fetch_enabled were still being set causing some code paths
> > > > to be executed were it should not.
> > > > We have tests for PSR1 and PSR2 so keep those features disabled when
> > > > PSR1 is active but PSR2 is supported is important.
> > > >
> > > > Cc: Gwan-gyeong Mun <
> > > > gwan-gyeong@intel.com
> > > >
> > > >
> > > > Cc: Ville Syrjälä <
> > > > ville.syrj...@linux.intel.com
> > > >
> > > >
> > > > Signed-off-by: José Roberto de Souza <
> > > > jose.so...@intel.com
> > > >
> > > >
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_psr.c | 11 +++
> > > > 1 file changed, 7 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > index 4e09ae61d4aa..6698d0209879 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > @@ -962,12 +962,14 @@ static void intel_psr_enable_locked(struct
> > > > drm_i915_private *dev_priv,
> > > > dev_priv->psr.psr2_enabled = intel_psr2_enabled(dev_priv,
> > > > crtc_state);
> > > > dev_priv->psr.busy_frontbuffer_bits = 0;
> > > > dev_priv->psr.pipe = to_intel_crtc(crtc_state->uapi.crtc)->pipe;
> > > > - dev_priv->psr.dc3co_enabled = !!crtc_state->dc3co_exitline;
> > > > + dev_priv->psr.dc3co_enabled = !!crtc_state->dc3co_exitline &&
> > > > + dev_priv->psr.psr2_enabled;
> > > > dev_priv->psr.transcoder = crtc_state->cpu_transcoder;
> > > > /* DC5/DC6 requires at least 6 idle frames */
> > > > val = usecs_to_jiffies(intel_get_frame_time_us(crtc_state) * 6);
> > > > dev_priv->psr.dc3co_exit_delay = val;
> > > > - dev_priv->psr.psr2_sel_fetch_enabled =
> > > > crtc_state->enable_psr2_sel_fetch;
> > > > + dev_priv->psr.psr2_sel_fetch_enabled =
> > > > crtc_state->enable_psr2_sel_fetch &&
> > > > +
> > > > dev_priv->psr.psr2_enabled;
> > > >
> > > > /*
> > > > * If a PSR error happened and the driver is reloaded, the
> > > > EDP_PSR_IIR
> > > > @@ -1178,7 +1180,7 @@ void intel_psr2_program_trans_man_trk_ctl(const
> > > > struct intel_crtc_state *crtc_st
> > > > struct i915_psr *psr = &dev_priv->psr;
> > > >
> > > > if (!HAS_PSR2_SEL_FETCH(dev_priv) ||
> > > > - !crtc_state->enable_psr2_sel_fetch)
> > > > + !dev_priv->psr.psr2_sel_fetch_enabled)
> > > > return;
> > > >
> > > > intel_de_write(dev_priv, PSR2_MAN_TRK_CTL(psr->transcoder),
> > > > @@ -1189,8 +1191,9 @@ void intel_psr2_sel_fetch_update(struct
> > > > intel_atomic_state *state,
> > > > struct intel_crtc *crtc)
> > > > {
> > > > struct intel_crtc_state *crtc_state =
> > > > intel_atomic_get_new_crtc_state(state, crtc);
> > > > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > >
> > > > - if (!crtc_state->enable_psr2_sel_fetch)
> > > > + if (!dev_priv->psr.psr2_sel_fetch_enabled)
> > >
> > > This looks rather sketchy. AFAICS this gets called during atomic_check()
> > > so looking at stuff outside the crtc state is very suspicious.
> >
> > This is called after the functions that change the PSR state so no issues,
> > also we can't really on information in CRTC state, as PSR is only enabled
> > if supported by state, i915 PSR parameter and PSR debug fs value.
>
> I see it getting called from intel_crtc_atomic_check(). Confused.
> Am I missing some other patches?
It is set from intel_psr_disable(), intel_psr_enable() and intel_psr_update()
all executed before intel_psr2_sel_fetch_update()
intel_enable_ddi()
intel_enable_ddi_dp()
intel_psr_enable()
intel_update_crtc() {
if (!modeset) {
intel_encoders_update_pipe()
encoder->update_pipe() / intel_ddi_update_pipe()
intel_ddi_update_pipe_dp()
intel_psr_update()
}
...
skl_update_planes_on_crtc(state, crtc);
intel_update_plane()
plane->update_plane() / skl_update_plane()
skl_program_plane()
intel_psr2_sel_fetch_update()
}
>
> > > > return;
> > > >
> > > > crtc_state->psr2_man_track_ctl = PSR2_MAN_TRK_CTL_ENABLE |
> > > > --
> > > > 2.28.0
> > >
> > >
>
>
_
[Intel-gfx] [patch 03/13] preempt: Clenaup PREEMPT_COUNT leftovers
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
removed. Cleanup the leftovers before doing so.
Signed-off-by: Thomas Gleixner
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Juri Lelli
Cc: Vincent Guittot
Cc: Dietmar Eggemann
Cc: Steven Rostedt
Cc: Ben Segall
Cc: Mel Gorman
Cc: Daniel Bristot de Oliveira
---
include/linux/preempt.h | 37 -
1 file changed, 4 insertions(+), 33 deletions(-)
--- a/include/linux/preempt.h
+++ b/include/linux/preempt.h
@@ -56,8 +56,7 @@
#define PREEMPT_DISABLED (PREEMPT_DISABLE_OFFSET + PREEMPT_ENABLED)
/*
- * Disable preemption until the scheduler is running -- use an unconditional
- * value so that it also works on !PREEMPT_COUNT kernels.
+ * Disable preemption until the scheduler is running.
*
* Reset by
start_kernel()->sched_init()->init_idle()->init_idle_preempt_count().
*/
@@ -69,7 +68,6 @@
*
*preempt_count() == 2*PREEMPT_DISABLE_OFFSET
*
- * Note: PREEMPT_DISABLE_OFFSET is 0 for !PREEMPT_COUNT kernels.
* Note: See finish_task_switch().
*/
#define FORK_PREEMPT_COUNT (2*PREEMPT_DISABLE_OFFSET + PREEMPT_ENABLED)
@@ -106,11 +104,7 @@
/*
* The preempt_count offset after preempt_disable();
*/
-#if defined(CONFIG_PREEMPT_COUNT)
-# define PREEMPT_DISABLE_OFFSETPREEMPT_OFFSET
-#else
-# define PREEMPT_DISABLE_OFFSET0
-#endif
+#define PREEMPT_DISABLE_OFFSET PREEMPT_OFFSET
/*
* The preempt_count offset after spin_lock()
@@ -122,8 +116,8 @@
*
* spin_lock_bh()
*
- * Which need to disable both preemption (CONFIG_PREEMPT_COUNT) and
- * softirqs, such that unlock sequences of:
+ * Which need to disable both preemption and softirqs, such that unlock
+ * sequences of:
*
* spin_unlock();
* local_bh_enable();
@@ -164,8 +158,6 @@ extern void preempt_count_sub(int val);
#define preempt_count_inc() preempt_count_add(1)
#define preempt_count_dec() preempt_count_sub(1)
-#ifdef CONFIG_PREEMPT_COUNT
-
#define preempt_disable() \
do { \
preempt_count_inc(); \
@@ -231,27 +223,6 @@ do { \
__preempt_count_dec(); \
} while (0)
-#else /* !CONFIG_PREEMPT_COUNT */
-
-/*
- * Even if we don't have any preemption, we need preempt disable/enable
- * to be barriers, so that we don't have things like get_user/put_user
- * that can cause faults and scheduling migrate into our preempt-protected
- * region.
- */
-#define preempt_disable() barrier()
-#define sched_preempt_enable_no_resched() barrier()
-#define preempt_enable_no_resched()barrier()
-#define preempt_enable() barrier()
-#define preempt_check_resched()do { } while (0)
-
-#define preempt_disable_notrace() barrier()
-#define preempt_enable_no_resched_notrace()barrier()
-#define preempt_enable_notrace() barrier()
-#define preemptible() 0
-
-#endif /* CONFIG_PREEMPT_COUNT */
-
#ifdef MODULE
/*
* Modules have no business playing preemption tricks.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [patch 00/13] preempt: Make preempt count unconditional
Folks! While working on various preempt count related things, I stumbled (again) over the inconsistency of our preempt count handling. The handling of preempt_count() is inconsistent accross kernel configurations. On kernels which have PREEMPT_COUNT=n preempt_disable/enable() and the lock/unlock functions are not affecting the preempt count, only local_bh_disable/enable() and _bh variants of locking, soft interrupt delivery, hard interrupt and NMI context affect it. It's therefore impossible to have a consistent set of checks which provide information about the context in which a function is called. In many cases it makes sense to have seperate functions for seperate contexts, but there are valid reasons to avoid that and handle different calling contexts conditionally. The lack of such indicators which work on all kernel configuratios is a constant source of trouble because developers either do not understand the implications or try to work around this inconsistency in weird ways. Neither seem these issues be catched by reviewers and testing. Recently merged code does: gfp = preemptible() ? GFP_KERNEL : GFP_ATOMIC; Looks obviously correct, except for the fact that preemptible() is unconditionally false for CONFIF_PREEMPT_COUNT=n, i.e. all allocations in that code use GFP_ATOMIC on such kernels. Attempts to make preempt count unconditional and consistent have been rejected in the past with handwaving performance arguments. Freshly conducted benchmarks did not reveal any measurable impact from enabling preempt count unconditionally. On kernels with CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY the preempt count is only incremented and decremented but the result of the decrement is not tested. Contrary to that enabling CONFIG_PREEMPT which tests the result has a small but measurable impact due to the conditional branch/call. It's about time to make essential functionality of the kernel consistent accross the various preemption models. The series is also available from git: git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git preempt That's the first part of a larger effort related to preempt count: 1) The analysis of the usage sites of in_interrupt(), in_atomic(), in_softirq() is still ongoing, but so far the number of buggy users is clearly the vast majority. There will be seperate patch series (currently 46 and counting) to address these issues once the analysis is complete in the next days. 2) The long discussed state tracking of local irq disable in preempt count which accounts interrupt disabled sections as atomic and avoids issuing costly instructions (sti, cli, popf or their non X86 counterparts) when the state does not change, i.e. nested irq_save() or irq_restore(). I have this working on X86 already and contrary to my earlier attempts this was reasonably straight forward due to the recent entry/exit code consolidation. What I've not done yet is to optimize the preempt count handling of the [un]lock_irq* operations so they handle the interrupt disabled state and the preempt count modification in one go. That's an obvious add on, but correctness first ... 3) Lazy interrupt disabling as a straight forward extension to #2. This avoids the actual disabling at the CPU level completely and catches an incoming interrupt in the low level entry code, modifies the interrupt disabled state on the return stack, notes the interrupt as pending in software and raises it again when interrupts are reenabled. This has still a few issues which I'm hunting down (cpuidle is unhappy ...) Thanks, tglx --- arch/arm/include/asm/assembler.h | 11 -- arch/arm/kernel/iwmmxt.S |2 arch/arm/mach-ep93xx/crunch-bits.S |2 arch/xtensa/kernel/entry.S |2 drivers/gpu/drm/i915/Kconfig.debug |1 drivers/gpu/drm/i915/i915_utils.h|3 include/linux/bit_spinlock.h |4 - include/linux/lockdep.h |6 - include/linux/pagemap.h |4 - include/linux/preempt.h | 37 +- include/linux/uaccess.h |6 - kernel/Kconfig.preempt |4 - kernel/sched/core.c |6 - lib/Kconfig.debug|3 lib/Kconfig.debug.rej| 14 +-- tools/testing/selftests/rcutorture/configs/rcu/SRCU-t|1 tools/testing/selftests/rcutorture/configs/rcu/SRCU-u|1 tools/testing/selftests/rcutorture/
[Intel-gfx] [patch 10/13] xtensa: Clenaup PREEMPT_COUNT leftovers
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be removed. Cleanup the leftovers before doing so. Signed-off-by: Thomas Gleixner Cc: Chris Zankel Cc: Max Filippov Cc: linux-xte...@linux-xtensa.org --- arch/xtensa/kernel/entry.S |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/xtensa/kernel/entry.S +++ b/arch/xtensa/kernel/entry.S @@ -819,7 +819,7 @@ ENTRY(debug_exception) * preemption if we have HW breakpoints to preserve DEBUGCAUSE.DBNUM * meaning. */ -#if defined(CONFIG_PREEMPT_COUNT) && defined(CONFIG_HAVE_HW_BREAKPOINT) +#ifdef CONFIG_HAVE_HW_BREAKPOINT GET_THREAD_INFO(a2, a1) l32ia3, a2, TI_PRE_COUNT addia3, a3, 1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 00/13] preempt: Make preempt count unconditional
On Mon, 14 Sep 2020 22:42:09 +0200 Thomas Gleixner wrote: > 21 files changed, 23 insertions(+), 92 deletions(-) This alone makes it look promising, and hopefully acceptable by Linus :-) -- Steve ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [patch 11/13] drm/i915: Clenaup PREEMPT_COUNT leftovers
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
removed. Cleanup the leftovers before doing so.
Signed-off-by: Thomas Gleixner
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: David Airlie
Cc: Daniel Vetter
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/i915/Kconfig.debug |1 -
drivers/gpu/drm/i915/i915_utils.h |3 +--
2 files changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -20,7 +20,6 @@ config DRM_I915_DEBUG
bool "Enable additional driver debugging"
depends on DRM_I915
select DEBUG_FS
- select PREEMPT_COUNT
select I2C_CHARDEV
select STACKDEPOT
select DRM_DP_AUX_CHARDEV
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -337,8 +337,7 @@ wait_remaining_ms_from_jiffies(unsigned
(Wmax))
#define wait_for(COND, MS) _wait_for((COND), (MS) * 1000, 10, 1000)
-/* If CONFIG_PREEMPT_COUNT is disabled, in_atomic() always reports false. */
-#if defined(CONFIG_DRM_I915_DEBUG) && defined(CONFIG_PREEMPT_COUNT)
+#ifdef CONFIG_DRM_I915_DEBUG
# define _WAIT_FOR_ATOMIC_CHECK(ATOMIC) WARN_ON_ONCE((ATOMIC) && !in_atomic())
#else
# define _WAIT_FOR_ATOMIC_CHECK(ATOMIC) do { } while (0)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [patch 07/13] uaccess: Clenaup PREEMPT_COUNT leftovers
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be removed. Cleanup the leftovers before doing so. Signed-off-by: Thomas Gleixner --- include/linux/uaccess.h |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/include/linux/uaccess.h +++ b/include/linux/uaccess.h @@ -230,9 +230,9 @@ static inline bool pagefault_disabled(vo * * This function should only be used by the fault handlers. Other users should * stick to pagefault_disabled(). - * Please NEVER use preempt_disable() to disable the fault handler. With - * !CONFIG_PREEMPT_COUNT, this is like a NOP. So the handler won't be disabled. - * in_atomic() will report different values based on !CONFIG_PREEMPT_COUNT. + * + * Please NEVER use preempt_disable() or local_irq_disable() to disable the + * fault handler. */ #define faulthandler_disabled() (pagefault_disabled() || in_atomic()) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [patch 04/13] lockdep: Clenaup PREEMPT_COUNT leftovers
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
removed. Cleanup the leftovers before doing so.
Signed-off-by: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
---
include/linux/lockdep.h |6 ++
lib/Kconfig.debug |1 -
2 files changed, 2 insertions(+), 5 deletions(-)
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -585,16 +585,14 @@ do {
\
#define lockdep_assert_preemption_enabled()\
do { \
- WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_COUNT) && \
-debug_locks&& \
+ WARN_ON_ONCE(debug_locks&& \
(preempt_count() != 0 || \
!raw_cpu_read(hardirqs_enabled)));\
} while (0)
#define lockdep_assert_preemption_disabled() \
do { \
- WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_COUNT) && \
-debug_locks&& \
+ WARN_ON_ONCE(debug_locks&& \
(preempt_count() == 0 && \
raw_cpu_read(hardirqs_enabled))); \
} while (0)
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1161,7 +1161,6 @@ config PROVE_LOCKING
select DEBUG_RWSEMS
select DEBUG_WW_MUTEX_SLOWPATH
select DEBUG_LOCK_ALLOC
- select PREEMPT_COUNT
select TRACE_IRQFLAGS
default n
help
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [patch 12/13] rcutorture: Clenaup PREEMPT_COUNT leftovers
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be removed. Cleanup the leftovers before doing so. Signed-off-by: Thomas Gleixner Cc: "Paul E. McKenney" Cc: Josh Triplett Cc: Steven Rostedt Cc: Mathieu Desnoyers Cc: Lai Jiangshan Cc: Shuah Khan Cc: r...@vger.kernel.org Cc: linux-kselft...@vger.kernel.org --- tools/testing/selftests/rcutorture/configs/rcu/SRCU-t|1 - tools/testing/selftests/rcutorture/configs/rcu/SRCU-u|1 - tools/testing/selftests/rcutorture/configs/rcu/TINY01|1 - tools/testing/selftests/rcutorture/doc/TINY_RCU.txt |5 ++--- tools/testing/selftests/rcutorture/doc/TREE_RCU-kconfig.txt |1 - tools/testing/selftests/rcutorture/formal/srcu-cbmc/src/config.h |1 - 6 files changed, 2 insertions(+), 8 deletions(-) --- a/tools/testing/selftests/rcutorture/configs/rcu/SRCU-t +++ b/tools/testing/selftests/rcutorture/configs/rcu/SRCU-t @@ -7,4 +7,3 @@ CONFIG_RCU_TRACE=n CONFIG_DEBUG_LOCK_ALLOC=n CONFIG_DEBUG_OBJECTS_RCU_HEAD=n CONFIG_DEBUG_ATOMIC_SLEEP=y -#CHECK#CONFIG_PREEMPT_COUNT=y --- a/tools/testing/selftests/rcutorture/configs/rcu/SRCU-u +++ b/tools/testing/selftests/rcutorture/configs/rcu/SRCU-u @@ -7,4 +7,3 @@ CONFIG_RCU_TRACE=n CONFIG_DEBUG_LOCK_ALLOC=y CONFIG_PROVE_LOCKING=y CONFIG_DEBUG_OBJECTS_RCU_HEAD=n -CONFIG_PREEMPT_COUNT=n --- a/tools/testing/selftests/rcutorture/configs/rcu/TINY01 +++ b/tools/testing/selftests/rcutorture/configs/rcu/TINY01 @@ -10,4 +10,3 @@ CONFIG_RCU_TRACE=n #CHECK#CONFIG_RCU_STALL_COMMON=n CONFIG_DEBUG_LOCK_ALLOC=n CONFIG_DEBUG_OBJECTS_RCU_HEAD=n -CONFIG_PREEMPT_COUNT=n --- a/tools/testing/selftests/rcutorture/doc/TINY_RCU.txt +++ b/tools/testing/selftests/rcutorture/doc/TINY_RCU.txt @@ -3,11 +3,10 @@ This document gives a brief rationale fo Kconfig Parameters: -CONFIG_DEBUG_LOCK_ALLOC -- Do all three and none of the three. -CONFIG_PREEMPT_COUNT +CONFIG_DEBUG_LOCK_ALLOC -- Do both and none of the two. CONFIG_RCU_TRACE -The theory here is that randconfig testing will hit the other six possible +The theory here is that randconfig testing will hit the other two possible combinations of these parameters. --- a/tools/testing/selftests/rcutorture/doc/TREE_RCU-kconfig.txt +++ b/tools/testing/selftests/rcutorture/doc/TREE_RCU-kconfig.txt @@ -43,7 +43,6 @@ CONFIG_64BIT Used only to check CONFIG_RCU_FANOUT value, inspection suffices. -CONFIG_PREEMPT_COUNT CONFIG_PREEMPT_RCU Redundant with CONFIG_PREEMPT, ignore. --- a/tools/testing/selftests/rcutorture/formal/srcu-cbmc/src/config.h +++ b/tools/testing/selftests/rcutorture/formal/srcu-cbmc/src/config.h @@ -8,7 +8,6 @@ #undef CONFIG_HOTPLUG_CPU #undef CONFIG_MODULES #undef CONFIG_NO_HZ_FULL_SYSIDLE -#undef CONFIG_PREEMPT_COUNT #undef CONFIG_PREEMPT_RCU #undef CONFIG_PROVE_RCU #undef CONFIG_RCU_NOCB_CPU ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [patch 05/13] mm/pagemap: Clenaup PREEMPT_COUNT leftovers
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
removed. Cleanup the leftovers before doing so.
Signed-off-by: Thomas Gleixner
Cc: Andrew Morton
Cc: linux...@kvack.org
---
include/linux/pagemap.h |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -168,9 +168,7 @@ void release_pages(struct page **pages,
static inline int __page_cache_add_speculative(struct page *page, int count)
{
#ifdef CONFIG_TINY_RCU
-# ifdef CONFIG_PREEMPT_COUNT
- VM_BUG_ON(!in_atomic() && !irqs_disabled());
-# endif
+ VM_BUG_ON(preemptible())
/*
* Preempt must be disabled here - we rely on rcu_read_lock doing
* this for us.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [patch 13/13] preempt: Remove PREEMPT_COUNT from Kconfig
All conditionals and irritations are gone. Signed-off-by: Thomas Gleixner --- kernel/Kconfig.preempt |3 --- 1 file changed, 3 deletions(-) --- a/kernel/Kconfig.preempt +++ b/kernel/Kconfig.preempt @@ -74,8 +74,5 @@ config PREEMPT_RT endchoice -config PREEMPT_COUNT - def_bool y - config PREEMPTION bool ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [patch 02/13] preempt: Make preempt count unconditional
The handling of preempt_count() is inconsistent accross kernel configurations. On kernels which have PREEMPT_COUNT=n preempt_disable/enable() and the lock/unlock functions are not affecting the preempt count, only local_bh_disable/enable() and _bh variants of locking, soft interrupt delivery, hard interrupt and NMI context affect it. It's therefore impossible to have a consistent set of checks which provide information about the context in which a function is called. In many cases it makes sense to have seperate functions for seperate contexts, but there are valid reasons to avoid that and handle different calling contexts conditionally. The lack of such indicators which work on all kernel configuratios is a constant source of trouble because developers either do not understand the implications or try to work around this inconsistency in weird ways. Neither seem these issues be catched by reviewers and testing. Recently merged code does: gfp = preemptible() ? GFP_KERNEL : GFP_ATOMIC; Looks obviously correct, except for the fact that preemptible() is unconditionally false for CONFIF_PREEMPT_COUNT=n, i.e. all allocations in that code use GFP_ATOMIC on such kernels. Attempts to make preempt count unconditional and consistent have been rejected in the past with handwaving performance arguments. Freshly conducted benchmarks did not reveal any measurable impact from enabling preempt count unconditionally. On kernels with CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY the preempt count is only incremented and decremented but the result of the decrement is not tested. Contrary to that enabling CONFIG_PREEMPT which tests the result has a small but measurable impact due to the conditional branch/call. It's about time to make essential functionality of the kernel consistent accross the various preemption models. Enable CONFIG_PREEMPT_COUNT unconditionally. Follow up changes will remove the #ifdeffery and remove the config option at the end. Signed-off-by: Thomas Gleixner --- kernel/Kconfig.preempt |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/kernel/Kconfig.preempt +++ b/kernel/Kconfig.preempt @@ -75,8 +75,7 @@ config PREEMPT_RT endchoice config PREEMPT_COUNT - bool + def_bool y config PREEMPTION bool - select PREEMPT_COUNT ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [patch 09/13] ARM: Clenaup PREEMPT_COUNT leftovers
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be removed. Cleanup the leftovers before doing so. Signed-off-by: Thomas Gleixner Cc: Russell King Cc: linux-arm-ker...@lists.infradead.org --- arch/arm/include/asm/assembler.h | 11 --- arch/arm/kernel/iwmmxt.S |2 -- arch/arm/mach-ep93xx/crunch-bits.S |2 -- 3 files changed, 15 deletions(-) --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -212,7 +212,6 @@ /* * Increment/decrement the preempt count. */ -#ifdef CONFIG_PREEMPT_COUNT .macro inc_preempt_count, ti, tmp ldr \tmp, [\ti, #TI_PREEMPT]@ get preempt count add \tmp, \tmp, #1 @ increment it @@ -229,16 +228,6 @@ get_thread_info \ti dec_preempt_count \ti, \tmp .endm -#else - .macro inc_preempt_count, ti, tmp - .endm - - .macro dec_preempt_count, ti, tmp - .endm - - .macro dec_preempt_count_ti, ti, tmp - .endm -#endif #define USERL(l, x...) \ : x; \ --- a/arch/arm/kernel/iwmmxt.S +++ b/arch/arm/kernel/iwmmxt.S @@ -94,9 +94,7 @@ ENTRY(iwmmxt_task_enable) mov r2, r2 @ cpwait bl concan_save -#ifdef CONFIG_PREEMPT_COUNT get_thread_info r10 -#endif 4: dec_preempt_count r10, r3 ret r9 @ normal exit from exception --- a/arch/arm/mach-ep93xx/crunch-bits.S +++ b/arch/arm/mach-ep93xx/crunch-bits.S @@ -191,9 +191,7 @@ ENTRY(crunch_task_enable) cfldr64 mvdx15, [r0, #CRUNCH_MVDX15] 1: -#ifdef CONFIG_PREEMPT_COUNT get_thread_info r10 -#endif 2: dec_preempt_count r10, r3 ret lr ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [patch 01/13] lib/debug: Remove pointless ARCH_NO_PREEMPT dependencies
ARCH_NO_PREEMPT disables the selection of CONFIG_PREEMPT_VOLUNTARY and CONFIG_PREEMPT, but architectures which set this config option still support preempt count for hard and softirq accounting. There is absolutely no reason to prevent lockdep from using the preempt counter nor is there a reason to prevent the enablement of CONFIG_DEBUG_ATOMIC_SLEEP on such architectures. Remove the dependencies, which affects ALPHA, HEXAGON, M68K and UM. Signed-off-by: Thomas Gleixner Cc: Richard Henderson Cc: Ivan Kokshaysky Cc: Matt Turner Cc: linux-al...@vger.kernel.org Cc: Jeff Dike Cc: Richard Weinberger Cc: Anton Ivanov Cc: linux...@lists.infradead.org Cc: Brian Cain Cc: linux-hexa...@vger.kernel.org Cc: Geert Uytterhoeven Cc: linux-m...@lists.linux-m68k.org --- lib/Kconfig.debug |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1161,7 +1161,7 @@ config PROVE_LOCKING select DEBUG_RWSEMS select DEBUG_WW_MUTEX_SLOWPATH select DEBUG_LOCK_ALLOC - select PREEMPT_COUNT if !ARCH_NO_PREEMPT + select PREEMPT_COUNT select TRACE_IRQFLAGS default n help @@ -1323,7 +1323,6 @@ config DEBUG_ATOMIC_SLEEP bool "Sleep inside atomic section checking" select PREEMPT_COUNT depends on DEBUG_KERNEL - depends on !ARCH_NO_PREEMPT help If you say Y here, various routines which may sleep will become very noisy if they are called inside atomic sections: when a spinlock is ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [patch 08/13] sched: Clenaup PREEMPT_COUNT leftovers
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be removed. Cleanup the leftovers before doing so. Signed-off-by: Thomas Gleixner Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Juri Lelli Cc: Vincent Guittot Cc: Dietmar Eggemann Cc: Steven Rostedt Cc: Ben Segall Cc: Mel Gorman Cc: Daniel Bristot de Oliveira --- kernel/sched/core.c |6 +- lib/Kconfig.debug |1 - 2 files changed, 1 insertion(+), 6 deletions(-) --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -3706,8 +3706,7 @@ asmlinkage __visible void schedule_tail( * finish_task_switch() for details. * * finish_task_switch() will drop rq->lock() and lower preempt_count -* and the preempt_enable() will end up enabling preemption (on -* PREEMPT_COUNT kernels). +* and the preempt_enable() will end up enabling preemption. */ rq = finish_task_switch(prev); @@ -7311,9 +7310,6 @@ void __cant_sleep(const char *file, int if (irqs_disabled()) return; - if (!IS_ENABLED(CONFIG_PREEMPT_COUNT)) - return; - if (preempt_count() > preempt_offset) return; --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1320,7 +1320,6 @@ config DEBUG_LOCKDEP config DEBUG_ATOMIC_SLEEP bool "Sleep inside atomic section checking" - select PREEMPT_COUNT depends on DEBUG_KERNEL help If you say Y here, various routines which may sleep will become very ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [patch 06/13] locking/bitspinlock: Clenaup PREEMPT_COUNT leftovers
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
removed. Cleanup the leftovers before doing so.
Signed-off-by: Thomas Gleixner
---
include/linux/bit_spinlock.h |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/include/linux/bit_spinlock.h
+++ b/include/linux/bit_spinlock.h
@@ -90,10 +90,8 @@ static inline int bit_spin_is_locked(int
{
#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK)
return test_bit(bitnum, addr);
-#elif defined CONFIG_PREEMPT_COUNT
- return preempt_count();
#else
- return 1;
+ return preempt_count();
#endif
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v6 00/24] tests/core_hotunplug: Fixes and enhancements
igt@core_hotunplug@hotrebind-lateclose test is not yet in CI bug log. Otherwise I filed the issue https://gitlab.freedesktop.org/drm/intel/-/issues/2464 Thanks, Lakshmi. -Original Message- From: Janusz Krzysztofik Sent: Monday, September 14, 2020 12:31 PM To: Winiarski, Michal ; igt-...@lists.freedesktop.org Cc: Michał Winiarski ; intel-gfx@lists.freedesktop.org; Latvala, Petri ; Vudum, Lakshminarayana Subject: Re: [Intel-gfx] [PATCH i-g-t v6 00/24] tests/core_hotunplug: Fixes and enhancements On Mon, 2020-09-14 at 20:18 +0200, Michał Winiarski wrote: > Quoting Janusz Krzysztofik (2020-09-11 12:30:15) > > Clean up the test code, add some new basic subtests, then unblock > > unbind test variants. > > > > No incompletes / aborts nor subsequently run test issues have been > > reported by Trybot. The hotrebind-lateclose subtest fails on a so > > far unidentified driver sysfs issue but the device is fully > > recovered and left in a usable state. Perceived Haswell/Broadwell > > issue with audio power management has been worked around and its > > potential occurrence is reported as an IGT warning. > > > > Series changelog: > > v2: New patch "Un-blocklist *bind* subtests added. > > v3: Patch "Follow failed subtests with healthcheck" renamed to "Recover > > from subtest failures". > > - a new patche "Clean up device open error handling" added, an old > > patch "Fix missing newline" obsoleted by the new one dropped, > > - other new patches added: > > - "Let the driver time out essential sysfs operations", > > - "More thorough i915 healthcheck and recovery", > > - a patch "Add 'lateclose before restore' variants" from another > > series included. > > v4: Optional patch "Duplicate debug messages in dmesg" from another > > series included. > > v5: New patch added with Haswell audio related kernel warning worked > > around and replaced with an IGT warning to preserve visibility of > > the issue. > > v6: New patch added for also checking health of render device nodes, > > - new patch added with proper handling of health check before late > > close, > > - inclusion of unbind-rebind scenario to BAT scope proposed. > > > > @Michał: Since some patch updates are trivial, I've preserved your > > v1/v2 Reviewd-by: except for patches with non-trivial changes, where > > I marked your R-b as v1/v2 applicable. Please have a look and > > confirm if you are still OK with them. > > Feel free to add: > Reviewed-by: Michał Winiarski > > For the whole series (with the exception of intel-ci part). Pushed. @Petri, @Michał - thank you for review. @Lakshmi: - please open a new bug for the issue reported by the igt@core _hotunplug@hotrebind-lateclose subtest failing on all platforms, - IGT warning reported by igt@core_hotunplug@*bind* on Haswell and Broadwell platofrms is caused by the same issue as the one reported now in a similar way on Haswell by igt@device_reset@unbind-reset-rebind - please update the associated filter so it covers all those tests. Thanks, Janusz > > -Michał > > > @Tvrtko: As I already asked before, please support my attempt to > > remove the unbind test variants from the blocklist. > > > > @Petri, @Martin: Assuming CI results will be as good as those > > obtained on Trybot, please give me your green light for merging this > > series if you have no objections. > > > > Thanks, > > Janusz > > > > Janusz Krzysztofik (24): > > tests/core_hotunplug: Use igt_assert_fd() > > tests/core_hotunplug: Constify dev_bus_addr string > > tests/core_hotunplug: Clean up device open error handling > > tests/core_hotunplug: Consolidate duplicated debug messages > > tests/core_hotunplug: Assert successful device filter application > > tests/core_hotunplug: Maintain a single data structure instance > > tests/core_hotunplug: Pass errors via a data structure field > > tests/core_hotunplug: Handle device close errors > > tests/core_hotunplug: Prepare invariant data once per test run > > tests/core_hotunplug: Skip selectively on sysfs close errors > > tests/core_hotunplug: Recover from subtest failures > > tests/core_hotunplug: Fail subtests on device close errors > > tests/core_hotunplug: Let the driver time out essential sysfs > > operations > > tests/core_hotunplug: Process return values of sysfs operations > > tests/core_hotunplug: Assert expected device presence/absence > > tests/core_hotunplug: Explicitly ignore unused return values > > tests/core_hotunplug: Also check health of render device node > > tests/core_hotunplug: More thorough i915 healthcheck and recovery > > tests/core_hotunplug: Add 'lateclose before restore' variants > > tests/core_hotunplug: Check health both before and after late close > > tests/core_hotunplug: HSW/BDW audio issue workaround > > tests/core_hotunplug: Duplicate debug messages in dmesg > > tests/core_hotunplug: Un-blocklist *bind* subtests > > tests/core_hotun
Re: [Intel-gfx] [PATCH 2/4] drm/i915/display: Fix state of PSR2 sub features
On Mon, Sep 14, 2020 at 07:57:34PM +, Souza, Jose wrote:
> On Mon, 2020-09-14 at 17:24 +0300, Ville Syrjälä wrote:
> > On Mon, Aug 31, 2020 at 06:09:22PM -0700, José Roberto de Souza wrote:
> > > In case PSR2 is disabled by debugfs dc3co_enabled and
> > > psr2_sel_fetch_enabled were still being set causing some code paths
> > > to be executed were it should not.
> > > We have tests for PSR1 and PSR2 so keep those features disabled when
> > > PSR1 is active but PSR2 is supported is important.
> > >
> > > Cc: Gwan-gyeong Mun <
> > > gwan-gyeong@intel.com
> > > >
> > > Cc: Ville Syrjälä <
> > > ville.syrj...@linux.intel.com
> > > >
> > > Signed-off-by: José Roberto de Souza <
> > > jose.so...@intel.com
> > > >
> > > ---
> > > drivers/gpu/drm/i915/display/intel_psr.c | 11 +++
> > > 1 file changed, 7 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index 4e09ae61d4aa..6698d0209879 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > @@ -962,12 +962,14 @@ static void intel_psr_enable_locked(struct
> > > drm_i915_private *dev_priv,
> > > dev_priv->psr.psr2_enabled = intel_psr2_enabled(dev_priv, crtc_state);
> > > dev_priv->psr.busy_frontbuffer_bits = 0;
> > > dev_priv->psr.pipe = to_intel_crtc(crtc_state->uapi.crtc)->pipe;
> > > - dev_priv->psr.dc3co_enabled = !!crtc_state->dc3co_exitline;
> > > + dev_priv->psr.dc3co_enabled = !!crtc_state->dc3co_exitline &&
> > > + dev_priv->psr.psr2_enabled;
> > > dev_priv->psr.transcoder = crtc_state->cpu_transcoder;
> > > /* DC5/DC6 requires at least 6 idle frames */
> > > val = usecs_to_jiffies(intel_get_frame_time_us(crtc_state) * 6);
> > > dev_priv->psr.dc3co_exit_delay = val;
> > > - dev_priv->psr.psr2_sel_fetch_enabled =
> > > crtc_state->enable_psr2_sel_fetch;
> > > + dev_priv->psr.psr2_sel_fetch_enabled =
> > > crtc_state->enable_psr2_sel_fetch &&
> > > +dev_priv->psr.psr2_enabled;
> > >
> > > /*
> > >* If a PSR error happened and the driver is reloaded, the EDP_PSR_IIR
> > > @@ -1178,7 +1180,7 @@ void intel_psr2_program_trans_man_trk_ctl(const
> > > struct intel_crtc_state *crtc_st
> > > struct i915_psr *psr = &dev_priv->psr;
> > >
> > > if (!HAS_PSR2_SEL_FETCH(dev_priv) ||
> > > - !crtc_state->enable_psr2_sel_fetch)
> > > + !dev_priv->psr.psr2_sel_fetch_enabled)
> > > return;
> > >
> > > intel_de_write(dev_priv, PSR2_MAN_TRK_CTL(psr->transcoder),
> > > @@ -1189,8 +1191,9 @@ void intel_psr2_sel_fetch_update(struct
> > > intel_atomic_state *state,
> > >struct intel_crtc *crtc)
> > > {
> > > struct intel_crtc_state *crtc_state =
> > > intel_atomic_get_new_crtc_state(state, crtc);
> > > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > >
> > > - if (!crtc_state->enable_psr2_sel_fetch)
> > > + if (!dev_priv->psr.psr2_sel_fetch_enabled)
> >
> > This looks rather sketchy. AFAICS this gets called during atomic_check()
> > so looking at stuff outside the crtc state is very suspicious.
>
> This is called after the functions that change the PSR state so no issues,
> also we can't really on information in CRTC state, as PSR is only enabled
> if supported by state, i915 PSR parameter and PSR debug fs value.
I see it getting called from intel_crtc_atomic_check(). Confused.
Am I missing some other patches?
>
> >
> > > return;
> > >
> > > crtc_state->psr2_man_track_ctl = PSR2_MAN_TRK_CTL_ENABLE |
> > > --
> > > 2.28.0
> >
> >
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6 11/11] drm/i915/display: [NOT FOR MERGE] Reduce blanking to support 4k60@10bpp for LSPCON
Blanking needs to be reduced to incorporate DP and HDMI timing/link
bandwidth limitations for CEA modes (4k@60 at 10 bpp). DP can drive
17.28Gbs while 4k modes (VIC97 etc) at 10 bpp required 17.8 Gbps.
This will cause mode to blank out. Reduced Htotal by shortening the
back porch and front porch within permissible limits.
Note: This is for reference for userspace, not to be merged in kernel.
v2: This is marked as Not for merge and the responsibilty to program
these custom timings will be on userspace. This patch is just for
reference purposes. This is based on Ville's recommendation.
v3: updated commit message.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 60bf01a8b4ad..c7ee13cd54e5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -640,8 +640,10 @@ intel_dp_mode_valid(struct drm_connector *connector,
{
struct intel_dp *intel_dp =
intel_attached_dp(to_intel_connector(connector));
struct intel_connector *intel_connector = to_intel_connector(connector);
+ struct intel_encoder *intel_encoder =
intel_attached_encoder(intel_connector);
struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
struct drm_i915_private *dev_priv = to_i915(connector->dev);
+ struct intel_lspcon *lspcon = enc_to_intel_lspcon(intel_encoder);
int target_clock = mode->clock;
int max_rate, mode_rate, max_lanes, max_link_clock;
int max_dotclk;
@@ -663,6 +665,21 @@ intel_dp_mode_valid(struct drm_connector *connector,
target_clock = fixed_mode->clock;
}
+ /*
+* Reducing Blanking to incorporate DP and HDMI timing/link bandwidth
+* limitations for CEA modes (4k@60 at 10 bpp). DP can drive 17.28Gbs
+* while 4k modes (VIC97 etc) at 10 bpp required 17.8 Gbps. This will
+* cause mode to blank out. Reduced Htotal by shortening the back porch
+* and front porch within permissible limits.
+*/
+ if (lspcon->active && lspcon->hdr_supported &&
+ mode->clock > 57) {
+ mode->clock = 57;
+ mode->htotal -= 180;
+ mode->hsync_start -= 72;
+ mode->hsync_end -= 72;
+ }
+
max_link_clock = intel_dp_max_link_rate(intel_dp);
max_lanes = intel_dp_max_lane_count(intel_dp);
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6 04/11] drm/i915/display: Enable BT2020 for HDR on LSPCON devices
Enable Colorspace as BT2020 if driving HDR content.Sending Colorimetry
data for HDR using AVI infoframe. LSPCON firmware expects this and though
SOC drives DP, for HDMI panel AVI infoframe is sent to the LSPCON device
which transfers the same to HDMI sink.
v2: Dropped state managed in drm core as per Jani Nikula's suggestion.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_lspcon.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index fd05210f4405..b0ca494f1110 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -507,6 +507,11 @@ void lspcon_read_infoframe(struct intel_encoder *encoder,
/* FIXME implement this */
}
+/* HDMI HDR Colorspace Spec Definitions */
+#define NORMAL_COLORIMETRY_MASK0x3
+#define EXTENDED_COLORIMETRY_MASK 0x7
+#define HDMI_COLORIMETRY_BT2020_YCC((3 << 0) | (6 << 2) | (0 << 5))
+
void lspcon_set_infoframes(struct intel_encoder *encoder,
bool enable,
const struct intel_crtc_state *crtc_state,
@@ -551,6 +556,19 @@ void lspcon_set_infoframes(struct intel_encoder *encoder,
HDMI_QUANTIZATION_RANGE_LIMITED :
HDMI_QUANTIZATION_RANGE_FULL);
+ /*
+* Set BT2020 colorspace if driving HDR data
+* ToDo: Make this generic and expose all colorspaces for lspcon
+*/
+ if (lspcon->active && lspcon->hdr_supported) {
+ frame.avi.colorimetry =
+ HDMI_COLORIMETRY_BT2020_YCC &
+ NORMAL_COLORIMETRY_MASK;
+ frame.avi.extended_colorimetry =
+ (HDMI_COLORIMETRY_BT2020_YCC >> 2) &
+EXTENDED_COLORIMETRY_MASK;
+ }
+
ret = hdmi_infoframe_pack(&frame, buf, sizeof(buf));
if (ret < 0) {
DRM_ERROR("Failed to pack AVI IF\n");
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6 05/11] drm/i915/display: Enable HDR for Parade based lspcon
Enable HDR for LSPCON based on Parade along with MCA.
Signed-off-by: Uma Shankar
Signed-off-by: Vipin Anand
---
drivers/gpu/drm/i915/display/intel_lspcon.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index b0ca494f1110..60863b825cc5 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -36,6 +36,7 @@
#define LSPCON_VENDOR_MCA_OUI 0x0060AD
#define DPCD_MCA_LSPCON_HDR_STATUS 0x70003
+#define DPCD_PARADE_LSPCON_HDR_STATUS 0x00511
/* AUX addresses to write MCA AVI IF */
#define LSPCON_MCA_AVI_IF_WRITE_OFFSET 0x5C0
@@ -112,16 +113,20 @@ static void lspcon_detect_hdr_capability(struct
intel_lspcon *lspcon)
container_of(lspcon, struct intel_digital_port, lspcon);
struct drm_device *dev = intel_dig_port->base.base.dev;
struct intel_dp *dp = lspcon_to_intel_dp(lspcon);
+ u32 lspcon_hdr_status_reg;
u8 hdr_caps;
int ret;
- /* Enable HDR for MCA based LSPCON devices */
if (lspcon->vendor == LSPCON_VENDOR_MCA)
- ret = drm_dp_dpcd_read(&dp->aux, DPCD_MCA_LSPCON_HDR_STATUS,
- &hdr_caps, 1);
+ lspcon_hdr_status_reg = DPCD_MCA_LSPCON_HDR_STATUS;
+ else if (lspcon->vendor == LSPCON_VENDOR_PARADE)
+ lspcon_hdr_status_reg = DPCD_PARADE_LSPCON_HDR_STATUS;
else
return;
+ ret = drm_dp_dpcd_read(&dp->aux, lspcon_hdr_status_reg,
+ &hdr_caps, 1);
+
if (ret < 0) {
drm_dbg_kms(dev, "hdr capability detection failed\n");
lspcon->hdr_supported = false;
@@ -465,14 +470,6 @@ void lspcon_write_infoframe(struct intel_encoder *encoder,
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
struct intel_lspcon *lspcon = enc_to_intel_lspcon(encoder);
- /*
-* Supporting HDR on MCA LSPCON
-* Todo: Add support for Parade later
-*/
- if (type == HDMI_PACKET_TYPE_GAMUT_METADATA &&
- lspcon->vendor != LSPCON_VENDOR_MCA)
- return;
-
switch (type) {
case HDMI_INFOFRAME_TYPE_AVI:
if (lspcon->vendor == LSPCON_VENDOR_MCA)
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6 02/11] drm/i915/display: Enable HDR on gen9 devices with MCA Lspcon
Gen9 hardware supports HDMI2.0 through LSPCON chips.
Extending HDR support for MCA LSPCON based GEN9 devices.
SOC will drive LSPCON as DP and send HDR metadata as standard
DP SDP packets. LSPCON will be set to operate in PCON mode,
will receive the metadata and create Dynamic Range and
Mastering Infoframe (DRM packets) and send it to HDR capable
HDMI sink devices.
v2: Re-used hsw infoframe write implementation for HDR metadata
for LSPCON as per Ville's suggestion.
v3: Addressed Jani Nikula's review comments.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 10 ++
drivers/gpu/drm/i915/display/intel_lspcon.c | 37 +++--
drivers/gpu/drm/i915/display/intel_lspcon.h | 5 ++-
3 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 0978b0d8f4c6..1e40ed473fb9 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -590,6 +590,16 @@ static u32 hsw_infoframes_enabled(struct intel_encoder
*encoder,
return val & mask;
}
+void lspcon_drm_write_infoframe(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ unsigned int type,
+ const void *frame, ssize_t len)
+{
+ drm_dbg_kms(encoder->base.dev, "Update HDR metadata for lspcon\n");
+ /* It uses the legacy hsw implementation for the same */
+ hsw_write_infoframe(encoder, crtc_state, type, frame, len);
+}
+
static const u8 infoframe_type_to_idx[] = {
HDMI_PACKET_TYPE_GENERAL_CONTROL,
HDMI_PACKET_TYPE_GAMUT_METADATA,
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index 8e8c7a02ab51..5e2d7ca1d20f 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -461,27 +461,42 @@ void lspcon_write_infoframe(struct intel_encoder *encoder,
unsigned int type,
const void *frame, ssize_t len)
{
- bool ret;
+ bool ret = true;
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
struct intel_lspcon *lspcon = enc_to_intel_lspcon(encoder);
- /* LSPCON only needs AVI IF */
- if (type != HDMI_INFOFRAME_TYPE_AVI)
+ /*
+* Supporting HDR on MCA LSPCON
+* Todo: Add support for Parade later
+*/
+ if (type == HDMI_PACKET_TYPE_GAMUT_METADATA &&
+ lspcon->vendor != LSPCON_VENDOR_MCA)
return;
- if (lspcon->vendor == LSPCON_VENDOR_MCA)
- ret = _lspcon_write_avi_infoframe_mca(&intel_dp->aux,
- frame, len);
- else
- ret = _lspcon_write_avi_infoframe_parade(&intel_dp->aux,
-frame, len);
+ switch (type) {
+ case HDMI_INFOFRAME_TYPE_AVI:
+ if (lspcon->vendor == LSPCON_VENDOR_MCA)
+ ret = _lspcon_write_avi_infoframe_mca(&intel_dp->aux,
+ frame, len);
+ else
+ ret = _lspcon_write_avi_infoframe_parade(&intel_dp->aux,
+frame, len);
+ break;
+ case HDMI_PACKET_TYPE_GAMUT_METADATA:
+ lspcon_drm_write_infoframe(encoder, crtc_state,
+ HDMI_PACKET_TYPE_GAMUT_METADATA,
+ frame, VIDEO_DIP_DATA_SIZE);
+ break;
+ default:
+ return;
+ }
if (!ret) {
- DRM_ERROR("Failed to write AVI infoframes\n");
+ DRM_ERROR("Failed to write infoframes\n");
return;
}
- DRM_DEBUG_DRIVER("AVI infoframes updated successfully\n");
+ DRM_DEBUG_DRIVER("Infoframes updated successfully\n");
}
void lspcon_read_infoframe(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.h
b/drivers/gpu/drm/i915/display/intel_lspcon.h
index 1cffe8a42a08..3fac05535731 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.h
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.h
@@ -34,5 +34,8 @@ u32 lspcon_infoframes_enabled(struct intel_encoder *encoder,
const struct intel_crtc_state *pipe_config);
void lspcon_ycbcr420_config(struct drm_connector *connector,
struct intel_crtc_state *crtc_state);
-
+void lspcon_drm_write_infoframe(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ unsigned int type,
+ const void *frame, ssize_t len);
#endif /* __INTEL_L
[Intel-gfx] [v6 08/11] drm/i915/lspcon: Create separate infoframe_enabled helper
Lspcon has Infoframes as well as DIP for HDR metadata(DRM Infoframe).
Create a separate mechanism for lspcon compared to HDMI in order to
address the same and ensure future scalability.
Suggested-by: Ville Syrjälä
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c| 10 +++---
drivers/gpu/drm/i915/display/intel_lspcon.c | 18 ++
drivers/gpu/drm/i915/display/intel_lspcon.h | 2 ++
3 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 6af080542c96..1b601b04f62f 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4307,6 +4307,7 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->uapi.crtc);
enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
u32 temp, flags = 0;
/* XXX: DSI transcoder paranoia */
@@ -4392,9 +4393,12 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
pipe_config->fec_enable);
}
- pipe_config->infoframes.enable |=
- intel_hdmi_infoframes_enabled(encoder, pipe_config);
-
+ if (dig_port->lspcon.active && dig_port->dp.has_hdmi_sink)
+ pipe_config->infoframes.enable |=
+ intel_lspcon_infoframes_enabled(encoder,
pipe_config);
+ else
+ pipe_config->infoframes.enable |=
+ intel_hdmi_infoframes_enabled(encoder,
pipe_config);
break;
case TRANS_DDI_MODE_SELECT_DP_MST:
pipe_config->output_types |= BIT(INTEL_OUTPUT_DP_MST);
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index ee77a5381cb5..5b2d96a80b49 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -30,6 +30,7 @@
#include "intel_display_types.h"
#include "intel_dp.h"
#include "intel_lspcon.h"
+#include "intel_hdmi.h"
/* LSPCON OUI Vendor ID(signatures) */
#define LSPCON_VENDOR_PARADE_OUI 0x001CF8
@@ -640,6 +641,23 @@ u32 lspcon_infoframes_enabled(struct intel_encoder
*encoder,
return val;
}
+u32 intel_lspcon_infoframes_enabled(struct intel_encoder *encoder,
+ const struct intel_crtc_state *pipe_config)
+{
+ struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+ u32 val, enabled = 0;
+
+ val = dig_port->infoframes_enabled(encoder, pipe_config);
+
+ if (val & VIDEO_DIP_ENABLE_AVI_HSW)
+ enabled |= intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_AVI);
+
+ if (val & VIDEO_DIP_ENABLE_GMP_HSW)
+ enabled |=
intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GAMUT_METADATA);
+
+ return enabled;
+}
+
void lspcon_resume(struct intel_lspcon *lspcon)
{
enum drm_lspcon_mode expected_mode;
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.h
b/drivers/gpu/drm/i915/display/intel_lspcon.h
index 1b9fb531128e..86305cc3a2d8 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.h
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.h
@@ -42,4 +42,6 @@ void lspcon_drm_read_infoframe(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
unsigned int type,
void *frame, ssize_t len);
+u32 intel_lspcon_infoframes_enabled(struct intel_encoder *encoder,
+ const struct intel_crtc_state *pipe_config);
#endif /* __INTEL_LSPCON_H__ */
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6 10/11] drm/i915/lspcon: Do not send DRM infoframes to non-HDMI sinks
Non-HDMI sinks shouldn't be sent Dynamic Range and Mastering infoframes.
Check for that when using LSPCON.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 8ce9bad4df91..81b3f4bdbe15 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3844,6 +3844,7 @@ static void intel_enable_ddi_dp(struct intel_atomic_state
*state,
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
enum port port = encoder->port;
if (port == PORT_A && INTEL_GEN(dev_priv) < 9)
@@ -3851,7 +3852,14 @@ static void intel_enable_ddi_dp(struct
intel_atomic_state *state,
intel_edp_backlight_on(crtc_state, conn_state);
intel_psr_enable(intel_dp, crtc_state, conn_state);
- intel_dp_set_infoframes(encoder, true, crtc_state, conn_state);
+
+ if (dig_port->lspcon.active) {
+ if (dig_port->dp.has_hdmi_sink)
+ intel_dp_set_infoframes(encoder, true, crtc_state,
conn_state);
+ } else {
+ intel_dp_set_infoframes(encoder, true, crtc_state, conn_state);
+ }
+
intel_edp_drrs_enable(intel_dp, crtc_state);
if (crtc_state->has_audio)
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6 03/11] drm/i915/display: Attach HDR property for capable Gen9 devices
Attach HDR property for Gen9 devices with MCA LSPCON
chips.
v2: Cleaned HDR property attachment logic based on capability
as per Jani Nikula's suggestion.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_lspcon.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index 5e2d7ca1d20f..fd05210f4405 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -626,6 +626,11 @@ bool lspcon_init(struct intel_digital_port *dig_port)
lspcon_detect_hdr_capability(lspcon);
+ if (lspcon->hdr_supported)
+ drm_object_attach_property(&connector->base,
+
connector->dev->mode_config.hdr_output_metadata_property,
+ 0);
+
connector->ycbcr_420_allowed = true;
lspcon->active = true;
DRM_DEBUG_KMS("Success: LSPCON init\n");
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6 09/11] drm/i915/lspcon: Do not send infoframes to non-HDMI sinks
From: Ville Syrjälä
Non-HDMI sinks shouldn't be sent infoframes. Check for that when
using LSPCON.
FIXME: How do we turn off infoframes once enabled? Do we even
have to?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 10 --
drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
drivers/gpu/drm/i915/display/intel_dp.c| 7 ++-
3 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 1b601b04f62f..8ce9bad4df91 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3581,19 +3581,17 @@ static void intel_ddi_pre_enable(struct
intel_atomic_state *state,
intel_ddi_pre_enable_hdmi(state, encoder, crtc_state,
conn_state);
} else {
- struct intel_lspcon *lspcon =
- enc_to_intel_lspcon(encoder);
+ struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
intel_ddi_pre_enable_dp(state, encoder, crtc_state,
conn_state);
- if (lspcon->active) {
- struct intel_digital_port *dig_port =
- enc_to_dig_port(encoder);
+ /* FIXME precompute everything properly */
+ /* FIXME how do we turn infoframes off again? */
+ if (dig_port->lspcon.active && dig_port->dp.has_hdmi_sink)
dig_port->set_infoframes(encoder,
crtc_state->has_infoframe,
crtc_state, conn_state);
- }
}
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5cf4e7a591e0..bb6b72bfd72d 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1279,6 +1279,7 @@ struct intel_dp {
u8 sink_count;
bool link_mst;
bool link_trained;
+ bool has_hdmi_sink;
bool has_audio;
bool reset_link_params;
u8 dpcd[DP_RECEIVER_CAP_SIZE];
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 8a673d0d7051..60bf01a8b4ad 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6069,7 +6069,11 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
edid = intel_dp_get_edid(intel_dp);
intel_connector->detect_edid = edid;
- intel_dp->has_audio = drm_detect_monitor_audio(edid);
+ if (edid && edid->input & DRM_EDID_INPUT_DIGITAL) {
+ intel_dp->has_hdmi_sink = drm_detect_hdmi_monitor(edid);
+ intel_dp->has_audio = drm_detect_monitor_audio(edid);
+ }
+
drm_dp_cec_set_edid(&intel_dp->aux, edid);
intel_dp->edid_quirks = drm_dp_get_edid_quirks(edid);
}
@@ -6083,6 +6087,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
kfree(intel_connector->detect_edid);
intel_connector->detect_edid = NULL;
+ intel_dp->has_hdmi_sink = false;
intel_dp->has_audio = false;
intel_dp->edid_quirks = 0;
}
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6 06/11] drm/i915/display: Implement infoframes readback for LSPCON
Implemented Infoframes enabled readback for LSPCON devices.
This will help align the implementation with state readback
infrastructure.
v2: Added proper bitmask of enabled infoframes as per Ville's
recommendation.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_lspcon.c | 57 -
1 file changed, 55 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index 60863b825cc5..565913b8e656 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -576,11 +576,64 @@ void lspcon_set_infoframes(struct intel_encoder *encoder,
buf, ret);
}
+static bool _lspcon_read_avi_infoframe_enabled_mca(struct drm_dp_aux *aux)
+{
+ int ret;
+ u32 val = 0;
+ u16 reg = LSPCON_MCA_AVI_IF_CTRL;
+
+ ret = drm_dp_dpcd_read(aux, reg, &val, 1);
+ if (ret < 0) {
+ DRM_ERROR("DPCD read failed, address 0x%x\n", reg);
+ return false;
+ }
+
+ return val & LSPCON_MCA_AVI_IF_KICKOFF;
+}
+
+static bool _lspcon_read_avi_infoframe_enabled_parade(struct drm_dp_aux *aux)
+{
+ int ret;
+ u32 val = 0;
+ u16 reg = LSPCON_PARADE_AVI_IF_CTRL;
+
+ ret = drm_dp_dpcd_read(aux, reg, &val, 1);
+ if (ret < 0) {
+ DRM_ERROR("DPCD read failed, address 0x%x\n", reg);
+ return false;
+ }
+
+ return val & LSPCON_PARADE_AVI_IF_KICKOFF;
+}
+
u32 lspcon_infoframes_enabled(struct intel_encoder *encoder,
const struct intel_crtc_state *pipe_config)
{
- /* FIXME actually read this from the hw */
- return 0;
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ struct intel_lspcon *lspcon = enc_to_intel_lspcon(encoder);
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ bool infoframes_enabled;
+ u32 val = 0;
+ u32 mask, tmp;
+
+ if (lspcon->vendor == LSPCON_VENDOR_MCA)
+ infoframes_enabled =
_lspcon_read_avi_infoframe_enabled_mca(&intel_dp->aux);
+ else
+ infoframes_enabled =
_lspcon_read_avi_infoframe_enabled_parade(&intel_dp->aux);
+
+ if (infoframes_enabled)
+ val |= VIDEO_DIP_ENABLE_AVI_HSW;
+
+ if (lspcon->hdr_supported) {
+ tmp = intel_de_read(dev_priv,
+
HSW_TVIDEO_DIP_CTL(pipe_config->cpu_transcoder));
+ mask = VIDEO_DIP_ENABLE_GMP_HSW;
+
+ if (tmp & mask)
+ val |= mask;
+ }
+
+ return val;
}
void lspcon_resume(struct intel_lspcon *lspcon)
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6 01/11] drm/i915/display: Add HDR Capability detection for LSPCON
LSPCON firmware exposes HDR capability through LPCON_CAPABILITIES
DPCD register. LSPCON implementations capable of supporting
HDR set HDR_CAPABILITY bit in LSPCON_CAPABILITIES to 1. This patch
reads the same, detects the HDR capability and adds this to
intel_lspcon struct.
v2: Addressed Jani Nikula's review comment and fixed the HDR
capability detection logic
Signed-off-by: Uma Shankar
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_lspcon.c | 30 +++
2 files changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b2d0edacc58c..5cf4e7a591e0 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1396,6 +1396,7 @@ struct intel_lspcon {
bool active;
enum drm_lspcon_mode mode;
enum lspcon_vendor vendor;
+ bool hdr_supported;
};
struct intel_digital_port {
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index dc1b35559afd..8e8c7a02ab51 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -35,6 +35,8 @@
#define LSPCON_VENDOR_PARADE_OUI 0x001CF8
#define LSPCON_VENDOR_MCA_OUI 0x0060AD
+#define DPCD_MCA_LSPCON_HDR_STATUS 0x70003
+
/* AUX addresses to write MCA AVI IF */
#define LSPCON_MCA_AVI_IF_WRITE_OFFSET 0x5C0
#define LSPCON_MCA_AVI_IF_CTRL 0x5DF
@@ -104,6 +106,32 @@ static bool lspcon_detect_vendor(struct intel_lspcon
*lspcon)
return true;
}
+static void lspcon_detect_hdr_capability(struct intel_lspcon *lspcon)
+{
+ struct intel_digital_port *intel_dig_port =
+ container_of(lspcon, struct intel_digital_port, lspcon);
+ struct drm_device *dev = intel_dig_port->base.base.dev;
+ struct intel_dp *dp = lspcon_to_intel_dp(lspcon);
+ u8 hdr_caps;
+ int ret;
+
+ /* Enable HDR for MCA based LSPCON devices */
+ if (lspcon->vendor == LSPCON_VENDOR_MCA)
+ ret = drm_dp_dpcd_read(&dp->aux, DPCD_MCA_LSPCON_HDR_STATUS,
+ &hdr_caps, 1);
+ else
+ return;
+
+ if (ret < 0) {
+ drm_dbg_kms(dev, "hdr capability detection failed\n");
+ lspcon->hdr_supported = false;
+ return;
+ } else if (hdr_caps & 0x1) {
+ drm_dbg_kms(dev, "lspcon capable of HDR\n");
+ lspcon->hdr_supported = true;
+ }
+}
+
static enum drm_lspcon_mode lspcon_get_current_mode(struct intel_lspcon
*lspcon)
{
enum drm_lspcon_mode current_mode;
@@ -581,6 +609,8 @@ bool lspcon_init(struct intel_digital_port *dig_port)
return false;
}
+ lspcon_detect_hdr_capability(lspcon);
+
connector->ycbcr_420_allowed = true;
lspcon->active = true;
DRM_DEBUG_KMS("Success: LSPCON init\n");
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6 00/11] Enable HDR on MCA LSPCON based Gen9 devices
Gen9 hardware supports HDMI2.0 through LSPCON chips. Extending HDR support for MCA and Parade LSPCON based GEN9 devices. SOC will drive LSPCON as DP and send HDR metadata as standard DP SDP packets. LSPCON will be set to operate in PCON mode, will receive the metadata and create Dynamic Range and Mastering Infoframe (DRM packets) and send it to HDR capable HDMI sink devices. v2: Fixed Ville's review comments. Suppressed some warnings. Patch 8 of the series is marked "Not for Merge" and is just for reference to userspace people to incorporate in order to support 10bit content with 4K@60 resolutions. v3: Added Infoframe readout support for DRM infoframes. Addressed Jani Nikula's review comments. v4: Addressed Ville's review comments and added proper bitmask for enabled infoframes. Series also incorporates Ville's patch for stopping infoframes to be sent to DVI sinks. Extended the same for DRM as well. v5: Created separate helper function for lspcon_infoframes_enabled as per Ville's suggestion. v6: Rebase Note: Patch 11 of the series is for reference to userspace, not to be merged to driver. Uma Shankar (10): drm/i915/display: Add HDR Capability detection for LSPCON drm/i915/display: Enable HDR on gen9 devices with MCA Lspcon drm/i915/display: Attach HDR property for capable Gen9 devices drm/i915/display: Enable BT2020 for HDR on LSPCON devices drm/i915/display: Enable HDR for Parade based lspcon drm/i915/display: Implement infoframes readback for LSPCON drm/i915/display: Implement DRM infoframe read for LSPCON drm/i915/lspcon: Create separate infoframe_enabled helper drm/i915/lspcon: Do not send DRM infoframes to non-HDMI sinks drm/i915/display: [NOT FOR MERGE] Reduce blanking to support 4k60@10bpp for LSPCON Ville Syrjälä (1): drm/i915/lspcon: Do not send infoframes to non-HDMI sinks drivers/gpu/drm/i915/display/intel_ddi.c | 30 ++-- .../drm/i915/display/intel_display_types.h| 2 + drivers/gpu/drm/i915/display/intel_dp.c | 24 ++- drivers/gpu/drm/i915/display/intel_hdmi.c | 20 +++ drivers/gpu/drm/i915/display/intel_lspcon.c | 170 -- drivers/gpu/drm/i915/display/intel_lspcon.h | 11 +- 6 files changed, 230 insertions(+), 27 deletions(-) -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v6 07/11] drm/i915/display: Implement DRM infoframe read for LSPCON
Implement Read back of HDR metadata infoframes i.e Dynamic Range
and Mastering Infoframe for LSPCON devices.
v2: Added proper bitmask of enabled infoframes as per Ville's
recommendation.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 10 ++
drivers/gpu/drm/i915/display/intel_lspcon.c | 6 +-
drivers/gpu/drm/i915/display/intel_lspcon.h | 4
3 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 1e40ed473fb9..02b0b5921bed 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -600,6 +600,16 @@ void lspcon_drm_write_infoframe(struct intel_encoder
*encoder,
hsw_write_infoframe(encoder, crtc_state, type, frame, len);
}
+void lspcon_drm_read_infoframe(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ unsigned int type,
+ void *frame, ssize_t len)
+{
+ drm_dbg_kms(encoder->base.dev, "Read HDR metadata for lspcon\n");
+ /* It uses the legacy hsw implementation for the same */
+ hsw_read_infoframe(encoder, crtc_state, type, frame, len);
+}
+
static const u8 infoframe_type_to_idx[] = {
HDMI_PACKET_TYPE_GENERAL_CONTROL,
HDMI_PACKET_TYPE_GAMUT_METADATA,
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index 565913b8e656..ee77a5381cb5 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -501,7 +501,11 @@ void lspcon_read_infoframe(struct intel_encoder *encoder,
unsigned int type,
void *frame, ssize_t len)
{
- /* FIXME implement this */
+ /* FIXME implement for AVI Infoframe as well */
+ if (type == HDMI_PACKET_TYPE_GAMUT_METADATA)
+ lspcon_drm_read_infoframe(encoder, crtc_state,
+ HDMI_PACKET_TYPE_GAMUT_METADATA,
+ frame, VIDEO_DIP_DATA_SIZE);
}
/* HDMI HDR Colorspace Spec Definitions */
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.h
b/drivers/gpu/drm/i915/display/intel_lspcon.h
index 3fac05535731..1b9fb531128e 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.h
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.h
@@ -38,4 +38,8 @@ void lspcon_drm_write_infoframe(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
unsigned int type,
const void *frame, ssize_t len);
+void lspcon_drm_read_infoframe(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ unsigned int type,
+ void *frame, ssize_t len);
#endif /* __INTEL_LSPCON_H__ */
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/atomic-helper: Remove the timestamping constant update from drm_atomic_helper_update_legacy_modeset_state()
On Mon, Sep 07, 2020 at 08:12:56PM +0200, Daniel Vetter wrote:
> On Mon, Sep 07, 2020 at 03:00:25PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The timestamping constants have nothing to do with any legacy state
> > so should not be updated from
> > drm_atomic_helper_update_legacy_modeset_state().
> >
> > Let's make everyone call drm_atomic_helper_calc_timestamping_constants()
> > directly instead of relying on
> > drm_atomic_helper_update_legacy_modeset_state() to call it.
> >
> > @@
> > expression S;
> > @@
> > - drm_atomic_helper_calc_timestamping_constants(S);
> >
> > @@
> > expression D, S;
> > @@
> > drm_atomic_helper_update_legacy_modeset_state(D, S);
> > + drm_atomic_helper_calc_timestamping_constants(S);
> >
> > Signed-off-by: Ville Syrjälä
>
> I think the kerneldoc for
> drm_crtc_vblank_helper_get_vblank/_timestamp_internal (both of them) also
> needs to be updated to mention the new function. With that fixed:
>
> Reviewed-by: Daniel Vetter
Fixed the docs while applying. Thanks for the review.
>
>
> > ---
> > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
> > drivers/gpu/drm/drm_atomic_helper.c | 7 ++-
> > drivers/gpu/drm/i915/display/intel_display.c | 1 +
> > drivers/gpu/drm/nouveau/dispnv50/disp.c | 1 +
> > 4 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index 490684787cff..0511097343da 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -7397,6 +7397,7 @@ static void amdgpu_dm_atomic_commit_tail(struct
> > drm_atomic_state *state)
> > int crtc_disable_count = 0;
> >
> > drm_atomic_helper_update_legacy_modeset_state(dev, state);
> > + drm_atomic_helper_calc_timestamping_constants(state);
> >
> > dm_state = dm_atomic_get_new_state(state);
> > if (dm_state && dm_state->context) {
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 673e3fc282d9..45ee613c8efd 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -1115,9 +1115,7 @@ disable_outputs(struct drm_device *dev, struct
> > drm_atomic_state *old_state)
> > * @old_state: atomic state object with old state structures
> > *
> > * This function updates all the various legacy modeset state pointers in
> > - * connectors, encoders and CRTCs. It also updates the timestamping
> > constants
> > - * used for precise vblank timestamps by calling
> > - * drm_calc_timestamping_constants().
> > + * connectors, encoders and CRTCs.
> > *
> > * Drivers can use this for building their own atomic commit if they don't
> > have
> > * a pure helper-based modeset implementation.
> > @@ -1187,8 +1185,6 @@ drm_atomic_helper_update_legacy_modeset_state(struct
> > drm_device *dev,
> > crtc->y = new_plane_state->src_y >> 16;
> > }
> > }
> > -
> > - drm_atomic_helper_calc_timestamping_constants(old_state);
> > }
> > EXPORT_SYMBOL(drm_atomic_helper_update_legacy_modeset_state);
> >
> > @@ -1296,6 +1292,7 @@ void drm_atomic_helper_commit_modeset_disables(struct
> > drm_device *dev,
> > disable_outputs(dev, old_state);
> >
> > drm_atomic_helper_update_legacy_modeset_state(dev, old_state);
> > + drm_atomic_helper_calc_timestamping_constants(old_state);
> >
> > crtc_set_mode(dev, old_state);
> > }
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index ec148a8da2c2..035840ce3825 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -15578,6 +15578,7 @@ static void intel_atomic_commit_tail(struct
> > intel_atomic_state *state)
> >
> > if (state->modeset) {
> > drm_atomic_helper_update_legacy_modeset_state(dev,
> > &state->base);
> > + drm_atomic_helper_calc_timestamping_constants(&state->base);
> >
> > intel_set_cdclk_pre_plane_update(state);
> >
> > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > index 7799530e07c1..b6d1b926bc5e 100644
> > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > @@ -2069,6 +2069,7 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state
> > *state)
> > drm_atomic_helper_wait_for_fences(dev, state, false);
> > drm_atomic_helper_wait_for_dependencies(state);
> > drm_atomic_helper_update_legacy_modeset_state(dev, state);
> > + drm_atomic_helper_calc_timestamping_constants(state);
> >
> > if (atom->lock_core)
> > mutex_lock(&disp->mutex);
> > --
> > 2.26.2
> >
> > ___
> > Intel-gfx mailing list
> >
Re: [Intel-gfx] [PATCH 3/4] drm/i915/display: Program PSR2 selective fetch registers
On Mon, 2020-09-14 at 17:28 +0300, Ville Syrjälä wrote:
> On Mon, Aug 31, 2020 at 06:09:23PM -0700, José Roberto de Souza wrote:
> > Another step towards PSR2 selective fetch, here programming plane
> > selective fetch registers and MAN_TRK_CTL enabling selective fetch but
> > for now it is fetching the whole area of the planes.
> > The damaged area calculation will come as next and final step.
> >
> > BSpec: 55229
> > Cc: Gwan-gyeong Mun <
> > gwan-gyeong@intel.com
> > >
> > Cc: Ville Syrjälä <
> > ville.syrj...@linux.intel.com
> > >
> > Signed-off-by: José Roberto de Souza <
> > jose.so...@intel.com
> > >
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 10 +-
> > .../drm/i915/display/intel_display_types.h| 2 +
> > drivers/gpu/drm/i915/display/intel_psr.c | 129 +-
> > drivers/gpu/drm/i915/display/intel_psr.h | 10 +-
> > drivers/gpu/drm/i915/display/intel_sprite.c | 3 +
> > 5 files changed, 145 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index c8b1dd1a9e46..865486e89915 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -11799,6 +11799,9 @@ static void i9xx_update_cursor(struct intel_plane
> > *plane,
> > if (INTEL_GEN(dev_priv) >= 9)
> > skl_write_cursor_wm(plane, crtc_state);
> >
> > + if (!needs_modeset(crtc_state))
> > + intel_psr2_program_plane_sel_fetch(plane, crtc_state,
> > plane_state, 0);
> > +
> > if (plane->cursor.base != base ||
> > plane->cursor.size != fbc_ctl ||
> > plane->cursor.cntl != cntl) {
> > @@ -12810,8 +12813,11 @@ static int intel_crtc_atomic_check(struct
> > intel_atomic_state *state,
> >
> > }
> >
> > - if (!mode_changed)
> > - intel_psr2_sel_fetch_update(state, crtc);
> > + if (!mode_changed) {
> > + ret = intel_psr2_sel_fetch_update(state, crtc);
> > + if (ret)
> > + return ret;
> > + }
> >
> > return 0;
> > }
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index 9349b15afff6..2138bb0f1587 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -586,6 +586,8 @@ struct intel_plane_state {
> > u32 planar_slave;
> >
> > struct drm_intel_sprite_colorkey ckey;
> > +
> > + struct drm_rect psr2_sel_fetch_area;
> > };
> >
> > struct intel_initial_plane_config {
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 6698d0209879..b60ea133a527 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -1173,6 +1173,46 @@ static void psr_force_hw_tracking_exit(struct
> > drm_i915_private *dev_priv)
> > intel_psr_exit(dev_priv);
> > }
> >
> > +void intel_psr2_program_plane_sel_fetch(struct intel_plane *plane,
> > + const struct intel_crtc_state
> > *crtc_state,
> > + const struct intel_plane_state
> > *plane_state,
> > + int color_plane)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> > + const struct drm_rect *clip;
> > + enum pipe pipe = plane->pipe;
> > + u32 val;
> > +
> > + if (!plane_state || !dev_priv->psr.psr2_sel_fetch_enabled)
> > + return;
> > +
> > + /*
> > +* skl_plane_ctl_crtc()/i9xx_cursor_ctl_crtc() return 0 for gen11+, so
> > +* plane_state->ctl is the right value
> > +*/
> > + intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, plane->id),
> > plane_state->ctl);
> > + if (!plane_state->ctl || plane->id == PLANE_CURSOR)
> > + return;
> > +
> > + clip = &plane_state->psr2_sel_fetch_area;
> > +
> > + val = (clip->y1 + plane_state->uapi.crtc_y) << 16;
>
> crtc_x/y are the raw values usrspace gave us. That is definitely not
> what we should be looking at.
plane_state->uapi.dst then? but for what I found crtc_x/y is set from dst.
plane_state->uapi.dst is used in skl_program_plane()
skl_program_plane()
int crtc_x = plane_state->uapi.dst.x1;
int crtc_y = plane_state->uapi.dst.y1;
...
intel_de_write_fw(dev_priv, PLANE_POS(pipe, plane_id), (crtc_y << 16) |
crtc_x);
>
> As the first step I think these functions should just program the
> registers with *exactly* the same values as we program into the
> normal plane register. That gets us to the point where we're
> actually programming something into the register without having to
> complicate things with calculating the selective fetch area.
Okay, I can move this to other patch but please check the comment above so we
have this agreed for first
Re: [Intel-gfx] [PATCH v6 08/11] drm/i915: Link planes in a bigjoiner configuration, v3.
On Mon, Sep 14, 2020 at 12:45:59PM -0700, Navare, Manasi wrote:
> On Mon, Sep 14, 2020 at 10:34:12PM +0300, Ville Syrjälä wrote:
> > On Mon, Sep 14, 2020 at 12:27:58PM -0700, Navare, Manasi wrote:
> > > On Mon, Sep 14, 2020 at 10:20:41PM +0300, Ville Syrjälä wrote:
> > > > On Mon, Sep 14, 2020 at 12:14:10PM -0700, Navare, Manasi wrote:
> > > > > On Thu, Sep 03, 2020 at 10:19:45PM +0300, Ville Syrjälä wrote:
> > > > > > On Wed, Jul 15, 2020 at 03:42:19PM -0700, Manasi Navare wrote:
> > > > > > > From: Maarten Lankhorst
> > > > > > >
> > > > > > > Make sure that when a plane is set in a bigjoiner mode, we will
> > > > > > > add
> > > > > > > their counterpart to the atomic state as well. This will allow
> > > > > > > us to
> > > > > > > make sure all state is available when planes are checked.
> > > > > > >
> > > > > > > Because of the funny interactions with bigjoiner and planar YUV
> > > > > > > formats, we may end up adding a lot of planes, so we have to keep
> > > > > > > iterating until we no longer add any planes.
> > > > > > >
> > > > > > > Also fix the atomic intel plane iterator, so things watermarks
> > > > > > > start
> > > > > > > working automagically.
> > > > > > >
> > > > > > > v5:
> > > > > > > * Rebase after adding sagv support (Manasi)
> > > > > > > v4:
> > > > > > > * Manual rebase (Manasi)
> > > > > > > Changes since v1:
> > > > > > > - Rebase on top of plane_state split, cleaning up the code a lot.
> > > > > > > - Make intel_atomic_crtc_state_for_each_plane_state() bigjoiner
> > > > > > > capable.
> > > > > > > - Add iter macro to
> > > > > > > intel_atomic_crtc_state_for_each_plane_state() to
> > > > > > > keep iteration working.
> > > > > > > Changes since v2:
> > > > > > > - Add icl_(un)set_bigjoiner_plane_links, to make it more clear
> > > > > > > where
> > > > > > > links are made and broken.
> > > > > > >
> > > > > > > Signed-off-by: Maarten Lankhorst
> > > > > > >
> > > > > > > Signed-off-by: Manasi Navare
> > > > > > > ---
> > > > > > > .../gpu/drm/i915/display/intel_atomic_plane.c | 52 -
> > > > > > > .../gpu/drm/i915/display/intel_atomic_plane.h | 3 +-
> > > > > > > drivers/gpu/drm/i915/display/intel_display.c | 207
> > > > > > > --
> > > > > > > drivers/gpu/drm/i915/display/intel_display.h | 20 +-
> > > > > > > .../drm/i915/display/intel_display_types.h| 11 +
> > > > > > > drivers/gpu/drm/i915/intel_pm.c | 20 +-
> > > > > > > 6 files changed, 274 insertions(+), 39 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > > > > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > > > > index 79032701873a..5c6e72063fac 100644
> > > > > > > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > > > > @@ -246,11 +246,17 @@ static void
> > > > > > > intel_plane_clear_hw_state(struct intel_plane_state *plane_state)
> > > > > > > memset(&plane_state->hw, 0, sizeof(plane_state->hw));
> > > > > > > }
> > > > > > >
> > > > > > > -void intel_plane_copy_uapi_to_hw_state(struct intel_plane_state
> > > > > > > *plane_state,
> > > > > > > +void intel_plane_copy_uapi_to_hw_state(const struct
> > > > > > > intel_crtc_state *crtc_state,
> > > > > > > +struct intel_plane_state
> > > > > > > *plane_state,
> > > > > > > const struct intel_plane_state
> > > > > > > *from_plane_state)
> > > > > > > {
> > > > > > > intel_plane_clear_hw_state(plane_state);
> > > > > > >
> > > > > > > + if (from_plane_state->uapi.crtc)
> > > > > > > + plane_state->hw.crtc = crtc_state->uapi.crtc;
> > > > > > > + else
> > > > > > > + plane_state->hw.crtc = NULL;
> > > > > > > +
> > > > > > > plane_state->hw.crtc = from_plane_state->uapi.crtc;
> > > > > >
> > > > > > eh?
> > > > >
> > > > > Hmm good catch here, this one definitely looks fishy probably got
> > > > > messed up in the rebase
> > > > > so this should just be:
> > > > >
> > > > > if (from_plane_state->uapi.crtc)
> > > > > plane_state->hw.crtc = crtc_state->uapi.crtc;
> > > > > else
> > > > >plane_state->hw.crtc = NULL;
> > > > >
> > > > > And the reassignmnet of plane_state->hw.crtc should be removed.
> > > > >
> > > > > Good?
> > > >
> > > > The if-else seems totally pointless.
> > > >
> > >
> > > Hmm yes so we assume that if from_plane_state->uapi.crtc is NULL then
> > > crtc_state->uapi.crtc is NULL?
> > > Then just have plane_state->hw.crtc = crtc_state->uapi.crtc; without
> > > if-else?
> >
> > Actually, re-reading this I don't even understand what this code is doing.
> >
>
> My understanding was that here this gets called by:
> intel_plane_atomic_check() where from_plane_state
> comes from the master_plane_state and then we copy this uapi state to hw
> state for both master and slave planes.
>
> so now if it has
Re: [Intel-gfx] [PATCH] drm/i915/tgl, rkl: Make Wa_1606700617/22010271021 permanent
> On Sep 11, 2020, at 9:00 PM, Dhanavanthri, Swathi
> wrote:
>
> It is in the if statement: if (IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915)) {
duh! sorry...
more below:
>
> -Original Message-
> From: Rodrigo Vivi
> Sent: Friday, September 11, 2020 6:10 PM
> To: Dhanavanthri, Swathi
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/tgl, rkl: Make
> Wa_1606700617/22010271021 permanent
>
> On Fri, Sep 11, 2020 at 03:11:58PM -0700, Swathi Dhanavanthri wrote:
>> This workaround applies to all TGL and RKL steppings.
>>
>> Signed-off-by: Swathi Dhanavanthri
>> ---
>> drivers/gpu/drm/i915/gt/intel_workarounds.c | 7 ---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
>> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
>> index 39817c5a7058..6c580d0d9ea8 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
>> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
>> @@ -1729,10 +1729,11 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
>> struct i915_wa_list *wal)
>> GEN6_RC_SLEEP_PSMI_CONTROL,
>> GEN12_WAIT_FOR_EVENT_POWER_DOWN_DISABLE |
>> GEN8_RC_SEMA_IDLE_MSG_DISABLE);
>> -}
now I noticed this ^ :)
>>
>> -if (IS_TGL_U(i915) || IS_TGL_Y(i915)) {
>
> please notice this function is called for other gens.
> In case you need to extend this to other platforms, please add them to the if
> instead of removing the if.
>
>> -/* Wa_1606700617:tgl */
>> +/*
>> + * Wa_1606700617:tgl
>> + * Wa_22010271021:tgl,rkl
1. This HSD only mentions TGL-U. No mention to RKL.
2. No mention to anything related to this clock gate.
3. Actually no W/a description at all and no sw_impact at all. But It links to
another entry 22010288313,
which describes the w/a as a 3dstate ff one...
What am I missing here?
Thanks,
Rodrigo.
>> + */
>> wa_masked_en(wal,
>> GEN9_CS_DEBUG_MODE1,
>> FF_DOP_CLOCK_GATE_DISABLE);
>> --
>> 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 2/4] drm/i915/display: Fix state of PSR2 sub features
On Mon, 2020-09-14 at 17:24 +0300, Ville Syrjälä wrote:
> On Mon, Aug 31, 2020 at 06:09:22PM -0700, José Roberto de Souza wrote:
> > In case PSR2 is disabled by debugfs dc3co_enabled and
> > psr2_sel_fetch_enabled were still being set causing some code paths
> > to be executed were it should not.
> > We have tests for PSR1 and PSR2 so keep those features disabled when
> > PSR1 is active but PSR2 is supported is important.
> >
> > Cc: Gwan-gyeong Mun <
> > gwan-gyeong@intel.com
> > >
> > Cc: Ville Syrjälä <
> > ville.syrj...@linux.intel.com
> > >
> > Signed-off-by: José Roberto de Souza <
> > jose.so...@intel.com
> > >
> > ---
> > drivers/gpu/drm/i915/display/intel_psr.c | 11 +++
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 4e09ae61d4aa..6698d0209879 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -962,12 +962,14 @@ static void intel_psr_enable_locked(struct
> > drm_i915_private *dev_priv,
> > dev_priv->psr.psr2_enabled = intel_psr2_enabled(dev_priv, crtc_state);
> > dev_priv->psr.busy_frontbuffer_bits = 0;
> > dev_priv->psr.pipe = to_intel_crtc(crtc_state->uapi.crtc)->pipe;
> > - dev_priv->psr.dc3co_enabled = !!crtc_state->dc3co_exitline;
> > + dev_priv->psr.dc3co_enabled = !!crtc_state->dc3co_exitline &&
> > + dev_priv->psr.psr2_enabled;
> > dev_priv->psr.transcoder = crtc_state->cpu_transcoder;
> > /* DC5/DC6 requires at least 6 idle frames */
> > val = usecs_to_jiffies(intel_get_frame_time_us(crtc_state) * 6);
> > dev_priv->psr.dc3co_exit_delay = val;
> > - dev_priv->psr.psr2_sel_fetch_enabled =
> > crtc_state->enable_psr2_sel_fetch;
> > + dev_priv->psr.psr2_sel_fetch_enabled =
> > crtc_state->enable_psr2_sel_fetch &&
> > + dev_priv->psr.psr2_enabled;
> >
> > /*
> > * If a PSR error happened and the driver is reloaded, the EDP_PSR_IIR
> > @@ -1178,7 +1180,7 @@ void intel_psr2_program_trans_man_trk_ctl(const
> > struct intel_crtc_state *crtc_st
> > struct i915_psr *psr = &dev_priv->psr;
> >
> > if (!HAS_PSR2_SEL_FETCH(dev_priv) ||
> > - !crtc_state->enable_psr2_sel_fetch)
> > + !dev_priv->psr.psr2_sel_fetch_enabled)
> > return;
> >
> > intel_de_write(dev_priv, PSR2_MAN_TRK_CTL(psr->transcoder),
> > @@ -1189,8 +1191,9 @@ void intel_psr2_sel_fetch_update(struct
> > intel_atomic_state *state,
> > struct intel_crtc *crtc)
> > {
> > struct intel_crtc_state *crtc_state =
> > intel_atomic_get_new_crtc_state(state, crtc);
> > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> >
> > - if (!crtc_state->enable_psr2_sel_fetch)
> > + if (!dev_priv->psr.psr2_sel_fetch_enabled)
>
> This looks rather sketchy. AFAICS this gets called during atomic_check()
> so looking at stuff outside the crtc state is very suspicious.
This is called after the functions that change the PSR state so no issues, also
we can't really on information in CRTC state, as PSR is only enabled
if supported by state, i915 PSR parameter and PSR debug fs value.
>
> > return;
> >
> > crtc_state->psr2_man_track_ctl = PSR2_MAN_TRK_CTL_ENABLE |
> > --
> > 2.28.0
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 04/11] drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.
On Mon, Sep 14, 2020 at 12:38:57PM -0700, Navare, Manasi wrote:
> On Mon, Sep 14, 2020 at 10:17:57PM +0300, Ville Syrjälä wrote:
> > On Mon, Sep 14, 2020 at 12:00:33PM -0700, Navare, Manasi wrote:
> > > On Mon, Sep 07, 2020 at 02:20:56PM +0300, Ville Syrjälä wrote:
> > > > On Wed, Jul 15, 2020 at 03:42:15PM -0700, Manasi Navare wrote:
> > > > > From: Maarten Lankhorst
> > > > >
> > > > > Small changes to intel_dp_mode_valid(), allow listing modes that
> > > > > can only be supported in the bigjoiner configuration, which is
> > > > > not supported yet.
> > > > >
> > > > > eDP does not support bigjoiner, so do not expose bigjoiner only
> > > > > modes on the eDP port.
> > > > >
> > > > > v5:
> > > > > * Increase max plane width to support 8K with bigjoiner (Maarten)
> > > > > v4:
> > > > > * Rebase (Manasi)
> > > > >
> > > > > Changes since v1:
> > > > > - Disallow bigjoiner on eDP.
> > > > > Changes since v2:
> > > > > - Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock,
> > > > > and split off the downstream and source checking to its own
> > > > > function.
> > > > > (Ville)
> > > > > v3:
> > > > > * Rebase (Manasi)
> > > > >
> > > > > Signed-off-by: Manasi Navare
> > > > > Signed-off-by: Maarten Lankhorst
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> > > > > drivers/gpu/drm/i915/display/intel_dp.c | 119
> > > > > ++-
> > > > > 2 files changed, 91 insertions(+), 30 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > index 78cbfefbfa62..3ecb642805a6 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > @@ -17400,7 +17400,7 @@ intel_mode_valid_max_plane_size(struct
> > > > > drm_i915_private *dev_priv,
> > > > >* too big for that.
> > > > >*/
> > > > > if (INTEL_GEN(dev_priv) >= 11) {
> > > > > - plane_width_max = 5120;
> > > > > + plane_width_max = 7680;
> > > >
> > > > This looks misplaced. Planes do no know whether bigjoiner can be used or
> > > > not. They should not care in fact. The caller should have that knowledge
> > > > and can deal with it properly.
> > >
> > > Hmm, so the caller of intel_mode_valid_max_plane_size() should check on
> > > the bigjoiner
> > > flag and perhaps if bigjoiner is true then increase the plane_width_max
> > > to 7680?
> > >
> > > Am still not sure where this should happen? We need to have the plane max
> > > width to be 7680
> > > before we prune the 8K mode in intel_mode_valid
> > >
> > > Where should this be added according to you?
> >
> > Hmm. I guess we do need to put it into this function given the way this
> > is structured. However we still can't assume bigjoiner can be used since
> > it can't be used on DDI A on icl. So we should probably just pass in a
> > bool here to indicate whether bigjoiner can be used or not.
> >
>
> So in intel_dp_mode_valid() we set bigjoiner = true if not edp and higher
> clock.
> I think here we need to do the platform check also, 1. because now we are
> enabling this for TGL+
> where big joiner on all pipes. But we should still I think add GEN >=12 check
> before setting bigjoiner
> to true in intel_dp_mode_valid() and then pass that to
> intel_mode_valid_max_plane_size(..., book bigjoiner)
can_bigjoiner() {
return gen >= 12 || (gen==11 && port!=A);
}
or something.
>
> Sounds good?
>
> > Personally I'd just write the thing as something like:
> > intel_mode_valid_max_plane_size(..., bool bigjoiner)
> > {
> > ...
> > plane_width_max = 5120 << bigjoiner;
> > ...
> > }
> >
> > >
> > > Manasi
> > > >
> > > > > plane_height_max = 4320;
> > > > > } else {
> > > > > plane_width_max = 5120;
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > index d6295eb20b63..fbfea99fd804 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > @@ -248,25 +248,37 @@ intel_dp_max_data_rate(int max_link_clock, int
> > > > > max_lanes)
> > > > > return max_link_clock * max_lanes;
> > > > > }
> > > > >
> > > > > -static int
> > > > > -intel_dp_downstream_max_dotclock(struct intel_dp *intel_dp)
> > > > > +static int source_max_dotclock(struct intel_dp *intel_dp, bool
> > > > > allow_bigjoiner)
> > > > > {
> > > > > - struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > > > > - struct intel_encoder *encoder = &dig_port->base;
> > > > > + struct intel_digital_port *intel_dig_port =
> > > > > dp_to_dig_port(intel_dp);
> > > > > + struct intel_encoder *encoder = &intel_dig_port->base;
> > > > > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > > > > - int max_
Re: [Intel-gfx] [PATCH v2 3/8] mm: Optimise madvise WILLNEED
On Mon, 2020-09-14 at 17:50 +0100, Matthew Wilcox wrote: > On Mon, Sep 14, 2020 at 12:17:07PM -0400, Qian Cai wrote: > > Reverting the "Return head pages from find_*_entry" patchset [1] up to this > > patch fixed the issue that LTP madvise06 test [2] would trigger endless > > soft- > > lockups below. It does not help after applied patches fixed other separate > > issues in the patchset [3][4]. > > Thanks for the report. Could you try this? It works fine. > > diff --git a/mm/madvise.c b/mm/madvise.c > index 96189acd6969..2d9ceccb338d 100644 > --- a/mm/madvise.c > +++ b/mm/madvise.c > @@ -234,6 +234,7 @@ static void force_shm_swapin_readahead(struct > vm_area_struct *vma, > > if (!xa_is_value(page)) > continue; > + xas_pause(&xas); > rcu_read_unlock(); > > swap = radix_to_swp_entry(page); > @@ -243,7 +244,6 @@ static void force_shm_swapin_readahead(struct > vm_area_struct *vma, > put_page(page); > > rcu_read_lock(); > - xas_reset(&xas); > } > rcu_read_unlock(); > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 08/11] drm/i915: Link planes in a bigjoiner configuration, v3.
On Mon, Sep 14, 2020 at 10:34:12PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 14, 2020 at 12:27:58PM -0700, Navare, Manasi wrote:
> > On Mon, Sep 14, 2020 at 10:20:41PM +0300, Ville Syrjälä wrote:
> > > On Mon, Sep 14, 2020 at 12:14:10PM -0700, Navare, Manasi wrote:
> > > > On Thu, Sep 03, 2020 at 10:19:45PM +0300, Ville Syrjälä wrote:
> > > > > On Wed, Jul 15, 2020 at 03:42:19PM -0700, Manasi Navare wrote:
> > > > > > From: Maarten Lankhorst
> > > > > >
> > > > > > Make sure that when a plane is set in a bigjoiner mode, we will add
> > > > > > their counterpart to the atomic state as well. This will allow us
> > > > > > to
> > > > > > make sure all state is available when planes are checked.
> > > > > >
> > > > > > Because of the funny interactions with bigjoiner and planar YUV
> > > > > > formats, we may end up adding a lot of planes, so we have to keep
> > > > > > iterating until we no longer add any planes.
> > > > > >
> > > > > > Also fix the atomic intel plane iterator, so things watermarks start
> > > > > > working automagically.
> > > > > >
> > > > > > v5:
> > > > > > * Rebase after adding sagv support (Manasi)
> > > > > > v4:
> > > > > > * Manual rebase (Manasi)
> > > > > > Changes since v1:
> > > > > > - Rebase on top of plane_state split, cleaning up the code a lot.
> > > > > > - Make intel_atomic_crtc_state_for_each_plane_state() bigjoiner
> > > > > > capable.
> > > > > > - Add iter macro to intel_atomic_crtc_state_for_each_plane_state()
> > > > > > to
> > > > > > keep iteration working.
> > > > > > Changes since v2:
> > > > > > - Add icl_(un)set_bigjoiner_plane_links, to make it more clear where
> > > > > > links are made and broken.
> > > > > >
> > > > > > Signed-off-by: Maarten Lankhorst
> > > > > > Signed-off-by: Manasi Navare
> > > > > > ---
> > > > > > .../gpu/drm/i915/display/intel_atomic_plane.c | 52 -
> > > > > > .../gpu/drm/i915/display/intel_atomic_plane.h | 3 +-
> > > > > > drivers/gpu/drm/i915/display/intel_display.c | 207
> > > > > > --
> > > > > > drivers/gpu/drm/i915/display/intel_display.h | 20 +-
> > > > > > .../drm/i915/display/intel_display_types.h| 11 +
> > > > > > drivers/gpu/drm/i915/intel_pm.c | 20 +-
> > > > > > 6 files changed, 274 insertions(+), 39 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > > > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > > > index 79032701873a..5c6e72063fac 100644
> > > > > > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > > > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > > > @@ -246,11 +246,17 @@ static void intel_plane_clear_hw_state(struct
> > > > > > intel_plane_state *plane_state)
> > > > > > memset(&plane_state->hw, 0, sizeof(plane_state->hw));
> > > > > > }
> > > > > >
> > > > > > -void intel_plane_copy_uapi_to_hw_state(struct intel_plane_state
> > > > > > *plane_state,
> > > > > > +void intel_plane_copy_uapi_to_hw_state(const struct
> > > > > > intel_crtc_state *crtc_state,
> > > > > > + struct intel_plane_state
> > > > > > *plane_state,
> > > > > >const struct intel_plane_state
> > > > > > *from_plane_state)
> > > > > > {
> > > > > > intel_plane_clear_hw_state(plane_state);
> > > > > >
> > > > > > + if (from_plane_state->uapi.crtc)
> > > > > > + plane_state->hw.crtc = crtc_state->uapi.crtc;
> > > > > > + else
> > > > > > + plane_state->hw.crtc = NULL;
> > > > > > +
> > > > > > plane_state->hw.crtc = from_plane_state->uapi.crtc;
> > > > >
> > > > > eh?
> > > >
> > > > Hmm good catch here, this one definitely looks fishy probably got
> > > > messed up in the rebase
> > > > so this should just be:
> > > >
> > > > if (from_plane_state->uapi.crtc)
> > > > plane_state->hw.crtc = crtc_state->uapi.crtc;
> > > > else
> > > > plane_state->hw.crtc = NULL;
> > > >
> > > > And the reassignmnet of plane_state->hw.crtc should be removed.
> > > >
> > > > Good?
> > >
> > > The if-else seems totally pointless.
> > >
> >
> > Hmm yes so we assume that if from_plane_state->uapi.crtc is NULL then
> > crtc_state->uapi.crtc is NULL?
> > Then just have plane_state->hw.crtc = crtc_state->uapi.crtc; without
> > if-else?
>
> Actually, re-reading this I don't even understand what this code is doing.
>
My understanding was that here this gets called by: intel_plane_atomic_check()
where from_plane_state
comes from the master_plane_state and then we copy this uapi state to hw state
for both master and slave planes.
so now if it has a crtc meaning it is the master crtc then we assign
plane_state->hw.crtc = crtc_state->uapi.crtc; else it means it is a slave crtc
and hence hw.crtc would be NULL?
I donno, may be Maarten needs to clarify this.
@Maarten??
Manasi
> >
> > Manasi
> >
> > > >
> > > > >
> > > > > > plane_state->hw.fb = f
Re: [Intel-gfx] [PATCH v6 04/11] drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.
On Mon, Sep 14, 2020 at 10:17:57PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 14, 2020 at 12:00:33PM -0700, Navare, Manasi wrote:
> > On Mon, Sep 07, 2020 at 02:20:56PM +0300, Ville Syrjälä wrote:
> > > On Wed, Jul 15, 2020 at 03:42:15PM -0700, Manasi Navare wrote:
> > > > From: Maarten Lankhorst
> > > >
> > > > Small changes to intel_dp_mode_valid(), allow listing modes that
> > > > can only be supported in the bigjoiner configuration, which is
> > > > not supported yet.
> > > >
> > > > eDP does not support bigjoiner, so do not expose bigjoiner only
> > > > modes on the eDP port.
> > > >
> > > > v5:
> > > > * Increase max plane width to support 8K with bigjoiner (Maarten)
> > > > v4:
> > > > * Rebase (Manasi)
> > > >
> > > > Changes since v1:
> > > > - Disallow bigjoiner on eDP.
> > > > Changes since v2:
> > > > - Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock,
> > > > and split off the downstream and source checking to its own function.
> > > > (Ville)
> > > > v3:
> > > > * Rebase (Manasi)
> > > >
> > > > Signed-off-by: Manasi Navare
> > > > Signed-off-by: Maarten Lankhorst
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> > > > drivers/gpu/drm/i915/display/intel_dp.c | 119 ++-
> > > > 2 files changed, 91 insertions(+), 30 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > index 78cbfefbfa62..3ecb642805a6 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > @@ -17400,7 +17400,7 @@ intel_mode_valid_max_plane_size(struct
> > > > drm_i915_private *dev_priv,
> > > > * too big for that.
> > > > */
> > > > if (INTEL_GEN(dev_priv) >= 11) {
> > > > - plane_width_max = 5120;
> > > > + plane_width_max = 7680;
> > >
> > > This looks misplaced. Planes do no know whether bigjoiner can be used or
> > > not. They should not care in fact. The caller should have that knowledge
> > > and can deal with it properly.
> >
> > Hmm, so the caller of intel_mode_valid_max_plane_size() should check on the
> > bigjoiner
> > flag and perhaps if bigjoiner is true then increase the plane_width_max to
> > 7680?
> >
> > Am still not sure where this should happen? We need to have the plane max
> > width to be 7680
> > before we prune the 8K mode in intel_mode_valid
> >
> > Where should this be added according to you?
>
> Hmm. I guess we do need to put it into this function given the way this
> is structured. However we still can't assume bigjoiner can be used since
> it can't be used on DDI A on icl. So we should probably just pass in a
> bool here to indicate whether bigjoiner can be used or not.
>
So in intel_dp_mode_valid() we set bigjoiner = true if not edp and higher clock.
I think here we need to do the platform check also, 1. because now we are
enabling this for TGL+
where big joiner on all pipes. But we should still I think add GEN >=12 check
before setting bigjoiner
to true in intel_dp_mode_valid() and then pass that to
intel_mode_valid_max_plane_size(..., book bigjoiner)
Sounds good?
> Personally I'd just write the thing as something like:
> intel_mode_valid_max_plane_size(..., bool bigjoiner)
> {
> ...
> plane_width_max = 5120 << bigjoiner;
> ...
> }
>
> >
> > Manasi
> > >
> > > > plane_height_max = 4320;
> > > > } else {
> > > > plane_width_max = 5120;
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > index d6295eb20b63..fbfea99fd804 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > @@ -248,25 +248,37 @@ intel_dp_max_data_rate(int max_link_clock, int
> > > > max_lanes)
> > > > return max_link_clock * max_lanes;
> > > > }
> > > >
> > > > -static int
> > > > -intel_dp_downstream_max_dotclock(struct intel_dp *intel_dp)
> > > > +static int source_max_dotclock(struct intel_dp *intel_dp, bool
> > > > allow_bigjoiner)
> > > > {
> > > > - struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > > > - struct intel_encoder *encoder = &dig_port->base;
> > > > + struct intel_digital_port *intel_dig_port =
> > > > dp_to_dig_port(intel_dp);
> > > > + struct intel_encoder *encoder = &intel_dig_port->base;
> > > > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > > > - int max_dotclk = dev_priv->max_dotclk_freq;
> > > > - int ds_max_dotclk;
> > > >
> > > > + if (allow_bigjoiner && INTEL_GEN(dev_priv) >= 11 &&
> > > > !intel_dp_is_edp(intel_dp))
> > > > + return 2 * dev_priv->max_dotclk_freq;
> > > > +
> > > > + return dev_priv->max_dotclk_freq;
> > > > +}
> > > > +
> > > > +static int downstream_max_dotc
Re: [Intel-gfx] [PATCH v6 08/11] drm/i915: Link planes in a bigjoiner configuration, v3.
On Mon, Sep 14, 2020 at 12:27:58PM -0700, Navare, Manasi wrote:
> On Mon, Sep 14, 2020 at 10:20:41PM +0300, Ville Syrjälä wrote:
> > On Mon, Sep 14, 2020 at 12:14:10PM -0700, Navare, Manasi wrote:
> > > On Thu, Sep 03, 2020 at 10:19:45PM +0300, Ville Syrjälä wrote:
> > > > On Wed, Jul 15, 2020 at 03:42:19PM -0700, Manasi Navare wrote:
> > > > > From: Maarten Lankhorst
> > > > >
> > > > > Make sure that when a plane is set in a bigjoiner mode, we will add
> > > > > their counterpart to the atomic state as well. This will allow us to
> > > > > make sure all state is available when planes are checked.
> > > > >
> > > > > Because of the funny interactions with bigjoiner and planar YUV
> > > > > formats, we may end up adding a lot of planes, so we have to keep
> > > > > iterating until we no longer add any planes.
> > > > >
> > > > > Also fix the atomic intel plane iterator, so things watermarks start
> > > > > working automagically.
> > > > >
> > > > > v5:
> > > > > * Rebase after adding sagv support (Manasi)
> > > > > v4:
> > > > > * Manual rebase (Manasi)
> > > > > Changes since v1:
> > > > > - Rebase on top of plane_state split, cleaning up the code a lot.
> > > > > - Make intel_atomic_crtc_state_for_each_plane_state() bigjoiner
> > > > > capable.
> > > > > - Add iter macro to intel_atomic_crtc_state_for_each_plane_state() to
> > > > > keep iteration working.
> > > > > Changes since v2:
> > > > > - Add icl_(un)set_bigjoiner_plane_links, to make it more clear where
> > > > > links are made and broken.
> > > > >
> > > > > Signed-off-by: Maarten Lankhorst
> > > > > Signed-off-by: Manasi Navare
> > > > > ---
> > > > > .../gpu/drm/i915/display/intel_atomic_plane.c | 52 -
> > > > > .../gpu/drm/i915/display/intel_atomic_plane.h | 3 +-
> > > > > drivers/gpu/drm/i915/display/intel_display.c | 207
> > > > > --
> > > > > drivers/gpu/drm/i915/display/intel_display.h | 20 +-
> > > > > .../drm/i915/display/intel_display_types.h| 11 +
> > > > > drivers/gpu/drm/i915/intel_pm.c | 20 +-
> > > > > 6 files changed, 274 insertions(+), 39 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > > index 79032701873a..5c6e72063fac 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > > @@ -246,11 +246,17 @@ static void intel_plane_clear_hw_state(struct
> > > > > intel_plane_state *plane_state)
> > > > > memset(&plane_state->hw, 0, sizeof(plane_state->hw));
> > > > > }
> > > > >
> > > > > -void intel_plane_copy_uapi_to_hw_state(struct intel_plane_state
> > > > > *plane_state,
> > > > > +void intel_plane_copy_uapi_to_hw_state(const struct intel_crtc_state
> > > > > *crtc_state,
> > > > > +struct intel_plane_state
> > > > > *plane_state,
> > > > > const struct intel_plane_state
> > > > > *from_plane_state)
> > > > > {
> > > > > intel_plane_clear_hw_state(plane_state);
> > > > >
> > > > > + if (from_plane_state->uapi.crtc)
> > > > > + plane_state->hw.crtc = crtc_state->uapi.crtc;
> > > > > + else
> > > > > + plane_state->hw.crtc = NULL;
> > > > > +
> > > > > plane_state->hw.crtc = from_plane_state->uapi.crtc;
> > > >
> > > > eh?
> > >
> > > Hmm good catch here, this one definitely looks fishy probably got messed
> > > up in the rebase
> > > so this should just be:
> > >
> > > if (from_plane_state->uapi.crtc)
> > > plane_state->hw.crtc = crtc_state->uapi.crtc;
> > > else
> > >plane_state->hw.crtc = NULL;
> > >
> > > And the reassignmnet of plane_state->hw.crtc should be removed.
> > >
> > > Good?
> >
> > The if-else seems totally pointless.
> >
>
> Hmm yes so we assume that if from_plane_state->uapi.crtc is NULL then
> crtc_state->uapi.crtc is NULL?
> Then just have plane_state->hw.crtc = crtc_state->uapi.crtc; without if-else?
Actually, re-reading this I don't even understand what this code is doing.
>
> Manasi
>
> > >
> > > >
> > > > > plane_state->hw.fb = from_plane_state->uapi.fb;
> > > > > if (plane_state->hw.fb)
> > > > > @@ -319,15 +325,36 @@ int intel_plane_atomic_check_with_state(const
> > > > > struct intel_crtc_state *old_crtc_
> > > > > }
> > > > >
> > > > > static struct intel_crtc *
> > > > > -get_crtc_from_states(const struct intel_plane_state *old_plane_state,
> > > > > +get_crtc_from_states(struct intel_atomic_state *state,
> > > > > + const struct intel_plane_state *old_plane_state,
> > > > >const struct intel_plane_state *new_plane_state)
> > > > > {
> > > > > + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > > > > + struct intel_plane *plane =
> > > > > to_intel_plane(new_plane_state->uapi.plane);
> > > > > +
>
Re: [Intel-gfx] [PATCH 01/20] drm/amdgpu: Introduce GEM object functions
Am 14.09.20 um 17:05 schrieb Thomas Zimmermann:
Hi
Am 13.08.20 um 12:22 schrieb Christian König:
Am 13.08.20 um 10:36 schrieb Thomas Zimmermann:
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in amdgpu. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 --
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 12
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 81a79760ca61..51525b8774c9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1468,19 +1468,13 @@ static struct drm_driver kms_driver = {
.lastclose = amdgpu_driver_lastclose_kms,
.irq_handler = amdgpu_irq_handler,
.ioctls = amdgpu_ioctls_kms,
- .gem_free_object_unlocked = amdgpu_gem_object_free,
- .gem_open_object = amdgpu_gem_object_open,
- .gem_close_object = amdgpu_gem_object_close,
.dumb_create = amdgpu_mode_dumb_create,
.dumb_map_offset = amdgpu_mode_dumb_mmap,
.fops = &amdgpu_driver_kms_fops,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_export = amdgpu_gem_prime_export,
.gem_prime_import = amdgpu_gem_prime_import,
- .gem_prime_vmap = amdgpu_gem_prime_vmap,
- .gem_prime_vunmap = amdgpu_gem_prime_vunmap,
.gem_prime_mmap = amdgpu_gem_prime_mmap,
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 43f4966331dd..ca2b79f94e99 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -36,6 +36,7 @@
#include
#include
#include "amdgpu.h"
+#include "amdgpu_dma_buf.h"
#include "amdgpu_trace.h"
#include "amdgpu_amdkfd.h"
@@ -510,6 +511,15 @@ bool amdgpu_bo_support_uswc(u64 bo_flags)
#endif
}
+static const struct drm_gem_object_funcs amdgpu_gem_object_funcs = {
+ .free = amdgpu_gem_object_free,
+ .open = amdgpu_gem_object_open,
+ .close = amdgpu_gem_object_close,
+ .export = amdgpu_gem_prime_export,
+ .vmap = amdgpu_gem_prime_vmap,
+ .vunmap = amdgpu_gem_prime_vunmap,
+};
+
Wrong file, this belongs into amdgpu_gem.c
static int amdgpu_bo_do_create(struct amdgpu_device *adev,
struct amdgpu_bo_param *bp,
struct amdgpu_bo **bo_ptr)
@@ -552,6 +562,8 @@ static int amdgpu_bo_do_create(struct
amdgpu_device *adev,
bo = kzalloc(sizeof(struct amdgpu_bo), GFP_KERNEL);
if (bo == NULL)
return -ENOMEM;
+
+ bo->tbo.base.funcs = &amdgpu_gem_object_funcs;
And this should probably go into amdgpu_gem_object_create().
I'm trying to understand what amdgpu does. What about all the places
where amdgpu calls amdgpu_bo_create() internally? Wouldn't these miss
the free callback for the GEM object?
Those shouldn't have a GEM object in the first place.
Or otherwise we would have a reference counting issue.
Regards,
Christian.
Best regards
Thomas
Apart from that looks like a good idea to me.
Christian.
drm_gem_private_object_init(adev->ddev, &bo->tbo.base, size);
INIT_LIST_HEAD(&bo->shadow_list);
bo->vm_bo = NULL;
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v6 00/24] tests/core_hotunplug: Fixes and enhancements
On Mon, 2020-09-14 at 20:18 +0200, Michał Winiarski wrote: > Quoting Janusz Krzysztofik (2020-09-11 12:30:15) > > Clean up the test code, add some new basic subtests, then unblock > > unbind test variants. > > > > No incompletes / aborts nor subsequently run test issues have been > > reported by Trybot. The hotrebind-lateclose subtest fails on a so far > > unidentified driver sysfs issue but the device is fully recovered and > > left in a usable state. Perceived Haswell/Broadwell issue with audio > > power management has been worked around and its potential occurrence > > is reported as an IGT warning. > > > > Series changelog: > > v2: New patch "Un-blocklist *bind* subtests added. > > v3: Patch "Follow failed subtests with healthcheck" renamed to "Recover > > from subtest failures". > > - a new patche "Clean up device open error handling" added, an old > > patch "Fix missing newline" obsoleted by the new one dropped, > > - other new patches added: > > - "Let the driver time out essential sysfs operations", > > - "More thorough i915 healthcheck and recovery", > > - a patch "Add 'lateclose before restore' variants" from another > > series included. > > v4: Optional patch "Duplicate debug messages in dmesg" from another > > series included. > > v5: New patch added with Haswell audio related kernel warning worked > > around and replaced with an IGT warning to preserve visibility of > > the issue. > > v6: New patch added for also checking health of render device nodes, > > - new patch added with proper handling of health check before late > > close, > > - inclusion of unbind-rebind scenario to BAT scope proposed. > > > > @Michał: Since some patch updates are trivial, I've preserved your > > v1/v2 Reviewd-by: except for patches with non-trivial changes, where I > > marked your R-b as v1/v2 applicable. Please have a look and confirm if > > you are still OK with them. > > Feel free to add: > Reviewed-by: Michał Winiarski > > For the whole series (with the exception of intel-ci part). Pushed. @Petri, @Michał - thank you for review. @Lakshmi: - please open a new bug for the issue reported by the igt@core _hotunplug@hotrebind-lateclose subtest failing on all platforms, - IGT warning reported by igt@core_hotunplug@*bind* on Haswell and Broadwell platofrms is caused by the same issue as the one reported now in a similar way on Haswell by igt@device_reset@unbind-reset-rebind - please update the associated filter so it covers all those tests. Thanks, Janusz > > -Michał > > > @Tvrtko: As I already asked before, please support my attempt to remove > > the unbind test variants from the blocklist. > > > > @Petri, @Martin: Assuming CI results will be as good as those obtained > > on Trybot, please give me your green light for merging this series if > > you have no objections. > > > > Thanks, > > Janusz > > > > Janusz Krzysztofik (24): > > tests/core_hotunplug: Use igt_assert_fd() > > tests/core_hotunplug: Constify dev_bus_addr string > > tests/core_hotunplug: Clean up device open error handling > > tests/core_hotunplug: Consolidate duplicated debug messages > > tests/core_hotunplug: Assert successful device filter application > > tests/core_hotunplug: Maintain a single data structure instance > > tests/core_hotunplug: Pass errors via a data structure field > > tests/core_hotunplug: Handle device close errors > > tests/core_hotunplug: Prepare invariant data once per test run > > tests/core_hotunplug: Skip selectively on sysfs close errors > > tests/core_hotunplug: Recover from subtest failures > > tests/core_hotunplug: Fail subtests on device close errors > > tests/core_hotunplug: Let the driver time out essential sysfs > > operations > > tests/core_hotunplug: Process return values of sysfs operations > > tests/core_hotunplug: Assert expected device presence/absence > > tests/core_hotunplug: Explicitly ignore unused return values > > tests/core_hotunplug: Also check health of render device node > > tests/core_hotunplug: More thorough i915 healthcheck and recovery > > tests/core_hotunplug: Add 'lateclose before restore' variants > > tests/core_hotunplug: Check health both before and after late close > > tests/core_hotunplug: HSW/BDW audio issue workaround > > tests/core_hotunplug: Duplicate debug messages in dmesg > > tests/core_hotunplug: Un-blocklist *bind* subtests > > tests/core_hotunplug: Add unbind-rebind subtest to BAT scope > > > > tests/core_hotunplug.c| 560 -- > > tests/intel-ci/blacklist.txt | 2 +- > > tests/intel-ci/fast-feedback.testlist | 1 + > > 3 files changed, 431 insertions(+), 132 deletions(-) > > > > -- > > 2.21.1 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 08/11] drm/i915: Link planes in a bigjoiner configuration, v3.
On Mon, Sep 14, 2020 at 10:20:41PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 14, 2020 at 12:14:10PM -0700, Navare, Manasi wrote:
> > On Thu, Sep 03, 2020 at 10:19:45PM +0300, Ville Syrjälä wrote:
> > > On Wed, Jul 15, 2020 at 03:42:19PM -0700, Manasi Navare wrote:
> > > > From: Maarten Lankhorst
> > > >
> > > > Make sure that when a plane is set in a bigjoiner mode, we will add
> > > > their counterpart to the atomic state as well. This will allow us to
> > > > make sure all state is available when planes are checked.
> > > >
> > > > Because of the funny interactions with bigjoiner and planar YUV
> > > > formats, we may end up adding a lot of planes, so we have to keep
> > > > iterating until we no longer add any planes.
> > > >
> > > > Also fix the atomic intel plane iterator, so things watermarks start
> > > > working automagically.
> > > >
> > > > v5:
> > > > * Rebase after adding sagv support (Manasi)
> > > > v4:
> > > > * Manual rebase (Manasi)
> > > > Changes since v1:
> > > > - Rebase on top of plane_state split, cleaning up the code a lot.
> > > > - Make intel_atomic_crtc_state_for_each_plane_state() bigjoiner capable.
> > > > - Add iter macro to intel_atomic_crtc_state_for_each_plane_state() to
> > > > keep iteration working.
> > > > Changes since v2:
> > > > - Add icl_(un)set_bigjoiner_plane_links, to make it more clear where
> > > > links are made and broken.
> > > >
> > > > Signed-off-by: Maarten Lankhorst
> > > > Signed-off-by: Manasi Navare
> > > > ---
> > > > .../gpu/drm/i915/display/intel_atomic_plane.c | 52 -
> > > > .../gpu/drm/i915/display/intel_atomic_plane.h | 3 +-
> > > > drivers/gpu/drm/i915/display/intel_display.c | 207 --
> > > > drivers/gpu/drm/i915/display/intel_display.h | 20 +-
> > > > .../drm/i915/display/intel_display_types.h| 11 +
> > > > drivers/gpu/drm/i915/intel_pm.c | 20 +-
> > > > 6 files changed, 274 insertions(+), 39 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > index 79032701873a..5c6e72063fac 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > @@ -246,11 +246,17 @@ static void intel_plane_clear_hw_state(struct
> > > > intel_plane_state *plane_state)
> > > > memset(&plane_state->hw, 0, sizeof(plane_state->hw));
> > > > }
> > > >
> > > > -void intel_plane_copy_uapi_to_hw_state(struct intel_plane_state
> > > > *plane_state,
> > > > +void intel_plane_copy_uapi_to_hw_state(const struct intel_crtc_state
> > > > *crtc_state,
> > > > + struct intel_plane_state
> > > > *plane_state,
> > > >const struct intel_plane_state
> > > > *from_plane_state)
> > > > {
> > > > intel_plane_clear_hw_state(plane_state);
> > > >
> > > > + if (from_plane_state->uapi.crtc)
> > > > + plane_state->hw.crtc = crtc_state->uapi.crtc;
> > > > + else
> > > > + plane_state->hw.crtc = NULL;
> > > > +
> > > > plane_state->hw.crtc = from_plane_state->uapi.crtc;
> > >
> > > eh?
> >
> > Hmm good catch here, this one definitely looks fishy probably got messed up
> > in the rebase
> > so this should just be:
> >
> > if (from_plane_state->uapi.crtc)
> > plane_state->hw.crtc = crtc_state->uapi.crtc;
> > else
> > plane_state->hw.crtc = NULL;
> >
> > And the reassignmnet of plane_state->hw.crtc should be removed.
> >
> > Good?
>
> The if-else seems totally pointless.
>
Hmm yes so we assume that if from_plane_state->uapi.crtc is NULL then
crtc_state->uapi.crtc is NULL?
Then just have plane_state->hw.crtc = crtc_state->uapi.crtc; without if-else?
Manasi
> >
> > >
> > > > plane_state->hw.fb = from_plane_state->uapi.fb;
> > > > if (plane_state->hw.fb)
> > > > @@ -319,15 +325,36 @@ int intel_plane_atomic_check_with_state(const
> > > > struct intel_crtc_state *old_crtc_
> > > > }
> > > >
> > > > static struct intel_crtc *
> > > > -get_crtc_from_states(const struct intel_plane_state *old_plane_state,
> > > > +get_crtc_from_states(struct intel_atomic_state *state,
> > > > +const struct intel_plane_state *old_plane_state,
> > > > const struct intel_plane_state *new_plane_state)
> > > > {
> > > > + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > > > + struct intel_plane *plane =
> > > > to_intel_plane(new_plane_state->uapi.plane);
> > > > +
> > > > if (new_plane_state->uapi.crtc)
> > > > return to_intel_crtc(new_plane_state->uapi.crtc);
> > > >
> > > > if (old_plane_state->uapi.crtc)
> > > > return to_intel_crtc(old_plane_state->uapi.crtc);
> > > >
> > > > + if (new_plane_state->bigjoiner_slave) {
> > > > + const str
Re: [Intel-gfx] [PATCH v6 08/11] drm/i915: Link planes in a bigjoiner configuration, v3.
On Mon, Sep 14, 2020 at 12:14:10PM -0700, Navare, Manasi wrote:
> On Thu, Sep 03, 2020 at 10:19:45PM +0300, Ville Syrjälä wrote:
> > On Wed, Jul 15, 2020 at 03:42:19PM -0700, Manasi Navare wrote:
> > > From: Maarten Lankhorst
> > >
> > > Make sure that when a plane is set in a bigjoiner mode, we will add
> > > their counterpart to the atomic state as well. This will allow us to
> > > make sure all state is available when planes are checked.
> > >
> > > Because of the funny interactions with bigjoiner and planar YUV
> > > formats, we may end up adding a lot of planes, so we have to keep
> > > iterating until we no longer add any planes.
> > >
> > > Also fix the atomic intel plane iterator, so things watermarks start
> > > working automagically.
> > >
> > > v5:
> > > * Rebase after adding sagv support (Manasi)
> > > v4:
> > > * Manual rebase (Manasi)
> > > Changes since v1:
> > > - Rebase on top of plane_state split, cleaning up the code a lot.
> > > - Make intel_atomic_crtc_state_for_each_plane_state() bigjoiner capable.
> > > - Add iter macro to intel_atomic_crtc_state_for_each_plane_state() to
> > > keep iteration working.
> > > Changes since v2:
> > > - Add icl_(un)set_bigjoiner_plane_links, to make it more clear where
> > > links are made and broken.
> > >
> > > Signed-off-by: Maarten Lankhorst
> > > Signed-off-by: Manasi Navare
> > > ---
> > > .../gpu/drm/i915/display/intel_atomic_plane.c | 52 -
> > > .../gpu/drm/i915/display/intel_atomic_plane.h | 3 +-
> > > drivers/gpu/drm/i915/display/intel_display.c | 207 --
> > > drivers/gpu/drm/i915/display/intel_display.h | 20 +-
> > > .../drm/i915/display/intel_display_types.h| 11 +
> > > drivers/gpu/drm/i915/intel_pm.c | 20 +-
> > > 6 files changed, 274 insertions(+), 39 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > index 79032701873a..5c6e72063fac 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > @@ -246,11 +246,17 @@ static void intel_plane_clear_hw_state(struct
> > > intel_plane_state *plane_state)
> > > memset(&plane_state->hw, 0, sizeof(plane_state->hw));
> > > }
> > >
> > > -void intel_plane_copy_uapi_to_hw_state(struct intel_plane_state
> > > *plane_state,
> > > +void intel_plane_copy_uapi_to_hw_state(const struct intel_crtc_state
> > > *crtc_state,
> > > +struct intel_plane_state *plane_state,
> > > const struct intel_plane_state
> > > *from_plane_state)
> > > {
> > > intel_plane_clear_hw_state(plane_state);
> > >
> > > + if (from_plane_state->uapi.crtc)
> > > + plane_state->hw.crtc = crtc_state->uapi.crtc;
> > > + else
> > > + plane_state->hw.crtc = NULL;
> > > +
> > > plane_state->hw.crtc = from_plane_state->uapi.crtc;
> >
> > eh?
>
> Hmm good catch here, this one definitely looks fishy probably got messed up
> in the rebase
> so this should just be:
>
> if (from_plane_state->uapi.crtc)
> plane_state->hw.crtc = crtc_state->uapi.crtc;
> else
>plane_state->hw.crtc = NULL;
>
> And the reassignmnet of plane_state->hw.crtc should be removed.
>
> Good?
The if-else seems totally pointless.
>
> >
> > > plane_state->hw.fb = from_plane_state->uapi.fb;
> > > if (plane_state->hw.fb)
> > > @@ -319,15 +325,36 @@ int intel_plane_atomic_check_with_state(const
> > > struct intel_crtc_state *old_crtc_
> > > }
> > >
> > > static struct intel_crtc *
> > > -get_crtc_from_states(const struct intel_plane_state *old_plane_state,
> > > +get_crtc_from_states(struct intel_atomic_state *state,
> > > + const struct intel_plane_state *old_plane_state,
> > >const struct intel_plane_state *new_plane_state)
> > > {
> > > + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > > + struct intel_plane *plane = to_intel_plane(new_plane_state->uapi.plane);
> > > +
> > > if (new_plane_state->uapi.crtc)
> > > return to_intel_crtc(new_plane_state->uapi.crtc);
> > >
> > > if (old_plane_state->uapi.crtc)
> > > return to_intel_crtc(old_plane_state->uapi.crtc);
> > >
> > > + if (new_plane_state->bigjoiner_slave) {
> > > + const struct intel_plane_state *new_master_plane_state =
> > > + intel_atomic_get_new_plane_state(state,
> > > new_plane_state->bigjoiner_plane);
> > > +
> > > + /* need to use uapi here, new_master_plane_state might not be
> > > copied to hw yet */
> > > + if (new_master_plane_state->uapi.crtc)
> > > + return intel_get_crtc_for_pipe(dev_priv, plane->pipe);
> > > + }
> > > +
> > > + if (old_plane_state->bigjoiner_slave) {
> > > + const struct intel_plane_state *old_master_plane_state =
> > > + intel_atomic_get_old_plane_state(state,
> > > o
Re: [Intel-gfx] [PATCH v6 10/11] drm/i915: Add intel_update_bigjoiner handling.
On Thu, Sep 03, 2020 at 10:23:35PM +0300, Ville Syrjälä wrote:
> On Wed, Jul 15, 2020 at 03:42:21PM -0700, Manasi Navare wrote:
> > From: Maarten Lankhorst
> >
> > Enabling is done in a special sequence and so should plane updates
> > be. Ideally the end user never notices the second pipe is used,
> > so use the vblank evasion to cover both pipes.
> >
> > This way ideally everything will be tear free, and updates are
> > really atomic as userspace expects it.
> >
> > This needs to be checked if it still works since lot of refactoring
> > in skl_commit_modeset_enables
> >
> > v2:
> > * Manual Rebase (Manasi)
> > * Refactoring on intel_update_crtc and enable_crtc and removing
> > special trans_port_sync_update (Manasi)
> >
> > Signed-off-by: Maarten Lankhorst
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 120 +--
> > drivers/gpu/drm/i915/display/intel_sprite.c | 25 +++-
> > drivers/gpu/drm/i915/display/intel_sprite.h | 3 +-
> > 3 files changed, 129 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index a1011414da6d..00b26863ffc6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -15656,7 +15656,7 @@ static void intel_update_crtc(struct
> > intel_atomic_state *state,
> > else
> > i9xx_update_planes_on_crtc(state, crtc);
> >
> > - intel_pipe_update_end(new_crtc_state);
> > + intel_pipe_update_end(new_crtc_state, NULL);
> >
> > /*
> > * We usually enable FIFO underrun interrupts as part of the
> > @@ -15754,6 +15754,52 @@ static void intel_commit_modeset_disables(struct
> > intel_atomic_state *state)
> > }
> > }
> >
> > +static void intel_update_bigjoiner(struct intel_crtc *crtc,
> > + struct intel_atomic_state *state,
> > + struct intel_crtc_state *old_crtc_state,
> > + struct intel_crtc_state *new_crtc_state)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > + bool modeset = needs_modeset(new_crtc_state);
> > + struct intel_crtc *slave = new_crtc_state->bigjoiner_linked_crtc;
> > + struct intel_crtc_state *new_slave_crtc_state =
> > + intel_atomic_get_new_crtc_state(state, slave);
> > +
> > + if (modeset) {
> > + /* Enable slave first */
> > + intel_crtc_update_active_timings(new_slave_crtc_state);
> > + dev_priv->display.crtc_enable(state, slave);
> > +
> > + /* Then master */
> > + intel_crtc_update_active_timings(new_crtc_state);
> > + dev_priv->display.crtc_enable(state, crtc);
> > +
> > + /* vblanks work again, re-enable pipe CRC. */
> > + intel_crtc_enable_pipe_crc(crtc);
> > +
> > + } else {
> > + intel_pre_plane_update(state, crtc);
> > + intel_pre_plane_update(state, slave);
> > +
> > + if (new_crtc_state->update_pipe)
> > + intel_encoders_update_pipe(state, crtc);
> > + }
> > +
> > + /*
> > +* Perform vblank evasion around commit operation, and make sure to
> > +* commit both planes simultaneously for best results.
> > +*/
> > + intel_pipe_update_start(new_crtc_state);
> > +
> > + commit_pipe_config(state, crtc);
> > + commit_pipe_config(state, slave);
> > +
> > + skl_update_planes_on_crtc(state, crtc);
> > + skl_update_planes_on_crtc(state, slave);
> > +
> > + intel_pipe_update_end(new_crtc_state, new_slave_crtc_state);
> > +}
>
> I think this should ideally all go away and just the normal logic
> in commit_modeset_enables() should deal with it. Just like it does
> for port sync/mst pipe dependencies.
>
Yes I think so too. Except for the intel_pipe_update_end where
now we send the new_slave_crtc_state() so thats still something I need to figure
how it will work in normal code without special bigjoiner handling.
I think the 2p2p transcoder ports sync code initially had a special trans port
sync handling
function and thats why this was written this way but with the new code we just
use
the regular modeset_enables function with no special handling
Manasi
> > +
> > static void intel_commit_modeset_enables(struct intel_atomic_state *state)
> > {
> > struct intel_crtc_state *new_crtc_state;
> > @@ -15772,15 +15818,22 @@ static void intel_commit_modeset_enables(struct
> > intel_atomic_state *state)
> > static void skl_commit_modeset_enables(struct intel_atomic_state *state)
> > {
> > struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > - struct intel_crtc *crtc;
> > + struct intel_crtc *crtc, *slave;
> > struct intel_crtc_state *old_crtc_state, *new_crtc_state;
> > struct skl_ddb_entry entries[I915_MAX_PIPES] = {};
> > + struct skl_ddb_entry new_entries[I915_MAX_PIPES] = {}
Re: [Intel-gfx] [PATCH v6 04/11] drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.
On Mon, Sep 14, 2020 at 12:00:33PM -0700, Navare, Manasi wrote:
> On Mon, Sep 07, 2020 at 02:20:56PM +0300, Ville Syrjälä wrote:
> > On Wed, Jul 15, 2020 at 03:42:15PM -0700, Manasi Navare wrote:
> > > From: Maarten Lankhorst
> > >
> > > Small changes to intel_dp_mode_valid(), allow listing modes that
> > > can only be supported in the bigjoiner configuration, which is
> > > not supported yet.
> > >
> > > eDP does not support bigjoiner, so do not expose bigjoiner only
> > > modes on the eDP port.
> > >
> > > v5:
> > > * Increase max plane width to support 8K with bigjoiner (Maarten)
> > > v4:
> > > * Rebase (Manasi)
> > >
> > > Changes since v1:
> > > - Disallow bigjoiner on eDP.
> > > Changes since v2:
> > > - Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock,
> > > and split off the downstream and source checking to its own function.
> > > (Ville)
> > > v3:
> > > * Rebase (Manasi)
> > >
> > > Signed-off-by: Manasi Navare
> > > Signed-off-by: Maarten Lankhorst
> > > ---
> > > drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> > > drivers/gpu/drm/i915/display/intel_dp.c | 119 ++-
> > > 2 files changed, 91 insertions(+), 30 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 78cbfefbfa62..3ecb642805a6 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -17400,7 +17400,7 @@ intel_mode_valid_max_plane_size(struct
> > > drm_i915_private *dev_priv,
> > >* too big for that.
> > >*/
> > > if (INTEL_GEN(dev_priv) >= 11) {
> > > - plane_width_max = 5120;
> > > + plane_width_max = 7680;
> >
> > This looks misplaced. Planes do no know whether bigjoiner can be used or
> > not. They should not care in fact. The caller should have that knowledge
> > and can deal with it properly.
>
> Hmm, so the caller of intel_mode_valid_max_plane_size() should check on the
> bigjoiner
> flag and perhaps if bigjoiner is true then increase the plane_width_max to
> 7680?
>
> Am still not sure where this should happen? We need to have the plane max
> width to be 7680
> before we prune the 8K mode in intel_mode_valid
>
> Where should this be added according to you?
Hmm. I guess we do need to put it into this function given the way this
is structured. However we still can't assume bigjoiner can be used since
it can't be used on DDI A on icl. So we should probably just pass in a
bool here to indicate whether bigjoiner can be used or not.
Personally I'd just write the thing as something like:
intel_mode_valid_max_plane_size(..., bool bigjoiner)
{
...
plane_width_max = 5120 << bigjoiner;
...
}
>
> Manasi
> >
> > > plane_height_max = 4320;
> > > } else {
> > > plane_width_max = 5120;
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index d6295eb20b63..fbfea99fd804 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -248,25 +248,37 @@ intel_dp_max_data_rate(int max_link_clock, int
> > > max_lanes)
> > > return max_link_clock * max_lanes;
> > > }
> > >
> > > -static int
> > > -intel_dp_downstream_max_dotclock(struct intel_dp *intel_dp)
> > > +static int source_max_dotclock(struct intel_dp *intel_dp, bool
> > > allow_bigjoiner)
> > > {
> > > - struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > > - struct intel_encoder *encoder = &dig_port->base;
> > > + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > > + struct intel_encoder *encoder = &intel_dig_port->base;
> > > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > > - int max_dotclk = dev_priv->max_dotclk_freq;
> > > - int ds_max_dotclk;
> > >
> > > + if (allow_bigjoiner && INTEL_GEN(dev_priv) >= 11 &&
> > > !intel_dp_is_edp(intel_dp))
> > > + return 2 * dev_priv->max_dotclk_freq;
> > > +
> > > + return dev_priv->max_dotclk_freq;
> > > +}
> > > +
> > > +static int downstream_max_dotclock(struct intel_dp *intel_dp)
> > > +{
> > > int type = intel_dp->downstream_ports[0] & DP_DS_PORT_TYPE_MASK;
> > >
> > > if (type != DP_DS_PORT_TYPE_VGA)
> > > - return max_dotclk;
> > > + return 0;
> > >
> > > - ds_max_dotclk = drm_dp_downstream_max_clock(intel_dp->dpcd,
> > > - intel_dp->downstream_ports);
> > > + return drm_dp_downstream_max_clock(intel_dp->dpcd,
> > > +intel_dp->downstream_ports);
> > > +}
> > > +
> > > +static int
> > > +intel_dp_max_dotclock(struct intel_dp *intel_dp, bool allow_bigjoiner)
> > > +{
> > > + int max_dotclk = source_max_dotclock(intel_dp, allow_bigjoiner);
> > > + int ds_max_dotclk = downstream_max_dotclock(intel_dp);
> > >
> > > if (ds_max_dotclk != 0)
Re: [Intel-gfx] [PATCH v6 08/11] drm/i915: Link planes in a bigjoiner configuration, v3.
On Thu, Sep 03, 2020 at 10:19:45PM +0300, Ville Syrjälä wrote:
> On Wed, Jul 15, 2020 at 03:42:19PM -0700, Manasi Navare wrote:
> > From: Maarten Lankhorst
> >
> > Make sure that when a plane is set in a bigjoiner mode, we will add
> > their counterpart to the atomic state as well. This will allow us to
> > make sure all state is available when planes are checked.
> >
> > Because of the funny interactions with bigjoiner and planar YUV
> > formats, we may end up adding a lot of planes, so we have to keep
> > iterating until we no longer add any planes.
> >
> > Also fix the atomic intel plane iterator, so things watermarks start
> > working automagically.
> >
> > v5:
> > * Rebase after adding sagv support (Manasi)
> > v4:
> > * Manual rebase (Manasi)
> > Changes since v1:
> > - Rebase on top of plane_state split, cleaning up the code a lot.
> > - Make intel_atomic_crtc_state_for_each_plane_state() bigjoiner capable.
> > - Add iter macro to intel_atomic_crtc_state_for_each_plane_state() to
> > keep iteration working.
> > Changes since v2:
> > - Add icl_(un)set_bigjoiner_plane_links, to make it more clear where
> > links are made and broken.
> >
> > Signed-off-by: Maarten Lankhorst
> > Signed-off-by: Manasi Navare
> > ---
> > .../gpu/drm/i915/display/intel_atomic_plane.c | 52 -
> > .../gpu/drm/i915/display/intel_atomic_plane.h | 3 +-
> > drivers/gpu/drm/i915/display/intel_display.c | 207 --
> > drivers/gpu/drm/i915/display/intel_display.h | 20 +-
> > .../drm/i915/display/intel_display_types.h| 11 +
> > drivers/gpu/drm/i915/intel_pm.c | 20 +-
> > 6 files changed, 274 insertions(+), 39 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > index 79032701873a..5c6e72063fac 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > @@ -246,11 +246,17 @@ static void intel_plane_clear_hw_state(struct
> > intel_plane_state *plane_state)
> > memset(&plane_state->hw, 0, sizeof(plane_state->hw));
> > }
> >
> > -void intel_plane_copy_uapi_to_hw_state(struct intel_plane_state
> > *plane_state,
> > +void intel_plane_copy_uapi_to_hw_state(const struct intel_crtc_state
> > *crtc_state,
> > + struct intel_plane_state *plane_state,
> >const struct intel_plane_state
> > *from_plane_state)
> > {
> > intel_plane_clear_hw_state(plane_state);
> >
> > + if (from_plane_state->uapi.crtc)
> > + plane_state->hw.crtc = crtc_state->uapi.crtc;
> > + else
> > + plane_state->hw.crtc = NULL;
> > +
> > plane_state->hw.crtc = from_plane_state->uapi.crtc;
>
> eh?
Hmm good catch here, this one definitely looks fishy probably got messed up in
the rebase
so this should just be:
if (from_plane_state->uapi.crtc)
plane_state->hw.crtc = crtc_state->uapi.crtc;
else
plane_state->hw.crtc = NULL;
And the reassignmnet of plane_state->hw.crtc should be removed.
Good?
>
> > plane_state->hw.fb = from_plane_state->uapi.fb;
> > if (plane_state->hw.fb)
> > @@ -319,15 +325,36 @@ int intel_plane_atomic_check_with_state(const struct
> > intel_crtc_state *old_crtc_
> > }
> >
> > static struct intel_crtc *
> > -get_crtc_from_states(const struct intel_plane_state *old_plane_state,
> > +get_crtc_from_states(struct intel_atomic_state *state,
> > +const struct intel_plane_state *old_plane_state,
> > const struct intel_plane_state *new_plane_state)
> > {
> > + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > + struct intel_plane *plane = to_intel_plane(new_plane_state->uapi.plane);
> > +
> > if (new_plane_state->uapi.crtc)
> > return to_intel_crtc(new_plane_state->uapi.crtc);
> >
> > if (old_plane_state->uapi.crtc)
> > return to_intel_crtc(old_plane_state->uapi.crtc);
> >
> > + if (new_plane_state->bigjoiner_slave) {
> > + const struct intel_plane_state *new_master_plane_state =
> > + intel_atomic_get_new_plane_state(state,
> > new_plane_state->bigjoiner_plane);
> > +
> > + /* need to use uapi here, new_master_plane_state might not be
> > copied to hw yet */
> > + if (new_master_plane_state->uapi.crtc)
> > + return intel_get_crtc_for_pipe(dev_priv, plane->pipe);
> > + }
> > +
> > + if (old_plane_state->bigjoiner_slave) {
> > + const struct intel_plane_state *old_master_plane_state =
> > + intel_atomic_get_old_plane_state(state,
> > old_plane_state->bigjoiner_plane);
> > +
> > + if (old_master_plane_state->uapi.crtc)
> > + return intel_get_crtc_for_pipe(dev_priv, plane->pipe);
> > + }
> > +
> > return NULL;
> > }
> >
> > @@ -338,18 +365,33 @@ int intel_plane_atomic_chec
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pll: Centralize PLL_ENABLE register lookup (rev5)
== Series Details ==
Series: drm/i915/pll: Centralize PLL_ENABLE register lookup (rev5)
URL : https://patchwork.freedesktop.org/series/81150/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9007 -> Patchwork_18494
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/index.html
Known issues
Here are the changes found in Patchwork_18494 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_flink_basic@basic:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar
issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-tgl-y/igt@gem_flink_ba...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/fi-tgl-y/igt@gem_flink_ba...@basic.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_9007/fi-byt-j1900/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
Possible fixes
* igt@gem_flink_basic@bad-flink:
- fi-tgl-y: [DMESG-WARN][7] ([i915#402]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@execlists:
- fi-icl-y: [INCOMPLETE][11] ([i915#2276]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-icl-y/igt@i915_selftest@l...@execlists.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/fi-icl-y/igt@i915_selftest@l...@execlists.html
* igt@kms_busy@basic@flip:
- fi-tgl-y: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-tgl-y/igt@kms_busy@ba...@flip.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/fi-tgl-y/igt@kms_busy@ba...@flip.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u: [DMESG-WARN][15] ([i915#2203]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
Warnings
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-tgl-y: [DMESG-WARN][17] ([i915#1982] / [i915#2411]) ->
[DMESG-WARN][18] ([i915#2411])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][19] ([i915#62]) -> [DMESG-FAIL][20]
([i915#62] / [i915#95])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92]) ->
[DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +6 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.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_9007/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18494/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name
Re: [Intel-gfx] [PATCH v6 04/11] drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.
On Mon, Sep 07, 2020 at 02:20:56PM +0300, Ville Syrjälä wrote:
> On Wed, Jul 15, 2020 at 03:42:15PM -0700, Manasi Navare wrote:
> > From: Maarten Lankhorst
> >
> > Small changes to intel_dp_mode_valid(), allow listing modes that
> > can only be supported in the bigjoiner configuration, which is
> > not supported yet.
> >
> > eDP does not support bigjoiner, so do not expose bigjoiner only
> > modes on the eDP port.
> >
> > v5:
> > * Increase max plane width to support 8K with bigjoiner (Maarten)
> > v4:
> > * Rebase (Manasi)
> >
> > Changes since v1:
> > - Disallow bigjoiner on eDP.
> > Changes since v2:
> > - Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock,
> > and split off the downstream and source checking to its own function.
> > (Ville)
> > v3:
> > * Rebase (Manasi)
> >
> > Signed-off-by: Manasi Navare
> > Signed-off-by: Maarten Lankhorst
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> > drivers/gpu/drm/i915/display/intel_dp.c | 119 ++-
> > 2 files changed, 91 insertions(+), 30 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 78cbfefbfa62..3ecb642805a6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -17400,7 +17400,7 @@ intel_mode_valid_max_plane_size(struct
> > drm_i915_private *dev_priv,
> > * too big for that.
> > */
> > if (INTEL_GEN(dev_priv) >= 11) {
> > - plane_width_max = 5120;
> > + plane_width_max = 7680;
>
> This looks misplaced. Planes do no know whether bigjoiner can be used or
> not. They should not care in fact. The caller should have that knowledge
> and can deal with it properly.
Hmm, so the caller of intel_mode_valid_max_plane_size() should check on the
bigjoiner
flag and perhaps if bigjoiner is true then increase the plane_width_max to 7680?
Am still not sure where this should happen? We need to have the plane max width
to be 7680
before we prune the 8K mode in intel_mode_valid
Where should this be added according to you?
Manasi
>
> > plane_height_max = 4320;
> > } else {
> > plane_width_max = 5120;
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index d6295eb20b63..fbfea99fd804 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -248,25 +248,37 @@ intel_dp_max_data_rate(int max_link_clock, int
> > max_lanes)
> > return max_link_clock * max_lanes;
> > }
> >
> > -static int
> > -intel_dp_downstream_max_dotclock(struct intel_dp *intel_dp)
> > +static int source_max_dotclock(struct intel_dp *intel_dp, bool
> > allow_bigjoiner)
> > {
> > - struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > - struct intel_encoder *encoder = &dig_port->base;
> > + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > + struct intel_encoder *encoder = &intel_dig_port->base;
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > - int max_dotclk = dev_priv->max_dotclk_freq;
> > - int ds_max_dotclk;
> >
> > + if (allow_bigjoiner && INTEL_GEN(dev_priv) >= 11 &&
> > !intel_dp_is_edp(intel_dp))
> > + return 2 * dev_priv->max_dotclk_freq;
> > +
> > + return dev_priv->max_dotclk_freq;
> > +}
> > +
> > +static int downstream_max_dotclock(struct intel_dp *intel_dp)
> > +{
> > int type = intel_dp->downstream_ports[0] & DP_DS_PORT_TYPE_MASK;
> >
> > if (type != DP_DS_PORT_TYPE_VGA)
> > - return max_dotclk;
> > + return 0;
> >
> > - ds_max_dotclk = drm_dp_downstream_max_clock(intel_dp->dpcd,
> > - intel_dp->downstream_ports);
> > + return drm_dp_downstream_max_clock(intel_dp->dpcd,
> > + intel_dp->downstream_ports);
> > +}
> > +
> > +static int
> > +intel_dp_max_dotclock(struct intel_dp *intel_dp, bool allow_bigjoiner)
> > +{
> > + int max_dotclk = source_max_dotclock(intel_dp, allow_bigjoiner);
> > + int ds_max_dotclk = downstream_max_dotclock(intel_dp);
> >
> > if (ds_max_dotclk != 0)
> > - max_dotclk = min(max_dotclk, ds_max_dotclk);
> > + return min(max_dotclk, ds_max_dotclk);
> >
> > return max_dotclk;
> > }
> > @@ -527,7 +539,8 @@ small_joiner_ram_size_bits(struct drm_i915_private
> > *i915)
> >
> > static u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> >u32 link_clock, u32 lane_count,
> > - u32 mode_clock, u32 mode_hdisplay)
> > + u32 mode_clock, u32 mode_hdisplay,
> > + bool bigjoiner)
> > {
> > u32 bits_per_pixel, max_bpp_small_joiner_ram;
> > int i;
> > @@ -545,6 +558,10
Re: [Intel-gfx] [PATCH v6 02/11] drm/i915: Remove hw.mode
On Mon, Sep 14, 2020 at 11:32:48AM -0700, Navare, Manasi wrote:
> On Mon, Sep 07, 2020 at 03:35:23PM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 03, 2020 at 09:40:44PM +0300, Ville Syrjälä wrote:
> > > On Thu, Sep 03, 2020 at 11:04:33AM -0700, Navare, Manasi wrote:
> > > > On Thu, Sep 03, 2020 at 08:49:44PM +0300, Ville Syrjälä wrote:
> > > > > On Wed, Jul 15, 2020 at 03:42:13PM -0700, Manasi Navare wrote:
> > > > > > From: Maarten Lankhorst
> > > > > >
> > > > > > The members in hw.mode can be used from adjusted_mode as well,
> > > > > > use that when available.
> > > > > >
> > > > > > Some places that use hw.mode can be converted to use adjusted_mode
> > > > > > as well.
> > > > > >
> > > > > > v2:
> > > > > > * Manual rebase (Manasi)
> > > > > > * remove the use of pipe_mode defined in patch 3 (Manasi)
> > > > > >
> > > > > > v3:
> > > > > > * Rebase on drm-tip (Manasi)
> > > > >
> > > > > Previous review was apparently ignored. Or is there a better version
> > > > > somewhere? If not, this still looks very wrong.
> > > >
> > > > This was the latest rev that Maarten had in his local tree which he
> > > > said should address all the review comments.
> > > > What in particular looks wrong or what review comments were unaddressed
> > > > here?
> > >
> > > The dvo/sdvo changes.
> >
> > I recommend just dropping this patch entirely. It doesn't seem to have
> > anything to do with the bigjoiner anyway.
>
> So for the dvo/svdo changes, no need to use the adjusted_mode instead keep
> using hw.mode?
> How about other cleanups like: intel_crtc_copy_hw_to_uapi_state(crtc_state,
> &mode); and
> static void intel_crtc_copy_hw_to_uapi_state(struct intel_crtc_state
> *crtc_state,
> + struct drm_display_mode *user_mode)
>
> You think we dont need mode as an argument there either?
Not in this patch if all the other stuff disappears. No idea if some
later patch might need something like it.
>
> Manasi
> >
> > >
> > > >
> > > > @Maarten any feedback on Ville's unaddressed comments?
> > > >
> > > > Manasi
> > > >
> > > > >
> > > > > >
> > > > > > Signed-off-by: Maarten Lankhorst
> > > > > > Signed-off-by: Manasi Navare
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/display/intel_display.c | 29
> > > > > > ++-
> > > > > > .../drm/i915/display/intel_display_types.h| 2 +-
> > > > > > drivers/gpu/drm/i915/display/intel_dvo.c | 2 +-
> > > > > > drivers/gpu/drm/i915/display/intel_sdvo.c | 16 --
> > > > > > 4 files changed, 23 insertions(+), 26 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > index 729ec6e0d43a..8652a7c6bf11 100644
> > > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > @@ -8892,9 +8892,6 @@ static void intel_get_pipe_src_size(struct
> > > > > > intel_crtc *crtc,
> > > > > > tmp = intel_de_read(dev_priv, PIPESRC(crtc->pipe));
> > > > > > pipe_config->pipe_src_h = (tmp & 0x) + 1;
> > > > > > pipe_config->pipe_src_w = ((tmp >> 16) & 0x) + 1;
> > > > > > -
> > > > > > - pipe_config->hw.mode.vdisplay = pipe_config->pipe_src_h;
> > > > > > - pipe_config->hw.mode.hdisplay = pipe_config->pipe_src_w;
> > > > > > }
> > > > > >
> > > > > > void intel_mode_from_pipe_config(struct drm_display_mode *mode,
> > > > > > @@ -13079,7 +13076,7 @@ static void intel_dump_pipe_config(const
> > > > > > struct intel_crtc_state *pipe_config,
> > > > > > intel_dump_dp_vsc_sdp(dev_priv,
> > > > > > &pipe_config->infoframes.vsc);
> > > > > >
> > > > > > drm_dbg_kms(&dev_priv->drm, "requested mode:\n");
> > > > > > - drm_mode_debug_printmodeline(&pipe_config->hw.mode);
> > > > > > + drm_mode_debug_printmodeline(&pipe_config->uapi.mode);
> > > > > > drm_dbg_kms(&dev_priv->drm, "adjusted mode:\n");
> > > > > > drm_mode_debug_printmodeline(&pipe_config->hw.adjusted_mode);
> > > > > > intel_dump_crtc_timings(dev_priv,
> > > > > > &pipe_config->hw.adjusted_mode);
> > > > > > @@ -13221,17 +13218,17 @@ intel_crtc_copy_uapi_to_hw_state(struct
> > > > > > intel_crtc_state *crtc_state)
> > > > > > {
> > > > > > crtc_state->hw.enable = crtc_state->uapi.enable;
> > > > > > crtc_state->hw.active = crtc_state->uapi.active;
> > > > > > - crtc_state->hw.mode = crtc_state->uapi.mode;
> > > > > > crtc_state->hw.adjusted_mode = crtc_state->uapi.adjusted_mode;
> > > > > > intel_crtc_copy_uapi_to_hw_state_nomodeset(crtc_state);
> > > > > > }
> > > > > >
> > > > > > -static void intel_crtc_copy_hw_to_uapi_state(struct
> > > > > > intel_crtc_state *crtc_state)
> > > > > > +static void intel_crtc_copy_hw_to_uapi_state(struct
> > > > > > intel_crtc_state *crtc_state,
> > > > > > +struct drm_display_mode
> > > > > > *user_mod
Re: [Intel-gfx] [PATCH v6 03/11] drm/i915: Add hw.pipe_mode to allow bigjoiner pipe/transcoder split
On Mon, Sep 14, 2020 at 11:45:37AM -0700, Navare, Manasi wrote:
> On Thu, Sep 03, 2020 at 08:54:40PM +0300, Ville Syrjälä wrote:
> > On Wed, Jul 15, 2020 at 03:42:14PM -0700, Manasi Navare wrote:
> > > From: Maarten Lankhorst
> > >
> > > v4:
> > > * Manual rebase (Manasi)
> > > v3:
> > > * Change state to crtc_state, fix rebase err (Manasi)
> > > v2:
> > > * Manual Rebase (Manasi)
> > >
> > > Signed-off-by: Maarten Lankhorst
> > > Signed-off-by: Manasi Navare
> > > ---
> > > drivers/gpu/drm/i915/display/intel_display.c | 61 ---
> > > .../drm/i915/display/intel_display_types.h| 11 ++-
> > > drivers/gpu/drm/i915/intel_pm.c | 76 +--
> > > 3 files changed, 79 insertions(+), 69 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 8652a7c6bf11..78cbfefbfa62 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -152,7 +152,7 @@ static void ilk_pch_clock_get(struct intel_crtc *crtc,
> > > static int intel_framebuffer_init(struct intel_framebuffer *ifb,
> > > struct drm_i915_gem_object *obj,
> > > struct drm_mode_fb_cmd2 *mode_cmd);
> > > -static void intel_set_pipe_timings(const struct intel_crtc_state
> > > *crtc_state);
> > > +static void intel_set_transcoder_timings(const struct intel_crtc_state
> > > *crtc_state);
> >
> > These renames make it hard to see what changed. Should be split out.
>
> So just have the renaming in separate patch?
Yeah.
>
> Manasi
> >
> > > static void intel_set_pipe_src_size(const struct intel_crtc_state
> > > *crtc_state);
> > > static void intel_cpu_transcoder_set_m_n(const struct intel_crtc_state
> > > *crtc_state,
> > >const struct intel_link_m_n *m_n,
> > > @@ -6110,18 +6110,16 @@ skl_update_scaler(struct intel_crtc_state
> > > *crtc_state, bool force_detach,
> > >
> > > static int skl_update_scaler_crtc(struct intel_crtc_state *crtc_state)
> > > {
> > > - const struct drm_display_mode *adjusted_mode =
> > > - &crtc_state->hw.adjusted_mode;
> > > + const struct drm_display_mode *pipe_mode = &crtc_state->hw.pipe_mode;
> > > int width, height;
> > >
> > > if (crtc_state->pch_pfit.enabled) {
> > > width = drm_rect_width(&crtc_state->pch_pfit.dst);
> > > height = drm_rect_height(&crtc_state->pch_pfit.dst);
> > > } else {
> > > - width = adjusted_mode->crtc_hdisplay;
> > > - height = adjusted_mode->crtc_vdisplay;
> > > + width = pipe_mode->crtc_hdisplay;
> > > + height = pipe_mode->crtc_vdisplay;
> > > }
> > > -
> > > return skl_update_scaler(crtc_state, !crtc_state->hw.active,
> > >SKL_CRTC_INDEX,
> > >&crtc_state->scaler_state.scaler_id,
> > > @@ -6901,7 +6899,7 @@ static void ilk_crtc_enable(struct
> > > intel_atomic_state *state,
> > > if (intel_crtc_has_dp_encoder(new_crtc_state))
> > > intel_dp_set_m_n(new_crtc_state, M1_N1);
> > >
> > > - intel_set_pipe_timings(new_crtc_state);
> > > + intel_set_transcoder_timings(new_crtc_state);
> > > intel_set_pipe_src_size(new_crtc_state);
> > >
> > > if (new_crtc_state->has_pch_encoder)
> > > @@ -7046,7 +7044,7 @@ static void hsw_crtc_enable(struct
> > > intel_atomic_state *state,
> > > intel_encoders_pre_enable(state, crtc);
> > >
> > > if (!transcoder_is_dsi(cpu_transcoder))
> > > - intel_set_pipe_timings(new_crtc_state);
> > > + intel_set_transcoder_timings(new_crtc_state);
> > >
> > > intel_set_pipe_src_size(new_crtc_state);
> > >
> > > @@ -7429,7 +7427,7 @@ static void valleyview_crtc_enable(struct
> > > intel_atomic_state *state,
> > > if (intel_crtc_has_dp_encoder(new_crtc_state))
> > > intel_dp_set_m_n(new_crtc_state, M1_N1);
> > >
> > > - intel_set_pipe_timings(new_crtc_state);
> > > + intel_set_transcoder_timings(new_crtc_state);
> > > intel_set_pipe_src_size(new_crtc_state);
> > >
> > > if (IS_CHERRYVIEW(dev_priv) && pipe == PIPE_B) {
> > > @@ -7497,7 +7495,7 @@ static void i9xx_crtc_enable(struct
> > > intel_atomic_state *state,
> > > if (intel_crtc_has_dp_encoder(new_crtc_state))
> > > intel_dp_set_m_n(new_crtc_state, M1_N1);
> > >
> > > - intel_set_pipe_timings(new_crtc_state);
> > > + intel_set_transcoder_timings(new_crtc_state);
> > > intel_set_pipe_src_size(new_crtc_state);
> > >
> > > i9xx_set_pipeconf(new_crtc_state);
> > > @@ -7971,7 +7969,7 @@ static bool intel_crtc_supports_double_wide(const
> > > struct intel_crtc *crtc)
> > >
> > > static u32 ilk_pipe_pixel_rate(const struct intel_crtc_state *crtc_state)
> > > {
> > > - u32 pixel_rate = crtc_state->hw.adjusted_mode.crtc_clock;
> > > + u32 pixel_rate = crtc_state->hw.pipe_mode.crtc_clock;
> > > unsigned int pipe
Re: [Intel-gfx] [PATCH v6 03/11] drm/i915: Add hw.pipe_mode to allow bigjoiner pipe/transcoder split
On Thu, Sep 03, 2020 at 08:54:40PM +0300, Ville Syrjälä wrote:
> On Wed, Jul 15, 2020 at 03:42:14PM -0700, Manasi Navare wrote:
> > From: Maarten Lankhorst
> >
> > v4:
> > * Manual rebase (Manasi)
> > v3:
> > * Change state to crtc_state, fix rebase err (Manasi)
> > v2:
> > * Manual Rebase (Manasi)
> >
> > Signed-off-by: Maarten Lankhorst
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 61 ---
> > .../drm/i915/display/intel_display_types.h| 11 ++-
> > drivers/gpu/drm/i915/intel_pm.c | 76 +--
> > 3 files changed, 79 insertions(+), 69 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 8652a7c6bf11..78cbfefbfa62 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -152,7 +152,7 @@ static void ilk_pch_clock_get(struct intel_crtc *crtc,
> > static int intel_framebuffer_init(struct intel_framebuffer *ifb,
> > struct drm_i915_gem_object *obj,
> > struct drm_mode_fb_cmd2 *mode_cmd);
> > -static void intel_set_pipe_timings(const struct intel_crtc_state
> > *crtc_state);
> > +static void intel_set_transcoder_timings(const struct intel_crtc_state
> > *crtc_state);
>
> These renames make it hard to see what changed. Should be split out.
So just have the renaming in separate patch?
Manasi
>
> > static void intel_set_pipe_src_size(const struct intel_crtc_state
> > *crtc_state);
> > static void intel_cpu_transcoder_set_m_n(const struct intel_crtc_state
> > *crtc_state,
> > const struct intel_link_m_n *m_n,
> > @@ -6110,18 +6110,16 @@ skl_update_scaler(struct intel_crtc_state
> > *crtc_state, bool force_detach,
> >
> > static int skl_update_scaler_crtc(struct intel_crtc_state *crtc_state)
> > {
> > - const struct drm_display_mode *adjusted_mode =
> > - &crtc_state->hw.adjusted_mode;
> > + const struct drm_display_mode *pipe_mode = &crtc_state->hw.pipe_mode;
> > int width, height;
> >
> > if (crtc_state->pch_pfit.enabled) {
> > width = drm_rect_width(&crtc_state->pch_pfit.dst);
> > height = drm_rect_height(&crtc_state->pch_pfit.dst);
> > } else {
> > - width = adjusted_mode->crtc_hdisplay;
> > - height = adjusted_mode->crtc_vdisplay;
> > + width = pipe_mode->crtc_hdisplay;
> > + height = pipe_mode->crtc_vdisplay;
> > }
> > -
> > return skl_update_scaler(crtc_state, !crtc_state->hw.active,
> > SKL_CRTC_INDEX,
> > &crtc_state->scaler_state.scaler_id,
> > @@ -6901,7 +6899,7 @@ static void ilk_crtc_enable(struct intel_atomic_state
> > *state,
> > if (intel_crtc_has_dp_encoder(new_crtc_state))
> > intel_dp_set_m_n(new_crtc_state, M1_N1);
> >
> > - intel_set_pipe_timings(new_crtc_state);
> > + intel_set_transcoder_timings(new_crtc_state);
> > intel_set_pipe_src_size(new_crtc_state);
> >
> > if (new_crtc_state->has_pch_encoder)
> > @@ -7046,7 +7044,7 @@ static void hsw_crtc_enable(struct intel_atomic_state
> > *state,
> > intel_encoders_pre_enable(state, crtc);
> >
> > if (!transcoder_is_dsi(cpu_transcoder))
> > - intel_set_pipe_timings(new_crtc_state);
> > + intel_set_transcoder_timings(new_crtc_state);
> >
> > intel_set_pipe_src_size(new_crtc_state);
> >
> > @@ -7429,7 +7427,7 @@ static void valleyview_crtc_enable(struct
> > intel_atomic_state *state,
> > if (intel_crtc_has_dp_encoder(new_crtc_state))
> > intel_dp_set_m_n(new_crtc_state, M1_N1);
> >
> > - intel_set_pipe_timings(new_crtc_state);
> > + intel_set_transcoder_timings(new_crtc_state);
> > intel_set_pipe_src_size(new_crtc_state);
> >
> > if (IS_CHERRYVIEW(dev_priv) && pipe == PIPE_B) {
> > @@ -7497,7 +7495,7 @@ static void i9xx_crtc_enable(struct
> > intel_atomic_state *state,
> > if (intel_crtc_has_dp_encoder(new_crtc_state))
> > intel_dp_set_m_n(new_crtc_state, M1_N1);
> >
> > - intel_set_pipe_timings(new_crtc_state);
> > + intel_set_transcoder_timings(new_crtc_state);
> > intel_set_pipe_src_size(new_crtc_state);
> >
> > i9xx_set_pipeconf(new_crtc_state);
> > @@ -7971,7 +7969,7 @@ static bool intel_crtc_supports_double_wide(const
> > struct intel_crtc *crtc)
> >
> > static u32 ilk_pipe_pixel_rate(const struct intel_crtc_state *crtc_state)
> > {
> > - u32 pixel_rate = crtc_state->hw.adjusted_mode.crtc_clock;
> > + u32 pixel_rate = crtc_state->hw.pipe_mode.crtc_clock;
> > unsigned int pipe_w, pipe_h, pfit_w, pfit_h;
> >
> > /*
> > @@ -8008,7 +8006,7 @@ static void intel_crtc_compute_pixel_rate(struct
> > intel_crtc_state *crtc_state)
> > if (HAS_GMCH(dev_priv))
> > /* FIXME
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/pll: Centralize PLL_ENABLE register lookup (rev5)
== Series Details ==
Series: drm/i915/pll: Centralize PLL_ENABLE register lookup (rev5)
URL : https://patchwork.freedesktop.org/series/81150/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f5ec8439a17d drm/i915/pll: Centralize PLL_ENABLE register lookup
-:38: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#38: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:154:
+{
+
-:39: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around
'pll->info->id == DPLL_ID_EHL_DPLL4'
#39: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:155:
+ if (IS_ELKHARTLAKE(i915) && (pll->info->id == DPLL_ID_EHL_DPLL4))
-:44: CHECK:LINE_SPACING: Please don't use multiple blank lines
#44: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:160:
+
+
-:45: CHECK:BRACES: Blank lines aren't necessary before a close brace '}'
#45: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:161:
+
+}
total: 0 errors, 0 warnings, 4 checks, 66 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 series starting with [1/2] drm/i915: Reduce INTEL_DISPLAY_ENABLED to just removing the outputs (rev4)
== Series Details == Series: series starting with [1/2] drm/i915: Reduce INTEL_DISPLAY_ENABLED to just removing the outputs (rev4) URL : https://patchwork.freedesktop.org/series/81507/ State : success == Summary == CI Bug Log - changes from CI_DRM_9007 -> Patchwork_18492 Summary --- **WARNING** Minor unknown changes coming with Patchwork_18492 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18492, 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_18492/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18492: ### IGT changes ### Warnings * igt@i915_selftest@live@gt_lrc: - fi-tgl-y: [DMESG-FAIL][1] ([i915#2373]) -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-tgl-y/igt@i915_selftest@live@gt_lrc.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18492/fi-tgl-y/igt@i915_selftest@live@gt_lrc.html Known issues Here are the changes found in Patchwork_18492 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@dmabuf: - fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#289]) +31 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-icl-u2/igt@i915_selftest@l...@dmabuf.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18492/fi-icl-u2/igt@i915_selftest@l...@dmabuf.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_9007/fi-kbl-x1275/igt@kms_busy@ba...@flip.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18492/fi-kbl-x1275/igt@kms_busy@ba...@flip.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-glk-dsi: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-glk-dsi/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18492/fi-glk-dsi/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@prime_vgem@basic-read: - fi-tgl-y: [PASS][9] -> [DMESG-WARN][10] ([i915#402]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-tgl-y/igt@prime_v...@basic-read.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18492/fi-tgl-y/igt@prime_v...@basic-read.html Possible fixes * igt@gem_flink_basic@bad-flink: - fi-tgl-y: [DMESG-WARN][11] ([i915#402]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18492/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18492/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_selftest@live@execlists: - fi-icl-y: [INCOMPLETE][15] ([i915#2276]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-icl-y/igt@i915_selftest@l...@execlists.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18492/fi-icl-y/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-7500u: [DMESG-WARN][17] ([i915#2203]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18492/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-tgl-y: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20] +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-tgl-y/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18492/fi-tgl-y/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92]) -> [DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [22]: https://intel-gfx-ci
Re: [Intel-gfx] [PULL] gvt-next
> On Sep 13, 2020, at 7:34 PM, Zhenyu Wang wrote: > > On 2020.09.11 19:58:25 -0400, Rodrigo Vivi wrote: >> On Thu, Sep 10, 2020 at 01:37:20PM +0800, Zhenyu Wang wrote: >>> >>> Hi, >>> >>> As we split pull request for 5.10 this time, here's gvt-next pull >>> for 5.10. For gvt ww lock fix, Zhi would send another pull based >>> on gem-next. >>> >>> This includes current command access flag cleanup for >>> handlers which would be used for next refined cmd scan. And also >>> two more recent fixes on workaround cmd access and MIA reset state. >>> >>> Thanks >>> -- >>> The following changes since commit ced026e959bec5046afa310d6474e147b6294da2: >>> >>> drm/i915: Update DRIVER_DATE to 20200824 (2020-08-24 14:26:38 -0400) >>> >>> are available in the Git repository at: >>> >>> https://github.com/intel/gvt-linux tags/gvt-next-2020-09-10 >> >> This is a malformed pull request line which dim doesn't recognize. >> Could you please regenerate it? >> >> $ cat /tmp/gvt-next/cur/1599868544.259925_1.rdvivi-losangeles\:2\,S | dim >> apply-pull drm-intel-next-queued >> dim: no pull request found >> > > Hmm, strange, it pulls fine here when I tried this in local. I just copied in > mutt and > cat /tmp/gvt-next.0910 | ./dim apply-pull drm-intel-next-queued sorry... it was dim's fault ;) dim now accepts python3, but a function used on email parser doesn't work in the same way... pulled now, thanks > >>> >>> for you to fetch changes up to df398e33b8fd3ac28b3c7166de555e38d26e7391: >>> >>> drm/i915/gvt: Init vreg GUC_STATUS to GS_MIA_IN_RESET (2020-09-10 13:49:05 >>> +0800) >>> >>> >>> gvt-next-2020-09-10 >>> >>> - Cleanup command access flag (Yan) >>> - New workaround cmd access fix (Colin) >>> - MIA reset state fix (Colin) >>> >>> >>> Colin Xu (2): >>> drm/i915/gvt: Add F_CMD_ACCESS for some GEN9 SKU WA MMIO access >>> drm/i915/gvt: Init vreg GUC_STATUS to GS_MIA_IN_RESET >>> >>> Yan Zhao (4): >>> drm/i915/gvt: rename F_IN_CTX flag to F_SR_IN_CTX >>> drm/i915/gvt: remove flag F_CMD_ACCESSED >>> drm/i915/gvt: add/modify interfaces for flag F_CMD_ACCESS >>> drm/i915/gvt: remove F_CMD_ACCESS flag for some registers >>> >>> drivers/gpu/drm/i915/gvt/cmd_parser.c | 6 ++--- >>> drivers/gpu/drm/i915/gvt/gvt.h | 44 >>> +++-- >>> drivers/gpu/drm/i915/gvt/handlers.c | 32 +--- >>> drivers/gpu/drm/i915/gvt/mmio.c | 3 +++ >>> drivers/gpu/drm/i915/gvt/mmio_context.c | 2 +- >>> 5 files changed, 49 insertions(+), 38 deletions(-) >>> >>> -- >>> >>> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 >> >> >> ___ >> intel-gvt-dev mailing list >> intel-gvt-...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev > > -- > > $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Return head pages from find_*_entry (rev4)
== Series Details == Series: Return head pages from find_*_entry (rev4) URL : https://patchwork.freedesktop.org/series/81557/ State : failure == Summary == Applying: mm: Factor find_get_incore_page out of mincore_page Applying: mm: Use find_get_incore_page in memcontrol Applying: mm: Optimise madvise WILLNEED Using index info to reconstruct a base tree... M mm/madvise.c Falling back to patching base and 3-way merge... Auto-merging mm/madvise.c CONFLICT (content): Merge conflict in mm/madvise.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0003 mm: Optimise madvise WILLNEED When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 02/11] drm/i915: Remove hw.mode
On Mon, Sep 07, 2020 at 03:35:23PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 03, 2020 at 09:40:44PM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 03, 2020 at 11:04:33AM -0700, Navare, Manasi wrote:
> > > On Thu, Sep 03, 2020 at 08:49:44PM +0300, Ville Syrjälä wrote:
> > > > On Wed, Jul 15, 2020 at 03:42:13PM -0700, Manasi Navare wrote:
> > > > > From: Maarten Lankhorst
> > > > >
> > > > > The members in hw.mode can be used from adjusted_mode as well,
> > > > > use that when available.
> > > > >
> > > > > Some places that use hw.mode can be converted to use adjusted_mode
> > > > > as well.
> > > > >
> > > > > v2:
> > > > > * Manual rebase (Manasi)
> > > > > * remove the use of pipe_mode defined in patch 3 (Manasi)
> > > > >
> > > > > v3:
> > > > > * Rebase on drm-tip (Manasi)
> > > >
> > > > Previous review was apparently ignored. Or is there a better version
> > > > somewhere? If not, this still looks very wrong.
> > >
> > > This was the latest rev that Maarten had in his local tree which he said
> > > should address all the review comments.
> > > What in particular looks wrong or what review comments were unaddressed
> > > here?
> >
> > The dvo/sdvo changes.
>
> I recommend just dropping this patch entirely. It doesn't seem to have
> anything to do with the bigjoiner anyway.
So for the dvo/svdo changes, no need to use the adjusted_mode instead keep
using hw.mode?
How about other cleanups like: intel_crtc_copy_hw_to_uapi_state(crtc_state,
&mode); and
static void intel_crtc_copy_hw_to_uapi_state(struct intel_crtc_state
*crtc_state,
+struct drm_display_mode *user_mode)
You think we dont need mode as an argument there either?
Manasi
>
> >
> > >
> > > @Maarten any feedback on Ville's unaddressed comments?
> > >
> > > Manasi
> > >
> > > >
> > > > >
> > > > > Signed-off-by: Maarten Lankhorst
> > > > > Signed-off-by: Manasi Navare
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_display.c | 29
> > > > > ++-
> > > > > .../drm/i915/display/intel_display_types.h| 2 +-
> > > > > drivers/gpu/drm/i915/display/intel_dvo.c | 2 +-
> > > > > drivers/gpu/drm/i915/display/intel_sdvo.c | 16 --
> > > > > 4 files changed, 23 insertions(+), 26 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > index 729ec6e0d43a..8652a7c6bf11 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > @@ -8892,9 +8892,6 @@ static void intel_get_pipe_src_size(struct
> > > > > intel_crtc *crtc,
> > > > > tmp = intel_de_read(dev_priv, PIPESRC(crtc->pipe));
> > > > > pipe_config->pipe_src_h = (tmp & 0x) + 1;
> > > > > pipe_config->pipe_src_w = ((tmp >> 16) & 0x) + 1;
> > > > > -
> > > > > - pipe_config->hw.mode.vdisplay = pipe_config->pipe_src_h;
> > > > > - pipe_config->hw.mode.hdisplay = pipe_config->pipe_src_w;
> > > > > }
> > > > >
> > > > > void intel_mode_from_pipe_config(struct drm_display_mode *mode,
> > > > > @@ -13079,7 +13076,7 @@ static void intel_dump_pipe_config(const
> > > > > struct intel_crtc_state *pipe_config,
> > > > > intel_dump_dp_vsc_sdp(dev_priv,
> > > > > &pipe_config->infoframes.vsc);
> > > > >
> > > > > drm_dbg_kms(&dev_priv->drm, "requested mode:\n");
> > > > > - drm_mode_debug_printmodeline(&pipe_config->hw.mode);
> > > > > + drm_mode_debug_printmodeline(&pipe_config->uapi.mode);
> > > > > drm_dbg_kms(&dev_priv->drm, "adjusted mode:\n");
> > > > > drm_mode_debug_printmodeline(&pipe_config->hw.adjusted_mode);
> > > > > intel_dump_crtc_timings(dev_priv,
> > > > > &pipe_config->hw.adjusted_mode);
> > > > > @@ -13221,17 +13218,17 @@ intel_crtc_copy_uapi_to_hw_state(struct
> > > > > intel_crtc_state *crtc_state)
> > > > > {
> > > > > crtc_state->hw.enable = crtc_state->uapi.enable;
> > > > > crtc_state->hw.active = crtc_state->uapi.active;
> > > > > - crtc_state->hw.mode = crtc_state->uapi.mode;
> > > > > crtc_state->hw.adjusted_mode = crtc_state->uapi.adjusted_mode;
> > > > > intel_crtc_copy_uapi_to_hw_state_nomodeset(crtc_state);
> > > > > }
> > > > >
> > > > > -static void intel_crtc_copy_hw_to_uapi_state(struct intel_crtc_state
> > > > > *crtc_state)
> > > > > +static void intel_crtc_copy_hw_to_uapi_state(struct intel_crtc_state
> > > > > *crtc_state,
> > > > > + struct drm_display_mode
> > > > > *user_mode)
> > > > > {
> > > > > crtc_state->uapi.enable = crtc_state->hw.enable;
> > > > > crtc_state->uapi.active = crtc_state->hw.active;
> > > > > drm_WARN_ON(crtc_state->uapi.crtc->dev,
> > > > > - drm_atomic_set_mode_for_crtc(&crtc_state->uapi,
> > > > > &crtc_state->hw.mode) < 0);
> > > > > + drm_atom
Re: [Intel-gfx] [PATCH i-g-t v6 00/24] tests/core_hotunplug: Fixes and enhancements
Quoting Janusz Krzysztofik (2020-09-11 12:30:15) > Clean up the test code, add some new basic subtests, then unblock > unbind test variants. > > No incompletes / aborts nor subsequently run test issues have been > reported by Trybot. The hotrebind-lateclose subtest fails on a so far > unidentified driver sysfs issue but the device is fully recovered and > left in a usable state. Perceived Haswell/Broadwell issue with audio > power management has been worked around and its potential occurrence > is reported as an IGT warning. > > Series changelog: > v2: New patch "Un-blocklist *bind* subtests added. > v3: Patch "Follow failed subtests with healthcheck" renamed to "Recover > from subtest failures". > - a new patche "Clean up device open error handling" added, an old > patch "Fix missing newline" obsoleted by the new one dropped, > - other new patches added: > - "Let the driver time out essential sysfs operations", > - "More thorough i915 healthcheck and recovery", > - a patch "Add 'lateclose before restore' variants" from another > series included. > v4: Optional patch "Duplicate debug messages in dmesg" from another > series included. > v5: New patch added with Haswell audio related kernel warning worked > around and replaced with an IGT warning to preserve visibility of > the issue. > v6: New patch added for also checking health of render device nodes, > - new patch added with proper handling of health check before late > close, > - inclusion of unbind-rebind scenario to BAT scope proposed. > > @Michał: Since some patch updates are trivial, I've preserved your > v1/v2 Reviewd-by: except for patches with non-trivial changes, where I > marked your R-b as v1/v2 applicable. Please have a look and confirm if > you are still OK with them. Feel free to add: Reviewed-by: Michał Winiarski For the whole series (with the exception of intel-ci part). -Michał > > @Tvrtko: As I already asked before, please support my attempt to remove > the unbind test variants from the blocklist. > > @Petri, @Martin: Assuming CI results will be as good as those obtained > on Trybot, please give me your green light for merging this series if > you have no objections. > > Thanks, > Janusz > > Janusz Krzysztofik (24): > tests/core_hotunplug: Use igt_assert_fd() > tests/core_hotunplug: Constify dev_bus_addr string > tests/core_hotunplug: Clean up device open error handling > tests/core_hotunplug: Consolidate duplicated debug messages > tests/core_hotunplug: Assert successful device filter application > tests/core_hotunplug: Maintain a single data structure instance > tests/core_hotunplug: Pass errors via a data structure field > tests/core_hotunplug: Handle device close errors > tests/core_hotunplug: Prepare invariant data once per test run > tests/core_hotunplug: Skip selectively on sysfs close errors > tests/core_hotunplug: Recover from subtest failures > tests/core_hotunplug: Fail subtests on device close errors > tests/core_hotunplug: Let the driver time out essential sysfs > operations > tests/core_hotunplug: Process return values of sysfs operations > tests/core_hotunplug: Assert expected device presence/absence > tests/core_hotunplug: Explicitly ignore unused return values > tests/core_hotunplug: Also check health of render device node > tests/core_hotunplug: More thorough i915 healthcheck and recovery > tests/core_hotunplug: Add 'lateclose before restore' variants > tests/core_hotunplug: Check health both before and after late close > tests/core_hotunplug: HSW/BDW audio issue workaround > tests/core_hotunplug: Duplicate debug messages in dmesg > tests/core_hotunplug: Un-blocklist *bind* subtests > tests/core_hotunplug: Add unbind-rebind subtest to BAT scope > > tests/core_hotunplug.c| 560 -- > tests/intel-ci/blacklist.txt | 2 +- > tests/intel-ci/fast-feedback.testlist | 1 + > 3 files changed, 431 insertions(+), 132 deletions(-) > > -- > 2.21.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] drm/i915/pll: Centralize PLL_ENABLE register lookup
We currenty check for platform at multiple parts in the driver
to grab the correct PLL. Let us begin to centralize it through a
helper function.
v2: s/intel_get_pll_enable_reg()/intel_combo_pll_enable_reg() (Ville)
v3: Clean up combo_pll_disable() (Rodrigo)
v4: s/dev_priv/i915 (Jani)
Move static and return type to the same line( Ville, Jani)
Suggested-by: Matt Roper
Cc: Ville Syrjälä
Cc: Matt Roper
Signed-off-by: Anusha Srivatsa
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index c9013f8f766f..e08684e34078 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -147,6 +147,18 @@ void assert_shared_dpll(struct drm_i915_private *dev_priv,
pll->info->name, onoff(state), onoff(cur_state));
}
+static i915_reg_t
+intel_combo_pll_enable_reg(struct drm_i915_private *i915,
+ struct intel_shared_dpll *pll)
+{
+
+ if (IS_ELKHARTLAKE(i915) && (pll->info->id == DPLL_ID_EHL_DPLL4))
+ return MG_PLL_ENABLE(0);
+
+ return CNL_DPLL_ENABLE(pll->info->id);
+
+
+}
/**
* intel_prepare_shared_dpll - call a dpll's prepare hook
* @crtc_state: CRTC, and its state, which has a shared dpll
@@ -3842,12 +3854,7 @@ static bool combo_pll_get_hw_state(struct
drm_i915_private *dev_priv,
struct intel_shared_dpll *pll,
struct intel_dpll_hw_state *hw_state)
{
- i915_reg_t enable_reg = CNL_DPLL_ENABLE(pll->info->id);
-
- if (IS_ELKHARTLAKE(dev_priv) &&
- pll->info->id == DPLL_ID_EHL_DPLL4) {
- enable_reg = MG_PLL_ENABLE(0);
- }
+ i915_reg_t enable_reg = intel_combo_pll_enable_reg(dev_priv, pll);
return icl_pll_get_hw_state(dev_priv, pll, hw_state, enable_reg);
}
@@ -4045,11 +4052,10 @@ static void icl_pll_enable(struct drm_i915_private
*dev_priv,
static void combo_pll_enable(struct drm_i915_private *dev_priv,
struct intel_shared_dpll *pll)
{
- i915_reg_t enable_reg = CNL_DPLL_ENABLE(pll->info->id);
+ i915_reg_t enable_reg = intel_combo_pll_enable_reg(dev_priv, pll);
if (IS_ELKHARTLAKE(dev_priv) &&
pll->info->id == DPLL_ID_EHL_DPLL4) {
- enable_reg = MG_PLL_ENABLE(0);
/*
* We need to disable DC states when this DPLL is enabled.
@@ -4157,19 +4163,14 @@ static void icl_pll_disable(struct drm_i915_private
*dev_priv,
static void combo_pll_disable(struct drm_i915_private *dev_priv,
struct intel_shared_dpll *pll)
{
- i915_reg_t enable_reg = CNL_DPLL_ENABLE(pll->info->id);
+ i915_reg_t enable_reg = intel_combo_pll_enable_reg(dev_priv, pll);
- if (IS_ELKHARTLAKE(dev_priv) &&
- pll->info->id == DPLL_ID_EHL_DPLL4) {
- enable_reg = MG_PLL_ENABLE(0);
- icl_pll_disable(dev_priv, pll, enable_reg);
+ icl_pll_disable(dev_priv, pll, enable_reg);
+ if (IS_ELKHARTLAKE(dev_priv) &&
+ pll->info->id == DPLL_ID_EHL_DPLL4)
intel_display_power_put(dev_priv, POWER_DOMAIN_DPLL_DC_OFF,
pll->wakeref);
- return;
- }
-
- icl_pll_disable(dev_priv, pll, enable_reg);
}
static void tbt_pll_disable(struct drm_i915_private *dev_priv,
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Per client engine busyness
== Series Details == Series: Per client engine busyness URL : https://patchwork.freedesktop.org/series/81652/ State : success == Summary == CI Bug Log - changes from CI_DRM_9007 -> Patchwork_18491 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/index.html Known issues Here are the changes found in Patchwork_18491 that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@reload: - fi-bsw-n3050: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-bsw-n3050/igt@i915_module_l...@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/fi-bsw-n3050/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_9007/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1: - fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-a: - fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-tgl-y/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-a.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/fi-tgl-y/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-a.html * igt@prime_self_import@basic-with_two_bos: - fi-tgl-y: [PASS][9] -> [DMESG-WARN][10] ([i915#402]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html Possible fixes * igt@gem_flink_basic@bad-flink: - fi-tgl-y: [DMESG-WARN][11] ([i915#402]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html * igt@i915_selftest@live@execlists: - fi-icl-y: [INCOMPLETE][13] ([i915#2276]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-icl-y/igt@i915_selftest@l...@execlists.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/fi-icl-y/igt@i915_selftest@l...@execlists.html * igt@kms_busy@basic@flip: - fi-tgl-y: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-tgl-y/igt@kms_busy@ba...@flip.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/fi-tgl-y/igt@kms_busy@ba...@flip.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-7500u: [DMESG-WARN][17] ([i915#2203]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) -> [DMESG-WARN][20] ([i915#1982] / [i915#62] / [i915#92] / [i915#95]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-tgl-y: [DMESG-WARN][21] ([i915#1982] / [i915#2411]) -> [DMESG-WARN][22] ([i915#2411]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html * igt@kms_cursor_legacy@basic-flip-before-cursor-legacy: - fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) -> [DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9007/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18491/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.htm
Re: [Intel-gfx] [PATCH] drm/i915: Fix the race between the GEM close and debugfs
On 9/14/2020 10:17 PM, Tvrtko Ursulin wrote:
On 14/09/2020 12:00, Nikunj A. Dadhania wrote:
As we close GEM object and set file_priv to -EBADF which is protected
by ctx->mutex, populating the GEM debugfs info is not protected
and results in the crash shown below.
Make sure to protect the access to file_priv using ctx->mutex to avoid
race.
BUG: unable to handle page fault for address:
RIP: 0010:i915_gem_object_info+0x26b/0x3eb
Code: 89 44 24 48 48 89 44 24 40 48 89 44 24 38 48 89 44 24 30 48 89
44 24 28 48 89 44 24 20 49 8b 46 f0 48 89 44 24 20 49 8b 46 a0 <48> 8b
58 08 b9 0a 00 00 00 48 b8 aa aa aa aa aa aa aa aa 48 8d bc
RSP: 0018:ac81c14cfc30 EFLAGS: 00010246
RAX: fff7 RBX: 95094429c218 RCX: 95096756c740
RDX: RSI: 919b93ee RDI: 95094429c218
RBP: ac81c14cfd58 R08: 9509746fab80 R09:
R10: 0001 R11: R12: 9509753f8e80
R13: ac81c14cfc98 R14: 95094429c268 R15: ac81c14cfc88
FS: 7a1bdcd52900() GS:950977e0()
knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: CR3: 00026b4e CR4: 00340ef0
Call Trace:
seq_read+0x162/0x3ca
full_proxy_read+0x5b/0x8d
__vfs_read+0x45/0x1b9
vfs_read+0xc9/0x15e
ksys_read+0x7e/0xde
do_syscall_64+0x54/0x7e
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7a1bdd34cf03
Signed-off-by: Nikunj A. Dadhania
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 784219962193..ea469168cd44 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -326,6 +326,7 @@ static void print_context_stats(struct seq_file *m,
}
i915_gem_context_unlock_engines(ctx);
+ mutex_lock(&ctx->mutex);
if (!IS_ERR_OR_NULL(ctx->file_priv)) {
struct file_stats stats = {
.vm = rcu_access_pointer(ctx->vm),
@@ -346,6 +347,7 @@ static void print_context_stats(struct seq_file *m,
print_file_stats(m, name, stats);
}
+ mutex_unlock(&ctx->mutex);
spin_lock(&i915->gem.contexts.lock);
list_safe_reset_next(ctx, cn, link);
Fix is correct, but it looked familiar and indeed I found a fix for the
same issues back from July. Copied you on that one which now has an r-b.
Yes, saw your other email. Both are same, whichever gets applied is fine.
This one can have it as well but please also copy stable.
Do I need to send the patch again with CC to stable?
> Reviewed-by: Tvrtko Ursulin
Thanks
Nikunj
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Per client engine busyness
== Series Details == Series: Per client engine busyness URL : https://patchwork.freedesktop.org/series/81652/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_reset.c:1311:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1440:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1494:15: warning: memset with byte count of 16777216 +./include/linux/seqlock.h:752:24: warning: trying to copy expression type 31 +./include/linux/seqlock.h:752:24: warning: trying to copy expression type 31 +./include/linux/seqlock.h:778:16: warning: trying to copy expression type 31 +./include/linux/seqlock.h:778:16: warning: trying to copy expression type 31 +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' - different lock contexts for basic block ___ Intel-gfx mailing list Intel-gfx@li
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Per client engine busyness
== Series Details ==
Series: Per client engine busyness
URL : https://patchwork.freedesktop.org/series/81652/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ac3c07ab42f4 drm/i915: Expose list of clients in sysfs
-:84: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#84:
new file mode 100644
-:274: WARNING:SPDX_LICENSE_TAG: Improper SPDX comment style for
'drivers/gpu/drm/i915/i915_drm_client.h', please use '/*' instead
#274: FILE: drivers/gpu/drm/i915/i915_drm_client.h:1:
+// SPDX-License-Identifier: MIT
-:274: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#274: FILE: drivers/gpu/drm/i915/i915_drm_client.h:1:
+// SPDX-License-Identifier: MIT
total: 0 errors, 3 warnings, 0 checks, 368 lines checked
5e257bb526a4 drm/i915: Update client name on context create
-:197: WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message
#197: FILE: drivers/gpu/drm/i915/i915_drm_client.c:237:
+ if (!name) {
+ drm_notice(&i915->drm,
total: 0 errors, 1 warnings, 0 checks, 201 lines checked
02a3cfd8e1dd drm/i915: Make GEM contexts track DRM clients
25668d5d310b drm/i915: Track runtime spent in unreachable intel_contexts
556043f2cc84 drm/i915: Track runtime spent in closed GEM contexts
71e7b25bc497 drm/i915: Track all user contexts per client
9cd6cdc6cf88 drm/i915: Expose per-engine client busyness
-:25: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#25:
Render/3D/0 63.73% |███ | 3% 0%
total: 0 errors, 1 warnings, 0 checks, 164 lines checked
b58bb1362c49 drm/i915: Track context current active time
-:71: CHECK:LINE_SPACING: Please don't use multiple blank lines
#71: FILE: drivers/gpu/drm/i915/gt/intel_context.c:504:
+
+
-:134: WARNING:LINE_SPACING: Missing a blank line after declarations
#134: FILE: drivers/gpu/drm/i915/gt/intel_context_types.h:96:
+ u32 last;
+ I915_SELFTEST_DECLARE(u32 num_underflow);
total: 0 errors, 1 warnings, 1 checks, 248 lines checked
2905d1efe3cd drm/i915: Prefer software tracked context busyness
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for dma-buf: Flag vmap'ed memory as system or I/O memory
== Series Details == Series: dma-buf: Flag vmap'ed memory as system or I/O memory URL : https://patchwork.freedesktop.org/series/81647/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/gem/i915_gem_dmabuf.o In file included from drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c:291:0: drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c:89:10: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] .vmap = mock_dmabuf_vmap, ^~~~ drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c:89:10: note: (near initialization for ‘mock_dmabuf_ops.vmap’) drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c:90:12: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] .vunmap = mock_dmabuf_vunmap, ^~ drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c:90:12: note: (near initialization for ‘mock_dmabuf_ops.vunmap’) cc1: all warnings being treated as errors scripts/Makefile.build:283: recipe for target 'drivers/gpu/drm/i915/gem/i915_gem_dmabuf.o' failed make[4]: *** [drivers/gpu/drm/i915/gem/i915_gem_dmabuf.o] Error 1 scripts/Makefile.build:500: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:500: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:500: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1784: 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] [10/12] drm/i915: Introduce HPD_PORT_TC
On Mon, Sep 14, 2020 at 04:58:33PM +, Souza, Jose wrote:
> On Mon, 2020-09-14 at 17:48 +0300, Ville Syrjälä wrote:
> > On Sat, Sep 12, 2020 at 01:30:23AM +, Souza, Jose wrote:
> > > On Wed, 2020-07-01 at 00:55 +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä <
> > > > ville.syrj...@linux.intel.com
> > > >
> > > >
> > > > Make a clean split between hpd pins for DDI vs. TC. This matches
> > > > how the actual hardware is split.
> > > >
> > > > And with this we move the DDI/PHY->HPD pin mapping into the encoder
> > > > init instead of having to remap yet again in the interrupt code.
> > > >
> > > > Signed-off-by: Ville Syrjälä <
> > > > ville.syrj...@linux.intel.com
> > > >
> > > >
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_ddi.c | 65 +-
> > > > drivers/gpu/drm/i915/display/intel_hotplug.c | 25 +---
> > > > drivers/gpu/drm/i915/i915_drv.h | 17 +--
> > > > drivers/gpu/drm/i915/i915_irq.c | 121 +--
> > > > 4 files changed, 102 insertions(+), 126 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > index d024491738b3..a2c9815c5abc 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > @@ -4847,6 +4847,57 @@ intel_ddi_max_lanes(struct intel_digital_port
> > > > *intel_dport)
> > > > return max_lanes;
> > > > }
> > > >
> > > > +static enum hpd_pin tgl_hpd_pin(struct drm_i915_private *dev_priv,
> > > > + enum port port)
> > > > +{
> > > > + if (port >= PORT_D)
> > > > + return HPD_PORT_TC1 + port - PORT_D;
> > > > + else
> > > > + return HPD_PORT_A + port - PORT_A;
> > > > +}
> > > > +
> > > > +static enum hpd_pin rkl_hpd_pin(struct drm_i915_private *dev_priv,
> > > > + enum port port)
> > > > +{
> > > > + if (HAS_PCH_TGP(dev_priv))
> > > > + return tgl_hpd_pin(dev_priv, port);
> > > > +
> > > > + if (port >= PORT_D)
> > > > + return HPD_PORT_C + port - PORT_D;
> > >
> > > The above looks wrong, for it would match with only the return bellow.
> >
> > On rkl+tgp we want:
> > PORT_A (DDI A) -> HPD_PORT_A
> > PORT_B (DDI B) -> HPD_PORT_B
> > PORT_D (DDI TC1) -> HPD_PORT_TC1
> > PORT_E (DDI TC2) -> HPD_PORT_TC2
> >
> > On rkl+cmp we want:
> > PORT_A (DDI A) -> HPD_PORT_A
> > PORT_B (DDI B) -> HPD_PORT_B
> > PORT_D (DDI TC1) -> HPD_PORT_C
> > PORT_E (DDI TC2) -> HPD_PORT_D
>
> oohh okay, missed this.
>
> >
> > > > + else
> > > > + return HPD_PORT_A + port - PORT_A;
> > > > +}
> > > > +
> > > > +static enum hpd_pin icl_hpd_pin(struct drm_i915_private *dev_priv,
> > > > + enum port port)
> > > > +{
> > > > + if (port >= PORT_C)
> > > > + return HPD_PORT_TC1 + port - PORT_C;
> > > > + else
> > > > + return HPD_PORT_A + port - PORT_A;
> > > > +}
> > > > +
> > > > +static enum hpd_pin ehl_hpd_pin(struct drm_i915_private *dev_priv,
> > > > + enum port port)
> > > > +{
> > > > + if (port == PORT_D)
> > > > + return HPD_PORT_A;
> > > > +
> > > > + if (HAS_PCH_MCC(dev_priv))
> > > > + return icl_hpd_pin(dev_priv, port);
> > >
> > > Maybe call tgl_hpd_pin() for HAS_PCH_MCC()? The code bellow will match
> > > but just for consistency.
> >
> > On jsl+mcc we want:
> > PORT_A/D (DDI A/D) -> HPD_PORT_A
> > PORT_B (DDI B) -> HPD_PORT_B
> > PORT_C (DDI C) -> HPD_PORT_TC1
> >
> > on jsl+icp we want:
> > PORT_A/D (DDI A/D) -> HPD_PORT_A
> > PORT_B (DDI B) -> HPD_PORT_B
> > PORT_C (DDI C) -> HPD_PORT_C
> >
> >
>
> The above would be the output of tgl_hpd_pin() but okay as it can be
> associate with SPT, LPT, ICP and TGP better keep the current code.
I suspect we probably want to change this to the already discussed
more declarative approach at some point, so it'll be easier to see
what maps to what. But in the meantime this at least gets this
hpd pin mapping stuff out from the guts of the irq code.
>
> Reviewed-by: José Roberto de Souza
Ta.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [10/12] drm/i915: Introduce HPD_PORT_TC
On Mon, 2020-09-14 at 17:48 +0300, Ville Syrjälä wrote:
> On Sat, Sep 12, 2020 at 01:30:23AM +, Souza, Jose wrote:
> > On Wed, 2020-07-01 at 00:55 +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä <
> > > ville.syrj...@linux.intel.com
> > >
> > >
> > > Make a clean split between hpd pins for DDI vs. TC. This matches
> > > how the actual hardware is split.
> > >
> > > And with this we move the DDI/PHY->HPD pin mapping into the encoder
> > > init instead of having to remap yet again in the interrupt code.
> > >
> > > Signed-off-by: Ville Syrjälä <
> > > ville.syrj...@linux.intel.com
> > >
> > >
> > > ---
> > > drivers/gpu/drm/i915/display/intel_ddi.c | 65 +-
> > > drivers/gpu/drm/i915/display/intel_hotplug.c | 25 +---
> > > drivers/gpu/drm/i915/i915_drv.h | 17 +--
> > > drivers/gpu/drm/i915/i915_irq.c | 121 +--
> > > 4 files changed, 102 insertions(+), 126 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > index d024491738b3..a2c9815c5abc 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > @@ -4847,6 +4847,57 @@ intel_ddi_max_lanes(struct intel_digital_port
> > > *intel_dport)
> > > return max_lanes;
> > > }
> > >
> > > +static enum hpd_pin tgl_hpd_pin(struct drm_i915_private *dev_priv,
> > > + enum port port)
> > > +{
> > > + if (port >= PORT_D)
> > > + return HPD_PORT_TC1 + port - PORT_D;
> > > + else
> > > + return HPD_PORT_A + port - PORT_A;
> > > +}
> > > +
> > > +static enum hpd_pin rkl_hpd_pin(struct drm_i915_private *dev_priv,
> > > + enum port port)
> > > +{
> > > + if (HAS_PCH_TGP(dev_priv))
> > > + return tgl_hpd_pin(dev_priv, port);
> > > +
> > > + if (port >= PORT_D)
> > > + return HPD_PORT_C + port - PORT_D;
> >
> > The above looks wrong, for it would match with only the return bellow.
>
> On rkl+tgp we want:
> PORT_A (DDI A) -> HPD_PORT_A
> PORT_B (DDI B) -> HPD_PORT_B
> PORT_D (DDI TC1) -> HPD_PORT_TC1
> PORT_E (DDI TC2) -> HPD_PORT_TC2
>
> On rkl+cmp we want:
> PORT_A (DDI A) -> HPD_PORT_A
> PORT_B (DDI B) -> HPD_PORT_B
> PORT_D (DDI TC1) -> HPD_PORT_C
> PORT_E (DDI TC2) -> HPD_PORT_D
oohh okay, missed this.
>
> > > + else
> > > + return HPD_PORT_A + port - PORT_A;
> > > +}
> > > +
> > > +static enum hpd_pin icl_hpd_pin(struct drm_i915_private *dev_priv,
> > > + enum port port)
> > > +{
> > > + if (port >= PORT_C)
> > > + return HPD_PORT_TC1 + port - PORT_C;
> > > + else
> > > + return HPD_PORT_A + port - PORT_A;
> > > +}
> > > +
> > > +static enum hpd_pin ehl_hpd_pin(struct drm_i915_private *dev_priv,
> > > + enum port port)
> > > +{
> > > + if (port == PORT_D)
> > > + return HPD_PORT_A;
> > > +
> > > + if (HAS_PCH_MCC(dev_priv))
> > > + return icl_hpd_pin(dev_priv, port);
> >
> > Maybe call tgl_hpd_pin() for HAS_PCH_MCC()? The code bellow will match but
> > just for consistency.
>
> On jsl+mcc we want:
> PORT_A/D (DDI A/D) -> HPD_PORT_A
> PORT_B (DDI B) -> HPD_PORT_B
> PORT_C (DDI C) -> HPD_PORT_TC1
>
> on jsl+icp we want:
> PORT_A/D (DDI A/D) -> HPD_PORT_A
> PORT_B (DDI B) -> HPD_PORT_B
> PORT_C (DDI C) -> HPD_PORT_C
>
>
The above would be the output of tgl_hpd_pin() but okay as it can be associate
with SPT, LPT, ICP and TGP better keep the current code.
Reviewed-by: José Roberto de Souza
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/8] mm: Optimise madvise WILLNEED
On Mon, Sep 14, 2020 at 12:17:07PM -0400, Qian Cai wrote: > Reverting the "Return head pages from find_*_entry" patchset [1] up to this > patch fixed the issue that LTP madvise06 test [2] would trigger endless soft- > lockups below. It does not help after applied patches fixed other separate > issues in the patchset [3][4]. Thanks for the report. Could you try this? diff --git a/mm/madvise.c b/mm/madvise.c index 96189acd6969..2d9ceccb338d 100644 --- a/mm/madvise.c +++ b/mm/madvise.c @@ -234,6 +234,7 @@ static void force_shm_swapin_readahead(struct vm_area_struct *vma, if (!xa_is_value(page)) continue; + xas_pause(&xas); rcu_read_unlock(); swap = radix_to_swp_entry(page); @@ -243,7 +244,6 @@ static void force_shm_swapin_readahead(struct vm_area_struct *vma, put_page(page); rcu_read_lock(); - xas_reset(&xas); } rcu_read_unlock(); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix the race between the GEM close and debugfs
On 14/09/2020 12:00, Nikunj A. Dadhania wrote:
As we close GEM object and set file_priv to -EBADF which is protected
by ctx->mutex, populating the GEM debugfs info is not protected
and results in the crash shown below.
Make sure to protect the access to file_priv using ctx->mutex to avoid
race.
BUG: unable to handle page fault for address:
RIP: 0010:i915_gem_object_info+0x26b/0x3eb
Code: 89 44 24 48 48 89 44 24 40 48 89 44 24 38 48 89 44 24 30 48 89 44 24 28 48 89
44 24 20 49 8b 46 f0 48 89 44 24 20 49 8b 46 a0 <48> 8b 58 08 b9 0a 00 00 00 48
b8 aa aa aa aa aa aa aa aa 48 8d bc
RSP: 0018:ac81c14cfc30 EFLAGS: 00010246
RAX: fff7 RBX: 95094429c218 RCX: 95096756c740
RDX: RSI: 919b93ee RDI: 95094429c218
RBP: ac81c14cfd58 R08: 9509746fab80 R09:
R10: 0001 R11: R12: 9509753f8e80
R13: ac81c14cfc98 R14: 95094429c268 R15: ac81c14cfc88
FS: 7a1bdcd52900() GS:950977e0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: CR3: 00026b4e CR4: 00340ef0
Call Trace:
seq_read+0x162/0x3ca
full_proxy_read+0x5b/0x8d
__vfs_read+0x45/0x1b9
vfs_read+0xc9/0x15e
ksys_read+0x7e/0xde
do_syscall_64+0x54/0x7e
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7a1bdd34cf03
Signed-off-by: Nikunj A. Dadhania
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 784219962193..ea469168cd44 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -326,6 +326,7 @@ static void print_context_stats(struct seq_file *m,
}
i915_gem_context_unlock_engines(ctx);
+ mutex_lock(&ctx->mutex);
if (!IS_ERR_OR_NULL(ctx->file_priv)) {
struct file_stats stats = {
.vm = rcu_access_pointer(ctx->vm),
@@ -346,6 +347,7 @@ static void print_context_stats(struct seq_file *m,
print_file_stats(m, name, stats);
}
+ mutex_unlock(&ctx->mutex);
spin_lock(&i915->gem.contexts.lock);
list_safe_reset_next(ctx, cn, link);
Fix is correct, but it looked familiar and indeed I found a fix for the
same issues back from July. Copied you on that one which now has an r-b.
This one can have it as well but please also copy stable.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/8] mm: Optimise madvise WILLNEED
On Mon, 2020-09-14 at 12:17 -0400, Qian Cai wrote: > On Thu, 2020-09-10 at 19:33 +0100, Matthew Wilcox (Oracle) wrote: > > Instead of calling find_get_entry() for every page index, use an XArray > > iterator to skip over NULL entries, and avoid calling get_page(), > > because we only want the swap entries. > > > > Signed-off-by: Matthew Wilcox (Oracle) > > Acked-by: Johannes Weiner > > Reverting the "Return head pages from find_*_entry" patchset [1] up to this > patch fixed the issue that LTP madvise06 test [2] would trigger endless soft- > lockups below. It does not help after applied patches fixed other separate > issues in the patchset [3][4]. Forgot to send this piece of RCU stall traces as well which might help debugging. 00: [ 2852.137748] madvise06 (62712): drop_caches: 3 01: [ 2928.208367] rcu: INFO: rcu_sched self-detected stall on CPU 01: [ 2928.210083] rcu: 1-: (6499 ticks this GP) idle=036/1/0x40 01: 02 softirq=1741392/1741392 fqs=3161 01: [ 2928.210610] (t=6500 jiffies g=610849 q=12529) 01: [ 2928.210620] Task dump for CPU 1: 01: [ 2928.210630] task:madvise06 state:R running task stack:53320 pi 01: d:62712 ppid: 62711 flags:0x0004 01: [ 2928.210676] Call Trace: 01: [ 2928.210693] [] show_stack+0x158/0x1f0 01: [ 2928.210703] [ ] sched_show_task+0x3d2/0x4c8 01: [ 2928.210710] [ ] rcu_dump_cpu_stacks+0x26a/0x2a8 01: [ 2928.210718] [ ] rcu_sched_clock_irq+0x1c92/0x2188 01: [ 2928.210726] [ ] update_process_times+0x4e/0x148 01: [ 2928.210734] [ ] tick_sched_timer+0x86/0x188 01: [ 2928.210741] [ ] __hrtimer_run_queues+0x84c/0x10b8 01: [ 2928.210748] [ ] hrtimer_interrupt+0x38a/0x860 01: [ 2928.210758] [ ] do_IRQ+0x152/0x1c8 01: [ 2928.210767] [ ] ext_int_handler+0x18e/0x194 01: [ 2928.210774] [ ] arch_local_irq_restore+0x86/0xa0 01: [ 2928.210782] [ ] lock_is_held_type+0xe4/0x130 01: [ 2928.210791] [ ] rcu_read_lock_held+0xba/0xd8 01: [ 2928.210799] [ ] xas_descend+0x244/0x2c8 01: [ 2928.210806] [ ] xas_load+0xd4/0x148 01: [ 2928.210812] [ ] xas_find+0x5d0/0x818 01: [ 2928.210822] [ ] do_madvise+0xd5c/0x1600 01: [ 2928.210828] [ ] __s390x_sys_madvise+0x72/0x98 01: [ 2928.210835] [ ] system_call+0xdc/0x278 01: [ 2928.210841] 3 locks held by madvise06/62712: 01: [ 2928.216406] #0: 0001437fca18 (&mm->mmap_lock){}-{3:3}, at: do_m 01: dvise+0x18c/0x1600 01: [ 2928.216430] #1: afbdd3e0 (rcu_read_lock){}-{1:2}, at: do_mad 01: vise+0xe72/0x1600 01: [ 2928.216449] #2: afbe0818 (rcu_node_1){-.-.}-{2:2}, at: rcu_dump_ 01: cpu_stacks+0xb2/0x2a8 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/gem: Serialise debugfs i915_gem_objects with ctx->mutex
On 23/07/2020 18:21, Chris Wilson wrote:
Since the debugfs may peek into the GEM contexts as the corresponding
client/fd is being closed, we may try and follow a dangling pointer.
However, the context closure itself is serialised with the ctx->mutex,
so if we hold that mutex as we inspect the state coupled in the context,
we know the pointers within the context are stable and will remain valid
as we inspect their tables.
Signed-off-by: Chris Wilson
Cc: CQ Tang
Cc: Daniel Vetter
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 784219962193..ea469168cd44 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -326,6 +326,7 @@ static void print_context_stats(struct seq_file *m,
}
i915_gem_context_unlock_engines(ctx);
+ mutex_lock(&ctx->mutex);
if (!IS_ERR_OR_NULL(ctx->file_priv)) {
struct file_stats stats = {
.vm = rcu_access_pointer(ctx->vm),
@@ -346,6 +347,7 @@ static void print_context_stats(struct seq_file *m,
print_file_stats(m, name, stats);
}
+ mutex_unlock(&ctx->mutex);
spin_lock(&i915->gem.contexts.lock);
list_safe_reset_next(ctx, cn, link);
Hm this apparently never got it's r-b and so got re-discovered in the
field. +Nikunj
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/8] mm: Optimise madvise WILLNEED
On Thu, 2020-09-10 at 19:33 +0100, Matthew Wilcox (Oracle) wrote: > Instead of calling find_get_entry() for every page index, use an XArray > iterator to skip over NULL entries, and avoid calling get_page(), > because we only want the swap entries. > > Signed-off-by: Matthew Wilcox (Oracle) > Acked-by: Johannes Weiner Reverting the "Return head pages from find_*_entry" patchset [1] up to this patch fixed the issue that LTP madvise06 test [2] would trigger endless soft- lockups below. It does not help after applied patches fixed other separate issues in the patchset [3][4]. [1] https://lore.kernel.org/intel-gfx/20200910183318.20139-1-wi...@infradead.org/ [2] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/madvise/madvise06.c [3] https://lore.kernel.org/intel-gfx/20200914112738.gm6...@casper.infradead.org/ [4] https://lore.kernel.org/lkml/20200914115559.gn6...@casper.infradead.org/ [ 2653.179563][C4] CPU: 4 PID: 23320 Comm: madvise06 Not tainted 5.9.0-rc5-next-20200914+ #2 [ 2653.220176][C4] Hardware name: HP ProLiant BL660c Gen9, BIOS I38 10/17/2018 [ 2653.254908][C4] RIP: 0010:lock_acquire+0x211/0x8e0 [ 2653.278534][C4] Code: 83 c0 03 38 d0 7c 08 84 d2 0f 85 3a 05 00 00 8b 85 04 08 00 00 83 e8 01 89 85 04 08 00 00 66 85 c0 0f 85 9a 04 00 00 41 52 9d <48> b8 00 00 00 00 00 fc ff df 48 01 c3 c7 03 00 00 00 00 c7 43 08 [ 2653.369929][C4] RSP: 0018:c9000e1bf9f0 EFLAGS: 0246 [ 2653.399398][C4] RAX: RBX: 192001c37f41 RCX: 192001c37f27 [ 2653.437720][C4] RDX: RSI: 29956a3e RDI: 889042f40844 [ 2653.475829][C4] RBP: 889042f40040 R08: fbfff5083905 R09: fbfff5083905 [ 2653.511611][C4] R10: 0246 R11: fbfff5083904 R12: a74ce320 [ 2653.547396][C4] R13: R14: R15: [ 2653.582938][C4] FS: 7f1fc85e4600() GS:1e10() knlGS: [ 2653.622910][C4] CS: 0010 DS: ES: CR0: 80050033 [ 2653.652310][C4] CR2: 00620050 CR3: 00054d438002 CR4: 001706e0 [ 2653.688228][C4] Call Trace: [ 2653.702537][C4] ? rcu_read_unlock+0x40/0x40 [ 2653.723647][C4] ? find_held_lock+0x33/0x1c0 [ 2653.744708][C4] ? __read_swap_cache_async+0x18f/0x870 [ 2653.770547][C4] get_swap_device+0xf5/0x280 rcu_read_lock at include/linux/rcupdate.h:642 (inlined by) get_swap_device at mm/swapfile.c:1303 [ 2653.791303][C4] ? get_swap_device+0xce/0x280 [ 2653.812693][C4] ? swap_page_trans_huge_swapped+0x2a0/0x2a0 [ 2653.839963][C4] __read_swap_cache_async+0x10c/0x870 __read_swap_cache_async at mm/swap_state.c:469 [ 2653.864243][C4] ? rcu_read_lock_sched_held+0x9c/0xd0 [ 2653.890657][C4] ? find_get_incore_page+0x220/0x220 [ 2653.916978][C4] ? rcu_read_lock_held+0x9c/0xb0 [ 2653.940235][C4] ? find_held_lock+0x33/0x1c0 [ 2653.961325][C4] ? do_madvise.part.30+0xd11/0x1b70 [ 2653.984922][C4] ? lock_downgrade+0x730/0x730 [ 2654.006502][C4] read_swap_cache_async+0x60/0xb0 read_swap_cache_async at mm/swap_state.c:564 [ 2654.029694][C4] ? __read_swap_cache_async+0x870/0x870 [ 2654.055486][C4] ? xas_find+0x410/0x6c0 [ 2654.074663][C4] do_madvise.part.30+0xd47/0x1b70 force_shm_swapin_readahead at mm/madvise.c:243 (inlined by) madvise_willneed at mm/madvise.c:277 (inlined by) madvise_vma at mm/madvise.c:939 (inlined by) do_madvise at mm/madvise.c:1142 [ 2654.097959][C4] ? find_held_lock+0x33/0x1c0 [ 2654.119031][C4] ? swapin_walk_pmd_entry+0x430/0x430 [ 2654.143518][C4] ? down_read_nested+0x420/0x420 [ 2654.165748][C4] ? rcu_read_lock_sched_held+0x9c/0xd0 [ 2654.190523][C4] ? __x64_sys_madvise+0xa1/0x110 [ 2654.212973][C4] __x64_sys_madvise+0xa1/0x110 [ 2654.233976][C4] ? syscall_enter_from_user_mode+0x1c/0x50 [ 2654.260983][C4] do_syscall_64+0x33/0x40 [ 2654.281132][C4] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 2654.307623][C4] RIP: 0033:0x7f1fc80fca6b [ 2654.327125][C4] Code: 64 89 02 b8 ff ff ff ff c3 48 8b 15 17 54 2c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bc 0f 1f 00 f3 0f 1e fa b8 1c 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ed 53 2c 00 f7 d8 64 89 01 48 [ 2654.420246][C4] RSP: 002b:7fff53609998 EFLAGS: 0202 ORIG_RAX: 001c [ 2654.458926][C4] RAX: ffda RBX: 7f1fc85e4580 RCX: 7f1fc80fca6b [ 2654.494295][C4] RDX: 0003 RSI: 1900 RDI: 7f1faf006000 [ 2654.530104][C4] RBP: 7f1faf006000 R08: R09: 7fff53609284 [ 2654.566057][C4] R10: 0003 R11: 0202 R12: [ 2654.601697][C4] R13: 0001 R14: R15: ... [ 2846.587644][ T353] Showing all locks held in the system: [ 2846.62236
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix the race between the GEM close and debugfs
== Series Details ==
Series: drm/i915: Fix the race between the GEM close and debugfs
URL : https://patchwork.freedesktop.org/series/81646/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9006 -> Patchwork_18489
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18489/index.html
Known issues
Here are the changes found in Patchwork_18489 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_flink_basic@flink-lifetime:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar
issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9006/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18489/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
* igt@i915_selftest@live@execlists:
- fi-icl-y: [PASS][3] -> [INCOMPLETE][4] ([i915#2276])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9006/fi-icl-y/igt@i915_selftest@l...@execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18489/fi-icl-y/igt@i915_selftest@l...@execlists.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9006/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18489/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.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_9006/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18489/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-tgl-y: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9006/fi-tgl-y/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18489/fi-tgl-y/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
Possible fixes
* igt@gem_flink_basic@double-flink:
- fi-tgl-y: [DMESG-WARN][11] ([i915#402]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9006/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18489/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
* igt@kms_busy@basic@flip:
- {fi-tgl-dsi}: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9006/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18489/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-tgl-y: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9006/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18489/fi-tgl-y/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
Warnings
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- 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_9006/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18489/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][20] ([i915#62] / [i915#92]) +3 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9006/fi-kbl-x1275/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18489/fi-kbl-x1275/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2276]: https://gitlab.freedesktop.org/drm/intel/issues/2276
[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/d
[Intel-gfx] [PATCH i-g-t v4] intel-gpu-top: Support for client stats
From: Tvrtko Ursulin
Adds support for per-client engine busyness stats i915 exports in sysfs
and produces output like the below:
==
intel-gpu-top - 935/ 935 MHz;0% RC6; 14.73 Watts; 1097 irqs/s
IMC reads: 1401 MiB/s
IMC writes:4 MiB/s
ENGINE BUSY MI_SEMA MI_WAIT
Render/3D/0 63.73% |███ | 3% 0%
Blitter/09.53% |██▊ | 6% 0%
Video/0 39.32% |███▊ | 16% 0%
Video/1 15.62% |▋ | 0% 0%
VideoEnhance/00.00% | | 0% 0%
PIDNAME RCS BCS VCS VECS
4084gem_wsim |█▌ ||█ || || |
4086gem_wsim |█▌ || ||███|| |
==
Apart from the existing physical engine utilization it now also shows
utilization per client and per engine class.
v2:
* Version to match removal of global enable_stats toggle.
* Plus various fixes.
v3:
* Support brief backward jumps in client stats.
v4:
* Support device selection.
Signed-off-by: Tvrtko Ursulin
---
tools/intel_gpu_top.c | 554 +-
1 file changed, 543 insertions(+), 11 deletions(-)
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index cae01c25b920..a3c69d73100e 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -679,23 +679,362 @@ static void pmu_sample(struct engines *engines)
}
}
+enum client_status {
+ FREE = 0, /* mbz */
+ ALIVE,
+ PROBE
+};
+
+struct clients;
+
+struct client {
+ struct clients *clients;
+
+ enum client_status status;
+ unsigned int id;
+ unsigned int pid;
+ char name[128];
+ unsigned int samples;
+ unsigned long total;
+ struct engines *engines;
+ unsigned long *val;
+ uint64_t *last;
+};
+
+struct engine_class {
+ unsigned int class;
+ const char *name;
+ unsigned int num_engines;
+};
+
+struct clients {
+ unsigned int num_classes;
+ struct engine_class *class;
+
+ char sysfs_root[64];
+
+ unsigned int num_clients;
+ struct client *client;
+};
+
+#define for_each_client(clients, c, tmp) \
+ for ((tmp) = (clients)->num_clients, c = (clients)->client; \
+(tmp > 0); (tmp)--, (c)++)
+
+static struct clients *init_clients(const char *drm_card)
+{
+ struct clients *clients = malloc(sizeof(*clients));
+ const char *slash;
+ ssize_t ret;
+
+ memset(clients, 0, sizeof(*clients));
+
+ if (drm_card) {
+ slash = rindex(drm_card, '/');
+ assert(slash);
+ } else {
+ slash = "card0";
+ }
+
+ ret = snprintf(clients->sysfs_root, sizeof(clients->sysfs_root),
+ "/sys/class/drm/%s/clients/", slash);
+ assert(ret > 0 && ret < sizeof(clients->sysfs_root));
+
+ return clients;
+}
+
+static uint64_t
+read_client_busy(const struct client *client, unsigned int class)
+{
+ char buf[256];
+ ssize_t ret;
+
+ ret = snprintf(buf, sizeof(buf), "%s/%u/busy/%u",
+ client->clients->sysfs_root, client->id, class);
+ assert(ret > 0 && ret < sizeof(buf));
+ if (ret <= 0 || ret == sizeof(buf))
+ return 0;
+
+ return filename_to_u64(buf, 10);
+}
+
+static struct client *
+find_client(struct clients *clients, enum client_status status, unsigned int
id)
+{
+ struct client *c;
+ int tmp;
+
+ for_each_client(clients, c, tmp) {
+ if ((status == FREE && c->status == FREE) ||
+ (status == c->status && c->id == id))
+ return c;
+ }
+
+ return NULL;
+}
+
+static void update_client(struct client *c, unsigned int pid, char *name)
+{
+ uint64_t val[c->clients->num_classes];
+ unsigned int i;
+
+ if (c->pid != pid)
+ c->pid = pid;
+
+ if (strcmp(c->name, name))
+ strncpy(c->name, name, sizeof(c->name) - 1);
+
+ for (i = 0; i < c->clients->num_classes; i++)
+ val[i] = read_client_busy(c, c->clients->class[i].class);
+
+ c->total = 0;
+
+ for (i = 0; i < c->clients->num_classes; i++) {
+ if (val[i] < c->last[i])
+ continue; /* It will catch up soon. */
+
+ c->val[i] = val[i] - c->last[i];
+ c->total += c->val[i];
+ c->last[i] = val[i];
+ }
+
+ c->samples++;
+ c->status = ALIVE;
+}
+
+static int class_cmp(const void *_a, const void *_b)
+{
+ const struct engine_class *a
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use fb->format->is_yuv for the g4x+ sprite RGB vs. YUV check
On Mon, 14 Sep 2020, Ville Syrjälä wrote: > On Fri, Sep 11, 2020 at 09:13:18PM +0300, Jani Nikula wrote: >> On Thu, 06 Feb 2020, Ville Syrjala wrote: >> > From: Ville Syrjälä >> > >> > g4x+ sprites have an extra cdclk limitation listed for RGB formats. >> > For some random reason I chose to use cpp>=4 as the check for that. >> > While that does actually work let's deobfuscate it by checking >> > for !is_yuv instead. I suspect is_yuv didn't exist way back when >> > I originally write the code. >> >> Mmh, there are formats with cpp >= 4 && is_yuv == true making this look >> like a functional change... but I presume those are not relevant and/or >> this change is the right thing to do anyway. > > This only applies to g4x/ilk/snb which only support > YUYV/etc. (cpp==2), and 32/64bpp RGB (cpp==4/8). Ack. > >> >> Acked-by: Jani Nikula >> >> > >> > Also drop the duplicate comment. >> > >> > Signed-off-by: Ville Syrjälä >> > --- >> > drivers/gpu/drm/i915/display/intel_sprite.c | 4 ++-- >> > 1 file changed, 2 insertions(+), 2 deletions(-) >> > >> > diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c >> > b/drivers/gpu/drm/i915/display/intel_sprite.c >> > index 6e2e22d9bbaa..f95fe2c99468 100644 >> > --- a/drivers/gpu/drm/i915/display/intel_sprite.c >> > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c >> > @@ -1624,8 +1624,8 @@ static int g4x_sprite_min_cdclk(const struct >> > intel_crtc_state *crtc_state, >> >limit -= decimate; >> > >> >/* -10% for RGB */ >> > - if (fb->format->cpp[0] >= 4) >> > - limit--; /* -10% for RGB */ >> > + if (!fb->format->is_yuv) >> > + limit--; >> > >> >/* >> > * We should also do -10% if sprite scaling is enabled >> >> -- >> Jani Nikula, Intel Open Source Graphics Center -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/9] drm/i915: Track runtime spent in closed GEM contexts
Tvrtko Ursulin writes:
> From: Tvrtko Ursulin
>
> As GEM contexts are closed we want to have the DRM client remember how
> much GPU time they used (per class) so later we can used it for smarter
> purposes.
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 12 +++-
> drivers/gpu/drm/i915/i915_drm_client.h | 7 +++
> 2 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index a12e926444e1..a50b83659399 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -351,8 +351,18 @@ static void i915_gem_context_free(struct
> i915_gem_context *ctx)
>
> GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
>
> - if (client)
> + if (client) {
> + unsigned int i;
> +
> + /* Transfer accumulated runtime to the parent drm client. */
> + BUILD_BUG_ON(ARRAY_SIZE(client->past_runtime) !=
> + ARRAY_SIZE(ctx->past_runtime));
> + for (i = 0; i < ARRAY_SIZE(client->past_runtime); i++)
> + atomic64_add(atomic64_read(&ctx->past_runtime[i]),
> + &client->past_runtime[i]);
> +
> i915_drm_client_put(client);
> + }
>
> spin_lock(&ctx->i915->gem.contexts.lock);
> list_del(&ctx->link);
> diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
> b/drivers/gpu/drm/i915/i915_drm_client.h
> index 11b48383881d..29b116606596 100644
> --- a/drivers/gpu/drm/i915/i915_drm_client.h
> +++ b/drivers/gpu/drm/i915/i915_drm_client.h
> @@ -15,6 +15,8 @@
> #include
> #include
>
> +#include "gt/intel_engine_types.h"
> +
> struct i915_drm_clients {
> struct xarray xarray;
> u32 next_id;
> @@ -41,6 +43,11 @@ struct i915_drm_client {
> struct device_attribute pid;
> struct device_attribute name;
> } attr;
> +
> + /**
> + * @past_runtime: Accumulation of pphwsp runtimes from closed contexts.
> + */
> + atomic64_t past_runtime[MAX_ENGINE_CLASS + 1];
> };
>
> void i915_drm_clients_init(struct i915_drm_clients *clients);
> --
> 2.25.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 01/20] drm/amdgpu: Introduce GEM object functions
Hi
Am 13.08.20 um 12:22 schrieb Christian König:
> Am 13.08.20 um 10:36 schrieb Thomas Zimmermann:
>> GEM object functions deprecate several similar callback interfaces in
>> struct drm_driver. This patch replaces the per-driver callbacks with
>> per-instance callbacks in amdgpu. The only exception is gem_prime_mmap,
>> which is non-trivial to convert.
>>
>> Signed-off-by: Thomas Zimmermann
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 --
>> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 12
>> 2 files changed, 12 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> index 81a79760ca61..51525b8774c9 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> @@ -1468,19 +1468,13 @@ static struct drm_driver kms_driver = {
>> .lastclose = amdgpu_driver_lastclose_kms,
>> .irq_handler = amdgpu_irq_handler,
>> .ioctls = amdgpu_ioctls_kms,
>> - .gem_free_object_unlocked = amdgpu_gem_object_free,
>> - .gem_open_object = amdgpu_gem_object_open,
>> - .gem_close_object = amdgpu_gem_object_close,
>> .dumb_create = amdgpu_mode_dumb_create,
>> .dumb_map_offset = amdgpu_mode_dumb_mmap,
>> .fops = &amdgpu_driver_kms_fops,
>> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
>> - .gem_prime_export = amdgpu_gem_prime_export,
>> .gem_prime_import = amdgpu_gem_prime_import,
>> - .gem_prime_vmap = amdgpu_gem_prime_vmap,
>> - .gem_prime_vunmap = amdgpu_gem_prime_vunmap,
>> .gem_prime_mmap = amdgpu_gem_prime_mmap,
>> .name = DRIVER_NAME,
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> index 43f4966331dd..ca2b79f94e99 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> @@ -36,6 +36,7 @@
>> #include
>> #include
>> #include "amdgpu.h"
>> +#include "amdgpu_dma_buf.h"
>> #include "amdgpu_trace.h"
>> #include "amdgpu_amdkfd.h"
>> @@ -510,6 +511,15 @@ bool amdgpu_bo_support_uswc(u64 bo_flags)
>> #endif
>> }
>> +static const struct drm_gem_object_funcs amdgpu_gem_object_funcs = {
>> + .free = amdgpu_gem_object_free,
>> + .open = amdgpu_gem_object_open,
>> + .close = amdgpu_gem_object_close,
>> + .export = amdgpu_gem_prime_export,
>> + .vmap = amdgpu_gem_prime_vmap,
>> + .vunmap = amdgpu_gem_prime_vunmap,
>> +};
>> +
>
> Wrong file, this belongs into amdgpu_gem.c
>
>> static int amdgpu_bo_do_create(struct amdgpu_device *adev,
>> struct amdgpu_bo_param *bp,
>> struct amdgpu_bo **bo_ptr)
>> @@ -552,6 +562,8 @@ static int amdgpu_bo_do_create(struct
>> amdgpu_device *adev,
>> bo = kzalloc(sizeof(struct amdgpu_bo), GFP_KERNEL);
>> if (bo == NULL)
>> return -ENOMEM;
>> +
>> + bo->tbo.base.funcs = &amdgpu_gem_object_funcs;
>
> And this should probably go into amdgpu_gem_object_create().
I'm trying to understand what amdgpu does. What about all the places
where amdgpu calls amdgpu_bo_create() internally? Wouldn't these miss
the free callback for the GEM object?
Best regards
Thomas
>
> Apart from that looks like a good idea to me.
>
> Christian.
>
>> drm_gem_private_object_init(adev->ddev, &bo->tbo.base, size);
>> INIT_LIST_HEAD(&bo->shadow_list);
>> bo->vm_bo = NULL;
>
--
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
Re: [Intel-gfx] [PATCH 4/9] drm/i915: Track runtime spent in unreachable intel_contexts
Tvrtko Ursulin writes:
> From: Tvrtko Ursulin
>
> As contexts are abandoned we want to remember how much GPU time they used
> (per class) so later we can used it for smarter purposes.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
> drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 5 +
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index df5488998d53..a12e926444e1 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -253,7 +253,19 @@ static void free_engines_rcu(struct rcu_head *rcu)
> {
> struct i915_gem_engines *engines =
> container_of(rcu, struct i915_gem_engines, rcu);
> + struct i915_gem_context *ctx = engines->ctx;
> + struct i915_gem_engines_iter it;
> + struct intel_context *ce;
> +
> + /* Transfer accumulated runtime to the parent GEM context. */
> + for_each_gem_engine(ce, engines, it) {
> + unsigned int class = ce->engine->uabi_class;
>
> + GEM_BUG_ON(class >= ARRAY_SIZE(ctx->past_runtime));
> + atomic64_add(ce->runtime.total, &ctx->past_runtime[class]);
> + }
> +
> + i915_gem_context_put(ctx);
> i915_sw_fence_fini(&engines->fence);
> free_engines(engines);
> }
> @@ -274,7 +286,6 @@ engines_notify(struct i915_sw_fence *fence, enum
> i915_sw_fence_notify state)
> list_del(&engines->link);
> spin_unlock_irqrestore(&ctx->stale.lock, flags);
> }
> - i915_gem_context_put(engines->ctx);
> break;
>
> case FENCE_FREE:
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> index 31a6a30f7ea8..e473984b52c8 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> @@ -178,6 +178,11 @@ struct i915_gem_context {
> spinlock_t lock;
> struct list_head engines;
> } stale;
> +
> + /**
> + * @past_runtime: Accumulation of freed intel_context pphwsp runtimes.
We are tracking runtime in per engine hw context, which pphwsp is just
part of (first page of it).
If this is also in par with the documentation, good enough.
Reviewed-by: Mika Kuoppala
> + */
> + atomic64_t past_runtime[MAX_ENGINE_CLASS + 1];
> };
>
> #endif /* __I915_GEM_CONTEXT_TYPES_H__ */
> --
> 2.25.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 3/9] drm/i915: Make GEM contexts track DRM clients
On 11/09/2020 07:44, Lucas De Marchi wrote:
On Fri, Sep 04, 2020 at 01:59:28PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
If we make GEM contexts keep a reference to i915_drm_client for the whole
of their lifetime, we can consolidate the current task pid and name usage
by getting it from the client.
v2:
* Don't bother supporting selftests contexts from debugfs. (Chris)
v3:
* Trivial rebase.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 19 +---
.../gpu/drm/i915/gem/i915_gem_context_types.h | 13 ++---
drivers/gpu/drm/i915/i915_debugfs.c | 29 +++
drivers/gpu/drm/i915/i915_gpu_error.c | 22 --
4 files changed, 41 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 5919cc5f8348..ab8d25eda204 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -336,8 +336,13 @@ static struct i915_gem_engines
*default_engines(struct i915_gem_context *ctx)
static void i915_gem_context_free(struct i915_gem_context *ctx)
{
+ struct i915_drm_client *client = ctx->client;
+
GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
+ if (client)
+ i915_drm_client_put(client);
+
spin_lock(&ctx->i915->gem.contexts.lock);
list_del(&ctx->link);
spin_unlock(&ctx->i915->gem.contexts.lock);
@@ -348,7 +353,6 @@ static void i915_gem_context_free(struct
i915_gem_context *ctx)
if (ctx->timeline)
intel_timeline_put(ctx->timeline);
- put_pid(ctx->pid);
mutex_destroy(&ctx->mutex);
kfree_rcu(ctx, rcu);
@@ -936,6 +940,7 @@ static int gem_context_register(struct
i915_gem_context *ctx,
u32 *id)
{
struct drm_i915_private *i915 = ctx->i915;
+ struct i915_drm_client *client;
struct i915_address_space *vm;
int ret;
@@ -947,9 +952,13 @@ static int gem_context_register(struct
i915_gem_context *ctx,
WRITE_ONCE(vm->file, fpriv); /* XXX */
mutex_unlock(&ctx->mutex);
- ctx->pid = get_task_pid(current, PIDTYPE_PID);
+ client = i915_drm_client_get(fpriv->client);
+
+ rcu_read_lock();
snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
- current->comm, pid_nr(ctx->pid));
+ rcu_dereference(client->name),
+ pid_nr(rcu_dereference(client->pid)));
+ rcu_read_unlock();
/* And finally expose ourselves to userspace via the idr */
ret = xa_alloc(&fpriv->context_xa, id, ctx, xa_limit_32b,
GFP_KERNEL);
@@ -960,10 +969,12 @@ static int gem_context_register(struct
i915_gem_context *ctx,
list_add_tail(&ctx->link, &i915->gem.contexts.list);
spin_unlock(&i915->gem.contexts.lock);
+ ctx->client = client;
as per 5f7cceabf104 ("drm/i915/gem: Delay tracking the GEM context until
it is registered")
shouldn't you finish construct ctx before adding it to the list?
Sent an updated series - should be okay now.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [10/12] drm/i915: Introduce HPD_PORT_TC
On Sat, Sep 12, 2020 at 01:30:23AM +, Souza, Jose wrote:
> On Wed, 2020-07-01 at 00:55 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä <
> > ville.syrj...@linux.intel.com
> > >
> >
> > Make a clean split between hpd pins for DDI vs. TC. This matches
> > how the actual hardware is split.
> >
> > And with this we move the DDI/PHY->HPD pin mapping into the encoder
> > init instead of having to remap yet again in the interrupt code.
> >
> > Signed-off-by: Ville Syrjälä <
> > ville.syrj...@linux.intel.com
> > >
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 65 +-
> > drivers/gpu/drm/i915/display/intel_hotplug.c | 25 +---
> > drivers/gpu/drm/i915/i915_drv.h | 17 +--
> > drivers/gpu/drm/i915/i915_irq.c | 121 +--
> > 4 files changed, 102 insertions(+), 126 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index d024491738b3..a2c9815c5abc 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -4847,6 +4847,57 @@ intel_ddi_max_lanes(struct intel_digital_port
> > *intel_dport)
> > return max_lanes;
> > }
> >
> > +static enum hpd_pin tgl_hpd_pin(struct drm_i915_private *dev_priv,
> > + enum port port)
> > +{
> > + if (port >= PORT_D)
> > + return HPD_PORT_TC1 + port - PORT_D;
> > + else
> > + return HPD_PORT_A + port - PORT_A;
> > +}
> > +
> > +static enum hpd_pin rkl_hpd_pin(struct drm_i915_private *dev_priv,
> > + enum port port)
> > +{
> > + if (HAS_PCH_TGP(dev_priv))
> > + return tgl_hpd_pin(dev_priv, port);
> > +
> > + if (port >= PORT_D)
> > + return HPD_PORT_C + port - PORT_D;
>
> The above looks wrong, for it would match with only the return bellow.
On rkl+tgp we want:
PORT_A (DDI A) -> HPD_PORT_A
PORT_B (DDI B) -> HPD_PORT_B
PORT_D (DDI TC1) -> HPD_PORT_TC1
PORT_E (DDI TC2) -> HPD_PORT_TC2
On rkl+cmp we want:
PORT_A (DDI A) -> HPD_PORT_A
PORT_B (DDI B) -> HPD_PORT_B
PORT_D (DDI TC1) -> HPD_PORT_C
PORT_E (DDI TC2) -> HPD_PORT_D
>
> > + else
> > + return HPD_PORT_A + port - PORT_A;
> > +}
> > +
> > +static enum hpd_pin icl_hpd_pin(struct drm_i915_private *dev_priv,
> > + enum port port)
> > +{
> > + if (port >= PORT_C)
> > + return HPD_PORT_TC1 + port - PORT_C;
> > + else
> > + return HPD_PORT_A + port - PORT_A;
> > +}
> > +
> > +static enum hpd_pin ehl_hpd_pin(struct drm_i915_private *dev_priv,
> > + enum port port)
> > +{
> > + if (port == PORT_D)
> > + return HPD_PORT_A;
> > +
> > + if (HAS_PCH_MCC(dev_priv))
> > + return icl_hpd_pin(dev_priv, port);
>
> Maybe call tgl_hpd_pin() for HAS_PCH_MCC()? The code bellow will match but
> just for consistency.
On jsl+mcc we want:
PORT_A/D (DDI A/D) -> HPD_PORT_A
PORT_B (DDI B) -> HPD_PORT_B
PORT_C (DDI C) -> HPD_PORT_TC1
on jsl+icp we want:
PORT_A/D (DDI A/D) -> HPD_PORT_A
PORT_B (DDI B) -> HPD_PORT_B
PORT_C (DDI C) -> HPD_PORT_C
--
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/4] drm/i915/display: Program PSR2 selective fetch registers
On Mon, Aug 31, 2020 at 06:09:23PM -0700, José Roberto de Souza wrote:
> Another step towards PSR2 selective fetch, here programming plane
> selective fetch registers and MAN_TRK_CTL enabling selective fetch but
> for now it is fetching the whole area of the planes.
> The damaged area calculation will come as next and final step.
>
> BSpec: 55229
> Cc: Gwan-gyeong Mun
> Cc: Ville Syrjälä
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 10 +-
> .../drm/i915/display/intel_display_types.h| 2 +
> drivers/gpu/drm/i915/display/intel_psr.c | 129 +-
> drivers/gpu/drm/i915/display/intel_psr.h | 10 +-
> drivers/gpu/drm/i915/display/intel_sprite.c | 3 +
> 5 files changed, 145 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index c8b1dd1a9e46..865486e89915 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -11799,6 +11799,9 @@ static void i9xx_update_cursor(struct intel_plane
> *plane,
> if (INTEL_GEN(dev_priv) >= 9)
> skl_write_cursor_wm(plane, crtc_state);
>
> + if (!needs_modeset(crtc_state))
> + intel_psr2_program_plane_sel_fetch(plane, crtc_state,
> plane_state, 0);
> +
> if (plane->cursor.base != base ||
> plane->cursor.size != fbc_ctl ||
> plane->cursor.cntl != cntl) {
> @@ -12810,8 +12813,11 @@ static int intel_crtc_atomic_check(struct
> intel_atomic_state *state,
>
> }
>
> - if (!mode_changed)
> - intel_psr2_sel_fetch_update(state, crtc);
> + if (!mode_changed) {
> + ret = intel_psr2_sel_fetch_update(state, crtc);
> + if (ret)
> + return ret;
> + }
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 9349b15afff6..2138bb0f1587 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -586,6 +586,8 @@ struct intel_plane_state {
> u32 planar_slave;
>
> struct drm_intel_sprite_colorkey ckey;
> +
> + struct drm_rect psr2_sel_fetch_area;
> };
>
> struct intel_initial_plane_config {
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 6698d0209879..b60ea133a527 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1173,6 +1173,46 @@ static void psr_force_hw_tracking_exit(struct
> drm_i915_private *dev_priv)
> intel_psr_exit(dev_priv);
> }
>
> +void intel_psr2_program_plane_sel_fetch(struct intel_plane *plane,
> + const struct intel_crtc_state
> *crtc_state,
> + const struct intel_plane_state
> *plane_state,
> + int color_plane)
> +{
> + struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> + const struct drm_rect *clip;
> + enum pipe pipe = plane->pipe;
> + u32 val;
> +
> + if (!plane_state || !dev_priv->psr.psr2_sel_fetch_enabled)
> + return;
> +
> + /*
> + * skl_plane_ctl_crtc()/i9xx_cursor_ctl_crtc() return 0 for gen11+, so
> + * plane_state->ctl is the right value
> + */
> + intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, plane->id),
> plane_state->ctl);
> + if (!plane_state->ctl || plane->id == PLANE_CURSOR)
> + return;
> +
> + clip = &plane_state->psr2_sel_fetch_area;
> +
> + val = (clip->y1 + plane_state->uapi.crtc_y) << 16;
crtc_x/y are the raw values usrspace gave us. That is definitely not
what we should be looking at.
As the first step I think these functions should just program the
registers with *exactly* the same values as we program into the
normal plane register. That gets us to the point where we're
actually programming something into the register without having to
complicate things with calculating the selective fetch area.
> + val |= plane_state->uapi.crtc_x;
> + intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_POS(pipe, plane->id),
> + val);
> +
> + val = (clip->y1 + plane_state->color_plane[color_plane].y) << 16;
> + val |= plane_state->color_plane[color_plane].x;
> + intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_OFFSET(pipe, plane->id),
> + val);
> +
> + /* Sizes are 0 based */
> + val = (drm_rect_height(clip) - 1) << 16;
> + val |= (drm_rect_width(&plane_state->uapi.src) >> 16) - 1;
> + intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_SIZE(pipe, plane->id),
> + val);
> +}
> +
> void intel_psr2_program_trans_man_trk_ctl(const struct intel_crtc_state
> *crtc_state)
> {
> st
Re: [Intel-gfx] [PATCH 2/4] drm/i915/display: Fix state of PSR2 sub features
On Mon, Aug 31, 2020 at 06:09:22PM -0700, José Roberto de Souza wrote:
> In case PSR2 is disabled by debugfs dc3co_enabled and
> psr2_sel_fetch_enabled were still being set causing some code paths
> to be executed were it should not.
> We have tests for PSR1 and PSR2 so keep those features disabled when
> PSR1 is active but PSR2 is supported is important.
>
> Cc: Gwan-gyeong Mun
> Cc: Ville Syrjälä
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 4e09ae61d4aa..6698d0209879 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -962,12 +962,14 @@ static void intel_psr_enable_locked(struct
> drm_i915_private *dev_priv,
> dev_priv->psr.psr2_enabled = intel_psr2_enabled(dev_priv, crtc_state);
> dev_priv->psr.busy_frontbuffer_bits = 0;
> dev_priv->psr.pipe = to_intel_crtc(crtc_state->uapi.crtc)->pipe;
> - dev_priv->psr.dc3co_enabled = !!crtc_state->dc3co_exitline;
> + dev_priv->psr.dc3co_enabled = !!crtc_state->dc3co_exitline &&
> + dev_priv->psr.psr2_enabled;
> dev_priv->psr.transcoder = crtc_state->cpu_transcoder;
> /* DC5/DC6 requires at least 6 idle frames */
> val = usecs_to_jiffies(intel_get_frame_time_us(crtc_state) * 6);
> dev_priv->psr.dc3co_exit_delay = val;
> - dev_priv->psr.psr2_sel_fetch_enabled =
> crtc_state->enable_psr2_sel_fetch;
> + dev_priv->psr.psr2_sel_fetch_enabled =
> crtc_state->enable_psr2_sel_fetch &&
> +dev_priv->psr.psr2_enabled;
>
> /*
>* If a PSR error happened and the driver is reloaded, the EDP_PSR_IIR
> @@ -1178,7 +1180,7 @@ void intel_psr2_program_trans_man_trk_ctl(const struct
> intel_crtc_state *crtc_st
> struct i915_psr *psr = &dev_priv->psr;
>
> if (!HAS_PSR2_SEL_FETCH(dev_priv) ||
> - !crtc_state->enable_psr2_sel_fetch)
> + !dev_priv->psr.psr2_sel_fetch_enabled)
> return;
>
> intel_de_write(dev_priv, PSR2_MAN_TRK_CTL(psr->transcoder),
> @@ -1189,8 +1191,9 @@ void intel_psr2_sel_fetch_update(struct
> intel_atomic_state *state,
>struct intel_crtc *crtc)
> {
> struct intel_crtc_state *crtc_state =
> intel_atomic_get_new_crtc_state(state, crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>
> - if (!crtc_state->enable_psr2_sel_fetch)
> + if (!dev_priv->psr.psr2_sel_fetch_enabled)
This looks rather sketchy. AFAICS this gets called during atomic_check()
so looking at stuff outside the crtc state is very suspicious.
> return;
>
> crtc_state->psr2_man_track_ctl = PSR2_MAN_TRK_CTL_ENABLE |
> --
> 2.28.0
--
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/2] drm/i915: Fix g4x+ sprite dotclock limit for upscaling
On Fri, Sep 11, 2020 at 09:03:36PM +0300, Jani Nikula wrote: > On Thu, 06 Feb 2020, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Even if we're not doing downscaling we should account for > > some of the extra dotclock limitations for g4x+ sprites. In > > particular we must never exceed the 90% rule, and with RGB > > that limits actually drops to 80%. > > > > So instead of bailing out when upscaling let's clamp the > > scaling factor appropriately and go through the rest of > > calculation normally. By luck we already did the full > > calculations for the 1:1 case. > > > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/i915/display/intel_sprite.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c > > b/drivers/gpu/drm/i915/display/intel_sprite.c > > index 7abeefe8dce5..6e2e22d9bbaa 100644 > > --- a/drivers/gpu/drm/i915/display/intel_sprite.c > > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c > > @@ -1611,8 +1611,7 @@ static int g4x_sprite_min_cdclk(const struct > > intel_crtc_state *crtc_state, > > hscale = drm_rect_calc_hscale(&plane_state->uapi.src, > > &plane_state->uapi.dst, > > 0, INT_MAX); > > - if (hscale < 0x1) > > - return pixel_rate; > > + hscale = max(hscale, 0x1u); > > It bugs me that drm_rect seems to be used for both integer and 16.16 > fixed point and whatnot. In theory it can use any arbitrary precision. There are a few functions which do assume .0 or .16 though. > > It also gives me an uneasy feeling that hscale is uint while > drm_rect_calc_hscale() may return -ERANGE... but I guess shouldn't > happen. Yeah, should not happen since we've already done this same calculation (+check for <0) earlier. I've occasionally pondered about stashing the h/vscale from that first check into the plane state so we wouldn't have to redo it here. But I never found sufficient motivation to actually do it. > > All in all, > > Reviewed-by: Jani Nikula Ta. > > > > > > /* Decimation steps at 2x,4x,8x,16x */ > > decimate = ilog2(hscale >> 16); > > -- > Jani Nikula, Intel Open Source Graphics Center -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915: boot/load regression since Linux v5.7-rc1 on Iris Pro (Crystal Well)
Hi Jani, there is also already a bug report at https://gitlab.freedesktop.org/drm/intel/-/issues/2381 but it also seems to get not much attention. Ville Syrjälä from Intel provided a workaround and mentioned the issue was encountered before, but has never been fixed. It would be great if someone from Intel would be investigating this bug that renders the affected machines virtually unusable and I guess all affected users who chimed in are willing to provide any information needed to find the root cause of this issue. Looking forward to hearing from you or your team! Best regards, Peter Ganzhorn On Thu, Sep 10, 2020, 15:37 Jani Nikula wrote: > On Wed, 02 Sep 2020, Peter Vollmer wrote: > > Hi, > > > > since kernel v5.7-rc1 my graphical output hangs on boot or if the i915 > > module is blacklisted on modprobe. > > I've already found and extended a bugzilla > > https://bugzilla.kernel.org/show_bug.cgi?id=208737 > > > > But sadly there has been little reaction so I would appreciate any > > help in further debugging or better yet resolving this issue. > > Sorry, nobody in the team looks at kernel.org bugzilla except once in a > blue moon to close bugs and tell people to report bugs at fdo gitlab > [1]. > > BR, > Jani. > > > [1] https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs > > > -- > Jani Nikula, Intel Open Source Graphics Center > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
