[AMD Official Use Only - General]
Thank you for your suggestion, I will split these two patches in the next
version.
Regards,
Horatio
-Original Message-
From: Zhou1, Tao
Sent: Monday, May 15, 2023 2:38 PM
To: Zhang, Horatio ; amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Xu, Feif
When testing sdma ib ring fails to detect sdma
hang for sdma fed error, force to perform soft
reset.
V2:
Add poison mode support check for special code
path.
Signed-off-by: YiPeng Chai
---
drivers/gpu/drm/amd/amdgpu/sdma_v6_0.c | 19 +++
1 file changed, 19 insertions(+)
dif
[AMD Official Use Only - General]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Chai, Thomas
Sent: Monday, May 15, 2023 15:17
To: amd-gfx@lists.freedesktop.org
Cc: Chai, Thomas ; Zhang, Hawking ;
Zhou1, Tao ; Li, Candice ; Yang, Stanley
; Chai, Thomas
Subject
No need cast (void*) to (struct amdgpu_device *).
Signed-off-by: Su Hui
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 2 +-
drivers/gp
On Mon, May 15, 2023 at 09:34:28AM +0800, Su Hui wrote:
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> index f60753f97ac5..c837e0bf2cfc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu
No invocation of get_user_pages() use the vmas parameter, so remove it.
The GUP API is confusing and caveated. Recent changes have done much to
improve that, however there is more we can do. Exporting vmas is a prime
target as the caller has to be extremely careful to preclude their use
after the
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Exynos does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirel
Many fbdev drivers use the same set of fb_ops helpers. Add Kconfig
options to select them at once. This will help with making DRM's
fbdev emulation code more modular, but can also be used to simplify
fbdev's driver configs.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/Kconfig | 21 ++
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Armada does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirel
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Gma500 does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirel
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Radeon does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirel
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Omapdrm does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entire
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Fbdev-dma does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions enti
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Fbdev-generic was the only caller of the
DRM helpers, so remove them from the helper module.
v2:
* use FB_SYS_HELPERS_DEFERRED option
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/Kconfig
DRM provides a number of wrappers around fbdev cfb_() sys_(), fb_io_()
and fb_sys_() helpers. The DRM functions don't provide any additional
functionality for most DRM drivers. So remove them and call the fbdev
I/O helpers directly.
The DRM fbdev I/O wrappers were originally added because
does no
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. i915 was the only caller of the DRM
helpers, so remove them from the helper module.
v2:
* use FB_IO_HELPERS options
Signed-off-by: Thomas Zimmermann
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Viv
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Msm does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.
Export drm_fb_helper_damage() and drm_fb_helper_damage_range(), which
handle damage areas for fbdev emulation. This is a temporary export
that allows to move the DRM I/O helpers for fbdev into drivers. Only
fbdev-generic and i915 need them. Both will be updated to implement
damage handling by thems
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Tegra does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely
[AMD Official Use Only - General]
The MQD data in VRAM would be lost after S3, for the MQD bo is pinned down as
kernel bo and can't be evicted to system memory.
AFAIK, driver should not to do allocate/free memory during S3, as there are
issues observed to do memory allocation during S3.
Regar
Looks good:
Reviewed-by: Christoph Hellwig
On 5/11/23 21:39, Sasha Levin wrote:
> From: Wesley Chalmers
>
> [ Upstream commit 474f01015ffdb74e01c2eb3584a2822c64e7b2be ]
>
> [WHY]
> Writing to DRR registers such as OTG_V_TOTAL_MIN on the same frame as a
> pipe commit can cause underflow.
>
> [HOW]
> Move DMUB p-state delegate into optimz
On Mon, May 15, 2023 at 6:40 AM Xiao, Jack wrote:
>
> [AMD Official Use Only - General]
>
> The MQD data in VRAM would be lost after S3, for the MQD bo is pinned down
> as kernel bo and can't be evicted to system memory.
> AFAIK, driver should not to do allocate/free memory during S3, as there a
[Public]
Hi all,
This week this patchset was tested on the following systems:
Lenovo ThinkPad T14s Gen2, with AMD Ryzen 5 5650U
Lenovo ThinkBook T13s Gen4 with AMD Ryzen 5 6600U
Reference AMD RX6800
These systems were tested on the following display types:
eDP, (1080p 60hz [5650U]) (1920x1
On Mon, May 15, 2023 at 3:17 AM Dan Carpenter wrote:
>
> On Mon, May 15, 2023 at 09:34:28AM +0800, Su Hui wrote:
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > index f60753f97ac5..c837e0bf2cfc 100644
> > --- a/drivers/gpu/drm/amd
From: Rob Clark
Similar motivation to other similar recent attempt[1]. But with an
attempt to have some shared code for this. As well as documentation.
It is probably a bit UMA-centric, I guess devices with VRAM might want
some placement stats as well. But this seems like a reasonable start.
From: Rob Clark
Signed-off-by: Rob Clark
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h | 2 +-
3 files changed, 9 insertions(+), 12 deletions(-)
On Thu, May 11, 2023 at 9:38 PM Linus Lüssing wrote:
>
> Hi,
>
> Initially noticed this in some games, which seem to be a bit lazy
> with their VRAM allocations + freeing, that performance would drop
> dramatically / become unusable once the VRAM is full and GTT gets
> used. For instance in No Man
On Mon, May 15, 2023 at 10:42 AM Alex Deucher wrote:
>
> On Thu, May 11, 2023 at 9:38 PM Linus Lüssing
> wrote:
> >
> > Hi,
> >
> > Initially noticed this in some games, which seem to be a bit lazy
> > with their VRAM allocations + freeing, that performance would drop
> > dramatically / become u
On Mon, May 15, 2023 at 10:11:39AM -0400, Alex Deucher wrote:
> On Mon, May 15, 2023 at 3:17 AM Dan Carpenter
> wrote:
> >
> > On Mon, May 15, 2023 at 09:34:28AM +0800, Su Hui wrote:
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.
[AMD Official Use Only - General]
Yes, it should work. If that, the routine would behave like *reset*. That means
driver would behave like to create a new queue instead of restoring a saved
queue. I can have a try with this solution.
Regards,
Jack
From: Alex Deu
On Mon, May 15, 2023 at 11:02 AM Xiao, Jack wrote:
>
> [AMD Official Use Only - General]
>
>
> Yes, it should work. If that, the routine would behave like *reset*. That
> means driver would behave like to create a new queue instead of restoring a
> saved queue. I can have a try with this solutio
Hi Thomas,
On Mon, May 15, 2023 at 11:40:24AM +0200, Thomas Zimmermann wrote:
> Use the regular fbdev helpers for framebuffer I/O instead of DRM's
> helpers. Exynos does not use damage handling, so DRM's fbdev helpers
> are mere wrappers around the fbdev code.
>
> By using fbdev helpers directly
Hi Thomas,
On Mon, May 15, 2023 at 11:40:23AM +0200, Thomas Zimmermann wrote:
> Use the regular fbdev helpers for framebuffer I/O instead of DRM's
> helpers. Armada does not use damage handling, so DRM's fbdev helpers
> are mere wrappers around the fbdev code.
>
> By using fbdev helpers directly
On Mon, May 15, 2023 at 07:55:44PM +0200, Sam Ravnborg wrote:
> Hi Thomas,
>
> On Mon, May 15, 2023 at 11:40:23AM +0200, Thomas Zimmermann wrote:
> > Use the regular fbdev helpers for framebuffer I/O instead of DRM's
> > helpers. Armada does not use damage handling, so DRM's fbdev helpers
> > are
On Sun, May 14, 2023, Lorenzo Stoakes wrote:
> No invocation of get_user_pages() use the vmas parameter, so remove it.
>
> The GUP API is confusing and caveated. Recent changes have done much to
> improve that, however there is more we can do. Exporting vmas is a prime
> target as the caller has t
From: Hawking Zhang
Avoid access null xcp_mgr pointer.
Signed-off-by: Hawking Zhang
Reviewed-by: Lijo Lazar
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kf
From: Hawking Zhang
Not all the asic needs xcp. ensure check xcp availabity
before accessing its member.
v2: add missing change in kfd_topology.c
Signed-off-by: Hawking Zhang
Reviewed-by: Le Ma
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 8
drivers/
[AMD Official Use Only - General]
> -Original Message-
> From: amd-gfx On Behalf Of Ma
> Jun
> Sent: Monday, May 15, 2023 2:14 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Sierra Guiza, Alejandro (Alex) ; Ma, Jun
> ; Kuehling, Felix ; Koenig,
> Christian
> Subject: [PATCH] drm/amdgpu: Fi
Applied. Thanks!
Alex
On Mon, May 15, 2023 at 3:18 AM Su Hui wrote:
>
> No need cast (void*) to (struct amdgpu_device *).
>
> Signed-off-by: Su Hui
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 ++--
> drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/
Applied. Thanks!
Alex
On Sat, May 13, 2023 at 8:54 AM Bas Nieuwenhuizen
wrote:
>
> None have been defined yet, so reject anybody setting any. Mesa sets
> it to 0 anyway.
>
> Signed-off-by: Bas Nieuwenhuizen
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4
> 1 file changed, 4 insertion
On 5/3/23 16:15, Sukrut Bellary wrote:
> smatch warning -
> 1) drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:3615 gfx_v9_0_kiq_resume()
> warn: inconsistent returns 'ring->mqd_obj->tbo.base.resv'.
>
> 2) drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:6901 gfx_v10_0_kiq_resume()
> warn: inconsistent returns 'rin
There will be a double check for the hotspot temperature on delay
expired. This can avoid unintended shutdown due to hotspot temperature
spark.
Signed-off-by: Evan Quan
--
v1->v2:
- add the proper millidegree Celsius to degree Celsius transform
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h
Add ras_poison_irq and functions.
Suggested-by: Hawking Zhang
Signed-off-by: Horatio Zhang
---
drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
b/drivers/gpu/drm/amd/amdgpu/
Separate vcn RAS poison consumption handling from the instance irq, and
register dedicated ras_poison_irq src and funcs for UVD_POISON.
v2:
- Separate ras irq from vcn instance irq
- Improve the subject and code comments
v3:
- Split the patch into three parts
- Improve the code comments
Suggeste
Add ras_poison_irq and functions. And fix the amdgpu_irq_put
call trace in vcn_v4_0_hw_fini.
[ 44.563572] RIP: 0010:amdgpu_irq_put+0xa4/0xc0 [amdgpu]
[ 44.563629] RSP: 0018:b36740edfc90 EFLAGS: 00010246
[ 44.563630] RAX: RBX: 0001 RCX:
[ 44
Separate jpegbRAS poison consumption handling from the instance irq, and
register dedicated ras_poison_irq src and funcs for UVD_POISON.
v2:
- Separate ras irq from jpeg instance irq
- Improve the subject and code comments
v3:
- Split the patch into three parts
- Improve the code comments
Sugges
Add ras_poison_irq and functions.
Suggested-by: Hawking Zhang
Signed-off-by: Horatio Zhang
---
drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c | 27 --
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c
b/drivers/gpu/drm/amd/amd
Add ras_poison_irq and functions. And fix the amdgpu_irq_put
call trace in jpeg_v4_0_hw_fini.
[ 50.497562] RIP: 0010:amdgpu_irq_put+0xa4/0xc0 [amdgpu]
[ 50.497619] RSP: 0018:aa2400fcfcb0 EFLAGS: 00010246
[ 50.497620] RAX: RBX: 0001 RCX:
[ 5
[AMD Official Use Only - General]
The series is:
Reviewed-by: Tao Zhou
> -Original Message-
> From: amd-gfx On Behalf Of Horatio
> Zhang
> Sent: Tuesday, May 16, 2023 1:04 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, HaoPing (Alan) ; Zhou, Bob
> ; Zhang, Horatio ; Xu, Feifei
> ; Z
On 5/16/2023 5:03 AM, Deucher, Alexander wrote:
> [AMD Official Use Only - General]
>
>> -Original Message-
>> From: amd-gfx On Behalf Of Ma
>> Jun
>> Sent: Monday, May 15, 2023 2:14 AM
>> To: amd-gfx@lists.freedesktop.org
>> Cc: Sierra Guiza, Alejandro (Alex) ; Ma, Jun
>> ; Kuehling,
51 matches
Mail list logo
