[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87cy8khcu7.fsf@bootlin.com>
Date: Sun, 24 Aug 2025 19:02:56 +0200
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Mark Brown <broonie@...nel.org>
Cc: Santhosh Kumar K <s-k6@...com>, richard@....at, vigneshr@...com,
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
Hello,
On 13/08/2025 at 21:26:06 +01, Mark Brown <broonie@...nel.org> wrote:
> On Tue, Aug 12, 2025 at 01:02:10AM +0530, Santhosh Kumar K 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). Add a hook that spi-mem client devices can call in order to tune
>> the controller to operate in a given mode and data rate.
>>
>> This is somewhat similar to eMMC/SD tuning for higher speed modes like
>> HS200, but there isn't a standard specification around the same though.
>
> Should we have something that blocks these tuning required modes without
> the appropriate tuning, and/or allows discovery of which modes require
> this tuning? This all feels very landmineish - client drivers just have
> to know when tuning is required.
The maximum bus frequency will tell whether tuning is relevant or not I
guess.
In the case of the Cadence controller, the bus speed is key to determine
whether calibration should happen or not because when PHY calibration is
enabled, the SPI bus frequency is equal to the controller clock rate
(pre-scalers are bypassed).
So the criteria for enabling calibration is:
max SPI bus freq >= min controller clock rate
Thanks,
Miquèl
Powered by blists - more mailing lists