From: sourav.poddar@ti•com (Sourav Poddar)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 0/4] mtd: spi-nor: add a new framework for SPI NOR
Date: Tue, 3 Dec 2013 19:20:37 +0530 [thread overview]
Message-ID: <529DE1AD.8030101@ti.com> (raw)
In-Reply-To: <201312031442.00141.marex@denx.de>
Dear Marek Vasut,
On Tuesday 03 December 2013 07:12 PM, Marek Vasut wrote:
> Dear Sourav Poddar,
>
>> Dear Marek Vasut,
>>
>> On Tuesday 03 December 2013 05:29 AM, Marek Vasut wrote:
>>> Dear Sourav Poddar,
>>>
>>>> Dear Marek Vasut,
>>>>
>>>> On Wednesday 27 November 2013 03:36 PM, Marek Vasut wrote:
>>>>> Dear Sourav Poddar,
>>>>>
>>>>>> Dear Marek Vasut, Huang,
>>>>>>
>>>>>> On Wednesday 27 November 2013 02:57 PM, Marek Vasut wrote:
>>>>>>> Dear Huang Shijie,
>>>>>>>
>>>>>>>> 1.) Why add a new framework for SPI NOR?
>>>>>>>>
>>>>>>>> The SPI-NOR controller such as Freescale's Quadspi controller
>>>>>>>> is working in a different way from the SPI bus. It should
>>>>>>>> knows the NOR commands to find the right LUT sequence.
>>>>>>>> Unfortunately, the current code can not meet this requirement.
>>>>>>> Is there any kind of documentation for this controller available? I
>>>>>>> cannot quite understand how this controller works and why can it not
>>>>>>> be used with our current infrastructure.
>>>>>> I do have a similar requirement where my controller need to be
>>>>>> configured from slave info. I have submiited a series in the mtd list
>>>>>> adding that portion
>>>>>> of handling such cases. Here, is the patch which specific to m25p80
>>>>>> part. http://patchwork.ozlabs.org/patch/294285/
>>>>>>
>>>>>> The whole series can be found here:
>>>>>> https://www.mail-archive.com/linux-omap at vger.kernel.org/msg98691.html
>>>>> Is this TI QSPI the same thing as the Altera QSPI controller please ?
>>>> No, its differenet.
>>>>
>>>>> Otherwise, I seriously believe you and Huang should work on a common
>>>>> infrastructure. I would first like to understand how is the controller
>>>>> in DRA7xx different from regular SPI controller though. Is there any
>>>>> kind of documentation I could study please?
>>>> Sorry, we dont have a public document yet.
>>> Sorry for the delayed reply. I am processing the input on the QSPI and
>>> I'm finally starting to understand what's going on in here.
>> Thanks for the response.
>>
>>>> Though, this is what ti qspi contoller has
>>>>
>>>> It supports two modes of operation, one is SPI mode(normal), other is
>>>> the memory mapped read mode.
>>>>
>>>> For SPI mode, the state machine remains the same as it is with other spi
>>>> controller
>>>> available.
>>>>
>>>> For memory mapped, there is something more which we need to do around ..
>>>>
>>>> 1. There is a qspi "set up" register available, which needs to be filled
>>>> with
>>>>
>>>> information like flash opcode, dummy bytes etc. In short, flash
>>>>
>>>> specific
>>>>
>>>> details.
>>>>
>>>> 2 if the above register is configured with the required opcodes, then
>>>> whenever
>>>>
>>>> we need to use memory mapped operations, we need to do is to
>>>>
>>>> switch our
>>>>
>>>> qspi controller to memory mapped mode.
>>>>
>>>> Switching of this mode to memory mapped needs
>>>>
>>>> a ) write to a particular qspi register
>>>> b) write to control module(optional based on SOC).
>>>>
>>>> 3. Once the above steps are configured, then the flash data will be
>>>> mapped to a
>>>>
>>>> particular memory address(SOC specific) from where the flash data
>>>>
>>>> can be read.
>>> OK, but is the memory mapped mode of any use (but for booting I suppose)
>>> ? How does it handle large SPI NOR flashes (we have spansion devices as
>>> big as 128MiB), does it really hog a _large_ amount of address space
>>> from the CPU address space ? Or is the operation somehow indexed ? Why
>>> is it better than using DMA?
>> Memory mapped will be of use whenever we try to read the flash content.
>> Instead of going through the entire SPI framework, and raising
>> interrupts, we can
>> memcpy the flash contents. I am using it for mounting a jffs2 filesystem.
>>
>> For me the memory mapped regions are like in the range 5c000000 -
>> 5fffffff, so
>> I can handle flash as large as 64MB.
>>
>> As far as its comparison with DMA is concerned, I cant comment much
>> about it.
>> My Qspi controller does not support DMA :(:(. So, memory mapped becomes the
>> best option option for me.
> OK, understood. So to sling large chunks of memory from SPI NOR to your DRAM,
> you need to issue these two steps in a loop:
>
> 1) write into the controller register the starting address of the SPI flash
> which you want to have available via the mmap interface
> 2) memcpy() from this mmaped area to DRAM
>
> correct? Won't the second step be pretty CPU-intensive
No, we dont need to write the starting address in any register.
1. we need to write opcodes(flash specific) in a qspi set up register.
2. Switch to mmap mode using qspi SWITCH register.
Memory mapped address need to be avilable though to m25p80_read api to
do memcpy, which is currently done by get_buf api.
We dont need to do the steps in a loop.
Point1 above is one time configurable.
point2 above need to be done whenever we want to use mmap operations.
memcpy(buf, base_addr + from, len) , where len <= min(FLASH_SIZE, MMAP
region)
next prev parent reply other threads:[~2013-12-03 13:50 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-26 6:32 [PATCH 0/4] mtd: spi-nor: add a new framework for SPI NOR Huang Shijie
2013-11-26 6:32 ` [PATCH 1/4] mtd: spi-nor: move the SPI NOR commands to a new header file Huang Shijie
2013-11-26 7:42 ` Gupta, Pekon
2013-11-26 8:53 ` Huang Shijie
2013-11-26 14:48 ` Angus Clark
2013-11-26 6:32 ` [PATCH 2/4] mtd: spi-nor: add a new data structrue spi_nor{} Huang Shijie
2013-11-26 11:42 ` Gupta, Pekon
2013-11-27 4:35 ` Huang Shijie
2013-11-27 9:32 ` Marek Vasut
2013-11-27 10:24 ` Huang Shijie
2013-11-27 10:27 ` Marek Vasut
2013-11-26 6:32 ` [PATCH 3/4] mtd: spi-nor: add the framework for SPI NOR Huang Shijie
2013-11-26 10:03 ` Gupta, Pekon
2013-11-27 9:39 ` Marek Vasut
2013-11-26 6:32 ` [PATCH 4/4] mtd: m25p80: use the new spi-nor APIs Huang Shijie
2013-11-26 12:57 ` [PATCH 0/4] mtd: spi-nor: add a new framework for SPI NOR Angus Clark
2013-11-27 4:32 ` Brian Norris
2013-11-27 4:39 ` Huang Shijie
2013-11-29 14:52 ` Angus Clark
2013-12-02 10:06 ` Huang Shijie
2013-12-02 11:01 ` Gupta, Pekon
2013-12-02 11:19 ` Angus Clark
2013-12-03 6:20 ` Huang Shijie
2013-12-03 8:23 ` Lee Jones
2013-12-10 8:25 ` Brian Norris
2013-12-10 10:00 ` Lee Jones
2013-12-03 0:32 ` Marek Vasut
2013-12-03 10:36 ` Huang Shijie
2013-12-03 14:51 ` David Woodhouse
2013-12-04 18:44 ` Brian Norris
2013-12-05 7:12 ` Huang Shijie
2013-12-05 8:11 ` Brian Norris
2013-12-05 7:59 ` Huang Shijie
2013-12-05 9:20 ` Brian Norris
2013-12-06 3:07 ` Huang Shijie
2013-12-05 14:35 ` Angus Clark
2013-12-06 8:18 ` Huang Shijie
2013-12-10 9:08 ` Brian Norris
2013-12-04 2:46 ` Huang Shijie
2013-12-04 6:58 ` Angus Clark
2013-12-04 7:19 ` Gupta, Pekon
2013-12-04 8:21 ` Angus Clark
2013-12-04 15:36 ` Marek Vasut
2013-12-05 2:42 ` Huang Shijie
2013-12-05 5:43 ` Gupta, Pekon
2013-12-05 7:33 ` Huang Shijie
2013-11-27 9:27 ` Marek Vasut
2013-11-27 9:47 ` Sourav Poddar
2013-11-27 10:06 ` Marek Vasut
2013-11-27 10:56 ` Sourav Poddar
2013-12-02 23:59 ` Marek Vasut
2013-12-03 10:01 ` Sourav Poddar
2013-12-03 13:42 ` Marek Vasut
2013-12-03 13:50 ` Sourav Poddar [this message]
2013-12-03 14:19 ` Marek Vasut
2013-12-03 14:31 ` Sourav Poddar
2013-12-03 15:09 ` Marek Vasut
2013-12-03 15:16 ` Sourav Poddar
2013-12-03 15:35 ` Marek Vasut
2013-12-03 15:23 ` David Woodhouse
2013-12-03 18:28 ` Brian Norris
2013-12-03 23:41 ` Marek Vasut
2013-11-27 10:19 ` Huang Shijie
2013-12-03 0:00 ` Marek Vasut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=529DE1AD.8030101@ti.com \
--to=sourav.poddar@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox