From: Basavaraj Natikar
Considering that amd_sfh exists only on AMD platforms, set the AMD SFH
driver to depend on x86 to avoid build warnings or errors on other
architectures, as shown below.
drivers/hid/amd-sfh-hid/amd_sfh_pcie.c: In function 'amd_mp2_pci_probe':
drivers/hid/amd-sfh-hid/amd_sf
From: Basavaraj Natikar
Various MP2 register sets are supported by newer processors. Therefore,
extend MP2 register access to SFH.
Signed-off-by: Basavaraj Natikar
Signed-off-by: Jiri Kosina
(cherry picked from commit 6296562f30b1caf4b5f44e0c89c8f5cbfdb14b4a)
---
drivers/hid/amd-sfh-hid/amd_s
From: Basavaraj Natikar
AMD SFH load takes longer time in initialization. Hence split and defer
initialization code to improve SFH module load time and boot time of the
system when SFH is available.
Signed-off-by: Basavaraj Natikar
Signed-off-by: Jiri Kosina
(cherry picked from commit 2105e8e0
From: Basavaraj Natikar
HP ProBook x360 435 G7 using older version of firmware which doesn't
support disabling the interrupt for all commands. Hence avoid disabling
the interrupt for that particular model.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218104
Fixes: b300667b33b2 ("HID: amd_sf
From: Basavaraj Natikar
HPD sensor data is not populating properly because of wrong order of HPD
sensor structure elements. So update the order of structure elements to
match the HPD sensor data received from the firmware.
Fixes: 24a31ea94922 ("HID: amd_sfh: Add initial support for HPD sensor")
From: Basavaraj Natikar
During the initialization sensors may take some time to respond. Hence,
increase the sensor command timeouts in order to obtain status responses
within a maximum timeout.
(Li: backport for s0ix issue, these patches have landed on 6.9)
Co-developed-by: Akshata MukundShetty
Fix sparse warning regarding symbol 'sw43408_backlight_ops' not being
declared.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202404200739.hbwzvohr-...@intel.com/
Reviewed-by: Neil Armstrong
Fixes: 069a6c0e94f9 ("drm: panel: Add LG sw43408 panel driver")
Signed-of
This panel driver uses DSC PPS functions and as such depends on the
DRM_DISPLAY_DP_HELPER. Select this symbol to make required functions
available to the driver.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202404200800.kysryyli-...@intel.com/
Fixes: 069a6c0e94f9
Fix two issues with the panel-lg-sw43408 driver reported by the kernel
test robot.
To: Neil Armstrong
To: Jessica Zhang
To: Sam Ravnborg
To: Maarten Lankhorst
To: Maxime Ripard
To: Thomas Zimmermann
To: David Airlie
To: Daniel Vetter
To: Sumit Semwal
To: Caleb Connolly
To: Alex Deucher
Currently the DRM DSC functions are selected by the
DRM_DISPLAY_DP_HELPER Kconfig symbol. This is not optimal, since the DSI
code (both panel and host drivers) end up selecting the seemingly
irrelevant DP helpers. Split the DSC code to be guarded by the separate
DRM_DISPLAY_DSC_HELPER Kconfig symbo
[AMD Official Use Only - AMD Internal Distribution Only]
Hi Victor,
Could you check if an approach like the attached one helps?
Thanks,
Lijo
-Original Message-
From: Zhao, Victor
Sent: Wednesday, May 22, 2024 11:13 AM
To: Zhao, Victor ; amd-gfx@lists.freedesktop.org; Lazar,
Lijo
Subje
[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] drm/amd/amdgpu
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 --
dri
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: longl
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 ; Koe
[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 V2
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
Reviewed-b
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 me
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, Ma
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 hard
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 v4
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 --
drivers/gpu/drm/amd/amdgp
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 --
drive
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 wi
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 accessibl
[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
; Zuo,
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 IG
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
> w
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 plane-XR30
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, Jess
[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, Jess
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
mech
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 case
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 in
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 H
[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 si
[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, Ha
[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 '%d
[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,
> Jesse(J
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 re
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 45b70a4c4ada..f1
[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 boo
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 --git
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
b/drivers/gpu/drm/am
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 ch
[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 changed,
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 b9cca51356b1..3abfa66d7
[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.
---
.../amd/display/amdgpu_
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 c8980d5f6540..70
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
69 matches
Mail list logo
