04-29-2015 10:31 PM
If the bit 22 is set to '1' in L2CCAuxControl , the cache is NOT coherence with ACP port.
If the bit is set to '0', there is a exclusive access issue for non-cacheable shared memory ( please see http://forums.xilinx.com/xlnx/board/crawl_message?board.id=zaps&message.id=1071 ).
Is there any way to handle the two issues perfectly? Thanks a lot.
06-09-2015 10:57 AM
To Xilinx experts,
I concur, this is a big problem. I have a linux application that makes heavy use of DMA to move data between interfaces. The upgrade from Linux kernel version from 3.17 to 3.18 changed the way (bit 22) was programmed in the L2CCAuxControl which killed the coherence of the ACP port for one of my IP peripherals. I have changed the bit (to 0) and things seem to work, but now the I have the spector of the exclusive access issue failing (presumably in a semaphore section).
The ACP port was used because of the obscenely CPU intensive cost of the ARM coprocessor 15 cache maintenance operations. Benchmarking shows that 50% of one CPU is totally consumed on one line of assembly language code when my DMA engines were (trying to) run at maximum speed. The line of code is the cache clean operation in arch/arm/mm/cache-v7.S(v7_dma_clean_range)
mcr p15, 0, r0, c7, c14, 1 @ clean & invalidate D / U line
Apparently the ACP port was invented as a workaround for this ARM performance bottleneck.
11-06-2015 07:14 PM
11-17-2015 02:54 PM
I have looked at this. See post https://forums.xilinx.com/t5/Zynq-All-Programmable-SoC/Zynq-ACP-Cohereny-with-Linux-ioremap-cache/m-p/663555#M10942
I discovered that with Bit 22 set (unmodifed kernel) I apparently get cache cohernecy on the ACP if I override AWCACHE and ARCACHE to 1111 on the block diagram.
I don't know whether this is a reliable solution, so have not marked it as solved.