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

From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "Michael Walle" <mwalle@kernel.org>
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>,  <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 10:50:12 +0100	[thread overview]
Message-ID: <87jyz3ao8b.fsf@bootlin.com> (raw)
In-Reply-To: <DEOH4AUI33SQ.DGKJ4W258658@kernel.org> (Michael Walle's message of "Wed, 03 Dec 2025 10:28:23 +0100")

>>> I think we should start with the requirement to have the pattern flashed
>>> already and figure out how SPI NOR or SPI NAND can discover that
>>> (perhaps via NVMEM?).
>
> But we should also keep in mind that certain flashes might return
> tuning data during the dummy cycles. I.e. the PHY might probably be
> tuned on each read and there is no need for any pre-programmed
> pattern.
>
> I'm not saying it should be implemented, but the current
> implementation should be that flexible that it will be easy to add
> that later.

Conceptually, yes, but in practice, I know no controller capable of
using just a few cycles every transfer to calibrate themselves
automatically and reaching such an optimized speed state as the cadence
controller is capable of ATM.

Despite the end result being close, I would still consider this other
way to optimize the I/Os somewhat orthogonal. If someone has some
knowledge to share about the training patterns sent during the dummy
cycles, I am all ears though.

>> For SPI NOR, we do not have an equivalent "write-to-cache" possible, so
>> we still require a pre-flashed pattern region. At the moment this is
>> provided via a dedicated "phypattern" partition, and its offset is
>> obtained through the of_get_* APIs.
>>
>> Regarding ways to locate the partition:
>>
>> 1. Using NVMEM:
>>     a. Exposing the phypattern partition as an NVMEM cell and issuing an
>>        NVMEM read during tuning does not work reliably, because NVMEM
>>        ends up calling into the MTD read path and we cannot control which
>>        read_op variant is used for the read.
>>
>>     b. Advertising the partition as an NVMEM cell and using NVMEM only
>>        to fetch the offset is not possible either. NVMEM abstracts the
>>        private data, including partition offsets, so we can't retrieve
>>        the offset as well.
>
> You can probably extend the NVMEM API in some way - or switching the
> read_op on the fly.
>
>> 2. Using of_get_* APIs:
>>        Using the standard OF helpers to locate the phypattern partition
>>        and retrieve its offset is both reliable and straighforward, and
>>        is the approach currently implemented in v2.
>
> I don't like that hardcoded partition name which is basically
> becoming an ABI then.
>
> At least we'd need some kind of phandle to the partition inside the
> controller node (and get the ACK from the DT maintainers).

Yes, agreed, this is controller specific, if we need to use an of_ API
(which is still not needed for SPI NANDs, only for tuning the read SPI
NOR path), it should not just be a partition hardcoded name but a
phandle in the controller node.

Thanks,
Miquèl

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