[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100720181239.5a1fd090@bike.lwn.net>
Date: Tue, 20 Jul 2010 18:12:39 -0600
From: Jonathan Corbet <corbet@....net>
To: Michal Nazarewicz <m.nazarewicz@...sung.com>
Cc: linux-mm@...ck.org, Marek Szyprowski <m.szyprowski@...sung.com>,
Pawel Osciak <p.osciak@...sung.com>,
Xiaolin Zhang <xiaolin.zhang@...el.com>,
Hiremath Vaibhav <hvaibhav@...com>,
Robert Fekete <robert.fekete@...ricsson.com>,
Marcus Lorentzon <marcus.xm.lorentzon@...ricsson.com>,
linux-kernel@...r.kernel.org,
Kyungmin Park <kyungmin.park@...sung.com>
Subject: Re: [PATCH 2/4] mm: cma: Contiguous Memory Allocator added
One other thing occurred to me as I was thinking about this...
> + There are four calls provided by the CMA framework to devices. To
> + allocate a chunk of memory cma_alloc() function needs to be used:
> +
> + unsigned long cma_alloc(const struct device *dev,
> + const char *kind,
> + unsigned long size,
> + unsigned long alignment);
The purpose behind this interface, I believe, is pretty much always
going to be to allocate memory for DMA buffers. Given that, might it
make more sense to integrate the API with the current DMA mapping API?
Then the allocation function could stop messing around with long values
and, instead, just hand back a void * kernel-space pointer and a
dma_addr_t to hand to the device. That would make life a little easier
in driverland...
jon
--
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