[PATCH 0/4] mtd: spi-nor: add a new framework for SPI NOR

[marex@denx.de (Marek Vasut)]

Dear Sourav Poddar,

> 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.htm
> >>>>>> l
> >>>>> 
> >>>>> 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.

OK, but how does this handle for example Spansion S70FL01GS , which is 1 GBit 
SPI NOR (128MB) if your memory map window is only 64MB?
 
> 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.

OK, got it.
 
> 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.

OK, but copying the SPI NOR will be pretty CPU intensive, correct? You'd need to 
do memcpy() on a full 64MB of stuff on the CPU. I mean, that's what we had DMA 
for thus far, so the CPU can do more useful things.

> memcpy(buf, base_addr + from, len) , where   len <= min(FLASH_SIZE, MMAP
> region)