On Mon, Nov 9, 2020 at 6:24 AM Jun Li <jun.li@xxxxxxx> wrote: > > From: Rob Herring <robh@xxxxxxxxxx> > > On Fri, Nov 6, 2020 at 5:07 AM Jun Li <jun.li@xxxxxxx> wrote: > > > > From: Rob Herring <robh@xxxxxxxxxx> > > > > > +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