dri-devel January 2021

dri-devel@lists.freedesktop.org

322 participants
737 discussions

[PATCH] drm/hisilicon: Use drm_crtc_mask()
by Tian Tao 11 Jan '21

11 Jan '21

Use drm_crtc_mask() where appropriate. Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> --- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c index c76f996..1c5f2fa 100644 --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c @@ -96,6 +96,7 @@ int hibmc_vdac_init(struct hibmc_drm_private *priv) struct drm_device *dev = &priv->dev; struct hibmc_connector *hibmc_connector = &priv->connector; struct drm_encoder *encoder = &priv->encoder; + struct drm_crtc *crtc = &priv->crtc; struct drm_connector *connector = &hibmc_connector->base; int ret; @@ -105,7 +106,7 @@ int hibmc_vdac_init(struct hibmc_drm_private *priv) return ret; } - encoder->possible_crtcs = 0x1; + encoder->possible_crtcs = drm_crtc_mask(crtc); ret = drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_DAC); if (ret) { drm_err(dev, "failed to init encoder: %d\n", ret); -- 2.7.4

2 1

linux-next: build warnings after merge of the amdgpu tree
by Stephen Rothwell 11 Jan '21

11 Jan '21

Hi all, After merging the amdgpu tree, today's linux-next build (htmldocs) produced these warnings: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:340: warning: Incorrect use of kernel-doc format: * @active_vblank_irq_count drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:379: warning: Function parameter or member 'active_vblank_irq_count' not described in 'amdgpu_display_manager' Introduced by commit 71338cb4a7c2 ("drm/amd/display: enable idle optimizations for linux (MALL stutter)") -- Cheers, Stephen Rothwell

1 0

[Bug 208947] New: amdgpu DisplayPort won't recognize all display modes after 5.9 merges
by bugzilla-daemon＠bugzilla.kernel.org 10 Jan '21

10 Jan '21

https://bugzilla.kernel.org/show_bug.cgi?id=208947 Bug ID: 208947 Summary: amdgpu DisplayPort won't recognize all display modes after 5.9 merges Product: Drivers Version: 2.5 Kernel Version: 5.9 staging-testing, rc1, and latest linux.git Hardware: x86-64 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: ckane(a)colemankane.org Regression: No I've got an AMD Ryzen 7 1700 and a POLARIS10 Radeon RX 580M GPU in an ASUS ROG GL702ZC laptop. I'm using the regular 5.8.1 kernel on Arch linux, and also have been tracking in-development kernel changes via the "staging-testing" branch on the gregkh/staging.git Linux tree as well as the torvalds/linux.git tree. Sometime during the course of the 5.9 updates getting merged into those trees, the 5.9 kernels I build no longer recognize all of the graphics modes for my 4K (3840x2160) monitor when it is plugged into the DisplayPort. Instead, the highest mode reported available is 1024x768, and Xorg also gets limited to these choices. This behavior appears limited to the monitor being plugged in via its DisplayPort input. When I use an HDMI input, all of the supported graphics modes are reported properly. I am using /sys/class/drm/card0-DP-1/modes to display the available modes, and also starting Xorg to test it as well. Would be happy to test patches if this is a known regression, or would appreciate some help/direction in tracking down potential likely culprits of the problem so I can try to diagnose it myself. I am somewhat familiar with kernel development, so I'm capable of hacking on it a bit if anyone can point me in a good direction. I'm just not too familiar with the inner workings of the AMDGPU, KMS, or DRM code. Not even certain if this is an issue specific to AMDGPU or something agnostic to the specific video hw. I also tried dumping the /sys/class/drm/card0-DP-1/edid after booting into 5.8.1 and then 5.9-latest and I get exactly the same data for both, so it seems like the EDID data is at least being fetched properly. I also tried saving that EDID data to a *.bin file and manually loading that via kernel arguments (drm.edid_firmware): verified it was loading properly for DP-1, but I still got the same results (no high-resolution video modes). Let me know what data would be helpful to attach to this issue, as well. Thanks, Coleman Kane -- You are receiving this mail because: You are watching the assignee of the bug.

1 22

[Bug 209987] New: Memory leak in amdgpu_dm_update_connector_after_detect
by bugzilla-daemon＠bugzilla.kernel.org 10 Jan '21

10 Jan '21

https://bugzilla.kernel.org/show_bug.cgi?id=209987 Bug ID: 209987 Summary: Memory leak in amdgpu_dm_update_connector_after_detect Product: Drivers Version: 2.5 Kernel Version: 5.9.1 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: lstarnes1024(a)gmail.com Regression: No Created attachment 293341 --> https://bugzilla.kernel.org/attachment.cgi?id=293341&action=edit /sys/kernel/debug/kmemleak It looks like there's a memory leak in drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:amdgpu_dm_update_connector_after_detect. It appears to be calling drm_add_edid_modes, which indirectly calling ito either do_detailed_mode or drm_mode_duplicate. This has caused me to run out of memory a handful of times, which could only be resolved by rebooting. I only experienced this after upgrading to 5.9.1, and it looks like commit b24bdc37d03a0478189e20a50286092840f414fa added the call to drm_add_edid_modes in amdgpu_dm_update_connector_after_detect. -- You are receiving this mail because: You are watching the assignee of the bug.

1 10

Re: [patch V3 13/37] mips/mm/highmem: Switch to generic kmap atomic
by Paul Cercueil 10 Jan '21

10 Jan '21

Hi Thomas, Le sam. 9 janv. 2021 à 1:33, Thomas Bogendoerfer <tsbogend(a)alpha.franken.de> a écrit : > On Sat, Jan 09, 2021 at 12:58:05AM +0100, Thomas Bogendoerfer wrote: >> On Fri, Jan 08, 2021 at 08:20:43PM +0000, Paul Cercueil wrote: >> > Hi Thomas, >> > >> > 5.11 does not boot anymore on Ingenic SoCs, I bisected it to this >> commit. >> > >> > Any idea what could be happening? >> >> not yet, kernel crash log of a Malta QEMU is below. > > update: > > This dirty hack lets the Malta QEMU boot again: > > diff --git a/mm/highmem.c b/mm/highmem.c > index c3a9ea7875ef..190cdda1149d 100644 > --- a/mm/highmem.c > +++ b/mm/highmem.c > @@ -515,7 +515,7 @@ void *__kmap_local_pfn_prot(unsigned long pfn, > pgprot_t prot) > vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx); > BUG_ON(!pte_none(*(kmap_pte - idx))); > pteval = pfn_pte(pfn, prot); > - set_pte_at(&init_mm, vaddr, kmap_pte - idx, pteval); > + set_pte(kmap_pte - idx, pteval); > arch_kmap_local_post_map(vaddr, pteval); > current->kmap_ctrl.pteval[kmap_local_idx()] = pteval; > preempt_enable(); > > set_pte_at() tries to update cache and could do an kmap_atomic() > there. > Not sure, if this is allowed at this point. Yes, I can confirm that your workaround works here too. Cheers, -Paul

2 1

[PATCH] drm/msm/a5xx: Allow all patchid for A540 chip
by AngeloGioacchino Del Regno 09 Jan '21

09 Jan '21

On at least MSM8998 it's possible to find Adreno 540.0 and 540.1 but I have never found any 540.2. In any case, the patchids 0-1 for A540 are completely supported by this driver and there is no reason to disallow probing them (as they also share the same firmware names). Besides that, the patchid number is also used in the a5xx_power.c function a540_lm_setup to disable the battery current limiter, which makes faking the Adreno patchid to .2 (which would anyway be sad) useless and even producing breakages. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)somainline.org> --- drivers/gpu/drm/msm/adreno/adreno_device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c b/drivers/gpu/drm/msm/adreno/adreno_device.c index 76a89a8175f8..133e3c15a1b7 100644 --- a/drivers/gpu/drm/msm/adreno/adreno_device.c +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c @@ -216,7 +216,7 @@ static const struct adreno_info gpulist[] = { .init = a5xx_gpu_init, .zapfw = "a530_zap.mdt", }, { - .rev = ADRENO_REV(5, 4, 0, 2), + .rev = ADRENO_REV(5, 4, 0, ANY_ID), .revn = 540, .name = "A540", .fw = { -- 2.29.2

1 0

[PATCH] dma-buf: cma_heap: Fix memory leak in CMA heap
by John Stultz 09 Jan '21

