ASoC: msm: Add support for meta data in compressed TX

There is a usecase where compressed data is sent over HDMI IN to
ADSP. The format of compressed is detected in ADSP and sent through
the meta data to compressed driver. Add support for meta data in
compressed TX for this use case.

Change-Id: Idbb18fe4a0ad828e9c2e9d7beec048b3cedf002d
Signed-off-by: Subhash Chandra Bose Naripeddy <snariped@codeaurora.org>
ASoc: msm: Add low latency playback and recording support.

- Add lowlatency pcm driver for Playback and Recording.
- Add support in target board files
- Add Recording Path to Multimedia5 FE DAI
- Add support in routing, platform, machine drivers
- Add low latency interfaces support in ASM and ADM drivers.

Change-Id: I1beb11db9010534e5aa91179ac6040a41622185d
Signed-off-by: Jayasena Sangaraboina <jsanga@codeaurora.org>

Conflicts:
	arch/arm/mach-msm/board-8930.c
apq8064: Add support for hdmi multichannel

Provide support for hdmi channel fixup.
Fix channel map order to WAV format.

BUG-ID: 7156174
Signed-off-by: SathishKumar Mani <smani@codeaurora.org>
lib/int_sqrt.c: optimize square root algorithm

Optimize the current version of the shift-and-subtract (hardware)
algorithm, described by John von Newmann[1] and Guy L Steele.

Iterating 1,000,000 times, perf shows for the current version:

 Performance counter stats for './sqrt-curr' (10 runs):

         27.170996 task-clock                #    0.979 CPUs utilized            ( +-  3.19% )
                 3 context-switches          #    0.103 K/sec                    ( +-  4.76% )
                 0 cpu-migrations            #    0.004 K/sec                    ( +-100.00% )
               104 page-faults               #    0.004 M/sec                    ( +-  0.16% )
        64,921,199 cycles                    #    2.389 GHz                      ( +-  0.03% )
        28,967,789 stalled-cycles-frontend   #   44.62% frontend cycles idle     ( +-  0.18% )
   <not supported> stalled-cycles-backend
       104,502,623 instructions              #    1.61  insns per cycle
                                             #    0.28  stalled cycles per insn  ( +-  0.00% )
        34,088,368 branches                  # 1254.587 M/sec                    ( +-  0.00% )
             4,901 branch-misses             #    0.01% of all branches          ( +-  1.32% )

       0.027763015 seconds time elapsed                                          ( +-  3.22% )

And for the new version:

Performance counter stats for './sqrt-new' (10 runs):

          0.496869 task-clock                #    0.519 CPUs utilized            ( +-  2.38% )
                 0 context-switches          #    0.000 K/sec
                 0 cpu-migrations            #    0.403 K/sec                    ( +-100.00% )
               104 page-faults               #    0.209 M/sec                    ( +-  0.15% )
           590,760 cycles                    #    1.189 GHz                      ( +-  2.35% )
           395,053 stalled-cycles-frontend   #   66.87% frontend cycles idle     ( +-  3.67% )
   <not supported> stalled-cycles-backend
           398,963 instructions              #    0.68  insns per cycle
                                             #    0.99  stalled cycles per insn  ( +-  0.39% )
            70,228 branches                  #  141.341 M/sec                    ( +-  0.36% )
             3,364 branch-misses             #    4.79% of all branches          ( +-  5.45% )

       0.000957440 seconds time elapsed                                          ( +-  2.42% )

Furthermore, this saves space in instruction text:

   text    data     bss     dec     hex filename
    111       0       0     111      6f lib/int_sqrt-baseline.o
     89       0       0      89      59 lib/int_sqrt.o

[1] http://en.wikipedia.org/wiki/First_Draft_of_a_Report_on_the_EDVAC

Signed-off-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
Reviewed-by: Jonathan Gonzalez <jgonzlez@linets.cl>
Tested-by: Jonathan Gonzalez <jgonzlez@linets.cl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
sched: provide per cpu-cgroup option to notify on migrations

On systems where CPUs may run asynchronously, task migrations
between CPUs running at grossly different speeds can cause
problems.

This change provides a mechanism to notify a subsystem
in the kernel if a task in a particular cgroup migrates to a
different CPU. Other subsystems (such as cpufreq) may then
register for this notifier to take appropriate action when
such a task is migrated.

The cgroup attribute to set for this behavior is
"notify_on_migrate" .

Change-Id: Ie1868249e53ef901b89c837fdc33b0ad0c0a4590
Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
ARM: Fix negative idle stats for offline cpu

We see negative idle stats because of cpu dying without
cleaning up idle entry statistics. When a cpu is offline,
the most immediate thing you'd want to do is just call
into cpu_die() and not waste time calling notifier(IDLE_START).

CRs-Fixed: 414554
Change-Id: Iadc6a3ca39997e0ccf65d2a29b004e24b1b211a1
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: Taniya Das <tdas@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
lib: rwsem: stash commits from upstream.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
sched: Set MC (multi-core) sched domain's busy_factor attribute to 1

busy_factor attribute of a scheduler domain causes busy CPUs (CPUs
that are not idle) to load balance less frequently in that domain,
which could impact performance by increasing scheduling latency for
tasks.

As an example, consider MC scheduler domain's attribute values of
max_interval = 4ms and busy_factor = 64. Further consider
max_load_balance_interval = 100 (HZ/10). In this case, a non-idle CPU
could put off load balance check in MC domain by 100ms. This
effectively means that a CPU running a single task in its queue could
fail to notice increased load on another CPU (that is in same MC
domain) for upto 100ms, before picking up load from the overloaded
CPU. Needless to say, this leads to increased scheduling latency for
tasks, affecting performance adversely.

By setting MC domain's busy_factor value to 1, we limit maximum
interval that busy CPU can put off load balance checks to 4ms
(effectively 10ms, given HZ value of 100).

Change-Id: Id45869d06f5556ea8eec602b65c2ffd2143fe060
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
mm: fix calculation of dirtyable memory

The system uses global_dirtyable_memory() to calculate number of
dirtyable pages/pages that can be allocated to the page cache.  A bug
causes an underflow thus making the page count look like a big unsigned
number.  This in turn confuses the dirty writeback throttling to
aggressively write back pages as they become dirty (usually 1 page at a
time).  This generally only affects systems with highmem because the
underflowed count gets subtracted from the global count of dirtyable
memory.

The problem was introduced with v3.2-4896-gab8fabd

Fix is to ensure we don't get an underflowed total of either highmem or
global dirtyable memory.

Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Signed-off-by: Puneet Kumar <puneetster@chromium.org>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Tested-by: Damien Wyart <damien.wyart@free.fr>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Add ACCESSORY_SET_AUDIO_MODE control request and ioctl

The control request will be used by the host to enable/disable USB audio
and the ioctl will be used by userspace to read the audio mode

Signed-off-by: Mike Lockwood <lockwood@google.com>
Change-Id: I48082ce473eb6577b0bf613be9ec27f2f5c19384
USB: gadget: f_accessory: Add support for HID input devices

Signed-off-by: Mike Lockwood <lockwood@google.com>
Change-Id: I4f5722bfa26a0d73419c54709b2f1672491bf56a
USB: gadget: f_audio_source: New gadget driver for audio output

This driver presents a standard USB audio class interface to the host
and an ALSA PCM device to userspace

Signed-off-by: Mike Lockwood <lockwood@google.com>
Change-Id: Ie20264ac86d21a1b1366491273034b755366d3c3

Conflicts:
	drivers/usb/gadget/android.c
Revert "msm: pm-8x60: save and restore CP15 registers"

This reverts commit 87fa40c1e6612ea834e2f2ec9a76d6157d04af1e.
msm: pm-8x60: Check for SPM status in msm_pm_verify_cpu_pc

Verify that SPM is in sleep mode in msm_pm_verify_cpu_pc. If not, it is
possible that msm_pm_wait_cpu_shutdown could fail but acpuclock would
turn off the clocks based on the the return value of
msm_pm_verify_cpu_pc.

CRs-fixed: 376791
Change-Id: Id55019508ea9bc27106eb298e19988aecc055cac
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
msm: pm-stats: fix the bug in pm stats refactor

