[PATCH 6/6] drm/amd/pm: enable memory temp reading for SMU 13.0.0

With the latest vbios, the memory temp reading is working. Signed-off-by: Evan Quan Reviewed-by: Hawking Zhang Change-Id: I3b4679f03e5ff7cf8e0b68c095d210e608149fcb --- drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 2 -- 1 file changed, 2 deletions(-) diff --git

[PATCH 5/6] drm/amd/pm: enable more dpm features for SMU 13.0.0

Enable OOB Monitor and SOC CG which are ready since 78.38.0. Signed-off-by: Evan Quan Reviewed-by: Hawking Zhang Acked-by: Alex Deucher Change-Id: I0d7334106917ac83fff2b673ec7e9eb096089afe --- drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 3 +++ 1 file changed, 3 insertions(+) diff

[PATCH 3/6] drm/amd/pm: update SMU 13.0.0 driver_if header

To align with 78.37.0 and later PMFWs. Signed-off-by: Evan Quan Reviewed-by: Hawking Zhang Change-Id: I17c3a6b466c921cb5ffe5025a94023fae478c80e --- .../inc/pmfw_if/smu13_driver_if_v13_0_0.h | 22 +-- drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 2 +- 2 files changed, 11

[PATCH 2/6] drm/amd/pm: skip dpm disablement on suspend for SMU 13.0.0

Since PMFW will handle this properly. Driver involvement is unnecessary. Signed-off-by: Evan Quan Reviewed-by: Hawking Zhang Change-Id: I19be26eed090d57040553f5cdff9534072f08106 --- drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 4/6] drm/amd/pm: correct the softpptable ids used for SMU 13.0.0

To better match with the pptable_id settings from VBIOS. Signed-off-by: Evan Quan Reviewed-by: Hawking Zhang Acked-by: Alex Deucher Change-Id: I3379443067a5df3a2fb04ff1bc48e8c8f28e1c66 --- .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c| 47 ++- 1 file changed, 35

[PATCH 1/6] drm/amd/pm: enable more dpm features for SMU 13.0.0

Enable MP0CLK DPM and FW Dstate since they are already supported by latest 78.36.0 PMFW. Signed-off-by: Evan Quan Reviewed-by: Hawking Zhang Change-Id: I75b6129dab509a51ccaf92bbc0b094eae41ea20f --- drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 3 +++ 1 file changed, 3 insertions(+)

RE: [PATCH] drm/amdgpu/discovery: validate VCN and SDMA instances

Reviewed-by: Guchun Chen Regards, Guchun -Original Message- From: amd-gfx On Behalf Of Alex Deucher Sent: Tuesday, May 17, 2022 2:17 AM To: amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander Subject: [PATCH] drm/amdgpu/discovery: validate VCN and SDMA instances Validate the VCN and

[linux-next:master] BUILD REGRESSION 3f7bdc402fb06f897ff1f492a2d42e1f7c2efedb

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 3f7bdc402fb06f897ff1f492a2d42e1f7c2efedb Add linux-next specific files for 20220516 Error/Warning reports: https://lore.kernel.org/linux-mm/202204291924.vtgzmeri-...@intel.com https

Re: [PATCH 2/3] drm/amdgpu: add AMDGPU_VM_NOALLOC

Dmesg doesn't contain anything. There is no backtrace because it's not a crash. The VA map ioctl just fails with the new flag. It looks like the flag is considered invalid. Marek On Mon., May 16, 2022, 12:13 Christian König, < ckoenig.leichtzumer...@gmail.com> wrote: > I don't have access to

[PATCH v2 11/13] mm: handling Non-LRU pages returned by vm_normal_pages

With DEVICE_COHERENT, we'll soon have vm_normal_pages() return device-managed anonymous pages that are not LRU pages. Although they behave like normal pages for purposes of mapping in CPU page, and for COW. They do not support LRU lists, NUMA migration or THP. We also introduced a FOLL_LRU flag

[PATCH v2 13/13] tools: add selftests to hmm for COW in device memory

