block: implement runtime pm strategy

When a request is added:
    If device is suspended or is suspending and the request is not a
    PM request, resume the device.

When the last request finishes:
    Call pm_runtime_mark_last_busy().

When pick a request:
    If device is resuming/suspending, then only PM request is allowed
    to go.

The idea and API is designed by Alan Stern and described here:
http://marc.info/?l=linux-scsi&m=133727953625963&w=2

Change-Id: If9c8332164afba6aeca984277e3398008ad9c45a
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Git-commit: c8158819d506a8aedeca53c52dfb709a0aabe011
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
block: allow REQ_PM requests even when the device is suspended

Some times even though the block device is suspended by the block layer
the low-level driver might want to queue the PM requests to the device.
Allow such requests to get peeked as the blk_pm_add_request() has already
added it to the I/O scheduler otherwise the request would be forever stuck
in the I/O scheduler without being fetched by the driver.

Change-Id: I353943a7008ea1d92ff825d220cad1828fe37c27
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
block: do not notify urgent request, when flush with data in flight

MMC device driver implements URGENT request execution with priority
(using stop flow), as a result currently running (and prepeared) request
may be reinserted back into I/O scheduler. This will break block layer
logic of flushes (flush request should not be inserted into I/O scheduler).

Block layer flush machinery keep q->flush_data_in_flight list updated with
started but not completed flush requests with data (REQ_FUA).

This change will not notify underling block device driver about pending
urgent request during flushes in flight.

Change-Id: I98113621223fe0c7d224de023db888a73bd62b48
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>