This patchset cleans up caam job ring driver.
The patch series needs to be applied after merging below mentioned
patch.
https://www.mail-archive.com/[email protected]/msg37068.html
Vakul Garg (3):
crypto: caam/jr - Remove spinlock for output job ring
crypto: caam/jr - Remove redundant vars from job ring private data
crypto: caam/jr - Remove extra memory barrier during job ring enqueue
drivers/crypto/caam/intern.h | 3 ---
drivers/crypto/caam/jr.c | 17 +++++------------
2 files changed, 5 insertions(+), 15 deletions(-)
--
2.13.6
For each job ring pair, the output ring is processed exactly by one cpu
at a time under a tasklet context (one per ring). Therefore, there is no
need to protect a job ring's access & its private data structure using a
lock. Hence the lock can be removed.
Signed-off-by: Vakul Garg <[email protected]>
---
drivers/crypto/caam/intern.h | 1 -
drivers/crypto/caam/jr.c | 5 -----
2 files changed, 6 deletions(-)
diff --git a/drivers/crypto/caam/intern.h b/drivers/crypto/caam/intern.h
index 30d5b6c5892f..48d62e020599 100644
--- a/drivers/crypto/caam/intern.h
+++ b/drivers/crypto/caam/intern.h
@@ -56,7 +56,6 @@ struct caam_drv_private_jr {
u32 inpring_avail; /* Number of free entries in input ring */
int head; /* entinfo (s/w ring) head index */
dma_addr_t *inpring; /* Base of input ring, alloc DMA-safe */
- spinlock_t outlock ____cacheline_aligned; /* Output ring index lock */
int out_ring_read_index; /* Output index "tail" */
int tail; /* entinfo (s/w ring) tail index */
struct jr_outentry *outring; /* Base of output ring, DMA-safe */
diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
index b9caa95755d1..89de7297d099 100644
--- a/drivers/crypto/caam/jr.c
+++ b/drivers/crypto/caam/jr.c
@@ -177,8 +177,6 @@ static void caam_jr_dequeue(unsigned long devarg)
head = READ_ONCE(jrp->head);
- spin_lock(&jrp->outlock);
-
sw_idx = tail = jrp->tail;
hw_idx = jrp->out_ring_read_index;
@@ -234,8 +232,6 @@ static void caam_jr_dequeue(unsigned long devarg)
jrp->tail = tail;
}
- spin_unlock(&jrp->outlock);
-
/* Finally, execute user's callback */
usercall(dev, userdesc, userstatus, userarg);
outring_used--;
@@ -452,7 +448,6 @@ static int caam_jr_init(struct device *dev)
jrp->inpring_avail = JOBR_DEPTH;
spin_lock_init(&jrp->inplock);
- spin_lock_init(&jrp->outlock);
/* Select interrupt coalescing parameters */
clrsetbits_32(&jrp->rregs->rconfig_lo, 0, JOBR_INTC |
--
2.13.6
For each job ring, the variable 'ringsize' is initialised but never
used. Similarly variables 'inp_ring_read_index' and 'head' always track
the same value and instead of 'inp_ring_read_index', caam_jr_enqueue()
can use 'head' itself. Both these variables have been removed.
Signed-off-by: Vakul Garg <[email protected]>
---
drivers/crypto/caam/intern.h | 2 --
drivers/crypto/caam/jr.c | 6 +-----
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/crypto/caam/intern.h b/drivers/crypto/caam/intern.h
index 48d62e020599..3392615dc91b 100644
--- a/drivers/crypto/caam/intern.h
+++ b/drivers/crypto/caam/intern.h
@@ -49,10 +49,8 @@ struct caam_drv_private_jr {
atomic_t tfm_count ____cacheline_aligned;
/* Job ring info */
- int ringsize; /* Size of rings (assume input = output) */
struct caam_jrentry_info *entinfo; /* Alloc'ed 1 per ring entry */
spinlock_t inplock ____cacheline_aligned; /* Input ring index lock */
- int inp_ring_write_index; /* Input index "tail" */
u32 inpring_avail; /* Number of free entries in input ring */
int head; /* entinfo (s/w ring) head index */
dma_addr_t *inpring; /* Base of input ring, alloc DMA-safe */
diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
index 89de7297d099..02f02fa996da 100644
--- a/drivers/crypto/caam/jr.c
+++ b/drivers/crypto/caam/jr.c
@@ -358,7 +358,7 @@ int caam_jr_enqueue(struct device *dev, u32 *desc,
head_entry->cbkarg = areq;
head_entry->desc_addr_dma = desc_dma;
- jrp->inpring[jrp->inp_ring_write_index] = cpu_to_caam_dma(desc_dma);
+ jrp->inpring[head] = cpu_to_caam_dma(desc_dma);
/*
* Guarantee that the descriptor's DMA address has been written to
@@ -367,8 +367,6 @@ int caam_jr_enqueue(struct device *dev, u32 *desc,
*/
smp_wmb();
- jrp->inp_ring_write_index = (jrp->inp_ring_write_index + 1) &
- (JOBR_DEPTH - 1);
jrp->head = (head + 1) & (JOBR_DEPTH - 1);
/*
@@ -434,7 +432,6 @@ static int caam_jr_init(struct device *dev)
jrp->entinfo[i].desc_addr_dma = !0;
/* Setup rings */
- jrp->inp_ring_write_index = 0;
jrp->out_ring_read_index = 0;
jrp->head = 0;
jrp->tail = 0;
@@ -444,7 +441,6 @@ static int caam_jr_init(struct device *dev)
wr_reg32(&jrp->rregs->inpring_size, JOBR_DEPTH);
wr_reg32(&jrp->rregs->outring_size, JOBR_DEPTH);
- jrp->ringsize = JOBR_DEPTH;
jrp->inpring_avail = JOBR_DEPTH;
spin_lock_init(&jrp->inplock);
--
2.13.6
In caam_jr_enqueue(), a write barrier is needed to order stores to job
ring slot before declaring addition of new job into input job ring.
The register write is done using wr_reg32() which internally uses
iowrite32() for write operation. The api iowrite32() issues a write
barrier before issuing write operation. Therefore, the wmb() preceding
wr_reg32() can be safely removed.
Signed-off-by: Vakul Garg <[email protected]>
---
drivers/crypto/caam/jr.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
index 02f02fa996da..3bd28386eb07 100644
--- a/drivers/crypto/caam/jr.c
+++ b/drivers/crypto/caam/jr.c
@@ -371,9 +371,11 @@ int caam_jr_enqueue(struct device *dev, u32 *desc,
/*
* Ensure that all job information has been written before
- * notifying CAAM that a new job was added to the input ring.
+ * notifying CAAM that a new job was added to the input ring
+ * using a memory barrier. The wr_reg32() uses api iowrite32()
+ * to do the register write. iowrite32() issues a memory barrier
+ * before the write operation.
*/
- wmb();
wr_reg32(&jrp->rregs->inpring_jobadd, 1);
--
2.13.6
Hi Vakul,
On Fri, 15 Mar 2019 at 04:05, Vakul Garg <[email protected]> wrote:
> For each job ring pair, the output ring is processed exactly by one cpu
> at a time under a tasklet context (one per ring). Therefore, there is no
> need to protect a job ring's access & its private data structure using a
> lock. Hence the lock can be removed.
>
> Signed-off-by: Vakul Garg <[email protected]>
This comment in caam_jr_dequeue doesn't really make sense anymore:
/* Stash callback params for use outside of lock */
Since the lock has been removed you could probably get away with just
invoking the user callback immediately which would simplify the code a
little.
Thanks,
Chris