On Tue, Aug 23, 2022 at 11:54:53AM -0700, Prashant Malani wrote: > On Fri, Aug 19, 2022 at 9:09 PM Bjorn Andersson > <bjorn.andersson@xxxxxxxxxx> wrote: > > > > > > We're talking about the static configuration here, where you describe > > which component are connected together. We can not dynamically switch > > the Devicetree representation around to match what the Type-C controller > > negotiates. > > Yes, but we don't need to switch the device tree representation at all. > The pin routing/connections from the connector (not the cable or the partner), > to the muxing hardware (QMP phy or anx7625) remains fixed always > The port driver tells what orientation the peripheral is connected with, > and the muxing/orientation hardware routes the signals according to that. > > > > > But why do you need to express the relationship between these 2 > > components with > 1 link in the graph? > > > > > The graph is static, since the hardware line routing between components > > > doesn't change (e.g SSTX1 from the Type-C port is always routed to Pin > > > X1,X2 on the switch hardware), but that is what the switch is for. > > > Note that in this case, the expectation is that > > > the switch driver only registers 1 switch (it can figure out that all > > > 4 endpoints > > > go to the same Type-C port). > > > > > > > Why do we need to express this with 4 endpoints and then implement code > > to discover that the 4 endpoints points to the same remote? Why not just > > describe the logical relationship between the two components in one > > endpoint reference? > > The issue I see is with the "supplier" side of that graph relationship > (i.e the DRM bridge side). > Since the bridge can be directly connected to a DP panel, the > endpoints can (technically) > represent a single DP lane. So, using 4 end-points for the > usb-c-connector port@1 gives > us something which is compatible with the bridge side endpoints too > (regardless of what > the bridge is connected to on the "output" side). > Reading the discussion, I agree 4 lanes is over-specifying, and 2 > endpoints is probably > enough (especially if we can use data-lanes on the bridge side > to define the number of lanes if needed for DP panel connections). > I'm sorry, but the part I don't understand is what you gain from representing each physical line in your connection with a remote-endpoint pair? What I propose is that you tie the two pieces together with a single reference. If you need to express the number of data-lanes we have several places where this is described separately, using the "data-lanes" property. With this model, if you have a 1:1 connection you have a single remote-endpoint pair, if you have a 1:N connection, then you would have N remote-endpoint pairs. Regards, Bjorn
