Re: [RFC PATCH 0/6] spi: Add OSPI PHY calibration support for spi-cadence-quadspi

From: <Tudor.Ambarus@microchip.com>
To: <p.yadav@ti.com>, <nm@ti.com>, <kristo@kernel.org>,
	<robh+dt@kernel.org>, <michael@walle.cc>,
	<miquel.raynal@bootlin.com>, <richard@nod.at>, <vigneshr@ti.com>,
	<broonie@kernel.org>, <linux-arm-kernel@lists.infradead.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-mtd@lists.infradead.org>, <linux-spi@vger.kernel.org>
Cc: <lokeshvutla@ti.com>
Subject: Re: [RFC PATCH 0/6] spi: Add OSPI PHY calibration support for spi-cadence-quadspi
Date: Fri, 12 Mar 2021 09:09:42 +0000	[thread overview]
Message-ID: <9c551f56-4c00-b41a-f051-8b7e197fbcdc@microchip.com> (raw)
In-Reply-To: <20210311191216.7363-1-p.yadav@ti.com>

On 3/11/21 9:12 PM, Pratyush Yadav wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hi,
> 
> This series adds support for OSPI PHY calibration on the Cadence OSPI
> controller. This calibration procedure is needed to allow high clock
> speeds in 8D-8D-8D mode. The procedure reads some pre-determined pattern
> data from the flash and runs a sequence of test reads to find out the
> optimal delays for high speed transfer. More details on the calibration
> procedure in patch 5/6.

Can the calibration sequence be avoided if the controller is informed
about the frequency on which the flash operates?

Can you add more details about the optimal delays? Are we talking about
flash's AC characteristics? Is the calibration still needed if the upper
layer informs the QSPI controller about the needed delays?

Cheers,
ta

> 
> The main problem here is telling the controller where to find the
> pattern and how to read it. This RFC uses nvmem cells which point to a
> fixed partition containing the data to do the reads. It depends on [0]
> and [1].
> 
> The obvious problem with this is it won't work when the partitions are
> defined via command line. I don't see any good way to add nvmem cells to
> command line partitions. I would like some help or ideas here. We don't
> necessarily have to use nvmem either. Any way that can cleanly and
> consistently let the controller find out where the pattern is stored is
> good.
> 
> The dts patch depends on [2].
> 
> Tested on TI's J721E EVM.
> 
> [0] https://patchwork.ozlabs.org/project/linux-mtd/patch/20210302190012.1255-1-zajec5@gmail.com/
> [1] https://patchwork.ozlabs.org/project/linux-mtd/patch/20210308011853.19360-1-ansuelsmth@gmail.com/
> [2] https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210305153926.3479-2-p.yadav@ti.com/
> 
> Pratyush Yadav (6):
>   spi: spi-mem: Tell controller when device is ready for calibration
>   mtd: spi-nor: core: consolidate read op creation
>   mtd: spi-nor: core: run calibration when initialization is done
>   spi: cadence-qspi: Use PHY for DAC reads if possible
>   spi: cadence-qspi: Tune PHY to allow running at higher frequencies
>   arm64: dts: ti: k3-j721e-som-p0: Enable PHY calibration
> 
>  arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi |  55 ++
>  drivers/mtd/spi-nor/core.c                  |  74 +-
>  drivers/spi/spi-cadence-quadspi.c           | 820 +++++++++++++++++++-
>  drivers/spi/spi-mem.c                       |  12 +
>  include/linux/spi/spi-mem.h                 |   8 +
>  5 files changed, 916 insertions(+), 53 deletions(-)
> 
> --
> 2.30.0
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 