On Wed, Oct 9, 2013 at 12:01 PM, Peter Korsgaard <[email protected]> wrote: >>>>>> "Mark" == Mark Brown <[email protected]> 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. ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
