Replace vmalloc allocation with physical page allocation#1
Open
zyr3x wants to merge 12 commits intobart594:masterfrom
AOKPZMod:master
Open
Replace vmalloc allocation with physical page allocation#1zyr3x wants to merge 12 commits intobart594:masterfrom AOKPZMod:master
zyr3x wants to merge 12 commits intobart594:masterfrom
AOKPZMod:master
Conversation
Replace vmalloc allocation with physical page allocation. For most allocations we do not need a kernel virual address. vmalloc uses up the kernel virtual address space. By replacing vmalloc with physical page alloction and mapping that allocation to kernel space only when it is required prevents the kgsl driver from using unnecessary vmalloc virtual space. CRs-Fixed: 346921 Signed-off-by: Harsh Vardhan Dwivedi <hdwivedi@codeaurora.org> (cherry picked from commit 8cb835b656ae2c3faa79af4f374563d344b46d4a) Conflicts: drivers/gpu/msm/kgsl_sharedmem.c Change-Id: I88e1eb282cc4822970811728d00b1096188f64e9 Signed-off-by: Ram Kumar Chakravarthy Chebathini <rcheba@codeaurora.org> (cherry picked from commit d5fa912f599a71223496d2ff97ecd5040b95baaf) Signed-off-by: Zhoulu Luo <zluo@codeaurora.org> Conflicts: drivers/gpu/msm/kgsl.c drivers/gpu/msm/kgsl_sharedmem.c drivers/gpu/msm/kgsl_sharedmem.h
Fix the state to requested state so that when both ISR and timer fire at the same time, the state is set as SLEEP CRs-Fixed: 340484 Signed-off-by: Suman Tatiraju <sumant@codeaurora.org> (cherry picked from commit 9b6110bb38c7acf61e065ec206b62b1e1f089908) Change-Id: Ie625aba09feddf495647be2844dc0a4014605141 Signed-off-by: Ram Kumar Chakravarthy Chebathini <rcheba@codeaurora.org> (cherry picked from commit 7704bbd086590ef68aa30530c0ea18dc7f379780) Conflicts: drivers/gpu/msm/kgsl_pwrctrl.c Signed-off-by: Zhoulu Luo <zluo@codeaurora.org>
The outer cache needs to be flushed for these pages after they are allocated so that the GPU and CPU have a consistent view of them. CRs-Fixed: 346921 Signed-off-by: Jeremy Gebben <jgebben@codeaurora.org> (cherry picked from commit 7018a21bf2b52f1296557d1f6ec9ed64e9169de7) Change-Id: Id5c11ab8d856fc270330fd3258baa51b8efca192 Signed-off-by: Ram Kumar Chakravarthy Chebathini <rcheba@codeaurora.org> (cherry picked from commit a240fca76b5562d3ca53677151213286306bbc96) Signed-off-by: Zhoulu Luo <zluo@codeaurora.org>
/sys/class/kgsl/kgsl-3d0/snapshot/timestamp will have sysfs_notify() called when a hang happens, so that a userspace process can poll(2) on this file to detect a hang. CRs-Fixed: 354385 Change-Id: I0a3c8fcbe3fb09256bcd12f6e63c107536734485 Signed-off-by: Jeremy Gebben <jgebben@codeaurora.org> (cherry picked from commit 90812c8eac42b5ce7bb48e35897537021e01e6de) (cherry picked from commit 15456a25c55409ee3032c4e083d232a3d3aedf6e) Signed-off-by: Zhoulu Luo <zluo@codeaurora.org>
The powerrail off during slumber is causing a GPU hang CRs-Fixed: 355216 Signed-off-by: Suman Tatiraju <sumant@codeaurora.org> (cherry picked from commit 2bd5c33b0c7a47fffc089ced6d14efc0369a5bdc) Change-Id: I6a1d933abaca690124170dbda2a3ccc0cb1879b3 Signed-off-by: Zhoulu Luo <zluo@codeaurora.org>
In order to support synchronization in a process with a single gralloc handle we require the ability to write lock a buffer while it is already read locked by the same handle. This change extends the concept of an exclusive write lock or recursive read locks to a genlock handle (rather than the genlock lock). Genlock cannot provide deadlock protection because the same handle can be used simultaneously by a producer and consumer. In practice an error will still be generated when the timeout expires. Conflicts: drivers/base/genlock.c
The BIT macro is not defined for !_KERNEL_ resulting in compile errors. CRs-fixed: 356263 Change-Id: Ib2acd913033fccca63716d6585a51707c72debf0 Signed-off-by: Jeff Boody <jboody@codeaurora.org> Signed-off-by: Zhoulu Luo <zluo@codeaurora.org>
A race condition exists where the attach may not kref_get before the kref_put finished. The genlock_file_lock was originally added to protect against this case however it was not protecting the kref. CRs-fixed: 359649 Signed-off-by: Jeff Boody <jboody@codeaurora.org> (cherry picked from commit d6f534fc51eb5fc23d08dacceecd42a4b98747a6) Change-Id: I4115ea1cc39ebe38ad0032ebf86871ac9d23a312 Signed-off-by: Ramakrishna Prasad N <crpn@codeaurora.org> (cherry picked from commit 295371180c3c46c0078ad247a53e1c8364aeee1b) Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
It is possible for user space to attempt to attach a valid fd that does not correspond to a genlock file. This change adds a magic to the kernel private data that is used for validation. CRs-fixed: 359649 Signed-off-by: Jeff Boody <jboody@codeaurora.org> (cherry picked from commit 507a9d3354b24e7cc7f22e9695339de6df317fc1) Change-Id: Ice93bfc904f61431688f03027a4090ceb7b9289a Signed-off-by: Ramakrishna Prasad N <crpn@codeaurora.org> (cherry picked from commit 6856721e05a2e97130a654884a16cf8d79753d58) Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
bart594
pushed a commit
that referenced
this pull request
May 30, 2013
Running one program that continuously hotplugs and replugs a cpu
concurrently with another program that continuously writes to the
scaling_set_speed node eventually deadlocks with:
=============================================
[ INFO: possible recursive locking detected ]
3.4.0 #37 Tainted: G W
---------------------------------------------
filemonkey/122 is trying to acquire lock:
(s_active#13){++++.+}, at: [<c01a3d28>] sysfs_remove_dir+0x9c/0xb4
but task is already holding lock:
(s_active#13){++++.+}, at: [<c01a22f0>] sysfs_write_file+0xe8/0x140
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(s_active#13);
lock(s_active#13);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by filemonkey/122:
#0: (&buffer->mutex){+.+.+.}, at: [<c01a2230>] sysfs_write_file+0x28/0x140
#1: (s_active#13){++++.+}, at: [<c01a22f0>] sysfs_write_file+0xe8/0x140
stack backtrace:
[<c0014fcc>] (unwind_backtrace+0x0/0x120) from [<c00ca600>] (validate_chain+0x6f8/0x1054)
[<c00ca600>] (validate_chain+0x6f8/0x1054) from [<c00cb778>] (__lock_acquire+0x81c/0x8d8)
[<c00cb778>] (__lock_acquire+0x81c/0x8d8) from [<c00cb9c0>] (lock_acquire+0x18c/0x1e8)
[<c00cb9c0>] (lock_acquire+0x18c/0x1e8) from [<c01a3ba8>] (sysfs_addrm_finish+0xd0/0x180)
[<c01a3ba8>] (sysfs_addrm_finish+0xd0/0x180) from [<c01a3d28>] (sysfs_remove_dir+0x9c/0xb4)
[<c01a3d28>] (sysfs_remove_dir+0x9c/0xb4) from [<c02d0e5c>] (kobject_del+0x10/0x38)
[<c02d0e5c>] (kobject_del+0x10/0x38) from [<c02d0f74>] (kobject_release+0xf0/0x194)
[<c02d0f74>] (kobject_release+0xf0/0x194) from [<c0565a98>] (cpufreq_cpu_put+0xc/0x24)
[<c0565a98>] (cpufreq_cpu_put+0xc/0x24) from [<c05683f0>] (store+0x6c/0x74)
[<c05683f0>] (store+0x6c/0x74) from [<c01a2314>] (sysfs_write_file+0x10c/0x140)
[<c01a2314>] (sysfs_write_file+0x10c/0x140) from [<c014af44>] (vfs_write+0xb0/0x128)
[<c014af44>] (vfs_write+0xb0/0x128) from [<c014b06c>] (sys_write+0x3c/0x68)
[<c014b06c>] (sys_write+0x3c/0x68) from [<c000e0e0>] (ret_fast_syscall+0x0/0x3c)
This is because store() in cpufreq.c indirectly grabs a kobject
with kobject_get() and is the last one to call kobject_put()
indirectly via cpufreq_cpu_put().
Fix this deadlock by introducing two new functions,
cpufreq_cpu_get_sysfs() and cpufreq_cpu_put_sysfs() which do the
same thing as cpufreq_cpu_{get,put}() but don't grab the kobject.
CRs-fixed: 366560
Signed-off-by: Ramakrishna Prasad N <crpn@codeaurora.org>
(cherry picked from commit ddda0cf21dc6cb487aacd81fdb1a7343d2746d94)
Change-Id: I6ac89789e89099cff315d7a02de216423376b7f7
Signed-off-by: Shruthi Krishna <skrish@codeaurora.org>
bart594
pushed a commit
that referenced
this pull request
Sep 22, 2013
Running one program that continuously hotplugs and replugs a cpu
concurrently with another program that continuously writes to the
scaling_set_speed node eventually deadlocks with:
=============================================
[ INFO: possible recursive locking detected ]
3.4.0 #37 Tainted: G W
---------------------------------------------
filemonkey/122 is trying to acquire lock:
(s_active#13){++++.+}, at: [<c01a3d28>] sysfs_remove_dir+0x9c/0xb4
but task is already holding lock:
(s_active#13){++++.+}, at: [<c01a22f0>] sysfs_write_file+0xe8/0x140
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(s_active#13);
lock(s_active#13);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by filemonkey/122:
#0: (&buffer->mutex){+.+.+.}, at: [<c01a2230>] sysfs_write_file+0x28/0x140
#1: (s_active#13){++++.+}, at: [<c01a22f0>] sysfs_write_file+0xe8/0x140
stack backtrace:
[<c0014fcc>] (unwind_backtrace+0x0/0x120) from [<c00ca600>] (validate_chain+0x6f8/0x1054)
[<c00ca600>] (validate_chain+0x6f8/0x1054) from [<c00cb778>] (__lock_acquire+0x81c/0x8d8)
[<c00cb778>] (__lock_acquire+0x81c/0x8d8) from [<c00cb9c0>] (lock_acquire+0x18c/0x1e8)
[<c00cb9c0>] (lock_acquire+0x18c/0x1e8) from [<c01a3ba8>] (sysfs_addrm_finish+0xd0/0x180)
[<c01a3ba8>] (sysfs_addrm_finish+0xd0/0x180) from [<c01a3d28>] (sysfs_remove_dir+0x9c/0xb4)
[<c01a3d28>] (sysfs_remove_dir+0x9c/0xb4) from [<c02d0e5c>] (kobject_del+0x10/0x38)
[<c02d0e5c>] (kobject_del+0x10/0x38) from [<c02d0f74>] (kobject_release+0xf0/0x194)
[<c02d0f74>] (kobject_release+0xf0/0x194) from [<c0565a98>] (cpufreq_cpu_put+0xc/0x24)
[<c0565a98>] (cpufreq_cpu_put+0xc/0x24) from [<c05683f0>] (store+0x6c/0x74)
[<c05683f0>] (store+0x6c/0x74) from [<c01a2314>] (sysfs_write_file+0x10c/0x140)
[<c01a2314>] (sysfs_write_file+0x10c/0x140) from [<c014af44>] (vfs_write+0xb0/0x128)
[<c014af44>] (vfs_write+0xb0/0x128) from [<c014b06c>] (sys_write+0x3c/0x68)
[<c014b06c>] (sys_write+0x3c/0x68) from [<c000e0e0>] (ret_fast_syscall+0x0/0x3c)
This is because store() in cpufreq.c indirectly grabs a kobject
with kobject_get() and is the last one to call kobject_put()
indirectly via cpufreq_cpu_put().
Fix this deadlock by introducing two new functions,
cpufreq_cpu_get_sysfs() and cpufreq_cpu_put_sysfs() which do the
same thing as cpufreq_cpu_{get,put}() but don't grab the kobject.
CRs-fixed: 366560
Signed-off-by: Ramakrishna Prasad N <crpn@codeaurora.org>
(cherry picked from commit ddda0cf21dc6cb487aacd81fdb1a7343d2746d94)
Change-Id: I6ac89789e89099cff315d7a02de216423376b7f7
Signed-off-by: Shruthi Krishna <skrish@codeaurora.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replace vmalloc allocation with physical page allocation. For most
allocations we do not need a kernel virual address. vmalloc uses up
the kernel virtual address space. By replacing vmalloc with physical
page alloction and mapping that allocation to kernel space only
when it is required prevents the kgsl driver from using unnecessary
vmalloc virtual space.
CRs-Fixed: 346921
Signed-off-by: Harsh Vardhan Dwivedi hdwivedi@codeaurora.org
(cherry picked from commit 8cb835b656ae2c3faa79af4f374563d344b46d4a)
Conflicts:
Change-Id: I88e1eb282cc4822970811728d00b1096188f64e9
Signed-off-by: Ram Kumar Chakravarthy Chebathini rcheba@codeaurora.org
(cherry picked from commit d5fa912f599a71223496d2ff97ecd5040b95baaf)
Signed-off-by: Zhoulu Luo zluo@codeaurora.org
Conflicts: