Re: [RFC PATCH 01/10] spi: spi-mem: Introduce support for tuning controller

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/