rmnet_usb: Kill some logspam

Change-Id: Ic8fa0f1472c82db9b2168483834e6960920d45a4
jf: Add CM defconfig

Change-Id: I796ad60185d15eed5881c122064096cbf2b5a5a2
input: Add option to disable touch booster

 * This can also be done from userspace, so allow disabling it.

Change-Id: I17f46abe89ed842d434307e90b7d2f8d4b6e1147
cm: Disable DVFS touch booster

 * We do this from userspace via boostpulse.

Change-Id: Ic1128c54779bf5c45c722f0f9e5610e8387aaa9f
mmc: Urgent request support

mmc: do not pack random requests

Packed commands causes higher latency since the completion of each
request is sent to the upper layer upon completion of the complete
packed request.
The benefit from this feature is card dependent. Some of the card
vendors do not have any benefit from using packed commands for random
requests. In case there is no benefit in random requests packing,
it is better to disable the packing to prevent this high latency.
This patch also add the new stop packing reason to the write packing
statistics.

Change-Id: I141887dcef2ceee14848634cc27c3c85f8edc7a5
Signed-off-by: Maya Erez <merez@codeaurora.org>

mmc: fix async request mechanism for sequential read scenarios

When current request is running on the bus and if next request fetched
by mmcqd is NULL, mmc context (mmcqd thread) gets blocked until the
current request completes. This means that if new request comes in while
the mmcqd thread is blocked, this new request can not be prepared in
parallel to current ongoing request. This may result in delaying the new
request execution and increase it's latency.

This change allows to wake up the MMC thread on new request arrival.
Now once the MMC thread is woken up, a new request can be fetched and
prepared in parallel to the current running request which means this new
request can be started immediately after the current running request
completes.

With this change read throughput is improved by 16%.

Change-Id: I8d74fda719c89a710330807c9d8994d40c885aa0
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>

mmc: block: add mmc_blk_disable_wr_packing() disables packing mode

The function disables packing mode. Right now the only reason is
change in data direction.

Change-Id: I0f4edba3da93fde28cf47ac95754a95e411fa2af
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>

mmc: Add support to handle Urgent data transfer request

Urgent request notification stops currently running transaction
on bus.
In order to decrease a latency of a prioritized requests (aka Urgent
request), we might want to stop the transmission of a running "low
priority" request in order to handle the Urgent request. The urgency of
the request is decided by the block layer I/O scheduler. When the block
layer notifies the MMC layer of an urgent request and if the MMC layer is
blocked on current request to complete, it will be woken up.

The decision on whether to stop an ongoing transfer is taken according to
several parameters, one of them being the number of bytes already
transferred for ongoing transfer by host controller so far.

To calculate how many bytes were successfully programmed before stop,
CORRECTLY_PRG_SECTORS_NUM[245:242] parsed from EXT_CSD register. The
remainder of stopped request (and next prepared request in case it
exists) re-inserted back to the I/O scheduler to be handled after the
completion of the urgent request.

In case it is decided not to stop the ongoing transfer, MMC context will
wait for normal completion of the ongoing transfer, then already prepared
next request (if it exists) will be re-inserted back into block layer and
the urgent request fetched.

URGENT_REQUEST handling has following dependencies:
1. Host controller driver should support mmc_host op named "stop_request"
2. Block I/O scheduler should support re-insert API
3. eMMC card should support HPI (High Priority Interrupt) command

If any of the above dependencies are not met then urgent request mechanism
will not become operational.

Change-Id: Ic3fa1ca9463cc8991aefee940d8bfddf76c111d3
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>

mmc: core: ignore new request notification, when 2 requests are in progress

In case both host->areq and areq requests exist and the new request
notification unblocks mmc context, instead of BUG_ON() in mmc_start_req(),
mmc_wait_for_data_req_done() continue to wait again for the completion
of the current request. New request notification is ignored in this case.

Change-Id: I5a0201a9fbe4cbaeb0c0a9b83f56f4af74eff95b
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>

mmc: fix read latency of urgent request

In order to improve read request latency, urgent notification allowed
anytime, when current or previous requests are existing in the mmc layer.
It is not allowed to stop following running requests:
- urgent request: block layer should serialize urgent request notification.
- read request: it can't be packed, therefore it is better
to wait for its completion.
- REQ_FUA: interruption and delay in such request will impact sync process
of upper layers.

Change-Id: Id7d1480cce2059c1f23a5f29ad8f74e858be1ee6
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>

mmc: msm_sdcc: enable support to handle Urgent data transfer request

In order to decrease a latency of a prioritized requests (aka Urgent
request), we might want to stop the transmission of a running "low
priority" request in order to handle the Urgent request.

URGENT_REQUEST handling has following dependencies:
1. Host controller driver should support mmc_host op named "stop_request"
2. Block I/O scheduler should support re-insert API
3. eMMC card should support HPI (High Priority Interrupt) command
If any of the above dependencies are not met then urgent request mechanism
will not become operational.

