dri-devel August 2021

dri-devel@lists.freedesktop.org

324 participants
762 discussions

[BISECTED] 5.14.0-rc4 broke drm/ttm when !CONFIG_DEBUG_FS
by Mikael Pettersson 03 Aug '21

03 Aug '21

Booting 5.14.0-rc4 on my box with Radeon graphics breaks with [drm:radeon_ttm_init [radeon]] *ERROR* failed initializing buffer object driver(-19). radeon 0000:01:00.0: Fatal error during GPU init after which the screen goes black for the rest of kernel boot and early user-space init. Once the console login shows up the screen is in some legacy low-res mode and Xorg can't be started. A git bisect between v5.14-rc3 (good) and v5.14-rc4 (bad) identified # first bad commit: [69de4421bb4c103ef42a32bafc596e23918c106f] drm/ttm: Initialize debugfs from ttm_global_init() Reverting that from 5.14.0-rc4 gives me a working kernel again. Note that I have # CONFIG_DEBUG_FS is not set /Mikael

2 2

[PATCH 0/9] remove rcu support from i915_address_space
by Daniel Vetter 03 Aug '21

03 Aug '21

Hi all, Jason wanted to do that as part of the scheduler series, but I object since rcu is very, very hard to review when adding, and much, much harder even to review when removing. This is because simply looking for __rcu pointer annotations and rcu functions isn't enough, rcu is also relied upon in many datastructures which have internally and rcu_read_lock protection (or at least the required amount of barriers), like xarray. The other problem is that it inherits when chasing pointers, e.g. i915_gem_engines has an rcu pointer to intel_context, which has a non-rcu pointer to i915_address_space. But since we could look-up the entire chain under rcu i.e. engines->context[i]->vm this means more code to audit. The audit explodes pretty quickly. Anyway I'm reasonable confident I got them all in the current code, and slightly less confident that I managed to stitch together the full history. References to relevant commits throughout the series. Cheers, Daniel Daniel Vetter (9): drm/i915: Drop code to handle set-vm races from execbuf drm/i915: Rename i915_gem_context_get_vm_rcu to i915_gem_context_get_eb_vm drm/i915: Use i915_gem_context_get_eb_vm in ctx_getparam drm/i915: Add i915_gem_context_is_full_ppgtt drm/i915: Use i915_gem_context_get_eb_vm in intel_context_set_gem drm/i915: Drop __rcu from gem_context->vm drm/i915: use xa_lock/unlock for fpriv->vm_xa lookups drm/i915: Stop rcu support for i915_address_space drm/i915: Split out intel_context_create_user drivers/gpu/drm/i915/gem/i915_gem_context.c | 82 ++++--------------- drivers/gpu/drm/i915/gem/i915_gem_context.h | 13 ++- .../gpu/drm/i915/gem/i915_gem_context_types.h | 2 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 12 ++- .../gpu/drm/i915/gem/selftests/huge_pages.c | 8 +- .../drm/i915/gem/selftests/i915_gem_context.c | 32 +++----- .../gpu/drm/i915/gem/selftests/mock_context.c | 2 +- drivers/gpu/drm/i915/gt/intel_context.c | 22 ++++- drivers/gpu/drm/i915/gt/intel_context.h | 2 + drivers/gpu/drm/i915/gt/intel_ggtt.c | 1 - drivers/gpu/drm/i915/gt/intel_gtt.c | 6 +- drivers/gpu/drm/i915/gt/intel_gtt.h | 2 +- drivers/gpu/drm/i915/gt/selftest_execlists.c | 2 +- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 4 +- drivers/gpu/drm/i915/i915_trace.h | 2 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +- drivers/gpu/drm/i915/selftests/i915_vma.c | 4 +- 18 files changed, 79 insertions(+), 123 deletions(-) -- 2.32.0

2 10

[PATCH v3] drm/mediatek: clear pending flag when cmdq packet is done
by Yongqiang Niu 02 Aug '21

02 Aug '21

