Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
On Wed, Sep 23 2020 at 17:12, Steven Rostedt wrote: > On Wed, 23 Sep 2020 22:55:54 +0200 > Then scratch the idea of having anonymous local_lock() and just bring > local_lock in directly? Then have a kmap local lock, which would only > block those that need to do a kmap. That's still going to end up in lock ordering nightmares and you lose the ability to use kmap_local from arbitrary contexts which was again one of the goals of this exercise. Aside of that you're imposing reentrancy protections on something which does not need it in the first place. > Now as for migration disabled nesting, at least now we would have > groupings of this, and perhaps the theorists can handle that. I mean, > how is this much different that having a bunch of tasks blocked on a > mutex with the owner is pinned on a CPU? > > migrate_disable() is a BKL of pinning affinity. No. That's just wrong. preempt disable is a concurrency control, i.e. protecting against reentrancy on a given CPU. But it's a cpu global protection which means that it's not protecting a specific code path. Contrary to preempt disable, migrate disable is not protecting against reentrancy on a given CPU. It's a temporary restriction to the scheduler on placement. The fact that disabling preemption implicitely disables migration does not make them semantically equivalent. > If we only have local_lock() available (even on !RT), then it makes > the blocking in groups. At least this way you could grep for all the > different local_locks in the system and plug that into the algorithm > for WCS, just like one would with a bunch of mutexes. You cannot do that on RT at all where migrate disable is substituting preempt disable in spin and rw locks. The result would be the same as with a !RT kernel just with horribly bad performance. That means the stacking problem has to be solved anyway. So why on earth do you want to create yet another special duct tape case for kamp_local() which proliferates inconsistency instead of aiming for consistency accross all preemption models? Thanks, tglx ___ 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/15/20 4:31 PM, Tvrtko Ursulin wrote:
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.
I am not sure what step is attaching domain to device, but these type
messages:
<3> [209.526605] DMAR: intel_iommu_map: iommu width (39) is not
>> sufficient for the mapped address (008000)
They definitely appear to happen at runtime, as i915 is getting
exercised by userspace.
Can you please check whether below change helps here?
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index c8323a9f8bde..0484c539debc 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -724,6 +724,7 @@ static int domain_update_device_node(struct
dmar_domain *domain)
/* Some capabilities may be different across iommus */
static void domain_update_iommu_cap(struct dmar_domain *domain)
{
+ domain->geometry.aperture_end = __DOMAIN_MAX_ADDR(dmar_domain->gaw);
domain_update_iommu_coherency(domain);
domain->iommu_snooping = domain_update_iommu_snooping(NULL);
domain->iommu_superpage = domain_update_iommu_superpage(domain,
NULL);
Best regards,
baolu
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Remove DPCD Aux Backlight Control PWM_PIN check
== Series Details == Series: Remove DPCD Aux Backlight Control PWM_PIN check URL : https://patchwork.freedesktop.org/series/82041/ State : success == Summary == CI Bug Log - changes from CI_DRM_9045_full -> Patchwork_18560_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18560_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]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/shard-kbl1/igt@gem_ctx_isolation@preservation...@vcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18560/shard-kbl7/igt@gem_ctx_isolation@preservation...@vcs0.html * igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox: - shard-skl: [PASS][3] -> [FAIL][4] ([i915#2374]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/shard-skl4/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18560/shard-skl3/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html * igt@gem_exec_reloc@basic-many-active@bcs0: - shard-glk: [PASS][5] -> [FAIL][6] ([i915#2389]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/shard-glk1/igt@gem_exec_reloc@basic-many-act...@bcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18560/shard-glk9/igt@gem_exec_reloc@basic-many-act...@bcs0.html * igt@gem_userptr_blits@process-exit-busy: - shard-skl: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +6 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/shard-skl9/igt@gem_userptr_bl...@process-exit-busy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18560/shard-skl4/igt@gem_userptr_bl...@process-exit-busy.html * igt@i915_selftest@mock@contexts: - shard-apl: [PASS][9] -> [INCOMPLETE][10] ([i915#1635] / [i915#2278]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/shard-apl6/igt@i915_selftest@m...@contexts.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18560/shard-apl2/igt@i915_selftest@m...@contexts.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([i915#300]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/shard-skl6/igt@kms_cursor_...@pipe-b-cursor-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18560/shard-skl9/igt@kms_cursor_...@pipe-b-cursor-suspend.html - shard-snb: [PASS][13] -> [DMESG-WARN][14] ([i915#42]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/shard-snb6/igt@kms_cursor_...@pipe-b-cursor-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18560/shard-snb2/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#2346]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/shard-skl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18560/shard-skl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html * igt@kms_flip@flip-vs-suspend@a-vga1: - shard-hsw: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/shard-hsw2/igt@kms_flip@flip-vs-susp...@a-vga1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18560/shard-hsw6/igt@kms_flip@flip-vs-susp...@a-vga1.html * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-cpu: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#49]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/shard-skl3/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-indfb-draw-mmap-cpu.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18560/shard-skl9/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-indfb-draw-mmap-cpu.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-render: - shard-tglb: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) +4 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/shard-tglb7/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-shrfb-draw-render.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18560/shard-tglb2/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-shrfb-draw-render.html * igt@kms_hdr@bpc-switch: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#1188]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/shard-skl1/igt@kms_...@bpc-switch.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18560/shard-skl1/igt@kms_...@bpc-switch.html * igt@kms_plane_alpha_blend@pipe-a-constant
[Intel-gfx] ✗ Fi.CI.IGT: failure for Fix NULL pointer found by static analysis (rev2)
== Series Details == Series: Fix NULL pointer found by static analysis (rev2) URL : https://patchwork.freedesktop.org/series/81999/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9045_full -> Patchwork_18559_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18559_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18559_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18559_full: ### IGT changes ### Possible regressions * igt@runner@aborted: - shard-hsw: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18559/shard-hsw8/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_18559_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_import_export@prime: - shard-hsw: [PASS][2] -> [INCOMPLETE][3] ([i915#2377]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/shard-hsw2/igt@drm_import_exp...@prime.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18559/shard-hsw8/igt@drm_import_exp...@prime.html * igt@gem_exec_reloc@basic-many-active@bcs0: - shard-glk: [PASS][4] -> [FAIL][5] ([i915#2389]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/shard-glk1/igt@gem_exec_reloc@basic-many-act...@bcs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18559/shard-glk4/igt@gem_exec_reloc@basic-many-act...@bcs0.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][6] -> [SKIP][7] ([i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/shard-tglb8/igt@gem_huc_c...@huc-copy.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18559/shard-tglb6/igt@gem_huc_c...@huc-copy.html * igt@gem_userptr_blits@sync-unmap-cycles: - shard-skl: [PASS][8] -> [TIMEOUT][9] ([i915#1958] / [i915#2424]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/shard-skl9/igt@gem_userptr_bl...@sync-unmap-cycles.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18559/shard-skl2/igt@gem_userptr_bl...@sync-unmap-cycles.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [PASS][10] -> [DMESG-WARN][11] ([i915#180]) +5 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/shard-kbl6/igt@kms_cursor_...@pipe-c-cursor-suspend.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18559/shard-kbl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - shard-skl: [PASS][12] -> [DMESG-WARN][13] ([i915#1982]) +3 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/shard-skl6/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18559/shard-skl8/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_flip@2x-flip-vs-blocking-wf-vblank@ab-vga1-hdmi-a1: - shard-hsw: [PASS][14] -> [DMESG-WARN][15] ([i915#1982]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/shard-hsw1/igt@kms_flip@2x-flip-vs-blocking-wf-vbl...@ab-vga1-hdmi-a1.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18559/shard-hsw6/igt@kms_flip@2x-flip-vs-blocking-wf-vbl...@ab-vga1-hdmi-a1.html * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-cpu: - shard-skl: [PASS][16] -> [FAIL][17] ([i915#49]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/shard-skl3/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-indfb-draw-mmap-cpu.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18559/shard-skl2/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-indfb-draw-mmap-cpu.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-render: - shard-tglb: [PASS][18] -> [DMESG-WARN][19] ([i915#1982]) +6 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/shard-tglb7/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-shrfb-draw-render.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18559/shard-tglb8/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-shrfb-draw-render.html * igt@kms_hdr@bpc-switch: - shard-skl: [PASS][20] -> [FAIL][21] ([i915#1188]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/shard-skl1/igt@kms_...@bpc-switch.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18559/shard-skl4/igt@kms_...@bpc-switch.html * igt@kms_plane_alpha_blend@pipe-a-constant-a
Re: [Intel-gfx] [PATCH 14/14] drm/i915: Sort EHL/JSL PCI IDs
> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Thursday, July 16, 2020 10:21 AM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH 14/14] drm/i915: Sort EHL/JSL PCI IDs > > From: Ville Syrjälä > > Sort the EHL/JSL PCI IDs numerically. Some order seems better than > randomness. > > Cc: Alexei Podtelezhnikov > Signed-off-by: Ville Syrjälä Reviewed-by: Anusha Srivatsa > --- > include/drm/i915_pciids.h | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index > 45da1b45c01e..880ffe8571e8 100644 > --- a/include/drm/i915_pciids.h > +++ b/include/drm/i915_pciids.h > @@ -585,16 +585,16 @@ > /* EHL/JSL */ > #define INTEL_EHL_IDS(info) \ > INTEL_VGA_DEVICE(0x4500, info), \ > - INTEL_VGA_DEVICE(0x4571, info), \ > - INTEL_VGA_DEVICE(0x4551, info), \ > INTEL_VGA_DEVICE(0x4541, info), \ > - INTEL_VGA_DEVICE(0x4E71, info), \ > - INTEL_VGA_DEVICE(0x4557, info), \ > + INTEL_VGA_DEVICE(0x4551, info), \ > INTEL_VGA_DEVICE(0x4555, info), \ > - INTEL_VGA_DEVICE(0x4E61, info), \ > - INTEL_VGA_DEVICE(0x4E57, info), \ > + INTEL_VGA_DEVICE(0x4557, info), \ > + INTEL_VGA_DEVICE(0x4571, info), \ > + INTEL_VGA_DEVICE(0x4E51, info), \ > INTEL_VGA_DEVICE(0x4E55, info), \ > - INTEL_VGA_DEVICE(0x4E51, info) > + INTEL_VGA_DEVICE(0x4E57, info), \ > + INTEL_VGA_DEVICE(0x4E61, info), \ > + INTEL_VGA_DEVICE(0x4E71, info) > > /* TGL */ > #define INTEL_TGL_12_IDS(info) \ > -- > 2.26.2 > > ___ > 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 13/14] drm/i915: Sort ICL PCI IDs
> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Thursday, July 16, 2020 10:21 AM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH 13/14] drm/i915: Sort ICL PCI IDs > > From: Ville Syrjälä > > Sort the ICL PCI IDs numerically. Some order seems better than randomness. > > Cc: Alexei Podtelezhnikov > Signed-off-by: Ville Syrjälä Reviewed-by: Anusha Srivatsa > --- > include/drm/i915_pciids.h | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index > 33a72e6eadd8..45da1b45c01e 100644 > --- a/include/drm/i915_pciids.h > +++ b/include/drm/i915_pciids.h > @@ -564,18 +564,18 @@ > /* ICL */ > #define INTEL_ICL_PORT_F_IDS(info) \ > INTEL_VGA_DEVICE(0x8A50, info), \ > - INTEL_VGA_DEVICE(0x8A5C, info), \ > - INTEL_VGA_DEVICE(0x8A59, info), \ > - INTEL_VGA_DEVICE(0x8A58, info), \ > INTEL_VGA_DEVICE(0x8A52, info), \ > + INTEL_VGA_DEVICE(0x8A53, info), \ > + INTEL_VGA_DEVICE(0x8A54, info), \ > + INTEL_VGA_DEVICE(0x8A56, info), \ > + INTEL_VGA_DEVICE(0x8A57, info), \ > + INTEL_VGA_DEVICE(0x8A58, info), \ > + INTEL_VGA_DEVICE(0x8A59, info), \ > INTEL_VGA_DEVICE(0x8A5A, info), \ > INTEL_VGA_DEVICE(0x8A5B, info), \ > - INTEL_VGA_DEVICE(0x8A57, info), \ > - INTEL_VGA_DEVICE(0x8A56, info), \ > - INTEL_VGA_DEVICE(0x8A71, info), \ > + INTEL_VGA_DEVICE(0x8A5C, info), \ > INTEL_VGA_DEVICE(0x8A70, info), \ > - INTEL_VGA_DEVICE(0x8A53, info), \ > - INTEL_VGA_DEVICE(0x8A54, info) > + INTEL_VGA_DEVICE(0x8A71, info) > > #define INTEL_ICL_11_IDS(info) \ > INTEL_ICL_PORT_F_IDS(info), \ > -- > 2.26.2 > > ___ > 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 12/14] drm/i915: Sort CNL PCI IDs
> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Thursday, July 16, 2020 10:21 AM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH 12/14] drm/i915: Sort CNL PCI IDs > > From: Ville Syrjälä > > Sort the CNL PCI IDs numerically. Some order seems better than > randomness. > > Cc: Alexei Podtelezhnikov > Signed-off-by: Ville Syrjälä Reviewed-by: Anusha Srivatsa > --- > include/drm/i915_pciids.h | 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index > c48c2b76aa7d..33a72e6eadd8 100644 > --- a/include/drm/i915_pciids.h > +++ b/include/drm/i915_pciids.h > @@ -543,23 +543,23 @@ > > /* CNL */ > #define INTEL_CNL_PORT_F_IDS(info) \ > - INTEL_VGA_DEVICE(0x5A54, info), \ > - INTEL_VGA_DEVICE(0x5A5C, info), \ > INTEL_VGA_DEVICE(0x5A44, info), \ > - INTEL_VGA_DEVICE(0x5A4C, info) > + INTEL_VGA_DEVICE(0x5A4C, info), \ > + INTEL_VGA_DEVICE(0x5A54, info), \ > + INTEL_VGA_DEVICE(0x5A5C, info) > > #define INTEL_CNL_IDS(info) \ > INTEL_CNL_PORT_F_IDS(info), \ > - INTEL_VGA_DEVICE(0x5A51, info), \ > - INTEL_VGA_DEVICE(0x5A59, info), \ > + INTEL_VGA_DEVICE(0x5A40, info), \ > INTEL_VGA_DEVICE(0x5A41, info), \ > - INTEL_VGA_DEVICE(0x5A49, info), \ > - INTEL_VGA_DEVICE(0x5A52, info), \ > - INTEL_VGA_DEVICE(0x5A5A, info), \ > INTEL_VGA_DEVICE(0x5A42, info), \ > + INTEL_VGA_DEVICE(0x5A49, info), \ > INTEL_VGA_DEVICE(0x5A4A, info), \ > INTEL_VGA_DEVICE(0x5A50, info), \ > - INTEL_VGA_DEVICE(0x5A40, info) > + INTEL_VGA_DEVICE(0x5A51, info), \ > + INTEL_VGA_DEVICE(0x5A52, info), \ > + INTEL_VGA_DEVICE(0x5A59, info), \ > + INTEL_VGA_DEVICE(0x5A5A, info) > > /* ICL */ > #define INTEL_ICL_PORT_F_IDS(info) \ > -- > 2.26.2 > > ___ > 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 11/14] drm/i915: Sort CFL PCI IDs
> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Thursday, July 16, 2020 10:21 AM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH 11/14] drm/i915: Sort CFL PCI IDs > > From: Ville Syrjälä > > Sort the CFL PCI IDs numerically. Some order seems better than > randomness. > > Cc: Alexei Podtelezhnikov > Signed-off-by: Ville Syrjälä Reviewed-by: Anusha Srivatsa > --- > include/drm/i915_pciids.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index > 2d36cbce0ac0..c48c2b76aa7d 100644 > --- a/include/drm/i915_pciids.h > +++ b/include/drm/i915_pciids.h > @@ -497,8 +497,8 @@ > INTEL_VGA_DEVICE(0x3E9C, info) > > #define INTEL_CFL_H_GT2_IDS(info) \ > - INTEL_VGA_DEVICE(0x3E9B, info), /* Halo GT2 */ \ > - INTEL_VGA_DEVICE(0x3E94, info) /* Halo GT2 */ > + INTEL_VGA_DEVICE(0x3E94, info), /* Halo GT2 */ \ > + INTEL_VGA_DEVICE(0x3E9B, info) /* Halo GT2 */ > > /* CFL U GT2 */ > #define INTEL_CFL_U_GT2_IDS(info) \ > -- > 2.26.2 > > ___ > 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 10/14] drm/i915: Sort CML PCI IDs
> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Thursday, July 16, 2020 10:21 AM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH 10/14] drm/i915: Sort CML PCI IDs > > From: Ville Syrjälä > > Sort the CML PCI IDs numerically. Some order seems better than > randomness. > > Cc: Alexei Podtelezhnikov > Signed-off-by: Ville Syrjälä Reviewed-by: Anusha Srivatsa > --- > include/drm/i915_pciids.h | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index > db409171d9c3..2d36cbce0ac0 100644 > --- a/include/drm/i915_pciids.h > +++ b/include/drm/i915_pciids.h > @@ -447,10 +447,10 @@ > > /* CML GT1 */ > #define INTEL_CML_GT1_IDS(info) \ > - INTEL_VGA_DEVICE(0x9BA5, info), \ > - INTEL_VGA_DEVICE(0x9BA8, info), \ > + INTEL_VGA_DEVICE(0x9BA2, info), \ > INTEL_VGA_DEVICE(0x9BA4, info), \ > - INTEL_VGA_DEVICE(0x9BA2, info) > + INTEL_VGA_DEVICE(0x9BA5, info), \ > + INTEL_VGA_DEVICE(0x9BA8, info) > > #define INTEL_CML_U_GT1_IDS(info) \ > INTEL_VGA_DEVICE(0x9B21, info), \ > @@ -459,11 +459,11 @@ > > /* CML GT2 */ > #define INTEL_CML_GT2_IDS(info) \ > - INTEL_VGA_DEVICE(0x9BC5, info), \ > - INTEL_VGA_DEVICE(0x9BC8, info), \ > - INTEL_VGA_DEVICE(0x9BC4, info), \ > INTEL_VGA_DEVICE(0x9BC2, info), \ > + INTEL_VGA_DEVICE(0x9BC4, info), \ > + INTEL_VGA_DEVICE(0x9BC5, info), \ > INTEL_VGA_DEVICE(0x9BC6, info), \ > + INTEL_VGA_DEVICE(0x9BC8, info), \ > INTEL_VGA_DEVICE(0x9BE6, info), \ > INTEL_VGA_DEVICE(0x9BF6, info) > > -- > 2.26.2 > > ___ > 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 09/14] drm/i915: Sort KBL PCI IDs
> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Thursday, July 16, 2020 10:21 AM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH 09/14] drm/i915: Sort KBL PCI IDs > > From: Ville Syrjälä > > Sort the KBL PCI IDs numerically. Some order seems better than > randomness. > > Cc: Alexei Podtelezhnikov > Signed-off-by: Ville Syrjälä Reviewed-by: Anusha Srivatsa > --- > include/drm/i915_pciids.h | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index > 5185ac789038..db409171d9c3 100644 > --- a/include/drm/i915_pciids.h > +++ b/include/drm/i915_pciids.h > @@ -406,8 +406,8 @@ > INTEL_KBL_ULX_GT1_IDS(info), \ > INTEL_VGA_DEVICE(0x5902, info), /* DT GT1 */ \ > INTEL_VGA_DEVICE(0x5908, info), /* Halo GT1 */ \ > - INTEL_VGA_DEVICE(0x590B, info), /* Halo GT1 */ \ > - INTEL_VGA_DEVICE(0x590A, info) /* SRV GT1 */ > + INTEL_VGA_DEVICE(0x590A, info), /* SRV GT1 */ \ > + INTEL_VGA_DEVICE(0x590B, info) /* Halo GT1 */ > > #define INTEL_KBL_ULT_GT2_IDS(info) \ > INTEL_VGA_DEVICE(0x5916, info), /* ULT GT2 */ \ @@ -419,10 > +419,10 @@ > #define INTEL_KBL_GT2_IDS(info) \ > INTEL_KBL_ULT_GT2_IDS(info), \ > INTEL_KBL_ULX_GT2_IDS(info), \ > - INTEL_VGA_DEVICE(0x5917, info), /* Mobile GT2 */ \ > INTEL_VGA_DEVICE(0x5912, info), /* DT GT2 */ \ > - INTEL_VGA_DEVICE(0x591B, info), /* Halo GT2 */ \ > + INTEL_VGA_DEVICE(0x5917, info), /* Mobile GT2 */ \ > INTEL_VGA_DEVICE(0x591A, info), /* SRV GT2 */ \ > + INTEL_VGA_DEVICE(0x591B, info), /* Halo GT2 */ \ > INTEL_VGA_DEVICE(0x591D, info) /* WKS GT2 */ > > #define INTEL_KBL_ULT_GT3_IDS(info) \ > -- > 2.26.2 > > ___ > 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 08/14] drm/i915: Sort SKL PCI IDs
> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Thursday, July 16, 2020 10:21 AM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH 08/14] drm/i915: Sort SKL PCI IDs > > From: Ville Syrjälä > > Sort the SKL PCI IDs numerically. Some order seems better than > randomness. There are 2 patches - patch 2 and 3 in the series that are reclassifying some PCI IDs and there is patch 4 that adds a missing ID. All of those with this patch can be combined to a single patch OR patch 2, 3 and 4 can be squashed as one solitary patch. Anusha > Cc: Alexei Podtelezhnikov > Signed-off-by: Ville Syrjälä > --- > include/drm/i915_pciids.h | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index > 4870c3c9f9b2..5185ac789038 100644 > --- a/include/drm/i915_pciids.h > +++ b/include/drm/i915_pciids.h > @@ -340,8 +340,8 @@ > INTEL_SKL_ULT_GT1_IDS(info), \ > INTEL_SKL_ULX_GT1_IDS(info), \ > INTEL_VGA_DEVICE(0x1902, info), /* DT GT1 */ \ > - INTEL_VGA_DEVICE(0x190B, info), /* Halo GT1 */ \ > INTEL_VGA_DEVICE(0x190A, info), /* SRV GT1 */ \ > + INTEL_VGA_DEVICE(0x190B, info), /* Halo GT1 */ \ > INTEL_VGA_DEVICE(0x1917, info) /* DT GT1.5 */ > > #define INTEL_SKL_ULT_GT2_IDS(info) \ > @@ -355,8 +355,8 @@ > INTEL_SKL_ULT_GT2_IDS(info), \ > INTEL_SKL_ULX_GT2_IDS(info), \ > INTEL_VGA_DEVICE(0x1912, info), /* DT GT2 */ \ > - INTEL_VGA_DEVICE(0x191B, info), /* Halo GT2 */ \ > INTEL_VGA_DEVICE(0x191A, info), /* SRV GT2 */ \ > + INTEL_VGA_DEVICE(0x191B, info), /* Halo GT2 */ \ > INTEL_VGA_DEVICE(0x191D, info) /* WKS GT2 */ > > #define INTEL_SKL_ULT_GT3_IDS(info) \ > @@ -372,9 +372,9 @@ > > #define INTEL_SKL_GT4_IDS(info) \ > INTEL_VGA_DEVICE(0x1932, info), /* DT GT4 */ \ > + INTEL_VGA_DEVICE(0x193A, info), /* SRV GT4e */ \ > INTEL_VGA_DEVICE(0x193B, info), /* Halo GT4e */ \ > - INTEL_VGA_DEVICE(0x193D, info), /* WKS GT4e */ \ > - INTEL_VGA_DEVICE(0x193A, info) /* SRV GT4e */ > + INTEL_VGA_DEVICE(0x193D, info) /* WKS GT4e */ > > #define INTEL_SKL_IDS(info) \ > INTEL_SKL_GT1_IDS(info), \ > -- > 2.26.2 > > ___ > 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 07/14] drm/i915: Sort HSW PCI IDs
> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Thursday, July 16, 2020 10:21 AM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH 07/14] drm/i915: Sort HSW PCI IDs > > From: Ville Syrjälä > > Sort the HSW PCI IDs numerically. Some order seems better than > randomness. I think the sorting, OCD-ness with hex and reclassifying can be combined in one patch. Anusha > Cc: Alexei Podtelezhnikov > Signed-off-by: Ville Syrjälä > --- > include/drm/i915_pciids.h | 34 +- > 1 file changed, 17 insertions(+), 17 deletions(-) > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index > 026db4d496e9..4870c3c9f9b2 100644 > --- a/include/drm/i915_pciids.h > +++ b/include/drm/i915_pciids.h > @@ -170,9 +170,9 @@ > > #define INTEL_HSW_ULT_GT1_IDS(info) \ > INTEL_VGA_DEVICE(0x0A02, info), /* ULT GT1 desktop */ \ > + INTEL_VGA_DEVICE(0x0A06, info), /* ULT GT1 mobile */ \ > INTEL_VGA_DEVICE(0x0A0A, info), /* ULT GT1 server */ \ > - INTEL_VGA_DEVICE(0x0A0B, info), /* ULT GT1 reserved */ \ > - INTEL_VGA_DEVICE(0x0A06, info) /* ULT GT1 mobile */ > + INTEL_VGA_DEVICE(0x0A0B, info) /* ULT GT1 reserved */ > > #define INTEL_HSW_ULX_GT1_IDS(info) \ > INTEL_VGA_DEVICE(0x0A0E, info) /* ULX GT1 mobile */ @@ -181,26 > +181,26 @@ > INTEL_HSW_ULT_GT1_IDS(info), \ > INTEL_HSW_ULX_GT1_IDS(info), \ > INTEL_VGA_DEVICE(0x0402, info), /* GT1 desktop */ \ > + INTEL_VGA_DEVICE(0x0406, info), /* GT1 mobile */ \ > INTEL_VGA_DEVICE(0x040A, info), /* GT1 server */ \ > INTEL_VGA_DEVICE(0x040B, info), /* GT1 reserved */ \ > INTEL_VGA_DEVICE(0x040E, info), /* GT1 reserved */ \ > INTEL_VGA_DEVICE(0x0C02, info), /* SDV GT1 desktop */ \ > + INTEL_VGA_DEVICE(0x0C06, info), /* SDV GT1 mobile */ \ > INTEL_VGA_DEVICE(0x0C0A, info), /* SDV GT1 server */ \ > INTEL_VGA_DEVICE(0x0C0B, info), /* SDV GT1 reserved */ \ > INTEL_VGA_DEVICE(0x0C0E, info), /* SDV GT1 reserved */ \ > INTEL_VGA_DEVICE(0x0D02, info), /* CRW GT1 desktop */ \ > + INTEL_VGA_DEVICE(0x0D06, info), /* CRW GT1 mobile */\ > INTEL_VGA_DEVICE(0x0D0A, info), /* CRW GT1 server */ \ > INTEL_VGA_DEVICE(0x0D0B, info), /* CRW GT1 reserved */ \ > - INTEL_VGA_DEVICE(0x0D0E, info), /* CRW GT1 reserved */ \ > - INTEL_VGA_DEVICE(0x0406, info), /* GT1 mobile */ \ > - INTEL_VGA_DEVICE(0x0C06, info), /* SDV GT1 mobile */ \ > - INTEL_VGA_DEVICE(0x0D06, info) /* CRW GT1 mobile */ > + INTEL_VGA_DEVICE(0x0D0E, info) /* CRW GT1 reserved */ > > #define INTEL_HSW_ULT_GT2_IDS(info) \ > INTEL_VGA_DEVICE(0x0A12, info), /* ULT GT2 desktop */ \ > + INTEL_VGA_DEVICE(0x0A16, info), /* ULT GT2 mobile */\ > INTEL_VGA_DEVICE(0x0A1A, info), /* ULT GT2 server */ \ > - INTEL_VGA_DEVICE(0x0A1B, info), /* ULT GT2 reserved */ \ > - INTEL_VGA_DEVICE(0x0A16, info) /* ULT GT2 mobile */ > + INTEL_VGA_DEVICE(0x0A1B, info) /* ULT GT2 reserved */ \ > > #define INTEL_HSW_ULX_GT2_IDS(info) \ > INTEL_VGA_DEVICE(0x0A1E, info) /* ULX GT2 mobile */ \ @@ - > 209,45 +209,45 @@ > INTEL_HSW_ULT_GT2_IDS(info), \ > INTEL_HSW_ULX_GT2_IDS(info), \ > INTEL_VGA_DEVICE(0x0412, info), /* GT2 desktop */ \ > + INTEL_VGA_DEVICE(0x0416, info), /* GT2 mobile */ \ > INTEL_VGA_DEVICE(0x041A, info), /* GT2 server */ \ > INTEL_VGA_DEVICE(0x041B, info), /* GT2 reserved */ \ > INTEL_VGA_DEVICE(0x041E, info), /* GT2 reserved */ \ > INTEL_VGA_DEVICE(0x0C12, info), /* SDV GT2 desktop */ \ > + INTEL_VGA_DEVICE(0x0C16, info), /* SDV GT2 mobile */ \ > INTEL_VGA_DEVICE(0x0C1A, info), /* SDV GT2 server */ \ > INTEL_VGA_DEVICE(0x0C1B, info), /* SDV GT2 reserved */ \ > INTEL_VGA_DEVICE(0x0C1E, info), /* SDV GT2 reserved */ \ > INTEL_VGA_DEVICE(0x0D12, info), /* CRW GT2 desktop */ \ > + INTEL_VGA_DEVICE(0x0D16, info), /* CRW GT2 mobile */ \ > INTEL_VGA_DEVICE(0x0D1A, info), /* CRW GT2 server */ \ > INTEL_VGA_DEVICE(0x0D1B, info), /* CRW GT2 reserved */ \ > - INTEL_VGA_DEVICE(0x0D1E, info), /* CRW GT2 reserved */ \ > - INTEL_VGA_DEVICE(0x0416, info), /* GT2 mobile */ \ > - INTEL_VGA_DEVICE(0x0C16, info), /* SDV GT2 mobile */ \ > - INTEL_VGA_DEVICE(0x0D16, info) /* CRW GT2 mobile */ > + INTEL_VGA_DEVICE(0x0D1E, info) /* CRW GT2 reserved */ > > #define INTEL_HSW_ULT_GT3_IDS(info) \ > INTEL_VGA_DEVICE(0x0A22, info), /* ULT GT3 desktop */ \ > + INTEL_VGA_DEVICE(0x0A26, info), /* ULT GT3 mobile */ \ > INTEL_VGA_DEVICE(0x0A2A, info), /* ULT GT3 server */ \ > INTEL_VGA_DEVICE(0x0A2B, info), /* ULT GT3 reserved */ \ > - INTEL_VGA_DEVICE(0x0A26, info), /* ULT GT3 mobile */ \ > INTEL_VGA_DEVICE(0x0A2E, info) /* ULT GT3 reserved */ > > #define INTEL_HSW_GT3_IDS(info) \ > INTEL_HSW_ULT_GT3_IDS(info), \ > INTEL_VGA_DEVICE(0x0422, i
Re: [Intel-gfx] [PATCH 06/14] drm/i915: Ocd the HSW PCI ID hex numbers
> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Thursday, July 16, 2020 10:21 AM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH 06/14] drm/i915: Ocd the HSW PCI ID hex > numbers > > From: Ville Syrjälä > > Most of the HSW PCI IDs are upper case hex numbers, but a few are lower > case. Make it consistent so these don't stick out like a sore thumb. > > Cc: Alexei Podtelezhnikov > Signed-off-by: Ville Syrjälä Reviewed-by: Anusha Srivatsa > --- > include/drm/i915_pciids.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index > 3792ab5f20ff..026db4d496e9 100644 > --- a/include/drm/i915_pciids.h > +++ b/include/drm/i915_pciids.h > @@ -181,7 +181,7 @@ > INTEL_HSW_ULT_GT1_IDS(info), \ > INTEL_HSW_ULX_GT1_IDS(info), \ > INTEL_VGA_DEVICE(0x0402, info), /* GT1 desktop */ \ > - INTEL_VGA_DEVICE(0x040a, info), /* GT1 server */ \ > + INTEL_VGA_DEVICE(0x040A, info), /* GT1 server */ \ > INTEL_VGA_DEVICE(0x040B, info), /* GT1 reserved */ \ > INTEL_VGA_DEVICE(0x040E, info), /* GT1 reserved */ \ > INTEL_VGA_DEVICE(0x0C02, info), /* SDV GT1 desktop */ \ @@ - > 209,7 +209,7 @@ > INTEL_HSW_ULT_GT2_IDS(info), \ > INTEL_HSW_ULX_GT2_IDS(info), \ > INTEL_VGA_DEVICE(0x0412, info), /* GT2 desktop */ \ > - INTEL_VGA_DEVICE(0x041a, info), /* GT2 server */ \ > + INTEL_VGA_DEVICE(0x041A, info), /* GT2 server */ \ > INTEL_VGA_DEVICE(0x041B, info), /* GT2 reserved */ \ > INTEL_VGA_DEVICE(0x041E, info), /* GT2 reserved */ \ > INTEL_VGA_DEVICE(0x0C12, info), /* SDV GT2 desktop */ \ @@ - > 234,7 +234,7 @@ #define INTEL_HSW_GT3_IDS(info) \ > INTEL_HSW_ULT_GT3_IDS(info), \ > INTEL_VGA_DEVICE(0x0422, info), /* GT3 desktop */ \ > - INTEL_VGA_DEVICE(0x042a, info), /* GT3 server */ \ > + INTEL_VGA_DEVICE(0x042A, info), /* GT3 server */ \ > INTEL_VGA_DEVICE(0x042B, info), /* GT3 reserved */ \ > INTEL_VGA_DEVICE(0x042E, info), /* GT3 reserved */ \ > INTEL_VGA_DEVICE(0x0C22, info), /* SDV GT3 desktop */ \ > -- > 2.26.2 > > ___ > 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 05/14] drm/i915: Try to fix the SKL GT3/4 vs. GT3e/4e comments
> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Thursday, July 16, 2020 10:21 AM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH 05/14] drm/i915: Try to fix the SKL GT3/4 vs. > GT3e/4e comments > > From: Ville Syrjälä > > Bunch of the SKL SKUs currently documented as GT3/4 seem to actually be > GT3e/4e. Fix up the comments. > > Cc: Alexei Podtelezhnikov > Signed-off-by: Ville Syrjälä Reviewed-by: Anusha Srivatsa > --- > include/drm/i915_pciids.h | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index > c906088ccffe..3792ab5f20ff 100644 > --- a/include/drm/i915_pciids.h > +++ b/include/drm/i915_pciids.h > @@ -361,19 +361,19 @@ > > #define INTEL_SKL_ULT_GT3_IDS(info) \ > INTEL_VGA_DEVICE(0x1923, info), /* ULT GT3 */ \ > - INTEL_VGA_DEVICE(0x1926, info), /* ULT GT3 */ \ > - INTEL_VGA_DEVICE(0x1927, info) /* ULT GT3 */ > + INTEL_VGA_DEVICE(0x1926, info), /* ULT GT3e */ \ > + INTEL_VGA_DEVICE(0x1927, info) /* ULT GT3e */ > > #define INTEL_SKL_GT3_IDS(info) \ > INTEL_SKL_ULT_GT3_IDS(info), \ > INTEL_VGA_DEVICE(0x192A, info), /* SRV GT3 */ \ > - INTEL_VGA_DEVICE(0x192B, info), /* Halo GT3 */ \ > - INTEL_VGA_DEVICE(0x192D, info) /* SRV GT3 */ > + INTEL_VGA_DEVICE(0x192B, info), /* Halo GT3e */ \ > + INTEL_VGA_DEVICE(0x192D, info) /* SRV GT3e */ > > #define INTEL_SKL_GT4_IDS(info) \ > INTEL_VGA_DEVICE(0x1932, info), /* DT GT4 */ \ > - INTEL_VGA_DEVICE(0x193B, info), /* Halo GT4 */ \ > - INTEL_VGA_DEVICE(0x193D, info), /* WKS GT4 */ \ > + INTEL_VGA_DEVICE(0x193B, info), /* Halo GT4e */ \ > + INTEL_VGA_DEVICE(0x193D, info), /* WKS GT4e */ \ > INTEL_VGA_DEVICE(0x193A, info) /* SRV GT4e */ > > #define INTEL_SKL_IDS(info) \ > -- > 2.26.2 > > ___ > 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 04/14] drm/i915: Add SKL GT1.5 PCI IDs
> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Thursday, July 16, 2020 10:21 AM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH 04/14] drm/i915: Add SKL GT1.5 PCI IDs > > From: Alexei Podtelezhnikov > > Add three new devices 0x1913, 0x1915, and 0x1917 also known as > iSKLULTGT15, iSKLULXGT15, and iSKLDTGT15. > > Signed-off-by: Alexei Podtelezhnikov > [vsyrjala: Split separate changes into separate patchs, >Sort the IDs] The above comment appears in every patch. If this is v2 of the patches then it goes right after the commit message as: V2: Split separate changes into separate patches, sort the IDs (Ville) > Signed-off-by: Ville Syrjälä The code changes itself look good. Reviewed-by: Anusha Srivatsa > --- > include/drm/i915_pciids.h | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index > 9df3697f074d..c906088ccffe 100644 > --- a/include/drm/i915_pciids.h > +++ b/include/drm/i915_pciids.h > @@ -329,17 +329,20 @@ > INTEL_VGA_DEVICE(0x22b3, info) > > #define INTEL_SKL_ULT_GT1_IDS(info) \ > - INTEL_VGA_DEVICE(0x1906, info) /* ULT GT1 */ > + INTEL_VGA_DEVICE(0x1906, info), /* ULT GT1 */ \ > + INTEL_VGA_DEVICE(0x1913, info) /* ULT GT1.5 */ > > #define INTEL_SKL_ULX_GT1_IDS(info) \ > - INTEL_VGA_DEVICE(0x190E, info) /* ULX GT1 */ > + INTEL_VGA_DEVICE(0x190E, info), /* ULX GT1 */ \ > + INTEL_VGA_DEVICE(0x1915, info) /* ULX GT1.5 */ > > #define INTEL_SKL_GT1_IDS(info) \ > INTEL_SKL_ULT_GT1_IDS(info), \ > INTEL_SKL_ULX_GT1_IDS(info), \ > INTEL_VGA_DEVICE(0x1902, info), /* DT GT1 */ \ > INTEL_VGA_DEVICE(0x190B, info), /* Halo GT1 */ \ > - INTEL_VGA_DEVICE(0x190A, info) /* SRV GT1 */ > + INTEL_VGA_DEVICE(0x190A, info), /* SRV GT1 */ \ > + INTEL_VGA_DEVICE(0x1917, info) /* DT GT1.5 */ > > #define INTEL_SKL_ULT_GT2_IDS(info) \ > INTEL_VGA_DEVICE(0x1916, info), /* ULT GT2 */ \ > -- > 2.26.2 > > ___ > 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 03/14] drm/i915: Reclassify SKL 0x1923 and 0x1927 as ULT
> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Thursday, July 16, 2020 10:21 AM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH 03/14] drm/i915: Reclassify SKL 0x1923 and > 0x1927 as ULT > > From: Alexei Podtelezhnikov > > Reclassify 0x1923, 0x1927 according to specifications. Of note, the second to > last digit seems to correspond to GT#. IMO we don’t need to specify the above. > Signed-off-by: Alexei Podtelezhnikov > [vsyrjala: Split separate changes into separate patches, >Sort the IDs] > Signed-off-by: Ville Syrjälä Reviewed-by: Anusha Srivatsa > --- > include/drm/i915_pciids.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index > d4c054e3b95f..9df3697f074d 100644 > --- a/include/drm/i915_pciids.h > +++ b/include/drm/i915_pciids.h > @@ -357,12 +357,12 @@ > INTEL_VGA_DEVICE(0x191D, info) /* WKS GT2 */ > > #define INTEL_SKL_ULT_GT3_IDS(info) \ > - INTEL_VGA_DEVICE(0x1926, info) /* ULT GT3 */ > + INTEL_VGA_DEVICE(0x1923, info), /* ULT GT3 */ \ > + INTEL_VGA_DEVICE(0x1926, info), /* ULT GT3 */ \ > + INTEL_VGA_DEVICE(0x1927, info) /* ULT GT3 */ > > #define INTEL_SKL_GT3_IDS(info) \ > INTEL_SKL_ULT_GT3_IDS(info), \ > - INTEL_VGA_DEVICE(0x1923, info), /* ULT GT3 */ \ > - INTEL_VGA_DEVICE(0x1927, info), /* ULT GT3 */ \ > INTEL_VGA_DEVICE(0x192A, info), /* SRV GT3 */ \ > INTEL_VGA_DEVICE(0x192B, info), /* Halo GT3 */ \ > INTEL_VGA_DEVICE(0x192D, info) /* SRV GT3 */ > -- > 2.26.2 > > ___ > 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/14] drm/i915: Update Haswell PCI IDs
> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Thursday, July 16, 2020 10:21 AM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH 01/14] drm/i915: Update Haswell PCI IDs > > From: Alexei Podtelezhnikov > > Reclassify 0x0426 as GT3 (GT2+) according to specifications and the second > least significant digit. > > Signed-off-by: Alexei Podtelezhnikov > [vsyrjala: s/GT2/GT3/ in the comment] > Signed-off-by: Ville Syrjälä Reviewed-by: Anusha Srivatsa > --- > include/drm/i915_pciids.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index > 8e7ae30ebcbb..51831c6f603c 100644 > --- a/include/drm/i915_pciids.h > +++ b/include/drm/i915_pciids.h > @@ -221,7 +221,6 @@ > INTEL_VGA_DEVICE(0x0D1B, info), /* CRW GT2 reserved */ \ > INTEL_VGA_DEVICE(0x0D1E, info), /* CRW GT2 reserved */ \ > INTEL_VGA_DEVICE(0x0416, info), /* GT2 mobile */ \ > - INTEL_VGA_DEVICE(0x0426, info), /* GT2 mobile */ \ > INTEL_VGA_DEVICE(0x0C16, info), /* SDV GT2 mobile */ \ > INTEL_VGA_DEVICE(0x0D16, info) /* CRW GT2 mobile */ > > @@ -246,6 +245,7 @@ > INTEL_VGA_DEVICE(0x0D2A, info), /* CRW GT3 server */ \ > INTEL_VGA_DEVICE(0x0D2B, info), /* CRW GT3 reserved */ \ > INTEL_VGA_DEVICE(0x0D2E, info), /* CRW GT3 reserved */ \ > + INTEL_VGA_DEVICE(0x0426, info), /* GT3 mobile */ \ > INTEL_VGA_DEVICE(0x0C26, info), /* SDV GT3 mobile */ \ > INTEL_VGA_DEVICE(0x0D26, info) /* CRW GT3 mobile */ > > -- > 2.26.2 > > ___ > 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 v6 05/11] drm/i915: Try to make bigjoiner work in atomic check
On Thu, Sep 03, 2020 at 09:38:31PM +0300, Ville Syrjälä wrote:
> On Wed, Jul 15, 2020 at 03:42:16PM -0700, Manasi Navare wrote:
> > From: Maarten Lankhorst
> >
> > When the clock is higher than the dotclock, try with 2 pipes enabled.
> > If we can enable 2, then we will go into big joiner mode, and steal
> > the adjacent crtc.
> >
> > This only links the crtc's in software, no hardware or plane
> > programming is done yet. Blobs are also copied from the master's
> > crtc_state, so it doesn't depend at commit time on the other
> > crtc_state.
> >
> > v3:
> > * Manual Rebase (Manasi)
> > Changes since v1:
> > - Rename pipe timings to transcoder timings, as they are now different.
> > Changes since v2:
> > - Rework bigjoiner checks; always disable slave when recalculating
> >master. No need to have a separate bigjoiner pass any more.
> > - Use pipe_mode instead of transcoder_mode, to clean up the code.
> >
> > Signed-off-by: Maarten Lankhorst
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/i915/display/intel_atomic.c | 9 +-
> > drivers/gpu/drm/i915/display/intel_atomic.h | 3 +-
> > drivers/gpu/drm/i915/display/intel_display.c | 201 --
> > .../drm/i915/display/intel_display_types.h| 9 +
> > drivers/gpu/drm/i915/display/intel_dp.c | 22 +-
> > 5 files changed, 211 insertions(+), 33 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> > b/drivers/gpu/drm/i915/display/intel_atomic.c
> > index 630f49b7aa01..b9dcdc74a10d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> > @@ -270,14 +270,15 @@ void intel_crtc_free_hw_state(struct intel_crtc_state
> > *crtc_state)
> > intel_crtc_put_color_blobs(crtc_state);
> > }
> >
> > -void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state)
> > +void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state,
> > +const struct intel_crtc_state *from_crtc_state)
> > {
> > drm_property_replace_blob(&crtc_state->hw.degamma_lut,
> > - crtc_state->uapi.degamma_lut);
> > + from_crtc_state->uapi.degamma_lut);
> > drm_property_replace_blob(&crtc_state->hw.gamma_lut,
> > - crtc_state->uapi.gamma_lut);
> > + from_crtc_state->uapi.gamma_lut);
> > drm_property_replace_blob(&crtc_state->hw.ctm,
> > - crtc_state->uapi.ctm);
> > + from_crtc_state->uapi.ctm);
> > }
> >
> > /**
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.h
> > b/drivers/gpu/drm/i915/display/intel_atomic.h
> > index 11146292b06f..fc556c032c8f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic.h
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic.h
> > @@ -43,7 +43,8 @@ struct drm_crtc_state *intel_crtc_duplicate_state(struct
> > drm_crtc *crtc);
> > void intel_crtc_destroy_state(struct drm_crtc *crtc,
> >struct drm_crtc_state *state);
> > void intel_crtc_free_hw_state(struct intel_crtc_state *crtc_state);
> > -void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state);
> > +void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state,
> > +const struct intel_crtc_state
> > *from_crtc_state);
> > struct drm_atomic_state *intel_atomic_state_alloc(struct drm_device *dev);
> > void intel_atomic_state_free(struct drm_atomic_state *state);
> > void intel_atomic_state_clear(struct drm_atomic_state *state);
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 3ecb642805a6..955e19abb563 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -8016,9 +8016,24 @@ static int intel_crtc_compute_config(struct
> > intel_crtc *crtc,
> > struct intel_crtc_state *pipe_config)
> > {
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > - const struct drm_display_mode *pipe_mode = &pipe_config->hw.pipe_mode;
> > + struct drm_display_mode *pipe_mode = &pipe_config->hw.pipe_mode;
> > int clock_limit = dev_priv->max_dotclk_freq;
> >
> > + *pipe_mode = pipe_config->hw.adjusted_mode;
> > +
> > + /* Adjust pipe_mode for bigjoiner, with half the horizontal mode */
> > + if (pipe_config->bigjoiner) {
> > + pipe_mode->crtc_clock /= 2;
> > + pipe_mode->crtc_hdisplay /= 2;
> > + pipe_mode->crtc_hblank_start /= 2;
> > + pipe_mode->crtc_hblank_end /= 2;
> > + pipe_mode->crtc_hsync_start /= 2;
> > + pipe_mode->crtc_hsync_end /= 2;
> > + pipe_mode->crtc_htotal /= 2;
> > + pipe_mode->crtc_hskew /= 2;
> > + pipe_config->pipe_src_w /= 2;
> > + }
> > +
> > i
[Intel-gfx] ✓ Fi.CI.BAT: success for Remove DPCD Aux Backlight Control PWM_PIN check
== Series Details ==
Series: Remove DPCD Aux Backlight Control PWM_PIN check
URL : https://patchwork.freedesktop.org/series/82041/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9045 -> Patchwork_18560
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18560/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18560:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gt_lrc:
- {fi-tgl-dsi}: [DMESG-FAIL][1] ([i915#2373]) -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/fi-tgl-dsi/igt@i915_selftest@live@gt_lrc.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18560/fi-tgl-dsi/igt@i915_selftest@live@gt_lrc.html
Known issues
Here are the changes found in Patchwork_18560 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18560/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [PASS][5] -> [DMESG-WARN][6] ([i915#2203])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18560/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
* igt@vgem_basic@dmabuf-fence:
- fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#402])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/fi-tgl-y/igt@vgem_ba...@dmabuf-fence.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18560/fi-tgl-y/igt@vgem_ba...@dmabuf-fence.html
* igt@vgem_basic@unload:
- fi-kbl-x1275: [PASS][9] -> [DMESG-WARN][10] ([i915#62] / [i915#92])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/fi-kbl-x1275/igt@vgem_ba...@unload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18560/fi-kbl-x1275/igt@vgem_ba...@unload.html
Possible fixes
* {igt@core_hotunplug@unbind-rebind}:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/fi-kbl-x1275/igt@core_hotunp...@unbind-rebind.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18560/fi-kbl-x1275/igt@core_hotunp...@unbind-rebind.html
* igt@debugfs_test@read_all_entries:
- {fi-kbl-7560u}: [INCOMPLETE][13] ([i915#2417]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/fi-kbl-7560u/igt@debugfs_test@read_all_entries.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18560/fi-kbl-7560u/igt@debugfs_test@read_all_entries.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_9045/fi-byt-j1900/igt@i915_module_l...@reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18560/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-tgl-dsi}: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/fi-tgl-dsi/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18560/fi-tgl-dsi/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20] +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18560/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
Warnings
* igt@gem_exec_suspend@basic-s3:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][22] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18560/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
- fi-tgl-y: [DMESG-WARN][23] ([i915#2411]) -> [DMESG-WARN][24]
([i915#2411] / [i915#402])
[23]:
https://intel-gfx-ci.01
[Intel-gfx] ✓ Fi.CI.BAT: success for Fix NULL pointer found by static analysis (rev2)
== Series Details ==
Series: Fix NULL pointer found by static analysis (rev2)
URL : https://patchwork.freedesktop.org/series/81999/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9045 -> Patchwork_18559
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18559/index.html
Known issues
Here are the changes found in Patchwork_18559 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#1982] /
[k.org#205379])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/fi-tgl-y/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18559/fi-tgl-y/igt@i915_module_l...@reload.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][3] -> [DMESG-WARN][4] ([i915#62] / [i915#92] /
[i915#95]) +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18559/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/fi-tgl-y/igt@kms_busy@ba...@flip.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18559/fi-tgl-y/igt@kms_busy@ba...@flip.html
* igt@prime_self_import@basic-with_two_bos:
- fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18559/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
Possible fixes
* igt@debugfs_test@read_all_entries:
- {fi-kbl-7560u}: [INCOMPLETE][9] ([i915#2417]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/fi-kbl-7560u/igt@debugfs_test@read_all_entries.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18559/fi-kbl-7560u/igt@debugfs_test@read_all_entries.html
* igt@gem_tiled_fence_blits@basic:
- fi-tgl-y: [DMESG-WARN][11] ([i915#402]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/fi-tgl-y/igt@gem_tiled_fence_bl...@basic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18559/fi-tgl-y/igt@gem_tiled_fence_bl...@basic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18559/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
* igt@vgem_basic@unload:
- fi-skl-guc: [DMESG-WARN][15] ([i915#2203]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/fi-skl-guc/igt@vgem_ba...@unload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18559/fi-skl-guc/igt@vgem_ba...@unload.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18559/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-tgl-y: [DMESG-WARN][19] ([i915#1982] / [i915#2411]) ->
[DMESG-WARN][20] ([i915#2411])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18559/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92]) ->
[DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18559/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][24] ([i915#62] / [i915#92]) +8 similar issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9045/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18559/fi-kbl-x1275/igt@kms_force_
[Intel-gfx] [RFC PATCH 0/1] Remove DPCD Aux Backlight Control PWM_PIN check
The Google Pixel Slate/Nocturne device uses a DPCD backlight which requires Aux Backlight Control to be enabled. This is enabled in the ChromeOS kernel trees via disabling the PWM_PIN check and also an extended heuristic, which was upstreamed in 2017, but reverted shortly thereafter due to a regression on a Thinkpad X1 Carbon 4th Gen as per https://bugs.freedesktop.org/show_bug.cgi?id=101619 I'm hoping that there is a way to remove that check and not cause problems for other machines, as otherwise the backlight is nonfunctional for nocturne, (and possibly for other related machines such as the eve Pixelbook as well.) Satadru Pramanik (1): Remove DPCD Aux Backlight Control PWM_PIN check drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 1/1] Remove DPCD Aux Backlight Control PWM_PIN check
Google Pixel Slate/Nocturne needs intel_dp_aux_display_control_capable
set for the DPCD backlight to work. (The display exposes PWM_PIN
capability, but the pin is not connected.) Disabling the check allows
backlight adjustment to work.
Signed-off-by: Satadru Pramanik
---
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index acbd7eb66..308b14159 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -334,8 +334,7 @@ intel_dp_aux_display_control_capable(struct intel_connector
*connector)
* the panel can support backlight control over the aux channel
*/
if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
- (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
- !(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))
{
+ (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
drm_dbg_kms(&i915->drm, "AUX Backlight Control Supported!\n");
return true;
}
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Fix NULL pointer found by static analysis (rev2)
== Series Details == Series: Fix NULL pointer found by static analysis (rev2) URL : https://patchwork.freedesktop.org/series/81999/ State : warning == Summary == $ dim checkpatch origin/drm-tip 3a559b7eb929 Fix NULL pointer found by static analysis -:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #9: From: Intel-gfx On Behalf Of Steve Hampson -:30: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Intel-gfx ' total: 0 errors, 2 warnings, 0 checks, 8 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Fix NULL pointer found by static analysis
Never mind. This is a false positive. -Original Message- From: Intel-gfx On Behalf Of Steve Hampson Sent: Tuesday, September 22, 2020 9:41 PM To: intel-gfx@lists.freedesktop.org Subject: [Intel-gfx] [PATCH] Fix NULL pointer found by static analysis A static analysis tool has reveiled a NULL pointer error in __i915_gem_object_lock. This appears to be correct as many calls pass a NULL into the ww parameter. Signed-off-by: Steve Hampson --- drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h b/drivers/gpu/drm/i915/gem/i915_gem_object.h index d46db8d8f38e..9b18ead42991 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h @@ -126,7 +126,7 @@ static inline int __i915_gem_object_lock(struct drm_i915_gem_object *obj, if (ret == -EALREADY) ret = 0; - if (ret == -EDEADLK) + if (ret == -EDEADLK && ww) ww->contended = obj; return ret; -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
On Wed, 23 Sep 2020 22:55:54 +0200 Thomas Gleixner wrote: > > Perhaps make migrate_disable() an anonymous local_lock()? > > > > This should lower the SHC in theory, if you can't have stacked migrate > > disables on the same CPU. > > I'm pretty sure this ends up in locking hell pretty fast and aside of > that it's not working for scenarios like: > > kmap_local(); >migrate_disable(); >... > > copy_from_user() > -> #PF >-> schedule() > > which brought us into that discussion in the first place. You would stop > any other migrate disable user from running until the page fault is > resolved... Then scratch the idea of having anonymous local_lock() and just bring local_lock in directly? Then have a kmap local lock, which would only block those that need to do a kmap. Now as for migration disabled nesting, at least now we would have groupings of this, and perhaps the theorists can handle that. I mean, how is this much different that having a bunch of tasks blocked on a mutex with the owner is pinned on a CPU? migrate_disable() is a BKL of pinning affinity. If we only have local_lock() available (even on !RT), then it makes the blocking in groups. At least this way you could grep for all the different local_locks in the system and plug that into the algorithm for WCS, just like one would with a bunch of mutexes. -- Steve ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
On Wed, Sep 23 2020 at 11:52, Steven Rostedt wrote: > On Wed, 23 Sep 2020 10:40:32 +0200 > pet...@infradead.org wrote: > >> However, with migrate_disable() we can have each task preempted in a >> migrate_disable() region, worse we can stack them all on the _same_ CPU >> (super ridiculous odds, sure). And then we end up only able to run one >> task, with the rest of the CPUs picking their nose. > > What if we just made migrate_disable() a local_lock() available for !RT? > > I mean make it a priority inheritance PER CPU lock. > > That is, no two tasks could do a migrate_disable() on the same CPU? If > one task does a migrate_disable() and then gets preempted and the > preempting task does a migrate_disable() on the same CPU, it will block > and wait for the first task to do a migrate_enable(). > > No two tasks on the same CPU could enter the migrate_disable() section > simultaneously, just like no two tasks could enter a preempt_disable() > section. > > In essence, we just allow local_lock() to be used for both RT and !RT. > > Perhaps make migrate_disable() an anonymous local_lock()? > > This should lower the SHC in theory, if you can't have stacked migrate > disables on the same CPU. I'm pretty sure this ends up in locking hell pretty fast and aside of that it's not working for scenarios like: kmap_local(); migrate_disable(); ... copy_from_user() -> #PF -> schedule() which brought us into that discussion in the first place. You would stop any other migrate disable user from running until the page fault is resolved... Thanks, tglx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for HDCP misc (rev4)
== Series Details ==
Series: HDCP misc (rev4)
URL : https://patchwork.freedesktop.org/series/73345/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9043_full -> Patchwork_18557_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_18557_full:
### Piglit changes ###
Possible regressions
*
spec@arb_gpu_shader_int64@execution@built-in-functions@gs-op-add-u64vec3-uint64_t
(NEW):
- {pig-icl-1065g7}: NOTRUN -> [CRASH][1] +2 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18557/pig-icl-1065g7/spec@arb_gpu_shader_int64@execution@built-in-functions@gs-op-add-u64vec3-uint64_t.html
*
spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-mod-uint64_t-u64vec3
(NEW):
- {pig-icl-1065g7}: NOTRUN -> [INCOMPLETE][2] +7 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18557/pig-icl-1065g7/spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-mod-uint64_t-u64vec3.html
New tests
-
New tests have been introduced between CI_DRM_9043_full and
Patchwork_18557_full:
### New Piglit tests (11) ###
*
spec@arb_gpu_shader_int64@execution@built-in-functions@cs-op-mod-u64vec4-uint64_t:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@arb_gpu_shader_int64@execution@built-in-functions@fs-op-mod-uint64_t-u64vec4:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@arb_gpu_shader_int64@execution@built-in-functions@gs-op-add-int64_t-int64_t:
- Statuses : 1 crash(s)
- Exec time: [0.50] s
*
spec@arb_gpu_shader_int64@execution@built-in-functions@gs-op-add-u64vec3-uint64_t:
- Statuses : 1 crash(s)
- Exec time: [0.80] s
*
spec@arb_gpu_shader_int64@execution@built-in-functions@gs-op-mult-i64vec4-int64_t:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-div-i64vec3-int64_t:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-div-int64_t-i64vec3:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-lshift-int64_t-uint:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-mod-uint64_t-u64vec3:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@arb_gpu_shader_int64@execution@built-in-functions@tcs-op-ne-uint64_t-uint64_t:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
* spec@arb_gpu_shader_int64@execution@built-in-functions@vs-abs-int64_t:
- Statuses : 1 crash(s)
- Exec time: [0.56] s
Known issues
Here are the changes found in Patchwork_18557_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@engines@rcs0:
- shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/shard-glk5/igt@gem_exec_gttfill@engi...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18557/shard-glk3/igt@gem_exec_gttfill@engi...@rcs0.html
* igt@kms_draw_crc@draw-method-xrgb2101010-render-xtiled:
- shard-skl: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +5 similar
issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/shard-skl7/igt@kms_draw_...@draw-method-xrgb2101010-render-xtiled.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18557/shard-skl4/igt@kms_draw_...@draw-method-xrgb2101010-render-xtiled.html
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-pgflip-blt:
- shard-apl: [PASS][7] -> [DMESG-WARN][8] ([i915#1635] /
[i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/shard-apl6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-indfb-pgflip-blt.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18557/shard-apl1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-indfb-pgflip-blt.html
* igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/shard-kbl1/igt@kms_frontbuffer_track...@fbc-suspend.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18557/shard-kbl2/igt@kms_frontbuffer_track...@fbc-suspend.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw:
- shard-tglb: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +6
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/shard-tglb3/igt@kms_frontbuffer_track...@fbcpsr-1p-pri-indfb-multidraw.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18557/
Re: [Intel-gfx] [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY
On Wed, Sep 23, 2020 at 9:17 PM Marius Vlad wrote:
>
> On Wed, Sep 23, 2020 at 05:18:52PM +0200, Daniel Vetter wrote:
> > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > pull in arbitrary other resources, including CRTCs (e.g. when
> > reconfiguring global resources).
> >
> > But in nonblocking mode userspace has then no idea this happened,
> > which can lead to spurious EBUSY calls, both:
> > - when that other CRTC is currently busy doing a page_flip the
> > ALLOW_MODESET commit can fail with an EBUSY
> > - on the other CRTC a normal atomic flip can fail with EBUSY because
> > of the additional commit inserted by the kernel without userspace's
> > knowledge
> >
> > For blocking commits this isn't a problem, because everyone else will
> > just block until all the CRTC are reconfigured. Only thing userspace
> > can notice is the dropped frames without any reason for why frames got
> > dropped.
> >
> > Consensus is that we need new uapi to handle this properly, but no one
> > has any idea what exactly the new uapi should look like. Since this
> > has been shipping for years already compositors need to deal no matter
> > what, so as a first step just try to enforce this across drivers
> > better with some checks.
> >
> > v2: Add comments and a WARN_ON to enforce this only when allowed - we
> > don't want to silently convert page flips into blocking plane updates
> > just because the driver is buggy.
> >
> > v3: Fix inverted WARN_ON (Pekka).
> >
> > v4: Drop the uapi changes, only add a WARN_ON for now to enforce some
> > rules for drivers.
> >
> > v5: Make the WARNING more informative (Daniel)
> >
> > v6: Add unconditional debug output for compositor hackers to figure
> > out what's going on when they get an EBUSY (Daniel)
> >
> > References:
> > https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
> > Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
> > Cc: Daniel Stone
> > Cc: Pekka Paalanen
> > Cc: Simon Ser
> > Cc: Ville Syrjälä
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_atomic.c | 29 +
> > 1 file changed, 29 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 58527f151984..f1a912e80846 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -281,6 +281,10 @@ EXPORT_SYMBOL(__drm_atomic_state_free);
> > * needed. It will also grab the relevant CRTC lock to make sure that the
> > state
> > * is consistent.
> > *
> > + * WARNING: Drivers may only add new CRTC states to a @state if
> > + * drm_atomic_state.allow_modeset is set, or if it's a driver-internal
> > commit
> > + * not created by userspace through an IOCTL call.
> > + *
> > * Returns:
> > *
> > * Either the allocated state or the error code encoded into the pointer.
> > When
> > @@ -1262,10 +1266,15 @@ int drm_atomic_check_only(struct drm_atomic_state
> > *state)
> > struct drm_crtc_state *new_crtc_state;
> > struct drm_connector *conn;
> > struct drm_connector_state *conn_state;
> > + unsigned requested_crtc = 0;
> > + unsigned affected_crtc = 0;
> > int i, ret = 0;
> >
> > DRM_DEBUG_ATOMIC("checking %p\n", state);
> >
> > + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> > + requested_crtc |= drm_crtc_mask(crtc);
> > +
> > for_each_oldnew_plane_in_state(state, plane, old_plane_state,
> > new_plane_state, i) {
> > ret = drm_atomic_plane_check(old_plane_state,
> > new_plane_state);
> > if (ret) {
> > @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state
> > *state)
> > }
> > }
> >
> > + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> > + affected_crtc |= drm_crtc_mask(crtc);
> > +
> > + /*
> > + * For commits that allow modesets drivers can add other CRTCs to the
> > + * atomic commit, e.g. when they need to reallocate global resources.
> > + * This can cause spurious EBUSY, which robs compositors of a very
> > + * effective sanity check for their drawing loop. Therefor only allow
> > + * drivers to add unrelated CRTC states for modeset commits.
> > + *
> > + * FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an
> > output
> > + * so compositors know what's going on.
> > + */
> > + if (affected_crtc != requested_crtc) {
> > + DRM_DEBUG_ATOMIC("driver added CRTC to commit: requested
> > 0x%x, affected 0x%0x\n",
> > + requested_crtc, affected_crtc);
> > + WARN(!state->allow_modeset, "adding CRTC not allowed without
> > modesets: requested 0x%x, affected 0x%0x\n",
> > + requested_crtc, affected_crtc);
> Previous patch had the warn on state->allow_modeset now is
> !state->allow_modeset. Is that correct?
We need
Re: [Intel-gfx] [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY
On Wed, Sep 23, 2020 at 05:18:52PM +0200, Daniel Vetter wrote:
> When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> pull in arbitrary other resources, including CRTCs (e.g. when
> reconfiguring global resources).
>
> But in nonblocking mode userspace has then no idea this happened,
> which can lead to spurious EBUSY calls, both:
> - when that other CRTC is currently busy doing a page_flip the
> ALLOW_MODESET commit can fail with an EBUSY
> - on the other CRTC a normal atomic flip can fail with EBUSY because
> of the additional commit inserted by the kernel without userspace's
> knowledge
>
> For blocking commits this isn't a problem, because everyone else will
> just block until all the CRTC are reconfigured. Only thing userspace
> can notice is the dropped frames without any reason for why frames got
> dropped.
>
> Consensus is that we need new uapi to handle this properly, but no one
> has any idea what exactly the new uapi should look like. Since this
> has been shipping for years already compositors need to deal no matter
> what, so as a first step just try to enforce this across drivers
> better with some checks.
>
> v2: Add comments and a WARN_ON to enforce this only when allowed - we
> don't want to silently convert page flips into blocking plane updates
> just because the driver is buggy.
>
> v3: Fix inverted WARN_ON (Pekka).
>
> v4: Drop the uapi changes, only add a WARN_ON for now to enforce some
> rules for drivers.
>
> v5: Make the WARNING more informative (Daniel)
>
> v6: Add unconditional debug output for compositor hackers to figure
> out what's going on when they get an EBUSY (Daniel)
>
> References:
> https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
> Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
> Cc: Daniel Stone
> Cc: Pekka Paalanen
> Cc: Simon Ser
> Cc: Ville Syrjälä
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic.c | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 58527f151984..f1a912e80846 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -281,6 +281,10 @@ EXPORT_SYMBOL(__drm_atomic_state_free);
> * needed. It will also grab the relevant CRTC lock to make sure that the
> state
> * is consistent.
> *
> + * WARNING: Drivers may only add new CRTC states to a @state if
> + * drm_atomic_state.allow_modeset is set, or if it's a driver-internal commit
> + * not created by userspace through an IOCTL call.
> + *
> * Returns:
> *
> * Either the allocated state or the error code encoded into the pointer.
> When
> @@ -1262,10 +1266,15 @@ int drm_atomic_check_only(struct drm_atomic_state
> *state)
> struct drm_crtc_state *new_crtc_state;
> struct drm_connector *conn;
> struct drm_connector_state *conn_state;
> + unsigned requested_crtc = 0;
> + unsigned affected_crtc = 0;
> int i, ret = 0;
>
> DRM_DEBUG_ATOMIC("checking %p\n", state);
>
> + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> + requested_crtc |= drm_crtc_mask(crtc);
> +
> for_each_oldnew_plane_in_state(state, plane, old_plane_state,
> new_plane_state, i) {
> ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
> if (ret) {
> @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state
> *state)
> }
> }
>
> + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> + affected_crtc |= drm_crtc_mask(crtc);
> +
> + /*
> + * For commits that allow modesets drivers can add other CRTCs to the
> + * atomic commit, e.g. when they need to reallocate global resources.
> + * This can cause spurious EBUSY, which robs compositors of a very
> + * effective sanity check for their drawing loop. Therefor only allow
> + * drivers to add unrelated CRTC states for modeset commits.
> + *
> + * FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an output
> + * so compositors know what's going on.
> + */
> + if (affected_crtc != requested_crtc) {
> + DRM_DEBUG_ATOMIC("driver added CRTC to commit: requested 0x%x,
> affected 0x%0x\n",
> + requested_crtc, affected_crtc);
> + WARN(!state->allow_modeset, "adding CRTC not allowed without
> modesets: requested 0x%x, affected 0x%0x\n",
> + requested_crtc, affected_crtc);
Previous patch had the warn on state->allow_modeset now is
!state->allow_modeset. Is that correct?
I haven't followed the entire thread on this matter, but I guess the idea
is that somehow the kernel would pass to userspace a CRTC mask of
affected_crtc (somehow, we don't know how atm) and with it, userspace
can then issue a new commit (this commit blocking) with those?
> + }
>
[Intel-gfx] ✓ Fi.CI.IGT: success for dma-buf: Flag vmap'ed memory as system or I/O memory (rev2)
== Series Details == Series: dma-buf: Flag vmap'ed memory as system or I/O memory (rev2) URL : https://patchwork.freedesktop.org/series/81647/ State : success == Summary == CI Bug Log - changes from CI_DRM_9042_full -> Patchwork_18556_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18556_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@kms: - shard-snb: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-snb4/igt@gem_...@kms.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18556/shard-snb5/igt@gem_...@kms.html * igt@gem_exec_create@forked: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-glk3/igt@gem_exec_cre...@forked.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18556/shard-glk9/igt@gem_exec_cre...@forked.html * igt@gem_exec_suspend@basic-s3: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([i915#198]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl10/igt@gem_exec_susp...@basic-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18556/shard-skl1/igt@gem_exec_susp...@basic-s3.html * igt@i915_pm_rc6_residency@rc6-fence: - shard-hsw: [PASS][7] -> [WARN][8] ([i915#1519]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-hsw2/igt@i915_pm_rc6_reside...@rc6-fence.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18556/shard-hsw1/igt@i915_pm_rc6_reside...@rc6-fence.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#1635] / [i915#1982]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-apl8/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18556/shard-apl8/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_draw_crc@draw-method-rgb565-mmap-cpu-ytiled: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +5 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl2/igt@kms_draw_...@draw-method-rgb565-mmap-cpu-ytiled.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18556/shard-skl8/igt@kms_draw_...@draw-method-rgb565-mmap-cpu-ytiled.html * igt@kms_flip@2x-flip-vs-blocking-wf-vblank@ab-vga1-hdmi-a1: - shard-hsw: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-hsw5/igt@kms_flip@2x-flip-vs-blocking-wf-vbl...@ab-vga1-hdmi-a1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18556/shard-hsw6/igt@kms_flip@2x-flip-vs-blocking-wf-vbl...@ab-vga1-hdmi-a1.html * igt@kms_flip@2x-flip-vs-suspend-interruptible@bc-vga1-hdmi-a1: - shard-hsw: [PASS][15] -> [INCOMPLETE][16] ([i915#2055]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-hsw2/igt@kms_flip@2x-flip-vs-suspend-interrupti...@bc-vga1-hdmi-a1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18556/shard-hsw8/igt@kms_flip@2x-flip-vs-suspend-interrupti...@bc-vga1-hdmi-a1.html * igt@kms_flip@2x-plain-flip-fb-recreate@ab-hdmi-a1-hdmi-a2: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#2122]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-glk3/igt@kms_flip@2x-plain-flip-fb-recre...@ab-hdmi-a1-hdmi-a2.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18556/shard-glk7/igt@kms_flip@2x-plain-flip-fb-recre...@ab-hdmi-a1-hdmi-a2.html * igt@kms_flip@flip-vs-expired-vblank@a-edp1: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#79]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl5/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18556/shard-skl5/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html * igt@kms_flip@flip-vs-suspend@c-dp1: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-kbl6/igt@kms_flip@flip-vs-susp...@c-dp1.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18556/shard-kbl1/igt@kms_flip@flip-vs-susp...@c-dp1.html * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-cpu: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#49]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl9/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-indfb-draw-mmap-cpu.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18
Re: [Intel-gfx] [PATCH v3 3/3] drm/i915/display: Program PSR2 selective fetch registers
On Wed, 2020-09-23 at 10:10 -0700, José Roberto de Souza wrote:
> On Wed, 2020-09-23 at 14:02 +0100, Mun, Gwan-gyeong wrote:
> > On Thu, 2020-09-17 at 18:02 -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.
> > >
> > > v2:
> > > - removed warn on when no plane is visible in state
> > > - removed calculations using plane damaged area in
> > > intel_psr2_program_plane_sel_fetch()
> > >
> > > v3:
> > > - do not shift 16 positions the plane dst coordinates, only src is
> > > shifted
> > >
> > > 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 +-
> > > drivers/gpu/drm/i915/display/intel_psr.c | 120
> > > ++-
> > > drivers/gpu/drm/i915/display/intel_psr.h | 10 +-
> > > drivers/gpu/drm/i915/display/intel_sprite.c | 3 +
> > > 4 files changed, 134 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 5a9d933e425a..96bc515497c1 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -11812,6 +11812,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) {
> > > @@ -12823,8 +12826,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_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index 02f74b0ddec1..deb0523f9f29 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > @@ -1166,6 +1166,41 @@ 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);
> > > + enum pipe pipe = plane->pipe;
> > > + u32 val;
> > > +
> > > + if (!crtc_state->enable_psr2_sel_fetch)
> > > + return;
> > > +
> > > + /*
> > > + * skl_plane_ctl_crtc()/i9xx_cursor_ctl_crtc() return 0 for
> > > gen11+, so
> > > + * plane_state->ctl is the right value
> > > + */
> > > + val = plane_state ? plane_state->ctl : 0;
> >
> > IMHO, skl_plane_ctl() might set other ctl bits, it would be better to
> > have separated ctl bit value for "selective fetch ctl".
>
> Like said all other bits are spares so can be set without issues but okay
> will a "plane_state->ctl & PLANE_SEL_FETCH_CTL_ENABLE".
Please take a look to the answer of your other comment bellow, with the change
above can I have your rv-b?
>
> > > + intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, plane-
> > > > id), val);
> > >
> > > + if (!val || plane->id == PLANE_CURSOR)
> > > + return;
> > > +
> > > + val = plane_state->uapi.dst.y1 << 16 | plane_state-
> > > > uapi.dst.x1;
> > >
> > > + intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_POS(pipe, plane-
> > > > id), val);
> > >
> > > +
> > > + val = 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(&plane_state->uapi.src) >> 16) - 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_
Re: [Intel-gfx] [PATCH v3 3/3] drm/i915/display: Program PSR2 selective fetch registers
On Wed, 2020-09-23 at 14:02 +0100, Mun, Gwan-gyeong wrote:
> On Thu, 2020-09-17 at 18:02 -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.
> >
> > v2:
> > - removed warn on when no plane is visible in state
> > - removed calculations using plane damaged area in
> > intel_psr2_program_plane_sel_fetch()
> >
> > v3:
> > - do not shift 16 positions the plane dst coordinates, only src is
> > shifted
> >
> > 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 +-
> > drivers/gpu/drm/i915/display/intel_psr.c | 120
> > ++-
> > drivers/gpu/drm/i915/display/intel_psr.h | 10 +-
> > drivers/gpu/drm/i915/display/intel_sprite.c | 3 +
> > 4 files changed, 134 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 5a9d933e425a..96bc515497c1 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -11812,6 +11812,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) {
> > @@ -12823,8 +12826,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_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 02f74b0ddec1..deb0523f9f29 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -1166,6 +1166,41 @@ 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);
> > + enum pipe pipe = plane->pipe;
> > + u32 val;
> > +
> > + if (!crtc_state->enable_psr2_sel_fetch)
> > + return;
> > +
> > + /*
> > +* skl_plane_ctl_crtc()/i9xx_cursor_ctl_crtc() return 0 for
> > gen11+, so
> > +* plane_state->ctl is the right value
> > +*/
> > + val = plane_state ? plane_state->ctl : 0;
>
> IMHO, skl_plane_ctl() might set other ctl bits, it would be better to
> have separated ctl bit value for "selective fetch ctl".
Like said all other bits are spares so can be set without issues but okay will
a "plane_state->ctl & PLANE_SEL_FETCH_CTL_ENABLE".
> > + intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, plane-
> > > id), val);
> >
> > + if (!val || plane->id == PLANE_CURSOR)
> > + return;
> > +
> > + val = plane_state->uapi.dst.y1 << 16 | plane_state-
> > > uapi.dst.x1;
> >
> > + intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_POS(pipe, plane-
> > > id), val);
> >
> > +
> > + val = 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(&plane_state->uapi.src) >> 16) - 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)
> > {
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > @@ -1180,16 +1215,91 @@ void
> > intel_psr2_program_trans_man_trk_ctl(const struct intel_crtc_state
> > *crtc_st
> >crtc_state->psr2_man_track_ctl);
> > }
> >
> > -void intel_psr2_sel_fetch_
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Switch 4k kmalloc to use get_free_page for alignment
== Series Details == Series: drm/i915/selftests: Switch 4k kmalloc to use get_free_page for alignment URL : https://patchwork.freedesktop.org/series/82028/ State : success == Summary == CI Bug Log - changes from CI_DRM_9042_full -> Patchwork_18555_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18555_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]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-kbl1/igt@gem_ctx_isolation@preservation...@vcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/shard-kbl2/igt@gem_ctx_isolation@preservation...@vcs0.html * igt@gem_exec_reloc@basic-many-active@rcs0: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#2389]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-glk3/igt@gem_exec_reloc@basic-many-act...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/shard-glk1/igt@gem_exec_reloc@basic-many-act...@rcs0.html * igt@gem_exec_whisper@basic-fds-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_9042/shard-glk8/igt@gem_exec_whis...@basic-fds-forked-all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/shard-glk7/igt@gem_exec_whis...@basic-fds-forked-all.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][7] -> [SKIP][8] ([i915#2190]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-tglb8/igt@gem_huc_c...@huc-copy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/shard-tglb6/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_offset@blt-coherency: - shard-apl: [PASS][9] -> [FAIL][10] ([i915#1635]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-apl1/igt@gem_mmap_off...@blt-coherency.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/shard-apl3/igt@gem_mmap_off...@blt-coherency.html * igt@gem_userptr_blits@unsync-unmap-cycles: - shard-skl: [PASS][11] -> [TIMEOUT][12] ([i915#1958]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl2/igt@gem_userptr_bl...@unsync-unmap-cycles.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/shard-skl6/igt@gem_userptr_bl...@unsync-unmap-cycles.html * igt@gem_workarounds@basic-read-context: - shard-snb: [PASS][13] -> [TIMEOUT][14] ([i915#1958]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-snb5/igt@gem_workarou...@basic-read-context.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/shard-snb5/igt@gem_workarou...@basic-read-context.html * igt@i915_selftest@mock@requests: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([i915#198] / [i915#2278]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl5/igt@i915_selftest@m...@requests.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/shard-skl9/igt@i915_selftest@m...@requests.html * igt@kms_big_fb@linear-64bpp-rotate-180: - shard-iclb: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-iclb3/igt@kms_big...@linear-64bpp-rotate-180.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/shard-iclb3/igt@kms_big...@linear-64bpp-rotate-180.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#1635] / [i915#1982]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-apl8/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/shard-apl3/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_flip@2x-flip-vs-expired-vblank@ab-hdmi-a1-hdmi-a2: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#79]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-glk8/igt@kms_flip@2x-flip-vs-expired-vbl...@ab-hdmi-a1-hdmi-a2.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/shard-glk5/igt@kms_flip@2x-flip-vs-expired-vbl...@ab-hdmi-a1-hdmi-a2.html * igt@kms_flip@flip-vs-suspend-interruptible@c-hdmi-a1: - shard-hsw: [PASS][23] -> [INCOMPLETE][24] ([i915#2055]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-hsw2/igt@kms_flip@flip-vs-suspend-interrupti...@c-hdmi-a1.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/shard-hsw1/igt@kms_flip@flip-vs-suspend-interrupti...@c-hdmi-a1.html * igt@kms_frontbuffer_trackin
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with drm/atomic: document and enforce rules around "spurious" EBUSY (rev2)
== Series Details ==
Series: series starting with drm/atomic: document and enforce rules around
"spurious" EBUSY (rev2)
URL : https://patchwork.freedesktop.org/series/82023/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9043 -> Patchwork_18558
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18558 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18558, 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_18558/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18558:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@execlists:
- fi-cml-u2: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-cml-u2/igt@i915_selftest@l...@execlists.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-cml-u2/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-bsw-kefka: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-bsw-kefka/igt@i915_selftest@live@gt_heartbeat.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-bsw-kefka/igt@i915_selftest@live@gt_heartbeat.html
Known issues
Here are the changes found in Patchwork_18558 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ringfill@basic-all:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-tgl-y/igt@gem_ringf...@basic-all.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-tgl-y/igt@gem_ringf...@basic-all.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][7] -> [DMESG-WARN][8] ([i915#62] / [i915#92] /
[i915#95])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-u2: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Possible fixes
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [FAIL][13] ([i915#1372]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
* igt@kms_flip@basic-plain-flip@d-dsi1:
- {fi-tgl-dsi}: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-tgl-dsi/igt@kms_flip@basic-plain-f...@d-dsi1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-tgl-dsi/igt@kms_flip@basic-plain-f...@d-dsi1.html
* igt@vgem_basic@setversion:
- fi-tgl-y: [DMESG-WARN][19] ([i915#402]) -> [PASS][20] +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-tgl-y/igt@vgem_ba...@setversion.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-tgl-y/igt@vgem_ba...@setversion.html
* igt@vgem_basic@unload:
- fi-skl-guc: [DMESG-WARN][21] ([i915#2203]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-skl-guc/igt@vgem_ba...@unload.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-skl-guc/igt@vgem_ba...@unload.html
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) -> [PASS]
Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
On Wed, 23 Sep 2020 10:40:32 +0200 pet...@infradead.org wrote: > However, with migrate_disable() we can have each task preempted in a > migrate_disable() region, worse we can stack them all on the _same_ CPU > (super ridiculous odds, sure). And then we end up only able to run one > task, with the rest of the CPUs picking their nose. What if we just made migrate_disable() a local_lock() available for !RT? I mean make it a priority inheritance PER CPU lock. That is, no two tasks could do a migrate_disable() on the same CPU? If one task does a migrate_disable() and then gets preempted and the preempting task does a migrate_disable() on the same CPU, it will block and wait for the first task to do a migrate_enable(). No two tasks on the same CPU could enter the migrate_disable() section simultaneously, just like no two tasks could enter a preempt_disable() section. In essence, we just allow local_lock() to be used for both RT and !RT. Perhaps make migrate_disable() an anonymous local_lock()? This should lower the SHC in theory, if you can't have stacked migrate disables on the same CPU. -- Steve ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with drm/atomic: document and enforce rules around "spurious" EBUSY (rev2)
== Series Details ==
Series: series starting with drm/atomic: document and enforce rules around
"spurious" EBUSY (rev2)
URL : https://patchwork.freedesktop.org/series/82023/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2ae63b2182d7 drm/atomic: document and enforce rules around "spurious" EBUSY
-:47: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#47:
References:
https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
-:74: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#74: FILE: drivers/gpu/drm/drm_atomic.c:1269:
+ unsigned requested_crtc = 0;
-:75: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#75: FILE: drivers/gpu/drm/drm_atomic.c:1270:
+ unsigned affected_crtc = 0;
-:112: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 4 warnings, 0 checks, 51 lines checked
126d6b5ccc51 drm/atomic: debug output for EBUSY
-:52: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#52: FILE: drivers/gpu/drm/drm_atomic_helper.c:1741:
+ DRM_DEBUG_ATOMIC("[PLANE:%d:%s] inflight previous commit
preventing async commit\n",
+ plane->base.id, plane->name);
-:63: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#63: FILE: drivers/gpu/drm/drm_atomic_helper.c:1962:
+ DRM_DEBUG_ATOMIC("[CRTC:%d:%s] busy with a
previous commit\n",
+ crtc->base.id, crtc->name);
-:75: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#75: FILE: drivers/gpu/drm/drm_atomic_helper.c:2140:
+ DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] busy with a
previous commit\n",
+ conn->base.id, conn->name);
-:89: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#89: FILE: drivers/gpu/drm/drm_atomic_helper.c:2159:
+ DRM_DEBUG_ATOMIC("[PLANE:%d:%s] busy with a previous
commit\n",
+ plane->base.id, plane->name);
-:95: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 4 checks, 63 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/3] dma-buf: Use struct dma_buf_map in dma_buf_vunmap() interfaces
On Wed, Sep 23, 2020 at 02:32:05PM +0200, Thomas Zimmermann wrote:
> This patch updates dma_buf_vunmap() and dma-buf's vunmap callback to
> use struct dma_buf_map. The interfaces used to receive a buffer address.
> This address is now given in an instance of the structure.
>
> Users of the functions are updated accordingly. This is only an interface
> change. It is currently expected that dma-buf memory can be accessed with
> system memory load/store operations.
>
> v2:
> * include dma-buf-heaps and i915 selftests (kernel test robot)
> * initialize cma_obj before using it in drm_gem_cma_free_object()
> (kernel test robot)
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Sumit Semwal
Acked-by: Daniel Vetter
> ---
> drivers/dma-buf/dma-buf.c | 8 ++---
> drivers/dma-buf/heaps/heap-helpers.c | 2 +-
> drivers/gpu/drm/drm_gem_cma_helper.c | 9 +++---
> drivers/gpu/drm/drm_gem_shmem_helper.c| 3 +-
> drivers/gpu/drm/drm_prime.c | 6 ++--
> drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 5 +--
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 2 +-
> .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 6 ++--
> .../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 4 +--
> drivers/gpu/drm/tegra/gem.c | 5 +--
> .../common/videobuf2/videobuf2-dma-contig.c | 3 +-
> .../media/common/videobuf2/videobuf2-dma-sg.c | 3 +-
> .../common/videobuf2/videobuf2-vmalloc.c | 6 ++--
> include/drm/drm_prime.h | 2 +-
> include/linux/dma-buf-map.h | 32 +--
> include/linux/dma-buf.h | 4 +--
> 16 files changed, 66 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 61bd24d21b38..a6ba4d598f0e 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -1236,21 +1236,21 @@ EXPORT_SYMBOL_GPL(dma_buf_vmap);
> /**
> * dma_buf_vunmap - Unmap a vmap obtained by dma_buf_vmap.
> * @dmabuf: [in]buffer to vunmap
> - * @vaddr: [in]vmap to vunmap
> + * @map: [in]vmap pointer to vunmap
> */
> -void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
> +void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map)
> {
> if (WARN_ON(!dmabuf))
> return;
>
> BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
> BUG_ON(dmabuf->vmapping_counter == 0);
> - BUG_ON(!dma_buf_map_is_vaddr(&dmabuf->vmap_ptr, vaddr));
> + BUG_ON(!dma_buf_map_is_equal(&dmabuf->vmap_ptr, map));
>
> mutex_lock(&dmabuf->lock);
> if (--dmabuf->vmapping_counter == 0) {
> if (dmabuf->ops->vunmap)
> - dmabuf->ops->vunmap(dmabuf, vaddr);
> + dmabuf->ops->vunmap(dmabuf, map);
> dma_buf_map_clear(&dmabuf->vmap_ptr);
> }
> mutex_unlock(&dmabuf->lock);
> diff --git a/drivers/dma-buf/heaps/heap-helpers.c
> b/drivers/dma-buf/heaps/heap-helpers.c
> index aeb9e100f339..fcf4ce3e2cbb 100644
> --- a/drivers/dma-buf/heaps/heap-helpers.c
> +++ b/drivers/dma-buf/heaps/heap-helpers.c
> @@ -251,7 +251,7 @@ static int dma_heap_dma_buf_vmap(struct dma_buf *dmabuf,
> struct dma_buf_map *map
> return 0;
> }
>
> -static void dma_heap_dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
> +static void dma_heap_dma_buf_vunmap(struct dma_buf *dmabuf, struct
> dma_buf_map *map)
> {
> struct heap_helper_buffer *buffer = dmabuf->priv;
>
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> b/drivers/gpu/drm/drm_gem_cma_helper.c
> index 1ece73fd3fe9..1059acdde519 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -175,13 +175,12 @@ drm_gem_cma_create_with_handle(struct drm_file
> *file_priv,
> */
> void drm_gem_cma_free_object(struct drm_gem_object *gem_obj)
> {
> - struct drm_gem_cma_object *cma_obj;
> -
> - cma_obj = to_drm_gem_cma_obj(gem_obj);
> + struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(gem_obj);
> + struct dma_buf_map map = DMA_BUF_MAP_INIT_VADDR(cma_obj->vaddr);
>
> if (gem_obj->import_attach) {
> if (cma_obj->vaddr)
> - dma_buf_vunmap(gem_obj->import_attach->dmabuf,
> cma_obj->vaddr);
> + dma_buf_vunmap(gem_obj->import_attach->dmabuf, &map);
> drm_prime_gem_destroy(gem_obj, cma_obj->sgt);
> } else if (cma_obj->vaddr) {
> dma_free_wc(gem_obj->dev->dev, cma_obj->base.size,
> @@ -628,7 +627,7 @@ drm_gem_cma_prime_import_sg_table_vmap(struct drm_device
> *dev,
>
> obj = drm_gem_cma_prime_import_sg_table(dev, attach, sgt);
> if (IS_ERR(obj)) {
> - dma_buf_vunmap(attach->dmabuf, map.vaddr);
> + dma_buf_vunmap(attach->dmabuf, &map);
> return obj;
> }
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
Re: [Intel-gfx] [PATCH v2 2/3] dma-buf: Use struct dma_buf_map in dma_buf_vmap() interfaces
On Wed, Sep 23, 2020 at 02:32:04PM +0200, Thomas Zimmermann wrote:
> This patch updates dma_buf_vmap() and dma-buf's vmap callback to use
> struct dma_buf_map.
>
> The interfaces used to return a buffer address. This address now gets
> stored in an instance of the structure that is given as an additional
> argument. The functions return an errno code on errors.
>
> Users of the functions are updated accordingly. This is only an interface
> change. It is currently expected that dma-buf memory can be accessed with
> system memory load/store operations.
>
> v2:
> * always clear map parameter in dma_buf_vmap() (Daniel)
> * include dma-buf-heaps and i915 selftests (kernel test robot)
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Sumit Semwal
Too lazy to check for all possible conversion issues, but I think I've
done a close look last time around. As long as this is build tested across
all drivers and architectures we care about we should be fine.
Acked-by: Daniel Vetter
> ---
> drivers/dma-buf/dma-buf.c | 28 +++
> drivers/dma-buf/heaps/heap-helpers.c | 8 --
> drivers/gpu/drm/drm_gem_cma_helper.c | 13 +
> drivers/gpu/drm/drm_gem_shmem_helper.c| 14 ++
> drivers/gpu/drm/drm_prime.c | 8 --
> drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 8 +-
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 11 ++--
> .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 12 ++--
> .../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 10 +--
> drivers/gpu/drm/tegra/gem.c | 18
> .../common/videobuf2/videobuf2-dma-contig.c | 14 +++---
> .../media/common/videobuf2/videobuf2-dma-sg.c | 16 +++
> .../common/videobuf2/videobuf2-vmalloc.c | 15 +++---
> include/drm/drm_prime.h | 3 +-
> include/linux/dma-buf-map.h | 13 +
> include/linux/dma-buf.h | 6 ++--
> 16 files changed, 138 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 5e849ca241a0..61bd24d21b38 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -1186,46 +1186,50 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
> * dma_buf_vmap - Create virtual mapping for the buffer object into kernel
> * address space. Same restrictions as for vmap and friends apply.
> * @dmabuf: [in]buffer to vmap
> + * @map: [out] returns the vmap pointer
> *
> * This call may fail due to lack of virtual mapping address space.
> * These calls are optional in drivers. The intended use for them
> * is for mapping objects linear in kernel space for high use objects.
> * Please attempt to use kmap/kunmap before thinking about these interfaces.
> *
> - * Returns NULL on error.
> + * Returns 0 on success, or a negative errno code otherwise.
> */
> -void *dma_buf_vmap(struct dma_buf *dmabuf)
> +int dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map *map)
> {
> - void *ptr;
> + struct dma_buf_map ptr;
> + int ret = 0;
> +
> + dma_buf_map_clear(map);
>
> if (WARN_ON(!dmabuf))
> - return NULL;
> + return -EINVAL;
>
> if (!dmabuf->ops->vmap)
> - return NULL;
> + return -EINVAL;
>
> mutex_lock(&dmabuf->lock);
> if (dmabuf->vmapping_counter) {
> dmabuf->vmapping_counter++;
> BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
> - ptr = dmabuf->vmap_ptr.vaddr;
> + *map = dmabuf->vmap_ptr;
> goto out_unlock;
> }
>
> BUG_ON(dma_buf_map_is_set(&dmabuf->vmap_ptr));
>
> - ptr = dmabuf->ops->vmap(dmabuf);
> - if (WARN_ON_ONCE(IS_ERR(ptr)))
> - ptr = NULL;
> - if (!ptr)
> + ret = dmabuf->ops->vmap(dmabuf, &ptr);
> + if (WARN_ON_ONCE(ret))
> goto out_unlock;
>
> - dmabuf->vmap_ptr.vaddr = ptr;
> + dmabuf->vmap_ptr = ptr;
> dmabuf->vmapping_counter = 1;
>
> + *map = dmabuf->vmap_ptr;
> +
> out_unlock:
> mutex_unlock(&dmabuf->lock);
> - return ptr;
> + return ret;
> }
> EXPORT_SYMBOL_GPL(dma_buf_vmap);
>
> diff --git a/drivers/dma-buf/heaps/heap-helpers.c
> b/drivers/dma-buf/heaps/heap-helpers.c
> index d0696cf937af..aeb9e100f339 100644
> --- a/drivers/dma-buf/heaps/heap-helpers.c
> +++ b/drivers/dma-buf/heaps/heap-helpers.c
> @@ -235,7 +235,7 @@ static int dma_heap_dma_buf_end_cpu_access(struct dma_buf
> *dmabuf,
> return 0;
> }
>
> -static void *dma_heap_dma_buf_vmap(struct dma_buf *dmabuf)
> +static int dma_heap_dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map
> *map)
> {
> struct heap_helper_buffer *buffer = dmabuf->priv;
> void *vaddr;
> @@ -244,7 +244,11 @@ static void *dma_heap_dma_buf_vmap(struct dma_buf
> *dmabuf)
> vaddr = dma_heap_buffer_vmap_get(b
Re: [Intel-gfx] [PATCH v2 1/3] dma-buf: Add struct dma-buf-map for storing struct dma_buf.vaddr_ptr
On Wed, Sep 23, 2020 at 04:27:04PM +0200, Christian König wrote:
> Am 23.09.20 um 14:32 schrieb Thomas Zimmermann:
> > The new type struct dma_buf_map represents a mapping of dma-buf memory
> > into kernel space. It contains a flag, is_iomem, that signals users to
> > access the mapped memory with I/O operations instead of regular loads
> > and stores.
> >
> > It was assumed that DMA buffer memory can be accessed with regular load
> > and store operations. Some architectures, such as sparc64, require the
> > use of I/O operations to access dma-map buffers that are located in I/O
> > memory. Providing struct dma_buf_map allows drivers to implement this.
> > This was specifically a problem when refreshing the graphics framebuffer
> > on such systems. [1]
> >
> > As the first step, struct dma_buf stores an instance of struct dma_buf_map
> > internally. Afterwards, dma-buf's vmap and vunmap interfaces are be
> > converted. Finally, affected drivers can be fixed.
> >
> > [1]
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20200725191012.GA434957%40ravnborg.org%2F&data=02%7C01%7Cchristian.koenig%40amd.com%7C54486b9682654f3950b808d85fbcb1d3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637364611338153209&sdata=%2BZm7t8OcgkIxnY%2FdZSLhSbKC7t1y4VW5lINFKwCQv3A%3D&reserved=0
>
> Only two nit picks below, apart from that Reviewed-by: Christian König
>
>
> >
> > Signed-off-by: Thomas Zimmermann
> > Acked-by: Sumit Semwal
> > ---
> > Documentation/driver-api/dma-buf.rst | 3 +
> > drivers/dma-buf/dma-buf.c| 14 ++---
> > include/linux/dma-buf-map.h | 87
> > include/linux/dma-buf.h | 3 +-
> > 4 files changed, 99 insertions(+), 8 deletions(-)
> > create mode 100644 include/linux/dma-buf-map.h
> >
> > diff --git a/Documentation/driver-api/dma-buf.rst
> > b/Documentation/driver-api/dma-buf.rst
> > index 13ea0cc0a3fa..3244c600a9a1 100644
> > --- a/Documentation/driver-api/dma-buf.rst
> > +++ b/Documentation/driver-api/dma-buf.rst
> > @@ -115,6 +115,9 @@ Kernel Functions and Structures Reference
> > .. kernel-doc:: include/linux/dma-buf.h
> > :internal:
Please add a heading here, maybe "Buffer mapping helpers" or somethig like
that.
> > +.. kernel-doc:: include/linux/dma-buf-map.h
> > + :internal:
> > +
> > Reservation Objects
> > ---
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index 58564d82a3a2..5e849ca241a0 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -1207,12 +1207,12 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
> > mutex_lock(&dmabuf->lock);
> > if (dmabuf->vmapping_counter) {
> > dmabuf->vmapping_counter++;
> > - BUG_ON(!dmabuf->vmap_ptr);
> > - ptr = dmabuf->vmap_ptr;
> > + BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
> > + ptr = dmabuf->vmap_ptr.vaddr;
> > goto out_unlock;
> > }
> > - BUG_ON(dmabuf->vmap_ptr);
> > + BUG_ON(dma_buf_map_is_set(&dmabuf->vmap_ptr));
> > ptr = dmabuf->ops->vmap(dmabuf);
> > if (WARN_ON_ONCE(IS_ERR(ptr)))
> > @@ -1220,7 +1220,7 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
> > if (!ptr)
> > goto out_unlock;
> > - dmabuf->vmap_ptr = ptr;
> > + dmabuf->vmap_ptr.vaddr = ptr;
> > dmabuf->vmapping_counter = 1;
> > out_unlock:
> > @@ -1239,15 +1239,15 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void
> > *vaddr)
> > if (WARN_ON(!dmabuf))
> > return;
> > - BUG_ON(!dmabuf->vmap_ptr);
> > + BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
> > BUG_ON(dmabuf->vmapping_counter == 0);
> > - BUG_ON(dmabuf->vmap_ptr != vaddr);
> > + BUG_ON(!dma_buf_map_is_vaddr(&dmabuf->vmap_ptr, vaddr));
> > mutex_lock(&dmabuf->lock);
> > if (--dmabuf->vmapping_counter == 0) {
> > if (dmabuf->ops->vunmap)
> > dmabuf->ops->vunmap(dmabuf, vaddr);
> > - dmabuf->vmap_ptr = NULL;
> > + dma_buf_map_clear(&dmabuf->vmap_ptr);
> > }
> > mutex_unlock(&dmabuf->lock);
> > }
> > diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
> > new file mode 100644
> > index ..d4b1bb3cc4b0
> > --- /dev/null
> > +++ b/include/linux/dma-buf-map.h
> > @@ -0,0 +1,87 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * Pointer to dma-buf-mapped memory, plus helpers.
> > + */
> > +
> > +#ifndef __DMA_BUF_MAP_H__
> > +#define __DMA_BUF_MAP_H__
> > +
> > +#include
> > +
> > +/**
> > + * struct dma_buf_map - Pointer to vmap'ed dma-buf memory.
> > + * @vaddr_iomem: The buffer's address if in I/O memory
> > + * @vaddr: The buffer's address if in system memory
> > + * @is_iomem: True if the dma-buf memory is located in I/O
> > + * memory, or false otherwise.
> > + *
> > + * Calling dma-buf's vmap operation returns a point
[Intel-gfx] ✗ Fi.CI.IGT: failure for Gen12 HDCP 1.4 support on DP MST (rev2)
== Series Details == Series: Gen12 HDCP 1.4 support on DP MST (rev2) URL : https://patchwork.freedesktop.org/series/81289/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9042_full -> Patchwork_18554_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18554_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18554_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18554_full: ### IGT changes ### Possible regressions * igt@i915_pm_backlight@fade_with_suspend: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl4/igt@i915_pm_backlight@fade_with_suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18554/shard-skl1/igt@i915_pm_backlight@fade_with_suspend.html * igt@kms_cursor_legacy@cursora-vs-flipa-toggle: - shard-hsw: NOTRUN -> [INCOMPLETE][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18554/shard-hsw7/igt@kms_cursor_leg...@cursora-vs-flipa-toggle.html * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-indfb-pgflip-blt: - shard-glk: [PASS][4] -> [INCOMPLETE][5] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-glk4/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-indfb-pgflip-blt.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18554/shard-glk4/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-indfb-pgflip-blt.html Known issues Here are the changes found in Patchwork_18554_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@processes: - shard-skl: [PASS][6] -> [FAIL][7] ([i915#2376]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl8/igt@gem_ctx_persiste...@processes.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18554/shard-skl7/igt@gem_ctx_persiste...@processes.html * igt@gem_exec_reloc@basic-many-active@rcs0: - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2389]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-glk3/igt@gem_exec_reloc@basic-many-act...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18554/shard-glk7/igt@gem_exec_reloc@basic-many-act...@rcs0.html * igt@gem_exec_whisper@basic-queues-priority: - shard-glk: [PASS][10] -> [DMESG-WARN][11] ([i915#118] / [i915#95]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-glk4/igt@gem_exec_whis...@basic-queues-priority.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18554/shard-glk4/igt@gem_exec_whis...@basic-queues-priority.html * igt@gem_userptr_blits@unsync-unmap-cycles: - shard-skl: [PASS][12] -> [TIMEOUT][13] ([i915#1958]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl2/igt@gem_userptr_bl...@unsync-unmap-cycles.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18554/shard-skl5/igt@gem_userptr_bl...@unsync-unmap-cycles.html * igt@i915_selftest@mock@contexts: - shard-skl: [PASS][14] -> [INCOMPLETE][15] ([i915#198] / [i915#2278]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl5/igt@i915_selftest@m...@contexts.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18554/shard-skl6/igt@i915_selftest@m...@contexts.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - shard-apl: [PASS][16] -> [DMESG-WARN][17] ([i915#1635] / [i915#1982]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-apl8/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18554/shard-apl8/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_cursor_legacy@cursor-vs-flip-toggle: - shard-hsw: [PASS][18] -> [FAIL][19] ([i915#2370]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-hsw7/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18554/shard-hsw1/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html * igt@kms_flip@flip-vs-suspend@c-dp1: - shard-kbl: [PASS][20] -> [DMESG-WARN][21] ([i915#180]) +3 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-kbl6/igt@kms_flip@flip-vs-susp...@c-dp1.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18554/shard-kbl7/igt@kms_flip@flip-vs-susp...@c-dp1.html * igt@kms_flip@plain-flip-ts-check-interruptible@c-edp1: - shard-skl:
[Intel-gfx] [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY
When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
pull in arbitrary other resources, including CRTCs (e.g. when
reconfiguring global resources).
But in nonblocking mode userspace has then no idea this happened,
which can lead to spurious EBUSY calls, both:
- when that other CRTC is currently busy doing a page_flip the
ALLOW_MODESET commit can fail with an EBUSY
- on the other CRTC a normal atomic flip can fail with EBUSY because
of the additional commit inserted by the kernel without userspace's
knowledge
For blocking commits this isn't a problem, because everyone else will
just block until all the CRTC are reconfigured. Only thing userspace
can notice is the dropped frames without any reason for why frames got
dropped.
Consensus is that we need new uapi to handle this properly, but no one
has any idea what exactly the new uapi should look like. Since this
has been shipping for years already compositors need to deal no matter
what, so as a first step just try to enforce this across drivers
better with some checks.
v2: Add comments and a WARN_ON to enforce this only when allowed - we
don't want to silently convert page flips into blocking plane updates
just because the driver is buggy.
v3: Fix inverted WARN_ON (Pekka).
v4: Drop the uapi changes, only add a WARN_ON for now to enforce some
rules for drivers.
v5: Make the WARNING more informative (Daniel)
v6: Add unconditional debug output for compositor hackers to figure
out what's going on when they get an EBUSY (Daniel)
References:
https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
Cc: Daniel Stone
Cc: Pekka Paalanen
Cc: Simon Ser
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 58527f151984..f1a912e80846 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -281,6 +281,10 @@ EXPORT_SYMBOL(__drm_atomic_state_free);
* needed. It will also grab the relevant CRTC lock to make sure that the state
* is consistent.
*
+ * WARNING: Drivers may only add new CRTC states to a @state if
+ * drm_atomic_state.allow_modeset is set, or if it's a driver-internal commit
+ * not created by userspace through an IOCTL call.
+ *
* Returns:
*
* Either the allocated state or the error code encoded into the pointer. When
@@ -1262,10 +1266,15 @@ int drm_atomic_check_only(struct drm_atomic_state
*state)
struct drm_crtc_state *new_crtc_state;
struct drm_connector *conn;
struct drm_connector_state *conn_state;
+ unsigned requested_crtc = 0;
+ unsigned affected_crtc = 0;
int i, ret = 0;
DRM_DEBUG_ATOMIC("checking %p\n", state);
+ for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
+ requested_crtc |= drm_crtc_mask(crtc);
+
for_each_oldnew_plane_in_state(state, plane, old_plane_state,
new_plane_state, i) {
ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
if (ret) {
@@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
}
}
+ for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
+ affected_crtc |= drm_crtc_mask(crtc);
+
+ /*
+* For commits that allow modesets drivers can add other CRTCs to the
+* atomic commit, e.g. when they need to reallocate global resources.
+* This can cause spurious EBUSY, which robs compositors of a very
+* effective sanity check for their drawing loop. Therefor only allow
+* drivers to add unrelated CRTC states for modeset commits.
+*
+* FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an output
+* so compositors know what's going on.
+*/
+ if (affected_crtc != requested_crtc) {
+ DRM_DEBUG_ATOMIC("driver added CRTC to commit: requested 0x%x,
affected 0x%0x\n",
+requested_crtc, affected_crtc);
+ WARN(!state->allow_modeset, "adding CRTC not allowed without
modesets: requested 0x%x, affected 0x%0x\n",
+requested_crtc, affected_crtc);
+ }
+
return 0;
}
EXPORT_SYMBOL(drm_atomic_check_only);
--
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 02/11] drm/i915: Remove hw.mode
Hi Ville, So to confirm I am skipping this patch completely. So basically keeping hw.mode as well Manasi On Tue, Sep 22, 2020 at 11:52:09AM -0700, Navare, Manasi wrote: > On Tue, Sep 22, 2020 at 01:19:15PM +0300, Ville Syrjälä wrote: > > On Mon, Sep 21, 2020 at 02:01:25PM -0700, Navare, Manasi wrote: > > > On Mon, Sep 14, 2020 at 09:52:57PM +0300, Ville Syrjälä wrote: > > > > 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. > > > > > > Hi Ville, > > > > > > So this patch basically removes the hw.mode and just keeps > > > hw.adjusted_mode > > > So no need to remove that? > > > But basically from this patch onwards we say that there is hw.pipe_mode > > > and hw.adjusted_mode, there is no hw.mode. > > > Are you suggesting keeping hw.mode as well? Would this be replacing > > > hw.pipe_mode then? > > > > No. hw.mode is the original timings, adjusted_mode is the output timings, > > pipe_mode is the the pipe timings. > > So is the suggestion to keep hw.mode so the original timings as well as > adjusted_mode and > then have pipe_mode for per pipe timings. > So get rid of this patch meaning do not remove hw.mode? > > Manasi > > > > > -- > > Ville Syrjälä > > Intel > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for HDCP misc (rev4)
== Series Details ==
Series: HDCP misc (rev4)
URL : https://patchwork.freedesktop.org/series/73345/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9043 -> Patchwork_18557
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18557/index.html
Known issues
Here are the changes found in Patchwork_18557 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_9043/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18557/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.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_9043/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18557/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +2 similar
issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/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_18557/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
Possible fixes
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18557/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
* igt@kms_flip@basic-plain-flip@d-dsi1:
- {fi-tgl-dsi}: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10] +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-tgl-dsi/igt@kms_flip@basic-plain-f...@d-dsi1.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18557/fi-tgl-dsi/igt@kms_flip@basic-plain-f...@d-dsi1.html
* igt@vgem_basic@setversion:
- 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_9043/fi-tgl-y/igt@vgem_ba...@setversion.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18557/fi-tgl-y/igt@vgem_ba...@setversion.html
* igt@vgem_basic@unload:
- fi-skl-guc: [DMESG-WARN][13] ([i915#2203]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-skl-guc/igt@vgem_ba...@unload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18557/fi-skl-guc/igt@vgem_ba...@unload.html
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-kbl-x1275/igt@vgem_ba...@unload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18557/fi-kbl-x1275/igt@vgem_ba...@unload.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-tgl-y: [DMESG-WARN][17] ([i915#2411]) -> [DMESG-WARN][18]
([i915#1982] / [i915#2411])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-tgl-y/igt@i915_pm_...@module-reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18557/fi-tgl-y/igt@i915_pm_...@module-reload.html
- fi-kbl-x1275: [DMESG-FAIL][19] ([i915#62] / [i915#95]) ->
[DMESG-FAIL][20] ([i915#62])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18557/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
- fi-skl-guc: [INCOMPLETE][21] ([i915#151] / [i915#2203]) ->
[DMESG-WARN][22] ([i915#2203])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-skl-guc/igt@i915_pm_...@module-reload.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18557/fi-skl-guc/igt@i915_pm_...@module-reload.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][24] ([i915#62] / [i915#92]) +7 similar issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18557/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-x1275: [DMESG-WARN][25] ([i915#62] / [i915#92]) ->
[DMESG-WARN][26] ([i915#62] / [i915#92] / [i
Re: [Intel-gfx] [PATCH 4/6] drm/i915: use vmap in i915_gem_object_map
On Wed, Sep 23, 2020 at 02:58:43PM +0100, Tvrtko Ursulin wrote: >>> Series did not get a CI run from our side because of a different base so I >>> don't know if you would like to have a run there? If so you would need to >>> rebase against git://anongit.freedesktop.org/drm-tip drm-tip and you could >>> even send a series to intel-gfx-try...@lists.freedesktop.org, suppressing >>> cc, to check it out without sending a copy to the real mailing list. >> >> It doesn't seem like I can post to any freedesktop list, as I always >> get rejection messages. But I'll happily prepare a branch if one >> of you an feed it into your CI. > > That's fine, just ping me and I will forward it for testing, thanks! git://git.infradead.org/users/hch/misc.git i915-vmap-wip Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/i915-vmap-wip note that this includes a new commit to clean up one of the recent commits in the code. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 00/22] Convert all remaining drivers to GEM object functions
Feel free to add an Acked-by: Christian König to all patches which I haven't explicitly reviewed. I would say we should just push this to drm-misc-next now. Thanks for the nice cleanup, Christian. Am 23.09.20 um 12:21 schrieb Thomas Zimmermann: The GEM and PRIME related callbacks in struct drm_driver are deprecated in favor of GEM object functions in struct drm_gem_object_funcs. This patchset converts the remaining drivers to object functions and removes most of the obsolete interfaces. Version 3 of this patchset mostly fixes drm_gem_prime_handle_to_fd and updates i.MX's dcss driver. The driver was missing from earlier versions and still needs review. Patches #1 to #6, #8 to #17 and #19 to #20 convert DRM drivers to GEM object functions, one by one. Each patch moves existing callbacks from struct drm_driver to an instance of struct drm_gem_object_funcs, and sets these funcs when the GEM object is initialized. The expection is .gem_prime_mmap. There are different ways of how drivers implement the callback, and moving it to GEM object functions requires a closer review for each. Patch #18 fixes virtgpu to use GEM object functions where possible. The driver recently introduced a function for one of the deprecated callbacks. Patches #7 and #20 convert i.MX's dcss and xlnx to CMA helper macros. There's no apparent reason why the drivers do the GEM setup on their's own. Using CMA helper macros adds GEM object functions implicitly. With most of the GEM and PRIME moved to GEM object functions, related code in struct drm_driver and in the DRM core/helpers is being removed by patch #22. Further testing is welcome. I tested the drivers for which I have HW available. These are gma500, i915, nouveau, radeon and vc4. The console, Weston and Xorg apparently work with the patches applied. v3: * restore default call to drm_gem_prime_export() in drm_gem_prime_handle_to_fd() * return -ENOSYS if get_sg_table is not set * drop all checks for obj->funcs * clean up TODO list and documentation v2: * moved code in amdgpu and radeon * made several functions static in various drivers * updated TODO-list item * fix virtgpu Thomas Zimmermann (22): drm/amdgpu: Introduce GEM object functions drm/armada: Introduce GEM object functions drm/etnaviv: Introduce GEM object functions drm/exynos: Introduce GEM object functions drm/gma500: Introduce GEM object functions drm/i915: Introduce GEM object functions drm/imx/dcss: Initialize DRM driver instance with CMA helper macro drm/mediatek: Introduce GEM object functions drm/msm: Introduce GEM object funcs drm/nouveau: Introduce GEM object functions drm/omapdrm: Introduce GEM object functions drm/pl111: Introduce GEM object functions drm/radeon: Introduce GEM object functions drm/rockchip: Convert to drm_gem_object_funcs drm/tegra: Introduce GEM object functions drm/vc4: Introduce GEM object functions drm/vgem: Introduce GEM object functions drm/virtgpu: Set PRIME export function in struct drm_gem_object_funcs drm/vkms: Introduce GEM object functions drm/xen: Introduce GEM object functions drm/xlnx: Initialize DRM driver instance with CMA helper macro drm: Remove obsolete GEM and PRIME callbacks from struct drm_driver Documentation/gpu/drm-mm.rst | 4 +- Documentation/gpu/todo.rst| 9 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 -- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 23 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h | 5 -- drivers/gpu/drm/armada/armada_drv.c | 3 - drivers/gpu/drm/armada/armada_gem.c | 12 ++- drivers/gpu/drm/armada/armada_gem.h | 2 - drivers/gpu/drm/drm_gem.c | 53 drivers/gpu/drm/drm_gem_cma_helper.c | 8 +- drivers/gpu/drm/drm_prime.c | 14 +-- drivers/gpu/drm/etnaviv/etnaviv_drv.c | 13 --- drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 - drivers/gpu/drm/etnaviv/etnaviv_gem.c | 19 - drivers/gpu/drm/exynos/exynos_drm_drv.c | 10 --- drivers/gpu/drm/exynos/exynos_drm_gem.c | 15 drivers/gpu/drm/gma500/framebuffer.c | 2 + drivers/gpu/drm/gma500/gem.c | 18 +++- drivers/gpu/drm/gma500/gem.h | 3 + drivers/gpu/drm/gma500/psb_drv.c | 9 -- drivers/gpu/drm/gma500/psb_drv.h | 2 - drivers/gpu/drm/i915/gem/i915_gem_object.c| 21 - drivers/gpu/drm/i915/gem/i915_gem_object.h| 3 - drivers/gpu/drm/i915/i915_drv.c | 4 - .../gpu/drm/i915/selftests/mock_gem_device.c | 3 - drivers/gpu/drm/imx/dcss/dcss-kms.c | 14 +-- drivers/gpu/drm/mediatek/mtk_drm_drv.c| 5 -- drivers/gpu/drm/mediatek/mtk_drm_gem.c| 11 +++ drivers/gpu/drm/msm/msm_drv.c | 13 --- drivers/gp
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/atomic: document and enforce rules around "spurious" EBUSY
== Series Details == Series: series starting with [1/2] drm/atomic: document and enforce rules around "spurious" EBUSY URL : https://patchwork.freedesktop.org/series/82023/ State : success == Summary == CI Bug Log - changes from CI_DRM_9042_full -> Patchwork_18553_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18553_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-mixed-process@render: - shard-apl: [PASS][1] -> [FAIL][2] ([i915#1635] / [i915#2374]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-apl7/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@render.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-apl1/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@render.html * igt@gem_exec_suspend@basic-s4-devices: - shard-hsw: [PASS][3] -> [INCOMPLETE][4] ([i915#1888]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-hsw2/igt@gem_exec_susp...@basic-s4-devices.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-hsw4/igt@gem_exec_susp...@basic-s4-devices.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-kbl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-kbl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_flip@flip-vs-expired-vblank@c-edp1: - shard-skl: [PASS][7] -> [FAIL][8] ([i915#79]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl5/igt@kms_flip@flip-vs-expired-vbl...@c-edp1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-skl7/igt@kms_flip@flip-vs-expired-vbl...@c-edp1.html * igt@kms_flip@flip-vs-suspend-interruptible@c-hdmi-a1: - shard-hsw: [PASS][9] -> [INCOMPLETE][10] ([i915#2055]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-hsw2/igt@kms_flip@flip-vs-suspend-interrupti...@c-hdmi-a1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-hsw6/igt@kms_flip@flip-vs-suspend-interrupti...@c-hdmi-a1.html * igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-render: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-kbl1/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-render.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-kbl6/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-render.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw: - shard-tglb: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-tglb8/igt@kms_frontbuffer_track...@fbcpsr-1p-pri-indfb-multidraw.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-tglb5/igt@kms_frontbuffer_track...@fbcpsr-1p-pri-indfb-multidraw.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#49]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-iclb3/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-wc: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#49]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl3/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-mmap-wc.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-skl4/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-mmap-wc.html * igt@kms_hdr@bpc-switch-suspend: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#1188]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl10/igt@kms_...@bpc-switch-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-skl10/igt@kms_...@bpc-switch-suspend.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-iclb: [PASS][21] -> [INCOMPLETE][22] ([i915#1185]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-iclb5/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-iclb3/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][2
Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
On Mon, Sep 21 2020 at 21:27, Thomas Gleixner wrote: > On Mon, Sep 21 2020 at 09:24, Linus Torvalds wrote: >> On Mon, Sep 21, 2020 at 12:39 AM Thomas Gleixner wrote: >> Maybe we really *could* call this new kmap functionality something >> like "kmap_percpu()" (or maybe "local" is good enough), and make it >> act like your RT code does for spinlocks - not disable preemption, but >> only disabling CPU migration. > > I"m all for it, but the scheduler people have opinions :) I just took the latest version of migrate disable patches https://lore.kernel.org/r/20200921163557.234036...@infradead.org removed the RT dependency on top of them and adopted the kmap stuff (addressing the various comments while at it and unbreaking ARM). I'm not going to post that until there is consensus about the general availability of migrate disable, but for those who want to play with it I've pushed the resulting combo out to: git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git highmem For testing I've tweaked a few places to use the new _local() variants and it survived testing so far and I've verified that there is actual preemption which means zap/restore of the thread local kmaps. Thanks, tglx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/3] dma-buf: Use struct dma_buf_map in dma_buf_vmap() interfaces
Am 23.09.20 um 14:32 schrieb Thomas Zimmermann:
This patch updates dma_buf_vmap() and dma-buf's vmap callback to use
struct dma_buf_map.
The interfaces used to return a buffer address. This address now gets
stored in an instance of the structure that is given as an additional
argument. The functions return an errno code on errors.
Users of the functions are updated accordingly. This is only an interface
change. It is currently expected that dma-buf memory can be accessed with
system memory load/store operations.
v2:
* always clear map parameter in dma_buf_vmap() (Daniel)
* include dma-buf-heaps and i915 selftests (kernel test robot)
Signed-off-by: Thomas Zimmermann
Acked-by: Sumit Semwal
Acked-by: Christian König for this one and #3.
---
drivers/dma-buf/dma-buf.c | 28 +++
drivers/dma-buf/heaps/heap-helpers.c | 8 --
drivers/gpu/drm/drm_gem_cma_helper.c | 13 +
drivers/gpu/drm/drm_gem_shmem_helper.c| 14 ++
drivers/gpu/drm/drm_prime.c | 8 --
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 8 +-
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 11 ++--
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 12 ++--
.../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 10 +--
drivers/gpu/drm/tegra/gem.c | 18
.../common/videobuf2/videobuf2-dma-contig.c | 14 +++---
.../media/common/videobuf2/videobuf2-dma-sg.c | 16 +++
.../common/videobuf2/videobuf2-vmalloc.c | 15 +++---
include/drm/drm_prime.h | 3 +-
include/linux/dma-buf-map.h | 13 +
include/linux/dma-buf.h | 6 ++--
16 files changed, 138 insertions(+), 59 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 5e849ca241a0..61bd24d21b38 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1186,46 +1186,50 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
* dma_buf_vmap - Create virtual mapping for the buffer object into kernel
* address space. Same restrictions as for vmap and friends apply.
* @dmabuf: [in]buffer to vmap
+ * @map: [out] returns the vmap pointer
*
* This call may fail due to lack of virtual mapping address space.
* These calls are optional in drivers. The intended use for them
* is for mapping objects linear in kernel space for high use objects.
* Please attempt to use kmap/kunmap before thinking about these interfaces.
*
- * Returns NULL on error.
+ * Returns 0 on success, or a negative errno code otherwise.
*/
-void *dma_buf_vmap(struct dma_buf *dmabuf)
+int dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map *map)
{
- void *ptr;
+ struct dma_buf_map ptr;
+ int ret = 0;
+
+ dma_buf_map_clear(map);
if (WARN_ON(!dmabuf))
- return NULL;
+ return -EINVAL;
if (!dmabuf->ops->vmap)
- return NULL;
+ return -EINVAL;
mutex_lock(&dmabuf->lock);
if (dmabuf->vmapping_counter) {
dmabuf->vmapping_counter++;
BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
- ptr = dmabuf->vmap_ptr.vaddr;
+ *map = dmabuf->vmap_ptr;
goto out_unlock;
}
BUG_ON(dma_buf_map_is_set(&dmabuf->vmap_ptr));
- ptr = dmabuf->ops->vmap(dmabuf);
- if (WARN_ON_ONCE(IS_ERR(ptr)))
- ptr = NULL;
- if (!ptr)
+ ret = dmabuf->ops->vmap(dmabuf, &ptr);
+ if (WARN_ON_ONCE(ret))
goto out_unlock;
- dmabuf->vmap_ptr.vaddr = ptr;
+ dmabuf->vmap_ptr = ptr;
dmabuf->vmapping_counter = 1;
+ *map = dmabuf->vmap_ptr;
+
out_unlock:
mutex_unlock(&dmabuf->lock);
- return ptr;
+ return ret;
}
EXPORT_SYMBOL_GPL(dma_buf_vmap);
diff --git a/drivers/dma-buf/heaps/heap-helpers.c b/drivers/dma-buf/heaps/heap-helpers.c
index d0696cf937af..aeb9e100f339 100644
--- a/drivers/dma-buf/heaps/heap-helpers.c
+++ b/drivers/dma-buf/heaps/heap-helpers.c
@@ -235,7 +235,7 @@ static int dma_heap_dma_buf_end_cpu_access(struct dma_buf
*dmabuf,
return 0;
}
-static void *dma_heap_dma_buf_vmap(struct dma_buf *dmabuf)
+static int dma_heap_dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map
*map)
{
struct heap_helper_buffer *buffer = dmabuf->priv;
void *vaddr;
@@ -244,7 +244,11 @@ static void *dma_heap_dma_buf_vmap(struct dma_buf *dmabuf)
vaddr = dma_heap_buffer_vmap_get(buffer);
mutex_unlock(&buffer->lock);
- return vaddr;
+ if (!vaddr)
+ return -ENOMEM;
+ dma_buf_map_set_vaddr(map, vaddr);
+
+ return 0;
}
static void dma_heap_dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
i
Re: [Intel-gfx] [PATCH v2 1/3] dma-buf: Add struct dma-buf-map for storing struct dma_buf.vaddr_ptr
Am 23.09.20 um 14:32 schrieb Thomas Zimmermann:
The new type struct dma_buf_map represents a mapping of dma-buf memory
into kernel space. It contains a flag, is_iomem, that signals users to
access the mapped memory with I/O operations instead of regular loads
and stores.
It was assumed that DMA buffer memory can be accessed with regular load
and store operations. Some architectures, such as sparc64, require the
use of I/O operations to access dma-map buffers that are located in I/O
memory. Providing struct dma_buf_map allows drivers to implement this.
This was specifically a problem when refreshing the graphics framebuffer
on such systems. [1]
As the first step, struct dma_buf stores an instance of struct dma_buf_map
internally. Afterwards, dma-buf's vmap and vunmap interfaces are be
converted. Finally, affected drivers can be fixed.
[1]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20200725191012.GA434957%40ravnborg.org%2F&data=02%7C01%7Cchristian.koenig%40amd.com%7C54486b9682654f3950b808d85fbcb1d3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637364611338153209&sdata=%2BZm7t8OcgkIxnY%2FdZSLhSbKC7t1y4VW5lINFKwCQv3A%3D&reserved=0
Only two nit picks below, apart from that Reviewed-by: Christian König
Signed-off-by: Thomas Zimmermann
Acked-by: Sumit Semwal
---
Documentation/driver-api/dma-buf.rst | 3 +
drivers/dma-buf/dma-buf.c| 14 ++---
include/linux/dma-buf-map.h | 87
include/linux/dma-buf.h | 3 +-
4 files changed, 99 insertions(+), 8 deletions(-)
create mode 100644 include/linux/dma-buf-map.h
diff --git a/Documentation/driver-api/dma-buf.rst
b/Documentation/driver-api/dma-buf.rst
index 13ea0cc0a3fa..3244c600a9a1 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -115,6 +115,9 @@ Kernel Functions and Structures Reference
.. kernel-doc:: include/linux/dma-buf.h
:internal:
+.. kernel-doc:: include/linux/dma-buf-map.h
+ :internal:
+
Reservation Objects
---
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 58564d82a3a2..5e849ca241a0 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1207,12 +1207,12 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
mutex_lock(&dmabuf->lock);
if (dmabuf->vmapping_counter) {
dmabuf->vmapping_counter++;
- BUG_ON(!dmabuf->vmap_ptr);
- ptr = dmabuf->vmap_ptr;
+ BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
+ ptr = dmabuf->vmap_ptr.vaddr;
goto out_unlock;
}
- BUG_ON(dmabuf->vmap_ptr);
+ BUG_ON(dma_buf_map_is_set(&dmabuf->vmap_ptr));
ptr = dmabuf->ops->vmap(dmabuf);
if (WARN_ON_ONCE(IS_ERR(ptr)))
@@ -1220,7 +1220,7 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
if (!ptr)
goto out_unlock;
- dmabuf->vmap_ptr = ptr;
+ dmabuf->vmap_ptr.vaddr = ptr;
dmabuf->vmapping_counter = 1;
out_unlock:
@@ -1239,15 +1239,15 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
if (WARN_ON(!dmabuf))
return;
- BUG_ON(!dmabuf->vmap_ptr);
+ BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
BUG_ON(dmabuf->vmapping_counter == 0);
- BUG_ON(dmabuf->vmap_ptr != vaddr);
+ BUG_ON(!dma_buf_map_is_vaddr(&dmabuf->vmap_ptr, vaddr));
mutex_lock(&dmabuf->lock);
if (--dmabuf->vmapping_counter == 0) {
if (dmabuf->ops->vunmap)
dmabuf->ops->vunmap(dmabuf, vaddr);
- dmabuf->vmap_ptr = NULL;
+ dma_buf_map_clear(&dmabuf->vmap_ptr);
}
mutex_unlock(&dmabuf->lock);
}
diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
new file mode 100644
index ..d4b1bb3cc4b0
--- /dev/null
+++ b/include/linux/dma-buf-map.h
@@ -0,0 +1,87 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Pointer to dma-buf-mapped memory, plus helpers.
+ */
+
+#ifndef __DMA_BUF_MAP_H__
+#define __DMA_BUF_MAP_H__
+
+#include
+
+/**
+ * struct dma_buf_map - Pointer to vmap'ed dma-buf memory.
+ * @vaddr_iomem: The buffer's address if in I/O memory
+ * @vaddr: The buffer's address if in system memory
+ * @is_iomem: True if the dma-buf memory is located in I/O
+ * memory, or false otherwise.
+ *
+ * Calling dma-buf's vmap operation returns a pointer to the buffer.
+ * Depending on the location of the buffer, users may have to access it
+ * with I/O operations or memory load/store operations. struct dma_buf_map
+ * stores the buffer address and a flag that signals the required access.
+ */
+struct dma_buf_map {
+ union {
+ void __iomem *vaddr_iomem;
+ void *vaddr;
+ };
+ bool is_iomem;
+};
+
+/* API transition helper */
+static inline bool
Re: [Intel-gfx] [PATCH 4/6] drm/i915: use vmap in i915_gem_object_map
On 23/09/2020 14:41, Christoph Hellwig wrote: On Wed, Sep 23, 2020 at 10:52:33AM +0100, Tvrtko Ursulin wrote: On 18/09/2020 17:37, Christoph Hellwig wrote: i915_gem_object_map implements fairly low-level vmap functionality in a driver. Split it into two helpers, one for remapping kernel memory which can use vmap, and one for I/O memory that uses vmap_pfn. The only practical difference is that alloc_vm_area prefeaults the vmalloc area PTEs, which doesn't seem to be required here for the kernel memory case (and could be added to vmap using a flag if actually required). Patch looks good to me. Series did not get a CI run from our side because of a different base so I don't know if you would like to have a run there? If so you would need to rebase against git://anongit.freedesktop.org/drm-tip drm-tip and you could even send a series to intel-gfx-try...@lists.freedesktop.org, suppressing cc, to check it out without sending a copy to the real mailing list. It doesn't seem like I can post to any freedesktop list, as I always get rejection messages. But I'll happily prepare a branch if one of you an feed it into your CI. That's fine, just ping me and I will forward it for testing, thanks! Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for dma-buf: Flag vmap'ed memory as system or I/O memory (rev2)
== Series Details ==
Series: dma-buf: Flag vmap'ed memory as system or I/O memory (rev2)
URL : https://patchwork.freedesktop.org/series/81647/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9042 -> Patchwork_18556
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18556/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18556:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gt_pm:
- {fi-kbl-7560u}: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-kbl-7560u/igt@i915_selftest@live@gt_pm.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18556/fi-kbl-7560u/igt@i915_selftest@live@gt_pm.html
Known issues
Here are the changes found in Patchwork_18556 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18556/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
* igt@vgem_basic@sysfs:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-tgl-y/igt@vgem_ba...@sysfs.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18556/fi-tgl-y/igt@vgem_ba...@sysfs.html
* igt@vgem_basic@unload:
- fi-skl-guc: [PASS][7] -> [DMESG-WARN][8] ([i915#2203])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-skl-guc/igt@vgem_ba...@unload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18556/fi-skl-guc/igt@vgem_ba...@unload.html
Possible fixes
* igt@gem_huc_copy@huc-copy:
- fi-tgl-y: [DMESG-WARN][9] ([i915#402]) -> [PASS][10] +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-tgl-y/igt@gem_huc_c...@huc-copy.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18556/fi-tgl-y/igt@gem_huc_c...@huc-copy.html
* igt@i915_module_load@reload:
- {fi-tgl-dsi}: [DMESG-WARN][11] ([i915#1982] / [k.org#205379]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-tgl-dsi/igt@i915_module_l...@reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18556/fi-tgl-dsi/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@execlists:
- {fi-tgl-dsi}: [INCOMPLETE][13] ([i915#2268]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18556/fi-tgl-dsi/igt@i915_selftest@l...@execlists.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_9042/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18556/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18556/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@vgem_basic@unload:
- 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_9042/fi-kbl-x1275/igt@vgem_ba...@unload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18556/fi-kbl-x1275/igt@vgem_ba...@unload.html
Warnings
* igt@i915_pm_rpm@module-reload:
- 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_9042/fi-tgl-y/igt@i915_pm_...@module-reload.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18556/fi-tgl-y/igt@i915_pm_...@module-reload.html
- fi-kbl-guc: [DMESG-FAIL][23] ([i915#2203]) -> [DMESG-WARN][24]
([i915#2203])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-kbl-guc/igt@i915_pm_...@module-reload.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18556
[Intel-gfx] ✓ Fi.CI.IGT: success for Convert all remaining drivers to GEM object functions (rev3)
== Series Details == Series: Convert all remaining drivers to GEM object functions (rev3) URL : https://patchwork.freedesktop.org/series/80593/ State : success == Summary == CI Bug Log - changes from CI_DRM_9042_full -> Patchwork_18552_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18552_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_reloc@basic-many-active@rcs0: - shard-glk: [PASS][1] -> [FAIL][2] ([i915#2389]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-glk3/igt@gem_exec_reloc@basic-many-act...@rcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18552/shard-glk2/igt@gem_exec_reloc@basic-many-act...@rcs0.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_9042/shard-skl2/igt@gem_userptr_bl...@unsync-unmap-cycles.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18552/shard-skl6/igt@gem_userptr_bl...@unsync-unmap-cycles.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][5] -> [DMESG-WARN][6] ([i915#1436] / [i915#716]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl5/igt@gen9_exec_pa...@allowed-single.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18552/shard-skl9/igt@gen9_exec_pa...@allowed-single.html * igt@kms_draw_crc@draw-method-rgb565-mmap-cpu-ytiled: - shard-skl: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +6 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl2/igt@kms_draw_...@draw-method-rgb565-mmap-cpu-ytiled.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18552/shard-skl6/igt@kms_draw_...@draw-method-rgb565-mmap-cpu-ytiled.html * igt@kms_draw_crc@draw-method-rgb565-pwrite-untiled: - shard-skl: [PASS][9] -> [FAIL][10] ([i915#177] / [i915#52] / [i915#54]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl3/igt@kms_draw_...@draw-method-rgb565-pwrite-untiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18552/shard-skl3/igt@kms_draw_...@draw-method-rgb565-pwrite-untiled.html * igt@kms_flip@flip-vs-suspend@b-dp1: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-kbl6/igt@kms_flip@flip-vs-susp...@b-dp1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18552/shard-kbl1/igt@kms_flip@flip-vs-susp...@b-dp1.html * igt@kms_flip@plain-flip-ts-check-interruptible@b-edp1: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#2122]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl5/igt@kms_flip@plain-flip-ts-check-interrupti...@b-edp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18552/shard-skl9/igt@kms_flip@plain-flip-ts-check-interrupti...@b-edp1.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw: - shard-tglb: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-tglb8/igt@kms_frontbuffer_track...@fbcpsr-1p-pri-indfb-multidraw.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18552/shard-tglb8/igt@kms_frontbuffer_track...@fbcpsr-1p-pri-indfb-multidraw.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-wc: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#49]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl3/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-mmap-wc.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18552/shard-skl3/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-mmap-wc.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145] / [i915#265]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl6/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18552/shard-skl9/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_psr@psr2_no_drrs: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-iclb2/igt@kms_psr@psr2_no_drrs.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18552/shard-iclb7/igt@kms_psr@psr2_no_drrs.html * igt@kms_vblank@pipe-b-query-busy: - shard-apl: [PASS][23] -> [DMESG-WARN][24] ([i915#1635] / [i915#1982]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-apl8/igt@km
Re: [Intel-gfx] [PATCH 4/6] drm/i915: use vmap in i915_gem_object_map
On Wed, Sep 23, 2020 at 10:52:33AM +0100, Tvrtko Ursulin wrote: > > On 18/09/2020 17:37, Christoph Hellwig wrote: >> i915_gem_object_map implements fairly low-level vmap functionality in >> a driver. Split it into two helpers, one for remapping kernel memory >> which can use vmap, and one for I/O memory that uses vmap_pfn. >> >> The only practical difference is that alloc_vm_area prefeaults the >> vmalloc area PTEs, which doesn't seem to be required here for the >> kernel memory case (and could be added to vmap using a flag if actually >> required). > > Patch looks good to me. > > Series did not get a CI run from our side because of a different base so I > don't know if you would like to have a run there? If so you would need to > rebase against git://anongit.freedesktop.org/drm-tip drm-tip and you could > even send a series to intel-gfx-try...@lists.freedesktop.org, suppressing > cc, to check it out without sending a copy to the real mailing list. It doesn't seem like I can post to any freedesktop list, as I always get rejection messages. But I'll happily prepare a branch if one of you an feed it into your CI. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
On Wed, Sep 23 2020 at 10:40, peterz wrote: > Right, so I'm concerned. migrate_disable() wrecks pretty much all > Real-Time scheduler theory we have, and PREEMPRT_RT bringing it in is > somewhat ironic. It's even more ironic that the approach of PREEMPT_RT has been 'pragmatic ignorance of theory' from the very beginning and despite violating all theories it still works. :) > Yes, it allows breaking up non-preemptible regions of non-deterministic > duration, and thereby both reduce and bound the scheduling latency, the > cost for doing that is that the theory on CPU utilization/bandwidth go > out the window. I agree, that the theory goes out of the window, but does it matter in practice? I've yet to see a report of migrate disable stacking being the culprit of a missed deadline and I surely have stared at lots of reports in the past 10+ years. > To easily see this consider an SMP system with a number of tasks equal > to the number of CPUs. On a regular (preempt_disable) kernel we can > always run each task, by virtue of always having an idle CPU to take the > task. > > However, with migrate_disable() we can have each task preempted in a > migrate_disable() region, worse we can stack them all on the _same_ CPU > (super ridiculous odds, sure). And then we end up only able to run one > task, with the rest of the CPUs picking their nose. > > The end result is that, like with unbounded latency, we will still miss > our deadline, simply because we got starved for CPU. I'm well aware of that. > Now, while we could (with a _lot_ of work) rework the kernel to not rely > on the implicit per-cpu ness of things like spinlock_t, the moment we > bring in basic primitives that rely on migrate_disable() we're stuck > with it. Right, but we are stuck with per CPUness and distangling that is just infeasible IMO. > The problem is; afaict there's been no research into this problem. There is no research on a lot of things the kernel does :) > There might be scheduling (read: balancing) schemes that can > mitigate/solve this problem, or it might prove to be a 'hard' problem, > I just don't know. In practive balancing surely can take the number of preempted tasks which are in a migrate disable section into account which would be just another measure to work around the fact that the kernel is not adhering to the theories. It never did that even w/o migrate disable. > But once we start down this road, it's going to be hell to get rid of > it. Like most of the other things the kernel came up with to deal with the oddities of modern hardware :) > That's why I've been arguing (for many years) to strictly limit this to > PREEMPT_RT and only as a gap-stop, not a fundamental primitive to build > on. I know, but short of rewriting the world, I'm not seing the faintest plan to remove the stop gap. :) As we discussed not long ago we have too many inconsistent preemption models already. RT is adding yet another one. And that's worse than introducing migrate disable as a general available facility. IMO, reaching a point of consistency where our different preemption models (NONE, VOLUNTARY, PREEMPT. RT) build on each other is far more important. For !RT migrate disable is far less of an danger than for RT kernels because the amount of code which will use it is rather limited compared to code which still will disable preemption implicit through spin and rw locks. On RT converting these locks to 'sleepable spinlocks' is just possible because RT forces almost everything into task context and migrate disable is just the obvious decomposition of preempt disable which implicitely disables migration. But that means that RT is by orders of magnitude more prone to run into the scheduling trainwreck you are worried about. It just refuses to do so at least with real world work loads. I'm surely in favour of having solid theories behind implementation, but at some point you just have to bite the bullet and chose pragmatism in order to make progress. Proliferating inconsistency is not real progress, as it is violating the most fundamental engineering principles. That's by far more dangerous than violating scheduling theories which are built on perfect models and therefore enforce violation by practical implementations anyway. Thanks, tglx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/2] drm/i915: dont retry stream management at seq_num_m roll over
From: Ramalingam C
When roll over detected for seq_num_m, we shouldn't continue with stream
management with rolled over value.
So we are terminating the stream management retry, on roll over of the
seq_num_m.
v2:
using drm_dbg_kms instead of DRM_DEBUG_KMS [Anshuman]
v3:
dev_priv is used as i915 [JaniN]
v4:
roll over is detected at the start of the stream management.
Signed-off-by: Ramalingam C
Reviewed-by: Anshuman Gupta [v3]
Tested-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index d750bb57f252..b2a4bbcfdcd2 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1448,7 +1448,6 @@ static
int _hdcp2_propagate_stream_management_info(struct intel_connector *connector)
{
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
- struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = &connector->hdcp;
union {
struct hdcp2_rep_stream_manage stream_manage;
@@ -1457,6 +1456,9 @@ int _hdcp2_propagate_stream_management_info(struct
intel_connector *connector)
const struct intel_hdcp_shim *shim = hdcp->shim;
int ret;
+ if (connector->hdcp.seq_num_m > HDCP_2_2_SEQ_NUM_MAX)
+ return -ERANGE;
+
/* Prepare RepeaterAuth_Stream_Manage msg */
msgs.stream_manage.msg_id = HDCP_2_2_REP_STREAM_MANAGE;
drm_hdcp_cpu_to_be24(msgs.stream_manage.seq_num_m, hdcp->seq_num_m);
@@ -1485,10 +1487,6 @@ int _hdcp2_propagate_stream_management_info(struct
intel_connector *connector)
out:
hdcp->seq_num_m++;
- if (hdcp->seq_num_m > HDCP_2_2_SEQ_NUM_MAX) {
- drm_dbg_kms(&i915->drm, "seq_num_m roll over.\n");
- return -ERANGE;
- }
return ret;
}
@@ -1699,6 +1697,13 @@ hdcp2_propagate_stream_management_info(struct
intel_connector *connector)
if (!ret)
break;
+ /* Lets restart the auth incase of seq_num_m roll over */
+ if (connector->hdcp.seq_num_m > HDCP_2_2_SEQ_NUM_MAX) {
+ drm_dbg_kms(&i915->drm,
+ "seq_num_m roll over.(%d)\n", ret);
+ break;
+ }
+
drm_dbg_kms(&i915->drm,
"HDCP2 stream management %d of %d Failed.(%d)\n",
i + 1, tries, ret);
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/2] drm/i915: terminate reauth at stream management failure
From: Ramalingam C
As per the HDCP2.2 compliance test 1B-10 expectation, when stream
management for a repeater fails, we retry thrice and when it fails
in all retries, HDCP2.2 reauthentication aborted at kernel.
v2:
seq_num_m++ is extended for steam management failures too.[Anshuman]
v3:
use drm_dbg_kms instead of DRM_DEBUG_KMS [Anshuman]
v4:
dev_priv is used as i915 [JaniN]
v5:
Few improvisements are done [Sean]
Signed-off-by: Ramalingam C
Tested-by: Anshuman Gupta
Reviewed-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 76 ++-
1 file changed, 47 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 5492076d1ae0..d750bb57f252 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1445,7 +1445,7 @@ static int hdcp2_session_key_exchange(struct
intel_connector *connector)
}
static
-int hdcp2_propagate_stream_management_info(struct intel_connector *connector)
+int _hdcp2_propagate_stream_management_info(struct intel_connector *connector)
{
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct drm_i915_private *i915 = to_i915(connector->base.dev);
@@ -1472,28 +1472,25 @@ int hdcp2_propagate_stream_management_info(struct
intel_connector *connector)
ret = shim->write_2_2_msg(dig_port, &msgs.stream_manage,
sizeof(msgs.stream_manage));
if (ret < 0)
- return ret;
+ goto out;
ret = shim->read_2_2_msg(dig_port, HDCP_2_2_REP_STREAM_READY,
&msgs.stream_ready, sizeof(msgs.stream_ready));
if (ret < 0)
- return ret;
+ goto out;
hdcp->port_data.seq_num_m = hdcp->seq_num_m;
hdcp->port_data.streams[0].stream_type = hdcp->content_type;
-
ret = hdcp2_verify_mprime(connector, &msgs.stream_ready);
- if (ret < 0)
- return ret;
+out:
hdcp->seq_num_m++;
-
if (hdcp->seq_num_m > HDCP_2_2_SEQ_NUM_MAX) {
drm_dbg_kms(&i915->drm, "seq_num_m roll over.\n");
- return -1;
+ return -ERANGE;
}
- return 0;
+ return ret;
}
static
@@ -1564,17 +1561,6 @@ int hdcp2_authenticate_repeater_topology(struct
intel_connector *connector)
return 0;
}
-static int hdcp2_authenticate_repeater(struct intel_connector *connector)
-{
- int ret;
-
- ret = hdcp2_authenticate_repeater_topology(connector);
- if (ret < 0)
- return ret;
-
- return hdcp2_propagate_stream_management_info(connector);
-}
-
static int hdcp2_authenticate_sink(struct intel_connector *connector)
{
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
@@ -1611,7 +1597,7 @@ static int hdcp2_authenticate_sink(struct intel_connector
*connector)
}
if (hdcp->is_repeater) {
- ret = hdcp2_authenticate_repeater(connector);
+ ret = hdcp2_authenticate_repeater_topology(connector);
if (ret < 0) {
drm_dbg_kms(&i915->drm,
"Repeater Auth Failed. Err: %d\n", ret);
@@ -1619,11 +1605,6 @@ static int hdcp2_authenticate_sink(struct
intel_connector *connector)
}
}
- hdcp->port_data.streams[0].stream_type = hdcp->content_type;
- ret = hdcp2_authenticate_port(connector);
- if (ret < 0)
- return ret;
-
return ret;
}
@@ -1704,15 +1685,52 @@ static int hdcp2_disable_encryption(struct
intel_connector *connector)
return ret;
}
+static int
+hdcp2_propagate_stream_management_info(struct intel_connector *connector)
+{
+ struct drm_i915_private *i915 = to_i915(connector->base.dev);
+ int i, tries = 3, ret;
+
+ if (!connector->hdcp.is_repeater)
+ return 0;
+
+ for (i = 0; i < tries; i++) {
+ ret = _hdcp2_propagate_stream_management_info(connector);
+ if (!ret)
+ break;
+
+ drm_dbg_kms(&i915->drm,
+ "HDCP2 stream management %d of %d Failed.(%d)\n",
+ i + 1, tries, ret);
+ }
+
+ return ret;
+}
+
static int hdcp2_authenticate_and_encrypt(struct intel_connector *connector)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
+ struct intel_hdcp *hdcp = &connector->hdcp;
int ret, i, tries = 3;
for (i = 0; i < tries; i++) {
ret = hdcp2_authenticate_sink(connector);
- if (!ret)
- break;
+ if (!ret) {
+ ret = hdcp2_propagate_stream_management_info(connector);
+ if (ret) {
+ drm_dbg_kms
[Intel-gfx] [PATCH v4 0/2] HDCP misc
Rebased of a older series which has been pending to merge. original series : https://patchwork.freedesktop.org/series/73345/ Ramalingam C (2): drm/i915: terminate reauth at stream management failure drm/i915: dont retry stream management at seq_num_m roll over drivers/gpu/drm/i915/display/intel_hdcp.c | 89 ++- 1 file changed, 56 insertions(+), 33 deletions(-) -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for dma-buf: Flag vmap'ed memory as system or I/O memory (rev2)
== Series Details == Series: dma-buf: Flag vmap'ed memory as system or I/O memory (rev2) URL : https://patchwork.freedesktop.org/series/81647/ State : warning == Summary == $ dim checkpatch origin/drm-tip 757ce74a1b9b dma-buf: Add struct dma-buf-map for storing struct dma_buf.vaddr_ptr -:52: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() #52: FILE: drivers/dma-buf/dma-buf.c:1212: + BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr)); -:58: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() #58: FILE: drivers/dma-buf/dma-buf.c:1217: + BUG_ON(dma_buf_map_is_set(&dmabuf->vmap_ptr)); -:76: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() #76: FILE: drivers/dma-buf/dma-buf.c:1244: + BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr)); -:79: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() #79: FILE: drivers/dma-buf/dma-buf.c:1246: + BUG_ON(!dma_buf_map_is_vaddr(&dmabuf->vmap_ptr, vaddr)); -:91: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #91: new file mode 100644 -:145: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!map->vaddr_iomem" #145: FILE: include/linux/dma-buf-map.h:50: + return map->vaddr_iomem == NULL; -:146: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!map->vaddr" #146: FILE: include/linux/dma-buf-map.h:51: + return map->vaddr == NULL; total: 0 errors, 5 warnings, 2 checks, 152 lines checked 3ed40eba3c1e dma-buf: Use struct dma_buf_map in dma_buf_vmap() interfaces a23bd28000a3 dma-buf: Use struct dma_buf_map in dma_buf_vunmap() interfaces -:43: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() #43: FILE: drivers/dma-buf/dma-buf.c:1250: + BUG_ON(!dma_buf_map_is_equal(&dmabuf->vmap_ptr, map)); total: 0 errors, 1 warnings, 0 checks, 287 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 3/3] drm/i915/display: Program PSR2 selective fetch registers
On Thu, 2020-09-17 at 18:02 -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.
>
> v2:
> - removed warn on when no plane is visible in state
> - removed calculations using plane damaged area in
> intel_psr2_program_plane_sel_fetch()
>
> v3:
> - do not shift 16 positions the plane dst coordinates, only src is
> shifted
>
> 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 +-
> drivers/gpu/drm/i915/display/intel_psr.c | 120
> ++-
> drivers/gpu/drm/i915/display/intel_psr.h | 10 +-
> drivers/gpu/drm/i915/display/intel_sprite.c | 3 +
> 4 files changed, 134 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 5a9d933e425a..96bc515497c1 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -11812,6 +11812,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) {
> @@ -12823,8 +12826,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_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 02f74b0ddec1..deb0523f9f29 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1166,6 +1166,41 @@ 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);
> + enum pipe pipe = plane->pipe;
> + u32 val;
> +
> + if (!crtc_state->enable_psr2_sel_fetch)
> + return;
> +
> + /*
> + * skl_plane_ctl_crtc()/i9xx_cursor_ctl_crtc() return 0 for
> gen11+, so
> + * plane_state->ctl is the right value
> + */
> + val = plane_state ? plane_state->ctl : 0;
IMHO, skl_plane_ctl() might set other ctl bits, it would be better to
have separated ctl bit value for "selective fetch ctl".
> + intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, plane-
> >id), val);
> + if (!val || plane->id == PLANE_CURSOR)
> + return;
> +
> + val = plane_state->uapi.dst.y1 << 16 | plane_state-
> >uapi.dst.x1;
> + intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_POS(pipe, plane-
> >id), val);
> +
> + val = 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(&plane_state->uapi.src) >> 16) - 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)
> {
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> @@ -1180,16 +1215,91 @@ void
> intel_psr2_program_trans_man_trk_ctl(const struct intel_crtc_state
> *crtc_st
> crtc_state->psr2_man_track_ctl);
> }
>
> -void intel_psr2_sel_fetch_update(struct intel_atomic_state *state,
> - struct intel_crtc *crtc)
> +static void psr2_man_trk_ctl_calc(struct intel_crtc_state
> *crtc_state,
> + struct drm_rect *clip, bool
> full_update)
> +{
> + u32 val = PSR2_MAN_TRK_CTL_ENABLE;
> +
> + if (full_update) {
> + val |= PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
> + goto exit;
> + }
> +
> + if (clip->y1 == -1)
> + goto exit;
> +
> +
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Switch 4k kmalloc to use get_free_page for alignment
== Series Details ==
Series: drm/i915/selftests: Switch 4k kmalloc to use get_free_page for alignment
URL : https://patchwork.freedesktop.org/series/82028/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9042 -> Patchwork_18555
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/index.html
Known issues
Here are the changes found in Patchwork_18555 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][1] -> [DMESG-WARN][2] ([i915#62] / [i915#92] /
[i915#95])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
* igt@vgem_basic@sysfs:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-tgl-y/igt@vgem_ba...@sysfs.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/fi-tgl-y/igt@vgem_ba...@sysfs.html
Possible fixes
* igt@i915_module_load@reload:
- {fi-tgl-dsi}: [DMESG-WARN][7] ([i915#1982] / [k.org#205379]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-tgl-dsi/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/fi-tgl-dsi/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@execlists:
- {fi-tgl-dsi}: [INCOMPLETE][11] ([i915#2268]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u: [DMESG-WARN][13] ([i915#2203]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@vgem_basic@debugfs:
- fi-tgl-y: [DMESG-WARN][15] ([i915#402]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-tgl-y/igt@vgem_ba...@debugfs.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/fi-tgl-y/igt@vgem_ba...@debugfs.html
Warnings
* igt@i915_pm_rpm@module-reload:
- 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_9042/fi-tgl-y/igt@i915_pm_...@module-reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/fi-tgl-y/igt@i915_pm_...@module-reload.html
- 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_9042/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
- fi-kbl-guc: [DMESG-FAIL][21] ([i915#2203]) -> [DMESG-WARN][22]
([i915#2203])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-kbl-guc/igt@i915_pm_...@module-reload.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/fi-kbl-guc/igt@i915_pm_...@module-reload.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) ->
[DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +5 similar issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18555/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-kbl-x1275: [DMESG-WARN][25] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][26] ([i915#62] / [i915#92]) +2 similar issues
[25]:
https://intel-gfx-
Re: [Intel-gfx] [patch RFC 06/15] csky/mm/highmem: Switch to generic kmap atomic
Acked-by: Guo Ren
On Sat, Sep 19, 2020 at 5:50 PM Thomas Gleixner wrote:
>
> Signed-off-by: Thomas Gleixner
> Cc: Guo Ren
> Cc: linux-c...@vger.kernel.org
> ---
> Note: Completely untested
> ---
> arch/csky/Kconfig |1
> arch/csky/include/asm/highmem.h |4 +-
> arch/csky/mm/highmem.c | 75
>
> 3 files changed, 5 insertions(+), 75 deletions(-)
>
> --- a/arch/csky/Kconfig
> +++ b/arch/csky/Kconfig
> @@ -285,6 +285,7 @@ config NR_CPUS
> config HIGHMEM
> bool "High Memory Support"
> depends on !CPU_CK610
> + select KMAP_ATOMIC_GENERIC
> default y
>
> config FORCE_MAX_ZONEORDER
> --- a/arch/csky/include/asm/highmem.h
> +++ b/arch/csky/include/asm/highmem.h
> @@ -32,10 +32,12 @@ extern pte_t *pkmap_page_table;
>
> #define ARCH_HAS_KMAP_FLUSH_TLB
> extern void kmap_flush_tlb(unsigned long addr);
> -extern void *kmap_atomic_pfn(unsigned long pfn);
>
> #define flush_cache_kmaps() do {} while (0)
>
> +#define arch_kmap_temp_post_map(vaddr, pteval) kmap_flush_tlb(vaddr)
> +#define arch_kmap_temp_post_unmap(vaddr) kmap_flush_tlb(vaddr)
> +
> extern void kmap_init(void);
>
> #endif /* __KERNEL__ */
> --- a/arch/csky/mm/highmem.c
> +++ b/arch/csky/mm/highmem.c
> @@ -9,8 +9,6 @@
> #include
> #include
>
> -static pte_t *kmap_pte;
> -
> unsigned long highstart_pfn, highend_pfn;
>
> void kmap_flush_tlb(unsigned long addr)
> @@ -19,67 +17,7 @@ void kmap_flush_tlb(unsigned long addr)
> }
> EXPORT_SYMBOL(kmap_flush_tlb);
>
> -void *kmap_atomic_high_prot(struct page *page, pgprot_t prot)
> -{
> - unsigned long vaddr;
> - int idx, type;
> -
> - type = kmap_atomic_idx_push();
> - idx = type + KM_TYPE_NR*smp_processor_id();
> - vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
> -#ifdef CONFIG_DEBUG_HIGHMEM
> - BUG_ON(!pte_none(*(kmap_pte - idx)));
> -#endif
> - set_pte(kmap_pte-idx, mk_pte(page, prot));
> - flush_tlb_one((unsigned long)vaddr);
> -
> - return (void *)vaddr;
> -}
> -EXPORT_SYMBOL(kmap_atomic_high_prot);
> -
> -void kunmap_atomic_high(void *kvaddr)
> -{
> - unsigned long vaddr = (unsigned long) kvaddr & PAGE_MASK;
> - int idx;
> -
> - if (vaddr < FIXADDR_START)
> - return;
> -
> -#ifdef CONFIG_DEBUG_HIGHMEM
> - idx = KM_TYPE_NR*smp_processor_id() + kmap_atomic_idx();
> -
> - BUG_ON(vaddr != __fix_to_virt(FIX_KMAP_BEGIN + idx));
> -
> - pte_clear(&init_mm, vaddr, kmap_pte - idx);
> - flush_tlb_one(vaddr);
> -#else
> - (void) idx; /* to kill a warning */
> -#endif
> - kmap_atomic_idx_pop();
> -}
> -EXPORT_SYMBOL(kunmap_atomic_high);
> -
> -/*
> - * This is the same as kmap_atomic() but can map memory that doesn't
> - * have a struct page associated with it.
> - */
> -void *kmap_atomic_pfn(unsigned long pfn)
> -{
> - unsigned long vaddr;
> - int idx, type;
> -
> - pagefault_disable();
> -
> - type = kmap_atomic_idx_push();
> - idx = type + KM_TYPE_NR*smp_processor_id();
> - vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
> - set_pte(kmap_pte-idx, pfn_pte(pfn, PAGE_KERNEL));
> - flush_tlb_one(vaddr);
> -
> - return (void *) vaddr;
> -}
> -
> -static void __init kmap_pages_init(void)
> +void __init kmap_init(void)
> {
> unsigned long vaddr;
> pgd_t *pgd;
> @@ -96,14 +34,3 @@ static void __init kmap_pages_init(void)
> pte = pte_offset_kernel(pmd, vaddr);
> pkmap_page_table = pte;
> }
> -
> -void __init kmap_init(void)
> -{
> - unsigned long vaddr;
> -
> - kmap_pages_init();
> -
> - vaddr = __fix_to_virt(FIX_KMAP_BEGIN);
> -
> - kmap_pte = pte_offset_kernel((pmd_t *)pgd_offset_k(vaddr), vaddr);
> -}
>
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
On Wed, Sep 23 2020 at 12:19, peterz wrote: > On Mon, Sep 21, 2020 at 09:27:57PM +0200, Thomas Gleixner wrote: >> Alternatively this could of course be solved with per CPU page tables >> which will come around some day anyway I fear. > > Previously (with PTI) we looked at making the entire kernel map per-CPU, > and that takes a 2K copy on switch_mm() (or more general, the user part > of whatever the top level directory is for architectures that have a > shared kernel/user page-table setup in the first place). > > The idea was having a fixed per-cpu kernel page-table, share a bunch of > (kernel) page-tables between all CPUs and then copy in the user part on > switch. > > I've forgotten what the plan was for ASID/PCID in that scheme. > > For x86_64 we've been fearing the performance of that 2k copy, but I > don't think we've ever actually bit the bullet and implemented it to see > how bad it really is. I actually did at some point and depending on the workload the overhead was clearly measurable. And yes, it fell apart with PCID and I could not come up with a scheme for it which did not suck horribly. So I burried the patches in the poison cabinet. Aside of that, we'd need to implement that for a eight other architectures as well... Thanks, tglx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/3] dma-buf: Use struct dma_buf_map in dma_buf_vunmap() interfaces
This patch updates dma_buf_vunmap() and dma-buf's vunmap callback to
use struct dma_buf_map. The interfaces used to receive a buffer address.
This address is now given in an instance of the structure.
Users of the functions are updated accordingly. This is only an interface
change. It is currently expected that dma-buf memory can be accessed with
system memory load/store operations.
v2:
* include dma-buf-heaps and i915 selftests (kernel test robot)
* initialize cma_obj before using it in drm_gem_cma_free_object()
(kernel test robot)
Signed-off-by: Thomas Zimmermann
Acked-by: Sumit Semwal
---
drivers/dma-buf/dma-buf.c | 8 ++---
drivers/dma-buf/heaps/heap-helpers.c | 2 +-
drivers/gpu/drm/drm_gem_cma_helper.c | 9 +++---
drivers/gpu/drm/drm_gem_shmem_helper.c| 3 +-
drivers/gpu/drm/drm_prime.c | 6 ++--
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 5 +--
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 2 +-
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 6 ++--
.../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 4 +--
drivers/gpu/drm/tegra/gem.c | 5 +--
.../common/videobuf2/videobuf2-dma-contig.c | 3 +-
.../media/common/videobuf2/videobuf2-dma-sg.c | 3 +-
.../common/videobuf2/videobuf2-vmalloc.c | 6 ++--
include/drm/drm_prime.h | 2 +-
include/linux/dma-buf-map.h | 32 +--
include/linux/dma-buf.h | 4 +--
16 files changed, 66 insertions(+), 34 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 61bd24d21b38..a6ba4d598f0e 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1236,21 +1236,21 @@ EXPORT_SYMBOL_GPL(dma_buf_vmap);
/**
* dma_buf_vunmap - Unmap a vmap obtained by dma_buf_vmap.
* @dmabuf:[in]buffer to vunmap
- * @vaddr: [in]vmap to vunmap
+ * @map: [in]vmap pointer to vunmap
*/
-void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
+void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map)
{
if (WARN_ON(!dmabuf))
return;
BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
BUG_ON(dmabuf->vmapping_counter == 0);
- BUG_ON(!dma_buf_map_is_vaddr(&dmabuf->vmap_ptr, vaddr));
+ BUG_ON(!dma_buf_map_is_equal(&dmabuf->vmap_ptr, map));
mutex_lock(&dmabuf->lock);
if (--dmabuf->vmapping_counter == 0) {
if (dmabuf->ops->vunmap)
- dmabuf->ops->vunmap(dmabuf, vaddr);
+ dmabuf->ops->vunmap(dmabuf, map);
dma_buf_map_clear(&dmabuf->vmap_ptr);
}
mutex_unlock(&dmabuf->lock);
diff --git a/drivers/dma-buf/heaps/heap-helpers.c
b/drivers/dma-buf/heaps/heap-helpers.c
index aeb9e100f339..fcf4ce3e2cbb 100644
--- a/drivers/dma-buf/heaps/heap-helpers.c
+++ b/drivers/dma-buf/heaps/heap-helpers.c
@@ -251,7 +251,7 @@ static int dma_heap_dma_buf_vmap(struct dma_buf *dmabuf,
struct dma_buf_map *map
return 0;
}
-static void dma_heap_dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
+static void dma_heap_dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map
*map)
{
struct heap_helper_buffer *buffer = dmabuf->priv;
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 1ece73fd3fe9..1059acdde519 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -175,13 +175,12 @@ drm_gem_cma_create_with_handle(struct drm_file *file_priv,
*/
void drm_gem_cma_free_object(struct drm_gem_object *gem_obj)
{
- struct drm_gem_cma_object *cma_obj;
-
- cma_obj = to_drm_gem_cma_obj(gem_obj);
+ struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(gem_obj);
+ struct dma_buf_map map = DMA_BUF_MAP_INIT_VADDR(cma_obj->vaddr);
if (gem_obj->import_attach) {
if (cma_obj->vaddr)
- dma_buf_vunmap(gem_obj->import_attach->dmabuf,
cma_obj->vaddr);
+ dma_buf_vunmap(gem_obj->import_attach->dmabuf, &map);
drm_prime_gem_destroy(gem_obj, cma_obj->sgt);
} else if (cma_obj->vaddr) {
dma_free_wc(gem_obj->dev->dev, cma_obj->base.size,
@@ -628,7 +627,7 @@ drm_gem_cma_prime_import_sg_table_vmap(struct drm_device
*dev,
obj = drm_gem_cma_prime_import_sg_table(dev, attach, sgt);
if (IS_ERR(obj)) {
- dma_buf_vunmap(attach->dmabuf, map.vaddr);
+ dma_buf_vunmap(attach->dmabuf, &map);
return obj;
}
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 6328cfbb828e..fb11df7aced5 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -337,6 +337,7 @@ EXPORT_SYMBOL(drm_gem_shmem_vmap);
static void drm_gem_
[Intel-gfx] [PATCH v2 0/3] dma-buf: Flag vmap'ed memory as system or I/O memory
Dma-buf provides vmap() and vunmap() for retrieving and releasing mappings of dma-buf memory in kernel address space. The functions operate with plain addresses and the assumption is that the memory can be accessed with load and store operations. This is not the case on some architectures (e.g., sparc64) where I/O memory can only be accessed with dedicated instructions. This patchset introduces struct dma_buf_map, which contains the address of a buffer and a flag that tells whether system- or I/O-memory instructions are required. Some background: updating the DRM framebuffer console on sparc64 makes the kernel panic. This is because the framebuffer memory cannot be accessed with system-memory instructions. We currently employ a workaround in DRM to address this specific problem. [1] To resolve the problem, we'd like to address it at the most common point, which is the dma-buf framework. The dma-buf mapping ideally knows if I/O instructions are required and exports this information to it's users. The new structure struct dma_buf_map stores the buffer address and a flag that signals I/O memory. Affected users of the buffer (e.g., drivers, frameworks) can then access the memory accordingly. This patchset only introduces struct dma_buf_map, and updates struct dma_buf and it's interfaces. Further patches can update dma-buf users. For example, there's a prototype patchset for DRM that fixes the framebuffer problem. [2] Further work: TTM, one of DRM's memory managers, already exports an is_iomem flag of its own. It could later be switched over to exporting struct dma_buf_map, thus simplifying some code. Several DRM drivers expect their fbdev console to operate on I/O memory. These could possibly be switched over to the generic fbdev emulation, as soon as the generic code uses struct dma_buf_map. [1] https://lore.kernel.org/dri-devel/20200725191012.ga434...@ravnborg.org/ [2] https://lore.kernel.org/dri-devel/20200806085239.4606-1-tzimmerm...@suse.de/ v2: * always clear map parameter in dma_buf_vmap() (Daniel) * include dma-buf-heaps and i915 selftests (kernel test robot) * initialize cma_obj before using it in drm_gem_cma_free_object() (kernel test robot) Thomas Zimmermann (3): dma-buf: Add struct dma-buf-map for storing struct dma_buf.vaddr_ptr dma-buf: Use struct dma_buf_map in dma_buf_vmap() interfaces dma-buf: Use struct dma_buf_map in dma_buf_vunmap() interfaces Documentation/driver-api/dma-buf.rst | 3 + drivers/dma-buf/dma-buf.c | 42 +++--- drivers/dma-buf/heaps/heap-helpers.c | 10 +- drivers/gpu/drm/drm_gem_cma_helper.c | 20 +-- drivers/gpu/drm/drm_gem_shmem_helper.c| 17 ++- drivers/gpu/drm/drm_prime.c | 14 +- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 13 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 13 +- .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 18 ++- .../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 14 +- drivers/gpu/drm/tegra/gem.c | 23 ++-- .../common/videobuf2/videobuf2-dma-contig.c | 17 ++- .../media/common/videobuf2/videobuf2-dma-sg.c | 19 ++- .../common/videobuf2/videobuf2-vmalloc.c | 21 ++- include/drm/drm_prime.h | 5 +- include/linux/dma-buf-map.h | 126 ++ include/linux/dma-buf.h | 11 +- 17 files changed, 294 insertions(+), 92 deletions(-) create mode 100644 include/linux/dma-buf-map.h -- 2.28.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/3] dma-buf: Use struct dma_buf_map in dma_buf_vmap() interfaces
This patch updates dma_buf_vmap() and dma-buf's vmap callback to use
struct dma_buf_map.
The interfaces used to return a buffer address. This address now gets
stored in an instance of the structure that is given as an additional
argument. The functions return an errno code on errors.
Users of the functions are updated accordingly. This is only an interface
change. It is currently expected that dma-buf memory can be accessed with
system memory load/store operations.
v2:
* always clear map parameter in dma_buf_vmap() (Daniel)
* include dma-buf-heaps and i915 selftests (kernel test robot)
Signed-off-by: Thomas Zimmermann
Acked-by: Sumit Semwal
---
drivers/dma-buf/dma-buf.c | 28 +++
drivers/dma-buf/heaps/heap-helpers.c | 8 --
drivers/gpu/drm/drm_gem_cma_helper.c | 13 +
drivers/gpu/drm/drm_gem_shmem_helper.c| 14 ++
drivers/gpu/drm/drm_prime.c | 8 --
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 8 +-
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 11 ++--
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 12 ++--
.../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 10 +--
drivers/gpu/drm/tegra/gem.c | 18
.../common/videobuf2/videobuf2-dma-contig.c | 14 +++---
.../media/common/videobuf2/videobuf2-dma-sg.c | 16 +++
.../common/videobuf2/videobuf2-vmalloc.c | 15 +++---
include/drm/drm_prime.h | 3 +-
include/linux/dma-buf-map.h | 13 +
include/linux/dma-buf.h | 6 ++--
16 files changed, 138 insertions(+), 59 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 5e849ca241a0..61bd24d21b38 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1186,46 +1186,50 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
* dma_buf_vmap - Create virtual mapping for the buffer object into kernel
* address space. Same restrictions as for vmap and friends apply.
* @dmabuf:[in]buffer to vmap
+ * @map: [out] returns the vmap pointer
*
* This call may fail due to lack of virtual mapping address space.
* These calls are optional in drivers. The intended use for them
* is for mapping objects linear in kernel space for high use objects.
* Please attempt to use kmap/kunmap before thinking about these interfaces.
*
- * Returns NULL on error.
+ * Returns 0 on success, or a negative errno code otherwise.
*/
-void *dma_buf_vmap(struct dma_buf *dmabuf)
+int dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map *map)
{
- void *ptr;
+ struct dma_buf_map ptr;
+ int ret = 0;
+
+ dma_buf_map_clear(map);
if (WARN_ON(!dmabuf))
- return NULL;
+ return -EINVAL;
if (!dmabuf->ops->vmap)
- return NULL;
+ return -EINVAL;
mutex_lock(&dmabuf->lock);
if (dmabuf->vmapping_counter) {
dmabuf->vmapping_counter++;
BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
- ptr = dmabuf->vmap_ptr.vaddr;
+ *map = dmabuf->vmap_ptr;
goto out_unlock;
}
BUG_ON(dma_buf_map_is_set(&dmabuf->vmap_ptr));
- ptr = dmabuf->ops->vmap(dmabuf);
- if (WARN_ON_ONCE(IS_ERR(ptr)))
- ptr = NULL;
- if (!ptr)
+ ret = dmabuf->ops->vmap(dmabuf, &ptr);
+ if (WARN_ON_ONCE(ret))
goto out_unlock;
- dmabuf->vmap_ptr.vaddr = ptr;
+ dmabuf->vmap_ptr = ptr;
dmabuf->vmapping_counter = 1;
+ *map = dmabuf->vmap_ptr;
+
out_unlock:
mutex_unlock(&dmabuf->lock);
- return ptr;
+ return ret;
}
EXPORT_SYMBOL_GPL(dma_buf_vmap);
diff --git a/drivers/dma-buf/heaps/heap-helpers.c
b/drivers/dma-buf/heaps/heap-helpers.c
index d0696cf937af..aeb9e100f339 100644
--- a/drivers/dma-buf/heaps/heap-helpers.c
+++ b/drivers/dma-buf/heaps/heap-helpers.c
@@ -235,7 +235,7 @@ static int dma_heap_dma_buf_end_cpu_access(struct dma_buf
*dmabuf,
return 0;
}
-static void *dma_heap_dma_buf_vmap(struct dma_buf *dmabuf)
+static int dma_heap_dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map
*map)
{
struct heap_helper_buffer *buffer = dmabuf->priv;
void *vaddr;
@@ -244,7 +244,11 @@ static void *dma_heap_dma_buf_vmap(struct dma_buf *dmabuf)
vaddr = dma_heap_buffer_vmap_get(buffer);
mutex_unlock(&buffer->lock);
- return vaddr;
+ if (!vaddr)
+ return -ENOMEM;
+ dma_buf_map_set_vaddr(map, vaddr);
+
+ return 0;
}
static void dma_heap_dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 59b9ca207b42..1ece73fd3fe9 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_
[Intel-gfx] [PATCH v2 1/3] dma-buf: Add struct dma-buf-map for storing struct dma_buf.vaddr_ptr
The new type struct dma_buf_map represents a mapping of dma-buf memory
into kernel space. It contains a flag, is_iomem, that signals users to
access the mapped memory with I/O operations instead of regular loads
and stores.
It was assumed that DMA buffer memory can be accessed with regular load
and store operations. Some architectures, such as sparc64, require the
use of I/O operations to access dma-map buffers that are located in I/O
memory. Providing struct dma_buf_map allows drivers to implement this.
This was specifically a problem when refreshing the graphics framebuffer
on such systems. [1]
As the first step, struct dma_buf stores an instance of struct dma_buf_map
internally. Afterwards, dma-buf's vmap and vunmap interfaces are be
converted. Finally, affected drivers can be fixed.
[1] https://lore.kernel.org/dri-devel/20200725191012.ga434...@ravnborg.org/
Signed-off-by: Thomas Zimmermann
Acked-by: Sumit Semwal
---
Documentation/driver-api/dma-buf.rst | 3 +
drivers/dma-buf/dma-buf.c| 14 ++---
include/linux/dma-buf-map.h | 87
include/linux/dma-buf.h | 3 +-
4 files changed, 99 insertions(+), 8 deletions(-)
create mode 100644 include/linux/dma-buf-map.h
diff --git a/Documentation/driver-api/dma-buf.rst
b/Documentation/driver-api/dma-buf.rst
index 13ea0cc0a3fa..3244c600a9a1 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -115,6 +115,9 @@ Kernel Functions and Structures Reference
.. kernel-doc:: include/linux/dma-buf.h
:internal:
+.. kernel-doc:: include/linux/dma-buf-map.h
+ :internal:
+
Reservation Objects
---
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 58564d82a3a2..5e849ca241a0 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1207,12 +1207,12 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
mutex_lock(&dmabuf->lock);
if (dmabuf->vmapping_counter) {
dmabuf->vmapping_counter++;
- BUG_ON(!dmabuf->vmap_ptr);
- ptr = dmabuf->vmap_ptr;
+ BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
+ ptr = dmabuf->vmap_ptr.vaddr;
goto out_unlock;
}
- BUG_ON(dmabuf->vmap_ptr);
+ BUG_ON(dma_buf_map_is_set(&dmabuf->vmap_ptr));
ptr = dmabuf->ops->vmap(dmabuf);
if (WARN_ON_ONCE(IS_ERR(ptr)))
@@ -1220,7 +1220,7 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
if (!ptr)
goto out_unlock;
- dmabuf->vmap_ptr = ptr;
+ dmabuf->vmap_ptr.vaddr = ptr;
dmabuf->vmapping_counter = 1;
out_unlock:
@@ -1239,15 +1239,15 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
if (WARN_ON(!dmabuf))
return;
- BUG_ON(!dmabuf->vmap_ptr);
+ BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
BUG_ON(dmabuf->vmapping_counter == 0);
- BUG_ON(dmabuf->vmap_ptr != vaddr);
+ BUG_ON(!dma_buf_map_is_vaddr(&dmabuf->vmap_ptr, vaddr));
mutex_lock(&dmabuf->lock);
if (--dmabuf->vmapping_counter == 0) {
if (dmabuf->ops->vunmap)
dmabuf->ops->vunmap(dmabuf, vaddr);
- dmabuf->vmap_ptr = NULL;
+ dma_buf_map_clear(&dmabuf->vmap_ptr);
}
mutex_unlock(&dmabuf->lock);
}
diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
new file mode 100644
index ..d4b1bb3cc4b0
--- /dev/null
+++ b/include/linux/dma-buf-map.h
@@ -0,0 +1,87 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Pointer to dma-buf-mapped memory, plus helpers.
+ */
+
+#ifndef __DMA_BUF_MAP_H__
+#define __DMA_BUF_MAP_H__
+
+#include
+
+/**
+ * struct dma_buf_map - Pointer to vmap'ed dma-buf memory.
+ * @vaddr_iomem: The buffer's address if in I/O memory
+ * @vaddr: The buffer's address if in system memory
+ * @is_iomem: True if the dma-buf memory is located in I/O
+ * memory, or false otherwise.
+ *
+ * Calling dma-buf's vmap operation returns a pointer to the buffer.
+ * Depending on the location of the buffer, users may have to access it
+ * with I/O operations or memory load/store operations. struct dma_buf_map
+ * stores the buffer address and a flag that signals the required access.
+ */
+struct dma_buf_map {
+ union {
+ void __iomem *vaddr_iomem;
+ void *vaddr;
+ };
+ bool is_iomem;
+};
+
+/* API transition helper */
+static inline bool dma_buf_map_is_vaddr(const struct dma_buf_map *map, const
void *vaddr)
+{
+ return !map->is_iomem && (map->vaddr == vaddr);
+}
+
+/**
+ * dma_buf_map_is_null - Tests for a dma-buf mapping to be NULL
+ * @map: The dma-buf mapping structure
+ *
+ * Depending on the state of struct dma_buf_map.is_iomem, tests if the
+ * mapping is NULL.
+ *
+ * Returns:
+ * True if the mapping is NULL, or f
Re: [Intel-gfx] [PATCH v3 03/22] drm/etnaviv: Introduce GEM object functions
On Mi, 2020-09-23 at 12:21 +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in etnaviv. The only exception is gem_prime_mmap,
> which is non-trivial to convert.
>
> Signed-off-by: Thomas Zimmermann
> Reviewed-by: Daniel Vetter
Acked-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 13 -
> drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 19 ++-
> 3 files changed, 18 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index a9a3afaef9a1..aa270b79e585 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -468,12 +468,6 @@ static const struct drm_ioctl_desc etnaviv_ioctls[] = {
> ETNA_IOCTL(PM_QUERY_SIG, pm_query_sig, DRM_RENDER_ALLOW),
> };
>
> -static const struct vm_operations_struct vm_ops = {
> - .fault = etnaviv_gem_fault,
> - .open = drm_gem_vm_open,
> - .close = drm_gem_vm_close,
> -};
> -
> static const struct file_operations fops = {
> .owner = THIS_MODULE,
> .open = drm_open,
> @@ -490,16 +484,9 @@ static struct drm_driver etnaviv_drm_driver = {
> .driver_features= DRIVER_GEM | DRIVER_RENDER,
> .open = etnaviv_open,
> .postclose = etnaviv_postclose,
> - .gem_free_object_unlocked = etnaviv_gem_free_object,
> - .gem_vm_ops = &vm_ops,
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_pin = etnaviv_gem_prime_pin,
> - .gem_prime_unpin= etnaviv_gem_prime_unpin,
> - .gem_prime_get_sg_table = etnaviv_gem_prime_get_sg_table,
> .gem_prime_import_sg_table = etnaviv_gem_prime_import_sg_table,
> - .gem_prime_vmap = etnaviv_gem_prime_vmap,
> - .gem_prime_vunmap = etnaviv_gem_prime_vunmap,
> .gem_prime_mmap = etnaviv_gem_prime_mmap,
> #ifdef CONFIG_DEBUG_FS
> .debugfs_init = etnaviv_debugfs_init,
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> index 4d8dc9236e5f..914f0867ff71 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> @@ -49,7 +49,6 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void
> *data,
> struct drm_file *file);
>
> int etnaviv_gem_mmap(struct file *filp, struct vm_area_struct *vma);
> -vm_fault_t etnaviv_gem_fault(struct vm_fault *vmf);
> int etnaviv_gem_mmap_offset(struct drm_gem_object *obj, u64 *offset);
> struct sg_table *etnaviv_gem_prime_get_sg_table(struct drm_gem_object *obj);
> void *etnaviv_gem_prime_vmap(struct drm_gem_object *obj);
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> index d1533bdc1335..67d9a2b9ea6a 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> @@ -171,7 +171,7 @@ int etnaviv_gem_mmap(struct file *filp, struct
> vm_area_struct *vma)
> return obj->ops->mmap(obj, vma);
> }
>
> -vm_fault_t etnaviv_gem_fault(struct vm_fault *vmf)
> +static vm_fault_t etnaviv_gem_fault(struct vm_fault *vmf)
> {
> struct vm_area_struct *vma = vmf->vma;
> struct drm_gem_object *obj = vma->vm_private_data;
> @@ -559,6 +559,22 @@ void etnaviv_gem_obj_add(struct drm_device *dev, struct
> drm_gem_object *obj)
> mutex_unlock(&priv->gem_lock);
> }
>
> +static const struct vm_operations_struct vm_ops = {
> + .fault = etnaviv_gem_fault,
> + .open = drm_gem_vm_open,
> + .close = drm_gem_vm_close,
> +};
> +
> +static const struct drm_gem_object_funcs etnaviv_gem_object_funcs = {
> + .free = etnaviv_gem_free_object,
> + .pin = etnaviv_gem_prime_pin,
> + .unpin = etnaviv_gem_prime_unpin,
> + .get_sg_table = etnaviv_gem_prime_get_sg_table,
> + .vmap = etnaviv_gem_prime_vmap,
> + .vunmap = etnaviv_gem_prime_vunmap,
> + .vm_ops = &vm_ops,
> +};
> +
> static int etnaviv_gem_new_impl(struct drm_device *dev, u32 size, u32 flags,
> const struct etnaviv_gem_ops *ops, struct drm_gem_object **obj)
> {
> @@ -593,6 +609,7 @@ static int etnaviv_gem_new_impl(struct drm_device *dev,
> u32 size, u32 flags,
> INIT_LIST_HEAD(&etnaviv_obj->vram_list);
>
> *obj = &etnaviv_obj->base;
> + (*obj)->funcs = &etnaviv_gem_object_funcs;
>
> return 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 Gen12 HDCP 1.4 support on DP MST (rev2)
== Series Details ==
Series: Gen12 HDCP 1.4 support on DP MST (rev2)
URL : https://patchwork.freedesktop.org/series/81289/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9042 -> Patchwork_18554
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18554/index.html
Known issues
Here are the changes found in Patchwork_18554 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_sync@basic-all:
- 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_9042/fi-tgl-y/igt@gem_s...@basic-all.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18554/fi-tgl-y/igt@gem_s...@basic-all.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][3] -> [DMESG-WARN][4] ([i915#62] / [i915#92] /
[i915#95])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18554/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +2 similar
issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18554/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@vgem_basic@unload:
- fi-skl-guc: [PASS][7] -> [DMESG-WARN][8] ([i915#2203])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-skl-guc/igt@vgem_ba...@unload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18554/fi-skl-guc/igt@vgem_ba...@unload.html
Possible fixes
* igt@gem_huc_copy@huc-copy:
- fi-tgl-y: [DMESG-WARN][9] ([i915#402]) -> [PASS][10] +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-tgl-y/igt@gem_huc_c...@huc-copy.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18554/fi-tgl-y/igt@gem_huc_c...@huc-copy.html
* igt@i915_selftest@live@execlists:
- {fi-tgl-dsi}: [INCOMPLETE][11] ([i915#2268]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18554/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u: [DMESG-WARN][13] ([i915#2203]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18554/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18554/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@i915_pm_rpm@module-reload:
- 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_9042/fi-tgl-y/igt@i915_pm_...@module-reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18554/fi-tgl-y/igt@i915_pm_...@module-reload.html
- fi-kbl-guc: [DMESG-FAIL][19] ([i915#2203]) -> [DMESG-WARN][20]
([i915#2203])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-kbl-guc/igt@i915_pm_...@module-reload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18554/fi-kbl-guc/igt@i915_pm_...@module-reload.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92]) ->
[DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-kbl-x1275/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18554/fi-kbl-x1275/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][24] ([i915#62] / [i915#92]) +1 similar issue
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-kbl-x1275/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[24]:
https://intel-gfx-ci.01.org/tree/drm
[Intel-gfx] [PATCH] drm/i915/selftests: Switch 4k kmalloc to use get_free_page for alignment
In generating the reference LRC, we want a page-aligned address for simplicity in computing the offsets within. This then shares the computation for the HW LRC which is mapped and so page aligned, making the comparison straightforward. It seems that kmalloc(4k) is not always returning from a 4k-aligned slab cache (which would give us a page aligned address) so force alignment by explicitly allocating a page. Reported-by: "Gote, Nitin R" Signed-off-by: Chris Wilson Cc: "Gote, Nitin R" --- drivers/gpu/drm/i915/gt/selftest_lrc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c b/drivers/gpu/drm/i915/gt/selftest_lrc.c index c8753559c44c..a885f2fb6e66 100644 --- a/drivers/gpu/drm/i915/gt/selftest_lrc.c +++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c @@ -4761,7 +4761,7 @@ static int live_lrc_layout(void *arg) * match the layout saved by HW. */ - lrc = kmalloc(PAGE_SIZE, GFP_KERNEL); + lrc = (u32 *)__get_free_page(GFP_KERNEL); if (!lrc) return -ENOMEM; @@ -4850,7 +4850,7 @@ static int live_lrc_layout(void *arg) break; } - kfree(lrc); + free_page((unsigned long)lrc); return err; } -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [V13 5/5] drm/i915/dsi: Enable software vblank counter
> -Original Message-
> From: Ville Syrjälä
> Sent: Wednesday, September 23, 2020 4:05 PM
> To: Kulkarni, Vandita
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> Subject: Re: [V13 5/5] drm/i915/dsi: Enable software vblank counter
>
> On Wed, Sep 23, 2020 at 10:16:05AM +, Kulkarni, Vandita wrote:
> > > -Original Message-
> > > From: Ville Syrjälä
> > > Sent: Wednesday, September 23, 2020 3:30 PM
> > > To: Kulkarni, Vandita
> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > >
> > > Subject: Re: [V13 5/5] drm/i915/dsi: Enable software vblank counter
> > >
> > > On Tue, Sep 22, 2020 at 07:14:26PM +0530, Vandita Kulkarni wrote:
> > > > In case of DSI cmd mode, we get hw vblank counter updated after
> > > > the TE comes in, if we try to read the hw vblank counter in te
> > > > handler we wouldnt have the udpated vblank counter yet.
> > > > This will lead to a state where we would send the vblank event to
> > > > the user space in the next te, though the frame update would have
> > > > completed in the first TE duration itself.
> > > > Hence switch to using software timestamp based vblank counter.
> > > >
> > > > Signed-off-by: Vandita Kulkarni
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_display.c | 11 +++
> > > > drivers/gpu/drm/i915/i915_irq.c | 4
> > > > 2 files changed, 15 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > index c4f331f2af45..8b9e59e52708 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > @@ -1808,6 +1808,17 @@ enum pipe intel_crtc_pch_transcoder(struct
> > > > intel_crtc *crtc) static u32 intel_crtc_max_vblank_count(const
> > > > struct intel_crtc_state *crtc_state) {
> > > > struct drm_i915_private *dev_priv =
> > > > to_i915(crtc_state->uapi.crtc->dev);
> > > > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > > + u32 flags = crtc->mode_flags;
> > >
> > > That's wrong. You need to look at the crtc_state instead.
> >
> > Thanks,
> > I will use crtc_state.
>
> I'd also frop the 'flags' variable. Single use so not much point.
> Or at the very least call it 'mode_flags' so we know what it actually is.
Ok, will use mode_flags.
Thanks,
Vandita
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Gen12 HDCP 1.4 support on DP MST (rev2)
== Series Details == Series: Gen12 HDCP 1.4 support on DP MST (rev2) URL : https://patchwork.freedesktop.org/series/81289/ 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:290: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: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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Gen12 HDCP 1.4 support on DP MST (rev2)
== Series Details ==
Series: Gen12 HDCP 1.4 support on DP MST (rev2)
URL : https://patchwork.freedesktop.org/series/81289/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
da72c67c9825 drm/i915/hdcp: DP MST transcoder for link and stream
f9f8c1ab6f3a drm/i915/hdcp: Move HDCP enc status timeout to header
-:13: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 7e90e8d0c0ea ("drm/i915:
Increase timeout for Encrypt status change")'
#13:
Related: 7e90e8d0c0ea ("drm/i915: Increase timeout for Encrypt
total: 1 errors, 0 warnings, 0 checks, 47 lines checked
a2c096ba0641 drm/i915/hdcp: HDCP stream encryption support
f4f6ef0e716b drm/i915/hdcp: Enable Gen12 HDCP 1.4 DP MST support
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Wed, Sep 23, 2020 at 01:16:42PM +0200, Daniel Vetter wrote: > On Wed, Sep 23, 2020 at 1:14 PM Marius Vlad wrote: > > > > On Wed, Sep 23, 2020 at 12:58:30PM +0200, Daniel Vetter wrote: > > > On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad > > > wrote: > > > > > > > > On Fri, Jan 31, 2020 at 07:34:00AM +, Daniel Stone wrote: > > > > > On Thu, 5 Jul 2018 at 11:21, Daniel Vetter > > > > > wrote: > > > > > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed > > > > > > to > > > > > > pull in arbitrary other resources, including CRTCs (e.g. when > > > > > > reconfiguring global resources). > > > > > > > > > > > > But in nonblocking mode userspace has then no idea this happened, > > > > > > which can lead to spurious EBUSY calls, both: > > > > > > - when that other CRTC is currently busy doing a page_flip the > > > > > > ALLOW_MODESET commit can fail with an EBUSY > > > > > > - on the other CRTC a normal atomic flip can fail with EBUSY because > > > > > > of the additional commit inserted by the kernel without > > > > > > userspace's > > > > > > knowledge > > > > > > > > > > > > For blocking commits this isn't a problem, because everyone else > > > > > > will > > > > > > just block until all the CRTC are reconfigured. Only thing userspace > > > > > > can notice is the dropped frames without any reason for why frames > > > > > > got > > > > > > dropped. > > > > > > > > > > > > Consensus is that we need new uapi to handle this properly, but no > > > > > > one > > > > > > has any idea what exactly the new uapi should look like. As a > > > > > > stop-gap > > > > > > plug this problem by demoting nonblocking commits which might cause > > > > > > issues by including CRTCs not in the original request to blocking > > > > > > commits. > > > > Gentle ping. I've tried out Linus's master tree and, and like Pekka, > > > > I've noticed this isn't integrated/added. > > > > > > > > Noticed this is fixing (also) DPMS when multiple outputs are in use. > > > > Wondering if we can just use a _ONCE() variant instead of WARN_ON(). > > > > I'm seeing > > > > the warning quite often. > > > > > > On which driver/chip does this happen? > > I've tried it out on i915. > > lspci -nn please. Sure, $ lspci -nn 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers [8086:5914] (rev 08) 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 620 [8086:5917] (rev 07) 00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 08) 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller [8086:9d2f] (rev 21) 00:14.2 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Thermal subsystem [8086:9d31] (rev 21) 00:15.0 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 [8086:9d60] (rev 21) 00:15.1 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 [8086:9d61] (rev 21) 00:16.0 Communication controller [0780]: Intel Corporation Sunrise Point-LP CSME HECI #1 [8086:9d3a] (rev 21) 00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #1 [8086:9d10] (rev f1) 00:1c.2 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #3 [8086:9d12] (rev f1) 00:1c.4 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 [8086:9d14] (rev f1) 00:1d.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 [8086:9d18] (rev f1) 00:1f.0 ISA bridge [0601]: Intel Corporation Sunrise Point LPC Controller/eSPI Controller [8086:9d4e] (rev 21) 00:1f.2 Memory controller [0580]: Intel Corporation Sunrise Point-LP PMC [8086:9d21] (rev 21) 00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-LP HD Audio [8086:9d71] (rev 21) 00:1f.4 SMBus [0c05]: Intel Corporation Sunrise Point-LP SMBus [8086:9d23] (rev 21) 01:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS525A PCI Express Card Reader [10ec:525a] (rev 01) 02:00.0 Network controller [0280]: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter [168c:003e] (rev 32) 6e:00.0 Non-Volatile memory controller [0108]: Toshiba Corporation Device [1179:0116] (it's a xps laptop) > > Also adding Ville, who has an idea where this can all go wrong. The > one he pointed out thus far is gen12+ only though. > -Daniel > > > > -Daniel > > > > > > > > > > > > > > > > > Thanks for writing this up Daniel, and for reminding me about it some > > > > > time later as well ... > > > > > > > > > > Reviewed-by: Daniel Stone > > > > > > > > > > Cheers, > > > > > Daniel > > > > > ___ > > > > > dri-devel mailing list > > > > > dri-de...@lists.freedesktop.org > > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > >
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/atomic: document and enforce rules around "spurious" EBUSY
== Series Details ==
Series: series starting with [1/2] drm/atomic: document and enforce rules
around "spurious" EBUSY
URL : https://patchwork.freedesktop.org/series/82023/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9042 -> Patchwork_18553
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/index.html
Known issues
Here are the changes found in Patchwork_18553 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_flink_basic@double-flink:
- 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_9042/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
* igt@i915_module_load@reload:
- fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#1982] /
[k.org#205379])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-tgl-y/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-tgl-y/igt@i915_module_l...@reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-apl-guc: [PASS][5] -> [DMESG-WARN][6] ([i915#1635] /
[i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-apl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-apl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-icl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
* igt@vgem_basic@unload:
- fi-skl-guc: [PASS][9] -> [DMESG-WARN][10] ([i915#2203])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-skl-guc/igt@vgem_ba...@unload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-skl-guc/igt@vgem_ba...@unload.html
Possible fixes
* igt@gem_huc_copy@huc-copy:
- 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_9042/fi-tgl-y/igt@gem_huc_c...@huc-copy.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-tgl-y/igt@gem_huc_c...@huc-copy.html
* igt@i915_module_load@reload:
- {fi-tgl-dsi}: [DMESG-WARN][13] ([i915#1982] / [k.org#205379]) ->
[PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-tgl-dsi/igt@i915_module_l...@reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-tgl-dsi/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@execlists:
- {fi-tgl-dsi}: [INCOMPLETE][17] ([i915#2268]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20] +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@i915_pm_rpm@module-reload:
- 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_9042/fi-tgl-y/igt@i915_pm_...@module-reload.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-tgl-y/igt@i915_pm_...@module-reload.html
- fi-kbl-guc: [DMESG-FAIL][23] ([i915#2203]) -> [DMESG-WARN][24]
([i915#2203])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-kbl-guc/igt@i915_pm_...@module-reload.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-kbl-guc/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-flip-after-curs
Re: [Intel-gfx] [PATCH v3 07/22] drm/imx/dcss: Initialize DRM driver instance with CMA helper macro
Hi Thomas,
On Wed, Sep 23, 2020 at 12:21:44PM +0200, Thomas Zimmermann wrote:
> The i.MX DCSS driver uses CMA helpers with default callback functions.
> Initialize the driver structure with the rsp CMA helper macro. The
> driver is being converted to use GEM object functions as part of
> this change.
>
> Two callbacks, .gem_prime_export and .gem_prime_import, were initialized
> to their default implementations, so they are just kept empty now.
>
> Signed-off-by: Thomas Zimmermann
> Reported-by: kernel test robot
> ---
Reviewed-by: Laurentiu Palcu
Thanks,
laurentiu
> drivers/gpu/drm/imx/dcss/dcss-kms.c | 14 +-
> 1 file changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c
> b/drivers/gpu/drm/imx/dcss/dcss-kms.c
> index 135a62366ab8..b72e5cef7e40 100644
> --- a/drivers/gpu/drm/imx/dcss/dcss-kms.c
> +++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c
> @@ -28,19 +28,7 @@ static const struct drm_mode_config_funcs
> dcss_drm_mode_config_funcs = {
>
> static struct drm_driver dcss_kms_driver = {
> .driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
> - .gem_free_object_unlocked = drm_gem_cma_free_object,
> - .gem_vm_ops = &drm_gem_cma_vm_ops,
> - .dumb_create= drm_gem_cma_dumb_create,
> -
> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_import = drm_gem_prime_import,
> - .gem_prime_export = drm_gem_prime_export,
> - .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> - .gem_prime_vmap = drm_gem_cma_prime_vmap,
> - .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
> - .gem_prime_mmap = drm_gem_cma_prime_mmap,
> + DRM_GEM_CMA_DRIVER_OPS,
> .fops = &dcss_cma_fops,
> .name = "imx-dcss",
> .desc = "i.MX8MQ Display Subsystem",
> --
> 2.28.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/4] drm/i915/hdcp: HDCP stream encryption support
Both HDCP_{1.x,2.x} requires to select/deselect Multistream HDCP bit
in TRANS_DDI_FUNC_CTL in order to enable/disable stream HDCP
encryption over DP MST Transport Link.
HDCP 1.4 stream encryption requires to validate the stream encryption
status in HDCP_STATUS_{TRANSCODER,PORT} register driving that link
in order to enable/disable the stream encryption.
Both of above requirement are same for all Gen with respect to
B.Spec Documentation.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_ddi.c | 10 +--
drivers/gpu/drm/i915/display/intel_ddi.h | 6 +-
.../drm/i915/display/intel_display_types.h| 4 +
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 80 ---
drivers/gpu/drm/i915/display/intel_hdmi.c | 14 ++--
drivers/gpu/drm/i915/i915_reg.h | 1 +
6 files changed, 90 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 683b252f1dbe..c7d073ec7a14 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1849,9 +1849,9 @@ void intel_ddi_disable_transcoder_func(const struct
intel_crtc_state *crtc_state
}
}
-int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
-enum transcoder cpu_transcoder,
-bool enable)
+int intel_ddi_toggle_hdcp_bits(struct intel_encoder *intel_encoder,
+ enum transcoder cpu_transcoder,
+ bool enable, u32 hdcp_mask)
{
struct drm_device *dev = intel_encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -1866,9 +1866,9 @@ int intel_ddi_toggle_hdcp_signalling(struct intel_encoder
*intel_encoder,
tmp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (enable)
- tmp |= TRANS_DDI_HDCP_SIGNALLING;
+ tmp |= hdcp_mask;
else
- tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
+ tmp &= ~hdcp_mask;
intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder), tmp);
intel_display_power_put(dev_priv, intel_encoder->power_domain, wakeref);
return ret;
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.h
b/drivers/gpu/drm/i915/display/intel_ddi.h
index f5fb62fc9400..69d9e495992c 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.h
+++ b/drivers/gpu/drm/i915/display/intel_ddi.h
@@ -43,9 +43,9 @@ void intel_ddi_compute_min_voltage_level(struct
drm_i915_private *dev_priv,
struct intel_crtc_state *crtc_state);
u32 bxt_signal_levels(struct intel_dp *intel_dp);
u32 ddi_signal_levels(struct intel_dp *intel_dp);
-int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
-enum transcoder cpu_transcoder,
-bool enable);
+int intel_ddi_toggle_hdcp_bits(struct intel_encoder *intel_encoder,
+ enum transcoder cpu_transcoder,
+ bool enable, u32 hdcp_mask);
void icl_sanitize_encoder_pll_mapping(struct intel_encoder *encoder);
#endif /* __INTEL_DDI_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 1a9e186e4a5d..58075f63bf52 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -319,6 +319,10 @@ struct intel_hdcp_shim {
enum transcoder cpu_transcoder,
bool enable);
+ /* Enable/Disable stream encryption on DP MST Transport Link */
+ int (*stream_encryption)(struct intel_digital_port *dig_port,
+bool enable);
+
/* Ensures the link is still protected */
bool (*check_link)(struct intel_digital_port *dig_port,
struct intel_connector *connector);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 03424d20e9f7..652d4645f255 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -16,6 +16,30 @@
#include "intel_dp.h"
#include "intel_hdcp.h"
+static unsigned int transcoder_to_stream_enc_status(enum transcoder
cpu_transcoder)
+{
+ u32 stream_enc_mask;
+
+ switch (cpu_transcoder) {
+ case TRANSCODER_A:
+ stream_enc_mask = HDCP_STATUS_STREAM_A_ENC;
+ break;
+ case TRANSCODER_B:
+ stream_enc_mask = HDCP_STATUS_STREAM_B_ENC;
+ break;
+ case TRANSCODER_C:
+ stream_enc_mask = HDCP_STATUS_STREAM_C_ENC;
+ break;
+ case TRANSCODER_D:
+ stream_enc_mask = HDCP_STATUS_STREAM_D_ENC;
+
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Wed, Sep 23, 2020 at 1:14 PM Marius Vlad wrote: > > On Wed, Sep 23, 2020 at 12:58:30PM +0200, Daniel Vetter wrote: > > On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad > > wrote: > > > > > > On Fri, Jan 31, 2020 at 07:34:00AM +, Daniel Stone wrote: > > > > On Thu, 5 Jul 2018 at 11:21, Daniel Vetter > > > > wrote: > > > > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to > > > > > pull in arbitrary other resources, including CRTCs (e.g. when > > > > > reconfiguring global resources). > > > > > > > > > > But in nonblocking mode userspace has then no idea this happened, > > > > > which can lead to spurious EBUSY calls, both: > > > > > - when that other CRTC is currently busy doing a page_flip the > > > > > ALLOW_MODESET commit can fail with an EBUSY > > > > > - on the other CRTC a normal atomic flip can fail with EBUSY because > > > > > of the additional commit inserted by the kernel without userspace's > > > > > knowledge > > > > > > > > > > For blocking commits this isn't a problem, because everyone else will > > > > > just block until all the CRTC are reconfigured. Only thing userspace > > > > > can notice is the dropped frames without any reason for why frames got > > > > > dropped. > > > > > > > > > > Consensus is that we need new uapi to handle this properly, but no one > > > > > has any idea what exactly the new uapi should look like. As a stop-gap > > > > > plug this problem by demoting nonblocking commits which might cause > > > > > issues by including CRTCs not in the original request to blocking > > > > > commits. > > > Gentle ping. I've tried out Linus's master tree and, and like Pekka, > > > I've noticed this isn't integrated/added. > > > > > > Noticed this is fixing (also) DPMS when multiple outputs are in use. > > > Wondering if we can just use a _ONCE() variant instead of WARN_ON(). I'm > > > seeing > > > the warning quite often. > > > > On which driver/chip does this happen? > I've tried it out on i915. lspci -nn please. Also adding Ville, who has an idea where this can all go wrong. The one he pointed out thus far is gen12+ only though. -Daniel > > -Daniel > > > > > > > > > > > > > Thanks for writing this up Daniel, and for reminding me about it some > > > > time later as well ... > > > > > > > > Reviewed-by: Daniel Stone > > > > > > > > Cheers, > > > > Daniel > > > > ___ > > > > dri-devel mailing list > > > > dri-de...@lists.freedesktop.org > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/4] drm/i915/hdcp: Move HDCP enc status timeout to header
DP MST stream encryption status requires time of a link frame
in order to change its status, but as there were some HDCP
encryption timeout observed earlier, it is safer to use
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS timeout for stream status too,
it requires to move the macro to a header.
It will be used by both HDCP{1.x,2.x} stream status timeout.
Related: 7e90e8d0c0ea ("drm/i915: Increase timeout for Encrypt
status change")
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 9 -
drivers/gpu/drm/i915/display/intel_hdcp.h | 2 ++
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 1d5026bb45a4..f401fdaa7336 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -23,7 +23,6 @@
#include "intel_connector.h"
#define KEY_LOAD_TRIES 5
-#define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS 50
#define HDCP2_LC_RETRY_CNT 3
static
@@ -762,7 +761,7 @@ static int intel_hdcp_auth(struct intel_connector
*connector)
if (intel_de_wait_for_set(dev_priv,
HDCP_STATUS(dev_priv, cpu_transcoder, port),
HDCP_STATUS_ENC,
- ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
+ HDCP_ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
drm_err(&dev_priv->drm, "Timed out waiting for encryption\n");
return -ETIMEDOUT;
}
@@ -809,7 +808,7 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
intel_de_write(dev_priv, HDCP_CONF(dev_priv, cpu_transcoder, port), 0);
if (intel_de_wait_for_clear(dev_priv,
HDCP_STATUS(dev_priv, cpu_transcoder, port),
- ~0, ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
+ ~0, HDCP_ENCRYPT_STATUS_CHANGE_TIMEOUT_MS))
{
drm_err(&dev_priv->drm,
"Failed to disable HDCP, timeout clearing status\n");
return -ETIMEDOUT;
@@ -1662,7 +1661,7 @@ static int hdcp2_enable_encryption(struct intel_connector
*connector)
HDCP2_STATUS(dev_priv, cpu_transcoder,
port),
LINK_ENCRYPTION_STATUS,
- ENCRYPT_STATUS_CHANGE_TIMEOUT_MS);
+ HDCP_ENCRYPT_STATUS_CHANGE_TIMEOUT_MS);
return ret;
}
@@ -1686,7 +1685,7 @@ static int hdcp2_disable_encryption(struct
intel_connector *connector)
HDCP2_STATUS(dev_priv, cpu_transcoder,
port),
LINK_ENCRYPTION_STATUS,
- ENCRYPT_STATUS_CHANGE_TIMEOUT_MS);
+ HDCP_ENCRYPT_STATUS_CHANGE_TIMEOUT_MS);
if (ret == -ETIMEDOUT)
drm_dbg_kms(&dev_priv->drm, "Disable Encryption Timedout");
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index bc51c1e9b481..b912a3a0f5b8 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -8,6 +8,8 @@
#include
+#define HDCP_ENCRYPT_STATUS_CHANGE_TIMEOUT_MS 50
+
struct drm_connector;
struct drm_connector_state;
struct drm_i915_private;
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/4] drm/i915/hdcp: DP MST transcoder for link and stream
Gen12 has H/W delta with respect to HDCP{1.x,2.x} display engine
instances lies in Transcoder instead of DDI as in Gen11.
This requires hdcp driver to use mst_master_transcoder for link
authentication and stream transcoder for stream encryption
separately.
This will be used for both HDCP 1.4 and HDCP 2.2 over DP MST
on Gen12.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
.../gpu/drm/i915/display/intel_display_types.h| 2 ++
drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
drivers/gpu/drm/i915/display/intel_hdcp.c | 15 +++
drivers/gpu/drm/i915/display/intel_hdcp.h | 2 +-
5 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 4d06178cd76c..683b252f1dbe 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3966,7 +3966,7 @@ static void intel_enable_ddi(struct intel_atomic_state
*state,
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_DESIRED)
intel_hdcp_enable(to_intel_connector(conn_state->connector),
- crtc_state->cpu_transcoder,
+ crtc_state,
(u8)conn_state->hdcp_content_type);
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 3d4bf9b6a0a2..1a9e186e4a5d 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -412,6 +412,8 @@ struct intel_hdcp {
* Hence caching the transcoder here.
*/
enum transcoder cpu_transcoder;
+ /* Only used for DP MST stream encryption */
+ enum transcoder stream_transcoder;
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 64d885539e94..79060b2aefcd 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -564,7 +564,7 @@ static void intel_mst_enable_dp(struct intel_atomic_state
*state,
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_DESIRED)
intel_hdcp_enable(to_intel_connector(conn_state->connector),
- pipe_config->cpu_transcoder,
+ pipe_config,
(u8)conn_state->hdcp_content_type);
}
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 5492076d1ae0..1d5026bb45a4 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2072,7 +2072,7 @@ int intel_hdcp_init(struct intel_connector *connector,
}
int intel_hdcp_enable(struct intel_connector *connector,
- enum transcoder cpu_transcoder, u8 content_type)
+ const struct intel_crtc_state *pipe_config, u8
content_type)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
@@ -2088,10 +2088,17 @@ int intel_hdcp_enable(struct intel_connector *connector,
drm_WARN_ON(&dev_priv->drm,
hdcp->value == DRM_MODE_CONTENT_PROTECTION_ENABLED);
hdcp->content_type = content_type;
- hdcp->cpu_transcoder = cpu_transcoder;
+
+ if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_DP_MST)) {
+ hdcp->cpu_transcoder = pipe_config->mst_master_transcoder;
+ hdcp->stream_transcoder = pipe_config->cpu_transcoder;
+ } else {
+ hdcp->cpu_transcoder = pipe_config->cpu_transcoder;
+ hdcp->stream_transcoder = INVALID_TRANSCODER;
+ }
if (INTEL_GEN(dev_priv) >= 12)
- hdcp->port_data.fw_tc = intel_get_mei_fw_tc(cpu_transcoder);
+ hdcp->port_data.fw_tc =
intel_get_mei_fw_tc(hdcp->cpu_transcoder);
/*
* Considering that HDCP2.2 is more secure than HDCP1.4, If the setup
@@ -2202,7 +2209,7 @@ void intel_hdcp_update_pipe(struct intel_atomic_state
*state,
if (desired_and_not_enabled || content_protection_type_changed)
intel_hdcp_enable(connector,
- crtc_state->cpu_transcoder,
+ crtc_state,
(u8)conn_state->hdcp_content_type);
}
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index 1bbf5b67ed0a..bc51c1e9b481 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -25,7 +25,7 @@ void intel_hdcp_atomic_check(struct drm_connector *connector,
int intel_hdcp
[Intel-gfx] [PATCH v2 4/4] drm/i915/hdcp: Enable Gen12 HDCP 1.4 DP MST support
Enable HDCP 1.4 over DP MST for Gen12.
This also enable the stream encryption support for
older generations, which was missing earlier.
v2:
- Added debug print for stream encryption.
- Disable the hdcp on port after disabling last stream
encryption.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 10 ++---
drivers/gpu/drm/i915/display/intel_hdcp.c | 46 ++---
2 files changed, 35 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 79060b2aefcd..9223d57ef3e3 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -813,13 +813,9 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
-
- /* TODO: Figure out how to make HDCP work on GEN12+ */
- if (INTEL_GEN(dev_priv) < 12) {
- ret = intel_dp_init_hdcp(dig_port, intel_connector);
- if (ret)
- DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
- }
+ ret = intel_dp_init_hdcp(dig_port, intel_connector);
+ if (ret)
+ drm_dbg_kms(&dev_priv->drm, "HDCP init failed, skipping.\n");
/*
* Reuse the prop from the SST connector because we're
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index f401fdaa7336..744cefc0c35d 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -612,7 +612,12 @@ int intel_hdcp_auth_downstream(struct intel_connector
*connector)
return ret;
}
-/* Implements Part 1 of the HDCP authorization procedure */
+/*
+ * Implements Part 1 of the HDCP authorization procedure.
+ * Authentication Part 1 steps for Multi-stream DisplayPort.
+ * Step 1. Auth Part 1 sequence on the driving MST Trasport Link.
+ * Step 2. Enable encryption for each stream that requires encryption.
+ */
static int intel_hdcp_auth(struct intel_connector *connector)
{
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
@@ -766,10 +771,16 @@ static int intel_hdcp_auth(struct intel_connector
*connector)
return -ETIMEDOUT;
}
- /*
-* XXX: If we have MST-connected devices, we need to enable encryption
-* on those as well.
-*/
+ /* DP MST Auth Part 1 Step 2.a and Step 2.b */
+ if (shim->stream_encryption) {
+ ret = shim->stream_encryption(dig_port, true);
+ if (ret) {
+ drm_err(&dev_priv->drm, "Failed to enable HDCP 1.4
stream enc\n");
+ return ret;
+ }
+ drm_dbg_kms(&dev_priv->drm, "HDCP 1.4 tras %s stream
encrypted\n",
+ transcoder_name(hdcp->stream_transcoder));
+ }
if (repeater_present)
return intel_hdcp_auth_downstream(connector);
@@ -790,19 +801,26 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
drm_dbg_kms(&dev_priv->drm, "[%s:%d] HDCP is being disabled...\n",
connector->base.name, connector->base.base.id);
+ /*
+* Step 1: Deselect HDCP Multiplestream Bit.
+* Step 2: poll for stream encryption status to be disable.
+*/
+ if (hdcp->shim->stream_encryption) {
+ ret = hdcp->shim->stream_encryption(dig_port, false);
+ if (ret) {
+ drm_err(&dev_priv->drm, "Failed to disable HDCP 1.4
stream enc\n");
+ return ret;
+ }
+ drm_dbg_kms(&dev_priv->drm, "HDCP 1.4 trans %s stream
encryption disabled\n",
+ transcoder_name(hdcp->stream_transcoder));
+ }
/*
-* If there are other connectors on this port using HDCP, don't disable
-* it. Instead, toggle the HDCP signalling off on that particular
-* connector/pipe and exit.
+* If there are other connectors on this port using HDCP, don't disable
it.
+* Repeat steps 1-2 for each stream that no longer requires encryption.
*/
- if (dig_port->num_hdcp_streams > 0) {
- ret = hdcp->shim->toggle_signalling(dig_port,
- cpu_transcoder, false);
- if (ret)
- DRM_ERROR("Failed to disable HDCP signalling\n");
+ if (dig_port->num_hdcp_streams > 0)
return ret;
- }
hdcp->hdcp_encrypted = false;
intel_de_write(dev_priv, HDCP_CONF(dev_priv, cpu_transcoder, port), 0);
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailma
[Intel-gfx] [PATCH v2 0/4] Gen12 HDCP 1.4 support on DP MST
This is the v2 version after testing DP with some rough changes in kms_content_protection IGT in order to test stream encryption with multiple streams. DP MST link authentication, stream encryption and link integrity check has been tested with this series on TGL platform. Anshuman Gupta (4): drm/i915/hdcp: DP MST transcoder for link and stream drm/i915/hdcp: Move HDCP enc status timeout to header drm/i915/hdcp: HDCP stream encryption support drm/i915/hdcp: Enable Gen12 HDCP 1.4 DP MST support drivers/gpu/drm/i915/display/intel_ddi.c | 12 +-- drivers/gpu/drm/i915/display/intel_ddi.h | 6 +- .../drm/i915/display/intel_display_types.h| 6 ++ drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 80 --- drivers/gpu/drm/i915/display/intel_dp_mst.c | 12 +-- drivers/gpu/drm/i915/display/intel_hdcp.c | 70 ++-- drivers/gpu/drm/i915/display/intel_hdcp.h | 4 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 14 ++-- drivers/gpu/drm/i915/i915_reg.h | 1 + 9 files changed, 147 insertions(+), 58 deletions(-) -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Wed, Sep 23, 2020 at 12:58:30PM +0200, Daniel Vetter wrote: > On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote: > > > > On Fri, Jan 31, 2020 at 07:34:00AM +, Daniel Stone wrote: > > > On Thu, 5 Jul 2018 at 11:21, Daniel Vetter wrote: > > > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to > > > > pull in arbitrary other resources, including CRTCs (e.g. when > > > > reconfiguring global resources). > > > > > > > > But in nonblocking mode userspace has then no idea this happened, > > > > which can lead to spurious EBUSY calls, both: > > > > - when that other CRTC is currently busy doing a page_flip the > > > > ALLOW_MODESET commit can fail with an EBUSY > > > > - on the other CRTC a normal atomic flip can fail with EBUSY because > > > > of the additional commit inserted by the kernel without userspace's > > > > knowledge > > > > > > > > For blocking commits this isn't a problem, because everyone else will > > > > just block until all the CRTC are reconfigured. Only thing userspace > > > > can notice is the dropped frames without any reason for why frames got > > > > dropped. > > > > > > > > Consensus is that we need new uapi to handle this properly, but no one > > > > has any idea what exactly the new uapi should look like. As a stop-gap > > > > plug this problem by demoting nonblocking commits which might cause > > > > issues by including CRTCs not in the original request to blocking > > > > commits. > > Gentle ping. I've tried out Linus's master tree and, and like Pekka, > > I've noticed this isn't integrated/added. > > > > Noticed this is fixing (also) DPMS when multiple outputs are in use. > > Wondering if we can just use a _ONCE() variant instead of WARN_ON(). I'm > > seeing > > the warning quite often. > > On which driver/chip does this happen? I've tried it out on i915. > -Daniel > > > > > > > > > Thanks for writing this up Daniel, and for reminding me about it some > > > time later as well ... > > > > > > Reviewed-by: Daniel Stone > > > > > > Cheers, > > > Daniel > > > ___ > > > dri-devel mailing list > > > dri-de...@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/atomic: document and enforce rules around "spurious" EBUSY
== Series Details ==
Series: series starting with [1/2] drm/atomic: document and enforce rules
around "spurious" EBUSY
URL : https://patchwork.freedesktop.org/series/82023/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a59f0f6c784d drm/atomic: document and enforce rules around "spurious" EBUSY
-:44: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#44:
References:
https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
-:71: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#71: FILE: drivers/gpu/drm/drm_atomic.c:1269:
+ unsigned requested_crtc = 0;
-:72: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#72: FILE: drivers/gpu/drm/drm_atomic.c:1270:
+ unsigned affected_crtc = 0;
-:107: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 4 warnings, 0 checks, 49 lines checked
03a8bf062d50 drm/atomic: debug output for EBUSY
-:52: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#52: FILE: drivers/gpu/drm/drm_atomic_helper.c:1741:
+ DRM_DEBUG_ATOMIC("[PLANE:%d:%s] inflight previous commit
preventing async commit\n",
+ plane->base.id, plane->name);
-:63: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#63: FILE: drivers/gpu/drm/drm_atomic_helper.c:1962:
+ DRM_DEBUG_ATOMIC("[CRTC:%d:%s] busy with a
previous commit\n",
+ crtc->base.id, crtc->name);
-:75: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#75: FILE: drivers/gpu/drm/drm_atomic_helper.c:2140:
+ DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] busy with a
previous commit\n",
+ conn->base.id, conn->name);
-:89: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#89: FILE: drivers/gpu/drm/drm_atomic_helper.c:2159:
+ DRM_DEBUG_ATOMIC("[PLANE:%d:%s] busy with a previous
commit\n",
+ plane->base.id, plane->name);
-:95: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 4 checks, 63 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 Convert all remaining drivers to GEM object functions (rev3)
== Series Details ==
Series: Convert all remaining drivers to GEM object functions (rev3)
URL : https://patchwork.freedesktop.org/series/80593/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9042 -> Patchwork_18552
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18552/index.html
Known issues
Here are the changes found in Patchwork_18552 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_9042/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18552/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
* igt@i915_module_load@reload:
- fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#1982] /
[k.org#205379])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-tgl-y/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18552/fi-tgl-y/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@coherency:
- fi-gdg-551: [PASS][5] -> [DMESG-FAIL][6] ([i915#1748])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-gdg-551/igt@i915_selftest@l...@coherency.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18552/fi-gdg-551/igt@i915_selftest@l...@coherency.html
* igt@i915_selftest@live@execlists:
- fi-icl-y: [PASS][7] -> [INCOMPLETE][8] ([i915#2276])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-icl-y/igt@i915_selftest@l...@execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18552/fi-icl-y/igt@i915_selftest@l...@execlists.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][9] -> [DMESG-WARN][10] ([i915#62] / [i915#92]
/ [i915#95])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18552/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900: [PASS][11] -> [DMESG-WARN][12] ([i915#1982])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18552/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@a-edp1:
- fi-tgl-y: [PASS][13] -> [DMESG-WARN][14] ([i915#1982])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-tgl-y/igt@kms_flip@basic-flip-vs-wf_vbl...@a-edp1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18552/fi-tgl-y/igt@kms_flip@basic-flip-vs-wf_vbl...@a-edp1.html
* igt@kms_flip@basic-flip-vs-wf_vblank@a-lvds1:
- fi-snb-2520m: [PASS][15] -> [FAIL][16] ([i915#2122])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-snb-2520m/igt@kms_flip@basic-flip-vs-wf_vbl...@a-lvds1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18552/fi-snb-2520m/igt@kms_flip@basic-flip-vs-wf_vbl...@a-lvds1.html
Possible fixes
* igt@gem_huc_copy@huc-copy:
- fi-tgl-y: [DMESG-WARN][17] ([i915#402]) -> [PASS][18] +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-tgl-y/igt@gem_huc_c...@huc-copy.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18552/fi-tgl-y/igt@gem_huc_c...@huc-copy.html
* igt@i915_module_load@reload:
- {fi-tgl-dsi}: [DMESG-WARN][19] ([i915#1982] / [k.org#205379]) ->
[PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-tgl-dsi/igt@i915_module_l...@reload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18552/fi-tgl-dsi/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18552/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
- fi-bsw-kefka: [DMESG-WARN][23] ([i915#1982]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18552/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@execlists:
- {fi-tgl-dsi}: [INCOMPLETE][25] ([i915#2268]) -> [PASS][26]
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-tgl-dsi/igt@i915_selftest@l...@execlists.ht
[Intel-gfx] [PATCH 1/2] drm/atomic: document and enforce rules around "spurious" EBUSY
When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
pull in arbitrary other resources, including CRTCs (e.g. when
reconfiguring global resources).
But in nonblocking mode userspace has then no idea this happened,
which can lead to spurious EBUSY calls, both:
- when that other CRTC is currently busy doing a page_flip the
ALLOW_MODESET commit can fail with an EBUSY
- on the other CRTC a normal atomic flip can fail with EBUSY because
of the additional commit inserted by the kernel without userspace's
knowledge
For blocking commits this isn't a problem, because everyone else will
just block until all the CRTC are reconfigured. Only thing userspace
can notice is the dropped frames without any reason for why frames got
dropped.
Consensus is that we need new uapi to handle this properly, but no one
has any idea what exactly the new uapi should look like. Since this
has been shipping for years already compositors need to deal no matter
what, so as a first step just try to enforce this across drivers
better with some checks.
v2: Add comments and a WARN_ON to enforce this only when allowed - we
don't want to silently convert page flips into blocking plane updates
just because the driver is buggy.
v3: Fix inverted WARN_ON (Pekka).
v4: Drop the uapi changes, only add a WARN_ON for now to enforce some
rules for drivers.
v5: Make the WARNING more informative (Daniel)
References:
https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
Cc: Daniel Stone
Cc: Pekka Paalanen
Cc: Simon Ser
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 58527f151984..e22669b64521 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -281,6 +281,10 @@ EXPORT_SYMBOL(__drm_atomic_state_free);
* needed. It will also grab the relevant CRTC lock to make sure that the state
* is consistent.
*
+ * WARNING: Drivers may only add new CRTC states to a @state if
+ * drm_atomic_state.allow_modeset is set, or if it's a driver-internal commit
+ * not created by userspace through an IOCTL call.
+ *
* Returns:
*
* Either the allocated state or the error code encoded into the pointer. When
@@ -1262,10 +1266,15 @@ int drm_atomic_check_only(struct drm_atomic_state
*state)
struct drm_crtc_state *new_crtc_state;
struct drm_connector *conn;
struct drm_connector_state *conn_state;
+ unsigned requested_crtc = 0;
+ unsigned affected_crtc = 0;
int i, ret = 0;
DRM_DEBUG_ATOMIC("checking %p\n", state);
+ for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
+ requested_crtc |= drm_crtc_mask(crtc);
+
for_each_oldnew_plane_in_state(state, plane, old_plane_state,
new_plane_state, i) {
ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
if (ret) {
@@ -1313,6 +1322,24 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
}
}
+ for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
+ affected_crtc |= drm_crtc_mask(crtc);
+
+ /*
+* For commits that allow modesets drivers can add other CRTCs to the
+* atomic commit, e.g. when they need to reallocate global resources.
+* This can cause spurious EBUSY, which robs compositors of a very
+* effective sanity check for their drawing loop. Therefor only allow
+* drivers to add unrelated CRTC states for modeset commits.
+*
+* FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an output
+* so compositors know what's going on.
+*/
+ if (affected_crtc != requested_crtc) {
+ WARN(!state->allow_modeset, "adding CRTC not allowed without
modesets: requested 0x%x, affected 0x%0x\n",
+requested_crtc, affected_crtc);
+ }
+
return 0;
}
EXPORT_SYMBOL(drm_atomic_check_only);
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote: > > On Fri, Jan 31, 2020 at 07:34:00AM +, Daniel Stone wrote: > > On Thu, 5 Jul 2018 at 11:21, Daniel Vetter wrote: > > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to > > > pull in arbitrary other resources, including CRTCs (e.g. when > > > reconfiguring global resources). > > > > > > But in nonblocking mode userspace has then no idea this happened, > > > which can lead to spurious EBUSY calls, both: > > > - when that other CRTC is currently busy doing a page_flip the > > > ALLOW_MODESET commit can fail with an EBUSY > > > - on the other CRTC a normal atomic flip can fail with EBUSY because > > > of the additional commit inserted by the kernel without userspace's > > > knowledge > > > > > > For blocking commits this isn't a problem, because everyone else will > > > just block until all the CRTC are reconfigured. Only thing userspace > > > can notice is the dropped frames without any reason for why frames got > > > dropped. > > > > > > Consensus is that we need new uapi to handle this properly, but no one > > > has any idea what exactly the new uapi should look like. As a stop-gap > > > plug this problem by demoting nonblocking commits which might cause > > > issues by including CRTCs not in the original request to blocking > > > commits. > Gentle ping. I've tried out Linus's master tree and, and like Pekka, > I've noticed this isn't integrated/added. > > Noticed this is fixing (also) DPMS when multiple outputs are in use. > Wondering if we can just use a _ONCE() variant instead of WARN_ON(). I'm > seeing > the warning quite often. On which driver/chip does this happen? -Daniel > > > > > Thanks for writing this up Daniel, and for reminding me about it some > > time later as well ... > > > > Reviewed-by: Daniel Stone > > > > Cheers, > > Daniel > > ___ > > dri-devel mailing list > > dri-de...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/atomic: debug output for EBUSY
Hopefully we'll have the drm crash recorder RSN, but meanwhile
compositors would like to know a bit better why they get an EBUSY.
Cc: Sean Paul
Cc: Daniel Stone
Cc: Pekka Paalanen
Cc: Simon Ser
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c| 4 ++--
drivers/gpu/drm/drm_atomic_helper.c | 20 +---
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index e22669b64521..6864e520269d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1272,7 +1272,7 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
DRM_DEBUG_ATOMIC("checking %p\n", state);
- for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
+ for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
requested_crtc |= drm_crtc_mask(crtc);
for_each_oldnew_plane_in_state(state, plane, old_plane_state,
new_plane_state, i) {
@@ -1322,7 +1322,7 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
}
}
- for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
+ for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
affected_crtc |= drm_crtc_mask(crtc);
/*
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index e8ab7fd1..6b3bfabac26c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1740,8 +1740,11 @@ int drm_atomic_helper_async_check(struct drm_device *dev,
* overridden by a previous synchronous update's state.
*/
if (old_plane_state->commit &&
- !try_wait_for_completion(&old_plane_state->commit->hw_done))
+ !try_wait_for_completion(&old_plane_state->commit->hw_done)) {
+ DRM_DEBUG_ATOMIC("[PLANE:%d:%s] inflight previous commit
preventing async commit\n",
+ plane->base.id, plane->name);
return -EBUSY;
+ }
return funcs->atomic_async_check(plane, new_plane_state);
}
@@ -1964,6 +1967,9 @@ static int stall_checks(struct drm_crtc *crtc, bool
nonblock)
* commit with nonblocking ones. */
if (!completed && nonblock) {
spin_unlock(&crtc->commit_lock);
+ DRM_DEBUG_ATOMIC("[CRTC:%d:%s] busy with a
previous commit\n",
+ crtc->base.id, crtc->name);
+
return -EBUSY;
}
} else if (i == 1) {
@@ -2132,8 +2138,12 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
/* Userspace is not allowed to get ahead of the previous
* commit with nonblocking ones. */
if (nonblock && old_conn_state->commit &&
-
!try_wait_for_completion(&old_conn_state->commit->flip_done))
+
!try_wait_for_completion(&old_conn_state->commit->flip_done)) {
+ DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] busy with a
previous commit\n",
+ conn->base.id, conn->name);
+
return -EBUSY;
+ }
/* Always track connectors explicitly for e.g. link retraining.
*/
commit = crtc_or_fake_commit(state, new_conn_state->crtc ?:
old_conn_state->crtc);
@@ -2147,8 +2157,12 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
/* Userspace is not allowed to get ahead of the previous
* commit with nonblocking ones. */
if (nonblock && old_plane_state->commit &&
-
!try_wait_for_completion(&old_plane_state->commit->flip_done))
+
!try_wait_for_completion(&old_plane_state->commit->flip_done)) {
+ DRM_DEBUG_ATOMIC("[PLANE:%d:%s] busy with a previous
commit\n",
+ plane->base.id, plane->name);
+
return -EBUSY;
+ }
/* Always track planes explicitly for async pageflip support. */
commit = crtc_or_fake_commit(state, new_plane_state->crtc ?:
old_plane_state->crtc);
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: document and enforce rules around "spurious" EBUSY from atomic_commit
On Wed, Sep 23, 2020 at 12:31 PM Ville Syrjälä
wrote:
>
> On Tue, Sep 22, 2020 at 08:18:34PM +0200, Daniel Vetter wrote:
> > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > pull in arbitrary other resources, including CRTCs (e.g. when
> > reconfiguring global resources).
> >
> > But in nonblocking mode userspace has then no idea this happened,
> > which can lead to spurious EBUSY calls, both:
> > - when that other CRTC is currently busy doing a page_flip the
> > ALLOW_MODESET commit can fail with an EBUSY
> > - on the other CRTC a normal atomic flip can fail with EBUSY because
> > of the additional commit inserted by the kernel without userspace's
> > knowledge
> >
> > For blocking commits this isn't a problem, because everyone else will
> > just block until all the CRTC are reconfigured. Only thing userspace
> > can notice is the dropped frames without any reason for why frames got
> > dropped.
> >
> > Consensus is that we need new uapi to handle this properly, but no one
> > has any idea what exactly the new uapi should look like. Since this
> > has been shipping for years already compositors need to deal no matter
> > what, so as a first step just try to enforce this across drivers
> > better with some checks.
> >
> > v2: Add comments and a WARN_ON to enforce this only when allowed - we
> > don't want to silently convert page flips into blocking plane updates
> > just because the driver is buggy.
> >
> > v3: Fix inverted WARN_ON (Pekka).
> >
> > v4: Drop the uapi changes, only add a WARN_ON for now to enforce some
> > rules for drivers.
> >
> > References:
> > https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
> > Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
> > Cc: Daniel Stone
> > Cc: Pekka Paalanen
> > Cc: Simon Ser
> > Cc: sta...@vger.kernel.org
> > Cc: Ville Syrjälä
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_atomic.c | 27 +++
> > 1 file changed, 27 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 58527f151984..ef106e7153a6 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -281,6 +281,10 @@ EXPORT_SYMBOL(__drm_atomic_state_free);
> > * needed. It will also grab the relevant CRTC lock to make sure that the
> > state
> > * is consistent.
> > *
> > + * WARNING: Drivers may only add new CRTC states to a @state if
> > + * drm_atomic_state.allow_modeset is set, or if it's a driver-internal
> > commit
> > + * not created by userspace through an IOCTL call.
> > + *
> > * Returns:
> > *
> > * Either the allocated state or the error code encoded into the pointer.
> > When
> > @@ -1262,10 +1266,15 @@ int drm_atomic_check_only(struct drm_atomic_state
> > *state)
> > struct drm_crtc_state *new_crtc_state;
> > struct drm_connector *conn;
> > struct drm_connector_state *conn_state;
> > + unsigned requested_crtc = 0;
> > + unsigned affected_crtc = 0;
> > int i, ret = 0;
> >
> > DRM_DEBUG_ATOMIC("checking %p\n", state);
> >
> > + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> > + requested_crtc |= drm_crtc_mask(crtc);
> > +
> > for_each_oldnew_plane_in_state(state, plane, old_plane_state,
> > new_plane_state, i) {
> > ret = drm_atomic_plane_check(old_plane_state,
> > new_plane_state);
> > if (ret) {
> > @@ -1313,6 +1322,24 @@ int drm_atomic_check_only(struct drm_atomic_state
> > *state)
> > }
> > }
> >
> > + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
>
> Inconsistent old vs. new.
Will fix, but also doesn't matter since I don't care about the state,
just that it's in there.
> > + affected_crtc |= drm_crtc_mask(crtc);
> > +
> > + /*
> > + * For commits that allow modesets drivers can add other CRTCs to the
> > + * atomic commit, e.g. when they need to reallocate global resources.
> > + * This can cause spurious EBUSY, which robs compositors of a very
> > + * effective sanity check for their drawing loop. Therefor only allow
> > + * this for modeset commits.
> > + *
> > + * FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an
> > output
> > + * so compositors know what's going on.
> > + */
> > + if (affected_crtc != requested_crtc) {
> > + /* adding other CRTC is only allowed for modeset commits */
> > + WARN_ON(!state->allow_modeset);
> > + }
>
> I think this means pretty much all non-pageflip commits will
> have to have allow_modeset==true on i915 or else we just can't
> guarantee that we can anything (due to sagv and/or cdclk mainly).
I guess not enough machines with multiple outputs in the shards.
> Also a bit baffled that CI didn't hit this. I think it should be
> totally possible to hit this now. To avoid that I gues
Re: [Intel-gfx] [V13 5/5] drm/i915/dsi: Enable software vblank counter
On Wed, Sep 23, 2020 at 10:16:05AM +, Kulkarni, Vandita wrote:
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Wednesday, September 23, 2020 3:30 PM
> > To: Kulkarni, Vandita
> > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > Subject: Re: [V13 5/5] drm/i915/dsi: Enable software vblank counter
> >
> > On Tue, Sep 22, 2020 at 07:14:26PM +0530, Vandita Kulkarni wrote:
> > > In case of DSI cmd mode, we get hw vblank counter updated after the TE
> > > comes in, if we try to read the hw vblank counter in te handler we
> > > wouldnt have the udpated vblank counter yet.
> > > This will lead to a state where we would send the vblank event to the
> > > user space in the next te, though the frame update would have
> > > completed in the first TE duration itself.
> > > Hence switch to using software timestamp based vblank counter.
> > >
> > > Signed-off-by: Vandita Kulkarni
> > > ---
> > > drivers/gpu/drm/i915/display/intel_display.c | 11 +++
> > > drivers/gpu/drm/i915/i915_irq.c | 4
> > > 2 files changed, 15 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index c4f331f2af45..8b9e59e52708 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -1808,6 +1808,17 @@ enum pipe intel_crtc_pch_transcoder(struct
> > > intel_crtc *crtc) static u32 intel_crtc_max_vblank_count(const struct
> > > intel_crtc_state *crtc_state) {
> > > struct drm_i915_private *dev_priv =
> > > to_i915(crtc_state->uapi.crtc->dev);
> > > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > + u32 flags = crtc->mode_flags;
> >
> > That's wrong. You need to look at the crtc_state instead.
>
> Thanks,
> I will use crtc_state.
I'd also frop the 'flags' variable. Single use so not much point.
Or at the very least call it 'mode_flags' so we know what it
actually is.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Convert all remaining drivers to GEM object functions (rev3)
== Series Details == Series: Convert all remaining drivers to GEM object functions (rev3) URL : https://patchwork.freedesktop.org/series/80593/ State : warning == Summary == $ dim checkpatch origin/drm-tip e68833e29f33 drm/amdgpu: Introduce GEM object functions c2ca03d5a2f6 drm/armada: Introduce GEM object functions f4bf6cb00591 drm/etnaviv: Introduce GEM object functions 51aa6b22d3cd drm/exynos: Introduce GEM object functions 83aa7ecb3b26 drm/gma500: Introduce GEM object functions 403f5cb7b9c5 drm/i915: Introduce GEM object functions 186114199dd4 drm/imx/dcss: Initialize DRM driver instance with CMA helper macro d2560e174c6b drm/mediatek: Introduce GEM object functions 397302d4830c drm/msm: Introduce GEM object funcs 5197f3332932 drm/nouveau: Introduce GEM object functions 130b2aad73de drm/omapdrm: Introduce GEM object functions b0df04425f42 drm/pl111: Introduce GEM object functions cb12d2a37716 drm/radeon: Introduce GEM object functions -:97: WARNING:AVOID_EXTERNS: externs should be avoided in .c files #97: FILE: drivers/gpu/drm/radeon/radeon_gem.c:41: +int radeon_gem_prime_pin(struct drm_gem_object *obj); -:98: WARNING:AVOID_EXTERNS: externs should be avoided in .c files #98: FILE: drivers/gpu/drm/radeon/radeon_gem.c:42: +void radeon_gem_prime_unpin(struct drm_gem_object *obj); -:100: WARNING:AVOID_EXTERNS: externs should be avoided in .c files #100: FILE: drivers/gpu/drm/radeon/radeon_gem.c:44: +void radeon_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr); total: 0 errors, 3 warnings, 0 checks, 118 lines checked fcc349b8c7fe drm/rockchip: Convert to drm_gem_object_funcs 0a9fb555f5bb drm/tegra: Introduce GEM object functions 180a1cc2a27b drm/vc4: Introduce GEM object functions f590e1e0e873 drm/vgem: Introduce GEM object functions eb3ee8cd3768 drm/virtgpu: Set PRIME export function in struct drm_gem_object_funcs ebd599450be2 drm/vkms: Introduce GEM object functions faaa00075c90 drm/xen: Introduce GEM object functions 9c03b50d30f0 drm/xlnx: Initialize DRM driver instance with CMA helper macro 9968e704252c drm: Remove obsolete GEM and PRIME callbacks from struct drm_driver -:298: WARNING:ENOSYS: ENOSYS means 'invalid syscall nr' and nothing else #298: FILE: drivers/gpu/drm/drm_prime.c:624: + return ERR_PTR(-ENOSYS); total: 0 errors, 1 warnings, 0 checks, 376 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [V13 4/5] drm/i915/dsi: Initiate fame request in cmd mode
On Wed, Sep 23, 2020 at 10:02:49AM +, Kulkarni, Vandita wrote:
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Wednesday, September 23, 2020 3:30 PM
> > To: Kulkarni, Vandita
> > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > Subject: Re: [V13 4/5] drm/i915/dsi: Initiate fame request in cmd mode
> >
> > On Tue, Sep 22, 2020 at 07:14:25PM +0530, Vandita Kulkarni wrote:
> > > In TE Gate mode or TE NO_GATE mode on every flip we need to set the
> > > frame update request bit.
> > > After this bit is set transcoder hardware will automatically send the
> > > frame data to the panel in case of TE NO_GATE mode, where it sends
> > > after it receives the TE event in case of TE_GATE mode.
> > > Once the frame data is sent to the panel, we see the frame counter
> > > updating.
> > >
> > > v2: Use intel_de_read/write
> > >
> > > v3: remove the usage of private_flags
> > >
> > > v4: Use icl_dsi in func names if non static,
> > > fix code formatting issues. (Jani)
> > >
> > > Signed-off-by: Vandita Kulkarni
> > > ---
> > > drivers/gpu/drm/i915/display/icl_dsi.c | 26
> > > drivers/gpu/drm/i915/display/intel_display.c | 10
> > > drivers/gpu/drm/i915/display/intel_dsi.h | 1 +
> > > 3 files changed, 37 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > > index 2789020e20db..7d2abc7f6ba3 100644
> > > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > > @@ -205,6 +205,32 @@ static int dsi_send_pkt_payld(struct intel_dsi_host
> > *host,
> > > return 0;
> > > }
> > >
> > > +void icl_dsi_frame_update(struct intel_crtc_state *crtc_state) {
> > > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > + u32 tmp, flags;
> > > + enum port port;
> > > +
> > > + flags = crtc->mode_flags;
> > > +
> > > + /*
> > > + * case 1 also covers dual link
> > > + * In case of dual link, frame update should be set on
> > > + * DSI_0
> > > + */
> > > + if (flags & I915_MODE_FLAG_DSI_USE_TE0)
> > > + port = PORT_A;
> > > + else if (flags & I915_MODE_FLAG_DSI_USE_TE1)
> > > + port = PORT_B;
> > > + else
> > > + return;
> > > +
> > > + tmp = intel_de_read(dev_priv, DSI_CMD_FRMCTL(port));
> > > + tmp |= DSI_FRAME_UPDATE_REQUEST;
> > > + intel_de_write(dev_priv, DSI_CMD_FRMCTL(port), tmp); }
> > > +
> > > static void dsi_program_swing_and_deemphasis(struct intel_encoder
> > > *encoder) {
> > > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > diff
> > > --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 5a9d933e425a..c4f331f2af45 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -15616,6 +15616,16 @@ static void intel_atomic_commit_tail(struct
> > intel_atomic_state *state)
> > > intel_set_cdclk_post_plane_update(state);
> > > }
> > >
> > > + /*
> > > + * Incase of mipi dsi command mode, we need to set frame update
> > > + * for every commit
> > > + */
> > > + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
> > > + if (INTEL_GEN(dev_priv) >= 11 &&
> > > + intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI))
> > > + if (new_crtc_state->hw.active)
> > > + icl_dsi_frame_update(new_crtc_state);
> > > +
> >
> > Still the wrong place.
> Should I be adding it at the end of pipe update? As we need TE to be enabled
> when we send frame update.
If it needs te then it should probably enable te.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: document and enforce rules around "spurious" EBUSY from atomic_commit
On Tue, Sep 22, 2020 at 08:18:34PM +0200, Daniel Vetter wrote:
> When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> pull in arbitrary other resources, including CRTCs (e.g. when
> reconfiguring global resources).
>
> But in nonblocking mode userspace has then no idea this happened,
> which can lead to spurious EBUSY calls, both:
> - when that other CRTC is currently busy doing a page_flip the
> ALLOW_MODESET commit can fail with an EBUSY
> - on the other CRTC a normal atomic flip can fail with EBUSY because
> of the additional commit inserted by the kernel without userspace's
> knowledge
>
> For blocking commits this isn't a problem, because everyone else will
> just block until all the CRTC are reconfigured. Only thing userspace
> can notice is the dropped frames without any reason for why frames got
> dropped.
>
> Consensus is that we need new uapi to handle this properly, but no one
> has any idea what exactly the new uapi should look like. Since this
> has been shipping for years already compositors need to deal no matter
> what, so as a first step just try to enforce this across drivers
> better with some checks.
>
> v2: Add comments and a WARN_ON to enforce this only when allowed - we
> don't want to silently convert page flips into blocking plane updates
> just because the driver is buggy.
>
> v3: Fix inverted WARN_ON (Pekka).
>
> v4: Drop the uapi changes, only add a WARN_ON for now to enforce some
> rules for drivers.
>
> References:
> https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
> Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
> Cc: Daniel Stone
> Cc: Pekka Paalanen
> Cc: Simon Ser
> Cc: sta...@vger.kernel.org
> Cc: Ville Syrjälä
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic.c | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 58527f151984..ef106e7153a6 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -281,6 +281,10 @@ EXPORT_SYMBOL(__drm_atomic_state_free);
> * needed. It will also grab the relevant CRTC lock to make sure that the
> state
> * is consistent.
> *
> + * WARNING: Drivers may only add new CRTC states to a @state if
> + * drm_atomic_state.allow_modeset is set, or if it's a driver-internal commit
> + * not created by userspace through an IOCTL call.
> + *
> * Returns:
> *
> * Either the allocated state or the error code encoded into the pointer.
> When
> @@ -1262,10 +1266,15 @@ int drm_atomic_check_only(struct drm_atomic_state
> *state)
> struct drm_crtc_state *new_crtc_state;
> struct drm_connector *conn;
> struct drm_connector_state *conn_state;
> + unsigned requested_crtc = 0;
> + unsigned affected_crtc = 0;
> int i, ret = 0;
>
> DRM_DEBUG_ATOMIC("checking %p\n", state);
>
> + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> + requested_crtc |= drm_crtc_mask(crtc);
> +
> for_each_oldnew_plane_in_state(state, plane, old_plane_state,
> new_plane_state, i) {
> ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
> if (ret) {
> @@ -1313,6 +1322,24 @@ int drm_atomic_check_only(struct drm_atomic_state
> *state)
> }
> }
>
> + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
Inconsistent old vs. new.
> + affected_crtc |= drm_crtc_mask(crtc);
> +
> + /*
> + * For commits that allow modesets drivers can add other CRTCs to the
> + * atomic commit, e.g. when they need to reallocate global resources.
> + * This can cause spurious EBUSY, which robs compositors of a very
> + * effective sanity check for their drawing loop. Therefor only allow
> + * this for modeset commits.
> + *
> + * FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an output
> + * so compositors know what's going on.
> + */
> + if (affected_crtc != requested_crtc) {
> + /* adding other CRTC is only allowed for modeset commits */
> + WARN_ON(!state->allow_modeset);
> + }
I think this means pretty much all non-pageflip commits will
have to have allow_modeset==true on i915 or else we just can't
guarantee that we can anything (due to sagv and/or cdclk mainly).
Also a bit baffled that CI didn't hit this. I think it should be
totally possible to hit this now. To avoid that I guess we'd just
need to make intel_atomic_serialize_global_state() fail if it
has to add any new crtcs when allow_modeset==false. Hopefully
there aren't many other places that add crtcs to the state
without forcing a modeset on them.
> +
> return 0;
> }
> EXPORT_SYMBOL(drm_atomic_check_only);
> --
> 2.28.0
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.or
[Intel-gfx] [PATCH v3 21/22] drm/xlnx: Initialize DRM driver instance with CMA helper macro
The xlnx driver uses CMA helpers with default callback functions.
Initialize the driver structure with the rsp CMA helper macro. The
driver is being converted to use GEM object functions as part of
this change.
Two callbacks, .dumb_destroy and .gem_prime_import, were initialized
to their default implementations, so they are just kept empty now.
v2:
* initialize with DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE (Laurent)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Reviewed-by: Hyun Kwon
---
drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
index 8e69303aad3f..f3ffc3703a0e 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
@@ -80,19 +80,7 @@ static struct drm_driver zynqmp_dpsub_drm_driver = {
.driver_features= DRIVER_MODESET | DRIVER_GEM |
DRIVER_ATOMIC,
- .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_export = drm_gem_prime_export,
- .gem_prime_import = drm_gem_prime_import,
- .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
- .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_vmap = drm_gem_cma_prime_vmap,
- .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
- .gem_prime_mmap = drm_gem_cma_prime_mmap,
- .gem_free_object_unlocked = drm_gem_cma_free_object,
- .gem_vm_ops = &drm_gem_cma_vm_ops,
- .dumb_create= zynqmp_dpsub_dumb_create,
- .dumb_destroy = drm_gem_dumb_destroy,
+ DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE(zynqmp_dpsub_dumb_create),
.fops = &zynqmp_dpsub_drm_fops,
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 17/22] drm/vgem: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in vgem. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Melissa Wen
---
drivers/gpu/drm/vgem/vgem_drv.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index cb884c890065..fa54a6d1403d 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -50,6 +50,8 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
+static const struct drm_gem_object_funcs vgem_gem_object_funcs;
+
static struct vgem_device {
struct drm_device drm;
struct platform_device *platform;
@@ -167,6 +169,8 @@ static struct drm_vgem_gem_object *__vgem_gem_create(struct
drm_device *dev,
if (!obj)
return ERR_PTR(-ENOMEM);
+ obj->base.funcs = &vgem_gem_object_funcs;
+
ret = drm_gem_object_init(dev, &obj->base, roundup(size, PAGE_SIZE));
if (ret) {
kfree(obj);
@@ -401,12 +405,20 @@ static int vgem_prime_mmap(struct drm_gem_object *obj,
return 0;
}
+static const struct drm_gem_object_funcs vgem_gem_object_funcs = {
+ .free = vgem_gem_free_object,
+ .pin = vgem_prime_pin,
+ .unpin = vgem_prime_unpin,
+ .get_sg_table = vgem_prime_get_sg_table,
+ .vmap = vgem_prime_vmap,
+ .vunmap = vgem_prime_vunmap,
+ .vm_ops = &vgem_gem_vm_ops,
+};
+
static struct drm_driver vgem_driver = {
.driver_features= DRIVER_GEM | DRIVER_RENDER,
.open = vgem_open,
.postclose = vgem_postclose,
- .gem_free_object_unlocked = vgem_gem_free_object,
- .gem_vm_ops = &vgem_gem_vm_ops,
.ioctls = vgem_ioctls,
.num_ioctls = ARRAY_SIZE(vgem_ioctls),
.fops = &vgem_driver_fops,
@@ -415,13 +427,8 @@ static struct drm_driver vgem_driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_pin = vgem_prime_pin,
- .gem_prime_unpin = vgem_prime_unpin,
.gem_prime_import = vgem_prime_import,
.gem_prime_import_sg_table = vgem_prime_import_sg_table,
- .gem_prime_get_sg_table = vgem_prime_get_sg_table,
- .gem_prime_vmap = vgem_prime_vmap,
- .gem_prime_vunmap = vgem_prime_vunmap,
.gem_prime_mmap = vgem_prime_mmap,
.name = DRIVER_NAME,
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 20/22] drm/xen: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in xen. The only exception is gem_prime_mmap,
which is non-trivial to convert.
v2:
* convert xen_drm_drv_free_object_unlocked() to static
callback (Oleksandr)
Signed-off-by: Thomas Zimmermann
Acked-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front.c | 44 ++---
drivers/gpu/drm/xen/xen_drm_front.h | 2 ++
drivers/gpu/drm/xen/xen_drm_front_gem.c | 15 +
3 files changed, 34 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_front.c
index cc93a8c9547b..98b6d2ba088a 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -381,6 +381,23 @@ void xen_drm_front_on_frame_done(struct xen_drm_front_info
*front_info,
fb_cookie);
}
+void xen_drm_front_gem_object_free(struct drm_gem_object *obj)
+{
+ struct xen_drm_front_drm_info *drm_info = obj->dev->dev_private;
+ int idx;
+
+ if (drm_dev_enter(obj->dev, &idx)) {
+ xen_drm_front_dbuf_destroy(drm_info->front_info,
+ xen_drm_front_dbuf_to_cookie(obj));
+ drm_dev_exit(idx);
+ } else {
+ dbuf_free(&drm_info->front_info->dbuf_list,
+ xen_drm_front_dbuf_to_cookie(obj));
+ }
+
+ xen_drm_front_gem_free_object_unlocked(obj);
+}
+
static int xen_drm_drv_dumb_create(struct drm_file *filp,
struct drm_device *dev,
struct drm_mode_create_dumb *args)
@@ -435,23 +452,6 @@ static int xen_drm_drv_dumb_create(struct drm_file *filp,
return ret;
}
-static void xen_drm_drv_free_object_unlocked(struct drm_gem_object *obj)
-{
- struct xen_drm_front_drm_info *drm_info = obj->dev->dev_private;
- int idx;
-
- if (drm_dev_enter(obj->dev, &idx)) {
- xen_drm_front_dbuf_destroy(drm_info->front_info,
- xen_drm_front_dbuf_to_cookie(obj));
- drm_dev_exit(idx);
- } else {
- dbuf_free(&drm_info->front_info->dbuf_list,
- xen_drm_front_dbuf_to_cookie(obj));
- }
-
- xen_drm_front_gem_free_object_unlocked(obj);
-}
-
static void xen_drm_drv_release(struct drm_device *dev)
{
struct xen_drm_front_drm_info *drm_info = dev->dev_private;
@@ -483,22 +483,12 @@ static const struct file_operations xen_drm_dev_fops = {
.mmap = xen_drm_front_gem_mmap,
};
-static const struct vm_operations_struct xen_drm_drv_vm_ops = {
- .open = drm_gem_vm_open,
- .close = drm_gem_vm_close,
-};
-
static struct drm_driver xen_drm_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET |
DRIVER_ATOMIC,
.release = xen_drm_drv_release,
- .gem_vm_ops= &xen_drm_drv_vm_ops,
- .gem_free_object_unlocked = xen_drm_drv_free_object_unlocked,
.prime_handle_to_fd= drm_gem_prime_handle_to_fd,
.prime_fd_to_handle= drm_gem_prime_fd_to_handle,
.gem_prime_import_sg_table = xen_drm_front_gem_import_sg_table,
- .gem_prime_get_sg_table= xen_drm_front_gem_get_sg_table,
- .gem_prime_vmap= xen_drm_front_gem_prime_vmap,
- .gem_prime_vunmap = xen_drm_front_gem_prime_vunmap,
.gem_prime_mmap= xen_drm_front_gem_prime_mmap,
.dumb_create = xen_drm_drv_dumb_create,
.fops = &xen_drm_dev_fops,
diff --git a/drivers/gpu/drm/xen/xen_drm_front.h
b/drivers/gpu/drm/xen/xen_drm_front.h
index 54486d89650e..cefafe859aba 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.h
+++ b/drivers/gpu/drm/xen/xen_drm_front.h
@@ -160,4 +160,6 @@ int xen_drm_front_page_flip(struct xen_drm_front_info
*front_info,
void xen_drm_front_on_frame_done(struct xen_drm_front_info *front_info,
int conn_idx, u64 fb_cookie);
+void xen_drm_front_gem_object_free(struct drm_gem_object *obj);
+
#endif /* __XEN_DRM_FRONT_H_ */
diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index 2f464ef2d53e..4f34ef34ba60 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -57,6 +57,19 @@ static void gem_free_pages_array(struct xen_gem_object
*xen_obj)
xen_obj->pages = NULL;
}
+static const struct vm_operations_struct xen_drm_drv_vm_ops = {
+ .open = drm_gem_vm_open,
+ .close = drm_gem_vm_close,
+};
+
+static const struct drm_gem_object_funcs xen_drm_front_gem_object_funcs = {
+ .free = xen_drm_front_gem_object_free,
+ .
[Intel-gfx] [PATCH v3 22/22] drm: Remove obsolete GEM and PRIME callbacks from struct drm_driver
Several GEM and PRIME callbacks have been deprecated in favor of
per-instance GEM object functions. Remove the callbacks as they are
now unused. The only exception is .gem_prime_mmap, which is still
in use by several drivers.
What is also gone is gem_vm_ops in struct drm_driver. All drivers now
use struct drm_gem_object_funcs.vm_ops instead.
While at it, the patch also improves error handling around calls
to .free and .get_sg_table callbacks.
v3:
* restore default call to drm_gem_prime_export() in
drm_gem_prime_handle_to_fd()
* return -ENOSYS if get_sg_table is not set
* drop all checks for obj->funcs
* clean up TODO list and documentation
v2:
* update related TODO item (Sam)
Signed-off-by: Thomas Zimmermann
Acked-by: Daniel Vetter
---
Documentation/gpu/drm-mm.rst | 4 +-
Documentation/gpu/todo.rst | 9 +--
drivers/gpu/drm/drm_gem.c| 53 ++---
drivers/gpu/drm/drm_gem_cma_helper.c | 8 +--
drivers/gpu/drm/drm_prime.c | 14 ++---
include/drm/drm_drv.h| 85 ++--
include/drm/drm_gem.h| 2 +-
7 files changed, 38 insertions(+), 137 deletions(-)
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index 9abee1589c1e..21be6deadc12 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -182,11 +182,11 @@ acquired and release by calling drm_gem_object_get() and
drm_gem_object_put()
respectively.
When the last reference to a GEM object is released the GEM core calls
-the :c:type:`struct drm_driver ` gem_free_object_unlocked
+the :c:type:`struct drm_gem_object_funcs ` free
operation. That operation is mandatory for GEM-enabled drivers and must
free the GEM object and all associated resources.
-void (\*gem_free_object) (struct drm_gem_object \*obj); Drivers are
+void (\*free) (struct drm_gem_object \*obj); Drivers are
responsible for freeing all GEM object resources. This includes the
resources created by the GEM core, which need to be released with
drm_gem_object_release().
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index b0ea17da8ff6..3751ac976c3e 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -149,7 +149,7 @@ have to keep track of that lock and either call
``unreference`` or
``unreference_locked`` depending upon context.
Core GEM doesn't have a need for ``struct_mutex`` any more since kernel 4.8,
-and there's a ``gem_free_object_unlocked`` callback for any drivers which are
+and there's a GEM object ``free`` callback for any drivers which are
entirely ``struct_mutex`` free.
For drivers that need ``struct_mutex`` it should be replaced with a driver-
@@ -289,11 +289,8 @@ struct drm_gem_object_funcs
---
GEM objects can now have a function table instead of having the callbacks on
the
-DRM driver struct. This is now the preferred way and drivers can be moved over.
-
-We also need a 2nd version of the CMA define that doesn't require the
-vmapping to be present (different hook for prime importing). Plus this needs to
-be rolled out to all drivers using their own implementations, too.
+DRM driver struct. This is now the preferred way. Callbacks in drivers have
been
+converted, except for struct drm_driver.gem_prime_mmap.
Level: Intermediate
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 19d73868490e..1da67d34e55d 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -247,12 +247,9 @@ drm_gem_object_release_handle(int id, void *ptr, void
*data)
{
struct drm_file *file_priv = data;
struct drm_gem_object *obj = ptr;
- struct drm_device *dev = obj->dev;
- if (obj->funcs && obj->funcs->close)
+ if (obj->funcs->close)
obj->funcs->close(obj, file_priv);
- else if (dev->driver->gem_close_object)
- dev->driver->gem_close_object(obj, file_priv);
drm_gem_remove_prime_handles(obj, file_priv);
drm_vma_node_revoke(&obj->vma_node, file_priv);
@@ -403,14 +400,10 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
if (ret)
goto err_remove;
- if (obj->funcs && obj->funcs->open) {
+ if (obj->funcs->open) {
ret = obj->funcs->open(obj, file_priv);
if (ret)
goto err_revoke;
- } else if (dev->driver->gem_open_object) {
- ret = dev->driver->gem_open_object(obj, file_priv);
- if (ret)
- goto err_revoke;
}
*handlep = handle;
@@ -982,12 +975,11 @@ drm_gem_object_free(struct kref *kref)
{
struct drm_gem_object *obj =
container_of(kref, struct drm_gem_object, refcount);
- struct drm_device *dev = obj->dev;
- if (obj->funcs)
- obj->funcs->free(obj);
- else if (dev->drive
[Intel-gfx] [PATCH v3 16/22] drm/vc4: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in vc4. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_bo.c | 21 -
drivers/gpu/drm/vc4/vc4_drv.c | 12
drivers/gpu/drm/vc4/vc4_drv.h | 1 -
3 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 74ceebd62fbc..f432278173cd 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -21,6 +21,8 @@
#include "vc4_drv.h"
#include "uapi/drm/vc4_drm.h"
+static vm_fault_t vc4_fault(struct vm_fault *vmf);
+
static const char * const bo_type_names[] = {
"kernel",
"V3D",
@@ -374,6 +376,21 @@ static struct vc4_bo *vc4_bo_get_from_cache(struct
drm_device *dev,
return bo;
}
+static const struct vm_operations_struct vc4_vm_ops = {
+ .fault = vc4_fault,
+ .open = drm_gem_vm_open,
+ .close = drm_gem_vm_close,
+};
+
+static const struct drm_gem_object_funcs vc4_gem_object_funcs = {
+ .free = vc4_free_object,
+ .export = vc4_prime_export,
+ .get_sg_table = drm_gem_cma_prime_get_sg_table,
+ .vmap = vc4_prime_vmap,
+ .vunmap = drm_gem_cma_prime_vunmap,
+ .vm_ops = &vc4_vm_ops,
+};
+
/**
* vc4_gem_create_object - Implementation of driver->gem_create_object.
* @dev: DRM device
@@ -400,6 +417,8 @@ struct drm_gem_object *vc4_create_object(struct drm_device
*dev, size_t size)
vc4->bo_labels[VC4_BO_TYPE_KERNEL].size_allocated += size;
mutex_unlock(&vc4->bo_lock);
+ bo->base.base.funcs = &vc4_gem_object_funcs;
+
return &bo->base.base;
}
@@ -684,7 +703,7 @@ struct dma_buf * vc4_prime_export(struct drm_gem_object
*obj, int flags)
return dmabuf;
}
-vm_fault_t vc4_fault(struct vm_fault *vmf)
+static vm_fault_t vc4_fault(struct vm_fault *vmf)
{
struct vm_area_struct *vma = vmf->vma;
struct drm_gem_object *obj = vma->vm_private_data;
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index f1a5fd5dab6f..d27eaa2d0cfe 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -140,12 +140,6 @@ static void vc4_close(struct drm_device *dev, struct
drm_file *file)
kfree(vc4file);
}
-static const struct vm_operations_struct vc4_vm_ops = {
- .fault = vc4_fault,
- .open = drm_gem_vm_open,
- .close = drm_gem_vm_close,
-};
-
static const struct file_operations vc4_drm_fops = {
.owner = THIS_MODULE,
.open = drm_open,
@@ -195,16 +189,10 @@ static struct drm_driver vc4_drm_driver = {
#endif
.gem_create_object = vc4_create_object,
- .gem_free_object_unlocked = vc4_free_object,
- .gem_vm_ops = &vc4_vm_ops,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_export = vc4_prime_export,
- .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = vc4_prime_import_sg_table,
- .gem_prime_vmap = vc4_prime_vmap,
- .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
.gem_prime_mmap = vc4_prime_mmap,
.dumb_create = vc4_dumb_create,
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 8c8d96b6289f..a22478a35199 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -799,7 +799,6 @@ int vc4_get_hang_state_ioctl(struct drm_device *dev, void
*data,
struct drm_file *file_priv);
int vc4_label_bo_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
-vm_fault_t vc4_fault(struct vm_fault *vmf);
int vc4_mmap(struct file *filp, struct vm_area_struct *vma);
int vc4_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma);
struct drm_gem_object *vc4_prime_import_sg_table(struct drm_device *dev,
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 19/22] drm/vkms: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in vkms.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Melissa Wen
---
drivers/gpu/drm/vkms/vkms_drv.c | 8
drivers/gpu/drm/vkms/vkms_gem.c | 13 +
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index cb0b6230c22c..726801ab44d4 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -51,12 +51,6 @@ static const struct file_operations vkms_driver_fops = {
.release= drm_release,
};
-static const struct vm_operations_struct vkms_gem_vm_ops = {
- .fault = vkms_gem_fault,
- .open = drm_gem_vm_open,
- .close = drm_gem_vm_close,
-};
-
static void vkms_release(struct drm_device *dev)
{
struct vkms_device *vkms = container_of(dev, struct vkms_device, drm);
@@ -98,8 +92,6 @@ static struct drm_driver vkms_driver = {
.release= vkms_release,
.fops = &vkms_driver_fops,
.dumb_create= vkms_dumb_create,
- .gem_vm_ops = &vkms_gem_vm_ops,
- .gem_free_object_unlocked = vkms_gem_free_object,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import_sg_table = vkms_prime_import_sg_table,
diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
index a017fc59905e..19a0e260a4df 100644
--- a/drivers/gpu/drm/vkms/vkms_gem.c
+++ b/drivers/gpu/drm/vkms/vkms_gem.c
@@ -7,6 +7,17 @@
#include "vkms_drv.h"
+static const struct vm_operations_struct vkms_gem_vm_ops = {
+ .fault = vkms_gem_fault,
+ .open = drm_gem_vm_open,
+ .close = drm_gem_vm_close,
+};
+
+static const struct drm_gem_object_funcs vkms_gem_object_funcs = {
+ .free = vkms_gem_free_object,
+ .vm_ops = &vkms_gem_vm_ops,
+};
+
static struct vkms_gem_object *__vkms_gem_create(struct drm_device *dev,
u64 size)
{
@@ -17,6 +28,8 @@ static struct vkms_gem_object *__vkms_gem_create(struct
drm_device *dev,
if (!obj)
return ERR_PTR(-ENOMEM);
+ obj->gem.funcs = &vkms_gem_object_funcs;
+
size = roundup(size, PAGE_SIZE);
ret = drm_gem_object_init(dev, &obj->gem, size);
if (ret) {
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 15/22] drm/tegra: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in tegra.
Signed-off-by: Thomas Zimmermann
Acked-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 4
drivers/gpu/drm/tegra/gem.c | 8
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index ba9d1c3e7cac..f0f581cd345e 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -858,12 +858,8 @@ static struct drm_driver tegra_drm_driver = {
.debugfs_init = tegra_debugfs_init,
#endif
- .gem_free_object_unlocked = tegra_bo_free_object,
- .gem_vm_ops = &tegra_bo_vm_ops,
-
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_export = tegra_gem_prime_export,
.gem_prime_import = tegra_gem_prime_import,
.dumb_create = tegra_bo_dumb_create,
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index a2bac20ff19d..794ec2456934 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -230,6 +230,12 @@ static int tegra_bo_iommu_unmap(struct tegra_drm *tegra,
struct tegra_bo *bo)
return 0;
}
+static const struct drm_gem_object_funcs tegra_gem_object_funcs = {
+ .free = tegra_bo_free_object,
+ .export = tegra_gem_prime_export,
+ .vm_ops = &tegra_bo_vm_ops,
+};
+
static struct tegra_bo *tegra_bo_alloc_object(struct drm_device *drm,
size_t size)
{
@@ -240,6 +246,8 @@ static struct tegra_bo *tegra_bo_alloc_object(struct
drm_device *drm,
if (!bo)
return ERR_PTR(-ENOMEM);
+ bo->gem.funcs = &tegra_gem_object_funcs;
+
host1x_bo_init(&bo->base, &tegra_bo_ops);
size = round_up(size, PAGE_SIZE);
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 09/22] drm/msm: Introduce GEM object funcs
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in msm. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/msm/msm_drv.c | 13 -
drivers/gpu/drm/msm/msm_drv.h | 1 -
drivers/gpu/drm/msm/msm_gem.c | 19 ++-
3 files changed, 18 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 79333842f70a..5952767ea478 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -978,12 +978,6 @@ static const struct drm_ioctl_desc msm_ioctls[] = {
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_QUERY, msm_ioctl_submitqueue_query,
DRM_RENDER_ALLOW),
};
-static const struct vm_operations_struct vm_ops = {
- .fault = msm_gem_fault,
- .open = drm_gem_vm_open,
- .close = drm_gem_vm_close,
-};
-
static const struct file_operations fops = {
.owner = THIS_MODULE,
.open = drm_open,
@@ -1009,18 +1003,11 @@ static struct drm_driver msm_driver = {
.irq_preinstall = msm_irq_preinstall,
.irq_postinstall= msm_irq_postinstall,
.irq_uninstall = msm_irq_uninstall,
- .gem_free_object_unlocked = msm_gem_free_object,
- .gem_vm_ops = &vm_ops,
.dumb_create= msm_gem_dumb_create,
.dumb_map_offset= msm_gem_dumb_map_offset,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_pin = msm_gem_prime_pin,
- .gem_prime_unpin= msm_gem_prime_unpin,
- .gem_prime_get_sg_table = msm_gem_prime_get_sg_table,
.gem_prime_import_sg_table = msm_gem_prime_import_sg_table,
- .gem_prime_vmap = msm_gem_prime_vmap,
- .gem_prime_vunmap = msm_gem_prime_vunmap,
.gem_prime_mmap = msm_gem_prime_mmap,
#ifdef CONFIG_DEBUG_FS
.debugfs_init = msm_debugfs_init,
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index af259b0573ea..7bcea10be81f 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -269,7 +269,6 @@ void msm_gem_shrinker_cleanup(struct drm_device *dev);
int msm_gem_mmap_obj(struct drm_gem_object *obj,
struct vm_area_struct *vma);
int msm_gem_mmap(struct file *filp, struct vm_area_struct *vma);
-vm_fault_t msm_gem_fault(struct vm_fault *vmf);
uint64_t msm_gem_mmap_offset(struct drm_gem_object *obj);
int msm_gem_get_iova(struct drm_gem_object *obj,
struct msm_gem_address_space *aspace, uint64_t *iova);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index e47958c3704a..3f4a3be53de6 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -244,7 +244,7 @@ int msm_gem_mmap(struct file *filp, struct vm_area_struct
*vma)
return msm_gem_mmap_obj(vma->vm_private_data, vma);
}
-vm_fault_t msm_gem_fault(struct vm_fault *vmf)
+static vm_fault_t msm_gem_fault(struct vm_fault *vmf)
{
struct vm_area_struct *vma = vmf->vma;
struct drm_gem_object *obj = vma->vm_private_data;
@@ -991,6 +991,22 @@ int msm_gem_new_handle(struct drm_device *dev, struct
drm_file *file,
return ret;
}
+static const struct vm_operations_struct vm_ops = {
+ .fault = msm_gem_fault,
+ .open = drm_gem_vm_open,
+ .close = drm_gem_vm_close,
+};
+
+static const struct drm_gem_object_funcs msm_gem_object_funcs = {
+ .free = msm_gem_free_object,
+ .pin = msm_gem_prime_pin,
+ .unpin = msm_gem_prime_unpin,
+ .get_sg_table = msm_gem_prime_get_sg_table,
+ .vmap = msm_gem_prime_vmap,
+ .vunmap = msm_gem_prime_vunmap,
+ .vm_ops = &vm_ops,
+};
+
static int msm_gem_new_impl(struct drm_device *dev,
uint32_t size, uint32_t flags,
struct drm_gem_object **obj)
@@ -1021,6 +1037,7 @@ static int msm_gem_new_impl(struct drm_device *dev,
INIT_LIST_HEAD(&msm_obj->vmas);
*obj = &msm_obj->base;
+ (*obj)->funcs = &msm_gem_object_funcs;
return 0;
}
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
