Message-ID: <0928678d-7f5e-418c-a006-ae56f7534ff5@ti.com>
Date: Wed, 10 Dec 2025 17:03:28 +0530
From: Santhosh Kumar K <s-k6@...com>
To: Miquel Raynal <miquel.raynal@...tlin.com>
CC: Pratyush Yadav <pratyush@...nel.org>, <richard@....at>, <vigneshr@...com>,
	<broonie@...nel.org>, <tudor.ambarus@...aro.org>, <mwalle@...nel.org>,
	<p-mantena@...com>, <linux-spi@...r.kernel.org>,
	<linux-mtd@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
	<a-dutta@...com>, <u-kumar1@...com>, <praneeth@...com>, <s-k6@...com>
Subject: Re: [RFC PATCH 01/10] spi: spi-mem: Introduce support for tuning
 controller

Miquel,

On 03/12/25 14:28, 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.

Yes, for now - on a tuning failure we can simply return an error and
fallback to the non-PHY, slower operation.

Also, note that "max-1" can mean different things depending on the
spi-mem client. It may refer to a secondary OSDR read_op if the primary
OSDR variant (e.g. 0xcb) fails, or falling back to OSDR when ODDR fails,
and so on. The exact logic will need further discussion once the basic
tuning support is in place.

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

Regarding dummy cycles, I meant adjusting them only as a consequence of
changing frequency, since we would drop to a lower frequency when tuning
fails.

For instance, on the W35N01JW OSPI NAND (using Fast Read I/O), the
required dummy cycles vary with the operating frequency:
    - 8 cycles at 86 MHz
    - 12 cycles at 124 MHz
    - 20 cycles at 166 MHz

So for flashes like this, we do need to call .configure_chip() when the
frequency changes.

Again, as I said earlier, we can revisit detailed failure-handling
logic after the basic tuning infrastructure is merged.

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

> 
> Thanks,
> Miquèl

Powered by blists - more mailing lists