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

[Potthuri, Sai Krishna]

Hi,

> -----Original Message-----
> From: Marek Vasut <marex at denx.de>
> Sent: Tuesday, October 18, 2022 2:37 PM
> To: Potthuri, Sai Krishna <sai.krishna.potthuri at amd.com>; Simek, Michal
> <michal.simek at amd.com>; linux-arm-kernel at lists.infradead.org
> Cc: Abhyuday Godhasara <abhyuday.godhasara at xilinx.com>; Harsha
> <harsha.harsha at xilinx.com>; Rajan Vaja <rajan.vaja at xilinx.com>; Ronak
> Jain <ronak.jain at xilinx.com>; Tanmay Shah <tanmay.shah at xilinx.com>
> Subject: Re: [PATCH] firmware: xilinx: Do not call IOCTL_SET_SD_TAPDELAY
> for value 0
> 
> 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 ?
ATF change I am talking about is
https://github.com/ARM-software/arm-trusted-firmware/commit/2ab0ef8db9561699fef0f77f5a1735e4903f6b3e

Looks like we are already taking care of disabling the ITAP in ATF(below commit)
if we get ZERO tap.
https://github.com/ARM-software/arm-trusted-firmware/commit/fe1fa205fca4d1dd4a1b1755942956dbca65d573

Above changes are part of ATF 2.5 version.

Regards
Sai Krishna