public inbox for linux-spi@vger.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Santhosh Kumar K <s-k6@ti.com>
Cc: Pratyush Yadav <pratyush@kernel.org>,  <richard@nod.at>,
	<vigneshr@ti.com>,  <broonie@kernel.org>,
	 <tudor.ambarus@linaro.org>, <mwalle@kernel.org>,
	 <p-mantena@ti.com>,  <linux-spi@vger.kernel.org>,
	<linux-mtd@lists.infradead.org>,  <linux-kernel@vger.kernel.org>,
	<a-dutta@ti.com>,  <u-kumar1@ti.com>,  <praneeth@ti.com>
Subject: Re: [RFC PATCH 01/10] spi: spi-mem: Introduce support for tuning controller
Date: Wed, 03 Dec 2025 09:58:28 +0100	[thread overview]
Message-ID: <87v7io9c23.fsf@bootlin.com> (raw)
In-Reply-To: <cf87ced7-aa66-4b15-98e5-92cb76737073@ti.com> (Santhosh Kumar K.'s message of "Wed, 3 Dec 2025 13:32:16 +0530")

> Just to summarize, fallback logic during probe:
>    - If the controller reports a tuning failure, the spi-mem client may
> either retry tuning with the next-best (max-1) operation

There is no such "next-best" variant once in ODDR mode unfortunately. We
will have to return an error indicating that PHY calibration needs to
happen again and just retry without it.

As to when/if we shall perform it again, this is a delicate topic. Being
conservative might imply just disabling the feature and no longer using
it from a SPI controller perspective until SPI NAND/NOR calls for
calibration again, but it is unclear to me when this should
happen. Maybe we could trigger a background job with a low priority for
that. But don't bother implementing this in the first place. Just make
it work, make it fit in the current subsystems, just KISS. We can figure
this out in a second time, especially since failures are not supposed to
happen very often.

> or fallback to
> the non-PHY, slower operation and adjust the dummy cycles accordingly to
> use the optimal non-PHY variant.

Why adjusting the dummy cycles? I am not aware of a different number of
cycles with and without PHY mode. It should be identical, no? The
difference lays in the frequency we use, not the fact that PHY is
active. And once we've decided a configuration, we can always handle
slower frequencies, at the cost of a few 100kiB/s maybe. So I would not
see this as a concern.

> And yes, for now the priority is to have a robust probe-time tuning flow
> before addressing any runtime tuning concerns.

Yes.

>>> But once we solve this, comes a similar problem on the write side. How
>>> do we know if a write will or did fail because of a temperature change?
>>> What may be the heuristics to fallback in this case?
>> Santhosh, do you have any numbers on write performance improvements? I
>> am curious if it is even worth the effort.
>
> There's no real performance gain for SPI NOR, but SPI NAND shows notable
> improvement wrt. page size.
>
> Write performance numbers from AM62A SK with W35N01JW OSPI NAND:
>
>    - without PHY: 6 MB/s
>    - with PHY: 9.2 MB/s

Eager to see this in SPI NAND (only) then!

Thanks,
Miquèl

  reply	other threads:[~2025-12-03  8:58 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-11 19:32 [RFC PATCH 00/10] SPINAND PHY Tuning Series Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 01/10] spi: spi-mem: Introduce support for tuning controller Santhosh Kumar K
2025-08-13 20:26   ` Mark Brown
2025-08-14 11:34     ` Santhosh Kumar K
2025-08-14 12:34       ` Mark Brown
2025-08-22  6:05         ` Santhosh Kumar K
2025-09-10  8:07         ` Miquel Raynal
2025-08-24 17:02     ` Miquel Raynal
2025-09-10  8:21   ` Miquel Raynal
2025-09-20 17:55     ` Santhosh Kumar K
2025-10-28 15:41       ` Miquel Raynal
2025-11-05  8:55         ` Santhosh Kumar K
2025-11-05  9:35           ` Miquel Raynal
2025-11-18 13:42             ` Pratyush Yadav
2025-12-03  8:02               ` Santhosh Kumar K
2025-12-03  8:58                 ` Miquel Raynal [this message]
2025-12-10 11:33                   ` Santhosh Kumar K
2025-12-12  6:43                   ` Pratyush Yadav
2025-11-18 13:49       ` Pratyush Yadav
2025-12-03  8:02         ` Santhosh Kumar K
2025-12-03  9:28           ` Michael Walle
2025-12-03  9:50             ` Miquel Raynal
2025-12-03 14:12               ` Michael Walle
2025-12-10 11:36                 ` Santhosh Kumar K
2025-12-10 11:34               ` Santhosh Kumar K
2025-12-11 14:16                 ` Miquel Raynal
2025-12-04 16:54           ` Mahapatra, Amit Kumar
2025-12-10 11:34             ` Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 02/10] spi: spi-mem: Define spi_mem_tuning_params and spi_mem_get_tuning_params() Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 03/10] mtd: nand: spi: Introduce _execute_tuning for mtd devices Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 04/10] mtd: mtdcore: Call mtd_execute_tuning during mtd_register Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 05/10] spi: cadence-quadspi: Move cqspi_readdata_capture() above all operations Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 06/10] spi: cadence-quadspi: Use BIT() macro for CQSPI_REG_READCAPTURE_BYPASS Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 07/10] spi: cadence-quadspi: Enable PHY for aligned DAC reads Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 08/10] spi: cadence-quadspi: Enable PHY for data writes Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 09/10] spi: cadence-quadspi: Implement PHY for higher frequencies in SDR mode Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 10/10] spi: cadence-quadspi: Define cqspi_get_tuning_params() Santhosh Kumar K

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=87v7io9c23.fsf@bootlin.com \
    --to=miquel.raynal@bootlin.com \
    --cc=a-dutta@ti.com \
    --cc=broonie@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=p-mantena@ti.com \
    --cc=praneeth@ti.com \
    --cc=pratyush@kernel.org \
    --cc=richard@nod.at \
    --cc=s-k6@ti.com \
    --cc=tudor.ambarus@linaro.org \
    --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