LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Haavard Skinnemoen <hskinnemoen@norway.atmel.com>
To: Haavard Skinnemoen <hskinnemoen@atmel.com>
Cc: "Dan Williams" <dan.j.williams@intel.com>,
	linux-kernel@vger.kernel.org,
	"Shannon Nelson" <shannon.nelson@intel.com>,
	"David Brownell" <david-b@pacbell.net>,
	kernel@avr32linux.org, "Francis Moreau" <francis.moro@gmail.com>,
	"Paul Mundt" <lethal@linux-sh.org>,
	"Vladimir A. Barinov" <vbarinov@ru.mvista.com>,
	"Pierre Ossman" <drzeus-list@drzeus.cx>
Subject: Re: [RFC v3 4/7] dmaengine: Add slave DMA interface
Date: Fri, 15 Feb 2008 10:53:02 +0100	[thread overview]
Message-ID: <20080215105302.1e4251a3@dhcp-252-066.norway.atmel.com> (raw)
In-Reply-To: <20080213202402.22818482@siona>

On Wed, 13 Feb 2008 20:24:02 +0100
Haavard Skinnemoen <hskinnemoen@atmel.com> wrote:

> But looking at your latest patch series, I guess we can use the new
> "next" field instead. It's not like we really need the full
> capabilities of list_head.

On second thought, if we do this, we would be using the "next" field in
an undocumented way. It is currently documented as follows:

 * @next: at completion submit this descriptor

But that's not how we're going to use it when doing slave transfers:
We're using it to keep track of all the descriptors that have already
been submitted.

I think it would actually be better to go the other way and have the
async_tx API extend the descriptor as well for its private fields. That
way, we get the pointer we need, but we can document it differently.

So how about we do something along the lines of the patch below? We
need to update all the users too of course, but apart from making the
dma_slave_descriptor struct smaller, I don't think it will change the
actual memory layout at all.

Haavard

diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 9bb3407..abaf324 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -267,8 +267,7 @@ struct dma_client {
 
 typedef void (*dma_async_tx_callback)(void *dma_async_param);
 /**
- * struct dma_async_tx_descriptor - async transaction descriptor
- * ---dma generic offload fields---
+ * struct dma_descriptor - generic dma offload descriptor
  * @cookie: tracking cookie for this transaction, set to -EBUSY if
  *	this tx is sitting on a dependency list
  * @ack: the descriptor can not be reused until the client acknowledges
@@ -280,12 +279,8 @@ typedef void (*dma_async_tx_callback)(void *dma_async_param);
  * @tx_submit: set the prepared descriptor(s) to be executed by the engine
  * @callback: routine to call after this operation is complete
  * @callback_param: general parameter to pass to the callback routine
- * ---async_tx api specific fields---
- * @next: at completion submit this descriptor
- * @parent: pointer to the next level up in the dependency chain
- * @lock: protect the parent and next pointers
  */
-struct dma_async_tx_descriptor {
+struct dma_descriptor {
 	dma_cookie_t cookie;
 	int ack;
 	dma_addr_t phys;
@@ -294,6 +289,17 @@ struct dma_async_tx_descriptor {
 	dma_cookie_t (*tx_submit)(struct dma_async_tx_descriptor *tx);
 	dma_async_tx_callback callback;
 	void *callback_param;
+};
+
+/**
+ * struct dma_async_tx_descriptor - async transaction descriptor
+ * @dma: generic dma descriptor
+ * @next: at completion submit this descriptor
+ * @parent: pointer to the next level up in the dependency chain
+ * @lock: protect the parent and next pointers
+ */
+struct dma_async_tx_descriptor {
+	struct dma_descriptor dma;
 	struct dma_async_tx_descriptor *next;
 	struct dma_async_tx_descriptor *parent;
 	spinlock_t lock;
@@ -301,13 +307,13 @@ struct dma_async_tx_descriptor {
 
 /**
  * struct dma_slave_descriptor - extended DMA descriptor for slave DMA
- * @async_tx: async transaction descriptor
- * @client_node: for use by the client, for example when operating on
- *	scatterlists.
+ * @dma: generic dma descriptor
+ * @next: for use by the client, for example to keep track of
+ *	submitted descriptors when dealing with scatterlists.
  */
 struct dma_slave_descriptor {
-	struct dma_async_tx_descriptor txd;
-	struct list_head client_node;
+	struct dma_descriptor dma;
+	struct dma_slave_descriptor *next;
 };
 
 /**

  reply	other threads:[~2008-02-15  9:53 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-12 16:43 [RFC v3 1/7] dmaengine: Couple DMA channels to their physical DMA device Haavard Skinnemoen
2008-02-12 16:43 ` [RFC v3 2/7] dmaengine: Add dma_client parameter to device_alloc_chan_resources Haavard Skinnemoen
2008-02-12 16:43   ` [RFC v3 3/7] dmaengine: Add dma_chan_is_in_use() function Haavard Skinnemoen
2008-02-12 16:43     ` [RFC v3 4/7] dmaengine: Add slave DMA interface Haavard Skinnemoen
2008-02-12 16:43       ` [RFC v3 5/7] dmaengine: Make DMA Engine menu visible for AVR32 users Haavard Skinnemoen
2008-02-12 16:43         ` [RFC v3 6/7] dmaengine: Driver for the Synopsys DesignWare DMA controller Haavard Skinnemoen
2008-02-12 16:43           ` [RFC v3 7/7] Atmel MCI: Driver for Atmel on-chip MMC controllers Haavard Skinnemoen
2008-02-12 20:43         ` [RFC v3 5/7] dmaengine: Make DMA Engine menu visible for AVR32 users Olof Johansson
2008-02-12 22:13           ` Haavard Skinnemoen
2008-02-12 22:27             ` Dan Williams
2008-02-13  8:44               ` Haavard Skinnemoen
2008-02-13  7:21       ` [RFC v3 4/7] dmaengine: Add slave DMA interface Dan Williams
2008-02-13  8:03         ` Haavard Skinnemoen
2008-02-13 19:07       ` Dan Williams
2008-02-13 19:24         ` Haavard Skinnemoen
2008-02-15  9:53           ` Haavard Skinnemoen [this message]
2008-02-15 17:12             ` Nelson, Shannon
2008-02-18 13:29               ` Haavard Skinnemoen
2008-02-19 18:46                 ` Nelson, Shannon
2008-02-16 20:06             ` Dan Williams
2008-02-18 13:22               ` Haavard Skinnemoen
2008-02-18 22:42                 ` Dan Williams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080215105302.1e4251a3@dhcp-252-066.norway.atmel.com \
    --to=hskinnemoen@norway.atmel.com \
    --cc=dan.j.williams@intel.com \
    --cc=david-b@pacbell.net \
    --cc=drzeus-list@drzeus.cx \
    --cc=francis.moro@gmail.com \
    --cc=hskinnemoen@atmel.com \
    --cc=kernel@avr32linux.org \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shannon.nelson@intel.com \
    --cc=vbarinov@ru.mvista.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).