[U-Boot,5/5] spi: ti_qspi: Add delay for successful bulk erase.

Bulk erase is not happening properly on dra7 due to erase timing constraints,
add a delay so that erase timing constraints are properly met.

Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Tested-by: Yebio Mesfin <ymesfin@ti.com>
---
 drivers/spi/ti_qspi.c |    3 +++
 1 file changed, 3 insertions(+)

Hi Sourav,

On Wednesday 02 April 2014 04:06 PM, Sourav Poddar wrote:
> Bulk erase is not happening properly on dra7 due to erase timing constraints,
> add a delay so that erase timing constraints are properly met.
>
> Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
> Tested-by: Yebio Mesfin <ymesfin@ti.com>
> ---
>   drivers/spi/ti_qspi.c |    3 +++
>   1 file changed, 3 insertions(+)
>
> diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c
> index dfa5d0c..c5d2245 100644
> --- a/drivers/spi/ti_qspi.c
> +++ b/drivers/spi/ti_qspi.c
> @@ -314,6 +314,9 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void *dout,
>                       qslave->cmd |= QSPI_RD_SNGL;
>                       debug("rx cmd %08x dc %08x\n",
>                             qslave->cmd, qslave->dc);
> +                     #ifdef CONFIG_DRA7XX
> +                             udelay(500);
> +                     #endif

I myself not conveyed these delays on spi_xfer() (looks odd to me), we
already have AM43XX delay on code, can't it be possible to manage
through status poll?

thanks!
--
Jagan.


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

On Thursday 03 April 2014 11:30 AM, Jagan Teki wrote:
> Hi Sourav,
>
> On Wednesday 02 April 2014 04:06 PM, Sourav Poddar wrote:
>> Bulk erase is not happening properly on dra7 due to erase timing 
>> constraints,
>> add a delay so that erase timing constraints are properly met.
>>
>> Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
>> Tested-by: Yebio Mesfin <ymesfin@ti.com>
>> ---
>>   drivers/spi/ti_qspi.c |    3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c
>> index dfa5d0c..c5d2245 100644
>> --- a/drivers/spi/ti_qspi.c
>> +++ b/drivers/spi/ti_qspi.c
>> @@ -314,6 +314,9 @@ int spi_xfer(struct spi_slave *slave, unsigned 
>> int bitlen, const void *dout,
>>                       qslave->cmd |= QSPI_RD_SNGL;
>>                       debug("rx cmd %08x dc %08x\n",
>>                             qslave->cmd, qslave->dc);
>> +                     #ifdef CONFIG_DRA7XX
>> +                             udelay(500);
>> +                     #endif
>
> I myself not conveyed these delays on spi_xfer() (looks odd to me), we
> already have AM43XX delay on code, can't it be possible to manage
> through status poll?
I know, its little out of place but with status poll way,  erase is 
inconsistent, might be some board timing constraints.
Hence, I am force to add this delay for dra board.

> I tried the status poll way, but erase is inconsistent, might be some 
> board timing constraints.
> thanks!
> -- 
> Jagan.
>
>
> This email and any attachments are intended for the sole use of the 
> named recipient(s) and contain(s) confidential information that may be 
> proprietary, privileged or copyrighted under applicable law. If you 
> are not the intended recipient, do not read, copy, or forward this 
> email message or any attachments. Delete this email message and any 
> attachments immediately.
>
>

Hi Sourav,

On Thu, Apr 3, 2014 at 11:46 AM, Sourav Poddar <sourav.poddar@ti.com> wrote:
> On Thursday 03 April 2014 11:30 AM, Jagan Teki wrote:
>>
>> Hi Sourav,
>>
>> On Wednesday 02 April 2014 04:06 PM, Sourav Poddar wrote:
>>>
>>> Bulk erase is not happening properly on dra7 due to erase timing
>>> constraints,
>>> add a delay so that erase timing constraints are properly met.
>>>
>>> Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
>>> Tested-by: Yebio Mesfin <ymesfin@ti.com>
>>> ---
>>>   drivers/spi/ti_qspi.c |    3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c
>>> index dfa5d0c..c5d2245 100644
>>> --- a/drivers/spi/ti_qspi.c
>>> +++ b/drivers/spi/ti_qspi.c
>>> @@ -314,6 +314,9 @@ int spi_xfer(struct spi_slave *slave, unsigned int
>>> bitlen, const void *dout,
>>>                       qslave->cmd |= QSPI_RD_SNGL;
>>>                       debug("rx cmd %08x dc %08x\n",
>>>                             qslave->cmd, qslave->dc);
>>> +                     #ifdef CONFIG_DRA7XX
>>> +                             udelay(500);
>>> +                     #endif
>>
>>
>> I myself not conveyed these delays on spi_xfer() (looks odd to me), we
>> already have AM43XX delay on code, can't it be possible to manage
>> through status poll?
>
> I know, its little out of place but with status poll way,  erase is
> inconsistent, might be some board timing constraints.
> Hence, I am force to add this delay for dra board.
>
>> I tried the status poll way, but erase is inconsistent, might be some
>> board timing constraints.

Understand your point as board timings have some unknown constraints
for causing these
delays, but it's not good to hack qspi driver instead of some other
place(board init parts, hw fix).

I expect a delay fix patch for your previous AM43XX delay.

May be we could think over it here, it's not good to expose the driver
with delays on ML
instead of private/local tree.

Hope you understand my point.

thanks!