On Wed, 2016-10-26 at 10:42 +0200, Stefan Roese wrote: > 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: > > 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) Right, ioremap() for non-prefetchable memory. > > > 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). I'm talking about prefetch here. In your case it means that two consequent reads from the same address may return different results. Of course you can do DMA on it, but data might be inconsistent. > > > 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). Yes. > But again, the main culprit might be, that the DMA controllers > on BayTrail just have no data patch to access such external PCI > devices. That's possible. I'm not so familiar with actual interconnect in BayTrail, but what I know that it's sitting on AHB bus which is bridged to internal fabric (IOSF). All request lines of both DMA controllers are wired to internal (LPSS) devices. -- 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
