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

Potthuri, Sai Krishna sai.krishna.potthuri at amd.com
Mon Oct 17 07:04:56 PDT 2022


Hi Marek Vasut,

> -----Original Message-----
> From: Simek, Michal <michal.simek at amd.com>
> Sent: Monday, October 17, 2022 6:16 PM
> To: Marek Vasut <marex at denx.de>; linux-arm-kernel at lists.infradead.org;
> Potthuri, Sai Krishna <sai.krishna.potthuri at amd.com>
> 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
> 
> +Sai
> 
> 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).
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.
Setting the tap delay value to Zero is required in some use cases (Boot mode)
to clear the previous software stack tap delay configurations.

Regards
Sai Krishna
> >
> > Avoid writing the IOU_SLCR SD_ITAPDLY register in case value is 0 to
> > keep the register at value 0x0 to reinstate the previous behavior that
> > was present in Xilinx downstream fork of Linux 4.19.y and which
> > prevented breakage of HS200 training in low temperature conditions.
> >
> > Note that the embeddedsw firmware does not permit clearing the
> > SD_ITAPDLY SD0_ITAPDLYENA bit, this bit can only ever be set by the
> > firmware and it is often impossible to update the possibly broken
> firmware.
> >
> > Signed-off-by: Marek Vasut <marex at denx.de>
> > ---
> > Cc: Abhyuday Godhasara <abhyuday.godhasara at xilinx.com>
> > Cc: Harsha <harsha.harsha at xilinx.com>
> > Cc: Michal Simek <michal.simek at amd.com>
> > Cc: Rajan Vaja <rajan.vaja at xilinx.com>
> > Cc: Ronak Jain <ronak.jain at xilinx.com>
> > Cc: Tanmay Shah <tanmay.shah at xilinx.com>
> > To: linux-arm-kernel at lists.infradead.org
> > ---
> >   drivers/firmware/xilinx/zynqmp.c | 3 +++
> >   1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/firmware/xilinx/zynqmp.c
> > b/drivers/firmware/xilinx/zynqmp.c
> > index ff5cabe70a2b2..12712f64fb932 100644
> > --- a/drivers/firmware/xilinx/zynqmp.c
> > +++ b/drivers/firmware/xilinx/zynqmp.c
> > @@ -738,6 +738,9 @@
> EXPORT_SYMBOL_GPL(zynqmp_pm_get_pll_frac_data);
> >    */
> >   int zynqmp_pm_set_sd_tapdelay(u32 node_id, u32 type, u32 value)
> >   {
> > +	if (!value)
> > +		return 0;
> > +
> >   	return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
> IOCTL_SET_SD_TAPDELAY,
> >   				   type, value, NULL);
> >   }


More information about the linux-arm-kernel mailing list