dri-devel April 2021

dri-devel@lists.freedesktop.org

317 participants
715 discussions

[PATCH 1/2] drm/atomic: document and enforce rules around "spurious" EBUSY
by Daniel Vetter 08 Nov '21

08 Nov '21

When doing an atomic modeset with ALLOW_MODESET drivers are allowed to pull in arbitrary other resources, including CRTCs (e.g. when reconfiguring global resources). But in nonblocking mode userspace has then no idea this happened, which can lead to spurious EBUSY calls, both: - when that other CRTC is currently busy doing a page_flip the ALLOW_MODESET commit can fail with an EBUSY - on the other CRTC a normal atomic flip can fail with EBUSY because of the additional commit inserted by the kernel without userspace's knowledge For blocking commits this isn't a problem, because everyone else will just block until all the CRTC are reconfigured. Only thing userspace can notice is the dropped frames without any reason for why frames got dropped. Consensus is that we need new uapi to handle this properly, but no one has any idea what exactly the new uapi should look like. Since this has been shipping for years already compositors need to deal no matter what, so as a first step just try to enforce this across drivers better with some checks. v2: Add comments and a WARN_ON to enforce this only when allowed - we don't want to silently convert page flips into blocking plane updates just because the driver is buggy. v3: Fix inverted WARN_ON (Pekka). v4: Drop the uapi changes, only add a WARN_ON for now to enforce some rules for drivers. v5: Make the WARNING more informative (Daniel) v6: Add unconditional debug output for compositor hackers to figure out what's going on when they get an EBUSY (Daniel) v7: Fix up old/new_crtc_state confusion for real (Pekka/Ville) References: https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568 Cc: Daniel Stone <daniel(a)fooishbar.org> Cc: Pekka Paalanen <pekka.paalanen(a)collabora.co.uk> Cc: Simon Ser <contact(a)emersion.fr> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- drivers/gpu/drm/drm_atomic.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 58527f151984..aac9122f1da2 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -281,6 +281,10 @@ EXPORT_SYMBOL(__drm_atomic_state_free); * needed. It will also grab the relevant CRTC lock to make sure that the state * is consistent. * + * WARNING: Drivers may only add new CRTC states to a @state if + * drm_atomic_state.allow_modeset is set, or if it's a driver-internal commit + * not created by userspace through an IOCTL call. + * * Returns: * * Either the allocated state or the error code encoded into the pointer. When @@ -1262,10 +1266,15 @@ int drm_atomic_check_only(struct drm_atomic_state *state) struct drm_crtc_state *new_crtc_state; struct drm_connector *conn; struct drm_connector_state *conn_state; + unsigned requested_crtc = 0; + unsigned affected_crtc = 0; int i, ret = 0; DRM_DEBUG_ATOMIC("checking %p\n", state); + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) + requested_crtc |= drm_crtc_mask(crtc); + for_each_oldnew_plane_in_state(state, plane, old_plane_state, new_plane_state, i) { ret = drm_atomic_plane_check(old_plane_state, new_plane_state); if (ret) { @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state *state) } } + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) + affected_crtc |= drm_crtc_mask(crtc); + + /* + * For commits that allow modesets drivers can add other CRTCs to the + * atomic commit, e.g. when they need to reallocate global resources. + * This can cause spurious EBUSY, which robs compositors of a very + * effective sanity check for their drawing loop. Therefor only allow + * drivers to add unrelated CRTC states for modeset commits. + * + * FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an output + * so compositors know what's going on. + */ + if (affected_crtc != requested_crtc) { + DRM_DEBUG_ATOMIC("driver added CRTC to commit: requested 0x%x, affected 0x%0x\n", + requested_crtc, affected_crtc); + WARN(!state->allow_modeset, "adding CRTC not allowed without modesets: requested 0x%x, affected 0x%0x\n", + requested_crtc, affected_crtc); + } + return 0; } EXPORT_SYMBOL(drm_atomic_check_only); -- 2.28.0

5 8

Radeon NI: GIT kernel with the nislands_smc commit doesn't boot on a Freescale P5040 board and P.A.Semi Nemo board
by Christian Zigotzky 08 Nov '21

08 Nov '21

Hello, The Nemo board (A-EON AmigaOne X1000) [1] and the FSL P5040 Cyrus+ board (A-EON AmigaOne X5000) [2] with installed AMD Radeon HD6970 NI graphics cards (Cayman XT) [3] don't boot with the latest git kernel anymore after the commit "drm/radeon/nislands_smc.h: Replace one-element array with flexible-array member in struct NISLANDS_SMC_SWSTATE branch" [4]. This git kernel boots in a virtual e5500 QEMU machine with a VirtIO-GPU [5]. I bisected today [6]. Result: drm/radeon/nislands_smc.h: Replace one-element array with flexible-array member in struct NISLANDS_SMC_SWSTATE branch (434fb1e7444a2efc3a4ebd950c7f771ebfcffa31) [4] is the first bad commit. I was able to revert this commit [7] and after a new compiling, the kernel boots without any problems on my AmigaOnes. After that I created a patch for reverting this commit for new git test kernels. [3] The kernel compiles and boots with this patch on my AmigaOnes. Please find attached the kernel config files. Please check the first bad commit. Thanks, Christian [1] https://en.wikipedia.org/wiki/AmigaOne_X1000 [2] http://wiki.amiga.org/index.php?title=X5000 [3] https://forum.hyperion-entertainment.com/viewtopic.php?f=35&t=4377 [4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… [5] qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev user,id=mynet0 -device virtio-net-pci,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga -usb -device usb-ehci,id=ehci -device usb-tablet -device virtio-keyboard-pci -smp 4 -vnc :1 [6] https://forum.hyperion-entertainment.com/viewtopic.php?p=53074#p53074 [7] git revert 434fb1e7444a2efc3a4ebd950c7f771ebfcffa3

5 10

[Bug 204987] New: general protection fault in amdgpu_dm_atomic_commit_tail (Vega64)
by bugzilla-daemon＠bugzilla.kernel.org 02 Nov '21

02 Nov '21

https://bugzilla.kernel.org/show_bug.cgi?id=204987 Bug ID: 204987 Summary: general protection fault in amdgpu_dm_atomic_commit_tail (Vega64) Product: Drivers Version: 2.5 Kernel Version: 5.3.1 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: steinex(a)nognu.de Regression: No drm.debug=0x54 log uploaded here due to attachment size limit: https://nognu.de/p/1569355650 This is on 5.3.1 with this patch series applied: https://patchwork.freedesktop.org/series/64505/ It happens between ~5 and ~45 minutes after the system is booted into X. There is no obvious pattern what triggers it. -- You are receiving this mail because: You are watching the assignee of the bug.

1 7

linux-next: build warning after merge of the drm tree
by Stephen Rothwell 28 Oct '21

28 Oct '21

Hi all, After merging the drm tree, today's linux-next build (x86_64 allmodconfig) produced this warning: WARNING: unmet direct dependencies detected for DRM_I915_WERROR Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] && !COMPILE_TEST [=y] Selected by [m]: - DRM_I915_DEBUG [=y] && HAS_IOMEM [=y] && EXPERT [=y] && DRM_I915 [=m] WARNING: unmet direct dependencies detected for DRM_I915_WERROR Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] && !COMPILE_TEST [=y] Selected by [m]: - DRM_I915_DEBUG [=y] && HAS_IOMEM [=y] && EXPERT [=y] && DRM_I915 [=m] WARNING: unmet direct dependencies detected for DRM_I915_WERROR Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] && !COMPILE_TEST [=y] Selected by [m]: - DRM_I915_DEBUG [=y] && HAS_IOMEM [=y] && EXPERT [=y] && DRM_I915 [=m] Maybe introduced by commit 4f86975f539d ("drm/i915: Add DEBUG_GEM to the recommended CI config") -- Cheers, Stephen Rothwell

3 7

[Bug 205649] New: Daisy Chain (MST) Session Crash after Screen Lock Resume
by bugzilla-daemon＠bugzilla.kernel.org 18 Oct '21

18 Oct '21

