Messages in this thread |  | | | Subject | RE: [PATCHv4] DMAEngine: Define interleaved transfer request api | | Date | Fri, 14 Oct 2011 11:11:11 -0700 | | From | "Bounine, Alexandre" <> |
| |
On Tue, Oct 11, 2011 at 2:42 PM, Jassi Brar <jaswinder.singh@linaro.org> wrote:
> > On 11 October 2011 22:14, Williams, Dan J <dan.j.williams@intel.com> > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |