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.