Re: AW: [MiNT] analysing syscall.spp

[Michael Schwingen <rincewind@discworld.dascon.de>]

On Sun, Apr 18, 1999 at 05:12:50PM +0200, Johan Klockars wrote:
> It could work something like this, for example:
> 1 The file system tells the device driver (HDDriver) that it wants to
>   transfer a block of data and be notified when it's done.
> 2 The FS code blocks on a semaphore or similar, thereby leaving all
>   processor time for other tasks.

2a another task wants to access a filesystem.  

If I understand the Magic approach right, then this task would go through
the filesystem and disk driver level on Magic *while* the other request is
still running, provided the device sits on a different physical bus.

Even when the same physical bus is accessed, it may be advantageous to have
multiple accesses come down to the lowlevel disk driver level: this is
actually *needed* to that the disk driver and the disk can fully use tagged
command queueing and reorder the requests in a order which provides maximum
throughput.

> 3 When a transfer is completed, the device driver wakes up the FS again,
>   which may initiate another transfer (goto 1) or return to the caller.

Which would disable all concurrent accesses to different drives, and
(depending on where the lock is), you might even block accesses that the FS
could handle from the caches without needing any disk access at all.

> Since HDDriver is not MiNT-aware, I guess the way to deal with step 3
> is to make the file system code wait for the 'DMA-complete' interrupt
> itself. IIRC, MiNT already can treat interrupts like signals, so it should
> be possible to handle that.

No. That may be possible on original Atari hardware (Magic provides routines
that do just that for background DMA).

However, as soon as we are talking about PCI cards, you have multiple
problems:
 - an interrupt need not mean the end of the DMA transfer - on a 53C8xx, it
   can mean anything that the RISC CPU can not handle, ie. an empty
   scatter/gather list, phase mispatch etc., in which case the driver needs
   to restart the RISC core and wait again.
 - There may be multiple PCI cards sitting on the same interrupt line. In
   this case, *only* the driver handling the card can know if the interrupt was
   for his card, or not.

These are two reasons that come to mind that make it impossible (or at least
a very bad idea, IMHO) for the kernel to know about interrupts ending DMA -
the lowlevel driver has to issue the command to tell the kernel that the
transfer is started/ended - and this *will* come from an interrupt.

You might get a scheme working without kernel calls from interrupts -
however, I think it might get a bit clumsy, and not as efficient as
possible.

cu
Michael
-- 
Michael Schwingen, Ahornstrasse 36, 52074 Aachen