Hi Jani, On Fri, Oct 15, 2021 at 06:21:35PM +0300, Jani Nikula wrote: > On Thu, 14 Oct 2021, Jani Nikula <jani.nikula@xxxxxxxxx> 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@xxxxxxxxxxxxxxx> > > Reviewed-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > Signed-off-by: Jani Nikula <jani.nikula@xxxxxxxxx> > > 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:
signature.asc
Description: PGP signature
