On 2022/1/7 上午11:57, JingWen Chen wrote:
> On 2022/1/7 上午3:13, Andrey Grodzovsky wrote:
>> On 2022-01-06 12:18 a.m., JingWen Chen wrote:
>>> On 2022/1/6 下午12:59, JingWen Chen wrote:
On 2022/1/6 上午2:24, Andrey Grodzovsky wrote:
> On 2022-01-05 2:59 a.m., Christian König wrote:
>> Am
if CONFIG_DRM_USE_DYNDBG=y, use new macro to create the sysfs bitmap
to control drm.debug callsites.
DEFINE_DYNAMIC_DEBUG_CLASSBITS( debug, __drm_debug,
"drm.debug - control summary",
/* inline vector of dyndbg.class_id (uint:4, 0 is reserved) */
DRM_UT_CORE,
Change __drm_dbg() macro to be CONFIG_DRM_USE_DYNAMIC_DEBUG dependent:
N- keep straight mapping to exported ___drm_dbg()
Y- wrap ___drm_dbg() inside _dynamic_func_call_no_desc()
This patch places ~1/2 of drm.debug API messages behind dyndbg's
JUMP_LABEL/NOOP optimization.
The
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
A recent commit adding trace-events to drm noted:
trace_*() additions are strictly redundant with printks to syslog,
not properly placed to reduce overall work.
That was because it didn't have the struct _ddebug *descriptor, whose
.flags specify TRACE and PRINTK actions on a controlled
DEFINE_DYNAMIC_DEBUG_CLASSBITS(fsname, var, bitmap_desc, classes..)
allows users to create a drm.debug style (bitmap) sysfs interface, to
control sets of pr_debug's according to their .class_id's
1st, due to a recent commit, this already works:
echo "module drm class 1 +p ; module drm class 3
Replace trace-drm-*()s category param with struct _ddebug *desc; it
has .classid field, which is the category.
This brings the events closer in line with those added for dyndbg; at
least the 1st param, and possibly the struct device (tb-checked).
There are still differences in the tail of the
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.
Upgrade the current use of _dynamic_func_call_no_desc(), adding the
suffix and the category arg. The arg has been available via the
macros implementing the drm.debug api, but dyndbg lacked a simple way
to represent it and use it until recently.
Signed-off-by: Jim Cromie
---
make drm_dev_dbg() macro CONFIG_DRM_USE_DYNAMIC_DEBUG dependent:
=N direct forwarding: drm_dev_dbg -> __drm_dev_dbg()
=Y wrap __drm_dev_dbg in _dynamic_func_call_no_desc().
This adds the metadata which creates a /proc/dynamic_debug/control
entry for each callsite, and exposes it for
__drm_debug() and __drm_dev_dbg() currently printk to syslog. These 2
underlay the vast bulk of DRM.debug api calls; they are a significant
source of debugging info, and could add useful context to debug traces.
Wire them to emit 2 new trace_*() events: drm_prdbg and drm_devdbg.
These events
drm_dev_dbg() & _drm_dbg() sit below the categorized layer of the DRM
debug API, and thus implement most of it. These are good places to
insert dynamic-debug jump-label mechanics, allowing DRM to avoid the
runtime cost of drm_debug_enabled().
Set up for this by changing the func names by adding
DRM.debug API is used thousands of times in drivers/gpu/drm/*; when
these are implemented using dynamic-debug, DYNAMIC_DEBUG_METADATA adds
a struct _ddebug (56 bytes) per site.
Since i915 will have ~2k callsites, and amdgpu ~4k, the memory costs
are substantial, and thus made configurable.
For a
enum drm_debug_category has 10 hardcoded values, which could be
"simplified" as sequential BIT(x)s. But lets take it one step
further, removing the explicit initializations (other than starting at
1), and move the BIT() operation into drm_debug_enabled().
This gives us a more compact
commit:HEAD~1 added pr_debug(), dev_dbg() params to the new events,
but didn't actually capture the params. Do that now; add the other
TP_* parts: __fields, fast-assign, and printk elements for the
desccriptor and device params.
The message capture part is copied from printk:console, it gets the
DRM defines/uses a 10 enum drm_debug_category to create exclusive
classes of debug messages. To support this directly in dynamic-debug,
add the following:
- struct _ddebug.class_id 4 bits is enough for drm_debug_category
and the query support:
- struct _ddebug_query.class_id
-
In commit HEAD~1, pr_debug temporarily issued a printk:console event.
Replace that use with 2 new events:
bash-5.1# ls events/dyndbg/
devdbg enable filter prdbg
..called from pr_debug(), dev_dbg() respectively for dyndbg builds.
This links the old pr_debug API to tracefs, via dyndbg,
adds: dynamic_trace()
uses trace_console() temporarily to issue printk:console event
uses internal-ish __ftrace_trace_stack code:
4-context buffer stack, barriers per Steve
call it from new funcs:
dynamic_printk() - print to both syslog/tracefs
dynamic_dev_printk() - dev-print to both
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
Distinguish the condition: _DPRINTK_FLAGS_ENABLED from the bit:
_DPRINTK_FLAGS_PRINT, in preparation to add _DPRINTK_FLAGS_TRACE next.
Also add a 'K' to get _DPRINTK_FLAGS_PRINTK, to insure is not used
elsewhere with a stale meaning.
CC: vincent.whitchu...@axis.com
Signed-off-by: Jim Cromie
---
hi Jason, Steve, Greg, DRM-folks,
This patchset plumbs debug streams, from dynamic-debug, and from
drm.debug, into tracefs. Enabling traffic is done on both source &
destination:
# enable at source
echo module usbcore +T > /proc/dynamic_debug/control
# enable events into
On 2022/1/7 上午3:13, Andrey Grodzovsky wrote:
>
> On 2022-01-06 12:18 a.m., JingWen Chen wrote:
>> On 2022/1/6 下午12:59, JingWen Chen wrote:
>>> On 2022/1/6 上午2:24, Andrey Grodzovsky wrote:
On 2022-01-05 2:59 a.m., Christian König wrote:
> Am 05.01.22 um 08:34 schrieb JingWen Chen:
>>
[Public]
> -Original Message-
> From: Chen, Guchun
> Sent: Thursday, January 6, 2022 9:22 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Quan, Evan
>
> Subject: RE: [PATCH 2/7] drm/amd/pm: drop unneeded vcn/jpeg_gate_lock
>
> [Public]
>
> err0_out:
>
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Thursday, January 6, 2022 4:29 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: Re: [PATCH 3/7] drm/amd/pm: drop unneeded smu->metrics_lock
>
>
>
> On 1/6/2022 12:32 PM,
[Public]
Reviewed-by: Guchun Chen
Next I will figure out which navy flounder boards have the bad harvest table
info from VBIOS, and add a quirk to enable this workaround.
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Deucher,
Alexander
Sent: Friday, January 7, 2022
Acked-by: Alex Deucher
On Thu, Jan 6, 2022 at 8:40 AM Mario Limonciello
wrote:
>
> When UBSAN is enabled a case is shown on unplugging the display that
> this variable hasn't been initialized by `update_dsc_caps`, presumably
> when the display was unplugged it wasn't copied from the DPCD.
>
>
On Thu, Jan 6, 2022 at 10:38 AM Yann Dirson wrote:
>
> Alex wrote:
> > > How is the stolen memory communicated to the driver ? That host
> > > physical
> > > memory probably has to be mapped at the same guest physical address
> > > for
> > > the magic to work, right ?
> >
> > Correct. The
> -Original Message-
> From: amd-gfx On Behalf Of Matthew
> Auld
> Sent: Tuesday, January 4, 2022 7:32 PM
> To: Paneer Selvam, Arunpravin ;
> dri-de...@lists.freedesktop.org; intel-...@lists.freedesktop.org;
> amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ;
On 2022-01-06 12:18 a.m., JingWen Chen wrote:
On 2022/1/6 下午12:59, JingWen Chen wrote:
On 2022/1/6 上午2:24, Andrey Grodzovsky wrote:
On 2022-01-05 2:59 a.m., Christian König wrote:
Am 05.01.22 um 08:34 schrieb JingWen Chen:
On 2022/1/5 上午12:56, Andrey Grodzovsky wrote:
On 2022-01-04 6:36
Got it
See bellow one small comment, with that the patch is Reviewed-by: Andrey
Grodzovsky
On 2022-01-05 9:24 p.m., Shi, Leslie wrote:
[AMD Official Use Only]
Hi Andrey,
It is the following patch calls to amdgpu_device_unmap_mmio() conditioned on
device unplugged.
3efb17ae7e92
On 04/01/22 7:41 pm, Matthew Auld wrote:
> On 26/12/2021 22:24, Arunpravin wrote:
>> On contiguous allocation, we round up the size
>> to the *next* power of 2, implement a function
>> to free the unused pages after the newly allocate block.
>>
>> v2(Matthew Auld):
>>- replace function name
[Public]
> -Original Message-
> From: amd-gfx On Behalf Of
> Peng Ju Zhou
> Sent: Thursday, January 6, 2022 2:30 AM
> To: amd-gfx@lists.freedesktop.org
> Subject: [PATCH v2] drm/amdgpu: Enable second VCN for certain Navy
> Flounder.
>
> Certain Navy Flounder cards have 2 VCNs, enable
Am 2022-01-06 um 4:05 a.m. schrieb Christian König:
> Am 05.01.22 um 17:16 schrieb Felix Kuehling:
>> [SNIP]
But KFD doesn't know anything about the inherited BOs
from the parent process.
>>> Ok, why that? When the KFD is reinitializing it's context why
>>> shouldn't it cleanup those
Am 2022-01-06 um 11:48 a.m. schrieb Christian König:
> Am 06.01.22 um 17:45 schrieb Felix Kuehling:
>> Am 2022-01-06 um 4:05 a.m. schrieb Christian König:
>>> Am 05.01.22 um 17:16 schrieb Felix Kuehling:
[SNIP]
>> But KFD doesn't know anything about the inherited BOs
>> from the
Am 06.01.22 um 17:45 schrieb Felix Kuehling:
Am 2022-01-06 um 4:05 a.m. schrieb Christian König:
Am 05.01.22 um 17:16 schrieb Felix Kuehling:
[SNIP]
But KFD doesn't know anything about the inherited BOs
from the parent process.
Ok, why that? When the KFD is reinitializing it's context why
The WA from commit 5965280abd30 ("drm/amd/display: Apply w/a for
hard hang on HPD") causes a regression in s0ix where the system will
fail to resume properly. This may be because an HPD was active the last
time clocks were updated but clocks didn't get updated again during s0ix.
So add an extra
This will make it cleaner to read through the logic for an upcoming change.
Signed-off-by: Mario Limonciello
---
Changes from v3->v4:
* New patch
.../amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c | 30 +++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git
This can be used by the display core to let decisions be made based
upon the requested power state.
Cc: Qingqing Zhuo
Cc: Scott Bruce
Cc: Chris Hixon
Cc: spassw...@web.de
Signed-off-by: Mario Limonciello
---
changes from v3->v4:
* Initialize power_state when context is created (0 shouldn't
Alex wrote:
> > How is the stolen memory communicated to the driver ? That host
> > physical
> > memory probably has to be mapped at the same guest physical address
> > for
> > the magic to work, right ?
>
> Correct. The driver reads the physical location of that memory from
> hardware
[Public]
> -Original Message-
> From: amd-gfx On Behalf Of
> Harry Wentland
> Sent: Wednesday, January 5, 2022 3:39 PM
> To: amd-gfx@lists.freedesktop.org; Koenig, Christian
> ; Lee, Becle ; Huang,
> Rex ; Huang, Ray
> Cc: Wentland, Harry
> Subject: [PATCH] drm/amdgpu: Use correct
[Public]
> -Original Message-
> From: Thorsten Leemhuis
> Sent: Thursday, January 6, 2022 05:39
> To: Limonciello, Mario ; amd-
> g...@lists.freedesktop.org
> Cc: Zhuo, Qingqing (Lillian) ; Scott Bruce
> ; Chris Hixon ;
> spassw...@web.de
> Subject: Re: [PATCH v2] drm/amd/display:
When UBSAN is enabled a case is shown on unplugging the display that
this variable hasn't been initialized by `update_dsc_caps`, presumably
when the display was unplugged it wasn't copied from the DPCD.
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1956497
Signed-off-by: Mario
[Public]
err0_out:
- mutex_unlock(_gate->jpeg_gate_lock);
- mutex_unlock(_gate->vcn_gate_lock);
-
return ret;
Is it better to refactor the code to drop error path of "err0_out"?
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Evan Quan
Sent: Thursday,
This largely reverts commit 5a7b95fb993ec399c8a685552aa6a8fc995c40bd. It
breaks suspend with AMD GPUs, and we couldn't incrementally fix it. So,
let's remove the code and go back to the drawing board. We keep the
header extension to not break drivers already populating the regulator.
We expect to
Hi
Am 03.01.22 um 08:41 schrieb Christian König:
Am 26.12.21 um 21:59 schrieb Arunpravin:
Hi Thomas
On 16/12/21 5:05 pm, Thomas Zimmermann wrote:
Hi
Am 01.12.21 um 17:39 schrieb Arunpravin:
- Make drm_buddy_alloc a single function to handle
range allocation and non-range allocation
[AMD Official Use Only]
Via ras_ctrl sys node one uncorrectable error injection on Sienna Cichlid, two
interrupts will be triggered.
I was informed the two interrupts are as expected since when error address is
not 64byte aligned, one 64Byte SDP request will be split to two 32Byte request
in
[AMD Official Use Only]
Reviewed-by: Tao Zhou
May I know how do you reproduce the issue?
> -Original Message-
> From: amd-gfx On Behalf Of Jiawei
> Gu
> Sent: Thursday, January 6, 2022 5:17 PM
> To: amd-gfx@lists.freedesktop.org; Clements, John
> ; Yang, Stanley ; Deng,
> Emily
> Cc:
Hi
Am 27.12.21 um 19:25 schrieb Alex Deucher:
Add a function for drivers to check if the a firmware initialized
fb is corresponds to their aperture. This allows drivers to check if the
device corresponds to what the firmware set up as the display device.
If simpledrm is in use, it will
> Should I send a revert, or is there a way to fix this?
You are the second one to report this problem and so far, there has been
no response from the authors. I will prepare a revert and CC all
involved people. Thank you for the nagging!
signature.asc
Description: PGP signature
Am 05.01.22 um 21:39 schrieb Harry Wentland:
For some reason this file isn't using the appropriate register
headers for DCN headers, which means that on DCN2 we're getting
the VIEWPORT_DIMENSION offset wrong.
This means that we're not correctly carving out the framebuffer
memory correctly for a
Memory of err_data should be cleaned before usage
when there're multiple entry in ras ih.
Otherwise garbage data from last loop will be used.
Signed-off-by: Jiawei Gu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Am 06.01.22 um 06:18 schrieb JingWen Chen:
On 2022/1/6 下午12:59, JingWen Chen wrote:
On 2022/1/6 上午2:24, Andrey Grodzovsky wrote:
On 2022-01-05 2:59 a.m., Christian König wrote:
Am 05.01.22 um 08:34 schrieb JingWen Chen:
On 2022/1/5 上午12:56, Andrey Grodzovsky wrote:
On 2022-01-04 6:36 a.m.,
Am 05.01.22 um 17:16 schrieb Felix Kuehling:
[SNIP]
But KFD doesn't know anything about the inherited BOs
from the parent process.
Ok, why that? When the KFD is reinitializing it's context why
shouldn't it cleanup those VMAs?
That cleanup has to be initiated by user mode. Basically closing
On 1/6/2022 12:32 PM, Quan, Evan wrote:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Thursday, January 6, 2022 2:17 PM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 3/7] drm/amd/pm: drop unneeded smu->metrics_lock
As the possible failure of the allocation, kmemdup() may return NULL
pointer.
Therefore, it should be better to check the 'props2' in order to prevent
the dereference of NULL pointer.
Fixes: 3a87177eb141 ("drm/amdkfd: Add topology support for dGPUs")
Signed-off-by: Jiasheng Jiang
---
Btw, please keep me on CC as I am not subscribed to the lists
On Thu, 2022-01-06 at 00:26 +0300, Konstantin Kharlamov wrote:
> Hello! Just a heads up to this report
> https://gitlab.freedesktop.org/drm/amd/-/issues/1850
>
> Basically, after waking up on suspend there're freezes in apps using
Hello! Just a heads up to this report
https://gitlab.freedesktop.org/drm/amd/-/issues/1850
Basically, after waking up on suspend there're freezes in apps using amdgpu,
and there's a spam in syslog `Fence fallback timer expired on ring …`.
I bisected that to a commit
57 matches
Mail list logo
