Re: [PATCH v3 0/3] drm/atomic-state-helper: fixes for blend-mode-prop warning

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 <[email protected]>

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