Re: [PATCH] spi: spi-nxp-fspi: exit stop mode before waiting for DLL lock

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] spi: nxp-fspi: DLL registers programmed outside stop mode
--

commit 51952120b76fbf34aadd629657697e2fb0e3c938
Author: Haibo Chen <haibo.chen@nxp.com>

spi: spi-nxp-fspi: exit stop mode before waiting for DLL lock

This commit addresses an issue where the DLL lock polling times out because
the serial root clock is gated in stop mode. To fix this, it moves the
exit from stop mode ahead of the DLL calibration step. However, this
causes the DLL control registers to be programmed while the module is active.

> diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c
> index 67d991dd249d2..66cb58f95fdb1 100644
> --- a/drivers/spi/spi-nxp-fspi.c
> +++ b/drivers/spi/spi-nxp-fspi.c
> @@ -898,10 +898,10 @@ static int nxp_fspi_select_mem(struct nxp_fspi *f, struct spi_device *spi,
>  	dev_dbg(f->dev, "Target device [CS:%x] selected\n", spi_get_chipselect(spi, 0));
>  
>  	/*
> -	 * Per the FlexSPI reference manual (initialization sequence), MCR0 and
> -	 * the DLL control registers should be configured while the module is in
> -	 * stop mode (MCR0[MDIS] = 1). Enter stop mode before reconfiguring the
> -	 * RX sample clock source and the DLL, then exit stop mode afterwards.
> +	 * Per the FlexSPI reference manual (initialization sequence), MCR0
> +	 * should be configured while the module is in stop mode (MCR0[MDIS] = 1).
> +	 * Enter stop mode before reconfiguring the RX sample clock source, then
> +	 * exit stop mode afterwards.
>  	 */
>  	reg = fspi_readl(f, f->iobase + FSPI_MCR0);
>  	fspi_writel(f, reg | FSPI_MCR0_MDIS, f->iobase + FSPI_MCR0);

[ ... ]

> @@ -936,6 +936,16 @@ static int nxp_fspi_select_mem(struct nxp_fspi *f, struct spi_device *spi,
>  	if (ret)
>  		return ret;
>  
> +	/*
> +	 * Exit stop mode before running the DLL calibration. The DLL
> +	 * reference clock is derived from the module clock domain, which is
> +	 * gated while MCR0[MDIS] = 1. Calibrating the DLL in stop mode leaves
> +	 * the STS2 lock bits stuck at 0 (the DLL never runs), so clear MDIS
> +	 * first and let the module and reference clock run.
> +	 */
> +	reg = fspi_readl(f, f->iobase + FSPI_MCR0);
> +	fspi_writel(f, reg & ~FSPI_MCR0_MDIS, f->iobase + FSPI_MCR0);
> +
>  	/*
>  	 * If clock rate > 100MHz, then switch from DLL override mode to
>  	 * DLL calibration mode.
>  	 */
>  	if (rate > 100000000)
>  		nxp_fspi_dll_calibration(f);
>  	else
>  		nxp_fspi_dll_override(f);

[Severity: High]
Since stop mode is exited before calling nxp_fspi_dll_calibration(), does
this result in the DLL registers being programmed while the module and
clocks are active?

Looking at nxp_fspi_dll_calibration(), it writes to the DLL control registers
(FSPI_DLLACR and FSPI_DLLBCR) before polling for the lock:

static void nxp_fspi_dll_calibration(struct nxp_fspi *f)
{
	...
	/* Reset the DLL, set the DLLRESET to 1 and then set to 0 */
	fspi_writel(f, FSPI_DLLACR_DLLRESET, f->iobase + FSPI_DLLACR);
	...
	/* Enable the DLL calibration mode. */
	fspi_writel(f, FSPI_DLLACR_DLLEN | FSPI_DLLACR_SLVDLY(0xF),
		    f->iobase + FSPI_DLLACR);
	...
}

Will writing to the DLL control registers outside of stop mode violate the
hardware constraints or inject severe jitter into the sampling clock domain?

Should the register configuration part of the DLL calibration remain in
stop mode, with only the STS2 lock polling delayed until after stop mode
is exited?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-fspi-fix-v1-1-a0f9288cd5c8@nxp.com?part=1