update #1
Open
update #1
Conversation
This file contains 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
In August 2012, Matthew Gretton-Dann checked a change into binutils labelled "Error on obsolete & warn on deprecated registers", apparently as part of ARMv8 support. Apparently, this was supposed to emit the message "Warning: This coprocessor register access is deprecated in ARMv8" when using certain mcr/mrc instructions and building for ARMv8. Unfortunately, the message that is actually emitted appears to be '(null)', which is less helpful in comparison. Even more unfortunately, this is biting us on every single kernel build with a new gas, because arch/arm/boot/compressed/head.S and some other files in that directory are built with -march=all since kernel commit 80cec14 "[ARM] Add -march=all to assembly file build in arch/arm/boot/compressed" back in v2.6.28. This patch reverts Russell's nice solution and replaces it with a more complex one that sprinkles .arch statements inside of the head.S file in functions that are executed in different architecture levels, which seems to solve the original problem just as well, and gets rid of the new one, too. Without this patch, building anything results in: arch/arm/boot/compressed/head.S: Assembler messages: arch/arm/boot/compressed/head.S:565: Warning: (null) arch/arm/boot/compressed/head.S:676: Warning: (null) arch/arm/boot/compressed/head.S:698: Warning: (null) arch/arm/boot/compressed/head.S:722: Warning: (null) arch/arm/boot/compressed/head.S:726: Warning: (null) arch/arm/boot/compressed/head.S:957: Warning: (null) arch/arm/boot/compressed/head.S:996: Warning: (null) arch/arm/boot/compressed/head.S:997: Warning: (null) arch/arm/boot/compressed/head.S:1027: Warning: (null) arch/arm/boot/compressed/head.S:1035: Warning: (null) arch/arm/boot/compressed/head.S:1046: Warning: (null) arch/arm/boot/compressed/head.S:1060: Warning: (null) arch/arm/boot/compressed/head.S:1092: Warning: (null) arch/arm/boot/compressed/head.S:1094: Warning: (null) arch/arm/boot/compressed/head.S:1095: Warning: (null) arch/arm/boot/compressed/head.S:1102: Warning: (null) arch/arm/boot/compressed/head.S:1134: Warning: (null) Signed-off-by: Arnd Bergmann <[email protected]> Cc: Matthew Gretton-Dann <[email protected]> Cc: Russell King <[email protected]> Signed-off-by: Paul Beeler <[email protected]>
Signed-off-by: kecinzer <[email protected]>
Signed-off-by: kecinzer <[email protected]>
CAF patch updated board file for 8064 but LGE split the files and the update was not applied to mako board Signed-off-by: faux123 <[email protected]>
Signed-off-by: faux123 <[email protected]>
Signed-off-by: faux123 <[email protected]>
Fully GPL'ed version. Signed-off-by: faux123 <[email protected]> Conflicts: sound/soc/codecs/Kconfig sound/soc/codecs/Makefile Conflicts: sound/soc/codecs/wcd9310.c
bump version to 2.1 to reflec this new addition Signed-off-by: Paul Reioux <[email protected]>
Signed-off-by: Paul Reioux <[email protected]> Conflicts: sound/soc/codecs/wcd9310.c
This is first official GPL release based on my private implementation. This release has been tested for Mako and Flo officially. It may work with other devices using the same WCD9310 Audio Codec as well, but not tested Signed-off-by: Paul Reioux <[email protected]>
Signed-off-by: Stratos Karafotis <[email protected]>
Signed-off-by: Stratos Karafotis <[email protected]>
…ature Probably bootloader in 4.3 does not pass the correct command line to the kernel to initialize LCD color temperature values during fastboot boot command. It should pass "lge.kcal=0|0|0|x" value. Use default values to work around the issue. Thanks @mskip from XDA for reporting this. Signed-off-by: Stratos Karafotis <[email protected]>
__fls(mask) is equivalent to find_last_bit(&mask, BITS_PER_LONG), but cheaper. find_last_bit was showing up high on the list when I was profiling for stalls on icache misses on a system with very small cache size (MIPS). Signed-off-by: Felix Fietkau <[email protected]>
Fix possible memory leak detected by kmemleak:
unreferenced object 0xc0f80f00 (size 64):
comm "swapper/0", pid 1, jiffies 4294937508 (age 82.980s)
hex dump (first 32 bytes):
6d 6d 63 30 5f 64 65 74 65 63 74 00 72 79 2e 68 mmc0_detect.ry.h
00 07 00 00 68 77 63 61 70 2e 68 00 02 00 00 70 ....hwcap.h....p
backtrace:
[<c010a1fc>] __kmalloc+0x164/0x220
[<c01e1630>] kvasprintf+0x38/0x58
[<c01e1668>] kasprintf+0x18/0x24
[<c02fcf60>] mmc_alloc_host+0x114/0x1b4
[<c0311c84>] msmsdcc_probe+0xc14/0x1fd8
[<c022b40c>] platform_drv_probe+0x14/0x18
[<c022a144>] driver_probe_device+0x144/0x334
[<c022a394>] __driver_attach+0x60/0x84
[<c022884c>] bus_for_each_dev+0x4c/0x78
[<c0229720>] bus_add_driver+0xd0/0x250
[<c022a884>] driver_register+0x9c/0x128
[<c00086bc>] do_one_initcall+0x90/0x160
[<c06d1904>] kernel_init+0xe8/0x1a4
[<c000ee4c>] kernel_thread_exit+0x0/0x8
[<ffffffff>] 0xffffffff
Change-Id: I3b29d71463af849a072cabbe56637adf6db6d0da
Signed-off-by: Sujit Reddy Thumma <[email protected]>
Currently, the card state is not being set as removed, even when the card is actually removed. We still wait for the next request to fail and then check the error and set the card to be removed. With the new runtime-pm in place, the card device would be removed on physical removal of card and the corresponding parent would be suspended as well. Hence, when the queue is flushed during clean-up, mmc_rpm_hold would be invoked, which would fail, since the runtime-pm was disabled when the card device was removed. Thus, it won't resume the card/host/ platform device. The request would continue and since the controller is in suspended state nasty things would happen. This patch sets the card as removed during mmc_sd_detect itself, so that when a clean-up of queue happens during card removal, it is known that the card has been removed and the request is errored out there itself. Change-Id: Id5022f8d7db43750edf137d4293796615b56ae36 Signed-off-by: Asutosh Das <[email protected]>
The commit fd6681cd4d0782f6e6ac918ab337016f59c2520b introduced a silent bug that incorrectly checks state of the clock while setting the next timer event. The bug manifests only during failure code path of msm idle operation, which is very rare. Due to the bug, the driver isn't be able to reprogram the timer device. CRs-fixed: 468902 Change-Id: I4ec14ea9c3a5d318ef98d2b13bd55efd89538df5 Signed-off-by: Jay Chokshi <[email protected]> Signed-off-by: Ajay Dudani <[email protected]>
An inactive timer's base can refer to a offline cpu's base. In the current code, cpu_base's lock is blindly reinitialized each time a CPU is brought up. If a CPU is brought online during the period that another thread is trying to modify an inactive timer on that CPU with holding its timer base lock, then the lock will be reinitialized under its feet. This leads to following SPIN_BUG(). <0> BUG: spinlock already unlocked on CPU#3, kworker/u:3/1466 <0> lock: 0xe3ebe000, .magic: dead4ead, .owner: kworker/u:3/1466, .owner_cpu: 1 <4> [<c0013dc4>] (unwind_backtrace+0x0/0x11c) from [<c026e794>] (do_raw_spin_unlock+0x40/0xcc) <4> [<c026e794>] (do_raw_spin_unlock+0x40/0xcc) from [<c076c160>] (_raw_spin_unlock+0x8/0x30) <4> [<c076c160>] (_raw_spin_unlock+0x8/0x30) from [<c009b858>] (mod_timer+0x294/0x310) <4> [<c009b858>] (mod_timer+0x294/0x310) from [<c00a5e04>] (queue_delayed_work_on+0x104/0x120) <4> [<c00a5e04>] (queue_delayed_work_on+0x104/0x120) from [<c04eae00>] (sdhci_msm_bus_voting+0x88/0x9c) <4> [<c04eae00>] (sdhci_msm_bus_voting+0x88/0x9c) from [<c04d8780>] (sdhci_disable+0x40/0x48) <4> [<c04d8780>] (sdhci_disable+0x40/0x48) from [<c04bf300>] (mmc_release_host+0x4c/0xb0) <4> [<c04bf300>] (mmc_release_host+0x4c/0xb0) from [<c04c7aac>] (mmc_sd_detect+0x90/0xfc) <4> [<c04c7aac>] (mmc_sd_detect+0x90/0xfc) from [<c04c2504>] (mmc_rescan+0x7c/0x2c4) <4> [<c04c2504>] (mmc_rescan+0x7c/0x2c4) from [<c00a6a7c>] (process_one_work+0x27c/0x484) <4> [<c00a6a7c>] (process_one_work+0x27c/0x484) from [<c00a6e94>] (worker_thread+0x210/0x3b0) <4> [<c00a6e94>] (worker_thread+0x210/0x3b0) from [<c00aad9c>] (kthread+0x80/0x8c) <4> [<c00aad9c>] (kthread+0x80/0x8c) from [<c000ea80>] (kernel_thread_exit+0x0/0x8) As an example, this particular crash occurred when CPU franciscofranco#3 is executing mod_timer() on an inactive timer whose base is refered to offlined CPU franciscofranco#2. The code locked the timer_base corresponding to CPU franciscofranco#2. Before it could proceed, CPU franciscofranco#2 came online and reinitialized the spinlock corresponding to its base. Thus now CPU franciscofranco#3 held a lock which was reinitialized. When CPU franciscofranco#3 finally ended up unlocking the old cpu_base corresponding to CPU franciscofranco#2, we hit the above SPIN_BUG(). CPU #0 CPU franciscofranco#3 CPU franciscofranco#2 ------ ------- ------- ..... ...... <Offline> mod_timer() lock_timer_base spin_lock_irqsave(&base->lock) cpu_up(2) ..... ...... init_timers_cpu() .... ..... spin_lock_init(&base->lock) ..... spin_unlock_irqrestore(&base->lock) ...... <spin_bug> Allocation of per_cpu timer vector bases is done only once under "tvec_base_done[]" check. In the current code, spinlock_initialization of base->lock isn't under this check. When a CPU is up each time the base lock is reinitialized. Move base spinlock initialization under the check. Change-Id: I73b48440fffb227a60af9180e318c851048530dd Signed-off-by: Tirupathi Reddy <[email protected]> Signed-off-by: Ajay Dudani <[email protected]>
Cleanup of IPC gpios for driver strength and toggle AP2MDM_STATUS only after AP2MDM_KPD_PWR is toggled, this will decrease the leakage from MSM to QSC before QSC powering up. CRs-Fixed: 460500 Change-Id: Iabfa34331b613dd66577e485572a809440cf5272 Signed-off-by: Taniya Das <[email protected]> modified for Mako use Signed-off-by: Paul Reioux <[email protected]>
Signed-off-by: Paul Reioux <[email protected]>
…o fix the length of the governor name for the sysfs entry. Signed-off-by: Francisco Franco <[email protected]>
Signed-off-by: kecinzer <[email protected]>
Add processor info for the Qualcomm, Inc. Krait family of processors, to use the generic ARMv7 initialisation procedure but explicitly enable the IDIV hardware capability flag. Change-Id: I080f60189fada2e4f87c79c6b8ef522cdc070759 Signed-off-by: Stepan Moskovchenko <[email protected]>
This hashtable implementation is using hlist buckets to provide a simple hashtable to prevent it from getting reimplemented all over the kernel. Signed-off-by: Sasha Levin <[email protected]> [ Merging this now, so that subsystems can start applying Sasha's patches that use this - Linus ] Signed-off-by: Linus Torvalds <[email protected]>
Switch elevator to use the new hashtable implementation. This reduces the
amount of generic unrelated code in the elevator.
This also removes the dymanic allocation of the hash table. The size of the table is
constant so there's no point in paying the price of an extra dereference when accessing
it.
This patch depends on d9b482c ("hashtable: introduce a small and naive
hashtable") which was merged in v3.6.
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
A process waiting on a signal can be awaken by any signal. We need to only continue processing when the condition of the wait event is met. Change-Id: Ib2102babbb505876f89b04399729e6ff5a475605 Signed-off-by: Mona Hossain <[email protected]> Signed-off-by: Praveen Chavan <[email protected]>
Many clocks that are used to provide sched_clock will reset during suspend. If read_sched_clock returns 0 after suspend, sched_clock will appear to jump forward. This patch resets cd.epoch_cyc to the current value of read_sched_clock during resume, which causes sched_clock() just after suspend to return the same value as sched_clock() just before suspend. In addition, during the window where epoch_ns has been updated before suspend, but epoch_cyc has not been updated after suspend, it is unknown whether the clock has reset or not, and sched_clock() could return a bogus value. Add a suspended flag, and return the pre-suspend epoch_ns value during this period. The new behavior is triggered by calling setup_sched_clock_needs_suspend instead of setup_sched_clock. Change-Id: I7441ef74dc6802c00eea61f3b8c0a25ac00a724d Signed-off-by: Colin Cross <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Russell King <[email protected]> CRs-Fixed: 497236 Git-commit: 237ec6f2e51d2fc2ff37c7c5f1ccc9264d09c85b Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Signed-off-by: Srivatsa Vaddagiri <[email protected]> Signed-off-by: Francisco Franco <[email protected]>
The scheduler imposes a requirement to sched_clock() which is to stop the clock during suspend, if we don't do that any RT thread will be rescheduled in the future which might cause any sort of problems. This became an issue on OMAP when we converted omap-i2c.c to use threaded IRQs, it turned out that depending on how much time we spent on suspend, the I2C IRQ thread would end up being rescheduled so far in the future that I2C transfers would timeout and, because omap_hsmmc depends on an I2C-connected device to detect if an MMC card is inserted in the slot, our rootfs would just vanish. arch/arm/kernel/sched_clock.c already had an optional implementation (sched_clock_needs_suspend()) which would handle scheduler's requirement properly, what this patch does is simply to make that implementation non-optional. Note that this has the side-effect that printk timings won't reflect the actual time spent on suspend so other methods to measure that will have to be used. This has been tested with beagleboard XM (OMAP3630) and pandaboard rev A3 (OMAP4430). Suspend to RAM is now working after this patch. Thanks to Kevin Hilman for helping out with debugging. Change-Id: Ie2f9e3b22eb3d1f3806cf8c598f22e2fa1b8651f Acked-by: Kevin Hilman <[email protected]> Acked-by: Linus Walleij <[email protected]> Signed-off-by: Felipe Balbi <[email protected]> Signed-off-by: Russell King <[email protected]> CRs-Fixed: 497236 Git-commit: 6a4dae5e138a32b45ca5218cc2b81802f9d378c3 Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Signed-off-by: Srivatsa Vaddagiri <[email protected]> Signed-off-by: Francisco Franco <[email protected]>
There is a small race between when the cycle count is read from
the hardware and when the epoch stabilizes. Consider this
scenario:
CPU0 CPU1
---- ----
cyc = read_sched_clock()
cyc_to_sched_clock()
update_sched_clock()
...
cd.epoch_cyc = cyc;
epoch_cyc = cd.epoch_cyc;
...
epoch_ns + cyc_to_ns((cyc - epoch_cyc)
The cyc on cpu0 was read before the epoch changed. But we
calculate the nanoseconds based on the new epoch by subtracting
the new epoch from the old cycle count. Since epoch is most likely
larger than the old cycle count we calculate a large number that
will be converted to nanoseconds and added to epoch_ns, causing
time to jump forward too much.
Fix this problem by reading the hardware after the epoch has
stabilized.
Change-Id: I995133b229b2c2fedd5091406d1dc366d8bfff7b
Cc: Russell King <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Git-commit: 336ae1180df5f69b9e0fb6561bec01c5f64361cf
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[sboyd: reworked for file movement kernel/time -> arm/kernel]
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Francisco Franco <[email protected]>
We see negative idle stats because of cpu dying without cleaning up idle entry statistics. When a cpu is offline, the most immediate thing you'd want to do is just call into cpu_die() and not waste time calling notifier(IDLE_START). CRs-Fixed: 414554 Change-Id: Iadc6a3ca39997e0ccf65d2a29b004e24b1b211a1 Signed-off-by: Srivatsa Vaddagiri <[email protected]> Signed-off-by: Taniya Das <[email protected]> Signed-off-by: Francisco Franco <[email protected]>
commit 9ecc39cd (EHCI: HSIC: Implement new reset sequence to workaround PHY lockup issue) does not halt controller before proceeding to reset sequence. If the controller is not halted and SOFs are transmitted, PHY may stuck during port reset. CRs-Fixed: 459280 Change-Id: I213ca7d41420596b91eb9b5e6803d1e237167136 Signed-off-by: Pavankumar Kondeti <[email protected]> Signed-off-by: Francisco Franco <[email protected]>
…of usb suspend to 2 second. Avoid the modem suspend/resume frequently. b/9911201 Change-Id: I0872f894c450b697bb2f0e05fc97c6ed0731b36a Signed-off-by: yi-hsin_hung <[email protected]> (cherry picked from commit 3aceb26a7e3f96ce03bc748fa271bb32b979ae87) Signed-off-by: Francisco Franco <[email protected]>
Signed-off-by: Francisco Franco <[email protected]>
…ld delta to 5ºC after the device is throttled. Signed-off-by: Francisco Franco <[email protected]>
In various network workloads, __do_softirq() latencies can be up to 20 ms if HZ=1000, and 200 ms if HZ=100. This is because we iterate 10 times in the softirq dispatcher, and some actions can consume a lot of cycles. This patch changes the fallback to ksoftirqd condition to : - A time limit of 2 ms. - need_resched() being set on current task When one of this condition is met, we wakeup ksoftirqd for further softirq processing if we still have pending softirqs. Using need_resched() as the only condition can trigger RCU stalls, as we can keep BH disabled for too long. I ran several benchmarks and got no significant difference in throughput, but a very significant reduction of latencies (one order of magnitude) : In following bench, 200 antagonist "netperf -t TCP_RR" are started in background, using all available cpus. Then we start one "netperf -t TCP_RR", bound to the cpu handling the NIC IRQ (hard+soft) Before patch : # netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind RT_LATENCY=550110.424 MIN_LATENCY=146858 MAX_LATENCY=997109 P50_LATENCY=305000 P90_LATENCY=550000 P99_LATENCY=710000 MEAN_LATENCY=376989.12 STDDEV_LATENCY=184046.92 After patch : # netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind RT_LATENCY=40545.492 MIN_LATENCY=9834 MAX_LATENCY=78366 P50_LATENCY=33583 P90_LATENCY=59000 P99_LATENCY=69000 MEAN_LATENCY=38364.67 STDDEV_LATENCY=12865.26 Signed-off-by: Eric Dumazet <[email protected]> Cc: David Miller <[email protected]> Cc: Tom Herbert <[email protected]> Cc: Ben Hutchings <[email protected]> Signed-off-by: David S. Miller <[email protected]>
The reset value of the BCR, BVR, WCR, and WVR registers are all UNKNOWN on ARMv7. Unfortunately, reset_ctrl_regs() clears these registers *after* enabling monitor mode, not before, and so some implementations may experience UNPREDICTABLE behavior if the reset values of these registers are non-zero. Clear the breakpoints before enabling monitor mode so that we don't experience boot hangs/loops due to breakpoints being enabled out of reset. Change-Id: I029fbe40725e803183544ddd6fe40285de4137e8 Signed-off-by: Stephen Boyd <[email protected]>
HAVE_HW_BREAKPOINT was disabled temporarily from commit 480a82f. Issue not seen with the latest kernel hence re-enable the feature and fix merge issue from previous kernel upgrade. Change-Id: Ia6e7e8282c848dd73108e4d951b3375bb7caa63c Signed-off-by: Jin Hong <[email protected]> Signed-off-by: Taniya Das <[email protected]>
Signed-off-by: Francisco Franco <[email protected]>
…apping the display or swipping from wherever you want. The device deep sleeps but the digitizer is still powered on, otherwise it couldn't detect touch events. Battery usage should be little to minimal, but I haven't ran any numbers. Signed-off-by: Francisco Franco <[email protected]>
Signed-off-by: Francisco Franco <[email protected]>
|
why? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.