The objective is to test device migration mechanism in pages marked as COW, for private and coherent device type. In case of writing to COW private page(s), a page fault will migrate pages back to system memory first. Then, these pages will be duplicated. In case of COW device coherent type, pages

[PATCH v2 08/13] lib: add support for device coherent type in test_hmm

Device Coherent type uses device memory that is coherently accesible by the CPU. This could be shown as SP (special purpose) memory range at the BIOS-e820 memory enumeration. If no SP memory is supported in system, this could be faked by setting CONFIG_EFI_FAKE_MEMMAP. Currently, test_hmm only

[PATCH v2 12/13] tools: add hmm gup tests for device coherent type

The intention is to test hmm device coherent type under different get user pages paths. Also, test gup with FOLL_LONGTERM flag set in device coherent pages. These pages should get migrated back to system memory. Signed-off-by: Alex Sierra Reviewed-by: Alistair Popple ---

[PATCH v2 10/13] tools: update test_hmm script to support SP config

Add two more parameters to set spm_addr_dev0 & spm_addr_dev1 addresses. These two parameters configure the start SP addresses for each device in test_hmm driver. Consequently, this configures zone device type as coherent. Signed-off-by: Alex Sierra Acked-by: Felix Kuehling Reviewed-by: Alistair

[PATCH v2 05/13] drm/amdkfd: add SPM support for SVM

When CPU is connected throug XGMI, it has coherent access to VRAM resource. In this case that resource is taken from a table in the device gmc aperture base. This resource is used along with the device type, which could be DEVICE_PRIVATE or DEVICE_COHERENT to create the device page map region.

[PATCH v2 09/13] tools: update hmm-test to support device coherent type

Test cases such as migrate_fault and migrate_multiple, were modified to explicit migrate from device to sys memory without the need of page faults, when using device coherent type. Snapshot test case updated to read memory device type first and based on that, get the proper returned results

[PATCH v2 07/13] lib: test_hmm add module param for zone device type

In order to configure device coherent in test_hmm, two module parameters should be passed, which correspond to the SP start address of each device (2) spm_addr_dev0 & spm_addr_dev1. If no parameters are passed, private device type is configured. Signed-off-by: Alex Sierra Acked-by: Felix

[PATCH v2 03/13] mm: remove the vma check in migrate_vma_setup()

From: Alistair Popple migrate_vma_setup() checks that a valid vma is passed so that the page tables can be walked to find the pfns associated with a given address range. However in some cases the pfns are already known, such as when migrating device coherent pages during pin_user_pages() meaning

[PATCH v2 06/13] lib: test_hmm add ioctl to get zone device type

new ioctl cmd added to query zone device type. This will be used once the test_hmm adds zone device coherent type. Signed-off-by: Alex Sierra Acked-by: Felix Kuehling Reviewed-by: Alistair Poppple Signed-off-by: Christoph Hellwig --- lib/test_hmm.c | 23 +--

[PATCH v2 04/13] mm/gup: migrate device coherent pages when pinning instead of failing

From: Alistair Popple Currently any attempts to pin a device coherent page will fail. This is because device coherent pages need to be managed by a device driver, and pinning them would prevent a driver from migrating them off the device. However this is no reason to fail pinning of these

[PATCH v2 01/13] mm: add zone device coherent type memory support

Device memory that is cache coherent from device and CPU point of view. This is used on platforms that have an advanced system bus (like CAPI or CXL). Any page of a process can be migrated to such memory. However, no one should be allowed to pin such memory so that it can always be evicted.

[PATCH v2 02/13] mm: add device coherent vma selection for memory migration

This case is used to migrate pages from device memory, back to system memory. Device coherent type memory is cache coherent from device and CPU point of view. Signed-off-by: Alex Sierra Acked-by: Felix Kuehling Reviewed-by: Alistair Poppple Signed-off-by: Christoph Hellwig ---

[PATCH v2 00/13] Add MEMORY_DEVICE_COHERENT for coherent device memory mapping

This is our MEMORY_DEVICE_COHERENT patch series rebased and updated for current 5.18-rc7. Changes since the last version: - Fixed problems with migration during long-term pinning in get_user_pages - Open coded vm_normal_lru_pages as suggested in previous code review - Update hmm_gup_test with

