RFC: usb: musb: Adding CPPI4.1 DMA driver under drivers/dma

RFC: usb: musb: Adding CPPI4.1 DMA driver under drivers/dma

[Gupta, Ajay Kumar]

Hi,

CPPI4.1 (Communication Port Programming Interface) is a TI specific DMA
controller used in multiple TI platform such as AM33x, DA8x, AM35x, TI81x.
The DMA engine is mainly used by musb controller on above platform.

Earlier version of the driver was submitted by Sergei Shtylyov at [1] but
was not merged due to disagreement on the location of driver in kernel.
Refer the discussions at [1] for more details.

[1] http://marc.info/?l=linux-usb&m=125087318308323

The new implementation of the CPPI4.1 DMA slave driver will be in the
drivers/dma folder, complying to dmaengine framework.
It would involve changes in existing musb driver also for which current
plan is to maintain the compatibility of non-CPPI4.1 DMA in musb driver. 

The task is planned to be spitted into below subtasks.

(1) Post RFC on the API details, changes envisaged in musb driver and other
challenges

(2) Implement and post RFC for the CPPI4.1 DMA driver and changes needed in
musb driver.

Let me know if you have any thoughts/comments on this.

Regards,
Ajay

Re: RFC: usb: musb: Adding CPPI4.1 DMA driver under drivers/dma

[Greg KH]

On Fri, Jan 13, 2012 at 10:40:50AM +0000, Gupta, Ajay Kumar wrote:
> Hi,
> 
> CPPI4.1 (Communication Port Programming Interface) is a TI specific DMA
> controller used in multiple TI platform such as AM33x, DA8x, AM35x, TI81x.
> The DMA engine is mainly used by musb controller on above platform.
> 
> Earlier version of the driver was submitted by Sergei Shtylyov at [1] but
> was not merged due to disagreement on the location of driver in kernel.
> Refer the discussions at [1] for more details.
> 
> [1] http://marc.info/?l=linux-usb&m=125087318308323
> 
> The new implementation of the CPPI4.1 DMA slave driver will be in the
> drivers/dma folder, complying to dmaengine framework.
> It would involve changes in existing musb driver also for which current
> plan is to maintain the compatibility of non-CPPI4.1 DMA in musb driver. 
> 
> The task is planned to be spitted into below subtasks.
> 
> (1) Post RFC on the API details, changes envisaged in musb driver and other
> challenges
> 
> (2) Implement and post RFC for the CPPI4.1 DMA driver and changes needed in
> musb driver.
> 
> Let me know if you have any thoughts/comments on this.

First off, don't highjack threads (you responded to a linux-usb thread
here, get a better email client please.)

Second, that sounds fine, please post patches.

thanks,

greg k-h

Re: RFC: usb: musb: Adding CPPI4.1 DMA driver under drivers/dma

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]

On Fri, Jan 13, 2012 at 10:09:32AM -0800, Greg KH wrote:
> On Fri, Jan 13, 2012 at 10:40:50AM +0000, Gupta, Ajay Kumar wrote:
> > Hi,
> > 
> > CPPI4.1 (Communication Port Programming Interface) is a TI specific DMA
> > controller used in multiple TI platform such as AM33x, DA8x, AM35x, TI81x.
> > The DMA engine is mainly used by musb controller on above platform.
> > 
> > Earlier version of the driver was submitted by Sergei Shtylyov at [1] but
> > was not merged due to disagreement on the location of driver in kernel.
> > Refer the discussions at [1] for more details.
> > 
> > [1] http://marc.info/?l=linux-usb&m=125087318308323
> > 
> > The new implementation of the CPPI4.1 DMA slave driver will be in the
> > drivers/dma folder, complying to dmaengine framework.
> > It would involve changes in existing musb driver also for which current
> > plan is to maintain the compatibility of non-CPPI4.1 DMA in musb driver. 
> > 
> > The task is planned to be spitted into below subtasks.
> > 
> > (1) Post RFC on the API details, changes envisaged in musb driver and other
> > challenges
> > 
> > (2) Implement and post RFC for the CPPI4.1 DMA driver and changes needed in
> > musb driver.
> > 
> > Let me know if you have any thoughts/comments on this.
> 
> First off, don't highjack threads (you responded to a linux-usb thread
> here, get a better email client please.)
> 
> Second, that sounds fine, please post patches.

