Linux SPI subsystem development
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Santhosh Kumar K <s-k6@ti.com>
Cc: <broonie@kernel.org>,  <robh@kernel.org>,  <krzk+dt@kernel.org>,
	<conor+dt@kernel.org>,  <richard@nod.at>,  <vigneshr@ti.com>,
	<pratyush@kernel.org>,  <mwalle@kernel.org>,
	<takahiro.kuwano@infineon.com>,  <linux-spi@vger.kernel.org>,
	<devicetree@vger.kernel.org>,  <linux-kernel@vger.kernel.org>,
	<linux-mtd@lists.infradead.org>,  <praneeth@ti.com>,
	 <u-kumar1@ti.com>, <a-dutta@ti.com>
Subject: Re: [PATCH v3 11/13] mtd: spinand: run PHY tuning after init and update dirmap frequencies
Date: Thu, 28 May 2026 11:27:13 +0200	[thread overview]
Message-ID: <87mrxjg9zi.fsf@bootlin.com> (raw)
In-Reply-To: <20260527175527.2247679-12-s-k6@ti.com> (Santhosh Kumar K.'s message of "Wed, 27 May 2026 23:25:25 +0530")

Hi Santhosh,

On 27/05/2026 at 23:25:25 +0530, Santhosh Kumar K <s-k6@ti.com> wrote:

> Run spi_mem_execute_tuning() in spinand_probe() after spinand_init()
> completes. The read and write op templates are copied into persistent
> fields in spinand_device so the controller can write the validated
> frequency directly back into them. On success, propagate that frequency
> to every dirmap's primary and secondary op templates. Updating the
> secondary template ensures continuous-read dirmaps also benefit from
> the validated speed, not just the primary read path.
>
> Signed-off-by: Santhosh Kumar K <s-k6@ti.com>
> ---
>  drivers/mtd/nand/spi/core.c | 35 +++++++++++++++++++++++++++++++++++
>  include/linux/mtd/spinand.h |  4 ++++
>  2 files changed, 39 insertions(+)
>
> diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
> index f1084d5e04b9..9b54e4607cfe 100644
> --- a/drivers/mtd/nand/spi/core.c
> +++ b/drivers/mtd/nand/spi/core.c
> @@ -2030,6 +2030,41 @@ static int spinand_probe(struct spi_mem *mem)
>  	if (ret)
>  		return ret;
>  
> +	/*
> +	 * Copy the read and write op templates into persistent fields so
> +	 * execute_tuning can write the validated frequency back into them.
> +	 * Tuning failure is non-fatal; the device operates at base speed.
> +	 */
> +	spinand->max_read_op = *spinand->op_templates->read_cache;
> +	spinand->max_write_op = *spinand->op_templates->write_cache;
> +
> +	ret = spi_mem_execute_tuning(mem, &spinand->max_read_op,
> +				     &spinand->max_write_op);
> +	if (ret && ret != -EOPNOTSUPP)
> +		dev_warn(&mem->spi->dev, "Failed to execute PHY tuning: %d\n",
> +			 ret);
> +
> +	/*
> +	 * Dirmaps were set up in spinand_init() before tuning ran; update
> +	 * their op templates to use the validated frequency.
> +	 */
> +	if (!ret) {
> +		struct nand_device *nand = spinand_to_nand(spinand);
> +		int i;
> +
> +		for (i = 0; i < nand->memorg.planes_per_lun; i++) {
> +			if (spinand->dirmaps[i].rdesc) {
> +				spinand->dirmaps[i].rdesc->info.primary_op_tmpl.max_freq =
> +					spinand->max_read_op.max_freq;
> +				spinand->dirmaps[i].rdesc->info.secondary_op_tmpl.max_freq =
> +					spinand->max_read_op.max_freq;
> +			}
> +			if (spinand->dirmaps[i].wdesc)
> +				spinand->dirmaps[i].wdesc->info.primary_op_tmpl.max_freq =
> +					spinand->max_write_op.max_freq;
> +		}
> +	}

Unfortunately, hot fixing the dirmaps is invalid. When we take the best
variant, we select a maximum speed that may be lower than the tuned PHY
speed. We cannot just overwrite that value without consequence, because
depending on the boundaries we cross, extra dummy cycles may be
required.

I believe spinand_select_op_variant() shall be aware of the different
possible speeds. It should look for the max_speed_hz capability and not
for the base_speed_hz, and fallback to base_speed_hz in case of
issue.

Or otherwise, maybe we could go through the whole I/O variant
selection again after tuning, with the actual maximum speed set.


Thanks,
Miquèl

  reply	other threads:[~2026-05-28  9:27 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-27 17:55 [PATCH v3 00/13] spi: cadence-quadspi: add PHY tuning support Santhosh Kumar K
2026-05-27 17:55 ` [PATCH v3 01/13] spi: dt-bindings: allow spi-max-frequency to specify a frequency pair Santhosh Kumar K
2026-05-28  8:32   ` Miquel Raynal
2026-05-27 17:55 ` [PATCH v3 02/13] spi: dt-bindings: cdns,qspi-nor: add PHY tuning pattern partition property Santhosh Kumar K
2026-05-28  8:34   ` Miquel Raynal
2026-05-27 17:55 ` [PATCH v3 03/13] spi: parse two-element spi-max-frequency property Santhosh Kumar K
2026-05-28  8:37   ` Miquel Raynal
2026-05-27 17:55 ` [PATCH v3 04/13] spi: spi-mem: add spi_mem_apply_base_freq_cap() Santhosh Kumar K
2026-05-28  8:43   ` Miquel Raynal
2026-05-27 17:55 ` [PATCH v3 05/13] spi: spi-mem: add execute_tuning callback and spi_mem_execute_tuning() Santhosh Kumar K
2026-05-28  8:44   ` Miquel Raynal
2026-05-27 17:55 ` [PATCH v3 06/13] spi: cadence-quadspi: move cqspi_readdata_capture earlier Santhosh Kumar K
2026-05-27 17:55 ` [PATCH v3 07/13] spi: cadence-quadspi: add DQS support to read data capture Santhosh Kumar K
2026-05-27 17:55 ` [PATCH v3 08/13] spi: cadence-quadspi: add PHY tuning support Santhosh Kumar K
2026-05-28  8:54   ` Miquel Raynal
2026-05-27 17:55 ` [PATCH v3 09/13] spi: cadence-quadspi: reject 2-byte-address DDR ops on PHY-tunable hardware Santhosh Kumar K
2026-05-28  9:01   ` Miquel Raynal
2026-05-27 17:55 ` [PATCH v3 10/13] spi: cadence-quadspi: enable PHY for direct reads and indirect writes Santhosh Kumar K
2026-05-28  9:09   ` Miquel Raynal
2026-05-27 17:55 ` [PATCH v3 11/13] mtd: spinand: run PHY tuning after init and update dirmap frequencies Santhosh Kumar K
2026-05-28  9:27   ` Miquel Raynal [this message]
2026-05-27 17:55 ` [PATCH v3 12/13] mtd: spi-nor: extract read op template construction into helper Santhosh Kumar K
2026-05-27 17:55 ` [PATCH v3 13/13] mtd: spi-nor: run PHY tuning after init and update dirmap frequency Santhosh Kumar K
2026-05-28  8:30 ` [PATCH v3 00/13] spi: cadence-quadspi: add PHY tuning support Miquel Raynal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mrxjg9zi.fsf@bootlin.com \
    --to=miquel.raynal@bootlin.com \
    --cc=a-dutta@ti.com \
    --cc=broonie@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=mwalle@kernel.org \
    --cc=praneeth@ti.com \
    --cc=pratyush@kernel.org \
    --cc=richard@nod.at \
    --cc=robh@kernel.org \
    --cc=s-k6@ti.com \
    --cc=takahiro.kuwano@infineon.com \
    --cc=u-kumar1@ti.com \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox