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

[Louis Chauvet]

Le 25/02/2025 à 15:45, Simon Ser a écrit :
> On Tuesday, February 25th, 2025 at 15:43, Harry Wentland <harry.wentland at 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