RE: [PATCH v5 1/4] dt-bindings: usb: add documentation for typec switch simple driver

[Jun Li <jun.li@nxp.com>]

Hi Rob

> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: Monday, November 9, 2020 10:38 PM
> To: Jun Li <jun.li@nxp.com>
> Cc: heikki.krogerus@linux.intel.com; rafael@kernel.org;
> gregkh@linuxfoundation.org; andriy.shevchenko@linux.intel.com;
> hdegoede@redhat.com; lee.jones@linaro.org;
> mika.westerberg@linux.intel.com; dmitry.torokhov@gmail.com;
> prabhakar.mahadev-lad.rj@bp.renesas.com;
> laurent.pinchart+renesas@ideasonboard.com; linux-usb@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
> 
> 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.

As typec class sub system already has its own interface(and users)
to do switch/mux control, using existing mux bindings means typec class will
add switch/mux control through another approach(mux chip/controller interface),
this makes the typec mux looks having 2 similar way for the same function.
so I was hesitating to use it.

After more check, I agree creating typec specific bindings will duplicate
much existing mux bindings, the mux controller based bindings can be a good
way used for various typec switch/mux, so I will try typec orientation
compatible with mux controller bindings.

> 
> > > > > 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.

Okay, I will add the connection to usb controller in example.

Thanks
Li Jun
> 
> Rob