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@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************