Skip to contentSkip to conversation

spi: ti_qspi: Fix failure on multiple READ_ID cmd

PATCH Superseded Vignesh R 3 participants 4 messages Jul 11, 2016 SPI

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore

Vignesh R

author
#0 lore raw

PATCH 1/2 spi: ti_qspi: Fix failure on multiple READ_ID cmd

Populating QSPI_RD_SNGL bit(0x1) in priv->cmd means that value QSPI_INVAL (0x4) is not written to CMD field of QSPI_SPI_CMD_REG in ti_qspi_cs_deactivate(). Therefore CS is never deactivated between successive READ ID which results in sf probe to fail.
Fix this by not populating priv->cmd with QSPI_RD_SNGL and OR it wih priv->cmd as required (similar to the convention followed in the driver).

---
 drivers/spi/ti_qspi.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/spi/ti_qspi.c +1 -2
index 9a372ad31dae..376fe378ed63 100644
@@ -247,13 +247,12 @@ static int __ti_qspi_xfer(struct ti_qspi_priv *priv, unsigned int bitlen,
 			debug("tx done, status %08x\n", status);
 		}
 		if (rxp) {
-			priv->cmd |= QSPI_RD_SNGL;
 			debug("rx cmd %08x dc %08x\n",
 			      priv->cmd, priv->dc);
 			#ifdef CONFIG_DRA7XX
 				udelay(500);
 			#endif
-			writel(priv->cmd, &priv->base->cmd);
+			writel(priv->cmd | QSPI_RD_SNGL, &priv->base->cmd);
 			status = readl(&priv->base->status);
 			timeout = QSPI_TIMEOUT;
 			while ((status & QSPI_WC_BUSY) != QSPI_XFER_DONE) {
Signature · 1 line
2.9.0
author
#1 lore raw

PATCH 2/2 spi: ti_qspi: Fix compiler warning when DEBUG macro is set

clk_div is uninitialized at the beginning of ti_spi_set_speed(), move debug() print after clk_div calculation to avoid compiler warning and to have proper value of clk_div printed during debugging.

---
 drivers/spi/ti_qspi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/spi/ti_qspi.c +2 -2
index 376fe378ed63..9da80355a417 100644
@@ -110,13 +110,13 @@ static void ti_spi_set_speed(struct ti_qspi_priv *priv, uint hz)
 {
 	uint clk_div;
 
-	debug("ti_spi_set_speed: hz: %d, clock divider %d\n", hz, clk_div);
-
 	if (!hz)
 		clk_div = 0;
 	else
 		clk_div = (QSPI_FCLK / hz) - 1;
 
+	debug("ti_spi_set_speed: hz: %d, clock divider %d\n", hz, clk_div);
+
 	/* disable SCLK */
 	writel(readl(&priv->base->clk_ctrl) & ~QSPI_CLK_EN,
 	       &priv->base->clk_ctrl);
Signature · 1 line
2.9.0
#2 lore raw

PATCH 1/2 spi: ti_qspi: Fix failure on multiple READ_ID cmd

In reply to Vignesh R
Quoted 18 lines · Vignesh R

Populating QSPI_RD_SNGL bit(0x1) in priv->cmd means that value QSPI_INVAL (0x4) is not written to CMD field of QSPI_SPI_CMD_REG in ti_qspi_cs_deactivate(). Therefore CS is never deactivated between successive READ ID which results in sf probe to fail.
Fix this by not populating priv->cmd with QSPI_RD_SNGL and OR it wih priv->cmd as required (similar to the convention followed in the driver).

---
 drivers/spi/ti_qspi.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/spi/ti_qspi.c +0 -0
index 9a372ad31dae..376fe378ed63 100644

drivers/spi/ti_qspi.c static int __ti_qspi_xfer(struct ti_qspi_priv *priv, unsigned int bitlen, · line 251

Quoted 6 lines
drivers/spi/ti_qspi.c +0 -1
@@ -247,13 +247,12 @@ static int __ti_qspi_xfer(struct ti_qspi_priv *priv, unsigned int bitlen,
                        debug("tx done, status %08x\n", status);
                }
                if (rxp) {
-                       priv->cmd |= QSPI_RD_SNGL;
                        debug("rx cmd %08x dc %08x\n",
                              priv->cmd, priv->dc);

| QSPI_RD_SNGL on debug statement as well.

drivers/spi/ti_qspi.c static int __ti_qspi_xfer(struct ti_qspi_priv *priv, unsigned int bitlen, · line 254

Quoted 3 lines
drivers/spi/ti_qspi.c +0 -0
                        #ifdef CONFIG_DRA7XX
                                udelay(500);
                        #endif

Can't we fix this delay, still need?

thanks!

Signature · 1 line
Jagan.
#3 lore raw

PATCH 1/2 spi: ti_qspi: Fix failure on multiple READ_ID cmd

Quoted 14 lines · Jagan Teki
Quoted 13 lines · Vignesh R

Populating QSPI_RD_SNGL bit(0x1) in priv->cmd means that value QSPI_INVAL (0x4) is not written to CMD field of QSPI_SPI_CMD_REG in ti_qspi_cs_deactivate(). Therefore CS is never deactivated between successive READ ID which results in sf probe to fail.
Fix this by not populating priv->cmd with QSPI_RD_SNGL and OR it wih priv->cmd as required (similar to the convention followed in the driver).

---
 drivers/spi/ti_qspi.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
Quoted 13 lines

drivers/spi/ti_qspi.c static int __ti_qspi_xfer(struct ti_qspi_priv *priv, unsigned int bitlen, · line 251

Quoted 11 lines
drivers/spi/ti_qspi.c +0 -1
index 9a372ad31dae..376fe378ed63 100644
@@ -247,13 +247,12 @@ static int __ti_qspi_xfer(struct ti_qspi_priv *priv, unsigned int bitlen,
                        debug("tx done, status %08x\n", status);
                }
                if (rxp) {
-                       priv->cmd |= QSPI_RD_SNGL;
                        debug("rx cmd %08x dc %08x\n",
                              priv->cmd, priv->dc);

| QSPI_RD_SNGL on debug statement as well.

Thanks, will fix this in v2.

Quoted 6 lines

drivers/spi/ti_qspi.c static int __ti_qspi_xfer(struct ti_qspi_priv *priv, unsigned int bitlen, · line 254

Quoted 4 lines
drivers/spi/ti_qspi.c +0 -0
                        #ifdef CONFIG_DRA7XX
                                udelay(500);
                        #endif

Can't we fix this delay, still need?

The patch that added this delay ( b545a98f5dc563 spi: ti_qspi: Add delay for successful bulk erase) says its added to meet bulk erase timing constraints (AFAIK, I believe bulk erase is same as chip erase which is not supported by sf erase but may be supported in future). I will experiment a bit and convince myself whether this delay is really applicable or not.

Regards
Vignesh