Change-Id: I976af4fa794fb0fac701fe12f249c36d78080c6e
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>

mmc: Do not perform blocking BKOPS

BKOPS operations can take long time and cause bad user experience and
failure of time critical operations as EFS sync.
In order to prevent the above failures all the levels will be handled only
in idle time BKOPS handling and will allow interrupting the BKOPS when
needed.
In case the card raised an exception with a need for BKOPS, a flag will
be set to indicate MMC to start the BKOPS activity when it becomes idle.

Fixed-CRs: 432027
Change-Id: I5f7b43569c0242f0fea83355f76f286b1ad037bc
Signed-off-by: Maya Erez <merez@codeaurora.org>
(cherry picked from commit 5f8ac3b955e44def61c2238192000ffe5f126714)
mmc: Fix warning during bootup

 * Don't call get_task_io_context with irqs off (this happens during the
   probe).

Change-Id: Ib56a38dfee7fed2632476fe729332111a22a7e8a
cm: Set ROW as default IO scheduler

Change-Id: I42a0faef64590136204439d06bacfa214cf5c388
msm: display: plane alpha support

Clean up the blending rule to follow blend_op set from hwc.
Use modulate alpha for plane alpha when it is not 0xff.
Keep backward compatibility if blend_op is not set.

Change-Id: I02fd3c3c7b5ace2e6eec22b2db0284161404a0fc
Signed-off-by: Ken Zhang <kenz@codeaurora.org>
msm_fb: display: fix iommu page fault when iommu buffer freed

There has possibility that pipe commit come very close to next vsync.
This may cause two consecutive pipe_commits happen within same vsync
period which cause iommu page fault when previous iommu buffer is
freed since mdp stil fetching it. Set ION_IOMMU_UNMAP_DELAYED flag
at ion_map_iommu() to add delay un mapping iommu buffer to fix this problem.
Otherwise four buffer mechanism is needed to avoid this problem..
Also ion_unmap_iommu() may take long time to free an ion buffer. Move
mdp4_overlay_iommu_unmap_freelist(mixer) called after stage_commit()
to increase chance to have pipe_commit (up to stage_commit) is completed
within same vsync period
This patch also fix an potential race condition at wait_for_completion
between show_event thread and wait4vsync thread.

Change-Id: I673b0e368bbcd3120bc26569fe7a7bb82931daaa
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
(cherry picked from commit ada63be0fd32e729e4b91aeeea2a5cfe0830148c)
(cherry picked from commit 799796f15e0b78ffe47975db1cf7f3791cb98129)
msm: restart: Always use Samsung magic restart reason

 * If this isn't passed, the bootloader won't honor the values written
   to the bootmode in the param partition.

Change-Id: I03a8bb764bc3392a3a43083b5c17893d86df7da7
workqueue: don't use WQ_HIGHPRI for unbound workqueues

Unbound wqs aren't concurrency-managed and try to execute work items
as soon as possible.  This is currently achieved by implicitly setting
%WQ_HIGHPRI on all unbound workqueues; however, WQ_HIGHPRI
implementation is about to be restructured and this usage won't be
valid anymore.

Add an explicit chain-wakeup path for unbound workqueues in
process_one_work() instead of piggy backing on %WQ_HIGHPRI.

Change-Id: Iecd17a9935ee28f856d8b726bb4c296762922bed
Signed-off-by: Tejun Heo <tj@kernel.org>
Git-commit: 974271c485a4d8bb801decc616748f90aafb07ec
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
workqueue: factor out worker_pool from global_cwq

Move worklist and all worker management fields from global_cwq into
the new struct worker_pool.  worker_pool points back to the containing
gcwq.  worker and cpu_workqueue_struct are updated to point to
worker_pool instead of gcwq too.

This change is mechanical and doesn't introduce any functional
difference other than rearranging of fields and an added level of
indirection in some places.  This is to prepare for multiple pools per
gcwq.

v2: Comment typo fixes as suggested by Namhyung.

Change-Id: Iefae84798c2af580f425b92ed79117935d99f21f
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Git-commit: bd7bdd43dcb81bb08240b9401b36a104f77dc135
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
workqueue: use @pool instead of @gcwq or @cpu where applicable

Modify all functions which deal with per-pool properties to pass
around @pool instead of @gcwq or @cpu.

The changes in this patch are mechanical and don't caues any
functional difference.  This is to prepare for multiple pools per
gcwq.

Change-Id: I4be6727e1cce6f9aa2a0057b96bdc725c84f1ea8
Signed-off-by: Tejun Heo <tj@kernel.org>
Git-commit: 63d95a9150ee3bbd4117fcd609dee40313b454d9
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
workqueue: separate out worker_pool flags

