dri-devel April 2021

dri-devel@lists.freedesktop.org

317 participants
715 discussions

[PATCH v2 00/10] Implement multi-GPU DMA mappings for KFD
by Felix Kuehling 10 May '21

10 May '21

This patch series fixes DMA-mappings of system memory (GTT and userptr) for KFD running on multi-GPU systems with IOMMU enabled. One SG-BO per GPU is needed to maintain the DMA mappings of each BO. Changes in v2: - Made the original BO parent of the SG BO to fix bo destruction order - Removed individualiation hack that is, not needed with parent BO - Removed resv locking hace in amdgpu_ttm_unpopulate, not needed without the individualization hack - Added a patch to enable the Intel IOMMU driver in rock-dbg_defconfig - Added a patch to move dmabuf attach/detach into backend_(un)bind I'm still seeing some IOMMU access faults in the eviction test. They seem to be related to userptr handling. They happen even without this patch series on a single-GPU system, where this patch series is not needed. I believe this is an old problem in KFD or amdgpu that is being exposed by device isolation from the IOMMU. I'm debugging it, but it should not hold up this patch series. "drm/ttm: Don't count pages in SG BOs against pages_limit" was already applied to drm-misc (I think). I'm still including it here because my patches depend on it. Without that, the SG BOs created for DMA mappings cause many tests fail because TTM incorrectly thinks it's out of memory. Felix Kuehling (10): rock-dbg_defconfig: Enable Intel IOMMU drm/amdgpu: Rename kfd_bo_va_list to kfd_mem_attachment drm/amdgpu: Keep a bo-reference per-attachment drm/amdgpu: Simplify AQL queue mapping drm/amdgpu: Add multi-GPU DMA mapping helpers drm/amdgpu: DMA map/unmap when updating GPU mappings drm/amdgpu: Move kfd_mem_attach outside reservation drm/amdgpu: Add DMA mapping of GTT BOs drm/ttm: Don't count pages in SG BOs against pages_limit drm/amdgpu: Move dmabuf attach/detach to backend_(un)bind arch/x86/configs/rock-dbg_defconfig | 11 +- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 18 +- .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 530 ++++++++++++------ drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 51 +- drivers/gpu/drm/ttm/ttm_tt.c | 27 +- 5 files changed, 437 insertions(+), 200 deletions(-) -- 2.31.1

5 31

[PATCH 1/3] drm/exynos: Init the DSIM PHY in samsung_dsim_enable()
by Marek Vasut 10 May '21

10 May '21

In case the PHY is not initialized, do it in samsung_dsim_enable(), otherwise the link configuration registers are not programmed at all. Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: Fabio Estevam <festevam(a)gmail.com> Cc: Guido Günther <agx(a)sigxcpu.org> Cc: Jaehoon Chung <jh80.chung(a)samsung.com> Cc: Lucas Stach <l.stach(a)pengutronix.de> Cc: Marek Szyprowski <m.szyprowski(a)samsung.com> Cc: Michael Tretter <m.tretter(a)pengutronix.de> Cc: NXP Linux Team <linux-imx(a)nxp.com> Cc: Shawn Guo <shawnguo(a)kernel.org> Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-samsung-soc(a)vger.kernel.org To: dri-devel(a)lists.freedesktop.org -- NOTE: This depends on https://patchwork.kernel.org/project/dri-devel/list/?series=347439 --- drivers/gpu/drm/bridge/samsung-dsim.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c index 6d2d8dc027de..fbd87a74eb9f 100644 --- a/drivers/gpu/drm/bridge/samsung-dsim.c +++ b/drivers/gpu/drm/bridge/samsung-dsim.c @@ -1244,6 +1244,13 @@ static void samsung_dsim_enable(struct samsung_dsim *dsi) pm_runtime_get_sync(dsi->dev); dsi->state |= DSIM_STATE_ENABLED; + if (!(dsi->state & DSIM_STATE_INITIALIZED)) { + ret = samsung_dsim_init(dsi); + if (ret) + return; + dsi->state |= DSIM_STATE_INITIALIZED; + } + if (dsi->panel) { ret = drm_panel_prepare(dsi->panel); if (ret < 0) -- 2.28.0

