[i2c] I2C Linux driver terminology and ARM926EJ (AMBA) I2C driver

[Mark M. Hoffman]

Hi Drasko:

* Drasko Draskovic <drasko.draskovic at gmail.com> [2006-08-09 14:50:46 +0200]:
> Hi all.
> After reading the docs, I am still a bit confused about terminology used by
> lm-sensors team. I have to implement i2c driver for my specific hardware,
> that is based on ARM926EJ and AMBA bus. As I can see, there is not support
> for I2C interface that sits on AMBA bus (APB part of AMBA) and is on the
> other side connected to peripherals via I2C bus. So, that interface, called
> ApI2c, is bridge between I2C and AMBA bus. I have to write driver to
> describe it, and I am confused what files to look.
> 
> I have several questions that are unclear to me, so maybe someone can answer
> these. As I understand now correctly, first of all I have to describe
> interface, called ApI2c that sits on AMBA bus on one side and is connected
> to I2C bus on the other side, so devices (peripherals) connected to I2C bus
> talk to microcontroller via this bridge.
> 
> 1) Is this (ApI2c bridge) "Adapter" in I2C teminology?

Yes.

> 2) Do all the files in "buses" directory decsribe such a "bridges" that are
> harware specific (tha is, do "busses" directory hold description for
> different "adapters", if these are adapters...)? If so, I have to write part
> of the driver that describes my bridge, that is ApI2c for AMBA, and put it
> in "busses" folder. Following your instructions, I have to inform amba
> driver that this "bridge" is another amba_device, and register it within
> else amba devices. Is this correct?

Yes.

> 3) Suppose I do not want to connect any I2C peripheral for now. So, I do not
> need "chips" part of the driver. I just want to enable the functionality for
> these chips (with their appropriate drivers) to be inserted later. Question
> is, how will I know (test) thah I enabled this functionality correctly? That
> means, when I change arch/arm/<mach-yourboard>/core.c file, and write ApI2c
> bridge decription (which I put in "busses" folder), and succesfuly compile
> kernel (or maybe this has to be loaded as a module?), under which directory
> in Linux will I see this "bridge" driver? How can I test it -- send some
> messages to it? Are there some userspace tools that can do that? I am asking
> this question because this "bridge" (ApI2c) is not a device in a strict
> sense. Devices are peripherals connected to I2C bus, and described with
> their own drivers from "chips" directory. So how is this "bridge" driver
> treated by Linux, and where I can see that it exists and that is wrote
> correctly, and how can I test it/talk to microcontrollet thru it?

As I mentioned before... the i2c-dev mechanism allows you to perform I2C
transactions from userspace programs, without need for a 'chip' driver.
However, you will still need to physically connect *something* to your
I2C bus in order to test your driver.

I have designed a small piece of hardware to be used for just this purpose.
It is based on a PIC microcontroller.  I've written firmware for it to do
some basic transactions, but it could do a lot more (testing error conditions,
etc.)  Read here: http://members.dca.net/mhoffman/sensors/fredbob/20060218/

Of course, if you don't feel like building one of those... you may use
whatever I2C slave device that you have on hand to do your testing.

> 4) What is exactly in "algo" folder. What are these algorithms? Does not one
> describe the functionality of such a bridge within "busses" folder? Do I
> need some file in "algo" folder (preferably not). If not, do I have to
> implemant some algorithm within my "bridge" file, which will sit in "busses"
> directory? What are these algorithms exactly, when we have
> protocol described in i2c-core file?

Assumption: AMBA->I2C bridge is more intelligent than manually bit-banging
two GPIO pins.

Given the above, you won't have to worry about the algos directory.  You
just need to define a single trivial 'struct i2c_algorithm' in your driver.
Take a look at i2c-i801.c or i2c-sis96x.c for an example.

Regards,

-- 
Mark M. Hoffman
mhoffman at lightlink.com