AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-12-02 16:46:41 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
1a94acf858
linux_dsm_epyc7002/Documentation/devicetree/bindings/crypto/mv_cesa.txt

34 lines
1.2 KiB
Plaintext
Raw Normal View History

Crypto: CESA: Add support for DT based instantiation. Based on work by Michael Walle and Jason Cooper. Added support for getting the interrupt number and address of SRAM from DT. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net> Conflicts: arch/arm/mach-kirkwood/board-dt.c
2012-09-04 01:29:34 +07:00
Marvell Cryptographic Engines And Security Accelerator
Required properties:
crypto: mv_cesa - explicitly define kirkwood and dove compatible strings We are about to add a new driver to support new features like using the TDMA engine to offload the CPU. Orion, Dove and Kirkwood platforms are already using the mv_cesa driver, but Orion SoCs do not embed the TDMA engine, which means we will have to differentiate them if we want to get TDMA support on Dove and Kirkwood. In the other hand, the migration from the old driver to the new one is not something all people are willing to do without first auditing the new driver. Hence we have to support the new compatible in the mv_cesa driver so that new platforms with updated DTs can still attach their crypto engine device to this driver. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-18 20:46:19 +07:00
- compatible: should be one of the following string
"marvell,orion-crypto"
"marvell,kirkwood-crypto"
"marvell,dove-crypto"
crypto: mv_cesa - use gen_pool to reserve the SRAM memory region The mv_cesa driver currently expects the SRAM memory region to be passed as a platform device resource. This approach implies two drawbacks: - the DT representation is wrong - the only one that can access the SRAM is the crypto engine The last point is particularly annoying in some cases: for example on armada 370, a small region of the crypto SRAM is used to implement the cpuidle, which means you would not be able to enable both cpuidle and the CESA driver. To address that problem, we explicitly define the SRAM device in the DT and then reference the sram node from the crypto engine node. Also note that the old way of retrieving the SRAM memory region is still supported, or in other words, backward compatibility is preserved. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-18 20:46:18 +07:00
- reg: base physical address of the engine and length of memory mapped
region. Can also contain an entry for the SRAM attached to the CESA,
but this representation is deprecated and marvell,crypto-srams should
be used instead
- reg-names: "regs". Can contain an "sram" entry, but this representation
is deprecated and marvell,crypto-srams should be used instead
- interrupts: interrupt number
crypto: mv_cesa - document the clocks property On Dove platforms, the crypto engine requires a clock. Document this clocks property in the mv_cesa bindings doc. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-18 20:46:17 +07:00
- clocks: reference to the crypto engines clocks. This property is only
required for Dove platforms
crypto: mv_cesa - use gen_pool to reserve the SRAM memory region The mv_cesa driver currently expects the SRAM memory region to be passed as a platform device resource. This approach implies two drawbacks: - the DT representation is wrong - the only one that can access the SRAM is the crypto engine The last point is particularly annoying in some cases: for example on armada 370, a small region of the crypto SRAM is used to implement the cpuidle, which means you would not be able to enable both cpuidle and the CESA driver. To address that problem, we explicitly define the SRAM device in the DT and then reference the sram node from the crypto engine node. Also note that the old way of retrieving the SRAM memory region is still supported, or in other words, backward compatibility is preserved. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-18 20:46:18 +07:00
- marvell,crypto-srams: phandle to crypto SRAM definitions
Optional properties:
- marvell,crypto-sram-size: SRAM size reserved for crypto operations, if not
specified the whole SRAM is used (2KB)
Crypto: CESA: Add support for DT based instantiation. Based on work by Michael Walle and Jason Cooper. Added support for getting the interrupt number and address of SRAM from DT. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net> Conflicts: arch/arm/mach-kirkwood/board-dt.c
2012-09-04 01:29:34 +07:00
Examples:
crypto@30000 {
compatible = "marvell,orion-crypto";
crypto: mv_cesa - use gen_pool to reserve the SRAM memory region The mv_cesa driver currently expects the SRAM memory region to be passed as a platform device resource. This approach implies two drawbacks: - the DT representation is wrong - the only one that can access the SRAM is the crypto engine The last point is particularly annoying in some cases: for example on armada 370, a small region of the crypto SRAM is used to implement the cpuidle, which means you would not be able to enable both cpuidle and the CESA driver. To address that problem, we explicitly define the SRAM device in the DT and then reference the sram node from the crypto engine node. Also note that the old way of retrieving the SRAM memory region is still supported, or in other words, backward compatibility is preserved. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-18 20:46:18 +07:00
reg = <0x30000 0x10000>;
reg-names = "regs";
Crypto: CESA: Add support for DT based instantiation. Based on work by Michael Walle and Jason Cooper. Added support for getting the interrupt number and address of SRAM from DT. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net> Conflicts: arch/arm/mach-kirkwood/board-dt.c
2012-09-04 01:29:34 +07:00
interrupts = <22>;
crypto: mv_cesa - use gen_pool to reserve the SRAM memory region The mv_cesa driver currently expects the SRAM memory region to be passed as a platform device resource. This approach implies two drawbacks: - the DT representation is wrong - the only one that can access the SRAM is the crypto engine The last point is particularly annoying in some cases: for example on armada 370, a small region of the crypto SRAM is used to implement the cpuidle, which means you would not be able to enable both cpuidle and the CESA driver. To address that problem, we explicitly define the SRAM device in the DT and then reference the sram node from the crypto engine node. Also note that the old way of retrieving the SRAM memory region is still supported, or in other words, backward compatibility is preserved. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-18 20:46:18 +07:00
marvell,crypto-srams = <&crypto_sram>;
marvell,crypto-sram-size = <0x600>;
Crypto: CESA: Add support for DT based instantiation. Based on work by Michael Walle and Jason Cooper. Added support for getting the interrupt number and address of SRAM from DT. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net> Conflicts: arch/arm/mach-kirkwood/board-dt.c
2012-09-04 01:29:34 +07:00
status = "okay";
};
Reference in New Issue Copy Permalink