bluetooth: Fix unusued variable warnings in bluesleep_bcm

Change-Id: I49d70cfb2eb0cca95acaabdb452db7487b86dfdb
KozmiKKernel: Updating updater-script to flash boot.img in recovery
Add SIO I/O scheduler

Conflicts:
	block/Kconfig.iosched
	block/Makefile
KozmiKKernel: mach-msm: KozmiK OC

Conflicts:
	arch/arm/configs/kozmik_defconfig
	arch/arm/mach-msm/acpuclock-krait.c
mach-msm: Switching to using custom msm-config.h

Conflicts:
	arch/arm/mach-msm/acpuclock-8064.c

Conflicts:
	arch/arm/mach-msm/acpuclock-8064.c

Conflicts:
	arch/arm/mach-msm/acpuclock-8064.c
mach-msm: acpuclock-krait: Switching VDD MIN/MAX to call values from include/mach/msm-config.h
Overclocking: limit initial max to system default

Signed-off-by: faux123 <reioux@gmail.com>
mach-msm: Setting initial max and min freq from a central file include/mach/msm-config.h

Conflicts:
	arch/arm/mach-msm/acpuclock-8064.c

Conflicts:
	arch/arm/mach-msm/cpufreq.c
mach-msm/cpufreq: set safe frequencies from config

Conflicts:
	arch/arm/mach-msm/cpufreq.c
mach-msm: Overlclocking:  Changing to use one singular freqency table. And adding min freq setup for 192mhz.

Conflicts:
	arch/arm/mach-msm/acpuclock-8064.c

Conflicts:
	arch/arm/mach-msm/acpuclock-krait.c

Conflicts:
	arch/arm/mach-msm/acpuclock-krait.c
mach-msm: msm-config: Setting min freq to 192mhz
mach-msm: acpuclock-8064: Adjusting freqencies.
mach-msm: acpuclock-8064: Adding 48000 and 96000 L2 Freq and CPU Freq

Conflicts:
	arch/arm/mach-msm/acpuclock-8064.c
drivers: cpufreq: cpufreq_ondemand: Switching from using trace/events/cpufreq_interactive.h
to trace/events/cpufreq_ondemand.h.  In addition to reverting back to HTC's ondemand with Phase 2.

Conflicts:
	drivers/cpufreq/cpufreq_ondemand.c
mach-msm: acpuclock-8064: Removing extra #endif added on accident.
mach-msm: msm_dcvs: Increasing DCVS_MAX_NUM_FREQS.

This is necessary if adding additional frequencies to acpuclock.  Without,
doing this it will not boot.
block: fiops ioscheduler core

FIOPS (Fair IOPS) ioscheduler is IOPS based ioscheduler, so only targets
for drive without I/O seek. It's quite similar like CFQ, but the dispatch
decision is made according to IOPS instead of slice.

The algorithm is simple. Drive has a service tree, and each task lives in
the tree. The key into the tree is called vios (virtual I/O). Every request
has vios, which is calculated according to its ioprio, request size and so
on. Task's vios is the sum of vios of all requests it dispatches. FIOPS
always selects task with minimum vios in the service tree and let the task
dispatch request. The dispatched request's vios is then added to the task's
vios and the task is repositioned in the sevice tree.

Unlike CFQ, FIOPS doesn't have separate sync/async queues, because with I/O
less writeback, usually a task can only dispatch either sync or async requests.
Bias read or write request can still be done with read/write scale.

One issue is if workload iodepth is lower than drive queue_depth, IOPS
share of a task might not be strictly according to its priority, request
size and so on. In this case, the drive is in idle actually. Solving the
problem need make drive idle, so impact performance. I believe CFQ isn't
completely fair between tasks in such case too.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>

Conflicts:
	block/Makefile

Conflicts:
	block/Kconfig.iosched
	block/Makefile
block: fiops read/write request scale

read/write speed of Flash based storage usually is different. For example,
in my SSD maxium thoughput of read is about 3 times faster than that of
write. Add a scale to differenate read and write. Also add a tunable, so
user can assign different scale for read and write.

By default, the scale is 1:1, which means the scale is a noop.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops sync/async scale

CFQ gives 2.5 times more share to sync workload. This matches CFQ.

Note this is different with the read/write scale. We have 3 types of
requests:
1. read
2. sync write
3. write
CFQ doesn't differentitate type 1 and 2, but request cost of 1 and 2
are usually different for flash based storage. So we have both sync/async
and read/write scale here.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops add ioprio support

Add CFQ-like ioprio support. Priority A will get 20% more share than priority
A+1, which matches CFQ.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>