dri-devel July 2021

dri-devel@lists.freedesktop.org

321 participants
829 discussions

[Bug 212655] New: AMDGPU crashes when resuming from suspend when amd_iommu=on
by bugzilla-daemon＠bugzilla.kernel.org 02 Sep '21

02 Sep '21

https://bugzilla.kernel.org/show_bug.cgi?id=212655 Bug ID: 212655 Summary: AMDGPU crashes when resuming from suspend when amd_iommu=on Product: Drivers Version: 2.5 Kernel Version: 5.11.10-1 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: fjfcavalcanti(a)gmail.com Regression: No So, my setup is the following: Manjaro Linux on kernel 5.11.10, but also tested on pop OS and it also happens. Mb MSI Tomahawk B450 Ryzen 5 3600 GPU Radeon RX5700 (Powercolor Red Devil) I tried multiple kernels from 5.9 to 5.12 and all had the same issue, if I turn on iommu AMDGPU crashes during resume, and I have to hard-reset the system (I cant reset it using shutdown -r for example) What I see in DMESG after resume is the following: [ 36.492418] amdgpu 0000:28:00.0: amdgpu: failed send message: RunBtc (58) param: 0x00000000 response 0xffffffc2 [ 36.492420] amdgpu 0000:28:00.0: amdgpu: RunBtc failed! [ 36.492421] amdgpu 0000:28:00.0: amdgpu: Failed to setup smc hw! [ 36.492422] [drm:amdgpu_device_ip_resume_phase2 [amdgpu]] *ERROR* resume of IP block <smu> failed -62 [ 36.492515] amdgpu 0000:28:00.0: amdgpu: amdgpu_device_ip_resume failed (-62). [ 36.492516] PM: dpm_run_callback(): pci_pm_resume+0x0/0xe0 returns -62 [ 36.492520] PM: Device 0000:28:00.0 failed to resume async: error -62 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

1 1

linux-next: manual merge of the drm tree with the qcom/for-next tree
by Mark Brown 02 Sep '21

02 Sep '21

Hi all, Today's linux-next merge of the drm tree got a conflict in: drivers/firmware/Makefile between commit: b42000e4b874 ("firmware: qcom_scm: Allow qcom_scm driver to be loadable as a permenent module") from the qcom/for-next tree and commits: 8633ef82f101 ("drivers/firmware: consolidate EFI framebuffer setup for all arches") d391c5827107 ("drivers/firmware: move x86 Generic System Framebuffers support") from the drm tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile index 3c2af2e98def..5ced0673d94b 100644 --- a/drivers/firmware/Makefile +++ b/drivers/firmware/Makefile @@ -19,6 +19,8 @@ obj-$(CONFIG_RASPBERRYPI_FIRMWARE) += raspberrypi.o obj-$(CONFIG_FW_CFG_SYSFS) += qemu_fw_cfg.o obj-$(CONFIG_QCOM_SCM) += qcom-scm.o qcom-scm-objs += qcom_scm.o qcom_scm-smc.o qcom_scm-legacy.o +obj-$(CONFIG_SYSFB) += sysfb.o +obj-$(CONFIG_SYSFB_SIMPLEFB) += sysfb_simplefb.o obj-$(CONFIG_TI_SCI_PROTOCOL) += ti_sci.o obj-$(CONFIG_TRUSTED_FOUNDATIONS) += trusted_foundations.o obj-$(CONFIG_TURRIS_MOX_RWTM) += turris-mox-rwtm.o

2 1

[PATCH] dt-bindings: display: renesas, du: Provide bindings for r8a779a0
by Kieran Bingham 01 Sep '21

01 Sep '21