5 6

[RFC PATCH 0/9] cgroup support for GPU devices
by Brian Welty 10 May '21

10 May '21

We'd like to revisit the proposal of a GPU cgroup controller for managing GPU devices but with just a basic set of controls. This series is based on the prior patch series from Kenny Ho [1]. We take Kenny's base patches which implement the basic framework for the controller, but we propose an alternate set of control files. Here we've taken a subset of the controls proposed in earlier discussion on ML here [2]. This series proposes a set of device memory controls (gpu.memory.current, gpu.memory.max, and gpu.memory.total) and accounting of GPU time usage (gpu.sched.runtime). GPU time sharing controls are left as future work. These are implemented within the GPU controller along with integration/usage of the device memory controls by the i915 device driver. As an accelerator or GPU device is similar in many respects to a CPU with (or without) attached system memory, the basic principle here is try to copy the semantics of existing controls from other controllers when possible and where these controls serve the same underlying purpose. For example, the memory.max and memory.current controls are based on same controls from MEMCG controller. Following with the implementation used by the existing RDMA controller, here we introduce a general purpose drm_cgroup_try_charge and uncharge pair of exported functions. These functions are to be used for charging and uncharging all current and future DRM resource controls. Patches 1 - 4 are part original work and part refactoring of the prior work from Kenny Ho from his series for GPU / DRM controller v2 [1]. Patches 5 - 7 introduce new controls to the GPU / DRM controller for device memory accounting and GPU time tracking. Patch 8 introduces DRM support for associating GEM objects with a cgroup. Patch 9 implements i915 changes to use cgroups for device memory charging and enforcing device memory allocation limit. [1] https://lists.freedesktop.org/archives/dri-devel/2020-February/257052.html [2] https://lists.freedesktop.org/archives/dri-devel/2019-November/242599.html Brian Welty (6): drmcg: Add skeleton seq_show and write for drmcg files drmcg: Add support for device memory accounting via page counter drmcg: Add memory.total file drmcg: Add initial support for tracking gpu time usage drm/gem: Associate GEM objects with drm cgroup drm/i915: Use memory cgroup for enforcing device memory limit Kenny Ho (3): cgroup: Introduce cgroup for drm subsystem drm, cgroup: Bind drm and cgroup subsystem drm, cgroup: Initialize drmcg properties Documentation/admin-guide/cgroup-v2.rst | 58 ++- Documentation/cgroup-v1/drm.rst | 1 + drivers/gpu/drm/drm_drv.c | 11 + drivers/gpu/drm/drm_gem.c | 89 ++++ drivers/gpu/drm/i915/gem/i915_gem_mman.c | 1 + drivers/gpu/drm/i915/gem/i915_gem_region.c | 23 +- drivers/gpu/drm/i915/intel_memory_region.c | 13 +- drivers/gpu/drm/i915/intel_memory_region.h | 2 +- include/drm/drm_cgroup.h | 85 ++++ include/drm/drm_device.h | 7 + include/drm/drm_gem.h | 17 + include/linux/cgroup_drm.h | 113 +++++ include/linux/cgroup_subsys.h | 4 + init/Kconfig | 5 + kernel/cgroup/Makefile | 1 + kernel/cgroup/drm.c | 533 +++++++++++++++++++++ 16 files changed, 954 insertions(+), 9 deletions(-) create mode 100644 Documentation/cgroup-v1/drm.rst create mode 100644 include/drm/drm_cgroup.h create mode 100644 include/linux/cgroup_drm.h create mode 100644 kernel/cgroup/drm.c -- 2.20.1

6 25

