Hi Andy, On 24.10.2016 16:12, Andy Shevchenko wrote: > On Mon, 2016-10-24 at 15:43 +0200, Stefan Roese wrote: >> Hi Andy, > >> The DMA controller is powered and generates an interrupt: >> >> [ 30.308167] dw_dmac_pci 0000:00:1e.0: dw_dma_interrupt: status=0x1 >> [ 30.308179] dw_dmac_pci 0000:00:1e.0: dw_dma_tasklet: status_err=0 >> >> Still no data transferred to the PCI memory space (FPGA). The >> parameters passed to dwc_prep_dma_memcpy() seem to okay at first >> glance. I'll debug a bit to see, if I find a problem here. >> >> One related question: >> Do you know if and how the memory-to-memory transfer has been tested >> lately on such x86 platforms? > > I used some ugly hack to power on the device (i.e. pm_runtime_get_sync() > when allocating channel and pm_runtime_put() at freeing) and run dmatest > on it. > > You may try it yourself (for PCI it would probably do not need any > hacks) and report any bugs you notice. dmatest works just fine when using it on local memory as source and destination. I've also hacked dmatest to use the PCI memory as destination address. The test shows that with "noverify=1" no data is written at all to this PCI memory. And w/o this parameter, only the data that is written "manually" in dmatest_init_dsts() shows up in the PCI memory space and dmatest reports the verify errors. So dmatest shows the same results as my testing device driver using the DW DMA driver to write data into this PCI memory space. Nothing seems to be written to this PCI memory space at all. May I ask if you are really sure that the DMA controller on Bay Trail is able to access data located on the PCI devices other than the internal BayTrail PCI devices (like I2C, SPI, HSUART)? Is there some documentation about the DW DMA controller on BayTrail and its relationship (hardwired request lines inside the SoC ?) other that the "Intel Atom Processor E3800 Product Family Datasheet"? 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
