[U-Boot] [PATCH] 7/12 Multiadapter/multibus I2C, drivers part 4

[ksi at koi8.net]

On Thu, 19 Feb 2009, Wolfgang Denk wrote:

> Dear ksi at koi8.net,
> 
> In message <Pine.LNX.4.64ksi.0902191024560.18501 at home-gw.koi8.net> you wrote:
> > 
> > Argh... Do you understand that those send_start etc. are _NOT_ the
> > functions? One more time -- they are _NOT_ functions, they are _TEMPLATES_.
> 
> 
> Please, please: calm down.
> 
> I think there is no reason to claim that Heiko did not understand
> this.

Yeah, that was a bit too far from my side, my apologies for that.

> On the other side, I,  too,  feel  that  you  should  (just  for  the
> theoretical  possibility  of  another,  probably completey stupid and
> braindead and whatever, but still another approach to solve the  same
> set  of  problems)  try to follow Heiko's thoughts and see where that
> would take us?
> 
> If you continue to perseverate on the position that your code is  the
> only possible solution, we might as well stop the discussion here.

Eh, I did try and I analyzed that approach in several postings. Please trust
me, I'm not sticking to my own approach and I do not hesitate to borrow
anything I could. Nobody's perfect and one have to run very fast just to
stay in place in our profession less for moving forward... We have to learn
constantly and I love to learn new things. That replaces me drugs, alcohol,
whatever.

I wouldn't've object for a second if that've had any benefits. But that did
not have any and handicaps however small they are were aplenty.

> > Hm... Please explain how are you going to use 2 different sets of pins with
> > different access methods with one function?
> 
> Been there before. See for example
> http://lists.denx.de/pipermail/u-boot/2009-February/047937.html

Yep. It is possible but it is not any better. It doesn't provide any
benefits. I did already explain this in several postings. If it did give
some benefits I would definitely use that way.

> > So we should make a monster with switches off of each and every send_start()
> > and friends and pass them a value to decide which set to use?
> 
> No, of course not.
> 
> > That makes everything more messy and has a performance penalty -- instead of
> > simple branch to those simple blocks you are adding at least one register
> > load per call to load that argument.
> 
> That seams a _terrible_ overhead to me: one register load per call.
> How fast is that I2C bus? Well below 50 kByte per second, right?
> 
> Please stay serious.

It is not big but it IS an overhead. One register load here, one function
call there and soon we are bloated up to our ears. But the main factor is
NOT that overhead. It simply doesn't give any benefits so it is not any
better even if didn't have any overhead. I wouldn't hesitate to go that way
if there were any benefits.

> > > No problem with this.
> > 
> > There IS a problem First, that means you have _ABSOLUTELY_ no way to access
> > any other adapter than default one until that variable made writable.
> 
> Please let's stop considering this as a problem.
> 
> Let's accept that this is a self-imposed and accepted restriction.

Eh, this is not about switching busses while running from flash, I was not
going to support this either. But it gives at least some means for a simple
hack if one or two boards really need this. Using global variable for this
a.) does not give any benefits and b.) removes any possibility for accessing
any adapter but the default one at all, hackish or not.

> > Second, all class functions must be self-sufficient, they should NOT rely on
> > some external global variable to work. That might sound C++ese but no matter
> > how I don't like C++ it does many things right.
> 
> We don't use C++ here, and we are not that strict if it allows for
> smaller code or solves other problems.

But it does not make code smaller or solve any problems. I would definitely
consider it if it did.

> > I can call a member function for any adapter directly if needed with
> > adap[N]->function(). You can NOT because in your case that "N" does not have
> > any effect and your functions rely on an external global variable that you
> > can not change.
> 
> Regards from the rat race. I am really tired of that.
> 
> It makes no sense to continue this discussion with you when  you  are
> not  willing  to  even  discuss  the  possibility  of  an alternative
> implementation that allows for a  (writable!)  global  variable,  and
> then  you  continue  claiming  we  could  not  use writable variables
> (especially when we will not even require it because  we  don;t  need
> bus switching before relocation).
> 
> There are better things I can do in my spare time.

Eh... I AM discussing it here. And that is NOT about switching busses while
running from flash...

Guys, why are you not listening?... That variable, put aside all the
ugliness and blasphemy, what problem it solves and what benefits it gives?
Please show me some, pull my eyelids and open my eyes and may be I'll see
the light... Where are the benefits?

> > That's a separate issue. I can offer N other ways to achieve this other than
> > using that horror. And if they use the same binary image for different
> > boards those boards are not different. If they put a chip on different bus
> > that means the hardware is different. Different hardware means quite a
> > lengthy process involving changes to the schematics, then re-layout, new set
> > of gerbers, new PCBs, new BOM, new P&P programs etc. Such an effort
> > definitely deserves a separate config file and simple repompile of U-Boot
> > that takes less than a minute time.
> 
> Do you  know  which  effort  is  involved  in  maintaining  different
> software  versions  in  a big project? It is a BIG win if you can use
> the same binary image on many differen board configurations.

Sure I do know. I'm in charge of some such projects right now and had been
doing this before. Just for info -- I'm not an impulsive young kid, I'm 50
years old fart so I saw plenty of anything...

> And who tells you that that allthe I2C busses and devices are on one
> board? There is things like backplanes that connect boards, where
> different boards in differnt configfurations may be inserted or
> removed and ... and ... 

I can suggest many other ways to accomodate such systems without those
dynamic busses. And keeping the entire maintenance and deployment concept
intact. With all that topology in EEPROM etc. Those dynamic busses are not
the only way to achieve this and even not the best one.

> Please get a clue before making such statements!

If you guys had looked at the code you would've noticed that I _DID_
reworked those 2 particular boards and offered not just an approach but a
working code to implement it. It might be not all that perfect (it never
happens on the first attempt) but it works and does not require that oddity.

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