All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Lyude Paul" <lyude@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 3/3] drm/nouveau/kms/nv50-: Unconditionally create blend_mode prop for wndws
Date: Mon, 20 Jul 2026 21:15:02 +0000	[thread overview]
Message-ID: <20260720211503.4BA811F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260720205541.257781-4-lyude@redhat.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch introduces a conditional check that contradicts its commit message and results in an incomplete fix for a DRM core WARN_ON. While claiming to 'unconditionally create blend_mode prop for wndws', the code limits this to planes where `func->blend_modes` is non-zero. Older primary planes (e.g., `base507c`) expose alpha formats but lack `.blend_modes` initialization, meaning they will still trigger the warning.
--

--- Patch [3]: [PATCH v2 3/3] drm/nouveau/kms/nv50-: Unconditionally create blend_mode prop for wndws ---
commit d890a1a203754ff1359f8cdacfa01e033bb7b8f3
Author: Lyude Paul <lyude@redhat.com>
drm/nouveau/kms/nv50-: Unconditionally create blend_mode prop for wndws

This patch attempts to resolve a DRM core validation warning by ensuring the
blend_mode property is created for all window types that expose color formats
with an alpha channel, even if they lack a blend_set function.

> diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
> index 0f331f47bded8..84b9a16bdb8ab 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c

[ ... ]

> @@ -944,6 +937,17 @@ nv50_wndw_new_(const struct nv50_wndw_func *func, struct drm_device *dev,
>  			return ret;
>  	}
>  
> +	/*
> +	 * DRM requires that we have a blend mode property for any type of plane that exposes color
> +	 * formats with an alpha channel. So do this, even if we don't actually have control for the
> +	 * blend property hooked up with blend_set.
> +	 */
> +	if (func->blend_modes) {

[Severity: Medium]
Does this conditional check contradict the commit message? The commit states
the blend_mode property is created unconditionally for all types of wndws.

However, for older primary planes like base507c, the nv50_wndw_func definition
does not initialize .blend_modes:

static const struct nv50_wndw_func
base507c = {
	.acquire = base507c_acquire,
	.release = base507c_release,
	.sema_set = base507c_sema_set,
	...

Since func->blend_modes evaluates to 0 here, the property creation is skipped.

Because base507c_format exposes formats with an alpha channel (such as
DRM_FORMAT_ARGB8888), won't skipping the property creation here leave the issue
unfixed and cause the DRM core validation WARN_ON to still trigger?

> +		ret = drm_plane_create_blend_mode_property(&wndw->plane, func->blend_modes);
> +		if (ret)
> +			return ret;
> +	}
> +
>  	return 0;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720205541.257781-1-lyude@redhat.com?part=3

  reply	other threads:[~2026-07-20 21:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-20 20:43 [PATCH v2 0/3] drm/nouveau: Fix WARN_ON() from missing blend modes Lyude Paul
2026-07-20 20:43 ` Lyude Paul
2026-07-20 20:43 ` [PATCH v2 1/3] drm/nouveau/kms/nv50-: Add .blend_modes to nv50_wndw_func Lyude Paul
2026-07-20 20:43   ` Lyude Paul
2026-07-20 21:06   ` sashiko-bot
2026-07-20 20:43 ` [PATCH v2 2/3] drm/nouveau/kms/nv50-: Introduce nv50_wndw_default_state() Lyude Paul
2026-07-20 20:43   ` Lyude Paul
2026-07-20 21:08   ` sashiko-bot
2026-07-20 20:43 ` [PATCH v2 3/3] drm/nouveau/kms/nv50-: Unconditionally create blend_mode prop for wndws Lyude Paul
2026-07-20 20:43   ` Lyude Paul
2026-07-20 21:15   ` sashiko-bot [this message]
2026-07-21 20:21     ` lyude
2026-07-21 20:08 ` [PATCH v2 0/3] drm/nouveau: Fix WARN_ON() from missing blend modes lyude
2026-07-21 20:08   ` lyude

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=20260720211503.4BA811F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=lyude@redhat.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.