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

[Maxime Ripard]

Hi Jani,

On Fri, Oct 15, 2021 at 06:21:35PM +0300, Jani Nikula wrote:
> On Thu, 14 Oct 2021, Jani Nikula <jani.nikula at 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 at linux.intel.com>
> > Reviewed-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > Signed-off-by: Jani Nikula <jani.nikula at 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.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20211018/01322c11/attachment.sig>