Messages in this thread | | | Date | Wed, 12 Oct 2011 00:12:05 +0530 | Subject | Re: [PATCHv4] DMAEngine: Define interleaved transfer request api | From | Jassi Brar <> |
| |
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.
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'. -- 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/
| |