GCWQ_MANAGE_WORKERS, GCWQ_MANAGING_WORKERS and GCWQ_HIGHPRI_PENDING
are per-pool properties.  Add worker_pool->flags and make the above
three flags per-pool flags.

The changes in this patch are mechanical and don't caues any
functional difference.  This is to prepare for multiple pools per
gcwq.

Change-Id: I1824fd1c509d8ac6b0619536621a22b15b316256
Signed-off-by: Tejun Heo <tj@kernel.org>
Git-commit: 11ebea50dbc1ade5994b2c838a096078d4c02399
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
workqueue: introduce NR_WORKER_POOLS and for_each_worker_pool()

Introduce NR_WORKER_POOLS and for_each_worker_pool() and convert code
paths which need to manipulate all pools in a gcwq to use them.
NR_WORKER_POOLS is currently one and for_each_worker_pool() iterates
over only @gcwq->pool.

Note that nr_running is per-pool property and converted to an array
with NR_WORKER_POOLS elements and renamed to pool_nr_running.  Note
that get_pool_nr_running() currently assumes 0 index.  The next patch
will make use of non-zero index.

The changes in this patch are mechanical and don't caues any
functional difference.  This is to prepare for multiple pools per
gcwq.

v2: nr_running indexing bug in get_pool_nr_running() fixed.

v3: Pointer to array is stupid.  Don't use it in get_pool_nr_running()
    as suggested by Linus.

Change-Id: I46e9488601d764d25e4a6c707de129ab68f7064c
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fengguang Wu <fengguang.wu@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Git-commit: 4ce62e9e30cacc26885cab133ad1de358dd79f21
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
workqueue: reimplement WQ_HIGHPRI using a separate worker_pool

WQ_HIGHPRI was implemented by queueing highpri work items at the head
of the global worklist.  Other than queueing at the head, they weren't
handled differently; unfortunately, this could lead to execution
latency of a few seconds on heavily loaded systems.

Now that workqueue code has been updated to deal with multiple
worker_pools per global_cwq, this patch reimplements WQ_HIGHPRI using
a separate worker_pool.  NR_WORKER_POOLS is bumped to two and
gcwq->pools[0] is used for normal pri work items and ->pools[1] for
highpri.  Highpri workers get -20 nice level and has 'H' suffix in
their names.  Note that this change increases the number of kworkers
per cpu.

POOL_HIGHPRI_PENDING, pool_determine_ins_pos() and highpri chain
wakeup code in process_one_work() are no longer used and removed.

This allows proper prioritization of highpri work items and removes
high execution latency of highpri work items.

v2: nr_running indexing bug in get_pool_nr_running() fixed.

v3: Refreshed for the get_pool_nr_running() update in the previous
    patch.

Change-Id: Id843c0a425f51f84083786fbf413d999d35771b7
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Josh Hunt <joshhunt00@gmail.com>
LKML-Reference: <CAKA=qzaHqwZ8eqpLNFjxnO2fX-tgAOjmpvxgBFjv6dJeQaOW1w@mail.gmail.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fengguang Wu <fengguang.wu@intel.com>
Git-commit: 3270476a6c0ce322354df8679652f060d66526dc
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
msm: rpm-smd: Configure WQ for higer priority

When the workqueue runs at a lower priority, it gets starved by higher
priority threads. Bump the WQ priority to high to ensure rpm smd work
queue gets a fair chance

Change-Id: I06b864611cf45afe6931d6030327806032894663
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
msm: cpufreq: increase priority of thread that increases frequencies

When the cpufreq governors request for increase in frequency from kworker
threads, there is chance that the kworker thread is cpu starved due to
other high priority threads, leading to undesirable increase in frequency
ramp-up latency. Add the calling thread to SCHED_FIFO policy when
requesting for increase in frequency and restore back to original policy
after ramp-up is completed.

Change-Id: Ie4fa199b7f9087717cb94dfcc2eddea27cc0012b
Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>
msm: cpufreq: Always update frequency limits when core is online

Remove condition in msm_cpufreq_init() so that when cpu is set to
online, it will call set_cpu_freq() and update the frequency limits.

CRs-Fixed: 462816
Change-Id: I40ac33c9cb4b42590a83f9d61b74f23379f5642e
Signed-off-by: Jennifer Liu <chihning@codeaurora.org>
Revert "msm: cpufreq: Remove cross-calling limitation"

This reverts commit be01a17afb6b6e85456217caa1ac11eb0b6674e1.

Re-introduce cross calling in cpufreq to prevent race conditions in the
hardware when changing PLLs.

A core could be in retention, while another core, could try and set the
frequency of the core in retention, causing a change in PLL and when the
core exits retention, the PLL mismatch could hang the SPM state machine.

Change-Id: I99b454a0f146652f2d8a369f79f6d35748160dcb
Signed-off-by: Praveen Chidambaram <pchidamb@codeaurora.org>