From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Santhosh Kumar K <s-k6@ti.com>
Cc: Conor Dooley <conor@kernel.org>, <broonie@kernel.org>,
<robh@kernel.org>, <krzk+dt@kernel.org>, <conor+dt@kernel.org>,
<richard@nod.at>, <vigneshr@ti.com>, <pratyush@kernel.org>,
<mwalle@kernel.org>, <takahiro.kuwano@infineon.com>,
<linux-spi@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-mtd@lists.infradead.org>,
<praneeth@ti.com>, <u-kumar1@ti.com>, <a-dutta@ti.com>
Subject: Re: [PATCH v3 01/13] spi: dt-bindings: allow spi-max-frequency to specify a frequency pair
Date: Tue, 02 Jun 2026 14:05:53 +0200 [thread overview]
Message-ID: <87cxy92llq.fsf@bootlin.com> (raw)
In-Reply-To: <eaa75113-2b89-468d-aca8-932bc7e33a7d@ti.com> (Santhosh Kumar K.'s message of "Mon, 1 Jun 2026 13:15:59 +0530")
Hello Conor, Santhosh,
>> I also don't get the point of this property, why can't you just set
>> the
>> max that the device can do and if the controller can configure itself to
>> be fast enough it will do so, and if it can't then it'll pick whatever
>> the fastest it can actually do instead?
If I may, this is not doable because there is always a phase at low
speed. By low speed, I mean the speed which allows reliable data
transfers between the host and the device. This "maximum low" speed is
non discoverable, it is necessary to describe it. As of today, it is
widely used (and I believe for good reasons) and covers 99.99% of the
use cases.
>> Seems like you're abusing a peripheral property to encode information
>> about the controller.
>
> The controller-side approach you mentioned is similar to what I had in
> v2, where a compatible-specific base_freq is used for non-PHY ops.
>
> Miquel,
>
> I think we should revert to the v2 approach.
>
> The non-PHY frequency is a controller limitation/capability rather than
> a flash characteristic, so it seems more appropriate to keep it in the
> controller driver as Conor suggested.
The non tuned frequency is the maximum frequency one could use
reliably. It is not controller specific. It is mostly board specific,
and to some extend may also be chip specific.
The tuned frequency is the maximum frequency one could use reliably
after line a controller or chip specific training procedure. It is
also the result of an aggregated set of non discoverable hardware
limitations:
- board routing
- chip capability
- controller capability
We must try to think about other (non TI) possible use cases of these
properties and also take into account the existing DT expectations. If
turning the property into an array is too complex, we may go for a
second property, but I believe the name should not be TI specific (but
I'll let the final decision to the DT gurus).
Thanks,
Miquèl
next prev parent reply other threads:[~2026-06-02 12:06 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-27 17:55 [PATCH v3 00/13] spi: cadence-quadspi: add PHY tuning support Santhosh Kumar K
2026-05-27 17:55 ` [PATCH v3 01/13] spi: dt-bindings: allow spi-max-frequency to specify a frequency pair Santhosh Kumar K
2026-05-27 18:17 ` sashiko-bot
2026-05-28 8:32 ` Miquel Raynal
2026-05-28 17:36 ` Conor Dooley
2026-05-30 8:54 ` Krzysztof Kozlowski
2026-06-01 7:45 ` Santhosh Kumar K
2026-06-02 12:05 ` Miquel Raynal [this message]
2026-06-02 16:18 ` Conor Dooley
2026-05-27 17:55 ` [PATCH v3 02/13] spi: dt-bindings: cdns,qspi-nor: add PHY tuning pattern partition property Santhosh Kumar K
2026-05-27 18:11 ` sashiko-bot
2026-05-28 8:34 ` Miquel Raynal
2026-05-30 8:52 ` Krzysztof Kozlowski
2026-06-01 8:26 ` Santhosh Kumar K
2026-06-01 11:26 ` Krzysztof Kozlowski
2026-06-01 11:47 ` Krzysztof Kozlowski
2026-06-02 6:30 ` Santhosh Kumar K
2026-06-02 12:08 ` Krzysztof Kozlowski
2026-06-02 12:36 ` Miquel Raynal
2026-06-02 12:48 ` Krzysztof Kozlowski
2026-06-02 16:49 ` Rob Herring
2026-05-27 17:55 ` [PATCH v3 03/13] spi: parse two-element spi-max-frequency property Santhosh Kumar K
2026-05-27 18:19 ` sashiko-bot
2026-05-28 8:37 ` Miquel Raynal
2026-05-27 17:55 ` [PATCH v3 04/13] spi: spi-mem: add spi_mem_apply_base_freq_cap() Santhosh Kumar K
2026-05-27 18:32 ` sashiko-bot
2026-05-28 8:43 ` Miquel Raynal
2026-05-27 17:55 ` [PATCH v3 05/13] spi: spi-mem: add execute_tuning callback and spi_mem_execute_tuning() Santhosh Kumar K
2026-05-27 18:21 ` sashiko-bot
2026-05-28 8:44 ` Miquel Raynal
2026-05-27 17:55 ` [PATCH v3 06/13] spi: cadence-quadspi: move cqspi_readdata_capture earlier Santhosh Kumar K
2026-05-27 17:55 ` [PATCH v3 07/13] spi: cadence-quadspi: add DQS support to read data capture Santhosh Kumar K
2026-05-27 18:17 ` sashiko-bot
2026-05-27 17:55 ` [PATCH v3 08/13] spi: cadence-quadspi: add PHY tuning support Santhosh Kumar K
2026-05-27 18:44 ` sashiko-bot
2026-05-28 8:54 ` Miquel Raynal
2026-06-01 8:44 ` Santhosh Kumar K
2026-05-27 17:55 ` [PATCH v3 09/13] spi: cadence-quadspi: reject 2-byte-address DDR ops on PHY-tunable hardware Santhosh Kumar K
2026-05-28 9:01 ` Miquel Raynal
2026-06-01 9:27 ` Santhosh Kumar K
2026-06-02 12:25 ` Miquel Raynal
2026-05-27 17:55 ` [PATCH v3 10/13] spi: cadence-quadspi: enable PHY for direct reads and indirect writes Santhosh Kumar K
2026-05-27 18:36 ` sashiko-bot
2026-05-28 9:09 ` Miquel Raynal
2026-06-01 8:39 ` Santhosh Kumar K
2026-06-02 12:15 ` Miquel Raynal
2026-05-27 17:55 ` [PATCH v3 11/13] mtd: spinand: run PHY tuning after init and update dirmap frequencies Santhosh Kumar K
2026-05-27 19:04 ` sashiko-bot
2026-05-28 9:27 ` Miquel Raynal
2026-06-01 9:16 ` Santhosh Kumar K
2026-06-02 12:18 ` Miquel Raynal
2026-05-27 17:55 ` [PATCH v3 12/13] mtd: spi-nor: extract read op template construction into helper Santhosh Kumar K
2026-05-27 17:55 ` [PATCH v3 13/13] mtd: spi-nor: run PHY tuning after init and update dirmap frequency Santhosh Kumar K
2026-05-27 18:59 ` sashiko-bot
2026-05-28 8:30 ` [PATCH v3 00/13] spi: cadence-quadspi: add PHY tuning support Miquel Raynal
2026-06-01 8:02 ` 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=87cxy92llq.fsf@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=a-dutta@ti.com \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=conor@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@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=praneeth@ti.com \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=robh@kernel.org \
--cc=s-k6@ti.com \
--cc=takahiro.kuwano@infineon.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox