Re: [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support

Re: [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support

[Russell King - ARM Linux]

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 manager are supported.
>> Support for the buffer manager is lacking but these chips don't have it anyway.
>
>> Signed-off-by: Sergei Shtylyov<sshtylyov@ru.mvista.com>
>> Signed-off-by: Sekhar Nori<nsekhar@ti.com>
>
>    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.

RE: [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support

[Gupta, Ajay Kumar]

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.
> >
> >> Signed-off-by: Sergei Shtylyov<sshtylyov@ru.mvista.com>
> >> Signed-off-by: Sekhar Nori<nsekhar@ti.com>
> >
> >    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.

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
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Re: [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support

[Sergei Shtylyov]

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 but these chips don't have it anyway.

>>>> Signed-off-by: Sergei Shtylyov<sshtylyov@ru.mvista.com>
>>>> Signed-off-by: Sekhar Nori<nsekhar@ti.com>

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

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

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

> Regards,
> Ajay

WBR, Sergei

RE: [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support

[Gupta, Ajay Kumar]

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.
> 
> >>>> Signed-off-by: Sergei Shtylyov<sshtylyov-hkdhdckH98+B+jHODAdFcQ@public.gmane.org>
> >>>> Signed-off-by: Sekhar Nori<nsekhar-l0cyMroinI0@public.gmane.org>
> 
> >>>     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.
> 
> > 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...

This is fine. No issues. We will discuss this at length at linux-usb list.

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

Thanks,
Ajay
> 
> > Regards,
> > Ajay
> 
> WBR, Sergei

Re: [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support

[Felipe Balbi]

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

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.

-- 
balbi

Re: [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support

[Sergei Shtylyov]

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

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

WBR, Sergei

Re: [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support

[Felipe Balbi]

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

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.

-- 
balbi

Re: [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support

[Ming Lei]

Hi,

2011/1/4 Felipe Balbi <me@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 cross-platform already after all.


thanks,
-- 
Lei Ming

Re: [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support

[Felipe Balbi]

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?   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 ?
</irony>

-- 
balbi

Re: [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support

[Ming Lei]

Hi,

2011/1/4 Felipe Balbi <me@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 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.

thanks,
-- 
Lei Ming
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support

[Felipe Balbi]

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 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. The thing is that we want to get rid of non-standard
"APIs" as much as possible.

-- 
balbi

Re: [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support

[Sergei Shtylyov]

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

    Yes, but the CPPI registers are not compatible between MUSB and EMAC, only 
the descriptors are, AFAIK.

WBR, Sergei

Re: [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support

[Sergei Shtylyov]

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

    Yes, I'm dense. :-)
    Especially after Ajay claiming that Mentor and CPPI 3.0 DMA will be moved to 
drivers/dma/...

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

    Yes, that's what I've already noted in this thread.

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

    Surely OMAP DMA needs to be moved under drivers/dma/, not the TUSB code
interfacing it.

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

    I don't quite see how DMA engine API is beneficial to what we currently have...

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

    The "ad-hoc" API is well suited for use with MUSB, while DMA engine API is 
more abstract, I think. The "ad-hoc" API takes into account some things that the 
DMA engine API just can't -- like the transfer mode and packet size...

WBR, Sergei

Re: [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support

[Russell King - ARM Linux]

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

Then why is it already separated into its own self-contained driver?

If it's because the DMA engine is used for different peripherals (possibly
re-used for different peripherals), then it does seem to make sense to
have it separated via some API.  And if possible that API might should
be something generic instead of specific.

Even more reason to do this is if the device being fed by the DMA has
been re-used with different DMA hardware (which I believe is the case
with MUSB.)  What if this different DMA hardware then gets re-used for
other devices?  Should they all implement the same custom API or try
for a generic API?

Re: [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support

[Russell King - ARM Linux]

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 queue manager are supported.
>>>>> Support for the buffer manager is lacking but these chips don't have it anyway.
>
>>>>> Signed-off-by: Sergei Shtylyov<sshtylyov@ru.mvista.com>
>>>>> Signed-off-by: Sekhar Nori<nsekhar@ti.com>
>
>>>>     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.
>
>> 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...
>
>> 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).

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.

Re: [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support

[Felipe Balbi]

Hi,

On Mon, Jan 03, 2011 at 05:19:45PM +0000, 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 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.

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.

-- 
balbi

Re: [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support

[Tony Lindgren]

* Felipe Balbi <balbi@ti.com> [110103 12:49]:
> Hi,
> 
> On Mon, Jan 03, 2011 at 05:19:45PM +0000, 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 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.
> 
> 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.

Yes I too agree with this. We just need to do whatever it takes to
make the DMA engine suitable for all drivers.

Regards,

Tony