https://bugzilla.kernel.org/show_bug.cgi?id=205649 Bug ID: 205649 Summary: Daisy Chain (MST) Session Crash after Screen Lock Resume Product: Drivers Version: 2.5 Kernel Version: 5.4 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: michael(a)rauch.be Regression: No Error message: Nov 25 17:18:59 hoi kernel: [ 664.616065] [drm] DM_MST: stopping TM on aconnector: 00000000d2ec50d2 [id: 64] Nov 25 17:19:03 hoi kernel: [ 668.779501] [drm] DM_MST: Disabling connector: 0000000020957698 [id: 72] [master: 00000000d2ec50d2] Nov 25 17:19:03 hoi kernel: [ 668.780518] [drm] DM_MST: Disabling connector: 00000000a3e45904 [id: 67] [master: 00000000d2ec50d2] Nov 25 17:19:03 hoi kernel: [ 668.795264] [drm] DM_MST: starting TM on aconnector: 00000000d2ec50d2 [id: 64] Nov 25 17:19:03 hoi kernel: [ 668.868743] [drm] DM_MST: added connector: 00000000a5e1fa4b [id: 84] [master: 00000000d2ec50d2] Nov 25 17:19:03 hoi kernel: [ 669.018055] [drm] DM_MST: added connector: 00000000a62ddae1 [id: 102] [master: 00000000d2ec50d2] Nov 25 17:19:49 hoi kernel: [ 715.510276] [drm] DM_MST: stopping TM on aconnector: 00000000d2ec50d2 [id: 64] Nov 25 17:19:54 hoi kernel: [ 719.723556] [drm] DM_MST: Disabling connector: 00000000a62ddae1 [id: 102] [master: 00000000d2ec50d2] Nov 25 17:19:54 hoi kernel: [ 719.724562] [drm] DM_MST: Disabling connector: 00000000a5e1fa4b [id: 84] [master: 00000000d2ec50d2] Nov 25 17:19:54 hoi kernel: [ 719.738593] [drm] DM_MST: starting TM on aconnector: 00000000d2ec50d2 [id: 64] Nov 25 17:19:54 hoi kernel: [ 719.799040] [drm] DM_MST: added connector: 0000000084594915 [id: 82] [master: 00000000d2ec50d2] Nov 25 17:19:54 hoi kernel: [ 719.944380] [drm] DM_MST: added connector: 000000007a6df593 [id: 111] [master: 00000000d2ec50d2] Nov 25 17:27:56 hoi kernel: [ 1202.137752] [drm] DM_MST: stopping TM on aconnector: 00000000d2ec50d2 [id: 64] Nov 25 17:28:00 hoi kernel: [ 1206.380336] [drm] DM_MST: Disabling connector: 000000007a6df593 [id: 111] [master: 00000000d2ec50d2] Nov 25 17:28:00 hoi kernel: [ 1206.381399] [drm] DM_MST: Disabling connector: 0000000084594915 [id: 82] [master: 00000000d2ec50d2] Nov 25 17:28:00 hoi kernel: [ 1206.395858] [drm] DM_MST: starting TM on aconnector: 00000000d2ec50d2 [id: 64] Nov 25 17:28:00 hoi kernel: [ 1206.478238] [drm] DM_MST: added connector: 00000000e1e4c871 [id: 84] [master: 00000000d2ec50d2] Nov 25 17:28:01 hoi kernel: [ 1206.628767] [drm] DM_MST: added connector: 00000000a3c8d4bc [id: 109] [master: 00000000d2ec50d2] Setup: 2 monitors in Daisy Chain (MST) setup as separate displays How to reproduce the issue: 1. Enable Screen Lock for a Gnome Session 2. Wake up the session after the monitors go to sleep During the issue, the following occured: 1. Session crash for a running user session after wake up 2. User has to login to a new session System specification: Radeon PRO WX 2100 Ubuntu 18.04 I have tried the following combination: Kernel 5.3, 5.4 Mesa 19.0.8 Let me know if more logfiles are needed -- You are receiving this mail because: You are watching the assignee of the bug.

1 9

[PATCH v8 0/4] drm: LogiCVC display controller support
by Paul Kocialkowski 13 Oct '21

13 Oct '21

