Hello,
On 3/6/2013 12:40 AM, Scott Jiang wrote:
No MMU systems also make use of this function to do mmap.
Signed-off-by: Scott Jiang <scott.jiang.linux@xxxxxxxxx>
---
drivers/base/dma-mapping.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 0ce39a3..ae655b2 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -245,7 +245,6 @@ int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size)
{
int ret = -ENXIO;
-#ifdef CONFIG_MMU
unsigned long user_count = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
unsigned long pfn = page_to_pfn(virt_to_page(cpu_addr));
@@ -262,7 +261,6 @@ int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
user_count << PAGE_SHIFT,
vma->vm_page_prot);
}
-#endif /* CONFIG_MMU */
return ret;
}
I really have no experience with NO-MMU kernels, could you explain a bit
more how this
is useful for handling mmap on such systems? How remap_pfn_range() is
handled on no-mmu
systems?
I've thought that mmap on no-mmu systems is silently replaced by a call to
get_unmapped_area(), but it looks that there is still a call to mmap
function.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
