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

[Bounine, Alexandre]

On Tue, Oct 11, 2011 at 2:42 PM, Jassi Brar <jaswinder.singh@xxxxxxxxxx> wrote:

> 
> On 11 October 2011 22:14, Williams, Dan J <dan.j.williams@xxxxxxxxx>
> wrote:
> > [ Adding Alexandre ]
> >
> > This is a tangent, but it would be nice if this API extension also
> > covered the needs of the incoming RapidIO case which wants to specify
> > new device context information per operation (and not once at
> > configuration time, like slave case).  Would it be enough if the
> > transfer template included a (struct device *context) member at the
> > end?  Most dma users could ignore it, but RapidIO could use it to do
> > something like:
> >
> >   struct rio_dev *rdev = container_of(context, typeof(*rdev),
> device);
> >
> > That might not be enough, but I'm concerned that making the context a
> > (void *) is too flexible.  I'd rather have something like this than
> > acquiring a lock in rio_dma_prep_slave_sg() and holding it over
> > ->prep().  The alternative is to extend device_prep_slave_sg to take
> > an extra parameter, but that impacts all other slave implementations
> > with a dead parameter.
> >
> From what I read so far, the requirement is closer to prep_slave_sg
> than to this api.
Yes, it is a closest fit so far but with one deficiency - it does not give
me a (natural) way to pass target device parameters for every transaction
that should be initiated.   

> 
> IMO, there should be a virtual channel for each device that the real
> physical channel, at the backend, can transfer data to/from.
> 
> The client driver should request each virtual channel corresponding
> to each target device it wants to transfer data with.
> 
> In the dmac driver - transfers queued for all virtual channels that are
> backed by the same physical channel, could be added to the same
> list and executed in FIFO manner.
> 
> That way, there won't be any need to hook target device info per
> transfer
> and more importantly "struct dma_chan" would continue to mean
> link between fixed 'endpoints'.
Passing a 66-bit RIO address will require an extra parameter anyway.
This brings us back to the problem that I have with the physical slave channel.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/