I am wondering how the kernel behaves in some extreme (but not completely uncommon) cases, such as running "cat bigfile.txt' in a console. With one DMA request following another, I wonder whether the kernel is smart enough to schedule enough CPU time to other processes needing the CPU in this case.dom wrote:The dma controller has a WAITS field, which can be used to reduce the memory bandwidth (by taking longer), if this were a problem (but I doubt it will be - the DMA is quick and will not saturate the memory bus for long).ssvb wrote: That's a good point, but I don't think it directly applies here. The CPU imageblit implementation is unsurprisingly fully occupying the CPU while it is doing its stuff, so the concurrently running programs are totally out of luck and are just waiting to be scheduled. Even if less memory bandwidth is used, it is still going to be wasted. And with IRQ enabled DMA, the concurrently running applications at least are going to still have a chance to do something useful at the same time.
A related question is the behaviour of bcm_dma_wait_idle(channel), which is used to wait for completion. Looking at the source code (arch/arm/mach-bcm2708/dma.c), this does "ugly busy wait"; does that mean the kernel cannot service any other requests during this time? What happens to processes needing "near real-time" scheduling precision during a big framebuffer DMA request? Scrolling the whole framebuffer at 1920x1080x32bpp takes about 15 MB/300 MB/s = 0.05 seconds, which could cause issues with other real-time processes. Of course, an IRQ-based DMA waiting would solve this.