Le 25/02/2025 à 15:45, Simon Ser a écrit :
On Tuesday, February 25th, 2025 at 15:43, Harry Wentland
<harry.wentl...@amd.com> wrote:
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)
I would think it's easier if it all goes in via drm-misc next,
except for patch 2 which can be part of drm-misc-fixes. Alex
and I based our branches on drm-misc-next. There shouldn't be
major conflicts with drm/amd code but we can check that before
merging.
That sounds like the simplest solution to me :)
So let's go this way!
I just applied PATCH 2.
I don't feel comfortable merging the whole colorop and AMD parts without
broader reviews, but I can definitely apply the VKMS part.
--
Louis Chauvet, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
