Message ID | 20231116195812.906115-1-mwen@igalia.com (mailing list archive) |
---|---|
Headers | show |
Series | drm/amd/display: add AMD driver-specific properties for color mgmt | expand |
On 2023-11-16 14:57, Melissa Wen wrote: > Hello, > > This series extends the current KMS color management API with AMD > driver-specific properties to enhance the color management support on > AMD Steam Deck. The key additions to the color pipeline include: > snip > Melissa Wen (18): > drm/drm_mode_object: increase max objects to accommodate new color > props > drm/drm_property: make replace_property_blob_from_id a DRM helper > drm/drm_plane: track color mgmt changes per plane If all patches are merged through amd-staging-drm-next I worry that conflicts creep in if any code around replace_property_blob_from_id changes in DRM. My plan is to merge DRM patches through drm-misc-next, as well as include them in the amd-staging-drm-next merge. They should then fall out at the next amd-staging-drm-next pull and (hopefully) ensure that there is no conflict. If no objections I'll go ahead with that later this week. Harry > drm/amd/display: add driver-specific property for plane degamma LUT > drm/amd/display: explicitly define EOTF and inverse EOTF > drm/amd/display: document AMDGPU pre-defined transfer functions > drm/amd/display: add plane 3D LUT driver-specific properties > drm/amd/display: add plane shaper LUT and TF driver-specific > properties > drm/amd/display: add CRTC gamma TF driver-specific property > drm/amd/display: add comments to describe DM crtc color mgmt behavior > drm/amd/display: encapsulate atomic regamma operation > drm/amd/display: decouple steps for mapping CRTC degamma to DC plane > drm/amd/display: reject atomic commit if setting both plane and CRTC > degamma > drm/amd/display: add plane shaper LUT support > drm/amd/display: add plane shaper TF support > drm/amd/display: add plane 3D LUT support > drm/amd/display: add plane CTM driver-specific property > drm/amd/display: add plane CTM support > > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 91 ++ > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 34 +- > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 108 +++ > .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 818 ++++++++++++++++-- > .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 72 ++ > .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 232 ++++- > .../gpu/drm/amd/display/include/fixed31_32.h | 12 + > drivers/gpu/drm/arm/malidp_crtc.c | 2 +- > drivers/gpu/drm/drm_atomic.c | 1 + > drivers/gpu/drm/drm_atomic_state_helper.c | 1 + > drivers/gpu/drm/drm_atomic_uapi.c | 43 +- > drivers/gpu/drm/drm_property.c | 49 ++ > include/drm/drm_mode_object.h | 2 +- > include/drm/drm_plane.h | 7 + > include/drm/drm_property.h | 6 + > include/uapi/drm/drm_mode.h | 8 + > 16 files changed, 1377 insertions(+), 109 deletions(-) >
On Tue, 28 Nov 2023 at 23:11, Harry Wentland <harry.wentland@amd.com> wrote: > > On 2023-11-16 14:57, Melissa Wen wrote: > > Hello, > > > > This series extends the current KMS color management API with AMD > > driver-specific properties to enhance the color management support on > > AMD Steam Deck. The key additions to the color pipeline include: > > > > snip > > > Melissa Wen (18): > > drm/drm_mode_object: increase max objects to accommodate new color > > props > > drm/drm_property: make replace_property_blob_from_id a DRM helper > > drm/drm_plane: track color mgmt changes per plane > > If all patches are merged through amd-staging-drm-next I worry that > conflicts creep in if any code around replace_property_blob_from_id > changes in DRM. > > My plan is to merge DRM patches through drm-misc-next, as well > as include them in the amd-staging-drm-next merge. They should then > fall out at the next amd-staging-drm-next pull and (hopefully) > ensure that there is no conflict. > > If no objections I'll go ahead with that later this week. Double-merging tends to be the worst because git doesn't realize the commits match, which actually makes the conflicts worse when they happen (because the 3-way merge diff gets absolute confused by all the changed context and misplaces everything to the max). So please don't, _only_ every cherry-pick when a patch in -next is also needed in -fixes, and we didn't put it into the right tree. But even that is a bit tricky and should only be done by maintainers (using dim cherry-pick if it's drm-misc) because the conflicts tend to be bad and need to be sorted out with backmerges sooner than later. For this case merge everything through one tree with the right acks, pull to drm-next asap and then backmerge into the other tree. Here probably amdgpu-next with drm-misc maintainer acks for the 3 core patches. Or if amdgpu-next pull won't come for a while, put them into drm-misc-next and just wait a week until it's in drm-next, then forward amdgpu-next. Cheers, Sima > Harry > > > drm/amd/display: add driver-specific property for plane degamma LUT > > drm/amd/display: explicitly define EOTF and inverse EOTF > > drm/amd/display: document AMDGPU pre-defined transfer functions > > drm/amd/display: add plane 3D LUT driver-specific properties > > drm/amd/display: add plane shaper LUT and TF driver-specific > > properties > > drm/amd/display: add CRTC gamma TF driver-specific property > > drm/amd/display: add comments to describe DM crtc color mgmt behavior > > drm/amd/display: encapsulate atomic regamma operation > > drm/amd/display: decouple steps for mapping CRTC degamma to DC plane > > drm/amd/display: reject atomic commit if setting both plane and CRTC > > degamma > > drm/amd/display: add plane shaper LUT support > > drm/amd/display: add plane shaper TF support > > drm/amd/display: add plane 3D LUT support > > drm/amd/display: add plane CTM driver-specific property > > drm/amd/display: add plane CTM support > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 91 ++ > > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 34 +- > > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 108 +++ > > .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 818 ++++++++++++++++-- > > .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 72 ++ > > .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 232 ++++- > > .../gpu/drm/amd/display/include/fixed31_32.h | 12 + > > drivers/gpu/drm/arm/malidp_crtc.c | 2 +- > > drivers/gpu/drm/drm_atomic.c | 1 + > > drivers/gpu/drm/drm_atomic_state_helper.c | 1 + > > drivers/gpu/drm/drm_atomic_uapi.c | 43 +- > > drivers/gpu/drm/drm_property.c | 49 ++ > > include/drm/drm_mode_object.h | 2 +- > > include/drm/drm_plane.h | 7 + > > include/drm/drm_property.h | 6 + > > include/uapi/drm/drm_mode.h | 8 + > > 16 files changed, 1377 insertions(+), 109 deletions(-) > > >
On 2023-11-30 06:34, Daniel Vetter wrote: > On Tue, 28 Nov 2023 at 23:11, Harry Wentland <harry.wentland@amd.com> wrote: >> >> On 2023-11-16 14:57, Melissa Wen wrote: >>> Hello, >>> >>> This series extends the current KMS color management API with AMD >>> driver-specific properties to enhance the color management support on >>> AMD Steam Deck. The key additions to the color pipeline include: >>> >> >> snip >> >>> Melissa Wen (18): >>> drm/drm_mode_object: increase max objects to accommodate new color >>> props >>> drm/drm_property: make replace_property_blob_from_id a DRM helper >>> drm/drm_plane: track color mgmt changes per plane >> >> If all patches are merged through amd-staging-drm-next I worry that >> conflicts creep in if any code around replace_property_blob_from_id >> changes in DRM. >> >> My plan is to merge DRM patches through drm-misc-next, as well >> as include them in the amd-staging-drm-next merge. They should then >> fall out at the next amd-staging-drm-next pull and (hopefully) >> ensure that there is no conflict. >> >> If no objections I'll go ahead with that later this week. > > Double-merging tends to be the worst because git doesn't realize the > commits match, which actually makes the conflicts worse when they > happen (because the 3-way merge diff gets absolute confused by all the > changed context and misplaces everything to the max). So please don't, > _only_ every cherry-pick when a patch in -next is also needed in > -fixes, and we didn't put it into the right tree. But even that is a > bit tricky and should only be done by maintainers (using dim > cherry-pick if it's drm-misc) because the conflicts tend to be bad and > need to be sorted out with backmerges sooner than later. > > For this case merge everything through one tree with the right acks, > pull to drm-next asap and then backmerge into the other tree. Here > probably amdgpu-next with drm-misc maintainer acks for the 3 core > patches. Or if amdgpu-next pull won't come for a while, put them into > drm-misc-next and just wait a week until it's in drm-next, then > forward amdgpu-next. > Maxime, Maarten, Thomas, could I get an ACK from you for the three DRM core patches and an ACK for pulling them through the AMD tree? Thanks, Harry > Cheers, Sima > >> Harry >> >>> drm/amd/display: add driver-specific property for plane degamma LUT >>> drm/amd/display: explicitly define EOTF and inverse EOTF >>> drm/amd/display: document AMDGPU pre-defined transfer functions >>> drm/amd/display: add plane 3D LUT driver-specific properties >>> drm/amd/display: add plane shaper LUT and TF driver-specific >>> properties >>> drm/amd/display: add CRTC gamma TF driver-specific property >>> drm/amd/display: add comments to describe DM crtc color mgmt behavior >>> drm/amd/display: encapsulate atomic regamma operation >>> drm/amd/display: decouple steps for mapping CRTC degamma to DC plane >>> drm/amd/display: reject atomic commit if setting both plane and CRTC >>> degamma >>> drm/amd/display: add plane shaper LUT support >>> drm/amd/display: add plane shaper TF support >>> drm/amd/display: add plane 3D LUT support >>> drm/amd/display: add plane CTM driver-specific property >>> drm/amd/display: add plane CTM support >>> >>> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 91 ++ >>> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 34 +- >>> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 108 +++ >>> .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 818 ++++++++++++++++-- >>> .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 72 ++ >>> .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 232 ++++- >>> .../gpu/drm/amd/display/include/fixed31_32.h | 12 + >>> drivers/gpu/drm/arm/malidp_crtc.c | 2 +- >>> drivers/gpu/drm/drm_atomic.c | 1 + >>> drivers/gpu/drm/drm_atomic_state_helper.c | 1 + >>> drivers/gpu/drm/drm_atomic_uapi.c | 43 +- >>> drivers/gpu/drm/drm_property.c | 49 ++ >>> include/drm/drm_mode_object.h | 2 +- >>> include/drm/drm_plane.h | 7 + >>> include/drm/drm_property.h | 6 + >>> include/uapi/drm/drm_mode.h | 8 + >>> 16 files changed, 1377 insertions(+), 109 deletions(-) >>> >> > >
On Fri, Dec 01, 2023 at 10:20:40AM -0500, Harry Wentland wrote: > > > On 2023-11-30 06:34, Daniel Vetter wrote: > > On Tue, 28 Nov 2023 at 23:11, Harry Wentland <harry.wentland@amd.com> wrote: > >> > >> On 2023-11-16 14:57, Melissa Wen wrote: > >>> Hello, > >>> > >>> This series extends the current KMS color management API with AMD > >>> driver-specific properties to enhance the color management support on > >>> AMD Steam Deck. The key additions to the color pipeline include: > >>> > >> > >> snip > >> > >>> Melissa Wen (18): > >>> drm/drm_mode_object: increase max objects to accommodate new color > >>> props > >>> drm/drm_property: make replace_property_blob_from_id a DRM helper > >>> drm/drm_plane: track color mgmt changes per plane > >> > >> If all patches are merged through amd-staging-drm-next I worry that > >> conflicts creep in if any code around replace_property_blob_from_id > >> changes in DRM. > >> > >> My plan is to merge DRM patches through drm-misc-next, as well > >> as include them in the amd-staging-drm-next merge. They should then > >> fall out at the next amd-staging-drm-next pull and (hopefully) > >> ensure that there is no conflict. > >> > >> If no objections I'll go ahead with that later this week. > > > > Double-merging tends to be the worst because git doesn't realize the > > commits match, which actually makes the conflicts worse when they > > happen (because the 3-way merge diff gets absolute confused by all the > > changed context and misplaces everything to the max). So please don't, > > _only_ every cherry-pick when a patch in -next is also needed in > > -fixes, and we didn't put it into the right tree. But even that is a > > bit tricky and should only be done by maintainers (using dim > > cherry-pick if it's drm-misc) because the conflicts tend to be bad and > > need to be sorted out with backmerges sooner than later. > > > > For this case merge everything through one tree with the right acks, > > pull to drm-next asap and then backmerge into the other tree. Here > > probably amdgpu-next with drm-misc maintainer acks for the 3 core > > patches. Or if amdgpu-next pull won't come for a while, put them into > > drm-misc-next and just wait a week until it's in drm-next, then > > forward amdgpu-next. > > > > Maxime, Maarten, Thomas, could I get an ACK from you for the three > DRM core patches and an ACK for pulling them through the AMD tree? Acked-by: Maxime Ripard <mripard@kernel.org> Maxime