Re: [RFC] PCI: tegra: Revert raw_violation_fixup for tegra124

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux