This training material from free-electron explains the cache effects and how to 
deal with them. Starting at slide 440 

http://free-electrons.com/doc/training/linux-kernel/linux-kernel-slides.pdf 
<http://free-electrons.com/doc/training/linux-kernel/linux-kernel-slides.pdf>

Regards,
John




> On Jan 3, 2016, at 8:58 AM, Thomas Köhler <kingtomm...@googlemail.com> wrote:
> 
> 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 
> <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 
> <mailto:beagleboard+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

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

Reply via email to