From: "Cédric Le Goater" <clg@kaod.org>
To: Pratyush Yadav <p.yadav@ti.com>
Cc: <linux-spi@vger.kernel.org>, <linux-mtd@lists.infradead.org>,
Mark Brown <broonie@kernel.org>,
Tudor Ambarus <tudor.ambarus@microchip.com>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
<linux-aspeed@lists.ozlabs.org>, Joel Stanley <joel@jms.id.au>,
Andrew Jeffery <andrew@aj.id.au>,
Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>,
<devicetree@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, Tao Ren <rentao.bupt@gmail.com>
Subject: Re: [PATCH v4 08/11] spi: aspeed: Calibrate read timings
Date: Mon, 4 Apr 2022 09:30:25 +0200 [thread overview]
Message-ID: <8c88e726-0ddb-e2ba-35df-676cfc3d0475@kaod.org> (raw)
In-Reply-To: <20220331164115.w5q3wxlmwcg3w4ns@ti.com>
On 3/31/22 18:41, Pratyush Yadav wrote:
> Hi,
>
> On 25/03/22 11:08AM, Cédric Le Goater wrote:
>> To accommodate the different response time of SPI transfers on different
>> boards and different SPI NOR devices, the Aspeed controllers provide a
>> set of Read Timing Compensation registers to tune the timing delays
>> depending on the frequency being used. The AST2600 SoC has one of these
>> registers per device. On the AST2500 and AST2400 SoCs, the timing
>> register is shared by all devices which is problematic to get good
>> results other than for one device.
>>
>> The algorithm first reads a golden buffer at low speed and then performs
>> reads with different clocks and delay cycle settings to find a breaking
>> point. This selects a default good frequency for the CEx control register.
>> The current settings are a bit optimistic as we pick the first delay giving
>> good results. A safer approach would be to determine an interval and
>> choose the middle value.
>>
>> Calibration is performed when the direct mapping for reads is created.
>> Since the underlying spi-nor object needs to be initialized to create
>> the spi_mem operation for direct mapping, we should be fine. Having a
>> specific API would clarify the requirements though.
>>
>> Cc: Pratyush Yadav <p.yadav@ti.com>
>> Reviewed-by: Joel Stanley <joel@jms.id.au>
>> Tested-by: Joel Stanley <joel@jms.id.au>
>> Tested-by: Tao Ren <rentao.bupt@gmail.com>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>> drivers/spi/spi-aspeed-smc.c | 281 +++++++++++++++++++++++++++++++++++
>> 1 file changed, 281 insertions(+)
>>
> [...]
>> @@ -517,6 +527,8 @@ static int aspeed_spi_chip_adjust_window(struct aspeed_spi_chip *chip,
>> return 0;
>> }
>>
>> +static int aspeed_spi_do_calibration(struct aspeed_spi_chip *chip);
>> +
>> static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
>> {
>> struct aspeed_spi *aspi = spi_controller_get_devdata(desc->mem->spi->master);
>> @@ -565,6 +577,8 @@ static int aspeed_spi_dirmap_create(struct spi_mem_dirmap_desc *desc)
>> chip->ctl_val[ASPEED_SPI_READ] = ctl_val;
>> writel(chip->ctl_val[ASPEED_SPI_READ], chip->ctl);
>>
>> + ret = aspeed_spi_do_calibration(chip);
>> +
>
> I am still not convinced this is a good idea. The API does not say
> anywhere what dirmap_create must be called after the flash is completely
> initialized, though that is what is done currently in practice.
Yes because we wouldn't have a correct 'spi_mem_dirmap_info' if it wasn't
the case. May be change the documentation ?
> I think
> an explicit API to mark flash as "ready for calibration" would be a
> better idea.
OK. Since the above is a oneliner, it should not be a problem to move
it under a new handler if needed.
The dirmap_create() handler expects the spi-mem descriptor and the field
'desc->info.op_tmpl' to be correctly initialized in order to compute the
control register value, which is a requirement for dirmap_read(). The
calibration sequence simply comes after.
AFAICT, there is nothing incorrect today.
> Tudor/Mark/Miquel, what do you think?
Thanks,
C.
next prev parent reply other threads:[~2022-04-04 7:30 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-25 10:08 [PATCH v4 00/11] spi: spi-mem: Convert Aspeed SMC driver to spi-mem Cédric Le Goater
2022-03-25 10:08 ` [PATCH v4 01/11] ARM: dts: aspeed: Adjust "reg" property of FMC/SPI controllers Cédric Le Goater
2022-03-25 10:08 ` [PATCH v4 02/11] dt-bindings: spi: Add Aspeed SMC controllers device tree binding Cédric Le Goater
2022-03-30 19:19 ` Pratyush Yadav
2022-03-31 7:36 ` Cédric Le Goater
2022-03-31 12:20 ` Pratyush Yadav
2022-03-25 10:08 ` [PATCH v4 03/11] spi: spi-mem: Convert Aspeed SMC driver to spi-mem Cédric Le Goater
2022-03-29 8:56 ` Cédric Le Goater
2022-03-29 10:49 ` Mark Brown
2022-03-30 19:33 ` Pratyush Yadav
2022-04-04 7:06 ` Cédric Le Goater
2022-04-05 19:29 ` Pratyush Yadav
2022-03-25 10:08 ` [PATCH v4 04/11] spi: aspeed: Add support for direct mapping Cédric Le Goater
2022-03-30 19:45 ` Pratyush Yadav
2022-04-04 7:11 ` Cédric Le Goater
2022-04-05 19:27 ` Pratyush Yadav
2022-03-25 10:08 ` [PATCH v4 05/11] spi: aspeed: Adjust direct mapping to device size Cédric Le Goater
2022-03-25 10:08 ` [PATCH v4 06/11] spi: aspeed: Workaround AST2500 limitations Cédric Le Goater
2022-03-25 10:08 ` [PATCH v4 07/11] spi: aspeed: Add support for the AST2400 SPI controller Cédric Le Goater
2022-03-25 10:08 ` [PATCH v4 08/11] spi: aspeed: Calibrate read timings Cédric Le Goater
2022-03-30 11:53 ` Chin-Ting Kuo
2022-03-30 12:14 ` Cédric Le Goater
2022-03-31 2:46 ` Chin-Ting Kuo
2022-03-31 7:15 ` Cédric Le Goater
2022-03-31 8:34 ` Chin-Ting Kuo
2022-03-31 16:41 ` Pratyush Yadav
2022-04-04 7:30 ` Cédric Le Goater [this message]
2022-04-05 19:22 ` Pratyush Yadav
2022-03-25 10:08 ` [PATCH v4 09/11] ARM: dts: aspeed: Enable Dual SPI RX transfers Cédric Le Goater
2022-03-25 10:08 ` [PATCH v4 10/11] ARM: dts: aspeed-g4: Set spi-max-frequency for all flashes Cédric Le Goater
2022-03-25 10:08 ` [PATCH v4 11/11] mtd: spi-nor: aspeed: set the decoding size to at least 2MB for AST2600 Cédric Le Goater
2022-03-30 19:49 ` Pratyush Yadav
2022-04-01 14:12 ` [PATCH v4 00/11] spi: spi-mem: Convert Aspeed SMC driver to spi-mem Jae Hyun Yoo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8c88e726-0ddb-e2ba-35df-676cfc3d0475@kaod.org \
--to=clg@kaod.org \
--cc=andrew@aj.id.au \
--cc=broonie@kernel.org \
--cc=chin-ting_kuo@aspeedtech.com \
--cc=devicetree@vger.kernel.org \
--cc=joel@jms.id.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=miquel.raynal@bootlin.com \
--cc=p.yadav@ti.com \
--cc=rentao.bupt@gmail.com \
--cc=richard@nod.at \
--cc=robh+dt@kernel.org \
--cc=tudor.ambarus@microchip.com \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®