1. 2009 IEEE International Advance Computing Conference (IACC 2009)
Patiala, India, 6–7 March 2009
Implementation of Codec Driver for
Network Embedded Devices
B.I.D Kumar Hanumanthappa. J Thippeswamy.K Dr.Manjaiah.D.H.
Assistant Professor Lecturer, Assistant Professor & HOD Reader,
Dept. of Information Department of Studies Dept. Information Science & Department of
Science & Engineering in Computer Science Engineering Computer Science
HKBK College of University of Mysore, R.L.Jalappa Institute of Mangalore University,
Engineering, Nagavara, Manasagongotry, Technology Mangalagangothri,
Bangalore,Karnataka, Mysore, Karnataka, Kodigehalli, Doddaballapura Mangalore, Karnataka,
INDIA. Email:- INDIA Bangalore Rural District , INDIA
kumarbid@gmail.com hanums_j@yahoo.com Karnataka, INDIA Email:-
Email:- ylm321@yahoo.co.in
thippeswamy_yadav@yahoo.com
Abstract - This paper, based on implementation of a embedded devices is one of the major needs for
device driver for CS4297A, an audio CODEC situated embedded systems.
on embedded development Intel® PXA255 XScale® The purpose of a device driver is to handle
Board [3] and Embedded Linux system which has requests made by the kernel with regards to a particular
excellent network function. As companies rely on type of device. There is a well-defined and consistent
applications like electronic mail and database interface for the kernel to make these requests. By
management for core business operations, computer isolating device-specific code in device drivers and by
networking becomes increasingly important. Meanwhile having a consistent interface to the kernel, adding a new
in embedded technology also we are finding wide device is easier.
requirement of network interfaced embedded devices. In the most basic sense, device drivers are those
Developing device driver for this network interfaced pieces of Linux code that provide the connection
embedded devices is one of the major needs for between the operating system, application and the
embedded systems. hardware (the device itself). Thus, device drivers have
This paper involves the study of to, among other things, deal with the asynchronous
Good understanding of architecture of 32-bit character of the hardware.
microcontroller like Intel® PXA255 The CS4297A is a high-performance, integrated
audio CODEC. It performs stereo analog-to-digital
Finding suitable Linux kernel for Intel® (A/D) and digital-to-analog (D/A) conversion of up to
PXA255 processor 24-bit serial values at sample rates up to 192 kHz. The
Developing a device driver for CS4297A, an D/A offers a volume control that operates with a 1 dB
audio CODEC situated on target machine on an step size. It incorporates selectable soft ramp and zero
Embedded Linux platform crossing transition functions to eliminate clicks and
The device driver is implemented using C programming pops. The D/A’s integrated digital mixing functions
language. allow a variety of output configurations ranging from a
Key Words – Audio CODEC, Embedded system, channel swap to a stereo-to-mono down mix.
PXA255 processor, Device Driver
2. METHODOLOGY
1. INTRODUCTION
The methodology involved in writing the Driver on
Industry has been very successful in design and target machines is as follows
manufacture of complex embedded system, such as Detection of hardware
modern vehicles (control, information, entertainment Registration with kernel (initialization)
etc), monitor system, telecommunication system, Making an audio setup
wireless communication systems, and the automation Opening an audio device
systems. These embedded systems are becoming more Transmission of character data
and more complex, distributed, interconnected Reception of character data
And based on distributed computing to a larger extent. Processing of data
Developing device driver for this network interfaced Releasing of device (cleaning)
2679

