It appears the the TCPCI spec does not allow for the TCPC to present 2 different Rp values. The ROLE_CONTROL register (0x1A) specifies that B5..4 control the Rp setting for both CC1 and CC2 lines when they are set to Rp.

How are we supposed to comply with the DTS requirements to set the Rp resistors to different values when acting as a DTS Source? Am I missing something in the TCPCI spec or does it need to be updated (and then TCPC chip manufactures need to add the new functionality)?

My understanding is that it would be a specially designed debug device. For example, servo_v4 is a board in our repo that behaves as a DTS source. It uses our own TCPC driver (e.g glados_pd, samus_pd, etc.) which allows setting differnt Rp values. I'm not sure if you can pick an "off the shelf" TCPCI compliant TCPC to make a DTS source.

Debug devices roll their own stuff and require captive cables to function and present differing CCs.  They don't fall under TCPCI's purview, which focuses only on the parts that make it into consumer devices.  TCPCI doesn't allow devices to mismatch their Rps because that is not valid behavior for anything other than the resistors in one of these specialized debug devices.

servoV4 now supports being in snkdts mode (which means it presents Rd Rd), but our chromebooks can't fulfill the role of srcdts by applying the correct Rp values.

Is it invalid for servoV4 to try to be a DTS SNK since everything it connects to cannot be a DTS SRC?

SRCDTS is another type of debug device.  Our chromebooks are never *DTSes.

Maybe I am using the wrong terminology for the chromebook side when it connect with a servoV4.

It sounds like servoV4 should never connect to a chromebook when the servoV4 is in snkdts, right?

ServoV4 can connect to the Chromebook in either mode.  When ServoV4 is a SNKDTS, the Chromebook is a DRP source.  When ServoV4 is a SRCDTS, the Chromebook is a DRP sink.

When Servo exports RdRd, how should PD polarity be determined?

There's additional behavior needed on the SNKDTS side to signal its polarity.  Check B.2.6.1.2 in the Type-C 1.3 spec.  Alternatively, the DRP Source could just assume CC1 polarity when it sends out its SourceCapabilities and servov4 could flip its own logic accordingly.

The behavior described in B.2.6.1.2 has the SNK drop one of its Rd's down to an Ra (or short). Then the SRC will know what CC line is used for communication.

However, won't this break CR50's detection of Rdd [0]? In light of that, maybe the servoV4 just listens for SrcCap messages on both CC lines instead (like David mentioned in comment 10).

Right now, the chromebook state machine does just assume CC1 for the polarity when Rd/Rd is detected.


[0] https://chromium.git.corp.google.com/chromiumos/platform/ec/+/4d4d8f06e91090336c2eb29ee00ca86fea2bb796/chip/g/rdd.c#116

Note that servo v4 doesn't need to negotiate any pd as a SNK, since it draws no power. So if polarity doesn't work it's fine. The main issue is that the CC lines should stay in Cr50's debug accessory range.

ServoV4 is already presenting the correct Rd/Rd values, so cr50's detection already does work.

If ServoV4 detects the polarity (based on SrcCaps), that would make the USB-C cable from the servoV4 to the DUT reversible (unlike the SuzyQ), right?

That's correct, although SuzyQ is supposed to be reversible, pending b/62203831

servo v4 is reversible from the CCD over SBU perspective already. The issue here is whether it's reversible from the USB PD standpoint.

I was under the impression that the CC polarity for PD communication also determined the polarity on the MUX for either the source or sink (or both) that allowed proper USB data/SBU/PD communication.

I guess there is a different polarity mechanism for servoV4?

CCD has a different polarity mechanism, it just detects USB init voltage level on SBU. Cr50 doesn't have access to PD and just has fixed polarity in most designs. So only CC voltage levels corresponding to RdRd/RpRp trigger CCD.

For the immediate case, servo_v4 doesn't use PD at all as a SNK (it never takes power from the dut at all), so whether polarity is detected doesn't really affect functionality, it just causes timeouts.

Dropping one CC to short isn't possible in servo_v4 hardware, and Ra is also not provisioned on servo_v4. 

Closing since there is no issue. Thanks for the explanations!