[beagleboard] PRU to DMA DDR caching issues
Hello, I encounter a caching issue with my application. I will describe what I want to do, how I planned to do it and what goes wrong: *WHAT:* By using the PRU on my BBB, I want to timestamp a periodic rising edge on one input pin in *a nanosecond scale *and signal it to a Linux Kernel module on the ARM. *HOW:* To receive an interrupt in my kernel module, I bridged the pin with the rising edge to a second one (timer4 interrupt). This interrupt fires a few microseconds after the event happened. To read values from the PRU with best determinism and lowest latency, I allocated some DDR memory with dma_alloc_coherent() in my kernel module and handout the address via debugfs to the PRU. The PRU is in endless loop: wait for rising edge, read out the PRU cycle counter and write the cycle counter to the DDR memory address. *This works like a charm and I got the event's cycle counter snapshot in my kernel module!* The kernel module interrupt is firing a few microseconds after the event and has some jitter I want to avoid. So I decided it would be best to burst the actual cycle counter to a second ram address for a ten thousand times by the PRU so when the Kernel module reads this ddr location, It knows the difference from the event's cycle counter and the cycle counter now. *This does not work!* *WRONG:* Initially everything appered to be working. I was reading out for example: event cycles: 1000 now cycles: 4300 great! But to test the "now cycles" counter, I added to the kernel module to read it thousand times in a loop. Guess what?* It is thousand times the same.* I tried a few options. For example to write and read two alternating memaddresses for this "now counter" by kernel and pru but nothing gives the results I expected. It seems like anyone caches the results. Any help? So many thanks... I hope the problem can be understood. Tom -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] PRU to DMA DDR caching issues
I tracked down the issue a bit more:
If I insert something between two reads of the DDR memory in my kernel
module (I inserted a pr_info("test")), the value is refreshed.
Maybe there is a possiblity to invalidate the cache? I will investigate
more.
Thanks
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] PRU to DMA DDR caching issues
Hello and thank you for the fast help. Here my answers for your comments: Unless you carefully write kernel code to treat your DDR memory buffer > as DMA memory, you are almost certainly encountering caching effects. > I thought to have this done by getting the memory space from dma_alloc_coherent(). I will research if there is more needed to disable the caching but my understanding was that a DMA flagged space will never be cached because the ARM core can not know if something has changed. > I recommend instead of using a buffer in DDR memory, use the PRU data memories. As to my tests, writing from the PRU to the DDR memory only requires 3 cycles on the PRU and not more on a few million tries (L3 fast interconnect). However I do not know how long it takes for this memory to be available at the ARM... I can not do all work in the PRU code because I need to tag the rising edge with the Linux Kernel time. Therefore I need to find out the most deterministic way to get the counter value into the Kernel. I will do further tests. Maybe there is someone here who experienced the same road. I think tagging an event with the PRU (5ns) and set it into relation to Linux Kernel Time without losing to much nanoseconds should be one of the great PRU benefits. Thanks all -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