This series introduces support for the LogiCVC display controller. The controller is a bit unusual since it is usually loaded as programmable logic on Xilinx FPGAs or Zynq-7000 SoCs. More details are presented on the main commit for the driver. More information about the controller is available on the dedicated web page: https://www.logicbricks.com/Products/logiCVC-ML.aspx Note that this driver has rather simple connector management, which was not converted to drm_panel_bridge to keep the ability to enable the panel at first vblank but also to support DVI. Change since v7: - Replaced DRM_INFO/DRM_ERROR/DRM_DEBUG_DRIVER with fashions using drm_device; - Fixed yaml binding alignment issue; - Renamed logicvc-display name to the generic "display" name; - Added patternProperties match for display in the parent mfd binding; - Used drm_atomic_get_new_crtc_state when needed; - Checked mode in mode_valid instead of atomic_check; - Switched to drmm_mode_config_init; - Removed useless logicvc_connector_destroy wrapper; - Removed useless drm_dev_put calls; - Removed atomic_commit_tail that enables the panel and streamlined the logic; - Reworked Makefile cosmetics; - Fixed checkpatch issues. Changes since v6: - Updated to the latest DRM internal API changes; - Used an enum to index dt properties instead of the name string. Changes since v5: - Subclass DRM device and use devm_drm_dev_alloc for allocation; - Removed call to drm_mode_config_cleanup (done automatically with devm); - Some related code cleanups; - Bring back not-for-merge patch adding colorkey support. Changes since v4: - Updated to internal DRM API changes (rebased on drm-misc-next); - Added Kconfig dependency on OF; - Added MAINTAINERS entry; - Used drm_err and dev_err instead of DRM_ERROR where possible; - Various cosmetic changes. Changes since v3: - Rebased on latest drm-misc; - Improved event lock wrapping; - Added collect tag; - Added color-key support patch (not for merge, for reference only). Changes since v2: - Fixed and slightly improved dt schema. Changes since v1: - Switched dt bindings documentation to dt schema; - Described more possible dt parameters; - Added support for the lvds-3bit interface; - Added support for grabbing syscon regmap from parent node; - Removed layers count property and count layers child nodes instead. Paul Kocialkowski (4): dt-bindings: display: Document the Xylon LogiCVC display controller dt-bindings: mfd: logicvc: Add patternProperties for the display drm: Add support for the LogiCVC display controller NOTFORMERGE: drm/logicvc: Add plane colorkey support .../display/xylon,logicvc-display.yaml | 313 +++++++ .../bindings/mfd/xylon,logicvc.yaml | 3 + MAINTAINERS | 6 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/logicvc/Kconfig | 9 + drivers/gpu/drm/logicvc/Makefile | 9 + drivers/gpu/drm/logicvc/logicvc_crtc.c | 280 +++++++ drivers/gpu/drm/logicvc/logicvc_crtc.h | 21 + drivers/gpu/drm/logicvc/logicvc_drm.c | 474 +++++++++++ drivers/gpu/drm/logicvc/logicvc_drm.h | 67 ++ drivers/gpu/drm/logicvc/logicvc_interface.c | 214 +++++ drivers/gpu/drm/logicvc/logicvc_interface.h | 28 + drivers/gpu/drm/logicvc/logicvc_layer.c | 762 ++++++++++++++++++ drivers/gpu/drm/logicvc/logicvc_layer.h | 71 ++ drivers/gpu/drm/logicvc/logicvc_mode.c | 80 ++ drivers/gpu/drm/logicvc/logicvc_mode.h | 15 + drivers/gpu/drm/logicvc/logicvc_of.c | 185 +++++ drivers/gpu/drm/logicvc/logicvc_of.h | 46 ++ drivers/gpu/drm/logicvc/logicvc_regs.h | 88 ++ 20 files changed, 2674 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml create mode 100644 drivers/gpu/drm/logicvc/Kconfig create mode 100644 drivers/gpu/drm/logicvc/Makefile create mode 100644 drivers/gpu/drm/logicvc/logicvc_crtc.c create mode 100644 drivers/gpu/drm/logicvc/logicvc_crtc.h create mode 100644 drivers/gpu/drm/logicvc/logicvc_drm.c create mode 100644 drivers/gpu/drm/logicvc/logicvc_drm.h create mode 100644 drivers/gpu/drm/logicvc/logicvc_interface.c create mode 100644 drivers/gpu/drm/logicvc/logicvc_interface.h create mode 100644 drivers/gpu/drm/logicvc/logicvc_layer.c create mode 100644 drivers/gpu/drm/logicvc/logicvc_layer.h create mode 100644 drivers/gpu/drm/logicvc/logicvc_mode.c create mode 100644 drivers/gpu/drm/logicvc/logicvc_mode.h create mode 100644 drivers/gpu/drm/logicvc/logicvc_of.c create mode 100644 drivers/gpu/drm/logicvc/logicvc_of.h create mode 100644 drivers/gpu/drm/logicvc/logicvc_regs.h -- 2.29.2

