SPRZ454B February   2018  – September 2024 TDA2P-ABZ , TDA2P-ACD

 

  1.   1
  2. 1Introduction
    1.     Related Documentation
    2.     Trademarks
    3.     Modules Impacted
  3. 2Silicon Advisories
    1.     Revisions SR 1.0 - Advisories List
    2.     i202
    3.     i378
    4.     i631
    5.     i694
    6.     i698
    7.     i699
    8.     i709
    9.     i727
    10.     i729
    11.     i734
    12.     i767
    13.     i782
    14.     i783
    15.     i802
    16.     i803
    17.     i807
    18.     i808
    19.     i809
    20.     i810
    21.     i813
    22.     i814
    23.     i815
    24.     i818
    25.     i819
    26.     i820
    27.     i824
    28.     i826
    29.     i829
    30.     i834
    31.     i849
    32.     i856
    33.     i862
    34.     i863
    35.     i869
    36.     i870
    37.     i871
    38.     i872
    39.     i874
    40.     i878
    41.     i879
    42.     i883
    43.     i889
    44.     i890
    45.     i893
    46.     i896
    47.     i897
    48.     i898
    49.     i899
    50.     i900
    51.     i903
    52.     i904
    53.     i916
    54.     i929
    55.     i930
    56.     i932
    57.     i933
    58.     i936
    59.     i940
    60.     i2446
  4. 3Silicon Limitations
    1.     Revisions SR 1.0 - Limitations List
    2.     i596
    3.     i641
    4.     i833
    5.     i838
    6.     i844
    7.     i845
    8.     i848
    9.     i876
    10.     i877
    11.     i892
    12.     i909
  5. 4Silicon Cautions
    1.     Revisions SR 1.0 - Cautions List
    2.     i781
    3.     i827
    4.     i832
    5.     i836
    6.     i839
    7.     i864
    8.     i885
    9.     i886
    10.     i912
    11.     i926
    12.     i931
    13.     i935
    14.     i937
  6. 5Revision History

i698

DMA4 Generates Unexpected Transaction on WR Port

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. Work around 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. Work around to resolve the data integrity only.
    Disable prefetch in all channels that are part of a channel chain

REVISIONS IMPACTED

SR 1.0

AM574x: 1.0

DRA75xP, DRA74xP, DRA77xP, DRA76xP: 1.0

TDA2Px: 1.0

AM576x: 1.0