Messages in this thread | | | Subject | Re: [PATCH v1 2/2] phy: phy-cadence-torrent: Use PHY kernel APIs to set PHY attributes | From | Tomi Valkeinen <> | Date | Fri, 8 May 2020 10:50:10 +0300 |
| |
On 07/05/2020 20:17, Maxime Ripard wrote:
>> 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.
I don't think this is negotiation, but just exposing the (max) capabilities of PHY, inside which the configure can work. Maybe all the capabilities could handled with a struct (struct phy_attrs), instead of adding separate functions for each, though.
Tomi
-- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
| |