dri-devel June 2022

dri-devel@lists.freedesktop.org

332 participants
697 discussions

[PATCH] fbcon: Remove obsolete reference to initmem_freed
by Geert Uytterhoeven 08 Jun '22

08 Jun '22

initmem_freed was removed in v2.1.124, and the underlying issue was fixed for good in commit 92b004d1aa9f367c ("video/logo: prevent use of logos after they have been freed"). Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> --- drivers/video/fbdev/core/fbcon.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index 594650452afd14d8..1be8aa9f80747987 100644 --- a/drivers/video/fbdev/core/fbcon.c +++ b/drivers/video/fbdev/core/fbcon.c @@ -2180,7 +2180,6 @@ static int fbcon_switch(struct vc_data *vc) if (logo_shown == FBCON_LOGO_DRAW) { logo_shown = fg_console; - /* This is protected above by initmem_freed */ fb_show_logo(info, ops->rotate); update_region(vc, vc->vc_origin + vc->vc_size_row * vc->vc_top, -- 2.25.1

2 1

[PATCH] drm/mgag200: Include <linux/vmalloc.h> for G200 BIOS code
by Thomas Zimmermann 08 Jun '22

08 Jun '22

After moving the vmalloc() call to another file, the rsp include statement needs to be moved as well. Resolves a build warning on parisc. drivers/gpu/drm/mgag200/mgag200_g200.c: In function 'mgag200_g200_init_refclk': drivers/gpu/drm/mgag200/mgag200_g200.c:120:16: error: implicit declaration of function 'vmalloc'; did you mean 'kvmalloc'? [-Werror=implicit-function-declaration] Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Fixes: 85397f6bc4ff ("drm/mgag200: Initialize each model in separate function") Reported-by: kernel test robot <lkp(a)intel.com> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Jocelyn Falempe <jfalempe(a)redhat.com> Cc: Dave Airlie <airlied(a)redhat.com> Cc: dri-devel(a)lists.freedesktop.org Link: https://lore.kernel.org/all/202206080734.ztAvDG7O-lkp@intel.com/ --- drivers/gpu/drm/mgag200/mgag200_drv.c | 1 - drivers/gpu/drm/mgag200/mgag200_g200.c | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c b/drivers/gpu/drm/mgag200/mgag200_drv.c index 361eb7dffda1..73e8e4e9e54b 100644 --- a/drivers/gpu/drm/mgag200/mgag200_drv.c +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c @@ -8,7 +8,6 @@ #include <linux/module.h> #include <linux/pci.h> -#include <linux/vmalloc.h> #include <drm/drm_aperture.h> #include <drm/drm_drv.h> diff --git a/drivers/gpu/drm/mgag200/mgag200_g200.c b/drivers/gpu/drm/mgag200/mgag200_g200.c index 616e11391e02..674385921b7f 100644 --- a/drivers/gpu/drm/mgag200/mgag200_g200.c +++ b/drivers/gpu/drm/mgag200/mgag200_g200.c @@ -1,6 +1,7 @@ // SPDX-License-Identifier: GPL-2.0-only #include <linux/pci.h> +#include <linux/vmalloc.h> #include <drm/drm_drv.h> -- 2.36.1

2 1

[PATCH] fbcon: Fix accelerated fbdev scrolling while logo is still shown
by Helge Deller 08 Jun '22

08 Jun '22

There is no need to directly skip over to the SCROLL_REDRAW case while the logo is still shown. When using DRM, this change has no effect because the code will reach the SCROLL_REDRAW case immediately anyway. But if you run an accelerated fbdev driver and have FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION enabled, console scrolling is slowed down by factors so that it feels as if you use a 9600 baud terminal. So, drop those unnecessary checks and speed up fbdev console acceleration during bootup. Signed-off-by: Helge Deller <deller(a)gmx.de> Cc: stable(a)vger.kernel.org diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index c2f9e5711c39..8eb5b73e98bc 100644 --- a/drivers/video/fbdev/core/fbcon.c +++ b/drivers/video/fbdev/core/fbcon.c @@ -1706,8 +1706,6 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned int t, unsigned int b, case SM_UP: if (count > vc->vc_rows) /* Maximum realistic size */ count = vc->vc_rows; - if (logo_shown >= 0) - goto redraw_up; switch (fb_scrollmode(p)) { case SCROLL_MOVE: fbcon_redraw_blit(vc, info, p, t, b - t - count, @@ -1796,8 +1794,6 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned int t, unsigned int b, case SM_DOWN: if (count > vc->vc_rows) /* Maximum realistic size */ count = vc->vc_rows; - if (logo_shown >= 0) - goto redraw_down; switch (fb_scrollmode(p)) { case SCROLL_MOVE: fbcon_redraw_blit(vc, info, p, b - 1, b - t - count,

2 1

[PATCH] fbcon: Fix boundary checks for fbcon=vc:n1-n2 parameters
by Helge Deller 08 Jun '22

08 Jun '22

The user may use the fbcon=vc:<n1>-<n2> option to tell fbcon to take over the given range (n1...n2) of consoles. The value for n1 and n2 needs to be a positive number and up to (MAX_NR_CONSOLES - 1). The given values were not fully checked against those boundaries yet. To fix the issue, convert first_fb_vc and last_fb_vc to unsigned integers and check them against the upper boundary, and make sure that first_fb_vc is smaller than last_fb_vc. Signed-off-by: Helge Deller <deller(a)gmx.de> Cc: stable(a)vger.kernel.org diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index 2fc1b80a26ad..c2f9e5711c39 100644 --- a/drivers/video/fbdev/core/fbcon.c +++ b/drivers/video/fbdev/core/fbcon.c @@ -115,8 +115,8 @@ static int logo_lines; enums. */ static int logo_shown = FBCON_LOGO_CANSHOW; /* console mappings */ -static int first_fb_vc; -static int last_fb_vc = MAX_NR_CONSOLES - 1; +static unsigned int first_fb_vc; +static unsigned int last_fb_vc = MAX_NR_CONSOLES - 1; static int fbcon_is_default = 1; static int primary_device = -1; static int fbcon_has_console_bind; @@ -464,10 +464,12 @@ static int __init fb_console_setup(char *this_opt) options += 3; if (*options) first_fb_vc = simple_strtoul(options, &options, 10) - 1; - if (first_fb_vc < 0) + if (first_fb_vc >= MAX_NR_CONSOLES) first_fb_vc = 0; if (*options++ == '-') last_fb_vc = simple_strtoul(options, &options, 10) - 1; + if (last_fb_vc < first_fb_vc || last_fb_vc >= MAX_NR_CONSOLES) + last_fb_vc = MAX_NR_CONSOLES - 1; fbcon_is_default = 0; continue; }

2 1

[RFC PATCH v2 00/27] DRM.debug on DYNAMIC_DEBUG, add trace events
by Jim Cromie 08 Jun '22

08 Jun '22

DRM.debug API is 23 macros, issuing 10 exclusive categories of debug messages. By rough count, they are used 5140 times in the kernel. These all call drm_dbg or drm_devdbg, which call drm_debug_enabled(), which checks bits in global __drm_debug. Some of these are page-flips and vblanks, and get called often. DYNAMIC_DEBUG (with CONFIG_JUMP_LABEL) is built to avoid this kind of work, with NOOPd jump/callsites. This patchset is RFC because: - it touches 2.5 subsystems: dyndbg, drm, tracefs (new events) - dyndbg class support is built for drm, needs it for validation - new api, used by drm - big memory impact, with 5100 new pr-debug callsites. - drm class bikeshedding opportunities - others, names etc. DYNAMIC_DEBUG: Adapt to directly represent 32 exclusive classes / categories. All existing users get _CLASS_DFLT:31, reserving 0-30 for opt-in. dynamic_debug_register_classes(): Tells dyndbg that caller/client is using .class_id's 0..N, and wants them exposed and manipulatable with names: DRM_UT_KMS etc. Client invokes DYNAMIC_DEBUG_CLASSES to define the name->id map, then registers it during its initialization. Then, when a dyndbg command-query has "class FOO": echo class DRM_UT_KMS +p > /proc/dynamic_debug/control ddebug_change() will 1st ddebug_validate_classname() for each module, using its registered class-maps; only modules which know DRM_UT_KMS will get those callsite adjustments. This "protects" each module's class-id space, unlike "class 4" query syntax. Add bitmap support for: echo 0x02 > /sys/module/drm/parameters/debug Add symbolic bitmap, because we have the class-names: echo +DRM_UT_KMS,+DRM_UT_ATOMIC > /sys/module/drm/parameters/debug Add test_dynamic_debug, to prove out the API. which is (used 3x to prove class-id ranges): - DYNAMIC_DEBUG_CLASSES(var, ... [3 class-name-literals each]) - dynamic_debug_register_classes(var) - dynamic_debug_unregister_classes(var) also (6x): +module_param_cb(<node-name>, &param_ops_dyndbg_classes, /[pt][123]_bitmap/, 0600); Bits 0,1,2 of each of the 6 bitmaps control the 3 named classes in each of 3 groups, toggling their p,T bits respectively. RFC: dynamic_debug_register_classes() cannot act early enough to be in effect at module-load. So this will not work as you'd reasonably expect: modprobe test_dynamic_debug dyndbg='+pfm; class FOO +pfmlt' The 1st query:+pfm will be enabled during load, but in the 2nd query, "class FOO" will be unknown at load time. Early class enablement would be nice. DYNAMIC_DEBUG_CLASSES is a static initializer, which is certainly early enough, but Im missing a trick, suggestions? Wildcarding on classname is possible, maybe useful: echo +DRM_UT_\* > /sys/module/drm/parameters/debug If contemplated in earnest, it should consider the difference between "DRM_*" and "*_KMS", wrt observing across class hierarchies, as well as decide whether that echo means 1st match, or all matching names. __pr_debug_cls(cls, fmt,...) is just for testing, drm doesnt need it. DRM adaptation: Basically, these patches add another layer of macro indirection, which by CONFIG_DRM_USE_DYNAMIC_DEBUG=y, wraps drm_*dbg() in dyndbg's callsite Factory macro, and adds the new descriptor arg to the funcs. With these patches, drm.debugs appear as controllable *pr-dbg* callsites: [ 11.804352] dyndbg: register_classes: drm [ 11.920715] dyndbg: 234 debug prints in module drm_kms_helper [ 11.932135] dyndbg: 2 debug prints in module ttm [ 11.936119] dyndbg: 8 debug prints in module video [ 12.537543] dyndbg: 1756 debug prints in module i915 [ 12.555045] dyndbg: register_classes: i915 [ 12.666727] AMD-Vi: AMD IOMMUv2 functionality not available on this .. [ 13.735310] dyndbg: 3859 debug prints in module amdgpu amdgpu's large count includes: 582 direct uses/mentions of pr_debug 43 defns of DC_LOG_*, which use either pr_debug or DRM_DEBUG_* ~1000 uses of DC_LOG_* 1116 uses of dml_print in drivers/gpu/drm/amd 15 drm_dbg_\\w+ drivers/gpu/drm/amd 273 DRM_DEBUG_\\w+ drivers/gpu/drm/amd i915 has: 1072 drm_dbg_\\w+ drivers/gpu/drm/i915/ | wc -l 200 DRM_DEBUG_\\w+ drivers/gpu/drm/i915/ 46 pr_debug drivers/gpu/drm/i915/ 144 gvt_dbg_\\w+ drivers/gpu/drm/i915/gvt, using pr_debug This impacts the data footprint, so everything new/drm is dependent on DRM_USE_DYNAMIC_DEBUG=y. RFC for DRM: - decoration flags "fmlt" do not work on drm_*dbg(). (drm_*dbg() dont use pr_debug, they *become* one flavor of them) this could (should?) be added, and maybe tailored for drm. some of the device prefixes are very long, a "d" flag could optionalize them. - api use needs review wrt drm life-cycle. enum drm_debug_category and DYNAMIC_DEBUG_CLASSES could be together? - class-names could stand review, perhaps extension "drm:core:" etc have appeared (maybe just from me) or a "plan" to look at it later - i915 & amdgpu have pr_debugs (DC_LOG_*, gvt_dbg_*) that have class-ish prefixes that are separate from, but similar to DRM_UT_*, and could stand review and possible unification with reformed or extended drm categories. - the change to enum drm_debug_category from bitmask values to 0..31 means that we foreclose this possiblility: drm_dbg(DRM_UT_CORE|DRM_UT_KMS, "wierd double-cat experiment"); - nouveau has very few drm.debug calls, has NV_DEBUG, VMM_DEBUG, nvkm_printk_, I havent looked deeply. DYNDBG/DRM -> TRACEFS My 1st try was motivated by Sean Paul's patch - DRM.trace: https://patchwork.freedesktop.org/patch/445549/?series=78133&rev=5 Those used trace_printk, so were not good for upstream. Vincent Whitchurch's code: https://lore.kernel.org/lkml/20200721141105.16034-1-vincent.whitchurch@axis… added similar features, by sending printk:console events from dyndbg. It met with a good reception from Steve Rostedt, so I re-started with that. The biggest addition (from UI viewpoint) is 4 new trace-events, 2 each from dyndbg (pr_debug, dev_dbg) and drm (drm_dbg, drm_dev_dbg); 2 have dev, other 2 avoid storing nulls. Im unsure that 4 distinctions is valuable, but it seemed most obvious to reflect them straight thru to tracefs. RFC: the event/message formats are a bit of a mash-up; in /sys/kernel/tracing: drm/drm_debug/format:print fmt: "%s", __get_str(msg) drm/drm_devdbg/format:print fmt: "cat:%d, %s %s", \ REC->drm_debug_category, dev_name(REC->dev), __get_str(msg) The 1st prints just the mesg itself, 2nd prints category as int; it'd be better if DRM.class-name replaced (not just augmented) the event-name "drm_devdbg" in the trace, is that possible ? dyndbg/prdbg/format: print fmt: "%s.%s %s", REC->desc->modname, REC->desc->function, __get_str(msg) dyndbg/devdbg/format: print fmt: "%s.%s %s", REC->desc->modname, REC->desc->function, __get_str(msg) These add a prefix string similar to dyndbg's decorations, except they don't use dyndbg's "fmlt" decoration flags. There are also 3 vblank trace-events already, declared in: drivers/gpu/drm/drm_trace.h 15:TRACE_EVENT(drm_vblank_event, 35:TRACE_EVENT(drm_vblank_event_queued, 52:TRACE_EVENT(drm_vblank_event_delivered, STATUS kernel-test-robot tested this patchset (on 5.18-rc6). github:[jimc:blead] BUILD SUCCESS 6c59e52ac81dd81ac7da4522a5e15b7ac488d5b5 May 15, 2022, 8:39 AM (1 day ago) Ive been testing, mostly on virtme, mostly with this: #!/bin/bash # test class FOO handling of dynamic-debug alias lmt='modprobe test_dynamic_debug dyndbg=+pmf' alias rmt='rmmod test_dynamic_debug' alias look='grep test_dynamic_debug /proc/dynamic_debug/control' lookfor() { grep $1 /proc/dynamic_debug/control } vx() { echo $* > /sys/module/dynamic_debug/parameters/verbose } # amdgpu has ~2200 pr-debugs (before drm-debug-on-dyndbg), # use them to prove modprobe <mod> dyndbg=+p works test_param_dyndbg() { modprobe amdgpu dyndbg=+pfm let count=$(grep =pmf /proc/dynamic_debug/control | grep amdgpu | wc -l) if [ $count -gt 200 ] ; then echo amdgpu has $count pr-dbgs return 0 else echo failed $count return -1 fi } out=$(test_param_dyndbg) echo out:$out $? [ $? -eq 0 ] || exit $? qry_cmd() { echo "QCMD: $* >control" >&2 echo $* > /proc/dynamic_debug/control } # enable dyndbg tracing dynable() { grep -P \\d $SKT/events/dyndbg/{.,*}/enable echo 1 > $SKT/events/dyndbg/enable grep -P \\d $SKT/events/dyndbg/{.,*}/enable } # enable drm tracing drmable() { grep -P \\d $SKT/events/drm/{.,*}/enable echo 1 > $SKT/events/drm/enable grep -P \\d $SKT/events/drm/{.,*}/enable } function doit() { cat /sys/module/test_dynamic_debug/parameters/do_prints } # test class FOO behavior of test_dynamic_debug module ttest_module__() { flg=$1 dmesg -C modprobe test_dynamic_debug dyndbg=+pfm doit for cls in FOO BAR BUZZ; do qry_cmd module test_dynamic_debug class $cls $flg doit done doit for cls in Foo Bar Buzz; do qry_cmd module test_dynamic_debug class $cls $flg doit done doit for cls in bing bong boom; do qry_cmd module test_dynamic_debug class $cls $flg doit done doit dmesg | grep class } ttest_module() { ttest_module__ +p ttest_module__ -p #ttest_module__ +T #ttest_module__ -T } #dynable #drmable ttest_module grep test_dyn /proc/dynamic_debug/control # use/test bitmaps set_tddm_() { val=$1; knob=$2; echo "TDDM: $val >$knob" >&2 echo $val > /sys/module/test_dynamic_debug/parameters/$knob cat /sys/module/test_dynamic_debug/parameters/$knob } CLS_1="FOO -FOO +FOO -FOO BAR -BAR +BAR -BAR BUZZ -BUZZ +BUZZ -BUZZ" CLS_2=" Foo Bar Buzz -Foo -Bar -Buzz +Foo +Bar +Buzz -Foo -Bar -Buzz" CLS_3=" bing bong boom -bing -bong -boom +bing +bong +boom -bing -bong -boom" tddm_sysnode_classes__() { targ=$1 shift cls=$* for bitsym in $cls; do set_tddm_ $bitsym $targ done } # work all 3 sysfs bitmaps for sysnode in c1_syslog_bits c2_syslog_bits c3_syslog_bits; do for val in 0 1 2 4 8 0; do tddm_sysnode_classes__ $sysnode $val done done tddm_sysnode_classes__ c1_syslog_bits $CLS_1 tddm_sysnode_classes__ c2_syslog_bits $CLS_2 tddm_sysnode_classes__ c3_syslog_bits $CLS_3 echo "show unknown: c3-names on c1-knob" >&2 tddm_sysnode_classes__ c1_trace_bits $CLS_3 echo "flags look inverted" >&2 tddm_sysnode_classes__ c1_syslog_bits $CLS_1 CLS_1_=FOO,-FOO,+FOO,-FOO,BAR,-BAR,+BAR,-BAR,BUZZ,-BUZZ,+BUZZ,-BUZZ CLS_2_=Foo,Bar,Buzz,-Foo,-Bar,-Buzz,+Foo,+Bar,+Buzz,-Foo,-Bar,-Buzz # leading err doesnt wreck the rest CLS_3_=,bing,bong,boom,-bing,-bong,-boom,+bing,+bong,+boom,-bing,-bong,-boom tddm_sysnode_classes__ c1_syslog_bits $CLS_1_ tddm_sysnode_classes__ c2_syslog_bits $CLS_2_ tddm_sysnode_classes__ c3_syslog_bits $CLS_3_ Cc: Sean Paul <seanpaul(a)chromium.org> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: David Airlie <airlied(a)gmail.com> Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Pekka Paalanen <ppaalanen(a)gmail.com> Cc: Rob Clark <robdclark(a)gmail.com> Cc: Steven Rostedt <rostedt(a)goodmis.org> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Steven Rostedt <rostedt(a)goodmis.org> Jim Cromie (27): dyndbg: fix static_branch manipulation dyndbg: show both old and new in change-info dyndbg: fix module.dyndbg handling dyndbg: drop EXPORTed dynamic_debug_exec_queries dyndbg: add exclusive class_id to pr_debug callsites dyndbg: add dynamic_debug_(un)register_classes dyndbg: validate class FOO on module dyndbg: add drm.debug style bitmap support Doc/dyndbg: document new class class_name query support dyndbg: let query-modname override defaulting modname dyndbg: support symbolic class-names in bitmap dyndbg: change zero-or-one classes-map to maps list dyndbg: add __pr_debug_cls(class, fmt, ...) dyndbg: add test_dynamic_debug module drm: POC drm on dyndbg - map class-names to drm_debug_category's drm/print: POC drm on dyndbg - use bitmap drm_print: condense enum drm_debug_category drm_print: interpose drm_*dbg with forwarding macros drm_print: wrap drm_*_dbg in dyndbg descriptor factory macro drm_print: refine drm_debug_enabled for jump-label drm_print: prefer bare printk KERN_DEBUG on generic fn drm_print: add _ddebug desc to drm_*dbg prototypes dyndbg: add _DPRINTK_FLAGS_ENABLED dyndbg: add _DPRINTK_FLAGS_TRACE dyndbg: add write-events-to-tracefs code dyndbg: 4 new trace-events: pr_debug, dev_dbg, drm_{,dev}debug dyndbg/drm: POC add tracebits sysfs-knob .../admin-guide/dynamic-debug-howto.rst | 12 + MAINTAINERS | 1 + drivers/gpu/drm/Kconfig | 12 + drivers/gpu/drm/Makefile | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 + drivers/gpu/drm/drm_drv.c | 5 + drivers/gpu/drm/drm_print.c | 69 ++- drivers/gpu/drm/i915/i915_module.c | 11 + drivers/gpu/drm/nouveau/nouveau_drm.c | 4 + include/drm/drm_drv.h | 26 + include/drm/drm_print.h | 84 ++- include/linux/dynamic_debug.h | 136 ++++- include/trace/events/drm.h | 68 +++ include/trace/events/dyndbg.h | 74 +++ lib/Kconfig.debug | 11 + lib/Makefile | 1 + lib/dynamic_debug.c | 487 +++++++++++++++--- lib/test_dynamic_debug.c | 172 +++++++ 18 files changed, 1049 insertions(+), 129 deletions(-) create mode 100644 include/trace/events/drm.h create mode 100644 include/trace/events/dyndbg.h create mode 100644 lib/test_dynamic_debug.c -- 2.35.1

3 30

[RFC PATCH 0/1] drm/vkms: ConfigFS support
by Jim Shargo 08 Jun '22

08 Jun '22

Hi! I wanted to send this patch out early to get some feedback on the layout of the code and new ConfigFS directory. I intend to follow this up with a more complete patch set that uses this to, for instance, add more connectors and toggle feature support. A few questions I had as someone new to kernel dev: 1. Would you prefer laying out all the objects right now or add them as-needed? IMO it’s nice to lay things out now to make future work that much easier. 2. Is the layout of /config/vkms/<type>s/<id>/<attributes> OK? If VKMS would eventually want to support installing multiple devices, we could do something like /config/vkms/card<N>/<type>s/<id>/<attributes>. 3. Should I split out the documention into a separate change? 4. Any other style / design thoughts? Thanks! I am excited to be reaching out and contributing. Jim Shargo (1): drm/vkms: Add basic support for ConfigFS to VKMS Documentation/gpu/vkms.rst | 23 +++++ drivers/gpu/drm/Kconfig | 1 + drivers/gpu/drm/vkms/Makefile | 1 + drivers/gpu/drm/vkms/vkms_configfs.c | 129 +++++++++++++++++++++++++++ drivers/gpu/drm/vkms/vkms_drv.c | 10 +++ drivers/gpu/drm/vkms/vkms_drv.h | 25 ++++++ drivers/gpu/drm/vkms/vkms_output.c | 2 + drivers/gpu/drm/vkms/vkms_plane.c | 2 + 8 files changed, 193 insertions(+) create mode 100644 drivers/gpu/drm/vkms/vkms_configfs.c -- 2.36.0.512.ge40c2bad7a-goog

3 4

DRM Master ignoring hotplug event during display switching (QT)
by Jagan Teki 08 Jun '22

08 Jun '22

Hi all, I have implemented runtime display switching in the MIPI switch design where LVDS and HDMI bridges are selected with the help of runtime GPIO. Initial discussion on the same can be found here, https://www.spinics.net/lists/dri-devel/msg318524.html The implementation has been done by creating each connector at runtime. The default boot will create the LVDS connector and based on the HDMI plug-in the ISR. 1. forcing the LVDS to disconnect 2. call drm_kms_helper_hotplug_event 3. detach the bridge chain 4. attach the new bridge chain (HDMI) 5. call drm_kms_helper_hotplug_event do the reverse when we unplug the HDMI cable. So, the bridge chains are attached and detached based on GPIO Interrupt which is indeed identified based on the physical HDMIA connector. Pipeline for LVDS, mxfsb => nwl-dsi => display-switch => sn65dsi83=> panel-bridge Pipeline for HDMI, mxfsb => nwl-dsi => display-switch => adv7511 => display-connector With this, implementation and I can able switch the displays with default DRM (without specific DRM applications) where the LVDS is ON by default and when HDMI plug-in the LVDS OFF/HDMI ON, and when HDMI unplug the HDMI OFF/LVDS ON. However, with QT5 I can see the DRM Master ignoring hotplug event by returning 0 on drm_master_internal_acquire in drm_fb_helper_hotplug_event. With this the hotplug returned early so it cannot able to disconnect and connect the new switching connector. Any help? Thanks, Jagan.

4 11

[RESEND v5 0/3] MediaTek MT8195 display binding
by Bo-Chen Chen 08 Jun '22

08 Jun '22

Add this series to present MediaTek display binding for MT8195. The reason I send this series is Jason and Nancy's binding patches are never received by devicetree mail server. Therefore, I help them to resend binding patches. Changes for resend v5: 1. Fix binding check error in [1/3] and [3/3]. 2. v5 is not received by devicetree mail server, so I resend them. Changes for resend v4: 1. Rebase to v5.19-rc1 which iommu series is included. 2. Add my signed-off. 3. v4 is not received by devicetree mail server, add more cc and resend. 4. This patch is from Nancy's v22 series:[2]. [2]: https://patchwork.kernel.org/project/linux-mediatek/list/?series=645240 Changes for v3: 1. Fix rdma and ethdr binding doc. 2. Nancy's series: [1]. 3. This series is based on linux-next: next-20220511. Changes for v2: 1. This patch is based on linux next-20220506. 2. Jason's patches are accepted and I drop them. [1]: https://lore.kernel.org/all/20220512053128.31415-1-nancy.lin@mediatek.com/ Nancy.Lin (3): dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 dt-bindings: reset: mt8195: add vdosys1 reset control bit dt-bindings: mediatek: add ethdr definition for mt8195 .../display/mediatek/mediatek,ethdr.yaml | 188 ++++++++++++++++++ .../display/mediatek/mediatek,mdp-rdma.yaml | 88 ++++++++ include/dt-bindings/reset/mt8195-resets.h | 45 +++++ 3 files changed, 321 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml -- 2.18.0

3 5

[RFC PATCH 00/16] drm/rockchip: Rockchip EBC ("E-Book Controller") display driver
by Samuel Holland 08 Jun '22

08 Jun '22

This series adds a DRM driver for the electrophoretic display controller found in a few different Rockchip SoCs, specifically the RK3566/RK3568 variant[0] used by the PineNote tablet[1]. This is my first real involvement with the DRM subsystem, so please let me know where I am misunderstanding things. This is now the second SoC-integrated EPD controller with a DRM driver submission -- the first one being the i.MX6 EPDC[2]. I want to thank Andreas for sending that series, and for his advice while writing this driver. One goal I have with sending this series is to discuss how to support EPDs more generally within the DRM subsystem, so the interfaces with panels and PMICs and waveform LUTs can be controller-independent. My understanding is that the i.MX6 EPDC series is at least partly based on the downstream vendor driver. This driver is a clean-sheet design for hardware with different (read: fewer) capabilities, so we took some different design paths, but we ran into many of the same sharp edges. Here are some of the areas I would like input on: Panel Lifecycle =============== Panels use prepare/unprepare callbacks for their power supply. EPDs should only be powered up when the display contents are changed. Should the controller call both drm_panel_(un)prepare during each atomic update when the framebuffer is dirty? Similarly, panel enable/disable callbacks are tied to backlight state. For an EPD, it makes sense to have the backlight enabled while the panel is powered down (because the contents are static). Is it acceptable to call drm_panel_{en,dis}able while the panel is not prepared? With panel_bridge, the "normal" callback ordering is enforced, and tied to the atomic state, so neither of these is possible. As a result, neither the backlight nor the voltage regulators are tied to the panel. The panel's regulators are consumed by the EBC itself. Panel Timing Parameters ======================= EPDs have more timing parameters than LCDs, and there are several different ways of labeling these parameters. See for example the timing diagrams on pp. 2237-2239 of the RK3568 TRM[0], the descriptions in the ED103TC2 panel datasheet[3], and the submitted EPDC bindings[2]. Both the EPDC and EBC vendor drivers put all of the timing parameters in the controller's OF node. There is no panel device/node. I was able to squeeze everything needed for my specific case into a struct drm_display_mode (see patches 5 and 14), but I don't know if this is an acceptable use of those fields, or if will work with other controllers. Is adding more fields to drm_display_mode an option? See also the discussion of "dumb" LCD TCONs below. Panel Connector Type / Media Bus Format ======================================= The EBC supports either an 8-bit or 16-bit wide data bus, where each pair of data lines represents the source driver polarity (positive, negative, or neutral) for a pixel. The only effect of the data bus width is the number of pixels that are transferred per clock cycle. It has no impact on the number of possible grayscale levels. How does that translate to DRM_MODE_CONNECTOR_* or MEDIA_BUS_FMT_*? Panel Reflection ================ The ED103TC2 panel scans from right to left. Currently, there is no API or OF property to represent this. I can add something similar to drm_panel_orientation. Should this be exposed to userspace? It is acceptable for the kernel driver to flip the image when blitting from the framebuffer? CRTC "active" and "enabled" states ================================== What do these states mean in the context of an EPD? Currently, the driver ignores "active" and clears the screen to solid white when the CRTC is disabled. The vendor drivers can switch to a user-provided image when the CRTC is disabled. Is this something that can/should be supported upstream? If so, how? Would userspace provide the image to the kernel, or just tell the kernel not to clear the screen? VBLANK Events and Asynchronous Commits ====================================== When should the VBLANK event complete? When the pixels have been blitted to the kernel's shadow buffer? When the first frame of the waveform is sent to the panel? When the last frame is sent to the panel? Currently, the driver is taking the first option, letting drm_atomic_helper_fake_vblank() send the VBLANK event without waiting on the refresh thread. This is the only way I was able to get good performance with existing userspace. Waveform Loading ================ Waveform files are calibrated for each batch of panels. So while a single waveform file may be "good enough" for all panels of a certain model, the correctly-calibrated file will have better image quality. I don't know of a good way to choose the calibrated file. Even the board's compatible string may not be specific enough, if the board is manufactured with multiple batches of panels. Maybe the filename should just be the panel compatible, and the user is responsible for putting the right file there? In that case, how should I get the compatible string from the panel_bridge? Traverse the OF graph myself? There is also the issue that different controllers need the waveform data in different formats. ".wbf" appears to be the format provided by PVI/eInk, the panel manufacturer. The Rockchip EBC hardware expects a single waveform in a flat array, so the driver has to extract/decompress that from the .wbf file (this is done in patch 1). On the other hand, the i.MX EPDC expects a ".wrf" file containing multiple waveforms[8]. I propose that the waveform file on disk should always be what was shipped with the panel -- the .wbf file -- and any extracting or reformatting is done in the kernel. Waveform Selection From Userspace ================================= EPDs use different waveforms for different purposes: high-quality grayscale vs. monochrome text vs. dithered monochrome video. How can userspace select which waveform to use? Should this be a plane property? It is also likely that userspace will want to use different waveforms at the same time for different parts of the screen, for example a fast monochrome waveform for the drawing area of a note-taking app, but a grayscale waveform for surrounding UI and window manager. I believe the i.MX6 EPDC supports multiple planes, each with their own waveform choice. That seems like a good abstraction, but the EBC only supports one plane in hardware. So using this abstraction with the EBC would require blending pixels and doing waveform lookups in software. Blitting/Blending in Software ============================= There are multiple layers to this topic (pun slightly intended): 1) Today's userspace does not expect a grayscale framebuffer. Currently, the driver advertises XRGB8888 and converts to Y4 in software. This seems to match other drivers (e.g. repaper). 2) Ignoring what userspace "wants", the closest existing format is DRM_FORMAT_R8. Geert sent a series[4] adding DRM_FORMAT_R1 through DRM_FORMAT_R4 (patch 9), which I believe are the "correct" formats to use. 3) The RK356x SoCs have an "RGA" hardware block that can do the RGB-to-grayscale conversion, and also RGB-to-dithered-monochrome which is needed for animation/video. Currently this is exposed with a V4L2 platform driver. Can this be inserted into the pipeline in a way that is transparent to userspace? Or must some userspace library be responsible for setting up the RGA => EBC pipeline? 4) Supporting multiple planes (for multiple concurrent waveforms) implies blending in software. Is that acceptable? 5) Thoughts on SIMD-optimized blitting and waveform lookup functions? 5) Currently the driver uses kmalloc() and dma_sync_single_for_device() for its buffers, because it needs both fast reads and fast writes to several of them. Maybe cma_alloc() or dma_alloc_from_contiguous() would be more appropriate, but I don't see any drivers using those directly. EPDs connected to "dumb" LCD TCONs ================================== This topic is mostly related to my first patch. Some boards exist that hook up an EPD to a normal LCD TCON, not a dedicated EPD controller. For example, there's the reMarkable 2[5] and some PocketBook models[6][7]. I have some concerns about this: 1) If we put EPD panel timings in panel drivers (e.g. panel-simple), can the same timings work with LCD TCONs and EPD controllers? For example: one cycle of the 16-bit data bus is "one pixel" to an LCD controller, but is "8 pixels" to an EPD controller. So there is a factor-of-8 difference in horizontal resolution depending on your perspective. Should we have the "number of pixel clock cycles" or "number of pixels" in .hdisplay/.htotal in the panel timings? Patch 14 adds a panel with "number of pixels" horizontal resolution, so the correct resolution is reported to userspace, but the existing eink_vb3300_kca_timing in panel-simple.c appears to use "number of pixel clocks" for its horizontal resolution. This makes the panel timing definitions incompatible across controllers. 2) Using fbdev/fbcon with an EPD hooked up to an LCD TCON will have unintended consequences, and possibly damage the panel. Currently, there is no way to mark the framebuffer as expecting "source driver polarity waveforms" and not pixel data. Is there a specific DRM_FORMAT_* we should use for these cases to prevent accidental use by userspace? Or should we disallow this entirely, and have some wrapper layer to do the waveform lookups in kernelspace? I like the wrapper layer idea because it allows normal userspace and fbcon to work. It would not be much new code, especially since this driver already supports doing the whole pipeline in software. So that's why I wrote a separate helper library; I hope this code can be reused. Thanks for any input! Samuel [0]: https://dl.radxa.com/rock3/docs/hw/datasheet/Rockchip%20RK3568%20TRM%20Part… [1]: https://wiki.pine64.org/wiki/PineNote [2]: https://lore.kernel.org/lkml/20220206080016.796556-1-andreas@kemnade.info/T/ [3]: https://files.pine64.org/doc/quartz64/Eink%20P-511-828-V1_ED103TC2%20Formal… [4]: https://lore.kernel.org/lkml/cover.1646683502.git.geert@linux-m68k.org/T/ [5]: https://lore.kernel.org/lkml/20220330094126.30252-1-alistair@alistair23.me/… [6]: https://github.com/megous/linux/commits/pb-5.17 [7]: https://github.com/megous/linux/commit/3cdf84388959 [8]: https://github.com/fread-ink/inkwave Samuel Holland (16): drm: Add a helper library for EPD drivers dt-bindings: display: rockchip: Add EBC binding drm/rockchip: Add EBC platform driver skeleton drm/rockchip: ebc: Add DRM driver skeleton drm/rockchip: ebc: Add CRTC mode setting drm/rockchip: ebc: Add CRTC refresh thread drm/rockchip: ebc: Add CRTC buffer management drm/rockchip: ebc: Add LUT loading drm/rockchip: ebc: Implement global refreshes drm/rockchip: ebc: Implement partial refreshes drm/rockchip: ebc: Enable diff mode for partial refreshes drm/rockchip: ebc: Add support for direct mode drm/rockchip: ebc: Add a panel reflection option drm/panel-simple: Add eInk ED103TC2 arm64: dts: rockchip: rk356x: Add EBC node [DO NOT MERGE] arm64: dts: rockchip: pinenote: Enable EBC display pipeline .../display/rockchip/rockchip,rk3568-ebc.yaml | 106 ++ .../boot/dts/rockchip/rk3566-pinenote.dtsi | 80 + arch/arm64/boot/dts/rockchip/rk356x.dtsi | 14 + drivers/gpu/drm/Kconfig | 6 + drivers/gpu/drm/Makefile | 4 +- drivers/gpu/drm/drm_epd_helper.c | 663 +++++++ drivers/gpu/drm/panel/panel-simple.c | 31 + drivers/gpu/drm/rockchip/Kconfig | 12 + drivers/gpu/drm/rockchip/Makefile | 2 + drivers/gpu/drm/rockchip/rockchip_ebc.c | 1586 +++++++++++++++++ include/drm/drm_epd_helper.h | 104 ++ 11 files changed, 2607 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip,rk3568-ebc.yaml create mode 100644 drivers/gpu/drm/drm_epd_helper.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_ebc.c create mode 100644 include/drm/drm_epd_helper.h -- 2.35.1

5 27

[PATCH v4] dma-buf: Add a capabilities directory
by Simon Ser 08 Jun '22

08 Jun '22

To discover support for new DMA-BUF IOCTLs, user-space has no choice but to try to perform the IOCTL on an existing DMA-BUF. However, user-space may want to figure out whether or not the IOCTL is available before it has a DMA-BUF at hand, e.g. at initialization time in a Wayland compositor. Add a /sys/kernel/dmabuf/caps directory which allows the DMA-BUF subsystem to advertise supported features. Add a sync_file_import_export entry which indicates that importing and exporting sync_files from/to DMA-BUFs is supported. v2: Add missing files lost in a rebase v3: - Create separate file in Documentation/ABI/testing/, add it to MAINTAINERS - Fix kernel version (Daniel) - Remove unnecessary brackets (Jason) - Fix SPDX comment style v4: improve sysfs code (Greg) Signed-off-by: Simon Ser <contact(a)emersion.fr> Reviewed-by: Jason Ekstrand <jason.ekstrand(a)collabora.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Bas Nieuwenhuizen <bas(a)basnieuwenhuizen.nl> Cc: Christian König <christian.koenig(a)amd.com> Cc: Greg KH <greg(a)kroah.com> --- .../ABI/testing/sysfs-kernel-dmabuf-caps | 13 ++++++ MAINTAINERS | 1 + drivers/dma-buf/Makefile | 2 +- drivers/dma-buf/dma-buf-sysfs-caps.c | 31 +++++++++++++ drivers/dma-buf/dma-buf-sysfs-caps.h | 15 +++++++ drivers/dma-buf/dma-buf-sysfs-stats.c | 16 ++----- drivers/dma-buf/dma-buf-sysfs-stats.h | 6 ++- drivers/dma-buf/dma-buf.c | 45 +++++++++++++++++-- include/uapi/linux/dma-buf.h | 6 +++ 9 files changed, 115 insertions(+), 20 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-kernel-dmabuf-caps create mode 100644 drivers/dma-buf/dma-buf-sysfs-caps.c create mode 100644 drivers/dma-buf/dma-buf-sysfs-caps.h diff --git a/Documentation/ABI/testing/sysfs-kernel-dmabuf-caps b/Documentation/ABI/testing/sysfs-kernel-dmabuf-caps new file mode 100644 index 000000000000..f83af422fd18 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-dmabuf-caps @@ -0,0 +1,13 @@ +What: /sys/kernel/dmabuf/caps +Date: May 2022 +KernelVersion: v5.20 +Contact: Simon Ser <contact(a)emersion.fr> +Description: This directory advertises DMA-BUF capabilities supported by the + kernel. + +What: /sys/kernel/dmabuf/caps/sync_file_import_export +Date: May 2022 +KernelVersion: v5.20 +Contact: Simon Ser <contact(a)emersion.fr> +Description: This file is read-only and advertises support for importing and + exporting sync_files from/to DMA-BUFs. diff --git a/MAINTAINERS b/MAINTAINERS index 11da16bfa123..8966686f7231 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5871,6 +5871,7 @@ L: dri-devel(a)lists.freedesktop.org L: linaro-mm-sig(a)lists.linaro.org (moderated for non-subscribers) S: Maintained T: git git://anongit.freedesktop.org/drm/drm-misc +F: Documentation/ABI/testing/sysfs-kernel-dmabuf-caps F: Documentation/driver-api/dma-buf.rst F: drivers/dma-buf/ F: include/linux/*fence.h diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile index 4c9eb53ba3f8..afc874272710 100644 --- a/drivers/dma-buf/Makefile +++ b/drivers/dma-buf/Makefile @@ -1,6 +1,6 @@ # SPDX-License-Identifier: GPL-2.0-only obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \ - dma-resv.o + dma-resv.o dma-buf-sysfs-caps.o obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o obj-$(CONFIG_DMABUF_HEAPS) += heaps/ obj-$(CONFIG_SYNC_FILE) += sync_file.o diff --git a/drivers/dma-buf/dma-buf-sysfs-caps.c b/drivers/dma-buf/dma-buf-sysfs-caps.c new file mode 100644 index 000000000000..6eb27b81469f --- /dev/null +++ b/drivers/dma-buf/dma-buf-sysfs-caps.c @@ -0,0 +1,31 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * DMA-BUF sysfs capabilities. + * + * Copyright (C) 2022 Simon Ser + */ + +#include <linux/kobject.h> +#include <linux/sysfs.h> + +#include "dma-buf-sysfs-caps.h" + +static ssize_t sync_file_import_export_show(struct kobject *kobj, + struct kobj_attribute *attr, + char *buf) +{ + return sysfs_emit(buf, "1\n"); +} + +static struct kobj_attribute dma_buf_sync_file_import_export_attr = + __ATTR_RO(sync_file_import_export); + +static struct attribute *dma_buf_caps_attrs[] = { + &dma_buf_sync_file_import_export_attr.attr, + NULL, +}; + +const struct attribute_group dma_buf_caps_group = { + .name = "caps", + .attrs = dma_buf_caps_attrs, +}; diff --git a/drivers/dma-buf/dma-buf-sysfs-caps.h b/drivers/dma-buf/dma-buf-sysfs-caps.h new file mode 100644 index 000000000000..e40a93513f06 --- /dev/null +++ b/drivers/dma-buf/dma-buf-sysfs-caps.h @@ -0,0 +1,15 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * DMA-BUF sysfs capabilities. + * + * Copyright (C) 2022 Simon Ser + */ + +#ifndef _DMA_BUF_SYSFS_CAPS_H +#define _DMA_BUF_SYSFS_CAPS_H + +struct attribute_group; + +extern const struct attribute_group dma_buf_caps_group; + +#endif // _DMA_BUF_SYSFS_CAPS_H diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.c b/drivers/dma-buf/dma-buf-sysfs-stats.c index 2bba0babcb62..e2e62f83ce18 100644 --- a/drivers/dma-buf/dma-buf-sysfs-stats.c +++ b/drivers/dma-buf/dma-buf-sysfs-stats.c @@ -141,23 +141,14 @@ static const struct kset_uevent_ops dmabuf_sysfs_no_uevent_ops = { .filter = dmabuf_sysfs_uevent_filter, }; -static struct kset *dma_buf_stats_kset; static struct kset *dma_buf_per_buffer_stats_kset; -int dma_buf_init_sysfs_statistics(void) +int dma_buf_init_sysfs_statistics(struct kset *kset) { - dma_buf_stats_kset = kset_create_and_add("dmabuf", - &dmabuf_sysfs_no_uevent_ops, - kernel_kobj); - if (!dma_buf_stats_kset) - return -ENOMEM; - dma_buf_per_buffer_stats_kset = kset_create_and_add("buffers", &dmabuf_sysfs_no_uevent_ops, - &dma_buf_stats_kset->kobj); - if (!dma_buf_per_buffer_stats_kset) { - kset_unregister(dma_buf_stats_kset); + &kset->kobj); + if (!dma_buf_per_buffer_stats_kset) return -ENOMEM; - } return 0; } @@ -165,7 +156,6 @@ int dma_buf_init_sysfs_statistics(void) void dma_buf_uninit_sysfs_statistics(void) { kset_unregister(dma_buf_per_buffer_stats_kset); - kset_unregister(dma_buf_stats_kset); } int dma_buf_stats_setup(struct dma_buf *dmabuf) diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.h b/drivers/dma-buf/dma-buf-sysfs-stats.h index a49c6e2650cc..798c54fb8ee3 100644 --- a/drivers/dma-buf/dma-buf-sysfs-stats.h +++ b/drivers/dma-buf/dma-buf-sysfs-stats.h @@ -8,9 +8,11 @@ #ifndef _DMA_BUF_SYSFS_STATS_H #define _DMA_BUF_SYSFS_STATS_H +struct kset; + #ifdef CONFIG_DMABUF_SYSFS_STATS -int dma_buf_init_sysfs_statistics(void); +int dma_buf_init_sysfs_statistics(struct kset *kset); void dma_buf_uninit_sysfs_statistics(void); int dma_buf_stats_setup(struct dma_buf *dmabuf); @@ -18,7 +20,7 @@ int dma_buf_stats_setup(struct dma_buf *dmabuf); void dma_buf_stats_teardown(struct dma_buf *dmabuf); #else -static inline int dma_buf_init_sysfs_statistics(void) +static inline int dma_buf_init_sysfs_statistics(struct kset *kset) { return 0; } diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 5e1b0534b3ce..61c5be57558e 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -30,6 +30,7 @@ #include <uapi/linux/dma-buf.h> #include <uapi/linux/magic.h> +#include "dma-buf-sysfs-caps.h" #include "dma-buf-sysfs-stats.h" static inline int is_dma_buf_file(struct file *); @@ -1546,22 +1547,57 @@ static inline void dma_buf_uninit_debugfs(void) } #endif +/* Capabilities and statistics files do not need to send uevents. */ +static int dmabuf_sysfs_uevent_filter(struct kobject *kobj) +{ + return 0; +} + +static const struct kset_uevent_ops dmabuf_sysfs_no_uevent_ops = { + .filter = dmabuf_sysfs_uevent_filter, +}; + +static const struct attribute_group *dma_buf_sysfs_groups[] = { + &dma_buf_caps_group, + NULL, +}; + +static struct kset *dma_buf_kset; + static int __init dma_buf_init(void) { int ret; - ret = dma_buf_init_sysfs_statistics(); + dma_buf_kset = kset_create_and_add("dmabuf", + &dmabuf_sysfs_no_uevent_ops, + kernel_kobj); + if (!dma_buf_kset) + return -ENOMEM; + + ret = sysfs_create_groups(&dma_buf_kset->kobj, dma_buf_sysfs_groups); if (ret) - return ret; + goto err_kset; + + ret = dma_buf_init_sysfs_statistics(dma_buf_kset); + if (ret) + goto err_kset; dma_buf_mnt = kern_mount(&dma_buf_fs_type); - if (IS_ERR(dma_buf_mnt)) - return PTR_ERR(dma_buf_mnt); + if (IS_ERR(dma_buf_mnt)) { + ret = PTR_ERR(dma_buf_mnt); + goto err_sysfs_stats; + } mutex_init(&db_list.lock); INIT_LIST_HEAD(&db_list.head); dma_buf_init_debugfs(); return 0; + +err_sysfs_stats: + dma_buf_uninit_sysfs_statistics(); +err_kset: + kset_unregister(dma_buf_kset); + return ret; } subsys_initcall(dma_buf_init); @@ -1570,5 +1606,6 @@ static void __exit dma_buf_deinit(void) dma_buf_uninit_debugfs(); kern_unmount(dma_buf_mnt); dma_buf_uninit_sysfs_statistics(); + kset_unregister(dma_buf_kset); } __exitcall(dma_buf_deinit); diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h index 70e213a0d7d9..ab3afd5da75a 100644 --- a/include/uapi/linux/dma-buf.h +++ b/include/uapi/linux/dma-buf.h @@ -114,6 +114,9 @@ struct dma_buf_sync { * ordering via these fences, it is the respnosibility of userspace to use * locks or other mechanisms to ensure that no other context adds fences or * submits work between steps 1 and 3 above. + * + * Userspace can check the availability of this API via + * /sys/kernel/dmabuf/caps/sync_file_import_export. */ struct dma_buf_export_sync_file { /** @@ -146,6 +149,9 @@ struct dma_buf_export_sync_file { * synchronized APIs such as Vulkan to inter-op with dma-buf consumers * which expect implicit synchronization such as OpenGL or most media * drivers/video. + * + * Userspace can check the availability of this API via + * /sys/kernel/dmabuf/caps/sync_file_import_export. */ struct dma_buf_import_sync_file { /** -- 2.36.1

7 15

← Newer
1
...
48
49
50
51
52
53
54
...
70
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2022