dri-devel June 2021

dri-devel@lists.freedesktop.org

341 participants
878 discussions

[PATCH -next] drivers: gpu: add missing MODULE_DEVICE_TABLE in anx7625.c
by Yu Jiahua 16 Jun '21

16 Jun '21

This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Signed-off-by: Yu Jiahua <yujiahua1(a)huawei.com> --- drivers/gpu/drm/bridge/analogix/anx7625.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c b/drivers/gpu/drm/bridge/analogix/anx7625.c index 65cc05982f82..beb01364af4d 100644 --- a/drivers/gpu/drm/bridge/analogix/anx7625.c +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c @@ -1830,6 +1830,7 @@ static const struct of_device_id anx_match_table[] = { {.compatible = "analogix,anx7625",}, {}, }; +MODULE_DEVICE_TABLE(of, anx_match_table); static struct i2c_driver anx7625_driver = { .driver = { -- 2.17.1

2 1

[PATCH] modified: gpu/drm/panfrost/panfrost_gpu.c
by ChunyouTang 16 Jun '21

16 Jun '21

From: tangchunyou <tangchunyou(a)163.icubecorp.cn> The GPU exception fault status register(0x3C),the low 8 bit is the EXCEPTION_TYPE.We can see the description at P3-78 in spec. Signed-off-by: tangchunyou <tangchunyou(a)163.icubecorp.cn> --- drivers/gpu/drm/panfrost/panfrost_gpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c b/drivers/gpu/drm/panfrost/panfrost_gpu.c index 2aae636f1cf5..1fffb6a0b24f 100644 --- a/drivers/gpu/drm/panfrost/panfrost_gpu.c +++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c @@ -33,7 +33,7 @@ static irqreturn_t panfrost_gpu_irq_handler(int irq, void *data) address |= gpu_read(pfdev, GPU_FAULT_ADDRESS_LO); dev_warn(pfdev->dev, "GPU Fault 0x%08x (%s) at 0x%016llx\n", - fault_status & 0xFF, panfrost_exception_name(pfdev, fault_status), + fault_status & 0xFF, panfrost_exception_name(pfdev, fault_status & 0xFF), address); if (state & GPU_IRQ_MULTIPLE_FAULT) -- 2.25.1

3 6

[PATCH 0/2] clk: Implement a clock request API
by Maxime Ripard 16 Jun '21

16 Jun '21

Hi, This is a follow-up of the discussion here: https://lore.kernel.org/linux-clk/20210319150355.xzw7ikwdaga2dwhv@gilmour/ This implements a mechanism to raise and lower clock rates based on consumer workloads, with an example of such an implementation for the RaspberryPi4 HDMI controller. There's a couple of things worth discussing: - The name is in conflict with clk_request_rate, and even though it feels like the right name to me, we should probably avoid any confusion - The code so far implements a policy of always going for the lowest rate possible. While we don't have an use-case for something else, this should maybe be made more flexible? Let me know what you think Maxime Maxime Ripard (2): clk: Introduce a clock request API drm/vc4: hdmi: Convert to the new clock request API drivers/clk/clk.c | 121 +++++++++++++++++++++++++++++++++ drivers/gpu/drm/vc4/vc4_hdmi.c | 19 ++++-- drivers/gpu/drm/vc4/vc4_hdmi.h | 3 + include/linux/clk.h | 4 ++ 4 files changed, 140 insertions(+), 7 deletions(-) -- 2.30.2

2 7

[Bug 205517] New: nouveau MMIO read of 00000000 FAULT at 619444
by bugzilla-daemon＠bugzilla.kernel.org 16 Jun '21

16 Jun '21

https://bugzilla.kernel.org/show_bug.cgi?id=205517 Bug ID: 205517 Summary: nouveau MMIO read of 00000000 FAULT at 619444 Product: Drivers Version: 2.5 Kernel Version: 5.3.0 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: todd.e.brandt(a)linux.intel.com Regression: No Created attachment 285893 --> https://bugzilla.kernel.org/attachment.cgi?id=285893&action=edit issue.def NVidia GPU driver fault on Dell systems during resume. [33133.398092] nouveau 0000:01:00.0: calling nv_msi_ht_cap_quirk_leaf+0x0/0x30 @ 27 [33133.398102] nouveau 0000:01:00.0: nv_msi_ht_cap_quirk_leaf+0x0/0x30 took 5 usecs [33133.398104] nouveau 0000:01:00.0: calling quirk_nvidia_hda+0x0/0xc0 @ 27 [33133.398107] nouveau 0000:01:00.0: Enabling HDA controller [33133.398110] nouveau 0000:01:00.0: quirk_nvidia_hda+0x0/0xc0 took 3 usecs [33133.399220] done. [33133.540201] nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 619444 [ IBUS ] [33133.556094] PM: suspend exit -- You are receiving this mail because: You are watching the assignee of the bug.

1 3

Re: [PATCH 07/10] vfio/mdev: Allow the mdev_parent_ops to specify the device driver to bind
by Greg Kroah-Hartman 16 Jun '21

16 Jun '21

On Tue, Jun 15, 2021 at 03:35:16PM +0200, Christoph Hellwig wrote: > From: Jason Gunthorpe <jgg(a)nvidia.com> > > This allows a mdev driver to opt out of using vfio_mdev.c, instead the > driver will provide a 'struct mdev_driver' and register directly with the > driver core. > > Much of mdev_parent_ops becomes unused in this mode: > - create()/remove() are done via the mdev_driver probe()/remove() > - mdev_attr_groups becomes mdev_driver driver.dev_groups > - Wrapper function callbacks are replaced with the same ones from > struct vfio_device_ops > > Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> > Signed-off-by: Christoph Hellwig <hch(a)lst.de> Messy, but ok... Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>

2 2

[PATCH v11 00/12] Restricted DMA
by Claire Chang 16 Jun '21

16 Jun '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… 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/1446882/ 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 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_dev_swiotlb_force 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 | 2 +- include/linux/device.h | 4 + include/linux/swiotlb.h | 40 ++- kernel/dma/Kconfig | 14 + kernel/dma/direct.c | 60 +++-- kernel/dma/direct.h | 8 +- kernel/dma/swiotlb.c | 255 +++++++++++++----- 16 files changed, 380 insertions(+), 103 deletions(-) -- 2.32.0.272.g935e593368-goog

1 14

Re: [PATCH v11 09/12] swiotlb: Add restricted DMA alloc/free support
by Claire Chang 16 Jun '21

16 Jun '21

On Wed, Jun 16, 2021 at 12:59 PM Christoph Hellwig <hch(a)lst.de> wrote: > > On Wed, Jun 16, 2021 at 12:04:16PM +0800, Claire Chang wrote: > > Just noticed that after propagating swiotlb_force setting into > > io_tlb_default_mem->force, the memory allocation behavior for > > swiotlb_force will change (i.e. always skipping arch_dma_alloc and > > dma_direct_alloc_from_pool). > > Yes, I think we need to split a "use_for_alloc" flag from the force flag. How about splitting is_dev_swiotlb_force into is_swiotlb_force_bounce (io_tlb_mem->force_bounce) and is_swiotlb_force_alloc (io_tlb_mem->force_alloc)?

1 0

[PATCH v10 00/12] Restricted DMA
by Claire Chang 16 Jun '21

16 Jun '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… 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 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_dev_swiotlb_force for swiotlb data bouncing swiotlb: Move alloc_size to swiotlb_find_slots swiotlb: Refactor swiotlb_tbl_unmap_single swiotlb: Add restricted DMA pool initialization swiotlb: Add restricted DMA alloc/free support 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 | 2 +- include/linux/device.h | 4 + include/linux/swiotlb.h | 40 ++- kernel/dma/Kconfig | 14 + kernel/dma/direct.c | 60 +++-- kernel/dma/direct.h | 8 +- kernel/dma/swiotlb.c | 255 +++++++++++++----- 16 files changed, 380 insertions(+), 103 deletions(-) -- 2.32.0.272.g935e593368-goog

2 14

[PATCH 0/2] Fix observed mst problems with StarTech hub
by Wayne Lin 16 Jun '21

16 Jun '21

Use Startech 1to3 DP hub to do some mst hotplug tests and find some light up issues. 1. ACT polling timeout: Which is due to we didn't update DPCD payload table but still try to send ACT and polling for "ACT Handled" bit 2. Not all monitors light up: Due to we wrongly set unavailable VCP ID for new streams Wayne Lin (2): drm/dp_mst: Do not set proposed vcpi directly drm/dp_mst: Avoid to mess up payload table by ports in stale topology drivers/gpu/drm/drm_dp_mst_topology.c | 65 ++++++++++++++++----------- 1 file changed, 39 insertions(+), 26 deletions(-) -- 2.17.1

3 6

[PATCH v10 00/10] Add support for SVM atomics in Nouveau
by Alistair Popple 16 Jun '21

16 Jun '21

Hi Andrew, This is an update to address some comments on the previous version of this series. Most are code comment updates, although there were a couple of code changes as well. The most significant are: - Re-introduce the check of VM_LOCKED under the PTL in page_mlock_one(). This was present in an earlier version of the series but removed because we thought it was redundant. However Shakeel provided some background making it clear it is needed. - Reworked the return codes in copy_pte_range() based on suggestions from Peter Xu to hopefully make the code clearer and less error-prone. - Integrated a fix to the Nouveau code reported by Colin King. As discussed to minimise impact I have also made this dependent on CONFIG_DEVICE_PRIVATE. Hopefully these changes don't break any other series that may have been based on the previous version. I see there has been some discussion from Hugh and others around patch order, so if you need me to rebase these to a different branch let me know. Introduction ============ Some devices have features such as atomic PTE bits that can be used to implement atomic access to system memory. To support atomic operations to a shared virtual memory page such a device needs access to that page which is exclusive of the CPU. This series introduces a mechanism to temporarily unmap pages granting exclusive access to a device. These changes are required to support OpenCL atomic operations in Nouveau to shared virtual memory (SVM) regions allocated with the CL_MEM_SVM_ATOMICS clSVMAlloc flag. A more complete description of the OpenCL SVM feature is available at https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/ OpenCL_API.html#_shared_virtual_memory . Implementation ============== Exclusive device access is implemented by adding a new swap entry type (SWAP_DEVICE_EXCLUSIVE) which is similar to a migration entry. The main difference is that on fault the original entry is immediately restored by the fault handler instead of waiting. Restoring the entry triggers calls to MMU notifers which allows a device driver to revoke the atomic access permission from the GPU prior to the CPU finalising the entry. Patches ======= Patches 1 & 2 refactor existing migration and device private entry functions. Patches 3 & 4 rework try_to_unmap_one() by splitting out unrelated functionality into separate functions - try_to_migrate_one() and try_to_munlock_one(). Patch 5 renames some existing code but does not introduce functionality. Patch 6 is a small clean-up to swap entry handling in copy_pte_range(). Patch 7 contains the bulk of the implementation for device exclusive memory. Patch 8 contains some additions to the HMM selftests to ensure everything works as expected. Patch 9 is a cleanup for the Nouveau SVM implementation. Patch 10 contains the implementation of atomic access for the Nouveau driver. Testing ======= This has been tested with upstream Mesa 21.1.0 and a simple OpenCL program which checks that GPU atomic accesses to system memory are atomic. Without this series the test fails as there is no way of write-protecting the page mapping which results in the device clobbering CPU writes. For reference the test is available at https://ozlabs.org/~apopple/opencl_svm_atomics/ Further testing has been performed by adding support for testing exclusive access to the hmm-tests kselftests. Alistair Popple (10): mm: Remove special swap entry functions mm/swapops: Rework swap entry manipulation code mm/rmap: Split try_to_munlock from try_to_unmap mm/rmap: Split migration into its own function mm: Rename migrate_pgmap_owner mm/memory.c: Allow different return codes for copy_nonpresent_pte() mm: Device exclusive memory access mm: Selftests for exclusive device memory nouveau/svm: Refactor nouveau_range_fault nouveau/svm: Implement atomic SVM access Documentation/vm/hmm.rst | 19 +- Documentation/vm/unevictable-lru.rst | 33 +- arch/s390/mm/pgtable.c | 2 +- drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1 + drivers/gpu/drm/nouveau/nouveau_svm.c | 156 ++++- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 1 + .../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 6 + fs/proc/task_mmu.c | 23 +- include/linux/mmu_notifier.h | 26 +- include/linux/rmap.h | 11 +- include/linux/swap.h | 13 +- include/linux/swapops.h | 123 ++-- lib/test_hmm.c | 126 +++- lib/test_hmm_uapi.h | 2 + mm/debug_vm_pgtable.c | 12 +- mm/hmm.c | 12 +- mm/huge_memory.c | 45 +- mm/hugetlb.c | 10 +- mm/memcontrol.c | 2 +- mm/memory.c | 173 ++++- mm/migrate.c | 51 +- mm/mlock.c | 12 +- mm/mprotect.c | 18 +- mm/page_vma_mapped.c | 15 +- mm/rmap.c | 602 +++++++++++++++--- tools/testing/selftests/vm/hmm-tests.c | 158 +++++ 26 files changed, 1328 insertions(+), 324 deletions(-) -- 2.20.1

2 26

← Newer
1
...
44
45
46
47
48
49
50
...
88
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2021