The rtt-upiu packets precede any data-out upiu packets, thus synchronizing the data input to the device: this mostly applies to write operations, but there are other operations that requires rtt as well. There are several rules binding this rtt - data-out dialog, specifically There can be at most outstanding bMaxNumOfRTT such packets. This might have an effect on write performance (sequential write in particular), as each data-out upiu must wait for its rtt sibling. UFSHCI expects bMaxNumOfRTT to be min(bDeviceRTTCap, NORTT). However, as of today, there does not appear to be no-one who sets it: not the host controller nor the driver. It wasn't an issue up to now: bMaxNumOfRTT is set to 2 after manufacturing, and wasn't limiting the write performance. UFS4.0, and specifically gear 5 changes this, and requires the device to be more attentive. This doesn't come free - the device has to allocate more resources to that end, but the sequential write performance improvement is significant. Early measurements shows 25% gain when moving from rtt 2 to 9. Therefore, set bMaxNumOfRTT to be min(bDeviceRTTCap, NORTT) as UFSHCI expects. v4 -> v5: Quiesce the queues before writing bMaxNumOfRTT (Bart) Make bDeviceRTTCap available in ufshcd_device_params_init() (Bart) v3 -> v4: Allow bMaxNumOfRTT to be configured via sysfs (Bart) v2 -> v3: Allow platform vendors to take precedence having their own rtt negotiation mechanism (Peter) v1 -> v2: bMaxNumOfRTT is a Persistent attribute - do not override if it was written (Bean) Avri Altman (3): scsi: ufs: Allow RTT negotiation scsi: ufs: Allow platform vendors to set rtt scsi: ufs: sysfs: Make max_number_of_rtt read-write Documentation/ABI/testing/sysfs-driver-ufs | 14 +++-- drivers/ufs/core/ufs-sysfs.c | 72 +++++++++++++++++++++- drivers/ufs/core/ufshcd-priv.h | 12 ++++ drivers/ufs/core/ufshcd.c | 53 ++++++++++++---- include/ufs/ufs.h | 2 + include/ufs/ufshcd.h | 4 ++ include/ufs/ufshci.h | 1 + 7 files changed, 139 insertions(+), 19 deletions(-) -- 2.34.1
