• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 63 subscribers
  • Views 96 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

TPS65988: UCSI support

TPS65988: UCSI version supported, and specification conformance

Mattias Johansson
Prodigy 40 points
Part Number: TPS65988

Hi!

I can't seem to find any notice about what version of UCSI is supported on TPS65988DH device. It's not stated in the data sheet or the Technical Reference Manual.

Also, according to chapter 4.15 in slvubh2b.pdf (Technical Reference Manual) some data descriptions do not match the UCSI specification. For example, Table 4-52. UCSI - PPM_RESET, byte 3, bits 6:0 "Connection Number". According to UCSI specification (versions 1.0, 1.2, 2.0 and 3.0), bytes 3-8 of PPM_RESET is "Reserved and shall be set to zero.". So custom ucsi frameworks (such as the one in the linux kernel) will most probably insert zeros in bytes 3-8, which will result in "Task Rejected" according to "Connection Number" description in Table 4-52.

See linux implementation of PPM_RESET here: https://elixir.bootlin.com/linux/v5.19.17/source/drivers/usb/typec/ucsi/ucsi.c#L870

Best Regards,

Mattias

  • 0
    TI__Mastermind 20485 points

    Hi,

    Our UCSI - PPM_RESET has a slight deviation from the UCSI spec due to our design so the connector number is required to be 0x01 or 0x02.

    Regards

  • 0 in reply to Tommy Lin
    Prodigy 40 points

    Hi!

    So you are not UCSI compliant then, since we will have to modify some messages coming from a ucsi framework before there sent to the TPS65988? Well, that we can live with if we know all deviations from the spec.

    Are there anymore deviations? Are they documented somewhere (except from having to diff your spec against the UCSI spec)? What version is supported? The UCSI specification (version 1) specifies 19 controller commands. The slvubh2b.pdf specifies only 11 commands. What about the remaining 8 commands? For example, the command ACK_CC_CI (0x04h) command is used a lot in the linux ucsi implementation. It's not mentioned in slvubh2b.pdf. Is it implemeted or not? And if it is, is it compliant to the spec?

    Best Regards,

    Mattias

  • 0 in reply to Mattias Johansson
    TI__Mastermind 20485 points

    Hi,

    Our PD supports UCSI command. It is compliant with UCSI if there is an EC that receives and parse UCSI command then send I2C to PD so not all commands are implemented in PD.

    Seems like you are looking to use TPS65988 under Linux system, I would recommend looking into this driver code here. https://github.com/brgl/linux/blob/master/drivers/usb/typec/tps6598x.c

    Regards

  • 0 in reply to Tommy Lin
    Prodigy 40 points

    Hi!

    The questions are not answered I'm afraid. And let's agree to disagree about what's conformant and what's not, it's not that interesting :)

    I use linux as an example, because it's, in my opinion, easy to relate to, and the source is open to everyone. It's the principle I'm after.

    Let's take a simle example. I have an embedded controller connected to the TPS65988DH over i2c. i2c addresses are 0x20 and 0x24 (7-bit) for the ports respectively. I have a UCSI framework which handles the logic. This framework gives me controller messages (according to the UCSI spec, version is customizable) to relay to the PD controller. Let's say I get the message 0x01h 0x00h 0x00h 0x00h 0x00h 0x00h 0x00h 0x00h, which is a UCSI compliant PPM_RESET message. I know by reading the slvubh2b.pdf file and previous response on this topic that I cannot blindly relay this message to the UCSI 4CC command. I need to modify the message to 0x01h 0x00 0x01h ... (fort port 1) or 0x01h 0x00h 0x02h... (for port 2) before I send it on the i2c bus.

    Now I get another message 0x04h 0x00h 0x01h 0x00h 0x00h 0x00h 0x00h 0x00h, which is a UCSI compliant ACK_CC_CI command. What to do now? Since the ACK_CC_CI command is not mentioned in slvubh2b.pdf my best bet is to simply ignore it, and send nothing on the i2c bus, correct? If not, can I send it unmodified?

    It would be nice if deviations from the UCSI spec are documented somewhere. I can do a manual "diff" between slvubh2.pdf and the UCSI spec to find out what differs, but I think this ought to be documented somewhere (so I don't have to dig in to the specs all the time :) ).

    Best Regards,

    Mattias

  • +1 in reply to Mattias Johansson
    TI__Mastermind 20485 points

    Hi,

    The UCSI commands listed in the TRM are the only UCSI commands that are supported by the device. Any other 4CC commands that are not listed in TRM are not supported and requires EC to parse the UCSI command then retrieve relevant information from PD. 

    Using Windows system as example, OS (OPM) sends UCSI commands to EC that has UCM driver (PPM), then EC (PPM) parse the commands and retrieve information from PD (LPM) via USCI 4CC command or reading register content.

    ACK_CC_CI command is a command between OPM and PPM, PD (LPM) is not directly involved here so this command string (0x04h 0x00h 0x01h 0x00h 0x00h 0x00h 0x00h 0x00h) will not be sent to PD (LPM) but it might requires PPM to retrieve register data via register read or other means. Same logic applies to other UCSI commands, not all command strings can be passed directly to PD (LPM) and this depends on how the EC driver is implemented.

    I do not know what command requires what information from PD as some of them are not explicitly stated in UCSI spec but we should have the required information in our device registers. 

    We do not have the UCSI command comparison as UCSI commands are between OPM and PPM. What we provided is an interface for PPM to access PD (LPM) so it will inherently be different.

    Regards

  • 0 in reply to Tommy Lin
    Prodigy 40 points

    Hi!

    Thanks, now it's clear to me. I might need to call other 4CC commands and/or read/write registers in my EC according to what UCSI messages I receive.

    Thanks for your time!

    Best regards,

    Mattias