Wang Lei

1
Chapter 5 Device Management for the Solaris
Platform

• Wang Lei
• wanglei_at_buaa.edu.cn

2
Outline

• Device Access
• Interrupt Handlers
• Mapping Device and Kernel Memory
• Device Context Management

3
Device Memory (1)

• Managing Differences in Device and Host
  Endianness
• The data format of the host can have different
  endian characteristics than the data format of
  the device. In such a case, data transferred
  between the host and device would need to be
  byte-swapped to conform to the data format
  requirements of the destination location
• Managing Data Ordering Requirements
• Platforms can reorder loads and stores of data to
  optimize performance of the platform. Because
  reordering might not be allowed by certain
  devices, the driver is required to specify the
  devices ordering requirements when setting up
  mappings to the device.

4
Device Memory (2)

• ddi_device_acc_attr Structure
• This structure describes the endian and data
  order requirements of the device. The driver is
  required to initialize and pass this structure as
  an argument to ddi_regs_map_setup(9F).
• typedef struct ddi_device_acc_attr
• ushort_t devacc_attr_version
• uchar_t devacc_attr_endian_flags
• uchar_t devacc_attr_dataorder
• ddi_device_acc_attr_t

5
Device Memory (3)

• Mapping Device Memory
• Drivers typically map all regions of a device
  during attach(9E). The driver maps a region of
  device memory by calling ddi_regs_map_setup(9F)
• The DDI framework sets up the mappings for the
  device region and returns an opaque handle to the
  driver. This data access handle is passed as an
  argument to the ddi_get8(9F) or ddi_put8(9F)
  family of routines
• The driver verifies that the shape of the device
  mappings match what the driver is expecting by
  checking the number of mappings exported by the
  device. The driver calls ddi_dev_nregs(9F) and
  then verifies the size of each mapping by calling
  ddi_dev_regsize(9F).

6
Device Access Functions

• Memory Space Access
• Device registers appear in memory address space.
  Theddi_getX family of routines and the ddi_putX
  family are available for use bydrivers as an
  alternative to the standard device access
  interfaces.
• I/O Space Access
• Device registers appear in I/O space. The
  ddi_io_get8(9F) andddi_io_put8(9F) routines are
  available for use by drivers as an alternative to
  thestandard device access interfaces.
• PCI Configuration Space Access
• Driver is required to map PCI configuration space
  by calling pci_config_setup(9F)in place of
  ddi_regs_map_setup(9F). Then call the
  pci_config_get8(9F) and pci_config_put8(9F) to
  accessPCI configuration space.

7
Outline

• Device Access
• Interrupt Handlers
• Mapping Device and Kernel Memory
• Device Context Management

8
Interrupt Handler Overview

• Interrupt Specification
• The interrupt specification is information the
  system uses to bind a device interrupt source
  with a specific device interrupt handler.
• Interrupt Number
• This interrupt number identifies the interrupt
  specification for which the driver isregistering
  a handler.
• Interrupt Block Cookies
• An iblock cookie is an opaque data structure that
  represents the information the system needs to
  block interrupts.

9
Device Interrupts (1)

• High-Level Interrupts
• A bus prioritizes a device interrupt at a
  bus-interrupt level. The bus interrupt level is
  then mapped to a processor-interrupt level. A bus
  interrupt level that maps to a CPU interrupt
  priority above the scheduler priority level is
  called a high-level interrupt. High-level
  interrupt handlers are restricted to calling the
  following DDI interfaces
• mutex_enter(9F) and mutex_exit(9F) on a mutex
  that is initialized with an iblock cookie
  associated with the high-level interrupt
• ddi_trigger_softintr(9F)
• The ddi_getX/ddi_putX families of routines

10
Device Interrupts (2)

• Normal Interrupts
• The only information the system has about a
  device interrupt is either the priority level for
  the bus interrupt, for example, the IPL on an
  SBus in a SPARC machine, or the interrupt request
  number, for example, the IRQ on an ISA bus in an
  x86 machine.
• When an interrupt handler is registered, the
  system adds the handler to a list of potential
  interrupt handlers for each IPL or IRQ. When the
  interrupt occurs, the system must determine which
  device, of all the devices associated with a
  given IPL or IRQ, actually interrupted. The
  system calls all the interrupt handlers for the
  designated IPL or IRQ until one handler claims
  the interrupt.

11
Device Interrupts (3)

