From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] 7/12 Multiadapter/multibus I2C, drivers part 4
Date: Thu, 19 Feb 2009 16:06:05 +0100 [thread overview]
Message-ID: <499D755D.10009@denx.de> (raw)
In-Reply-To: <Pine.LNX.4.64ksi.0902190644570.17744@home-gw.koi8.net>
Hello ksi,
ksi at koi8.net wrote:
> On Thu, 19 Feb 2009, Heiko Schocher wrote:
>
>> Hello ksi,
>>
>> ksi at koi8.net wrote:
>>> On Wed, 18 Feb 2009, Heiko Schocher wrote:
>>>
>>>> Hello Wolfgang,
>>>>
>>>> Wolfgang Denk wrote:
>>>>> Dear ksi at koi8.net,
>>>>>
>>>>> In message <Pine.LNX.4.64ksi.0902171233390.30435@home-gw.koi8.net> you wrote:
>>>> [...]
>>>>>>> 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.
>>>> But is is possible to use that code when running from flash, if
>>>> this current pointer is writeable ...
>>> It is not the pointer that must be writeable, it's what it is pointing to...
>> But in your approach this is also not writeable! So we lost nothing, when
>> using such a pointer.
>
> No, we did NOT. I can still cal adap[N]->init() and it will init the proper
For what you will do this, when you can;t use the adapter, when running from
flash? See Later, why you cannot use it.
> adapter. It does NOT require any global variables for it, it is
> self-sufficient.
But you could not switch busses, nor work with it, first because
i2c_set_bus_num() don;t work for you and i2c_cur_bus is not writeable,
so _all_ accesses with the API in i2c-core.c like for example
int i2c_read(u_int8_t chip, unsigned int addr, int alen,
u_int8_t *buffer, int len)
{
return(ADAP(i2c_cur_bus)->read(chip, addr, alen, buffer, len));
}
_will_ fail, when running from flash, because i2c_cur_bus is not
writeable!
So why will you initialize all adapters when running from flash?
But this is no problem, when we make i2c_cur_bus or this pointer
I would like to see, writeable. And think about my proposal for
i2c_set_bus_num() and we have there also no problem with calling
init() for an adapter.
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
next prev parent reply other threads:[~2009-02-19 15:06 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
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 [this message]
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=499D755D.10009@denx.de \
--to=hs@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.