Dear ksi@koi8.net,
In message Pine.LNX.4.64ksi.0902171233390.30435@home-gw.koi8.net you wrote:
What is unreadable in that code?
It gets out of control. You don;t see any more how much code gets generated from that.
This is a boot loader with limited resources, not a general purpose OS.
It doesn't matter. It is much better to have a uniform API for all the future developers to use than to multiply horrible hacks and reinventing the wheel again and again.
Well, I tell you again that size does matter, and may even be a killing point when deciding abouut a patch.
What makes you insist that we cannot change a variable if we need to be able to change one?
It is NOT just variable. My approach uses i2c _BUS_, not _ADAPTER_. And number of busses can be bigger than number of adapters (e.g. when some busses a reached via muxes or switches.) When doing i2c_set_current_bus() you are switching _NOT_ adapters, but busses. That involves not only changing that global variable but also reprogramming muxes/switches for i2c_set_current_bus() to be consistent and hardware independent. Otherwise your code should know if that particular bus it is switching to is directly connected or switched and check the bus it is switching from for muxes. If they are switched, your code should disconnect the current bus switches, then do that i2c_set_current_bus() and connect the switches to the new bus after that.
That means that code MUST somehow know the topology to take appropriate actions and properly configure those switches. That means you should somehow describe that topology for each and every board in CONFIG_* terms and make each and every place at U-Boot that invokes _ANY_ i2c function to take care of that switching.
You convinced me. This code must not be used before relocation to RAM, then.
[On the other hand I still wonder why I have never seen any such board appear to me in real life yet. None of the 500+ boards supported in U-Boot uses any such configuration.]
And yes, we DO have some boards with switched I2C busses in U-Boot main tree so this is NOT a hypothetical situation.
Yes, it is, because none of them needs any such switching before relocation. And switching is really simple so far.
And the million dollar question -- what is the potential gain?
Indeed. The same question goes to you - where is this added complexity really needed? So far nowhere. Are we just talking about hypothetical cases, or about a real design? How many such designs? Just a single one?
Please see above.
You did not answer my question.
Best regards,
Wolfgang Denk