On Tue, 17 Feb 2009, Wolfgang Denk wrote: > Dear k...@koi8.net, > > In message <pine.lnx.4.64ksi.0902171233390.30...@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.
Why not? But anyways, I can make those instances manually, without CPP participations. Would it be better? > > > 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. There is no much size increase here. Also it is still possible to simply include just those adapters that are required for SPD and thus reduce size if several I2C drivers make it too big. > > > 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.] Eh, for those 500+ (actually 472 judging on the number of files in include/configs) boards there are at least twice that many that were never submitted to the U-Boot tree... I have ported U-Boot/Linux to at least 10 different boards that were never submitted anywhere myself. You know, company only pays for making their boards work, not for pushing them in the official tree. This is the second company where I have a luxury of crafting patches for submission (the first one was that now defunct that allowed me to push that Davinci port.) And one can not even imagine what runaway hardware designers can design... I still remember some Brasilian MPC8560/Fujitsu ARM boards that were pure nightmare to work on :( > > 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. No, it is not easy. You simply did not dig deep enough :) > > > > 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. OK, this is not about using multiple I2C busses before relocation and using them right now for any of existing boards (some of which are actually dead or vaporware.) This is about consistent logical API for multiple I2C busses. As for multiple busses I personally need that right now for my new board. That board has 2 ST Micro M41ST87 chips on it (braindead chip, I wouldn't've used such a weirdo but it is "certified" by our licensing authorities so I have to) and DS1307 RTT. M41ST87 is a Tamper Detector with RTT but I can not use those RTTs for timekeeping because they are frozen to give a tamper event timestamp hence the separate RTT. Operation procedure requires to check for tamper events on bootup and if one's detected the system must log the current bootup time, give some indication to the user and halt for proper authorities to investigate. The problem is M41ST87 uses a fixed I2C address, 0x68 that is also used by RTT. That means I need 3 I2C busses to talk to those 3 chips... And this is just a first such board out of a whole bunch that we have in various stages. The next one, OMAP3-based, is almost ready, we should have prototypes in a month or two. And we are not the only players at that niche market (however very old ones,) there are others. And this is just one of heavily regulated industries (you know those big shiny casinos on Las Vegas Strip, don't ya? :) There are others with different braindead requirements out there... --- ****************************************************************** * k...@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ****************************************************************** _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
