Re: [Intel-gfx] remove alloc_vm_area v2
On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig wrote: > this series removes alloc_vm_area, which was left over from the big > vmalloc interface rework. It is a rather arkane interface, basicaly > the equivalent of get_vm_area + actually faulting in all PTEs in > the allocated area. It was originally addeds for Xen (which isn't > modular to start with), and then grew users in zsmalloc and i915 > which seems to mostly qualify as abuses of the interface, especially > for i915 as a random driver should not set up PTE bits directly. > > Note that the i915 patches apply to the drm-tip branch of the drm-tip > tree, as that tree has recent conflicting commits in the same area. Is the drm-tip material in linux-next yet? I'm still seeing a non-trivial reject in there at present. ___ 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/guc: Update to GuC v49
== Series Details ==
Series: drm/i915/guc: Update to GuC v49
URL : https://patchwork.freedesktop.org/series/82113/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9057_full -> Patchwork_18577_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18577_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18577_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_18577_full:
### IGT changes ###
Possible regressions
* igt@kms_cursor_legacy@pipe-c-torture-bo:
- shard-hsw: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-hsw1/igt@kms_cursor_leg...@pipe-c-torture-bo.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18577/shard-hsw4/igt@kms_cursor_leg...@pipe-c-torture-bo.html
Warnings
* igt@gem_ctx_shared@disjoint-timelines:
- shard-hsw: [SKIP][3] ([fdo#109271]) -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-hsw8/igt@gem_ctx_sha...@disjoint-timelines.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18577/shard-hsw6/igt@gem_ctx_sha...@disjoint-timelines.html
- shard-snb: [SKIP][5] ([fdo#109271]) -> [FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-snb6/igt@gem_ctx_sha...@disjoint-timelines.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18577/shard-snb5/igt@gem_ctx_sha...@disjoint-timelines.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@core_hotunplug@hotrebind-lateclose}:
- shard-iclb: [FAIL][7] ([i915#2476]) -> [DMESG-FAIL][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-iclb6/igt@core_hotunp...@hotrebind-lateclose.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18577/shard-iclb2/igt@core_hotunp...@hotrebind-lateclose.html
Known issues
Here are the changes found in Patchwork_18577_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@psr2:
- shard-iclb: [PASS][9] -> [SKIP][10] ([i915#658])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-iclb2/igt@feature_discov...@psr2.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18577/shard-iclb1/igt@feature_discov...@psr2.html
* igt@gem_flink_race@flink_close:
- shard-iclb: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-iclb4/igt@gem_flink_race@flink_close.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18577/shard-iclb2/igt@gem_flink_race@flink_close.html
* igt@gem_userptr_blits@sync-unmap-cycles:
- shard-skl: [PASS][13] -> [TIMEOUT][14] ([i915#1958] /
[i915#2424])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-skl3/igt@gem_userptr_bl...@sync-unmap-cycles.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18577/shard-skl1/igt@gem_userptr_bl...@sync-unmap-cycles.html
* igt@i915_suspend@fence-restore-untiled:
- shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +2
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-kbl7/igt@i915_susp...@fence-restore-untiled.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18577/shard-kbl6/igt@i915_susp...@fence-restore-untiled.html
* igt@kms_big_fb@yf-tiled-16bpp-rotate-0:
- shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-kbl7/igt@kms_big...@yf-tiled-16bpp-rotate-0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18577/shard-kbl6/igt@kms_big...@yf-tiled-16bpp-rotate-0.html
* igt@kms_cursor_legacy@pipe-d-torture-move:
- shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#128])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-tglb3/igt@kms_cursor_leg...@pipe-d-torture-move.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18577/shard-tglb6/igt@kms_cursor_leg...@pipe-d-torture-move.html
* igt@kms_flip@2x-flip-vs-fences@ab-vga1-hdmi-a1:
- shard-hsw: [PASS][21] -> [DMESG-WARN][22] ([i915#1982])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-hsw8/igt@kms_flip@2x-flip-vs-fen...@ab-vga1-hdmi-a1.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18577/shard-hsw1/igt@kms_flip@2x-flip-vs-fen...@ab-vga1-hdmi-a1.html
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Make intel_{enable, disable}_sagv() static
On Fri, 2020-09-25 at 15:17 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
>
> intel_{enable,disable}_sagv() are no longer needed outside the
> compilation unit. Make them static.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
> ---
> drivers/gpu/drm/i915/intel_pm.c | 4 ++--
> drivers/gpu/drm/i915/intel_pm.h | 2 --
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 34e0d22d456b..8cd62402d597 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3706,7 +3706,7 @@ skl_setup_sagv_block_time(struct drm_i915_private
> *dev_priv)
> * - All planes can enable watermarks for latencies >= SAGV engine block
> time
> * - We're not using an interlaced display configuration
> */
> -int
> +static int
> intel_enable_sagv(struct drm_i915_private *dev_priv)
> {
> int ret;
> @@ -3740,7 +3740,7 @@ intel_enable_sagv(struct drm_i915_private *dev_priv)
> return 0;
> }
>
> -int
> +static int
> intel_disable_sagv(struct drm_i915_private *dev_priv)
> {
> int ret;
> diff --git a/drivers/gpu/drm/i915/intel_pm.h b/drivers/gpu/drm/i915/intel_pm.h
> index a2473594c2db..eab83e251dd5 100644
> --- a/drivers/gpu/drm/i915/intel_pm.h
> +++ b/drivers/gpu/drm/i915/intel_pm.h
> @@ -49,8 +49,6 @@ void g4x_wm_sanitize(struct drm_i915_private *dev_priv);
> void vlv_wm_sanitize(struct drm_i915_private *dev_priv);
> bool intel_can_enable_sagv(struct drm_i915_private *dev_priv,
> const struct intel_bw_state *bw_state);
> -int intel_enable_sagv(struct drm_i915_private *dev_priv);
> -int intel_disable_sagv(struct drm_i915_private *dev_priv);
> void intel_sagv_pre_plane_update(struct intel_atomic_state *state);
> void intel_sagv_post_plane_update(struct intel_atomic_state *state);
> bool skl_wm_level_equals(const struct skl_wm_level *l1,
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Don't hide the intel_crtc_atomic_check() call
On Fri, 2020-09-25 at 15:17 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
>
> Move the intel_crtc_atomic_check() call out from the variable
> declarations to a place where we can actually see it.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 5a9d933e425a..11862de3d772 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14844,8 +14844,10 @@ static int intel_atomic_check_crtcs(struct
> intel_atomic_state *state)
> int i;
>
> for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
> - int ret = intel_crtc_atomic_check(state, crtc);
> struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> + int ret;
> +
> + ret = intel_crtc_atomic_check(state, crtc);
> if (ret) {
> drm_dbg_atomic(>drm,
> "[CRTC:%d:%s] atomic driver check
> failed\n",
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Update to GuC v49
== Series Details ==
Series: drm/i915/guc: Update to GuC v49
URL : https://patchwork.freedesktop.org/series/82113/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9057 -> Patchwork_18577
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_18577 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18577, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18577/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18577:
### IGT changes ###
Warnings
* igt@gem_huc_copy@huc-copy:
- fi-cml-u2: [SKIP][1] ([i915#2190]) -> [SKIP][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-cml-u2/igt@gem_huc_c...@huc-copy.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18577/fi-cml-u2/igt@gem_huc_c...@huc-copy.html
- fi-cml-s: [SKIP][3] ([i915#2190]) -> [SKIP][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-cml-s/igt@gem_huc_c...@huc-copy.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18577/fi-cml-s/igt@gem_huc_c...@huc-copy.html
Known issues
Here are the changes found in Patchwork_18577 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18577/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18577/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [PASS][9] -> [DMESG-WARN][10] ([i915#2203])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18577/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
Possible fixes
* igt@debugfs_test@read_all_entries:
- fi-bsw-nick:[INCOMPLETE][11] ([i915#1250] / [i915#1436]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-bsw-nick/igt@debugfs_test@read_all_entries.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18577/fi-bsw-nick/igt@debugfs_test@read_all_entries.html
* igt@gem_huc_copy@huc-copy:
- fi-tgl-u2: [SKIP][13] ([i915#2190]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-tgl-u2/igt@gem_huc_c...@huc-copy.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18577/fi-tgl-u2/igt@gem_huc_c...@huc-copy.html
- {fi-ehl-1}: [SKIP][15] ([i915#2190]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-ehl-1/igt@gem_huc_c...@huc-copy.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18577/fi-ehl-1/igt@gem_huc_c...@huc-copy.html
- fi-icl-y: [SKIP][17] ([i915#2190]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-icl-y/igt@gem_huc_c...@huc-copy.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18577/fi-icl-y/igt@gem_huc_c...@huc-copy.html
- {fi-tgl-dsi}: [SKIP][19] ([i915#2190]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-tgl-dsi/igt@gem_huc_c...@huc-copy.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18577/fi-tgl-dsi/igt@gem_huc_c...@huc-copy.html
- fi-icl-u2: [SKIP][21] ([i915#2190]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18577/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-bsw-kefka: [INCOMPLETE][23] ([i915#2509]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-bsw-kefka/igt@i915_selftest@live@gt_heartbeat.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18577/fi-bsw-kefka/igt@i915_selftest@live@gt_heartbeat.html
* igt@vgem_basic@unload:
- fi-skl-guc: [DMESG-WARN][25] ([i915#2203]) -> [PASS][26]
[25]:
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/11] mm: update the documentation for vfree (rev2)
== Series Details == Series: series starting with [01/11] mm: update the documentation for vfree (rev2) URL : https://patchwork.freedesktop.org/series/82063/ State : success == Summary == CI Bug Log - changes from CI_DRM_9057_full -> Patchwork_18576_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18576_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@psr2: - shard-iclb: [PASS][1] -> [SKIP][2] ([i915#658]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-iclb2/igt@feature_discov...@psr2.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-iclb8/igt@feature_discov...@psr2.html * igt@gem_userptr_blits@sync-unmap-cycles: - shard-skl: [PASS][3] -> [TIMEOUT][4] ([i915#1958] / [i915#2424]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-skl3/igt@gem_userptr_bl...@sync-unmap-cycles.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-skl1/igt@gem_userptr_bl...@sync-unmap-cycles.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][5] -> [DMESG-WARN][6] ([i915#1436] / [i915#716]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-skl5/igt@gen9_exec_pa...@allowed-single.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-skl3/igt@gen9_exec_pa...@allowed-single.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][7] -> [FAIL][8] ([i915#454]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-iclb8/igt@i915_pm...@dc6-psr.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-iclb4/igt@i915_pm...@dc6-psr.html * igt@i915_selftest@mock@contexts: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([i915#198] / [i915#2278]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-skl4/igt@i915_selftest@m...@contexts.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-skl7/igt@i915_selftest@m...@contexts.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-kbl1/igt@i915_susp...@fence-restore-tiled2untiled.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-kbl4/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([i915#300]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-skl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-skl1/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_flip@2x-flip-vs-dpms-off-vs-modeset-interruptible@ab-vga1-hdmi-a1: - shard-hsw: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-hsw4/igt@kms_flip@2x-flip-vs-dpms-off-vs-modeset-interrupti...@ab-vga1-hdmi-a1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-hsw6/igt@kms_flip@2x-flip-vs-dpms-off-vs-modeset-interrupti...@ab-vga1-hdmi-a1.html * igt@kms_flip@flip-vs-suspend@a-edp1: - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +8 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-skl7/igt@kms_flip@flip-vs-susp...@a-edp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-skl10/igt@kms_flip@flip-vs-susp...@a-edp1.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-pwrite: - shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-kbl2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-pwrite.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-kbl6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-pwrite.html * igt@kms_hdr@bpc-switch-suspend: - shard-kbl: [PASS][21] -> [FAIL][22] ([i915#1188]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-kbl7/igt@kms_...@bpc-switch-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-kbl7/igt@kms_...@bpc-switch-suspend.html * igt@kms_psr2_su@page_flip: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109642] / [fdo#111068]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/shard-iclb2/igt@kms_psr2_su@page_flip.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/shard-iclb7/igt@kms_psr2_su@page_flip.html * igt@kms_psr@psr2_cursor_mmap_cpu: - shard-iclb: [PASS][25] -> [SKIP][26] ([fdo#109441]) +1 similar issue [25]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/guc: Update to GuC v49
== Series Details == Series: drm/i915/guc: Update to GuC v49 URL : https://patchwork.freedesktop.org/series/82113/ State : warning == Summary == $ dim checkpatch origin/drm-tip ea290b73bdf2 drm/i915/guc: Update to use firmware v49.0.1 -:231: WARNING:LONG_LINE: line length of 103 exceeds 100 columns #231: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c:167: + blob->system_info.generic_gt_sysinfo[GUC_GENERIC_GT_SYSINFO_DOORBELL_COUNT_PER_SQIDI] = total: 0 errors, 1 warnings, 0 checks, 445 lines checked 03354ab7bdc3 drm/i915/guc: Improved reporting when GuC fails to load aa99d1545ade drm/i915/guc: Clear pointers on free 81ce9706d11b drm/i915/uc: turn on GuC/HuC auto mode by default ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915/guc: Improved reporting when GuC fails to load
From: John Harrison
Rather than just saying 'GuC failed to load: -110', actually print out
the GuC status register and break it down into the individual fields.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 31 ---
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
index d4a87f4c9421..f9d0907ea1a5 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
@@ -76,6 +76,7 @@ static inline bool guc_ready(struct intel_uncore *uncore, u32
*status)
static int guc_wait_ucode(struct intel_uncore *uncore)
{
+ struct drm_device *drm = >i915->drm;
u32 status;
int ret;
@@ -90,15 +91,27 @@ static int guc_wait_ucode(struct intel_uncore *uncore)
ret = wait_for(guc_ready(uncore, ), 100);
DRM_DEBUG_DRIVER("GuC status %#x\n", status);
- if ((status & GS_BOOTROM_MASK) == GS_BOOTROM_RSA_FAILED) {
- DRM_ERROR("GuC firmware signature verification failed\n");
- ret = -ENOEXEC;
- }
-
- if ((status & GS_UKERNEL_MASK) == GS_UKERNEL_EXCEPTION) {
- DRM_ERROR("GuC firmware exception. EIP: %#x\n",
- intel_uncore_read(uncore, SOFT_SCRATCH(13)));
- ret = -ENXIO;
+ if (ret) {
+ drm_err(drm, "GuC load failed: status = 0x%08X\n", status);
+ drm_err(drm, "GuC load failed: status: Reset = %d, "
+ "BootROM = 0x%02X, UKernel = 0x%02X, "
+ "MIA = 0x%02X, Auth = 0x%02X\n",
+ REG_FIELD_GET(GS_MIA_IN_RESET, status),
+ REG_FIELD_GET(GS_BOOTROM_MASK, status),
+ REG_FIELD_GET(GS_UKERNEL_MASK, status),
+ REG_FIELD_GET(GS_MIA_MASK, status),
+ REG_FIELD_GET(GS_AUTH_STATUS_MASK, status));
+
+ if ((status & GS_BOOTROM_MASK) == GS_BOOTROM_RSA_FAILED) {
+ drm_err(drm, "GuC firmware signature verification
failed\n");
+ ret = -ENOEXEC;
+ }
+
+ if ((status & GS_UKERNEL_MASK) == GS_UKERNEL_EXCEPTION) {
+ drm_err(drm, "GuC firmware exception. EIP: %#x\n",
+ intel_uncore_read(uncore, SOFT_SCRATCH(13)));
+ ret = -ENXIO;
+ }
}
return ret;
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915/uc: turn on GuC/HuC auto mode by default
From: Daniele Ceraolo Spurio This will enable HuC loading for Gen11+ by default if the binaries are available on the system. GuC submission still requires explicit enabling by the user. Signed-off-by: Daniele Ceraolo Spurio Cc: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 330c03e2b4f7..7bdbd8f6ed30 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -58,7 +58,7 @@ struct drm_printer; param(int, disable_power_well, -1, 0400) \ param(int, enable_ips, 1, 0600) \ param(int, invert_brightness, 0, 0600) \ - param(int, enable_guc, 0, 0400) \ + param(int, enable_guc, -1, 0400) \ param(int, guc_log_level, -1, 0400) \ param(char *, guc_firmware_path, NULL, 0400) \ param(char *, huc_firmware_path, NULL, 0400) \ -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915/guc: Update to use firmware v49.0.1
From: John Harrison
The latest GuC firmware includes a number of interface changes that
require driver updates to match.
* Starting from Gen11, the ID to be provided to GuC needs to contain
the engine class in bits [0..2] and the instance in bits [3..6].
NOTE: this patch breaks pointer dereferences in some existing GuC
functions that use the guc_id to dereference arrays but these functions
are not used for now as we have GuC submission disabled and we will
update these functions in follow up patch which requires new IDs.
* The new GuC requires the additional data structure (ADS) and associated
'private_data' pointer to be setup. This is basically a scratch area
of memory that the GuC owns. The size is read from the CSS header.
* There is now a physical to logical engine mapping table in the ADS
which needs to be configured in order for the firmware to load. For
now, the table is initialised with a 1 to 1 mapping.
* GUC_CTL_CTXINFO has been removed from the initialization params.
* reg_state_buffer is maintained internally by the GuC as part of
the private data.
* The ADS layout has changed significantly. This patch updates the
shared structure and also adds better documentation of the layout.
* While i915 does not use GuC doorbells, the firmware now requires
that some initialisation is done.
* The number of engine classes and instances supported in the ADS has
been increased.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Oscar Mateo
Signed-off-by: Michel Thierry
Signed-off-by: Rodrigo Vivi
Signed-off-by: Michal Wajdeczko
Cc: Michal Winiarski
Cc: Tomasz Lis
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 18 ---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 131 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 80 +--
drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h | 5 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 27 ++--
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 6 +-
8 files changed, 176 insertions(+), 96 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 1985772152bf..3fb52fac0d5d 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -305,8 +305,9 @@ static int intel_engine_setup(struct intel_gt *gt, enum
intel_engine_id id)
engine->i915 = i915;
engine->gt = gt;
engine->uncore = gt->uncore;
- engine->hw_id = engine->guc_id = info->hw_id;
engine->mmio_base = __engine_mmio_base(i915, info->mmio_bases);
+ engine->hw_id = info->hw_id;
+ engine->guc_id = MAKE_GUC_ID(info->class, info->instance);
engine->class = info->class;
engine->instance = info->instance;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 942c7c187adb..6909da1e1a73 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -213,23 +213,6 @@ static u32 guc_ctl_feature_flags(struct intel_guc *guc)
return flags;
}
-static u32 guc_ctl_ctxinfo_flags(struct intel_guc *guc)
-{
- u32 flags = 0;
-
- if (intel_guc_submission_is_used(guc)) {
- u32 ctxnum, base;
-
- base = intel_guc_ggtt_offset(guc, guc->stage_desc_pool);
- ctxnum = GUC_MAX_STAGE_DESCRIPTORS / 16;
-
- base >>= PAGE_SHIFT;
- flags |= (base << GUC_CTL_BASE_ADDR_SHIFT) |
- (ctxnum << GUC_CTL_CTXNUM_IN16_SHIFT);
- }
- return flags;
-}
-
static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
{
u32 offset = intel_guc_ggtt_offset(guc, guc->log.vma) >> PAGE_SHIFT;
@@ -291,7 +274,6 @@ static void guc_init_params(struct intel_guc *guc)
BUILD_BUG_ON(sizeof(guc->params) != GUC_CTL_MAX_DWORDS * sizeof(u32));
- params[GUC_CTL_CTXINFO] = guc_ctl_ctxinfo_flags(guc);
params[GUC_CTL_LOG_PARAMS] = guc_ctl_log_params_flags(guc);
params[GUC_CTL_FEATURE] = guc_ctl_feature_flags(guc);
params[GUC_CTL_DEBUG] = guc_ctl_debug_flags(guc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index d44061033f23..7950d28beb8c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -10,11 +10,52 @@
/*
* The Additional Data Struct (ADS) has pointers for different buffers used by
- * the GuC. One single gem object contains the ADS struct itself (guc_ads), the
- * scheduling policies (guc_policies), a structure describing a collection of
- * register sets (guc_mmio_reg_state) and some extra pages for the GuC to save
- * its internal state for sleep.
+ * the GuC. One single gem
[Intel-gfx] [PATCH 0/4] drm/i915/guc: Update to GuC v49
From: John Harrison Update to the latest GuC firmware and enable by default. Signed-off-by: John Harrison Daniele Ceraolo Spurio (1): drm/i915/uc: turn on GuC/HuC auto mode by default John Harrison (3): drm/i915/guc: Update to use firmware v49.0.1 drm/i915/guc: Improved reporting when GuC fails to load drm/i915/guc: Clear pointers on free drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 +- drivers/gpu/drm/i915/gt/uc/intel_guc.c | 18 --- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 132 +++ drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c| 1 + drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c| 31 +++-- drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 80 +-- drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h | 5 + drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 27 ++-- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 + drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 6 +- drivers/gpu/drm/i915/i915_params.h | 2 +- 11 files changed, 201 insertions(+), 106 deletions(-) -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915/guc: Clear pointers on free
From: John Harrison
Was hitting null pointers and similar issues when running various
module load/unload and inject failure type tests. So clear those
pointers down when the objects have been de-allocated.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 7950d28beb8c..5212ff844292 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -220,6 +220,7 @@ int intel_guc_ads_create(struct intel_guc *guc)
void intel_guc_ads_destroy(struct intel_guc *guc)
{
i915_vma_unpin_and_release(>ads_vma, I915_VMA_RELEASE_MAP);
+ guc->ads_blob = NULL;
}
static void guc_ads_private_data_reset(struct intel_guc *guc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 11742fca0e9e..fa9e048cc65f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -210,6 +210,7 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
GEM_BUG_ON(ct->enabled);
i915_vma_unpin_and_release(>vma, I915_VMA_RELEASE_MAP);
+ memset(ct, 0, sizeof(*ct));
}
/**
--
2.25.1
___
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: Finish (de)gamma readout prep bits
== Series Details == Series: drm/i915: Finish (de)gamma readout prep bits URL : https://patchwork.freedesktop.org/series/82099/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9056_full -> Patchwork_18575_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18575_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18575_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_18575_full: ### Piglit changes ### Possible regressions * spec@glsl-1.50@execution@built-in-functions@gs-op-mult-uvec4-uvec4 (NEW): - pig-snb-2600: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18575/pig-snb-2600/spec@glsl-1.50@execution@built-in-functi...@gs-op-mult-uvec4-uvec4.html New tests - New tests have been introduced between CI_DRM_9056_full and Patchwork_18575_full: ### New Piglit tests (1) ### * spec@glsl-1.50@execution@built-in-functions@gs-op-mult-uvec4-uvec4: - Statuses : 1 fail(s) - Exec time: [0.14] s Known issues Here are the changes found in Patchwork_18575_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_reloc@basic-many-active@vcs0: - shard-glk: [PASS][2] -> [FAIL][3] ([i915#2389]) +1 similar issue [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-glk6/igt@gem_exec_reloc@basic-many-act...@vcs0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18575/shard-glk6/igt@gem_exec_reloc@basic-many-act...@vcs0.html * igt@gem_mmap_offset@blt-coherency: - shard-glk: [PASS][4] -> [FAIL][5] ([i915#2328]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-glk8/igt@gem_mmap_off...@blt-coherency.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18575/shard-glk3/igt@gem_mmap_off...@blt-coherency.html * igt@gem_workarounds@suspend-resume: - shard-skl: [PASS][6] -> [INCOMPLETE][7] ([i915#198]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-skl10/igt@gem_workarou...@suspend-resume.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18575/shard-skl6/igt@gem_workarou...@suspend-resume.html * igt@i915_suspend@forcewake: - shard-kbl: [PASS][8] -> [DMESG-WARN][9] ([i915#180]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-kbl6/igt@i915_susp...@forcewake.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18575/shard-kbl6/igt@i915_susp...@forcewake.html * igt@kms_big_fb@x-tiled-64bpp-rotate-180: - shard-apl: [PASS][10] -> [DMESG-WARN][11] ([i915#1635] / [i915#1982]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-apl1/igt@kms_big...@x-tiled-64bpp-rotate-180.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18575/shard-apl4/igt@kms_big...@x-tiled-64bpp-rotate-180.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_9056/shard-hsw2/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18575/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html * igt@kms_flip@flip-vs-expired-vblank@c-edp1: - shard-skl: [PASS][14] -> [FAIL][15] ([i915#79]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-skl1/igt@kms_flip@flip-vs-expired-vbl...@c-edp1.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18575/shard-skl4/igt@kms_flip@flip-vs-expired-vbl...@c-edp1.html * igt@kms_flip@flip-vs-suspend@a-edp1: - shard-skl: [PASS][16] -> [DMESG-WARN][17] ([i915#1982]) +3 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-skl2/igt@kms_flip@flip-vs-susp...@a-edp1.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18575/shard-skl9/igt@kms_flip@flip-vs-susp...@a-edp1.html * igt@kms_flip@plain-flip-ts-check-interruptible@c-edp1: - shard-skl: [PASS][18] -> [FAIL][19] ([i915#2122]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-skl7/igt@kms_flip@plain-flip-ts-check-interrupti...@c-edp1.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18575/shard-skl3/igt@kms_flip@plain-flip-ts-check-interrupti...@c-edp1.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-gtt: - shard-tglb: [PASS][20] -> [DMESG-WARN][21] ([i915#1982]) +2 similar issues [20]:
Re: [Intel-gfx] [PATCH v3 0/4] dma-buf: Flag vmap'ed memory as system or I/O memory
Hi Thomas, On Fri, Sep 25, 2020 at 01:55:57PM +0200, Thomas Zimmermann wrote: > Dma-buf provides vmap() and vunmap() for retriving and releasing mappings > of dma-buf memory in kernel address space. The functions operate with plain > addresses and the assumption is that the memory can be accessed with load > and store operations. This is not the case on some architectures (e.g., > sparc64) where I/O memory can only be accessed with dedicated instructions. > > This patchset introduces struct dma_buf_map, which contains the address of > a buffer and a flag that tells whether system- or I/O-memory instructions > are required. > > Some background: updating the DRM framebuffer console on sparc64 makes the > kernel panic. This is because the framebuffer memory cannot be accessed with > system-memory instructions. We currently employ a workaround in DRM to > address this specific problem. [1] > > To resolve the problem, we'd like to address it at the most common point, > which is the dma-buf framework. The dma-buf mapping ideally knows if I/O > instructions are required and exports this information to it's users. The > new structure struct dma_buf_map stores the buffer address and a flag that > signals I/O memory. Affected users of the buffer (e.g., drivers, frameworks) > can then access the memory accordingly. > > This patchset only introduces struct dma_buf_map, and updates struct dma_buf > and it's interfaces. Further patches can update dma-buf users. For example, > there's a prototype patchset for DRM that fixes the framebuffer problem. [2] > > Further work: TTM, one of DRM's memory managers, already exports an > is_iomem flag of its own. It could later be switched over to exporting struct > dma_buf_map, thus simplifying some code. Several DRM drivers expect their > fbdev console to operate on I/O memory. These could possibly be switched over > to the generic fbdev emulation, as soon as the generic code uses struct > dma_buf_map. > > v3: > * update fastrpc driver (kernel test robot) > * expand documentation (Daniel) > * move documentation into separate patch > v2: > * always clear map parameter in dma_buf_vmap() (Daniel) > * include dma-buf-heaps and i915 selftests (kernel test robot) > * initialize cma_obj before using it in drm_gem_cma_free_object() > (kernel test robot) > > [1] https://lore.kernel.org/dri-devel/20200725191012.ga434...@ravnborg.org/ > [2] > https://lore.kernel.org/dri-devel/20200806085239.4606-1-tzimmerm...@suse.de/ > > Thomas Zimmermann (4): > dma-buf: Add struct dma-buf-map for storing struct dma_buf.vaddr_ptr > dma-buf: Use struct dma_buf_map in dma_buf_vmap() interfaces > dma-buf: Use struct dma_buf_map in dma_buf_vunmap() interfaces > dma-buf: Document struct dma_buf_map > > Documentation/driver-api/dma-buf.rst | 9 + > drivers/dma-buf/dma-buf.c | 42 ++-- > drivers/dma-buf/heaps/heap-helpers.c | 10 +- > drivers/gpu/drm/drm_gem_cma_helper.c | 20 +- > drivers/gpu/drm/drm_gem_shmem_helper.c| 17 +- > drivers/gpu/drm/drm_prime.c | 15 +- > drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 13 +- > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 13 +- > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 18 +- > .../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 14 +- > drivers/gpu/drm/tegra/gem.c | 23 ++- > .../common/videobuf2/videobuf2-dma-contig.c | 17 +- > .../media/common/videobuf2/videobuf2-dma-sg.c | 19 +- > .../common/videobuf2/videobuf2-vmalloc.c | 21 +- > drivers/misc/fastrpc.c| 6 +- > include/drm/drm_prime.h | 5 +- > include/linux/dma-buf-map.h | 193 ++ > include/linux/dma-buf.h | 11 +- > 18 files changed, 372 insertions(+), 94 deletions(-) > create mode 100644 include/linux/dma-buf-map.h For drivers/media/common/videobuf2 changes: Acked-by: Tomasz Figa Best regards, Tomasz ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for Add support for DP-HDMI2.1 PCON
== Series Details == Series: Add support for DP-HDMI2.1 PCON URL : https://patchwork.freedesktop.org/series/82098/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9056_full -> Patchwork_18574_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18574_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18574_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_18574_full: ### IGT changes ### Possible regressions * igt@gem_softpin@noreloc-s3: - shard-glk: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-glk5/igt@gem_soft...@noreloc-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18574/shard-glk8/igt@gem_soft...@noreloc-s3.html * igt@runner@aborted: - shard-tglb: NOTRUN -> [FAIL][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18574/shard-tglb1/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_18574_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_reloc@basic-many-active@vcs0: - shard-glk: [PASS][4] -> [FAIL][5] ([i915#2389]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-glk6/igt@gem_exec_reloc@basic-many-act...@vcs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18574/shard-glk1/igt@gem_exec_reloc@basic-many-act...@vcs0.html * igt@gem_mmap_offset@blt-coherency: - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2328]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-glk8/igt@gem_mmap_off...@blt-coherency.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18574/shard-glk5/igt@gem_mmap_off...@blt-coherency.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][8] -> [DMESG-WARN][9] ([i915#1436] / [i915#716]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-skl9/igt@gen9_exec_pa...@allowed-single.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18574/shard-skl9/igt@gen9_exec_pa...@allowed-single.html * igt@i915_module_load@reload: - shard-iclb: [PASS][10] -> [DMESG-WARN][11] ([i915#1982]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-iclb6/igt@i915_module_l...@reload.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18574/shard-iclb3/igt@i915_module_l...@reload.html * igt@i915_selftest@mock@contexts: - shard-skl: [PASS][12] -> [INCOMPLETE][13] ([i915#198] / [i915#2278]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-skl10/igt@i915_selftest@m...@contexts.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18574/shard-skl4/igt@i915_selftest@m...@contexts.html * igt@kms_cursor_crc@pipe-b-cursor-256x256-random: - shard-snb: [PASS][14] -> [SKIP][15] ([fdo#109271]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-snb1/igt@kms_cursor_...@pipe-b-cursor-256x256-random.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18574/shard-snb1/igt@kms_cursor_...@pipe-b-cursor-256x256-random.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: - shard-hsw: [PASS][16] -> [FAIL][17] ([i915#96]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-hsw2/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18574/shard-hsw8/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-hdmi-a1: - shard-glk: [PASS][18] -> [FAIL][19] ([i915#79]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-glk3/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-hdmi-a1.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18574/shard-glk6/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-hdmi-a1.html * igt@kms_flip@flip-vs-suspend@a-edp1: - shard-skl: [PASS][20] -> [DMESG-WARN][21] ([i915#1982]) +10 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-skl2/igt@kms_flip@flip-vs-susp...@a-edp1.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18574/shard-skl2/igt@kms_flip@flip-vs-susp...@a-edp1.html * igt@kms_flip@flip-vs-suspend@c-dp1: - shard-kbl: [PASS][22] -> [DMESG-WARN][23] ([i915#180]) +2 similar issues [22]:
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Make intel_{enable, disable}_sagv() static
== Series Details ==
Series: series starting with [1/2] drm/i915: Make intel_{enable,
disable}_sagv() static
URL : https://patchwork.freedesktop.org/series/82096/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9056_full -> Patchwork_18573_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_18573_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox:
- shard-skl: [PASS][1] -> [FAIL][2] ([i915#2374])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-skl10/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18573/shard-skl7/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html
* igt@gem_exec_reloc@basic-many-active@vcs0:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2389])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-glk6/igt@gem_exec_reloc@basic-many-act...@vcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18573/shard-glk8/igt@gem_exec_reloc@basic-many-act...@vcs0.html
* igt@gem_mmap_offset@blt-coherency:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#2328])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-glk8/igt@gem_mmap_off...@blt-coherency.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18573/shard-glk9/igt@gem_mmap_off...@blt-coherency.html
* igt@gem_workarounds@suspend-resume-fd:
- shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +4 similar
issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-kbl6/igt@gem_workarou...@suspend-resume-fd.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18573/shard-kbl4/igt@gem_workarou...@suspend-resume-fd.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@b-dp1:
- shard-kbl: [PASS][9] -> [FAIL][10] ([i915#79])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-kbl7/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-dp1.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18573/shard-kbl2/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-dp1.html
* igt@kms_flip@flip-vs-suspend@a-edp1:
- shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +6
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-skl2/igt@kms_flip@flip-vs-susp...@a-edp1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18573/shard-skl1/igt@kms_flip@flip-vs-susp...@a-edp1.html
* igt@kms_flip@plain-flip-fb-recreate-interruptible@c-edp1:
- shard-skl: [PASS][13] -> [FAIL][14] ([i915#2122])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-skl7/igt@kms_flip@plain-flip-fb-recreate-interrupti...@c-edp1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18573/shard-skl6/igt@kms_flip@plain-flip-fb-recreate-interrupti...@c-edp1.html
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-gtt:
- shard-tglb: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-tglb1/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-mmap-gtt.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18573/shard-tglb8/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-mmap-gtt.html
* igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl: [PASS][17] -> [DMESG-FAIL][18] ([fdo#108145] /
[i915#1982])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-skl5/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18573/shard-skl2/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145] / [i915#265])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-skl3/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18573/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
* igt@kms_psr@psr2_cursor_plane_onoff:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +2 similar
issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18573/shard-iclb4/igt@kms_psr@psr2_cursor_plane_onoff.html
* igt@kms_vblank@pipe-c-query-busy:
- shard-apl: [PASS][23] -> [DMESG-WARN][24] ([i915#1635] /
[i915#1982])
[23]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for dma-buf: Flag vmap'ed memory as system or I/O memory (rev3)
== Series Details == Series: dma-buf: Flag vmap'ed memory as system or I/O memory (rev3) URL : https://patchwork.freedesktop.org/series/81647/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9056_full -> Patchwork_18572_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18572_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18572_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_18572_full: ### Piglit changes ### Possible regressions * spec@arb_texture_multisample@texelfetch@2-gs-isampler2dms (NEW): - pig-snb-2600: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18572/pig-snb-2600/spec@arb_texture_multisample@texelfe...@2-gs-isampler2dms.html New tests - New tests have been introduced between CI_DRM_9056_full and Patchwork_18572_full: ### New Piglit tests (1) ### * spec@arb_texture_multisample@texelfetch@2-gs-isampler2dms: - Statuses : 1 fail(s) - Exec time: [0.14] s Known issues Here are the changes found in Patchwork_18572_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_reloc@basic-many-active@vcs0: - shard-glk: [PASS][2] -> [FAIL][3] ([i915#2389]) +1 similar issue [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-glk6/igt@gem_exec_reloc@basic-many-act...@vcs0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18572/shard-glk7/igt@gem_exec_reloc@basic-many-act...@vcs0.html * igt@gem_mmap_offset@blt-coherency: - shard-glk: [PASS][4] -> [FAIL][5] ([i915#2328]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-glk8/igt@gem_mmap_off...@blt-coherency.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18572/shard-glk4/igt@gem_mmap_off...@blt-coherency.html * igt@gem_softpin@noreloc-s3: - shard-apl: [PASS][6] -> [INCOMPLETE][7] ([i915#1635]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-apl8/igt@gem_soft...@noreloc-s3.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18572/shard-apl8/igt@gem_soft...@noreloc-s3.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][8] -> [DMESG-WARN][9] ([i915#1436] / [i915#716]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-skl9/igt@gen9_exec_pa...@allowed-single.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18572/shard-skl7/igt@gen9_exec_pa...@allowed-single.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][10] -> [FAIL][11] ([i915#454]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-iclb2/igt@i915_pm...@dc6-psr.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18572/shard-iclb4/igt@i915_pm...@dc6-psr.html * igt@i915_pm_rpm@system-suspend-modeset: - shard-kbl: [PASS][12] -> [DMESG-WARN][13] ([i915#165]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-kbl4/igt@i915_pm_...@system-suspend-modeset.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18572/shard-kbl4/igt@i915_pm_...@system-suspend-modeset.html * igt@kms_flip@2x-wf_vblank-ts-check-interruptible@ab-vga1-hdmi-a1: - shard-hsw: [PASS][14] -> [DMESG-WARN][15] ([i915#1982]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-hsw4/igt@kms_flip@2x-wf_vblank-ts-check-interrupti...@ab-vga1-hdmi-a1.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18572/shard-hsw1/igt@kms_flip@2x-wf_vblank-ts-check-interrupti...@ab-vga1-hdmi-a1.html * igt@kms_flip@flip-vs-suspend@a-edp1: - shard-skl: [PASS][16] -> [DMESG-WARN][17] ([i915#1982]) +7 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-skl2/igt@kms_flip@flip-vs-susp...@a-edp1.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18572/shard-skl4/igt@kms_flip@flip-vs-susp...@a-edp1.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-gtt: - shard-tglb: [PASS][18] -> [DMESG-WARN][19] ([i915#1982]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-tglb3/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-mmap-gtt.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18572/shard-tglb5/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-mmap-gtt.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [PASS][20] -> [DMESG-WARN][21] ([i915#180]) +1 similar issue [20]:
Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.
On Thu, 2020-09-24 at 17:46 -0600, Kevin Chowski wrote: > cc back a few others who were unintentionally dropped from the thread > earlier. > > Someone (at Google) helped me dig into this a little more and they > found a document titled "eDP Backlight Brightness bit alignment" sent > out for review in January 2017. I registered for a new account (google > is a member) and have access to the document; here is the URL for > those who also have access: > https://groups.vesa.org/wg/AllMem/document/7786. For what it's worth, > it seems like Lyude's contact Bill Lempesis uploaded this > change-request document, so I think we can reach out to him if we have > further questions. It's actually unclear to me what the status of this > change request is, and whether it's been officially accepted. But I > think it can be seen as some official advice on how we can move > forward here. > > Basically, this is a change request to the spec which acknowledges > that, despite the original spec implying that the > most-significant-bits were relevant here, many implementations used > the least-significant-bits. In defense of most-significant it laid out > some similar arguments to what Ville was saying. But it ends up > saying: > > > Unfortunately, the most common interpretation that we have > > encountered is case 1 in the example above. TCON vendors > > tend to align the valid bits to the LSBs, not the MSBs. > > Instead of changing the default defined functionality (as some earlier > version of this doc apparently suggested), this doc prefers to > allocate two extra bits in EDP_GENERAL_CAPABILITY_2 so that future > backlight devices can specify to the Source how to program them: > > 00: the current functionality, i,e. no defined interpretation > 01: aligned to most-significant bits > 10: aligned to least-significant bits > 11: reserved > > It also says "[Sources] should only need panel-specific workarounds > for the currently available panels." > > So I believe this document is an acknowledgement of many > implementations having their alignment to the least-significant bits, > and (to my eyes) clearly validates that the spec "should" be the > opposite. If we believe the doc's claim that "the most common > interpretation" is least-significant, it seems to me that it would > require more quirks if we made most-significant the default > implementation. > > Ville mentioned at some point earlier that we should try to match the > spec, whereas Lyude mentioned we should prefer to do what the majority > of machines do. What do you both think of this new development? That's how displayport happens to be sometimes :). Definitely isn't the first time something in the spec like this got implemented incorrectly so many times by different vendors that they had to update the spec in response (same thing happened with MST and interleaved sideband messages as of DP 2.0), so I'm really glad we went and actually investigated this. So yes - I think a quirk for this would definitely be a good idea, and IMO we should always lean on the side that more panels implement even if it's not according to spec - so defaulting to the behavior we currently have in the kernel, and adding quirks for panels that were smart enough not to fall for this would probably be the best way to go. That just leaves the challenge of "how do we figure out which panels actually need this and which ones don't?" This might end up being a bit of a challenge, but I've got some ideas on how we might be able to tackle it to the best of our ability based off my discussions with laptop vendors. It seems like some of the homegrown backlight interfaces might help us out here. Note I'm mentioning other laptop vendors here because at least for nouveau, our plan for DPCD backlight support is to move a lot of the code for handling it that currently lives in i915 into shared DRM helpers (which now we'll definitely need to do as a result of these quirks). So, on the x86 front, there's already a few different interfaces in use for laptop panels: * AMD usually uses their own backlight interface, so for AMD-only laptops we can probably safely ignore this * Intel uses their own DPCD backlight interface on most of the _non-ChromeOS_ machines on the market right now afaik based off my discussion with some laptop vendors. For panels that only come up in Intel-only machines, that means we only really need to care about the ChromeOS case here. So-if Google's able to actually survey the devices they're shipping with ChromeOS right now to figure out which ones are using DPCD backlight controls, and which ones need to be MSB aligned - then I'd think we could probably build an accurate quirk list of those panels easily. * This just leaves the nvidia case. Nvidia seems to be one of the only GPU vendors that didn't come up with their own backlight interface over DPCD, and they actually require that the panel support the VESA backlight control interface.
Re: [Intel-gfx] [PATCH v2 4/6] drm/dp: Add LTTPR helpers
On Fri, Sep 25, 2020 at 07:02:47PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 24, 2020 at 09:48:03PM +0300, Imre Deak wrote:
> > 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.
> >
> > v2:
> > - Add drm_dp_dpcd_read_phy_link_status() and DP_PHY_LTTPR() here instead
> > of adding these to i915. (Ville)
> >
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: Ville Syrjälä
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 244 +++-
> > include/drm/drm_dp_helper.h | 62
> > 2 files changed, 302 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 478dd51f738d..6014c858b06b 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 */
> > @@ -363,6 +387,71 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux
> > *aux,
> > }
> > EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
> >
> > +/**
> > + * drm_dp_dpcd_read_phy_link_status - get the link status information for
> > a DP PHY
> > + * @aux: DisplayPort AUX channel
> > + * @dp_phy: the DP PHY to get the link status for
> > + * @link_status: buffer to return the status in
> > + *
> > + * Fetch the AUX DPCD registers for the DPRX or an LTTPR PHY link status.
> > The
> > + * layout of the returned @link_status matches the DPCD register layout of
> > the
> > + * DPRX PHY link status.
> > + *
> > + * Returns 0 if the information was read successfully or a negative error
> > code
> > + * on failure.
> > + */
> > +int drm_dp_dpcd_read_phy_link_status(struct drm_dp_aux *aux,
> > +enum drm_dp_phy dp_phy,
> > +u8 link_status[DP_LINK_STATUS_SIZE])
> > +{
> > + u8 lttpr_status[DP_LINK_STATUS_SIZE - 1];
> > + int ret;
> > +
> > + if (dp_phy == DP_PHY_DPRX) {
> > + ret = drm_dp_dpcd_read(aux,
> > + DP_LANE0_1_STATUS,
> > + link_status,
> > + DP_LINK_STATUS_SIZE);
> > +
> > + if (ret < 0)
> > + return ret;
> > +
> > + WARN_ON(ret != DP_LINK_STATUS_SIZE);
> > +
> > + return 0;
> > + }
> > +
> > + ret = drm_dp_dpcd_read(aux,
> > + DP_LANE0_1_STATUS_PHY_REPEATER(dp_phy),
> > + lttpr_status,
> > + sizeof(lttpr_status));
> > +
> > + if (ret < 0)
> > + return ret;
> > +
> > + WARN_ON(ret != sizeof(lttpr_status));
> > +
> > +#define link_reg(reg) link_status[(reg) - DP_LANE0_1_STATUS]
> > +#define lttpr_reg(reg) lttpr_status[(reg) -
> > DP_LANE0_1_STATUS_PHY_REPEATER1]
> > +
> > + /* Convert the LTTPR to the sink PHY link status layout */
> > +
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/11] mm: update the documentation for vfree (rev2)
== Series Details ==
Series: series starting with [01/11] mm: update the documentation for vfree
(rev2)
URL : https://patchwork.freedesktop.org/series/82063/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9057 -> Patchwork_18576
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/index.html
Known issues
Here are the changes found in Patchwork_18576 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_9057/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
Possible fixes
* igt@debugfs_test@read_all_entries:
- fi-bsw-nick:[INCOMPLETE][3] ([i915#1250] / [i915#1436]) ->
[PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-bsw-nick/igt@debugfs_test@read_all_entries.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/fi-bsw-nick/igt@debugfs_test@read_all_entries.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-bsw-kefka: [INCOMPLETE][5] -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-bsw-kefka/igt@i915_selftest@live@gt_heartbeat.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/fi-bsw-kefka/igt@i915_selftest@live@gt_heartbeat.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][7] ([i915#62] / [i915#95]) ->
[DMESG-FAIL][8] ([i915#62])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92]) ->
[DMESG-WARN][10] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.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]) +2 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
* igt@vgem_basic@unload:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) ->
[DMESG-WARN][14] ([i915#95])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9057/fi-kbl-x1275/igt@vgem_ba...@unload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18576/fi-kbl-x1275/igt@vgem_ba...@unload.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1250]: https://gitlab.freedesktop.org/drm/intel/issues/1250
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#289]: https://gitlab.freedesktop.org/drm/intel/issues/289
[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 (45 -> 39)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_9057 -> Patchwork_18576
CI-20190529: 20190529
CI_DRM_9057: f812e3c53df08387b5b322aef7f911f21e77aa05 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5788: a7520973a210b7268c3039902789f433ee0f5ef7 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18576: c11fe008f1751502cedfffb96abe32165940beae @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
c11fe008f175 mm: remove alloc_vm_area
e6569a322009 x86/xen: open code alloc_vm_area in arch_gnttab_valloc
ee890e84c9e2 xen/xenbus: use apply_to_page_range directly in xenbus_map_ring_pv
df7c4a828c36 drm/i915: use vmap in i915_gem_object_map
fd8fa2d72d09 drm/i915: stop using kmap in i915_gem_object_map
179e795ffba4 drm/i915: use vmap in shmem_pin_map
1dae0eeec9bf zsmalloc: switch from alloc_vm_area to get_vm_area
4b84416af184 mm: allow a NULL fn
Re: [Intel-gfx] [PATCH v2 5/6] drm/i915: Switch to LTTPR transparent mode link training
On Fri, Sep 25, 2020 at 07:03:50PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 24, 2020 at 09:48:04PM +0300, Imre Deak wrote:
> > 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.
> >
> > v2:
> > - Add a code comment about the explicit disabling of non-transparent
> > mode.
> >
> > Cc: Ville Syrjälä
> > 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 | 52 +++
> > .../drm/i915/display/intel_dp_link_training.h | 2 +
> > 4 files changed, 58 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 b21f42193a11..64bf4aa384d3 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -4726,6 +4726,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > {
> > int ret;
> >
> > + if (!intel_dp_is_edp(intel_dp))
> > + intel_dp_lttpr_init(intel_dp);
>
> I was initially a bit confused why this is before we read dpcd[], but
> looks like the spec says that is the expected order.
Yes. It's strange but reading the spec makes me think that even reading
regs could have side-effects, here the LTTPR caps reading is the first
according to the spec.
Btw, the other less clearly specified things are the order of
(explicitly) switching to transparent mode vs. reading the LTTPR common
caps, and in what case to perform the switch. I decided the correct
order is to read the caps first, and switch unconditionally. The latter
has the downside of an AUX timeout/NAK on platforms w/o LTTPRs, but this
seemed to be the more robust way.
> Reviewed-by: Ville Syrjälä
Thanks. I mucked up the eDP check, missing it from
intel_dp_start_link_train(), will move it to intel_dp_lttpr_init()
instead.
>
> > +
> > 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 38d4553670a1..4f8f42cc25fa 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,52 @@ intel_dp_dump_link_status(const u8
> > link_status[DP_LINK_STATUS_SIZE])
> > link_status[3], link_status[4], link_status[5]);
> > }
> >
> > +static bool intel_dp_read_lttpr_common_caps(struct intel_dp *intel_dp)
> > +{
> > + if (drm_dp_read_lttpr_common_caps(_dp->aux,
> > + intel_dp->lttpr_common_caps) < 0) {
> > + memset(intel_dp->lttpr_common_caps, 0,
> > + sizeof(intel_dp->lttpr_common_caps));
> > + return false;
> > + }
> > +
> > + 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);
> > +
> > + return true;
> > +}
> > +
> > +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;
> > +}
> > +
> > +/**
> > + * intel_dp_lttpr_init - detect LTTPRs and init the LTTPR link training
> > mode
> > + * @intel_dp: Intel DP struct
> > + *
> > + * Read the LTTPR common capabilities and switch to transparent link
> > training
> > + * mode.
> > + */
> > +int intel_dp_lttpr_init(struct intel_dp *intel_dp)
> > +{
> > + intel_dp_read_lttpr_common_caps(intel_dp);
> > +
> > + /*
> > +* See DP Standard v2.0 3.6.6.1. about the explicit disabling of
> > +* non-transparent mode.
> > +*/
> > + intel_dp_set_lttpr_transparent_mode(intel_dp, true);
> > +
> > +
[Intel-gfx] [PATCH 08/11, fixed] drm/i915: use vmap in i915_gem_object_map
i915_gem_object_map implements fairly low-level vmap functionality in
a driver. Split it into two helpers, one for remapping kernel memory
which can use vmap, and one for I/O memory that uses vmap_pfn.
The only practical difference is that alloc_vm_area prefeaults the
vmalloc area PTEs, which doesn't seem to be required here for the
kernel memory case (and could be added to vmap using a flag if actually
required).
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 127 ++
2 files changed, 60 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 9afa5c4a6bf006..1e1cb245fca778 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -25,6 +25,7 @@ config DRM_I915
select CRC32
select SND_HDA_I915 if SND_HDA_CORE
select CEC_CORE if CEC_NOTIFIER
+ select VMAP_PFN
help
Choose this option if you have a system that has "Intel Graphics
Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 6550c0bc824ea2..f60ca6dc911f29 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -232,34 +232,21 @@ int __i915_gem_object_put_pages(struct
drm_i915_gem_object *obj)
return err;
}
-static inline pte_t iomap_pte(resource_size_t base,
- dma_addr_t offset,
- pgprot_t prot)
-{
- return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
-}
-
/* The 'mapping' part of i915_gem_object_pin_map() below */
-static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
-enum i915_map_type type)
+static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj,
+ enum i915_map_type type)
{
- unsigned long n_pte = obj->base.size >> PAGE_SHIFT;
- struct sg_table *sgt = obj->mm.pages;
- pte_t *stack[32], **mem;
- struct vm_struct *area;
+ unsigned long n_pages = obj->base.size >> PAGE_SHIFT, i;
+ struct page *stack[32], **pages = stack, *page;
+ struct sgt_iter iter;
pgprot_t pgprot;
+ void *vaddr;
- if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC)
- return NULL;
-
- if (GEM_WARN_ON(type == I915_MAP_WC &&
- !static_cpu_has(X86_FEATURE_PAT)))
- return NULL;
-
- /* A single page can always be kmapped */
- if (n_pte == 1 && type == I915_MAP_WB) {
- struct page *page = sg_page(sgt->sgl);
-
+ switch (type) {
+ default:
+ MISSING_CASE(type);
+ fallthrough;/* to use PAGE_KERNEL anyway */
+ case I915_MAP_WB:
/*
* On 32b, highmem using a finite set of indirect PTE (i.e.
* vmap) to provide virtual mappings of the high pages.
@@ -277,30 +264,8 @@ static void *i915_gem_object_map(struct
drm_i915_gem_object *obj,
* So if the page is beyond the 32b boundary, make an explicit
* vmap.
*/
- if (!PageHighMem(page))
- return page_address(page);
- }
-
- mem = stack;
- if (n_pte > ARRAY_SIZE(stack)) {
- /* Too big for stack -- allocate temporary array instead */
- mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
- if (!mem)
- return NULL;
- }
-
- area = alloc_vm_area(obj->base.size, mem);
- if (!area) {
- if (mem != stack)
- kvfree(mem);
- return NULL;
- }
-
- switch (type) {
- default:
- MISSING_CASE(type);
- fallthrough;/* to use PAGE_KERNEL anyway */
- case I915_MAP_WB:
+ if (n_pages == 1 && !PageHighMem(sg_page(obj->mm.pages->sgl)))
+ return page_address(sg_page(obj->mm.pages->sgl));
pgprot = PAGE_KERNEL;
break;
case I915_MAP_WC:
@@ -308,30 +273,50 @@ static void *i915_gem_object_map(struct
drm_i915_gem_object *obj,
break;
}
- if (i915_gem_object_has_struct_page(obj)) {
- struct sgt_iter iter;
- struct page *page;
- pte_t **ptes = mem;
+ if (n_pages > ARRAY_SIZE(stack)) {
+ /* Too big for stack -- allocate temporary array instead */
+ pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
+ if (!pages)
+ return NULL;
+ }
- for_each_sgt_page(page, iter, sgt)
- **ptes++ = mk_pte(page, pgprot);
- } else
Re: [Intel-gfx] [PATCH v2 5/6] drm/i915: Switch to LTTPR transparent mode link training
On Thu, Sep 24, 2020 at 09:48:04PM +0300, Imre Deak wrote:
> 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.
>
> v2:
> - Add a code comment about the explicit disabling of non-transparent
> mode.
>
> Cc: Ville Syrjälä
> 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 | 52 +++
> .../drm/i915/display/intel_dp_link_training.h | 2 +
> 4 files changed, 58 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 b21f42193a11..64bf4aa384d3 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4726,6 +4726,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> {
> int ret;
>
> + if (!intel_dp_is_edp(intel_dp))
> + intel_dp_lttpr_init(intel_dp);
I was initially a bit confused why this is before we read dpcd[], but
looks like the spec says that is the expected order.
Reviewed-by: Ville Syrjälä
> +
> 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 38d4553670a1..4f8f42cc25fa 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,52 @@ intel_dp_dump_link_status(const u8
> link_status[DP_LINK_STATUS_SIZE])
> link_status[3], link_status[4], link_status[5]);
> }
>
> +static bool intel_dp_read_lttpr_common_caps(struct intel_dp *intel_dp)
> +{
> + if (drm_dp_read_lttpr_common_caps(_dp->aux,
> + intel_dp->lttpr_common_caps) < 0) {
> + memset(intel_dp->lttpr_common_caps, 0,
> +sizeof(intel_dp->lttpr_common_caps));
> + return false;
> + }
> +
> + 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);
> +
> + return true;
> +}
> +
> +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;
> +}
> +
> +/**
> + * intel_dp_lttpr_init - detect LTTPRs and init the LTTPR link training mode
> + * @intel_dp: Intel DP struct
> + *
> + * Read the LTTPR common capabilities and switch to transparent link training
> + * mode.
> + */
> +int intel_dp_lttpr_init(struct intel_dp *intel_dp)
> +{
> + intel_dp_read_lttpr_common_caps(intel_dp);
> +
> + /*
> + * See DP Standard v2.0 3.6.6.1. about the explicit disabling of
> + * non-transparent mode.
> + */
> + intel_dp_set_lttpr_transparent_mode(intel_dp, true);
> +
> + return 0;
> +}
> +
> static u8 dp_voltage_max(u8 preemph)
> {
> switch (preemph & DP_TRAIN_PRE_EMPHASIS_MASK) {
> @@ -471,6 +517,12 @@ static void
> intel_dp_schedule_fallback_link_training(struct intel_dp *intel_dp)
> */
> void intel_dp_start_link_train(struct intel_dp *intel_dp)
> {
> + /*
> + * TODO: Reiniting LTTPRs here won't be needed once proper connector
> + * HW state readout is added.
> + */
> + intel_dp_lttpr_init(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 518d834dbc98..3536ce73a123 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
Re: [Intel-gfx] [PATCH v2 4/6] drm/dp: Add LTTPR helpers
On Thu, Sep 24, 2020 at 09:48:03PM +0300, Imre Deak wrote:
> 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.
>
> v2:
> - Add drm_dp_dpcd_read_phy_link_status() and DP_PHY_LTTPR() here instead
> of adding these to i915. (Ville)
>
> Cc: dri-de...@lists.freedesktop.org
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/drm_dp_helper.c | 244 +++-
> include/drm/drm_dp_helper.h | 62
> 2 files changed, 302 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 478dd51f738d..6014c858b06b 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 */
> @@ -363,6 +387,71 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
> }
> EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
>
> +/**
> + * drm_dp_dpcd_read_phy_link_status - get the link status information for a
> DP PHY
> + * @aux: DisplayPort AUX channel
> + * @dp_phy: the DP PHY to get the link status for
> + * @link_status: buffer to return the status in
> + *
> + * Fetch the AUX DPCD registers for the DPRX or an LTTPR PHY link status. The
> + * layout of the returned @link_status matches the DPCD register layout of
> the
> + * DPRX PHY link status.
> + *
> + * Returns 0 if the information was read successfully or a negative error
> code
> + * on failure.
> + */
> +int drm_dp_dpcd_read_phy_link_status(struct drm_dp_aux *aux,
> + enum drm_dp_phy dp_phy,
> + u8 link_status[DP_LINK_STATUS_SIZE])
> +{
> + u8 lttpr_status[DP_LINK_STATUS_SIZE - 1];
> + int ret;
> +
> + if (dp_phy == DP_PHY_DPRX) {
> + ret = drm_dp_dpcd_read(aux,
> +DP_LANE0_1_STATUS,
> +link_status,
> +DP_LINK_STATUS_SIZE);
> +
> + if (ret < 0)
> + return ret;
> +
> + WARN_ON(ret != DP_LINK_STATUS_SIZE);
> +
> + return 0;
> + }
> +
> + ret = drm_dp_dpcd_read(aux,
> +DP_LANE0_1_STATUS_PHY_REPEATER(dp_phy),
> +lttpr_status,
> +sizeof(lttpr_status));
> +
> + if (ret < 0)
> + return ret;
> +
> + WARN_ON(ret != sizeof(lttpr_status));
> +
> +#define link_reg(reg)link_status[(reg) - DP_LANE0_1_STATUS]
> +#define lttpr_reg(reg) lttpr_status[(reg) -
> DP_LANE0_1_STATUS_PHY_REPEATER1]
> +
> + /* Convert the LTTPR to the sink PHY link status layout */
> + link_reg(DP_LANE0_1_STATUS) =
> lttpr_reg(DP_LANE0_1_STATUS_PHY_REPEATER1);
> + link_reg(DP_LANE2_3_STATUS) =
> lttpr_reg(DP_LANE2_3_STATUS_PHY_REPEATER1);
> + link_reg(DP_LANE_ALIGN_STATUS_UPDATED) =
> + lttpr_reg(DP_LANE_ALIGN_STATUS_UPDATED_PHY_REPEATER1);
> +
Re: [Intel-gfx] [PATCH 08/11] drm/i915: use vmap in i915_gem_object_map
On Fri, Sep 25, 2020 at 03:08:59PM +0100, Matthew Auld wrote: > > + i = 0; > > + for_each_sgt_page(page, iter, obj->mm.pages) > > + pages[i++] = page; > > + vaddr = vmap(pages, n_pages, 0, pgprot); > > + if (pages != stack) > > + kvfree(pages); > > + return vaddr; > > +} > > - return area->addr; > > + for_each_sgt_daddr(addr, iter, obj->mm.pages) > > + pfns[i++] = (iomap + addr) >> PAGE_SHIFT; > > Missing the i = 0 fix from Dan? Yeah, looks like I only managed to apply the one in the page based version above. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/i915: Redo "Remove i915_request.lock requirement for execution callbacks"
== Series Details == Series: series starting with [CI,1/2] drm/i915: Redo "Remove i915_request.lock requirement for execution callbacks" URL : https://patchwork.freedesktop.org/series/82091/ State : success == Summary == CI Bug Log - changes from CI_DRM_9056_full -> Patchwork_18571_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18571_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 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-glk6/igt@gem_exec_reloc@basic-many-act...@vcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18571/shard-glk4/igt@gem_exec_reloc@basic-many-act...@vcs0.html * igt@gem_mmap_offset@blt-coherency: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#2328]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-glk8/igt@gem_mmap_off...@blt-coherency.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18571/shard-glk5/igt@gem_mmap_off...@blt-coherency.html * igt@gem_softpin@noreloc-s3: - shard-apl: [PASS][5] -> [INCOMPLETE][6] ([i915#1635]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-apl8/igt@gem_soft...@noreloc-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18571/shard-apl7/igt@gem_soft...@noreloc-s3.html - shard-glk: [PASS][7] -> [FAIL][8] ([fdo#103375]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-glk5/igt@gem_soft...@noreloc-s3.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18571/shard-glk4/igt@gem_soft...@noreloc-s3.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ac-hdmi-a1-hdmi-a2: - shard-glk: [PASS][9] -> [FAIL][10] ([i915#79]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-glk5/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ac-hdmi-a1-hdmi-a2.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18571/shard-glk9/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ac-hdmi-a1-hdmi-a2.html * igt@kms_flip@2x-flip-vs-fences@ab-vga1-hdmi-a1: - shard-hsw: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-hsw7/igt@kms_flip@2x-flip-vs-fen...@ab-vga1-hdmi-a1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18571/shard-hsw1/igt@kms_flip@2x-flip-vs-fen...@ab-vga1-hdmi-a1.html * igt@kms_flip@2x-flip-vs-suspend-interruptible@bc-vga1-hdmi-a1: - shard-hsw: [PASS][13] -> [INCOMPLETE][14] ([i915#2055]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-hsw6/igt@kms_flip@2x-flip-vs-suspend-interrupti...@bc-vga1-hdmi-a1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18571/shard-hsw2/igt@kms_flip@2x-flip-vs-suspend-interrupti...@bc-vga1-hdmi-a1.html * igt@kms_flip@flip-vs-expired-vblank@b-edp1: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#79]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-skl1/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18571/shard-skl6/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html * igt@kms_flip@flip-vs-suspend@a-edp1: - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +7 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-skl2/igt@kms_flip@flip-vs-susp...@a-edp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18571/shard-skl2/igt@kms_flip@flip-vs-susp...@a-edp1.html * igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-render: - shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-tglb2/igt@kms_frontbuffer_track...@fbcpsr-rgb565-draw-render.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18571/shard-tglb7/igt@kms_frontbuffer_track...@fbcpsr-rgb565-draw-render.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-kbl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18571/shard-kbl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145] / [i915#265]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-skl10/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [24]:
Re: [Intel-gfx] [PATCH][next] drm/i915: Fix inconsistent IS_ERR and PTR_ERR
Hi all,
Friendly ping: who can take this?
Thanks
--
Gustavo
On 9/10/20 05:21, Gustavo A. R. Silva wrote:
> Fix inconsistent IS_ERR and PTR_ERR in i915_gem_object_copy_blt().
>
> The proper pointer to be passed as argument to PTR_ERR() is vma[1].
>
> This bug was detected with the help of Coccinelle.
>
> Fixes: 6b05030496f7 ("drm/i915: Convert i915_gem_object/client_blt.c to use
> ww locking as well, v2.")
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object_blt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> index d93eb36160c9..aee7ad3cc3c6 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_blt.c
> @@ -364,7 +364,7 @@ int i915_gem_object_copy_blt(struct drm_i915_gem_object
> *src,
>
> vma[1] = i915_vma_instance(dst, vm, NULL);
> if (IS_ERR(vma[1]))
> - return PTR_ERR(vma);
> + return PTR_ERR(vma[1]);
>
> i915_gem_ww_ctx_init(, true);
> intel_engine_pm_get(ce->engine);
>
___
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 Fri, Sep 25, 2020 at 01:29:49PM +0100, Tvrtko Ursulin wrote: > > On 25/09/2020 12:58, Jason Gunthorpe wrote: > > On Fri, Sep 25, 2020 at 12:41:29PM +0100, Tvrtko Ursulin wrote: > > > > > > On 25/09/2020 08:13, Leon Romanovsky wrote: > > > > On Thu, Sep 24, 2020 at 09:21:20AM +0100, Tvrtko Ursulin wrote: > > > > > > > > > > On 22/09/2020 09:39, Leon Romanovsky wrote: > > > > > > 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). > > > > > > > > > > So it's appending and growing the "list", did I get that right? > > > > > Sounds handy > > > > > indeed. Some comments/questions below. > > > > > > > > Yes, we (RDMA) use this function to chain contiguous pages. > > > > > > I will eveluate if i915 could start using it. We have some loops which > > > build > > > page by page and coalesce. > > > > Christoph H doesn't like it, but if there are enough cases we should > > really have a pin_user_pages_to_sg() rather than open code this all > > over the place. > > > > With THP the chance of getting a coalescing SG is much higher, and > > everything is more efficient with larger SGEs. > > Right, I was actually referring to i915 sites where we build sg tables out > of shmem and plain kernel pages. In those areas we have some open coded > coalescing loops (see for instance our shmem_get_pages). Plus a local "trim" > to discard the unused entries, since we allocate pessimistically not knowing > how coalescing will pan out. This kind of core function which appends pages > could replace some of that. Maybe it would be slightly less efficient but I > will pencil in to at least evaluate it. > > Otherwise I do agree that coalescing is a win and in the past I have > measured savings in a few MiB range just for struct scatterlist storage. I think the eventual dream is to have a pin_user_pages_bvec or similar that is integrated into the GUP logic so avoids all the extra work, just allocates pages of bvecs on the fly. No extra step through a linear array of page *'s Starting to structuring things to take advantage of that makes some sense Jason ___ 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 Fri, Sep 25, 2020 at 10:13:30AM +0300, Leon Romanovsky wrote:
> > > diff --git a/tools/testing/scatterlist/main.c
> > > b/tools/testing/scatterlist/main.c
> > > index 0a1464181226..4899359a31ac 100644
> > > +++ b/tools/testing/scatterlist/main.c
> > > @@ -55,14 +55,13 @@ int main(void)
> > > for (i = 0, test = tests; test->expected_segments; test++, i++)
> > > {
> > > struct page *pages[MAX_PAGES];
> > > struct sg_table st;
> > > - int ret;
> > > + struct scatterlist *sg;
> > >
> > > set_pages(pages, test->pfn, test->num_pages);
> > >
> > > - ret = __sg_alloc_table_from_pages(, pages, test->num_pages,
> > > - 0, test->size, test->max_seg,
> > > - GFP_KERNEL);
> > > - assert(ret == test->alloc_ret);
> > > + sg = __sg_alloc_table_from_pages(, pages, test->num_pages, 0,
> > > + test->size, test->max_seg, NULL, 0, GFP_KERNEL);
> > > + assert(PTR_ERR_OR_ZERO(sg) == test->alloc_ret);
> >
> > Some test coverage for relatively complex code would be very welcomed. Since
> > the testing framework is already there, even if it bit-rotted a bit, but
> > shouldn't be hard to fix.
> >
> > A few tests to check append/grow works as expected, in terms of how the end
> > table looks like given the initial state and some different page patterns
> > added to it. And both crossing and not crossing into sg chaining scenarios.
>
> This function is basic for all RDMA devices and we are pretty confident
> that the old and new flows are tested thoroughly.
Well, since 0-day is reporting that __i915_gem_userptr_alloc_pages is
crashing on this, it probably does need some tests :\
Jason
___
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 9/25/2020 2:55 PM, Jason Gunthorpe wrote:
On Fri, Sep 25, 2020 at 10:13:30AM +0300, Leon Romanovsky wrote:
diff --git a/tools/testing/scatterlist/main.c b/tools/testing/scatterlist/main.c
index 0a1464181226..4899359a31ac 100644
+++ b/tools/testing/scatterlist/main.c
@@ -55,14 +55,13 @@ int main(void)
for (i = 0, test = tests; test->expected_segments; test++, i++) {
struct page *pages[MAX_PAGES];
struct sg_table st;
- int ret;
+ struct scatterlist *sg;
set_pages(pages, test->pfn, test->num_pages);
- ret = __sg_alloc_table_from_pages(, pages, test->num_pages,
- 0, test->size, test->max_seg,
- GFP_KERNEL);
- assert(ret == test->alloc_ret);
+ sg = __sg_alloc_table_from_pages(, pages, test->num_pages, 0,
+ test->size, test->max_seg, NULL, 0, GFP_KERNEL);
+ assert(PTR_ERR_OR_ZERO(sg) == test->alloc_ret);
Some test coverage for relatively complex code would be very welcomed. Since
the testing framework is already there, even if it bit-rotted a bit, but
shouldn't be hard to fix.
A few tests to check append/grow works as expected, in terms of how the end
table looks like given the initial state and some different page patterns
added to it. And both crossing and not crossing into sg chaining scenarios.
This function is basic for all RDMA devices and we are pretty confident
that the old and new flows are tested thoroughly.
Well, since 0-day is reporting that __i915_gem_userptr_alloc_pages is
crashing on this, it probably does need some tests :\
Jason
It is crashing in the regular old flow which already tested.
However, I will add more tests.
___
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 Fri, Sep 25, 2020 at 12:41:29PM +0100, Tvrtko Ursulin wrote: > > On 25/09/2020 08:13, Leon Romanovsky wrote: > > On Thu, Sep 24, 2020 at 09:21:20AM +0100, Tvrtko Ursulin wrote: > > > > > > On 22/09/2020 09:39, Leon Romanovsky wrote: > > > > 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). > > > > > > So it's appending and growing the "list", did I get that right? Sounds > > > handy > > > indeed. Some comments/questions below. > > > > Yes, we (RDMA) use this function to chain contiguous pages. > > I will eveluate if i915 could start using it. We have some loops which build > page by page and coalesce. Christoph H doesn't like it, but if there are enough cases we should really have a pin_user_pages_to_sg() rather than open code this all over the place. With THP the chance of getting a coalescing SG is much higher, and everything is more efficient with larger SGEs. Jason ___ 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 9/25/2020 2:41 PM, Tvrtko Ursulin wrote:
On 25/09/2020 08:13, Leon Romanovsky wrote:
On Thu, Sep 24, 2020 at 09:21:20AM +0100, Tvrtko Ursulin wrote:
On 22/09/2020 09:39, Leon Romanovsky wrote:
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).
So it's appending and growing the "list", did I get that right?
Sounds handy
indeed. Some comments/questions below.
Yes, we (RDMA) use this function to chain contiguous pages.
I will eveluate if i915 could start using it. We have some loops which
build page by page and coalesce.
[snip]
if (unlikely(ret))
diff --git a/tools/testing/scatterlist/main.c
b/tools/testing/scatterlist/main.c
index 0a1464181226..4899359a31ac 100644
--- a/tools/testing/scatterlist/main.c
+++ b/tools/testing/scatterlist/main.c
@@ -55,14 +55,13 @@ int main(void)
for (i = 0, test = tests; test->expected_segments; test++,
i++) {
struct page *pages[MAX_PAGES];
struct sg_table st;
- int ret;
+ struct scatterlist *sg;
set_pages(pages, test->pfn, test->num_pages);
- ret = __sg_alloc_table_from_pages(, pages,
test->num_pages,
- 0, test->size, test->max_seg,
- GFP_KERNEL);
- assert(ret == test->alloc_ret);
+ sg = __sg_alloc_table_from_pages(, pages,
test->num_pages, 0,
+ test->size, test->max_seg, NULL, 0, GFP_KERNEL);
+ assert(PTR_ERR_OR_ZERO(sg) == test->alloc_ret);
Some test coverage for relatively complex code would be very
welcomed. Since
the testing framework is already there, even if it bit-rotted a bit,
but
shouldn't be hard to fix.
A few tests to check append/grow works as expected, in terms of how
the end
table looks like given the initial state and some different page
patterns
added to it. And both crossing and not crossing into sg chaining
scenarios.
This function is basic for all RDMA devices and we are pretty confident
that the old and new flows are tested thoroughly.
We will add proper test in next kernel cycle.
Patch seems to be adding a requirement that all callers of
(__)sg_alloc_table_from_pages pass in zeroed struct sg_table, which
wasn't the case so far.
Have you audited all the callers and/or fixed them? There seems to be
quite a few. Gut feel says problem would probably be better solved in
lib/scatterlist.c and not by making all the callers memset. Should be
possible if you make sure you only read st->nents if prev was passed in?
I've fixed the unit test and with this change the existing tests do
pass. But without zeroing it does fail on the very first, single page,
test scenario.
You can pull the unit test hacks from
git://people.freedesktop.org/~tursulin/drm-intel sgtest.
Regards,
Tvrtko
Thanks for finding this issue. In the regular flow,
__sg_alloc_table_from_pages memset the sg_table struct, but currently
the code access this struct before. Will be fixed internally in scatterlist.
___
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 9/25/2020 3:33 PM, Tvrtko Ursulin wrote:
On 25/09/2020 13:18, Maor Gottlieb wrote:
On 9/25/2020 2:55 PM, Jason Gunthorpe wrote:
On Fri, Sep 25, 2020 at 10:13:30AM +0300, Leon Romanovsky wrote:
diff --git a/tools/testing/scatterlist/main.c
b/tools/testing/scatterlist/main.c
index 0a1464181226..4899359a31ac 100644
+++ b/tools/testing/scatterlist/main.c
@@ -55,14 +55,13 @@ int main(void)
for (i = 0, test = tests; test->expected_segments; test++,
i++) {
struct page *pages[MAX_PAGES];
struct sg_table st;
- int ret;
+ struct scatterlist *sg;
set_pages(pages, test->pfn, test->num_pages);
- ret = __sg_alloc_table_from_pages(, pages,
test->num_pages,
- 0, test->size, test->max_seg,
- GFP_KERNEL);
- assert(ret == test->alloc_ret);
+ sg = __sg_alloc_table_from_pages(, pages,
test->num_pages, 0,
+ test->size, test->max_seg, NULL, 0, GFP_KERNEL);
+ assert(PTR_ERR_OR_ZERO(sg) == test->alloc_ret);
Some test coverage for relatively complex code would be very
welcomed. Since
the testing framework is already there, even if it bit-rotted a
bit, but
shouldn't be hard to fix.
A few tests to check append/grow works as expected, in terms of
how the end
table looks like given the initial state and some different page
patterns
added to it. And both crossing and not crossing into sg chaining
scenarios.
This function is basic for all RDMA devices and we are pretty
confident
that the old and new flows are tested thoroughly.
Well, since 0-day is reporting that __i915_gem_userptr_alloc_pages is
crashing on this, it probably does need some tests :\
Jason
It is crashing in the regular old flow which already tested.
However, I will add more tests.
Do you want to take some of the commits from
git://people.freedesktop.org/~tursulin/drm-intel sgtest? It would be
fine by me. I can clean up the commit messages if you want.
I will very appreciate it. Thanks
https://cgit.freedesktop.org/~tursulin/drm-intel/commit/?h=sgtest=79102f4d795c4769431fc44a6cf7ed5c5b1b5214
- this one undoes the bit rot and makes the test just work on the
current kernel.
https://cgit.freedesktop.org/~tursulin/drm-intel/commit/?h=sgtest=b09bfe80486c4d93ee1d8ae17d5b46397b1c6ee1
- this one you probably should squash in your patch. Minus the zeroing
of struct sg_stable since that would hide the issue.
https://cgit.freedesktop.org/~tursulin/drm-intel/commit/?h=sgtest=97f5df37e612f798ced90541eece13e2ef639181
- final commit is optional but I guess handy for debugging.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/11] x86/xen: open code alloc_vm_area in arch_gnttab_valloc
On 9/24/20 9:58 AM, Christoph Hellwig wrote: > Replace the last call to alloc_vm_area with an open coded version using > an iterator in struct gnttab_vm_area instead of the triple indirection > magic in alloc_vm_area. > > Signed-off-by: Christoph Hellwig Reviewed-by: Boris Ostrovsky ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/11] xen/xenbus: use apply_to_page_range directly in xenbus_map_ring_pv
On 9/24/20 9:58 AM, Christoph Hellwig wrote: > Replacing alloc_vm_area with get_vm_area_caller + apply_page_range > allows to fill put the phys_addr values directly instead of doing > another loop over all addresses. > > Signed-off-by: Christoph Hellwig Reviewed-by: Boris Ostrovsky -boris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/atomic: document and enforce rules around "spurious" EBUSY
== Series Details == Series: series starting with [1/2] drm/atomic: document and enforce rules around "spurious" EBUSY URL : https://patchwork.freedesktop.org/series/82086/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9056_full -> Patchwork_18570_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18570_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18570_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_18570_full: ### IGT changes ### Possible regressions * igt@kms_cursor_crc@pipe-c-cursor-64x21-sliding: - shard-hsw: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18570/shard-hsw1/igt@kms_cursor_...@pipe-c-cursor-64x21-sliding.html * igt@kms_cursor_legacy@short-flip-after-cursor-atomic-transitions: - shard-glk: [PASS][2] -> [FAIL][3] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-glk5/igt@kms_cursor_leg...@short-flip-after-cursor-atomic-transitions.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18570/shard-glk8/igt@kms_cursor_leg...@short-flip-after-cursor-atomic-transitions.html Known issues Here are the changes found in Patchwork_18570_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-mixed-process@blt: - shard-apl: [PASS][4] -> [FAIL][5] ([i915#1635] / [i915#2374]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-apl1/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18570/shard-apl2/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html * igt@gem_exec_reloc@basic-many-active@vcs0: - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2389]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-glk6/igt@gem_exec_reloc@basic-many-act...@vcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18570/shard-glk9/igt@gem_exec_reloc@basic-many-act...@vcs0.html * igt@gem_flink_race@flink_close: - shard-iclb: [PASS][8] -> [DMESG-WARN][9] ([i915#1982]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-iclb6/igt@gem_flink_race@flink_close.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18570/shard-iclb2/igt@gem_flink_race@flink_close.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][10] -> [SKIP][11] ([i915#2190]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-tglb7/igt@gem_huc_c...@huc-copy.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18570/shard-tglb6/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_offset@blt-coherency: - shard-glk: [PASS][12] -> [FAIL][13] ([i915#2328]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-glk8/igt@gem_mmap_off...@blt-coherency.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18570/shard-glk5/igt@gem_mmap_off...@blt-coherency.html * igt@i915_selftest@mock@contexts: - shard-apl: [PASS][14] -> [INCOMPLETE][15] ([i915#1635] / [i915#2278]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-apl8/igt@i915_selftest@m...@contexts.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18570/shard-apl8/igt@i915_selftest@m...@contexts.html * igt@kms_flip@2x-wf_vblank-ts-check-interruptible@ab-vga1-hdmi-a1: - shard-hsw: [PASS][16] -> [DMESG-WARN][17] ([i915#1982]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-hsw4/igt@kms_flip@2x-wf_vblank-ts-check-interrupti...@ab-vga1-hdmi-a1.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18570/shard-hsw6/igt@kms_flip@2x-wf_vblank-ts-check-interrupti...@ab-vga1-hdmi-a1.html * igt@kms_flip@flip-vs-suspend@a-edp1: - shard-skl: [PASS][18] -> [DMESG-WARN][19] ([i915#1982]) +11 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-skl2/igt@kms_flip@flip-vs-susp...@a-edp1.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18570/shard-skl1/igt@kms_flip@flip-vs-susp...@a-edp1.html * igt@kms_flip@plain-flip-fb-recreate-interruptible@a-hdmi-a1: - shard-glk: [PASS][20] -> [FAIL][21] ([i915#2122]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/shard-glk6/igt@kms_flip@plain-flip-fb-recreate-interrupti...@a-hdmi-a1.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18570/shard-glk9/igt@kms_flip@plain-flip-fb-recreate-interrupti...@a-hdmi-a1.html
Re: [Intel-gfx] [PATCH 3/4] drm/i915/gt: Always send a pulse down the engine after disabling heartbeat
Quoting Tvrtko Ursulin (2020-09-25 14:19:22)
>
> On 25/09/2020 11:01, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-09-24 14:43:08)
> >>
> >> On 16/09/2020 10:42, Chris Wilson wrote:
> >>> Currently, we check we can send a pulse prior to disabling the
> >>> heartbeat to verify that we can change the heartbeat, but since we may
> >>> re-evaluate execution upon changing the heartbeat interval we need another
> >>> pulse afterwards to refresh execution.
> >>>
> >>> Fixes: 9a40bddd47ca ("drm/i915/gt: Expose heartbeat interval via sysfs")
> >>> Signed-off-by: Chris Wilson
> >>> Cc: Joonas Lahtinen
> >>> Cc: # v5.7+
> >>> ---
> >>>drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 6 --
> >>>1 file changed, 4 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> >>> b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> >>> index 8ffdf676c0a0..d09df370f7cd 100644
> >>> --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> >>> +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> >>> @@ -192,10 +192,12 @@ int intel_engine_set_heartbeat(struct
> >>> intel_engine_cs *engine,
> >>>WRITE_ONCE(engine->props.heartbeat_interval_ms, delay);
> >>>
> >>>if (intel_engine_pm_get_if_awake(engine)) {
> >>> - if (delay)
> >>> + if (delay) {
> >>>intel_engine_unpark_heartbeat(engine);
> >>> - else
> >>> + } else {
> >>>intel_engine_park_heartbeat(engine);
> >>> + intel_engine_pulse(engine); /* recheck execution */
> >>> + }
> >>>intel_engine_pm_put(engine);
> >>>}
> >>>
> >>>
> >>
> >> I did not immediately get this one. Do we really need two pulses or
> >> maybe we could re-order the code a bit and just undo the heartbeat park
> >> if pulse after parking did not work?
> >
> > We use the first pulse to determine if it's legal for the parameter to
> > be changed (checking we support the preemptive pulse to remove
> > non-persistent contexts). Then the second pulse after changing the
> > parameter to flush the changes through.
> >
> > I like checking for support before making the change, although we could
> > try and fixup after failure, there would still be a window where the
> > change would be visible to the system. We don't need to use the pulse per
> > se for that check, that's pure convenience as it performs the checking
> > already.
>
> Hm second pulse also has a problem that sneaky user can nerf it with a
> precisely timed SIGINT on itself. It's a bit ridiculous isn't it? :)
Sufficient pause for concern. In both this and the kill_context path, we
are using the pulse to evict hostile contexts, that could be reasonable
grounds to have the pulse not be interrupted.
> Have engine preemption check open coded first and uninterruptible
> flavour of pulse sending? It's also not good since we do want it to be
> interruptible..
Right, allowing it to be interruptible does ensure we have an escape
plan. That escape plan is often invaluable. :|
> Unwind the change and report error back to write(2) if
> intel_engine_pulse failed for any reason?
The concern then is how atomic do we want the change to appear to be.
Would it be sufficient to only rollback after error if the value still
matches (multiple users), cmpxchg for paranoia. Then anything that
observes the intermediate value will just have to obey the new rules
temporarily, as they would have to in future if the change succeeded.
new = strtoull_from_user();
/* validate new */
old = xchg(, new);
/* apply changes */
if (err)
cmpxchg(, new, old);
If heartbeat is changed in the interval, the pulse either uses the new
or the new-new value, fail/pass regardless. That could mean we report an
error for another heartbeat value from a second user. That's arguing for
a mutex guard for the sysfs writes.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/11] drm/i915: use vmap in i915_gem_object_map
On Thu, 24 Sep 2020 at 14:59, Christoph Hellwig wrote:
>
> i915_gem_object_map implements fairly low-level vmap functionality in
> a driver. Split it into two helpers, one for remapping kernel memory
> which can use vmap, and one for I/O memory that uses vmap_pfn.
>
> The only practical difference is that alloc_vm_area prefeaults the
> vmalloc area PTEs, which doesn't seem to be required here for the
> kernel memory case (and could be added to vmap using a flag if actually
> required).
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/Kconfig | 1 +
> drivers/gpu/drm/i915/gem/i915_gem_pages.c | 126 ++
> 2 files changed, 59 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 9afa5c4a6bf006..1e1cb245fca778 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -25,6 +25,7 @@ config DRM_I915
> select CRC32
> select SND_HDA_I915 if SND_HDA_CORE
> select CEC_CORE if CEC_NOTIFIER
> + select VMAP_PFN
> help
> Choose this option if you have a system that has "Intel Graphics
> Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index 6550c0bc824ea2..b519417667eb4b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -232,34 +232,21 @@ int __i915_gem_object_put_pages(struct
> drm_i915_gem_object *obj)
> return err;
> }
>
> -static inline pte_t iomap_pte(resource_size_t base,
> - dma_addr_t offset,
> - pgprot_t prot)
> -{
> - return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
> -}
> -
> /* The 'mapping' part of i915_gem_object_pin_map() below */
> -static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
> -enum i915_map_type type)
> +static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj,
> + enum i915_map_type type)
> {
> - unsigned long n_pte = obj->base.size >> PAGE_SHIFT;
> - struct sg_table *sgt = obj->mm.pages;
> - pte_t *stack[32], **mem;
> - struct vm_struct *area;
> + unsigned long n_pages = obj->base.size >> PAGE_SHIFT, i;
> + struct page *stack[32], **pages = stack, *page;
> + struct sgt_iter iter;
> pgprot_t pgprot;
> + void *vaddr;
>
> - if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC)
> - return NULL;
> -
> - if (GEM_WARN_ON(type == I915_MAP_WC &&
> - !static_cpu_has(X86_FEATURE_PAT)))
> - return NULL;
> -
> - /* A single page can always be kmapped */
> - if (n_pte == 1 && type == I915_MAP_WB) {
> - struct page *page = sg_page(sgt->sgl);
> -
> + switch (type) {
> + default:
> + MISSING_CASE(type);
> + fallthrough;/* to use PAGE_KERNEL anyway */
> + case I915_MAP_WB:
> /*
> * On 32b, highmem using a finite set of indirect PTE (i.e.
> * vmap) to provide virtual mappings of the high pages.
> @@ -277,30 +264,8 @@ static void *i915_gem_object_map(struct
> drm_i915_gem_object *obj,
> * So if the page is beyond the 32b boundary, make an explicit
> * vmap.
> */
> - if (!PageHighMem(page))
> - return page_address(page);
> - }
> -
> - mem = stack;
> - if (n_pte > ARRAY_SIZE(stack)) {
> - /* Too big for stack -- allocate temporary array instead */
> - mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
> - if (!mem)
> - return NULL;
> - }
> -
> - area = alloc_vm_area(obj->base.size, mem);
> - if (!area) {
> - if (mem != stack)
> - kvfree(mem);
> - return NULL;
> - }
> -
> - switch (type) {
> - default:
> - MISSING_CASE(type);
> - fallthrough;/* to use PAGE_KERNEL anyway */
> - case I915_MAP_WB:
> + if (n_pages == 1 && !PageHighMem(sg_page(obj->mm.pages->sgl)))
> + return page_address(sg_page(obj->mm.pages->sgl));
> pgprot = PAGE_KERNEL;
> break;
> case I915_MAP_WC:
> @@ -308,30 +273,49 @@ static void *i915_gem_object_map(struct
> drm_i915_gem_object *obj,
> break;
> }
>
> - if (i915_gem_object_has_struct_page(obj)) {
> - struct sgt_iter iter;
> - struct page *page;
> - pte_t **ptes = mem;
> + if (n_pages > ARRAY_SIZE(stack)) {
> + /* Too big for stack -- allocate
Re: [Intel-gfx] [PATCH rdma-next v3 1/2] lib/scatterlist: Add support in dynamic allocation of SG table from pages
On 25/09/2020 14:39, Maor Gottlieb wrote:
On 9/25/2020 3:33 PM, Tvrtko Ursulin wrote:
On 25/09/2020 13:18, Maor Gottlieb wrote:
On 9/25/2020 2:55 PM, Jason Gunthorpe wrote:
On Fri, Sep 25, 2020 at 10:13:30AM +0300, Leon Romanovsky wrote:
diff --git a/tools/testing/scatterlist/main.c
b/tools/testing/scatterlist/main.c
index 0a1464181226..4899359a31ac 100644
+++ b/tools/testing/scatterlist/main.c
@@ -55,14 +55,13 @@ int main(void)
for (i = 0, test = tests; test->expected_segments; test++,
i++) {
struct page *pages[MAX_PAGES];
struct sg_table st;
- int ret;
+ struct scatterlist *sg;
set_pages(pages, test->pfn, test->num_pages);
- ret = __sg_alloc_table_from_pages(, pages,
test->num_pages,
- 0, test->size, test->max_seg,
- GFP_KERNEL);
- assert(ret == test->alloc_ret);
+ sg = __sg_alloc_table_from_pages(, pages,
test->num_pages, 0,
+ test->size, test->max_seg, NULL, 0, GFP_KERNEL);
+ assert(PTR_ERR_OR_ZERO(sg) == test->alloc_ret);
Some test coverage for relatively complex code would be very
welcomed. Since
the testing framework is already there, even if it bit-rotted a
bit, but
shouldn't be hard to fix.
A few tests to check append/grow works as expected, in terms of
how the end
table looks like given the initial state and some different page
patterns
added to it. And both crossing and not crossing into sg chaining
scenarios.
This function is basic for all RDMA devices and we are pretty
confident
that the old and new flows are tested thoroughly.
Well, since 0-day is reporting that __i915_gem_userptr_alloc_pages is
crashing on this, it probably does need some tests :\
Jason
It is crashing in the regular old flow which already tested.
However, I will add more tests.
Do you want to take some of the commits from
git://people.freedesktop.org/~tursulin/drm-intel sgtest? It would be
fine by me. I can clean up the commit messages if you want.
I will very appreciate it. Thanks
I've pushed a branch with tidied commit messages and a bit re-ordered to
the same location. You can pull and include in your series:
tools/testing/scatterlist: Rejuvenate bit-rotten test
tools/testing/scatterlist: Show errors in human readable form
And "test fixes for sg append" you can squash (minus the sg_table
zeroing) into your patch.
If this plan does not work for you, I can send two of my patches to lkml
independently. What ever you prefer.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Finish (de)gamma readout prep bits
== Series Details ==
Series: drm/i915: Finish (de)gamma readout prep bits
URL : https://patchwork.freedesktop.org/series/82099/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9056 -> Patchwork_18575
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18575/index.html
Known issues
Here are the changes found in Patchwork_18575 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_9056/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18575/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +2 similar
issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18575/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
Possible fixes
* igt@kms_busy@basic@flip:
- {fi-tgl-dsi}: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18575/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
- fi-kbl-x1275: [DMESG-WARN][7] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18575/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18575/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@gem_exec_suspend@basic-s3:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][12] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18575/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) ->
[DMESG-WARN][14] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18575/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][16] ([i915#62] / [i915#92]) +4 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18575/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#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
[k.org#205379]: https://bugzilla.kernel.org/show_bug.cgi?id=205379
Participating hosts (46 -> 39)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_9056 -> Patchwork_18575
CI-20190529: 20190529
CI_DRM_9056: 637f215bda901249b97da25ee2983f72cc12e1c5 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5788: a7520973a210b7268c3039902789f433ee0f5ef7 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18575: 7730cfbdab97c0ba827c7047513546a43a4fb723 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7730cfbdab97 drm/i915: Replace some gamma_mode ifs with switches
8be5dd40339c drm/i915: Polish bdw_read_lut_10() a bit
ffd8429c6769 drm/i915: Relocate CHV CGM gamma masks
[Intel-gfx] [PATCH 3/9] drm/i915: Include the LUT sizes in the state dump
From: Ville Syrjälä Dump the sizes of the software LUTs in the state dump. Makes it a bit easier to see which is present without having to decode it from the gamma_mode and other bits of state. v2: Drop a spurious "is" in commit msg (Uma) Reviewed-by: Uma Shankar Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index e5ba8dbbca1b..dadf8959f625 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -13197,6 +13197,12 @@ static void intel_dump_pipe_config(const struct intel_crtc_state *pipe_config, pipe_config->csc_mode, pipe_config->gamma_mode, pipe_config->gamma_enable, pipe_config->csc_enable); + drm_dbg_kms(_priv->drm, "degamma lut: %d entries, gamma lut: %d entries\n", + pipe_config->hw.degamma_lut ? + drm_color_lut_size(pipe_config->hw.degamma_lut) : 0, + pipe_config->hw.gamma_lut ? + drm_color_lut_size(pipe_config->hw.gamma_lut) : 0); + dump_planes: if (!state) return; -- 2.26.2 ___ 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: Finish (de)gamma readout prep bits
== Series Details == Series: drm/i915: Finish (de)gamma readout prep bits URL : https://patchwork.freedesktop.org/series/82099/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_reset.c:1311:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gvt/mmio.c:290:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1440:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1494:15: warning: memset with byte count of 16777216 +./include/linux/seqlock.h:752:24: warning: trying to copy expression type 31 +./include/linux/seqlock.h:778:16: warning: trying to copy expression type 31 +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' - different lock contexts for basic block ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/gem: Always test execution status on closing the context
On 25/09/2020 11:05, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-09-24 15:26:56)
On 16/09/2020 10:42, Chris Wilson wrote:
Verify that if a context is active at the time it is closed, that it is
either persistent and preemptible (with hangcheck running) or it shall
be removed from execution.
Fixes: 9a40bddd47ca ("drm/i915/gt: Expose heartbeat interval via sysfs")
Testcase: igt/gem_ctx_persistence/heartbeat-close
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: # v5.7+
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 48 +
1 file changed, 10 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index a548626fa8bc..4fd38101bb56 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -390,24 +390,6 @@ __context_engines_static(const struct i915_gem_context
*ctx)
return rcu_dereference_protected(ctx->engines, true);
}
-static bool __reset_engine(struct intel_engine_cs *engine)
-{
- struct intel_gt *gt = engine->gt;
- bool success = false;
-
- if (!intel_has_reset_engine(gt))
- return false;
-
- if (!test_and_set_bit(I915_RESET_ENGINE + engine->id,
- >reset.flags)) {
- success = intel_engine_reset(engine, NULL) == 0;
- clear_and_wake_up_bit(I915_RESET_ENGINE + engine->id,
- >reset.flags);
- }
-
- return success;
-}
-
static void __reset_context(struct i915_gem_context *ctx,
struct intel_engine_cs *engine)
{
@@ -431,12 +413,7 @@ static bool __cancel_engine(struct intel_engine_cs *engine)
* kill the banned context, we fallback to doing a local reset
* instead.
*/
- if (IS_ACTIVE(CONFIG_DRM_I915_PREEMPT_TIMEOUT) &&
- !intel_engine_pulse(engine))
- return true;
-
- /* If we are unable to send a pulse, try resetting this engine. */
- return __reset_engine(engine);
+ return intel_engine_pulse(engine) == 0;
Where is the path now which actually resets the currently running
workload (engine) of a non-persistent context? Pulse will be sent and
then rely on hangcheck but otherwise let it run?
If the pulse fails, we just call intel_handle_error() on the engine. On
looking at this code again, I could not justify the open-coding of the
engine reset fragment of the general error handler, especially as we end
up taking that route anyway for device resets. (Unlike inside the
tasklet, there's no atomicity concerns on this engine-reset path.)
I think yesterday I got lost in boolean logic and flows here. Today it
looks fine. Bool ban will be true and code will indeed enter the
__kill_context path.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/9] drm/i915: Fix state checker hw.active/hw.enable readout
From: Ville Syrjälä
Previously intel_dump_pipe_config() used to dump the full crtc state
whether or not the crtc was logically enabled or not. As that meant
occasionally dumping confusing stale garbage I changed it to
check whether the crtc is logically enabled or not. However I did
not realize that the state checker readout code does not
populate crtc_state.hw.{active,enabled}. Hence the state checker
dump would only give us a full dump of the sw state but not the hw
state. Fix that by populating those bits of the hw state as well.
Reviewed-by: Uma Shankar
Fixes: 10d75f5428fd ("drm/i915: Fix plane state dumps")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 5a9d933e425a..d64e46acfbbd 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14304,7 +14304,6 @@ verify_crtc_state(struct intel_crtc *crtc,
struct intel_encoder *encoder;
struct intel_crtc_state *pipe_config = old_crtc_state;
struct drm_atomic_state *state = old_crtc_state->uapi.state;
- bool active;
__drm_atomic_helper_crtc_destroy_state(_crtc_state->uapi);
intel_crtc_free_hw_state(old_crtc_state);
@@ -14314,16 +14313,19 @@ verify_crtc_state(struct intel_crtc *crtc,
drm_dbg_kms(_priv->drm, "[CRTC:%d:%s]\n", crtc->base.base.id,
crtc->base.name);
- active = dev_priv->display.get_pipe_config(crtc, pipe_config);
+ pipe_config->hw.enable = new_crtc_state->hw.enable;
+
+ pipe_config->hw.active =
+ dev_priv->display.get_pipe_config(crtc, pipe_config);
/* we keep both pipes enabled on 830 */
- if (IS_I830(dev_priv))
- active = new_crtc_state->hw.active;
+ if (IS_I830(dev_priv) && pipe_config->hw.active)
+ pipe_config->hw.active = new_crtc_state->hw.active;
- I915_STATE_WARN(new_crtc_state->hw.active != active,
+ I915_STATE_WARN(new_crtc_state->hw.active != pipe_config->hw.active,
"crtc active state doesn't match with hw state "
"(expected %i, found %i)\n",
- new_crtc_state->hw.active, active);
+ new_crtc_state->hw.active, pipe_config->hw.active);
I915_STATE_WARN(crtc->active != new_crtc_state->hw.active,
"transitional active state does not match atomic hw
state "
@@ -14332,6 +14334,7 @@ verify_crtc_state(struct intel_crtc *crtc,
for_each_encoder_on_crtc(dev, >base, encoder) {
enum pipe pipe;
+ bool active;
active = encoder->get_hw_state(encoder, );
I915_STATE_WARN(active != new_crtc_state->hw.active,
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/9] drm/i915: Finish (de)gamma readout prep bits
From: Ville Syrjälä The easy prep stuff from my earlier (de)gamma readout series. All reviewed already by Uma (thanks). The rest of that series still needs some work. Ville Syrjälä (9): drm/i915: Fix state checker hw.active/hw.enable readout drm/i915: Move MST master transcoder dump earlier drm/i915: Include the LUT sizes in the state dump drm/i915: s/glk_read_lut_10/bdw_read_lut_10/ drm/i915: Reset glk degamma index after programming/readout drm/i915: Shuffle chv_cgm_gamma_pack() around a bit drm/i915: Relocate CHV CGM gamma masks drm/i915: Polish bdw_read_lut_10() a bit drm/i915: Replace some gamma_mode ifs with switches drivers/gpu/drm/i915/display/intel_color.c | 124 ++- drivers/gpu/drm/i915/display/intel_display.c | 25 ++-- drivers/gpu/drm/i915/i915_reg.h | 9 +- 3 files changed, 113 insertions(+), 45 deletions(-) -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Add support for DP-HDMI2.1 PCON
== Series Details ==
Series: Add support for DP-HDMI2.1 PCON
URL : https://patchwork.freedesktop.org/series/82098/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9056 -> Patchwork_18574
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18574/index.html
Known issues
Here are the changes found in Patchwork_18574 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-bxt-dsi: [PASS][1] -> [DMESG-WARN][2] ([i915#1635] /
[i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-bxt-dsi/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18574/fi-bxt-dsi/igt@i915_module_l...@reload.html
- fi-icl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-icl-y/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18574/fi-icl-y/igt@i915_module_l...@reload.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18574/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
* igt@vgem_basic@unload:
- fi-skl-guc: [PASS][7] -> [DMESG-WARN][8] ([i915#2203])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-skl-guc/igt@vgem_ba...@unload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18574/fi-skl-guc/igt@vgem_ba...@unload.html
Possible fixes
* igt@kms_busy@basic@flip:
- {fi-tgl-dsi}: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18574/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18574/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18574/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18574/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
Warnings
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92]) ->
[DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-kbl-x1275/igt@i915_pm_...@basic-pci-d3-state.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18574/fi-kbl-x1275/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][19] ([i915#62]) -> [DMESG-FAIL][20]
([i915#62] / [i915#95])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18574/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
- fi-kbl-guc: [DMESG-WARN][21] ([i915#2203]) -> [DMESG-FAIL][22]
([i915#2203])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-kbl-guc/igt@i915_pm_...@module-reload.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18574/fi-kbl-guc/igt@i915_pm_...@module-reload.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][24] ([i915#62] / [i915#92]) +3 similar issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-kbl-x1275/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18574/fi-kbl-x1275/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
* igt@vgem_basic@unload:
- fi-kbl-x1275: [DMESG-WARN][25] ([i915#62] / [i915#92]) ->
[DMESG-WARN][26] ([i915#95])
[25]:
Re: [Intel-gfx] [PATCH 3/4] drm/i915/gt: Always send a pulse down the engine after disabling heartbeat
On 25/09/2020 11:01, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-09-24 14:43:08)
On 16/09/2020 10:42, Chris Wilson wrote:
Currently, we check we can send a pulse prior to disabling the
heartbeat to verify that we can change the heartbeat, but since we may
re-evaluate execution upon changing the heartbeat interval we need another
pulse afterwards to refresh execution.
Fixes: 9a40bddd47ca ("drm/i915/gt: Expose heartbeat interval via sysfs")
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: # v5.7+
---
drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 8ffdf676c0a0..d09df370f7cd 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -192,10 +192,12 @@ int intel_engine_set_heartbeat(struct intel_engine_cs
*engine,
WRITE_ONCE(engine->props.heartbeat_interval_ms, delay);
if (intel_engine_pm_get_if_awake(engine)) {
- if (delay)
+ if (delay) {
intel_engine_unpark_heartbeat(engine);
- else
+ } else {
intel_engine_park_heartbeat(engine);
+ intel_engine_pulse(engine); /* recheck execution */
+ }
intel_engine_pm_put(engine);
}
I did not immediately get this one. Do we really need two pulses or
maybe we could re-order the code a bit and just undo the heartbeat park
if pulse after parking did not work?
We use the first pulse to determine if it's legal for the parameter to
be changed (checking we support the preemptive pulse to remove
non-persistent contexts). Then the second pulse after changing the
parameter to flush the changes through.
I like checking for support before making the change, although we could
try and fixup after failure, there would still be a window where the
change would be visible to the system. We don't need to use the pulse per
se for that check, that's pure convenience as it performs the checking
already.
Hm second pulse also has a problem that sneaky user can nerf it with a
precisely timed SIGINT on itself. It's a bit ridiculous isn't it? :)
Have engine preemption check open coded first and uninterruptible
flavour of pulse sending? It's also not good since we do want it to be
interruptible.. Unwind the change and report error back to write(2) if
intel_engine_pulse failed for any reason?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/9] drm/i915: s/glk_read_lut_10/bdw_read_lut_10/
From: Ville Syrjälä
glk_read_lut_10() works just fine for all bdw+ platforms, so
rename it.
Reviewed-by: Uma Shankar
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 945bb03bdd4d..77c103a86a30 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1919,7 +1919,8 @@ static void ilk_read_luts(struct intel_crtc_state
*crtc_state)
crtc_state->hw.gamma_lut = ilk_read_lut_10(crtc);
}
-static struct drm_property_blob *glk_read_lut_10(struct intel_crtc *crtc,
+/* On BDW+ the index auto increment mode actually works */
+static struct drm_property_blob *bdw_read_lut_10(struct intel_crtc *crtc,
u32 prec_index)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -1960,7 +1961,7 @@ static void glk_read_luts(struct intel_crtc_state
*crtc_state)
if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
crtc_state->hw.gamma_lut = ilk_read_lut_8(crtc);
else
- crtc_state->hw.gamma_lut = glk_read_lut_10(crtc,
PAL_PREC_INDEX_VALUE(0));
+ crtc_state->hw.gamma_lut = bdw_read_lut_10(crtc,
PAL_PREC_INDEX_VALUE(0));
}
static struct drm_property_blob *
@@ -2016,7 +2017,7 @@ static void icl_read_luts(struct intel_crtc_state
*crtc_state)
crtc_state->hw.gamma_lut = icl_read_lut_multi_segment(crtc);
break;
default:
- crtc_state->hw.gamma_lut = glk_read_lut_10(crtc,
PAL_PREC_INDEX_VALUE(0));
+ crtc_state->hw.gamma_lut = bdw_read_lut_10(crtc,
PAL_PREC_INDEX_VALUE(0));
}
}
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/9] drm/i915: Shuffle chv_cgm_gamma_pack() around a bit
From: Ville Syrjälä
Move chv_cgm_gamma_pack() next to the other CGM gamma functions.
Right now it's stuck in the middle of the CGM degamma functions.
Reviewed-by: Uma Shankar
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 37a4fede7bc0..260bbbd5bbf2 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1030,13 +1030,6 @@ static u32 chv_cgm_degamma_udw(const struct
drm_color_lut *color)
return drm_color_lut_extract(color->red, 14);
}
-static void chv_cgm_gamma_pack(struct drm_color_lut *entry, u32 ldw, u32 udw)
-{
- entry->green =
intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_GREEN_MASK, ldw), 10);
- entry->blue =
intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_BLUE_MASK, ldw), 10);
- entry->red =
intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_RED_MASK, udw), 10);
-}
-
static void chv_load_cgm_degamma(struct intel_crtc *crtc,
const struct drm_property_blob *blob)
{
@@ -1064,6 +1057,13 @@ static u32 chv_cgm_gamma_udw(const struct drm_color_lut
*color)
return drm_color_lut_extract(color->red, 10);
}
+static void chv_cgm_gamma_pack(struct drm_color_lut *entry, u32 ldw, u32 udw)
+{
+ entry->green =
intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_GREEN_MASK, ldw), 10);
+ entry->blue =
intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_BLUE_MASK, ldw), 10);
+ entry->red =
intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_RED_MASK, udw), 10);
+}
+
static void chv_load_cgm_gamma(struct intel_crtc *crtc,
const struct drm_property_blob *blob)
{
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/9] drm/i915: Polish bdw_read_lut_10() a bit
From: Ville Syrjälä
Since bdw_read_lut_10() uses the auto-increment mode we must
have an equal number of entries in the software LUT and the
hardware LUT. WARN if that is not the case.
Reviewed-by: Uma Shankar
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 260bbbd5bbf2..290d1871ef57 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1929,12 +1929,15 @@ static struct drm_property_blob *bdw_read_lut_10(struct
intel_crtc *crtc,
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
int i, hw_lut_size = ivb_lut_10_size(prec_index);
+ int lut_size = INTEL_INFO(dev_priv)->color.gamma_lut_size;
enum pipe pipe = crtc->pipe;
struct drm_property_blob *blob;
struct drm_color_lut *lut;
+ drm_WARN_ON(_priv->drm, lut_size != hw_lut_size);
+
blob = drm_property_create_blob(_priv->drm,
- sizeof(struct drm_color_lut) *
hw_lut_size,
+ sizeof(struct drm_color_lut) * lut_size,
NULL);
if (IS_ERR(blob))
return NULL;
@@ -1944,7 +1947,7 @@ static struct drm_property_blob *bdw_read_lut_10(struct
intel_crtc *crtc,
intel_de_write(dev_priv, PREC_PAL_INDEX(pipe),
prec_index | PAL_PREC_AUTO_INCREMENT);
- for (i = 0; i < hw_lut_size; i++) {
+ for (i = 0; i < lut_size; i++) {
u32 val = intel_de_read(dev_priv, PREC_PAL_DATA(pipe));
ilk_lut_10_pack([i], val);
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/9] drm/i915: Move MST master transcoder dump earlier
From: Ville Syrjälä Move the MST master transcoder dump next to the other transcoder bits. Reviewed-by: Uma Shankar Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index d64e46acfbbd..e5ba8dbbca1b 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -13097,6 +13097,9 @@ static void intel_dump_pipe_config(const struct intel_crtc_state *pipe_config, transcoder_name(pipe_config->cpu_transcoder), pipe_config->pipe_bpp, pipe_config->dither); + drm_dbg_kms(_priv->drm, "MST master transcoder: %s\n", + transcoder_name(pipe_config->mst_master_transcoder)); + drm_dbg_kms(_priv->drm, "port sync: master transcoder: %s, slave transcoder bitmask = 0x%x\n", transcoder_name(pipe_config->master_transcoder), @@ -13194,9 +13197,6 @@ static void intel_dump_pipe_config(const struct intel_crtc_state *pipe_config, pipe_config->csc_mode, pipe_config->gamma_mode, pipe_config->gamma_enable, pipe_config->csc_enable); - drm_dbg_kms(_priv->drm, "MST master transcoder: %s\n", - transcoder_name(pipe_config->mst_master_transcoder)); - dump_planes: if (!state) return; -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/9] drm/i915: Reset glk degamma index after programming/readout
From: Ville Syrjälä Just for some extra consistency let's reset the glk degamma LUT index back to 0 after we're dong trawling the LUT. Reviewed-by: Uma Shankar Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_color.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c index 77c103a86a30..37a4fede7bc0 100644 --- a/drivers/gpu/drm/i915/display/intel_color.c +++ b/drivers/gpu/drm/i915/display/intel_color.c @@ -818,12 +818,14 @@ static void glk_load_degamma_lut(const struct intel_crtc_state *crtc_state) * as compared to just 16 to achieve this. */ intel_de_write(dev_priv, PRE_CSC_GAMC_DATA(pipe), - lut[i].green); + lut[i].green); } /* Clamp values > 1.0. */ while (i++ < 35) intel_de_write(dev_priv, PRE_CSC_GAMC_DATA(pipe), 1 << 16); + + intel_de_write(dev_priv, PRE_CSC_GAMC_INDEX(pipe), 0); } static void glk_load_degamma_lut_linear(const struct intel_crtc_state *crtc_state) @@ -851,6 +853,8 @@ static void glk_load_degamma_lut_linear(const struct intel_crtc_state *crtc_stat /* Clamp values > 1.0. */ while (i++ < 35) intel_de_write(dev_priv, PRE_CSC_GAMC_DATA(pipe), 1 << 16); + + intel_de_write(dev_priv, PRE_CSC_GAMC_INDEX(pipe), 0); } static void glk_load_luts(const struct intel_crtc_state *crtc_state) -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/9] drm/i915: Relocate CHV CGM gamma masks
From: Ville Syrjälä
CGM_PIPE_GAMMA_RED_MASK & co. are misplaced. Move then below the
relevant register. And while at it add the degamma counterparts.
Reviewed-by: Uma Shankar
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d805d4da6181..f629cdf8dc16 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -11003,14 +11003,17 @@ enum skl_power_gate {
#define _CGM_PIPE_A_CSC_COEFF67(VLV_DISPLAY_BASE + 0x6790C)
#define _CGM_PIPE_A_CSC_COEFF8 (VLV_DISPLAY_BASE + 0x67910)
#define _CGM_PIPE_A_DEGAMMA(VLV_DISPLAY_BASE + 0x66000)
+#define CGM_PIPE_DEGAMMA_RED_MASKREG_GENMASK(13, 0)
+#define CGM_PIPE_DEGAMMA_GREEN_MASK REG_GENMASK(29, 16)
+#define CGM_PIPE_DEGAMMA_BLUE_MASK REG_GENMASK(13, 0)
#define _CGM_PIPE_A_GAMMA (VLV_DISPLAY_BASE + 0x67000)
+#define CGM_PIPE_GAMMA_RED_MASK REG_GENMASK(9, 0)
+#define CGM_PIPE_GAMMA_GREEN_MASKREG_GENMASK(25, 16)
+#define CGM_PIPE_GAMMA_BLUE_MASK REG_GENMASK(9, 0)
#define _CGM_PIPE_A_MODE (VLV_DISPLAY_BASE + 0x67A00)
#define CGM_PIPE_MODE_GAMMA (1 << 2)
#define CGM_PIPE_MODE_CSC(1 << 1)
#define CGM_PIPE_MODE_DEGAMMA(1 << 0)
-#define CGM_PIPE_GAMMA_RED_MASK REG_GENMASK(9, 0)
-#define CGM_PIPE_GAMMA_GREEN_MASK REG_GENMASK(25, 16)
-#define CGM_PIPE_GAMMA_BLUE_MASK REG_GENMASK(9, 0)
#define _CGM_PIPE_B_CSC_COEFF01(VLV_DISPLAY_BASE + 0x69900)
#define _CGM_PIPE_B_CSC_COEFF23(VLV_DISPLAY_BASE + 0x69904)
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 9/9] drm/i915: Replace some gamma_mode ifs with switches
From: Ville Syrjälä
Since gamma_mode can have more than two values on ilk+
let's use switch statements when interpreting them.
v2: Fix typo (Uma)
Reviewed-by: Uma Shankar
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 92 --
1 file changed, 70 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 290d1871ef57..172d398081ee 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -638,10 +638,17 @@ static void ilk_load_luts(const struct intel_crtc_state
*crtc_state)
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
- if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
+ switch (crtc_state->gamma_mode) {
+ case GAMMA_MODE_MODE_8BIT:
ilk_load_lut_8(crtc, gamma_lut);
- else
+ break;
+ case GAMMA_MODE_MODE_10BIT:
ilk_load_lut_10(crtc, gamma_lut);
+ break;
+ default:
+ MISSING_CASE(crtc_state->gamma_mode);
+ break;
+ }
}
static int ivb_lut_10_size(u32 prec_index)
@@ -745,21 +752,27 @@ static void ivb_load_luts(const struct intel_crtc_state
*crtc_state)
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
const struct drm_property_blob *degamma_lut =
crtc_state->hw.degamma_lut;
+ const struct drm_property_blob *blob = gamma_lut ?: degamma_lut;
- if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT) {
- ilk_load_lut_8(crtc, gamma_lut);
- } else if (crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT) {
+ switch (crtc_state->gamma_mode) {
+ case GAMMA_MODE_MODE_8BIT:
+ ilk_load_lut_8(crtc, blob);
+ break;
+ case GAMMA_MODE_MODE_SPLIT:
ivb_load_lut_10(crtc, degamma_lut, PAL_PREC_SPLIT_MODE |
PAL_PREC_INDEX_VALUE(0));
ivb_load_lut_ext_max(crtc_state);
ivb_load_lut_10(crtc, gamma_lut, PAL_PREC_SPLIT_MODE |
PAL_PREC_INDEX_VALUE(512));
- } else {
- const struct drm_property_blob *blob = gamma_lut ?: degamma_lut;
-
+ break;
+ case GAMMA_MODE_MODE_10BIT:
ivb_load_lut_10(crtc, blob,
PAL_PREC_INDEX_VALUE(0));
ivb_load_lut_ext_max(crtc_state);
+ break;
+ default:
+ MISSING_CASE(crtc_state->gamma_mode);
+ break;
}
}
@@ -768,21 +781,28 @@ static void bdw_load_luts(const struct intel_crtc_state
*crtc_state)
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
const struct drm_property_blob *degamma_lut =
crtc_state->hw.degamma_lut;
+ const struct drm_property_blob *blob = gamma_lut ?: degamma_lut;
- if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT) {
- ilk_load_lut_8(crtc, gamma_lut);
- } else if (crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT) {
+ switch (crtc_state->gamma_mode) {
+ case GAMMA_MODE_MODE_8BIT:
+ ilk_load_lut_8(crtc, blob);
+ break;
+ case GAMMA_MODE_MODE_SPLIT:
bdw_load_lut_10(crtc, degamma_lut, PAL_PREC_SPLIT_MODE |
PAL_PREC_INDEX_VALUE(0));
ivb_load_lut_ext_max(crtc_state);
bdw_load_lut_10(crtc, gamma_lut, PAL_PREC_SPLIT_MODE |
PAL_PREC_INDEX_VALUE(512));
- } else {
- const struct drm_property_blob *blob = gamma_lut ?: degamma_lut;
+ break;
+ case GAMMA_MODE_MODE_10BIT:
bdw_load_lut_10(crtc, blob,
PAL_PREC_INDEX_VALUE(0));
ivb_load_lut_ext_max(crtc_state);
+ break;
+ default:
+ MISSING_CASE(crtc_state->gamma_mode);
+ break;
}
}
@@ -875,11 +895,17 @@ static void glk_load_luts(const struct intel_crtc_state
*crtc_state)
else
glk_load_degamma_lut_linear(crtc_state);
- if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT) {
+ switch (crtc_state->gamma_mode) {
+ case GAMMA_MODE_MODE_8BIT:
ilk_load_lut_8(crtc, gamma_lut);
- } else {
+ break;
+ case GAMMA_MODE_MODE_10BIT:
bdw_load_lut_10(crtc, gamma_lut, PAL_PREC_INDEX_VALUE(0));
ivb_load_lut_ext_max(crtc_state);
+ break;
+ default:
+ MISSING_CASE(crtc_state->gamma_mode);
+
Re: [Intel-gfx] [PATCH 08/11] drm/i915: use vmap in i915_gem_object_map
On 24/09/2020 14:58, Christoph Hellwig wrote:
i915_gem_object_map implements fairly low-level vmap functionality in
a driver. Split it into two helpers, one for remapping kernel memory
which can use vmap, and one for I/O memory that uses vmap_pfn.
The only practical difference is that alloc_vm_area prefeaults the
vmalloc area PTEs, which doesn't seem to be required here for the
kernel memory case (and could be added to vmap using a flag if actually
required).
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 126 ++
2 files changed, 59 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 9afa5c4a6bf006..1e1cb245fca778 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -25,6 +25,7 @@ config DRM_I915
select CRC32
select SND_HDA_I915 if SND_HDA_CORE
select CEC_CORE if CEC_NOTIFIER
+ select VMAP_PFN
help
Choose this option if you have a system that has "Intel Graphics
Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 6550c0bc824ea2..b519417667eb4b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -232,34 +232,21 @@ int __i915_gem_object_put_pages(struct
drm_i915_gem_object *obj)
return err;
}
-static inline pte_t iomap_pte(resource_size_t base,
- dma_addr_t offset,
- pgprot_t prot)
-{
- return pte_mkspecial(pfn_pte((base + offset) >> PAGE_SHIFT, prot));
-}
-
/* The 'mapping' part of i915_gem_object_pin_map() below */
-static void *i915_gem_object_map(struct drm_i915_gem_object *obj,
-enum i915_map_type type)
+static void *i915_gem_object_map_page(struct drm_i915_gem_object *obj,
+ enum i915_map_type type)
{
- unsigned long n_pte = obj->base.size >> PAGE_SHIFT;
- struct sg_table *sgt = obj->mm.pages;
- pte_t *stack[32], **mem;
- struct vm_struct *area;
+ unsigned long n_pages = obj->base.size >> PAGE_SHIFT, i;
+ struct page *stack[32], **pages = stack, *page;
+ struct sgt_iter iter;
pgprot_t pgprot;
+ void *vaddr;
- if (!i915_gem_object_has_struct_page(obj) && type != I915_MAP_WC)
- return NULL;
-
- if (GEM_WARN_ON(type == I915_MAP_WC &&
- !static_cpu_has(X86_FEATURE_PAT)))
- return NULL;
-
- /* A single page can always be kmapped */
- if (n_pte == 1 && type == I915_MAP_WB) {
- struct page *page = sg_page(sgt->sgl);
-
+ switch (type) {
+ default:
+ MISSING_CASE(type);
+ fallthrough;/* to use PAGE_KERNEL anyway */
+ case I915_MAP_WB:
/*
* On 32b, highmem using a finite set of indirect PTE (i.e.
* vmap) to provide virtual mappings of the high pages.
@@ -277,30 +264,8 @@ static void *i915_gem_object_map(struct
drm_i915_gem_object *obj,
* So if the page is beyond the 32b boundary, make an explicit
* vmap.
*/
- if (!PageHighMem(page))
- return page_address(page);
- }
-
- mem = stack;
- if (n_pte > ARRAY_SIZE(stack)) {
- /* Too big for stack -- allocate temporary array instead */
- mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
- if (!mem)
- return NULL;
- }
-
- area = alloc_vm_area(obj->base.size, mem);
- if (!area) {
- if (mem != stack)
- kvfree(mem);
- return NULL;
- }
-
- switch (type) {
- default:
- MISSING_CASE(type);
- fallthrough;/* to use PAGE_KERNEL anyway */
- case I915_MAP_WB:
+ if (n_pages == 1 && !PageHighMem(sg_page(obj->mm.pages->sgl)))
+ return page_address(sg_page(obj->mm.pages->sgl));
pgprot = PAGE_KERNEL;
break;
case I915_MAP_WC:
@@ -308,30 +273,49 @@ static void *i915_gem_object_map(struct
drm_i915_gem_object *obj,
break;
}
- if (i915_gem_object_has_struct_page(obj)) {
- struct sgt_iter iter;
- struct page *page;
- pte_t **ptes = mem;
+ if (n_pages > ARRAY_SIZE(stack)) {
+ /* Too big for stack -- allocate temporary array instead */
+ pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
+ if (!pages)
+ return NULL;
+ }
- for_each_sgt_page(page, iter, sgt)
- **ptes++
Re: [Intel-gfx] [PATCH 06/11] drm/i915: use vmap in shmem_pin_map
On 24/09/2020 14:58, Christoph Hellwig wrote:
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). Switch to use vmap, and use vfree to free both the
vmalloc mapping and the page array, as well as dropping the references
to each page.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gt/shmem_utils.c | 76 +++
1 file changed, 18 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c
b/drivers/gpu/drm/i915/gt/shmem_utils.c
index 43c7acbdc79dea..f011ea42487e11 100644
--- a/drivers/gpu/drm/i915/gt/shmem_utils.c
+++ b/drivers/gpu/drm/i915/gt/shmem_utils.c
@@ -49,80 +49,40 @@ struct file *shmem_create_from_object(struct
drm_i915_gem_object *obj)
return file;
}
-static size_t shmem_npte(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;
- }
+ struct page **pages;
+ size_t n_pages, i;
+ void *vaddr;
- area = alloc_vm_area(n_pte << PAGE_SHIFT, mem);
- if (!area) {
- if (mem != stack)
- kvfree(mem);
+ n_pages = file->f_mapping->host->i_size >> PAGE_SHIFT;
+ 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, VM_MAP_PUT_PAGES, 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)
{
mapping_clear_unevictable(file->f_mapping);
- __shmem_unpin_map(file, ptr, shmem_npte(file));
+ vfree(ptr);
}
static int __shmem_rw(struct file *file, loff_t off,
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/11] drm/i915: stop using kmap in i915_gem_object_map
On 24/09/2020 14:58, Christoph Hellwig wrote:
kmap for !PageHighmem is just a convoluted way to say page_address,
and kunmap is a no-op in that case.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index d6eeefab3d018b..6550c0bc824ea2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -162,8 +162,6 @@ static void unmap_object(struct drm_i915_gem_object *obj,
void *ptr)
{
if (is_vmalloc_addr(ptr))
vunmap(ptr);
- else
- kunmap(kmap_to_page(ptr));
}
struct sg_table *
@@ -277,11 +275,10 @@ static void *i915_gem_object_map(struct
drm_i915_gem_object *obj,
* forever.
*
* So if the page is beyond the 32b boundary, make an explicit
-* vmap. On 64b, this check will be optimised away as we can
-* directly kmap any page on the system.
+* vmap.
*/
if (!PageHighMem(page))
- return kmap(page);
+ return page_address(page);
}
mem = stack;
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add support for DP-HDMI2.1 PCON
== Series Details == Series: Add support for DP-HDMI2.1 PCON URL : https://patchwork.freedesktop.org/series/82098/ 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: cast to restricted __le16
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add support for DP-HDMI2.1 PCON
== Series Details ==
Series: Add support for DP-HDMI2.1 PCON
URL : https://patchwork.freedesktop.org/series/82098/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ca36191ea8ce drm/edid: Add additional HFVSDB fields for HDMI2.1
-:57: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Swati Sharma '
total: 0 errors, 1 warnings, 0 checks, 36 lines checked
085ed8f42a16 drm/edid: Parse MAX_FRL field from HFVSDB block
-:27: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#27: FILE: drivers/gpu/drm/drm_edid.c:4857:
+u8 max_frl_rate_per_lane;$
-:28: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#28: FILE: drivers/gpu/drm/drm_edid.c:4858:
+struct drm_hdmi_info *hdmi = >display_info.hdmi;$
-:30: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#30: FILE: drivers/gpu/drm/drm_edid.c:4860:
+max_frl_rate_per_lane = (db[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;$
-:32: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#32: FILE: drivers/gpu/drm/drm_edid.c:4862:
+switch(max_frl_rate_per_lane) {$
-:32: ERROR:SPACING: space required before the open parenthesis '('
#32: FILE: drivers/gpu/drm/drm_edid.c:4862:
+switch(max_frl_rate_per_lane) {
-:33: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#33: FILE: drivers/gpu/drm/drm_edid.c:4863:
+case 0:$
-:36: WARNING:TABSTOP: Statements should start on a tabstop
#36: FILE: drivers/gpu/drm/drm_edid.c:4866:
+ break;
-:37: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#37: FILE: drivers/gpu/drm/drm_edid.c:4867:
+case 1:$
-:40: WARNING:TABSTOP: Statements should start on a tabstop
#40: FILE: drivers/gpu/drm/drm_edid.c:4870:
+ break;
-:41: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#41: FILE: drivers/gpu/drm/drm_edid.c:4871:
+case 2:$
-:44: WARNING:TABSTOP: Statements should start on a tabstop
#44: FILE: drivers/gpu/drm/drm_edid.c:4874:
+ break;
-:45: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#45: FILE: drivers/gpu/drm/drm_edid.c:4875:
+case 3:$
-:48: WARNING:TABSTOP: Statements should start on a tabstop
#48: FILE: drivers/gpu/drm/drm_edid.c:4878:
+ break;
-:49: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#49: FILE: drivers/gpu/drm/drm_edid.c:4879:
+case 4:$
-:52: WARNING:TABSTOP: Statements should start on a tabstop
#52: FILE: drivers/gpu/drm/drm_edid.c:4882:
+ break;
-:53: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#53: FILE: drivers/gpu/drm/drm_edid.c:4883:
+case 5:$
-:56: WARNING:TABSTOP: Statements should start on a tabstop
#56: FILE: drivers/gpu/drm/drm_edid.c:4886:
+ break;
-:57: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#57: FILE: drivers/gpu/drm/drm_edid.c:4887:
+case 6:$
-:60: WARNING:TABSTOP: Statements should start on a tabstop
#60: FILE: drivers/gpu/drm/drm_edid.c:4890:
+ break;
-:63: WARNING:TABSTOP: Statements should start on a tabstop
#63: FILE: drivers/gpu/drm/drm_edid.c:4893:
+ break;
-:64: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#64: FILE: drivers/gpu/drm/drm_edid.c:4894:
+}$
-:74: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional
statements (8, 20)
#74: FILE: drivers/gpu/drm/drm_edid.c:4950:
+ if (hf_vsdb[7]) {
+ DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
-:98: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Swati Sharma '
total: 1 errors, 22 warnings, 0 checks, 74 lines checked
57e6b62ff35a drm/dp_helper: Add FRL training support for a DP-HDMI2.1 PCON
35c096404566 drm/i915: Add support for starting FRL training for HDMI2.1 via
PCON
-:174: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#174: FILE: drivers/gpu/drm/i915/display/intel_dp.c:3936:
+ wait_for(is_active = drm_dp_pcon_is_frl_ready(_dp->aux) == true,
TIMEOUT_FRL_READY_MS);
-:193: WARNING:LONG_LINE: line length of 112 exceeds 100 columns
#193: FILE: drivers/gpu/drm/i915/display/intel_dp.c:3955:
+ wait_for(is_active = drm_dp_pcon_hdmi_link_active(_dp->aux) ==
true, TIMEOUT_HDMI_LINK_ACTIVE_MS);
-:200: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#200: FILE: drivers/gpu/drm/i915/display/intel_dp.c:3962:
+ if (DP_PCON_HDMI_MODE_FRL != drm_dp_pcon_hdmi_link_mode(_dp->aux,
_trained_mask)) {
-:200: WARNING:CONSTANT_COMPARISON: Comparisons should place the constant on
the right side of the test
#200: FILE: drivers/gpu/drm/i915/display/intel_dp.c:3962:
+ if (DP_PCON_HDMI_MODE_FRL != drm_dp_pcon_hdmi_link_mode(_dp->aux,
_trained_mask)) {
-:204: WARNING:LONG_LINE: line length of 106 exceeds 100 columns
#204: FILE: drivers/gpu/drm/i915/display/intel_dp.c:3966:
+ drm_dbg(>drm, "MAX_FRL_MASK = %u, FRL_TRAINED_MASK = %u\n",
max_frl_mask,
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Make intel_{enable, disable}_sagv() static
== Series Details ==
Series: series starting with [1/2] drm/i915: Make intel_{enable,
disable}_sagv() static
URL : https://patchwork.freedesktop.org/series/82096/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9056 -> Patchwork_18573
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18573/index.html
Known issues
Here are the changes found in Patchwork_18573 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_9056/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18573/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +2 similar
issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18573/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
* igt@vgem_basic@unload:
- fi-skl-guc: [PASS][5] -> [DMESG-WARN][6] ([i915#2203])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-skl-guc/igt@vgem_ba...@unload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18573/fi-skl-guc/igt@vgem_ba...@unload.html
Possible fixes
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18573/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_busy@basic@flip:
- {fi-tgl-dsi}: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18573/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18573/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18573/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][16] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18573/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92]) ->
[DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18573/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][20] ([i915#62] / [i915#92]) +4 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-kbl-x1275/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18573/fi-kbl-x1275/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.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 (46 -> 39)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915: Make intel_{enable, disable}_sagv() static
== Series Details ==
Series: series starting with [1/2] drm/i915: Make intel_{enable,
disable}_sagv() static
URL : https://patchwork.freedesktop.org/series/82096/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+./include/linux/spinlock.h:409:9: warning: context imbalance in
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16'
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32'
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64'
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' -
different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16'
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32'
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8'
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16'
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32'
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8'
- different lock contexts for basic block
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH rdma-next v3 1/2] lib/scatterlist: Add support in dynamic allocation of SG table from pages
On 25/09/2020 13:18, Maor Gottlieb wrote:
On 9/25/2020 2:55 PM, Jason Gunthorpe wrote:
On Fri, Sep 25, 2020 at 10:13:30AM +0300, Leon Romanovsky wrote:
diff --git a/tools/testing/scatterlist/main.c
b/tools/testing/scatterlist/main.c
index 0a1464181226..4899359a31ac 100644
+++ b/tools/testing/scatterlist/main.c
@@ -55,14 +55,13 @@ int main(void)
for (i = 0, test = tests; test->expected_segments; test++,
i++) {
struct page *pages[MAX_PAGES];
struct sg_table st;
- int ret;
+ struct scatterlist *sg;
set_pages(pages, test->pfn, test->num_pages);
- ret = __sg_alloc_table_from_pages(, pages,
test->num_pages,
- 0, test->size, test->max_seg,
- GFP_KERNEL);
- assert(ret == test->alloc_ret);
+ sg = __sg_alloc_table_from_pages(, pages,
test->num_pages, 0,
+ test->size, test->max_seg, NULL, 0, GFP_KERNEL);
+ assert(PTR_ERR_OR_ZERO(sg) == test->alloc_ret);
Some test coverage for relatively complex code would be very
welcomed. Since
the testing framework is already there, even if it bit-rotted a bit,
but
shouldn't be hard to fix.
A few tests to check append/grow works as expected, in terms of how
the end
table looks like given the initial state and some different page
patterns
added to it. And both crossing and not crossing into sg chaining
scenarios.
This function is basic for all RDMA devices and we are pretty confident
that the old and new flows are tested thoroughly.
Well, since 0-day is reporting that __i915_gem_userptr_alloc_pages is
crashing on this, it probably does need some tests :\
Jason
It is crashing in the regular old flow which already tested.
However, I will add more tests.
Do you want to take some of the commits from
git://people.freedesktop.org/~tursulin/drm-intel sgtest? It would be
fine by me. I can clean up the commit messages if you want.
https://cgit.freedesktop.org/~tursulin/drm-intel/commit/?h=sgtest=79102f4d795c4769431fc44a6cf7ed5c5b1b5214
- this one undoes the bit rot and makes the test just work on the
current kernel.
https://cgit.freedesktop.org/~tursulin/drm-intel/commit/?h=sgtest=b09bfe80486c4d93ee1d8ae17d5b46397b1c6ee1
- this one you probably should squash in your patch. Minus the zeroing
of struct sg_stable since that would hide the issue.
https://cgit.freedesktop.org/~tursulin/drm-intel/commit/?h=sgtest=97f5df37e612f798ced90541eece13e2ef639181
- final commit is optional but I guess handy for debugging.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for dma-buf: Flag vmap'ed memory as system or I/O memory (rev3)
== Series Details ==
Series: dma-buf: Flag vmap'ed memory as system or I/O memory (rev3)
URL : https://patchwork.freedesktop.org/series/81647/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9056 -> Patchwork_18572
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18572/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18572:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gt_lrc:
- {fi-tgl-dsi}: [DMESG-FAIL][1] ([i915#2373]) -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-tgl-dsi/igt@i915_selftest@live@gt_lrc.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18572/fi-tgl-dsi/igt@i915_selftest@live@gt_lrc.html
Known issues
Here are the changes found in Patchwork_18572 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-kbl-r: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-kbl-r/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18572/fi-kbl-r/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18572/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
* igt@vgem_basic@unload:
- fi-skl-guc: [PASS][7] -> [DMESG-WARN][8] ([i915#2203])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-skl-guc/igt@vgem_ba...@unload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18572/fi-skl-guc/igt@vgem_ba...@unload.html
Possible fixes
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18572/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_busy@basic@flip:
- {fi-tgl-dsi}: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18572/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18572/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][15] ([i915#62]) -> [DMESG-FAIL][16]
([i915#62] / [i915#95])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18572/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
- fi-skl-6700k2: [DMESG-WARN][17] ([i915#2203]) -> [INCOMPLETE][18]
([i915#151] / [i915#2203])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-skl-6700k2/igt@i915_pm_...@module-reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18572/fi-skl-6700k2/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) ->
[DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18572/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][22] ([i915#62] / [i915#92]) +4 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
[22]:
Re: [Intel-gfx] [PATCH rdma-next v3 1/2] lib/scatterlist: Add support in dynamic allocation of SG table from pages
On 25/09/2020 12:58, Jason Gunthorpe wrote: On Fri, Sep 25, 2020 at 12:41:29PM +0100, Tvrtko Ursulin wrote: On 25/09/2020 08:13, Leon Romanovsky wrote: On Thu, Sep 24, 2020 at 09:21:20AM +0100, Tvrtko Ursulin wrote: On 22/09/2020 09:39, Leon Romanovsky wrote: 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). So it's appending and growing the "list", did I get that right? Sounds handy indeed. Some comments/questions below. Yes, we (RDMA) use this function to chain contiguous pages. I will eveluate if i915 could start using it. We have some loops which build page by page and coalesce. Christoph H doesn't like it, but if there are enough cases we should really have a pin_user_pages_to_sg() rather than open code this all over the place. With THP the chance of getting a coalescing SG is much higher, and everything is more efficient with larger SGEs. Right, I was actually referring to i915 sites where we build sg tables out of shmem and plain kernel pages. In those areas we have some open coded coalescing loops (see for instance our shmem_get_pages). Plus a local "trim" to discard the unused entries, since we allocate pessimistically not knowing how coalescing will pan out. This kind of core function which appends pages could replace some of that. Maybe it would be slightly less efficient but I will pencil in to at least evaluate it. Otherwise I do agree that coalescing is a win and in the past I have measured savings in a few MiB range just for struct scatterlist storage. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 4/7] drm/i915: Add support for starting FRL training for HDMI2.1 via PCON
This patch adds functions to start FRL training for an HDMI2.1 sink,
connected via a PCON as a DP branch device.
This patch also adds a new structure for storing frl training related
data, when FRL training is completed.
Signed-off-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_types.h| 6 +
drivers/gpu/drm/i915/display/intel_dp.c | 202 ++
drivers/gpu/drm/i915/display/intel_dp.h | 2 +
3 files changed, 210 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..9a295a43b189 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1264,6 +1264,11 @@ struct intel_dp_compliance {
u8 test_lane_count;
};
+struct intel_dp_pcon_frl {
+ bool is_trained;
+ int trained_rate_gbps;
+};
+
struct intel_dp {
i915_reg_t output_reg;
u32 DP;
@@ -1312,6 +1317,7 @@ struct intel_dp {
unsigned long last_backlight_off;
ktime_t panel_power_off_time;
+ struct intel_dp_pcon_frl frl;
struct notifier_block edp_notifier;
/*
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index bf1e9cf1c0f3..3a8e69e5bbfb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2869,6 +2869,9 @@ static void intel_dp_prepare(struct intel_encoder
*encoder,
intel_dp->DP |= DP_PIPE_SEL_CHV(crtc->pipe);
else
intel_dp->DP |= DP_PIPE_SEL(crtc->pipe);
+
+ intel_dp->frl.is_trained = false;
+ intel_dp->frl.trained_rate_gbps = 0;
}
}
@@ -3705,6 +3708,9 @@ static void intel_disable_dp(struct intel_atomic_state
*state,
intel_edp_backlight_off(old_conn_state);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
intel_edp_panel_off(intel_dp);
+
+ intel_dp->frl.is_trained = false;
+ intel_dp->frl.trained_rate_gbps = 0;
}
static void g4x_disable_dp(struct intel_atomic_state *state,
@@ -3799,6 +3805,202 @@ cpt_set_link_train(struct intel_dp *intel_dp,
intel_de_posting_read(dev_priv, intel_dp->output_reg);
}
+static int intel_dp_get_max_rate_gbps(struct intel_dp *intel_dp)
+{
+ int max_link_clock, max_lanes, max_rate_khz, max_rate_gbps;
+
+ max_link_clock = intel_dp_max_link_rate(intel_dp);
+ max_lanes = intel_dp_max_lane_count(intel_dp);
+ max_rate_khz = intel_dp_max_data_rate(max_link_clock, max_lanes);
+ max_rate_gbps = 8 * DIV_ROUND_UP(max_rate_khz, 100);
+
+ return max_rate_gbps;
+}
+
+static int intel_dp_pcon_get_frl_mask(u8 frl_bw_mask)
+{
+ int bw_gbps[] = {9, 18, 24, 32, 40, 48};
+ int i;
+
+ for (i = ARRAY_SIZE(bw_gbps) - 1; i >= 0; i--) {
+ if (frl_bw_mask & (1 << i))
+ return bw_gbps[i];
+ }
+ return 0;
+}
+
+static int intel_dp_pcon_set_frl_mask(int max_frl)
+{
+ int max_frl_mask = 0;
+
+ switch (max_frl) {
+ case 48:
+ max_frl_mask |= DP_PCON_FRL_BW_MASK_48GBPS;
+ break;
+ case 40:
+ max_frl_mask |= DP_PCON_FRL_BW_MASK_40GBPS;
+ break;
+ case 32:
+ max_frl_mask |= DP_PCON_FRL_BW_MASK_32GBPS;
+ break;
+ case 24:
+ max_frl_mask |= DP_PCON_FRL_BW_MASK_24GBPS;
+ break;
+ case 18:
+ max_frl_mask |= DP_PCON_FRL_BW_MASK_18GBPS;
+ break;
+ case 9:
+ max_frl_mask |= DP_PCON_FRL_BW_MASK_9GBPS;
+ break;
+ default:
+ max_frl_mask = 0;
+ }
+
+ return max_frl_mask;
+}
+
+static int intel_dp_hdmi_sink_max_frl(struct intel_dp *intel_dp)
+{
+ struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct drm_connector *connector = _connector->base;
+
+ return (connector->display_info.hdmi.max_frl_rate_per_lane *
+ connector->display_info.hdmi.max_lane);
+}
+
+static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
+{
+#define PCON_EXTENDED_TRAIN_MODE true
+#define PCON_CONCURRENT_MODE true
+#define PCON_SEQUENTIAL_MODE !PCON_CONCURRENT_MODE
+#define PCON_NORMAL_TRAIN_MODE !PCON_EXTENDED_TRAIN_MODE
+#define TIMEOUT_FRL_READY_MS 500
+#define TIMEOUT_HDMI_LINK_ACTIVE_MS 1000
+
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ int max_frl, max_pcon_frl, max_sink_frl, max_rate_gbps, max_frl_edid,
ret;
+ u8 max_frl_mask = 0, frl_trained_mask;
+ bool is_active;
+
+ ret = drm_dp_pcon_reset_frl_config(_dp->aux);
+ if (ret < 0)
+ return ret;
+
+ max_rate_gbps = intel_dp_get_max_rate_gbps(intel_dp);
+ drm_dbg(>drm, "Source max rate = %d Gbps\n", max_rate_gbps);
+
+
[Intel-gfx] [RFC 0/7] Add support for DP-HDMI2.1 PCON
This patch series attempts to add support for a DP-HDMI2.1 Protocol Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata E5 to DisplayPort_v2.0: https://vesa.org/join-vesamemberships/member-downloads/?action=stamp=42299 The details are mentioned in DP to HDMI2.1 PCON Enum/Config improvement slide decks: https://groups.vesa.org/wg/DP/document/folder/1316 This RFC series starts with adding support for FRL (Fixed Rate Link) Training between the PCON and HDMI2.1 sink. As per HDMI2.1 specification, a new data-channel or lane is added in FRL mode, by repurposing the TMDS clock Channel. Through FRL, higher bit-rate can be supported, ie. up to 12 Gbps/lane (48 Gbps over 4 lanes). With these patches, the HDMI2.1 PCON can be configured to achieve FRL training based on the maximum FRL rate supported by the panel, source and the PCON. The approach is to add the support for FRL training between PCON and HDMI2.1 sink and gradually add other blocks for supporting higher resolutions and other HDMI2.1 features, that can be supported by pcon for the sources that do not natively support HDMI2.1. This is done before the DP Link training between the source and PCON is started. In case of FRL training is not achieved, the PCON will work in the regular TMDS mode, without HDMI2.1 feature support. Any interruption in FRL training between the PCON and HDMI2.1 sink is notified through IRQ_HPD. On receiving the IRQ_HPD the concerned DPCD registers are read and FRL training is re-attempted. Currently, we have tested the FRL training and are able to enable 4K display with TGL Platform + Realtek PCON RTD2173 with HDMI2.1 supporting panel. Ankit Nautiyal (3): drm/dp_helper: Add FRL training support for a DP-HDMI2.1 PCON drm/i915: Add support for starting FRL training for HDMI2.1 via PCON drm/i915: Check for FRL training before DP Link training Swati Sharma (4): drm/edid: Add additional HFVSDB fields for HDMI2.1 drm/edid: Parse MAX_FRL field from HFVSDB block drm/dp_helper: Add support for link status and link recovery drm/i915: Add support for enabling link status and recovery drivers/gpu/drm/drm_dp_helper.c | 338 ++ drivers/gpu/drm/drm_edid.c| 50 +++ drivers/gpu/drm/i915/display/intel_ddi.c | 2 + .../drm/i915/display/intel_display_types.h| 6 + drivers/gpu/drm/i915/display/intel_dp.c | 251 - drivers/gpu/drm/i915/display/intel_dp.h | 2 + include/drm/drm_connector.h | 6 + include/drm/drm_dp_helper.h | 97 + include/drm/drm_edid.h| 30 ++ 9 files changed, 779 insertions(+), 3 deletions(-) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 1/7] drm/edid: Add additional HFVSDB fields for HDMI2.1
From: Swati Sharma
The HDMI2.1 extends HFVSBD (HDMI Forum Vendor Specific
Data block) to have fields related to newly defined methods of FRL
(Fixed Rate Link) levels, number of lanes supported, DSC Color bit
depth, VRR min/max, FVA (Fast Vactive), ALLM etc.
This patch adds the new HFVSDB fields that are required for
HDMI2.1.
Signed-off-by: Sharma, Swati2
Signed-off-by: Ankit Nautiyal
---
include/drm/drm_edid.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index b27a0e2169c8..3b6371f36676 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -229,6 +229,36 @@ struct detailed_timing {
DRM_EDID_YCBCR420_DC_36 | \
DRM_EDID_YCBCR420_DC_30)
+/* HDMI 2.1 additional fields */
+#define DRM_EDID_MAX_FRL_RATE_MASK 0xf0
+#define DRM_EDID_FAPA_START_LOCATION (1 << 0)
+#define DRM_EDID_ALLM (1 << 1)
+#define DRM_EDID_FVA (1 << 2)
+
+/* Deep Color specific */
+#define DRM_EDID_DC_30BIT_420 (1 << 0)
+#define DRM_EDID_DC_36BIT_420 (1 << 1)
+#define DRM_EDID_DC_48BIT_420 (1 << 2)
+
+/* VRR specific */
+#define DRM_EDID_CNMVRR(1 << 3)
+#define DRM_EDID_CINEMA_VRR(1 << 4)
+#define DRM_EDID_MDELTA(1 << 5)
+#define DRM_EDID_VRR_MAX_UPPER_MASK0xc0
+#define DRM_EDID_VRR_MAX_LOWER_MASK0xff
+#define DRM_EDID_VRR_MIN_MASK 0x3f
+
+/* DSC specific */
+#define DRM_EDID_DSC_10(1 << 0)
+#define DRM_EDID_DSC_12(1 << 1)
+#define DRM_EDID_DSC_16(1 << 2)
+#define DRM_EDID_DSC_ALL (1 << 3)
+#define DRM_EDID_DSC_NATIVE_420(1 << 6)
+#define DRM_EDID_1P2 (1 << 7)
+#define DRM_EDID_DSC_MAX_FRL_RATE 0xf
+#define DRM_EDID_DSC_MAX_SLICES0xf
+#define DRM_EDID_DSC_TOTAL_CHUNK_KBYTES0x3f
+
/* ELD Header Block */
#define DRM_ELD_HEADER_BLOCK_SIZE 4
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 2/7] drm/edid: Parse MAX_FRL field from HFVSDB block
From: Swati Sharma
This patch parses MAX_FRL field to get the MAX rate in Gbps that
the HDMI 2.1 panel can support in FRL mode. Source need this
field to determine the optimal rate between the source and sink
during FRL training.
Signed-off-by: Sharma, Swati2
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_edid.c | 50 +
include/drm/drm_connector.h | 6 +
2 files changed, 56 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 631125b46e04..d468ac91abb6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4849,6 +4849,51 @@ static void drm_parse_vcdb(struct drm_connector
*connector, const u8 *db)
info->rgb_quant_range_selectable = true;
}
+static void drm_parse_hdmi_21_additional_fields(struct drm_connector
*connector,
+ const u8 *db)
+{
+ /* hf_vsdb 7:14 support needs to be added */
+
+u8 max_frl_rate_per_lane;
+struct drm_hdmi_info *hdmi = >display_info.hdmi;
+
+max_frl_rate_per_lane = (db[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
+
+switch(max_frl_rate_per_lane) {
+case 0:
+ hdmi->max_lane = 0;
+ hdmi->max_frl_rate_per_lane = 0;
+ break;
+case 1:
+ hdmi->max_lane = 3;
+ hdmi->max_frl_rate_per_lane = 3;
+ break;
+case 2:
+ hdmi->max_lane = 3;
+ hdmi->max_frl_rate_per_lane = 6;
+ break;
+case 3:
+ hdmi->max_lane = 4;
+ hdmi->max_frl_rate_per_lane = 6;
+ break;
+case 4:
+ hdmi->max_lane = 4;
+ hdmi->max_frl_rate_per_lane = 8;
+ break;
+case 5:
+ hdmi->max_lane = 4;
+ hdmi->max_frl_rate_per_lane = 10;
+ break;
+case 6:
+ hdmi->max_lane = 4;
+ hdmi->max_frl_rate_per_lane = 12;
+ break;
+default:
+ DRM_DEBUG_KMS("max frl rate per lane 0x%x, reserved\n",
max_frl_rate_per_lane);
+ break;
+}
+}
+
static void drm_parse_ycbcr420_deep_color_info(struct drm_connector *connector,
const u8 *db)
{
@@ -4902,6 +4947,11 @@ static void drm_parse_hdmi_forum_vsdb(struct
drm_connector *connector,
}
}
+ if (hf_vsdb[7]) {
+ DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
+ drm_parse_hdmi_21_additional_fields(connector, hf_vsdb);
+ }
+
drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 928136556174..aa6ae9c17ca4 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -207,6 +207,12 @@ struct drm_hdmi_info {
/** @y420_dc_modes: bitmap of deep color support index */
u8 y420_dc_modes;
+
+ /** @max_frl_rate_per_lane: support fixed rate link */
+ u8 max_frl_rate_per_lane;
+
+ /** @max_lane: supported by sink */
+ u8 max_lane;
};
/**
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 6/7] drm/dp_helper: Add support for link status and link recovery
From: Swati Sharma
This patch adds support for link status and link recovery. There
are specific DPCD’s defined for link status check and recovery in
case of any issues. PCON will communicate the same using an IRQ_HPD
to source. HDMI sink would have indicated the same to PCON using
SCDC interrupt mechanism. While source can always read final HDMI
sink’s status using I2C over AUX, it’s easier and faster to read
the PCON’s already read HDMI sink’s status registers.
Signed-off-by: Swati Sharma
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_dp_helper.c | 33 +
include/drm/drm_dp_helper.h | 16
2 files changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 36302d4924f4..aac282bc5dfc 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2671,3 +2671,36 @@ int drm_dp_pcon_hdmi_link_mode(struct drm_dp_aux *aux,
u8 *frl_trained_mask)
return mode;
}
EXPORT_SYMBOL(drm_dp_pcon_hdmi_link_mode);
+
+void drm_dp_pcon_hdmi_frl_link_error_count(struct drm_dp_aux *aux,
+ struct drm_connector *connector)
+{
+ u8 buf, error_count;
+ int i, num_error;
+ struct drm_hdmi_info *hdmi = >display_info.hdmi;
+
+ for (i = 0; i < hdmi->max_lane; i++)
+ {
+ if (drm_dp_dpcd_readb(aux, DP_PCON_HDMI_ERROR_STATUS_LN0 + i ,
) < 0)
+ return;
+
+ error_count = buf & DP_PCON_HDMI_ERROR_COUNT_MASK;
+
+ switch(error_count) {
+ case DP_PCON_HDMI_ERROR_COUNT_HUNDRED_PLUS:
+ num_error = 100;
+ break;
+ case DP_PCON_HDMI_ERROR_COUNT_TEN_PLUS:
+ num_error = 10;
+ break;
+ case DP_PCON_HDMI_ERROR_COUNT_THREE_PLUS:
+ num_error = 3;
+ break;
+ default:
+ num_error = 0;
+ }
+
+ DRM_ERROR("More than %d errors since the last read for lane
%d", num_error, i);
+ }
+}
+EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 58a6600e5698..7b143a2ae5ff 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -946,6 +946,11 @@ struct drm_device;
# define DP_CEC_IRQ (1 << 2)
#define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005 /* 1.2 */
+# define RX_CAP_CHANGED (1 << 0)
+# define LINK_STATUS_CHANGED (1 << 1)
+# define STREAM_STATUS_CHANGED (1 << 2)
+# define HDMI_LINK_STATUS_CHANGED(1 << 3)
+# define CONNECTED_OFF_ENTRY_REQUESTED (1 << 4)
#define DP_PSR_ERROR_STATUS 0x2006 /* XXX 1.2? */
# define DP_PSR_LINK_CRC_ERROR (1 << 0)
@@ -1130,6 +1135,16 @@ struct drm_device;
#define DP_PROTOCOL_CONVERTER_CONTROL_20x3052 /* DP 1.3 */
# define DP_CONVERSION_TO_YCBCR422_ENABLE (1 << 0) /* DP 1.3 */
+/* PCON Downstream HDMI ERROR Status per Lane */
+#define DP_PCON_HDMI_ERROR_STATUS_LN0 0x3037
+#define DP_PCON_HDMI_ERROR_STATUS_LN1 0x3038
+#define DP_PCON_HDMI_ERROR_STATUS_LN2 0x3039
+#define DP_PCON_HDMI_ERROR_STATUS_LN3 0x303A
+# define DP_PCON_HDMI_ERROR_COUNT_MASK (0x7 << 0)
+# define DP_PCON_HDMI_ERROR_COUNT_THREE_PLUS (1 << 0)
+# define DP_PCON_HDMI_ERROR_COUNT_TEN_PLUS (1 << 1)
+# define DP_PCON_HDMI_ERROR_COUNT_HUNDRED_PLUS (1 << 2)
+
/* HDCP 1.3 and HDCP 2.2 */
#define DP_AUX_HDCP_BKSV 0x68000
#define DP_AUX_HDCP_RI_PRIME 0x68005
@@ -1985,4 +2000,5 @@ int drm_dp_pcon_frl_enable(struct drm_dp_aux *aux);
bool drm_dp_pcon_hdmi_link_active(struct drm_dp_aux *aux);
int drm_dp_pcon_hdmi_link_mode(struct drm_dp_aux *aux, u8 *frl_trained_mask);
+void drm_dp_pcon_hdmi_frl_link_error_count(struct drm_dp_aux *aux, struct
drm_connector *connector);
#endif /* _DRM_DP_HELPER_H_ */
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 3/7] drm/dp_helper: Add FRL training support for a DP-HDMI2.1 PCON
This patch adds support for configuring a PCON device,
connected as a DP branched device to enable FRL Link training
with a HDMI2.1 + sink.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_dp_helper.c | 305
include/drm/drm_dp_helper.h | 81 +
2 files changed, 386 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 478dd51f738d..36302d4924f4 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2366,3 +2366,308 @@ void drm_dp_vsc_sdp_log(const char *level, struct
device *dev,
#undef DP_SDP_LOG
}
EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
+
+/**
+ * drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
+ * @dpcd: DisplayPort configuration data
+ * @port_cap: port capabilities
+ *
+ * Returns maximum frl bandwidth supported by PCON in GBPS.
+ **/
+int drm_dp_get_pcon_max_frl_bw(struct drm_dp_aux *aux,
+ const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+ const u8 port_cap[4])
+{
+ int bw;
+ u8 buf;
+
+ buf = port_cap[2];
+ bw = buf & DP_PCON_MAX_FRL_BW;
+
+ switch (bw) {
+ case DP_PCON_MAX_9GBPS:
+ return 9;
+ case DP_PCON_MAX_18GBPS:
+ return 18;
+ case DP_PCON_MAX_24GBPS:
+ return 24;
+ case DP_PCON_MAX_32GBPS:
+ return 32;
+ case DP_PCON_MAX_40GBPS:
+ return 40;
+ case DP_PCON_MAX_48GBPS:
+ return 48;
+ case DP_PCON_MAX_0GBPS:
+ default:
+ return 0;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_get_pcon_max_frl_bw);
+
+/**
+ * drm_dp_get_hdmi_max_frl_bw() - maximum frl supported by HDMI Sink
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns maximum frl bandwidth supported by HDMI in Gbps on success,
+ * else returns negative error code.
+ **/
+int drm_dp_get_hdmi_max_frl_bw(struct drm_dp_aux *aux)
+{
+ u8 buf;
+ int bw, ret;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_SINK, );
+ if (ret < 0)
+ return ret;
+ bw = buf & DP_HDMI_SINK_LINK_BW;
+
+ switch (bw) {
+ case DP_HDMI_SINK_BW_9GBPS:
+ return 9;
+ case DP_HDMI_SINK_BW_18GBPS:
+ return 18;
+ case DP_HDMI_SINK_BW_24GBPS:
+ return 24;
+ case DP_HDMI_SINK_BW_32GBPS:
+ return 32;
+ case DP_HDMI_SINK_BW_40GBPS:
+ return 40;
+ case DP_HDMI_SINK_BW_48GBPS:
+ return 48;
+ case DP_HDMI_SINK_BW_0GBPS:
+ default:
+ return 0;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_get_hdmi_max_frl_bw);
+
+/**
+ * drm_dp_pcon_frl_prepare() - Prepare PCON for FRL.
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns 0 if success, else returns negative error code.
+ **/
+int drm_dp_pcon_frl_prepare(struct drm_dp_aux *aux, bool enable_frl_ready_hpd)
+{
+ int ret;
+ u8 buf = DP_PCON_ENABLE_SOURCE_CTL_MODE |
+DP_PCON_ENABLE_LINK_FRL_MODE;
+
+ if (enable_frl_ready_hpd)
+ buf |= DP_PCON_ENABLE_HPD_READY;
+
+ ret = drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_1, buf);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_dp_pcon_frl_prepare);
+
+/**
+ * drm_dp_pcon_is_frl_ready() - Is PCON ready for FRL
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns true if success, else returns false.
+ **/
+bool drm_dp_pcon_is_frl_ready(struct drm_dp_aux *aux)
+{
+ int ret;
+ u8 buf;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_TX_LINK_STATUS, );
+ if (ret < 0)
+ return false;
+
+ if (buf & DP_PCON_FRL_READY)
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL(drm_dp_pcon_is_frl_ready);
+
+/**
+ * drm_dp_pcon_frl_configure_1() - Set HDMI LINK Configuration-Step1
+ * @aux: DisplayPort AUX channel
+ * max_frl_mask: mask for selecting the bandwidths supported by source,
+ * to be tried by Pcon f/w.
+ * @concurrent_mode: true if concurrent mode or operation is required,
+ * false otherwise.
+ *
+ * Returns 0 if success, else returns negative error code.
+ **/
+
+int drm_dp_pcon_frl_configure_1(struct drm_dp_aux *aux, int max_frl_gbps,
+ bool concurrent_mode)
+{
+ int ret;
+ u8 buf;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_LINK_CONFIG_1, );
+ if (ret < 0)
+ return ret;
+
+ if (concurrent_mode)
+ buf |= DP_PCON_ENABLE_CONCURRENT_LINK;
+ else
+ buf &= ~DP_PCON_ENABLE_CONCURRENT_LINK;
+
+ switch (max_frl_gbps) {
+ case 9:
+ buf |= DP_PCON_ENABLE_MAX_BW_9GBPS;
+ break;
+ case 18:
+ buf |= DP_PCON_ENABLE_MAX_BW_18GBPS;
+ break;
+ case 24:
+ buf |= DP_PCON_ENABLE_MAX_BW_24GBPS;
+ break;
+ case 32:
+
[Intel-gfx] [RFC 5/7] drm/i915: Check for FRL training before DP Link training
This patch calls functions to check FRL training requirements for an HDMI2.1 sink, when connected through PCON. The call is made before the DP link training. In case FRL is not required or failure during FRL training, the TMDS mode is selected for the pcon. Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++ drivers/gpu/drm/i915/display/intel_dp.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index 4d06178cd76c..cf8a8e2a64f7 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -3389,6 +3389,8 @@ static void tgl_ddi_pre_enable_dp(struct intel_atomic_state *state, if (!is_mst) intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); + intel_dp_check_frl_training(intel_dp); + intel_dp_sink_set_decompression_state(intel_dp, crtc_state, true); /* * DDI FEC: "anticipates enabling FEC encoding sets the FEC_READY bit diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 3a8e69e5bbfb..b6e53e4f06ee 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -4129,6 +4129,7 @@ static void intel_enable_dp(struct intel_atomic_state *state, intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); intel_dp_configure_protocol_converter(intel_dp); + intel_dp_check_frl_training(intel_dp); intel_dp_start_link_train(intel_dp); intel_dp_stop_link_train(intel_dp); @@ -6050,6 +6051,7 @@ int intel_dp_retrain_link(struct intel_encoder *encoder, intel_crtc_pch_transcoder(crtc), false); } + intel_dp_check_frl_training(intel_dp); intel_dp_start_link_train(intel_dp); intel_dp_stop_link_train(intel_dp); -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 7/7] drm/i915: Add support for enabling link status and recovery
From: Swati Sharma
In this patch enabled support for link status and recovery in i915
driver. HDMI link loss indication to upstream DP source is indicated
via IRQ_HPD. This is followed by reading of HDMI link configuration
status (HDMI_TX_LINK_ACTIVE_STATUS). If the PCON → HDMI 2.1 link status
is off; reinitiate frl link training to recover.
Also, HDMI FRL link error count range for each individual FRL
active lane is indicated by DOWNSTREAM_HDMI_ERROR_STATUS_LN registers.
Signed-off-by: Swati Sharma
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 47 +++--
1 file changed, 44 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index b6e53e4f06ee..0de4c72e66c1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5893,6 +5893,29 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
return link_ok;
}
+static void
+intel_dp_handle_hdmi_link_status_change(struct intel_dp *intel_dp)
+{
+ bool is_active;
+ u8 buf = 0;
+
+ is_active = drm_dp_pcon_hdmi_link_active(_dp->aux);
+ if (intel_dp->frl.is_trained && !is_active) {
+ if (drm_dp_dpcd_readb(_dp->aux,
DP_PCON_HDMI_LINK_CONFIG_1, ) < 0)
+ return;
+
+ buf &= ~DP_PCON_ENABLE_HDMI_LINK;
+ if (drm_dp_dpcd_writeb(_dp->aux,
DP_PCON_HDMI_LINK_CONFIG_1, buf) < 0)
+ return;
+
+ intel_dp->frl.is_trained = false;
+ intel_dp->frl.trained_rate_gbps = 0;
+
+ intel_dp_check_frl_training(intel_dp);
+ drm_dp_pcon_hdmi_frl_link_error_count(_dp->aux,
_dp->attached_connector->base);
+ }
+}
+
static bool
intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
{
@@ -6121,7 +6144,7 @@ intel_dp_hotplug(struct intel_encoder *encoder,
return state;
}
-static void intel_dp_check_service_irq(struct intel_dp *intel_dp)
+static void intel_dp_check_device_service_irq(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 val;
@@ -6145,6 +6168,23 @@ static void intel_dp_check_service_irq(struct intel_dp
*intel_dp)
drm_dbg_kms(>drm, "Sink specific irq unhandled\n");
}
+static void intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
+{
+ u8 val;
+
+ if (intel_dp->dpcd[DP_DPCD_REV] < 0x11)
+ return;
+
+ if (drm_dp_dpcd_readb(_dp->aux,
+ DP_LINK_SERVICE_IRQ_VECTOR_ESI0, ) != 1 ||
!val)
+ return;
+
+ drm_dp_dpcd_writeb(_dp->aux, DP_LINK_SERVICE_IRQ_VECTOR_ESI0,
val);
+
+ if (val & HDMI_LINK_STATUS_CHANGED)
+ intel_dp_handle_hdmi_link_status_change(intel_dp);
+}
+
/*
* According to DP spec
* 5.1.2:
@@ -6184,7 +6224,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
return false;
}
- intel_dp_check_service_irq(intel_dp);
+ intel_dp_check_device_service_irq(intel_dp);
+ intel_dp_check_link_service_irq(intel_dp);
/* Handle CEC interrupts, if any */
drm_dp_cec_irq(_dp->aux);
@@ -6594,7 +6635,7 @@ intel_dp_detect(struct drm_connector *connector,
to_intel_connector(connector)->detect_edid)
status = connector_status_connected;
- intel_dp_check_service_irq(intel_dp);
+ intel_dp_check_device_service_irq(intel_dp);
out:
if (status != connector_status_connected && !intel_dp->is_mst)
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Don't hide the intel_crtc_atomic_check() call
From: Ville Syrjälä
Move the intel_crtc_atomic_check() call out from the variable
declarations to a place where we can actually see it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 5a9d933e425a..11862de3d772 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14844,8 +14844,10 @@ static int intel_atomic_check_crtcs(struct
intel_atomic_state *state)
int i;
for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
- int ret = intel_crtc_atomic_check(state, crtc);
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+ int ret;
+
+ ret = intel_crtc_atomic_check(state, crtc);
if (ret) {
drm_dbg_atomic(>drm,
"[CRTC:%d:%s] atomic driver check
failed\n",
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Make intel_{enable, disable}_sagv() static
From: Ville Syrjälä
intel_{enable,disable}_sagv() are no longer needed outside the
compilation unit. Make them static.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
drivers/gpu/drm/i915/intel_pm.h | 2 --
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 34e0d22d456b..8cd62402d597 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3706,7 +3706,7 @@ skl_setup_sagv_block_time(struct drm_i915_private
*dev_priv)
* - All planes can enable watermarks for latencies >= SAGV engine block time
* - We're not using an interlaced display configuration
*/
-int
+static int
intel_enable_sagv(struct drm_i915_private *dev_priv)
{
int ret;
@@ -3740,7 +3740,7 @@ intel_enable_sagv(struct drm_i915_private *dev_priv)
return 0;
}
-int
+static int
intel_disable_sagv(struct drm_i915_private *dev_priv)
{
int ret;
diff --git a/drivers/gpu/drm/i915/intel_pm.h b/drivers/gpu/drm/i915/intel_pm.h
index a2473594c2db..eab83e251dd5 100644
--- a/drivers/gpu/drm/i915/intel_pm.h
+++ b/drivers/gpu/drm/i915/intel_pm.h
@@ -49,8 +49,6 @@ void g4x_wm_sanitize(struct drm_i915_private *dev_priv);
void vlv_wm_sanitize(struct drm_i915_private *dev_priv);
bool intel_can_enable_sagv(struct drm_i915_private *dev_priv,
const struct intel_bw_state *bw_state);
-int intel_enable_sagv(struct drm_i915_private *dev_priv);
-int intel_disable_sagv(struct drm_i915_private *dev_priv);
void intel_sagv_pre_plane_update(struct intel_atomic_state *state);
void intel_sagv_post_plane_update(struct intel_atomic_state *state);
bool skl_wm_level_equals(const struct skl_wm_level *l1,
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for dma-buf: Flag vmap'ed memory as system or I/O memory (rev3)
== Series Details == Series: dma-buf: Flag vmap'ed memory as system or I/O memory (rev3) URL : https://patchwork.freedesktop.org/series/81647/ 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: cast
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for dma-buf: Flag vmap'ed memory as system or I/O memory (rev3)
== Series Details == Series: dma-buf: Flag vmap'ed memory as system or I/O memory (rev3) URL : https://patchwork.freedesktop.org/series/81647/ State : warning == Summary == $ dim checkpatch origin/drm-tip c94eaf86e18e dma-buf: Add struct dma-buf-map for storing struct dma_buf.vaddr_ptr -:47: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() #47: FILE: drivers/dma-buf/dma-buf.c:1212: + BUG_ON(dma_buf_map_is_null(>vmap_ptr)); -:53: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() #53: FILE: drivers/dma-buf/dma-buf.c:1217: + BUG_ON(dma_buf_map_is_set(>vmap_ptr)); -:71: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() #71: FILE: drivers/dma-buf/dma-buf.c:1244: + BUG_ON(dma_buf_map_is_null(>vmap_ptr)); -:74: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() #74: FILE: drivers/dma-buf/dma-buf.c:1246: + BUG_ON(!dma_buf_map_is_vaddr(>vmap_ptr, vaddr)); -:86: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #86: new file mode 100644 total: 0 errors, 5 warnings, 0 checks, 138 lines checked 55973e093508 dma-buf: Use struct dma_buf_map in dma_buf_vmap() interfaces c929afc2d68f dma-buf: Use struct dma_buf_map in dma_buf_vunmap() interfaces -:48: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() #48: FILE: drivers/dma-buf/dma-buf.c:1250: + BUG_ON(!dma_buf_map_is_equal(>vmap_ptr, map)); total: 0 errors, 1 warnings, 0 checks, 287 lines checked 993652ae5805 dma-buf: Document struct dma_buf_map ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: Redo "Remove i915_request.lock requirement for execution callbacks"
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Redo "Remove i915_request.lock
requirement for execution callbacks"
URL : https://patchwork.freedesktop.org/series/82091/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9056 -> Patchwork_18571
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18571/index.html
Known issues
Here are the changes found in Patchwork_18571 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18571/fi-byt-j1900/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18571/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-cml-s: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-cml-s/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18571/fi-cml-s/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
Possible fixes
* igt@kms_busy@basic@flip:
- {fi-tgl-dsi}: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18571/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
- fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18571/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18571/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18571/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
Warnings
* igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92]) ->
[DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18571/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +4 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18571/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#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
[k.org#205379]: https://bugzilla.kernel.org/show_bug.cgi?id=205379
Participating hosts (46 -> 39)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_9056 -> Patchwork_18571
CI-20190529: 20190529
CI_DRM_9056: 637f215bda901249b97da25ee2983f72cc12e1c5 @
[Intel-gfx] [PATCH v3 3/4] dma-buf: Use struct dma_buf_map in dma_buf_vunmap() interfaces
This patch updates dma_buf_vunmap() and dma-buf's vunmap callback to
use struct dma_buf_map. The interfaces used to receive a buffer address.
This address is now given in an instance of the structure.
Users of the functions are updated accordingly. This is only an interface
change. It is currently expected that dma-buf memory can be accessed with
system memory load/store operations.
v2:
* include dma-buf-heaps and i915 selftests (kernel test robot)
* initialize cma_obj before using it in drm_gem_cma_free_object()
(kernel test robot)
Signed-off-by: Thomas Zimmermann
Acked-by: Sumit Semwal
Acked-by: Christian König
Acked-by: Daniel Vetter
---
drivers/dma-buf/dma-buf.c | 8 ++---
drivers/dma-buf/heaps/heap-helpers.c | 2 +-
drivers/gpu/drm/drm_gem_cma_helper.c | 9 +++---
drivers/gpu/drm/drm_gem_shmem_helper.c| 3 +-
drivers/gpu/drm/drm_prime.c | 6 ++--
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 5 +--
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 2 +-
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 6 ++--
.../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 4 +--
drivers/gpu/drm/tegra/gem.c | 5 +--
.../common/videobuf2/videobuf2-dma-contig.c | 3 +-
.../media/common/videobuf2/videobuf2-dma-sg.c | 3 +-
.../common/videobuf2/videobuf2-vmalloc.c | 6 ++--
include/drm/drm_prime.h | 2 +-
include/linux/dma-buf-map.h | 32 +--
include/linux/dma-buf.h | 4 +--
16 files changed, 66 insertions(+), 34 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 61bd24d21b38..a6ba4d598f0e 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1236,21 +1236,21 @@ EXPORT_SYMBOL_GPL(dma_buf_vmap);
/**
* dma_buf_vunmap - Unmap a vmap obtained by dma_buf_vmap.
* @dmabuf:[in]buffer to vunmap
- * @vaddr: [in]vmap to vunmap
+ * @map: [in]vmap pointer to vunmap
*/
-void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
+void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map)
{
if (WARN_ON(!dmabuf))
return;
BUG_ON(dma_buf_map_is_null(>vmap_ptr));
BUG_ON(dmabuf->vmapping_counter == 0);
- BUG_ON(!dma_buf_map_is_vaddr(>vmap_ptr, vaddr));
+ BUG_ON(!dma_buf_map_is_equal(>vmap_ptr, map));
mutex_lock(>lock);
if (--dmabuf->vmapping_counter == 0) {
if (dmabuf->ops->vunmap)
- dmabuf->ops->vunmap(dmabuf, vaddr);
+ dmabuf->ops->vunmap(dmabuf, map);
dma_buf_map_clear(>vmap_ptr);
}
mutex_unlock(>lock);
diff --git a/drivers/dma-buf/heaps/heap-helpers.c
b/drivers/dma-buf/heaps/heap-helpers.c
index aeb9e100f339..fcf4ce3e2cbb 100644
--- a/drivers/dma-buf/heaps/heap-helpers.c
+++ b/drivers/dma-buf/heaps/heap-helpers.c
@@ -251,7 +251,7 @@ static int dma_heap_dma_buf_vmap(struct dma_buf *dmabuf,
struct dma_buf_map *map
return 0;
}
-static void dma_heap_dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
+static void dma_heap_dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map
*map)
{
struct heap_helper_buffer *buffer = dmabuf->priv;
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 19670b05ead5..2165633c9b9e 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -175,13 +175,12 @@ drm_gem_cma_create_with_handle(struct drm_file *file_priv,
*/
void drm_gem_cma_free_object(struct drm_gem_object *gem_obj)
{
- struct drm_gem_cma_object *cma_obj;
-
- cma_obj = to_drm_gem_cma_obj(gem_obj);
+ struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(gem_obj);
+ struct dma_buf_map map = DMA_BUF_MAP_INIT_VADDR(cma_obj->vaddr);
if (gem_obj->import_attach) {
if (cma_obj->vaddr)
- dma_buf_vunmap(gem_obj->import_attach->dmabuf,
cma_obj->vaddr);
+ dma_buf_vunmap(gem_obj->import_attach->dmabuf, );
drm_prime_gem_destroy(gem_obj, cma_obj->sgt);
} else if (cma_obj->vaddr) {
dma_free_wc(gem_obj->dev->dev, cma_obj->base.size,
@@ -628,7 +627,7 @@ drm_gem_cma_prime_import_sg_table_vmap(struct drm_device
*dev,
obj = drm_gem_cma_prime_import_sg_table(dev, attach, sgt);
if (IS_ERR(obj)) {
- dma_buf_vunmap(attach->dmabuf, map.vaddr);
+ dma_buf_vunmap(attach->dmabuf, );
return obj;
}
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 6328cfbb828e..fb11df7aced5 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -337,6 +337,7 @@ EXPORT_SYMBOL(drm_gem_shmem_vmap);
static void
[Intel-gfx] [PATCH v3 4/4] dma-buf: Document struct dma_buf_map
This patch adds struct dma_buf_map and its helpers to the documentation. A short tutorial is included. v3: * update documentation in a separate patch * expand docs (Daniel) * carry-over acks from patch 1 Signed-off-by: Thomas Zimmermann Reviewed-by: Christian König Reviewed-by: Daniel Vetter Acked-by: Sumit Semwal --- Documentation/driver-api/dma-buf.rst | 9 include/linux/dma-buf-map.h | 72 2 files changed, 81 insertions(+) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 13ea0cc0a3fa..6dbcc4714b0b 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -115,6 +115,15 @@ Kernel Functions and Structures Reference .. kernel-doc:: include/linux/dma-buf.h :internal: +Buffer Mapping Helpers +~~ + +.. kernel-doc:: include/linux/dma-buf-map.h + :doc: overview + +.. kernel-doc:: include/linux/dma-buf-map.h + :internal: + Reservation Objects --- diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h index c173a4abf4ba..fd1aba545fdf 100644 --- a/include/linux/dma-buf-map.h +++ b/include/linux/dma-buf-map.h @@ -8,6 +8,78 @@ #include +/** + * DOC: overview + * + * Calling dma-buf's vmap operation returns a pointer to the buffer's memory. + * Depending on the location of the buffer, users may have to access it with + * I/O operations or memory load/store operations. For example, copying to + * system memory could be done with memcpy(), copying to I/O memory would be + * done with memcpy_toio(). + * + * .. code-block:: c + * + * void *vaddr = ...; // pointer to system memory + * memcpy(vaddr, src, len); + * + * void *vaddr_iomem = ...; // pointer to I/O memory + * memcpy_toio(vaddr, _iomem, src, len); + * + * When using dma-buf's vmap operation, the returned pointer is encoded as + * :c:type:`struct dma_buf_map `. + * :c:type:`struct dma_buf_map ` stores the buffer's address in + * system or I/O memory and a flag that signals the required method of + * accessing the buffer. Use the returned instance and the helper functions + * to access the buffer's memory in the correct way. + * + * Open-coding access to :c:type:`struct dma_buf_map ` is + * considered bad style. Rather then accessing its fields directly, use one + * of the provided helper functions, or implement your own. For example, + * instances of :c:type:`struct dma_buf_map ` can be initialized + * statically with DMA_BUF_MAP_INIT_VADDR(), or at runtime with + * dma_buf_map_set_vaddr(). These helpers will set an address in system memory. + * + * .. code-block:: c + * + * struct dma_buf_map map = DMA_BUF_MAP_INIT_VADDR(0xdeadbeaf); + * + * dma_buf_map_set_vaddr( 0xdeadbeaf); + * + * Test if a mapping is valid with either dma_buf_map_is_set() or + * dma_buf_map_is_null(). + * + * .. code-block:: c + * + * if (dma_buf_map_is_set() != dma_buf_map_is_null()) + * // always true + * + * Instances of :c:type:`struct dma_buf_map ` can be compared + * for equality with dma_buf_map_is_equal(). Mappings the point to different + * memory spaces, system or I/O, are never equal. That's even true if both + * spaces are located in the same address space, both mappings contain the + * same address value, or both mappings refer to NULL. + * + * .. code-block:: c + * + * struct dma_buf_map sys_map; // refers to system memory + * struct dma_buf_map io_map; // refers to I/O memory + * + * if (dma_buf_map_is_equal(_map, _map)) + * // always false + * + * Instances of struct dma_buf_map do not have to be cleaned up, but + * can be cleared to NULL with dma_buf_map_clear(). Cleared mappings + * always refer to system memory. + * + * The type :c:type:`struct dma_buf_map ` and its helpers are + * actually independent from the dma-buf infrastructure. When sharing buffers + * among devices, drivers have to know the location of the memory to access + * the buffers in a safe way. :c:type:`struct dma_buf_map ` + * solves this problem for dma-buf and its users. If other drivers or + * sub-systems require similar functionality, the type could be generalized + * and moved to a more prominent header file. + */ + /** * struct dma_buf_map - Pointer to vmap'ed dma-buf memory. * @vaddr_iomem: The buffer's address if in I/O memory -- 2.28.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/4] dma-buf: Add struct dma-buf-map for storing struct dma_buf.vaddr_ptr
The new type struct dma_buf_map represents a mapping of dma-buf memory
into kernel space. It contains a flag, is_iomem, that signals users to
access the mapped memory with I/O operations instead of regular loads
and stores.
It was assumed that DMA buffer memory can be accessed with regular load
and store operations. Some architectures, such as sparc64, require the
use of I/O operations to access dma-map buffers that are located in I/O
memory. Providing struct dma_buf_map allows drivers to implement this.
This was specifically a problem when refreshing the graphics framebuffer
on such systems. [1]
As the first step, struct dma_buf stores an instance of struct dma_buf_map
internally. Afterwards, dma-buf's vmap and vunmap interfaces are be
converted. Finally, affected drivers can be fixed.
v3:
* moved documentation into separate patch
* test for NULL pointers with !
[1] https://lore.kernel.org/dri-devel/20200725191012.ga434...@ravnborg.org/
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
Reviewed-by: Daniel Vetter
Acked-by: Sumit Semwal
---
drivers/dma-buf/dma-buf.c | 14 +++
include/linux/dma-buf-map.h | 82 +
include/linux/dma-buf.h | 3 +-
3 files changed, 91 insertions(+), 8 deletions(-)
create mode 100644 include/linux/dma-buf-map.h
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 58564d82a3a2..5e849ca241a0 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1207,12 +1207,12 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
mutex_lock(>lock);
if (dmabuf->vmapping_counter) {
dmabuf->vmapping_counter++;
- BUG_ON(!dmabuf->vmap_ptr);
- ptr = dmabuf->vmap_ptr;
+ BUG_ON(dma_buf_map_is_null(>vmap_ptr));
+ ptr = dmabuf->vmap_ptr.vaddr;
goto out_unlock;
}
- BUG_ON(dmabuf->vmap_ptr);
+ BUG_ON(dma_buf_map_is_set(>vmap_ptr));
ptr = dmabuf->ops->vmap(dmabuf);
if (WARN_ON_ONCE(IS_ERR(ptr)))
@@ -1220,7 +1220,7 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
if (!ptr)
goto out_unlock;
- dmabuf->vmap_ptr = ptr;
+ dmabuf->vmap_ptr.vaddr = ptr;
dmabuf->vmapping_counter = 1;
out_unlock:
@@ -1239,15 +1239,15 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
if (WARN_ON(!dmabuf))
return;
- BUG_ON(!dmabuf->vmap_ptr);
+ BUG_ON(dma_buf_map_is_null(>vmap_ptr));
BUG_ON(dmabuf->vmapping_counter == 0);
- BUG_ON(dmabuf->vmap_ptr != vaddr);
+ BUG_ON(!dma_buf_map_is_vaddr(>vmap_ptr, vaddr));
mutex_lock(>lock);
if (--dmabuf->vmapping_counter == 0) {
if (dmabuf->ops->vunmap)
dmabuf->ops->vunmap(dmabuf, vaddr);
- dmabuf->vmap_ptr = NULL;
+ dma_buf_map_clear(>vmap_ptr);
}
mutex_unlock(>lock);
}
diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
new file mode 100644
index ..00143c88feb6
--- /dev/null
+++ b/include/linux/dma-buf-map.h
@@ -0,0 +1,82 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Pointer to dma-buf-mapped memory, plus helpers.
+ */
+
+#ifndef __DMA_BUF_MAP_H__
+#define __DMA_BUF_MAP_H__
+
+#include
+
+/**
+ * struct dma_buf_map - Pointer to vmap'ed dma-buf memory.
+ * @vaddr_iomem: The buffer's address if in I/O memory
+ * @vaddr: The buffer's address if in system memory
+ * @is_iomem: True if the dma-buf memory is located in I/O
+ * memory, or false otherwise.
+ */
+struct dma_buf_map {
+ union {
+ void __iomem *vaddr_iomem;
+ void *vaddr;
+ };
+ bool is_iomem;
+};
+
+/* API transition helper */
+static inline bool dma_buf_map_is_vaddr(const struct dma_buf_map *map, const
void *vaddr)
+{
+ return !map->is_iomem && (map->vaddr == vaddr);
+}
+
+/**
+ * dma_buf_map_is_null - Tests for a dma-buf mapping to be NULL
+ * @map: The dma-buf mapping structure
+ *
+ * Depending on the state of struct dma_buf_map.is_iomem, tests if the
+ * mapping is NULL.
+ *
+ * Returns:
+ * True if the mapping is NULL, or false otherwise.
+ */
+static inline bool dma_buf_map_is_null(const struct dma_buf_map *map)
+{
+ if (map->is_iomem)
+ return !map->vaddr_iomem;
+ return !map->vaddr;
+}
+
+/**
+ * dma_buf_map_is_set - Tests is the dma-buf mapping has been set
+ * @map: The dma-buf mapping structure
+ *
+ * Depending on the state of struct dma_buf_map.is_iomem, tests if the
+ * mapping has been set.
+ *
+ * Returns:
+ * True if the mapping is been set, or false otherwise.
+ */
+static inline bool dma_buf_map_is_set(const struct dma_buf_map *map)
+{
+ return !dma_buf_map_is_null(map);
+}
+
+/**
+ * dma_buf_map_clear - Clears a dma-buf mapping structure
+ * @map: The dma-buf
[Intel-gfx] [PATCH v3 0/4] dma-buf: Flag vmap'ed memory as system or I/O memory
Dma-buf provides vmap() and vunmap() for retriving and releasing mappings of dma-buf memory in kernel address space. The functions operate with plain addresses and the assumption is that the memory can be accessed with load and store operations. This is not the case on some architectures (e.g., sparc64) where I/O memory can only be accessed with dedicated instructions. This patchset introduces struct dma_buf_map, which contains the address of a buffer and a flag that tells whether system- or I/O-memory instructions are required. Some background: updating the DRM framebuffer console on sparc64 makes the kernel panic. This is because the framebuffer memory cannot be accessed with system-memory instructions. We currently employ a workaround in DRM to address this specific problem. [1] To resolve the problem, we'd like to address it at the most common point, which is the dma-buf framework. The dma-buf mapping ideally knows if I/O instructions are required and exports this information to it's users. The new structure struct dma_buf_map stores the buffer address and a flag that signals I/O memory. Affected users of the buffer (e.g., drivers, frameworks) can then access the memory accordingly. This patchset only introduces struct dma_buf_map, and updates struct dma_buf and it's interfaces. Further patches can update dma-buf users. For example, there's a prototype patchset for DRM that fixes the framebuffer problem. [2] Further work: TTM, one of DRM's memory managers, already exports an is_iomem flag of its own. It could later be switched over to exporting struct dma_buf_map, thus simplifying some code. Several DRM drivers expect their fbdev console to operate on I/O memory. These could possibly be switched over to the generic fbdev emulation, as soon as the generic code uses struct dma_buf_map. v3: * update fastrpc driver (kernel test robot) * expand documentation (Daniel) * move documentation into separate patch v2: * always clear map parameter in dma_buf_vmap() (Daniel) * include dma-buf-heaps and i915 selftests (kernel test robot) * initialize cma_obj before using it in drm_gem_cma_free_object() (kernel test robot) [1] https://lore.kernel.org/dri-devel/20200725191012.ga434...@ravnborg.org/ [2] https://lore.kernel.org/dri-devel/20200806085239.4606-1-tzimmerm...@suse.de/ Thomas Zimmermann (4): dma-buf: Add struct dma-buf-map for storing struct dma_buf.vaddr_ptr dma-buf: Use struct dma_buf_map in dma_buf_vmap() interfaces dma-buf: Use struct dma_buf_map in dma_buf_vunmap() interfaces dma-buf: Document struct dma_buf_map Documentation/driver-api/dma-buf.rst | 9 + drivers/dma-buf/dma-buf.c | 42 ++-- drivers/dma-buf/heaps/heap-helpers.c | 10 +- drivers/gpu/drm/drm_gem_cma_helper.c | 20 +- drivers/gpu/drm/drm_gem_shmem_helper.c| 17 +- drivers/gpu/drm/drm_prime.c | 15 +- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 13 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 13 +- .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 18 +- .../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 14 +- drivers/gpu/drm/tegra/gem.c | 23 ++- .../common/videobuf2/videobuf2-dma-contig.c | 17 +- .../media/common/videobuf2/videobuf2-dma-sg.c | 19 +- .../common/videobuf2/videobuf2-vmalloc.c | 21 +- drivers/misc/fastrpc.c| 6 +- include/drm/drm_prime.h | 5 +- include/linux/dma-buf-map.h | 193 ++ include/linux/dma-buf.h | 11 +- 18 files changed, 372 insertions(+), 94 deletions(-) create mode 100644 include/linux/dma-buf-map.h -- 2.28.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/4] dma-buf: Use struct dma_buf_map in dma_buf_vmap() interfaces
This patch updates dma_buf_vmap() and dma-buf's vmap callback to use
struct dma_buf_map.
The interfaces used to return a buffer address. This address now gets
stored in an instance of the structure that is given as an additional
argument. The functions return an errno code on errors.
Users of the functions are updated accordingly. This is only an interface
change. It is currently expected that dma-buf memory can be accessed with
system memory load/store operations.
v3:
* update fastrpc driver (kernel test robot)
v2:
* always clear map parameter in dma_buf_vmap() (Daniel)
* include dma-buf-heaps and i915 selftests (kernel test robot)
Signed-off-by: Thomas Zimmermann
Acked-by: Sumit Semwal
Acked-by: Christian König
Acked-by: Daniel Vetter
---
drivers/dma-buf/dma-buf.c | 28 +++
drivers/dma-buf/heaps/heap-helpers.c | 8 --
drivers/gpu/drm/drm_gem_cma_helper.c | 13 +
drivers/gpu/drm/drm_gem_shmem_helper.c| 14 ++
drivers/gpu/drm/drm_prime.c | 9 --
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 8 +-
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 11 ++--
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 12 ++--
.../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 10 +--
drivers/gpu/drm/tegra/gem.c | 18
.../common/videobuf2/videobuf2-dma-contig.c | 14 +++---
.../media/common/videobuf2/videobuf2-dma-sg.c | 16 +++
.../common/videobuf2/videobuf2-vmalloc.c | 15 +++---
drivers/misc/fastrpc.c| 6 ++--
include/drm/drm_prime.h | 3 +-
include/linux/dma-buf-map.h | 13 +
include/linux/dma-buf.h | 6 ++--
17 files changed, 143 insertions(+), 61 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 5e849ca241a0..61bd24d21b38 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1186,46 +1186,50 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
* dma_buf_vmap - Create virtual mapping for the buffer object into kernel
* address space. Same restrictions as for vmap and friends apply.
* @dmabuf:[in]buffer to vmap
+ * @map: [out] returns the vmap pointer
*
* This call may fail due to lack of virtual mapping address space.
* These calls are optional in drivers. The intended use for them
* is for mapping objects linear in kernel space for high use objects.
* Please attempt to use kmap/kunmap before thinking about these interfaces.
*
- * Returns NULL on error.
+ * Returns 0 on success, or a negative errno code otherwise.
*/
-void *dma_buf_vmap(struct dma_buf *dmabuf)
+int dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map *map)
{
- void *ptr;
+ struct dma_buf_map ptr;
+ int ret = 0;
+
+ dma_buf_map_clear(map);
if (WARN_ON(!dmabuf))
- return NULL;
+ return -EINVAL;
if (!dmabuf->ops->vmap)
- return NULL;
+ return -EINVAL;
mutex_lock(>lock);
if (dmabuf->vmapping_counter) {
dmabuf->vmapping_counter++;
BUG_ON(dma_buf_map_is_null(>vmap_ptr));
- ptr = dmabuf->vmap_ptr.vaddr;
+ *map = dmabuf->vmap_ptr;
goto out_unlock;
}
BUG_ON(dma_buf_map_is_set(>vmap_ptr));
- ptr = dmabuf->ops->vmap(dmabuf);
- if (WARN_ON_ONCE(IS_ERR(ptr)))
- ptr = NULL;
- if (!ptr)
+ ret = dmabuf->ops->vmap(dmabuf, );
+ if (WARN_ON_ONCE(ret))
goto out_unlock;
- dmabuf->vmap_ptr.vaddr = ptr;
+ dmabuf->vmap_ptr = ptr;
dmabuf->vmapping_counter = 1;
+ *map = dmabuf->vmap_ptr;
+
out_unlock:
mutex_unlock(>lock);
- return ptr;
+ return ret;
}
EXPORT_SYMBOL_GPL(dma_buf_vmap);
diff --git a/drivers/dma-buf/heaps/heap-helpers.c
b/drivers/dma-buf/heaps/heap-helpers.c
index d0696cf937af..aeb9e100f339 100644
--- a/drivers/dma-buf/heaps/heap-helpers.c
+++ b/drivers/dma-buf/heaps/heap-helpers.c
@@ -235,7 +235,7 @@ static int dma_heap_dma_buf_end_cpu_access(struct dma_buf
*dmabuf,
return 0;
}
-static void *dma_heap_dma_buf_vmap(struct dma_buf *dmabuf)
+static int dma_heap_dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map
*map)
{
struct heap_helper_buffer *buffer = dmabuf->priv;
void *vaddr;
@@ -244,7 +244,11 @@ static void *dma_heap_dma_buf_vmap(struct dma_buf *dmabuf)
vaddr = dma_heap_buffer_vmap_get(buffer);
mutex_unlock(>lock);
- return vaddr;
+ if (!vaddr)
+ return -ENOMEM;
+ dma_buf_map_set_vaddr(map, vaddr);
+
+ return 0;
}
static void dma_heap_dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/2] drm/i915: Redo "Remove i915_request.lock requirement for execution callbacks"
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Redo "Remove i915_request.lock
requirement for execution callbacks"
URL : https://patchwork.freedesktop.org/series/82091/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e9ed1a8a1759 drm/i915: Redo "Remove i915_request.lock requirement for execution
callbacks"
-:9: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 99f0a640d464 ("drm/i915: Remove
requirement for holding i915_request.lock for breadcrumbs")'
#9:
revert an earlier correction. Let us restore commit 99f0a640d464
total: 1 errors, 0 warnings, 0 checks, 18 lines checked
22345dfa1434 drm/i915/gem: Hold request reference for canceling an active
context
-:16: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#16:
<4> [582.745252] general protection fault, probably for non-canonical address
0xcd5c: [#1] PREEMPT SMP PTI
total: 0 errors, 1 warnings, 0 checks, 40 lines checked
___
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 25/09/2020 08:13, Leon Romanovsky wrote:
On Thu, Sep 24, 2020 at 09:21:20AM +0100, Tvrtko Ursulin wrote:
On 22/09/2020 09:39, Leon Romanovsky wrote:
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).
So it's appending and growing the "list", did I get that right? Sounds handy
indeed. Some comments/questions below.
Yes, we (RDMA) use this function to chain contiguous pages.
I will eveluate if i915 could start using it. We have some loops which
build page by page and coalesce.
[snip]
if (unlikely(ret))
diff --git a/tools/testing/scatterlist/main.c b/tools/testing/scatterlist/main.c
index 0a1464181226..4899359a31ac 100644
--- a/tools/testing/scatterlist/main.c
+++ b/tools/testing/scatterlist/main.c
@@ -55,14 +55,13 @@ int main(void)
for (i = 0, test = tests; test->expected_segments; test++, i++) {
struct page *pages[MAX_PAGES];
struct sg_table st;
- int ret;
+ struct scatterlist *sg;
set_pages(pages, test->pfn, test->num_pages);
- ret = __sg_alloc_table_from_pages(, pages, test->num_pages,
- 0, test->size, test->max_seg,
- GFP_KERNEL);
- assert(ret == test->alloc_ret);
+ sg = __sg_alloc_table_from_pages(, pages, test->num_pages, 0,
+ test->size, test->max_seg, NULL, 0, GFP_KERNEL);
+ assert(PTR_ERR_OR_ZERO(sg) == test->alloc_ret);
Some test coverage for relatively complex code would be very welcomed. Since
the testing framework is already there, even if it bit-rotted a bit, but
shouldn't be hard to fix.
A few tests to check append/grow works as expected, in terms of how the end
table looks like given the initial state and some different page patterns
added to it. And both crossing and not crossing into sg chaining scenarios.
This function is basic for all RDMA devices and we are pretty confident
that the old and new flows are tested thoroughly.
We will add proper test in next kernel cycle.
Patch seems to be adding a requirement that all callers of
(__)sg_alloc_table_from_pages pass in zeroed struct sg_table, which
wasn't the case so far.
Have you audited all the callers and/or fixed them? There seems to be
quite a few. Gut feel says problem would probably be better solved in
lib/scatterlist.c and not by making all the callers memset. Should be
possible if you make sure you only read st->nents if prev was passed in?
I've fixed the unit test and with this change the existing tests do
pass. But without zeroing it does fail on the very first, single page,
test scenario.
You can pull the unit test hacks from
git://people.freedesktop.org/~tursulin/drm-intel sgtest.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] dma-buf: Add struct dma-buf-map for storing struct dma_buf.vaddr_ptr
Hi
Am 23.09.20 um 16:27 schrieb Christian König:
> Am 23.09.20 um 14:32 schrieb Thomas Zimmermann:
>> The new type struct dma_buf_map represents a mapping of dma-buf memory
>> into kernel space. It contains a flag, is_iomem, that signals users to
>> access the mapped memory with I/O operations instead of regular loads
>> and stores.
>>
>> It was assumed that DMA buffer memory can be accessed with regular load
>> and store operations. Some architectures, such as sparc64, require the
>> use of I/O operations to access dma-map buffers that are located in I/O
>> memory. Providing struct dma_buf_map allows drivers to implement this.
>> This was specifically a problem when refreshing the graphics framebuffer
>> on such systems. [1]
>>
>> As the first step, struct dma_buf stores an instance of struct
>> dma_buf_map
>> internally. Afterwards, dma-buf's vmap and vunmap interfaces are be
>> converted. Finally, affected drivers can be fixed.
>>
>> [1]
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20200725191012.GA434957%40ravnborg.org%2Fdata=02%7C01%7Cchristian.koenig%40amd.com%7C54486b9682654f3950b808d85fbcb1d3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637364611338153209sdata=%2BZm7t8OcgkIxnY%2FdZSLhSbKC7t1y4VW5lINFKwCQv3A%3Dreserved=0
>>
>
> Only two nit picks below, apart from that Reviewed-by: Christian König
>
>
>>
>> Signed-off-by: Thomas Zimmermann
>> Acked-by: Sumit Semwal
>> ---
>> Documentation/driver-api/dma-buf.rst | 3 +
>> drivers/dma-buf/dma-buf.c | 14 ++---
>> include/linux/dma-buf-map.h | 87
>> include/linux/dma-buf.h | 3 +-
>> 4 files changed, 99 insertions(+), 8 deletions(-)
>> create mode 100644 include/linux/dma-buf-map.h
>>
>> diff --git a/Documentation/driver-api/dma-buf.rst
>> b/Documentation/driver-api/dma-buf.rst
>> index 13ea0cc0a3fa..3244c600a9a1 100644
>> --- a/Documentation/driver-api/dma-buf.rst
>> +++ b/Documentation/driver-api/dma-buf.rst
>> @@ -115,6 +115,9 @@ Kernel Functions and Structures Reference
>> .. kernel-doc:: include/linux/dma-buf.h
>> :internal:
>> +.. kernel-doc:: include/linux/dma-buf-map.h
>> + :internal:
>> +
>> Reservation Objects
>> ---
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index 58564d82a3a2..5e849ca241a0 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -1207,12 +1207,12 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
>> mutex_lock(>lock);
>> if (dmabuf->vmapping_counter) {
>> dmabuf->vmapping_counter++;
>> - BUG_ON(!dmabuf->vmap_ptr);
>> - ptr = dmabuf->vmap_ptr;
>> + BUG_ON(dma_buf_map_is_null(>vmap_ptr));
>> + ptr = dmabuf->vmap_ptr.vaddr;
>> goto out_unlock;
>> }
>> - BUG_ON(dmabuf->vmap_ptr);
>> + BUG_ON(dma_buf_map_is_set(>vmap_ptr));
>> ptr = dmabuf->ops->vmap(dmabuf);
>> if (WARN_ON_ONCE(IS_ERR(ptr)))
>> @@ -1220,7 +1220,7 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
>> if (!ptr)
>> goto out_unlock;
>> - dmabuf->vmap_ptr = ptr;
>> + dmabuf->vmap_ptr.vaddr = ptr;
>> dmabuf->vmapping_counter = 1;
>> out_unlock:
>> @@ -1239,15 +1239,15 @@ void dma_buf_vunmap(struct dma_buf *dmabuf,
>> void *vaddr)
>> if (WARN_ON(!dmabuf))
>> return;
>> - BUG_ON(!dmabuf->vmap_ptr);
>> + BUG_ON(dma_buf_map_is_null(>vmap_ptr));
>> BUG_ON(dmabuf->vmapping_counter == 0);
>> - BUG_ON(dmabuf->vmap_ptr != vaddr);
>> + BUG_ON(!dma_buf_map_is_vaddr(>vmap_ptr, vaddr));
>> mutex_lock(>lock);
>> if (--dmabuf->vmapping_counter == 0) {
>> if (dmabuf->ops->vunmap)
>> dmabuf->ops->vunmap(dmabuf, vaddr);
>> - dmabuf->vmap_ptr = NULL;
>> + dma_buf_map_clear(>vmap_ptr);
>> }
>> mutex_unlock(>lock);
>> }
>> diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
>> new file mode 100644
>> index ..d4b1bb3cc4b0
>> --- /dev/null
>> +++ b/include/linux/dma-buf-map.h
>> @@ -0,0 +1,87 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * Pointer to dma-buf-mapped memory, plus helpers.
>> + */
>> +
>> +#ifndef __DMA_BUF_MAP_H__
>> +#define __DMA_BUF_MAP_H__
>> +
>> +#include
>> +
>> +/**
>> + * struct dma_buf_map - Pointer to vmap'ed dma-buf memory.
>> + * @vaddr_iomem: The buffer's address if in I/O memory
>> + * @vaddr: The buffer's address if in system memory
>> + * @is_iomem: True if the dma-buf memory is located in I/O
>> + * memory, or false otherwise.
>> + *
>> + * Calling dma-buf's vmap operation returns a pointer to the buffer.
>> + * Depending on the location of the buffer, users may have to access it
>> + * with I/O operations or memory load/store operations. struct
>> dma_buf_map
>> + * stores the buffer address and a flag that signals the required
>> access.
>> + */
>>
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/atomic: document and enforce rules around "spurious" EBUSY
== Series Details ==
Series: series starting with [1/2] drm/atomic: document and enforce rules
around "spurious" EBUSY
URL : https://patchwork.freedesktop.org/series/82086/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9056 -> Patchwork_18570
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18570/index.html
Known issues
Here are the changes found in Patchwork_18570 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-apl-guc: [PASS][1] -> [DMESG-WARN][2] ([i915#1635] /
[i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-apl-guc/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18570/fi-apl-guc/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18570/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@vgem_basic@unload:
- fi-skl-guc: [PASS][5] -> [DMESG-WARN][6] ([i915#2203]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-skl-guc/igt@vgem_ba...@unload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18570/fi-skl-guc/igt@vgem_ba...@unload.html
Possible fixes
* igt@kms_busy@basic@flip:
- {fi-tgl-dsi}: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18570/fi-tgl-dsi/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10] +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18570/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18570/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
Warnings
* igt@i915_module_load@reload:
- fi-icl-u2: [DMESG-WARN][13] ([i915#289]) -> [DMESG-WARN][14]
([i915#1982] / [i915#289])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-icl-u2/igt@i915_module_l...@reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18570/fi-icl-u2/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [DMESG-WARN][15] ([i915#2203]) -> [DMESG-FAIL][16]
([i915#2203])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-kbl-guc/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18570/fi-kbl-guc/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92]) ->
[DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18570/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][20] ([i915#62] / [i915#92]) +4 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9056/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18570/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#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#289]: https://gitlab.freedesktop.org/drm/intel/issues/289
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]:
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_ctx_persistence: Exercise cleanup after disabling heartbeats
Quoting Chris Wilson (2020-08-13 00:33:00)
> We expose the heartbeat interval on each engine, allowing the sysadim to
> disable them if they prefer avoiding any interruption for their GPU
> tasks. A caveat to allowing the contexts to run without checks is that
> we require such contexts to be non-persistent and so cleaned up on
> closure (including abnormal process termination). However, we also need
> to flush any persistent contexts that are still inflight at that time,
> lest they continue to run unchecked.
>
> Signed-off-by: Chris Wilson
As mentioned on the kernel patches, the right thing to do.
Acked-by: Joonas Lahtinen
Regards, Joonas
> ---
> tests/i915/gem_ctx_persistence.c | 92
> 1 file changed, 92 insertions(+)
>
> diff --git a/tests/i915/gem_ctx_persistence.c
> b/tests/i915/gem_ctx_persistence.c
> index e73a3e6a0..ca676d845 100644
> --- a/tests/i915/gem_ctx_persistence.c
> +++ b/tests/i915/gem_ctx_persistence.c
> @@ -426,6 +426,87 @@ static void test_nohangcheck_hang(int i915)
> close(dir);
> }
>
> +static bool set_heartbeat(int i915, const char *name, unsigned int value)
> +{
> + return gem_engine_property_printf(i915, name,
> + "heartbeat_interval_ms",
> + "%d", value) > 0;
> +}
> +
> +static void test_noheartbeat_many(int i915, int count, unsigned int flags)
> +{
> + cleanup(i915);
> +
> + /*
> +* If the user disables the heartbeat, after leaving behind
> +* a number of long running *persistent* contexts, check they get
> +* cleaned up.
> +*/
> +
> + for_each_engine(e, i915) {
> + igt_spin_t *spin[count];
> +
> + if (!set_heartbeat(i915, e->full_name, 100))
> + continue;
> +
> + for (int n = 0; n < ARRAY_SIZE(spin); n++) {
> + uint32_t ctx;
> +
> + ctx = gem_context_create(i915);
> + spin[n] = igt_spin_new(i915, ctx, .engine =
> eb_ring(e),
> + .flags = (IGT_SPIN_FENCE_OUT |
> +flags));
> + gem_context_destroy(i915, ctx);
> + }
> +
> + if (set_heartbeat(i915, e->full_name, 0)) {
> + for (int n = 0; n < ARRAY_SIZE(spin); n++) {
> + igt_assert_eq(wait_for_status(i915,
> spin[n]->out_fence, reset_timeout_ms),
> + -EIO);
> + }
> + }
> +
> + for (int n = 0; n < ARRAY_SIZE(spin); n++)
> + igt_spin_free(i915, spin[n]);
> +
> + set_heartbeat(i915, e->full_name, 2500);
> + cleanup(i915);
> + }
> +}
> +
> +static void test_noheartbeat_close(int i915, unsigned int flags)
> +{
> + cleanup(i915);
> +
> + /*
> +* Check that non-persistent contexts are also cleaned up if we
> +* close the context while they are active, but the engine's
> +* heartbeat has already been disabled.
> +*/
> +
> + for_each_engine(e, i915) {
> + igt_spin_t *spin;
> + uint32_t ctx;
> +
> + if (!set_heartbeat(i915, e->full_name, 0))
> + continue;
> +
> + ctx = gem_context_create(i915);
> + gem_context_set_persistence(i915, ctx, false);
> + spin = igt_spin_new(i915, ctx, .engine = eb_ring(e),
> + .flags = (IGT_SPIN_FENCE_OUT | flags));
> + gem_context_destroy(i915, ctx);
> +
> + set_heartbeat(i915, e->full_name, 2500);
> +
> + igt_assert_eq(wait_for_status(i915, spin->out_fence,
> reset_timeout_ms),
> + -EIO);
> +
> + igt_spin_free(i915, spin);
> + cleanup(i915);
> + }
> +}
> +
> static void test_nonpersistent_file(int i915)
> {
> int debugfs = i915;
> @@ -1157,6 +1238,17 @@ igt_main
> igt_subtest("hang")
> test_nohangcheck_hang(i915);
>
> + igt_subtest("heartbeat-stop")
> + test_noheartbeat_many(i915, 1, 0);
> + igt_subtest("heartbeat-hang")
> + test_noheartbeat_many(i915, 1, IGT_SPIN_NO_PREEMPTION);
> + igt_subtest("heartbeat-many")
> + test_noheartbeat_many(i915, 16, 0);
> + igt_subtest("heartbeat-close")
> + test_noheartbeat_close(i915, 0);
> + igt_subtest("heartbeat-hostile")
> + test_noheartbeat_close(i915, IGT_SPIN_NO_PREEMPTION);
> +
> igt_subtest_group {
> igt_fixture
> gem_require_contexts(i915);
> --
> 2.28.0
>
> ___
> igt-dev mailing list
>
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Cancel outstanding work after disabling heartbeats on an engine
Quoting Chris Wilson (2020-09-16 12:42:17)
> We only allow persistent requests to remain on the GPU past the closure
> of their containing context (and process) so long as they are continuously
> checked for hangs or allow other requests to preempt them, as we need to
> ensure forward progress of the system. If we allow persistent contexts
> to remain on the system after the the hangcheck mechanism is disabled,
> the system may grind to a halt. On disabling the mechanism, we sent a
> pulse along the engine to remove all executing contexts from the engine
> which would check for hung contexts -- but we did not prevent those
> contexts from being resubmitted if they survived the final hangcheck.
>
> Fixes: 9a40bddd47ca ("drm/i915/gt: Expose heartbeat interval via sysfs")
> Testcase: igt/gem_ctx_persistence/heartbeat-stop
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: # v5.7+
Definitely makes sense to ensure.
Acked-by: Joonas Lahtinen
Regards, Joonas
> ---
> drivers/gpu/drm/i915/gt/intel_engine.h | 9 +
> drivers/gpu/drm/i915/i915_request.c| 5 +
> 2 files changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
> b/drivers/gpu/drm/i915/gt/intel_engine.h
> index 08e2c000dcc3..7c3a1012e702 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
> @@ -337,4 +337,13 @@ intel_engine_has_preempt_reset(const struct
> intel_engine_cs *engine)
> return intel_engine_has_preemption(engine);
> }
>
> +static inline bool
> +intel_engine_has_heartbeat(const struct intel_engine_cs *engine)
> +{
> + if (!IS_ACTIVE(CONFIG_DRM_I915_HEARTBEAT_INTERVAL))
> + return false;
> +
> + return READ_ONCE(engine->props.heartbeat_interval_ms);
> +}
> +
> #endif /* _INTEL_RINGBUFFER_H_ */
> diff --git a/drivers/gpu/drm/i915/i915_request.c
> b/drivers/gpu/drm/i915/i915_request.c
> index 436ce368ddaa..0e813819b041 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -542,8 +542,13 @@ bool __i915_request_submit(struct i915_request *request)
> if (i915_request_completed(request))
> goto xfer;
>
> + if (unlikely(intel_context_is_closed(request->context) &&
> +!intel_engine_has_heartbeat(engine)))
> + intel_context_set_banned(request->context);
> +
> if (unlikely(intel_context_is_banned(request->context)))
> i915_request_set_error_once(request, -EIO);
> +
> if (unlikely(fatal_error(request->fence.error)))
> __i915_request_skip(request);
>
> --
> 2.20.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Implement display WA #1142:kbl, cfl, cml
On Thu, Sep 24, 2020 at 08:43:33PM +, Souza, Jose wrote:
> On Thu, 2020-09-24 at 22:48 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä <
> > ville.syrj...@linux.intel.com
> > >
> >
> > Implement display w/a #1142. This supposedly fixes some underruns
> > with FBC+VTd. Bspec says we should use the same programming regardless
> > of circumstances. Apparently we should flip the magic bits before
> > turning on any planes so let's put this into the early w/as.
> >
> > Cc: Lee Shawn C <
> > shawn.c@intel.com
> > >
> > Signed-off-by: Ville Syrjälä <
> > ville.syrj...@linux.intel.com
> > >
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 9 +
> > drivers/gpu/drm/i915/i915_reg.h | 3 +++
> > 2 files changed, 12 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 5a9d933e425a..9d64187cfd56 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -18677,6 +18677,15 @@ static void intel_early_display_was(struct
> > drm_i915_private *dev_priv)
> > intel_de_write(dev_priv, CHICKEN_PAR1_1,
> >intel_de_read(dev_priv, CHICKEN_PAR1_1) |
> > FORCE_ARB_IDLE_PLANES);
> > }
> > +
> > + if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) ||
> > IS_COMETLAKE(dev_priv)) {
>
> WA mentions that it is required only for KBL, but if Lee says that this helps
> with his CML issues.
I think there's a note somewhere that says cfl+ are derived from the
last kbl, and I don't think there's are specific cfl/cml tags for w/as.
>
> Reviewed-by: José Roberto de Souza
Ta.
>
> > + /* Display WA #1142:kbl,cfl,cml */
> > + intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
> > +KBL_ARB_FILL_SPARE_22, KBL_ARB_FILL_SPARE_22);
> > + intel_de_rmw(dev_priv, CHICKEN_MISC_2,
> > +KBL_ARB_FILL_SPARE_13 | KBL_ARB_FILL_SPARE_14,
> > +KBL_ARB_FILL_SPARE_14);
> > + }
> > }
> >
> > static void ibx_sanitize_pch_hdmi_port(struct drm_i915_private *dev_priv,
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index d805d4da6181..3f97cc0fcbf1 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7865,6 +7865,7 @@ enum {
> > # define CHICKEN3_DGMG_DONE_FIX_DISABLE(1 << 2)
> >
> > #define CHICKEN_PAR1_1 _MMIO(0x42080)
> > +#define KBL_ARB_FILL_SPARE_22 REG_BIT(22)
> > #define DIS_RAM_BYPASS_PSR2_MAN_TRACK (1 << 16)
> > #define SKL_DE_COMPRESSED_HASH_MODE (1 << 15)
> > #define DPA_MASK_VBLANK_SRD (1 << 15)
> > @@ -7877,6 +7878,8 @@ enum {
> >
> > #define CHICKEN_MISC_2 _MMIO(0x42084)
> > #define CNL_COMP_PWR_DOWN (1 << 23)
> > +#define KBL_ARB_FILL_SPARE_14 REG_BIT(14)
> > +#define KBL_ARB_FILL_SPARE_13 REG_BIT(13)
> > #define GLK_CL2_PWR_DOWN (1 << 12)
> > #define GLK_CL1_PWR_DOWN (1 << 11)
> > #define GLK_CL0_PWR_DOWN (1 << 10)
> >
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/atomic: document and enforce rules around "spurious" EBUSY
== Series Details ==
Series: series starting with [1/2] drm/atomic: document and enforce rules
around "spurious" EBUSY
URL : https://patchwork.freedesktop.org/series/82086/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6e02c964a485 drm/atomic: document and enforce rules around "spurious" EBUSY
-:49: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#49:
References:
https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
-:76: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#76: FILE: drivers/gpu/drm/drm_atomic.c:1269:
+ unsigned requested_crtc = 0;
-:77: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#77: FILE: drivers/gpu/drm/drm_atomic.c:1270:
+ unsigned affected_crtc = 0;
-:114: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 4 warnings, 0 checks, 51 lines checked
caec65c608ae drm/atomic: debug output for EBUSY
-:33: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#33: FILE: drivers/gpu/drm/drm_atomic_helper.c:1741:
+ DRM_DEBUG_ATOMIC("[PLANE:%d:%s] inflight previous commit
preventing async commit\n",
+ plane->base.id, plane->name);
-:44: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#44: FILE: drivers/gpu/drm/drm_atomic_helper.c:1962:
+ DRM_DEBUG_ATOMIC("[CRTC:%d:%s] busy with a
previous commit\n",
+ crtc->base.id, crtc->name);
-:56: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#56: FILE: drivers/gpu/drm/drm_atomic_helper.c:2140:
+ DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] busy with a
previous commit\n",
+ conn->base.id, conn->name);
-:70: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#70: FILE: drivers/gpu/drm/drm_atomic_helper.c:2159:
+ DRM_DEBUG_ATOMIC("[PLANE:%d:%s] busy with a previous
commit\n",
+ plane->base.id, plane->name);
-:76: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 4 checks, 47 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/2] drm/i915: Redo "Remove i915_request.lock requirement for execution callbacks"
The reordering and rebasing of commit 2e4c6c1a9db5 ("drm/i915: Remove
i915_request.lock requirement for execution callbacks") caused it to
revert an earlier correction. Let us restore commit 99f0a640d464
("drm/i915: Remove requirement for holding i915_request.lock for
breadcrumbs")
Fixes: 2e4c6c1a9db5 ("drm/i915: Remove i915_request.lock requirement for
execution callbacks")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Rodrigo Vivi
Cc: Joonas Lahtinen
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 11e272422fb7..436ce368ddaa 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -593,16 +593,8 @@ bool __i915_request_submit(struct i915_request *request)
__notify_execute_cb_irq(request);
/* We may be recursing from the signal callback of another i915 fence */
- if (!i915_request_signaled(request)) {
- spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
-
- if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
->fence.flags) &&
- !i915_request_enable_breadcrumb(request))
- intel_engine_signal_breadcrumbs(engine);
-
- spin_unlock(>lock);
- }
+ if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
+ i915_request_enable_breadcrumb(request);
return result;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/2] drm/i915/gem: Hold request reference for canceling an active context
We have to be very careful while walking the timeline->requests list
under the RCU guard, as the requests (and so rq->link) use
SLAB_TYPESAFE_BY_RCU and so the requests may be reallocated within an
rcu grace period. As the requests are reallocated, they are removed from
one list and placed on another, and if we are iterating over that
request at that moment, the list iteration jumps from one list to the
next and promptly gets confused. Verify we hold the request reference
to ensure that the request is not added to a new list behind our backs.
<4> [582.745252] general protection fault, probably for non-canonical address
0xcd5c: [#1] PREEMPT SMP PTI
<4> [582.745297] CPU: 0 PID: 1475 Comm: gem_ctx_persist Not tainted
5.9.0-rc1-CI-CI_DRM_8908+ #1
<4> [582.745304] Hardware name: Intel Corporation NUC7CJYH/NUC7JYB, BIOS
JYGLKCPX.86A.0027.2018.0125.1347 01/25/2018
<4> [582.745317] RIP: 0010:__lock_acquire+0x2c3/0x1f40
<4> [582.745323] Code: 00 65 8b 05 c7 8a ef 7e 85 c0 0f 85 b4 07 00 00 44 8b 9d
c4 08 00 00 45 85 db 0f 84 0f 01 00 00 ba 05 00 00 00 e9 c8 06 00 00 <48> 81 3f
c0 89 c7 82 b8 00 00 00 00 41 0f 45 c0 83 fe 01 41 89 c3
<4> [582.745334] RSP: 0018:c9000461bc40 EFLAGS: 00010002
<4> [582.745340] RAX: RBX: 0001 RCX:
<4> [582.745345] RDX: RSI: RDI:
cd5c
<4> [582.745350] RBP: 8881ec4a2880 R08: 0001 R09:
0001
<4> [582.745356] R10: 0001 R11: 0001 R12:
<4> [582.745361] R13: R14: R15:
cd5c
<4> [582.745367] FS: 7fb44da78e40() GS:88827800()
knlGS:
<4> [582.745373] CS: 0010 DS: ES: CR0: 80050033
<4> [582.745378] CR2: 7fb44daad040 CR3: 000268428000 CR4:
00350ef0
<4> [582.745383] Call Trace:
<4> [582.745390] ? __lock_acquire+0x913/0x1f40
<4> [582.745397] lock_acquire+0xb5/0x3c0
<4> [582.745526] ? kill_engines+0x19a/0x4b0 [i915]
<4> [582.745533] ? find_held_lock+0x2d/0x90
<4> [582.745541] _raw_spin_lock_irq+0x30/0x40
<4> [582.745635] ? kill_engines+0x19a/0x4b0 [i915]
<4> [582.745727] kill_engines+0x19a/0x4b0 [i915]
<4> [582.745820] context_close+0x195/0x410 [i915]
<4> [582.745912] i915_gem_context_close+0x5b/0x160 [i915]
<4> [582.745994] i915_driver_postclose+0x14/0x40 [i915]
<4> [582.746003] drm_file_free.part.13+0x240/0x290
<4> [582.746009] drm_release_noglobal+0x16/0x50
<4> [582.746016] __fput+0xa5/0x250
<4> [582.746021] task_work_run+0x6e/0xb0
<4> [582.746028] exit_to_user_mode_prepare+0x178/0x180
<4> [582.746034] syscall_exit_to_user_mode+0x36/0x220
<4> [582.746040] entry_SYSCALL_64_after_hwframe+0x44/0xa9
<4> [582.746045] RIP: 0033:0x7fb44d1dc421
<4> [582.746050] Code: f7 d8 64 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00
00 00 00 00 66 90 8b 05 ea cf 20 00 85 c0 75 16 b8 03 00 00 00 0f 05 <48> 3d 00
f0 ff ff 77 3f f3 c3 0f 1f 44 00 00 53 89 fb 48 83 ec 10
<4> [582.746062] RSP: 002b:7ffed2e83818 EFLAGS: 0246 ORIG_RAX:
0003
<4> [582.746069] RAX: RBX: 556410bfe840 RCX:
7fb44d1dc421
<4> [582.746075] RDX: 000a RSI: c0406469 RDI:
0008
<4> [582.746080] RBP: 0008 R08: 7fb44d1c51cc R09:
7fb44d1c5240
<4> [582.746086] R10: 0001 R11: 0246 R12:
fffb
<4> [582.746091] R13: 0006 R14: R15:
000a
<4> [582.746099] Modules linked in: vgem mei_hdcp snd_hda_codec_hdmi
snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio btusb btrtl btbcm
btintel x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul bluetooth
ghash_clmulni_intel ecdh_generic ecc i915 r8169 realtek mei_me mei
snd_hda_intel i2c_hid snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core
snd_pcm pinctrl_geminilake pinctrl_intel prime_numbers [last unloaded:
test_drm_mm]
Fixes: 09a3054f38db ("drm/i915/gem: Reduce context termination list iteration
guard to RCU")
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 25 -
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index cf5ecbde9e06..a548626fa8bc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -460,8 +460,8 @@ __active_engine(struct i915_request *rq, struct
intel_engine_cs **active)
spin_lock(>active.lock);
}
- if (!i915_request_completed(rq)) {
- if (i915_request_is_active(rq) && rq->fence.error != -EIO)
+ if (i915_request_is_active(rq)) {
+ if (!i915_request_completed(rq))
*active = locked;
ret = true;
}
@@ -479,13 +479,26 @@ static struct
Re: [Intel-gfx] [PATCH 4/4] drm/i915/gem: Always test execution status on closing the context
Quoting Tvrtko Ursulin (2020-09-24 15:26:56)
>
> On 16/09/2020 10:42, Chris Wilson wrote:
> > Verify that if a context is active at the time it is closed, that it is
> > either persistent and preemptible (with hangcheck running) or it shall
> > be removed from execution.
> >
> > Fixes: 9a40bddd47ca ("drm/i915/gt: Expose heartbeat interval via sysfs")
> > Testcase: igt/gem_ctx_persistence/heartbeat-close
> > Signed-off-by: Chris Wilson
> > Cc: Joonas Lahtinen
> > Cc: # v5.7+
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 48 +
> > 1 file changed, 10 insertions(+), 38 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index a548626fa8bc..4fd38101bb56 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -390,24 +390,6 @@ __context_engines_static(const struct i915_gem_context
> > *ctx)
> > return rcu_dereference_protected(ctx->engines, true);
> > }
> >
> > -static bool __reset_engine(struct intel_engine_cs *engine)
> > -{
> > - struct intel_gt *gt = engine->gt;
> > - bool success = false;
> > -
> > - if (!intel_has_reset_engine(gt))
> > - return false;
> > -
> > - if (!test_and_set_bit(I915_RESET_ENGINE + engine->id,
> > - >reset.flags)) {
> > - success = intel_engine_reset(engine, NULL) == 0;
> > - clear_and_wake_up_bit(I915_RESET_ENGINE + engine->id,
> > - >reset.flags);
> > - }
> > -
> > - return success;
> > -}
> > -
> > static void __reset_context(struct i915_gem_context *ctx,
> > struct intel_engine_cs *engine)
> > {
> > @@ -431,12 +413,7 @@ static bool __cancel_engine(struct intel_engine_cs
> > *engine)
> >* kill the banned context, we fallback to doing a local reset
> >* instead.
> >*/
> > - if (IS_ACTIVE(CONFIG_DRM_I915_PREEMPT_TIMEOUT) &&
> > - !intel_engine_pulse(engine))
> > - return true;
> > -
> > - /* If we are unable to send a pulse, try resetting this engine. */
> > - return __reset_engine(engine);
> > + return intel_engine_pulse(engine) == 0;
>
> Where is the path now which actually resets the currently running
> workload (engine) of a non-persistent context? Pulse will be sent and
> then rely on hangcheck but otherwise let it run?
If the pulse fails, we just call intel_handle_error() on the engine. On
looking at this code again, I could not justify the open-coding of the
engine reset fragment of the general error handler, especially as we end
up taking that route anyway for device resets. (Unlike inside the
tasklet, there's no atomicity concerns on this engine-reset path.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/gt: Always send a pulse down the engine after disabling heartbeat
Quoting Tvrtko Ursulin (2020-09-24 14:43:08)
>
> On 16/09/2020 10:42, Chris Wilson wrote:
> > Currently, we check we can send a pulse prior to disabling the
> > heartbeat to verify that we can change the heartbeat, but since we may
> > re-evaluate execution upon changing the heartbeat interval we need another
> > pulse afterwards to refresh execution.
> >
> > Fixes: 9a40bddd47ca ("drm/i915/gt: Expose heartbeat interval via sysfs")
> > Signed-off-by: Chris Wilson
> > Cc: Joonas Lahtinen
> > Cc: # v5.7+
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> > index 8ffdf676c0a0..d09df370f7cd 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> > @@ -192,10 +192,12 @@ int intel_engine_set_heartbeat(struct intel_engine_cs
> > *engine,
> > WRITE_ONCE(engine->props.heartbeat_interval_ms, delay);
> >
> > if (intel_engine_pm_get_if_awake(engine)) {
> > - if (delay)
> > + if (delay) {
> > intel_engine_unpark_heartbeat(engine);
> > - else
> > + } else {
> > intel_engine_park_heartbeat(engine);
> > + intel_engine_pulse(engine); /* recheck execution */
> > + }
> > intel_engine_pm_put(engine);
> > }
> >
> >
>
> I did not immediately get this one. Do we really need two pulses or
> maybe we could re-order the code a bit and just undo the heartbeat park
> if pulse after parking did not work?
We use the first pulse to determine if it's legal for the parameter to
be changed (checking we support the preemptive pulse to remove
non-persistent contexts). Then the second pulse after changing the
parameter to flush the changes through.
I like checking for support before making the change, although we could
try and fixup after failure, there would still be a window where the
change would be visible to the system. We don't need to use the pulse per
se for that check, that's pure convenience as it performs the checking
already.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib: Only avoid relocations with full-ppgtt
On Fri, Sep 25, 2020 at 09:41:48AM +0100, Chris Wilson wrote:
> We can only assigned random addresses with impunity if we know we have
> complete control over the ppGTT. If the ppGTT is shared, either aliased
> with the global GTT or simply the global GTT on ancient HW, then we have
> to be careful in case they are objects already fixed in place inside the
> GTT, e.g. active framebuffers. As the relocation code is still
> available, only enforce no-relocations by default when the context has
> its own ppGTT.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2491
> Signed-off-by: Chris Wilson
> Cc: Zbigniew Kempczyński
> ---
> lib/intel_batchbuffer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/intel_batchbuffer.c b/lib/intel_batchbuffer.c
> index be764646e..42d7cd251 100644
> --- a/lib/intel_batchbuffer.c
> +++ b/lib/intel_batchbuffer.c
> @@ -1306,7 +1306,7 @@ __intel_bb_create(int i915, uint32_t size, bool
> do_relocs)
> */
> struct intel_bb *intel_bb_create(int i915, uint32_t size)
> {
> - return __intel_bb_create(i915, size, false);
> + return __intel_bb_create(i915, size, !gem_uses_full_ppgtt(i915));
> }
>
> /**
> --
> 2.28.0
If we won't enforce EXEC_OBJECT_PINNED and set I915_EXEC_NO_RELOC for execbuf
still driver will try to use offsets configured in the objects array? I thought
NO_RELOC + !PINNED will relocate not properly configured objects but I'm likely
wrong. I don't have much experience with !ppgtt tables but if they are shared
I guess we can rely on kernel relocations only. So
Reviewed-by: Zbigniew Kempczyński
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/atomic: debug output for EBUSY
On Fri, 25 Sep 2020 10:46:51 +0200 Daniel Vetter wrote: > Hopefully we'll have the drm crash recorder RSN, but meanwhile > compositors would like to know a bit better why they get an EBUSY. > > v2: Move misplaced hunk to the right patch (Pekka) Hi, both patches Acked-by: Pekka Paalanen Thanks, pq pgp41lRbzLA_Y.pgp Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/atomic: debug output for EBUSY
Hopefully we'll have the drm crash recorder RSN, but meanwhile
compositors would like to know a bit better why they get an EBUSY.
v2: Move misplaced hunk to the right patch (Pekka)
Cc: Sean Paul
Cc: Daniel Stone
Cc: Pekka Paalanen
Cc: Simon Ser
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index e8ab7fd1..6b3bfabac26c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1740,8 +1740,11 @@ int drm_atomic_helper_async_check(struct drm_device *dev,
* overridden by a previous synchronous update's state.
*/
if (old_plane_state->commit &&
- !try_wait_for_completion(_plane_state->commit->hw_done))
+ !try_wait_for_completion(_plane_state->commit->hw_done)) {
+ DRM_DEBUG_ATOMIC("[PLANE:%d:%s] inflight previous commit
preventing async commit\n",
+ plane->base.id, plane->name);
return -EBUSY;
+ }
return funcs->atomic_async_check(plane, new_plane_state);
}
@@ -1964,6 +1967,9 @@ static int stall_checks(struct drm_crtc *crtc, bool
nonblock)
* commit with nonblocking ones. */
if (!completed && nonblock) {
spin_unlock(>commit_lock);
+ DRM_DEBUG_ATOMIC("[CRTC:%d:%s] busy with a
previous commit\n",
+ crtc->base.id, crtc->name);
+
return -EBUSY;
}
} else if (i == 1) {
@@ -2132,8 +2138,12 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
/* Userspace is not allowed to get ahead of the previous
* commit with nonblocking ones. */
if (nonblock && old_conn_state->commit &&
-
!try_wait_for_completion(_conn_state->commit->flip_done))
+
!try_wait_for_completion(_conn_state->commit->flip_done)) {
+ DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] busy with a
previous commit\n",
+ conn->base.id, conn->name);
+
return -EBUSY;
+ }
/* Always track connectors explicitly for e.g. link retraining.
*/
commit = crtc_or_fake_commit(state, new_conn_state->crtc ?:
old_conn_state->crtc);
@@ -2147,8 +2157,12 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
/* Userspace is not allowed to get ahead of the previous
* commit with nonblocking ones. */
if (nonblock && old_plane_state->commit &&
-
!try_wait_for_completion(_plane_state->commit->flip_done))
+
!try_wait_for_completion(_plane_state->commit->flip_done)) {
+ DRM_DEBUG_ATOMIC("[PLANE:%d:%s] busy with a previous
commit\n",
+ plane->base.id, plane->name);
+
return -EBUSY;
+ }
/* Always track planes explicitly for async pageflip support. */
commit = crtc_or_fake_commit(state, new_plane_state->crtc ?:
old_plane_state->crtc);
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/atomic: document and enforce rules around "spurious" EBUSY
When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
pull in arbitrary other resources, including CRTCs (e.g. when
reconfiguring global resources).
But in nonblocking mode userspace has then no idea this happened,
which can lead to spurious EBUSY calls, both:
- when that other CRTC is currently busy doing a page_flip the
ALLOW_MODESET commit can fail with an EBUSY
- on the other CRTC a normal atomic flip can fail with EBUSY because
of the additional commit inserted by the kernel without userspace's
knowledge
For blocking commits this isn't a problem, because everyone else will
just block until all the CRTC are reconfigured. Only thing userspace
can notice is the dropped frames without any reason for why frames got
dropped.
Consensus is that we need new uapi to handle this properly, but no one
has any idea what exactly the new uapi should look like. Since this
has been shipping for years already compositors need to deal no matter
what, so as a first step just try to enforce this across drivers
better with some checks.
v2: Add comments and a WARN_ON to enforce this only when allowed - we
don't want to silently convert page flips into blocking plane updates
just because the driver is buggy.
v3: Fix inverted WARN_ON (Pekka).
v4: Drop the uapi changes, only add a WARN_ON for now to enforce some
rules for drivers.
v5: Make the WARNING more informative (Daniel)
v6: Add unconditional debug output for compositor hackers to figure
out what's going on when they get an EBUSY (Daniel)
v7: Fix up old/new_crtc_state confusion for real (Pekka/Ville)
References:
https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
Cc: Daniel Stone
Cc: Pekka Paalanen
Cc: Simon Ser
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 58527f151984..aac9122f1da2 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, new_crtc_state, i)
+ requested_crtc |= drm_crtc_mask(crtc);
+
for_each_oldnew_plane_in_state(state, plane, old_plane_state,
new_plane_state, i) {
ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
if (ret) {
@@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
}
}
+ for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
+ affected_crtc |= drm_crtc_mask(crtc);
+
+ /*
+* For commits that allow modesets drivers can add other CRTCs to the
+* atomic commit, e.g. when they need to reallocate global resources.
+* This can cause spurious EBUSY, which robs compositors of a very
+* effective sanity check for their drawing loop. Therefor only allow
+* drivers to add unrelated CRTC states for modeset commits.
+*
+* FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an output
+* so compositors know what's going on.
+*/
+ if (affected_crtc != requested_crtc) {
+ DRM_DEBUG_ATOMIC("driver added CRTC to commit: requested 0x%x,
affected 0x%0x\n",
+requested_crtc, affected_crtc);
+ WARN(!state->allow_modeset, "adding CRTC not allowed without
modesets: requested 0x%x, affected 0x%0x\n",
+requested_crtc, affected_crtc);
+ }
+
return 0;
}
EXPORT_SYMBOL(drm_atomic_check_only);
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY
On Fri, Sep 25, 2020 at 11:24:46AM +0300, Pekka Paalanen wrote:
> On Wed, 23 Sep 2020 17:18:52 +0200
> Daniel Vetter wrote:
>
> > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > pull in arbitrary other resources, including CRTCs (e.g. when
> > reconfiguring global resources).
> >
> > But in nonblocking mode userspace has then no idea this happened,
> > which can lead to spurious EBUSY calls, both:
> > - when that other CRTC is currently busy doing a page_flip the
> > ALLOW_MODESET commit can fail with an EBUSY
> > - on the other CRTC a normal atomic flip can fail with EBUSY because
> > of the additional commit inserted by the kernel without userspace's
> > knowledge
> >
> > For blocking commits this isn't a problem, because everyone else will
> > just block until all the CRTC are reconfigured. Only thing userspace
> > can notice is the dropped frames without any reason for why frames got
> > dropped.
> >
> > Consensus is that we need new uapi to handle this properly, but no one
> > has any idea what exactly the new uapi should look like. Since this
> > has been shipping for years already compositors need to deal no matter
> > what, so as a first step just try to enforce this across drivers
> > better with some checks.
> >
> > v2: Add comments and a WARN_ON to enforce this only when allowed - we
> > don't want to silently convert page flips into blocking plane updates
> > just because the driver is buggy.
> >
> > v3: Fix inverted WARN_ON (Pekka).
> >
> > v4: Drop the uapi changes, only add a WARN_ON for now to enforce some
> > rules for drivers.
> >
> > v5: Make the WARNING more informative (Daniel)
> >
> > v6: Add unconditional debug output for compositor hackers to figure
> > out what's going on when they get an EBUSY (Daniel)
>
> ... gmail workaround ...
>
> > ---
> > drivers/gpu/drm/drm_atomic.c | 29 +
> > 1 file changed, 29 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 58527f151984..f1a912e80846 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -281,6 +281,10 @@ EXPORT_SYMBOL(__drm_atomic_state_free);
> > * needed. It will also grab the relevant CRTC lock to make sure that the
> > state
> > * is consistent.
> > *
> > + * WARNING: Drivers may only add new CRTC states to a @state if
> > + * drm_atomic_state.allow_modeset is set, or if it's a driver-internal
> > commit
> > + * not created by userspace through an IOCTL call.
> > + *
> > * Returns:
> > *
> > * Either the allocated state or the error code encoded into the pointer.
> > When
> > @@ -1262,10 +1266,15 @@ int drm_atomic_check_only(struct drm_atomic_state
> > *state)
> > struct drm_crtc_state *new_crtc_state;
> > struct drm_connector *conn;
> > struct drm_connector_state *conn_state;
> > + unsigned requested_crtc = 0;
> > + unsigned affected_crtc = 0;
> > int i, ret = 0;
> >
> > DRM_DEBUG_ATOMIC("checking %p\n", state);
> >
> > + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> > + requested_crtc |= drm_crtc_mask(crtc);
>
> Is "old crtc state" the state that userspace is requesting as the new
> state?
It's a dummy iterator variable we don't care about, all we really want is
to know which crtc are all part of the update. But everyone else also
wants the state.
I'll shuffle the patches so the hunk Ville requested is in the right
patch.
-Daniel
>
> > +
> > for_each_oldnew_plane_in_state(state, plane, old_plane_state,
> > new_plane_state, i) {
> > ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
> > if (ret) {
> > @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state
> > *state)
> > }
> > }
> >
> > + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> > + affected_crtc |= drm_crtc_mask(crtc);
>
> And after driver check processing, the "old crtc state" has been
> modified by the driver to add anything it will necessarily need like
> other CRTCs?
>
> What is "new state" then?
>
> > +
> > + /*
> > +* For commits that allow modesets drivers can add other CRTCs to the
> > +* atomic commit, e.g. when they need to reallocate global resources.
> > +* This can cause spurious EBUSY, which robs compositors of a very
> > +* effective sanity check for their drawing loop. Therefor only allow
> > +* drivers to add unrelated CRTC states for modeset commits.
> > +*
> > +* FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an output
> > +* so compositors know what's going on.
> > +*/
> > + if (affected_crtc != requested_crtc) {
> > + DRM_DEBUG_ATOMIC("driver added CRTC to commit: requested 0x%x,
> > affected 0x%0x\n",
> > +requested_crtc, affected_crtc);
> > + WARN(!state->allow_modeset, "adding CRTC not allowed without
>
[Intel-gfx] [PATCH i-g-t] lib: Only avoid relocations with full-ppgtt
We can only assigned random addresses with impunity if we know we have
complete control over the ppGTT. If the ppGTT is shared, either aliased
with the global GTT or simply the global GTT on ancient HW, then we have
to be careful in case they are objects already fixed in place inside the
GTT, e.g. active framebuffers. As the relocation code is still
available, only enforce no-relocations by default when the context has
its own ppGTT.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2491
Signed-off-by: Chris Wilson
Cc: Zbigniew Kempczyński
---
lib/intel_batchbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/intel_batchbuffer.c b/lib/intel_batchbuffer.c
index be764646e..42d7cd251 100644
--- a/lib/intel_batchbuffer.c
+++ b/lib/intel_batchbuffer.c
@@ -1306,7 +1306,7 @@ __intel_bb_create(int i915, uint32_t size, bool do_relocs)
*/
struct intel_bb *intel_bb_create(int i915, uint32_t size)
{
- return __intel_bb_create(i915, size, false);
+ return __intel_bb_create(i915, size, !gem_uses_full_ppgtt(i915));
}
/**
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