Change since v2: rebase https://patchwork.kernel.org/project/linux-mediatek/cover/20210712235014.42… Yongqiang Niu (1): drm/mediatek: clear pending flag when cmdq packet is done. drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 51 +++++++++++++++++++++++++++++---- 1 file changed, 46 insertions(+), 5 deletions(-) -- 1.8.1.1.dirty

2 2

[PATCH v5] drm/mediatek: add dither 6 setting
by Yongqiang Niu 02 Aug '21

02 Aug '21

Change since v4: - change commit message Yongqiang Niu (1): Fixes: a6b7c98afdca(drm/mediatek: add mtk_dither_set_common() function) drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 ++ 1 file changed, 2 insertions(+) -- 1.8.1.1.dirty

2 2

[PATCH 1/9] dt-bindings: phy: mediatek: tphy: support type switch by pericfg
by Chunfeng Yun 02 Aug '21

02 Aug '21

Add support type switch by pericfg register between USB3, PCIe, SATA, SGMII, this is used to replace the way through efuse or jumper. Signed-off-by: Chunfeng Yun <chunfeng.yun(a)mediatek.com> --- .../devicetree/bindings/phy/mediatek,tphy.yaml | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml index 838852cb8527..9e6c0f43f1c6 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml @@ -201,6 +201,22 @@ patternProperties: Specify the flag to enable BC1.2 if support it type: boolean + mediatek,syscon-type: + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + description: + A phandle to syscon used to access the register of type switch, + the field should always be 3 cells long. + items: + items: + - description: + The first cell represents a phandle to syscon + - description: + The second cell represents the register offset + - description: + The third cell represents the index of config segment + enum: [0, 1, 2, 3] + required: - reg - "#phy-cells" -- 2.18.0

3 12

[PATCH 0/3] drm/amdgpu: modernize virtual display feature
by Ryan Taylor 02 Aug '21

02 Aug '21

The amdgpu vkms interface provides a virtual KMS interface for several use cases: devices without display hardware, platforms where the actual display hardware is not useful (e.g., servers), SR-IOV virtual functions, device emulation/simulation, and device bring up prior to display hardware being usable. We previously emulated a legacy KMS interface, but there was a desire to move to the atomic KMS interface. The vkms driver did everything we needed, but we wanted KMS support natively in the driver without buffer sharing and the ability to support an instance of VKMS per device. We first looked at splitting vkms into a stub driver and a helper module that other drivers could use to implement a virtual display, but this strategy ended up being messy due to driver specific callbacks needed for buffer management. Ultimately, it proved easier to import the vkms code as it mostly used core drm helpers anyway. Ryan Taylor (3): drm/amdgpu: create amdgpu_vkms (v4) drm/amdgpu: cleanup dce_virtual drm/amdgpu: replace dce_virtual with amdgpu_vkms (v3) drivers/gpu/drm/amd/amdgpu/Makefile | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 641 +++++++++++++++++++ drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.h | 26 + drivers/gpu/drm/amd/amdgpu/cik.c | 10 +- drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 780 ----------------------- drivers/gpu/drm/amd/amdgpu/dce_virtual.h | 30 - drivers/gpu/drm/amd/amdgpu/nv.c | 22 +- drivers/gpu/drm/amd/amdgpu/si.c | 8 +- drivers/gpu/drm/amd/amdgpu/soc15.c | 10 +- drivers/gpu/drm/amd/amdgpu/vi.c | 14 +- 13 files changed, 703 insertions(+), 845 deletions(-) create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.h delete mode 100644 drivers/gpu/drm/amd/amdgpu/dce_virtual.c delete mode 100644 drivers/gpu/drm/amd/amdgpu/dce_virtual.h base-commit: e0186426a7efeb506164da7d4a56cfdaea38b380 -- 2.32.0

2 4

[PATCH] gpu/drm/amd: Remove duplicated include of drm_drv.h
by zhouchuangao 02 Aug '21

02 Aug '21

