[PATCH v5 28/33] drm_print: refine drm_debug_enabled for jump-label
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. The legacy version always checks the bits.
2. is privileged, for use by __drm_dbg(), __drm_dev_dbg(), which do an
early return unless the category is enabled. For dyndbg builds, debug
callsites are selectively "pre-enabled", so __drm_debug_enabled()
short-circuits to true there. Remaining callers of 1 may be able to
use 2, case by case.
3. is 1st wrapped in a macro, with a pr_debug, which reports each
usage in /proc/dynamic_debug/control, making it observable in the
logs. The macro lets the pr_debug see the real caller, not an inline
function.
When plugged into 1, 3 identified ~10 remaining callers of the
function, leading to the follow-on cleanup patch, and would allow
activating the pr_debugs, estimating the callrate, and the potential
savings by using the wrapper macro. It is unused ATM, but it fills
out the picture.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/drm_print.c | 4 ++--
include/drm/drm_print.h | 28
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 29a29949ad0b..cb203d63b286 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -285,7 +285,7 @@ void __drm_dev_dbg(const struct device *dev, enum
drm_debug_category category,
struct va_format vaf;
va_list args;
- if (!drm_debug_enabled(category))
+ if (!__drm_debug_enabled(category))
return;
va_start(args, format);
@@ -308,7 +308,7 @@ void ___drm_dbg(enum drm_debug_category category, const
char *format, ...)
struct va_format vaf;
va_list args;
- if (!drm_debug_enabled(category))
+ if (!__drm_debug_enabled(category))
return;
va_start(args, format);
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index dfdd81c3287c..7631b5fb669e 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -321,11 +321,39 @@ enum drm_debug_category {
DRM_UT_DRMRES
};
+/*
+ * 3 name flavors of drm_debug_enabled:
+ * drm_debug_enabled - public/legacy, always checks bits
+ * _drm_debug_enabled - instrumented to observe call-rates, est overheads.
+ * __drm_debug_enabled - privileged - knows jump-label state, can short-circuit
+ */
static inline bool drm_debug_enabled(enum drm_debug_category category)
{
return unlikely(__drm_debug & BIT(category));
}
+/*
+ * Wrap fn in macro, so that the pr_debug sees the actual caller, not
+ * the inline fn. Using this name creates a callsite entry / control
+ * point in /proc/dynamic_debug/control.
+ */
+#define _drm_debug_enabled(category) \
+ ({ \
+ pr_debug("todo: maybe avoid via dyndbg\n"); \
+ drm_debug_enabled(category);\
+ })
+
+#if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
+/*
+ * dyndbg is wrapping the drm.debug API, so as to avoid the runtime
+ * bit-test overheads of drm_debug_enabled() in those api calls.
+ * In this case, executed callsites are known enabled, so true.
+ */
+#define __drm_debug_enabled(category) true
+#else
+#define __drm_debug_enabled(category) drm_debug_enabled(category)
+#endif
+
/*
* struct device based logging
*
--
2.37.1
[PATCH v5 14/33] dyndbg: add DECLARE_DYNDBG_CLASSMAP macro
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 ddebug_class_map:
- maps approved class-names to class_ids used in module,
by array order. forex: DRM_UT_*
- class-name vals allow validation of "class FOO" queries
using macro is opt-in
- enum class_map_type - determines interface, behavior
Each module has its own .class_id space, and only known class-names
will be authorized for a manipulation. Only DRM stuff should know this:
:#> echo class DRM_UT_CORE +p > control # across all modules
pr_debugs (with default class_id) are still controllable as before.
DECLARE_DYNDBG_CLASSMAP(_var, _maptype, _base, classes...) is::
_var: name of the static struct var. user passes to module_param_cb()
if they want a sysfs node.
_maptype: this is hard-coded to DD_CLASS_TYPE_DISJOINT_BITS for now.
_base: usually 0, it allows splitting 31 classes into subranges, so
that multiple classes / sysfs-nodes can share the module's
class-id space.
classes: list of class_name strings, these are mapped to class-ids
starting at _base. This class-names list must have a
corresponding ENUM, with SYMBOLS that match the literals,
and 1st enum val = _base.
enum class_map_type has 4 values, on 2 factors::
- classes are disjoint/independent vs relative/xcontrol interface
doesn't enforce the LEVELS relationship, so you could confusingly have
V3 enabled, but V1 disabled. OTOH, the control iface already allows
infinite tweaking of the underlying callsites; sysfs node readback can
only tell the user what they previously wrote.
2. All dyndbg >control reduces to a query/command, includes +/-, which
is at-root a kernel patching operation with +/- semantics. And the
_NAMES handling exposes it to the user, making it API-adjacent.
And its not just >control where +/- gets used (which is settled), the
new place is with sysfs-nodes exposing _*_NAMES classes, and here its
subtly different.
_DISJOINT_NAMES: is simple, independent
_LEVEL_NAMES: masks-on bits 0 .. N-1, N..max off
# turn on L3,L2,L1 others off
echo +L3 > /sys/module/test_dynamic_debug/parameters/p_level_names
# turn on L2,L1 others off
echo -L3 > /sys/module/test_dynamic_debug/parameters/p_level_names
IOW, the - changes the threshold-on bitpos by 1.
Alternatively, we could treat the +/- as half-duplex, where -L3 turns
off L>2 (and ignores L1), and +L2 would turn on L<=2 (and ignore others).
Signed-off-by: Jim Cromie
---
. revised DD_CLASS_TYPE_{DISJOINT,LEVEL}_* names
. reorder-enum by necessity - _NAMES feature is extra.
---
include/linux/dynamic_debug.h | 56 +++
1 file changed, 56 insertions(+)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index cb4696c91901..71cdc8612257 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -56,6 +56,62 @@ struct _ddebug {
#endif
} __attribute__((aligned(8)));
+enum class_map_type {
+ DD_CLASS_TYPE_DISJOINT_BITS,
+ /**
+* DD_CLASS_TYPE_DISJOINT_BITS: classes are independent, one per bit.
+* expecting hex input. Built for drm.debug, basis for other types.
+*/
+ DD_CLASS_TYPE_LEVEL_NUM,
+ /**
+* DD_CLASS_TYPE_LEVEL_NUM: input is numeric level, 0-N.
+* N turns on just bits N-1 .. 0, so N=0 turns all bits off.
+*/
+ DD_CLASS_TYPE_DISJOINT_NAMES,
+ /**
+* DD_CLASS_TYPE_DISJOINT_NAMES: input is a CSV of [+-]CLASS_NAMES,
+* classes are independent, like _DISJOINT_BITS. Model user
+* would be /sys/module/drm/parameters/debug_categories.
+*/
+ DD_CLASS_TYPE_LEVEL_NAMES,
+ /**
+* DD_CLASS_TYPE_LEVEL_NAMES: input is a CSV of [+-]CLASS_NAMES,
+* intended for names like: INFO,DEBUG,TRACE, with a module prefix
+* avoid EMERG,ALERT,CRIT,ERR,WARNING: they're not debug
+*/
+};
+
+struct ddebug_class_map {
+ struct list_head link;
+ struct module *mod;
+ const char *mod_name; /* needed for builtins */
+ const char **class_names;
+ const int length;
+ const int base; /* index of 1st .class_id, allows split/shared
space */
+ enum class_map_type map_type;
+};
+
+/**
+ * DECLARE_DYNDBG_CLASSMAP - declare classnames known by a module
+ * @_var: a struct ddebug_class_map, passed to module_param_cb
+ * @_type: enum class_map_type, chooses bits/verbose, numeric/symbolic
+ * @_base: offset of 1st class-name. splits .class_id space
+ * @classes: class-names used to control class'd prdbgs
+ */
+#define DECLARE_DYNDBG_CLASSMAP(_var, _maptype, _base, ...)\
+ static const char *_var##_classnames[] = { __VA_ARGS__ }; \
[PATCH v5 29/33] drm_print: prefer bare printk KERN_DEBUG on generic fn
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 generic, serves multiple drm users.
it is soft-wired on currently by #define DEBUG
could accidentally: #> echo -p > /proc/dynamic_debug/control
2- optional "decorations" by dyndbg are unhelpful/misleading here,
they describe only the generic site, not end users
IOW, 1,2 are unhelpful at best, and possibly confusing.
reverting yields a nominal data and text shrink:
textdata bss dec hex filename
462583 36604 54592 553779 87333 /kernel/drivers/gpu/drm/drm.ko
462515 36532 54592 553639 872a7 -dirty/kernel/drivers/gpu/drm/drm.ko
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/drm_print.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index cb203d63b286..ec477c44a784 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -23,8 +23,6 @@
* Rob Clark
*/
-#define DEBUG /* for pr_debug() */
-
#include
#include
@@ -185,7 +183,8 @@ EXPORT_SYMBOL(__drm_printfn_info);
void __drm_printfn_debug(struct drm_printer *p, struct va_format *vaf)
{
- pr_debug("%s %pV", p->prefix, vaf);
+ /* pr_debug callsite decorations are unhelpful here */
+ printk(KERN_DEBUG "%s %pV", p->prefix, vaf);
}
EXPORT_SYMBOL(__drm_printfn_debug);
--
2.37.1
[PATCH v5 13/33] dyndbg: add __pr_debug_cls for testing
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 least until a
need emerges. ISTM the drm.debug model (macro wrappers inserting enum
const 1st arg) is the baseline approach.
That said, nouveau might want it for easy use in its debug macros. TBD.
NB: it does require a builtin-constant class, __pr_debug_cls(i++, ...)
is disallowed by compiler.
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index b6803f7e818f..cb4696c91901 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -221,6 +221,13 @@ void __dynamic_ibdev_dbg(struct _ddebug *descriptor,
KERN_DEBUG, prefix_str, prefix_type, \
rowsize, groupsize, buf, len, ascii)
+/* for test only, generally expect drm.debug style macro wrappers */
+#define __pr_debug_cls(cls, fmt, ...) do { \
+ BUILD_BUG_ON_MSG(!__builtin_constant_p(cls),\
+"expecting constant class int/enum"); \
+ dynamic_pr_debug_cls(cls, fmt, ##__VA_ARGS__); \
+ } while (0)
+
#else /* !CONFIG_DYNAMIC_DEBUG_CORE */
#include
--
2.37.1
[PATCH v5 25/33] drm_print: wrap drm_*_dbg in dyndbg descriptor factory macro
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 > /proc/dynamic_debug/control CONFIG_DRM_USE_DYNAMIC_DEBUG=y/n is configurable because of the .data footprint cost of per-callsite control; 56 bytes/site * ~2k for i915, ~4k callsites for amdgpu. This is large enough that a kernel builder might not want it. Signed-off-by: Jim Cromie --- drivers/gpu/drm/Kconfig | 12 drivers/gpu/drm/Makefile | 2 ++ include/drm/drm_print.h | 12 3 files changed, 26 insertions(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index f65656df3619..aad2ac5641c1 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -50,6 +50,18 @@ config DRM_DEBUG_MM If in doubt, say "N". +config DRM_USE_DYNAMIC_DEBUG + bool "use dynamic debug to implement drm.debug" + default y + depends on DRM + depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE + depends on JUMP_LABEL + help + Use dynamic-debug to avoid drm_debug_enabled() runtime overheads. + Due to callsite counts in DRM drivers (~4k in amdgpu) and 56 + bytes per callsite, the .data costs can be substantial, and + are therefore configurable. + config DRM_DEBUG_SELFTEST tristate "kselftests for DRM" depends on DRM diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 15fe3163f822..272de137d207 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -3,6 +3,8 @@ # Makefile for the drm device driver. This driver provides support for the # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. +CFLAGS-$(CONFIG_DRM_USE_DYNAMIC_DEBUG) += -DDYNAMIC_DEBUG_MODULE + drm-y := drm_aperture.o drm_auth.o drm_cache.o \ drm_file.o drm_gem.o drm_ioctl.o \ drm_drv.o \ diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h index c429c258c957..2d2cef76b5c1 100644 --- a/include/drm/drm_print.h +++ b/include/drm/drm_print.h @@ -384,8 +384,14 @@ void __drm_dev_dbg(const struct device *dev, enum drm_debug_category category, } \ }) +#if !defined(CONFIG_DRM_USE_DYNAMIC_DEBUG) #define drm_dev_dbg(dev, cat, fmt, ...)\ __drm_dev_dbg(dev, cat, fmt, ##__VA_ARGS__) +#else +#define drm_dev_dbg(dev, cat, fmt, ...)\ + _dynamic_func_call_no_desc(fmt, __drm_dev_dbg, \ + dev, cat, fmt, ##__VA_ARGS__) +#endif /** * DRM_DEV_DEBUG() - Debug output for generic drm code @@ -492,7 +498,13 @@ void ___drm_dbg(enum drm_debug_category category, const char *format, ...); __printf(1, 2) void __drm_err(const char *format, ...); +#if !defined(CONFIG_DRM_USE_DYNAMIC_DEBUG) #define __drm_dbg(fmt, ...)___drm_dbg(fmt, ##__VA_ARGS__) +#else +#define __drm_dbg(cat, fmt, ...) \ + _dynamic_func_call_no_desc(fmt, ___drm_dbg, \ + cat, fmt, ##__VA_ARGS__) +#endif /* Macros to make printk easier */ -- 2.37.1
[PATCH v5 33/33] nouveau: WIP add 2 LEVEL_NUM classmaps for CLI, SUBDEV
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 enablement. WIP.
Then undo the 1-line change that reduced count of prdbgs from 632 to 119.
ie: s/NV_SUBDEV_DBG_##l/NV_DBG_##l/
So heres what happened: new symbol is 15 (or 10), and fails this macro
test, so gets compiled out, and the dev_dbg is excluded.
if (CONFIG_NOUVEAU_DEBUG >= (l) && _subdev->debug >= (l)) \
dev_dbg(_subdev->device->dev, "%s: "f, _subdev->name, ##a); \
I could hack this, by doing (l + base), but base is pretty distant.
OTOH, the whole CONFIG_NOUVEAU_DEBUG check could be reworked; given
that trace is minumum recommended, theres not that many callsites
elided (SPAM only iirc) at compile-time, and dyndbg means keeping them
has "zero" run-cost (and 56 bytes per callsite). So this config item
doesnt do much when DRM_USE_DYNAMIC_DEBUG=y.
So this is a useful place to stop and look around, try to guess which
trail to take..
nouveau has additional debug variables to consider:
drivers/gpu/drm/nouveau/include/nvkm/core/device.h
131:if (_device->debug >= (l)) \
drivers/gpu/drm/nouveau/include/nvkm/core/client.h
39: if (_client->debug >= NV_DBG_##l) \
drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h
54: if (CONFIG_NOUVEAU_DEBUG >= (l) && _subdev->debug >= (l)) \
This is another baby-step, that seems not to break, so lets get a
snapshot.
whats done here:
In nouveau_drm.c, do DECLARE_DYNDBG_CLASSMAP(LEVEL_NUM type) 2x more,
for cli and subdev, right after the drm DECLARE. Adjust base for
each, to share the 0..30 classid-space.
These declare class-names: NV_CLI_DBG_* NV_SUBDEV_DBG_* accordingly.
Note: class-name-space is flat and wide, so super-generic names like
INFO should be prefixed; who could predict what a generic V3 does
across all modules.
s should be included
adjusting the base to avoid each other, and the 0-10
already mapped to drm-debug-categorys (just above this addition).
In nvkm/core/debug.h, add enums to match the names, with initial
values to match the bases.
In nvkm/core/subdev.h, alter (recently added) nvkm_drmdbg_() to use
NV_SUBDEV_DBG_* instead of NV_DBG_*.
NB: in both classmaps, Ive left FATAL..WARN out, they're not really
optional the way INFO..SPAM are; dyndbg shouldn't be able to turn them off.
bash-5.1# modprobe nouveau
[ 966.107833] dyndbg: 3 debug prints in module wmi
[ 966.342188] dyndbg: class[0]: module:nouveau base:15 len:5 ty:1
[ 966.342873] dyndbg: 15: 0 NV_SUBDEV_DBG_OFF
[ 966.343352] dyndbg: 16: 1 NV_SUBDEV_DBG_INFO
[ 966.343912] dyndbg: 17: 2 NV_SUBDEV_DBG_DEBUG
[ 966.33] dyndbg: 18: 3 NV_SUBDEV_DBG_TRACE
[ 966.344938] dyndbg: 19: 4 NV_SUBDEV_DBG_SPAM
[ 966.345402] dyndbg: class[1]: module:nouveau base:10 len:5 ty:1
[ 966.346011] dyndbg: 10: 0 NV_CLI_DBG_OFF
[ 966.346477] dyndbg: 11: 1 NV_CLI_DBG_INFO
[ 966.346989] dyndbg: 12: 2 NV_CLI_DBG_DEBUG
[ 966.347442] dyndbg: 13: 3 NV_CLI_DBG_TRACE
[ 966.347875] dyndbg: 14: 4 NV_CLI_DBG_SPAM
[ 966.348284] dyndbg: class[2]: module:nouveau base:0 len:10 ty:0
[ 966.34] dyndbg: 0: 0 DRM_UT_CORE
[ 966.349310] dyndbg: 1: 1 DRM_UT_DRIVER
[ 966.349694] dyndbg: 2: 2 DRM_UT_KMS
[ 966.350083] dyndbg: 3: 3 DRM_UT_PRIME
[ 966.350482] dyndbg: 4: 4 DRM_UT_ATOMIC
[ 966.351016] dyndbg: 5: 5 DRM_UT_VBL
[ 966.351475] dyndbg: 6: 6 DRM_UT_STATE
[ 966.351899] dyndbg: 7: 7 DRM_UT_LEASE
[ 966.352309] dyndbg: 8: 8 DRM_UT_DP
[ 966.352678] dyndbg: 9: 9 DRM_UT_DRMRES
[ 966.353104] dyndbg: module:nouveau attached 3 classes
[ 966.353759] dyndbg: 119 debug prints in module nouveau
NOTE: it was 632 with previous commit, switching NV_DEBUG to use
NV_SUBDEV_DBG_DEBUG instead of NV_DBG_DEBUG may be the cause.
Signed-off-by: Jim Cromie
---
.../gpu/drm/nouveau/include/nvkm/core/debug.h | 16 +
.../drm/nouveau/include/nvkm/core/subdev.h| 17 ++
drivers/gpu/drm/nouveau/nouveau_drm.c | 7 ++
drivers/gpu/drm/nouveau/nvkm/core/subdev.c| 23 +++
4 files changed, 59 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/core/debug.h
b/drivers/gpu/drm/nouveau/include/nvkm/core/debug.h
index b4a9c7d991ca..6a155a23a3d1 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/core/debug.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/core/debug.h
@@ -9,4 +9,20 @@
#define NV_DBG_TRACE5
#define NV_DBG_PARANOIA 6
#define NV_DBG_SPAM 7
+
+enum nv_cli_dbg_verbose {
+ NV_CLI_DBG_OFF = 10,
+ NV_CLI_DBG_INFO,
+ NV_CLI_DBG_DEBUG,
+ NV_CLI_DBG_TRACE,
+ NV_CLI_DBG_SPAM
+};
+enum nv_subdev_dbg_verbose {
+ NV_SUBDEV_DBG_OFF = 15,
+ NV_SUBDEV_DBG_INFO,
[PATCH v5 32/33] nouveau: adapt NV_DEBUG, NV_ATOMIC to use DRM.debug
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 /proc/dynamic_debug/control | grep class | grep DRIVER | wc
74 7049709
:#> grep nouveau /proc/dynamic_debug/control | grep class | grep ATOMIC | wc
31 3074237
:#> grep nouveau /proc/dynamic_debug/control | grep class | grep KMS | wc
11 1191638
the KMS entries are due to existing uses of drm_dbg_kms().
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/nouveau/nouveau_drv.h | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index b2a970aa9bf4..f266cd6b0405 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -39,6 +39,7 @@
*/
#include
+#include
#include
#include
@@ -264,13 +265,16 @@ void nouveau_drm_device_remove(struct drm_device *dev);
#define NV_WARN(drm,f,a...) NV_PRINTK(warn, &(drm)->client, f, ##a)
#define NV_INFO(drm,f,a...) NV_PRINTK(info, &(drm)->client, f, ##a)
-#define NV_DEBUG(drm,f,a...) do {
\
- if (drm_debug_enabled(DRM_UT_DRIVER)) \
- NV_PRINTK(info, &(drm)->client, f, ##a); \
+#define NV_DRMDBG(cat,c,f,a...) do { \
+ struct nouveau_cli *_cli = (c); \
+ drm_dbg_##cat(_cli->drm->dev, "%s: "f, _cli->name, ##a); \
} while(0)
-#define NV_ATOMIC(drm,f,a...) do {
\
- if (drm_debug_enabled(DRM_UT_ATOMIC)) \
- NV_PRINTK(info, &(drm)->client, f, ##a); \
+
+#define NV_DEBUG(drm,f,a...) do { \
+ NV_DRMDBG(driver, &(drm)->client, f, ##a); \
+} while(0)
+#define NV_ATOMIC(drm,f,a...) do { \
+ NV_DRMDBG(atomic, &(drm)->client, f, ##a); \
} while(0)
#define NV_PRINTK_ONCE(l,c,f,a...) NV_PRINTK(l##_once,c,f, ##a)
--
2.37.1
[PATCH v5 27/33] drm-print: add drm_dbg_driver to improve namespace symmetry
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 with nouveau, which uses its own stack of macros to
construct calls to dev_info, dev_dbg, etc, for which adaptation means
drm_dbg_##driver constructs.
Signed-off-by: Jim Cromie
---
include/drm/drm_print.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index f8bb3e7158c6..dfdd81c3287c 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -468,7 +468,7 @@ void __drm_dev_dbg(const struct device *dev, enum
drm_debug_category category,
#define drm_dbg_core(drm, fmt, ...)\
drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_CORE, fmt, ##__VA_ARGS__)
-#define drm_dbg(drm, fmt, ...) \
+#define drm_dbg_driver(drm, fmt, ...)
\
drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRIVER, fmt,
##__VA_ARGS__)
#define drm_dbg_kms(drm, fmt, ...) \
drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_KMS, fmt, ##__VA_ARGS__)
@@ -487,6 +487,7 @@ void __drm_dev_dbg(const struct device *dev, enum
drm_debug_category category,
#define drm_dbg_drmres(drm, fmt, ...) \
drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRMRES, fmt,
##__VA_ARGS__)
+#define drm_dbg(drm, fmt, ...) drm_dbg_driver(drm, fmt, ##__VA_ARGS__)
/*
* printk based logging
--
2.37.1
[PATCH v5 18/33] doc-dyndbg: describe "class CLASS_NAME" query support
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 a/Documentation/admin-guide/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst index a89cfa083155..d8954ab05c7b 100644 --- a/Documentation/admin-guide/dynamic-debug-howto.rst +++ b/Documentation/admin-guide/dynamic-debug-howto.rst @@ -35,6 +35,7 @@ Dynamic debug has even more useful features: - line number (including ranges of line numbers) - module name - format string + - class name (as known/declared by each module) * Provides a debugfs control file: ``/dynamic_debug/control`` which can be read to display the complete list of known debug @@ -142,6 +143,7 @@ against. Possible keywords are::: 'file' string | 'module' string | 'format' string | +'class' string | 'line' line-range line-range ::= lineno | @@ -203,6 +205,15 @@ format format "nfsd: SETATTR" // a neater way to match a format with whitespace format 'nfsd: SETATTR' // yet another way to match a format with whitespace +class +The given class_name is validated against each module, which may +have declared a list of known class_names. If the class_name is +found for a module, callsite & class matching and adjustment +proceeds. Examples:: + + class DRM_UT_KMS# a DRM.debug category + class JUNK # silent non-match + line The given line number or range of line numbers is compared against the line number of each ``pr_debug()`` callsite. A single -- 2.37.1
[PATCH v5 31/33] nouveau: change nvkm_debug/trace to use dev_dbg POC
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 nouveau Its possible to control error, warn, info callsites too, but they're usually on, and the .data overheads on ~450 more callsites (56 bytes each) would just be wasted. $ for l in fatal error warn info debug trace spam; do echo $l; ack nvkm_$l drivers/gpu |wc; done fatal 3 19 335 error 2891956 30651 warn 84 5138860 info 14 881502 debug 3872339 40844 trace 31 2193368 spam 1 7 123 bash-5.1# echo $(( 516-65-387-31-1 )) 32 Thats approximate; not accounting #defines and doc/comment mentions. NOTE: this patch changes the log-level of the macro-issued messages from KERN_INFO to KERN_DEBUG. Adding a .kern_lvl field to struct _ddebug could fix that. RFC: dyndbg & subdev->debug Separate class-maps for each subdev are possible; except for the coordinated use of _base, each is independent, including choice of DISJOINT or LEVELS, as long as class-names don't conflict. So theres some flexibility. Signed-off-by: Jim Cromie --- drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h b/drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h index 96113c8bee8c..065d07ccea87 100644 --- a/drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h +++ b/drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h @@ -59,8 +59,8 @@ void nvkm_subdev_intr(struct nvkm_subdev *); #define nvkm_error(s,f,a...) nvkm_printk((s), ERROR,err, f, ##a) #define nvkm_warn(s,f,a...) nvkm_printk((s), WARN, notice, f, ##a) #define nvkm_info(s,f,a...) nvkm_printk((s), INFO, info, f, ##a) -#define nvkm_debug(s,f,a...) nvkm_printk((s), DEBUG, info, f, ##a) -#define nvkm_trace(s,f,a...) nvkm_printk((s), TRACE, info, f, ##a) +#define nvkm_debug(s,f,a...) nvkm_printk((s), DEBUG,dbg, f, ##a) +#define nvkm_trace(s,f,a...) nvkm_printk((s), TRACE,dbg, f, ##a) #define nvkm_spam(s,f,a...) nvkm_printk((s), SPAM,dbg, f, ##a) #define nvkm_error_ratelimited(s,f,a...) nvkm_printk((s), ERROR, err_ratelimited, f, ##a) -- 2.37.1
[PATCH v5 23/33] drm: POC drm on dyndbg - use in core, 2 helpers, 3 drivers.
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 it, and provide an elaborated alternative.
- in drm_*_helper modules:
dp/drm_dp - 1st item in makefile target
drivers/gpu/drm/drm_crtc_helper.c - random pick iirc.
Since these modules all use identical CLASSMAP declarations (ie: names
and .class_id's) they will all respond together to "class DRM_UT_*"
query-commands:
:#> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control
NOTES:
This changes __drm_debug from int to ulong, so BIT() is usable on it.
DRM's enum drm_debug_category values need to sync with the index of
their respective class-names here. Then .class_id == category, and
dyndbg's class FOO mechanisms will enable drm_dbg(DRM_UT_KMS, ...).
Though DRM needs consistent categories across all modules, thats not
generally needed; modules X and Y could define FOO differently (ie a
different NAME => class_id mapping), changes are made according to
each module's private class-map.
No callsites are actually selected by this patch, since none are
class'd yet.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 14 +
drivers/gpu/drm/display/drm_dp_helper.c | 13
drivers/gpu/drm/drm_crtc_helper.c | 13
drivers/gpu/drm/drm_print.c | 27 +++--
drivers/gpu/drm/i915/i915_params.c | 12 +++
drivers/gpu/drm/nouveau/nouveau_drm.c | 13
include/drm/drm_print.h | 3 ++-
7 files changed, 92 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 8890300766a5..183d604559fe 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -38,6 +38,8 @@
#include
#include
#include
+#include
+#include
#include "amdgpu.h"
#include "amdgpu_irq.h"
@@ -183,6 +185,18 @@ int amdgpu_vcnfw_log;
static void amdgpu_drv_delayed_reset_work_handler(struct work_struct *work);
+DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+ "DRM_UT_CORE",
+ "DRM_UT_DRIVER",
+ "DRM_UT_KMS",
+ "DRM_UT_PRIME",
+ "DRM_UT_ATOMIC",
+ "DRM_UT_VBL",
+ "DRM_UT_STATE",
+ "DRM_UT_LEASE",
+ "DRM_UT_DP",
+ "DRM_UT_DRMRES");
+
struct amdgpu_mgpu_info mgpu_info = {
.mutex = __MUTEX_INITIALIZER(mgpu_info.mutex),
.delayed_reset_work = __DELAYED_WORK_INITIALIZER(
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index e7c22c2ca90c..c8a4076aa4ab 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
@@ -38,6 +39,18 @@
#include "drm_dp_helper_internal.h"
+DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+ "DRM_UT_CORE",
+ "DRM_UT_DRIVER",
+ "DRM_UT_KMS",
+ "DRM_UT_PRIME",
+ "DRM_UT_ATOMIC",
+ "DRM_UT_VBL",
+ "DRM_UT_STATE",
+ "DRM_UT_LEASE",
+ "DRM_UT_DP",
+ "DRM_UT_DRMRES");
+
struct dp_aux_backlight {
struct backlight_device *base;
struct drm_dp_aux *aux;
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index b632825654a9..73e16fc0659f 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -50,6 +51,18 @@
#include "drm_crtc_helper_internal.h"
+DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+ "DRM_UT_CORE",
+ "DRM_UT_DRIVER",
+ "DRM_UT_KMS",
+ "DRM_UT_PRIME",
+ "DRM_UT_ATOMIC",
+ "DRM_UT_VBL",
+ "DRM_UT_STATE",
+ "DRM_UT_LEASE",
+ "DRM_UT_DP",
+ "DRM_UT_DRMRES");
+
/**
* DOC: overview
*
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index f783d4963d4b..ec32df35a3e3 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -40,7 +40,7 @@
* __drm_debug: Enable debug output.
* Bitmask of DRM_UT_x. See include/drm/drm_print.h for details.
*/
[PATCH v5 30/33] drm_print: add _ddebug descriptor to drm_*dbg prototypes
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 to the decorator flags, but does
none of the dynamic-prefixing done by __dynamic_emit_prefix().
DRM already has conventions for logging/messaging; just tossing
optional decorations on top may not help. Instead, existing flags (or
new ones) can be used to make current conventions optional.
For CONFIG_DRM_USE_DYNAMIC_DEBUG=N, just pass null.
Note: desc->class_id is redundant with category parameter, but its
availability is dependent on desc.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/drm_print.c | 8 +---
include/drm/drm_print.h | 23 ---
2 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index ec477c44a784..5b93c11895bb 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
@@ -278,8 +279,8 @@ void drm_dev_printk(const struct device *dev, const char
*level,
}
EXPORT_SYMBOL(drm_dev_printk);
-void __drm_dev_dbg(const struct device *dev, enum drm_debug_category category,
- const char *format, ...)
+void __drm_dev_dbg(struct _ddebug *desc, const struct device *dev,
+ enum drm_debug_category category, const char *format, ...)
{
struct va_format vaf;
va_list args;
@@ -287,6 +288,7 @@ void __drm_dev_dbg(const struct device *dev, enum
drm_debug_category category,
if (!__drm_debug_enabled(category))
return;
+ /* we know we are printing for either syslog, tracefs, or both */
va_start(args, format);
vaf.fmt = format;
vaf.va =
@@ -302,7 +304,7 @@ void __drm_dev_dbg(const struct device *dev, enum
drm_debug_category category,
}
EXPORT_SYMBOL(__drm_dev_dbg);
-void ___drm_dbg(enum drm_debug_category category, const char *format, ...)
+void ___drm_dbg(struct _ddebug *desc, enum drm_debug_category category, const
char *format, ...)
{
struct va_format vaf;
va_list args;
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 7631b5fb669e..46f14cfb401e 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -363,9 +363,10 @@ static inline bool drm_debug_enabled(enum
drm_debug_category category)
__printf(3, 4)
void drm_dev_printk(const struct device *dev, const char *level,
const char *format, ...);
-__printf(3, 4)
-void __drm_dev_dbg(const struct device *dev, enum drm_debug_category category,
-const char *format, ...);
+struct _ddebug;
+__printf(4, 5)
+void __drm_dev_dbg(struct _ddebug *desc, const struct device *dev,
+ enum drm_debug_category category, const char *format, ...);
/**
* DRM_DEV_ERROR() - Error output.
@@ -415,11 +416,11 @@ void __drm_dev_dbg(const struct device *dev, enum
drm_debug_category category,
#if !defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
#define drm_dev_dbg(dev, cat, fmt, ...)\
- __drm_dev_dbg(dev, cat, fmt, ##__VA_ARGS__)
+ __drm_dev_dbg(NULL, dev, cat, fmt, ##__VA_ARGS__)
#else
#define drm_dev_dbg(dev, cat, fmt, ...)\
- _dynamic_func_call_no_desc(fmt, __drm_dev_dbg, \
- dev, cat, fmt, ##__VA_ARGS__)
+ _dynamic_func_call_cls(cat, fmt, __drm_dev_dbg, \
+ dev, cat, fmt, ##__VA_ARGS__)
#endif
/**
@@ -523,17 +524,17 @@ void __drm_dev_dbg(const struct device *dev, enum
drm_debug_category category,
* Prefer drm_device based logging over device or prink based logging.
*/
-__printf(2, 3)
-void ___drm_dbg(enum drm_debug_category category, const char *format, ...);
+__printf(3, 4)
+void ___drm_dbg(struct _ddebug *desc, enum drm_debug_category category, const
char *format, ...);
__printf(1, 2)
void __drm_err(const char *format, ...);
#if !defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
-#define __drm_dbg(fmt, ...)___drm_dbg(fmt, ##__VA_ARGS__)
+#define __drm_dbg(fmt, ...)___drm_dbg(NULL, fmt, ##__VA_ARGS__)
#else
#define __drm_dbg(cat, fmt, ...) \
- _dynamic_func_call_no_desc(fmt, ___drm_dbg, \
- cat, fmt, ##__VA_ARGS__)
+ _dynamic_func_call_cls(cat, fmt, ___drm_dbg,\
+ cat, fmt, ##__VA_ARGS__)
#endif
/* Macros to make printk easier */
--
2.37.1
[PATCH v5 17/33] dyndbg: validate class FOO by checking with module
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 class-space, other than the default:31.
The authors' choice of FOO is highly selective, giving isolation
and/or coordinated sharing of FOOs. For example, only DRM modules
should know and respond to DRM_UT_KMS.
So this, combined with module's opt-in declaration of known classes,
effectively privatizes the .class_id space for each module (or
coordinated set of modules).
Notes:
For all "class FOO" queries, ddebug_find_valid_class() is called, it
returns the map matching the query, and sets valid_class via an
*outvar).
If no "class FOO" is supplied, valid_class = _CLASS_DFLT. This
insures that legacy queries do not trample on new class'd callsites,
as they get added.
Also add a new column to control-file output, displaying non-default
class-name (when found) or the "unknown _id:", if it has not been
(correctly) declared with one of the declarator macros.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 76 -
1 file changed, 68 insertions(+), 8 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index a3ace5866f1b..eb410b412f0d 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -56,6 +56,7 @@ struct ddebug_query {
const char *module;
const char *function;
const char *format;
+ const char *class_string;
unsigned int first_lineno, last_lineno;
};
@@ -136,15 +137,33 @@ static void vpr_info_dq(const struct ddebug_query *query,
const char *msg)
fmtlen--;
}
- v3pr_info("%s: func=\"%s\" file=\"%s\" module=\"%s\" format=\"%.*s\"
lineno=%u-%u\n",
-msg,
-query->function ?: "",
-query->filename ?: "",
-query->module ?: "",
-fmtlen, query->format ?: "",
-query->first_lineno, query->last_lineno);
+ v3pr_info("%s: func=\"%s\" file=\"%s\" module=\"%s\" format=\"%.*s\"
lineno=%u-%u class=%s\n",
+ msg,
+ query->function ?: "",
+ query->filename ?: "",
+ query->module ?: "",
+ fmtlen, query->format ?: "",
+ query->first_lineno, query->last_lineno, query->class_string);
}
+static struct ddebug_class_map *ddebug_find_valid_class(struct ddebug_table
const *dt,
+ const char
*class_string, int *class_id)
+{
+ struct ddebug_class_map *map;
+ int idx;
+
+ list_for_each_entry(map, >maps, link) {
+ idx = match_string(map->class_names, map->length, class_string);
+ if (idx >= 0) {
+ *class_id = idx + map->base;
+ return map;
+ }
+ }
+ *class_id = -ENOENT;
+ return NULL;
+}
+
+#define __outvar /* filled by callee */
/*
* Search the tables for _ddebug's which match the given `query' and
* apply the `flags' and `mask' to them. Returns number of matching
@@ -159,6 +178,8 @@ static int ddebug_change(const struct ddebug_query *query,
unsigned int newflags;
unsigned int nfound = 0;
struct flagsbuf fbuf, nbuf;
+ struct ddebug_class_map *map = NULL;
+ int __outvar valid_class;
/* search for matching ddebugs */
mutex_lock(_lock);
@@ -169,9 +190,22 @@ static int ddebug_change(const struct ddebug_query *query,
!match_wildcard(query->module, dt->mod_name))
continue;
+ if (query->class_string) {
+ map = ddebug_find_valid_class(dt, query->class_string,
_class);
+ if (!map)
+ continue;
+ } else {
+ /* constrain query, do not touch class'd callsites */
+ valid_class = _DPRINTK_CLASS_DFLT;
+ }
+
for (i = 0; i < dt->num_ddebugs; i++) {
struct _ddebug *dp = >ddebugs[i];
+ /* match site against query-class */
+ if (dp->class_id != valid_class)
+ continue;
+
/* match against the source filename */
if (query->filename &&
!match_wildcard(query->filename, dp->filename) &&
@@ -420,6 +454,8 @@ static int ddebug_parse_query(char *words[], int nwords,
} else if (!strcmp(keyword, "line")) {
if (parse_linerange(query, arg))
return -EINVAL;
+ } else if (!strcmp(keyword, "class")) {
+
[PATCH v5 24/33] drm_print: interpose drm_*dbg with forwarding macros
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, which will allow
DRM to avoid the runtime cost of drm_debug_enabled().
no functional changes.
memory cost baseline: (unchanged)
bash-5.1# drms_load
[9.220389] dyndbg: 1 debug prints in module drm
[9.224426] ACPI: bus type drm_connector registered
[9.302192] dyndbg: 2 debug prints in module ttm
[9.305033] dyndbg: 8 debug prints in module video
[9.627563] dyndbg: 127 debug prints in module i915
[9.721505] AMD-Vi: AMD IOMMUv2 functionality not available on this system -
This is not a bug.
[ 10.091345] dyndbg: 2196 debug prints in module amdgpu
[ 10.106589] [drm] amdgpu kernel modesetting enabled.
[ 10.107270] amdgpu: CRAT table not found
[ 10.107926] amdgpu: Virtual CRAT table created for CPU
[ 10.108398] amdgpu: Topology: Add CPU node
[ 10.168507] dyndbg: 3 debug prints in module wmi
[ 10.329587] dyndbg: 3 debug prints in module nouveau
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/drm_print.c | 10 +-
include/drm/drm_print.h | 9 +++--
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index ec32df35a3e3..29a29949ad0b 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -279,8 +279,8 @@ void drm_dev_printk(const struct device *dev, const char
*level,
}
EXPORT_SYMBOL(drm_dev_printk);
-void drm_dev_dbg(const struct device *dev, enum drm_debug_category category,
-const char *format, ...)
+void __drm_dev_dbg(const struct device *dev, enum drm_debug_category category,
+ const char *format, ...)
{
struct va_format vaf;
va_list args;
@@ -301,9 +301,9 @@ void drm_dev_dbg(const struct device *dev, enum
drm_debug_category category,
va_end(args);
}
-EXPORT_SYMBOL(drm_dev_dbg);
+EXPORT_SYMBOL(__drm_dev_dbg);
-void __drm_dbg(enum drm_debug_category category, const char *format, ...)
+void ___drm_dbg(enum drm_debug_category category, const char *format, ...)
{
struct va_format vaf;
va_list args;
@@ -320,7 +320,7 @@ void __drm_dbg(enum drm_debug_category category, const char
*format, ...)
va_end(args);
}
-EXPORT_SYMBOL(__drm_dbg);
+EXPORT_SYMBOL(___drm_dbg);
void __drm_err(const char *format, ...)
{
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 668273e36c2c..c429c258c957 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -335,7 +335,7 @@ __printf(3, 4)
void drm_dev_printk(const struct device *dev, const char *level,
const char *format, ...);
__printf(3, 4)
-void drm_dev_dbg(const struct device *dev, enum drm_debug_category category,
+void __drm_dev_dbg(const struct device *dev, enum drm_debug_category category,
const char *format, ...);
/**
@@ -384,6 +384,9 @@ void drm_dev_dbg(const struct device *dev, enum
drm_debug_category category,
} \
})
+#define drm_dev_dbg(dev, cat, fmt, ...)\
+ __drm_dev_dbg(dev, cat, fmt, ##__VA_ARGS__)
+
/**
* DRM_DEV_DEBUG() - Debug output for generic drm code
*
@@ -485,10 +488,12 @@ void drm_dev_dbg(const struct device *dev, enum
drm_debug_category category,
*/
__printf(2, 3)
-void __drm_dbg(enum drm_debug_category category, const char *format, ...);
+void ___drm_dbg(enum drm_debug_category category, const char *format, ...);
__printf(1, 2)
void __drm_err(const char *format, ...);
+#define __drm_dbg(fmt, ...)___drm_dbg(fmt, ##__VA_ARGS__)
+
/* Macros to make printk easier */
#define _DRM_PRINTK(once, level, fmt, ...) \
--
2.37.1
[PATCH v5 21/33] dyndbg: test DECLARE_DYNDBG_CLASSMAP, sysfs nodes
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 each class-name
- declare 2 sysnodes for each class-map
for 'p' flag, and future 'T' flag
These declarations create the following sysfs parameter interface:
:#> pwd
/sys/module/test_dynamic_debug/parameters
:#> ls
T_disjoint_bits T_disjoint_names T_level_names T_level_num do_prints
p_disjoint_bits p_disjoint_names p_level_names p_level_num
NOTES:
The local wrapper macro is an api candidate, but there are already too
many parameters. OTOH, maybe related enum should be in there too,
since it has _base inter-dependencies.
The T_* params control the (future) T flag on the same class'd
pr_debug callsites as their p* counterparts. Using them will fail,
until the dyndbg-trace patches are added in.
:#> echo 1 > T_disjoint
[ 28.792489] dyndbg: disjoint: 0x1 > test_dynamic_debug.T_D2
[ 28.793848] dyndbg: query 0: "class D2_CORE +T" mod:*
[ 28.795086] dyndbg: split into words: "class" "D2_CORE" "+T"
[ 28.796467] dyndbg: op='+'
[ 28.797148] dyndbg: unknown flag 'T'
[ 28.798021] dyndbg: flags parse failed
[ 28.798947] dyndbg: processed 1 queries, with 0 matches, 1 errs
[ 28.800378] dyndbg: bit_0: -22 matches on class: D2_CORE -> 0x1
[ 28.801959] dyndbg: test_dynamic_debug.T_D2: updated 0x0 -> 0x1
[ 28.803974] dyndbg: total matches: -22
Signed-off-by: Jim Cromie
---
lib/test_dynamic_debug.c | 125 ++-
1 file changed, 110 insertions(+), 15 deletions(-)
diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index ba3882ca3e48..8dd250ad022b 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -10,57 +10,152 @@
#include
-static void do_prints(void); /* device under test */
-
-/* run tests by reading or writing sysfs node */
+/* run tests by reading or writing sysfs node: do_prints */
+static void do_prints(void); /* device under test */
static int param_set_do_prints(const char *instr, const struct kernel_param
*kp)
{
do_prints();
return 0;
}
-
static int param_get_do_prints(char *buffer, const struct kernel_param *kp)
{
do_prints();
return scnprintf(buffer, PAGE_SIZE, "did do_prints\n");
}
-
static const struct kernel_param_ops param_ops_do_prints = {
.set = param_set_do_prints,
.get = param_get_do_prints,
};
-
module_param_cb(do_prints, _ops_do_prints, NULL, 0600);
-static void do_alpha(void)
+/*
+ * Using the CLASSMAP api:
+ * - classmaps must have corresponding enum
+ * - enum symbols must match/correlate with class-name strings in the map.
+ * - base must equal enum's 1st value
+ * - multiple maps must set their base to share the 0-30 class_id space !!
+ * (build-bug-on tips welcome)
+ * Additionally, here:
+ * - tie together sysname, mapname, bitsname, flagsname
+ */
+#define DD_SYS_WRAP(_model, _flags)\
+ static unsigned long bits_##_model; \
+ static struct ddebug_class_param _flags##_model = { \
+ .bits = _##_model, \
+ .flags = #_flags, \
+ .map = _##_model, \
+ }; \
+ module_param_cb(_flags##_##_model, _ops_dyndbg_classes,
&_flags##_model, 0600)
+
+/* numeric input, independent bits */
+enum cat_disjoint_bits {
+ D2_CORE = 0,
+ D2_DRIVER,
+ D2_KMS,
+ D2_PRIME,
+ D2_ATOMIC,
+ D2_VBL,
+ D2_STATE,
+ D2_LEASE,
+ D2_DP,
+ D2_DRMRES };
+DECLARE_DYNDBG_CLASSMAP(map_disjoint_bits, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+ "D2_CORE",
+ "D2_DRIVER",
+ "D2_KMS",
+ "D2_PRIME",
+ "D2_ATOMIC",
+ "D2_VBL",
+ "D2_STATE",
+ "D2_LEASE",
+ "D2_DP",
+ "D2_DRMRES");
+DD_SYS_WRAP(disjoint_bits, p);
+DD_SYS_WRAP(disjoint_bits, T);
+
+/* symbolic input, independent bits */
+enum cat_disjoint_names { LOW = 11, MID, HI };
+DECLARE_DYNDBG_CLASSMAP(map_disjoint_names, DD_CLASS_TYPE_DISJOINT_NAMES, 10,
+ "LOW", "MID", "HI");
+DD_SYS_WRAP(disjoint_names, p);
+DD_SYS_WRAP(disjoint_names, T);
+
+/* numeric verbosity, V2 > V1 related */
+enum cat_level_num { V0 = 14, V1, V2, V3, V4, V5, V6, V7 };
+DECLARE_DYNDBG_CLASSMAP(map_level_num, DD_CLASS_TYPE_LEVEL_NUM, 14,
+ "V0", "V1", "V2", "V3", "V4", "V5", "V6", "V7");
+DD_SYS_WRAP(level_num, p);
[PATCH v5 15/33] kernel/module: add __dyndbg_classes section
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 find_module_sections(), using section_objs()
- extend callchain prototypes
to pass classes, length
load_module(): pass new info to dynamic_debug_setup()
dynamic_debug_setup(): new params, pass through to ddebug_add_module()
dynamic_debug.c:
- add externs to the linker symbols.
ddebug_add_module():
- It currently builds a debug_table, and *will* find and attach classes.
dynamic_debug_init():
- add class fields to the _ddebug_info cursor var: di.
Signed-off-by: Jim Cromie
---
include/asm-generic/vmlinux.lds.h | 3 +++
include/linux/dynamic_debug.h | 2 ++
kernel/module/main.c | 2 ++
lib/dynamic_debug.c | 7 +++
4 files changed, 14 insertions(+)
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index 7515a465ec03..9b8bd5504ad9 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -345,6 +345,9 @@
*(__tracepoints)\
/* implement dynamic printk debug */\
. = ALIGN(8); \
+ __start___dyndbg_classes = .; \
+ KEEP(*(__dyndbg_classes)) \
+ __stop___dyndbg_classes = .;\
__start___dyndbg = .; \
KEEP(*(__dyndbg)) \
__stop___dyndbg = .;\
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 71cdc8612257..46ed10682e87 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -115,7 +115,9 @@ struct ddebug_class_map {
/* encapsulate linker provided built-in (or module) dyndbg data */
struct _ddebug_info {
struct _ddebug *descs;
+ struct ddebug_class_map *classes;
unsigned int num_descs;
+ unsigned int num_classes;
};
#if defined(CONFIG_DYNAMIC_DEBUG_CORE)
diff --git a/kernel/module/main.c b/kernel/module/main.c
index cfe10356793d..f68f331c867d 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -2095,6 +2095,8 @@ static int find_module_sections(struct module *mod,
struct load_info *info)
info->dyndbg.descs = section_objs(info, "__dyndbg",
sizeof(*info->dyndbg.descs),
>dyndbg.num_descs);
+ info->dyndbg.classes = section_objs(info, "__dyndbg_classes",
+ sizeof(*info->dyndbg.classes),
>dyndbg.num_classes);
return 0;
}
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 457ce936191a..0d6cb6b258bd 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -41,6 +41,8 @@
extern struct _ddebug __start___dyndbg[];
extern struct _ddebug __stop___dyndbg[];
+extern struct ddebug_class_map __start___dyndbg_classes[];
+extern struct ddebug_class_map __stop___dyndbg_classes[];
struct ddebug_table {
struct list_head link;
@@ -1079,7 +1081,9 @@ static int __init dynamic_debug_init(void)
struct _ddebug_info di = {
.descs = __start___dyndbg,
+ .classes = __start___dyndbg_classes,
.num_descs = __stop___dyndbg - __start___dyndbg,
+ .num_classes = __stop___dyndbg_classes -
__start___dyndbg_classes,
};
if (&__start___dyndbg == &__stop___dyndbg) {
@@ -1122,6 +1126,9 @@ static int __init dynamic_debug_init(void)
i, mod_ct, (int)((mod_ct * sizeof(struct ddebug_table)) >> 10),
(int)((i * sizeof(struct _ddebug)) >> 10));
+ if (di.num_classes)
+ v2pr_info(" %d builtin ddebug class-maps\n", di.num_classes);
+
/* now that ddebug tables are loaded, process all boot args
* again to find and activate queries given in dyndbg params.
* While this has already been done for known boot params, it
--
2.37.1
[PATCH v5 12/33] dyndbg: add class_id to pr_debug callsites
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 callsites are initialized with _DPRINTK_CLASS_DFLT, which
is 2^5-1. This reserves 0-30 for use in new categorized/class'd
pr_debugs, which fits perfectly with natural enums (ints: 0..N).
Then extend the init macro: DEFINE_DYNAMIC_DEBUG_METADATA() with
_CLS(cls, ...), and redef old name using extended name.
And extend the factory macro callchain with _cls() versions to provide
the callsite.class_id, with old-names passing _DPRINTK_CLASS_DFLT.
This sets us up to create class'd prdebug callsites (class'd callsites
are those with .class_id != _DPRINTK_CLASS_DFLT).
No behavior change.
cc: Rasmus Villemoes
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 71 +++
1 file changed, 55 insertions(+), 16 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 6a2001250da1..b6803f7e818f 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -6,6 +6,8 @@
#include
#endif
+#include
+
/*
* An instance of this structure is created in a special
* ELF section at every dynamic debug callsite. At runtime,
@@ -21,6 +23,9 @@ struct _ddebug {
const char *filename;
const char *format;
unsigned int lineno:18;
+#define CLS_BITS 5
+ unsigned int class_id:CLS_BITS;
+#define _DPRINTK_CLASS_DFLT((1 << CLS_BITS) - 1)
/*
* The flags field controls the behaviour at the callsite.
* The bits here are changed dynamically when the user
@@ -88,7 +93,7 @@ void __dynamic_ibdev_dbg(struct _ddebug *descriptor,
const struct ib_device *ibdev,
const char *fmt, ...);
-#define DEFINE_DYNAMIC_DEBUG_METADATA(name, fmt) \
+#define DEFINE_DYNAMIC_DEBUG_METADATA_CLS(name, cls, fmt) \
static struct _ddebug __aligned(8) \
__section("__dyndbg") name = { \
.modname = KBUILD_MODNAME, \
@@ -97,8 +102,14 @@ void __dynamic_ibdev_dbg(struct _ddebug *descriptor,
.format = (fmt),\
.lineno = __LINE__, \
.flags = _DPRINTK_FLAGS_DEFAULT,\
+ .class_id = cls,\
_DPRINTK_KEY_INIT \
- }
+ }; \
+ BUILD_BUG_ON_MSG(cls > _DPRINTK_CLASS_DFLT, \
+"classid value overflow")
+
+#define DEFINE_DYNAMIC_DEBUG_METADATA(name, fmt) \
+ DEFINE_DYNAMIC_DEBUG_METADATA_CLS(name, _DPRINTK_CLASS_DFLT, fmt)
#ifdef CONFIG_JUMP_LABEL
@@ -129,17 +140,34 @@ void __dynamic_ibdev_dbg(struct _ddebug *descriptor,
#endif /* CONFIG_JUMP_LABEL */
-#define __dynamic_func_call(id, fmt, func, ...) do { \
- DEFINE_DYNAMIC_DEBUG_METADATA(id, fmt); \
- if (DYNAMIC_DEBUG_BRANCH(id)) \
- func(, ##__VA_ARGS__); \
-} while (0)
-
-#define __dynamic_func_call_no_desc(id, fmt, func, ...) do { \
- DEFINE_DYNAMIC_DEBUG_METADATA(id, fmt); \
+/*
+ * Factory macros: ($prefix)dynamic_func_call($suffix)
+ *
+ * Lower layer (with __ prefix) gets the callsite metadata, and wraps
+ * the func inside a debug-branch/static-key construct. Upper layer
+ * (with _ prefix) does the UNIQUE_ID once, so that lower can ref the
+ * name/label multiple times, and tie the elements together.
+ * Multiple flavors:
+ * (|_cls):adds in _DPRINT_CLASS_DFLT as needed
+ * (|_no_desc):former gets callsite descriptor as 1st arg (for prdbgs)
+ */
+#define __dynamic_func_call_cls(id, cls, fmt, func, ...) do { \
+ DEFINE_DYNAMIC_DEBUG_METADATA_CLS(id, cls, fmt);\
if (DYNAMIC_DEBUG_BRANCH(id)) \
- func(__VA_ARGS__); \
+ func(, ##__VA_ARGS__); \
} while (0)
+#define __dynamic_func_call(id, fmt, func, ...)
\
+ __dynamic_func_call_cls(id, _DPRINTK_CLASS_DFLT, fmt, \
+ func, ##__VA_ARGS__)
+
+#define __dynamic_func_call_cls_no_desc(id, cls, fmt, func, ...) do { \
+ DEFINE_DYNAMIC_DEBUG_METADATA_CLS(id, cls, fmt);\
+ if (DYNAMIC_DEBUG_BRANCH(id)) \
+ func(__VA_ARGS__); \
+} while (0)
+#define __dynamic_func_call_no_desc(id, fmt, func, ...)
[PATCH v5 26/33] drm-print.h: include dyndbg header
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",
Since that macro is defined in drm_print.h, and under DRM_USE_DYN*=y
configs, invokes dyndbg-factory macros, include dynamic_debug.h from
there too, so that those configs have the definitions of all the
macros in the callchain.
This is done as a separate patch mostly to see how lkp sorts it.
Signed-off-by: Jim Cromie
---
include/drm/drm_print.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 2d2cef76b5c1..f8bb3e7158c6 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
--
2.37.1
[PATCH v5 16/33] dyndbg: add ddebug_attach_module_classes
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 list.
It is called indirectly from 2 sources:
- from load_module(), where it scans the module's __dyndbg_classes
section, which contains DYNAMIC_DEBUG_CLASSES definitions from just
the module.
- from dynamic_debug_init(), where all DYNAMIC_DEBUG_CLASSES
definitions of each builtin module have been packed together.
This is why ddebug_attach_module_classes() checks module-name.
NOTES
Its (highly) likely that builtin classes will be ordered by module
name (just like prdbg descriptors are in the __dyndbg section). So
the list can be replaced by a vector (ptr + length), which will work
for loaded modules too. This would imitate whats currently done for
the _ddebug descriptors.
That said, converting to vector,len is close to pointless; a small
minority of modules will ever define a class-map, and almost all of
them will have only 1 or 2 class-maps, so theres only a couple dozen
pointers to save.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 0d6cb6b258bd..a3ace5866f1b 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -45,7 +45,7 @@ extern struct ddebug_class_map __start___dyndbg_classes[];
extern struct ddebug_class_map __stop___dyndbg_classes[];
struct ddebug_table {
- struct list_head link;
+ struct list_head link, maps;
const char *mod_name;
unsigned int num_ddebugs;
struct _ddebug *ddebugs;
@@ -921,6 +921,32 @@ static const struct proc_ops proc_fops = {
.proc_write = ddebug_proc_write
};
+static void ddebug_attach_module_classes(struct ddebug_table *dt,
+struct ddebug_class_map *classes,
+int num_classes)
+{
+ struct ddebug_class_map *cm;
+ int i, j, ct = 0;
+
+ for (cm = classes, i = 0; i < num_classes; i++, cm++) {
+
+ if (!strcmp(cm->mod_name, dt->mod_name)) {
+
+ v2pr_info("class[%d]: module:%s base:%d len:%d
ty:%d\n", i,
+ cm->mod_name, cm->base, cm->length,
cm->map_type);
+
+ for (j = 0; j < cm->length; j++)
+ v3pr_info(" %d: %d %s\n", j + cm->base, j,
+ cm->class_names[j]);
+
+ list_add(>link, >maps);
+ ct++;
+ }
+ }
+ if (ct)
+ vpr_info("module:%s attached %d classes\n", dt->mod_name, ct);
+}
+
/*
* Allocate a new ddebug_table for the given module
* and add it to the global list.
@@ -953,6 +979,12 @@ static int __ddebug_add_module(struct _ddebug_info *di,
unsigned int base,
INIT_LIST_HEAD(>link);
+ INIT_LIST_HEAD(>link);
+ INIT_LIST_HEAD(>maps);
+
+ if (classes && num_classes)
+ ddebug_attach_module_classes(dt, classes, num_classes);
+
mutex_lock(_lock);
list_add_tail(>link, _tables);
mutex_unlock(_lock);
--
2.37.1
[PATCH v5 11/33] dyndbg: create and use struct _ddebug_info
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 single _ddebug_info object containing them. This
future-proofs the function against the looming addition of class-map
info, for either the builtin module set, or the loaded module.
In dynamic_debug_init(): add & initialize an auto struct _ddebug_info
var, and use it like a cursor / multi-part iterator. Re-initialize
the var's component values before each call to ddebug_add_module().
This gives us the inch-worm walk thru the modules in the built-in
__dyndbgs data section.
In kernel/module/{main.c,internal.h}:
Embed a struct _ddebug_info into struct load_info, replacing the 2 fields it
contains. Populate its members in find_module_sections.
Also adjust dynamic_debug_setup/remove() to match the change to
ddebug_add_module().
Note: this adds an include dynamic_debug, and might be prone to
include loops, since its also smuggled in by printk.h. Nothing has
puked in robot-land.
cc: Luis Chamberlain
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 13 +++-
kernel/module/internal.h | 4 ++--
kernel/module/main.c | 18
lib/dynamic_debug.c | 40 +++
4 files changed, 50 insertions(+), 25 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 8d9eec5f6d8b..6a2001250da1 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -51,12 +51,16 @@ struct _ddebug {
#endif
} __attribute__((aligned(8)));
-
+/* encapsulate linker provided built-in (or module) dyndbg data */
+struct _ddebug_info {
+ struct _ddebug *descs;
+ unsigned int num_descs;
+};
#if defined(CONFIG_DYNAMIC_DEBUG_CORE)
-int ddebug_add_module(struct _ddebug *tab, unsigned int n,
- const char *modname);
+int ddebug_add_module(struct _ddebug_info *dyndbg, const char *modname);
+
extern int ddebug_remove_module(const char *mod_name);
extern __printf(2, 3)
void __dynamic_pr_debug(struct _ddebug *descriptor, const char *fmt, ...);
@@ -184,8 +188,7 @@ void __dynamic_ibdev_dbg(struct _ddebug *descriptor,
#include
#include
-static inline int ddebug_add_module(struct _ddebug *tab, unsigned int n,
- const char *modname)
+static inline int ddebug_add_module(struct _ddebug_info *dinfo, const char
*modname)
{
return 0;
}
diff --git a/kernel/module/internal.h b/kernel/module/internal.h
index ec104c2950c3..ce42b5b8b4da 100644
--- a/kernel/module/internal.h
+++ b/kernel/module/internal.h
@@ -53,6 +53,7 @@ extern const struct kernel_symbol __stop___ksymtab_gpl[];
extern const s32 __start___kcrctab[];
extern const s32 __start___kcrctab_gpl[];
+#include
struct load_info {
const char *name;
/* pointer to module in temporary copy, freed at end of load_module() */
@@ -62,8 +63,7 @@ struct load_info {
Elf_Shdr *sechdrs;
char *secstrings, *strtab;
unsigned long symoffs, stroffs, init_typeoffs, core_typeoffs;
- struct _ddebug *debug;
- unsigned int num_debug;
+ struct _ddebug_info dyndbg;
bool sig_ok;
#ifdef CONFIG_KALLSYMS
unsigned long mod_kallsyms_init_off;
diff --git a/kernel/module/main.c b/kernel/module/main.c
index 0548151dd933..cfe10356793d 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -1593,16 +1593,16 @@ static void free_modinfo(struct module *mod)
}
}
-static void dynamic_debug_setup(struct module *mod, struct _ddebug *debug,
unsigned int num)
+static void dynamic_debug_setup(struct module *mod, struct _ddebug_info
*dyndbg)
{
- if (!debug)
+ if (!dyndbg->num_descs)
return;
- ddebug_add_module(debug, num, mod->name);
+ ddebug_add_module(dyndbg, mod->name);
}
-static void dynamic_debug_remove(struct module *mod, struct _ddebug *debug)
+static void dynamic_debug_remove(struct module *mod, struct _ddebug_info
*dyndbg)
{
- if (debug)
+ if (dyndbg->num_descs)
ddebug_remove_module(mod->name);
}
@@ -2093,8 +2093,8 @@ static int find_module_sections(struct module *mod,
struct load_info *info)
if (section_addr(info, "__obsparm"))
pr_warn("%s: Ignoring obsolete parameters\n", mod->name);
- info->debug = section_objs(info, "__dyndbg",
- sizeof(*info->debug), >num_debug);
+ info->dyndbg.descs = section_objs(info, "__dyndbg",
+ sizeof(*info->dyndbg.descs),
>dyndbg.num_descs);
return 0;
}
@@ -2783,7 +2783,7 @@ static int load_module(struct load_info *info, const char
__user *uargs,
}
init_build_id(mod,
[PATCH v5 22/33] drm_print: condense enum drm_debug_category
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, via the ddebug.class_id field.
While this slightly pessimizes the bit-test in drm_debug_enabled(),
using dyndbg with JUMP_LABEL will avoid the function entirely.
NOTE: this change forecloses the possibility of doing:
drm_dbg(DRM_UT_CORE|DRM_UT_KMS, "weird 2-cat experiment")
but thats already strongly implied by the use of the enum itself; its
not a normal enum if it can be 2 values simultaneously.
Signed-off-by: Jim Cromie
---
include/drm/drm_print.h | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 22fabdeed297..b3b470440e46 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -279,49 +279,49 @@ enum drm_debug_category {
* @DRM_UT_CORE: Used in the generic drm code: drm_ioctl.c, drm_mm.c,
* drm_memory.c, ...
*/
- DRM_UT_CORE = 0x01,
+ DRM_UT_CORE,
/**
* @DRM_UT_DRIVER: Used in the vendor specific part of the driver: i915,
* radeon, ... macro.
*/
- DRM_UT_DRIVER = 0x02,
+ DRM_UT_DRIVER,
/**
* @DRM_UT_KMS: Used in the modesetting code.
*/
- DRM_UT_KMS = 0x04,
+ DRM_UT_KMS,
/**
* @DRM_UT_PRIME: Used in the prime code.
*/
- DRM_UT_PRIME= 0x08,
+ DRM_UT_PRIME,
/**
* @DRM_UT_ATOMIC: Used in the atomic code.
*/
- DRM_UT_ATOMIC = 0x10,
+ DRM_UT_ATOMIC,
/**
* @DRM_UT_VBL: Used for verbose debug message in the vblank code.
*/
- DRM_UT_VBL = 0x20,
+ DRM_UT_VBL,
/**
* @DRM_UT_STATE: Used for verbose atomic state debugging.
*/
- DRM_UT_STATE= 0x40,
+ DRM_UT_STATE,
/**
* @DRM_UT_LEASE: Used in the lease code.
*/
- DRM_UT_LEASE= 0x80,
+ DRM_UT_LEASE,
/**
* @DRM_UT_DP: Used in the DP code.
*/
- DRM_UT_DP = 0x100,
+ DRM_UT_DP,
/**
* @DRM_UT_DRMRES: Used in the drm managed resources code.
*/
- DRM_UT_DRMRES = 0x200,
+ DRM_UT_DRMRES
};
static inline bool drm_debug_enabled(enum drm_debug_category category)
{
- return unlikely(__drm_debug & category);
+ return unlikely(__drm_debug & BIT(category));
}
/*
--
2.37.1
[PATCH v5 20/33] dyndbg: add drm.debug style (drm/parameters/debug) bitmap support
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 param_get_dyndbg_classes()
- struct kernel_param_ops param_ops_dyndbg_classes
Following the model of kernel/params.c STANDARD_PARAM_DEFS, these are
non-static and exported. This might be unnecessary here.
get/set use an augmented kernel_param; the arg refs a new struct
ddebug_class_param, which contains:
A union of bits, level; which points to user module's ulong
storing the module's debug-state. By ref'g the client's bit-state
_var, code coordinates with existing code (like drm_debug_enabled)
which uses it, so existing works unchanged. Changing to a ulong
allows use of BIT() etc.
FLAGS: dyndbg.flags toggled by changes to bitmap. Usually just "p".
MAP: a pointer to struct ddebug_classes_map, which maps those
class-names to .class_ids 0..N that the module is using. This
class-map is declared & initialized by DECLARE_DYNDBG_CLASSMAP.
map-type: 4 enums DD_CLASS_TYPE_* select 2 input forms and 2 meanings.
numeric input:
DD_CLASS_TYPE_DISJOINT_BITS integer input, independent bits. ie: drm.debug
DD_CLASS_TYPE_LEVEL_NUM integer input, 0..N levels
classnames-list (comma separated) input:
DD_CLASS_TYPE_DISJOINT_NAMES each name affects a bit, others preserved
DD_CLASS_TYPE_LEVEL_NAMES names have level meanings, like kern_levels.h
_NAMES- comma-separated classnames (with optional +-)
_NUM - numeric input, 0-N expected
_BITS - numeric input, 0x1F bitmap form expected
_DISJOINT - bits are independent
_LEVEL- (x /sys/module/drm/parameters/debug_catnames
A standard _LEVEL_NAMES use, with one class, that sets all in the
class-map according to (x /sys/module/test_dynamic_debug/parameters/p_level_names
: problem solved
echo -L1 > /sys/module/test_dynamic_debug/parameters/p_level_names
Note this artifact:
: this is same as prev cmd (due to +/-)
echo L0 > /sys/module/test_dynamic_debug/parameters/p_level_names
: this is "even-more" off, but same wo __pr_debug_class(L0, "..").
echo -L0 > /sys/module/test_dynamic_debug/parameters/p_level_names
A stress-test/make-work usage (kid toggling a light switch):
echo +L7,L0,L7,L0,L7,L0,L7,L0,L7,L0,L7,L0,L7 \
> /sys/module/test_dynamic_debug/parameters/p_level_names
ddebug_apply_class_bitmap(): inside-fn, works on bitmaps, receives
new-bits, finds diffs vs client-bitvector holding "current" state,
and issues exec_query to commit the adjustment.
param_set_dyndbg_classes(): interface fn, sends _NAMES to
param_set_dyndbg_classnames() and returns, falls thru to handle _BITS,
_NUM internally, and calls ddebug_apply_class_bitmap(). Finishes by
updating state.
param_set_dyndbg_classnames(): handles classnames-list in loop, calls
ddebug_apply_class_bitmap for each, then updates state.
NOTES:
_LEVEL_ is overlay on _DISJOINT_; inputs are converted to a bitmask,
and is done by callbacks. IOW this is possible, and possibly confusing:
echo class V3 +p > control
echo class V1 -p > control
IMO thats ok, relative verbosity is an interface property.
_LEVEL_NUM maps still need class-names, even though the names are not
usable at the sysfs interface (unlike with _NAMES style). The names
are the only way to >control the classes.
- It must have a "V0" name,
something below "V1" to turn "V1" off.
__pr_debug_cls(V0,..) is printk, don't do that.
- "class names" is required at the >control interface.
- relative levels are not enforced at >control
_LEVEL_NAMES bear +/- signs, which alters the on-bit-pos by 1. IOW,
+L2 means L0,L1,L2, and -L2 means just L0,L1. This kinda spoils the
readback fidelity, since the L0 bit gets turned on by any use of any
L*, except "-L0".
All the interface uncertainty here pertains to the _NAMES features.
Nobody has actually asked for this, so its practical (if a little
tedious) to split it out.
Signed-off-by: Jim Cromie
---
. drop kp->mod->name as unneeded (build-dependent)
. param_set_dyndbg_classnames, not _class_strings
. DD_CLASS_TYPE_* name changes, per Jason
. callbacks:
extend comments on DD_CLASS_TYPE_* handling, flow notes
varname changes
. kdoc tweaks
. add stub macro: #define KP_NAME(kp) kp->name
later, add "$module." prefix when config doesn't do it
. s/struct ddebug_classes_bitmap_param/struct ddebug_class_param/
. fix levels state handling
v4 had trouble where level-type's state was fouled by conversion to
bitmap form given to apply-bitmap. fix by:
(simplify/clarify)
add old-bits, new-bits to sysfs-iface
use CLASSMAP_BITMASK more
in param_set_dyndbg_class{es,names}():
move state-saving inside switches, and tailor it to type.
this preserves lvl-state, vs -v4 which didnt.
I could "hack" in an offset, but the problem feels deeper.
The
[PATCH v5 08/33] dyndbg: add test_dynamic_debug module
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 /sys/module/test_dynamic_debug/parameters/do_prints
echo module test_dynamic_debug +mftl > /proc/dynamic_debug/control
echo junk > /sys/module/test_dynamic_debug/parameters/do_prints
Signed-off-by: Jim Cromie
Acked-by: Jason Baron
---
MAINTAINERS | 2 ++
lib/Kconfig.debug| 10 ++
lib/Makefile | 1 +
lib/test_dynamic_debug.c | 70
4 files changed, 83 insertions(+)
create mode 100644 lib/test_dynamic_debug.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 64379c699903..a14fc4b6a10b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7093,6 +7093,8 @@ M:Jason Baron
S: Maintained
F: include/linux/dynamic_debug.h
F: lib/dynamic_debug.c
+M: Jim Cromie
+F: lib/test_dynamic_debug.c
DYNAMIC INTERRUPT MODERATION
M: Tal Gilboa
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 2e24db4bff19..ca5978e1d18a 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -2529,6 +2529,16 @@ config TEST_STATIC_KEYS
If unsure, say N.
+config TEST_DYNAMIC_DEBUG
+ tristate "Test DYNAMIC_DEBUG"
+ depends on DYNAMIC_DEBUG
+ help
+ This module registers a tracer callback to count enabled
+ pr_debugs in a 'do_debugging' function, then alters their
+ enablements, calls the function, and compares counts.
+
+ If unsure, say N.
+
config TEST_KMOD
tristate "kmod stress tester"
depends on m
diff --git a/lib/Makefile b/lib/Makefile
index f99bf61f8bbc..9c316df868de 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_TEST_SORT) += test_sort.o
obj-$(CONFIG_TEST_USER_COPY) += test_user_copy.o
obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_keys.o
obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_key_base.o
+obj-$(CONFIG_TEST_DYNAMIC_DEBUG) += test_dynamic_debug.o
obj-$(CONFIG_TEST_PRINTF) += test_printf.o
obj-$(CONFIG_TEST_SCANF) += test_scanf.o
obj-$(CONFIG_TEST_BITMAP) += test_bitmap.o
diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
new file mode 100644
index ..ba3882ca3e48
--- /dev/null
+++ b/lib/test_dynamic_debug.c
@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Kernel module for testing dynamic_debug
+ *
+ * Authors:
+ * Jim Cromie
+ */
+
+#define pr_fmt(fmt) "test_dd: " fmt
+
+#include
+
+static void do_prints(void); /* device under test */
+
+/* run tests by reading or writing sysfs node */
+
+static int param_set_do_prints(const char *instr, const struct kernel_param
*kp)
+{
+ do_prints();
+ return 0;
+}
+
+static int param_get_do_prints(char *buffer, const struct kernel_param *kp)
+{
+ do_prints();
+ return scnprintf(buffer, PAGE_SIZE, "did do_prints\n");
+}
+
+static const struct kernel_param_ops param_ops_do_prints = {
+ .set = param_set_do_prints,
+ .get = param_get_do_prints,
+};
+
+module_param_cb(do_prints, _ops_do_prints, NULL, 0600);
+
+static void do_alpha(void)
+{
+ pr_debug("do alpha\n");
+}
+static void do_beta(void)
+{
+ pr_debug("do beta\n");
+}
+
+static void do_prints(void)
+{
+ do_alpha();
+ do_beta();
+}
+
+static int __init test_dynamic_debug_init(void)
+{
+ pr_debug("init start\n");
+
+ do_prints();
+
+ pr_debug("init done\n");
+ return 0;
+}
+
+static void __exit test_dynamic_debug_exit(void)
+{
+ pr_debug("exiting\n");
+}
+
+module_init(test_dynamic_debug_init);
+module_exit(test_dynamic_debug_exit);
+
+MODULE_AUTHOR("Jim Cromie ");
+MODULE_LICENSE("GPL");
--
2.37.1
[PATCH v5 19/33] doc-dyndbg: edit dynamic-debug-howto for brevity, audience
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 independent. - swap sections: Viewing before Controlling. control file as Catalog. - focus on use by a system administrator add an alias to make examples more readable drop grep-101 lessons, admins know this. - use init/main.c as 1st example, thread it thru doc where useful. everybodys kernel boots, runs these. - add *prdbg* api section to the bottom of the file, its for developers more than admins. move list of api functions there. - simplify - drop extra words, phrases, sentences. - add "decorator" flags line to unify "prefix", trim fmlt descriptions CC: linux-...@vger.kernel.org Signed-off-by: Jim Cromie --- fixup-doc: trailing colons for block headers, trim fedora numbers. Bagas --- .../admin-guide/dynamic-debug-howto.rst | 235 +- 1 file changed, 117 insertions(+), 118 deletions(-) diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst index d8954ab05c7b..faa22f77847a 100644 --- a/Documentation/admin-guide/dynamic-debug-howto.rst +++ b/Documentation/admin-guide/dynamic-debug-howto.rst @@ -5,30 +5,19 @@ Dynamic debug Introduction -This document describes how to use the dynamic debug (dyndbg) feature. +Dynamic debug allows you to dynamically enable/disable kernel +debug-print code to obtain additional kernel information. -Dynamic debug is designed to allow you to dynamically enable/disable -kernel code to obtain additional kernel information. Currently, if -``CONFIG_DYNAMIC_DEBUG`` is set, then all ``pr_debug()``/``dev_dbg()`` and -``print_hex_dump_debug()``/``print_hex_dump_bytes()`` calls can be dynamically -enabled per-callsite. +If ``/proc/dynamic_debug/control`` exists, your kernel has dynamic +debug. You'll need root access (sudo su) to use this. -If you do not want to enable dynamic debug globally (i.e. in some embedded -system), you may set ``CONFIG_DYNAMIC_DEBUG_CORE`` as basic support of dynamic -debug and add ``ccflags := -DDYNAMIC_DEBUG_MODULE`` into the Makefile of any -modules which you'd like to dynamically debug later. +Dynamic debug provides: -If ``CONFIG_DYNAMIC_DEBUG`` is not set, ``print_hex_dump_debug()`` is just -shortcut for ``print_hex_dump(KERN_DEBUG)``. + * a Catalog of all *prdbgs* in your kernel. + ``cat /proc/dynamic_debug/control`` to see them. -For ``print_hex_dump_debug()``/``print_hex_dump_bytes()``, format string is -its ``prefix_str`` argument, if it is constant string; or ``hexdump`` -in case ``prefix_str`` is built dynamically. - -Dynamic debug has even more useful features: - - * Simple query language allows turning on and off debugging - statements by matching any combination of 0 or 1 of: + * a Simple query/command language to alter *prdbgs* by selecting on + any combination of 0 or 1 of: - source filename - function name @@ -37,107 +26,88 @@ Dynamic debug has even more useful features: - format string - class name (as known/declared by each module) - * Provides a debugfs control file: ``/dynamic_debug/control`` - which can be read to display the complete list of known debug - statements, to help guide you - -Controlling dynamic debug Behaviour -=== - -The behaviour of ``pr_debug()``/``dev_dbg()`` are controlled via writing to a -control file in the 'debugfs' filesystem. Thus, you must first mount -the debugfs filesystem, in order to make use of this feature. -Subsequently, we refer to the control file as: -``/dynamic_debug/control``. For example, if you want to enable -printing from source file ``svcsock.c``, line 1603 you simply do:: - - nullarbor:~ # echo 'file svcsock.c line 1603 +p' > - /dynamic_debug/control - -If you make a mistake with the syntax, the write will fail thus:: - - nullarbor:~ # echo 'file svcsock.c wtf 1 +p' > - /dynamic_debug/control - -bash: echo: write error: Invalid argument - -Note, for systems without 'debugfs' enabled, the control file can be -found in ``/proc/dynamic_debug/control``. - Viewing Dynamic Debug Behaviour === -You can view the currently configured behaviour of all the debug -statements via:: +You can view the currently configured behaviour in the *prdbg* catalog:: - nullarbor:~ # cat /dynamic_debug/control + :#> head -n7 /proc/dynamic_debug/control # filename:lineno [module]function flags format - net/sunrpc/svc_rdma.c:323 [svcxprt_rdma]svc_rdma_cleanup =_ "SVCRDMA Module Removed, deregister RPC RDMA transport\012" - net/sunrpc/svc_rdma.c:341 [svcxprt_rdma]svc_rdma_init =_ "\011max_inline : %d\012" - net/sunrpc/svc_rdma.c:340
[PATCH v5 10/33] dyndbg: cleanup local vars in ddebug_init
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
this allows 'demotion' of iter->site (for removal later)
treat vars as iters:
- drop init at top
init just above for-loop, in a textual block
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index e96dc216463b..2e8ebef3bd0d 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1059,11 +1059,10 @@ static int __init dynamic_debug_init_control(void)
static int __init dynamic_debug_init(void)
{
- struct _ddebug *iter, *iter_start;
- const char *modname = NULL;
+ struct _ddebug *iter, *iter_mod_start;
+ int ret, i, mod_sites, mod_ct;
+ const char *modname;
char *cmdline;
- int ret = 0;
- int n = 0, entries = 0, modct = 0;
if (&__start___dyndbg == &__stop___dyndbg) {
if (IS_ENABLED(CONFIG_DYNAMIC_DEBUG)) {
@@ -1074,30 +1073,32 @@ static int __init dynamic_debug_init(void)
ddebug_init_success = 1;
return 0;
}
- iter = __start___dyndbg;
+
+ iter = iter_mod_start = __start___dyndbg;
modname = iter->modname;
- iter_start = iter;
- for (; iter < __stop___dyndbg; iter++) {
- entries++;
+ i = mod_sites = mod_ct = 0;
+
+ for (; iter < __stop___dyndbg; iter++, i++, mod_sites++) {
+
if (strcmp(modname, iter->modname)) {
- modct++;
- ret = ddebug_add_module(iter_start, n, modname);
+ mod_ct++;
+ ret = ddebug_add_module(iter_mod_start, mod_sites,
modname);
if (ret)
goto out_err;
- n = 0;
+
+ mod_sites = 0;
modname = iter->modname;
- iter_start = iter;
+ iter_mod_start = iter;
}
- n++;
}
- ret = ddebug_add_module(iter_start, n, modname);
+ ret = ddebug_add_module(iter_mod_start, mod_sites, modname);
if (ret)
goto out_err;
ddebug_init_success = 1;
vpr_info("%d prdebugs in %d modules, %d KiB in ddebug tables, %d kiB in
__dyndbg section\n",
-entries, modct, (int)((modct * sizeof(struct ddebug_table)) >>
10),
-(int)((entries * sizeof(struct _ddebug)) >> 10));
+i, mod_ct, (int)((mod_ct * sizeof(struct ddebug_table)) >> 10),
+(int)((i * sizeof(struct _ddebug)) >> 10));
/* now that ddebug tables are loaded, process all boot args
* again to find and activate queries given in dyndbg params.
--
2.37.1
[PATCH v5 07/33] dyndbg: let query-modname override actual module name
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 query.module 1st,
which disallowed its use in the query-string.
But now, its useful to allow a module-load to enable classes across a
whole (or part of) a subsystem at once.
# enable (dynamic-debug in) drm only
modprobe drm dyndbg="class DRM_UT_CORE +p"
# get drm_helper too
modprobe drm dyndbg="class DRM_UT_CORE module drm* +p"
# get everything that knows DRM_UT_CORE
modprobe drm dyndbg="class DRM_UT_CORE module * +p"
# also for boot-args:
drm.dyndbg="class DRM_UT_CORE module * +p"
So convert the override into a default, by filling it only when/after
the query-string omitted the module.
NB: the query class FOO handling is forthcoming.
Fixes: 8e59b5cfb9a6 dynamic_debug: add modname arg to exec_query callchain
Signed-off-by: Jim Cromie
Acked-by: Jason Baron
---
lib/dynamic_debug.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index e5cbe603000c..5a849716220a 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -385,10 +385,6 @@ static int ddebug_parse_query(char *words[], int nwords,
return -EINVAL;
}
- if (modname)
- /* support $modname.dyndbg= */
- query->module = modname;
-
for (i = 0; i < nwords; i += 2) {
char *keyword = words[i];
char *arg = words[i+1];
@@ -429,6 +425,13 @@ static int ddebug_parse_query(char *words[], int nwords,
if (rc)
return rc;
}
+ if (!query->module && modname)
+ /*
+* support $modname.dyndbg=, when
+* not given in the query itself
+*/
+ query->module = modname;
+
vpr_info_dq(query, "parsed");
return 0;
}
--
2.37.1
[PATCH v5 06/33] dyndbg: use ESCAPE_SPACE for cat control
`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 initcall %s\n" init/main.c:1218 [main]initcall_blacklisted =_ "initcall %s blacklisted\n" init/main.c:1424 [main]run_init_process =_ " with arguments:\n" init/main.c:1426 [main]run_init_process =_ "%s\n" init/main.c:1427 [main]run_init_process =_ " with environment:\n" init/main.c:1429 [main]run_init_process =_ "%s\n" Signed-off-by: Jim Cromie Acked-by: Jason Baron --- lib/dynamic_debug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index 8ff11977b8bd..e5cbe603000c 100644 --- a/lib/dynamic_debug.c +++ b/lib/dynamic_debug.c @@ -900,7 +900,7 @@ static int ddebug_proc_show(struct seq_file *m, void *p) trim_prefix(dp->filename), dp->lineno, iter->table->mod_name, dp->function, ddebug_describe_flags(dp->flags, )); - seq_escape(m, dp->format, "\t\r\n\""); + seq_escape_str(m, dp->format, ESCAPE_SPACE, "\t\r\n\""); seq_puts(m, "\"\n"); return 0; -- 2.37.1
[PATCH v5 09/33] dyndbg: drop EXPORTed dynamic_debug_exec_queries
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 ("dyndbg: refine export, rename to
dynamic_debug_exec_queries()")
Fixes: 4c0d77828d4f ("dyndbg: export ddebug_exec_queries")
Signed-off-by: Jim Cromie
Acked-by: Jason Baron
---
include/linux/dynamic_debug.h | 9 -
lib/dynamic_debug.c | 29 -
2 files changed, 38 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index f30b01aa9fa4..8d9eec5f6d8b 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -55,9 +55,6 @@ struct _ddebug {
#if defined(CONFIG_DYNAMIC_DEBUG_CORE)
-/* exported for module authors to exercise >control */
-int dynamic_debug_exec_queries(const char *query, const char *modname);
-
int ddebug_add_module(struct _ddebug *tab, unsigned int n,
const char *modname);
extern int ddebug_remove_module(const char *mod_name);
@@ -221,12 +218,6 @@ static inline int ddebug_dyndbg_module_param_cb(char
*param, char *val,
rowsize, groupsize, buf, len, ascii); \
} while (0)
-static inline int dynamic_debug_exec_queries(const char *query, const char
*modname)
-{
- pr_warn("kernel not built with CONFIG_DYNAMIC_DEBUG_CORE\n");
- return 0;
-}
-
#endif /* !CONFIG_DYNAMIC_DEBUG_CORE */
#endif
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 5a849716220a..e96dc216463b 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -558,35 +558,6 @@ static int ddebug_exec_queries(char *query, const char
*modname)
return nfound;
}
-/**
- * dynamic_debug_exec_queries - select and change dynamic-debug prints
- * @query: query-string described in admin-guide/dynamic-debug-howto
- * @modname: string containing module name, usually _name
- *
- * This uses the >/proc/dynamic_debug/control reader, allowing module
- * authors to modify their dynamic-debug callsites. The modname is
- * canonically struct module.mod_name, but can also be null or a
- * module-wildcard, for example: "drm*".
- */
-int dynamic_debug_exec_queries(const char *query, const char *modname)
-{
- int rc;
- char *qry; /* writable copy of query */
-
- if (!query) {
- pr_err("non-null query/command string expected\n");
- return -EINVAL;
- }
- qry = kstrndup(query, PAGE_SIZE, GFP_KERNEL);
- if (!qry)
- return -ENOMEM;
-
- rc = ddebug_exec_queries(qry, modname);
- kfree(qry);
- return rc;
-}
-EXPORT_SYMBOL_GPL(dynamic_debug_exec_queries);
-
#define PREFIX_SIZE 64
static int remaining(int wrote)
--
2.37.1
[PATCH v5 05/33] dyndbg: reverse module.callsite walk in cat control
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.
Combined with previous commit, which reversed tables-list, we get:
:#> head -n7 /proc/dynamic_debug/control
# filename:lineno [module]function flags format
init/main.c:1179 [main]initcall_blacklist =_ "blacklisting initcall %s\012"
init/main.c:1218 [main]initcall_blacklisted =_ "initcall %s blacklisted\012"
init/main.c:1424 [main]run_init_process =_ " with arguments:\012"
init/main.c:1426 [main]run_init_process =_ "%s\012"
init/main.c:1427 [main]run_init_process =_ " with environment:\012"
init/main.c:1429 [main]run_init_process =_ "%s\012"
Signed-off-by: Jim Cromie
Acked-by: Jason Baron
---
lib/dynamic_debug.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 7fb99492c16f..8ff11977b8bd 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -59,7 +59,7 @@ struct ddebug_query {
struct ddebug_iter {
struct ddebug_table *table;
- unsigned int idx;
+ int idx;
};
struct flag_settings {
@@ -805,13 +805,12 @@ static struct _ddebug *ddebug_iter_first(struct
ddebug_iter *iter)
{
if (list_empty(_tables)) {
iter->table = NULL;
- iter->idx = 0;
return NULL;
}
iter->table = list_entry(ddebug_tables.next,
struct ddebug_table, link);
- iter->idx = 0;
- return >table->ddebugs[iter->idx];
+ iter->idx = iter->table->num_ddebugs;
+ return >table->ddebugs[--iter->idx];
}
/*
@@ -824,15 +823,16 @@ static struct _ddebug *ddebug_iter_next(struct
ddebug_iter *iter)
{
if (iter->table == NULL)
return NULL;
- if (++iter->idx == iter->table->num_ddebugs) {
+ if (--iter->idx < 0) {
/* iterate to next table */
- iter->idx = 0;
if (list_is_last(>table->link, _tables)) {
iter->table = NULL;
return NULL;
}
iter->table = list_entry(iter->table->link.next,
struct ddebug_table, link);
+ iter->idx = iter->table->num_ddebugs;
+ --iter->idx;
}
return >table->ddebugs[iter->idx];
}
--
2.37.1
[PATCH v5 02/33] dyndbg: fix module.dyndbg handling
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 caused no ill effects, because unknown parameters are either
ignored by default with an "unknown parameter" warning, or ignored
because dyndbg allows its no-effect use on non-dyndbg builds.
But since the code has an explicit feedback message, it should be
issued accurately. Fix with strcmp for exact param-name match.
Reported-by: Rasmus Villemoes
Fixes: b48420c1d301 dynamic_debug: make dynamic-debug work for module
initialization
Signed-off-by: Jim Cromie
Acked-by: Jason Baron
---
include/linux/dynamic_debug.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index dce631e678dd..f30b01aa9fa4 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -201,7 +201,7 @@ static inline int ddebug_remove_module(const char *mod)
static inline int ddebug_dyndbg_module_param_cb(char *param, char *val,
const char *modname)
{
- if (strstr(param, "dyndbg")) {
+ if (!strcmp(param, "dyndbg")) {
/* avoid pr_warn(), which wants pr_fmt() fully defined */
printk(KERN_WARNING "dyndbg param is supported only in "
"CONFIG_DYNAMIC_DEBUG builds\n");
--
2.37.1
[PATCH v5 04/33] dyndbg: reverse module walk in cat control
/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 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 8faf584f2f4b..7fb99492c16f 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -970,7 +970,7 @@ int ddebug_add_module(struct _ddebug *tab, unsigned int n,
dt->ddebugs = tab;
mutex_lock(_lock);
- list_add(>link, _tables);
+ list_add_tail(>link, _tables);
mutex_unlock(_lock);
vpr_info("%3u debug prints in module %s\n", n, dt->mod_name);
--
2.37.1
[PATCH v5 01/33] dyndbg: fix static_branch manipulation
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 computed newflags, but then in the JUMP_LABEL block,
failed to use that result, instead using just one of the terms in it.
Using newflags instead made the code work properly.
This is Vincents test-case, reduced. It needs the 2nd flag to
demonstrate the bug, but it's explanatory here.
pt_test() {
echo 5 > /sys/module/dynamic_debug/verbose
site="module tcp" # just one callsite
echo " $site =_ " > /proc/dynamic_debug/control # clear it
# A B ~A ~B
for flg in +T +p "-T #broke here" -p; do
echo " $site $flg " > /proc/dynamic_debug/control
done;
# A B ~B ~A
for flg in +T +p "-p #broke here" -T; do
echo " $site $flg " > /proc/dynamic_debug/control
done
}
pt_test
Fixes: 84da83a6ffc0 dyndbg: combine flags & mask into a struct, simplify with it
CC: vincent.whitchu...@axis.com
Signed-off-by: Jim Cromie
Acked-by: Jason Baron
---
.drop @stable, no exposed bug.
.add jbaron ack
---
lib/dynamic_debug.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index dd7f56af9aed..a56c1286ffa4 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -211,10 +211,11 @@ static int ddebug_change(const struct ddebug_query *query,
continue;
#ifdef CONFIG_JUMP_LABEL
if (dp->flags & _DPRINTK_FLAGS_PRINT) {
- if (!(modifiers->flags & _DPRINTK_FLAGS_PRINT))
+ if (!(newflags & _DPRINTK_FLAGS_PRINT))
static_branch_disable(>key.dd_key_true);
- } else if (modifiers->flags & _DPRINTK_FLAGS_PRINT)
+ } else if (newflags & _DPRINTK_FLAGS_PRINT) {
static_branch_enable(>key.dd_key_true);
+ }
#endif
dp->flags = newflags;
v4pr_info("changed %s:%d [%s]%s =%s\n",
--
2.37.1
[PATCH v5 03/33] dyndbg: show both old and new in change-info
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 a56c1286ffa4..8faf584f2f4b 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -156,7 +156,7 @@ static int ddebug_change(const struct ddebug_query *query,
struct ddebug_table *dt;
unsigned int newflags;
unsigned int nfound = 0;
- struct flagsbuf fbuf;
+ struct flagsbuf fbuf, nbuf;
/* search for matching ddebugs */
mutex_lock(_lock);
@@ -217,11 +217,12 @@ static int ddebug_change(const struct ddebug_query *query,
static_branch_enable(>key.dd_key_true);
}
#endif
+ v4pr_info("changed %s:%d [%s]%s %s => %s\n",
+ trim_prefix(dp->filename), dp->lineno,
+ dt->mod_name, dp->function,
+ ddebug_describe_flags(dp->flags, ),
+ ddebug_describe_flags(newflags, ));
dp->flags = newflags;
- v4pr_info("changed %s:%d [%s]%s =%s\n",
-trim_prefix(dp->filename), dp->lineno,
-dt->mod_name, dp->function,
-ddebug_describe_flags(dp->flags, ));
}
}
mutex_unlock(_lock);
--
2.37.1
[PATCH v5 00/33] DYNDBG: opt-in class'd debug for modules, use in drm.
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 addition (class keyword is small) patches between the move are the guts of the "class foo" feature. exposure of feature is only via >control, until sysfs parts added DRM chunk: included here to see how patchwork's merge & test proceeds. categories -> classes re-work is unchanged - feels pretty solid. nouveau & LEVEL made some progress, still WIP. I left out tracefs bits for now. UNCERTAINTIES / RFC: 1st is my "sharing" technique, across DRM's multi modules. Its literally duplicated decls, by each participating module, each adding static data in its own special section. I didn't try at all to shrink or unify this any further. There might be a perfect place to add a single decl, but that quest will require a pony. Sharing by class-names lacks the compiler support that varnames get; "incomplete" enables will probably happen if one of the declarations miss-spells one of the classnames. That said, see the how-to below: stringifying va-args in the macro would allow direct use of the enum-consts, and cc will insist that those consts are defined, eliminating part of the un-support. I could split the _BITS,_NUM handling out from _NAMES (ie split drm.debug style patch); theres no user-demand for the _NAMES feature ATM, and theres probably some legit API-bikeshedding to do. PATCHSET DESCRIPTION This patchset adds 'typed' "class FOO" support to dynamic-debug, where 'typed' means either DISJOINT_BITS, like drm_dbg(DRM_UT_CORE,..), or LEVEL_NUM (like nouveau debug-levels). Use it in DRM modules: core, helpers, and in drivers i915, amdgpu, nouveau. If a module is using class'd prdbgs (pr_debug_class, dev_dbg_class, or adapted drm_dbg_) or similar in its code, it can "opt in" to allow dyndbg to manipulate those class'd prdebugs, by declaring in a c-file: DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0, "DRM_UT_CORE", "DRM_UT_DRIVER", "DRM_UT_KMS", "DRM_UT_PRIME", "DRM_UT_ATOMIC", "DRM_UT_VBL", "DRM_UT_STATE", "DRM_UT_LEASE", "DRM_UT_DP", "DRM_UT_DRMRES"); // how-to stringify __va_args inside the macro ? By doing this, a module tells dyndbg that it: - is using class-ids [0..N] in prdbg callsites ( 0..N == DRM_UT_CORE..DRM_UT_DRMRES ) - wants to refer to them by class-names [0..N] - is mapping those names to those class-ids - expects users to enable them via >control or >parameter/knob Then, a user can enable the prdbgs by their class: :#> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control And with another 3-line bitmap param decl/init, wrapping the drm_debug_classes var in a module-param-cb: :#> echo 0x1 > /sys/module/drm/parameters/debug and optionally using classnames: :#> echo +DRM_UT_CORE,-DRM_UT_KMS \ > /sys/module/drm/parameters/debug_cats DYNAMIC_DEBUG gets: struct _ddebug gets a new .class_id:5 field, big enough to represent drm_debug_category (after squeezing). It defaults to 31 for all existing prdbgs. class_id also supports verbose uses. classmaps (as declared by macro above) are in their own linker section, are loaded by kernel/module, and handled by add_module, which attaches classmaps to their module's ddebug table. ddebug_change() handles a class FOO query by validating that FOO is known by each module in the loop. The query is skipped unless the module knows FOO, so no changes are possible w/o a good classname. Without class FOO in a query/command, only ids=31 can be changed by that query. This protects all class'd prdbgs from changes by legacy class-less user queries. With this support, the module opt-in approach means that: - modules declare classnames they like, meaningful names: DRM_UT_* these are numbered [0..N] - modules call pr_debug_class(N, "fmt..",...) or drm_dbg(CAT, "fmt..",...) - same form. - class-id space, while limited:0-30, is private to each module - "class FOO" is only way to select a class'd prdbg - unrelated modules use 0..N separately, for different purposes. - modules "share" classnames by separate decls (uses of macro) all drm modules reuse the above declaration. then they respond together to a >control 4 CLASS_TYPES are defined; they split behavior on 2 factors: 1. independent bits vs related:(X sysknob ambiguity as was case when both were accepted on same knob - narrower interfaces uint is uint - can defer DISJOINT_NAMES handling, but keep
Re: [PATCH 4/5] drm/vkms: Add ConfigFS scaffolding to VKMS
On Fri, Jul 22, 2022 at 05:32:12PM -0400, Jim Shargo wrote: > This change adds the basic scaffolding for ConfigFS, including setting > up the default directories. It does not allow for the registration of > configfs-backed devices, which is complex and provided in a follow-up > commit. > > This CL includes docs about using ConfigFS with VKMS, but I'll summarize > in brief here as well (assuming ConfigFS is mounted at /config/): > > To create a new configuration, you can do so via `mkdir > /config/vkms/my-device`. > > This will create a number of directories and files automatically: > > /config > `-- vkms > `-- my-device > |-- connectors > |-- crtcs > |-- encoders > |-- planes > `-- is_registered > > You can then configure objects by mkdir'ing in each of the directories. > > When you're satisfied, you can `echo 1 > > /config/vkms/my-device/is_registered`. > This will create a new device according to your configuration. > > For now, this will fail, but the next change will add support for it. > > Signed-off-by: Jim Shargo > --- > Documentation/gpu/vkms.rst | 76 > drivers/gpu/drm/Kconfig | 1 + > drivers/gpu/drm/vkms/Makefile| 1 + > drivers/gpu/drm/vkms/vkms_configfs.c | 527 +++ > drivers/gpu/drm/vkms/vkms_drv.c | 28 +- > drivers/gpu/drm/vkms/vkms_drv.h | 75 +++- > drivers/gpu/drm/vkms/vkms_output.c | 11 +- > 7 files changed, 711 insertions(+), 8 deletions(-) > create mode 100644 drivers/gpu/drm/vkms/vkms_configfs.c > > diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst > index 9c873c3912cc..f5f8ea0de5bc 100644 > --- a/Documentation/gpu/vkms.rst > +++ b/Documentation/gpu/vkms.rst > @@ -51,6 +51,82 @@ To disable the driver, use :: > >sudo modprobe -r vkms > > +Configuration With ConfigFS > +=== > + > +VKMS is instrumented with support for configuration via `ConfigFS`. With VKMS > +installed, you can mount ConfigFS at /config/ like so:: > + > + mkdir -p /config/ > + sudo mount -t configfs none /config > + > +This allows you to configure multiple virtual cards in addition to an > immutable > +"default" card created by the driver at initialization time. Is the default for backwards compatibility? > + > +To set up a new card, create a new directory under the vkms configfs > +directory:: > + > + $ mkdir /config/vkms/test > + > +With your card created you'll find an new directory ready to be configured:: > + > + /config > + `-- vkms > + |-- default > + | `-- is_registered > + `-- test > + |-- connectors > + |-- crtcs > + |-- encoders > + |-- planes > + `-- is_registered > + > +Each directory you add within the connectors, crtcs, encoders, and planes > +directories will let you configure a new object of that type. Adding new > +objects will automatically create a set of default files and folders you can > +use to configure that object. > + > +For instance, we can set up a very basic driver like so:: > + > + DRM_PLANE_TYPE_PRIMARY=1 > + DRM_PLANE_TYPE_CURSOR=2 > + DRM_PLANE_TYPE_OVERLAY=0 > + > + mkdir /config/vkms/test/planes/primary > + echo $DRM_PLANE_TYPE_PRIMARY > /config/vkms/test/planes/primary/type > + > + mkdir /config/vkms/test/planes/other_primary > + echo $DRM_PLANE_TYPE_PRIMARY > /config/vkms/test/planes/other_primary/type > + > + mkdir /config/vkms/test/planes/cursor > + echo $DRM_PLANE_TYPE_CURSOR > /config/vkms/test/planes/cursor/type > + > + mkdir /config/vkms/test/planes/overlay > + echo $DRM_PLANE_TYPE_OVERLAY > /config/vkms/test/planes/overlay/type > + > + mkdir /config/vkms/test/crtcs/crtc > + mkdir /config/vkms/test/crtcs/crtc_other > + mkdir /config/vkms/test/encoders/encoder > + mkdir /config/vkms/test/connectors/connector > + > + ln -s /config/vkms/test/encoders/encoder > /config/vkms/test/connectors/connector/possible_encoders > + ln -s /config/vkms/test/crtcs/crtc > /config/vkms/test/encoders/encoder/possible_crtcs/ > + ln -s /config/vkms/test/crtcs/crtc > /config/vkms/test/planes/primary/possible_crtcs/ > + ln -s /config/vkms/test/crtcs/crtc > /config/vkms/test/planes/cursor/possible_crtcs/ > + ln -s /config/vkms/test/crtcs/crtc > /config/vkms/test/planes/overlay/possible_crtcs/ > + ln -s /config/vkms/test/crtcs/crtc_other > /config/vkms/test/planes/overlay/possible_crtcs/ > + > +You can see that specific attributes, such as `...//type`, can be > +configured by writing into them. Associating objects together can be done via > +symlinks. > + > +Finally, to register your newly configured objects with DRM so you can use > your > +virtual device, all you need to do is write `1` into the special file > +`/config/vkms/test/is_registered``, which will return non-zero on error. > + > +When you're done with the virtual card, all you need to do is `rmdir` the >
Re: [PATCH v2 1/3] drm/dp_mst: add passthrough_aux to struct drm_dp_mst_port
lgtm!
Reviewed-by: Lyude Paul
On Fri, 2022-08-05 at 17:13 -0400, Hamza Mahfooz wrote:
> Currently, there is no way to identify if DSC pass-through can be
> enabled and what aux DSC pass-through requests ought to be sent to. So,
> add a variable to struct drm_dp_mst_port that keeps track of the
> aforementioned information.
>
> Signed-off-by: Hamza Mahfooz
> ---
> v2: define DP_DSC_PASSTHROUGH_IS_SUPPORTED
> ---
> drivers/gpu/drm/display/drm_dp_mst_topology.c | 4 +++-
> include/drm/display/drm_dp.h | 1 +
> include/drm/display/drm_dp_mst_helper.h | 3 +++
> 3 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 67b3b9697da7..71915afd9892 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -5921,8 +5921,10 @@ struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct
> drm_dp_mst_port *port)
> /* Enpoint decompression with DP-to-DP peer device */
> if ((endpoint_dsc & DP_DSC_DECOMPRESSION_IS_SUPPORTED) &&
> (endpoint_fec & DP_FEC_CAPABLE) &&
> - (upstream_dsc & 0x2) /* DSC passthrough */)
> + (upstream_dsc & DP_DSC_PASSTHROUGH_IS_SUPPORTED)) {
> + port->passthrough_aux = _upstream_port->aux;
> return >aux;
> + }
>
> /* Virtual DPCD decompression with DP-to-DP peer device */
> return _upstream_port->aux;
> diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
> index 9e3aff7e68bb..4d0abe4c7ea9 100644
> --- a/include/drm/display/drm_dp.h
> +++ b/include/drm/display/drm_dp.h
> @@ -239,6 +239,7 @@
>
> #define DP_DSC_SUPPORT 0x060 /* DP 1.4 */
> # define DP_DSC_DECOMPRESSION_IS_SUPPORTED (1 << 0)
> +# define DP_DSC_PASSTHROUGH_IS_SUPPORTED(1 << 1)
>
> #define DP_DSC_REV 0x061
> # define DP_DSC_MAJOR_MASK (0xf << 0)
> diff --git a/include/drm/display/drm_dp_mst_helper.h
> b/include/drm/display/drm_dp_mst_helper.h
> index 10adec068b7f..4a39c95f8afd 100644
> --- a/include/drm/display/drm_dp_mst_helper.h
> +++ b/include/drm/display/drm_dp_mst_helper.h
> @@ -86,6 +86,8 @@ struct drm_dp_vcpi {
> * @next: link to next port on this branch device
> * @aux: i2c aux transport to talk to device connected to this port,
> protected
> * by _dp_mst_topology_mgr.base.lock.
> + * @passthrough_aux: parent aux to which DSC pass-through requests should be
> + * sent, only set if DSC pass-through is possible.
> * @parent: branch device parent of this port
> * @vcpi: Virtual Channel Payload info for this port.
> * @connector: DRM connector this port is connected to. Protected by
> @@ -140,6 +142,7 @@ struct drm_dp_mst_port {
>*/
> struct drm_dp_mst_branch *mstb;
> struct drm_dp_aux aux; /* i2c bus for this port? */
> + struct drm_dp_aux *passthrough_aux;
> struct drm_dp_mst_branch *parent;
>
> struct drm_dp_vcpi vcpi;
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
[PATCH v2 3/3] drm/amd/display: implement DSC pass-through support
Currently, we only attempt to setup DSC at the virtual DPCD port,
however many modern displays come with DSC support and MST hubs can now
support DSC pass-through. So, to more optimally make use of the
available bandwidth, use DSC pass-through when possible by adding DSC
pass-through enablement support into the DSC enable sequence.
Signed-off-by: Hamza Mahfooz
---
v2: print the correct type of port that we are writing to using dsc_aux
in dm_helpers_dp_write_dsc_enable().
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 45 +--
1 file changed, 41 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index a0154a5f7183..bd364d2cc4f7 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -729,8 +729,14 @@ bool dm_helpers_dp_write_dsc_enable(
const struct dc_stream_state *stream,
bool enable)
{
- uint8_t enable_dsc = enable ? 1 : 0;
+ static const uint8_t DSC_DISABLE;
+ static const uint8_t DSC_DECODING = 0x01;
+ static const uint8_t DSC_PASSTHROUGH = 0x02;
+
struct amdgpu_dm_connector *aconnector;
+ struct drm_dp_mst_port *port;
+ uint8_t enable_dsc = enable ? DSC_DECODING : DSC_DISABLE;
+ uint8_t enable_passthrough = enable ? DSC_PASSTHROUGH : DSC_DISABLE;
uint8_t ret = 0;
if (!stream)
@@ -750,8 +756,39 @@ bool dm_helpers_dp_write_dsc_enable(
aconnector->dsc_aux, stream, enable_dsc);
#endif
- ret = drm_dp_dpcd_write(aconnector->dsc_aux, DP_DSC_ENABLE,
_dsc, 1);
- DC_LOG_DC("Send DSC %s to MST RX\n", enable_dsc ? "enable" :
"disable");
+ port = aconnector->port;
+
+ if (enable) {
+ if (port->passthrough_aux) {
+ ret = drm_dp_dpcd_write(port->passthrough_aux,
+ DP_DSC_ENABLE,
+ _passthrough, 1);
+ DC_LOG_DC("Sent DSC pass-through enable to
virtual dpcd port, ret = %u\n",
+ ret);
+ }
+
+ ret = drm_dp_dpcd_write(aconnector->dsc_aux,
+ DP_DSC_ENABLE, _dsc, 1);
+ DC_LOG_DC("Sent DSC decoding enable to %s port, ret =
%u\n",
+ (port->passthrough_aux) ? "remote RX" :
+ "virtual dpcd",
+ ret);
+ } else {
+ ret = drm_dp_dpcd_write(aconnector->dsc_aux,
+ DP_DSC_ENABLE, _dsc, 1);
+ DC_LOG_DC("Sent DSC decoding disable to %s port, ret =
%u\n",
+ (port->passthrough_aux) ? "remote RX" :
+ "virtual dpcd",
+ ret);
+
+ if (port->passthrough_aux) {
+ ret = drm_dp_dpcd_write(port->passthrough_aux,
+ DP_DSC_ENABLE,
+ _passthrough, 1);
+ DC_LOG_DC("Sent DSC pass-through disable to
virtual dpcd port, ret = %u\n",
+ ret);
+ }
+ }
}
if (stream->signal == SIGNAL_TYPE_DISPLAY_PORT || stream->signal ==
SIGNAL_TYPE_EDP) {
@@ -768,7 +805,7 @@ bool dm_helpers_dp_write_dsc_enable(
#endif
}
- return (ret > 0);
+ return ret;
}
bool dm_helpers_is_dp_sink_present(struct dc_link *link)
--
2.37.1
[PATCH v2 2/3] drm/amd/display: consider DSC pass-through during mode validation
Add a mode validation routine for DSC pass-through. Both the link from
source to hub, and the link from hub to monitor are checked, according
to the current link training result and full pbn returned by enum path
resource sideband message.
Pick up the minimum value as the bandwidth bottleneck for the end to
end link bandwidth constraint, and check if the maximum DSC decompression
bandwidth can fit.
Co-authored-by: Fangzhi Zuo
Signed-off-by: Hamza Mahfooz
---
v2: use multi-line comments, use a temp variable in kbps_from_pbn() and
add a debug print statement in dm_dp_mst_is_port_support_mode().
---
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 79 +--
1 file changed, 74 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 2e74ccf7df5b..ef6c94cd852b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -36,6 +36,7 @@
#include "dm_helpers.h"
#include "dc_link_ddc.h"
+#include "dc_link_dp.h"
#include "ddc_service_types.h"
#include "dpcd_defs.h"
@@ -1388,17 +1389,85 @@ bool pre_validate_dsc(struct drm_atomic_state *state,
#endif
+static unsigned int kbps_from_pbn(unsigned int pbn)
+{
+ unsigned int kbps = pbn;
+
+ kbps *= (100 / PEAK_FACTOR_X1000);
+ kbps *= 8;
+ kbps *= 54;
+ kbps /= 64;
+
+ return kbps;
+}
+
+static bool is_dsc_common_config_possible(struct dc_stream_state *stream,
+ struct dc_dsc_bw_range *bw_range)
+{
+ struct dc_dsc_policy dsc_policy = {0};
+
+ dc_dsc_get_policy_for_timing(>timing, 0, _policy);
+ dc_dsc_compute_bandwidth_range(stream->sink->ctx->dc->res_pool->dscs[0],
+
stream->sink->ctx->dc->debug.dsc_min_slice_height_override,
+ dsc_policy.min_target_bpp * 16,
+ dsc_policy.max_target_bpp * 16,
+ >sink->dsc_caps.dsc_dec_caps,
+ >timing, bw_range);
+
+ return bw_range->max_target_bpp_x16 && bw_range->min_target_bpp_x16;
+}
+
enum dc_status dm_dp_mst_is_port_support_mode(
struct amdgpu_dm_connector *aconnector,
struct dc_stream_state *stream)
{
+ struct dc_link_settings cur_link_settings;
+ unsigned int end_to_end_bw_in_kbps = 0;
+ unsigned int upper_link_bw_in_kbps = 0, down_link_bw_in_kbps = 0;
+ unsigned int max_compressed_bw_in_kbps = 0;
+ struct dc_dsc_bw_range bw_range = {0};
int bpp, pbn, branch_max_throughput_mps = 0;
- /* check if mode could be supported within fUll_pbn */
- bpp =
convert_dc_color_depth_into_bpc(stream->timing.display_color_depth) * 3;
- pbn = drm_dp_calc_pbn_mode(stream->timing.pix_clk_100hz / 10, bpp,
false);
- if (pbn > aconnector->port->full_pbn)
- return DC_FAIL_BANDWIDTH_VALIDATE;
+ /*
+* check if the mode could be supported if DSC pass-through is supported
+* AND check if there enough bandwidth available to support the mode
+* with DSC enabled.
+*/
+ if (is_dsc_common_config_possible(stream, _range) &&
+ aconnector->port->passthrough_aux) {
+ mutex_lock(>mst_mgr.lock);
+
+ cur_link_settings = stream->link->verified_link_cap;
+
+ upper_link_bw_in_kbps =
dc_link_bandwidth_kbps(aconnector->dc_link,
+
_link_settings
+ );
+ down_link_bw_in_kbps =
kbps_from_pbn(aconnector->port->full_pbn);
+
+ /* pick the bottleneck */
+ end_to_end_bw_in_kbps = min(upper_link_bw_in_kbps,
+ down_link_bw_in_kbps);
+
+ mutex_unlock(>mst_mgr.lock);
+
+ /*
+* use the maximum dsc compression bandwidth as the required
+* bandwidth for the mode
+*/
+ max_compressed_bw_in_kbps = bw_range.min_kbps;
+
+ if (end_to_end_bw_in_kbps < max_compressed_bw_in_kbps) {
+ DRM_DEBUG_DRIVER("Mode does not fit into DSC
pass-through bandwidth validation\n");
+ return DC_FAIL_BANDWIDTH_VALIDATE;
+ }
+ } else {
+ /* check if mode could be supported within full_pbn */
+ bpp =
convert_dc_color_depth_into_bpc(stream->timing.display_color_depth) * 3;
+ pbn = drm_dp_calc_pbn_mode(stream->timing.pix_clk_100hz / 10,
bpp, false);
+
+ if (pbn > aconnector->port->full_pbn)
+ return DC_FAIL_BANDWIDTH_VALIDATE;
+ }
/* check is mst dsc
[PATCH v2 1/3] drm/dp_mst: add passthrough_aux to struct drm_dp_mst_port
Currently, there is no way to identify if DSC pass-through can be
enabled and what aux DSC pass-through requests ought to be sent to. So,
add a variable to struct drm_dp_mst_port that keeps track of the
aforementioned information.
Signed-off-by: Hamza Mahfooz
---
v2: define DP_DSC_PASSTHROUGH_IS_SUPPORTED
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 4 +++-
include/drm/display/drm_dp.h | 1 +
include/drm/display/drm_dp_mst_helper.h | 3 +++
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 67b3b9697da7..71915afd9892 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -5921,8 +5921,10 @@ struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct
drm_dp_mst_port *port)
/* Enpoint decompression with DP-to-DP peer device */
if ((endpoint_dsc & DP_DSC_DECOMPRESSION_IS_SUPPORTED) &&
(endpoint_fec & DP_FEC_CAPABLE) &&
- (upstream_dsc & 0x2) /* DSC passthrough */)
+ (upstream_dsc & DP_DSC_PASSTHROUGH_IS_SUPPORTED)) {
+ port->passthrough_aux = _upstream_port->aux;
return >aux;
+ }
/* Virtual DPCD decompression with DP-to-DP peer device */
return _upstream_port->aux;
diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index 9e3aff7e68bb..4d0abe4c7ea9 100644
--- a/include/drm/display/drm_dp.h
+++ b/include/drm/display/drm_dp.h
@@ -239,6 +239,7 @@
#define DP_DSC_SUPPORT 0x060 /* DP 1.4 */
# define DP_DSC_DECOMPRESSION_IS_SUPPORTED (1 << 0)
+# define DP_DSC_PASSTHROUGH_IS_SUPPORTED(1 << 1)
#define DP_DSC_REV 0x061
# define DP_DSC_MAJOR_MASK (0xf << 0)
diff --git a/include/drm/display/drm_dp_mst_helper.h
b/include/drm/display/drm_dp_mst_helper.h
index 10adec068b7f..4a39c95f8afd 100644
--- a/include/drm/display/drm_dp_mst_helper.h
+++ b/include/drm/display/drm_dp_mst_helper.h
@@ -86,6 +86,8 @@ struct drm_dp_vcpi {
* @next: link to next port on this branch device
* @aux: i2c aux transport to talk to device connected to this port, protected
* by _dp_mst_topology_mgr.base.lock.
+ * @passthrough_aux: parent aux to which DSC pass-through requests should be
+ * sent, only set if DSC pass-through is possible.
* @parent: branch device parent of this port
* @vcpi: Virtual Channel Payload info for this port.
* @connector: DRM connector this port is connected to. Protected by
@@ -140,6 +142,7 @@ struct drm_dp_mst_port {
*/
struct drm_dp_mst_branch *mstb;
struct drm_dp_aux aux; /* i2c bus for this port? */
+ struct drm_dp_aux *passthrough_aux;
struct drm_dp_mst_branch *parent;
struct drm_dp_vcpi vcpi;
--
2.37.1
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Fri, Aug 5, 2022 at 7:56 AM Adam Ford wrote: > > On Fri, Aug 5, 2022 at 5:55 AM Adam Ford wrote: > > > > On Fri, Aug 5, 2022 at 3:44 AM Biju Das wrote: > > > > > > Hi Adam and all, > > > > > > > Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors > > > > > > > > On Thu, Aug 4, 2022 at 9:52 AM Dave Stevenson > > > > wrote: > > > > > > > > > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch > > > > wrote: > > > > > > > > > > > > Hi Dave, > > > > > > > > > > > > On 22-08-04, Dave Stevenson wrote: > > > > > > > Hi Marco > > > > > > > > > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch > > > > wrote: > > > > > > > > > > > > > > > > Hi Dave, Adam, > > > > > > > > > > > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > > > > > > Hi Adam > > > > > > > > > > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford > > > > wrote: > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > Did managed to get access to the ADV7535 programming > > > > > > > > > > > guide? This is the black box here. Let me check if I can > > > > > > > > > > > provide you a link with our repo so you can test our > > > > current DSIM state if you want. > > > > > > > > > > > > > > > > > > > > I do have access to the programming guide, but it's under > > > > > > > > > > NDA, but I'll try to answer questions if I can. > > > > > > > > > > > > > > > > > > Not meaning to butt in, but I have datasheets for ADV7533 and > > > > > > > > > 7535 from previously looking at these chips. > > > > > > > > > > > > > > > > Thanks for stepping into :) > > > > > > > > > > > > > > > > > Mine fairly plainly states: > > > > > > > > > "The DSI receiver input supports DSI video mode operation > > > > > > > > > only, and specifically, only supports nonburst mode with sync > > > > pulses". > > > > > > > > > > > > > > > > I've read this also, and we are working in nonburst mode with > > > > > > > > sync pulses. I have no access to an MIPI-DSI analyzer therefore > > > > > > > > I can't verify it. > > > > > > > > > > > > > > > > > Non-burst mode meaning that the DSI pixel rate MUST be the > > > > > > > > > same as the HDMI pixel rate. > > > > > > > > > > > > > > > > On DSI side you don't have a pixel-clock instead there is bit- > > > > clock. > > > > > > > > > > > > > > You have an effective pixel clock, with a fixed conversion for the > > > > > > > configuration. > > > > > > > > > > > > > > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate. > > > > > > > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s > > > > > > > > > > > > Okay, I just checked the bandwidth which must equal. > > > > > > > > > > > > > As noted elsewhere, the DSI is DDR, so the clock lane itself is > > > > > > > only running at 891 / 2 = 445.5MHz. > > > > > > > > > > > > > > > > Section 6.1.1 "DSI Input Modes" of > > > > > > > > > adv7533_hardware_user_s_guide is even more explicit about the > > > > > > > > > requirement of DSI timing matching > > > > > > > > > > > > > > > > Is it possible to share the key points of the requirements? > > > > > > > > > > > > > > "Specifically the ADV7533 supports the Non-Burst Mode with syncs. > > > > > > > This mode requires real time data generation as a pulse packet > > > > > > > received becomes a pulse generated. Therefore this mode requires a > > > > > > > continuous stream of data with correct video timing to avoid any > > > > > > > visual artifacts." > > > > > > > > > > > > > > LP mode is supported on data lanes. Clock lane must remain in HS > > > > mode. > > > > > > > > > > > > > > "... the goal is to accurately convey DPI-type timing over DSI. > > > > > > > This includes matching DPI pixel-transmission rates, and widths of > > > > > > > timing events." > > > > > > > > > > > > Thanks for sharing. > > > > > > > > > > > > > > > The NXP kernel switching down to an hs_clk of 445.5MHz would > > > > > > > > > therefore be correct for 720p operation. > > > > > > > > > > > > > > > > It should be absolute no difference if you work on 891MHz with 2 > > > > > > > > lanes or on 445.5 MHz with 4 lanes. What must be ensured is that > > > > > > > > you need the minimum required bandwidth which is roughly: > > > > > > > > 1280*720*24*60 = 1.327 GBps. > > > > > > > > > > > > > > Has someone changed the number of lanes in use? I'd missed that if > > > > > > > so, but I'll agree that 891MHz over 2 lanes should work for > > > > 720p60. > > > > > > > > > > > > The ADV driver is changing it autom. but this logic is somehow odd > > > > > > and there was already a approach to stop the driver doing this. > > > > > > > > > > I'd missed that bit in the driver where it appears to drop to 3 lanes > > > > > for pixel clock < 8 via a mipi_dsi_detach and _attach. Quirky, but > > > > > probably the only way it can be achieved in the current framework. > > > > > > > > > > > To sync up: we have two problems: > > > > > > 1) The 720P mode with static DSI host configuration isn't working > > > > > > without hacks. > > > > > > 2) The DSI link
[PULL] drm-intel-next (updated without the bad commit)
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 backport it for now. Sorry for the noise. And a big thanks to Mauro who noticed and pointed it out before the propagation. Here goes drm-intel-next-2022-08-05: - disable pci resize on 32-bit systems (Nirmoy) - don't leak the ccs state (Matt) - TLB invalidation fixes (Chris) [Excluding the bad commit drm/i915/gt: Batch TLB invalidations \ present on drm-intel-next-fixes-2022-08-04] Thanks, Rodrigo. The following changes since commit 5493ee1919eae4f49d62276cf5986b7f7c7aa8f6: Merge tag 'amd-drm-next-5.20-2022-07-29' of https://gitlab.freedesktop.org/agd5f/linux into drm-next (2022-08-03 14:00:19 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2022-08-05 for you to fetch changes up to fc30eea1542dd787c6aa46e970014e97e390c5b2: Merge drm/drm-next into drm-intel-next (2022-08-04 10:19:24 -0400) - disable pci resize on 32-bit systems (Nirmoy) - don't leak the ccs state (Matt) - TLB invalidation fixes (Chris) [Excluding the bad commit drm/i915/gt: Batch TLB invalidations \ present on drm-intel-next-fixes-2022-08-04] Ankit Nautiyal (1): drm/i915/hdmi: Prune modes that require HDMI2.1 FRL Anusha Srivatsa (3): drm/i915/display: Cleanup intel_phy_is_combo() drm/i915: Pass drm_i915_private struct instead of gt for gen11_gu_misc_irq_handler/ack() drm/i915/dg2: Add support for DC5 state Imre Deak (3): drm/i915/tgl+: Fix HDMI transcoder clock vs. DDI BUF disabling order drm/i915/d12+: Disable DMC handlers during loading/disabling the firmware drm/i915/d13: Add Wa_16015201720 disabling clock gating for PIPEDMC-A/B José Roberto de Souza (2): Revert "drm/i915/display: Ensure PSR gets disabled if no encoders in new state" drm/i915/psr: Disable PSR before disable pipe Jouni Högander (1): drm/i915/display: Ensure PSR gets disabled if no encoders in new state Madhumitha Tolakanahalli Pradeep (1): drm/i915/dmc: Update DG2 DMC firmware to v2.07 Matt Roper (1): drm/i915: Add Wa_14016291713 Rodrigo Vivi (1): Merge drm/drm-next into drm-intel-next Stanislav Lisovskiy (1): drm/i915/dg2: Bump up CDCLK for DG2 Swati Sharma (1): drm/i915/display: Add debug print for scaler filter drivers/gpu/drm/i915/display/intel_cdclk.c | 4 +- .../gpu/drm/i915/display/intel_crtc_state_dump.c | 9 ++-- drivers/gpu/drm/i915/display/intel_ddi.c | 6 ++- drivers/gpu/drm/i915/display/intel_display.c | 14 +++-- .../gpu/drm/i915/display/intel_display_debugfs.c | 5 +- drivers/gpu/drm/i915/display/intel_display_power.c | 13 - drivers/gpu/drm/i915/display/intel_dmc.c | 60 +++--- drivers/gpu/drm/i915/display/intel_dmc.h | 1 + drivers/gpu/drm/i915/display/intel_dmc_regs.h | 2 + drivers/gpu/drm/i915/display/intel_fbc.c | 6 +++ drivers/gpu/drm/i915/display/intel_hdmi.c | 9 drivers/gpu/drm/i915/display/intel_psr.c | 14 ++--- drivers/gpu/drm/i915/i915_irq.c| 16 +++--- drivers/gpu/drm/i915/i915_reg.h| 7 +++ 14 files changed, 126 insertions(+), 40 deletions(-)
Re: [Intel-gfx] [PULL] drm-intel-next-fixes
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 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 following changes since commit > > > > 2bc7ea71a73747a77e7f83bc085b0d2393235410: > > > > > > > > Merge tag 'topic/nouveau-misc-2022-07-27' of > > > > git://anongit.freedesktop.org/drm/drm into drm-next (2022-07-27 > > > > 11:34:07 +1000) > > > > > > > > are available in the Git repository at: > > > > > > > > git://anongit.freedesktop.org/drm/drm-intel > > > > tags/drm-intel-next-fixes-2022-08-04 > > > > > > > > for you to fetch changes up to e57b9369e0c6f60155027e120fafd4b57e385b71: > > > > > > > > drm/i915/gt: Batch TLB invalidations (2022-08-01 09:48:06 -0400) > > > > > > > > > > > > - disable pci resize on 32-bit systems (Nirmoy) > > > > - don't leak the ccs state (Matt) > > > > - TLB invalidation fixes (Chris) > > > > > > > > > > > > Chris Wilson (4): > > > > drm/i915/gt: Ignore TLB invalidations on idle engines > > > > drm/i915/gt: Invalidate TLB of the OA unit at TLB invalidations > > > > drm/i915/gt: Skip TLB invalidations once wedged > > > > > > > drm/i915/gt: Batch TLB invalidations > > > This patch actually adds a regression due to a silly mistake. > > > The fix is here: > > > > > > https://patchwork.freedesktop.org/patch/496249/?series=106805=4 > > > > > > > Thank you for the heads up. > > > > Since that patch is not merged yet, what are your recommendations here? > > Should I remove this from drm-intel-next-fixes now? > > Those patches are OK to merge: > >drm/i915/gt: Ignore TLB invalidations on idle engines >drm/i915/gt: Invalidate TLB of the OA unit at TLB invalidations >drm/i915/gt: Skip TLB invalidations once wedged > > And helps reduce performance regressions due to TLB cache invalidation. > So, I would keep them. > > With regards to the 4th patch, please don't merge: > > drm/i915/gt: Batch TLB invalidations > > or merge it together with: > > drm/i915: pass a pointer for tlb seqno at vma_invalidate_tlb() Since this one has not landed yet I won't rush it in. I'm removing the Batch TLB invalidations and sending a new pull request without that patch. Thank you for the info and great work there. > > > Which regression is worst? > > The regression caused by the batch patch is a lot worse, as it > effectively disables TLB cache invalidation. The fix was meant to > be merged at the patch, but somehow between several rebases and 3 > machines involved on tests, internal development and upstream, the > branch actually sent upstream was not the right one. It got only > noticed after reviewing a newer patch. Yeah, that sucks. > > > Also dim has trouble with fixes for fixes in the same round. > > Please ping me when you get that patch merged so I can pull that. > > OK. > > Regards, > Mauro
Re: [PATCH 3/5] drm/vkms: Support multiple objects (crtcs, etc.) per card
On Fri, Jul 22, 2022 at 05:32:11PM -0400, Jim Shargo wrote:
> This change supports multiple CRTCs, encoders, connectors instead of one
> of each per card.
>
> Since ConfigFS-based devices will support multiple crtcs, it's useful to
> move all of the writeback/composition data from being a per-output thing
> to being a per-CRTC thing.
>
> Since there's still only ever one CRTC, this should be a no-op refactor.
>
> Signed-off-by: Jim Shargo
> ---
Actual PATCH 3/5 review below :-)
> drivers/gpu/drm/vkms/vkms_composer.c | 28 +++
> drivers/gpu/drm/vkms/vkms_crtc.c | 91 +++--
> drivers/gpu/drm/vkms/vkms_drv.c | 3 +-
> drivers/gpu/drm/vkms/vkms_drv.h | 66 ++--
> drivers/gpu/drm/vkms/vkms_output.c| 110 ++
> drivers/gpu/drm/vkms/vkms_plane.c | 39 ++---
> drivers/gpu/drm/vkms/vkms_writeback.c | 25 +++---
> 7 files changed, 225 insertions(+), 137 deletions(-)
>
/snip
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index c1b632952532..d93678d984ae 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -11,35 +11,34 @@
>
> static enum hrtimer_restart vkms_vblank_simulate(struct hrtimer *timer)
> {
> - struct vkms_output *output = container_of(timer, struct vkms_output,
> - vblank_hrtimer);
> - struct drm_crtc *crtc = >crtc;
> + struct vkms_crtc *vkms_crtc = timer_to_vkms_crtc(timer);
> + struct drm_crtc *crtc = _crtc->base;
> struct vkms_crtc_state *state;
> u64 ret_overrun;
> bool ret, fence_cookie;
>
> fence_cookie = dma_fence_begin_signalling();
>
> - ret_overrun = hrtimer_forward_now(>vblank_hrtimer,
> - output->period_ns);
> + ret_overrun = hrtimer_forward_now(_crtc->vblank_hrtimer,
> + vkms_crtc->period_ns);
> if (ret_overrun != 1)
> pr_warn("%s: vblank timer overrun\n", __func__);
>
> - spin_lock(>lock);
> + spin_lock(_crtc->lock);
> ret = drm_crtc_handle_vblank(crtc);
> if (!ret)
> DRM_ERROR("vkms failure on handling vblank");
>
> - state = output->composer_state;
> - spin_unlock(>lock);
> + state = vkms_crtc->composer_state;
> + spin_unlock(_crtc->lock);
>
> - if (state && output->composer_enabled) {
> + if (state && vkms_crtc->composer_enabled) {
> u64 frame = drm_crtc_accurate_vblank_count(crtc);
>
> /* update frame_start only if a queued vkms_composer_worker()
>* has read the data
>*/
> - spin_lock(>composer_lock);
> + spin_lock(_crtc->composer_lock);
> if (!state->crc_pending)
> state->frame_start = frame;
> else
> @@ -47,9 +46,9 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
> hrtimer *timer)
>state->frame_start, frame);
> state->frame_end = frame;
> state->crc_pending = true;
> - spin_unlock(>composer_lock);
> + spin_unlock(_crtc->composer_lock);
>
> - ret = queue_work(output->composer_workq, >composer_work);
> + ret = queue_work(vkms_crtc->composer_workq,
> >composer_work);
> if (!ret)
> DRM_DEBUG_DRIVER("Composer worker already queued\n");
> }
> @@ -62,28 +61,24 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
> hrtimer *timer)
> static int vkms_enable_vblank(struct drm_crtc *crtc)
> {
> struct drm_device *dev = crtc->dev;
> - struct vkms_card *card = drm_device_to_vkms_card(dev);
> - struct vkms_output *out = >output;
> + struct vkms_crtc *vkms_crtc = drm_crtc_to_vkms_crtc(crtc);
> unsigned int pipe = drm_crtc_index(crtc);
> struct drm_vblank_crtc *vblank = >vblank[pipe];
>
> drm_calc_timestamping_constants(crtc, >mode);
>
> - hrtimer_init(>vblank_hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> - out->vblank_hrtimer.function = _vblank_simulate;
> - out->period_ns = ktime_set(0, vblank->framedur_ns);
> - hrtimer_start(>vblank_hrtimer, out->period_ns, HRTIMER_MODE_REL);
> + hrtimer_init(_crtc->vblank_hrtimer, CLOCK_MONOTONIC,
> HRTIMER_MODE_REL);
> + vkms_crtc->vblank_hrtimer.function = _vblank_simulate;
> + vkms_crtc->period_ns = ktime_set(0, vblank->framedur_ns);
> + hrtimer_start(_crtc->vblank_hrtimer, vkms_crtc->period_ns,
> HRTIMER_MODE_REL);
>
> return 0;
> }
>
> static void vkms_disable_vblank(struct drm_crtc *crtc)
> {
> - struct drm_device *dev = crtc->dev;
> - struct vkms_card *card = drm_device_to_vkms_card(dev);
> - struct vkms_output *out = >output;
> -
> - hrtimer_cancel(>vblank_hrtimer);
> + struct vkms_crtc *vkms_crtc =
Re: mainline build failure for x86_64 allmodconfig with clang
On Fri, Aug 5, 2022 at 8:02 PM Nathan Chancellor wrote: > On Fri, Aug 05, 2022 at 06:16:45PM +0200, Arnd Bergmann wrote: > > On Fri, Aug 5, 2022 at 5:32 PM Harry Wentland > > wrote: > > While splitting out sub-functions can help reduce the maximum stack > > usage, it seems that in this case it makes the actual problem worse: > > I see 2168 bytes for the combined > > dml32_ModeSupportAndSystemConfigurationFull(), but marking > > mode_support_configuration() as noinline gives me 1992 bytes > > for the outer function plus 384 bytes for the inner one. So it does > > avoid the warning (barely), but not the problem that the warning tries > > to point out. > > I haven't had a chance to take a look at splitting things up yet, would > you recommend a different approach? Splitting up large functions can help when you have large local variables that are used in different parts of the function, and the split gets the compiler to reuse stack locations. I think in this particular function, the problem isn't actually local variables but either pushing variables on the stack for argument passing, or something that causes the compiler to run out of registers so it has to spill registers to the stack. In either case, one has to actually look at the generated output and then try to rearrange the codes so this does not happen. One thing to try would be to condense a function call like dml32_CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport( >dummy_vars.dml32_CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport, mode_lib->vba.USRRetrainingRequiredFinal, mode_lib->vba.UsesMALLForPStateChange, mode_lib->vba.PrefetchModePerState[mode_lib->vba.VoltageLevel][mode_lib->vba.maxMpcComb], mode_lib->vba.NumberOfActiveSurfaces, mode_lib->vba.MaxLineBufferLines, mode_lib->vba.LineBufferSizeFinal, mode_lib->vba.WritebackInterfaceBufferSize, mode_lib->vba.DCFCLK, mode_lib->vba.ReturnBW, mode_lib->vba.SynchronizeTimingsFinal, mode_lib->vba.SynchronizeDRRDisplaysForUCLKPStateChangeFinal, mode_lib->vba.DRRDisplay, v->dpte_group_bytes, v->meta_row_height, v->meta_row_height_chroma, v->dummy_vars.DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation.mmSOCParameters, mode_lib->vba.WritebackChunkSize, mode_lib->vba.SOCCLK, v->DCFCLKDeepSleep, mode_lib->vba.DETBufferSizeY, mode_lib->vba.DETBufferSizeC, mode_lib->vba.SwathHeightY, mode_lib->vba.SwathHeightC, mode_lib->vba.LBBitPerPixel, v->SwathWidthY, v->SwathWidthC, mode_lib->vba.HRatio, mode_lib->vba.HRatioChroma, mode_lib->vba.vtaps, mode_lib->vba.VTAPsChroma, mode_lib->vba.VRatio, mode_lib->vba.VRatioChroma, mode_lib->vba.HTotal, mode_lib->vba.VTotal, mode_lib->vba.VActive, mode_lib->vba.PixelClock, mode_lib->vba.BlendingAndTiming, /* more arguments */); into calling conventions that take a pointer to 'mode_lib->vba' and another one to 'v', so these are no longer passed on the stack individually. Arnd
Re: [PATCH 2/5] drm/vkms: VKMS now supports more than one "card"
On Fri, Jul 22, 2022 at 05:32:10PM -0400, Jim Shargo wrote:
> This is a small refactor to make ConfigFS support easier.
>
> We now store the vkms_device statically, and maintain a list of
> "cards", each representing a different virtual DRM driver.
>
> We also make it clear when a card is "default", that is created at
> initialization, and not. This is because, due to limitations on what we
> can do with the configfs API, the default card won't be reflected in
> configfs and is initialized in a unique way.
>
> Since we're only managing a single card, this should be a no-op.
>
> Signed-off-by: Jim Shargo
Re-sending the review with the correct subject and reply-to. Let's use this one
for discussion and pretend the other one doesn't exist :-)
> ---
> drivers/gpu/drm/vkms/vkms_crtc.c | 11 +-
> drivers/gpu/drm/vkms/vkms_drv.c | 160 --
> drivers/gpu/drm/vkms/vkms_drv.h | 32 --
> drivers/gpu/drm/vkms/vkms_output.c| 25 ++--
> drivers/gpu/drm/vkms/vkms_plane.c | 4 +-
> drivers/gpu/drm/vkms/vkms_writeback.c | 20 ++--
> 6 files changed, 158 insertions(+), 94 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index 57bbd32e9beb..c1b632952532 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -62,9 +62,10 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
> hrtimer *timer)
> static int vkms_enable_vblank(struct drm_crtc *crtc)
> {
> struct drm_device *dev = crtc->dev;
> + struct vkms_card *card = drm_device_to_vkms_card(dev);
> + struct vkms_output *out = >output;
> unsigned int pipe = drm_crtc_index(crtc);
> struct drm_vblank_crtc *vblank = >vblank[pipe];
> - struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
>
> drm_calc_timestamping_constants(crtc, >mode);
>
> @@ -78,7 +79,9 @@ static int vkms_enable_vblank(struct drm_crtc *crtc)
>
> static void vkms_disable_vblank(struct drm_crtc *crtc)
> {
> - struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
> + struct drm_device *dev = crtc->dev;
> + struct vkms_card *card = drm_device_to_vkms_card(dev);
> + struct vkms_output *out = >output;
>
> hrtimer_cancel(>vblank_hrtimer);
> }
> @@ -88,9 +91,9 @@ static bool vkms_get_vblank_timestamp(struct drm_crtc *crtc,
> bool in_vblank_irq)
> {
> struct drm_device *dev = crtc->dev;
> + struct vkms_card *card = drm_device_to_vkms_card(dev);
> + struct vkms_output *output = >output;
> unsigned int pipe = crtc->index;
> - struct vkms_device *vkmsdev = drm_device_to_vkms_device(dev);
> - struct vkms_output *output = >output;
> struct drm_vblank_crtc *vblank = >vblank[pipe];
>
> if (!READ_ONCE(vblank->enabled)) {
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 81ed9417e511..92fbade2199b 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -9,9 +9,9 @@
> * the GPU in DRM API tests.
> */
>
> +#include
Unless you're using something directly from this header, it's probably best
not to include it as it pulls in a _lot_ of stuff.
> #include
> #include
> -#include
>
> #include
> #include
> @@ -37,7 +37,7 @@
> #define DRIVER_MAJOR 1
> #define DRIVER_MINOR 0
>
> -static struct vkms_device *vkms_device;
> +static struct vkms_device vkms_device;
>
> static bool enable_cursor = true;
> module_param_named(enable_cursor, enable_cursor, bool, 0444);
> @@ -55,9 +55,9 @@ DEFINE_DRM_GEM_FOPS(vkms_driver_fops);
>
> static void vkms_release(struct drm_device *dev)
> {
> - struct vkms_device *vkms = drm_device_to_vkms_device(dev);
> + struct vkms_card *card = drm_device_to_vkms_card(dev);
>
> - destroy_workqueue(vkms->output.composer_workq);
> + destroy_workqueue(card->output.composer_workq);
> }
>
> static void vkms_atomic_commit_tail(struct drm_atomic_state *old_state)
> @@ -91,9 +91,9 @@ static void vkms_atomic_commit_tail(struct drm_atomic_state
> *old_state)
>
> static int vkms_config_show(struct seq_file *m, void *data)
> {
> - seq_printf(m, "writeback=%d\n", vkms_device->config.writeback);
> - seq_printf(m, "cursor=%d\n", vkms_device->config.cursor);
> - seq_printf(m, "overlay=%d\n", vkms_device->config.overlay);
> + seq_printf(m, "writeback=%d\n", vkms_device.config.writeback);
> + seq_printf(m, "cursor=%d\n", vkms_device.config.cursor);
> + seq_printf(m, "overlay=%d\n", vkms_device.config.overlay);
>
> return 0;
> }
> @@ -133,9 +133,9 @@ static const struct drm_mode_config_helper_funcs
> vkms_mode_config_helpers = {
> .atomic_commit_tail = vkms_atomic_commit_tail,
> };
>
> -static int vkms_modeset_init(struct vkms_device *vkmsdev)
> +static int vkms_modeset_init(struct vkms_card *card)
> {
> - struct drm_device *dev = >drm;
> +
RE: [PATCH] drm/hyperv: Fix an error handling path in hyperv_vmbus_probe()
From: Christophe JAILLET Sent: Sunday, July 31,
2022 1:02 PM
>
> hyperv_setup_vram() calls vmbus_allocate_mmio().
> This must be undone in the error handling path of the probe, as already
> done in the remove function.
>
> This patch depends on commit a0ab5abced55 ("drm/hyperv : Removing the
> restruction of VRAM allocation with PCI bar size").
> Without it, something like what is done in commit e048834c209a
> ("drm/hyperv: Fix device removal on Gen1 VMs") should be done.
Should the above paragraph be below the '---' as a comment, rather than
part of the commit message? It's more about staging instructions than a
long-term record of the actual functional/code change.
>
> Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video
> device")
I wonder if the Fixes: dependency should be on a0ab5abced55. As you noted,
this patch won't apply cleanly on stable kernel versions that lack that commit,
so we'll need a separate patch for stable if we want to make the fix there.
> Signed-off-by: Christophe JAILLET
All that said, the fix looks good, so
Reviewed-by: Michael Kelley
> ---
> drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> index 6d11e7938c83..fc8b4e045f5d 100644
> --- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> +++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c
> @@ -133,7 +133,6 @@ static int hyperv_vmbus_probe(struct hv_device *hdev,
> }
>
> ret = hyperv_setup_vram(hv, hdev);
> -
> if (ret)
> goto err_vmbus_close;
>
> @@ -150,18 +149,20 @@ static int hyperv_vmbus_probe(struct hv_device *hdev,
>
> ret = hyperv_mode_config_init(hv);
> if (ret)
> - goto err_vmbus_close;
> + goto err_free_mmio;
>
> ret = drm_dev_register(dev, 0);
> if (ret) {
> drm_err(dev, "Failed to register drm driver.\n");
> - goto err_vmbus_close;
> + goto err_free_mmio;
> }
>
> drm_fbdev_generic_setup(dev, 0);
>
> return 0;
>
> +err_free_mmio:
> + vmbus_free_mmio(hv->mem->start, hv->fb_size);
> err_vmbus_close:
> vmbus_close(hdev->channel);
> err_hv_set_drv_data:
> --
> 2.34.1
Re: [PATCH 3/5] drm/vkms: Support multiple objects (crtcs, etc.) per card
On Fri, Aug 05, 2022 at 06:27:08PM +, Sean Paul wrote: > On Fri, Jul 22, 2022 at 05:32:10PM -0400, Jim Shargo wrote: > > This is a small refactor to make ConfigFS support easier. > > > > We now store the vkms_device statically, and maintain a list of > > "cards", each representing a different virtual DRM driver. > > > > We also make it clear when a card is "default", that is created at > > initialization, and not. This is because, due to limitations on what we > > can do with the configfs API, the default card won't be reflected in > > configfs and is initialized in a unique way. > > > > Since we're only managing a single card, this should be a no-op. > > > > Signed-off-by: Jim Shargo /snip What a mess, I replied to the wrong patch. The review here is targeting PATCH 2/5 despite the title and reply-to.
Re: [PATCH 3/5] drm/vkms: Support multiple objects (crtcs, etc.) per card
On Fri, Jul 22, 2022 at 05:32:10PM -0400, Jim Shargo wrote:
> This is a small refactor to make ConfigFS support easier.
>
> We now store the vkms_device statically, and maintain a list of
> "cards", each representing a different virtual DRM driver.
>
> We also make it clear when a card is "default", that is created at
> initialization, and not. This is because, due to limitations on what we
> can do with the configfs API, the default card won't be reflected in
> configfs and is initialized in a unique way.
>
> Since we're only managing a single card, this should be a no-op.
>
> Signed-off-by: Jim Shargo
> ---
> drivers/gpu/drm/vkms/vkms_crtc.c | 11 +-
> drivers/gpu/drm/vkms/vkms_drv.c | 160 --
> drivers/gpu/drm/vkms/vkms_drv.h | 32 --
> drivers/gpu/drm/vkms/vkms_output.c| 25 ++--
> drivers/gpu/drm/vkms/vkms_plane.c | 4 +-
> drivers/gpu/drm/vkms/vkms_writeback.c | 20 ++--
> 6 files changed, 158 insertions(+), 94 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index 57bbd32e9beb..c1b632952532 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -62,9 +62,10 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
> hrtimer *timer)
> static int vkms_enable_vblank(struct drm_crtc *crtc)
> {
> struct drm_device *dev = crtc->dev;
> + struct vkms_card *card = drm_device_to_vkms_card(dev);
> + struct vkms_output *out = >output;
> unsigned int pipe = drm_crtc_index(crtc);
> struct drm_vblank_crtc *vblank = >vblank[pipe];
> - struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
>
> drm_calc_timestamping_constants(crtc, >mode);
>
> @@ -78,7 +79,9 @@ static int vkms_enable_vblank(struct drm_crtc *crtc)
>
> static void vkms_disable_vblank(struct drm_crtc *crtc)
> {
> - struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
> + struct drm_device *dev = crtc->dev;
> + struct vkms_card *card = drm_device_to_vkms_card(dev);
> + struct vkms_output *out = >output;
>
> hrtimer_cancel(>vblank_hrtimer);
> }
> @@ -88,9 +91,9 @@ static bool vkms_get_vblank_timestamp(struct drm_crtc *crtc,
> bool in_vblank_irq)
> {
> struct drm_device *dev = crtc->dev;
> + struct vkms_card *card = drm_device_to_vkms_card(dev);
> + struct vkms_output *output = >output;
> unsigned int pipe = crtc->index;
> - struct vkms_device *vkmsdev = drm_device_to_vkms_device(dev);
> - struct vkms_output *output = >output;
> struct drm_vblank_crtc *vblank = >vblank[pipe];
>
> if (!READ_ONCE(vblank->enabled)) {
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 81ed9417e511..92fbade2199b 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -9,9 +9,9 @@
> * the GPU in DRM API tests.
> */
>
> +#include
Unless you're using something directly from this header, it's probably best not
to include it as it pulls in a _lot_ of stuff.
> #include
> #include
> -#include
>
> #include
> #include
> @@ -37,7 +37,7 @@
> #define DRIVER_MAJOR 1
> #define DRIVER_MINOR 0
>
> -static struct vkms_device *vkms_device;
> +static struct vkms_device vkms_device;
>
> static bool enable_cursor = true;
> module_param_named(enable_cursor, enable_cursor, bool, 0444);
> @@ -55,9 +55,9 @@ DEFINE_DRM_GEM_FOPS(vkms_driver_fops);
>
> static void vkms_release(struct drm_device *dev)
> {
> - struct vkms_device *vkms = drm_device_to_vkms_device(dev);
> + struct vkms_card *card = drm_device_to_vkms_card(dev);
>
> - destroy_workqueue(vkms->output.composer_workq);
> + destroy_workqueue(card->output.composer_workq);
> }
>
> static void vkms_atomic_commit_tail(struct drm_atomic_state *old_state)
> @@ -91,9 +91,9 @@ static void vkms_atomic_commit_tail(struct drm_atomic_state
> *old_state)
>
> static int vkms_config_show(struct seq_file *m, void *data)
> {
> - seq_printf(m, "writeback=%d\n", vkms_device->config.writeback);
> - seq_printf(m, "cursor=%d\n", vkms_device->config.cursor);
> - seq_printf(m, "overlay=%d\n", vkms_device->config.overlay);
> + seq_printf(m, "writeback=%d\n", vkms_device.config.writeback);
> + seq_printf(m, "cursor=%d\n", vkms_device.config.cursor);
> + seq_printf(m, "overlay=%d\n", vkms_device.config.overlay);
>
> return 0;
> }
> @@ -133,9 +133,9 @@ static const struct drm_mode_config_helper_funcs
> vkms_mode_config_helpers = {
> .atomic_commit_tail = vkms_atomic_commit_tail,
> };
>
> -static int vkms_modeset_init(struct vkms_device *vkmsdev)
> +static int vkms_modeset_init(struct vkms_card *card)
> {
> - struct drm_device *dev = >drm;
> + struct drm_device *dev = >drm;
>
> drm_mode_config_init(dev);
> dev->mode_config.funcs = _mode_funcs;
> @@ -151,89 +151,133 @@
Re: mainline build failure for x86_64 allmodconfig with clang
On Fri, Aug 05, 2022 at 06:16:45PM +0200, Arnd Bergmann wrote:
> On Fri, Aug 5, 2022 at 5:32 PM Harry Wentland wrote:
> > > I do notice that these files build with a non-configurable
> > > -Wframe-large-than value:
> > >
> > > $ rg frame_warn_flag drivers/gpu/drm/amd/display/dc/dml/Makefile
> > > 54:frame_warn_flag := -Wframe-larger-than=2048
> >
> > Tbh, I was looking at the history and I can't find a good reason this
> > was added. It should be safe to drop this. I would much rather use
> > the CONFIG_FRAME_WARN value than override it.
> >
> > AFAIK most builds use 2048 by default anyways.
>
> I'm fairly sure this was done for 32-bit builds, which default to a lower
> warning limit of 1024 bytes and would otherwise run into this
> problem when 64-bit platforms don't. With the default warning limit,
> clang warns even more about an i386 build:
>
> display/dc/dml/dcn20/display_rq_dlg_calc_20.c:1549:6: error: stack
> frame size (1324) exceeds limit (1024) in 'dml20_rq_dlg_get_dlg_reg'
> display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c:1550:6: error: stack
> frame size (1324) exceeds limit (1024) in 'dml20v2_rq_dlg_get_dlg_reg'
> display/dc/dml/dcn30/display_rq_dlg_calc_30.c:1742:6: error: stack
> frame size (1484) exceeds limit (1024) in 'dml30_rq_dlg_get_dlg_reg'
> display/dc/dml/dcn31/display_rq_dlg_calc_31.c:1571:6: error: stack
> frame size (1548) exceeds limit (1024) in 'dml31_rq_dlg_get_dlg_reg'
> display/dc/dml/dcn21/display_rq_dlg_calc_21.c:1657:6: error: stack
> frame size (1388) exceeds limit (1024) in 'dml21_rq_dlg_get_dlg_reg'
> display/dc/dml/dcn32/display_rq_dlg_calc_32.c:206:6: error: stack
> frame size (1276) exceeds limit (1024) in 'dml32_rq_dlg_get_dlg_reg'
> display/dc/dml/dcn31/display_mode_vba_31.c:2049:13: error: stack frame
> size (1468) exceeds limit (1024) in
> 'DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation'
> display/dc/dml/dcn20/display_mode_vba_20v2.c:1145:13: error: stack
> frame size (1228) exceeds limit (1024) in
> 'dml20v2_DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation'
> display/dc/dml/dcn20/display_mode_vba_20.c:1085:13: error: stack frame
> size (1340) exceeds limit (1024) in
> 'dml20_DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation'
> display/dc/dml/dcn31/display_mode_vba_31.c:3908:6: error: stack frame
> size (1996) exceeds limit (1024) in
> 'dml31_ModeSupportAndSystemConfigurationFull'
> display/dc/dml/dcn21/display_mode_vba_21.c:1466:13: error: stack frame
> size (1308) exceeds limit (1024) in
> 'DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation'
> display/dc/dml/dcn20/display_mode_vba_20v2.c:3393:6: error: stack
> frame size (1356) exceeds limit (1024) in
> 'dml20v2_ModeSupportAndSystemConfigurationFull'
> display/dc/dml/dcn20/display_mode_vba_20.c:3286:6: error: stack frame
> size (1468) exceeds limit (1024) in
> 'dml20_ModeSupportAndSystemConfigurationFull'
> display/dc/dml/dcn21/display_mode_vba_21.c:3518:6: error: stack frame
> size (1228) exceeds limit (1024) in
> 'dml21_ModeSupportAndSystemConfigurationFull'
> display/dc/dml/dcn30/display_mode_vba_30.c:1906:13: error: stack frame
> size (1436) exceeds limit (1024) in
> 'DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation'
> display/dc/dml/dcn30/display_mode_vba_30.c:3596:6: error: stack frame
> size (2092) exceeds limit (1024) in
> 'dml30_ModeSupportAndSystemConfigurationFull'
> > > I do note that commit 1b54a0121dba ("drm/amd/display: Reduce stack size
> > > in the mode support function") did have a workaround for GCC. It appears
> > > clang will still inline mode_support_configuration(). If I mark it as
> > > 'noinline', the warning disappears in that file.
> >
> > That'd be the best quick fix. I guess if we split out functions to fix
> > stack usage we should mark them as 'noinline' in the future to avoid
> > agressive compiler optimizations.
>
> While splitting out sub-functions can help reduce the maximum stack
> usage, it seems that in this case it makes the actual problem worse:
> I see 2168 bytes for the combined
> dml32_ModeSupportAndSystemConfigurationFull(), but marking
> mode_support_configuration() as noinline gives me 1992 bytes
> for the outer function plus 384 bytes for the inner one. So it does
> avoid the warning (barely), but not the problem that the warning tries
> to point out.
I haven't had a chance to take a look at splitting things up yet, would
you recommend a different approach?
Cheers,
Nathan
Re: [PATCH 00/12] drm/format-helper: Move to struct iosys_map
Hi Thomas, On Wed, Jul 27, 2022 at 01:33:00PM +0200, Thomas Zimmermann wrote: > Change format-conversion helpers to use struct iosys_map for source > and destination buffers. Update all users. Also prepare interface for > multi-plane color formats. > > The format-conversion helpers mostly used to convert to I/O memory > or system memory. To actual memory type depended on the usecase. We > now have drivers upcomming that do the conversion entirely in system > memory. It's a good opportunity to stream-line the interface of the > conversion helpers to use struct iosys_map. Source and destination > buffers can now be either in system or in I/O memory. Thanks for looking into this - I like how we hide the memory details in the helpers (system vs io). And unifying the system and io variants makes the API simpler - also good. > Note that the > implementation still only supports source buffers in system memory. Yeah, I noted this in my feedback but realized only now that it is written here. I left a few comments (details only) in some of the patches, most are reviewed without comments. There is a few general things - mostly bikeshedding about naming and such. As usual ignore what you think is irrelevant. Sam
Re: [PATCH 12/12] drm/format-helper: Move destination-buffer handling into internal helper
Hi Thomas,
On Wed, Jul 27, 2022 at 01:33:12PM +0200, Thomas Zimmermann wrote:
> The format-convertion helpers handle several cases for different
> values of destination buffer and pitch. Move that code into the
> internal helper drm_fb_xfrm() and avoid quite a bit of duplucation.
This is very nice patch that should come before all the conversion
patches - but then you have had to come up with another name.
So I think this is fine.
A few comments below, mostly in the same area as the comments from José.
Sam
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_format_helper.c | 169 +++-
> 1 file changed, 64 insertions(+), 105 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index d296d181659d..35aebdb90165 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -41,11 +41,11 @@ unsigned int drm_fb_clip_offset(unsigned int pitch, const
> struct drm_format_info
> }
> EXPORT_SYMBOL(drm_fb_clip_offset);
>
> -/* TODO: Make this functon work with multi-plane formats. */
> -static int drm_fb_xfrm(void *dst, unsigned long dst_pitch, unsigned long
> dst_pixsize,
> -const void *vaddr, const struct drm_framebuffer *fb,
> -const struct drm_rect *clip, bool vaddr_cached_hint,
> -void (*xfrm_line)(void *dbuf, const void *sbuf, unsigned
> int npixels))
> +/* TODO: Make this function work with multi-plane formats. */
> +static int __drm_fb_xfrm(void *dst, unsigned long dst_pitch, unsigned long
> dst_pixsize,
> + const void *vaddr, const struct drm_framebuffer *fb,
> + const struct drm_rect *clip, bool vaddr_cached_hint,
> + void (*xfrm_line)(void *dbuf, const void *sbuf,
> unsigned int npixels))
> {
> unsigned long linepixels = drm_rect_width(clip);
> unsigned long lines = drm_rect_height(clip);
> @@ -84,11 +84,11 @@ static int drm_fb_xfrm(void *dst, unsigned long
> dst_pitch, unsigned long dst_pix
> return 0;
> }
>
> -/* TODO: Make this functon work with multi-plane formats. */
> -static int drm_fb_xfrm_toio(void __iomem *dst, unsigned long dst_pitch,
> unsigned long dst_pixsize,
> - const void *vaddr, const struct drm_framebuffer *fb,
> - const struct drm_rect *clip, bool vaddr_cached_hint,
> - void (*xfrm_line)(void *dbuf, const void *sbuf,
> unsigned int npixels))
> +/* TODO: Make this function work with multi-plane formats. */
> +static int __drm_fb_xfrm_toio(void __iomem *dst, unsigned long dst_pitch,
> unsigned long dst_pixsize,
> + const void *vaddr, const struct drm_framebuffer
> *fb,
> + const struct drm_rect *clip, bool
> vaddr_cached_hint,
> + void (*xfrm_line)(void *dbuf, const void *sbuf,
> unsigned int npixels))
> {
> unsigned long linepixels = drm_rect_width(clip);
> unsigned long lines = drm_rect_height(clip);
> @@ -129,6 +129,29 @@ static int drm_fb_xfrm_toio(void __iomem *dst, unsigned
> long dst_pitch, unsigned
> return 0;
> }
>
> +/* TODO: Make this function work with multi-plane formats. */
> +static int drm_fb_xfrm(struct iosys_map *dst,
> +const unsigned int *dst_pitch, const u8 *dst_pixsize,
> +const struct iosys_map *vmap, const struct
> drm_framebuffer *fb,
> +const struct drm_rect *clip, bool vaddr_cached_hint,
> +void (*xfrm_line)(void *dbuf, const void *sbuf, unsigned
> int npixels))
> +{
Just to repeat myself a little, this assumes src (vmap) is always system
memory (not io).
> + static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> + 0, 0, 0, 0
> + };
> +
> + if (!dst_pitch)
> + dst_pitch = default_dst_pitch;
> +
> + if (dst[0].is_iomem)
> + return __drm_fb_xfrm_toio(dst[0].vaddr_iomem, dst_pitch[0],
> dst_pixsize[0],
> + vmap[0].vaddr, fb, clip, false,
> xfrm_line);
> + else
> + return __drm_fb_xfrm(dst[0].vaddr, dst_pitch[0], dst_pixsize[0],
> + vmap[0].vaddr, fb, clip, false, xfrm_line);
It looks like vaddr_cached_hint is always false, so can we remove it?
> +}
> +
> +
> /**
> * drm_fb_memcpy - Copy clip buffer
> * @dst: Array of destination buffers
> @@ -213,14 +236,10 @@ void drm_fb_swab(struct iosys_map *dst, const unsigned
> int *dst_pitch,
>const struct iosys_map *vmap, const struct drm_framebuffer *fb,
>const struct drm_rect *clip, bool cached)
> {
> - static const unsigned int default_dst_pitch[DRM_FORMAT_MAX_PLANES] = {
> - 0, 0, 0, 0
> - };
> const struct drm_format_info *format = fb->format;
Re: [PATCH 0/3] Fix bugs in *_set_par() caused by user input
On 8/4/22 14:41, Zheyu Ma wrote: > In the function *_set_par(), the value of 'screen_size' is > calculated by the user input. If the user provides the improper value, > the value of 'screen_size' may larger than 'info->screen_size', which > may cause a bug in the memset_io(). > > Zheyu Ma (3): > video: fbdev: vt8623fb: Check the size of screen before memset_io() > video: fbdev: arkfb: Check the size of screen before memset_io() > video: fbdev: s3fb: Check the size of screen before memset_io() applied all 3 patches to fbdev git tree. Thanks! Helge > > drivers/video/fbdev/arkfb.c| 2 ++ > drivers/video/fbdev/s3fb.c | 2 ++ > drivers/video/fbdev/vt8623fb.c | 2 ++ > 3 files changed, 6 insertions(+) >
Re: mainline build failure for x86_64 allmodconfig with clang
On Fri, Aug 5, 2022 at 5:32 PM Harry Wentland wrote:
> > I do notice that these files build with a non-configurable
> > -Wframe-large-than value:
> >
> > $ rg frame_warn_flag drivers/gpu/drm/amd/display/dc/dml/Makefile
> > 54:frame_warn_flag := -Wframe-larger-than=2048
>
> Tbh, I was looking at the history and I can't find a good reason this
> was added. It should be safe to drop this. I would much rather use
> the CONFIG_FRAME_WARN value than override it.
>
> AFAIK most builds use 2048 by default anyways.
I'm fairly sure this was done for 32-bit builds, which default to a lower
warning limit of 1024 bytes and would otherwise run into this
problem when 64-bit platforms don't. With the default warning limit,
clang warns even more about an i386 build:
display/dc/dml/dcn20/display_rq_dlg_calc_20.c:1549:6: error: stack
frame size (1324) exceeds limit (1024) in 'dml20_rq_dlg_get_dlg_reg'
display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c:1550:6: error: stack
frame size (1324) exceeds limit (1024) in 'dml20v2_rq_dlg_get_dlg_reg'
display/dc/dml/dcn30/display_rq_dlg_calc_30.c:1742:6: error: stack
frame size (1484) exceeds limit (1024) in 'dml30_rq_dlg_get_dlg_reg'
display/dc/dml/dcn31/display_rq_dlg_calc_31.c:1571:6: error: stack
frame size (1548) exceeds limit (1024) in 'dml31_rq_dlg_get_dlg_reg'
display/dc/dml/dcn21/display_rq_dlg_calc_21.c:1657:6: error: stack
frame size (1388) exceeds limit (1024) in 'dml21_rq_dlg_get_dlg_reg'
display/dc/dml/dcn32/display_rq_dlg_calc_32.c:206:6: error: stack
frame size (1276) exceeds limit (1024) in 'dml32_rq_dlg_get_dlg_reg'
display/dc/dml/dcn31/display_mode_vba_31.c:2049:13: error: stack frame
size (1468) exceeds limit (1024) in
'DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation'
display/dc/dml/dcn20/display_mode_vba_20v2.c:1145:13: error: stack
frame size (1228) exceeds limit (1024) in
'dml20v2_DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation'
display/dc/dml/dcn20/display_mode_vba_20.c:1085:13: error: stack frame
size (1340) exceeds limit (1024) in
'dml20_DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation'
display/dc/dml/dcn31/display_mode_vba_31.c:3908:6: error: stack frame
size (1996) exceeds limit (1024) in
'dml31_ModeSupportAndSystemConfigurationFull'
display/dc/dml/dcn21/display_mode_vba_21.c:1466:13: error: stack frame
size (1308) exceeds limit (1024) in
'DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation'
display/dc/dml/dcn20/display_mode_vba_20v2.c:3393:6: error: stack
frame size (1356) exceeds limit (1024) in
'dml20v2_ModeSupportAndSystemConfigurationFull'
display/dc/dml/dcn20/display_mode_vba_20.c:3286:6: error: stack frame
size (1468) exceeds limit (1024) in
'dml20_ModeSupportAndSystemConfigurationFull'
display/dc/dml/dcn21/display_mode_vba_21.c:3518:6: error: stack frame
size (1228) exceeds limit (1024) in
'dml21_ModeSupportAndSystemConfigurationFull'
display/dc/dml/dcn30/display_mode_vba_30.c:1906:13: error: stack frame
size (1436) exceeds limit (1024) in
'DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation'
display/dc/dml/dcn30/display_mode_vba_30.c:3596:6: error: stack frame
size (2092) exceeds limit (1024) in
'dml30_ModeSupportAndSystemConfigurationFull'
> > I do note that commit 1b54a0121dba ("drm/amd/display: Reduce stack size
> > in the mode support function") did have a workaround for GCC. It appears
> > clang will still inline mode_support_configuration(). If I mark it as
> > 'noinline', the warning disappears in that file.
>
> That'd be the best quick fix. I guess if we split out functions to fix
> stack usage we should mark them as 'noinline' in the future to avoid
> agressive compiler optimizations.
While splitting out sub-functions can help reduce the maximum stack
usage, it seems that in this case it makes the actual problem worse:
I see 2168 bytes for the combined
dml32_ModeSupportAndSystemConfigurationFull(), but marking
mode_support_configuration() as noinline gives me 1992 bytes
for the outer function plus 384 bytes for the inner one. So it does
avoid the warning (barely), but not the problem that the warning tries
to point out.
Arnd
[PATCH v3 0/2] Sanitycheck PCI BARs
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 use. This is an evolution of the concept I presented in the patch: https://patchwork.freedesktop.org/patch/470184/?series=99094 The main difference between the original patch and what I have prepared here is that previously I checked all BARs at the beginning of i915 initialization, and now I only check BAR 0 at beginning. This is due to the fact that I have noticed that it can happen that only BAR 0 is available (I have observed this in the case of virtualization, on some platforms). Therefore, at the beginning, let's verify only BAR 0, and the others only before the first use. v2: Fix build v3: replace header linux/pci.h to forward declaration for struct pci_dev Signed-off-by: Piotr Piórkowski Cc: Jani Nikula Cc: Lucas De Marchi Cc: Matt Roper Piotr Piórkowski (2): drm/i915: Use of BARs names instead of numbers drm/i915: Sanitycheck PCI BARs .../gpu/drm/i915/display/intel_lpe_audio.c| 5 ++-- drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 11 +--- drivers/gpu/drm/i915/gt/intel_ggtt.c | 16 +--- drivers/gpu/drm/i915/gt/intel_gt.c| 3 ++- drivers/gpu/drm/i915/gt/intel_region_lmem.c | 17 +++-- drivers/gpu/drm/i915/gvt/cfg_space.c | 5 ++-- drivers/gpu/drm/i915/i915_pci.c | 25 +++ drivers/gpu/drm/i915/i915_pci.h | 6 + drivers/gpu/drm/i915/intel_pci_config.h | 7 ++ 9 files changed, 76 insertions(+), 19 deletions(-) -- 2.25.1
[PATCH v3 2/2] drm/i915: Sanitycheck PCI BARs
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 i915
initialization.
For other BARs, let's validate before first use.
Signed-off-by: Piotr Piórkowski
Cc: Jani Nikula
Cc: Lucas De Marchi
Cc: Matt Roper
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 4
drivers/gpu/drm/i915/gt/intel_ggtt.c| 7 ++
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 4
drivers/gpu/drm/i915/i915_pci.c | 25 +
drivers/gpu/drm/i915/i915_pci.h | 6 +
5 files changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index c369cfd185bc..4f4c9461a23b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -18,6 +18,7 @@
#include "gt/intel_region_lmem.h"
#include "i915_drv.h"
#include "i915_gem_stolen.h"
+#include "i915_pci.h"
#include "i915_reg.h"
#include "i915_utils.h"
#include "i915_vgpu.h"
@@ -828,6 +829,9 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915,
u16 type,
if (WARN_ON_ONCE(instance))
return ERR_PTR(-ENODEV);
+ if (!i915_pci_resource_valid(pdev, GEN12_LMEM_BAR))
+ return ERR_PTR(-ENXIO);
+
/* Use DSM base address instead for stolen memory */
dsm_base = intel_uncore_read64(uncore, GEN12_DSMBASE);
if (IS_DG1(uncore->i915)) {
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 8214e07a0f5b..30cf5c3369d9 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -18,6 +18,7 @@
#include "intel_gt_regs.h"
#include "intel_pci_config.h"
#include "i915_drv.h"
+#include "i915_pci.h"
#include "i915_scatterlist.h"
#include "i915_utils.h"
#include "i915_vgpu.h"
@@ -931,6 +932,9 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
u16 snb_gmch_ctl;
if (!HAS_LMEM(i915)) {
+ if (!i915_pci_resource_valid(pdev, GTT_APERTURE_BAR))
+ return -ENXIO;
+
ggtt->gmadr = pci_resource(pdev, GTT_APERTURE_BAR);
ggtt->mappable_end = resource_size(>gmadr);
}
@@ -1085,6 +1089,9 @@ static int gen6_gmch_probe(struct i915_ggtt *ggtt)
unsigned int size;
u16 snb_gmch_ctl;
+ if (!i915_pci_resource_valid(pdev, GTT_APERTURE_BAR))
+ return -ENXIO;
+
ggtt->gmadr = pci_resource(pdev, GTT_APERTURE_BAR);
ggtt->mappable_end = resource_size(>gmadr);
diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index 1e79d3c8b126..f3ad93db0b21 100644
--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
@@ -4,6 +4,7 @@
*/
#include "i915_drv.h"
+#include "i915_pci.h"
#include "i915_reg.h"
#include "intel_memory_region.h"
#include "intel_pci_config.h"
@@ -201,6 +202,9 @@ static struct intel_memory_region *setup_lmem(struct
intel_gt *gt)
if (!IS_DGFX(i915))
return ERR_PTR(-ENODEV);
+ if (!i915_pci_resource_valid(pdev, GEN12_LMEM_BAR))
+ return ERR_PTR(-ENXIO);
+
if (HAS_FLAT_CCS(i915)) {
resource_size_t lmem_range;
u64 tile_stolen, flat_ccs_base;
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index aacc10f2e73f..9fd788e147a3 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -30,6 +30,7 @@
#include "i915_drv.h"
#include "i915_pci.h"
#include "i915_reg.h"
+#include "intel_pci_config.h"
#define PLATFORM(x) .platform = (x)
#define GEN(x) \
@@ -1262,6 +1263,27 @@ static bool force_probe(u16 device_id, const char
*devices)
return ret;
}
+bool i915_pci_resource_valid(struct pci_dev *pdev, int bar)
+{
+ if (!pci_resource_flags(pdev, bar))
+ return false;
+
+ if (pci_resource_flags(pdev, bar) & IORESOURCE_UNSET)
+ return false;
+
+ if (!pci_resource_len(pdev, bar))
+ return false;
+
+ return true;
+}
+
+static bool intel_mmio_bar_valid(struct pci_dev *pdev, struct
intel_device_info *intel_info)
+{
+ int gttmmaddr_bar = intel_info->graphics.ver == 2 ? GEN2_GTTMMADR_BAR :
GTTMMADR_BAR;
+
+ return i915_pci_resource_valid(pdev, gttmmaddr_bar);
+}
+
static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id
*ent)
{
struct intel_device_info *intel_info =
@@ -1287,6 +1309,9 @@ static int i915_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (PCI_FUNC(pdev->devfn))
return -ENODEV;
+
[PATCH v3 1/2] drm/i915: Use of BARs names instead of numbers
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 cfg_space.c
Signed-off-by: Piotr Piórkowski
Cc: Jani Nikula
Cc: Lucas De Marchi
Cc: Matt Roper
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_lpe_audio.c | 5 +++--
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 7 ---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 9 +
drivers/gpu/drm/i915/gt/intel_gt.c | 3 ++-
drivers/gpu/drm/i915/gt/intel_region_lmem.c| 13 ++---
drivers/gpu/drm/i915/gvt/cfg_space.c | 5 +++--
drivers/gpu/drm/i915/intel_pci_config.h| 7 +++
7 files changed, 30 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_lpe_audio.c
b/drivers/gpu/drm/i915/display/intel_lpe_audio.c
index 4970bf146c4a..1e18696aaecf 100644
--- a/drivers/gpu/drm/i915/display/intel_lpe_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_lpe_audio.c
@@ -73,6 +73,7 @@
#include "i915_drv.h"
#include "intel_de.h"
#include "intel_lpe_audio.h"
+#include "intel_pci_config.h"
#define HAS_LPE_AUDIO(dev_priv) ((dev_priv)->audio.lpe.platdev != NULL)
@@ -100,9 +101,9 @@ lpe_audio_platdev_create(struct drm_i915_private *dev_priv)
rsc[0].flags= IORESOURCE_IRQ;
rsc[0].name = "hdmi-lpe-audio-irq";
- rsc[1].start= pci_resource_start(pdev, 0) +
+ rsc[1].start= pci_resource_start(pdev, GTTMMADR_BAR) +
I915_HDMI_LPE_AUDIO_BASE;
- rsc[1].end = pci_resource_start(pdev, 0) +
+ rsc[1].end = pci_resource_start(pdev, GTTMMADR_BAR) +
I915_HDMI_LPE_AUDIO_BASE + I915_HDMI_LPE_AUDIO_SIZE - 1;
rsc[1].flags= IORESOURCE_MEM;
rsc[1].name = "hdmi-lpe-audio-mmio";
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 166d0a4b9e8c..c369cfd185bc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -22,6 +22,7 @@
#include "i915_utils.h"
#include "i915_vgpu.h"
#include "intel_mchbar_regs.h"
+#include "intel_pci_config.h"
/*
* The BIOS typically reserves some of the system's memory for the exclusive
@@ -830,7 +831,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915,
u16 type,
/* Use DSM base address instead for stolen memory */
dsm_base = intel_uncore_read64(uncore, GEN12_DSMBASE);
if (IS_DG1(uncore->i915)) {
- lmem_size = pci_resource_len(pdev, 2);
+ lmem_size = pci_resource_len(pdev, GEN12_LMEM_BAR);
if (WARN_ON(lmem_size < dsm_base))
return ERR_PTR(-ENODEV);
} else {
@@ -842,11 +843,11 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915,
u16 type,
}
dsm_size = lmem_size - dsm_base;
- if (pci_resource_len(pdev, 2) < lmem_size) {
+ if (pci_resource_len(pdev, GEN12_LMEM_BAR) < lmem_size) {
io_start = 0;
io_size = 0;
} else {
- io_start = pci_resource_start(pdev, 2) + dsm_base;
+ io_start = pci_resource_start(pdev, GEN12_LMEM_BAR) + dsm_base;
io_size = dsm_size;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 15a915bb4088..8214e07a0f5b 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -16,6 +16,7 @@
#include "intel_ggtt_gmch.h"
#include "intel_gt.h"
#include "intel_gt_regs.h"
+#include "intel_pci_config.h"
#include "i915_drv.h"
#include "i915_scatterlist.h"
#include "i915_utils.h"
@@ -869,8 +870,8 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64
size)
u32 pte_flags;
int ret;
- GEM_WARN_ON(pci_resource_len(pdev, 0) != gen6_gttmmadr_size(i915));
- phys_addr = pci_resource_start(pdev, 0) + gen6_gttadr_offset(i915);
+ GEM_WARN_ON(pci_resource_len(pdev, GTTMMADR_BAR) !=
gen6_gttmmadr_size(i915));
+ phys_addr = pci_resource_start(pdev, GTTMMADR_BAR) +
gen6_gttadr_offset(i915);
/*
* On BXT+/ICL+ writes larger than 64 bit to the GTT pagetable range
@@ -930,7 +931,7 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
u16 snb_gmch_ctl;
if (!HAS_LMEM(i915)) {
- ggtt->gmadr = pci_resource(pdev, 2);
+ ggtt->gmadr = pci_resource(pdev, GTT_APERTURE_BAR);
ggtt->mappable_end = resource_size(>gmadr);
}
@@ -1084,7 +1085,7 @@ static int gen6_gmch_probe(struct i915_ggtt *ggtt)
unsigned int size;
u16 snb_gmch_ctl;
- ggtt->gmadr = pci_resource(pdev, 2);
+ ggtt->gmadr = pci_resource(pdev, GTT_APERTURE_BAR);
Re: [PATCH 2/3] dt-bindings: reserved-memory: add linaro,secure-heap
+Rob and devicetree list.
I don't know if this should be "linaro" or something more generic,
and also where previous discussions got to about DMA heaps in DT.
Cheers,
-Brian
On Fri, Aug 05, 2022 at 03:53:29PM +0200, Olivier Masse wrote:
> DMABUF Reserved memory definition for OP-TEE SDP feaure.
>
> Signed-off-by: Olivier Masse
> ---
> .../reserved-memory/linaro,secure-heap.yaml | 56 +++
> 1 file changed, 56 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/reserved-memory/linaro,secure-heap.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/reserved-memory/linaro,secure-heap.yaml
> b/Documentation/devicetree/bindings/reserved-memory/linaro,secure-heap.yaml
> new file mode 100644
> index ..80522a4e2989
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/reserved-memory/linaro,secure-heap.yaml
> @@ -0,0 +1,56 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/reserved-memory/linaro,secure-heap.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Linaro Secure DMABUF Heap
> +
> +maintainers:
> + - Olivier Masse
> +
> +description:
> + Linaro OP-TEE firmware needs a reserved memory for the
> + Secure Data Path feature (aka SDP).
> + The purpose is to provide a secure memory heap which allow
> + non-secure OS to allocate/free secure buffers.
> + The TEE is reponsible for protecting the SDP memory buffers.
> + TEE Trusted Application can access secure memory references
> + provided as parameters (DMABUF file descriptor).
> +
> +allOf:
> + - $ref: "reserved-memory.yaml"
> +
> +properties:
> + compatible:
> +const: linaro,secure-heap
> +
> + reg:
> +description:
> + Region of memory reserved for OP-TEE SDP feature
> +
> + no-map:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description:
> + Avoid creating a virtual mapping of the region as part of the OS'
> + standard mapping of system memory.
> +
> +unevaluatedProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - no-map
> +
> +examples:
> + - |
> + reserved-memory {
> +#address-cells = <2>;
> +#size-cells = <2>;
> +
> +sdp@3e80 {
> + compatible = "linaro,secure-heap";
> + no-map;
> + reg = <0 0x3E80 0 0x0040>;
> +};
> + };
> --
> 2.25.0
>
Re: [PATCH 1/3] dma-buf: heaps: add Linaro secure dmabuf heap support
Hi Olivier,
Thanks, I think this is looking much better.
I'd like to know how others feel about landing this heap; there's been
push-back in the past about heaps in device-tree and discussions
around how "custom" heaps should be treated (though IMO this is quite
a generic one).
On Fri, Aug 05, 2022 at 03:53:28PM +0200, Olivier Masse wrote:
> add Linaro secure heap bindings: linaro,secure-heap
> use genalloc to allocate/free buffer from buffer pool.
> buffer pool info is from dts.
> use sg_table instore the allocated memory info, the length of sg_table is 1.
> implement secure_heap_buf_ops to implement buffer share in difference device:
> 1. Userspace passes this fd to all drivers it wants this buffer
> to share with: First the filedescriptor is converted to a _buf using
> dma_buf_get(). Then the buffer is attached to the device using
> dma_buf_attach().
> 2. Once the buffer is attached to all devices userspace can initiate DMA
> access to the shared buffer. In the kernel this is done by calling
> dma_buf_map_attachment()
> 3. get sg_table with dma_buf_map_attachment in difference device.
>
I think this commit message could use a little rework. A few thoughts:
* The bindings are in a separate commit, so seems strange to mention
here.
* "buffer pool info is from dts" --> I think you should mention that
this uses a reserved-memory region.
* sg_table nents and genalloc seem like low-level implementation
details, so probably not needed in the commit message
* The usage steps 1, 2, 3 aren't specific to this heap - that's how
all dma-buf sharing works.
> Signed-off-by: Olivier Masse
> ---
> drivers/dma-buf/heaps/Kconfig | 9 +
> drivers/dma-buf/heaps/Makefile | 1 +
> drivers/dma-buf/heaps/secure_heap.c | 357
> 3 files changed, 367 insertions(+)
> create mode 100644 drivers/dma-buf/heaps/secure_heap.c
>
> diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
> index 3782eeeb91c0..c9070c728b9a 100644
> --- a/drivers/dma-buf/heaps/Kconfig
> +++ b/drivers/dma-buf/heaps/Kconfig
> @@ -20,3 +20,12 @@ config DMABUF_HEAPS_DSP
>Choose this option to enable the dsp dmabuf heap. The dsp heap
>is allocated by gen allocater. it's allocated according the dts.
>If in doubt, say Y.
> +
> +config DMABUF_HEAPS_SECURE
> + tristate "DMA-BUF Secure Heap"
> + depends on DMABUF_HEAPS
> + help
> + Choose this option to enable the secure dmabuf heap. The secure heap
> + pools are defined according to the DT. Heaps are allocated
> + in the pools using gen allocater.
> + If in doubt, say Y.
> diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
> index 29733f84c354..863ef10056a3 100644
> --- a/drivers/dma-buf/heaps/Makefile
> +++ b/drivers/dma-buf/heaps/Makefile
> @@ -2,3 +2,4 @@
> obj-$(CONFIG_DMABUF_HEAPS_SYSTEM)+= system_heap.o
> obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
> obj-$(CONFIG_DMABUF_HEAPS_DSP) += dsp_heap.o
> +obj-$(CONFIG_DMABUF_HEAPS_SECURE)+= secure_heap.o
> diff --git a/drivers/dma-buf/heaps/secure_heap.c
> b/drivers/dma-buf/heaps/secure_heap.c
> new file mode 100644
> index ..25b3629613f3
> --- /dev/null
> +++ b/drivers/dma-buf/heaps/secure_heap.c
> @@ -0,0 +1,357 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * DMABUF secure heap exporter
> + *
> + * Copyright 2021 NXP.
It's 2022 :-)
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MAX_SECURE_HEAP 2
> +#define MAX_HEAP_NAME_LEN 32
> +
> +struct secure_heap_buffer {
> + struct dma_heap *heap;
> + struct list_head attachments;
> + struct mutex lock;
> + unsigned long len;
> + struct sg_table sg_table;
> + int vmap_cnt;
> + void *vaddr;
> +};
> +
> +struct secure_heap_attachment {
> + struct device *dev;
> + struct sg_table *table;
> + struct list_head list;
> +};
> +
> +struct secure_heap_info {
> + struct gen_pool *pool;
> +};
> +
> +struct rmem_secure {
> + phys_addr_t base;
> + phys_addr_t size;
> +
> + char name[MAX_HEAP_NAME_LEN];
> +};
> +
> +static struct rmem_secure secure_data[MAX_SECURE_HEAP] = {0};
> +static unsigned int secure_data_count;
> +
> +static struct sg_table *dup_sg_table(struct sg_table *table)
> +{
> + struct sg_table *new_table;
> + int ret, i;
> + struct scatterlist *sg, *new_sg;
> +
> + new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
> + if (!new_table)
> + return ERR_PTR(-ENOMEM);
> +
> + ret = sg_alloc_table(new_table, table->orig_nents, GFP_KERNEL);
> + if (ret) {
> + kfree(new_table);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + new_sg = new_table->sgl;
> + for_each_sgtable_sg(table, sg, i) {
> +
Re: [PATCH 1/5] drm/vkms: Merge default_config and device
On Fri, Jul 22, 2022 at 05:32:09PM -0400, Jim Shargo wrote:
> This is a small refactor to make ConfigFS support easier.
>
> vkms_config is now a member of vkms_device and we now store a top-level
> reference to vkms_device.
>
> This should be a no-op refactor.
>
> Signed-off-by: Jim Shargo
> ---
> drivers/gpu/drm/vkms/vkms_drv.c| 58 +-
> drivers/gpu/drm/vkms/vkms_drv.h| 5 ++-
> drivers/gpu/drm/vkms/vkms_output.c | 6 ++--
> 3 files changed, 22 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 0ffe5f0e33f7..81ed9417e511 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -37,7 +37,7 @@
> #define DRIVER_MAJOR 1
> #define DRIVER_MINOR 0
>
> -static struct vkms_config *default_config;
> +static struct vkms_device *vkms_device;
I think this should be stored in the platform device data on registration as
opposed to a global.
>
> static bool enable_cursor = true;
> module_param_named(enable_cursor, enable_cursor, bool, 0444);
> @@ -91,13 +91,9 @@ static void vkms_atomic_commit_tail(struct
> drm_atomic_state *old_state)
>
> static int vkms_config_show(struct seq_file *m, void *data)
> {
> - struct drm_info_node *node = (struct drm_info_node *)m->private;
> - struct drm_device *dev = node->minor->dev;
> - struct vkms_device *vkmsdev = drm_device_to_vkms_device(dev);
> -
> - seq_printf(m, "writeback=%d\n", vkmsdev->config->writeback);
> - seq_printf(m, "cursor=%d\n", vkmsdev->config->cursor);
> - seq_printf(m, "overlay=%d\n", vkmsdev->config->overlay);
> + seq_printf(m, "writeback=%d\n", vkms_device->config.writeback);
> + seq_printf(m, "cursor=%d\n", vkms_device->config.cursor);
> + seq_printf(m, "overlay=%d\n", vkms_device->config.overlay);
>
> return 0;
> }
> @@ -158,11 +154,10 @@ static int vkms_modeset_init(struct vkms_device
> *vkmsdev)
> return vkms_output_init(vkmsdev, 0);
> }
>
> -static int vkms_create(struct vkms_config *config)
> +static int vkms_create(void)
> {
> int ret;
> struct platform_device *pdev;
> - struct vkms_device *vkms_device;
>
> pdev = platform_device_register_simple(DRIVER_NAME, -1, NULL, 0);
> if (IS_ERR(pdev))
> @@ -179,9 +174,11 @@ static int vkms_create(struct vkms_config *config)
> ret = PTR_ERR(vkms_device);
> goto out_devres;
> }
> +
In order to avoid the vkms_device global you would call platform_set_drvdata()
here and use platform_get_drvdata() to retrieve it elsewhere.
> vkms_device->platform = pdev;
> - vkms_device->config = config;
> - config->dev = vkms_device;
> + vkms_device->config.cursor = enable_cursor;
> + vkms_device->config.writeback = enable_writeback;
> + vkms_device->config.overlay = enable_overlay;
>
> ret = dma_coerce_mask_and_coherent(vkms_device->drm.dev,
> DMA_BIT_MASK(64));
> @@ -207,6 +204,8 @@ static int vkms_create(struct vkms_config *config)
>
> drm_fbdev_generic_setup(_device->drm, 0);
>
> + vkms_device->initialized = true;
> +
Do we really need this? If so, is there a race between this and the check in
vkms_exit(), or do you get serialization for free from module init/exit?
> return 0;
>
> out_devres:
> @@ -218,46 +217,23 @@ static int vkms_create(struct vkms_config *config)
>
> static int __init vkms_init(void)
> {
> - struct vkms_config *config;
> -
> - config = kmalloc(sizeof(*config), GFP_KERNEL);
> - if (!config)
> - return -ENOMEM;
> -
> - default_config = config;
> -
> - config->cursor = enable_cursor;
> - config->writeback = enable_writeback;
> - config->overlay = enable_overlay;
> -
> - return vkms_create(config);
> + return vkms_create();
> }
>
> -static void vkms_destroy(struct vkms_config *config)
> +static void __exit vkms_exit(void)
> {
> struct platform_device *pdev;
>
> - if (!config->dev) {
> - DRM_INFO("vkms_device is NULL.\n");
> + if (!vkms_device || !vkms_device->initialized) {
> return;
> }
>
> - pdev = config->dev->platform;
> + pdev = vkms_device->platform;
>
> - drm_dev_unregister(>dev->drm);
> - drm_atomic_helper_shutdown(>dev->drm);
> + drm_dev_unregister(_device->drm);
> + drm_atomic_helper_shutdown(_device->drm);
> devres_release_group(>dev, NULL);
> platform_device_unregister(pdev);
> -
> - config->dev = NULL;
> -}
> -
> -static void __exit vkms_exit(void)
> -{
> - if (default_config->dev)
> - vkms_destroy(default_config);
> -
> - kfree(default_config);
> }
>
> module_init(vkms_init);
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 91e63b12f60f..c7ebc4ee6b14 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++
Re: mainline build failure for x86_64 allmodconfig with clang
On 2022-08-04 16:43, Nathan Chancellor wrote:
> On Thu, Aug 04, 2022 at 09:24:41PM +0200, Arnd Bergmann wrote:
>> On Thu, Aug 4, 2022 at 8:52 PM Linus Torvalds
>> wrote:
>>>
>>> On Thu, Aug 4, 2022 at 11:37 AM Sudip Mukherjee (Codethink)
>>> wrote:cov_trace_cmp
git bisect points to 3876a8b5e241 ("drm/amd/display: Enable building new
display engine with KCOV enabled").
>>>
>>> Ahh. So that was presumably why it was disabled before - because it
>>> presumably does disgusting things that make KCOV generate even bigger
>>> stack frames than it already has.
>>>
>>> Those functions do seem to have fairly big stack footprints already (I
>>> didn't try to look into why, I assume it's partly due to aggressive
>>> inlining, and probably some automatic structures on stack). But gcc
>>> doesn't seem to make it all that much worse with KCOV (and my clang
>>> build doesn't enable KCOV).
>>>
>>> So it's presumably some KCOV-vs-clang thing. Nathan?
>
> Looks like Arnd beat me to it :)
>
>> The dependency was originally added to avoid a link failure in 9d1d02ff3678
>> ("drm/amd/display: Don't build DCN1 when kcov is enabled") after I reported
>> the
>> problem in
>> https://lists.freedesktop.org/archives/dri-devel/2018-August/186131.html>>>
>> The commit from the bisection just turns off KCOV for the entire directory
>> to avoid the link failure, so it's not actually a problem with KCOV vs clang,
>> but I think a problem with clang vs badly written code that was obscured
>> in allmodconfig builds prior to this.
>
> Right, I do think the sanitizers make things worse here too, as those get
> enabled with allmodconfig. I ran some really quick tests with allmodconfig and
> a few instrumentation options flipped on/off:
>
> allmodconfig (CONFIG_KASAN=y, CONFIG_KCSAN=n, CONFIG_KCOV=y, and
> CONFIG_UBSAN=y):
>
> warning: stack frame size (2216) exceeds limit (2048) in
> 'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
> warning: stack frame size (2184) exceeds limit (2048) in
> 'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
> warning: stack frame size (2176) exceeds limit (2048) in
> 'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
>
> allmodconfig + CONFIG_KASAN=n:
>
> warning: stack frame size (2112) exceeds limit (2048) in
> 'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
>
> allmodconfig + CONFIG_KCOV=n:
>
> warning: stack frame size (2216) exceeds limit (2048) in
> 'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
> warning: stack frame size (2184) exceeds limit (2048) in
> 'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
> warning: stack frame size (2176) exceeds limit (2048) in
> 'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
>
> allmodconfig + CONFIG_UBSAN=n:
>
> warning: stack frame size (2584) exceeds limit (2048) in
> 'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
> warning: stack frame size (2680) exceeds limit (2048) in
> 'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
> warning: stack frame size (2352) exceeds limit (2048) in
> 'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
>
> allmodconfig + CONFIG_KASAN=n + CONFIG_KCSAN=y + CONFIG_UBSAN=n:
>
> warning: stack frame size (2504) exceeds limit (2048) in
> 'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
> warning: stack frame size (2600) exceeds limit (2048) in
> 'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
> warning: stack frame size (2264) exceeds limit (2048) in
> 'dml32_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
>
> allmodconfig + CONFIG_KASAN=n + CONFIG_KCSAN=n + CONFIG_UBSAN=n:
>
> warning: stack frame size (2072) exceeds limit (2048) in
> 'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than]
>
> There might be other debugging configurations that make this worse too,
> as I don't see those warnings on my distribution configuration.
>
>> The dml30_ModeSupportAndSystemConfigurationFull() function exercises
>> a few paths in the compiler that are otherwise rare. On thing it does is to
>> pass up to 60 arguments to other functions, and it heavily uses float and
>> double variables. Both of these make it rather fragile when it comes to
>> unusual compiler options, so the files keep coming up whenever a new
>> instrumentation feature gets added. There is probably some other flag
>> in allmodconfig that we can disable to improve this again, but I have not
>> checked this time.
>
> I do notice that these files build with a non-configurable
> -Wframe-large-than value:
>
> $ rg frame_warn_flag drivers/gpu/drm/amd/display/dc/dml/Makefile
> 54:frame_warn_flag := -Wframe-larger-than=2048
Tbh, I was looking at the history and I can't find a good reason this
was added. It should be safe to drop this. I would much rather use
the CONFIG_FRAME_WARN value
Re: [Intel-gfx] [PULL] drm-intel-next-fixes
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 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 following changes since commit > > > 2bc7ea71a73747a77e7f83bc085b0d2393235410: > > > > > > Merge tag 'topic/nouveau-misc-2022-07-27' of > > > git://anongit.freedesktop.org/drm/drm into drm-next (2022-07-27 11:34:07 > > > +1000) > > > > > > are available in the Git repository at: > > > > > > git://anongit.freedesktop.org/drm/drm-intel > > > tags/drm-intel-next-fixes-2022-08-04 > > > > > > for you to fetch changes up to e57b9369e0c6f60155027e120fafd4b57e385b71: > > > > > > drm/i915/gt: Batch TLB invalidations (2022-08-01 09:48:06 -0400) > > > > > > > > > - disable pci resize on 32-bit systems (Nirmoy) > > > - don't leak the ccs state (Matt) > > > - TLB invalidation fixes (Chris) > > > > > > > > > Chris Wilson (4): > > > drm/i915/gt: Ignore TLB invalidations on idle engines > > > drm/i915/gt: Invalidate TLB of the OA unit at TLB invalidations > > > drm/i915/gt: Skip TLB invalidations once wedged > > > > > drm/i915/gt: Batch TLB invalidations > > This patch actually adds a regression due to a silly mistake. > > The fix is here: > > > > https://patchwork.freedesktop.org/patch/496249/?series=106805=4 > > > > Thank you for the heads up. > > Since that patch is not merged yet, what are your recommendations here? > Should I remove this from drm-intel-next-fixes now? Those patches are OK to merge: drm/i915/gt: Ignore TLB invalidations on idle engines drm/i915/gt: Invalidate TLB of the OA unit at TLB invalidations drm/i915/gt: Skip TLB invalidations once wedged And helps reduce performance regressions due to TLB cache invalidation. So, I would keep them. With regards to the 4th patch, please don't merge: drm/i915/gt: Batch TLB invalidations or merge it together with: drm/i915: pass a pointer for tlb seqno at vma_invalidate_tlb() > Which regression is worst? The regression caused by the batch patch is a lot worse, as it effectively disables TLB cache invalidation. The fix was meant to be merged at the patch, but somehow between several rebases and 3 machines involved on tests, internal development and upstream, the branch actually sent upstream was not the right one. It got only noticed after reviewing a newer patch. Yeah, that sucks. > Also dim has trouble with fixes for fixes in the same round. > Please ping me when you get that patch merged so I can pull that. OK. Regards, Mauro
Re: [Intel-gfx] [PULL] drm-intel-next-fixes
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 leak the ccs state (Matt) > > - TLB invalidation fixes (Chris) > > > > Thanks, > > Rodrigo. > > > > The following changes since commit 2bc7ea71a73747a77e7f83bc085b0d2393235410: > > > > Merge tag 'topic/nouveau-misc-2022-07-27' of > > git://anongit.freedesktop.org/drm/drm into drm-next (2022-07-27 11:34:07 > > +1000) > > > > are available in the Git repository at: > > > > git://anongit.freedesktop.org/drm/drm-intel > > tags/drm-intel-next-fixes-2022-08-04 > > > > for you to fetch changes up to e57b9369e0c6f60155027e120fafd4b57e385b71: > > > > drm/i915/gt: Batch TLB invalidations (2022-08-01 09:48:06 -0400) > > > > > > - disable pci resize on 32-bit systems (Nirmoy) > > - don't leak the ccs state (Matt) > > - TLB invalidation fixes (Chris) > > > > > > Chris Wilson (4): > > drm/i915/gt: Ignore TLB invalidations on idle engines > > drm/i915/gt: Invalidate TLB of the OA unit at TLB invalidations > > drm/i915/gt: Skip TLB invalidations once wedged > > > drm/i915/gt: Batch TLB invalidations > This patch actually adds a regression due to a silly mistake. > The fix is here: > > https://patchwork.freedesktop.org/patch/496249/?series=106805=4 > Thank you for the heads up. Since that patch is not merged yet, what are your recommendations here? Should I remove this from drm-intel-next-fixes now? Which regression is worst? Also dim has trouble with fixes for fixes in the same round. Please ping me when you get that patch merged so I can pull that. Thanks, Rodrigo. > Regards, > Mauro
Re: [EXT] Re: [PATCH 3/5] dma-buf: heaps: add Linaro secure dmabuf heap support
Hi Brian, Sorry for pushing all the patches again, but I've done some cleanup regarding your comments. secure-heap are now protected by default and no mapping could be done for the CPU. deferred-free is no more needed. useless page pool code removed too. Best regards, Olivier On mer., 2022-08-03 at 13:37 +0100, Brian Starkey wrote: > Caution: EXT Email > > Hi, > > On Wed, Aug 03, 2022 at 11:07:54AM +, Olivier Masse wrote: > > Hi Brian, > > > > Thanks for your comments, please find my reply below. > > > > On mar., 2022-08-02 at 15:39 +0100, Brian Starkey wrote: > > > Caution: EXT Email > > > > > > Hi Olivier, > > > > > > Some comments below as I mentioned off-list. > > > > > > One additional point: some devices need to know if a buffer is > > > protected, so that they can configure registers appropriately to > > > make > > > use of that protected buffer. There was previously a discussion > > > about > > > adding a flag to a dma_buf to indicate that it is allocated from > > > protected memory[1]. > > > > > > [1] > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2019-September%2F238059.htmldata=05%7C01%7Colivier.masse%40nxp.com%7Cafa24901ad92491c9a6a08da754d00b5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637951270862339002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=LoQfoWYr0yHvTWa2tth9XOm2PACji4ATHnx3BRNKnJM%3Dreserved=0 > > > > > > > > > > Interesting, could we introduce is_protected 1-bit flag into struct > > dma_buf ? > > That was the earlier proposal, yeah. > > > struct dma_buf_ops.map_dma_buf and struct dma_buf_ops.unmap_dma_buf > > could become optional for such buffer ? > > > > map_dma_buf and unmap_dma_buf are needed to give devices access to > the > dma-buf, I don't think they should become optional. > > Mapping to the CPU maybe should be optional/disallowed for protected > buffers. > > > > On Tue, Aug 02, 2022 at 11:58:41AM +0200, Olivier Masse wrote: > > > > add Linaro secure heap bindings: linaro,secure-heap > > > > use genalloc to allocate/free buffer from buffer pool. > > > > buffer pool info is from dts. > > > > use sg_table instore the allocated memory info, the length of > > > > sg_table is 1. > > > > implement secure_heap_buf_ops to implement buffer share in > > > > difference device: > > > > 1. Userspace passes this fd to all drivers it wants this buffer > > > > to share with: First the filedescriptor is converted to a > > > > _buf > > > > using > > > > dma_buf_get(). Then the buffer is attached to the device using > > > > dma_buf_attach(). > > > > 2. Once the buffer is attached to all devices userspace can > > > > initiate DMA > > > > access to the shared buffer. In the kernel this is done by > > > > calling > > > > dma_buf_map_attachment() > > > > 3. get sg_table with dma_buf_map_attachment in difference > > > > device. > > > > > > > > Signed-off-by: Olivier Masse > > > > --- > > > > drivers/dma-buf/heaps/Kconfig | 21 +- > > > > drivers/dma-buf/heaps/Makefile | 1 + > > > > drivers/dma-buf/heaps/secure_heap.c | 588 > > > > > > > > 3 files changed, 606 insertions(+), 4 deletions(-) > > > > create mode 100644 drivers/dma-buf/heaps/secure_heap.c > > > > > > > > diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma- > > > > buf/heaps/Kconfig > > > > index 6a33193a7b3e..b2406932192e 100644 > > > > --- a/drivers/dma-buf/heaps/Kconfig > > > > +++ b/drivers/dma-buf/heaps/Kconfig > > > > @@ -1,8 +1,12 @@ > > > > -config DMABUF_HEAPS_DEFERRED_FREE > > > > - tristate > > > > +menuconfig DMABUF_HEAPS_DEFERRED_FREE > > > > + bool "DMA-BUF heaps deferred-free library" > > > > + help > > > > + Choose this option to enable the DMA-BUF heaps > > > > deferred- > > > > free library. > > > > > > > > -config DMABUF_HEAPS_PAGE_POOL > > > > - tristate > > > > +menuconfig DMABUF_HEAPS_PAGE_POOL > > > > + bool "DMA-BUF heaps page-pool library" > > > > + help > > > > + Choose this option to enable the DMA-BUF heaps page- > > > > pool > > > > library. > > > > > > > > config DMABUF_HEAPS_SYSTEM > > > > bool "DMA-BUF System Heap" > > > > @@ -26,3 +30,12 @@ config DMABUF_HEAPS_DSP > > > >Choose this option to enable the dsp dmabuf heap. > > > > The > > > > dsp heap > > > >is allocated by gen allocater. it's allocated > > > > according > > > > the dts. > > > >If in doubt, say Y. > > > > + > > > > +config DMABUF_HEAPS_SECURE > > > > + tristate "DMA-BUF Secure Heap" > > > > + depends on DMABUF_HEAPS && DMABUF_HEAPS_DEFERRED_FREE > > > > + help > > > > + Choose this option to enable the secure dmabuf heap. > > > > The > > > > secure heap > > > > + pools are defined according to the DT. Heaps are > > > > allocated > > > > + in the pools using gen allocater. > > > > + If in doubt, say Y. > >
[PATCH 3/3] plat-hikey: Add linaro,secure-heap compatible
Add DMABUF_HEAPS_SECURE in defconfig
Signed-off-by: Olivier Masse
---
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 11 +++
arch/arm64/configs/defconfig | 2 ++
2 files changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index 3df2afb2f637..e4af0d914279 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -258,6 +258,17 @@ optee {
};
};
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ sdp@3e80 {
+ compatible = "linaro,secure-heap";
+ no-map;
+ reg = <0 0x3E80 0 0x0040>;
+ };
+ };
+
sound_card {
compatible = "audio-graph-card";
dais = <_port0>;
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index c09b07c22d57..ffdc45acef94 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1465,6 +1465,8 @@ CONFIG_CRYPTO_DEV_HISI_SEC2=m
CONFIG_CRYPTO_DEV_HISI_ZIP=m
CONFIG_CRYPTO_DEV_HISI_HPRE=m
CONFIG_CRYPTO_DEV_HISI_TRNG=m
+CONFIG_DMABUF_HEAPS=y
+CONFIG_DMABUF_HEAPS_SECURE=y
CONFIG_CMA_SIZE_MBYTES=32
CONFIG_PRINTK_TIME=y
CONFIG_DEBUG_KERNEL=y
--
2.25.0
[PATCH 1/3] dma-buf: heaps: add Linaro secure dmabuf heap support
add Linaro secure heap bindings: linaro,secure-heap
use genalloc to allocate/free buffer from buffer pool.
buffer pool info is from dts.
use sg_table instore the allocated memory info, the length of sg_table is 1.
implement secure_heap_buf_ops to implement buffer share in difference device:
1. Userspace passes this fd to all drivers it wants this buffer
to share with: First the filedescriptor is converted to a _buf using
dma_buf_get(). Then the buffer is attached to the device using dma_buf_attach().
2. Once the buffer is attached to all devices userspace can initiate DMA
access to the shared buffer. In the kernel this is done by calling
dma_buf_map_attachment()
3. get sg_table with dma_buf_map_attachment in difference device.
Signed-off-by: Olivier Masse
---
drivers/dma-buf/heaps/Kconfig | 9 +
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/secure_heap.c | 357
3 files changed, 367 insertions(+)
create mode 100644 drivers/dma-buf/heaps/secure_heap.c
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index 3782eeeb91c0..c9070c728b9a 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -20,3 +20,12 @@ config DMABUF_HEAPS_DSP
Choose this option to enable the dsp dmabuf heap. The dsp heap
is allocated by gen allocater. it's allocated according the dts.
If in doubt, say Y.
+
+config DMABUF_HEAPS_SECURE
+ tristate "DMA-BUF Secure Heap"
+ depends on DMABUF_HEAPS
+ help
+ Choose this option to enable the secure dmabuf heap. The secure heap
+ pools are defined according to the DT. Heaps are allocated
+ in the pools using gen allocater.
+ If in doubt, say Y.
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index 29733f84c354..863ef10056a3 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -2,3 +2,4 @@
obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
obj-$(CONFIG_DMABUF_HEAPS_DSP) += dsp_heap.o
+obj-$(CONFIG_DMABUF_HEAPS_SECURE) += secure_heap.o
diff --git a/drivers/dma-buf/heaps/secure_heap.c
b/drivers/dma-buf/heaps/secure_heap.c
new file mode 100644
index ..25b3629613f3
--- /dev/null
+++ b/drivers/dma-buf/heaps/secure_heap.c
@@ -0,0 +1,357 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DMABUF secure heap exporter
+ *
+ * Copyright 2021 NXP.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MAX_SECURE_HEAP 2
+#define MAX_HEAP_NAME_LEN 32
+
+struct secure_heap_buffer {
+ struct dma_heap *heap;
+ struct list_head attachments;
+ struct mutex lock;
+ unsigned long len;
+ struct sg_table sg_table;
+ int vmap_cnt;
+ void *vaddr;
+};
+
+struct secure_heap_attachment {
+ struct device *dev;
+ struct sg_table *table;
+ struct list_head list;
+};
+
+struct secure_heap_info {
+ struct gen_pool *pool;
+};
+
+struct rmem_secure {
+ phys_addr_t base;
+ phys_addr_t size;
+
+ char name[MAX_HEAP_NAME_LEN];
+};
+
+static struct rmem_secure secure_data[MAX_SECURE_HEAP] = {0};
+static unsigned int secure_data_count;
+
+static struct sg_table *dup_sg_table(struct sg_table *table)
+{
+ struct sg_table *new_table;
+ int ret, i;
+ struct scatterlist *sg, *new_sg;
+
+ new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
+ if (!new_table)
+ return ERR_PTR(-ENOMEM);
+
+ ret = sg_alloc_table(new_table, table->orig_nents, GFP_KERNEL);
+ if (ret) {
+ kfree(new_table);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ new_sg = new_table->sgl;
+ for_each_sgtable_sg(table, sg, i) {
+ sg_set_page(new_sg, sg_page(sg), sg->length, sg->offset);
+ new_sg->dma_address = sg->dma_address;
+#ifdef CONFIG_NEED_SG_DMA_LENGTH
+ new_sg->dma_length = sg->dma_length;
+#endif
+ new_sg = sg_next(new_sg);
+ }
+
+ return new_table;
+}
+
+static int secure_heap_attach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attachment)
+{
+ struct secure_heap_buffer *buffer = dmabuf->priv;
+ struct secure_heap_attachment *a;
+ struct sg_table *table;
+
+ a = kzalloc(sizeof(*a), GFP_KERNEL);
+ if (!a)
+ return -ENOMEM;
+
+ table = dup_sg_table(>sg_table);
+ if (IS_ERR(table)) {
+ kfree(a);
+ return -ENOMEM;
+ }
+
+ a->table = table;
+ a->dev = attachment->dev;
+ INIT_LIST_HEAD(>list);
+ attachment->priv = a;
+
+ mutex_lock(>lock);
+ list_add(>list, >attachments);
+ mutex_unlock(>lock);
+
+ return 0;
+}
+
[PATCH 2/3] dt-bindings: reserved-memory: add linaro,secure-heap
DMABUF Reserved memory definition for OP-TEE SDP feaure.
Signed-off-by: Olivier Masse
---
.../reserved-memory/linaro,secure-heap.yaml | 56 +++
1 file changed, 56 insertions(+)
create mode 100644
Documentation/devicetree/bindings/reserved-memory/linaro,secure-heap.yaml
diff --git
a/Documentation/devicetree/bindings/reserved-memory/linaro,secure-heap.yaml
b/Documentation/devicetree/bindings/reserved-memory/linaro,secure-heap.yaml
new file mode 100644
index ..80522a4e2989
--- /dev/null
+++ b/Documentation/devicetree/bindings/reserved-memory/linaro,secure-heap.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reserved-memory/linaro,secure-heap.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Linaro Secure DMABUF Heap
+
+maintainers:
+ - Olivier Masse
+
+description:
+ Linaro OP-TEE firmware needs a reserved memory for the
+ Secure Data Path feature (aka SDP).
+ The purpose is to provide a secure memory heap which allow
+ non-secure OS to allocate/free secure buffers.
+ The TEE is reponsible for protecting the SDP memory buffers.
+ TEE Trusted Application can access secure memory references
+ provided as parameters (DMABUF file descriptor).
+
+allOf:
+ - $ref: "reserved-memory.yaml"
+
+properties:
+ compatible:
+const: linaro,secure-heap
+
+ reg:
+description:
+ Region of memory reserved for OP-TEE SDP feature
+
+ no-map:
+$ref: /schemas/types.yaml#/definitions/flag
+description:
+ Avoid creating a virtual mapping of the region as part of the OS'
+ standard mapping of system memory.
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - no-map
+
+examples:
+ - |
+ reserved-memory {
+#address-cells = <2>;
+#size-cells = <2>;
+
+sdp@3e80 {
+ compatible = "linaro,secure-heap";
+ no-map;
+ reg = <0 0x3E80 0 0x0040>;
+};
+ };
--
2.25.0
[PATCH 0/3] Add dma-buf secure-heap
Purpose of these patches is to add a new dma-buf heap: linaro,secure-heap Linaro OPTEE OS Secure Data Path feature is relying on a reserved memory defined at Linux Kernel level and OPTEE OS level. >From Linux Kernel side, heap management is using dma-buf heaps interface. Olivier Masse (3): dma-buf: heaps: add Linaro secure dmabuf heap support dt-bindings: reserved-memory: add linaro,secure-heap plat-hikey: Add linaro,secure-heap compatible .../reserved-memory/linaro,secure-heap.yaml | 56 +++ .../arm64/boot/dts/hisilicon/hi6220-hikey.dts | 11 + arch/arm64/configs/defconfig | 2 + drivers/dma-buf/heaps/Kconfig | 9 + drivers/dma-buf/heaps/Makefile| 1 + drivers/dma-buf/heaps/secure_heap.c | 357 ++ 6 files changed, 436 insertions(+) create mode 100644 Documentation/devicetree/bindings/reserved-memory/linaro,secure-heap.yaml create mode 100644 drivers/dma-buf/heaps/secure_heap.c -- 2.25.0
[PATCH 1/2] drm/i915/ttm: remove calc_ctrl_surf_instr_size
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 a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 9a0814422ba4..1bbed7aa436a 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -511,44 +511,16 @@ static inline u32 *i915_flush_dw(u32 *cmd, u32 flags)
return cmd;
}
-static u32 calc_ctrl_surf_instr_size(struct drm_i915_private *i915, int size)
-{
- u32 num_cmds, num_blks, total_size;
-
- if (!GET_CCS_BYTES(i915, size))
- return 0;
-
- /*
-* XY_CTRL_SURF_COPY_BLT transfers CCS in 256 byte
-* blocks. one XY_CTRL_SURF_COPY_BLT command can
-* transfer upto 1024 blocks.
-*/
- num_blks = DIV_ROUND_UP(GET_CCS_BYTES(i915, size),
- NUM_CCS_BYTES_PER_BLOCK);
- num_cmds = DIV_ROUND_UP(num_blks, NUM_CCS_BLKS_PER_XFER);
- total_size = XY_CTRL_SURF_INSTR_SIZE * num_cmds;
-
- /*
-* Adding a flush before and after XY_CTRL_SURF_COPY_BLT
-*/
- total_size += 2 * MI_FLUSH_DW_SIZE;
-
- return total_size;
-}
-
static int emit_copy_ccs(struct i915_request *rq,
u32 dst_offset, u8 dst_access,
u32 src_offset, u8 src_access, int size)
{
struct drm_i915_private *i915 = rq->engine->i915;
int mocs = rq->engine->gt->mocs.uc_index << 1;
- u32 num_ccs_blks, ccs_ring_size;
+ u32 num_ccs_blks;
u32 *cs;
- ccs_ring_size = calc_ctrl_surf_instr_size(i915, size);
- WARN_ON(!ccs_ring_size);
-
- cs = intel_ring_begin(rq, round_up(ccs_ring_size, 2));
+ cs = intel_ring_begin(rq, 12);
if (IS_ERR(cs))
return PTR_ERR(cs);
@@ -583,8 +555,7 @@ static int emit_copy_ccs(struct i915_request *rq,
FIELD_PREP(XY_CTRL_SURF_MOCS_MASK, mocs);
cs = i915_flush_dw(cs, MI_FLUSH_DW_LLC | MI_FLUSH_DW_CCS);
- if (ccs_ring_size & 1)
- *cs++ = MI_NOOP;
+ *cs++ = MI_NOOP;
intel_ring_advance(rq, cs);
--
2.37.1
[PATCH 2/2] drm/i915/ttm: fix CCS handling
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
migrate_copy():
- We are using plain integer in various places, which we can easily overflow
with a large object.
- We pass the entire object size (when the src is lmem) into
emit_pte() and then try to copy it, which doesn't work, since we
only have a few fixed sized windows in which to map the pages and
perform the copy. With an object > 8M we therefore aren't properly
copying the pages. And then with an object > 64M we trigger the
GEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER).
So it looks like our copy handling for any object > 8M (which is our
CHUNK_SZ) is currently broken on DG2.
Fixes: da0595ae91da ("drm/i915/migrate: Evict and restore the flatccs capable
lmem obj")
Testcase: igt@gem_lmem_swapping@basic-big
Testcase: igt@gem_lmem_swapping@verify-ccs-big
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 44 -
1 file changed, 21 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 1bbed7aa436a..aaaf1906026c 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -609,9 +609,9 @@ static int emit_copy(struct i915_request *rq,
return 0;
}
-static int scatter_list_length(struct scatterlist *sg)
+static u64 scatter_list_length(struct scatterlist *sg)
{
- int len = 0;
+ u64 len = 0;
while (sg && sg_dma_len(sg)) {
len += sg_dma_len(sg);
@@ -621,28 +621,26 @@ static int scatter_list_length(struct scatterlist *sg)
return len;
}
-static void
+static int
calculate_chunk_sz(struct drm_i915_private *i915, bool src_is_lmem,
- int *src_sz, u32 bytes_to_cpy, u32 ccs_bytes_to_cpy)
+ u64 bytes_to_cpy, u64 ccs_bytes_to_cpy)
{
- if (ccs_bytes_to_cpy) {
- if (!src_is_lmem)
- /*
-* When CHUNK_SZ is passed all the pages upto CHUNK_SZ
-* will be taken for the blt. in Flat-ccs supported
-* platform Smem obj will have more pages than required
-* for main meory hence limit it to the required size
-* for main memory
-*/
- *src_sz = min_t(int, bytes_to_cpy, CHUNK_SZ);
- } else { /* ccs handling is not required */
- *src_sz = CHUNK_SZ;
- }
+ if (ccs_bytes_to_cpy && !src_is_lmem)
+ /*
+* When CHUNK_SZ is passed all the pages upto CHUNK_SZ
+* will be taken for the blt. in Flat-ccs supported
+* platform Smem obj will have more pages than required
+* for main meory hence limit it to the required size
+* for main memory
+*/
+ return min_t(u64, bytes_to_cpy, CHUNK_SZ);
+ else
+ return CHUNK_SZ;
}
-static void get_ccs_sg_sgt(struct sgt_dma *it, u32 bytes_to_cpy)
+static void get_ccs_sg_sgt(struct sgt_dma *it, u64 bytes_to_cpy)
{
- u32 len;
+ u64 len;
do {
GEM_BUG_ON(!it->sg || !sg_dma_len(it->sg));
@@ -673,12 +671,12 @@ intel_context_migrate_copy(struct intel_context *ce,
{
struct sgt_dma it_src = sg_sgt(src), it_dst = sg_sgt(dst), it_ccs;
struct drm_i915_private *i915 = ce->engine->i915;
- u32 ccs_bytes_to_cpy = 0, bytes_to_cpy;
+ u64 ccs_bytes_to_cpy = 0, bytes_to_cpy;
enum i915_cache_level ccs_cache_level;
u32 src_offset, dst_offset;
u8 src_access, dst_access;
struct i915_request *rq;
- int src_sz, dst_sz;
+ u64 src_sz, dst_sz;
bool ccs_is_src, overwrite_ccs;
int err;
@@ -761,8 +759,8 @@ intel_context_migrate_copy(struct intel_context *ce,
if (err)
goto out_rq;
- calculate_chunk_sz(i915, src_is_lmem, _sz,
- bytes_to_cpy, ccs_bytes_to_cpy);
+ src_sz = calculate_chunk_sz(i915, src_is_lmem,
+ bytes_to_cpy, ccs_bytes_to_cpy);
len = emit_pte(rq, _src, src_cache_level, src_is_lmem,
src_offset, src_sz);
--
2.37.1
Re: [PATCH v7 12/13] leds: flash: mt6370: Add MediaTek MT6370 flashlight support
On Fri, Aug 5, 2022 at 9:07 AM ChiaEn Wu wrote: > > From: Alice Chen > > The MediaTek MT6370 is a highly-integrated smart power management IC, > which includes a single cell Li-Ion/Li-Polymer switching battery > charger, a USB Type-C & Power Delivery (PD) controller, dual Flash > LED current sources, a RGB LED driver, a backlight WLED driver, > a display bias driver and a general LDO for portable devices. > > Add a support for the MT6370 Flash LED driver. Flash LED in MT6370 > has 2 channels and support torch/strobe mode. Same comments as per previous LED related patch. ... > + /* > +* For the flash to turn on/off, we need to wait HW ramping up/down > time > +* 5ms/500us to prevent the unexpected problem. > +*/ > + if (!priv->fled_strobe_used && curr) > + usleep_range(5000, 6000); > + else if (priv->fled_strobe_used && !curr) > + usleep_range(500, 600); Now it's much better! ... > + /* > +* Always configure as min level when off to > +* prevent flash current spike /* * You need to check the style * of multi-line comments like * this one. */ > +*/ -- With Best Regards, Andy Shevchenko
Re: [PATCH v7 13/13] video: backlight: mt6370: Add MediaTek MT6370 support
On Fri, Aug 5, 2022 at 9:08 AM ChiaEn Wu wrote: > > From: ChiaEn Wu > > MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger > with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight > driver, display bias voltage supply, one general purpose LDO, and the > USB Type-C & PD controller complies with the latest USB Type-C and PD > standards. > > Add a support for the MediaTek MT6370 backlight driver. > It controls 4 channels of 8 series WLEDs in > 2048 (only for MT6370/MT6371) / 16384 (only for MT6372) > current steps (30 mA) in exponential or linear mapping curves. ... > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include Why? Since below drop this and use fully fwnode / device property APIs. > +#include Missed property.h which is heavily used in.the driver > +#include ... > + /* > +* MT6372 uses 14 bits to control the brightness but MT6370 and MT6371 > +* use 11 bits. They are different so we have to use this function to > +* check the vendor ID and use different mask, shift and default > +* maxiimum brightness value. Use spell-checker for all your patches. > +*/ -- With Best Regards, Andy Shevchenko
How to test whether a buffer is in linear format
Suppose that I want to map a GPU buffer to the CPU and do image analysis on it. I know all the usual cautions about this being a poor performance option, etc. But suppose for the moment that the use-case requires it. What's the right set of preconditions to conclude that the buffer is in vanilla linear representation? In other words: no compression, tiling, or any other proprietary GPU tricks that would prevent accessing the pixel data in the same way you would for a dumb buffer. I think that requiring the modifiers to be 0x0 would suffice. But is that overkill? Maybe there are situations when some modifiers are set, but they don't affect the interpretation of the pixel data. Thanks -Matt
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Fri, Aug 5, 2022 at 5:55 AM Adam Ford wrote: > > On Fri, Aug 5, 2022 at 3:44 AM Biju Das wrote: > > > > Hi Adam and all, > > > > > Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors > > > > > > On Thu, Aug 4, 2022 at 9:52 AM Dave Stevenson > > > wrote: > > > > > > > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch > > > wrote: > > > > > > > > > > Hi Dave, > > > > > > > > > > On 22-08-04, Dave Stevenson wrote: > > > > > > Hi Marco > > > > > > > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch > > > wrote: > > > > > > > > > > > > > > Hi Dave, Adam, > > > > > > > > > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > > > > > Hi Adam > > > > > > > > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford > > > wrote: > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > Did managed to get access to the ADV7535 programming > > > > > > > > > > guide? This is the black box here. Let me check if I can > > > > > > > > > > provide you a link with our repo so you can test our > > > current DSIM state if you want. > > > > > > > > > > > > > > > > > > I do have access to the programming guide, but it's under > > > > > > > > > NDA, but I'll try to answer questions if I can. > > > > > > > > > > > > > > > > Not meaning to butt in, but I have datasheets for ADV7533 and > > > > > > > > 7535 from previously looking at these chips. > > > > > > > > > > > > > > Thanks for stepping into :) > > > > > > > > > > > > > > > Mine fairly plainly states: > > > > > > > > "The DSI receiver input supports DSI video mode operation > > > > > > > > only, and specifically, only supports nonburst mode with sync > > > pulses". > > > > > > > > > > > > > > I've read this also, and we are working in nonburst mode with > > > > > > > sync pulses. I have no access to an MIPI-DSI analyzer therefore > > > > > > > I can't verify it. > > > > > > > > > > > > > > > Non-burst mode meaning that the DSI pixel rate MUST be the > > > > > > > > same as the HDMI pixel rate. > > > > > > > > > > > > > > On DSI side you don't have a pixel-clock instead there is bit- > > > clock. > > > > > > > > > > > > You have an effective pixel clock, with a fixed conversion for the > > > > > > configuration. > > > > > > > > > > > > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate. > > > > > > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s > > > > > > > > > > Okay, I just checked the bandwidth which must equal. > > > > > > > > > > > As noted elsewhere, the DSI is DDR, so the clock lane itself is > > > > > > only running at 891 / 2 = 445.5MHz. > > > > > > > > > > > > > > Section 6.1.1 "DSI Input Modes" of > > > > > > > > adv7533_hardware_user_s_guide is even more explicit about the > > > > > > > > requirement of DSI timing matching > > > > > > > > > > > > > > Is it possible to share the key points of the requirements? > > > > > > > > > > > > "Specifically the ADV7533 supports the Non-Burst Mode with syncs. > > > > > > This mode requires real time data generation as a pulse packet > > > > > > received becomes a pulse generated. Therefore this mode requires a > > > > > > continuous stream of data with correct video timing to avoid any > > > > > > visual artifacts." > > > > > > > > > > > > LP mode is supported on data lanes. Clock lane must remain in HS > > > mode. > > > > > > > > > > > > "... the goal is to accurately convey DPI-type timing over DSI. > > > > > > This includes matching DPI pixel-transmission rates, and widths of > > > > > > timing events." > > > > > > > > > > Thanks for sharing. > > > > > > > > > > > > > The NXP kernel switching down to an hs_clk of 445.5MHz would > > > > > > > > therefore be correct for 720p operation. > > > > > > > > > > > > > > It should be absolute no difference if you work on 891MHz with 2 > > > > > > > lanes or on 445.5 MHz with 4 lanes. What must be ensured is that > > > > > > > you need the minimum required bandwidth which is roughly: > > > > > > > 1280*720*24*60 = 1.327 GBps. > > > > > > > > > > > > Has someone changed the number of lanes in use? I'd missed that if > > > > > > so, but I'll agree that 891MHz over 2 lanes should work for > > > 720p60. > > > > > > > > > > The ADV driver is changing it autom. but this logic is somehow odd > > > > > and there was already a approach to stop the driver doing this. > > > > > > > > I'd missed that bit in the driver where it appears to drop to 3 lanes > > > > for pixel clock < 8 via a mipi_dsi_detach and _attach. Quirky, but > > > > probably the only way it can be achieved in the current framework. > > > > > > > > > To sync up: we have two problems: > > > > > 1) The 720P mode with static DSI host configuration isn't working > > > > > without hacks. > > > > > 2) The DSI link frequency should changed as soon as required > > > > > automatically. So we can provide all modes. > > > > > > > > > > I would concentrate on problem 1 first before moving on to the 2nd. > > > > > > > > If you change your link frequency, it may be worth trying a lower > > > >
Re: [RFC PATCH] drm/msm: lookup the ICC paths in both mdp5/dpu and mdss devices
On 2022-08-05 14:56:30, Dmitry Baryshkov wrote:
> The commit 6874f48bb8b0 ("drm/msm: make mdp5/dpu devices master
> components") changed the MDP5 driver to look for the interconnect paths
> in the MDSS device rather than in the MDP5 device itself. This was left
> unnoticed since on my testing devices the interconnects probably didn't
> reach the sync state.
>
> Rather than just using the MDP5 device for ICC path lookups for the MDP5
> devices, introduce an additional helper to check both MDP5/DPU and MDSS
> nodes. This will be helpful for the MDP5->DPU conversion, since the
> driver will have to check both nodes.
>
> Fixes: 6874f48bb8b0 ("drm/msm: make mdp5/dpu devices master components")
> Reported-by: Marijn Suijten
> Reported-by: Yassine Oudjana
> Signed-off-by: Dmitry Baryshkov
Tested-by: Marijn Suijten # On sdm630
But I'm not sure about giving my Reviewed-by to this, as I'd rather
*correct* the DT bindings for sdm630 and msm8996 to provide
interconnects in the MDSS node unless there are strong reasons not to
(and I don't consider "backwards compatibility" to be one, this binding
"never even existed" if mdp5.txt is to be believed).
- Marijn
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 7 ++-
> drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 9 +++--
> drivers/gpu/drm/msm/msm_drv.h| 2 ++
> drivers/gpu/drm/msm/msm_io_utils.c | 22 ++
> 4 files changed, 29 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index e23e2552e802..9eff6c2b1917 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -383,12 +383,9 @@ static int dpu_kms_parse_data_bus_icc_path(struct
> dpu_kms *dpu_kms)
> struct icc_path *path1;
> struct drm_device *dev = dpu_kms->dev;
> struct device *dpu_dev = dev->dev;
> - struct device *mdss_dev = dpu_dev->parent;
>
> - /* Interconnects are a part of MDSS device tree binding, not the
> - * MDP/DPU device. */
> - path0 = of_icc_get(mdss_dev, "mdp0-mem");
> - path1 = of_icc_get(mdss_dev, "mdp1-mem");
> + path0 = msm_icc_get(dpu_dev, "mdp0-mem");
> + path1 = msm_icc_get(dpu_dev, "mdp1-mem");
>
> if (IS_ERR_OR_NULL(path0))
> return PTR_ERR_OR_ZERO(path0);
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> index 3d5621a68f85..b0c372fef5d5 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> @@ -921,12 +921,9 @@ static int mdp5_init(struct platform_device *pdev,
> struct drm_device *dev)
>
> static int mdp5_setup_interconnect(struct platform_device *pdev)
> {
> - /* Interconnects are a part of MDSS device tree binding, not the
> - * MDP5 device. */
> - struct device *mdss_dev = pdev->dev.parent;
> - struct icc_path *path0 = of_icc_get(mdss_dev, "mdp0-mem");
> - struct icc_path *path1 = of_icc_get(mdss_dev, "mdp1-mem");
> - struct icc_path *path_rot = of_icc_get(mdss_dev, "rotator-mem");
> + struct icc_path *path0 = msm_icc_get(>dev, "mdp0-mem");
> + struct icc_path *path1 = msm_icc_get(>dev, "mdp1-mem");
> + struct icc_path *path_rot = msm_icc_get(>dev, "rotator-mem");
>
> if (IS_ERR(path0))
> return PTR_ERR(path0);
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index 08388d742d65..d38510f6dbf5 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -441,6 +441,8 @@ void __iomem *msm_ioremap_size(struct platform_device
> *pdev, const char *name,
> phys_addr_t *size);
> void __iomem *msm_ioremap_quiet(struct platform_device *pdev, const char
> *name);
>
> +struct icc_path *msm_icc_get(struct device *dev, const char *name);
> +
> #define msm_writel(data, addr) writel((data), (addr))
> #define msm_readl(addr) readl((addr))
>
> diff --git a/drivers/gpu/drm/msm/msm_io_utils.c
> b/drivers/gpu/drm/msm/msm_io_utils.c
> index 7b504617833a..d02cd29ce829 100644
> --- a/drivers/gpu/drm/msm/msm_io_utils.c
> +++ b/drivers/gpu/drm/msm/msm_io_utils.c
> @@ -5,6 +5,8 @@
> * Author: Rob Clark
> */
>
> +#include
> +
> #include "msm_drv.h"
>
> /*
> @@ -124,3 +126,23 @@ void msm_hrtimer_work_init(struct msm_hrtimer_work *work,
> work->worker = worker;
> kthread_init_work(>work, fn);
> }
> +
> +struct icc_path *msm_icc_get(struct device *dev, const char *name)
> +{
> + struct device *mdss_dev = dev->parent;
> + struct icc_path *path;
> +
> + path = of_icc_get(dev, name);
> + if (path)
> + return path;
> +
> + /*
> + * If there are no interconnects attached to the corresponding device
> + * node, of_icc_get() will return NULL.
> + *
> + * If the MDP5/DPU device node doesn't have interconnects, lookup the
> + * path in
Re: [PATCH 0/4] drm/udl: Fix stray URBs and cleanup
Hi Takashi, Am 04.08.22 um 09:58 schrieb Takashi Iwai: Hi, this is a series of fixes for UDL driver to address the leftover URBs at suspend/resume. It begins with the simplification of FIFO control code with the standard wait queue, followed by the handling of pending URBs, and replace BUG_ON() with WARN_ON() as a cleanup. Reviewed-by: Thomas Zimmermann That's a lot better than what's currently there. If no other reviews come in, I'll add the patches next week. Best regards Thomas Takashi === Takashi Iwai (4): drm/udl: Replace semaphore with a simple wait queue drm/udl: Sync pending URBs at suspend / disconnect drm/udl: Kill pending URBs at suspend and disconnect drm/udl: Replace BUG_ON() with WARN_ON() drivers/gpu/drm/udl/udl_drv.h | 14 +++- drivers/gpu/drm/udl/udl_main.c | 125 ++--- drivers/gpu/drm/udl/udl_modeset.c | 4 + drivers/gpu/drm/udl/udl_transfer.c | 3 +- 4 files changed, 79 insertions(+), 67 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
[RFC PATCH] drm/msm: lookup the ICC paths in both mdp5/dpu and mdss devices
The commit 6874f48bb8b0 ("drm/msm: make mdp5/dpu devices master
components") changed the MDP5 driver to look for the interconnect paths
in the MDSS device rather than in the MDP5 device itself. This was left
unnoticed since on my testing devices the interconnects probably didn't
reach the sync state.
Rather than just using the MDP5 device for ICC path lookups for the MDP5
devices, introduce an additional helper to check both MDP5/DPU and MDSS
nodes. This will be helpful for the MDP5->DPU conversion, since the
driver will have to check both nodes.
Fixes: 6874f48bb8b0 ("drm/msm: make mdp5/dpu devices master components")
Reported-by: Marijn Suijten
Reported-by: Yassine Oudjana
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 7 ++-
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 9 +++--
drivers/gpu/drm/msm/msm_drv.h| 2 ++
drivers/gpu/drm/msm/msm_io_utils.c | 22 ++
4 files changed, 29 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index e23e2552e802..9eff6c2b1917 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -383,12 +383,9 @@ static int dpu_kms_parse_data_bus_icc_path(struct dpu_kms
*dpu_kms)
struct icc_path *path1;
struct drm_device *dev = dpu_kms->dev;
struct device *dpu_dev = dev->dev;
- struct device *mdss_dev = dpu_dev->parent;
- /* Interconnects are a part of MDSS device tree binding, not the
-* MDP/DPU device. */
- path0 = of_icc_get(mdss_dev, "mdp0-mem");
- path1 = of_icc_get(mdss_dev, "mdp1-mem");
+ path0 = msm_icc_get(dpu_dev, "mdp0-mem");
+ path1 = msm_icc_get(dpu_dev, "mdp1-mem");
if (IS_ERR_OR_NULL(path0))
return PTR_ERR_OR_ZERO(path0);
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 3d5621a68f85..b0c372fef5d5 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -921,12 +921,9 @@ static int mdp5_init(struct platform_device *pdev, struct
drm_device *dev)
static int mdp5_setup_interconnect(struct platform_device *pdev)
{
- /* Interconnects are a part of MDSS device tree binding, not the
-* MDP5 device. */
- struct device *mdss_dev = pdev->dev.parent;
- struct icc_path *path0 = of_icc_get(mdss_dev, "mdp0-mem");
- struct icc_path *path1 = of_icc_get(mdss_dev, "mdp1-mem");
- struct icc_path *path_rot = of_icc_get(mdss_dev, "rotator-mem");
+ struct icc_path *path0 = msm_icc_get(>dev, "mdp0-mem");
+ struct icc_path *path1 = msm_icc_get(>dev, "mdp1-mem");
+ struct icc_path *path_rot = msm_icc_get(>dev, "rotator-mem");
if (IS_ERR(path0))
return PTR_ERR(path0);
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 08388d742d65..d38510f6dbf5 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -441,6 +441,8 @@ void __iomem *msm_ioremap_size(struct platform_device
*pdev, const char *name,
phys_addr_t *size);
void __iomem *msm_ioremap_quiet(struct platform_device *pdev, const char
*name);
+struct icc_path *msm_icc_get(struct device *dev, const char *name);
+
#define msm_writel(data, addr) writel((data), (addr))
#define msm_readl(addr) readl((addr))
diff --git a/drivers/gpu/drm/msm/msm_io_utils.c
b/drivers/gpu/drm/msm/msm_io_utils.c
index 7b504617833a..d02cd29ce829 100644
--- a/drivers/gpu/drm/msm/msm_io_utils.c
+++ b/drivers/gpu/drm/msm/msm_io_utils.c
@@ -5,6 +5,8 @@
* Author: Rob Clark
*/
+#include
+
#include "msm_drv.h"
/*
@@ -124,3 +126,23 @@ void msm_hrtimer_work_init(struct msm_hrtimer_work *work,
work->worker = worker;
kthread_init_work(>work, fn);
}
+
+struct icc_path *msm_icc_get(struct device *dev, const char *name)
+{
+ struct device *mdss_dev = dev->parent;
+ struct icc_path *path;
+
+ path = of_icc_get(dev, name);
+ if (path)
+ return path;
+
+ /*
+* If there are no interconnects attached to the corresponding device
+* node, of_icc_get() will return NULL.
+*
+* If the MDP5/DPU device node doesn't have interconnects, lookup the
+* path in the parent (MDSS) device.
+*/
+ return of_icc_get(mdss_dev, name);
+
+}
--
2.35.1
Re: [PATCH] tty: vt: selection: Add check for valid tiocl_selection values
On Thu, Aug 04, 2022 at 11:22:26AM +0200, Jiri Slaby wrote: > On 04. 08. 22, 10:44, Helge Deller wrote: > > On 8/4/22 09:15, Helge Deller wrote: > > > On 8/4/22 07:47, Jiri Slaby wrote: > > > > On 30. 07. 22, 20:49, Helge Deller wrote: > > > > > The line and column numbers for the selection need to start at 1. > > > > > Add the checks to prevent invalid input. > > > > > --- a/drivers/tty/vt/selection.c > > > > > +++ b/drivers/tty/vt/selection.c > > > > > @@ -326,6 +326,9 @@ static int vc_selection(struct vc_data *vc, > > > > > struct tiocl_selection *v, > > > > > + if (!v->xs || !v->ys || !v->xe || !v->ye) > > > > > + return -EINVAL; > > > > > > > > Hmm, I'm not sure about this. It potentially breaks userspace (by > > > > returning EINVAL now). > We can still do a trial and revert it if something breaks... It's just that > _noone_ knows with all this undocumented stuff ;). > > But in fact, 0 currently means full row/column. Isn't it on purpose? > > Today, we are out of luck, codesearch.debian.net gives no clue about users: > https://codesearch.debian.net/search?q=%5CbTIOCL_SETSEL%5Cb=0 That's because the macro is undocumented. "man ioctl_console" says: TIOCLINUX, subcode=2 Set selection. argp points to a [...] thus everyone writes it as a number. You'd need to grep for TIOCLINUX; there's not that many references to check... Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Say what you want about Adolf, at least he was the man who ⢿⡄⠘⠷⠚⠋⠀ killed Hitler. Your turn, Vlad! ⠈⠳⣄
Re: [PATCH v7 11/13] leds: rgb: mt6370: Add MediaTek MT6370 current sink type LED Indicator support
On Fri, Aug 5, 2022 at 9:07 AM ChiaEn Wu wrote:
>
> From: ChiYuan Huang
>
> The MediaTek MT6370 is a highly-integrated smart power management IC,
> which includes a single cell Li-Ion/Li-Polymer switching battery
> charger, a USB Type-C & Power Delivery (PD) controller, dual
> Flash LED current sources, a RGB LED driver, a backlight WLED driver,
> a display bias driver and a general LDO for portable devices.
>
> Add a support for the MediaTek MT6370 Current Sink Type LED Indicator
Add support
(This is also for all other commit messages)
> driver. It can control four channels current-sink RGB LEDs with 3 modes,
3 modes:
> constant current, PWM, and breath mode.
...
> +static int mt6370_gen_breath_pattern(struct mt6370_priv *priv,
> +struct led_pattern *pattern, u32 len,
> +u8 *pattern_val, u32 val_len)
> +{
> + enum mt6370_led_ranges sel_range;
> + struct led_pattern *curr;
> + unsigned int sel;
> + u32 val = 0;
> + int i;
> +
> + if (len < P_MAX_PATTERNS && val_len < P_MAX_PATTERNS / 2)
> + return -EINVAL;
> +
> + /*
> +* Pattern list
> +* tr1: byte 0, b'[7: 4]
> +* tr2: byte 0, b'[3: 0]
> +* tf1: byte 1, b'[7: 4]
> +* tf2: byte 1, b'[3: 0]
> +* ton: byte 2, b'[7: 4]
> +* toff: byte 2, b'[3: 0]
> +*/
> + for (i = 0; i < P_MAX_PATTERNS; i++) {
> + curr = pattern + i;
> +
> + sel_range = i == P_LED_TOFF ? R_LED_TOFF : R_LED_TRFON;
> +
> + linear_range_get_selector_within(priv->ranges + sel_range,
> +curr->delta_t, );
> +
> + val <<= i % 2 == 0 ? 8 : 0;
> + val |= sel << (i % 2 == 0 ? 4 : 0);
It's too cryptic, why not simply:
if (i % 2) {
val |= sel;
} else {
val <<= 8;
val |= sel << 4;
}
?
> + }
> +
> + put_unaligned_be24(val, pattern_val);
> +
> + return 0;
> +}
...
> + const char * const states[] = { "off", "keep", "on" };
> + ret = fwnode_property_read_string(init_data->fwnode, "default-state",
> + _str);
> + if (!ret) {
> + ret = match_string(states, ARRAY_SIZE(states), stat_str);
> + if (ret < 0)
> + ret = STATE_OFF;
> +
> + led->default_state = ret;
> + }
Replace this by using led_init_default_state_get().
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v7 10/13] power: supply: mt6370: Add MediaTek MT6370 charger driver
On Fri, Aug 5, 2022 at 9:07 AM ChiaEn Wu wrote: > > From: ChiaEn Wu > > MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger > with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight > driver, display bias voltage supply, one general purpose LDO, and the > USB Type-C & PD controller complies with the latest USB Type-C and PD > standards. > > Add a support for the MediaTek MT6370 Charger driver. The charger module > of MT6370 supports High-Accuracy Voltage/Current Regulation, > Average Input Current Regulation, Battery Temperature Sensing, > Over-Temperature Protection, DPDM Detection for BC1.2. On Fri, Aug 5, 2022 at 9:07 AM ChiaEn Wu wrote: > > From: ChiYuan Huang > > The MediaTek MT6370 is a highly-integrated smart power management IC, > which includes a single cell Li-Ion/Li-Polymer switching battery > charger, a USB Type-C & Power Delivery (PD) controller, dual > Flash LED current sources, a RGB LED driver, a backlight WLED driver, > a display bias driver and a general LDO for portable devices. > > Add a support for the Type-C & Power Delivery controller in > MediaTek MT6370 IC. FWIW, Reviewed-by: Andy Shevchenko > Signed-off-by: ChiaEn Wu > --- > > v7 > - Revise the method to enable/disable irq > - Revise all 'if (ret < 0)' to 'if (ret)' after using > mt6370_chg_field_set/get() > - Revise all 'OTG' text > --- > drivers/power/supply/Kconfig | 14 + > drivers/power/supply/Makefile | 1 + > drivers/power/supply/mt6370-charger.c | 965 > ++ > 3 files changed, 980 insertions(+) > create mode 100644 drivers/power/supply/mt6370-charger.c > > diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig > index 1aa8323..591deb8 100644 > --- a/drivers/power/supply/Kconfig > +++ b/drivers/power/supply/Kconfig > @@ -619,6 +619,20 @@ config CHARGER_MT6360 > Average Input Current Regulation, Battery Temperature Sensing, > Over-Temperature Protection, DPDM Detection for BC1.2. > > +config CHARGER_MT6370 > + tristate "MediaTek MT6370 Charger Driver" > + depends on MFD_MT6370 > + depends on REGULATOR > + select LINEAR_RANGES > + help > + Say Y here to enable MT6370 Charger Part. > + The device supports High-Accuracy Voltage/Current Regulation, > + Average Input Current Regulation, Battery Temperature Sensing, > + Over-Temperature Protection, DPDM Detection for BC1.2. > + > + This driver can also be built as a module. If so, the module > + will be called "mt6370-charger". > + > config CHARGER_QCOM_SMBB > tristate "Qualcomm Switch-Mode Battery Charger and Boost" > depends on MFD_SPMI_PMIC || COMPILE_TEST > diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile > index 7f02f36..8c95276 100644 > --- a/drivers/power/supply/Makefile > +++ b/drivers/power/supply/Makefile > @@ -82,6 +82,7 @@ obj-$(CONFIG_CHARGER_MAX8997) += max8997_charger.o > obj-$(CONFIG_CHARGER_MAX8998) += max8998_charger.o > obj-$(CONFIG_CHARGER_MP2629) += mp2629_charger.o > obj-$(CONFIG_CHARGER_MT6360) += mt6360_charger.o > +obj-$(CONFIG_CHARGER_MT6370) += mt6370-charger.o > obj-$(CONFIG_CHARGER_QCOM_SMBB)+= qcom_smbb.o > obj-$(CONFIG_CHARGER_BQ2415X) += bq2415x_charger.o > obj-$(CONFIG_CHARGER_BQ24190) += bq24190_charger.o > diff --git a/drivers/power/supply/mt6370-charger.c > b/drivers/power/supply/mt6370-charger.c > new file mode 100644 > index 000..42fddc3 > --- /dev/null > +++ b/drivers/power/supply/mt6370-charger.c > @@ -0,0 +1,965 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Copyright (C) 2022 Richtek Technology Corp. > + * > + * Author: ChiaEn Wu > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define MT6370_REG_CHG_CTRL1 0x111 > +#define MT6370_REG_CHG_CTRL2 0x112 > +#define MT6370_REG_CHG_CTRL3 0x113 > +#define MT6370_REG_CHG_CTRL4 0x114 > +#define MT6370_REG_CHG_CTRL5 0x115 > +#define MT6370_REG_CHG_CTRL6 0x116 > +#define MT6370_REG_CHG_CTRL7 0x117 > +#define MT6370_REG_CHG_CTRL8 0x118 > +#define MT6370_REG_CHG_CTRL9 0x119 > +#define MT6370_REG_CHG_CTRL10 0x11A > +#define MT6370_REG_DEVICE_TYPE 0x122 > +#define MT6370_REG_USB_STATUS1 0x127 > +#define MT6370_REG_CHG_STAT0x14A > +#define MT6370_REG_FLED_EN 0x17E > +#define MT6370_REG_CHG_STAT1 0X1D0 > +#define MT6370_REG_OVPCTRL_STAT0x1D8 > + > +#define MT6370_VOBST_MASK GENMASK(7, 2) > +#define MT6370_OTG_PIN_EN_MASK BIT(1) > +#define MT6370_OPA_MODE_MASK BIT(0) > +#define MT6370_OTG_OC_MASK GENMASK(2, 0) > + > +#define
Re: imx8mm lcdif->dsi->adv7535 no video, no errors
On Fri, Aug 5, 2022 at 3:44 AM Biju Das wrote: > > Hi Adam and all, > > > Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors > > > > On Thu, Aug 4, 2022 at 9:52 AM Dave Stevenson > > wrote: > > > > > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch > > wrote: > > > > > > > > Hi Dave, > > > > > > > > On 22-08-04, Dave Stevenson wrote: > > > > > Hi Marco > > > > > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch > > wrote: > > > > > > > > > > > > Hi Dave, Adam, > > > > > > > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > > > > Hi Adam > > > > > > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford > > wrote: > > > > > > > > > > > > ... > > > > > > > > > > > > > > > Did managed to get access to the ADV7535 programming > > > > > > > > > guide? This is the black box here. Let me check if I can > > > > > > > > > provide you a link with our repo so you can test our > > current DSIM state if you want. > > > > > > > > > > > > > > > > I do have access to the programming guide, but it's under > > > > > > > > NDA, but I'll try to answer questions if I can. > > > > > > > > > > > > > > Not meaning to butt in, but I have datasheets for ADV7533 and > > > > > > > 7535 from previously looking at these chips. > > > > > > > > > > > > Thanks for stepping into :) > > > > > > > > > > > > > Mine fairly plainly states: > > > > > > > "The DSI receiver input supports DSI video mode operation > > > > > > > only, and specifically, only supports nonburst mode with sync > > pulses". > > > > > > > > > > > > I've read this also, and we are working in nonburst mode with > > > > > > sync pulses. I have no access to an MIPI-DSI analyzer therefore > > > > > > I can't verify it. > > > > > > > > > > > > > Non-burst mode meaning that the DSI pixel rate MUST be the > > > > > > > same as the HDMI pixel rate. > > > > > > > > > > > > On DSI side you don't have a pixel-clock instead there is bit- > > clock. > > > > > > > > > > You have an effective pixel clock, with a fixed conversion for the > > > > > configuration. > > > > > > > > > > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate. > > > > > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s > > > > > > > > Okay, I just checked the bandwidth which must equal. > > > > > > > > > As noted elsewhere, the DSI is DDR, so the clock lane itself is > > > > > only running at 891 / 2 = 445.5MHz. > > > > > > > > > > > > Section 6.1.1 "DSI Input Modes" of > > > > > > > adv7533_hardware_user_s_guide is even more explicit about the > > > > > > > requirement of DSI timing matching > > > > > > > > > > > > Is it possible to share the key points of the requirements? > > > > > > > > > > "Specifically the ADV7533 supports the Non-Burst Mode with syncs. > > > > > This mode requires real time data generation as a pulse packet > > > > > received becomes a pulse generated. Therefore this mode requires a > > > > > continuous stream of data with correct video timing to avoid any > > > > > visual artifacts." > > > > > > > > > > LP mode is supported on data lanes. Clock lane must remain in HS > > mode. > > > > > > > > > > "... the goal is to accurately convey DPI-type timing over DSI. > > > > > This includes matching DPI pixel-transmission rates, and widths of > > > > > timing events." > > > > > > > > Thanks for sharing. > > > > > > > > > > > The NXP kernel switching down to an hs_clk of 445.5MHz would > > > > > > > therefore be correct for 720p operation. > > > > > > > > > > > > It should be absolute no difference if you work on 891MHz with 2 > > > > > > lanes or on 445.5 MHz with 4 lanes. What must be ensured is that > > > > > > you need the minimum required bandwidth which is roughly: > > > > > > 1280*720*24*60 = 1.327 GBps. > > > > > > > > > > Has someone changed the number of lanes in use? I'd missed that if > > > > > so, but I'll agree that 891MHz over 2 lanes should work for > > 720p60. > > > > > > > > The ADV driver is changing it autom. but this logic is somehow odd > > > > and there was already a approach to stop the driver doing this. > > > > > > I'd missed that bit in the driver where it appears to drop to 3 lanes > > > for pixel clock < 8 via a mipi_dsi_detach and _attach. Quirky, but > > > probably the only way it can be achieved in the current framework. > > > > > > > To sync up: we have two problems: > > > > 1) The 720P mode with static DSI host configuration isn't working > > > > without hacks. > > > > 2) The DSI link frequency should changed as soon as required > > > > automatically. So we can provide all modes. > > > > > > > > I would concentrate on problem 1 first before moving on to the 2nd. > > > > > > If you change your link frequency, it may be worth trying a lower > > > resolution again such as 720x480 @ 60fps on 2 lanes. (720480@60 on 4 > > > lanes is again listed as mandatory for using the timing generator). > > > > > > > > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as > > > > > one of the modes that is mandatory to use the timing
Re: [PATCH v7 09/13] iio: adc: mt6370: Add MediaTek MT6370 support
On Fri, Aug 5, 2022 at 9:07 AM ChiaEn Wu wrote:
>
> From: ChiaEn Wu
>
> MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger
> with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight
> driver, display bias voltage supply, one general purpose LDO, and the
> USB Type-C & PD controller complies with the latest USB Type-C and PD
> standards.
>
> Add a support for the MT6370 ADC driver for system monitoring, including
> charger current, voltage, and temperature.
On Fri, Aug 5, 2022 at 9:07 AM ChiaEn Wu wrote:
>
> From: ChiYuan Huang
>
> The MediaTek MT6370 is a highly-integrated smart power management IC,
> which includes a single cell Li-Ion/Li-Polymer switching battery
> charger, a USB Type-C & Power Delivery (PD) controller, dual
> Flash LED current sources, a RGB LED driver, a backlight WLED driver,
> a display bias driver and a general LDO for portable devices.
>
> Add a support for the Type-C & Power Delivery controller in
> MediaTek MT6370 IC.
Reviewed-by: Andy Shevchenko
> Reviewed-by: AngeloGioacchino Del Regno
>
> Signed-off-by: ChiaEn Wu
> ---
>
> v7
> - Add AICR(100mA ~ 350mA), ICHG(100mA ~ 800mA) macros
> - Remove 400mA AICR and 900mA ICHG macros
> - Revise using 'if-else' to 'switch-case' in mt6370_adc_read_scale()
> where the adc channel is ibus or ibat
> ---
> drivers/iio/adc/Kconfig | 12 ++
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/mt6370-adc.c | 305
> +++
> 3 files changed, 318 insertions(+)
> create mode 100644 drivers/iio/adc/mt6370-adc.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 7fe5930..995cbb5 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -736,6 +736,18 @@ config MEDIATEK_MT6360_ADC
> is used in smartphones and tablets and supports a 11 channel
> general purpose ADC.
>
> +config MEDIATEK_MT6370_ADC
> + tristate "MediaTek MT6370 ADC driver"
> + depends on MFD_MT6370
> + help
> + Say yes here to enable MediaTek MT6370 ADC support.
> +
> + This ADC driver provides 9 channels for system monitoring (charger
> + current, voltage, and temperature).
> +
> + This driver can also be built as a module. If so, the module
> + will be called "mt6370-adc".
> +
> config MEDIATEK_MT6577_AUXADC
> tristate "MediaTek AUXADC driver"
> depends on ARCH_MEDIATEK || COMPILE_TEST
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 1772a54..c6bc35f 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -68,6 +68,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
> obj-$(CONFIG_MCP3422) += mcp3422.o
> obj-$(CONFIG_MCP3911) += mcp3911.o
> obj-$(CONFIG_MEDIATEK_MT6360_ADC) += mt6360-adc.o
> +obj-$(CONFIG_MEDIATEK_MT6370_ADC) += mt6370-adc.o
> obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o
> obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
> obj-$(CONFIG_MESON_SARADC) += meson_saradc.o
> diff --git a/drivers/iio/adc/mt6370-adc.c b/drivers/iio/adc/mt6370-adc.c
> new file mode 100644
> index 000..2a46471
> --- /dev/null
> +++ b/drivers/iio/adc/mt6370-adc.c
> @@ -0,0 +1,305 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2022 Richtek Technology Corp.
> + *
> + * Author: ChiaEn Wu
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#define MT6370_REG_CHG_CTRL3 0x113
> +#define MT6370_REG_CHG_CTRL7 0x117
> +#define MT6370_REG_CHG_ADC 0x121
> +#define MT6370_REG_ADC_DATA_H 0x14C
> +
> +#define MT6370_ADC_START_MASK BIT(0)
> +#define MT6370_ADC_IN_SEL_MASK GENMASK(7, 4)
> +#define MT6370_AICR_ICHG_MASK GENMASK(7, 2)
> +
> +#define MT6370_AICR_100_mA 0x0
> +#define MT6370_AICR_150_mA 0x1
> +#define MT6370_AICR_200_mA 0x2
> +#define MT6370_AICR_250_mA 0x3
> +#define MT6370_AICR_300_mA 0x4
> +#define MT6370_AICR_350_mA 0x5
> +
> +#define MT6370_ICHG_100_mA 0x0
> +#define MT6370_ICHG_200_mA 0x1
> +#define MT6370_ICHG_300_mA 0x2
> +#define MT6370_ICHG_400_mA 0x3
> +#define MT6370_ICHG_500_mA 0x4
> +#define MT6370_ICHG_600_mA 0x5
> +#define MT6370_ICHG_700_mA 0x6
> +#define MT6370_ICHG_800_mA 0x7
> +
> +#define ADC_CONV_TIME_MS 35
> +#define ADC_CONV_POLLING_TIME_US 1000
> +
> +struct mt6370_adc_data {
> + struct device *dev;
> + struct regmap *regmap;
> + /*
> +* This mutex lock is for preventing the different ADC channels
> +* from being read at the same time.
> +*/
> + struct mutex adc_lock;
> +};
> +
> +static int mt6370_adc_read_channel(struct mt6370_adc_data
Re: [PATCH v7 08/13] usb: typec: tcpci_mt6370: Add MediaTek MT6370 tcpci driver
On Fri, Aug 5, 2022 at 9:07 AM ChiaEn Wu wrote:
>
> From: ChiYuan Huang
>
> The MediaTek MT6370 is a highly-integrated smart power management IC,
> which includes a single cell Li-Ion/Li-Polymer switching battery
> charger, a USB Type-C & Power Delivery (PD) controller, dual
> Flash LED current sources, a RGB LED driver, a backlight WLED driver,
> a display bias driver and a general LDO for portable devices.
>
> Add a support for the Type-C & Power Delivery controller in
> MediaTek MT6370 IC.
Reviewed-by: Andy Shevchenko
> Reviewed-by: AngeloGioacchino Del Regno
>
> Reviewed-by: Guenter Roeck
> Signed-off-by: ChiYuan Huang
> Signed-off-by: ChiaEn Wu
> ---
>
> v7
> - Revise 'devm_add_action_or_reset(dev, ...)' to one line
> - Revise 'return regmap_update_bits(...)' with using positive
> conditional
> ---
> drivers/usb/typec/tcpm/Kconfig| 11 ++
> drivers/usb/typec/tcpm/Makefile | 1 +
> drivers/usb/typec/tcpm/tcpci_mt6370.c | 207
> ++
> 3 files changed, 219 insertions(+)
> create mode 100644 drivers/usb/typec/tcpm/tcpci_mt6370.c
>
> diff --git a/drivers/usb/typec/tcpm/Kconfig b/drivers/usb/typec/tcpm/Kconfig
> index 073fd2e..e6b88ca 100644
> --- a/drivers/usb/typec/tcpm/Kconfig
> +++ b/drivers/usb/typec/tcpm/Kconfig
> @@ -35,6 +35,17 @@ config TYPEC_MT6360
> USB Type-C. It works with Type-C Port Controller Manager
> to provide USB PD and USB Type-C functionalities.
>
> +config TYPEC_TCPCI_MT6370
> + tristate "MediaTek MT6370 Type-C driver"
> + depends on MFD_MT6370
> + help
> + MediaTek MT6370 is a multi-functional IC that includes
> + USB Type-C. It works with Type-C Port Controller Manager
> + to provide USB PD and USB Type-C functionalities.
> +
> + This driver can also be built as a module. The module
> + will be called "tcpci_mt6370".
> +
> config TYPEC_TCPCI_MAXIM
> tristate "Maxim TCPCI based Type-C chip driver"
> help
> diff --git a/drivers/usb/typec/tcpm/Makefile b/drivers/usb/typec/tcpm/Makefile
> index 7d499f3..906d9dc 100644
> --- a/drivers/usb/typec/tcpm/Makefile
> +++ b/drivers/usb/typec/tcpm/Makefile
> @@ -6,4 +6,5 @@ typec_wcove-y := wcove.o
> obj-$(CONFIG_TYPEC_TCPCI) += tcpci.o
> obj-$(CONFIG_TYPEC_RT1711H)+= tcpci_rt1711h.o
> obj-$(CONFIG_TYPEC_MT6360) += tcpci_mt6360.o
> +obj-$(CONFIG_TYPEC_TCPCI_MT6370) += tcpci_mt6370.o
> obj-$(CONFIG_TYPEC_TCPCI_MAXIM)+= tcpci_maxim.o
> diff --git a/drivers/usb/typec/tcpm/tcpci_mt6370.c
> b/drivers/usb/typec/tcpm/tcpci_mt6370.c
> new file mode 100644
> index 000..c5bb201
> --- /dev/null
> +++ b/drivers/usb/typec/tcpm/tcpci_mt6370.c
> @@ -0,0 +1,207 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2022 Richtek Technology Corp.
> + *
> + * Author: ChiYuan Huang
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MT6370_REG_SYSCTRL80x9B
> +
> +#define MT6370_AUTOIDLE_MASK BIT(3)
> +
> +#define MT6370_VENDOR_ID 0x29CF
> +#define MT6370_TCPC_DID_A 0x2170
> +
> +struct mt6370_priv {
> + struct device *dev;
> + struct regulator *vbus;
> + struct tcpci *tcpci;
> + struct tcpci_data tcpci_data;
> +};
> +
> +static const struct reg_sequence mt6370_reg_init[] = {
> + REG_SEQ(0xA0, 0x1, 1000),
> + REG_SEQ(0x81, 0x38, 0),
> + REG_SEQ(0x82, 0x82, 0),
> + REG_SEQ(0xBA, 0xFC, 0),
> + REG_SEQ(0xBB, 0x50, 0),
> + REG_SEQ(0x9E, 0x8F, 0),
> + REG_SEQ(0xA1, 0x5, 0),
> + REG_SEQ(0xA2, 0x4, 0),
> + REG_SEQ(0xA3, 0x4A, 0),
> + REG_SEQ(0xA4, 0x01, 0),
> + REG_SEQ(0x95, 0x01, 0),
> + REG_SEQ(0x80, 0x71, 0),
> + REG_SEQ(0x9B, 0x3A, 1000),
> +};
> +
> +static int mt6370_tcpc_init(struct tcpci *tcpci, struct tcpci_data *data)
> +{
> + u16 did;
> + int ret;
> +
> + ret = regmap_register_patch(data->regmap, mt6370_reg_init,
> + ARRAY_SIZE(mt6370_reg_init));
> + if (ret)
> + return ret;
> +
> + ret = regmap_raw_read(data->regmap, TCPC_BCD_DEV, , sizeof(u16));
> + if (ret)
> + return ret;
> +
> + if (did == MT6370_TCPC_DID_A)
> + return regmap_write(data->regmap, TCPC_FAULT_CTRL, 0x80);
> +
> + return 0;
> +}
> +
> +static int mt6370_tcpc_set_vconn(struct tcpci *tcpci, struct tcpci_data
> *data,
> +bool enable)
> +{
> + return regmap_update_bits(data->regmap, MT6370_REG_SYSCTRL8,
> + MT6370_AUTOIDLE_MASK,
> + enable ? 0 : MT6370_AUTOIDLE_MASK);
> +}
> +
> +static int mt6370_tcpc_set_vbus(struct tcpci *tcpci, struct tcpci_data *data,
> +
Re: [Intel-gfx] [PATCH v3 3/3] drm/i915/gt: document TLB cache invalidation functions
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 know what a > >> GT structure is. I looked thru multiple C and header files yesterday > >> and didn't find any comments about it. > >> > >> Just saying that @gt is a GT structure isn't very helpful, other > >> than making kernel-doc shut up. > > > > the 'gt' belongs to the drivers/gpu/drm/i915/gt/ subsystem and > > it's widely used a throughout i915. > > > > I think it's inappropriate to describe it just here. On the other > > hand I agree that a better documentation is required for the GT > > itself where other parts can point to. GT is actually a well-understood term for GPU developers. It is an alias for: https://en.wikipedia.org/wiki/Intel_Graphics_Technology It is basically the "core" of the GPU, where the engine units sit. I agree with Andi: terms like this should likely be defined on a glossary at i915.rst file. > Yeah agreed there is no point of copy pasting some explanation all over > the place. Could we just do s/GT structure/struct intel_gt/, or "pointer > to struct intel_gt to operate on", would that be good enough? IMO, it won't make any difference. kerneldoc already says that the parameter has struct intel_gt type on its output: .. c:function:: void intel_gt_fini_tlb (struct intel_gt *gt) free TLB-specific vars **Parameters** ``struct intel_gt *gt`` GT structure **Description** Frees any resources needed by TLB cache invalidation logic. This struct somewhat is similar to struct device. This is a container struct that has the common data needed to control the GT hardware. Almost all functions that work with GT needs it. There's not much sense to describe it everywhere. What makes sense is to have struct intel_gt documented at intel_gt_types.h, letting the build system to generate hiperlinks to it. This is easier said than done... Regards, Mauro
FYI: misc: visconti: Toshiba Visconti DSP accelerator driver sample
Hello Odded This is a sample (wip) driver for a DSP found on Toshiba Visconti SoC. The DSP typically accepts some images, apply an algorithm on them and yields resulting one. Therefore (image-in, image-out), they say this driver should be classified to media driver category. However, it can handle various data format (wider than v4l2 officially supports) if userland provide firmware (=algorithm) for its own. Yes, this rough implementation is the first step only our staff could go. I'm not for sure whether we could carry out experiments earlier if we chose to use existing frameworks, instead of writing our own routine for handling DMA-BUFs and interrupts. I hope this post will help your case-study. Regards Yuji Ishikawa misc: visconti: Add Toshiba Visconti DSPIF image processing accelerator Add support to DSPIF image processing accelerator on Toshiba Visconti ARM SoCs. The accelerator accepts a task description and a firmware, provides various filter / image processing algorithm. Currently, DSP firmware is fixed one loaded by bootloader. And the phisical address of the firmware is specified from userland, not hard-coded nor loaded from device tree. CPU and DSP share following communication media to manage tasks. * DSP registers: 32bit word access registers to specify DSP firmware address and several parameters. * shared mem: a part of DRAM to pass task description (struct hwd_dspif_msg). The DSP busmaster interface is little endian. * interrupt controller (DCOMM): to notify start event (CPU->DSP) and finish event (DSP->CPU). The implementation has two C sources: * dspif.c The user interface. It receives inference task description from userlan library. manages lifecycle of DMA-BUF instances holding input/output data, managegs interrupt requests and updates device file status. Memory blocks are specified with fds + offsets of DMA-BUF instances. * hwd_dspif.c The hardware layer. It configures hardware registers following a request from dspif.c. This layer communicate with DSP hardware via registers, shared memory and dedicated interrupt controller. Memory blocks are specified with 32bit-truncated phisical address Future plan: * Power management operations will be added, once the visconti clock framework driver supports the DSP hardware. * When the visconti IOMMU driver (currently under review) is accepted, the hardware layer will use 32bit IO virutal address mapped by the dedicated IOMMU. * Better way to load / specify DSP firmware. dt-bindings: misc: visconti: Add Toshiba Visconti DSPIF image processing accelerator bindings Also, here's a Device Tree binding documentation that allows to describe the DSPIF image processing accelerator found in Toshiba Visconti SoCs. Signed-off-by: Yuji Ishikawa --- .../misc/visconti/toshiba,visconti-dspif.yaml | 61 ++ drivers/misc/Kconfig | 1 + drivers/misc/Makefile | 1 + drivers/misc/visconti/Kconfig | 8 + drivers/misc/visconti/Makefile| 7 + drivers/misc/visconti/dspif/Makefile | 8 + drivers/misc/visconti/dspif/dspif.c | 547 ++ drivers/misc/visconti/dspif/hwd_dspif.c | 275 + drivers/misc/visconti/dspif/hwd_dspif.h | 100 include/uapi/linux/visconti-dspif.h | 85 +++ include/uapi/linux/visconti-ipa.h | 87 +++ 11 files changed, 1180 insertions(+) create mode 100644 Documentation/devicetree/bindings/misc/visconti/toshiba,visconti-dspif.yaml create mode 100644 drivers/misc/visconti/Kconfig create mode 100644 drivers/misc/visconti/Makefile create mode 100644 drivers/misc/visconti/dspif/Makefile create mode 100644 drivers/misc/visconti/dspif/dspif.c create mode 100644 drivers/misc/visconti/dspif/hwd_dspif.c create mode 100644 drivers/misc/visconti/dspif/hwd_dspif.h create mode 100644 include/uapi/linux/visconti-dspif.h create mode 100644 include/uapi/linux/visconti-ipa.h diff --git a/Documentation/devicetree/bindings/misc/visconti/toshiba,visconti-dspif.yaml b/Documentation/devicetree/bindings/misc/visconti/toshiba,visconti-dspif.yaml new file mode 100644 index 0..7c10e28dc --- /dev/null +++ b/Documentation/devicetree/bindings/misc/visconti/toshiba,visconti-dspif.yaml @@ -0,0 +1,61 @@ +# SPDX-LIcense-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/visconti/toshiba,visconti-dspif.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Toshiba Visconti DSPIF image processing accerelator + +maintainers: + - Nobuhiro Iwamatsu + +description: | + Toshiba Visconti DSPIF image processing accelerator provides various operation on images. + Visconti5 have up to 4 DSP units. + +properties: + compatible: +items: + - const: toshiba,visconti-dspif + + reg: +items: + - description: DSP control register + - description: DCOMM interrupt
[CI 1/2] drm/i915/edid: convert DP, HDMI and LVDS to drm_edid
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. Especially DP depends on the details parsed from EDID. (The big
behavioural change conflating EDID reading with parsing and property
update was done in commit 5186421cbfe2 ("drm: Introduce epoch counter to
drm_connector"))
v4: Call drm_edid_connector_update() after reading HDMI/DP EDID
v3: Don't leak vga switcheroo EDID in LVDS init (Ville)
v2: Don't leak opregion fallback EDID (Ville)
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
.../gpu/drm/i915/display/intel_connector.c| 4 +-
.../drm/i915/display/intel_display_types.h| 4 +-
drivers/gpu/drm/i915/display/intel_dp.c | 80 +++
drivers/gpu/drm/i915/display/intel_hdmi.c | 28 ---
drivers/gpu/drm/i915/display/intel_lvds.c | 37 +
5 files changed, 87 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
b/drivers/gpu/drm/i915/display/intel_connector.c
index 1dcc268927a2..d83b2a64f618 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -95,12 +95,12 @@ void intel_connector_destroy(struct drm_connector
*connector)
{
struct intel_connector *intel_connector = to_intel_connector(connector);
- kfree(intel_connector->detect_edid);
+ drm_edid_free(intel_connector->detect_edid);
intel_hdcp_cleanup(intel_connector);
if (!IS_ERR_OR_NULL(intel_connector->edid))
- kfree(intel_connector->edid);
+ drm_edid_free(intel_connector->edid);
intel_panel_fini(intel_connector);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 0da9b208d56e..d476df0ac9df 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -592,8 +592,8 @@ struct intel_connector {
struct intel_panel panel;
/* Cached EDID for eDP and LVDS. May hold ERR_PTR for invalid EDID. */
- struct edid *edid;
- struct edid *detect_edid;
+ const struct drm_edid *edid;
+ const struct drm_edid *detect_edid;
/* Number of times hotplug detection was tried after an HPD interrupt */
int hotplug_retries;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 32292c0be2bd..8a3b2dbebe04 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3577,12 +3577,11 @@ static u8 intel_dp_autotest_edid(struct intel_dp
*intel_dp)
intel_dp->aux.i2c_defer_count);
intel_dp->compliance.test_data.edid =
INTEL_DP_RESOLUTION_FAILSAFE;
} else {
- struct edid *block = intel_connector->detect_edid;
+ /* FIXME: Get rid of drm_edid_raw() */
+ const struct edid *block =
drm_edid_raw(intel_connector->detect_edid);
- /* We have to write the checksum
-* of the last block read
-*/
- block += intel_connector->detect_edid->extensions;
+ /* We have to write the checksum of the last block read */
+ block += block->extensions;
if (drm_dp_dpcd_writeb(_dp->aux, DP_TEST_EDID_CHECKSUM,
block->checksum) <= 0)
@@ -4461,7 +4460,7 @@ bool intel_digital_port_connected(struct intel_encoder
*encoder)
return is_connected;
}
-static struct edid *
+static const struct drm_edid *
intel_dp_get_edid(struct intel_dp *intel_dp)
{
struct intel_connector *intel_connector = intel_dp->attached_connector;
@@ -4472,18 +4471,22 @@ intel_dp_get_edid(struct intel_dp *intel_dp)
if (IS_ERR(intel_connector->edid))
return NULL;
- return drm_edid_duplicate(intel_connector->edid);
+ return drm_edid_dup(intel_connector->edid);
} else
- return drm_get_edid(_connector->base,
- _dp->aux.ddc);
+ return drm_edid_read_ddc(_connector->base,
+_dp->aux.ddc);
}
static void
intel_dp_update_dfp(struct intel_dp *intel_dp,
- const struct edid *edid)
+ const struct drm_edid *drm_edid)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_connector *connector = intel_dp->attached_connector;
+ const struct edid *edid;
+
+ /* FIXME: Get rid of drm_edid_raw() */
+ edid = drm_edid_raw(drm_edid);
intel_dp->dfp.max_bpc =
[CI 2/2] drm/i915/bios: convert intel_bios_init_panel() to drm_edid
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 ++-
drivers/gpu/drm/i915/display/intel_bios.h | 4 ++--
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
drivers/gpu/drm/i915/display/intel_lvds.c | 2 +-
4 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 51dde5bfd956..2fa296d8e69d 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -606,14 +606,14 @@ get_lfp_data_tail(const struct bdb_lvds_lfp_data *data,
static int opregion_get_panel_type(struct drm_i915_private *i915,
const struct intel_bios_encoder_data
*devdata,
- const struct edid *edid)
+ const struct drm_edid *drm_edid)
{
return intel_opregion_get_panel_type(i915);
}
static int vbt_get_panel_type(struct drm_i915_private *i915,
const struct intel_bios_encoder_data *devdata,
- const struct edid *edid)
+ const struct drm_edid *drm_edid)
{
const struct bdb_lvds_options *lvds_options;
@@ -638,12 +638,13 @@ static int vbt_get_panel_type(struct drm_i915_private
*i915,
static int pnpid_get_panel_type(struct drm_i915_private *i915,
const struct intel_bios_encoder_data *devdata,
- const struct edid *edid)
+ const struct drm_edid *drm_edid)
{
const struct bdb_lvds_lfp_data *data;
const struct bdb_lvds_lfp_data_ptrs *ptrs;
const struct lvds_pnp_id *edid_id;
struct lvds_pnp_id edid_id_nodate;
+ const struct edid *edid = drm_edid_raw(drm_edid); /* FIXME */
int i, best = -1;
if (!edid)
@@ -685,7 +686,7 @@ static int pnpid_get_panel_type(struct drm_i915_private
*i915,
static int fallback_get_panel_type(struct drm_i915_private *i915,
const struct intel_bios_encoder_data
*devdata,
- const struct edid *edid)
+ const struct drm_edid *drm_edid)
{
return 0;
}
@@ -699,13 +700,13 @@ enum panel_type {
static int get_panel_type(struct drm_i915_private *i915,
const struct intel_bios_encoder_data *devdata,
- const struct edid *edid)
+ const struct drm_edid *drm_edid)
{
struct {
const char *name;
int (*get_panel_type)(struct drm_i915_private *i915,
const struct intel_bios_encoder_data
*devdata,
- const struct edid *edid);
+ const struct drm_edid *drm_edid);
int panel_type;
} panel_types[] = {
[PANEL_TYPE_OPREGION] = {
@@ -728,7 +729,7 @@ static int get_panel_type(struct drm_i915_private *i915,
int i;
for (i = 0; i < ARRAY_SIZE(panel_types); i++) {
- panel_types[i].panel_type = panel_types[i].get_panel_type(i915,
devdata, edid);
+ panel_types[i].panel_type = panel_types[i].get_panel_type(i915,
devdata, drm_edid);
drm_WARN_ON(>drm, panel_types[i].panel_type > 0xf &&
panel_types[i].panel_type != 0xff);
@@ -3144,11 +3145,11 @@ void intel_bios_init(struct drm_i915_private *i915)
void intel_bios_init_panel(struct drm_i915_private *i915,
struct intel_panel *panel,
const struct intel_bios_encoder_data *devdata,
- const struct edid *edid)
+ const struct drm_edid *drm_edid)
{
init_vbt_panel_defaults(panel);
- panel->vbt.panel_type = get_panel_type(i915, devdata, edid);
+ panel->vbt.panel_type = get_panel_type(i915, devdata, drm_edid);
parse_panel_options(i915, panel);
parse_generic_dtd(i915, panel);
diff --git a/drivers/gpu/drm/i915/display/intel_bios.h
b/drivers/gpu/drm/i915/display/intel_bios.h
index e47582b0de0a..defea578a768 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.h
+++ b/drivers/gpu/drm/i915/display/intel_bios.h
@@ -32,8 +32,8 @@
#include
+struct drm_edid;
struct drm_i915_private;
-struct edid;
struct intel_bios_encoder_data;
struct intel_crtc_state;
struct intel_encoder;
@@ -235,7 +235,7 @@ void intel_bios_init(struct drm_i915_private *dev_priv);
void intel_bios_init_panel(struct drm_i915_private *dev_priv,
struct intel_panel *panel,
const struct
Re: [PATCH] [Draft]: media: videobuf2-dma-heap: add a vendor defined memory runtine
On Tue, Aug 2, 2022 at 9:21 PM ayaka wrote: > > Sorry, the previous one contains html data. > > > On Aug 2, 2022, at 3:33 PM, Tomasz Figa wrote: > > > > On Mon, Aug 1, 2022 at 8:43 PM ayaka wrote: > >> Sent from my iPad > On Aug 1, 2022, at 5:46 PM, Tomasz Figa wrote: > >>> CAUTION: Email originated externally, do not click links or open > >>> attachments unless you recognize the sender and know the content is safe. > On Mon, Aug 1, 2022 at 3:44 PM Hsia-Jun Li > wrote: > > On 8/1/22 14:19, Tomasz Figa wrote: > Hello Tomasz > > ?Hi Randy, > > On Mon, Aug 1, 2022 at 5:21 AM wrote: > >> From: Randy Li > >> This module is still at a early stage, I wrote this for showing what > >> APIs we need here. > >> Let me explain why we need such a module here. > >> If you won't allocate buffers from a V4L2 M2M device, this module > >> may not be very useful. I am sure the most of users won't know a > >> device would require them allocate buffers from a DMA-Heap then > >> import those buffers into a V4L2's queue. > >> Then the question goes back to why DMA-Heap. From the Android's > >> description, we know it is about the copyright's DRM. > >> When we allocate a buffer in a DMA-Heap, it may register that buffer > >> in the trusted execution environment so the firmware which is running > >> or could only be acccesed from there could use that buffer later. > >> The answer above leads to another thing which is not done in this > >> version, the DMA mapping. Although in some platforms, a DMA-Heap > >> responses a IOMMU device as well. For the genernal purpose, we would > >> be better assuming the device mapping should be done for each device > >> itself. The problem here we only know alloc_devs in those DMAbuf > >> methods, which are DMA-heaps in my design, the device from the queue > >> is not enough, a plane may requests another IOMMU device or table > >> for mapping. > >> Signed-off-by: Randy Li > >> --- > >> drivers/media/common/videobuf2/Kconfig| 6 + > >> drivers/media/common/videobuf2/Makefile | 1 + > >> .../common/videobuf2/videobuf2-dma-heap.c | 350 ++ > >> include/media/videobuf2-dma-heap.h| 30 ++ > >> 4 files changed, 387 insertions(+) > >> create mode 100644 drivers/media/common/videobuf2/videobuf2-dma-heap.c > >> create mode 100644 include/media/videobuf2-dma-heap.h > > First of all, thanks for the series. > > Possibly a stupid question, but why not just allocate the DMA-bufs > > directly from the DMA-buf heap device in the userspace and just import > > the buffers to the V4L2 device using V4L2_MEMORY_DMABUF? > Sometimes the allocation policy could be very complex, let's suppose a > multiple planes pixel format enabling with frame buffer compression. > Its luma, chroma data could be allocated from a pool which is delegated > for large buffers while its metadata would come from a pool which many > users could take some few slices from it(likes system pool). > Then when we have a new users knowing nothing about this platform, if we > just configure the alloc_devs in each queues well. The user won't need > to know those complex rules. > The real situation could be more complex, Samsung MFC's left and right > banks could be regarded as two pools, many devices would benefit from > this either from the allocation times or the security buffers policy. > In our design, when we need to do some security decoding(DRM video), > codecs2 would allocate buffers from the pool delegated for that. While > the non-DRM video, users could not care about this. > >>> I'm a little bit surprised about this, because on Android all the > >>> graphics buffers are allocated from the system IAllocator and imported > >>> to the specific devices. > >> In the non-tunnel mode, yes it is. While the tunnel mode is completely > >> vendor defined. Neither HWC nor codec2 cares about where the buffers > >> coming from, you could do what ever you want. > >> Besides there are DRM video in GNU Linux platform, I heard the webkit has > >> made huge effort here and Playready is one could work in non-Android Linux. > >>> Would it make sense to instead extend the UAPI to expose enough > >>> information about the allocation requirements to the userspace, so it > >>> can allocate correctly? > >> Yes, it could. But as I said it would need the users to do more works. > >>> My reasoning here is that it's not a driver's decision to allocate > >>> from a DMA-buf heap (and which one) or not. It's the userspace which > >>> knows that, based on the specific use case that it wants to fulfill. > >> Although I would like to let the users decide that, users just can’t do > >> that which would violate the security rules in some platforms. > >> For example, video codec and
RE: mainline build failure for x86_64 allmodconfig with clang
... > * NOTE: > * This file is gcc-parsable HW gospel, coming straight from HW engineers. I never trust hardware engineers to write code :-) (Although at the moment they trust me to write VHDL...) David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH v3 3/3] drm/i915/gt: document TLB cache invalidation functions
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 find any comments about it. Just saying that @gt is a GT structure isn't very helpful, other than making kernel-doc shut up. the 'gt' belongs to the drivers/gpu/drm/i915/gt/ subsystem and it's widely used a throughout i915. I think it's inappropriate to describe it just here. On the other hand I agree that a better documentation is required for the GT itself where other parts can point to. Yeah agreed there is no point of copy pasting some explanation all over the place. Could we just do s/GT structure/struct intel_gt/, or "pointer to struct intel_gt to operate on", would that be good enough? Regards, Tvrtko
Re: [PATCH v4 4/6] drm/i915: Implement intersect/compatible functions
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 König
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 41 +--
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 73 +++
2 files changed, 74 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 70e2ed4e99df..bf5fd6886ca0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -379,7 +379,6 @@ static bool i915_ttm_eviction_valuable(struct
ttm_buffer_object *bo,
const struct ttm_place *place)
{
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
- struct ttm_resource *res = bo->resource;
if (!obj)
return false;
@@ -396,45 +395,7 @@ static bool i915_ttm_eviction_valuable(struct
ttm_buffer_object *bo,
if (!i915_gem_object_evictable(obj))
return false;
- switch (res->mem_type) {
- case I915_PL_LMEM0: {
- struct ttm_resource_manager *man =
- ttm_manager_type(bo->bdev, res->mem_type);
- struct i915_ttm_buddy_resource *bman_res =
- to_ttm_buddy_resource(res);
- struct drm_buddy *mm = bman_res->mm;
- struct drm_buddy_block *block;
-
- if (!place->fpfn && !place->lpfn)
- return true;
-
- GEM_BUG_ON(!place->lpfn);
-
- /*
-* If we just want something mappable then we can quickly check
-* if the current victim resource is using any of the CPU
-* visible portion.
-*/
- if (!place->fpfn &&
- place->lpfn == i915_ttm_buddy_man_visible_size(man))
- return bman_res->used_visible_size > 0;
-
- /* Real range allocation */
- list_for_each_entry(block, _res->blocks, link) {
- unsigned long fpfn =
- drm_buddy_block_offset(block) >> PAGE_SHIFT;
- unsigned long lpfn = fpfn +
- (drm_buddy_block_size(mm, block) >> PAGE_SHIFT);
-
- if (place->fpfn < lpfn && place->lpfn > fpfn)
- return true;
- }
- return false;
- } default:
- break;
- }
-
- return true;
+ return ttm_bo_eviction_valuable(bo, place);
}
static void i915_ttm_evict_flags(struct ttm_buffer_object *bo,
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
index a5109548abc0..9def01d5f368 100644
--- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
+++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
@@ -178,6 +178,77 @@ static void i915_ttm_buddy_man_free(struct
ttm_resource_manager *man,
kfree(bman_res);
}
+static bool i915_ttm_buddy_man_intersects(struct ttm_resource_manager *man,
+ struct ttm_resource *res,
+ const struct ttm_place *place,
+ size_t size)
+{
+ struct i915_ttm_buddy_resource *bman_res = to_ttm_buddy_resource(res);
+ struct i915_ttm_buddy_manager *bman = to_buddy_manager(man);
+ struct drm_buddy *mm = >mm;
+ struct drm_buddy_block *block;
+
+ if (!place->fpfn && !place->lpfn)
+ return true;
+
+ GEM_BUG_ON(!place->lpfn);
+
+ /*
+* If we just want something mappable then we can quickly check
+* if the current victim resource is using any of the CP
Nit: s/CP/CPU/
Reviewed-by: Matthew Auld
+* visible portion.
+*/
+ if (!place->fpfn &&
+ place->lpfn == i915_ttm_buddy_man_visible_size(man))
+ return bman_res->used_visible_size > 0;
+
+ /* Check each drm buddy block individually */
+ list_for_each_entry(block, _res->blocks, link) {
+ unsigned long fpfn =
+ drm_buddy_block_offset(block) >> PAGE_SHIFT;
+ unsigned long lpfn = fpfn +
+ (drm_buddy_block_size(mm, block) >> PAGE_SHIFT);
+
+ if (place->fpfn < lpfn && place->lpfn > fpfn)
+ return true;
+ }
+
+ return false;
+}
+
+static bool i915_ttm_buddy_man_compatible(struct ttm_resource_manager *man,
+ struct ttm_resource *res,
+ const struct ttm_place *place,
+
Re: [PATCH v3 3/3] drm/i915/gt: document TLB cache invalidation functions
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 it. > > Just saying that @gt is a GT structure isn't very helpful, other > than making kernel-doc shut up. the 'gt' belongs to the drivers/gpu/drm/i915/gt/ subsystem and it's widely used a throughout i915. I think it's inappropriate to describe it just here. On the other hand I agree that a better documentation is required for the GT itself where other parts can point to. Andi
Re: [Intel-gfx] [PULL] drm-intel-next-fixes
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 following changes since commit 2bc7ea71a73747a77e7f83bc085b0d2393235410: > > Merge tag 'topic/nouveau-misc-2022-07-27' of > git://anongit.freedesktop.org/drm/drm into drm-next (2022-07-27 11:34:07 > +1000) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-intel > tags/drm-intel-next-fixes-2022-08-04 > > for you to fetch changes up to e57b9369e0c6f60155027e120fafd4b57e385b71: > > drm/i915/gt: Batch TLB invalidations (2022-08-01 09:48:06 -0400) > > > - disable pci resize on 32-bit systems (Nirmoy) > - don't leak the ccs state (Matt) > - TLB invalidation fixes (Chris) > > > Chris Wilson (4): > drm/i915/gt: Ignore TLB invalidations on idle engines > drm/i915/gt: Invalidate TLB of the OA unit at TLB invalidations > drm/i915/gt: Skip TLB invalidations once wedged > drm/i915/gt: Batch TLB invalidations This patch actually adds a regression due to a silly mistake. The fix is here: https://patchwork.freedesktop.org/patch/496249/?series=106805=4 Regards, Mauro
RE: imx8mm lcdif->dsi->adv7535 no video, no errors
Hi Adam and all, > Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors > > On Thu, Aug 4, 2022 at 9:52 AM Dave Stevenson > wrote: > > > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch > wrote: > > > > > > Hi Dave, > > > > > > On 22-08-04, Dave Stevenson wrote: > > > > Hi Marco > > > > > > > > On Thu, 4 Aug 2022 at 10:38, Marco Felsch > wrote: > > > > > > > > > > Hi Dave, Adam, > > > > > > > > > > On 22-08-03, Dave Stevenson wrote: > > > > > > Hi Adam > > > > > > > > > > > > On Wed, 3 Aug 2022 at 12:03, Adam Ford > wrote: > > > > > > > > > > ... > > > > > > > > > > > > > Did managed to get access to the ADV7535 programming > > > > > > > > guide? This is the black box here. Let me check if I can > > > > > > > > provide you a link with our repo so you can test our > current DSIM state if you want. > > > > > > > > > > > > > > I do have access to the programming guide, but it's under > > > > > > > NDA, but I'll try to answer questions if I can. > > > > > > > > > > > > Not meaning to butt in, but I have datasheets for ADV7533 and > > > > > > 7535 from previously looking at these chips. > > > > > > > > > > Thanks for stepping into :) > > > > > > > > > > > Mine fairly plainly states: > > > > > > "The DSI receiver input supports DSI video mode operation > > > > > > only, and specifically, only supports nonburst mode with sync > pulses". > > > > > > > > > > I've read this also, and we are working in nonburst mode with > > > > > sync pulses. I have no access to an MIPI-DSI analyzer therefore > > > > > I can't verify it. > > > > > > > > > > > Non-burst mode meaning that the DSI pixel rate MUST be the > > > > > > same as the HDMI pixel rate. > > > > > > > > > > On DSI side you don't have a pixel-clock instead there is bit- > clock. > > > > > > > > You have an effective pixel clock, with a fixed conversion for the > > > > configuration. > > > > > > > > DSI bit-clock * number of lanes / bits_per_pixel = pixel rate. > > > > 891Mbit/s * 4 lanes / 24bpp = 148.5 Mpixels/s > > > > > > Okay, I just checked the bandwidth which must equal. > > > > > > > As noted elsewhere, the DSI is DDR, so the clock lane itself is > > > > only running at 891 / 2 = 445.5MHz. > > > > > > > > > > Section 6.1.1 "DSI Input Modes" of > > > > > > adv7533_hardware_user_s_guide is even more explicit about the > > > > > > requirement of DSI timing matching > > > > > > > > > > Is it possible to share the key points of the requirements? > > > > > > > > "Specifically the ADV7533 supports the Non-Burst Mode with syncs. > > > > This mode requires real time data generation as a pulse packet > > > > received becomes a pulse generated. Therefore this mode requires a > > > > continuous stream of data with correct video timing to avoid any > > > > visual artifacts." > > > > > > > > LP mode is supported on data lanes. Clock lane must remain in HS > mode. > > > > > > > > "... the goal is to accurately convey DPI-type timing over DSI. > > > > This includes matching DPI pixel-transmission rates, and widths of > > > > timing events." > > > > > > Thanks for sharing. > > > > > > > > > The NXP kernel switching down to an hs_clk of 445.5MHz would > > > > > > therefore be correct for 720p operation. > > > > > > > > > > It should be absolute no difference if you work on 891MHz with 2 > > > > > lanes or on 445.5 MHz with 4 lanes. What must be ensured is that > > > > > you need the minimum required bandwidth which is roughly: > > > > > 1280*720*24*60 = 1.327 GBps. > > > > > > > > Has someone changed the number of lanes in use? I'd missed that if > > > > so, but I'll agree that 891MHz over 2 lanes should work for > 720p60. > > > > > > The ADV driver is changing it autom. but this logic is somehow odd > > > and there was already a approach to stop the driver doing this. > > > > I'd missed that bit in the driver where it appears to drop to 3 lanes > > for pixel clock < 8 via a mipi_dsi_detach and _attach. Quirky, but > > probably the only way it can be achieved in the current framework. > > > > > To sync up: we have two problems: > > > 1) The 720P mode with static DSI host configuration isn't working > > > without hacks. > > > 2) The DSI link frequency should changed as soon as required > > > automatically. So we can provide all modes. > > > > > > I would concentrate on problem 1 first before moving on to the 2nd. > > > > If you change your link frequency, it may be worth trying a lower > > resolution again such as 720x480 @ 60fps on 2 lanes. (720480@60 on 4 > > lanes is again listed as mandatory for using the timing generator). > > > > > > I have just noted that 720p59.94 at 24bpp on 4 lanes is listed as > > > > one of the modes that is mandatory to use the timing generator > > > > (reg 0x27 bit 7 = 1). On 2 lanes it is not required. > > > > I don't know why it's referencing the 1000/1001 pixel clock rates > > > > and not the base one, as it's only a base clock change with the > > > > same timing (74.176MHz clock instead of 74.25MHz). > > > > > >
Re: [PATCH v15 03/11] drm/edid: Add cea_sad helpers for freq/length
On Fri, 05 Aug 2022, Rex-BC Chen wrote:
> On Tue, 2022-08-02 at 17:11 +0300, Jani Nikula wrote:
>> On Wed, 27 Jul 2022, Bo-Chen Chen wrote:
>> > From: Guillaume Ranquet
>> >
>> > This patch adds two helper functions that extract the frequency and
>> > word
>> > length from a struct cea_sad.
>> >
>> > For these helper functions new defines are added that help
>> > translate the
>> > 'freq' and 'byte2' fields into real numbers.
>>
>> I think we should stop adding a plethora of functions that deal with
>> sads like this.
>>
>> There should probably be *one* struct that contains all the details
>> you
>> and everyone need extracted. There should be *one* function that
>> fills
>> in all the details. The struct should be placed in
>> connector->display_info, and the function should be called *once*
>> from
>> update_display_info().
>>
>> Ideally, the function shouldn't even be exposed from drm_edid.c, but
>> if
>> you still need to deal with situations where you don't call connector
>> update, maybe it needs to be exposed.
>>
>> BR,
>> Jani.
>>
>>
>
> Hello Jani,
>
> Thanks for your review.
> After checking our patches, we found we will not use these two function
> because we remove them in patch [11/11] drm/mediatek: Use cached audio
> config when changing resolution.
>
> I will drop [02/11] and [03/11].
>
> Thanks!
Thank you too! :)
BR,
Jani.
>
> BRs,
> Bo-Chen
>
>> >
>> > Signed-off-by: Markus Schneider-Pargmann
>> > Signed-off-by: Guillaume Ranquet
>> > Signed-off-by: Bo-Chen Chen
>> > ---
>> > drivers/gpu/drm/drm_edid.c | 63
>> > ++
>> > include/drm/drm_edid.h | 14 +
>> > 2 files changed, 77 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/drm_edid.c
>> > b/drivers/gpu/drm/drm_edid.c
>> > index bc43e1b32092..2a6f92da5ff3 100644
>> > --- a/drivers/gpu/drm/drm_edid.c
>> > +++ b/drivers/gpu/drm/drm_edid.c
>> > @@ -4916,6 +4916,69 @@ int drm_edid_to_speaker_allocation(const
>> > struct edid *edid, u8 **sadb)
>> > }
>> > EXPORT_SYMBOL(drm_edid_to_speaker_allocation);
>> >
>> > +/**
>> > + * drm_cea_sad_get_sample_rate - Extract the sample rate from
>> > cea_sad
>> > + * @sad: Pointer to the cea_sad struct
>> > + *
>> > + * Extracts the cea_sad frequency field and returns the sample
>> > rate in Hz.
>> > + *
>> > + * Return: Sample rate in Hz or a negative errno if parsing
>> > failed.
>> > + */
>> > +int drm_cea_sad_get_sample_rate(const struct cea_sad *sad)
>> > +{
>> > + switch (sad->freq) {
>> > + case DRM_CEA_SAD_FREQ_32KHZ:
>> > + return 32000;
>> > + case DRM_CEA_SAD_FREQ_44KHZ:
>> > + return 44100;
>> > + case DRM_CEA_SAD_FREQ_48KHZ:
>> > + return 48000;
>> > + case DRM_CEA_SAD_FREQ_88KHZ:
>> > + return 88200;
>> > + case DRM_CEA_SAD_FREQ_96KHZ:
>> > + return 96000;
>> > + case DRM_CEA_SAD_FREQ_176KHZ:
>> > + return 176400;
>> > + case DRM_CEA_SAD_FREQ_192KHZ:
>> > + return 192000;
>> > + default:
>> > + return -EINVAL;
>> > + }
>> > +}
>> > +EXPORT_SYMBOL(drm_cea_sad_get_sample_rate);
>> > +
>> > +/**
>> > + * drm_cea_sad_get_uncompressed_word_length - Extract word length
>> > + * @sad: Pointer to the cea_sad struct
>> > + *
>> > + * Extracts the cea_sad byte2 field and returns the word length
>> > for an
>> > + * uncompressed stream.
>> > + *
>> > + * Note: This function may only be called for uncompressed audio.
>> > + *
>> > + * Return: Word length in bits or a negative errno if parsing
>> > failed.
>> > + */
>> > +int drm_cea_sad_get_uncompressed_word_length(const struct cea_sad
>> > *sad)
>> > +{
>> > + if (sad->format != HDMI_AUDIO_CODING_TYPE_PCM) {
>> > + DRM_WARN("Unable to get the uncompressed word length
>> > for format: %u\n",
>> > + sad->format);
>> > + return -EINVAL;
>> > + }
>> > +
>> > + switch (sad->byte2) {
>> > + case DRM_CEA_SAD_UNCOMPRESSED_WORD_16BIT:
>> > + return 16;
>> > + case DRM_CEA_SAD_UNCOMPRESSED_WORD_20BIT:
>> > + return 20;
>> > + case DRM_CEA_SAD_UNCOMPRESSED_WORD_24BIT:
>> > + return 24;
>> > + default:
>> > + return -EINVAL;
>> > + }
>> > +}
>> > +EXPORT_SYMBOL(drm_cea_sad_get_uncompressed_word_length);
>> > +
>> > /**
>> > * drm_av_sync_delay - compute the HDMI/DP sink audio-video sync
>> > delay
>> > * @connector: connector associated with the HDMI/DP sink
>> > diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
>> > index c2c43a4af681..779b710aed40 100644
>> > --- a/include/drm/drm_edid.h
>> > +++ b/include/drm/drm_edid.h
>> > @@ -373,6 +373,18 @@ struct cea_sad {
>> >u8 byte2;
>> > };
>> >
>> > +#define DRM_CEA_SAD_FREQ_32KHZ BIT(0)
>> > +#define DRM_CEA_SAD_FREQ_44KHZ BIT(1)
>> > +#define DRM_CEA_SAD_FREQ_48KHZ BIT(2)
>> > +#define DRM_CEA_SAD_FREQ_88KHZ BIT(3)
>> > +#define DRM_CEA_SAD_FREQ_96KHZ BIT(4)
>> > +#define DRM_CEA_SAD_FREQ_176KHZ BIT(5)
>> > +#define DRM_CEA_SAD_FREQ_192KHZ BIT(6)
>> > +
[PATCH v7 04/13] dt-bindings: leds: Add MediaTek MT6370 flashlight
From: Alice Chen Add MediaTek MT6370 flashlight binding documentation. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Alice Chen Signed-off-by: ChiaEn Wu --- .../bindings/leds/mediatek,mt6370-flashlight.yaml | 41 ++ 1 file changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/mediatek,mt6370-flashlight.yaml diff --git a/Documentation/devicetree/bindings/leds/mediatek,mt6370-flashlight.yaml b/Documentation/devicetree/bindings/leds/mediatek,mt6370-flashlight.yaml new file mode 100644 index 000..e9d02ed --- /dev/null +++ b/Documentation/devicetree/bindings/leds/mediatek,mt6370-flashlight.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/mediatek,mt6370-flashlight.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Flash LED driver for MT6370 PMIC from MediaTek Integrated. + +maintainers: + - Alice Chen + +description: | + This module is part of the MT6370 MFD device. + Add MT6370 flash LED driver include 2-channel flash LED support Torch/Strobe Mode. + +properties: + compatible: +const: mediatek,mt6370-flashlight + + "#address-cells": +const: 1 + + "#size-cells": +const: 0 + +patternProperties: + "^led@[0-1]$": +type: object +$ref: common.yaml# +unevaluatedProperties: false + +properties: + reg: +enum: [0, 1] + +required: + - compatible + - "#address-cells" + - "#size-cells" + +additionalProperties: false -- 2.7.4
[PATCH v7 12/13] leds: flash: mt6370: Add MediaTek MT6370 flashlight support
From: Alice Chen
The MediaTek MT6370 is a highly-integrated smart power management IC,
which includes a single cell Li-Ion/Li-Polymer switching battery
charger, a USB Type-C & Power Delivery (PD) controller, dual Flash
LED current sources, a RGB LED driver, a backlight WLED driver,
a display bias driver and a general LDO for portable devices.
Add a support for the MT6370 Flash LED driver. Flash LED in MT6370
has 2 channels and support torch/strobe mode.
Signed-off-by: Alice Chen
Signed-off-by: ChiaEn Wu
---
v7
- Fix the indentation.
- For the well defined macro, the parenthesis is needed for input parameters.
- Replace some dev_warn to dev_info in 'init_flash_properties'.
- Add sentinel comment for the terminator entry of of_device_id.
- Use priv->fled_torch_used directly.
- Delete 0 in {}.
- Use _uA instead of _UA in definition.
- Refine the description.
- Use usleep_range instead of udelay.
- Rename config to LEDS_MT6370_FLASH.
- Add missing ">" in copyright.
- Change the Kconfig order
---
drivers/leds/flash/Kconfig | 12 +
drivers/leds/flash/Makefile| 1 +
drivers/leds/flash/leds-mt6370-flash.c | 632 +
3 files changed, 645 insertions(+)
create mode 100644 drivers/leds/flash/leds-mt6370-flash.c
diff --git a/drivers/leds/flash/Kconfig b/drivers/leds/flash/Kconfig
index d3eb689..4b1afc1 100644
--- a/drivers/leds/flash/Kconfig
+++ b/drivers/leds/flash/Kconfig
@@ -61,6 +61,18 @@ config LEDS_MT6360
Independent current sources supply for each flash LED support torch
and strobe mode.
+config LEDS_MT6370_FLASH
+ tristate "Flash LED Support for MediaTek MT6370 PMIC"
+ depends on LEDS_CLASS
+ depends on MFD_MT6370
+ help
+ Support 2 channels and torch/strobe mode.
+ Say Y here to enable support for
+ MT6370_FLASH_LED device.
+
+ This driver can also be built as a module. If so, the module
+ will be called "leds-mt6370-flash".
+
config LEDS_RT4505
tristate "LED support for RT4505 flashlight controller"
depends on I2C && OF
diff --git a/drivers/leds/flash/Makefile b/drivers/leds/flash/Makefile
index 0acbddc..0c1f3c5 100644
--- a/drivers/leds/flash/Makefile
+++ b/drivers/leds/flash/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_LEDS_MAX77693) += leds-max77693.o
obj-$(CONFIG_LEDS_RT4505) += leds-rt4505.o
obj-$(CONFIG_LEDS_RT8515) += leds-rt8515.o
obj-$(CONFIG_LEDS_SGM3140) += leds-sgm3140.o
+obj-$(CONFIG_LEDS_MT6370_FLASH)+= leds-mt6370-flash.o
diff --git a/drivers/leds/flash/leds-mt6370-flash.c
b/drivers/leds/flash/leds-mt6370-flash.c
new file mode 100644
index 000..e36e264
--- /dev/null
+++ b/drivers/leds/flash/leds-mt6370-flash.c
@@ -0,0 +1,632 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 Richtek Technology Corp.
+ *
+ * Author: Alice Chen
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+enum {
+ MT6370_LED_FLASH1,
+ MT6370_LED_FLASH2,
+ MT6370_MAX_LEDS
+};
+
+/* Virtual definition for multicolor */
+
+#define MT6370_REG_FLEDEN 0x17E
+#define MT6370_REG_STRBTO 0x173
+#define MT6370_REG_CHGSTAT20x1D1
+#define MT6370_REG_FLEDSTAT1 0x1D9
+#define MT6370_REG_FLEDISTRB(_id) (0x174 + 4 * (_id))
+#define MT6370_REG_FLEDITOR(_id) (0x175 + 4 * (_id))
+#define MT6370_ITORCH_MASK GENMASK(4, 0)
+#define MT6370_ISTROBE_MASKGENMASK(6, 0)
+#define MT6370_STRBTO_MASK GENMASK(6, 0)
+#define MT6370_TORCHEN_MASKBIT(3)
+#define MT6370_STROBEN_MASKBIT(2)
+#define MT6370_FLCSEN_MASK(_id)BIT(MT6370_LED_FLASH2 - (_id))
+#define MT6370_FLCSEN_MASK_ALL GENMASK(1, 0)
+#define MT6370_FLEDCHGVINOVP_MASK BIT(3)
+#define MT6370_FLED1STRBTO_MASKBIT(11)
+#define MT6370_FLED2STRBTO_MASKBIT(10)
+#define MT6370_FLED1STRB_MASK BIT(9)
+#define MT6370_FLED2STRB_MASK BIT(8)
+#define MT6370_FLED1SHORT_MASK BIT(7)
+#define MT6370_FLED2SHORT_MASK BIT(6)
+#define MT6370_FLEDLVF_MASKBIT(3)
+
+#define MT6370_LED_JOINT 2
+#define MT6370_RANGE_FLED_REG 4
+#define MT6370_ITORCH_MIN_uA 25000
+#define MT6370_ITORCH_STEP_uA 12500
+#define MT6370_ITORCH_MAX_uA 40
+#define MT6370_ITORCH_DOUBLE_MAX_uA80
+#define MT6370_ISTRB_MIN_uA5
+#define MT6370_ISTRB_STEP_uA 12500
+#define MT6370_ISTRB_MAX_uA150
+#define MT6370_ISTRB_DOUBLE_MAX_uA 300
+#define MT6370_STRBTO_MIN_US 64000
+#define MT6370_STRBTO_STEP_US 32000
+#define MT6370_STRBTO_MAX_US 2432000
+
+#define STATE_OFF 0
+#define STATE_KEEP 1
+#define STATE_ON 2
[PATCH v7 07/13] mfd: mt6370: Add MediaTek MT6370 support
From: ChiYuan Huang
This adds support for the MediaTek MT6370 SubPMIC. MediaTek MT6370 is a
SubPMIC consisting of a single cell battery charger with ADC monitoring,
RGB LEDs, dual channel flashlight, WLED backlight driver, display bias
voltage supply, one general purpose LDO, and the USB Type-C & PD controller
complies with the latest USB Type-C and PD standards.
Reviewed-by: Andy Shevchenko
Signed-off-by: ChiYuan Huang
Signed-off-by: ChiaEn Wu
---
v7
- Move '#define MT6370_REG_MAXADDR' to the next line of
'#define MT6370_REG_CHG_MASK1'
- Rename 'MT6370_REG_ADDRLEN' to 'MT6370_MAX_ADDRLEN'
---
drivers/mfd/Kconfig | 16 +++
drivers/mfd/Makefile | 1 +
drivers/mfd/mt6370.c | 312 +++
drivers/mfd/mt6370.h | 99
4 files changed, 428 insertions(+)
create mode 100644 drivers/mfd/mt6370.c
create mode 100644 drivers/mfd/mt6370.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 9566341..0666bda 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -938,6 +938,22 @@ config MFD_MT6360
PMIC part includes 2-channel BUCKs and 2-channel LDOs
LDO part includes 4-channel LDOs
+config MFD_MT6370
+ tristate "MediaTek MT6370 SubPMIC"
+ select MFD_CORE
+ select REGMAP_I2C
+ select REGMAP_IRQ
+ depends on I2C
+ help
+ Say Y here to enable MT6370 SubPMIC functional support.
+ It consists of a single cell battery charger with ADC monitoring, RGB
+ LEDs, dual channel flashlight, WLED backlight driver, display bias
+ voltage supply, one general purpose LDO, and the USB Type-C & PD
+ controller complies with the latest USB Type-C and PD standards.
+
+ This driver can also be built as a module. If so, the module
+ will be called "mt6370".
+
config MFD_MT6397
tristate "MediaTek MT6397 PMIC Support"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 8c69867..81dbed3 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -173,6 +173,7 @@ obj-$(CONFIG_MFD_MAX8998) += max8998.o max8998-irq.o
obj-$(CONFIG_MFD_MP2629) += mp2629.o
obj-$(CONFIG_MFD_MT6360) += mt6360-core.o
+obj-$(CONFIG_MFD_MT6370) += mt6370.o
mt6397-objs:= mt6397-core.o mt6397-irq.o mt6358-irq.o
obj-$(CONFIG_MFD_MT6397) += mt6397.o
diff --git a/drivers/mfd/mt6370.c b/drivers/mfd/mt6370.c
new file mode 100644
index 000..cf19cce
--- /dev/null
+++ b/drivers/mfd/mt6370.c
@@ -0,0 +1,312 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 Richtek Technology Corp.
+ *
+ * Author: ChiYuan Huang
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "mt6370.h"
+
+#define MT6370_REG_DEV_INFO0x100
+#define MT6370_REG_CHG_IRQ10x1C0
+#define MT6370_REG_CHG_MASK1 0x1E0
+#define MT6370_REG_MAXADDR 0x1FF
+
+#define MT6370_VENID_MASK GENMASK(7, 4)
+
+#define MT6370_NUM_IRQREGS 16
+#define MT6370_USBC_I2CADDR0x4E
+#define MT6370_MAX_ADDRLEN 2
+
+#define MT6370_VENID_RT50810x8
+#define MT6370_VENID_RT5081A 0xA
+#define MT6370_VENID_MT63700xE
+#define MT6370_VENID_MT63710xF
+#define MT6370_VENID_MT6372P 0x9
+#define MT6370_VENID_MT6372CP 0xB
+
+static const struct regmap_irq mt6370_irqs[] = {
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_DIRCHGON, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_CHG_TREG, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_CHG_AICR, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_CHG_MIVR, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_PWR_RDY, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_FL_CHG_VINOVP, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_CHG_VSYSUV, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_CHG_VSYSOV, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_CHG_VBATOV, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_CHG_VINOVPCHG, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_TS_BAT_COLD, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_TS_BAT_COOL, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_TS_BAT_WARM, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_TS_BAT_HOT, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_TS_STATC, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_CHG_FAULT, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_CHG_STATC, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_CHG_TMR, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_CHG_BATABS, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_CHG_ADPBAD, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_CHG_RVP, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_TSHUTDOWN, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_CHG_IINMEAS, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_CHG_ICCMEAS, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_CHGDET_DONE, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_WDTMR, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_SSFINISH, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_CHG_RECHG, 8),
+ REGMAP_IRQ_REG_LINE(MT6370_IRQ_CHG_TERM, 8),
+
[PATCH v7 08/13] usb: typec: tcpci_mt6370: Add MediaTek MT6370 tcpci driver
From: ChiYuan Huang
The MediaTek MT6370 is a highly-integrated smart power management IC,
which includes a single cell Li-Ion/Li-Polymer switching battery
charger, a USB Type-C & Power Delivery (PD) controller, dual
Flash LED current sources, a RGB LED driver, a backlight WLED driver,
a display bias driver and a general LDO for portable devices.
Add a support for the Type-C & Power Delivery controller in
MediaTek MT6370 IC.
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Guenter Roeck
Signed-off-by: ChiYuan Huang
Signed-off-by: ChiaEn Wu
---
v7
- Revise 'devm_add_action_or_reset(dev, ...)' to one line
- Revise 'return regmap_update_bits(...)' with using positive
conditional
---
drivers/usb/typec/tcpm/Kconfig| 11 ++
drivers/usb/typec/tcpm/Makefile | 1 +
drivers/usb/typec/tcpm/tcpci_mt6370.c | 207 ++
3 files changed, 219 insertions(+)
create mode 100644 drivers/usb/typec/tcpm/tcpci_mt6370.c
diff --git a/drivers/usb/typec/tcpm/Kconfig b/drivers/usb/typec/tcpm/Kconfig
index 073fd2e..e6b88ca 100644
--- a/drivers/usb/typec/tcpm/Kconfig
+++ b/drivers/usb/typec/tcpm/Kconfig
@@ -35,6 +35,17 @@ config TYPEC_MT6360
USB Type-C. It works with Type-C Port Controller Manager
to provide USB PD and USB Type-C functionalities.
+config TYPEC_TCPCI_MT6370
+ tristate "MediaTek MT6370 Type-C driver"
+ depends on MFD_MT6370
+ help
+ MediaTek MT6370 is a multi-functional IC that includes
+ USB Type-C. It works with Type-C Port Controller Manager
+ to provide USB PD and USB Type-C functionalities.
+
+ This driver can also be built as a module. The module
+ will be called "tcpci_mt6370".
+
config TYPEC_TCPCI_MAXIM
tristate "Maxim TCPCI based Type-C chip driver"
help
diff --git a/drivers/usb/typec/tcpm/Makefile b/drivers/usb/typec/tcpm/Makefile
index 7d499f3..906d9dc 100644
--- a/drivers/usb/typec/tcpm/Makefile
+++ b/drivers/usb/typec/tcpm/Makefile
@@ -6,4 +6,5 @@ typec_wcove-y := wcove.o
obj-$(CONFIG_TYPEC_TCPCI) += tcpci.o
obj-$(CONFIG_TYPEC_RT1711H)+= tcpci_rt1711h.o
obj-$(CONFIG_TYPEC_MT6360) += tcpci_mt6360.o
+obj-$(CONFIG_TYPEC_TCPCI_MT6370) += tcpci_mt6370.o
obj-$(CONFIG_TYPEC_TCPCI_MAXIM)+= tcpci_maxim.o
diff --git a/drivers/usb/typec/tcpm/tcpci_mt6370.c
b/drivers/usb/typec/tcpm/tcpci_mt6370.c
new file mode 100644
index 000..c5bb201
--- /dev/null
+++ b/drivers/usb/typec/tcpm/tcpci_mt6370.c
@@ -0,0 +1,207 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 Richtek Technology Corp.
+ *
+ * Author: ChiYuan Huang
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MT6370_REG_SYSCTRL80x9B
+
+#define MT6370_AUTOIDLE_MASK BIT(3)
+
+#define MT6370_VENDOR_ID 0x29CF
+#define MT6370_TCPC_DID_A 0x2170
+
+struct mt6370_priv {
+ struct device *dev;
+ struct regulator *vbus;
+ struct tcpci *tcpci;
+ struct tcpci_data tcpci_data;
+};
+
+static const struct reg_sequence mt6370_reg_init[] = {
+ REG_SEQ(0xA0, 0x1, 1000),
+ REG_SEQ(0x81, 0x38, 0),
+ REG_SEQ(0x82, 0x82, 0),
+ REG_SEQ(0xBA, 0xFC, 0),
+ REG_SEQ(0xBB, 0x50, 0),
+ REG_SEQ(0x9E, 0x8F, 0),
+ REG_SEQ(0xA1, 0x5, 0),
+ REG_SEQ(0xA2, 0x4, 0),
+ REG_SEQ(0xA3, 0x4A, 0),
+ REG_SEQ(0xA4, 0x01, 0),
+ REG_SEQ(0x95, 0x01, 0),
+ REG_SEQ(0x80, 0x71, 0),
+ REG_SEQ(0x9B, 0x3A, 1000),
+};
+
+static int mt6370_tcpc_init(struct tcpci *tcpci, struct tcpci_data *data)
+{
+ u16 did;
+ int ret;
+
+ ret = regmap_register_patch(data->regmap, mt6370_reg_init,
+ ARRAY_SIZE(mt6370_reg_init));
+ if (ret)
+ return ret;
+
+ ret = regmap_raw_read(data->regmap, TCPC_BCD_DEV, , sizeof(u16));
+ if (ret)
+ return ret;
+
+ if (did == MT6370_TCPC_DID_A)
+ return regmap_write(data->regmap, TCPC_FAULT_CTRL, 0x80);
+
+ return 0;
+}
+
+static int mt6370_tcpc_set_vconn(struct tcpci *tcpci, struct tcpci_data *data,
+bool enable)
+{
+ return regmap_update_bits(data->regmap, MT6370_REG_SYSCTRL8,
+ MT6370_AUTOIDLE_MASK,
+ enable ? 0 : MT6370_AUTOIDLE_MASK);
+}
+
+static int mt6370_tcpc_set_vbus(struct tcpci *tcpci, struct tcpci_data *data,
+ bool source, bool sink)
+{
+ struct mt6370_priv *priv = container_of(data, struct mt6370_priv,
+ tcpci_data);
+ int ret;
+
+ ret = regulator_is_enabled(priv->vbus);
+ if (ret < 0)
+ return ret;
+
+ if (ret && !source)
+ return
Re: [PATCH v3 0/2] Add R16 Vista E board from RenewWorldOutreach
Hi all, Can you guys please review and comment for any changes. Regards Suniel On Mon, Jul 11, 2022 at 3:27 PM Suniel Mahesh wrote: > This patch series adds the R16-Vista-E board from RenewWorldOutreach based > on allwinner R16(A33). > > Patch 1/2 adds the dt-bindings for the board. > > Patch 2/2 adds the board with the following below features: > > General features: > - 1GB RAM > - microSD slot > - Realtek Wifi > - 1 x USB 2.0 > - HDMI IN > - HDMI OUT > - Audio out > - MIPI DSI > - TI DLPC3433 > > It has also connectors to connect an external mini keypad. > > v2 patches can be found here: > > https://lore.kernel.org/all/20220615093900.344726-1-su...@amarulasolutions.com/ > > Suniel Mahesh (2): > dt-bindings: arm: sunxi: Add binding for RenewWorldOutReach > R16-Vista-E board > ARM: dts: sun8i: Add R16 Vista E board from RenewWorldOutreach > > .../devicetree/bindings/arm/sunxi.yaml| 6 + > .../devicetree/bindings/vendor-prefixes.yaml | 2 + > arch/arm/boot/dts/Makefile| 1 + > arch/arm/boot/dts/sun8i-r16-renew-vista-e.dts | 362 ++ > 4 files changed, 371 insertions(+) > create mode 100644 arch/arm/boot/dts/sun8i-r16-renew-vista-e.dts > > -- > 2.25.1 > >
Re: [PATCH v3 1/2] dt-bindings: arm: sunxi: Add binding for RenewWorldOutReach R16-Vista-E board
Hi all, Can you guys please review and comment for any changes. Regards Suniel On Mon, Jul 11, 2022 at 3:27 PM Suniel Mahesh wrote: > Add a binding for the RenewWorldOutReach R16-Vista-E board based on > allwinner R16. > > Signed-off-by: Suniel Mahesh > Signed-off-by: Jagan Teki > Signed-off-by: Christopher Vollo > Acked-by: Rob Herring > --- > Changes for v3: > - As suggested by Samuel Holland: > - vendor prefix documented > - primary author of the commit should be the first signer > > Changes for v2: > - Add missing compatible string > - insert missing signatures of contributors > --- > Documentation/devicetree/bindings/arm/sunxi.yaml | 6 ++ > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 2 files changed, 8 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml > b/Documentation/devicetree/bindings/arm/sunxi.yaml > index 95278a6a9a8e..52b8c9aba6f3 100644 > --- a/Documentation/devicetree/bindings/arm/sunxi.yaml > +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml > @@ -787,6 +787,12 @@ properties: >- const: allwinner,r7-tv-dongle >- const: allwinner,sun5i-a10s > > + - description: RenewWorldOutreach R16-Vista-E > +items: > + - const: renewworldoutreach,r16-vista-e > + - const: allwinner,sun8i-r16 > + - const: allwinner,sun8i-a33 > + >- description: RerVision H3-DVK > items: >- const: rervision,h3-dvk > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml > b/Documentation/devicetree/bindings/vendor-prefixes.yaml > index 6bb20b4554d7..f5cd0acb1036 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > @@ -1030,6 +1030,8 @@ patternProperties: > description: reMarkable AS >"^renesas,.*": > description: Renesas Electronics Corporation > + "^renewworldoutreach,.*": > +description: RENEW WORLD OUTREACH >"^rex,.*": > description: iMX6 Rex Project >"^rervision,.*": > -- > 2.25.1 > >
