Hi Tomasz, On Friday 08 June 2012 16:31:31 Tomasz Stanislawski wrote: > Hi Laurent and Subash, > > I confirm the issue found by Subash. The function vb2_dc_kaddr_to_pages does > fail for some occasions. The failures are rather strange like 'got 95 of > 150 pages'. It took me some time to find the reason of the problem. > > I found that dma_alloc_coherent for iommu an ARM does use ioremap_page_range > to map a buffer to the kernel space. The mapping is done by updating the > page-table. > > The problem is that any process has a different first-level page-table. The > ioremap_page_range updates only the table for init process. The PT present > in current->mm shares a majority of entries of 1st-level PT at kernel range > (above 0xc0000000) but *not all*. That is why vb2_dc_kaddr_to_pages worked > for small buffers and occasionally failed for larger buffers. > > I found two ways to fix this problem. > a) use &init_mm instead of current->mm while creating an artificial vma > b) access the dma memory by calling > *((volatile int *)kaddr) = 0; > before calling follow_pfn > This way a fault is generated and the PT is > updated by copying entries from init_mm. > > What do you think about presented solutions? Just to be sure, this is a hack until dma_get_sgtable is available, and it won't make it to mainline, right ? In that case using init_mm seem easier. -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
