Dear k...@koi8.net,
In message <pine.lnx.4.64ksi.0902162132540.27...@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: w...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
