[PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

[PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

[Gupta, Ajay Kumar]

> Hello.
> Russell King - ARM Linux wrote:
>>>>Is there any updated patch on cppi4.1 core also?
>>>Is there _any_ cppi4.1 core patch anywhere?? Not according to google.
>>Russell,
>>Here is the latest ersion of cppi4.1 core.
>>http://patchwork.kernel.org/patch/46698/

>> [...]

>>>If it's a USB DMA device (from the patches I can find, that seems to be
>>>the case) then why can't it live in drivers/usb or drivers/dma ?
>>
>>CPPI4.1 DMA engine can be used either by USB or by Ethernet interface though
>>currently only USB is using it but in future even Ethernet devices may use it.

> drivers/dma does seem to be the right place for this.

>??? Russell, it makes me wonder why drivers/dma/ seemed the right place to 
> you, just because of the name? :-)
>??? After spending some time on studying the infrastructure there I came to 
> conclusion that this is not the right place because all the controllers 
> supported there have features like memory-to-memory transfers or even RAID 
> function offloading -- which CPPI 4.1 totally lacks (it's there purely to 
> serve the peripherals).
>??? Adding drivers/dma/ people to this discussion in hopes they can correct 
> me (or support me :-)...

As this discussion is taking time which is affecting the further
development and bug fixes on CPPI4.1. 

So can we move CPPI4.1 files to drivers/usb/musb for time being and submit
a replacement patch whenever we all agree on the location of CPPI4.1
related files.

-Ajay

> WBR, Sergei
> --

[PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

[Felipe Balbi]

Hi,

On Tue, Dec 29, 2009 at 09:43:49AM +0100, ext Gupta, Ajay Kumar wrote:
>As this discussion is taking time which is affecting the further
>development and bug fixes on CPPI4.1.
>
>So can we move CPPI4.1 files to drivers/usb/musb for time being and submit
>a replacement patch whenever we all agree on the location of CPPI4.1
>related files.

problem is that once it's applied, no-one seems to care anymore. And 
it'll be there for good. Better is to decide what really is the correct 
place for this otherwise it'll be like tusb6010_omap.c

-- 
balbi

[PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

[Subbrathnam, Swaminathan]

Felipe,

We have been on this front months together now!!! Ideally the place holder would be a place independant of platforms as this piece of code is more of a platform independant library relating to TI CPPI DMA operations.  This would be used during initialization and confiuration  of CPPI4.x based peripherals.  Though today USB is the only peripheral that falls in that catagory ideally other like TI EMAC could fall in the same space.

Having said that I also see that there seems to be no roadmap/plan for any other peripheral other than USB to use CPPI4.x in the near future.  TI EMAC seems to continue use CPPI3.x.

This was the reason I had recommended earlier to locate this generic CPPI 4.x functionality within MUSB.  This definitely helps in having a functional peripheral in the near (and most probably long) term.

I think it is prudent to locate this functionality in the musb directory for now.  In future if need arises we can relook at this later (I am sure this in all probabilities would not be required).

In either way I would really appreiciate if we can come to a conclusion at the earliest.  Appreciate everybody's feedback and direction.

regards
swami

________________________________________
From: Felipe Balbi [felipe.balbi at nokia.com]
Sent: Tuesday, December 29, 2009 6:24 PM
To: Gupta, Ajay Kumar
Cc: linux-usb at vger.kernel.org; linux-arm-kernel at lists.infradead.org; Sergei Shtylyov; Balbi Felipe (Nokia-D/Helsinki); Subbrathnam, Swaminathan
Subject: Re: [PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

Hi,

On Tue, Dec 29, 2009 at 09:43:49AM +0100, ext Gupta, Ajay Kumar wrote:
>As this discussion is taking time which is affecting the further
>development and bug fixes on CPPI4.1.
>
>So can we move CPPI4.1 files to drivers/usb/musb for time being and submit
>a replacement patch whenever we all agree on the location of CPPI4.1
>related files.

problem is that once it's applied, no-one seems to care anymore. And
it'll be there for good. Better is to decide what really is the correct
place for this otherwise it'll be like tusb6010_omap.c

--
balbi

[PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

[Felipe Balbi]

Hi,

please wrap your mails at 80 characters

On Wed, Dec 30, 2009 at 09:16:08AM +0530, Subbrathnam, Swaminathan
wrote:
> We have been on this front months together now!!! Ideally the place
> holder would be a place independant of platforms as this piece of code
> is more of a platform independant library relating to TI CPPI DMA
> operations.  This would be used during initialization and confiuration
> of CPPI4.x based peripherals.  Though today USB is the only peripheral
> that falls in that catagory ideally other like TI EMAC could fall in
> the same space.
> 
> Having said that I also see that there seems to be no roadmap/plan for
> any other peripheral other than USB to use CPPI4.x in the near future.
> TI EMAC seems to continue use CPPI3.x.
> 
> This was the reason I had recommended earlier to locate this generic
> CPPI 4.x functionality within MUSB.  This definitely helps in having a
> functional peripheral in the near (and most probably long) term.
> 
> I think it is prudent to locate this functionality in the musb
> directory for now.  In future if need arises we can relook at this
> later (I am sure this in all probabilities would not be required).
> 
> In either way I would really appreiciate if we can come to a
> conclusion at the earliest.  Appreciate everybody's feedback and
> direction.

You can do like omap and have the generic dma interface sitting in
mach-davinci, then for musb, you'd have a series of wrappers to use the
cppi dma code. Just look at arch/arm/plat-omap/dma.c and
drivers/usb/musb/tusb6010_omap.c

-- 
balbi

[PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

[Subbrathnam, Swaminathan]

Felipe,

This code is also being used for other architectures such as OMAP3517,
OMAPL13x etc.

Given this I do not think we can locate it under a mach-* directory.

Have corrected the wrap issue.  Thanks for point it out.

regards
swami

________________________________________
From: Felipe Balbi [me at felipebalbi.com]
Sent: Wednesday, December 30, 2009 5:54 PM
To: Subbrathnam, Swaminathan
Cc: felipe.balbi at nokia.com; Gupta, Ajay Kumar; linux-usb at vger.kernel.org; linux-arm-kernel at lists.infradead.org; Sergei Shtylyov
Subject: Re: [PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

Hi,

please wrap your mails at 80 characters

On Wed, Dec 30, 2009 at 09:16:08AM +0530, Subbrathnam, Swaminathan
wrote:
> We have been on this front months together now!!! Ideally the place
> holder would be a place independant of platforms as this piece of code
> is more of a platform independant library relating to TI CPPI DMA
> operations.  This would be used during initialization and confiuration
> of CPPI4.x based peripherals.  Though today USB is the only peripheral
> that falls in that catagory ideally other like TI EMAC could fall in
> the same space.
>
> Having said that I also see that there seems to be no roadmap/plan for
> any other peripheral other than USB to use CPPI4.x in the near future.
> TI EMAC seems to continue use CPPI3.x.
>
> This was the reason I had recommended earlier to locate this generic
> CPPI 4.x functionality within MUSB.  This definitely helps in having a
> functional peripheral in the near (and most probably long) term.
>
> I think it is prudent to locate this functionality in the musb
> directory for now.  In future if need arises we can relook at this
> later (I am sure this in all probabilities would not be required).
>
> In either way I would really appreiciate if we can come to a
> conclusion at the earliest.  Appreciate everybody's feedback and
> direction.

You can do like omap and have the generic dma interface sitting in
mach-davinci, then for musb, you'd have a series of wrappers to use the
cppi dma code. Just look at arch/arm/plat-omap/dma.c and
drivers/usb/musb/tusb6010_omap.c

--
balbi

[PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

[Felipe Balbi]

Hi,

On Wed, 2009-12-30 at 16:14 +0300, Sergei Shtylyov wrote:
>    We're currently having it there but the matter is it should be shred 
> between different platforms, so arch/arm/common/ seems like the right 
> place (which Russell didn't like, suggesting ill suited for that 
> drivers/dma/ instead).

if it had to be shared between different platforms, it could very well
live under drivers/usb/musb, problem is that it has to be shared among
several devices. Then drivers/usb/musb is not the right place anymore.

-- 
balbi

[PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

[Gupta, Ajay Kumar]

> Hello.
> 
> Russell King - ARM Linux wrote:
> 
> >>>>Is there any updated patch on cppi4.1 core also?
> 
> >>>Is there _any_ cppi4.1 core patch anywhere?  Not according to google.
> 
> >>Russell,
> 
> >>Here is the latest version of cppi4.1 core.
> >>http://patchwork.kernel.org/patch/46698/
> 
> [...]
> 
> >>>If it's a USB DMA device (from the patches I can find, that seems to be
> >>>the case) then why can't it live in drivers/usb or drivers/dma ?
> >>
> >>CPPI4.1 DMA engine can be used either by USB or by Ethernet interface
> though
> >>currently only USB is using it but in future even Ethernet devices may
> use it.
> 
> > drivers/dma does seem to be the right place for this.
> 
>     Russell, it makes me wonder why drivers/dma/ seemed the right place to
> you, just because of the name? :-)
>     After spending some time on studying the infrastructure there I came
> to
> conclusion that this is not the right place because all the controllers
> supported there have features like memory-to-memory transfers or even RAID
> function offloading -- which CPPI 4.1 totally lacks (it's there purely to
> serve the peripherals).
>     Adding drivers/dma/ people to this discussion in hopes they can
> correct
> me (or support me :-)...

Russell,

Please provide your thought/suggestion on this issue which is affecting
further development of CPPI4.1 DMA driver.

As Sergei pointed out, arch/arm/common seems to be the best suited place
for this driver. Is this fine for you OR do you see any issue with this
approach?

Please let us know if you need more details.

Regards,
Ajay
> 
> WBR, Sergei
> --

[PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

[Gupta, Ajay Kumar]

> -----Original Message-----
> From: Sergei Shtylyov [mailto:sshtylyov at ru.mvista.com]
> Sent: Wednesday, October 28, 2009 8:24 PM
> To: Gupta, Ajay Kumar
> Cc: linux-usb at vger.kernel.org; davinci-linux-open-
> source at linux.davincidsp.com; stanley.miao; Hilman, Kevin; david-
> b at pacbell.net; Subbrathnam, Swaminathan; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)
> 
> Hello.
> 
> Gupta, Ajay Kumar wrote:
> 
> > Sergei,
> 
> > Is there any other update to this patch ?
> 
>     The last was take 5 from August 21th:
> 
> http://marc.info/?l=linux-usb&m=125087318308323

Thanks, I will check this one.

> 
>  > We have some patches on top of your base version.
> 
>     Interesting...
> 
> > Kevin and David,
> > There is another TI platform AM3517 which also has same CPPI41 DMA. So
> even this platform has to use same CPPI41 files but there is an issue on
> using cppi4.1 core engine (cppi41.c file at arch/arm/mach-XXX).
> 
>     Are you going to push the AM3517 support upstream?

Currently AM3517 base port patches are being submitted. Once they are done, and cppi4.1 core dependency is cleared then I plan to submit patches on top of your latest version (take 5).

-Ajay
 
> 
> > Can we move this cppi41 core part to some arch/arm/common place so that
> both da8xx and Am3517 can use it ? Or is there any other option ?
> 
>     Adding linux-arm-kernel list to the loop as well...
> 
> > -Ajay
> 
> WBR, Sergei

[PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

[Gupta, Ajay Kumar]

> -----Original Message-----
> From: linux-usb-owner at vger.kernel.org [mailto:linux-usb-
> owner at vger.kernel.org] On Behalf Of Gupta, Ajay Kumar
> Sent: Wednesday, October 28, 2009 8:48 PM
> To: Sergei Shtylyov
> Cc: linux-usb at vger.kernel.org; davinci-linux-open-
> source at linux.davincidsp.com; stanley.miao; Hilman, Kevin; david-
> b at pacbell.net; Subbrathnam, Swaminathan; linux-arm-
> kernel at lists.infradead.org
> Subject: RE: [PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)
> 
> > -----Original Message-----
> > From: Sergei Shtylyov [mailto:sshtylyov at ru.mvista.com]
> > Sent: Wednesday, October 28, 2009 8:24 PM
> > To: Gupta, Ajay Kumar
> > Cc: linux-usb at vger.kernel.org; davinci-linux-open-
> > source at linux.davincidsp.com; stanley.miao; Hilman, Kevin; david-
> > b at pacbell.net; Subbrathnam, Swaminathan; linux-arm-
> > kernel at lists.infradead.org
> > Subject: Re: [PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)
> >
> > Hello.
> >
> > Gupta, Ajay Kumar wrote:
> >
> > > Sergei,
> >
> > > Is there any other update to this patch ?
> >
> >     The last was take 5 from August 21th:
> >
> > http://marc.info/?l=linux-usb&m=125087318308323
> 
> Thanks, I will check this one.

Sergei,
How about cppi41 core? I could see only one post on that while searching davinci list. Did it get merged to any tree? 

Is there any updated patch on cppi4.1 core also?

> 
> >
> >  > We have some patches on top of your base version.
> >
> >     Interesting...
> >
> > > Kevin and David,
> > > There is another TI platform AM3517 which also has same CPPI41 DMA. So
> > even this platform has to use same CPPI41 files but there is an issue on
> > using cppi4.1 core engine (cppi41.c file at arch/arm/mach-XXX).
> >
> >     Are you going to push the AM3517 support upstream?
> 
> Currently AM3517 base port patches are being submitted. Once they are
> done, and cppi4.1 core dependency is cleared then I plan to submit patches
> on top of your latest version (take 5).
> 
> -Ajay
> 
> >
> Can we move this cppi41 core part to some arch/arm/common place so
> that both da8xx and Am3517 can use it ? Or is there any other option ?
> >
> >     Adding linux-arm-kernel list to the loop as well...

Any comment on this?

Another option is to create arch/arm/ti-common to place all TI platform's common software, such as CPPI4.1 used both in DA8xx and AM3517.

-Ajay
 
> >
> > > -Ajay
> >
> > WBR, Sergei
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

[Russell King - ARM Linux]

On Mon, Nov 02, 2009 at 09:51:13AM +0530, Gupta, Ajay Kumar wrote:
> Is there any updated patch on cppi4.1 core also?

Is there _any_ cppi4.1 core patch anywhere?  Not according to google.

> Another option is to create arch/arm/ti-common to place all TI platform's
> common software, such as CPPI4.1 used both in DA8xx and AM3517.

No thanks.  I really don't see why we should allow TI to have yet more
directories scattered throughout the tree that are out of place with
existing conventions.

And what is this CPPI thing anyway?

http://acronyms.thefreedictionary.com/CPPI

"Communications Port Programming Interface" seems to be about the best
applicable one from that list!

If it's a USB DMA device (from the patches I can find, that seems to be
the case) then why can't it live in drivers/usb or drivers/dma ?

[PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

[Gupta, Ajay Kumar]

> On Mon, Nov 02, 2009 at 09:51:13AM +0530, Gupta, Ajay Kumar wrote:
> > Is there any updated patch on cppi4.1 core also?
> 
> Is there _any_ cppi4.1 core patch anywhere?  Not according to google.

Russell,

Here is the latest version of cppi4.1 core.
http://patchwork.kernel.org/patch/46698/

 
> > Another option is to create arch/arm/ti-common to place all TI
> platform's
> > common software, such as CPPI4.1 used both in DA8xx and AM3517.
> 
> No thanks.  I really don't see why we should allow TI to have yet more
> directories scattered throughout the tree that are out of place with
> existing conventions.
> 
> And what is this CPPI thing anyway?
> 
> http://acronyms.thefreedictionary.com/CPPI
> 
> "Communications Port Programming Interface" seems to be about the best
> applicable one from that list!

Yes, this is the correct one.

> If it's a USB DMA device (from the patches I can find, that seems to be
> the case) then why can't it live in drivers/usb or drivers/dma ?

CPPI4.1 DMA engine can be used either by USB or by Ethernet interface though
currently only USB is using it but in future even Ethernet devices may use it.

Infact, there is a TI platform (not in mainline), where both USB and Ethernet interface is using CPPI4.1 DMA.

Regards,
Ajay

[PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

[Felipe Balbi]

On Mon, Nov 02, 2009 at 11:57:59AM +0100, ext Gupta, Ajay Kumar wrote:
> > On Mon, Nov 02, 2009 at 09:51:13AM +0530, Gupta, Ajay Kumar wrote:
> > > Is there any updated patch on cppi4.1 core also?
> > 
> > Is there _any_ cppi4.1 core patch anywhere?  Not according to google.
> 
> Russell,
> 
> Here is the latest version of cppi4.1 core.
> http://patchwork.kernel.org/patch/46698/
> 
>  
> > > Another option is to create arch/arm/ti-common to place all TI
> > platform's
> > > common software, such as CPPI4.1 used both in DA8xx and AM3517.
> > 
> > No thanks.  I really don't see why we should allow TI to have yet more
> > directories scattered throughout the tree that are out of place with
> > existing conventions.
> > 
> > And what is this CPPI thing anyway?
> > 
> > http://acronyms.thefreedictionary.com/CPPI
> > 
> > "Communications Port Programming Interface" seems to be about the best
> > applicable one from that list!
> 
> Yes, this is the correct one.
> 
> > If it's a USB DMA device (from the patches I can find, that seems to be
> > the case) then why can't it live in drivers/usb or drivers/dma ?
> 
> CPPI4.1 DMA engine can be used either by USB or by Ethernet interface though
> currently only USB is using it but in future even Ethernet devices may use it.
> 
> Infact, there is a TI platform (not in mainline), where both USB and Ethernet interface is using CPPI4.1 DMA.

you might want to provide support for it via drivers/dma and for the
musb stuff, you just add the wrappers musb uses. See how tusb6010_omap.c
uses OMAP's system dma which is also used by any other driver which
requests a dma channel.

-- 
balbi

[PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

[Gupta, Ajay Kumar]

> >
> > > If it's a USB DMA device (from the patches I can find, that seems to
> be
> > > the case) then why can't it live in drivers/usb or drivers/dma ?
> >
> > CPPI4.1 DMA engine can be used either by USB or by Ethernet interface
> though
> > currently only USB is using it but in future even Ethernet devices may
> use it.
> >
> > Infact, there is a TI platform (not in mainline), where both USB and
> Ethernet interface is using CPPI4.1 DMA.
> 
> you might want to provide support for it via drivers/dma and for the
> musb stuff, you just add the wrappers musb uses. See how tusb6010_omap.c
> uses OMAP's system dma which is also used by any other driver which
> requests a dma channel.

Sounds good. 

So if we want to move CPPI4.1 DMA core to drivers/dma then it has to follow
standard set of DMA APIs (right?), which I afraid, may not be done in current implementation.

Regards,
Ajay
  
> --
> balbi

[PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

[Felipe Balbi]

On Mon, Nov 02, 2009 at 12:24:00PM +0100, ext Gupta, Ajay Kumar wrote:
> > >
> > > > If it's a USB DMA device (from the patches I can find, that seems to
> > be
> > > > the case) then why can't it live in drivers/usb or drivers/dma ?
> > >
> > > CPPI4.1 DMA engine can be used either by USB or by Ethernet interface
> > though
> > > currently only USB is using it but in future even Ethernet devices may
> > use it.
> > >
> > > Infact, there is a TI platform (not in mainline), where both USB and
> > Ethernet interface is using CPPI4.1 DMA.
> > 
> > you might want to provide support for it via drivers/dma and for the
> > musb stuff, you just add the wrappers musb uses. See how tusb6010_omap.c
> > uses OMAP's system dma which is also used by any other driver which
> > requests a dma channel.
> 
> Sounds good. 
> 
> So if we want to move CPPI4.1 DMA core to drivers/dma then it has to follow
> standard set of DMA APIs (right?), which I afraid, may not be done in current implementation.

yes, if it's not done right now, it has to be done.

-- 
balbi

[PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

[Russell King - ARM Linux]

On Mon, Nov 02, 2009 at 04:27:59PM +0530, Gupta, Ajay Kumar wrote:
> > On Mon, Nov 02, 2009 at 09:51:13AM +0530, Gupta, Ajay Kumar wrote:
> > > Is there any updated patch on cppi4.1 core also?
> > 
> > Is there _any_ cppi4.1 core patch anywhere?  Not according to google.
> 
> Russell,
> 
> Here is the latest version of cppi4.1 core.
> http://patchwork.kernel.org/patch/46698/

A few points come up about this.

1. alloc_queue() - this is a find_next_zero_bit loop coupled with a
   check for the excluded bitmap.

	end = start + count;
	do {
		bit = find_next_zero_bit(allocated, end, start);
		if (bit >= end)
			return -ENOSPC;
		start = bit + 1;
	} while (test_bit(bit, excluded));

	__set_bit(bit, allocated);

	return bit;

   Note that 'allocated' and 'excluded' both need to be arrays of
   unsigned long.

2. alloc_queue() again - it looks to me like the existing implementation
   is racy - who ensures that we don't have two people searching and
   allocating the same bit?  A solution to that without adding locking
   would be:

	end = start + count;
	do {
		bit = find_next_zero_bit(allocated, end, start);
		if (bit >= end)
			return -ENOSPC;
		start = bit + 1;
	} while (test_bit(bit, excluded) || test_and_set_bit(bit, allocated));
	return bit;

3. linking_ram - cppi41_queue_mgr_init() seems to be the only user.  I
   don't see why linking_ram would be necessary.

4. debugging printks via pr_debug() please (and define DEBUG at the top of
   the file to enable debugging.)

> > If it's a USB DMA device (from the patches I can find, that seems to be
> > the case) then why can't it live in drivers/usb or drivers/dma ?
> 
> CPPI4.1 DMA engine can be used either by USB or by Ethernet interface though
> currently only USB is using it but in future even Ethernet devices may use it.

drivers/dma does seem to be the right place for this.

[PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

[Gupta, Ajay Kumar]

> > Here is the latest version of cppi4.1 core.
> > http://patchwork.kernel.org/patch/46698/
> 
> A few points come up about this.
> 
> 1. alloc_queue() - this is a find_next_zero_bit loop coupled with a
>    check for the excluded bitmap.
> 
> 	end = start + count;
> 	do {
> 		bit = find_next_zero_bit(allocated, end, start);
> 		if (bit >= end)
> 			return -ENOSPC;
> 		start = bit + 1;
> 	} while (test_bit(bit, excluded));
> 
> 	__set_bit(bit, allocated);
> 
> 	return bit;
> 
>    Note that 'allocated' and 'excluded' both need to be arrays of
>    unsigned long.
> 
> 2. alloc_queue() again - it looks to me like the existing implementation
>    is racy - who ensures that we don't have two people searching and
>    allocating the same bit?  A solution to that without adding locking
>    would be:
> 
> 	end = start + count;
> 	do {
> 		bit = find_next_zero_bit(allocated, end, start);
> 		if (bit >= end)
> 			return -ENOSPC;
> 		start = bit + 1;
> 	} while (test_bit(bit, excluded) || test_and_set_bit(bit,
> allocated));
> 	return bit;
> 
> 3. linking_ram - cppi41_queue_mgr_init() seems to be the only user.  I
>    don't see why linking_ram would be necessary.
> 
> 4. debugging printks via pr_debug() please (and define DEBUG at the top of
>    the file to enable debugging.)

Thanks for the review and valuable comments.

As we have to change the current implementation in accordance with
standard DMA APIs, we will take above comments and post it in next RFC. 

Regards,
Ajay

> > > If it's a USB DMA device (from the patches I can find, that seems to
> be
> > > the case) then why can't it live in drivers/usb or drivers/dma ?
> >
> > CPPI4.1 DMA engine can be used either by USB or by Ethernet interface
> though
> > currently only USB is using it but in future even Ethernet devices may
> use it.
> 
> drivers/dma does seem to be the right place for this.

[PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

[Gupta, Ajay Kumar]

> > 3. linking_ram - cppi41_queue_mgr_init() seems to be the only user.  I
> >    don't see why linking_ram would be necessary.
> >
> > 4. debugging printks via pr_debug() please (and define DEBUG at the top
> of
> >    the file to enable debugging.)
> 
> Thanks for the review and valuable comments.
> 
> As we have to change the current implementation in accordance with
> standard DMA APIs, we will take above comments and post it in next RFC.

Sergei,

Any comment on this?  

Regards,
Ajay

> > > > If it's a USB DMA device (from the patches I can find, that seems to
> > be
> > > > the case) then why can't it live in drivers/usb or drivers/dma ?
> > >
> > > CPPI4.1 DMA engine can be used either by USB or by Ethernet interface
> > though
> > > currently only USB is using it but in future even Ethernet devices may
> > use it.
> >
> > drivers/dma does seem to be the right place for this.
> 
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

[PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

[Subbrathnam, Swaminathan]

Sergei,

Another option is to have the cppi-generic code reside in the musb directory itself.  We do not have other peripherals such as Ethernet using cppi4.1 infrastructure in the near future.  Given this I think it will be better to locate this code in the "drivers/usb/musb" directory itself and decide on any relocation later if the need arises (which I feel is remote).

regards
swami

________________________________________
From: Sergei Shtylyov [sshtylyov at ru.mvista.com]
Sent: Friday, November 27, 2009 1:00 AM
To: Russell King - ARM Linux
Cc: Gupta, Ajay Kumar; Hilman, Kevin; davinci-linux-open-source at linux.davincidsp.com; linux-usb at vger.kernel.org; david-b at pacbell.net; stanley.miao; Subbrathnam, Swaminathan; linux-arm-kernel at lists.infradead.org; dan.j.williams at intel.com; maciej.sosnowski at intel.com
Subject: Re: [PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)

Hello.

Russell King - ARM Linux wrote:

>>>>Is there any updated patch on cppi4.1 core also?

>>>Is there _any_ cppi4.1 core patch anywhere?  Not according to google.

>>Russell,

>>Here is the latest version of cppi4.1 core.
>>http://patchwork.kernel.org/patch/46698/

[...]

>>>If it's a USB DMA device (from the patches I can find, that seems to be
>>>the case) then why can't it live in drivers/usb or drivers/dma ?
>>
>>CPPI4.1 DMA engine can be used either by USB or by Ethernet interface though
>>currently only USB is using it but in future even Ethernet devices may use it.

> drivers/dma does seem to be the right place for this.

    Russell, it makes me wonder why drivers/dma/ seemed the right place to
you, just because of the name? :-)
    After spending some time on studying the infrastructure there I came to
conclusion that this is not the right place because all the controllers
supported there have features like memory-to-memory transfers or even RAID
function offloading -- which CPPI 4.1 totally lacks (it's there purely to
serve the peripherals).
    Adding drivers/dma/ people to this discussion in hopes they can correct
me (or support me :-)...

WBR, Sergei