[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87seguemzu.fsf@bootlin.com>
Date: Wed, 10 Sep 2025 10:21:41 +0200
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Santhosh Kumar K <s-k6@...com>
Cc: <richard@....at>, <vigneshr@...com>, <broonie@...nel.org>,
<tudor.ambarus@...aro.org>, <pratyush@...nel.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>
Subject: Re: [RFC PATCH 01/10] spi: spi-mem: Introduce support for tuning
controller
On 12/08/2025 at 01:02:10 +0530, Santhosh Kumar K <s-k6@...com> wrote:
> From: Pratyush Yadav <pratyush@...nel.org>
>
> Some controllers like the Cadence OSPI controller need to perform a
> tuning sequence to operate at high data rates. Tuning is needs to happen
> once the device is switched to appropriate mode (say 8S-8S-8S or
> 8D-8D-8D).
This is actually wrong. Tuning is way more generic than that :)
If someone wants to use a chip at a high frequency (50MHz in your case,
but whatever, there is a threshold above which additional care must be
taken), it must go through the calibration step. It does not matter in
which mode you are. Calibration would still be relevant in single SDR
mode.
This 50MHz bothered Mark because it is too Cadence specific. Maybe this
should be a controller parameter? If the spi-mem core (or even the spi
core, by extensino) sees that the design allows running at XMHz (due to
the SPI peripheral properties or simply the absence of any limitation),
and if the controller states that it requires an extra tuning step above
YMHz (and X > Y), then it launches the calibration.
>From a core perspective, I would like the calibration hook to be as
simple as possible, because what "calibration" means is highly
controller and chip specific.
The Cadence SPI controller driver could request the pattern through
the nvmem interface or maybe we can even include it in the kernel
through some type of firmware interface (it could be stored anywhere)
and if it gets it, it writes it to the device cache. Once done, it takes
the fastest available read operation available for the chip and performs
its calibration.
The calibration hook no longer needs anything SPI driver specific. I
don't know if still requires anything chip specific though (like the
optimal read operation), but can you please try implementing that and
then we'll discuss this further.
Thanks,
Miquèl
Powered by blists - more mailing lists