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 got discontinuity migrates j+1 pages
that ith page is migrated. That cause error p
Am Wed, 15 Jan 2025 15:27:00 -0500
schrieb Alex Deucher :
> On Wed, Jan 15, 2025 at 3:22 PM Marco Moock wrote:
> >
> > Am Wed, 15 Jan 2025 16:08:34 +0100
> > schrieb Marco Moock :
> >
> > > I assume it was 6.12.6, but Debian doesn't have the old packages
> > > anymore and it has been purged fro
On Wed, Jan 15, 2025 at 3:22 PM Marco Moock wrote:
>
> Am Wed, 15 Jan 2025 16:08:34 +0100
> schrieb Marco Moock :
>
> > I assume it was 6.12.6, but Debian doesn't have the old packages
> > anymore and it has been purged from my system already.
>
> I've now tried 6.12.6, same situation.
>
> Any fur
Am Wed, 15 Jan 2025 16:08:34 +0100
schrieb Marco Moock :
> I assume it was 6.12.6, but Debian doesn't have the old packages
> anymore and it has been purged from my system already.
I've now tried 6.12.6, same situation.
Any further ideas what could cause this?
On 1/13/2025 19:58, Gerry Liu wrote:
2025年1月14日 06:27，Mario Limonciello 写道：
On 1/12/2025 19:42, Jiang Liu wrote:
Make the device state machine work in stack like way to better support
suspend/resume by following changes:
1. amdgpu_driver_load_kms()
amdgpu_device_init()
The function amdgpu_dm_crtc_mem_type_changed was dereferencing pointers
returned by drm_atomic_get_plane_state without checking for errors. This
could lead to undefined behavior if the function returns an error pointer.
This commit adds checks using IS_ERR to ensure that new_plane_state and
old_pl
From: Asad Kamal
Add pmfw headers for smuv13.0.12 to pmfw version 86.24.0
Signed-off-by: Asad Kamal
Reviewed-by: Lijo Lazar
Signed-off-by: Alex Deucher
---
.../pm/swsmu/inc/pmfw_if/smu_v13_0_12_pmfw.h | 248 ++
1 file changed, 248 insertions(+)
create mode 100644 drivers/gp
From: Asad Kamal
Add SMUv13.0.12 PPT interface to fetch metrics data
Signed-off-by: Asad Kamal
Reviewed-by: Lijo Lazar
Signed-off-by: Alex Deucher
---
.../drm/amd/pm/swsmu/inc/smu_v13_0_12_ppt.h | 35 ++
drivers/gpu/drm/amd/pm/swsmu/smu13/Makefile | 2 +-
.../drm/amd/pm/swsmu/smu13/sm
Reviewed-by: Simon Ser
> + prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, "SIZE",
Ah, I forgot something: I think this needs to be DRM_MODE_PROP_ATOMIC?
Hi Dave, Simona,
Fixes for 6.13. A little bigger than normal. Lots of stuff that
built up over the holidays.
The following changes since commit fddb4fd91a955636baa451fe82ad0266f55c7ede:
Merge tag 'mediatek-drm-fixes-20250104' of
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/l
Am 14.01.2025 um 17:25:46 Uhr schrieb Alex Deucher:
> What kernel version(s) is it working properly with? Can you bisect?
I assume it was 6.12.6, but Debian doesn't have the old packages
anymore and it has been purged from my system already.
I am trying to find a way to get the old kernel for t
Applied. thanks!
Alex
On Wed, Jan 15, 2025 at 7:02 AM Colin Ian King wrote:
>
> There are a couple of statements with two following semicolons, replace
> these with just one semicolon.
>
> Signed-off-by: Colin Ian King
> ---
> .../dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c| 4
On Tue, Jan 14, 2025 at 11:02 PM Shaoyun Liu wrote:
>
> MES internal will check CP_MES_MSCRATCH_LO/HI register to set scratch data
> location
> during ucode start, driver side need to start the MES one by one with
> different
> setting for each pipe
>
> Signed-off-by: Shaoyun Liu
Acked-by: Ale
On Wed, Jan 15, 2025 at 4:48 AM jesse.zh...@amd.com wrote:
>
> From: "jesse.zh...@amd.com"
>
> This patch refactors the firmware version checks in `smu_v13_0_6_reset_sdma`
> to support multiple SMU programs with different firmware version thresholds.
>
> V2: return -EOPNOTSUPP for unspported pmfw
On 1/15/2025 3:18 PM, jesse.zh...@amd.com wrote:
> From: "jesse.zh...@amd.com"
>
> This patch refactors the firmware version checks in `smu_v13_0_6_reset_sdma`
> to support multiple SMU programs with different firmware version thresholds.
>
> V2: return -EOPNOTSUPP for unspported pmfw
>
> Su
Hi!
On Thu, 2024-12-26 at 12:31 +0530, Arunpravin Paneer Selvam wrote:
> - Added a testcase to verify the multiroot force merge fini.
> - Added a new field in_use to track the mm freed status.
>
> v2:(Matthew)
> - Add kunit_fail_current_test() when WARN_ON is true.
>
> Signed-off-by: Arunpravi
There are a couple of statements with two following semicolons, replace
these with just one semicolon.
Signed-off-by: Colin Ian King
---
.../dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
a/drivers/gpu/drm/amd/disp
Hi Jani,
I merged the below patch into drm-misc-next, Please try rebuilding the
drm-tip.
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=00728273bdf1001f8d2f7b65bc398000d7defe0b
Thanks,
Arun.
On 1/15/2025 5:08 PM, Jani Nikula wrote:
On Thu, 26 Dec 2024, Arunpravin Paneer Selvam
wrote
On Wed, 15 Jan 2025 at 04:05, Marek Olšák wrote:
> On Tue, Jan 14, 2025 at 12:58 PM Daniel Stone wrote:
>> AMD hardware is the only hardware I know of which doesn't support
>> overaligning. Say (not hypothetically) we have a GPU and a display
>> controller which have a minimum pitch alignment of
Am 15.01.25 um 07:52 schrieb jesse.zh...@amd.com:
When a GPU job times out, the driver attempts to recover by restarting
the scheduler. Previously, the scheduler was restarted with an error
code of 0, which does not distinguish between a full GPU reset and a
queue reset. This patch changes the er
On Thu, 26 Dec 2024, Arunpravin Paneer Selvam
wrote:
> - Added a testcase to verify the multiroot force merge fini.
> - Added a new field in_use to track the mm freed status.
>
> v2:(Matthew)
> - Add kunit_fail_current_test() when WARN_ON is true.
This i.e. commit 8cb3a1e2b350 ("drm/buddy: Add
Hi Shaoyun and Gerry,
yes good idea, live migration is certainly an option as well.
In live migration the hypervisor transparently provides the same GPU
configuration to the client on the new GPU like it has seen it before on
the old GPU. In other words your fully state including VRAM content
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 range
length >= huge page and free PTB bo, update mapping to alloc new PT bo.
There is race bug that the freed entry bo maybe
From: "jesse.zh...@amd.com"
This patch refactors the firmware version checks in `smu_v13_0_6_reset_sdma`
to support multiple SMU programs with different firmware version thresholds.
V2: return -EOPNOTSUPP for unspported pmfw
Suggested-by: Lazar Lijo
Signed-off-by: Jesse Zhang
---
.../drm/amd
[AMD Official Use Only - AMD Internal Distribution Only]
-Original Message-
From: Lazar, Lijo
Sent: Wednesday, January 15, 2025 4:23 PM
To: Zhang, Jesse(Jie) ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Koenig, Christian
; Huang, Tim ; Zhu, Jiadong
Subject: Re: [PATCH 3/3]
On Tue, Jan 14, 2025 at 12:33:57PM -0600, Faith Ekstrand wrote:
> On January 14, 2025 03:39:45 Marek Olšák wrote:
> > I would keep the existing modifier interfaces, API extensions, and
> > expectations the same as today for simplicity.
> >
> > The new linear modifier definition (proposal) will ha
On 1/15/2025 1:59 PM, Lazar, Lijo wrote:
>
>
> On 1/14/2025 10:51 PM, Kim, Jonathan wrote:
>> [Public]
>>
>>> -Original Message-
>>> From: Lazar, Lijo
>>> Sent: Friday, January 10, 2025 10:37 PM
>>> To: Kim, Jonathan ; amd-gfx@lists.freedesktop.org
>>> Cc: Kasiviswanathan, Harish
>>>
On 1/14/2025 10:51 PM, Kim, Jonathan wrote:
> [Public]
>
>> -Original Message-
>> From: Lazar, Lijo
>> Sent: Friday, January 10, 2025 10:37 PM
>> To: Kim, Jonathan ; amd-gfx@lists.freedesktop.org
>> Cc: Kasiviswanathan, Harish
>> Subject: Re: [PATCH] drm/amdgpu: fix gpu recovery disab
On 1/15/2025 7:10 AM, jesse.zh...@amd.com wrote:
> From: "jesse.zh...@amd.com"
>
> This patch refactors the firmware version checks in `smu_v13_0_6_reset_sdma`
> to support multiple SMU programs with different firmware version thresholds.
>
> Signed-off-by: Jesse Zhang
> ---
> .../gpu/drm/a
Hello Leo Li,
Commit 4caacd1671b7 ("drm/amd/display: Do not elevate mem_type change
to full update") from Dec 11, 2024 (linux-next), leads to the
following Smatch static checker warning:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:11486
amdgpu_dm_crtc_mem_type_changed()
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index a3e1fcad47ad..4744c12e429d 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -701,6 +701,9 @@ static int drm_atomic_color_set_data_property(struct
> drm_col
> The BT.709 and BT.2020 OETFs are the same, the only difference
> being that the BT.2020 variant is defined with more precision
> for 10 and 12-bit per color encodings.
Just to make sure, the spec defines this precision, correct? It's
not an AMD-specific thing?
> Both are used as encoding functi
Is this 125 magic number something we can expect other hardware to
implement as well?
Could AMD use the HDR multiplier or another block to behave as if
the multiplier didn't exist?
Note, I am no HDR expert. Maybe others have a better idea whether this
makes sense or not.
34 matches
Mail list logo
