I2C EEPROM client driver in mini2440

Hi,

I'm trying to understand I2C subsystem in Linux with mini2440 board.

There's one userspace program to access the EEPROM which is present in the
examples(24cXX.c, 24cXX.h and eeprog.c) in the CD.

I'm a bit confused in the terminology used by I2C subsystem in linux. I
have always worked on RTOS based systems where this kind of abstraction is
not present. After reading through a bit, below is my understanding :
1. Chip/bus driver : This seems to be the S3C24xx I2c controller specific
part. 
2. Adapter driver : could not get what it is... can anyone explain more on
this...
3. Client driver : This is The slave driver...e.g. for eeprom chip AT24C0X


I could get that I2C driver(it looks to be Bus driver) in :
..\linux-2.6.32.2\drivers\i2c\bussesi2c-s3c2410.c

But I could not get where is the client/slave driver implemented for the
EEPROM chip onboard mini2440 ?

Regards
RKC

In a recent kernel:

"adapter" is the framework, which uses a bus driver to drive the signals on
the I2C lines. "clients" connecting to a bus via the "adapter" in order to
communicate with their devices attached to this bus.

adapter: drivers/i2c/i2c-*.c
bus driver: drivers/i2c/busses/i2c-s3c2410.c
eeprom driver: drivers/misc/eeprom/at24.c

thanks for answering. This has always been a question in my mind. Given a
new SOC with an I2C controller, what do I need to write and what Linux
subsystem provides on its own ?

In RTOS world, I need to provide a few routine based on the I2c
controller's abilities to the applications... Only knowledge I need is
controller spec ...but Linux system looks more complicated... whats the
need for this kind of framework ?

> but Linux system looks more complicated

IMHO the word 'complex' is better, not complicated. Your RTOS world is much
smaller and most of the time you can make a specific software solution for
a specific hardware job. And in the next hardware job you create a new
specific software solution and so on.
In Linux you must support a wide amount of architectures, platforms, chip
sets and controllers on one side and a huge amount of I2C devices on the
other side *at once*. Sometimes you have more than one I2C bus on the
platform, all of this needs locking and solutions to bring the data to the
calling applications in always the same way (you really do not want to
reinvent an application, because the I2C host controller changes). And the
developer needs an easy way to describe all of these I2C buses, their
devices and interrupt lines and interrupt levels and so on. And due to this
you need a good abstraction to meet all requirements at once. That is the
purpose of the framework.

The bright side of the framework is: writing a new I2C device driver or a
new I2C master driver is very simple. And everybody can immediately use it
in her/his own application, because there is no need for further adaptions
even if her/his application is different from the application is was
developed for. The keyword is: code reuse.

Hi to all,

This is sathireddy.

I am working on i2c device driver for eeprom  .i am at initial stage.
Initially i have some doubts in my mind.

1)what kind of data it will store.

2)at what scenarios it will be used.

please explain with a simple example.


Thanks