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_DRA7XXudelay(500);#endifI 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!