[PATCH v5 00/27] RFC Support hot device unplug in amdgpu
by Andrey Grodzovsky 10 May '21

10 May '21

Until now extracting a card either by physical extraction (e.g. eGPU with thunderbolt connection or by emulation through syfs -> /sys/bus/pci/devices/device_id/remove) would cause random crashes in user apps. The random crashes in apps were mostly due to the app having mapped a device backed BO into its address space was still trying to access the BO while the backing device was gone. To answer this first problem Christian suggested to fix the handling of mapped memory in the clients when the device goes away by forcibly unmap all buffers the user processes has by clearing their respective VMAs mapping the device BOs. Then when the VMAs try to fill in the page tables again we check in the fault handlerif the device is removed and if so, return an error. This will generate a SIGBUS to the application which can then cleanly terminate.This indeed was done but this in turn created a problem of kernel OOPs were the OOPSes were due to the fact that while the app was terminating because of the SIGBUSit would trigger use after free in the driver by calling to accesses device structures that were already released from the pci remove sequence.This was handled by introducing a 'flush' sequence during device removal were we wait for drm file reference to drop to 0 meaning all user clients directly using this device terminated. v2: Based on discussions in the mailing list with Daniel and Pekka [1] and based on the document produced by Pekka from those discussions [2] the whole approach with returning SIGBUS and waiting for all user clients having CPU mapping of device BOs to die was dropped. Instead as per the document suggestion the device structures are kept alive until the last reference to the device is dropped by user client and in the meanwhile all existing and new CPU mappings of the BOs belonging to the device directly or by dma-buf import are rerouted to per user process dummy rw page.Also, I skipped the 'Requirements for KMS UAPI' section of [2] since i am trying to get the minimal set of requirements that still give useful solution to work and this is the'Requirements for Render and Cross-Device UAPI' section and so my test case is removing a secondary device, which is render only and is not involved in KMS. v3: More updates following comments from v2 such as removing loop to find DRM file when rerouting page faults to dummy page,getting rid of unnecessary sysfs handling refactoring and moving prevention of GPU recovery post device unplug from amdgpu to scheduler layer. On top of that added unplug support for the IOMMU enabled system. v4: Drop last sysfs hack and use sysfs default attribute. Guard against write accesses after device removal to avoid modifying released memory. Update dummy pages handling to on demand allocation and release through drm managed framework. Add return value to scheduler job TO handler (by Luben Tuikov) and use this in amdgpu for prevention of GPU recovery post device unplug Also rebase on top of drm-misc-mext instead of amd-staging-drm-next v5: The most significant in this series is the improved protection from kernel driver accessing MMIO ranges that were allocated for the device once the device is gone. To do this, first a patch 'drm/amdgpu: Unmap all MMIO mappings' is introduced. This patch unamps all MMIO mapped into the kernel address space in the form of BARs and kernel BOs with CPU visible VRAM mappings. This way it helped to discover multiple such access points because a page fault would be immediately generated on access. Most of them were solved by moving HW fini code into pci_remove stage (patch drm/amdgpu: Add early fini callback) and for some who were harder to unwind drm_dev_enter/exit scoping was used. In addition all the IOCTLs and all background work and timers are now protected with drm_dev_enter/exit at their root in an attempt that after drm_dev_unplug is finished none of them run anymore and the pci_remove thread is the only thread executing which might touch the HW. To prevent deadlocks in such case against threads stuck on various HW or SW fences patches 'drm/amdgpu: Finalise device fences on device remove' and drm/amdgpu: Add rw_sem to pushing job into sched queue' take care of force signaling all such existing fences and rejecting any newly added ones. With these patches I am able to gracefully remove the secondary card using sysfs remove hook while glxgears is running off of secondary card (DRI_PRIME=1) without kernel oopses or hangs and keep working with the primary card or soft reset the device without hangs or oopses. Also as per Daniel's comment I added 3 tests to IGT [4] to core_hotunplug test suite - remove device while commands are submitted, exported BO and exported fence (not pushed yet). Also now it's possible to plug back the device after unplug Also some users now can successfully use those patches with eGPU boxes[3]. TODOs for followup work: Convert AMDGPU code to use devm (for hw stuff) and drmm (for sw stuff and allocations) (Daniel) Add support for 'Requirements for KMS UAPI' section of [2] - unplugging primary, display connected card. [1] - Discussions during v4 of the patchset https://lists.freedesktop.org/archives/amd-gfx/2021-January/058595.html [2] - drm/doc: device hot-unplug for userspace https://www.spinics.net/lists/dri-devel/msg259755.html [3] - Related gitlab ticket https://gitlab.freedesktop.org/drm/amd/-/issues/1081 [4] - https://gitlab.freedesktop.org/agrodzov/igt-gpu-tools/-/commits/master Andrey Grodzovsky (27): drm/ttm: Remap all page faults to per process dummy page. drm/ttm: Expose ttm_tt_unpopulate for driver use drm/amdgpu: Split amdgpu_device_fini into early and late drm/amdkfd: Split kfd suspend from devie exit drm/amdgpu: Add early fini callback drm/amdgpu: Handle IOMMU enabled case. drm/amdgpu: Remap all page faults to per process dummy page. PCI: add support for dev_groups to struct pci_device_driver dmr/amdgpu: Move some sysfs attrs creation to default_attr drm/amdgpu: Guard against write accesses after device removal drm/sched: Make timeout timer rearm conditional. drm/amdgpu: Prevent any job recoveries after device is unplugged. drm/amdgpu: When filizing the fence driver. stop scheduler first. drm/amdgpu: Fix hang on device removal. drm/scheduler: Fix hang when sched_entity released drm/amdgpu: Unmap all MMIO mappings drm/amdgpu: Add rw_sem to pushing job into sched queue drm/sched: Expose drm_sched_entity_kill_jobs drm/amdgpu: Finilise device fences on device remove. drm: Scope all DRM IOCTLs with drm_dev_enter/exit drm/amdgpu: Add support for hot-unplug feature at DRM level. drm/amd/display: Scope all DM queued work with drm_dev_enter/exit drm/amd/powerplay: Scope all PM queued work with drm_dev_enter/exit drm/amdkfd: Scope all KFD queued work with drm_dev_enter/exit drm/amdgpu: Scope all amdgpu queued work with drm_dev_enter/exit drm/amd/display: Remove superflous drm_mode_config_cleanup drm/amdgpu: Verify DMA opearations from device are done drivers/gpu/drm/amd/amdgpu/amdgpu.h | 18 +- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 13 +- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 17 +- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 13 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 353 ++++++++++++++---- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 34 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 34 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 9 + drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 25 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 228 +++++------ drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 61 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 33 +- drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c | 28 +- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 12 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 41 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 7 + drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 115 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 3 + drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 56 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 70 ++++ drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 52 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 21 +- drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 74 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 45 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 83 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 7 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 14 +- drivers/gpu/drm/amd/amdgpu/cik_ih.c | 3 +- drivers/gpu/drm/amd/amdgpu/cz_ih.c | 3 +- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 10 +- drivers/gpu/drm/amd/amdgpu/iceland_ih.c | 3 +- drivers/gpu/drm/amd/amdgpu/navi10_ih.c | 5 +- drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 44 +-- drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 8 +- drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 8 +- drivers/gpu/drm/amd/amdgpu/si_ih.c | 3 +- drivers/gpu/drm/amd/amdgpu/tonga_ih.c | 3 +- drivers/gpu/drm/amd/amdgpu/vce_v4_0.c | 26 +- drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 22 +- drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 5 +- drivers/gpu/drm/amd/amdgpu/vega20_ih.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_device.c | 3 +- drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c | 14 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 +- .../amd/display/amdgpu_dm/amdgpu_dm_hdcp.c | 124 +++--- .../drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 24 +- drivers/gpu/drm/amd/include/amd_shared.h | 2 + drivers/gpu/drm/amd/pm/amdgpu_dpm.c | 44 ++- .../drm/amd/pm/powerplay/smumgr/smu7_smumgr.c | 2 + drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 26 +- drivers/gpu/drm/drm_ioctl.c | 15 +- drivers/gpu/drm/scheduler/sched_entity.c | 6 +- drivers/gpu/drm/scheduler/sched_main.c | 35 +- drivers/gpu/drm/ttm/ttm_bo_vm.c | 79 +++- drivers/gpu/drm/ttm/ttm_tt.c | 1 + drivers/pci/pci-driver.c | 1 + include/drm/drm_drv.h | 6 + include/drm/gpu_scheduler.h | 1 + include/drm/ttm/ttm_bo_api.h | 2 + include/linux/pci.h | 3 + 64 files changed, 1388 insertions(+), 633 deletions(-) -- 2.25.1

