linux-kernel - RE: [PATCHv4] DMAEngine: Define interleaved transfer request api

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:	Mon, 24 Oct 2011 05:36:53 -0700
From:	"Bounine, Alexandre" <Alexandre.Bounine@....com>
To:	Vinod Koul <vinod.koul@...el.com>
CC:	Jassi Brar <jaswinder.singh@...aro.org>,
	Russell King <rmk@....linux.org.uk>,
	"Williams, Dan J" <dan.j.williams@...el.com>,
	Barry Song <21cnbao@...il.com>, <linux-kernel@...r.kernel.org>,
	DL-SHA-WorkGroupLinux <workgroup.linux@....com>,
	Dave Jiang <dave.jiang@...el.com>
Subject: RE: [PATCHv4] DMAEngine: Define interleaved transfer request api

On Sun, Oct 23, 2011 at 11:49 PM, Vinod Koul <vinod.koul@...el.com> wrote:
> 
> On Tue, 2011-10-18 at 10:57 -0700, Bounine, Alexandre wrote:
> 
> > I would like to put a simple example of RIO based system that may
> help to
> > understand our DMA requirements.
> >
> > Consider a platform with one host CPU and several DSP cards connected
> > to it through a switched backplane (transparent for purpose of this
> example).
> >
> > The host CPU has one or more RIO-capable DMA channel and runs device
> > drivers for connected DSP cards. Each device driver is required to
> load
> > an individual program code into corresponding DSP(s). Directly
> addressed
> > writes have a lot of sense.
> >
> > After DSP code is loaded device drivers start DSP program and may
> > participate in data transfers between DSP cards and host CPU. Again
> > messaging type transfers may add unnecessary overhead here compared
> > to direct data reads/writes.
> >
> > Configuration of each DSP card may be different but from host's
> > POV is RIO spec compliant.
> 
> I think we all agree that this fits the dma_slave case :)
> 
> As for changing in dmaengine to u64, if we are thinking this as slave
> usage, then ideally we should not make assumption of the address type
> of
> peripheral so we should only move the dma_slave_config address fields
> to
> u64, if that helps in RIO case. Moving other usages would be insane.
> 
> At this point we have two proposals
> a) to make RIO exceptional case and add RIO specific stuff.
> b) make dmaengine transparent and add additional argument
> in .device_prep_slave_sg() callback which is subsystem dependent.
> Current dmacs and those who don't need it will ignore it.
> 
> ATM, I am leaning towards the latter, for the main reason to keep
> dmaengine away from subsystem details.
> 
Both proposals will work for RapidIO but second option looks more
universal and may be used by another subsystem in the future.
My vote goes to the option b).