2. Companion Chip interface
Some care must be taken while writing device drivers to Additional Peripherals for system connectivity
avoid “Race condition” between processes. Linux Multimedia Card Controller (MMC)
supports different synchronization tools like SSP Controller
semaphores, spin lock and wait queues to avoid race Network SSP controller for baseband
condition. I2C Controller
Two Pulse Width Modulators (PWMs)
3. HARDWARE IMPLEMENTATION All peripheral pins double as GPIOs
Hardware debug features
3.1 Intel® PXA255 XScale® Processor Hardware Performance Monitoring features
It is an application specific standard product
(ASSP) that provides industry-leading MIPS/mW
performance for handheld computing applications. The
processor is a highly integrated system on a chip and
includes a high-performance low-power Intel®
XScale™ microarchitecture with a variety of different
system peripherals.
The PXA255 processor is a 17x17mm 256-pin
PBGA package configuration for high performance. The
17x17mm package has a 32-bit memory data bus and
the full assortment of peripherals.
Product Features
High Performance Processor
Intel® XScale™ Microarchitecture
32 KB Instruction Cache
32 KB Data Cache
2 KB “mini” Data Cache Fig: Block diagram
Extensive Data Buffering
Intel® Media Processing Technology The PXA255 processor is an integrated system-
Enhanced 16-bit Multiply on-a-chip microprocessor for high performance, low
40-bit Accumulator power portable handheld and handset devices. It
Flexible Clocking incorporates the Intel® XScale™ microarchitecture with
CPU clock from 100 to 400 MHz on-the-fly frequency scaling and sophisticated power
Flexible memory clock ratios management to provide industry leading MIPs/mW
Frequency change modes performance. The PXA255 processor is ARM*
Rich Serial Peripheral Set Architecture Version 5TE instruction set compliant
AC97 Audio Port (excluding floating point instructions) and follows the
I2S Audio Port ARM* programmer’s model.
USB Client Controller
High Speed UART 3.2 CS4297A audio codec
Second UART with flow control
UART with hardware flow control
FIR and SIR infrared comm ports The CS4297 is a AC’97 1.03 compatible stereo
Low Power audio Codec designed for PC multimedia systems [4].
Less than 500 mW Typical Internal Using the industry leading CrystalClear delta-sigma and
Dissipation mixed signal technology, the CS4297 paves the way for
Supply Voltage may be Reduced to PC’97-compliant desktop, portable, and entertainment
1.00 V PCs, where high-quality audio is required.
Low Power/Sleep Modes The CS4297, when coupled with a DC’97 PCI
High Performance Memory Controller audio accelerator such as the CS4610, implements a
Four Banks of SDRAM - up to 100 MHz cost-effective, superior quality, two-chip audio solution.
Five Static Chip Selects The CS4297 Audio Codec ’97 and CS4610 PCI Audio
Support for PCMCIA or Compact Flash Accelerator are the first members of the Sound Fusion
family of advanced PCI audio products for next
2680 2009 IEEE International Advance Computing Conference (IACC 2009)

3. generation multimedia PCs. piece of hardware respond to a well-defined internal
programming interface; they hide completely the details
of how the device works.
User activities are performed by means of a set of
standardized calls that are independent of the specific
driver; mapping those calls to device-specific operations
that act on real hardware is then the role of the device
driver. This programming interface is such that drivers
can be built separately from the rest of the kernel, and
“plugged in” at runtime when needed. This modularity
makes Linux drivers easy to write.
4.2 Sound Card Technology
Sound is an analog property; it can take on any
value over a continuous range. Computers are digital;
they like to work with discrete values. Sound cards use a
Fig: Block diagram of CS4297A device known as an Analog to Digital Converter (A/D
or ADC) to convert voltages corresponding to analog
The CS4297 is a mixed-signal serial Codec sound waves into digital or numeric values which can be
based on the AC’97 Specification. It is designed to be stored in memory. Similarly, a Digital to Analog
paired with a digital controller, typically located on the Converter (D/A or DAC) converts numeric values back
PCI bus. The AC’97 Controller is responsible for all to an analog voltage which can in turn drive a
communications between the CS4297 and the rest of the loudspeaker, producing sound.
system. The CS4297 functions as an analog mixer, a
stereo ADC, a stereo DAC, and a control and digital The process of analog to digital conversion,
audio stream interface to the AC’97 Controller. The known as sampling, introduces some error. Two factors
CS4297 contains two distinct functional sections: are key in determining how well the sampled signal
Digital and Analog. The Digital section includes the represents the original. Sampling rate is the number of
AC-Link registers, power management support, SYNC samples made per unit of time (usually expresses as
detection circuitry, and AC-Link serial port interface samples per second or Hertz). A low sampling rate will
logic. The Analog section includes the analog input provide a less accurate representation of the analog
multiplex or (mux), stereo output mixer and mono signal. Sample size is the range of values used to
output mixer, stereo ADCs, stereo DACs, and analog represent each sample, usually expressed in bits. The
volume controls. larger the sample size, the more accurate the digitized
signal will be.
4. SOFTWARE IMPLEMENTATION
Sound cards commonly use 8 or 16 bit samples
at sampling rates from about 4000 to 44,000 samples per
4.1 Linux Device Drivers
second. The samples may also be contain one channel
(mono) or two (stereo).
In the most basic sense, device drivers are
those pieces of Linux code that provide the connection
between the operating system, applications and the FM Synthesis is an older technique for
hardware (the device itself). Thus, device drivers have producing sound. It is based on combining different
to, among other things, deal with the asynchronous waveforms (e.g. sine, triangle, square). FM synthesis is
character of the hardware [2]. simpler to implement in hardware that D/A conversion,
The device driver is a set of functions used to but is more difficult to program and less flexible. Many
control access to a device. The device drivers for sound cards provide FM synthesis for backward
keyboard, monitor, mouse and Ethernet card are usually compatibility with older cards and software. Several
inbuilt with Linux kernel. But when we need to access independent sound generators or voices are usually
new devices for a particular application, then we have to provided.
write device drivers to access them. Also, if we want to
modify the default actions of the existing devices, we Most sound cards provide the capability of
need to rewrite the corresponding device drivers. mixing, combining signals from different input sources
Device drivers take on a special role in the Linux kernel. and controlling gain levels.
They are distinct “black boxes” that make a particular
2009 IEEE International Advance Computing Conference (IACC 2009) 2681

