Re: [Intel-gfx] [PATCH 1/3] drm/dp: add helpers to read link training delays

[Jani Nikula <jani.nikula@intel.com>]

On Mon, 18 Oct 2021, Maxime Ripard <maxime@cerno.tech> wrote:
> Hi Jani,
>
> On Fri, Oct 15, 2021 at 06:21:35PM +0300, Jani Nikula wrote:
>> On Thu, 14 Oct 2021, Jani Nikula <jani.nikula@intel.com> wrote:
>> > The link training delays are different and/or available in different
>> > DPCD offsets depending on:
>> >
>> > - Clock recovery vs. channel equalization
>> > - DPRX vs. LTTPR
>> > - 128b/132b vs. 8b/10b
>> > - DPCD 1.4+ vs. earlier
>> >
>> > Add helpers to get the correct delays in us, reading DPCD if
>> > necessary. This is more straightforward than trying to retrofit the
>> > existing helpers to take 128b/132b into account.
>> >
>> > Having to pass in the DPCD receiver cap field seems unavoidable, because
>> > reading it involves checking the revision and reading extended receiver
>> > cap. So unfortunately the interface is mixed cached and read as needed.
>> >
>> > v2: Remove delay_us < 0 check and the whole local var (Ville)
>> >
>> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> > Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>> 
>> Maarten, Maxime, Thomas -
>> 
>> Ack on the first two patches in this series?
>> 
>> Should we merge them via a topic branch to both drm-misc-next and
>> drm-intel-next, or is it fine to merge them all via drm-intel-next? We
>> might be at a point in the development cycle that it takes a while to
>> get the branches in sync again.
>
> I guess the easiest would be to send a PR so that we can merge it in the
> two branches then.

Sent.

https://lore.kernel.org/r/878ryps5b6.fsf@intel.com

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center