[PATCH v5 00/14] OMAP: DMA: hwmod and DMA as platform device

[PATCH v5 00/14] OMAP: DMA: hwmod and DMA as platform device

[G, Manjunath Kondaiah]

Hi Tony/Kevin,

* G, Manjunath Kondaiah <manjugk@ti.com> [2010-11-25 16:58:11 +0530]:

> Kevin,
> 
> * G, Manjunath Kondaiah <manjugk@ti.com> [2010-11-24 18:21:36 +0530]:
> 
> > Patch series to convert DMA library into platform driver using platform
> > device model and adapting hwmod for omap2+.
> > 	
> [...]
> > 
> > Patch series applies on top of latest linux omap master branch:
> > *************************************************************************
> > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
> > Branch: master
> > commit 25f7615faa843731af4eda7d05077f1c5132e1a9
> > Merge: 784bee8 8973a21
> > Author: Tony Lindgren <tony@atomide.com>
> > 
> >     Linux-omap rebuilt: Updated to -rc3
> > *************************************************************************
> 
> It also applies cleanly on top of:
> 
> *************************************************************************
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
> Branch: pm-core
> commit 8bcd9727ee126dc50093e84f19dd6c118842202f
> Merge: 632dd87 25f7a1d
> Author: Kevin Hilman <khilman@deeprootsystems.com>
> 
>     Merge branch 'pm-hacks' into pm-reset
>   
> *************************************************************************
Do you have any further comments for this series?

-Manjunath
[...]

[PATCH v5 00/14] OMAP: DMA: hwmod and DMA as platform device

[Tony Lindgren]

Hi,

* G, Manjunath Kondaiah <manjugk@ti.com> [101201 10:53]:
>
> Do you have any further comments for this series?

I'll be looking at it on Thursday.

Tony

[PATCH v5 10/14] OMAP: DMA: Use DMA device attributes

[Tony Lindgren]

* G, Manjunath Kondaiah <manjugk@ti.com> [101124 04:43]:
> Existing DMA API's are using cpu_*is_* checks for differentiating
> omap1 and omap2+ code and handle cpu_*is_* checks with DMA device
> attributes.
> 
> Also, move OMAP1 and OMAP2+ specific API's into respective mach-omap
> dma driver files.

This patch is unreadable and needs to be split.

Also, why are you making duplicate copies of the same generic
functions?

Now you've copied these into mach-omap1/dma.c: 

> +set_src_params(int lch, unsigned long src_start, int src_ei, int src_fi)
> +{
> +	dma_write(src_start, CSSA, lch);
> +
> +	dma_write(src_ei, CSEI, lch);
> +	dma_write(src_fi, CSFI, lch);
> +}
> +
> +static void set_dest_params(int lch, unsigned long dest_start, int dst_ei,
> +								int dst_fi)
> +{
> +	dma_write(dest_start, CDSA, lch);
> +
> +	dma_write(dst_ei, CDEI, lch);
> +	dma_write(dst_fi, CDFI, lch);
> +}
...

And then again the same functions in mach-omap2/dma.c:

> +static void omap2_set_src_params(int lch, unsigned long src_start, int src_ei,
> +								int src_fi)
> +{
> +	dma_write(src_start, CSSA, lch);
> +
> +	dma_write(src_ei, CSEI, lch);
> +	dma_write(src_fi, CSFI, lch);
> +}
> +
> +static void omap2_set_dest_params(int lch, unsigned long dest_start, int dst_ei,
> +								int dst_fi)
> +{
> +	dma_write(dest_start, CDSA, lch);
> +
> +	dma_write(dst_ei, CDEI, lch);
> +	dma_write(dst_fi, CDFI, lch);
> +}
...

All the common functions should stay in plat-omap/dma.c.

Rgards,

Tony

[PATCH v5 10/14] OMAP: DMA: Use DMA device attributes

[G, Manjunath Kondaiah]

