Actually, for this particular case, consumer driver will be the Cadence MHDP
bridge driver for DisplayPort which is also under review process for
upstreaming [1]. So this DRM bridge driver will make use of the PHY APIs
phy_get_bus_width() and phy_get_max_link_rate() during execution of probe
function to get the number of lanes and maximum link rate supported by Cadence
Torrent PHY. This information is required to set the host capabilities in the
DRM bridge driver, based on which initial values for DisplayPort link training
will be determined.
The changes in this PHY patch series are based on suggestions in the review
comments in [1] which asks to use kernel PHY APIs to read these properties
instead of directly accessing PHY device node. The complete driver and actual
use of these APIs can be found in [2]. This is how we are planning to use
these APIs.
I haven't really looked into the displayport spec, but I'd assume that there's a
lot more parameters that would need to be negociated between the phy and the DP
block? If so, then it would make more sense to follow the path we did for
MIPI-DSI where the parameters can be negociated through the phy_configure /
phy_validate interface.