On 2021-11-05 1:59 p.m., Liu, Shaoyun wrote:
[AMD Official Use Only]
Ye, a lot already been changed since then , now the pre_reset and post_reset
not in the lock/unlock anymore. With my previous change , we make
kfd_pre_reset avoid touch HW . Now it's pure SW handling , should be safe
On 2021-11-05 3:25 p.m., Alex Sierra wrote:
The low 16MB of virtual address space are currently reserved for kernel
mode allocations mapped into user virtual address space. This causes
conflicts with HMM/SVM mappings at low virtual addresses. We tried to
move those kernel mode allocations to the
On 2021-11-05 2:43 p.m., Graham Sider wrote:
These get funcs simply return an adev field. Replace funcs/calls with
direct field accesses instead.
Signed-off-by: Graham Sider
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 30 ---
drivers/
[Public]
Hi all,
This week this patchset was tested on the following systems:
HP Envy 360, with Ryzen 5 4500U, with the following display types: eDP 1080p
60hz, 4k 60hz (via USB-C to DP/HDMI), 1440p 144hz (via USB-C to DP/HDMI),
1680*1050 60hz (via USB-C to DP and then DP to DVI/VGA)
AMD
Switch to IP version checking instead of asic_type on various KFD
version checks.
Signed-off-by: Graham Sider
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 4 ++--
drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 24 ++-
Patches to change KFD to use IP versions rather than asic_type.
Converting IP version checking in main switch statements.
Signed-off-by: Graham Sider
---
drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 124 +-
.../drm/amd/amdkfd/kfd_device_queue_manager.c | 56
drivers/
Sean Paul proposed, in:
https://patchwork.freedesktop.org/series/78133/
drm/trace: Mirror DRM debug logs to tracefs
His patchset's objective is to be able to independently steer some of
the drm.debug stream to an alternate tracing destination, by splitting
drm_debug_enabled() into syslog & trace f
drm's debug system writes 10 distinct categories of messages to syslog
using a small API[1]: drm_dbg*(10 names), DRM_DEV_DEBUG*(3 names),
DRM_DEBUG*(8 names). There are thousands of these callsites, each
categorized in this systematized way.
These callsites can be enabled at runtime by their cate
add sysfs knobs to enable modules' pr_debug()s ---> tracefs
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/amd/display/dc/core/dc_debug.c | 8
drivers/gpu/drm/drm_print.c| 13 ++---
drivers/gpu/drm/i915/intel_gvt.c | 15 ---
3 files
With the recent addition of pr_debug to tracefs via +T flag, we now
want to add drm.trace; like its model: drm.debug, it maps bits to
pr_debug categories, but this one enables/disables writing to tracefs
(iff CONFIG_TRACING).
Do this by:
1. add flags to dyndbg_bitmap_param, holds "p" or "T" to wo
Duplicate drm_debug_enabled() code into both "basic" and "dyndbg"
ifdef branches. Then add a pr_debug("todo: ...") into the "dyndbg"
branch.
Then convert the "dyndbg" branch's code to a macro, so that the
pr_debug() get its callsite info from the invoking function, instead
of from drm_debug_enabl
Taking embedded spaces out of existing prefixes makes them more easily
searchable; simplifying the extra quoting needed otherwise:
$> echo format "^gvt: core:" +p >control
Dropping the internal spaces means any trailing space in a query will
more clearly terminate the prefix being searched for.
The gvt component of this driver has ~120 pr_debugs with formats using
one of 9 fixed string prefixes, which are quite similar to those
enumerated in DRM debug categories. Following the interface model of
drm.debug, add a parameter to map bits to these format prefixes.
static struct dyndbg_bitdes
allocates and initializes ...
Signed-off-by: Jim Cromie
---
include/drm/drm_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 0cd95953cdf5..4b29261c4537 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -
logger_types.h defines many DC_LOG_*() categorized debug wrappers.
Most of these already use DRM debug API, so are controllable using
drm.debug, but others use a bare pr_debug("$prefix: .."), with 1 of 13
different class-prefixes matching [:uppercase:]
Use DEFINE_DYNAMIC_DEBUG_BITGRPS to create a
DEFINE_DYNAMIC_DEBUG_BITGRPS(fsname, var, bitmap_desc, bitmap)
allows users to create a drm.debug style (bitmap) sysfs interface,
mapping each bit to a group of pr_debugs, matching on their formats.
This works well when the formats systematically include a prefix
string such as ERR|WARN|INFO, etc.
Hi Jason, Greg, DRM-everyone,
This patchset has 3 separate but related parts:
1. DEFINE_DYNAMIC_DEBUG_BITGRPS [patch 1/10]
Declares DRM.debug style bitmap, bits control pr_debugs by matching formats
Adds callback to translate bits to $cmd > dynamic_debug/control
This could obsolete EXPO
The low 16MB of virtual address space are currently reserved for kernel
mode allocations mapped into user virtual address space. This causes
conflicts with HMM/SVM mappings at low virtual addresses. We tried to
move those kernel mode allocations to the upper half of the 64-bit
virtual address space
These get funcs simply return an adev field. Replace funcs/calls with
direct field accesses instead.
Signed-off-by: Graham Sider
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 30 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 6
drivers/gpu/drm/amd/amdkfd/kfd_cha
[AMD Official Use Only]
Ye, a lot already been changed since then , now the pre_reset and post_reset
not in the lock/unlock anymore. With my previous change , we make
kfd_pre_reset avoid touch HW . Now it's pure SW handling , should be safe to
be moved out of the full access .
Anyway,
There was a reason why pre_reset was done differently on SRIOV. However,
the code has changed a lot since then. Is this concern still valid?
commit 7b184b006185215daf4e911f8de212964c99a514
Author: wentalou
Date: Fri Dec 7 13:53:18 2018 +0800
drm/amdgpu: kfd_pre_reset outside req_full_gp
The KFD pre_reset should be called before reset been executed, it will
hold the lock to prevent other rocm process to sent the packlage to hiq
during host execute the real reset on the HW
Signed-off-by: shaoyunl
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 +
1 file changed, 1 insertio
On 11/5/2021 3:17 PM, Alex Deucher wrote:
On Fri, Nov 5, 2021 at 10:09 AM Nirmoy Das wrote:
There is a HW bug which prevents CP to read secure buffers
with HIQ being configured and mapped using KIQ. KFD already
does this for amdgpu but when kfd is not enabled amdgpu
should that for itself.
C
Am 2021-11-04 um 12:53 p.m. schrieb shaoyunl:
> When kfd need to be reset, sent command to HWS might cause hang and get
> unnecessary timeout.
> This change try not to touch HW in pre_reset and keep queues to be in the
> evicted state
> when the reset is done, so they are not put back on the ru
On Fri, Nov 5, 2021 at 10:09 AM Nirmoy Das wrote:
>
> There is a HW bug which prevents CP to read secure buffers
> with HIQ being configured and mapped using KIQ. KFD already
> does this for amdgpu but when kfd is not enabled amdgpu
> should that for itself.
Can we just move the HIQ init/fini int
Allow KIQ to map/unmap HIQ MQD as well.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 14 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 2 ++
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 4 ++--
4 files change
There is a HW bug which prevents CP to read secure buffers
with HIQ being configured and mapped using KIQ. KFD already
does this for amdgpu but when kfd is not enabled amdgpu
should that for itself.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 14 -
drivers/gpu/drm
Add HIQ ring structs and functions that will map HIQ
using KIQ.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 142 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 24
drivers/gpu/drm/amd
On Fri, Nov 05, 2021 at 08:05:41AM +, Quan, Evan wrote:
> I'm wondering are you able to give the attached patch(alone) a try.
Yap, looks good.
Tested-by: Borislav Petkov
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 11/5/21 11:04, Jani Nikula wrote:
> On Fri, 05 Nov 2021, Javier Martinez Canillas wrote:
[snip]
>>
>> Do you envision other condition that could be added later to disable a
>> DRM driver ? Or do you think that just from a code readability point of
>> view makes worth it ?
>
> Taking a step b
On 11/5/21 10:39, Thomas Zimmermann wrote:
[snip]
+obj-$(CONFIG_VGA_CONSOLE) += drm_nomodeset.o
+
>>>
>>> This now depends on the VGA textmode console. Even if you have no VGA
>>> console, you'd want drm_nomodeset.o. Simpledrm might be built-in and can
>>> provide graphics. Non
Hello Thomas,
On 11/5/21 09:43, Thomas Zimmermann wrote:
> Hi
>
> Am 04.11.21 um 21:09 schrieb Javier Martinez Canillas:
>> Hello Jani,
>>
>> On 11/4/21 20:57, Jani Nikula wrote:
>>> On Thu, 04 Nov 2021, Javier Martinez Canillas wrote:
+/**
+ * drm_drv_enabled - Checks if a DRM driver
On 11/5/21 10:00, Thomas Zimmermann wrote:
[snip]
>> +
>> +static int __init disable_modeset(char *str)
>> +{
>> +drm_nomodeset = true;
>> +
>> +pr_warn("You have booted with nomodeset. This means your GPU drivers
>> are DISABLED\n");
>> +pr_warn("Any video related functionality will
Hi
Am 05.11.21 um 13:00 schrieb Javier Martinez Canillas:
On 11/5/21 11:04, Jani Nikula wrote:
On Fri, 05 Nov 2021, Javier Martinez Canillas wrote:
[snip]
Do you envision other condition that could be added later to disable a
DRM driver ? Or do you think that just from a code readability
[Public]
Acked-by: Guchun Chen
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Asher Song
Sent: Friday, November 5, 2021 5:41 PM
To: amd-gfx@lists.freedesktop.org
Cc: Song, Asher
Subject: [PATCH] drm/amdgpu: assign dpms for amdgpu_vkms_crtc_helper_funcs
In drm_helper_di
Hi
Am 05.11.21 um 10:48 schrieb Javier Martinez Canillas:
Hello Thomas,
On 11/5/21 09:43, Thomas Zimmermann wrote:
Hi
Am 04.11.21 um 21:09 schrieb Javier Martinez Canillas:
Hello Jani,
On 11/4/21 20:57, Jani Nikula wrote:
On Thu, 04 Nov 2021, Javier Martinez Canillas wrote:
+/**
+ * drm_
On Fri, 05 Nov 2021, Javier Martinez Canillas wrote:
> Hello Thomas,
>
> On 11/5/21 09:43, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 04.11.21 um 21:09 schrieb Javier Martinez Canillas:
>>> Hello Jani,
>>>
>>> On 11/4/21 20:57, Jani Nikula wrote:
On Thu, 04 Nov 2021, Javier Martinez Canillas w
In drm_helper_disable_unused_functions(), when !crtc->enable is false, a NULL
pointer crtc_funcs->dpms may occur. To avoid this, assign dpms for
amdgpu_vkms_crtc_helper_funcs.
Call Trace:
__drm_helper_disable_unused_functions+0xac/0xe0 [drm_kms_helper]
drm_helper_disable_unused_functions+0x
Hi
Am 05.11.21 um 10:22 schrieb Jani Nikula:
On Fri, 05 Nov 2021, Thomas Zimmermann wrote:
Hi
Am 04.11.21 um 17:07 schrieb Javier Martinez Canillas:
The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
but the exported vgacon_text_force() symbol is only used by DRM driver
On Fri, 05 Nov 2021, Thomas Zimmermann wrote:
> Hi
>
> Am 04.11.21 um 17:07 schrieb Javier Martinez Canillas:
>> The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
>> but the exported vgacon_text_force() symbol is only used by DRM drivers.
>>
>> It makes much more sense for
Hi
Am 04.11.21 um 17:07 schrieb Javier Martinez Canillas:
The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
but the exported vgacon_text_force() symbol is only used by DRM drivers.
It makes much more sense for the parameter logic to be in the subsystem
of the drivers that
Hi
Am 04.11.21 um 21:09 schrieb Javier Martinez Canillas:
Hello Jani,
On 11/4/21 20:57, Jani Nikula wrote:
On Thu, 04 Nov 2021, Javier Martinez Canillas wrote:
+/**
+ * drm_drv_enabled - Checks if a DRM driver can be enabled
+ * @driver: DRM driver to check
+ *
+ * Checks whether a DRM drive
I found the following warning in my log this evening. I don’t know if or how
it can be reproduced.
Linux 5.10.77 amd64. Kernel config attached. (The kernel taint is merely
because of the struct randomization plugin.)
zzy
..
kernel: [ cut here ]
kernel: refcount_t: a
Another use-after-free on the same computer that looks like it’s in amdgpu:
[ 2101.168138] [ cut here ]
[ 2101.168144] refcount_t: underflow; use-after-free.
[ 2101.168162] WARNING: CPU: 4 PID: 965 at lib/refcount.c:28
refcount_warn_saturate+0xa6/0xf0
[ 2101.168167] CPU: 4
[AMD Official Use Only]
> -Original Message-
> From: amd-gfx On Behalf Of
> James Zhu
> Sent: Friday, November 5, 2021 10:03 AM
> To: amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amdgpu: fix the Carrizo UVD hang on system
> reboot
>
>
> On 2021-11-04 4:19 a.m., Evan Quan w
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Thursday, November 4, 2021 4:55 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: Re: [PATCH] drm/amdgpu: fix the Carrizo UVD hang on system
> reboot
>
>
>
> On 11/4/2021 1
Am 05.11.21 um 00:05 schrieb Felix Kuehling:
If a kfd_bo was shared (e.g. a dmabuf export), the original kfd_bo may be
freed when the amdgpu_bo still lives on. Free the kfd_bo struct in the
release_notify callback then the amdgpu_bo is freed.
Signed-off-by: Felix Kuehling
Reviewed-by: Christi
47 matches
Mail list logo
