Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 11/11/2017 02:50 PM, Ladislav Michl wrote: > 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 :-) aargh, yes, you are right... > 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: Pretty cool! Thanks for doing it! > 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 > -- Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki -- 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