From: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com> Extend the Renesas DU display bindings to support the r8a779a0 V3U. Signed-off-by: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com> --- .../bindings/display/renesas,du.yaml | 52 +++++++++++++++++++ 1 file changed, 52 insertions(+) diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml index 121596f106da..febbd89a646e 100644 --- a/Documentation/devicetree/bindings/display/renesas,du.yaml +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml @@ -39,6 +39,7 @@ properties: - renesas,du-r8a77980 # for R-Car V3H compatible DU - renesas,du-r8a77990 # for R-Car E3 compatible DU - renesas,du-r8a77995 # for R-Car D3 compatible DU + - renesas,du-r8a779a0 # for R-Car V3U compatible DU reg: maxItems: 1 @@ -774,6 +775,57 @@ allOf: - reset-names - renesas,vsps + - if: + properties: + compatible: + contains: + enum: + - renesas,du-r8a779a0 + then: + properties: + clocks: + items: + - description: Functional clock for DU0 + - description: Functional clock for DU1 + + clock-names: + items: + - const: du.0 + - const: du.1 + + interrupts: + maxItems: 2 + + resets: + maxItems: 1 + + reset-names: + items: + - const: du.0 + + ports: + properties: + port@0: + description: DSI 0 + port@1: + description: DSI 1 + port@2: false + port@3: false + + required: + - port@0 + - port@1 + + renesas,vsps: + minItems: 2 + + required: + - clock-names + - interrupts + - resets + - reset-names + - renesas,vsps + additionalProperties: false examples: -- 2.30.2

3 8

[PATCH 0/8] drm/i915: Migrate memory to SMEM when imported cross-device (v8)
by Jason Ekstrand 01 Sep '21

01 Sep '21

This patch series fixes an issue with discrete graphics on Intel where we allowed dma-buf import while leaving the object in local memory. This breaks down pretty badly if the import happened on a different physical device. v7: - Drop "drm/i915/gem/ttm: Place new BOs in the requested region" - Add a new "drm/i915/gem: Call i915_gem_flush_free_objects() in i915_gem_dumb_create()" - Misc. review feedback from Matthew Auld v8: - Misc. review feedback from Matthew Auld v9: - Replace the i915/ttm patch with two that are hopefully more correct Jason Ekstrand (6): drm/i915/gem: Check object_can_migrate from object_migrate drm/i915/gem: Refactor placement setup for i915_gem_object_create* (v2) drm/i915/gem: Call i915_gem_flush_free_objects() in i915_gem_dumb_create() drm/i915/gem: Unify user object creation (v3) drm/i915/gem/ttm: Only call __i915_gem_object_set_pages if needed drm/i915/gem: Always call obj->ops->migrate unless can_migrate fails Thomas Hellström (2): drm/i915/gem: Correct the locking and pin pattern for dma-buf (v8) drm/i915/gem: Migrate to system at dma-buf attach time (v7) drivers/gpu/drm/i915/gem/i915_gem_create.c | 177 ++++++++-------- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 58 ++++-- drivers/gpu/drm/i915/gem/i915_gem_object.c | 20 +- drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 + drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 13 +- .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 190 +++++++++++++++++- .../drm/i915/gem/selftests/i915_gem_migrate.c | 15 -- 7 files changed, 341 insertions(+), 136 deletions(-) -- 2.31.1

3 16

[PATCH] drm/mipi: set fwnode when a mipi_dsi_device is registered
by Will McVicker 31 Aug '21

31 Aug '21

This allows the fw_devlink feature to work across mipi_dsi bus devices too. This feature avoids unnecessary probe deferrals of mipi_dsi devices, defers consumers of mipi_dsi devices till the mipi_dsi devices probe, and allows mipi_dsi drivers to implement sync_state() callbacks. Suggested-by: Saravana Kannan <saravanak(a)google.com> Signed-off-by: Will McVicker <willmcvicker(a)google.com> Reviewed-by: Saravana Kannan <saravanak(a)google.com> --- drivers/gpu/drm/drm_mipi_dsi.c | 1 + 1 file changed, 1 insertion(+) v2: Thanks Saravana for the comments! I updated the commit message and added your reviewed-by. diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c index 5dd475e82995..469d56cf2a50 100644 --- a/drivers/gpu/drm/drm_mipi_dsi.c +++ b/drivers/gpu/drm/drm_mipi_dsi.c @@ -222,6 +222,7 @@ mipi_dsi_device_register_full(struct mipi_dsi_host *host, } dsi->dev.of_node = info->node; + dsi->dev.fwnode = of_fwnode_handle(info->node); dsi->channel = info->channel; strlcpy(dsi->name, info->type, sizeof(dsi->name)); -- 2.32.0.402.g57bb445576-goog

