Re: BayTrail DW DMA: MEMCPY to custom PCI device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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..

> 
> 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

-- 
~Vinod
--
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



[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux PCI]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux