From: Prashant Malani <pmalani@chromium.org>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: 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: Tue, 23 Aug 2022 11:54:53 -0700 [thread overview]
Message-ID: <CACeCKaewr92JcouMgyiL5rKdHf_dDmoWoyoW-U2snCNBkNijQg@mail.gmail.com> (raw)
In-Reply-To: <YwBei45gx4oVqSql@builder.lan>
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).
BR,
-Prashant
next prev parent reply other threads:[~2022-08-23 19:51 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 [this message]
2022-08-26 3:02 ` Bjorn Andersson
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=CACeCKaewr92JcouMgyiL5rKdHf_dDmoWoyoW-U2snCNBkNijQg@mail.gmail.com \
--to=pmalani@chromium.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=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.