From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Mark Brown <broonie@kernel.org>
Cc: Santhosh Kumar K <s-k6@ti.com>,
richard@nod.at, vigneshr@ti.com, tudor.ambarus@linaro.org,
pratyush@kernel.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: Wed, 10 Sep 2025 10:07:50 +0200 [thread overview]
Message-ID: <87y0qmenmx.fsf@bootlin.com> (raw)
In-Reply-To: <2f051eae-61c7-4bff-9f85-cf37b02a7ea3@sirena.org.uk> (Mark Brown's message of "Thu, 14 Aug 2025 13:34:38 +0100")
On 14/08/2025 at 13:34:38 +01, Mark Brown <broonie@kernel.org> wrote:
> On Thu, Aug 14, 2025 at 05:04:33PM +0530, Santhosh Kumar K wrote:
>> On 14/08/25 01:56, Mark Brown wrote:
>
>> > 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 flash's maximum operating frequency determines whether PHY tuning is
>> required, as we need tuning in case of Cadence controller for frequencies
>> over 50 MHz.
>
> That's entirely specific to the Candence controller from the sounds of
> it, that makes it hard to write a client driver if you need to know
> exactly what the controller you're dealing with is and what it's
> requirements are.
>
>> And we do check for this condition - see Patch 07/10,
>> cqspi_phy_op_eligible_sdr(), which currently verifies the flash frequency
>> against 166 MHz. This logic can be improved by implementing both min and max
>> frequency checks, will update in the following version.
>
> I can't actually tell how that verifies if the tuning has been done
> appropriately TBH, at least not without more effort than I'd care to
> (and the tuning only gets added in patch 10?).
Santhosh, do you need more inputs? Or can you send an updated version?
I am still thinking about the interface on the spi-mem/spi-nand side,
but please iterate so we can move forward.
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Mark Brown <broonie@kernel.org>
Cc: Santhosh Kumar K <s-k6@ti.com>,
richard@nod.at, vigneshr@ti.com, tudor.ambarus@linaro.org,
pratyush@kernel.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: Wed, 10 Sep 2025 10:07:50 +0200 [thread overview]
Message-ID: <87y0qmenmx.fsf@bootlin.com> (raw)
In-Reply-To: <2f051eae-61c7-4bff-9f85-cf37b02a7ea3@sirena.org.uk> (Mark Brown's message of "Thu, 14 Aug 2025 13:34:38 +0100")
On 14/08/2025 at 13:34:38 +01, Mark Brown <broonie@kernel.org> wrote:
> On Thu, Aug 14, 2025 at 05:04:33PM +0530, Santhosh Kumar K wrote:
>> On 14/08/25 01:56, Mark Brown wrote:
>
>> > 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 flash's maximum operating frequency determines whether PHY tuning is
>> required, as we need tuning in case of Cadence controller for frequencies
>> over 50 MHz.
>
> That's entirely specific to the Candence controller from the sounds of
> it, that makes it hard to write a client driver if you need to know
> exactly what the controller you're dealing with is and what it's
> requirements are.
>
>> And we do check for this condition - see Patch 07/10,
>> cqspi_phy_op_eligible_sdr(), which currently verifies the flash frequency
>> against 166 MHz. This logic can be improved by implementing both min and max
>> frequency checks, will update in the following version.
>
> I can't actually tell how that verifies if the tuning has been done
> appropriately TBH, at least not without more effort than I'd care to
> (and the tuning only gets added in patch 10?).
Santhosh, do you need more inputs? Or can you send an updated version?
I am still thinking about the interface on the spi-mem/spi-nand side,
but please iterate so we can move forward.
Thanks,
Miquèl
next prev parent reply other threads:[~2025-09-10 8:08 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-11 19:32 [RFC PATCH 00/10] SPINAND PHY Tuning Series Santhosh Kumar K
2025-08-11 19:32 ` Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 01/10] spi: spi-mem: Introduce support for tuning controller Santhosh Kumar K
2025-08-11 19:32 ` Santhosh Kumar K
2025-08-13 20:26 ` Mark Brown
2025-08-13 20:26 ` Mark Brown
2025-08-14 11:34 ` Santhosh Kumar K
2025-08-14 11:34 ` Santhosh Kumar K
2025-08-14 12:34 ` Mark Brown
2025-08-14 12:34 ` Mark Brown
2025-08-22 6:05 ` Santhosh Kumar K
2025-08-22 6:05 ` Santhosh Kumar K
2025-09-10 8:07 ` Miquel Raynal [this message]
2025-09-10 8:07 ` Miquel Raynal
2025-08-24 17:02 ` Miquel Raynal
2025-08-24 17:02 ` Miquel Raynal
2025-09-10 8:21 ` Miquel Raynal
2025-09-10 8:21 ` Miquel Raynal
2025-09-20 17:55 ` Santhosh Kumar K
2025-09-20 17:55 ` Santhosh Kumar K
2025-10-28 15:41 ` Miquel Raynal
2025-10-28 15:41 ` Miquel Raynal
2025-11-05 8:55 ` Santhosh Kumar K
2025-11-05 8:55 ` Santhosh Kumar K
2025-11-05 9:35 ` Miquel Raynal
2025-11-05 9:35 ` Miquel Raynal
2025-11-18 13:42 ` Pratyush Yadav
2025-11-18 13:42 ` Pratyush Yadav
2025-12-03 8:02 ` Santhosh Kumar K
2025-12-03 8:02 ` Santhosh Kumar K
2025-12-03 8:58 ` Miquel Raynal
2025-12-03 8:58 ` Miquel Raynal
2025-12-10 11:33 ` Santhosh Kumar K
2025-12-10 11:33 ` Santhosh Kumar K
2025-12-12 6:43 ` Pratyush Yadav
2025-12-12 6:43 ` Pratyush Yadav
2025-11-18 13:49 ` Pratyush Yadav
2025-11-18 13:49 ` Pratyush Yadav
2025-12-03 8:02 ` Santhosh Kumar K
2025-12-03 8:02 ` Santhosh Kumar K
2025-12-03 9:28 ` Michael Walle
2025-12-03 9:28 ` Michael Walle
2025-12-03 9:50 ` Miquel Raynal
2025-12-03 9:50 ` Miquel Raynal
2025-12-03 14:12 ` Michael Walle
2025-12-03 14:12 ` Michael Walle
2025-12-10 11:36 ` Santhosh Kumar K
2025-12-10 11:36 ` Santhosh Kumar K
2025-12-10 11:34 ` Santhosh Kumar K
2025-12-10 11:34 ` Santhosh Kumar K
2025-12-11 14:16 ` Miquel Raynal
2025-12-11 14:16 ` Miquel Raynal
2025-12-04 16:54 ` Mahapatra, Amit Kumar
2025-12-04 16:54 ` Mahapatra, Amit Kumar
2025-12-10 11:34 ` Santhosh Kumar K
2025-12-10 11:34 ` Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 02/10] spi: spi-mem: Define spi_mem_tuning_params and spi_mem_get_tuning_params() Santhosh Kumar K
2025-08-11 19:32 ` Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 03/10] mtd: nand: spi: Introduce _execute_tuning for mtd devices Santhosh Kumar K
2025-08-11 19:32 ` Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 04/10] mtd: mtdcore: Call mtd_execute_tuning during mtd_register Santhosh Kumar K
2025-08-11 19:32 ` Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 05/10] spi: cadence-quadspi: Move cqspi_readdata_capture() above all operations Santhosh Kumar K
2025-08-11 19:32 ` Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 06/10] spi: cadence-quadspi: Use BIT() macro for CQSPI_REG_READCAPTURE_BYPASS Santhosh Kumar K
2025-08-11 19:32 ` Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 07/10] spi: cadence-quadspi: Enable PHY for aligned DAC reads Santhosh Kumar K
2025-08-11 19:32 ` Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 08/10] spi: cadence-quadspi: Enable PHY for data writes Santhosh Kumar K
2025-08-11 19:32 ` Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 09/10] spi: cadence-quadspi: Implement PHY for higher frequencies in SDR mode Santhosh Kumar K
2025-08-11 19:32 ` Santhosh Kumar K
2025-08-11 19:32 ` [RFC PATCH 10/10] spi: cadence-quadspi: Define cqspi_get_tuning_params() Santhosh Kumar K
2025-08-11 19:32 ` Santhosh Kumar K
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=87y0qmenmx.fsf@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=a-dutta@ti.com \
--cc=broonie@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=mwalle@kernel.org \
--cc=p-mantena@ti.com \
--cc=praneeth@ti.com \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=s-k6@ti.com \
--cc=tudor.ambarus@linaro.org \
--cc=u-kumar1@ti.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.