[U-Boot] [PATCH/RFC, 0/2] I2C rework -- what do you think?

[ksi at koi8.net]

Hi everyone,

Here is the first draft of major I2C subsystem rework. This is not a patch
that should be applied to the tree--it will break systems with I2C busses
over multiplexers and probably something else--but rather a Request For
Comments. I would like to here all the objections, suggestions etc. before I
go on and undertake a big job to change all the boards and other stuff to
the new code. It is a big job and I don't want to spend a lot of time doing
something that nobody would accept.

My goal is to somehow untie I2C subsystem from platform-specific parts. This
is not an attempt for a "code cleanup" though some cleanup could be achieved
in process. But this is not a goal, it is just a probable side effect.

Primary goal is to allow multiple I2C busses on a board served by different
I2C controllers (on-SoC, external, bit-banging.) As of now we have
rudimentary support for multiple BUILT-IN adapters in some SoCs (e.g.
fsl_i2c.c) but this support is platform specific and does NOT allow any
additional (external etc.) adapters.

This is not a problem for a vast majority of supported boards that usually
have a single I2C bus but there are cases when boards have several busses
served by different I2C adapters. I personally have the first prototype of
such a board right now in PCB fab. It's MPC8548E based mATX motherboard that
uses both built-in I2C adapters (fsl_i2c.c) AND the third one off of SM502
chip sitting on PCI bus. All 3 busses are required for proper system
initialization and operation because we have 3 I2C devices with the same
address, 0x68 that can not be changed.

For existing boards we have just 2 MUTUALLY EXCLUSIVE options,
CONFIG_HARD_I2C and CONFIG_SOFT_I2C. That gives very little control over I2C
subsystem. It won't even allow for having a bit-banged I2C bus in addition
to a hardware adapter, less for several such busses or anything external
(e.g. some chipset adapters that would give some control over sensors and
such.) This is obvious even from that HARD/SOFT I2C exclusivness --
bit-banging I2C interface is ortogonal to a built-in hardware one so why
wouldn't we were able to use both? One can even have several bit-banging
busses as long as GPIO pins are available...

There are 2 different ways to address this issue -- make another platform
specific monster or rework the entire I2C subsystem to make that multibus
support generic and common U-Bootwide.

This is an attempt to make I2C uniform and scalable.

Here is a little manifest...

First of all, there is a basic entity, I2C bus. It can be a simple I2C bus
from the only I2C adapter on a SoC, several busses from several adapters,
both on-SoC and external, and several busses growing off of several adapters
via I2C multiplexers/switches (e.g. PCA9544 etc.) They are all the same for
the rest of code accessed with single set of i2c_read()/i2c_write() and
friends for all busses no matter what adapter they are on and if they are
directly connected to an adapter or reached through a set of I2C mux chips.

Any I2C operation is performed on the CURRENT bus. Current bus is set with
i2c_set_bus_num(). In case of directly connected busses it merely changes a
global variable that is used as an index into an array. If some busses are
connected via I2C muxes, it disconnects the previously connected muxes if
any and sets all chips along the path to the new bus so next access will go
to that bus.

All those paths are statically allocated at compile time according to
board's config file. That means we can use I2C from flash before U-Boot is
relocated to DRAM thus allowing us to use SPD for DRAM initialization. It is
also means we do NOT need that "i2c bus" or whatever command to setup a bus
behind muxes for consecutive access--we just choose that bus number and
that's it.

All busses are explicitely defined in boards' config files so we know
exactly where all accesses are going.

I did test it on MPC8548CDS system and it works OK. There is a patch for
MPC8548CDS.h in the patchset that changes it to the new I2C code and a
speculative example of multiadapter multibus configuration with 3 adapters
and 5 busses 3 of which are connected with I2C muxes, 2 from them are
multihop.

Please let me know guys what you think so I would be able to start with a
big patch.

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************