On 14/06/2019 16:34, Christoph Hellwig wrote:
On Fri, Jun 14, 2019 at 05:30:32PM +0200, Greg KH wrote:
On Fri, Jun 14, 2019 at 04:48:57PM +0200, Christoph Hellwig wrote:
On Fri, Jun 14, 2019 at 04:02:39PM +0200, Greg KH wrote:
Perhaps a hint as to how we can fix this up? This is the first time
I've heard of the comedi code not handling dma properly.
It can be fixed by:
a) never calling virt_to_page (or vmalloc_to_page for that matter)
on dma allocation
b) never remapping dma allocation with conflicting cache modes
(no remapping should be doable after a) anyway).
Ok, fair enough, have any pointers of drivers/core code that does this
correctly? I can put it on my todo list, but might take a week or so...
Just about everyone else. They just need to remove the vmap and
either do one large allocation, or live with the fact that they need
helpers to access multiple array elements instead of one net vmap,
which most of the users already seem to do anyway, with just a few
using the vmap (which might explain why we didn't see blowups yet).
Avoiding the vmap in comedi should be do-able as it already has other
means to get at the buffer pages.
When comedi makes the buffer from DMA coherent memory, it currently
allocates it as a series of page-sized chunks. That cannot be mmap'ed
in one go with dma_mmap_coherent(), so I see the following solutions.
1. Change the buffer allocation to allocate a single chunk of DMA
coherent memory and use dma_mmap_coherent() to mmap it.
2. Call dma_mmap_coherent() in a loop, adjusting vma->vm_start and
vma->vm_end for each iteration (vma->vm_pgoff will be 0), and restoring
the vma->vm_start and vma->vm_end at the end.
I'm not sure if 2 is a legal option.
--
-=( Ian Abbott <abbotti@xxxxxxxxx> || Web: www.mev.co.uk )=-
-=( MEV Ltd. is a company registered in England & Wales. )=-
-=( Registered number: 02862268. Registered address: )=-
-=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=-
