Re: [Intel-gfx] [PATCH][next] drm/i915/hdcp: Fix null pointer dereference of connector->encoder
> -Original Message-
> From: Colin King
> Sent: Wednesday, February 24, 2021 12:49 AM
> To: Jani Nikula ; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> David Airlie ; Daniel Vetter ; C,
> Ramalingam
> ; Gupta, Anshuman ;
> intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: kernel-janit...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: [PATCH][next] drm/i915/hdcp: Fix null pointer dereference of
> connector->encoder
>
> From: Colin Ian King
>
> The recent commit 6c63e6e14da7 ("drm/i915/hdcp: No HDCP when encoder is't
> initialized") added a null pointer check on connector->encoder hence implying
> that it could potentially be null. This means that the initialization of
> dig_port via
> the call intel_attached_dig_port may cause a null pointer dereference on
> connector->encoder. Fix this by only assigning dig_port after a null check has
> been performed on connector->encoder.
>
> Addresses-Coverity: ("Dereference before null check")
> Fixes: 36e5e7042b20 ("drm/i915: Don't fully disable HDCP on a port if multiple
> pipes are using it")
> Signed-off-by: Colin Ian King
Looks good to me.
Reviewed-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/display/intel_hdcp.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index ae1371c36a32..7525ea31766c 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -2260,7 +2260,7 @@ int intel_hdcp_enable(struct intel_connector
> *connector,
> const struct intel_crtc_state *pipe_config, u8
> content_type)
> {
> struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> - struct intel_digital_port *dig_port =
> intel_attached_dig_port(connector);
> + struct intel_digital_port *dig_port;
> struct intel_hdcp *hdcp = >hdcp;
> unsigned long check_link_interval = DRM_HDCP_CHECK_PERIOD_MS;
> int ret = -EINVAL;
> @@ -2274,6 +2274,7 @@ int intel_hdcp_enable(struct intel_connector
> *connector,
> return -ENODEV;
> }
>
> + dig_port = intel_attached_dig_port(connector);
> mutex_lock(>mutex);
> mutex_lock(_port->hdcp_mutex);
> drm_WARN_ON(_priv->drm,
> --
> 2.30.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] dma-buf: Require VM_PFNMAP vma for mmap
On Tue, Feb 23, 2021 at 3:00 AM Daniel Vetter wrote: > > tldr; DMA buffers aren't normal memory, expecting that you can use > them like that (like calling get_user_pages works, or that they're > accounting like any other normal memory) cannot be guaranteed. > > Since some userspace only runs on integrated devices, where all > buffers are actually all resident system memory, there's a huge > temptation to assume that a struct page is always present and useable > like for any more pagecache backed mmap. This has the potential to > result in a uapi nightmare. > > To stop this gap require that DMA buffer mmaps are VM_PFNMAP, which > blocks get_user_pages and all the other struct page based > infrastructure for everyone. In spirit this is the uapi counterpart to > the kernel-internal CONFIG_DMABUF_DEBUG. > > Motivated by a recent patch which wanted to swich the system dma-buf > heap to vm_insert_page instead of vm_insert_pfn. > > v2: > > Jason brought up that we also want to guarantee that all ptes have the > pte_special flag set, to catch fast get_user_pages (on architectures > that support this). Allowing VM_MIXEDMAP (like VM_SPECIAL does) would > still allow vm_insert_page, but limiting to VM_PFNMAP will catch that. > > From auditing the various functions to insert pfn pte entires > (vm_insert_pfn_prot, remap_pfn_range and all it's callers like > dma_mmap_wc) it looks like VM_PFNMAP is already required anyway, so > this should be the correct flag to check for. > > References: > https://lore.kernel.org/lkml/cakmk7uhi+mg0z0humnt13qccvuturvjpcr0njrl12k-wbwz...@mail.gmail.com/ > Acked-by: Christian König > Cc: Jason Gunthorpe > Cc: Suren Baghdasaryan > Cc: Matthew Wilcox > Cc: John Stultz > Signed-off-by: Daniel Vetter > Cc: Sumit Semwal > Cc: "Christian König" > Cc: linux-me...@vger.kernel.org > Cc: linaro-mm-...@lists.linaro.org > --- > drivers/dma-buf/dma-buf.c | 15 +-- > 1 file changed, 13 insertions(+), 2 deletions(-) So I gave this a spin in a few of my environments, and with the current dmabuf heaps it spews a lot of warnings. I'm testing some simple fixes to add: vma->vm_flags |= VM_PFNMAP; to the dmabuf heap mmap ops, which we might want to queue along side of this. So assuming those can land together. Acked-by: John Stultz thanks -john ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/uc: Use platform specific defaults for GuC/HuC enabling (rev3)
== Series Details == Series: drm/i915/uc: Use platform specific defaults for GuC/HuC enabling (rev3) URL : https://patchwork.freedesktop.org/series/86100/ State : success == Summary == CI Bug Log - changes from CI_DRM_9809_full -> Patchwork_19730_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_19730_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19730_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_19730_full: ### IGT changes ### Warnings * igt@runner@aborted: - shard-kbl: ([FAIL][1], [FAIL][2], [FAIL][3], [FAIL][4], [FAIL][5], [FAIL][6]) ([i915#1436] / [i915#180] / [i915#1814] / [i915#3002]) -> ([FAIL][7], [FAIL][8], [FAIL][9], [FAIL][10], [FAIL][11]) ([i915#180] / [i915#2505] / [i915#2724] / [i915#3002]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9809/shard-kbl3/igt@run...@aborted.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9809/shard-kbl7/igt@run...@aborted.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9809/shard-kbl7/igt@run...@aborted.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9809/shard-kbl7/igt@run...@aborted.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9809/shard-kbl2/igt@run...@aborted.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9809/shard-kbl7/igt@run...@aborted.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19730/shard-kbl7/igt@run...@aborted.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19730/shard-kbl7/igt@run...@aborted.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19730/shard-kbl6/igt@run...@aborted.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19730/shard-kbl3/igt@run...@aborted.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19730/shard-kbl1/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_19730_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-snb: NOTRUN -> [DMESG-WARN][12] ([i915#3002]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19730/shard-snb2/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@engines-mixed: - shard-snb: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#1099]) +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19730/shard-snb5/igt@gem_ctx_persiste...@engines-mixed.html * igt@gem_ctx_shared@q-in-order: - shard-snb: NOTRUN -> [SKIP][14] ([fdo#109271]) +344 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19730/shard-snb5/igt@gem_ctx_sha...@q-in-order.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][15] -> [TIMEOUT][16] ([i915#3063]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9809/shard-tglb2/igt@gem_...@unwedge-stress.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19730/shard-tglb2/igt@gem_...@unwedge-stress.html * igt@gem_exec_balancer@hang: - shard-iclb: [PASS][17] -> [INCOMPLETE][18] ([i915#1895] / [i915#3031]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9809/shard-iclb3/igt@gem_exec_balan...@hang.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19730/shard-iclb2/igt@gem_exec_balan...@hang.html * igt@gem_exec_fair@basic-deadline: - shard-apl: NOTRUN -> [FAIL][19] ([i915#2846]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19730/shard-apl3/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][20] ([i915#2842]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19730/shard-iclb2/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-none@vecs0: - shard-kbl: [PASS][21] -> [FAIL][22] ([i915#2842]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9809/shard-kbl7/igt@gem_exec_fair@basic-n...@vecs0.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19730/shard-kbl7/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-kbl: NOTRUN -> [FAIL][23] ([i915#2842]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19730/shard-kbl1/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][24] ([i915#2389]) +1 similar issue [24]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/uc: Use platform specific defaults for GuC/HuC enabling (rev3)
== Series Details == Series: drm/i915/uc: Use platform specific defaults for GuC/HuC enabling (rev3) URL : https://patchwork.freedesktop.org/series/86100/ State : success == Summary == CI Bug Log - changes from CI_DRM_9809 -> Patchwork_19730 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19730/index.html Known issues Here are the changes found in Patchwork_19730 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@userptr: - fi-byt-j1900: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19730/fi-byt-j1900/igt@amdgpu/amd_ba...@userptr.html * igt@gem_linear_blits@basic: - fi-kbl-8809g: [PASS][2] -> [TIMEOUT][3] ([i915#2502]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9809/fi-kbl-8809g/igt@gem_linear_bl...@basic.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19730/fi-kbl-8809g/igt@gem_linear_bl...@basic.html * igt@i915_selftest@live@execlists: - fi-bsw-nick:[PASS][4] -> [INCOMPLETE][5] ([i915#2940]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9809/fi-bsw-nick/igt@i915_selftest@l...@execlists.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19730/fi-bsw-nick/igt@i915_selftest@l...@execlists.html * igt@prime_self_import@basic-with_one_bo_two_files: - fi-tgl-y: [PASS][6] -> [DMESG-WARN][7] ([i915#402]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9809/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19730/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html * igt@runner@aborted: - fi-bsw-nick:NOTRUN -> [FAIL][8] ([i915#1436]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19730/fi-bsw-nick/igt@run...@aborted.html - fi-bdw-5557u: NOTRUN -> [FAIL][9] ([i915#1602] / [i915#2029] / [i915#2369]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19730/fi-bdw-5557u/igt@run...@aborted.html Possible fixes * igt@i915_pm_rpm@module-reload: - fi-byt-j1900: [INCOMPLETE][10] ([i915#142] / [i915#2405]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9809/fi-byt-j1900/igt@i915_pm_...@module-reload.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19730/fi-byt-j1900/igt@i915_pm_...@module-reload.html * igt@prime_self_import@basic-with_one_bo: - fi-tgl-y: [DMESG-WARN][12] ([i915#402]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9809/fi-tgl-y/igt@prime_self_import@basic-with_one_bo.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19730/fi-tgl-y/igt@prime_self_import@basic-with_one_bo.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#142]: https://gitlab.freedesktop.org/drm/intel/issues/142 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602 [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029 [i915#2369]: https://gitlab.freedesktop.org/drm/intel/issues/2369 [i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405 [i915#2502]: https://gitlab.freedesktop.org/drm/intel/issues/2502 [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (41 -> 36) -- Missing(5): fi-kbl-soraka fi-ilk-m540 fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_9809 -> Patchwork_19730 CI-20190529: 20190529 CI_DRM_9809: 93b382e7eb2063e860d913775cecd9208e25ee0b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6015: aa44cddf4ef689f8a3726fcbeedc03f08b12bd82 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19730: de9e826a5cc3c18b97147870404176c0e2e88d66 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == de9e826a5cc3 drm/i915/uc: Use platform specific defaults for GuC/HuC enabling == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19730/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/uc: Use platform specific defaults for GuC/HuC enabling
From: John Harrison The meaning of 'default' for the enable_guc module parameter has been updated to accurately reflect what is supported on current platforms. So start using the defaults instead of forcing everything off. Although, note that right now, the default is for everything to be off anyway. So this is not a change for current platforms. Signed-off-by: John Harrison Reviewed-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/i915_params.c | 2 +- drivers/gpu/drm/i915/i915_params.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index 6939634e56ed..ec1561f5b051 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c @@ -160,7 +160,7 @@ i915_param_named_unsafe(edp_vswing, int, 0400, i915_param_named_unsafe(enable_guc, int, 0400, "Enable GuC load for GuC submission and/or HuC load. " "Required functionality can be selected using bitmask values. " - "(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)"); + "(-1=auto [default], 0=disable, 1=GuC submission, 2=HuC load)"); i915_param_named(guc_log_level, int, 0400, "GuC firmware logging level. Requires GuC to be loaded. " diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 48f47e44e848..8c485595dca2 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -59,7 +59,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] ✓ Fi.CI.IGT: success for drm/i915: Move DDI clock readout to encoder->get_config() (rev2)
== Series Details == Series: drm/i915: Move DDI clock readout to encoder->get_config() (rev2) URL : https://patchwork.freedesktop.org/series/87351/ State : success == Summary == CI Bug Log - changes from CI_DRM_9804_full -> Patchwork_19729_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_19729_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19729_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_19729_full: ### IGT changes ### Warnings * igt@runner@aborted: - shard-kbl: ([FAIL][1], [FAIL][2], [FAIL][3], [FAIL][4]) ([i915#180] / [i915#2724] / [i915#3002]) -> ([FAIL][5], [FAIL][6], [FAIL][7], [FAIL][8], [FAIL][9], [FAIL][10], [FAIL][11]) ([i915#1436] / [i915#180] / [i915#1814] / [i915#3002]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9804/shard-kbl3/igt@run...@aborted.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9804/shard-kbl2/igt@run...@aborted.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9804/shard-kbl2/igt@run...@aborted.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9804/shard-kbl7/igt@run...@aborted.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/shard-kbl7/igt@run...@aborted.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/shard-kbl7/igt@run...@aborted.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/shard-kbl2/igt@run...@aborted.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/shard-kbl7/igt@run...@aborted.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/shard-kbl4/igt@run...@aborted.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/shard-kbl7/igt@run...@aborted.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/shard-kbl7/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_19729_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@idempotent: - shard-snb: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#1099]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/shard-snb2/igt@gem_ctx_persiste...@idempotent.html * igt@gem_exec_balancer@hang: - shard-iclb: [PASS][13] -> [INCOMPLETE][14] ([i915#1895]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9804/shard-iclb7/igt@gem_exec_balan...@hang.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/shard-iclb4/igt@gem_exec_balan...@hang.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][15] -> [FAIL][16] ([i915#2842]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9804/shard-tglb5/igt@gem_exec_fair@basic-f...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/shard-tglb3/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-iclb: [PASS][17] -> [FAIL][18] ([i915#2842]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9804/shard-iclb7/igt@gem_exec_fair@basic-n...@vcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][19] ([i915#2842]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][20] -> [FAIL][21] ([i915#2842]) +1 similar issue [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9804/shard-kbl3/igt@gem_exec_fair@basic-p...@rcs0.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-kbl: [PASS][22] -> [SKIP][23] ([fdo#109271]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9804/shard-kbl3/igt@gem_exec_fair@basic-p...@vecs0.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][24] -> [FAIL][25] ([i915#2842]) +2 similar issues [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9804/shard-glk7/igt@gem_exec_fair@basic-throt...@rcs0.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/shard-glk6/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_schedule@u-fairslice@vcs1: - shard-tglb: [PASS][26] -> [DMESG-WARN][27]
Re: [Intel-gfx] udldrm does not recover from powersave? Re: udldrmfb: causes WARN in i915 on X60 (x86-32)
Hi! > > > > This is in -next, but I get same behaviour on 5.11; and no, udl does > > > > > > Thanks for reporting. We are in the process of fixing the issue. The > > > latest > > > patch is at [1]. > > > > > > > Thank you, that fixes the DMA issue, and I can use the udl. > > > > ...for a while. Then screensaver blanks laptop screen, udl screen > > blanks too. Upon hitting a key, internal screen shows up, udl does > > not. > > > > I try rerunning xrandr ... --auto, but could not recover it. > > > > Any ideas? > > Did it work before the regression? > > For testing, could you please remove the fix and then do > > git revert 6eb0233ec2d0 > > This would restore the old version. Please report back on the > results. Ok, I went to 7f206cf3ec2b with 6eb0233ec2d0 reverted. That fails to build: drivers/usb/core/message.c: In function ‘usb_set_configuration’: drivers/usb/core/message.c:2100:12: error: ‘struct device’ has no member named ‘dma_pfn_offset’ 2100 | intf->dev.dma_pfn_offset = dev->dev.dma_pfn_offset; |^ drivers/usb/core/message.c:2100:38: error: ‘struct device’ has no member named ‘dma_pfn_offset’ 2100 | intf->dev.dma_pfn_offset = dev->dev.dma_pfn_offset; | ^ CC drivers/net/ethernet/intel/e1000e/param.o make[3]: *** [scripts/Makefile.build:271: drivers/usb/core/message.o] Error 1 So I tried to go to bad commit's parent: git checkout 6eb0233ec2d0^ git log commit cf141ae989e2ff119cd320326da5923b480d1641 ARM/keystone: move the DMA offset handling under ifdef CONFIG_ARM_LPAE But that resulted in lockup soon after "--setprovidersource" command was isued. Best regards, Pavel -- http://www.livejournal.com/~pavelmachek signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Move DDI clock readout to encoder->get_config() (rev2)
== Series Details ==
Series: drm/i915: Move DDI clock readout to encoder->get_config() (rev2)
URL : https://patchwork.freedesktop.org/series/87351/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9804 -> Patchwork_19729
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/index.html
Known issues
Here are the changes found in Patchwork_19729 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@sync-compute0:
- fi-kbl-r: NOTRUN -> [SKIP][1] ([fdo#109271]) +20 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/fi-kbl-r/igt@amdgpu/amd_cs_...@sync-compute0.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-r: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/fi-kbl-r/igt@gem_huc_c...@huc-copy.html
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [PASS][3] -> [INCOMPLETE][4] ([i915#142] /
[i915#2405])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9804/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/fi-byt-j1900/igt@i915_pm_...@module-reload.html
* igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-r: NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/fi-kbl-r/igt@kms_chamel...@hdmi-edid-read.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-r: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#533])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/fi-kbl-r/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@prime_self_import@basic-with_one_bo_two_files:
- fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9804/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
* igt@runner@aborted:
- fi-byt-j1900: NOTRUN -> [FAIL][9] ([i915#1814] / [i915#2505])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/fi-byt-j1900/igt@run...@aborted.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-kbl-soraka: [DMESG-WARN][10] ([i915#1982]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9804/fi-kbl-soraka/igt@i915_pm_...@module-reload.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/fi-kbl-soraka/igt@i915_pm_...@module-reload.html
* igt@prime_vgem@basic-fence-flip:
- fi-tgl-y: [DMESG-WARN][12] ([i915#402]) -> [PASS][13] +1
similar issue
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9804/fi-tgl-y/igt@prime_v...@basic-fence-flip.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19729/fi-tgl-y/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1222]: https://gitlab.freedesktop.org/drm/intel/issues/1222
[i915#142]: https://gitlab.freedesktop.org/drm/intel/issues/142
[i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405
[i915#2505]: https://gitlab.freedesktop.org/drm/intel/issues/2505
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
Participating hosts (42 -> 38)
--
Additional (1): fi-ehl-2
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600
fi-bdw-samus
Build changes
-
* Linux: CI_DRM_9804 -> Patchwork_19729
CI-20190529: 20190529
CI_DRM_9804: 0ed1d18cdc37ecf5e07f009a9788ea9ad74677a8 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6015: aa44cddf4ef689f8a3726fcbeedc03f08b12bd82 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_19729: 80a910e388958d3943d65661cd19781a4c75e74f @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
80a910e38895 drm/i915: Extend icl_sanitize_encoder_pll_mapping() to all DDI
platforms
f83943e75f3f drm/i915: Add encoder->is_clock_enabled()
Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf: Require VM_PFNMAP vma for mmap
Am 25.02.21 um 16:49 schrieb Daniel Vetter: On Thu, Feb 25, 2021 at 11:44 AM Daniel Vetter wrote: On Thu, Feb 25, 2021 at 11:28:31AM +0100, Christian König wrote: Am 24.02.21 um 10:31 schrieb Daniel Vetter: On Wed, Feb 24, 2021 at 10:16 AM Thomas Hellström (Intel) wrote: On 2/24/21 9:45 AM, Daniel Vetter wrote: On Wed, Feb 24, 2021 at 8:46 AM Thomas Hellström (Intel) wrote: On 2/23/21 11:59 AM, Daniel Vetter wrote: tldr; DMA buffers aren't normal memory, expecting that you can use them like that (like calling get_user_pages works, or that they're accounting like any other normal memory) cannot be guaranteed. Since some userspace only runs on integrated devices, where all buffers are actually all resident system memory, there's a huge temptation to assume that a struct page is always present and useable like for any more pagecache backed mmap. This has the potential to result in a uapi nightmare. To stop this gap require that DMA buffer mmaps are VM_PFNMAP, which blocks get_user_pages and all the other struct page based infrastructure for everyone. In spirit this is the uapi counterpart to the kernel-internal CONFIG_DMABUF_DEBUG. Motivated by a recent patch which wanted to swich the system dma-buf heap to vm_insert_page instead of vm_insert_pfn. v2: Jason brought up that we also want to guarantee that all ptes have the pte_special flag set, to catch fast get_user_pages (on architectures that support this). Allowing VM_MIXEDMAP (like VM_SPECIAL does) would still allow vm_insert_page, but limiting to VM_PFNMAP will catch that. From auditing the various functions to insert pfn pte entires (vm_insert_pfn_prot, remap_pfn_range and all it's callers like dma_mmap_wc) it looks like VM_PFNMAP is already required anyway, so this should be the correct flag to check for. If we require VM_PFNMAP, for ordinary page mappings, we also need to disallow COW mappings, since it will not work on architectures that don't have CONFIG_ARCH_HAS_PTE_SPECIAL, (see the docs for vm_normal_page()). Hm I figured everyone just uses MAP_SHARED for buffer objects since COW really makes absolutely no sense. How would we enforce this? Perhaps returning -EINVAL on is_cow_mapping() at mmap time. Either that or allowing MIXEDMAP. Also worth noting is the comment in ttm_bo_mmap_vma_setup() with possible performance implications with x86 + PAT + VM_PFNMAP + normal pages. That's a very old comment, though, and might not be valid anymore. I think that's why ttm has a page cache for these, because it indeed sucks. The PAT changes on pages are rather expensive. IIRC the page cache was implemented because of the slowness of the caching mode transition itself, more specifically the wbinvd() call + global TLB flush. Yes, exactly that. The global TLB flush is what really breaks our neck here from a performance perspective. There is still an issue for iomem mappings, because the PAT validation does a linear walk of the resource tree (lol) for every vm_insert_pfn. But for i915 at least this is fixed by using the io_mapping infrastructure, which does the PAT reservation only once when you set up the mapping area at driver load. Yes, I guess that was the issue that the comment describes, but the issue wasn't there with vm_insert_mixed() + VM_MIXEDMAP. Also TTM uses VM_PFNMAP right now for everything, so it can't be a problem that hurts much :-) Hmm, both 5.11 and drm-tip appears to still use MIXEDMAP? https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Fdrivers%2Fgpu%2Fdrm%2Fttm%2Fttm_bo_vm.c%23L554data=04%7C01%7Cchristian.koenig%40amd.com%7Ca93d0dbbc0484fec118808d8d9a4fc22%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637498649935442516%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=7%2BO0WNdBF62eVDy7u4hRydsfviF6dBJEDeZiYIzQAcc%3Dreserved=0 Uh that's bad, because mixed maps pointing at struct page wont stop gup. At least afaik. Hui? I'm pretty sure MIXEDMAP stops gup as well. Otherwise we would have already seen tons of problems with the page cache. On any architecture which has CONFIG_ARCH_HAS_PTE_SPECIAL vm_insert_mixed boils down to vm_insert_pfn wrt gup. And special pte stops gup fast path. But if you don't have VM_IO or VM_PFNMAP set, then I'm not seeing how you're stopping gup slow path. See check_vma_flags() in mm/gup.c. Also if you don't have CONFIG_ARCH_HAS_PTE_SPECIAL then I don't think vm_insert_mixed even works on iomem pfns. There's the devmap exception, but we're not devmap. Worse ttm abuses some accidental codepath to smuggle in hugepte support by intentionally not being devmap. So I'm really not sure this works as we think it should. Maybe good to do a quick test program on amdgpu with a buffer in system memory only and try to do direct io into it. If it works, you have a problem, and a bad one. That's probably impossible, since a quick git grep shows that pretty much anything
Re: [Intel-gfx] [PATCH] drm/compat: Clear bounce structures
On Mon, Feb 22, 2021 at 11:06:43AM +0100, Daniel Vetter wrote: > Some of them have gaps, or fields we don't clear. Native ioctl code > does full copies plus zero-extends on size mismatch, so nothing can > leak. But compat is more hand-rolled so need to be careful. > > None of these matter for performance, so just memset. > > Also I didn't fix up the CONFIG_DRM_LEGACY or CONFIG_DRM_AGP ioctl, those > are security holes anyway. > > Reported-by: syzbot+620cf21140fc7e772...@syzkaller.appspotmail.com # vblank > ioctl > Cc: syzbot+620cf21140fc7e772...@syzkaller.appspotmail.com > Cc: sta...@vger.kernel.org > Signed-off-by: Daniel Vetter Acked-by: Maxime Ripard Maxime signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/compat: more dummy implementations
On Mon, Feb 22, 2021 at 11:06:08AM +0100, Daniel Vetter wrote:
> drm_noop really doesnt do much, and who cares about the permission checks.
^ doesn't
> So let's delete some code.
With the typo fixed,
Acked-by: Maxime Ripard
Maxime
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_ioc32.c | 15 +++
> 1 file changed, 3 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
> index dc734d4828a1..33390f02f5eb 100644
> --- a/drivers/gpu/drm/drm_ioc32.c
> +++ b/drivers/gpu/drm/drm_ioc32.c
> @@ -302,12 +302,8 @@ static int compat_drm_getstats(struct file *file,
> unsigned int cmd,
> unsigned long arg)
> {
> drm_stats32_t __user *argp = (void __user *)arg;
> - int err;
> -
> - err = drm_ioctl_kernel(file, drm_noop, NULL, 0);
> - if (err)
> - return err;
>
> + /* getstats is defunct, just clear */
> if (clear_user(argp, sizeof(drm_stats32_t)))
> return -EFAULT;
> return 0;
> @@ -820,13 +816,8 @@ typedef struct drm_update_draw32 {
> static int compat_drm_update_draw(struct file *file, unsigned int cmd,
> unsigned long arg)
> {
> - drm_update_draw32_t update32;
> -
> - if (copy_from_user(, (void __user *)arg, sizeof(update32)))
> - return -EFAULT;
> -
> - return drm_ioctl_kernel(file, drm_noop, NULL,
> - DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY);
> + /* update_draw is defunct */
> + return 0;
> }
> #endif
>
> --
> 2.30.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Move DDI clock readout to encoder->get_config() (rev2)
== Series Details == Series: drm/i915: Move DDI clock readout to encoder->get_config() (rev2) URL : https://patchwork.freedesktop.org/series/87351/ 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:1323:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gvt/mmio.c:295:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1437:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1491:15: warning: memset with byte count of 16777216 +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' - different lock contexts for basic block ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/6] drm/i915: Do intel_dpll_readout_hw_state() after encoder readout
From: Ville Syrjälä
The clock readout for DDI encoders needs to moved into the encoders.
To that end intel_dpll_readout_hw_state() needs to happen after
the encoder readout as otherwise it can't correctly populate
the PLL crtc_mask/active_mask bitmasks.
v2: Populate DPLL ref clocks before the encoder->get_config()
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 5 +++--
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 9 ++---
drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 1 +
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index d0da88751c72..faf9507c9da2 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -12908,6 +12908,7 @@ int intel_modeset_init_nogem(struct drm_i915_private
*i915)
intel_update_czclk(i915);
intel_modeset_init_hw(i915);
+ intel_dpll_update_ref_clks(i915);
intel_hdcp_component_init(i915);
@@ -13444,8 +13445,6 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
readout_plane_state(dev_priv);
- intel_dpll_readout_hw_state(dev_priv);
-
for_each_intel_encoder(dev, encoder) {
pipe = 0;
@@ -13480,6 +13479,8 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
pipe_name(pipe));
}
+ intel_dpll_readout_hw_state(dev_priv);
+
drm_connector_list_iter_begin(dev, _iter);
for_each_intel_connector_iter(connector, _iter) {
if (connector->get_hw_state(connector)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index 529b1d569af2..ac6460962e29 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -4612,12 +4612,15 @@ static void readout_dpll_hw_state(struct
drm_i915_private *i915,
pll->info->name, pll->state.crtc_mask, pll->on);
}
-void intel_dpll_readout_hw_state(struct drm_i915_private *i915)
+void intel_dpll_update_ref_clks(struct drm_i915_private *i915)
{
- int i;
-
if (i915->dpll.mgr && i915->dpll.mgr->update_ref_clks)
i915->dpll.mgr->update_ref_clks(i915);
+}
+
+void intel_dpll_readout_hw_state(struct drm_i915_private *i915)
+{
+ int i;
for (i = 0; i < i915->dpll.num_shared_dpll; i++)
readout_dpll_hw_state(i915, >dpll.shared_dplls[i]);
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
index 2eb7618ef957..81e67639dadb 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
@@ -410,6 +410,7 @@ void intel_enable_shared_dpll(const struct intel_crtc_state
*crtc_state);
void intel_disable_shared_dpll(const struct intel_crtc_state *crtc_state);
void intel_shared_dpll_swap_state(struct intel_atomic_state *state);
void intel_shared_dpll_init(struct drm_device *dev);
+void intel_dpll_update_ref_clks(struct drm_i915_private *dev_priv);
void intel_dpll_readout_hw_state(struct drm_i915_private *dev_priv);
void intel_dpll_sanitize_state(struct drm_i915_private *dev_priv);
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf: Require VM_PFNMAP vma for mmap
On Thu, Feb 25, 2021 at 11:44 AM Daniel Vetter wrote: > > On Thu, Feb 25, 2021 at 11:28:31AM +0100, Christian König wrote: > > Am 24.02.21 um 10:31 schrieb Daniel Vetter: > > > On Wed, Feb 24, 2021 at 10:16 AM Thomas Hellström (Intel) > > > wrote: > > > > > > > > On 2/24/21 9:45 AM, Daniel Vetter wrote: > > > > > On Wed, Feb 24, 2021 at 8:46 AM Thomas Hellström (Intel) > > > > > wrote: > > > > > > On 2/23/21 11:59 AM, Daniel Vetter wrote: > > > > > > > tldr; DMA buffers aren't normal memory, expecting that you can use > > > > > > > them like that (like calling get_user_pages works, or that they're > > > > > > > accounting like any other normal memory) cannot be guaranteed. > > > > > > > > > > > > > > Since some userspace only runs on integrated devices, where all > > > > > > > buffers are actually all resident system memory, there's a huge > > > > > > > temptation to assume that a struct page is always present and > > > > > > > useable > > > > > > > like for any more pagecache backed mmap. This has the potential to > > > > > > > result in a uapi nightmare. > > > > > > > > > > > > > > To stop this gap require that DMA buffer mmaps are VM_PFNMAP, > > > > > > > which > > > > > > > blocks get_user_pages and all the other struct page based > > > > > > > infrastructure for everyone. In spirit this is the uapi > > > > > > > counterpart to > > > > > > > the kernel-internal CONFIG_DMABUF_DEBUG. > > > > > > > > > > > > > > Motivated by a recent patch which wanted to swich the system > > > > > > > dma-buf > > > > > > > heap to vm_insert_page instead of vm_insert_pfn. > > > > > > > > > > > > > > v2: > > > > > > > > > > > > > > Jason brought up that we also want to guarantee that all ptes > > > > > > > have the > > > > > > > pte_special flag set, to catch fast get_user_pages (on > > > > > > > architectures > > > > > > > that support this). Allowing VM_MIXEDMAP (like VM_SPECIAL does) > > > > > > > would > > > > > > > still allow vm_insert_page, but limiting to VM_PFNMAP will catch > > > > > > > that. > > > > > > > > > > > > > >From auditing the various functions to insert pfn pte entires > > > > > > > (vm_insert_pfn_prot, remap_pfn_range and all it's callers like > > > > > > > dma_mmap_wc) it looks like VM_PFNMAP is already required anyway, > > > > > > > so > > > > > > > this should be the correct flag to check for. > > > > > > > > > > > > > If we require VM_PFNMAP, for ordinary page mappings, we also need to > > > > > > disallow COW mappings, since it will not work on architectures that > > > > > > don't have CONFIG_ARCH_HAS_PTE_SPECIAL, (see the docs for > > > > > > vm_normal_page()). > > > > > Hm I figured everyone just uses MAP_SHARED for buffer objects since > > > > > COW really makes absolutely no sense. How would we enforce this? > > > > Perhaps returning -EINVAL on is_cow_mapping() at mmap time. Either that > > > > or allowing MIXEDMAP. > > > > > > > > > > Also worth noting is the comment in ttm_bo_mmap_vma_setup() with > > > > > > possible performance implications with x86 + PAT + VM_PFNMAP + > > > > > > normal > > > > > > pages. That's a very old comment, though, and might not be valid > > > > > > anymore. > > > > > I think that's why ttm has a page cache for these, because it indeed > > > > > sucks. The PAT changes on pages are rather expensive. > > > > IIRC the page cache was implemented because of the slowness of the > > > > caching mode transition itself, more specifically the wbinvd() call + > > > > global TLB flush. > > > > Yes, exactly that. The global TLB flush is what really breaks our neck here > > from a performance perspective. > > > > > > > There is still an issue for iomem mappings, because the PAT validation > > > > > does a linear walk of the resource tree (lol) for every vm_insert_pfn. > > > > > But for i915 at least this is fixed by using the io_mapping > > > > > infrastructure, which does the PAT reservation only once when you set > > > > > up the mapping area at driver load. > > > > Yes, I guess that was the issue that the comment describes, but the > > > > issue wasn't there with vm_insert_mixed() + VM_MIXEDMAP. > > > > > > > > > Also TTM uses VM_PFNMAP right now for everything, so it can't be a > > > > > problem that hurts much :-) > > > > Hmm, both 5.11 and drm-tip appears to still use MIXEDMAP? > > > > > > > > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/ttm/ttm_bo_vm.c#L554 > > > Uh that's bad, because mixed maps pointing at struct page wont stop > > > gup. At least afaik. > > > > Hui? I'm pretty sure MIXEDMAP stops gup as well. Otherwise we would have > > already seen tons of problems with the page cache. > > On any architecture which has CONFIG_ARCH_HAS_PTE_SPECIAL vm_insert_mixed > boils down to vm_insert_pfn wrt gup. And special pte stops gup fast path. > > But if you don't have VM_IO or VM_PFNMAP set, then I'm not seeing how > you're stopping gup slow path. See check_vma_flags() in mm/gup.c. > > Also if you don't have
[Intel-gfx] [PULL] drm-intel-next-fixes
Hi Dave and Daniel, Here goes drm-intel-next-fixes-2021-02-25: A fix for color format check from Ville, plus the re-enable of -Wuninitialized from Nathan, and the GVT fixes including fixes for ww locking, cmd parser and a general cleanup of dev_priv->gt. Thanks, Rodrigo. The following changes since commit 81ce8f04aa96f7f6cae05770f68b5d15be91f5a2: drm/i915/gt: Correct surface base address for renderclear (2021-02-17 06:19:04 -0500) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2021-02-25 for you to fetch changes up to ed428ffc28521b9f1b6a71584d1875318a122859: drm/i915: Nuke INTEL_OUTPUT_FORMAT_INVALID (2021-02-23 09:38:14 -0500) A fix for color format check from Ville, plus the re-enable of -Wuninitialized from Nathan, and the GVT fixes including fixes for ww locking, cmd parser and a general cleanup of dev_priv->gt. Chris Wilson (2): drm/i915/gvt: Parse default state to update reg whitelist drm/i915/gvt: Purge dev_priv->gt Nathan Chancellor (1): drm/i915: Enable -Wuninitialized Rodrigo Vivi (1): Merge tag 'gvt-next-fixes-2021-02-22' of https://github.com/intel/gvt-linux into drm-intel-next-fixes Ville Syrjälä (1): drm/i915: Nuke INTEL_OUTPUT_FORMAT_INVALID Zhi Wang (1): drm/i915/gvt: Introduce per object locking in GVT scheduler. drivers/gpu/drm/i915/Makefile | 1 - drivers/gpu/drm/i915/display/intel_crtc.c | 1 - drivers/gpu/drm/i915/display/intel_display.c | 3 +- drivers/gpu/drm/i915/display/intel_display_types.h | 1 - drivers/gpu/drm/i915/gvt/cmd_parser.c | 93 +- drivers/gpu/drm/i915/gvt/execlist.c| 8 +- drivers/gpu/drm/i915/gvt/scheduler.c | 52 +--- 7 files changed, 65 insertions(+), 94 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf: Require VM_PFNMAP vma for mmap
Am 24.02.21 um 10:31 schrieb Daniel Vetter: On Wed, Feb 24, 2021 at 10:16 AM Thomas Hellström (Intel) wrote: On 2/24/21 9:45 AM, Daniel Vetter wrote: On Wed, Feb 24, 2021 at 8:46 AM Thomas Hellström (Intel) wrote: On 2/23/21 11:59 AM, Daniel Vetter wrote: tldr; DMA buffers aren't normal memory, expecting that you can use them like that (like calling get_user_pages works, or that they're accounting like any other normal memory) cannot be guaranteed. Since some userspace only runs on integrated devices, where all buffers are actually all resident system memory, there's a huge temptation to assume that a struct page is always present and useable like for any more pagecache backed mmap. This has the potential to result in a uapi nightmare. To stop this gap require that DMA buffer mmaps are VM_PFNMAP, which blocks get_user_pages and all the other struct page based infrastructure for everyone. In spirit this is the uapi counterpart to the kernel-internal CONFIG_DMABUF_DEBUG. Motivated by a recent patch which wanted to swich the system dma-buf heap to vm_insert_page instead of vm_insert_pfn. v2: Jason brought up that we also want to guarantee that all ptes have the pte_special flag set, to catch fast get_user_pages (on architectures that support this). Allowing VM_MIXEDMAP (like VM_SPECIAL does) would still allow vm_insert_page, but limiting to VM_PFNMAP will catch that. From auditing the various functions to insert pfn pte entires (vm_insert_pfn_prot, remap_pfn_range and all it's callers like dma_mmap_wc) it looks like VM_PFNMAP is already required anyway, so this should be the correct flag to check for. If we require VM_PFNMAP, for ordinary page mappings, we also need to disallow COW mappings, since it will not work on architectures that don't have CONFIG_ARCH_HAS_PTE_SPECIAL, (see the docs for vm_normal_page()). Hm I figured everyone just uses MAP_SHARED for buffer objects since COW really makes absolutely no sense. How would we enforce this? Perhaps returning -EINVAL on is_cow_mapping() at mmap time. Either that or allowing MIXEDMAP. Also worth noting is the comment in ttm_bo_mmap_vma_setup() with possible performance implications with x86 + PAT + VM_PFNMAP + normal pages. That's a very old comment, though, and might not be valid anymore. I think that's why ttm has a page cache for these, because it indeed sucks. The PAT changes on pages are rather expensive. IIRC the page cache was implemented because of the slowness of the caching mode transition itself, more specifically the wbinvd() call + global TLB flush. Yes, exactly that. The global TLB flush is what really breaks our neck here from a performance perspective. There is still an issue for iomem mappings, because the PAT validation does a linear walk of the resource tree (lol) for every vm_insert_pfn. But for i915 at least this is fixed by using the io_mapping infrastructure, which does the PAT reservation only once when you set up the mapping area at driver load. Yes, I guess that was the issue that the comment describes, but the issue wasn't there with vm_insert_mixed() + VM_MIXEDMAP. Also TTM uses VM_PFNMAP right now for everything, so it can't be a problem that hurts much :-) Hmm, both 5.11 and drm-tip appears to still use MIXEDMAP? https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/ttm/ttm_bo_vm.c#L554 Uh that's bad, because mixed maps pointing at struct page wont stop gup. At least afaik. Hui? I'm pretty sure MIXEDMAP stops gup as well. Otherwise we would have already seen tons of problems with the page cache. Regards, Christian. Christian, do we need to patch this up, and maybe fix up ttm fault handler to use io_mapping so the vm_insert_pfn stuff is fast? -Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [5.10.y regression] i915 clear-residuals mitigation is causing gfx issues
Hi Chris,
On 2/11/21 11:49 AM, Chris Wilson wrote:
> Quoting Hans de Goede (2021-02-11 10:36:13)
>> Hi,
>>
>> On 2/10/21 1:48 PM, Chris Wilson wrote:
>>> Quoting Hans de Goede (2021-02-10 10:37:19)
Hi,
On 2/10/21 12:07 AM, Chris Wilson wrote:
> Quoting Hans de Goede (2021-02-09 11:46:46)
>> Hi,
>>
>> On 2/9/21 12:27 AM, Chris Wilson wrote:
>>> Quoting Hans de Goede (2021-02-08 20:38:58)
Hi All,
We (Fedora) have been receiving reports from multiple users about gfx
issues / glitches
stating with 5.10.9. All reporters are users of Ivy Bridge / Haswell
iGPUs and all
reporters report that adding i915.mitigations=off to the cmdline fixes
things, see:
>>>
>>> I tried to reproduce this on the w/e on hsw-gt1, to no avail; and piglit
>>> did not report any differences with and without mitigations. I have yet
>>> to test other platforms. So I don't yet have an alternative.
>>
>> Note the original / first reporter of:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1925346
>>
>> Is using hsw-gt2, so it seems that the problem is not just the enabling
>> of
>> the mitigations on ivy-bridge / bay-trail but that there actually is
>> a regression on devices where the WA worked fine before...
>
> There have been 3 crashes uploaded related to v5.10.9, and in all 3
> cases the ACTHD has been in the first page. This strongly suggests that
> the w/a is scribbling over address 0. And there's then a very good
> chance that
>
> commit 29d35b73ead4e41aa0d1a954c9bfbdce659ec5d6
> Author: Chris Wilson
> Date: Mon Jan 25 12:50:33 2021 +
>
> drm/i915/gt: Always try to reserve GGTT address 0x0
>
> commit 489140b5ba2e7cc4b853c29e0591895ddb462a82 upstream.
>
> in v5.10.14 is sufficient to hide the issue.
That one actually is already in v5.10.13 and the various reportes of these
issues have already tested 5.10.13. They did mention that it took longer
to reproduce with 5.10.13 then with 5.10.10, but that could also be due to:
"drm/i915/gt: Clear CACHE_MODE prior to clearing residuals"
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y=520d05a77b2866eb4cb9e548e1d8c8abcfe60ec5
>>>
>>> Started looking for scratch page overwrites, and found this little gem:
>>> https://patchwork.freedesktop.org/patch/420436/?series=86947=1
>>>
>>> Looks promising wrt the cause of overwriting random addresses -- and
>>> I hope that is the explanation for the glitches/hangs. I have a hsw gt2
>>> with gnome shell, piglit is happy, but I suspect it is all due to
>>> placement and so will only occur at random.
>>
>> If you can give me a list of commits to cherry-pick then I can prepare
>> a Fedora 5.10.y kernel which those added for the group of Fedora users
>> who are hitting this to test.
>
> e627d5923cae ("drm/i915/gt: One more flush for Baytrail clear residuals")
> d30bbd62b1bf ("drm/i915/gt: Flush before changing register state")
> 1914911f4aa0 ("drm/i915/gt: Correct surface base address for renderclear")
The bug reports for this keep coming in here is the full lists of bugs which I'm
aware of which all have this as root cause (the ones with out links are all
bugzilla.redhat.com bugs):
1843274 - i915 GPU Hang with kernel 5.7 on Haswell (Acer C720P Chromebook)
1922511 - Recent upgrades caused smearing/tearing
1925346 - Screen glitches after updating to Kernel 5.10.10
1925903 - Flickering UI elements, screen instability (Wayland)
1931065 - Frequent i915 hangs
https://gitlab.freedesktop.org/drm/intel/-/issues/3099
Testing by various reporters shows that this appears to be fully resolved for
all
reporters except one by the quoted 3 commits from -next above.
For the one reporter who is still seeing some rendering glitches things are
much improved, so I think they are also hitting a different issue.
I wanted to send cherry-picks of the 3 quoted commits to stable@vger, but
2 of the 3 are not in Linus' master yet; and I'm also not seeing these
in any drm -fixes branches yet :(
Chris, can you please get d30bbd62b1bf and 1914911f4aa0 on their way to Linus?
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] dma-buf: Require VM_PFNMAP vma for mmap (rev3)
== Series Details == Series: series starting with [1/2] dma-buf: Require VM_PFNMAP vma for mmap (rev3) URL : https://patchwork.freedesktop.org/series/87313/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9804 -> Patchwork_19728 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19728 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19728, 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_19728/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19728: ### IGT changes ### Possible regressions * igt@prime_vgem@basic-fence-mmap: - fi-byt-j1900: [PASS][1] -> [FAIL][2] +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9804/fi-byt-j1900/igt@prime_v...@basic-fence-mmap.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19728/fi-byt-j1900/igt@prime_v...@basic-fence-mmap.html * igt@prime_vgem@basic-fence-read: - fi-bsw-kefka: [PASS][3] -> [INCOMPLETE][4] +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9804/fi-bsw-kefka/igt@prime_v...@basic-fence-read.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19728/fi-bsw-kefka/igt@prime_v...@basic-fence-read.html - fi-ilk-650: [PASS][5] -> [INCOMPLETE][6] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9804/fi-ilk-650/igt@prime_v...@basic-fence-read.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19728/fi-ilk-650/igt@prime_v...@basic-fence-read.html - fi-byt-j1900: [PASS][7] -> [INCOMPLETE][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9804/fi-byt-j1900/igt@prime_v...@basic-fence-read.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19728/fi-byt-j1900/igt@prime_v...@basic-fence-read.html * igt@prime_vgem@basic-gtt: - fi-ilk-650: [PASS][9] -> [FAIL][10] +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9804/fi-ilk-650/igt@prime_v...@basic-gtt.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19728/fi-ilk-650/igt@prime_v...@basic-gtt.html - fi-elk-e7500: [PASS][11] -> [FAIL][12] +5 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9804/fi-elk-e7500/igt@prime_v...@basic-gtt.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19728/fi-elk-e7500/igt@prime_v...@basic-gtt.html * igt@prime_vgem@basic-read: - fi-bsw-nick:[PASS][13] -> [FAIL][14] +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9804/fi-bsw-nick/igt@prime_v...@basic-read.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19728/fi-bsw-nick/igt@prime_v...@basic-read.html * igt@prime_vgem@basic-write: - fi-pnv-d510:[PASS][15] -> [FAIL][16] +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9804/fi-pnv-d510/igt@prime_v...@basic-write.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19728/fi-pnv-d510/igt@prime_v...@basic-write.html * igt@runner@aborted: - fi-ilk-650: NOTRUN -> [FAIL][17] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19728/fi-ilk-650/igt@run...@aborted.html - fi-kbl-x1275: NOTRUN -> [FAIL][18] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19728/fi-kbl-x1275/igt@run...@aborted.html - fi-bsw-kefka: NOTRUN -> [FAIL][19] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19728/fi-bsw-kefka/igt@run...@aborted.html - fi-cfl-8700k: NOTRUN -> [FAIL][20] [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19728/fi-cfl-8700k/igt@run...@aborted.html - fi-tgl-y: NOTRUN -> [FAIL][21] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19728/fi-tgl-y/igt@run...@aborted.html - fi-skl-6600u: NOTRUN -> [FAIL][22] [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19728/fi-skl-6600u/igt@run...@aborted.html - fi-cfl-8109u: NOTRUN -> [FAIL][23] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19728/fi-cfl-8109u/igt@run...@aborted.html - fi-bsw-nick:NOTRUN -> [FAIL][24] [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19728/fi-bsw-nick/igt@run...@aborted.html - fi-snb-2520m: NOTRUN -> [FAIL][25] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19728/fi-snb-2520m/igt@run...@aborted.html - fi-kbl-soraka: NOTRUN -> [FAIL][26] [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19728/fi-kbl-soraka/igt@run...@aborted.html - fi-kbl-7500u: NOTRUN -> [FAIL][27] [27]:
Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf: Require VM_PFNMAP vma for mmap
On Thu, Feb 25, 2021 at 11:30:23AM +0100, Christian König wrote: > > > Am 24.02.21 um 19:46 schrieb Jason Gunthorpe: > > On Wed, Feb 24, 2021 at 09:45:51AM +0100, Daniel Vetter wrote: > > > > > Hm I figured everyone just uses MAP_SHARED for buffer objects since > > > COW really makes absolutely no sense. How would we enforce this? > > In RDMA we test > > > > drivers/infiniband/core/ib_core_uverbs.c: if (!(vma->vm_flags & > > VM_SHARED)) > > > > During mmap to reject use of MAP_PRIVATE on BAR pages. > > That's a really good idea. MAP_PRIVATE and any driver mappings doesn't > really work at all. Yeah I feel like this is the next patch we need to add on this little series of locking down dma-buf mmap semantics. Probably should also push these into drm gem mmap code (and maybe ttm can switch over to that, it's really the same). One at a time. -Daniel > > Christian. > > > > > Jason > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf: Require VM_PFNMAP vma for mmap
On Thu, Feb 25, 2021 at 11:28:31AM +0100, Christian König wrote: > Am 24.02.21 um 10:31 schrieb Daniel Vetter: > > On Wed, Feb 24, 2021 at 10:16 AM Thomas Hellström (Intel) > > wrote: > > > > > > On 2/24/21 9:45 AM, Daniel Vetter wrote: > > > > On Wed, Feb 24, 2021 at 8:46 AM Thomas Hellström (Intel) > > > > wrote: > > > > > On 2/23/21 11:59 AM, Daniel Vetter wrote: > > > > > > tldr; DMA buffers aren't normal memory, expecting that you can use > > > > > > them like that (like calling get_user_pages works, or that they're > > > > > > accounting like any other normal memory) cannot be guaranteed. > > > > > > > > > > > > Since some userspace only runs on integrated devices, where all > > > > > > buffers are actually all resident system memory, there's a huge > > > > > > temptation to assume that a struct page is always present and > > > > > > useable > > > > > > like for any more pagecache backed mmap. This has the potential to > > > > > > result in a uapi nightmare. > > > > > > > > > > > > To stop this gap require that DMA buffer mmaps are VM_PFNMAP, which > > > > > > blocks get_user_pages and all the other struct page based > > > > > > infrastructure for everyone. In spirit this is the uapi counterpart > > > > > > to > > > > > > the kernel-internal CONFIG_DMABUF_DEBUG. > > > > > > > > > > > > Motivated by a recent patch which wanted to swich the system dma-buf > > > > > > heap to vm_insert_page instead of vm_insert_pfn. > > > > > > > > > > > > v2: > > > > > > > > > > > > Jason brought up that we also want to guarantee that all ptes have > > > > > > the > > > > > > pte_special flag set, to catch fast get_user_pages (on architectures > > > > > > that support this). Allowing VM_MIXEDMAP (like VM_SPECIAL does) > > > > > > would > > > > > > still allow vm_insert_page, but limiting to VM_PFNMAP will catch > > > > > > that. > > > > > > > > > > > >From auditing the various functions to insert pfn pte entires > > > > > > (vm_insert_pfn_prot, remap_pfn_range and all it's callers like > > > > > > dma_mmap_wc) it looks like VM_PFNMAP is already required anyway, so > > > > > > this should be the correct flag to check for. > > > > > > > > > > > If we require VM_PFNMAP, for ordinary page mappings, we also need to > > > > > disallow COW mappings, since it will not work on architectures that > > > > > don't have CONFIG_ARCH_HAS_PTE_SPECIAL, (see the docs for > > > > > vm_normal_page()). > > > > Hm I figured everyone just uses MAP_SHARED for buffer objects since > > > > COW really makes absolutely no sense. How would we enforce this? > > > Perhaps returning -EINVAL on is_cow_mapping() at mmap time. Either that > > > or allowing MIXEDMAP. > > > > > > > > Also worth noting is the comment in ttm_bo_mmap_vma_setup() with > > > > > possible performance implications with x86 + PAT + VM_PFNMAP + normal > > > > > pages. That's a very old comment, though, and might not be valid > > > > > anymore. > > > > I think that's why ttm has a page cache for these, because it indeed > > > > sucks. The PAT changes on pages are rather expensive. > > > IIRC the page cache was implemented because of the slowness of the > > > caching mode transition itself, more specifically the wbinvd() call + > > > global TLB flush. > > Yes, exactly that. The global TLB flush is what really breaks our neck here > from a performance perspective. > > > > > There is still an issue for iomem mappings, because the PAT validation > > > > does a linear walk of the resource tree (lol) for every vm_insert_pfn. > > > > But for i915 at least this is fixed by using the io_mapping > > > > infrastructure, which does the PAT reservation only once when you set > > > > up the mapping area at driver load. > > > Yes, I guess that was the issue that the comment describes, but the > > > issue wasn't there with vm_insert_mixed() + VM_MIXEDMAP. > > > > > > > Also TTM uses VM_PFNMAP right now for everything, so it can't be a > > > > problem that hurts much :-) > > > Hmm, both 5.11 and drm-tip appears to still use MIXEDMAP? > > > > > > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/ttm/ttm_bo_vm.c#L554 > > Uh that's bad, because mixed maps pointing at struct page wont stop > > gup. At least afaik. > > Hui? I'm pretty sure MIXEDMAP stops gup as well. Otherwise we would have > already seen tons of problems with the page cache. On any architecture which has CONFIG_ARCH_HAS_PTE_SPECIAL vm_insert_mixed boils down to vm_insert_pfn wrt gup. And special pte stops gup fast path. But if you don't have VM_IO or VM_PFNMAP set, then I'm not seeing how you're stopping gup slow path. See check_vma_flags() in mm/gup.c. Also if you don't have CONFIG_ARCH_HAS_PTE_SPECIAL then I don't think vm_insert_mixed even works on iomem pfns. There's the devmap exception, but we're not devmap. Worse ttm abuses some accidental codepath to smuggle in hugepte support by intentionally not being devmap. So I'm really not sure this works as we think it should. Maybe good to
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] dma-buf: Require VM_PFNMAP vma for mmap (rev3)
== Series Details == Series: series starting with [1/2] dma-buf: Require VM_PFNMAP vma for mmap (rev3) URL : https://patchwork.freedesktop.org/series/87313/ State : warning == Summary == $ dim checkpatch origin/drm-tip b71cc38b23b9 dma-buf: Require VM_PFNMAP vma for mmap -:34: WARNING:TYPO_SPELLING: 'entires' may be misspelled - perhaps 'entries'? #34: >From auditing the various functions to insert pfn pte entires ^^^ -:39: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #39: References: https://lore.kernel.org/lkml/cakmk7uhi+mg0z0humnt13qccvuturvjpcr0njrl12k-wbwz...@mail.gmail.com/ -:97: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: Daniel Vetter ' total: 0 errors, 3 warnings, 0 checks, 39 lines checked 93fc58ee63d1 drm/vgem: use shmem helpers -:424: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 381 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf: Require VM_PFNMAP vma for mmap
Am 24.02.21 um 19:46 schrieb Jason Gunthorpe: On Wed, Feb 24, 2021 at 09:45:51AM +0100, Daniel Vetter wrote: Hm I figured everyone just uses MAP_SHARED for buffer objects since COW really makes absolutely no sense. How would we enforce this? In RDMA we test drivers/infiniband/core/ib_core_uverbs.c: if (!(vma->vm_flags & VM_SHARED)) During mmap to reject use of MAP_PRIVATE on BAR pages. That's a really good idea. MAP_PRIVATE and any driver mappings doesn't really work at all. Christian. Jason ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/vgem: use shmem helpers
Aside from deleting lots of code the real motivation here is to switch
the mmap over to VM_PFNMAP, to be more consistent with what real gpu
drivers do. They're all VM_PFNMP, which means get_user_pages doesn't
work, and even if you try and there's a struct page behind that,
touching it and mucking around with its refcount can upset drivers
real bad.
v2: Review from Thomas:
- sort #include
- drop more dead code that I didn't spot somehow
v3: select DRM_GEM_SHMEM_HELPER to make it build (intel-gfx-ci)
Cc: Thomas Zimmermann
Acked-by: Thomas Zimmermann
Cc: John Stultz
Cc: Sumit Semwal
Cc: "Christian König"
Signed-off-by: Daniel Vetter
Cc: Melissa Wen
Cc: Chris Wilson
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/vgem/vgem_drv.c | 340 +---
2 files changed, 4 insertions(+), 337 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 8e73311de583..94e4ac830283 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -274,6 +274,7 @@ source "drivers/gpu/drm/kmb/Kconfig"
config DRM_VGEM
tristate "Virtual GEM provider"
depends on DRM
+ select DRM_GEM_SHMEM_HELPER
help
Choose this option to get a virtual graphics memory manager,
as used by Mesa's software renderer for enhanced performance.
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index a0e75f1d5d01..b1b3a5ffc542 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -38,6 +38,7 @@
#include
#include
+#include
#include
#include
#include
@@ -50,87 +51,11 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
-static const struct drm_gem_object_funcs vgem_gem_object_funcs;
-
static struct vgem_device {
struct drm_device drm;
struct platform_device *platform;
} *vgem_device;
-static void vgem_gem_free_object(struct drm_gem_object *obj)
-{
- struct drm_vgem_gem_object *vgem_obj = to_vgem_bo(obj);
-
- kvfree(vgem_obj->pages);
- mutex_destroy(_obj->pages_lock);
-
- if (obj->import_attach)
- drm_prime_gem_destroy(obj, vgem_obj->table);
-
- drm_gem_object_release(obj);
- kfree(vgem_obj);
-}
-
-static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
-{
- struct vm_area_struct *vma = vmf->vma;
- struct drm_vgem_gem_object *obj = vma->vm_private_data;
- /* We don't use vmf->pgoff since that has the fake offset */
- unsigned long vaddr = vmf->address;
- vm_fault_t ret = VM_FAULT_SIGBUS;
- loff_t num_pages;
- pgoff_t page_offset;
- page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
-
- num_pages = DIV_ROUND_UP(obj->base.size, PAGE_SIZE);
-
- if (page_offset >= num_pages)
- return VM_FAULT_SIGBUS;
-
- mutex_lock(>pages_lock);
- if (obj->pages) {
- get_page(obj->pages[page_offset]);
- vmf->page = obj->pages[page_offset];
- ret = 0;
- }
- mutex_unlock(>pages_lock);
- if (ret) {
- struct page *page;
-
- page = shmem_read_mapping_page(
- file_inode(obj->base.filp)->i_mapping,
- page_offset);
- if (!IS_ERR(page)) {
- vmf->page = page;
- ret = 0;
- } else switch (PTR_ERR(page)) {
- case -ENOSPC:
- case -ENOMEM:
- ret = VM_FAULT_OOM;
- break;
- case -EBUSY:
- ret = VM_FAULT_RETRY;
- break;
- case -EFAULT:
- case -EINVAL:
- ret = VM_FAULT_SIGBUS;
- break;
- default:
- WARN_ON(PTR_ERR(page));
- ret = VM_FAULT_SIGBUS;
- break;
- }
-
- }
- return ret;
-}
-
-static const struct vm_operations_struct vgem_gem_vm_ops = {
- .fault = vgem_gem_fault,
- .open = drm_gem_vm_open,
- .close = drm_gem_vm_close,
-};
-
static int vgem_open(struct drm_device *dev, struct drm_file *file)
{
struct vgem_file *vfile;
@@ -159,265 +84,12 @@ static void vgem_postclose(struct drm_device *dev, struct
drm_file *file)
kfree(vfile);
}
-static struct drm_vgem_gem_object *__vgem_gem_create(struct drm_device *dev,
- unsigned long size)
-{
- struct drm_vgem_gem_object *obj;
- int ret;
-
- obj = kzalloc(sizeof(*obj), GFP_KERNEL);
- if (!obj)
- return ERR_PTR(-ENOMEM);
-
- obj->base.funcs = _gem_object_funcs;
-
- ret = drm_gem_object_init(dev, >base,
Re: [Intel-gfx] udldrm does not recover from powersave? Re: udldrmfb: causes WARN in i915 on X60 (x86-32)
Hi! > > Thank you, that fixes the DMA issue, and I can use the udl. > > > > ...for a while. Then screensaver blanks laptop screen, udl screen > > blanks too. Upon hitting a key, internal screen shows up, udl does > > not. > > > > I try rerunning xrandr ... --auto, but could not recover it. > > > > Any ideas? > > Did it work before the regression? I don't know. I'm trying to get it to work, I basically did not use it before. > For testing, could you please remove the fix and then do > > git revert 6eb0233ec2d0 > > This would restore the old version. Please report back on the results. I doubt this is related, but I can try. Best regards, Pavel -- http://www.livejournal.com/~pavelmachek signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] udldrm does not recover from powersave? Re: udldrmfb: causes WARN in i915 on X60 (x86-32)
Hi Am 25.02.21 um 10:53 schrieb Pavel Machek: Hi! This is in -next, but I get same behaviour on 5.11; and no, udl does Thanks for reporting. We are in the process of fixing the issue. The latest patch is at [1]. Thank you, that fixes the DMA issue, and I can use the udl. ...for a while. Then screensaver blanks laptop screen, udl screen blanks too. Upon hitting a key, internal screen shows up, udl does not. I try rerunning xrandr ... --auto, but could not recover it. Any ideas? Did it work before the regression? For testing, could you please remove the fix and then do git revert 6eb0233ec2d0 This would restore the old version. Please report back on the results. Best regards Thomas Best regards, Pavel ___ dri-devel mailing list dri-de...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] udldrm does not recover from powersave? Re: udldrmfb: causes WARN in i915 on X60 (x86-32)
Hi! > >This is in -next, but I get same behaviour on 5.11; and no, udl does > > Thanks for reporting. We are in the process of fixing the issue. The latest > patch is at [1]. > Thank you, that fixes the DMA issue, and I can use the udl. ...for a while. Then screensaver blanks laptop screen, udl screen blanks too. Upon hitting a key, internal screen shows up, udl does not. I try rerunning xrandr ... --auto, but could not recover it. Any ideas? Best regards, Pavel -- http://www.livejournal.com/~pavelmachek signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-next-fixes
drm-misc-next-fixes-2021-02-25:
drm-misc-next tasty fixes for v5.12:
- Cherry pick of drm-misc-fixes pull:
"here's this week's PR for drm-misc-fixes. One of the patches is a memory
leak; the rest is for hardware issues."
- Fix dt bindings for dp connector.
- Fix build error in atyfb.
- Improve error handling for dma-buf heaps.
- Make vblank timestamp more correct, by recording timestamp to be set when
signaling.
The following changes since commit e2183fb135a7f62d317aa1c61eb3d1919080edba:
Revert "drm/scheduler: Job timeout handler returns status (v3)" (2021-02-10
15:26:00 +0100)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2021-02-25
for you to fetch changes up to d922d58fedcd98ba625e89b625a98e222b090b10:
drm/panel: kd35t133: allow using non-continuous dsi clock (2021-02-25
10:18:45 +0100)
drm-misc-next tasty fixes for v5.12:
- Cherry pick of drm-misc-fixes pull:
"here's this week's PR for drm-misc-fixes. One of the patches is a memory
leak; the rest is for hardware issues."
- Fix dt bindings for dp connector.
- Fix build error in atyfb.
- Improve error handling for dma-buf heaps.
- Make vblank timestamp more correct, by recording timestamp to be set when
signaling.
Alyssa Rosenzweig (1):
drm/rockchip: Require the YTR modifier for AFBC
Bjorn Andersson (1):
dt-bindings: dp-connector: Drop maxItems from -supply
Heiko Stuebner (1):
drm/panel: kd35t133: allow using non-continuous dsi clock
John Stultz (2):
dma-buf: system_heap: Make sure to return an error if we abort
dma-buf: heaps: Rework heap allocation hooks to return struct dma_buf
instead of fd
Randy Dunlap (1):
fbdev: atyfb: add stubs for aty_{ld,st}_lcd()
Veera Sundaram Sankaran (2):
dma-fence: allow signaling drivers to set fence timestamp
drm/drm_vblank: set the dma-fence timestamp during send_vblank_event
xinhui pan (1):
drm/ttm: Fix a memory leak
.../bindings/display/connector/dp-connector.yaml | 1 -
drivers/dma-buf/dma-fence.c| 70 +++---
drivers/dma-buf/dma-heap.c | 14 -
drivers/dma-buf/heaps/cma_heap.c | 22 +++
drivers/dma-buf/heaps/system_heap.c| 25
drivers/gpu/drm/drm_file.c | 68 +
drivers/gpu/drm/drm_vblank.c | 9 ++-
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 3 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.h| 11
drivers/gpu/drm/ttm/ttm_bo.c | 9 ++-
drivers/video/fbdev/aty/atyfb_base.c | 9 +++
include/drm/drm_file.h | 3 +
include/linux/dma-fence.h | 3 +
include/linux/dma-heap.h | 12 ++--
14 files changed, 197 insertions(+), 62 deletions(-)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] drm-misc-fixes
On Thu, Feb 25, 2021 at 8:53 AM Thomas Zimmermann wrote: > > Hi > > Am 25.02.21 um 02:55 schrieb Dave Airlie: > > On Wed, 24 Feb 2021 at 20:27, Thomas Zimmermann wrote: > >> > >> Hi Dave and Daniel, > >> > >> here's this week's PR for drm-misc-fixes. One of the patches is a memory > >> leak; the rest is for hardware issues. > >> > > > > This is based on 5.11 and I'm not currently in the market for a > > backmege now before rc1 so can you just top this up next week? > > I can, but I think Maxime will take over after -rc1. I think we could also cherry-pick these 3 patches over to Maarten's drm-misc-next-fixes pull. Committers pushing stuff to the wrong branch is kinda normal, it's always a bit tricky around the merge window :-) -Daniel > > Best regards > Thomas > > > > > Though maybe the ttm fix should be fast tracked, will contemplate it. > > > > Dave. > > > >> Best regards > >> Thomas > >> > >> drm-misc-fixes-2021-02-24: > >> * drm/panel: kd35t133: Work with non-continuous DSI clock > >> * drm/rockchip: Require YTR modifier for AFBC > >> * drm/ttm: Fix a memory leak in error handling > >> The following changes since commit > >> f40ddce88593482919761f74910f42f4b84c004b: > >> > >>Linux 5.11 (2021-02-14 14:32:24 -0800) > >> > >> are available in the Git repository at: > >> > >>git://anongit.freedesktop.org/drm/drm-misc > >> tags/drm-misc-fixes-2021-02-24 > >> > >> for you to fetch changes up to 54dab3a718f7094532daf7d25cd14121a0e00e34: > >> > >>drm/panel: kd35t133: allow using non-continuous dsi clock (2021-02-23 > >> 22:44:58 +0100) > >> > >> > >> * drm/panel: kd35t133: Work with non-continuous DSI clock > >> * drm/rockchip: Require YTR modifier for AFBC > >> * drm/ttm: Fix a memory leak in error handling > >> > >> > >> Alyssa Rosenzweig (1): > >>drm/rockchip: Require the YTR modifier for AFBC > >> > >> Heiko Stuebner (1): > >>drm/panel: kd35t133: allow using non-continuous dsi clock > >> > >> xinhui pan (1): > >>drm/ttm: Fix a memory leak > >> > >> drivers/gpu/drm/panel/panel-elida-kd35t133.c | 3 ++- > >> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 11 +++ > >> drivers/gpu/drm/ttm/ttm_bo.c | 9 ++--- > >> 3 files changed, 19 insertions(+), 4 deletions(-) > >> > >> -- > >> Thomas Zimmermann > >> Graphics Driver Developer > >> SUSE Software Solutions Germany GmbH > >> Maxfeldstr. 5, 90409 Nürnberg, Germany > >> (HRB 36809, AG Nürnberg) > >> Geschäftsführer: Felix Imendörffer > > ___ > > dri-devel mailing list > > dri-de...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] drm-misc-fixes
Hi, On Thu, Feb 25, 2021 at 08:53:42AM +0100, Thomas Zimmermann wrote: > Am 25.02.21 um 02:55 schrieb Dave Airlie: > > On Wed, 24 Feb 2021 at 20:27, Thomas Zimmermann wrote: > > > > > > Hi Dave and Daniel, > > > > > > here's this week's PR for drm-misc-fixes. One of the patches is a memory > > > leak; the rest is for hardware issues. > > > > > > > This is based on 5.11 and I'm not currently in the market for a > > backmege now before rc1 so can you just top this up next week? > > I can, but I think Maxime will take over after -rc1. I'm going to handle -next, Maarten will be in charge of -fixes Maxime signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] udldrmfb: causes WARN in i915 on X60 (x86-32)
Hi Am 24.02.21 um 21:09 schrieb Pavel Machek: Hi! This is in -next, but I get same behaviour on 5.11; and no, udl does Thanks for reporting. We are in the process of fixing the issue. The latest patch is at [1]. Best regards Thomas [1] https://lore.kernel.org/dri-devel/b44307cf-25f9-acd0-eb35-92e871620...@suse.de/T/#m74795744a58836dcba055fdcd6a0697811b8c14b not work, but monitor is detected: pavel@amd:~/g/tui/crashled$ xrandr Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096 LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 246mm x 185mm 1024x768 50.00*+ 60.0040.00 800x600 60.3256.25 640x480 59.94 VGA1 disconnected (normal left inverted right x axis y axis) DVI-1-0 connected 1024x768+0+0 304mm x 228mm 1024x768 60.00*+ 75.03 800x600 75.0060.32 640x480 75.0059.94 720x400 70.08 1024x768 (0x45) 65.000MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew0 clock 48.36KHz v: height 768 start 771 end 777 total 806 clock 60.00Hz 800x600 (0x47) 40.000MHz +HSync +VSync h: width 800 start 840 end 968 total 1056 skew0 clock 37.88KHz v: height 600 start 601 end 605 total 628 clock 60.32Hz 640x480 (0x49) 25.175MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew0 clock 31.47KHz v: height 480 start 490 end 492 total 525 clock 59.94Hz pavel@amd:~/g/tui/crashled$ [13957.499755] wlan0: associated [13962.906368] udl 1-5:1.0: [drm] fb1: udldrmfb frame buffer device [13972.585101] [ cut here ] [13972.585117] WARNING: CPU: 0 PID: 3159 at kernel/dma/mapping.c:192 dma_map_sg_attrs+0x38/0x50 [13972.585137] Modules linked in: [13972.585149] CPU: 0 PID: 3159 Comm: Xorg Not tainted 5.11.0-next-20210223+ #176 [13972.585158] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW (2.19 ) 03/31/2011 [13972.585166] EIP: dma_map_sg_attrs+0x38/0x50 [13972.585176] Code: f0 01 00 00 00 74 23 ff 75 0c 53 e8 72 1b 00 00 5a 59 85 c0 78 1c 8b 5d fc c9 c3 8d b4 26 00 00 00 00 0f 0b 8d b6 00 00 00 00 <0f> 0b 31 c0 eb e6 66 90 0f 0b 8d b4 26 00 00 00 00 8d b4 26 00 00 [13972.585186] EAX: c296c41c EBX: ECX: 0055 EDX: dbbc4800 [13972.585194] ESI: c69f9ea0 EDI: d2c313c0 EBP: c5cbdda8 ESP: c5cbdda4 [13972.585202] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210246 [13972.585211] CR0: 80050033 CR2: b6b99000 CR3: 05d42000 CR4: 06b0 [13972.585219] Call Trace: [13972.585227] i915_gem_map_dma_buf+0xee/0x160 [13972.585240] dma_buf_map_attachment+0xb8/0x140 [13972.585251] drm_gem_prime_import_dev.part.0+0x33/0xc0 [13972.585262] ? drm_gem_shmem_create+0x10/0x10 [13972.585271] drm_gem_prime_import_dev+0x22/0x70 [13972.585280] drm_gem_prime_fd_to_handle+0x186/0x1c0 [13972.585289] ? drm_gem_prime_import_dev+0x70/0x70 [13972.585298] ? drm_prime_destroy_file_private+0x20/0x20 [13972.585307] drm_prime_fd_to_handle_ioctl+0x1c/0x30 [13972.585315] drm_ioctl_kernel+0x8e/0xe0 [13972.585325] ? drm_prime_destroy_file_private+0x20/0x20 [13972.585334] drm_ioctl+0x1fd/0x380 [13972.585343] ? drm_prime_destroy_file_private+0x20/0x20 [13972.585352] ? ksys_write+0x5c/0xd0 [13972.585363] ? vfs_write+0xeb/0x3f0 [13972.585371] ? drm_ioctl_kernel+0xe0/0xe0 [13972.585380] __ia32_sys_ioctl+0x369/0x7d0 [13972.585389] ? exit_to_user_mode_prepare+0x4e/0x170 [13972.585398] do_int80_syscall_32+0x2c/0x40 [13972.585409] entry_INT80_32+0x111/0x111 [13972.585419] EIP: 0xb7f68092 [13972.585427] Code: 00 00 00 e9 90 ff ff ff ff a3 24 00 00 00 68 30 00 00 00 e9 80 ff ff ff ff a3 e8 ff ff ff 66 90 00 00 00 00 00 00 00 00 cd 80 8d b4 26 00 00 00 00 8d b6 00 00 00 00 8b 1c 24 c3 8d b4 26 00 [13972.585436] EAX: ffda EBX: 0030 ECX: c00c642e EDX: bfaeda30 [13972.585444] ESI: 00915790 EDI: c00c642e EBP: 0030 ESP: bfaed9e4 [13972.585452] DS: 007b ES: 007b FS: GS: 0033 SS: 007b EFLAGS: 00200296 [13972.585461] ? asm_exc_nmi+0xcc/0x2bc [13972.585470] ---[ end trace 46a21fad0595bc89 ]--- pavel@amd:~/g/tui/crashled$ Any ideas? Best regards, Pavel -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
