CRITICALITY

Medium

DESCRIPTION

The DMA4 channel generates an unexpected transaction on WR port under the following 2 scenarios:

• Scenario 1
  1. Software synchronization: Bit fields SYNCHRO_CONTROL and SYNCHRO_CONTROL_UPPER are set to 0 in register DMA4_CCRi
     • Channel element number: Bit field CHANNEL_ELMNT_NBR is set to 0x9 in register DMA4_CENi
     • Channel frame number: Bit field CHANNEL_FRAME_NBR is set to 0x1 in register DMA4_CFNi
     • Element size: Bit field DATA_TYPE is set to 0x2 in register DMA4_CSDPi
     • Destination addressing mode: Bit field DST_AMODE is set to 0x1 in register DMA4_CCRi
     • Destination is packed: Bit field DST_PACKED is set to 0x1 in register DMA4_CSDPi
     • Destination endianism: Bit field DST_ENDIAN is set to 0x0 in register DMA4_CSDPi
     • Destination burst enable: Bit field DST_BURST_EN is set to 0x1 in register DMA4_CSDPi
     • Destination start address: Register DMA4_CDSAi is set to 0xabcd0000
     • Disable graphics operation: Bit fields CONSTANT_FILL_ENABLE and TRANSPARENT_COPY_ENABLE are set to 0x0 in register DMA4_CCRi
     The channel has got an ERR response on the WR port before the end of block transfer. The channel has gone for clean abort and got disabled. The same channel has been configured with soft-sync and included in the channel chaining (This channel is not the head of the chain). When this channel gets enabled through the link, the channel is writing the data out as soon as it fetches the data from Read side. It is expected that the channel should go with burst transfer, but it is going for single transfers.
     This results in a performance issue as DMA is executing single transfers instead of burst transfers. This performance issue is also observed while using the channel with destination synchronization and prefetch enabled.
  2. Destination sync with Prefetch enabled: Bit field SEL_SRC_DST_SYNC is set to 0x0; Bit fields SYNCRO_CONTROL_UPPER and SYNCRO_CONTROL should not be set to 0x0; Bit field PREFETCH is set to 0x1 in register DMA4_CCRi. The other settings remain same as in use case #1 described above
• Scenario 2
  • The channel has got an ERR response on the WR port before the end of block transfer. The channel has gone for clean abort and got disabled. The same channel has been configured with destination-sync with prefetch enabled and included in the channel chaining (This channel is not the head of the chain). When this channel gets enabled through the link, the read port will start its transaction. If the HWR request to this channel comes before the channel gets its first response, the channel will start a WR transaction with byte enable 0. Also, the internal data counters get updated and the corresponding data will never come out of DMA4. The Data FIFO locations are also not recovered.
    This results in a Data Integrity issue.

WORKAROUND

There is a software workaround to solve this issue

1. Workaround to resolve both Data Integrity and Performance issue:
   • Dummy enable-disable for an aborted Channel. i.e. on abort, configure the channel as soft sync with No of frames = 0 and enable the channel by writing 0x1 into the ENABLE bitfield of register DMA4_CCRi. Wait for the Address Misaligment Interrupt. The channel is now ready for reuse.
   • Ensure that clean drain happens for a channel that is or is to be used as part of a channel chain. i.e. ensure that the abort conditions never occur for this channel
   • If a channel gets aborted, do not reuse the channel in a chain
   • Don't use channel chaining
2. Workaround to resolve the data integrity only.
   Disable prefetch in all channels that are part of a channel chain

REVISIONS IMPACTED

DRA72x SR 2.0, 1.0
DRA71x SR 2.1, 2.0

DRA79x: 2.1, 2.0

TDA2Ex (23mm): 2.0, 1.0

TDA2Ex (17mm): 2.1, 2.0

AM571x: 2.1, 2.0, 1.0

AM570x: 2.1, 2.0

DRA72x: 2.0, 1.0

DRA71x: 2.1, 2.0