We are using the AD9144 with a Microblaze core (based on hdl_2016R1) and Linux on a KCU105 and noticed several odd things.
1. ) We have derived the configuration from the provided FMCDAQ2 reference design. In the 2016R1 release the cyclic property for the the DMAC controller disabled in the HDL but enabled in the device tree. Using an IIO buffer with the cyclic property set, does not lead to a cyclic behaviour. Disabling the cyclic property in the device tree does not lead to a software-emulated cyclic behaviour either. Is cyclic DMA behaviour in any configuration possible?
2.) The util_dacfifo seems to have no way to detect under- or even worse overflows, which means it can practically never be used for continous streaming (we use interpolation and therefore DMA memory bandwidth would be sufficient).
3.) Increasing the DAC FIFO and let the device iterate on the data in the FIFO (which is in fact more like a ringbuffer) is made difficult, as we haven't found a way to trigger a DMA transfer which sets the dma_xfer_last flag. This would be necessary to set lastaddr and reset the write addr. So for now the only way seems to be a padding of the data to the full dacfifo buffer size.
4.) And finally the clock domain crossing of the lastaddr signal from DMA to DAC clock domain, seems to exhibit a race condition. The value is used directly after the data is crossing the clock domain and there is no edge detection on the XFER_OUT signal.
I understand that DMA transfer support for these fast devices is not fully implemented yet. But I don't even get, how it is currently meant to be used.