Re: [U-Boot] [UBOOT][PATCH 5/5] spi: ti_qspi: Add delay for successful bulk erase.
Hi Sourav,
On Thu, Apr 3, 2014 at 11:46 AM, Sourav Poddar 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
>>> Tested-by: Yebio Mesfin
>>> ---
>>> 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.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [UBOOT][PATCH 5/5] spi: ti_qspi: Add delay for successful bulk erase.
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
Tested-by: Yebio Mesfin
---
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.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [UBOOT][PATCH 5/5] spi: ti_qspi: Add delay for successful bulk erase.
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
Tested-by: Yebio Mesfin
---
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.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [UBOOT][PATCH 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
Tested-by: Yebio Mesfin
---
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
writel(qslave->cmd, &qslave->base->cmd);
status = readl(&qslave->base->status);
timeout = QSPI_TIMEOUT;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
