[AMD Official Use Only - AMD Internal Distribution Only]
Hi @Lazar, Lijo,
Can you help review this?
Thanks,
Victor
-Original Message-
From: Victor Zhao
Sent: Tuesday, May 21, 2024 12:08 AM
To: amd-gfx@lists.freedesktop.org
Cc: Lazar, Lijo ; Zhao, Victor
Subject: [PATCH]
This patch changes the implementation of AMDGPU_PTE_MTYPE_VG10,
clear the bits before setting the new one.
Suggested-by: Alex Deucher
Signed-off-by: longlyao
Signed-off-by: Shane Xiao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 7 --
This patch changes the implementation of AMDGPU_PTE_MTYPE_NV10,
clear the bits before setting the new one.
Suggested-by: Alex Deucher
Signed-off-by: longlyao
Signed-off-by: Shane Xiao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 7 +--
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 17
This patch changes the implementation of AMDGPU_PTE_MTYPE_GFX12,
clear the bits before setting the new one.
This fixed the potential issue that GFX12 setting memory to NC.
v2: Clear mtype field before setting the new one (Alex)
v3: Fix typo (Felix)
Suggested-by: Alex Deucher
Signed-off-by:
On 5/22/2024 7:49 AM, Zhang, Jesse(Jie) wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> Hi Lijo
>
> -Original Message-
> From: Lazar, Lijo
> Sent: Tuesday, May 21, 2024 4:20 PM
> To: Zhang, Jesse(Jie) ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ;
[AMD Official Use Only - AMD Internal Distribution Only]
Hi Lijo
-Original Message-
From: Lazar, Lijo
Sent: Tuesday, May 21, 2024 4:20 PM
To: Zhang, Jesse(Jie) ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Koenig, Christian
; Huang, Tim ; Yu, Lang
Subject: Re: [PATCH 1/4
On Mon, May 20, 2024 at 5:37 AM Xiao, Shane wrote:
>
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> Hi Alex,
>
> I have changed the macro AMDGPU_PTE_MTYPE_GFX12 to clear mtype bit before
> setting.
> Add one parameter for this macro, and some related code needs to be changed.
>
>
On 5/21/2024 15:06, Rino André Johnsen wrote:
What is already there in debugfs is 'bpc' and 'colorspace', but not
the pixel encoding/format.
I have searched high and low for that to be able to verify that my
monitor and computer are using my preferred combination of all those
three values.
I do
On 2024-05-20 5:14, Shane Xiao wrote:
> This patch changes the implementation of AMDGPU_PTE_MTYPE_GFX12,
> clear the bits before setting the new one.
> This fixed the potential issue that GFX12 setting memory to NC.
>
> v2: Clear mtype field before setting the new one (Alex)
>
> Signed-off-by:
Am 21.05.24 um 07:11 schrieb Rino Andre Johnsen:
[Why]
For debugging and testing purposes.
[How]
Create amdgpu_current_pixelencoding debugfs entry.
Usage: cat /sys/kernel/debug/dri/1/crtc-0/amdgpu_current_pixelencoding
Why isn't that available as standard DRM CRTC property in either sysfs
or
Am 20.05.24 um 10:18 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Align kerneldoc with the function argument name.
Signed-off-by: Tvrtko Ursulin
Reported-by: Stephen Rothwell
Fixes: 26e20235ce00 ("drm/amdgpu: Add amdgpu_bo_is_vm_bo helper")
Cc: Christian König
Cc: Alex Deucher
On 2024-05-21 13:32, Mario Limonciello wrote:
On 5/21/2024 12:27, Leo Li wrote:
On 2024-05-21 12:21, Mario Limonciello wrote:
On 5/21/2024 11:14, Xaver Hugl wrote:
Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello
:
On 5/21/2024 08:43, Simon Ser wrote:
This makes sense to
On Tuesday, May 21st, 2024 at 19:27, Leo Li wrote:
> I wonder if flags would work better than enums? A compositor can set something
> like `REQUIRE_ACCURACY & REQUIRE_LOW_LATENCY`, for example.
(FWIW, the KMS uAPI has first-class support for bitfields.)
Applied and pushed out:
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=8a0a7b98d4b6eeeab337ec25daa4bc0a5e710a15
Alex
On Tue, May 21, 2024 at 12:12 PM Alex Deucher wrote:
>
> I've got it teed up. Is drm-misc-fixes the right branch since we are
> in the merge window?
>
> Alex
>
> On Tue,
On 5/21/2024 12:27, Leo Li wrote:
On 2024-05-21 12:21, Mario Limonciello wrote:
On 5/21/2024 11:14, Xaver Hugl wrote:
Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello
:
On 5/21/2024 08:43, Simon Ser wrote:
This makes sense to me in general. I like the fact that it's simple
and
On 2024-05-21 12:21, Mario Limonciello wrote:
On 5/21/2024 11:14, Xaver Hugl wrote:
Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello
:
On 5/21/2024 08:43, Simon Ser wrote:
This makes sense to me in general. I like the fact that it's simple and
vendor-neutral.
Do we want to
On 5/21/2024 11:48, Pratap Nirujogi wrote:
Add support for ISP interrupts and disable MMHUB prefetch for ISP v4.1.1
Pratap Nirujogi (3):
drm/amd/amdgpu: Map ISP interrupts as generic IRQs
drm/amd/amdgpu: Add ISP4.1.0 and ISP4.1.1 modules
drm/amd/amdgpu: Disable MMHUB prefetch for ISP
Map ISP IH interrupts to Linux generic IRQ for ISP driver to
handle the interrupts using MFD IORESOURCE_IRQ resource.
Signed-off-by: Pratap Nirujogi
---
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c | 31 --
Add independent IP centric modules for ISP4.1.0 and ISP4.1.1 hw blocks.
Signed-off-by: Pratap Nirujogi
---
drivers/gpu/drm/amd/amdgpu/Makefile | 5 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c | 167 --
Disable MMHUB prefetch for ISP v4.1.1 as a temporary WA until
the GART supports MMHUB TLSi and SAW for ISP HW to access
GART memory using the TLSi path.
Signed-off-by: Pratap Nirujogi
---
drivers/gpu/drm/amd/amdgpu/isp_v4_1_1.c | 12
drivers/gpu/drm/amd/amdgpu/isp_v4_1_1.h | 7
Add support for ISP interrupts and disable MMHUB prefetch for ISP v4.1.1
Pratap Nirujogi (3):
drm/amd/amdgpu: Map ISP interrupts as generic IRQs
drm/amd/amdgpu: Add ISP4.1.0 and ISP4.1.1 modules
drm/amd/amdgpu: Disable MMHUB prefetch for ISP v4.1.1
drivers/gpu/drm/amd/amdgpu/Makefile
kernel test robot writes:
> tree/branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> branch HEAD: 124cfbcd6d185d4f50be02d5f5afe61578916773 Add linux-next
> specific files for 20240521
[...]
> Error/Warning ids grouped by kconfigs:
>
&
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 124cfbcd6d185d4f50be02d5f5afe61578916773 Add linux-next specific
files for 20240521
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202405211405.tidtwibx-...@intel.com
Error
On 5/21/2024 11:14, Xaver Hugl wrote:
Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello
:
On 5/21/2024 08:43, Simon Ser wrote:
This makes sense to me in general. I like the fact that it's simple and
vendor-neutral.
Do we want to hardcode "panel" in the name? Are we sure that this
I've got it teed up. Is drm-misc-fixes the right branch since we are
in the merge window?
Alex
On Tue, May 21, 2024 at 7:20 AM Linux regression tracking (Thorsten
Leemhuis) wrote:
>
> Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
> for once, to make this easily
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Wenjing Liu
-Original Message-
From: SHANMUGAM, SRINIVASAN
Sent: Friday, May 10, 2024 6:12 AM
To: Liu, Wenjing ; Siqueira, Rodrigo
; Pillai, Aurabindo
Cc: amd-gfx@lists.freedesktop.org; SHANMUGAM, SRINIVASAN
;
On 05/21, Melissa Wen wrote:
> On 02/26, Harry Wentland wrote:
> > From: Alex Hung
> >
> > Expose one 1D curve colorop with support for
> > DRM_COLOROP_1D_CURVE_SRGB_EOTF and program HW to perform
> > the sRGB transform when the colorop is not in bypass.
> >
> > With this change the following
On 02/26, Harry Wentland wrote:
> This is an RFC set for a color pipeline API, along with a sample
> implementation in VKMS. All the key API bits are here. VKMS now
> supports two named transfer function colorops and two matrix
> colorops. We have IGT tests that check all four of these colorops
>
On 02/26, Harry Wentland wrote:
> From: Alex Hung
>
> Expose one 1D curve colorop with support for
> DRM_COLOROP_1D_CURVE_SRGB_EOTF and program HW to perform
> the sRGB transform when the colorop is not in bypass.
>
> With this change the following IGT test passes:
> kms_colorop --run
On 02/26, Harry Wentland wrote:
> From: Alex Hung
>
> This introduces a new drm_colorop_type: DRM_COLOROP_MULTIPLIER.
>
> It's a simple multiplier to all pixel values. The value is
> specified via a S31.32 fixed point provided via the
> "MULTIPLIER" property.
>
> Signed-off-by: Alex Hung
>
On 02/26, Harry Wentland wrote:
> This patches introduces a new drm_colorop mode object. This
> object represents color transformations and can be used to
> define color pipelines.
>
> We also introduce the drm_colorop_state here, as well as
> various helpers and state tracking bits.
>
> v4:
>
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Harish Kasiviswanathan
-Original Message-
From: Zhang, Hawking
Sent: Tuesday, May 21, 2024 3:55 AM
To: Lazar, Lijo ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Kuehling, Felix
; Kasiviswanathan, Harish
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Alex Deucher
From: Jesse Zhang
Sent: Tuesday, May 21, 2024 3:17 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Koenig, Christian
; Huang, Tim ; Zhang, Jesse(Jie)
; Zhang,
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Alex Deucher
From: Jesse Zhang
Sent: Tuesday, May 21, 2024 3:16 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Koenig, Christian
; Huang, Tim ; Zhang, Jesse(Jie)
; Zhang,
On 5/21/2024 08:43, Simon Ser wrote:
This makes sense to me in general. I like the fact that it's simple and
vendor-neutral.
Do we want to hardcode "panel" in the name? Are we sure that this will
ever only apply to panels?
Do we want to use a name which reflects the intent, rather than the
This makes sense to me in general. I like the fact that it's simple and
vendor-neutral.
Do we want to hardcode "panel" in the name? Are we sure that this will
ever only apply to panels?
Do we want to use a name which reflects the intent, rather than the
mechanism? In other words, something like
Am 17.05.24 um 17:46 schrieb Alex Deucher:
On Fri, May 17, 2024 at 2:35 AM Christian König
wrote:
Am 16.05.24 um 19:57 schrieb Tim Van Patten:
From: Tim Van Patten
The following commit updated gmc->noretry from 0 to 1 for GC HW IP
9.3.0:
commit 5f3854f1f4e2 ("drm/amdgpu: add more
Hi Mikhail,
Thanks for the report. I will look into it this week and get back to you.
-Vasant
On 5/21/2024 3:09 PM, Mikhail Gavrilov wrote:
> Hi,
> Yesterday on the fresh kernel snapshot
> I spotted a new bug message with follow stacktrace:
> [4.307097] BUG: sleeping function called from
On 5/21/2024 12:46 PM, Jesse Zhang wrote:
> Since the type of data_size is uint32_t, adev->umsch_mm.data_size - 1 >> 16
> >> 16 is 0
> regardless of the values of its operands
>
> So removing the operations upper_32_bits and lower_32_bits.
>
> Signed-off-by: Jesse Zhang
> Suggested-by: Tim
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Tao Zhou
Sent: Tuesday, May 21, 2024 11:17
To: amd-gfx@lists.freedesktop.org
Cc: Zhou1, Tao
Subject: [PATCH] drm/amdgpu: use u32 for buf
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Lazar, Lijo
Sent: Tuesday, May 21, 2024 15:15
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander
; Kuehling, Felix ;
Kasiviswanathan,
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Xiao, Jack
Sent: Tuesday, May 21, 2024 15:36
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
; Zhang, Hawking ; Min, Frank
; Gao, Likun ; Feng, Kenneth
On 5/21/2024 1:07 PM, Srinivasan Shanmugam wrote:
> This commit fixes a format truncation issue arosed by the snprintf
> function potentially writing more characters into the ring->name buffer
> than it can hold, in the amdgpu_gfx_kiq_init_ring function
>
> The issue occurred because the
[AMD Official Use Only - AMD Internal Distribution Only]
Series is,
Reviewed-by: Tim Huang
> -Original Message-
> From: Jesse Zhang
> Sent: Tuesday, May 21, 2024 3:18 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Koenig, Christian
> ; Huang, Tim ; Zhang,
>
This commit fixes a format truncation issue arosed by the snprintf
function potentially writing more characters into the ring->name buffer
than it can hold, in the amdgpu_gfx_kiq_init_ring function
The issue occurred because the '%d' format specifier could write between
1 and 10 bytes into a
Port mes11 hw_fini to mes12, fix for mode1 reset.
Signed-off-by: Jack Xiao
---
drivers/gpu/drm/amd/amdgpu/mes_v12_0.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/mes_v12_0.c
b/drivers/gpu/drm/amd/amdgpu/mes_v12_0.c
index
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Tao Zhou
> -Original Message-
> From: Zhang, Hawking
> Sent: Tuesday, May 21, 2024 3:12 PM
> To: amd-gfx@lists.freedesktop.org; Zhou1, Tao
> Cc: Zhang, Hawking
> Subject: [PATCH] drm/amdgpu: correct hbm field in
When user space sets an invalid ta type, the pointer context will be empty.
So it need to check the pointer context before using it
Signed-off-by: Jesse Zhang
Suggested-by: Tim Huang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Since the type of pg_flags is u32, adev->pg_flags >> 16 >> 16 is 0
regardless of the values of its operands.
So removing the operations upper_32_bits and lower_32_bits.
Signed-off-by: Jesse Zhang
Suggested-by: Tim Huang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 ++--
1 file changed,
Enum asic_type always greater than or equal CHIP_TAHITI.
Signed-off-by: Jesse Zhang
Suggested-by: Tim Huang
---
drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
Since the type of data_size is uint32_t, adev->umsch_mm.data_size - 1 >> 16 >>
16 is 0
regardless of the values of its operands
So removing the operations upper_32_bits and lower_32_bits.
Signed-off-by: Jesse Zhang
Suggested-by: Tim Huang
---
drivers/gpu/drm/amd/amdgpu/umsch_mm_v4_0.c | 5
KFD uses crc16 for gpu_id generation.
Fixes: 6dbc6469ab0b ("drm/amdkfd: Ensure gpu_id is unique")
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202405211405.tidtwibx-...@intel.com/
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgpu/Kconfig | 1 +
1 file
[Why]
For debugging and testing purposes.
[How]
Create amdgpu_current_pixelencoding debugfs entry.
Usage: cat /sys/kernel/debug/dri/1/crtc-0/amdgpu_current_pixelencoding
Signed-off-by: Rino Andre Johnsen
---
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 47 +++
1 file
Make @abo to @bo to silence the kernel-doc warning.
Signed-off-by: Yang Li
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index
[Why]
For debugging and testing purposes.
[How]
Create amdgpu_current_pixelencoding debugfs entry.
Usage: cat /sys/kernel/debug/dri/1/crtc-0/amdgpu_current_pixelencoding
Signed-off-by: Rino Andre Johnsen
---
Changes in v2:
1. Do not initialize dm_crtc_state to NULL.
---
hbm filed takes bit 13 and bit 14 in boot status.
Signed-off-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
index
Hi Dmitry,
On 20/05/24 16:32, Dmitry Baryshkov wrote:
On Fri, May 17, 2024 at 02:54:59PM +0530, Vignesh Raman wrote:
With latest IGT, the tests tries to load the module and it
fails. So build the virtual GPU driver for virtio as module.
Why? If the test fails on module loading (if the driver
Hi Helen,
On 21/05/24 01:54, Helen Koike wrote:
On 17/05/2024 06:24, Vignesh Raman wrote:
Stop vendoring the testlist into the kernel. Instead, use the
testlist from the IGT build to ensure we do not miss renamed
or newly added tests.
Signed-off-by: Vignesh Raman
---
v2:
- Fix testlist
Hi Dmitry,
On 20/05/24 16:30, Dmitry Baryshkov wrote:
On Fri, May 17, 2024 at 02:54:58PM +0530, Vignesh Raman wrote:
Stop vendoring the testlist into the kernel. Instead, use the
testlist from the IGT build to ensure we do not miss renamed
or newly added tests.
Signed-off-by: Vignesh Raman
[AMD Official Use Only - AMD Internal Distribution Only]
Hi Tim,
-Original Message-
From: Huang, Tim
Sent: Tuesday, May 21, 2024 2:12 PM
To: Zhang, Jesse(Jie) ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Koenig, Christian
; Zhang, Jesse(Jie) ; Zhang,
Jesse(Jie)
Subject:
[AMD Official Use Only - AMD Internal Distribution Only]
Hi Jesse,
> -Original Message-
> From: amd-gfx On Behalf Of Jesse
> Zhang
> Sent: Tuesday, May 21, 2024 11:26 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Koenig, Christian
> ; Huang, Tim ; Zhang,
> Jesse(Jie)
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Yang Wang
Best Regards,
Kevin
-Original Message-
From: amd-gfx On Behalf Of Tao Zhou
Sent: Tuesday, May 21, 2024 11:17 AM
To: amd-gfx@lists.freedesktop.org
Cc: Zhou1, Tao
Subject: [PATCH] drm/amdgpu: use u32 for
62 matches
Mail list logo
