RE: [PATCH] spi/omap2: Let device core handle pinctrl
On Fri, May 10, 2013 at 15:26:29, Mark Brown wrote: On Tue, May 07, 2013 at 10:47:31AM +, Hebbar, Gururaja wrote: On Tue, May 07, 2013 at 14:25:35, Mark Brown wrote: There's also been some discussion about factoring out the suspend/resume code since it's going to get equally repetitive. Really. Any link/referenceso that I can follow. But I think each module will have its own work to do. May be I can confirm once I look at the factoring-out discussion. It was part of the threads where the idea of adding the helper for the boilerplate stuff to the core was discussed initially IIRC. Ok. Thanks. I will check for it. I will be submitting a patch to enhance the existing pinctrl support for spi omap2 shortly which does above work. How soon is shortly? Since I am adding this Pinctrl PM mode support to many other drivers (i2c, cpsw, da8xx-fb, hsmmc, ti-pwm, usb ...), I would say Shortly = 1 week - 10 days. Well, I guess I'll keep the patch for now and drop it when you send out the PM code. Fair enough. Regards, Gururaja -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP: fix __init section mismatch for _enable_preprogram
Hi, _enable_preprogram is marked as __init, but is called from _enable which is not. Without this patch, the board oopses after init. Tested on custom hardware and on beagle board xM. Signed-off-by: Jean-Philippe François jp.franc...@cynove.com omap_hwmod_fix.patch Description: Binary data
Re: [PATCH] OMAP: AES: Don't idle/start AES device between Encrypt operations
Joel A Fernandes joelag...@ti.com writes:
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 of the session (cra_init)
and runtime_pm_put at the end. This result in upto a 50% speedup as below:
Before:
root@beagleboard:~# time -v openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 13310 aes-128-cbc's in 0.01s
Doing aes-128-cbc for 3s on 64 size blocks: 13040 aes-128-cbc's in 0.04s
Doing aes-128-cbc for 3s on 256 size blocks: 9134 aes-128-cbc's in 0.03s
Doing aes-128-cbc for 3s on 1024 size blocks: 8939 aes-128-cbc's in 0.01s
Doing aes-128-cbc for 3s on 8192 size blocks: 4299 aes-128-cbc's in 0.00s
After:
root@beagleboard:~# time -v openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 18911 aes-128-cbc's in 0.02s
Doing aes-128-cbc for 3s on 64 size blocks: 18878 aes-128-cbc's in 0.02s
Doing aes-128-cbc for 3s on 256 size blocks: 11878 aes-128-cbc's in 0.10s
Doing aes-128-cbc for 3s on 1024 size blocks: 11538 aes-128-cbc's in 0.05s
Doing aes-128-cbc for 3s on 8192 size blocks: 4857 aes-128-cbc's in 0.03s
While at it, also drop enter and exit pr_debugs, in related code. tracers
are exactly used for that.
Tested on a Beaglebone (AM335x SoC) board.
Signed-off-by: Joel A Fernandes joelag...@ti.com
Did you explore using runtime PM autosuspend timeouts for this instead?
They are intended for exactly this kind of thing, and the timeouts can
have sane defaults, but can be configured from userspace to allow a
power/performance trade-off.
[...]
static void omap_aes_cra_exit(struct crypto_tfm *tfm)
{
- pr_debug(enter\n);
+ struct omap_aes_dev *dd = NULL;
+
+ /* Find AES device, currently picks the first device */
+ spin_lock_bh(list_lock);
+ list_for_each_entry(dd, dev_list, list) {
+ break;
+ }
+ spin_unlock_bh(list_lock);
+
+ pm_runtime_put_sync(dd-dev);
nit: Why use the synchronous call here? The original was async.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: defconfigs: OMAP: omap2plus_defconfig missing CONFIG_ARCH_MULTI_V6=y
omap2plus_defconfig is missing CONFIG_ARCH_MULTI_V6. This results in undefined instruction traps in u-boot (and boot failures) on OMAP2xxx SoCs, which are ARM11-based. Fix by setting CONFIG_ARCH_MULTI_V7. Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/configs/omap2plus_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index c1ef64b..f590902 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -20,6 +20,7 @@ CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y # CONFIG_BLK_DEV_BSG is not set +CONFIG_ARCH_MULTI_V6=y CONFIG_ARCH_OMAP2PLUS=y CONFIG_OMAP_RESET_CLOCKS=y CONFIG_OMAP_MUX_DEBUG=y -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: defconfigs: OMAP: omap2plus_defconfig missing CONFIG_ARCH_MULTI_V6=y
On Mon, 13 May 2013, Paul Walmsley wrote: Fix by setting CONFIG_ARCH_MULTI_V7. Well, obvious typo here. Here's the updated version. - Paul From: Paul Walmsley p...@pwsan.com Date: Mon, 13 May 2013 10:47:48 -0600 Subject: [PATCH] ARM: defconfigs: OMAP: omap2plus_defconfig missing CONFIG_ARCH_MULTI_V6=y omap2plus_defconfig is missing CONFIG_ARCH_MULTI_V6. This results in undefined instruction traps in u-boot (and boot failures) on OMAP2xxx SoCs, which are ARM11-based. Fix by setting CONFIG_ARCH_MULTI_V6. Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/configs/omap2plus_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index c1ef64b..f590902 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -20,6 +20,7 @@ CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y # CONFIG_BLK_DEV_BSG is not set +CONFIG_ARCH_MULTI_V6=y CONFIG_ARCH_OMAP2PLUS=y CONFIG_OMAP_RESET_CLOCKS=y CONFIG_OMAP_MUX_DEBUG=y -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap pm : _enable_preprogram should not be __init ?
Salut Jean-philippe,
jean-philippe francois jp.franc...@cynove.com writes:
Hi list,
Launching program using I2C after init leads to an oops with 3.9 on a
custom dm3730 based board.
Looking at the disassembly of the _enable function in omap_hwmod.o, I
noticed the call to _enable_preprogram was a direct branch to an
adress in the .text section in the middle of another function. Looking
for _enable_preprogram, it was at the right offset, but in the
.init.text section, so I guess this is why it works fine during the
boot, and oops once init is started
I recompiled the kernel with the attached patch and the oops is gone.
Is that the right ting to do ?
Yes, that looks like the right thing to do.
Could you please send a proper patch with changelog and signoff?
Thanks,
Kevin
Jean-Philippe François
Index: b/arch/arm/mach-omap2/omap_hwmod.c
===
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2066,7 +2066,7 @@
* do so is present in the hwmod data, then call it and pass along the
* return value; otherwise, return 0.
*/
-static int __init _enable_preprogram(struct omap_hwmod *oh)
+static int _enable_preprogram(struct omap_hwmod *oh)
{
if (!oh-class-enable_preprogram)
return 0;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP: AES: Don't idle/start AES device between Encrypt operations
Hi Kevin,
Thanks for your review.
-Original Message-
From: Kevin Hilman [mailto:khil...@linaro.org]
Sent: Monday, May 13, 2013 11:36 AM
To: Fernandes, Joel A
Cc: linux-cry...@vger.kernel.org; linux-omap@vger.kernel.org; Mark A. Greer
Subject: Re: [PATCH] OMAP: AES: Don't idle/start AES device between Encrypt
operations
Joel A Fernandes joelag...@ti.com writes:
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 of the session
(cra_init) and runtime_pm_put at the end. This result in upto a 50% speedup
as below:
Before:
root@beagleboard:~# time -v openssl speed -evp aes-128-cbc Doing
aes-128-cbc for 3s on 16 size blocks: 13310 aes-128-cbc's in 0.01s
Doing aes-128-cbc for 3s on 64 size blocks: 13040 aes-128-cbc's in
0.04s Doing aes-128-cbc for 3s on 256 size blocks: 9134 aes-128-cbc's
in 0.03s Doing aes-128-cbc for 3s on 1024 size blocks: 8939
aes-128-cbc's in 0.01s Doing aes-128-cbc for 3s on 8192 size blocks:
4299 aes-128-cbc's in 0.00s
After:
root@beagleboard:~# time -v openssl speed -evp aes-128-cbc Doing
aes-128-cbc for 3s on 16 size blocks: 18911 aes-128-cbc's in 0.02s
Doing aes-128-cbc for 3s on 64 size blocks: 18878 aes-128-cbc's in
0.02s Doing aes-128-cbc for 3s on 256 size blocks: 11878 aes-128-cbc's
in 0.10s Doing aes-128-cbc for 3s on 1024 size blocks: 11538
aes-128-cbc's in 0.05s Doing aes-128-cbc for 3s on 8192 size blocks:
4857 aes-128-cbc's in 0.03s
While at it, also drop enter and exit pr_debugs, in related code.
tracers are exactly used for that.
Tested on a Beaglebone (AM335x SoC) board.
Signed-off-by: Joel A Fernandes joelag...@ti.com
Did you explore using runtime PM autosuspend timeouts for this instead?
They are intended for exactly this kind of thing, and the timeouts can have
sane
defaults, but can be configured from userspace to allow a power/performance
trade-off.
[Joel] Actually, I feel there is no real benefit in calling runtime PM api so
many
times in between crypto operations. The patch just moves the runtime pm usage
to the beginning and end of a crypto session which will have to be created
anyway.
Imagine encrypting a 20M block- this means runtime PM API is called
20 * 1024 / 4 =~ 5000 times. The slow down in my opinion doesn't make it worth
it.
What is your opinion about this?
I can explore runtime-pm timeouts and propose the numbers to describe what would
the speedup w/ my patch and w/ timeouts.
[...]
static void omap_aes_cra_exit(struct crypto_tfm *tfm) {
- pr_debug(enter\n);
+ struct omap_aes_dev *dd = NULL;
+
+ /* Find AES device, currently picks the first device */
+ spin_lock_bh(list_lock);
+ list_for_each_entry(dd, dev_list, list) {
+ break;
+ }
+ spin_unlock_bh(list_lock);
+
+ pm_runtime_put_sync(dd-dev);
nit: Why use the synchronous call here? The original was async.
[Joel] Async was required there because that was in interrupt context. It was
originally sync but changed to
async in another separate patch.
Thanks,
Joel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: AES: Don't idle/start AES device between Encrypt operations
Hi Joel, Fernandes, Joel A joelag...@ti.com writes: Hi Kevin, Thanks for your review. -Original Message- From: Kevin Hilman [mailto:khil...@linaro.org] Sent: Monday, May 13, 2013 11:36 AM To: Fernandes, Joel A Cc: linux-cry...@vger.kernel.org; linux-omap@vger.kernel.org; Mark A. Greer Subject: Re: [PATCH] OMAP: AES: Don't idle/start AES device between Encrypt operations Joel A Fernandes joelag...@ti.com writes: 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 of the session (cra_init) and runtime_pm_put at the end. This result in upto a 50% speedup as below: Before: root@beagleboard:~# time -v openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 13310 aes-128-cbc's in 0.01s Doing aes-128-cbc for 3s on 64 size blocks: 13040 aes-128-cbc's in 0.04s Doing aes-128-cbc for 3s on 256 size blocks: 9134 aes-128-cbc's in 0.03s Doing aes-128-cbc for 3s on 1024 size blocks: 8939 aes-128-cbc's in 0.01s Doing aes-128-cbc for 3s on 8192 size blocks: 4299 aes-128-cbc's in 0.00s After: root@beagleboard:~# time -v openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 18911 aes-128-cbc's in 0.02s Doing aes-128-cbc for 3s on 64 size blocks: 18878 aes-128-cbc's in 0.02s Doing aes-128-cbc for 3s on 256 size blocks: 11878 aes-128-cbc's in 0.10s Doing aes-128-cbc for 3s on 1024 size blocks: 11538 aes-128-cbc's in 0.05s Doing aes-128-cbc for 3s on 8192 size blocks: 4857 aes-128-cbc's in 0.03s While at it, also drop enter and exit pr_debugs, in related code. tracers are exactly used for that. Tested on a Beaglebone (AM335x SoC) board. Signed-off-by: Joel A Fernandes joelag...@ti.com Did you explore using runtime PM autosuspend timeouts for this instead? They are intended for exactly this kind of thing, and the timeouts can have sane defaults, but can be configured from userspace to allow a power/performance trade-off. [Joel] Actually, I feel there is no real benefit in calling runtime PM api so many times in between crypto operations. The patch just moves the runtime pm usage to the beginning and end of a crypto session which will have to be created anyway. Imagine encrypting a 20M block- this means runtime PM API is called 20 * 1024 / 4 =~ 5000 times. The slow down in my opinion doesn't make it worth it. What is your opinion about this? OK, I'm not terribly familiar with the crypto API, so I was assuming that the init/exit calls you're instrumenting were happening at driver probe/remove time. Based on your clarifications, that doesn't seem to be the case. My main concern is that drivers don't simply use 'get' on driver probe and 'put' on driver remove and force the system awake as long as the driver is present. I've seen that plenty of times, and I was assuming that's what was going on here. Sorry for the confusion. I can explore runtime-pm timeouts and propose the numbers to describe what would the speedup w/ my patch and w/ timeouts. Probably not needed. How about just add a few more details to the changelog summarizing how/when the init/exit calls happen to make it a bit more clear. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression
Hi, I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: [2.264221] retu-mfd 2-0001: Retu v3.2 found [2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 [2.300140] retu-mfd: probe of 2-0001 failed with error -12 The error is coming from regmap code. According to git bisect, it is caused by: commit ede4d7a5b9835510fd1f724367f68d2fa4128453 Author: Jon Hunter jon-hun...@ti.com Date: Fri Mar 1 11:22:47 2013 -0600 gpio/omap: convert gpio irq domain to linear mapping The commit does not anymore revert cleanly, and I haven't yet tried crafting a manual revert, so any fix proposals/ideas are welcome... Thanks, A. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3+: am33xx id: Add new am33xx specific function to check dev_feature
Vaibhav Hiremath hvaib...@ti.com writes: Layout of DEV_FEATURE register (offset = 0x604) is different between TI81xx and AM33xx device, so create separate function which will check for features available on specific AM33xx SoC and set the flags accordingly. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Minor nit below, otherwise... Reviewed-by: Kevin Hilman khil...@linaro.org --- arch/arm/mach-omap2/control.h |5 + arch/arm/mach-omap2/id.c | 13 + arch/arm/mach-omap2/io.c |2 +- arch/arm/mach-omap2/soc.h |1 + 4 files changed, 20 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h index e6c3281..4acdfc5 100644 --- a/arch/arm/mach-omap2/control.h +++ b/arch/arm/mach-omap2/control.h @@ -358,6 +358,11 @@ #define AM33XX_CONTROL_STATUS_SYSBOOT1_WIDTH 0x2 #define AM33XX_CONTROL_STATUS_SYSBOOT1_MASK (0x3 22) +/* DEV Feature register to identify AM33XX features */ +#define AM33XX_DEV_FEATURE 0x604 +#define AM33XX_SGX_SHIFT 29 You don't need the shift value anywhere in the code, so... +#define AM33XX_SGX_MASK (1 AM33XX_SGX_SHIFT) #define AM33XX_SGX_MASK BIT(29) instead? Otherwise, rest of patch looks fine. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 1/6] clk: OMAP: introduce device tree binding to kernel clock data
Quoting Nishanth Menon (2013-05-08 12:06:11)
snip
Overall strategy introduced here is simple: a clock node described in
device tree blob is used to identify the exact clock provided in the
SoC specific data. This is then linked back using of_clk_add_provider
to the device node to be accessible by of_clk_get.
FYI, I'm working on moving the OMAP clocks over to DT which is a better
alternative than this patch. I'll share what I have on the list,
hopefully next week.
Regards,
Mike
Based on discussion contributions from Roger Quadros, Grygorii Strashko
and others.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Mike Turquette mturque...@linaro.org
Cc: Paul Walmsley p...@pwsan.com
[t...@atomide.com: co-developed]
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Changes in this version:
- review comments incorporated.
Previous version of this patch was discussed in:
http://marc.info/?t=13658075851r=1w=2
.../devicetree/bindings/clock/omap-clock.txt | 40 +
drivers/clk/Makefile |1 +
drivers/clk/omap/Makefile |1 +
drivers/clk/omap/clk.c | 91
4 files changed, 133 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/omap-clock.txt
create mode 100644 drivers/clk/omap/Makefile
create mode 100644 drivers/clk/omap/clk.c
diff --git a/Documentation/devicetree/bindings/clock/omap-clock.txt
b/Documentation/devicetree/bindings/clock/omap-clock.txt
new file mode 100644
index 000..047c1e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/omap-clock.txt
@@ -0,0 +1,40 @@
+Device Tree Clock bindings for Texas Instrument's OMAP compatible platforms
+
+This binding is an initial minimal binding that may be enhanced as part of
+transitioning OMAP clock data out of kernel image.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be ti,omap-clock
+- #clock-cells : from common clock binding; shall be set to 0.
+NOTE:
+node name should map to clock database in
arch/arm/mach-omap2/cclockSoC_data.c
+Since all clocks are described with _ck, the node name is optimized to drop
the
+usage of _ck. For example, a clock called dpll1_ck will be defined as dpll1.
+
+Example #1: describing clock node for CPU on OMAP34xx platform:
+Ref: arch/arm/mach-omap2/cclock3xxx_data.c
+describes the CPU clock to be as follows
+ CLK(NULL, dpll1_ck, dpll1_ck, CK_3XXX),
+Corresponding binding will be:
+ dpll1: dpll1 {
+ #clock-cells = 0;
+ compatible = ti,omap-clock;
+ };
+And it's usage will be:
+ clocks = dpll1;
+
+Example #2: describing clock node for auxilary clock #3 on OMAP443x platform:
+Ref: arch/arm/mach-omap2/cclock44xx_data.c
+describes the auxclk3 clock to be as follows:
+ CLK(NULL, auxclk3_ck, auxclk3_ck,CK_443X),
+Corresponding binding will be:
+ auxclk3: auxclk3 {
+ #clock-cells = 0;
+ compatible = ti,omap-clock;
+ };
+And it's usage will be:
+ clocks = auxclk3;
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 137d3e7..1d5a2ec 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
obj-$(CONFIG_ARCH_ZYNQ)+= clk-zynq.o
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_PLAT_SAMSUNG) += samsung/
+obj-$(CONFIG_ARCH_OMAP)+= omap/
obj-$(CONFIG_X86) += x86/
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
new file mode 100644
index 000..8195931
--- /dev/null
+++ b/drivers/clk/omap/Makefile
@@ -0,0 +1 @@
+obj-y += clk.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
new file mode 100644
index 000..5a3c6d9
--- /dev/null
+++ b/drivers/clk/omap/clk.c
@@ -0,0 +1,91 @@
+/*
+ * Texas Instruments OMAP Clock driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Nishanth Menon n...@ti.com
+ * Tony Lindgren t...@atomide.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clkdev.h
+#include linux/clk-provider.h
+#include linux/kernel.h
+#include linux/module.h
+#include
[PATCH] arm: configs: omap2plus_defconfig: enable USB bits which work
those USB bits work fine, so we can enable them safely. Plus, without USB_PHY EHCI wouldn't work and it would take quite a few bogus error reports until all users got the new changes. Signed-off-by: Felipe Balbi ba...@ti.com --- comiple tested only. Would be great to have someone testing on actual HW. Right now I don't have access to my HW. cheers arch/arm/configs/omap2plus_defconfig | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index c1ef64b..a1fc0ca 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -74,6 +74,7 @@ CONFIG_CMA=y CONFIG_CONNECTOR=y CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y +CONFIG_OMAP_OCP2SCP=y CONFIG_MTD=y CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_CHAR=y @@ -206,10 +207,18 @@ CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_DEVICEFS=y CONFIG_USB_SUSPEND=y CONFIG_USB_MON=y +CONFIG_USB_EHCI_HCD=y CONFIG_USB_WDM=y CONFIG_USB_STORAGE=y CONFIG_USB_LIBUSUAL=y +CONFIG_USB_DWC3=m +CONFIG_USB_DWC3_DEBUG=y +CONFIG_USB_DWC3_VERBOSE=y CONFIG_USB_TEST=y +CONFIG_USB_PHY=y +CONFIG_NOP_USB_XCEIV=y +CONFIG_OMAP_USB2=y +CONFIG_OMAP_USB3=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_DEBUG=y CONFIG_USB_GADGET_DEBUG_FILES=y -- 1.8.2.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP: AES: Don't idle/start AES device between Encrypt operations
Hi Kevin, have to be created anyway. Imagine encrypting a 20M block- this means runtime PM API is called 20 * 1024 / 4 =~ 5000 times. The slow down in my opinion doesn't make it worth it. What is your opinion about this? OK, I'm not terribly familiar with the crypto API, so I was assuming that the init/exit calls you're instrumenting were happening at driver probe/remove time. Based on your clarifications, that doesn't seem to be the case. My main concern is that drivers don't simply use 'get' on driver probe and 'put' on driver remove and force the system awake as long as the driver is present. I've seen that plenty of times, and I was assuming that's what was going on here. Sorry for the confusion. [Joel] No problem, thanks. Yes, the driver doesn't put/get in the probe functions. Just when it has to do its work. How about just add a few more details to the changelog summarizing how/when the init/exit calls happen to make it a bit more clear. [Joel] Sure, I will make this more clear. Sorry for not doing so earlier. Thanks, Joel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] OMAP: AES: Don't idle/start AES device between Encrypt operations
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 as below.
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.
Before:
root@beagleboard:~# time -v openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 13310 aes-128-cbc's in 0.01s
Doing aes-128-cbc for 3s on 64 size blocks: 13040 aes-128-cbc's in 0.04s
Doing aes-128-cbc for 3s on 256 size blocks: 9134 aes-128-cbc's in 0.03s
Doing aes-128-cbc for 3s on 1024 size blocks: 8939 aes-128-cbc's in 0.01s
Doing aes-128-cbc for 3s on 8192 size blocks: 4299 aes-128-cbc's in 0.00s
After:
root@beagleboard:~# time -v openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 18911 aes-128-cbc's in 0.02s
Doing aes-128-cbc for 3s on 64 size blocks: 18878 aes-128-cbc's in 0.02s
Doing aes-128-cbc for 3s on 256 size blocks: 11878 aes-128-cbc's in 0.10s
Doing aes-128-cbc for 3s on 1024 size blocks: 11538 aes-128-cbc's in 0.05s
Doing aes-128-cbc for 3s on 8192 size blocks: 4857 aes-128-cbc's in 0.03s
While at it, also drop enter and exit pr_debugs, in related code. tracers
can be used for that.
Tested on a Beaglebone (AM335x SoC) board.
Signed-off-by: Joel A Fernandes joelag...@ti.com
---
v2 changes: Clarify usage of runtime PM a bit more in the commit logs.
drivers/crypto/omap-aes.c | 23 +++
1 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 6aa425f..e6474eb 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -208,7 +208,6 @@ static int omap_aes_hw_init(struct omap_aes_dev *dd)
* It may be long delays between requests.
* Device might go to off mode to save power.
*/
- pm_runtime_get_sync(dd-dev);
if (!(dd-flags FLAGS_INIT)) {
dd-flags |= FLAGS_INIT;
@@ -636,7 +635,6 @@ static void omap_aes_finish_req(struct omap_aes_dev *dd,
int err)
pr_debug(err: %d\n, err);
- pm_runtime_put_sync(dd-dev);
dd-flags = ~FLAGS_BUSY;
req-base.complete(req-base, err);
@@ -837,8 +835,16 @@ static int omap_aes_ctr_decrypt(struct ablkcipher_request
*req)
static int omap_aes_cra_init(struct crypto_tfm *tfm)
{
- pr_debug(enter\n);
+ struct omap_aes_dev *dd = NULL;
+
+ /* Find AES device, currently picks the first device */
+ spin_lock_bh(list_lock);
+ list_for_each_entry(dd, dev_list, list) {
+ break;
+ }
+ spin_unlock_bh(list_lock);
+ pm_runtime_get_sync(dd-dev);
tfm-crt_ablkcipher.reqsize = sizeof(struct omap_aes_reqctx);
return 0;
@@ -846,7 +852,16 @@ static int omap_aes_cra_init(struct crypto_tfm *tfm)
static void omap_aes_cra_exit(struct crypto_tfm *tfm)
{
- pr_debug(enter\n);
+ struct omap_aes_dev *dd = NULL;
+
+ /* Find AES device, currently picks the first device */
+ spin_lock_bh(list_lock);
+ list_for_each_entry(dd, dev_list, list) {
+ break;
+ }
+ spin_unlock_bh(list_lock);
+
+ pm_runtime_put_sync(dd-dev);
}
/* ** ALGS */
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
