From: Rob Herring <robh@kernel.org>
To: Jun Li <jun.li@nxp.com>
Cc: "heikki.krogerus@linux.intel.com"
<heikki.krogerus@linux.intel.com>,
"rafael@kernel.org" <rafael@kernel.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"andriy.shevchenko@linux.intel.com"
<andriy.shevchenko@linux.intel.com>,
"hdegoede@redhat.com" <hdegoede@redhat.com>,
"lee.jones@linaro.org" <lee.jones@linaro.org>,
"mika.westerberg@linux.intel.com"
<mika.westerberg@linux.intel.com>,
"dmitry.torokhov@gmail.com" <dmitry.torokhov@gmail.com>,
"prabhakar.mahadev-lad.rj@bp.renesas.com"
<prabhakar.mahadev-lad.rj@bp.renesas.com>,
"laurent.pinchart+renesas@ideasonboard.com"
<laurent.pinchart+renesas@ideasonboard.com>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
dl-linux-imx <linux-imx@nxp.com>, Peter Chen <peter.chen@nxp.com>
Subject: Re: [PATCH v5 1/4] dt-bindings: usb: add documentation for typec switch simple driver
Date: Mon, 9 Nov 2020 08:37:53 -0600 [thread overview]
Message-ID: <CAL_Jsq+OB=aGN+sVAtN89x3LjaRXi_BCy94uceDKmvD+7MnV0g@mail.gmail.com> (raw)
In-Reply-To: <VE1PR04MB6528D5291F820CDDA8EBE65A89EA0@VE1PR04MB6528.eurprd04.prod.outlook.com>
On Mon, Nov 9, 2020 at 6:24 AM Jun Li <jun.li@nxp.com> wrote:
> > From: Rob Herring <robh@kernel.org>
> > On Fri, Nov 6, 2020 at 5:07 AM Jun Li <jun.li@nxp.com> wrote:
> > > > From: Rob Herring <robh@kernel.org>
> > > > > +properties:
> > > > > + compatible:
> > > > > + const: typec-orientation-switch
> > > > > +
> > > > > + switch-gpios:
> > > > > + description: |
> > > > > + gpio specifier to switch the super speed active channel,
> > > > > + GPIO_ACTIVE_HIGH: GPIO state high for cc1;
> > > > > + GPIO_ACTIVE_LOW: GPIO state low for cc1.
> > > >
> > > > What does active mean? There isn't really an active and inactive state,
> > right?
> > > > It's more a mux selecting 0 or 1 input?
> > >
> > > Yes, I will change the description:
> > > gpio specifier to select the target channel of mux.
> >
> > I wonder if the existing mux bindings should be used here.
>
> If only consider typec switch via "gpio", existing "mux-gpio"
> binding may be used with property "mux-control-names" to be
> "typec-xxx" for match, but we still need create typec stuff at
> mux driver to hook to typec system, so little benefit, considering
> this binding is going to be for a generic typec orientation switch
> simple driver, I think a new typec binding make sense.
You can instantiate drivers without a compatible. That's just the easy
way. However, using the mux binding doesn't necessarily mean you have
to use 'mux-gpio'. Consider if you need to do more control than just
the GPIO line. For example, the chips you mentioned may have a s/w
controlled power supply or reset.
Also, consider what the mux would look like with different control
interfaces. That could be I2C or some sub-block in a PMIC or ??? I'm
sure we already have some examples. I'm not happy with these piecemeal
additions to TypeC related bindings that don't consider more than 1
h/w possibility.
> > > > I think you want flags 0 (aka GPIO_ACTIVE_HIGH) unless there's an
> > > > inverter in the middle.
> > >
> > > This depends on the switch IC design and board design, leave 2 flags
> > > (GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW) can cover all possible cases.
> > >
> > > NXP has 2 diff IC parts for this:
> > > 1. PTN36043(used on iMX8MQ)
> > > Output selection control
> > > When SEL=0, RX_AP_*/TX_AP_* are connected to RX_CON_2*/TX_CON_2*, and
> > > RX_CON_1*/TX_CON_1* are connected to VDD thru low ohmic resistor.
> > > When SEL=1, RX_AP_*/TX_AP_* are connected to RX_CON_1*/TX_CON_1*, and
> > > RX_CON_2*/TX_CON_2* are connected to VDD thru low ohmic resistor.
> > >
> > > Board design connects RX_CON_1*/TX_CON_1* to typec connector CC1, so
> > > GPIO_ACTIVE_HIGH
> > >
> > > 2. CBTU02043(used on iMX8MP)
> > > SEL Function
> > > --------------------------------------
> > > Low A to B ports and vice versa
> > > High A to C ports and vice versa
> > >
> > > Board design connects B to typec connector CC1, so GPIO_ACTIVE_LOW
> > >
> > > Therefore, we need 2 flags.
> >
> > I'm not saying you don't. Just that the description is a bit odd.
> > Please expand the description for how one decides how to set the flags.
>
> Misunderstood your point, OK, I thought the "how to set the flags" was
> simple and clear enough:
> Use GPIO_ACTIVE_HIGH if GPIO physical state high is for cc1; or
> Use GPIO_ACTIVE_LOW if GPIO physical state low is for cc1.
Okay.
> > > > > +examples:
> > > > > + - |
> > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > + ptn36043 {
> > > > > + compatible = "typec-orientation-switch";
> > > > > + pinctrl-names = "default";
> > > > > + pinctrl-0 = <&pinctrl_ss_sel>;
> > > > > + switch-gpios = <&gpio3 15 GPIO_ACTIVE_HIGH>;
> > > > > +
> > > > > + port {
> > > > > + usb3_data_ss: endpoint {
> > > > > + remote-endpoint = <&typec_con_ss>;
> > > >
> > > > The data goes from the connector to here and then where? You need a
> > > > connection to the USB host controller.
> > >
> > > The orientation switch only need interact with type-c, no any
> > > interaction with USB controller, do we still need a connection to it?
> >
> > If you have 2 USB hosts and 2 connectors (and 2 muxes), how would you describe
> > which connector goes with which host?
>
> One instance of typec orientation switch defined by this binding only for
> One typec connector. With that, my understanding is
> Whether a connection need be described depends on if the connector
> (typec driver) need notify the host controller driver to do something
> (e.g. role switch need a connection between controller node and connector
> node for controller driver to swap usb role). If the mux/switch control is
> transparent to usb host controller (e.g. my case, usb controller drivers
> normally don't need do anything for orientation change), there is no need
> to describe connection between orientation switch node and host controller
> node.
There can be several reasons you need to know the association. When
writing the DT you can't assume what information is or isn't needed.
That may vary by h/w or can evolve in an OS and the DT shouldn't
change.
Rob
next prev parent reply other threads:[~2020-11-09 14:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-03 11:40 [PATCH v5 1/4] dt-bindings: usb: add documentation for typec switch simple driver Li Jun
2020-11-03 11:40 ` [PATCH v5 2/4] device property: Add fwnode_is_compatible() and device_is_compatible() helpers Li Jun
2020-11-03 11:40 ` [PATCH v5 3/4] usb: typec: mux: add "compatible" property for switch match Li Jun
2020-11-10 10:51 ` Heikki Krogerus
2020-11-03 11:40 ` [PATCH v5 4/4] usb: typec: mux: add typec switch simple driver Li Jun
2020-11-09 8:36 ` Heikki Krogerus
2020-11-24 1:56 ` Jun Li
2020-11-05 22:25 ` [PATCH v5 1/4] dt-bindings: usb: add documentation for " Rob Herring
2020-11-06 11:07 ` Jun Li
2020-11-06 14:24 ` Rob Herring
2020-11-09 12:24 ` Jun Li
2020-11-09 14:37 ` Rob Herring [this message]
2020-11-11 15:40 ` Jun Li
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='CAL_Jsq+OB=aGN+sVAtN89x3LjaRXi_BCy94uceDKmvD+7MnV0g@mail.gmail.com' \
--to=robh@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hdegoede@redhat.com \
--cc=heikki.krogerus@linux.intel.com \
--cc=jun.li@nxp.com \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=lee.jones@linaro.org \
--cc=linux-imx@nxp.com \
--cc=linux-usb@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=peter.chen@nxp.com \
--cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
--cc=rafael@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).