[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53CD6B1C.2010801@codeaurora.org>
Date: Mon, 21 Jul 2014 12:33:48 -0700
From: Laura Abbott <lauraa@...eaurora.org>
To: Catalin Marinas <catalin.marinas@....com>
CC: Will Deacon <Will.Deacon@....com>,
David Riley <davidriley@...omium.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Ritesh Harjain <ritesh.harjani@...il.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCHv4 3/5] common: dma-mapping: Introduce common remapping
functions
On 7/18/2014 6:53 AM, Catalin Marinas wrote:
> On Wed, Jul 02, 2014 at 07:03:36PM +0100, Laura Abbott wrote:
>> +void *dma_common_pages_remap(struct page **pages, size_t size,
>> + unsigned long vm_flags, pgprot_t prot,
>> + const void *caller)
>> +{
>> + struct vm_struct *area;
>> +
>> + area = get_vm_area_caller(size, vm_flags, caller);
>> + if (!area)
>> + return NULL;
>> +
>> + if (map_vm_area(area, prot, &pages)) {
>> + vunmap(area->addr);
>> + return NULL;
>> + }
>> +
>> + return area->addr;
>> +}
>
> Why not just replace this function with vmap()? It is nearly identical.
>
With this version, the caller stored and printed via /proc/vmallocinfo
is the actual caller of the DMA API whereas if we just call vmap we
don't get any useful caller information. Going to vmap would change
the existing behavior on ARM so it seems unwise to switch. Another
option is to move this into vmalloc.c and add vmap_caller.
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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