dri-devel June 2021

dri-devel@lists.freedesktop.org

341 participants
878 discussions

[PATCH v3 0/2] backlight: lm3630a: convert to atomic PWM API
by Uwe Kleine-König 25 Jun '21

25 Jun '21

From: Uwe Kleine-König <uwe(a)kleine-koenig.org> Hello, this is v3 of the series. In v1 and v2 I failed to notice that the driver contains two (nearly identical) update_status callbacks. Daniel pointed that out, so here comes v3. Best regards Uwe Uwe Kleine-König (2): backlight: lm3630a: fix return code of .update_status() callback backlight: lm3630a: convert to atomic PWM API and check for errors drivers/video/backlight/lm3630a_bl.c | 50 +++++++++++++--------------- 1 file changed, 23 insertions(+), 27 deletions(-) -- 2.30.2

3 8

[PATCH v2 0/5] Remove uses of struct page from x86 and arm64 MMU
by David Stevens 25 Jun '21

25 Jun '21

KVM supports mapping VM_IO and VM_PFNMAP memory into the guest by using follow_pte in gfn_to_pfn. However, the resolved pfns may not have assoicated struct pages, so they should not be passed to pfn_to_page. This series removes such calls from the x86 and arm64 secondary MMU. To do this, this series introduces gfn_to_pfn_page functions that parallel the gfn_to_pfn functions. These functions take an extra out parameter which contains the page if the hva was resovled by gup. This allows the caller to call put_page only when necessated by gup. The gfn_to_pfn functions are depreciated. For now the functions remain with identical behavior to before, but callers should be migrated to the new gfn_to_pfn_page functions. I added new functions instead of simply adding another parameter to the existing functions to make it easier to track down users of the deprecated functions. I have migrated the x86 and arm64 secondary MMUs to the new gfn_to_pfn_page functions. This addresses CVE-2021-22543 on x86 and arm64. v1 -> v2: - Introduce new gfn_to_pfn_page functions instead of modifying the behavior of existing gfn_to_pfn functions, to make the change less invasive. - Drop changes to mmu_audit.c - Include Nicholas Piggin's patch to avoid corrupting refcount in the follow_pte case, and use it in depreciated gfn_to_pfn functions. - Rebase on kvm/next David Stevens (4): KVM: mmu: introduce new gfn_to_pfn_page functions KVM: x86/mmu: use gfn_to_pfn_page KVM: arm64/mmu: use gfn_to_pfn_page KVM: mmu: remove over-aggressive warnings Nicholas Piggin (1): KVM: do not allow mapping valid but non-refcounted pages arch/arm64/kvm/mmu.c | 26 +++-- arch/x86/kvm/mmu/mmu.c | 50 ++++----- arch/x86/kvm/mmu/mmu_internal.h | 3 +- arch/x86/kvm/mmu/paging_tmpl.h | 23 +++-- arch/x86/kvm/mmu/tdp_mmu.c | 6 +- arch/x86/kvm/mmu/tdp_mmu.h | 4 +- arch/x86/kvm/x86.c | 6 +- include/linux/kvm_host.h | 17 +++ virt/kvm/kvm_main.c | 177 +++++++++++++++++++++++++------- 9 files changed, 222 insertions(+), 90 deletions(-) -- 2.32.0.93.g670b81a890-goog

3 7

[PATCH v2] drm/i915: Reinstate the mmap ioctl for some platforms
by Thomas Hellström 25 Jun '21

25 Jun '21

Reinstate the mmap ioctl for all current integrated platforms. The intention was really to have it disabled for discrete graphics where we enforce a single mmap mode. Fixes: 35cbd91eb541 ("drm/i915: Disable mmap ioctl for gen12+") Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld(a)intel.com> --- v2: - Added a R-B. - Fixed up the code comment a bit. --- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c index 2fd155742bd2..4f50a508c7a0 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c @@ -62,10 +62,11 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data, struct drm_i915_gem_object *obj; unsigned long addr; - /* mmap ioctl is disallowed for all platforms after TGL-LP. This also - * covers all platforms with local memory. + /* + * mmap ioctl is disallowed for all discrete platforms, + * and for all platforms with GRAPHICS_VER > 12. */ - if (GRAPHICS_VER(i915) >= 12 && !IS_TIGERLAKE(i915)) + if (IS_DGFX(i915) || GRAPHICS_VER(i915) > 12) return -EOPNOTSUPP; if (args->flags & ~(I915_MMAP_WC)) -- 2.31.1

3 3

[PATCH 0/6] KVM: Remove uses of struct page from x86 and arm64 MMU
by David Stevens 25 Jun '21