09 Jan '21

Bing Song noticed the CMA heap was leaking memory due to a flub I made in commit a5d2d29e24be ("dma-buf: heaps: Move heap-helper logic into the cma_heap implementation"), and provided this fix which ensures the pagelist is also freed on release. Cc: Bing Song <bing.song(a)nxp.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Liam Mark <lmark(a)codeaurora.org> Cc: Laura Abbott <labbott(a)kernel.org> Cc: Brian Starkey <Brian.Starkey(a)arm.com> Cc: Hridya Valsaraju <hridya(a)google.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Sandeep Patil <sspatil(a)google.com> Cc: Daniel Mentz <danielmentz(a)google.com> Cc: Chris Goldsworthy <cgoldswo(a)codeaurora.org> Cc: Ørjan Eide <orjan.eide(a)arm.com> Cc: Robin Murphy <robin.murphy(a)arm.com> Cc: Ezequiel Garcia <ezequiel(a)collabora.com> Cc: Simon Ser <contact(a)emersion.fr> Cc: James Jones <jajones(a)nvidia.com> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Reported-by: Bing Song <bing.song(a)nxp.com> Fixes: a5d2d29e24be ("dma-buf: heaps: Move heap-helper logic into the cma_heap implementation") Signed-off-by: John Stultz <john.stultz(a)linaro.org> --- drivers/dma-buf/heaps/cma_heap.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c index 3c4e34301172..364fc2f3e499 100644 --- a/drivers/dma-buf/heaps/cma_heap.c +++ b/drivers/dma-buf/heaps/cma_heap.c @@ -251,6 +251,9 @@ static void cma_heap_dma_buf_release(struct dma_buf *dmabuf) buffer->vaddr = NULL; } + /* free page list */ + kfree(buffer->pages); + /* release memory */ cma_release(cma_heap->cma, buffer->cma_pages, buffer->pagecount); kfree(buffer); } -- 2.17.1

2 1

[PATCH 1/3] drm: uapi: Use SPDX in DRM core uAPI headers
by Laurent Pinchart 09 Jan '21

09 Jan '21