[PATCH v2 27/27] dyndbg/drm: POC add tracebits sysfs-knob

clone DRM.debug interface to DRM.tracebits: ie map bits to drm-debug-categories, except this interface enables messages to tracefs, not to syslog. This reuses dyndbg's register-classes API to add the new sysfs-knob: drm_drv.h: [A] 2nd use of DYNAMIC_DEBUG_CLASSES(drm_trace_classes), which

[PATCH v2 21/27] drm_print: prefer bare printk KERN_DEBUG on generic fn

drm_print.c calls pr_debug() just once, from __drm_printfn_debug(), which is a generic/service fn. The callsite is compile-time enabled by DEBUG in both DYNAMIC_DEBUG=y/n builds. For dyndbg builds, reverting this callsite back to bare printk is correcting a few anti-features: 1- callsite is

[PATCH v2 24/27] dyndbg: add _DPRINTK_FLAGS_TRACE

add new flag, and OR it into _DPRINTK_FLAGS_ENABLED definition CC: vincent.whitchu...@axis.com Signed-off-by: Jim Cromie --- include/linux/dynamic_debug.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h index

[PATCH v2 22/27] drm_print: add _ddebug desc to drm_*dbg prototypes

Add a struct _ddebug ptr to drm_dbg() and drm_dev_dbg() protos, and upgrade their callers - the interposed macros added recently, to use _dynamic_func_call_no_desc(); ie drop the '_no_desc', since the factory macro's callees (these 2 functions) are now expecting the arg. This makes those

[PATCH v2 25/27] dyndbg: add write-events-to-tracefs code

adds: ddebug_trace() uses trace_console() temporarily to issue printk:console event uses internal-ish __ftrace_trace_stack code: 4-context buffer stack, barriers per Steve Rostedt call it from new funcs: ddebug_printk() - print to both syslog/tracefs ddebug_dev_printk() - dev-print to

[PATCH v2 23/27] dyndbg: add _DPRINTK_FLAGS_ENABLED

Distinguish the condition: _DPRINTK_FLAGS_ENABLED from the bit: _DPRINTK_FLAGS_PRINT (and define former as latter), in preparation to add another bit next: _DPRINTK_FLAGS_TRACE And change JUMP_LABEL code block to use the more general _DPRINTK_FLAGS_ENABLED symbol. Also add a 'K' to get new

[PATCH v2 26/27] dyndbg: 4 new trace-events: pr_debug, dev_dbg, drm_{, dev}debug

ddebug_trace() currently issues a single printk:console event. Replace that, adding include/trace/events/dyndbg.h, which defines 2 new events: - dyndbg:prdbg - from trace_prdbg() - if !dev - dyndbg:devdbg - from trace_devdbg() - if !!dev This links the legacy pr_debug API to tracefs, via

[PATCH v2 20/27] drm_print: refine drm_debug_enabled for jump-label

In order to use dynamic-debug's jump-label optimization in drm-debug, its clarifying to refine drm_debug_enabled into 3 uses: 1. drm_debug_enabled - legacy, public 2. __drm_debug_enabled - optimized for dyndbg jump-label enablement. 3. _drm_debug_enabled - pr_debug instrumented, observable 1.

[PATCH v2 18/27] drm_print: interpose drm_*dbg with forwarding macros

change drm_dev_dbg & drm_dbg to macros, which forward to the renamed functions (with __ prefix added). Those functions sit below the categorized layer of macros implementing the DRM debug.category API, and implement most of it. These are good places to insert dynamic-debug jump-label mechanics,

[PATCH v2 17/27] drm_print: condense enum drm_debug_category

enum drm_debug_category has 10 categories, but is initialized with bitmasks which require 10 bits of underlying storage. By using natural enumeration, and moving the BIT(cat) into drm_debug_enabled(), the enum fits in 4 bits, allowing the category to be represented directly in pr_debug callsites,

[PATCH v2 15/27] drm: POC drm on dyndbg - map class-names to drm_debug_category's

