usb: gadget: mass_storage: added sysfs entry for cdrom to LUNs

This patch adds a "cdrom" sysfs entry for each mass_storage LUN, just
like "ro" sysfs entry. This allows switching between USB and CD-ROM
emulation without reinserting the module or recompiling the kernel.

Change-Id: Idf83c74815b1ad370428ab9d3e5503d5f7bcd3b6
added overclock upto 2.5GHz
enabled overclock in defconfig
cap bootup frequencies in defconfig
added kernel level Sound Control GPL interface (thanks to @faux123)
Sound Control: Added headphone poweramp controls

bump version to 2.1 to reflec this new addition

Signed-off-by: Paul Reioux <reioux@gmail.com>
sound/soc/codecs/wcd9310.c: expose additional controls
sound control 3.x: Initial GPL release for WCD9310 Audio Codec

This is first official GPL release based on my private implementation.

This release has been tested for Mako and Flo officially.  It may work
with other devices using the same WCD9310 Audio Codec as well, but not tested

Signed-off-by: Paul Reioux <reioux@gmail.com>
added optimizations for compiling (thanks to @franciscofranco)
added CPU freq governor wheatley (thanks to @Ezekeel)
msm_cpu_freq_limit: module for controlling MSM quadcore cpus along with fixes (thanks to @faux123)

this module will allow proper max frequency control across all msm cores

Signed-off-by: faux123 <reioux@gmail.com>
overall_stats: add overall stats for all available cores

this is much more accurate stats tracking than just displaying core 0's
stats from most other kernels

Signed-off-by: faux123 <reioux@gmail.com>
overall_stats: make dual/quad core stats configurable via meunconfig

Signed-off-by: faux123 <reioux@gmail.com>
overall_stats: forward port to kernel 3.4+

by replacing deprecated functions with native add/sub for 64bit data types

Signed-off-by: faux123 <reioux@gmail.com>
block: add simple io scheduler
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>
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>
block: fiops preserve vios key for deep queue depth workload

If the task has running request, even it's added into service tree newly,
we preserve its vios key, so it will not lost its share. This should work
for task driving big queue depth. For single depth task, there is no approach
to preserve its vios key.

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