linux-kernel - RE: [RFC PATCH 1/2] RapidIO: Add DMA Engine support for RIO data transfers

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]

Message-ID: <0CE8B6BE3C4AD74AB97D9D29BD24E55202321E3E@CORPEXCH1.na.ads.idt.com>
Date:	Mon, 17 Oct 2011 07:33:01 -0700
From:	"Bounine, Alexandre" <Alexandre.Bounine@....com>
To:	Vinod Koul <vinod.koul@...el.com>,
	Jassi Brar <jaswinder.singh@...aro.org>
CC:	Dan <dan.j.williams@...el.com>, <akpm@...ux-foundation.org>,
	<linux-kernel@...r.kernel.org>, <linuxppc-dev@...ts.ozlabs.org>,
	Kumar Gala <galak@...nel.crashing.org>,
	Matt Porter <mporter@...nel.crashing.org>,
	Li Yang <leoli@...escale.com>
Subject: RE: [RFC PATCH 1/2] RapidIO: Add DMA Engine support for RIO data transfers

On Sat, Oct 15, 2011 at 1:36 PM, Vinod Koul <vinod.koul@...el.com> wrote:
> 
> > ... skip ...
> > > >
> > > > Second, having ability to pass private target information allows me to pass
> > > > information about remote target device on per-transfer basis.
> > > Okay, then why not pass the dma address and make your dma driver
> > > transparent (i saw you passed RIO address, IIRC 64+2 bits)
> > > Currently using dma_slave_config we pass channel specific information,
> > > things like peripheral address and config don't change typically
> > > between
> > > transfers and if you have some controller specific properties you can
> > > pass them by embedding dma_slave_config in your specific structure.
> > > Worst case, you can configure slave before every prepare
> >
> > In addition to address on target RIO device I need to pass corresponding
> > device destination ID. With single channel capable to transfer data between
> > local memory and different RapidIO devices I have to pass device specific
> > information on per transfer basis (destID + 66-bit address + type of write ops, etc.).
> >
> > Even having 8 channels (each set for specific target) will not help me with
> > full support of RapidIO network where I have 8- or 16-bit destID (256 or 64K
> > devices respectively).
> >
> > RapidIO controller device (and its DMA component) may provide services to
> > multiple device drivers which service individual devices on RapidIO network
> > (similar to PCIe having multiple peripherals, but not using memory mapped
> > model - destID defines route to a device).
> >
> > Generic RapidIO controller may have only one DMA channel which services all
> > target devices forming the network. We may have multiple concurrent data
> > transfer requests for different devices.
> >
> > Parallel discussion with Dan touches the same post-config approach and
> > another option. I like Dan's idea of having RIO-specific version of prep_sg().
> > At the same time my current implementation of rio_dma_prep_slave_sg() with
> > added appropriate locking may do job as well and keeps DMA part within
> > existing API (DMA_RAPIDIO removed).
> Thanks this helps to understand your model.
> 
> Per above you need destID, 66bit address and type of write to be passed
> for each transfer. Looking at your rio_dma_data, i cant see the destID.
> 
destID is extracted by rio_dma_prep_slave_sg() from the rio_dev parameter
and passed down prep_slave_sg() as part of rio_dma_ext structure
(as dchan->private). 

> Nevertheless we have few ways to solve this, pass this using
> dma_slave_config _every-time_ before doing a prep_slave_sg. Or as Dan
> pointed out create RIO specific version. Principally I am not for
> adding
> a subsystem specific stuff, even more when we are talking about
> converging and cutting down on dmaengine API :)
> 
Agree. This is why I am trying to find my way within boundaries of DMA_SLAVE API first.

> Another alternate approach could be to add one more argument to
> prep_slave_sg API which allows us to pass additional runtime specific
> parameters. This can be NULL and unused for existing drivers and used
> in
> RIO and any future subsystems which want to use dmaengine.
> Thoughts...?
> 
This is exactly what I need and it may be useful for future systems.
This makes DMA_SLAVE prepared for variations in device addressing.

Plus, this will make porting RIO DMA to previous kernel versions
relatively easy for those who prefers/requires that.

Based on the fact that you started transition to the new DMA transfer
direction flags, it may be a good time to add that extra argument
to prep_slave_sg().

Alex.