TweetFollow Us on Twitter

December 95 - The New Device Drivers: Memory Matters

The New Device Drivers: Memory Matters

Martin Minow

If you're writing a device driver for the new PCI-based Macintosh computers, you need to understand the relationship of the memory an application sees to the memory the hardware device sees. The support for these drivers (which will also run under Copland, the next generation of the Mac OS) includes the PrepareMemoryForIO function, as discussed in my article in Issue 22. This single coherent facility connects the application's logical view of memory to the hardware device's physical view. PrepareMemoryForIO has proven difficult to understand; this article should help clarify its use.

If you managed to struggle through my article "Creating PCI Device Drivers" in develop Issue 22, you probably noticed that it got rather vague toward the end when I tried to describe how the PrepareMemoryForIO function works. There are a few reasons for this: the article was getting pretty long and significantly overdue (the excuse), and I really didn't understand the function that well myself (the reason). Things are a bit better now, thanks to the enforced boredom of a very long trip, the need to teach this algorithm to a group of developers, and some related work I'm doing on the SCSI interface for Copland.

My previous article showed the simple process of preparing a permanent data area that might be used by a device driver to share microcode or other permanent information with a device. This article attacks a number of more complex problems that appear when a device performs direct memory access (DMA) transfers to or from a user data area. It also explores issues that arise if data transfers are needed in situations where the device's hardware cannot use DMA.

A later version of the sample device driver that accompanied the Issue 22 article is included in its entirety on this issue's CD. Of course, you'll need a hardware device to use the driver and updated headers and libraries to recompile it. Included is the source code for the DMA support library (files DMATransfer.c and DMATransfer.h), which consists of several functions I've written that interact with PrepareMemoryForIO; the revised sample device driver shows how this library can be incorporated into a complete device driver for PCI-based Power Macintosh computers.

