The heap id is compared against the heap mask in ion_alloc which is
incorrect, the heap type should be used.
Signed-off-by: Johan Mossberg <johan.mossberg(a)stericsson.com>
---
drivers/gpu/ion/ion.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/ion/ion.c b/drivers/gpu/ion/ion.c
index fc152b9..c811380f 100644
--- a/drivers/gpu/ion/ion.c
+++ b/drivers/gpu/ion/ion.c
@@ -414,7 +414,7 @@ struct ion_handle *ion_alloc(struct ion_client *client, size_t len,
if (!((1 << heap->type) & client->heap_mask))
continue;
/* if the caller didn't specify this heap type */
- if (!((1 << heap->id) & heap_mask))
+ if (!((1 << heap->type) & heap_mask))
continue;
buffer = ion_buffer_create(heap, dev, len, align, flags);
if (!IS_ERR_OR_NULL(buffer))
--
1.8.0
The heap mask used during client create was a bitmask of heap types
and the heap mask used during buffer allocation was a bitmask of
heap ids. Now, both of them assume a bitmask of heap ids.
The debugfs show functions for client and heap were showing info
for the heap type instead of showing info of the individual heap.
Change-Id: I9c2c142a63865f3d4250cd681dc5cde9638ca09f
Signed-off-by: Nishanth Peethambaran <nishanth(a)broadcom.com>
---
drivers/gpu/ion/ion.c | 26 +++++++++++++-------------
include/linux/ion.h | 8 ++++----
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/ion/ion.c b/drivers/gpu/ion/ion.c
index 6aa817a..b808972 100644
--- a/drivers/gpu/ion/ion.c
+++ b/drivers/gpu/ion/ion.c
@@ -62,7 +62,7 @@ struct ion_device {
* @dev: backpointer to ion device
* @handles: an rb tree of all the handles in this client
* @lock: lock protecting the tree of handles
- * @heap_mask: mask of all supported heaps
+ * @heap_mask: mask of all supported heap ids
* @name: used for debugging
* @task: used for debugging
*
@@ -398,7 +398,7 @@ struct ion_handle *ion_alloc(struct ion_client
*client, size_t len,
align, heap_mask, flags);
/*
* traverse the list of heaps available in this system in priority
- * order. If the heap type is supported by the client, and matches the
+ * order. If the heap id is supported by the client, and matches the
* request of the caller allocate from it. Repeat until allocate has
* succeeded or all heaps have been tried
*/
@@ -410,10 +410,10 @@ struct ion_handle *ion_alloc(struct ion_client
*client, size_t len,
down_read(&dev->lock);
for (n = rb_first(&dev->heaps); n != NULL; n = rb_next(n)) {
struct ion_heap *heap = rb_entry(n, struct ion_heap, node);
- /* if the client doesn't support this heap type */
- if (!((1 << heap->type) & client->heap_mask))
+ /* if the client doesn't support this heap id */
+ if (!((1 << heap->id) & client->heap_mask))
continue;
- /* if the caller didn't specify this heap type */
+ /* if the caller didn't specify this heap id */
if (!((1 << heap->id) & heap_mask))
continue;
buffer = ion_buffer_create(heap, dev, len, align, flags);
@@ -597,11 +597,11 @@ static int ion_debug_client_show(struct seq_file
*s, void *unused)
for (n = rb_first(&client->handles); n; n = rb_next(n)) {
struct ion_handle *handle = rb_entry(n, struct ion_handle,
node);
- enum ion_heap_type type = handle->buffer->heap->type;
+ int id = handle->buffer->heap->id;
- if (!names[type])
- names[type] = handle->buffer->heap->name;
- sizes[type] += handle->buffer->size;
+ if (!names[id])
+ names[id] = handle->buffer->heap->name;
+ sizes[id] += handle->buffer->size;
}
mutex_unlock(&client->lock);
@@ -1176,7 +1176,7 @@ static const struct file_operations ion_fops = {
};
static size_t ion_debug_heap_total(struct ion_client *client,
- enum ion_heap_type type)
+ int id)
{
size_t size = 0;
struct rb_node *n;
@@ -1186,7 +1186,7 @@ static size_t ion_debug_heap_total(struct
ion_client *client,
struct ion_handle *handle = rb_entry(n,
struct ion_handle,
node);
- if (handle->buffer->heap->type == type)
+ if (handle->buffer->heap->id == id)
size += handle->buffer->size;
}
mutex_unlock(&client->lock);
@@ -1207,7 +1207,7 @@ static int ion_debug_heap_show(struct seq_file
*s, void *unused)
for (n = rb_first(&dev->clients); n; n = rb_next(n)) {
struct ion_client *client = rb_entry(n, struct ion_client,
node);
- size_t size = ion_debug_heap_total(client, heap->type);
+ size_t size = ion_debug_heap_total(client, heap->id);
if (!size)
continue;
if (client->task) {
@@ -1228,7 +1228,7 @@ static int ion_debug_heap_show(struct seq_file
*s, void *unused)
for (n = rb_first(&dev->buffers); n; n = rb_next(n)) {
struct ion_buffer *buffer = rb_entry(n, struct ion_buffer,
node);
- if (buffer->heap->type != heap->type)
+ if (buffer->heap->id != heap->id)
continue;
total_size += buffer->size;
if (!buffer->handle_count) {
diff --git a/include/linux/ion.h b/include/linux/ion.h
index a7d399c..f0399ae 100644
--- a/include/linux/ion.h
+++ b/include/linux/ion.h
@@ -72,7 +72,7 @@ struct ion_buffer;
/**
* struct ion_platform_heap - defines a heap in the given platform
* @type: type of the heap from ion_heap_type enum
- * @id: unique identifier for heap. When allocating (lower numbers
+ * @id: unique identifier for heap. When allocating (lower numbers
* will be allocated from first)
* @name: used for debug purposes
* @base: base address of heap in physical memory if applicable
@@ -114,7 +114,7 @@ void ion_reserve(struct ion_platform_data *data);
/**
* ion_client_create() - allocate a client and returns it
* @dev: the global ion device
- * @heap_mask: mask of heaps this client can allocate from
+ * @heap_mask: mask of heap ids this client can allocate from
* @name: used for debugging
*/
struct ion_client *ion_client_create(struct ion_device *dev,
@@ -135,7 +135,7 @@ void ion_client_destroy(struct ion_client *client);
* @len: size of the allocation
* @align: requested allocation alignment, lots of hardware blocks have
* alignment requirements of some kind
- * @heap_mask: mask of heaps to allocate from, if multiple bits are set
+ * @heap_mask: mask of heap ids to allocate from, if multiple bits are set
* heaps will be tried in order from lowest to highest order bit
* @flags: heap flags, the low 16 bits are consumed by ion, the high 16
* bits are passed on to the respective heap and can be heap
@@ -236,7 +236,7 @@ struct ion_handle *ion_import_dma_buf(struct
ion_client *client, int fd);
* struct ion_allocation_data - metadata passed from userspace for allocations
* @len: size of the allocation
* @align: required alignment of the allocation
- * @heap_mask: mask of heaps to allocate from
+ * @heap_mask: mask of heap ids to allocate from
* @flags: flags passed to heap
* @handle: pointer that will be populated with a cookie to use to refer
* to this allocation
--
1.7.0.4
Hi Linus,
I would like to ask for pulling another set of Contiguous Memory Allocator and
DMA-mapping framework updates for v3.8.
The following changes since commit 29594404d7fe73cd80eaa4ee8c43dcc53970c60e:
Linux 3.7 (2012-12-10 19:30:57 -0800)
are available in the git repository at:
git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git for-v3.8
for you to fetch changes up to 4009793e15d44469da1547a46ab129cc08ffa503:
drivers: cma: represent physical addresses as phys_addr_t (2012-12-11 09:28:09 +0100)
----------------------------------------------------------------
This pull request consists only of two patches. First fixes long standing
issue with dmapools (the code predates current GIT history), which forced all
allocations to use GFP_ATOMIC flag, ignoring the flags passed by the caller.
The second patch changes CMA code to correctly use phys_addr_t type what
enables support for LPAE systems.
Thanks!
Best regards
Marek Szyprowski
Samsung Poland R&D Center
Patch summary:
Marek Szyprowski (1):
mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
Vitaly Andrianov (1):
drivers: cma: represent physical addresses as phys_addr_t
drivers/base/dma-contiguous.c | 24 ++++++++++--------------
include/linux/dma-contiguous.h | 4 ++--
mm/dmapool.c | 31 +++++++------------------------
3 files changed, 19 insertions(+), 40 deletions(-)
The goal of those patches is to allow ION clients (drivers or userland applications)
to use Contiguous Memory Allocator (CMA).
To get more info about CMA:
http://lists.linaro.org/pipermail/linaro-mm-sig/2012-February/001328.html
patches version 8:
- fix memory leak when release sg_table
- remove virt_to_phys from ion_cma_phys
patches version 7:
- rebased on Android kernel
- fix ion Makefile
- add ion_cma_map_kernel function
- remove CONFIG_CMA compilation flags from ion_heap.c
patches version 6:
- add private field in ion_platform_heap to pass the device
linked with CMA.
- rework CMA heap to use private field.
- prepare CMA heap for incoming dma_common_get_sgtable function
http://lists.linaro.org/pipermail/linaro-mm-sig/2012-June/002109.html
- simplify ion-ux500 driver.
patches version 5:
- port patches on android kernel 3.4 where ION use dmabuf
- add ion_cma_heap_map_dma and ion_cma_heap_unmap_dma functions
patches version 4:
- add ION_HEAP_TYPE_DMA heap type in ion_heap_type enum.
- CMA heap is now a "native" ION heap.
- add ion_heap_create_full function to keep backward compatibilty.
- clean up included files in CMA heap
- ux500-ion is using ion_heap_create_full instead of ion_heap_create
patches version 3:
- add a private field in ion_heap structure instead of expose ion_device
structure to all heaps
- ion_cma_heap is no more a platform driver
- ion_cma_heap use ion_heap private field to store the device pointer and
make the link with reserved CMA regions
- provide ux500-ion driver and configuration file for snowball board to give
an example of how use CMA heaps
patches version 2:
- fix comments done by Andy Green
Benjamin Gaignard (3):
gpu: ion: fix ion_platform_data definition
gpu: ion: add private field in ion_heap and ion_platform_heap
structure
gpu: ion: add CMA heap
drivers/gpu/ion/Kconfig | 5 ++
drivers/gpu/ion/Makefile | 1 +
drivers/gpu/ion/ion_cma_heap.c | 192 ++++++++++++++++++++++++++++++++++++++++
drivers/gpu/ion/ion_heap.c | 7 ++
drivers/gpu/ion/ion_priv.h | 16 ++++
include/linux/ion.h | 7 +-
6 files changed, 227 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/ion/ion_cma_heap.c
--
1.7.10