https://bugzilla.kernel.org/show_bug.cgi?id=212469
Bug ID: 212469
Summary: plymouth animation freezes during shutdown
Product: Drivers
Version: 2.5
Kernel Version: 5.11.6
Hardware: Intel
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: …
[View More]amirgi73(a)criptext.com
Regression: No
Created attachment 296125
--> https://bugzilla.kernel.org/attachment.cgi?id=296125&action=edit
plymouth animation freezes during shutdown
Overview:
plymouth animation during shutdown freezes. the system would shutdown
without
any problem.
Steps to reproduce:
with plymouth installed and lightdm-plymouth/sddm-plymouth.service enabled,
after pressing restart or shutdown button, plymouth animation appears
normally then the screen would turn off and then it turn on again, this
time it shows a frozen plymouth animation. after about 5sec the system
would shutdown/restart normally.
Expected Results:
plymouth animation will work during shutdown and won't freeze.
Build Date & Hardware:
archlinux-kernel 5.11.6 build 1
CPU: intel i5 7200u
GPU: Intel HD 620 + Nivida 940mx
Video Driver: modsettings driver for Intel HD + Nvidia-proprietary 460.67
in prime render offloading mode
DE: KDE Plasma 5.21.3
plymouth: latest git build
Additional Builds and Platforms:
this problem doesn't occur with kernel 5.10.16.
Additional Information:
see attached video bellow
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
[View Less]
https://bugzilla.kernel.org/show_bug.cgi?id=208909
Bug ID: 208909
Summary: amdgpu Ryzen 7 4700U NULL pointer dereference multi
monitor with rotation
Product: Drivers
Version: 2.5
Kernel Version: 5.8.0-050800-generic
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
…
[View More]Assignee: drivers_video-dri(a)kernel-bugs.osdl.org
Reporter: kernel(a)890.at
Regression: No
Created attachment 290909
--> https://bugzilla.kernel.org/attachment.cgi?id=290909&action=edit
dmesg output
Hi,
I have a lenovo E15 gen2 laptop running, with a Ryzen 7 4700U renoir Vega 7, on
a 5.8 ubuntu mainline kernel including the latest firmware files (git).
System seems stable so far when running 2 monitors (internal display, and
external display on DP).
When adding a third monitor on the HDMI output and rotating this monitor, the
system crashes with a null pointer dereference.
any help would be appreciated
cheers
--
You are receiving this mail because:
You are watching the assignee of the bug.
[View Less]
Currently, the drm_fourcc.h header depends on drm.h for __u32 and __u64.
At the same time drm.h pulls a lot of unneeded symbols.
Add new guard DRM_FOURCC_STANDALONE, which when set will use local
declaration of said symbols.
When used on linux - we pull linux/types.h which is used either way.
On other platforms, BSDs et al, we need a couple of typedefs.
Since those can trigger a warning in some corner-cases*, add some GCC
magic to silence them. Note that incorrect type redefinitions will …
[View More]still
be flagged, and the GCC pragma is ignored by other compilers.
*Corner-case:
If one sets DRM_FOURCC_STANDALONE and compiles with C99 or earlier while
also using -pedantic _and_ the header lives outside of the standard
/usr/include (like BSDs normally do).
v2:
- Add corner-case handling, based on popular demand.
Cc: James Park <james.park(a)lagfreegames.com>
Cc: Pekka Paalanen <pekka.paalanen(a)collabora.com>
Cc: Simon Ser <contact(a)emersion.fr>
Signed-off-by: Emil Velikov <emil.l.velikov(a)gmail.com>
---
include/uapi/drm/drm.h | 10 ++++++++++
include/uapi/drm/drm_fourcc.h | 29 +++++++++++++++++++++++++++++
2 files changed, 39 insertions(+)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 808b48a93330..cd78950e05ce 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -53,6 +53,15 @@ typedef unsigned int drm_handle_t;
#include <stdint.h>
#include <sys/ioccom.h>
#include <sys/types.h>
+
+/*
+ * When using C99 -pedantic the typedefs will trigger a warning.
+ * If the header is considered a system one (-isystem) those will be
+ * ignored, yet on the target platforms BSDs, et al - the headers live
+ * in a non-system location.
+ */
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wpedantic"
typedef int8_t __s8;
typedef uint8_t __u8;
typedef int16_t __s16;
@@ -63,6 +72,7 @@ typedef int64_t __s64;
typedef uint64_t __u64;
typedef size_t __kernel_size_t;
typedef unsigned long drm_handle_t;
+#pragma GCC diagnostic pop
#endif
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 6f0628eb13a6..84a1f96cc4ef 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -24,7 +24,36 @@
#ifndef DRM_FOURCC_H
#define DRM_FOURCC_H
+/*
+ * Define DRM_FOURCC_STANDALONE you're interested only FOURCC and do not want
+ * to pull drm.h into your application.
+ */
+#ifdef DRM_FOURCC_STANDALONE
+#if defined(__linux__)
+
+#include <linux/types.h>
+
+#else /* One of the BSDs */
+
+#include <stdint.h>
+
+/*
+ * When using C99 -pedantic the typedefs will trigger a warning.
+ * If the header is considered a system one (-isystem) those will be
+ * ignored, yet on the target platforms BSDs, et al - the headers live
+ * in a non-system location.
+ */
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wpedantic"
+typedef uint32_t __u32;
+typedef uint64_t __u64;
+#pragma GCC diagnostic pop
+
+#endif /* __linux __ */
+
+#else
#include "drm.h"
+#endif /* DRM_FOURCC_STANDALONE */
#if defined(__cplusplus)
extern "C" {
--
2.30.0
[View Less]
Attempting to submit patch in response to https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6162#note_712454
This will allow Mesa to port code to Windows more easily.
Hide BSD header and drm_handle_t behind _WIN32 check.
Change __volatile__ to volatile, which is standard.
James Park (1):
drm: Fix drm.h uapi header for Windows
include/uapi/drm/drm.h | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
--
2.7.4
commit ecd7274fb4cd ("iommu: Remove unused IOMMU_SYS_CACHE_ONLY flag")
removed unused IOMMU_SYS_CACHE_ONLY prot flag and along with it went
the memory type setting required for the non-coherent masters to use
system cache. Now that system cache support for GPU is added, we will
need to set the right PTE attribute for GPU buffers to be sys cached.
Without this, the system cache lines are not allocated for GPU.
So the patches in this series introduces a new prot flag IOMMU_LLC,
renames …
[View More]IO_PGTABLE_QUIRK_ARM_OUTER_WBWA to IO_PGTABLE_QUIRK_PTW_LLC
and makes GPU the user of this protection flag.
The series slightly depends on following 2 patches posted earlier and
is based on msm-next branch:
* https://lore.kernel.org/patchwork/patch/1363008/
* https://lore.kernel.org/patchwork/patch/1363010/
Sai Prakash Ranjan (3):
iommu/io-pgtable: Rename last-level cache quirk to
IO_PGTABLE_QUIRK_PTW_LLC
iommu/io-pgtable-arm: Add IOMMU_LLC page protection flag
drm/msm: Use IOMMU_LLC page protection flag to map gpu buffers
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 3 +++
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
drivers/gpu/drm/msm/msm_iommu.c | 3 +++
drivers/gpu/drm/msm/msm_mmu.h | 4 ++++
drivers/iommu/io-pgtable-arm.c | 9 ++++++---
include/linux/io-pgtable.h | 6 +++---
include/linux/iommu.h | 6 ++++++
7 files changed, 26 insertions(+), 7 deletions(-)
base-commit: 00fd44a1a4700718d5d962432b55c09820f7e709
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[View Less]
This series adds support for DSI on the MT8167 SoC. HDMI is not yet supported
as secondary display path.
mmsys is not supported by this series and will be sent in a seperate series
based on [0].
[0] https://patchwork.kernel.org/project/linux-mediatek/list/?series=360447
Changelog:
V2: removed 3 patches
Fabien Parent (5):
dt-bindings: display: mediatek: disp: add documentation for MT8167 SoC
dt-bindings: display: mediatek: dsi: add documentation for MT8167 SoC
drm/mediatek: add disp-…
[View More]color MT8167 support
drm/mediatek: add DDP support for MT8167
drm/mediatek: Add support for main DDP path on MT8167
.../display/mediatek/mediatek,disp.txt | 4 +-
.../display/mediatek/mediatek,dsi.txt | 4 +-
drivers/gpu/drm/mediatek/mtk_disp_color.c | 7 +++
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 47 +++++++++++++++++++
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 38 +++++++++++++++
5 files changed, 96 insertions(+), 4 deletions(-)
--
2.28.0
[View Less]
From: Quanyang Wang <quanyang.wang(a)windriver.com>
When insmod zynqmp-dpsub.ko after rmmod it, system will hang with the
error log as below:
root@xilinx-zynqmp:~# insmod zynqmp-dpsub.ko
[ 88.391289] [drm] Initialized zynqmp-dpsub 1.0.0 20130509 for fd4a0000.display on minor 0
[ 88.529906] Console: switching to colour frame buffer device 128x48
[ 88.549402] zynqmp-dpsub fd4a0000.display: [drm] fb0: zynqmp-dpsubdrm frame buffer device
[ 88.571624] zynqmp-dpsub fd4a0000.display: …
[View More]ZynqMP DisplayPort Subsystem driver probed
root@xilinx-zynqmp:~# rmmod zynqmp_dpsub
[ 94.023404] Console: switching to colour dummy device 80x25
root@xilinx-zynqmp:~# insmod zynqmp-dpsub.ko
<hang here>
This is because that in zynqmp_dp_probe it tries to access some DP
registers while the DP controller is still in the reset state. When
running "rmmod zynqmp_dpsub", zynqmp_dp_reset(dp, true) in
zynqmp_dp_phy_exit is called to force the DP controller into the reset
state. Then insmod will call zynqmp_dp_probe to program the DP registers,
but at this moment the DP controller hasn't been brought out of the reset
state yet since the function zynqmp_dp_reset(dp, false) is called later and
this will result the system hang.
Releasing the reset to DP controller before any read/write operation to it
will fix this issue. And for symmetry, move zynqmp_dp_reset() call from
zynqmp_dp_phy_exit() to zynqmp_dp_remove().
Signed-off-by: Quanyang Wang <quanyang.wang(a)windriver.com>
---
V2:
According to Laurent's comments:
- add zynqmp_dp_reset(dp, true) in error path in zynqmp_dp_probe
- move the zynqmp_dp_reset() call from zynqmp_dp_phy_exit() to zynqmp_dp_remove()
---
drivers/gpu/drm/xlnx/zynqmp_dp.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c
index 99158ee67d02..337adf0769ad 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
@@ -402,10 +402,6 @@ static int zynqmp_dp_phy_init(struct zynqmp_dp *dp)
}
}
- ret = zynqmp_dp_reset(dp, false);
- if (ret < 0)
- return ret;
-
zynqmp_dp_clr(dp, ZYNQMP_DP_PHY_RESET, ZYNQMP_DP_PHY_RESET_ALL_RESET);
/*
@@ -441,8 +437,6 @@ static void zynqmp_dp_phy_exit(struct zynqmp_dp *dp)
ret);
}
- zynqmp_dp_reset(dp, true);
-
for (i = 0; i < dp->num_lanes; i++) {
ret = phy_exit(dp->phy[i]);
if (ret)
@@ -1682,9 +1676,13 @@ int zynqmp_dp_probe(struct zynqmp_dpsub *dpsub, struct drm_device *drm)
return PTR_ERR(dp->reset);
}
+ ret = zynqmp_dp_reset(dp, false);
+ if (ret < 0)
+ return ret;
+
ret = zynqmp_dp_phy_probe(dp);
if (ret)
- return ret;
+ goto err_reset;
/* Initialize the hardware. */
zynqmp_dp_write(dp, ZYNQMP_DP_TX_PHY_POWER_DOWN,
@@ -1696,7 +1694,7 @@ int zynqmp_dp_probe(struct zynqmp_dpsub *dpsub, struct drm_device *drm)
ret = zynqmp_dp_phy_init(dp);
if (ret)
- return ret;
+ goto err_reset;
zynqmp_dp_write(dp, ZYNQMP_DP_TRANSMITTER_ENABLE, 1);
@@ -1708,15 +1706,18 @@ int zynqmp_dp_probe(struct zynqmp_dpsub *dpsub, struct drm_device *drm)
zynqmp_dp_irq_handler, IRQF_ONESHOT,
dev_name(dp->dev), dp);
if (ret < 0)
- goto error;
+ goto err_phy_exit;
dev_dbg(dp->dev, "ZynqMP DisplayPort Tx probed with %u lanes\n",
dp->num_lanes);
return 0;
-error:
+err_phy_exit:
zynqmp_dp_phy_exit(dp);
+err_reset:
+ zynqmp_dp_reset(dp, true);
+
return ret;
}
@@ -1734,4 +1735,5 @@ void zynqmp_dp_remove(struct zynqmp_dpsub *dpsub)
zynqmp_dp_write(dp, ZYNQMP_DP_INT_DS, 0xffffffff);
zynqmp_dp_phy_exit(dp);
+ zynqmp_dp_reset(dp, true);
}
--
2.25.1
[View Less]