On 02/11/2022 20:28, Doug Anderson wrote:
Hi,
On Wed, Nov 2, 2022 at 10:23 AM Dmitry Baryshkov
<dmitry.baryshkov@xxxxxxxxxx> wrote:
1. Someone figures out how to model this with the bridge chain and
then we only allow HBR3 if we detect we've got a TCPC that supports
it. This seems like the cleanest / best but feels like a long pole.
Not only have we been trying to get the TCPC-modeled-as-a-bridge stuff
landed for a long time but even when we do it we still don't have a
solution for how to communicate the number of lanes and other stuff
between the TCPC and the DP controller so we have to enrich the bridge
interface.
I think we'd need some OOB interface. For example for DSI interfaces we
have mipi_dsi_device struct to communicate such OOB data.
Also take a note regarding data-lanes from my previous email.
Right, we can somehow communicate the max link rate through the bridge
chain to the DP controller in an OOB manner that would work.
I'd note that our dp_panel has some notion of such OOB data. So do AUX
drivers including the panel-edp. My suggestion would be to consider both
of them while modelling the OOB data.
2. We add in a DT property to the display controller node that says
the max link rate for use on this board. This feels like a hack, but
maybe it's not too bad. Certainly it would be incredibly simple to
implement. Actually... ...one could argue that even if we later model
the TCPC as a bridge that this property would still be valid / useful!
You could certainly imagine that the SoC supports HBR3 and the TCPC
supports HBR3 but that the board routing between the SoC and the TCPC
is bad and only supports HBR2. In this case the only way out is
essentially a "board constraint" AKA a DT property in the DP
controller.
We have been discussing similar topics with Abhinav. Krzysztof suggested
using link-frequencies property to provide max and min values.
This sounds good to me and seems worth doing even if we eventually do #1.
And the bonus point is that it can be done easily.
--
With best wishes
Dmitry
