From: Kevin Hilman <hidden> Date: 2011-03-03 18:35:23
"G, Manjunath Kondaiah" [off-list ref] writes:
This patch series is remaining part of dma hwmod to support pm runtime
and for handling mstandby mode for all applicable DMA mstandby mode errata.
This is still not runtime-suspending when I use my DMA test in linking
mode.
If I put a large enough period between transfers, it should autosuspend
during transfers. It seems to do auto-suspend and resume once, but then
it never suspends again.
I tested with my dmatest module[1], and loaded with:
# insmod ./dmatest.ko linking=1 forever=1 forever_period=1024
Not only does it not auto-suspend between transfers (which I expected),
it also doesn't suspend after removing the module which stops all active
channels.
Kevin
[1] git://gitorious.org/omap-test/dmatest.git
The alignment for pm runtime API's usage is at:
http://thread.gmane.org/gmane.linux.ports.arm.omap/51588/focus=52493http://thread.gmane.org/gmane.linux.ports.arm.omap/50762/focus=50840
The alignment for handling mstandby mode errata handling is at:
http://thread.gmane.org/gmane.linux.ports.arm.omap/47398/focus=47426http://thread.gmane.org/gmane.linux.ports.arm.omap/47479/focus=47537
Testing:
Compile tested for
- omap1_defconfig
- omap2plus_defconfig
Boot test on:
- OMAP1710-H3
- OMAP2420-H4
- OMAP3430-LDP
- OMAP3630-Zoom3
- OMAP4430-Blaze
DMA memory to memory test cases(including chaining) are executed for
all the above boards and for each test case,
/sys/devices/platform/omap/omap_dma_system.0/power/runtime_status
was verified and after completion of the tests, runtime_status will be
always suspended.
Apart from that, offmode testing is done for OMAP3430-LDP using the procedure:
echo 1 > /debug/pm_debug/sleep_while_idle
echo 1 > /debug/pm_debug/enable_off_mode
echo 5 > /sys/devices/platform/omap/omap_uart.0/sleep_timeout
echo 5 > /sys/devices/platform/omap/omap_uart.1/sleep_timeout
echo 5 > /sys/devices/platform/omap/omap_uart.2/sleep_timeout
With the above steps, core off mode count gets increasing if the the board
is idle for more than 5 seconds.
Baseline:
Applies cleanly on top of mainline 2.6.38-rc6:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
commit f5412be599602124d2bdd49947b231dd77c0bf99
Author: Linus Torvalds [off-list ref]
Date: Mon Feb 21 17:25:52 2011 -0800
Linux 2.6.38-rc6
Note: OMAP1 is tested on top of 2.6.38-rc5 since rc6 is broken for omap1 build
Patch Summary:
==============
G, Manjunath Kondaiah (2):
OMAP2+: PM: omap device: API's for handling mstandby mode
OMAP2+: DMA: prevent races while setting M idle mode to nostandby
Manjunath G Kondaiah (1):
OMAP: PM: DMA: Enable runtime pm
arch/arm/mach-omap1/dma.c | 1 +
arch/arm/mach-omap2/dma.c | 16 ++
arch/arm/mach-omap2/omap_hwmod.c | 42 ++++++
arch/arm/plat-omap/dma.c | 190 +++++++++++++++++++++----
arch/arm/plat-omap/include/plat/dma.h | 1 +
arch/arm/plat-omap/include/plat/omap_device.h | 2 +
arch/arm/plat-omap/include/plat/omap_hwmod.h | 4 +-
arch/arm/plat-omap/omap_device.c | 64 +++++++++
8 files changed, 293 insertions(+), 27 deletions(-)
On Thu, Mar 03, 2011 at 10:35:23AM -0800, Kevin Hilman wrote:
"G, Manjunath Kondaiah" [off-list ref] writes:
quoted
This patch series is remaining part of dma hwmod to support pm runtime
and for handling mstandby mode for all applicable DMA mstandby mode errata.
This is still not runtime-suspending when I use my DMA test in linking
mode.
If I put a large enough period between transfers, it should autosuspend
during transfers. It seems to do auto-suspend and resume once, but then
it never suspends again.
I tested with my dmatest module[1], and loaded with:
# insmod ./dmatest.ko linking=1 forever=1 forever_period=1024
Not only does it not auto-suspend between transfers (which I expected),
it also doesn't suspend after removing the module which stops all active
channels.
The normal chaining test cases are executed and which used to show the
proper status. Let me reproduce this issue with your test procedure.
Sorry. It's OMAP3430 Zoom2 and not LDP.
-Manjunath
quoted
- OMAP3630-Zoom3
- OMAP4430-Blaze
DMA memory to memory test cases(including chaining) are executed for
all the above boards and for each test case,
/sys/devices/platform/omap/omap_dma_system.0/power/runtime_status
was verified and after completion of the tests, runtime_status will be
always suspended.
Apart from that, offmode testing is done for OMAP3430-LDP using the procedure:
echo 1 > /debug/pm_debug/sleep_while_idle
echo 1 > /debug/pm_debug/enable_off_mode
echo 5 > /sys/devices/platform/omap/omap_uart.0/sleep_timeout
echo 5 > /sys/devices/platform/omap/omap_uart.1/sleep_timeout
echo 5 > /sys/devices/platform/omap/omap_uart.2/sleep_timeout
With the above steps, core off mode count gets increasing if the the board
is idle for more than 5 seconds.
Baseline:
Applies cleanly on top of mainline 2.6.38-rc6:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
commit f5412be599602124d2bdd49947b231dd77c0bf99
Author: Linus Torvalds [off-list ref]
Date: Mon Feb 21 17:25:52 2011 -0800
Linux 2.6.38-rc6
Note: OMAP1 is tested on top of 2.6.38-rc5 since rc6 is broken for omap1 build
Patch Summary:
==============
G, Manjunath Kondaiah (2):
OMAP2+: PM: omap device: API's for handling mstandby mode
OMAP2+: DMA: prevent races while setting M idle mode to nostandby
Manjunath G Kondaiah (1):
OMAP: PM: DMA: Enable runtime pm
arch/arm/mach-omap1/dma.c | 1 +
arch/arm/mach-omap2/dma.c | 16 ++
arch/arm/mach-omap2/omap_hwmod.c | 42 ++++++
arch/arm/plat-omap/dma.c | 190 +++++++++++++++++++++----
arch/arm/plat-omap/include/plat/dma.h | 1 +
arch/arm/plat-omap/include/plat/omap_device.h | 2 +
arch/arm/plat-omap/include/plat/omap_hwmod.h | 4 +-
arch/arm/plat-omap/omap_device.c | 64 +++++++++
8 files changed, 293 insertions(+), 27 deletions(-)
On Fri, Mar 04, 2011 at 09:48:26AM +0530, G, Manjunath Kondaiah wrote:
On Thu, Mar 03, 2011 at 10:35:23AM -0800, Kevin Hilman wrote:
quoted
"G, Manjunath Kondaiah" [off-list ref] writes:
quoted
This patch series is remaining part of dma hwmod to support pm runtime
and for handling mstandby mode for all applicable DMA mstandby mode errata.
This is still not runtime-suspending when I use my DMA test in linking
mode.
If I put a large enough period between transfers, it should autosuspend
during transfers. It seems to do auto-suspend and resume once, but then
it never suspends again.
I tested with my dmatest module[1], and loaded with:
# insmod ./dmatest.ko linking=1 forever=1 forever_period=1024
Not only does it not auto-suspend between transfers (which I expected),
it also doesn't suspend after removing the module which stops all active
channels.
The normal chaining test cases are executed and which used to show the
proper status. Let me reproduce this issue with your test procedure.
ok. I am able to reproduce this issue and fixed _get_sync usage in
omap_start_dma if channel linking is used. Earlier it was handled for
the cases with chaining API's. If linking is done without chaining
API's, it will result in _get_sync and _put mismatch.
Thanks for the test case and I will be re posting the patches with the
above fix.
-Manjunath
On Mon, Mar 07, 2011 at 04:36:12PM +0530, G, Manjunath Kondaiah wrote:
On Fri, Mar 04, 2011 at 09:48:26AM +0530, G, Manjunath Kondaiah wrote:
quoted
On Thu, Mar 03, 2011 at 10:35:23AM -0800, Kevin Hilman wrote:
quoted
"G, Manjunath Kondaiah" [off-list ref] writes:
quoted
This patch series is remaining part of dma hwmod to support pm runtime
and for handling mstandby mode for all applicable DMA mstandby mode errata.
This is still not runtime-suspending when I use my DMA test in linking
mode.
If I put a large enough period between transfers, it should autosuspend
during transfers. It seems to do auto-suspend and resume once, but then
it never suspends again.
I tested with my dmatest module[1], and loaded with:
# insmod ./dmatest.ko linking=1 forever=1 forever_period=1024
Not only does it not auto-suspend between transfers (which I expected),
it also doesn't suspend after removing the module which stops all active
channels.
The normal chaining test cases are executed and which used to show the
proper status. Let me reproduce this issue with your test procedure.
ok. I am able to reproduce this issue and fixed _get_sync usage in
omap_start_dma if channel linking is used. Earlier it was handled for
the cases with chaining API's. If linking is done without chaining
API's, it will result in _get_sync and _put mismatch.
Thanks for the test case and I will be re posting the patches with the
above fix.
While testing your test case with off mode for scenario:
insmod ./dmatest.ko linking=1 forever=1 forever_period=1024 debug=1
the transfer after timer expiry will get corrupted once it comes out of
off mode. Debugging offmode issue...
Trying to use omap_pm_get_dev_context_loss_count(dev) for checking
offmode count for context restore in omap_start_dma.
-Manjunath