[PATCH 0/4] mtd: spi-nor: add a new framework for SPI NOR
Marek Vasut
marex at denx.de
Tue Dec 3 10:35:29 EST 2013
Dear Sourav Poddar,
> Dear Marek Vasut,
>
> On Tuesday 03 December 2013 08:39 PM, Marek Vasut wrote:
> > Dear Sourav Poddar,
> >
> >> Dear Marek Vasut,
> >>
> >> On Tuesday 03 December 2013 07:49 PM, Marek Vasut wrote:
> >>> 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@vger.kernel.org/msg98691
> >>>>>>>>>> .h tm 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?
> >>
> >> So, the code added in m25p80 does not care about the flash size. It
> >> works for me
> >> for 64MB flash spansion (S25fl256s) and Macronix( mx66l51235l, 128 MB)
> >> flash.
> >> That memory mapped region info will from device tree. You can see
> >> patch16/17) of my
> >> series.
> >> so in m25p80_read,
> >>
> >> memcpy(buf, base + from, len)
> >>
> >> where,
> >> base= memmaped base region
> >>
> >> ex: ioremap(0x5c000000)
> >>
> >> len = can be anything, (64mb, 128 mb etc..). Just we need to
> >> make sure that we have ioremapped the required region through dt.
> >>
> >> For me, SOC takes care of the memory mapped region required.
> >>
> >> DRA7xx board with 64mb spansion flash has mmap region (5c000000 -
> >> 5fffffff) AM43x board with 128mb macronix flash has mmap region
> >> (30000000 - 33fffffff)
> >
> > You mean 0x3000_0000 - 0x33ff_ffff (with one less 'f'), or am I wrong?
> > But 0x0400_0000 is only 64MiB, how can this map 128MiB SPI NOR? I am
> > still not connecting with you here, I am sorry.
>
> Sorry on my side for confusing you. I got confused with macronix
> flash sheet. Actually, here also the flash is 64MB, for which my SOC has
> the required memory map address space reserved.
>
> > Does the QSPI controller simply chomp away N MiB of CPU address space?
> > How big is the maximum N here ? I was under the impression that N=64 ,
> > but now I am a bit confused by your claim that you can use 128 MiB SPI
> > NOR.
>
> Yes, and for my SOC(DRA7x and am43x), its 64MB.
OK, I think I now clearly understand the requirement for your controller. Thank
you!
More information about the linux-mtd
mailing list