I'll assume that you've read my earlier article (which you can find on the CD if you don't have it in print). That article gives an overview of the new device driver architecture and touches on the PrepareMemoryForIO function, but for a comprehensive description of the architecture and details about the function, see Designing PCI Cards and Drivers for Power Macintosh Computers (available from Apple Developer Catalog). I'll also assume that you're reasonably familiar with the basic concepts of a virtual memory operating system, including memory pages and logical and physical addresses; for a brief review, see "Virtual Memory on the Macintosh."


    VIRTUAL MEMORY ON THE MACINTOSH

    BY DAVE SMITH

    Virtual memory on the Macintosh has two major functions: it increases the apparent size of RAM transparently by moving data back and forth from a disk file, and it remaps addresses. Of the two, remapping addresses is more relevant to device driver developers (and, incidentally, much more of a headache).

    When Macintosh virtual memory is turned on, the processor and the code running on the processor always access logical addresses. A logical address is used the same way as a physical address; however, the Memory Management Unit (MMU) integrated into the processor remaps the logical address on the fly to a physical address if the data is resident in memory. If the data isn't resident in memory, a page fault occurs; this requires reading the desired data into memory from the disk and possibly writing other, unneeded data from memory to the disk to free up space in memory. (This explanation is slightly simplified, of course.)

    Since it would be impractical to have a mapping for each byte address, memory is subdivided into blocks called pages. A page is the smallest unit that can be remapped. Memory is broken into pages on page boundaries, which are page-size intervals starting at 0. The remapping allows physical pages that are not actually contiguous in physical memory to appear contiguous in the logical address space.

    The Macintosh currently uses a page size of 4096 bytes; however, future hardware may use a different page size. You should call the GetLogicalPageSize function in the Driver Services Library to determine the page size if you need it.

    DMA is performed on physical addresses since the MMU of the processor is not on the address bus that devices use. One of the functions of PrepareMemoryForIO is to translate logical addresses into physical addresses so that devices can copy data directly to and from the appropriate buffers.

    Many virtual memory systems provide multiple logical address spaces to prevent applications from interfering with each other. It appears to each application that it has its own memory system, not shared with any other application. The Macintosh currently has only one logical address space, but future releases of the Mac OS will support multiple logical address spaces.

PREPARING MEMORY FOR A USER DATA TRANSFER

At the beginning of a user data transfer (a data transfer on behalf of a program that's calling into your driver), the device driver calls PrepareMemoryForIO to determine the physical addresses of the data and to ensure the coherency of memory caches. At the end of the transfer, the driver calls the CheckpointIO function to release system resources and adjust caches, if necessary. PrepareMemoryForIO performs three functions that are necessary for DMA transfers: it locates data in physical memory; it ensures that the data locations contain the actual data needed or provided by the device; and, with the help of CheckpointIO, it maintains cache coherence.

Your device driver can call PrepareMemoryForIO from task level, from a software interrupt, or from the mainline driver function (that is, DoDriverIO). CheckpointIO can be called from task level, from a software interrupt, or from a secondary interrupt handler. (For more on the available levels of execution, see "Execution Levels for Code on the PCI-Based Macintosh.") In a short while, we'll see how the fact that these functions must be called from particular points affects the transfer process.


    EXECUTION LEVELS FOR CODE ON THE PCI-BASED MACINTOSH

    BY TOM SAULPAUGH

    Native code on PCI-based Macintosh computers may run in any of four execution contexts: software interrupt, secondary interrupt, primary interrupt, or task. All driver code contexts have access to a driver's global data. No special work (such as calling the SetA5 function on any of the 680x0 processors) is needed to access globals from any of these contexts.

    SOFTWARE INTERRUPT

    A software interrupt routine runs within the execution environment of a particular task. Running a software interrupt routine in a task is like forcing the task to call a specific subroutine asynchronously. When the software interrupt routine exits, the task resumes its activities. A software interrupt routine affects only the task in which it's run; the task can still be preempted so that other tasks can run. Those tasks, in turn, can run their own software interrupt routines, and a task running a software interrupt routine can be interrupted by a primary or secondary interrupt handler.

    All software interrupt routines for a particular task are serialized; they don't interrupt each other, so there's no equivalent to the 680x0 model of nested primary interrupt handlers.

    Page faults are allowed from software interrupt routines. A software interrupt routine is analogous to a Posix signal or a Windows NT asynchronous procedure call. A software interrupt routine running in the context of an application, INIT, or cdev doesn't have access to a driver's global data.

    SECONDARY INTERRUPT

    The secondary interrupt level is the execution context provided to a device driver's secondary interrupt handler. In this context, hardware interrupts are enabled and additional interrupts may occur. A secondary interrupt handler is a routine that runs in privileged mode with primary interrupts enabled but task switching disabled.

    All secondary interrupt handlers are serialized, and they never interrupt primary interrupt handlers; in other words, they resemble primary interrupt handlers but have a lower priority. Thus, a secondary interrupt handler queued from a primary interrupt handler doesn't execute until the primary interrupt handler exits, while a secondary interrupt handler queued from a task executes immediately.

    Page faults are not allowed at primary or secondary interrupt level. A secondary interrupt handler is analogous to a deferred task in Mac OS System 7 or a Windows NT deferred procedure call. Secondary interrupt handlers, like primary interrupt handlers, should be used only by device drivers. Never attempt to run application, INIT, or cdev code in this context or at primary interrupt level.

    PRIMARY INTERRUPT

    The primary interrupt level (also called hardware interrupt level) is the execution context in which a device's primary interrupt handler runs. Here, primary interrupts of the same or lower priority are disabled, the immediate needs of the device that caused the interrupt are serviced, and any actions that must be synchronized with the interrupt are performed. The primary interrupt handler is the routine that responds directly to a hardware interrupt. It usually satisfies the source of the interrupt and queues a secondary interrupt handler to perform the bulk of the servicing.

    TASK (NON-INTERRUPT)

    The task level (also called non-interrupt level) is the execution environment for applications and other programs that don't service interrupts. Page faults are allowed in this context.

If the data is currently in physical memory, PrepareMemoryForIO locks the memory page containing the data so that it cannot be relocated. If the data isn't in physical memory, PrepareMemoryForIO calls the virtual memory subsystem and a page fault occurs, reorganizing physical memory to make space in it for the data. After the transfer finishes, CheckpointIO releases the memory page locks.

PrepareMemoryForIO and CheckpointIO perform an important function related to the use of caches. A cache is a private, very fast memory area that the CPU can access at full speed. The processor runs much faster than its memory runs; to keep the processor running at its best speed, the CPU copies data from main memory to a cache. Both the PowerPC and the Motorola 68040 processors support caching, although their implementation details differ. The important point is that a value of a data item in memory can differ from the value for the same data item in the cache (called cache incoherence). Furthermore, you have to explicitly tell the PowerPC or 680x0 processor to synchronize the cache with memory.

Normally, the processor hardware prevents cache incoherence from causing data value problems. However, for some processor architectures, DMA transfers access main memory independently of the processor cache. PrepareMemoryForIO (for write operations) and CheckpointIO (for read operations) synchronize the processor cache with main memory. This means that DMA write operations write the valid contents of memory, and the processor uses the valid data just read from the external device.

As noted earlier, some devices cannot perform DMA transfers; instead, they use programmed I/O, in which the CPU moves data between logical addresses and the device. PrepareMemoryForIO also returns the logical address that such devices must use.

A SIMPLE MEMORY PREPARATION EXAMPLE

Listing 1 presents a very simple example that shows how a memory area may be prepared for I/O.
    To simplify listings, I've often omitted data type casting. Think of all data types as unsigned 32-bit integers. Because of this omission, you can't implement these listings as written, but should base your code on the sample on this issue's CD.*
Listing 1. Simplified memory preparation
#define kBufferSize   512
#define kMapCount      2
/* The buffer your driver or application is preparing */
UInt8                  gMyBuffer[kBufferSize];
IOPreparationTable   gIOTable;
/* Logical & physical mapping tables, */
/* filled in by PrepareMemoryForIO */
LogicalAddress         gLogicalMapping[2];
PhysicalAddress      gPhysicalMapping[kMapCount];

void SimpleMemoryPreparation(void)
{
   OSStatus      osStatus;

   gIOTable.options =
      (kIOMinimalLogicalMapping | kIOLogicalRanges | kIOIsInput);
   gIOTable.state = 0;
   gIOTable.addressSpace = kCurrentAddressSpaceID;
   gIOTable.granularity = 0;
   gIOTable.firstPrepared = 0;
   gIOTable.lengthPrepared = 0;
   gIOTable.mappingEntryCount = kMapCount;
   gIOTable.logicalMapping = gLogicalMapping;
   gIOTable.physicalMapping = gPhysicalMapping;
   /* Set the logical address to be mapped and the length of the area
      to be mapped. */
   gIOTable.rangeInfo.range.base = (LogicalAddress) gMyBuffer;
   gIOTable.rangeInfo.range.length = sizeof gMyBuffer;
   /* Call PrepareMemoryForIO and process the preparation. */
   do {
      osStatus = PrepareMemoryForIO(&gIOTable);
      if (osStatus != noErr)
         break;
      MyDriverDMARoutine(...);
      CheckpointIO(gIOTable.preparationID, kNilOptions);
      gIOTable.firstPrepared += gIOTable.lengthPrepared;
   } while ((gIOTable.state & kIOStateDone) == 0);
}
PrepareMemoryForIO is called with one parameter, an IOPreparationTable. Among other things, this table specifies one or more address ranges to prepare (only one, in this example). Each address range is indicated by a starting logical address and a count of the number of bytes in the range.

The IOPreparationTable also points to a logical mapping table and a physical mapping table (gLogicalMapping and gPhysicalMapping in our example). The physical mapping table is where PrepareMemoryForIO returns the page addresses that the driver can use to access the client's buffer during DMA. The logical mapping table is the list of addresses that the driver must use for doing programmed I/O.

The simplest IOPreparationTable options -- kIOMinimalLogicalMapping and kIOLogicalRanges -- are set in this example. The kIOMinimalLogicalMapping flag indicates that only the first and last logical pages need to be mapped, while the kIOLogicalRanges flag indicates that the data (here, the gMyBuffer vector) consists of logical addresses.

Because kIOMinimalLogicalMapping is set, the logical mapping table requires two entries for each address range; we have only one range, so our logical mapping table needs a total of two entries. The physical mapping table requires one entry per page; we set this to two entries because our 512-byte buffer may cross a page boundary. When writing your driver, you can use the GetMapEntryCount function in the DMA support library to compute the actual number of physical mapping table entries needed for an address range.

If the preparation is successful, the driver performs the DMA transfer and calls CheckpointIO to release internal operating system structures that were used by PrepareMemoryForIO. PrepareMemoryForIO sets the kIOStateDone flag in the IOPreparationTable's state field if the entire area has been prepared.

If PrepareMemoryForIO can't prepare the entire area, it doesn't set the kIOStateDone flag, and your driver needs to call PrepareMemoryForIO again with the firstPrepared field updated to reflect the number of bytes prepared in this range of memory. The recall must be done from a software interrupt routine; it cannot be performed from an interrupt handler.

MORE ABOUT MAPPING

Address ranges to be prepared by PrepareMemoryForIO may cross one or more page boundaries and thus may take up two or more pages in physical memory. Figure 1 shows what the physical mapping might look like for two address ranges: the first is more than two pages long and crosses two page boundaries, while the second is an even page long and crosses one page boundary.

Figure 1. Mapping to multiple pages

Each address range maps to an area in physical memory that can be thought of as having up to three sections: the beginning page, the middle pages, and the ending page.

  • Every address range produces a beginning page. Your data may start at an offset into this page, depending on the starting address of the range. This is true for both address ranges in Figure 1. The address in the mapping table for the beginning page points to the beginning of your data in the page. Notice that for the second address range in our example, the logical address for the start of the data, 0x4400, maps to the physical address 0x6400.

  • If your address range maps to three or more pages, some number of middle pages are completely filled with your data. The first address range in Figure 1 illustrates this.

  • If your address range maps to two or more pages, the data on the ending page begins at the beginning of the page, but it may cover only part of the page, depending on the count in your address range.
Unfortunately, there's no simple one-to-one correspondence between entries in the physical and logical mapping tables and the address range (or ranges) that a driver or application specifies when it calls PrepareMemoryForIO. Because of this, the function that controls a driver's DMA or programmed I/O process must iterate through the input address ranges and output mapping tables to compute the address and size of each data transfer segment. As you'll see when you look at the DMA support library on this issue's CD, this turns out to be an extremely complex process.

The DMA support library functions iterate through the address ranges and mapping tables, matching the two together to provide each data transfer segment in order. The library recognizes when two physical pages are contiguous and extends the data transfer length as far as possible.

When called for the example in Figure 1, the DMA support library returns five physical transfer segments (this example doesn't demonstrate logical alignment problems). To learn how PrepareMemoryForIO's algorithm works, I'd recommend that you work out the actual addresses and segment transfer lengths using pencil and paper. (When you look at the DMA support library in DMATransfer.c, you'll see a more mechanized approach that I strongly recommend if you're developing complex software.)

THE DATA TRANSFER PROCESS

Figure 2 illustrates how a data transfer might proceed through the system. It shows the five steps involved in a transfer that requires partial preparation of a large chunk of data that can't be prepared in one gulp. The diagram also shows the proper execution levels for each step. As we'll see later, the process is considerably simpler without partial preparation.

Figure 2. The progress of a data transfer with partial preparation

Here's a breakdown of the steps in the data transfer:

    1. The transfer starts at task (application or driver mainline) level. The driver must call PrepareMemoryForIO from task level because PrepareMemoryForIO may require virtual memory page faults and has to reserve system memory for its own tables. After memory is prepared, the driver examines the logical and physical mapping tables and starts the DMA operation. It then waits for an interrupt. (Of course, the actual driver behavior depends on your hardware.)

    2. When the driver's primary interrupt handler runs, it determines that another DMA transfer is needed, but that no more data is prepared (because the number of bytes transferred equals the value in the lengthPrepared field in the IOPreparationTable). Since another partial preparation must be performed, the primary interrupt handler queues a secondary interrupt and exits the primary interrupt. The device is in a "frozen" state: it either has data available (to read) or needs more data (to write) but cannot proceed at this time. I'll talk more about this problem later.

    3. The driver's secondary interrupt handler starts. It examines its internal state and determines that a DMA transfer has been completed. It calls CheckpointIO with the kMoreIOTransfers flag to complete the current partial transfer. Since another data transfer will be needed, it begins the process of calling PrepareMemoryForIO again, by calling SendSoftwareInterrupt to queue a software interrupt routine. Then, with nothing more to do, the secondary interrupt handler exits. The device is still frozen.

    4. The software interrupt routine runs. It updates the firstPrepared field and calls PrepareMemoryForIO to prepare the next segment (range of memory). This may require a page fault, causing the virtual memory subsystem to move data between main memory and the virtual memory disk file. When PrepareMemoryForIO finishes, the logical and physical mapping tables are updated and the lengthPrepared field contains the number of bytes that can be transferred in the next segment. The software interrupt routine calls a secondary interrupt handler (which is equivalent to queuing the handler).

    5. The sequence returns to the secondary interrupt handler, and the DMA operation is restarted. The partial preparation algorithm continues at step 2, progressing through steps 2 to 5 until all data is transferred.

The device is frozen in steps 2 to 5; it cannot proceed on the current I/O request until the partial preparation completes. But note that the page fault handler in step 4 may require disk I/O; consequently, any device that can service the page fault device (such as the SCSI bus manager) cannot support partial preparation. Writers of disk drivers and other SCSI-based interface software must understand these restrictions.

A CLOSER LOOK: SOME EXAMPLES

Unfortunately, as a result of some necessary constraints of PrepareMemoryForIO, the code in Listing 1 isn't usable in an actual device driver when the data transfer results in the interruption of the hardware device by the CPU. In this section, I'll return to the five-step transfer process outlined above, with more detail on the way that a driver interacts with memory preparation. I'll illustrate the process with three different examples: the simple case of a single DMA transfer; the more complicated case where more than one DMA transfer is needed because the physical mapping entries are discontiguous; and finally the full five-step transfer process, complete with partial preparation.

A SIMPLE TRANSFER

Our first example uses the sample preparation shown in Figure 3. Here your application or driver created a simple IOPreparationTable for an application data buffer that's 512 bytes long and begins at logical address 0x01B89F80. In this case the transfer process consists of only three steps:
    1. The buffer in our example crosses a physical page boundary, so two mapping entries are needed. PrepareMemoryForIO fills in the logical and physical mapping tables and sets the lengthPrepared field. Since it has successfully prepared the entire buffer, it sets the kIOStateDone flag in the state field. After your driver uses the NextPageIsContiguous macro (in DMATransfer.h) to determine that the two physical mapping entries are contiguous, it puts the first physical address, 0x0077EF80, and the entire byte count into the DMA registers and starts the device.

    2. When the transfer finishes, the driver's primary interrupt handler runs. It determines that the transfer has finished and queues a secondary interrupt to complete processing.

    3. The driver's secondary interrupt handler calls CheckpointIO to complete the transfer. It then completes the entire device driver operation by calling IOCommandIsComplete.

DISCONTIGUOUS PHYSICAL MAPPING

The above example requires a single DMA transfer; however, if the physical mapping entries are discontiguous, the first two steps of the process become more complicated:
    1. After preparation, your driver determines that the two physical mapping entries are not contiguous. Therefore, it puts the first physical address, 0x0077EF80, and the first byte count (128 bytes in this case) into the DMA registers and starts the DMA operation.

    2. When the transfer finishes, the driver's primary interrupt handler runs. It determines that the transfer has finished; however, another physical transfer is needed and can be performed, so it loads the DMA registers with the new physical address and the remaining byte count (384 bytes in this case), restarts the DMA operation, and exits the primary interrupt handler.

    After this DMA operation finishes, the operating system reenters the primary interrupt handler. Upon the completion of the entire transfer, the primary interrupt handler queues the secondary interrupt handler to finish the entire operation.

PARTIAL PREPARATION

The example in Figure 3 requires only a single preparation, but in some cases PrepareMemoryForIO cannot prepare the entire area at once and so requires partial preparation. To illustrate this, I'll change a few parameters in the IOPreparationTable.
  • The logical address of the buffer is 0x01B89F80.

  • The transfer length is 20480 bytes.

  • The transfer granularity is 8192 bytes. This value limits the length of the longest preparation.

Figure 3. A simple IOPreparationTable

PrepareMemoryForIO performs partial preparation of the data three times, as shown in Table 1.

The entire transfer requires these three repetitions of the five-step transfer process:

    1. The driver prepares the first DMA operation for physical address 0x0077EF80, length 4224. After it interrupts, the primary interrupt handler queues a secondary interrupt that, when run, calls CheckpointIO and causes a software interrupt routine to run. This software interrupt routine updates the firstPrepared field from 0 to 4224 (the amount previously prepared) and calls PrepareMemoryForIO for the next partial preparation. When PrepareMemoryForIO finishes, the software interrupt routine calls the secondary interrupt handler.

    2. The secondary interrupt starts the next transfer for physical address 0x00780000, length 8192. When this transfer finishes, the primary interrupt queues the secondary interrupt, which, in turn, calls CheckpointIO and causes the software interrupt routine to run a second time. This task calls PrepareMemoryForIO for the next preparation and calls the secondary interrupt handler again.

    3. The secondary interrupt handler starts the final transfer. When it finishes, the driver completes the entire preparation.

LOGICAL DATA TRANSFER: PROGRAMMED I/O

Some hardware devices do not support DMA but rather use programmed I/O, in which the main processor moves data between program logical addresses and the device. Programmed I/O is also needed when the device's DMA hardware cannot use DMA in a particular situation or context -- for example, a one-byte transfer.

Some hardware devices cannot transfer data that isn't properly aligned to some hardware-specific address value. For example, the DMA controller on the Power Macintosh 8100 requires addresses to be aligned to an 8-byte boundary; it can only transfer to physical addresses in which the low-order three bits are set to 0. Also, data transfers must be a multiple of 8 bytes. To handle such cases, the DMA support library returns the logical addresses of unaligned segments so that a device driver can transfer them with programmed I/O operations.

This restriction on logical alignment means that before starting a DMA transfer, the driver must look at the low-order bits of the physical address and the low-order bits of the count. The actual data transfer process is illustrated by the code in Listing 2, which presumes 8-byte alignment and ignores a few additional complications. The ugly stuff is in the ComputeThisSegment function, which examines the global IOPreparationTable and handles multiple address ranges. The DMA support library simplifies the procedure, as we'll see in the next section.

Listing 2. Data transfer with logical alignment

LogicalAddress      thisLogicalAddress;
PhysicalAddress   thisPhysicalAddress;
ByteCount         thisByteCount, segmentByteCount;

ComputeThisSegment(&thisLogicalAddress, &thisPhysicalAddress,
   &thisByteCount);
if ((thisPhysicalAddress & 0x07) != 0) {
   /* Pre-alignment logical transfer */
   segmentByteCount = 8 - (thisPhysicalAddress & 0x07);
   if (segmentByteCount > thisByteCount)
      segmentByteCount = thisByteCount;
   DoLogicalTransfer(thisLogicalAddress, segmentByteCount);
   thisByteCount -= segmentByteCount;
   thisLogicalAddress += segmentByteCount;
   thisPhysicalAddress += segmentByteCount;
}
if (thisByteCount > 0) {
   /* Aligned physical transfer */
   segmentByteCount = thisByteCount & ~0x07;
   if (segmentByteCount != 0) {
      DoPhysicalTransfer(thisPhysicalAddress, segmentByteCount);
      thisByteCount -= segmentByteCount;
      thisLogicalAddress += segmentByteCount;
   }
}
if (thisByteCount != 0) {
   /* Post-alignment logical transfer */
   DoLogicalTransfer(thisLogicalAddress, thisByteCount);
}

PUTTING IT ALL TOGETHER

Here we'll take a look at how your driver can use several of the functions in the DMA support library to simplify dealing with PrepareMemoryForIO.

Before you can call any of the functions in the DMA support library to make a partial preparation, you need to create the system context for a software interrupt. This context is created by the CreateSoftwareInterrupt system routine, as shown in the InitializePrepareMemoryGlobals function in Listing 3. CreateSoftwareInterrupt must be called from your driver's intialization routine because it allocates memory. Your driver's interrupt handler uses a software interrupt to start a task that can call PrepareMemoryForIO (as described earlier in step 4 of the data transfer process).

Listing 3. Initialization for DMA

SoftwareInterruptID      gNextDMAInterruptID;

/* This function is called once, when your driver starts. */
OSErr InitializePrepareMemoryGlobals(void)
{
   OSErr      status;

   gLogicalPageSize = GetLogicalPageSize();
   gPageMask = gLogicalPageSize - 1;
   status = CreateSoftwareInterrupt(
         PrepareNextDMATask,     /* Software interrupt routine */
         CurrentTaskID(),        /* For my device driver */
         NULL,                   /* Becomes the p1 parameter */
         TRUE,                   /* Persistent software interrupt */
         &gNextDMAInterruptID); /* Result is the task ID. */
   return (status);
}
The DMA support library contains two functions that a driver can use to simplify processing the output from PrepareMemoryForIO: InitializeDMATransfer, which is called once to configure the overall transfer operation, and PrepareDMATransfer, which is called to set up each individual transfer.

The MyConfigureDMATransfer function in Listing 4 calls PrepareMemoryIO and InitializeDMATransfer to configure the transfer. This function is called by the mainline driver function (and by a software interrupt routine for partial preparation, as we'll see later).

Listing 4. MyConfigureDMATransfer

/* In a production system, kPageCount should be retrieved from the
   operating system by calling GetLogicalPageSize. */
#define kPageCount         4096
#define kLongestDMA         65536
#define kLogicalAlignment   8
#define kMappingEntries
                    ((kLongestDMA + (kPageCount - 1)) / kPageCount)

DMATransferInfo            gDMATransferInfo;
IOPreparationTable         gIOTable;
LogicalAddress             gLogicalMapping[2];
PhysicalAddress            gPhysicalMapping[kMappingEntries];
AddressRange               gThisTransfer;
Boolean                    gIsLogical;
OSErr MyConfigureDMATransfer(
         IOCommandCode   ioCommandCode, /* Parameter to DoDriverIO */
         ByteCount      firstPrepared   /* Zero at first call */
   )
{
   OSErr      status;

   gThisTransfer.base = NULL;        /* Setup for programmed I/O */
   gThisTransfer.length = 0;         /* Interrupt handler */
   gIsLogical = FALSE;

   if (firstPrepared == 0) {
      /* This is an initial preparation for the transfer. */
      gIOTable.preparationID = kInvalidID;   /* Error exit marker */
      switch (ioCommandCode) {
         case kReadCommand:  gIOTable.options = kIOIsInput;  break;
         case kWriteCommand: gIOTable.options = kIOIsOutput; break;
         default:               return (paramErr);
      }
      ioTable.ioOptions |=
         ( kIOLogicalRanges            /* Logical input area */
         | kIOShareMappingTables       /* Share with OS kernel */
         | kIOMinimalLogicalMapping    /* Minimal table output */
         );
      gIOTable.state = 0;
      gIOTable.addressSpace = CurrentTaskID();
      gIOTable.granularity = kLongestDMA;
      gIOTable.firstPrepared = 0;
      gIOTable.lengthPrepared = 0;
      gIOTable.mappingEntryCount = kMappingEntries;
      gIOTable.logicalMapping = gLogicalMapping;
      gIOTable.physicalMapping = gPhysicalMapping;
      gIOTable.rangeInfo.range.base = pb->ioBuffer;
      gIOTable.rangeInfo.range.length = pb->ioReqCount;
   }
   else   {  /* We were called to continue a partial preparation. */
      gIOTable.firstPrepared = firstPrepared;
   }
   status = PrepareMemoryForIO(&gIOTable);
   if (status != noErr)
      return (status);
   status = InitializeDMATransfer(&gIOTable, kLogicalAlignment, 
      &gDMATransferInfo);
   return (status);
}
If MyConfigureDMATransfer is successful, the driver initializes the hardware to begin processing. I assume here that the hardware interrupts the process when it requires a data transfer. The primary interrupt handler is shown in Listing 5.

Listing 5. The primary interrupt handler

InterruptMemberNumber
    MyInterruptHandler(InterruptSetMember  member, void *refCon,
                      UInt32 theIntCount)
{
   OSErr      status;

   if (<device has or requires more data> == FALSE)
      status = noErr;               /* Presume I/O completion. */
   else 
      status = MySetupForDataTransfer();
   if (status != kIOBusyStatus)
      /* This partial transfer (or device operation) is complete. */
      QueueSecondaryInterruptHandler(DriverSecondaryInterruptHandler,
            NULL, NULL, (void *) status);
   return (kIsrIsComplete);
}

OSErr MySetupForDataTransfer(void)
{
   OSErr      status;

   if (gIsLogical && gThisTransfer.length > 0) {
      /* Continue a programmed I/O transfer. */
      DoOneProgrammedIOByte(* ((UInt8 *) gThisTransfer.base));
      gThisTransfer.base += 1;
      gThisTransfer.length -= 1;
      status = kIOBusyStatus;
   }
   else {      /* We need another preparation segment. */
      status = PrepareDMATransfer(&gDMATransferInfo,
            &gThisTransfer, &gIsLogical);
      if (status == noErr) {      /* Do we have more data? */
         status = kIOBusyStatus;  /* Don't queue secondary task. */
         if (gIsLogical) {     /* Start a programmed I/O transfer. */
            DoOneProgrammedIOByte(* ((UInt8 *) gThisTransfer.base));
            gThisTransfer.base += 1;
            gThisTransfer.length -= 1;
         }
         else   /* Start a DMA transfer segment. */
            StartProgrammedIOToDevice(&gThisTransfer);
      }
      else      /* This preparation is done. Can we start another? */
         status = kPrepareMemoryStartTask;
   }
   return (status);
}
When the primary interrupt handler determines that a data transfer is needed, it calls the function MySetupForDataTransfer, which tries to continue a logical (programmed I/O) transfer. If no logical transfer is appropriate, it calls PrepareDMATransfer, to configure the next data transfer segment. This will be either a logical or a DMA transfer, depending on the interaction between the user's data transfer parameters and the device's logical alignment restrictions. If more data remains to be transferred, MySetupForDataTransfer starts either a DMA transfer or another logical transfer; otherwise, it returns a private status value that will eventually cause a software interrupt routine to call PrepareMemoryForIO again to continue a partial preparation.

Listing 6 shows the secondary interrupt handler -- at least the part that handles the DMA operation. The primary interrupt handler provides the operation status in the p2 parameter; the secondary interrupt handler uses this parameter to determine whether the operation is complete (in which case this is the final status), or whether some intermediate operation is required.

Listing 6. The secondary interrupt handler

OSStatus DriverSecondaryInterruptHandler(void   *p1, 
                                          void   *p2)
{
   OSStatus      osStatus;

   osStatus = (OSErr) p2;
   switch (osStatus) {
      case kPrepareMemoryStartTask:      /* Need more preparation */
         CancelDeviceWatchdogTimer();
         osStatus = SendSoftwareInterrupt(gNextDMAInterruptID, 0);
         if (osStatus != noErr) {
            /* Handle error status by stopping the device. */
            ...
         }
         break
      case kPrepareMemoryRestart:         /* Preparation completed */
         osStatus = MySetupForDataTransfer();
         break;
   }
   if (osStatus != kIOBusyStatus) {       /* If I/O is complete */
      CancelDeviceWatchdogTimer();
      CheckpointIO(&ioTable, kNilOptions);
      IOCommandIsComplete(ioCommandID, (OSErr) osStatus);
   }
   return (noErr);
}
Finally, Listing 7 shows the software interrupt routine that's called when the driver must call PrepareMemoryForIO again to perform a partial preparation.

Listing 7. A software interrupt routine for partial preparation

void PrepareNextDMATask(void   *p1, void   *p2)
{
   OSErr         status;
   ByteCount   newFirstPrepared;

   if ((gIOTable.state & kIOStateDone) != 0)
      status = eofErr;        /* Data overrun or underrun error */
   else {                     /* Do the next partial preparation. */
      newFirstPrepared =
            gIOTable.firstPrepared + gIOTable.lengthPrepared;
      status = MyConfigureDMATransfer(0, newFirstPrepared);
                                 /* ioCommandCode is not used. */
   }
   QueueSecondaryInterruptHandler(DriverSecondaryInterruptHandler,
         NULL, NULL, (void *) status);
}

YOUR TURN IN THE BARREL

At times, working through the complexity of this problem felt like going off Niagara Falls in a barrel. There used to be a joke among the developers of the UNIX operating system: "We never document our code: if it was hard to write, it should be hard to understand." The algorithms I've described here were hard to write, but I hope I was able to document and clarify the most important features of the library well enough that you don't have to go through the same struggle I did.

MARTIN MINOW is writing the SCSI plug-in for Copland on a computer named "There must be a pony here" and competes with his boss to see who is more cynical about Apple management. During the few moments he can escape from meetings, he runs with the Hash House Harriers.

Thanks to our technical reviewers David Harrison, Tom Saulpaugh, Dave Smith, and George Towner.

 

Community Search:
MacTech Search:

Software Updates via MacUpdate

Together 3.6.1 - Store and organize all...
Together helps you organize your Mac, giving you the ability to store, edit and preview your files in a single clean, uncluttered interface. Features Smart storage. With simple drag-and-drop... Read more
Cloud 4.1.1 - File sharing from your men...
Cloud is simple file sharing for the Mac. Drag a file from your Mac to the CloudApp icon in the menubar and we take care of the rest. A link to the file will automatically be copied to your clipboard... Read more
OmniFocus 2.7.1 - GTD task manager with...
OmniFocus helps you manage your tasks the way that you want, freeing you to focus your attention on the things that matter to you most. Capturing tasks and ideas is always a keyboard shortcut away in... Read more
CleanApp 5.1.1 - Application deinstaller...
CleanApp is an application deinstaller and archiver.... Your hard drive gets fuller day by day, but do you know why? CleanApp 5 provides you with insights how to reclaim disk space. There are... Read more
ForkLift 3.0 Beta 2 - Powerful file mana...
ForkLift is a powerful file manager and ferociously fast FTP client clothed in a clean and versatile UI that offers the combination of absolute simplicity and raw power expected from a well-executed... Read more
Sublime Text 3126 - Sophisticated text e...
Sublime Text is a sophisticated text editor for code, markup, and prose. You'll love the slick user interface, extraordinary features, and amazing performance. Features Goto Anything. Use Goto... Read more
1Password 6.3.3 - Powerful password mana...
1Password is a password manager that uniquely brings you both security and convenience. It is the only program that provides anti-phishing protection and goes beyond password management by adding Web... Read more
WhatsApp 0.2.1880 - Desktop client for W...
WhatsApp is the desktop client for WhatsApp Messenger, a cross-platform mobile messaging app which allows you to exchange messages without having to pay for SMS. WhatsApp Messenger is available for... Read more
NeoFinder 6.9.3 - Catalog your external...
NeoFinder (formerly CDFinder) rapidly organizes your data, either on external or internal disks, or any other volumes. It catalogs all your data, so you stay in control of your data archive or disk... Read more
Amadeus Pro 2.3.1 - Multitrack sound rec...
Amadeus Pro lets you use your Mac computer for any audio-related task, such as live audio recording, digitizing tapes and records, converting between a variety of sound formats, etc. Thanks to its... Read more

Zip—Zap (Games)
Zip—Zap 1.01 Device: iOS Universal Category: Games Price: $1.99, Version: 1.01 (iTunes) Description: Touch to contract.Release to let go.Bring the clumsy mechanical beings home. · · · over 100 levelsno adsno in-app-purchases Zip—... | Read more »
Paperback: The Game (Games)
Paperback: The Game 1.0 Device: iOS Universal Category: Games Price: $3.99, Version: 1.0 (iTunes) Description: You are an author trying to finish kitschy paperback novels. Complete Westerns, Science Fiction, Romance or even a Crime... | Read more »
How to Rule With a Firm Hand in My Majes...
My Majesty is a kingdom management sim not unlike August’s magisterial hit, Reigns. It’s essentially a reskin of developer Tigrido’s previous management sim, Dictator. As supreme ruler of the land, you must consult with a number of subjects to... | Read more »
Our 5 Favorite iMessage Sticker Packs
At long last, iMessage joins the ranks of messaging apps the likes of LINE and Whatsapp, adding an impressive collection of stickers. They’re a great way to add a little something extra to your daily conversations. [Read more] | Read more »
How to get past Vulture Island's tr...
Vulture Island is a colorful and quirky mish-mash of platforming and puzzles. It’s creative and fresh, but sometimes the game can throw a curveball at you, leaving you stuck as to how you should progress. These tips will help you explore smoothly... | Read more »
The new Clash of Kings is just for Weste...
If you’ve played the original Clash of Kings, you’ll probably recognise the city building, alliance forging and strategic battles in Clash of Kings: The West. What sets this version apart is that it’s tailor made for a Western audience and the... | Read more »
Frost - Survival card game (Games)
Frost - Survival card game 1.12.1 Device: iOS Universal Category: Games Price: $3.99, Version: 1.12.1 (iTunes) Description: *Warning: the game will work on iPhone 5C and above and iPad Pro / 4. Other devices are not supported* | Read more »
How to build and care for your team in D...
Before you hit the trail and become a dog sledding legend, there’s actually a fair bit of prep work to be done. In Dog Sled Saga, you’re not only racing, you’re also building and caring for a team of furry friends. There’s a lot to consider—... | Read more »
How to win every race in Dog Sled Saga
If I had to guess, I’d say Dog Sled Saga is the most adorable racing game on the App Store right now. It’s a dog sled racing sim full of adorable, loyal puppies. Just look at those fluffy little tails wagging. Behind that cute, pixelated facade is... | Read more »
Let the war games commence in Gunship Ba...
Buzz Lightyear famously said, “This isn’t flying, this is falling – with style!” In the case of Gunship Battle: Second War, though, this really is flying - with style! The flight simulator app from Joycity puts you in control of 20 faithfully... | Read more »

Price Scanner via MacPrices.net

15-inch 2.2GHz Retina MacBook Pro on sale for...
B&H Photo has the 2015 15″ 2.2GHz Retina MacBook Pro (MJLQ2LL/A) on sale for $1799, including free shipping plus NY sales tax only. Amazon also has the 2015 15″ 2.2GHz Retina MacBook Pro (... Read more
Toughbook Celebrates 20 Years of Ruggedized M...
Panasonic System Communications Company of North America, Division of Panasonic Corporation of North America (Panasonic) today celebrates the 20th anniversary of its industry-leading Toughbook mobile... Read more
12-inch 1.1GHz Gray Retina MacBook on sale fo...
B&H Photo has the 2016 12″ 1.1GHz Gray Retina MacBook on sale for $1199.99 including free shipping plus NY sales tax only. Their price is $100 off MSRP. Read more
13-inch 2.5GHz MacBook Pro (Apple refurbished...
Apple has Certified Refurbished 13″ 2.5GHz MacBook Pros available for $829, or $270 off the cost of new models. Apple’s one-year warranty is standard, and shipping is free: - 13″ 2.5GHz MacBook Pros... Read more
Save 30% on Camera Guard’s Secure Protection...
To celebrate the release of macOS Sierra, Miami-based security solutions company, ProtectStar has announced a special 30% discount on Camera Guard Professional for Mac 2016. This innovative security... Read more
DVDFab Special Deal – Get a 1-Year Free Licen...
Beijing, China based specialist in the field of DVD, Blu-ray and video backup solutions, Fengtao Software has launched its Autumn Special Deals 2016, giving a 1-year free license of a randomly picked... Read more
21-inch iMacs on sale for up to $120 off MSRP
B&H Photo has 21″ iMacs on sale for up to $120 off MSRP including free shipping plus NY sales tax only: - 21″ 3.1GHz iMac 4K: $1379 $120 off MSRP - 21″ 2.8GHz iMac: $1199.99 $100 off MSRP - 21″ 1... Read more
13-inch 2.7GHz/256GB Retina MacBook Pro on sa...
Amazon.com has the 13″ 2.7GHz/256GB Retina Apple MacBook Pro on sale for $151 off MSRP including free shipping: - 13″ 2.7GHz/256GB Retina MacBook Pro (sku MF840LL/A): $1348 $151 off MSRP Read more
Apple TVs on sale for up to $50 off MSRP
Best Buy has 32GB and 64GB Apple TVs on sale for $40-$50 off MSRP on their online store. Choose free shipping or free local store pickup (if available). Sale prices for online orders only, in-store... Read more
Apple refurbished 13-inch Retina MacBook Pros...
Apple has Certified Refurbished 13″ Retina MacBook Pros available for up to $270 off the cost of new models. An Apple one-year warranty is included with each model, and shipping is free: - 13″ 2.7GHz... Read more

Jobs Board

*Apple* Retail - Multiple Positions (US) - A...
Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, you're also the Read more
Restaurant Manager (Neighborhood Captain) - A...
…in every aspect of daily operation. WHY YOU'LL LIKE IT: You'll be the Big Apple . You'll solve problems. You'll get to show your ability to handle the stress and Read more
Sr. *Apple* Mac Engineer - Net2Source Inc....
…staffing, training and technology. We have following position open with our client. Sr. Apple Mac Engineer6+ Months CTH Start date : 19th Sept Travelling Job If Read more
*Apple* Retail - Multiple Positions-Norfolk,...
Job Description: Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, Read more
Restaurant Manager (Neighborhood Captain) - A...
…in every aspect of daily operation. WHY YOU'LL LIKE IT: You'll be the Big Apple . You'll solve problems. You'll get to show your ability to handle the stress and Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.