In the current implementation DBA driver always assumes
the TV connected is supporting audio. However if the TV
connected is in DVI mode or it's EDID does not contain
any audio block then it will not support audio data.
Hence after parsing EDID, check if the connected TV has
support for audio and accordingly configure and send HPD
events to audio framework.
Change-Id: Id1d175b9c0c1c07bcb4447eeaa907a17c15df098
Signed-off-by: Sandeep Panda <spanda@codeaurora.org>
Signed-off-by: Vishnuvardhan Prodduturi <vproddut@codeaurora.org>
By enabling the MMU early in cpu_resume(), the sleep_save_sp and stack can
be accessed by VA, which avoids the need to convert-addresses and clean to
PoC on the suspend path.
MMU setup is shared with the boot path, meaning the swapper_pg_dir is
restored directly: ttbr1_el1 is no longer saved/restored.
struct sleep_save_sp is removed, replacing it with a single array of
pointers.
cpu_do_{suspend,resume} could be further reduced to not restore: cpacr_el1,
mdscr_el1, tcr_el1, vbar_el1 and sctlr_el1, all of which are set by
__cpu_setup(). However these values all contain res0 bits that may be used
to enable future features.
Change-Id: I9a188fe2600914463ca30d7515db48851f12a7fe
Signed-off-by: James Morse <james.morse@arm.com>
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Git-commit: cabe1c81ea5be983425d117912d7883e252a3b09
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Mohammed Khajapasha <mkhaja@codeaurora.org>
Functions which the compiler has instrumented for KASAN place poison on
the stack shadow upon entry and remove this poison prior to returning.
In the case of cpuidle, CPUs exit the kernel a number of levels deep in
C code. Any instrumented functions on this critical path will leave
portions of the stack shadow poisoned.
If CPUs lose context and return to the kernel via a cold path, we
restore a prior context saved in __cpu_suspend_enter are forgotten, and
we never remove the poison they placed in the stack shadow area by
functions calls between this and the actual exit of the kernel.
Thus, (depending on stackframe layout) subsequent calls to instrumented
functions may hit this stale poison, resulting in (spurious) KASAN
splats to the console.
To avoid this, clear any stale poison from the idle thread for a CPU
prior to bringing a CPU online.
Change-Id: I2d928e26d66d14e9e625ab862e453c59d2341ae4
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Git-commit: 0d97e6d8024c71cc838b292c01d5bd951e080eba
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Mohammed Khajapasha <mkhaja@codeaurora.org>
This reverts commit 3b5f4eb596 ("arm64: Change cpu_resume()
to enable mmu early then access sleep_sp by va"). This
change removed KASAN unpoison check from the original upstream
commit. Subsequent change in this series includes the original
change, with KASAN check present.
Change-Id: Ib8ec11078bef1eb167d69d922a66630aa6379e84
Signed-off-by: Mohammed Khajapasha <mkhaja@codeaurora.org>
Functions which the compiler has instrumented for KASAN place poison on
the stack shadow upon entry and remove this poision prior to returning.
In the case of CPU hotplug, CPUs exit the kernel a number of levels deep
in C code. Any instrumented functions on this critical path will leave
portions of the stack shadow poisoned.
When a CPU is subsequently brought back into the kernel via a different
path, depending on stackframe, layout calls to instrumented functions
may hit this stale poison, resulting in (spurious) KASAN splats to the
console.
To avoid this, clear any stale poison from the idle thread for a CPU
prior to bringing a CPU online.
Change-Id: I05a91c3e39e86e186e957cb84442a7da456e8fb7
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Cc: Alexander Potapenko <glider@google.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Git-commit: e1b77c92981a522223bd1ac118fdcade6b7ad086
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Mohammed Khajapasha <mkhaja@codeaurora.org>
Functions which the compiler has instrumented for ASAN place poison on
the stack shadow upon entry and remove this poison prior to returning.
In some cases (e.g. hotplug and idle), CPUs may exit the kernel a
number of levels deep in C code. If there are any instrumented
functions on this critical path, these will leave portions of the idle
thread stack shadow poisoned.
If a CPU returns to the kernel via a different path (e.g. a cold
entry), then depending on stack frame layout subsequent calls to
instrumented functions may use regions of the stack with stale poison,
resulting in (spurious) KASAN splats to the console.
Contemporary GCCs always add stack shadow poisoning when ASAN is
enabled, even when asked to not instrument a function [1], so we can't
simply annotate functions on the critical path to avoid poisoning.
Instead, this series explicitly removes any stale poison before it can
be hit. In the common hotplug case we clear the entire stack shadow in
common code, before a CPU is brought online.
On architectures which perform a cold return as part of cpu idle may
retain an architecture-specific amount of stack contents. To retain the
poison for this retained context, the arch code must call the core KASAN
code, passing a "watermark" stack pointer value beyond which shadow will
be cleared. Architectures which don't perform a cold return as part of
idle do not need any additional code.
This patch (of 3):
Functions which the compiler has instrumented for KASAN place poison on
the stack shadow upon entry and remove this poision prior to returning.
In some cases (e.g. hotplug and idle), CPUs may exit the kernel a number
of levels deep in C code. If there are any instrumented functions on this
critical path, these will leave portions of the stack shadow poisoned.
If a CPU returns to the kernel via a different path (e.g. a cold entry),
then depending on stack frame layout subsequent calls to instrumented
functions may use regions of the stack with stale poison, resulting in
(spurious) KASAN splats to the console.
To avoid this, we must clear stale poison from the stack prior to
instrumented functions being called. This patch adds functions to the
KASAN core for removing poison from (portions of) a task's stack. These
will be used by subsequent patches to avoid problems with hotplug and
idle.
Change-Id: I5813ed6901ad27b168e54dfc6186ffc31aba8d84
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Git-commit: e3ae116339f9a0c77523abc95e338fa405946e07
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Mohammed Khajapasha <mkhaja@codeaurora.org>
(Cherry-pick from commit be0726d33cb8f411945884664924bed3cb8c70ee)
The conversion is generally straightforward. We convert filesystem from
a global cache to per-fs one. Similarly to ext4 the tricky part is that
xattr block corresponding to found mbcache entry can get freed before we
get buffer lock for that block. So we have to check whether the entry is
still valid after getting the buffer lock.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Bug: 32461228
(Cherry-pick from commit 82939d7999dfc1f1998c4b1c12e2f19edbdff272)
The conversion is generally straightforward. The only tricky part is
that xattr block corresponding to found mbcache entry can get freed
before we get buffer lock for that block. So we have to check whether
the entry is still valid after getting buffer lock.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Bug; 32461228
(Cherry-pick from commit f9a61eb4e2471c56a63cd804c7474128138c38ac)
Original mbcache was designed to have more features than what ext?
filesystems ended up using. It supported entry being in more hashes, it
had a home-grown rwlocking of each entry, and one cache could cache
entries from multiple filesystems. This genericity also resulted in more
complex locking, larger cache entries, and generally more code
complexity.
This is reimplementation of the mbcache functionality to exactly fit the
purpose ext? filesystems use it for. Cache entries are now considerably
smaller (7 instead of 13 longs), the code is considerably smaller as
well (414 vs 913 lines of code), and IMO also simpler. The new code is
also much more lightweight.
I have measured the speed using artificial xattr-bench benchmark, which
spawns P processes, each process sets xattr for F different files, and
the value of xattr is randomly chosen from a pool of V values. Averages
of runtimes for 5 runs for various combinations of parameters are below.
The first value in each cell is old mbache, the second value is the new
mbcache.
V=10
F\P 1 2 4 8 16 32 64
10 0.158,0.157 0.208,0.196 0.500,0.277 0.798,0.400 3.258,0.584 13.807,1.047 61.339,2.803
100 0.172,0.167 0.279,0.222 0.520,0.275 0.825,0.341 2.981,0.505 12.022,1.202 44.641,2.943
1000 0.185,0.174 0.297,0.239 0.445,0.283 0.767,0.340 2.329,0.480 6.342,1.198 16.440,3.888
V=100
F\P 1 2 4 8 16 32 64
10 0.162,0.153 0.200,0.186 0.362,0.257 0.671,0.496 1.433,0.943 3.801,1.345 7.938,2.501
100 0.153,0.160 0.221,0.199 0.404,0.264 0.945,0.379 1.556,0.485 3.761,1.156 7.901,2.484
1000 0.215,0.191 0.303,0.246 0.471,0.288 0.960,0.347 1.647,0.479 3.916,1.176 8.058,3.160
V=1000
F\P 1 2 4 8 16 32 64
10 0.151,0.129 0.210,0.163 0.326,0.245 0.685,0.521 1.284,0.859 3.087,2.251 6.451,4.801
100 0.154,0.153 0.211,0.191 0.276,0.282 0.687,0.506 1.202,0.877 3.259,1.954 8.738,2.887
1000 0.145,0.179 0.202,0.222 0.449,0.319 0.899,0.333 1.577,0.524 4.221,1.240 9.782,3.579
V=10000
F\P 1 2 4 8 16 32 64
10 0.161,0.154 0.198,0.190 0.296,0.256 0.662,0.480 1.192,0.818 2.989,2.200 6.362,4.746
100 0.176,0.174 0.236,0.203 0.326,0.255 0.696,0.511 1.183,0.855 4.205,3.444 19.510,17.760
1000 0.199,0.183 0.240,0.227 1.159,1.014 2.286,2.154 6.023,6.039 ---,10.933 ---,36.620
V=100000
F\P 1 2 4 8 16 32 64
10 0.171,0.162 0.204,0.198 0.285,0.230 0.692,0.500 1.225,0.881 2.990,2.243 6.379,4.771
100 0.151,0.171 0.220,0.210 0.295,0.255 0.720,0.518 1.226,0.844 3.423,2.831 19.234,17.544
1000 0.192,0.189 0.249,0.225 1.162,1.043 2.257,2.093 5.853,4.997 ---,10.399 ---,32.198
We see that the new code is faster in pretty much all the cases and
starting from 4 processes there are significant gains with the new code
resulting in upto 20-times shorter runtimes. Also for large numbers of
cached entries all values for the old code could not be measured as the
kernel started hitting softlockups and died before the test completed.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Bug: 32461228
Add reset of the phy pll when driver
exits idle screen. This fixes random
failures that were causing dsi commands
to fail after exit idle power collapse.
Change-Id: I0f6a53aef31c1c00f6d3cf1efceaa8211684412c
Signed-off-by: Ingrid Gallardo <ingridg@codeaurora.org>
Fix the security issue where mux channel name might
not be null-terminated in ipa wan driver.
Change-Id: I3ef440b62cf3861464fb60c1e7f65f2be5e39ed0
Acked-by: Shihuan Liu <shihuanl@qti.qualcomm.com>
Signed-off-by: Skylar Chang <chiaweic@codeaurora.org>
In case of WDSP fatal errors, subsystem restart is done to reset the
WDSP. Currently, the driver performs subsystem restart silently and
does not cause devie crash. Add debugfs property 'panic_on_error'
to indicate the driver to induce BUG_ON to aid debugging. The BUG_ON
is done only when the debugfs property is explicity set through
debugfs. If not set, the driver will continue without crashing. The
below command can be used to set the debugfs property.
echo Y > /sys/kernel/debug/wdsp_mgr/panic_on_error
CRs-fixed: 2029058
Change-Id: I1442cc59e1819c3b0abd4c4776f4b32ba63d59e2
Signed-off-by: Bhalchandra Gajare <gajare@codeaurora.org>
Allow clients to specify the IOVA range for fastmap clients
via the DOMAIN_ATTR_GEOMETRY domain attribute.
Presently fastmap only allocates page tables for the IOVA
range specified during the create mapping call. However
clients may want to use IOVA addresses outside this range,
such as for their calls to iommu_map.
So allow clients to extend the available IOVA space by setting
the DOMAIN_ATTR_GEOMETRY domain attribute's
iommu_domain_geometry.aperture_start to
the new start address of the IOVA space and by setting
iommu_domain_geometry.aperture_end to the new end address of the
IOVA space.
The new IOVA space created by iommu_domain_geometry.aperture_start
and iommu_domain_geometry.aperture_end will be a superset of the
IOVA range which was created through the create mapping call.
The DOMAIN_ATTR_GEOMETRY domain attribute can only be set before
attaching.
Calls to set the DOMAIN_ATTR_GEOMETRY domain attribute can only
be used to extend the IOVA space, it cannot shrink the range.
Note that extending the IOVA range will not change the range of
IOVA addresses which will be available to the DMA APIs.
Change-Id: Ib389e019a022d98417884002de08115fb0fc9384
Signed-off-by: Liam Mark <lmark@codeaurora.org>
On some conditions, such as reboot, the allocation context
for DMA task might be a user space processes with SIGKILL.
Pre allocate this buffer to avoid DMA allocation failure.
Change-Id: Ie0c5ecbb7aebbf03c42c2f8976aad40e9987fd4a
CRs-Fixed: 2032907
Acked-by: Ady Abraham <adya@qti.qualcomm.com>
Signed-off-by: Skylar Chang <chiaweic@codeaurora.org>
This reverts 'commit 9730348075 ("arm64: Increase the max
granular size") and also sets ARM_DMA_MINALIGN to 128.
ARCH_DMA_MINALIGN is dependent on L1_CACHE_SHIFT but it should
be set to maximum *known* cache line size on ARMv8 systems to
avoid DMA coherecy issues. So setting ARM_DMA_MINALIGN to 128.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Change-Id: Ie771d1b693789fce8793538a6efddfe68e2a0043
Patch-mainline: linux-kernel @ 21/03/16, 17:14:03
Signed-off-by: Imran Khan <kimran@codeaurora.org>
The pointer req_frm comes from userspace,
req_frm->stream_handle is passed as an argument to
the function msm_isp_get_stream_common_data,
stream_idx can overflow common_data->streams[] and
the code ends up copying an out of bound
kernel address into stream_info. Adding bound check to
handle the same.
CRs-fixed: 2008683
Change-Id: Ib4a059bfd573cdc4e18ce630b4091576ff8edc7e
Signed-off-by: Senthil Kumar Rajagopal <skrajago@codeaurora.org>
Add PMIC revid support to identify the PMIC subtype for OLEDB driver.
This is useful to enable the functionalities/features that are specific to
certain PMICs like PM660A.
Change-Id: I4539955abb29fe37256e21ac507db646953e0abf
Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
Channel 511 is used for debug port on MSM8998/SDM660/SDM630
targets. Reserve the same to avoid the access from other
peripherals.
Change-Id: I928916b7d61793a07e9a3b2e1c2127a247c71730
Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
Disable the laser sensor when camera crash to avoid
call CCI funciton after CCI released.
Change-Id: Ic9654730f936da68a74c0d9fa41801c7a1470971
Signed-off-by: Wei Ding <weiding@codeaurora.org>