On Thu, Dec 02, 2010 at 09:07:25AM -0800, Tony Lindgren wrote:
> * G, Manjunath Kondaiah <manjugk@ti.com> [101124 04:43]:
> > Existing DMA API's are using cpu_*is_* checks for differentiating
> > omap1 and omap2+ code and handle cpu_*is_* checks with DMA device
> > attributes.
> > 
> > Also, move OMAP1 and OMAP2+ specific API's into respective mach-omap
> > dma driver files.
> 
> This patch is unreadable and needs to be split.

I can split this patch as:
1. all chaining related API movement in one patch.
2. Rest of the changes in second patch.

> 
> Also, why are you making duplicate copies of the same generic
> functions?
> 
> Now you've copied these into mach-omap1/dma.c: 
> 
> > +set_src_params(int lch, unsigned long src_start, int src_ei, int src_fi)
> > +{
> > +	dma_write(src_start, CSSA, lch);
> > +
> > +	dma_write(src_ei, CSEI, lch);
> > +	dma_write(src_fi, CSFI, lch);
> > +}
> > +
> > +static void set_dest_params(int lch, unsigned long dest_start, int dst_ei,
> > +								int dst_fi)
> > +{
> > +	dma_write(dest_start, CDSA, lch);
> > +
> > +	dma_write(dst_ei, CDEI, lch);
> > +	dma_write(dst_fi, CDFI, lch);
> > +}
> ...
> 
> And then again the same functions in mach-omap2/dma.c:

Earlier, handling of CSSA and CDSA was different because 16 bit
registers vs 32 bit registers. Now, with latest patch series, all the
registers are handled inside functions, these API's can be retained in
plat-omap.

> 
> > +static void omap2_set_src_params(int lch, unsigned long src_start, int src_ei,
> > +								int src_fi)
> > +{
> > +	dma_write(src_start, CSSA, lch);
> > +
> > +	dma_write(src_ei, CSEI, lch);
> > +	dma_write(src_fi, CSFI, lch);
> > +}
> > +
> > +static void omap2_set_dest_params(int lch, unsigned long dest_start, int dst_ei,
> > +								int dst_fi)
> > +{
> > +	dma_write(dest_start, CDSA, lch);
> > +
> > +	dma_write(dst_ei, CDEI, lch);
> > +	dma_write(dst_fi, CDFI, lch);
> > +}
> ...
> 
> All the common functions should stay in plat-omap/dma.c.
I agree.

-Manjunath

[PATCH v5 09/14] OMAP: DMA: Convert DMA library into platform driver

[Tony Lindgren]

* G, Manjunath Kondaiah <manjugk@ti.com> [101124 04:42]:
> Convert DMA library into DMA platform driver and make use of
> platform data provided by hwmod data base for OMAP2+ onwards.
> 
> For OMAP1 processors, the DMA driver in mach-omap uses resource
> structures for getting platform data.

And has never been tested..

<snip>

>  static int __init omap1_system_dma_init(void)
>  {
>  	struct omap_system_dma_plat_info	*p;
> +	struct omap_dma_dev_attr		*d;
>  	struct platform_device			*pdev;
>  	int ret;
>  
> @@ -153,22 +295,74 @@ static int __init omap1_system_dma_init(void)
>  		goto exit_device_put;
>  	}
>  
> +	d = p->dma_attr;

This fails on omap1 as d is not allocated. Please merge the
following fix.

Tony


From: Tony Lindgren <tony@atomide.com>
Date: Thu, 2 Dec 2010 10:02:08 -0800
Subject: [PATCH] Fix dma init for omap1

Fix dma init for omap1

Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -295,13 +295,20 @@ static int __init omap1_system_dma_init(void)
 		goto exit_device_put;
 	}
 
-	d = p->dma_attr;
+	d = kzalloc(sizeof(struct omap_dma_dev_attr), GFP_KERNEL);
+	if (!d) {
+		dev_err(&pdev->dev, "%s: Unable to allocate 'd' for %s\n",
+			__func__, pdev->name);
+		ret = -ENOMEM;
+		goto exit_release_p;
+	}
+
 	d->chan = kzalloc(sizeof(struct omap_dma_lch) *
 					(d->lch_count), GFP_KERNEL);
 	if (!d->chan) {
 		dev_err(&pdev->dev, "%s: Memory allocation failed"
 					"for d->chan!!!\n", __func__);
-		goto exit_release_p;
+		goto exit_release_d;
 	}
 
 	/* Valid attributes for omap1 plus processors */
