On 26-Jun-20 6:52 PM, Nicolas Chauvet wrote: > External email: Use caution opening links or attachments > > > Le lun. 20 avr. 2020 à 20:16, Manikanta Maddireddy > <mmaddireddy@xxxxxxxxxx> a écrit : >> Thank you Nicolas for identifying the patch which caused the CmpltTO. >> >> Little background on the fixup, >> In the internal testing with dGPU on Tegra124, CmplTO is reported by >> dGPU. This happened because FIFO queue in AFI(AXI to PCIe) module >> get full by upstream posted writes. Back to back upstream writes >> interleaved with infrequent reads, triggers RAW violation and CmpltTO. >> This is fixed by reducing the posted write credits and by changing >> updateFC timer frequency. These settings are fixed after stress test. >> >> In the current case, RTL NIC is also reporting CmplTO. These settings >> seems to be aggravating the issue instead of fixing it. > Seems I've lost track of this issue. > > @Manikanta Maddireddy Do you plan to have some time to work on this ? Unfortunately, I don't have access to T124 platform because of lock down. > If going with the revert I wonder if I need to revert more completely > the original patch ? Since only tegra124 used the raw_violation_fixup, > should I remove this case and the related function completely or leave > the code as is ? (there will be few unused functions maybe). Given > other fixup have been added at a later time, the full revert is less > trivial. There are no unused functions, small piece of code under raw_violation_fixup check will become redundant. Yes, revert will give conflicts. I may not get a chance to work on this bug in coming months. If possible, please do complete revert. Once I get a chance to work on this bug, I will send out new patch. -Manikanta > > Right now this partial revert is enough to work reliably with the device. > > Thanks for your advice. > I will send a non-RFC version then.