Duplicate include header file <drm/drm_drv.h> line 28: #include <drm/drm_drv.h> line 44: #include <drm/drm_drv.h> Signed-off-by: zhouchuangao <zhouchuangao(a)vivo.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c index 3ec5099..05f864f 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c @@ -41,8 +41,6 @@ #include "amdgpu_securedisplay.h" #include "amdgpu_atomfirmware.h" -#include <drm/drm_drv.h> - static int psp_sysfs_init(struct amdgpu_device *adev); static void psp_sysfs_fini(struct amdgpu_device *adev); -- 2.7.4

2 1

[PATCH v4 0/7] drm: use dyndbg in drm_print
by Jim Cromie 02 Aug '21

02 Aug '21

hi all, Apologies for broad --to, but it touches a wide range, if casually. In order to avoid runtime costs of drm_debug_enabled(), this patchset re-implements drm.debug to use dyndbg, after extending dyndbg with kernel_param_ops to implement the bitmap->dydnbg-query and expose it for use. To define your pr_debugs categorization (that you want to control): DEFINE_DYNDBG_BITMAP(debug_gvt, __gvt_debug, "i915/gvt dyndbg bitmap desc", /* bits 0-N are initialized with these exprs */ { "gvt:cmd: ", "command processing" }, { "gvt:core: ", "core help" }, { "gvt:dpy: ", "display help" }, { "gvt:el: ", "help" }, { "gvt:irq: ", "help" }, { "gvt:mm: ", "help" }, { "gvt:mmio: ", "help" }, { "gvt:render: ", "help" }, { "gvt:sched: ", "help" }); Then, you can change whole categories of pr_debugs: echo 0x5A > /sys/modules/i915/parameters/debug_gvt BIT($i++) is implied by order, can it be autogend with macros and stuffed into MODULE_PARAM_DESC automagically ? v4: - extend kernel_param with void* .data (2/7) - move v3 kernel_param_ops code into dyndbg (3/7) - add DEFINE_DYNDBG_BITMAP (3/7) - use DEFINE_DYNDBG_BITMAP in drm-core, i915 (5/7), amdgpu (7/7) - lots of changes per @DanVet feedback, thanks! no doc yet, content more in commit-log refinements v3: https://lore.kernel.org/lkml/20210714175138.319514-1-jim.cromie@gmail.com/ main element is now patch 6/7, v2: https://lore.kernel.org/lkml/20210711055003.528167-1-jim.cromie@gmail.com/ v1: https://lore.kernel.org/lkml/20201204035318.332419-1-jim.cromie@gmail.com/ NOTES: https://github.com/jimc/linux/tree/dd-drm-v4 should be seen and tested by robots soon. Using dyndbg to implement categories/classes of pr_debugs requires that the class-prefix is compiled into the format string, and not written at runtime with pr_debug("%s %pV", class_str, vaf). That caveat is reflected in (6/7) where category is catenated with the format, and ceases to exist as a separate arg for DRM_USE_DD=y builds. ISTM this also means drm_debug_enabled() isnt going away just yet. The categories arent atomic in any sense; callsites controlled via drm.debug can still be tweaked arbitrarily with echo $query > control. dyndbg's search is global by default; format ^$prefix cuts across code modules, and anyone can add a pr_debug("drm:foobar: yada") classification. Rules against this are policy, and belong in the realm of author taste and code review, not in the tool. Maybe modname's already available via kp, if we need it. Other query terms are possible, if struct dyndbg_bitdesc is elaborated. The dyndbg-queries built by the callback don't include modname. This allows drm.dbg to control pr-debugs inside i915, despite being done from a different module. This is ok because i915 used the drm_debug api for those messages. i915/gvt uses a different way to prepend its classes, but it shares the classification space. Like a good namespace citizen, it has "gvt:" as its top-level name, with ~9 2nd level names. sean(a)chromium.org posited "drm:atomic:fail: " as a new category, to leverage the additional selectivity of dyndbg. Allowing for N-level namespaces, ' ' terminates the prefix, not ':'. So "drm:atomic:" & "drm:atomic: " are different searches, 1st including pr_debug("drm:atomic:fail: ") DEFINE_DYNDBG_BITMAP() bits and masks are dependent on order of bit-declarations. Since bits are applied 0-N, later bits could override (ie sub-categorize) earlier ones. IOW, "drm:atomic:fail: " just needs to be after "drm:atomic: ". dyndbg is extremely agnostic about how you use format ^$prefix, your classification scheme just needs to work within the limitation that its a simple anchored literal substring match, no regex stuff. In particular, commit 578b1e0701af ("dynamic_debug: add wildcard support to filter files/functions/modules") left format out, because it was already special (floating substr match, no need for '*'). Patch 6/7 has many more "advices" on classification / categorization. and im restating things. Much more to say/do instead of what follows, which is v3 prose. I wanted to send, see how its received by robots and people. drm_debug_enabled() is called a lot to do unlikely bit-tests to selectively enable debug printing; this is a good job for dynamic-debug, IFF it is built with JUMP_LABEL. This patchset enables the use of dynamic-debug to avoid all those drm_debug_enabled() overheads, if CONFIG_DRM_USE_DYNAMIC_DEBUG=y. Doing so creates many new pr_debug callsites, otherwise i915 has ~120 prdbgs, and drm has just 1; bash-5.1# modprobe i915 dyndbg: 8 debug prints in module video dyndbg: 305 debug prints in module drm dyndbg: 207 debug prints in module drm_kms_helper dyndbg: 2 debug prints in module ttm dyndbg: 1720 debug prints in module i915 On amdgpu, enabling it adds ~3200 prdbgs, currently at 56 bytes each. So CONFIG_DRM_USE_DYNAMIC_DEBUG=y affects resource requirements. Im running this patchset bare-metal on an i915 laptop & an amdgpu desktop (both as loadable modules). I booted the amdgpu box with: BOOT_IMAGE=(hd2,gpt2)/vmlinuz-5.13.0-dd7-13692-g8def25788f56 \ root=UUID=mumble ro \ rootflags=subvol=root00 rhgb \ dynamic_debug.verbose=3 main.dyndbg=+p \ amdgpu.debug=1 amdgpu.test=1 \ "amdgpu.dyndbg=format ^[ +p" That last line enables ~1700 prdbg callsites with a format like '[DML' etc at boot, and amdgpu.test=1 triggers 3 minutes of tests, causing ~76k prdbgs in 409 seconds, before I turned them off with: echo module amdgpu -p > /proc/dynamic_debug/control This is on top of master @ v5.14-rc3. Jim Cromie (7): drm/print: fixup spelling in a comment (already in drm-mumble) moduleparam: add data member to struct kernel_param dyndbg: add dyndbg-bitmap definer and callbacks i915/gvt: remove spaces in pr_debug "gvt: core:" etc prefixes i915/gvt: control pr_debug("gvt:")s with bits in parameters/debug_gvt drm/print: add choice to use dynamic debug in drm-debug amdgpu: define a dydbg-bitmap to control categorized pr_debugs drivers/gpu/drm/Kconfig | 13 +++ .../gpu/drm/amd/display/dc/core/dc_debug.c | 42 +++++++- drivers/gpu/drm/drm_print.c | 15 ++- drivers/gpu/drm/i915/gvt/Makefile | 4 + drivers/gpu/drm/i915/gvt/debug.h | 18 ++-- drivers/gpu/drm/i915/i915_params.c | 34 +++++++ include/drm/drm_print.h | 99 ++++++++++++++----- include/linux/dynamic_debug.h | 36 +++++++ include/linux/moduleparam.h | 11 ++- lib/dynamic_debug.c | 55 +++++++++++ 10 files changed, 284 insertions(+), 43 deletions(-) -- 2.31.1

