On 15/11/2022 21:43, Kuogee Hsieh wrote:
On 11/9/2022 11:43 PM, Dmitry Baryshkov wrote:
On 10/11/2022 02:47, Kuogee Hsieh wrote:
On 11/2/2022 11:04 AM, Dmitry Baryshkov wrote:
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.
questions,
1)is Krzysztof suggested had been implemented?
I can not parse this question, please excuse me.
Yes, Krzysztof suggested this being implemented as a link property,
see media/video-interfaces.txt.
Moreover your implementation goes against both the existing definition
(array with the list of frequencies) and Krzysztof's suggested
extension (min and max). Listing just a single frequency goes against
both these suggestions. In case of DP we have a fixed set of
frequencies. Thus I'd suggest listing all supported frequencies instead.
I think this proposal is kind of strange.
According to DP spec, if a link support 5,4G, then it must support 1.6,
2.7 and 5.4.
If it support 8.1G, then it must support 1.6 , 2.7 and 5.4.
There is no link can only support 2.7 and 5.4G without supporting 1.6G.
Let me quote the docs.
link-frequencies:
$ref: /schemas/types.yaml#/definitions/uint64-array
description:
Allowed data bus frequencies. For MIPI CSI-2, for instance, this
is the
actual frequency of the bus, not bits per clock per lane value.
An array
of 64-bit unsigned integers.
Note. 'allowed data bus frequencies'. So by listing only the max
frequency you'd break this description.
--
With best wishes
Dmitry
