On Mon, Oct 7, 2013 at 5:58 PM, Sourav Poddar <sourav.pod...@ti.com> wrote:
> 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.
OK.. Thread ends!
--
Thanks,
Jagan.
--------
Jagannadha Sutradharudu Teki,
E: jagannadh.t...@gmail.com, P: +91-9676773388
Engineer - System Software Hacker
U-boot - SPI Custodian and Zynq APSOC
Ln: http://www.linkedin.com/in/jaganteki
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
