Hi All,
On Thursday 10 October 2013 07:57 AM, Trent Piepho wrote:
> On Wed, Oct 9, 2013 at 12:01 PM, Peter Korsgaard<pe...@korsgaard.com> wrote:
>>>>>>> "Mark" == Mark Brown<broo...@kernel.org> writes:
>> Mark> I'm not convinced that this is the most useful API, it sounds like
>> the
>> Mark> hardware can "memory map" the entire flash chip so the whole SPI
>> Mark> framework seems like overhead.
>>
>> Mark> It also seems seems like it's going to involve the CPU being
>> Mark> stalled waiting for reads to complete instead of asking the SPI
>> Mark> controller to DMA the data to RAM and allowing the CPU to get on
>> Mark> with other things - replacing the explicit transmission of
>> Mark> commands with memory to memory DMAs might be advantageous but
>> Mark> replacing DMA with memcpy() would need numbers to show that it
>> Mark> was a win.
>>
>> Indeed. I can see how such a feature could be useful in E.G. a lowlevel
>> bootloader (because of simplicity), but am less convinced about it in
>> Linux where we could conceivable do something else useful while waiting
>> on the spi controller.
> I've found that the SPI layer adds rather a lot of overhead to SPI
> transactions. It appears to come mostly from using another thread to
> run the queue. A fast SPI message of a few dozen bytes ends up having
> more overhead from the SPI layer than the time it takes the driver to
> do the actual transfer.
>
> So memory mapped mode via some kind of SPI hack seems like a bad
> design. All the SPI layer overhead and you don't get DMA. Memory
> mapped SPI could be a win, but I think you'd need to do it at the MTD
> layer with a mapping driver that could read the mmapped SPI flash
> directly.
Yes, you are correct in all your comments above. I also feel that SPI
framework
should be bypassed. But the subject patch is derived based on the
following points/limitation:
1. There is a setup register in QSPI, that need to be filled, as of now
I am filling it
in my driver as a MACRO.
2. Controller repsonds to memory mapped read for read opcodes, so during the
read path we should tell the controller to switch to memory mapped port.
[Trent]: With mapping driver, I believe you are hinting at
drivers/mtd/maps? I had
a look at it and what I got is that it is used/suitable for parallel
flashes and not the
serial flashes.
All in all, Just at the beginning of the read api, I could have done
memory mapped read and bypass
the spi framework. But, prior to that above 1, 2 point need to be
executed and that need to be
communicated to controller driver.
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
