[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Asad Kamal
Thanks & Regards
Asad
-Original Message-
From: Lazar, Lijo
Sent: Tuesday, January 21, 2025 1:12 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander
; Kamal, Asad ; Wang,
Yang(Kev
Fix the initialization and usage of SMU v13.0.6 capability values. Use
caps_set/clear functions to set/clear capability.
Also, fix SET_UCLK_MAX capability on APUs, it is supported on APUs.
Signed-off-by: Lijo Lazar
Reviewed-by: Alex Deucher
Reviewed-by: Yang Wang
Fixes: 9bb53d2ce109 ("drm/amd
This commit adds the cleaner shader microcode for GFX10.1.0 GPUs. The
cleaner shader is a piece of GPU code that is used to clear or
initialize certain GPU resources, such as Local Data Share (LDS), Vector
General Purpose Registers (VGPRs), and Scalar General Purpose Registers
(SGPRs).
Clearing th
use job && job->vm to check ib has vmid and use job && job->vmid to
check if switch buffer should be emitted
Signed-off-by: Lin.Cao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
b/driv
On 1/13/2025 9:10 AM, Jiang Liu wrote:
> When GPU suspend is aborted, do the same for dGPU as APU to reset
> soc15 asic. Otherwise it may cause following errors:
> [ 547.229463] amdgpu 0001:81:00.0: [drm:amdgpu_ring_test_helper [amdgpu]]
> *ERROR* ring kiq_0.2.1.0 test failed (-110)
>
> [ 55
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Yang Wang
Best Regards,
Kevin
-Original Message-
From: Lazar, Lijo
Sent: Tuesday, January 21, 2025 13:39
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander
; Kamal, Asad ; Wang,
Yang(Kevin) ;
Fix the initialization and usage of SMU v13.0.6 capability values. Use
caps_set/clear functions to set/clear capability.
Also, fix SET_UCLK_MAX capability on APUs, it is supported on APUs.
Signed-off-by: Lijo Lazar
Reviewed-by: Alex Deucher
Fixes: 9bb53d2ce109 ("drm/amd/pm: Add capability flag
On 1/12/2025 21:40, Jiang Liu wrote:
When GPU suspend is aborted, do the same for dGPU as APU to reset
soc15 asic. Otherwise it may cause following errors:
[ 547.229463] amdgpu 0001:81:00.0: [drm:amdgpu_ring_test_helper [amdgpu]]
*ERROR* ring kiq_0.2.1.0 test failed (-110)
[ 555.126827] amdgp
On Fri, Jan 10, 2025 at 01:23:40PM -0800, James Jones wrote:
> On 12/19/24 10:03, Simona Vetter wrote:
> > On Thu, Dec 19, 2024 at 09:02:27AM +, Daniel Stone wrote:
> >> On Wed, 18 Dec 2024 at 10:32, Brian Starkey wrote:
> >>> On Wed, Dec 18, 2024 at 11:24:58AM +, Simona Vetter wrote:
> >>
On Tue, Dec 17, 2024 at 11:13:05AM +0100, Michel Dänzer wrote:
> On 2024-12-17 10:14, Brian Starkey wrote:
> > On Sun, Dec 15, 2024 at 03:53:14PM +, Marek Olšák wrote:
> >> The comment explains the problem with DRM_FORMAT_MOD_LINEAR.
> >>
> >> Signed-off-by: Marek Olšák
> >>
> >> diff --git a/
On Mon, Jan 20, 2025 at 08:58:20AM +0100, Thomas Zimmermann wrote:
> Am 18.01.25 um 03:37 schrieb Marek Olšák:
> [...]
> >
> > 3) Implementing DRM_FORMAT_MOD_LINEAR as having 256B pitch and offset
> > alignment. This is what we do today. Even if Intel and some AMD chips
> > can do 64B or 128B ali
Some minor comments below, apart from that looks good!
Typo in the commit title: s/supports/support/
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 5ef87cb5b242..316c643e0dea 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -913
[Public]
> -Original Message-
> From: amd-gfx On Behalf Of Pavel
> Nikulin
> Sent: Sunday, January 19, 2025 2:29 PM
> To: Alex Deucher
> Cc: amd-gfx@lists.freedesktop.org
> Subject: Re: drm/amdgpu: AMDGPU unusable since 6.12.1 and it looks like no one
> cares.
>
> On Sun, Jan 19, 2025 at
From: Mario Limonciello
The message in amdgpu_dm about seamless boot is about an ASIC version
check and module parameter check. It doesn't actually mean that seamless
boot will work.
Push this message into debug to avoid being disingenuous about it working
until it's been tested.
Signed-off-by
From: Mario Limonciello
mark_seamless_boot_stream() can be called multiple times to run
the more expensive checks in dc_validate_boot_timing().
Refactor the function so that if those have already passed once
the function isn't called again.
Also add a message the first time that they have passe
From: Mario Limonciello
dc_validate_boot_timing() runs through an exhaustive list of checks to
determine whether a boot stream can be marked as seamless. When the
checks fail, a user will be left guessing what the reason was
Add debug statements that will be helpful to validate the specific
reas
From: Mario Limonciello
`DC_LOG_INFO` will wrap `drm_info()` and be used for the typical
`INFO` level printk messages but in DC code.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/display/include/logger_types.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/
Am 20.01.2025 um 11:35:07 Uhr schrieb Alex Deucher:
> On Thu, Jan 16, 2025 at 11:57 AM Marco Moock wrote:
> >
> > Am 16.01.2025 um 11:32:42 Uhr schrieb Alex Deucher:
> >
> > > I'd like to see the driver messages leading up to that.
> >
> > I've now attached the entire dmesg without the firewall s
Consolidate PM4 definitions. Most of these were previously
only defined in UMDs. Add them here as well and sync with
latest packets. Also no need to include soc15d.h on gfx10+.
Suggested-by: Saurabh Verma
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 1 -
drivers
Am 20.01.25 um 18:13 schrieb Danilo Krummrich:
On Mon, Jan 20, 2025 at 04:52:37PM +, Tvrtko Ursulin wrote:
Idea is to add a helper for popping jobs from the entity with the goal
of making amdgpu use it in the next patch. That way amdgpu will decouple
itself a tiny bit more from scheduler imp
On Mon, Jan 20, 2025 at 08:58:20AM +0100, Thomas Zimmermann wrote:
> Hi
>
>
> Am 18.01.25 um 03:37 schrieb Marek Olšák:
> [...]
> >
> > 3) Implementing DRM_FORMAT_MOD_LINEAR as having 256B pitch and offset
> > alignment. This is what we do today. Even if Intel and some AMD chips
> > can do 64B o
On Mon, Jan 20, 2025 at 04:52:39PM +, Tvrtko Ursulin wrote:
> The code assumes queue node is the first element in struct
> drm_sched_job.
I'd add that this assumption lies in doing the NULL check after the
container_of(). Without saying that, it might not be that obvious.
> Since this is not
On Mon, Jan 20, 2025 at 04:52:37PM +, Tvrtko Ursulin wrote:
> Idea is to add a helper for popping jobs from the entity with the goal
> of making amdgpu use it in the next patch. That way amdgpu will decouple
> itself a tiny bit more from scheduler implementation details.
I object to adding thi
On 1/20/2025 10:13 AM, Philip Yang wrote:
On 2025-01-15 16:40, Xiaogang.Chen wrote:
From: Xiaogang Chen
Current svm_migrate_copy_to_vram handles sys pages(src) and dst pages (vram)
discontinuation in different way. When src got discontinuity migrates j pages
that ith page is not migrated; Wh
[Public]
Reviewed-by: Roman Li
> -Original Message-
> From: SHANMUGAM, SRINIVASAN
> Sent: Wednesday, January 15, 2025 12:07 PM
> To: Siqueira, Rodrigo ; Pillai, Aurabindo
>
> Cc: amd-gfx@lists.freedesktop.org; SHANMUGAM, SRINIVASAN
> ; Li, Sun peng (Leo)
> ; Chung, ChiaHsuan (Tom)
> ;
On Thu, Jan 16, 2025 at 11:57 AM Marco Moock wrote:
>
> Am 16.01.2025 um 11:32:42 Uhr schrieb Alex Deucher:
>
> > I'd like to see the driver messages leading up to that.
>
> I've now attached the entire dmesg without the firewall stuff.
Does the attached test patch help?
Alex
>
> --
> Gruß
> M
On 2025-01-15 16:40, Xiaogang.Chen
wrote:
From: Xiaogang Chen
Current svm_migrate_copy_to_vram handles sys pages(src) and dst pages (vram)
discontinuation in different way. When src got discontinuity migrates j pages
that ith page is not migrated; When dst
On 2025-01-15 06:01, Christian König
wrote:
Am
14.01.25 um 15:53 schrieb Philip Yang:
SVM migration unmap pages from GPU and
then update mapping to GPU to
recover page fault. Currently unmap clears the PDE entry for
On Mon, Jan 20, 2025 at 6:17 AM Lijo Lazar wrote:
>
> Fix the initialization and usage of SMU v13.0.6 capability values. Use
> caps_set/clear functions to set/clear capability.
>
> Also, fix SET_UCLK_MAX capability on APUs, it is supported on APUs.
>
> Signed-off-by: Lijo Lazar
>
> Fixes: 9bb53d2
On Sun, Jan 19, 2025 at 3:25 PM SyntheticBird
wrote:
>
>
> Hello,
>
> One person on the Gitlab issue have potentially bisected the commit causing
> the kernel freeze:
> https://gitlab.freedesktop.org/drm/amd/-/issues/3787#note_2741901
>
> https://gitlab.freedesktop.org/drm/kernel/-/commit/de848d
On Mon, Jan 20, 2025 at 2:52 AM Perry Yuan wrote:
>
> GCC raises a parameter compatibility error log for the
> amdgpu_vkms_early_init function because it previously accepted
> a generic `void *handle` parameter. This change updates the
> function signature to accept a specific `struct amdgpu_ip_bl
Hello Alex Deucher,
Commit 8fae3b201fee ("drm/amdgpu: cache gpu pcie link width") from
Jan 6, 2025 (linux-next), leads to the following Smatch static
checker warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:6193
amdgpu_device_gpu_bandwidth()
error: we previously assumed 'paren
From: Pierre-Eric Pelloux-Prayer
commit 6fb15dcbcf4f212930350eaee174bb60ed40a536 upstream.
The call to radeon_vm_clear_freed might clear bo_va->bo, so
we have to check it before dereferencing it.
Signed-off-by: Pierre-Eric Pelloux-Prayer
Acked-by: Alex Deucher
Signed-off-by: Alex Deucher
[De
Am 20.01.25 um 14:38 schrieb Srinivasan Shanmugam:
If the parent is NULL, adev->pdev is used to retrieve the PCIe speed and
width, ensuring that the function can still determine these
capabilities from the device itself.
Fixes the below:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:6193 amdgpu_de
[Public]
Hi all,
This week this patchset was tested on 4 systems, two dGPU and two APU based,
and tested across multiple display and connection types.
APU
* Single Display eDP -> 1080p 60hz, 2560x1600 120hz, 1920x1200 165hz
* Single Display DP (SST DSC) -> 4k144hz, 4k240hz
On 1/20/2025 7:08 PM, Srinivasan Shanmugam wrote:
> If the parent is NULL, adev->pdev is used to retrieve the PCIe speed and
> width, ensuring that the function can still determine these
> capabilities from the device itself.
>
> Fixes the below:
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:61
If the parent is NULL, adev->pdev is used to retrieve the PCIe speed and
width, ensuring that the function can still determine these
capabilities from the device itself.
Fixes the below:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:6193 amdgpu_device_gpu_bandwidth()
error: we previously ass
Am 20.01.25 um 14:31 schrieb Srinivasan Shanmugam:
If the parent is NULL, adev->pdev is used to retrieve the PCIe speed and
width, ensuring that the function can still determine these
capabilities from the device itself.
Fixes the below:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:6193 amdgpu_de
If the parent is NULL, adev->pdev is used to retrieve the PCIe speed and
width, ensuring that the function can still determine these
capabilities from the device itself.
Fixes the below:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:6193 amdgpu_device_gpu_bandwidth()
error: we previously ass
[Public]
Pls ignore v2,
-Original Message-
From: SHANMUGAM, SRINIVASAN
Sent: Monday, January 20, 2025 6:42 PM
To: Koenig, Christian ; Deucher, Alexander
Cc: amd-gfx@lists.freedesktop.org; SHANMUGAM, SRINIVASAN
; Dan Carpenter ;
Lazar, Lijo
Subject: [PATCH v2] drm/amd/amdgpu: Prevent
If the parent is NULL, adev->pdev is used to retrieve the PCIe speed and
width, ensuring that the function can still determine these
capabilities from the device itself.
Fixes the below:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:6193 amdgpu_device_gpu_bandwidth()
error: we previously assu
Am 20.01.25 um 13:32 schrieb Srinivasan Shanmugam:
This commit adds an early return if no upstream bridge is found, setting
the speed and width to PCI_SPEED_UNKNOWN and PCIE_LNK_WIDTH_UNKNOWN,
respectively. This ensures that the function handles the absence of an
upstream bridge gracefully.
F
On 1/20/2025 6:02 PM, Srinivasan Shanmugam wrote:
> This commit adds an early return if no upstream bridge is found, setting
> the speed and width to PCI_SPEED_UNKNOWN and PCIE_LNK_WIDTH_UNKNOWN,
> respectively. This ensures that the function handles the absence of an
> upstream bridge gracefull
This commit adds an early return if no upstream bridge is found, setting
the speed and width to PCI_SPEED_UNKNOWN and PCIE_LNK_WIDTH_UNKNOWN,
respectively. This ensures that the function handles the absence of an
upstream bridge gracefully.
Fixes the below:
drivers/gpu/drm/amd/amdgpu/amdgpu_device
Fix the initialization and usage of SMU v13.0.6 capability values. Use
caps_set/clear functions to set/clear capability.
Also, fix SET_UCLK_MAX capability on APUs, it is supported on APUs.
Signed-off-by: Lijo Lazar
Fixes: 9bb53d2ce109 ("drm/amd/pm: Add capability flags for SMU v13.0.6")
---
v1:
Am 17.01.25 um 08:55 schrieb Jiang Liu:
Introduce amdgpu_device_fini_schedulers() to clean scheduler related
resources, and avoid possible invalid memory access.
Signed-off-by: Jiang Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 35 +++---
drivers/gpu/drm/amd/amdgpu/am
Am 17.01.25 um 07:05 schrieb cao, lin:
[AMD Official Use Only - AMD Internal Distribution Only]
-Original Message-
From: Lin.Cao
Sent: Tuesday, January 14, 2025 6:06 PM
To: amd-gfx@lists.freedesktop.org
Cc: Koenig, Christian ; Deucher, Alexander
; cao, lin
Subject: [PATCH] drm/amdgpu:
On Fri, Jan 17, 2025 at 6:08 PM Alex Deucher wrote:
>
> On Fri, Jan 17, 2025 at 7:27 AM Pavel Nikulin wrote:
> >
> > I think it persists as of 6.12.9 and today's firmware version from git.
> >
> > Hardware Asus um560.6
> >
> > It only happens when the AC adaptor is disconnected, and the screen
>
Hello,
One person on the Gitlab issue have potentially bisected the commit causing the
kernel freeze: https://gitlab.freedesktop.org/drm/amd/-/issues/3787#note_2741901
https://gitlab.freedesktop.org/drm/kernel/-/commit/de848da12f752170c2ebe114804a985314fd5a6a
Also I apologize Alex I think I s
On Sun, Jan 19, 2025 at 5:53 PM Pavel Nikulin wrote:
>
> On Fri, Jan 17, 2025 at 6:08 PM Alex Deucher wrote:
> >
> > On Fri, Jan 17, 2025 at 7:27 AM Pavel Nikulin wrote:
> > >
> > > I think it persists as of 6.12.9 and today's firmware version from git.
> > >
> > > Hardware Asus um560.6
> > >
>
50 matches
Mail list logo