- Added multiple ACM instance support in Android gadget
- Fixed multiple instance naming issue in ACM function
- Increased max instances from 4 to 8
Change-Id: I65f1b0be94da859bab7ec0ad7cd804b896c7c4c5
Signed-off-by: John Michelau <john.michelau@motorola.com>
capacitive proximity(cap-prox) calibration scheme to rule out
proximity detection due to some light conductive surfaces as device
covers and table-top.
Change-Id: I64d566a168befb82a610de6094044eeca294c6c4
Signed-off-by: makarand.karvekar <makarand.karvekar@motorola.com>
This governor is designed for latency-sensitive workloads, such as
interactive user interfaces. The interactive governor aims to be
significantly more responsive to ramp CPU quickly up when CPU-intensive
activity begins.
Existing governors sample CPU load at a particular rate, typically
every X ms. This can lead to under-powering UI threads for the period of
time during which the user begins interacting with a previously-idle system
until the next sample period happens.
The 'interactive' governor uses a different approach. Instead of sampling
the CPU at a specified rate, the governor will check whether to scale the
CPU frequency up soon after coming out of idle. When the CPU comes out of
idle, a timer is configured to fire within 1-2 ticks. If the CPU is very
busy from exiting idle to when the timer fires then we assume the CPU is
underpowered and ramp to MAX speed.
If the CPU was not sufficiently busy to immediately ramp to MAX speed, then
the governor evaluates the CPU load since the last speed adjustment,
choosing the highest value between that longer-term load or the short-term
load since idle exit to determine the CPU speed to ramp to.
A realtime thread is used for scaling up, giving the remaining tasks the
CPU performance benefit, unlike existing governors which are more likely to
schedule rampup work to occur after your performance starved tasks have
completed.
The tuneables for this governor are:
/sys/devices/system/cpu/cpufreq/interactive/min_sample_time:
The minimum amount of time to spend at the current frequency before
ramping down. This is to ensure that the governor has seen enough
historic CPU load data to determine the appropriate workload.
Default is 80000 uS.
/sys/devices/system/cpu/cpufreq/interactive/go_maxspeed_load
The CPU load at which to ramp to max speed. Default is 85.
Change-Id: Ib2b362607c62f7c56d35f44a9ef3280f98c17585
Signed-off-by: Mike Chan <mike@android.com>
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Bug: 3152864
Initial version of the NCT1008 driver to turn off the sensor when the
device is suspended. This improves standby current drain.
Change-Id: Ia64613c33c0052434d5e304c434605611e5ef789
Signed-off-by: Greg Meiste <w30289@motorola.com>
For backward compatibility with PTP, MTP is limited to a 32-bit file size.
When transferring files greater than 4 gig, MTP uses 0xFFFFFFFF as the file size
and the receiver reads until it receives a short packet.
Expanded size of mtp_file_range.length to 64 bits and added support for
writing zero length packets.
Signed-off-by: Mike Lockwood <lockwood@android.com>
wake-line gpio high puts touch uC in low-power mode.
fixed inconsistent irq disable in suspend when irq_enable
is skipped due to i2c failure.
Change-Id: I6a9fe011abdffad599da0b2897f3a976db10fff5
Signed-off-by: makarand.karvekar <makarand.karvekar@motorola.com>
The audio will now be routed to dock accesory when an accesory connected to
dock is detected.
Signed-off-by: Praveen Bharathi <pbharathi@motorola.com>
Signed-off-by: Iliyan Malchev <malchev@google.com>
Creates /dev/spdif_out and /dev/spdif_out_ctl for playback and control
settings. Playback is working.
Signed-off-by: Iliyan Malchev <malchev@google.com>
Commit 84061e0 fixed an accounting bug only to introduce the
possibility of a kernel OOPS if the journal has a non-zero j_errno
field indicating that the file system had detected a fs inconsistency.
After the journal replay, if the journal superblock indicates that the
file system has an error, this indication is transfered to the file
system and then ext4_commit_super() is called to write this to the
disk.
But since the percpu counters are now initialized after the journal
replay, the call to ext4_commit_super() will cause a kernel oops since
it needs to use the percpu counters the ext4 superblock structure.
The fix is to skip setting the ext4 free block and free inode fields
if the percpu counter has not been set.
Thanks to Ken Sumrall for reporting and analyzing the root causes of
this bug.
Addresses-Google-Bug: #3054080
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
We currently have a kernel internal type called aligned_u64 which aligns
__u64's on 8 bytes boundaries even on systems which would normally align
them on 4 byte boundaries. This patch creates a new type __aligned_u64
which does the same thing but which is exposed to userspace rather than
being kernel internal.
[akpm: merge early as both the net and audit trees want this]
[akpm@linux-foundation.org: enhance the comment describing the reasons for using aligned_u64. Via Andreas and Andi.]
Based-on-patch-by: Andreas Gruenbacher <agruen@suse.de>
Signed-off-by: Eric Paris <eparis@redhat.com>
Cc: Jan Engelhardt <jengelh@medozas.de>
Cc: David Miller <davem@davemloft.net>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Tony Luck reports that the addition of the access_ok() check in commit
0eead9ab41 ("Don't dump task struct in a.out core-dumps") broke the
ia64 compile due to missing the necessary header file includes.
Rather than add yet another include (<asm/unistd.h>) to make everything
happy, just uninline the silly core dump helper functions and move the
bodies to fs/exec.c where they make a lot more sense.
dump_seek() in particular was too big to be an inline function anyway,
and none of them are in any way performance-critical. And we really
don't need to mess up our include file headers more than they already
are.
Reported-and-tested-by: Tony Luck <tony.luck@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
akiphie points out that a.out core-dumps have that odd task struct
dumping that was never used and was never really a good idea (it goes
back into the mists of history, probably the original core-dumping
code). Just remove it.
Also do the access_ok() check on dump_write(). It probably doesn't
matter (since normal filesystems all seem to do it anyway), but he
points out that it's normally done by the VFS layer, so ...
[ I suspect that we should possibly do "vfs_write()" instead of
calling ->write directly. That also does the whole fsnotify and write
statistics thing, which may or may not be a good idea. ]
And just to be anal, do this all for the x86-64 32-bit a.out emulation
code too, even though it's not enabled (and won't currently even
compile)
Reported-by: akiphie <akiphie@lavabit.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-- Ignore kfifo thresholds on recording and playback and adjust the delays.
-- Take out the code from TEGRA_AUDIO_IN_STOP into a separate function
stop_recording_nosync()
-- Rename stop_recording() to wait_for_recording_to_stop().
-- add ioctl(TEGRA_AUDIO_OUT_FLUSH), which blocks the caller until the output
fifo is drained. While the caller is blocked, pending write() calls will
return immediately with whatever data they had managed to queue up.
-- removed ioctl(TEGRA_AUDIO_OUT_PRELOAD_FIFO)
-- since TEGRA_AUDIO_OUT_FLUSH and TEGRA_AUDIO_IN_STOP act similarly, moved
audio_driver_state::recording_cancelled to audio_stream::stop and changed
the code accordingly. Renamed functions wait_for_recording_to_stop() and
stop_recording_nosync() to wait_till_stopped() and request_stop_nosync()
since they handle both playback and recording.
-- print errors on close() if wakelocks are still held
-- Call request_stop_nosync() on close() of a recording file handle
-- Do not use struct audio_stream::active for playback streams. Instead,
where applicable, use kfifo_len(). As a consequence, playback kfifo
underruns are no longer reported. These were bogus anyway, as we really
need the DMA engine to tell us if there are underruns.
-- Because of above item, had to rework tx_fifo_atn_store(),
rx_fifo_atn_store(), and __attr_fifo_atn_write().
-- Set struct audio_stream::active for a recording stream to true when a
recording starts, and set it to false when recording get stopped. Do not
set/clear it within the body of read(), because just being within read()
does not mean that recording is in progress.
-- In tegra_audio_read(), check for stop == true before calling
start_recording_if_necessary(); this makes sure that if a user calls read()
after calling ioctl(TEGRA_AUDIO_IN_STOP), recording will not resume unless
ioctl(TEGRA_AUDIO_IN_START) gets called, or the file is closed and
re-opened.
-- Fixed TEGRA_AUDIO_IN_START
-- In PIO mode, enabled FIFOs before enabling interrupts as specified in the
TRM.
-- Added missing break in tegra_audio_ioctl().
-- Silenced some debug spew
Signed-off-by: Iliyan Malchev <malchev@google.com>
This patch disables the fanotify syscalls by just not building them and
letting the cond_syscall() statements in kernel/sys_ni.c redirect them
to sys_ni_syscall().
It was pointed out by Tvrtko Ursulin that the fanotify interface did not
include an explicit prioritization between groups. This is necessary
for fanotify to be usable for hierarchical storage management software,
as they must get first access to the file, before inotify-like notifiers
see the file.
This feature can be added in an ABI compatible way in the next release
(by using a number of bits in the flags field to carry the info) but it
was suggested by Alan that maybe we should just hold off and do it in
the next cycle, likely with an (new) explicit argument to the syscall.
I don't like this approach best as I know people are already starting to
use the current interface, but Alan is all wise and noone on list backed
me up with just using what we have. I feel this is needlessly ripping
the rug out from under people at the last minute, but if others think it
needs to be a new argument it might be the best way forward.
Three choices:
Go with what we got (and implement the new feature next cycle). Add a
new field right now (and implement the new feature next cycle). Wait
till next cycle to release the ABI (and implement the new feature next
cycle). This is number 3.
Signed-off-by: Eric Paris <eparis@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