1 1

[PATCH v7 00/12] Clean up "mediatek,larb"
by Yong Wu 31 Aug '21

31 Aug '21

MediaTek IOMMU block diagram always like below: M4U | smi-common | ------------- | | ... | | larb1 larb2 | | vdec venc All the consumer connect with smi-larb, then connect with smi-common. When the consumer works, it should enable the smi-larb's power which also need enable the smi-common's power firstly. Thus, Firstly, use the device link connect the consumer and the smi-larbs. then add device link between the smi-larb and smi-common. After adding the device_link, then "mediatek,larb" property can be removed. the iommu consumer don't need call the mtk_smi_larb_get/put to enable the power and clock of smi-larb and smi-common. Base on v5.14-rc1, and a jpeg[1] and mdp[2] patchset. [1] https://lore.kernel.org/linux-mediatek/20210702102304.3346429-1-hsinyi@chro… [2] https://lore.kernel.org/linux-mediatek/20210709022324.1607884-1-eizan@chrom… Change notes: v7: 1) Fix a arm32 boot fail issue. reported from Frank. 2) Add a return fail in the mtk drm. suggested by Dafna. v6: https://lore.kernel.org/linux-mediatek/20210714025626.5528-1-yong.wu@mediat… 1) rebase on v5.14-rc1. 2) Fix the issue commented in v5 from Dafna and Hsin-Yi. 3) Remove the patches about using pm_runtime_resume_and_get since they have already been merged by other patches. v5: https://lore.kernel.org/linux-mediatek/20210410091128.31823-1-yong.wu@media… 1) Base v5.12-rc2. 2) Remove changing the mtk-iommu to module_platform_driver patch, It have already been a independent patch. v4: https://lore.kernel.org/linux-mediatek/1590826218-23653-1-git-send-email-yo… base on v5.7-rc1. 1) Move drm PM patch before smi patchs. 2) Change builtin_platform_driver to module_platform_driver since we may need build as module. 3) Rebase many patchset as above. v3: https://lore.kernel.org/linux-iommu/1567503456-24725-1-git-send-email-yong.… 1) rebase on v5.3-rc1 and the latest mt8183 patchset. 2) Use device_is_bound to check whether the driver is ready from Matthias. 3) Add DL_FLAG_STATELESS flag when calling device_link_add and explain the reason in the commit message[3/14]. 4) Add a display patch[12/14] into this series. otherwise it may affect display HW fastlogo even though it don't happen in mt8183. v2: https://lore.kernel.org/linux-iommu/1560171313-28299-1-git-send-email-yong.… 1) rebase on v5.2-rc1. 2) Move adding device_link between the consumer and smi-larb into iommu_add_device from Robin. 3) add DL_FLAG_AUTOREMOVE_CONSUMER even though the smi is built-in from Evan. 4) Remove the shutdown callback in iommu. v1: https://lore.kernel.org/linux-iommu/1546318276-18993-1-git-send-email-yong.… Yong Wu (11): dt-binding: mediatek: Get rid of mediatek,larb for multimedia HW iommu/mediatek-v1: Free the existed fwspec if the master dev already has iommu/mediatek: Add probe_defer for smi-larb iommu/mediatek: Add device_link between the consumer and the larb devices media: mtk-jpeg: Get rid of mtk_smi_larb_get/put media: mtk-mdp: Get rid of mtk_smi_larb_get/put drm/mediatek: Get rid of mtk_smi_larb_get/put media: mtk-vcodec: Get rid of mtk_smi_larb_get/put memory: mtk-smi: Get rid of mtk_smi_larb_get/put arm: dts: mediatek: Get rid of mediatek,larb for MM nodes arm64: dts: mediatek: Get rid of mediatek,larb for MM nodes Yongqiang Niu (1): drm/mediatek: Add pm runtime support for ovl and rdma .../display/mediatek/mediatek,disp.txt | 9 ---- .../bindings/media/mediatek-jpeg-decoder.yaml | 9 ---- .../bindings/media/mediatek-jpeg-encoder.yaml | 9 ---- .../bindings/media/mediatek-mdp.txt | 8 ---- .../bindings/media/mediatek-vcodec.txt | 4 -- arch/arm/boot/dts/mt2701.dtsi | 2 - arch/arm/boot/dts/mt7623n.dtsi | 5 -- arch/arm64/boot/dts/mediatek/mt8173.dtsi | 16 ------- arch/arm64/boot/dts/mediatek/mt8183.dtsi | 6 --- drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 9 +++- drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 9 +++- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 15 +++--- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 36 +-------------- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 - drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +- drivers/iommu/mtk_iommu.c | 24 +++++++++- drivers/iommu/mtk_iommu_v1.c | 31 ++++++++++++- .../media/platform/mtk-jpeg/mtk_jpeg_core.c | 45 +----------------- .../media/platform/mtk-jpeg/mtk_jpeg_core.h | 2 - drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 46 +------------------ drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 2 - drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 1 - .../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 37 ++------------- .../platform/mtk-vcodec/mtk_vcodec_drv.h | 3 -- .../platform/mtk-vcodec/mtk_vcodec_enc.c | 1 - .../platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 44 ++---------------- drivers/memory/mtk-smi.c | 14 ------ include/soc/mediatek/smi.h | 20 -------- 28 files changed, 92 insertions(+), 321 deletions(-) -- 2.18.0

