lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 13 Jan 2012 22:10:13 +0200
From:	Felipe Balbi <balbi@...com>
To:	Sergei Shtylyov <sshtylyov@...sta.com>
Cc:	"Gupta, Ajay Kumar" <ajay.gupta@...com>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: RFC: usb: musb: Adding CPPI4.1 DMA driver under drivers/dma

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

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