From: Kevin Hilman <khilman@ti.com>
To: "G, Manjunath Kondaiah" <manjugk@ti.com>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
tony@atomide.com
Subject: Re: [PATCH v2] OMAP: PM: DMA: Enable runtime pm
Date: Mon, 14 Feb 2011 14:06:53 -0800 [thread overview]
Message-ID: <87ipwm1daa.fsf@ti.com> (raw)
In-Reply-To: 1297082286-8449-1-git-send-email-manjugk@ti.com
"G, Manjunath Kondaiah" <manjugk@ti.com> writes:
> From: Manjunath G Kondaiah <manjugk@ti.com>
>
> Enable runtime pm and use pm_runtime_get_sync and pm_runtime_put_autosuspend
> for OMAP DMA driver.
>
> The DMA driver uses auto suspend feature of runtime pm framework through
> which the clock gets disabled automatically if there is no activity for
> more than one second.
>
> Testing:
> Compile: omap1_defconfig and omap2plus_defconfig
> Boot: OMAP1710(H3), OMAP2420(H4), OMAP3630(Zoom3), OMAP4(Blaze)
The normal DMA tests should also be run on these platforms. Based on
the above, I can't tell any DMA tests were run. Based on my tests,
this isn't working for chained xfers.
Using the runtime PM sysfs interface, you can check the runtime status
of the device:
# cat /sys/devices/platform/omap/omap_dma_system.0/power/runtime_status
It should show 'active' during transfer, and after timeout expires it
will show 'suspended'.
Doing some tests using my dmatest module:
git://gitorious.org/omap-test/dmatest.git
I noticed that it gets stuck in 'active' and never gets suspended when I
used DMA channel linking (load module using 'linking=1' as load-time option)
I'm not sure exactly why, but I will guess that the reason is that there
is an imbalance in get/put calls when using chaining, since 'get' is
only called once upon omap_start_dma() but 'put' is called for every
channel in the callback.
> On zoom3 core retention is tested with following steps:
> 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
> echo 5 > /sys/devices/platform/omap/omap_uart.3/sleep_timeout
>
> It is observed that(on pm branch), core retention count gets increasing if the
> board is left idle for more than 5 seconds. However, it doesnot enter off mode
> (even without DMA runtime changes).
What silicon rev is on your Zoom3? Mainline kernels now disable core
off-mode for 3630 revs < ES2.1 due to erratum i583.
If this happens, you should see something like this on the console:
Core OFF disabled due to errata i583
Kevin
> Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
> ---
> arch/arm/plat-omap/dma.c | 27 +++++++++++++++++++++++++++
> 1 files changed, 27 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
> index 2ec3b5d..6bfe25c 100644
> --- a/arch/arm/plat-omap/dma.c
> +++ b/arch/arm/plat-omap/dma.c
> @@ -35,6 +35,7 @@
> #include <linux/io.h>
> #include <linux/slab.h>
> #include <linux/delay.h>
> +#include <linux/pm_runtime.h>
>
> #include <asm/system.h>
> #include <mach/hardware.h>
> @@ -59,6 +60,7 @@ enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED };
>
> static struct omap_system_dma_plat_info *p;
> static struct omap_dma_dev_attr *d;
> +static struct device *dev;
>
> static int enable_1510_mode;
> static u32 errata;
> @@ -676,6 +678,7 @@ int omap_request_dma(int dev_id, const char *dev_name,
> unsigned long flags;
> struct omap_dma_lch *chan;
>
> + pm_runtime_get_sync(dev);
> spin_lock_irqsave(&dma_chan_lock, flags);
> for (ch = 0; ch < dma_chan_count; ch++) {
> if (free_ch == -1 && dma_chan[ch].dev_id == -1) {
> @@ -686,6 +689,7 @@ int omap_request_dma(int dev_id, const char *dev_name,
> }
> if (free_ch == -1) {
> spin_unlock_irqrestore(&dma_chan_lock, flags);
> + pm_runtime_put_autosuspend(dev);
> return -EBUSY;
> }
> chan = dma_chan + free_ch;
> @@ -743,6 +747,7 @@ int omap_request_dma(int dev_id, const char *dev_name,
> }
>
> *dma_ch_out = free_ch;
> + pm_runtime_put_autosuspend(dev);
>
> return 0;
> }
> @@ -871,6 +876,8 @@ void omap_start_dma(int lch)
> {
> u32 l;
>
> + pm_runtime_get_sync(dev);
> +
> /*
> * The CPC/CDAC register needs to be initialized to zero
> * before starting dma transfer.
> @@ -1805,6 +1812,8 @@ static int omap1_dma_handle_ch(int ch)
> if (likely(dma_chan[ch].callback != NULL))
> dma_chan[ch].callback(ch, csr, dma_chan[ch].data);
>
> + pm_runtime_mark_last_busy(dev);
> + pm_runtime_put_autosuspend(dev);
> return 1;
> }
>
> @@ -1899,6 +1908,8 @@ static int omap2_dma_handle_ch(int ch)
> if (likely(dma_chan[ch].callback != NULL))
> dma_chan[ch].callback(ch, status, dma_chan[ch].data);
>
> + pm_runtime_mark_last_busy(dev);
> + pm_runtime_put_autosuspend(dev);
> return 0;
> }
>
> @@ -1978,6 +1989,7 @@ static int __devinit omap_system_dma_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> + dev = &pdev->dev;
> d = p->dma_attr;
> errata = p->errata;
>
> @@ -1999,6 +2011,11 @@ static int __devinit omap_system_dma_probe(struct platform_device *pdev)
> }
> }
>
> + pm_runtime_use_autosuspend(dev);
> + pm_runtime_set_autosuspend_delay(dev, 1000);
> + pm_runtime_enable(dev);
> + pm_runtime_get_sync(dev);
> +
> spin_lock_init(&dma_chan_lock);
> for (ch = 0; ch < dma_chan_count; ch++) {
> omap_clear_dma(ch);
> @@ -2064,6 +2081,16 @@ static int __devinit omap_system_dma_probe(struct platform_device *pdev)
> dma_chan[1].dev_id = 1;
> }
> p->show_dma_caps();
> +
> + /*
> + * Note: If dma channels are reserved through boot paramters,
> + * then dma device is always enabled.
> + */
> + if (omap_dma_reserve_channels)
> + pm_runtime_get(dev);
> +
> + pm_runtime_put_autosuspend(dev);
> +
> return 0;
>
> exit_dma_irq_fail:
WARNING: multiple messages have this Message-ID (diff)
From: khilman@ti.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] OMAP: PM: DMA: Enable runtime pm
Date: Mon, 14 Feb 2011 14:06:53 -0800 [thread overview]
Message-ID: <87ipwm1daa.fsf@ti.com> (raw)
In-Reply-To: 1297082286-8449-1-git-send-email-manjugk@ti.com
"G, Manjunath Kondaiah" <manjugk@ti.com> writes:
> From: Manjunath G Kondaiah <manjugk@ti.com>
>
> Enable runtime pm and use pm_runtime_get_sync and pm_runtime_put_autosuspend
> for OMAP DMA driver.
>
> The DMA driver uses auto suspend feature of runtime pm framework through
> which the clock gets disabled automatically if there is no activity for
> more than one second.
>
> Testing:
> Compile: omap1_defconfig and omap2plus_defconfig
> Boot: OMAP1710(H3), OMAP2420(H4), OMAP3630(Zoom3), OMAP4(Blaze)
The normal DMA tests should also be run on these platforms. Based on
the above, I can't tell any DMA tests were run. Based on my tests,
this isn't working for chained xfers.
Using the runtime PM sysfs interface, you can check the runtime status
of the device:
# cat /sys/devices/platform/omap/omap_dma_system.0/power/runtime_status
It should show 'active' during transfer, and after timeout expires it
will show 'suspended'.
Doing some tests using my dmatest module:
git://gitorious.org/omap-test/dmatest.git
I noticed that it gets stuck in 'active' and never gets suspended when I
used DMA channel linking (load module using 'linking=1' as load-time option)
I'm not sure exactly why, but I will guess that the reason is that there
is an imbalance in get/put calls when using chaining, since 'get' is
only called once upon omap_start_dma() but 'put' is called for every
channel in the callback.
> On zoom3 core retention is tested with following steps:
> 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
> echo 5 > /sys/devices/platform/omap/omap_uart.3/sleep_timeout
>
> It is observed that(on pm branch), core retention count gets increasing if the
> board is left idle for more than 5 seconds. However, it doesnot enter off mode
> (even without DMA runtime changes).
What silicon rev is on your Zoom3? Mainline kernels now disable core
off-mode for 3630 revs < ES2.1 due to erratum i583.
If this happens, you should see something like this on the console:
Core OFF disabled due to errata i583
Kevin
> Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
> ---
> arch/arm/plat-omap/dma.c | 27 +++++++++++++++++++++++++++
> 1 files changed, 27 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
> index 2ec3b5d..6bfe25c 100644
> --- a/arch/arm/plat-omap/dma.c
> +++ b/arch/arm/plat-omap/dma.c
> @@ -35,6 +35,7 @@
> #include <linux/io.h>
> #include <linux/slab.h>
> #include <linux/delay.h>
> +#include <linux/pm_runtime.h>
>
> #include <asm/system.h>
> #include <mach/hardware.h>
> @@ -59,6 +60,7 @@ enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED };
>
> static struct omap_system_dma_plat_info *p;
> static struct omap_dma_dev_attr *d;
> +static struct device *dev;
>
> static int enable_1510_mode;
> static u32 errata;
> @@ -676,6 +678,7 @@ int omap_request_dma(int dev_id, const char *dev_name,
> unsigned long flags;
> struct omap_dma_lch *chan;
>
> + pm_runtime_get_sync(dev);
> spin_lock_irqsave(&dma_chan_lock, flags);
> for (ch = 0; ch < dma_chan_count; ch++) {
> if (free_ch == -1 && dma_chan[ch].dev_id == -1) {
> @@ -686,6 +689,7 @@ int omap_request_dma(int dev_id, const char *dev_name,
> }
> if (free_ch == -1) {
> spin_unlock_irqrestore(&dma_chan_lock, flags);
> + pm_runtime_put_autosuspend(dev);
> return -EBUSY;
> }
> chan = dma_chan + free_ch;
> @@ -743,6 +747,7 @@ int omap_request_dma(int dev_id, const char *dev_name,
> }
>
> *dma_ch_out = free_ch;
> + pm_runtime_put_autosuspend(dev);
>
> return 0;
> }
> @@ -871,6 +876,8 @@ void omap_start_dma(int lch)
> {
> u32 l;
>
> + pm_runtime_get_sync(dev);
> +
> /*
> * The CPC/CDAC register needs to be initialized to zero
> * before starting dma transfer.
> @@ -1805,6 +1812,8 @@ static int omap1_dma_handle_ch(int ch)
> if (likely(dma_chan[ch].callback != NULL))
> dma_chan[ch].callback(ch, csr, dma_chan[ch].data);
>
> + pm_runtime_mark_last_busy(dev);
> + pm_runtime_put_autosuspend(dev);
> return 1;
> }
>
> @@ -1899,6 +1908,8 @@ static int omap2_dma_handle_ch(int ch)
> if (likely(dma_chan[ch].callback != NULL))
> dma_chan[ch].callback(ch, status, dma_chan[ch].data);
>
> + pm_runtime_mark_last_busy(dev);
> + pm_runtime_put_autosuspend(dev);
> return 0;
> }
>
> @@ -1978,6 +1989,7 @@ static int __devinit omap_system_dma_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> + dev = &pdev->dev;
> d = p->dma_attr;
> errata = p->errata;
>
> @@ -1999,6 +2011,11 @@ static int __devinit omap_system_dma_probe(struct platform_device *pdev)
> }
> }
>
> + pm_runtime_use_autosuspend(dev);
> + pm_runtime_set_autosuspend_delay(dev, 1000);
> + pm_runtime_enable(dev);
> + pm_runtime_get_sync(dev);
> +
> spin_lock_init(&dma_chan_lock);
> for (ch = 0; ch < dma_chan_count; ch++) {
> omap_clear_dma(ch);
> @@ -2064,6 +2081,16 @@ static int __devinit omap_system_dma_probe(struct platform_device *pdev)
> dma_chan[1].dev_id = 1;
> }
> p->show_dma_caps();
> +
> + /*
> + * Note: If dma channels are reserved through boot paramters,
> + * then dma device is always enabled.
> + */
> + if (omap_dma_reserve_channels)
> + pm_runtime_get(dev);
> +
> + pm_runtime_put_autosuspend(dev);
> +
> return 0;
>
> exit_dma_irq_fail:
next prev parent reply other threads:[~2011-02-14 22:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-07 12:38 [PATCH v2] OMAP: PM: DMA: Enable runtime pm G, Manjunath Kondaiah
2011-02-07 12:38 ` G, Manjunath Kondaiah
2011-02-10 18:48 ` G, Manjunath Kondaiah
2011-02-10 18:48 ` G, Manjunath Kondaiah
2011-02-14 22:06 ` Kevin Hilman [this message]
2011-02-14 22:06 ` Kevin Hilman
2011-02-16 14:05 ` G, Manjunath Kondaiah
2011-02-16 14:05 ` G, Manjunath Kondaiah
2011-02-16 19:47 ` Kevin Hilman
2011-02-16 19:47 ` Kevin Hilman
2011-02-17 10:20 ` G, Manjunath Kondaiah
2011-02-17 10:20 ` G, Manjunath Kondaiah
2011-02-19 13:39 ` G, Manjunath Kondaiah
2011-02-19 13:39 ` G, Manjunath Kondaiah
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ipwm1daa.fsf@ti.com \
--to=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=manjugk@ti.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.