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: Fri, 19 Aug 2022 15:18:15 -0700 [thread overview]
Message-ID: <CACeCKaeXpU+AxFNAwkutMX9LT2XLgAv1XmwJRyj7Exqxg6v8rA@mail.gmail.com> (raw)
In-Reply-To: <YwADGgNVwtKacUBR@builder.lan>
On Fri, Aug 19, 2022 at 2:39 PM Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
>
> On Fri 19 Aug 15:49 CDT 2022, Stephen Boyd wrote:
>
> > > I like 2 endpoints to represent the usb-c-connector, but that doesn't seem
> > > to be compatible (without introducing `data-lanes`, at least) with all
> > > the various
> > > combinations on the remote side, if that remote side is a DRM bridge with DP
> > > output capability (like it6505 or anx7625).
> > > That type of DRM bridge supports 1, 2 or 4 lane DP connections.
> >
> > Why can't the remote side that's a pure DP bridge (it6505) bundle
> > however many lanes it wants into one endpoint? If it's a pure DP bridge
> > we should design the bridge binding to have up to 4 endpoints, but
> > sometimes 2 or 1 and then overlay data-lanes onto that binding so that
> > we can tell the driver how to remap the lanes if it can. If the hardware
> > can't support remapping lanes then data-lanes shouldn't be in the
> > binding.
2 endpoints sounds fine to me. The overloading of the bridge-side endpoint
to mean different things depending on what it's connected to seemed odd to
me, but if that is acceptable for the bridge binding, then great.
> The existing implementation provides the interfaces usb_role_switch,
> usb_typec_mux and usb_typec_switch. These works based on the concept
> that the USB Type-C controller will request the endpoints connected to
> the usb-c-connector about changes such as "switch to host mode", "switch
> to 2+2 USB/DP combo" and "switch orientation to reverse". We use this
> same operations to inform any endpoint at any port about these events
> and they all react accordingly.
Right, but that implementation/assumption doesn't work so well when you
have 2 Type-C ports which might route to the same bridge (2 lane from each).
The other 2 lanes from the other endpoints can go to (say) a USB HUB.
>
> Perhaps I'm misunderstanding your suggestion, but if you start
> representing each individual lane in the SuperSpeed interface I believe
> you would have to just abandon this interface and replace it with
> something like "give me USB on port@1/endpoint@0 and port@1/endpoint@1
> and give me DP on port@1/endpoint@2 and port@1/endpoint@3".
I don't think that is necessary. The switch driver can register the switches (
and it can find out which end-points map to the same usb-c-connector).
From the port driver, the port driver just needs to tell each switch
registered for it's port that "I want
DP Pin assignment C/ DP Pin assignment D / Plain USB3.x" and the
switch driver(s) can figure out what to output on its pins (since
the Type-C binding will specify ep0 = A2-A3 (TX1), ep1 = B10-B11 , etc)
orientation-switch can tell the switch if the signals need to be swapped around.
The above notwithstanding, it sounds like the 2-ep approach has more support
than 4 ep-approach, so this specific example is moot.
next prev parent reply other threads:[~2022-08-19 22:18 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 [this message]
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
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=CACeCKaeXpU+AxFNAwkutMX9LT2XLgAv1XmwJRyj7Exqxg6v8rA@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.