(cherry picked from url https://patchwork.kernel.org/patch/10044505/)
Take an effort to recode the arm64 vdso code from assembler to C
previously submitted by Andrew Pinski <apinski@cavium.com>, rework
it for use in both arm and arm64, overlapping any optimizations
for each architecture. But instead of landing it in arm64, land the
result into lib/vdso and unify both implementations to simplify
future maintenance.
Rename seq_count to tb_seq_count. Rename tk_is_cntvct to use_syscall.
Rename cs_mult to cs_mono_mult. All to align with the variables in the
arm64 vdso datapage. Rework vdso_read_begin() and vdso_read_retry()
functions to reflect modern access patterns for tb_seq_count field.
Update copyright message to reflect the start of the contributions in
this series.
Signed-off-by: Mark Salyzyn <salyzyn@android.com>
Cc: James Morse <james.morse@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Laura Abbott <labbott@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Andy Gross <andy.gross@linaro.org>
Cc: Kevin Brodsky <kevin.brodsky@arm.com>
Cc: Andrew Pinski <apinski@cavium.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Bug: 63737556
Bug: 20045882
Change-Id: I13f16e71b1ecba3d72b999caafef72e3c7f48dfe
(cherry picked from url http://lkml.iu.edu/hypermail/linux/kernel/1709.1/01903.html)
Make it possible to disable the kuser helpers by adding a KUSER_HELPERS
config option (enabled by default). When disabled, all kuser
helpers-related code is removed from the kernel and no mapping is done
at the fixed high address (0xffff0000); any attempt to use a kuser
helper from a 32-bit process will result in a segfault.
Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
Signed-off-by: Mark Salyzyn <salyzyn@android.com>
Bug: 9674955
Bug: 63737556
Bug: 20045882
Change-Id: Ie8c543301d39bfe88ef71fb6a669e571914b117b
(cherry picked from url http://lkml.iu.edu/hypermail/linux/kernel/1709.1/01902.html)
AArch32 processes are currently installed a special [vectors] page that
contains the sigreturn trampolines and the kuser helpers, at the fixed
address mandated by the kuser helpers ABI.
Having both functionalities in the same page has become problematic,
because:
* It makes it impossible to disable the kuser helpers (the sigreturn
trampolines cannot be removed), which is possible on arm.
* A future 32-bit vDSO would provide the sigreturn trampolines itself,
making those in [vectors] redundant.
This patch addresses the problem by moving the sigreturn trampolines
sources to its own file. Wrapped the comments to reduce the wrath of
checkpatch.pl.
Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
Signed-off-by: Mark Salyzyn <salyzyn@android.com>
Bug: 9674955
Bug: 63737556
Bug: 20045882
Change-Id: I1d7b96e7cfbe979ecf4cb4996befd1f3ae0e64fd
(cherry picked from url http://lkml.iu.edu/hypermail/linux/kernel/1709.1/01901.html)
AArch32 processes are currently installed a special [vectors] page that
contains the sigreturn trampolines and the kuser helpers, at the fixed
address mandated by the kuser helpers ABI.
Having both functionalities in the same page has become problematic,
because:
* It makes it impossible to disable the kuser helpers (the sigreturn
trampolines cannot be removed), which is possible on arm.
* A future 32-bit vDSO would provide the sigreturn trampolines itself,
making those in [vectors] redundant.
This patch addresses the problem by moving the sigreturn trampolines to
a separate [sigpage] page, mirroring [sigpage] on arm.
Even though [vectors] has always been a misnomer on arm64/compat, as
there is no AArch32 vector there (and now only the kuser helpers),
its name has been left unchanged, for compatibility with arm (there
are reports of software relying on [vectors] being there as the last
mapping in /proc/maps).
mm->context.vdso used to point to the [vectors] page, which is
unnecessary (as its address is fixed). It now points to the [sigpage]
page (whose address is randomized like a vDSO).
Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
Signed-off-by: Mark Salyzyn <salyzyn@android.com>
Bug: 9674955
Bug: 63737556
Bug: 20045882
Change-Id: I52a56ea71d7326df8c784f90eb73b5c324fe9d20
If error, don't trust "now" time that it should be setting
kernel/time/posix-cpu-timers.c:1269:13: warning: 'now' may be used uninitialized in this function [-Wmaybe-uninitialized]
Change-Id: I679d99c335494bae50fd926663fad37aedb1487a
Signed-off-by: Chris Fries <cfries@google.com>
If OSM driver is initialized later than msm_thermal, it will fail:
[ 0.226183] cpu cpu0: dev_pm_opp_get_opp_count: OPP table not found (-19)
[ 0.227931] msm_thermal:get_cpu_freq_plan_len Error reading CPU0 freq table len. error:-19
[ 0.227955] cpu cpu4: dev_pm_opp_get_opp_count: OPP table not found (-19)
[ 0.229631] msm_thermal:get_cpu_freq_plan_len Error reading CPU4 freq table len. error:-19
[ 0.229652] cpu cpu0: dev_pm_opp_get_opp_count: OPP table not found (-19)
[ 0.231380] msm_thermal:get_cpu_freq_plan_len Error reading CPU0 freq table len. error:-19
[ 0.231404] cpu cpu4: dev_pm_opp_get_opp_count: OPP table not found (-19)
[ 0.233095] msm_thermal:get_cpu_freq_plan_len Error reading CPU4 freq table len. error:-19
Change-Id: I98be9d37701f1f9366cef1427cfdd9082b8fb24c
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
Signed-off-by: celtare21 <celtare21@gmail.com>
trace_printk will cause trace_printk_init_buffers executed in kernel
start. Remove them from non-debug build.
Test: see nasty message gone in dmesg
Bug: 64215528
Change-Id: I82b8435a3cf36123608aae572c843db8ad86ac8a
Signed-off-by: Wei Wang <wvw@google.com>
Since commit d6f346f2d2 (cpuidle: improve governor Kconfig options)
the best cpuidle governor is selected automatically. There is little
point in additionally selecting the other one as it will not be used,
so don't select both governors by default.
Being able to select more than one governor is still good for
developers booting with cpuidle_sysfs_switch, though.
This fixes the second half of kernel BZ #65531.
Change-Id: I8757624f6bdc2d418b12ffcad294d273b9aca26d
Link: https://bugzilla.kernel.org/show_bug.cgi?id=65531
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Harsh Shandilya <harsh@prjkt.io>
Change the VM_MAX_READAHED value from the default 128KB to a
configurable value. This will allow the readahead window to grow to a
maximum size bigger than 128KB, which greatly benefits to sequential
read throughput and thus boot performance.
Bug: 62413151
Test: boot walleye 100ms faster
Change-Id: Iad448cf1198056de46654dcb409466802b3b908d
Signed-off-by: Wei Wang <wvw@google.com>
To avoid compile errors and warnings when the pfk module is enabled
without ecryptfs, the ecryptfs stubs need to be static inline.
Bug: 34712722
Change-Id: I39d715fcac1ff2f7781230cc2d1da2a8d803e974
Signed-off-by: Eric Biggers <ebiggers@google.com>
Crypto work is used to program file keys into
the Crypto HW. Some times the thread is scheduled
but is not executed and is preempted oftenly by
block i/o kworker. This causes same requests to be
requeued leading to timeout and cpu overload issues.
Change-Id: Icd9b5108018b85d60d72858c92673e1f2feddbd4
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
This reverts commit e3c2d0c27e3bd3df4b66bba9e9b47c7e0a442eb8.
This was severely slowing down usb transfer speeds.
Bug: 76154677
Test: mtp and adb speeds return to normal
Change-Id: I70e7a45b3d71a66a4191637891d145a86495aab6
Signed-off-by: Jerry Zhang <zhangjerry@google.com>
Prevents crash in the following sequence:
successful bind initializes all elements of rx_req
unbind frees all elements of rx_req but doesn't zero out rx_req
bind() -> failed create_bulk_endpoints() on allocating rx_req[0], tries
to free all elements of rx_req, double free on rx_req[1]
Bug: 73769117
Test: no crash
Change-Id: I69c538450ea52a1aa718d27a2a48629f66a7e8b6
Signed-off-by: Jerry Zhang <zhangjerry@google.com>
Set the request to null to avoid double free in
retry_rx_alloc.
Bug: 73645054
Test: no double free
Change-Id: Iecf22c807a4a23b4b2ba7ebee53c53502c616ec5
Signed-off-by: Jerry Zhang <zhangjerry@google.com>
Requests begin with large buffers for performance, and
the buffers are halved if allocation fails.
Bug: 67683483
Change-Id: I63d9f18385ca8e86894fd75d80c1702ee3e4e25f
Signed-off-by: Jerry Zhang <zhangjerry@google.com>
This reverts commit 545339b82c446a0509e775722b675115241c9f57.
This workaround is no longer needed because pinctrl IRQ chip driver has been fixed
to clear spurious interrupts:
https://partner-android-review.googlesource.com/c/kernel/private/msm-google/+/1070357/
Bug: 68261352
Bug: 77429706
Change-Id: I66400003a04f50f22033f80fe31ef81ce622cfc1
Signed-off-by: Petri Gynther <pgynther@google.com>
This reverts commit 59612d1879.
Android doesn't need to worry about buggy i686 implementations, which
was the reason behind the original revert.
See https://bugzilla.kernel.org/show_bug.cgi?id=61781.
Test: device enters suspend and everything works fine
bug 77139736
Change-Id: I84dd94d3cc8624293f10d0904c189ca63ecbe3d8
Signed-off-by: Tim Murray <timmurray@google.com>
Certain USB-C devices are failing to enumerate if the bus
transitions from active to suspend between connection and enumeration.
When a USB-C accessory is inserted in a phone and is detected by the
CC lines, the controller driver is loaded and the only devices present
on the bus are the root hubs, until the device enumerations.
As a result, a suspend transition between device connection and
enumeration is very likely.
This change leaves the hub autosuspend set to the usbcore.autosuspend
value so a value can be set high enough to prevent this race.
This reverts:
commit bdd405d2a5 ("usb: hub: Prevent hub autosuspend if usbcore.autosuspend is -1")
If user specifies that USB autosuspend must be disabled by module
parameter "usbcore.autosuspend=-1" then we must prevent
autosuspend of USB hub devices as well.
commit 596d789a21 introduced in v3.8 changed the original behaivour
and stopped respecting the usbcore.autosuspend parameter for hubs.
Bug: 71936484
Change-Id: Ie20471b9e8d44f92f9eff97ed12ccd903c98c272
Signed-off-by: Thierry Strudel <tstrudel@google.com>
Signed-off-by: Andrew Chant <achant@google.com>
Enable the xHCI plat runtime PM for parent device to
suspend/resume xHCI.
https://patchwork.kernel.org/patch/9679003/
Leaving out the pm_runtime_forbid() as autosuspend
seems to be enabled in qualcomm's code.
BUG: 63697798
Change-Id: I5c1ce3ccc0a70cddce9c68def30c7bc54165f479
Signed-off-by: Badhri Jagan Sridharan <Badhri@google.com>
For Low-latency audio playback usecase, vote for a priority
upgrade for Glink Rx thread, to avoid any performance issue.
Bug: 38234822
Change-Id: I8332c80eedd7325700e695f341fc4b92f65fd77c
Signed-off-by: Banajit Goswami <bgoswami@codeaurora.org>
If a driver invokes multiple power_supply_register(), the each supply
will not be saved in the supplied_from[] with the correct index.
supplied_from[0] = "dc"
num_supplies = 1;
supplied_from[0] = "usb"
num_supplies = 2;
supplied_from[0] = "battery"
num_supplies = 3;
...
It results in NPE when iterating the supplied_from[] with num_supplies on
__power_supply_is_supplied_by()
Bug: 63785418
Change-Id: Ifd14ca7c6e2df247e1090e4fa8d8c66bd2912180
Signed-off-by; Devin Kim <dojip.kim@lge.com>
Signed-off-by: Steve Pfetsch <spfetsch@google.com>
Android uses a 1 MiB console ramoops region, which requires kmalloc
to be changed to vmalloc in the following places:
1. pstore_mkfile(), allocation of inode->i_private
2. ramoops_pstore_read(), allocation of buf
Bug: 67383905
Change-Id: Ie4f355a5991b7cb6ad356ded7bd9d41630602bf5
Signed-off-by: Siqi Lin <siqilin@google.com>
console-ramoops size can be big enough for kmalloc() to
fail due to memory fragmentation. Use vmalloc() instead.
Bug: 65495856
Change-Id: I28c7ba97e8ebfd6b8f4ebfe9296a2d76fa6e2652
Signed-off-by: Siqi Lin <siqilin@google.com>
This patch protects against unknown spurious signals generated on Rx
line.
The possible sources of spurious signals are unknown as of now.
Yes, 1 msec delay after enabling wakeup interrupt to suppress false call
to ISR handlers which we do not expect.
In case of shutdown, we do not expect wake up irq to get fired as irq
gets disabled in the start.
Change-Id: I3cb34e5c39bff715cad1618c2eeefbf9bc95c87c
Signed-off-by: Mukesh Kumar Savaliya <msavaliy@codeaurora.org>
Kthread allocation can fail, so check that it's not an error value
before trying to stop it.
Bug: 63354008
Test: build & run bluetooth audio
Signed-off-by: Philip Cuadra <philipcuadra@google.com>
Change-Id: Ia8a91645beef2b4df64582b9059272f6df8ad4a9
For Bluetooth, the tty kthread should be RT in order to avoid scheduling
delays.
Bug: 36106419
Test: play bluetooth audio, verify tty kthread runs at RT via systrace
Change-Id: I441dd10d22f8831d055166bcd1ff9f01e5ca13d4
Signed-off-by: Philip Cuadra <philipcuadra@google.com>
This function allows the port's scheduling policy to be changed. Some
tty ports (like Bluetooth ones), need a higher priority to reduce
jitter.
Bug: 36106419
Test: Bluetooth audio
Change-Id: If11e21c55924314910d602573c735c6afae09709
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This makes each tty_port have their own kthread, hopefully allowing them
a bit more freedom in scheduling when they reveive data.
Based on a patch from Philip Cuadra <philipcuadra@google.com>
Based on a patch from Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 36106419
Test: run Bluetooth audio, ensure separate tty thread is created.
Signed-off-by: Philip Cuadra <philipcuadra@google.com>
Change-Id: I9fd25235b26a66acb37a40304c356209b74ad46c
msm_serial_hs threads for RX and TX are responsible for passing key
bluetooth buffers, such as bluetooth audio, between the Bluetooth HW and
the upper layers of the stack. These threads are therefore on the
critical path for bluetooth audio latency, and should be scheduled as
RT threads in order to ensure that they meet audio deadlines.
Bug 36106419
Test: Play bluetooth audio, confirm msm_serial_hs_0 threads are
scheduled as RT threads via systrace
Change-Id: I078dbcbab189a03bdc5fdfde6ec8c41c79c11610
Signed-off-by: Philip Cuadra <philipcuadra@google.com>
Regardless of CPU isolation or not, we need to wake up all the
CPUs during suspend to idle so that each CPU can disable their
local tick device, etc. If we don't wake every CPU up, then we
don't fully suspend the system and things like sched_clock and
timekeeping are never stopped properly.
Change-Id: Ic9141602acc5e6cddefca0727f9be075dad3e498
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
While doing a load balance there is a race in setting
loop_max variable since nr_running can be changed causing
incorect iteration loops.
As a result we may skip some candidates or check the same
tasks again.
Change-Id: I2f58f8fe96c14bd70674e600bc33caeb8aa960c6
Signed-off-by: Uladzislau 2 Rezki <uladzislau2.rezki@sonymobile.com>
Signed-off-by: Artem Labazov <123321artyom@gmail.com>
Thermal core uses work events to poll for sensor driver temperature
crossing a threshold. Since it is not using a deferrable workqueue, it
might wake-up the device from sleep.
Use a deferrable work event and post the work in the power efficient
workqueue for estimating virtual sensor temperature.
Change-Id: I9dd21d8fc4e5ca96e06db9ecb57a628618494a01
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
Thermal framework uses system freezable work queue for processing the
governor action and mitigation action will be performed in the same
context. System work queue can have one max active event processing
and if the mitigation action is delayed, that will bottleneck the
rest of the work queue event processing. This will result in delayed
action and temperature overshoot.
To avoid this, a new high priority thermal work queue is created and all
the passive monitoring will be done in the high priority context. Also
this work queue has a max active count defined as 16, which will allow
multi-processing of work events.
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
The Android-tuned page block heuristic was accidentally reset in an AU
drop. Fix the heuristic to avoid unnecessary unmovable pageblock
migration over time.
bug 30643938
Bug: 63336523
(cherry-picked from commit 3e19bcf7d08713daaaba888b4d13502e06e38e96)
Change-Id: I59efcd3934f29982b1c9aeb7b0f18eb17e0934b3
Signed-off-by: John Dias <joaodias@google.com>
Poorly made kernel trees often use trace_printk() without
properly guarding them in a #ifdef macro.
Such usage of trace_printk() causes a warning at
boot and additional memory allocation.
This option serves to disable those all at once with ease.
Change-Id: I2cb2085f48064bda8c18806597c5aee57237dca6
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
Signed-off-by: Alex Naidis <alex.naidis@linux.com>
Introduce the irq_enable callback which will be same as irq_unmask
except that it will also clear the status bit before unmask.
This will help in clearing any erraneous interrupts that would
have got latched when the interrupt is not in use.
There may be devices like UART which can use the same gpio line
for data rx as well as a wakeup gpio when in suspend. The data that
was flowing on the line may latch the interrupt and when we enable
the interrupt before going to suspend, this would trigger the
unexpected interrupt. This change helps clearing the interrupt
so that these unexpected interrupts gets cleared.
Bug: 68261352
Bug: 77429706
Change-Id: I017badff8d5b993599d7e7240ed4702ff4b344ad
Signed-off-by: Srinivas Ramana <sramana@codeaurora.org>
Signed-off-by: Kyle Yan <kyan@codeaurora.org>
Signed-off-by: Mugata, Sreenivasa Rao <smugat@codeaurora.org>
Signed-off-by: Petri Gynther <pgynther@google.com>
Fix race condition between rls handler thread and clock scaling thread when
LINERESET indication is sent out from host controller. A known scenario is
when clock scaling thread has put link to hibern8 after gear scaling down
is done, if rls handler thread, scheduled because of LINERESET indication
from controller, starts to run now to scale gear up (PWM to HS), it would
fail as the link state is still in hibern8 state. This change fixes this
race condition by using write semaphore to prevent rls handler thread and
clock scaling thread getting chance to run simultaneously.
Change-Id: Ia1731c921c42155cacb43029d56491ddffcf2ee2
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Can Guo <cang@codeaurora.org>
We have noticed that UFS load based clock scaling is ramping up to highest
frequency during low power usecases but never scales back to lower
frequency during the remaining usecase run period. This increases the
oveall power consumption for a given low power usecase. We analyzed UFS
data transfer pattern for different low power usecases and updated clock
scaling polling period & up threshold which helps with power numbers
without affecting performance numbers.
Change-Id: I74cf8a1f07d1b1a0ac112f28fc98a8a82cac1d28
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
In case of an exception, there could be a deadlock:
eeh_work:
-002|schedule()
-003|spin_lock_irq()
-003|rpm_resume << pm_runtime_get_sync(hba->dev);
-004|__pm_runtime_resume()
-005|ufshcd_scsi_block_requests()
-005|ufshcd_exception_event_handler()
ufshcd_suspend:
-002|schedule()
-003|schedule_timeout()
-004|do_wait_for_common()
-004|__wait_for_common()
-004|wait_for_common()
-005|wait_for_completion()
-006|destroy_work_on_stack()
-006|flush_work(?) << eeh_work
-007|ufshcd_suspend()
-008|ufshcd_runtime_suspend()
-009|ufshcd_pltfrm_runtime_suspend()
-010|pm_generic_runtime_suspend()
-011|__rpm_callback()
Scenario looks like :
1.Hba->eeh_work starts to work and at the almost same
time ufshcd_runtime_suspend start to work by rpm core.
2.pm_runtime_get_sync in eeh_work remains pending as
rpm_status is RPM_SUSPENDING due to ufshcd_runtime_suspend.
To fix this, call pm_runtime_get_noresume() once eeh_work
is scheduled so that suspend cannot be invoked during
exception work.
Change-Id: Ib212f71e22f063dad9c6ccca4aa8f7261e568b51
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
