summaryrefslogtreecommitdiff
path: root/drivers/pci/doe.c
diff options
context:
space:
mode:
authorMartin K. Petersen <martin.petersen@oracle.com>2024-05-31 03:36:08 +0300
committerMartin K. Petersen <martin.petersen@oracle.com>2024-05-31 03:36:08 +0300
commit23646f013404a69e2cc5b1be51eef67e720d7021 (patch)
treec5c1e214ada3e74af18ff4a37f82902464386aa7 /drivers/pci/doe.c
parent96281dfa266d333522c004205acc5ff1e9e3a337 (diff)
parent600edc6620a4380b9f6027f293dac09eb0f22048 (diff)
downloadlinux-23646f013404a69e2cc5b1be51eef67e720d7021.tar.xz
Merge patch series "scsi: ufs: Allow RTT negotiation"
Avri Altman <avri.altman@wdc.com> says: 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. Link: https://lore.kernel.org/r/20240530142510.734-1-avri.altman@wdc.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Diffstat (limited to 'drivers/pci/doe.c')
0 files changed, 0 insertions, 0 deletions