8 81

[PATCH] drm/panel: s6e63m0: Depromote debug prints
by Linus Walleij 10 May '21

10 May '21

The dev_info():s in the DSI driver are very talkative, depromote these to dev_dbg(). Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> --- drivers/gpu/drm/panel/panel-samsung-s6e63m0-dsi.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63m0-dsi.c b/drivers/gpu/drm/panel/panel-samsung-s6e63m0-dsi.c index eec74c10ddda..bf0f4b4f1d20 100644 --- a/drivers/gpu/drm/panel/panel-samsung-s6e63m0-dsi.c +++ b/drivers/gpu/drm/panel/panel-samsung-s6e63m0-dsi.c @@ -27,7 +27,7 @@ static int s6e63m0_dsi_dcs_read(struct device *dev, const u8 cmd, u8 *data) return ret; } - dev_info(dev, "DSI read CMD %02x = %02x\n", cmd, *data); + dev_dbg(dev, "DSI read CMD %02x = %02x\n", cmd, *data); return 0; } @@ -42,7 +42,7 @@ static int s6e63m0_dsi_dcs_write(struct device *dev, const u8 *data, size_t len) int chunk; int ret; - dev_info(dev, "DSI writing dcs seq: %*ph\n", (int)len, data); + dev_dbg(dev, "DSI writing dcs seq: %*ph\n", (int)len, data); /* Pick out and skip past the DCS command */ cmd = *seqp; @@ -80,7 +80,7 @@ static int s6e63m0_dsi_dcs_write(struct device *dev, const u8 *data, size_t len) cmdwritten += chunk; seqp += chunk; } - dev_info(dev, "sent command %02x %02x bytes\n", cmd, cmdwritten); + dev_dbg(dev, "sent command %02x %02x bytes\n", cmd, cmdwritten); usleep_range(8000, 9000); -- 2.29.2

