ARM: add CPPI 4.1 DMA support

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 Shtylyov <[email protected]>

Signed-off-by Sekhar Nori <[email protected]>

---
Changes since the previous version:
- moved everything from arch/arm/mach-davinci/ to arch/arm/common/;
- s/CONFIG_CPPI41/CONFIG_TI_CPPI41/, made that option invisible;
- added #include <linux/slab.h> for kzalloc();
- switched alloc_queue() and cppi41_queue_free() to using bit operations;
- replaced 'static' linking_ram[] by local variable in cppi41_queue_mgr_init();
- fixed pr_debug() in cppi41_dma_ctrlr_init() to print the real queue manager #.

Add support for Texas Instuments Communication Port Programming Interface 4.1 (CPPI 4.1) used on OMAP-L1x/DA8xx and AM35x.

+++ linux-davinci/arch/arm/common/cppi41.c

Quoted 2 lines

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

Quoted 1 line

+++ linux-davinci/arch/arm/common/cppi41.c

Can you migrate this driver to drivers/dma/cppi41.c and use the DMAengine interface like so many DMA drivers we have created recently, or is there some very special characteristics about this DMA controller meriting it to be placed in arch/arm/*?

Yours,
Linus Walleij

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 Shtylyov<[email protected]>

Signed-off-by Sekhar Nori<[email protected]>

Hello.

Quoted 2 lines · Sergei Shtylyov

Add support for Texas Instuments Communication Port Programming Interface 4.1 (CPPI 4.1) used on OMAP-L1x/DA8xx and AM35x.

Quoted 5 lines

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 Shtylyov<[email protected]>

Signed-off-by Sekhar Nori<[email protected]>

Russell, you have recently discarded this patch from your patch
system. Can we know the reason?

Quoted 1 line

Quoted 1 line

Add support for Texas Instuments Communication Port Programming

Interface 4.1

Quoted 4 lines

Quoted 4 lines

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

Quoted 6 lines

Quoted 3 lines

Signed-off-by Sergei Shtylyov<[email protected]>

Signed-off-by Sekhar Nori<[email protected]>

Russell, you have recently discarded this patch from your patch
system. Can we know the reason?

It was recently discussed with TI, and various people raised concerns about it. I don't remember the exact details, and I wish they'd raise them with the patch author directly. It may have been that it's inventing its own API rather than using something like the DMA engine API.

Adding linux-omap to try to get a response there.

_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source at linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Quoted 17 lines

Quoted 11 lines

Quoted 8 lines

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 Shtylyov<[email protected]>

Signed-off-by Sekhar Nori<[email protected]>

Russell, you have recently discarded this patch from your patch
system. Can we know the reason?

It was recently discussed with TI, and various people raised concerns about it. I don't remember the exact details, and I wish they'd raise them with the patch author directly. It may have been that it's inventing its own API rather than using something like the DMA engine API.

Quoted 1 line

Adding linux-omap to try to get a response there.

Sergei,
This issue was discussed recently at TI and proposal was to place it to drivers/dma folder.

Moreover, even Felipe also seems to move other musb DMAs (Inventra, CPPI3.0, TUSB) to drivers/dma.

Regards,
Ajay

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Add support for Texas Instuments Communication Port Programming

Interface 4.1

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

(CPPI 4.1) used on OMAP-L1x/DA8xx and AM35x.

At this moment, only the DMA controller and queue manager are

supported.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Support for the buffer manager is lacking but these chips don't have

it anyway.

Quoted 11 lines

Quoted 11 lines

Quoted 5 lines

Quoted 2 lines

Signed-off-by Sergei Shtylyov<[email protected]>

Signed-off-by Sekhar Nori<[email protected]>

Russell, you have recently discarded this patch from your patch
system. Can we know the reason?

It was recently discussed with TI, and various people raised concerns about it. I don't remember the exact details, and I wish they'd raise them with the patch author directly. It may have been that it's inventing its own API rather than using something like the DMA engine API.

Quoted 5 lines

Quoted 1 line

Adding linux-omap to try to get a response there.

Sergei,
This issue was discussed recently at TI and proposal was to place it to drivers/dma folder.

Note that I have neither time nor inclination to do this work (not do
I think it's even feasible), so it will have to fall on TI's shoulders...

Quoted 3 lines

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 DMA BTW it uses OMAP DMA).

Quoted 3 lines

Regards,
Ajay

WBR, Sergei

Quoted 6 lines

Quoted 2 lines

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 DMA BTW it uses OMAP DMA).

I think we will get more clarity once we start on this activity.

Quoted 6 lines

Quoted 6 lines

Quoted 2 lines

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 DMA BTW it uses OMAP DMA).

Quoted 1 line

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.

Quoted 5 lines

Quoted 1 line

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 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 sense, in my opinion. drivers/dma/ is for the dedicated DMA controllers (which can *optionally* serve the slave devices).

The end goal is just to drop all these ad-hoc "APIs" for accessing DMA on musb code.

Quoted 2 lines

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 cross-platform already after all.

Hi,

Quoted 3 lines · Ming Lei

Quoted 2 lines

The end goal is just to drop all these ad-hoc "APIs" for accessing DMA on musb code.

Quoted 3 lines

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 cross-platform already after all.

<irony>
correct, OMAP GPIO controller is only used on OMAPs, so why do we even bother having gpiolib, right ?

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 used by MUSB or only for MUSB, so it doesn't matter to access them by dmaengine or not.

Quoted 6 lines · Ming Lei

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 used by MUSB or only for MUSB, so it doesn't matter to access them by dmaengine or not.

Not entirely true. TUSB uses OMAP system DMA and AFAICT CPPI is used also for ethernet.

Quoted 5 lines

Quoted 5 lines

Quoted 1 line

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.

Quoted 5 lines

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 sense, in my opinion. drivers/dma/ is for the dedicated DMA controllers (which can *optionally* serve the slave devices).

Do I really have to spell it out ? Really ?

You don't need to physically move the part of the code to drivers/dma, but it has to use the API. The mentor DMA is internal to MUSB. tusb6010_omap.c isn't.

Where it makes sense to move the code under drivers/dma, it will be

done, where it doesn't, it won't be done, but it will use the same API. That's all.

The end goal is just to drop all these ad-hoc "APIs" for accessing DMA on musb code.

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 sense, in my opinion. drivers/dma/ is for the dedicated DMA controllers (which can *optionally* serve the slave devices).

Hello.

Quoted 18 lines · Ajay Kumar

Quoted 17 lines

Quoted 11 lines

Quoted 8 lines

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 Shtylyov<[email protected]>

Signed-off-by Sekhar Nori<[email protected]>

Russell, you have recently discarded this patch from your patch
system. Can we know the reason?

It was recently discussed with TI, and various people raised concerns about it. I don't remember the exact details, and I wish they'd raise them with the patch author directly. It may have been that it's inventing its own API rather than using something like the DMA engine API.

Quoted 5 lines

Quoted 1 line

Adding linux-omap to try to get a response there.

Sergei,
This issue was discussed recently at TI and proposal was to place it to drivers/dma folder.

Note that I have neither time nor inclination to do this work (not do
I think it's even feasible), so it will have to fall on TI's shoulders...

Quoted 2 lines

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 DMA BTW -- it uses OMAP DMA).

Quoted 3 lines

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 platform private DMA interfaces. There's a growing amount of IP that's being shared not only between ARM silicon vendors, but also across architectures, and having to re-implement drivers because the underlying DMA engine is different is not feasible.

For example, we're seeing ARMs primecells being used with various different DMA controllers in various different ARM SoCs. I've heard rumours of them appearing in MIPS or PPC stuff as well. We're seeing PXA peripheral IP appearing in x86 stuff too.

We can't have drivers tied to their SoC DMA engines, and we can't continue having SoC DMA engines implementing their own unique APIs. We do need to get on top of this before it becomes a major problem (if it hasn't already).

The DMA engine API is still evolving, and should not be taken as concrete
- I've recently been bringing up a number of points with Dan on various aspects of the API, some of which ultimately will lead to changes to the async-tx API, and others which hopefully will mean that the DMA slave API is better documented.

Hi,

Quoted 19 lines · Russell King - ARM Linux

Quoted 3 lines

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 platform private DMA interfaces. There's a growing amount of IP that's being shared not only between ARM silicon vendors, but also across architectures, and having to re-implement drivers because the underlying DMA engine is different is not feasible.

For example, we're seeing ARMs primecells being used with various different DMA controllers in various different ARM SoCs. I've heard rumours of them appearing in MIPS or PPC stuff as well. We're seeing PXA peripheral IP appearing in x86 stuff too.

We can't have drivers tied to their SoC DMA engines, and we can't continue having SoC DMA engines implementing their own unique APIs. We do need to get on top of this before it becomes a major problem (if it hasn't already).

Quoted 5 lines

The DMA engine API is still evolving, and should not be taken as concrete
- I've recently been bringing up a number of points with Dan on various aspects of the API, some of which ultimately will lead to changes to the async-tx API, and others which hopefully will mean that the DMA slave API is better documented.

I couldn't agree more with you Russell. If the API isn't enough currently, we can always propose an extension.

Having all sorts of SoC-specific "APIs" has already caused enough problems and it still does (non-generic IRQ handling on twl?030, menelaus, cbus - which isn't in mainline yet -, etc, non-generic McBSP usage, non-generic GPMC usage, etc etc). So, if we can plan for making use of generic APIs, let's do so.