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:	Wed, 14 Mar 2012 13:19:29 -0700
From:	David Brown <davidb@...eaurora.org>
To:	Daniel Walker <dwalker@...o99.com>
Cc:	Ravi Kumar V <kumarrav@...eaurora.org>,
	Russell King <linux@....linux.org.uk>,
	Vinod Koul <vinod.koul@...el.com>,
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
	Bryan Huntsman <bryanh@...eaurora.org>,
	gregkh@...uxfoundation.org,
	Dan Williams <dan.j.williams@...el.com>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3 2/2] DMAEngine: Add DMAEngine driver based on old MSM
 DMA APIs

On Wed, Mar 14, 2012 at 08:05:53AM -0700, Daniel Walker wrote:
> On Tue, Mar 13, 2012 at 06:16:39PM +0530, Ravi Kumar V wrote:
> > On 3/13/2012 1:44 AM, Daniel Walker wrote:
> > >On Mon, Mar 12, 2012 at 04:02:44PM +0530, Ravi Kumar V wrote:
> > >>Add DMAEngine based driver using the old MSM DMA APIs internally.
> > >
> > >What do you mean by this?
> > >
> > There is a MSM DMA driver in arch/arm/mach-msm/ which is not in
> > dmaengine framework standards, but that driver is been used by
> > client drivers nand, eMMC and serial drivers. Now if we implement
> > the whole dma driver using dmaengine framework then nand, eMMC like
> > drivers will be failed as they are using old dma driver API's, so
> > instead of implementing new driver from scratch we are keeping the
> > old dma API's as it is and using those API's in new dmaengine
> > framework.So that we can convert clients drivers to use dma engine
> > framework.
> 
> Did you investigate converting the drivers (nand, eMMC, serial) ? It
> seems like there would be a 1:1 mapping between the API's , so it might
> only be a find->replace operation.

Only at a very superficial level--they both do DMA.  The ADM driver
wants its scatterlists constructed manually by the caller (in DMA-able
memory) and just the pointer handed over.  The drivers will have to be
converted to use the abstracted scatterlists that dmaengine wants.
Drivers like msm_sdcc are currently fairly intimitely tied to flow
that is specific to ADM.  The msm_sdcc driver also needs use of the
ADM's "box" mode, which has to be made to work with DMAEngine as well.

Providing both APIs is really the only practical way to get this in
without having to rewrite several other drivers.

The nand driver (which doesn't seem to have made it in yet,
https://lkml.org/lkml/2011/2/28/570) is much worse.  About half of the
code is constructing ADM specific command blocks.  I'm not even sure
it will be practical to even migrate that driver to DMAEngine, since
the nand controller hardware is so intimately tied to the functioning
of the ADM.

David

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