From the UFSHCI 4.0 specification, about the MCQ mode: "Command Submission 1. Host SW writes an Entry to SQ 2. Host SW updates SQ doorbell tail pointer Command Processing 3. After fetching the Entry, Host Controller updates SQ doorbell head pointer 4. Host controller sends COMMAND UPIU to UFS device" In other words, in MCQ mode, UFS controllers are required to forward commands to the UFS device in the order these commands have been received from the host. This patch improves performance as follows on a test setup with UFSHCI 4.0 controller: - When not using an I/O scheduler: 2.3x more IOPS for small writes. - With the mq-deadline scheduler: 2.0x more IOPS for small writes. Reviewed-by: Avri Altman Reviewed-by: Can Guo Cc: Bao D. Nguyen Cc: Martin K. Petersen Signed-off-by: Bart Van Assche --- drivers/ufs/core/ufshcd.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c index 9a43102b2b21..c980857db9e2 100644 --- a/drivers/ufs/core/ufshcd.c +++ b/drivers/ufs/core/ufshcd.c @@ -5324,6 +5324,13 @@ static int ufshcd_sdev_configure(struct scsi_device *sdev, struct ufs_hba *hba = shost_priv(sdev->host); struct request_queue *q = sdev->request_queue; + /* + * The write order is preserved per MCQ. Without MCQ, auto-hibernation + * may cause write reordering that results in unaligned write errors. + */ + if (hba->mcq_enabled) + lim->features |= BLK_FEAT_ORDERED_HWQ; + lim->dma_pad_mask = PRDT_DATA_BYTE_COUNT_PAD - 1; /*