From: "Andy Yan" <andyshrk@163.com>
To: "Johan Jonker" <jbx6244@gmail.com>
Cc: "Heiko Stübner" <heiko@sntech.de>,
andy.yan@rock-chips.com, hjc@rock-chips.com,
maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch,
dri-devel@lists.freedesktop.org,
linux-rockchip@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re:Re: [RFC PATCH v1] drm: rockchip: add drm_plane_create_blend_mode_property
Date: Fri, 4 Sep 2026 19:13:03 +0800 (CST) [thread overview]
Message-ID: <3ff2201c.8fbe.1a06c1f43f5.Coremail.andyshrk@163.com> (raw)
In-Reply-To: <a239b296-ba90-45d1-b8b8-713ab29fda5c@gmail.com>
Helllo,
At 2026-08-24 05:06:45, "Johan Jonker" <jbx6244@gmail.com> wrote:
>
>
>On 8/23/26 21:19, Heiko Stübner wrote:
>> Hi Johan,
>>
>> Am Sonntag, 23. August 2026, 14:29:09 Mitteleuropäische Sommerzeit schrieb Johan Jonker:
>>> A validate_blend_mode_for_alpha_formats() function was added that
>>> fills the kernel log with warnings for Rockchip VOP version 1 SoCs.
>>> Add a drm_plane_create_blend_mode_property() function as fix.
>>
>
>> This is missing explanation on why PIXEL_NONE is the correct value.
>>
>> VOP2 seems to support all 3 blend modes? So a sentece explaining
>> the pixel_none value would be helpful.
>>
>>
>
>Hi,
>
>In the vop_plane_atomic_update() function there's a comment with win0 blend broken:
>
> /*
> * Blending win0 with the background color doesn't seem to work
> * correctly. We only get the background color, no matter the contents
> * of the win0 framebuffer. However, blending pre-multiplied color
> * with the default opaque black default background color is a no-op,
> * so we can just disable blending to get the correct result.
> */
>
All VOP 1 do not support alpha blending with background.
Also, some VOPs do not support alpha when scaling is enabled, except those marked with VOP_FEATURE_ALPHA_SCALE, see[0]
[0]https://github.com/rockchip-linux/kernel/blob/develop-6.12/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
>In the function vop2_plane_init() there are these blends:
>
> unsigned int blend_caps = BIT(DRM_MODE_BLEND_PIXEL_NONE) |
> BIT(DRM_MODE_BLEND_PREMULTI) |
> BIT(DRM_MODE_BLEND_COVERAGE);
>
>My question:
>Could someone with more know-how tell us what VOP version 1 is capable of?
>Is there anything that needs to be set like in other drivers?
>
>For example:
> switch (pixel_blend_mode) {
> case DRM_MODE_BLEND_PREMULTI:
> break;
> case DRM_MODE_BLEND_COVERAGE:
> break;
> case DRM_MODE_BLEND_PIXEL_NONE:
> default:
> break;
> }
>
>If someone comes up with another solution/patch that's also fine, as long the kernel warnings are gone.
>
>Thanks!
>
>Johan
>
>
>
>> Heiko
>>
>>> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
>>> ---
>>>
>>> https://lore.kernel.org/all/20260526181700.25310-3-leandro.ribeiro@collabora.com/
>>> ---
>>> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>> index 0090d8ff0c79..0bc5b606f021 100644
>>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>> @@ -1850,6 +1850,8 @@ static void vop_plane_add_properties(struct drm_plane *plane,
>>> if (flags)
>>> drm_plane_create_rotation_property(plane, DRM_MODE_ROTATE_0,
>>> DRM_MODE_ROTATE_0 | flags);
>>> + drm_plane_create_blend_mode_property(plane,
>>> + BIT(DRM_MODE_BLEND_PIXEL_NONE));
>>> }
>>>
>>> static int vop_create_crtc(struct vop *vop)
>>>
>>
>>
>>
>>
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
prev parent reply other threads:[~2026-09-04 11:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-23 12:29 [RFC PATCH v1] drm: rockchip: add drm_plane_create_blend_mode_property Johan Jonker
2026-08-23 19:19 ` Heiko Stübner
2026-08-23 21:06 ` Johan Jonker
2026-09-04 11:13 ` Andy Yan [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=3ff2201c.8fbe.1a06c1f43f5.Coremail.andyshrk@163.com \
--to=andyshrk@163.com \
--cc=airlied@gmail.com \
--cc=andy.yan@rock-chips.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=heiko@sntech.de \
--cc=hjc@rock-chips.com \
--cc=jbx6244@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=simona@ffwll.ch \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox