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

[Thomas Zimmermann <tzimmermann@xxxxxxx>]

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)