Re: [PATCH 0/9] drm: replace simple display pipe users with atomic helpers

Hi

Am 06.07.26 um 10:22 schrieb Ze Huang:
> On Mon Jul 6, 2026 at 3:27 PM CST, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 04.07.26 um 20:31 schrieb Ze Huang:
>>> struct drm_simple_display_pipe was meant to simplify simple DRM
>>> drivers, but instead adds an extra wrapper around normal DRM atomic
>>> helper setup. As noted in Documentation/gpu/todo.rst, remaining users
>>> should be converted to regular atomic helpers and stop depending on the
>>> simple-KMS interfaces.
>>>
>>> This series converts the following drivers:
>>>
>>>     - arcpgu
>>>     - aspeed
>>>     - imx lcdc
>>>     - mcde
>>>     - pl111
>>>     - gm12u320
>>>     - repaper
>>>     - tve200
>>>     - xen frontend
>>>
>>> Each patch replaces drm_simple_display_pipe_init() with explicit
>>> primary plane, CRTC and encoder setup, and moves the old simple-pipe
>>> callbacks into regular plane and CRTC helper callbacks named according
>>> to local driver conventions.
>>>
>>> The conversions preserve helper behavior that used to be implicit in
>>> drm_simple_kms_helper.c, including plane-state validation, CRTC
>>> primary-plane checks, affected-plane propagation, framebuffer prepare
>>> handling, and existing event/vblank flow where applicable.
>>>
>>> Result is less helper indirection and more explicit driver-side atomic
>>> wiring, with no remaining simple-KMS dependency in these drivers.
>>>
>>> These changes are build-tested only. No hardware testing has been
>>> performed on the affected devices.
>> Thanks a lot for the series. That's quite a nice cleanup.  Did you use
>> any AI to create these patches?
>>
> Hi Thomas,
>
> Yes, I did. I wrote the first two conversion patches (arcpgu and
> aspeed) myself to understand the migration pattern. For the remaining
> drivers, I used GPT-5.5 to help with the repetitive boilerplate
> conversion.
>
> I should have reviewed the generated code more carefully before sending
> the series. The sashiko-bot feedback shows that I missed several important
> details, including commit-local state handling, the implicit NULL fb /
> visibility checks from simple-KMS, and vblank/pageflip event ordering.
> I am now going through these issues more carefully and working out the
> correct fixes before sending a v2.

Great, thanks.

The drivers you've picked are somewhat under-maintained, but I'll take a 
look at your submissions.


>
> Do you expect AI assistance to be mentioned in the cover letter or commit
> messages in some specific form? If there is a preferred tag or wording
> for this, I will use it in v2.

See Documentation/process/coding-assistents.rst for how to mark AI-made 
patches.  Although not everyone agrees that it's a good idea.  IMHO you 
should mention AI usage in the cover letter.


>
> For issues that appear to be pre-existing but are exposed or carried over
> by the migration, which is better?

It's probably better to not bother about pre-existing issues for now.  
Those are a rabbit hole.  If you're looking for follow-up patches to do. 
You're welcome to address them.


>
> 1. Include them as separate prep/fix patches at the beginning of the v2
> series, before the corresponding conversion patches; or
> 2. address those pre-existing issues in a separate follow-up series?
>
> Thanks for your time and review. :)
>
>> Best regards
>> Thomas
>>
> Best regards,
> Ze

-- 
--
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)