Am 05.12.22 um 03:27 schrieb jiadong@amd.com:
From: Jiadong Zhu
lkp robot reported missing-prototypes and unused-but-set-variable warnings on
some functions of amdgpu_mcbp_mux.c. Make them static and remove the unused
variable.
Reported-by: kernel test robot
Signed-off-by: Jiadong Zhu
- There is no need to evict resources from vram to sram for sriov
because GPU is still powered on. And evicet is taking too much time
that would cause full access mode timedout in multi-vf mode.
Signed-off-by: Shikang Fan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 +---
1 file ch
Add CG support for GFX/MC/HDP/ATHUB/IH/BIF.
Signed-off-by: Tim Huang
---
drivers/gpu/drm/amd/amdgpu/soc21.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/soc21.c
b/drivers/gpu/drm/amd/amdgpu/soc21.c
index 41b94c824717..7d5fdf45
Enable GFX Power Gating control for GC IP v11.0.4.
Signed-off-by: Tim Huang
---
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
index bf78440e1e70..506c285d5f49 100644
--
Enable GFX IP v11.0.4 CG gate/ungate control.
Signed-off-by: Tim Huang
---
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
index 506c285d5f49..a56c6e106d00 100644
--- a/dri
Add tmz support for GC 11.0.4.
Signed-off-by: Tim Huang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
index e970e3760cec..02a4c93673ce 100644
--- a/drivers/gpu/drm
Am 05.12.22 um 09:47 schrieb Shikang Fan:
- There is no need to evict resources from vram to sram for sriov
because GPU is still powered on. And evicet is taking too much time
that would cause full access mode timedout in multi-vf mode.
Well big NAK to this!
The suspend is usually done t
Bas pointed out that this isn't working as expected and could cause
crashes. Fix the handling by storing the marker that a switch is needed
inside the job instead.
Reported-by: Bas Nieuwenhuizen
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 42 +++
Instead of reserving a VMID for a single process allow that many
processes use the reserved ID. This allows for proper isolation
between the processes.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 45 -
drivers/gpu/drm/amd/amdgpu/amdgpu_ids
This is completely pointless since the VMID always stays allocated until
the VM is idle.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/am
This should probably not access job->vm and also emit the SPM switch
under the conditional execute.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_job.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 9 +
3 files chan
Am 29.11.22 um 22:14 schrieb Felix Kuehling:
On 2022-11-25 05:21, Christian König wrote:
Instead of a single worker going over the list of delete BOs in regular
intervals use a per BO worker which blocks for the resv object and
locking of the BO.
This not only simplifies the handling massively,
Am 25.11.22 um 19:18 schrieb Alex Deucher:
On Fri, Nov 25, 2022 at 5:21 AM Christian König
wrote:
We already fallback to a dummy BO with no backing store when we
allocate GDS,GWS and OA resources and to GTT when we allocate VRAM.
Drop all those workarounds and generalize this for GTT as well.
Series is:
Reviewed-by: Alex Deucher
On Mon, Dec 5, 2022 at 4:43 AM Tim Huang wrote:
>
> Add tmz support for GC 11.0.4.
>
> Signed-off-by: Tim Huang
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
hi DRM-folks,
DRM_USE_DYNAMIC_DEBUG has regression, mark as BROKEN for now.
Also correct a comment.
Jim Cromie (2):
drm: mark CONFIG_DRM_USE_DYNAMIC_DEBUG as BROKEN for now
drm_print: fix stale macro-name in comment
drivers/gpu/drm/Kconfig | 3 ++-
include/drm/drm_print.h | 5 -
2 files
Cited commit uses stale macro name, fix this, and explain better.
When DRM_USE_DYNAMIC_DEBUG=y, DYNDBG_CLASSMAP_DEFINE() maps DRM_UT_*
onto BITs in drm.debug. This still uses enum drm_debug_category, but
it is somewhat indirect, with the ordered set of DRM_UT_* enum-vals.
This requires that the m
CONFIG_DRM_USE_DYNAMIC_DEBUG=y has a regression, due to a chicken-egg
initialization problem:
1- modprobe i915
i915 needs drm.ko, which is loaded 1st
2- "modprobe drm drm.debug=0x1ff" (virtual/implied)
drm.debug is set post-initialization, from boot-args etc
3- `modprobe i915` finishes
W/
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: ee9bda616d36d2dc864aa294c2656fad88c9efa0 Add linux-next specific
files for 20221205
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202211242120.mzzvguln-...@intel.com
https
Am 30.11.22 um 15:06 schrieb Daniel Vetter:
On Wed, 30 Nov 2022 at 14:03, Tvrtko Ursulin
wrote:
On 29/11/2022 18:05, Matthew Auld wrote:
On Fri, 25 Nov 2022 at 11:14, Tvrtko Ursulin
wrote:
+ Matt
On 25/11/2022 10:21, Christian König wrote:
TTM is just wrapping core DMA functionality here,
[AMD Official Use Only - General]
I agree with Christian . Although on some hypervisior with live migration
support , there will be specific API between OS and PF driver to handle the
FB content save/restore for VF, in this case , guest side save/restore is not
necessary. On other hyperv
[Why&How]
LinkCapacitySupport array is indexed with the number of voltage states and
not the number of max DPPs. Fix the error by changing the array
declaration to use the correct (larger) array size of total number of
voltage states.
Signed-off-by: Aurabindo Pillai
---
drivers/gpu/drm/amd/displ
On 12/5/22 16:08, Aurabindo Pillai wrote:
[Why&How]
LinkCapacitySupport array is indexed with the number of voltage states and
not the number of max DPPs. Fix the error by changing the array
declaration to use the correct (larger) array size of total number of
voltage states.
Signed-off-by: A
fix MMHUB register base coding error.
Fixes: ec6837591f992 ("drm/amdgpu/gmc10: program the smallK fragment size")
Signed-off-by: Yang Wang
Reviewed-by: Hawking Zhang
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/mmhub_v2_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c |
We fixed a similar issue with Philip's patch "drm/amdgpu: Drop eviction
lock when allocating PT BO", but there was another one hiding underneath
that (see the log below). The problem is, that we're still allocating
page tables while holding the prange->lock in the kfd_svm code, which is
also he
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
Hi everyone,
DRM_USE_DYNAMIC_DEBUG=y has a regression on rc-*
Regression is due to a chicken-egg problem loading modules; on
`modprobe i915`, drm is loaded 1st, and drm.debug is set. When
drm_debug_enabled() tested __drm_debug at runtime, that just worked.
But with DRM_USE_DYNAMIC_DEBUG=y, the
Dyndbg is required to enable prdbgs at compile-time if DEBUG is
defined. Show this works; add the defn to test_dynamic_debug.c,
and manually inspect/verify its effect at module load:
[ 15.292810] dyndbg: module:test_dynamic_debug attached 4 classes
[ 15.293189] dyndbg: 32 debug prints in mod
Since sysfs knobs should generally read-back what was just written
(unless theres a good reason to do otherwise), this result (using
test_dynamic_debug.ko) is suboptimal:
echo L3 > p_level_names
cat p_level_names
4
Fix this with a -1 offset in LEVEL_NAMES readback.
NOTE:
Calling this a BU
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
ddebug_apply_class_bitmap() currently applies the class settings to
all modules, make it more selective, by adding query_module param.
The fn now calls ddebug_exec_queries(query, NULL), where NULL is
query_modname wildcard ("*" does the same). So just expose the
parameter, and alter users to expl
ARRAY_SIZE works here, since array decl is complete.
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 bf47bcfad8e6..81b643ab7f6e 100644
--- a/incl
currently, for verbose=3, this is logged:
[ 3832.333424] dyndbg: parsed: func="" file="" module="amdgpu" format=""
lineno=0-0 class=DRM_UT_PRIME
[ 3832.333888] dyndbg: no matches for query
[ 3832.334093] dyndbg: no-match: func="" file="" module="amdgpu" format=""
lineno=0-0 class=DRM_UT_PRIME
[
dynamic_debug_init() currently uses strcmp to find the module
boundaries in the builtin _ddebug[] table.
The table is filled by the linker; for its content, pointer inequality
works, is faster, and communicates the data properties more tightly.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c
The inner func has a base arg which is unused in the body, so theres
no point in having the inner fn. Its one-time purpose was subsumed
into the ddebug_info record, which is used in dynamic_debug_init() as
a cursor to load the builtin _ddebug[] table.
TODO: cited commit gives another reason for b
DECLARE_DYNDBG_CLASSMAPs job was to allow modules to declare the debug
classes/categories they want dyndbg to >control on their behalf. Its
args give the class-names, their mapping to class_ids, and the sysfs
interface style (usually a class-bitmap). Modules wanting a drm.debug
style knob need to
Drop macro args after _var. Since DYNDBG_CLASSMAP_USE no longer
forwards to DYNDBG_CLASSMAP_DEFINE, it doesn't need those args to
forward. Keep only the _var arg, which is the extern'd struct
classmap with all the class info.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.
Now that the DECLARE_DYNDBG_CLASSMAP macro has been split into
DYNDBG_CLASSMAP_DEFINE and DYNDBG_CLASSMAP_USE variants, lets
differentiate them according to their separate jobs.
Dyndbg's existing __dyndbg_classes[] section does:
. catalogs the classmaps defined by the module (or builtin modules)
It appears that, at least for builtin drm,i915 loadable amdgpu, data
in the class_refs section is not properly linked, this works partway
towards isolating the problem.
The "NO CLI" name test is failing.
This version of the report fails with a non-canonical address:
// v2pr_info("NO CLI name on:
Cited commit uses stale macro name, fix this, and explain better.
When DRM_USE_DYNAMIC_DEBUG=y, DYNDBG_CLASSMAP_DEFINE() maps DRM_UT_*
onto BITs in drm.debug. This still uses enum drm_debug_category, but
it is somewhat indirect, with the ordered set of DRM_UT_* enum-vals.
This requires that the m
patch 1 in this series fixed a CLASSMAP usage error, this improves the
api so that misuse is less likely.
changes here:
0- Add William Swanson's public domain map macro:
https://github.com/swansontec/map-macro/blob/master/map.h
this makes 1 possible.
1- classnames were formerly specified a
for loadable drm, helpers, and drivers, dependent-load is failing to
apply changes, needs more investigation.
---
lib/dynamic_debug.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 46684aa7284d..3ef1c0a1f0cd 100644
--- a/
dont break the loop, to see multiple clients. the 3 client records
are differently wrong.
---
lib/dynamic_debug.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 3ef1c0a1f0cd..a26eaa348731 100644
--- a/lib/dynamic_debug.c
++
Add a per-process MMU notifier lock for processing notifiers from
userptrs. Use that lock to properly synchronize page table updates with
MMU notifiers.
v2: rebased
Signed-off-by: Felix Kuehling
Reviewed-by: Xiaogang Chen (v1)
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 13 +-
.../gpu/
[AMD Official Use Only - General]
Hi Shaoyun and Christian,
Thank you for your comments! We indeed did not consider the live migration case
when we tried to fix this and we shall come up with other methods for our issue.
Best regards,
Shikang.
-Original Message-
From: Liu, Shaoyun
S
44 matches
Mail list logo
