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)