I'm with Greg here, please post patches.

What I suggest is:

- first create a dma-engine.c file on drivers/usb/musb which will simply
  translate dmaengine into the MUSB-specific API.
  	this will allow us to slowly convert other platforms without
	breaking the legacy stuff.

- Then move CPPI to drivers/dma

- Test it all out ;-)

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: RFC: usb: musb: Adding CPPI4.1 DMA driver under drivers/dma

[Gupta, Ajay Kumar]

Hi,
> On Fri, Jan 13, 2012 at 10:40:50AM +0000, Gupta, Ajay Kumar wrote:
> > Hi,
> >
> > CPPI4.1 (Communication Port Programming Interface) is a TI specific
> DMA
> > controller used in multiple TI platform such as AM33x, DA8x, AM35x,
> TI81x.
> > The DMA engine is mainly used by musb controller on above platform.
> >
> > Earlier version of the driver was submitted by Sergei Shtylyov at [1]
> but
> > was not merged due to disagreement on the location of driver in
> kernel.
> > Refer the discussions at [1] for more details.
> >
> > [1] http://marc.info/?l=linux-usb&m=125087318308323
> >
> > The new implementation of the CPPI4.1 DMA slave driver will be in the
> > drivers/dma folder, complying to dmaengine framework.
> > It would involve changes in existing musb driver also for which
> current
> > plan is to maintain the compatibility of non-CPPI4.1 DMA in musb
> driver.
> >
> > The task is planned to be spitted into below subtasks.
> >
> > (1) Post RFC on the API details, changes envisaged in musb driver and
> other
> > challenges
> >
> > (2) Implement and post RFC for the CPPI4.1 DMA driver and changes
> needed in
> > musb driver.
> >
> > Let me know if you have any thoughts/comments on this.
> 
> First off, don't highjack threads (you responded to a linux-usb thread
> here, get a better email client please.)

Sorry for inconvenience, I will take care of this in future.

Thanks,
Ajay
> 
> Second, that sounds fine, please post patches.
> 
> thanks,
> 
> greg k-h

Re: RFC: usb: musb: Adding CPPI4.1 DMA driver under drivers/dma

[Sergei Shtylyov]

Hello.

On 01/13/2012 01:40 PM, Gupta, Ajay Kumar wrote:

> CPPI4.1 (Communication Port Programming Interface) is a TI specific DMA
> controller used in multiple TI platform such as AM33x, DA8x, AM35x, TI81x.
> The DMA engine is mainly used by musb controller on above platform.

    There are (at least out of tree) platforms using CPPI 4.1 for Ethernet.

> Earlier version of the driver was submitted by Sergei Shtylyov at [1] but
> was not merged due to disagreement on the location of driver in kernel.

    To be precise, TI requested pulling out already queued (to arch/arm/common/) 
CPPI 4.1 driver from RMK's patch system without even notifying me. At least that 
was RMK's version...

> Refer the discussions at [1] for more details.

> [1] http://marc.info/?l=linux-usb&m=125087318308323

    Unfortunately, that's not all of the discussion of interest.

> The new implementation of the CPPI4.1 DMA slave driver will be in the
> drivers/dma folder, complying to dmaengine framework.

    Has there been any work in this direction done yet?

> It would involve changes in existing musb driver also for which current
> plan is to maintain the compatibility of non-CPPI4.1 DMA in musb driver.

    I didn't quite understand this part...

> The task is planned to be spitted into below subtasks.

> (1) Post RFC on the API details, changes envisaged in musb driver and other
> challenges

    First of all, I foresee changes in drivers/dma/ to cope with the entity in 
CPPI 4.1 called the queue manager (there's also buffer manager but it wasn't 
implemented on DA8xx, so I didn't design any API for it).

> (2) Implement and post RFC for the CPPI4.1 DMA driver and changes needed in
> musb driver.

> Let me know if you have any thoughts/comments on this.

> Regards,
> Ajay

WBR, Sergei

Re: RFC: usb: musb: Adding CPPI4.1 DMA driver under drivers/dma

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2236 bytes --]

