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

[Marek Vasut]

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@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?