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

Maxime Ripard
2021-10-18T08:41:55Z

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

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.

Maxime

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