All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Hervé Poussineau" <hpoussin@reactos.org>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC] Floppy controller: break relation with	PC-style DMA
Date: Sat, 22 Nov 2008 14:48:06 +0100	[thread overview]
Message-ID: <49280D96.8030001@reactos.org> (raw)
In-Reply-To: <f43fc5580811220402y669fa5a7hf75d52304e1c807f@mail.gmail.com>

Blue Swirl a écrit :
> On 11/22/08, Hervé Poussineau <hpoussin@reactos.org> 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).
> 
> 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 
transfer. I suppose the check should be moved to DMA engine, or at least 
to the _read and _write handlers.
b) There is also the problem at initialization, where each i8257 client 
calls DMA_register_channel() to register itself, and gives a callback 
function (fdctrl_transfer_handler for fdc.c).
c) This callback will then be called to feed destination DMA buffer part 
by part (see dma_pos and dma_len in fdctrl_transfer_handler), instead of 
in one big transfer. That also explains the data_pos parameter when 
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 
controller is using its own scheme.
For me, a first step in this direction is to break links between devices 
and DMA engines, like it has already be done for esp adapter. Then, 
something good can emerge.
You should also notice that I chose _read and _write callbacks for fdc 
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 
initialization, and then, DMA should be avoided/prevented if they are 
not defined.

Hervé

  reply	other threads:[~2008-11-22 13:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-22  8:32 [Qemu-devel] [RFC] Floppy controller: break relation with PC-style DMA Hervé Poussineau
2008-11-22 12:02 ` Blue Swirl
2008-11-22 13:48   ` Hervé Poussineau [this message]
2008-11-22 14:27     ` Blue Swirl

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=49280D96.8030001@reactos.org \
    --to=hpoussin@reactos.org \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.