[U-Boot] [PATCH] 0/12 Multiadapter/multibus I2C

[ksi at koi8.net]

On Mon, 16 Feb 2009, Wolfgang Denk wrote:

> Dear ksi at koi8.net,
> 
> In message <Pine.LNX.4.64ksi.0902152236430.17769 at home-gw.koi8.net> you wrote:
> > 
> > Yep. But nobody's perfect and you can have a situation when you need to
> > access several busses before relocation. It is not hardware for U-Boot, it
> > is U-Boot for hardware. When hardware designers design their hardware they
> > don't make their decisions based on U-Boot limitation. That is us who should
> > accomodate what they designed.
> 
> We don't have to make the mainline U-Boot implementation  unnecessary
> complex  just  for  the  small  chance  that there is sombeody stupid
> enough to design a broken system.
> 
> It is our task as software engineers to tell the  hardware  designers
> which  designs  are  easy to support, nd which will cause problems in
> the software.

It is not complex. Quite in the contrary, it is much simpler and more
straightforward to have 2 sets of functions for 2 adapters in one place than
to have one that includes both of them in one place switchable using some
global variable at another place used by wrappers in a third place.

> 
> > There is also another consideration -- when having several adapters which
> > one should be initialized at boot time, before relocation? Another problem
> 
> The one that is needed there, if any at all.

You will have to pick that one for each and every board somehow...

> > is init() function that can be unique for each adapter. To make the lower
> > layer transparent I'm reprogramming muxes if any when switching busses. It
> > is necessary to make I2C API simple and uniform between muxed and non-muxed
> > busses. That essentially means that we can NOT do i2c_set_bus_num() to
> > execute init() for a particular adapter -- adapter MUST be initialized for
> > i2c_set_bus_num() to succeed.
> > 
> > Your suggestion requires total LOGIC change.
> 
> Maybe. But that's why we're discussing this here.
> 
> > > Is this needed? If so, you must before call a i2c_set_bus_num(), and after
> > > you finished call it again with the old busnumber. So it is done for example
> > > in do_date () common/cmd_date.c
> > 
> > You can not do it before all adapters are initialized. And you WON'T be able
> > to initialize adapters because you will not be able to switch busses.
> 
> This sounds like a design problem to me, then.
> 
> Please keep in  mind  that  according  to  U-Boot  philosophy  it  is
> forbidden to always initialize all adapters. Only those actually used
> by U-Boot may be initialized, and shall be de-initialized after use.

Eh, I don't see any problem initializing all I2C controllers at the same
time. What is the problem with that?

Then, we _DO_ already initialize _ALL_ controllers in U-Boot. Most of the
time the total number of controllers is 1 and we do initialize all of them.
In those rare cases when that number is not 1, we _DO_ initialize all of
them (look at fsl_i2c.c as it is in the main tree right now.) Existing
i2c_init() function does not have any provision for initializing any
particular controller; it initializes them all.

> > > Yes, thats a point. But do we need this before running from ram (except
> > > one hardwareadapter)?
> > 
> > Yes, see above.
> 
> Um... Maybe I missed something - did you give an example (except for
> broken designs) where this really might be needed?

We did not have such boards as of now but that does not mean they can't
exist. I would've agreed for making a handicapped version if it had been
difficult to make a full-featured one but it is not. Furthermore,
additional efforts required to put such a handicap on existing code.

> > > Yes, I know. But again, do we need this?
> > 
> > We do. Otherwise we can essentially throw everything to trash and start
> > over. This requires changing the logical design, architecture. And this is
> > that logic that is most difficult and takes most thinking. Coding is easy.
> 
> You say: "we do [need that]". I ask: why? what for?
> 
> > Another reason why macros are used is speed. Not everyone is running U-Boot
> > on 10 GHz Pentium-9 with gigabyte of cache. In bitbanged I2C every
> > instruction counts if you want to run a bus at a decent speed (I won't even
> > start with regular 100kHz less for 400kHz; 50kHz would be very good.) Your
> 
> Are you sure? If I remember correctly soft-I2C can even run 400 KHz on
> a slow 50 MHz MPC8xx system.
> 
> Do you have other numbers?

Is something wrong with those numbers?

> > must be executed. And remember, there is probably no instruction cache and
> > you're running off of flash so every instruction fetch is something like
> 
> I tend to say that an U-Boot port where instruction cache is disabled
> is misconfigured and should be fixed :-)

Eh, everything is easy when you have your RAM running and all handicaps
dropped off... Just try to run 100 meters with heavy weights on your legs
and you will see you can not compete with sprinters :)

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