[V7 02/45] drm/vkms: Round fixp2int conversion in lerp_u16

Louis Chauvet louis.chauvet at bootlin.com
Tue Feb 25 14:05:13 UTC 2025



Le 25/02/2025 à 12:28, Simon Ser a écrit :
> On Tuesday, February 25th, 2025 at 10:37, Louis Chauvet <louis.chauvet at 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.exposito89@gmail.com/

Thanks,
Louis Chauvet

> Simon

-- 
Louis Chauvet, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com



More information about the amd-gfx mailing list