From: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
To: mwen@igalia.com, airlied@gmail.com, alexander.deucher@amd.com,
christian.koenig@amd.com, daniels@collabora.com,
harry.wentland@amd.com, leandro.ribeiro@collabora.com,
maarten.lankhorst@linux.intel.com, mripard@kernel.org,
pekka.paalanen@collabora.com, siqueira@igalia.com,
sunpeng.li@amd.com, tzimmermann@suse.de
Cc: alex.hung@amd.com, Daniel.Wheeler@amd.com, kernel-dev@igalia.com,
lyude@redhat.com, amd-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org,
Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Subject: Re: [PATCH v3 0/3] drm/atomic-state-helper: fixes for blend-mode-prop warning
Date: Wed, 26 Aug 2026 02:24:49 +0500 [thread overview]
Message-ID: <20260825212449.48288-1-mikhail.v.gavrilov@gmail.com> (raw)
In-Reply-To: <20260813143605.106104-1-mwen@igalia.com>
Hi,
On current mainline every boot on my machine produces this at amdgpu probe:
[PLANE:44:plane-0] pixel format with alpha exposed but blend mode not setup
WARNING: drivers/gpu/drm/drm_mode_config.c:872 at drm_mode_config_validate+0xa16/0x13b0
16 times per boot: 8 per GPU, on the 4 primary and 4 cursor planes of each of
the two cards in this box. I bisected it to 860e748bddcc ("drm: ensure blend
mode supported if pixel format with alpha exposed") and confirmed it by
reverting that commit, before I found this series.
With all three patches of this series applied the warnings are gone.
Base: 66498c75b4f8, kernel 7.2.0-66498c75b4f8+ #154, KASAN and lockdep enabled.
Hardware:
0000:03:00.0 Navi 31 (0x1002:0x744C), DCN 3.2
0000:0f:00.0 Raphael iGPU (0x1002:0x164E), DCN 3.1.5
After booting into a normal desktop session:
dmesg | grep -c 'blend mode not setup' -> 0
dmesg | grep -c 'drm_mode_config_validate' -> 0
drm_info | grep -c 'pixel blend mode' -> 20
i.e. all 10 planes on each GPU (4 primary, 2 overlay, 4 cursor) now expose the
property. No WARNING, no UBSAN and no lockdep report anywhere in the buffer.
What I did not cover: I have no DCE hardware, so patch 3/3 is untested; and
since PREMULTI is present in the blend caps of every plane here, the property
default lookup added by 1/3 resolves to the same value that was hardcoded
before, so that path is exercised only in its trivial case.
Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
One question about routing: 860e748bddcc landed in the 7.3 merge window, so
this is a merge-window regression - it was never in a release, and no stable
backport is involved. But the fix should still make 7.3 rather than wait for
the 7.4 merge window: right now every amdgpu machine on mainline hits this at
probe. 271e90eb5f9f ("drm: use drm_warn() in
validate_blend_mode_for_alpha_formats()") is already in drm-misc-next-fixes,
while this series is in neither linux-next nor amd-staging-drm-next. Could it
go the same way - drm-misc-next-fixes while the window is open, drm-fixes
after -rc1 - instead of through amd-staging-drm-next, which is aimed at 7.4
now? Splitting it looks wrong anyway: 3/3 gives DCE planes a property with
PIXEL_NONE only, which needs 1/3 to not end up with PREMULTI in the default
state.
--
Thanks,
Mikhail
prev parent reply other threads:[~2026-08-25 21:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 14:30 [PATCH v3 0/3] drm/atomic-state-helper: fixes for blend-mode-prop warning Melissa Wen
2026-08-13 14:30 ` [PATCH v3 1/3] drm/atomic-state-helper: set pixel_blend_mode to prop default on reset Melissa Wen
2026-08-13 14:30 ` [PATCH v3 2/3] drm/amd/display: fix missing blend-mode-prop warning for DCN Melissa Wen
2026-08-13 17:49 ` Alex Hung
2026-08-21 21:47 ` Alex Hung
2026-08-13 14:30 ` [PATCH v3 3/3] drm/amd/display: advertise PIXEL_NONE as blend mode for DCE generations Melissa Wen
2026-08-13 14:44 ` sashiko-bot
2026-08-13 15:04 ` Melissa Wen
2026-08-21 21:48 ` Alex Hung
2026-08-24 20:38 ` Viktor Jägersküpper
2026-08-24 21:02 ` Viktor Jägersküpper
2026-08-25 8:06 ` Melissa Wen
2026-08-25 11:25 ` Xaver Hugl
2026-08-25 18:56 ` Viktor Jägersküpper
2026-08-13 17:58 ` [PATCH v3 0/3] drm/atomic-state-helper: fixes for blend-mode-prop warning Wheeler, Daniel
2026-08-18 10:28 ` Melissa Wen
2026-08-21 13:49 ` Wheeler, Daniel
2026-08-25 21:24 ` Mikhail Gavrilov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260825212449.48288-1-mikhail.v.gavrilov@gmail.com \
--to=mikhail.v.gavrilov@gmail.com \
--cc=Daniel.Wheeler@amd.com \
--cc=airlied@gmail.com \
--cc=alex.hung@amd.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=daniels@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=harry.wentland@amd.com \
--cc=kernel-dev@igalia.com \
--cc=leandro.ribeiro@collabora.com \
--cc=lyude@redhat.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=mwen@igalia.com \
--cc=pekka.paalanen@collabora.com \
--cc=siqueira@igalia.com \
--cc=sunpeng.li@amd.com \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.