>>>>> "Mark" == Mark Brown <[email protected]> writes:
Hi, 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. But if there's number to prove otherwise.. -- Bye, Peter Korsgaard ------------------------------------------------------------------------------ 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
