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 make
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 transfers.
Hi,
2011/1/4 Felipe Balbi m...@felipebalbi.com:
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 convert? MUSB is
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 convert?
Hi,
2011/1/4 Felipe Balbi m...@felipebalbi.com:
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
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
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
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 and queue
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
anyway.
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 anyway.
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 the DMA controller and
12 matches
Mail list logo
