On Wed, 2016-10-26 at 07:15 +0200, Stefan Roese wrote: > On 25.10.2016 18:49, Andy Shevchenko wrote: > > On Tue, 2016-10-25 at 08:43 +0200, Stefan Roese wrote: > $ lspci > ... > 05:00.0 Unassigned class [ff00]: Altera Corporation Device e001 (rev > 10) > Physical Slot: 3 > Flags: bus master, fast devsel, latency 0, IRQ 95 > Memory at 81600000 (32-bit, non-prefetchable) [size=128K] > Memory at 90000000 (32-bit, non-prefetchable) [size=256M] > > And accessing works in the same way (mapping based) as system > memory (every transfer width supported): > > $ sudo ./memtool md 0x00000000+0x20 > 00000000: 00001000 00001009 00001012 > 0000101b ................ > 00000010: 00001024 0000102d 00001036 0000103f $...- > ...6...?... > $ sudo ./memtool md 0x90000000+0x20 > 90000000: 55555555 55555555 55555555 > 55555555 UUUUUUUUUUUUUUUU > 90000010: 55555555 55555555 55555555 > 55555555 UUUUUUUUUUUUUUUU Here you access bus address directly. Are you sure that it's the same (what dma_map_page() returns) when you run dmatest for example? How your RAM is represented in *virtual* address space? Your memory marked is non-prefetchable, meaning it's MMIO space, OS has to perform IO on it (that's what I was talking about above). System DMA apparently can't operate with such resource. > But perhaps the DMA controller implementation on BayTrail does not > support to access data on external (non-BayTrail) PCI devices > (data path missing?). That's correct. It can't perform IO to the devices which are external. But we are talking about memory-to-memory accesses, right? -- Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
