On 25.10.2016 18:49, Andy Shevchenko wrote:
> On Tue, 2016-10-25 at 08:43 +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,
>
>> dmatest works just fine when using it on local memory as source
>> and destination.
>
> So, DMA engine works.
>
>
>> I've also hacked dmatest to use the PCI memory as destination address.
>
> And here is the problem. How memory is addressed? DMA there works with
> memory in system address space. Moreover it a) supports only 32-bit DMA
> mask, and b) does increment addresses after each burst size. Transfer
> width and alignment is calculated automatically from addresses and
> lengths parameters (when you call prep_memcpy()). Burst sizes IIRC hard
> coded to 16 items. All those at least what you have to think of. If your
> PCI memory space requires I/O operation, it will not work I assume.
What exactly do you mean with I/O operation? In my case I want
to access the memory (DDR) behind an FPGA connected to the PCI
bus exposed via a 32bit memory BAR (see below).
> Basically you need to be sure that your memory is represented in the
> system in the same way as system memory (including virtual <-> physical
> mapping).
Thats what I currently have. The physical address is in my case:
$ 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
But perhaps the DMA controller implementation on BayTrail does not
support to access data on external (non-BayTrail) PCI devices
(data path missing?).
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
