RFC: usb: musb: Adding CPPI4.1 DMA driver under drivers/dma
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 20120112215014.GC5735@xanatos
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 20120112222947.GD5735@xanatos
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
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
Quoted 19 lines · 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/dmafolder, 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.
Quoted 7 lines
(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
Quoted 26 lines · Greg KH
Quoted 25 lines · 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/dmafolder, 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.
Quoted 6 lines
Quoted 1 line
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 ;-)
Signature · 1 line
balbi
Hi,
Quoted 30 lines · Ajay Kumar
Quoted 3 lines
Hi,
CPPI4.1 (Communication Port Programming Interface) is a TI specific
DMA
Quoted 1 line
controller used in multiple TI platform such as AM33x, DA8x, AM35x,
TI81x.
Quoted 3 lines
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
Quoted 1 line
was not merged due to disagreement on the location of driver in
kernel.
Quoted 7 lines
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/dmafolder, complying to dmaengine framework.
It would involve changes in existing musb driver also for whichcurrent
Quoted 1 line
plan is to maintain the compatibility of non-CPPI4.1 DMA in musb
driver.
Quoted 4 lines
The task is planned to be spitted into below subtasks.
(1) Post RFC on the API details, changes envisaged in musb driver and
other
Quoted 2 lines
challenges
Quoted 8 lines
Quoted 1 line
(2) Implement and post RFC for the CPPI4.1 DMA driver and changes
needed in
Quoted 3 lines
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
Quoted 6 lines
Second, that sounds fine, please post patches.
thanks,
greg k-h
Hello.
Quoted 3 lines · Ajay Kumar
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.
Quoted 2 lines
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...
Quoted 3 lines
Refer the discussions at [1] for more details.
Unfortunately, that's not all of the discussion of interest.
Quoted 2 lines
The new implementation of the CPPI4.1 DMA slave driver will be in the
drivers/dmafolder, complying to dmaengine framework.
Has there been any work in this direction done yet?
Quoted 2 lines
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...
Quoted 4 lines
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).
Quoted 7 lines
(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
Quoted 9 lines · Sergei Shtylyov
Hello.
Quoted 3 lines · Ajay Kumar
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.
Quoted 16 lines
Quoted 2 lines
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...Quoted 3 lines
Refer the discussions at [1] for more details.
Unfortunately, that's not all of the discussion of interest.
Quoted 2 lines
The new implementation of the CPPI4.1 DMA slave driver will be in the
drivers/dmafolder, complying to dmaengine framework.
Quoted 6 lines
Has there been any work in this direction done yet?
Quoted 2 lines
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).
Quoted 9 lines
Quoted 4 lines
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.
Signature · 1 line
balbi
Hello.
Quoted 8 lines · Felipe Balbi
Quoted 5 lines
Quoted 3 lines
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.
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
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.cto
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.
Quoted 8 lines
drivers/dmahe will not move all the other dma engines (Inventra, OMAP, TUSB-over-GPMC, etc).Quoted 4 lines
Quoted 4 lines
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
Quoted 7 lines
Quoted 4 lines
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
Hi,
Quoted 9 lines · Felipe Balbi
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
CPPI4.1 (Communication Port Programming Interface) is a TI specific
DMA
Quoted 1 line
Quoted 1 line
Quoted 1 line
controller used in multiple TI platform such as AM33x, DA8x, AM35x,
TI81x.
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
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
Quoted 8 lines
Ethernet.
Quoted 1 line
if they are out of tree, I'm sorry but we don't care about them. If
they
Quoted 1 line
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.
Quoted 29 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
It would involve changes in existing musb driver also for which
current
Quoted 1 line
Quoted 1 line
Quoted 1 line
plan is to maintain the compatibility of non-CPPI4.1 DMA in musb
driver.
Quoted 3 lines
Quoted 1 line
I didn't quite understand this part...
how come ? What he's saying is that while moving
cppi-dma.ctoHow come we are taling of
cppi-dma.cat all? It's CPPI 3.0 driver
having
nothing in common with CPPI 4.1.Quoted 1 line
drivers/dmahe will not move all the other dma engines (Inventra,OMAP,
Quoted 5 lines
TUSB-over-GPMC, etc).
Quoted 3 lines
Quoted 3 lines
The task is planned to be spitted into below subtasks.
(1) Post RFC on the API details, changes envisaged in musb driver
and other
Quoted 6 lines
Quoted 6 lines
Quoted 1 line
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).
Quoted 5 lines
Quoted 1 line
that's why the kernel is open source, right ? If we need to improve
the
Quoted 1 line
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
Quoted 2 lines
WBR, Sergei
Hi,
Quoted 24 lines · Ajay Kumar
Quoted 2 lines
CPPI4.1 (Communication Port Programming Interface) is a TI specific
DMA
Quoted 1 line
controller used in multiple TI platform such as AM33x, DA8x, AM35x,
TI81x.
Quoted 1 line
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.Quoted 1 line
Earlier version of the driver was submitted by Sergei Shtylyov at [1]
but
Quoted 1 line
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...Quoted 1 line
Refer the discussions at [1] for more details.
Quoted 8 lines
Quoted 1 line
Unfortunately, that's not all of the discussion of interest.
Quoted 2 lines
The new implementation of the CPPI4.1 DMA slave driver will be in the
drivers/dmafolder, 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
Quoted 30 lines
Quoted 2 lines
It would involve changes in existing musb driver also for which
current
Quoted 1 line
plan is to maintain the compatibility of non-CPPI4.1 DMA in musb
driver.
I didn't quite understand this part...
Quoted 3 lines
The task is planned to be spitted into below subtasks.
(1) Post RFC on the API details, changes envisaged in musb driver and
other
Quoted 1 line
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).Quoted 1 line
(2) Implement and post RFC for the CPPI4.1 DMA driver and changes
needed in
Quoted 6 lines
musb driver.
Let me know if you have any thoughts/comments on this.
Regards,
AjayWBR, Sergei