Understanding Interrupt Handling and Tasklets in Linux Kernel: NS16550 UART Study, Slides of Computer Applications

Download Understanding Interrupt Handling and Tasklets in Linux Kernel: NS16550 UART Study and more Slides Computer Applications in PDF only on Docsity!

On using ‘tasklets’

An example of the Linux kernel’s

‘tasklet’ mechanism for deferring

some interrupt-handling work

Recall purpose of Project

• Allow you to gain experience encountering

the kinds of issues that commonly arise in

crafting software to operate real hardware:

– Learning the hardware device’s capabilities

– Deciding which driver-methods to implement

– Accommodating your platform’s interfaces

– Exploiting the OS kernel’s support-functions

– Devising a strategy for testing and debugging

Urgent versus non-urgent

• When some peripheral device issues an

interrupt request, it may need a prompt

response to handle an urgent situation

• After the emergency has been dealt with,

there may also be some further actions

which are necessary, but which can be

safely delayed without jeopardizing the

integrity of proper system functioning

The serial UART

• As an example, when the UART receives

characters via its serial-port, there is only

a limited capability for preserving them in

the device’s on-board ‘receive buffer’

• These received characters need to be

quickly moved out of the UART before

they get overwritten by newer data -- or

before they can cause other incoming

characters to be ‘lost’ for lack of space

9-wire null-modem cable

CD

RxD TxD GND DSR DTR RTS CTS RI

CD

RxD TxD GND DSR DTR RTS CTS RI

Data

Terminal

Equipment

Data

Terminal

Equipment

the sender the receiver

Modem Control Register

LOOP

BACK

OUT2 OUT1 RTS DTR

Legend: DTR = Data Terminal Ready (1=yes, 0=no) RTS = Request To Send (1=yes, 0=no) OUT1 = not used (except in loopback mode) OUT2 = enables the UART to issue interrupts LOOPBACK-mode (1=enabled, 0=disabled)

The receiver clears this bit

Read the Line Status Register

Write byte to the Transmit Data Register

THRE==1?

NO

YES

DONE

Read the Modem Status Register

CTS==1?

NO

YES

The sender’s algorithm

Set RTS=1 in the Modem Control Register

The receiver’s actions

• When the receiver’s storage capacity has

been reached, it takes urgent action to

‘pause’ any further transfers of data (i.e.,

it writes ‘0’ to the RTS-bit in its Modem

Control register)

• Then it needs to remove its accumulation

of received data out of its storage medium

• Being less urgent this can be postponed

Application to the UART

• Top Half:

– Tell sender to ‘pause’ further data-transfers

• Bottom-Half:

– Move accumulated data out of the device’s

on-board storage-area (e.g., its receive FIFO)

A tasklet for ‘bottom half’ work

name

function

‘struct tasklet_struct’ object data-pointer

• Your device-driver allocates and initializes

a ‘struct tasklet_struct’ object, possessing

a name , a function and a pointer to data

• Your driver’s ‘top-half’ interrupt-handler will

schedule your tasklet for future execution

Tasklet semantics

• A few technical points to keep in mind if

you decide to make use of ‘tasklets’:

• A ‘tasklet’ runs at ‘interrupt time’ (so it doesn’t own

any user-space context, just kernel-space context)

user space

‘virtual’ memory

kernel space

Some interrupted task’s context resides here (so it can’t be predicted)

The kernel-space context is consistent across all tasks

More tasklet semantics…

• A tasklet runs in ‘atomic mode’ (so cannot sleep),

although it can ‘wake up’ a task that is sleeping

• A tasklet executes on the CPU that scheduled it

(and so doesn’t execute concurrently with itself)

• You can schedule your tasklet to run either at

“normal” priority or at “high” priority – the latter

ones all are run before any of the former ones

The senario overview

ISR

stops the sending of additional data

schedules the tasklet

resumes the Interrupted task

Arrival of new data interrupts the CPU

TASKLET

transfers received bytes from UART to to ringbuffer

wakes up sleeping readers

READ()

sleeps until driver’s ringbuffer has some data

moves data from driver’s ringbuffer to user’s buffer

issues ‘Clear-To-Send’ if case the driver’s ringbuffer has been emptied

reports count of bytes returned in user’s buffer

‘write()’

• We did not employ efficiency-techniques in

our device-driver’s ‘write()’ function:

– No wait-queues

– No interrupts

– No tasklets

• Thus there is still an opportunity for you to

add improvements to our ‘tasklet.c’ demo!