Re: [PATCH v17 0/9] Enable Adaptive Sync SDP Support for DP

[Maxime Ripard <mripard@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2082 bytes --]

On Fri, Apr 19, 2024 at 05:09:29PM +0300, Jani Nikula wrote:
> On Fri, 19 Apr 2024, Maxime Ripard <mripard@kernel.org> wrote:
> > On Fri, Apr 19, 2024 at 03:35:55PM +0300, Jani Nikula wrote:
> >> On Thu, 04 Apr 2024, "Nautiyal, Ankit K" <ankit.k.nautiyal@intel.com> wrote:
> >> > On 3/19/2024 3:16 PM, Maxime Ripard wrote:
> >> >> On Mon, Mar 18, 2024 at 04:37:58PM +0200, Jani Nikula wrote:
> >> >>> On Mon, 11 Mar 2024, Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> wrote:
> >> >>>>   An Adaptive-Sync-capable DP protocol converter indicates its
> >> >>>> support by setting the related bit in the DPCD register. This
> >> >>>> is valid for DP and edp as well.
> >> >>>>
> >> >>>> Computes AS SDP values based on the display configuration,
> >> >>>> ensuring proper handling of Variable Refresh Rate (VRR)
> >> >>>> in the context of Adaptive Sync.
> >> >>> [snip]
> >> >>>
> >> >>>> Mitul Golani (9):
> >> >>>>    drm/dp: Add support to indicate if sink supports AS SDP
> >> >>>>    drm: Add Adaptive Sync SDP logging
> >> >>> Maarten, Maxime, Thomas, ack for merging these two patches via
> >> >>> drm-intel-next?
> >> >> Ack
> >> >>
> >> >> Maxime
> >> >
> >> > Thanks for the patch, ack and reviews, pushed to drm-intel-next.
> >> 
> >> This came up again today [1]. The acks absolutely must be recorded in
> >> the commit messages when pushing the patches.
> >> 
> >> dim should complain about applying non-i915 patches without acks.
> >
> > It doesn't at the moment, this has bitten us a couple of times in
> > drm-misc too.
> 
> See check_maintainer() that gets called from apply_patch() and
> dim_b4_shazam_branch().

Oh, right, I missed it sorry.

> It's of limited value, but it should complain while applying non-i915
> patches.
> 
> > I did a MR to address that that hasn't been reviewed yet:
> > https://gitlab.freedesktop.org/drm/maintainer-tools/-/merge_requests/40
> 
> Yeah, a more generic solution is needed, but I think we should unify
> with the above.

Fully agreed, I'll rework it.

Thanks!
Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]