Re: [PATCH 02/28] crypto: omap-sham: Don't idle/start SHA device between Encrypt operations

2016-06-01 Thread Dave Gerlach

On 06/01/2016 04:53 AM, Grygorii Strashko wrote:

On 06/01/2016 11:56 AM, Tero Kristo wrote:

From: Lokesh Vutla 

Calling runtime PM API for every block causes serious perf 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.

We call runtime_pm_get_sync only at beginning on the session (cra_init)
and runtime_pm_put at the end. This result in upto a 50% speedup.
This doesn't make the driver to keep the system awake as runtime get/put
is only called during a crypto session which completes usually quickly.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Tero Kristo 
---
  drivers/crypto/omap-sham.c | 27 +--
  1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 6eefaa2..bd0258f 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -360,14 +360,6 @@ static void omap_sham_copy_ready_hash(struct
ahash_request *req)

  static int omap_sham_hw_init(struct omap_sham_dev *dd)
  {
-int err;
-
-err = pm_runtime_get_sync(dd->dev);
-if (err < 0) {
-dev_err(dd->dev, "failed to get sync: %d\n", err);
-return err;
-}
-


Would it be worth it to investigate a pm_runtime autosuspend approach 
rather than knocking runtime PM out here completely? I am not clear if 
the overhead is coming from the pm_runtime calls themselves or the 
actual idling of the IP, but if it's the idling of the IP causing the 
slowdown, with a large enough autosuspend_delay we don't actually sleep 
between each block but after a long enough period of idle time we would 
actually suspend.


Regards,
Dave


  if (!test_bit(FLAGS_INIT, >flags)) {
  set_bit(FLAGS_INIT, >flags);
  dd->err = 0;
@@ -999,8 +991,6 @@ 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);
-
  if (req->base.complete)
  req->base.complete(>base, err);

@@ -1239,6 +1229,7 @@ static int omap_sham_cra_init_alg(struct
crypto_tfm *tfm, const char *alg_base)
  {
  struct omap_sham_ctx *tctx = crypto_tfm_ctx(tfm);
  const char *alg_name = crypto_tfm_alg_name(tfm);
+struct omap_sham_dev *dd;

  /* Allocate a fallback and abort if it failed. */
  tctx->fallback = crypto_alloc_shash(alg_name, 0,
@@ -1266,6 +1257,13 @@ static int omap_sham_cra_init_alg(struct
crypto_tfm *tfm, const char *alg_base)

  }

+spin_lock_bh();
+list_for_each_entry(dd, _list, list) {
+break;
+}
+spin_unlock_bh();
+
+pm_runtime_get_sync(dd->dev);
  return 0;
  }

@@ -1307,6 +1305,7 @@ static int omap_sham_cra_sha512_init(struct
crypto_tfm *tfm)
  static void omap_sham_cra_exit(struct crypto_tfm *tfm)
  {
  struct omap_sham_ctx *tctx = crypto_tfm_ctx(tfm);
+struct omap_sham_dev *dd;

  crypto_free_shash(tctx->fallback);
  tctx->fallback = NULL;
@@ -1315,6 +1314,14 @@ static void omap_sham_cra_exit(struct
crypto_tfm *tfm)
  struct omap_sham_hmac_ctx *bctx = tctx->base;
  crypto_free_shash(bctx->shash);
  }
+
+spin_lock_bh();
+list_for_each_entry(dd, _list, list) {
+break;
+}
+spin_unlock_bh();
+
+pm_runtime_get_sync(dd->dev);


May be put_?


  }

  static struct ahash_alg algs_sha1_md5[] = {






--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] hwrng: omap - Only fail if pm_runtime_get_sync returns < 0

2016-09-20 Thread Dave Gerlach
Currently omap-rng checks the return value of pm_runtime_get_sync and
reports failure if anything is returned, however it should be checking
if ret < 0 as pm_runtime_get_sync return 0 on success but also can return
1 if the device was already active which is not a failure case. Only
values < 0 are actual failures.

Fixes: 61dc0a446e5d ("hwrng: omap - Fix assumption that runtime_get_sync will 
always succeed")
Signed-off-by: Dave Gerlach <d-gerl...@ti.com>
---
 drivers/char/hw_random/omap-rng.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/char/hw_random/omap-rng.c 
b/drivers/char/hw_random/omap-rng.c
index 01d4be2c354b..f5c26a5f6875 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -385,7 +385,7 @@ static int omap_rng_probe(struct platform_device *pdev)
 
pm_runtime_enable(>dev);
ret = pm_runtime_get_sync(>dev);
-   if (ret) {
+   if (ret < 0) {
dev_err(>dev, "Failed to runtime_get device: %d\n", ret);
pm_runtime_put_noidle(>dev);
goto err_ioremap;
@@ -443,7 +443,7 @@ static int __maybe_unused omap_rng_resume(struct device 
*dev)
int ret;
 
ret = pm_runtime_get_sync(dev);
-   if (ret) {
+   if (ret < 0) {
dev_err(dev, "Failed to runtime_get device: %d\n", ret);
pm_runtime_put_noidle(dev);
return ret;
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html