From: Wig Cheng
Mayqueen is a Taiwan-based company primarily focused on the development
of arm64 development boards and e-paper displays.
Signed-off-by: Wig Cheng
Acked-by: Rob Herring (Arm)
Acked-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 fi
Introduce a DRM driver for the Mayqueen Pixpaper e-ink display panel,
which is controlled via SPI. The driver supports a 122x250 resolution
display with XRGB format.
Also, add a MAINTAINERS entry for the Pixpaper driver.
Signed-off-by: LiangCheng Wang
---
MAINTAINERS
The binding is for the Mayqueen Pixpaper e-ink display panel,
controlled via an SPI interface.
Signed-off-by: LiangCheng Wang
Reviewed-by: Rob Herring (Arm)
---
.../bindings/display/mayqueen,pixpaper.yaml| 63 ++
1 file changed, 63 insertions(+)
diff --git a/Documen
This patch series adds support for the Mayqueen Pixpaper e-ink display panel,
controlled via SPI.
The series includes:
- A new vendor-prefix entry for "mayqueen"
- Device tree binding documentation for the Pixpaper panel
- A DRM tiny driver implementation for the Pixpaper panel
- A MAINTAINERS ent
Hi,
On Wed, 30 Jul 2025 21:23:40 -0600, Brigham Campbell wrote:
> Fix bug in novatek-nt35560 driver's nt35560_set_brightness() which
> causes the driver to incorrectly report that it "failed to disable
> display backlight".
>
> Add mipi_dsi_dcs_read_multi() to drm_mipi_dsi.c for improved error
>
On Sat, 2025-08-02 at 11:40 +0900, Simon Richter wrote:
> This driver, for the time being, assumes that the kernel page size is
> 4kB,
> so it fails on loong64 and aarch64 with 16kB pages, and ppc64el with
> 64kB
> pages.
>
> Signed-off-by: Simon Richter
> Cc: sta...@vger.kernel.org
> ---
> driv
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
This driver, for the time being, assumes that the kernel page size is 4kB,
so it fails on loong64 and aarch64 with 16kB pages, and ppc64el with 64kB
pages.
Signed-off-by: Simon Richter
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/xe/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/d
On Tue, Jun 24, 2025 at 11:14:44AM +0530, Jayesh Choudhary wrote:
> Now that we have DBANC framework, remove the connector initialisation code
> as that piece of code is not called if DRM_BRIDGE_ATTACH_NO_CONNECTOR flag
> is used. Only TI K3 platforms consume this driver and tidss (their display
>
On 6/24/25 11:14, Jayesh Choudhary wrote:
With the introduction of DBANC framework, the connector is no longer
initialised in bridge_attach if that flag is set by the display
controller.
This series does some cleanup for legacy !(DRM_BRIDGE_ATTACH_NO_CONNECTOR)
usecase and adds fixes for DRM_BRI
Update driver to use the "multi" variants of MIPI functions which
facilitate improved error handling and cleaner driver code.
Remove information from a comment which was made obsolete by commit
994ea402c767 ("drm/panel: Rename Sony ACX424 to Novatek NT35560"), which
determined that this driver sup
Create mipi_dsi_dcs_read_multi(), which accepts a mipi_dsi_multi_context
struct for improved error handling and cleaner panel driver code.
Create mipi_dsi_dcs_write_var_seq_multi() and
mipi_dsi_generic_write_var_seq_multi() macros which allow MIPI panel
drivers to write non-constant data to displa
Fix bug in nt35560_set_brightness() which causes the function to
erroneously report an error. mipi_dsi_dcs_write() returns either a
negative value when an error occurred or a positive number of bytes
written when no error occurred. The buggy code reports an error under
either condition.
Fixes: 815
Fix bug in novatek-nt35560 driver's nt35560_set_brightness() which
causes the driver to incorrectly report that it "failed to disable
display backlight".
Add mipi_dsi_dcs_read_multi() to drm_mipi_dsi.c for improved error
handling in drivers which use mipi_dsi_dcs_read() multiple times in a
row. Ad
Hi Kaustabh Chakraborty,
This patch series has been merged into the exynos-drm-next branch.
Thanks,
Inki Dae
2025년 7월 7일 (월) 오전 2:30, Kaustabh Chakraborty 님이 작성:
>
> This patch series aims at adding support for Exynos7870's DECON in the
> Exynos7 DECON driver. It introduces a driver data struct
On 6/17/25 00:50, Mario Limonciello wrote:
> From: Mario Limonciello
>
> A variety of issues both in function and in power consumption have been
> raised as a result of devices not being put into a low power state when
> the system is powered off.
>
> There have been some localized changes[1] to
We've discussed a number of times of how some heap names are bad, but
not really what makes a good heap name.
Let's document what we expect the heap names to look like.
Reviewed-by: Andrew Davis
Reviewed-by: Bagas Sanjaya
Signed-off-by: Maxime Ripard
---
Changes in v4:
- Dropped *all* the cach
On 18/07/2025 15:49, Adrián Larumbe wrote:
> On 16.05.2025 16:49, Lukas Zapolskas wrote:
>> From: Adrián Larumbe
>>
>> The sampler aggregates counter and set requests coming from userspace
>> and mediates interactions with the FW interface, to ensure that user
>> sessions cannot override the globa
On 18/07/2025 16:01, Adrián Larumbe wrote:
> On 16.05.2025 16:49, Lukas Zapolskas wrote:
>> The sampler must disable and re-enable counter sampling around suspends,
>> and must re-program the FW interface after a reset to avoid losing
>> data.
>>
>> Signed-off-by: Lukas Zapolskas
>> ---
>> dri
On 18/07/2025 16:19, Adrián Larumbe wrote:
> Hi Lucas, another missing remark from the original review,
>
> On 16.05.2025 16:49, Lukas Zapolskas wrote:
>> This patch implements the PANTHOR_PERF_CONTROL ioctl series, and
>> a PANTHOR_GET_UOBJ wrapper to deal with the backwards and forwards
>> co
On 23-07-25, 11:49, Tomi Valkeinen wrote:
> Hi Vinod,
>
> (I accidentally sent my mail only to you. List added here).
>
> On 23/07/2025 10:36, Tomi Valkeinen wrote:
> > Hi Vinod,
> >
> > On 27/06/2025 02:32, Vinod Koul wrote:
> >> On 18-06-25, 12:59, Tomi Valkeinen wrote:
> >>> The code in cdns-
Hi Vinod,
(I accidentally sent my mail only to you. List added here).
On 23/07/2025 10:36, Tomi Valkeinen wrote:
> Hi Vinod,
>
> On 27/06/2025 02:32, Vinod Koul wrote:
>> On 18-06-25, 12:59, Tomi Valkeinen wrote:
>>> The code in cdns-dphy has probably been part of a DSI driver in the
>>> past. R
On 07.07.2025 17:04, Caterina Shablia wrote:
> From: Asahi Lina
>
> drm_gpuva objects have a flags field. Currently, this can be managed by
> drivers out-of-band, without any special handling in drm_gpuvm.
>
> To be able to introduce flags that do affect the logic in the drm_gpuvm
> core, we need
On 07.07.2025 17:04, Caterina Shablia wrote:
> From: Boris Brezillon
>
> We are going to add flags/properties that will impact the VA merging
> ability. Instead of sprinkling tests all over the place in
> __drm_gpuvm_sm_map(), let's add a helper aggregating all these checks
> can call it for every
On Mon, Jul 21, 2025 at 01:57:26PM GMT, Mario Limonciello wrote:
> From: Mario Limonciello
>
> The boot_display attribute is currently created by PCI core, but the
> main reason it exists is for userspace software that interacts with
> drm to make decisions. Move the attribute to DRM.
>
> This a
From: Mario Limonciello
The boot_display attribute is currently created by PCI core, but the
main reason it exists is for userspace software that interacts with
drm to make decisions. Move the attribute to DRM.
This also fixes a compilation failure when compiled without
CONFIG_VIDEO on sparc.
S
From: Mario Limonciello
Shortly after the series for introducing boot_display was merged
Manivannan Sadhasivam suggested that it's better not to introduce
new top level PCI attributes where possible.
He proposed that the boot_display attribute should be provided by DRM
instead and that userspace
Hi,
On Sun, Jul 20, 2025 at 4:19 AM Diogo Ivo wrote:
>
> On 7/20/25 8:50 AM, Brigham Campbell wrote:
> > On Sat Jul 19, 2025 at 11:10 AM MDT, Diogo Ivo wrote:
> >>> nit: can just be this:
> >>>
> >>> struct mipi_dsi_multi_context dsi_ctx = {};
> >>
> >> I am not an expert here but I was under the
On 11/06/2025 00:45, Chia-I Wu wrote:
> On Mon, Jun 2, 2025 at 7:34 AM Karunika Choo wrote:
>>
>> Mali-Gx20 and Mali-Gx25 deprecates the use of FLUSH_MEM and FLUSH_PT
>> MMU_AS commands in favour of cache maintenance via
>> GPU_COMMAND's FLUSH_CACHES and FLUSH_PA_RANGE.
>>
>> They also introduce t
On 23/06/2025 11:23, Steven Price wrote:
> On 02/06/2025 15:32, Karunika Choo wrote:
>> As the FLUSH_MEM and FLUSH_PT commands are deprecated in GPUs from
>> Mali-Gx20 onwards, this patch adds support for performing cache
>> maintenance via the FLUSH_CACHES command in GPU_CONTROL, in place of
>
>
On 11/06/2025 00:42, Chia-I Wu wrote:
> On Mon, Jun 2, 2025 at 7:42 AM Karunika Choo wrote:
>>
>> As the FLUSH_MEM and FLUSH_PT commands are deprecated in GPUs from
>> Mali-Gx20 onwards, this patch adds support for performing cache
>> maintenance via the FLUSH_CACHES command in GPU_CONTROL, in pla
On 11/06/2025 00:32, Chia-I Wu wrote:
> On Mon, Jun 2, 2025 at 8:16 AM Karunika Choo wrote:
>>
>> This patch replaces the panthor_model structure with a simple switch
>> case based on the product_id which is in the format of:
>> ((arch_major << 24) | product_major)
>>
>> This simplifies co
On 11/06/2025 00:12, Chia-I Wu wrote:
> On Mon, Jun 2, 2025 at 7:33 AM Karunika Choo wrote:
>>
>> This patch provides an initialization framework for multiple Mali GPUs
>> by introducing a GPU support look-up table. Each entry contains, at
>> minimum, the architecture major version of the GPU, and
Hello Steve,
Thanks for taking a look. Looks like my rebase wasn't great, and I missed a
patch
removing some of the GEM functions. Will get that fixed.
Kind regards,
Lukas
On 20/06/2025 16:28, Steven Price wrote:
> Hi Lukas,
>
> I was going to try testing this out, but it doesn't look functi
On 18/07/2025 04:34, Adrián Larumbe wrote:
> On 16.05.2025 16:49, Lukas Zapolskas wrote:
>> To allow for combining the requests from multiple userspace clients, an
>> intermediary layer between the HW/FW interfaces and userspace is
>> created, containing the information for the counter requests
On 18/07/2025 04:10, Adrián Larumbe wrote:
> On 16.05.2025 16:49, Lukas Zapolskas wrote:
>> Added the panthor_perf system initialization and unplug code to allow
>> for the handling of userspace sessions to be added in follow-up
>> patches.
>>
>> Signed-off-by: Lukas Zapolskas
>> ---
>> driver
On 18/07/2025 16:11, Adrián Larumbe wrote:
> Hi Lucas, forgot to add one comment in the previous patch review,
>
> On 16.05.2025 16:49, Lukas Zapolskas wrote:
>> This change adds the IOCTL to query data about the performance counter
>> setup. Some of this data was available via previous DEV_QUE
On 18/07/2025 03:52, Adrián Larumbe wrote:
> On 16.05.2025 16:49, Lukas Zapolskas wrote:
>> This change adds the IOCTL to query data about the performance counter
>> setup. Some of this data was available via previous DEV_QUERY calls,
>> for instance for GPU info, but exposing it via PERF_INFO
>
Hello Adrián,
Thanks for taking a look!
On 18/07/2025 03:43, Adrián Larumbe wrote:
> Hi Lucas,
>
> On 16.05.2025 16:49, Lukas Zapolskas wrote:
>> This patch extends the DEV_QUERY ioctl to return information about the
>> performance counter setup for userspace, and introduces the new
>> ioctl D
On Sun, 20 Jul 2025 17:33:07 +0530, Kaustabh Chakraborty wrote:
> Samsung AMS561RA01 is an AMOLED panel, using the Samsung S6E8AA5X01 MIPI
> DSI panel controller. Document the compatible and devicetree properties
> of this hardware. It has a reset GPIO and two voltage regulators.
>
> Acked-by: C
Samsung AMS561RA01 is an AMOLED panel, using the Samsung S6E8AA5X01 MIPI
DSI controller. Implement a basic panel driver for such panels.
The driver also initializes a backlight device, which works by changing
the panel's gamma values and aid brightness levels appropriately, with
the help of look-u
Samsung AMS561RA01 is an AMOLED panel, using the Samsung S6E8AA5X01 MIPI
DSI panel controller. Document the compatible and devicetree properties
of this hardware. It has a reset GPIO and two voltage regulators.
Acked-by: Conor Dooley
Signed-off-by: Kaustabh Chakraborty
---
.../panel/samsung,s6e
1 - 100 of 5403 matches
Mail list logo
