- 14 Dec, 2013 35 commits
-
-
Rebecca Schultz Zavin authored
When ion_map_kernel is execute the system must allocate an array large enough to hold a pointer to each page in the buffer. If the buffer is very large and the system memory has become very fragmented, there may not be sufficient high order allocations available from kmalloc. Use vmalloc instead. Signed-off-by:
Rebecca Schultz Zavin <rebecca@android.com> [jstultz: modified patch to apply to staging directory] Signed-off-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Rebecca Schultz Zavin authored
Signed-off-by:
-
Rebecca Schultz Zavin authored
With this patch the system heap will only try to allocate from each order as long as allocations succeed. If it failes to obtain a higher order allocation, it doesn't retry that order. Signed-off-by:
-
Rebecca Schultz Zavin authored
If a buffer's user mappings are not going to be faulted in it need not be allocated page wise. We can optimize this common case by allocating an sglist of larger chunks rather than creating an entry for each page in the allocation. Signed-off-by:
-
Rebecca Schultz Zavin authored
We have found that faulting in the mappings for cached allocations has a significant performance impact and is only a benefit if only a small part of the buffer is touched by the cpu (an uncommon case for software rendering). This patch introduces a ION_FLAG_CACHED_NEEDS_SYNC which determines whether a mapping should be created by faulting or at mmap time. If this flag is set, userspace must manage the caches explictly using the SYNC ioctl. Signed-off-by:
-
Rebecca Schultz Zavin authored
Signed-off-by:
-
Rebecca Schultz Zavin authored
It is possible for a buffer to exist only as a dma_buf file descriptor without it being held in any handles. When this occurs it is impossible to track where the buffer is in the system (without traversing every process in the system and inspecting its file table). When buffers are orphaned like this, copy the task comm and pid of the last client to hold them into the buffer so we have a debugging hint as to where this buffer came from. In practice this will probalby be the process that allocated the buffer. Signed-off-by:
-
Rebecca Schultz Zavin authored
Signed-off-by:
-
Rebecca Schultz Zavin authored
If preemted during ion_free after the refcount is updated but before the handle can be removed from the rb_tree, import might find that handle in the tree and try to reuse it when execution returns to free, the handle will be cleaned up leaving the caller of import with a corrupt handle. This patch modifies the locking to protect agains this race. Signed-off-by:
-
Greg Hackmann authored
Signed-off-by:
Greg Hackmann <ghackmann@google.com> [jstultz: modified patch to apply to staging directory] Signed-off-by:
-
Rebecca Schultz Zavin authored
Previously, metadata was stored in the allocated pages themselves during allocation. However the system can only have a limited number of kmapped pages. A very large allocation might exceed this limit. Signed-off-by:
-
Rebecca Schultz Zavin authored
Signed-off-by:
-
Laura Abbott authored
If dma_buf_fd fails, the dma_buf needs to be cleaned up by calling dma_buf_put. dma_buf_put will call ion_dma_buf_release which in turn calls ion_buffer_put to clean up the buffer reference. Calling ion_buffer_put after dma_buf_put drops the reference count by one more which is incorrect. Fix this by getting rid of the extra ion_buffer_put call. Signed-off-by:
Laura Abbott <lauraa@codeaurora.org> [jstultz: modified patch to apply to staging directory] Signed-off-by:
-
Olav Haugan authored
ION_IOC_MAP, ION_IOC_SHARE, and ION_IOC_IMPORT may return success when an error occurs. Add correct error handling to ION_IOC_MAP, ION_IOC_SHARE, and ION_IOC_IMPORT. Signed-off-by:
Olav Haugan <ohaugan@codeaurora.org> [jstultz: modified patch to apply to staging directory] Signed-off-by:
-
Olav Haugan authored
Several functions in the ion interface is missing EXPORT_SYMBOL. This is needed to allow clients to use these functions from kernel modules. Add EXPORT_SYMBOL to functions that are supposed to be exposed. Signed-off-by:
-
Olav Haugan authored
The condition argument to the WARN call in ion_free and ion_share_dma_buf are missing. Add the argument to allow correct printing of warning message. Signed-off-by:
-
Dima Zavin authored
Signed-off-by:
Dima Zavin <dima@android.com> [jstultz: modified patch to apply to staging directory] Signed-off-by:
-
Rebecca Schultz Zavin authored
This is deprecated in favor of using the dma_buf api which will automatically sync a buffer to memory when it is mapped to a device. However, that functionality is not ready, so this patch adds the ability to sync a buffer explicitly. Signed-off-by:
-
Rebecca Schultz Zavin authored
On some systems there is a performance benefit to reducing tlb pressure by minimizing the number of chunks in an allocation. Signed-off-by:
-
Rebecca Schultz Zavin authored
This patch adds cache maintenance operations to ion. As per mailing list discussions regarding dma_buf, cache operations are done implicitly. At buffer allocaiton time the user can select whether he'd like mappings (both kernel and user) to be cached. When cached mappings are selected, no mappings will be created for a buffer at mmap time. Instead pages will be faulted in one at a time so we can track which pages require flushing before dma. When the buffers are mapped for dma (via the dma_buf apis) any pages which were touched will be synced for device. Signed-off-by:
-
Laura Abbott authored
When mapping carveout buffers into userspace, only map the size of the vma given, not the full size of the buffer since clients may map less than the buffer size. Signed-off-by:
-
Laura Abbott authored
When destroying a handle, all kernel mappings to that handle should be destroyed. Other handles may still have references and valid mappings to the buffer underneath which should not be destroyed. Loop on the handle reference count, not the buffer reference count to get rid of all kernel mappings for the handle. Signed-off-by:
-
Rebecca Schultz Zavin authored
Previously the ion_system_heap was using GFP_KERNEL, forcing all allocations to be in lowmem. This quickly causes us to run out of lowmem. Signed-off-by:
-
Rebecca Schultz Zavin authored
This patch sets the dma_address field of the sglist representing an allocation at allocation time. This technically breaks the dma api which states that these addresses should be set when a particular device takes ownership of a buffer via the dma_map apis. In the case of our systems the only dma address space is physical addresses. Additionally, we can not afford the overhead of calling dma_map_sg from this location as it implies a cache invalidate that is not necessary if the memory was previously mapped cached. Instead, the expectation is that memory being returned from the heaps is ready for dma in that if any cached mappings of that memory exist they have been invalidated. Signed-off-by:
-
Greg Hackmann authored
At least one map_dma() implementation (EXYNOS_CONTIG) assumes the fields are filled in Signed-off-by:
-
Rebecca Schultz Zavin authored
This patch adds an interface to return and sg_table given a valid ion handle. Signed-off-by:
-
Rebecca Schultz Zavin authored
Rather than calling map_dma on the allocations dynamically, this patch switches to creating the sg_table at the time the buffer is created. This is necessary because in future updates the sg_table will be used for cache maintenance. Signed-off-by:
-
Rebecca Schultz Zavin authored
These ops were added in the 3.4 kernel. This patch adds support for them to ion. Previous ion_map/unmap_kernel api is also retained in addition to this new api. Signed-off-by:
-
Rebecca Schultz Zavin authored
With this change the ion_system_heap will only use kernel address space when the memory is mapped into the kernel (rare case). Signed-off-by:
-
Rebecca Schultz Zavin authored
Ion now uses dma-buf file descriptors to share buffers with userspace. Ion becomes a dma-buf exporter and any driver that can import dma-bufs can now import ion file descriptors. Signed-off-by:
-
KyongHo Cho authored
1. Verifying if the size of memory allocation in ion_alloc() is aligned by PAGE_SIZE at least. If it is not, this change makes the size to be aligned by PAGE_SIZE. 2. Unmaps all mappings to the kernel and DMA address spaces when destroying ion_buffer in ion_buffer_destroy(). This prevents leaks in those virtual address spaces. 3. Makes the return value of ion_alloc() to be explicit Linux error code when it fails to allocate a buffer. 4. Makes ion_alloc() implementation simpler. Removes 'goto' statement and relavant call to ion_buffer_put(). 5. Checks if the task is valid before calling put_task_struct() due to failure on creating a ion client in ion_client_create(). 6. Returns error when buffer allocation requested by userspace is failed. Signed-off-by:
KyongHo Cho <pullip.cho@samsung.com> [jstultz: modified patch to apply to staging directory] Signed-off-by:
-
Rebecca Schultz Zavin authored
Rather than requiring each platform call memblock_remove or reserve from the board file, add this to ion Signed-off-by:
-
Rebecca Schultz Zavin authored
Switch these api's from scatterlists to sg_tables Signed-off-by:
-
Colin Cross authored
__arch_ioremap is no longer available, use __arm_ioremap instead. Signed-off-by:
Colin Cross <ccross@android.com> [jstultz: modified patch to apply to staging directory] Signed-off-by:
-
Rebecca Schultz Zavin authored
Signed-off-by:
-
- 11 Dec, 2013 5 commits
-
-
H Hartley Sweeten authored
As pointed out by the kbuild test robot, and Ian Abbott, the dma >= 0 test is always true because dma is unsigned. This generates a warn message: drivers/staging/comedi/drivers/ni_at_a2150.c:715 a2150_attach() warn: always true condition '(dma >= 0) => (0-u32max >= 0)' Fix the test as suggested by Ian Abbott. Signed-off-by:
H Hartley Sweeten <hsweeten@visionengravers.com> Reported-by:
kbuild test robot <fengguang.wu@intel.com> Cc: Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
Eli Billauer authored
The driver was forced to "module only" following a previous failure to build into the kernel. The problem was resolved several months ago. This has been successfully tested with "make allyesconfig" on x86_64. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Eli Billauer <eli.billauer@gmail.com> Signed-off-by:
-
Malcolm Priestley authored
Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by:
-
Malcolm Priestley authored
byBBPreEDIndex value is initially 0, this means that from cold BBvUpdatePreEDThreshold is never set. This means that sensitivity may be in an ambiguous state, failing to scan any wireless points or at least distant ones. Signed-off-by:
-
Malcolm Priestley authored
Change s_vSaveTxPktInfo and BSSvUpdateNodeTxCounter to use vnt_tx_pkt_info relayed to BSSvUpdateNodeTxCounter via INTnsProcessData. pStatistic->abyTxPktInfo[byPktNum].byBroadMultiUni is unused and discarded. Signed-off-by:
-
