Thursday, August 2, 2007

DSP Chip Market rises by 8% in 2007

The DSP chip market is forecast grow a moderate 8% in 2007
The market for general-purpose digital signal processor (DSP) chips is forecast to grow 8% in 2007 to the $9 billion level according to a new market study from Forward Concepts, here. The new study, "DSP Chip Strategies '07" predicts a more typical growth of 15% in 2008 driven by communications and multimedia applications. But the new study also emphasizes the even bigger embedded DSP market that will grow to $17.6 billion in 2007, to almost twice the size of the general-purpose DSP chip market. The new in-depth study is believed to be the most comprehensive study available of markets driven by DSP technology, and includes the results of a new survey of DSP professionals in over 30 countries.
Forward Concepts’ President and Principal Analyst, Will Strauss, is the author of the study and he is considered the foremost authority on DSP market trends. According to Mr. Strauss, “The general-purpose DSP market is the best known and is dominated by Analog Devices, Freescale, Agere/LSI and Texas Instruments. The embedded DSP market, on the other hand, is where most new opportunities for emerging companies are because of lower barriers to entry. For example, a number of new companies identified in the study are introducing parallel array processor chips for unprecedented DSP horsepower on a single chip at relatively low clock frequencies and reduced power consumption."
The embedded DSP market is dominated by companies like Qualcomm, Broadcom, Marvell and Infineon, with most of their DSP products offered as Systems on Chip (SoC). Because of the heavy SoC emphasis, the major RISC vendors have added DSP capability to their product offerings. The report profiles the DSP market stance of these and over 100 other chip and core vendors.
The study points out that the general-purpose DSP market is dominated by communications applications, with cellular being the biggest. The embedded DSP market, however, is more closely identified with multimedia applications. But, that market segment also includes communications chips for Wi-Fi, WiMAX and Bluetooth as well as DSL and cable modems. All of these and new DSP-centric markets like DAB and HDTV are also forecast in the report through 2011.
This is the only study available that provides worldwide equipment production forecasts by major application and geography with IC and DSP penetration for each. This is a valuable resource for business planning by both chip vendors and their customers.

Wednesday, August 1, 2007

Writing a Linux device driver

from : http://www.freeos.com/articles/2677/

Does the idea of writing a Linux device driver sound difficult? If
you have some basic programming experience, the task is
simpler than you think. Get started with this quick primer on
device driver programming.

What do I need to know about writing drivers?

Basic knowledge of kernel compilation, a good deal of programming
experience in C under Linux and lastly, the right techniques of data
structures, like linked list is essential along with their data types.

The first thing a programmer must know before attempting to write a
driver, is to know how the Linux kernel source compiles, paying attention
to the compilation process (the gcc compiler flags).

Choosing the device type

a) Block drivers

A block device is something that can host a filesystem such as a disk. A
block device can only be accessed as multiples of a block, where a block
is usually one kilobyte of data .

b) Character drivers

A character device is one that can be accessed like a file, and a char
driver is in charge of implementing this behaviour. This driver implements
the open, close, read and write system calls. The console and parallel
ports are examples of char devices.

Device drivers in Linux are known as modules and can be loaded dynamically
into the kernel using the insmod command.

A single module can be compiled alone, and also can be linked to the
kernel (here, care has to be taken on the type of driver).

eg: A simple module

#define MODULE
#include

int init_module (void) /* Loads a module in the kernel */
{
printk("Hello kernel n");
return 0;
}

void cleanup_module(void) /* Removes module from kernel */
{
printk("GoodBye Kerneln");
}

Compiling the module

# gcc -c hello.c
# insmod hello.o

The output is

Hello kernel

# rmmod hello.o

GoodBye Kernel

How init_module works?

init_module loads the relocated module image into kernel space and runs
the module's init function.

The module image begins with a module structure and is followed by code
and data as appropriate.

The module structure is defined as follows:

struct module
{
unsigned long size_of_struct;
struct module *next;
const char *name;
unsigned long size;
long usecount;
unsigned long flags;
unsigned int nsyms;
unsigned int ndeps;
struct module_symbol *syms;
struct module_ref *deps;
struct module_ref *refs;
int (*init)(void);
void (*cleanup)(void);
const struct exception_table_entry *ex_table_start;
const struct exception_table_entry *ex_table_end;
#ifdef __alpha__
unsigned long gp;
#endif
};


All of the pointer fields, with the exception of next and refs, are
expected to point within the module body and be initialized as appropriate
for kernel space, i.e. relocated with the rest of the module.

Return Values

On success, zero is returned. On error, -1 is returned
and errno is set appropriately.

Errors

EPERM The user is not the superuser.

ENOENT No module by that name exists.

EINVAL Some image slot filled in incorrectly, image->name
does not correspond to the original module name,
some image->deps entry does not correspond to a
loaded module, or some other similar inconsistency.

EBUSY The module's initialization routine failed.

EFAULT name or image is outside the program's accessible
address space.

How cleanup_module works?


cleanup_module attempts to remove an unused loadable module entry. If
name is NULL, all unused modules marked auto clean will be removed.

Return Values

On success, zero is returned. On error, -1 is returned and errno is
set appropriately.

Errors

EPERM The user is not the superuser.

ENOENT No module by that name exists.

EINVAL name was the empty string.

EBUSY The module is in use.

EFAULT name is outside the program's accessible address
space.

This simple module is called skull, short for Simple Kernel Utility For
Loading Localities.

General flags used for compiling any driver are

-D__KERNEL__ _DMODULE -O -Wall -I$(INCLUDEDIR)

Note: The INCLUDEDIR should contain the header files of the kernel source.

Module code has to be recompiled for each version of the kernel that it
will be linked to. Each module defines a symbol called kernel_version
which is defined in . In case of a version mismatch, use
the insmod -f (force) option to load the module.