@@ -328,6 +335,8 @@ static int __init omap1_system_dma_init(void)
 			d->chan_count = 9;
 	}
 
+	p->dma_attr = d;
+
 	dma_base		= (void __iomem *)res[0].start;
 
 	p->show_dma_caps	= omap1_show_dma_caps;
@@ -361,6 +370,8 @@ static int __init omap1_system_dma_init(void)
 
 exit_release_chan:
 	kfree(d->chan);
+exit_release_d:
+	kfree(d);
 exit_release_p:
 	kfree(p);
 exit_device_put:

[PATCH v5 09/14] OMAP: DMA: Convert DMA library into platform driver

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [101202 10:34]:
> 
> This fails on omap1 as d is not allocated. Please merge the
> following fix.

And another fix here:

From: Tony Lindgren <tony@atomide.com>
Date: Thu, 2 Dec 2010 10:19:15 -0800
Subject: [PATCH] Fix omap1_system_dma_init to use ioremap

Fix omap1_system_dma_init to use ioremap

Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -280,6 +280,12 @@ static int __init omap1_system_dma_init(void)
 		return -ENOMEM;
 	}
 
+	dma_base = ioremap(res[0].start, resource_size(&res[0]));
+	if (!dma_base) {
+		pr_err("%s: Unable to ioremap\n", __func__);
+		return -ENODEV;
+	}
+
 	ret = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
 	if (ret) {
 		dev_err(&pdev->dev, "%s: Unable to add resources for %s%d\n",
@@ -337,8 +343,6 @@ static int __init omap1_system_dma_init(void)
 
 	p->dma_attr = d;
 
-	dma_base		= (void __iomem *)res[0].start;
-
 	p->show_dma_caps	= omap1_show_dma_caps;
 	p->clear_lch_regs	= omap1_clear_lch_regs;
 	p->clear_dma		= omap1_clear_dma;

[PATCH v5 09/14] OMAP: DMA: Convert DMA library into platform driver

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [101202 10:36]:
> * Tony Lindgren <tony@atomide.com> [101202 10:34]:
> > 
> > This fails on omap1 as d is not allocated. Please merge the
> > following fix.
> 
> And another fix here:

One more fix below.

Note that even with these three fixes, 5912OSK still fails to
boot to init. Maybe something wrong with the framebuffer DMA?

Tony


From: Tony Lindgren <tony@atomide.com>
Date: Thu, 2 Dec 2010 10:34:18 -0800
Subject: [PATCH] Fix omap1_system_dma_init to initialize d->lch_count earlier

Otherwise the kzalloc will allocate wrong amount of memory.

Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -309,13 +309,7 @@ static int __init omap1_system_dma_init(void)
 		goto exit_release_p;
 	}
 
-	d->chan = kzalloc(sizeof(struct omap_dma_lch) *
-					(d->lch_count), GFP_KERNEL);
-	if (!d->chan) {
-		dev_err(&pdev->dev, "%s: Memory allocation failed"
-					"for d->chan!!!\n", __func__);
-		goto exit_release_d;
-	}
+	d->lch_count		= OMAP1_LOGICAL_DMA_CH_COUNT;
 
 	/* Valid attributes for omap1 plus processors */
 	if (cpu_is_omap15xx())
@@ -330,7 +324,14 @@ static int __init omap1_system_dma_init(void)
 	d->dev_caps		|= CLEAR_CSR_ON_READ;
 	d->dev_caps		|= IS_WORD_16;
 
-	d->lch_count		= OMAP1_LOGICAL_DMA_CH_COUNT;
+
+	d->chan = kzalloc(sizeof(struct omap_dma_lch) *
+					(d->lch_count), GFP_KERNEL);
+	if (!d->chan) {
+		dev_err(&pdev->dev, "%s: Memory allocation failed"
+					"for d->chan!!!\n", __func__);
+		goto exit_release_d;
+	}
 
 	if (cpu_is_omap15xx())
 		d->chan_count = 9;

[PATCH v5 09/14] OMAP: DMA: Convert DMA library into platform driver

[G, Manjunath Kondaiah]

On Thu, Dec 02, 2010 at 10:49:25AM -0800, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [101202 10:36]:
> > * Tony Lindgren <tony@atomide.com> [101202 10:34]:
> > > 
> > > This fails on omap1 as d is not allocated. Please merge the
> > > following fix.
> > 
> > And another fix here:
> 
> One more fix below.

Thanks. I will merge these fixes.

> 
> Note that even with these three fixes, 5912OSK still fails to
> boot to init. Maybe something wrong with the framebuffer DMA?

Not sure. I don't have omap1 board for testing. Patch series is only 
build tested for omap1.

Can you pls confirm if OSK5912 boots successfully without this patch
series?

If yes, I will cross verify omap1 changes again.

-Manjunath

[PATCH v5 09/14] OMAP: DMA: Convert DMA library into platform driver

[Tony Lindgren]

* G, Manjunath Kondaiah <manjugk@ti.com> [101202 11:55]:
> 
> > 
> > Note that even with these three fixes, 5912OSK still fails to
> > boot to init. Maybe something wrong with the framebuffer DMA?
> 
> Not sure. I don't have omap1 board for testing. Patch series is only 
> build tested for omap1.
> 
> Can you pls confirm if OSK5912 boots successfully without this patch
> series?

Yeah boots just fine without these as always.

Anybody care to donate a OSK5912 or similar for the TI guys
for doing quick omap1 boot testing on?
 
> If yes, I will cross verify omap1 changes again.

Found the problem. INT_DMA_LCD is handled in mach-omap1/lcd_dma.c.
In your omap_system_dma_probe we now exit everything if request_irq
fails for one channel. So let's skip INT_DMA_LCD.

Also, you should check the logic in omap_system_dma_probe as it's
not very good handling right now. Note how platform_get_irq_byname
does not free other dma_irqs like after request_irq we do.

With your patches applied up to patch "Convert DMA library into
platform driver" + my three earlie fixes + the following fix
I can now boot OSK5912 and see the penguin on the LCD too.

I suggest you break your series into two where the last patch
in the first series is "Convert DMA library into platform driver".
That way the init related changes are done, and we can merge
those in for testing while you update the rest of the series.

Also, eventually within next few merge cycles we should have:

arch/arm/mach-omap1/dma.c	omap1 specific platform init
arch/arm/mach-omap2/dma.c	omap2+ specific platform init
drivers/dma/omap-dma.c		driver using dmaengine.c

So before continuing beyond "Convert DMA library into platform
driver" in the series, maybe take a quick look at dmaengine
in drivers/dma/ so we don't have to redo tons of things again
later on.

Regards,

Tony


From: Tony Lindgren <tony@atomide.com>
Date: Thu, 2 Dec 2010 12:35:02 -0800
Subject: [PATCH] Fix omap_system_dma_probe for omap1 INT_DMA_LCD

We don't want to request it as it's handled by mach-omap1/lcd_dma.c.

Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -118,6 +118,7 @@ static struct resource res[] __initdata = {
 		.start  = INT_DMA_CH5,
 		.flags  = IORESOURCE_IRQ,
 	},
+	/* Handled in lcd_dma.c */
 	[7] = {
 		.name   = "6",
 		.start  = INT_DMA_LCD,
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -2025,6 +2025,11 @@ static int __devinit omap_system_dma_probe(struct platform_device *pdev)
 				ret = dma_irq;
 				goto exit_dma_chan;
 			}
+
+			/* INT_DMA_LCD is handled in lcd_dma.c */
+			if (dma_irq == INT_DMA_LCD)
+				continue;
+
 			ret = request_irq(dma_irq,
 					omap1_dma_irq_handler, 0, "DMA",
 					(void *) (ch + 1));

[PATCH v5 09/14] OMAP: DMA: Convert DMA library into platform driver

[G, Manjunath Kondaiah]

Hi Tony,

* Tony Lindgren <tony@atomide.com> [2010-12-02 12:52:19 -0800]:

> * G, Manjunath Kondaiah <manjugk@ti.com> [101202 11:55]:
> > 
> > > 
> > > Note that even with these three fixes, 5912OSK still fails to
> > > boot to init. Maybe something wrong with the framebuffer DMA?
> > 
> > Not sure. I don't have omap1 board for testing. Patch series is only 
> > build tested for omap1.
> > 
> > Can you pls confirm if OSK5912 boots successfully without this patch
> > series?
> 
> Yeah boots just fine without these as always.
> 
> Anybody care to donate a OSK5912 or similar for the TI guys
> for doing quick omap1 boot testing on?
>  
> > If yes, I will cross verify omap1 changes again.
> 
> Found the problem. INT_DMA_LCD is handled in mach-omap1/lcd_dma.c.
> In your omap_system_dma_probe we now exit everything if request_irq
> fails for one channel. So let's skip INT_DMA_LCD.
> 
> Also, you should check the logic in omap_system_dma_probe as it's
> not very good handling right now. Note how platform_get_irq_byname
> does not free other dma_irqs like after request_irq we do.

Fixed error handling cases.

> 
> With your patches applied up to patch "Convert DMA library into
> platform driver" + my three earlie fixes + the following fix
> I can now boot OSK5912 and see the penguin on the LCD too.

Thanks a lot. I pulled in all these fixes into the patch series.

> 
> I suggest you break your series into two where the last patch
> in the first series is "Convert DMA library into platform driver".

I am ok with this approach.

> That way the init related changes are done, and we can merge
> those in for testing while you update the rest of the series.

cool.

I have done required changes to patch series and tested the same on
omap2+ boards. Can you pls test OSK5912 board boot from the below
git repo? If OSK5912 boots up(with LCD), I will post the 1st series to
LO ML.

git://dev.omapzoom.org/pub/scm/manju/kernel-omap3-dev.git
Branch: dma_testing
commit 3047de5b11cc3fef9ea18a7e8d64fec7a9ea7a89
Author: G, Manjunath Kondaiah <manjugk@ti.com>
Date:   Fri Dec 3 20:03:23 2010 +0530

    OMAP: DMA: Convert DMA library into platform driver
    
    Convert DMA library into DMA platform driver and make use of
    platform data provided by hwmod data base for OMAP2+ onwards.
    
    For OMAP1 processors, the DMA driver in mach-omap uses resource
    structures for getting platform data.
    
    Thanks to Tony Lindgren <tony@atomide.com> for fixing various
    omap1 issues and testing the same on OSK5912 board.
    
    Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Cc: Benoit Cousson <b-cousson@ti.com>
    Cc: Kevin Hilman <khilman@deeprootsystems.com>
    Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>

> 
> Also, eventually within next few merge cycles we should have:
> 
> arch/arm/mach-omap1/dma.c	omap1 specific platform init
> arch/arm/mach-omap2/dma.c	omap2+ specific platform init

This seems to be ok.

> drivers/dma/omap-dma.c		driver using dmaengine.c

This might require more time.

-Manjunath

[PATCH v5 09/14] OMAP: DMA: Convert DMA library into platform driver

[Tony Lindgren]

* G, Manjunath Kondaiah <manjugk@ti.com> [101203 08:32]:
> 
> I have done required changes to patch series and tested the same on
> omap2+ boards. Can you pls test OSK5912 board boot from the below
> git repo? If OSK5912 boots up(with LCD), I will post the 1st series to
> LO ML.

Yeah seems to boot OK now with tux showing up too.

Tony

[PATCH v5 09/14] OMAP: DMA: Convert DMA library into platform driver

[G, Manjunath Kondaiah]

Hi Tony,

On Fri, Dec 3, 2010 at 10:13 PM, G, Manjunath Kondaiah <manjugk@ti.com> wrote:
> Hi Tony,
>
> * Tony Lindgren <tony@atomide.com> [2010-12-02 12:52:19 -0800]:
>
>> * G, Manjunath Kondaiah <manjugk@ti.com> [101202 11:55]:
>> >
>> > >
>> > > Note that even with these three fixes, 5912OSK still fails to
>> > > boot to init. Maybe something wrong with the framebuffer DMA?
>> >
>> > Not sure. I don't have omap1 board for testing. Patch series is only
>> > build tested for omap1.
>> >
>> > Can you pls confirm if OSK5912 boots successfully without this patch
>> > series?
>>
>> Yeah boots just fine without these as always.
>>
>> Anybody care to donate a OSK5912 or similar for the TI guys
>> for doing quick omap1 boot testing on?
>>
>> > If yes, I will cross verify omap1 changes again.
>>
>> Found the problem. INT_DMA_LCD is handled in mach-omap1/lcd_dma.c.
>> In your omap_system_dma_probe we now exit everything if request_irq
>> fails for one channel. So let's skip INT_DMA_LCD.
>>
>> Also, you should check the logic in omap_system_dma_probe as it's
>> not very good handling right now. Note how platform_get_irq_byname
>> does not free other dma_irqs like after request_irq we do.
>
> Fixed error handling cases.
>
>>
>> With your patches applied up to patch "Convert DMA library into
>> platform driver" + my three earlie fixes + the following fix
>> I can now boot OSK5912 and see the penguin on the LCD too.
>
> Thanks a lot. I pulled in all these fixes into the patch series.
>
>>
>> I suggest you break your series into two where the last patch
>> in the first series is "Convert DMA library into platform driver".
>
> I am ok with this approach.
>
>> That way the init related changes are done, and we can merge
>> those in for testing while you update the rest of the series.
>
> cool.
>
> I have done required changes to patch series and tested the same on
> omap2+ boards. Can you pls test OSK5912 board boot from the below
> git repo? If OSK5912 boots up(with LCD), I will post the 1st series to
> LO ML.
>
> git://dev.omapzoom.org/pub/scm/manju/kernel-omap3-dev.git
> Branch: dma_testing
> commit 3047de5b11cc3fef9ea18a7e8d64fec7a9ea7a89
> Author: G, Manjunath Kondaiah <manjugk@ti.com>
> Date: ? Fri Dec 3 20:03:23 2010 +0530
>
> ? ?OMAP: DMA: Convert DMA library into platform driver
>
> ? ?Convert DMA library into DMA platform driver and make use of
> ? ?platform data provided by hwmod data base for OMAP2+ onwards.
>
> ? ?For OMAP1 processors, the DMA driver in mach-omap uses resource
> ? ?structures for getting platform data.
>
> ? ?Thanks to Tony Lindgren <tony@atomide.com> for fixing various
> ? ?omap1 issues and testing the same on OSK5912 board.
>
> ? ?Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
> ? ?Signed-off-by: Tony Lindgren <tony@atomide.com>
> ? ?Cc: Benoit Cousson <b-cousson@ti.com>
> ? ?Cc: Kevin Hilman <khilman@deeprootsystems.com>
> ? ?Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
>>
>> Also, eventually within next few merge cycles we should have:
>>
>> arch/arm/mach-omap1/dma.c ? ? omap1 specific platform init
>> arch/arm/mach-omap2/dma.c ? ? omap2+ specific platform init
>
> This seems to be ok.
>
>> drivers/dma/omap-dma.c ? ? ? ? ? ? ? ?driver using dmaengine.c
>
> This might require more time.

Since this will take more time, can we have run time pm changes on top
of existing dma hwmod changes?
If so, I can pull out run time pm patch from the dma hwmod series and
resend it again.

-Manjunath

[PATCH v5 09/14] OMAP: DMA: Convert DMA library into platform driver

[Tony Lindgren]

* G, Manjunath Kondaiah <manjugk@ti.com> [110113 03:19]:
> >
> >>
> >> Also, eventually within next few merge cycles we should have:
> >>
> >> arch/arm/mach-omap1/dma.c ? ? omap1 specific platform init
> >> arch/arm/mach-omap2/dma.c ? ? omap2+ specific platform init
> >
> > This seems to be ok.
> >
> >> drivers/dma/omap-dma.c ? ? ? ? ? ? ? ?driver using dmaengine.c
> >
> > This might require more time.
> 
> Since this will take more time, can we have run time pm changes on top
> of existing dma hwmod changes?
> If so, I can pull out run time pm patch from the dma hwmod series and
> resend it again.

Sure. That will make it easier to convert it to use dmaengine
eventually.

Tony