In message 420CC656.7000309@web.de you wrote:
But ... another assumption of mine ... normally hardware support makes things easier than if there is no hardware support, for noone implements hardware support for something that can be done in software quite simple... or not?
Not in this case. The soft-i2c driver just toggles two port pins with appropriate busy wait loops to get the bit timings right. Really simple. For the CPM driver you have to prepare buffers and buffer descriptors, initialize the CPM's I2C controller, hand it over the buffer descriptor(s), start the transfer, wait until it gets done, check for error conditions, etc.
Hardware I2C is OK in Linux, because it is a slow transfer and you don't want to keep the CPU in a busy wait loop just to clock out the bits when you can start a transfer and then wait for an interrupt. Here the overhead is payed for by the advantage of being able to run other more useful things in parallel. U-Boot is single-threaded, so the CPM i2c driver is just a waste of code and programming effort.
Well, to be honest, it may have advantages when reading lots of data at "high" speeds (i. e. with a I2C clock >> 100 kHz). Then you may actually be faster. But when time is critical than this is only a workaround for the design error of putting time critical data in an I2C device.
Okay, the HARD code is twice as long and looks more complicated, but this could - theoretically - also be the fault of the coder, not the hardware.
It ain't so.
At least believing in and following experts is a good excuse in case you fail (Noone ever got fired for buying IBM - or trusting experts). It also saves time - if it works - which it does most time.
:-)
Best regards,
Wolfgang Denk