Re: [Intel-gfx] [PATCH v6 04/11] drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.
On Thu, Sep 17, 2020 at 03:20:46PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 15, 2020 at 04:03:45PM -0700, Navare, Manasi wrote:
> > On Mon, Sep 14, 2020 at 10:47:56PM +0300, Ville Syrjälä wrote:
> > > On Mon, Sep 14, 2020 at 12:38:57PM -0700, Navare, Manasi wrote:
> > > > On Mon, Sep 14, 2020 at 10:17:57PM +0300, Ville Syrjälä wrote:
> > > > > On Mon, Sep 14, 2020 at 12:00:33PM -0700, Navare, Manasi wrote:
> > > > > > On Mon, Sep 07, 2020 at 02:20:56PM +0300, Ville Syrjälä wrote:
> > > > > > > On Wed, Jul 15, 2020 at 03:42:15PM -0700, Manasi Navare wrote:
> > > > > > > > From: Maarten Lankhorst
> > > > > > > >
> > > > > > > > Small changes to intel_dp_mode_valid(), allow listing modes that
> > > > > > > > can only be supported in the bigjoiner configuration, which is
> > > > > > > > not supported yet.
> > > > > > > >
> > > > > > > > eDP does not support bigjoiner, so do not expose bigjoiner only
> > > > > > > > modes on the eDP port.
> > > > > > > >
> > > > > > > > v5:
> > > > > > > > * Increase max plane width to support 8K with bigjoiner
> > > > > > > > (Maarten)
> > > > > > > > v4:
> > > > > > > > * Rebase (Manasi)
> > > > > > > >
> > > > > > > > Changes since v1:
> > > > > > > > - Disallow bigjoiner on eDP.
> > > > > > > > Changes since v2:
> > > > > > > > - Rename intel_dp_downstream_max_dotclock to
> > > > > > > > intel_dp_max_dotclock,
> > > > > > > > and split off the downstream and source checking to its own
> > > > > > > > function.
> > > > > > > > (Ville)
> > > > > > > > v3:
> > > > > > > > * Rebase (Manasi)
> > > > > > > >
> > > > > > > > Signed-off-by: Manasi Navare
> > > > > > > > Signed-off-by: Maarten Lankhorst
> > > > > > > >
> > > > > > > > ---
> > > > > > > > drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> > > > > > > > drivers/gpu/drm/i915/display/intel_dp.c | 119
> > > > > > > > ++-
> > > > > > > > 2 files changed, 91 insertions(+), 30 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > > > index 78cbfefbfa62..3ecb642805a6 100644
> > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > > > @@ -17400,7 +17400,7 @@ intel_mode_valid_max_plane_size(struct
> > > > > > > > drm_i915_private *dev_priv,
> > > > > > > > * too big for that.
> > > > > > > > */
> > > > > > > > if (INTEL_GEN(dev_priv) >= 11) {
> > > > > > > > - plane_width_max = 5120;
> > > > > > > > + plane_width_max = 7680;
> > > > > > >
> > > > > > > This looks misplaced. Planes do no know whether bigjoiner can be
> > > > > > > used or
> > > > > > > not. They should not care in fact. The caller should have that
> > > > > > > knowledge
> > > > > > > and can deal with it properly.
> > > > > >
> > > > > > Hmm, so the caller of intel_mode_valid_max_plane_size() should
> > > > > > check on the bigjoiner
> > > > > > flag and perhaps if bigjoiner is true then increase the
> > > > > > plane_width_max to 7680?
> > > > > >
> > > > > > Am still not sure where this should happen? We need to have the
> > > > > > plane max width to be 7680
> > > > > > before we prune the 8K mode in intel_mode_valid
> > > > > >
> > > > > > Where should this be added according to you?
> > > > >
> > > > > Hmm. I guess we do need to put it into this function given the way
> > > > > this
> > > > > is structured. However we still can't assume bigjoiner can be used
> > > > > since
> > > > > it can't be used on DDI A on icl. So we should probably just pass in a
> > > > > bool here to indicate whether bigjoiner can be used or not.
> > > > >
> > > >
> > > > So in intel_dp_mode_valid() we set bigjoiner = true if not edp and
> > > > higher clock.
> > > > I think here we need to do the platform check also, 1. because now we
> > > > are enabling this for TGL+
> > > > where big joiner on all pipes. But we should still I think add GEN >=12
> > > > check before setting bigjoiner
> > > > to true in intel_dp_mode_valid() and then pass that to
> > > > intel_mode_valid_max_plane_size(..., book bigjoiner)
> > >
> > > can_bigjoiner() {
> > > return gen >= 12 || (gen==11 && port!=A);
On Gen 11, Port A is eDP or MIPI DSI so I could check:
can_bigjoiner()
{
return gen >=12 || (gen == 11 && !intel_dp_is_edp())
}
The above should be okay right?
Manasi
> > > }
> >
> > Hmm, gen check can be done but can the port check be done in
> > intel_dp_mode_valid() since we dont have
> > an encoder yet?
>
> The encoder is there already.
>
> > Else we set the bigjoiner to true here based on gen check but add the port
> > check later in compute_config at
> > what point if not supported then encoder config will fail.
> >
> > or can this be sufficient check:
> >
> > can_bigjoiner() {
> > return gen >= 12 || (gen == 11 && !intel_dp_is_edp())
> >
Re: [Intel-gfx] [PATCH v3 0/6] Convert the intel iommu driver to the dma-iommu api
On 9/22/20 7:05 PM, Robin Murphy 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. AFAICS this certainly might be related to this series - iommu-dma will Oh! I looked at the wrong function. prepare_domain_attach_device() prints a similar message which made me believe that it was not caused by the this patches series. constrain IOVA allocation based on the domain geometry that the driver reports, which in this case is set only once when first allocating the domain. Thus it looks like both the dmar_domain->gaw adjustment in prepare_domain_attach_device() and the domain_use_first_level() business in intel_alloc_iova() effectively get lost in this conversion, since the domain geometry never gets updated to reflect those additional constraints. Sounds reasonable. I will look into the code and work out a fix. > Robin. Best regards, baolu ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH rdma-next v3 1/2] lib/scatterlist: Add support in dynamic allocation of SG table from pages
On Tue, Sep 22, 2020 at 11:39:57AM +0300, Leon Romanovsky wrote: > E.g. with the Infiniband driver that allocates a single page for hold > the > pages. For 1TB memory registration, the temporary buffer would consume > only > 4KB, instead of 2GB. Formatting looks little weird here. Otherwise looks good: Reviewed-by: Christoph Hellwig ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Fix NULL pointer found by static analysis
== Series Details ==
Series: Fix NULL pointer found by static analysis
URL : https://patchwork.freedesktop.org/series/81999/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9039 -> Patchwork_18551
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18551/index.html
Known issues
Here are the changes found in Patchwork_18551 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_busy@basic@flip:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) +1 similar
issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9039/fi-tgl-y/igt@kms_busy@ba...@flip.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18551/fi-tgl-y/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9039/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18551/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@vgem_basic@setversion:
- 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_9039/fi-tgl-y/igt@vgem_ba...@setversion.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18551/fi-tgl-y/igt@vgem_ba...@setversion.html
Possible fixes
* igt@gem_flink_basic@basic:
- fi-tgl-y: [DMESG-WARN][7] ([i915#402]) -> [PASS][8] +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9039/fi-tgl-y/igt@gem_flink_ba...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18551/fi-tgl-y/igt@gem_flink_ba...@basic.html
* igt@i915_module_load@reload:
- {fi-tgl-dsi}: [DMESG-WARN][9] ([i915#1982] / [k.org#205379]) ->
[PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9039/fi-tgl-dsi/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18551/fi-tgl-dsi/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@coherency:
- fi-gdg-551: [DMESG-FAIL][11] ([i915#1748]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9039/fi-gdg-551/igt@i915_selftest@l...@coherency.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18551/fi-gdg-551/igt@i915_selftest@l...@coherency.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- fi-icl-u2: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9039/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18551/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.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_9039/fi-skl-guc/igt@vgem_ba...@unload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18551/fi-skl-guc/igt@vgem_ba...@unload.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#1982] / [i915#62] / [i915#92]
/ [i915#95]) -> [DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9039/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18551/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@gem_exec_suspend@basic-s3:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][20] ([i915#1982] / [i915#62] / [i915#92])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9039/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18551/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
- fi-tgl-y: [DMESG-WARN][21] ([i915#2411] / [i915#402]) ->
[DMESG-WARN][22] ([i915#2411])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9039/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18551/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][23] ([i915#62] / [i915#95]) ->
[DMESG-FAIL][24] ([i915#62])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9039/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18551/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][25] ([i915#62] / [i915#92]) ->
[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] ✗ Fi.CI.IGT: failure for drm: document and enforce rules around "spurious" EBUSY from atomic_commit
== Series Details == Series: drm: document and enforce rules around "spurious" EBUSY from atomic_commit URL : https://patchwork.freedesktop.org/series/81988/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9036_full -> Patchwork_18550_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18550_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18550_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_18550_full: ### IGT changes ### Possible regressions * igt@perf_pmu@busy-accuracy-98@rcs0: - shard-kbl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9036/shard-kbl6/igt@perf_pmu@busy-accuracy...@rcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18550/shard-kbl6/igt@perf_pmu@busy-accuracy...@rcs0.html Known issues Here are the changes found in Patchwork_18550_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_workarounds@reset-fd: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#1635] / [i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9036/shard-apl6/igt@gem_workarou...@reset-fd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18550/shard-apl1/igt@gem_workarou...@reset-fd.html * igt@i915_pm_rpm@system-suspend-modeset: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([i915#151]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9036/shard-skl3/igt@i915_pm_...@system-suspend-modeset.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18550/shard-skl6/igt@i915_pm_...@system-suspend-modeset.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - shard-skl: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +4 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9036/shard-skl8/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18550/shard-skl1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_flip@flip-vs-suspend@b-vga1: - shard-snb: [PASS][9] -> [INCOMPLETE][10] ([i915#82]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9036/shard-snb2/igt@kms_flip@flip-vs-susp...@b-vga1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18550/shard-snb1/igt@kms_flip@flip-vs-susp...@b-vga1.html * igt@kms_flip@flip-vs-suspend@c-dp1: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +5 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9036/shard-kbl7/igt@kms_flip@flip-vs-susp...@c-dp1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18550/shard-kbl4/igt@kms_flip@flip-vs-susp...@c-dp1.html * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9036/shard-kbl6/igt@kms_frontbuffer_track...@fbc-rgb565-draw-pwrite.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18550/shard-kbl6/igt@kms_frontbuffer_track...@fbc-rgb565-draw-pwrite.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-fullscreen: - shard-tglb: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9036/shard-tglb1/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-fullscreen.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18550/shard-tglb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-fullscreen.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([i915#648]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9036/shard-skl7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18550/shard-skl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145] / [i915#265]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9036/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18550/shard-skl2/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][21] -> [DMESG-FAIL][22] ([fdo#108145] /
Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.
Hi! Since I got dropped from the thread, many responses inline
On Tue, 2020-09-22 at 12:58 -0700, Puthikorn Voravootivat wrote:
> +Lyude
> I notice that Lyude email was somehow dropped from the thread.
> Lyude was the person who submitted the patch for Thinkpad and should
> know the OUI of the panel.
no need - currently because of some confusion that got caused by the Intel HDR
backlight interface being the only backlight interface that works properly on
a lot of panels (many panels will advertise both interfaces, but might only
work with the Intel one), we actually rely on a small allowlist of "approved"
panels for enabling DPCD backlight control.
…however, many of these panels are annoying and don't actually provide a
reliable enough OUID to use for quirk detection, which is why we had to add
EDID quirk detection as a temporary workaround for this. The current list of
panels lives in drm_dp_helper.c:
/*
* Some devices have unreliable OUIDs where they don't set the device ID
* correctly, and as a result we need to use the EDID for finding additional
* DP quirks in such cases.
*/
static const struct edid_quirk edid_quirk_list[] = {
/* Optional 4K AMOLED panel in the ThinkPad X1 Extreme 2nd Generation
* only supports DPCD backlight controls
*/
{ MFG(0x4c, 0x83), PROD_ID(0x41, 0x41),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
/*
* Some Dell CML 2020 systems have panels support both AUX and PWM
* backlight control, and some only support AUX backlight control. All
* said panels start up in AUX mode by default, and we don't have any
* support for disabling HDR mode on these panels which would be
* required to switch to PWM backlight control mode (plus, I'm not
* even sure we want PWM backlight controls over DPCD backlight
* controls anyway...). Until we have a better way of detecting these,
* force DPCD backlight mode on all of them.
*/
{ MFG(0x06, 0xaf), PROD_ID(0x9b, 0x32),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
{ MFG(0x06, 0xaf), PROD_ID(0xeb, 0x41),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
{ MFG(0x4d, 0x10), PROD_ID(0xc7, 0x14),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
{ MFG(0x4d, 0x10), PROD_ID(0xe6, 0x14),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
{ MFG(0x4c, 0x83), PROD_ID(0x47, 0x41),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
};
Also note that I think just about every panel on that list supports the Intel
HDR backlight interface, so it's -possible- that the VESA interface could be
broken on these panels. But, that would be a lot of different panels from
different vendors to all be broken in the same way.
>
> On Tue, Sep 22, 2020 at 11:47 AM Kevin Chowski wrote:
> > Alrighty, I'll take everyone else's silence as tacit approval of
> > Ville's opinions. (I didn't receive any email bounces this time, so I
> > think my issue was transient.) I will start on inverting the quirk and
> > making the most-significant-alignment matter for these registers by
> > default.
> >
> > Who can help me gather a list of OUIs that we need to add to the
> > quirk? I can follow up with Puthikorn about the relevant Chromebooks,
> > but I don't know what other types of laptops are using this driver.
> >
> > Thanks for your time,
> > Kevin Chowski
> >
> >
> > On Fri, Sep 18, 2020 at 12:16 PM Puthikorn Voravootivat
> > wrote:
> > > I'll defer to Ville & Lyude.
> > >
> > > I dug up more on the bug report and found that both Thinkpad and
> > > Galaxy Chromebook use the same Samsung OLED.
> > > So my 2 vs 1 argument is actually not valid.
> > >
> > > On Fri, Sep 18, 2020 at 10:59 AM Kevin Chowski
> > > wrote:
> > > > Apologies once again, some of my emails were bouncing for some
> > > > addresses yesterday. Hopefully it was a temporary condition; I'll
> > > > continue trying to dig into it on my end if it happens again for this
> > > > email.
> > > >
> > > > Since there's evidence that some models want lsb and some (well, at
> > > > least one) want msb, my understanding is that we'll need a quirk one
> > > > way or the other (please correct if I'm mistaken). I unfortunately
> > > > don't have the ability to test anything other than the Pixelbook, so
> > > > if we decide the msb is the "right" way, then I will have to rely on
> > > > others to test (and find the OUI of) other models which require lsb.
> > > >
> > > > I am happy to make any changes requested, but I do not at all have
> > > > enough background here to make the decision on whether the msb
> > > > functionality deserves the quirk or if the lsb one does. How can I
> > > > help you all come to an agreement here?
> > > >
> > > > * It seems like Ville feels strongly about the msb being the correct
> > > > interpretation of the spec.
> > > > * It's unclear to me on which side of the fence Lyude falls, I
> > > > couldn't pick up a strong opinion in her clarifying question.
> > > > * Puthikorn seems to be on
Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.
+Lyude I notice that Lyude email was somehow dropped from the thread. Lyude was the person who submitted the patch for Thinkpad and should know the OUI of the panel. On Tue, Sep 22, 2020 at 11:47 AM Kevin Chowski wrote: > > Alrighty, I'll take everyone else's silence as tacit approval of > Ville's opinions. (I didn't receive any email bounces this time, so I > think my issue was transient.) I will start on inverting the quirk and > making the most-significant-alignment matter for these registers by > default. > > Who can help me gather a list of OUIs that we need to add to the > quirk? I can follow up with Puthikorn about the relevant Chromebooks, > but I don't know what other types of laptops are using this driver. > > Thanks for your time, > Kevin Chowski > > > On Fri, Sep 18, 2020 at 12:16 PM Puthikorn Voravootivat > wrote: > > > > I'll defer to Ville & Lyude. > > > > I dug up more on the bug report and found that both Thinkpad and > > Galaxy Chromebook use the same Samsung OLED. > > So my 2 vs 1 argument is actually not valid. > > > > On Fri, Sep 18, 2020 at 10:59 AM Kevin Chowski wrote: > > > > > > Apologies once again, some of my emails were bouncing for some > > > addresses yesterday. Hopefully it was a temporary condition; I'll > > > continue trying to dig into it on my end if it happens again for this > > > email. > > > > > > Since there's evidence that some models want lsb and some (well, at > > > least one) want msb, my understanding is that we'll need a quirk one > > > way or the other (please correct if I'm mistaken). I unfortunately > > > don't have the ability to test anything other than the Pixelbook, so > > > if we decide the msb is the "right" way, then I will have to rely on > > > others to test (and find the OUI of) other models which require lsb. > > > > > > I am happy to make any changes requested, but I do not at all have > > > enough background here to make the decision on whether the msb > > > functionality deserves the quirk or if the lsb one does. How can I > > > help you all come to an agreement here? > > > > > > * It seems like Ville feels strongly about the msb being the correct > > > interpretation of the spec. > > > * It's unclear to me on which side of the fence Lyude falls, I > > > couldn't pick up a strong opinion in her clarifying question. > > > * Puthikorn seems to be on the side of lsb being correct, but maybe > > > was swayed by Ville's argument. > > > > > > If no one feels that Ville's argument is not strong in some way, and > > > we go with that, I will get to work on the requested changes. I am > > > concerned, though, about changing the default functionality without > > > testing it widely to find the set of laptops which require the lsb > > > quirk. I'd appreciate any advice people might have about making this > > > change safely. > > > > > > Thank you for your time, > > > Kevin > > > > > > On Thu, Sep 17, 2020 at 2:11 PM Ville Syrjälä > > > wrote: > > > > > > > > On Thu, Sep 17, 2020 at 09:25:35PM +0300, Ville Syrjälä wrote: > > > > > On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat > > > > > wrote: > > > > > > The Lyude fde7266fb2f6 change is actually based on Chromium change > > > > > > (https://crrev.com/c/1650325) that fixes the brightness for Samsung > > > > > > Galaxy Chromebook. So currently we have 2 examples that use LSB > > > > > > interpretation and 1 that use MSB. > > > > > > > > > > "If field 4:0 of the EDP_PWMGEN_BIT_COUNT register represents a value > > > > > of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT bit > > > > > is cleared to 0, only the 8 MSB of the brightness control value can be > > > > > controlled. > > > > > (See Note below.) > > > > > Assigned bits are allocated to the MSB of the enabled register > > > > > combination." > > > > > > > > > > I think that's pretty clear the assigned bits are supposed to be > > > > > msb aligned. > > > > > > > > I guess there's some email issues happening, but just to clarify: > > > > > > > > When the spec says MSB in caps here it clearly means > > > > "most significant-bit(s)" since otherwise "8 MSB" would not make > > > > any sense in the context of a 2 byte value. > > > > > > > > Granted the spec is crap here since "Table 1-1: Acronyms and > > > > Initialism" does claim "MSB" should be byte(s) and "msb" bit(s). > > > > > > > > Also I can't imagine anyone would allocate the bits starting > > > > from the lsb when the whole thing is clearly supposed to be a > > > > 16bit big endian integer. So with >8 assigned bits you'd end > > > > up with crazy stuff like this: > > > > > > > > [ 7 ... 0 ][7 ... 0] > > > > [ 8 MSB ][][N LSB] > > > > > > > > so you couldn't even treat the value as a regular big endian > > > > thing. Instead, if you squint a bit, it now looks like a funky > > > > little endian value. So we're deep into some mixed endian land > > > > where nothing makes sense anymore. > > > > > > > > Anyways I think the code should simply do this to match the
[Intel-gfx] ✓ Fi.CI.BAT: success for drm: document and enforce rules around "spurious" EBUSY from atomic_commit
== Series Details ==
Series: drm: document and enforce rules around "spurious" EBUSY from
atomic_commit
URL : https://patchwork.freedesktop.org/series/81988/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9036 -> Patchwork_18550
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18550/index.html
Known issues
Here are the changes found in Patchwork_18550 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_9036/fi-tgl-y/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18550/fi-tgl-y/igt@i915_module_l...@reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9036/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18550/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9036/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_18550/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@vgem_basic@setversion:
- 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_9036/fi-tgl-y/igt@vgem_ba...@setversion.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18550/fi-tgl-y/igt@vgem_ba...@setversion.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_9036/fi-kbl-x1275/igt@vgem_ba...@unload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18550/fi-kbl-x1275/igt@vgem_ba...@unload.html
Possible fixes
* {igt@core_hotunplug@unbind-rebind}:
- {fi-tgl-dsi}: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9036/fi-tgl-dsi/igt@core_hotunp...@unbind-rebind.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18550/fi-tgl-dsi/igt@core_hotunp...@unbind-rebind.html
- fi-tgl-y: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9036/fi-tgl-y/igt@core_hotunp...@unbind-rebind.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18550/fi-tgl-y/igt@core_hotunp...@unbind-rebind.html
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9036/fi-kbl-x1275/igt@core_hotunp...@unbind-rebind.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18550/fi-kbl-x1275/igt@core_hotunp...@unbind-rebind.html
* igt@gem_flink_basic@flink-lifetime:
- 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_9036/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18550/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9036/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18550/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22] +2
similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9036/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18550/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
Warnings
* igt@gem_exec_suspend@basic-s3:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#1982] / [i915#62] /
[i915#92]) -> [DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9036/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
[24]:
Re: [Intel-gfx] [PATCH] drm: document and enforce rules around "spurious" EBUSY from atomic_commit
Hi,
On Tue, 22 Sep 2020 at 19:18, Daniel Vetter wrote:
> + 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
> +* 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);
> + }
> +
Can we please add a DRM_DEBUG() here, regardless of the WARN_ON(), to
let people know what's happening?
With that, R-b me.
Cheers,
Daniel
___
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
Hi, On Tue, 22 Sep 2020 at 17:02, Daniel Vetter wrote: > On Tue, Sep 22, 2020 at 4:14 PM Daniel Stone wrote: > > I think we need a guarantee that this never happens if ALLOW_MODESET > > is always used in blocking mode, plus in future a cap we can use to > > detect that we won't be getting spurious EBUSY events. > > > > I really don't want to ever paper over this, because it's one of the > > clearest indications that userspace has its timing/signalling wrong. > > Ok so the hang-up last time around iirc was that I broke igt by making > a few things more synchronous. Let's hope I'm not also breaking stuff > with the WARN_ON ... > > New plan: > - make this patch here only document existing behaviour and enforce it > with the WARN_ON > - new uapi would be behind a flag or something, with userspace and > everything hanging off it. > > Thoughts? What do you mean by 'new uapi'? The proposal that the kernel communicates back which object IDs have been added to the state behind your back? That it's been made automatically blocking? Something else? Cheers, Daniel (the other one) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: document and enforce rules around "spurious" EBUSY from atomic_commit
== Series Details == Series: drm: document and enforce rules around "spurious" EBUSY from atomic_commit URL : https://patchwork.freedesktop.org/series/81988/ State : warning == Summary == $ dim checkpatch origin/drm-tip a5bc5130e920 drm: document and enforce rules around "spurious" EBUSY from atomic_commit -:42: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #42: References: https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html -:70: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' #70: FILE: drivers/gpu/drm/drm_atomic.c:1269: + unsigned requested_crtc = 0; -:71: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' #71: FILE: drivers/gpu/drm/drm_atomic.c:1270: + unsigned affected_crtc = 0; -:106: 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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 10/11] drm/i915: Add intel_update_bigjoiner handling.
On Tue, Sep 22, 2020 at 01:27:35PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 21, 2020 at 02:18:33PM -0700, Navare, Manasi wrote:
> > On Mon, Sep 14, 2020 at 12:21:26PM -0700, Navare, Manasi wrote:
> > > On Thu, Sep 03, 2020 at 10:23:35PM +0300, Ville Syrjälä wrote:
> > > > On Wed, Jul 15, 2020 at 03:42:21PM -0700, Manasi Navare wrote:
> > > > > From: Maarten Lankhorst
> > > > >
> > > > > Enabling is done in a special sequence and so should plane updates
> > > > > be. Ideally the end user never notices the second pipe is used,
> > > > > so use the vblank evasion to cover both pipes.
> > > > >
> > > > > This way ideally everything will be tear free, and updates are
> > > > > really atomic as userspace expects it.
> > > > >
> > > > > This needs to be checked if it still works since lot of
> > > > > refactoring
> > > > > in skl_commit_modeset_enables
> > > > >
> > > > > v2:
> > > > > * Manual Rebase (Manasi)
> > > > > * Refactoring on intel_update_crtc and enable_crtc and removing
> > > > > special trans_port_sync_update (Manasi)
> > > > >
> > > > > Signed-off-by: Maarten Lankhorst
> > > > > Signed-off-by: Manasi Navare
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_display.c | 120
> > > > > +--
> > > > > drivers/gpu/drm/i915/display/intel_sprite.c | 25 +++-
> > > > > drivers/gpu/drm/i915/display/intel_sprite.h | 3 +-
> > > > > 3 files changed, 129 insertions(+), 19 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > index a1011414da6d..00b26863ffc6 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > @@ -15656,7 +15656,7 @@ static void intel_update_crtc(struct
> > > > > intel_atomic_state *state,
> > > > > else
> > > > > i9xx_update_planes_on_crtc(state, crtc);
> > > > >
> > > > > - intel_pipe_update_end(new_crtc_state);
> > > > > + intel_pipe_update_end(new_crtc_state, NULL);
> > > > >
> > > > > /*
> > > > >* We usually enable FIFO underrun interrupts as part of the
> > > > > @@ -15754,6 +15754,52 @@ static void
> > > > > intel_commit_modeset_disables(struct intel_atomic_state *state)
> > > > > }
> > > > > }
> > > > >
> > > > > +static void intel_update_bigjoiner(struct intel_crtc *crtc,
> > > > > +struct intel_atomic_state *state,
> > > > > +struct intel_crtc_state
> > > > > *old_crtc_state,
> > > > > +struct intel_crtc_state
> > > > > *new_crtc_state)
> > > > > +{
> > > > > + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > > > > + bool modeset = needs_modeset(new_crtc_state);
> > > > > + struct intel_crtc *slave =
> > > > > new_crtc_state->bigjoiner_linked_crtc;
> > > > > + struct intel_crtc_state *new_slave_crtc_state =
> > > > > + intel_atomic_get_new_crtc_state(state, slave);
> > > > > +
> > > > > + if (modeset) {
> > > > > + /* Enable slave first */
> > > > > + intel_crtc_update_active_timings(new_slave_crtc_state);
> > > > > + dev_priv->display.crtc_enable(state, slave);
> > > > > +
> > > > > + /* Then master */
> > > > > + intel_crtc_update_active_timings(new_crtc_state);
> > > > > + dev_priv->display.crtc_enable(state, crtc);
> > > > > +
> > > > > + /* vblanks work again, re-enable pipe CRC. */
> > > > > + intel_crtc_enable_pipe_crc(crtc);
> > > > > +
> > > > > + } else {
> > > > > + intel_pre_plane_update(state, crtc);
> > > > > + intel_pre_plane_update(state, slave);
> > > > > +
> > > > > + if (new_crtc_state->update_pipe)
> > > > > + intel_encoders_update_pipe(state, crtc);
> > > > > + }
> > > > > +
> > > > > + /*
> > > > > + * Perform vblank evasion around commit operation, and make
> > > > > sure to
> > > > > + * commit both planes simultaneously for best results.
> > > > > + */
> > > > > + intel_pipe_update_start(new_crtc_state);
> > > > > +
> > > > > + commit_pipe_config(state, crtc);
> > > > > + commit_pipe_config(state, slave);
> > > > > +
> > > > > + skl_update_planes_on_crtc(state, crtc);
> > > > > + skl_update_planes_on_crtc(state, slave);
> > > > > +
> > > > > + intel_pipe_update_end(new_crtc_state, new_slave_crtc_state);
> > > > > +}
> > > >
> > > > I think this should ideally all go away and just the normal logic
> > > > in commit_modeset_enables() should deal with it. Just like it does
> > > > for port sync/mst pipe dependencies.
> > > >
> > >
> > > Yes I think so too. Except for the intel_pipe_update_end where
> > > now we send the new_slave_crtc_state() so thats still something I need to
> > > figure
> > > how it will work in normal
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: kernel-doc fixes for new DP helpers
== Series Details == Series: drm/i915: kernel-doc fixes for new DP helpers URL : https://patchwork.freedesktop.org/series/81985/ State : failure == Summary == Applying: drm/dp: fix kernel-doc warnings at drm_dp_helper.c Using index info to reconstruct a base tree... M drivers/gpu/drm/drm_dp_helper.c Falling back to patching base and 3-way merge... No changes -- Patch already applied. Applying: drm/dp: fix a kernel-doc issue at drm_edid.c Using index info to reconstruct a base tree... M drivers/gpu/drm/drm_edid.c Falling back to patching base and 3-way merge... No changes -- Patch already applied. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 02/11] drm/i915: Remove hw.mode
On 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, ); 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
Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.
Alrighty, I'll take everyone else's silence as tacit approval of Ville's opinions. (I didn't receive any email bounces this time, so I think my issue was transient.) I will start on inverting the quirk and making the most-significant-alignment matter for these registers by default. Who can help me gather a list of OUIs that we need to add to the quirk? I can follow up with Puthikorn about the relevant Chromebooks, but I don't know what other types of laptops are using this driver. Thanks for your time, Kevin Chowski On Fri, Sep 18, 2020 at 12:16 PM Puthikorn Voravootivat wrote: > > I'll defer to Ville & Lyude. > > I dug up more on the bug report and found that both Thinkpad and > Galaxy Chromebook use the same Samsung OLED. > So my 2 vs 1 argument is actually not valid. > > On Fri, Sep 18, 2020 at 10:59 AM Kevin Chowski wrote: > > > > Apologies once again, some of my emails were bouncing for some > > addresses yesterday. Hopefully it was a temporary condition; I'll > > continue trying to dig into it on my end if it happens again for this > > email. > > > > Since there's evidence that some models want lsb and some (well, at > > least one) want msb, my understanding is that we'll need a quirk one > > way or the other (please correct if I'm mistaken). I unfortunately > > don't have the ability to test anything other than the Pixelbook, so > > if we decide the msb is the "right" way, then I will have to rely on > > others to test (and find the OUI of) other models which require lsb. > > > > I am happy to make any changes requested, but I do not at all have > > enough background here to make the decision on whether the msb > > functionality deserves the quirk or if the lsb one does. How can I > > help you all come to an agreement here? > > > > * It seems like Ville feels strongly about the msb being the correct > > interpretation of the spec. > > * It's unclear to me on which side of the fence Lyude falls, I > > couldn't pick up a strong opinion in her clarifying question. > > * Puthikorn seems to be on the side of lsb being correct, but maybe > > was swayed by Ville's argument. > > > > If no one feels that Ville's argument is not strong in some way, and > > we go with that, I will get to work on the requested changes. I am > > concerned, though, about changing the default functionality without > > testing it widely to find the set of laptops which require the lsb > > quirk. I'd appreciate any advice people might have about making this > > change safely. > > > > Thank you for your time, > > Kevin > > > > On Thu, Sep 17, 2020 at 2:11 PM Ville Syrjälä > > wrote: > > > > > > On Thu, Sep 17, 2020 at 09:25:35PM +0300, Ville Syrjälä wrote: > > > > On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote: > > > > > The Lyude fde7266fb2f6 change is actually based on Chromium change > > > > > (https://crrev.com/c/1650325) that fixes the brightness for Samsung > > > > > Galaxy Chromebook. So currently we have 2 examples that use LSB > > > > > interpretation and 1 that use MSB. > > > > > > > > "If field 4:0 of the EDP_PWMGEN_BIT_COUNT register represents a value > > > > of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT bit > > > > is cleared to 0, only the 8 MSB of the brightness control value can be > > > > controlled. > > > > (See Note below.) > > > > Assigned bits are allocated to the MSB of the enabled register > > > > combination." > > > > > > > > I think that's pretty clear the assigned bits are supposed to be > > > > msb aligned. > > > > > > I guess there's some email issues happening, but just to clarify: > > > > > > When the spec says MSB in caps here it clearly means > > > "most significant-bit(s)" since otherwise "8 MSB" would not make > > > any sense in the context of a 2 byte value. > > > > > > Granted the spec is crap here since "Table 1-1: Acronyms and > > > Initialism" does claim "MSB" should be byte(s) and "msb" bit(s). > > > > > > Also I can't imagine anyone would allocate the bits starting > > > from the lsb when the whole thing is clearly supposed to be a > > > 16bit big endian integer. So with >8 assigned bits you'd end > > > up with crazy stuff like this: > > > > > > [ 7 ... 0 ][7 ... 0] > > > [ 8 MSB ][][N LSB] > > > > > > so you couldn't even treat the value as a regular big endian > > > thing. Instead, if you squint a bit, it now looks like a funky > > > little endian value. So we're deep into some mixed endian land > > > where nothing makes sense anymore. > > > > > > Anyways I think the code should simply do this to match the spec: > > > u16 value = brightness << (16 - num_assigned_bits); > > > val[0] = value >> 8; > > > val[1] = value & 0xff; > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski > > > > > wrote: > > > > > > > > > > > > Apologies for being too vague. To be as precise I can be, here is > > > > > > the > > > > > > specific code delta I tested: https://crrev.com/c/2406616 . To > > > > > > answer >
Re: [Intel-gfx] [PATCH v3 0/6] Convert the intel iommu driver to the dma-iommu api
On 2020-09-22 3:51 a.m., Robin Murphy wrote:
> On 2020-09-18 21:47, Logan Gunthorpe wrote:
>> Hi Lu,
>>
>> On 2020-09-11 9:21 p.m., Lu Baolu wrote:
>>> Tom Murphy has almost done all the work. His latest patch series was
>>> posted here.
>>>
>>> https://lore.kernel.org/linux-iommu/20200903201839.7327-1-murph...@tcd.ie/
>>>
>>> Thanks a lot!
>>>
>>> This series is a follow-up with below changes:
>>>
>>> 1. Add a quirk for the i915 driver issue described in Tom's cover
>>> letter.
>>> 2. Fix several bugs in patch "iommu: Allow the dma-iommu api to use
>>> bounce buffers" to make the bounce buffer work for untrusted devices.
>>> 3. Several cleanups in iommu/vt-d driver after the conversion.
>>>
>>
>> I'm trying to test this on an old Sandy Bridge, but found that I get
>> spammed with warnings on boot. I've put a sample of a few of them below.
>> They all seem to be related to ioat.
>>
>> I had the same issue with Tom's v2 but never saw this on his v1.
>
> I think this might have more to do with ioat being totally broken -
> AFAICS it appears to allocate descriptors with a size of 2MB, but free
> them with a size of 512KB. Try throwing CONFIG_DMA_API_DEBUG at it to
> confirm.
Ah, yes, nice catch. Looks like it was broken recently by the following
commit, but nobody noticed and the dma-iommu patch set added a warning
which caught it.
a02254f8a676 ("dmaengine: ioat: Decreasing allocation chunk size 2M->512K")
Reverting that fixes the issue. I'll try to send patch or two for this.
Logan
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Switch to LTTPR non-transparent mode link training
On Tue, Sep 22, 2020 at 08:37:44PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 22, 2020 at 03:51:06PM +0300, Imre Deak wrote:
> > The DP Standard's recommendation is to use the LTTPR non-transparent
> > mode link training if LTTPRs are detected, so let's do this.
> >
> > Besides power-saving, the advantages of this are that the maximum number
> > of LTTPRs can only be used in non-transparent mode (the limit is 5-8 in
> > transparent mode), and it provides a way to narrow down the reason for a
> > link training failure to a given link segment. Non-transparent mode is
> > probably also the mode that was tested the most by the industry.
> >
> > The changes in this patchset:
> > - Pass the DP PHY that is currently link trained to all LT helpers, so
> > that these can access the correct LTTPR/DPRX DPCD registers.
> > - During LT take into account the LTTPR common lane rate/count and the
> > per LTTPR-PHY vswing/pre-emph limits.
> > - Switch to LTTPR non-transparent LT mode and train each link segment
> > according to the sequence in DP Standard v2.0 (complete CR/EQ for
> > each segment before continuing with the next segment).
> >
> > Signed-off-by: Imre Deak
> > ---
> > .../drm/i915/display/intel_display_types.h| 1 +
> > drivers/gpu/drm/i915/display/intel_dp.c | 14 +-
> > .../drm/i915/display/intel_dp_link_training.c | 374 +++---
> > .../drm/i915/display/intel_dp_link_training.h | 10 +-
> > 4 files changed, 327 insertions(+), 72 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index b04921eba73b..2fb4e9a6a316 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -1281,6 +1281,7 @@ struct intel_dp {
> > u8 edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE];
> > u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE];
> > u8 lttpr_common_caps[DP_LTTPR_COMMON_CAP_SIZE];
> > + u8 lttpr_phy_caps[DP_MAX_LTTPR_COUNT][DP_LTTPR_PHY_CAP_SIZE];
> > u8 fec_capable;
> > /* source rates */
> > int num_source_rates;
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index d88f327aa9ef..54ad31044eef 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -161,6 +161,7 @@ static void intel_dp_set_sink_rates(struct intel_dp
> > *intel_dp)
> > 162000, 27, 54, 81
> > };
> > int i, max_rate;
> > + int max_lttpr_rate;
> >
> > if (drm_dp_has_quirk(_dp->desc, 0,
> > DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS)) {
> > @@ -174,6 +175,9 @@ static void intel_dp_set_sink_rates(struct intel_dp
> > *intel_dp)
> > }
> >
> > max_rate =
> > drm_dp_bw_code_to_link_rate(intel_dp->dpcd[DP_MAX_LINK_RATE]);
> > + max_lttpr_rate =
> > drm_dp_lttpr_max_link_rate(intel_dp->lttpr_common_caps);
> > + if (max_lttpr_rate)
> > + max_rate = min(max_rate, max_lttpr_rate);
> >
> > for (i = 0; i < ARRAY_SIZE(dp_rates); i++) {
> > if (dp_rates[i] > max_rate)
> > @@ -219,6 +223,10 @@ static int intel_dp_max_common_lane_count(struct
> > intel_dp *intel_dp)
> > int source_max = dig_port->max_lanes;
> > int sink_max = drm_dp_max_lane_count(intel_dp->dpcd);
> > int fia_max = intel_tc_port_fia_max_lane_count(dig_port);
> > + int lttpr_max =
> > drm_dp_lttpr_max_lane_count(intel_dp->lttpr_common_caps);
> > +
> > + if (lttpr_max)
> > + sink_max = min(sink_max, lttpr_max);
> >
> > return min3(source_max, sink_max, fia_max);
> > }
> > @@ -5540,13 +5548,13 @@ void intel_dp_process_phy_request(struct intel_dp
> > *intel_dp)
> > _dp->compliance.test_data.phytest;
> > u8 link_status[DP_LINK_STATUS_SIZE];
> >
> > - if (!intel_dp_get_link_status(intel_dp, link_status)) {
> > + if (!intel_dp_get_link_status(intel_dp, DP_PHY_DPRX, link_status)) {
> > DRM_DEBUG_KMS("failed to get link status\n");
> > return;
> > }
> >
> > /* retrieve vswing & pre-emphasis setting */
> > - intel_dp_get_adjust_train(intel_dp, link_status);
> > + intel_dp_get_adjust_train(intel_dp, DP_PHY_DPRX, link_status);
> >
> > intel_dp_autotest_phy_ddi_disable(intel_dp);
> >
> > @@ -5701,7 +5709,7 @@ intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
> > if (intel_psr_enabled(intel_dp))
> > return false;
> >
> > - if (!intel_dp_get_link_status(intel_dp, link_status))
> > + if (!intel_dp_get_link_status(intel_dp, DP_PHY_DPRX, link_status))
>
> Should we check all repeaters here too perhaps?
> I guess that should be a followup if we need it.
Hm, yea, would be better even if only for debugging; otherwise DPRX should have
a bad link if an LTTPR does.
>
> > return false;
> >
> > /*
> > diff --git
[Intel-gfx] [PATCH] drm: document and enforce rules around "spurious" EBUSY from atomic_commit
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)
+ 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);
+ }
+
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 4/7] drm/i915: Factor out a helper to disable the DPCD training pattern
On Tue, Sep 22, 2020 at 08:47:56PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 22, 2020 at 08:41:28PM +0300, Imre Deak wrote:
> > On Tue, Sep 22, 2020 at 07:54:20PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 22, 2020 at 03:51:03PM +0300, Imre Deak wrote:
> > > > To prepare for a follow-up LTTPR change factor out a helper to disable
> > > > the training pattern in DPCD. We'll need to do this for each LTTPR
> > > > (without programming the port to output the idle pattern) when training
> > > > in LTTPR non-transparent mode.
> > > >
> > > > Signed-off-by: Imre Deak
> > > > ---
> > > > .../drm/i915/display/intel_dp_link_training.c | 28 +++
> > > > 1 file changed, 16 insertions(+), 12 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > > index 0c3809891bd2..6994a32244dc 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > > @@ -102,30 +102,34 @@ void intel_dp_get_adjust_train(struct intel_dp
> > > > *intel_dp,
> > > > intel_dp->train_set[lane] = v | p;
> > > > }
> > > >
> > > > +static bool intel_dp_disable_dpcd_training_pattern(struct intel_dp
> > > > *intel_dp)
> > > > +{
> > > > + u8 val = DP_TRAINING_PATTERN_DISABLE;
> > > > +
> > > > + return drm_dp_dpcd_write(_dp->aux,
> > > > DP_TRAINING_PATTERN_SET, , 1) == 1;
> > > > +}
> > >
> > >
> > > > +
> > > > static bool
> > > > intel_dp_set_link_train(struct intel_dp *intel_dp,
> > > > u8 dp_train_pat)
> > > > {
> > > > u8 buf[sizeof(intel_dp->train_set) + 1];
> > > > - int ret, len;
> > > > + int len;
> > > >
> > > > intel_dp_program_link_training_pattern(intel_dp, dp_train_pat);
> > > >
> > > > - buf[0] = dp_train_pat;
> > > > if ((dp_train_pat & ~DP_LINK_SCRAMBLING_DISABLE) ==
> > > > - DP_TRAINING_PATTERN_DISABLE) {
> > > > + DP_TRAINING_PATTERN_DISABLE)
> > > > /* don't write DP_TRAINING_LANEx_SET on disable */
> > >
> > > As mentioned in the other patch I think we're doing things in the wrong
> > > order here. I suspect it'll be cleaner to just stop doing
> > > intel_dp_set_link_train(DISABLE) entirely and just have a dedicated
> > > function for disabling link training. We can then trivially do a
> > > followup to swap the order of operations to match the spec.
> >
> > intel_dp_disable_dpcd_training_pattern() would be needed after each
> > LTTPR link training phase, where the port should not output idle
> > patterns, that's the only reason for this change.
> >
> > Do you mean to remove intel_dp_stop_link_train() then and do the idle
> > pattern programming + corresponding DPCD training pattern disable
> > programming at the end of the link training sequence (and remove the
> > DP_TRAINING_PATTERN_DISABLE case handling from above)? I agree with
> > that, but I see that too as a follow-up material (along with changing
> > the order as you suggested).
>
> Yeah, followup shuld be fine. I was just thinking of doing
> s/intel_dp_set_link_train(DP_TRAINING_PATTERN_DISABLE)/intel_dp_set_normal_link_train()/
> or
> s/intel_dp_set_link_train(DP_TRAINING_PATTERN_DISABLE)/intel_dp_disable_link_train()/
> or something along those lines.
Ok, that's simple enough, will do that instead in this patch.
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RESEND PATCH 1/2] drm/dp: fix kernel-doc warnings at drm_dp_helper.c
From: Mauro Carvalho Chehab
As warned by kernel-doc:
./drivers/gpu/drm/drm_dp_helper.c:385: warning: Function parameter or
member 'type' not described in 'drm_dp_downstream_is_type'
./drivers/gpu/drm/drm_dp_helper.c:886: warning: Function parameter or
member 'dev' not described in 'drm_dp_downstream_mode'
Some function parameters weren't documented.
Fixes: 38784f6f8805 ("drm/dp: Add helpers to identify downstream facing port
types")
Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_helper.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 90807a6b415c..478dd51f738d 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -374,6 +374,10 @@ static bool is_edid_digital_input_dp(const struct edid
*edid)
* drm_dp_downstream_is_type() - is the downstream facing port of certain type?
* @dpcd: DisplayPort configuration data
* @port_cap: port capabilities
+ * @type: port type to be checked. Can be:
+ * %DP_DS_PORT_TYPE_DP, %DP_DS_PORT_TYPE_VGA, %DP_DS_PORT_TYPE_DVI,
+ * %DP_DS_PORT_TYPE_HDMI, %DP_DS_PORT_TYPE_NON_EDID,
+ * %DP_DS_PORT_TYPE_DP_DUALMODE or %DP_DS_PORT_TYPE_WIRELESS.
*
* Caveat: Only works with DPCD 1.1+ port caps.
*
@@ -870,6 +874,7 @@ EXPORT_SYMBOL(drm_dp_downstream_444_to_420_conversion);
/**
* drm_dp_downstream_mode() - return a mode for downstream facing port
+ * @dev: DRM device
* @dpcd: DisplayPort configuration data
* @port_cap: port capabilities
*
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RESEND PATCH 0/2] drm/i915: kernel-doc fixes for new DP helpers
Note that none of the code that this touches is in i915, however at the time I posted this patch all of the DP helpers that concern these patches were added through drm-intel-next-queued, not drm-misc-next, so it makes more sense to merge it through drm-intel-next-queued. As such, I'm just sending this onto intel-gfx so that it gets a patch ID. This should introduce no functional changes, and is already reviewed by me. Mauro Carvalho Chehab (2): drm/dp: fix kernel-doc warnings at drm_dp_helper.c drm/dp: fix a kernel-doc issue at drm_edid.c drivers/gpu/drm/drm_dp_helper.c | 5 + drivers/gpu/drm/drm_edid.c | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-) -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RESEND PATCH 2/2] drm/dp: fix a kernel-doc issue at drm_edid.c
From: Mauro Carvalho Chehab
The name of the argument is different, causing those warnings:
./drivers/gpu/drm/drm_edid.c:3754: warning: Function parameter or
member 'video_code' not described in 'drm_display_mode_from_cea_vic'
./drivers/gpu/drm/drm_edid.c:3754: warning: Excess function parameter
'vic' description in 'drm_display_mode_from_cea_vic'
Fixes: 7af655bce275 ("drm/dp: Add drm_dp_downstream_mode()")
Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Lyude Paul
---
drivers/gpu/drm/drm_edid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a82f37d44258..631125b46e04 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3741,7 +3741,7 @@ drm_add_cmdb_modes(struct drm_connector *connector, u8
svd)
/**
* drm_display_mode_from_cea_vic() - return a mode for CEA VIC
* @dev: DRM device
- * @vic: CEA VIC of the mode
+ * @video_code: CEA VIC of the mode
*
* Creates a new mode matching the specified CEA VIC.
*
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915: Factor out a helper to disable the DPCD training pattern
On Tue, Sep 22, 2020 at 08:41:28PM +0300, Imre Deak wrote:
> On Tue, Sep 22, 2020 at 07:54:20PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 22, 2020 at 03:51:03PM +0300, Imre Deak wrote:
> > > To prepare for a follow-up LTTPR change factor out a helper to disable
> > > the training pattern in DPCD. We'll need to do this for each LTTPR
> > > (without programming the port to output the idle pattern) when training
> > > in LTTPR non-transparent mode.
> > >
> > > Signed-off-by: Imre Deak
> > > ---
> > > .../drm/i915/display/intel_dp_link_training.c | 28 +++
> > > 1 file changed, 16 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > index 0c3809891bd2..6994a32244dc 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > @@ -102,30 +102,34 @@ void intel_dp_get_adjust_train(struct intel_dp
> > > *intel_dp,
> > > intel_dp->train_set[lane] = v | p;
> > > }
> > >
> > > +static bool intel_dp_disable_dpcd_training_pattern(struct intel_dp
> > > *intel_dp)
> > > +{
> > > + u8 val = DP_TRAINING_PATTERN_DISABLE;
> > > +
> > > + return drm_dp_dpcd_write(_dp->aux, DP_TRAINING_PATTERN_SET, ,
> > > 1) == 1;
> > > +}
> >
> >
> > > +
> > > static bool
> > > intel_dp_set_link_train(struct intel_dp *intel_dp,
> > > u8 dp_train_pat)
> > > {
> > > u8 buf[sizeof(intel_dp->train_set) + 1];
> > > - int ret, len;
> > > + int len;
> > >
> > > intel_dp_program_link_training_pattern(intel_dp, dp_train_pat);
> > >
> > > - buf[0] = dp_train_pat;
> > > if ((dp_train_pat & ~DP_LINK_SCRAMBLING_DISABLE) ==
> > > - DP_TRAINING_PATTERN_DISABLE) {
> > > + DP_TRAINING_PATTERN_DISABLE)
> > > /* don't write DP_TRAINING_LANEx_SET on disable */
> >
> > As mentioned in the other patch I think we're doing things in the wrong
> > order here. I suspect it'll be cleaner to just stop doing
> > intel_dp_set_link_train(DISABLE) entirely and just have a dedicated
> > function for disabling link training. We can then trivially do a
> > followup to swap the order of operations to match the spec.
>
> intel_dp_disable_dpcd_training_pattern() would be needed after each
> LTTPR link training phase, where the port should not output idle
> patterns, that's the only reason for this change.
>
> Do you mean to remove intel_dp_stop_link_train() then and do the idle
> pattern programming + corresponding DPCD training pattern disable
> programming at the end of the link training sequence (and remove the
> DP_TRAINING_PATTERN_DISABLE case handling from above)? I agree with
> that, but I see that too as a follow-up material (along with changing
> the order as you suggested).
Yeah, followup shuld be fine. I was just thinking of doing
s/intel_dp_set_link_train(DP_TRAINING_PATTERN_DISABLE)/intel_dp_set_normal_link_train()/
or
s/intel_dp_set_link_train(DP_TRAINING_PATTERN_DISABLE)/intel_dp_disable_link_train()/
or something along those lines.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/7] drm/i915: Simplify the link training functions
On Tue, Sep 22, 2020 at 08:25:35PM +0300, Imre Deak wrote:
> On Tue, Sep 22, 2020 at 07:49:17PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 22, 2020 at 06:30:35PM +0300, Imre Deak wrote:
> > > On Tue, Sep 22, 2020 at 04:27:05PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Sep 22, 2020 at 03:51:02PM +0300, Imre Deak wrote:
> > > > > Split the prepare, link training, fallback-handling steps into their
> > > > > own
> > > > > functions for clarity and as a preparation for the upcoming LTTPR
> > > > > changes.
> > > > >
> > > > > While at it also add some documentation to exported functions.
> > > > >
> > > > > Signed-off-by: Imre Deak
> > > > > ---
> > > > > .../drm/i915/display/intel_dp_link_training.c | 80
> > > > > ++-
> > > > > 1 file changed, 62 insertions(+), 18 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > > > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > > > index 6d13d00db5e6..0c3809891bd2 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > > > @@ -162,14 +162,13 @@ static bool
> > > > > intel_dp_link_max_vswing_reached(struct intel_dp *intel_dp)
> > > > > return true;
> > > > > }
> > > > >
> > > > > -/* Enable corresponding port and start training pattern 1 */
> > > > > -static bool
> > > > > -intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > > > > +/*
> > > > > + * Prepare link training by configuring the link parameters and
> > > > > enabling the
> > > > > + * corresponding port.
> > > > > + */
> > > > > +static void intel_dp_prepare_link_train(struct intel_dp *intel_dp)
> > > > > {
> > > > > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > > - u8 voltage;
> > > > > - int voltage_tries, cr_tries, max_cr_tries;
> > > > > - bool max_vswing_reached = false;
> > > > > u8 link_config[2];
> > > > > u8 link_bw, rate_select;
> > > > >
> > > > > @@ -203,6 +202,16 @@ intel_dp_link_training_clock_recovery(struct
> > > > > intel_dp *intel_dp)
> > > > > drm_dp_dpcd_write(_dp->aux, DP_DOWNSPREAD_CTRL,
> > > > > link_config, 2);
> > > > >
> > > > > intel_dp->DP |= DP_PORT_EN;
> > > >
> > > > I guess we no longer actually enable the port here? The comment ^ still
> > > > says
> > > > we do.
> > > >
> > > > Hmm. Seems we do enable the port on ddi platforms, but not on older
> > > > platforms. I guess the docs could still use a tweak to reflect
> > > > reality a bit better.
> > >
> > > Yes, missed the old platform part, will update the comment.
> > >
> > > >
> > > > > +}
> > > > > +
> > > > > +/* Perform the link training clock recovery phase using training
> > > > > pattern 1. */
> > > > > +static bool
> > > > > +intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > > > > +{
> > > > > + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > > + u8 voltage;
> > > > > + int voltage_tries, cr_tries, max_cr_tries;
> > > > > + bool max_vswing_reached = false;
> > > > >
> > > > > /* clock recovery */
> > > > > if (!intel_dp_reset_link_train(intel_dp,
> > > > > @@ -325,6 +334,10 @@ static u32 intel_dp_training_pattern(struct
> > > > > intel_dp *intel_dp)
> > > > > return DP_TRAINING_PATTERN_2;
> > > > > }
> > > > >
> > > > > +/*
> > > > > + * Perform the link training channel equalization phase using one of
> > > > > training
> > > > > + * pattern 2, 3 or 4 depending on the the source and sink
> > > > > capabilities.
> > > > > + */
> > > > > static bool
> > > > > intel_dp_link_training_channel_equalization(struct intel_dp
> > > > > *intel_dp)
> > > > > {
> > > > > @@ -395,6 +408,15 @@
> > > > > intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > > > >
> > > > > }
> > > > >
> > > > > +/**
> > > > > + * intel_dp_stop_link_train - stop link training
> > > > > + * @intel_dp: DP struct
> > > > > + *
> > > > > + * Stop the link training of the @intel_dp port, programming the
> > > > > port to
> > > > > + * output an idle pattern
> > > >
> > > > I don't think we use the idle pattern on all platforms.
> > >
> > > Yes, just DDI, this also needs a doc update.
> > >
> > > > BTW intel_dp_set_idle_link_train() looks pretty pointless. Could just
> > > > inline it into its only caller, or at least move it into
> > > > intel_dp_link_training.c.
> > >
> > > Ok, can unexport/inline it. Btw, this part made me wonder what's the
> > > exact reason for keeping the idle pattern output and corresponding DPCD
> > > programming separate, that is why can't we disable the training pattern
> > > in DPCD after intel_dp_set_idle_link_train()? That would make things
> > > more uniform on all platforms.
> >
> > Hmm. I guess we're violating the DP spec a bit with the current
> > sequence:
> > "The Source device shall start sending the idle pattern after it
Re: [Intel-gfx] [PATCH 4/7] drm/i915: Factor out a helper to disable the DPCD training pattern
On Tue, Sep 22, 2020 at 07:54:20PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 22, 2020 at 03:51:03PM +0300, Imre Deak wrote:
> > To prepare for a follow-up LTTPR change factor out a helper to disable
> > the training pattern in DPCD. We'll need to do this for each LTTPR
> > (without programming the port to output the idle pattern) when training
> > in LTTPR non-transparent mode.
> >
> > Signed-off-by: Imre Deak
> > ---
> > .../drm/i915/display/intel_dp_link_training.c | 28 +++
> > 1 file changed, 16 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > index 0c3809891bd2..6994a32244dc 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > @@ -102,30 +102,34 @@ void intel_dp_get_adjust_train(struct intel_dp
> > *intel_dp,
> > intel_dp->train_set[lane] = v | p;
> > }
> >
> > +static bool intel_dp_disable_dpcd_training_pattern(struct intel_dp
> > *intel_dp)
> > +{
> > + u8 val = DP_TRAINING_PATTERN_DISABLE;
> > +
> > + return drm_dp_dpcd_write(_dp->aux, DP_TRAINING_PATTERN_SET, ,
> > 1) == 1;
> > +}
>
>
> > +
> > static bool
> > intel_dp_set_link_train(struct intel_dp *intel_dp,
> > u8 dp_train_pat)
> > {
> > u8 buf[sizeof(intel_dp->train_set) + 1];
> > - int ret, len;
> > + int len;
> >
> > intel_dp_program_link_training_pattern(intel_dp, dp_train_pat);
> >
> > - buf[0] = dp_train_pat;
> > if ((dp_train_pat & ~DP_LINK_SCRAMBLING_DISABLE) ==
> > - DP_TRAINING_PATTERN_DISABLE) {
> > + DP_TRAINING_PATTERN_DISABLE)
> > /* don't write DP_TRAINING_LANEx_SET on disable */
>
> As mentioned in the other patch I think we're doing things in the wrong
> order here. I suspect it'll be cleaner to just stop doing
> intel_dp_set_link_train(DISABLE) entirely and just have a dedicated
> function for disabling link training. We can then trivially do a
> followup to swap the order of operations to match the spec.
intel_dp_disable_dpcd_training_pattern() would be needed after each
LTTPR link training phase, where the port should not output idle
patterns, that's the only reason for this change.
Do you mean to remove intel_dp_stop_link_train() then and do the idle
pattern programming + corresponding DPCD training pattern disable
programming at the end of the link training sequence (and remove the
DP_TRAINING_PATTERN_DISABLE case handling from above)? I agree with
that, but I see that too as a follow-up material (along with changing
the order as you suggested).
>
> > - len = 1;
> > - } else {
> > - /* DP_TRAINING_LANEx_SET follow DP_TRAINING_PATTERN_SET */
> > - memcpy(buf + 1, intel_dp->train_set, intel_dp->lane_count);
> > - len = intel_dp->lane_count + 1;
> > - }
> > + return intel_dp_disable_dpcd_training_pattern(intel_dp);
> >
> > - ret = drm_dp_dpcd_write(_dp->aux, DP_TRAINING_PATTERN_SET,
> > - buf, len);
> > + buf[0] = dp_train_pat;
> > + /* DP_TRAINING_LANEx_SET follow DP_TRAINING_PATTERN_SET */
> > + memcpy(buf + 1, intel_dp->train_set, intel_dp->lane_count);
> > + len = intel_dp->lane_count + 1;
> >
> > - return ret == len;
> > + return drm_dp_dpcd_write(_dp->aux, DP_TRAINING_PATTERN_SET,
> > +buf, len) == len;
> > }
> >
> > static bool
> > --
> > 2.17.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Switch to LTTPR non-transparent mode link training
On Tue, Sep 22, 2020 at 03:51:06PM +0300, Imre Deak wrote:
> The DP Standard's recommendation is to use the LTTPR non-transparent
> mode link training if LTTPRs are detected, so let's do this.
>
> Besides power-saving, the advantages of this are that the maximum number
> of LTTPRs can only be used in non-transparent mode (the limit is 5-8 in
> transparent mode), and it provides a way to narrow down the reason for a
> link training failure to a given link segment. Non-transparent mode is
> probably also the mode that was tested the most by the industry.
>
> The changes in this patchset:
> - Pass the DP PHY that is currently link trained to all LT helpers, so
> that these can access the correct LTTPR/DPRX DPCD registers.
> - During LT take into account the LTTPR common lane rate/count and the
> per LTTPR-PHY vswing/pre-emph limits.
> - Switch to LTTPR non-transparent LT mode and train each link segment
> according to the sequence in DP Standard v2.0 (complete CR/EQ for
> each segment before continuing with the next segment).
>
> Signed-off-by: Imre Deak
> ---
> .../drm/i915/display/intel_display_types.h| 1 +
> drivers/gpu/drm/i915/display/intel_dp.c | 14 +-
> .../drm/i915/display/intel_dp_link_training.c | 374 +++---
> .../drm/i915/display/intel_dp_link_training.h | 10 +-
> 4 files changed, 327 insertions(+), 72 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index b04921eba73b..2fb4e9a6a316 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1281,6 +1281,7 @@ struct intel_dp {
> u8 edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE];
> u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE];
> u8 lttpr_common_caps[DP_LTTPR_COMMON_CAP_SIZE];
> + u8 lttpr_phy_caps[DP_MAX_LTTPR_COUNT][DP_LTTPR_PHY_CAP_SIZE];
> u8 fec_capable;
> /* source rates */
> int num_source_rates;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index d88f327aa9ef..54ad31044eef 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -161,6 +161,7 @@ static void intel_dp_set_sink_rates(struct intel_dp
> *intel_dp)
> 162000, 27, 54, 81
> };
> int i, max_rate;
> + int max_lttpr_rate;
>
> if (drm_dp_has_quirk(_dp->desc, 0,
>DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS)) {
> @@ -174,6 +175,9 @@ static void intel_dp_set_sink_rates(struct intel_dp
> *intel_dp)
> }
>
> max_rate =
> drm_dp_bw_code_to_link_rate(intel_dp->dpcd[DP_MAX_LINK_RATE]);
> + max_lttpr_rate =
> drm_dp_lttpr_max_link_rate(intel_dp->lttpr_common_caps);
> + if (max_lttpr_rate)
> + max_rate = min(max_rate, max_lttpr_rate);
>
> for (i = 0; i < ARRAY_SIZE(dp_rates); i++) {
> if (dp_rates[i] > max_rate)
> @@ -219,6 +223,10 @@ static int intel_dp_max_common_lane_count(struct
> intel_dp *intel_dp)
> int source_max = dig_port->max_lanes;
> int sink_max = drm_dp_max_lane_count(intel_dp->dpcd);
> int fia_max = intel_tc_port_fia_max_lane_count(dig_port);
> + int lttpr_max =
> drm_dp_lttpr_max_lane_count(intel_dp->lttpr_common_caps);
> +
> + if (lttpr_max)
> + sink_max = min(sink_max, lttpr_max);
>
> return min3(source_max, sink_max, fia_max);
> }
> @@ -5540,13 +5548,13 @@ void intel_dp_process_phy_request(struct intel_dp
> *intel_dp)
> _dp->compliance.test_data.phytest;
> u8 link_status[DP_LINK_STATUS_SIZE];
>
> - if (!intel_dp_get_link_status(intel_dp, link_status)) {
> + if (!intel_dp_get_link_status(intel_dp, DP_PHY_DPRX, link_status)) {
> DRM_DEBUG_KMS("failed to get link status\n");
> return;
> }
>
> /* retrieve vswing & pre-emphasis setting */
> - intel_dp_get_adjust_train(intel_dp, link_status);
> + intel_dp_get_adjust_train(intel_dp, DP_PHY_DPRX, link_status);
>
> intel_dp_autotest_phy_ddi_disable(intel_dp);
>
> @@ -5701,7 +5709,7 @@ intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
> if (intel_psr_enabled(intel_dp))
> return false;
>
> - if (!intel_dp_get_link_status(intel_dp, link_status))
> + if (!intel_dp_get_link_status(intel_dp, DP_PHY_DPRX, link_status))
Should we check all repeaters here too perhaps?
I guess that should be a followup if we need it.
> return false;
>
> /*
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index 1485602659be..3aa685a9aa2a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -25,6 +25,8 @@
> #include "intel_dp.h"
> #include
Re: [Intel-gfx] [PULL] gvt-fixes
On Thu, 17 Sep 2020, Zhenyu Wang wrote: > Hi, > > Here's one left GVT fix against 5.9 is for kernel oops with VFIO edid > on BDW. Pulled, thanks. BR, Jani. > > Thanks > -- > The following changes since commit a291e4fba259a56a6a274c1989997acb6f0bb03a: > > drm/i915/gvt: Use GFP_ATOMIC instead of GFP_KERNEL in atomic context > (2020-06-17 12:36:19 +0800) > > are available in the Git repository at: > > https://github.com/intel/gvt-linux tags/gvt-fixes-2020-09-17 > > for you to fetch changes up to 28284943ac94014767ecc2f7b3c5747c4a5617a0: > > drm/i915/gvt: Fix port number for BDW on EDID region setup (2020-09-14 > 16:44:39 +0800) > > > gvt-fixes-2020-09-17 > > - Fix kernel oops for VFIO edid on BDW (Zhenyu) > > > Zhenyu Wang (1): > drm/i915/gvt: Fix port number for BDW on EDID region setup > > drivers/gpu/drm/i915/gvt/vgpu.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/7] drm/i915: Simplify the link training functions
On Tue, Sep 22, 2020 at 07:49:17PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 22, 2020 at 06:30:35PM +0300, Imre Deak wrote:
> > On Tue, Sep 22, 2020 at 04:27:05PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 22, 2020 at 03:51:02PM +0300, Imre Deak wrote:
> > > > Split the prepare, link training, fallback-handling steps into their own
> > > > functions for clarity and as a preparation for the upcoming LTTPR
> > > > changes.
> > > >
> > > > While at it also add some documentation to exported functions.
> > > >
> > > > Signed-off-by: Imre Deak
> > > > ---
> > > > .../drm/i915/display/intel_dp_link_training.c | 80 ++-
> > > > 1 file changed, 62 insertions(+), 18 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > > index 6d13d00db5e6..0c3809891bd2 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > > @@ -162,14 +162,13 @@ static bool
> > > > intel_dp_link_max_vswing_reached(struct intel_dp *intel_dp)
> > > > return true;
> > > > }
> > > >
> > > > -/* Enable corresponding port and start training pattern 1 */
> > > > -static bool
> > > > -intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > > > +/*
> > > > + * Prepare link training by configuring the link parameters and
> > > > enabling the
> > > > + * corresponding port.
> > > > + */
> > > > +static void intel_dp_prepare_link_train(struct intel_dp *intel_dp)
> > > > {
> > > > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > - u8 voltage;
> > > > - int voltage_tries, cr_tries, max_cr_tries;
> > > > - bool max_vswing_reached = false;
> > > > u8 link_config[2];
> > > > u8 link_bw, rate_select;
> > > >
> > > > @@ -203,6 +202,16 @@ intel_dp_link_training_clock_recovery(struct
> > > > intel_dp *intel_dp)
> > > > drm_dp_dpcd_write(_dp->aux, DP_DOWNSPREAD_CTRL,
> > > > link_config, 2);
> > > >
> > > > intel_dp->DP |= DP_PORT_EN;
> > >
> > > I guess we no longer actually enable the port here? The comment ^ still
> > > says
> > > we do.
> > >
> > > Hmm. Seems we do enable the port on ddi platforms, but not on older
> > > platforms. I guess the docs could still use a tweak to reflect
> > > reality a bit better.
> >
> > Yes, missed the old platform part, will update the comment.
> >
> > >
> > > > +}
> > > > +
> > > > +/* Perform the link training clock recovery phase using training
> > > > pattern 1. */
> > > > +static bool
> > > > +intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > > > +{
> > > > + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > + u8 voltage;
> > > > + int voltage_tries, cr_tries, max_cr_tries;
> > > > + bool max_vswing_reached = false;
> > > >
> > > > /* clock recovery */
> > > > if (!intel_dp_reset_link_train(intel_dp,
> > > > @@ -325,6 +334,10 @@ static u32 intel_dp_training_pattern(struct
> > > > intel_dp *intel_dp)
> > > > return DP_TRAINING_PATTERN_2;
> > > > }
> > > >
> > > > +/*
> > > > + * Perform the link training channel equalization phase using one of
> > > > training
> > > > + * pattern 2, 3 or 4 depending on the the source and sink capabilities.
> > > > + */
> > > > static bool
> > > > intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > > > {
> > > > @@ -395,6 +408,15 @@ intel_dp_link_training_channel_equalization(struct
> > > > intel_dp *intel_dp)
> > > >
> > > > }
> > > >
> > > > +/**
> > > > + * intel_dp_stop_link_train - stop link training
> > > > + * @intel_dp: DP struct
> > > > + *
> > > > + * Stop the link training of the @intel_dp port, programming the port
> > > > to
> > > > + * output an idle pattern
> > >
> > > I don't think we use the idle pattern on all platforms.
> >
> > Yes, just DDI, this also needs a doc update.
> >
> > > BTW intel_dp_set_idle_link_train() looks pretty pointless. Could just
> > > inline it into its only caller, or at least move it into
> > > intel_dp_link_training.c.
> >
> > Ok, can unexport/inline it. Btw, this part made me wonder what's the
> > exact reason for keeping the idle pattern output and corresponding DPCD
> > programming separate, that is why can't we disable the training pattern
> > in DPCD after intel_dp_set_idle_link_train()? That would make things
> > more uniform on all platforms.
>
> Hmm. I guess we're violating the DP spec a bit with the current
> sequence:
> "The Source device shall start sending the idle pattern after it has
> cleared the Training_Pattern byte in the DPCD"
Yep, that order sounds correct. In v2.0 3.6.6.6.10 End of Link Training
suggests the current sequence though, but the sink should be able to
handle the idle pattern after the sink reported symbol lock .
> Currently we start sending the idle pattern
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: simplify the return expression of i915_driver_release()
== Series Details == Series: drm/i915: simplify the return expression of i915_driver_release() URL : https://patchwork.freedesktop.org/series/81977/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9034_full -> Patchwork_18546_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18546_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18546_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_18546_full: ### IGT changes ### Possible regressions * igt@kms_flip@2x-plain-flip-interruptible@ac-vga1-hdmi-a1: - shard-hsw: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18546/shard-hsw4/igt@kms_flip@2x-plain-flip-interrupti...@ac-vga1-hdmi-a1.html * igt@kms_flip@dpms-vs-vblank-race-interruptible@c-vga1: - shard-hsw: [PASS][2] -> [INCOMPLETE][3] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/shard-hsw4/igt@kms_flip@dpms-vs-vblank-race-interrupti...@c-vga1.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18546/shard-hsw2/igt@kms_flip@dpms-vs-vblank-race-interrupti...@c-vga1.html Known issues Here are the changes found in Patchwork_18546_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_userptr_blits@unsync-unmap-cycles: - shard-skl: [PASS][4] -> [TIMEOUT][5] ([i915#1958]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/shard-skl1/igt@gem_userptr_bl...@unsync-unmap-cycles.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18546/shard-skl3/igt@gem_userptr_bl...@unsync-unmap-cycles.html * igt@gen9_exec_parse@allowed-all: - shard-kbl: [PASS][6] -> [DMESG-WARN][7] ([i915#1436] / [i915#716]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/shard-kbl6/igt@gen9_exec_pa...@allowed-all.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18546/shard-kbl2/igt@gen9_exec_pa...@allowed-all.html * igt@i915_selftest@mock@requests: - shard-skl: [PASS][8] -> [INCOMPLETE][9] ([i915#198] / [i915#2278]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/shard-skl1/igt@i915_selftest@m...@requests.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18546/shard-skl6/igt@i915_selftest@m...@requests.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-skl: [PASS][10] -> [INCOMPLETE][11] ([i915#300]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/shard-skl10/igt@kms_cursor_...@pipe-b-cursor-suspend.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18546/shard-skl4/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: - shard-hsw: [PASS][12] -> [FAIL][13] ([i915#96]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/shard-hsw7/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18546/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html * igt@kms_draw_crc@draw-method-rgb565-mmap-cpu-ytiled: - shard-skl: [PASS][14] -> [DMESG-WARN][15] ([i915#1982]) +5 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/shard-skl1/igt@kms_draw_...@draw-method-rgb565-mmap-cpu-ytiled.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18546/shard-skl3/igt@kms_draw_...@draw-method-rgb565-mmap-cpu-ytiled.html * igt@kms_flip@flip-vs-suspend-interruptible@b-edp1: - shard-skl: [PASS][16] -> [INCOMPLETE][17] ([i915#198]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/shard-skl3/igt@kms_flip@flip-vs-suspend-interrupti...@b-edp1.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18546/shard-skl3/igt@kms_flip@flip-vs-suspend-interrupti...@b-edp1.html * igt@kms_flip@plain-flip-ts-check@c-edp1: - shard-skl: [PASS][18] -> [FAIL][19] ([i915#2122]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/shard-skl2/igt@kms_flip@plain-flip-ts-ch...@c-edp1.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18546/shard-skl1/igt@kms_flip@plain-flip-ts-ch...@c-edp1.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-wc: - shard-skl: [PASS][20] -> [FAIL][21] ([i915#49]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/shard-skl9/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-mmap-wc.html [21]:
Re: [Intel-gfx] [PATCH 3/6] drm/i915: use vmap in shmem_pin_map
On 22/09/2020 17:33, Christoph Hellwig wrote:
On Tue, Sep 22, 2020 at 05:13:45PM +0100, Tvrtko Ursulin wrote:
void *shmem_pin_map(struct file *file)
{
- const size_t n_pte = shmem_npte(file);
- pte_t *stack[32], **ptes, **mem;
Chris can comment how much he'd miss the 32 page stack shortcut.
I'd like to see a profile that claim that kmalloc matters in a
path that does a vmap and reads pages through the page cache.
Especially when the kmalloc saves doing another page cache lookup
on the free side.
Only reason I can come up with now is if mapping side is on a latency
sensitive path, while un-mapping is lazy/delayed so can be more costly.
Then fast map and extra cost on unmap may make sense.
It more applies to the other i915 patch, which implements a much more
used API, but whether or not we can demonstrate any difference in the
perf profiles I couldn't tell you without trying to collect some.
Is there something in vmap() preventing us from freeing the pages array
here? I can't spot anything that is holding on to the pointer. Or it was
just a sketch before you realized we could walk the vm_area?
Also, I may be totally misunderstanding something, but I think you need to
assign area->pages manually so shmem_unpin_map can access it below.
We need area->pages to hold the pages for the free side. That being
said the patch I posted is broken because it never assigned to that.
As said it was a sketch. This is the patch I just rebooted into on
my Laptop:
http://git.infradead.org/users/hch/misc.git/commitdiff/048522dfa26b6667adfb0371ff530dc263abe829
it needs extra prep patches from the series:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/alloc_vm_area
mapping_clear_unevictable(file->f_mapping);
- __shmem_unpin_map(file, ptr, shmem_npte(file));
+ for (i = 0; i < shmem_npages(file); i++)
+ put_page(area->pages[i]);
+ kvfree(area->pages);
+ vunmap(ptr);
Is the verdict from mm experts that we can't use vfree due __free_pages vs
put_page differences?
Switched to vfree now.
Could we get from ptes to pages, so that we don't have to keep the
area->pages array allocated for the duration of the pin?
We could do vmalloc_to_page, but that is fairly expensive (not as bad
as reading from the page cache..). Are you really worried about the
allocation?
Not so much given how we don't even use shmem_pin_map outside selftests.
If we start using it I expect it will be for tiny objects anyway. Only
if they end up being pinned for the lifetime of the driver, it may be a
pointless waste of memory compared to the downsides of vmalloc_to_page.
But we can revisit this particular edge case optimization if the need
arises.
I'll look at your other i915 patch tomorrow.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915: Factor out a helper to disable the DPCD training pattern
On Tue, Sep 22, 2020 at 03:51:03PM +0300, Imre Deak wrote:
> To prepare for a follow-up LTTPR change factor out a helper to disable
> the training pattern in DPCD. We'll need to do this for each LTTPR
> (without programming the port to output the idle pattern) when training
> in LTTPR non-transparent mode.
>
> Signed-off-by: Imre Deak
> ---
> .../drm/i915/display/intel_dp_link_training.c | 28 +++
> 1 file changed, 16 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index 0c3809891bd2..6994a32244dc 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -102,30 +102,34 @@ void intel_dp_get_adjust_train(struct intel_dp
> *intel_dp,
> intel_dp->train_set[lane] = v | p;
> }
>
> +static bool intel_dp_disable_dpcd_training_pattern(struct intel_dp *intel_dp)
> +{
> + u8 val = DP_TRAINING_PATTERN_DISABLE;
> +
> + return drm_dp_dpcd_write(_dp->aux, DP_TRAINING_PATTERN_SET, ,
> 1) == 1;
> +}
> +
> static bool
> intel_dp_set_link_train(struct intel_dp *intel_dp,
> u8 dp_train_pat)
> {
> u8 buf[sizeof(intel_dp->train_set) + 1];
> - int ret, len;
> + int len;
>
> intel_dp_program_link_training_pattern(intel_dp, dp_train_pat);
>
> - buf[0] = dp_train_pat;
> if ((dp_train_pat & ~DP_LINK_SCRAMBLING_DISABLE) ==
> - DP_TRAINING_PATTERN_DISABLE) {
> + DP_TRAINING_PATTERN_DISABLE)
> /* don't write DP_TRAINING_LANEx_SET on disable */
As mentioned in the other patch I think we're doing things in the wrong
order here. I suspect it'll be cleaner to just stop doing
intel_dp_set_link_train(DISABLE) entirely and just have a dedicated
function for disabling link training. We can then trivially do a
followup to swap the order of operations to match the spec.
> - len = 1;
> - } else {
> - /* DP_TRAINING_LANEx_SET follow DP_TRAINING_PATTERN_SET */
> - memcpy(buf + 1, intel_dp->train_set, intel_dp->lane_count);
> - len = intel_dp->lane_count + 1;
> - }
> + return intel_dp_disable_dpcd_training_pattern(intel_dp);
>
> - ret = drm_dp_dpcd_write(_dp->aux, DP_TRAINING_PATTERN_SET,
> - buf, len);
> + buf[0] = dp_train_pat;
> + /* DP_TRAINING_LANEx_SET follow DP_TRAINING_PATTERN_SET */
> + memcpy(buf + 1, intel_dp->train_set, intel_dp->lane_count);
> + len = intel_dp->lane_count + 1;
>
> - return ret == len;
> + return drm_dp_dpcd_write(_dp->aux, DP_TRAINING_PATTERN_SET,
> + buf, len) == len;
> }
>
> static bool
> --
> 2.17.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/7] drm/i915: Simplify the link training functions
On Tue, Sep 22, 2020 at 06:30:35PM +0300, Imre Deak wrote:
> On Tue, Sep 22, 2020 at 04:27:05PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 22, 2020 at 03:51:02PM +0300, Imre Deak wrote:
> > > Split the prepare, link training, fallback-handling steps into their own
> > > functions for clarity and as a preparation for the upcoming LTTPR changes.
> > >
> > > While at it also add some documentation to exported functions.
> > >
> > > Signed-off-by: Imre Deak
> > > ---
> > > .../drm/i915/display/intel_dp_link_training.c | 80 ++-
> > > 1 file changed, 62 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > index 6d13d00db5e6..0c3809891bd2 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > @@ -162,14 +162,13 @@ static bool intel_dp_link_max_vswing_reached(struct
> > > intel_dp *intel_dp)
> > > return true;
> > > }
> > >
> > > -/* Enable corresponding port and start training pattern 1 */
> > > -static bool
> > > -intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > > +/*
> > > + * Prepare link training by configuring the link parameters and enabling
> > > the
> > > + * corresponding port.
> > > + */
> > > +static void intel_dp_prepare_link_train(struct intel_dp *intel_dp)
> > > {
> > > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > - u8 voltage;
> > > - int voltage_tries, cr_tries, max_cr_tries;
> > > - bool max_vswing_reached = false;
> > > u8 link_config[2];
> > > u8 link_bw, rate_select;
> > >
> > > @@ -203,6 +202,16 @@ intel_dp_link_training_clock_recovery(struct
> > > intel_dp *intel_dp)
> > > drm_dp_dpcd_write(_dp->aux, DP_DOWNSPREAD_CTRL, link_config, 2);
> > >
> > > intel_dp->DP |= DP_PORT_EN;
> >
> > I guess we no longer actually enable the port here? The comment ^ still says
> > we do.
> >
> > Hmm. Seems we do enable the port on ddi platforms, but not on older
> > platforms. I guess the docs could still use a tweak to reflect
> > reality a bit better.
>
> Yes, missed the old platform part, will update the comment.
>
> >
> > > +}
> > > +
> > > +/* Perform the link training clock recovery phase using training pattern
> > > 1. */
> > > +static bool
> > > +intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > > +{
> > > + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > + u8 voltage;
> > > + int voltage_tries, cr_tries, max_cr_tries;
> > > + bool max_vswing_reached = false;
> > >
> > > /* clock recovery */
> > > if (!intel_dp_reset_link_train(intel_dp,
> > > @@ -325,6 +334,10 @@ static u32 intel_dp_training_pattern(struct intel_dp
> > > *intel_dp)
> > > return DP_TRAINING_PATTERN_2;
> > > }
> > >
> > > +/*
> > > + * Perform the link training channel equalization phase using one of
> > > training
> > > + * pattern 2, 3 or 4 depending on the the source and sink capabilities.
> > > + */
> > > static bool
> > > intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > > {
> > > @@ -395,6 +408,15 @@ intel_dp_link_training_channel_equalization(struct
> > > intel_dp *intel_dp)
> > >
> > > }
> > >
> > > +/**
> > > + * intel_dp_stop_link_train - stop link training
> > > + * @intel_dp: DP struct
> > > + *
> > > + * Stop the link training of the @intel_dp port, programming the port to
> > > + * output an idle pattern
> >
> > I don't think we use the idle pattern on all platforms.
>
> Yes, just DDI, this also needs a doc update.
>
> > BTW intel_dp_set_idle_link_train() looks pretty pointless. Could just
> > inline it into its only caller, or at least move it into
> > intel_dp_link_training.c.
>
> Ok, can unexport/inline it. Btw, this part made me wonder what's the
> exact reason for keeping the idle pattern output and corresponding DPCD
> programming separate, that is why can't we disable the training pattern
> in DPCD after intel_dp_set_idle_link_train()? That would make things
> more uniform on all platforms.
Hmm. I guess we're violating the DP spec a bit with the current
sequence:
"The Source device shall start sending the idle pattern after it has
cleared the Training_Pattern byte in the DPCD"
Currently we start sending the idle pattern way earlier. And even
on platform where we don't send the idle pattern [1] we are disabling
the training pattern before we do the corresponding DPCD write.
So we may want to change the order to follow the spec.
[1] I guess the hw must send a few idle patterns automagically
since IIRC the spec requires it?
--
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.IGT: success for Add support for mipi dsi cmd mode (rev13)
== Series Details == Series: Add support for mipi dsi cmd mode (rev13) URL : https://patchwork.freedesktop.org/series/69290/ State : success == Summary == CI Bug Log - changes from CI_DRM_9034_full -> Patchwork_18545_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18545_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_reloc@basic-many-active@vcs0: - shard-glk: [PASS][1] -> [FAIL][2] ([i915#2389]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/shard-glk1/igt@gem_exec_reloc@basic-many-act...@vcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18545/shard-glk5/igt@gem_exec_reloc@basic-many-act...@vcs0.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_9034/shard-skl1/igt@gem_userptr_bl...@unsync-unmap-cycles.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18545/shard-skl5/igt@gem_userptr_bl...@unsync-unmap-cycles.html * igt@gen9_exec_parse@allowed-all: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#1436] / [i915#716]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/shard-kbl6/igt@gen9_exec_pa...@allowed-all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18545/shard-kbl2/igt@gen9_exec_pa...@allowed-all.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - shard-skl: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +7 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/shard-skl10/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18545/shard-skl7/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_flip@flip-vs-expired-vblank@a-edp1: - shard-skl: [PASS][9] -> [FAIL][10] ([i915#79]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/shard-skl1/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18545/shard-skl9/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html * igt@kms_flip@flip-vs-suspend@b-vga1: - shard-snb: [PASS][11] -> [INCOMPLETE][12] ([i915#82]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/shard-snb2/igt@kms_flip@flip-vs-susp...@b-vga1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18545/shard-snb1/igt@kms_flip@flip-vs-susp...@b-vga1.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-wc: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#49]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/shard-skl9/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-mmap-wc.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18545/shard-skl7/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-mmap-wc.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-render: - shard-tglb: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/shard-tglb2/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-shrfb-draw-render.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18545/shard-tglb2/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-shrfb-draw-render.html * igt@kms_hdr@bpc-switch-suspend: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/shard-kbl2/igt@kms_...@bpc-switch-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18545/shard-kbl4/igt@kms_...@bpc-switch-suspend.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145] / [i915#265]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/shard-skl9/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18545/shard-skl2/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][21] -> [DMESG-FAIL][22] ([fdo#108145] / [i915#1982]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18545/shard-skl10/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html [24]:
Re: [Intel-gfx] [PATCH 3/6] drm/i915: use vmap in shmem_pin_map
On Tue, Sep 22, 2020 at 05:13:45PM +0100, Tvrtko Ursulin wrote:
>> void *shmem_pin_map(struct file *file)
>> {
>> -const size_t n_pte = shmem_npte(file);
>> -pte_t *stack[32], **ptes, **mem;
>
> Chris can comment how much he'd miss the 32 page stack shortcut.
I'd like to see a profile that claim that kmalloc matters in a
path that does a vmap and reads pages through the page cache.
Especially when the kmalloc saves doing another page cache lookup
on the free side.
> Is there something in vmap() preventing us from freeing the pages array
> here? I can't spot anything that is holding on to the pointer. Or it was
> just a sketch before you realized we could walk the vm_area?
>
> Also, I may be totally misunderstanding something, but I think you need to
> assign area->pages manually so shmem_unpin_map can access it below.
We need area->pages to hold the pages for the free side. That being
said the patch I posted is broken because it never assigned to that.
As said it was a sketch. This is the patch I just rebooted into on
my Laptop:
http://git.infradead.org/users/hch/misc.git/commitdiff/048522dfa26b6667adfb0371ff530dc263abe829
it needs extra prep patches from the series:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/alloc_vm_area
>> mapping_clear_unevictable(file->f_mapping);
>> -__shmem_unpin_map(file, ptr, shmem_npte(file));
>> +for (i = 0; i < shmem_npages(file); i++)
>> +put_page(area->pages[i]);
>> +kvfree(area->pages);
>> +vunmap(ptr);
>
> Is the verdict from mm experts that we can't use vfree due __free_pages vs
> put_page differences?
Switched to vfree now.
> Could we get from ptes to pages, so that we don't have to keep the
> area->pages array allocated for the duration of the pin?
We could do vmalloc_to_page, but that is fairly expensive (not as bad
as reading from the page cache..). Are you really worried about the
allocation?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] x86/xen: open code alloc_vm_area in arch_gnttab_valloc
On 9/22/20 10:58 AM, Christoph Hellwig wrote:
> On Mon, Sep 21, 2020 at 04:44:10PM -0400, boris.ostrov...@oracle.com wrote:
>> This will end up incrementing area->ptes pointer. So perhaps something like
>>
>>
>> pte_t **ptes = area->ptes;
>>
>> if (apply_to_page_range(_mm, (unsigned long)area->area->addr,
>> PAGE_SIZE * nr_frames, gnttab_apply, )) {
>>
>> ...
> Yeah. What do you think of this version?
Oh yes, this is way better. This now can actually be read without trying to
mentally unwind triple pointers. (You probably want to initialize idx to zero
before calling apply_to_page_range(), I am not sure it's guaranteed to be zero).
> I think it is a little
> cleaner and matches what xenbus does. At this point it probably should
> be split into a Xen and a alloc_vm_area removal patch, though.
Right.
-boris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] x86/xen: open code alloc_vm_area in arch_gnttab_valloc
On 9/22/20 11:27 AM, Christoph Hellwig wrote:
> On Tue, Sep 22, 2020 at 11:24:20AM -0400, boris.ostrov...@oracle.com wrote:
>> On 9/22/20 10:58 AM, Christoph Hellwig wrote:
>>> On Mon, Sep 21, 2020 at 04:44:10PM -0400, boris.ostrov...@oracle.com wrote:
This will end up incrementing area->ptes pointer. So perhaps something like
pte_t **ptes = area->ptes;
if (apply_to_page_range(_mm, (unsigned long)area->area->addr,
PAGE_SIZE * nr_frames, gnttab_apply, )) {
...
>>> Yeah. What do you think of this version?
>>
>> Oh yes, this is way better. This now can actually be read without trying to
>> mentally unwind triple pointers. (You probably want to initialize idx to
>> zero before calling apply_to_page_range(), I am not sure it's guaranteed to
>> be zero).
> Both instances are static variables, thus in .bss and initialized.
> So unless you insist I don't think we need a manual one.
Yes, you are right. (I thought perhaps this code could be called more than once
but no, it can't).
-boris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: use vmap in shmem_pin_map
On 22/09/2020 15:31, Christoph Hellwig wrote:
On Tue, Sep 22, 2020 at 09:23:59AM +0100, Tvrtko Ursulin wrote:
If I understood this sub-thread correctly, iterating and freeing the pages
via the vmapped ptes, so no need for a
shmem_read_mapping_page_gfp loop in shmem_unpin_map looks plausible to me.
I did not get the reference to kernel/dma/remap.c though,
What I mean is the code in dma_common_find_pages, which returns the
page array for freeing.
Got it.
and also not sure
how to do the error unwind path in shmem_pin_map at which point the
allocated vm area hasn't been fully populated yet. Hand-roll the loop
walking vm area struct in there?
Yes. What I originally did (re-created as I didn't save it) would be
something like this:
---
From 5605e77cda246df6dd7ded99ec22cb3f341ef5d5 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date: Wed, 16 Sep 2020 13:54:04 +0200
Subject: drm/i915: use vmap in shmem_pin_map
shmem_pin_map somewhat awkwardly reimplements vmap using
alloc_vm_area and manual pte setup. The only practical difference
is that alloc_vm_area prefeaults the vmalloc area PTEs, which doesn't
seem to be required here (and could be added to vmap using a flag
if actually required).
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gt/shmem_utils.c | 81 +--
1 file changed, 27 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c
b/drivers/gpu/drm/i915/gt/shmem_utils.c
index 43c7acbdc79dea..7ec6ba4c1065b2 100644
--- a/drivers/gpu/drm/i915/gt/shmem_utils.c
+++ b/drivers/gpu/drm/i915/gt/shmem_utils.c
@@ -49,80 +49,53 @@ struct file *shmem_create_from_object(struct
drm_i915_gem_object *obj)
return file;
}
-static size_t shmem_npte(struct file *file)
+static size_t shmem_npages(struct file *file)
{
return file->f_mapping->host->i_size >> PAGE_SHIFT;
}
-static void __shmem_unpin_map(struct file *file, void *ptr, size_t n_pte)
-{
- unsigned long pfn;
-
- vunmap(ptr);
-
- for (pfn = 0; pfn < n_pte; pfn++) {
- struct page *page;
-
- page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
- GFP_KERNEL);
- if (!WARN_ON(IS_ERR(page))) {
- put_page(page);
- put_page(page);
- }
- }
-}
-
void *shmem_pin_map(struct file *file)
{
- const size_t n_pte = shmem_npte(file);
- pte_t *stack[32], **ptes, **mem;
Chris can comment how much he'd miss the 32 page stack shortcut.
- struct vm_struct *area;
- unsigned long pfn;
-
- mem = stack;
- if (n_pte > ARRAY_SIZE(stack)) {
- mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
- if (!mem)
- return NULL;
- }
+ size_t n_pages = shmem_npages(file), i;
+ struct page **pages;
+ void *vaddr;
- area = alloc_vm_area(n_pte << PAGE_SHIFT, mem);
- if (!area) {
- if (mem != stack)
- kvfree(mem);
+ pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
+ if (!pages)
return NULL;
- }
-
- ptes = mem;
- for (pfn = 0; pfn < n_pte; pfn++) {
- struct page *page;
- page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
- GFP_KERNEL);
- if (IS_ERR(page))
+ for (i = 0; i < n_pages; i++) {
+ pages[i] = shmem_read_mapping_page_gfp(file->f_mapping, i,
+ GFP_KERNEL);
+ if (IS_ERR(pages[i]))
goto err_page;
-
- **ptes++ = mk_pte(page, PAGE_KERNEL);
}
- if (mem != stack)
- kvfree(mem);
-
+ vaddr = vmap(pages, n_pages, 0, PAGE_KERNEL);
+ if (!vaddr)
+ goto err_page;
mapping_set_unevictable(file->f_mapping);
- return area->addr;
-
+ return vaddr;
Is there something in vmap() preventing us from freeing the pages array
here? I can't spot anything that is holding on to the pointer. Or it was
just a sketch before you realized we could walk the vm_area?
Also, I may be totally misunderstanding something, but I think you need
to assign area->pages manually so shmem_unpin_map can access it below.
err_page:
- if (mem != stack)
- kvfree(mem);
-
- __shmem_unpin_map(file, area->addr, pfn);
+ while (--i >= 0)
+ put_page(pages[i]);
+ kvfree(pages);
return NULL;
}
void shmem_unpin_map(struct file *file, void *ptr)
{
+ struct vm_struct *area = find_vm_area(ptr);
+ size_t i = shmem_npages(file);
+
+ if (WARN_ON_ONCE(!area || !area->pages))
+ return;
+
mapping_clear_unevictable(file->f_mapping);
- __shmem_unpin_map(file, ptr,
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Tue, Sep 22, 2020 at 4:14 PM Daniel Stone wrote: > > On Tue, 22 Sep 2020 at 15:04, Daniel Vetter wrote: > > On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad > > wrote: > > > Gentle ping. I've tried out Linus's master tree and, and like Pekka, > > > I've noticed this isn't integrated/added. > > > > Defacto the uapi we have now is that userspace needs to ignore "spurious" > > EBUSY. > > This really, really, really, bites. > > I think we need a guarantee that this never happens if ALLOW_MODESET > is always used in blocking mode, plus in future a cap we can use to > detect that we won't be getting spurious EBUSY events. > > I really don't want to ever paper over this, because it's one of the > clearest indications that userspace has its timing/signalling wrong. Ok so the hang-up last time around iirc was that I broke igt by making a few things more synchronous. Let's hope I'm not also breaking stuff with the WARN_ON ... New plan: - make this patch here only document existing behaviour and enforce it with the WARN_ON - new uapi would be behind a flag or something, with userspace and everything hanging off it. Thoughts? Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/6] Convert the intel iommu driver to the dma-iommu api
On 2020-09-21 6:24 p.m., Lu Baolu wrote: I'm trying to test this on an old Sandy Bridge, but found that I get spammed with warnings on boot. I've put a sample of a few of them below. They all seem to be related to ioat. I had the same issue with Tom's v2 but never saw this on his v1. >>> >>> Have you verified whether this could be reproduced with the lasted >>> upstream kernel (without this patch series)? >> >> Yes. > > I am sorry. Just want to make sure I understand you correctly. :-) When > you say "yes", do you mean you could reproduce this with pure upstream > kernel (5.9-rc6)? I mean I've verified the bug does *not* exist without this patch set. > >> Also, it's hitting a warning in the dma-iommu code which would not >> be hit without this patch set. > > Without this series, DMA APIs don't go through dma-iommu. Do you mind > posting the warning message? It was on my original email but here it is again: [ 44.057877] [ cut here ] [ 44.063167] WARNING: CPU: 4 PID: 84 at drivers/iommu/dma-iommu.c:496 __iommu_dma_unmap+0x115/0x130 [ 44.073351] Modules linked in: [ 44.076882] CPU: 4 PID: 84 Comm: kworker/4:1 Tainted: GW 5.9.0-rc4-6-g110da1e703a2 #216 [ 44.087935] Hardware name: Supermicro SYS-7047GR-TRF/X9DRG-QF, BIOS 3.0a 12/05/2013 [ 44.096650] Workqueue: events work_for_cpu_fn [ 44.101644] RIP: 0010:__iommu_dma_unmap+0x115/0x130 [ 44.107225] Code: 48 8b 0c 24 48 c7 44 24 10 00 00 00 00 48 c7 44 24 18 00 00 00 00 48 c7 44 24 20 00 00 00 00 48 c7 44 24 08 ff ff ff ff eb 8d <0f> 0b e9 74 ff ff ff e8 1f 36 66 00 66 66 2e 0f 1f 84 00 00 00 00 [ 44.128443] RSP: :c90002397c38 EFLAGS: 00010206 [ 44.134413] RAX: 0020 RBX: 0008 RCX: [ 44.144487] RDX: 0403 RSI: 82a7fb20 RDI: 888477804f30 [ 44.152613] RBP: fec0 R08: 000fec00 R09: 000fedff [ 44.160733] R10: 0002 R11: 0004 R12: 888270c39000 [ 44.168861] R13: 888472d85ee8 R14: 0008 R15: [ 44.176980] FS: () GS:88847980() knlGS: [ 44.186198] CS: 0010 DS: ES: CR0: 80050033 [ 44.192761] CR2: CR3: 02a20001 CR4: 000606e0 [ 44.200871] Call Trace: [ 44.203716] ? lockdep_hardirqs_on_prepare+0xad/0x180 [ 44.209509] iommu_dma_free+0x18/0x30 [ 44.213734] ioat_free_chan_resources+0x19e/0x300 [ 44.219133] ioat_dma_self_test+0x2a0/0x3d0 [ 44.223964] ioat_pci_probe+0x60e/0x903 [ 44.228387] local_pci_probe+0x42/0x80 [ 44.232721] work_for_cpu_fn+0x16/0x20 [ 44.237037] process_one_work+0x292/0x630 [ 44.241644] ? __schedule+0x344/0x970 [ 44.245868] worker_thread+0x227/0x3e0 [ 44.250185] ? process_one_work+0x630/0x630 [ 44.254989] kthread+0x136/0x150 [ 44.258718] ? kthread_use_mm+0x100/0x100 [ 44.263334] ret_from_fork+0x22/0x30 [ 44.267474] irq event stamp: 1881262 [ 44.271602] hardirqs last enabled at (1881272): [] console_unlock+0x435/0x570 [ 44.281593] hardirqs last disabled at (1881281): [] console_unlock+0x42b/0x570 [ 44.291588] softirqs last enabled at (1747140): [] ioat_cleanup+0x65/0x470 [ 44.301285] softirqs last disabled at (1747144): [] ioat_free_chan_resources+0x6a/0x300 [ 44.312153] ---[ end trace ed0f88fd959a5a39 ]--- ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Tweak initial dpcd backlight.enabled value
On Tue, 2020-09-22 at 09:39 -0400, Sean Paul wrote:
> On Mon, Sep 21, 2020 at 6:35 PM Lyude Paul wrote:
> > So if I understand this correctly, it sounds like that some Pixelbooks
> > boot up
> > with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB set to a non-zero value, without the
> > panel actually having DPCD backlight controls enabled?
>
> It boots with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB == 0, which used to set
> backlight.enabled = false. By changing backlight.level = max,
> backlight.enabled is now set to true. This results in losing backlight
> control on boot (since the enable routine is no longer invoked).
>
Ahhh ok, I'm fine with that - review still stands :)
> Sean
>
> > If I'm understanding that correctly, then this patch looks good to me:
> >
> > Reviewed-by: Lyude Paul
> >
> > On Thu, 2020-09-17 at 20:28 -0400, Sean Paul wrote:
> > > From: Sean Paul
> > >
> > > In commit 79946723092b ("drm/i915: Assume 100% brightness when not in
> > > DPCD control mode"), we fixed the brightness level when DPCD control was
> > > not active to max brightness. This is as good as we can guess since most
> > > backlights go on full when uncontrolled.
> > >
> > > However in doing so we changed the semantics of the initial
> > > 'backlight.enabled' value. At least on Pixelbooks, they were relying
> > > on the brightness level in DP_EDP_BACKLIGHT_BRIGHTNESS_MSB to be 0 on
> > > boot such that enabled would be false. This causes the device to be
> > > enabled when the brightness is set. Without this, brightness control
> > > doesn't work. So by changing brightness to max, we also flipped enabled
> > > to be true on boot.
> > >
> > > To fix this, make enabled a function of brightness and backlight control
> > > mechanism.
> > >
> > > Fixes: 79946723092b ("drm/i915: Assume 100% brightness when not in DPCD
> > > control mode")
> > > Cc: Lyude Paul
> > > Cc: Jani Nikula
> > > Cc: Juha-Pekka Heikkila
> > > Cc: "Ville Syrjälä"
> > > Cc: Rodrigo Vivi
> > > Cc: Kevin Chowski >
> > > Signed-off-by: Sean Paul
> > > ---
> > > .../drm/i915/display/intel_dp_aux_backlight.c | 31 ---
> > > 1 file changed, 20 insertions(+), 11 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 acbd7eb66cbe..036f504ac7db 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > @@ -52,17 +52,11 @@ static void set_aux_backlight_enable(struct intel_dp
> > > *intel_dp, bool enable)
> > > }
> > > }
> > >
> > > -/*
> > > - * Read the current backlight value from DPCD register(s) based
> > > - * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
> > > - */
> > > -static u32 intel_dp_aux_get_backlight(struct intel_connector
> > > *connector)
> > > +static bool intel_dp_aux_backlight_dpcd_mode(struct intel_connector
> > > *connector)
> > > {
> > > struct intel_dp *intel_dp = intel_attached_dp(connector);
> > > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > - u8 read_val[2] = { 0x0 };
> > > u8 mode_reg;
> > > - u16 level = 0;
> > >
> > > if (drm_dp_dpcd_readb(_dp->aux,
> > > DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
> > > @@ -70,15 +64,29 @@ static u32 intel_dp_aux_get_backlight(struct
> > > intel_connector *connector)
> > > drm_dbg_kms(>drm,
> > > "Failed to read the DPCD register 0x%x\n",
> > > DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
> > > - return 0;
> > > + return false;
> > > }
> > >
> > > + return (mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) ==
> > > +DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> > > +}
> > > +
> > > +/*
> > > + * Read the current backlight value from DPCD register(s) based
> > > + * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
> > > + */
> > > +static u32 intel_dp_aux_get_backlight(struct intel_connector
> > > *connector)
> > > +{
> > > + struct intel_dp *intel_dp = intel_attached_dp(connector);
> > > + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > + u8 read_val[2] = { 0x0 };
> > > + u16 level = 0;
> > > +
> > > /*
> > >* If we're not in DPCD control mode yet, the programmed
> > > brightness
> > >* value is meaningless and we should assume max brightness
> > >*/
> > > - if ((mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) !=
> > > - DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD)
> > > + if (!intel_dp_aux_backlight_dpcd_mode(connector))
> > > return connector->panel.backlight.max;
> > >
> > > if (drm_dp_dpcd_read(_dp->aux,
> > > DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
> > > @@ -319,7 +327,8 @@ static int intel_dp_aux_setup_backlight(struct
> > > intel_connector *connector,
> > >
> > > panel->backlight.min = 0;
> > >
Re: [Intel-gfx] [PATCH 3/7] drm/i915: Simplify the link training functions
On Tue, Sep 22, 2020 at 04:27:05PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 22, 2020 at 03:51:02PM +0300, Imre Deak wrote:
> > Split the prepare, link training, fallback-handling steps into their own
> > functions for clarity and as a preparation for the upcoming LTTPR changes.
> >
> > While at it also add some documentation to exported functions.
> >
> > Signed-off-by: Imre Deak
> > ---
> > .../drm/i915/display/intel_dp_link_training.c | 80 ++-
> > 1 file changed, 62 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > index 6d13d00db5e6..0c3809891bd2 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > @@ -162,14 +162,13 @@ static bool intel_dp_link_max_vswing_reached(struct
> > intel_dp *intel_dp)
> > return true;
> > }
> >
> > -/* Enable corresponding port and start training pattern 1 */
> > -static bool
> > -intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > +/*
> > + * Prepare link training by configuring the link parameters and enabling
> > the
> > + * corresponding port.
> > + */
> > +static void intel_dp_prepare_link_train(struct intel_dp *intel_dp)
> > {
> > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > - u8 voltage;
> > - int voltage_tries, cr_tries, max_cr_tries;
> > - bool max_vswing_reached = false;
> > u8 link_config[2];
> > u8 link_bw, rate_select;
> >
> > @@ -203,6 +202,16 @@ intel_dp_link_training_clock_recovery(struct intel_dp
> > *intel_dp)
> > drm_dp_dpcd_write(_dp->aux, DP_DOWNSPREAD_CTRL, link_config, 2);
> >
> > intel_dp->DP |= DP_PORT_EN;
>
> I guess we no longer actually enable the port here? The comment ^ still says
> we do.
>
> Hmm. Seems we do enable the port on ddi platforms, but not on older
> platforms. I guess the docs could still use a tweak to reflect
> reality a bit better.
Yes, missed the old platform part, will update the comment.
>
> > +}
> > +
> > +/* Perform the link training clock recovery phase using training pattern
> > 1. */
> > +static bool
> > +intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > +{
> > + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > + u8 voltage;
> > + int voltage_tries, cr_tries, max_cr_tries;
> > + bool max_vswing_reached = false;
> >
> > /* clock recovery */
> > if (!intel_dp_reset_link_train(intel_dp,
> > @@ -325,6 +334,10 @@ static u32 intel_dp_training_pattern(struct intel_dp
> > *intel_dp)
> > return DP_TRAINING_PATTERN_2;
> > }
> >
> > +/*
> > + * Perform the link training channel equalization phase using one of
> > training
> > + * pattern 2, 3 or 4 depending on the the source and sink capabilities.
> > + */
> > static bool
> > intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> > {
> > @@ -395,6 +408,15 @@ intel_dp_link_training_channel_equalization(struct
> > intel_dp *intel_dp)
> >
> > }
> >
> > +/**
> > + * intel_dp_stop_link_train - stop link training
> > + * @intel_dp: DP struct
> > + *
> > + * Stop the link training of the @intel_dp port, programming the port to
> > + * output an idle pattern
>
> I don't think we use the idle pattern on all platforms.
Yes, just DDI, this also needs a doc update.
> BTW intel_dp_set_idle_link_train() looks pretty pointless. Could just
> inline it into its only caller, or at least move it into
> intel_dp_link_training.c.
Ok, can unexport/inline it. Btw, this part made me wonder what's the
exact reason for keeping the idle pattern output and corresponding DPCD
programming separate, that is why can't we disable the training pattern
in DPCD after intel_dp_set_idle_link_train()? That would make things
more uniform on all platforms.
>
> Reviewed-by: Ville Syrjälä
>
> > on the link and disabling the training pattern in
> > + * the sink's DPCD.
> > + * This function must be called after intel_dp_start_link_train().
> > + */
> > void intel_dp_stop_link_train(struct intel_dp *intel_dp)
> > {
> > intel_dp->link_trained = true;
> > @@ -403,30 +425,37 @@ void intel_dp_stop_link_train(struct intel_dp
> > *intel_dp)
> > DP_TRAINING_PATTERN_DISABLE);
> > }
> >
> > -void
> > -intel_dp_start_link_train(struct intel_dp *intel_dp)
> > +static bool
> > +intel_dp_link_train(struct intel_dp *intel_dp)
> > {
> > struct intel_connector *intel_connector = intel_dp->attached_connector;
> > + bool ret = false;
> > +
> > + intel_dp_prepare_link_train(intel_dp);
> >
> > if (!intel_dp_link_training_clock_recovery(intel_dp))
> > - goto failure_handling;
> > + goto out;
> > +
> > if (!intel_dp_link_training_channel_equalization(intel_dp))
> > - goto failure_handling;
> > + goto out;
> >
> > - drm_dbg_kms(_to_i915(intel_dp)->drm,
> > -
Re: [Intel-gfx] [PATCH 6/6] x86/xen: open code alloc_vm_area in arch_gnttab_valloc
On Tue, Sep 22, 2020 at 11:24:20AM -0400, boris.ostrov...@oracle.com wrote:
>
> On 9/22/20 10:58 AM, Christoph Hellwig wrote:
> > On Mon, Sep 21, 2020 at 04:44:10PM -0400, boris.ostrov...@oracle.com wrote:
> >> This will end up incrementing area->ptes pointer. So perhaps something like
> >>
> >>
> >> pte_t **ptes = area->ptes;
> >>
> >> if (apply_to_page_range(_mm, (unsigned long)area->area->addr,
> >> PAGE_SIZE * nr_frames, gnttab_apply, )) {
> >>
> >> ...
> > Yeah. What do you think of this version?
>
>
> Oh yes, this is way better. This now can actually be read without trying to
> mentally unwind triple pointers. (You probably want to initialize idx to zero
> before calling apply_to_page_range(), I am not sure it's guaranteed to be
> zero).
Both instances are static variables, thus in .bss and initialized.
So unless you insist I don't think we need a manual one.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add support for LTTPR non-transparent link training mode
== Series Details == Series: drm/i915: Add support for LTTPR non-transparent link training mode URL : https://patchwork.freedesktop.org/series/81968/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9033_full -> Patchwork_18544_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18544_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18544_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_18544_full: ### IGT changes ### Possible regressions * igt@kms_flip@2x-nonexisting-fb-interruptible@ac-vga1-hdmi-a1: - shard-hsw: [PASS][1] -> [INCOMPLETE][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9033/shard-hsw4/igt@kms_flip@2x-nonexisting-fb-interrupti...@ac-vga1-hdmi-a1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18544/shard-hsw7/igt@kms_flip@2x-nonexisting-fb-interrupti...@ac-vga1-hdmi-a1.html Known issues Here are the changes found in Patchwork_18544_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-mixed-process@blt: - shard-skl: [PASS][3] -> [FAIL][4] ([i915#2374]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9033/shard-skl4/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18544/shard-skl1/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html * igt@gem_eio@kms: - shard-skl: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +7 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9033/shard-skl2/igt@gem_...@kms.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18544/shard-skl2/igt@gem_...@kms.html * igt@gem_exec_whisper@basic-queues-priority: - shard-glk: [PASS][7] -> [DMESG-WARN][8] ([i915#118] / [i915#95]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9033/shard-glk5/igt@gem_exec_whis...@basic-queues-priority.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18544/shard-glk7/igt@gem_exec_whis...@basic-queues-priority.html * igt@gen9_exec_parse@allowed-all: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#1436] / [i915#716]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9033/shard-kbl7/igt@gen9_exec_pa...@allowed-all.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18544/shard-kbl7/igt@gen9_exec_pa...@allowed-all.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1436] / [i915#716]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9033/shard-skl1/igt@gen9_exec_pa...@allowed-single.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18544/shard-skl5/igt@gen9_exec_pa...@allowed-single.html * igt@i915_pm_dc@dc5-dpms: - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([i915#198]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9033/shard-skl4/igt@i915_pm...@dc5-dpms.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18544/shard-skl1/igt@i915_pm...@dc5-dpms.html * igt@i915_pm_rc6_residency@rc6-fence: - shard-hsw: [PASS][15] -> [WARN][16] ([i915#1519]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9033/shard-hsw7/igt@i915_pm_rc6_reside...@rc6-fence.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18544/shard-hsw6/igt@i915_pm_rc6_reside...@rc6-fence.html * igt@kms_cursor_legacy@flip-vs-cursor-legacy: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#2346]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9033/shard-skl3/igt@kms_cursor_leg...@flip-vs-cursor-legacy.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18544/shard-skl3/igt@kms_cursor_leg...@flip-vs-cursor-legacy.html * igt@kms_draw_crc@draw-method-rgb565-pwrite-untiled: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#177] / [i915#52] / [i915#54]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9033/shard-skl7/igt@kms_draw_...@draw-method-rgb565-pwrite-untiled.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18544/shard-skl7/igt@kms_draw_...@draw-method-rgb565-pwrite-untiled.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-hdmi-a1: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#2122]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9033/shard-glk1/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-hdmi-a1.html [22]:
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/6] zsmalloc: switch from alloc_vm_area to get_vm_area (rev5)
== Series Details == Series: series starting with [1/6] zsmalloc: switch from alloc_vm_area to get_vm_area (rev5) URL : https://patchwork.freedesktop.org/series/81855/ State : failure == Summary == Applying: zsmalloc: switch from alloc_vm_area to get_vm_area error: sha1 information is lacking or useless (mm/memory.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 zsmalloc: switch from alloc_vm_area to get_vm_area When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] x86/xen: open code alloc_vm_area in arch_gnttab_valloc
On Mon, Sep 21, 2020 at 04:44:10PM -0400, boris.ostrov...@oracle.com wrote:
> This will end up incrementing area->ptes pointer. So perhaps something like
>
>
> pte_t **ptes = area->ptes;
>
> if (apply_to_page_range(_mm, (unsigned long)area->area->addr,
> PAGE_SIZE * nr_frames, gnttab_apply, )) {
>
> ...
Yeah. What do you think of this version? I think it is a little
cleaner and matches what xenbus does. At this point it probably should
be split into a Xen and a alloc_vm_area removal patch, though.
---
>From 74d6b797e049f72b5e9f63f14da6321c4209a792 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date: Wed, 16 Sep 2020 16:09:42 +0200
Subject: x86/xen: open code alloc_vm_area in arch_gnttab_valloc
Open code alloc_vm_area in the last remaining caller.
Signed-off-by: Christoph Hellwig
---
arch/x86/xen/grant-table.c | 27 +++--
include/linux/vmalloc.h| 5 +---
mm/nommu.c | 7 --
mm/vmalloc.c | 48 --
4 files changed, 21 insertions(+), 66 deletions(-)
diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index 4988e19598c8a5..1e681bf62561a0 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -25,6 +25,7 @@
static struct gnttab_vm_area {
struct vm_struct *area;
pte_t **ptes;
+ int idx;
} gnttab_shared_vm_area, gnttab_status_vm_area;
int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
@@ -90,19 +91,31 @@ void arch_gnttab_unmap(void *shared, unsigned long
nr_gframes)
}
}
+static int gnttab_apply(pte_t *pte, unsigned long addr, void *data)
+{
+ struct gnttab_vm_area *area = data;
+
+ area->ptes[area->idx++] = pte;
+ return 0;
+}
+
static int arch_gnttab_valloc(struct gnttab_vm_area *area, unsigned nr_frames)
{
area->ptes = kmalloc_array(nr_frames, sizeof(*area->ptes), GFP_KERNEL);
if (area->ptes == NULL)
return -ENOMEM;
-
- area->area = alloc_vm_area(PAGE_SIZE * nr_frames, area->ptes);
- if (area->area == NULL) {
- kfree(area->ptes);
- return -ENOMEM;
- }
-
+ area->area = get_vm_area(PAGE_SIZE * nr_frames, VM_IOREMAP);
+ if (!area->area)
+ goto out_free_ptes;
+ if (apply_to_page_range(_mm, (unsigned long)area->area->addr,
+ PAGE_SIZE * nr_frames, gnttab_apply, area))
+ goto out_free_vm_area;
return 0;
+out_free_vm_area:
+ free_vm_area(area->area);
+out_free_ptes:
+ kfree(area->ptes);
+ return -ENOMEM;
}
static void arch_gnttab_vfree(struct gnttab_vm_area *area)
diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index 8ecd92a947ee0c..a1a4e2f8163504 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -168,6 +168,7 @@ extern struct vm_struct *__get_vm_area_caller(unsigned long
size,
unsigned long flags,
unsigned long start, unsigned long end,
const void *caller);
+void free_vm_area(struct vm_struct *area);
extern struct vm_struct *remove_vm_area(const void *addr);
extern struct vm_struct *find_vm_area(const void *addr);
@@ -203,10 +204,6 @@ static inline void set_vm_flush_reset_perms(void *addr)
}
#endif
-/* Allocate/destroy a 'vmalloc' VM area. */
-extern struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes);
-extern void free_vm_area(struct vm_struct *area);
-
/* for /dev/kmem */
extern long vread(char *buf, char *addr, unsigned long count);
extern long vwrite(char *buf, char *addr, unsigned long count);
diff --git a/mm/nommu.c b/mm/nommu.c
index 75a327149af127..9272f30e4c4726 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -354,13 +354,6 @@ void vm_unmap_aliases(void)
}
EXPORT_SYMBOL_GPL(vm_unmap_aliases);
-struct vm_struct *alloc_vm_area(size_t size, pte_t **ptes)
-{
- BUG();
- return NULL;
-}
-EXPORT_SYMBOL_GPL(alloc_vm_area);
-
void free_vm_area(struct vm_struct *area)
{
BUG();
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 59f2afcf26c312..9f29147deca580 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -3077,54 +3077,6 @@ int remap_vmalloc_range(struct vm_area_struct *vma, void
*addr,
}
EXPORT_SYMBOL(remap_vmalloc_range);
-static int f(pte_t *pte, unsigned long addr, void *data)
-{
- pte_t ***p = data;
-
- if (p) {
- *(*p) = pte;
- (*p)++;
- }
- return 0;
-}
-
-/**
- * alloc_vm_area - allocate a range of kernel address space
- * @size: size of the area
- * @ptes: returns the PTEs for the address space
- *
- * Returns:NULL on failure, vm_struct on success
- *
- * This function reserves a range of kernel address space, and
- * allocates pagetables to map that range. No actual mappings
- * are created.
- *
- * If @ptes is
Re: [Intel-gfx] [PATCH 3/6] drm/i915: use vmap in shmem_pin_map
On Tue, Sep 22, 2020 at 04:39:06PM +0200, Christoph Hellwig wrote: > On Tue, Sep 22, 2020 at 12:21:44PM +0100, Matthew Wilcox wrote: > > Actually, vfree() will work today; I cc'd you on a documentation update > > to make it clear that this is permitted. > > vfree calls __free_pages, the i915 and a lot of other code calls > put_page. They are mostly the same, but not quite and everytime I > look into that mess I'm more confused than before. > > Can someone in the know write sensible documentation on when to use > __free_page(s) vs put_page? I started on that, and then I found a bug that's been lurking for 12 years, so that delayed the documentation somewhat. The short answer is that __free_pages() lets you free non-compound high-order pages while put_page() can only free order-0 and compound pages. I would really like to overhaul our memory allocation APIs: current new __get_free_page(s) alloc_page(s) free_page(s)free_page(s) alloc_page(s) get_free_page(s) __free_pagesput_page_order Then put_page() and put_page_order() are more obviously friends. But I cannot imagine a world in which Linus says yes to that upheaval. He's previous expressed dislike of the get_free_page() family of APIs, and thinks all those callers should just use kmalloc(). Maybe we can make that transition happen, now that kmalloc() aligns larger allocations. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/7] drm/i915: Move intel_dp_get_link_status to intel_dp_link_training.c
On Tue, Sep 22, 2020 at 04:14:24PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 22, 2020 at 03:51:01PM +0300, Imre Deak wrote:
> > The link status is used to communicate the parameters of the link
> > training with the DPRX and determine if the link training is successful
> > or a retraining is needed. Accordingly move the function to read the
> > link status to intel_dp_link_training.c
> >
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 11 ---
> > drivers/gpu/drm/i915/display/intel_dp.h | 2 --
> > .../drm/i915/display/intel_dp_link_training.c| 16
> > .../drm/i915/display/intel_dp_link_training.h| 3 +++
> > 4 files changed, 19 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 2a4a9c0e7427..ee93a00a4d5e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -4126,17 +4126,6 @@ static void chv_dp_post_pll_disable(struct
> > intel_atomic_state *state,
> > chv_phy_post_pll_disable(encoder, old_crtc_state);
> > }
> >
> > -/*
> > - * Fetch AUX CH registers 0x202 - 0x207 which contain
> > - * link status information
> > - */
> > -bool
> > -intel_dp_get_link_status(struct intel_dp *intel_dp, u8
> > link_status[DP_LINK_STATUS_SIZE])
> > -{
> > - return drm_dp_dpcd_read(_dp->aux, DP_LANE0_1_STATUS, link_status,
> > - DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
> > -}
> > -
> > static u8 intel_dp_voltage_max_2(struct intel_dp *intel_dp)
> > {
> > return DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> > b/drivers/gpu/drm/i915/display/intel_dp.h
> > index 08a1c0aa8b94..34ae7988a554 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.h
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> > @@ -100,8 +100,6 @@ void intel_dp_compute_rate(struct intel_dp *intel_dp,
> > int port_clock,
> >u8 *link_bw, u8 *rate_select);
> > bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp);
> > bool intel_dp_source_supports_hbr3(struct intel_dp *intel_dp);
> > -bool
> > -intel_dp_get_link_status(struct intel_dp *intel_dp, u8 *link_status);
> >
> > bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp);
> > int intel_dp_link_required(int pixel_clock, int bpp);
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > index f8b53c5b5777..6d13d00db5e6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > @@ -34,6 +34,22 @@ intel_dp_dump_link_status(const u8
> > link_status[DP_LINK_STATUS_SIZE])
> > link_status[3], link_status[4], link_status[5]);
> > }
> >
> > +/**
> > + * intel_dp_get_link_status - get the link status information for the DPRX
> > + * @intel_dp: DP struct
> > + * @link_status: buffer to return the status in
> > + *
> > + * Fetch the AUX DPCD registers for the DPRX link status.
> > + *
> > + * Returns true if the information was read successfully, false otherwise.
> > + */
> > +bool
> > +intel_dp_get_link_status(struct intel_dp *intel_dp, u8
> > link_status[DP_LINK_STATUS_SIZE])
> > +{
> > + return drm_dp_dpcd_read(_dp->aux, DP_LANE0_1_STATUS, link_status,
> > + DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
> > +}
> > +
> > static u8 dp_voltage_max(u8 preemph)
> > {
> > switch (preemph & DP_TRAIN_PRE_EMPHASIS_MASK) {
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> > b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> > index 01f1dabbb060..47c97f4a0d57 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> > @@ -10,6 +10,9 @@
> >
> > struct intel_dp;
> >
> > +bool intel_dp_get_link_status(struct intel_dp *intel_dp,
> > + u8 link_status[DP_LINK_STATUS_SIZE]);
> > +
>
> Do we still need it outside? Hmm, I guess we do.
Yes, for PHY auto-testing, but I think that should rather depend on the
regular link training sequence as discussed elsewhere.
>
> Oh well
> Reviewed-by: Ville Syrjälä
>
> > void intel_dp_get_adjust_train(struct intel_dp *intel_dp,
> >const u8 link_status[DP_LINK_STATUS_SIZE]);
> > void intel_dp_start_link_train(struct intel_dp *intel_dp);
> > --
> > 2.17.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: simplify the return expression of i915_driver_release()
== Series Details ==
Series: drm/i915: simplify the return expression of i915_driver_release()
URL : https://patchwork.freedesktop.org/series/81977/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9034 -> Patchwork_18546
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18546/index.html
Known issues
Here are the changes found in Patchwork_18546 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) +1 similar
issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18546/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [PASS][3] -> [DMESG-WARN][4] ([i915#2203])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18546/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
Possible fixes
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18546/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@vgem_basic@unload:
- fi-skl-guc: [DMESG-WARN][7] ([i915#2203]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/fi-skl-guc/igt@vgem_ba...@unload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18546/fi-skl-guc/igt@vgem_ba...@unload.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [DMESG-WARN][9] ([i915#2203]) -> [SKIP][10]
([fdo#109271])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/fi-kbl-guc/igt@i915_pm_...@module-reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18546/fi-kbl-guc/igt@i915_pm_...@module-reload.html
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][12] ([i915#62] / [i915#92]) +4 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18546/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) ->
[DMESG-WARN][14] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18546/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (41 -> 36)
--
Additional (1): fi-cml-u2
Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-icl-u2
fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_9034 -> Patchwork_18546
CI-20190529: 20190529
CI_DRM_9034: 6348adbb00184ce4f166e3260583f09aa381c7e3 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5787: 0ec962017c8131de14e0cb038f7f76b1f17ed637 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18546: dbd52e11de372c76743925cc316394653cf59053 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
dbd52e11de37 drm/i915: simplify the return expression of i915_driver_release()
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18546/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/6] zsmalloc: switch from alloc_vm_area to get_vm_area (rev4)
== Series Details == Series: series starting with [1/6] zsmalloc: switch from alloc_vm_area to get_vm_area (rev4) URL : https://patchwork.freedesktop.org/series/81855/ State : failure == Summary == Applying: zsmalloc: switch from alloc_vm_area to get_vm_area error: sha1 information is lacking or useless (mm/memory.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 zsmalloc: switch from alloc_vm_area to get_vm_area When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Fix DP link training pattern mask
On Tue, Sep 22, 2020 at 04:13:23PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 22, 2020 at 03:51:00PM +0300, Imre Deak wrote:
> > An LTTPR can be trained with training pattern 4 even if the DPCD
> > revision is < 1.4, but drm_dp_training_pattern_mask() would change
> > pattern 4 to pattern 3 on those DPCD revisions.
> >
> > Since intel_dp_training_pattern() makes already sure that the proper
> > training pattern is used, all that needs to be masked out is the
> > scrambling disable flag, which is or'd to the mask later based on the
> > training pattern.
> >
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 3 +--
> > drivers/gpu/drm/i915/display/intel_dp.c | 10 +-
> > drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 +-
> > 3 files changed, 7 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 4d06178cd76c..946a3b6f2d10 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -4158,13 +4158,12 @@ static void intel_ddi_set_link_train(struct
> > intel_dp *intel_dp,
> > u8 dp_train_pat)
> > {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > - u8 train_pat_mask = drm_dp_training_pattern_mask(intel_dp->dpcd);
> > u32 temp;
> >
> > temp = intel_de_read(dev_priv, intel_dp->regs.dp_tp_ctl);
> >
> > temp &= ~DP_TP_CTL_LINK_TRAIN_MASK;
> > - switch (dp_train_pat & train_pat_mask) {
> > + switch (dp_train_pat & ~DP_LINK_SCRAMBLING_DISABLE) {
>
> Maybe introduce a helper to do the masking for us?
Ok, will add intel_dp_training_pattern_symbol().
>
> Anyways
> Reviewed-by: Ville Syrjälä
>
> > case DP_TRAINING_PATTERN_DISABLE:
> > temp |= DP_TP_CTL_LINK_TRAIN_NORMAL;
> > break;
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index bf1e9cf1c0f3..2a4a9c0e7427 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -3778,7 +3778,7 @@ cpt_set_link_train(struct intel_dp *intel_dp,
> >
> > *DP &= ~DP_LINK_TRAIN_MASK_CPT;
> >
> > - switch (dp_train_pat & DP_TRAINING_PATTERN_MASK) {
> > + switch (dp_train_pat & ~DP_LINK_SCRAMBLING_DISABLE) {
> > case DP_TRAINING_PATTERN_DISABLE:
> > *DP |= DP_LINK_TRAIN_OFF_CPT;
> > break;
> > @@ -3808,7 +3808,7 @@ g4x_set_link_train(struct intel_dp *intel_dp,
> >
> > *DP &= ~DP_LINK_TRAIN_MASK;
> >
> > - switch (dp_train_pat & DP_TRAINING_PATTERN_MASK) {
> > + switch (dp_train_pat & ~DP_LINK_SCRAMBLING_DISABLE) {
> > case DP_TRAINING_PATTERN_DISABLE:
> > *DP |= DP_LINK_TRAIN_OFF;
> > break;
> > @@ -4498,12 +4498,12 @@ intel_dp_program_link_training_pattern(struct
> > intel_dp *intel_dp,
> >u8 dp_train_pat)
> > {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > - u8 train_pat_mask = drm_dp_training_pattern_mask(intel_dp->dpcd);
> >
> > - if (dp_train_pat & train_pat_mask)
> > + if ((dp_train_pat & ~DP_LINK_SCRAMBLING_DISABLE) !=
> > + DP_TRAINING_PATTERN_DISABLE)
> > drm_dbg_kms(_priv->drm,
> > "Using DP training pattern TPS%d\n",
> > - dp_train_pat & train_pat_mask);
> > + dp_train_pat & ~DP_LINK_SCRAMBLING_DISABLE);
> >
> > intel_dp->set_link_train(intel_dp, dp_train_pat);
> > }
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > index f2c8b56be9ea..f8b53c5b5777 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > @@ -96,7 +96,7 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
> > intel_dp_program_link_training_pattern(intel_dp, dp_train_pat);
> >
> > buf[0] = dp_train_pat;
> > - if ((dp_train_pat & DP_TRAINING_PATTERN_MASK) ==
> > + if ((dp_train_pat & ~DP_LINK_SCRAMBLING_DISABLE) ==
> > DP_TRAINING_PATTERN_DISABLE) {
> > /* don't write DP_TRAINING_LANEx_SET on disable */
> > len = 1;
> > --
> > 2.17.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: use vmap in shmem_pin_map
On Tue, Sep 22, 2020 at 12:21:44PM +0100, Matthew Wilcox wrote: > Actually, vfree() will work today; I cc'd you on a documentation update > to make it clear that this is permitted. vfree calls __free_pages, the i915 and a lot of other code calls put_page. They are mostly the same, but not quite and everytime I look into that mess I'm more confused than before. Can someone in the know write sensible documentation on when to use __free_page(s) vs put_page? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: use vmap in shmem_pin_map
On Tue, Sep 22, 2020 at 09:23:59AM +0100, Tvrtko Ursulin wrote:
> If I understood this sub-thread correctly, iterating and freeing the pages
> via the vmapped ptes, so no need for a
> shmem_read_mapping_page_gfp loop in shmem_unpin_map looks plausible to me.
>
> I did not get the reference to kernel/dma/remap.c though,
What I mean is the code in dma_common_find_pages, which returns the
page array for freeing.
>
> and also not sure
> how to do the error unwind path in shmem_pin_map at which point the
> allocated vm area hasn't been fully populated yet. Hand-roll the loop
> walking vm area struct in there?
Yes. What I originally did (re-created as I didn't save it) would be
something like this:
---
>From 5605e77cda246df6dd7ded99ec22cb3f341ef5d5 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date: Wed, 16 Sep 2020 13:54:04 +0200
Subject: drm/i915: use vmap in shmem_pin_map
shmem_pin_map somewhat awkwardly reimplements vmap using
alloc_vm_area and manual pte setup. The only practical difference
is that alloc_vm_area prefeaults the vmalloc area PTEs, which doesn't
seem to be required here (and could be added to vmap using a flag
if actually required).
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gt/shmem_utils.c | 81 +--
1 file changed, 27 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c
b/drivers/gpu/drm/i915/gt/shmem_utils.c
index 43c7acbdc79dea..7ec6ba4c1065b2 100644
--- a/drivers/gpu/drm/i915/gt/shmem_utils.c
+++ b/drivers/gpu/drm/i915/gt/shmem_utils.c
@@ -49,80 +49,53 @@ struct file *shmem_create_from_object(struct
drm_i915_gem_object *obj)
return file;
}
-static size_t shmem_npte(struct file *file)
+static size_t shmem_npages(struct file *file)
{
return file->f_mapping->host->i_size >> PAGE_SHIFT;
}
-static void __shmem_unpin_map(struct file *file, void *ptr, size_t n_pte)
-{
- unsigned long pfn;
-
- vunmap(ptr);
-
- for (pfn = 0; pfn < n_pte; pfn++) {
- struct page *page;
-
- page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
- GFP_KERNEL);
- if (!WARN_ON(IS_ERR(page))) {
- put_page(page);
- put_page(page);
- }
- }
-}
-
void *shmem_pin_map(struct file *file)
{
- const size_t n_pte = shmem_npte(file);
- pte_t *stack[32], **ptes, **mem;
- struct vm_struct *area;
- unsigned long pfn;
-
- mem = stack;
- if (n_pte > ARRAY_SIZE(stack)) {
- mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
- if (!mem)
- return NULL;
- }
+ size_t n_pages = shmem_npages(file), i;
+ struct page **pages;
+ void *vaddr;
- area = alloc_vm_area(n_pte << PAGE_SHIFT, mem);
- if (!area) {
- if (mem != stack)
- kvfree(mem);
+ pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
+ if (!pages)
return NULL;
- }
-
- ptes = mem;
- for (pfn = 0; pfn < n_pte; pfn++) {
- struct page *page;
- page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
- GFP_KERNEL);
- if (IS_ERR(page))
+ for (i = 0; i < n_pages; i++) {
+ pages[i] = shmem_read_mapping_page_gfp(file->f_mapping, i,
+ GFP_KERNEL);
+ if (IS_ERR(pages[i]))
goto err_page;
-
- **ptes++ = mk_pte(page, PAGE_KERNEL);
}
- if (mem != stack)
- kvfree(mem);
-
+ vaddr = vmap(pages, n_pages, 0, PAGE_KERNEL);
+ if (!vaddr)
+ goto err_page;
mapping_set_unevictable(file->f_mapping);
- return area->addr;
-
+ return vaddr;
err_page:
- if (mem != stack)
- kvfree(mem);
-
- __shmem_unpin_map(file, area->addr, pfn);
+ while (--i >= 0)
+ put_page(pages[i]);
+ kvfree(pages);
return NULL;
}
void shmem_unpin_map(struct file *file, void *ptr)
{
+ struct vm_struct *area = find_vm_area(ptr);
+ size_t i = shmem_npages(file);
+
+ if (WARN_ON_ONCE(!area || !area->pages))
+ return;
+
mapping_clear_unevictable(file->f_mapping);
- __shmem_unpin_map(file, ptr, shmem_npte(file));
+ for (i = 0; i < shmem_npages(file); i++)
+ put_page(area->pages[i]);
+ kvfree(area->pages);
+ vunmap(ptr);
}
static int __shmem_rw(struct file *file, loff_t off,
--
2.28.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 Add support for mipi dsi cmd mode (rev13)
== Series Details ==
Series: Add support for mipi dsi cmd mode (rev13)
URL : https://patchwork.freedesktop.org/series/69290/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9034 -> Patchwork_18545
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18545/index.html
Known issues
Here are the changes found in Patchwork_18545 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18545/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18545/fi-byt-j1900/igt@i915_pm_...@module-reload.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u: [PASS][5] -> [DMESG-WARN][6] ([i915#2203])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18545/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
Possible fixes
* igt@vgem_basic@unload:
- fi-kbl-x1275: [DMESG-WARN][7] ([i915#62] / [i915#92]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/fi-kbl-x1275/igt@vgem_ba...@unload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18545/fi-kbl-x1275/igt@vgem_ba...@unload.html
Warnings
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92]) ->
[DMESG-WARN][10] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18545/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][12] ([i915#62] / [i915#92]) +4 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9034/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18545/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (41 -> 37)
--
Additional (1): fi-cml-u2
Missing(5): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-byt-clapper
fi-bdw-samus
Build changes
-
* Linux: CI_DRM_9034 -> Patchwork_18545
CI-20190529: 20190529
CI_DRM_9034: 6348adbb00184ce4f166e3260583f09aa381c7e3 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5787: 0ec962017c8131de14e0cb038f7f76b1f17ed637 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18545: 8f61cd262902944cc8a261360bb1fdc2d84a5d57 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8f61cd262902 drm/i915/dsi: Enable software vblank counter
b1c8ba29cb59 drm/i915/dsi: Initiate fame request in cmd mode
3ea842d0592b drm/i915/dsi: Add TE handler for dsi cmd mode.
24b589446a6b i915/dsi: Configure TE interrupt for cmd mode
21f8331c75f9 drm/i915/dsi: Add details about TE in get_config
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18545/index.html
___
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, 22 Sep 2020 at 15:04, Daniel Vetter wrote: > On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote: > > Gentle ping. I've tried out Linus's master tree and, and like Pekka, > > I've noticed this isn't integrated/added. > > Defacto the uapi we have now is that userspace needs to ignore "spurious" > EBUSY. This really, really, really, bites. I think we need a guarantee that this never happens if ALLOW_MODESET is always used in blocking mode, plus in future a cap we can use to detect that we won't be getting spurious EBUSY events. I really don't want to ever paper over this, because it's one of the clearest indications that userspace has its timing/signalling wrong. Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH -next] drm/i915: simplify the return expression of i915_driver_release()
Simplify the return expression.
Signed-off-by: Qinglang Miao
---
drivers/gpu/drm/i915/i915_drv.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index acc32066c..a594bb4aa 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -985,13 +985,8 @@ static void i915_driver_release(struct drm_device *dev)
static int i915_driver_open(struct drm_device *dev, struct drm_file *file)
{
struct drm_i915_private *i915 = to_i915(dev);
- int ret;
- ret = i915_gem_open(i915, file);
- if (ret)
- return ret;
-
- return 0;
+ return i915_gem_open(i915, file);
}
/**
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] XDC 2020 feedback and comments
On Mon, 21 Sep 2020 10:03:32 +0200 Samuel Iglesias Gonsálvez wrote: > Hi all, > > Huge thanks again to the entire team from Intel, for their great work > organizing XDC 2020, our first virtual conference! > > As usual we're looking for feedback on both XDC itself, and the CFP > process and program selection. Both about what was great and should be > kept for next year's edition, and where there's room for improvement. > > The board does keep some notes, for those interested in what we have > already: > > - XDC notes for prospective organizers: > https://www.x.org/wiki/Events/RFP/ > > - CFP notes: https://www.x.org/wiki/Events/PapersCommittee/ > > If you want to send in your comments in private, please send them to > the X.org Foundation board: bo...@foundation.x.org > > Cheers, > > Sam Hi Sam, I'd like to make a note about using some more privacy-friendly streaming platform. When I tried to watch the streams, instead of showing the video, youtube presented me with a GDPR dialog. While it was glitched and unskippable for me, just the fact that Google made it non-optional shows their disregard for my privacy (and, IMO, the letter of law, which mandates opt-in). Unfortunately, I wasn't able to evaluate the dialog's contents due to the glitch, but online reports suggest they are similarly ignorant. All in all, I only access youtube via youtube-dl any more, and that doesn't support streaming. When attending Akademy 2 weeks ago, they had a setup based on BigBlueButton that worked well without that sort of issues. Cheers, Dorota ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] x86/xen: open code alloc_vm_area in arch_gnttab_valloc
On 9/18/20 12:37 PM, Christoph Hellwig wrote:
>
> +static int gnttab_apply(pte_t *pte, unsigned long addr, void *data)
> +{
> + pte_t ***p = data;
> +
> + **p = pte;
> + (*p)++;
> + return 0;
> +}
> +
> static int arch_gnttab_valloc(struct gnttab_vm_area *area, unsigned
> nr_frames)
> {
> area->ptes = kmalloc_array(nr_frames, sizeof(*area->ptes), GFP_KERNEL);
> if (area->ptes == NULL)
> return -ENOMEM;
> -
> - area->area = alloc_vm_area(PAGE_SIZE * nr_frames, area->ptes);
> - if (area->area == NULL) {
> - kfree(area->ptes);
> - return -ENOMEM;
> - }
> -
> + area->area = get_vm_area(PAGE_SIZE * nr_frames, VM_IOREMAP);
> + if (!area->area)
> + goto out_free_ptes;
> + if (apply_to_page_range(_mm, (unsigned long)area->area->addr,
> + PAGE_SIZE * nr_frames, gnttab_apply, >ptes))
This will end up incrementing area->ptes pointer. So perhaps something like
pte_t **ptes = area->ptes;
if (apply_to_page_range(_mm, (unsigned long)area->area->addr,
PAGE_SIZE * nr_frames, gnttab_apply, )) {
...
}
-boris
___
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
On 2020-09-15 09:31, Tvrtko Ursulin wrote: On 15/09/2020 02:47, Lu Baolu wrote: Hi Tvrtko, On 9/14/20 4:04 PM, Tvrtko Ursulin wrote: Hi, On 12/09/2020 04:21, Lu Baolu wrote: Tom Murphy has almost done all the work. His latest patch series was posted here. https://lore.kernel.org/linux-iommu/20200903201839.7327-1-murph...@tcd.ie/ Thanks a lot! This series is a follow-up with below changes: 1. Add a quirk for the i915 driver issue described in Tom's cover letter. Last week I have copied you on an i915 series which appears to remove the need for this quirk. so if we get those i915 patches reviewed and merged, do you still want to pursue this quirk? It's up to the graphic guys. I don't know the details in i915 driver. I don't think my tests could cover all cases. I am the graphic guy. :) I just need some reviews (internally) for my series and then we can merge it, at which point you don't need the quirk patch any more. I'll try to accelerate this. With regards to testing, you could send your series with my patches on top to our trybot mailing list (intel-gfx-try...@lists.freedesktop.org / https://patchwork.freedesktop.org/project/intel-gfx-trybot/series/?ordering=-last_updated) which would show you if it is still hitting the DMAR issues in i915. 2. Fix several bugs in patch "iommu: Allow the dma-iommu api to use bounce buffers" to make the bounce buffer work for untrusted devices. 3. Several cleanups in iommu/vt-d driver after the conversion. With the previous version of the series I hit a problem on Ivybridge where apparently the dma engine width is not respected. At least that is my layman interpretation of the errors. From the older thread: <3> [209.526605] DMAR: intel_iommu_map: iommu width (39) is not sufficient for the mapped address (008000) Relevant iommu boot related messages are: <6>[ 0.184234] DMAR: Host address width 36 <6>[ 0.184245] DMAR: DRHD base: 0x00fed9 flags: 0x0 <6>[ 0.184288] DMAR: dmar0: reg_base_addr fed9 ver 1:0 cap c020e60262 ecap f0101a <6>[ 0.184308] DMAR: DRHD base: 0x00fed91000 flags: 0x1 <6>[ 0.184337] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap c9008020660262 ecap f0105a <6>[ 0.184357] DMAR: RMRR base: 0x00d8d28000 end: 0x00d8d46fff <6>[ 0.184377] DMAR: RMRR base: 0x00db00 end: 0x00df1f <6>[ 0.184398] DMAR-IR: IOAPIC id 2 under DRHD base 0xfed91000 IOMMU 1 <6>[ 0.184414] DMAR-IR: HPET id 0 under DRHD base 0xfed91000 <6>[ 0.184428] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping. <6>[ 0.185173] DMAR-IR: Enabled IRQ remapping in x2apic mode <6>[ 0.878934] DMAR: No ATSR found <6>[ 0.878966] DMAR: dmar0: Using Queued invalidation <6>[ 0.879007] DMAR: dmar1: Using Queued invalidation <6>[ 0.915032] DMAR: Intel(R) Virtualization Technology for Directed I/O <6>[ 0.915060] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) <6>[ 0.915084] software IO TLB: mapped [mem 0xc80d4000-0xcc0d4000] (64MB) (Full boot log at https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_7054/fi-ivb-3770/boot0.txt, failures at https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_7054/fi-ivb-3770/igt@i915_selftest@l...@blt.html.) Does this look familiar or at least plausible to you? Is this something your new series has fixed? This happens during attaching a domain to device. It has nothing to do with this patch series. I will look into this issue, but not in this email thread context. 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. AFAICS this certainly might be related to this series - iommu-dma will constrain IOVA allocation based on the domain geometry that the driver reports, which in this case is set only once when first allocating the domain. Thus it looks like both the dmar_domain->gaw adjustment in prepare_domain_attach_device() and the domain_use_first_level() business in intel_alloc_iova() effectively get lost in this conversion, since the domain geometry never gets updated to reflect those additional constraints. Robin. Regards, Tvrtko ___ iommu mailing list io...@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ___ 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
On 2020-09-18 21:47, Logan Gunthorpe wrote: Hi Lu, On 2020-09-11 9:21 p.m., Lu Baolu wrote: Tom Murphy has almost done all the work. His latest patch series was posted here. https://lore.kernel.org/linux-iommu/20200903201839.7327-1-murph...@tcd.ie/ Thanks a lot! This series is a follow-up with below changes: 1. Add a quirk for the i915 driver issue described in Tom's cover letter. 2. Fix several bugs in patch "iommu: Allow the dma-iommu api to use bounce buffers" to make the bounce buffer work for untrusted devices. 3. Several cleanups in iommu/vt-d driver after the conversion. I'm trying to test this on an old Sandy Bridge, but found that I get spammed with warnings on boot. I've put a sample of a few of them below. They all seem to be related to ioat. I had the same issue with Tom's v2 but never saw this on his v1. I think this might have more to do with ioat being totally broken - AFAICS it appears to allocate descriptors with a size of 2MB, but free them with a size of 512KB. Try throwing CONFIG_DMA_API_DEBUG at it to confirm. Robin. Thanks, Logan [ 44.057877] [ cut here ] [ 44.063167] WARNING: CPU: 4 PID: 84 at drivers/iommu/dma-iommu.c:496 __iommu_dma_unmap+0x115/0x130 [ 44.073351] Modules linked in: [ 44.076882] CPU: 4 PID: 84 Comm: kworker/4:1 Tainted: GW 5.9.0-rc4-6-g110da1e703a2 #216 [ 44.087935] Hardware name: Supermicro SYS-7047GR-TRF/X9DRG-QF, BIOS 3.0a 12/05/2013 [ 44.096650] Workqueue: events work_for_cpu_fn [ 44.101644] RIP: 0010:__iommu_dma_unmap+0x115/0x130 [ 44.107225] Code: 48 8b 0c 24 48 c7 44 24 10 00 00 00 00 48 c7 44 24 18 00 00 00 00 48 c7 44 24 20 00 00 00 00 48 c7 44 24 08 ff ff ff ff eb 8d <0f> 0b e9 74 ff ff ff e8 1f 36 66 00 66 66 2e 0f 1f 84 00 00 00 00 [ 44.128443] RSP: :c90002397c38 EFLAGS: 00010206 [ 44.134413] RAX: 0020 RBX: 0008 RCX: [ 44.144487] RDX: 0403 RSI: 82a7fb20 RDI: 888477804f30 [ 44.152613] RBP: fec0 R08: 000fec00 R09: 000fedff [ 44.160733] R10: 0002 R11: 0004 R12: 888270c39000 [ 44.168861] R13: 888472d85ee8 R14: 0008 R15: [ 44.176980] FS: () GS:88847980() knlGS: [ 44.186198] CS: 0010 DS: ES: CR0: 80050033 [ 44.192761] CR2: CR3: 02a20001 CR4: 000606e0 [ 44.200871] Call Trace: [ 44.203716] ? lockdep_hardirqs_on_prepare+0xad/0x180 [ 44.209509] iommu_dma_free+0x18/0x30 [ 44.213734] ioat_free_chan_resources+0x19e/0x300 [ 44.219133] ioat_dma_self_test+0x2a0/0x3d0 [ 44.223964] ioat_pci_probe+0x60e/0x903 [ 44.228387] local_pci_probe+0x42/0x80 [ 44.232721] work_for_cpu_fn+0x16/0x20 [ 44.237037] process_one_work+0x292/0x630 [ 44.241644] ? __schedule+0x344/0x970 [ 44.245868] worker_thread+0x227/0x3e0 [ 44.250185] ? process_one_work+0x630/0x630 [ 44.254989] kthread+0x136/0x150 [ 44.258718] ? kthread_use_mm+0x100/0x100 [ 44.263334] ret_from_fork+0x22/0x30 [ 44.267474] irq event stamp: 1881262 [ 44.271602] hardirqs last enabled at (1881272): [] console_unlock+0x435/0x570 [ 44.281593] hardirqs last disabled at (1881281): [] console_unlock+0x42b/0x570 [ 44.291588] softirqs last enabled at (1747140): [] ioat_cleanup+0x65/0x470 [ 44.301285] softirqs last disabled at (1747144): [] ioat_free_chan_resources+0x6a/0x300 [ 44.312153] ---[ end trace ed0f88fd959a5a39 ]--- [ 44.353963] [ cut here ] [ 44.359291] WARNING: CPU: 4 PID: 84 at drivers/iommu/dma-iommu.c:496 __iommu_dma_unmap+0x115/0x130 [ 44.369482] Modules linked in: [ 44.373030] CPU: 4 PID: 84 Comm: kworker/4:1 Tainted: GW 5.9.0-rc4-6-g110da1e703a2 #216 [ 44.384097] Hardware name: Supermicro SYS-7047GR-TRF/X9DRG-QF, BIOS 3.0a 12/05/2013 [ 44.392825] Workqueue: events work_for_cpu_fn [ 44.397831] RIP: 0010:__iommu_dma_unmap+0x115/0x130 [ 44.403421] Code: 48 8b 0c 24 48 c7 44 24 10 00 00 00 00 48 c7 44 24 18 00 00 00 00 48 c7 44 24 20 00 00 00 00 48 c7 44 24 08 ff ff ff ff eb 8d <0f> 0b e9 74 ff ff ff e8 1f 36 66 00 66 66 2e 0f 1f 84 00 00 00 00 [ 44.424644] RSP: :c90002397c38 EFLAGS: 00010206 [ 44.430627] RAX: 0020 RBX: 0008 RCX: [ 44.438770] RDX: 0403 RSI: 82a7fb20 RDI: 888477804f30 [ 44.446885] RBP: ffc0 R08: 000ffc00 R09: 000ffdff [ 44.455000] R10: 0002 R11: 0004 R12: 888270c55000 [ 44.463119] R13: 888472dc7268 R14: 0008 R15: [ 44.471235] FS: () GS:88847980() knlGS: [ 44.480440] CS: 0010 DS: ES: CR0: 80050033 [ 44.487004] CR2: CR3: 02a20001 CR4: 000606e0 [
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. Defacto the uapi we have now is that userspace needs to ignore "spurious" EBUSY. > 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. This would be a driver bug I think. That really shouldn't happen for normal page flips. -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] [V13 4/5] drm/i915/dsi: Initiate fame request in cmd mode
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);
+
/* FIXME: We should call drm_atomic_helper_commit_hw_done() here
* already, but still need the state for the delayed optimization. To
* fix this:
diff --git a/drivers/gpu/drm/i915/display/intel_dsi.h
b/drivers/gpu/drm/i915/display/intel_dsi.h
index 19f78a4022d3..625f2f1ae061 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi.h
+++ b/drivers/gpu/drm/i915/display/intel_dsi.h
@@ -167,6 +167,7 @@ static inline u16 intel_dsi_encoder_ports(struct
intel_encoder *encoder)
/* icl_dsi.c */
void icl_dsi_init(struct drm_i915_private *dev_priv);
+void icl_dsi_frame_update(struct intel_crtc_state *crtc_state);
/* intel_dsi.c */
int intel_dsi_bitrate(const struct intel_dsi *intel_dsi);
--
2.21.0.5.gaeb582a
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [V13 2/5] i915/dsi: Configure TE interrupt for cmd mode
Configure TE interrupt as part of the vblank
enable call flow.
v2: Hide the private flags check inside configure_te (Jani)
v3: Fix the position of masking de_port_masked for DSI_TE.
v4: Simplify the caller of configure_te (Jani)
v5: Clear IIR, remove the usage of private_flags
v6: including icl_dsi header is not needed
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/i915_irq.c | 50 +++--
1 file changed, 48 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 759f523c6a6b..913548addfba 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2631,12 +2631,47 @@ int ilk_enable_vblank(struct drm_crtc *crtc)
return 0;
}
+static bool gen11_dsi_configure_te(struct intel_crtc *intel_crtc,
+ bool enable)
+{
+ struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
+ enum port port;
+ u32 tmp;
+
+ if (!(intel_crtc->mode_flags &
+ (I915_MODE_FLAG_DSI_USE_TE1 | I915_MODE_FLAG_DSI_USE_TE0)))
+ return false;
+
+ /* for dual link cases we consider TE from slave */
+ if (intel_crtc->mode_flags & I915_MODE_FLAG_DSI_USE_TE1)
+ port = PORT_B;
+ else
+ port = PORT_A;
+
+ tmp = I915_READ(DSI_INTR_MASK_REG(port));
+ if (enable)
+ tmp &= ~DSI_TE_EVENT;
+ else
+ tmp |= DSI_TE_EVENT;
+
+ I915_WRITE(DSI_INTR_MASK_REG(port), tmp);
+
+ tmp = I915_READ(DSI_INTR_IDENT_REG(port));
+ I915_WRITE(DSI_INTR_IDENT_REG(port), tmp);
+
+ return true;
+}
+
int bdw_enable_vblank(struct drm_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
- enum pipe pipe = to_intel_crtc(crtc)->pipe;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ enum pipe pipe = intel_crtc->pipe;
unsigned long irqflags;
+ if (gen11_dsi_configure_te(intel_crtc, true))
+ return 0;
+
spin_lock_irqsave(_priv->irq_lock, irqflags);
bdw_enable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK);
spin_unlock_irqrestore(_priv->irq_lock, irqflags);
@@ -2702,9 +2737,13 @@ void ilk_disable_vblank(struct drm_crtc *crtc)
void bdw_disable_vblank(struct drm_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
- enum pipe pipe = to_intel_crtc(crtc)->pipe;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ enum pipe pipe = intel_crtc->pipe;
unsigned long irqflags;
+ if (gen11_dsi_configure_te(intel_crtc, false))
+ return;
+
spin_lock_irqsave(_priv->irq_lock, irqflags);
bdw_disable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK);
spin_unlock_irqrestore(_priv->irq_lock, irqflags);
@@ -3400,6 +3439,13 @@ static void gen8_de_irq_postinstall(struct
drm_i915_private *dev_priv)
if (IS_GEN9_LP(dev_priv))
de_port_masked |= BXT_DE_PORT_GMBUS;
+ if (INTEL_GEN(dev_priv) >= 11) {
+ enum port port;
+
+ if (intel_bios_is_dsi_present(dev_priv, ))
+ de_port_masked |= DSI0_TE | DSI1_TE;
+ }
+
de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
GEN8_PIPE_FIFO_UNDERRUN;
--
2.21.0.5.gaeb582a
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [V13 5/5] drm/i915/dsi: Enable software vblank counter
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;
+
+ /*
+* From Gen 11, In case of dsi cmd mode, frame counter wouldnt
+* have updated at the beginning of TE, if we want to use
+* the hw counter, then we would find it updated in only
+* the next TE, hence switching to sw counter.
+*/
+ if (flags & (I915_MODE_FLAG_DSI_USE_TE0 | I915_MODE_FLAG_DSI_USE_TE1))
+ return 0;
/*
* On i965gm the hardware frame counter reads
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c2e4b227bdf3..634c60befe7e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -682,8 +682,12 @@ u32 i915_get_vblank_counter(struct drm_crtc *crtc)
u32 g4x_get_vblank_counter(struct drm_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
+ struct drm_vblank_crtc *vblank =
_priv->drm.vblank[drm_crtc_index(crtc)];
enum pipe pipe = to_intel_crtc(crtc)->pipe;
+ if (!vblank->max_vblank_count)
+ return 0;
+
return I915_READ(PIPE_FRMCOUNT_G4X(pipe));
}
--
2.21.0.5.gaeb582a
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [V13 0/5] Add support for mipi dsi cmd mode
This series contain interrupt handling part of cmd mode. Configuration patches were merged already. v10: Address the review comments on patch 3 and 4 v11: fix compilation issue introduced in v10 v12: fix check patch errors on patch 3 v13: Use sw vblank counter (Ville) Vandita Kulkarni (5): drm/i915/dsi: Add details about TE in get_config i915/dsi: Configure TE interrupt for cmd mode drm/i915/dsi: Add TE handler for dsi cmd mode. drm/i915/dsi: Initiate fame request in cmd mode drm/i915/dsi: Enable software vblank counter drivers/gpu/drm/i915/display/icl_dsi.c | 56 +++-- drivers/gpu/drm/i915/display/intel_display.c | 21 drivers/gpu/drm/i915/display/intel_dsi.h | 1 + drivers/gpu/drm/i915/i915_irq.c | 119 ++- 4 files changed, 183 insertions(+), 14 deletions(-) -- 2.21.0.5.gaeb582a ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [V13 3/5] drm/i915/dsi: Add TE handler for dsi cmd mode.
In case of dual link, we get the TE on slave.
So clear the TE on slave DSI IIR.
If we are operating in TE_GATE mode, after we do
a frame update, the transcoder will send the frame data
to the panel, after it receives a TE. Whereas if we
are operating in NO_GATE mode then the transcoder will
immediately send the frame data to the panel.
We are not dealing with the periodic command mode here.
v2: Pass only relevant masked bits to the handler (Jani)
v3: Fix the check for cmd mode in TE handler function.
v4: Use intel_handle_vblank instead of drm_handle_vblank (Jani)
v3: Use static on handler func (Jani)
Signed-off-by: Vandita Kulkarni
Reported-by: kernel test robot
Acked-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_irq.c | 65 +
1 file changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 913548addfba..c2e4b227bdf3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2237,6 +2237,63 @@ gen8_de_misc_irq_handler(struct drm_i915_private
*dev_priv, u32 iir)
drm_err(_priv->drm, "Unexpected DE Misc interrupt\n");
}
+static void gen11_dsi_te_interrupt_handler(struct drm_i915_private *dev_priv,
+ u32 te_trigger)
+{
+ enum pipe pipe = INVALID_PIPE;
+ enum transcoder dsi_trans;
+ enum port port;
+ u32 val, tmp;
+
+ /*
+* Incase of dual link, TE comes from DSI_1
+* this is to check if dual link is enabled
+*/
+ val = I915_READ(TRANS_DDI_FUNC_CTL2(TRANSCODER_DSI_0));
+ val &= PORT_SYNC_MODE_ENABLE;
+
+ /*
+* if dual link is enabled, then read DSI_0
+* transcoder registers
+*/
+ port = ((te_trigger & DSI1_TE && val) || (te_trigger & DSI0_TE)) ?
+ PORT_A : PORT_B;
+ dsi_trans = (port == PORT_A) ? TRANSCODER_DSI_0 : TRANSCODER_DSI_1;
+
+ /* Check if DSI configured in command mode */
+ val = I915_READ(DSI_TRANS_FUNC_CONF(dsi_trans));
+ val = val & OP_MODE_MASK;
+
+ if (val != CMD_MODE_NO_GATE && val != CMD_MODE_TE_GATE) {
+ drm_err(_priv->drm, "DSI trancoder not configured in
command mode\n");
+ return;
+ }
+
+ /* Get PIPE for handling VBLANK event */
+ val = I915_READ(TRANS_DDI_FUNC_CTL(dsi_trans));
+ switch (val & TRANS_DDI_EDP_INPUT_MASK) {
+ case TRANS_DDI_EDP_INPUT_A_ON:
+ pipe = PIPE_A;
+ break;
+ case TRANS_DDI_EDP_INPUT_B_ONOFF:
+ pipe = PIPE_B;
+ break;
+ case TRANS_DDI_EDP_INPUT_C_ONOFF:
+ pipe = PIPE_C;
+ break;
+ default:
+ drm_err(_priv->drm, "Invalid PIPE\n");
+ return;
+ }
+
+ intel_handle_vblank(dev_priv, pipe);
+
+ /* clear TE in dsi IIR */
+ port = (te_trigger & DSI1_TE) ? PORT_B : PORT_A;
+ tmp = I915_READ(DSI_INTR_IDENT_REG(port));
+ I915_WRITE(DSI_INTR_IDENT_REG(port), tmp);
+}
+
static irqreturn_t
gen8_de_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)
{
@@ -2301,6 +2358,14 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
u32 master_ctl)
found = true;
}
+ if (INTEL_GEN(dev_priv) >= 11) {
+ tmp_mask = iir & (DSI0_TE | DSI1_TE);
+ if (tmp_mask) {
+
gen11_dsi_te_interrupt_handler(dev_priv, tmp_mask);
+ found = true;
+ }
+ }
+
if (!found)
drm_err(_priv->drm,
"Unexpected DE Port interrupt\n");
--
2.21.0.5.gaeb582a
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [V13 1/5] drm/i915/dsi: Add details about TE in get_config
We need details about enabling TE on which port
before we enable TE through vblank enable path.
This is based on the configuration that we receive
from the VBT wrt ports, dual_link.
Signed-off-by: Vandita Kulkarni
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/display/icl_dsi.c | 30 +++---
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 520715b7d5b5..2789020e20db 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1447,6 +1447,18 @@ static bool gen11_dsi_is_periodic_cmd_mode(struct
intel_dsi *intel_dsi)
return (val & DSI_PERIODIC_FRAME_UPDATE_ENABLE);
}
+static void gen11_dsi_get_cmd_mode_config(struct intel_dsi *intel_dsi,
+ struct intel_crtc_state *pipe_config)
+{
+ if (intel_dsi->ports == (BIT(PORT_B) | BIT(PORT_A)))
+ pipe_config->mode_flags |= I915_MODE_FLAG_DSI_USE_TE1 |
+ I915_MODE_FLAG_DSI_USE_TE0;
+ else if (intel_dsi->ports == BIT(PORT_B))
+ pipe_config->mode_flags |= I915_MODE_FLAG_DSI_USE_TE1;
+ else
+ pipe_config->mode_flags |= I915_MODE_FLAG_DSI_USE_TE0;
+}
+
static void gen11_dsi_get_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config)
{
@@ -1468,6 +1480,10 @@ static void gen11_dsi_get_config(struct intel_encoder
*encoder,
pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI);
pipe_config->pipe_bpp = bdw_get_pipemisc_bpp(crtc);
+ /* Get the details on which TE should be enabled */
+ if (is_cmd_mode(intel_dsi))
+ gen11_dsi_get_cmd_mode_config(intel_dsi, pipe_config);
+
if (gen11_dsi_is_periodic_cmd_mode(intel_dsi))
pipe_config->mode_flags |= I915_MODE_FLAG_DSI_PERIODIC_CMD_MODE;
}
@@ -1562,18 +1578,8 @@ static int gen11_dsi_compute_config(struct intel_encoder
*encoder,
* receive TE from the slave if
* dual link is enabled
*/
- if (is_cmd_mode(intel_dsi)) {
- if (intel_dsi->ports == (BIT(PORT_B) | BIT(PORT_A)))
- pipe_config->mode_flags |=
- I915_MODE_FLAG_DSI_USE_TE1 |
- I915_MODE_FLAG_DSI_USE_TE0;
- else if (intel_dsi->ports == BIT(PORT_B))
- pipe_config->mode_flags |=
- I915_MODE_FLAG_DSI_USE_TE1;
- else
- pipe_config->mode_flags |=
- I915_MODE_FLAG_DSI_USE_TE0;
- }
+ if (is_cmd_mode(intel_dsi))
+ gen11_dsi_get_cmd_mode_config(intel_dsi, pipe_config);
return 0;
}
--
2.21.0.5.gaeb582a
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Tweak initial dpcd backlight.enabled value
On Mon, Sep 21, 2020 at 6:35 PM Lyude Paul wrote:
>
> So if I understand this correctly, it sounds like that some Pixelbooks boot up
> with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB set to a non-zero value, without the
> panel actually having DPCD backlight controls enabled?
It boots with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB == 0, which used to set
backlight.enabled = false. By changing backlight.level = max,
backlight.enabled is now set to true. This results in losing backlight
control on boot (since the enable routine is no longer invoked).
Sean
>
> If I'm understanding that correctly, then this patch looks good to me:
>
> Reviewed-by: Lyude Paul
>
> On Thu, 2020-09-17 at 20:28 -0400, Sean Paul wrote:
> > From: Sean Paul
> >
> > In commit 79946723092b ("drm/i915: Assume 100% brightness when not in
> > DPCD control mode"), we fixed the brightness level when DPCD control was
> > not active to max brightness. This is as good as we can guess since most
> > backlights go on full when uncontrolled.
> >
> > However in doing so we changed the semantics of the initial
> > 'backlight.enabled' value. At least on Pixelbooks, they were relying
> > on the brightness level in DP_EDP_BACKLIGHT_BRIGHTNESS_MSB to be 0 on
> > boot such that enabled would be false. This causes the device to be
> > enabled when the brightness is set. Without this, brightness control
> > doesn't work. So by changing brightness to max, we also flipped enabled
> > to be true on boot.
> >
> > To fix this, make enabled a function of brightness and backlight control
> > mechanism.
> >
> > Fixes: 79946723092b ("drm/i915: Assume 100% brightness when not in DPCD
> > control mode")
> > Cc: Lyude Paul
> > Cc: Jani Nikula
> > Cc: Juha-Pekka Heikkila
> > Cc: "Ville Syrjälä"
> > Cc: Rodrigo Vivi
> > Cc: Kevin Chowski >
> > Signed-off-by: Sean Paul
> > ---
> > .../drm/i915/display/intel_dp_aux_backlight.c | 31 ---
> > 1 file changed, 20 insertions(+), 11 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 acbd7eb66cbe..036f504ac7db 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > @@ -52,17 +52,11 @@ static void set_aux_backlight_enable(struct intel_dp
> > *intel_dp, bool enable)
> > }
> > }
> >
> > -/*
> > - * Read the current backlight value from DPCD register(s) based
> > - * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
> > - */
> > -static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
> > +static bool intel_dp_aux_backlight_dpcd_mode(struct intel_connector
> > *connector)
> > {
> > struct intel_dp *intel_dp = intel_attached_dp(connector);
> > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > - u8 read_val[2] = { 0x0 };
> > u8 mode_reg;
> > - u16 level = 0;
> >
> > if (drm_dp_dpcd_readb(_dp->aux,
> > DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
> > @@ -70,15 +64,29 @@ static u32 intel_dp_aux_get_backlight(struct
> > intel_connector *connector)
> > drm_dbg_kms(>drm,
> > "Failed to read the DPCD register 0x%x\n",
> > DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
> > - return 0;
> > + return false;
> > }
> >
> > + return (mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) ==
> > +DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> > +}
> > +
> > +/*
> > + * Read the current backlight value from DPCD register(s) based
> > + * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
> > + */
> > +static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
> > +{
> > + struct intel_dp *intel_dp = intel_attached_dp(connector);
> > + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > + u8 read_val[2] = { 0x0 };
> > + u16 level = 0;
> > +
> > /*
> >* If we're not in DPCD control mode yet, the programmed brightness
> >* value is meaningless and we should assume max brightness
> >*/
> > - if ((mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) !=
> > - DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD)
> > + if (!intel_dp_aux_backlight_dpcd_mode(connector))
> > return connector->panel.backlight.max;
> >
> > if (drm_dp_dpcd_read(_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
> > @@ -319,7 +327,8 @@ static int intel_dp_aux_setup_backlight(struct
> > intel_connector *connector,
> >
> > panel->backlight.min = 0;
> > panel->backlight.level = intel_dp_aux_get_backlight(connector);
> > - panel->backlight.enabled = panel->backlight.level != 0;
> > + panel->backlight.enabled = intel_dp_aux_backlight_dpcd_mode(connector)
> > &&
> > +panel->backlight.level != 0;
> >
> > return 0;
> > }
> --
> Cheers,
> Lyude Paul (she/her)
>
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
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. > > 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 signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH v2 2/2] drm/i915: Introduce a i915_gem_do_ww(){} utility
On 9/22/20 11:12 AM, Tvrtko Ursulin wrote:
On 17/09/2020 19:59, Thomas Hellström (Intel) wrote:
From: Thomas Hellström
With the huge number of sites where multiple-object locking is
needed in the driver, it becomes difficult to avoid recursive
ww_acquire_ctx initialization, and the function prototypes become
bloated passing the ww_acquire_ctx around. Furthermore it's not
always easy to get the -EDEADLK handling correct and to follow it.
Introduce a i915_gem_do_ww utility that tries to remedy all these
problems
by enclosing parts of a ww transaction in the following way:
my_function() {
struct i915_gem_ww_ctx *ww, template;
int err;
bool interruptible = true;
i915_do_ww(ww, , err, interruptible) {
err = ww_transaction_part(ww);
}
return err;
}
The utility will automatically look up an active ww_acquire_ctx if one
is initialized previously in the call chain, and if one found will
forward the -EDEADLK instead of handling it, which takes care of the
recursive initalization. Using the utility also discourages nested ww
unlocking / relocking that is both very fragile and hard to follow.
To look up and register an active ww_acquire_ctx, use a
driver-wide hash table for now. But noting that a task could only have
a single active ww_acqurie_ctx per ww_class, the active CTX is really
task state and a generic version of this utility in the ww_mutex code
could thus probably use a quick lookup from a list in the
struct task_struct.
Maybe a stupid question, but is it safe to assume process context is
the only entry point to a ww transaction? I guess I was thinking about
things like background scrub/migrate threads, but yes, they would be
threads so would work. Other than those I have no ideas who could need
locking multiple objects so from this aspect it looks okay.
But it is kind of neat to avoid changing deep hierarchies of function
prototypes.
My concern is that the approach isn't to "magicky"? I mean too hidden
and too stateful, and that some unwanted surprises could be coming in
use with this model. But it is a very vague feeling at this point so
don't know.
I also worry that if the graphics subsystem would start thinking it is
so special that it needs dedicated handling in task_struct, that it
might make it (subsystem) sound a bit pretentious. I had a quick
browse through struct task_struct and couldn't spot any precedent to
such things so I don't know what core kernel would say.
Thanks for taking a look Tvrtko.
Yes, I've discussed with Maarten and we'll favour changing prototype for
now, although for code clarity and simplicity we could still use the
i915_do_ww() notation.
For any upsteam move we would have to move the utility to locking /
ww_mutex, (with driver-specific adaption still possible, so any
additional task struct fields will not belong to graphics but rather to
locking) so I'll post a RFC for a generic utility on dri-devel, time
permitting, to see if there is any interest.
/Thomas
Regards,
Tvrtko
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_gem_ww.c | 74 -
drivers/gpu/drm/i915/i915_gem_ww.h | 56 +-
drivers/gpu/drm/i915/i915_globals.c | 1 +
drivers/gpu/drm/i915/i915_globals.h | 1 +
4 files changed, 130 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_ww.c
b/drivers/gpu/drm/i915/i915_gem_ww.c
index 3490b72cf613..6247af1dba87 100644
--- a/drivers/gpu/drm/i915/i915_gem_ww.c
+++ b/drivers/gpu/drm/i915/i915_gem_ww.c
@@ -1,10 +1,12 @@
// SPDX-License-Identifier: MIT
/*
- * Copyright © 2020 Intel Corporation
+ * Copyright © 2019 Intel Corporation
*/
+#include
#include
#include
#include "i915_gem_ww.h"
+#include "i915_globals.h"
#include "gem/i915_gem_object.h"
void i915_gem_ww_ctx_init(struct i915_gem_ww_ctx *ww, bool intr)
@@ -70,3 +72,73 @@ int __must_check i915_gem_ww_ctx_backoff(struct
i915_gem_ww_ctx *ww)
return ret;
}
+
+static struct rhashtable ww_ht;
+static const struct rhashtable_params ww_params = {
+ .key_len = sizeof(struct task_struct *),
+ .key_offset = offsetof(struct i915_gem_ww_ctx, ctx.task),
+ .head_offset = offsetof(struct i915_gem_ww_ctx, head),
+ .min_size = 128,
+};
+
+static void i915_ww_item_free(void *ptr, void *arg)
+{
+ WARN_ON_ONCE(1);
+}
+
+static void i915_global_ww_exit(void)
+{
+ rhashtable_free_and_destroy(_ht, i915_ww_item_free, NULL);
+}
+
+static void i915_global_ww_shrink(void)
+{
+}
+
+static struct i915_global global = {
+ .shrink = i915_global_ww_shrink,
+ .exit = i915_global_ww_exit,
+};
+
+int __init i915_global_ww_init(void)
+{
+ int ret = rhashtable_init(_ht, _params);
+
+ if (ret)
+ return ret;
+
+ i915_global_register();
+
+ return 0;
+}
+
+void __i915_gem_ww_mark_unused(struct i915_gem_ww_ctx *ww)
+{
+ GEM_WARN_ON(rhashtable_remove_fast(_ht, >head, ww_params));
+}
+
+/**
+ *
Re: [Intel-gfx] [PATCH 3/7] drm/i915: Simplify the link training functions
On Tue, Sep 22, 2020 at 03:51:02PM +0300, Imre Deak wrote:
> Split the prepare, link training, fallback-handling steps into their own
> functions for clarity and as a preparation for the upcoming LTTPR changes.
>
> While at it also add some documentation to exported functions.
>
> Signed-off-by: Imre Deak
> ---
> .../drm/i915/display/intel_dp_link_training.c | 80 ++-
> 1 file changed, 62 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index 6d13d00db5e6..0c3809891bd2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -162,14 +162,13 @@ static bool intel_dp_link_max_vswing_reached(struct
> intel_dp *intel_dp)
> return true;
> }
>
> -/* Enable corresponding port and start training pattern 1 */
> -static bool
> -intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> +/*
> + * Prepare link training by configuring the link parameters and enabling the
> + * corresponding port.
> + */
> +static void intel_dp_prepare_link_train(struct intel_dp *intel_dp)
> {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> - u8 voltage;
> - int voltage_tries, cr_tries, max_cr_tries;
> - bool max_vswing_reached = false;
> u8 link_config[2];
> u8 link_bw, rate_select;
>
> @@ -203,6 +202,16 @@ intel_dp_link_training_clock_recovery(struct intel_dp
> *intel_dp)
> drm_dp_dpcd_write(_dp->aux, DP_DOWNSPREAD_CTRL, link_config, 2);
>
> intel_dp->DP |= DP_PORT_EN;
I guess we no longer actually enable the port here? The comment ^ still says
we do.
Hmm. Seems we do enable the port on ddi platforms, but not on older
platforms. I guess the docs could still use a tweak to reflect
reality a bit better.
> +}
> +
> +/* Perform the link training clock recovery phase using training pattern 1.
> */
> +static bool
> +intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + u8 voltage;
> + int voltage_tries, cr_tries, max_cr_tries;
> + bool max_vswing_reached = false;
>
> /* clock recovery */
> if (!intel_dp_reset_link_train(intel_dp,
> @@ -325,6 +334,10 @@ static u32 intel_dp_training_pattern(struct intel_dp
> *intel_dp)
> return DP_TRAINING_PATTERN_2;
> }
>
> +/*
> + * Perform the link training channel equalization phase using one of training
> + * pattern 2, 3 or 4 depending on the the source and sink capabilities.
> + */
> static bool
> intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
> {
> @@ -395,6 +408,15 @@ intel_dp_link_training_channel_equalization(struct
> intel_dp *intel_dp)
>
> }
>
> +/**
> + * intel_dp_stop_link_train - stop link training
> + * @intel_dp: DP struct
> + *
> + * Stop the link training of the @intel_dp port, programming the port to
> + * output an idle pattern
I don't think we use the idle pattern on all platforms.
BTW intel_dp_set_idle_link_train() looks pretty pointless. Could just
inline it into its only caller, or at least move it into
intel_dp_link_training.c.
Reviewed-by: Ville Syrjälä
> on the link and disabling the training pattern in
> + * the sink's DPCD.
> + * This function must be called after intel_dp_start_link_train().
> + */
> void intel_dp_stop_link_train(struct intel_dp *intel_dp)
> {
> intel_dp->link_trained = true;
> @@ -403,30 +425,37 @@ void intel_dp_stop_link_train(struct intel_dp *intel_dp)
> DP_TRAINING_PATTERN_DISABLE);
> }
>
> -void
> -intel_dp_start_link_train(struct intel_dp *intel_dp)
> +static bool
> +intel_dp_link_train(struct intel_dp *intel_dp)
> {
> struct intel_connector *intel_connector = intel_dp->attached_connector;
> + bool ret = false;
> +
> + intel_dp_prepare_link_train(intel_dp);
>
> if (!intel_dp_link_training_clock_recovery(intel_dp))
> - goto failure_handling;
> + goto out;
> +
> if (!intel_dp_link_training_channel_equalization(intel_dp))
> - goto failure_handling;
> + goto out;
>
> - drm_dbg_kms(_to_i915(intel_dp)->drm,
> - "[CONNECTOR:%d:%s] Link Training Passed at Link Rate = %d,
> Lane count = %d",
> - intel_connector->base.base.id,
> - intel_connector->base.name,
> - intel_dp->link_rate, intel_dp->lane_count);
> - return;
> + ret = true;
>
> - failure_handling:
> +out:
> drm_dbg_kms(_to_i915(intel_dp)->drm,
> - "[CONNECTOR:%d:%s] Link Training failed at link rate = %d,
> lane count = %d",
> + "[CONNECTOR:%d:%s] Link Training %s at Link Rate = %d, Lane
> count = %d",
> intel_connector->base.base.id,
> intel_connector->base.name,
> + ret ?
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add support for LTTPR non-transparent link training mode
== Series Details == Series: drm/i915: Add support for LTTPR non-transparent link training mode URL : https://patchwork.freedesktop.org/series/81968/ State : success == Summary == CI Bug Log - changes from CI_DRM_9033 -> Patchwork_18544 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18544/index.html Known issues Here are the changes found in Patchwork_18544 that come from known issues: ### IGT changes ### Issues hit * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [PASS][1] -> [DMESG-WARN][2] ([i915#165]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9033/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18544/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html Possible fixes * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: [DMESG-WARN][3] ([i915#1982]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9033/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18544/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [DMESG-FAIL][5] ([i915#62] / [i915#95]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9033/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18544/fi-kbl-x1275/igt@i915_pm_...@module-reload.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-icl-u2: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9033/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18544/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_flip@basic-flip-vs-modeset@b-dp1: - fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92]) -> [PASS][10] +30 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9033/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@b-dp1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18544/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@b-dp1.html * igt@kms_force_connector_basic@prune-stale-modes: - fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95]) -> [PASS][12] +12 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9033/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18544/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (43 -> 37) -- Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_9033 -> Patchwork_18544 CI-20190529: 20190529 CI_DRM_9033: afeb3835029ad70d17802a9c7148a8372fb08479 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5787: 0ec962017c8131de14e0cb038f7f76b1f17ed637 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_18544: 91260e606734a4fc95f326bb4eb13f45f8793794 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 91260e606734 drm/i915: Switch to LTTPR non-transparent mode link training 4fbcfbcb1a33 drm/i915: Switch to LTTPR transparent mode link training 6a20187d3dfa drm/dp: Add LTTPR helpers 0b95955d4877 drm/i915: Factor out a helper to disable the DPCD training pattern b7d02e6b76cc drm/i915: Simplify the link training functions b688f7336e26 drm/i915: Move intel_dp_get_link_status to intel_dp_link_training.c 154fc7783917 drm/i915: Fix DP link training pattern mask == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18544/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/7] drm/i915: Move intel_dp_get_link_status to intel_dp_link_training.c
On Tue, Sep 22, 2020 at 03:51:01PM +0300, Imre Deak wrote:
> The link status is used to communicate the parameters of the link
> training with the DPRX and determine if the link training is successful
> or a retraining is needed. Accordingly move the function to read the
> link status to intel_dp_link_training.c
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 11 ---
> drivers/gpu/drm/i915/display/intel_dp.h | 2 --
> .../drm/i915/display/intel_dp_link_training.c| 16
> .../drm/i915/display/intel_dp_link_training.h| 3 +++
> 4 files changed, 19 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 2a4a9c0e7427..ee93a00a4d5e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4126,17 +4126,6 @@ static void chv_dp_post_pll_disable(struct
> intel_atomic_state *state,
> chv_phy_post_pll_disable(encoder, old_crtc_state);
> }
>
> -/*
> - * Fetch AUX CH registers 0x202 - 0x207 which contain
> - * link status information
> - */
> -bool
> -intel_dp_get_link_status(struct intel_dp *intel_dp, u8
> link_status[DP_LINK_STATUS_SIZE])
> -{
> - return drm_dp_dpcd_read(_dp->aux, DP_LANE0_1_STATUS, link_status,
> - DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
> -}
> -
> static u8 intel_dp_voltage_max_2(struct intel_dp *intel_dp)
> {
> return DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index 08a1c0aa8b94..34ae7988a554 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -100,8 +100,6 @@ void intel_dp_compute_rate(struct intel_dp *intel_dp, int
> port_clock,
> u8 *link_bw, u8 *rate_select);
> bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp);
> bool intel_dp_source_supports_hbr3(struct intel_dp *intel_dp);
> -bool
> -intel_dp_get_link_status(struct intel_dp *intel_dp, u8 *link_status);
>
> bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp);
> int intel_dp_link_required(int pixel_clock, int bpp);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index f8b53c5b5777..6d13d00db5e6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -34,6 +34,22 @@ intel_dp_dump_link_status(const u8
> link_status[DP_LINK_STATUS_SIZE])
> link_status[3], link_status[4], link_status[5]);
> }
>
> +/**
> + * intel_dp_get_link_status - get the link status information for the DPRX
> + * @intel_dp: DP struct
> + * @link_status: buffer to return the status in
> + *
> + * Fetch the AUX DPCD registers for the DPRX link status.
> + *
> + * Returns true if the information was read successfully, false otherwise.
> + */
> +bool
> +intel_dp_get_link_status(struct intel_dp *intel_dp, u8
> link_status[DP_LINK_STATUS_SIZE])
> +{
> + return drm_dp_dpcd_read(_dp->aux, DP_LANE0_1_STATUS, link_status,
> + DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
> +}
> +
> static u8 dp_voltage_max(u8 preemph)
> {
> switch (preemph & DP_TRAIN_PRE_EMPHASIS_MASK) {
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> index 01f1dabbb060..47c97f4a0d57 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> @@ -10,6 +10,9 @@
>
> struct intel_dp;
>
> +bool intel_dp_get_link_status(struct intel_dp *intel_dp,
> + u8 link_status[DP_LINK_STATUS_SIZE]);
> +
Do we still need it outside? Hmm, I guess we do.
Oh well
Reviewed-by: Ville Syrjälä
> void intel_dp_get_adjust_train(struct intel_dp *intel_dp,
> const u8 link_status[DP_LINK_STATUS_SIZE]);
> void intel_dp_start_link_train(struct intel_dp *intel_dp);
> --
> 2.17.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Fix DP link training pattern mask
On Tue, Sep 22, 2020 at 03:51:00PM +0300, Imre Deak wrote:
> An LTTPR can be trained with training pattern 4 even if the DPCD
> revision is < 1.4, but drm_dp_training_pattern_mask() would change
> pattern 4 to pattern 3 on those DPCD revisions.
>
> Since intel_dp_training_pattern() makes already sure that the proper
> training pattern is used, all that needs to be masked out is the
> scrambling disable flag, which is or'd to the mask later based on the
> training pattern.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 3 +--
> drivers/gpu/drm/i915/display/intel_dp.c | 10 +-
> drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 +-
> 3 files changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 4d06178cd76c..946a3b6f2d10 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4158,13 +4158,12 @@ static void intel_ddi_set_link_train(struct intel_dp
> *intel_dp,
>u8 dp_train_pat)
> {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> - u8 train_pat_mask = drm_dp_training_pattern_mask(intel_dp->dpcd);
> u32 temp;
>
> temp = intel_de_read(dev_priv, intel_dp->regs.dp_tp_ctl);
>
> temp &= ~DP_TP_CTL_LINK_TRAIN_MASK;
> - switch (dp_train_pat & train_pat_mask) {
> + switch (dp_train_pat & ~DP_LINK_SCRAMBLING_DISABLE) {
Maybe introduce a helper to do the masking for us?
Anyways
Reviewed-by: Ville Syrjälä
> case DP_TRAINING_PATTERN_DISABLE:
> temp |= DP_TP_CTL_LINK_TRAIN_NORMAL;
> break;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index bf1e9cf1c0f3..2a4a9c0e7427 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3778,7 +3778,7 @@ cpt_set_link_train(struct intel_dp *intel_dp,
>
> *DP &= ~DP_LINK_TRAIN_MASK_CPT;
>
> - switch (dp_train_pat & DP_TRAINING_PATTERN_MASK) {
> + switch (dp_train_pat & ~DP_LINK_SCRAMBLING_DISABLE) {
> case DP_TRAINING_PATTERN_DISABLE:
> *DP |= DP_LINK_TRAIN_OFF_CPT;
> break;
> @@ -3808,7 +3808,7 @@ g4x_set_link_train(struct intel_dp *intel_dp,
>
> *DP &= ~DP_LINK_TRAIN_MASK;
>
> - switch (dp_train_pat & DP_TRAINING_PATTERN_MASK) {
> + switch (dp_train_pat & ~DP_LINK_SCRAMBLING_DISABLE) {
> case DP_TRAINING_PATTERN_DISABLE:
> *DP |= DP_LINK_TRAIN_OFF;
> break;
> @@ -4498,12 +4498,12 @@ intel_dp_program_link_training_pattern(struct
> intel_dp *intel_dp,
> u8 dp_train_pat)
> {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> - u8 train_pat_mask = drm_dp_training_pattern_mask(intel_dp->dpcd);
>
> - if (dp_train_pat & train_pat_mask)
> + if ((dp_train_pat & ~DP_LINK_SCRAMBLING_DISABLE) !=
> + DP_TRAINING_PATTERN_DISABLE)
> drm_dbg_kms(_priv->drm,
> "Using DP training pattern TPS%d\n",
> - dp_train_pat & train_pat_mask);
> + dp_train_pat & ~DP_LINK_SCRAMBLING_DISABLE);
>
> intel_dp->set_link_train(intel_dp, dp_train_pat);
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index f2c8b56be9ea..f8b53c5b5777 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -96,7 +96,7 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
> intel_dp_program_link_training_pattern(intel_dp, dp_train_pat);
>
> buf[0] = dp_train_pat;
> - if ((dp_train_pat & DP_TRAINING_PATTERN_MASK) ==
> + if ((dp_train_pat & ~DP_LINK_SCRAMBLING_DISABLE) ==
> DP_TRAINING_PATTERN_DISABLE) {
> /* don't write DP_TRAINING_LANEx_SET on disable */
> len = 1;
> --
> 2.17.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Add support for LTTPR non-transparent link training mode
== Series Details == Series: drm/i915: Add support for LTTPR non-transparent link training mode URL : https://patchwork.freedesktop.org/series/81968/ 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/amd/amdgpu/amdgpu_atombios.c:1019:47:expected unsigned int [addressable] [usertype] ulClockParams +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47:got restricted __le32 [usertype] +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47: warning: incorrect type in assignment (different base types) +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1028:50: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1029:49: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1037:47: warning: too many warnings +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:184:44: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:283:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:320:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:323:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:326:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:329:18: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:330:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:338:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:340:38: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:342:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:346:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:348:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:353:33: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:367:43: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:369:38: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:374:67: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:375:53: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:378:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:389:80: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:395:57: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:402:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:403:53: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:406:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:414:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:423:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:424:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:473:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:476:45: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:477:45: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:484:54: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:52:28: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:531:35: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:53:29: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:533:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:54:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:55:27: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:56:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:57:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:577:21: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:581:25: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:58:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:583:21: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:586:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:590:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:59:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:598:21: warning:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add support for LTTPR non-transparent link training mode
== Series Details == Series: drm/i915: Add support for LTTPR non-transparent link training mode URL : https://patchwork.freedesktop.org/series/81968/ State : warning == Summary == $ dim checkpatch origin/drm-tip 154fc7783917 drm/i915: Fix DP link training pattern mask b688f7336e26 drm/i915: Move intel_dp_get_link_status to intel_dp_link_training.c b7d02e6b76cc drm/i915: Simplify the link training functions -:60: WARNING:REPEATED_WORD: Possible repeated word: 'the' #60: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:339: + * pattern 2, 3 or 4 depending on the the source and sink capabilities. total: 0 errors, 1 warnings, 0 checks, 127 lines checked 0b95955d4877 drm/i915: Factor out a helper to disable the DPCD training pattern 6a20187d3dfa drm/dp: Add LTTPR helpers 4fbcfbcb1a33 drm/i915: Switch to LTTPR transparent mode link training 91260e606734 drm/i915: Switch to LTTPR non-transparent mode link training -:140: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional statements (8, 24) #140: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:64: + if (drm_dp_dpcd_read(_dp->aux, [...] + return false; -:237: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u8' over 'uint8_t' #237: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:156: + uint8_t *phy_caps = intel_dp_lttpr_phy_caps(intel_dp, dp_phy); -:265: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u8' over 'uint8_t' #265: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:194: + const uint8_t *phy_caps = intel_dp_lttpr_phy_caps(intel_dp, dp_phy); -:276: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u8' over 'uint8_t' #276: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:205: + const uint8_t *phy_caps = intel_dp_lttpr_phy_caps(intel_dp, dp_phy); -:285: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #285: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:214: +static u8 intel_dp_phy_voltage_max(struct intel_dp *intel_dp, + enum drm_dp_phy dp_phy) -:410: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #410: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:326: +intel_dp_reset_link_train(struct intel_dp *intel_dp, enum drm_dp_phy dp_phy, u8 dp_train_pat) -:535: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u8' over 'uint8_t' #535: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:557: + const uint8_t *phy_caps = intel_dp_lttpr_phy_caps(intel_dp, dp_phy); -:545: WARNING:REPEATED_WORD: Possible repeated word: 'the' #545: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:565: + * using one of training pattern 2, 3 or 4 depending on the the source and total: 0 errors, 2 warnings, 6 checks, 678 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/7] drm/dp: Add LTTPR helpers
Add the helpers and register definitions needed to read out the common
and per-PHY LTTPR capabilities and perform link training in the LTTPR
non-transparent mode.
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_dp_helper.c | 179 +++-
include/drm/drm_dp_helper.h | 56 ++
2 files changed, 231 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 90807a6b415c..115d2c3320ef 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -150,11 +150,8 @@ void drm_dp_link_train_clock_recovery_delay(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
}
EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
-void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+static void __drm_dp_link_train_channel_eq_delay(unsigned long rd_interval)
{
- unsigned long rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
-DP_TRAINING_AUX_RD_MASK;
-
if (rd_interval > 4)
DRM_DEBUG_KMS("AUX interval %lu, out of range (max 4)\n",
rd_interval);
@@ -166,8 +163,35 @@ void drm_dp_link_train_channel_eq_delay(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
usleep_range(rd_interval, rd_interval * 2);
}
+
+void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ __drm_dp_link_train_channel_eq_delay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+DP_TRAINING_AUX_RD_MASK);
+}
EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
+void drm_dp_lttpr_link_train_clock_recovery_delay(void)
+{
+ usleep_range(100, 200);
+}
+EXPORT_SYMBOL(drm_dp_lttpr_link_train_clock_recovery_delay);
+
+static u8 dp_lttpr_phy_cap(const u8 phy_cap[DP_LTTPR_PHY_CAP_SIZE], int r)
+{
+ return phy_cap[r - DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1];
+}
+
+void drm_dp_lttpr_link_train_channel_eq_delay(const u8
phy_cap[DP_LTTPR_PHY_CAP_SIZE])
+{
+ u8 interval = dp_lttpr_phy_cap(phy_cap,
+
DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1) &
+ DP_TRAINING_AUX_RD_MASK;
+
+ __drm_dp_link_train_channel_eq_delay(interval);
+}
+EXPORT_SYMBOL(drm_dp_lttpr_link_train_channel_eq_delay);
+
u8 drm_dp_link_rate_to_bw_code(int link_rate)
{
/* Spec says link_bw = link_rate / 0.27Gbps */
@@ -2093,6 +2117,153 @@ int drm_dp_dsc_sink_supported_input_bpcs(const u8
dsc_dpcd[DP_DSC_RECEIVER_CAP_S
}
EXPORT_SYMBOL(drm_dp_dsc_sink_supported_input_bpcs);
+/**
+ * drm_dp_read_lttpr_common_caps - read the LTTPR common capabilities
+ * @aux: DisplayPort AUX channel
+ * @caps: buffer to return the capability info in
+ *
+ * Read capabilities common to all LTTPRs.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_read_lttpr_common_caps(struct drm_dp_aux *aux,
+ u8 caps[DP_LTTPR_COMMON_CAP_SIZE])
+{
+ int ret;
+
+ ret = drm_dp_dpcd_read(aux,
+
DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV,
+ caps, DP_LTTPR_COMMON_CAP_SIZE);
+ if (ret < 0)
+ return ret;
+
+ WARN_ON(ret != DP_LTTPR_COMMON_CAP_SIZE);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_read_lttpr_common_caps);
+
+/**
+ * drm_dp_read_lttpr_phy_caps - read the capabilities for a given LTTPR PHY
+ * @aux: DisplayPort AUX channel
+ * @dp_phy: LTTPR PHY to read the capabilities for
+ * @caps: buffer to return the capability info in
+ *
+ * Read the capabilities for the given LTTPR PHY.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_read_lttpr_phy_caps(struct drm_dp_aux *aux,
+ enum drm_dp_phy dp_phy,
+ u8 caps[DP_LTTPR_PHY_CAP_SIZE])
+{
+ int ret;
+
+ ret = drm_dp_dpcd_read(aux,
+ DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER(dp_phy),
+ caps, DP_LTTPR_PHY_CAP_SIZE);
+ if (ret < 0)
+ return ret;
+
+ WARN_ON(ret != DP_LTTPR_PHY_CAP_SIZE);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_read_lttpr_phy_caps);
+
+static u8 dp_lttpr_common_cap(const u8 caps[DP_LTTPR_COMMON_CAP_SIZE], int r)
+{
+ return caps[r - DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV];
+}
+
+/**
+ * drm_dp_lttpr_count - get the number of detected LTTPRs
+ * @caps: LTTPR common capabilities
+ *
+ * Get the number of detected LTTPRs from the LTTPR common capabilities info.
+ *
+ * Returns:
+ * -ERANGE if more than supported number (8) of LTTPRs are detected
+ * -EINVAL if the DP_PHY_REPEATER_CNT register contains an invalid value
+ * otherwise the number of detected LTTPRs
+ */
+int drm_dp_lttpr_count(const u8 caps[DP_LTTPR_COMMON_CAP_SIZE])
+{
+ u8 count = dp_lttpr_common_cap(caps,
[Intel-gfx] [PATCH 6/7] drm/i915: Switch to LTTPR transparent mode link training
By default LTTPRs should be in transparent link training mode,
nevertheless in this patch we switch to this default mode explicitly.
The DP Standard recommends this, supposedly because an LTTPR may be left
in the non-transparent mode (by BIOS, previous kernel, or after reset
due to a firmware bug). I haven't seen this happening, but let's follow
the DP Standard.
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 3 ++
.../drm/i915/display/intel_dp_link_training.c | 42 +++
.../drm/i915/display/intel_dp_link_training.h | 1 +
4 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 3d4bf9b6a0a2..b04921eba73b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1280,6 +1280,7 @@ struct intel_dp {
u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
u8 edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE];
u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE];
+ u8 lttpr_common_caps[DP_LTTPR_COMMON_CAP_SIZE];
u8 fec_capable;
/* source rates */
int num_source_rates;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index ee93a00a4d5e..d88f327aa9ef 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4721,6 +4721,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
{
int ret;
+ if (!intel_dp_is_edp(intel_dp))
+ intel_dp_read_lttpr_caps(intel_dp);
+
if (drm_dp_read_dpcd_caps(_dp->aux, intel_dp->dpcd))
return false;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 6994a32244dc..1485602659be 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -50,6 +50,24 @@ intel_dp_get_link_status(struct intel_dp *intel_dp, u8
link_status[DP_LINK_STATU
DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
}
+/**
+ * intel_dp_read_lttpr_caps - read the LTTPR common capabilities
+ * @intel_dp: Intel DP struct
+ *
+ * Read the LTTPR common capabilities.
+ */
+void intel_dp_read_lttpr_caps(struct intel_dp *intel_dp)
+{
+ if (drm_dp_read_lttpr_common_caps(_dp->aux,
+ intel_dp->lttpr_common_caps) < 0)
+ return;
+
+ drm_dbg_kms(_to_i915(intel_dp)->drm,
+ "LTTPR common capabilities: %*ph\n",
+ (int)sizeof(intel_dp->lttpr_common_caps),
+ intel_dp->lttpr_common_caps);
+}
+
static u8 dp_voltage_max(u8 preemph)
{
switch (preemph & DP_TRAIN_PRE_EMPHASIS_MASK) {
@@ -474,6 +492,28 @@ static void
intel_dp_schedule_fallback_link_training(struct intel_dp *intel_dp)
schedule_work(_connector->modeset_retry_work);
}
+static bool
+intel_dp_set_lttpr_transparent_mode(struct intel_dp *intel_dp, bool enable)
+{
+ u8 val = enable ? DP_PHY_REPEATER_MODE_TRANSPARENT :
+ DP_PHY_REPEATER_MODE_NON_TRANSPARENT;
+
+ return drm_dp_dpcd_write(_dp->aux, DP_PHY_REPEATER_MODE, , 1)
== 1;
+}
+
+static void intel_dp_init_lttpr_mode(struct intel_dp *intel_dp)
+{
+ if (intel_dp_is_edp(intel_dp))
+ return;
+
+ /*
+* TODO: the following re-reading of LTTPR caps can be removed
+* after a proper connector HW readout is added.
+*/
+ intel_dp_read_lttpr_caps(intel_dp);
+ intel_dp_set_lttpr_transparent_mode(intel_dp, true);
+}
+
/**
* intel_dp_start_link_train - start link training
* @intel_dp: DP struct
@@ -485,6 +525,8 @@ static void intel_dp_schedule_fallback_link_training(struct
intel_dp *intel_dp)
*/
void intel_dp_start_link_train(struct intel_dp *intel_dp)
{
+ intel_dp_init_lttpr_mode(intel_dp);
+
if (!intel_dp_link_train(intel_dp))
intel_dp_schedule_fallback_link_training(intel_dp);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
index 47c97f4a0d57..c0be3ff709a0 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
@@ -12,6 +12,7 @@ struct intel_dp;
bool intel_dp_get_link_status(struct intel_dp *intel_dp,
u8 link_status[DP_LINK_STATUS_SIZE]);
+void intel_dp_read_lttpr_caps(struct intel_dp *intel_dp);
void intel_dp_get_adjust_train(struct intel_dp *intel_dp,
const u8 link_status[DP_LINK_STATUS_SIZE]);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] [PATCH 7/7] drm/i915: Switch to LTTPR non-transparent mode link training
The DP Standard's recommendation is to use the LTTPR non-transparent
mode link training if LTTPRs are detected, so let's do this.
Besides power-saving, the advantages of this are that the maximum number
of LTTPRs can only be used in non-transparent mode (the limit is 5-8 in
transparent mode), and it provides a way to narrow down the reason for a
link training failure to a given link segment. Non-transparent mode is
probably also the mode that was tested the most by the industry.
The changes in this patchset:
- Pass the DP PHY that is currently link trained to all LT helpers, so
that these can access the correct LTTPR/DPRX DPCD registers.
- During LT take into account the LTTPR common lane rate/count and the
per LTTPR-PHY vswing/pre-emph limits.
- Switch to LTTPR non-transparent LT mode and train each link segment
according to the sequence in DP Standard v2.0 (complete CR/EQ for
each segment before continuing with the next segment).
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 14 +-
.../drm/i915/display/intel_dp_link_training.c | 374 +++---
.../drm/i915/display/intel_dp_link_training.h | 10 +-
4 files changed, 327 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b04921eba73b..2fb4e9a6a316 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1281,6 +1281,7 @@ struct intel_dp {
u8 edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE];
u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE];
u8 lttpr_common_caps[DP_LTTPR_COMMON_CAP_SIZE];
+ u8 lttpr_phy_caps[DP_MAX_LTTPR_COUNT][DP_LTTPR_PHY_CAP_SIZE];
u8 fec_capable;
/* source rates */
int num_source_rates;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index d88f327aa9ef..54ad31044eef 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -161,6 +161,7 @@ static void intel_dp_set_sink_rates(struct intel_dp
*intel_dp)
162000, 27, 54, 81
};
int i, max_rate;
+ int max_lttpr_rate;
if (drm_dp_has_quirk(_dp->desc, 0,
DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS)) {
@@ -174,6 +175,9 @@ static void intel_dp_set_sink_rates(struct intel_dp
*intel_dp)
}
max_rate =
drm_dp_bw_code_to_link_rate(intel_dp->dpcd[DP_MAX_LINK_RATE]);
+ max_lttpr_rate =
drm_dp_lttpr_max_link_rate(intel_dp->lttpr_common_caps);
+ if (max_lttpr_rate)
+ max_rate = min(max_rate, max_lttpr_rate);
for (i = 0; i < ARRAY_SIZE(dp_rates); i++) {
if (dp_rates[i] > max_rate)
@@ -219,6 +223,10 @@ static int intel_dp_max_common_lane_count(struct intel_dp
*intel_dp)
int source_max = dig_port->max_lanes;
int sink_max = drm_dp_max_lane_count(intel_dp->dpcd);
int fia_max = intel_tc_port_fia_max_lane_count(dig_port);
+ int lttpr_max =
drm_dp_lttpr_max_lane_count(intel_dp->lttpr_common_caps);
+
+ if (lttpr_max)
+ sink_max = min(sink_max, lttpr_max);
return min3(source_max, sink_max, fia_max);
}
@@ -5540,13 +5548,13 @@ void intel_dp_process_phy_request(struct intel_dp
*intel_dp)
_dp->compliance.test_data.phytest;
u8 link_status[DP_LINK_STATUS_SIZE];
- if (!intel_dp_get_link_status(intel_dp, link_status)) {
+ if (!intel_dp_get_link_status(intel_dp, DP_PHY_DPRX, link_status)) {
DRM_DEBUG_KMS("failed to get link status\n");
return;
}
/* retrieve vswing & pre-emphasis setting */
- intel_dp_get_adjust_train(intel_dp, link_status);
+ intel_dp_get_adjust_train(intel_dp, DP_PHY_DPRX, link_status);
intel_dp_autotest_phy_ddi_disable(intel_dp);
@@ -5701,7 +5709,7 @@ intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
if (intel_psr_enabled(intel_dp))
return false;
- if (!intel_dp_get_link_status(intel_dp, link_status))
+ if (!intel_dp_get_link_status(intel_dp, DP_PHY_DPRX, link_status))
return false;
/*
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 1485602659be..3aa685a9aa2a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -25,6 +25,8 @@
#include "intel_dp.h"
#include "intel_dp_link_training.h"
+#define DP_PHY_LTTPR(i)(DP_PHY_LTTPR1 + (i))
+
static void
intel_dp_dump_link_status(const u8 link_status[DP_LINK_STATUS_SIZE])
{
@@ -35,37 +37,140 @@ intel_dp_dump_link_status(const u8
link_status[DP_LINK_STATUS_SIZE])
}
/**
- *
[Intel-gfx] [PATCH 1/7] drm/i915: Fix DP link training pattern mask
An LTTPR can be trained with training pattern 4 even if the DPCD
revision is < 1.4, but drm_dp_training_pattern_mask() would change
pattern 4 to pattern 3 on those DPCD revisions.
Since intel_dp_training_pattern() makes already sure that the proper
training pattern is used, all that needs to be masked out is the
scrambling disable flag, which is or'd to the mask later based on the
training pattern.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 +--
drivers/gpu/drm/i915/display/intel_dp.c | 10 +-
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 +-
3 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 4d06178cd76c..946a3b6f2d10 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4158,13 +4158,12 @@ static void intel_ddi_set_link_train(struct intel_dp
*intel_dp,
u8 dp_train_pat)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
- u8 train_pat_mask = drm_dp_training_pattern_mask(intel_dp->dpcd);
u32 temp;
temp = intel_de_read(dev_priv, intel_dp->regs.dp_tp_ctl);
temp &= ~DP_TP_CTL_LINK_TRAIN_MASK;
- switch (dp_train_pat & train_pat_mask) {
+ switch (dp_train_pat & ~DP_LINK_SCRAMBLING_DISABLE) {
case DP_TRAINING_PATTERN_DISABLE:
temp |= DP_TP_CTL_LINK_TRAIN_NORMAL;
break;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index bf1e9cf1c0f3..2a4a9c0e7427 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3778,7 +3778,7 @@ cpt_set_link_train(struct intel_dp *intel_dp,
*DP &= ~DP_LINK_TRAIN_MASK_CPT;
- switch (dp_train_pat & DP_TRAINING_PATTERN_MASK) {
+ switch (dp_train_pat & ~DP_LINK_SCRAMBLING_DISABLE) {
case DP_TRAINING_PATTERN_DISABLE:
*DP |= DP_LINK_TRAIN_OFF_CPT;
break;
@@ -3808,7 +3808,7 @@ g4x_set_link_train(struct intel_dp *intel_dp,
*DP &= ~DP_LINK_TRAIN_MASK;
- switch (dp_train_pat & DP_TRAINING_PATTERN_MASK) {
+ switch (dp_train_pat & ~DP_LINK_SCRAMBLING_DISABLE) {
case DP_TRAINING_PATTERN_DISABLE:
*DP |= DP_LINK_TRAIN_OFF;
break;
@@ -4498,12 +4498,12 @@ intel_dp_program_link_training_pattern(struct intel_dp
*intel_dp,
u8 dp_train_pat)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
- u8 train_pat_mask = drm_dp_training_pattern_mask(intel_dp->dpcd);
- if (dp_train_pat & train_pat_mask)
+ if ((dp_train_pat & ~DP_LINK_SCRAMBLING_DISABLE) !=
+ DP_TRAINING_PATTERN_DISABLE)
drm_dbg_kms(_priv->drm,
"Using DP training pattern TPS%d\n",
- dp_train_pat & train_pat_mask);
+ dp_train_pat & ~DP_LINK_SCRAMBLING_DISABLE);
intel_dp->set_link_train(intel_dp, dp_train_pat);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index f2c8b56be9ea..f8b53c5b5777 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -96,7 +96,7 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
intel_dp_program_link_training_pattern(intel_dp, dp_train_pat);
buf[0] = dp_train_pat;
- if ((dp_train_pat & DP_TRAINING_PATTERN_MASK) ==
+ if ((dp_train_pat & ~DP_LINK_SCRAMBLING_DISABLE) ==
DP_TRAINING_PATTERN_DISABLE) {
/* don't write DP_TRAINING_LANEx_SET on disable */
len = 1;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/7] drm/i915: Simplify the link training functions
Split the prepare, link training, fallback-handling steps into their own
functions for clarity and as a preparation for the upcoming LTTPR changes.
While at it also add some documentation to exported functions.
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_dp_link_training.c | 80 ++-
1 file changed, 62 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 6d13d00db5e6..0c3809891bd2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -162,14 +162,13 @@ static bool intel_dp_link_max_vswing_reached(struct
intel_dp *intel_dp)
return true;
}
-/* Enable corresponding port and start training pattern 1 */
-static bool
-intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
+/*
+ * Prepare link training by configuring the link parameters and enabling the
+ * corresponding port.
+ */
+static void intel_dp_prepare_link_train(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
- u8 voltage;
- int voltage_tries, cr_tries, max_cr_tries;
- bool max_vswing_reached = false;
u8 link_config[2];
u8 link_bw, rate_select;
@@ -203,6 +202,16 @@ intel_dp_link_training_clock_recovery(struct intel_dp
*intel_dp)
drm_dp_dpcd_write(_dp->aux, DP_DOWNSPREAD_CTRL, link_config, 2);
intel_dp->DP |= DP_PORT_EN;
+}
+
+/* Perform the link training clock recovery phase using training pattern 1. */
+static bool
+intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
+{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ u8 voltage;
+ int voltage_tries, cr_tries, max_cr_tries;
+ bool max_vswing_reached = false;
/* clock recovery */
if (!intel_dp_reset_link_train(intel_dp,
@@ -325,6 +334,10 @@ static u32 intel_dp_training_pattern(struct intel_dp
*intel_dp)
return DP_TRAINING_PATTERN_2;
}
+/*
+ * Perform the link training channel equalization phase using one of training
+ * pattern 2, 3 or 4 depending on the the source and sink capabilities.
+ */
static bool
intel_dp_link_training_channel_equalization(struct intel_dp *intel_dp)
{
@@ -395,6 +408,15 @@ intel_dp_link_training_channel_equalization(struct
intel_dp *intel_dp)
}
+/**
+ * intel_dp_stop_link_train - stop link training
+ * @intel_dp: DP struct
+ *
+ * Stop the link training of the @intel_dp port, programming the port to
+ * output an idle pattern on the link and disabling the training pattern in
+ * the sink's DPCD.
+ * This function must be called after intel_dp_start_link_train().
+ */
void intel_dp_stop_link_train(struct intel_dp *intel_dp)
{
intel_dp->link_trained = true;
@@ -403,30 +425,37 @@ void intel_dp_stop_link_train(struct intel_dp *intel_dp)
DP_TRAINING_PATTERN_DISABLE);
}
-void
-intel_dp_start_link_train(struct intel_dp *intel_dp)
+static bool
+intel_dp_link_train(struct intel_dp *intel_dp)
{
struct intel_connector *intel_connector = intel_dp->attached_connector;
+ bool ret = false;
+
+ intel_dp_prepare_link_train(intel_dp);
if (!intel_dp_link_training_clock_recovery(intel_dp))
- goto failure_handling;
+ goto out;
+
if (!intel_dp_link_training_channel_equalization(intel_dp))
- goto failure_handling;
+ goto out;
- drm_dbg_kms(_to_i915(intel_dp)->drm,
- "[CONNECTOR:%d:%s] Link Training Passed at Link Rate = %d,
Lane count = %d",
- intel_connector->base.base.id,
- intel_connector->base.name,
- intel_dp->link_rate, intel_dp->lane_count);
- return;
+ ret = true;
- failure_handling:
+out:
drm_dbg_kms(_to_i915(intel_dp)->drm,
- "[CONNECTOR:%d:%s] Link Training failed at link rate = %d,
lane count = %d",
+ "[CONNECTOR:%d:%s] Link Training %s at Link Rate = %d, Lane
count = %d",
intel_connector->base.base.id,
intel_connector->base.name,
+ ret ? "passed" : "failed",
intel_dp->link_rate, intel_dp->lane_count);
+ return ret;
+}
+
+static void intel_dp_schedule_fallback_link_training(struct intel_dp *intel_dp)
+{
+ struct intel_connector *intel_connector = intel_dp->attached_connector;
+
if (intel_dp->hobl_active) {
drm_dbg_kms(_to_i915(intel_dp)->drm,
"Link Training failed with HOBL active, not
enabling it from now on");
@@ -440,3 +469,18 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
/* Schedule a Hotplug Uevent to userspace to start modeset */
schedule_work(_connector->modeset_retry_work);
}
+
+/**
+ * intel_dp_start_link_train - start
[Intel-gfx] [PATCH 4/7] drm/i915: Factor out a helper to disable the DPCD training pattern
To prepare for a follow-up LTTPR change factor out a helper to disable
the training pattern in DPCD. We'll need to do this for each LTTPR
(without programming the port to output the idle pattern) when training
in LTTPR non-transparent mode.
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_dp_link_training.c | 28 +++
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 0c3809891bd2..6994a32244dc 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -102,30 +102,34 @@ void intel_dp_get_adjust_train(struct intel_dp *intel_dp,
intel_dp->train_set[lane] = v | p;
}
+static bool intel_dp_disable_dpcd_training_pattern(struct intel_dp *intel_dp)
+{
+ u8 val = DP_TRAINING_PATTERN_DISABLE;
+
+ return drm_dp_dpcd_write(_dp->aux, DP_TRAINING_PATTERN_SET, ,
1) == 1;
+}
+
static bool
intel_dp_set_link_train(struct intel_dp *intel_dp,
u8 dp_train_pat)
{
u8 buf[sizeof(intel_dp->train_set) + 1];
- int ret, len;
+ int len;
intel_dp_program_link_training_pattern(intel_dp, dp_train_pat);
- buf[0] = dp_train_pat;
if ((dp_train_pat & ~DP_LINK_SCRAMBLING_DISABLE) ==
- DP_TRAINING_PATTERN_DISABLE) {
+ DP_TRAINING_PATTERN_DISABLE)
/* don't write DP_TRAINING_LANEx_SET on disable */
- len = 1;
- } else {
- /* DP_TRAINING_LANEx_SET follow DP_TRAINING_PATTERN_SET */
- memcpy(buf + 1, intel_dp->train_set, intel_dp->lane_count);
- len = intel_dp->lane_count + 1;
- }
+ return intel_dp_disable_dpcd_training_pattern(intel_dp);
- ret = drm_dp_dpcd_write(_dp->aux, DP_TRAINING_PATTERN_SET,
- buf, len);
+ buf[0] = dp_train_pat;
+ /* DP_TRAINING_LANEx_SET follow DP_TRAINING_PATTERN_SET */
+ memcpy(buf + 1, intel_dp->train_set, intel_dp->lane_count);
+ len = intel_dp->lane_count + 1;
- return ret == len;
+ return drm_dp_dpcd_write(_dp->aux, DP_TRAINING_PATTERN_SET,
+buf, len) == len;
}
static bool
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/7] drm/i915: Move intel_dp_get_link_status to intel_dp_link_training.c
The link status is used to communicate the parameters of the link
training with the DPRX and determine if the link training is successful
or a retraining is needed. Accordingly move the function to read the
link status to intel_dp_link_training.c
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 11 ---
drivers/gpu/drm/i915/display/intel_dp.h | 2 --
.../drm/i915/display/intel_dp_link_training.c| 16
.../drm/i915/display/intel_dp_link_training.h| 3 +++
4 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 2a4a9c0e7427..ee93a00a4d5e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4126,17 +4126,6 @@ static void chv_dp_post_pll_disable(struct
intel_atomic_state *state,
chv_phy_post_pll_disable(encoder, old_crtc_state);
}
-/*
- * Fetch AUX CH registers 0x202 - 0x207 which contain
- * link status information
- */
-bool
-intel_dp_get_link_status(struct intel_dp *intel_dp, u8
link_status[DP_LINK_STATUS_SIZE])
-{
- return drm_dp_dpcd_read(_dp->aux, DP_LANE0_1_STATUS, link_status,
- DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
-}
-
static u8 intel_dp_voltage_max_2(struct intel_dp *intel_dp)
{
return DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index 08a1c0aa8b94..34ae7988a554 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -100,8 +100,6 @@ void intel_dp_compute_rate(struct intel_dp *intel_dp, int
port_clock,
u8 *link_bw, u8 *rate_select);
bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp);
bool intel_dp_source_supports_hbr3(struct intel_dp *intel_dp);
-bool
-intel_dp_get_link_status(struct intel_dp *intel_dp, u8 *link_status);
bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp);
int intel_dp_link_required(int pixel_clock, int bpp);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index f8b53c5b5777..6d13d00db5e6 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -34,6 +34,22 @@ intel_dp_dump_link_status(const u8
link_status[DP_LINK_STATUS_SIZE])
link_status[3], link_status[4], link_status[5]);
}
+/**
+ * intel_dp_get_link_status - get the link status information for the DPRX
+ * @intel_dp: DP struct
+ * @link_status: buffer to return the status in
+ *
+ * Fetch the AUX DPCD registers for the DPRX link status.
+ *
+ * Returns true if the information was read successfully, false otherwise.
+ */
+bool
+intel_dp_get_link_status(struct intel_dp *intel_dp, u8
link_status[DP_LINK_STATUS_SIZE])
+{
+ return drm_dp_dpcd_read(_dp->aux, DP_LANE0_1_STATUS, link_status,
+ DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
+}
+
static u8 dp_voltage_max(u8 preemph)
{
switch (preemph & DP_TRAIN_PRE_EMPHASIS_MASK) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
index 01f1dabbb060..47c97f4a0d57 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
@@ -10,6 +10,9 @@
struct intel_dp;
+bool intel_dp_get_link_status(struct intel_dp *intel_dp,
+ u8 link_status[DP_LINK_STATUS_SIZE]);
+
void intel_dp_get_adjust_train(struct intel_dp *intel_dp,
const u8 link_status[DP_LINK_STATUS_SIZE]);
void intel_dp_start_link_train(struct intel_dp *intel_dp);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/7] drm/i915: Add support for LTTPR non-transparent link training mode
Add the drm-core helpers and register definitions required to detect LTTPRs and perform the link training in non-transparent mode. In i915 switch to non-transparent link training mode if any LTTPR is detected. Cc: dri-de...@lists.freedesktop.org Imre Deak (7): drm/i915: Fix DP link training pattern mask drm/i915: Move intel_dp_get_link_status to intel_dp_link_training.c drm/i915: Simplify the link training functions drm/i915: Factor out a helper to disable the DPCD training pattern drm/dp: Add LTTPR helpers drm/i915: Switch to LTTPR transparent mode link training drm/i915: Switch to LTTPR non-transparent mode link training drivers/gpu/drm/drm_dp_helper.c | 179 ++- drivers/gpu/drm/i915/display/intel_ddi.c | 3 +- .../drm/i915/display/intel_display_types.h| 2 + drivers/gpu/drm/i915/display/intel_dp.c | 38 +- drivers/gpu/drm/i915/display/intel_dp.h | 2 - .../drm/i915/display/intel_dp_link_training.c | 492 +++--- .../drm/i915/display/intel_dp_link_training.h | 10 +- include/drm/drm_dp_helper.h | 56 ++ 8 files changed, 682 insertions(+), 100 deletions(-) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] topic/gvt-ww-lock
Hi, Here's the patch which introduces GVT-g ww lock support against drm-intel-gt-next branch. Thanks -- The following changes since commit 4316b19dee27cc5cd34a95fdbc0a3a5237507701: drm/i915: Fix uninitialised variable in intel_context_create_request. (2020-09-21 11:09:46 +0200) are available in the git repository at: https://github.com/intel/gvt-linux.git tags/gvt-ww-lock-09-22-2020 for you to fetch changes up to e1b49ae155451aaa039eeb23fce808c71a038283: drm/i915/gvt: Introduce per object locking in GVT scheduler. (2020-09-22 12:09:56 +0300) gvt-ww-lock-09-22-2020: - Introduce ww lock support into GVT-g. Zhi Wang (1): drm/i915/gvt: Introduce per object locking in GVT scheduler. drivers/gpu/drm/i915/gvt/scheduler.c | 68 ++-- 1 file changed, 57 insertions(+), 11 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: use vmap in shmem_pin_map
On Tue, Sep 22, 2020 at 08:22:49AM +0200, Christoph Hellwig wrote: > On Mon, Sep 21, 2020 at 08:11:57PM +0100, Matthew Wilcox wrote: > > This is awkward. I'd like it if we had a vfree() variant which called > > put_page() instead of __free_pages(). I'd like it even more if we > > used release_pages() instead of our own loop that called put_page(). > > Note that we don't need a new vfree variant, we can do this manually if > we want, take a look at kernel/dma/remap.c. But I thought this code > intentionally doesn't want to do that to avoid locking in the memory > for the pages array. Maybe the i915 maintainers can clarify. Actually, vfree() will work today; I cc'd you on a documentation update to make it clear that this is permitted. >From my current experience with the i915 shmem code, I think that the i915 maintainers are experts at graphics, and are unfamiliar with the MM. There are a number of places where they do things the hard way. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 10/11] drm/i915: Add intel_update_bigjoiner handling.
On Mon, Sep 21, 2020 at 02:18:33PM -0700, Navare, Manasi wrote:
> On Mon, Sep 14, 2020 at 12:21:26PM -0700, Navare, Manasi wrote:
> > On Thu, Sep 03, 2020 at 10:23:35PM +0300, Ville Syrjälä wrote:
> > > On Wed, Jul 15, 2020 at 03:42:21PM -0700, Manasi Navare wrote:
> > > > From: Maarten Lankhorst
> > > >
> > > > Enabling is done in a special sequence and so should plane updates
> > > > be. Ideally the end user never notices the second pipe is used,
> > > > so use the vblank evasion to cover both pipes.
> > > >
> > > > This way ideally everything will be tear free, and updates are
> > > > really atomic as userspace expects it.
> > > >
> > > > This needs to be checked if it still works since lot of refactoring
> > > > in skl_commit_modeset_enables
> > > >
> > > > v2:
> > > > * Manual Rebase (Manasi)
> > > > * Refactoring on intel_update_crtc and enable_crtc and removing
> > > > special trans_port_sync_update (Manasi)
> > > >
> > > > Signed-off-by: Maarten Lankhorst
> > > > Signed-off-by: Manasi Navare
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_display.c | 120 +--
> > > > drivers/gpu/drm/i915/display/intel_sprite.c | 25 +++-
> > > > drivers/gpu/drm/i915/display/intel_sprite.h | 3 +-
> > > > 3 files changed, 129 insertions(+), 19 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > index a1011414da6d..00b26863ffc6 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > @@ -15656,7 +15656,7 @@ static void intel_update_crtc(struct
> > > > intel_atomic_state *state,
> > > > else
> > > > i9xx_update_planes_on_crtc(state, crtc);
> > > >
> > > > - intel_pipe_update_end(new_crtc_state);
> > > > + intel_pipe_update_end(new_crtc_state, NULL);
> > > >
> > > > /*
> > > > * We usually enable FIFO underrun interrupts as part of the
> > > > @@ -15754,6 +15754,52 @@ static void
> > > > intel_commit_modeset_disables(struct intel_atomic_state *state)
> > > > }
> > > > }
> > > >
> > > > +static void intel_update_bigjoiner(struct intel_crtc *crtc,
> > > > + struct intel_atomic_state *state,
> > > > + struct intel_crtc_state
> > > > *old_crtc_state,
> > > > + struct intel_crtc_state
> > > > *new_crtc_state)
> > > > +{
> > > > + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > > > + bool modeset = needs_modeset(new_crtc_state);
> > > > + struct intel_crtc *slave =
> > > > new_crtc_state->bigjoiner_linked_crtc;
> > > > + struct intel_crtc_state *new_slave_crtc_state =
> > > > + intel_atomic_get_new_crtc_state(state, slave);
> > > > +
> > > > + if (modeset) {
> > > > + /* Enable slave first */
> > > > + intel_crtc_update_active_timings(new_slave_crtc_state);
> > > > + dev_priv->display.crtc_enable(state, slave);
> > > > +
> > > > + /* Then master */
> > > > + intel_crtc_update_active_timings(new_crtc_state);
> > > > + dev_priv->display.crtc_enable(state, crtc);
> > > > +
> > > > + /* vblanks work again, re-enable pipe CRC. */
> > > > + intel_crtc_enable_pipe_crc(crtc);
> > > > +
> > > > + } else {
> > > > + intel_pre_plane_update(state, crtc);
> > > > + intel_pre_plane_update(state, slave);
> > > > +
> > > > + if (new_crtc_state->update_pipe)
> > > > + intel_encoders_update_pipe(state, crtc);
> > > > + }
> > > > +
> > > > + /*
> > > > +* Perform vblank evasion around commit operation, and make
> > > > sure to
> > > > +* commit both planes simultaneously for best results.
> > > > +*/
> > > > + intel_pipe_update_start(new_crtc_state);
> > > > +
> > > > + commit_pipe_config(state, crtc);
> > > > + commit_pipe_config(state, slave);
> > > > +
> > > > + skl_update_planes_on_crtc(state, crtc);
> > > > + skl_update_planes_on_crtc(state, slave);
> > > > +
> > > > + intel_pipe_update_end(new_crtc_state, new_slave_crtc_state);
> > > > +}
> > >
> > > I think this should ideally all go away and just the normal logic
> > > in commit_modeset_enables() should deal with it. Just like it does
> > > for port sync/mst pipe dependencies.
> > >
> >
> > Yes I think so too. Except for the intel_pipe_update_end where
> > now we send the new_slave_crtc_state() so thats still something I need to
> > figure
> > how it will work in normal code without special bigjoiner handling.
> >
> > I think the 2p2p transcoder ports sync code initially had a special trans
> > port sync handling
> > function and thats why this was written this way but with the new code
Re: [Intel-gfx] [PATCH v6 02/11] drm/i915: Remove hw.mode
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, ); 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. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH v2 2/2] drm/i915: Introduce a i915_gem_do_ww(){} utility
On 17/09/2020 19:59, Thomas Hellström (Intel) wrote:
From: Thomas Hellström
With the huge number of sites where multiple-object locking is
needed in the driver, it becomes difficult to avoid recursive
ww_acquire_ctx initialization, and the function prototypes become
bloated passing the ww_acquire_ctx around. Furthermore it's not
always easy to get the -EDEADLK handling correct and to follow it.
Introduce a i915_gem_do_ww utility that tries to remedy all these problems
by enclosing parts of a ww transaction in the following way:
my_function() {
struct i915_gem_ww_ctx *ww, template;
int err;
bool interruptible = true;
i915_do_ww(ww, , err, interruptible) {
err = ww_transaction_part(ww);
}
return err;
}
The utility will automatically look up an active ww_acquire_ctx if one
is initialized previously in the call chain, and if one found will
forward the -EDEADLK instead of handling it, which takes care of the
recursive initalization. Using the utility also discourages nested ww
unlocking / relocking that is both very fragile and hard to follow.
To look up and register an active ww_acquire_ctx, use a
driver-wide hash table for now. But noting that a task could only have
a single active ww_acqurie_ctx per ww_class, the active CTX is really
task state and a generic version of this utility in the ww_mutex code
could thus probably use a quick lookup from a list in the
struct task_struct.
Maybe a stupid question, but is it safe to assume process context is the
only entry point to a ww transaction? I guess I was thinking about
things like background scrub/migrate threads, but yes, they would be
threads so would work. Other than those I have no ideas who could need
locking multiple objects so from this aspect it looks okay.
But it is kind of neat to avoid changing deep hierarchies of function
prototypes.
My concern is that the approach isn't to "magicky"? I mean too hidden
and too stateful, and that some unwanted surprises could be coming in
use with this model. But it is a very vague feeling at this point so
don't know.
I also worry that if the graphics subsystem would start thinking it is
so special that it needs dedicated handling in task_struct, that it
might make it (subsystem) sound a bit pretentious. I had a quick browse
through struct task_struct and couldn't spot any precedent to such
things so I don't know what core kernel would say.
Regards,
Tvrtko
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_gem_ww.c | 74 -
drivers/gpu/drm/i915/i915_gem_ww.h | 56 +-
drivers/gpu/drm/i915/i915_globals.c | 1 +
drivers/gpu/drm/i915/i915_globals.h | 1 +
4 files changed, 130 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_ww.c
b/drivers/gpu/drm/i915/i915_gem_ww.c
index 3490b72cf613..6247af1dba87 100644
--- a/drivers/gpu/drm/i915/i915_gem_ww.c
+++ b/drivers/gpu/drm/i915/i915_gem_ww.c
@@ -1,10 +1,12 @@
// SPDX-License-Identifier: MIT
/*
- * Copyright © 2020 Intel Corporation
+ * Copyright © 2019 Intel Corporation
*/
+#include
#include
#include
#include "i915_gem_ww.h"
+#include "i915_globals.h"
#include "gem/i915_gem_object.h"
void i915_gem_ww_ctx_init(struct i915_gem_ww_ctx *ww, bool intr)
@@ -70,3 +72,73 @@ int __must_check i915_gem_ww_ctx_backoff(struct
i915_gem_ww_ctx *ww)
return ret;
}
+
+static struct rhashtable ww_ht;
+static const struct rhashtable_params ww_params = {
+ .key_len = sizeof(struct task_struct *),
+ .key_offset = offsetof(struct i915_gem_ww_ctx, ctx.task),
+ .head_offset = offsetof(struct i915_gem_ww_ctx, head),
+ .min_size = 128,
+};
+
+static void i915_ww_item_free(void *ptr, void *arg)
+{
+ WARN_ON_ONCE(1);
+}
+
+static void i915_global_ww_exit(void)
+{
+ rhashtable_free_and_destroy(_ht, i915_ww_item_free, NULL);
+}
+
+static void i915_global_ww_shrink(void)
+{
+}
+
+static struct i915_global global = {
+ .shrink = i915_global_ww_shrink,
+ .exit = i915_global_ww_exit,
+};
+
+int __init i915_global_ww_init(void)
+{
+ int ret = rhashtable_init(_ht, _params);
+
+ if (ret)
+ return ret;
+
+ i915_global_register();
+
+ return 0;
+}
+
+void __i915_gem_ww_mark_unused(struct i915_gem_ww_ctx *ww)
+{
+ GEM_WARN_ON(rhashtable_remove_fast(_ht, >head, ww_params));
+}
+
+/**
+ * __i915_gem_ww_locate_or_use - return the task's i915_gem_ww_ctx context
+ * to use.
+ *
+ * @template: The context to use if there was none initialized previously
+ * in the call chain.
+ *
+ * RETURN: The task's i915_gem_ww_ctx context.
+ */
+struct i915_gem_ww_ctx *
+__i915_gem_ww_locate_or_use(struct i915_gem_ww_ctx *template)
+{
+ struct i915_gem_ww_ctx *tmp;
+
+ /* ctx.task is the hash key, so set it first. */
+ template->ctx.task = current;
+
+ /*
+* Ideally we'd just hook the
[Intel-gfx] [PATCH rdma-next v3 1/2] lib/scatterlist: Add support in dynamic allocation of SG table from pages
From: Maor Gottlieb
Extend __sg_alloc_table_from_pages to support dynamic allocation of
SG table from pages. It should be used by drivers that can't supply
all the pages at one time.
This function returns the last populated SGE in the table. Users should
pass it as an argument to the function from the second call and forward.
As before, nents will be equal to the number of populated SGEs (chunks).
With this new extension, drivers can benefit the optimization of merging
contiguous pages without a need to allocate all pages in advance and
hold them in a large buffer.
E.g. with the Infiniband driver that allocates a single page for hold
the
pages. For 1TB memory registration, the temporary buffer would consume
only
4KB, instead of 2GB.
Signed-off-by: Maor Gottlieb
Signed-off-by: Leon Romanovsky
---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 12 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 15 +-
include/linux/scatterlist.h | 43 +++---
lib/scatterlist.c | 158 +++-
lib/sg_pool.c | 3 +-
tools/testing/scatterlist/main.c| 9 +-
6 files changed, 163 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index 12b30075134a..f2eaed6aca3d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -403,6 +403,7 @@ __i915_gem_userptr_alloc_pages(struct drm_i915_gem_object
*obj,
unsigned int max_segment = i915_sg_segment_size();
struct sg_table *st;
unsigned int sg_page_sizes;
+ struct scatterlist *sg;
int ret;
st = kmalloc(sizeof(*st), GFP_KERNEL);
@@ -410,13 +411,12 @@ __i915_gem_userptr_alloc_pages(struct drm_i915_gem_object
*obj,
return ERR_PTR(-ENOMEM);
alloc_table:
- ret = __sg_alloc_table_from_pages(st, pvec, num_pages,
- 0, num_pages << PAGE_SHIFT,
- max_segment,
- GFP_KERNEL);
- if (ret) {
+ sg = __sg_alloc_table_from_pages(st, pvec, num_pages, 0,
+num_pages << PAGE_SHIFT, max_segment,
+NULL, 0, GFP_KERNEL);
+ if (IS_ERR(sg)) {
kfree(st);
- return ERR_PTR(ret);
+ return ERR_CAST(sg);
}
ret = i915_gem_gtt_prepare_pages(obj, st);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index ab524ab3b0b4..f22acd398b1f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -419,6 +419,7 @@ static int vmw_ttm_map_dma(struct vmw_ttm_tt *vmw_tt)
int ret = 0;
static size_t sgl_size;
static size_t sgt_size;
+ struct scatterlist *sg;
if (vmw_tt->mapped)
return 0;
@@ -441,13 +442,15 @@ static int vmw_ttm_map_dma(struct vmw_ttm_tt *vmw_tt)
if (unlikely(ret != 0))
return ret;
- ret = __sg_alloc_table_from_pages
- (_tt->sgt, vsgt->pages, vsgt->num_pages, 0,
-(unsigned long) vsgt->num_pages << PAGE_SHIFT,
-dma_get_max_seg_size(dev_priv->dev->dev),
-GFP_KERNEL);
- if (unlikely(ret != 0))
+ sg = __sg_alloc_table_from_pages(_tt->sgt, vsgt->pages,
+ vsgt->num_pages, 0,
+ (unsigned long) vsgt->num_pages << PAGE_SHIFT,
+ dma_get_max_seg_size(dev_priv->dev->dev),
+ NULL, 0, GFP_KERNEL);
+ if (IS_ERR(sg)) {
+ ret = PTR_ERR(sg);
goto out_sg_alloc_fail;
+ }
if (vsgt->num_pages > vmw_tt->sgt.nents) {
uint64_t over_alloc =
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index 45cf7b69d852..c24cc667b56b 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -165,6 +165,22 @@ static inline void sg_set_buf(struct scatterlist *sg,
const void *buf,
#define for_each_sgtable_dma_sg(sgt, sg, i)\
for_each_sg((sgt)->sgl, sg, (sgt)->nents, i)
+static inline void __sg_chain(struct scatterlist *chain_sg,
+ struct scatterlist *sgl)
+{
+ /*
+* offset and length are unused for chain entry. Clear them.
+*/
+ chain_sg->offset = 0;
+ chain_sg->length = 0;
+
+ /*
+* Set lowest bit to indicate a link pointer, and make sure to clear
+* the termination bit if it happens to be set.
+*/
+ chain_sg->page_link = ((unsigned long) sgl | SG_CHAIN) & ~SG_END;
[Intel-gfx] [PATCH rdma-next v3 0/2] Dynamicaly allocate SG table from the pages
From: Leon Romanovsky Changelog: v3: * Squashed Christopher's suggestion to avoid introduced new API, but extend existing one. v2: https://lore.kernel.org/linux-rdma/20200916140726.839377-1-l...@kernel.org * Fixed indentations and comments * Deleted sg_alloc_next() * Squashed lib/scatterlist patches into one v1: https://lore.kernel.org/lkml/20200910134259.1304543-1-l...@kernel.org * Changed _sg_chain to be __sg_chain * Added dependency on ARCH_NO_SG_CHAIN * Removed struct sg_append v0: * https://lore.kernel.org/lkml/20200903121853.1145976-1-l...@kernel.org -- >From Maor: This series extends __sg_alloc_table_from_pages to allow chaining of new pages to already initialized SG table. This allows drivers to utilize the optimization of merging contiguous pages without a need to pre allocate all the pages and hold them in a very large temporary buffer prior to the call to SG table initialization. The second patch changes the Infiniband driver to use the new API. It removes duplicate functionality from the code and benefits the optimization of allocating dynamic SG table from pages. In huge pages system of 2MB page size, without this change, the SG table would contain x512 SG entries. E.g. for 100GB memory registration: Number of entries Size Before26214400 600.0MB After512001.2MB Thanks Maor Gottlieb (2): lib/scatterlist: Add support in dynamic allocation of SG table from pages RDMA/umem: Move to allocate SG table from pages drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 12 +- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 15 +- drivers/infiniband/core/umem.c | 92 ++-- include/linux/scatterlist.h | 43 +++--- lib/scatterlist.c | 158 +++- lib/sg_pool.c | 3 +- tools/testing/scatterlist/main.c| 9 +- 7 files changed, 175 insertions(+), 157 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 3/6] drm/i915: use vmap in shmem_pin_map
On 22/09/2020 07:22, Christoph Hellwig wrote: On Mon, Sep 21, 2020 at 08:11:57PM +0100, Matthew Wilcox wrote: This is awkward. I'd like it if we had a vfree() variant which called put_page() instead of __free_pages(). I'd like it even more if we used release_pages() instead of our own loop that called put_page(). Note that we don't need a new vfree variant, we can do this manually if we want, take a look at kernel/dma/remap.c. But I thought this code intentionally doesn't want to do that to avoid locking in the memory for the pages array. Maybe the i915 maintainers can clarify. + Chris & Matt who were involved with this part of i915. If I understood this sub-thread correctly, iterating and freeing the pages via the vmapped ptes, so no need for a shmem_read_mapping_page_gfp loop in shmem_unpin_map looks plausible to me. I did not get the reference to kernel/dma/remap.c though, and also not sure how to do the error unwind path in shmem_pin_map at which point the allocated vm area hasn't been fully populated yet. Hand-roll the loop walking vm area struct in there? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: use vmap in shmem_pin_map
On Mon, Sep 21, 2020 at 08:11:57PM +0100, Matthew Wilcox wrote: > This is awkward. I'd like it if we had a vfree() variant which called > put_page() instead of __free_pages(). I'd like it even more if we > used release_pages() instead of our own loop that called put_page(). Note that we don't need a new vfree variant, we can do this manually if we want, take a look at kernel/dma/remap.c. But I thought this code intentionally doesn't want to do that to avoid locking in the memory for the pages array. Maybe the i915 maintainers can clarify. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
