Currently amdxdna uses drm_dbg, so it needs this cflag in order to
compile; it currently gets the cflag from its own Makefile.
If other accel modules want to use DRM.debug, they will need this flag
too, so add it in accel/Makefile.
NOTE: ivpu has its own CLASS-ish dbg system:
./drivers/accel/ivp
with DRM_USE_DYNAMIC_DEBUG=y now un-BROKEN
for configs like:
CONFIG_DRM_USE_DYNAMIC_DEBUG=y
# CONFIG_DYNAMIC_DEBUG is not set
CONFIG_DYNAMIC_DEBUG_CORE=y
this module gets macro breakage:
from ../drivers/accel/amdxdna/aie2_ctx.c:8:
../drivers/accel/amdxdna/aie2_ctx.c: In f
Time for some thorough CI.
Also, the previous 18 patches could perhaps be replaced by a single
invocation of DYNDBG_CLASSMAP_USE, from a C-file linked into all drm
drivers & helpers. I didn't find such a file, nor a drm-client
linkage item in the Makefile.
Signed-off-by: Jim Cromie
---
drivers
The drm_gem_shmem_helper driver has a number of DRM_UT_* debugs, make
them controllable when CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling
dyndbg that the module uses them.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/driver
The gud driver has a number of DRM_UT_* debugs, make them
controllable when CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg
that the module uses them.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/gud/gud_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/gud/gud_drv.c
The qxl driver has a number of DRM_UT_* debugs, make them
controllable when CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg
that the module uses them.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/qxl/qxl_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c
The udl driver has a number of DRM_UT_* debugs, make them
controllable when CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg
that the module uses them.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/udl/udl_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/udl/udl_main.
The mgag200 driver has a number of DRM_UT_* debugs, make them
controllable when CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg
that the module uses them.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/mg
The vkms driver has a number of DRM_UT_* debugs, make them
controllable when CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg
that the module uses them.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/vkms/vkms_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/vkms/vkms_d
The vmwgfx driver has a number of DRM_UT_* debugs, make them
controllable when CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg
that the module uses them.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/vmwgf
radeon has some DRM_UT_* debugs, make them controllable when
CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg about its use of
the class'd debugs.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/radeon/radeon_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon
etnaviv has 5 DRM_UT_CORE debugs, make them controllable when
CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg that the module has
class'd debugs as well as plain-old pr_debug()s
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --g
The gma500 has 126 DRM_UT_* debugs, make them controllable when
CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg that the module has
class'd debugs.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/gma500/psb_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/gma500/psb_drv
tiny/bochs has 5 DRM_UT_* debugs, make them controllable when
CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg that the module has
class'd debugs.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/tiny/bochs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/tiny/bochs.c b/drive
Following the dyndbg-api-fix, replace DECLARE_DYNDBG_CLASSMAP with
DRM_CLASSMAP_USE. This refs the defined & exported classmap, rather
than re-declaring it redundantly, and error-prone-ly.
This resolves the appearance of "class:_UNKNOWN_" in the control file
for the driver's drm_dbg()s.
Fixes: f
Invoke DRM_CLASSMAP_USE from xe_drm_client.c. When built with
CONFIG_DRM_USE_DYNAMIC_DEBUG=y, this tells dydnbg that Xe has
drm.debug callsites.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/xe/xe_drm_client.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_drm_clien
tiny/simpledrm has 3 DRM_UT_DRIVER debugs, make them controllable when
CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg that the module has
class'd debugs.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/sysfb/simpledrm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/sysfb/
virtio_gpu has 10 DRM_UT_CORE debugs, make them controllable when
CONFIG_DRM_USE_DYNAMIC_DEBUG=y by telling dyndbg that the module has
class'd debugs.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/virtio/v
Following the dyndbg-api-fix, replace DECLARE_DYNDBG_CLASSMAP with
DRM_CLASSMAP_USE. This refs the defined & exported classmap, rather
than re-declaring it redundantly, and error-prone-ly.
This resolves the appearance of "class:_UNKNOWN_" in the control file
for the driver's drm_dbg()s.
Fixes: f
Following the dyndbg-api-fix, replace DECLARE_DYNDBG_CLASSMAP with
DRM_CLASSMAP_USE. This refs the defined & exported classmap, rather
than re-declaring it redundantly, and error-prone-ly.
This resolves the appearance of "class:_UNKNOWN_" in the control file
for the driver's drm_dbg()s.
Fixes: f
Following the dyndbg-api-fix, replace DECLARE_DYNDBG_CLASSMAP with
DRM_CLASSMAP_USE. This refs the defined & exported classmap, rather
than re-declaring it redundantly, and error-prone-ly.
This resolves the appearance of "class:_UNKNOWN_" in the control file
for the driver's drm_dbg()s.
Fixes: f
Following the dyndbg-api-fix, replace DECLARE_DYNDBG_CLASSMAP with
DRM_CLASSMAP_USE. This refs the defined & exported classmap, rather
than re-declaring it redundantly, and error-prone-ly.
This resolves the appearance of "class:_UNKNOWN_" in the control file
for the driver's drm_dbg()s.
Fixes: f
With CONFIG_DRM_USE_DYNAMIC_DEBUG=y, __drm_printfn_dbg() gets an
unused variable warning/error on 'category', even though the usage
follows immediately, in drm_debug_enabled(category).
For static-key optimized dyndbg, the macro doesn't actually check the
category var, since the static-key patches
Invoke DYNAMIC_DEBUG_CLASSMAP_PARAM to hook drm.debug (__drm_debug) to the
DRM_UT_* classmap, replacing the ad-hoc wiring previously doing it.
Add DRM_CLASSMAP_* adapter macros to selectively use
DYNAMIC_DEBUG_CLASSMAP_* when DRM_USE_DYNAMIC_DEBUG=y is configured.
Signed-off-by: Jim Cromie
Revie
dyndbg's CLASSMAP-v1 api was broken; DECLARE_DYNDBG_CLASSMAP tried to
do too much. Its replaced by DRM_CLASSMAP_DEFINE, which creates &
EXPORTs a classmap (in DRM core), and DRM_CLASSMAP_USE which refers to
the classmap defined elsewhere.
The drivers still use DECLARE_DYNDBG_CLASSMAP for now, so
Reserve a flag-bit to remember that a pr-debug callsite is/was:
- enabled, with +p
- wants a dynamic-prefix, with 1+ of module:function:sourcefile
- was previously called
- was thus saved in the prefix cache. NOT YET.
This allows (later) to cache part/all of the dynamic-prefix for each
pr_debug th
Split dynamic_emit_prefix():
1. keep dynamic_emit_prefix() static inline
check ANY flags before calling 2
2. __dynamic_emit_prefix()
prints [TID] or if +t flag
check LOOKUP flags before calling 3
3. __dynamic_emit_lookup()
prints 1+ of: module, function, src-file, line
Notes:
With
Incorrectly spelled CFLAGS- failed to add -DDYNAMIC_DEBUG_MODULE,
which disabled dynamic-debug in modules built with:
CONFIG_DYNAMIC_DEBUG=n # 1
CONFIG_DYNAMIC_DEBUG_CORE=y # 2
CONFIG_DRM_USE_DYNAMIC_DEBUG=y # 3
NB: this adds the flag (when 3) more often than strictly needed;
module
dyndbg's dynamic prefixing can get expensive; each enabled callsite's
prefix is sprintf'd into stack-mem, every time a pr_debug is called.
A cache would help, if callsites mark _DPRINTK_FLAGS_PREFIX_CACHED
after saving the prefix string. But not just yet.
_DPRINTK_FLAGS_INCL_LOOKUP distinguishes
Describe the 3 API macros providing dynamic_debug's classmaps
DYNDBG_CLASSMAP_DEFINE - create & export a classmap
DYNDBG_CLASSMAP_USE- refer to exported map
DYNDBG_CLASSMAP_PARAM - bind control param to the classmap
DYNDBG_CLASSMAP_PARAM_REF + use module's storage - __drm_debug
TBD: some of
DRM has always had /sys/module/drm/parameters/debug (ie drm.debug).
Without dyndbg, this is their only control point. One could presume
they like it - in any case its a system/user interface, ie ABI.
With dyndbg enabled, drm calls DYNAMIC_DEBUG_CLASSMAP_PARAM() to
create the drm.debug kparam, wir
Current classmap code protects class'd pr_debugs from unintended
changes by "legacy" unclassed queries:
# this doesn't disable all of DRM_UT_* categories
echo "-p" > /proc/dynamic_debug/control
# name the class to change it - protective but tedious
echo "class DRM_UT_CORE +p" > /proc/dyna
Since commit
85f7f6c0edb8 ("dynamic_debug: process multiple debug-queries on a line")
Multi-query commands have been allowed:
modprobe drm dyndbg="class DRM_UT_CORE +p; class DRM_UT_KMS +p"
modprobe drm dyndbg=<
[ 203.902703] dyndbg: query parse failed
[ 203.902871] dyndbg: processed 2 quer
This new test-fn runs 3 module/submodule modprobe scenarios, variously
using both the generic dyndbg= modprobe arg, and the
test-module's classmap-params to manipulate the test-mod*'s pr_debugs.
In all cases, the current flag-settings are counted and tested vs
expectations.
The 3rd scenario recapi
Treat comma as a token terminator, just like a space. This allows a
user to avoid quoting hassles when spaces are otherwise needed:
:#> modprobe drm dyndbg=class,DRM_UT_CORE,+p\;class,DRM_UT_KMS,+p
or as a boot arg:
drm.dyndbg=class,DRM_UT_CORE,+p # todo: support multi-query here
Given the
echo 1000 > /sys/module/test_dynamic_debug/parameters/do_prints
This allows its use as a scriptable load generator, to generate
dynamic-prefix-emits for flag combinations vs undecorated messages.
This will make it easy to assess the cost of the prefixing.
Reading the ./do_prints node also prints
move the DYNAMIC_DEBUG_CLASSMAP_PARAM macro from test-dynamic-debug.c into
the header, and refine it, by distinguishing the 2 use cases:
1.DYNAMIC_DEBUG_CLASSMAP_PARAM_REF
for DRM, to pass in extern __drm_debug by name.
dyndbg keeps bits in it, so drm can still use it as before
2.DYNAMIC_
Add __DYNAMIC_DEBUG_CLASSMAP_CHECK to implement the following
arg-checks at compile-time:
0 <= _base < 63
class_names is not empty
class_names[0] is a string
(class_names.length + _base) < 63
These compile-time checks will prevent several misuses; 4 such
examples a
If a module _DEFINEs + _USEs 2 or more classmaps, it must devise them
to share the per-module 0..62 class-id space; ie their respective
base,+length reservations cannot overlap.
To detect conflicts at modprobe, add ddebug_class_range_overlap(),
call it from ddebug_add_module(), and WARN and return
DECLARE_DYNDBG_CLASSMAP() has a design error; its usage fails a basic
K&R rule: "define once, refer many times".
When DRM_USE_DYNAMIC_DEBUG=y, it is used across DRM core & drivers;
each invocation allocates/inits the classmap understood by that
module. All must match for the modules to respond to
The Xe driver's XE_IOCTL_DBG macro calls drm_dbg() from inside an if
(expression). This breaks when CONFIG_DRM_USE_DYNAMIC_DEBUG=y because
the invoked macro has a do-while-0 wrapper, and is not an expression.
if (cond && (drm_dbg("expr-form"),1)) {
... do some more stuff
}
Fix for th
Add a selftest script for dynamic-debug. The config requires
CONFIG_TEST_DYNAMIC_DEBUG=m and CONFIG_TEST_DYNAMIC_DEBUG_SUBMOD=m,
which tacitly requires either CONFIG_DYNAMIC_DEBUG=y or
CONFIG_DYNAMIC_DEBUG_CORE=y
ATM this has just basic_tests(), which modify pr_debug() flags in the
builtin params
Remove the DD_CLASS_TYPE_*_NAMES classmap types and code.
These 2 classmap types accept class names at the PARAM interface, for
example:
echo +DRM_UT_CORE,-DRM_UT_KMS > /sys/module/drm/parameters/debug_names
The code works, but its only used by test-dynamic-debug, and wasn't
asked for by anyon
dynamic-debug has several __sections, each with ,
num_, and it iterates over these with a 2-index for-loop.
These loops are fiddly with the 2 names.
We have only 2 such loops now, but are getting more soon; lets
embed/abstract the fiddlyness in the for_subvec() macro, and avoid
repeating it going
struct _ddebug_info already has most of dyndbg's info for a module;
push debug_table.mod_name down into it, finishing the encapsulation.
This allows refactoring several callchains, passing &_ddebug_info
instead of &ddebug_table, and hoisting the "&dt->info" deref up.
ddebug_table contains a _ddeb
The body of ddebug_attach_module_classes() is dominated by a
code-block that finds the contiguous subrange of classmaps matching on
modname, and saves it into the ddebug_table's info record.
Implement this block in a macro to accommodate different component
vectors in the "box" (as named in the fo
recompose struct _ddebug_info, inserting proper sub-structs.
The struct currently has 2 pairs of fields: descs, num_descs and
classes, num_classes. Several for-loops operate on these field pairs,
soon many more will be added.
Looping over these blocks by respective field-pairs is repetitive and
Classmaps are stored in an elf section/array, but currently are
individually list-linked onto dyndbg's per-module ddebug_table for
operation. This is unnecessary.
Just like dyndbg's descriptors, classes are packed in compile order;
so even with many builtin modules employing multiple classmaps, ea
old_bits arg is currently a pointer to the input bits, but this could
allow inadvertent changes to the input by the fn. Disallow this.
And constify new_bits while here.
Signed-off-by: Jim Cromie
Reviewed-by: Louis Chauvet
---
lib/dynamic_debug.c | 21 +++--
1 file changed, 11 i
Refactor callchain below param_set_dyndbg_classes(1) to allow mod-name
specific settings. Split (1) into upper/lower fns, adding modname
param to lower, and passing NULL in from upper. Below that, add the
same param to ddebug_apply_class_bitmap(), and pass it thru to
_ddebug_queries(), replacing
currently, for verbose=3, these are logged (blank lines for clarity):
dyndbg: query 0: "class DRM_UT_CORE +p" mod:*
dyndbg: split into words: "class" "DRM_UT_CORE" "+p"
dyndbg: op='+'
dyndbg: flags=0x1
dyndbg: *flagsp=0x1 *maskp=0x
dyndbg: parsed: func="" file="" module="" format="
Disambiguate pr_fmt(fmt) arg, by changing it to _FMT_, to avoid naming
confusion with many later macros also using that argname.
no functional change
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/dynamic_debug.c b/lib/d
ARRAY_SIZE works here, since array decl is complete.
no functional change
Signed-off-by: Jim Cromie
Reviewed-by: Louis Chauvet
---
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
struct ddebug_class_param keeps a ref to the state-storage of the
param; make both class-types use the same unsigned long storage type.
ISTM this is simpler and safer; it avoids an irrelevant difference,
and if 2 users somehow get class-type mixed up (or refer to the wrong
union member), at least
When writing queries to >control, flags are parsed 1st, since they are
the only required field, and they require specific compositions. So
if the flags draw an error (on those specifics), then keyword errors
aren't reported. This can be mildly confusing/annoying, so explain it
instead.
cc: linux
When a dyndbg classname is unknown to a kernel module (as before
previous patch), the callsite is un-addressable via >control queries.
The control-file displays this condition as "class unknown,"
currently. That spelling is sub-optimal/too-generic, so change it to
"class:_UNKNOWN_" to loudly anno
commit 6ea3bf466ac6 ("dyndbg: test DECLARE_DYNDBG_CLASSMAP, sysfs nodes")
A closer look at test_dynamic_debug.ko logging output reveals a macro
usage error:
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
commit 47ea6f99d06e ("dyndbg: use ESCAPE_SPACE for cat control")
changed the control-file to display format strings with "\n" rather
than "\012". Update the docs to match the new reality.
Signed-off-by: Jim Cromie
Reviewed-by: Louis Chauvet
Tested-by: Louis Chauvet
---
-v2 fix missed \012's
---
This series fixes dynamic-debug's support for DRM debug-categories.
Classmaps-v1 evaded full review, and got committed in 2 chunks:
b7b4eebdba7b..6ea3bf466ac6# core dyndbg changes
0406faf25fb1..ee7d633f2dfb# drm adoption
Then DRM-CI found a regression when booting with drm.debug=;
t
On Tue, Apr 15, 2025 at 12:42:58PM +0200, AngeloGioacchino Del Regno wrote:
>
> This series adds support for the HDMI-TX v2 Encoder and DDCv2, and for
> the direct connection DPI as found in MT8195, MT8188 and their variants.
Angelo, just wanted to check, what is the fate of this series? I think
On 25/07/24 03:59PM, Seyediman Seyedarab wrote:
> snprintf() returns the number of characters that *would* have been
> written, which can overestimate how much you actually wrote to the
> buffer in case of truncation. That leads to 'data += this' advancing
> the pointer past the end of the buffer a
On Sat Aug 2, 2025 at 4:15 PM CEST, Daniel Almeida wrote:
> On 2 Aug 2025, at 07:42, Benno Lossin wrote:
>> On Fri Aug 1, 2025 at 11:22 PM CEST, Daniel Almeida wrote:
>>> One thing I didn’t understand with your approach: is it amenable to loops?
>>> i.e.: are things like drm_exec() implementable?
On 7/31/25 22:36, Sravan Kumar Gundu wrote:
This issue triggers when a userspace program does an ioctl
FBIOPUT_CON2FBMAP by passing console number and frame buffer number.
Ideally this maps console to frame buffer and updates the screen if
console is visible.
As part of mapping it has to do resi
Replace DRM_GPU_SCHED_STAT_NOMINAL with GPU_DRM_SCHED_STAT_RESET, in
accordance with commit 0a5dc1b67ef5 ("drm/sched: Rename
DRM_GPU_SCHED_STAT_NOMINAL to DRM_GPU_SCHED_STAT_RESET")
Pass extra parameter to drm_sched_job_init, as required by commit
2956554823ce ("drm/sched: Store the drm client_id
Fix sparse warning regarding an undeclared const rocket_pm_ops, which is
used in rocket_drv.c.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202508030021.uwdr4p08-...@intel.com/
Signed-off-by: Brigham Campbell
---
drivers/accel/rocket/rocket_drv.h | 2 ++
1 file
: 01ac6e4e53b6351df42c97d217b0d2dbeef5c917
change-id: 20250802-fix-rockchip-npu-build-ca759ba8da06
Best regards,
--
Brigham Campbell
On Tue, 08 Jul 2025 10:51:22 +0200, Johan Hovold wrote:
> Make sure to drop the OF node references taken when creating bridge
> device when the devices are later released.
>
> Johan
>
>
> Johan Hovold (2):
> drm/bridge: fix OF node leak
> drm/bridge: ti-sn65dsi86: fix OF node leak
>
> [...]
On Tue, Jul 08, 2025 at 10:51:23AM +0200, Johan Hovold wrote:
> Make sure to drop the OF node reference taken when creating the aux
> bridge device when the device is later released.
>
> Fixes: 6914968a0b52 ("drm/bridge: properly refcount DT nodes in aux bridge
> drivers")
> Cc: Dmitry Baryshkov
-r132-20250802
(https://download.01.org/0day-ci/archive/20250803/202508030021.uwdr4p08-...@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 8.5.0
reproduce:
(https://download.01.org/0day-ci/archive/20250803/202508030021.uwdr4p08-...@intel.com/reproduce)
If you fix the issue in a separate
The pull request you sent on Sat, 2 Aug 2025 13:04:24 +0200:
> http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git
> tags/fbdev-for-6.17-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/eacf91b0c78a7113844830ed65ebf543eb9052c5
Thank you!
--
Deet
drm: drm_bridge: fix missing parameter documentation
The function documentation was missing description for the
parameter 'connector'.
Add missing function parameter documentation for drm_bridge_detect()
to fix kernel-doc warnings.
Warning: drivers/gpu/drm/drm_bridge.c:1241 function parameter 'c
On Fri, Aug 01, 2025 at 01:30:02PM -0700, James Jones wrote:
> Apologies, I saw your changes for another chipset, but missed the nouveau
> part.
Ok, no problem, thanks for testing it and the review. The omap patch is
still missing an ack/review, the patchset can be merged after an
omap maintainer
> On 2 Aug 2025, at 07:42, Benno Lossin wrote:
>
> On Fri Aug 1, 2025 at 11:22 PM CEST, Daniel Almeida wrote:
>> Hi Benno,
>>
>>> On 7 Jul 2025, at 16:48, Benno Lossin wrote:
>>>
>>> On Mon Jul 7, 2025 at 8:06 PM CEST, Onur wrote:
On Mon, 07 Jul 2025 17:31:10 +0200
"Benno Lossin"
On Sat, Aug 2, 2025 at 12:49 AM Dan Carpenter wrote:
>
> Hello Rob Clark,
>
> Commit 2e6a8a1fe2b2 ("drm/msm: Add VM_BIND ioctl") from Jun 29, 2025
> (linux-next), leads to the following Smatch static checker warning:
>
> drivers/gpu/drm/msm/msm_gem_vma.c:596 msm_gem_vm_sm_step_remap()
>
On Tue, Jul 29, 2025 at 01:42:14PM +0800, Chen Ni wrote:
> Remove unnecessary semicolons reported by Coccinelle/coccicheck and the
> semantic patch at scripts/coccinelle/misc/semicolon.cocci.
>
> Signed-off-by: Chen Ni
> ---
> drivers/gpu/drm/panel/panel-himax-hx8279.c | 2 +-
> 1 file changed,
On Sat, Aug 02, 2025 at 08:38:36AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Aug 01, 2025 at 06:26:04PM +0300, Imre Deak wrote:
> > Hi Greg and Shradha,
> >
> > could you please check the comment below about the 4ad8d57d902f backport
> > commit in the v6.1.y stable tree and if you agree with the
Hi Linus,
please pull the fbdev fixes and updates for 6.17-rc1:
One potential buffer overflow fix in the framebuffer registration function,
some fixes for the imxfb, nvidiafb and simplefb drivers, and a bunch of
cleanups for fbcon, kyrofb and svgalib.
Thanks,
Helge
-
c2b2be16ea6ee9e23799ca182e1cd37c
change-id: 20250802-dp-conn-no-detect-b901893b5e3c
Best regards,
--
With best wishes
Dmitry
On Fri, Aug 01, 2025 at 04:58:55PM -0700, Jessica Zhang wrote:
>
>
> On 7/14/2025 4:54 AM, Dmitry Baryshkov wrote:
> > On Fri, Jul 11, 2025 at 05:58:23PM -0700, Jessica Zhang wrote:
> > > Currently, the DP link training is being done during HPD. Move
> > > link training to atomic_enable() in acco
Hi Ethan,
kernel test robot noticed the following build errors:
[auto build test ERROR on b9ddaa95fd283bce7041550ddbbe7e764c477110]
url:
https://github.com/intel-lab-lkp/linux/commits/Ethan-Carter-Edwards/drm-nouveau-gsp-remove-always-true-if-check/20250802-095804
base
On Wed, Jul 30, 2025 at 05:42:28PM +0800, Yongxing Mou wrote:
> Document the MDSS hardware found on the Qualcomm QCS8300 platform.
>
> Signed-off-by: Yongxing Mou
> ---
> .../bindings/display/msm/qcom,qcs8300-mdss.yaml| 284
> +
> 1 file changed, 284 insertions(+)
>
> d
On Thu, Jul 31, 2025 at 10:19:49AM +0800, Chaoyi Chen wrote:
> Hi Dmitry,
>
> On 7/31/2025 3:13 AM, Dmitry Baryshkov wrote:
> > On Tue, Jul 29, 2025 at 05:00:27PM +0800, Chaoyi Chen wrote:
> > > From: Chaoyi Chen
> > >
> > > This series focuses on adding Type-C DP support for USBDP PHY and DP
>
On Wed, 30 Jul 2025 at 03:37, Marie Zhussupova wrote:
>
> To enable more complex parameterized test scenarios,
> the `generate_params` function sometimes needs additional
> context beyond just the previously generated parameter.
> This patch modifies the `generate_params` function signature
> to i
On Wed, 30 Jul 2025 at 03:37, Marie Zhussupova wrote:
>
> -Update the KUnit documentation to explain the concept
> of a parent parameterized test.
> -Add examples demonstrating different ways of passing
> parameters to parameterized tests and how to manage
> shared resources between them.
>
Nit:
On Wed, 30 Jul 2025 at 03:37, Marie Zhussupova wrote:
>
> Introduce `example_params_test_with_init_dynamic_arr`. This new
> KUnit test demonstrates directly assigning a dynamic parameter
> array using the `kunit_register_params_array` macro. It highlights the
> use of `param_init` and `param_exit`
On Wed, 30 Jul 2025 at 03:37, Marie Zhussupova wrote:
>
> KUnit parameterized tests currently support two
> primary methods for getting parameters:
> 1. Defining custom logic within a `generate_params`
> function.
> 2. Using the KUNIT_ARRAY_PARAM and KUNIT_ARRAY_PARAM_DESC
> macros with
On Wed, 30 Jul 2025 at 03:37, Marie Zhussupova wrote:
>
> Add `example_params_test_with_init` to illustrate how to manage
> shared resources across parameterized KUnit tests. This example
> showcases the use of the new `param_init` function and its registration
> to a test using the `KUNIT_CASE_PA
On Wed, 30 Jul 2025 at 03:37, Marie Zhussupova wrote:
>
> This patch modifies `xe_pci_live_device_gen_param`
> in xe_pci.c to accept an additional `struct kunit *test`
> argument.
>
> Signed-off-by: Marie Zhussupova
> ---
This is a pretty straightforward fix after patch 3. xe folks, would
you p
On Wed, 30 Jul 2025 at 03:37, Marie Zhussupova wrote:
>
> This patch modifies `nthreads_gen_params` in kcsan_test.c
> to accept an additional `struct kunit *test` argument.
>
> Signed-off-by: Marie Zhussupova
> ---
This is a pretty straightforward fix after patch 3. KCSAN folks, would
you prefer
On Wed, 30 Jul 2025 at 03:37, Marie Zhussupova wrote:
>
> Add `param_init` and `param_exit` function pointers to
> `struct kunit_case`. Users will be able to set them
> via the new `KUNIT_CASE_PARAM_WITH_INIT` macro.
>
> These functions are invoked by kunit_run_tests() once before
> and once after
On Wed, 30 Jul 2025 at 03:37, Marie Zhussupova wrote:
>
> Currently, KUnit parameterized tests lack a mechanism
> to share resources across individual test invocations
> because the same `struct kunit` instance is reused for
> each test.
>
> This patch refactors kunit_run_tests() to provide each
>
The repeated checks on grbm_soft_reset are unnecessary. Remove them.
Signed-off-by: Ethan Carter Edwards
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
b/drivers/gpu
On Thu, Jul 31, 2025 at 9:38 PM Alex Deucher wrote:
> On Thu, Jul 31, 2025 at 3:33 AM Philipp Zabel
> wrote:
> >
> > Don't wake the GPU if libdrm queries the mmGB_ADDR_CONFIG register
> > value during amdgpu_query_gpu_info_init(). Instead, return the already
> > cached value adev->gfx.config.gb_
Hello Intel Linux Graphics Team,
I'm using an Intel Arrow Lake GPU (8086:7d67) on Ubuntu 24.04 (kernel 6.16)
and facing complete lack of video output without 'nomodeset'.
Problem Description:
- GPU: Intel Arrow Lake [8086:7d67] (Core Ultra 7 265K)
- Kernel: 6.16.0-xx-generic (Ubuntu 24.04)
- Issu
The repeated checks on grbm_soft_reset are unnecessary. Remove them.
Signed-off-by: Ethan Carter Edwards
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/d
On Mon, Jun 16, 2025 at 08:33:19PM +0100, Lorenzo Stoakes wrote:
> The intent is to gradually deprecate f_op->mmap, and in that vein this
> series coverts the majority of file systems to using f_op->mmap_prepare.
I saw this on lwn and just wanted to give a little bit of thought on
this topic..
I
if (1) always evaluates to true. Remove the unneeded check.
Signed-off-by: Ethan Carter Edwards
---
.../gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/fifo.c | 36 ++
1 file changed, 16 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/fifo
The repeated checks on grbm_soft_reset are unnecessary. Remove them.
Signed-off-by: Ethan Carter Edwards
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c
b/drivers/g
Hello Rob Clark,
Commit 2e6a8a1fe2b2 ("drm/msm: Add VM_BIND ioctl") from Jun 29, 2025
(linux-next), leads to the following Smatch static checker warning:
drivers/gpu/drm/msm/msm_gem_vma.c:596 msm_gem_vm_sm_step_remap()
error: we previously assumed 'vm_bo' could be null (see line 5
On Fri, Aug 01, 2025 at 06:26:04PM +0300, Imre Deak wrote:
> Hi Greg and Shradha,
>
> could you please check the comment below about the 4ad8d57d902f backport
> commit in the v6.1.y stable tree and if you agree with the reasoning why
> it has an issue, then suggest a way to resolve it?
>
> Also,
1 - 100 of 101 matches
Mail list logo
