From: Bjorn Andersson <andersson@kernel.org>
To: Prashant Malani <pmalani@chromium.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
Stephen Boyd <swboyd@chromium.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
linux-usb@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
Pin-yen Lin <treapking@chromium.org>
Subject: Re: [PATCH 1/2] dt-bindings: usb: Introduce GPIO-based SBU mux
Date: Thu, 25 Aug 2022 22:02:22 -0500 [thread overview]
Message-ID: <20220826030222.jmgjlsf7p3sx2lld@baldur> (raw)
In-Reply-To: <CACeCKaewr92JcouMgyiL5rKdHf_dDmoWoyoW-U2snCNBkNijQg@mail.gmail.com>
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@linaro.org> 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
next prev parent reply other threads:[~2022-08-26 3:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-10 20:47 [PATCH 0/2] usb: typec: mux: GPIO-based SBU mux Bjorn Andersson
2022-08-10 20:47 ` [PATCH 1/2] dt-bindings: usb: Introduce " Bjorn Andersson
2022-08-11 9:14 ` Krzysztof Kozlowski
2022-08-14 21:01 ` Rob Herring
2022-08-17 23:00 ` Bjorn Andersson
2022-08-19 1:09 ` Stephen Boyd
2022-08-19 20:14 ` Prashant Malani
2022-08-19 20:49 ` Stephen Boyd
2022-08-19 21:39 ` Bjorn Andersson
2022-08-19 22:18 ` Prashant Malani
2022-08-20 4:04 ` Bjorn Andersson
2022-08-23 18:21 ` Prashant Malani
2022-08-19 22:00 ` Bjorn Andersson
2022-08-19 22:55 ` Prashant Malani
2022-08-20 4:09 ` Bjorn Andersson
2022-08-23 18:54 ` Prashant Malani
2022-08-26 3:02 ` Bjorn Andersson [this message]
2022-08-19 21:26 ` Bjorn Andersson
2022-08-20 3:51 ` Stephen Boyd
2022-08-20 4:56 ` Bjorn Andersson
2022-08-26 1:49 ` Stephen Boyd
2022-08-10 20:47 ` [PATCH 2/2] usb: typec: mux: " Bjorn Andersson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220826030222.jmgjlsf7p3sx2lld@baldur \
--to=andersson@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=pmalani@chromium.org \
--cc=robh@kernel.org \
--cc=swboyd@chromium.org \
--cc=treapking@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.