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

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

[Miquel Raynal]

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.

Here is the original thread which lead to this series:
https://lore.kernel.org/linux-spi/87v7gbdwdh.fsf@bootlin.com/T/#ma79fc364d7b882a48dbdf47203dde75df4bb0ec4

This series was compile tested only at this stage. As DDR tuning does
not yet work on my board, I cannot make sure this change has a real
impact.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
Miquel Raynal (4):
      spi: spi-mem: Flag DQS capability
      mtd: spi-nand: Set the DQS spi-mem capability if available
      mtd: spi-nand: winbond: Enable the DQS pin on W35N**JW series
      [DO NOT MERGE] spi: cadence-qspi: Retrieve DQS capability using the core helper

 drivers/mtd/nand/spi/core.c       |  4 ++++
 drivers/mtd/nand/spi/winbond.c    |  8 ++++----
 drivers/spi/spi-cadence-quadspi.c |  8 ++++++--
 drivers/spi/spi-mem.c             | 32 ++++++++++++++++++++++++++++++++
 include/linux/mtd/spinand.h       |  1 +
 include/linux/spi/spi-mem.h       |  4 ++++
 6 files changed, 51 insertions(+), 6 deletions(-)
---
base-commit: c5884449d02575c7984000eb30d2a2971c7dfcc7
change-id: 20260205-winbond-nand-next-phy-tuning-aabefc018032

Best regards,
-- 
Miquel Raynal <miquel.raynal@bootlin.com>

[PATCH RFC 1/4] spi: spi-mem: Flag DQS capability

[Miquel Raynal]

DQS is a typical SPI memory signal used to help with reading the data on
the bus at high speeds (especially in DTR mode) by avoiding clock
skews. The chip generates a clock signal synchronized with its data
output fronts, also called data strobe.

SPI NOR and SPI NAND cores must set this flag in order to indicate to
other layers that DQS is available.

Create a getter and a setter to reach this capability.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/spi/spi-mem.c       | 32 ++++++++++++++++++++++++++++++++
 include/linux/spi/spi-mem.h |  4 ++++
 2 files changed, 36 insertions(+)

diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index 444bd8ec34f5..b746a821c984 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -534,6 +534,38 @@ const char *spi_mem_get_name(struct spi_mem *mem)
 }
 EXPORT_SYMBOL_GPL(spi_mem_get_name);
 
+/**
+ * spi_mem_set_dqs() - Mark DQS as being available
+ * @mem: the SPI memory
+ *
+ * When reading at high frequencies (> 100MHz), especially when DTR is enabled,
+ * transfer speed is limited due to clock skews. In particular, the controller
+ * does not know the board propagation delay nor the memory chip internal delay
+ * (clock in to data out) and thus cannot optimize its sampling points.
+ * Mitigating this limitation is possible with the addition of a data strobe
+ * signal, commonly named DQS.
+ *
+ * Set the DQS boolean if the feature is available and configured at the chip
+ * level. Controllers may query this value.
+ */
+void spi_mem_set_dqs(struct spi_mem *mem)
+{
+	mem->dqs = true;
+}
+EXPORT_SYMBOL_GPL(spi_mem_set_dqs);
+
+/**
+ * spi_mem_has_dqs() - Query whether the DQS is available or not
+ * @mem: the SPI memory
+ *
+ * Return: a boolean indicating whether the DQS signal is available or not.
+ */
+bool spi_mem_has_dqs(struct spi_mem *mem)
+{
+	return mem->dqs;
+}
+EXPORT_SYMBOL_GPL(spi_mem_has_dqs);
+
 /**
  * spi_mem_adjust_op_size() - Adjust the data size of a SPI mem operation to
  *			      match controller limitations
diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
index a0543ca09da4..b58963242ba6 100644
--- a/include/linux/spi/spi-mem.h
+++ b/include/linux/spi/spi-mem.h
@@ -259,6 +259,7 @@ struct spi_mem_dirmap_desc {
  * @spi: the underlying SPI device
  * @drvpriv: spi_mem_driver private data
  * @name: name of the SPI memory device
+ * @dqs: extra data trobe pin available for high frequency read operations
  *
  * Extra information that describe the SPI memory device and may be needed by
  * the controller to properly handle this device should be placed here.
@@ -270,6 +271,7 @@ struct spi_mem {
 	struct spi_device *spi;
 	void *drvpriv;
 	const char *name;
+	bool dqs;
 };
 
 /**
@@ -440,6 +442,8 @@ bool spi_mem_default_supports_op(struct spi_mem *mem,
 }
 #endif /* CONFIG_SPI_MEM */
 
+void spi_mem_set_dqs(struct spi_mem *mem);
+bool spi_mem_has_dqs(struct spi_mem *mem);
 int spi_mem_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op);
 void spi_mem_adjust_op_freq(struct spi_mem *mem, struct spi_mem_op *op);
 u64 spi_mem_calc_op_duration(struct spi_mem *mem, struct spi_mem_op *op);