On Fri, Jan 13, 2012 at 11:41:13PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 01/13/2012 01:40 PM, Gupta, Ajay Kumar wrote:
> 
> >CPPI4.1 (Communication Port Programming Interface) is a TI specific DMA
> >controller used in multiple TI platform such as AM33x, DA8x, AM35x, TI81x.
> >The DMA engine is mainly used by musb controller on above platform.
> 
>    There are (at least out of tree) platforms using CPPI 4.1 for Ethernet.

if they are out of tree, I'm sorry but we don't care about them. If they
are in tree, then that needs to be sorted out on the same patchset.

> >Earlier version of the driver was submitted by Sergei Shtylyov at [1] but
> >was not merged due to disagreement on the location of driver in kernel.
> 
>    To be precise, TI requested pulling out already queued (to
> arch/arm/common/) CPPI 4.1 driver from RMK's patch system without
> even notifying me. At least that was RMK's version...
> 
> >Refer the discussions at [1] for more details.
> 
> >[1] http://marc.info/?l=linux-usb&m=125087318308323
> 
>    Unfortunately, that's not all of the discussion of interest.
> 
> >The new implementation of the CPPI4.1 DMA slave driver will be in the
> >drivers/dma folder, complying to dmaengine framework.
> 
>    Has there been any work in this direction done yet?
> 
> >It would involve changes in existing musb driver also for which current
> >plan is to maintain the compatibility of non-CPPI4.1 DMA in musb driver.
> 
>    I didn't quite understand this part...

how come ? What he's saying is that while moving cppi-dma.c to
drivers/dma he will not move all the other dma engines (Inventra, OMAP,
TUSB-over-GPMC, etc).

> >The task is planned to be spitted into below subtasks.
> 
> >(1) Post RFC on the API details, changes envisaged in musb driver and other
> >challenges
> 
>    First of all, I foresee changes in drivers/dma/ to cope with the
> entity in CPPI 4.1 called the queue manager (there's also buffer
> manager but it wasn't implemented on DA8xx, so I didn't design any
> API for it).

that's why the kernel is open source, right ? If we need to improve the
framework so that it understands other types of DMAs, so be it.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: RFC: usb: musb: Adding CPPI4.1 DMA driver under drivers/dma

[Sergei Shtylyov]

Hello.

On 14-01-2012 0:10, Felipe Balbi wrote:

>>> CPPI4.1 (Communication Port Programming Interface) is a TI specific DMA
>>> controller used in multiple TI platform such as AM33x, DA8x, AM35x, TI81x.
>>> The DMA engine is mainly used by musb controller on above platform.

>>     There are (at least out of tree) platforms using CPPI 4.1 for Ethernet.

> if they are out of tree, I'm sorry but we don't care about them. If they
> are in tree, then that needs to be sorted out on the same patchset.

    I'm not sure if Puma-5 is the only one using CPPI 4.1 for Etherhet, and 
not some new platfroms introduced just now like AM33x/TI81x.

>>> It would involve changes in existing musb driver also for which current
>>> plan is to maintain the compatibility of non-CPPI4.1 DMA in musb driver.

>>     I didn't quite understand this part...

> how come ? What he's saying is that while moving cppi-dma.c to

    How come we are taling of cppi-dma.c at all? It's CPPI 3.0 driver having 
nothing in common with CPPI 4.1.

> drivers/dma he will not move all the other dma engines (Inventra, OMAP,
> TUSB-over-GPMC, etc).

>>> The task is planned to be spitted into below subtasks.

>>> (1) Post RFC on the API details, changes envisaged in musb driver and other
>>> challenges

>>     First of all, I foresee changes in drivers/dma/ to cope with the
>> entity in CPPI 4.1 called the queue manager (there's also buffer
>> manager but it wasn't implemented on DA8xx, so I didn't design any
>> API for it).

> that's why the kernel is open source, right ? If we need to improve the
> framework so that it understands other types of DMAs, so be it.

    I just foresee difficulties here.

WBR, Sergei

RE: RFC: usb: musb: Adding CPPI4.1 DMA driver under drivers/dma

[Gupta, Ajay Kumar]

Hi,

