[RFC][PATCH] DMA: Expand dmaengine implementation for more DMACs

[RFC][PATCH] DMA: Expand dmaengine implementation for more DMACs

[Peter Pearse]

Hi,

The existing DMAC used by the dmaengine API (Intel IOAT) assumes all 
possible clients can use any available DMA channel.

Some other DMACs restrict particular peripherals to particular DMA channels.

The patch below (against v2.6.22-rc7) extends the dmaengine implementation 
to allow such DMACs to differentiate between clients.

Regards

Peter Pearse

---
From: Peter Pearse <peter.pearse@arm.com>

Pass client data down to the dmaengine DMAC implementation code.

Signed-off-by: Peter Pearse <peter.pearse@arm.com> 
---
diff -purN RFCbase/drivers/dma/dmaengine.c
RFCpatched/drivers/dma/dmaengine.c
--- RFCbase/drivers/dma/dmaengine.c	2007-07-02 09:38:15.124179000 +0100
+++ RFCpatched/drivers/dma/dmaengine.c	2007-07-03 15:16:45.550630000 +0100
@@ -146,7 +146,7 @@ static struct dma_chan *dma_client_chan_
 			if (chan->client)
 				continue;
 
-			desc =
chan->device->device_alloc_chan_resources(chan);
+			desc =
chan->device->device_alloc_chan_resources(chan, client);
 			if (desc >= 0) {
 				kref_get(&device->refcount);
 				kref_init(&chan->refcount);
diff -purN RFCbase/drivers/dma/ioatdma.c RFCpatched/drivers/dma/ioatdma.c
--- RFCbase/drivers/dma/ioatdma.c	2007-07-02 09:38:15.129184000 +0100
+++ RFCpatched/drivers/dma/ioatdma.c	2007-07-03 12:58:01.525560000 +0100
@@ -110,7 +110,7 @@ static struct ioat_desc_sw *ioat_dma_all
 static void ioat_start_null_desc(struct ioat_dma_chan *ioat_chan);
 
 /* returns the actual number of allocated descriptors */
-static int ioat_dma_alloc_chan_resources(struct dma_chan *chan)
+static int ioat_dma_alloc_chan_resources(struct dma_chan, struct dma_client
*client)
 {
 	struct ioat_dma_chan *ioat_chan = to_ioat_chan(chan);
 	struct ioat_desc_sw *desc = NULL;
diff -purN RFCbase/include/linux/dmaengine.h
RFCpatched/include/linux/dmaengine.h
--- RFCbase/include/linux/dmaengine.h	2007-07-02 09:39:08.954261000 +0100
+++ RFCpatched/include/linux/dmaengine.h	2007-07-03
15:46:33.552608000 +0100
@@ -143,6 +143,8 @@ typedef void (*dma_event_callback) (stru
  * @event_callback: func ptr to call when something happens
  * @chan_count: number of chans allocated
  * @chans_desired: number of chans requested. Can be +/- chan_count
+ * @client_data: ptr to data which allows implementations to distinguish
+ *               between clients
  * @lock: protects access to the channels list
  * @channels: the list of DMA channels allocated
  * @global_node: list_head for global dma_client_list
@@ -151,6 +153,7 @@ struct dma_client {
 	dma_event_callback	event_callback;
 	unsigned int		chan_count;
 	unsigned int		chans_desired;
+	void *client_data;
 
 	spinlock_t		lock;
 	struct list_head	channels;

Re: [RFC][PATCH] DMA: Expand dmaengine implementation for more DMACs

[Dan Williams]

On 7/3/07, Peter Pearse <peter.pearse@arm.com> wrote:
> Hi,
>
> The existing DMAC used by the dmaengine API (Intel IOAT) assumes all
> possible clients can use any available DMA channel.
>
> Some other DMACs restrict particular peripherals to particular DMA channels.
>
> The patch below (against v2.6.22-rc7) extends the dmaengine implementation
> to allow such DMACs to differentiate between clients.
>
Hi Peter,

Have a look at:
http://marc.info/?l=linux-raid&m=118290909528910&w=2
http://marc.info/?l=linux-raid&m=118290909523734&w=2

It seems your requirement could be satisfied by a natural extension of
the 'dma_cap_mask' implementation.  'dma_cap_mask' allows clients to
only be notified of channels that meet a certain capability profile.

However since your driver is pretty much guaranteed to be the only
dmaengine driver in the system you can safely do something like the
following in your client callback:

static enum dma_state_client
my_dma_client_callback(struct dma_client *client,
			struct dma_chan *chan, enum dma_state state)
{
	struct dma_device *dma_dev;
	struct my_platform_specific_dma *plat_dma_dev;
	
	dma_dev = chan->device;
	plat_dma_dev = container_of(dma_dev, struct my_platform_specific_dma, dma_dev);

	if (!plat_dma_dev->platform_specific_capability)
		return DMA_DUP;

	. . .
}

> Regards
>
> Peter Pearse
>

--
Dan

RE: [RFC][PATCH] DMA: Expand dmaengine implementation for more DMACs

[Nelson, Shannon]

Dan Williams [mailto:dan.j.williams@gmail.com] 
>On 7/3/07, Peter Pearse <peter.pearse@arm.com> wrote:
>> Hi,
>>
>> The existing DMAC used by the dmaengine API (Intel IOAT) assumes all
>> possible clients can use any available DMA channel.
>>
>> Some other DMACs restrict particular peripherals to 
>particular DMA channels.
>>
>> The patch below (against v2.6.22-rc7) extends the dmaengine 
>implementation
>> to allow such DMACs to differentiate between clients.
>>
>Hi Peter,
>
>Have a look at:
>http://marc.info/?l=linux-raid&m=118290909528910&w=2
>http://marc.info/?l=linux-raid&m=118290909523734&w=2
>
>It seems your requirement could be satisfied by a natural extension of
>the 'dma_cap_mask' implementation.  'dma_cap_mask' allows clients to
>only be notified of channels that meet a certain capability profile.
>
>However since your driver is pretty much guaranteed to be the only
>dmaengine driver in the system you can safely do something like the
>following in your client callback:
>

Peter,

If the client is looking for a specific channel capability, that can be
worked with Dan's version of the interface as he suggests with the
dma_cap_mask.  However, it sounds like you need not just channel
capabilities, but also client capabilities information, which I assume
you would carry in the "void *client_data" that you suggested, allowing
the DMAC itself to Ack/Nak the provisioning.  Dan's other suggestion
below has the client controlling the provisioning by accepting a
particular channel.  If the DMAC is the one that has the restriction
information and needs to enforce the restriction based on the specific
client, I suspect this may not help.

Can you give us an example of exactly how your DMAC restriction works?

Is it possible for you to pull this off with the suggested dma_cap_mask?
The only info the client would need is the particular capability bit for
a specific channel type.

Thanks,
sln