Add support for Texas Instuments Communication Port Programming Interface 4.1
(CPPI 4.1) used on OMAP-L1x/DA8xx and AM35x.
At this moment, only the DMA controller and queue manager are supported.
Support for the buffer manager is lacking but these chips don't have it anyway.
Signed-off-by: Sergei
Hello.
On 15-05-2010 22:14, Sergei Shtylyov wrote:
Add support for Texas Instuments Communication Port Programming Interface 4.1
(CPPI 4.1) used on OMAP-L1x/DA8xx and AM35x.
At this moment, only the DMA controller and queue manager are supported.
Support for the buffer manager is lacking but
On Mon, Jan 03, 2011 at 07:06:10PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 15-05-2010 22:14, Sergei Shtylyov wrote:
>
>> Add support for Texas Instuments Communication Port Programming Interface 4.1
>> (CPPI 4.1) used on OMAP-L1x/DA8xx and AM35x.
>
>> At this moment, only the DMA controller a
Hi,
> >> Add support for Texas Instuments Communication Port Programming
> Interface 4.1
> >> (CPPI 4.1) used on OMAP-L1x/DA8xx and AM35x.
> >
> >> At this moment, only the DMA controller and queue manager are supported.
> >> Support for the buffer manager is lacking but these chips don't have it
>
Hello.
On 03-01-2011 20:01, Gupta, Ajay Kumar wrote:
Add support for Texas Instuments Communication Port Programming Interface 4.1
(CPPI 4.1) used on OMAP-L1x/DA8xx and AM35x.
At this moment, only the DMA controller and queue manager are supported.
Support for the buffer manager is lacking b
Hi,
> Add support for Texas Instuments Communication Port Programming
> Interface 4.1
> (CPPI 4.1) used on OMAP-L1x/DA8xx and AM35x.
>
> At this moment, only the DMA controller and queue manager are
> supported.
> Support for the buffer manager is lacking but these chips don't
On Mon, Jan 03, 2011 at 08:07:18PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 03-01-2011 20:01, Gupta, Ajay Kumar wrote:
>
> Add support for Texas Instuments Communication Port Programming Interface
> 4.1
> (CPPI 4.1) used on OMAP-L1x/DA8xx and AM35x.
>
> At this moment, only th
Hi,
On Mon, Jan 03, 2011 at 10:45:35PM +0530, Gupta, Ajay Kumar wrote:
> Moreover, even Felipe also seems to move other musb
> DMAs (Inventra, CPPI3.0, TUSB) to drivers/dma.
Frankly speaking, I doubt that drivers/dma/ will have place for the
purely MUSB specific DMA engines such as the name
Hi,
On Mon, Jan 03, 2011 at 05:19:45PM +, Russell King - ARM Linux wrote:
Frankly speaking, I doubt that drivers/dma/ will have place for the
purely MUSB specific DMA engines such as the named ones (there's no TUSB
DMA BTW -- it uses OMAP DMA).
Long term, we need to kill off all these p
Hello.
On 03-01-2011 23:44, Felipe Balbi wrote:
> Moreover, even Felipe also seems to move other musb
> DMAs (Inventra, CPPI3.0, TUSB) to drivers/dma.
Frankly speaking, I doubt that drivers/dma/ will have place for the
purely MUSB specific DMA engines such as the named ones (there's no TUSB
Hi,
(using personal email, left the office)
On Tue, 2011-01-04 at 16:06 +0300, Sergei Shtylyov wrote:
> >> I think we will get more clarity once we start on this activity.
>
> > I agree, but I personally don't see that many limiting factors.
> > dmaengine is just a generic API for doing DMA tran
Hi,
On Tue, 2011-01-04 at 22:40 +0800, Ming Lei wrote:
> > The end goal is just to drop all these ad-hoc "APIs" for accessing DMA
> > on musb code.
>
> If this kind of DMA controllers are only used by MUSB, seems not
> necessary to convert to dmaengine API. Any benefit we can get
> from the conv
Hello.
Felipe Balbi wrote:
I think we will get more clarity once we start on this activity.
I agree, but I personally don't see that many limiting factors.
dmaengine is just a generic API for doing DMA transfers. If it's not
enough for us currently, we extend it.
Putting MUSB DMA enign
Hi,
On Tue, Jan 04, 2011 at 11:41:05PM +0800, Ming Lei wrote:
> OMAP GPIOs have many usages or use cases, so we can use gpiolib
> to simplify access to GPIOs. If GPIOs has only one usage or use case,
> it is not necessary to access GPIOs by gpiolib.
>
> Now this kind of DMA controllers are only
Hello.
Felipe Balbi wrote:
On Tue, Jan 04, 2011 at 11:41:05PM +0800, Ming Lei wrote:
OMAP GPIOs have many usages or use cases, so we can use gpiolib
to simplify access to GPIOs. If GPIOs has only one usage or use case,
it is not necessary to access GPIOs by gpiolib.
Now this kind of DMA co
* Felipe Balbi [110103 12:49]:
> Hi,
>
> On Mon, Jan 03, 2011 at 05:19:45PM +, Russell King - ARM Linux wrote:
> >> Frankly speaking, I doubt that drivers/dma/ will have place for the
> >>purely MUSB specific DMA engines such as the named ones (there's no TUSB
> >>DMA BTW -- it uses OMAP DM
On Tue, Jan 04, 2011 at 04:06:39PM +0300, Sergei Shtylyov wrote:
>Putting MUSB DMA enignes into drivers/dma/ is the same as taking *any*
> chip capable of bus-mastering DMA, "separating" its bus mastering related
> code from its driver and putting this code into drivers/dma/. This
> doesn't
Hi,
> Would you mind a brief call about this patch after we've had a chance to
> analyze this?
Apologies for the spam, hitting "reply" didn't function as expected :-)
Regards
Cyril.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@l
Hello.
I wrote:
Add support for Texas Instuments Communication Port Programming Interface 4.1
(CPPI 4.1) used on OMAP-L1x/DA8xx and AM35x.
At this moment, only the DMA controller and queue manager are supported.
Support for the buffer manager is lacking but these chips don't have it anyway.
S
Hello.
On 28-09-2010 13:13, Linus Walleij wrote:
Add support for Texas Instuments Communication Port Programming Interface 4.1
(CPPI 4.1) used on OMAP-L1x/DA8xx and AM35x.
Sorry for late feedback ...
+++ linux-davinci/arch/arm/common/cppi41.c
Can you migrate this driver to drivers/dma/
2010/5/15 Sergei Shtylyov :
> Add support for Texas Instuments Communication Port Programming Interface 4.1
> (CPPI 4.1) used on OMAP-L1x/DA8xx and AM35x.
Sorry for late feedback ...
> +++ linux-davinci/arch/arm/common/cppi41.c
Can you migrate this driver to drivers/dma/cppi41.c and use the
DMA
21 matches
Mail list logo