6 19

[PATCH v10 00/11] Move LMEM (VRAM) management over to TTM
by Thomas Hellström 30 Aug '21

30 Aug '21

This is an initial patch series to move discrete memory management over to TTM. It will be followed up shortly with adding more functionality. The buddy allocator is temporarily removed along with its selftests and It is replaced with the TTM range manager and some selftests are adjusted to account for introduced fragmentation. Work is ongoing to reintroduce the buddy allocator as a TTM resource manager. A new memcpy ttm move is introduced that uses kmap_local() functionality rather than vmap(). Among other things stated in the patch commit message it helps us deal with page-pased LMEM memory. It is generic enough to replace the ttm memcpy move with some additional work if so desired. On x86 it also enables prefetching reads from write-combined memory. Finally the old i915 gem object LMEM backend is replaced with a i915 gem object TTM backend and some additional i915 gem object ops are introduced to support the added functionality. Currently it is used only to support management and eviction of the LMEM region, but work is underway to extend the support to system memory. In this way we use TTM the way it was originally intended, having the GPU binding taken care of by driver code. Intention is to follow up with - System memory support - Pipelined accelerated moves / migration - Re-added buddy allocator in the TTM framework v2: - Add patches to move pagefaulting over to TTM - Break out TTM changes to separate patches - Address various review comments as detailed in the affected patches v3: - Drop TTM pagefaulting patches for now due changing approach due to a NAK. - Address feedback on TTM patches - Move the new TTM memcpy functionality into TTM. - Move fast WC memcpy to drm - Various fixes all over the place as shown in patch commit messages. v4: - Re-add TTM pagefaulting patches. - Addressed review feedback mainly from Matthew Auld - Fixed the mock ttm device code that was using an incorrect approach. v5: - Cleanups in the TTM pagefaulting patches. - Just add the WC memcpy to DRM without removing from i915 (Suggested by Daniel Vetter). - Various minor fixes as reported in patch log messages. v6: - Fix a merge conflict causing build error. v7: - Fix the WC memcpy compilation and perform a fallback memcpy in addition to warning in interrupt (Suggested by Christian König) - Renistate check for ttm_tt_is_populated() on swapout. v8: - Added a couple of acks and r-bs - pgoff_t -> u32 in interface of ttm_move_memcpy. - Fix missing export in !X86 WC memcpy. v9: - Fix a NULL pointer deref if bo->ttm == NULL v10: - Fix a kerneldoc title underline Cc: Christian König <christian.koenig(a)amd.com> Maarten Lankhorst (2): drm/vma: Add a driver_private member to vma_node. drm/i915: Use ttm mmap handling for ttm bo's. Thomas Hellström (9): drm/i915/ttm Initialize the ttm device and memory managers drm/i915/ttm: Embed a ttm buffer object in the i915 gem object drm/ttm: Add a generic TTM memcpy move for page-based iomem drm: Add a prefetching memcpy_from_wc drm/ttm: Use drm_memcpy_from_wc for TTM bo moves drm/ttm: Document and optimize ttm_bo_pipeline_gutting() drm/ttm, drm/amdgpu: Allow the driver some control over swapping drm/i915/ttm: Introduce a TTM i915 gem object backend drm/i915/lmem: Verify checks for lmem residency Documentation/gpu/drm-mm.rst | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 + drivers/gpu/drm/drm_cache.c | 148 ++++ drivers/gpu/drm/drm_drv.c | 2 + drivers/gpu/drm/drm_gem.c | 9 - drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/Makefile | 3 +- drivers/gpu/drm/i915/display/intel_display.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_create.c | 9 +- drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 71 +- drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 5 - drivers/gpu/drm/i915/gem/i915_gem_mman.c | 83 +- drivers/gpu/drm/i915/gem/i915_gem_object.c | 150 +++- drivers/gpu/drm/i915/gem/i915_gem_object.h | 19 +- .../gpu/drm/i915/gem/i915_gem_object_types.h | 48 +- drivers/gpu/drm/i915/gem/i915_gem_pages.c | 6 +- drivers/gpu/drm/i915/gem/i915_gem_region.c | 126 +-- drivers/gpu/drm/i915/gem/i915_gem_region.h | 4 - drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 4 +- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 10 +- drivers/gpu/drm/i915/gem/i915_gem_stolen.h | 9 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 647 ++++++++++++++ drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 48 ++ .../drm/i915/gem/selftests/i915_gem_mman.c | 90 +- drivers/gpu/drm/i915/gt/intel_gt.c | 2 - drivers/gpu/drm/i915/gt/intel_region_lmem.c | 30 +- drivers/gpu/drm/i915/i915_buddy.c | 435 ---------- drivers/gpu/drm/i915/i915_buddy.h | 131 --- drivers/gpu/drm/i915/i915_drv.c | 8 + drivers/gpu/drm/i915/i915_drv.h | 8 +- drivers/gpu/drm/i915/i915_gem.c | 6 +- drivers/gpu/drm/i915/i915_globals.c | 1 - drivers/gpu/drm/i915/i915_globals.h | 1 - drivers/gpu/drm/i915/i915_scatterlist.c | 70 ++ drivers/gpu/drm/i915/i915_scatterlist.h | 4 + drivers/gpu/drm/i915/intel_memory_region.c | 181 ++-- drivers/gpu/drm/i915/intel_memory_region.h | 45 +- drivers/gpu/drm/i915/intel_region_ttm.c | 220 +++++ drivers/gpu/drm/i915/intel_region_ttm.h | 37 + drivers/gpu/drm/i915/selftests/i915_buddy.c | 789 ------------------ .../drm/i915/selftests/i915_mock_selftests.h | 1 - drivers/gpu/drm/i915/selftests/igt_mmap.c | 25 +- drivers/gpu/drm/i915/selftests/igt_mmap.h | 12 +- .../drm/i915/selftests/intel_memory_region.c | 133 +-- .../gpu/drm/i915/selftests/mock_gem_device.c | 10 + drivers/gpu/drm/i915/selftests/mock_region.c | 70 +- drivers/gpu/drm/ttm/ttm_bo.c | 66 +- drivers/gpu/drm/ttm/ttm_bo_util.c | 320 +++---- drivers/gpu/drm/ttm/ttm_module.c | 35 + drivers/gpu/drm/ttm/ttm_resource.c | 193 +++++ drivers/gpu/drm/ttm/ttm_tt.c | 45 + include/drm/drm_cache.h | 7 + include/drm/drm_vma_manager.h | 2 +- include/drm/ttm/ttm_bo_driver.h | 28 + include/drm/ttm/ttm_caching.h | 2 + include/drm/ttm/ttm_kmap_iter.h | 61 ++ include/drm/ttm/ttm_resource.h | 61 ++ include/drm/ttm/ttm_tt.h | 29 + 58 files changed, 2416 insertions(+), 2154 deletions(-) create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm.c create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm.h delete mode 100644 drivers/gpu/drm/i915/i915_buddy.c delete mode 100644 drivers/gpu/drm/i915/i915_buddy.h create mode 100644 drivers/gpu/drm/i915/intel_region_ttm.c create mode 100644 drivers/gpu/drm/i915/intel_region_ttm.h delete mode 100644 drivers/gpu/drm/i915/selftests/i915_buddy.c create mode 100644 include/drm/ttm/ttm_kmap_iter.h -- 2.31.1

