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>
The ratio value that's compared against ratio_ceil tunable can be 0 for
workloads that are extremely latency sensitive. So, we can't ignore cores
that have a ratio of 0 (which was done to ignore idle cores). So, stop
ignoring cores with a ratio of 0 and instead check for instruction or
frequency being 0 to identify idle cores.
Change-Id: I8c6c14f374f016e6612c3b834589d065bad8f488
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
In bytes_to_mbps function, the parameter is all unsigned,
so change the decleration of the function to include unsigned long
long to avoid compilation errors in 32 bit environment.
Also changed the return value as unsigned long to avoid
any data loss possible in 64 bit environment.
Change-Id: Ib3906bb4bc16086ae343764c5a718f6f005428c5
Signed-off-by: Maria Yu <aiquny@codeaurora.org>
During suspend alarm timer sends next wakeup time to
be programmed. Currently next wakeup time is not reset
upon wakeup. This causes unintended wakeups if there is
no alarm set during next suspend.
Reset suspend wake time during exit from suspend.
Change-Id: Ia0e5d08a4e5cdc71f6c2d884363b830de5ef88d5
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Prediction can select shallower low power mode for isolated
cpu based on historical data.
Do not predict LPMs for isolated cpus.
Change-Id: I998008ef3c578c1dccfacae8513a15dfbe397e16
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
As it's a general understanding across all architectures to have
a WFI (or equalivalent) mode always present and never disabled
for cpuidle, return true for CPU WFI mode allow check.
Change-Id: Ic55571488f845e4aaf997faaac3b2e0f22368d4e
Signed-off-by: Srinivas Rao L <lsrao@codeaurora.org>
In below scenario blkio cgroup does not work as per their assigned
weights :-
1. When the underlying device is nonrotational with a single HW queue
with depth of > 5
2. When the use case is forming two blkio cgroups cg1(weight 1000) &
cg2(wight 100) and two processes(file1 and file2) doing sync IO in
their respective blkio cgroups.
For above usecase result of fio (without this patch):-
file1: (groupid=0, jobs=1): err= 0: pid=685: Thu Jan 1 19:41:49 1970
write: IOPS=1315, BW=41.1MiB/s (43.1MB/s)(1024MiB/24906msec)
<...>
file2: (groupid=0, jobs=1): err= 0: pid=686: Thu Jan 1 19:41:49 1970
write: IOPS=1295, BW=40.5MiB/s (42.5MB/s)(1024MiB/25293msec)
<...>
// both the process BW is equal even though they belong to different
cgroups with weight of 1000(cg1) and 100(cg2)
In above case as soon as the request from cg1 is completed and even
though it is provided with higher slice_idle=10, because of CFQ
algorithm when the driver tries to fetch the request, CFQ expires
this group without providing any idle time nor weight priority
and schedules another cfq group (in this case cg2).
And thus both cfq groups(cg1 & cg2) keep alternating to get the
disk time and hence loses the cgroup weight based scheduling.
Below patch gives a chance to cfq algorithm (cfq_arm_slice_timer)
to arm the slice timer in case group_idle is enabled.
With this patch result of fio(for above usecase) :-
file1: (groupid=0, jobs=1): err= 0: pid=690: Thu Jan 1 00:06:08 1970
write: IOPS=1706, BW=53.3MiB/s (55.9MB/s)(1024MiB/19197msec)
<..>
file2: (groupid=0, jobs=1): err= 0: pid=691: Thu Jan 1 00:06:08 1970
write: IOPS=1043, BW=32.6MiB/s (34.2MB/s)(1024MiB/31401msec)
<..>
// In this processes BW is as per their respective cgroups weight.
Change-Id: I2eb20e48d6fd8ee48e01f00c514a1ee1476fd19c
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
The supported mappings for ARMv8 are 1GB, 2MB, 64KB and 4KB. So 1MB
allocations from ion pool is not used for ARMv8 section map. Such
allocations end up being mapped as multiple 64K sections map, while still
using 1MB contiguous memory. In case of ARMv7s, page-order 9 allocations
are not used as section map.
Drop page-order 8 ion pool for builds using ARMv8 pagetables and page-order
9 ion pool for builds using ARMv7s.
Change-Id: Ifff2d8f1cf61ce443311d16c11b8edc191b27a22
Signed-off-by: Prakash Gupta <guptap@codeaurora.org>
We need kgsl_worker_thread to preempt
all userspace surfaceflinger threads to
avoid a possible deadlock.
This will prevent the SF
threads from "stealing" cputime from
kgsl_worker_thread.
This is important, since kgsl_worker_thread
executes work which blocks SF from proceeding.
Change-Id: Ic4c9ca1f44ad8952ae2154a84ded7013244ca20d
Signed-off-by: Alex Naidis <alex.naidis@linux.com>
do_shrink_slab() scans each shrinker in batches of at most
batch_size (128) pages at a time until total_scan pages are
scanned or until shrinker returns SHRINK_STOP. Under heavy
memory pressure total_scan can be large (in thousands) and
kgsl_pool_shrink_scan_objects() ends up returning 0 after
all pages that were reclaimable are reclaimed. This results in
multiple calls to kgsl_pool_shrink_scan_objects() that do not
reclaim any memory. To prevent this kgsl_pool_shrink_scan_objects()
is modified to return SHRINK_STOP as soon as no more memory can
be reclaimed.
Bug: 69931996
Test: tested using alloc-stress with additional traces
Change-Id: Ia48fc2c0d888c54ec9642c0b0962a70ca3cb4c5e
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
This reverts commit 90d6246fca5f288606551c5d02af920bfeb05b9b.
To address the launch latency issue seen because of increase in
memory allocation time.
Change-Id: I147ca8607337541b7a29056b4bd1b46aa374c6e3
Signed-off-by: Deepak Kumar <dkumar@codeaurora.org>
This enum is already perfectly aliased to enum nl80211_band, and
the only reason for it is that we get IEEE80211_NUM_BANDS out of
it. There's no really good reason to not declare the number of
bands in nl80211 though, so do that and remove the cfg80211 one.
Change-Id: Ifc56e6297146c9095432b757fabd0c463d7cc583
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bug: 62057517
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Without much context to why these warnings even exist (especially with
the ambiguous comment "Avoid warning in user-space"), I'd rather play
it safe and not disturb the code but "fix" the warning.
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
As pointed out by Josh in the comments of 60e5a5f0b974, this seems
like an addition that just isn't necessary. Self assign shouldn't
be necessary here so we'll just reverse the condition and eliminate
the self assignment.
Reviewed-by: joshuous <joshuous@gmail.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Clang warns when a variable is assigned to itself.
drivers/net/usb/lan78xx.c:940:11: warning: explicitly assigning value of
variable of type 'u32' (aka 'unsigned int') to itself [-Wself-assign]
offset = offset;
~~~~~~ ^ ~~~~~~
1 warning generated.
Reorder the if statement to acheive the same result and avoid a self
assignment warning.
Link: https://github.com/ClangBuiltLinux/linux/issues/129
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
