block: introduce the BFQ-v7r5 I/O sched for 3.4
Add the BFQ-v7r5 I/O scheduler to 3.4.
The general structure is borrowed from CFQ, as much of the code for
handling I/O contexts. Over time, several useful features have been
ported from CFQ as well (details in the changelog in README.BFQ). 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 a very low latency.

    - Latency guarantees are preserved also in the presence of NCQ.

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

    - BFQ features Early Queue Merge (EQM), a sort of fusion of the
      cooperating-queue-merging and the preemption mechanisms present
      in CFQ. EQM is in fact a unified mechanism that tries to get a
      sequential read pattern, and hence a high throughput, with any
      set of processes performing interleaved I/O over a contiguous
      sequence of sectors.

    - BFQ supports full hierarchical scheduling, exporting a cgroups
      interface.  Since each node has a full scheduler, each group can
      be assigned its own weight.

    - If the cgroups interface is not used, only I/O priorities can be
      assigned to processes, with ioprio values mapped to weights
      with 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.4.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>

Conflicts:
	block/bfq.h
Lower minimum voltage
msm: slimbus: remove default drivers
slimbus: Add Qualcomm Slimbus driver

Signed-off-by: David Brown <davidb@codeaurora.org>
slimbus: Modify check for empty slots

There was a corner case where the open slot count was going -ve
indicating that there are no slots left for messaging. The current
check to ensure non-zero messaging slots does not take that into
account. This commit fixes that check.

CRs-fixed: 370229
Change-Id: I832ce0a26f1919d3d03b4ef0311603a5a778685e
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
slimbus: Disconnect source port if source end is removed by client

If source end of a channel removes its vote, it should be allowed to
be reclaimed by other client (or by other source port by same client)
who wants to be the source for this channel.

CRs-Fixed: 376731
Change-Id: Ia30c6a4b07de7df98cde8bc928205b4f4598036d
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
slimbus: Export clock pause function

Previously this function was left-out to be exported by mistake.
Exporting the function helps any caller driver to be a module.

Change-Id: I2b9caca62821caea5ae92123689c6f8ddf2b207a
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
slim:msm: Change to register access for RX path if required

MSM controller for slimbus usually uses a BAM pipe to receive control
data. However, some targets may not have a BAM pipe assinged for
receiving this data. In that case, RX data should be received using
direct register access instead.
Introduce a Device-Tree property to change this access.

Change-Id: I9bb1502f25e0e855937bc6fb4131f55348d04794
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
slimbus: Fix channel concurrent usage during reconfiguration sequence

Reconfiguration sequence can lead to changes in channel segment
distribution and state. Since multiple clients can use 1 channel,
make sure channels cannot be manipulated when reconfiguration
sequence is in progress, and make sure that client doesn't send
reconfiguration sequence when no changes are pending to be sent
in the sequence from it.

CRs-Fixed: 383406
Change-Id: Ib5f0bc32f67f51f118fa417a2e580c8dc87ef0d0
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
slimbus: Callback to indicate device report present message

Clients can register a callback (just like probe) and that callback
will be called when the client's device reports present per slimbus
specification. The callback is hosted in a workqueue to avoid doing
it in same context from which probe is called (and/or in the context
receiving report present message). Callback is called when the device
reports present for the first time after the bus is initialized.

Change-Id: I8396b87121950f99a09764d497bf2d4b1535565d
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
slim: msm: Control interface clock if it's specified

Some platforms (e.g. 8974) have interface clock that is not ON by
default. Turn it ON during probe, and control it like core clock
if it needs to be controlled.

Change-Id: Ifffb4b7ea9afb5f3f1208b4b2b6638594ffca541
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
slimbus: Add slave devices to controller after controller HW is up

Register controller is only responsible for making sure slimbus
controller structure is initialized with framework. This should not
assume that slimbus controller's hardware programming is done (e.g. if
slave's probe is trying to get logical address, then that will fail if
controller is registered, but slimbus hardware programming is not
complete, since probe is called synchrounously when device is added.
So this API separates register controller from slave device
registration. It should be called by controller when its hardware
programming is complete.

Change-Id: I52fa5567fc072951c89f99c70507aa3b1e4e22af
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
slimbus: Defer probing slimbus until ADSP is ready

If slimbus master resides in ADSP, slimbus driver has to wait until it's
up and running.  Do probe deferral until ADSP is ready.

Change-Id: I31ba4e270331c3b5250758f604d0d0cde9537427
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
slim_msm: Keep track of satellite reconfiguring a channel

With mutiple clients able to use the same channel, it is not correct
assumption that a channel was active due to satellite client's
reconfiguration only. So during sub-system restart of a satellite,
rely on satellite-reconfiguration vote for a channel instead of
channel status to remove channels that were setup by the satellite
before sub-system restart.

CRs-Fixed: 389514
Change-Id: I825381f15cb55396fece5b390d395c7f0a7580ff
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
slimbus: Decrement channel reference during reconfigure now

Slimbus clients can specify multiple add/remove channel requests
through control_ch API, followed by reconfiguration request (also
known as "commit request"). Clients may rely on the reconfiguration
request to actuate the channel activation/removal and not the
control-channel API.
So the channel reference should be decremented during reconfiguration
request, and not control_ch API.

CRs-Fixed: 389518
Change-Id: Id6ff57c6a4cad878e35004937fb08daf3b9afe7b
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
slimbus: Clear slimbus read transaction if synchronous read fails

Failed read transaction is removed from the table of active
transactions if the transaction fails

CRs-fixed: 396237
Change-Id: Idda4d8b5fa2cdfde8a049cc4af4d92e9e57f678a
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
slim_msm: Retry initial sequence messages

Initial sequence messages (logical address assignment, and master
capability message) are very important messages to enable the
devices. It is possible that the device may NACK these messages
initially if it is in process of acquiring sync.
If these type of messages fail, retry a few times before actually
deeming the device unresponsive. Log the registers in case of NACKs
to better analyze the reason.

CRs-fixed: 396230
Change-Id: If0824f7ba962dbce068756e810a7bad8342373ec
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
slim_msm: Satellite channel should not be deallocated more than once

It is possible that satellite channel deallocation is requested more
than once. (e.g. if the satellite times out waiting for response from
previous removal, then it will request removal again during
channel deallocation from its side).
Make sure that does not result in deallocating the channel more than
once.

CRs-fixed: 395926
Change-Id: I002635849bcaa7309de1fbddf1127c456bca6f20
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
slim_msm: Move out common functionality from MSM controller driver

Starting with new platforms, MSM slimbus controller can operate in
master mode or satellite mode. (Not in both modes for the same build)
Move out common functional code from the controller driver that can
be reused by satellite mode and master mode.

Change-Id: Idbc3fa93067f67f645981071ff6ad457c284576f
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>