25 Jun '21

KVM supports mapping VM_IO and VM_PFNMAP memory into the guest by using follow_pte in gfn_to_pfn. However, the resolved pfns may not have assoicated struct pages, so they should not be passed to pfn_to_page. This series removes such calls from the x86 and arm64 secondary MMU. To do this, this series modifies gfn_to_pfn to return a struct page in addition to a pfn, if the hva was resolved by gup. This allows the caller to call put_page only when necessated by gup. This series provides a helper function that unwraps the new return type of gfn_to_pfn to provide behavior identical to the old behavior. As I have no hardware to test powerpc/mips changes, the function is used there for minimally invasive changes. Additionally, as gfn_to_page and gfn_to_pfn_cache are not integrated with mmu notifier, they cannot be easily changed over to only use pfns. This addresses CVE-2021-22543 on x86 and arm64. David Stevens (6): KVM: x86/mmu: release audited pfns KVM: mmu: also return page from gfn_to_pfn KVM: x86/mmu: avoid struct page in MMU KVM: arm64/mmu: avoid struct page in MMU KVM: mmu: remove over-aggressive warnings drm/i915/gvt: use gfn_to_pfn's page instead of pfn arch/arm64/kvm/mmu.c | 42 +++++---- arch/mips/kvm/mmu.c | 3 +- arch/powerpc/kvm/book3s.c | 3 +- arch/powerpc/kvm/book3s_64_mmu_hv.c | 5 +- arch/powerpc/kvm/book3s_64_mmu_radix.c | 5 +- arch/powerpc/kvm/book3s_hv_uvmem.c | 4 +- arch/powerpc/kvm/e500_mmu_host.c | 2 +- arch/x86/kvm/mmu/mmu.c | 60 ++++++------ arch/x86/kvm/mmu/mmu_audit.c | 13 ++- arch/x86/kvm/mmu/mmu_internal.h | 3 +- arch/x86/kvm/mmu/paging_tmpl.h | 36 +++++--- arch/x86/kvm/mmu/tdp_mmu.c | 7 +- arch/x86/kvm/mmu/tdp_mmu.h | 4 +- arch/x86/kvm/x86.c | 9 +- drivers/gpu/drm/i915/gvt/gtt.c | 12 ++- drivers/gpu/drm/i915/gvt/hypercall.h | 3 +- drivers/gpu/drm/i915/gvt/kvmgt.c | 12 +-- drivers/gpu/drm/i915/gvt/mpt.h | 8 +- include/linux/kvm_host.h | 27 ++++-- include/linux/kvm_types.h | 5 + virt/kvm/kvm_main.c | 123 +++++++++++++------------ 21 files changed, 212 insertions(+), 174 deletions(-) -- 2.32.0.93.g670b81a890-goog

6 33

[PATCH 00/17] drm/msm/dpu: switch dpu_plane to be virtual
by Dmitry Baryshkov 25 Jun '21

25 Jun '21

As discussed on IRC, change dpu_plane implementation to be virtual: register unified planes and select backing SSPP block at runtime. In future this would allow implementing multirect (or wide planes) in a proper way, without requiring zpos hacks or additional userspace handling. The last patch adds a compile time #if to select between virtual planes or traditional planes. It is implemented this way to ease testing of this patchset. In the next versions it is going to be morphed into the proper module parameter. The following changes since commit e88bbc91849b2bf57683119c339e52916d34433f: Revert "drm/msm/mdp5: provide dynamic bandwidth management" (2021-06-23 14:06:20 -0700) are available in the Git repository at: https://git.linaro.org/people/dmitry.baryshkov/kernel.git dpu-virtual-planes for you to fetch changes up to c0b20040e9b265e77cbf02c5b5312090b3677f81: drm/msm/dpu: switch into using virtual planes (2021-06-24 17:50:54 +0300) ---------------------------------------------------------------- Dmitry Baryshkov (17): drm/msm/dpu: move LUT levels out of QOS config drm/msm/dpu: remove pipe_qos_cfg from struct dpu_plane drm/msm/dpu: drop pipe_name from struct dpu_plane drm/msm/dpu: remove stage_cfg from struct dpu_crtc drm/msm/dpu: rip out master planes support drm/msm/dpu: move dpu_hw_pipe_cfg out of struct dpu_plane drm/msm/dpu: don't cache pipe->cap->features in dpu_plane drm/msm/dpu: don't cache pipe->cap->sblk in dpu_plane drm/msm/dpu: rip out debugfs support from dpu_plane drm/msm/dpu: simplify colorspace conversion setup drm/msm/dpu: drop src_split and multirect check from dpu_crtc_atomic_check drm/msm/dpu: add list of supported formats to the DPU caps drm/msm/dpu: simplify DPU_SSPP features checks drm/msm/dpu: do not limit the zpos property drm/msm/dpu: add support for SSPP allocation to RM drm/msm/dpu: add support for virtualized planes drm/msm/dpu: switch into using virtual planes drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 215 ++------ drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 2 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 10 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 17 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 44 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 139 ++--- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 70 +-- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 709 ++++++++++--------------- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 42 +- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 81 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 6 + 14 files changed, 560 insertions(+), 783 deletions(-)

