* [PATCH v2 03/14] crypto: omap-aes: Populate number of SG elements
From: Joel Fernandes @ 2013-08-18 2:42 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Mark Greer, Tony Lindgren,
Santosh Shilimkar, Rajendra Nayak, Lokesh Vutla
Cc: Joel Fernandes, Linux OMAP List, Linux Kernel Mailing List,
Linux ARM Kernel List, Linux Crypto Mailing List
In-Reply-To: <1376793755-30478-1-git-send-email-joelf@ti.com>
Crypto layer only passes nbytes but number of SG elements is needed for mapping
or unmapping SGs at one time using dma_map* API and also needed to pass in for
dmaengine prep function.
We call function added to scatterwalk for this purpose in omap_aes_handle_queue
to populate the values which are used later.
Signed-off-by: Joel Fernandes <joelf@ti.com>
---
drivers/crypto/omap-aes.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 26b802b..e369e6e 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -164,6 +164,8 @@ struct omap_aes_dev {
void *buf_out;
int dma_out;
struct dma_chan *dma_lch_out;
+ int in_sg_len;
+ int out_sg_len;
dma_addr_t dma_addr_out;
const struct omap_aes_pdata *pdata;
@@ -731,6 +733,10 @@ static int omap_aes_handle_queue(struct omap_aes_dev *dd,
dd->out_offset = 0;
dd->out_sg = req->dst;
+ dd->in_sg_len = scatterwalk_bytes_sglen(dd->in_sg, dd->total);
+ dd->out_sg_len = scatterwalk_bytes_sglen(dd->out_sg, dd->total);
+ BUG_ON(dd->in_sg_len < 0 || dd->out_sg_len < 0);
+
rctx = ablkcipher_request_ctx(req);
ctx = crypto_ablkcipher_ctx(crypto_ablkcipher_reqtfm(req));
rctx->mode &= FLAGS_MODE_MASK;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 02/14] crypto: omap-aes: Add useful debug macros
From: Joel Fernandes @ 2013-08-18 2:42 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Mark Greer, Tony Lindgren,
Santosh Shilimkar, Rajendra Nayak, Lokesh Vutla
Cc: Linux OMAP List, Linux ARM Kernel List, Linux Kernel Mailing List,
Linux Crypto Mailing List, Joel Fernandes
In-Reply-To: <1376793755-30478-1-git-send-email-joelf@ti.com>
When DEBUG is enabled, these macros can be used to print variables in integer
and hex format, and clearly display which registers, offsets and values are
being read/written , including printing the names of the offsets and their values.
Note:
This patch results in a checkpatch error that cannot be fixed.
ERROR: Macros with multiple statements should be enclosed in a do - while loop
+#define omap_aes_read(dd, offset) \
+ __raw_readl(dd->io_base + offset); \
+ pr_debug("omap_aes_read(" #offset ")\n");
Using do-while loop will break a lot of code such as:
ret = omap_aes_read(..);
On the other hand, not using a do-while loop will only result in a spurious
debug print message when DEBUG is enabled, all other issues would be caught at
compile time if any. As such, there is no code in the driver as of now that
requires a do-while loop, but there is code that will break if a do-while loop
is used in the macro so we ignore the checkpatch error in this case.
Signed-off-by: Joel Fernandes <joelf@ti.com>
---
drivers/crypto/omap-aes.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index ee15b0f..26b802b 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -13,7 +13,8 @@
*
*/
-#define pr_fmt(fmt) "%s: " fmt, __func__
+#define prn(num) pr_debug(#num "=%d\n", num)
+#define prx(num) pr_debug(#num "=%x\n", num)
#include <linux/err.h>
#include <linux/module.h>
@@ -172,16 +173,35 @@ struct omap_aes_dev {
static LIST_HEAD(dev_list);
static DEFINE_SPINLOCK(list_lock);
+#ifdef DEBUG
+/*
+ * Note: In DEBUG mode, when using conditionals, omap_aes_read _must_
+ * be surrounded by braces otherwise you may see spurious prints.
+ */
+#define omap_aes_read(dd, offset) \
+ __raw_readl(dd->io_base + offset); \
+ pr_debug("omap_aes_read(" #offset ")\n");
+#else
static inline u32 omap_aes_read(struct omap_aes_dev *dd, u32 offset)
{
return __raw_readl(dd->io_base + offset);
}
+#endif
+#ifdef DEBUG
+#define omap_aes_write(dd, offset, value) \
+ do { \
+ pr_debug("omap_aes_write(" #offset "=%x) value=%d\n", \
+ offset, value); \
+ __raw_writel(value, dd->io_base + offset); \
+ } while (0)
+#else
static inline void omap_aes_write(struct omap_aes_dev *dd, u32 offset,
u32 value)
{
__raw_writel(value, dd->io_base + offset);
}
+#endif
static inline void omap_aes_write_mask(struct omap_aes_dev *dd, u32 offset,
u32 value, u32 mask)
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 00/14] crypto: omap-aes: Improve DMA, add PIO mode and support for AM437x
From: Joel Fernandes @ 2013-08-18 2:42 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Mark Greer, Tony Lindgren,
Santosh Shilimkar, Rajendra Nayak, Lokesh Vutla
Cc: Linux OMAP List, Linux ARM Kernel List, Linux Kernel Mailing List,
Linux Crypto Mailing List
Following patch series rewrites the DMA code to be cleaner and faster. Earlier,
only a single SG was used for DMA purpose, and the SG-list passed from the
crypto layer was being copied and DMA'd one entry at a time. This turns out to
be quite inefficient and lot of code, we replace it with much simpler approach
that directly passes the SG-list from crypto to the DMA layers for cases where
possible. For all cases where such a direct passing of SG list is not possible,
we create a new SG-list and do the copying. This is still better than before, as
we create an SG list as big as needed and not just 1-element list.
We also add PIO mode support to the driver, and switch to it whenever the DMA
channel allocation is not available. This also has shown to give good performance
for small blocks as shown below.
Tests have been performed on AM335x, OMAP4 and AM437x SoCs.
Below is a sample run on AM335x SoC (beaglebone board), showing
performance improvement (20% for 8K blocks):
With DMA rewrite (key size = 128-bit)
16 byte blocks: 4318 operations in 1 seconds (69088 bytes)
64 byte blocks: 4360 operations in 1 seconds (279040 bytes)
256 byte blocks: 3609 operations in 1 seconds (923904 bytes)
1024 byte blocks: 3418 operations in 1 seconds (3500032 bytes)
8192 byte blocks: 1766 operations in 1 seconds (14467072 bytes)
Without DMA rewrite:
16 byte blocks: 4417 operations in 1 seconds (70672 bytes)
64 byte blocks: 4221 operations in 1 seconds (270144 bytes)
256 byte blocks: 3528 operations in 1 seconds (903168 bytes)
1024 byte blocks: 3281 operations in 1 seconds (3359744 bytes)
8192 byte blocks: 1460 operations in 1 seconds (11960320 bytes)
With PIO mode, good performance is observed for small blocks:
16 byte blocks: 20585 operations in 1 seconds (329360 bytes)
64 byte blocks: 8106 operations in 1 seconds (518784 bytes)
256 byte blocks: 2359 operations in 1 seconds (603904 bytes)
1024 byte blocks: 605 operations in 1 seconds (619520 bytes)
8192 byte blocks: 79 operations in 1 seconds (647168 bytes)
Future work in this direction would be to dynamically change between PIO/DMA mode
based on the block size.
Changes since last series:
* Unaligned cases for omap-aes are handled with patch:
"Add support for cases of unaligned lengths"
* Support for am437x SoC is added and tested.
* Changes following review comments on debug patch
Note:
The debug patch: "crypto: omap-aes: Add useful debug macros" will generate
a checkpatch error, which cannot be fixed. Refer to patch for error message
and reasons for why cannot be fixed, thanks.
Joel Fernandes (14):
crypto: scatterwalk: Add support for calculating number of SG
elements
crypto: omap-aes: Add useful debug macros
crypto: omap-aes: Populate number of SG elements
crypto: omap-aes: Simplify DMA usage by using direct SGs
crypto: omap-aes: Sync SG before DMA operation
crypto: omap-aes: Remove previously used intermediate buffers
crypto: omap-aes: Add IRQ info and helper macros
crypto: omap-aes: PIO mode: Add IRQ handler and walk SGs
crypto: omap-aes: PIO mode: platform data for OMAP4/AM437x and
trigger
crypto: omap-aes: Switch to PIO mode during probe
crypto: omap-aes: Add support for cases of unaligned lengths
crypto: omap-aes: Convert kzalloc to devm_kzalloc
crypto: omap-aes: Convert request_irq to devm_request_irq
crypto: omap-aes: Kconfig: Add build support for AM437x
crypto/scatterwalk.c | 22 ++
drivers/crypto/Kconfig | 2 +-
drivers/crypto/omap-aes.c | 466 +++++++++++++++++++++++-------------------
include/crypto/scatterwalk.h | 2 +
4 files changed, 284 insertions(+), 208 deletions(-)
--
1.7.9.5
^ permalink raw reply
* Re: Questions about the Crypto API
From: Herbert Xu @ 2013-08-16 6:37 UTC (permalink / raw)
To: Hsieh, Che-Min; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <A83C99F8370D4D42BEB2D2B3153A6BBC23D569CE@NASANEXD02C.na.qualcomm.com>
On Tue, Aug 13, 2013 at 07:25:50PM +0000, Hsieh, Che-Min wrote:
> > Garg: For any tfm, blkcipher or ablkcipher, they must return results
> > in the order they were given. For a blkcipher which is synchronous,
> > this is always true by definition since we return only after the
> > result has been completed. For an async ablkcipher, this means that
> > if you receive two requests on the same CPU, then the first request
> > must be served and completed before the second request's completion
> > can be initiated.
>
> Herbert, can you give further clarification:
> (*) This ordering of result is also true for others, such as aead and hashing, right?
Correct.
> Can you confirm, or correct the following statements:
> (*)To perform hashing on a long data stream, it may come in multiple requests to the driver; in a sequence of one .init request, one or more than one .update requests, and lastly one .final request. In this sequence, a request has to be complete, before next one to be issued to the driver. Those requests should always come in the same struct crypto_async_request.
> Is this correct?
No. Operations can always be interleaved, i.e., two different
requests can both start with init and then update in lock-step.
For hashes all state must be confined to the context area of
ahash_request. That is, the hardware must not maintain internal
state, or if it does, it must be prepared to refresh its state if
an ahash_request comes in that does not agree with the hardware's
current state.
Now, I understand that not all hardware makes it easy to do this,
that is why we don't require all hardware to provide the
init/update/final interface. The hardware can provide only the
digest interface (and most likely the finup interface) and then
rely on a software fall-back for the "stateless" init/update/final
operations.
Accordingly, on the user side we encourage everyone to use digest
and/or finup wherever possible so that the chances of hardware
acceleration is maximised.
> If driver needs to maintain state variables for such (init, update, final), the state variables can be maintained in the request implementation context, instead of tfm context. Right?
Right.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Questions about the Crypto API
From: Herbert Xu @ 2013-08-16 6:30 UTC (permalink / raw)
To: Marcelo Cerri
Cc: Hsieh, Che-Min, Garg Vakul-B16394, linux-crypto@vger.kernel.org
In-Reply-To: <20130812134913.GA5173@oc8526070481.ibm.com>
On Mon, Aug 12, 2013 at 10:49:13AM -0300, Marcelo Cerri wrote:
>
> So does that means that it's possible to keep data in the tfm's context
> that is the same for a single SA, such as the AES expanded key, but it's
> not possible to keep data that is specific for the current operation,
> such as an operation state that the driver might require?
Correct.
> Actually I think that probably I have misunderstood the blkcipher
> interface, so here it is another question: is each encrypt/decrypt call
> a complete operation? I mean, I'm considering that I could always chain
> a series of calls to encrypt data in separated chunks, in a similar way
> that is done for the hash interface and because that I'm assuming that I
> would have to keep state between those calls if the device requires
> that.
You could always chain blkcipher operations together, however, the
only state that can be stored is the IV.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [RFC] [PATCH] Fix for a warning - crypto/fcrypt,c
From: Jan-Simon Möller @ 2013-08-15 12:01 UTC (permalink / raw)
To: dl9pf, Herbert Xu, David S. Miller, linux-crypto, behanw,
pageexec
[-- Attachment #1: Type: text/plain, Size: 1668 bytes --]
Hi all,
please merge the attached patch.
Fix for warning:
linux/crypto/fcrypt.c:143:47: warning: signed shift result (0x598000000)
requires 36 bits to
represent, but 'int' only has 32 bits [-Wshift-overflow]
Z(0xef), Z(0x70), Z(0xcf), Z(0xc2), Z(0x2a), Z(0xb3), Z(0x61),
Z(0xad),
^~~~~~~
linux/crypto/fcrypt.c:113:29: note: expanded from macro 'Z'
#define Z(x) cpu_to_be32((x << 27 ) | (x >> 5))
^ ~~
linux/include/uapi/linux/byteorder/little_endian.h:38:53: note: expanded from
macro
'__cpu_to_be32'
#define __cpu_to_be32(x) ((__force __be32)__swab32((x)))
^
linux/include/uapi/linux/swab.h:116:21: note: expanded from macro '__swab32'
___constant_swab32(x) : \
^
linux/include/uapi/linux/swab.h:18:12: note: expanded from macro
'___constant_swab32'
(((__u32)(x) & (__u32)0x0000ff00UL) << 8) | \
^
Solution - make sure we don't exceed the 32 bit range by adding (x & ~(1U <<
27))
= & (0xF7FFFFFF)_16 or & (1111 0111 1111 1111 1111 1111 1111 1111)_2
Author: PaX Team <pageexec at freemail.hu>
ML-Post: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120507/142707.html
URL: http://llvm.linuxfoundation.org
Merge: Jan-Simon Möller <dl9pf at gmx.de>
Best,
--
Dipl.-Ing.
Jan-Simon Möller
jansimon.moeller@gmx.de
[-- Attachment #2: 0044-Fix-bitoperation-for-compilation-with-clang.patch --]
[-- Type: text/x-patch, Size: 2424 bytes --]
>From 7b1f235999aa1f1c45602826696e613b1eab315b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jan-Simon=20M=C3=B6ller?= <dl9pf@gmx.de>
Date: Wed, 14 Nov 2012 13:09:07 +0100
Subject: [PATCH 44/51] Fix bitoperation for compilation with clang
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Author: PaX Team <pageexec at freemail.hu>
ML-Post: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120507/142707.html
URL: http://llvm.linuxfoundation.org
Merge: Jan-Simon Möller <dl9pf at gmx.de>
Description:
Fix for warning:
linux/crypto/fcrypt.c:143:47: warning: signed shift result (0x598000000) requires 36 bits to
represent, but 'int' only has 32 bits [-Wshift-overflow]
Z(0xef), Z(0x70), Z(0xcf), Z(0xc2), Z(0x2a), Z(0xb3), Z(0x61), Z(0xad),
^~~~~~~
linux/crypto/fcrypt.c:113:29: note: expanded from macro 'Z'
#define Z(x) cpu_to_be32((x << 27 ) | (x >> 5))
^ ~~
linux/include/uapi/linux/byteorder/little_endian.h:38:53: note: expanded from macro
'__cpu_to_be32'
#define __cpu_to_be32(x) ((__force __be32)__swab32((x)))
^
linux/include/uapi/linux/swab.h:116:21: note: expanded from macro '__swab32'
___constant_swab32(x) : \
^
linux/include/uapi/linux/swab.h:18:12: note: expanded from macro '___constant_swab32'
(((__u32)(x) & (__u32)0x0000ff00UL) << 8) | \
^
Solution - make sure we don't exceed the 32 bit range by adding (x & ~(1U << 27))
= & (0xF7FFFFFF)_16 or & (1111 0111 1111 1111 1111 1111 1111 1111)_2
Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>
---
crypto/fcrypt.c | 2 +-
1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/crypto/fcrypt.c b/crypto/fcrypt.c
index 3b2cf56..8ad29b7 100644
--- a/crypto/fcrypt.c
+++ b/crypto/fcrypt.c
@@ -110,7 +110,7 @@ static const __be32 sbox0[256] = {
};
#undef Z
-#define Z(x) cpu_to_be32((x << 27) | (x >> 5))
+#define Z(x) cpu_to_be32(((x & ~(1U << 27)) << 27) | (x >> 5))
static const __be32 sbox1[256] = {
Z(0x77), Z(0x14), Z(0xa6), Z(0xfe), Z(0xb2), Z(0x5e), Z(0x8c), Z(0x3e),
Z(0x67), Z(0x6c), Z(0xa1), Z(0x0d), Z(0xc2), Z(0xa2), Z(0xc1), Z(0x85),
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 02/10] crypto: omap-aes: Add useful debug macros
From: Joel Fernandes @ 2013-08-15 7:27 UTC (permalink / raw)
To: Dmitry Kasatkin
Cc: Tony Lindgren, Rajendra Nayak, Mark Greer,
Linux Kernel Mailing List, Herbert Xu, Santosh Shilimkar,
Linux ARM Kernel List, Joe Perches, Linux OMAP List,
David S. Miller, Lokesh Vutla, Linux Crypto Mailing List
In-Reply-To: <520C73D6.3010904@samsung.com>
On 08/15/2013 01:23 AM, Dmitry Kasatkin wrote:
> On 15/08/13 06:12, Joel Fernandes wrote:
>> On 08/14/2013 07:47 PM, Joe Perches wrote:
>>> On Wed, 2013-08-14 at 18:40 -0500, Joel Fernandes wrote:
>>>> On 08/14/2013 06:29 PM, Joe Perches wrote:
>>>>> On Wed, 2013-08-14 at 18:12 -0500, Joel Fernandes wrote:
>>>>>> When DEBUG is enabled, these macros can be used to print variables
>>>>>> in integer and hex format, and clearly display which registers,
>>>>>> offsets and values are being read/written , including printing the
>>>>>> names of the offsets and their values.
>>>>> []
>>>>>> diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
>>>>> []
>>>>>> @@ -15,6 +15,14 @@
>>>>>>
>>>>>> #define pr_fmt(fmt) "%s: " fmt, __func__
>>>>>>
>>>>>> +#ifdef DEBUG
>>>>>> +#define prn(num) printk(#num "=%d\n", num)
>>>>>> +#define prx(num) printk(#num "=%x\n", num)
>>>>> pr_debug?
>>>> Sure, can change that.
>>>>
>>>>>> +#else
>>>>>> +#define prn(num) do { } while (0)
>>>>>> +#define prx(num) do { } while (0)
>>>>>> +#endif
>>>>> []
>>>>>> @@ -172,13 +180,35 @@ struct omap_aes_dev {
>>>>>> static LIST_HEAD(dev_list);
>>>>>> static DEFINE_SPINLOCK(list_lock);
>>>>>>
>>>>>> +#ifdef DEBUG
>>>>>> +#define omap_aes_read(dd, offset) \
>>>>>> + do { \
>>>>>> + omap_aes_read_1(dd, offset); \
>>>>>> + pr_debug("omap_aes_read(" #offset ")\n"); \
>>>>>> + } while (0)
>>>>>> +
>>>>>> +static inline u32 omap_aes_read_1(struct omap_aes_dev *dd, u32 offset)
>>>>>> +#else
>>>>>> static inline u32 omap_aes_read(struct omap_aes_dev *dd, u32 offset)
>>>>>> +#endif
>>>>>> {
>>>>>> return __raw_readl(dd->io_base + offset);
>>>>>> }
>>>>>>
>>>>>> +#ifdef DEBUG
>>>>>> +#define omap_aes_write(dd, offset, value) \
>>>>>> + do { \
>>>>>> + pr_debug("omap_aes_write(" #offset "=%x) value=%d\n", \
>>>>>> + offset, value); \
>>>>>> + omap_aes_write_1(dd, offset, value); \
>>>>>> + } while (0)
>>>>>> +
>>>>>> +static inline void omap_aes_write_1(struct omap_aes_dev *dd, u32 offset,
>>>>>> + u32 value)
>>>>>> +#else
>>>>>> static inline void omap_aes_write(struct omap_aes_dev *dd, u32 offset,
>>>>>> u32 value)
>>>>>> +#endif
>>>>>> {
>>>>>> __raw_writel(value, dd->io_base + offset);
>>>>>> }
>>>>> Umm, yuck?
>>>>>
>>>>> Is there any real value in read_1 and write_1?
>>>> Can you be more descriptive? There is a lot of value in them for debug
>>>> to show clearly sequence of read/writes. Moreover, they are no-op'd when
>>>> DEBUG is disabled.
>>> pr_debug is no-op'd when DEBUG is not #defined.
>>> so just use a single
>>>
>>> omap_aes_write(...)
>>> {
>>> pr_debug(...)
>>> __raw_writel(...);
>>> }
>> Actually this doesn't work, as the pr_debug cannot print the name of the
>> offset as my original patch set does using "#offset".
>>
>> There are many places where named offsets are used to pass to
>> read/write, and this macro helps to visually see which offset is being
>> written to by name.
>>
>> So the original patch would stand in its current form except for a small
>> rewrite of the write debug part of it as follows to be cleaner getting
>> rid of the _1. For the read , we still need it as we need to return the
>> value from a function which cannot be done in a macro.
>>
>> So the new patch would look something like this:
>>
>> #ifdef DEBUG
>> #define omap_aes_read(dd, offset) \
>> omap_aes_read_1(dd, offset); \
>> pr_debug("omap_aes_read(" #offset ")\n");
>> static inline u32 omap_aes_read_1(struct omap_aes_dev *dd, u32 offset)
>> #else
>> static inline u32 omap_aes_read(struct omap_aes_dev *dd, u32 offset)
>> #endif
>> {
>> return __raw_readl(dd->io_base + offset);
>> }
>
> Bellow version "write" looks much more readable - never re-define
> function signature by macro.
> Above should be similar as well...
Yes, I'll write the read in the final version of this patch like the
write. Its certainly cleaner.
-Joel
>> #ifdef DEBUG
>> #define omap_aes_write(dd, offset, value) \
>> do { \
>> pr_debug("omap_aes_write(" #offset "=%x) value=%d\n", \
>> offset, value); \
>> __raw_writel(value, dd->io_base + offset); \
>> } while (0)
>> #else
>> static inline void omap_aes_write(struct omap_aes_dev *dd, u32 offset,
>> u32 value)
>> {
>> __raw_writel(value, dd->io_base + offset);
>> }
>> #endif
>
>>
>>
>> Thanks,
>>
>> -Joel
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply
* Re: [PATCH 00/10] crypto: omap-aes: DMA and PIO mode improvements
From: Joel Fernandes @ 2013-08-15 7:02 UTC (permalink / raw)
To: Dmitry Kasatkin
Cc: Herbert Xu, David S. Miller, Mark Greer, Tony Lindgren,
Santosh Shilimkar, Rajendra Nayak, Lokesh Vutla, Linux OMAP List,
Linux ARM Kernel List, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <520C6E0A.8030505@samsung.com>
On 08/15/2013 12:58 AM, Dmitry Kasatkin wrote:
> On 15/08/13 02:30, Joel Fernandes wrote:
>> On 08/14/2013 06:12 PM, Joel Fernandes wrote:
>>> This patch series is a rewrite of the DMA portion of omap-aes driver
>>> and also adds support for PIO mode. Both these modes, give better
>>> performance than before.
>>>
>>> Earlier, only a single SG was used for DMA purpose, and the SG-list
>>> passed from the crypto layer was being copied and DMA'd one entry at
>>> a time. This turns out to be quite inefficient, so we replace it with
>>> much simpler code that directly passes the SG-list from crypto to the
>>> DMA layer.
>>>
>>> We also add PIO mode support to the driver, and switch to PIO mode
>>> whenever the DMA channel allocation is not available. This is only for
>>> OMAP4 platform will work on any platform on which IRQ information is
>>> populated.
>>>
>>> Tests performed on am33xx and omap4 SoCs , notice the 50% perf improvement
>> Just correcting, this is more like 35% not 50% when using DMA.
>
> Hmm :)
>
> 1766/1460 = ~20%
Yes sorry, I messed the cover letter up. If I resend the series again,
I'll update this number.
On OMAP4 though, I saw 2800 ops/sec vs 1800 ops/sec which is around 50%
so it depends on SoC and DMA controller. OMAP4 uses SDMA while AM335x
uses EDMA.
Also with very large blocks, this improvement will be much higher as we
will not be doing all the intermediate copy but I haven't tested with
such large blocks.
Thanks,
-Joel
^ permalink raw reply
* Re: [PATCH 02/10] crypto: omap-aes: Add useful debug macros
From: Dmitry Kasatkin @ 2013-08-15 6:23 UTC (permalink / raw)
To: joelf
Cc: Joe Perches, Herbert Xu, David S. Miller, Mark Greer,
Tony Lindgren, Santosh Shilimkar, Rajendra Nayak, Lokesh Vutla,
Linux OMAP List, Linux ARM Kernel List, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <520C472D.8000904@ti.com>
On 15/08/13 06:12, Joel Fernandes wrote:
> On 08/14/2013 07:47 PM, Joe Perches wrote:
>> On Wed, 2013-08-14 at 18:40 -0500, Joel Fernandes wrote:
>>> On 08/14/2013 06:29 PM, Joe Perches wrote:
>>>> On Wed, 2013-08-14 at 18:12 -0500, Joel Fernandes wrote:
>>>>> When DEBUG is enabled, these macros can be used to print variables
>>>>> in integer and hex format, and clearly display which registers,
>>>>> offsets and values are being read/written , including printing the
>>>>> names of the offsets and their values.
>>>> []
>>>>> diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
>>>> []
>>>>> @@ -15,6 +15,14 @@
>>>>>
>>>>> #define pr_fmt(fmt) "%s: " fmt, __func__
>>>>>
>>>>> +#ifdef DEBUG
>>>>> +#define prn(num) printk(#num "=%d\n", num)
>>>>> +#define prx(num) printk(#num "=%x\n", num)
>>>> pr_debug?
>>> Sure, can change that.
>>>
>>>>> +#else
>>>>> +#define prn(num) do { } while (0)
>>>>> +#define prx(num) do { } while (0)
>>>>> +#endif
>>>> []
>>>>> @@ -172,13 +180,35 @@ struct omap_aes_dev {
>>>>> static LIST_HEAD(dev_list);
>>>>> static DEFINE_SPINLOCK(list_lock);
>>>>>
>>>>> +#ifdef DEBUG
>>>>> +#define omap_aes_read(dd, offset) \
>>>>> + do { \
>>>>> + omap_aes_read_1(dd, offset); \
>>>>> + pr_debug("omap_aes_read(" #offset ")\n"); \
>>>>> + } while (0)
>>>>> +
>>>>> +static inline u32 omap_aes_read_1(struct omap_aes_dev *dd, u32 offset)
>>>>> +#else
>>>>> static inline u32 omap_aes_read(struct omap_aes_dev *dd, u32 offset)
>>>>> +#endif
>>>>> {
>>>>> return __raw_readl(dd->io_base + offset);
>>>>> }
>>>>>
>>>>> +#ifdef DEBUG
>>>>> +#define omap_aes_write(dd, offset, value) \
>>>>> + do { \
>>>>> + pr_debug("omap_aes_write(" #offset "=%x) value=%d\n", \
>>>>> + offset, value); \
>>>>> + omap_aes_write_1(dd, offset, value); \
>>>>> + } while (0)
>>>>> +
>>>>> +static inline void omap_aes_write_1(struct omap_aes_dev *dd, u32 offset,
>>>>> + u32 value)
>>>>> +#else
>>>>> static inline void omap_aes_write(struct omap_aes_dev *dd, u32 offset,
>>>>> u32 value)
>>>>> +#endif
>>>>> {
>>>>> __raw_writel(value, dd->io_base + offset);
>>>>> }
>>>> Umm, yuck?
>>>>
>>>> Is there any real value in read_1 and write_1?
>>> Can you be more descriptive? There is a lot of value in them for debug
>>> to show clearly sequence of read/writes. Moreover, they are no-op'd when
>>> DEBUG is disabled.
>> pr_debug is no-op'd when DEBUG is not #defined.
>> so just use a single
>>
>> omap_aes_write(...)
>> {
>> pr_debug(...)
>> __raw_writel(...);
>> }
> Actually this doesn't work, as the pr_debug cannot print the name of the
> offset as my original patch set does using "#offset".
>
> There are many places where named offsets are used to pass to
> read/write, and this macro helps to visually see which offset is being
> written to by name.
>
> So the original patch would stand in its current form except for a small
> rewrite of the write debug part of it as follows to be cleaner getting
> rid of the _1. For the read , we still need it as we need to return the
> value from a function which cannot be done in a macro.
>
> So the new patch would look something like this:
>
> #ifdef DEBUG
> #define omap_aes_read(dd, offset) \
> omap_aes_read_1(dd, offset); \
> pr_debug("omap_aes_read(" #offset ")\n");
> static inline u32 omap_aes_read_1(struct omap_aes_dev *dd, u32 offset)
> #else
> static inline u32 omap_aes_read(struct omap_aes_dev *dd, u32 offset)
> #endif
> {
> return __raw_readl(dd->io_base + offset);
> }
Bellow version "write" looks much more readable - never re-define
function signature by macro.
Above should be similar as well...
> #ifdef DEBUG
> #define omap_aes_write(dd, offset, value) \
> do { \
> pr_debug("omap_aes_write(" #offset "=%x) value=%d\n", \
> offset, value); \
> __raw_writel(value, dd->io_base + offset); \
> } while (0)
> #else
> static inline void omap_aes_write(struct omap_aes_dev *dd, u32 offset,
> u32 value)
> {
> __raw_writel(value, dd->io_base + offset);
> }
> #endif
>
>
> Thanks,
>
> -Joel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 00/10] crypto: omap-aes: DMA and PIO mode improvements
From: Dmitry Kasatkin @ 2013-08-15 5:58 UTC (permalink / raw)
To: joelf
Cc: Herbert Xu, David S. Miller, Mark Greer, Tony Lindgren,
Santosh Shilimkar, Rajendra Nayak, Lokesh Vutla, Linux OMAP List,
Linux ARM Kernel List, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <520C1327.8090607@ti.com>
On 15/08/13 02:30, Joel Fernandes wrote:
> On 08/14/2013 06:12 PM, Joel Fernandes wrote:
>> This patch series is a rewrite of the DMA portion of omap-aes driver
>> and also adds support for PIO mode. Both these modes, give better
>> performance than before.
>>
>> Earlier, only a single SG was used for DMA purpose, and the SG-list
>> passed from the crypto layer was being copied and DMA'd one entry at
>> a time. This turns out to be quite inefficient, so we replace it with
>> much simpler code that directly passes the SG-list from crypto to the
>> DMA layer.
>>
>> We also add PIO mode support to the driver, and switch to PIO mode
>> whenever the DMA channel allocation is not available. This is only for
>> OMAP4 platform will work on any platform on which IRQ information is
>> populated.
>>
>> Tests performed on am33xx and omap4 SoCs , notice the 50% perf improvement
> Just correcting, this is more like 35% not 50% when using DMA.
Hmm :)
1766/1460 = ~20%
>
> Thanks,
>
> -Joel
>
>
>
>
>
>> for large 8K blocks:
>>
>> Sample run on am33xx (beaglebone):
>> With DMA rewrite:
>> [ 26.410052] test 0 (128 bit key, 16 byte blocks): 4318 operations in 1 seconds (69088 bytes)
>> [ 27.414314] test 1 (128 bit key, 64 byte blocks): 4360 operations in 1 seconds (279040 bytes)
>> [ 28.414406] test 2 (128 bit key, 256 byte blocks): 3609 operations in 1 seconds (923904 bytes)
>> [ 29.414410] test 3 (128 bit key, 1024 byte blocks): 3418 operations in 1 seconds (3500032 bytes)
>> [ 30.414510] test 4 (128 bit key, 8192 byte blocks): 1766 operations in 1 seconds (14467072 bytes)
>>
>> Without DMA rewrite:
>> [ 31.920519] test 0 (128 bit key, 16 byte blocks): 4417 operations in 1 seconds (70672 bytes)
>> [ 32.925997] test 1 (128 bit key, 64 byte blocks): 4221 operations in 1 seconds (270144 bytes)
>> [ 33.926194] test 2 (128 bit key, 256 byte blocks): 3528 operations in 1 seconds (903168 bytes)
>> [ 34.926225] test 3 (128 bit key, 1024 byte blocks): 3281 operations in 1 seconds (3359744 bytes)
>> [ 35.926385] test 4 (128 bit key, 8192 byte blocks): 1460 operations in 1 seconds (11960320 bytes)
>>
>> With PIO mode, note the tremndous boost in performance for small blocks there:
>> [ 27.294905] test 0 (128 bit key, 16 byte blocks): 20585 operations in 1 seconds (329360 bytes)
>> [ 28.302282] test 1 (128 bit key, 64 byte blocks): 8106 operations in 1 seconds (518784 bytes)
>> [ 29.302374] test 2 (128 bit key, 256 byte blocks): 2359 operations in 1 seconds (603904 bytes)
>> [ 30.302575] test 3 (128 bit key, 1024 byte blocks): 605 operations in 1 seconds (619520 bytes)
>> [ 31.303781] test 4 (128 bit key, 8192 byte blocks): 79 operations in 1 seconds (647168 bytes)
>>
>> Future work in this direction would be to dynamically change between
>> PIO/DMA mode based on the block size.
>>
>> Joel Fernandes (10):
>> crypto: scatterwalk: Add support for calculating number of SG
>> elements
>> crypto: omap-aes: Add useful debug macros
>> crypto: omap-aes: Populate number of SG elements
>> crypto: omap-aes: Simplify DMA usage by using direct SGs
>> crypto: omap-aes: Sync SG before DMA operation
>> crypto: omap-aes: Remove previously used intermediate buffers
>> crypto: omap-aes: Add IRQ info and helper macros
>> crypto: omap-aes: PIO mode: Add IRQ handler and walk SGs
>> crypto: omap-aes: PIO mode: platform data for OMAP4 and trigger it
>> crypto: omap-aes: Switch to PIO mode in probe function
>>
>> crypto/scatterwalk.c | 22 +++
>> drivers/crypto/omap-aes.c | 400 ++++++++++++++++++++----------------------
>> include/crypto/scatterwalk.h | 2 +
>> 3 files changed, 217 insertions(+), 207 deletions(-)
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 02/10] crypto: omap-aes: Add useful debug macros
From: Joel Fernandes @ 2013-08-15 3:12 UTC (permalink / raw)
To: Joe Perches
Cc: Tony Lindgren, Rajendra Nayak, Mark Greer,
Linux Kernel Mailing List, Herbert Xu, Santosh Shilimkar,
Linux ARM Kernel List, Linux OMAP List, David S. Miller,
Lokesh Vutla, Linux Crypto Mailing List
In-Reply-To: <1376527636.1949.120.camel@joe-AO722>
On 08/14/2013 07:47 PM, Joe Perches wrote:
> On Wed, 2013-08-14 at 18:40 -0500, Joel Fernandes wrote:
>> On 08/14/2013 06:29 PM, Joe Perches wrote:
>>> On Wed, 2013-08-14 at 18:12 -0500, Joel Fernandes wrote:
>>>> When DEBUG is enabled, these macros can be used to print variables
>>>> in integer and hex format, and clearly display which registers,
>>>> offsets and values are being read/written , including printing the
>>>> names of the offsets and their values.
>>> []
>>>> diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
>>> []
>>>> @@ -15,6 +15,14 @@
>>>>
>>>> #define pr_fmt(fmt) "%s: " fmt, __func__
>>>>
>>>> +#ifdef DEBUG
>>>> +#define prn(num) printk(#num "=%d\n", num)
>>>> +#define prx(num) printk(#num "=%x\n", num)
>>>
>>> pr_debug?
>>
>> Sure, can change that.
>>
>>>> +#else
>>>> +#define prn(num) do { } while (0)
>>>> +#define prx(num) do { } while (0)
>>>> +#endif
>>> []
>>>> @@ -172,13 +180,35 @@ struct omap_aes_dev {
>>>> static LIST_HEAD(dev_list);
>>>> static DEFINE_SPINLOCK(list_lock);
>>>>
>>>> +#ifdef DEBUG
>>>> +#define omap_aes_read(dd, offset) \
>>>> + do { \
>>>> + omap_aes_read_1(dd, offset); \
>>>> + pr_debug("omap_aes_read(" #offset ")\n"); \
>>>> + } while (0)
>>>> +
>>>> +static inline u32 omap_aes_read_1(struct omap_aes_dev *dd, u32 offset)
>>>> +#else
>>>> static inline u32 omap_aes_read(struct omap_aes_dev *dd, u32 offset)
>>>> +#endif
>>>> {
>>>> return __raw_readl(dd->io_base + offset);
>>>> }
>>>>
>>>> +#ifdef DEBUG
>>>> +#define omap_aes_write(dd, offset, value) \
>>>> + do { \
>>>> + pr_debug("omap_aes_write(" #offset "=%x) value=%d\n", \
>>>> + offset, value); \
>>>> + omap_aes_write_1(dd, offset, value); \
>>>> + } while (0)
>>>> +
>>>> +static inline void omap_aes_write_1(struct omap_aes_dev *dd, u32 offset,
>>>> + u32 value)
>>>> +#else
>>>> static inline void omap_aes_write(struct omap_aes_dev *dd, u32 offset,
>>>> u32 value)
>>>> +#endif
>>>> {
>>>> __raw_writel(value, dd->io_base + offset);
>>>> }
>>>
>>> Umm, yuck?
>>>
>>> Is there any real value in read_1 and write_1?
>>
>> Can you be more descriptive? There is a lot of value in them for debug
>> to show clearly sequence of read/writes. Moreover, they are no-op'd when
>> DEBUG is disabled.
>
> pr_debug is no-op'd when DEBUG is not #defined.
> so just use a single
>
> omap_aes_write(...)
> {
> pr_debug(...)
> __raw_writel(...);
> }
Actually this doesn't work, as the pr_debug cannot print the name of the
offset as my original patch set does using "#offset".
There are many places where named offsets are used to pass to
read/write, and this macro helps to visually see which offset is being
written to by name.
So the original patch would stand in its current form except for a small
rewrite of the write debug part of it as follows to be cleaner getting
rid of the _1. For the read , we still need it as we need to return the
value from a function which cannot be done in a macro.
So the new patch would look something like this:
#ifdef DEBUG
#define omap_aes_read(dd, offset) \
omap_aes_read_1(dd, offset); \
pr_debug("omap_aes_read(" #offset ")\n");
static inline u32 omap_aes_read_1(struct omap_aes_dev *dd, u32 offset)
#else
static inline u32 omap_aes_read(struct omap_aes_dev *dd, u32 offset)
#endif
{
return __raw_readl(dd->io_base + offset);
}
#ifdef DEBUG
#define omap_aes_write(dd, offset, value) \
do { \
pr_debug("omap_aes_write(" #offset "=%x) value=%d\n", \
offset, value); \
__raw_writel(value, dd->io_base + offset); \
} while (0)
#else
static inline void omap_aes_write(struct omap_aes_dev *dd, u32 offset,
u32 value)
{
__raw_writel(value, dd->io_base + offset);
}
#endif
Thanks,
-Joel
^ permalink raw reply
* Re: [PATCH 02/10] crypto: omap-aes: Add useful debug macros
From: Joe Perches @ 2013-08-15 0:47 UTC (permalink / raw)
To: Joel Fernandes
Cc: Herbert Xu, David S. Miller, Mark Greer, Tony Lindgren,
Santosh Shilimkar, Rajendra Nayak, Lokesh Vutla, Linux OMAP List,
Linux ARM Kernel List, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <520C156D.2090003@ti.com>
On Wed, 2013-08-14 at 18:40 -0500, Joel Fernandes wrote:
> On 08/14/2013 06:29 PM, Joe Perches wrote:
> > On Wed, 2013-08-14 at 18:12 -0500, Joel Fernandes wrote:
> >> When DEBUG is enabled, these macros can be used to print variables
> >> in integer and hex format, and clearly display which registers,
> >> offsets and values are being read/written , including printing the
> >> names of the offsets and their values.
> > []
> >> diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
> > []
> >> @@ -15,6 +15,14 @@
> >>
> >> #define pr_fmt(fmt) "%s: " fmt, __func__
> >>
> >> +#ifdef DEBUG
> >> +#define prn(num) printk(#num "=%d\n", num)
> >> +#define prx(num) printk(#num "=%x\n", num)
> >
> > pr_debug?
>
> Sure, can change that.
>
> >> +#else
> >> +#define prn(num) do { } while (0)
> >> +#define prx(num) do { } while (0)
> >> +#endif
> > []
> >> @@ -172,13 +180,35 @@ struct omap_aes_dev {
> >> static LIST_HEAD(dev_list);
> >> static DEFINE_SPINLOCK(list_lock);
> >>
> >> +#ifdef DEBUG
> >> +#define omap_aes_read(dd, offset) \
> >> + do { \
> >> + omap_aes_read_1(dd, offset); \
> >> + pr_debug("omap_aes_read(" #offset ")\n"); \
> >> + } while (0)
> >> +
> >> +static inline u32 omap_aes_read_1(struct omap_aes_dev *dd, u32 offset)
> >> +#else
> >> static inline u32 omap_aes_read(struct omap_aes_dev *dd, u32 offset)
> >> +#endif
> >> {
> >> return __raw_readl(dd->io_base + offset);
> >> }
> >>
> >> +#ifdef DEBUG
> >> +#define omap_aes_write(dd, offset, value) \
> >> + do { \
> >> + pr_debug("omap_aes_write(" #offset "=%x) value=%d\n", \
> >> + offset, value); \
> >> + omap_aes_write_1(dd, offset, value); \
> >> + } while (0)
> >> +
> >> +static inline void omap_aes_write_1(struct omap_aes_dev *dd, u32 offset,
> >> + u32 value)
> >> +#else
> >> static inline void omap_aes_write(struct omap_aes_dev *dd, u32 offset,
> >> u32 value)
> >> +#endif
> >> {
> >> __raw_writel(value, dd->io_base + offset);
> >> }
> >
> > Umm, yuck?
> >
> > Is there any real value in read_1 and write_1?
>
> Can you be more descriptive? There is a lot of value in them for debug
> to show clearly sequence of read/writes. Moreover, they are no-op'd when
> DEBUG is disabled.
pr_debug is no-op'd when DEBUG is not #defined.
so just use a single
omap_aes_write(...)
{
pr_debug(...)
__raw_writel(...);
}
^ permalink raw reply
* Re: [PATCH 02/10] crypto: omap-aes: Add useful debug macros
From: Joel Fernandes @ 2013-08-14 23:40 UTC (permalink / raw)
To: Joe Perches
Cc: Herbert Xu, David S. Miller, Mark Greer, Tony Lindgren,
Santosh Shilimkar, Rajendra Nayak, Lokesh Vutla, Linux OMAP List,
Linux ARM Kernel List, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <1376522998.1949.118.camel@joe-AO722>
On 08/14/2013 06:29 PM, Joe Perches wrote:
> On Wed, 2013-08-14 at 18:12 -0500, Joel Fernandes wrote:
>> When DEBUG is enabled, these macros can be used to print variables
>> in integer and hex format, and clearly display which registers,
>> offsets and values are being read/written , including printing the
>> names of the offsets and their values.
> []
>> diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
> []
>> @@ -15,6 +15,14 @@
>>
>> #define pr_fmt(fmt) "%s: " fmt, __func__
>>
>> +#ifdef DEBUG
>> +#define prn(num) printk(#num "=%d\n", num)
>> +#define prx(num) printk(#num "=%x\n", num)
>
> pr_debug?
Sure, can change that.
>> +#else
>> +#define prn(num) do { } while (0)
>> +#define prx(num) do { } while (0)
>> +#endif
> []
>> @@ -172,13 +180,35 @@ struct omap_aes_dev {
>> static LIST_HEAD(dev_list);
>> static DEFINE_SPINLOCK(list_lock);
>>
>> +#ifdef DEBUG
>> +#define omap_aes_read(dd, offset) \
>> + do { \
>> + omap_aes_read_1(dd, offset); \
>> + pr_debug("omap_aes_read(" #offset ")\n"); \
>> + } while (0)
>> +
>> +static inline u32 omap_aes_read_1(struct omap_aes_dev *dd, u32 offset)
>> +#else
>> static inline u32 omap_aes_read(struct omap_aes_dev *dd, u32 offset)
>> +#endif
>> {
>> return __raw_readl(dd->io_base + offset);
>> }
>>
>> +#ifdef DEBUG
>> +#define omap_aes_write(dd, offset, value) \
>> + do { \
>> + pr_debug("omap_aes_write(" #offset "=%x) value=%d\n", \
>> + offset, value); \
>> + omap_aes_write_1(dd, offset, value); \
>> + } while (0)
>> +
>> +static inline void omap_aes_write_1(struct omap_aes_dev *dd, u32 offset,
>> + u32 value)
>> +#else
>> static inline void omap_aes_write(struct omap_aes_dev *dd, u32 offset,
>> u32 value)
>> +#endif
>> {
>> __raw_writel(value, dd->io_base + offset);
>> }
>
> Umm, yuck?
>
> Is there any real value in read_1 and write_1?
Can you be more descriptive? There is a lot of value in them for debug
to show clearly sequence of read/writes. Moreover, they are no-op'd when
DEBUG is disabled.
Other than the obvious use, I guess it could be rewritten to be bit
cleaner. I can do that.
-Joel
^ permalink raw reply
* Re: [PATCH 00/10] crypto: omap-aes: DMA and PIO mode improvements
From: Joel Fernandes @ 2013-08-14 23:30 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Mark Greer, Tony Lindgren,
Santosh Shilimkar, Rajendra Nayak, Lokesh Vutla
Cc: Linux OMAP List, Linux ARM Kernel List, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <1376521969-16807-1-git-send-email-joelf@ti.com>
On 08/14/2013 06:12 PM, Joel Fernandes wrote:
> This patch series is a rewrite of the DMA portion of omap-aes driver
> and also adds support for PIO mode. Both these modes, give better
> performance than before.
>
> Earlier, only a single SG was used for DMA purpose, and the SG-list
> passed from the crypto layer was being copied and DMA'd one entry at
> a time. This turns out to be quite inefficient, so we replace it with
> much simpler code that directly passes the SG-list from crypto to the
> DMA layer.
>
> We also add PIO mode support to the driver, and switch to PIO mode
> whenever the DMA channel allocation is not available. This is only for
> OMAP4 platform will work on any platform on which IRQ information is
> populated.
>
> Tests performed on am33xx and omap4 SoCs , notice the 50% perf improvement
Just correcting, this is more like 35% not 50% when using DMA.
Thanks,
-Joel
> for large 8K blocks:
>
> Sample run on am33xx (beaglebone):
> With DMA rewrite:
> [ 26.410052] test 0 (128 bit key, 16 byte blocks): 4318 operations in 1 seconds (69088 bytes)
> [ 27.414314] test 1 (128 bit key, 64 byte blocks): 4360 operations in 1 seconds (279040 bytes)
> [ 28.414406] test 2 (128 bit key, 256 byte blocks): 3609 operations in 1 seconds (923904 bytes)
> [ 29.414410] test 3 (128 bit key, 1024 byte blocks): 3418 operations in 1 seconds (3500032 bytes)
> [ 30.414510] test 4 (128 bit key, 8192 byte blocks): 1766 operations in 1 seconds (14467072 bytes)
>
> Without DMA rewrite:
> [ 31.920519] test 0 (128 bit key, 16 byte blocks): 4417 operations in 1 seconds (70672 bytes)
> [ 32.925997] test 1 (128 bit key, 64 byte blocks): 4221 operations in 1 seconds (270144 bytes)
> [ 33.926194] test 2 (128 bit key, 256 byte blocks): 3528 operations in 1 seconds (903168 bytes)
> [ 34.926225] test 3 (128 bit key, 1024 byte blocks): 3281 operations in 1 seconds (3359744 bytes)
> [ 35.926385] test 4 (128 bit key, 8192 byte blocks): 1460 operations in 1 seconds (11960320 bytes)
>
> With PIO mode, note the tremndous boost in performance for small blocks there:
> [ 27.294905] test 0 (128 bit key, 16 byte blocks): 20585 operations in 1 seconds (329360 bytes)
> [ 28.302282] test 1 (128 bit key, 64 byte blocks): 8106 operations in 1 seconds (518784 bytes)
> [ 29.302374] test 2 (128 bit key, 256 byte blocks): 2359 operations in 1 seconds (603904 bytes)
> [ 30.302575] test 3 (128 bit key, 1024 byte blocks): 605 operations in 1 seconds (619520 bytes)
> [ 31.303781] test 4 (128 bit key, 8192 byte blocks): 79 operations in 1 seconds (647168 bytes)
>
> Future work in this direction would be to dynamically change between
> PIO/DMA mode based on the block size.
>
> Joel Fernandes (10):
> crypto: scatterwalk: Add support for calculating number of SG
> elements
> crypto: omap-aes: Add useful debug macros
> crypto: omap-aes: Populate number of SG elements
> crypto: omap-aes: Simplify DMA usage by using direct SGs
> crypto: omap-aes: Sync SG before DMA operation
> crypto: omap-aes: Remove previously used intermediate buffers
> crypto: omap-aes: Add IRQ info and helper macros
> crypto: omap-aes: PIO mode: Add IRQ handler and walk SGs
> crypto: omap-aes: PIO mode: platform data for OMAP4 and trigger it
> crypto: omap-aes: Switch to PIO mode in probe function
>
> crypto/scatterwalk.c | 22 +++
> drivers/crypto/omap-aes.c | 400 ++++++++++++++++++++----------------------
> include/crypto/scatterwalk.h | 2 +
> 3 files changed, 217 insertions(+), 207 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 02/10] crypto: omap-aes: Add useful debug macros
From: Joe Perches @ 2013-08-14 23:29 UTC (permalink / raw)
To: Joel Fernandes
Cc: Herbert Xu, David S. Miller, Mark Greer, Tony Lindgren,
Santosh Shilimkar, Rajendra Nayak, Lokesh Vutla, Linux OMAP List,
Linux ARM Kernel List, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <1376521969-16807-3-git-send-email-joelf@ti.com>
On Wed, 2013-08-14 at 18:12 -0500, Joel Fernandes wrote:
> When DEBUG is enabled, these macros can be used to print variables
> in integer and hex format, and clearly display which registers,
> offsets and values are being read/written , including printing the
> names of the offsets and their values.
[]
> diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
[]
> @@ -15,6 +15,14 @@
>
> #define pr_fmt(fmt) "%s: " fmt, __func__
>
> +#ifdef DEBUG
> +#define prn(num) printk(#num "=%d\n", num)
> +#define prx(num) printk(#num "=%x\n", num)
pr_debug?
> +#else
> +#define prn(num) do { } while (0)
> +#define prx(num) do { } while (0)
> +#endif
[]
> @@ -172,13 +180,35 @@ struct omap_aes_dev {
> static LIST_HEAD(dev_list);
> static DEFINE_SPINLOCK(list_lock);
>
> +#ifdef DEBUG
> +#define omap_aes_read(dd, offset) \
> + do { \
> + omap_aes_read_1(dd, offset); \
> + pr_debug("omap_aes_read(" #offset ")\n"); \
> + } while (0)
> +
> +static inline u32 omap_aes_read_1(struct omap_aes_dev *dd, u32 offset)
> +#else
> static inline u32 omap_aes_read(struct omap_aes_dev *dd, u32 offset)
> +#endif
> {
> return __raw_readl(dd->io_base + offset);
> }
>
> +#ifdef DEBUG
> +#define omap_aes_write(dd, offset, value) \
> + do { \
> + pr_debug("omap_aes_write(" #offset "=%x) value=%d\n", \
> + offset, value); \
> + omap_aes_write_1(dd, offset, value); \
> + } while (0)
> +
> +static inline void omap_aes_write_1(struct omap_aes_dev *dd, u32 offset,
> + u32 value)
> +#else
> static inline void omap_aes_write(struct omap_aes_dev *dd, u32 offset,
> u32 value)
> +#endif
> {
> __raw_writel(value, dd->io_base + offset);
> }
Umm, yuck?
Is there any real value in read_1 and write_1?
^ permalink raw reply
* [PATCH 00/10] crypto: omap-aes: DMA and PIO mode improvements
From: Joel Fernandes @ 2013-08-14 23:12 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Mark Greer, Tony Lindgren,
Santosh Shilimkar, Rajendra Nayak, Lokesh Vutla
Cc: Linux OMAP List, Linux ARM Kernel List, Linux Kernel Mailing List,
Linux Crypto Mailing List
This patch series is a rewrite of the DMA portion of omap-aes driver
and also adds support for PIO mode. Both these modes, give better
performance than before.
Earlier, only a single SG was used for DMA purpose, and the SG-list
passed from the crypto layer was being copied and DMA'd one entry at
a time. This turns out to be quite inefficient, so we replace it with
much simpler code that directly passes the SG-list from crypto to the
DMA layer.
We also add PIO mode support to the driver, and switch to PIO mode
whenever the DMA channel allocation is not available. This is only for
OMAP4 platform will work on any platform on which IRQ information is
populated.
Tests performed on am33xx and omap4 SoCs , notice the 50% perf improvement
for large 8K blocks:
Sample run on am33xx (beaglebone):
With DMA rewrite:
[ 26.410052] test 0 (128 bit key, 16 byte blocks): 4318 operations in 1 seconds (69088 bytes)
[ 27.414314] test 1 (128 bit key, 64 byte blocks): 4360 operations in 1 seconds (279040 bytes)
[ 28.414406] test 2 (128 bit key, 256 byte blocks): 3609 operations in 1 seconds (923904 bytes)
[ 29.414410] test 3 (128 bit key, 1024 byte blocks): 3418 operations in 1 seconds (3500032 bytes)
[ 30.414510] test 4 (128 bit key, 8192 byte blocks): 1766 operations in 1 seconds (14467072 bytes)
Without DMA rewrite:
[ 31.920519] test 0 (128 bit key, 16 byte blocks): 4417 operations in 1 seconds (70672 bytes)
[ 32.925997] test 1 (128 bit key, 64 byte blocks): 4221 operations in 1 seconds (270144 bytes)
[ 33.926194] test 2 (128 bit key, 256 byte blocks): 3528 operations in 1 seconds (903168 bytes)
[ 34.926225] test 3 (128 bit key, 1024 byte blocks): 3281 operations in 1 seconds (3359744 bytes)
[ 35.926385] test 4 (128 bit key, 8192 byte blocks): 1460 operations in 1 seconds (11960320 bytes)
With PIO mode, note the tremndous boost in performance for small blocks there:
[ 27.294905] test 0 (128 bit key, 16 byte blocks): 20585 operations in 1 seconds (329360 bytes)
[ 28.302282] test 1 (128 bit key, 64 byte blocks): 8106 operations in 1 seconds (518784 bytes)
[ 29.302374] test 2 (128 bit key, 256 byte blocks): 2359 operations in 1 seconds (603904 bytes)
[ 30.302575] test 3 (128 bit key, 1024 byte blocks): 605 operations in 1 seconds (619520 bytes)
[ 31.303781] test 4 (128 bit key, 8192 byte blocks): 79 operations in 1 seconds (647168 bytes)
Future work in this direction would be to dynamically change between
PIO/DMA mode based on the block size.
Joel Fernandes (10):
crypto: scatterwalk: Add support for calculating number of SG
elements
crypto: omap-aes: Add useful debug macros
crypto: omap-aes: Populate number of SG elements
crypto: omap-aes: Simplify DMA usage by using direct SGs
crypto: omap-aes: Sync SG before DMA operation
crypto: omap-aes: Remove previously used intermediate buffers
crypto: omap-aes: Add IRQ info and helper macros
crypto: omap-aes: PIO mode: Add IRQ handler and walk SGs
crypto: omap-aes: PIO mode: platform data for OMAP4 and trigger it
crypto: omap-aes: Switch to PIO mode in probe function
crypto/scatterwalk.c | 22 +++
drivers/crypto/omap-aes.c | 400 ++++++++++++++++++++----------------------
include/crypto/scatterwalk.h | 2 +
3 files changed, 217 insertions(+), 207 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH 03/10] crypto: omap-aes: Populate number of SG elements
From: Joel Fernandes @ 2013-08-14 23:12 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Mark Greer, Tony Lindgren,
Santosh Shilimkar, Rajendra Nayak, Lokesh Vutla
Cc: Linux OMAP List, Linux ARM Kernel List, Linux Kernel Mailing List,
Linux Crypto Mailing List, Joel Fernandes
In-Reply-To: <1376521969-16807-1-git-send-email-joelf@ti.com>
Crypto layer only passes nbytes but number of SG elements is needed
for mapping/unmapping SGs at one time using dma_map* API and also
needed to pass in for dmaengine prep function.
We call function added to scatterwalk for this purpose in omap_aes_handle_queue
to populate the values which are used later.
Signed-off-by: Joel Fernandes <joelf@ti.com>
---
drivers/crypto/omap-aes.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 3838e0a..b7189a8 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -171,6 +171,8 @@ struct omap_aes_dev {
void *buf_out;
int dma_out;
struct dma_chan *dma_lch_out;
+ int in_sg_len;
+ int out_sg_len;
dma_addr_t dma_addr_out;
const struct omap_aes_pdata *pdata;
@@ -741,6 +743,10 @@ static int omap_aes_handle_queue(struct omap_aes_dev *dd,
dd->out_offset = 0;
dd->out_sg = req->dst;
+ dd->in_sg_len = scatterwalk_bytes_sglen(dd->in_sg, dd->total);
+ dd->out_sg_len = scatterwalk_bytes_sglen(dd->out_sg, dd->total);
+ BUG_ON(dd->in_sg_len < 0 || dd->out_sg_len < 0);
+
rctx = ablkcipher_request_ctx(req);
ctx = crypto_ablkcipher_ctx(crypto_ablkcipher_reqtfm(req));
rctx->mode &= FLAGS_MODE_MASK;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 10/10] crypto: omap-aes: Switch to PIO mode in probe function
From: Joel Fernandes @ 2013-08-14 23:12 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Mark Greer, Tony Lindgren,
Santosh Shilimkar, Rajendra Nayak, Lokesh Vutla
Cc: Linux OMAP List, Linux ARM Kernel List, Linux Kernel Mailing List,
Linux Crypto Mailing List, Joel Fernandes
In-Reply-To: <1376521969-16807-1-git-send-email-joelf@ti.com>
In cases where requesting for DMA channels fails for some reason, or channel
numbers are not provided in DT or platform data, we switch to PIO-only mode
also checking if platform provides IRQ numbers and interrupt register offsets
in DT and platform data. All dma-only paths are avoided in this mode.
Signed-off-by: Joel Fernandes <joelf@ti.com>
---
drivers/crypto/omap-aes.c | 28 +++++++++++++++++++++++-----
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 54f2729..34e3b77 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -1074,7 +1074,7 @@ static int omap_aes_probe(struct platform_device *pdev)
struct omap_aes_dev *dd;
struct crypto_alg *algp;
struct resource res;
- int err = -ENOMEM, i, j;
+ int err = -ENOMEM, i, j, irq = -1;
u32 reg;
dd = kzalloc(sizeof(struct omap_aes_dev), GFP_KERNEL);
@@ -1118,8 +1118,23 @@ static int omap_aes_probe(struct platform_device *pdev)
tasklet_init(&dd->queue_task, omap_aes_queue_task, (unsigned long)dd);
err = omap_aes_dma_init(dd);
- if (err)
- goto err_dma;
+ if (err && AES_REG_IRQ_STATUS(dd) && AES_REG_IRQ_ENABLE(dd)) {
+ dd->pio_only = 1;
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0) {
+ dev_err(dev, "can't get IRQ resource\n");
+ goto err_irq;
+ }
+
+ err = request_irq(irq, omap_aes_irq, 0,
+ dev_name(dev), dd);
+ if (err) {
+ dev_err(dev, "Unable to grab omap-aes IRQ\n");
+ goto err_irq;
+ }
+ }
+
INIT_LIST_HEAD(&dd->list);
spin_lock(&list_lock);
@@ -1147,8 +1162,11 @@ err_algs:
for (j = dd->pdata->algs_info[i].registered - 1; j >= 0; j--)
crypto_unregister_alg(
&dd->pdata->algs_info[i].algs_list[j]);
- omap_aes_dma_cleanup(dd);
-err_dma:
+ if (dd->pio_only)
+ free_irq(irq, dd);
+ else
+ omap_aes_dma_cleanup(dd);
+err_irq:
tasklet_kill(&dd->done_task);
tasklet_kill(&dd->queue_task);
pm_runtime_disable(dev);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 09/10] crypto: omap-aes: PIO mode: platform data for OMAP4 and trigger it
From: Joel Fernandes @ 2013-08-14 23:12 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Mark Greer, Tony Lindgren,
Santosh Shilimkar, Rajendra Nayak, Lokesh Vutla
Cc: Joel Fernandes, Linux OMAP List, Linux Kernel Mailing List,
Linux ARM Kernel List, Linux Crypto Mailing List
In-Reply-To: <1376521969-16807-1-git-send-email-joelf@ti.com>
We initialize the scatter gather walk lists needed for PIO mode
and avoid all DMA paths such as mapping/unmapping buffers by
checking for the pio_only flag.
Signed-off-by: Joel Fernandes <joelf@ti.com>
---
drivers/crypto/omap-aes.c | 43 ++++++++++++++++++++++++++++++-------------
1 file changed, 30 insertions(+), 13 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 891455b..54f2729 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -175,6 +175,7 @@ struct omap_aes_dev {
struct dma_chan *dma_lch_out;
int in_sg_len;
int out_sg_len;
+ int pio_only;
const struct omap_aes_pdata *pdata;
};
@@ -423,6 +424,16 @@ static int omap_aes_crypt_dma(struct crypto_tfm *tfm,
struct dma_slave_config cfg;
int ret;
+ if (dd->pio_only) {
+ scatterwalk_start(&dd->in_walk, dd->in_sg);
+ scatterwalk_start(&dd->out_walk, dd->out_sg);
+
+ /* Enable DATAIN interrupt and let it take
+ care of the rest */
+ omap_aes_write(dd, AES_REG_IRQ_ENABLE(dd), 0x2);
+ return 0;
+ }
+
dma_sync_sg_for_device(dd->dev, dd->in_sg, in_sg_len, DMA_TO_DEVICE);
memset(&cfg, 0, sizeof(cfg));
@@ -492,21 +503,25 @@ static int omap_aes_crypt_dma_start(struct omap_aes_dev *dd)
pr_debug("total: %d\n", dd->total);
- err = dma_map_sg(dd->dev, dd->in_sg, dd->in_sg_len, DMA_TO_DEVICE);
- if (!err) {
- dev_err(dd->dev, "dma_map_sg() error\n");
- return -EINVAL;
- }
+ if (!dd->pio_only) {
+ err = dma_map_sg(dd->dev, dd->in_sg, dd->in_sg_len,
+ DMA_TO_DEVICE);
+ if (!err) {
+ dev_err(dd->dev, "dma_map_sg() error\n");
+ return -EINVAL;
+ }
- err = dma_map_sg(dd->dev, dd->out_sg, dd->out_sg_len, DMA_FROM_DEVICE);
- if (!err) {
- dev_err(dd->dev, "dma_map_sg() error\n");
- return -EINVAL;
+ err = dma_map_sg(dd->dev, dd->out_sg, dd->out_sg_len,
+ DMA_FROM_DEVICE);
+ if (!err) {
+ dev_err(dd->dev, "dma_map_sg() error\n");
+ return -EINVAL;
+ }
}
err = omap_aes_crypt_dma(tfm, dd->in_sg, dd->out_sg, dd->in_sg_len,
dd->out_sg_len);
- if (err) {
+ if (err && !dd->pio_only) {
dma_unmap_sg(dd->dev, dd->in_sg, dd->in_sg_len, DMA_TO_DEVICE);
dma_unmap_sg(dd->dev, dd->out_sg, dd->out_sg_len,
DMA_FROM_DEVICE);
@@ -610,9 +625,11 @@ static void omap_aes_done_task(unsigned long data)
pr_debug("enter done_task\n");
- dma_sync_sg_for_cpu(dd->dev, dd->in_sg, dd->in_sg_len, DMA_FROM_DEVICE);
-
- omap_aes_crypt_dma_stop(dd);
+ if (!dd->pio_only) {
+ dma_sync_sg_for_device(dd->dev, dd->out_sg, dd->out_sg_len,
+ DMA_FROM_DEVICE);
+ omap_aes_crypt_dma_stop(dd);
+ }
omap_aes_finish_req(dd, 0);
omap_aes_handle_queue(dd, NULL);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 08/10] crypto: omap-aes: PIO mode: Add IRQ handler and walk SGs
From: Joel Fernandes @ 2013-08-14 23:12 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Mark Greer, Tony Lindgren,
Santosh Shilimkar, Rajendra Nayak, Lokesh Vutla
Cc: Linux OMAP List, Linux ARM Kernel List, Linux Kernel Mailing List,
Linux Crypto Mailing List, Joel Fernandes
In-Reply-To: <1376521969-16807-1-git-send-email-joelf@ti.com>
We add an IRQ handler that implements a state-machine for PIO-mode
and data structures for walking the scatter-gather list. The IRQ handler
is called in succession both when data is available to read or next
data can be sent for processing. This process continues till the entire
in/out SG lists have been walked. Once the SG-list has been completely
walked, the IRQ handler schedules the done_task tasklet.
Also add a useful macro that is used through out the IRQ code for a
common pattern of calculating how much an SG list has been walked.
This improves code readability and avoids checkpatch errors.
Signed-off-by: Joel Fernandes <joelf@ti.com>
---
drivers/crypto/omap-aes.c | 90 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 90 insertions(+)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index c057eac..891455b 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -46,6 +46,8 @@
#define DST_MAXBURST 4
#define DMA_MIN (DST_MAXBURST * sizeof(u32))
+#define _calc_walked(inout) (dd->inout##_walk.offset - dd->inout##_sg->offset)
+
/* OMAP TRM gives bitfields as start:end, where start is the higher bit
number. For example 7:0 */
#define FLD_MASK(start, end) (((1 << ((start) - (end) + 1)) - 1) << (end))
@@ -98,6 +100,8 @@
#define FLAGS_FAST BIT(5)
#define FLAGS_BUSY BIT(6)
+#define AES_BLOCK_WORDS (AES_BLOCK_SIZE >> 2)
+
struct omap_aes_ctx {
struct omap_aes_dev *dd;
@@ -163,6 +167,8 @@ struct omap_aes_dev {
size_t total;
struct scatterlist *in_sg;
struct scatterlist *out_sg;
+ struct scatter_walk in_walk;
+ struct scatter_walk out_walk;
int dma_in;
struct dma_chan *dma_lch_in;
int dma_out;
@@ -862,6 +868,90 @@ static const struct omap_aes_pdata omap_aes_pdata_omap4 = {
.minor_shift = 0,
};
+static irqreturn_t omap_aes_irq(int irq, void *dev_id)
+{
+ struct omap_aes_dev *dd = dev_id;
+ u32 status, i;
+ u32 *src, *dst;
+
+ status = omap_aes_read(dd, AES_REG_IRQ_STATUS(dd));
+ if (status & AES_REG_IRQ_DATA_IN) {
+ omap_aes_write(dd, AES_REG_IRQ_ENABLE(dd), 0x0);
+
+ BUG_ON(!dd->in_sg);
+
+ BUG_ON(_calc_walked(in) > dd->in_sg->length);
+
+ src = sg_virt(dd->in_sg) + _calc_walked(in);
+
+ for (i = 0; i < AES_BLOCK_WORDS; i++) {
+ omap_aes_write(dd, AES_REG_DATA_N(dd, i), *src);
+
+ scatterwalk_advance(&dd->in_walk, 4);
+ if (dd->in_sg->length == _calc_walked(in)) {
+ dd->in_sg = scatterwalk_sg_next(dd->in_sg);
+ if (dd->in_sg) {
+ scatterwalk_start(&dd->in_walk,
+ dd->in_sg);
+ src = sg_virt(dd->in_sg) +
+ _calc_walked(in);
+ }
+ } else {
+ src++;
+ }
+ }
+
+ /* Clear IRQ status */
+ status &= ~AES_REG_IRQ_DATA_IN;
+ omap_aes_write(dd, AES_REG_IRQ_STATUS(dd), status);
+
+ /* Enable DATA_OUT interrupt */
+ omap_aes_write(dd, AES_REG_IRQ_ENABLE(dd), 0x4);
+
+ } else if (status & AES_REG_IRQ_DATA_OUT) {
+ omap_aes_write(dd, AES_REG_IRQ_ENABLE(dd), 0x0);
+
+ BUG_ON(!dd->out_sg);
+
+ BUG_ON(_calc_walked(out) > dd->out_sg->length);
+
+ dst = sg_virt(dd->out_sg) + _calc_walked(out);
+
+ for (i = 0; i < AES_BLOCK_WORDS; i++) {
+ *dst = omap_aes_read(dd, AES_REG_DATA_N(dd, i));
+ scatterwalk_advance(&dd->out_walk, 4);
+ if (dd->out_sg->length == _calc_walked(out)) {
+ dd->out_sg = scatterwalk_sg_next(dd->out_sg);
+ if (dd->out_sg) {
+ scatterwalk_start(&dd->out_walk,
+ dd->out_sg);
+ dst = sg_virt(dd->out_sg) +
+ _calc_walked(out);
+ }
+ } else {
+ dst++;
+ }
+ }
+
+ dd->total -= AES_BLOCK_SIZE;
+
+ BUG_ON(dd->total < 0);
+
+ /* Clear IRQ status */
+ status &= ~AES_REG_IRQ_DATA_OUT;
+ omap_aes_write(dd, AES_REG_IRQ_STATUS(dd), status);
+
+ if (!dd->total)
+ /* All bytes read! */
+ tasklet_schedule(&dd->done_task);
+ else
+ /* Enable DATA_IN interrupt for next block */
+ omap_aes_write(dd, AES_REG_IRQ_ENABLE(dd), 0x2);
+ }
+
+ return IRQ_HANDLED;
+}
+
static const struct of_device_id omap_aes_of_match[] = {
{
.compatible = "ti,omap2-aes",
--
1.7.9.5
^ permalink raw reply related
* [PATCH 07/10] crypto: omap-aes: Add IRQ info and helper macros
From: Joel Fernandes @ 2013-08-14 23:12 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Mark Greer, Tony Lindgren,
Santosh Shilimkar, Rajendra Nayak, Lokesh Vutla
Cc: Joel Fernandes, Linux OMAP List, Linux Kernel Mailing List,
Linux ARM Kernel List, Linux Crypto Mailing List
In-Reply-To: <1376521969-16807-1-git-send-email-joelf@ti.com>
Add IRQ information to pdata and helper macros. These are
required for PIO-mode support.
Signed-off-by: Joel Fernandes <joelf@ti.com>
---
drivers/crypto/omap-aes.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 71da52b..c057eac 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -82,6 +82,10 @@
#define AES_REG_LENGTH_N(x) (0x54 + ((x) * 0x04))
+#define AES_REG_IRQ_STATUS(dd) ((dd)->pdata->irq_status_ofs)
+#define AES_REG_IRQ_ENABLE(dd) ((dd)->pdata->irq_enable_ofs)
+#define AES_REG_IRQ_DATA_IN BIT(1)
+#define AES_REG_IRQ_DATA_OUT BIT(2)
#define DEFAULT_TIMEOUT (5*HZ)
#define FLAGS_MODE_MASK 0x000f
@@ -127,6 +131,8 @@ struct omap_aes_pdata {
u32 data_ofs;
u32 rev_ofs;
u32 mask_ofs;
+ u32 irq_enable_ofs;
+ u32 irq_status_ofs;
u32 dma_enable_in;
u32 dma_enable_out;
@@ -846,6 +852,8 @@ static const struct omap_aes_pdata omap_aes_pdata_omap4 = {
.data_ofs = 0x60,
.rev_ofs = 0x80,
.mask_ofs = 0x84,
+ .irq_status_ofs = 0x8c,
+ .irq_enable_ofs = 0x90,
.dma_enable_in = BIT(5),
.dma_enable_out = BIT(6),
.major_mask = 0x0700,
--
1.7.9.5
^ permalink raw reply related
* [PATCH 06/10] crypto: omap-aes: Remove previously used intermediate buffers
From: Joel Fernandes @ 2013-08-14 23:12 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Mark Greer, Tony Lindgren,
Santosh Shilimkar, Rajendra Nayak, Lokesh Vutla
Cc: Linux OMAP List, Linux ARM Kernel List, Linux Kernel Mailing List,
Linux Crypto Mailing List, Joel Fernandes
In-Reply-To: <1376521969-16807-1-git-send-email-joelf@ti.com>
Intermdiate buffers were allocated, mapped and used for DMA.
These are no longer required as we use the SGs from crypto layer
directly in previous commits in the series. Also along with it,
remove the logic for copying SGs etc as they are no longer used,
and all the associated variables in omap_aes_device.
Signed-off-by: Joel Fernandes <joelf@ti.com>
---
drivers/crypto/omap-aes.c | 90 ---------------------------------------------
1 file changed, 90 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index df2f867..71da52b 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -156,25 +156,13 @@ struct omap_aes_dev {
struct ablkcipher_request *req;
size_t total;
struct scatterlist *in_sg;
- struct scatterlist in_sgl;
- size_t in_offset;
struct scatterlist *out_sg;
- struct scatterlist out_sgl;
- size_t out_offset;
-
- size_t buflen;
- void *buf_in;
- size_t dma_size;
int dma_in;
struct dma_chan *dma_lch_in;
- dma_addr_t dma_addr_in;
- void *buf_out;
int dma_out;
struct dma_chan *dma_lch_out;
int in_sg_len;
int out_sg_len;
- dma_addr_t dma_addr_out;
-
const struct omap_aes_pdata *pdata;
};
@@ -362,33 +350,6 @@ static int omap_aes_dma_init(struct omap_aes_dev *dd)
dd->dma_lch_out = NULL;
dd->dma_lch_in = NULL;
- dd->buf_in = (void *)__get_free_pages(GFP_KERNEL, OMAP_AES_CACHE_SIZE);
- dd->buf_out = (void *)__get_free_pages(GFP_KERNEL, OMAP_AES_CACHE_SIZE);
- dd->buflen = PAGE_SIZE << OMAP_AES_CACHE_SIZE;
- dd->buflen &= ~(AES_BLOCK_SIZE - 1);
-
- if (!dd->buf_in || !dd->buf_out) {
- dev_err(dd->dev, "unable to alloc pages.\n");
- goto err_alloc;
- }
-
- /* MAP here */
- dd->dma_addr_in = dma_map_single(dd->dev, dd->buf_in, dd->buflen,
- DMA_TO_DEVICE);
- if (dma_mapping_error(dd->dev, dd->dma_addr_in)) {
- dev_err(dd->dev, "dma %d bytes error\n", dd->buflen);
- err = -EINVAL;
- goto err_map_in;
- }
-
- dd->dma_addr_out = dma_map_single(dd->dev, dd->buf_out, dd->buflen,
- DMA_FROM_DEVICE);
- if (dma_mapping_error(dd->dev, dd->dma_addr_out)) {
- dev_err(dd->dev, "dma %d bytes error\n", dd->buflen);
- err = -EINVAL;
- goto err_map_out;
- }
-
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
@@ -415,14 +376,6 @@ static int omap_aes_dma_init(struct omap_aes_dev *dd)
err_dma_out:
dma_release_channel(dd->dma_lch_in);
err_dma_in:
- dma_unmap_single(dd->dev, dd->dma_addr_out, dd->buflen,
- DMA_FROM_DEVICE);
-err_map_out:
- dma_unmap_single(dd->dev, dd->dma_addr_in, dd->buflen, DMA_TO_DEVICE);
-err_map_in:
- free_pages((unsigned long)dd->buf_out, OMAP_AES_CACHE_SIZE);
- free_pages((unsigned long)dd->buf_in, OMAP_AES_CACHE_SIZE);
-err_alloc:
if (err)
pr_err("error: %d\n", err);
return err;
@@ -432,11 +385,6 @@ static void omap_aes_dma_cleanup(struct omap_aes_dev *dd)
{
dma_release_channel(dd->dma_lch_out);
dma_release_channel(dd->dma_lch_in);
- dma_unmap_single(dd->dev, dd->dma_addr_out, dd->buflen,
- DMA_FROM_DEVICE);
- dma_unmap_single(dd->dev, dd->dma_addr_in, dd->buflen, DMA_TO_DEVICE);
- free_pages((unsigned long)dd->buf_out, OMAP_AES_CACHE_SIZE);
- free_pages((unsigned long)dd->buf_in, OMAP_AES_CACHE_SIZE);
}
static void sg_copy_buf(void *buf, struct scatterlist *sg,
@@ -453,42 +401,6 @@ static void sg_copy_buf(void *buf, struct scatterlist *sg,
scatterwalk_done(&walk, out, 0);
}
-static int sg_copy(struct scatterlist **sg, size_t *offset, void *buf,
- size_t buflen, size_t total, int out)
-{
- unsigned int count, off = 0;
-
- while (buflen && total) {
- count = min((*sg)->length - *offset, total);
- count = min(count, buflen);
-
- if (!count)
- return off;
-
- /*
- * buflen and total are AES_BLOCK_SIZE size aligned,
- * so count should be also aligned
- */
-
- sg_copy_buf(buf + off, *sg, *offset, count, out);
-
- off += count;
- buflen -= count;
- *offset += count;
- total -= count;
-
- if (*offset == (*sg)->length) {
- *sg = sg_next(*sg);
- if (*sg)
- *offset = 0;
- else
- total = 0;
- }
- }
-
- return off;
-}
-
static int omap_aes_crypt_dma(struct crypto_tfm *tfm,
struct scatterlist *in_sg, struct scatterlist *out_sg,
int in_sg_len, int out_sg_len)
@@ -653,9 +565,7 @@ static int omap_aes_handle_queue(struct omap_aes_dev *dd,
/* assign new request to device */
dd->req = req;
dd->total = req->nbytes;
- dd->in_offset = 0;
dd->in_sg = req->src;
- dd->out_offset = 0;
dd->out_sg = req->dst;
dd->in_sg_len = scatterwalk_bytes_sglen(dd->in_sg, dd->total);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 05/10] crypto: omap-aes: Sync SG before DMA operation
From: Joel Fernandes @ 2013-08-14 23:12 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Mark Greer, Tony Lindgren,
Santosh Shilimkar, Rajendra Nayak, Lokesh Vutla
Cc: Linux OMAP List, Linux ARM Kernel List, Linux Kernel Mailing List,
Linux Crypto Mailing List, Joel Fernandes
In-Reply-To: <1376521969-16807-1-git-send-email-joelf@ti.com>
Earlier functions that did a similar sync are replaced by
the dma_sync_sg_* which can operate on entire SG list.
Signed-off-by: Joel Fernandes <joelf@ti.com>
---
drivers/crypto/omap-aes.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 9104a7f..df2f867 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -499,6 +499,8 @@ static int omap_aes_crypt_dma(struct crypto_tfm *tfm,
struct dma_slave_config cfg;
int ret;
+ dma_sync_sg_for_device(dd->dev, dd->in_sg, in_sg_len, DMA_TO_DEVICE);
+
memset(&cfg, 0, sizeof(cfg));
cfg.src_addr = dd->phys_base + AES_REG_DATA_N(dd, 0);
@@ -686,6 +688,8 @@ static void omap_aes_done_task(unsigned long data)
pr_debug("enter done_task\n");
+ dma_sync_sg_for_cpu(dd->dev, dd->in_sg, dd->in_sg_len, DMA_FROM_DEVICE);
+
omap_aes_crypt_dma_stop(dd);
omap_aes_finish_req(dd, 0);
omap_aes_handle_queue(dd, NULL);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 04/10] crypto: omap-aes: Simplify DMA usage by using direct SGs
From: Joel Fernandes @ 2013-08-14 23:12 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Mark Greer, Tony Lindgren,
Santosh Shilimkar, Rajendra Nayak, Lokesh Vutla
Cc: Linux OMAP List, Linux ARM Kernel List, Linux Kernel Mailing List,
Linux Crypto Mailing List, Joel Fernandes
In-Reply-To: <1376521969-16807-1-git-send-email-joelf@ti.com>
In early version of this driver, assumptions were made such as
DMA layer requires contiguous buffers etc. Due to this, new buffers
were allocated, mapped and used for DMA. These assumptions are no
longer true and DMAEngine scatter-gather DMA doesn't have such
requirements. We simply the DMA operations by directly using the
scatter-gather buffers provided by the crypto layer instead of
creating our own.
Lot of logic that handled DMA'ing only X number of bytes of the
total, or as much as fitted into a 3rd party buffer is removed
and is no longer required.
Also, drastically improves performance (atleast 35% seen with
encrypting a buffer size of 8K (2800 ops/sec vs 1800 ops/sec).
Also DMA usage is much more simplified and coherent with rest
of the code.
Signed-off-by: Joel Fernandes <joelf@ti.com>
---
drivers/crypto/omap-aes.c | 147 ++++++++-------------------------------------
1 file changed, 25 insertions(+), 122 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index b7189a8..9104a7f 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -490,22 +490,14 @@ static int sg_copy(struct scatterlist **sg, size_t *offset, void *buf,
}
static int omap_aes_crypt_dma(struct crypto_tfm *tfm,
- struct scatterlist *in_sg, struct scatterlist *out_sg)
+ struct scatterlist *in_sg, struct scatterlist *out_sg,
+ int in_sg_len, int out_sg_len)
{
struct omap_aes_ctx *ctx = crypto_tfm_ctx(tfm);
struct omap_aes_dev *dd = ctx->dd;
struct dma_async_tx_descriptor *tx_in, *tx_out;
struct dma_slave_config cfg;
- dma_addr_t dma_addr_in = sg_dma_address(in_sg);
- int ret, length = sg_dma_len(in_sg);
-
- pr_debug("len: %d\n", length);
-
- dd->dma_size = length;
-
- if (!(dd->flags & FLAGS_FAST))
- dma_sync_single_for_device(dd->dev, dma_addr_in, length,
- DMA_TO_DEVICE);
+ int ret;
memset(&cfg, 0, sizeof(cfg));
@@ -524,7 +516,7 @@ static int omap_aes_crypt_dma(struct crypto_tfm *tfm,
return ret;
}
- tx_in = dmaengine_prep_slave_sg(dd->dma_lch_in, in_sg, 1,
+ tx_in = dmaengine_prep_slave_sg(dd->dma_lch_in, in_sg, in_sg_len,
DMA_MEM_TO_DEV,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!tx_in) {
@@ -543,7 +535,7 @@ static int omap_aes_crypt_dma(struct crypto_tfm *tfm,
return ret;
}
- tx_out = dmaengine_prep_slave_sg(dd->dma_lch_out, out_sg, 1,
+ tx_out = dmaengine_prep_slave_sg(dd->dma_lch_out, out_sg, out_sg_len,
DMA_DEV_TO_MEM,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!tx_out) {
@@ -561,7 +553,7 @@ static int omap_aes_crypt_dma(struct crypto_tfm *tfm,
dma_async_issue_pending(dd->dma_lch_out);
/* start DMA */
- dd->pdata->trigger(dd, length);
+ dd->pdata->trigger(dd, dd->total);
return 0;
}
@@ -570,93 +562,28 @@ static int omap_aes_crypt_dma_start(struct omap_aes_dev *dd)
{
struct crypto_tfm *tfm = crypto_ablkcipher_tfm(
crypto_ablkcipher_reqtfm(dd->req));
- int err, fast = 0, in, out;
- size_t count;
- dma_addr_t addr_in, addr_out;
- struct scatterlist *in_sg, *out_sg;
- int len32;
+ int err;
pr_debug("total: %d\n", dd->total);
- if (sg_is_last(dd->in_sg) && sg_is_last(dd->out_sg)) {
- /* check for alignment */
- in = IS_ALIGNED((u32)dd->in_sg->offset, sizeof(u32));
- out = IS_ALIGNED((u32)dd->out_sg->offset, sizeof(u32));
-
- fast = in && out;
+ err = dma_map_sg(dd->dev, dd->in_sg, dd->in_sg_len, DMA_TO_DEVICE);
+ if (!err) {
+ dev_err(dd->dev, "dma_map_sg() error\n");
+ return -EINVAL;
}
- if (fast) {
- count = min(dd->total, sg_dma_len(dd->in_sg));
- count = min(count, sg_dma_len(dd->out_sg));
-
- if (count != dd->total) {
- pr_err("request length != buffer length\n");
- return -EINVAL;
- }
-
- pr_debug("fast\n");
-
- err = dma_map_sg(dd->dev, dd->in_sg, 1, DMA_TO_DEVICE);
- if (!err) {
- dev_err(dd->dev, "dma_map_sg() error\n");
- return -EINVAL;
- }
-
- err = dma_map_sg(dd->dev, dd->out_sg, 1, DMA_FROM_DEVICE);
- if (!err) {
- dev_err(dd->dev, "dma_map_sg() error\n");
- dma_unmap_sg(dd->dev, dd->in_sg, 1, DMA_TO_DEVICE);
- return -EINVAL;
- }
-
- addr_in = sg_dma_address(dd->in_sg);
- addr_out = sg_dma_address(dd->out_sg);
-
- in_sg = dd->in_sg;
- out_sg = dd->out_sg;
-
- dd->flags |= FLAGS_FAST;
-
- } else {
- /* use cache buffers */
- count = sg_copy(&dd->in_sg, &dd->in_offset, dd->buf_in,
- dd->buflen, dd->total, 0);
-
- len32 = DIV_ROUND_UP(count, DMA_MIN) * DMA_MIN;
-
- /*
- * The data going into the AES module has been copied
- * to a local buffer and the data coming out will go
- * into a local buffer so set up local SG entries for
- * both.
- */
- sg_init_table(&dd->in_sgl, 1);
- dd->in_sgl.offset = dd->in_offset;
- sg_dma_len(&dd->in_sgl) = len32;
- sg_dma_address(&dd->in_sgl) = dd->dma_addr_in;
-
- sg_init_table(&dd->out_sgl, 1);
- dd->out_sgl.offset = dd->out_offset;
- sg_dma_len(&dd->out_sgl) = len32;
- sg_dma_address(&dd->out_sgl) = dd->dma_addr_out;
-
- in_sg = &dd->in_sgl;
- out_sg = &dd->out_sgl;
-
- addr_in = dd->dma_addr_in;
- addr_out = dd->dma_addr_out;
-
- dd->flags &= ~FLAGS_FAST;
-
+ err = dma_map_sg(dd->dev, dd->out_sg, dd->out_sg_len, DMA_FROM_DEVICE);
+ if (!err) {
+ dev_err(dd->dev, "dma_map_sg() error\n");
+ return -EINVAL;
}
- dd->total -= count;
-
- err = omap_aes_crypt_dma(tfm, in_sg, out_sg);
+ err = omap_aes_crypt_dma(tfm, dd->in_sg, dd->out_sg, dd->in_sg_len,
+ dd->out_sg_len);
if (err) {
- dma_unmap_sg(dd->dev, dd->in_sg, 1, DMA_TO_DEVICE);
- dma_unmap_sg(dd->dev, dd->out_sg, 1, DMA_TO_DEVICE);
+ dma_unmap_sg(dd->dev, dd->in_sg, dd->in_sg_len, DMA_TO_DEVICE);
+ dma_unmap_sg(dd->dev, dd->out_sg, dd->out_sg_len,
+ DMA_FROM_DEVICE);
}
return err;
@@ -677,7 +604,6 @@ static void omap_aes_finish_req(struct omap_aes_dev *dd, int err)
static int omap_aes_crypt_dma_stop(struct omap_aes_dev *dd)
{
int err = 0;
- size_t count;
pr_debug("total: %d\n", dd->total);
@@ -686,21 +612,8 @@ static int omap_aes_crypt_dma_stop(struct omap_aes_dev *dd)
dmaengine_terminate_all(dd->dma_lch_in);
dmaengine_terminate_all(dd->dma_lch_out);
- if (dd->flags & FLAGS_FAST) {
- dma_unmap_sg(dd->dev, dd->out_sg, 1, DMA_FROM_DEVICE);
- dma_unmap_sg(dd->dev, dd->in_sg, 1, DMA_TO_DEVICE);
- } else {
- dma_sync_single_for_device(dd->dev, dd->dma_addr_out,
- dd->dma_size, DMA_FROM_DEVICE);
-
- /* copy data */
- count = sg_copy(&dd->out_sg, &dd->out_offset, dd->buf_out,
- dd->buflen, dd->dma_size, 1);
- if (count != dd->dma_size) {
- err = -EINVAL;
- pr_err("not all data converted: %u\n", count);
- }
- }
+ dma_unmap_sg(dd->dev, dd->in_sg, dd->in_sg_len, DMA_TO_DEVICE);
+ dma_unmap_sg(dd->dev, dd->out_sg, dd->out_sg_len, DMA_FROM_DEVICE);
return err;
}
@@ -770,21 +683,11 @@ static int omap_aes_handle_queue(struct omap_aes_dev *dd,
static void omap_aes_done_task(unsigned long data)
{
struct omap_aes_dev *dd = (struct omap_aes_dev *)data;
- int err;
-
- pr_debug("enter\n");
- err = omap_aes_crypt_dma_stop(dd);
-
- err = dd->err ? : err;
-
- if (dd->total && !err) {
- err = omap_aes_crypt_dma_start(dd);
- if (!err)
- return; /* DMA started. Not fininishing. */
- }
+ pr_debug("enter done_task\n");
- omap_aes_finish_req(dd, err);
+ omap_aes_crypt_dma_stop(dd);
+ omap_aes_finish_req(dd, 0);
omap_aes_handle_queue(dd, NULL);
pr_debug("exit\n");
--
1.7.9.5
^ permalink raw reply related
* [PATCH 02/10] crypto: omap-aes: Add useful debug macros
From: Joel Fernandes @ 2013-08-14 23:12 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Mark Greer, Tony Lindgren,
Santosh Shilimkar, Rajendra Nayak, Lokesh Vutla
Cc: Joel Fernandes, Linux OMAP List, Linux Kernel Mailing List,
Linux ARM Kernel List, Linux Crypto Mailing List
In-Reply-To: <1376521969-16807-1-git-send-email-joelf@ti.com>
When DEBUG is enabled, these macros can be used to print variables
in integer and hex format, and clearly display which registers,
offsets and values are being read/written , including printing the
names of the offsets and their values.
Signed-off-by: Joel Fernandes <joelf@ti.com>
---
drivers/crypto/omap-aes.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index ee15b0f..3838e0a 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -15,6 +15,14 @@
#define pr_fmt(fmt) "%s: " fmt, __func__
+#ifdef DEBUG
+#define prn(num) printk(#num "=%d\n", num)
+#define prx(num) printk(#num "=%x\n", num)
+#else
+#define prn(num) do { } while (0)
+#define prx(num) do { } while (0)
+#endif
+
#include <linux/err.h>
#include <linux/module.h>
#include <linux/init.h>
@@ -172,13 +180,35 @@ struct omap_aes_dev {
static LIST_HEAD(dev_list);
static DEFINE_SPINLOCK(list_lock);
+#ifdef DEBUG
+#define omap_aes_read(dd, offset) \
+ do { \
+ omap_aes_read_1(dd, offset); \
+ pr_debug("omap_aes_read(" #offset ")\n"); \
+ } while (0)
+
+static inline u32 omap_aes_read_1(struct omap_aes_dev *dd, u32 offset)
+#else
static inline u32 omap_aes_read(struct omap_aes_dev *dd, u32 offset)
+#endif
{
return __raw_readl(dd->io_base + offset);
}
+#ifdef DEBUG
+#define omap_aes_write(dd, offset, value) \
+ do { \
+ pr_debug("omap_aes_write(" #offset "=%x) value=%d\n", \
+ offset, value); \
+ omap_aes_write_1(dd, offset, value); \
+ } while (0)
+
+static inline void omap_aes_write_1(struct omap_aes_dev *dd, u32 offset,
+ u32 value)
+#else
static inline void omap_aes_write(struct omap_aes_dev *dd, u32 offset,
u32 value)
+#endif
{
__raw_writel(value, dd->io_base + offset);
}
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox