[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <52D7EC74.7030401@samsung.com>
Date: Thu, 16 Jan 2014 15:28:04 +0100
From: Marek Szyprowski <m.szyprowski@...sung.com>
To: Akinobu Mita <akinobu.mita@...il.com>,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org
Cc: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
David Woodhouse <dwmw2@...radead.org>,
Don Dutile <ddutile@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, Andi Kleen <andi@...stfloor.org>,
x86@...nel.org, iommu@...ts.linux-foundation.org
Subject: Re: [PATCH v2 3/5] intel-iommu: integrate DMA CMA
Hello,
On 2014-01-14 15:13, Akinobu Mita wrote:
> This adds support for the DMA Contiguous Memory Allocator for intel-iommu.
> This change enables dma_alloc_coherent() to allocate big contiguous
> memory.
>
> It is achieved in the same way as nommu_dma_ops currently does, i.e.
> trying to allocate memory by dma_alloc_from_contiguous() and alloc_pages()
> is used as a fallback.
>
> Cc: Marek Szyprowski <m.szyprowski@...sung.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
> Cc: David Woodhouse <dwmw2@...radead.org>
> Cc: Don Dutile <ddutile@...hat.com>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Ingo Molnar <mingo@...hat.com>
> Cc: "H. Peter Anvin" <hpa@...or.com>
> Cc: Andi Kleen <andi@...stfloor.org>
> Cc: x86@...nel.org
> Cc: iommu@...ts.linux-foundation.org
> Signed-off-by: Akinobu Mita <akinobu.mita@...il.com>
> ---
> No change from the previous version
>
> drivers/iommu/intel-iommu.c | 32 ++++++++++++++++++++++++--------
> 1 file changed, 24 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index fd426ca..172c2b0 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -3004,7 +3004,7 @@ static void *intel_alloc_coherent(struct device *hwdev, size_t size,
> dma_addr_t *dma_handle, gfp_t flags,
> struct dma_attrs *attrs)
> {
> - void *vaddr;
> + struct page *page = NULL;
> int order;
>
> size = PAGE_ALIGN(size);
> @@ -3019,17 +3019,31 @@ static void *intel_alloc_coherent(struct device *hwdev, size_t size,
> flags |= GFP_DMA32;
> }
>
> - vaddr = (void *)__get_free_pages(flags, order);
> - if (!vaddr)
> + if (!(flags & GFP_ATOMIC)) {
GFP_ATOMIC is not a flag, so please change the above check to:
if (flags & __GFP_WAIT)
I will also fix the similar issue in arch/x86/kernel/pci-dma.c
> + unsigned int count = size >> PAGE_SHIFT;
> +
> + page = dma_alloc_from_contiguous(hwdev, count, order);
> + if (page && iommu_no_mapping(hwdev) &&
> + page_to_phys(page) + size > hwdev->coherent_dma_mask) {
> + dma_release_from_contiguous(hwdev, page, count);
> + page = NULL;
> + }
> + }
> +
> + if (!page)
> + page = alloc_pages(flags, order);
> + if (!page)
> return NULL;
> - memset(vaddr, 0, size);
> + memset(page_address(page), 0, size);
>
> - *dma_handle = __intel_map_single(hwdev, virt_to_bus(vaddr), size,
> + *dma_handle = __intel_map_single(hwdev, page_to_phys(page), size,
> DMA_BIDIRECTIONAL,
> hwdev->coherent_dma_mask);
> if (*dma_handle)
> - return vaddr;
> - free_pages((unsigned long)vaddr, order);
> + return page_address(page);
> + if (!dma_release_from_contiguous(hwdev, page, size >> PAGE_SHIFT))
> + __free_pages(page, order);
> +
> return NULL;
> }
>
> @@ -3037,12 +3051,14 @@ static void intel_free_coherent(struct device *hwdev, size_t size, void *vaddr,
> dma_addr_t dma_handle, struct dma_attrs *attrs)
> {
> int order;
> + struct page *page = virt_to_page(vaddr);
>
> size = PAGE_ALIGN(size);
> order = get_order(size);
>
> intel_unmap_page(hwdev, dma_handle, size, DMA_BIDIRECTIONAL, NULL);
> - free_pages((unsigned long)vaddr, order);
> + if (!dma_release_from_contiguous(hwdev, page, size >> PAGE_SHIFT))
> + __free_pages(page, order);
> }
>
> static void intel_unmap_sg(struct device *hwdev, struct scatterlist *sglist,
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists