Linux SPI subsystem development
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Conor Dooley <conor.dooley@microchip.com>
Cc: Conor Dooley <conor@kernel.org>,  Santhosh Kumar K <s-k6@ti.com>,
	<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: Fri, 05 Jun 2026 09:26:13 +0200	[thread overview]
Message-ID: <87tsrh4fe2.fsf@bootlin.com> (raw)
In-Reply-To: <20260605-regulate-crawling-253c6d6bd971@wendy> (Conor Dooley's message of "Fri, 5 Jun 2026 08:17:18 +0100")

On 05/06/2026 at 08:17:18 +01, Conor Dooley <conor.dooley@microchip.com> wrote:

> On Fri, Jun 05, 2026 at 08:32:56AM +0200, Miquel Raynal wrote:
>> On 04/06/2026 at 09:36:49 +01, Conor Dooley <conor@kernel.org> wrote:
>> 
>> > On Thu, Jun 04, 2026 at 09:14:16AM +0200, Miquel Raynal wrote:
>> >> Hi Conor,
>> >> 
>> >> >> >> > Right, and this I guess is what scuppers letting the controller driver
>> >> >> >> > sort the configuration out itself and leaving the property as-is.
>> >> >> >> > It could be that the speed in spi-max-frequency is lower than the "base
>> >> >> >> > speed" of the controller but because of board routing or device
>> >> >> >> > capability that the tuned mode is still required, right?
>> >> >> >> 
>> >> >> >> I do not actually expect any tuned mode/frequency to be mandatory.
>> >> >> >
>> >> >> > I think you misunderstood my use of "required", I meant that the new
>> >> >> > property/information was needed in the scenario I described, not that it
>> >> >> > should be a required property in a binding.
>> >> >> 
>> >> >> Yes I misunderstood the term indeed. However I still fail to catch what
>> >> >> you meant here, I'm sorry. Would you mind rephrasing?
>> >> >
>> >> > I was talking about a scenario where you want to use the tuned mode to
>> >> > achieve the maximum rate because of the device and/or board configuration,
>> >> > but the rate is below the point where the controller would need tuning.
>> >> > Say the controller needs tuning above 8 Hz but the conditions require
>> >> > tuning to achieve more than 5 Hz. In this example, if the device can do
>> >> > 6 Hz, spi-max-frequency (in the current form) would be set to 6 Hz, and
>> >> > the controller would not enable the tuned mode, leading to problems
>> >> > because the inflection point determined from the controller compatible
>> >> > of 8 Hz would not have been reached.
>> >> 
>> >> I don't think this is a real situation. If the "conditions", as you say
>> >> (ie. PCB routing, mostly) require tuning above 5, then spi-max-frequency
>> >> should be 5.
>> >
>> > Then tuning mode would never be used.
>> 
>> Well, this is exactly what we propose in this series, a way to indicate
>> two maximum frequencies, one that just works (like before) and a higher
>> frequency that is only reachable after an extra tuning procedure.
>> 
>> > Remember, this is a theoretical world
>> > where spi-max-frequency would contain the tuned frequency and the
>> > controller was using compatible-specific speed thresholds to determine
>> > if tuning was required.
>> 
>> That is not what we are proposing. I don't think indicating the "after
>> tuning" frequency in a property that has long been used for an always
>> reachable frequency is wise. Hence either the use of an array (the
>> second entry could contain a higher frequency) or a secondary
>> spi-max-frequency-whatever property.
>
> I am/was trying to come up with a scenario that would justify the patch
> man, stop trying to interpret it as what I want done.

Ah :-) Sorry the intention was unclear to me. So what is your preferred
take in the end?

  reply	other threads:[~2026-06-05  7:26 UTC|newest]

Thread overview: 64+ 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-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
2026-06-02 16:18         ` Conor Dooley
2026-06-03 15:54           ` Miquel Raynal
2026-06-03 16:07             ` Conor Dooley
2026-06-03 16:29               ` Miquel Raynal
2026-06-03 16:40                 ` Conor Dooley
2026-06-04  7:14                   ` Miquel Raynal
2026-06-04  8:36                     ` Conor Dooley
2026-06-05  6:32                       ` Miquel Raynal
2026-06-05  7:17                         ` Conor Dooley
2026-06-05  7:26                           ` Miquel Raynal [this message]
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-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-04 12:01                 ` Santhosh Kumar K
2026-06-02 16:49   ` Rob Herring
2026-06-03 16:01     ` Miquel Raynal
2026-06-03 17:38       ` Rob Herring
2026-06-03 19:00         ` Michael Walle
2026-06-04 12:07           ` Santhosh Kumar K
2026-06-04  7:28         ` Miquel Raynal
2026-06-04 12:04           ` Santhosh Kumar K
2026-05-27 17:55 ` [PATCH v3 03/13] spi: parse two-element spi-max-frequency property Santhosh Kumar K
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-28  8:43   ` Miquel Raynal
2026-06-04 12:10     ` Santhosh Kumar K
2026-06-05  6:15       ` 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-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 17:55 ` [PATCH v3 08/13] spi: cadence-quadspi: add PHY tuning support Santhosh Kumar K
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-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-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-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=87tsrh4fe2.fsf@bootlin.com \
    --to=miquel.raynal@bootlin.com \
    --cc=a-dutta@ti.com \
    --cc=broonie@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=conor.dooley@microchip.com \
    --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