scsi: ufs: block requests during clock scaling
UFS clock scaling may do couple of things such as scaling UFS controller
clock frequencies and UFS interface gear scaling. To ensure that these
operations are completed successfully, driver need to make sure that there
are no regular transfer commands allowed until clock scaling is completed.
Currently we are only blocking the scsi command requests during gear
scaling but not during clock frequency scaling (and related operations).
So first fix is to block scsi requests for entire clock scaling operation,
we are doing this by invoking scsi_block_requests() and then waiting for
all pending requests (doorbells) to be completed. But this approach can not
always ensure that no new request will be issued while clock scaling is in
progress. Think of a scenario where one request just got queued via
->queuecommand() (but still haven't set the doorbell) when no doorbells
were pending and assume that clock scaling function has also started
executing in parallel. In this case clock scaling function blocks the new
scsi requests from being issued and wait for all the pending doorbells
to be cleared. As there were no doorbells pending when it checks for it,
it decides to go ahead with clock scaling but now the command with was just
issued via ->queuecommand() sets the doorbell and gets issued by
controller.
This change fixes such race condition by using the read-write semaphore
approach which basically blocks all the requests until clock scaling work
finishes but would allow multiple requests to be queued in parallel if
clock scaling work isn't running.
Change-Id: I99beed27bbc5b768fb3cee8b84cb5392619cace7
Signed-off-by:
Subhash Jadavani <subhashj@codeaurora.org>
Loading
Please register or sign in to comment