3 15

[PATCH v15 00/12] Restricted DMA
by Claire Chang 27 Aug '21

27 Aug '21

This series implements mitigations for lack of DMA access control on systems without an IOMMU, which could result in the DMA accessing the system memory at unexpected times and/or unexpected addresses, possibly leading to data leakage or corruption. For example, we plan to use the PCI-e bus for Wi-Fi and that PCI-e bus is not behind an IOMMU. As PCI-e, by design, gives the device full access to system memory, a vulnerability in the Wi-Fi firmware could easily escalate to a full system exploit (remote wifi exploits: [1a], [1b] that shows a full chain of exploits; [2], [3]). To mitigate the security concerns, we introduce restricted DMA. Restricted DMA utilizes the existing swiotlb to bounce streaming DMA in and out of a specially allocated region and does memory allocation from the same region. The feature on its own provides a basic level of protection against the DMA overwriting buffer contents at unexpected times. However, to protect against general data leakage and system memory corruption, the system needs to provide a way to restrict the DMA to a predefined memory region (this is usually done at firmware level, e.g. MPU in ATF on some ARM platforms [4]). [1a] https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcom… [1b] https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcom… [2] https://blade.tencent.com/en/advisories/qualpwn/ [3] https://www.bleepingcomputer.com/news/security/vulnerabilities-found-in-hig… [4] https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/media… v15: - Apply Will's diff (https://lore.kernel.org/patchwork/patch/1448957/#1647521) to fix the crash reported by Qian. - Add Stefano's Acked-by tag for patch 01/12 from v14 v14: - Move set_memory_decrypted before swiotlb_init_io_tlb_mem (patch 01/12, 10,12) - Add Stefano's Acked-by tag from v13 https://lore.kernel.org/patchwork/cover/1448954/ v13: - Fix xen-swiotlb issues - memset in patch 01/12 - is_swiotlb_force_bounce in patch 06/12 - Fix the dts example typo in reserved-memory.txt - Add Stefano and Will's Tested-by tag from v12 https://lore.kernel.org/patchwork/cover/1448001/ v12: Split is_dev_swiotlb_force into is_swiotlb_force_bounce (patch 06/12) and is_swiotlb_for_alloc (patch 09/12) https://lore.kernel.org/patchwork/cover/1447254/ v11: - Rebase against swiotlb devel/for-linus-5.14 - s/mempry/memory/g - exchange the order of patch 09/12 and 10/12 https://lore.kernel.org/patchwork/cover/1447216/ v10: Address the comments in v9 to - fix the dev->dma_io_tlb_mem assignment - propagate swiotlb_force setting into io_tlb_default_mem->force - move set_memory_decrypted out of swiotlb_init_io_tlb_mem - move debugfs_dir declaration into the main CONFIG_DEBUG_FS block - add swiotlb_ prefix to find_slots and release_slots - merge the 3 alloc/free related patches - move the CONFIG_DMA_RESTRICTED_POOL later https://lore.kernel.org/patchwork/cover/1446882/ v9: Address the comments in v7 to - set swiotlb active pool to dev->dma_io_tlb_mem - get rid of get_io_tlb_mem - dig out the device struct for is_swiotlb_active - move debugfs_create_dir out of swiotlb_create_debugfs - do set_memory_decrypted conditionally in swiotlb_init_io_tlb_mem - use IS_ENABLED in kernel/dma/direct.c - fix redefinition of 'of_dma_set_restricted_buffer' https://lore.kernel.org/patchwork/cover/1445081/ v8: - Fix reserved-memory.txt and add the reg property in example. - Fix sizeof for of_property_count_elems_of_size in drivers/of/address.c#of_dma_set_restricted_buffer. - Apply Will's suggestion to try the OF node having DMA configuration in drivers/of/address.c#of_dma_set_restricted_buffer. - Fix typo in the comment of drivers/of/address.c#of_dma_set_restricted_buffer. - Add error message for PageHighMem in kernel/dma/swiotlb.c#rmem_swiotlb_device_init and move it to rmem_swiotlb_setup. - Fix the message string in rmem_swiotlb_setup. https://lore.kernel.org/patchwork/cover/1437112/ v7: Fix debugfs, PageHighMem and comment style in rmem_swiotlb_device_init https://lore.kernel.org/patchwork/cover/1431031/ v6: Address the comments in v5 https://lore.kernel.org/patchwork/cover/1423201/ v5: Rebase on latest linux-next https://lore.kernel.org/patchwork/cover/1416899/ v4: - Fix spinlock bad magic - Use rmem->name for debugfs entry - Address the comments in v3 https://lore.kernel.org/patchwork/cover/1378113/ v3: Using only one reserved memory region for both streaming DMA and memory allocation. https://lore.kernel.org/patchwork/cover/1360992/ v2: Building on top of swiotlb. https://lore.kernel.org/patchwork/cover/1280705/ v1: Using dma_map_ops. https://lore.kernel.org/patchwork/cover/1271660/ Claire Chang (12): swiotlb: Refactor swiotlb init functions swiotlb: Refactor swiotlb_create_debugfs swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used swiotlb: Update is_swiotlb_buffer to add a struct device argument swiotlb: Update is_swiotlb_active to add a struct device argument swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing swiotlb: Move alloc_size to swiotlb_find_slots swiotlb: Refactor swiotlb_tbl_unmap_single swiotlb: Add restricted DMA alloc/free support swiotlb: Add restricted DMA pool initialization dt-bindings: of: Add restricted DMA pool of: Add plumbing for restricted DMA pool .../reserved-memory/reserved-memory.txt | 36 ++- drivers/base/core.c | 4 + drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +- drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +- drivers/iommu/dma-iommu.c | 12 +- drivers/of/address.c | 33 +++ drivers/of/device.c | 3 + drivers/of/of_private.h | 6 + drivers/pci/xen-pcifront.c | 2 +- drivers/xen/swiotlb-xen.c | 4 +- include/linux/device.h | 4 + include/linux/swiotlb.h | 53 +++- kernel/dma/Kconfig | 14 + kernel/dma/direct.c | 59 ++-- kernel/dma/direct.h | 8 +- kernel/dma/swiotlb.c | 251 +++++++++++++----- 16 files changed, 390 insertions(+), 103 deletions(-) -- 2.32.0.288.g62a8d224e6-goog

