[U-Boot] [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).
Signed-off-by: Vignesh R vigneshr@ti.com --- drivers/spi/ti_qspi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c index 9a372ad31dae..376fe378ed63 100644 --- a/drivers/spi/ti_qspi.c +++ b/drivers/spi/ti_qspi.c @@ -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) {
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.
Signed-off-by: Vignesh R vigneshr@ti.com --- drivers/spi/ti_qspi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c index 376fe378ed63..9da80355a417 100644 --- a/drivers/spi/ti_qspi.c +++ b/drivers/spi/ti_qspi.c @@ -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);
On 11 July 2016 at 11:00, Vignesh R vigneshr@ti.com wrote:
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).
Signed-off-by: Vignesh R vigneshr@ti.com
drivers/spi/ti_qspi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c index 9a372ad31dae..376fe378ed63 100644 --- a/drivers/spi/ti_qspi.c +++ b/drivers/spi/ti_qspi.c @@ -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.
#ifdef CONFIG_DRA7XX udelay(500); #endif
Can't we fix this delay, still need?
thanks!
On 7/11/2016 12:05 PM, Jagan Teki wrote:
On 11 July 2016 at 11:00, Vignesh R vigneshr@ti.com wrote:
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).
Signed-off-by: Vignesh R vigneshr@ti.com
drivers/spi/ti_qspi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c index 9a372ad31dae..376fe378ed63 100644 --- a/drivers/spi/ti_qspi.c +++ b/drivers/spi/ti_qspi.c @@ -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.
#ifdef CONFIG_DRA7XX udelay(500); #endifCan'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
participants (3)
-
Jagan Teki -
R, Vignesh -
Vignesh R