On Wed, Sep 21, 2022 at 05:20:19PM -0400, Yunxiang Li wrote:
> manage_dm_interrupts disable/enable vblank using drm_crtc_vblank_off/on
> which causes drm_crtc_vblank_get in vrr_transition to fail, and later
> when drm_crtc_vblank_put is called the refcount on vblank will be messed
> up. Therefore m
On Fri, Oct 14, 2022 at 8:22 AM Nathan Chancellor wrote:
>
> After commit 8799c0be89eb ("drm/amd/display: Fix vblank refcount in vrr
> transition"), a build with CONFIG_DEBUG_FS=n is broken due to a
> misplaced brace, along the lines of:
Thanks, applied.
Linus
On Fri, Oct 14, 2022 at 02:27:35PM +, Li, Yunxiang (Teddy) wrote:
> [AMD Official Use Only - General]
>
> > This patch results in a large number of compile errors if
> > CONFIG_DEBUG_FS=n. Reverting it fixes the problem.
> >
> > This is an architecture independent problem.
> >
> > Guenter
>
kmap() is being deprecated in favor of kmap_local_page().
There are two main problems with kmap(): (1) It comes with an overhead as
mapping space is restricted and protected by a global lock for
synchronization and (2) it also requires global TLB invalidation when the
kmap’s pool wraps and it migh
On Thu, Oct 13, 2022 at 11:07:14PM +0200, Fabio M. De Francesco wrote:
> The use of kmap() is being deprecated in favor of kmap_local_page().
>
> There are two main problems with kmap(): (1) It comes with an overhead as
> the mapping space is restricted and protected by a global lock for
> synchro
[Why]
L1 blocks most of GC registers accessing by MMIO.
[How]
Use RLCG interface to program GC registers under SRIOV VF in full access time.
Signed-off-by: Yifan Zha
Reviewed-by: Hawking Zhang
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v11.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
The function get_umc_v6_7_channel_index() is defined in the umc_v6_7.c
file, but not called elsewhere, so delete this unused function.
drivers/gpu/drm/amd/amdgpu/umc_v6_7.c:60:24: warning: unused function
'get_umc_v6_7_channel_index'.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2413
Rep
The function amdgpu_ucode_print_imu_hdr() is defined in the amdgpu_ucode.c
file, but not called elsewhere, so delete this unused function.
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:129:6: warning: no previous prototype
for function 'amdgpu_ucode_print_imu_hdr'.
Link: https://bugzilla.openanolis.
Hi Hamza,
On 10/14/22 11:31, Hamza Mahfooz wrote:
Currently, if we encounter unimplemented functions, it is difficult to
tell what caused them just by looking at dmesg and that is compounded by
the fact that it is often hard to reproduce said issues. So, to have
access to more detailed debugging
On 2022-10-17 09:06, Rodrigo Siqueira wrote:
Hi Hamza,
On 10/14/22 11:31, Hamza Mahfooz wrote:
Currently, if we encounter unimplemented functions, it is difficult to
tell what caused them just by looking at dmesg and that is compounded by
the fact that it is often hard to reproduce said issues.
On Mon, Oct 17, 2022 at 5:21 AM Yifan Zha wrote:
>
> [Why]
> L1 blocks most of GC registers accessing by MMIO.
>
> [How]
> Use RLCG interface to program GC registers under SRIOV VF in full access time.
Acked-by: Alex Deucher
>
> Signed-off-by: Yifan Zha
> Reviewed-by: Hawking Zhang
> ---
> .
On 10/13/22 13:02, Simon Ser wrote:
So no tests that actually verify that the kernel properly rejects
stuff stuff like modesets, gamma LUT updates, plane movement,
etc.?
Pondering this a bit more, it just occurred to me the current driver
level checks might easily lead to confusing behaviour. E
On Mon, Oct 17, 2022 at 5:04 AM Jiapeng Chong
wrote:
>
> The function amdgpu_ucode_print_imu_hdr() is defined in the amdgpu_ucode.c
> file, but not called elsewhere, so delete this unused function.
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:129:6: warning: no previous
> prototype for function
Currently, if we encounter unimplemented functions, it is difficult to
tell what caused them just by looking at dmesg and that is compounded by
the fact that it is often hard to reproduce said issues, for instance we
have had reports of this condition being triggered when removing a
secondary displ
On 2022-10-17 11:38, Hamza Mahfooz wrote:
> Currently, if we encounter unimplemented functions, it is difficult to
> tell what caused them just by looking at dmesg and that is compounded by
> the fact that it is often hard to reproduce said issues, for instance we
> have had reports of this cond
On Mon, 17 Oct 2022, Geert Uytterhoeven wrote:
Below is the list of build error/warning regressions/improvements in
v6.1-rc1[1] compared to v6.0[2].
Summarized:
- build errors: +25/-13
[1]
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/9abf2313adc1ca1b6180c508c25f22f9395cc780/
(all
Currently, if we encounter unimplemented functions, it is difficult to
tell what caused them just by looking at dmesg and that is compounded by
the fact that it is often hard to reproduce said issues, for instance we
have had reports of this condition being triggered when removing a
secondary displ
When booting a kernel compiled with CONFIG_CFI_CLANG on a machine with
an RX 6700 XT, there is a CFI failure in kfd_destroy_mqd_cp():
[ 12.894543] CFI failure at kfd_destroy_mqd_cp+0x2a/0x40 [amdgpu] (target:
hqd_destroy_v10_3+0x0/0x260 [amdgpu]; expected type: 0x8594d794)
Clang's kernel Con
They are no longer used so drop them.
Fixes: 498acd86a942ae ("drm/amdgpu: Refactor mode2 reset logic for v11.0.7")
Signed-off-by: Alex Deucher
Cc: Victor Zhao
---
drivers/gpu/drm/amd/amdgpu/sienna_cichlid.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/
Applied. Thanks!
On Thu, Oct 13, 2022 at 2:25 PM Guenter Roeck wrote:
>
> Building 32-bit images may fail with the following error.
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_util_32.c:
> In function ‘dml32_UseMinimumDCFCLK’:
> drivers/gpu/drm/amd/amdgpu/../d
Applied. Thanks!
On Fri, Oct 14, 2022 at 3:03 AM Christian König
wrote:
>
> Am 13.10.22 um 23:07 schrieb Fabio M. De Francesco:
> > The use of kmap() is being deprecated in favor of kmap_local_page().
> >
> > There are two main problems with kmap(): (1) It comes with an overhead as
> > the mappi
Applied. Thanks!
On Sun, Oct 16, 2022 at 1:42 PM Fabio M. De Francesco
wrote:
>
> kmap() is being deprecated in favor of kmap_local_page().
>
> There are two main problems with kmap(): (1) It comes with an overhead as
> mapping space is restricted and protected by a global lock for
> synchroniza
Applied. Thanks!
Alex
On Mon, Oct 17, 2022 at 12:30 PM Nathan Chancellor wrote:
>
> When booting a kernel compiled with CONFIG_CFI_CLANG on a machine with
> an RX 6700 XT, there is a CFI failure in kfd_destroy_mqd_cp():
>
> [ 12.894543] CFI failure at kfd_destroy_mqd_cp+0x2a/0x40 [amdgpu]
Add unlocked variant of dma_buf_vmap/vunmap() that will be utilized
by drivers that don't take the reservation lock explicitly.
Acked-by: Sumit Semwal
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 43 +++
include/li
Prepare DRM prime core to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Reviewed-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_prime.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
dif
Add unlocked variant of dma_buf_map/unmap_attachment() that will
be used by drivers that don't take the reservation lock explicitly.
Acked-by: Sumit Semwal
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 53 +++
inclu
Prepare Etnaviv driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
The new common dma-buf locking convention will require buffer importers
to hold the reservation lock around mapping operations. Make DRM GEM core
to take the lock around the vmapping operations and update DRM drivers to
use the locked functions for the case where DRM core now holds the lock.
This p
All drivers that use dma-bufs have been moved to the updated locking
specification and now dma-buf reservation is guaranteed to be locked
by importers during the mapping operations. There is no need to take
the internal dma-buf lock anymore. Remove locking from the videobuf2
memory allocators.
Ack
Prepare InfiniBand drivers to the common dynamic dma-buf locking
convention by starting to use the unlocked versions of dma-buf API
functions.
Acked-by: Jason Gunthorpe
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/infiniband/core/umem_dmabuf.c | 7 ---
1 file change
Prepare V4L2 memory allocators to the common dynamic dma-buf locking
convention by starting to use the unlocked versions of dma-buf API
functions.
Acked-by: Tomasz Figa
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/media/common/videobuf2/videobuf2-dma-contig.c | 11 +
Add documentation for the dynamic locking convention. The documentation
tells dma-buf API users when they should take the reservation lock and
when not.
Acked-by: Sumit Semwal
Reviewed-by: Christian König
Signed-off-by: Dmitry Osipenko
---
Documentation/driver-api/dma-buf.rst | 6 +++
drivers
Hello,
This series moves all drivers to a dynamic dma-buf locking specification.
>From now on all dma-buf importers are made responsible for holding
dma-buf's reservation lock around all operations performed over dma-bufs
in accordance to the locking specification. This allows us to utilize
reserv
Prepare i915 driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions
and handling cases where importer now holds the reservation lock.
Acked-by: Christian König
Reviewed-by: Michael J. Ruhl
Signed-off-by: Dmitry Osipenko
---
dri
Move dma-buf attachment mapping functions to the dynamic locking
specification by asserting that the reservation lock is held.
Acked-by: Sumit Semwal
Reviewed-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 10 ++
1 file changed, 2 insertions(+), 8 de
Prepare fastrpc to the common dynamic dma-buf locking convention by
starting to use the unlocked versions of dma-buf API functions.
Acked-by: Christian König
Acked-by: Srinivas Kandagatla
Signed-off-by: Dmitry Osipenko
---
drivers/misc/fastrpc.c | 6 +++---
1 file changed, 3 insertions(+), 3 d
Prepare gntdev driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Acked-by: Juergen Gross
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/xen/gntdev-dmabuf.c | 8
1 file changed, 4 insertions(
Prepare Tegra DRM driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/gem.c | 17 +
1 file changed, 9 insertions(+), 8 deleti
Move dma-buf attachment API functions to the dynamic locking specification
by taking the reservation lock around the mapping operations. The strict
locking convention prevents deadlock situations for dma-buf importers and
exporters.
Acked-by: Sumit Semwal
Reviewed-by: Christian König
Signed-off-
Prepare Armada driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/armada/armada_gem.c | 8
1 file changed, 4 insertions(+), 4 deletions(-
The internal dma-buf lock isn't needed anymore because the updated
locking specification claims that dma-buf reservation must be locked
by importers, and thus, the internal data is already protected by the
reservation lock. Remove the obsoleted internal lock.
Acked-by: Sumit Semwal
Acked-by: Chri
Move dma_buf_mmap() function to the dynamic locking specification by
taking the reservation lock. Neither of the today's drivers take the
reservation lock within the mmap() callback, hence it's safe to enforce
the locking.
Acked-by: Sumit Semwal
Acked-by: Christian König
Signed-off-by: Dmitry Os
Prepare OMAP DRM driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletio
Prepare Tegra video decoder driver to the common dynamic dma-buf
locking convention by starting to use the unlocked versions of dma-buf
API functions.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/media/platform/nvidia/tegra-vde/dmabuf-cache.c | 6 +++---
1 file changed,
Move dma_buf_vmap/vunmap() functions to the dynamic locking
specification by asserting that the reservation lock is held.
Acked-by: Sumit Semwal
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 4
1 file changed, 4 insertions(+)
diff --git a/driver
On 2022-10-17 12:13, Hamza Mahfooz wrote:
> Currently, if we encounter unimplemented functions, it is difficult to
> tell what caused them just by looking at dmesg and that is compounded by
> the fact that it is often hard to reproduce said issues, for instance we
> have had reports of this conditi
On 2022-10-06 22:48, Deming Wang wrote:
Using vma_lookup() verifies the start address is contained in the found
vma. This results in easier to read the code.
Thank you for the patches. This and your other patch look good to me.
However, you missed one use of find_vma in svm_range_is_valid.
On Wed, May 11, 2022 at 5:01 PM Christian König
wrote:
>
>
> We have implemented a workaround, but still don't know the exact root cause.
>
> If anybody wants to look into this it would be rather helpful to be able
> to reproduce the issue.
>
> Regards,
> Christian.
I see that issue was returned
[AMD Official Use Only - General]
Reviewed-by: Evan Quan
> -Original Message-
> From: Rafael Mendonca
> Sent: Tuesday, October 18, 2022 8:54 AM
> To: Quan, Evan ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter
> Cc: Rafael Mendonca ; amd-
> g.
Hi Alex,
Could you help review this patch? Thanks.
Best Regards,
Yubiao Wang
-Original Message-
From: Koenig, Christian
Sent: Friday, October 14, 2022 3:08 PM
To: Wang, YuBiao ; amd-gfx@lists.freedesktop.org
Cc: Grodzovsky, Andrey ; Quan, Evan
; Chen, Horace ; Tuikov, Luben
; Deucher
Enable RAS EEPROM support for smu v13_0_0 and v13_0_10.
Signed-off-by: Candice Li
Reviewed-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c
b/drivers/gpu/drm/amd/a
1. Update EEPROM_I2C_MADDR_SMU_13_0_0 to EEPROM_I2C_MADDR_54H
2. Add EEPROM I2C address support for smu v13_0_0 and v13_0_10.
Signed-off-by: Candice Li
Reviewed-by: Tao Zhou
---
.../gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c| 20 +--
1 file changed, 18 insertions(+), 2 deletions
Reviewed-by: Guchun Chen
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Tuesday, October 18, 2022 12:48 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Zhao, Victor
Subject: [PATCH] drm/amdgpu/sienna_cichlid: drop unused variables
They
[AMD Official Use Only - General]
>> + /* dequeue sched pipe via kiq */
>> + void(*kiq_dequeue_sched)(struct
>> amdgpu_device *adev);
>> +
It's unnecessary to expose a new callback function proto to perform dequeuing
scheduler queue,
for kiq_fini or mes_
MMHUB 2.1.x versions don't have ATCL2. Remove accesses to ATCL2 registers.
Since they are non-existing registers, read access will cause a
'Completer Abort' and gets reported when AER is enabled with the below patch.
Tagging with the patch so that this is backported along with it.
Fixes: 8795e182
On 10/18/2022 10:51 AM, Greg KH wrote:
On Tue, Oct 18, 2022 at 10:17:24AM +0530, Lijo Lazar wrote:
MMHUB 2.1.x versions don't have ATCL2. Remove accesses to ATCL2 registers.
Since they are non-existing registers, read access will cause a
'Completer Abort' and gets reported when AER is enable
[Why]
If mes is not dequeued during fini, mes will be in an uncleaned state
during reload, then mes couldn't receive some commands which leads to
reload failure.
[How]
Perform MES dequeue via MMIO after all the unmap jobs are done by mes
and before kiq fini.
v3: Move the dequeue operation inside
MMHUB 2.1.x versions don't have ATCL2. Remove accesses to ATCL2 registers.
Since they are non-existing registers, read access will cause a
'Completer Abort' and gets reported when AER is enabled with the below patch.
Tagging with the patch so that this is backported along with it.
Fixes: 8795e182
Reviewed-by: Guchun Chen
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Lijo Lazar
Sent: Tuesday, October 18, 2022 1:41 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; helg...@kernel.org;
sta...@vger.kernel.org; Chen, Guchun ; Zhang, Hawking
Subject: [PAT
Please ignore this one. A newer one with the correct format is sent.
Thanks,
Lijo
On 10/18/2022 10:17 AM, Lijo Lazar wrote:
MMHUB 2.1.x versions don't have ATCL2. Remove accesses to ATCL2 registers.
Since they are non-existing registers, read access will cause a
'Completer Abort' and gets rep
If the number of pages from the userptr BO differs from the SG BO then the
allocated memory for the SG table doesn't get freed before returning
-EINVAL, which may lead to a memory leak in some error paths. Fix this by
checking the number of pages before allocating memory for the SG table.
Fixes: 2
Hi,
The function vma_lookup show below. Vma valid check is included in it. Or,
What other questions do you have?
static inline
struct vm_area_struct *vma_lookup(struct mm_struct *mm, unsigned long addr)
{
struct vm_area_struct *vma = find_vma(mm, addr);
if (vma && addr < vma-
On Tue, Oct 18, 2022 at 10:17:24AM +0530, Lijo Lazar wrote:
> MMHUB 2.1.x versions don't have ATCL2. Remove accesses to ATCL2 registers.
>
> Since they are non-existing registers, read access will cause a
> 'Completer Abort' and gets reported when AER is enabled with the below patch.
> Tagging wit
Commit 902bc65de0b3 ("drm/amdgpu/powerplay/psm: return an error in power
state init") made the power state init function return early in case of
failure to get an entry from the powerplay table, but it missed to clean up
the allocated memory for the current power state before returning.
Fixes: 902
On 10/17/22 20:22, Dmitry Osipenko wrote:
> Hello,
>
> This series moves all drivers to a dynamic dma-buf locking specification.
> From now on all dma-buf importers are made responsible for holding
> dma-buf's reservation lock around all operations performed over dma-bufs
> in accordance to the lo
65 matches
Mail list logo
