Age | Commit message (Collapse) | Author |
|
When user doesn't use default heap policy and selects
GART or carveout allocation, automatic single-page-to-sysmem
rule doesn't work. Because of broken rule many single page
allocations take extra space in carveout and create
unnecessary page mappings in GART and SMMU.
The fix adds sysmem bit to heap mask when allocation is
single page and GART or carveout is present in heap mask.
bug 730124
bug 731923
The change also does sanity check of available system memory
before adding sysmem bit for carveout allocations.
bug 777839
Reviewed-on: http://git-master/r/31383
(cherry picked from commit 502c2becc54b49d26371f9b167f0c6f82a1bc37f)
Bug 844307
Conflicts:
drivers/video/tegra/nvmap/nvmap_handle.c
Reviewed-on: http://git-master/r/38429
(cherry picked from commit ddfc93d27830a28a1c9786fd5bce6dc35727e9ff)
Change-Id: I9b8f84a5a7daf192d1d412926f91e5de71938818
Reviewed-on: http://git-master/r/47829
Reviewed-by: Andre Sihera <asihera@nvidia.com>
Tested-by: Andre Sihera <asihera@nvidia.com>
Reviewed-by: Kirill Artamonov <kartamonov@nvidia.com>
Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
|
|
The kernel now receives wait tracking data (similar to gathers and
relocs) and compares the current syncpt with the threshold value.
If it's old, it gets a kernel mapping and rewrites the method data
to use a kernel reserved syncpt that is always 0 (so trivially pops
when seen by the HW).
Bug 519650
Bug 785525
Bug 803452
Note: reset the author in this commit to fix a email addr problem
and since from the latest/last cherry pick there was a reworking
of the code to be compatible with different user space versions
it also seemed reasonable.
(cherry picked from commit 4069d8e67665624ad3dceb628e572980dd57acd0)
(cherry picked from commit 6e4336408588e348804a62e53386acc9abc06823)
(cherry picked from commit 87a9efe751716ca741caac72b9061fdfdcec540a)
Change-Id: I9c6076da2384f373d5f402bee4406b09b4ebc4ff
Reviewed-on: http://git-master/r/23159
Reviewed-on: http://git-master/r/30281
Tested-by: Chris Johnson <cwj@nvidia.com>
Reviewed-by: Ken Adams <kadams@nvidia.com>
Reviewed-by: Prajakta Gudadhe <pgudadhe@nvidia.com>
|
|
nvmap's debugfs had a bad format so it was
very difficult to read the outputs. this commit
fixes it and added total allocation size along
with it
Bug 813891
Change-Id: I6e3165b3ff917d9510d39f1e35b8e6b59c086592
Reviewed-on: http://git-master/r/27349
Reviewed-by: Donghan Ryu <dryu@nvidia.com>
Tested-by: Donghan Ryu <dryu@nvidia.com>
Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
|
|
This reverts commit be7b9ce20d645c2c9293441830ee33a0a5fc489f.
|
|
Change-Id: I517760af5756279b41836062063bdcaa04e5bfef
|
|
video:tegra:nvmap: Clean whole L1 instead of cleaning by MVA
For large allocations, cleaning each page of the allocation can
take a significant amount of time. If an allocation that nvmap needs
to clean or invalidate out of the cache is significantly larger than
the cache, just flush the entire cache by set/ways.
bug 788967
Reviewed-on: http://git-master/r/19354
(cherry picked from commit c01c12e63b1476501204152356867aeb5091fb80)
tegra:video:nvmap: optimize cache_maint operation.
optimize cache_maint operation for carveout and heap memories.
flush carveout memory allocations on memory free.
Bug 761637
Reviewed-on: http://git-master/r/21205
Conflicts:
drivers/video/tegra/nvmap/nvmap_dev.c
drivers/video/tegra/nvmap/nvmap_heap.c
drivers/video/tegra/nvmap/nvmap_ioctl.c
(cherry picked from commit 731df4df5e895e1d4999359d6d5939fc2095f883)
tegra:video:nvmap: optimize cache flush for system heap pages.
optimize cache flush for pages allocated from system heap.
Bug 788187
Reviewed-on: http://git-master/r/21687
(cherry picked from commit 3f318911ad91410aed53c90494210e2b8f74308b)
Change-Id: Ia7b90ba0b50acfef1b88dd8095219c51733e027f
Reviewed-on: http://git-master/r/23465
Reviewed-by: Kirill Artamonov <kartamonov@nvidia.com>
Tested-by: Kirill Artamonov <kartamonov@nvidia.com>
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
|
|
Bug 786016
Change-Id: Ic72c57b710a305851dfea3dda3eb217156683b39
Reviewed-on: http://git-master/r/17795
Reviewed-by: Varun Colbert <vcolbert@nvidia.com>
Tested-by: Varun Colbert <vcolbert@nvidia.com>
|
|
Change-Id: Id030cc94db62c9dcaa79a2ddd7c034ac9f9adc61
Reviewed-on: http://git-master/r/21803
Reviewed-by: Varun Colbert <vcolbert@nvidia.com>
Tested-by: Varun Colbert <vcolbert@nvidia.com>
|
|
This reverts commit b3cc1d84d0b962fe80fc297d2e2417c3157508b6.
|
|
This reverts commit 2d49bf33f3885aab293f12d54447f66e911e3226.
|
|
The kernel now receives wait tracking data (similar to gathers and
relocs) and compares the current syncpt with the threshold value.
If it's old, it gets a kernel mapping and rewrites the method data
to use a kernel reserved syncpt that is always 0 (so trivially pops
when seen by the HW).
Patch has dependency to the user-space patches
Submitted on behalf of: Chris Johnson <cjohnson@nvidia.com>
original work by: Chris Johnson <cjohnson@nvidia.com>
Change-Id: I4d4e5d3b49cab860485c4172f87247f5b4f5ea6e
|
|
Enabled mutex debugging reavealed potential deadlocks
introduced with compaction.
Handle spin lock replaced with mutex. Heap functions cannot be
protected with spinlock because they call kernel slab allocation
functions which cannot be called from atomic context.
nvmap_client ref_lock is also replaced with mutex. Otherwise we
cannot access heap parameters protected by mutex nvmap_handle lock.
Extra locking for handle->owner removed.
bug 793364
Change-Id: I635ce9ebf259dd7bf8802457567f93b7be5795ea
Reviewed-on: http://git-master/r/19850
Reviewed-by: Kirill Artamonov <kartamonov@nvidia.com>
Tested-by: Kirill Artamonov <kartamonov@nvidia.com>
Reviewed-by: Daniel Willemsen <dwillemsen@nvidia.com>
|
|
There are places where nvmap_free_handle_id is called
when interrupts are disabled and mutex cannot be used as
nvmap handle lock.
Change-Id: Icc220fe627c08f21c677d936a54f70c818dc8e8c
Reviewed-on: http://git-master/r/19489
Reviewed-by: Varun Colbert <vcolbert@nvidia.com>
Tested-by: Varun Colbert <vcolbert@nvidia.com>
|
|
Conflicts:
drivers/net/wireless/bcm4329/Makefile
Change-Id: I13ed89657bb43ac906c6424372050df5fd681374
|
|
An attempt had been made to reduce the number of pte operations
while patching relocs. The optimization was incorrectly coded
and was not providing the expected speedup.
Credit for the find goes to Peter Pipkorn.
Change-Id: Ic83b20ee470e54d5053f747dbcbdf7b038b7c7c4
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
|
|
bug 762482
Change-Id: Ifadebc1b0c4eb0df89e179091acca0ff6e527e56
Reviewed-on: http://git-master/r/15743
Reviewed-by: Kirill Artamonov <kartamonov@nvidia.com>
Tested-by: Kirill Artamonov <kartamonov@nvidia.com>
Reviewed-by: Varun Colbert <vcolbert@nvidia.com>
|
|
Conflicts:
arch/arm/mach-tegra/include/mach/dc.h
drivers/video/tegra/dc/hdmi.c
drivers/video/tegra/host/nvhost_acm.c
Change-Id: Iddf74984cc02f08dca3738967c0580ba7c375337
|
|
Need cache maintenance on rw_handle to remove
display garbage issue which happens randomly.
Bug 778138
Change-Id: I227913d1e49d7c28a1a776e2b946cfa0cc7e9803
Reviewed-on: http://git-master/r/17236
Reviewed-by: Niket Sirsi <nsirsi@nvidia.com>
Tested-by: Niket Sirsi <nsirsi@nvidia.com>
|
|
For NVMAP_IOC_GET_ID, if the requested handle isn't found in the
client-private list, check the device-wide handles if allowed (global
handles or superuser).
The proper way to share memory between clients is to first call
IOC_GET_ID from the client who owns the memory, pass the resulting ID to
the new client, and then use IOC_FROM_ID in the new client to get a
handle. However, some (broken) legacy applications did both IOC_GET_ID
and IOC_FROM_ID steps in the new client. To support those applications
but hopefully prevent new applications from growing the same behavior,
the NVMAP_SEARCH_GLOBAL_HANDLES config option was added that restores
the old behavior (default N).
Note that even with this option enabled, the client issuing the
IOC_GET_ID call must be privileged to access the handle provided. In
practice, this means the global list search only works for clients who
have opened the /dev/knvmap super device node.
Change-Id: I6a4490de922864d9119b24e610cfa127ec64bdc7
Signed-off-by: Robert Morell <rmorell@nvidia.com>
Reviewed-on: http://git-master/r/14431
Reviewed-by: Niket Sirsi <nsirsi@nvidia.com>
Tested-by: Niket Sirsi <nsirsi@nvidia.com>
|
|
-Add a module param to enable/disable carveout killer
-Fix race condition in code to wait for something to free memory
after firing carveout killer
-Fix the check for current so we always compare task->group_leaders
Change-Id: Ie030978827dce6b0fbbfa1db0d80e4abe59eaa51
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
|
|
-Modify the carveout killer to only kill tasks with lower priorities
than the one that's trying to allocate
-After delivering a sigkill to a task, wait for something to exit and
cleanup before retrying the allocation
Change-Id: If62b6ed008a73fc3c347ff26735a83eee284909e
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
|
|
No need to maintain a reference to the task struct if the client
is a kernel thread. In this case just set the task to NULL.
Change-Id: Ica4785388932f6b298eeb0da04b78b0e1cdc3a44
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
|
|
This change attempts to reclaim carveout memory by killing
other carveout users when an allocation fails. Processes
are killed in order of priority from lowest to highest, and then
from largest to smallest users.
Change-Id: Iee8a6f36269bc8165d691000a153dbf9f4337775
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
|
|
Change-Id: I1ec34fd4a6bb21a6d84912a7228c209f459261be
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
|
|
A struct nvmap_handle may be shared by multiple clients. If the
original client (the handle "owner") is destroyed, but the handle is
still referenced by other clients, h->owner points to freed memory. To
prevent this, clear h->owner when the owner frees its reference to that
struct nvmap_handle.
Change-Id: I54722091568ce2058f5988e5f6e00e68605a8100
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
|
|
Fix the way the total number of carveout allocations is
managed per client.
Change-Id: I3e12e2a98a74cafc1f4c51a48e3c3c549e930160
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
|
|
This reverts commit e3ad53ad739afae7e8a4252c807a195e2311cfa7.
|
|
This modifies the api to allow the user to specify a name
for their clients. This will allow the system to track
allocations from the kernel by name.
Change-Id: I44aad209bc54e72126be3bebfe416b30291d206c
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
|
|
Moves the file tracking clients to debugfs
Add a debugfs file to track the list of allocations per client
Change-Id: I2bb683e3ac0599fa05d962c79ef0b7cbd0007d75
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
|
|
Prints a log message if the nvmap allocate ioctl fails.
Change-Id: Ia0777bc2fcd665dafff0f8948b01faad3f552d72
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
|
|
In the current implementation handles hold references to a
client and clients hold references to their handles. As a
result when a process terminates it's handles can't be cleaned
up and we leak memory. Instead only hold references to handles
from clients.
Change-Id: Iba699e740a043deaf0a78b13b4ea01544675078f
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
|
|
This patch adds the ability to track the total allocations in a
given carveout heap by client. It also adds a sys file to print
the list of clients, their pids and their respective carveout sizes
Change-Id: I34fc97c3be574d2bd30d7594320ff05f6e13c476
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
|
|
Change-Id: Icfe552ad4a968329a1a2959d5b438062587a83b6
Signed-off-by: Colin Cross <ccross@android.com>
|
|
The framebuffer driver needs to be able to arbitrarily pin whatever
gets handed to it. Regardless of the interface used, functions need
to unpin as soon as they finish using the gart anyway.
Change-Id: Ida8aea2fb6eaca8bcbf3ae72f8dfa849dc198542
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
|
|
remove the dependency that nvmap has on the arm_attrib_allocator
and the lowmem in PTEs change by adding a private page allocator
utility function and calling vm_map_ram unconditionally for all
sysmem handles.
also, add Kconfig variables to allow platforms to disallow the
SYSMEM heap, and to optionally restrict the SYSMEM and IOVMM
heaps to just HIGHMEM.
Change-Id: I3dab1c7323f54a8ab3994dc672b27fd79a9057d7
Signed-off-by: Gary King <gking@nvidia.com>
|
|
Low mem pages are allocated in larger super pages and their caching
attributes can't be controlled on a per page basis. This patch
forces nvmap to map out of highmem pages which are guaranteed to have
page mappings.
Change-Id: Id3921342ecceb0345d43365d4dd90b82ca8cfd11
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
|
|
a >= vs > error when checking the operating region of the read and
write ioctls was causing failures when reading the last byte of a handle.
the super-user node (knvmap) wasn't registered correctly due to a cut-
and-paste error, and the regular user node was assigned super-user
priveleges.
noref pinning wasn't correctly validating that the specified handle
existed before pinning it, which caused the reference count for the
handle to become imbalanced on a subsequent unpin
Change-Id: I9985b85023705b00389a53fb962c3b60d62da6b8
Signed-off-by: Gary King <gking@nvidia.com>
|
|
nvmap provides an interface for user- and kernel-space clients to
allocate and access memory "handles" which can be pinned to enable
the memory to be shared with DMA devices on the system, and may
also be mapped (using caller-specified cache attributes) so that
they are directly accessible by the CPU.
the memory handle object gives clients a common API to allocate from
multiple types of memory: platform-reserved physically contiguous
"carveout" memory, physically contiguous (order > 0) OS pages,
or physically discontiguous order-0 OS pages that can be remapped
into a contiguous region of the DMA device's virtual address space
through the tegra IOVMM subsystem.
unpinned and unmapped memory handles are relocatable at run-time
by the nvmap system. handles may also be shared between multiple
clients, allowing (for example) a window manager and its client
applications to directly share framebuffers
Change-Id: Ie8ead17fe7ab64f1c27d922b1b494f2487a478b6
Signed-off-by: Gary King <gking@nvidia.com>
|