Le 25/02/2025 à 12:28, Simon Ser a écrit :
On Tuesday, February 25th, 2025 at 10:37, Louis Chauvet
<louis.chau...@bootlin.com> wrote:
Can I extract this patch from the series and apply it on drm-misc-next?
That sounds completely fine by me, and TBH it sounds like it could even
be drm-misc-fixes material?
Probably yes, I can take it now.
We need to be a bit careful when merging patches from the same series
via multiple trees. Maybe we'll merge the colorop stuff via the amd
tree? I don't remember the rules around trees, and I don't know if it
would be fine to merge the vkms changes in that tree as well. (I only
remember Simona recommending against merging via multiple trees, because
it's painful.)
If we can't merge the vkms changes via the amd tree, they will likely
need to wait for the amd tree to be merged back in drm-next?
If we merge some changes via drm-misc-next, then we won't be able to
merge the rest via amd, if the rest depends on these changes.
If the drm-*-next branches are synchronized often, I propose to split
into 4 series:
- 2/45, in drm-misc-fixes (it is a bug)
- 3/45, in drm-misc-next (only the vkms part needs it, can be merged
just after [1] with minor conflict resolution, which I can do)
- 1, 4..13, 21..45, in drm-amd-next
- 14..20, in drm-misc-next, once drm-amd-next is merged in drm-misc-next
(I don't expect huge conflicts if this is merged "soon", afaik nobody is
currently working on the composition algorithm)
[1]:https://lore.kernel.org/all/20250218101214.5790-1-jose.exposit...@gmail.com/
Thanks,
Louis Chauvet
Simon
--
Louis Chauvet, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
