== Series Details ==
Series: DYNDBG: opt-in class'd debug for modules, use in drm. (rev3)
URL : https://patchwork.freedesktop.org/series/106427/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/106427/revisions/3/mbox/ not
applied
Applying: dyndbg:
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.
lkp robot told me:
>> drivers/gpu/drm/drm_ioc32.c:989:2:
error: call to undeclared function '_dynamic_func_call_cls';
ISO C99 and later do not support implicit function declarations
[-Wimplicit-function-declaration]
DRM_DEBUG("comm=\"%s\", pid=%d, dev=0x%lx, auth=%d, %s\n",
Add an explanation of the new "class CLASS_NAME" syntax and meaning,
noting that the module determines if CLASS_NAME applies to it.
Signed-off-by: Jim Cromie
---
Documentation/admin-guide/dynamic-debug-howto.rst | 11 +++
1 file changed, 11 insertions(+)
diff --git
This exported fn is unused, and will not be needed. Lets dump it.
The export was added to let drm control pr_debugs, as part of using
them to avoid drm_debug_enabled overheads. But its better to just
implement the drm.debug bitmap interface, then its available for
everyone.
Fixes: a2d375eda771
upgrade the callchain to drm_dbg() and drm_dev_dbg(); add a struct
_ddebug ptr parameter to them, and supply that additional param by
replacing the '_no_desc' flavor of dyndbg Factory macro currently used
with the flavor that supplies the descriptor.
NOTES:
The descriptor gives these fns access
Use DECLARE_DYNDBG_CLASSMAP across DRM:
- in .c files, since macro defines/initializes a record
- in drivers, $mod_{drv,drm,param}.c
ie where param setup is done, since a classmap is param related
- in drm/drm_print.c
since existing __drm_debug param is defined there,
and we ifdef
clone the nvkm_printk,_,__ macro ladder into nvkm_drmdbg,_,__.
And alter the debug, trace, spam macros to use the renamed ladder.
This *sets-up* (not done yet) to remove the _subdev->debug >= (l)
condition, once the bitmap-param is wired up correctly, and figured
into dyndbg's jump-label
Add kernel_param_ops and callbacks to use a class-map to validate and
apply input to a sysfs-node, which allows users to control classes
defined in that class-map. This supports uses like:
echo 0x3 > /sys/module/drm/parameters/debug
IE add these:
- int param_set_dyndbg_classes()
- int
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().
This adds the callsite descriptor into the code, and an entry for each
into /proc/dynamic_debug/control.
#> echo class DRM_UT_ATOMIC +p >
Rework/modernize docs:
- use /proc/dynamic_debug/control in examples
its *always* there (when dyndbg is config'd), even when is not.
drop talk, its a distraction here.
- alias ddcmd='echo $* > /proc/dynamic_debug/control
focus on args: declutter, hide boilerplate, make pwd
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,
These 2 macros used drm_debug_enabled() on DRM_UT_{DRIVER,ATOMIC}
respectively, replace those with drm_dbg_##cat invocations.
this results in new class'd prdbg callsites:
:#> grep nouveau /proc/dynamic_debug/control | grep class | wc
1161130 15584
:#> grep nouveau
drm_print defines all of these:
drm_dbg_{core,kms,prime,atomic,vbl,lease,_dp,_drmres}
but not drm_dbg_driver itself, since it was the original drm_dbg.
To improve namespace symmetry, change the drm_dbg defn to
drm_dbg_driver, and redef grandfathered name to symmetric one.
This will help
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 in drm_dbg, drm_devdbg. But test_dynamic_debug needs it in
order to demonstrate all the moving parts.
Note the __ prefix; its not intended for general use, at
With DECLARE_DYNDBG_CLASSMAP modules can declare up to 31 classnames.
By doing so, they authorize dyndbg to manipulate class'd prdbgs (ie:
__pr_debug_cls, and soon drm_*dbg)
:#> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control
The macro declares and initializes a static struct
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
Add module-to-class validation:
#> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control
If a query has "class FOO", then ddebug_find_valid_class(), called
from ddebug_change(), requires that FOO is known to module X,
otherwize the query is skipped entirely for X. This protects each
module's
These 2 macros formerly used dev_info, and they still check
subdev->debug to gate the printing. So dyndbg control is redundant
ATM (and possibly confusing, since its off by default).
prdbg count is up from 3, or from 65 (with VMM_DEBUG here)
[7.765379] dyndbg: 516 debug prints in module
rework var-names for clarity, regularity
rename variables
- n to mod_sites - it counts sites-per-module
- entries to i - display only
- iter_start to iter_mod_start - marks start of each module's subrange
- modct to mod_ct - stylistic
new iterator var:
- site - cursor parallel to iter
Add ddebug_attach_module_classes(), call it from ddebug_add_module().
It scans the classes/section its given, finds records where the
module-name matches the module being added, and adds them to the
module's maps list. No locking here, since the record
isn't yet linked into the ddebug_tables
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,
Add __dyndbg_classes section, using __dyndbg as a model. Use it:
vmlinux.lds.h:
KEEP the new section, which also silences orphan section warning on
loadable modules. Add (__start_/__stop_)__dyndbg_classes linker
symbols for the c externs (below).
kernel/module/main.c:
- fill new fields in
this new struct gathers the linker provided vectors/sections:
descs - the vector of descriptors in __dyndbg section.
num_descs - length of the data/section
Use it as follows:
In lib/dynamic_debug.c:
Alter ddebug_add_module() params-list, replacing descriptor-table and
its length with a
DRM issues ~10 exclusive categories of debug messages; to represent
this directly in dyndbg, add a new field: struct _ddebug.class_id:5.
This gives us 32 classes, which is a practical usability limit
with a bitmap interface:
#> echo 0x012345678 > /sys/module/drm/parameters/debug
All existing
`cat control` currently does octal escape, so '\n' becomes "\012".
Change this to display as "\n" instead, which reads much cleaner.
:#> head -n7 /proc/dynamic_debug/control
# filename:lineno [module]function flags format
init/main.c:1179 [main]initcall_blacklist =_ "blacklisting
Demonstrate use of DECLARE_DYNDBG_CLASSMAP macro, and expose them as
sysfs-nodes for testing.
For each of the 4 class-map-types:
- declare a class-map of that type,
- declare the enum corresponding to those class-names
- share _base across 0..30 range
- add a __pr_debug_cls() call for
Provide a simple module to allow testing DYNAMIC_DEBUG behavior. It
calls do_prints() from module-init, and with a sysfs-node.
dmesg -C
dmesg -w &
modprobe test_dynamic_debug dyndbg=+p
echo 1 > /sys/module/dynamic_debug/parameters/verbose
cat
Walk the module's vector of callsites backwards; ie N..0. This
"corrects" the backwards appearance of a module's prdbg vector when
walked 0..N. I think this is due to linker mechanics, which I'm
inclined to treat as immutable, and the order is fixable in display.
No functional changes.
dyndbg's control-parser: ddebug_parse_query(), requires that search
terms: module, func, file, lineno, are used only once in a query; a
thing cannot be named both foo and bar.
The cited commit added an overriding module modname, taken from the
module loader, which is authoritative. So it set
/proc/dynamic_debug/control walks the prdbg catalog in "reverse",
fix this by adding new ddebug_tables to tail of list.
This puts init/main.c entries 1st, which looks more than coincidental.
no functional changes.
Signed-off-by: Jim Cromie
Acked-by: Jason Baron
---
lib/dynamic_debug.c | 2 +-
print "old => new" flag values to the info("change") message.
no functional change.
Signed-off-by: Jim Cromie
Acked-by: Jason Baron
---
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
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
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
Hi Jason, Greg, DRM-folk,
heres V5. Diffs vs V4:
1st 9 have Jason's Ack
10 is new: simple var cleanup
11 new struct, to contain future addins. touches kernel/module/
dyndbg-param callbacks moved to last (of dyndbg patches)
they're where the uncertainty is,
and the bulk of the API
== Series Details ==
Series: series starting with [1/2] drm/i915/ttm: remove
calc_ctrl_surf_instr_size
URL : https://patchwork.freedesktop.org/series/107031/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11971_full -> Patchwork_107031v1_full
Hi Dave and Daniel,
Please pick this one instead of drm-intel-next-fixes-2022-08-04.
Mauro has pointed out that the commit "drm/i915/gt: Batch TLB invalidations"
was introducing a worst regression in comparison to its intent.
The work is in progress to fix on our -next branches, but we shouldn't
On Fri, Aug 05, 2022 at 05:25:43PM +0200, Mauro Carvalho Chehab wrote:
> On Fri, 5 Aug 2022 10:39:44 -0400
> Rodrigo Vivi wrote:
>
> > On Fri, Aug 05, 2022 at 10:46:57AM +0200, Mauro Carvalho Chehab wrote:
> > > Hi Rodrigo,
> > >
> > > On Thu, 4 Aug 2022 13:33:06 -0400
> > > Rodrigo Vivi
== Series Details ==
Series: Sanitycheck PCI BARs (rev2)
URL : https://patchwork.freedesktop.org/series/106927/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11971 -> Patchwork_106927v2
Summary
---
**FAILURE**
== Series Details ==
Series: Sanitycheck PCI BARs (rev2)
URL : https://patchwork.freedesktop.org/series/106927/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_gt.h:106:16:
From: Piotr Piórkowski
For proper operation of i915 we need usable PCI GTTMMADDR BAR 0
(1 for GEN2). In most cases we also need usable PCI GFXMEM BAR 2.
Let's add functions to check if BARs are set, and that it have
a size greater than 0.
In case GTTMMADDR BAR, let's validate at the beginning of
From: Piotr Piórkowski
When initializing the i915, we want to be sure that the PCI
BARs have been properly initialized.
As part of this series, I have prepared two patches,
one that introduces BARs names to use in code instead of numbers,
and another that adds function to validate BARs before
From: Piotr Piórkowski
At the moment, when we refer to some PCI BAR we use the number of
this BAR in the code. The meaning of BARs between different platforms
may be different. Therefore, in order to organize the code,
let's start using defined names instead of numbers.
v2: Add lost header in
On Fri, 5 Aug 2022 10:39:44 -0400
Rodrigo Vivi wrote:
> On Fri, Aug 05, 2022 at 10:46:57AM +0200, Mauro Carvalho Chehab wrote:
> > Hi Rodrigo,
> >
> > On Thu, 4 Aug 2022 13:33:06 -0400
> > Rodrigo Vivi wrote:
> >
> > > Hi Dave and Daniel,
> > >
> > > Here goes
On Fri, Aug 05, 2022 at 10:45:30AM +0100, Tvrtko Ursulin wrote:
On 05/08/2022 00:21, Umesh Nerlige Ramappa wrote:
From: John Harrison
GuC provides engine_id and last_switch_in ticks for an active context in
the pphwsp. The context image provides a 32 bit total ticks which is the
accumulated
== Series Details ==
Series: series starting with [1/2] drm/i915/ttm: remove
calc_ctrl_surf_instr_size
URL : https://patchwork.freedesktop.org/series/107031/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11971 -> Patchwork_107031v1
Commit ed7c8cfb67e3 ("tests/i915/gem_exec_fence: Add
__for_each_physical_engine to utilize all engines."), while replacing
depraciated for_each_physical_engine(e, fd) loop with
__for_each_physical_engine(fd, e2) and gem_can_store_dword() inside that
loop with gem_class_can_store_dword(), didn't
On Fri, Aug 05, 2022 at 10:46:57AM +0200, Mauro Carvalho Chehab wrote:
> Hi Rodrigo,
>
> On Thu, 4 Aug 2022 13:33:06 -0400
> Rodrigo Vivi wrote:
>
> > Hi Dave and Daniel,
> >
> > Here goes drm-intel-next-fixes-2022-08-04:
> >
> > - disable pci resize on 32-bit systems (Nirmoy)
> > - don't
== Series Details ==
Series: series starting with [1/2] drm/i915/ttm: remove
calc_ctrl_surf_instr_size
URL : https://patchwork.freedesktop.org/series/107031/
State : warning
== Summary ==
Error: dim checkpatch failed
ad7f4d913058 drm/i915/ttm: remove calc_ctrl_surf_instr_size
179693b5b5ef
Commit c8f6aaf32d83 "tests/gem_exec_fence: Check stored values only for
valid workloads" resolved an issue, observed in *await-hang scenarios,
where a fence exposed by an invalid spin batch was signaled asynchronously
to pending checks for depended test batches still waiting for that fence.
Those
When i = 0, condition out[i] == i will be true even if a batch supposed
to store i in out[i] fails. Don't use i = 0 in batches that store values
in out[i].
v2: still check for out[0] == 0 (Chris)
Signed-off-by: Janusz Krzysztofik
---
tests/i915/gem_exec_fence.c | 13 -
1 file
On 2022/06/30 22:09, Tvrtko Ursulin wrote:
>>> On the i915 specifics, the caller in
>>> drivers/gpu/drm/i915/gt/selftest_execlists.c
>>> I am pretty sure can be removed. It is synchronized with the error capture
>>> side of
>>> things which is not required for the test to work.
>>>
>>> I can
We only ever need to emit one ccs block copy command.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 35 +++--
1 file changed, 3 insertions(+), 32 deletions(-)
diff --git
Crucible + recent Mesa seems to sometimes hit:
GEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER)
And it looks like we can also trigger this with gem_lmem_swapping, if we
modify the test to use slightly larger object sizes.
Looking closer it looks like we have the following issues in
Everything we are testing here unfortunately fits within one packet (8M)
which means we have zero coverage when we need to split the copy over
multiple packets (including the aux CCS state).
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
tests/i915/gem_lmem_swapping.c |
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/edid: convert DP, HDMI and LVDS
to drm_edid
URL : https://patchwork.freedesktop.org/series/107020/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11970_full -> Patchwork_107020v1_full
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/edid: convert DP, HDMI and LVDS
to drm_edid
URL : https://patchwork.freedesktop.org/series/107020/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11970 -> Patchwork_107020v1
== Series Details ==
Series: drm/i915/hdcp: register cleanup (rev3)
URL : https://patchwork.freedesktop.org/series/106964/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11970_full -> Patchwork_106964v3_full
Summary
---
On Fri, 5 Aug 2022 10:24:25 +0100
Tvrtko Ursulin wrote:
> On 05/08/2022 10:08, Andi Shyti wrote:
> > Hi Randy,
> >
> >>> +/**
> >>> + * intel_gt_invalidate_tlb_full - do full TLB cache invalidation
> >>> + * @gt: GT structure
> >>
> >> In multiple places (here and below) it would be nice to
Convert all the connectors that use cached connector edid and
detect_edid to drm_edid.
Since drm_get_edid() calls drm_connector_update_edid_property() while
drm_edid_read*() do not, we need to call drm_edid_connector_update()
separately, in part due to the EDID caching behaviour in HDMI and
DP.
Try to use struct drm_edid where possible, even if having to fall back
to looking into struct edid down low via drm_edid_raw().
v2: Rebase
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 19 ++-
On 05/08/2022 00:21, Umesh Nerlige Ramappa wrote:
From: John Harrison
GuC provides engine_id and last_switch_in ticks for an active context in
the pphwsp. The context image provides a 32 bit total ticks which is the
accumulated by the context (a.k.a. context[CTX_TIMESTAMP]). This
information
On 05/08/2022 10:08, Andi Shyti wrote:
Hi Randy,
+/**
+ * intel_gt_invalidate_tlb_full - do full TLB cache invalidation
+ * @gt: GT structure
In multiple places (here and below) it would be nice to know what a
GT structure is. I looked thru multiple C and header files yesterday
and didn't
On 04/08/2022 19:56, Summers, Stuart wrote:
On Thu, 2022-08-04 at 09:42 +0100, Tvrtko Ursulin wrote:
On 04/08/2022 00:03, Stuart Summers wrote:
In the driver teardown, we are unregistering the gt prior
to unregistering the PMU. This means there is a small window
of time in which the
== Series Details ==
Series: drm/i915/hdcp: register cleanup (rev3)
URL : https://patchwork.freedesktop.org/series/106964/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11970 -> Patchwork_106964v3
Summary
---
On 04/08/2022 09:59, Arunpravin Paneer Selvam wrote:
Implemented a new intersect and compatible callback function
fetching start offset from drm buddy allocator.
v3: move the bits that are specific to buddy_man (Matthew)
v4: consider the block size /range (Matthew)
Signed-off-by: Christian
Hi Randy,
> > +/**
> > + * intel_gt_invalidate_tlb_full - do full TLB cache invalidation
> > + * @gt: GT structure
>
> In multiple places (here and below) it would be nice to know what a
> GT structure is. I looked thru multiple C and header files yesterday
> and didn't find any comments about
== Series Details ==
Series: drm/i915/hdcp: register cleanup (rev3)
URL : https://patchwork.freedesktop.org/series/106964/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915/hdcp: register cleanup (rev3)
URL : https://patchwork.freedesktop.org/series/106964/
State : warning
== Summary ==
Error: dim checkpatch failed
d17261c0cd1c drm/i915/hdcp: split out hdcp registers to a separate file
Traceback (most recent call last):
Hi Rodrigo,
On Thu, 4 Aug 2022 13:33:06 -0400
Rodrigo Vivi wrote:
> Hi Dave and Daniel,
>
> Here goes drm-intel-next-fixes-2022-08-04:
>
> - disable pci resize on 32-bit systems (Nirmoy)
> - don't leak the ccs state (Matt)
> - TLB invalidation fixes (Chris)
>
> Thanks,
> Rodrigo.
>
> The
Commit ed7c8cfb67e3 ("tests/i915/gem_exec_fence: Add
__for_each_physical_engine to utilize all engines."), while replacing
depraciated for_each_physical_engine(e, fd) loop with
__for_each_physical_engine(fd, e2) and gem_can_store_dword() inside that
loop with gem_class_can_store_dword(), didn't
> -Original Message-
> From: Nikula, Jani
> Sent: Wednesday, August 3, 2022 1:44 PM
> To: Manna, Animesh ; intel-
> g...@lists.freedesktop.org
> Cc: ville.syrj...@linux.intel.com; Shankar, Uma ;
> Manna, Animesh
> Subject: Re: [PATCH] drm/i915/pps: added get_pps_idx() hook as part of
When i == 0, condition out[i] == i will be true even if a batch supposed
to store i in out[i] fails. Don't use 0.
Signed-off-by: Janusz Krzysztofik
---
tests/i915/gem_exec_fence.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/tests/i915/gem_exec_fence.c
Commit c8f6aaf32d83 "tests/gem_exec_fence: Check stored values only for
valid workloads" resolved an issue, observed in *await-hang scenarios,
where a fence exposed by an invalid spin batch was signaled asynchronously
to pending checks for depended test batches still waiting for that fence.
Those
== Series Details ==
Series: i915/pmu: Wire GuC backend to per-client busyness (rev4)
URL : https://patchwork.freedesktop.org/series/105085/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11970_full -> Patchwork_105085v4_full
75 matches
Mail list logo