3 12

Re: [PATCH 42/64] net: qede: Use memset_after() for counters
by Kees Cook 02 Aug '21

02 Aug '21

On Mon, Aug 02, 2021 at 02:29:28PM +0000, Shai Malin wrote: > > On Tue, Jul 31, 2021 at 07:07:00PM -0300, Kees Cook wrote: > > On Tue, Jul 27, 2021 at 01:58:33PM -0700, Kees Cook wrote: > > > In preparation for FORTIFY_SOURCE performing compile-time and run-time > > > field bounds checking for memset(), avoid intentionally writing across > > > neighboring fields. > > > > > > Use memset_after() so memset() doesn't get confused about writing > > > beyond the destination member that is intended to be the starting point > > > of zeroing through the end of the struct. > > > > > > Signed-off-by: Kees Cook <keescook(a)chromium.org> > > > --- > > > The old code seems to be doing the wrong thing: starting from not the > > > first member, but sized for the whole struct. Which is correct? > > > > Quick ping on this question. > > > > The old code seems to be doing the wrong thing: it starts from the second > > member and writes beyond int_info, clobbering qede_lock: > > Thanks for highlighting the problem, but actually, the memset is redundant. > We will remove it so the change will not be needed. > > > > > struct qede_dev { > > ... > > struct qed_int_info int_info; > > > > /* Smaller private variant of the RTNL lock */ > > struct mutex qede_lock; > > ... > > > > > > struct qed_int_info { > > struct msix_entry *msix; > > u8 msix_cnt; > > > > /* This should be updated by the protocol driver */ > > u8 used_cnt; > > }; > > > > Should this also clear the "msix" member, or should this not write > > beyond int_info? This patch does the latter. > > It should clear only the msix_cnt, no need to clear the entire > qed_int_info structure. Should used_cnt be cleared too? It is currently. Better yet, what patch do you suggest I replace this proposed one with? :) Thanks for looking at this! -Kees -- Kees Cook

