[U-Boot] [PATCH 1/2] spi: ti_qspi: Fix failure on multiple READ_ID cmd

[U-Boot] [PATCH 1/2] spi: ti_qspi: Fix failure on multiple READ_ID cmd

[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).

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) {
-- 
2.9.0

[U-Boot] [PATCH 2/2] spi: ti_qspi: Fix compiler warning when DEBUG macro is set

[Vignesh R]

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);
-- 
2.9.0

[U-Boot] [PATCH 1/2] spi: ti_qspi: Fix failure on multiple READ_ID cmd

[Jagan Teki]

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!
-- 
Jagan.

[U-Boot] [PATCH 1/2] spi: ti_qspi: Fix failure on multiple READ_ID cmd

[R, Vignesh]

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);
>>                         #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