Invoke DYNAMIC_DEBUG_CLASSES from drm_drv.h. This declares a maybe-unused struct ddebug_known_classes_map var, initialized with: . var: passed to dynamic_debug_register_classes() . class-names: "DRM_UT_CORE", "DRM_UT_DRIVER", "DRM_UT_KMS", etc. These names map to .class_id's by their index,

[PATCH v2 19/27] drm_print: wrap drm_*_dbg in dyndbg descriptor factory macro

For CONFIG_DRM_USE_DYNAMIC_DEBUG=y, wrap __drm_dbg() & __drm_dev_dbg() in one of dyndbg's Factory macros: _dynamic_func_call_no_desc(). Next, those functions are adapted to accept a descriptor arg, and we drop the _no_desc suffix, then the (~4000) drm.debug callsites will be controllable by their

[PATCH v2 16/27] drm/print: POC drm on dyndbg - use bitmap

POC: adapt drm_print to use/test the bitmap callback support. with dynamic_debug.verbose=1: bash-5.1# echo 1 > /sys/module/drm/parameters/debug [ 33.697039] dyndbg: set_dyndbg_classes: new 0x1 current 0x0 [ 33.697571] dyndbg: query 0: "class DRM_UT_CORE +p" mod:* [ 33.698072] dyndbg: no

[PATCH v2 14/27] dyndbg: add test_dynamic_debug module

Demonstrate dyndbg's "class FOO" and bitmap-to-classes support. This support is meant to plug into drm.debug system, and largely replace the use of drm_debug_enabled(category) with JUMP_LABELs. Recap: #> echo class DRM_UT_CORE +p > /proc/dynamic_debug/control This is made "safe" because

[PATCH v2 13/27] dyndbg: add __pr_debug_cls(class, fmt, ...)

For selftest purposes, add __pr_debug_cls(class, fmt, ...) I didn't think we'd need to define this, since DRM effectively has it already. But test_dynamic_debug needs it in order to demonstrate all the moving parts. Note the __ prefix; its not intended for general use, and doesn't include any

[PATCH v2 12/27] dyndbg: change zero-or-one classes-map to maps list

Upgrade single classes-map to list of them: This allows multiple DYNAMIC_DEBUG_CLASSES(class-map)s per module, using _base to segment the 0..30 classid space. alter struct ddebug table: replace .classes (a ) with maps (list-head) dynamic_debug_register_classes(map) - adds new map to maps list.

[PATCH v2 10/27] dyndbg: let query-modname override defaulting modname

dyndbg's control-parser: ddebug_parse_query(), requires that search terms: module, func, file, lineno, are not used 2x in a query; a thing cannot be named both foo and bar (not even wildcards, no OR is contemplated). Amend the treatment of module; while still enforcing the 2x rule on it, set the

[PATCH v2 11/27] dyndbg: support symbolic class-names in bitmap

Extend the sysfs-node bitmap support to accept class-names registered by the module, allowing: #> echo DRM_UT_CORE,-DRM_UT_ATOMIC,+DRM_UT_KMS \ > /sys/module/drm/parameters/debug Do this in param_set_dyndbg_class_strings(), which is called from param_set_dyndbg_classes() when the

[PATCH v2 08/27] dyndbg: add drm.debug style bitmap support

Add kernel_param_ops and callbacks to implement a bitmap in a sysfs-node. IE, add these: - int param_set_dyndbg_classes() - int param_get_dyndbg_classes() - struct kernel_param_ops param_ops_dyndbg_classes Following the model of kernel/params.c STANDARD_PARAM_DEFS, these are non-static and

[PATCH v2 07/27] dyndbg: validate class FOO on module

Add module-to-class validation, in #> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control If a query has "class FOO", ddebug_validate_classname (called from ddebug_change) requires that FOO is known to module X, otherwize X is skipped entirely. The choice of FOO is highly selective, giving

[PATCH v2 09/27] Doc/dyndbg: document new class class_name query support