7 34

[PATCH 1/5] drm/vmwgfx: unbind in vmw_ttm_unpopulate
by Christian König 26 Aug '21

26 Aug '21

Doing this in vmw_ttm_destroy() is to late. It turned out that this is not a good idea at all because it leaves pointers to freed up system memory pages in the GART tables of the drivers. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c index b0973c27e774..904031d03dbe 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c @@ -526,14 +526,9 @@ static void vmw_ttm_destroy(struct ttm_device *bdev, struct ttm_tt *ttm) struct vmw_ttm_tt *vmw_be = container_of(ttm, struct vmw_ttm_tt, dma_ttm); - vmw_ttm_unbind(bdev, ttm); ttm_tt_destroy_common(bdev, ttm); vmw_ttm_unmap_dma(vmw_be); - if (vmw_be->dev_priv->map_mode == vmw_dma_alloc_coherent) - ttm_tt_fini(&vmw_be->dma_ttm); - else - ttm_tt_fini(ttm); - + ttm_tt_fini(ttm); if (vmw_be->mob) vmw_mob_destroy(vmw_be->mob); @@ -578,6 +573,8 @@ static void vmw_ttm_unpopulate(struct ttm_device *bdev, dma_ttm); unsigned int i; + vmw_ttm_unbind(bdev, ttm); + if (vmw_tt->mob) { vmw_mob_destroy(vmw_tt->mob); vmw_tt->mob = NULL; -- 2.25.1

3 9

[PATCH] dma-heap: Let dma heap use dma_map_attrs to map & unmap iova
by guangming.cao＠mediatek.com 26 Aug '21

26 Aug '21

From: Guangming Cao <Guangming.Cao(a)mediatek.com> For dma-heap users, they can't bypass cache sync when map/unmap iova with dma heap. But they can do it by adding DMA_ATTR_SKIP_CPU_SYNC into dma_alloc_attrs. To keep alignment, at dma_heap side, also use dma_buf_attachment.dma_map_attrs to do iova map & unmap. Signed-off-by: Guangming Cao <Guangming.Cao(a)mediatek.com> --- drivers/dma-buf/heaps/cma_heap.c | 6 ++++-- drivers/dma-buf/heaps/system_heap.c | 6 ++++-- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c index 0c05b79870f9..2c9feb3bfc3e 100644 --- a/drivers/dma-buf/heaps/cma_heap.c +++ b/drivers/dma-buf/heaps/cma_heap.c @@ -99,9 +99,10 @@ static struct sg_table *cma_heap_map_dma_buf(struct dma_buf_attachment *attachme { struct dma_heap_attachment *a = attachment->priv; struct sg_table *table = &a->table; + int attrs = attachment->dma_map_attrs; int ret; - ret = dma_map_sgtable(attachment->dev, table, direction, 0); + ret = dma_map_sgtable(attachment->dev, table, direction, attrs); if (ret) return ERR_PTR(-ENOMEM); a->mapped = true; @@ -113,9 +114,10 @@ static void cma_heap_unmap_dma_buf(struct dma_buf_attachment *attachment, enum dma_data_direction direction) { struct dma_heap_attachment *a = attachment->priv; + int attrs = attachment->dma_map_attrs; a->mapped = false; - dma_unmap_sgtable(attachment->dev, table, direction, 0); + dma_unmap_sgtable(attachment->dev, table, direction, attrs); } static int cma_heap_dma_buf_begin_cpu_access(struct dma_buf *dmabuf, diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c index 23a7e74ef966..fc7b1e02988e 100644 --- a/drivers/dma-buf/heaps/system_heap.c +++ b/drivers/dma-buf/heaps/system_heap.c @@ -130,9 +130,10 @@ static struct sg_table *system_heap_map_dma_buf(struct dma_buf_attachment *attac { struct dma_heap_attachment *a = attachment->priv; struct sg_table *table = a->table; + int attrs = attachment->dma_map_attrs; int ret; - ret = dma_map_sgtable(attachment->dev, table, direction, 0); + ret = dma_map_sgtable(attachment->dev, table, direction, attrs); if (ret) return ERR_PTR(ret); @@ -145,9 +146,10 @@ static void system_heap_unmap_dma_buf(struct dma_buf_attachment *attachment, enum dma_data_direction direction) { struct dma_heap_attachment *a = attachment->priv; + int attrs = attachment->dma_map_attrs; a->mapped = false; - dma_unmap_sgtable(attachment->dev, table, direction, 0); + dma_unmap_sgtable(attachment->dev, table, direction, attrs); } static int system_heap_dma_buf_begin_cpu_access(struct dma_buf *dmabuf, -- 2.17.1

1 4

← Newer
1
...
10
11
12
13
14
15
16
...
83
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2021