Wang Leiwanglei@buaa.edu.cn

Chapter 5 Device ManagementChapter 5 Device Management

— for the Solaris Platform

2

Outline

Device AccessDevice 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 device’s 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 HandlersInterrupt 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 Mapping Device and Kernel MemoryMemory

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 driver’s 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 ManagementDevice 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

userprocess performs any of the following

actions:Accesses a mappingDuplicates a mappingFrees a mappingCreates a mapping

23

Context Management Operation

devmap_callback_ctl StructureEntry Points for Device Context

ManagementAssociating User Mappings With

Driver NotificationsManaging Mapping Accesses

24

Reference

Sun Microsystems, Inc. Writing Device Drivers January 2005

25

End

• Last.first@Sun.COM