4. MIDI stands for Musical Instrument Digital
Interface, and is a standard hardware and software Figure: User space where applications reside, and kernel
protocol for allowing musical instruments to space where modules or device drivers reside
communicate with each other. The events sent over a
MIDI bus can also be stored as MIDI files for later
editing and playback. Many sound cards provide a MIDI Events User functions Kernel functions
interface. Those that do not can still play MIDI files Load module insmod module_init()
using the on-board capabilities of the sound card. Open device fopen file_operations:open
Read device read file_operations:read
MOD files are a common format for computer Write device fwrite file_operations:write
generated songs. As well as information about the Close device fclose file_operations:release
musical notes to be played, the files contain digitized Remove module rmmod module_exit()
samples for the instruments (or voices). MOD files
originated on the Amiga computer, but can be played on Table 1:-Device driver events and their associated
other systems, including Linux, with suitable software. interfacing functions in kernel space and user space.
4.3 User Space and Kernel Space Events Kernel functions
Read data inb
When you write device drivers, it’s important to Write data outb
make the distinction between “user space” and “kernel
space”. Table 2:-Device driver events and their associated
functions between kernel space and the hardware
Kernel space. Linux (which is a kernel)
device.
manages the machine’s hardware in a simple
and efficient manner, offering the user a simple
and uniform programming interface. In the 4.4 Major and Minor Numbers
same way, the kernel, and in particular its
device drivers, form a bridge or interface Each character or block device is accessed through a file
between the end- user/programmer and the in the file system. This file is usually located in the /dev
hardware. Any subroutines or functions directory, which contains all device special files.
forming part of the kernel (modules and device
drivers, for example) are considered to be part These files are represented with a “c” in the
of kernel space. output of the “ls –l” command, or with a “b”
for a block device.
User space. End-user programs, like the UNIX The output of the “ls –l” command also gives
shell or other GUI based applications the major and minor numbers of the device.
(kpresenter for example), are part of the
user space. Obviously, these applications need The major number is an 8-bit number
to interact with the system’s hardware. representing the device type.
However, they don’t do so directly, but through Due to its length (8 bits), this number cannot
the kernel supported functions. exceed 255.
Devices using the same driver are usually
represented by the ame major number on the
User Space system.
(Applications)
A minor number usually identifies a specific
Table 1 functions device among other devices sharing the same driver.
This number is also stored on 8 bits, so the system is
limited to 255 devices per major number.
Kernel Space Assigning a major number to a device is accomplished
(Modules or Drivers) in the Kernel by invoking the devfs_register_chrdev()
function when the driver is being initialized.
The devfs_register_chrdev() function may also register
Table 2 functions major number dynamically. Similarly, the
devfs_unregister_chrdev() function is used when a
Hardware character is unloaded from the Kernel.
2682 2009 IEEE International Advance Computing Conference (IACC 2009)

5. Increment the usage count, so that the driver
4.5 Registration with DevFS may not be removed from the Kernel (in the
case of a module).
Devfs_register_chrdev() and Check for hardware-specific problems
devfs_unregister_chrdev are functions provided for associated with this particular device.
Kernels that do not use the new DevFS filesystem. The Initialize the hardware, if it is needed.
DevFS filesystem allows the Kernel to dynamically Identify the minor number of the device that
created files in the /dev directory.The register_chrdev() was open and update the f_op pointer if
and unregister_chrdev() functions are still available in necessary. This is needed for device sharing the
2.4, but they were typically used in 2.2 (or older) same major number but having different
Kernels.devfs_register_chrdev() and Device drivers (i.e., miscellaneous devices).
devfs_unregister_chrdev() acts merely as wrappers for Allocate the memory needed for the various
the old functions. This is necessary in case the DevFS data structures used in the device driver and
filesystem is not available. initialize these structures.
The DevFS filesystem does not necessitate the
devfs_register_chrdev() and devfs_unregister_chrdev 4.7 Closing device
functions. With DevFS, every files in the /dev directory
could be created with devfs_register(). A sound driver is closed when a User space
This new feature in the 2.4 Kernel avoids application no longer needs it. This function is executed
having to manually create files in /dev with the mknod in the sys_close() system call. The release() function
command. The Kernel source makes an heavy use of will not be called if it is not implemented by a specific
thedevfs_register() function in almost every driver. device driver. This behavior may be observed in
If the Kernel was not compiled with DevFS fput().The release() function is in charge of the
support, these functions will return NULL and will be following steps:
useless.Drivers may support both the old and new ways
It decrements the usage count. This is
of registering devices in the Kernel.
necessary in order for the Kernel to be able
to remove the module.
The structure for devfs is described below:
Removes any unnecessary data from
memory. This is particularly true for data
devfs_handle_t devfs_register (devfs_handle_t dir, placed in the private data field of the file
const char *name, structure associated with the device.
unsigned int namelen, Shut down the physical device if needed.
unsigned int flags, This includes any operation that must be
unsigned int major, executed in order to leave the hardware in
unsigned int minor, a sane state, and disabling interrupts.
umode_t mode,
uid_t uid,
The release () function associated with a particular
gid_t gid,
driver will not be invoked if the open() function was not
void *ops,
called. Again, this may be observed in the fput()
void *info);
function.
Device drivers may support both the static and dynamic
allocation of /dev entries. 4.8 Reading Device
4.6 Opening device read() is called to read data from the device. The
form of the read function is as follows:
A sound device driver is first accessed by
executing its open () function. This function is executed static ssize_t device_read (struct file * file,
in the sys_open() system call. The open () function will char * buffer, size_t count, loff_t *ppos)
just not be called if a specific device driver does not
Note that the arguments of the read () method have
implement it. This behavior may be observed in
changed in the 2.4 and subsequent Kernels.
dentry_open ().
In the case that a character needs to implement its The new method passes only a file structure,
open() function, it will have to provide the following from which we can find the disk inode associated with
functionality: the device file. The read() method implemented by a
device driver should copy the specified number of bytes
2009 IEEE International Advance Computing Conference (IACC 2009) 2683

