diff options
author | Martin K. Petersen <martin.petersen@oracle.com> | 2024-05-31 03:36:08 +0300 |
---|---|---|
committer | Martin K. Petersen <martin.petersen@oracle.com> | 2024-05-31 03:36:08 +0300 |
commit | 23646f013404a69e2cc5b1be51eef67e720d7021 (patch) | |
tree | c5c1e214ada3e74af18ff4a37f82902464386aa7 /drivers/dma | |
parent | 96281dfa266d333522c004205acc5ff1e9e3a337 (diff) | |
parent | 600edc6620a4380b9f6027f293dac09eb0f22048 (diff) | |
download | linux-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/dma')
0 files changed, 0 insertions, 0 deletions