5 12

[PATCH 0/3] drm/nouveau: fix a use-after-free in postclose()
by Jeremy Cline 11 Oct '21

11 Oct '21

This series fixes a number of use-after-frees in nouveau's postclose() handler. It was discovered by pointing IGT's core_hotunplug tests at a nouveau device, but the steps to reproduce it are simple: 1. Open the device file 2. Unbind the driver or remove the device 3. Close the file opened in step 1. During the device removal, the nouveau_drm structure is de-allocated, but is dereferenced in the postclose() handler. One obvious solution is to ensure all the operations in the postclose() handler are valid by extending the lifetime of the nouveau_drm structure. This is possible with the new devm_drm_dev_alloc() interface, but the change is somewhat invasive so I thought it best to submit that work separately. Instead, we make use of the drm_dev_unplug() API, clean up all clients in the device removal call, and check to make sure the device has not been unplugged in the postclose() handler. While this does not enable hot-unplug support for nouveau, it's enough to avoid crashing the kernel and leads to all the core_hotunplug tests to pass. Jeremy Cline (3): drm/nouveau: use drm_dev_unplug() during device removal drm/nouveau: Add a dedicated mutex for the clients list drm/nouveau: clean up all clients on device removal drivers/gpu/drm/nouveau/nouveau_drm.c | 39 +++++++++++++++++++++++---- drivers/gpu/drm/nouveau/nouveau_drv.h | 5 ++++ 2 files changed, 39 insertions(+), 5 deletions(-) -- 2.28.0

4 15

[PATCH 0/9] Add 4 Jenson simple panels
by Giulio Benetti 05 Oct '21

05 Oct '21

This patchset introduce Jenson vendor and add 4 of its panels to panel-simple driver. Giulio Benetti (9): dt-bindings: Add Jenson Display vendor prefix dt-bindings: display/panel: add Jenson JT60248-01 dt-bindings: display/panel: add Jenson JT60249-01 dt-bindings: display/panel: add Jenson JT60245-01 dt-bindings: display/panel: add Jenson JT60250-02 drm/panel: simple: add Jenson JT60245-01 drm/panel: simple: add Jenson JT60248-01 drm/panel: simple: add Jenson JT60249-01 drm/panel: simple: add Jenson JT60250-02 .../bindings/display/panel/panel-simple.yaml | 8 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + drivers/gpu/drm/panel/panel-simple.c | 108 ++++++++++++++++++ 3 files changed, 118 insertions(+) -- 2.25.1

3 37

[PATCH] drm: fsl-dcu: enable PIXCLK on LS1021A
by Matthias Schiffer 05 Oct '21

05 Oct '21

