SPRUJ28 User guide

SPRUJ28E November 2021 – September 2024 AM68 , AM68A , TDA4AL-Q1 , TDA4VE-Q1 , TDA4VL-Q1

12.6.4.7.5.6 Return Path Operation

The DSI Return Path behaves like a slave, by collecting data from the DPHY receive interface when the DPHY is configured to accept a transmission from the peripheral. The RP receives 6 signals from the DPHY (see Table 12-365).

The data (and trigger) reception is inactive if the DPHY PPI direction signal is at low level. When it is active, data is received using the RX ESC_CLK clock (the clock is transmitted with the data itself - see D-PHY protocol description from MIPI) and may stop if there is a pause in the data transmission but data is generated on clock falling edge. New data is available on rx_data_esc on a rising edge of the clock, if both rx_lpdt_esc and rx_valid_esc are asserted.

Table 12-365 Interface Between Return Path and DPHY

Signal Name	I/O	From/To	Description
rx_lpdt_esc	I	DPHY	Escape Low Power data receive mode This active high signal is asserted to indicate that the lane module is in low-power data receive mode. While in this mode, received data bytes are driven onto the rx_data_esc output when rx_valid_esc is active. The lane module remains in this mode with rx_lpdt_esc asserted until a stop state is detected on the lane interconnect.
rx_trigger_esc(3:0)	I	DPHY	Escape trigger received These signals indicate that an escape trigger command has been received. Only one of these signals will be asserted at any time and the signal will remain asserted until the lane module returns to stop state.
rx_data_esc(7:0)	I	DPHY	Escape receive data For Low Power data receptions, this eight-bit value is driven by the D-PHY and is valid on rising edges of rx_clk_esc with rx_valid_esc asserted. The bit connected to rx_data_esc[0] was received first.
rx_valid_esc	I	DPHY	Escape receive data valid This signal indicates that the lane module is driving data on rx_data_esc and expects the protocol layers to take the data at the current rising edge of rx_clk_esc. There is no "ready" signal to throttle the receive data.
stop_state_dl1	I	DPHY	Lane is in stop state This signal indicates that the lane module is in STOP state. Note that this signal is asynchronous to any clock in the protocol interface.
direction	I	DPHY	Lane direction. When this signal is high, the lane module is in receive mode. When direction is low, the lane module is in transmit mode. (Mnemonic: 1 = Input, 0 = Output.)

The received data messages are identified as one of two possible types:

Trigger
Read packet

Trigger messages are passed almost directly to the register (reg_req = reg_trigger = 1 and reg_rd_data<3:0> equals to trigger value during one clock cycle). However, triggers are decoded to see if they are a TE trigger or an acknowledge with no error.

The TE data is passed separately to the CSM using csm_te_received pin. It needs to be resynchronized with tx_byte_clk byte clock because of the CSM working clock domain.
The acknowledge in only passed to register using reg_req and reg_ack pins. All other trigger values are passed undecoded to the registers without any processing. It is the responsibility of the application to decode and decide what to do with them.

Read Packet: When data is received, the system waits for the 4 bytes of the HEADER, and performs an ECC correction (if it is enabled) and then decodes the packets.

The following cases are considered when the system performs the ECC check:

If the received command is not in the list of legal display opcodes, (i.e. errors in the packet header), it discards that packet and all further incoming bytes, even if they are legal packets (until the next BTA - i.e. direction change). It sends errors to the register bank (err_undecodable and uncorrectable_err). This may also result in an EOT error being reported as no further bytes have been decoded. But even if ECC correction shows an uncorrected error, decoding is attempted (if the errors are in the ECC byte or in the payload bytes, the opcode can be understood and data correctly recovered). In this case only err_uncorrectable error bit is sent to register and it falls in the situation of regular commands (acknowledge with error or read).
If "an acknowledge with error", the two status bytes are sent to the registers (reg_req = 1 and reg_ack_err = 1 and reg_rd_data<15:0> contains the correct value).
If the message type is a short read (either DCS or generic), data is passed to the registers (2 bytes without any specific decoding). Interface signals must be set accordingly and the two bytes are sent to registers (reg_req = reg_start = reg_end = reg_read = 1 with data and dscnotgen set accordingly). Size information is decoded in the first byte of the received packet depending on the data type information and then sent to register using reg_size port.
If a long read, the size is sent to the register using reg_size. The system goes to LONG state. All data received are sent to register using reg_data and are used for checksum detection. If during receive, return packet fifo (in control block) becomes full (rd_data_fifo_full), the error flag err_oversize must be set. All remaining data is used for checksum calculation but are not transferred to registers. When the number of received bytes is equal to the packet size, the system will check the CHECKSUM. The two checksum bytes are never transferred to register. They are used to make checksum detection and indicate err_checkum status.
If the transfer is shorter than the size specified in the header, the error err_wrong_length is issued along with any subsequent errors such as err_missing_eot (if needed). The case where it is longer drives to a tentative checksum decoding that generates an error and by a tentative to decode a new header (that is in fact a part of the previous packet) that drives to an error err_undecodable and the throwing of the rest of the received bytes (with corresponding errors such as err_missing_eot).
If it is an EoT packet, it is not passed to the control block. The following data is ignored (if any). If the system is waiting for EoT, this is the only action. If system is not waiting for EoT packet, the err_eot_with_err is sent.
If after an "acknowledge with error", the system waits for EoT packet and counts 4 bytes but is not able to decode them, it emits an err_eot_with_err and err_undecodable.
If direction is removed at a "wrong" time (i.e before the fourth byte of a small packet, the system stops to works but emit errors to the register: err_receive with eventually err_missing_eot.

The DSI is designed to support multi-peripheral integration, the virtual channel of the received packet is also stored in register using reg_vc port.

The application FW layer is responsible of all read actions, it is assumed that once a read is requested, application reads return packets before requesting other read actions. Based on this assumption, the receive FIFO implemented in the register block is cleared each time a read action is started. All data not read before the new read command are lost.

A re-initialization of the return path is also performed using register access on reg_init_rp.

All errors related to short or long received data packets should be captured in the register when the direction changes (to capture all errors at the same time and not generate several errors and possibly several interrupts on the same reverse transaction). As soon as an error is detected on a packet, the error must be recorded and maintained up to the end of the packet transfer.

The maximum packet size supported by the DSI return path is 16 bytes. If a longer packet is received, only the first 16 bytes are available (by register way) for application.