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

Jagan Teki jagannadh.teki at gmail.com
Thu Apr 3 08:42:37 CEST 2014


Hi Sourav,

On Thu, Apr 3, 2014 at 11:46 AM, Sourav Poddar <sourav.poddar at 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 at ti.com>
>>> Tested-by: Yebio Mesfin <ymesfin at 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!
-- 
Jagan.


More information about the U-Boot mailing list