2 2

[PATCH v5 00/16] Restricted DMA
by Claire Chang 10 May '21

10 May '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… v5: Rebase on latest linux-next v4: - Fix spinlock bad magic - Use rmem->name for debugfs entry - Address the comments in v3 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 (16): swiotlb: Fix the type of index swiotlb: Refactor swiotlb init functions swiotlb: Refactor swiotlb_create_debugfs swiotlb: Add DMA_RESTRICTED_POOL swiotlb: Add restricted DMA pool initialization swiotlb: Add a new get_io_tlb_mem getter swiotlb: Update is_swiotlb_buffer to add a struct device argument swiotlb: Update is_swiotlb_active to add a struct device argument swiotlb: Bounce data from/to restricted DMA pool if available swiotlb: Move alloc_size to find_slots swiotlb: Refactor swiotlb_tbl_unmap_single dma-direct: Add a new wrapper __dma_direct_free_pages() swiotlb: Add restricted DMA alloc/free support. dma-direct: Allocate memory from restricted DMA pool if available dt-bindings: of: Add restricted DMA pool of: Add plumbing for restricted DMA pool .../reserved-memory/reserved-memory.txt | 24 ++ 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 | 25 ++ drivers/of/device.c | 3 + drivers/of/of_private.h | 5 + drivers/pci/xen-pcifront.c | 2 +- drivers/xen/swiotlb-xen.c | 2 +- include/linux/device.h | 4 + include/linux/swiotlb.h | 41 ++- kernel/dma/Kconfig | 14 + kernel/dma/direct.c | 57 +++-- kernel/dma/direct.h | 9 +- kernel/dma/swiotlb.c | 242 +++++++++++++----- 15 files changed, 347 insertions(+), 97 deletions(-) -- 2.31.1.368.gbe11c130af-goog

