summaryrefslogtreecommitdiffstats
path: root/crypto/gcm.c
diff options
context:
space:
mode:
authorGeert Uytterhoeven <geert+renesas@glider.be>2019-05-27 14:19:35 +0200
committerMark Brown <broonie@kernel.org>2019-05-28 16:57:03 +0200
commit635bdb7a3e1fe1531573ff87b92c2506adafe7f7 (patch)
treed48f80b767751cec21a05a7c76f63c07551e3296 /crypto/gcm.c
parentMerge branch 'spi-5.2' into spi-5.3 (diff)
downloadlinux-635bdb7a3e1fe1531573ff87b92c2506adafe7f7.tar.xz
linux-635bdb7a3e1fe1531573ff87b92c2506adafe7f7.zip
spi: sh-msiof: Reduce delays in sh_msiof_modify_ctr_wait()
While the Hardware User Manual does not document the maximum time needed for modifying bits in the MSIOF Control Register, experiments on R-Car Gen2/Gen3 and SH-Mobile AG5 revealed the following typical modification times for the various bits: - CTR.TXE and CTR.RXE: no delay, - CTR.TSCKE: less than 10 ns, - CTR.TFSE: up to a few hundred ns (depending on SPI transfer clock, i.e. less for faster transfers). There are no reasons to believe these figures are different for SH-MobileR2 SoCs (SH7723/SH7724). Hence the minimum busy-looping delay of 10 µs is excessive. Reduce the delay per loop iteration from 10 to 1 us, and the maximum delay from 1000 to 100 µs. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Mark Brown <broonie@kernel.org>
Diffstat (limited to 'crypto/gcm.c')
0 files changed, 0 insertions, 0 deletions