When PAGE_SIZE 4096, MAX_PAGE_ORDER 10, 64bit machine,
change size limit into 3GB and then create a udmabuf,
current ubuf->folios alloc from kmalloc_array will trigger this
warn and fail create:
[ 4080.876581] [ cut here ]
[ 4080.876843] WARNING: CPU: 3 PID: 2015 at mm/page
Hello all,
On 2024-07-17 08:29, Dragan Simic wrote:
From: Ondrej Jirman
After a suspend and resume cycle, ISP1 stops receiving data, as
observed
on the Pine64 PinePhone Pro, which is based on the Rockchip RK3399 SoC.
Re-initializing DPHY during the PHY power-on, if the SoC variant
supports
On Tue, Jul 16, 2024 at 10:10 PM Alex Deucher wrote:
>
> Does the attached partial revert fix it?
>
> Alex
>
Yes, thanks.
Tested-by: Mikhail Gavrilov
--
Best Regards,
Mike Gavrilov.
From: Ondrej Jirman
After a suspend and resume cycle, ISP1 stops receiving data, as observed
on the Pine64 PinePhone Pro, which is based on the Rockchip RK3399 SoC.
Re-initializing DPHY during the PHY power-on, if the SoC variant supports
initialization, fixes this issue.
[ dsimic: Added more de
From: Hsiao Chien Sung
Support "None" alpha blending mode on MediaTek's chips.
Reviewed-by: CK Hu
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drive
From: Hsiao Chien Sung
Support "Pre-multiplied" and "None" blend mode on MediaTek's chips by
adding correct blend mode property when the planes init.
Before this patch, only the "Coverage" mode (default) is supported.
For more information, there are three pixel blend modes in DRM driver:
"None",
From: Hsiao Chien Sung
Support "Pre-multiplied" alpha blending mode in Mixer.
Before this patch, only the coverage mode is supported.
To replace the default setting that is set in mtk_ethdr_config(),
we change mtk_ddp_write_mask() to mtk_ddp_write(), and this change will
also reset the NON_PREMU
From: Hsiao Chien Sung
Support "None" alpha blending mode on MediaTek's chips.
Reviewed-by: AngeloGioacchino Del Regno
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_ethdr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_
From: Hsiao Chien Sung
Support "Pre-multiplied" alpha blending mode on in OVL.
Before this patch, only the "coverage" mode is supported.
As whether OVL_CON_CLRFMT_MAN bit is enabled, (3 << 12)
means different formats in the datasheet. To prevent
misunderstandings going forward, instead of reusin
Support "Pre-multiplied" and "None" blend mode on MediaTek's chips by
adding correct blend mode property when the planes init.
Before this patch, only the "Coverage" mode (default) is supported.
Signed-off-by: Hsiao Chien Sung
---
Changes in v4:
- Add more information to the commit message
- Link
AMDGPU_GEM_CREATE_GFX12_DCC is set on 90% of all memory allocations, and
almost all of them are not displayable. Shouldn't we use a different way to
indicate that we need a non-power-of-two alignment, such as looking at the
alignment field directly?
Marek
On Tue, Jul 16, 2024, 11:45 Arunpravin Pa
On 7/16/24 9:50 PM, Michael Walle wrote:
Thank you for testing and keeping up with this. I will wait for more
feedback if there is any (Frieder? Lucas? Michael?). If there are no
objections, then I can merge it in a week or two ?
I'll try to use your approach on the tc358775. Hopefully, I'll fi
On Wed, 17 Jul 2024 at 02:15, Abhinav Kumar wrote:
>
>
>
> On 7/16/2024 4:10 PM, Dmitry Baryshkov wrote:
> > On Wed, 17 Jul 2024 at 01:43, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 7/16/2024 2:50 PM, Rob Clark wrote:
> >>> On Tue, Jul 16, 2024 at 2:45 PM Abhinav Kumar
> >>> wrote:
>
Hi Jessica,
On 12/07/2024 23:39, Jessica Zhang wrote:
On 6/30/2024 11:36 AM, Caleb Connolly wrote:
Some panels like the Samsung AMB655X use long write commands for all
non-standard messages and do not work when trying to use the appropriate
command type.
Support these panels by introducing a
On 7/16/2024 4:10 PM, Dmitry Baryshkov wrote:
On Wed, 17 Jul 2024 at 01:43, Abhinav Kumar wrote:
On 7/16/2024 2:50 PM, Rob Clark wrote:
On Tue, Jul 16, 2024 at 2:45 PM Abhinav Kumar wrote:
On 7/15/2024 12:51 PM, Rob Clark wrote:
On Mon, Jul 1, 2024 at 12:43 PM Dmitry Baryshkov
wro
On Wed, 17 Jul 2024 at 01:43, Abhinav Kumar wrote:
>
>
>
> On 7/16/2024 2:50 PM, Rob Clark wrote:
> > On Tue, Jul 16, 2024 at 2:45 PM Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 7/15/2024 12:51 PM, Rob Clark wrote:
> >>> On Mon, Jul 1, 2024 at 12:43 PM Dmitry Baryshkov
> >>> wrote:
>
>
On Wed, 17 Jul 2024 at 01:40, Abhinav Kumar wrote:
>
>
>
> On 6/24/2024 2:13 PM, Dmitry Baryshkov wrote:
> > Historically CRTC resources (LMs and CTLs) were assigned in
> > dpu_crtc_atomic_begin(). The commit 9222cdd27e82 ("drm/msm/dpu: move hw
> > resource tracking to crtc state") simply moved re
On 6/24/2024 2:13 PM, Dmitry Baryshkov wrote:
The DPU driver isn't expected to be used without an IOMMU. Thus the
aspace will be always present. Not to mention that mdp4/mdp5 drivers
call msm_framebuffer_iova() without such checks, as the whole
msm_framebuffer layer is expected to support both
On 7/16/2024 2:50 PM, Rob Clark wrote:
On Tue, Jul 16, 2024 at 2:45 PM Abhinav Kumar wrote:
On 7/15/2024 12:51 PM, Rob Clark wrote:
On Mon, Jul 1, 2024 at 12:43 PM Dmitry Baryshkov
wrote:
On Fri, Jun 28, 2024 at 02:48:47PM GMT, Abhinav Kumar wrote:
There is no recovery mechanism in p
On 6/24/2024 2:13 PM, Dmitry Baryshkov wrote:
Historically CRTC resources (LMs and CTLs) were assigned in
dpu_crtc_atomic_begin(). The commit 9222cdd27e82 ("drm/msm/dpu: move hw
resource tracking to crtc state") simply moved resources to
struct dpu_crtc_state, without changing the code sequenc
On 7/13/2024 2:49 AM, Dmitry Baryshkov wrote:
On Sat, 13 Jul 2024 at 03:25, Abhinav Kumar wrote:
On 7/12/2024 4:11 PM, Dmitry Baryshkov wrote:
On Fri, 12 Jul 2024 at 22:41, Abhinav Kumar wrote:
On 6/24/2024 2:13 PM, Dmitry Baryshkov wrote:
The commit b954fa6baaca ("drm/msm/dpu: Refact
On Tue, Jul 16, 2024 at 02:35:11PM +0200, Christian König wrote:
> Instead of a TTM reference grab a GEM reference whenever necessary.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 8
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 7 ++-
> 2
On Tue, Jul 16, 2024 at 2:45 PM Abhinav Kumar wrote:
>
>
>
> On 7/15/2024 12:51 PM, Rob Clark wrote:
> > On Mon, Jul 1, 2024 at 12:43 PM Dmitry Baryshkov
> > wrote:
> >>
> >> On Fri, Jun 28, 2024 at 02:48:47PM GMT, Abhinav Kumar wrote:
> >>> There is no recovery mechanism in place yet to recover
On Tue, Jul 16, 2024 at 09:06:30AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> -ENODEV is used to signify that there is no zap shader for the platform,
> and the CPU can directly take the GPU out of secure mode. We want to
> use this return code when there is no zap-shader node. But not when
On 7/15/2024 12:51 PM, Rob Clark wrote:
On Mon, Jul 1, 2024 at 12:43 PM Dmitry Baryshkov
wrote:
On Fri, Jun 28, 2024 at 02:48:47PM GMT, Abhinav Kumar wrote:
There is no recovery mechanism in place yet to recover from mmu
faults for DPU. We can only prevent the faults by making sure there
i
On Tue, Jul 16, 2024 at 02:35:19PM +0200, Christian König wrote:
> Prevent drivers from using this directly.
>
This is a good change. Early on in Xe, our reference counting for BOs
was flawed (and incorrect) due to confusion between GEM ref count and
TTM ref count.
Is there any way we can just e
On 7/1/2024 12:43 PM, Dmitry Baryshkov wrote:
On Fri, Jun 28, 2024 at 02:48:47PM GMT, Abhinav Kumar wrote:
There is no recovery mechanism in place yet to recover from mmu
faults for DPU. We can only prevent the faults by making sure there
is no misconfiguration.
Rate-limit the snapshot captu
On 7/1/2024 1:41 PM, Rob Clark wrote:
On Fri, Jun 28, 2024 at 2:49 PM Abhinav Kumar wrote:
Introduce a new API msm_iommu_disp_new() for display use-cases.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/msm_iommu.c | 26 ++
drivers/gpu/drm/msm/msm_mmu.h |
On Fri, Jun 21, 2024 at 10:45 PM Douglas Anderson wrote:
> At shutdown if you've got a _properly_ coded DRM modeset driver then
> you'll get these two warnings at shutdown time:
>
> Skipping disable of already disabled panel
> Skipping unprepare of already unprepared panel
>
> These warnings
Implement drm object's status callback.
Also, we consider a PRIME imported BO to be resident if its matching
dma_buf has an open attachment, which means its backing storage had already
been allocated.
Signed-off-by: Adrián Larumbe
Reviewed-by: Liviu Dudau
---
drivers/gpu/drm/panthor/panthor_ge
Drawing from the FW-calculated values in the previous commit, we can
increase the numbers for an open file by collecting them from finished jobs
when updating their group synchronisation objects.
Display of fdinfo key-value pairs is governed by a flag that is by default
disabled in the present com
This commit introduces a DRM device sysfs attribute that lets UM control
the job accounting status in the device. The knob variable had been brought
in as part of a previous commit, but now we're able to fix it manually.
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/panthor/panthor_drv.c | 3
Enable calculations of job submission times in clock cycles and wall
time. This is done by expanding the boilerplate command stream when running
a job to include instructions that compute said times right before an after
a user CS.
Those numbers are stored in the queue's group's sync objects BO, r
This patch series enables userspace utilities like gputop and nvtop to
query a render context's fdinfo file and figure out rates of engine
and memory utilisation.
Previous discussion can be found at
https://lore.kernel.org/dri-devel/dqhnxhgho6spfh7xhw6yvs2iiqeqzeg63e6jqqpw2g7gkrfphn@dojsixyl4esv/
On Mon, May 20, 2024 at 03:18:36PM GMT, Clayton Craft wrote:
> This panel is found on some laptops e.g., variants of the Thinkpad X13s.
>
> Signed-off-by: Clayton Craft
> ---
> drivers/gpu/drm/panel/panel-edp.c | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Dmitry Baryshkov
It had s
> Thank you for testing and keeping up with this. I will wait for more
> feedback if there is any (Frieder? Lucas? Michael?). If there are no
> objections, then I can merge it in a week or two ?
> >>>
> >>> I'll try to use your approach on the tc358775. Hopefully, I'll find
> >>> som
On 7/12/24 9:16 AM, Michael Walle wrote:
Hi Marek,
Hi,
Thank you for testing and keeping up with this. I will wait for more
feedback if there is any (Frieder? Lucas? Michael?). If there are no
objections, then I can merge it in a week or two ?
I'll try to use your approach on the tc358775.
On 7/10/24 5:33 PM, Rob Herring (Arm) wrote:
On Mon, 08 Jul 2024 17:01:13 +0200, Marek Vasut wrote:
Document default DP port preemphasis configurable via new DT property
"toshiba,pre-emphasis". This is useful in case the DP link properties
are known and starting link training from preemphasis s
On 7/11/24 5:57 PM, Marek Szyprowski wrote:
On 11.07.2024 17:38, Marek Vasut wrote:
On 6/26/24 10:02 AM, Michael Walle wrote:
On Wed Jun 26, 2024 at 5:21 AM CEST, Marek Vasut wrote:
Thank you for testing and keeping up with this. I will wait for more
feedback if there is any (Frieder? Lucas? M
The DYNDBG_CLASSMAP_DEFINE expects a list of classnames, and
maps them to consecutive classids starting at _base. That
1- list-of-classnames can be syntactically replaced by a
2- designated-initializers-list/map.
But this creates ambiguity. The 1st thing the macro does:
static const char *_va
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
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
Invoke DYNDBG_CLASSMAP_PARAM to hook drm.debug (__drm_debug) to the
DRM_UT_* classmap, replacing the ad-hoc wiring previously doing it.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/drm_print.c | 8 ++--
include/drm/drm_print.h | 6 --
2 files changed, 6 insertions(+), 8 deletions(-)
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.
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
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
Several tests are dependent upon config choices. Lets avoid failing
where that is noise.
The KCONFIG_CONFIG var exists to convey the config-file around. If
the var names a file, read it and extract the relevant CONFIG items,
and use them to skip the dependent tests, thus avoiding the fails that
w
reword the classmaps-api section to better explain how it supports
DRM, and (a little bit) to steer clear of designated-inits in the
_DEFINE description.
probably just squash this back in
Signed-off-by: Jim Cromie
---
.../admin-guide/dynamic-debug-howto.rst | 64 +++
1 fil
end of official submission.
Time for some quality CI
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index d0aa277fc3bf..c508c0834641 100644
--- a/drivers/gpu/drm/Kconfi
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
With CONFIG_DRM_USE_DYNAMIC_DEBUG=y, I'm getting an unused variable
warning/error on 'category', though the usage follows immediately, in
drm_debug_enabled().
This drops the local var and refs the field directly in the
macro-call, which avoids the warning. For static-key optimized
dyndbg, the mac
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 | 2 ++
1 file changed, 2 insertions(+)
diff --git a/driv
New fn validates parsing and effect of queries using combinations of
commas and spaces to delimit the tokens.
It manipulates pr-debugs in builtin module/params, so might have deps
I havent foreseen on odd configurations.
Signed-off-by: Jim Cromie
---
.../selftests/dynamic_debug/dyndbg_selftest.
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
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
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 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
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 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
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(), it modifies pr_debug flags in a few
builtins (ini
Remove the '-v' arg from the tests in test_mod_submod().
Setting V=1 in the environment turns it back on, for all tests.
Signed-off-by: Jim Cromie
---
.../dynamic_debug/dyndbg_selftest.sh | 23 +--
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/tools/tes
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/tiny/simpledrm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/tiny/si
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
Describe the 3 API macros providing dynamic_debug's classmaps
DYNDBG_CLASSMAP_DEFINE - create, exports a module's 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
cc:
Invoke DRM_CLASSMAP_USE from xe_drm_client.c. When built with
CONFIG_DRM_USE_DYNAMIC_DEBUG=y, this tells dydnbg that Xe uses
has drm.debug calls.
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_clie
dyndbg's CLASSMAP-v1 api was broken; DECLARE_DYNDBG_CLASSMAP tried to
do too much. Its replaced by DRM_CLASSMAP_DEFINE, which creates &
EXPORTs the classmap when CONFIG_DRM_USE_DYNAMIC_DEBUG=y, for direct
reference by drivers.
The drivers still use DECLARE_DYNDBG_CLASSMAP for now, so they still
r
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
Change function's 1st arg-type, and deref in the caller.
The fn doesn't need any other fields in the struct.
no functional change.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_d
When writing queries to >control, flags are parsed 1st, since they are
the only required field. So if the flags draw an error, then keyword
errors aren't reported. This can be mildly confusing/annoying, so
explain it instead.
This note could be moved up to just after the grammar id's the flags,
This does basic testing of classmaps using '%' separated
multi-queries. It modprobes test_dynamic_debug with several classes
enabled, and counts to verify that the expected sites show the
enablement in the control file.
Signed-off-by: Jim Cromie
---
.../dynamic_debug/dyndbg_selftest.sh
Add mention of comma and percent delimiters into the respective
paragraphs describing their equivalents: space and newline.
Signed-off-by: Jim Cromie
---
.../admin-guide/dynamic-debug-howto.rst| 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/Documen
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.
if (cond && (drm_dbg("expr-form"),1)) {
... do some more stuff
}
Fix it by changing __dynamic_func_ca
Incorrectly spelled CFLAGS- failed to add -DDYNAMIC_DEBUG_MODULE,
which broke builds with:
CONFIG_DRM_USE_DYNAMIC_DEBUG=y
CONFIG_DYNAMIC_DEBUG_CORE=y
CONFIG_DYNAMIC_DEBUG=n
Also add subdir-ccflags so that all drivers pick up the addition.
Fixes: 84ec67288c10 ("drm_print: wrap drm_*_dbg in dyndbg
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="
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
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
DECLARE_DYNDBG_CLASSMAP() has a design error; its usage fails a basic
K&R rule: "define once, refer many times".
It is used across DRM core & drivers, each use re-defines the classmap
understood by that module; and all must match for the modules to
respond together when DRM.debug categories are en
Split api-fn: param_set_dyndbg_classes(), adding modname param and
passing NULL in from api-fn.
The new arg allows caller to specify that only one module is affected
by a prdbgs update. This selectivity will be used later to narrow the
scope of changes made.
no functional change.
Signed-off-by:
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
When modprobing a module, dyndbg currently logs/says "add-module", and
then "skipping" if the module has no prdbgs. Instead just check 1st
and return quietly.
no functional change
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
di
move the DYNDBG_CLASSMAP_PARAM macro from test-dynamic-debug.c into
the header, and refine it, by distinguishing the 2 use cases:
1.DYNDBG_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.DYNDBG_CLASSMAP_PARAM
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
---
lib/dynamic_debug.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-
Remove the NAMED class types; 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 anyone else, so reduce test-surfac
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
ARRAY_SIZE works here, since array decl is complete.
no functional change
Signed-off-by: Jim Cromie
---
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
index 2b0057058ecf..e458d4b8
In ddebug_apply_class_bitmap(), check for actual changes to the bits
before announcing them, to declutter logs.
no functional change.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dyna
Add param: query_module to ddebug_apply_class_bitmap(), and pass it
thru to _ddebug_queries(), replacing NULL with query_module. This
allows its caller to update just one module, or all (as currently).
We'll use this later to propagate drm.debug to each USEr as they're
modprobed.
No functional c
Classmaps are stored in an elf section/array, but are individually
list-linked onto dyndbg's per-module ddebug_table for operation.
This is unnecessary; even when ddebug_attach_classmap() is handling
the builtin section (with classmaps for multiple builtin modules), its
contents are ordered, so a
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
A more careful reading of logging output from test_dynamic_debug.ko
reveals:
lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing
categories\n"
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_ca
resending to fix double-copies of a dozen patches.
added 2 squash-ins to address Ville's designated-initializer comment.
This fixes dynamic-debug support for DRM.debug, added via classmaps.
commit bb2ff6c27bc9 (drm: Disable dynamic debug as broken)
CONFIG_DRM_USE_DYNAMIC_DEBUG=y was marked broken
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
---
Documentation/admin-guide/dynamic-debug-howto.rst | 10 +-
1 file ch
On Tue, Jul 16, 2024 at 06:48:12PM GMT, Thomas Zimmermann wrote:
> Hi
>
> Am 16.07.24 um 18:35 schrieb Dmitry Baryshkov:
> > On Tue, 16 Jul 2024 at 18:58, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 27.02.24 um 23:40 schrieb Dmitry Baryshkov:
> > > > Hello,
> > > >
> > > > We are currently
Does the attached partial revert fix it?
Alex
On Wed, Jul 10, 2024 at 3:03 AM Mikhail Gavrilov
wrote:
>
> On Wed, Jul 10, 2024 at 12:01 PM Mikhail Gavrilov
> wrote:
> >
> > On Tue, Jul 9, 2024 at 7:48 PM Rodrigo Siqueira Jordao
> > wrote:
> > > Hi,
> > >
> > > I also tried it with 6900XT. I go
On Tue, Jul 16, 2024 at 07:01:17PM GMT, Tejas Vipin wrote:
> Introduce 2 new macros, DSI_CTX_NO_OP and MIPI_DSI_ADD_MULTI_VARIANT.
>
> DSI_CTX_NO_OP calls a function only if the context passed to it hasn't
> encountered any errors. It is a generic form of what mipi_dsi_msleep
> does.
>
> MIPI_DSI
On Tue, Jul 16, 2024 at 09:06:30AM GMT, Rob Clark wrote:
> From: Rob Clark
>
> -ENODEV is used to signify that there is no zap shader for the platform,
> and the CPU can directly take the GPU out of secure mode. We want to
> use this return code when there is no zap-shader node. But not when
>
1 - 100 of 187 matches
Mail list logo