• Software Interrupts
• The Solaris 10 DDI/DKI supports software
  interrupts, also known as soft interrupts. Soft
  interrupts are initiated by software rather than
  by a hardware device. Handlers for these
  interrupts must also be added to and removed from
  the system. Soft interrupt handlers run in
  interrupt context and therefore can be used to do
  many of the tasks that belong to an interrupt
  handler.

12
Registering Interrupts

• Before a device driver can receive and service
  interrupts, the driver must register an interrupt
  handler with the system by calling
  ddi_add_intr(9F).
• Registering interrupts provides the system with
  a way to associate an interrupt handler with an
  interrupt specification.
• The interrupt handler is called when the device
  might have been responsible for the interrupt.
• The handler has the responsibility of determining
  whether it should handle the interrupt and, if
  so, of claiming that interrupt.

Registering Interrupts
13
Interrupt Handler Responsibilities

• Determine whether the device is interrupting and
  possibly reject the interrupt.
• Inform the device that the device is being
  serviced.
• Perform any I/O request-related processing.
• Do any additional processing that could prevent
  another interrupt.
• Return DDI_INTR_CLAIMED.

Registering Interrupts
14
Handling High-Level Interrupts

• High-level interrupts are those interrupts that
  interrupt at the level of the scheduler and
  above.
• The driver use ddi_intr_hilevel(9F) to determine
  whether the driver is using high-level
  interrupts.
• The suggested method is to add a high-level
  interrupt handler, which simply triggers a
  lower-priority software interrupt to handle the
  device.

15
Outline

• Device Access
• Interrupt Handlers
• Mapping Device and Kernel Memory
• Device Context Management

16
Memory Mapping Overview

• The steps that a driver must take to export
  device or kernel memory are as follows
• 1. Set the D_DEVMAP flag in the cb_flag flag of
  the cb_ops(9S) structure.
• 2. Define a devmap(9E) driver entry point to
  export the mapping.
• 3. Use devmap_devmem_setup(9F) to set up user
  mappings to a device. To set up user mappings to
  kernel memory, use devmap_umem_setup(9F).

17
Exporting the Mapping

• The devmap(9E) entry point is called as a
  result of the mmap(2) system call. devmap(9E) is
  used for the following operations
• Validate the user mapping to the device or kernel
  memory
• Translate the logical offset within the
  application mapping to the corresponding offset
  within the device or kernel memory
• Pass the mapping information to the system for
  setting up the mapping

18
Associating Device Memory With User Mappings

• Use devmap_devmem_setup(9F) to export device
  memory to user applications.
• Note devmap_devmem_setup() has to be called
  from the drivers devmap(9E) entry point.
• devmap_devmem_setup() has the following syntax
• int devmap_devmem_setup(devmap_cookie_t handle,
  dev_info_t dip,
• struct devmap_callback_ctl callbackops,
  uint_t rnumber,
• offset_t roff, size_t len, uint_t maxprot,
  uint_t flags,
• ddi_device_acc_attr_t accattrp)

19
Associating Kernel Memory With User Mappings

• Allocating Kernel Memory for User Access
• Use ddi_umem_alloc(9F) to allocate kernel memory.
• Exporting Kernel Memory to Applications
• Use devmap_umem_setup(9F) to export the memory.
• Freeing Kernel Memory Exported for User Access
• Use ddi_umem_free(9F) to free the memory when the
  memory is no longer needed.

20
Outline

• Device Access
• Interrupt Handlers
• Mapping Device and Kernel Memory
• Device Context Management

21
Introduction to Device Context (1)

• What Is a Device Context?
• The context of a device is the current state of
  the device hardware.
• The device driver manages the device context for
  a process on behalf of the process.
• The driver must maintain a separate device
  context for each process that accesses the
  device.
• The device driver has the responsibility to
  restore the correct device context when a process
  accesses the device.

22
Introduction to Device Context (2)

• Context Management Model
• A device driver is notified whenever a user
• process performs any of the following actions
• Accesses a mapping
• Duplicates a mapping
• Frees a mapping
• Creates a mapping

23
Context Management Operation

• devmap_callback_ctl Structure
• Entry Points for Device Context Management
• Associating User Mappings With Driver
  Notifications
• Managing Mapping Accesses

24
Reference

• Sun Microsystems, Inc. Writing Device Drivers
  January 2005

25
End

• Last.first_at_Sun.COM