On Mon, 18 Oct 2021, Maxime Ripard <maxime@xxxxxxxxxx> 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@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. Sent. https://lore.kernel.org/r/878ryps5b6.fsf@xxxxxxxxx BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
