From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Kt9Ne-0001gk-Vy
	for qemu-devel@nongnu.org; Thu, 23 Oct 2008 19:14:15 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Kt9Na-0001f1-Lt
	for qemu-devel@nongnu.org; Thu, 23 Oct 2008 19:14:14 -0400
Received: from [199.232.76.173] (port=56398 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Kt9Na-0001ey-Gp
	for qemu-devel@nongnu.org; Thu, 23 Oct 2008 19:14:10 -0400
Received: from mail.codesourcery.com ([65.74.133.4]:54279)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1Kt9NZ-00051x-JY
	for qemu-devel@nongnu.org; Thu, 23 Oct 2008 19:14:10 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH][RFT] Make DMA timer driven
Date: Fri, 24 Oct 2008 00:13:49 +0100
References: <1224797417-26044-1-git-send-email-aliguori@us.ibm.com>
	<20081023220453.GA15547@edgar.se.axis.com>
In-Reply-To: <20081023220453.GA15547@edgar.se.axis.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200810240013.50522.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: Anthony Liguori <aliguori@us.ibm.com>, "Edgar E. Iglesias" <edgar.iglesias@axis.com>

> You can find info regarding CRIS/ETRAX testing here:
> http://lists.gnu.org/archive/html/qemu-devel/2008-09/msg00279.html
>
> I tested the patch. It works but unfortunately DMA transfers to/from
> the ethernet block now seem to emulate very slowly.

Is there a reason you're deferring the DMA transfers, rather than completing 
them immediately? In most cases you want to do the DMA as soon as both ends 
are ready, and there's no benefit artificially delaying things. Any delay is 
entirely arbitrary, and won't work reliably.

Paul