Change will handle codec config buffer with EOS.
Video driver will make sure that the codec config buffer with
EOS will be requeued in case of reconfig and non-reconfig paths.
CRs-fixed: 399347
Signed-off-by: Gopikrishnaiah Anandan <agopik@codeaurora.org>
(cherry picked from commit 43b203869814fe5f0ddcb265a8f859aebdaa652f)
Change-Id: Ib9a41fb842d2295804db86b2e03a62238c29984d
Signed-off-by: Dhivya Subramanian <dthiru@codeaurora.org>
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
This change will ensure that video core clock is
set to 266Mhz on supported devices, else fallback
to 228Mhz.
Signed-off-by: Arun Menon <menon@codeaurora.org>
(cherry picked from commit 2cd6f1a77d845c162966b974b0e9dd4db0878020)
Change-Id: Ie9d28b218150f2e21fa95c4d4346251ddab3ee50
Signed-off-by: Dhivya Subramanian <dthiru@codeaurora.org>
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
Perform ion_phys instead of ion_map_iommu() to get physical address
for a secure session. This is a CP 2.0 requirement.
Change-Id: I9a8124bec2f635cf6311523006a37ca201c8a51e
CRs-fixed: 380161
Signed-off-by: Arun Menon <menon@codeaurora.org>
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
Initialize mdp_iommu_split_domain for both wfd devices. Without this
change, mdp_iommu_split_domain is uninitialized for the second wfd
device during secure session.
Change-Id: Ic72dfc49a1e9a4ade1eaf8ea5e9412611431f787
CRs-fixed: 380161
Signed-off-by: Arun Menon <menon@codeaurora.org>
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
- Error handling is not performed when memory allocation failed.
- Reset wfd driver status to false.
Change-Id: I9827e2a6c6b971004bb45f6b90edb1e94d28b319
CRs-Fixed: 383712
Signed-off-by: Srinu Gorle <sgorle@codeaurora.org>
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
Support is added for MPEG-2 extension and user data. With this
changes Core returns extension and user data as an extradata.
Change-Id: I66a230aa651dabafa883625ce9f687d5c35b8671
Signed-off-by: Shobhit Pandey <cshopan@codeaurora.org>
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
In slice delivery mode, sometimes video hardware is giving
zero frame tag on output slices instead of input frame tag
value. This commit will fix the issue by copying the input
frame tag value to the output slice frame tag when video
hardware gives zero frame tag values.
Change-Id: Icc75ca72375c4445ff9becaea45b43c03a6ddc17
Signed-off-by: Maheshwar Ajja <majja@codeaurora.org>
Signed-off-by: Ramakrishna Prasad N <crpn@codeaurora.org>
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
This commit will add support for pause command in
eos state along with run state of the video driver.
Change-Id: I7edd064bb68845f63f0a085165e99f60ed0f3bfe
CRs-fixed: 387562
Signed-off-by: Maheshwar Ajja <majja@codeaurora.org>
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
The slices completed is not matching with the expected number
of slices in frame done. The fix is available in July firmware
release and this commit will have the corresponding video driver
changes.
Change-Id: Ic0c3c7ce4f9fdbcd6e8bed852a93dcc533d83a02
CRs-fixed: 380629
Signed-off-by: Maheshwar Ajja <majja@codeaurora.org>
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
These messages are non-fatal and appear frequently
during video session. Hence suppressing them.
Change-Id: I539bc966bd79b4074c82a432ba7eb3fd2746bf54
CRs-Fixed: 389408
Signed-off-by: Arun Menon <menon@codeaurora.org>
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
Support is added to enable temporary buffer for processing
the MPEG-2 extension and user data for the first sequence
done.
Change-Id: Ib7fdc8bfd50bfb0da651e8da6fca26a3542c671e
Signed-off-by: Shobhit Pandey <cshopan@codeaurora.org>
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
All msm_ion clients need to use <linux/msm_ion.h> instead of
<linux/ion.h>
Change-Id: I521a079686780c117ccc9d91f27b9c59aaeafa04
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
Read IDR picture type from 1080p core register set
and propagate it to user space using IDR frame type
enumeration in api header file. The IDR frame type
info is used in SYNCFRAME logic for H264 format in
userspace.
Change-Id: I6f87aea9f3c6e26b06effe68f7cb5a6c17d4bb1c
Signed-off-by: Maheshwar Ajja <majja@codeaurora.org>
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
- video core is bumped up to turbo mode, if more performance
level required from multiple clients.
- Enable turbo mode atleast one of client set turbo mode.
Change-Id: Ied777463fdfe54ea6ff3b2a29cbaf0d27a9586cb
CRs-Fixed: 385454
Signed-off-by: Srinu Gorle <sgorle@codeaurora.org>
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
Assign the correct master clk ids to vidc
bus client. Without this change video init
fails.
Change-Id: Id51f686f56d750854e4e14964b7b28c2ea27efe3
Signed-off-by: Arun Menon <menon@codeaurora.org>
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
- 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>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Adding two (or more) timers with large values for "expires" (they have
to reside within tv5 in the same list) leads to endless looping
between cascade() and internal_add_timer() in case CONFIG_BASE_SMALL
is one and jiffies are crossing the value 1 << 18. The bug was
introduced between 2.6.11 and 2.6.12 (and survived for quite some
time).
This patch ensures that when cascade() is called timers within tv5 are
not added endlessly to their own list again, instead they are added to
the next lower tv level tv4 (as expected).
Change-Id: Ia4e9b79767a4d255f676ecbb739b537bbe7033af
Signed-off-by: Christian Hildner <christian.hildner@siemens.com>
Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
Link: http://lkml.kernel.org/r/98673C87CB31274881CFFE0B65ECC87B0F5FC1963E@DEFTHW99EA4MSX.ww902.siemens.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Git commit 09a1d34f85 "nohz: Make idle/iowait counter update
conditional" introduced a bug in regard to cpu hotplug. The effect is
that the number of idle ticks in the cpu summary line in /proc/stat is
still counting ticks for offline cpus.
Reproduction is easy, just start a workload that keeps all cpus busy,
switch off one or more cpus and then watch the idle field in top.
On a dual-core with one cpu 100% busy and one offline cpu you will get
something like this:
%Cpu(s): 48.7 us, 1.3 sy, 0.0 ni, 50.0 id, 0.0 wa, 0.0 hi, 0.0 si,
%0.0 st
The problem is that an offline cpu still has ts->idle_active == 1.
To fix this we should make sure that the cpu is online when calling
get_cpu_idle_time_us and get_cpu_iowait_time_us.
[Srivatsa: Rebased to current mainline]
Change-Id: I53cd02fef784647e45abb4c99ff641e5e69a9d3e
Reported-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Link: http://lkml.kernel.org/r/20121010061820.8999.57245.stgit@srivatsabhat.in.ibm.com
Cc: deepthi@linux.vnet.ibm.com
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
worker_enter_idle() has WARN_ON_ONCE() which triggers if nr_running
isn't zero when every worker is idle. This can trigger spuriously
while a cpu is going down due to the way trustee sets %WORKER_ROGUE
and zaps nr_running.
It first sets %WORKER_ROGUE on all workers without updating
nr_running, releases gcwq->lock, schedules, regrabs gcwq->lock and
then zaps nr_running. If the last running worker enters idle
inbetween, it would see stale nr_running which hasn't been zapped yet
and trigger the WARN_ON_ONCE().
Fix it by performing the sanity check iff the trustee is idle.
Change-Id: I78c6300647a9e14a5f5f27fee0679d9072481188
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org
commit 386ad800716b6660d40c677b57ee4bf8e4430329 msm-3.4
What is the race condition? (NOTE: RPM stands for Runtime Power Management)
1. SDCC is in RPM_SUSPENEDED state and SDCC platform suspend gets
triggered and then system goes into suspend.
2. During platform resume, SDCC platform resume is triggered
which blindly sets the pending_resume flag in SDCC host structure.
3. If new MMC transfer request comes then MMC block driver calls
mmc_claim_host() which internally calls msmsdcc_enable().
4. msmsdcc_enable() checks for following 3 conditions to be true:
1. host->sdcc_suspended == true
2. host->pending_resume == true
3. pm_runtime_suspended() == false
But as SDCC state is RPM_SUSPENDED, 3rd condition is not be satisfied
so msmsdcc_enable() don't clear the host->pending_resume flag and simply
calls pm_runtime_get_sync() to resume the SDCC. Once SDCC is resumed,
host->sdcc_suspended = false, runtime_status = RPM_ACTIVE but
host->pending_resume is still set.
5. Now after RPM idle timeout, SDCC runtime suspend gets triggered which
calls SDCC driver's runtime suspend callback (msmsdcc_runtime_suspend).
Note that before executing the RPM suspend calllback, SDCC RPM status
is set to RPM_SUSPENDING.
6. As SDCC driver's runtime suspend callback gets executed, it sets the
host->sdcc_suspended to true. But now before the RPM framework
sets the SDCC RPM status to RPM_SUSPENDED, on other active CPU core,
new MMC transfer reques comes in which would first call msmsdcc_enable()
and all of the 3 conditions below is true:
1. host->sdcc_suspended == true
2. host->pending_resume == true
3. pm_runtime_suspended() == false (RPM status is RPM_SUSPENDING)
As these conditions are satisfied, msmsdcc_enable() does not call
pm_runtime_get_sync(), instead just calls pm_runtime_get_noresume() and
msmsdcc_runtime_resume(). This means even after execution of
msmsdcc_enable(), SDCC RPM status is either RPM_SUSPENDING or
RPM_SUSPENDED.
7. RPM suspend framework on 1st core sets the SDCC RPM status to
RPM_SUSPENDED once SDCC runtime suspend callback returns.
8. Now once MMC transfer request is completed on other core, it will call
msmsdcc_disable(). This function calls pm_runtime_put_sync() which
returns -EAGAIN error as RPM status is already RPM_SUSPENED.
This error gets returned to MMC layer so MMC layer thinks that
SDCC is still enabled and skips call to msmsdcc_enable() until
msmsdcc_disable() succeeds.
8. Note when msmsdcc_disable() returned error, RPM usage_counter was set to
0 so next call to msmsdcc_disable() decrements RPM usage_counter to -1
(remember msmsdcc_enable() was skipped).
9. Now new MMC request comes in and it will first call msmsdcc_enable()
which calls pm_runtime_get_sync() and it sets the usage_counter to 0
and blindly resumes the SDCC as it was already suspended. After this
RPM status will be RPM_ACTIVE.
10. Once MMC request is processed, it will call smsdcc_disable() which
calls pm_runtime_put_sync() and it decrements RPM usage counter to -1
and skips scheduling runtime suspend callback as RPM usage counter
is not 0. RPM status remains in RPM_ACTIVE.
11. Now onwards for every new MMC transfer requests, 9 and 10 repeats and
SDCC always stays in RPM_ACTIVE state forever.
How is this race condition fixed?
Above race is created because host->pending_resume is remaining sticky.
Following changes are done to ensure that pending_resume gets set and
cleared at appropriate places:
1. In SDCC platform resume callback, set the host->pending_resume flag
only if RPM status is RPM_ACTIVE.
2. Clear the pending_resume flag once msmsdcc_runtime_resume() is
completed.
3. In msmsdcc_enable() function, if pending_resume flag is set skip calling
pm_runtime_get_sync() instead directly call msmsdcc_runtime_resume()
because RPM status is RPM_ACTIVE.
In addition, this patch adds WARN() messages in case of failures in
msmsdcc_enable() and msmsdcc_disable() functions to capture more details
in error conditions.
CRs-Fixed: 373338
Change-Id: I50d1bd63480c668dd2b83f01567f912661f0c606
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
commit 9985432a82e6700cf9759f413ecaecbf617318cb
check for fh->dev being NULL before kzalloc to fix the memory leak
Change-Id: I3377ef39297f63c692aa5451d2bdbe327e2df18a
nullify pointers after kfree and remove unnecessary kmallocs
Also fix the memory leaks. should free the memory after v4l2_event_dequeue()
even if there are some errors in copy_to/from_user(). Because entry was
already removed from its own list after v4l2_event_dequeue().
Change-Id: I733538c2fd76a6b77cfd8d6b780caebcb3fd70a8
git://codeaurora.org/external/wlan/prima.git
e3f3c9d wlan: Release 3.2.1.11h
57634f6 Fix race condition in new cfg80211 APIs
ce5aeb6 Teardown Link with AP if riva indicates del sta reason keep alive
Signed-off-by: Iliyan Malchev <malchev@google.com>
Notify WCNSS when the Kernel is suspended and also when it resumes.
Signed-off-by: Sameer Thalappil <sameert@codeaurora.org>
Signed-off-by: Jeff Johnson <jjohnson@codeaurora.org>
This patch (as1591) moves the pm_runtime_get_noresume() and
pm_runtime_put_sync() calls from __device_suspend() and
device_resume() to device_prepare() and device_complete() in the PM
core.
The reason for doing this is to make sure that parent devices remain
at full power (i.e., don't go into runtime suspend) while their
children are being resumed from a system sleep.
The PCI core already contained equivalent code to serve the same
purpose. The patch removes the duplicated code, since it is no longer
needed. One of the comments from the PCI core gets moved into the PM
core, and a second comment is added to explain whe the _get_noresume
and _put_sync calls are present.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Add checks for hf->vdev being NULL to guard against cases where
v4l2_event_subscribe and v4l2_fh_del being called after v4l2_fh_exit.
Signed-off-by: Iliyan Malchev <malchev@google.com>
The min/max call needed to have explicit types on some architectures
(e.g. mn10300). Use clamp_t instead to avoid the warning:
kernel/sys.c: In function 'override_release':
kernel/sys.c:1287:10: warning: comparison of distinct pointer types lacks a cast [enabled by default]
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Calling uname() with the UNAME26 personality set allows a leak of kernel
stack contents. This fixes it by defensively calculating the length of
copy_to_user() call, making the len argument unsigned, and initializing
the stack buffer to zero (now technically unneeded, but hey, overkill).
CVE-2012-0957
Reported-by: PaX Team <pageexec@freemail.hu>
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: PaX Team <pageexec@freemail.hu>
Cc: Brad Spengler <spender@grsecurity.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Wait for 2 ms to make sure both dsi lanes are in stop state and
fifo are empty before reseting dsi controller.
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
Both front and back camera share the common cam gpios.
Each sensor controls the common cam gpios on his own power control.
It causes the power up failure.
Front camera requests the common cam gpios, and then back camera try
to request the common cam gpios. However common cam gpios is already
requested by front camera. At that time, front camera power up is failed.
It also might cause the kernel panic.
Mako common cam gpios are not used by other device. So muxing is not
needed.
[ 957.927514] msm_camera_request_gpio_table common gpio request failed
[ 957.927910] msm_sensor_power_up: request gpio failed
[ 957.928460] msm_sensor_power: imx119 power_up failed rc = -16
[ 957.928765] msm_mctl_open: sensor powerup failed: -16
[ 957.929284] msm_open: HW open failed rc = 0xfffffff0
[ 957.929558] msm_release_ion_client Calling ion_client_destroy
[ 957.930138] msm_open: error end
...
[ 1078.978696] msm_camera_request_gpio_table common gpio request failed
[ 1078.979032] msm_sensor_power_up: request gpio failed
[ 1078.979123] msm_sensor_power: imx119 power_up failed rc = -16
[ 1078.979276] msm_mctl_open: sensor powerup failed: -16
[ 1078.979337] msm_open: HW open failed rc = 0xfffffff0
[ 1078.979490] msm_release_ion_client Calling ion_client_destroy
[ 1078.979673] msm_open: error end
[ 1079.691805] Unable to handle kernel NULL pointer dereference at virtual address 00000228
...
Change-Id: Ie3bf982b4e1cea6c989fb93bbd39d5bd4eb1bf51
In extreme cases VFE needs more bandwith to suffice the client req in normal
power mode. This patch sets ensures to changes the bandwith dynamically.
Signed-off-by: Azam Sadiq Pasha Kapatrala Syed <akapatra@codeaurora.org>
Signed-off-by: Iliyan Malchev <malchev@google.com>
default brightness will be used in recovery or off-charing mode
This definition comes from lm3530 driver.
Change-Id: Ic3914403cc4844dc98049d7d131e1072c0eb79ca
