EmbLogic » gaurav

Interrupt handler

gaurav — Sat, 07 May 2011 13:27:13 +0000

The role of an interrupt handler is to give feedback to its device about interrupt
reception and to read or write data according to the meaning of the interrupt being
serviced. The first step usually consists of clearing a bit on the interface board; most
hardware devices won’t generate other interrupts until their “interrupt-pending” bit
has been cleared. Depending on how your hardware works, this step may need to be
performed last instead of first; there is no catch-all rule here. Some devices don’t
require this step, because they don’t have an “interrupt-pending” bit; such devices
are a minority.

Blocking I/O

gaurav — Thu, 05 May 2011 13:39:39 +0000

A call to read may come when no data is available, but more is expected in the future. Or a process could attempt to write, but your device is not ready to accept the data, because your output buffer is full. The calling process usually does not care about such issues; the programmer simply expects to call read or write and have the call return after the necessary work has been done. So, in such cases, your driver should (by default) block the process,
putting it to sleep until the request can proceed.

Interrupt Disabling

gaurav — Sun, 01 May 2011 13:40:29 +0000

However, interrupt disabling alone does not always prevent kernel control path interleaving.
Indeed, a kernel control path could raise a “Page fault” exception, which in turn could suspend the current process (and thus the corresponding kernel control path). Or again, a kernelcontrol path could directly invoke the schedule( ) function. This happens during most I/O disk operations because they are potentially blocking, that is, they may force the process to sleep until the I/O operation completes. Therefore, the kernel must never execute a blocking operation when interrupts are disabled, since the system could freeze.

Interrupt Disabling

gaurav — Sat, 30 Apr 2011 13:29:33 +0000

For any section of code too large to be defined as an atomic operation, more complicated
means of providing critical sections are needed. To ensure that no window is left open for a
race condition to slip in, even a window one instruction long, these critical sections always
have an atomic operation at their base.
Interrupt disabling is one of the key mechanisms used to ensure that a sequence of kernel
statements is operated as a critical section. It allows a kernel control path to continue
executing even when hardware devices issue IRQ signals, thus providing an effective way to
protect data structures that are also accessed by interrupt handlers.

Atomic Operations

gaurav — Sun, 24 Apr 2011 13:37:35 +0000

The easiest way to prevent race conditions is by ensuring that an operation is atomic at the chip level: the operation must be executed in a single instruction. These very small atomic operations can be found at the base of other, more flexible mechanisms to create critical sections. Thus, an atomic operation is something that can be performed by executing a single assembly language instruction in an “atomic” way, that is, without being interrupted in the middle.

gaurav — Sat, 23 Apr 2011 13:36:59 +0000

A race condition can occur when the outcome of some computation depends on how two or more interleaved kernel control paths are nested. A critical region is any section of code that should be completely executed by each kernel control path that begins it, before another kernel control path can enter it.
Here are four broad types of synchronization techniques:

Nonpreemptability of processes in Kernel Mode.
Atomic operations
Interrupt disabling.
Locking.

Nonpreemptability of Processes in Kernel Mode

gaurav — Fri, 22 Apr 2011 13:47:29 +0000

Linux kernel is not preemptive, that is, a running process cannot
be preempted (replaced by a higher-priority process) while it remains in Kernel Mode. In
particular, the following assertions always hold in Linux:

No process running in Kernel Mode may be replaced by another process, except when the former voluntarily relinquishes control of the CPU.
Interrupt or exception handling can interrupt a process running in Kernel Mode
however, when the interrupt handler terminates, the kernel control path of the process is resumed.

PCI

gaurav — Mon, 18 Apr 2011 13:24:54 +0000

The CPU and the PCI devices need to access memory that is shared between them. This memory is used by device drivers to control the PCI devices and to pass information between them. Typically the shared memory contains control and status registers for the device. These registers are used to control the device and to read its status. For example, the PCI SCSI device driver would read its status register to find out if the SCSI device was ready to write a block of information to the SCSI disk. Or it might write to the control register to start the device running after it has been turned on.

SPI

gaurav — Sat, 16 Apr 2011 13:32:50 +0000

The Serial Peripheral Interface (SPI) bus is a serial master-slave interface similar to I 2C and comes built in on many microcontrollers. It uses four wires (compared to two on I2C): Serial CLocK (SCLK), Chip Select (CS),Master Out Slave In (MOSI), and Master In Slave Out (MISO). MOSI is used for shifting data into the slave device, and MISO is used for shifting data out of the slave device. Because the SPI bus has dedicated wires for transmitting and receiving data, it can operate in full-duplex mode, unlike the I 2C bus. The typical speed of
operation of SPI is in the low-megahertz range, unlike the mid-kilohertz range on I2C, so the former yields higher throughput.

sysfs

gaurav — Fri, 15 Apr 2011 13:54:19 +0000

Kobjects are the mechanism behind the sysfs virtual filesystem. For every directory
found in sysfs, there is a kobject lurking somewhere within the kernel. Every kobject
of interest also exports one or more attributes, which appear in that kobject’s sysfs
directory as files containing kernel-generated information.Code that works with sysfs should include .

kobject

gaurav — Tue, 12 Apr 2011 13:45:46 +0000

Adding a kobject to a kset is usually done when the object is created; it is a two-step
process. The kobject’s kset field must be pointed at the kset of interest; then the
kobject should be passed to:
int kobject_add(struct kobject *kobj);
As always, programmers should be aware that this function can fail (in which case it
returns a negative error code) and respond accordingly. There is a convenience func-
tion provided by the kernel:
extern int kobject_register(struct kobject *kobj);

i2c probe and attach functions.

gaurav — Mon, 11 Apr 2011 14:00:54 +0000

When the i2c core calls the driver’s probe() method signifying the presence of a host adapter, it, in turn,invokes i2c_probe() with arguments specifying the addresses of the slave devices that the driver is responsible for and an associated attach() routine,which … Continue reading →

class object

gaurav — Sun, 10 Apr 2011 12:49:16 +0000

Each class object includes a list of class_device descriptors, each of which represents a single logical device belonging to the class. The class_device structure includes a dev field that points to a device descriptor, thus a logical device always refers to a given device in the device driver model. However, there can be several class_device descriptors that refer to the same device. In fact, a hardware device might include several different sub-devices, each of which requires a different User Mode interface.

i2c

gaurav — Sat, 09 Apr 2011 13:56:57 +0000

I2C is the name for a two-wire serial bus protocol originally developed by Phillips. It commonly is used in embedded systems so different components can communicate; PC motherboards use I2C to talk to different sensor chips. Those sensors typically report … Continue reading →

Dentry Object

gaurav — Thu, 31 Mar 2011 13:28:11 +0000

VFS considers each directory a file that contains a list of files and other directories.Once a directory entry is read into memory, however, it is transformed by the VFS into a dentry object based on the dentry structure.The kernel creates a dentry object for every component of a pathname that a process looks up; the dentry object associates the component to its corresponding inode. For example, when looking up the /tmp/test pathname, the kernel creates a dentry object for the / root directory, a second dentry object for the tmp entry of the root directory, and a third dentry object for the test entry of the /tmp directory.