On Fri, Nov 10, 2017 at 10:29:38AM -0800, Tony Lindgren wrote: > I just made sure things keep working with Peter's changes, no additional > patches. So the dma is barely used at all. It seemed suspicious to me looking here: https://github.com/omap-audio/linux-audio/commit/52e914395afe31a7401b35814b6dabf3ef46a052#diff-1662a4cc544d322b68c547cfdc99448cR312 as wait_for_completion_timeout is returning time remaining and zero on timeout :-) Fixed in next version and also changed to wait_for_completion_io_timeout to get proper sched stats. Btw, I think we should stop DMA on timeout as we are unmapping DMA region later and it might not behave nicely if we do so while DMA is eventually running (that's fixed too). I made Peter's patches part of next version and enabled DMA unconditionally. It works nicely on: OF: fdt: Machine model: IGEPv2 Rev. C (TI OMAP AM/DM37x) OMAP3630/DM3730 ES1.2 (l2cache iva sgx neon isp 192mhz_clk) ... omap-gpmc 6e000000.gpmc: GPMC revision 5.0 gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000 omap2-onenand 30000000.onenand: initializing on CS0 (0x30000000), va e0080000, DMA mode Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58) OneNAND version = 0x0031 Scanning device for bad blocks OneNAND eraseblock 597 is an initial bad block OneNAND eraseblock 1159 is an initial bad block OneNAND eraseblock 2812 is an initial bad block omap2-onenand 30000000.onenand: optimized timings for 83 MHz 2 ofpart partitions found on MTD device 30000000.onenand Creating 2 MTD partitions on "30000000.onenand": 0x000000000000-0x000000080000 : "SPL" 0x000000080000-0x000020000000 : "UBI" ... Based on this experiment, I'll delay v4 a bit and leave DMA enabled by default. We are brave enough and want some testing, right? It would be nice if someone could provide some benchmarks using PIO and DMA mode. I do not expect any dramatic change, but kernel latencies should decrease when doing flash I/O. Based on above I also think R/B pin should be in ordinary GPIO mode. Perhaps using external DMA request is somehow posible, but it is not clear to me how after yet another reading of SDMA, GPMC and OneNAND documentation, so I'll happily leave it for others. Btw, using R/B pin would elimitate latencies caused by busy looping while waiting for onenand command to complete. Nice todo for someone with a lot of spare time :-) Best regards, ladis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