Return value of msm_timer_get_sclk_time api is int64_t. Storing the
return value in integer would lead to inconsistencies in pm_stats.

CRs-fixed: 375038
Change-Id: I2c73b387ef01db3a7f71cd1b21b135bea2a475fa
Signed-off-by: Anji Jonnala <anjir@codeaurora.org>
msm: pm-8x60: Remove msm_pm_wait_cpu_shutdown()/verify_cpu_pc() APIs

The APIs are currently unused. They were added for the benefit of
the acpuclock-8960 driver, which needed them to ensure that CPUs
were really power-collapsed before their clocks were disabled.

The current acpuclock-krait driver solves this problem a different
way, by taking advantage of hardware features that were not
available in early (unreleased) versions of the Krait cores. Now,
instead of disabling the CPUs' clocks, a low-frequency always-on
clock source is selected and hardware clock gating is employed to
save power. With this, it is no longer necessary to wait for the
SPM to confirm the CPU has power-collapsed before acpuclock's
CPU_DEAD callback executed.

Change-Id: If93efea7c0bd4bb2943e1a1782217943eacf31a0
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
msm: pm-8x60: Unconditionally support WFI hotplug

Using the irqsoff tracer and hotplugging a CPU with nothing in
the 'suspend allowed' mask causes the preempt count for the new
CPU to become less than 0 (0xfffffffe usually). This is because
the hotplug code is never actually doing any sort of hotplug.

Instead it's running a tight loop of

	msm_pm_cpu_enter_lowpower()
	if (pen_release == cpu_logical_map(cpu)) {
		...
	}
	dmac_inv_range(&pen_release);

and ftrace is recording the branching back and forth to
msm_pm_cpu_enter_lowpower(). While this is going on, the other
CPU that's bringing the "not actually" hotplugged CPU back online
goes and reinitializes the idle task for the hotplugged CPU. The
assumption in the cpu bringup code is that the CPU is not
actually running so it's safe to mess with that CPUs idle task.
This assumption is broken when no sorts of hotplug are allowed.

Fix this by unconditionally supporting WFI hotplug. This way, no
matter what, hotplug will put the CPU into some low power state
where it's safe to modify the CPUs idle task state.

Change-Id: I456673a3223dd294585a12da0fd0641a84626c52
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
msm: pm-8x60: fix timeout bug issue in suspend processing

if msm_rpm_request is not NULL, it is not expected to enter the
power collapse of CPU0. msm_rpm_local_request_is_outstanding is
check if msm_rpm_request is NULL or not. this check routine is
added to msm_pm_idle_prepare for fix timeout issue in suspend
processing.

Change-Id: I02cb344e451a0893f4c8dce88d0a564d55839f01
msm: pm: Support for Krait Retention

Introduce a new low power state for Krait, retention.
This state will lower the voltage to the Krait core to
retention voltage in addition to clock gating. This state
will be in between WFI and Standalone power collapse in
terms of time overhead and power savings.

Change-Id: I6b1f0a0d2e4954a705a047fd4a07f4dd1fb3518a
Signed-off-by: Girish Mahadevan <girishm@codeaurora.org>
(cherry picked from commit d27ca4a7526a890f9d2979acefda3561e49d2e66)

Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
(cherry picked from commit 3af7249c36ab53923fdf216df3b3ba2c7f847851)
EHCI: HSIC: Add support to vote for SVS digital voltage

HSIC HW can operate at SVS digital voltage when it is active.
Currently HSIC is voting for 120Mhz SFAB and 64Mhz DFAB clock
frequencies. Clock frequencies are directly proportional to SVS
voltage. If DFAB is running at 64Mhz or SFAB is running at 120Mhz
or higher SVS is not possible even though HSIC votes for it. Hence
do not vote for SFAB clock frequency and only vote for 32Mhz for
DFAB in order to allow SVS to happen. Voting for SVS voltage reduces
current consumption by 3mA in HSDPA network.

Change-Id: I8a6844efbbe90a8ea118be8450f8210717c2641b
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
(cherry picked from commit cdf7fd212e2761525c07b842eb630677777cb3e5)
(cherry picked from commit f7f368826935049e7ffdb482865c47a3badcd147)