On Fri, 22 Mar 2024 at 17:23, Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx> wrote: > > On 22/03/2024 15:09, neil.armstrong@xxxxxxxxxx wrote: > >> TBH I think we should drop this HS, SS stuff from the connector > >> definition - there's nothing to say in a h/w definition anywhere HS > >> must be a port or indeed SS - not all hardware knows or cares about > >> different HS/SS signalling. > > > > It matches the USB-C connector electrical characteristics, which by spec > > has, at least: > > - High-Speed USB Line > > - up to 4 differential high-speed lanes that can be switched to DP, USB2 > > or PCIe > > - SideBand line (SBU) > > > > And those 3 components can be handled by 3 different HW in the SoC, so > > each one has a dedicated port. > > > > Remember DT describes the HW, not the SW implementation. > > > > Neil > > Yes, you're right about that. > > I suppose > > 1. Orientation switches should be defined as coming from a port on the > connector associated with the CC pins. > port@3: > orientation-switch port name goes here > > 2. Data-role switches... > Again the CC pins > > https://community.silabs.com/s/article/what-s-the-role-of-cc-pin-in-type-c-solution?language=en_US > > Maybe the right-thing-to-do is to add another port for the CC pins - > which would still describe the hardware characteristics but would > _accurately_ name the thing which does the data-role/orientation switching It's true that we don't describe CC lines. However In most of the cases CC lines are handled by the Type-C port manager directly. So there will be a connection from usb-c-connector to the pmic-typec itself (which looks pretty redundant). The TCPM then sends these events to the interested parties. SS and SBU chains really care only about orientation (to be able to remux SS lanes and SBU polarity). USB data role is only relevant for the USB controller itself. So either we should add special role-switching link from the TCPM to USB-controller, or just reuse the HS link. > > CC1/CC2 > > Then we would not be abusing HS/SS/SBU for the port names - we'd be > extending the connector definition but also naming the ports/endpoints > appropriately associated with the data over the hw -- With best wishes Dmitry
