Re: [PATCH RFC 0/4] mtd/spi-mem: Enable DQS support

From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Santhosh Kumar K <s-k6@ti.com>
Cc: Mark Brown <broonie@kernel.org>,
	 Richard Weinberger <richard@nod.at>,
	"Vignesh Raghavendra" <vigneshr@ti.com>,
	 Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	 <praneeth@ti.com>,  <u-kumar1@ti.com>, <p-mantena@ti.com>,
	 <a-dutta@ti.com>,  <linux-spi@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,  <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH RFC 0/4] mtd/spi-mem: Enable DQS support
Date: Tue, 10 Feb 2026 11:23:55 +0100	[thread overview]
Message-ID: <87pl6czykk.fsf@bootlin.com> (raw)
In-Reply-To: <41f49187-e68b-4731-ac86-7c346de63173@ti.com> (Santhosh Kumar K.'s message of "Sat, 7 Feb 2026 01:02:12 +0530")

On 07/02/2026 at 01:02:12 +0530, Santhosh Kumar K <s-k6@ti.com> wrote:

> Hello Miquel,
>
> On 06/02/26 00:36, Miquel Raynal wrote:
>> For his PHY tuning series on the Cadence QSPI controller embedded in TI
>> SoCs, Santhosh needs to access the availability of the DQS (data strobe)
>> signal. This is a chip dependent capability, which may sometimes be
>> enabled.
>> Create a SPI memory flag for it, let the SPI NAND core set this flag
>> when it knows about the capability, and show how to use it from a SPI
>> controller driver.
>> This is an alternative at needing a DT property. Please note that
>> there
>> are a few blind spots:
>> - the line may not be wired (this would be surprising, but can be
>>    flagged this time by a DT property)
>> - manufacturer drivers must enable the feature if it is
>>    available (especially for high speed DTR modes)
>> - this implementation is proposed for SPI NANDs only, if this proposal
>>    is accepted the same approach must be taken in SPI NOR.
>
> Thank you for the series!
>
> As mentioned in the tuning series, in addition to the flash advertising
> its DQS capability, we also need a DT property to describe whether DQS
> is physically connected to the controller. This can be represented using
> either a "dqs-wired" or "dqs-not-wired" property; the exact naming can
> be chosen based on the majority case.
>
> With this series, the controller will enable or disable DQS by logically
> AND-ing both pieces of information.

Do we really need this?

My expectation is that someone wiring an octal DTR SPI chip for high
speed octal DTR use **will** route the DQS signal. If this signal is not
wired, I want to consider this as a hardware bug.

As a result, the default case should be "if there is a DQS signal, use
it".

If, however people come up with non correctly routed chips but still
want high frequency support, the burden will be on them to ask for a DT
property describing a non compliant hardware layout, eg. the "no-dqs"
property. You can take this on your shoulders if you want, but I would
recommend not to, because this will require more patches and another
round of review from DT maintainers which, I believe, we do not need at
the moment. This DT property would be orthogonal and could very easily
be added in a second step, keeping this series "small".

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/