Information from slimport vendor:
With the wrong value set to SP_TX_AUX_CTRL_REG2, 7808 will try to
write 0x00 to a random offset of EDID in the monitor. if the monitor's
EDID is over written, we make it a bad EDID; with a bad EDID, AP will
output 640x480p only normally. But most of monitors have write protection
of EDID, 7808 is not able over write it.
This issue not able to be reproduced with a monitor with EDID write
protection.
We have to fix this bug in case the very unlucky end user has a monitor
without EDID write protection.
Issue 10062852
Change-Id: Id8eff5a77154d648c8eb5046ef1cf35f4f9a712d
Signed-off-by: yetta_wu <yetta_wu@asus.com>
Fix/Improve issue:
1.[Issue 9692415] Touch screen on flo is broken for games.
2.Broken line.
3.Two Fingers Tapping Easy Connectivity.
4.co-axis problem with two finger.
Change-Id: I4c906bc612a6184a131e52bc69d4e7d4d0e460c1
Signed-off-by: mars_kao <mars_kao@asus.com>
When we allocate from iommu heap we first try to allocate 1M pages. If
that fails we try 64K pages, which falls back to 4K pages. However,
we don't want to incur too much overhead when allocating with fallbacks
so we don't want the higher order page allocation to retry, perform
reclaim, or run memory compaction.
Configure the GFP flags to ensure that when we allocate pages greater
than order 0 we don't try to do any retries, reclaim, access emergency
pools, or run memory compaction. This will ensure lower memory allocation
latency for applications.
CRs-Fixed: 470389
Change-Id: Ibb3483dddbedbc733a1f7968821e7bc47bedffcd
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
(cherry picked from commit 365a6e063e66b55dbba6f7cfbd7070b8c567e429)
git://codeaurora.org/external/wlan/prima.git
4990d1c Wlan: Release 3.2.2.17B
d6b217f wlan: DTIM3 changed to DTIM1 after roaming
f83a6cd Wlan: Release 3.2.2.17A
2f45a43 Fix for "crash in pMac->cfg.gCfgEntry"
c8faf30 wlan: Change regulatory followed customer request
82e75bf wlan: Add msecs_to_jiffies() to wake lock argument
f1bb518 Revert "wlan: Release 3.2.2.18"
a65fc60 Revert "wlan: Set the country code in cfg before creating channel list."
d235ff4 Revert "wlan: Release 3.2.2.19"
2742bc2 Revert "wlan: Decrease SAP timeout from 100 to 10 seconds"
768b6f5 Revert "wlan: Change RX wakelock to 50 milliseconds"
4edbdc7 Revert "wlan: Fix for spectrum management bit in AddBss for SM disabled AP"
2b46b25 Revert "wlan: Release 3.2.2.20"
0647d89 wlan: Release 3.2.2.20
e1c76a3 wlan: Fix for spectrum management bit in AddBss for SM disabled AP
b8493a3 wlan: Change RX wakelock to 50 milliseconds
476a501 wlan: Decrease SAP timeout from 100 to 10 seconds
c883f13 wlan: Release 3.2.2.19
4dbdab2 wlan: Set the country code in cfg before creating channel list.
7cabdd8 wlan: Release 3.2.2.18
Signed-off-by: Iliyan Malchev <malchev@google.com>
(cherry picked from commit 3bafaebe43a88fbd951b02d257def2f7f1489bb3)
When there is no secure pipe configured, we can unmap secure
memory instead of relying on unset with secure flag set from
userspace.
Signed-off-by: Naseer Ahmed <naseer@codeaurora.org>
Average current drawn can be calculated by reading the coulomb
counter based charge before and after the usecase is run and
dividing the difference in the charge by the time it took to
run the usecase.
Use power supply property POWER_SUPPLY_PROP_CHARGE_NOW, to
expose the coulomb counter based charge.
Change-Id: I43e26a2932ab3e3d9d79bb5af7daf2364ca133b7
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: Ajay Dudani <adudani@codeaurora.org>
In original schematic design, project identification is composed
of PCB_ID8, PCB_ID7, and PCB_ID6. In proposed schematic design,
PCB_ID8 would be recycled and re-assign it as new hardware
identifier for adjusting PWM Freq. for JDI panel variants.
Bug: 9848554
Change-Id: Id2c62f8904e22c19dbdede191541bb3cb2927fbc
Signed-off-by: paris_yeh <paris_yeh@asus.com>
to avoid unexpected retry command in firmware update mechanism.
[9867254]Need to wait for 20 ms before starting communicate with touch IC for boot-code initialization after the hw reset.
Change-Id: I6ae85336cb98e44f1de0344e4831a670d7a11d47
Signed-off-by: mars_kao <mars_kao@asus.com>
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 <pkondeti@codeaurora.org>
(cherry picked from commit e119ebfcea1058c28b877164e2478cff2c406c14)
1.[Issue 9728761] [Flo/Deb] To prevent Deadlock while switching on/off CapSensor
Change-Id: Ia4aa17a5f8f3e67081c2ae88d02094f071d78881
Signed-off-by: rock lin <Rock_Lin@asus.com>
In high temperature environment, charger will occur over-voltage
and it will latch charging battery function, we need to refine
JEITA function to avoid it
Bug: 9847839
Change-Id: I1185fd3a49e318ebd83b30d843d2b72c39f22e40
Signed-off-by: Hank_Lee <Hank_Lee@asus.com>
Avoid waking up every thread sleeping in read call on an AF_UNIX
socket during suspend and resume by calling a freezable blocking
call. Previous patches modified the freezer to avoid sending
wakeups to threads that are blocked in freezable blocking calls.
This call was selected to be converted to a freezable call because
it doesn't hold any locks or release any resources when interrupted
that might be needed by another freezing task or a kernel driver
during suspend, and is a common site where idle userspace tasks are
blocked.
Change-Id: I788246a76780ea892659526e70be018b18f646c4
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Avoid waking up every thread sleeping in a sigtimedwait call during
suspend and resume by calling a freezable blocking call. Previous
patches modified the freezer to avoid sending wakeups to threads
that are blocked in freezable blocking calls.
This call was selected to be converted to a freezable call because
it doesn't hold any locks or release any resources when interrupted
that might be needed by another freezing task or a kernel driver
during suspend, and is a common site where idle userspace tasks are
blocked.
Change-Id: Ic27469b60a67d50cdc0d0c78975951a99c25adcd
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Avoid waking up every thread sleeping in a nanosleep call during
suspend and resume by calling a freezable blocking call. Previous
patches modified the freezer to avoid sending wakeups to threads
that are blocked in freezable blocking calls.
This call was selected to be converted to a freezable call because
it doesn't hold any locks or release any resources when interrupted
that might be needed by another freezing task or a kernel driver
during suspend, and is a common site where idle userspace tasks are
blocked.
Change-Id: I93383201d4dd62130cd9a9153842d303fc2e2986
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Avoid waking up every thread sleeping in a futex_wait call during
suspend and resume by calling a freezable blocking call. Previous
patches modified the freezer to avoid sending wakeups to threads
that are blocked in freezable blocking calls.
This call was selected to be converted to a freezable call because
it doesn't hold any locks or release any resources when interrupted
that might be needed by another freezing task or a kernel driver
during suspend, and is a common site where idle userspace tasks are
blocked.
Change-Id: I9ccab9c2d201adb66c85432801cdcf43fc91e94f
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Avoid waking up every thread sleeping in a select call during
suspend and resume by calling a freezable blocking call. Previous
patches modified the freezer to avoid sending wakeups to threads
that are blocked in freezable blocking calls.
This call was selected to be converted to a freezable call because
it doesn't hold any locks or release any resources when interrupted
that might be needed by another freezing task or a kernel driver
during suspend, and is a common site where idle userspace tasks are
blocked.
Change-Id: I0d7565ec0b6bc5d44cb55f958589c56e6bd16348
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Avoid waking up every thread sleeping in an epoll_wait call during
suspend and resume by calling a freezable blocking call. Previous
patches modified the freezer to avoid sending wakeups to threads
that are blocked in freezable blocking calls.
This call was selected to be converted to a freezable call because
it doesn't hold any locks or release any resources when interrupted
that might be needed by another freezing task or a kernel driver
during suspend, and is a common site where idle userspace tasks are
blocked.
Change-Id: I848d08d28c89302fd42bbbdfa76489a474ab27bf
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Iliyan Malchev <malchev@google.com>
Conflicts:
fs/eventpoll.c
Avoid waking up every thread sleeping in a binder call during
suspend and resume by calling a freezable blocking call. Previous
patches modified the freezer to avoid sending wakeups to threads
that are blocked in freezable blocking calls.
This call was selected to be converted to a freezable call because
it doesn't hold any locks or release any resources when interrupted
that might be needed by another freezing task or a kernel driver
during suspend, and is a common site where idle userspace tasks are
blocked.
Change-Id: Ic4458ae90447f6caa895cc62f08e515caa7790ba
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Freezing tasks will wake up almost every userspace task from
where it is blocking and force it to run until it hits a
call to try_to_sleep(), generally on the exit path from the syscall
it is blocking in. On resume each task will run again, usually
restarting the syscall and running until it hits the same
blocking call as it was originally blocked in.
To allow tasks to avoid running on every suspend/resume cycle,
this patch adds additional freezable wrappers around blocking calls
that call freezer_do_not_count(). Combined with the previous patch,
these tasks will not run during suspend or resume unless they wake
up for another reason, in which case they will run until they hit
the try_to_freeze() in freezer_count(), and then continue processing
the wakeup after tasks are thawed.
Additional patches will convert the most common locations that
userspace blocks in to use freezable helpers.
Change-Id: Id909760ce460f2532801a4b00d344f0816bfefc9
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Some of the freezable helpers have to be macros because their
condition argument needs to get evaluated every time through
the wait loop. Convert the others to static inline to make
future changes easier.
Change-Id: I69d3fc10d26522cb9bf3a616ff4f21245f9c071a
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Freezing tasks will wake up almost every userspace task from
where it is blocking and force it to run until it hits a
call to try_to_sleep(), generally on the exit path from the syscall
it is blocking in. On resume each task will run again, usually
restarting the syscall and running until it hits the same
blocking call as it was originally blocked in.
Convert the existing wait_event_freezable* wrappers to use
freezer_do_not_count(). Combined with a previous patch,
these tasks will not run during suspend or resume unless they wake
up for another reason, in which case they will run until they hit
the try_to_freeze() in freezer_count(), and then continue processing
the wakeup after tasks are thawed.
This results in a small change in behavior, previously a race
between freezing and a normal wakeup would be won by the wakeup,
now the task will freeze and then handle the wakeup after thawing.
Change-Id: I532e62251f58c1a9ca488b3fb6220c53acf7d33d
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Android goes through suspend/resume very often (every few seconds when
on a busy wifi network with the screen off), and a significant portion
of the energy used to go in and out of suspend is spent in the
freezer. If a task has called freezer_do_not_count(), don't bother
waking it up. If it happens to wake up later it will call
freezer_count() and immediately enter the refrigerator.
Combined with patches to convert freezable helpers to use
freezer_do_not_count() and convert common sites where idle userspace
tasks are blocked to use the freezable helpers, this reduces the
time and energy required to suspend and resume.
Change-Id: I6ba019d24273619849af757a413271da3261d7db
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
All tasks can easily be frozen in under 10 ms, switch to using
an initial 1 ms sleep followed by exponential backoff until
8 ms. Also convert the printed time to ms instead of centiseconds.
Change-Id: I7b198b16eefb623c2b0fc45dce50d9bca320afdc
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
We shouldn't try_to_freeze if locks are held. Holding a lock can cause a
deadlock if the lock is later acquired in the suspend or hibernate path
(e.g. by dpm). Holding a lock can also cause a deadlock in the case of
cgroup_freezer if a lock is held inside a frozen cgroup that is later
acquired by a process outside that group.
History:
This patch was originally applied as 6aa9707099c and reverted in
dbf520a9d7d4 because NFS was freezing with locks held. It was
deemed better to keep the bad freeze point in NFS to allow laptops
to suspend consistently. The previous patch in this series converts
NFS to call _unsafe versions of the freezable helpers so that
lockdep doesn't complain about them until a more correct fix
can be applied.
Change-Id: Ib9d4299fb75a39e611b868be42e413909a994baa
[akpm@linux-foundation.org: export debug_check_no_locks_held]
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The only existing caller to debug_check_no_locks_held calls it
with 'current' as the task, and the freezer needs to call
debug_check_no_locks_held but doesn't already have a current
task pointer, so remove the argument. It is already assuming
that the current task is relevant by dumping the current stack
trace as part of the warning.
This was originally part of 6aa9707099c (lockdep: check that
no locks held at freeze time) which was reverted in
dbf520a9d7d4.
Change-Id: Idbaf1332ce6c80dc49c1d31c324c7fbf210657c5
Original-author: Mandeep Singh Baines <msb@chromium.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CIFS calls wait_event_freezekillable_unsafe with a VFS lock held,
which is unsafe and will cause lockdep warnings when 6aa9707
"lockdep: check that no locks held at freeze time" is reapplied
(it was reverted in dbf520a). CIFS shouldn't be doing this, but
it has long-running syscalls that must hold a lock but also
shouldn't block suspend. Until CIFS freeze handling is rewritten
to use a signal to exit out of the critical section, add a new
wait_event_freezekillable_unsafe helper that will not run the
lockdep test when 6aa9707 is reapplied, and call it from CIFS.
In practice the likley result of holding the lock while freezing
is that a second task blocked on the lock will never freeze,
aborting suspend, but it is possible to manufacture a case using
the cgroup freezer, the lock, and the suspend freezer to create
a deadlock. Silencing the lockdep warning here will allow
problems to be found in other drivers that may have a more
serious deadlock risk, and prevent new problems from being added.
Change-Id: I420c5392bacf68e58e268293b2b36068ad4df753
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
NFS calls the freezable helpers with locks held, which is unsafe
and will cause lockdep warnings when 6aa9707 "lockdep: check
that no locks held at freeze time" is reapplied (it was reverted
in dbf520a). NFS shouldn't be doing this, but it has
long-running syscalls that must hold a lock but also shouldn't
block suspend. Until NFS freeze handling is rewritten to use a
signal to exit out of the critical section, add new *_unsafe
versions of the helpers that will not run the lockdep test when
6aa9707 is reapplied, and call them from NFS.
In practice the likley result of holding the lock while freezing
is that a second task blocked on the lock will never freeze,
aborting suspend, but it is possible to manufacture a case using
the cgroup freezer, the lock, and the suspend freezer to create
a deadlock. Silencing the lockdep warning here will allow
problems to be found in other drivers that may have a more
serious deadlock risk, and prevent new problems from being added.
Change-Id: Ia17d32cdd013a6517bdd5759da900970a4427170
Signed-off-by: Colin Cross <ccross@android.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ARM disables interrupts in do_signal, which triggers a warning in
try_to_freeze, see details at https://lkml.org/lkml/2011/8/23/221.
To prevent the warnings, add try_to_freeze_nowarn and call it from
do_signal.
Change-Id: If7482de21c386adc705fa1ac4ecb8c7ece5bb356
Signed-off-by: Colin Cross <ccross@android.com>
commit dd67d32dbc5de299d70cc9e10c6c1e29ffa56b92 upstream.
A task is considered frozen enough between freezer_do_not_count() and
freezer_count() and freezers use freezer_should_skip() to test this
condition. This supposedly works because freezer_count() always calls
try_to_freezer() after clearing %PF_FREEZER_SKIP.
However, there currently is nothing which guarantees that
freezer_count() sees %true freezing() after clearing %PF_FREEZER_SKIP
when freezing is in progress, and vice-versa. A task can escape the
freezing condition in effect by freezer_count() seeing !freezing() and
freezer_should_skip() seeing %PF_FREEZER_SKIP.
This patch adds smp_mb()'s to freezer_count() and
freezer_should_skip() such that either %true freezing() is visible to
freezer_count() or !PF_FREEZER_SKIP is visible to
freezer_should_skip().
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Define the offset of FSYNR1 IOMMU register correctly for IOMMU-v0.
Change-Id: Ibcbc863e1be02da3be22dd1a9cfe4a41e043d503
Signed-off-by: Shubhraprakash Das <sadas@codeaurora.org>
Signed-off-by: Ling Wan <lingw@codeaurora.org>
Add a %pF to the kgsl_fire_event tracepoint to show which function is
being called when the event expired. This will help debugging when
something goes bad in the callback which isn't always intuitive from
a stack trace.
Change-Id: Ic0dedbad41bdceefb29cec2730036620d2e4d8f3
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Ling Wan <lingw@codeaurora.org>
The GPU memory allocation flags allow 8 bits of space to specify
a power of 2 aligment for the allocated memory block. Cap the
actual alignment to 2^31 since any value more than that will have
unintended effects on a 32 bit system.
Change-Id: Ic0dedbadd42a9a886b8bfada0c7d415caaed65de
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Ling Wan <lingw@codeaurora.org>
Compute workloads run without kernel interaction for long periods
of time. If one is identified early, increase the frequency to
finish it as fast as possible, rather than waiting for the standard
algorithm to do so.
Change-Id: I213ccabfae5e1000cdc34bc1d92bdc3bad86383d
CRs-Fixed: 441847
Signed-off-by: Lucille Sylvester <lsylvest@codeaurora.org>
Signed-off-by: Ling Wan <lingw@codeaurora.org>
Base the decision to call power scaling functions on the current
state, not the requested state. The GPU may not transition to the
requested state; call through based on current GPU state instead.
Change-Id: I1524bc92c908dc50a60b5815f2221ae3feef59be
CRs-Fixed: 441847
Signed-off-by: Lucille Sylvester <lsylvest@codeaurora.org>
Signed-off-by: Ling Wan <lingw@codeaurora.org>