The PIXCLK needs to be enabled in SCFG before accessing the DCU on LS1021A, or the access will hang. Signed-off-by: Matthias Schiffer <matthias.schiffer(a)ew.tq-group.com> --- drivers/gpu/drm/fsl-dcu/Kconfig | 1 + drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 25 +++++++++++++++++++++++ drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 3 +++ 3 files changed, 29 insertions(+) diff --git a/drivers/gpu/drm/fsl-dcu/Kconfig b/drivers/gpu/drm/fsl-dcu/Kconfig index d7dd8ba90e3a..9e5a35e7c00c 100644 --- a/drivers/gpu/drm/fsl-dcu/Kconfig +++ b/drivers/gpu/drm/fsl-dcu/Kconfig @@ -8,6 +8,7 @@ config DRM_FSL_DCU select DRM_PANEL select REGMAP_MMIO select VIDEOMODE_HELPERS + select MFD_SYSCON if SOC_LS1021A help Choose this option if you have an Freescale DCU chipset. If M is selected the module will be called fsl-dcu-drm. diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c index abbc1ddbf27f..8a7556655581 100644 --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c @@ -51,6 +51,23 @@ static const struct regmap_config fsl_dcu_regmap_config = { .volatile_reg = fsl_dcu_drm_is_volatile_reg, }; +static int fsl_dcu_scfg_config_ls1021a(struct device_node *np) +{ + struct regmap *scfg; + + scfg = syscon_regmap_lookup_by_compatible("fsl,ls1021a-scfg"); + if (IS_ERR(scfg)) + return PTR_ERR(scfg); + + /* + * For simplicity, enable the PIXCLK unconditionally. It might + * be possible to disable the clock in PM or on unload as a future + * improvement. + */ + return regmap_update_bits(scfg, SCFG_PIXCLKCR, SCFG_PIXCLKCR_PXCEN, + SCFG_PIXCLKCR_PXCEN); +} + static void fsl_dcu_irq_uninstall(struct drm_device *dev) { struct fsl_dcu_drm_device *fsl_dev = dev->dev_private; @@ -70,6 +87,14 @@ static int fsl_dcu_load(struct drm_device *dev, unsigned long flags) return ret; } + if (of_device_is_compatible(fsl_dev->np, "fsl,ls1021a-dcu")) { + ret = fsl_dcu_scfg_config_ls1021a(fsl_dev->np); + if (ret < 0) { + dev_err(dev->dev, "failed to enable pixclk\n"); + goto done; + } + } + ret = drm_vblank_init(dev, dev->mode_config.num_crtc); if (ret < 0) { dev_err(dev->dev, "failed to initialize vblank\n"); diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h index e2049a0e8a92..566396013c04 100644 --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h @@ -160,6 +160,9 @@ #define FSL_DCU_ARGB4444 12 #define FSL_DCU_YUV422 14 +#define SCFG_PIXCLKCR 0x28 +#define SCFG_PIXCLKCR_PXCEN BIT(31) + #define VF610_LAYER_REG_NUM 9 #define LS1021A_LAYER_REG_NUM 10 -- 2.17.1

2 5

[Bug 206349] New: WARNING: dcn20_validate_bandwidth+0x87/0x9e [ amdgpu on 5700 XT ]
by bugzilla-daemon＠bugzilla.kernel.org 05 Oct '21

05 Oct '21

https://bugzilla.kernel.org/show_bug.cgi?id=206349 Bug ID: 206349 Summary: WARNING: dcn20_validate_bandwidth+0x87/0x9e [ amdgpu on 5700 XT ] Product: Drivers Version: 2.5 Kernel Version: 5.5.0 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: low Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: doublej472(a)gmail.com Regression: No Created attachment 287027 --> https://bugzilla.kernel.org/attachment.cgi?id=287027&action=edit dmesg warnings from amdgpu I've been seeing this warning pop up in my dmesg for a while from amdgpu, all relating to dcn20_validate_bandwidth. I'm not sure if it's affecting my machine in a significant manner, but it keeps showing up. [ 8236.203353] arch-desktop kernel: ------------[ cut here ]------------ [ 8236.203403] arch-desktop kernel: WARNING: CPU: 9 PID: 555 at drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:2959 dcn20_validate_bandwidth+0x87/0x9e [amdgpu] [ 8236.203405] arch-desktop kernel: Modules linked in: bridge stp llc bcache crc64 raid1 snd_usb_audio snd_usbmidi_lib kvm_amd snd_rawmidi kvm amdgpu gpu_sched k10temp ttm sch_fq_codel efivarfs [ 8236.203414] arch-desktop kernel: CPU: 9 PID: 555 Comm: Xorg Not tainted 5.5.0-gentoo #1 [ 8236.203415] arch-desktop kernel: Hardware name: System manufacturer System Product Name/PRIME X370-PRO, BIOS 5220 09/12/2019 [ 8236.203451] arch-desktop kernel: RIP: 0010:dcn20_validate_bandwidth+0x87/0x9e [amdgpu] [ 8236.203453] arch-desktop kernel: Code: 00 00 01 eb 29 31 d2 f2 0f 11 85 70 21 00 00 48 89 ee e8 e9 f7 ff ff 89 c2 22 85 b8 1d 00 00 74 09 c6 85 b8 1d 00 00 00 eb 04 <0f> 0b 89 d0 f2 0f 10 1c 24 f2 0f 11 9d 70 21 00 00 48 83 c4 10 5d [ 8236.203455] arch-desktop kernel: RSP: 0018:ffff8e9800c9fa80 EFLAGS: 00010246 [ 8236.203457] arch-desktop kernel: RAX: 0000000000000000 RBX: ffff8b19d3f6b900 RCX: 0000000000215f49 [ 8236.203458] arch-desktop kernel: RDX: 0000000000000001 RSI: 0000000000215f09 RDI: 000000000002e300 [ 8236.203460] arch-desktop kernel: RBP: ffff8b17ee190000 R08: ffff8b1b7b406840 R09: ffffffffc0345b6b [ 8236.203461] arch-desktop kernel: R10: ffff8b1b66e6a000 R11: ffff8b1b66e6a000 R12: 0000000000000000 [ 8236.203462] arch-desktop kernel: R13: 0000000000000000 R14: ffff8b17ee190000 R15: 0000000000000002 [ 8236.203464] arch-desktop kernel: FS: 00007ff890a4e980(0000) GS:ffff8b1b7ea40000(0000) knlGS:0000000000000000 [ 8236.203465] arch-desktop kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8236.203467] arch-desktop kernel: CR2: 00005620d7c8eef0 CR3: 00000007e2886000 CR4: 0000000000340ee0 [ 8236.203468] arch-desktop kernel: Call Trace: [ 8236.203504] arch-desktop kernel: dc_validate_global_state+0x1b6/0x1d7 [amdgpu] [ 8236.203549] arch-desktop kernel: amdgpu_dm_atomic_check+0x52a/0x666 [amdgpu] [ 8236.203556] arch-desktop kernel: drm_atomic_check_only+0x586/0x62e [ 8236.203559] arch-desktop kernel: ? drm_atomic_set_crtc_for_connector+0xd9/0xe1 [ 8236.203562] arch-desktop kernel: drm_atomic_commit+0xe/0x44 [ 8236.203565] arch-desktop kernel: drm_atomic_helper_set_config+0x50/0x66 [ 8236.203569] arch-desktop kernel: drm_mode_setcrtc+0x221/0x5dc [ 8236.203574] arch-desktop kernel: ? drm_mode_getcrtc+0x145/0x145 [ 8236.203576] arch-desktop kernel: drm_ioctl_kernel+0x8d/0xe1 [ 8236.203579] arch-desktop kernel: drm_ioctl+0x1f9/0x2d3 [ 8236.203582] arch-desktop kernel: ? drm_mode_getcrtc+0x145/0x145 [ 8236.203613] arch-desktop kernel: amdgpu_drm_ioctl+0x45/0x71 [amdgpu] [ 8236.203617] arch-desktop kernel: vfs_ioctl+0x19/0x26 [ 8236.203620] arch-desktop kernel: do_vfs_ioctl+0x574/0x59e [ 8236.203623] arch-desktop kernel: ksys_ioctl+0x49/0x68 [ 8236.203626] arch-desktop kernel: __x64_sys_ioctl+0x11/0x14 [ 8236.203629] arch-desktop kernel: do_syscall_64+0x48/0x55 [ 8236.203632] arch-desktop kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 8236.203634] arch-desktop kernel: RIP: 0033:0x7ff890d0b5c7 [ 8236.203636] arch-desktop kernel: Code: 00 00 00 75 0c 48 c7 c0 ff ff ff ff 48 83 c4 18 c3 e8 0d c8 01 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 99 e8 0c 00 f7 d8 64 89 01 48 [ 8236.203638] arch-desktop kernel: RSP: 002b:00007ffea4921a48 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 8236.203639] arch-desktop kernel: RAX: ffffffffffffffda RBX: 00007ffea4921a80 RCX: 00007ff890d0b5c7 [ 8236.203641] arch-desktop kernel: RDX: 00007ffea4921a80 RSI: 00000000c06864a2 RDI: 000000000000000c [ 8236.203642] arch-desktop kernel: RBP: 00000000c06864a2 R08: 0000000000000000 R09: 0000000000000000 [ 8236.203643] arch-desktop kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 00005620d7fe1e70 [ 8236.203644] arch-desktop kernel: R13: 000000000000000c R14: 00005620d8e342f0 R15: 00005620d6dc2040 [ 8236.203649] arch-desktop kernel: ---[ end trace 82184d8b2d613936 ]--- I've attached a few more warnings to this bug report. I'm not sure what causes this warning. It *might* happen whenever the GPU is being used, if I leave the machine alone it tends to not show. It could be related to waking up my monitor? (Attached to a DisplayPort cable, running at 1920x1080 @ 144 Hz, if that matters) My system is running on an ASUS PRIME X370-PRO motherboard with a ryzen 3900x, 32GB of ram, and a 5700 XT GPU (on a PCIe 3.0 x16 link). Please let me know if you need more info! -- You are receiving this mail because: You are watching the assignee of the bug.

1 1

← Newer
1
2
3
4
5
6
7
8
...
72
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2021