Hi Vinod, On 25.10.2016 18:02, Vinod Koul wrote: > On Tue, Oct 25, 2016 at 08:43:43AM +0200, Stefan Roese wrote: >> 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)? > > Which DMA controller are you using. I am aware of two, once in audio cluster > which can only access audio fifos and other on lpss cluster which can access > only lpss devices. Here the current PCI setup: $ lspci ... 00:18.0 DMA controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series LPIO2 DMA Controller (rev 11) 00:18.1 Serial bus controller [0c80]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series LPIO2 I2C Controller #1 (rev 11) 00:18.2 Serial bus controller [0c80]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series LPIO2 I2C Controller #2 (rev 11) 00:18.3 Serial bus controller [0c80]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series LPIO2 I2C Controller #3 (rev 11) 00:18.4 Serial bus controller [0c80]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series LPIO2 I2C Controller #4 (rev 11) 00:18.5 Serial bus controller [0c80]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series LPIO2 I2C Controller #5 (rev 11) 00:18.6 Serial bus controller [0c80]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series LPIO2 I2C Controller #6 (rev 11) 00:18.7 Serial bus controller [0c80]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series LPIO2 I2C Controller #7 (rev 11) 00:1c.0 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express Root Port 1 (rev 11) 00:1d.0 USB controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series USB EHCI (rev 11) 00:1e.0 DMA controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series LPIO1 DMA Controller (rev 11) 00:1e.1 Serial bus controller [0c80]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series LPIO1 PWM Controller (rev 11) 00:1e.2 Serial bus controller [0c80]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series LPIO1 PWM Controller (rev 11) 00:1e.3 Communication controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series LPIO1 HSUART Controller #1 (rev 11) 00:1e.4 Communication controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series LPIO1 HSUART Controller #2 (rev 11) 00:1e.5 Serial bus controller [0c80]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series LPIO1 SPI Controller (rev 11) ... I'm trying to use one of the 2 DMA controllers above (00:18.0 or 00.1e.0). > These controllers can access system memory as dmatest worked fine in your > test. As Andy replied, the peripheral request lines are hard wired to specific > peripherals so if you do not have request lines hooked up, DMA will not > work.. I do not have request line hooked up so this means that a memory BAR of an external PCI device can not be accessed via these DW DMA controllers. This is very unfortunate but can't be helped. We need to think a a different solution to provide a DMA controller in this system in this case. Perhaps we'll integrate one in the FPGA itself. 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