6. into the buffer and return the actual number of bytes Synopsis
read (or an error code).The read() function may (struct file_operations *
therefore read less data than was requested. In this case
fops, int dev);
the returned value will be less than size passed in
Arguments
parameter
fops
A negative return value means that there was
File operations for the driver
an error. Note that the buffer field passed to the device
dev
drivers refers to the memory space of the User space
Unit number to allocate
process that invoked the read() system call.The
Description
copy_to_user() function must thus be used in order to
Allocate a mixer device. Unit is the number of the mixer
return the data in the proper memory segment.
requested. Pass -1 to request the next free mixer unit. On
success the allocated number is returned, on failure a
4.9 Writing Device
negative error code is returned.
4.12 unregister_sound_special
The write() method implemented by a driver is
Name
invoked to write data to the device. It is defined as
unregister_sound_special -- unregister a special sound
follows:
device
Synopsis
static ssize_t device_write(struct file *file,
const char *buf, size_t count, loff_t *ppos) (int unit);
Arguments
write() should copy the specified number of bytes from unit
the User space buffer into the device. The number of
bytes specified by the value of count should be written unit number to allocate
to the device. Similarly to the read() method, the number Description
returned by the write() function should match the value Release a sound device that was allocated with
of count. If it’s not the case, the data was partially register_sound_special. The unit passed is the return
written or, in the case of a negative value, an error value from the register function.
occurred.
4.13 unregister_sound_mixer
4.10 Register_sound_special Name
unregister_sound_mixer -- unregister a mixer
Name Synopsis
register_sound_special -- register a special (int unit);
sound node Arguments
Synopsis unit
(struct file_operations *
unit number to allocate
fops, int unit); Description
Arguments Release a sound device that was allocated with
fops register_sound_mixer. The unit passed is the return
value from the register function.
File operations for the driver
5. CONCLUSION
unit
This paper introduced an implementation of a device
Unit number to allocate driver for CS4297A, an audio CODEC situated on an
Description embedded development Intel® PXA255 XScale® Board
Allocate a special sound device by minor number from and Embedded Linux system. As we have discussed the
the sound subsystem. The allocated number is returned architecture of CS4297A, its applications and its
on succes. On failure a negative error code is returned. features, it is possible to get low latency out of standard
drivers, but this is still very much dependent on the
4.11 Register_sound_mixer quality of the driver.
The device driver has been successfully developed for
Name CS4297A and met all the requirements and has achieved
register_sound_mixer -- register a mixer device
2684 2009 IEEE International Advance Computing Conference (IACC 2009)

7. all the major goals. The major features of the application the Linux Kernel : O’reilly
are
Portability: The application is developed in C [2] Linux Device Drivers, Alessandro Rubini &
language, which in tern is coded in Linux platform, Jonathan Corbet
accessibility of the software will not be a problem in any
environment at the time of developing. Once the [3] Intel® PXA255 Processor Developer’s Manual
software is loaded into kernel it works as kernel part.
[4] Cirrus Logic, CS4297A Product data sheet
6. REFERENCES
[1] Daniel P. Bovet and Marco Cesati, Understanding
2009 IEEE International Advance Computing Conference (IACC 2009) 2685