* [PATCH] drm/pl111: Advertise no pixel blending
@ 2026-08-25 10:54 Roshan Kumar
2026-08-25 11:07 ` sashiko-bot
` (7 more replies)
0 siblings, 8 replies; 23+ messages in thread
From: Roshan Kumar @ 2026-08-25 10:54 UTC (permalink / raw)
To: linusw, dri-devel
Cc: leandro.ribeiro, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, pimyn, linux-kernel, roshaen09
Commit 860e748bddcc ("drm: ensure blend mode supported if
pixel format with alpha exposed") added validation that warns when a
plane exposes an alpha format without a pixel blend mode property. PL111
exposes several such formats but does not attach the property.
The PL110/PL111 controller scans out a single framebuffer and does not
blend its alpha channel with a background. Advertise
DRM_MODE_BLEND_PIXEL_NONE to match the existing hardware behavior.
With panic_on_warn enabled, this warning prevents the syzkaller
vexpress-a15 manager from booting. The change was tested on current
master with QEMU 10 and the existing production DTB; the guest reached
sshd and returned an SSH banner.
Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed")
Link: https://github.com/google/syzkaller/issues/7805
Signed-off-by: Roshan Kumar <roshaen09@gmail.com>
---
drivers/gpu/drm/pl111/pl111_display.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/pl111/pl111_display.c b/drivers/gpu/drm/pl111/pl111_display.c
index 5d10bc5..758b297 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -15,6 +15,7 @@
#include <linux/media-bus-format.h>
#include <linux/of_graph.h>
+#include <drm/drm_blend.h>
#include <drm/drm_fb_dma_helper.h>
#include <drm/drm_fourcc.h>
#include <drm/drm_framebuffer.h>
@@ -596,5 +597,10 @@ int pl111_display_init(struct drm_device *drm)
if (ret)
return ret;
+ ret = drm_plane_create_blend_mode_property(&priv->pipe.plane,
+ BIT(DRM_MODE_BLEND_PIXEL_NONE));
+ if (ret)
+ return ret;
+
return 0;
}
--
2.43.0
^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/pl111: Advertise no pixel blending
2026-08-25 10:54 [PATCH] drm/pl111: Advertise no pixel blending Roshan Kumar
@ 2026-08-25 11:07 ` sashiko-bot
2026-09-08 21:31 ` Leandro Ribeiro
` (6 subsequent siblings)
7 siblings, 0 replies; 23+ messages in thread
From: sashiko-bot @ 2026-08-25 11:07 UTC (permalink / raw)
To: Roshan Kumar; +Cc: dri-devel
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The initial atomic plane state defaults to an invalid pixel blend mode, which contradicts the newly added blend mode property that only supports `DRM_MODE_BLEND_PIXEL_NONE`.
--
--- Patch [1]: [PATCH] drm/pl111: Advertise no pixel blending ---
commit e96a716603035744ccddd019e74ade69db24a36e
Author: Roshan Kumar <roshaen09@gmail.com>
drm/pl111: Advertise no pixel blending
This commit adds a pixel blend mode property to the PL111 display plane to
satisfy validation introduced in commit 860e748bddcc, advertising only
DRM_MODE_BLEND_PIXEL_NONE. This resolves a syzkaller panic during boot on
vexpress-a15 managers.
Link: https://github.com/google/syzkaller/issues/7805
> diff --git a/drivers/gpu/drm/pl111/pl111_display.c b/drivers/gpu/drm/pl111/pl111_display.c
> index 5d10bc5fdf1f6..758b297cbdea5 100644
> --- a/drivers/gpu/drm/pl111/pl111_display.c
> +++ b/drivers/gpu/drm/pl111/pl111_display.c
[ ... ]
> @@ -596,5 +597,10 @@ int pl111_display_init(struct drm_device *drm)
> if (ret)
> return ret;
>
> + ret = drm_plane_create_blend_mode_property(&priv->pipe.plane,
> + BIT(DRM_MODE_BLEND_PIXEL_NONE));
[Severity: High]
Will this cause atomic commits to fail with -EINVAL for standard userspace
compositors?
Because pl111 uses drm_simple_display_pipe_init() and lacks a custom
reset_plane hook, the DRM core falls back to drm_atomic_helper_plane_reset()
which unconditionally sets plane_state->pixel_blend_mode =
DRM_MODE_BLEND_PREMULTI during __drm_atomic_helper_plane_state_init().
Since this newly created property only supports DRM_MODE_BLEND_PIXEL_NONE,
userspace reading the initial state and submitting it back will provide an
enum value that is not in the allowed mask. This causes
drm_property_change_valid_get() to reject the commit.
Does the driver need a custom reset hook to initialize the plane state to
DRM_MODE_BLEND_PIXEL_NONE instead of relying on the default initialization?
> + if (ret)
> + return ret;
> +
> return 0;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260825105427.686619-1-roshaen09@gmail.com?part=1
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/pl111: Advertise no pixel blending
2026-08-25 10:54 [PATCH] drm/pl111: Advertise no pixel blending Roshan Kumar
2026-08-25 11:07 ` sashiko-bot
@ 2026-09-08 21:31 ` Leandro Ribeiro
2026-09-09 4:17 ` Roshan Kumar
` (5 subsequent siblings)
7 siblings, 0 replies; 23+ messages in thread
From: Leandro Ribeiro @ 2026-09-08 21:31 UTC (permalink / raw)
To: Roshan Kumar, linusw, dri-devel
Cc: maarten.lankhorst, mripard, tzimmermann, airlied, simona, pimyn,
linux-kernel
On 8/25/26 7:54 AM, Roshan Kumar wrote:
> Commit 860e748bddcc ("drm: ensure blend mode supported if
> pixel format with alpha exposed") added validation that warns when a
> plane exposes an alpha format without a pixel blend mode property. PL111
> exposes several such formats but does not attach the property.
>
> The PL110/PL111 controller scans out a single framebuffer and does not
> blend its alpha channel with a background. Advertise
> DRM_MODE_BLEND_PIXEL_NONE to match the existing hardware behavior.
>
> With panic_on_warn enabled, this warning prevents the syzkaller
> vexpress-a15 manager from booting. The change was tested on current
> master with QEMU 10 and the existing production DTB; the guest reached
> sshd and returned an SSH banner.
>
> Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed")
> Link: https://github.com/google/syzkaller/issues/7805
> Signed-off-by: Roshan Kumar <roshaen09@gmail.com>
> ---
> drivers/gpu/drm/pl111/pl111_display.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/pl111/pl111_display.c b/drivers/gpu/drm/pl111/pl111_display.c
> index 5d10bc5..758b297 100644
> --- a/drivers/gpu/drm/pl111/pl111_display.c
> +++ b/drivers/gpu/drm/pl111/pl111_display.c
> @@ -15,6 +15,7 @@
> #include <linux/media-bus-format.h>
> #include <linux/of_graph.h>
>
> +#include <drm/drm_blend.h>
> #include <drm/drm_fb_dma_helper.h>
> #include <drm/drm_fourcc.h>
> #include <drm/drm_framebuffer.h>
> @@ -596,5 +597,10 @@ int pl111_display_init(struct drm_device *drm)
> if (ret)
> return ret;
>
> + ret = drm_plane_create_blend_mode_property(&priv->pipe.plane,
> + BIT(DRM_MODE_BLEND_PIXEL_NONE));
> + if (ret)
> + return ret;
> +
Hello,
Thank you! Looks good to me from the blend-mode requirements
perspective. But I'm not familiar with this driver. So, with this caveat:
Reviewed-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
> return 0;
> }
--
Leandro Ribeiro
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/pl111: Advertise no pixel blending
2026-08-25 10:54 [PATCH] drm/pl111: Advertise no pixel blending Roshan Kumar
2026-08-25 11:07 ` sashiko-bot
2026-09-08 21:31 ` Leandro Ribeiro
@ 2026-09-09 4:17 ` Roshan Kumar
2026-09-09 8:16 ` Thomas Zimmermann
` (4 subsequent siblings)
7 siblings, 0 replies; 23+ messages in thread
From: Roshan Kumar @ 2026-09-09 4:17 UTC (permalink / raw)
To: linusw, dri-devel
Cc: leandro.ribeiro, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, pimyn, linux-kernel
Thank you, Leandro!
I have applied your Reviewed-by tag to the commit. Since this also fixes
the boot failure behind google/syzkaller#7805 (the ci-qemu2-arm32
instance currently works around it in kernel config), I am hoping
drm-misc can pick this up.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/pl111: Advertise no pixel blending
2026-08-25 10:54 [PATCH] drm/pl111: Advertise no pixel blending Roshan Kumar
` (2 preceding siblings ...)
2026-09-09 4:17 ` Roshan Kumar
@ 2026-09-09 8:16 ` Thomas Zimmermann
2026-09-11 13:24 ` Linus Walleij
[not found] ` <d3a928e0-0faa-4cd4-9d2e-cb9be4cf84c0@suse.de>
` (3 subsequent siblings)
7 siblings, 1 reply; 23+ messages in thread
From: Thomas Zimmermann @ 2026-09-09 8:16 UTC (permalink / raw)
To: Roshan Kumar, linusw, dri-devel
Cc: leandro.ribeiro, maarten.lankhorst, mripard, airlied, simona,
pimyn, linux-kernel
Hi
Am 25.08.26 um 12:54 schrieb Roshan Kumar:
> Commit 860e748bddcc ("drm: ensure blend mode supported if
> pixel format with alpha exposed") added validation that warns when a
> plane exposes an alpha format without a pixel blend mode property. PL111
> exposes several such formats but does not attach the property.
>
> The PL110/PL111 controller scans out a single framebuffer and does not
> blend its alpha channel with a background. Advertise
> DRM_MODE_BLEND_PIXEL_NONE to match the existing hardware behavior.
Why does the driver report ARGB formats in the first place. I'm looking
at the code at [1] and I don't see any difference to XRGB. Unless I'm
missing something, please remove ARGB formats from this driver instead.
Drivers should not report formats they don't support.
[1]
https://elixir.bootlin.com/linux/v7.2.2/source/drivers/gpu/drm/pl111/pl111_display.c#L259
Best regards
Thomas
>
> With panic_on_warn enabled, this warning prevents the syzkaller
> vexpress-a15 manager from booting. The change was tested on current
> master with QEMU 10 and the existing production DTB; the guest reached
> sshd and returned an SSH banner.
>
> Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed")
> Link: https://github.com/google/syzkaller/issues/7805
> Signed-off-by: Roshan Kumar <roshaen09@gmail.com>
> ---
> drivers/gpu/drm/pl111/pl111_display.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/pl111/pl111_display.c b/drivers/gpu/drm/pl111/pl111_display.c
> index 5d10bc5..758b297 100644
> --- a/drivers/gpu/drm/pl111/pl111_display.c
> +++ b/drivers/gpu/drm/pl111/pl111_display.c
> @@ -15,6 +15,7 @@
> #include <linux/media-bus-format.h>
> #include <linux/of_graph.h>
>
> +#include <drm/drm_blend.h>
> #include <drm/drm_fb_dma_helper.h>
> #include <drm/drm_fourcc.h>
> #include <drm/drm_framebuffer.h>
> @@ -596,5 +597,10 @@ int pl111_display_init(struct drm_device *drm)
> if (ret)
> return ret;
>
> + ret = drm_plane_create_blend_mode_property(&priv->pipe.plane,
> + BIT(DRM_MODE_BLEND_PIXEL_NONE));
> + if (ret)
> + return ret;
> +
> return 0;
> }
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, (HRB 36809, AG Nürnberg)
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/pl111: Advertise no pixel blending
[not found] ` <d3a928e0-0faa-4cd4-9d2e-cb9be4cf84c0@suse.de>
@ 2026-09-10 5:44 ` Roshan Kumar
0 siblings, 0 replies; 23+ messages in thread
From: Roshan Kumar @ 2026-09-10 5:44 UTC (permalink / raw)
To: linusw, dri-devel
Cc: leandro.ribeiro, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, pimyn, linux-kernel
Hi Thomas,
You are right, there is no good reason for these formats to be here: the
hardware never looks at the alpha byte, and the ARGB/ABGR entries just
duplicate their X counterparts.
I will send a v2 that removes the alpha formats from the driver instead.
(Thanks Leandro for the review of v1; the approach changed in v2 so I have
dropped the tag.)
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH v2] drm/pl111: drop alpha formats the hardware cannot scan out
2026-08-25 10:54 [PATCH] drm/pl111: Advertise no pixel blending Roshan Kumar
` (4 preceding siblings ...)
[not found] ` <d3a928e0-0faa-4cd4-9d2e-cb9be4cf84c0@suse.de>
@ 2026-09-10 5:45 ` Roshan Kumar
2026-09-10 5:51 ` sashiko-bot
2026-09-10 6:15 ` Thomas Zimmermann
2026-09-10 19:25 ` [PATCH] drm/pl111: Advertise no pixel blending Roshan Kumar
2026-09-10 19:25 ` [PATCH v3] drm/pl111: drop alpha formats the hardware cannot scan out Roshan Kumar
7 siblings, 2 replies; 23+ messages in thread
From: Roshan Kumar @ 2026-09-10 5:45 UTC (permalink / raw)
To: linusw, dri-devel
Cc: leandro.ribeiro, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, pimyn, linux-kernel
The PL110/PL111 controller scans out a single framebuffer and never
blends its alpha channel with anything. In the pixel-format tables every
alpha-carrying entry (ARGB/ABGR in 8888, 1555 and 4444) maps to exactly
the same register configuration as its XRGB/XBGR counterpart, so the
alpha byte was never used by the hardware.
Commit 860e748bddcc ("drm: ensure blend mode supported if pixel format
with alpha exposed") added validation that warns when a plane exposes
alpha formats without a pixel blend mode property, and PL111 does exactly
that. With panic_on_warn enabled the warning prevents the syzkaller
vexpress-a15 manager from booting.
Drivers should not report formats they do not support, so remove the
alpha formats from the PL110, PL111 and Nomadik PL110 variant tables and
the now dead case labels in the display setup, instead of advertising a
blend mode property. Behavior is unchanged for userspace that picks an
XRGB/XBGR/RGB format; alpha-picking clients fall back to the identical
X variant.
Link: https://github.com/google/syzkaller/issues/7805
Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed")
Signed-off-by: Roshan Kumar <roshaen09@gmail.com>
Changes in v2: drop the alpha formats entirely instead of advertising a
DRM_MODE_BLEND_PIXEL_NONE property, per review feedback from Thomas
Zimmermann. Leandro's Reviewed-by from v1 is not carried as the
approach changed.
---
drivers/gpu/drm/pl111/pl111_display.c | 6 ------
drivers/gpu/drm/pl111/pl111_drv.c | 16 ----------------
2 files changed, 22 deletions(-)
diff --git a/drivers/gpu/drm/pl111/pl111_display.c b/drivers/gpu/drm/pl111/pl111_display.c
index 5d10bc5fdf1f..e1b513d36c27 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -267,14 +267,12 @@ static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
if (priv->variant->st_bitmux_control)
cntl |= CNTL_ST_LCDBPP24_PACKED;
break;
- case DRM_FORMAT_ABGR8888:
case DRM_FORMAT_XBGR8888:
if (priv->variant->st_bitmux_control)
cntl |= CNTL_LCDBPP24 | CNTL_BGR;
else
cntl |= CNTL_LCDBPP24;
break;
- case DRM_FORMAT_ARGB8888:
case DRM_FORMAT_XRGB8888:
if (priv->variant->st_bitmux_control)
cntl |= CNTL_LCDBPP24;
@@ -297,13 +295,11 @@ static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
else
cntl |= CNTL_LCDBPP16_565 | CNTL_BGR;
break;
- case DRM_FORMAT_ABGR1555:
case DRM_FORMAT_XBGR1555:
cntl |= CNTL_LCDBPP16;
if (priv->variant->st_bitmux_control)
cntl |= CNTL_ST_1XBPP_5551 | CNTL_BGR;
break;
- case DRM_FORMAT_ARGB1555:
case DRM_FORMAT_XRGB1555:
cntl |= CNTL_LCDBPP16;
if (priv->variant->st_bitmux_control)
@@ -311,13 +307,11 @@ static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
else
cntl |= CNTL_BGR;
break;
- case DRM_FORMAT_ABGR4444:
case DRM_FORMAT_XBGR4444:
cntl |= CNTL_LCDBPP16_444;
if (priv->variant->st_bitmux_control)
cntl |= CNTL_ST_1XBPP_444 | CNTL_BGR;
break;
- case DRM_FORMAT_ARGB4444:
case DRM_FORMAT_XRGB4444:
cntl |= CNTL_LCDBPP16_444;
if (priv->variant->st_bitmux_control)
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c b/drivers/gpu/drm/pl111/pl111_drv.c
index ac7b1d12a0f5..2175ac953795 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -341,13 +341,9 @@ static void pl111_amba_shutdown(struct amba_device *amba_dev)
* This early variant lacks the 565 and 444 pixel formats.
*/
static const u32 pl110_pixel_formats[] = {
- DRM_FORMAT_ABGR8888,
DRM_FORMAT_XBGR8888,
- DRM_FORMAT_ARGB8888,
DRM_FORMAT_XRGB8888,
- DRM_FORMAT_ABGR1555,
DRM_FORMAT_XBGR1555,
- DRM_FORMAT_ARGB1555,
DRM_FORMAT_XRGB1555,
};
@@ -361,19 +357,13 @@ static const struct pl111_variant_data pl110_variant = {
/* RealView, Versatile Express etc use this modern variant */
static const u32 pl111_pixel_formats[] = {
- DRM_FORMAT_ABGR8888,
DRM_FORMAT_XBGR8888,
- DRM_FORMAT_ARGB8888,
DRM_FORMAT_XRGB8888,
DRM_FORMAT_BGR565,
DRM_FORMAT_RGB565,
- DRM_FORMAT_ABGR1555,
DRM_FORMAT_XBGR1555,
- DRM_FORMAT_ARGB1555,
DRM_FORMAT_XRGB1555,
- DRM_FORMAT_ABGR4444,
DRM_FORMAT_XBGR4444,
- DRM_FORMAT_ARGB4444,
DRM_FORMAT_XRGB4444,
};
@@ -387,19 +377,13 @@ static const struct pl111_variant_data pl111_variant = {
static const u32 pl110_nomadik_pixel_formats[] = {
DRM_FORMAT_RGB888,
DRM_FORMAT_BGR888,
- DRM_FORMAT_ABGR8888,
DRM_FORMAT_XBGR8888,
- DRM_FORMAT_ARGB8888,
DRM_FORMAT_XRGB8888,
DRM_FORMAT_BGR565,
DRM_FORMAT_RGB565,
- DRM_FORMAT_ABGR1555,
DRM_FORMAT_XBGR1555,
- DRM_FORMAT_ARGB1555,
DRM_FORMAT_XRGB1555,
- DRM_FORMAT_ABGR4444,
DRM_FORMAT_XBGR4444,
- DRM_FORMAT_ARGB4444,
DRM_FORMAT_XRGB4444,
};
--
2.43.0
^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH v2] drm/pl111: drop alpha formats the hardware cannot scan out
2026-09-10 5:45 ` [PATCH v2] drm/pl111: drop alpha formats the hardware cannot scan out Roshan Kumar
@ 2026-09-10 5:51 ` sashiko-bot
2026-09-10 6:15 ` Thomas Zimmermann
1 sibling, 0 replies; 23+ messages in thread
From: sashiko-bot @ 2026-09-10 5:51 UTC (permalink / raw)
To: Roshan Kumar; +Cc: dri-devel
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The patch fails to remove alpha pixel formats from board-specific variant tables in `pl111_versatile.c` (such as `pl111_realview_pixel_formats` used by `vexpress-a15`). This leaves the original bug unfixed on the exact platform mentioned in the commit message. Furthermore, it introduces a new regression: because the alpha case labels were removed from `pl111_display_enable()`, selecting one of these still-exposed formats will hit the `default:` case. This triggers a new `WARN_ONCE` and fails to properly configure the hardware display registers (skipping `cntl` setup).
--
commit 10499c458facc30bed43b7322f9a6352b1c136f7
Author: Roshan Kumar <roshaen09@gmail.com>
drm/pl111: drop alpha formats the hardware cannot scan out
This commit removes alpha pixel formats from the PL110 and PL111 variant
tables to prevent exposing unsupported blend modes to userspace. It also
removes the corresponding format case labels from the display setup code.
Link: https://github.com/google/syzkaller/issues/7805
> diff --git a/drivers/gpu/drm/pl111/pl111_display.c b/drivers/gpu/drm/pl111/pl111_display.c
> index 5d10bc5fdf1f6..e1b513d36c27c 100644
> --- a/drivers/gpu/drm/pl111/pl111_display.c
> +++ b/drivers/gpu/drm/pl111/pl111_display.c
> @@ -267,14 +267,12 @@ static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
> if (priv->variant->st_bitmux_control)
> cntl |= CNTL_ST_LCDBPP24_PACKED;
> break;
> - case DRM_FORMAT_ABGR8888:
> case DRM_FORMAT_XBGR8888:
[Severity: High]
Will removing these case labels cause a regression for boards using the
versatile variants?
It looks like the alpha formats were not removed from the board-specific
tables in drivers/gpu/drm/pl111/pl111_versatile.c (such as the
pl111_realview_pixel_formats table used by vexpress-a15).
Because those formats are still exposed to userspace, if an application
selects an alpha format like DRM_FORMAT_ABGR8888, pl111_display_enable()
will now fall through to the default case:
default:
WARN_ONCE(true, "Unknown FB format 0x%08x\n",
fb->format->format);
break;
This seems like it would trigger the newly reachable warning (causing boot
failures on systems like the vexpress-a15 manager if panic_on_warn is
enabled) and fail to properly configure the hardware display registers.
Should the versatile formats be updated to drop the alpha formats as well?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260910054503.4155812-1-roshaen09@gmail.com?part=1
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v2] drm/pl111: drop alpha formats the hardware cannot scan out
2026-09-10 5:45 ` [PATCH v2] drm/pl111: drop alpha formats the hardware cannot scan out Roshan Kumar
2026-09-10 5:51 ` sashiko-bot
@ 2026-09-10 6:15 ` Thomas Zimmermann
1 sibling, 0 replies; 23+ messages in thread
From: Thomas Zimmermann @ 2026-09-10 6:15 UTC (permalink / raw)
To: Roshan Kumar, linusw, dri-devel
Cc: leandro.ribeiro, maarten.lankhorst, mripard, airlied, simona,
pimyn, linux-kernel
Hi
Am 10.09.26 um 07:45 schrieb Roshan Kumar:
> The PL110/PL111 controller scans out a single framebuffer and never
> blends its alpha channel with anything. In the pixel-format tables every
> alpha-carrying entry (ARGB/ABGR in 8888, 1555 and 4444) maps to exactly
> the same register configuration as its XRGB/XBGR counterpart, so the
> alpha byte was never used by the hardware.
>
> Commit 860e748bddcc ("drm: ensure blend mode supported if pixel format
> with alpha exposed") added validation that warns when a plane exposes
> alpha formats without a pixel blend mode property, and PL111 does exactly
> that. With panic_on_warn enabled the warning prevents the syzkaller
> vexpress-a15 manager from booting.
>
> Drivers should not report formats they do not support, so remove the
> alpha formats from the PL110, PL111 and Nomadik PL110 variant tables and
> the now dead case labels in the display setup, instead of advertising a
> blend mode property. Behavior is unchanged for userspace that picks an
> XRGB/XBGR/RGB format; alpha-picking clients fall back to the identical
> X variant.
Please see the comment from the Sashiko bot about additional alpha
formats. Apart from that that patch looks good.
BTW, do you have this hardware available for testing?
Best regards
Thomas
>
> Link: https://github.com/google/syzkaller/issues/7805
> Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed")
> Signed-off-by: Roshan Kumar <roshaen09@gmail.com>
> Changes in v2: drop the alpha formats entirely instead of advertising a
> DRM_MODE_BLEND_PIXEL_NONE property, per review feedback from Thomas
> Zimmermann. Leandro's Reviewed-by from v1 is not carried as the
> approach changed.
>
> ---
> drivers/gpu/drm/pl111/pl111_display.c | 6 ------
> drivers/gpu/drm/pl111/pl111_drv.c | 16 ----------------
> 2 files changed, 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/pl111/pl111_display.c b/drivers/gpu/drm/pl111/pl111_display.c
> index 5d10bc5fdf1f..e1b513d36c27 100644
> --- a/drivers/gpu/drm/pl111/pl111_display.c
> +++ b/drivers/gpu/drm/pl111/pl111_display.c
> @@ -267,14 +267,12 @@ static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
> if (priv->variant->st_bitmux_control)
> cntl |= CNTL_ST_LCDBPP24_PACKED;
> break;
> - case DRM_FORMAT_ABGR8888:
> case DRM_FORMAT_XBGR8888:
> if (priv->variant->st_bitmux_control)
> cntl |= CNTL_LCDBPP24 | CNTL_BGR;
> else
> cntl |= CNTL_LCDBPP24;
> break;
> - case DRM_FORMAT_ARGB8888:
> case DRM_FORMAT_XRGB8888:
> if (priv->variant->st_bitmux_control)
> cntl |= CNTL_LCDBPP24;
> @@ -297,13 +295,11 @@ static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
> else
> cntl |= CNTL_LCDBPP16_565 | CNTL_BGR;
> break;
> - case DRM_FORMAT_ABGR1555:
> case DRM_FORMAT_XBGR1555:
> cntl |= CNTL_LCDBPP16;
> if (priv->variant->st_bitmux_control)
> cntl |= CNTL_ST_1XBPP_5551 | CNTL_BGR;
> break;
> - case DRM_FORMAT_ARGB1555:
> case DRM_FORMAT_XRGB1555:
> cntl |= CNTL_LCDBPP16;
> if (priv->variant->st_bitmux_control)
> @@ -311,13 +307,11 @@ static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
> else
> cntl |= CNTL_BGR;
> break;
> - case DRM_FORMAT_ABGR4444:
> case DRM_FORMAT_XBGR4444:
> cntl |= CNTL_LCDBPP16_444;
> if (priv->variant->st_bitmux_control)
> cntl |= CNTL_ST_1XBPP_444 | CNTL_BGR;
> break;
> - case DRM_FORMAT_ARGB4444:
> case DRM_FORMAT_XRGB4444:
> cntl |= CNTL_LCDBPP16_444;
> if (priv->variant->st_bitmux_control)
> diff --git a/drivers/gpu/drm/pl111/pl111_drv.c b/drivers/gpu/drm/pl111/pl111_drv.c
> index ac7b1d12a0f5..2175ac953795 100644
> --- a/drivers/gpu/drm/pl111/pl111_drv.c
> +++ b/drivers/gpu/drm/pl111/pl111_drv.c
> @@ -341,13 +341,9 @@ static void pl111_amba_shutdown(struct amba_device *amba_dev)
> * This early variant lacks the 565 and 444 pixel formats.
> */
> static const u32 pl110_pixel_formats[] = {
> - DRM_FORMAT_ABGR8888,
> DRM_FORMAT_XBGR8888,
> - DRM_FORMAT_ARGB8888,
> DRM_FORMAT_XRGB8888,
> - DRM_FORMAT_ABGR1555,
> DRM_FORMAT_XBGR1555,
> - DRM_FORMAT_ARGB1555,
> DRM_FORMAT_XRGB1555,
> };
>
> @@ -361,19 +357,13 @@ static const struct pl111_variant_data pl110_variant = {
>
> /* RealView, Versatile Express etc use this modern variant */
> static const u32 pl111_pixel_formats[] = {
> - DRM_FORMAT_ABGR8888,
> DRM_FORMAT_XBGR8888,
> - DRM_FORMAT_ARGB8888,
> DRM_FORMAT_XRGB8888,
> DRM_FORMAT_BGR565,
> DRM_FORMAT_RGB565,
> - DRM_FORMAT_ABGR1555,
> DRM_FORMAT_XBGR1555,
> - DRM_FORMAT_ARGB1555,
> DRM_FORMAT_XRGB1555,
> - DRM_FORMAT_ABGR4444,
> DRM_FORMAT_XBGR4444,
> - DRM_FORMAT_ARGB4444,
> DRM_FORMAT_XRGB4444,
> };
>
> @@ -387,19 +377,13 @@ static const struct pl111_variant_data pl111_variant = {
> static const u32 pl110_nomadik_pixel_formats[] = {
> DRM_FORMAT_RGB888,
> DRM_FORMAT_BGR888,
> - DRM_FORMAT_ABGR8888,
> DRM_FORMAT_XBGR8888,
> - DRM_FORMAT_ARGB8888,
> DRM_FORMAT_XRGB8888,
> DRM_FORMAT_BGR565,
> DRM_FORMAT_RGB565,
> - DRM_FORMAT_ABGR1555,
> DRM_FORMAT_XBGR1555,
> - DRM_FORMAT_ARGB1555,
> DRM_FORMAT_XRGB1555,
> - DRM_FORMAT_ABGR4444,
> DRM_FORMAT_XBGR4444,
> - DRM_FORMAT_ARGB4444,
> DRM_FORMAT_XRGB4444,
> };
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, (HRB 36809, AG Nürnberg)
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/pl111: Advertise no pixel blending
2026-08-25 10:54 [PATCH] drm/pl111: Advertise no pixel blending Roshan Kumar
` (5 preceding siblings ...)
2026-09-10 5:45 ` [PATCH v2] drm/pl111: drop alpha formats the hardware cannot scan out Roshan Kumar
@ 2026-09-10 19:25 ` Roshan Kumar
2026-09-11 6:33 ` Thomas Zimmermann
2026-09-11 12:58 ` Thomas Zimmermann
2026-09-10 19:25 ` [PATCH v3] drm/pl111: drop alpha formats the hardware cannot scan out Roshan Kumar
7 siblings, 2 replies; 23+ messages in thread
From: Roshan Kumar @ 2026-09-10 19:25 UTC (permalink / raw)
To: linusw, dri-devel
Cc: leandro.ribeiro, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, pimyn, linux-kernel
No physical PL111 hardware here; I tested under QEMU vexpress with
panic_on_warn, which is also how the syzkaller instance hits this.
On current master (7.3-rc2) the unpatched driver registers and
immediately warns: "[PLANE:35:plane-0] pixel format with alpha exposed
but blend mode not setup", which kills the boot with panic_on_warn.
With v3 below, the same boot registers pl111 with no warnings at all.
One note: 860e748bddcc is not in v7.2, so the splat only shows up on
master/7.3 and later.
v3 also removes the alpha formats from the board-specific tables in
pl111_versatile.c that the sashiko review caught v2 missing.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH v3] drm/pl111: drop alpha formats the hardware cannot scan out
2026-08-25 10:54 [PATCH] drm/pl111: Advertise no pixel blending Roshan Kumar
` (6 preceding siblings ...)
2026-09-10 19:25 ` [PATCH] drm/pl111: Advertise no pixel blending Roshan Kumar
@ 2026-09-10 19:25 ` Roshan Kumar
2026-09-10 19:34 ` sashiko-bot
` (2 more replies)
7 siblings, 3 replies; 23+ messages in thread
From: Roshan Kumar @ 2026-09-10 19:25 UTC (permalink / raw)
To: linusw, dri-devel
Cc: leandro.ribeiro, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, pimyn, linux-kernel
The PL110/PL111 controller scans out a single framebuffer and never
blends its alpha channel with anything. In every pixel-format table
each alpha-carrying entry (ARGB/ABGR in 8888, 1555 and 4444) maps to
exactly the same register configuration as its XRGB/XBGR counterpart,
so the alpha byte was never used by the hardware.
Commit 860e748bddcc ("drm: ensure blend mode supported if pixel format
with alpha exposed") added validation that warns when a plane exposes
alpha formats without a pixel blend mode property, and PL111 does exactly
that. With panic_on_warn enabled the warning prevents the syzkaller
vexpress-a15 manager from booting.
Drivers should not report formats they do not support, so remove the
alpha formats from all variant tables: the generic PL110, PL111 and
Nomadik tables in pl111_drv.c and the board-specific Integrator, IM-PD1,
Versatile and RealView/Versatile-Express tables in pl111_versatile.c,
plus the now dead case labels in the display setup and the Versatile
syscon connector switch, instead of advertising a blend mode property.
Behavior is unchanged for userspace that picks an XRGB/XBGR/RGB format;
alpha-picking clients fall back to the identical X variant.
Link: https://github.com/google/syzkaller/issues/7805
Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed")
Signed-off-by: Roshan Kumar <roshaen09@gmail.com>
Changes in v2: drop the alpha formats entirely instead of advertising a
DRM_MODE_BLEND_PIXEL_NONE property, per review feedback from Thomas
Zimmermann. Leandro's Reviewed-by from v1 is not carried as the
approach changed.
Changes in v3: v2 missed the board-specific variant tables in
pl111_versatile.c (Integrator, IM-PD1, Versatile, RealView and
Versatile Express), which still exposed alpha formats and would fall
through to the WARN_ONCE default in pl111_display_enable() on those
boards. Pointed out by the sashiko AI reviewer.
---
drivers/gpu/drm/pl111/pl111_display.c | 6 ------
drivers/gpu/drm/pl111/pl111_drv.c | 16 ----------------
drivers/gpu/drm/pl111/pl111_versatile.c | 18 ------------------
3 files changed, 40 deletions(-)
diff --git a/drivers/gpu/drm/pl111/pl111_display.c b/drivers/gpu/drm/pl111/pl111_display.c
index 5d10bc5fdf1f..e1b513d36c27 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -267,14 +267,12 @@ static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
if (priv->variant->st_bitmux_control)
cntl |= CNTL_ST_LCDBPP24_PACKED;
break;
- case DRM_FORMAT_ABGR8888:
case DRM_FORMAT_XBGR8888:
if (priv->variant->st_bitmux_control)
cntl |= CNTL_LCDBPP24 | CNTL_BGR;
else
cntl |= CNTL_LCDBPP24;
break;
- case DRM_FORMAT_ARGB8888:
case DRM_FORMAT_XRGB8888:
if (priv->variant->st_bitmux_control)
cntl |= CNTL_LCDBPP24;
@@ -297,13 +295,11 @@ static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
else
cntl |= CNTL_LCDBPP16_565 | CNTL_BGR;
break;
- case DRM_FORMAT_ABGR1555:
case DRM_FORMAT_XBGR1555:
cntl |= CNTL_LCDBPP16;
if (priv->variant->st_bitmux_control)
cntl |= CNTL_ST_1XBPP_5551 | CNTL_BGR;
break;
- case DRM_FORMAT_ARGB1555:
case DRM_FORMAT_XRGB1555:
cntl |= CNTL_LCDBPP16;
if (priv->variant->st_bitmux_control)
@@ -311,13 +307,11 @@ static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
else
cntl |= CNTL_BGR;
break;
- case DRM_FORMAT_ABGR4444:
case DRM_FORMAT_XBGR4444:
cntl |= CNTL_LCDBPP16_444;
if (priv->variant->st_bitmux_control)
cntl |= CNTL_ST_1XBPP_444 | CNTL_BGR;
break;
- case DRM_FORMAT_ARGB4444:
case DRM_FORMAT_XRGB4444:
cntl |= CNTL_LCDBPP16_444;
if (priv->variant->st_bitmux_control)
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c b/drivers/gpu/drm/pl111/pl111_drv.c
index ac7b1d12a0f5..2175ac953795 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -341,13 +341,9 @@ static void pl111_amba_shutdown(struct amba_device *amba_dev)
* This early variant lacks the 565 and 444 pixel formats.
*/
static const u32 pl110_pixel_formats[] = {
- DRM_FORMAT_ABGR8888,
DRM_FORMAT_XBGR8888,
- DRM_FORMAT_ARGB8888,
DRM_FORMAT_XRGB8888,
- DRM_FORMAT_ABGR1555,
DRM_FORMAT_XBGR1555,
- DRM_FORMAT_ARGB1555,
DRM_FORMAT_XRGB1555,
};
@@ -361,19 +357,13 @@ static const struct pl111_variant_data pl110_variant = {
/* RealView, Versatile Express etc use this modern variant */
static const u32 pl111_pixel_formats[] = {
- DRM_FORMAT_ABGR8888,
DRM_FORMAT_XBGR8888,
- DRM_FORMAT_ARGB8888,
DRM_FORMAT_XRGB8888,
DRM_FORMAT_BGR565,
DRM_FORMAT_RGB565,
- DRM_FORMAT_ABGR1555,
DRM_FORMAT_XBGR1555,
- DRM_FORMAT_ARGB1555,
DRM_FORMAT_XRGB1555,
- DRM_FORMAT_ABGR4444,
DRM_FORMAT_XBGR4444,
- DRM_FORMAT_ARGB4444,
DRM_FORMAT_XRGB4444,
};
@@ -387,19 +377,13 @@ static const struct pl111_variant_data pl111_variant = {
static const u32 pl110_nomadik_pixel_formats[] = {
DRM_FORMAT_RGB888,
DRM_FORMAT_BGR888,
- DRM_FORMAT_ABGR8888,
DRM_FORMAT_XBGR8888,
- DRM_FORMAT_ARGB8888,
DRM_FORMAT_XRGB8888,
DRM_FORMAT_BGR565,
DRM_FORMAT_RGB565,
- DRM_FORMAT_ABGR1555,
DRM_FORMAT_XBGR1555,
- DRM_FORMAT_ARGB1555,
DRM_FORMAT_XRGB1555,
- DRM_FORMAT_ABGR4444,
DRM_FORMAT_XBGR4444,
- DRM_FORMAT_ARGB4444,
DRM_FORMAT_XRGB4444,
};
diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c b/drivers/gpu/drm/pl111/pl111_versatile.c
index 0d8331a3909f..9a60f10231b1 100644
--- a/drivers/gpu/drm/pl111/pl111_versatile.c
+++ b/drivers/gpu/drm/pl111/pl111_versatile.c
@@ -209,9 +209,7 @@ static void pl111_versatile_enable(struct drm_device *drm, u32 format)
drm_info(drm, "enable Versatile CLCD connectors\n");
switch (format) {
- case DRM_FORMAT_ABGR8888:
case DRM_FORMAT_XBGR8888:
- case DRM_FORMAT_ARGB8888:
case DRM_FORMAT_XRGB8888:
val |= SYS_CLCD_MODE_888;
break;
@@ -221,9 +219,7 @@ static void pl111_versatile_enable(struct drm_device *drm, u32 format)
case DRM_FORMAT_RGB565:
val |= SYS_CLCD_MODE_565_B_LSB;
break;
- case DRM_FORMAT_ABGR1555:
case DRM_FORMAT_XBGR1555:
- case DRM_FORMAT_ARGB1555:
case DRM_FORMAT_XRGB1555:
val |= SYS_CLCD_MODE_5551;
break;
@@ -266,44 +262,30 @@ static void pl111_realview_clcd_enable(struct drm_device *drm, u32 format)
/* PL110 pixel formats for Integrator, vanilla PL110 */
static const u32 pl110_integrator_pixel_formats[] = {
- DRM_FORMAT_ABGR8888,
DRM_FORMAT_XBGR8888,
- DRM_FORMAT_ARGB8888,
DRM_FORMAT_XRGB8888,
- DRM_FORMAT_ABGR1555,
DRM_FORMAT_XBGR1555,
- DRM_FORMAT_ARGB1555,
DRM_FORMAT_XRGB1555,
};
/* Extended PL110 pixel formats for Integrator and Versatile */
static const u32 pl110_versatile_pixel_formats[] = {
- DRM_FORMAT_ABGR8888,
DRM_FORMAT_XBGR8888,
- DRM_FORMAT_ARGB8888,
DRM_FORMAT_XRGB8888,
DRM_FORMAT_BGR565, /* Uses external PLD */
DRM_FORMAT_RGB565, /* Uses external PLD */
- DRM_FORMAT_ABGR1555,
DRM_FORMAT_XBGR1555,
- DRM_FORMAT_ARGB1555,
DRM_FORMAT_XRGB1555,
};
static const u32 pl111_realview_pixel_formats[] = {
- DRM_FORMAT_ABGR8888,
DRM_FORMAT_XBGR8888,
- DRM_FORMAT_ARGB8888,
DRM_FORMAT_XRGB8888,
DRM_FORMAT_BGR565,
DRM_FORMAT_RGB565,
- DRM_FORMAT_ABGR1555,
DRM_FORMAT_XBGR1555,
- DRM_FORMAT_ARGB1555,
DRM_FORMAT_XRGB1555,
- DRM_FORMAT_ABGR4444,
DRM_FORMAT_XBGR4444,
- DRM_FORMAT_ARGB4444,
DRM_FORMAT_XRGB4444,
};
--
2.43.0
^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH v3] drm/pl111: drop alpha formats the hardware cannot scan out
2026-09-10 19:25 ` [PATCH v3] drm/pl111: drop alpha formats the hardware cannot scan out Roshan Kumar
@ 2026-09-10 19:34 ` sashiko-bot
2026-09-11 6:41 ` Thomas Zimmermann
2026-09-11 18:00 ` Linus Walleij
2 siblings, 0 replies; 23+ messages in thread
From: sashiko-bot @ 2026-09-10 19:34 UTC (permalink / raw)
To: Roshan Kumar; +Cc: dri-devel
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Sleeping function msleep() is called from CRTC atomic enable/disable callbacks, which execute in atomic context.
--
commit a2121d13cc86548614d1273c2a018211978e598e
Author: Roshan Kumar <roshaen09@gmail.com>
drm/pl111: drop alpha formats the hardware cannot scan out
The PL110/PL111 controller does not support alpha blending, so exposing alpha
formats causes issues when pixel blend mode properties are expected. This
patch drops alpha formats from all variant tables and format checking
switches so that alpha-picking clients fall back to XRGB/XBGR/RGB formats
instead.
Link: https://github.com/google/syzkaller/issues/7805
> diff --git a/drivers/gpu/drm/pl111/pl111_display.c b/drivers/gpu/drm/pl111/pl111_display.c
> index 5d10bc5fdf1f6..e1b513d36c27c 100644
> --- a/drivers/gpu/drm/pl111/pl111_display.c
> +++ b/drivers/gpu/drm/pl111/pl111_display.c
[ ... ]
> @@ -311,13 +307,11 @@ static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
> else
> cntl |= CNTL_BGR;
> break;
> - case DRM_FORMAT_ABGR4444:
> case DRM_FORMAT_XBGR4444:
> cntl |= CNTL_LCDBPP16_444;
> if (priv->variant->st_bitmux_control)
> cntl |= CNTL_ST_1XBPP_444 | CNTL_BGR;
> break;
> - case DRM_FORMAT_ARGB4444:
> case DRM_FORMAT_XRGB4444:
> cntl |= CNTL_LCDBPP16_444;
> if (priv->variant->st_bitmux_control)
[Severity: High]
This is a pre-existing issue, but I noticed that msleep() is called
further down in pl111_display_enable():
/*
* We expect this delay to stabilize the contrast
* voltage Vee as stipulated by the manual
*/
msleep(20);
There is also a similar msleep(20) call in pl111_display_disable()
in the same file (drivers/gpu/drm/pl111/pl111_display.c).
Since pl111_display_enable() and pl111_display_disable() serve as the
CRTC atomic enable and disable callbacks, they execute in atomic context
where sleeping is forbidden.
Can calling msleep() in these paths cause kernel warnings, system
instability, or potential deadlocks during modeset operations?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260910192526.137057-1-roshaen09@gmail.com?part=1
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/pl111: Advertise no pixel blending
2026-09-10 19:25 ` [PATCH] drm/pl111: Advertise no pixel blending Roshan Kumar
@ 2026-09-11 6:33 ` Thomas Zimmermann
2026-09-11 12:58 ` Thomas Zimmermann
1 sibling, 0 replies; 23+ messages in thread
From: Thomas Zimmermann @ 2026-09-11 6:33 UTC (permalink / raw)
To: Roshan Kumar, linusw, dri-devel
Cc: leandro.ribeiro, maarten.lankhorst, mripard, airlied, simona,
pimyn, linux-kernel
Hi
Am 10.09.26 um 21:25 schrieb Roshan Kumar:
> No physical PL111 hardware here; I tested under QEMU vexpress with
> panic_on_warn, which is also how the syzkaller instance hits this.
Thanks a lot for this info. I'll try to set up such a system so I can
test the driver myself.
Best regards
Thomas
>
> On current master (7.3-rc2) the unpatched driver registers and
> immediately warns: "[PLANE:35:plane-0] pixel format with alpha exposed
> but blend mode not setup", which kills the boot with panic_on_warn.
> With v3 below, the same boot registers pl111 with no warnings at all.
> One note: 860e748bddcc is not in v7.2, so the splat only shows up on
> master/7.3 and later.
>
> v3 also removes the alpha formats from the board-specific tables in
> pl111_versatile.c that the sashiko review caught v2 missing.
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, (HRB 36809, AG Nürnberg)
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v3] drm/pl111: drop alpha formats the hardware cannot scan out
2026-09-10 19:25 ` [PATCH v3] drm/pl111: drop alpha formats the hardware cannot scan out Roshan Kumar
2026-09-10 19:34 ` sashiko-bot
@ 2026-09-11 6:41 ` Thomas Zimmermann
2026-09-11 18:00 ` Linus Walleij
2 siblings, 0 replies; 23+ messages in thread
From: Thomas Zimmermann @ 2026-09-11 6:41 UTC (permalink / raw)
To: Roshan Kumar, linusw, dri-devel
Cc: leandro.ribeiro, maarten.lankhorst, mripard, airlied, simona,
pimyn, linux-kernel
Am 10.09.26 um 21:25 schrieb Roshan Kumar:
> The PL110/PL111 controller scans out a single framebuffer and never
> blends its alpha channel with anything. In every pixel-format table
> each alpha-carrying entry (ARGB/ABGR in 8888, 1555 and 4444) maps to
> exactly the same register configuration as its XRGB/XBGR counterpart,
> so the alpha byte was never used by the hardware.
>
> Commit 860e748bddcc ("drm: ensure blend mode supported if pixel format
> with alpha exposed") added validation that warns when a plane exposes
> alpha formats without a pixel blend mode property, and PL111 does exactly
> that. With panic_on_warn enabled the warning prevents the syzkaller
> vexpress-a15 manager from booting.
>
> Drivers should not report formats they do not support, so remove the
> alpha formats from all variant tables: the generic PL110, PL111 and
> Nomadik tables in pl111_drv.c and the board-specific Integrator, IM-PD1,
> Versatile and RealView/Versatile-Express tables in pl111_versatile.c,
> plus the now dead case labels in the display setup and the Versatile
> syscon connector switch, instead of advertising a blend mode property.
> Behavior is unchanged for userspace that picks an XRGB/XBGR/RGB format;
> alpha-picking clients fall back to the identical X variant.
>
> Link: https://github.com/google/syzkaller/issues/7805
> Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed")
> Signed-off-by: Roshan Kumar <roshaen09@gmail.com>
The tags always go last, but we can fix this when we merge the patch.
Thanks for fixing the issue.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
>
> Changes in v2: drop the alpha formats entirely instead of advertising a
> DRM_MODE_BLEND_PIXEL_NONE property, per review feedback from Thomas
> Zimmermann. Leandro's Reviewed-by from v1 is not carried as the
> approach changed.
>
> Changes in v3: v2 missed the board-specific variant tables in
> pl111_versatile.c (Integrator, IM-PD1, Versatile, RealView and
> Versatile Express), which still exposed alpha formats and would fall
> through to the WARN_ONCE default in pl111_display_enable() on those
> boards. Pointed out by the sashiko AI reviewer.
> ---
> drivers/gpu/drm/pl111/pl111_display.c | 6 ------
> drivers/gpu/drm/pl111/pl111_drv.c | 16 ----------------
> drivers/gpu/drm/pl111/pl111_versatile.c | 18 ------------------
> 3 files changed, 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/pl111/pl111_display.c b/drivers/gpu/drm/pl111/pl111_display.c
> index 5d10bc5fdf1f..e1b513d36c27 100644
> --- a/drivers/gpu/drm/pl111/pl111_display.c
> +++ b/drivers/gpu/drm/pl111/pl111_display.c
> @@ -267,14 +267,12 @@ static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
> if (priv->variant->st_bitmux_control)
> cntl |= CNTL_ST_LCDBPP24_PACKED;
> break;
> - case DRM_FORMAT_ABGR8888:
> case DRM_FORMAT_XBGR8888:
> if (priv->variant->st_bitmux_control)
> cntl |= CNTL_LCDBPP24 | CNTL_BGR;
> else
> cntl |= CNTL_LCDBPP24;
> break;
> - case DRM_FORMAT_ARGB8888:
> case DRM_FORMAT_XRGB8888:
> if (priv->variant->st_bitmux_control)
> cntl |= CNTL_LCDBPP24;
> @@ -297,13 +295,11 @@ static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
> else
> cntl |= CNTL_LCDBPP16_565 | CNTL_BGR;
> break;
> - case DRM_FORMAT_ABGR1555:
> case DRM_FORMAT_XBGR1555:
> cntl |= CNTL_LCDBPP16;
> if (priv->variant->st_bitmux_control)
> cntl |= CNTL_ST_1XBPP_5551 | CNTL_BGR;
> break;
> - case DRM_FORMAT_ARGB1555:
> case DRM_FORMAT_XRGB1555:
> cntl |= CNTL_LCDBPP16;
> if (priv->variant->st_bitmux_control)
> @@ -311,13 +307,11 @@ static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
> else
> cntl |= CNTL_BGR;
> break;
> - case DRM_FORMAT_ABGR4444:
> case DRM_FORMAT_XBGR4444:
> cntl |= CNTL_LCDBPP16_444;
> if (priv->variant->st_bitmux_control)
> cntl |= CNTL_ST_1XBPP_444 | CNTL_BGR;
> break;
> - case DRM_FORMAT_ARGB4444:
> case DRM_FORMAT_XRGB4444:
> cntl |= CNTL_LCDBPP16_444;
> if (priv->variant->st_bitmux_control)
> diff --git a/drivers/gpu/drm/pl111/pl111_drv.c b/drivers/gpu/drm/pl111/pl111_drv.c
> index ac7b1d12a0f5..2175ac953795 100644
> --- a/drivers/gpu/drm/pl111/pl111_drv.c
> +++ b/drivers/gpu/drm/pl111/pl111_drv.c
> @@ -341,13 +341,9 @@ static void pl111_amba_shutdown(struct amba_device *amba_dev)
> * This early variant lacks the 565 and 444 pixel formats.
> */
> static const u32 pl110_pixel_formats[] = {
> - DRM_FORMAT_ABGR8888,
> DRM_FORMAT_XBGR8888,
> - DRM_FORMAT_ARGB8888,
> DRM_FORMAT_XRGB8888,
> - DRM_FORMAT_ABGR1555,
> DRM_FORMAT_XBGR1555,
> - DRM_FORMAT_ARGB1555,
> DRM_FORMAT_XRGB1555,
> };
>
> @@ -361,19 +357,13 @@ static const struct pl111_variant_data pl110_variant = {
>
> /* RealView, Versatile Express etc use this modern variant */
> static const u32 pl111_pixel_formats[] = {
> - DRM_FORMAT_ABGR8888,
> DRM_FORMAT_XBGR8888,
> - DRM_FORMAT_ARGB8888,
> DRM_FORMAT_XRGB8888,
> DRM_FORMAT_BGR565,
> DRM_FORMAT_RGB565,
> - DRM_FORMAT_ABGR1555,
> DRM_FORMAT_XBGR1555,
> - DRM_FORMAT_ARGB1555,
> DRM_FORMAT_XRGB1555,
> - DRM_FORMAT_ABGR4444,
> DRM_FORMAT_XBGR4444,
> - DRM_FORMAT_ARGB4444,
> DRM_FORMAT_XRGB4444,
> };
>
> @@ -387,19 +377,13 @@ static const struct pl111_variant_data pl111_variant = {
> static const u32 pl110_nomadik_pixel_formats[] = {
> DRM_FORMAT_RGB888,
> DRM_FORMAT_BGR888,
> - DRM_FORMAT_ABGR8888,
> DRM_FORMAT_XBGR8888,
> - DRM_FORMAT_ARGB8888,
> DRM_FORMAT_XRGB8888,
> DRM_FORMAT_BGR565,
> DRM_FORMAT_RGB565,
> - DRM_FORMAT_ABGR1555,
> DRM_FORMAT_XBGR1555,
> - DRM_FORMAT_ARGB1555,
> DRM_FORMAT_XRGB1555,
> - DRM_FORMAT_ABGR4444,
> DRM_FORMAT_XBGR4444,
> - DRM_FORMAT_ARGB4444,
> DRM_FORMAT_XRGB4444,
> };
>
> diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c b/drivers/gpu/drm/pl111/pl111_versatile.c
> index 0d8331a3909f..9a60f10231b1 100644
> --- a/drivers/gpu/drm/pl111/pl111_versatile.c
> +++ b/drivers/gpu/drm/pl111/pl111_versatile.c
> @@ -209,9 +209,7 @@ static void pl111_versatile_enable(struct drm_device *drm, u32 format)
> drm_info(drm, "enable Versatile CLCD connectors\n");
>
> switch (format) {
> - case DRM_FORMAT_ABGR8888:
> case DRM_FORMAT_XBGR8888:
> - case DRM_FORMAT_ARGB8888:
> case DRM_FORMAT_XRGB8888:
> val |= SYS_CLCD_MODE_888;
> break;
> @@ -221,9 +219,7 @@ static void pl111_versatile_enable(struct drm_device *drm, u32 format)
> case DRM_FORMAT_RGB565:
> val |= SYS_CLCD_MODE_565_B_LSB;
> break;
> - case DRM_FORMAT_ABGR1555:
> case DRM_FORMAT_XBGR1555:
> - case DRM_FORMAT_ARGB1555:
> case DRM_FORMAT_XRGB1555:
> val |= SYS_CLCD_MODE_5551;
> break;
> @@ -266,44 +262,30 @@ static void pl111_realview_clcd_enable(struct drm_device *drm, u32 format)
>
> /* PL110 pixel formats for Integrator, vanilla PL110 */
> static const u32 pl110_integrator_pixel_formats[] = {
> - DRM_FORMAT_ABGR8888,
> DRM_FORMAT_XBGR8888,
> - DRM_FORMAT_ARGB8888,
> DRM_FORMAT_XRGB8888,
> - DRM_FORMAT_ABGR1555,
> DRM_FORMAT_XBGR1555,
> - DRM_FORMAT_ARGB1555,
> DRM_FORMAT_XRGB1555,
> };
>
> /* Extended PL110 pixel formats for Integrator and Versatile */
> static const u32 pl110_versatile_pixel_formats[] = {
> - DRM_FORMAT_ABGR8888,
> DRM_FORMAT_XBGR8888,
> - DRM_FORMAT_ARGB8888,
> DRM_FORMAT_XRGB8888,
> DRM_FORMAT_BGR565, /* Uses external PLD */
> DRM_FORMAT_RGB565, /* Uses external PLD */
> - DRM_FORMAT_ABGR1555,
> DRM_FORMAT_XBGR1555,
> - DRM_FORMAT_ARGB1555,
> DRM_FORMAT_XRGB1555,
> };
>
> static const u32 pl111_realview_pixel_formats[] = {
> - DRM_FORMAT_ABGR8888,
> DRM_FORMAT_XBGR8888,
> - DRM_FORMAT_ARGB8888,
> DRM_FORMAT_XRGB8888,
> DRM_FORMAT_BGR565,
> DRM_FORMAT_RGB565,
> - DRM_FORMAT_ABGR1555,
> DRM_FORMAT_XBGR1555,
> - DRM_FORMAT_ARGB1555,
> DRM_FORMAT_XRGB1555,
> - DRM_FORMAT_ABGR4444,
> DRM_FORMAT_XBGR4444,
> - DRM_FORMAT_ARGB4444,
> DRM_FORMAT_XRGB4444,
> };
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, (HRB 36809, AG Nürnberg)
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/pl111: Advertise no pixel blending
2026-09-10 19:25 ` [PATCH] drm/pl111: Advertise no pixel blending Roshan Kumar
2026-09-11 6:33 ` Thomas Zimmermann
@ 2026-09-11 12:58 ` Thomas Zimmermann
2026-09-11 18:07 ` Roshan Kumar
1 sibling, 1 reply; 23+ messages in thread
From: Thomas Zimmermann @ 2026-09-11 12:58 UTC (permalink / raw)
To: Roshan Kumar, linusw, dri-devel, Ze Huang
Cc: leandro.ribeiro, maarten.lankhorst, mripard, airlied, simona,
pimyn, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]
Hi
Am 10.09.26 um 21:25 schrieb Roshan Kumar:
> No physical PL111 hardware here; I tested under QEMU vexpress with
> panic_on_warn, which is also how the syzkaller instance hits this.
Or since you have the system set up already, could you test a patch for
the pl111 driver? It reworks some internals and could use some basic
testing before getting merged. Patch file is attached. Thanks!
Best regards
Thomas
>
> On current master (7.3-rc2) the unpatched driver registers and
> immediately warns: "[PLANE:35:plane-0] pixel format with alpha exposed
> but blend mode not setup", which kills the boot with panic_on_warn.
> With v3 below, the same boot registers pl111 with no warnings at all.
> One note: 860e748bddcc is not in v7.2, so the splat only shows up on
> master/7.3 and later.
>
> v3 also removes the alpha formats from the board-specific tables in
> pl111_versatile.c that the sashiko review caught v2 missing.
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, (HRB 36809, AG Nürnberg)
[-- Attachment #2: 0001-drm-pl111-replace-struct-drm_simple_display_pipe-wit.patch --]
[-- Type: text/x-patch, Size: 12098 bytes --]
From fe49e0da40ca703d13c33395b047da9c1ccaa731 Mon Sep 17 00:00:00 2001
From: Ze Huang <ze.huang@oss.qualcomm.com>
Date: Mon, 27 Jul 2026 03:45:17 +0800
Subject: [PATCH] drm/pl111: replace struct drm_simple_display_pipe with
regular atomic helpers
Replace the PL111 simple display pipe with explicit plane, CRTC and
encoder objects.
Move the existing timing, format and pitch validation into explicit
atomic check paths. Use commit-local plane state in the CRTC enable path
when reading framebuffer format state.
Move page-flip event handling to the CRTC commit path.
Signed-off-by: Ze Huang <ze.huang@oss.qualcomm.com>
---
drivers/gpu/drm/pl111/pl111_display.c | 199 +++++++++++++++++++-------
drivers/gpu/drm/pl111/pl111_drm.h | 5 +-
drivers/gpu/drm/pl111/pl111_drv.c | 3 +-
3 files changed, 148 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/pl111/pl111_display.c b/drivers/gpu/drm/pl111/pl111_display.c
index 5d10bc5fdf1f..deac1dee7838 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -15,6 +15,7 @@
#include <linux/media-bus-format.h>
#include <linux/of_graph.h>
+#include <drm/drm_atomic_helper.h>
#include <drm/drm_fb_dma_helper.h>
#include <drm/drm_fourcc.h>
#include <drm/drm_framebuffer.h>
@@ -37,7 +38,7 @@ irqreturn_t pl111_irq(int irq, void *data)
return IRQ_NONE;
if (irq_stat & CLCD_IRQ_NEXTBASE_UPDATE) {
- drm_crtc_handle_vblank(&priv->pipe.crtc);
+ drm_crtc_handle_vblank(&priv->crtc);
status = IRQ_HANDLED;
}
@@ -49,10 +50,10 @@ irqreturn_t pl111_irq(int irq, void *data)
}
static enum drm_mode_status
-pl111_mode_valid(struct drm_simple_display_pipe *pipe,
- const struct drm_display_mode *mode)
+pl111_crtc_helper_mode_valid(struct drm_crtc *crtc,
+ const struct drm_display_mode *mode)
{
- struct drm_device *drm = pipe->crtc.dev;
+ struct drm_device *drm = crtc->dev;
struct pl111_drm_dev_private *priv = drm->dev_private;
u32 cpp = DIV_ROUND_UP(priv->variant->fb_depth, 8);
u64 bw;
@@ -83,13 +84,34 @@ pl111_mode_valid(struct drm_simple_display_pipe *pipe,
return MODE_OK;
}
-static int pl111_display_check(struct drm_simple_display_pipe *pipe,
- struct drm_plane_state *pstate,
- struct drm_crtc_state *cstate)
+static int pl111_plane_helper_atomic_check(struct drm_plane *plane,
+ struct drm_atomic_commit *commit)
{
- const struct drm_display_mode *mode = &cstate->mode;
- struct drm_framebuffer *old_fb = pipe->plane.state->fb;
+ struct drm_plane_state *pstate = drm_atomic_get_new_plane_state(commit, plane);
+ struct drm_plane_state *old_pstate = drm_atomic_get_old_plane_state(commit, plane);
+ struct drm_crtc_state *cstate = NULL;
+ const struct drm_display_mode *mode;
+ struct drm_framebuffer *old_fb = old_pstate->fb;
struct drm_framebuffer *fb = pstate->fb;
+ int ret;
+
+ if (pstate->crtc) {
+ cstate = drm_atomic_get_crtc_state(commit, pstate->crtc);
+ if (IS_ERR(cstate))
+ return PTR_ERR(cstate);
+ }
+
+ ret = drm_atomic_helper_check_plane_state(pstate, cstate,
+ DRM_PLANE_NO_SCALING,
+ DRM_PLANE_NO_SCALING,
+ false, false);
+ if (ret)
+ return ret;
+
+ if (!pstate->visible)
+ return 0;
+
+ mode = &cstate->mode;
if (mode->hdisplay % 16)
return -EINVAL;
@@ -117,16 +139,15 @@ static int pl111_display_check(struct drm_simple_display_pipe *pipe,
return 0;
}
-static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
- struct drm_crtc_state *cstate,
- struct drm_plane_state *plane_state)
+static void pl111_crtc_helper_atomic_enable(struct drm_crtc *crtc,
+ struct drm_atomic_commit *commit)
{
- struct drm_crtc *crtc = &pipe->crtc;
- struct drm_plane *plane = &pipe->plane;
struct drm_device *drm = crtc->dev;
struct pl111_drm_dev_private *priv = drm->dev_private;
+ struct drm_crtc_state *cstate = drm_atomic_get_new_crtc_state(commit, crtc);
+ struct drm_plane_state *plane_state = drm_atomic_get_new_plane_state(commit, &priv->plane);
const struct drm_display_mode *mode = &cstate->mode;
- struct drm_framebuffer *fb = plane->state->fb;
+ struct drm_framebuffer *fb = plane_state->fb;
struct drm_connector *connector = priv->connector;
struct drm_bridge *bridge = priv->bridge;
bool grayscale = false;
@@ -355,9 +376,9 @@ static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
drm_crtc_vblank_on(crtc);
}
-static void pl111_display_disable(struct drm_simple_display_pipe *pipe)
+static void pl111_crtc_helper_atomic_disable(struct drm_crtc *crtc,
+ struct drm_atomic_commit *commit)
{
- struct drm_crtc *crtc = &pipe->crtc;
struct drm_device *drm = crtc->dev;
struct pl111_drm_dev_private *priv = drm->dev_private;
u32 cntl;
@@ -387,38 +408,43 @@ static void pl111_display_disable(struct drm_simple_display_pipe *pipe)
clk_disable_unprepare(priv->clk);
}
-static void pl111_display_update(struct drm_simple_display_pipe *pipe,
- struct drm_plane_state *old_pstate)
+static void pl111_plane_helper_atomic_update(struct drm_plane *plane,
+ struct drm_atomic_commit *commit)
{
- struct drm_crtc *crtc = &pipe->crtc;
- struct drm_device *drm = crtc->dev;
+ struct drm_device *drm = plane->dev;
struct pl111_drm_dev_private *priv = drm->dev_private;
- struct drm_pending_vblank_event *event = crtc->state->event;
- struct drm_plane *plane = &pipe->plane;
- struct drm_plane_state *pstate = plane->state;
+ struct drm_plane_state *pstate = drm_atomic_get_new_plane_state(commit, plane);
struct drm_framebuffer *fb = pstate->fb;
- if (fb) {
- u32 addr = drm_fb_dma_get_gem_addr(fb, pstate, 0);
+ if (!fb)
+ return;
- writel(addr, priv->regs + CLCD_UBAS);
- }
+ u32 addr = drm_fb_dma_get_gem_addr(fb, pstate, 0);
- if (event) {
- crtc->state->event = NULL;
+ writel(addr, priv->regs + CLCD_UBAS);
+}
- spin_lock_irq(&crtc->dev->event_lock);
- if (crtc->state->active && drm_crtc_vblank_get(crtc) == 0)
- drm_crtc_arm_vblank_event(crtc, event);
- else
- drm_crtc_send_vblank_event(crtc, event);
- spin_unlock_irq(&crtc->dev->event_lock);
- }
+static void pl111_crtc_helper_atomic_flush(struct drm_crtc *crtc,
+ struct drm_atomic_commit *commit)
+{
+ struct drm_crtc_state *cstate = drm_atomic_get_new_crtc_state(commit, crtc);
+ struct drm_pending_vblank_event *event = cstate->event;
+
+ if (!event)
+ return;
+
+ cstate->event = NULL;
+
+ spin_lock_irq(&crtc->dev->event_lock);
+ if (cstate->active && drm_crtc_vblank_get(crtc) == 0)
+ drm_crtc_arm_vblank_event(crtc, event);
+ else
+ drm_crtc_send_vblank_event(crtc, event);
+ spin_unlock_irq(&crtc->dev->event_lock);
}
-static int pl111_display_enable_vblank(struct drm_simple_display_pipe *pipe)
+static int pl111_display_enable_vblank(struct drm_crtc *crtc)
{
- struct drm_crtc *crtc = &pipe->crtc;
struct drm_device *drm = crtc->dev;
struct pl111_drm_dev_private *priv = drm->dev_private;
@@ -427,21 +453,62 @@ static int pl111_display_enable_vblank(struct drm_simple_display_pipe *pipe)
return 0;
}
-static void pl111_display_disable_vblank(struct drm_simple_display_pipe *pipe)
+static void pl111_display_disable_vblank(struct drm_crtc *crtc)
{
- struct drm_crtc *crtc = &pipe->crtc;
struct drm_device *drm = crtc->dev;
struct pl111_drm_dev_private *priv = drm->dev_private;
writel(0, priv->regs + priv->ienb);
}
-static struct drm_simple_display_pipe_funcs pl111_display_funcs = {
- .mode_valid = pl111_mode_valid,
- .check = pl111_display_check,
- .enable = pl111_display_enable,
- .disable = pl111_display_disable,
- .update = pl111_display_update,
+static int pl111_crtc_helper_atomic_check(struct drm_crtc *crtc, struct drm_atomic_commit *commit)
+{
+ struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(commit, crtc);
+ int ret;
+
+ if (crtc_state->enable) {
+ ret = drm_atomic_helper_check_crtc_primary_plane(crtc_state);
+ if (ret)
+ return ret;
+ }
+
+ return drm_atomic_add_affected_planes(commit, crtc);
+}
+
+static struct drm_crtc_funcs pl111_crtc_funcs = {
+ .reset = drm_atomic_helper_crtc_reset,
+ .destroy = drm_crtc_cleanup,
+ .set_config = drm_atomic_helper_set_config,
+ .page_flip = drm_atomic_helper_page_flip,
+ .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
+};
+
+static const struct drm_crtc_helper_funcs pl111_crtc_helper_funcs = {
+ .mode_valid = pl111_crtc_helper_mode_valid,
+ .atomic_check = pl111_crtc_helper_atomic_check,
+ .atomic_enable = pl111_crtc_helper_atomic_enable,
+ .atomic_disable = pl111_crtc_helper_atomic_disable,
+ .atomic_flush = pl111_crtc_helper_atomic_flush,
+};
+
+static const struct drm_plane_funcs pl111_plane_funcs = {
+ .update_plane = drm_atomic_helper_update_plane,
+ .disable_plane = drm_atomic_helper_disable_plane,
+ .reset = drm_atomic_helper_plane_reset,
+ .destroy = drm_plane_cleanup,
+ .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
+};
+
+static const struct drm_plane_helper_funcs pl111_plane_helper_funcs = {
+ .prepare_fb = drm_gem_plane_helper_prepare_fb,
+ .atomic_check = pl111_plane_helper_atomic_check,
+ .atomic_update = pl111_plane_helper_atomic_update,
+};
+
+static const struct drm_encoder_funcs pl111_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
};
static int pl111_clk_div_choose_div(struct clk_hw *hw, unsigned long rate,
@@ -583,18 +650,40 @@ int pl111_display_init(struct drm_device *drm)
return ret;
if (!priv->variant->broken_vblank) {
- pl111_display_funcs.enable_vblank = pl111_display_enable_vblank;
- pl111_display_funcs.disable_vblank = pl111_display_disable_vblank;
+ pl111_crtc_funcs.enable_vblank = pl111_display_enable_vblank;
+ pl111_crtc_funcs.disable_vblank = pl111_display_disable_vblank;
}
- ret = drm_simple_display_pipe_init(drm, &priv->pipe,
- &pl111_display_funcs,
- priv->variant->formats,
- priv->variant->nformats,
- NULL,
- priv->connector);
+ ret = drm_universal_plane_init(drm, &priv->plane, 0,
+ &pl111_plane_funcs,
+ priv->variant->formats,
+ priv->variant->nformats,
+ NULL, DRM_PLANE_TYPE_PRIMARY, NULL);
+ if (ret)
+ return ret;
+
+ drm_plane_helper_add(&priv->plane, &pl111_plane_helper_funcs);
+
+ ret = drm_crtc_init_with_planes(drm, &priv->crtc, &priv->plane,
+ NULL, &pl111_crtc_funcs, NULL);
+ if (ret)
+ return ret;
+
+ drm_crtc_helper_add(&priv->crtc, &pl111_crtc_helper_funcs);
+
+ ret = drm_encoder_init(drm, &priv->encoder, &pl111_encoder_funcs,
+ DRM_MODE_ENCODER_NONE, NULL);
if (ret)
return ret;
+ priv->encoder.possible_crtcs = drm_crtc_mask(&priv->crtc);
+
+ if (priv->connector) {
+ ret = drm_connector_attach_encoder(priv->connector,
+ &priv->encoder);
+ if (ret)
+ return ret;
+ }
+
return 0;
}
diff --git a/drivers/gpu/drm/pl111/pl111_drm.h b/drivers/gpu/drm/pl111/pl111_drm.h
index d1fe756444ee..ec92a5a180a8 100644
--- a/drivers/gpu/drm/pl111/pl111_drm.h
+++ b/drivers/gpu/drm/pl111/pl111_drm.h
@@ -21,7 +21,6 @@
#include <drm/drm_encoder.h>
#include <drm/drm_gem.h>
#include <drm/drm_panel.h>
-#include <drm/drm_simple_kms_helper.h>
/*
* CLCD Controller Internal Register addresses
@@ -135,7 +134,9 @@ struct pl111_drm_dev_private {
struct drm_connector *connector;
struct drm_panel *panel;
struct drm_bridge *bridge;
- struct drm_simple_display_pipe pipe;
+ struct drm_plane plane;
+ struct drm_crtc crtc;
+ struct drm_encoder encoder;
void *regs;
u32 memory_bw;
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c b/drivers/gpu/drm/pl111/pl111_drv.c
index 8ec659b3c08e..e83eb95c8414 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -169,8 +169,7 @@ static int pl111_modeset_init(struct drm_device *dev)
goto out_bridge;
}
- ret = drm_simple_display_pipe_attach_bridge(&priv->pipe,
- bridge);
+ ret = drm_bridge_attach(&priv->encoder, bridge, NULL, 0);
if (ret)
return ret;
--
2.55.0
^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/pl111: Advertise no pixel blending
2026-09-09 8:16 ` Thomas Zimmermann
@ 2026-09-11 13:24 ` Linus Walleij
2026-09-11 13:26 ` Linus Walleij
0 siblings, 1 reply; 23+ messages in thread
From: Linus Walleij @ 2026-09-11 13:24 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Roshan Kumar, dri-devel, leandro.ribeiro, maarten.lankhorst,
mripard, airlied, simona, pimyn, linux-kernel
On Wed, Sep 9, 2026 at 10:16 AM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> > The PL110/PL111 controller scans out a single framebuffer and does not
> > blend its alpha channel with a background. Advertise
> > DRM_MODE_BLEND_PIXEL_NONE to match the existing hardware behavior.
>
> Why does the driver report ARGB formats in the first place. I'm looking
> at the code at [1] and I don't see any difference to XRGB. Unless I'm
> missing something, please remove ARGB formats from this driver instead.
> Drivers should not report formats they don't support.
This should be the TRM for PL111:
https://support.arm.com/documentation/ddi0293/c/?lang=en
I checked it and indeed the ARGB* should be search/replaced with
XRGB everywhere.
Shall I propose a patch?
I also have the actual hardware so I can test it properly.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/pl111: Advertise no pixel blending
2026-09-11 13:24 ` Linus Walleij
@ 2026-09-11 13:26 ` Linus Walleij
0 siblings, 0 replies; 23+ messages in thread
From: Linus Walleij @ 2026-09-11 13:26 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Roshan Kumar, dri-devel, leandro.ribeiro, maarten.lankhorst,
mripard, airlied, simona, pimyn, linux-kernel
On Fri, Sep 11, 2026 at 3:24 PM Linus Walleij <linusw@kernel.org> wrote:
> On Wed, Sep 9, 2026 at 10:16 AM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>
> > > The PL110/PL111 controller scans out a single framebuffer and does not
> > > blend its alpha channel with a background. Advertise
> > > DRM_MODE_BLEND_PIXEL_NONE to match the existing hardware behavior.
> >
> > Why does the driver report ARGB formats in the first place. I'm looking
> > at the code at [1] and I don't see any difference to XRGB. Unless I'm
> > missing something, please remove ARGB formats from this driver instead.
> > Drivers should not report formats they don't support.
>
> This should be the TRM for PL111:
> https://support.arm.com/documentation/ddi0293/c/?lang=en
>
> I checked it and indeed the ARGB* should be search/replaced with
> XRGB everywhere.
>
> Shall I propose a patch?
>
> I also have the actual hardware so I can test it properly.
Ah I see Roshan has already sent a patch (sorry for the confusion).
I will review/test that patch.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v3] drm/pl111: drop alpha formats the hardware cannot scan out
2026-09-10 19:25 ` [PATCH v3] drm/pl111: drop alpha formats the hardware cannot scan out Roshan Kumar
2026-09-10 19:34 ` sashiko-bot
2026-09-11 6:41 ` Thomas Zimmermann
@ 2026-09-11 18:00 ` Linus Walleij
2 siblings, 0 replies; 23+ messages in thread
From: Linus Walleij @ 2026-09-11 18:00 UTC (permalink / raw)
To: Roshan Kumar
Cc: dri-devel, leandro.ribeiro, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, pimyn, linux-kernel
On Thu, Sep 10, 2026 at 9:25 PM Roshan Kumar <roshaen09@gmail.com> wrote:
> The PL110/PL111 controller scans out a single framebuffer and never
> blends its alpha channel with anything. In every pixel-format table
> each alpha-carrying entry (ARGB/ABGR in 8888, 1555 and 4444) maps to
> exactly the same register configuration as its XRGB/XBGR counterpart,
> so the alpha byte was never used by the hardware.
>
> Commit 860e748bddcc ("drm: ensure blend mode supported if pixel format
> with alpha exposed") added validation that warns when a plane exposes
> alpha formats without a pixel blend mode property, and PL111 does exactly
> that. With panic_on_warn enabled the warning prevents the syzkaller
> vexpress-a15 manager from booting.
>
> Drivers should not report formats they do not support, so remove the
> alpha formats from all variant tables: the generic PL110, PL111 and
> Nomadik tables in pl111_drv.c and the board-specific Integrator, IM-PD1,
> Versatile and RealView/Versatile-Express tables in pl111_versatile.c,
> plus the now dead case labels in the display setup and the Versatile
> syscon connector switch, instead of advertising a blend mode property.
> Behavior is unchanged for userspace that picks an XRGB/XBGR/RGB format;
> alpha-picking clients fall back to the identical X variant.
>
> Link: https://github.com/google/syzkaller/issues/7805
> Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed")
> Signed-off-by: Roshan Kumar <roshaen09@gmail.com>
Patch applied to drm-misc-next with Thomas' review tag.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/pl111: Advertise no pixel blending
2026-09-11 12:58 ` Thomas Zimmermann
@ 2026-09-11 18:07 ` Roshan Kumar
2026-09-11 18:22 ` Linus Walleij
0 siblings, 1 reply; 23+ messages in thread
From: Roshan Kumar @ 2026-09-11 18:07 UTC (permalink / raw)
To: Thomas Zimmermann; +Cc: Ze Huang, linusw, dri-devel
Hi Thomas,
Sure, I tested Ze Huang's patch on the QEMU vexpress setup I used for the
format testing (master 7.3-rc2, vexpress a9 + CA9 DTB,
DRM_PL111/SII902X/panel-simple, panic_on_warn).
It compiles cleanly and works: the driver probes, finds the panel on the
coretile CLCD, registers ("Initialized pl111 on minor 0") and the boot
goes through all of device init without any splats.
One observation: with the alpha formats still in the tables,
registration prints the "[PLANE:35:plane-0] pixel format with alpha
exposed but blend mode not setup" message once (drm_warn, non-fatal
since 271e90eb converted the validation away from WARN). I also stacked
my format removal patch on top of the rework: it applies cleanly despite
the renames, and the combined boot is fully silent. So the two changes
are orthogonal and can merge in either order.
Tested-by: Roshan Kumar <roshaen09@gmail.com> # Ze Huang's patch, QEMU vexpress
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/pl111: Advertise no pixel blending
2026-09-11 18:07 ` Roshan Kumar
@ 2026-09-11 18:22 ` Linus Walleij
2026-09-11 19:07 ` Roshan Kumar
0 siblings, 1 reply; 23+ messages in thread
From: Linus Walleij @ 2026-09-11 18:22 UTC (permalink / raw)
To: Roshan Kumar; +Cc: Thomas Zimmermann, Ze Huang, dri-devel
On Fri, Sep 11, 2026 at 8:07 PM Roshan Kumar <roshaen09@gmail.com> wrote:
> Sure, I tested Ze Huang's patch on the QEMU vexpress setup I used for the
> format testing (master 7.3-rc2, vexpress a9 + CA9 DTB,
> DRM_PL111/SII902X/panel-simple, panic_on_warn).
Is that this patch?
https://lore.kernel.org/dri-devel/20260716-drm-simple-kms-removal-v2-4-1133a8fc3785@oss.qualcomm.com/
> Tested-by: Roshan Kumar <roshaen09@gmail.com> # Ze Huang's patch, QEMU vexpress
I can just apply that one patch with your tested tag if that is
desireable, I don't know about the rest of the patches
in that series.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/pl111: Advertise no pixel blending
2026-09-11 18:22 ` Linus Walleij
@ 2026-09-11 19:07 ` Roshan Kumar
2026-09-11 20:05 ` Linus Walleij
0 siblings, 1 reply; 23+ messages in thread
From: Roshan Kumar @ 2026-09-11 19:07 UTC (permalink / raw)
To: Linus Walleij; +Cc: Thomas Zimmermann, Ze Huang, dri-devel
Not quite. I tested the newer iteration attached to Thomas' earlier email
(patch dated Jul 27), which Ze hasn't posted to the list.
I also gave the v2 4/8 you linked a boot on the same QEMU setup and it
behaves the same, so the tag covers either version.
Tested-by: Roshan Kumar <roshaen09@gmail.com> # QEMU vexpress; v2 4/8 and the Jul 27 iteration
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/pl111: Advertise no pixel blending
2026-09-11 19:07 ` Roshan Kumar
@ 2026-09-11 20:05 ` Linus Walleij
2026-09-12 19:49 ` Ze Huang
0 siblings, 1 reply; 23+ messages in thread
From: Linus Walleij @ 2026-09-11 20:05 UTC (permalink / raw)
To: Roshan Kumar; +Cc: Thomas Zimmermann, Ze Huang, dri-devel
On Fri, Sep 11, 2026 at 9:07 PM Roshan Kumar <roshaen09@gmail.com> wrote:
> Not quite. I tested the newer iteration attached to Thomas' earlier email
> (patch dated Jul 27), which Ze hasn't posted to the list.
>
> I also gave the v2 4/8 you linked a boot on the same QEMU setup and it
> behaves the same, so the tag covers either version.
>
> Tested-by: Roshan Kumar <roshaen09@gmail.com> # QEMU vexpress; v2 4/8 and the Jul 27 iteration
Aha I see.
I will wait for Thomas & Ze to tell me what they want me to do
here.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] drm/pl111: Advertise no pixel blending
2026-09-11 20:05 ` Linus Walleij
@ 2026-09-12 19:49 ` Ze Huang
0 siblings, 0 replies; 23+ messages in thread
From: Ze Huang @ 2026-09-12 19:49 UTC (permalink / raw)
To: Linus Walleij, Roshan Kumar; +Cc: Thomas Zimmermann, Ze Huang, dri-devel
On Sat Sep 12, 2026 at 4:05 AM CST, Linus Walleij wrote:
> On Fri, Sep 11, 2026 at 9:07 PM Roshan Kumar <roshaen09@gmail.com> wrote:
>
>> Not quite. I tested the newer iteration attached to Thomas' earlier email
>> (patch dated Jul 27), which Ze hasn't posted to the list.
>>
>> I also gave the v2 4/8 you linked a boot on the same QEMU setup and it
>> behaves the same, so the tag covers either version.
>>
>> Tested-by: Roshan Kumar <roshaen09@gmail.com> # QEMU vexpress; v2 4/8 and the Jul 27 iteration
>
> Aha I see.
>
> I will wait for Thomas & Ze to tell me what they want me to do
> here.
>
Hi Linus,
Please go ahead with the v3 patch attached by Thomas, which corresponds to [1].
Thanks Roshan for the testing, and thanks Thomas and Linus for pushing this forward!
[1] https://lore.kernel.org/all/20260727-drm-simple-kms-removal-v3-4-cd5dc89858c6@oss.qualcomm.com/
>
> Yours,
> Linus Walleij
Best regards,
Ze
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2026-09-13 20:54 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-25 10:54 [PATCH] drm/pl111: Advertise no pixel blending Roshan Kumar
2026-08-25 11:07 ` sashiko-bot
2026-09-08 21:31 ` Leandro Ribeiro
2026-09-09 4:17 ` Roshan Kumar
2026-09-09 8:16 ` Thomas Zimmermann
2026-09-11 13:24 ` Linus Walleij
2026-09-11 13:26 ` Linus Walleij
[not found] ` <d3a928e0-0faa-4cd4-9d2e-cb9be4cf84c0@suse.de>
2026-09-10 5:44 ` Roshan Kumar
2026-09-10 5:45 ` [PATCH v2] drm/pl111: drop alpha formats the hardware cannot scan out Roshan Kumar
2026-09-10 5:51 ` sashiko-bot
2026-09-10 6:15 ` Thomas Zimmermann
2026-09-10 19:25 ` [PATCH] drm/pl111: Advertise no pixel blending Roshan Kumar
2026-09-11 6:33 ` Thomas Zimmermann
2026-09-11 12:58 ` Thomas Zimmermann
2026-09-11 18:07 ` Roshan Kumar
2026-09-11 18:22 ` Linus Walleij
2026-09-11 19:07 ` Roshan Kumar
2026-09-11 20:05 ` Linus Walleij
2026-09-12 19:49 ` Ze Huang
2026-09-10 19:25 ` [PATCH v3] drm/pl111: drop alpha formats the hardware cannot scan out Roshan Kumar
2026-09-10 19:34 ` sashiko-bot
2026-09-11 6:41 ` Thomas Zimmermann
2026-09-11 18:00 ` Linus Walleij
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox