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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Gupta, Ajay Kumar
> -----Original Message-----
> From: [hidden email] [mailto:linux-usb-
> [hidden email]] On Behalf Of Gupta, Ajay Kumar
> Sent: Wednesday, October 28, 2009 8:48 PM
> To: Sergei Shtylyov
> Cc: [hidden email]; davinci-linux-open-
> [hidden email]; stanley.miao; Hilman, Kevin; david-
> [hidden email]; Subbrathnam, Swaminathan; linux-arm-
> [hidden email]
> Subject: RE: [PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)
>
> > -----Original Message-----
> > From: Sergei Shtylyov [mailto:[hidden email]]
> > Sent: Wednesday, October 28, 2009 8:24 PM
> > To: Gupta, Ajay Kumar
> > Cc: [hidden email]; davinci-linux-open-
> > [hidden email]; stanley.miao; Hilman, Kevin; david-
> > [hidden email]; Subbrathnam, Swaminathan; linux-arm-
> > [hidden email]
> > 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 [hidden email]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply | Threaded
Open this post in threaded view
|

[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

Reply | Threaded
Open this post in threaded view
|

[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.

Reply | Threaded
Open this post in threaded view
|

[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
> [hidden email]
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source