> On 14-01-2012 0:10, Felipe Balbi wrote:
> 
> >>> CPPI4.1 (Communication Port Programming Interface) is a TI specific
> DMA
> >>> controller used in multiple TI platform such as AM33x, DA8x, AM35x,
> TI81x.
> >>> The DMA engine is mainly used by musb controller on above platform.
> 
> >>     There are (at least out of tree) platforms using CPPI 4.1 for
> Ethernet.
> 
> > if they are out of tree, I'm sorry but we don't care about them. If
> they
> > are in tree, then that needs to be sorted out on the same patchset.
> 
>     I'm not sure if Puma-5 is the only one using CPPI 4.1 for Etherhet,
> and not some new platfroms introduced just now like AM33x/TI81x.

Currently AM33x/TI81x doesn't use cppi4.1 for Ethernet.

> 
> >>> It would involve changes in existing musb driver also for which
> current
> >>> plan is to maintain the compatibility of non-CPPI4.1 DMA in musb
> driver.
> 
> >>     I didn't quite understand this part...
> 
> > how come ? What he's saying is that while moving cppi-dma.c to
> 
>     How come we are taling of cppi-dma.c at all? It's CPPI 3.0 driver
> having
> nothing in common with CPPI 4.1.
> 
> > drivers/dma he will not move all the other dma engines (Inventra,
> OMAP,
> > TUSB-over-GPMC, etc).
> 
> >>> The task is planned to be spitted into below subtasks.
> 
> >>> (1) Post RFC on the API details, changes envisaged in musb driver
> and other
> >>> challenges
> 
> >>     First of all, I foresee changes in drivers/dma/ to cope with the
> >> entity in CPPI 4.1 called the queue manager (there's also buffer
> >> manager but it wasn't implemented on DA8xx, so I didn't design any
> >> API for it).
> 
> > that's why the kernel is open source, right ? If we need to improve
> the
> > framework so that it understands other types of DMAs, so be it.
> 
>     I just foresee difficulties here. 

We can discuss more on this when we post design and API flow for review.

Regards,
Ajay
> 
> WBR, Sergei

RE: RFC: usb: musb: Adding CPPI4.1 DMA driver under drivers/dma

[Gupta, Ajay Kumar]

Hi,
> On 01/13/2012 01:40 PM, Gupta, Ajay Kumar wrote:
> 
> > CPPI4.1 (Communication Port Programming Interface) is a TI specific
> DMA
> > controller used in multiple TI platform such as AM33x, DA8x, AM35x,
> TI81x.
> > The DMA engine is mainly used by musb controller on above platform.
> 
>     There are (at least out of tree) platforms using CPPI 4.1 for
> Ethernet.
> 
> > Earlier version of the driver was submitted by Sergei Shtylyov at [1]
> but
> > was not merged due to disagreement on the location of driver in
> kernel.
> 
>     To be precise, TI requested pulling out already queued (to
> arch/arm/common/)
> CPPI 4.1 driver from RMK's patch system without even notifying me. At
> least that
> was RMK's version...
> 
> > Refer the discussions at [1] for more details.
> 
> > [1] http://marc.info/?l=linux-usb&m=125087318308323
> 
>     Unfortunately, that's not all of the discussion of interest.
> 
> > The new implementation of the CPPI4.1 DMA slave driver will be in the
> > drivers/dma folder, complying to dmaengine framework.
> 
>     Has there been any work in this direction done yet?

Currently we are working on design flow and API details which will be posted
first for review.

Ajay
> 
> > It would involve changes in existing musb driver also for which
> current
> > plan is to maintain the compatibility of non-CPPI4.1 DMA in musb
> driver.
> 
>     I didn't quite understand this part...
> 
> > The task is planned to be spitted into below subtasks.
> 
> > (1) Post RFC on the API details, changes envisaged in musb driver and
> other
> > challenges
> 
>     First of all, I foresee changes in drivers/dma/ to cope with the
> entity in
> CPPI 4.1 called the queue manager (there's also buffer manager but it
> wasn't
> implemented on DA8xx, so I didn't design any API for it).
> 
> > (2) Implement and post RFC for the CPPI4.1 DMA driver and changes
> needed in
> > musb driver.
> 
> > Let me know if you have any thoughts/comments on this.
> 
> > Regards,
> > Ajay
> 
> WBR, Sergei