RE: [PATCHv4] DMAEngine: Define interleaved transfer request api

[Bounine, Alexandre]

On Sun, Oct 23, 2011 at 11:49 PM, Vinod Koul <vinod.koul@xxxxxxxxx> 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).


èº{.nÇ+‰·Ÿ®‰­†+%ŠËlzwm…ébëæìr¸›zX§»®w¥Š{ayºÊÚë,j­¢f£¢·hš‹àz¹®w¥¢¸¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾«‘êçzZ+ƒùšŽŠÝj"ú!¶iO•æ¬z·švØ^¶m§ÿðÃnÆàþY&—