On Tuesday, July 09, 2013, Sujit Reddy Thumma wrote:
From: Dolev Raviv dra...@codeaurora.org
Allow UFS device to complete its initialization and accept
SCSI commands by setting fDeviceInit flag. The device may take
time for this operation and hence the host should poll until
fDeviceInit flag
On 7/10/2013 6:58 PM, Seungwon Jeon wrote:
On Tue, July 09, 2013, Sujit Reddy Thumma wrote:
As part of device initialization sequence, sending NOP OUT UPIU and
waiting for NOP IN UPIU response is mandatory. This confirms that the
device UFS Transport (UTP) layer is functional and the host can
On 7/10/2013 7:01 PM, Seungwon Jeon wrote:
I'm not sure that BKOPS with runtime-pm associates.
Do you think it's helpful for power management?
How about hibernation scheme for runtime-pm?
I'm testing and I can introduce soon.
Well, I am thinking on following approach when we introduce
power
On 7/10/2013 7:01 PM, Seungwon Jeon wrote:
On Tue, July 09, 2013, Sujit Reddy Thumma wrote:
Add runtime PM helpers to suspend/resume UFS controller at runtime.
Enable runtime PM by default for pci and platform drivers as the
initialized hardware can suspend if it is not used after bootup.
In order to decrease the latency of a prioritized request (such as READ
requests) the device driver might decide to stop the transmission of a
current low priority request in order to handle the high priority one.
The urgency of the request is decided by the block layer I/O scheduler.
When the
Add support for reinserting a dispatched request back to the
scheduler's internal data structures.
This capability is used by the device driver when it chooses to
interrupt the current request transmission and execute another (more
urgent) pending request. For example: interrupting long write in
From: Jens Axboe ax...@kernel.dk
We have officially run out of flags in a 32-bit space. Extend it
to 64-bit even on 32-bit archs.
Signed-off-by: Jens Axboe ax...@kernel.dk
diff --git a/block/blk-core.c b/block/blk-core.c
index 93a18d1..cfa4dd3 100644
--- a/block/blk-core.c
+++
This patch add support in block elevator layers for handling
urgent requests. The decision if a request is urgent or not is taken
by the scheduler. Request is marked as urgent in cmd_flags (by the
scheduler) with a new flag - REQ_URGENT.
Urgent request notification is passed to the underlying
When the scheduler reports to the block layer that there is an urgent
request pending, the device driver may decide to stop the transmission
of the current request in order to handle the urgent one. This is done
in order to reduce the latency of an urgent request. For example:
long WRITE may be
On Thu, Jul 11, 2013 at 6:31 PM, Tanya Brokhman tlin...@codeaurora.org wrote:
When the scheduler reports to the block layer that there is an urgent
request pending, the device driver may decide to stop the transmission
of the current request in order to handle the urgent one. This is done
in
Tanya Brokhman tlin...@codeaurora.org writes:
When the scheduler reports to the block layer that there is an urgent
request pending, the device driver may decide to stop the transmission
of the current request in order to handle the urgent one. This is done
in order to reduce the latency of
11 matches
Mail list logo
