mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@ti.com>
To: Sergei Shtylyov <sshtylyov@mvista.com>
Cc: "Gupta, Ajay Kumar" <ajay.gupta@ti.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: RFC: usb: musb: Adding CPPI4.1 DMA driver under drivers/dma
Date: Fri, 13 Jan 2012 22:10:13 +0200	[thread overview]
Message-ID: <20120113201010.GJ3133@legolas.emea.dhcp.ti.com> (raw)
In-Reply-To: <4F1096E9.4020501@mvista.com>

[-- 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 --]

  reply	other threads:[~2012-01-13 20:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <201201120753.00667.oneukum@suse.de>
     [not found] ` <Pine.LNX.4.44L0.1201121037340.1384-100000@iolanthe.rowland.org>
     [not found]   ` <20120112215014.GC5735@xanatos>
     [not found]     ` <20120112215459.GA1161@kroah.com>
     [not found]       ` <20120112222947.GD5735@xanatos>
     [not found]         ` <20120112223513.GA2925@kroah.com>
     [not found]           ` <20120113061144.GA30569@suse.cz>
2012-01-13 10:40             ` Gupta, Ajay Kumar
2012-01-13 18:09               ` Greg KH
2012-01-13 20:12                 ` Felipe Balbi
2012-01-16  4:25                 ` Gupta, Ajay Kumar
2012-01-13 20:41               ` Sergei Shtylyov
2012-01-13 20:10                 ` Felipe Balbi [this message]
2012-01-14 21:24                   ` Sergei Shtylyov
2012-01-16 10:59                     ` Gupta, Ajay Kumar
2012-01-16 10:56                 ` Gupta, Ajay Kumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120113201010.GJ3133@legolas.emea.dhcp.ti.com \
    --to=balbi@ti.com \
    --cc=ajay.gupta@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=sshtylyov@mvista.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome