Hi, On 5/8/2020 1:20 PM, Tomi Valkeinen wrote: > 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.
yeah, that makes sense. Just that users should take care not to over-write all the phy attributes with partial information. Thanks Kishon
