USB3 Data Port with External PD Control
Added by David Cuccia 7 days ago
Hey Team,
I'm working on porting a hardware design for a custom carrier board to leverage the MitySOM platform. This carrier board owns the USB3 port's CC lines for PD negotiation and cable orientation detection. We don't need DisplayPort in our use case.
The reference board has CC1 and CC2 routed to the SOM and uses all the data lines routed to the redriver for DP. We only need USB3 data and we have an external USB-PD control IC on our carrier board that handles cable orientation and controls an USB3 orientation mux for TX/RX from the USB-C connector.
I need some help with figuring out how to route my muxed TX and RX from the orientation mux to the SOM. A couple of questions below:
1) Can the MitySOM's USB3 interface be used when the SOM isn't connected to CC1/2 and does not control or know cable orientation?
2) If yes, which lane pair should be treated as the native/default USB3 lane into the external orientation mux: RX0/TX0 (J10-11, J14-15) or RX1/TX1 (G16-17, I16-17)?
3) What should be done with the unused RX/TX pairs, CCs, DP-AUX, SBUs, can they be left floating?
Is there anything else that I'd need to account for on the SOM side to get this configuration working? I've attached a quick block diagram to try to help clarify what I'm trying to do - thanks for the help!
Replies (3)
RE: USB3 Data Port with External PD Control - Added by William Evans 5 days ago
Hello David,
After thinking about this, here are my thoughts.
The MitySOM-QC natively supports USB 3.0 signal MUXing as well as USB PD. The simplest path, if you're not committed to the external PD/MUX, is to let the SOM handle both.
If you are committed to the MUX and PD on the baseboard, then I believe we could accomplish this.
Considering the PD controller communicates cable orientation, it likely also has information about whether the connected USB cable is a device or a host. On some of the various PD controllers we have used, all of this information is available from registers on the PD controller. Regardless of the interface, if this is connected back to the processor, then we should be able to use that information. Linux has a USB role switch kernel framework that is designed for this case so it can be configured to determine the SOM's role based on input from the PD controller. You would have to ensure that cable orientation is always registered as "un-flipped" at the processor as that is handled by the baseboard MUX. This should allow the processor to act as a host or a device as well as support dual-role.
To answer your third question, all unused USB0 signals can be left floating.
Please let me know if you have any further questions!
RE: USB3 Data Port with External PD Control - Added by David Cuccia 5 days ago
Hello William,
Thanks for your response!
Unfortunately we're locked into having the MUX/PD on the baseboard, so we can't continue down the easy path.
But I've checked and confirmed that the PD controller we are using exposes all information about the USB-C connection over I2C to be read out. So we could connect the PD controller's I2C bus to the processor and the processor should be able to get the exact state of the USB-C port and attached cable (host or device).
Please forgive my naivety, but in response to this: "You would have to ensure that cable orientation is always registered as "un-flipped" at the processor...". Would this be something that we could configure in software or are you suggesting that we tie the processor's CC lines to a specific orientation to emulate an un-flipped connection? Sorry, I'm just the hardware guy and this seems to be creeping out of my circle of competence...
But overall this is sounding hopeful - I appreciate your help!
RE: USB3 Data Port with External PD Control - Added by William Evans 2 days ago
Good morning David, I hope you had a good weekend!
I'm not super familiar with the kernel framework but I would think that it would get both the "role" the processor needs to be (either host or device) as well as the "orientation" of the cable (flipped or un-flipped). The MUX is already retrieving and being configured based on the orientation of the cable so the processor only needs the role from the PD controller. As we would only be connecting the one RX and TX pair from the MUX to the processor, the orientation (from the processor's perspective) should always be the same.
So to answer your question, the CC lines should be able to be left floating. The USB role switch kernel framework essentially replaces the native CC line detection in favor of fetching it from elsewhere (the PD controller in this case). Then, the kernel framework would have to be configured in software so that only the role was being fetched and the orientation is static at the processor. This should result in the PD and orientation being handled from the base board while the processor would be able to function in host, device, or dual-role.
