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

Wolfgang Denk wd at denx.de
Tue Feb 17 13:27:33 CET 2009


Dear ksi at koi8.net,

In message <Pine.LNX.4.64ksi.0902162132540.27482 at home-gw.koi8.net> you wrote:
> 
> > 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.

To code I've seen so far looked pretty complex, and the fact that
we've spend many rounds of discussion here seems to indicate a certain
level of cmplexity, too.

> > > 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...

Only for those boards that need it, whichis a tiny fraction of all
boards which use I2C. And there,it should be trivial to configure in
the board config file.

> > 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?

Why would you do that? It makes little sense to initialize components
that may never be accessed at all.

> 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.

When we re-implementing that code, we should fix that error instead
of copying it.

> > > 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?

You seem to claim that soft-I2C cannot run at 400 kHz clock. I doubt
that claim.

> > 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 :)

We're at the point: who needs I2C before relocation to  RAM?  Only  a
small fraction of all boards. How many of these use soft-I2C? An even
smaller  fraction. For how many of these is it critical to run at 100
kHz I2C clock or faster? Well, I think the answer is none here.

We're wasting time and efforts on a non-issue.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
He had been eight years upon a project for extracting sunbeams out of
cucumbers, which were to be put in vials hermetically sealed, and let
out to warm the air in raw inclement summers.        - Jonathan Swift
              _Gulliver's Travels_ ``A Voyage to Laputa, etc.'' ch. 5


More information about the U-Boot mailing list