-- 
2.51.1

[PATCH RFC 2/4] mtd: spi-nand: Set the DQS spi-mem capability if available

[Miquel Raynal]

Check whether the NAND is capable of generating a DQS signal and set the
flag accordingly.

Not wiring the DQS signal on a DQS capable chip that will be used at
frequency requiring this signal may be considered a hardware bug, so
let's assume this line will be routed "in most cases". If/when we get
issues with this assumption, a DT property describing the lacking line
in the routing can be created.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/mtd/nand/spi/core.c | 4 ++++
 include/linux/mtd/spinand.h | 1 +
 2 files changed, 5 insertions(+)

diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 95df4dd5330d..67270e49c179 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -1974,6 +1974,10 @@ static int spinand_probe(struct spi_mem *mem)
 	read_op = *spinand->op_templates->read_cache;
 	write_op = *spinand->op_templates->write_cache;
 
+	/* Assume manufacturer drivers will enable the DQS pin if it is available */
+	if (spinand->flags & SPINAND_HAS_DQS)
+		spi_mem_set_dqs(mem);
+
 	ret = spi_mem_execute_tuning(mem, &read_op, &write_op);
 	if (ret && ret != -EOPNOTSUPP) {
 		dev_warn(&mem->spi->dev, "Failed to execute PHY tuning: %d\n",
diff --git a/include/linux/mtd/spinand.h b/include/linux/mtd/spinand.h
index 58abd306ebe3..72babba69c7a 100644
--- a/include/linux/mtd/spinand.h
+++ b/include/linux/mtd/spinand.h
@@ -483,6 +483,7 @@ struct spinand_ecc_info {
 #define SPINAND_HAS_PROG_PLANE_SELECT_BIT		BIT(2)
 #define SPINAND_HAS_READ_PLANE_SELECT_BIT		BIT(3)
 #define SPINAND_NO_RAW_ACCESS				BIT(4)
+#define SPINAND_HAS_DQS					BIT(5)
 
 /**
  * struct spinand_ondie_ecc_conf - private SPI-NAND on-die ECC engine structure

-- 
2.51.1

[PATCH RFC 3/4] mtd: spi-nand: winbond: Enable the DQS pin on W35N**JW series

[Miquel Raynal]

These chips have a DQS pin, enable it by default in DTR mode because
there is apparently no issue in setting it for lower frequencies, and
the extra power consumption seems very low compared to the current drawn
by the NAND array itself while operating.

This setting will be required for high speed I/O transfers (with PHY
tuning).

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/mtd/nand/spi/winbond.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/spi/winbond.c b/drivers/mtd/nand/spi/winbond.c
index 6dfd0dcc8ee7..7401ee1007c0 100644
--- a/drivers/mtd/nand/spi/winbond.c
+++ b/drivers/mtd/nand/spi/winbond.c
@@ -437,7 +437,7 @@ static int w35n0xjw_vcr_cfg(struct spinand_device *spinand,
 	else if (!single && !dtr)
 		io_mode = W35N01JW_VCR_IO_MODE_OCTAL_SDR;
 	else if (!single && dtr)
-		io_mode = W35N01JW_VCR_IO_MODE_OCTAL_DDR;
+		io_mode = W35N01JW_VCR_IO_MODE_OCTAL_DDR_DS;
 	else
 		return -EINVAL;
 
@@ -504,7 +504,7 @@ static const struct spinand_info winbond_spinand_table[] = {
 		     SPINAND_INFO_OP_VARIANTS(&read_cache_octal_variants,
 					      &write_cache_octal_variants,
 					      &update_cache_octal_variants),
-		     0,
+		     SPINAND_HAS_DQS,
 		     SPINAND_INFO_VENDOR_OPS(&winbond_w35_ops),
 		     SPINAND_ECCINFO(&w35n01jw_ooblayout, NULL),
 		     SPINAND_CONFIGURE_CHIP(w35n0xjw_vcr_cfg)),
@@ -515,7 +515,7 @@ static const struct spinand_info winbond_spinand_table[] = {
 		     SPINAND_INFO_OP_VARIANTS(&read_cache_octal_variants,
 					      &write_cache_octal_variants,
 					      &update_cache_octal_variants),
-		     0,
+		     SPINAND_HAS_DQS,
 		     SPINAND_INFO_VENDOR_OPS(&winbond_w35_ops),
 		     SPINAND_ECCINFO(&w35n01jw_ooblayout, NULL),
 		     SPINAND_CONFIGURE_CHIP(w35n0xjw_vcr_cfg)),
@@ -526,7 +526,7 @@ static const struct spinand_info winbond_spinand_table[] = {
 		     SPINAND_INFO_OP_VARIANTS(&read_cache_octal_variants,
 					      &write_cache_octal_variants,
 					      &update_cache_octal_variants),
-		     0,
+		     SPINAND_HAS_DQS,
 		     SPINAND_INFO_VENDOR_OPS(&winbond_w35_ops),
 		     SPINAND_ECCINFO(&w35n01jw_ooblayout, NULL),
 		     SPINAND_CONFIGURE_CHIP(w35n0xjw_vcr_cfg)),

-- 
2.51.1

[PATCH DO NOT MERGE RFC 4/4] spi: cadence-qspi: Retrieve DQS capability using the core helper

[Miquel Raynal]

This is just a suggestion for Santhosh on how to get the DQS capability
information without the DT property, to introduce in his Cadence QSPI
PHY tuning series:
https://lore.kernel.org/linux-spi/87v7gbdwdh.fsf@bootlin.com/T/#t

This patch shall not be applied as-is and is just given as an FYI.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/spi/spi-cadence-quadspi.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
index 4f799f747346..0809846a6ef0 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -3476,6 +3476,12 @@ static int cqspi_mem_op_execute_tuning(struct spi_mem *mem,
 	if (!cqspi->ddata->execute_tuning)
 		return -EOPNOTSUPP;
 
+	/*
+	 * FIXME: maybe this boolean could be queried when needed by
+	 * saving a pointer to the spi memory somewhere?
+	 */
+	cqspi->f_pdata->has_dqs = spi_mem_has_dqs(mem);
+
 	return cqspi->ddata->execute_tuning(mem, read_op, write_op);
 }
 
@@ -3517,8 +3523,6 @@ static int cqspi_of_get_flash_pdata(struct platform_device *pdev,
 		f_pdata->non_phy_clk_rate =
 			f_pdata->cqspi->ddata->get_non_phy_clk_rate(f_pdata->cqspi);
 
-	f_pdata->has_dqs = of_property_read_bool(np, "spi-has-dqs");
-
 	return 0;
 }
 

-- 
2.51.1

Re: [PATCH RFC 1/4] spi: spi-mem: Flag DQS capability

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 595 bytes --]

On Thu, Feb 05, 2026 at 08:06:58PM +0100, Miquel Raynal wrote:
> DQS is a typical SPI memory signal used to help with reading the data on
> the bus at high speeds (especially in DTR mode) by avoiding clock
> skews. The chip generates a clock signal synchronized with its data
> output fronts, also called data strobe.

Acked-by: Mark Brown <broonie@kernel.org>

This seems fine if the rest of the series is fine; if people like this
approach then it's probably sensible to merge along with the MTD patches
using it and then send me a tag with the SPI bit for me to apply the
SPI driver changes.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH RFC 1/4] spi: spi-mem: Flag DQS capability

