91大神国内在线麻豆 ,精品国产91久久久久久浪潮蜜月

SLVUCR8A September 2023 – March 2024 TPS25751

4.2.7 'GPPI' - PD Get Port Partner Information

The 'GPPI' Task can be used to cause the PD controller to issue these types of USB PD Get messages:

Get_Source_Cap_Extended (control message)
Get_Sink_Cap_Extended (control message)
Get_Country_Codes (Control message)
Get_Country_Info (Data message)
Get_Manufacturer_Info (Extended message)

The PD controller does not have dedicated registers to store the response to these messages. The host must get that response from the DATAX register associated with this Task.

The host must NOT use 'GPPI' to send Get_Sink_Capabilities or Get_Source_Capabilities messages, because the USB PD spec requires specific actions be taken by the PD controller any time those messages are received. While executing the 'GPPI' Task, the PD controller does not parse the returned message to carry out those checks. Instead, the host must use 'GSkC' to send Get_Sink_Capabilities and 'GSrC' to send Get_Source_Capabilities messages.

This Task is defined to enable supporting any new Get message that can be defined by USB PD in the future.

Table 4-9 'GPPI' - Send a USB PD Get* Message

Description	The 'GPPI' Task instructs PD Controller to issue a specific USB PDmessage to the Port Partner at the first opportunity while maintaining policyengine compliance.
INPUT DATAX	Bit	Name	Description
	15	Reserved
	14:13	FrameType
			00b	SOP
			01b	SOP'
			10b	SOP''
			11b	Reserved
	12:8	NumBytes
	7	Reserved
	6:5	MessageCategory
			00b	Control message (no payload)
			01b	Data message (requires payload)
			10b	Extended message (requires payload)
			11b	Reserved
	4:0	MessageType	This field must be the MessageType as defined in the USB PD specification. It specifies the Type of message the PD controller will send.
OUTPUT DATAX	Byte 1: Standard Task Return Code.
Task Completion	The 'GPPI' Task completes either when the appropriate message is received or the Task otherwise fails. The 'GPPI' Task shall be considered rejected if: Sending the requested message can violate the USB PD spec. For example, the Port Partner is a Sink and indicated (through previous Source or Sink Capabilities) it was not Dual-Role Power. The PortPartner replies with a Reject or Not_Supported message. The USB PD spec revision (PlugPartnerNegSpecRev or PortPartnerNegSpecRev in PD3_STATUS register (0x41) does not allow sending the requested message. The 'GPPI' Task shall be considered timed-out if: The requested message is sent, GoodCRC'ed and the recipient (Port Partner or Cable Plug) fails to respond within the time required by the PD spec. A PD Hard Reset or a disconnection happens before the Task completes. The 'GPPI' Task shall be considered successful if: The requested message is sent, GoodCRC'ed and an appropriate response is received and processed. The 'GPPI' Task shall be aborted when the Rx Buffer is locked. The Rx Buffer is locked after data from a receive message is placed in the DATAX register. The Rx Buffer is unlocked after disconnect and by the 'MBRd' Task.
Side Effects	If necessary, the PD controller can issue a VCONN_Swap in order to send the requested message to a Cable Plug. If the PD controller is in the sink power role and it reads Rp = SinkTxNG, it will wait until Rp = SinkTxOK before initiating the atomic message sequence requested by this 'GPPI' Task. This can cause an non-deterministic delay in completing the Task.
Additional Information	The PD controller will continue trying to execute this Task until it times out or aborts as described above. The host can want to issue the 'ABRT' Task if the process takes too long. Some scenarios where this can happen are: The PD controller is required to be the VCONN_Source in order to send any message on SOP or SOP'. The PD controller will continue trying to become the VCONN provider until it is successful. The PD controller with a sink power role (that is PresentRole = Sink) is required to wait for Rp = SinkTxOK before initiating an Atomic Message Sequence. The PD controller will continue waiting for Rp = SinkTxOK until it is able to send the appropriate message required for this 'GPPI' Task. The host must wait until CMDx reads as 0 or INT_EVENT1.CmdComplete is asserted before issuing the 'MBRd' 4CC Task to read the Rx Buffer after issuing this 'GPPI' Task. While executing the 'GPPI' Task, the PD controller uses the same shared buffer that is used to store other extended messages. Therefore, the host must not use the 'GPPI' Task when any other atomic message sequence is ongoing. To read the PD response received as a result of issuing the 'GPPI' Task after it is completed, the host must use the 'MBRd' 4CC command. The 'MBRd' Task must also be used to unlock the Rx Buffer for other incoming message.

Figure 4-1 Example Sequence for 'GPPI' Task When Host Uses INT_EVENT1

Figure 4-2 Example Sequence for 'GPPI' Task When Host Uses CMD1 Polling

Figure 4-3 'GPPI' Interrupted by an Unknown Message

Figure 4-4 'GPPI' Interrupted by an Unknown Extended Message