From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L3sqI-0004ul-Cj for qemu-devel@nongnu.org; Sat, 22 Nov 2008 08:48:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L3sqG-0004uZ-Ne for qemu-devel@nongnu.org; Sat, 22 Nov 2008 08:48:09 -0500 Received: from [199.232.76.173] (port=43461 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L3sqG-0004uW-HF for qemu-devel@nongnu.org; Sat, 22 Nov 2008 08:48:08 -0500 Received: from smtp7-g19.free.fr ([212.27.42.64]:46676) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L3sqG-0000G9-7d for qemu-devel@nongnu.org; Sat, 22 Nov 2008 08:48:08 -0500 Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id 040ECB012E for ; Sat, 22 Nov 2008 14:48:07 +0100 (CET) Received: from [192.168.0.32] (rob92-10-88-171-126-33.fbx.proxad.net [88.171.126.33]) by smtp7-g19.free.fr (Postfix) with ESMTP id D21C7B013A for ; Sat, 22 Nov 2008 14:48:06 +0100 (CET) Message-ID: <49280D96.8030001@reactos.org> Date: Sat, 22 Nov 2008 14:48:06 +0100 From: =?UTF-8?B?SGVydsOpIFBvdXNzaW5lYXU=?= MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] Floppy controller: break relation with PC-style DMA References: <4927C38C.20508@reactos.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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 Blue Swirl a =C3=A9crit : > On 11/22/08, Herv=C3=A9 Poussineau wrote: >> Hi, >> >> Currently, floppy disk controller is tied to PC-style DMA controller. >> Attached patch is an attempt to break the link between those, by >> introducing function pointers for dma operations (read, write, hold, >> release). >=20 > Isn't it possible to move the i8257 DMA helpers to for example dma.c? > Then I could eliminate some dummy DMA_xx functions from sun4m.c and I > think fdctrl_i8257_init would not be needed. That's a little bit hard for 3 reasons: a) i8257_dma_hold() checks if DMA is well programmed before doing the=20 transfer. I suppose the check should be moved to DMA engine, or at least=20 to the _read and _write handlers. b) There is also the problem at initialization, where each i8257 client=20 calls DMA_register_channel() to register itself, and gives a callback=20 function (fdctrl_transfer_handler for fdc.c). c) This callback will then be called to feed destination DMA buffer part=20 by part (see dma_pos and dma_len in fdctrl_transfer_handler), instead of=20 in one big transfer. That also explains the data_pos parameter when=20 calling DMA_read_memory/DMA_write_memory Yet, I've no good idea to solve problem b) and c). I suppose we really need a generic DMA framework, as it seems each DMA=20 controller is using its own scheme. For me, a first step in this direction is to break links between devices=20 and DMA engines, like it has already be done for esp adapter. Then,=20 something good can emerge. You should also notice that I chose _read and _write callbacks for fdc=20 to be exactly the same as in esp. > You are calling fdctrl->dma_memory_write and _read without checking > that they are not NULL. Ok, I'll add checks for fdctrl->dma_memory_write and _read. In all cases, one without the other should be an error at=20 initialization, and then, DMA should be avoided/prevented if they are=20 not defined. Herv=C3=A9