Added missing boot animation binary to support custom boot animations
mach-exynos: Support for current CPU temperature reading from Exynos4 TMU driver
boeffla_defconfig: Enable support for CPU temperature reading from Exynos4 TMU
cpufreq: Update to ZZMoove v0.9 beta4

Changelog:

- removed 'freq_step' functionality as it never had any function in this governor. it was a left over from mialwes 'smoove' governor and also
  had no function in his governor back then. so yeah all the 'feelings' about it's influence were placebo :)
- introduced 'proportional scaling' for more 'connectivity' to current load, this should give more 'balanced' frequencies
  in general. when enabled all targeted frequencies in scaling logic will be compared with the ones from system table method and at the end
  the lowest of them both will be used. so all used scaling frequencies will be 'tentential' lower in both directions
- added support for exynos4 CPU temperature reading (patches available in zzmoove repositories: https://github.com/zanezam)
  this must be enabled via 'CONFIG_EXYNOS4_EXPORT_TEMP=y' in the config of a kernel which has exynos4 CPU temperature export implementation
  included. the default temp polling interval is 1000 ms and can be set with DEF_TMU_READ_DELAY. however the TMU driver has it's own polling
  interval which is 10 seconds, so leaving it at the default value of 1 second is recommended temperature reading will only be enabled if the
  tuneable 'scaling_block_temp' is set and will be disabled whenever early suspend is entered
- if exynos4 CPU temperature reading is enabled in the code use current CPU temperature in scaling block functionality to be able to 'hold' the cpu
  temperatue to the given one in 'scaling_block_temp'. this function is used in combination with the already existent tuneable 'scaling_block_freq'
  so u have to set both to enable it. the possible temperature range is 30°C to 80°C (lower temps are making no sense and higher temps would reach
  into exynos4 TMU driver trottling range)
- if exynos4 CPU temperature reading is enabled added current CPU temperature to debug info tuneable
- added auto adjustment of all available frequency thresholds when scaling max limit has changed
- improved sampling rate idle switching by making it scaling thresholds independent
- again some code style and comment changes/fixes

profile header file (Version 0.2 beta3):

- added scaling block temperature tuneable to all profiles if CONFIG_EXYNOS4_EXPORT_TEMP is defined
- use CPU temperature treshold of 65°C instead of 15 scaling block cycles in game profile if
  CONFIG_EXYNOS4_EXPORT_TEMP is defined
- added proportional frequency tuneable to all profiles
- added auto adjust freq thresholds to all profiles (disabled by default)
- enabled scaling proportional in ybat, ybatext, zzbat, zzbatp, zzmod and zzgame profile
- enabled scaling fast down over 1200MHz and resposiveness over 400Mhz with up threshold of 20
  in ybat, ybatext, zzbat, zzbatp, and zzmod profile
- added core macros to exclude not used code like it is in governor
- removed freq_step tuneable from all profiles
Boeffla ramfs: Add knockon delay slider configuration for boeffla-config
Boeffla ramfs: Fix error in touchwake parametrization creating exceptions in boeffla config
Revert "block, bfq: add Early Queue Merge (EQM) to BFQ-v7r2 for 3.0.0"

This reverts commit 15af68463f7c24ab8716b3dee08d184906bfc503.
Revert "block: introduce the BFQ-v7r2 I/O sched for 3.0"

This reverts commit e74da47c3f750668474cdf0cffe948d5f7e19620.
Revert "block: cgroups, kconfig, build bits for BFQ-v7r2-3.0"

This reverts commit cfd3d5150bff2a7da345ea5aaadc8bc879a12f1b.
Revert "block: prepare I/O context code for BFQ-v7r2 for 3.0"

This reverts commit ea1b0baa5df08e24c1806b5003d9f3e5c32fa7d8.
block: prepare I/O context code for BFQ-v7r5 for 3.0

BFQ uses struct cfq_io_context to store its per-process per-device data,
reusing the same code for cic handling of CFQ.  The code is not shared
ATM to minimize the impact of these patches.

This patch introduces a new hlist to each io_context to store all the
cic's allocated by BFQ to allow calling the right destructor on module
unload; the radix tree used for cic lookup needs to be duplicated
because it can contain dead keys inserted by a scheduler and later
retrieved by the other one.

Update the io_context exit and free paths to take care also of
the BFQ cic's.

Change the type of cfqq inside struct cfq_io_context to void *
to use it also for BFQ per-queue data.

A new bfq-specific ioprio_changed field is necessary, too, to avoid
clobbering cfq's one, so switch ioprio_changed to a bitmap, with one
element per scheduler.

Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
block: cgroups, kconfig, build bits for BFQ-v7r5-3.0

Add a Kconfig option and do the related Makefile changes to compile
the BFQ I/O scheduler.  Also add the bfqio controller to the cgroups
subsystem.

Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
block: introduce the BFQ-v7r5 I/O sched for 3.0

Add the BFQ-v7r5 I/O scheduler to 3.0.
The general structure is borrowed from CFQ, as much code. A (bfq_)queue is
associated to each task doing I/O on a device, and each time a scheduling
decision has to be made a queue is selected and served until it expires.

    - Slices are given in the service domain: tasks are assigned budgets,
      measured in number of sectors. Once got the disk, a task must
      however consume its assigned budget within a configurable maximum time
      (by default, the maximum possible value of the budgets is automatically
      computed to comply with this timeout). This allows the desired latency
      vs "throughput boosting" tradeoff to be set.

    - Budgets are scheduled according to a variant of WF2Q+, implemented
      using an augmented rb-tree to take eligibility into account while
      preserving an O(log N) overall complexity.

    - A low-latency tunable is provided; if enabled, both interactive and soft
      real-time applications are guaranteed very low latency.

    - Latency guarantees are preserved also in presence of NCQ.

    - Also with flash-based devices, a high throughput is achieved while
      still preserving latency guarantees.

    - Useful features borrowed from CFQ: cooperating-queues merging (with
      some additional optimizations with respect to the original CFQ version),
      static fallback queue for OOM.

    - BFQ supports full hierarchical scheduling, exporting a cgroups
      interface.  Each node has a full scheduler, so each group can
      be assigned its own ioprio (mapped to a weight, see next point)
      and an ioprio_class.

    - If the cgroups interface is used, weights can be explictly assigned,
      otherwise ioprio values are mapped to weights using the relation
      weight = IOPRIO_BE_NR - ioprio.

    - ioprio classes are served in strict priority order, i.e., lower
      priority queues are not served as long as there are higher priority
      queues.  Among queues in the same class the bandwidth is distributed
      in proportion to the weight of each queue. A very thin extra bandwidth
      is however guaranteed to the Idle class, to prevent it from starving.

Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
block, bfq: add Early Queue Merge (EQM) to BFQ-v7r5 for 3.0.0

A set of processes may happen  to  perform interleaved reads, i.e., requests
whose union would give rise to a  sequential read  pattern.  There are two
typical  cases: in the first  case,   processes  read  fixed-size chunks of
data at a fixed distance from each other, while in the second case processes
may read variable-size chunks at  variable distances. The latter case occurs
for  example with QEMU, which  splits the  I/O generated  by the  guest into
multiple chunks,  and lets these chunks  be served by a  pool of cooperating
processes,  iteratively  assigning  the  next  chunk of  I/O  to  the first
available  process. CFQ  uses actual  queue merging  for the  first type of
rocesses, whereas it  uses preemption to get a sequential  read pattern out
of the read requests  performed by the second type of  processes. In the end
it uses  two different  mechanisms to  achieve the  same goal: boosting the
throughput with interleaved I/O.

This patch introduces  Early Queue Merge (EQM), a unified mechanism to get a
sequential  read pattern  with both  types of  processes. The  main idea is
checking newly arrived requests against the next request of the active queue
both in case of actual request insert and in case of request merge. By doing
so, both the types of processes can be handled by just merging their queues.
EQM is  then simpler and  more compact than the  pair of mechanisms used in
CFQ.

Finally, EQM  also preserves the  typical low-latency properties of BFQ, by
properly restoring the weight-raising state of  a queue when it gets back to
a non-merged state.

Signed-off-by: Mauro Andreolini <mauro.andreolini@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
su: update su to version 2.02
boeffla_defconfig: Enable external USB web cam support (CONFIG_USB_VIDEO_CLASS)
vmscan: Fix zRam
Release tag: 1.1-beta2