[PATCH] firmware: xilinx: Do not call IOCTL_SET_SD_TAPDELAY for value 0

[Marek Vasut]

On 10/18/22 09:07, Potthuri, Sai Krishna wrote:
> Hi,

Hi,

>>>> On 10/17/22 14:35, Marek Vasut wrote:
>>>>> In case the tap delay required by Arasan SDHCI is set to 0, the
>>>>> current embeddedsw firmware unconditionally writes IOU_SLCR
>>>> SD_ITAPDLY
>>>>> to 0x100 (SD0_ITAPDLYENA=1, SD0_ITAPDLYSEL=0). Previous behavior
>> was
>>>>> to keep the IOU_SLCR SD_ITAPDLY set to 0x0. There is some sort of
>>>>> difference in the behavior between SD0_ITAPDLYENA=1/0 with the same
>>>>> SD0_ITAPDLYSEL=0, even though the behavior should be identical --
>>>>> zero delay added to rxclk_in line. The former breaks HS200 training
>>>>> in low
>>>> temperature conditions.
>>> We got a similar issue from one of the customers saying tuning was
>>> failing at lower temperatures with 4.19 kernel.
>>> Root cause of this issue is incorrect tap delay sequence in 4.19
>>> kernel which got fixed in 5.4 Xilinx Linux tree (2022.2 release).
>>
>> I am not using the Xilinx downstream stuff, I am using linux-next and Linux
>> 5.10.y from linux-stable for these tests.
>>
>>> 4.19 sequence:
>>> DLL assert->ITAP->DLL de-assert->DLL assert->OTAP->DLL de-assert
>>> 5.4 sequence:
>>> DLL assert->ITAP->OTAP->DLL de-assert
>>>
>>> Please give a try with the updated sequence.
>>
>> Whatever fixes are in Linux 5.4 should already be present, and no, that does
>> NOT work.
> This fix has dependency on ATF version, are you testing with >=2.5 version?
> https://github.com/ARM-software/arm-trusted-firmware/tree/v2.5

No, I am still running whatever downstream fork of ATF came with the 
hardware and this cannot be updated.

Can you point me to specific commit(s) in the aforementioned repository 
which are related to this topic ?