Revert "block: fix BFQ build for the last patch"

This reverts commit 08eaba460516b7665dc18ae5e1b75de97c9767a7.
Revert "iosched: prevent aliased requests from starving other I/O"

This reverts commit 8f05924d9bcf95b89cb91fe4c041b1835cb338be.
block: introduce the BFQ-v5 I/O sched for 3.0

Add the BFQ-v5 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 taken a queue is selected and it is 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.

    - High throughput with flash-based devices, 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 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 weights 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>
staging: zcache: changes to fix linking and crashing issue

copied from android_kernel_samsung_d2 in CyanogenMod
msm_fb: display: Fix blend configuration for MDDI I/F

MDP4.0 blend operation registers are not double buffered and
take effect as soon as they are configured. Configuring these
registers at any place other than between dma and vsync produce
flickers as new blend values would get applied to previous
mixer configurations. Configure blend operation registers just
after dma is over, before vsync.

CRs-Fixed: 410029
Change-Id: I2d04b2edb1e6592ac192fd00d302d8941a56ad69
Signed-off-by: Jeevan Shriram <jshriram@codeaurora.org>
Switch to board-saga-audio.c from HTC kernel