crypto: fixes for omap family of devices
Subsystems (9)
v2 cover crypto: fixes for omap family of devices
Hi,
Changes compared to v1 of the series:
- dropped first patch from the series (crypto: omap-aes: Fix registration of algorithms) as it was queued by Herbert already
- modified the second (now first) patch of the series to use runtime auto- suspend instead of getting static sync over a cra lifetime
- re-ordered the DTS / hwmod changes in the series, the merge order of these must be maintained to avoid issues
Patches #01 .. #14 should be merged via crypto tree, the rest should be handled by Tony.
Merging the omap / dts parts can be done safely separately, assuming you just use omap2plus_defconfig (enabling crypto features will cause some issues without the driver level fixes.)
- Tero
PATCH v2 1/27 crypto: omap-sham: use runtime_pm autosuspend for clock handling
Calling runtime PM API for every block causes serious performance hit to crypto operations that are done on a long buffer. As crypto is performed on a page boundary, encrypting large buffers can cause a series of crypto operations divided by page. The runtime PM API is also called those many times.
Convert the driver to use runtime_pm autosuspend instead, with a default timeout value of 1 second. This results in upto ~50% speedup.
--- drivers/crypto/omap-sham.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/crypto/omap-sham.c +7 -1
@@ -100,6 +100,8 @@#define DEFAULT_TIMEOUT_INTERVAL HZ +#define DEFAULT_AUTOSUSPEND_DELAY 1000 +/* mostly device flags */ #define FLAGS_BUSY 0#define FLAGS_FINAL 1
@@ -999,7 +1001,8 @@ static void omap_sham_finish_req(struct ahash_request *req, int err) dd->flags &= ~(BIT (FLAGS_BUSY ) |BIT (FLAGS_FINAL ) |BIT (FLAGS_CPU ) |BIT (FLAGS_DMA_READY ) |BIT (FLAGS_OUTPUT_READY )); -pm_runtime_put (dd->dev); +pm_runtime_mark_last_busy (dd->dev); +pm_runtime_put_autosuspend (dd->dev);if (req->base.complete) req->base.complete (&req->base, err);
@@ -1946,6 +1949,9 @@ static int omap_sham_probe(struct platform_device *pdev) dd->flags |= dd->pdata->flags; +pm_runtime_use_autosuspend (dev); +pm_runtime_set_autosuspend_delay (dev,DEFAULT_AUTOSUSPEND_DELAY ); +pm_runtime_enable (dev);pm_runtime_irq_safe (dev);
Signature · 1 line
1.9.1
Herbert Xu
maintainerPATCH v2 1/27 crypto: omap-sham: use runtime_pm autosuspend for clock handling
Quoted 10 lines · Tero Kristo
Calling runtime PM API for every block causes serious performance hit to crypto operations that are done on a long buffer. As crypto is performed on a page boundary, encrypting large buffers can cause a series of crypto operations divided by page. The runtime PM API is also called those many times.
Convert the driver to use
runtime_pmautosuspend instead, with a default timeout value of 1 second. This results in upto ~50% speedup.Signed-off-by Tero Kristo <[email protected]>
Patches 1-4 applied. Thanks.
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
PATCH v2 2/27 crypto: omap-sham: change queue size from 1 to 10
In reply to Tero KristoChange crypto queue size from 1 to 10 for omap SHA driver. This should allow clients to enqueue requests more effectively to avoid serializing whole crypto sequences, giving extra performance.
--- drivers/crypto/omap-sham.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/crypto/omap-sham.c +1 -1
@@ -175,7 +175,7 @@ struct omap_sham_ctx {struct omap_sham_hmac_ctx base[0 ]; }; -#define OMAP_SHAM_QUEUE_LENGTH 1 +#define OMAP_SHAM_QUEUE_LENGTH 10struct omap_sham_algs_info {struct ahash_alg *algs_list;
Signature · 1 line
1.9.1
PATCH v2 3/27 crypto: omap: do not call dmaengine_terminate_all
In reply to Tero KristoFrom: Lokesh Vutla <[email protected]>
The extra call to dmaengine_terminate_all is not needed, as the DMA is not running at this point. This improves performance slightly.
--- drivers/crypto/omap-aes.c | 2 -- drivers/crypto/omap-sham.c | 1 - 2 files changed, 3 deletions(-)
drivers/crypto/omap-aes.c +0 -2
@@ -528,8 +528,6 @@ static int omap_aes_crypt_dma_stop(struct omap_aes_dev *dd)omap_aes_dma_stop (dd); -dmaengine_terminate_all (dd->dma_lch_in); -dmaengine_terminate_all (dd->dma_lch_out);return 0 ; }
drivers/crypto/omap-sham.c +0 -1
@@ -815,7 +815,6 @@ static int omap_sham_update_dma_stop(struct omap_sham_dev *dd) {struct omap_sham_reqctx *ctx =ahash_request_ctx (dd->req); -dmaengine_terminate_all (dd->dma_lch);if (ctx->flags &BIT (FLAGS_SG )) {dma_unmap_sg (dd->dev, ctx->sg,1 ,DMA_TO_DEVICE );
Signature · 1 line
1.9.1
PATCH v2 4/27 crypto: omap-sham: set sw fallback to 240 bytes
In reply to Tero KristoFrom: Bin Liu <[email protected]>
Adds software fallback support for small crypto requests. In these cases, it is undesirable to use DMA, as setting it up itself is rather heavy operation. Gives about 40% extra performance in ipsec usecase.
[t-kristo at ti.com: dropped the extra traces, updated some comments
on the code]
--- drivers/crypto/omap-sham.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
drivers/crypto/omap-sham.c +8 -4
@@ -1095,7 +1095,7 @@ static int omap_sham_update(struct ahash_request *req) ctx->offset =0 ;if (ctx->flags &BIT (FLAGS_FINUP )) { -if ((ctx->digcnt + ctx->bufcnt + ctx->total) <9 ) { +if ((ctx->digcnt + ctx->bufcnt + ctx->total) <240 ) {/* * OMAP HW accel works only with buffers >= 9 * will switch to bypass in final()
@@ -1151,9 +1151,13 @@ static int omap_sham_final(struct ahash_request *req)if (ctx->flags &BIT (FLAGS_ERROR ))return 0 ;/* uncompleted hash is not needed */ -/* OMAP HW accel works only with buffers >= 9 */ -/* HMAC is always >= 9 because ipad == block size */ -if ((ctx->digcnt + ctx->bufcnt) <9 ) +/* +* OMAP HW accel works only with buffers >= 9. +* HMAC is always >= 9 because ipad == block size. +* If buffersize is less than 240, we use fallback SW encoding, +* as using DMA + HW in this case doesn't provide any benefit. +*/ +if ((ctx->digcnt + ctx->bufcnt) <240 )return omap_sham_final_shash (req);else if (ctx->bufcnt)return omap_sham_enqueue (req,OP_FINAL );
Signature · 1 line
1.9.1
PATCH v2 5/27 crypto: omap-sham: avoid executing tasklet where not needed
In reply to Tero KristoSome of the call paths of OMAP SHA driver can avoid executing the next step of the crypto queue under tasklet; instead, execute the next step directly via function call. This avoids a costly round-trip via the scheduler giving a slight performance boost.
--- drivers/crypto/omap-sham.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/crypto/omap-sham.c +3 -1
@@ -242,6 +242,8 @@ static struct omap_sham_drv sham = { .lock = __SPIN_LOCK_UNLOCKED(sham.lock), }; +static void omap_sham_done_task (unsigned long data); +static inline u32 omap_sham_read (struct omap_sham_dev *dd,u32 offset) {return __raw_readl (dd->io_base + offset);
@@ -1007,7 +1009,7 @@ static void omap_sham_finish_req(struct ahash_request *req, int err) req->base.complete (&req->base, err);/* handle new request */ -tasklet_schedule (&dd->done_task); +omap_sham_done_task ((unsigned long )dd); } static int omap_sham_handle_queue(struct omap_sham_dev *dd,
Signature · 1 line
1.9.1
Herbert Xu
maintainerPATCH v2 5/27 crypto: omap-sham: avoid executing tasklet where not needed
Quoted 24 lines · Tero Kristo
Some of the call paths of OMAP SHA driver can avoid executing the next step of the crypto queue under tasklet; instead, execute the next step directly via function call. This avoids a costly round-trip via the scheduler giving a slight performance boost.
Signed-off-by Tero Kristo <[email protected]>--- drivers/crypto/omap-sham.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)drivers/crypto/omap-sham.c +2
-0@@ -242,6 +242,8 @@ static struct omap_sham_drv sham = { .lock = __SPIN_LOCK_UNLOCKED(sham.lock), }; +static void omap_sham_done_task (unsigned long data); +static inline u32 omap_sham_read (struct omap_sham_dev *dd,u32 offset) {return __raw_readl (dd->io_base + offset);
drivers/crypto/omap-sham.c static void omap_sham_finish_req(struct ahash_request *req, int err) · line 1013
Quoted 6 lines
drivers/crypto/omap-sham.c +1
-1@@ -1007,7 +1009,7 @@ static void omap_sham_finish_req(struct ahash_request *req, int err) req->base.complete (&req->base, err);/* handle new request */ -tasklet_schedule (&dd->done_task); +omap_sham_done_task ((unsigned long )dd); }
Hmm, what guarnatees that you won't run out of stack doing this?
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
PATCH v2 5/27 crypto: omap-sham: avoid executing tasklet where not needed
Quoted 27 lines · Herbert Xu
Quoted 26 lines · Tero Kristo
Some of the call paths of OMAP SHA driver can avoid executing the next step of the crypto queue under tasklet; instead, execute the next step directly via function call. This avoids a costly round-trip via the scheduler giving a slight performance boost.
Signed-off-by Tero Kristo <[email protected]>--- drivers/crypto/omap-sham.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)drivers/crypto/omap-sham.c +2
-0@@ -242,6 +242,8 @@ static struct omap_sham_drv sham = { .lock = __SPIN_LOCK_UNLOCKED(sham.lock), }; +static void omap_sham_done_task (unsigned long data); +static inline u32 omap_sham_read (struct omap_sham_dev *dd,u32 offset) {return __raw_readl (dd->io_base + offset);@@ -1007,7 +1009,7 @@ static void omap_sham_finish_req(struct ahash_request *req, int err) req->base.complete (&req->base, err);
Quoted 6 lines
drivers/crypto/omap-sham.c static void omap_sham_finish_req(struct ahash_request *req, int err) · line 1013
Quoted 4 lines
drivers/crypto/omap-sham.c +1
-1/* handle new request */ -tasklet_schedule (&dd->done_task); +omap_sham_done_task ((unsigned long )dd); }Hmm, what guarnatees that you won't run out of stack doing this?
Good question, I had a deeper look at the driver and it seems you are right... It may result in a recursion loop within the driver. I will dig this further and break the recursion if it indeed can call itself indefinitely.
My knowledge of the crypto stack (+ these drivers unfortunately) is still pretty limited, I appreciate your reviews a lot.
-Tero
PATCH v2 6/27 crypto: ahash: increase the maximum allowed statesize
In reply to Tero KristoThe statesize is used to determine the maximum size for saved ahash context. In some cases, this can be much larger than what is currently allocated for it, for example omap-sham driver uses a buffer size of PAGE_SIZE. Increase the statesize to accommodate this.
--- crypto/ahash.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
crypto/ahash.c +1 -1
@@ -536,7 +536,7 @@ static int ahash_prepare_alg(struct ahash_alg *alg)struct crypto_alg *base = &alg->halg.base;if (alg->halg.digestsize >PAGE_SIZE /8 || - alg->halg.statesize >PAGE_SIZE /8 || + alg->halg.statesize >PAGE_SIZE *2 || alg->halg.statesize ==0 )return -EINVAL ;
Signature · 1 line
1.9.1
Herbert Xu
maintainerPATCH v2 6/27 crypto: ahash: increase the maximum allowed statesize
Quoted 6 lines · Tero Kristo
The statesize is used to determine the maximum size for saved ahash context. In some cases, this can be much larger than what is currently allocated for it, for example omap-sham driver uses a buffer size of
PAGE_SIZE. Increase the statesize to accommodate this.Signed-off-by Tero Kristo <[email protected]>
Nack. The exported state is supposed to consist of the actual hash state, plus at most one block worth of unhashed data. It's limited so that we can store it on the stack.
So no I'm not taking this patch.
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
PATCH v2 6/27 crypto: ahash: increase the maximum allowed statesize
Quoted 6 lines · Herbert Xu
Quoted 5 lines · Tero Kristo
The statesize is used to determine the maximum size for saved ahash context. In some cases, this can be much larger than what is currently allocated for it, for example omap-sham driver uses a buffer size of
PAGE_SIZE. Increase the statesize to accommodate this.
Quoted 8 lines
Quoted 1 line
Signed-off-by Tero Kristo <[email protected]>Nack. The exported state is supposed to consist of the actual hash state, plus at most one block worth of unhashed data. It's limited so that we can store it on the stack.
So no I'm not taking this patch.
Ok, I think I need to allocate the storage space locally then within the driver. Would it be ok to call kmalloc / free in the export / import implementation of the driver? The size of the unhashed buffer in omap-sham is unfortunately rather large.
-Tero
Herbert Xu
maintainerPATCH v2 6/27 crypto: ahash: increase the maximum allowed statesize
Quoted 5 lines · Tero Kristo
Ok, I think I need to allocate the storage space locally then within the driver. Would it be ok to call kmalloc / free in the export / import implementation of the driver? The size of the unhashed buffer in omap-sham is unfortunately rather large.
The allocation should usually be done from the request_alloc function, i.e., you set the reqsize and the user does the allocation for you.
Cheers,
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
PATCH v2 6/27 crypto: ahash: increase the maximum allowed statesize
Quoted 10 lines · Herbert Xu
Quoted 5 lines · Tero Kristo
Ok, I think I need to allocate the storage space locally then within the driver. Would it be ok to call kmalloc / free in the export / import implementation of the driver? The size of the unhashed buffer in omap-sham is unfortunately rather large.
The allocation should usually be done from the
request_allocfunction, i.e., you set the reqsize and the user does the allocation for you.
I need some clarification on this, afaik request_alloc related functionality only works per-request basis. The export / import functionality however is supposed to work across multiple requests. The test code for example does this:
ret = crypto_ahash_export(req, state);
...
ahash_request_free(req);
req = ahash_request_alloc(tfm, GFP_KERNEL);
...
ret = crypto_ahash_import(req, state);... which means if I attempt to allocate extra space for the export buffer within the first request, it is not available at the import time anymore.
Is there any limitation how many simultaneous exports can be done from a driver? I was wondering if I can allocate a single export buffer for the whole driver.
-Tero
Herbert Xu
maintainerPATCH v2 6/27 crypto: ahash: increase the maximum allowed statesize
Quoted 5 lines · Tero Kristo
I need some clarification on this, afaik
request_allocrelated functionality only works per-request basis. The export / import functionality however is supposed to work across multiple requests. The test code for example does this:
Why are you trying to allocate memory in export/import at all? The preferred approach is to unconditionally allocate the memory in ahash_request_alloc.
Cheers,
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
PATCH v2 6/27 crypto: ahash: increase the maximum allowed statesize
Quoted 10 lines · Herbert Xu
Quoted 5 lines · Tero Kristo
I need some clarification on this, afaik
request_allocrelated functionality only works per-request basis. The export / import functionality however is supposed to work across multiple requests. The test code for example does this:Why are you trying to allocate memory in export/import at all? The preferred approach is to unconditionally allocate the memory in
ahash_request_alloc.
The driver allocates a largish buffer for copying the input data from the sgs into a sequential space. If I don't save the contents of this buffer anywhere, the export/import doesn't work as expected it seems.
Actually I am now wondering why the driver allocates this sequential buffer at all, DMA should be possible to use over the sgs just fine, at least some other crypto drivers are doing this.
-Tero
Herbert Xu
maintainerPATCH v2 6/27 crypto: ahash: increase the maximum allowed statesize
Quoted 9 lines · Tero Kristo
The driver allocates a largish buffer for copying the input data from the sgs into a sequential space. If I don't save the contents of this buffer anywhere, the export/import doesn't work as expected it seems.
Actually I am now wondering why the driver allocates this sequential buffer at all, DMA should be possible to use over the sgs just fine, at least some other crypto drivers are doing this.
Indeed this is totally broken. No hash driver should be holding data without actually hashing it, unless of course if there is less than a block of data.
So either fix the driver to hash the data as they come in, or make it use a software fallback for update.
Cheers,
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
PATCH v2 7/27 crypto: omap-sham: implement context export/import APIs
In reply to Tero KristoContext export/import are now required for ahash algorithms due to required support in algif_hash. Implement these for OMAP SHA driver, saving and restoring the internal state of the driver.
--- drivers/crypto/omap-sham.c | 40 ++++++++++++++++++++++++++++++++++++++-- 1 file changed, 38 insertions(+), 2 deletions(-)
drivers/crypto/omap-sham.c +38 -2
@@ -1325,6 +1325,35 @@ static void omap_sham_cra_exit(struct crypto_tfm *tfm) } } +static int omap_sham_export (struct ahash_request *req,void *out) +{ +struct crypto_ahash *tfm =crypto_ahash_reqtfm (req); +struct omap_sham_reqctx *rctx =ahash_request_ctx (req); +struct omap_sham_ctx *ctx =crypto_ahash_ctx (tfm); +struct omap_sham_hmac_ctx *bctx = ctx->base; + +memcpy (out, rctx,sizeof (*rctx) +BUFLEN ); +memcpy (out +sizeof (*rctx) +BUFLEN , ctx,sizeof (*ctx)); +memcpy (out +sizeof (*rctx) +BUFLEN +sizeof (*ctx), bctx, +sizeof (*bctx)); + +return 0 ; +} + +static int omap_sham_import (struct ahash_request *req,const void *in) +{ +struct crypto_ahash *tfm =crypto_ahash_reqtfm (req); +struct omap_sham_reqctx *rctx =ahash_request_ctx (req); +struct omap_sham_ctx *ctx =crypto_ahash_ctx (tfm); +struct omap_sham_hmac_ctx *bctx = ctx->base; + +memcpy (rctx, in,sizeof (*rctx) +BUFLEN ); +memcpy (ctx, in +sizeof (*rctx) +BUFLEN ,sizeof (*ctx)); +memcpy (bctx, in +sizeof (*rctx) +BUFLEN +sizeof (*ctx),sizeof (*bctx)); + +return 0 ; +} +static struct ahash_alg algs_sha1_md5[] = { { .init = omap_sham_init,
@@ -1979,8 +2008,15 @@ static int omap_sham_probe(struct platform_device *pdev)for (i =0 ; i < dd->pdata->algs_info_size; i++) {for (j =0 ; j < dd->pdata->algs_info[i].size; j++) { - err =crypto_register_ahash ( - &dd->pdata->algs_info[i].algs_list[j]); +struct ahash_alg *alg; + + alg = &dd->pdata->algs_info[i].algs_list[j]; + alg->export = omap_sham_export; + alg->import = omap_sham_import; + alg->halg.statesize =sizeof (struct omap_sham_reqctx ) + +sizeof (struct omap_sham_ctx ) + +sizeof (struct omap_sham_hmac_ctx ) +BUFLEN ; + err =crypto_register_ahash (alg);if (err) goto err_algs;
Signature · 1 line
1.9.1
PATCH v2 8/27 crypto: omap-des: Fix support for unequal lengths
In reply to Tero KristoFrom: Lokesh Vutla <[email protected]>
For cases where total length of an input SGs is not same as length of the input data for encryption, omap-des driver crashes. This happens in the case when IPsec is trying to use omap-des driver.
To avoid this, we copy all the pages from the input SG list into a contiguous buffer and prepare a single element SG list for this buffer with length as the total bytes to crypt, which is similar thing that is done in case of unaligned lengths.
--- drivers/crypto/omap-des.c | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-)
drivers/crypto/omap-des.c +17 -10
@@ -521,29 +521,36 @@ static int omap_des_crypt_dma_stop(struct omap_des_dev *dd)return 0 ; } -static int omap_des_copy_needed (struct scatterlist *sg) +static int omap_des_copy_needed (struct scatterlist *sg,int total) { +int len =0 ; + +if (!IS_ALIGNED (total,DES_BLOCK_SIZE )) +return -1 ; +while (sg) {if (!IS_ALIGNED (sg->offset,4 ))return -1 ;if (!IS_ALIGNED (sg->length,DES_BLOCK_SIZE ))return -1 ; + + len += sg->length; sg =sg_next (sg); } + +if (len != total) +return -1 ; +return 0 ; }static int omap_des_copy_sgs (struct omap_des_dev *dd) {void *buf_in, *buf_out; -int pages; - - pages = dd->total >>PAGE_SHIFT ; - -if (dd->total & (PAGE_SIZE -1 )) - pages++; +int pages, total; -BUG_ON (!pages); + total =ALIGN (dd->total,DES_BLOCK_SIZE ); + pages =get_order (total); buf_in = (void *)__get_free_pages (GFP_ATOMIC , pages); buf_out = (void *)__get_free_pages (GFP_ATOMIC , pages);
@@ -595,8 +602,8 @@ static int omap_des_prepare_req(struct crypto_engine *engine, dd->in_sg = req->src; dd->out_sg = req->dst; -if (omap_des_copy_needed (dd->in_sg) || -omap_des_copy_needed (dd->out_sg)) { +if (omap_des_copy_needed (dd->in_sg, dd->total) || +omap_des_copy_needed (dd->out_sg, dd->total)) {if (omap_des_copy_sgs (dd))pr_err ("Failed to copy SGs for unaligned cases\n" ); dd->sgs_copied =1 ;
Signature · 1 line
1.9.1
PATCH v2 9/27 crypto: omap-aes - Fix enabling clocks
In reply to Tero KristoFrom: Lokesh Vutla <[email protected]>
Enable clocks for all cores before starting session. Driver has to pic the aes core dynamically based on the queue length.
--- drivers/crypto/omap-aes.c | 23 +++++++---------------- 1 file changed, 7 insertions(+), 16 deletions(-)
drivers/crypto/omap-aes.c +7 -16
@@ -760,18 +760,13 @@ static int omap_aes_cra_init(struct crypto_tfm *tfm)struct omap_aes_dev *dd =NULL ;int err; -/* Find AES device, currently picks the first device */ -spin_lock_bh (&list_lock);list_for_each_entry (dd, &dev_list, list) { -break ; - } -spin_unlock_bh (&list_lock); - - err =pm_runtime_get_sync (dd->dev); -if (err <0 ) { -dev_err (dd->dev,"%s: failed to get_sync(%d)\n" , - __func__, err); -return err; + err =pm_runtime_get_sync (dd->dev); +if (err <0 ) { +dev_err (dd->dev,"%s: failed to get_sync(%d)\n" , + __func__, err); +return err; + } } tfm->crt_ablkcipher.reqsize =sizeof (struct omap_aes_reqctx );
@@ -783,14 +778,10 @@ static void omap_aes_cra_exit(struct crypto_tfm *tfm) {struct omap_aes_dev *dd =NULL ; -/* Find AES device, currently picks the first device */ -spin_lock_bh (&list_lock);list_for_each_entry (dd, &dev_list, list) { -break ; +pm_runtime_put_sync (dd->dev); } -spin_unlock_bh (&list_lock); -pm_runtime_put_sync (dd->dev); }/* ********************** ALGS ************************************ */
Signature · 1 line
1.9.1
PATCH v2 10/27 crypto: omap-aes: Add support for multiple cores
In reply to Tero KristoFrom: Lokesh Vutla <[email protected]>
Some SoCs like omap4/omap5/dra7 contain multiple AES crypto accelerator cores. Adapt the driver to support this. The driver picks the last used device from a list of AES devices.
--- drivers/crypto/omap-aes.c | 20 ++++++-------------- 1 file changed, 6 insertions(+), 14 deletions(-)
drivers/crypto/omap-aes.c +6 -14
@@ -319,20 +319,12 @@ static void omap_aes_dma_stop(struct omap_aes_dev *dd)static struct omap_aes_dev *omap_aes_find_dev (struct omap_aes_ctx *ctx) { -struct omap_aes_dev *dd =NULL , *tmp; +struct omap_aes_dev *dd;spin_lock_bh (&list_lock); -if (!ctx->dd) { -list_for_each_entry (tmp, &dev_list, list) { -/* FIXME: take fist available aes core */ - dd = tmp; -break ; - } - ctx->dd = dd; - }else { -/* already found before */ - dd = ctx->dd; - } + dd = list_first_entry(&dev_list, struct omap_aes_dev, list); +list_move_tail (&dd->list, &dev_list); + ctx->dd = dd;spin_unlock_bh (&list_lock);return dd;
@@ -600,7 +592,7 @@ static int omap_aes_prepare_req(struct crypto_engine *engine, {struct omap_aes_ctx *ctx =crypto_ablkcipher_ctx (crypto_ablkcipher_reqtfm (req)); -struct omap_aes_dev *dd =omap_aes_find_dev (ctx); +struct omap_aes_dev *dd = ctx->dd;struct omap_aes_reqctx *rctx;int len;
@@ -644,7 +636,7 @@ static int omap_aes_crypt_req(struct crypto_engine *engine, {struct omap_aes_ctx *ctx =crypto_ablkcipher_ctx (crypto_ablkcipher_reqtfm (req)); -struct omap_aes_dev *dd =omap_aes_find_dev (ctx); +struct omap_aes_dev *dd = ctx->dd;if (!dd)return -ENODEV ;
Signature · 1 line
1.9.1
PATCH v2 11/27 crypto: omap-aes: Add fallback support
In reply to Tero KristoFrom: Lokesh Vutla <[email protected]>
As setting up the DMA operations is quite costly, add software fallback support for requests smaller than 200 bytes. This change gives some 10% extra performance in ipsec use case.
--- drivers/crypto/Kconfig | 3 +++ drivers/crypto/omap-aes.c | 45 ++++++++++++++++++++++++++++++++++++++++++--- 2 files changed, 45 insertions(+), 3 deletions(-)
drivers/crypto/Kconfig +3 -0
@@ -305,6 +305,9 @@ config CRYPTO_DEV_OMAP_AES select CRYPTO_AES select CRYPTO_BLKCIPHER select CRYPTO_ENGINE + select CRYPTO_CBC + select CRYPTO_ECB + select CRYPTO_CTR help OMAP processors have AES module accelerator. Select this if you want to use the OMAP module for AES algorithms.
drivers/crypto/omap-aes.c +42 -3
119 lines not on this page · raw message
Signature · 1 line
1.9.1
PATCH v2 12/27 crypto: engine: avoid unnecessary context switches
In reply to Tero KristoCrypto engine will now hi-jack the currently running thread for executing crypto functionality. Only if we are not running a thread (in interrupt context) the kthread will be scheduled.
This will improve performance of crypto operations using crypto engine.
--- crypto/crypto_engine.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-)
crypto/crypto_engine.c +13 -4
@@ -136,6 +136,14 @@ static void crypto_pump_work(struct kthread_work *work)crypto_pump_requests (engine, true); } +static void queue_pump_work (struct crypto_engine *engine) +{ +if (in_interrupt ()) +queue_kthread_work (&engine->kworker, &engine->pump_requests); +else +crypto_pump_requests (engine, true); +} +/** * crypto_transfer_request - transfer the new request into the engine queue * @engine: the hardware engine
@@ -156,10 +164,11 @@ int crypto_transfer_request(struct crypto_engine *engine, ret =ablkcipher_enqueue_request (&engine->queue, req); +spin_unlock_irqrestore (&engine->queue_lock, flags); +if (!engine->busy && need_pump) -queue_kthread_work (&engine->kworker, &engine->pump_requests); +queue_pump_work (engine); -spin_unlock_irqrestore (&engine->queue_lock, flags);return ret; }EXPORT_SYMBOL_GPL (crypto_transfer_request);
@@ -210,7 +219,7 @@ void crypto_finalize_request(struct crypto_engine *engine, req->base.complete (&req->base, err); -queue_kthread_work (&engine->kworker, &engine->pump_requests); +queue_pump_work (engine); }EXPORT_SYMBOL_GPL (crypto_finalize_request);
@@ -234,7 +243,7 @@ int crypto_engine_start(struct crypto_engine *engine) engine->running = true;spin_unlock_irqrestore (&engine->queue_lock, flags); -queue_kthread_work (&engine->kworker, &engine->pump_requests); +queue_pump_work (engine);return 0 ; }
Signature · 1 line
1.9.1
PATCH v2 13/27 crypto: omap-aes: fix crypto engine initialization order
In reply to Tero KristoThe crypto engine must be initialized before registering algorithms, otherwise the test manager will crash as it attempts to execute tests for the algos while they are being registered.
--- drivers/crypto/omap-aes.c | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-)
drivers/crypto/omap-aes.c +15 -13
@@ -1204,6 +1204,17 @@ static int omap_aes_probe(struct platform_device *pdev)list_add_tail (&dd->list, &dev_list);spin_unlock (&list_lock); +/* Initialize crypto engine */ + dd->engine =crypto_engine_alloc_init (dev,1 ); +if (!dd->engine) + goto err_engine; + + dd->engine->prepare_request = omap_aes_prepare_req; + dd->engine->crypt_one_request = omap_aes_crypt_req; + err =crypto_engine_start (dd->engine); +if (err) + goto err_engine; +for (i =0 ; i < dd->pdata->algs_info_size; i++) {if (!dd->pdata->algs_info[i].registered) {for (j =0 ; j < dd->pdata->algs_info[i].size; j++) {
@@ -1221,26 +1232,17 @@ static int omap_aes_probe(struct platform_device *pdev) } } -/* Initialize crypto engine */ - dd->engine =crypto_engine_alloc_init (dev,1 ); -if (!dd->engine) - goto err_algs; - - dd->engine->prepare_request = omap_aes_prepare_req; - dd->engine->crypt_one_request = omap_aes_crypt_req; - err =crypto_engine_start (dd->engine); -if (err) - goto err_engine; -return 0 ; -err_engine: -crypto_engine_exit (dd->engine); err_algs:for (i = dd->pdata->algs_info_size -1 ; i >=0 ; i--)for (j = dd->pdata->algs_info[i].registered -1 ; j >=0 ; j--)crypto_unregister_alg ( &dd->pdata->algs_info[i].algs_list[j]); +err_engine: +if (dd->engine) +crypto_engine_exit (dd->engine); +omap_aes_dma_cleanup (dd); err_irq:tasklet_kill (&dd->done_task);
Signature · 1 line
1.9.1
PATCH v2 14/27 crypto: omap-des: fix crypto engine initialization order
In reply to Tero KristoThe crypto engine must be initialized before registering algorithms, otherwise the test manager will crash as it attempts to execute tests for the algos while they are being registered.
--- drivers/crypto/omap-des.c | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-)
drivers/crypto/omap-des.c +15 -13
@@ -1079,6 +1079,17 @@ static int omap_des_probe(struct platform_device *pdev)list_add_tail (&dd->list, &dev_list);spin_unlock (&list_lock); +/* Initialize des crypto engine */ + dd->engine =crypto_engine_alloc_init (dev,1 ); +if (!dd->engine) + goto err_engine; + + dd->engine->prepare_request = omap_des_prepare_req; + dd->engine->crypt_one_request = omap_des_crypt_req; + err =crypto_engine_start (dd->engine); +if (err) + goto err_engine; +for (i =0 ; i < dd->pdata->algs_info_size; i++) {for (j =0 ; j < dd->pdata->algs_info[i].size; j++) { algp = &dd->pdata->algs_info[i].algs_list[j];
@@ -1094,27 +1105,18 @@ static int omap_des_probe(struct platform_device *pdev) } } -/* Initialize des crypto engine */ - dd->engine =crypto_engine_alloc_init (dev,1 ); -if (!dd->engine) - goto err_algs; - - dd->engine->prepare_request = omap_des_prepare_req; - dd->engine->crypt_one_request = omap_des_crypt_req; - err =crypto_engine_start (dd->engine); -if (err) - goto err_engine; -return 0 ; -err_engine: -crypto_engine_exit (dd->engine); err_algs:for (i = dd->pdata->algs_info_size -1 ; i >=0 ; i--)for (j = dd->pdata->algs_info[i].registered -1 ; j >=0 ; j--)crypto_unregister_alg ( &dd->pdata->algs_info[i].algs_list[j]); +err_engine: +if (dd->engine) +crypto_engine_exit (dd->engine); +omap_des_dma_cleanup (dd); err_irq:tasklet_kill (&dd->done_task);
Signature · 1 line
1.9.1
PATCH v2 15/27 ARM: dts: DRA7: Add DT node for DES IP
In reply to Tero KristoFrom: Joel Fernandes <[email protected]>
DRA7xx SoCs have a DES3DES IP. Add DT data for the same.
--- arch/arm/boot/dts/dra7.dtsi | 11 +++++++++++ 1 file changed, 11 insertions(+)
arch/arm/boot/dts/dra7.dtsi +11 -0
@@ -1743,6 +1743,17 @@ clock-names = "fck", "sys_clk"; }; }; + + des: des at 480a5000 { + compatible = "ti,omap4-des"; + ti,hwmods = "des"; + reg = <0x480a5000 0xa0>; + interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>; + dmas = <&sdma_xbar 117>, <&sdma_xbar 116>; + dma-names = "tx", "rx"; + clocks = <&l3_iclk_div>; + clock-names = "fck"; + }; }; thermal_zones: thermal-zones {
Signature · 1 line
1.9.1
PATCH v2 16/27 ARM: dts: DRA7: Add DT nodes for AES IP
In reply to Tero KristoFrom: Joel Fernandes <[email protected]>
DRA7 SoC has the same AES IP as OMAP4. Add DT entries for both AES cores.
[t-kristo at ti.com: squashed in the change to use EDMA, squashed in
support for two AES cores]
--- arch/arm/boot/dts/dra7.dtsi | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)
arch/arm/boot/dts/dra7.dtsi +22 -0
@@ -1744,6 +1744,28 @@ }; }; + aes1: aes at 4b500000 { + compatible = "ti,omap4-aes"; + ti,hwmods = "aes1"; + reg = <0x4b500000 0xa0>; + interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>; + dmas = <&edma_xbar 111 0>, <&edma_xbar 110 0>; + dma-names = "tx", "rx"; + clocks = <&l3_iclk_div>; + clock-names = "fck"; + }; + + aes2: aes at 4b700000 { + compatible = "ti,omap4-aes"; + ti,hwmods = "aes2"; + reg = <0x4b700000 0xa0>; + interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>; + dmas = <&edma_xbar 114 0>, <&edma_xbar 113 0>; + dma-names = "tx", "rx"; + clocks = <&l3_iclk_div>; + clock-names = "fck"; + }; + des: des at 480a5000 { compatible = "ti,omap4-des"; ti,hwmods = "des";
Signature · 1 line
1.9.1
PATCH v2 17/27 ARM: dts: DRA7: Add support for SHA IP
In reply to Tero KristoFrom: Lokesh Vutla <[email protected]>
DRA7 SoC has the same SHA IP as OMAP5. Add DT entry for the same.
--- arch/arm/boot/dts/dra7.dtsi | 11 +++++++++++ 1 file changed, 11 insertions(+)
arch/arm/boot/dts/dra7.dtsi +11 -0
@@ -1776,6 +1776,17 @@ clocks = <&l3_iclk_div>; clock-names = "fck"; }; + + sham: sham at 53100000 { + compatible = "ti,omap5-sham"; + ti,hwmods = "sham"; + reg = <0x4b101000 0x300>; + interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>; + dmas = <&edma_xbar 119 0>; + dma-names = "rx"; + clocks = <&l3_iclk_div>; + clock-names = "fck"; + }; }; thermal_zones: thermal-zones {
Signature · 1 line
1.9.1
PATCH v2 18/27 ARM: dts: DRA7: Add DT node for RNG IP
In reply to Tero KristoFrom: Lokesh Vutla <[email protected]>
Adding dt node for hardware random number generator IP.
--- arch/arm/boot/dts/dra7.dtsi | 9 +++++++++ 1 file changed, 9 insertions(+)
arch/arm/boot/dts/dra7.dtsi +9 -0
@@ -1787,6 +1787,15 @@ clocks = <&l3_iclk_div>; clock-names = "fck"; }; + + rng: rng at 48090000 { + compatible = "ti,omap4-rng"; + ti,hwmods = "rng"; + reg = <0x48090000 0x2000>; + interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&l3_iclk_div>; + clock-names = "fck"; + }; }; thermal_zones: thermal-zones {
Signature · 1 line
1.9.1
PATCH v2 19/27 ARM: dts: AM43xx: clk: Add RNG clk node
In reply to Tero KristoFrom: Lokesh Vutla <[email protected]>
Add clk node for RNG module.
--- arch/arm/boot/dts/am43xx-clocks.dtsi | 8 ++++++++ drivers/clk/ti/clk-43xx.c | 1 + 2 files changed, 9 insertions(+)
arch/arm/boot/dts/am43xx-clocks.dtsi +8 -0
@@ -104,6 +104,14 @@ clock-div = <1>; }; + rng_fck: rng_fck { + #clock-cells = <0>; + compatible = "fixed-factor-clock"; + clocks = <&sys_clkin_ck>; + clock-mult = <1>; + clock-div = <1>; + }; + ehrpwm0_tbclk: ehrpwm0_tbclk at 664 { #clock-cells = <0>; compatible = "ti,gate-clock";
drivers/clk/ti/clk-43xx.c +1 -0
@@ -58,6 +58,7 @@ static struct ti_dt_clk am43xx_clks[] = {DT_CLK (NULL ,"smartreflex1_fck" ,"smartreflex1_fck" ),DT_CLK (NULL ,"sha0_fck" ,"sha0_fck" ),DT_CLK (NULL ,"aes0_fck" ,"aes0_fck" ), +DT_CLK (NULL ,"rng_fck" ,"rng_fck" ),DT_CLK (NULL ,"timer1_fck" ,"timer1_fck" ),DT_CLK (NULL ,"timer2_fck" ,"timer2_fck" ), DT_CLK(NULL, "timer3_fck", "timer3_fck"),
Signature · 1 line
1.9.1
PATCH v2 20/27 ARM: dts: AM43xx: Add node for RNG
In reply to Tero KristoFrom: Lokesh Vutla <[email protected]>
Adding DT node for hardware random number generator.
--- arch/arm/boot/dts/am4372.dtsi | 7 +++++++ 1 file changed, 7 insertions(+)
arch/arm/boot/dts/am4372.dtsi +7 -0
@@ -843,6 +843,13 @@ dma-names = "tx", "rx"; }; + rng: rng at 48310000 { + compatible = "ti,omap4-rng"; + ti,hwmods = "rng"; + reg = <0x48310000 0x2000>; + interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>; + }; + mcasp0: mcasp at 48038000 { compatible = "ti,am33xx-mcasp-audio"; ti,hwmods = "mcasp0";
Signature · 1 line
1.9.1
PATCH v2 21/27 ARM: DRA7: hwmod: Add data for DES IP
In reply to Tero KristoFrom: Joel Fernandes <[email protected]>
DRA7 SoC contains DES crypto hardware accelerator. Add hwmod data for this IP so that it can be utilized by crypto frameworks.
--- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 37 +++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+)
arch/arm/mach-omap2/omap_hwmod_7xx_data.c +37 -0
@@ -2541,6 +2541,34 @@ static struct omap_hwmod dra7xx_uart10_hwmod = { }, }; +/* DES (the 'P' (public) device) */ +static struct omap_hwmod_class_sysconfig dra7xx_des_sysc = { + .rev_offs =0x0030 , + .sysc_offs =0x0034 , + .syss_offs =0x0038 , + .sysc_flags =SYSS_HAS_RESET_STATUS , +}; + +static struct omap_hwmod_class dra7xx_des_hwmod_class = { + .name ="des" , + .sysc = &dra7xx_des_sysc, +}; + +/* DES */ +static struct omap_hwmod dra7xx_des_hwmod = { + .name ="des" , + .class = &dra7xx_des_hwmod_class, + .clkdm_name ="l4sec_clkdm" , + .main_clk ="l3_iclk_div" , + .prcm = { + .omap4 = { + .clkctrl_offs =DRA7XX_CM_L4SEC_DES3DES_CLKCTRL_OFFSET , + .context_offs =DRA7XX_RM_L4SEC_DES3DES_CONTEXT_OFFSET , + .modulemode =MODULEMODE_HWCTRL , + }, + }, +}; +/* * 'usb_otg_ss' class *
@@ -3683,6 +3711,14 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per2__uart7 = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; +/* l4_per1 -> des */ +static struct omap_hwmod_ocp_if dra7xx_l4_per1__des = { + .master = &dra7xx_l4_per1_hwmod, + .slave = &dra7xx_des_hwmod, + .clk ="l3_iclk_div" , + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; +/* l4_per2 -> uart8 */ static struct omap_hwmod_ocp_if dra7xx_l4_per2__uart8 = { .master = &dra7xx_l4_per2_hwmod,
@@ -3916,6 +3952,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = { &dra7xx_l4_per2__uart8, &dra7xx_l4_per2__uart9, &dra7xx_l4_wkup__uart10, + &dra7xx_l4_per1__des, &dra7xx_l4_per3__usb_otg_ss1, &dra7xx_l4_per3__usb_otg_ss2, &dra7xx_l4_per3__usb_otg_ss3,
Signature · 1 line
1.9.1
PATCH v2 22/27 ARM: DRA7: hwmod: Add data for AES IP
In reply to Tero KristoFrom: Joel Fernandes <[email protected]>
DRA7 SoC contains AES crypto hardware accelerator. Add hwmod data for this IP so that it can be utilized by crypto frameworks.
--- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 62 +++++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+)
arch/arm/mach-omap2/omap_hwmod_7xx_data.c +62 -0
@@ -690,6 +690,50 @@ static struct omap_hwmod dra7xx_dss_hdmi_hwmod = { .parent_hwmod = &dra7xx_dss_hwmod, }; +/* AES (the 'P' (public) device) */ +static struct omap_hwmod_class_sysconfig dra7xx_aes_sysc = { + .rev_offs =0x0080 , + .sysc_offs =0x0084 , + .syss_offs =0x0088 , + .sysc_flags =SYSS_HAS_RESET_STATUS , +}; + +static struct omap_hwmod_class dra7xx_aes_hwmod_class = { + .name ="aes" , + .sysc = &dra7xx_aes_sysc, + .rev =2 , +}; + +/* AES1 */ +static struct omap_hwmod dra7xx_aes1_hwmod = { + .name ="aes1" , + .class = &dra7xx_aes_hwmod_class, + .clkdm_name ="l4sec_clkdm" , + .main_clk ="l3_iclk_div" , + .prcm = { + .omap4 = { + .clkctrl_offs =DRA7XX_CM_L4SEC_AES1_CLKCTRL_OFFSET , + .context_offs =DRA7XX_RM_L4SEC_AES1_CONTEXT_OFFSET , + .modulemode =MODULEMODE_HWCTRL , + }, + }, +}; + +/* AES2 */ +static struct omap_hwmod dra7xx_aes2_hwmod = { + .name ="aes2" , + .class = &dra7xx_aes_hwmod_class, + .clkdm_name ="l4sec_clkdm" , + .main_clk ="l3_iclk_div" , + .prcm = { + .omap4 = { + .clkctrl_offs =DRA7XX_CM_L4SEC_AES2_CLKCTRL_OFFSET , + .context_offs =DRA7XX_RM_L4SEC_AES2_CONTEXT_OFFSET , + .modulemode =MODULEMODE_HWCTRL , + }, + }, +}; +/* * 'elm' class *
@@ -2988,6 +3032,22 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__hdmi = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; +/* l3_main_1 -> aes1 */ +static struct omap_hwmod_ocp_if dra7xx_l3_main_1__aes1 = { + .master = &dra7xx_l3_main_1_hwmod, + .slave = &dra7xx_aes1_hwmod, + .clk ="l3_iclk_div" , + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; + +/* l3_main_1 -> aes2 */ +static struct omap_hwmod_ocp_if dra7xx_l3_main_1__aes2 = { + .master = &dra7xx_l3_main_1_hwmod, + .slave = &dra7xx_aes2_hwmod, + .clk ="l3_iclk_div" , + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; +/* l4_per2 -> mcasp1 */ static struct omap_hwmod_ocp_if dra7xx_l4_per2__mcasp1 = { .master = &dra7xx_l4_per2_hwmod,
@@ -3877,6 +3937,8 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = { &dra7xx_l3_main_1__dss, &dra7xx_l3_main_1__dispc, &dra7xx_l3_main_1__hdmi, + &dra7xx_l3_main_1__aes1, + &dra7xx_l3_main_1__aes2, &dra7xx_l4_per1__elm, &dra7xx_l4_wkup__gpio1, &dra7xx_l4_per1__gpio2,
Signature · 1 line
1.9.1
PATCH v2 23/27 ARM: DRA7: hwmod: Add data for SHA IP
In reply to Tero KristoFrom: Lokesh Vutla <[email protected]>
DRA7 SoC contains SHA crypto hardware accelerator. Add hwmod data for this IP so that it can be utilized by crypto frameworks.
--- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 37 +++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+)
arch/arm/mach-omap2/omap_hwmod_7xx_data.c +37 -0
@@ -734,6 +734,34 @@ static struct omap_hwmod dra7xx_aes2_hwmod = { }, }; +/* sha0 HIB2 (the 'P' (public) device) */ +static struct omap_hwmod_class_sysconfig dra7xx_sha0_sysc = { + .rev_offs =0x100 , + .sysc_offs =0x110 , + .syss_offs =0x114 , + .sysc_flags =SYSS_HAS_RESET_STATUS , +}; + +static struct omap_hwmod_class dra7xx_sha0_hwmod_class = { + .name ="sham" , + .sysc = &dra7xx_sha0_sysc, + .rev =2 , +}; + +struct omap_hwmod dra7xx_sha0_hwmod = { + .name ="sham" , + .class = &dra7xx_sha0_hwmod_class, + .clkdm_name ="l4sec_clkdm" , + .main_clk ="l3_iclk_div" , + .prcm = { + .omap4 = { + .clkctrl_offs =DRA7XX_CM_L4SEC_SHA2MD51_CLKCTRL_OFFSET , + .context_offs =DRA7XX_RM_L4SEC_SHA2MD51_CONTEXT_OFFSET , + .modulemode =MODULEMODE_HWCTRL , + }, + }, +}; +/* * 'elm' class *
@@ -3048,6 +3076,14 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__aes2 = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; +/* l3_main_1 -> sha0 */ +static struct omap_hwmod_ocp_if dra7xx_l3_main_1__sha0 = { + .master = &dra7xx_l3_main_1_hwmod, + .slave = &dra7xx_sha0_hwmod, + .clk ="l3_iclk_div" , + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; +/* l4_per2 -> mcasp1 */ static struct omap_hwmod_ocp_if dra7xx_l4_per2__mcasp1 = { .master = &dra7xx_l4_per2_hwmod,
@@ -3939,6 +3975,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = { &dra7xx_l3_main_1__hdmi, &dra7xx_l3_main_1__aes1, &dra7xx_l3_main_1__aes2, + &dra7xx_l3_main_1__sha0, &dra7xx_l4_per1__elm, &dra7xx_l4_wkup__gpio1, &dra7xx_l4_per1__gpio2,
Signature · 1 line
1.9.1
PATCH v2 24/27 ARM: DRA7: hwmod: Add data for RNG IP
In reply to Tero KristoFrom: Joel Fernandes <[email protected]>
DRA7 SoC contains hardware random number generator. Add hwmod data for this IP so that it can be utilized.
[t-kristo at ti.com: squashed the RNG hwmod IP flag fixes from Lokesh,
squashed the HS chip fix from Daniel Allred]
--- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 36 +++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+)
arch/arm/mach-omap2/omap_hwmod_7xx_data.c +36 -0
@@ -2641,6 +2641,34 @@ static struct omap_hwmod dra7xx_des_hwmod = { }, }; +/* rng */ +static struct omap_hwmod_class_sysconfig dra7xx_rng_sysc = { + .rev_offs =0x1fe0 , + .sysc_offs =0x1fe4 , + .sysc_flags =SYSC_HAS_AUTOIDLE |SYSC_HAS_SIDLEMODE , + .idlemodes =SIDLE_FORCE |SIDLE_NO , + .sysc_fields = &omap_hwmod_sysc_type1, +}; + +static struct omap_hwmod_class dra7xx_rng_hwmod_class = { + .name ="rng" , + .sysc = &dra7xx_rng_sysc, +}; + +static struct omap_hwmod dra7xx_rng_hwmod = { + .name ="rng" , + .class = &dra7xx_rng_hwmod_class, + .flags =HWMOD_SWSUP_SIDLE , + .clkdm_name ="l4sec_clkdm" , + .prcm = { + .omap4 = { + .clkctrl_offs =DRA7XX_CM_L4SEC_RNG_CLKCTRL_OFFSET , + .context_offs =DRA7XX_RM_L4SEC_RNG_CONTEXT_OFFSET , + .modulemode =MODULEMODE_HWCTRL , + }, + }, +}; +/* * 'usb_otg_ss' class *
@@ -3839,6 +3867,13 @@ static struct omap_hwmod_ocp_if dra7xx_l4_wkup__uart10 = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; +/* l4_per1 -> rng */ +static struct omap_hwmod_ocp_if dra7xx_l4_per1__rng = { + .master = &dra7xx_l4_per1_hwmod, + .slave = &dra7xx_rng_hwmod, + .user =OCP_USER_MPU , +}; +/* l4_per3 -> usb_otg_ss1 */ static struct omap_hwmod_ocp_if dra7xx_l4_per3__usb_otg_ss1 = { .master = &dra7xx_l4_per3_hwmod,
@@ -4069,6 +4104,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {/* GP-only hwmod links */ static struct omap_hwmod_ocp_if *dra7xx_gp_hwmod_ocp_ifs[]__initdata = { &dra7xx_l4_wkup__timer12, + &dra7xx_l4_per1__rng,NULL , };
Signature · 1 line
1.9.1
PATCH v2 25/27 ARM: OMAP: DRA7xx: Make L4SEC clock domain SWSUP only
In reply to Tero KristoFrom: Joel Fernandes <[email protected]>
Using HWSUP for l4sec clock domain is causing warnings in HWMOD code for DRA7. Based on some observations, once the clock domain goes into an IDLE state (because of no activity etc), the IDLEST for the module goes to '0x2' value which means Interface IDLE condition. So far so go, however once the MODULEMODE is set to disabled for the particular IP, the IDLEST for the module should go to '0x3', per the HW AUTO IDLE protocol. However this is not observed and there is no reason per the protocl for the transition to not happen. This could potentially be a bug in the HW AUTO state-machine.
Work around for this is to use SWSUP only for the particular clockdomain. With this all the transitions of IDLEST happen correctly and warnings don't occur.
--- arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/mach-omap2/clockdomains7xx_data.c +1 -1
@@ -409,7 +409,7 @@ static struct clockdomain l4sec_7xx_clkdm = { .dep_bit = DRA7XX_L4SEC_STATDEP_SHIFT, .wkdep_srcs = l4sec_wkup_sleep_deps, .sleepdep_srcs = l4sec_wkup_sleep_deps, - .flags = CLKDM_CAN_HWSUP_SWSUP, + .flags = CLKDM_CAN_SWSUP, };static struct clockdomain l3main1_7xx_clkdm = {
Signature · 1 line
1.9.1
PATCH v2 26/27 ARM: AM43xx: hwmod: Add data for DES
In reply to Tero KristoFrom: Lokesh Vutla <[email protected]>
AM43xx SoC contains DES crypto hardware accelerator. Add hwmod data for this IP so that it can be utilized by crypto frameworks.
--- arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 33 ++++++++++++++++++++++++++++++ arch/arm/mach-omap2/prcm43xx.h | 1 + 2 files changed, 34 insertions(+)
arch/arm/mach-omap2/omap_hwmod_43xx_data.c +33 -0
@@ -463,6 +463,31 @@ static struct omap_hwmod am43xx_adc_tsc_hwmod = { }, }; +static struct omap_hwmod_class_sysconfig am43xx_des_sysc = { + .rev_offs =0x30 , + .sysc_offs =0x34 , + .syss_offs =0x38 , + .sysc_flags =SYSS_HAS_RESET_STATUS , +}; + +static struct omap_hwmod_class am43xx_des_hwmod_class = { + .name ="des" , + .sysc = &am43xx_des_sysc, +}; + +static struct omap_hwmod am43xx_des_hwmod = { + .name ="des" , + .class = &am43xx_des_hwmod_class, + .clkdm_name ="l3_clkdm" , + .main_clk ="l3_gclk" , + .prcm = { + .omap4 = { + .clkctrl_offs =AM43XX_CM_PER_DES_CLKCTRL_OFFSET , + .modulemode =MODULEMODE_SWCTRL , + }, + }, +}; +/* dss */ static struct omap_hwmod am43xx_dss_core_hwmod = {
@@ -912,6 +937,13 @@ static struct omap_hwmod_ocp_if am43xx_l4_ls__vpfe1 = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; +static struct omap_hwmod_ocp_if am43xx_l3_main__des = { + .master = &am33xx_l3_main_hwmod, + .slave = &am43xx_des_hwmod, + .clk ="l3_gclk" , + .user =OCP_USER_MPU , +}; +static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[]__initdata = { &am33xx_l4_wkup__synctimer, &am43xx_l4_ls__timer8,
@@ -1004,6 +1036,7 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = { &am33xx_cpgmac0__mdio, &am33xx_l3_main__sha0, &am33xx_l3_main__aes0, + &am43xx_l3_main__des, &am43xx_l4_ls__ocp2scp0, &am43xx_l4_ls__ocp2scp1, &am43xx_l3_s__usbotgss0,
arch/arm/mach-omap2/prcm43xx.h +1 -0
@@ -132,6 +132,7 @@#define AM43XX_CM_PER_OCMCRAM_CLKCTRL_OFFSET 0x0050#define AM43XX_CM_PER_SHA0_CLKCTRL_OFFSET 0x0058#define AM43XX_CM_PER_AES0_CLKCTRL_OFFSET 0x0028 +#define AM43XX_CM_PER_DES_CLKCTRL_OFFSET 0x0030#define AM43XX_CM_PER_TIMER8_CLKCTRL_OFFSET 0x0560#define AM43XX_CM_PER_TIMER9_CLKCTRL_OFFSET 0x0568#define AM43XX_CM_PER_TIMER10_CLKCTRL_OFFSET 0x0570
Signature · 1 line
1.9.1
PATCH v2 27/27 ARM: AMx3xx: hwmod: Add data for RNG
In reply to Tero KristoFrom: Lokesh Vutla <[email protected]>
Hardware random number generator is present in both AM33xx and AM43xx SoC's. So moving the hwmod data to common data.
--- .../mach-omap2/omap_hwmod_33xx_43xx_common_data.h | 2 ++ .../omap_hwmod_33xx_43xx_interconnect_data.c | 8 +++++ .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 29 ++++++++++++++++++ arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 35 ---------------------- arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 1 + arch/arm/mach-omap2/prcm43xx.h | 1 + 6 files changed, 41 insertions(+), 35 deletions(-)
arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h +2 -0
@@ -77,6 +77,7 @@ extern struct omap_hwmod_ocp_if am33xx_l4_ls__uart6;extern struct omap_hwmod_ocp_if am33xx_l3_main__ocmc;extern struct omap_hwmod_ocp_if am33xx_l3_main__sha0;extern struct omap_hwmod_ocp_if am33xx_l3_main__aes0; +extern struct omap_hwmod_ocp_if am33xx_l4_per__rng;extern struct omap_hwmod am33xx_l3_main_hwmod;extern struct omap_hwmod am33xx_l3_s_hwmod;
@@ -89,6 +90,7 @@ extern struct omap_hwmod am33xx_gfx_hwmod;extern struct omap_hwmod am33xx_prcm_hwmod;extern struct omap_hwmod am33xx_aes0_hwmod;extern struct omap_hwmod am33xx_sha0_hwmod; +extern struct omap_hwmod am33xx_rng_hwmod;extern struct omap_hwmod am33xx_ocmcram_hwmod;extern struct omap_hwmod am33xx_smartreflex0_hwmod;extern struct omap_hwmod am33xx_smartreflex1_hwmod;
arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c +8 -0
@@ -611,3 +611,11 @@ struct omap_hwmod_ocp_if am33xx_l3_main__aes0 = { .addr = am33xx_aes0_addrs, .user = OCP_USER_MPU | OCP_USER_SDMA, }; + +/* l4 per -> rng */ +struct omap_hwmod_ocp_if am33xx_l4_per__rng = { + .master = &am33xx_l4_ls_hwmod, + .slave = &am33xx_rng_hwmod, + .clk ="rng_fck" , + .user =OCP_USER_MPU , +};
arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c +29 -0
@@ -267,6 +267,33 @@ struct omap_hwmod am33xx_sha0_hwmod = { }, }; +/* rng */ +static struct omap_hwmod_class_sysconfig am33xx_rng_sysc = { + .rev_offs =0x1fe0 , + .sysc_offs =0x1fe4 , + .sysc_flags =SYSC_HAS_AUTOIDLE |SYSC_HAS_SIDLEMODE , + .idlemodes =SIDLE_FORCE |SIDLE_NO , + .sysc_fields = &omap_hwmod_sysc_type1, +}; + +static struct omap_hwmod_class am33xx_rng_hwmod_class = { + .name ="rng" , + .sysc = &am33xx_rng_sysc, +}; + +struct omap_hwmod am33xx_rng_hwmod = { + .name ="rng" , + .class = &am33xx_rng_hwmod_class, + .clkdm_name ="l4ls_clkdm" , + .flags =HWMOD_SWSUP_SIDLE , + .main_clk ="rng_fck" , + .prcm = { + .omap4 = { + .modulemode =MODULEMODE_SWCTRL , + }, + }, +}; +/* ocmcram */ static struct omap_hwmod_class am33xx_ocmcram_hwmod_class = { .name ="ocmcram" ,
@@ -1397,6 +1424,7 @@ static void omap_hwmod_am33xx_clkctrl(void)CLKCTRL (am33xx_ocmcram_hwmod ,AM33XX_CM_PER_OCMCRAM_CLKCTRL_OFFSET );CLKCTRL (am33xx_sha0_hwmod ,AM33XX_CM_PER_SHA0_CLKCTRL_OFFSET );CLKCTRL (am33xx_aes0_hwmod ,AM33XX_CM_PER_AES0_CLKCTRL_OFFSET ); +CLKCTRL (am33xx_rng_hwmod,AM33XX_CM_PER_RNG_CLKCTRL_OFFSET ); }static void omap_hwmod_am33xx_rst (void )
@@ -1470,6 +1498,7 @@ static void omap_hwmod_am43xx_clkctrl(void)CLKCTRL (am33xx_ocmcram_hwmod ,AM43XX_CM_PER_OCMCRAM_CLKCTRL_OFFSET );CLKCTRL (am33xx_sha0_hwmod ,AM43XX_CM_PER_SHA0_CLKCTRL_OFFSET );CLKCTRL (am33xx_aes0_hwmod ,AM43XX_CM_PER_AES0_CLKCTRL_OFFSET ); +CLKCTRL (am33xx_rng_hwmod,AM43XX_CM_PER_RNG_CLKCTRL_OFFSET ); }static void omap_hwmod_am43xx_rst (void )
arch/arm/mach-omap2/omap_hwmod_33xx_data.c +0 -35
@@ -503,41 +503,6 @@ static struct omap_hwmod_ocp_if am33xx_l3_s__usbss = { .flags = OCPIF_SWSUP_IDLE, }; -/* rng */ -static struct omap_hwmod_class_sysconfig am33xx_rng_sysc = { - .rev_offs =0x1fe0 , - .sysc_offs =0x1fe4 , - .sysc_flags =SYSC_HAS_AUTOIDLE |SYSC_HAS_SIDLEMODE , - .idlemodes =SIDLE_FORCE |SIDLE_NO , - .sysc_fields = &omap_hwmod_sysc_type1, -}; - -static struct omap_hwmod_class am33xx_rng_hwmod_class = { - .name ="rng" , - .sysc = &am33xx_rng_sysc, -}; - -static struct omap_hwmod am33xx_rng_hwmod = { - .name ="rng" , - .class = &am33xx_rng_hwmod_class, - .clkdm_name ="l4ls_clkdm" , - .flags =HWMOD_SWSUP_SIDLE , - .main_clk ="rng_fck" , - .prcm = { - .omap4 = { - .clkctrl_offs =AM33XX_CM_PER_RNG_CLKCTRL_OFFSET , - .modulemode =MODULEMODE_SWCTRL , - }, - }, -}; - -static struct omap_hwmod_ocp_if am33xx_l4_per__rng = { - .master = &am33xx_l4_ls_hwmod, - .slave = &am33xx_rng_hwmod, - .clk ="rng_fck" , - .user =OCP_USER_MPU , -}; -static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[]__initdata = { &am33xx_l3_main__emif, &am33xx_mpu__l3_main,
arch/arm/mach-omap2/omap_hwmod_43xx_data.c +1 -0
@@ -994,6 +994,7 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = { &am33xx_l4_per__i2c2, &am33xx_l4_per__i2c3, &am33xx_l4_per__mailbox, + &am33xx_l4_per__rng, &am33xx_l4_ls__mcasp0, &am33xx_l4_ls__mcasp1, &am33xx_l4_ls__mmc0,
arch/arm/mach-omap2/prcm43xx.h +1 -0
@@ -91,6 +91,7 @@#define AM43XX_CM_PER_MAILBOX0_CLKCTRL_OFFSET 0x04b8#define AM43XX_CM_PER_MMC0_CLKCTRL_OFFSET 0x04c0#define AM43XX_CM_PER_MMC1_CLKCTRL_OFFSET 0x04c8 +#define AM43XX_CM_PER_RNG_CLKCTRL_OFFSET 0x04e0#define AM43XX_CM_PER_SPI0_CLKCTRL_OFFSET 0x0500#define AM43XX_CM_PER_SPI1_CLKCTRL_OFFSET 0x0508#define AM43XX_CM_PER_SPINLOCK_CLKCTRL_OFFSET 0x0528
Signature · 1 line
1.9.1
Tony Lindgren
maintainerv2 cover crypto: fixes for omap family of devices
In reply to Tero KristoQuoted 11 lines · Tero Kristo
Hi,
Changes compared to v1 of the series:
- dropped first patch from the series (crypto: omap-aes: Fix registration of algorithms) as it was queued by Herbert already
- modified the second (now first) patch of the series to use runtime auto- suspend instead of getting static sync over a cra lifetime
- re-ordered the DTS / hwmod changes in the series, the merge order of these must be maintained to avoid issues
Quoted 2 lines
Patches #01 .. #14 should be merged via crypto tree, the rest should be handled by Tony.
Next time, please post sets like these split into three separate sets with the cover letter listing possible dependencies. Picking patches from sets in certain order is a big pain to follow up, and some maintainers tend to ignore patchsets with dependencies.
Quoted 3 lines
Merging the omap / dts parts can be done safely separately, assuming you just use
omap2plus_defconfig(enabling crypto features will cause some issues without the driver level fixes.)
I've already applied the dts changes I believe.. So reposting already applied patches further confuses things. Now I have to figure out what is already applied..
Regards,
Tony