All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pratyush Yadav <pratyush@kernel.org>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Santhosh Kumar K <s-k6@ti.com>,
	 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: Fri, 12 Dec 2025 15:43:56 +0900	[thread overview]
Message-ID: <86tsxw6vyr.fsf@kernel.org> (raw)
In-Reply-To: <87v7io9c23.fsf@bootlin.com> (Miquel Raynal's message of "Wed, 03 Dec 2025 09:58:28 +0100")

On Wed, Dec 03 2025, Miquel Raynal wrote:

>> 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.

Yeah, that is what I was thinking. I have mostly worked with NOR flashes
and with those writes are so slow that the transmission time is pretty
much noise.

>>
>> Write performance numbers from AM62A SK with W35N01JW OSPI NAND:
>>
>>    - without PHY: 6 MB/s
>>    - with PHY: 9.2 MB/s

Nice!

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

I suppose we should have a generic mechanism in SPI MEM, and then only
NAND would use it?

-- 
Regards,
Pratyush Yadav

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Pratyush Yadav <pratyush@kernel.org>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Santhosh Kumar K <s-k6@ti.com>,
	 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: Fri, 12 Dec 2025 15:43:56 +0900	[thread overview]
Message-ID: <86tsxw6vyr.fsf@kernel.org> (raw)
In-Reply-To: <87v7io9c23.fsf@bootlin.com> (Miquel Raynal's message of "Wed, 03 Dec 2025 09:58:28 +0100")

On Wed, Dec 03 2025, Miquel Raynal wrote:

>> 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.

Yeah, that is what I was thinking. I have mostly worked with NOR flashes
and with those writes are so slow that the transmission time is pretty
much noise.

>>
>> Write performance numbers from AM62A SK with W35N01JW OSPI NAND:
>>
>>    - without PHY: 6 MB/s
>>    - with PHY: 9.2 MB/s

Nice!

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

I suppose we should have a generic mechanism in SPI MEM, and then only
NAND would use it?

-- 
Regards,
Pratyush Yadav

  parent reply	other threads:[~2025-12-12  6:44 UTC|newest]

Thread overview: 74+ 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 ` 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-11 19:32   ` Santhosh Kumar K
2025-08-13 20:26   ` Mark Brown
2025-08-13 20:26     ` Mark Brown
2025-08-14 11:34     ` Santhosh Kumar K
2025-08-14 11:34       ` Santhosh Kumar K
2025-08-14 12:34       ` Mark Brown
2025-08-14 12:34         ` Mark Brown
2025-08-22  6:05         ` Santhosh Kumar K
2025-08-22  6:05           ` Santhosh Kumar K
2025-09-10  8:07         ` Miquel Raynal
2025-09-10  8:07           ` Miquel Raynal
2025-08-24 17:02     ` Miquel Raynal
2025-08-24 17:02       ` Miquel Raynal
2025-09-10  8:21   ` Miquel Raynal
2025-09-10  8:21     ` Miquel Raynal
2025-09-20 17:55     ` Santhosh Kumar K
2025-09-20 17:55       ` Santhosh Kumar K
2025-10-28 15:41       ` Miquel Raynal
2025-10-28 15:41         ` Miquel Raynal
2025-11-05  8:55         ` Santhosh Kumar K
2025-11-05  8:55           ` Santhosh Kumar K
2025-11-05  9:35           ` Miquel Raynal
2025-11-05  9:35             ` Miquel Raynal
2025-11-18 13:42             ` Pratyush Yadav
2025-11-18 13:42               ` Pratyush Yadav
2025-12-03  8:02               ` Santhosh Kumar K
2025-12-03  8:02                 ` Santhosh Kumar K
2025-12-03  8:58                 ` Miquel Raynal
2025-12-03  8:58                   ` Miquel Raynal
2025-12-10 11:33                   ` Santhosh Kumar K
2025-12-10 11:33                     ` Santhosh Kumar K
2025-12-12  6:43                   ` Pratyush Yadav [this message]
2025-12-12  6:43                     ` Pratyush Yadav
2025-11-18 13:49       ` Pratyush Yadav
2025-11-18 13:49         ` Pratyush Yadav
2025-12-03  8:02         ` Santhosh Kumar K
2025-12-03  8:02           ` Santhosh Kumar K
2025-12-03  9:28           ` Michael Walle
2025-12-03  9:28             ` Michael Walle
2025-12-03  9:50             ` Miquel Raynal
2025-12-03  9:50               ` Miquel Raynal
2025-12-03 14:12               ` Michael Walle
2025-12-03 14:12                 ` Michael Walle
2025-12-10 11:36                 ` Santhosh Kumar K
2025-12-10 11:36                   ` Santhosh Kumar K
2025-12-10 11:34               ` Santhosh Kumar K
2025-12-10 11:34                 ` Santhosh Kumar K
2025-12-11 14:16                 ` Miquel Raynal
2025-12-11 14:16                   ` Miquel Raynal
2025-12-04 16:54           ` Mahapatra, Amit Kumar
2025-12-04 16:54             ` Mahapatra, Amit Kumar
2025-12-10 11:34             ` Santhosh Kumar K
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   ` 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   ` 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   ` 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   ` 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   ` 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   ` 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   ` 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   ` Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 10/10] spi: cadence-quadspi: Define cqspi_get_tuning_params() Santhosh Kumar K
2025-08-11 19:32   ` 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=86tsxw6vyr.fsf@kernel.org \
    --to=pratyush@kernel.org \
    --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=miquel.raynal@bootlin.com \
    --cc=mwalle@kernel.org \
    --cc=p-mantena@ti.com \
    --cc=praneeth@ti.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.