This patchset does 3 main things.
Adds DEFINE_DYNAMIC_DEBUG_CATEGORIES to define bitmap => category
control of pr_debugs, and to create their sysfs entries.
Uses it in amdgpu, i915 to control existing pr_debugs according to
their ad-hoc categorizations.
Plugs dyndbg into drm-debug framework, in
Add a const void* data member to the struct, to allow attaching
private data that will be used soon by a setter method (via kp->data)
to perform more elaborate actions.
To attach the data at compile time, add new macros:
module_param_cb_data() derives from module_param_cb(), adding data
param, an
DEFINE_DYNAMIC_DEBUG_CATEGORIES(name, var, bitmap_desc, @bit_descs)
allows users to define a drm.debug style (bitmap) sysfs interface, and
to specify the desired mapping from bits[0-N] to the format-prefix'd
pr_debug()s to be controlled.
DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,
The gvt component of this driver has ~120 pr_debugs, in 9 categories
quite similar to those in DRM. Following the interface model of
drm.debug, add a parameter to map bits to these categorizations.
DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,
"dyndbg bitmap desc",
{ "gv
With DRM_USE_DYNAMIC_DEBUG, each callsite record requires 56 bytes.
We can combine 12 into one here and save ~620 bytes.
Signed-off-by: Jim Cromie
---
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 36 +--
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git a/drive
Taking embedded spaces out of existing prefixes makes them better
class-prefixes; simplifying the nested 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 fo
logger_types.h defines many DC_LOG_*() categorized debug wrappers.
Most of these use DRM debug API, so are controllable using drm.debug,
but others use bare pr_debug("$prefix: .."), each with a different
class-prefix matching "^\[\w+\]:"
Use DEFINE_DYNAMIC_DEBUG_CATEGORIES to create a /sys debug_d
Its tautological that having pr_debug()s with optional print-once and
rate-limiting features could be useful. Build it, they will come.
The advantages:
- dynamically configured with flags
- can use them on existing callsites
- printonce is easy, (almost) just new flags
no additional resources
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 its
pr_debug() get its callsite info from the invoking function, instead
of from drm_debug_enabl
Sean Paul seanp...@chromium.org proposed, in
https://patchwork.freedesktop.org/series/78133/
drm/trace: Mirror DRM debug logs to tracefs
That patchset's objective is to be able to independently steer some of
the debug stream to an alternate tracing destination, by splitting
drm_debug_enabled() int
drm's debug system writes 10 distinct categories of messages to syslog
using a small API[1]: drm_dbg*(10 names), DRM_DEBUG*(8 names),
DRM_DEV_DEBUG*(3 names). There are thousands of these callsites, each
categorized by their authors.
These callsites can be enabled at runtime by their category, ea
There are blocks of DRM_DEBUG calls, consolidate their args into
single calls. With dynamic-debug in use, each callsite consumes 56
bytes of ro callsite data, and this patch removes about 65 calls, so
it saves ~3.5kb.
no functional changes.
RFC: this creates multi-line log messages, does that br
Hi, I have a HAINAN GPU below:
lspci -nn
0a:00.0 Display controller [0380]: Advanced Micro Devices, Inc. [AMD/ATI]
Sun LE [Radeon HD 8550M / R5 M230] [1002:666f]
I run linux 5.13.12 on Arch on a Lenovo B40-70 laptop.
I'm trying to understand more on how voltage control works and how I can
modify
The clocks should be gated before power. And reverse sequence should be
used on ungating.
Change-Id: Iab09f1f616560ff1083b75e95bfc6433d05d7f98
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 8 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 8 +++
.../
Perform proper cleanups on UVD/VCE suspend: powergate enablement,
clockgating enablement and dpm disablement. This can fix some hangs
observed on suspending when UVD/VCE still using(e.g. issue
"pm-suspend" when video is still playing).
Change-Id: I36f39d9731e0a9638b52d5d92558b0ee9c23a9ed
Signed-of
This is a supplement for commit below:
"drm/amdgpu: add missing cleanups for Polaris12 UVD/VCE on suspend".
Change-Id: I7ff5692fd0c3e880ec8e55a7329469a67e5a1363
Signed-off-by: Evan Quan
--
v1->v2:
- correct the sequence for clock/power gating (Lijo Lazar)
---
drivers/gpu/drm/amd/amdgpu/uvd_v3_
As those _sw_fini() APIs follow just after _suspend() APIs.
And the cancel_delayed_work_sync was already called in latter.
Change-Id: I7f092e39242a1ffbc3c29e1fcd7bf31b769b0ef5
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c | 2 --
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c |
From: Praful Swarnakar
[Why]
Recent HDMI2.0 HF1-1 V-Swing testing showed that logging deep color
status helps in validation of testcase.
[How]
Add logging based on various color depths and pixel encoding
formats.
Signed-off-by: Praful Swarnakar
Reviewed-by: Hersen Wu
---
.../drm/amd/display/
Thanks Kees!
Reviewed-by: Lijo Lazar
Thanks,
Lijo
On 8/20/2021 1:44 AM, Kees Cook wrote:
In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
intentionally writing across neighboring fields.
The "Board Param
Am 22.08.21 um 23:23 schrieb Christophe JAILLET:
The wrappers in include/linux/pci-dma-compat.h should go away.
The patch has been generated with the coccinelle script below.
It has been compile tested.
@@
@@
-PCI_DMA_BIDIRECTIONAL
+DMA_BIDIRECTIONAL
@@
@@
-PCI_DMA_TODEVICE
+D
Am 19.08.21 um 22:14 schrieb Kees Cook:
In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
intentionally writing across neighboring fields.
The "Board Parameters" members of the structs:
struct atom
[Public]
Hi Andrey,
Thanks for your notice. The cause why moving drm_sched_fini to sw_fini is it's
a SW behavior and part of SW shutdown, so hw_fini should not touch it. But if
the race, that scheduler on the ring possibly keeps submitting jobs which
causes un-empty ring is there, possibly we
Good mornings guys,
Andrey has a rather valid concern here, but I think we need to approach
this from a more high level view.
When hw_fini is called we should make sure that the scheduler can't
submit any more work to the hardware, because the hw is finalized and
not expected to response any
Hi Evans,
in general the voltage tables are stored in the atombios and the best
advice I can give you is to first double check if there isn't an updated
BIOS for your hardware.
But Alex is the expert on power management, especially for those older
hardware generations. Maybe he has another i
24 matches
Mail list logo