The DRM core uAPI headers are licensed under the MIT license, and carry copies of the license with slight variations. Replace them with SPDX headers. Following a discussion with Daniel Vetter on this topic, add a clarification in the drm-uapi.rst file that independent closed-source userspace implementations of software using the DRM uAPI are accepted, as allowed by the MIT license. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com> Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Reviewed-by: Thomas Gleixner <tglx(a)linutronix.de> --- Documentation/gpu/drm-uapi.rst | 4 ++++ include/uapi/drm/drm.h | 20 +------------------- include/uapi/drm/drm_fourcc.h | 20 +------------------- include/uapi/drm/drm_mode.h | 19 +------------------ include/uapi/drm/drm_sarea.h | 20 +------------------- 5 files changed, 8 insertions(+), 75 deletions(-) diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index 56fec6ed1ad8..de2ecc76dd6c 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -107,6 +107,10 @@ is already rather painful for the DRM subsystem, with multiple different uAPIs for the same thing co-existing. If we add a few more complete mistakes into the mix every year it would be entirely unmanageable. +The DRM subsystem has however no concern with independent closed-source +userspace implementations. To officialize that position, the DRM uAPI headers +are covered by the MIT license. + .. _drm_render_node: Render nodes diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h index 808b48a93330..14d57361e580 100644 --- a/include/uapi/drm/drm.h +++ b/include/uapi/drm/drm.h @@ -1,3 +1,4 @@ +/* SPDX-License-Identifier: MIT */ /** * \file drm.h * Header for the Direct Rendering Manager @@ -12,25 +13,6 @@ * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas. * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California. * All rights reserved. - * - * Permission is hereby granted, free of charge, to any person obtaining a - * copy of this software and associated documentation files (the "Software"), - * to deal in the Software without restriction, including without limitation - * the rights to use, copy, modify, merge, publish, distribute, sublicense, - * and/or sell copies of the Software, and to permit persons to whom the - * Software is furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice (including the next - * paragraph) shall be included in all copies or substantial portions of the - * Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL - * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR - * OTHER DEALINGS IN THE SOFTWARE. */ #ifndef _DRM_H_ diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h index 490143500a50..d2c4a597620f 100644 --- a/include/uapi/drm/drm_fourcc.h +++ b/include/uapi/drm/drm_fourcc.h @@ -1,24 +1,6 @@ +/* SPDX-License-Identifier: MIT */ /* * Copyright 2011 Intel Corporation - * - * Permission is hereby granted, free of charge, to any person obtaining a - * copy of this software and associated documentation files (the "Software"), - * to deal in the Software without restriction, including without limitation - * the rights to use, copy, modify, merge, publish, distribute, sublicense, - * and/or sell copies of the Software, and to permit persons to whom the - * Software is furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice (including the next - * paragraph) shall be included in all copies or substantial portions of the - * Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL - * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR - * OTHER DEALINGS IN THE SOFTWARE. */ #ifndef DRM_FOURCC_H diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index 735c8cfdaaa1..c34a544fdf29 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -1,27 +1,10 @@ +/* SPDX-License-Identifier: MIT */ /* * Copyright (c) 2007 Dave Airlie <airlied(a)linux.ie> * Copyright (c) 2007 Jakob Bornecrantz <wallbraker(a)gmail.com> * Copyright (c) 2008 Red Hat Inc. * Copyright (c) 2007-2008 Tungsten Graphics, Inc., Cedar Park, TX., USA * Copyright (c) 2007-2008 Intel Corporation - * - * Permission is hereby granted, free of charge, to any person obtaining a - * copy of this software and associated documentation files (the "Software"), - * to deal in the Software without restriction, including without limitation - * the rights to use, copy, modify, merge, publish, distribute, sublicense, - * and/or sell copies of the Software, and to permit persons to whom the - * Software is furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice shall be included in - * all copies or substantial portions of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE - * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS - * IN THE SOFTWARE. */ #ifndef _DRM_MODE_H diff --git a/include/uapi/drm/drm_sarea.h b/include/uapi/drm/drm_sarea.h index a951ced60ebe..1e38d028332d 100644 --- a/include/uapi/drm/drm_sarea.h +++ b/include/uapi/drm/drm_sarea.h @@ -1,3 +1,4 @@ +/* SPDX-License-Identifier: MIT */ /** * \file drm_sarea.h * \brief SAREA definitions @@ -8,25 +9,6 @@ /* * Copyright 2002 Tungsten Graphics, Inc., Cedar Park, Texas. * All Rights Reserved. - * - * Permission is hereby granted, free of charge, to any person obtaining a - * copy of this software and associated documentation files (the "Software"), - * to deal in the Software without restriction, including without limitation - * the rights to use, copy, modify, merge, publish, distribute, sublicense, - * and/or sell copies of the Software, and to permit persons to whom the - * Software is furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice (including the next - * paragraph) shall be included in all copies or substantial portions of the - * Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL - * TUNGSTEN GRAPHICS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR - * OTHER DEALINGS IN THE SOFTWARE. */ #ifndef _DRM_SAREA_H_ -- Regards, Laurent Pinchart

