Re: [PATCH v2] OMAP: PM: DMA: Enable runtime pm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Feb 14, 2011 at 02:06:53PM -0800, Kevin Hilman wrote:
> "G, Manjunath Kondaiah" <manjugk@xxxxxx> writes:
> 
> > From: Manjunath G Kondaiah <manjugk@xxxxxx>
> >
> > 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.

found this issue and fixed. It was due to chain handling in interrupt
handler. Since get_sync used only in omap_start_dma for 1st transfer and there
will be no omap_start_dma for second transfer onwards since it will be linked
through chaining in interrupt handler. Here is the fix.

@@ -1895,8 +2002,11 @@ static int omap2_dma_handle_ch(int ch)
                                                OMAP_DMA_DYNAMIC_CHAIN)
                        disable_lnk(ch);
 
-               if (!OMAP_DMA_CHAIN_QEMPTY(chain_id))
+               if (!OMAP_DMA_CHAIN_QEMPTY(chain_id)) {
                        OMAP_DMA_CHAIN_INCQHEAD(chain_id);
+                       pm_runtime_get_sync(dev);
+               }
+
 
                status = p->dma_read(CSR, ch);
                p->dma_write(status, CSR, ch);

-Manjunath

> 
> > 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@xxxxxx>
> > ---
> >  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:
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux