On Monday 07 October 2013 05:51 PM, Jagan Teki wrote:
On Wed, Aug 7, 2013 at 8:46 PM, Sourav Poddar<sourav.pod...@ti.com> wrote:
On Wednesday 07 August 2013 08:35 PM, Jagan Teki wrote:
On Wed, Aug 7, 2013 at 5:34 PM, Sourav Poddar<sourav.pod...@ti.com>
wrote:
Hi Jagan,
On Wednesday 07 August 2013 05:21 PM, Jagan Teki wrote:
Hi,
On Wed, Aug 7, 2013 at 11:27 AM, Sourav Poddar<sourav.pod...@ti.com>
wrote:
Hi Jagan,
On Wednesday 31 July 2013 12:23 PM, Sourav Poddar wrote:
Hi Jagan,
On Tuesday 23 July 2013 07:53 PM, Sourav Poddar wrote:
+ jagan,
On Tuesday 23 July 2013 02:29 PM, Sourav Poddar wrote:
Reading using the already supported read command is causing
regression
after 4k bytes, as a result doing a page by page read. Its
happening,
because
ti qpsi controller CS will get de asserted after 4096 bytes.
Signed-off-by: Sourav Poddar<sourav.pod...@ti.com>
---
drivers/mtd/spi/spi_flash.c | 32
+++++++++++++++++++++++++++++++-
1 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash.c
b/drivers/mtd/spi/spi_flash.c
index 6a6fe37..5f8db7b 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -303,6 +303,36 @@ int spi_flash_cmd_read_fast(struct spi_flash
*flash, u32 offset,
else
read_len = remain_len;
+#ifdef CONFIG_TI_QSPI
+ unsigned long page_addr, byte_addr, page_size;
+ size_t chunk_len, actual;
+ int ret = 0;
+
+ page_size = flash->page_size;
+ page_addr = offset / page_size;
+ byte_addr = offset % page_size;
+
+ for (actual = 0; actual< read_len; actual += chunk_len)
{
+ chunk_len = min(read_len - actual, page_size -
byte_addr);
+
+ cmd[1] = page_addr>> 8;
+ cmd[2] = page_addr;
+ cmd[3] = byte_addr;
+
+ ret = spi_flash_read_common(flash, cmd, sizeof(cmd),
+ data + actual, chunk_len);
+ if (ret< 0) {
+ debug("SF: read failed");
+ break;
+ }
+
+ byte_addr += chunk_len;
+ if (byte_addr == page_size) {
+ page_addr++;
+ byte_addr = 0;
+ }
+ }
+#else
spi_flash_addr(offset, cmd);
ret = spi_flash_read_common(flash, cmd, sizeof(cmd),
@@ -311,7 +341,7 @@ int spi_flash_cmd_read_fast(struct spi_flash
*flash,
u32 offset,
debug("SF: read failed\n");
break;
}
-
+#endif
offset += read_len;
len -= read_len;
data += read_len;
Elaborating a bit more on this,
There is a constrain on our hardware, which goes like this..
As soon as the words transfered is 4096 bytes, the CS gets deasserted
automatically.
As a result of this bottleneck, I am not able to use the current use
read
api in mtd framework.
This requires me to send the read command every time in range upto
4096
bytes only.
To overcome this, I have updated the mtd read based on TI_QSPI config
as
done above.
[Jagan]:
Do you have any suggestion of dealing this in a better way?
I don't see a way to get around this apart from updating mtd read
depending on TI_QSPI config.
Any inputs on this?
Any suggestions on the patch?
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Yes, this part is pretty much working as with other s25fl.
Can you point me the respective controller driver for this.
Thanks for the response.
This is the link to uboot patches which I submitted to uboot mailing
list.
http://patchwork.ozlabs.org/patch/260989/
http://patchwork.ozlabs.org/patch/260990/
http://patchwork.ozlabs.org/patch/260991/
http://patchwork.ozlabs.org/patch/260992/
http://patchwork.ozlabs.org/patch/260994/
http://patchwork.ozlabs.org/patch/260993/
http://patchwork.ozlabs.org/patch/260996/
http://patchwork.ozlabs.org/patch/260995/
Above are the links to uboot patches containing all def configs and uboot
ti
qspi driver.
As communicated earlier, there is a limitation in our qspi controller
driver, wherein after every
4096 bytes CS gets de asserted. So, I had to modify the above read
framework
to do a page read.
Need better way to handle this limitation, so that the above patch series
can get upstreamed.
Does linux support this ti_qspi, please point the defconfig if you have.
Patches for linux is under review and still not mainlined.
https://patchwork.kernel.org/patch/2838342/
Thanks, please give me some time I will look at these and let u know
early next week.
Thanks!!
You still see this issue.
Please ignore this mail thread. This was due to some ip limitation.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
