[U-Boot] [PATCHv2 5/8] drivers: mtd: spi: Modify read/write command for sfl256s flash.

[Sourav Poddar <sourav.poddar@ti.com>]

On Wednesday 07 August 2013 08:35 PM, Jagan Teki wrote:
> On Wed, Aug 7, 2013 at 5:34 PM, Sourav Poddar<sourav.poddar@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.poddar@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.poddar@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 at 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!!
> --
> Thanks,
> Jagan.