kernel.git/drivers/crypto/caam/intern.h, branch linux-4.9.y

Revert "crypto: caam - get rid of tasklet"

2017-12-09T21:01:46Z

commit 2b163b5bce04546da72617bfb6c8bf07a45c4b17 upstream. This reverts commit 66d2e2028091a074aa1290d2eeda5ddb1a6c329c. Quoting from Russell's findings: https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg21136.html [quote] Okay, I've re-tested, using a different way of measuring, because using openssl speed is impractical for off-loaded engines. I've decided to use this way to measure the performance: dd if=/dev/zero bs=1048576 count=128 | /usr/bin/time openssl dgst -md5 For the threaded IRQs case gives: 0.05user 2.74system 0:05.30elapsed 52%CPU (0avgtext+0avgdata 2400maxresident)k 0.06user 2.52system 0:05.18elapsed 49%CPU (0avgtext+0avgdata 2404maxresident)k 0.12user 2.60system 0:05.61elapsed 48%CPU (0avgtext+0avgdata 2460maxresident)k => 5.36s => 25.0MB/s and the tasklet case: 0.08user 2.53system 0:04.83elapsed 54%CPU (0avgtext+0avgdata 2468maxresident)k 0.09user 2.47system 0:05.16elapsed 49%CPU (0avgtext+0avgdata 2368maxresident)k 0.10user 2.51system 0:04.87elapsed 53%CPU (0avgtext+0avgdata 2460maxresident)k => 4.95 => 27.1MB/s which corresponds to an 8% slowdown for the threaded IRQ case. So, tasklets are indeed faster than threaded IRQs. [...] I think I've proven from the above that this patch needs to be reverted due to the performance regression, and that there _is_ most definitely a deterimental effect of switching from tasklets to threaded IRQs. [/quote] Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: caam - get rid of tasklet

2016-08-09T10:47:28Z

Threaded interrupts can perform the function of the tasklet, and much more safely too - without races when trying to take the tasklet and interrupt down on device removal. With the old code, there is a window where we call tasklet_kill(). If the interrupt handler happens to be running on a different CPU, and subsequently calls tasklet_schedule(), the tasklet will be re-scheduled for execution. Switching to a hardirq/threadirq combination implementation avoids this, and it also means generic code deals with the teardown sequencing of the threaded and non-threaded parts. Signed-off-by: Russell King Signed-off-by: Herbert Xu

crypto: caam - Enable and disable clocks on Freescale i.MX platforms

2015-08-10T15:18:56Z

ARM-based systems may disable clocking to the CAAM device on the Freescale i.MX platform for power management purposes. This patch enables the required clocks when the CAAM module is initialized and disables the required clocks when the CAAM module is shut down. Signed-off-by: Victoria Milhoan Tested-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam - Dynamic allocation of addresses for various memory blocks in CAAM.

2014-09-15T11:44:11Z

CAAM's memory is broken into following address blocks: Block Included Registers 0 General Registers 1-4 Job ring registers 6 RTIC registers 7 QI registers 8 DECO and CCB Size of the above stated blocks varies in various platforms. The block size can be 4K or 64K. The block size can be dynamically determined by reading CTPR register in CAAM. This patch initializes the block addresses dynamically based on the value read from this register. Signed-off-by: Ruchika Gupta Signed-off-by: Nitesh Narayan Lal Signed-off-by: Herbert Xu

crypto: caam - Configuration for platforms with virtualization enabled in CAAM

2014-06-25T13:38:39Z

For platforms with virtualization enabled 1. The job ring registers can be written to only is the job ring has been started i.e STARTR bit in JRSTART register is 1 2. For DECO's under direct software control, with virtualization enabled PL, BMT, ICID and SDID values need to be provided. These are provided by selecting a Job ring in start mode whose parameters would be used for the DECO access programming. Signed-off-by: Ruchika Gupta Signed-off-by: Herbert Xu

crypto: caam - Modify the interface layers to use JR API's

2013-10-30T04:02:58Z

- Earlier interface layers - caamalg, caamhash, caamrng were directly using the Controller driver private structure to access the Job ring. - Changed the above to use alloc/free API's provided by Job Ring Drive Signed-off-by: Ruchika Gupta Reviewed-by: Garg Vakul-B16394 Signed-off-by: Herbert Xu

crypto: caam - Add API's to allocate/free Job Rings

2013-10-30T04:02:57Z

With each of the Job Ring available as a platform device, the Job Ring driver needs to take care of allocation/deallocation of the Job Rings to the above interface layers. Added APIs in Job Ring Driver to allocate/free Job rings Signed-off-by: Ruchika Gupta Reviewed-by: Garg Vakul-B16394 Signed-off-by: Herbert Xu

crypto: caam - Add Platform driver for Job Ring

2013-10-30T04:02:57Z

The SEC Job Rings are now available as individual devices. This would enable sharing of job rings between kernel and user space. Job Rings can now be dynamically bound/unbound from kernel. Changes are made in the following layers of CAAM Driver 1. Controller driver - Does basic initialization of CAAM Block. - Creates platform devices for Job Rings. (Earlier the initialization of Job ring was done by the controller driver) 2. JobRing Platform driver - Manages the platform Job Ring devices created by the controller driver Signed-off-by: Ruchika Gupta Reviewed-by: Garg Vakul-B16394 Signed-off-by: Herbert Xu

crypto: caam - enable instantiation of all RNG4 state handles

2013-09-13T11:43:56Z

RNG4 block contains multiple (i.e. 2) state handles that can be initialized. This patch adds the necessary code for detecting which of the two state handles has been instantiated by another piece of software e.g. u-boot and instantiate the other one (or both if none was instantiated). Only the state handle(s) instantiated by this driver will be deinstantiated when removing the module. Signed-off-by: Alex Porosanu Signed-off-by: Herbert Xu

crypto: caam - uninstantiate RNG state handle 0 if instantiated by caam driver

2013-09-13T11:43:55Z

If the caam driver module instantiates the RNG state handle 0, then upon the removal of the module, the RNG state handle is left initialized. This patch takes care of reverting the state of the handle back to its previous uninstantatied state. Signed-off-by: Alex Porosanu Signed-off-by: Herbert Xu