From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH 2/6] PCI DMA API (v2) Date: Sun, 6 Apr 2008 19:40:36 -0500 Message-ID: <200804061940.37403.paul@codesourcery.com> References: <1207368175-19476-1-git-send-email-aliguori@us.ibm.com> <47F8EAAB.2080806@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Blue Swirl , kvm-devel@lists.sourceforge.net, andrzej zaborowski To: qemu-devel@nongnu.org Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org > As a note, the DMA controllers in the ARM system-on-chip's can > byte-swap, do 90deg rotation of 2D arrays, transparency (probably > intened for image blitting, but still available on any kind of > transfers), etc., and most importantly issue interrupts on reaching > different points of a transfer. It is not worth worrying about them > in this API. I have been for some time wanting to make a separate api > called soc_dma whose task would be using simply memcpy (or zero-copy) > in the most basic case (interrupts off, no transparency, > same-endianness endpoints), as these properties are common for DMA on > the TI OMAPs, the Intel PXAs and the Samsung S3Cs (which otherwise > have little in common). Are you sure you aren't confusing the DMA engine itelf (which is just annother peripheral) with a mechanism for allowing dma engines access to the system. Paul ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JifPl-0005Xj-IZ for qemu-devel@nongnu.org; Sun, 06 Apr 2008 20:40:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JifPk-0005To-2Z for qemu-devel@nongnu.org; Sun, 06 Apr 2008 20:40:49 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JifPj-0005Tc-UW for qemu-devel@nongnu.org; Sun, 06 Apr 2008 20:40:47 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JifPj-0003kC-FT for qemu-devel@nongnu.org; Sun, 06 Apr 2008 20:40:47 -0400 From: Paul Brook Subject: Re: [kvm-devel] [Qemu-devel] [PATCH 2/6] PCI DMA API (v2) Date: Sun, 6 Apr 2008 19:40:36 -0500 References: <1207368175-19476-1-git-send-email-aliguori@us.ibm.com> <47F8EAAB.2080806@codemonkey.ws> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804061940.37403.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Blue Swirl , kvm-devel@lists.sourceforge.net > As a note, the DMA controllers in the ARM system-on-chip's can > byte-swap, do 90deg rotation of 2D arrays, transparency (probably > intened for image blitting, but still available on any kind of > transfers), etc., and most importantly issue interrupts on reaching > different points of a transfer. It is not worth worrying about them > in this API. I have been for some time wanting to make a separate api > called soc_dma whose task would be using simply memcpy (or zero-copy) > in the most basic case (interrupts off, no transparency, > same-endianness endpoints), as these properties are common for DMA on > the TI OMAPs, the Intel PXAs and the Samsung S3Cs (which otherwise > have little in common). Are you sure you aren't confusing the DMA engine itelf (which is just annother peripheral) with a mechanism for allowing dma engines access to the system. Paul