2 18

[PATCH] drm/amdgpu: use kvcalloc for entry->entries.
by huqiqiao 25 Jun '21

25 Jun '21

kmalloc_array + __GFP_ZERO is the same with kvcalloc. Signed-off-by: huqiqiao <huqiqiao(a)uniontech.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c index 9acee4a5b2ba..5a012321d09e 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c @@ -909,8 +909,7 @@ static int amdgpu_vm_alloc_pts(struct amdgpu_device *adev, num_entries = amdgpu_vm_num_entries(adev, cursor->level); entry->entries = kvmalloc_array(num_entries, - sizeof(*entry->entries), - GFP_KERNEL | __GFP_ZERO); + sizeof(*entry->entries), GFP_KERNEL); if (!entry->entries) return -ENOMEM; } -- 2.11.0

1 0

Re: [PATH 0/4] [RFC] Support virtual DRM
by Esaki Tomohito 25 Jun '21

25 Jun '21

Hi, Enrico Weigelt Thank you for reply. On 2021/06/22 1:05, Enrico Weigelt, metux IT consult wrote: > On 21.06.21 08:27, Tomohito Esaki wrote: > > Hi, > >> Virtual DRM splits the overlay planes of a display controller into multiple >> virtual devices to allow each plane to be accessed by each process. >> >> This makes it possible to overlay images output from multiple processes on a >> display. For example, one process displays the camera image without compositor >> while another process overlays the UI. > > Are you attempting to create an simple in-kernel compositor ? I think the basic idea is the same as DRMlease. We want to separate the resources from the master in units of planes, so we proposed virtual DRM. I think the advantage of vDRM is that you can use general DRM APIs in userland. > I don't think that's not the way to go, at least not by touching each > single display driver, and not hardcoding the planes in DT. Thank you for comment. I will reconsider about DT. > What's the actual use case you're doing that for ? Why not using some > userland compositor ? I think when latency is important (e.g., AR, VR, for displaying camera images in IVI systems), there may be use cases where the compositor cannot be used. Normally, when the image is passed through the compositor, it is displayed after 2 VSYNC at most, because the compositor combines the image with VSYNC synchronization. On the other hand, if we use vDRM, the image will be displayed at the next VSYNC, so it will be displayed after 1 VSYNC at most. Also, since the compositor is a single point of failure, we may not want to make it dependent on it. Best regards Tomohito Esaki

3 7

[PATCH] drm/amdgpu:use kvcalloc instead of kvmalloc_array
by huqiqiao 25 Jun '21

25 Jun '21

kvmalloc_array + __GFP_ZERO is the same with kvcalloc. Signed-off-by: huqiqiao <huqiqiao(a)uniontech.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c index 9acee4a5b2ba..50edc73525b0 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c @@ -908,9 +908,8 @@ static int amdgpu_vm_alloc_pts(struct amdgpu_device *adev, unsigned num_entries; num_entries = amdgpu_vm_num_entries(adev, cursor->level); - entry->entries = kvmalloc_array(num_entries, - sizeof(*entry->entries), - GFP_KERNEL | __GFP_ZERO); + entry->entries = kvcalloc(num_entries, + sizeof(*entry->entries), GFP_KERNEL); if (!entry->entries) return -ENOMEM; } -- 2.11.0

3 2

[PATCH v4 0/3] drm/msm/dsi: support CPHY mode for 7nm pll/phy
by Jonathan Marek 24 Jun '21

24 Jun '21

