eedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander
; Sun, Ce(Overlord)
Subject: Re: [PATCH v3] drm/amdgpu: Save and restore switch state
On 8/1/2025 6:10 PM, Lijo Lazar wrote:
> During a DPC error kernel waits for the link to be active before
> notifying downstream devices. On certain pla
On 08/02, Timur Kristóf wrote:
> On DCE 6, DP audio was not working. However, it worked when an
> HDMI monitor was also plugged in.
>
> Looking at dce_aud_wall_dto_setup it seems that the main
> difference is that we use DTO1 when only DP is plugged in.
>
> When programming DTO1, it uses audio_dt
On Thu, 2025-08-07 at 16:34 -0400, Harry Wentland wrote:
>
>
> On 2025-08-07 15:12, Harry Wentland wrote:
> > On 2025-07-23 11:58, Timur Kristóf wrote:
> > > Analog displays typically have a DDC connection which can be
> > > used by the GPU to read EDID. This commit adds the capability
> > > to p
On 2025-08-04 7:05, Zhu Lingshan wrote:
> This commit removes test_kq() function becuse it has been
> marked as unused since 2014 and no other functions calls it.
>
> Signed-off-by: Zhu Lingshan
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 31 ---
On 2025-08-04 7:05, Zhu Lingshan wrote:
> This commit remove DIQ support because it has been
> marked as DEPRECATED since 2022 in commit 5bdd3eb2
I think you can also remove KFD_QUEUE_TYPE_DIQ from enum kfd_queue_type in
kfd_priv.h.
See two more comments inline ...
>
> Signed-off-by: Zhu Ling
On 2025-08-04 7:05, Zhu Lingshan wrote:
> This commit finds the proper kfd_process by
> filep->private_data in kfd_mmap,
> because the function kfd_get_process()
> can not locate a specific kfd process among
> multiple contexts.
>
> Signed-off-by: Zhu Lingshan
Reviewed-by: Felix Kuehling
> ---
On 2025-08-04 7:05, Zhu Lingshan wrote:
> In kq_initialize, queue->process of a HIQ should
> be set to NULL because it does not belong to any kfd_process.
>
> This commit decommisions the function kfd_get_process() because
> it can not locate a specific kfd_process among multiple
> contexts and n
On 2025-08-04 7:05, Zhu Lingshan wrote:
> This commit introduces a new id field for
> struct kfd process, which helps identify
> a kfd process among multiple contexts that
> all belong to a single user space program.
>
> The sysfs entry of a secondary kfd process
> is placed under the sysfs entry
On 2025-08-07 15:12, Harry Wentland wrote:
> On 2025-07-23 11:58, Timur Kristóf wrote:
>> Analog displays typically have a DDC connection which can be
>> used by the GPU to read EDID. This commit adds the capability
>> to probe analog displays using DDC, reading the EDID header and
>> deciding w
On 2025-07-23 11:58, Timur Kristóf wrote:
> Analog displays typically have a DDC connection which can be
> used by the GPU to read EDID. This commit adds the capability
> to probe analog displays using DDC, reading the EDID header and
> deciding whether the analog link is connected based on the dat
On 07.08.25 16:00, David Francis wrote:
> Add new GEM_OP_IOCTL option GET_MAPPING_INFO, which
> returns a list of mappings associated with a given bo, along with
> their positions and offsets.
>
> Signed-off-by: David Francis
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 97 ++
WR(DRM_COMMAND_BASE +
> DRM_AMDGPU_GEM_BO_INFO, struct drm_amdgpu_gem_bo_info)
>
> /**
> * DOC: memory domains
> @@ -811,6 +813,37 @@ struct drm_amdgpu_gem_op {
> __u64 value;
> };
>
> +#define AMDGPU_GEM_BO_INFO_FLAG_IS_IMPORT(1 << 0)
> +
>
On 8/7/25 9:10 AM, Christian Zigotzky wrote:
> I bisected today.
>
> git clone https://gitlab.freedesktop.org/drm/kernel a
>
> git bisect start
>
> git bisect good 2f29b5c231011b94007d2c8a6d793992f2275db1
> (Good: video: screen_info: Relocate framebuffers behind PCI bridges)
>
> git bisect bad
On Thu, 7 Aug 2025 at 14:22, Alex Deucher wrote:
>
> On Thu, Aug 7, 2025 at 9:13 AM Brahmajit Das wrote:
> >
> > Hello Alex, Christian,
> >
> > I'm a mentee at Linux kernel Bug Fixing Summer 2025. I came across the
> > TODO list on the kernel doc, and specifically this section[0]. Would
> > amdgp
On Thu, Aug 7, 2025 at 9:13 AM Brahmajit Das wrote:
>
> Hello Alex, Christian,
>
> I'm a mentee at Linux kernel Bug Fixing Summer 2025. I came across the
> TODO list on the kernel doc, and specifically this section[0]. Would
> amdgpu be open to this conversion. I saw that before starting it is
> r
On 07.08.25 15:22, Alex Deucher wrote:
> On Thu, Aug 7, 2025 at 9:13 AM Brahmajit Das wrote:
>>
>> Hello Alex, Christian,
>>
>> I'm a mentee at Linux kernel Bug Fixing Summer 2025. I came across the
>> TODO list on the kernel doc, and specifically this section[0]. Would
>> amdgpu be open to this c
On 07.08.25 15:01, oushixiong wrote:
> Should we move audio disabling to hw_fini()?
Yes and when you look at the patch Alex pointed out that is pretty much exactly
what it does.
So still good catch from your side, but a fix is already in the pipeline.
Regards,
Christian.
>
> Regards,
> Shixio
On Thu, Aug 7, 2025 at 5:53 AM wrote:
>
> From: Shixiong Ou
>
> When Stopping lightdm and removing amdgpu driver are executed, the following
> error is triggered probably:
There's already a patch to fix this here:
https://gitlab.freedesktop.org/drm/amd/-/issues/4481
Alex
>
> Unable to handle k
On 07.08.2025 13:18, Christian König wrote:
> IIRC we settled on printing everything DRM related (e.g. display, device
> lifetime, clients etc...) with the DRM macros.
>
> But everything related to general HW information like PCI slot configuration,
> BARs, speed etc... is printed with the gener
IIRC we settled on printing everything DRM related (e.g. display, device
lifetime, clients etc...) with the DRM macros.
But everything related to general HW information like PCI slot configuration,
BARs, speed etc... is printed with the general kernel functions, e.g. dev_err()
dev_warn()
B
On 07.08.25 11:47, oushixiong1...@163.com wrote:
> From: Shixiong Ou
>
> When Stopping lightdm and removing amdgpu driver are executed, the following
> error is triggered probably:
>
> Unable to handle kernel paging request at virtual address 5e00
> .
> [ 2] [T10084] Call trace:
On 07.08.25 10:46, Liu01 Tong wrote:
> The early commit b8adc31cc0ca ("drm/amdgpu: Avoid extra evict-restore
> process.") changed amdgpu_vm_wait_idle to use drm_sched_entity_flush
> instead of dma_resv_wait_timeout to avoid KFD eviction fence signaling.
> But this introduce a race condition when pr
[AMD Official Use Only - AMD Internal Distribution Only]
Tested-by: Ce Sun
Thanks
Ce Sun
From: Lazar, Lijo
Sent: Thursday, August 7, 2025 3:33 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander
; Sun, Ce(Overlord)
Subject: Re
On 8/1/2025 6:10 PM, Lijo Lazar wrote:
> During a DPC error kernel waits for the link to be active before
> notifying downstream devices. On certain platforms with Broadcom switch
> in synthetiic mode, switch responds with values even though the link is
> not fully ready. The config space restora
[AMD Official Use Only - AMD Internal Distribution Only]
Tested-by: Ce Sun
Thanks
Ce Sun
From: Lazar, Lijo
Sent: Friday, August 1, 2025 3:26 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander
; Sun, Ce(Overlord)
Subject: [PA
ject: Re: [PATCH] drm/amdgpu: Add description for partition commands
On 7/17/2025 4:37 PM, Lijo Lazar wrote:
> Add string description for partition commands.
>
> Signed-off-by: Lijo Lazar
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 4
> 1 file changed, 4 insertio
[AMD Official Use Only - AMD Internal Distribution Only]
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Wednesday, August 6, 2025 2:06 PM
To: Liu, Shaoyun
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/amd/amdgpu : Use the MES INV_TLBS API for tlb
On 2025-08-06 13:45, Timur Kristóf wrote:
>
> Harry Wentland mailto:harry.wentl...@amd.com>> ezt
> írta (időpont: 2025. aug. 6., Sze 16:56):
>
> On 2025-07-23 11:57, Timur Kristóf wrote:
> > Previously, DC determined the DRM connector type based on the
> > signal type, which becom
s.freedesktop.org
> Subject: Re: [PATCH 2/2] drm/amd/amdgpu : Use the MES INV_TLBS API for tlb
> invalidation on gfx12
>
> On Wed, Jul 30, 2025 at 10:33 AM Shaoyun Liu wrote:
> >
> > From MES version 0x81, it provide the new API INV_TLBS that support
> > inval
[AMD Official Use Only - AMD Internal Distribution Only]
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Wednesday, August 6, 2025 1:45 PM
To: Liu, Shaoyun
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/amd/amdgpu : Use the MES INV_TLBS API for tlb
Harry Wentland ezt írta (időpont: 2025. aug. 6.,
Sze 16:56):
> On 2025-07-23 11:57, Timur Kristóf wrote:
> > Previously, DC determined the DRM connector type based on the
> > signal type, which becomes problematic when a connector may
> > support different signal types, such as DVI-I.
> >
> > Wit
On Wed, Jul 30, 2025 at 10:33 AM Shaoyun Liu wrote:
>
> From MES version 0x81, it provide the new API INV_TLBS that support
> invalidate tlbs with PASID.
>
> Signed-off-by: Shaoyun Liu
> ---> drivers/gpu/drm/amd/amdgpu/amdgpu_mes.h | 9 +
> drivers/gpu/drm/amd/amdgpu/gmc_v12_0.c | 15 +
...@lists.freedesktop.org
>> Cc: sta...@vger.kernel.org
>> Subject: Re: [PATCH] drm/amdgpu/discovery: fix fw based ip discovery
>>
>>
>>
>> On 7/30/2025 9:29 PM, Alex Deucher wrote:
>>> We only need the fw based discovery table for sysfs. No need to parse
>>> it
[AMD Official Use Only - AMD Internal Distribution Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Wednesday, August 6, 2025 11:17 AM
> To: Deucher, Alexander ; amd-
> g...@lists.freedesktop.org
> Cc: sta...@vger.kernel.org
> Subject: Re: [PATCH] drm/amdgpu/di
On 7/30/2025 9:29 PM, Alex Deucher wrote:
> We only need the fw based discovery table for sysfs. No
> need to parse it. Additionally parsing some of the board
> specific tables may result in incorrect data on some boards.
> just load the binary and don't parse it on those boards.
>
> Closes:
On 2025-07-23 11:57, Timur Kristóf wrote:
> Previously, DC determined the DRM connector type based on the
> signal type, which becomes problematic when a connector may
> support different signal types, such as DVI-I.
>
> With this patch, it is now determined according to the actual
> connector typ
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Monday, August 4, 2025 23:43
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH] drm/amdgpu: add m
Ping?
On Mon, Aug 4, 2025 at 11:43 AM Alex Deucher wrote:
>
> Legacy resets reset the memory controllers so VRAM contents
> may be unreliable after reset.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/
On 7/30/2025 10:59 AM, Alex Deucher wrote:
We only need the fw based discovery table for sysfs. No
need to parse it. Additionally parsing some of the board
specific tables may result in incorrect data on some boards.
just load the binary and don't parse it on those boards.
Closes: https://gitl
Ping again? This fixes a regression.
Alex
On Mon, Aug 4, 2025 at 10:16 AM Alex Deucher wrote:
>
> Ping?
>
> Alex
>
> On Wed, Jul 30, 2025 at 12:18 PM Alex Deucher
> wrote:
> >
> > We only need the fw based discovery table for sysfs. No
> > need to parse it. Additionally parsing some of the
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Aurabindo Pillai
--
Regards,
Jay
From: SHANMUGAM, SRINIVASAN
Sent: Wednesday, August 6, 2025 8:51 AM
To: Hung, Alex ; Pillai, Aurabindo
Cc: amd-gfx@lists.freedesktop.org ; SHANMUGAM,
SRI
On 06.08.25 12:15, Philipp Zabel wrote:
> On Mi, 2025-08-06 at 10:58 +0200, Christian König wrote:
>> On 31.07.25 07:36, Philipp Zabel wrote:
>>> This is an attempt at fixing amd#2295 [1]:
>>>
>>> On an AMD Rembrandt laptop with 680M iGPU and 6700S dGPU, calling
>>> vkEnumeratePhysicalDevices()
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Hawking Zhang
Regards,
Hawking
From: Min, Frank
Sent: Wednesday, August 6, 2025 21:07
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
; Zhang, Hawking
Subject: [PATCH] drm/amdgpu: Add PSP fw version check for fw reser
On 06.08.25 02:35, Timur Kristóf wrote:
>>
>
> Alex
Hi,
These are my observations about how the UVD clock works on SI:
1. It seems that the SMC needs to know whether UVD is enabled or
not,
and the UVD clocks are included as part of the power states. S
On Tue, Aug 05, 2025 at 08:57:49PM +0300, Imre Deak wrote:
> This is v2 of [1], describing in the patch logs the functional issue the
> patchset fixes based on Tomi's feedback and adding the T-b/A-b/R-b
> tags.
>
> I would like this patchset to be included in the v6.17-rc1 release, if
> this is st
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Leo Liu
> -Original Message-
> From: Sundararaju, Sathishkumar
> Sent: August 6, 2025 3:17 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Liu, Leo
> ; Sundararaju, Sathishkumar
>
> Subject: [PATCH
On 06.08.25 05:34, Cryolitia PukNgae via B4 Relay wrote:
> From: Cryolitia PukNgae
>
> Comments should not have a leading plus sign.
Good catch, potentially a left over from a merge conflict or similar.
>
> Signed-off-by: Cryolitia PukNgae
Acked-by: Christian König
> ---
> drivers/gpu/drm
[AMD Official Use Only - AMD Internal Distribution Only]
Series is
Reviewed-by: Asad Kamal
Thanks & Regards
Asad
-Original Message-
From: Lazar, Lijo
Sent: Wednesday, August 6, 2025 4:52 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander
; Kamal, Asad
Subjec
On Mi, 2025-08-06 at 10:58 +0200, Christian König wrote:
> On 31.07.25 07:36, Philipp Zabel wrote:
> > This is an attempt at fixing amd#2295 [1]:
> >
> > On an AMD Rembrandt laptop with 680M iGPU and 6700S dGPU, calling
> > vkEnumeratePhysicalDevices() wakes up the sleeping dGPU, even if all
>
On 31.07.25 07:36, Philipp Zabel wrote:
> This is an attempt at fixing amd#2295 [1]:
>
> On an AMD Rembrandt laptop with 680M iGPU and 6700S dGPU, calling
> vkEnumeratePhysicalDevices() wakes up the sleeping dGPU, even if all
> the application wants is to find and use the iGPU. This causes a
Hi,
On 2025-07-30 14:58:54 -0400, roman...@amd.com wrote:
> From: Aurabindo Pillai
>
> Accessing DC from amdgpu_dm is usually preceded by acquisition of
> dc_lock mutex. Most of the DC API that DM calls are under a DC lock.
> However, there are a few that are not. Some DC API called from interru
On Mon, 2025-08-04 at 20:59 +0200, Christian König wrote:
> On 04.08.25 19:45, Alex Deucher wrote:
> > On Mon, Aug 4, 2025 at 12:00 PM Timur Kristóf
> > wrote:
> > >
> > > On Mon, 2025-08-04 at 11:20 -0400, Alex Deucher wrote:
> > > > On Mon, Aug 4, 2025 at 9:58 AM Timur Kristóf
> > > > wrote:
>
t;> Cc: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
>> Subject: Re: [PATCH v2 1/1] drm/amdkfd: return -ENOTTY for unsupported
>> IOCTLs
>>
>>
>>
>> On 7/9/2025 2:09 PM, Christian König wrote:
>>> On 09.07.25 06:56, Lazar, Lijo wrote:
>>
[Public]
> -Original Message-
> From: Lazar, Lijo
> Sent: Wednesday, July 9, 2025 5:02 AM
> To: Koenig, Christian ; Deucher, Alexander
> ; McRae, Geoffrey
> ; Kuehling, Felix
> Cc: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: Re: [
, Le ; Zhang,
Morris ; Deucher, Alexander ;
Kamal, Asad
Subject: Re: [PATCH v2] drm/amd/pm: Increase cache interval time
[Public]
Hi Asad,
Sorry, after initing the cache interval time, I meant to move the cache time
check logic to swsmu level and not at smu v13.0.12. I believe this was the
orig
On 2025-08-04 04:03, Michel Dänzer wrote:
> On 31.07.25 19:27, Harry Wentland wrote:
>> On 2025-07-30 04:09, Michel Dänzer wrote:
>>> From: Michel Dänzer
>>>
>>> amdgpu_dm_commit_planes calls update_freesync_state_on_stream only for
>>> the primary plane. If a commit affects a CRTC but not its
On 2025-08-04 04:20, Michel Dänzer wrote:
> On 31.07.25 22:51, Harry Wentland wrote:
>> Thanks for the series. It makes sense to me.
> I'm glad to hear it, thanks for taking a look.
>
> May I take this as R-b?
Yes, please do. :)
Harry
>
>
>>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm
[Public]
Hi Asad,
Sorry, after initing the cache interval time, I meant to move the cache time
check logic to swsmu level and not at smu v13.0.12. I believe this was the
original ask from Alex.
Other SOCs can customize if required by adjusting the cache interval.
Thanks,
Lijo
On Tue, Aug 5, 2025 at 11:55 AM Alex Deucher wrote:
>
> On Tue, Aug 5, 2025 at 11:51 AM Asad Kamal wrote:
> >
> > Increase cache interval time to 50 ms while fetching system
> > metrics table for smu_v13_0_12 since polling interval is less frequent for
> > this data.
> >
> > v2: Make caching inte
On Tue, Aug 5, 2025 at 11:51 AM Asad Kamal wrote:
>
> Increase cache interval time to 50 ms while fetching system
> metrics table for smu_v13_0_12 since polling interval is less frequent for
> this data.
>
> v2: Make caching interval soc independent, however customization can be
> done in soc spec
On Tue, Aug 5, 2025 at 10:38 AM Asad Kamal wrote:
>
> Increase cache interval time to 50 ms while fetching system
> metrics table for smu_v13_0_12
>
Can we move the caching up to the device independent level? It would
be nice to have this for other GPUs.
Alex
> Signed-off-by: Asad Kamal
> ---
On 8/5/2025 7:58 PM, Asad Kamal wrote:
> Increase cache interval time to 50 ms while fetching system
> metrics table for smu_v13_0_12
>
> Signed-off-by: Asad Kamal
You may add additional info in commit description like this data is
expected to be polled less frequently.
Reviewed-by: Lijo Laz
On Tue, Aug 5, 2025 at 10:09 AM Aurabindo Pillai
wrote:
>
> Fix the following warning in struct documentation:
>
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:168: warning: expecting
> prototype for struct dm_vupdate_work. Prototype was for struct
> vupdate_offload_work instead
>
> Fixes:
This patch is:
Reviewed-by: Sathishkumar S
On 8/5/2025 5:55 PM, Lijo Lazar wrote:
The buffer is already freed as part of amdgpu_vcn_reg_dump_fini(). The
issue is introduced by below patch series.
Fixes: 699853ae00ca ("drm/amdgpu/vcn: Add regdump helper functions")
Signed-off-by: Lijo Lazar
[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, 1920x1200 165hz
* Single Display DP (SST DSC) -> 4k144hz, 4k240hz
* Multi displa
On 28.07.25 18:38, Alex Deucher wrote:
Anyway, back to your suggestion, I think we can probably drop the
checks as you should always get a compatible memory buffer due to
amdgpu_bo_get_preferred_domain(). Pinning should fail if we can't pin
in the required domain. amdgpu_displa
[AMD Official Use Only - AMD Internal Distribution Only]
Series is
Reviewed-by: Asad Kamal
Thanks & Regards
Asad
-Original Message-
From: Lazar, Lijo
Sent: Monday, August 4, 2025 5:28 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander
; Kamal, Asad ; Huang,
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Liu, Xiang(Dean)
Sent: Tuesday, August 5, 2025 11:44
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Liu, Xiang(Dean)
Subject: [PATCH] drm/amdgpu: Genera
redhat.com; intel-
>g...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org;
>alexdeuc...@gmail.com
>Subject: Re: [PATCH v3] drm: don't run atomic_async_check for disabled planes
>
>Am Mo., 4. Aug. 2025 um 11:54 Uhr schrieb Murthy, Arun R
>:
>>
>> On 01-08-2025 18:40, Xaver Hugl wro
I am using the R580 chip which is the Radeon X1950 XT.
The board i am using is a T1042 PowerPC based one with e5500 core.
I also lost the ability to start Xorg and therefore just a blank screen.
Dave
Op ma 4 aug 2025, 18:04 schreef Christian Zigotzky :
>
> On 04 August 2025 at 04:42 pm, Al
> It would become mutable only for hardware that supports switching the
> interpolation. It would remain immutable otherwise.
Please let's avoid making (more) properties *sometimes* immutable, it
just makes it easier to use KMS wrong, with no benefits to it.
If a compositor is written against a dri
On Mon, Aug 04, 2025 at 11:08:57AM -0400, Alex Deucher wrote:
> On Mon, Aug 4, 2025 at 10:49 AM Dan Carpenter
> wrote:
> >
> > On Mon, Aug 04, 2025 at 10:32:43AM -0400, Alex Deucher wrote:
> > > On Sat, Aug 2, 2025 at 4:22 AM Ethan Carter Edwards
> > > wrote:
> > > >
> > > > The repeated checks
On Mon, Aug 04, 2025 at 10:32:43AM -0400, Alex Deucher wrote:
> On Sat, Aug 2, 2025 at 4:22 AM Ethan Carter Edwards
> wrote:
> >
> > The repeated checks on grbm_soft_reset are unnecessary. Remove them.
> >
>
> These are not NULL checks and they are necessary. The code is
> checking if any bits a
Am Mo., 4. Aug. 2025 um 11:54 Uhr schrieb Murthy, Arun R
:
>
> On 01-08-2025 18:40, Xaver Hugl wrote:
> > It's entirely valid and correct for compositors to include disabled
> > planes in the atomic commit, and doing that should not prevent async
> > flips from working. To fix that, this commit mov
On Mon, 2025-06-16 at 22:17 -0600, Alex Hung wrote:
> This adds support for a 3D LUT.
>
> The color pipeline now consists of the following colorops:
> 1. 1D curve colorop
> 2. Multiplier
> 3. 3x4 CTM
> 4. 1D curve colorop
> 5. 1D LUT
> 6. 3D LUT
> 7. 1D curve colorop
> 8. 1D LUT
>
> Signed-off-by
[AMD Official Use Only - AMD Internal Distribution Only]
-Original Message-
From: Alex Deucher
Sent: Tuesday, August 5, 2025 1:03 AM
To: Zhang, Jesse(Jie)
Cc: amd-gfx@lists.freedesktop.org; Deucher, Alexander
; Koenig, Christian ;
Chau, Kyle-hai
Subject: Re: [v6 04/13] drm/amdgpu
[AMD Official Use Only - AMD Internal Distribution Only]
-Original Message-
From: Alex Deucher
Sent: Tuesday, August 5, 2025 1:01 AM
To: Zhang, Jesse(Jie)
Cc: amd-gfx@lists.freedesktop.org; Deucher, Alexander
; Koenig, Christian
Subject: Re: [v6 03/13] drm/amdgpu/mes12: implement
On Mon, Aug 04, 2025 at 03:43:12PM +0100, Liviu Dudau wrote:
> Hi,
>
> On Fri, Aug 01, 2025 at 04:51:08PM +0300, Dmitry Baryshkov wrote:
> > Drivers using drm_writeback_connector_init() / _with_encoder() don't
> > perform cleanup in a manner similar to drmm_writeback_connector_init()
> > (see drm_
On 8/4/2025 7:47 PM, Asad Kamal wrote:
> Enable temperature metrics caps for smu_v13_0_12
>
> Signed-off-by: Asad Kamal
A few inits in a couple of patches. With those fixed, series is
Reviewed-by: Lijo Lazar
Thanks,
Lijo
> ---
> drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 5 +
On 8/4/2025 7:47 PM, Asad Kamal wrote:
> Add temperature metrics sysfs entry to expose gpuboard/baseboard
> temperature metrics
>
> v2: Removed unused function, rename functions(Lijo)
>
> v3: Remove unnecessary initialization
>
> Signed-off-by: Asad Kamal
> ---
> drivers/gpu/drm/amd/pm/amdg
On 8/4/2025 7:47 PM, Asad Kamal wrote:
> Fetch system metrics table to fill gpuboard/baseboard temperature
> metrics data for smu_v13_0_12
>
> v2: Remove unnecessary checks, used separate metrics time for
> temperature metrics table(Lijo)
>
> v3: Use cached values for back to back system metri
On 05-08-2025 03:02, Xaver Hugl wrote:
Am Mo., 4. Aug. 2025 um 11:54 Uhr schrieb Murthy, Arun R
:
On 01-08-2025 18:40, Xaver Hugl wrote:
It's entirely valid and correct for compositors to include disabled
planes in the atomic commit, and doing that should not prevent async
flips from working. T
On 04.08.25 19:45, Alex Deucher wrote:
> On Mon, Aug 4, 2025 at 12:00 PM Timur Kristóf wrote:
>>
>> On Mon, 2025-08-04 at 11:20 -0400, Alex Deucher wrote:
>>> On Mon, Aug 4, 2025 at 9:58 AM Timur Kristóf
>>> wrote:
Unlike later versions, UVD 3 has firmware validation.
For this to w
On Mon, 2025-08-04 at 13:45 -0400, Alex Deucher wrote:
> On Mon, Aug 4, 2025 at 12:00 PM Timur Kristóf
> wrote:
> >
> > On Mon, 2025-08-04 at 11:20 -0400, Alex Deucher wrote:
> > > On Mon, Aug 4, 2025 at 9:58 AM Timur Kristóf
> > > wrote:
> > > >
> > > > Unlike later versions, UVD 3 has firmwar
On Mon, Aug 4, 2025 at 12:00 PM Timur Kristóf wrote:
>
> On Mon, 2025-08-04 at 11:20 -0400, Alex Deucher wrote:
> > On Mon, Aug 4, 2025 at 9:58 AM Timur Kristóf
> > wrote:
> > >
> > > Unlike later versions, UVD 3 has firmware validation.
> > > For this to work, the UVD should be powered up correc
On Mon, Aug 4, 2025 at 12:16 PM Timur Kristóf wrote:
>
> On Mon, 2025-08-04 at 11:32 -0400, Alex Deucher wrote:
> > On Mon, Aug 4, 2025 at 9:42 AM Timur Kristóf
> > wrote:
> > >
> > > The si_upload_smc_data function uses si_write_smc_soft_register
> > > to set some register values in the SMC, and
On Mon, Aug 4, 2025 at 12:09 PM Timur Kristóf wrote:
>
> On Mon, 2025-08-04 at 11:24 -0400, Alex Deucher wrote:
> > On Mon, Aug 4, 2025 at 10:18 AM Timur Kristóf
> > wrote:
> > >
> > > Backport of the same commit to amdgpu.
> > > This commit fixes some instability on Tahiti.
> >
> > Have you test
On Mon, Aug 4, 2025 at 12:04 PM Timur Kristóf wrote:
>
> On Mon, 2025-08-04 at 11:24 -0400, Alex Deucher wrote:
> > On Mon, Aug 4, 2025 at 9:58 AM Timur Kristóf
> > wrote:
> > >
> > > This commit fixes some instability on Tahiti.
> > >
> > > Sometimes UVD initialization would fail when using DC.
Applied all three patches with a slight tweak to the commit messages
to make it clearer what is changing.
Alex
On Mon, Aug 4, 2025 at 1:25 PM Alex Deucher wrote:
>
> On Mon, Aug 4, 2025 at 1:15 PM Dan Carpenter wrote:
> >
> > On Mon, Aug 04, 2025 at 11:08:57AM -0400, Alex Deucher wrote:
> > > O
On Mon, Aug 4, 2025 at 4:48 AM Jesse.Zhang wrote:
>
> MES queue reset functionality for GFX queues. The changes include:
>
> 1. Added detection of active VMIDs by reading CP_CNTX_STAT and CP_VMID
>registers to properly identify contexts that need resetting
>
> 2. Implemented fallback to HPD st
On Mon, Aug 4, 2025 at 1:15 PM Dan Carpenter wrote:
>
> On Mon, Aug 04, 2025 at 11:08:57AM -0400, Alex Deucher wrote:
> > On Mon, Aug 4, 2025 at 10:49 AM Dan Carpenter
> > wrote:
> > >
> > > On Mon, Aug 04, 2025 at 10:32:43AM -0400, Alex Deucher wrote:
> > > > On Sat, Aug 2, 2025 at 4:22 AM Etha
On Mon, Aug 4, 2025 at 4:41 AM Jesse.Zhang wrote:
>
> Replace the queue remove/add approach with suspend/resume semantics
> for user queue preemption. This change:
>
> 1. Maintains queue scheduling registration while only preempting execution
>- Previously used remove_queue/add_queue would ful
On Mon, Aug 4, 2025 at 4:48 AM Jesse.Zhang wrote:
>
> This commit implements the actual MES (Micro Engine Scheduler) suspend
> and resume gang operations for version 12 hardware. Previously these
> functions were just stubs returning success.
>
> Signed-off-by: Jesse Zhang
> ---
> drivers/gpu/dr
On Mon, Aug 4, 2025 at 4:41 AM Jesse.Zhang wrote:
>
> Use the suspend and resume API rather than remove queue
> and add queue API. The former just preempts the queue
> while the latter remove it from the scheduler completely.
> There is no need to do that, we only need preemption
> in this case.
On Mon, Aug 4, 2025 at 4:48 AM Jesse.Zhang wrote:
>
> MES queue reset functionality for GFX queues. The changes include:
>
> 1. Added detection of active VMIDs by reading CP_CNTX_STAT and CP_VMID
>registers to properly identify contexts that need resetting
>
> 2. Implemented fallback to HPD st
On Mon, Aug 4, 2025 at 4:48 AM Jesse.Zhang wrote:
>
> MES queue reset functionality for GFX queues. The changes include:
>
> 1. Added detection of active VMIDs by reading CP_CNTX_STAT and CP_VMID
>registers to properly identify contexts that need resetting
>
> 2. Implemented fallback to HPD st
On Mon, Aug 4, 2025 at 4:53 AM Jesse.Zhang wrote:
>
> From: Alex Deucher
>
> Implement support for the hung queue detect and reset
> functionality.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/mes_v12_0.c | 37 ++
> 1 file changed, 37 insertions(+)
On Mon, Aug 4, 2025 at 12:35 PM Timur Kristóf wrote:
>
> On Mon, 2025-08-04 at 11:56 -0400, Alex Deucher wrote:
> > On Thu, Jul 31, 2025 at 5:58 AM Timur Kristóf
> > wrote:
> > >
> > > Adjust the nominal (and performance) clocks for DCE 8-10,
> > > and set them to 625 MHz, which is the value used
On Mon, 2025-08-04 at 11:56 -0400, Alex Deucher wrote:
> On Thu, Jul 31, 2025 at 5:58 AM Timur Kristóf
> wrote:
> >
> > Adjust the nominal (and performance) clocks for DCE 8-10,
> > and set them to 625 MHz, which is the value used by the legacy
> > display code in amdgpu_atombios_get_clock_info.
On Mon, 2025-08-04 at 11:32 -0400, Alex Deucher wrote:
> On Mon, Aug 4, 2025 at 9:42 AM Timur Kristóf
> wrote:
> >
> > The si_upload_smc_data function uses si_write_smc_soft_register
> > to set some register values in the SMC, and expects the result
> > to be PPSMC_Result_OK which is 1.
> >
> >
1 - 100 of 4491 matches
Mail list logo
