[U-Boot] [PATCHv2 5/8] drivers: mtd: spi: Modify read/write command for sfl256s flash.
Sourav Poddar
sourav.poddar at ti.com
Mon Oct 7 14:30:54 CEST 2013
On Monday 07 October 2013 05:59 PM, Jagan Teki wrote:
> On Mon, Oct 7, 2013 at 5:58 PM, Sourav Poddar<sourav.poddar at 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.poddar at 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.poddar at 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 at 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 at 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!!
>>> You still see this issue.
>>>
>> Please ignore this mail thread. This was due to some ip limitation.
> OK.. Thread ends!
>
Anyways, we have move much ahead and there is already a v6 which I posted :)
More information about the U-Boot
mailing list