Add the required changes to support 7nm pll/phy in CPHY mode. This adds a "qcom,dsi-phy-cphy-mode" property for the PHY node to enable the CPHY mode. v2: - rebased on DSI PHY reworks - reworked getting cphy_mode in dsi_host.c - documentation change in separate patch v3: - yaml bindings - changed binding to "phy-type = <PHY_TYPE_DSI_CPHY>;" v4: - PHY_TYPE_{DPHY,CPHY} instead of PHY_TYPE_DSI_{DPHY,CPHY} - use enum/default for phy-type property - remove a stray semicolon in dts example Jonathan Marek (3): dt-bindings: msm: dsi: add missing 7nm bindings dt-bindings: msm: dsi: document phy-type property for 7nm dsi phy drm/msm/dsi: support CPHY mode for 7nm pll/phy .../bindings/display/msm/dsi-phy-7nm.yaml | 71 +++++++++ drivers/gpu/drm/msm/dsi/dsi.xml.h | 2 + drivers/gpu/drm/msm/dsi/dsi_host.c | 34 +++- drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 49 ++++++ drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 3 + drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 145 ++++++++++++------ include/dt-bindings/phy/phy.h | 2 + 7 files changed, 259 insertions(+), 47 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml -- 2.26.1

3 7

[PATCH 00/11] drm/scheduler dependency tracking
by Daniel Vetter 24 Jun '21

24 Jun '21

Hi all, While trying to carefully auditing how all the various drivers handler the implicit dependencies in the dma-resv object I got a bit too annoyed about all the hand-rolling. Here's some patches to unify this at least for drivers using the drm/scheduler. 4 out of 5 are converted over (but only compile-tested), I think amdgpu would also work: - handle the job->sync dependencies using drm_sched_job_await* - build up the job->sched_sync fences needed for deciding whether we need a full flush or not before we push the job into the scheduler, instead of in the ->dependency callback. This also has the benefit of removing a bunch of allocations from scheduler callbacks, where they're not ok (due to recursuion into mmu notifier/shrinker on direct reclaim) - keep the vmid_grab stuff in the ->dependency callback, for special things like that I've kept that as a fallback. There's a few complications though: - amdgpu_sync is both used for amdgpu_job and for other things, mostly amdkfd, but also some bo wait functions - amdgpu_job is both used for pushing jobs into the scheduler, but also for directly pushing a job into the hw through an ib All not insurmountable, but a bit too much when the main goal here was just to establish the drm_sched_job_await api. Wrt the datastructure I picked: Since 3 out of 5 drivers used the xarray, and that should at least be fairly storage efficient and easy to grow, I went with that. We can bikeshed/tune the backing implementation later on. Similarly the await_implicit implementation is as inefficient as the one the drivers currently use, relying on dma_resv_get_fences(). This means we copy all the fences to some temporary array first, which is entirely unecessary because we're holding the dma_resv lock. All that can be tuned later on easily. Review, comments and especially testing very much welcome. Cheers, Daniel Daniel Vetter (11): drm/sched: Split drm_sched_job_init drm/sched: Add dependency tracking drm/sched: drop entity parameter from drm_sched_push_job drm/panfrost: use scheduler dependency tracking drm/lima: use scheduler dependency tracking drm/v3d: Move drm_sched_job_init to v3d_job_init drm/v3d: Use scheduler dependency handling drm/etnaviv: Use scheduler dependency handling drm/gem: Delete gem array fencing helpers drm/scheduler: Don't store self-dependencies drm/sched: Check locking in drm_sched_job_await_implicit .gitignore | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 4 +- drivers/gpu/drm/drm_gem.c | 96 ------------- drivers/gpu/drm/etnaviv/etnaviv_gem.h | 5 +- drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 32 ++--- drivers/gpu/drm/etnaviv/etnaviv_sched.c | 63 +-------- drivers/gpu/drm/etnaviv/etnaviv_sched.h | 3 +- drivers/gpu/drm/lima/lima_gem.c | 7 +- drivers/gpu/drm/lima/lima_sched.c | 28 +--- drivers/gpu/drm/lima/lima_sched.h | 6 +- drivers/gpu/drm/panfrost/panfrost_drv.c | 14 +- drivers/gpu/drm/panfrost/panfrost_job.c | 39 +----- drivers/gpu/drm/panfrost/panfrost_job.h | 5 +- drivers/gpu/drm/scheduler/sched_entity.c | 30 +++-- drivers/gpu/drm/scheduler/sched_fence.c | 15 ++- drivers/gpu/drm/scheduler/sched_main.c | 135 ++++++++++++++++++- drivers/gpu/drm/v3d/v3d_drv.h | 5 - drivers/gpu/drm/v3d/v3d_gem.c | 91 ++++--------- drivers/gpu/drm/v3d/v3d_sched.c | 29 +--- include/drm/drm_gem.h | 5 - include/drm/gpu_scheduler.h | 40 +++++- 22 files changed, 282 insertions(+), 375 deletions(-) -- 2.32.0.rc2

6 36

← Newer
1
...
24
25
26
27
28
29
30
...
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