On 26.10.2016 09:58, Andy Shevchenko wrote: > 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? Yes, absolutely. This tool uses /dev/mem to access this memory. And please also note, that dmatest with my hack to enable access to this PCI device memory works just fine on a different system (ARM platform with same PCI layout / bridges, same FPGA with the same PCI core). > How your RAM is represented in *virtual* address space? You need to ioremap this PCI memory exactly in the same way as you ioremap system memory to access it from kernel space. My current driver reports something like this: 0000:05:00.0: bar0=ffffc900007c0000 (phys=88000000 size=00020000) 0000:05:00.0: bar2=ffffc90060000000 (phys=90000000 size=10000000) > 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. I can use all normal accessors on this "memory", like readl(), memcpy() etc. On the virtually mapped addresses of course. For the DMA addresses I need to use the physical addresses. And as mentioned above, this works without problems on a ARM based system also using DMA (Marvell Armada XP). >> 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? We seem to have a different understanding of "memory-to-memory". For you this only refers to system memory, right? For me, this also includes memories such as this FPGA DDR located on the PCI bus (accessible in the same way as system memory as mentioned above). But again, the main culprit might be, that the DMA controllers on BayTrail just have no data patch to access such external PCI devices. Thanks, Stefan -- 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