The added paragraph is slightly process oriented, rather than in language of guarantees; I thought the implications were clear enough. It does perhaps undersell the selectivity gained with string class_names; only drm/* would sanely register DRM_UT_CORE etc, so doing multiple "module

[PATCH v2 05/27] dyndbg: add exclusive class_id to pr_debug callsites

DRM issues ~10 exclusive categories of debug messages; to represent this directly in dyndbg, add a new field: struct _ddebug.class_id:5. We only need 4 bits for drm, and with that reserved, we have 2 to spare on 32 bit builds; lets take one extra (5 bits total), and keep a spare bit. 32

[PATCH v2 06/27] dyndbg: add dynamic_debug_(un)register_classes

Add dynamic_debug_register_classes() to API, allowing user modules (builtin and loadable) to register class_names for the .class_id's they are using. Knowing classes is 1st step to validating with them. Add dynamic_debug_unregister_classes() also. Add struct ddebug_known_classes_map: maps known

[PATCH v2 03/27] dyndbg: fix module.dyndbg handling

For CONFIG_DYNAMIC_DEBUG=N, the ddebug_dyndbg_module_param_cb() stub-fn is too permissive: bash-5.1# modprobe drm JUNKdyndbg bash-5.1# modprobe drm dyndbgJUNK [ 42.933220] dyndbg param is supported only in CONFIG_DYNAMIC_DEBUG builds [ 42.937484] ACPI: bus type drm_connector registered This

[PATCH v2 04/27] dyndbg: drop EXPORTed dynamic_debug_exec_queries

This exported fn is unused, and is effectively obsoleted by a forthcoming commit, so remove it. The export was added to let drm control pr_debugs, as part of using them to avoid drm_debug_enabled overheads. But following patches implement the drm.debug interface, and adapt drm to just use it, so

[PATCH v2 02/27] dyndbg: show both old and new in change-info

print "old -> new" flag values in the info("change") message. no functional change. Signed-off-by: Jim Cromie --- lib/dynamic_debug.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index a56c1286ffa4..ca2a28f1d51c

[PATCH v2 01/27] dyndbg: fix static_branch manipulation

In https://lore.kernel.org/lkml/20211209150910.ga23...@axis.com/ Vincent's patch commented on, and worked around, a bug toggling static_branch's, when a 2nd PRINTK-ish flag was added. The bug results in a premature static_branch_disable when the 1st of 2 flags was disabled. The cited commit

[RFC PATCH v2 00/27] DRM.debug on DYNAMIC_DEBUG, add trace events

DRM.debug API is 23 macros, issuing 10 exclusive categories of debug messages. By rough count, they are used 5140 times in the kernel. These all call drm_dbg or drm_devdbg, which call drm_debug_enabled(), which checks bits in global __drm_debug. Some of these are page-flips and vblanks, and get

[PATCH] drm/amdgpu: Unmap legacy queue when MES is enabled

This fixes a kernel oops when MES is not enabled. Reported-by: Kenny Ho Suggested-by: Jack Xiao Reviewed-by: Alex Deucher Signed-off-by: Luben Tuikov Fixes: d69e773ca75b8f ("drm/amdgpu: add mes unmap legacy queue routine") Fixes: 36d7a7094750fc ("drm/amdgpu: add init support for GFX11 (v2)")

Re: [PATCH] drm/amdkfd: simplify cpu hive assignment

Am 2022-05-16 um 10:43 schrieb Jonathan Kim: CPU hive assignment currently assumes when a GPU hive is connected_to_cpu, there is only one hive in the system. Only assign CPUs to the hive if they are explicitly directly connected to the GPU hive to get rid of the need for this assumption. It's

Re: VCN_INFO_TABLE_MAX_NUM_INSTANCES vs AMDGPU_MAX_VCN_INSTANCES

Am 16.05.22 um 20:15 schrieb Alex Deucher: On Mon, May 16, 2022 at 2:10 PM Christian König wrote: Am 16.05.22 um 19:49 schrieb Ernst Sjöstrand: Den mån 16 maj 2022 kl 17:13 skrev Alex Deucher : On Sun, May 15, 2022 at 11:46 AM Ernst Sjöstrand wrote: smatch found this problem on

[PATCH 1/2] drm/amdkfd: port cwsr trap handler from dkms branch

It is to simplify trap handler support for new asics in the future. Signed-off-by: Eric Huang --- .../gpu/drm/amd/amdkfd/cwsr_trap_handler.h| 2527 + .../amd/amdkfd/cwsr_trap_handler_gfx10.asm| 325 ++- .../drm/amd/amdkfd/cwsr_trap_handler_gfx9.asm | 244 +- 3 files

[PATCH 2/2] drm/amdkfd: Add gfx11 trap handler

From: Jay Cornwall Based on gfx10 with following changes: - GPR_ALLOC.VGPR_SIZE field moved (and size corrected in gfx10) - s_sendmsg_rtn_b64 replaces some s_sendmsg/s_getreg - Buffer instructions no longer have direct-to-LDS modifier Signed-off-by: Jay Cornwall Reviewed-by: Laurent

Re: [linux-next:master] BUILD REGRESSION 1e1b28b936aed946122b4e0991e7144fdbbfd77e

On Sun, 15 May 2022 21:00:21 +0800 kernel test robot wrote: > tree/branch: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > branch HEAD: 1e1b28b936aed946122b4e0991e7144fdbbfd77e Add linux-next > specific files for 20220513 > > Error/Warning reports: > >

Re: [PATCH] drm/amdgpu: Clean up of initializing doorbells for gfx_v9 and gfx_v10

Applied. Thanks! Alex On Mon, May 16, 2022 at 8:01 AM wrote: > > From: Haohui Mai > > Clean up redundant, copy-paste code blocks during the intialization of > the doorbells in mqd_init(). > > Signed-off-by: Haohui Mai > --- > drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 17 - >

Re: VCN_INFO_TABLE_MAX_NUM_INSTANCES vs AMDGPU_MAX_VCN_INSTANCES

Looks good to me! Den mån 16 maj 2022 kl 20:15 skrev Alex Deucher : > On Mon, May 16, 2022 at 2:10 PM Christian König > wrote: > > > > Am 16.05.22 um 19:49 schrieb Ernst Sjöstrand: > > > > Den mån 16 maj 2022 kl 17:13 skrev Alex Deucher : > >> > >> On Sun, May 15, 2022 at 11:46 AM Ernst

[PATCH] drm/amdgpu/discovery: validate VCN and SDMA instances

Validate the VCN and SDMA instances against the driver structure sizes to make sure we don't get into a situation where the firmware reports more instances than the driver supports. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 17 ++--- 1 file

Re: VCN_INFO_TABLE_MAX_NUM_INSTANCES vs AMDGPU_MAX_VCN_INSTANCES

On Mon, May 16, 2022 at 2:10 PM Christian König wrote: > > Am 16.05.22 um 19:49 schrieb Ernst Sjöstrand: > > Den mån 16 maj 2022 kl 17:13 skrev Alex Deucher : >> >> On Sun, May 15, 2022 at 11:46 AM Ernst Sjöstrand wrote: >> > >> > smatch found this problem on amd-staging-drm-next: >> > >> >

Re: VCN_INFO_TABLE_MAX_NUM_INSTANCES vs AMDGPU_MAX_VCN_INSTANCES

Am 16.05.22 um 19:49 schrieb Ernst Sjöstrand: Den mån 16 maj 2022 kl 17:13 skrev Alex Deucher : On Sun, May 15, 2022 at 11:46 AM Ernst Sjöstrand wrote: > > smatch found this problem on amd-staging-drm-next: > > drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1443

Re: VCN_INFO_TABLE_MAX_NUM_INSTANCES vs AMDGPU_MAX_VCN_INSTANCES

Den mån 16 maj 2022 kl 17:13 skrev Alex Deucher : > On Sun, May 15, 2022 at 11:46 AM Ernst Sjöstrand wrote: > > > > smatch found this problem on amd-staging-drm-next: > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1443 > amdgpu_discovery_get_vcn_info() error: buffer overflow >

Re: [PATCH v2 00/19] DC/DM changes needed for amdgpu PSR-SU

On Mon, 16 May 2022 at 18:23, Leo Li wrote: > > > > On 2022-05-12 13:39, Daniel Vetter wrote: > > On Thu, 12 May 2022 at 19:22, Zhang, Dingchen (David) > > wrote: > >> > >> [AMD Official Use Only - General] > >> > >> Hi Daniel > >> > >> Thanks for your comments and explanations. I replied

Re: [PATCH v2 00/19] DC/DM changes needed for amdgpu PSR-SU

On 2022-05-12 13:39, Daniel Vetter wrote: On Thu, 12 May 2022 at 19:22, Zhang, Dingchen (David) wrote: [AMD Official Use Only - General] Hi Daniel Thanks for your comments and explanations. I replied in-line and look forward to more discussion. regards David From: Daniel Vetter

Re: [PATCH 2/3] drm/amdgpu: add AMDGPU_VM_NOALLOC

I don't have access to any gfx10 hardware. Can you give me a dmesg and/or backtrace, etc..? I can't push this unless it's working properly. Christian. Am 16.05.22 um 14:56 schrieb Marek Olšák: Reproduction steps: - use mesa/main on gfx10.3 (not sure what other GPUs do) - run:

Re: [PATCH] drm/amdgpu: Fix multiple GPU resets in XGMI hive.

On 2022-05-16 11:08, Christian König wrote: Am 16.05.22 um 16:12 schrieb Andrey Grodzovsky: Ping Ah, yes sorry. Andrey On 2022-05-13 11:41, Andrey Grodzovsky wrote: Yes, exactly that's the idea. Basically the reset domain knowns which amdgpu devices it needs to reset together. If

Re: VCN_INFO_TABLE_MAX_NUM_INSTANCES vs AMDGPU_MAX_VCN_INSTANCES

On Sun, May 15, 2022 at 11:46 AM Ernst Sjöstrand wrote: > > smatch found this problem on amd-staging-drm-next: > > drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1443 > amdgpu_discovery_get_vcn_info() error: buffer overflow > 'adev->vcn.vcn_codec_disable_mask' 2 <= 3 > > This is caused by: >

Re: [PATCH] drm/amdgpu: Fix multiple GPU resets in XGMI hive.

Am 16.05.22 um 16:12 schrieb Andrey Grodzovsky: Ping Ah, yes sorry. Andrey On 2022-05-13 11:41, Andrey Grodzovsky wrote: Yes, exactly that's the idea. Basically the reset domain knowns which amdgpu devices it needs to reset together. If you then represent that so that you always have

Re: [PATCH v12] drm/amdgpu: add drm buddy support to amdgpu

On Mon, May 16, 2022 at 8:40 AM Mike Lothian wrote: > > Hi > > The merge window for 5.19 will probably be opening next week, has > there been any progress with this bug? It took a while to find a combination of GPUs that would repro the issue, but now that we can, it is still being investigated.

[PATCH] drm/amdkfd: simplify cpu hive assignment

CPU hive assignment currently assumes when a GPU hive is connected_to_cpu, there is only one hive in the system. Only assign CPUs to the hive if they are explicitly directly connected to the GPU hive to get rid of the need for this assumption. It's more efficient to do this when querying IO

Re: [PATCH] drm/amdgpu: Fix multiple GPU resets in XGMI hive.

Ping Andrey On 2022-05-13 11:41, Andrey Grodzovsky wrote: Yes, exactly that's the idea. Basically the reset domain knowns which amdgpu devices it needs to reset together. If you then represent that so that you always have a hive even when you only have one device in it, or if you put an

RE: [PATCH v2 00/11] DC Patches May 16, 2022

[Public] Hi all, This week this patchset was tested on the following systems: Sapphire Pulse RX5700XT Reference AMD RX6800 Engineering board with Ryzen 9 5900H These systems were tested on the following display types: eDP, (1080p 60hz [5900H]) VGA and DVI (1680x1050 60HZ [DP to VGA/DVI,

Re: Screen corruption using radeon kernel driver

On Mon, Apr 25, 2022 at 01:22:04PM -0400, Alex Deucher wrote: > + dri-devel > > On Mon, Apr 25, 2022 at 3:33 AM Krylov Michael wrote: > > > > Hello! > > > > After updating my Linux kernel from version 4.19 (Debian 10 version) to > > 5.10 (packaged with Debian 11), I've noticed that the image > >

Re: [PATCH 2/3] drm/amdgpu: add AMDGPU_VM_NOALLOC

Reproduction steps: - use mesa/main on gfx10.3 (not sure what other GPUs do) - run: radeonsi_mall_noalloc=true glxgears Marek On Mon, May 16, 2022 at 7:53 AM Christian König < ckoenig.leichtzumer...@gmail.com> wrote: > Crap, do you have a link to the failure? > > Am 16.05.22 um 13:10 schrieb

Re: [PATCH v1 14/15] tools: add hmm gup tests for device coherent type

Alex Sierra writes: > The intention is to test hmm device coherent type under different get > user pages paths. Also, test gup with FOLL_LONGTERM flag set in > device coherent pages. These pages should get migrated back to system > memory. > > Signed-off-by: Alex Sierra > --- >

Re: [PATCH v12] drm/amdgpu: add drm buddy support to amdgpu

Hi The merge window for 5.19 will probably be opening next week, has there been any progress with this bug? Thanks Mike On Mon, 2 May 2022 at 17:31, Mike Lothian wrote: > > On Mon, 2 May 2022 at 16:54, Arunpravin Paneer Selvam > wrote: > > > > > > > > On 5/2/2022 8:41 PM, Mike Lothian wrote:

[PATCH] drm/amdgpu: Clean up of initializing doorbells for gfx_v9 and gfx_v10

From: Haohui Mai Clean up redundant, copy-paste code blocks during the intialization of the doorbells in mqd_init(). Signed-off-by: Haohui Mai --- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 17 - drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 17 - 2 files changed, 34

Re: [PATCH 2/3] drm/amdgpu: add AMDGPU_VM_NOALLOC

Crap, do you have a link to the failure? Am 16.05.22 um 13:10 schrieb Marek Olšák: I forgot to say: The NOALLOC flag causes an allocation failure, so there is a kernel bug somewhere. Marek On Mon, May 16, 2022 at 7:06 AM Marek Olšák wrote: FYI, I think it's time to merge this because

Re: [PATCH 2/3] drm/amdgpu: add AMDGPU_VM_NOALLOC

I forgot to say: The NOALLOC flag causes an allocation failure, so there is a kernel bug somewhere. Marek On Mon, May 16, 2022 at 7:06 AM Marek Olšák wrote: > FYI, I think it's time to merge this because the Mesa commits are going to > be merged in ~30 minutes if Gitlab CI is green, and that

Re: [PATCH 2/3] drm/amdgpu: add AMDGPU_VM_NOALLOC

FYI, I think it's time to merge this because the Mesa commits are going to be merged in ~30 minutes if Gitlab CI is green, and that includes updated amdgpu_drm.h. Marek On Wed, May 11, 2022 at 2:55 PM Marek Olšák wrote: > Ok sounds good. > > Marek > > On Wed., May 11, 2022, 03:43 Christian

RE: [Intel-gfx] [V2 2/3] drm/i915/display/debug: Expose crtc current bpc via debugfs

On Tue, 12 Apr 2022, "Murthy, Arun R" wrote: >> -Original Message- >> From: Intel-gfx On Behalf Of >> Bhanuprakash Modem >> Sent: Monday, April 11, 2022 3:21 PM >> To: intel-...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; amd- >> g...@lists.freedesktop.org;

Re: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector debugfs to drm

On Mon, 02 May 2022, Harry Wentland wrote: > Both the kernel and IGT series look good to me. > > I recommend you merge the entire kernel set as one into drm-next. We > can pull it into amd-staging-drm-next so as not to break our CI once > the IGT patches land. Can we read that as an ack to merge

[PATCH] drm/amdgpu: Off by one in dm_dmub_outbox1_low_irq()

The > ARRAY_SIZE() should be >= ARRAY_SIZE() to prevent an out of bounds access. Fixes: e27c41d5b068 ("drm/amd/display: Support for DMUB HPD interrupt handling") Signed-off-by: Dan Carpenter --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- 1 file changed, 1 insertion(+), 1