[RFC PATCH v2 08/12] spi: cadence-quadspi: read 'has-dqs' DT property

Santhosh Kumar K posted 12 patches 3 weeks, 5 days ago
[RFC PATCH v2 08/12] spi: cadence-quadspi: read 'has-dqs' DT property
Posted by Santhosh Kumar K 3 weeks, 5 days ago
Add a boolean field to struct cqspi_flash_pdata to store whether the
attached flash device supports DQS (Data Strobe) mode. Read this from
the 'spi-has-dqs' device tree property during flash node parsing.

This is preparatory infrastructure for PHY tuning support. The field
will be used by subsequent patches to configure read data capture timing
with DQS enabled for improved margins in high-speed operations.

Signed-off-by: Santhosh Kumar K <s-k6@ti.com>
---
 drivers/spi/spi-cadence-quadspi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
index 1d708dde4463..0df286d24256 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -70,6 +70,7 @@ struct cqspi_flash_pdata {
 	u32		tsd2d_ns;
 	u32		tchsh_ns;
 	u32		tslch_ns;
+	bool		has_dqs;
 	u8		cs;
 };
 
@@ -1583,6 +1584,8 @@ static int cqspi_of_get_flash_pdata(struct platform_device *pdev,
 		return -ENXIO;
 	}
 
+	f_pdata->has_dqs = of_property_read_bool(np, "spi-has-dqs");
+
 	return 0;
 }
 
-- 
2.34.1
Re: [RFC PATCH v2 08/12] spi: cadence-quadspi: read 'has-dqs' DT property
Posted by Miquel Raynal 3 days, 17 hours ago
On 13/01/2026 at 19:46:13 +0530, Santhosh Kumar K <s-k6@ti.com> wrote:

> Add a boolean field to struct cqspi_flash_pdata to store whether the
> attached flash device supports DQS (Data Strobe) mode. Read this from
> the 'spi-has-dqs' device tree property during flash node parsing.
>
> This is preparatory infrastructure for PHY tuning support. The field
> will be used by subsequent patches to configure read data capture timing
> with DQS enabled for improved margins in high-speed operations.
>
> Signed-off-by: Santhosh Kumar K <s-k6@ti.com>

As mentioned in my answer to the cover letter, I am not too much in
favour of this property because this is something that is somewhat
related to the chip ID, thus discoverable. I drafted something to get
rid of this property already, I will share it for opening the
discussion.

However, for now I am closing my eyes on the fact that the DQS pin might
not be wired to the controller. In this case we will need some kind of
"dqs-not-wired" DT property, that's true, but also easily manageable at
the core level later, when/if the need arises.

Thanks,
Miquèl