Hi Hari,
Here is the Type-C PD I2C usages of our current design:
- PD I2C_EC/IRQ <-> MCU
- PD I2Cs/IRQ <-> SoC (Intel)
- PD I2C3m <-> Burnside Bridge Re-timer (one for each Type-C Port)
We are seeing an issue:
- When a USB3 device is plugged to a Type-C port, PD writes DATA_STATUS (reg. 0x5F) value to the Re-timer (offset 0x04, connection status) of the port.
- However, from the captures on I2C3m, it is noticed PD writes to the Re-timer with DATA_STATUS bit-24 = 1b.
- In PD manual (SLVUBT3, May 2020), DATA_STATUS bit-24 is defined as "Reserved".
- In Re-timer spec, this bit however is defined as "Power_Mismatch, 1b - USB PD power mismatch. Not enough power for S0".
- We are warned that PD setting this bit as 1b could affect Re-timer operation.
From our observation:
- Since PD is also configured to alert SoC port events over I2Cs_IRQ, so SoC attempts to read DATA_STATUS from PD as well.
- However, from the captures on I2Cs, it is noticed SoC reads from PD with DATA_STATUS bit-24 = 0b.
- For the same port plug event, I2C3m transaction is ~2.4ms ahead of I2Cs transaction as you could see from below logs.
- It appears that DATA_STAUS bit-24 = 1b only lasts for a while.
Please help to check:
- Why this reserved bit would become 1b? Our understanding is a reserved bit should always read as 0b.
- Is this PD configuration related?
- Any way to avoid DATA_STATUS bit-24 = 1b from being written to Re-timer?
Also let us know if you need more information.
Thanks,
Jonathan