Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764569AbYBOJxU (ORCPT ); Fri, 15 Feb 2008 04:53:20 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755727AbYBOJxL (ORCPT ); Fri, 15 Feb 2008 04:53:11 -0500 Received: from nat-132.atmel.no ([80.232.32.132]:64428 "EHLO relay.atmel.no" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755722AbYBOJxJ (ORCPT ); Fri, 15 Feb 2008 04:53:09 -0500 Date: Fri, 15 Feb 2008 10:53:02 +0100 From: Haavard Skinnemoen To: Haavard Skinnemoen Cc: "Dan Williams" , linux-kernel@vger.kernel.org, "Shannon Nelson" , "David Brownell" , kernel@avr32linux.org, "Francis Moreau" , "Paul Mundt" , "Vladimir A. Barinov" , "Pierre Ossman" Subject: Re: [RFC v3 4/7] dmaengine: Add slave DMA interface Message-ID: <20080215105302.1e4251a3@dhcp-252-066.norway.atmel.com> In-Reply-To: <20080213202402.22818482@siona> References: <1202834638-9009-1-git-send-email-hskinnemoen@atmel.com> <1202834638-9009-2-git-send-email-hskinnemoen@atmel.com> <1202834638-9009-3-git-send-email-hskinnemoen@atmel.com> <1202834638-9009-4-git-send-email-hskinnemoen@atmel.com> <20080213202402.22818482@siona> Organization: Atmel Norway X-Mailer: Claws Mail 3.2.0 (GTK+ 2.12.5; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3740 Lines: 97 On Wed, 13 Feb 2008 20:24:02 +0100 Haavard Skinnemoen 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; }; /** -- 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/