From: Tero Kristo <hidden> Date: 2016-06-22 13:24:56
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
From: Tero Kristo <hidden> Date: 2016-06-22 13:23:38
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 <redacted>
---
drivers/crypto/omap-sham.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
From: Herbert Xu <herbert@gondor.apana.org.au> Date: 2016-06-24 10:30:51
On Wed, Jun 22, 2016 at 04:23:38PM +0300, Tero Kristo wrote:
quoted hunk
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 <redacted>
---
drivers/crypto/omap-sham.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
From: Tero Kristo <hidden> Date: 2016-06-27 05:05:01
On 24/06/16 13:30, Herbert Xu wrote:
On Wed, Jun 22, 2016 at 04:23:38PM +0300, Tero Kristo wrote:
quoted
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 <redacted>
---
drivers/crypto/omap-sham.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
@@ -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((unsignedlong)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
From: Tero Kristo <hidden> Date: 2016-06-22 13:23:39
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 <redacted>
---
crypto/ahash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Herbert Xu <herbert@gondor.apana.org.au> Date: 2016-06-24 10:32:15
On Wed, Jun 22, 2016 at 04:23:39PM +0300, Tero Kristo wrote:
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 <redacted>
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.
--
Email: Herbert Xu [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
From: Tero Kristo <hidden> Date: 2016-06-27 04:59:20
On 24/06/16 13:32, Herbert Xu wrote:
On Wed, Jun 22, 2016 at 04:23:39PM +0300, Tero Kristo wrote:
quoted
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 <redacted>
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
From: Herbert Xu <herbert@gondor.apana.org.au> Date: 2016-06-27 05:00:41
On Mon, Jun 27, 2016 at 07:58:43AM +0300, Tero Kristo wrote:
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.
From: Tero Kristo <hidden> Date: 2016-07-04 09:17:02
On 27/06/16 08:00, Herbert Xu wrote:
On Mon, Jun 27, 2016 at 07:58:43AM +0300, Tero Kristo wrote:
quoted
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.
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
From: Herbert Xu <herbert@gondor.apana.org.au> Date: 2016-07-04 09:19:58
On Mon, Jul 04, 2016 at 12:17:02PM +0300, Tero Kristo wrote:
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:
From: Tero Kristo <hidden> Date: 2016-07-04 09:27:34
On 04/07/16 12:19, Herbert Xu wrote:
On Mon, Jul 04, 2016 at 12:17:02PM +0300, Tero Kristo wrote:
quoted
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:
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
From: Herbert Xu <herbert@gondor.apana.org.au> Date: 2016-07-04 09:42:26
On Mon, Jul 04, 2016 at 12:27:00PM +0300, Tero Kristo wrote:
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,
--
Email: Herbert Xu [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
From: Tero Kristo <hidden> Date: 2016-06-22 13:24:56
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.
Signed-off-by: Tero Kristo <redacted>
---
drivers/crypto/omap-sham.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
From: Herbert Xu <herbert@gondor.apana.org.au> Date: 2016-06-24 13:30:57
On Wed, Jun 22, 2016 at 04:23:34PM +0300, Tero Kristo wrote:
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.
Signed-off-by: Tero Kristo <redacted>
From: Tero Kristo <hidden> Date: 2016-06-22 13:25:03
From: Bin Liu <b-liu@ti.com>
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.
Signed-off-by: Bin Liu <b-liu@ti.com>
[t-kristo at ti.com: dropped the extra traces, updated some comments
on the code]
Signed-off-by: Tero Kristo <redacted>
---
drivers/crypto/omap-sham.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
@@ -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){/**OMAPHWaccelworksonlywithbuffers>=9*willswitchtobypassinfinal()
@@ -1151,9 +1151,13 @@ static int omap_sham_final(struct ahash_request *req)if(ctx->flags&BIT(FLAGS_ERROR))return0;/* 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)+/*+*OMAPHWaccelworksonlywithbuffers>=9.+*HMACisalways>=9becauseipad==blocksize.+*Ifbuffersizeislessthan240,weusefallbackSWencoding,+*asusingDMA+HWinthiscasedoesn'tprovideanybenefit.+*/+if((ctx->digcnt+ctx->bufcnt)<240)returnomap_sham_final_shash(req);elseif(ctx->bufcnt)returnomap_sham_enqueue(req,OP_FINAL);
From: Tero Kristo <hidden> Date: 2016-06-22 13:25:08
From: Lokesh Vutla <redacted>
The extra call to dmaengine_terminate_all is not needed, as the DMA
is not running at this point. This improves performance slightly.
Signed-off-by: Lokesh Vutla <redacted>
Signed-off-by: Tero Kristo <redacted>
---
drivers/crypto/omap-aes.c | 2 --
drivers/crypto/omap-sham.c | 1 -
2 files changed, 3 deletions(-)
From: Tero Kristo <hidden> Date: 2016-06-22 13:25:10
Change 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.
Signed-off-by: Tero Kristo <redacted>
---
drivers/crypto/omap-sham.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Tero Kristo <hidden> Date: 2016-06-22 13:25:11
Context 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.
Signed-off-by: Tero Kristo <redacted>
---
drivers/crypto/omap-sham.c | 40 ++++++++++++++++++++++++++++++++++++++--
1 file changed, 38 insertions(+), 2 deletions(-)
From: Tero Kristo <hidden> Date: 2016-06-22 13:25:14
From: Lokesh Vutla <redacted>
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.
Signed-off-by: Lokesh Vutla <redacted>
Tested-by: Aparna Balasubramanian <redacted>
Signed-off-by: Tero Kristo <redacted>
---
drivers/crypto/omap-des.c | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
@@ -521,29 +521,36 @@ static int omap_des_crypt_dma_stop(struct omap_des_dev *dd)return0;}-staticintomap_des_copy_needed(structscatterlist*sg)+staticintomap_des_copy_needed(structscatterlist*sg,inttotal){+intlen=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;+return0;}staticintomap_des_copy_sgs(structomap_des_dev*dd){void*buf_in,*buf_out;-intpages;--pages=dd->total>>PAGE_SHIFT;--if(dd->total&(PAGE_SIZE-1))-pages++;+intpages,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;
From: Tero Kristo <hidden> Date: 2016-06-22 13:25:21
From: Lokesh Vutla <redacted>
Enable clocks for all cores before starting session.
Driver has to pic the aes core dynamically based on the queue length.
Signed-off-by: Lokesh Vutla <redacted>
---
drivers/crypto/omap-aes.c | 23 +++++++----------------
1 file changed, 7 insertions(+), 16 deletions(-)
@@ -760,18 +760,13 @@ static int omap_aes_cra_init(struct crypto_tfm *tfm)structomap_aes_dev*dd=NULL;interr;-/* 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);-returnerr;+err=pm_runtime_get_sync(dd->dev);+if(err<0){+dev_err(dd->dev,"%s: failed to get_sync(%d)\n",+__func__,err);+returnerr;+}}tfm->crt_ablkcipher.reqsize=sizeof(structomap_aes_reqctx);
@@ -783,14 +778,10 @@ static void omap_aes_cra_exit(struct crypto_tfm *tfm){structomap_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 ************************************ */
From: Tero Kristo <hidden> Date: 2016-06-22 13:25:22
From: Lokesh Vutla <redacted>
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.
Signed-off-by: Lokesh Vutla <redacted>
[t-kristo at ti.com: forward ported to 4.7 kernel]
Signed-off-by: Tero Kristo <redacted>
---
drivers/crypto/omap-aes.c | 20 ++++++--------------
1 file changed, 6 insertions(+), 14 deletions(-)
@@ -319,20 +319,12 @@ static void omap_aes_dma_stop(struct omap_aes_dev *dd)staticstructomap_aes_dev*omap_aes_find_dev(structomap_aes_ctx*ctx){-structomap_aes_dev*dd=NULL,*tmp;+structomap_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,structomap_aes_dev,list);+list_move_tail(&dd->list,&dev_list);+ctx->dd=dd;spin_unlock_bh(&list_lock);returndd;
@@ -600,7 +592,7 @@ static int omap_aes_prepare_req(struct crypto_engine *engine,{structomap_aes_ctx*ctx=crypto_ablkcipher_ctx(crypto_ablkcipher_reqtfm(req));-structomap_aes_dev*dd=omap_aes_find_dev(ctx);+structomap_aes_dev*dd=ctx->dd;structomap_aes_reqctx*rctx;intlen;
@@ -644,7 +636,7 @@ static int omap_aes_crypt_req(struct crypto_engine *engine,{structomap_aes_ctx*ctx=crypto_ablkcipher_ctx(crypto_ablkcipher_reqtfm(req));-structomap_aes_dev*dd=omap_aes_find_dev(ctx);+structomap_aes_dev*dd=ctx->dd;if(!dd)return-ENODEV;
From: Tero Kristo <hidden> Date: 2016-06-22 13:25:22
From: Lokesh Vutla <redacted>
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.
Signed-off-by: Lokesh Vutla <redacted>
Signed-off-by: Tero Kristo <redacted>
---
drivers/crypto/Kconfig | 3 +++
drivers/crypto/omap-aes.c | 45 ++++++++++++++++++++++++++++++++++++++++++---
2 files changed, 45 insertions(+), 3 deletions(-)
From: Tero Kristo <hidden> Date: 2016-06-22 13:25:25
The 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.
Fixes: f1b77aaca85a ("crypto: omap-des - Integrate with the crypto engine framework")
Signed-off-by: Tero Kristo <redacted>
---
drivers/crypto/omap-des.c | 28 +++++++++++++++-------------
1 file changed, 15 insertions(+), 13 deletions(-)
From: Tero Kristo <hidden> Date: 2016-06-22 13:25:26
Crypto 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.
Signed-off-by: Tero Kristo <redacted>
---
crypto/crypto_engine.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
From: Tero Kristo <hidden> Date: 2016-06-22 13:25:28
From: Joel Fernandes <redacted>
DRA7xx SoCs have a DES3DES IP. Add DT data for the same.
Signed-off-by: Joel Fernandes <redacted>
---
arch/arm/boot/dts/dra7.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
From: Tero Kristo <hidden> Date: 2016-06-22 13:25:29
The 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.
Fixes: 0529900a01cb ("crypto: omap-aes - Support crypto engine framework")
Signed-off-by: Tero Kristo <redacted>
---
drivers/crypto/omap-aes.c | 28 +++++++++++++++-------------
1 file changed, 15 insertions(+), 13 deletions(-)
From: Tero Kristo <hidden> Date: 2016-06-22 13:25:30
From: Joel Fernandes <redacted>
DRA7 SoC has the same AES IP as OMAP4. Add DT entries for both AES cores.
Signed-off-by: Joel Fernandes <redacted>
Signed-off-by: Lokesh Vutla <redacted>
[t-kristo at ti.com: squashed in the change to use EDMA, squashed in
support for two AES cores]
Signed-off-by: Tero Kristo <redacted>
---
arch/arm/boot/dts/dra7.dtsi | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
From: Tero Kristo <hidden> Date: 2016-06-22 13:25:42
From: Lokesh Vutla <redacted>
DRA7 SoC has the same SHA IP as OMAP5. Add DT entry for the same.
Signed-off-by: Lokesh Vutla <redacted>
[t-kristo at ti.com: changed SHA to use EDMA instead of SDMA]
Signed-off-by: Tero Kristo <redacted>
---
arch/arm/boot/dts/dra7.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
From: Tero Kristo <hidden> Date: 2016-06-22 13:25:47
From: Joel Fernandes <redacted>
DRA7 SoC contains DES crypto hardware accelerator. Add hwmod data for
this IP so that it can be utilized by crypto frameworks.
Signed-off-by: Joel Fernandes <redacted>
Signed-off-by: Lokesh Vutla <redacted>
Signed-off-by: Tero Kristo <redacted>
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 37 +++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
From: Tero Kristo <hidden> Date: 2016-06-22 13:25:54
From: Joel Fernandes <redacted>
DRA7 SoC contains hardware random number generator. Add hwmod data for
this IP so that it can be utilized.
Signed-off-by: Joel Fernandes <redacted>
Signed-off-by: Lokesh Vutla <redacted>
[t-kristo at ti.com: squashed the RNG hwmod IP flag fixes from Lokesh,
squashed the HS chip fix from Daniel Allred]
Signed-off-by: Tero Kristo <redacted>
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 36 +++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
From: Tero Kristo <hidden> Date: 2016-06-22 13:25:57
From: Joel Fernandes <redacted>
DRA7 SoC contains AES crypto hardware accelerator. Add hwmod data for
this IP so that it can be utilized by crypto frameworks.
Signed-off-by: Joel Fernandes <redacted>
Signed-off-by: Lokesh Vutla <redacted>
[t-kristo at ti.com: squash in support for both AES1 and AES2 cores]
Signed-off-by: Tero Kristo <redacted>
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 62 +++++++++++++++++++++++++++++++
1 file changed, 62 insertions(+)
From: Tero Kristo <hidden> Date: 2016-06-22 13:26:03
From: Lokesh Vutla <redacted>
DRA7 SoC contains SHA crypto hardware accelerator. Add hwmod data for
this IP so that it can be utilized by crypto frameworks.
Signed-off-by: Lokesh Vutla <redacted>
Signed-off-by: Tero Kristo <redacted>
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 37 +++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
From: Tero Kristo <hidden> Date: 2016-06-22 13:26:03
From: Lokesh Vutla <redacted>
AM43xx SoC contains DES crypto hardware accelerator. Add hwmod data for
this IP so that it can be utilized by crypto frameworks.
Signed-off-by: Lokesh Vutla <redacted>
Signed-off-by: Tero Kristo <redacted>
---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 33 ++++++++++++++++++++++++++++++
arch/arm/mach-omap2/prcm43xx.h | 1 +
2 files changed, 34 insertions(+)
From: Tero Kristo <hidden> Date: 2016-06-22 13:26:04
From: Joel Fernandes <redacted>
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.
Signed-off-by: Joel Fernandes <redacted>
Signed-off-by: Lokesh Vutla <redacted>
Signed-off-by: Tero Kristo <redacted>
---
arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Tony Lindgren <tony@atomide.com> Date: 2016-06-23 04:49:21
* Tero Kristo [off-list ref] [160622 06:27]:
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.
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.
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