From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] 7/12 Multiadapter/multibus I2C, drivers part 4
Date: Tue, 17 Feb 2009 23:49:39 +0100 [thread overview]
Message-ID: <20090217224940.02BC6832E893@gemini.denx.de> (raw)
In-Reply-To: <Pine.LNX.4.64ksi.0902171233390.30435@home-gw.koi8.net>
Dear ksi at koi8.net,
In message <Pine.LNX.4.64ksi.0902171233390.30435@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.
> > 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.
> > 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.]
> 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.
> > > 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.
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
I express preference for a chronological sequence of events which
precludes a violence. - Terry Pratchett, _The Dark Side of the Sun_
next prev parent reply other threads:[~2009-02-17 22:49 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-13 10:17 [U-Boot] [PATCH] 7/12 Multiadapter/multibus I2C, drivers part 4 Heiko Schocher
2009-02-13 21:23 ` ksi at koi8.net
2009-02-14 8:24 ` Heiko Schocher
2009-02-15 5:03 ` ksi at koi8.net
2009-02-15 7:56 ` Heiko Schocher
2009-02-16 6:35 ` ksi at koi8.net
2009-02-16 9:03 ` Heiko Schocher
2009-02-16 22:17 ` Wolfgang Denk
2009-02-17 21:23 ` ksi at koi8.net
2009-02-16 22:16 ` Wolfgang Denk
2009-02-17 21:22 ` ksi at koi8.net
2009-02-18 7:23 ` Heiko Schocher
2009-02-16 22:11 ` Wolfgang Denk
2009-02-17 21:19 ` ksi at koi8.net
2009-02-17 22:49 ` Wolfgang Denk [this message]
2009-02-17 23:42 ` ksi at koi8.net
2009-02-18 0:13 ` Wolfgang Denk
2009-02-18 0:35 ` ksi at koi8.net
2009-02-18 7:47 ` Heiko Schocher
2009-02-18 18:05 ` ksi at koi8.net
2009-02-18 18:26 ` Wolfgang Denk
2009-02-18 19:47 ` ksi at koi8.net
2009-02-18 22:09 ` Wolfgang Denk
2009-02-18 23:00 ` ksi at koi8.net
2009-02-18 23:31 ` Wolfgang Denk
2009-02-19 0:46 ` ksi at koi8.net
2009-02-19 8:00 ` Heiko Schocher
2009-02-19 19:48 ` ksi at koi8.net
2009-02-19 20:50 ` Wolfgang Denk
2009-02-19 22:26 ` ksi at koi8.net
2009-02-20 8:53 ` Heiko Schocher
2009-02-20 7:08 ` Heiko Schocher
2009-02-20 7:06 ` Heiko Schocher
2009-02-18 7:33 ` Heiko Schocher
2009-02-18 8:06 ` Wolfgang Denk
2009-02-18 8:15 ` Heiko Schocher
2009-02-18 8:55 ` Wolfgang Denk
2009-02-18 18:58 ` ksi at koi8.net
2009-02-18 18:51 ` ksi at koi8.net
2009-02-18 17:44 ` ksi at koi8.net
2009-02-19 6:10 ` Heiko Schocher
2009-02-19 14:46 ` ksi at koi8.net
2009-02-19 15:06 ` Heiko Schocher
2009-02-19 19:52 ` ksi at koi8.net
2009-02-19 20:55 ` Wolfgang Denk
2009-02-19 22:33 ` ksi at koi8.net
2009-02-20 7:09 ` Heiko Schocher
2009-02-18 7:20 ` Heiko Schocher
2009-02-18 18:48 ` ksi at koi8.net
2009-02-19 6:31 ` Heiko Schocher
2009-02-19 19:35 ` ksi at koi8.net
2009-02-19 21:22 ` Wolfgang Denk
2009-02-20 0:13 ` ksi at koi8.net
2009-02-20 7:01 ` Heiko Schocher
2009-02-20 21:29 ` ksi at koi8.net
2009-02-21 7:25 ` Heiko Schocher
2009-02-21 18:19 ` ksi at koi8.net
2009-02-18 8:17 ` Heiko Schocher
2009-02-18 8:58 ` Heiko Schocher
2009-02-18 18:57 ` ksi at koi8.net
2009-02-18 21:56 ` Wolfgang Denk
2009-02-18 22:32 ` ksi at koi8.net
2009-02-18 22:48 ` Wolfgang Denk
2009-02-19 0:35 ` ksi at koi8.net
2009-02-19 8:04 ` Heiko Schocher
2009-02-19 21:29 ` Wolfgang Denk
2009-02-19 7:39 ` Heiko Schocher
2009-02-19 19:40 ` ksi at koi8.net
2009-02-19 6:42 ` Heiko Schocher
2009-02-18 18:53 ` ksi at koi8.net
2009-02-19 6:34 ` Heiko Schocher
2009-02-19 19:36 ` ksi at koi8.net
-- strict thread matches above, loose matches on Subject: below --
2009-02-12 22:25 ksi at koi8.net
2009-02-16 21:58 ` Wolfgang Denk
2009-02-17 20:02 ` ksi at koi8.net
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090217224940.02BC6832E893@gemini.denx.de \
--to=wd@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox