caveh jalali has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37870 )
Change subject: soc/intel/tigerlake: Add code for early tcss ......................................................................
Patch Set 16:
(2 comments)
https://review.coreboot.org/c/coreboot/+/37870/16/src/soc/intel/tigerlake/ea... File src/soc/intel/tigerlake/early_tcss.c:
https://review.coreboot.org/c/coreboot/+/37870/16/src/soc/intel/tigerlake/ea... PS16, Line 29: * Flags representing mux state */ : #define USB_PD_MUX_USB_ENABLED BIT(0) /* USB connected */ : #define USB_PD_MUX_DP_ENABLED BIT(1) /* DP connected */ : #define USB_PD_MUX_POLARITY_INVERTED BIT(2) /* CC line Polarity inverted */ : #define USB_PD_MUX_HPD_IRQ BIT(3) /* HPD IRQ is asserted */ : #define USB_PD_MUX_HPD_LVL BIT(4) /* HPD level is asserted */ : we can get these from ec_commands.h, right?
https://review.coreboot.org/c/coreboot/+/37870/16/src/soc/intel/tigerlake/ea... PS16, Line 158: mux_data.polarity = mux_flags & USB_PD_MUX_POLARITY_INVERTED; i'm a bit confused about the polarity and muxing policy. if there is no external retimer/redriver/TCPC, then TCSS has to do the muxing and it makes sense to ask the EC what the cable orientation is in order to set the mux appropriately.
what happens when the muxing is potentially done externally? should we disable/prevent this by system design? my guess is that if we do have a case where muxing is done externally for some reason, the EC will still report the observed orientation and we'll end up double flipping the lanes.
has this aspect of the system design been captured somewhere?
-
caveh jalali (Code Review)