Created attachment 219721 [details]
Kernel configuration

Steps to reproduce:

* Armada 385 board (88F6820)
* Linux 4.4.10 (or later up to Linux 4.7-rc3)
* Marvell-cesa enabled on kernel configuration (full conf as attachment)
* Device tree: armada-385-db-ap.dts

# cryptsetup benchmark --cipher aes-cbc


Actual results:

Kernel messages during boot:

marvell-cesa f1090000.crypto: CESA device successfully registered
mv_xor f1060800.xor: Marvell shared XOR driver
mv_xor f1060800.xor: Marvell XOR (Registers Mode): ( xor cpy intr )
mv_xor f1060900.xor: Marvell shared XOR driver
mv_xor f1060900.xor: Marvell XOR (Registers Mode): ( xor cpy intr )

Cryptsetup benchmark never completes and the device locks up.

Expected results:
Cryptsetup benchmark completed.



Additional information:

After some testing and debugging, I can workaround this issue by disabling TDMA:
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -239,7 +239,7 @@ static const struct mv_cesa_caps armada_xp_caps = {
        .ncipher_algs = ARRAY_SIZE(armada_370_cipher_algs),
        .ahash_algs = armada_370_ahash_algs,
        .nahash_algs = ARRAY_SIZE(armada_370_ahash_algs),
-       .has_tdma = true,
+       .has_tdma = false,
 };

 static const struct of_device_id mv_cesa_of_match_table[] = {

After patching I can run the cryptsetup benchmark with following results:
 # Tests are approximate using memory only (no storage IO).
 #  Algorithm | Key |  Encryption |  Decryption
      aes-cbc   256b    51.0 MiB/s    50.5 MiB/s

Performance is slightly better than without acceleration which is approx. 25 MiB/s.

The device still hangs after a couple of crypto tasks, e.g. when writing a few hundred MiB of data to btrfs which is on top of luks.

I'm using Linux-yocto 4.4.10 and tried to update drivers/crypto/marvell and drivers/dma/mv_xor.* to Linux 4.7-rc3-version. I haven't noticed any difference with 4.4.10 -version.

I'm primarily using a custom dts, but I tested with an unmodified armada-385-db-ap.dts with the same results.