Patch 1 #2
Open
Patch 1 #2
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
This reverts commit a315348.
… be replaced with an Atrix-appropriate CONFIG_CMDLINE, if CONFIG_CMDLINE_PREPEND_ATRIX=y (which should contain the proper mem=,nvmem=,vmalloc=). This way, even though the unlockable international bootloader passes the wrong mem=, we can hack it in .config, and still not need boot.img unique for each tegrapart, since we now inherit the rest of cmdline from bootloader.
…ings" Heap memory not initialized yet. DOH! This reverts commit 3518c49.
RWSEM implementation for ARM using atomic functions. Heavily based on arch/sh/include/asm/rwsem.h Signed-off-by: Ashwin Chaugule <ashwinc@codeaurora.org>
The spinlock used in the do_IPI function is declared in per_cpu section, and it does not have the cache snooping which can cause the spinlock failure. This fix is based on the main kernel tree: - ARM: SMP: avoid using bitmasks and locks for IPIs, use hardware instead commit 24480d9 - ARM: SMP: remove IRQ-disabling for smp_cross_call() commit 0df7095 BUG 798775 Change-Id: I6e03027cb3f586803a260e216c71fc2fd74d09f2 Reviewed-on: http://git-master/r/23779 Reviewed-by: Xin Xie <xxie@nvidia.com> Tested-by: Xin Xie <xxie@nvidia.com> Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
Taken from the p999's v21e drop
The cache controller will stop its clock when idle after several clock cycles. Change-Id: Ifc9997d4e7fd4f1e3c6129bac2fd42f8995a069e Signed-off-by: Todd Poynor <toddpoynor@google.com>
Tegra 2.6.36 code needs to restore PL310 dynamic clock gating upon resume from a power event. As of 2.6.39 the PL310 is re-init'ed from scratch upon resume, and this patch can be dropped. Change-Id: I8c1fb1add3c3cfcffff58fab642b84d8d5a7a90a Signed-off-by: Todd Poynor <toddpoynor@google.com>
An earlier fix for a race resulted in a situation where the CPUs other than the CPU that detected the end of the grace period would not process their callbacks until the next grace period started. This means that these other CPUs would unnecessarily demand that an extra grace period be started. This patch eliminates this extra grace period and speeds callback processing by propagating rsp->completed to the rcu_node structures in the case where the CPU detecting the end of the grace period sees no reason to start a new grace period. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: laijs@cn.fujitsu.com Cc: dipankar@in.ibm.com Cc: mathieu.desnoyers@polymtl.ca Cc: josh@joshtriplett.org Cc: dvhltc@us.ibm.com Cc: niv@us.ibm.com Cc: peterz@infradead.org Cc: rostedt@goodmis.org Cc: Valdis.Kletnieks@vt.edu Cc: dhowells@redhat.com LKML-Reference: <1258094104417-git-send-email-> Signed-off-by: Ingo Molnar <mingo@elte.hu>
…kins. However, lookup2() is outdated as Bob wrote a new hash function called lookup3(). The new hash function - mixes better than lookup2(): it passes the check that every input bit changes every output bit 50% of the time, while lookup2() failed it. - performs better: compiled with -O2 on Core2 Duo, lookup3() is 20-40% faster than lookup2() depending on the key length. The patch replaces the lookup2() implementation of the 'jhash*' functions with that of lookup3() in linux/jhash.h. You can read a longer comparison of the Jenkins and other hash functions at http://burtleburtle.net/bob/hash/doobs.html. Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
frequency by copying policy from sibling CPU and save the policy to percpu policy saved data as well for Power Management hotplugs
Bug 760630 Change-Id: If5e4ac1045cdb46d12a03bf47f24fb712fdbd11e Reviewed-on: http://git-master/r/11632 Reviewed-by: Niket Sirsi <nsirsi@nvidia.com> Tested-by: Niket Sirsi <nsirsi@nvidia.com>
Bug 753226 Change-Id: I34e9e392580b38d4ebf805ce984a800097adf09a Reviewed-on: http://git-master/r/11527 Tested-by: Aleksandr Frid <afrid@nvidia.com> Reviewed-by: Narendra Damahe <ndamahe@nvidia.com> Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com>
Since core power partition can be un-gated at low voltage - e.g., on exit from LP1, disable partition clocks before de-asserting reset (instead of disabling clocks immediately after reset is de-asserted). Change-Id: Ic56685186d14525fcc1fca1c933e90b7879e7b6c Reviewed-on: http://git-master/r/10199 Tested-by: Aleksandr Frid <afrid@nvidia.com> Reviewed-by: Narendra Damahe <ndamahe@nvidia.com> Tested-by: Narendra Damahe <ndamahe@nvidia.com> Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com>
irq_pm_syscore_resume is only available iff CONFIG_PM_SLEEP (kernel/irq/pm.o is only built if this is true). Move the definition (and the dummy definition) under that umbrella. Introduced by the backport of upstream 9bab0b7fbaceec47d32db51cd9e59c82fb071f5a as 0f12a6ad9fa3a03f2bcee36c9cb704821e244c40. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Reported-by: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de> Reported-by: Antoine Martin <antoine@nagafix.co.uk>
Atrix's DHD wifi module is not compatible with the new PM scheme introduced in 2.6.32.40. This patch will cause a null pointer exception when mmc module is awaken from PM suspend. The null pointer exception will eventually lead to a kernel panic which causes an instant reboot of the system.
(backport from common android-3.0 commit: 692e468137ebb2a31431c4b3fad1dca0a2da7659) It was using ANDROID_ALARM_ELAPSED_REALTIME_WAKEUP_MASK as an index. Change-Id: I919860cc71254453e382616bce9fd5455802cb3d Signed-off-by: JP Abgrall <jpa@google.com>
If the wakelock driver aborts suspend due to an already-held wakelock, don't report the next wakelock held as the "wake up wakelock". Change-Id: I582ffbb87a3c361739a77d839a0c62921cff11a6 Signed-off-by: Todd Poynor <toddpoynor@google.com>
It improves perfomance, especially if autogroup enabled. The size of set_task_rq() was 0x180 and now it is 0xa0. Signed-off-by: Andrew Vagin <avagin@openvz.org>
LOAD_FREQ is (5*HZ+1) to avoid high load average when idle: http://kerneltrap.org/mailarchive/linux-kernel/2007/10/3/328568 I suggest (4*HZ+61) for a better distribution. With some seconds based load (like SSL heartbeats) and LOAD_FREQ at (5*HZ+1) I see Moire patterns like inverse sawtooth, since 2 or 3 probes hit the jobs (load increases quickly), followed by several probes missing it. A 4.61 sec interval gives optimal distribution over when within a second a probe is taken, as .61 is close to golden ratio phi 1.618... (test in http://ripke.com/goldenratio.c). 12*4.61 = 55.32 secs is still close to a minute, and 13*4.61=59.93 is even closer than the current 12*5.01=60.12 (with exponents EXP_x adjusted to a ratio of 13 instead of 12).
As part of mode sense CBW command, communicate to the host that write cache support is enabled and due to this during the write commnd, the host is asking for FUA and because of this write performance is degrading. Hence during mode sense command, intimate the host that write cache is not supported. (cherry picked from commit a2da2c47967c3f80a7127b0c698aae300b9c5b91) Change-Id: I6ec66ff11181eeb70d62d31b7ddfbbf87880a885 CRs-Fixed: 278310 Signed-off-by: Chiranjeevi Velempati <cvelempa@codeaurora.org>
With the rapidly increasing number of intelligent multi-contact and multi-user devices, the need to send digested, filtered information from a set of different sources within the same device is imminent. This patch adds the concept of slots to the MT protocol. The slots enumerate a set of identified sources, such that all MT events can be passed independently and selectively per identified source. The protocol works like this: Instead of sending a SYN_MT_REPORT event immediately after the contact data, one sends an ABS_MT_SLOT event immediately before the contact data. The input core will only emit events for slots with modified MT events. It is assumed that the same slot is used for the duration of an initiated contact. Acked-by: Ping Cheng <pingc@wacom.com> Acked-by: Chase Douglas <chase.douglas@canonical.com> Acked-by: Rafi Rubin <rafi@seas.upenn.edu> Signed-off-by: Henrik Rydberg <rydberg@euromail.se> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
In preparation for common code to handle a larger set of MT slots devices, move the slots handling over to a separate file. Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
Touch devices capable of hovering, i.e., fingers detected a distance from the surface, are not supported by the current input MT protocol. This patch adds ABS_MT_DISTANCE, which may be used to indicate the distance between the contact and the surface. Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
Today, userspace sets up an input device based on the data it emits. This is not always enough; a tablet and a touchscreen may emit exactly the same data, for instance, but the former should be set up with a pointer whereas the latter does not need to. Recently, a new type of touchpad has emerged where the buttons are under the pad, which changes logic without changing the emitted data. This patch introduces a new ioctl, EVIOCGPROP, which enables user access to a set of device properties useful during setup. The properties are given as a bitmap in the same fashion as the event types, and are also made available via sysfs, uevent and /proc/bus/input/devices. Acked-by: Ping Cheng <pingc@wacom.com> Acked-by: Chase Douglas <chase.douglas@canonical.com> Acked-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
From: Ming Lei <tom.leiming@gmail.com> This patch removes the lockdep warning[1] on ARM platform. The warning is caused by printk inside smp_setup_processor_id. It is safe to do this because lockdep_init doesn't depend on smp_setup_processor_id, so make printk can be called as early as possible without lockdep complainment. [1], lockdep warning [ 0.000000] WARNING: lockdep init error! Arch code didn't call lockdep_init() early enough? [ 0.000000] Call stack leading to lockdep invocation was: [ 0.000000] [<c00164bc>] save_stack_trace_tsk+0x0/0x90 [ 0.000000] [<ffffffff>] 0xffffffff Signed-off-by: Ming Lei <tom.leiming@gmail.com>
From: Ming Lei <tom.leiming@gmail.com> This patch prints the name of the lock which is acquired before lockdep_init is called, so that user can easily find which lock trigged the lockdep init error warning. This patch also removes the lockdep_init_error message of "Arch code didn't call lockdep_init() early enough?" since lockdep_init is called in arch independent code now. Signed-off-by: Ming Lei <tom.leiming@gmail.com>
If either of the vas or vms arrays are not properly kzalloced, then the code jumps to the err_free label. The err_free label runs a loop to check and free each of the array members of the vas and vms arrays which is not required for this situation as none of the array members have been allocated till this point. Eliminate the extra loop we have to go through by introducing a new label err_free2 and then jumping to it. Signed-off-by: Kautuk Consul <consul.kautuk@gmail.com>
A pair of missing braces inside the state_store() function causes even invalid arguments to suspend to be wrongly treated as failed suspend attempts. Fix this. Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Linus reports a _really_ small & slow (505kB, 15kB/s) USB device,
on which blkid runs unpleasantly slow. He manages to optimize the blkid
reads down to 1kB+16kB, but still kernel read-ahead turns it into 48kB.
lseek 0, read 1024 => readahead 4 pages (start of file)
lseek 1536, read 16384 => readahead 8 pages (page contiguous)
The readahead heuristics involved here are reasonable ones in general.
So it's good to fix blkid with fadvise(RANDOM), as Linus already did.
For the kernel part, Linus suggests:
So maybe we could be less aggressive about read-ahead when the size of
the device is small? Turning a 16kB read into a 64kB one is a big deal,
when it's about 15% of the whole device!
This looks reasonable: smaller device tend to be slower (USB sticks as
well as micro/mobile/old hard disks).
Given that the non-rotational attribute is not always reported, we can
take disk size as a max readahead size hint. This patch uses a formula
that generates the following concrete limits:
disk size readahead size
(scale by 4) (scale by 2)
1M 8k
4M 16k
16M 32k
64M 64k
256M 128k
--------------------------- (*)
1G 256k
4G 512k
16G 1024k
64G 2048k
256G 4096k
(*) Since the default readahead size is 128k, this limit only takes
effect for devices whose size is less than 256M.
The formula is determined on the following data, collected by script:
#!/bin/sh
# please make sure BDEV is not mounted or opened by others
BDEV=sdb
for rasize in 4 16 32 64 128 256 512 1024 2048 4096 8192
do
echo $rasize > /sys/block/$BDEV/queue/read_ahead_kb
time dd if=/dev/$BDEV of=/dev/null bs=4k count=102400
done
The principle is, the formula shall not limit readahead size to such a
degree that will impact some device's sequential read performance.
The Intel SSD is special in that its throughput increases steadily with
larger readahead size. However it may take years for Linux to increase
its default readahead size to 2MB, so we don't take it seriously in the
formula.
SSD 80G Intel x25-M SSDSA2M080 (reported by Li Shaohua)
rasize 1st run 2nd run
----------------------------------
4k 123 MB/s 122 MB/s
16k 153 MB/s 153 MB/s
32k 161 MB/s 162 MB/s
64k 167 MB/s 168 MB/s
128k 197 MB/s 197 MB/s
256k 217 MB/s 217 MB/s
512k 238 MB/s 234 MB/s
1M 251 MB/s 248 MB/s
2M 259 MB/s 257 MB/s
==> 4M 269 MB/s 264 MB/s
8M 266 MB/s 266 MB/s
Note that ==> points to the readahead size that yields plateau throughput.
SSD 22G MARVELL SD88SA02 MP1F (reported by Jens Axboe)
rasize 1st 2nd
--------------------------------
4k 41 MB/s 41 MB/s
16k 85 MB/s 81 MB/s
32k 102 MB/s 109 MB/s
64k 125 MB/s 144 MB/s
128k 183 MB/s 185 MB/s
256k 216 MB/s 216 MB/s
512k 216 MB/s 236 MB/s
1024k 251 MB/s 252 MB/s
2M 258 MB/s 258 MB/s
==> 4M 266 MB/s 266 MB/s
8M 266 MB/s 266 MB/s
SSD 30G SanDisk SATA 5000
4k 29.6 MB/s 29.6 MB/s 29.6 MB/s
16k 52.1 MB/s 52.1 MB/s 52.1 MB/s
32k 61.5 MB/s 61.5 MB/s 61.5 MB/s
64k 67.2 MB/s 67.2 MB/s 67.1 MB/s
128k 71.4 MB/s 71.3 MB/s 71.4 MB/s
256k 73.4 MB/s 73.4 MB/s 73.3 MB/s
==> 512k 74.6 MB/s 74.6 MB/s 74.6 MB/s
1M 74.7 MB/s 74.6 MB/s 74.7 MB/s
2M 76.1 MB/s 74.6 MB/s 74.6 MB/s
USB stick 32G Teclast CoolFlash idVendor=1307, idProduct=0165
4k 7.9 MB/s 7.9 MB/s 7.9 MB/s
16k 17.9 MB/s 17.9 MB/s 17.9 MB/s
32k 24.5 MB/s 24.5 MB/s 24.5 MB/s
64k 28.7 MB/s 28.7 MB/s 28.7 MB/s
128k 28.8 MB/s 28.9 MB/s 28.9 MB/s
==> 256k 30.5 MB/s 30.5 MB/s 30.5 MB/s
512k 30.9 MB/s 31.0 MB/s 30.9 MB/s
1M 31.0 MB/s 30.9 MB/s 30.9 MB/s
2M 30.9 MB/s 30.9 MB/s 30.9 MB/s
USB stick 4G SanDisk Cruzer idVendor=0781, idProduct=5151
4k 6.4 MB/s 6.4 MB/s 6.4 MB/s
16k 13.4 MB/s 13.4 MB/s 13.2 MB/s
32k 17.8 MB/s 17.9 MB/s 17.8 MB/s
64k 21.3 MB/s 21.3 MB/s 21.2 MB/s
128k 21.4 MB/s 21.4 MB/s 21.4 MB/s
==> 256k 23.3 MB/s 23.2 MB/s 23.2 MB/s
512k 23.3 MB/s 23.8 MB/s 23.4 MB/s
1M 23.8 MB/s 23.4 MB/s 23.3 MB/s
2M 23.4 MB/s 23.2 MB/s 23.4 MB/s
USB stick 2G idVendor=0204, idProduct=6025 SerialNumber: 08082005000113
4k 6.7 MB/s 6.9 MB/s 6.7 MB/s
16k 11.7 MB/s 11.7 MB/s 11.7 MB/s
32k 12.4 MB/s 12.4 MB/s 12.4 MB/s
64k 13.4 MB/s 13.4 MB/s 13.4 MB/s
128k 13.4 MB/s 13.4 MB/s 13.4 MB/s
==> 256k 13.6 MB/s 13.6 MB/s 13.6 MB/s
512k 13.7 MB/s 13.7 MB/s 13.7 MB/s
1M 13.7 MB/s 13.7 MB/s 13.7 MB/s
2M 13.7 MB/s 13.7 MB/s 13.7 MB/s
64 MB, USB full speed (collected by Clemens Ladisch)
Bus 003 Device 003: ID 08ec:0011 M-Systems Flash Disk Pioneers DiskOnKey
4KB: 139.339 s, 376 kB/s
16KB: 81.0427 s, 647 kB/s
32KB: 71.8513 s, 730 kB/s
==> 64KB: 67.3872 s, 778 kB/s
128KB: 67.5434 s, 776 kB/s
256KB: 65.9019 s, 796 kB/s
512KB: 66.2282 s, 792 kB/s
1024KB: 67.4632 s, 777 kB/s
2048KB: 69.9759 s, 749 kB/s
An unnamed SD card (Yakui):
4k 195.873 s, 5.5 MB/s
8k 123.425 s, 8.7 MB/s
16k 86.6425 s, 12.4 MB/s
32k 66.7519 s, 16.1 MB/s
==> 64k 58.5262 s, 18.3 MB/s
128k 59.3847 s, 18.1 MB/s
256k 59.3188 s, 18.1 MB/s
512k 59.0218 s, 18.2 MB/s
CC: Li Shaohua <shaohua.li@intel.com>
CC: Clemens Ladisch <clemens@ladisch.de>
Acked-by: Jens Axboe <jens.axboe@oracle.com>
Acked-by: Rik van Riel <riel@redhat.com>
Tested-by: Vivek Goyal <vgoyal@redhat.com>
Tested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
fixed frequency revert to power max freq when 2nd cpu is online
This reverts commit ff99333. Conflicts: arch/arm/kernel/traps.c
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.
Improve how second core is called if maxcpu is increased