3 27

[PATCH v3 1/5] drm/connector: Create a helper to attach the hdr_output_metadata property
by Maxime Ripard 10 May '21

10 May '21

All the drivers that implement HDR output call pretty much the same function to initialise the hdr_output_metadata property, and while the creation of that property is in a helper, every driver uses the same code to attach it. Provide a helper for it as well Reviewed-by: Harry Wentland <harry.wentland(a)amd.com> Reviewed-by: Jernej Skrabec <jernej.skrabec(a)siol.net> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> --- Changes from v2: - Rebased on current drm-misc-next - Fixed a merge conflict with i915 Changes from v1: - Rebased on latest drm-misc-next tag - Added the tags --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +--- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 +-- drivers/gpu/drm/drm_connector.c | 21 +++++++++++++++++++ drivers/gpu/drm/i915/display/intel_hdmi.c | 3 +-- include/drm/drm_connector.h | 1 + 5 files changed, 25 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index a0c8c41e4e57..c8d7e7dbc05e 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -7498,9 +7498,7 @@ void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm, if (connector_type == DRM_MODE_CONNECTOR_HDMIA || connector_type == DRM_MODE_CONNECTOR_DisplayPort || connector_type == DRM_MODE_CONNECTOR_eDP) { - drm_object_attach_property( - &aconnector->base.base, - dm->ddev->mode_config.hdr_output_metadata_property, 0); + drm_connector_attach_hdr_output_metadata_property(&aconnector->base); if (!aconnector->mst_port) drm_connector_attach_vrr_capable_property(&aconnector->base); diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index ae97513ef886..dd7f6eda2ce2 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -2492,8 +2492,7 @@ static int dw_hdmi_connector_create(struct dw_hdmi *hdmi) drm_connector_attach_max_bpc_property(connector, 8, 16); if (hdmi->version >= 0x200a && hdmi->plat_data->use_drm_infoframe) - drm_object_attach_property(&connector->base, - connector->dev->mode_config.hdr_output_metadata_property, 0); + drm_connector_attach_hdr_output_metadata_property(connector); drm_connector_attach_encoder(connector, hdmi->bridge.encoder); diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index eab8c0b82de2..c5e2f642acd9 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -2151,6 +2151,27 @@ int drm_connector_attach_max_bpc_property(struct drm_connector *connector, } EXPORT_SYMBOL(drm_connector_attach_max_bpc_property); +/** + * drm_connector_attach_hdr_output_metadata_property - attach "HDR_OUTPUT_METADA" property + * @connector: connector to attach the property on. + * + * This is used to allow the userspace to send HDR Metadata to the + * driver. + * + * Returns: + * Zero on success, negative errno on failure. + */ +int drm_connector_attach_hdr_output_metadata_property(struct drm_connector *connector) +{ + struct drm_device *dev = connector->dev; + struct drm_property *prop = dev->mode_config.hdr_output_metadata_property; + + drm_object_attach_property(&connector->base, prop, 0); + + return 0; +} +EXPORT_SYMBOL(drm_connector_attach_hdr_output_metadata_property); + /** * drm_connector_set_vrr_capable_property - sets the variable refresh rate * capable property for a connector diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c index 9c172dd6fb5b..3c767bcc47b1 100644 --- a/drivers/gpu/drm/i915/display/intel_hdmi.c +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c @@ -2459,8 +2459,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector *c drm_connector_attach_content_type_property(connector); if (DISPLAY_VER(dev_priv) >= 10) - drm_object_attach_property(&connector->base, - connector->dev->mode_config.hdr_output_metadata_property, 0); + drm_connector_attach_hdr_output_metadata_property(connector); if (!HAS_GMCH(dev_priv)) drm_connector_attach_max_bpc_property(connector, 8, 12); diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h index 1922b278ffad..32172dab8427 100644 --- a/include/drm/drm_connector.h +++ b/include/drm/drm_connector.h @@ -1671,6 +1671,7 @@ int drm_connector_attach_scaling_mode_property(struct drm_connector *connector, u32 scaling_mode_mask); int drm_connector_attach_vrr_capable_property( struct drm_connector *connector); +int drm_connector_attach_hdr_output_metadata_property(struct drm_connector *connector); int drm_mode_create_aspect_ratio_property(struct drm_device *dev); int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector); int drm_mode_create_dp_colorspace_property(struct drm_connector *connector); -- 2.31.1

2 7

[git pull] drm fixes for 5.12 final
by Dave Airlie 10 May '21

10 May '21

Hi Linus, Just some small i915 and amdgpu fixes this week, Should be all until you open the merge window. Regards, Dave. drm-fixes-2021-04-23: drm fixes for 5.12 final amdgpu: - Fix gpuvm page table update issue - Modifier fixes - Register fix for dimgrey cavefish i915: - GVT's BDW regression fix for cmd parser - Fix modesetting in case of unexpected AUX timeouts The following changes since commit bf05bf16c76bb44ab5156223e1e58e26dfe30a88: Linux 5.12-rc8 (2021-04-18 14:45:32 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-04-23 for you to fetch changes up to aca38735ae624b93c71c055b68d5802b8f356ea5: Merge tag 'drm-intel-fixes-2021-04-22' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2021-04-23 12:18:21 +1000) ---------------------------------------------------------------- drm fixes for 5.12 final amdgpu: - Fix gpuvm page table update issue - Modifier fixes - Register fix for dimgrey cavefish i915: - GVT's BDW regression fix for cmd parser - Fix modesetting in case of unexpected AUX timeouts ---------------------------------------------------------------- Dave Airlie (2): Merge tag 'amd-drm-fixes-5.12-2021-04-21' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2021-04-22' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Imre Deak (1): drm/i915: Fix modesetting in case of unexpected AUX timeouts Jiansong Chen (1): drm/amdgpu: fix GCR_GENERAL_CNTL offset for dimgrey_cavefish Philip Yang (1): drm/amdgpu: reserve fence slot to update page table Qingqing Zhuo (1): drm/amd/display: Update modifier list for gfx10_3 Rodrigo Vivi (1): Merge tag 'gvt-fixes-2021-04-20' of https://github.com/intel/gvt-linux into drm-intel-fixes Simon Ser (1): amd/display: allow non-linear multi-planar formats Zhenyu Wang (1): drm/i915/gvt: Fix BDW command parser regression drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 10 ++++++++-- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 ++++++--------- drivers/gpu/drm/i915/display/intel_dp_link_training.c | 3 ++- drivers/gpu/drm/i915/gvt/cmd_parser.c | 19 +++++++++++++------ 5 files changed, 30 insertions(+), 19 deletions(-)

4 6

[PATCH v2] drm/amdgpu: Ensure that the modifier requested is supported by plane.
by Mark Yacoub 09 May '21

09 May '21

From: Mark Yacoub <markyacoub(a)google.com> On initializing the framebuffer, call drm_any_plane_has_format to do a check if the modifier is supported. drm_any_plane_has_format calls dm_plane_format_mod_supported which is extended to validate that the modifier is on the list of the plane's supported modifiers. The bug was caught using igt-gpu-tools test: kms_addfb_basic.addfb25-bad-modifier Tested on ChromeOS Zork by turning on the display, running an overlay test, and running a YT video. === Changes from v1 === Explicitly handle DRM_FORMAT_MOD_INVALID modifier. Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: Bas Nieuwenhuizen <bas(a)basnieuwenhuizen.nl> Signed-off-by: default avatarMark Yacoub <markyacoub(a)chromium.org> --- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 13 +++++++++++++ .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 18 +++++++++++++++--- 2 files changed, 28 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c index afa5f8ad0f563..a947b5aa420d2 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c @@ -908,6 +908,19 @@ int amdgpu_display_gem_fb_verify_and_init( &amdgpu_fb_funcs); if (ret) goto err; + /* Verify that the modifier is supported. */ + if (!drm_any_plane_has_format(dev, mode_cmd->pixel_format, + mode_cmd->modifier[0])) { + struct drm_format_name_buf format_name; + drm_dbg_kms(dev, + "unsupported pixel format %s / modifier 0x%llx\n", + drm_get_format_name(mode_cmd->pixel_format, + &format_name), + mode_cmd->modifier[0]); + + ret = -EINVAL; + goto err; + } ret = amdgpu_display_framebuffer_init(dev, rfb, mode_cmd, obj); if (ret) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 961abf1cf040c..6fc746996c24f 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -3939,6 +3939,7 @@ static bool dm_plane_format_mod_supported(struct drm_plane *plane, { struct amdgpu_device *adev = drm_to_adev(plane->dev); const struct drm_format_info *info = drm_format_info(format); + int i; enum dm_micro_swizzle microtile = modifier_gfx9_swizzle_mode(modifier) & 3; @@ -3946,11 +3947,22 @@ static bool dm_plane_format_mod_supported(struct drm_plane *plane, return false; /* - * We always have to allow this modifier, because core DRM still - * checks LINEAR support if userspace does not provide modifers. + * We always have to allow these modifiers: + * 1. Core DRM checks for LINEAR support if userspace does not provide modifiers. + * 2. Not passing any modifiers is the same as explicitly passing INVALID. */ - if (modifier == DRM_FORMAT_MOD_LINEAR) + if (modifier == DRM_FORMAT_MOD_LINEAR || + modifier == DRM_FORMAT_MOD_INVALID) { return true; + } + + /* Check that the modifier is on the list of the plane's supported modifiers. */ + for (i = 0; i < plane->modifier_count; i++) { + if (modifier == plane->modifiers[i]) + break; + } + if (i == plane->modifier_count) + return false; /* * The arbitrary tiling support for multiplane formats has not been hooked -- 2.31.0.291.g576ba9dcdaf-goog

3 2

[PATCH] drm/radeon/ttm: Fix memory leak userptr pages
by Daniel Gomez 08 May '21

08 May '21

If userptr pages have been pinned but not bounded, they remain uncleared. Signed-off-by: Daniel Gomez <daniel(a)qtec.com> --- drivers/gpu/drm/radeon/radeon_ttm.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index e8c66d10478f..bbcc6264d48f 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -485,13 +485,14 @@ static void radeon_ttm_backend_unbind(struct ttm_bo_device *bdev, struct ttm_tt struct radeon_ttm_tt *gtt = (void *)ttm; struct radeon_device *rdev = radeon_get_rdev(bdev); + if (gtt->userptr) + radeon_ttm_tt_unpin_userptr(bdev, ttm); + if (!gtt->bound) return; radeon_gart_unbind(rdev, gtt->offset, ttm->num_pages); - if (gtt->userptr) - radeon_ttm_tt_unpin_userptr(bdev, ttm); gtt->bound = false; } -- 2.30.2

6 10

← Newer
1
...
14
15
16
17
18
19
20
...
72
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2021