DMA <=> Memory Manager Interfaces
=================================

Requirements
------------

The DMA manager must convert logical addresses to physical addresses using
the memory manager (SWI OS_Memory currently does this).

The DMA manager must suspend transfers on unsafe pages ie. pages which are
about to be remapped (Service_PagesUnsafe and Service_PagesSafe provides for
this).

The cache must be flushed and logical pages must be marked as uncacheable
during a DMA read from device to memory (so that DMAed data can be read from
memory while the transfer is in progress rather than cached data - this may
be necessary for a sound system).

Someone must keep track of multiple requests to mark pages as uncacheable.


Thoughts
--------

Should the conversion be done before the transfer starts (ie. create a
physical address scatter list) or for each page (called from the DMA manager
interrupt routine)?

1) Converted before the transfer

        Disadvantages:
        - DMA manager must create and maintain at most 6 physical address
          scatter lists (either by OS_Memory or new memory manager call to
          convert a whole scatter list).
        - On Service_PagesUnsafe each physical address scatter list must be
          scanned for the unsafe pages.
        - If a physical address scatter list contains an unsafe page then
          the transfer must be suspended even if the unsafe page has not
          been reached yet (the transfer may reach the page before
          Service_PagesSafe is received).  This is inefficient.

        Advantages:
        - On a DMA read to memory pages can be marked as uncacheable when
          the logical to physical address conversion takes place.  This
          means that the cache can be flushed once for the whole transfer.

2) Converted during the transfer

        Disadvantages:
        - Conversion must be done by calling SWI OS_Memory from the DMA
          manager interrupt routine (not thought too be too bad).
        - On a DMA read to memory only the active page would be marked as
          uncacheable.  This would mean that the cache would have to be
          flushed for each page (may have a performance impact on the rest
          of the system).

        Advantages:
        - On Service_PagesUnsafe only the pages which were being DMAed to
          or from would have to be checked and a transfer need only be
          suspended if the page currently being used was unsafe.  This is
          more efficient than option 1).
        - The DMA manager does not have to create and manage space for
          physical address scatter lists.

3) Combination of 1) and 2)

        Advantages:
        - As for 1) and 2)

        Disadvantages:
        - As for 2) plus:
        - The logical address to physical address conversion would take
          place twice (once up front and then again during the transfer).


Steve Cormie (28/04/93)


Decisions
---------

The memory manager specification will change such that SWI OS_Memory will
convert between address types using a table.  Each entry of the table will
contain 3 words, physical page no., logical address and physical address.
A flags word given in the OS_Memory call will specify which of the 3 entries
is to be converted from and the other entries will be filled in by the
memory manager.  Another bit in the flags word will specify whether the
pages in the table are to be marked as uncacheable or made cacheable again.
The memory manager will keep a count of how many times a page has been made
uncacheable and will only make it cacheable again when the count reaches 0.
Each entry in the table refers to one page and the addresses are page
aligned.

When the DMA manager activates a DMA request the scatter list will be split
down into a table as described above where only the logical address entries
are filled.  SWI OS_Memory will be called to fill in the physical addresses
and to mark the pages as uncacheable (if a read to memory is being
performed).  The DMA manager will then flush the cache and the transfer will
be started.

On Service_PagesUnsafe the DMA manager will be passed a table as above with
information about the unsafe pages.  The DMA manager will scan the tables it
holds looking for matches with the table which has been passed via the
service call.  If a match is found and the page is currently being DMAed to
or from then the transfer is suspended otherwise the page is simply flagged
and the DMA manager must suspend the transfer when it reaches the unsafe
page.

On Service_PagesSafe the DMA manager will be passed two tables as described
above.  The first will contain the old page information and the second will
contain the new page information.  The DMA manager will scan its tables
looking for pages marked as unsafe and change the old physical addresses to
the new physical addresses.  If the transfer concerned had been suspended
then it is restarted with the new physical page address.

If the transfer was from device to memory then the DMA manager will call SWI
OS_Memory when the transfer is complete.  The call will pass in the
(possible modified) table created before the transfer but will not ask for a
conversion to take place only for the pages to be marked as cacheable again. 
The internal table will then be destroyed.

Steve Cormie (30/04/93)
