UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Participant pharbanau
Participant
4,394 Views
Registered: ‎12-20-2016

mmap wrong behavior after migrating to new kernel

Jump to solution

Hi everyone,

 

In our project we use Analog devices AD9361 firmware, customizing it for our needs.

So, we've added AXI DMA block and custom block with AXI Stream interface. This design was running on Zynq ZC706 under Linux. In general we used kernel driver to allocate coherent memory, mmap it into userspace, which writes to this memory, then we transfer data to our custom block using DMA (i.e. only MM2S channel is used, on PS side it is connected to HP3 port). 

 

This design was working as expected, but after migrating from version 2014_R2 to 2016_R1 (kernel version 4.6) we have a problem that data written from userspace aren't visible to kernel module, i.e. allocated memory always holds initial zeroes inside kernel space.

 

We use dma_zalloc_coherent() to allocate memory, and

dma_common_mmap() to map this memory into userspace.

 

I think it is some caching issue. I know that there is some kernel routines to manually invalidate cache, but I'm not sure it is right way to solve problem, I prefer to rely on kernel. Previously everything worked and we didn't have to do manually cache control.

 

Could someone help with this issue?

 

Pavel.

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
Participant pharbanau
Participant
8,236 Views
Registered: ‎12-20-2016

Re: mmap wrong behavior after migrating to new kernel

Jump to solution

Thanks for the answer. 

 

I don't think that I have to use dma_sync_single_for_cpu(). As I understood from here this functions should be used with streaming API, like dma_map_single, but as I mentioned I used coherent (uncachable) DMA mapping during probe of my driver. Should I use dma_sync* functions in this case? 

 

BTW, I solved initial problem replacing dma_common_mmap with remap_pfn_range.

 

Best,

Pavel

 

 

 

0 Kudos
2 Replies
Teacher muzaffer
Teacher
4,354 Views
Registered: ‎03-31-2012

Re: mmap wrong behavior after migrating to new kernel

Jump to solution

@pharbanau Your problem is that you don't have a way to tell the system that the processor update to memory should be written to memory. You were just lucky that it worked in previous setup. You need to call dma_sync_single_for_device in the kernel to fix it. Add an ioctl to your kernel driver which the user space can call so that this function can be called so that the cache is flushed for PL to see.

- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
0 Kudos
Participant pharbanau
Participant
8,237 Views
Registered: ‎12-20-2016

Re: mmap wrong behavior after migrating to new kernel

Jump to solution

Thanks for the answer. 

 

I don't think that I have to use dma_sync_single_for_cpu(). As I understood from here this functions should be used with streaming API, like dma_map_single, but as I mentioned I used coherent (uncachable) DMA mapping during probe of my driver. Should I use dma_sync* functions in this case? 

 

BTW, I solved initial problem replacing dma_common_mmap with remap_pfn_range.

 

Best,

Pavel

 

 

 

0 Kudos