set_xgmi_plpd_mode may be unsupported and this isn't error, no need to
print warning for it.
Suggested-by: lijo.la...@amd.com
Signed-off-by: Tao Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/
The UE registe list is larger than CE list.
Reported-by: yipeng.c...@amd.com
Signed-off-by: Tao Zhou
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c | 38 +
1 file changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c
b/drivers/gpu/drm/amd/amdgpu/gf
Handle xgmi hive case.
Suggested-by: Hawking Zhang
Signed-off-by: Tao Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index 7532607
On 24/10/23 23:41, Bragatheswaran Manickavel wrote:
The member variable enable_hpo_pg_support is already initialized
and hence the reinitialization instruction can be removed. Issue
identified using the doubleinit.cocci Coccinelle semantic patch script.
Signed-off-by: Bragatheswaran Manickavel
Hello Stylon Wang,
The patch 71ba6b577a35: "drm/amd/display: Add interface to enable
DPIA trace" from Jun 30, 2023 (linux-next), leads to the following
Smatch static checker warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:1041
dc_dmub_srv_enable_dpia_trace()
error
On 2023-10-30 15:52, Aurabindo Pillai wrote:
On 10/29/2023 8:44 AM, José Pekkarinen wrote:
This patch addresses the following warning spotted by
using coccinelle where the case checked does the same
than the else case.
drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_util_32.c:4664:8-1
Am 31.10.23 um 03:55 schrieb YuanShang:
The variable "chunk_ptr" should be a pointer pointing
to a struct drm_amdgpu_cs_chunk instead of to a pointer
of that.
Signed-off-by: YuanShang
Good catch, Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
1 file chang
[AMD Official Use Only - General]
Reviewed-by: Stanley.Yang
Regards,
Stanley
> -Original Message-
> From: amd-gfx On Behalf Of Tao
> Zhou
> Sent: Tuesday, October 31, 2023 3:13 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhou1, Tao ; Zhang, Hawking
>
> Subject: [PATCH] drm/amdgpu: che
[AMD Official Use Only - General]
Is it better to handle CE and UE list separately?
Anyway Reviewed-by: Stanley.Yang
Regards,
Stanley
> -Original Message-
> From: amd-gfx On Behalf Of Tao
> Zhou
> Sent: Tuesday, October 31, 2023 3:09 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Chai, Th
[AMD Official Use Only - General]
In fact, the UE list has only one extra entry compared with CE list.
The code structure of handling CE and UE list one by one is more simple. The
current approach has less loop cycles, either way is fine to me.
Regards,
Tao
> -Original Message-
> From:
Hi Alexey,
trying to answer some of the questions since Alex is currently on vacation.
Am 30.10.23 um 17:01 schrieb Alexey Klimov:
Hi Alex,
On Thu, 26 Oct 2023 at 19:53, Alex Deucher wrote:
On Thu, Oct 26, 2023 at 1:33 PM Alexey Klimov wrote:
#regzbot introduced: 1cfb4d612127
#regzbot titl
On Mon, Oct 30, 2023 at 11:37 PM Li Ma wrote:
>
> dorp fw version check and using max table size to init table.
>
> Signed-off-by: Li Ma
> Reviewed-by: Yifan Zhang
Acked-by: Alex Deucher
> ---
> .../gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c| 17 -
> 1 file changed, 4 inser
In Vulkan, it is the application's responsibility to perform adequate
synchronization before a sparse unmap, replace or BO destroy operation.
This adds an option to AMDGPU_VA_OPs to disable redundant implicit sync
that happens on sparse unmap or replace operations.
This has seen a significant impr
These are considered map operations rather than unmap, and there is no
point of doing implicit synchronization here.
Signed-off-by: Tatsuyuki Ishi
---
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
The current amdgpu_gem_va_update_vm only tries to perform updates for the
BO specified in the GEM ioctl; however, when a binding is split, the
adjacent bindings also need to be updated. Such updates currently ends up
getting deferred until next submission which causes stalls.
Introduce a new state
In short, eviction never really belonged to the vm_status state machine.
Even when evicted, the BO could belong to either the moved or done state.
The "evicted" state needed to handle both cases, causing greater confusion.
Additionally, there were inconsistencies in the definition of an evicted
BO
All the state changes are handled in the TTM move callback; doing it again
here just leads to more confusion.
The table update remains here because it needs to be done exactly once,
while doing it in the move callback will result it getting triggered twice,
once by the actual BO and once by the sh
In Vulkan, it is the application's responsibility to perform adequate
synchronization before a sparse unmap, replace or BO destroy operation.
Until now, the kernel applied the same rule as implicitly-synchronized
APIs like OpenGL, which with per-VM BOs made page table updates stall the
queue comple
For detection of the new explicit sync functionality without having to try
the ioctl.
Signed-off-by: Tatsuyuki Ishi
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amd
Am 31.10.23 um 14:40 schrieb Tatsuyuki Ishi:
In short, eviction never really belonged to the vm_status state machine.
I strongly disagree to that.
Even when evicted, the BO could belong to either the moved or done state.
The "evicted" state needed to handle both cases, causing greater confusi
[AMD Official Use Only - General]
> -Original Message-
> From: amd-gfx On Behalf Of Li Ma
> Sent: Monday, October 30, 2023 6:55 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Zhang, Yifan
> ; Feng, Kenneth ; Ma, Li
> ; Du, Xiaojian
> Subject: [PATCH v2] drm/amd/swsmu:
Am 31.10.23 um 14:40 schrieb Tatsuyuki Ishi:
The current amdgpu_gem_va_update_vm only tries to perform updates for the
BO specified in the GEM ioctl; however, when a binding is split, the
adjacent bindings also need to be updated. Such updates currently ends up
getting deferred until next submiss
On Tue, Oct 31, 2023 at 2:57 PM Christian König
wrote:
> Am 31.10.23 um 14:40 schrieb Tatsuyuki Ishi:
> > The current amdgpu_gem_va_update_vm only tries to perform updates for the
> > BO specified in the GEM ioctl; however, when a binding is split, the
> > adjacent bindings also need to be update
Am 31.10.23 um 14:40 schrieb Tatsuyuki Ishi:
All the state changes are handled in the TTM move callback; doing it again
here just leads to more confusion.
The state move here is because we need to track which PDs/PTs are
already validated and which have new locations reflected in the PDEs.
W
Am 31.10.23 um 14:59 schrieb Bas Nieuwenhuizen:
On Tue, Oct 31, 2023 at 2:57 PM Christian König
wrote:
Am 31.10.23 um 14:40 schrieb Tatsuyuki Ishi:
> The current amdgpu_gem_va_update_vm only tries to perform
updates for the
> BO specified in the GEM ioctl; however, when a bi
On 10/31/23 14:40, Tatsuyuki Ishi wrote:
> In Vulkan, it is the application's responsibility to perform adequate
> synchronization before a sparse unmap, replace or BO destroy operation.
> Until now, the kernel applied the same rule as implicitly-synchronized
> APIs like OpenGL, which with per-VM B
On Tue, Oct 31, 2023 at 3:08 PM Christian König
wrote:
> Am 31.10.23 um 14:59 schrieb Bas Nieuwenhuizen:
>
>
>
> On Tue, Oct 31, 2023 at 2:57 PM Christian König
> wrote:
>
>> Am 31.10.23 um 14:40 schrieb Tatsuyuki Ishi:
>> > The current amdgpu_gem_va_update_vm only tries to perform updates for
>
On Tue, Oct 31, 2023 at 3:14 PM Michel Dänzer
wrote:
> On 10/31/23 14:40, Tatsuyuki Ishi wrote:
> > In Vulkan, it is the application's responsibility to perform adequate
> > synchronization before a sparse unmap, replace or BO destroy operation.
> > Until now, the kernel applied the same rule as
Am 31.10.23 um 15:14 schrieb Michel Dänzer:
On 10/31/23 14:40, Tatsuyuki Ishi wrote:
In Vulkan, it is the application's responsibility to perform adequate
synchronization before a sparse unmap, replace or BO destroy operation.
Until now, the kernel applied the same rule as implicitly-synchroni
> On Oct 31, 2023, at 22:55, Christian König wrote:
>
> Am 31.10.23 um 14:40 schrieb Tatsuyuki Ishi:
>> In short, eviction never really belonged to the vm_status state machine.
>
> I strongly disagree to that.
>
>> Even when evicted, the BO could belong to either the moved or done state.
>>
> On Oct 31, 2023, at 23:17, Bas Nieuwenhuizen wrote:
>
>
>
> On Tue, Oct 31, 2023 at 3:08 PM Christian König
> wrote:
> Am 31.10.23 um 14:59 schrieb Bas Nieuwenhuizen:
>>
>>
>> On Tue, Oct 31, 2023 at 2:57 PM Christian König
>> wrote:
>> Am 31.10.23 um 14:40 schrieb Tatsuyuki Ishi:
>>
Am 31.10.23 um 15:39 schrieb Tatsuyuki Ishi:
On Oct 31, 2023, at 22:55, Christian König wrote:
Am 31.10.23 um 14:40 schrieb Tatsuyuki Ishi:
In short, eviction never really belonged to the vm_status state machine.
I strongly disagree to that.
Even when evicted, the BO could belong to eithe
When clearing the root PD fails we need to properly release it again.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 31 +-
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/d
On 10/31/23 15:34, Christian König wrote:
> Am 31.10.23 um 15:14 schrieb Michel Dänzer:
>
>> FWIW, RADV will also want explicit sync in the CS ioctl.
> You can replace that with the DMA-buf IOCTLs like Faith is planning to do for
> NVK.
Those ioctls cannot disable implicit sync for the CS ioctl
On Tue, Oct 31, 2023 at 11:12 AM Christian König
wrote:
>
> When clearing the root PD fails we need to properly release it again.
>
> Signed-off-by: Christian König
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 31 +-
> 1 file changed, 16 inse
Ping on this series?
Alex
On Sat, Oct 28, 2023 at 2:32 AM Alex Deucher wrote:
>
> The ATRM ACPI method is for fetching the dGPU vbios rom
> image on laptops and all-in-one systems. It should not be
> used for external add in cards. If the dGPU is thunderbolt
> connected, don't try ATRM.
>
> v2
On Sat, Oct 28, 2023 at 8:05 AM José Pekkarinen
wrote:
>
> On 2023-10-27 20:55, Deucher, Alexander wrote:
> > [Public]
> >
> >> -Original Message-
> >> From: José Pekkarinen
> >> Sent: Friday, October 27, 2023 12:59 PM
> >> To: Deucher, Alexander ; Koenig, Christian
> >> ; Pan, Xinhui ;
>
WREG32/RREG32_SOC15_IP_NO_KIQ and amdgpu_virt_kiq_reg_write_reg_wait
are not using the correct rlcg interface or mec engine, respectively.
Add xcc instance parameter to them.
v4: Use GET_INST and squash commit with:
"drm/amdgpu: Add xcc_inst param to amdgpu_virt_kiq_reg_write_reg_wait"
v3: xcc n
Issues were reported with commit 1cfb4d612127
("drm/amdgpu: put MQDs in VRAM") on an ADLINK Ampere
Altra Developer Platform (AVA developer platform).
Various ARM systems seem to have problems related
to PCIe and MMIO access. In this case, I'm not sure
if this is specific to the ADLINK platform or
Reported by coccinelle, the following patch will move the
following 1 element arrays to flexible arrays.
drivers/gpu/drm/radeon/atombios.h:5523:32-48: WARNING use flexible-array member
instead
(https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays)
dri
On 2023-10-31 17:45, Alex Deucher wrote:
On Sat, Oct 28, 2023 at 8:05 AM José Pekkarinen
wrote:
On 2023-10-27 20:55, Deucher, Alexander wrote:
> [Public]
>
>> -Original Message-
>> From: José Pekkarinen
>> Sent: Friday, October 27, 2023 12:59 PM
>> To: Deucher, Alexander ; Koenig, Chr
On 10/27/2023 10:42, Alex Deucher wrote:
The ATRM ACPI method is for fetching the dGPU vbios rom
image on laptops and all-in-one systems. It should not be
used for external add in cards. If the dGPU is thunderbolt
connected, don't try ATRM.
v2: pci_is_thunderbolt_attached only works for Intel.
On 10/27/2023 10:42, Alex Deucher wrote:
It's only valid on Intel systems with the Intel VSEC.
Use dev_is_removable() instead. This should do the right
thing regardless of the platform.
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2925
Signed-off-by: Alex Deucher
---
Reviewed-by: Ma
On 10/27/2023 10:42, Alex Deucher wrote:
AMD dGPUs have integrated FW that runs as soon as the
device gets power and initializes the board (determines
the amount of memory, provides configuration details to
the driver, etc.). For direct PCIe attached cards this
happens as soon as power is applie
On Tue, Oct 31, 2023 at 1:09 PM José Pekkarinen
wrote:
>
> Reported by coccinelle, the following patch will move the
> following 1 element arrays to flexible arrays.
>
> drivers/gpu/drm/radeon/atombios.h:5523:32-48: WARNING use flexible-array
> member instead
> (https://www.kernel.org/doc/html/l
Hi Tatsuyuki,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.6 next-20231031
hi Jason, DRM-folk
(v7d - refreshed onto v6.6, patch-21 squashed into 14)
This patchest fixes the chicken-egg initialization problem in the 1st
version of ddebug-class-maps, that DRM-CI uncovered.
The root-problem was DECLARE_DYNDBG_CLASSMAP, which broke the K&R rule:
"define once, refer many".
more careful reading of test output reveals:
lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing
categories\n"
lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n"
class:MID
lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI
lib/t
This appears in the control-file to report an unknown class-name, which
indicates that the class_id is not authorized, and dyndbg will ignore
changes to it. Generally, this means that a DYNDBG_CLASSMAP_DEFINE or
DYNDBG_CLASSMAP_USE is missing.
But the word "unknown" appears in quite a few prdbg f
Classmaps are stored/linked in a section/array, but are each added to
the module's ddebug_table.maps list-head.
This is unnecessary; even when ddebug_attach_classmap() is handling
the builtin section (with classmaps for multiple builtin modules), its
contents are ordered, so a module's possibly mu
struct ddebug_class_param keeps a ref to the state-storage of the
param, make both flavors use the same unsigned long under-type.
ISTM this is simpler and safer.
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 2 +-
lib/dynamic_debug.c | 2 +-
2 files changed, 2 insertion
Add query_module param to ddebug_apply_class_bitmap(). This allows
its caller to update just one module, or all (as currently). We'll
use this later to propagate drm.debug to each USEr as they're
modprobed.
No functional change.
Signed-off-by: Jim Cromie
---
after `modprobe i915`, heres the m
ARRAY_SIZE works here, since array decl is complete.
no functional change
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index b53217e4b711..8116d0a0
rename param_set_dyndbg_classes: add _module_ name & arg, old name is
wrapper to new. New arg allows caller to specify that only one module
is affected by a prdbgs update.
Outer fn preserves kernel_param interface, passing NULL to inner fn.
This selectivity will be used later to narrow the scope
currently, for verbose=3, these are logged (blank lines for clarity):
dyndbg: query 0: "class DRM_UT_CORE +p" mod:*
dyndbg: split into words: "class" "DRM_UT_CORE" "+p"
dyndbg: op='+'
dyndbg: flags=0x1
dyndbg: *flagsp=0x1 *maskp=0x
dyndbg: parsed: func="" file="" module="" format="
check for actual changes before announcing them, declutter logs.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index b0e11f6bfaa2..b07aab422604 100644
--- a/lib/dynamic_
Change function's 1st arg-type, and deref in the caller.
The fn doesn't need any other fields in the struct.
no functional change.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_d
Remove the NAMED class types; these 2 classmap types accept class
names at the PARAM interface, for example:
echo +DRM_UT_CORE,-DRM_UT_KMS > /sys/module/drm/parameters/debug_names
The code works, but its only used by test-dynamic-debug, and wasn't
asked for by anyone else, so simplify things fo
The fn currently says "add-module", then "skipping" if the module has
no prdbgs. Just check 1st and return quietly.
no functional change
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynami
old_bits arg is currently a pointer to the input bits, but this could
allow inadvertent changes to the input by the fn. Disallow this.
And constify new_bits while here.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-
DECLARE_DYNDBG_CLASSMAP() has a design error; its usage fails a basic
K&R rule: "define once, refer many times".
When DRM_USE_DYNAMIC_DEBUG=y, DECLARE_DYNDBG_CLASSMAP() is used across
DRM core & drivers; they all repeat the same classmap-defn args, which
must match for the modules to respond toget
Extract input validation code, from param_set_dyndbg_module_classes()
(the sys-node >handler) to new: ddebug_classparam_clamp_input(kp),
call it from former. It takes kernel-param arg, so it can complain
about "foo: bad input".
Reuse ddparam_clamp_input(kp) in ddebug_sync_classbits(),
to validate
Reserve bit 7 to remember that a pr-debug callsite is/was:
- enabled, with +p
- wants a dynamic-prefix, with one+ of module:function:sourcfile
- was previously called
- was thus saved in the cache. NOT YET.
Its unclear whether any cache fetch would be faster than 2-3 field
fetches, but theres anot
move the DYNDBG_CLASSMAP_PARAM macro from test-dynamic-debug.c into
the header, and refine it, by distinguishing the 2 use cases:
1.DYNDBG_CLASSMAP_PARAM_REF
for DRM, to pass in extern __drm_debug by name.
dyndbg keeps bits in it, so drm can still use it as before
2.DYNDBG_CLASSMAP_PARAM
Refactor the split of duties between outer & inner fns.
The outer fn was previously just an inline unlikely forward to inner,
which did all the work.
Now, outer handles +t and +l flags itself, and calls inner only when
_DPRINTK_FLAGS_INCL_LOOKUP is needed.
No functional change.
But it does make
Incorrectly spelled CFLAGS- failed to add -DDYNAMIC_DEBUG_MODULE,
which broke builds with:
CONFIG_DRM_USE_DYNAMIC_DEBUG=y
CONFIG_DYNAMIC_DEBUG_CORE=y
CONFIG_DYNAMIC_DEBUG=n
Also add subdir-ccflags so that all drivers pick up the addition.
Fixes: 84ec67288c10 ("drm_print: wrap drm_*_dbg in dyndbg
dyndbg's dynamic prefixing (by +tmfsl flags) is needlessly expensive.
When an enabled (with +p) pr_debug is called, _DPRINTK_FLAGS_INCL_ANY
prefix decorations are sprintf'd into stack-mem for every call.
This string (or part of it) could be cached once its 1st generated,
and retrieved thereafter,
Add some basic info on classmap usage and api
cc: linux-...@vger.kernel.org
Signed-off-by: Jim Cromie
---
v5- adjustments per Randy Dunlap, me
v7b- checkpatch fixes
---
.../admin-guide/dynamic-debug-howto.rst | 60 ++-
1 file changed, 59 insertions(+), 1 deletion(-)
diff -
Add a DRM_CLASSMAP_USE declaration to 2nd batch of helpers and *_drv.c
files. For drivers, add the decl just above the module's PARAMs,
since it identifies the "inherited" drm.debug param.
Note: with CONFIG_DRM_USE_DYNAMIC_DEBUG=y, a module not also declaring
DRM_CLASSMAP_USE will have its class'
Lots of burn-in testing needed before signing, upstreaming.
NOTE: I set default Y to maximize testing by default.
Is there a better way to do this ?
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/Kconfi
-tip
next-20231031]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Tats
Use a new struct array to define the asic information which
asic type needs to be fixed.
Signed-off-by: Ma Jun
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 35 ++---
include/drm/amd_asic_type.h | 5
2 files changed, 31 insertions(+), 9 deletions(-)
diff --
Some special new asics use the same device id as Sienna_Cichlid.
So fix it.
Signed-off-by: Ma Jun
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index
Ma, Jun would like to recall the message, "[PATCH 2/2] drm/amdgpu: Fix the the
asic type of some new asics".
Ma, Jun would like to recall the message, "[PATCH 1/2] drm/amdgpu: Optimize the
asic type fix code".
-tip
next-20231031]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Tats
Some new asics use the same device id as Sienna_Cichlid.
So fix it.
Signed-off-by: Ma Jun
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 756cf495
Use a new struct array to define the asic information which
asic type needs to be fixed.
Signed-off-by: Ma Jun
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 35 ++---
include/drm/amd_asic_type.h | 5
2 files changed, 31 insertions(+), 9 deletions(-)
diff --
[AMD Official Use Only - General]
Reviewed-by: Stanley.Yang
Regards,
Stanley
> -Original Message-
> From: amd-gfx On Behalf Of Tao
> Zhou
> Sent: Tuesday, October 31, 2023 3:08 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Lazar, Lijo ; Zhou1, Tao
> Subject: [PATCH] drm/amdgpu: Don't wa
79 matches
Mail list logo
