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

R, Vignesh
2016-07-11T16:39:45Z

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