1 0

[PATCH] drm/msm/dp: update is_connected status base on sink count at dp_pm_resume()
by Kuogee Hsieh 02 Aug '21

02 Aug '21

Currently at dp_pm_resume() is_connected state is decided base on hpd connection status only. This will put is_connected in wrongly "true" state at the scenario that dongle attached to DUT but without hmdi cable connecting to it. Fix this problem by adding read sink count from dongle and decided is_connected state base on both sink count and hpd connection status. Signed-off-by: Kuogee Hsieh <khsieh(a)codeaurora.org> --- drivers/gpu/drm/msm/dp/dp_display.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c index 2b660e9..9bcb261 100644 --- a/drivers/gpu/drm/msm/dp/dp_display.c +++ b/drivers/gpu/drm/msm/dp/dp_display.c @@ -1308,6 +1308,17 @@ static int dp_display_remove(struct platform_device *pdev) return 0; } +static int dp_get_sink_count(struct dp_display_private *dp) +{ + u8 sink_count; + + sink_count = drm_dp_read_sink_count(dp->aux); + if (sink_count < 0) + return 0; + + return sink_count; +} + static int dp_pm_resume(struct device *dev) { struct platform_device *pdev = to_platform_device(dev); @@ -1327,14 +1338,22 @@ static int dp_pm_resume(struct device *dev) dp_catalog_ctrl_hpd_config(dp->catalog); - status = dp_catalog_link_is_connected(dp->catalog); + /* + * set sink to normal operation mode -- D0 + * before dpcd read + */ + dp_link_psm_config(dp->link, &dp->panel->link_info, false); + if ((status = dp_catalog_link_is_connected(dp->catalog))) + dp->link->sink_count = dp_get_sink_count(dp); + else + dp->link->sink_count = 0; /* * can not declared display is connected unless * HDMI cable is plugged in and sink_count of * dongle become 1 */ - if (status && dp->link->sink_count) + if (dp->link->sink_count) dp->dp_display.is_connected = true; else dp->dp_display.is_connected = false; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

3 2

← Newer
1
...
70
71
72
73
74
75
76
77
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2021