8 15

[PATCH RESEND v2 1/2] dma-fence: allow signaling drivers to set fence timestamp
by Veera Sundaram Sankaran 09 Jan '21

09 Jan '21

Some drivers have hardware capability to get the precise timestamp of certain events based on which the fences are triggered. This allows it to set accurate timestamp factoring out any software and IRQ latencies. Add a timestamp variant of fence signal function, dma_fence_signal_timestamp to allow drivers to update the precise timestamp for fences. Changes in v2: - Add a new fence signal variant instead of modifying fence struct Signed-off-by: Veera Sundaram Sankaran <veeras(a)codeaurora.org> --- drivers/dma-buf/dma-fence.c | 70 ++++++++++++++++++++++++++++++++++++++++----- include/linux/dma-fence.h | 3 ++ 2 files changed, 66 insertions(+), 7 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index 7475e09..8887c5a 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -312,22 +312,25 @@ void __dma_fence_might_wait(void) /** - * dma_fence_signal_locked - signal completion of a fence + * dma_fence_signal_timestamp_locked - signal completion of a fence * @fence: the fence to signal + * @timestamp: fence signal timestamp * * Signal completion for software callbacks on a fence, this will unblock * dma_fence_wait() calls and run all the callbacks added with * dma_fence_add_callback(). Can be called multiple times, but since a fence * can only go from the unsignaled to the signaled state and not back, it will - * only be effective the first time. + * only be effective the first time. Set the timestamp provided as the fence + * signal timestamp. * - * Unlike dma_fence_signal(), this function must be called with &dma_fence.lock - * held. + * Unlike dma_fence_signal_timestamp(), this function must be called with + * &dma_fence.lock held. * * Returns 0 on success and a negative error value when @fence has been * signalled already. */ -int dma_fence_signal_locked(struct dma_fence *fence) +int dma_fence_signal_timestamp_locked(struct dma_fence *fence, + ktime_t timestamp) { struct dma_fence_cb *cur, *tmp; struct list_head cb_list; @@ -341,7 +344,7 @@ int dma_fence_signal_locked(struct dma_fence *fence) /* Stash the cb_list before replacing it with the timestamp */ list_replace(&fence->cb_list, &cb_list); - fence->timestamp = ktime_get(); + fence->timestamp = timestamp; set_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags); trace_dma_fence_signaled(fence); @@ -352,6 +355,59 @@ int dma_fence_signal_locked(struct dma_fence *fence) return 0; } +EXPORT_SYMBOL(dma_fence_signal_timestamp_locked); + +/** + * dma_fence_signal_timestamp - signal completion of a fence + * @fence: the fence to signal + * @timestamp: fence signal timestamp + * + * Signal completion for software callbacks on a fence, this will unblock + * dma_fence_wait() calls and run all the callbacks added with + * dma_fence_add_callback(). Can be called multiple times, but since a fence + * can only go from the unsignaled to the signaled state and not back, it will + * only be effective the first time. Set the timestamp provided as the fence + * signal timestamp. + * + * Returns 0 on success and a negative error value when @fence has been + * signalled already. + */ +int dma_fence_signal_timestamp(struct dma_fence *fence, ktime_t timestamp) +{ + unsigned long flags; + int ret; + + if (!fence) + return -EINVAL; + + spin_lock_irqsave(fence->lock, flags); + ret = dma_fence_signal_timestamp_locked(fence, timestamp); + spin_unlock_irqrestore(fence->lock, flags); + + return ret; +} +EXPORT_SYMBOL(dma_fence_signal_timestamp); + +/** + * dma_fence_signal_locked - signal completion of a fence + * @fence: the fence to signal + * + * Signal completion for software callbacks on a fence, this will unblock + * dma_fence_wait() calls and run all the callbacks added with + * dma_fence_add_callback(). Can be called multiple times, but since a fence + * can only go from the unsignaled to the signaled state and not back, it will + * only be effective the first time. + * + * Unlike dma_fence_signal(), this function must be called with &dma_fence.lock + * held. + * + * Returns 0 on success and a negative error value when @fence has been + * signalled already. + */ +int dma_fence_signal_locked(struct dma_fence *fence) +{ + return dma_fence_signal_timestamp_locked(fence, ktime_get()); +} EXPORT_SYMBOL(dma_fence_signal_locked); /** @@ -379,7 +435,7 @@ int dma_fence_signal(struct dma_fence *fence) tmp = dma_fence_begin_signalling(); spin_lock_irqsave(fence->lock, flags); - ret = dma_fence_signal_locked(fence); + ret = dma_fence_signal_timestamp_locked(fence, ktime_get()); spin_unlock_irqrestore(fence->lock, flags); dma_fence_end_signalling(tmp); diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h index 09e23ad..9f12efa 100644 --- a/include/linux/dma-fence.h +++ b/include/linux/dma-fence.h @@ -372,6 +372,9 @@ static inline void __dma_fence_might_wait(void) {} int dma_fence_signal(struct dma_fence *fence); int dma_fence_signal_locked(struct dma_fence *fence); +int dma_fence_signal_timestamp(struct dma_fence *fence, ktime_t timestamp); +int dma_fence_signal_timestamp_locked(struct dma_fence *fence, + ktime_t timestamp); signed long dma_fence_default_wait(struct dma_fence *fence, bool intr, signed long timeout); int dma_fence_add_callback(struct dma_fence *fence, -- 2.7.4

3 4

[PULL] drm-fixes
by Daniel Vetter 08 Jan '21

08 Jan '21

Hi Linus, Looks like people are back from the break, usual small pile of fixes all over. Next week Dave should be back. Only thing pending I'm aware of is a "this shouldn't have become uapi" reverts for amdgpu, but they're already on the list and not that important really so can wait another week. Cheers, Daniel drm-fixes-2021-01-08: drm-fixes for -rc3 - fix for ttm list corruption in radeon, reported by a few people - fixes for amdgpu, i915, msm - dma-buf use-after free fix Cheers, Daniel The following changes since commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62: Linux 5.11-rc2 (2021-01-03 15:55:30 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-01-08 for you to fetch changes up to 29f95f20581c4bb4e58c1cc1cb15bff9b931cad9: Merge tag 'drm-misc-fixes-2021-01-08' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2021-01-08 10:39:18 +0100) ---------------------------------------------------------------- drm-fixes for -rc3 - fix for ttm list corruption in radeon, reported by a few people - fixes for amdgpu, i915, msm - dma-buf use-after free fix ---------------------------------------------------------------- Alex Deucher (2): drm/amdgpu/display: drop DCN support for aarch64 Revert "drm/amd/display: Fix memory leaks in S3 resume" Arnd Bergmann (1): drm/amd/display: Fix unused variable warning Charan Teja Reddy (1): dmabuf: fix use-after-free of dmabuf's file->f_inode Chris Wilson (2): drm/i915/gt: Define guc firmware blob for older Cometlakes drm/i915/dp: Track pm_qos per connector Christian König (2): drm/radeon: stop re-init the TTM page pool drm/ttm: unexport ttm_pool_init/fini Craig Tatlor (1): drm/msm: Call msm_init_vram before binding the gpu Daniel Vetter (4): Merge tag 'amd-drm-fixes-5.11-2021-01-06' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2021-01-07' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'drm-msm-fixes-2021-01-07' of https://gitlab.freedesktop.org/drm/msm into drm-fixes Merge tag 'drm-misc-fixes-2021-01-08' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Dennis Li (3): drm/amdgpu: fix a memory protection fault when remove amdgpu device drm/amdgpu: fix a GPU hang issue when remove device drm/amdgpu: fix no bad_pages issue after umc ue injection Hawking Zhang (1): drm/amdgpu: switched to cached noretry setting for vangogh Iskren Chernev (3): drm/msm: Fix null dereference in _msm_gem_new drm/msm: Ensure get_pages is called when locked drm/msm: Add modparam to allow vram carveout Jiawei Gu (1): drm/amdgpu: fix potential memory leak during navi12 deinitialization John Clements (2): drm/amd/pm: updated PM to I2C controller port on sienna cichlid drm/amdgpu: enable ras eeprom support for sienna cichlid Kevin Wang (1): drm/amd/display: fix sysfs amdgpu_current_backlight_pwm NULL pointer issue Konrad Dybcio (1): drm/msm: Only enable A6xx LLCC code on A6xx Kuogee Hsieh (1): drm/msm/dp: postpone irq_hpd event during connection pending state Matthew Auld (2): drm/i915: clear the shadow batch drm/i915: clear the gpu reloc batch Rob Clark (1): drm/msm: Fix WARN_ON() splat in _free_object() Xiaojian Du (4): drm/amd/pm: correct the sensor value of power for vangogh drm/amd/pm: improve the fine grain tuning function for RV/RV2/PCO drm/amd/pm: fix the failure when change power profile for renoir drm/amd/pm: improve the fine grain tuning function for RV/RV2/PCO drivers/dma-buf/dma-buf.c | 21 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 25 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 8 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c | 8 +- drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c | 2 +- drivers/gpu/drm/amd/display/Kconfig | 2 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h | 2 +- drivers/gpu/drm/amd/display/dc/calcs/Makefile | 4 - drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile | 21 --- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 7 +- drivers/gpu/drm/amd/display/dc/dcn10/Makefile | 7 - .../gpu/drm/amd/display/dc/dcn10/dcn10_resource.c | 7 - drivers/gpu/drm/amd/display/dc/dcn20/Makefile | 4 - drivers/gpu/drm/amd/display/dc/dcn21/Makefile | 4 - drivers/gpu/drm/amd/display/dc/dcn30/Makefile | 5 - drivers/gpu/drm/amd/display/dc/dcn301/Makefile | 4 - drivers/gpu/drm/amd/display/dc/dcn302/Makefile | 4 - drivers/gpu/drm/amd/display/dc/dml/Makefile | 4 - drivers/gpu/drm/amd/display/dc/dsc/Makefile | 4 - drivers/gpu/drm/amd/display/dc/os_types.h | 4 - .../gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c | 166 +++++++++++++++++++-- .../gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.h | 3 + .../drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 2 +- drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 3 +- drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c | 1 + drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c | 1 + drivers/gpu/drm/i915/display/intel_display_types.h | 3 + drivers/gpu/drm/i915/display/intel_dp.c | 8 +- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 + drivers/gpu/drm/i915/i915_cmd_parser.c | 27 ++-- drivers/gpu/drm/i915/i915_drv.c | 5 - drivers/gpu/drm/i915/i915_drv.h | 3 - drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 6 +- drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 6 +- drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 6 +- drivers/gpu/drm/msm/adreno/adreno_device.c | 4 + drivers/gpu/drm/msm/adreno/adreno_gpu.c | 21 +-- drivers/gpu/drm/msm/adreno/adreno_gpu.h | 6 + drivers/gpu/drm/msm/dp/dp_display.c | 7 + drivers/gpu/drm/msm/dp/dp_panel.c | 12 +- drivers/gpu/drm/msm/msm_drv.c | 8 +- drivers/gpu/drm/msm/msm_gem.c | 13 +- drivers/gpu/drm/radeon/radeon_ttm.c | 3 - drivers/gpu/drm/ttm/ttm_pool.c | 2 - 47 files changed, 302 insertions(+), 177 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

2 1

← Newer
1
...
59
60
61
62
63
64
65
...
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2021