[Miquel Raynal]

On 05/02/2026 at 19:11:45 GMT, Mark Brown <broonie@kernel.org> wrote:

> On Thu, Feb 05, 2026 at 08:06:58PM +0100, Miquel Raynal wrote:
>> DQS is a typical SPI memory signal used to help with reading the data on
>> the bus at high speeds (especially in DTR mode) by avoiding clock
>> skews. The chip generates a clock signal synchronized with its data
>> output fronts, also called data strobe.
>
> Acked-by: Mark Brown <broonie@kernel.org>
>
> This seems fine if the rest of the series is fine; if people like this
> approach then it's probably sensible to merge along with the MTD patches
> using it and then send me a tag with the SPI bit for me to apply the
> SPI driver changes.

For sure. This is a prerequisite for Santhosh's SPI tuning series, so if
we go that way, I will merge that bit and offer an immutable tag with
the spi-mem and mtd patches as you proposed.

Thanks,
Miquèl

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

[Santhosh Kumar K]

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.

Regards,
Santhosh.

> 
> Here is the original thread which lead to this series:
> https://lore.kernel.org/linux-spi/87v7gbdwdh.fsf@bootlin.com/T/#ma79fc364d7b882a48dbdf47203dde75df4bb0ec4
> 
> This series was compile tested only at this stage. As DDR tuning does
> not yet work on my board, I cannot make sure this change has a real
> impact.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> Miquel Raynal (4):
>        spi: spi-mem: Flag DQS capability
>        mtd: spi-nand: Set the DQS spi-mem capability if available
>        mtd: spi-nand: winbond: Enable the DQS pin on W35N**JW series
>        [DO NOT MERGE] spi: cadence-qspi: Retrieve DQS capability using the core helper
> 
>   drivers/mtd/nand/spi/core.c       |  4 ++++
>   drivers/mtd/nand/spi/winbond.c    |  8 ++++----
>   drivers/spi/spi-cadence-quadspi.c |  8 ++++++--
>   drivers/spi/spi-mem.c             | 32 ++++++++++++++++++++++++++++++++
>   include/linux/mtd/spinand.h       |  1 +
>   include/linux/spi/spi-mem.h       |  4 ++++
>   6 files changed, 51 insertions(+), 6 deletions(-)
> ---
> base-commit: c5884449d02575c7984000eb30d2a2971c7dfcc7
> change-id: 20260205-winbond-nand-next-phy-tuning-aabefc018032
> 
> Best regards,

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

[Miquel Raynal]

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