Accessing hardware

A driver should not attempt to access any devices other than those controlled by the driver itself.

• Drivers must never attempt to program the PIC (Programmable Interrupt Controller) or PIT (Programmable Interval Timer) to avoid conflicts with other drivers or handle hardware conflicts such as the lack of an Intel 8259 in the configured hardware. If the driver needs to delay execution for a small, fixed period of time, it should call delay(D3) or delay(D3oddi) if possible.
  

• DDI drivers should use drv_usecwait(D3) if the driver needs to spin on some hardware condition such as the outcome of a status register for less than 1/100th of a second. This provides a fixed, bounded spin without using delay(D3). For example:

     #define SPIN_IN_MICROSECS	10000	/* .01 seconds */
     
  
     <driver writes to memory-mapped register or calls outb(D3), etc.>
     
  
     /* give register/device time to catch up */
     
  
     drv_usecwait (SPIN_IN_MICROSECS);
     
  
     <check register or continue with multipart programming of device>
  

  ODDI drivers should use the suspend(D3oddi) function in this case.

  If the driver needs to busy-spin a longer period, use a timeout (see ``Timeouts'') or release processor control and block. Delays and busy-waits can increase the preemption latency that is experienced by high-priority processes. This is especially important in a realtime environment, where short and bounded preemption latency can be critical.

• Drivers should never program or access information about the bus except with the autoconfiguration and autodetection mechanisms discussed in ``Autoconfiguration''.

• Most peripheral devices are intelligent, meaning that they contain their own microprocessor that can hold driver code. Proper use of firmware can enhance the features, portability, and performance of your device. Drivers should take full advantage of the board's intelligence by writing firmware code or code that is downloaded to controller RAM at system boot time. Board diagnostics are often handled this way. You may also want to include a basic subset of the protocol necessary to talk to the host processor directly, such as the memory management protocol, in firmware.
  

• Drivers can download code to an adapter in a variety of ways. If the code is relatively small (less than a page), locate the code within the driver data itself and avoid the complexity of a user-level process that downloads the microcode. If the code is large, provide a simple download program and the required ioctl( ) commands.

  Drivers that use MDI 2 and later versions can use the mdi_open_file(D3mdi), mdi_close_file(D3mdi), and, for MDI 2.1 and later, mdi_read_file(D3mdi) to download code to the adapter.

  MDI version 2 drivers can use the mdi_open_file(D3mdi) and mdi_close_file(D3mdi) functions to download code to the hardware. MDI version 2.1 adds the mdi_read_file(D3mdi) function that allows larger amounts of data to be downloaded.