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 07:42:09 +0100 [thread overview]
Message-ID: <499CFF41.5000000@denx.de> (raw)
In-Reply-To: <Pine.LNX.4.64ksi.0902181054310.5002@home-gw.koi8.net>
Hello ksi,
ksi at koi8.net wrote:
> On Wed, 18 Feb 2009, Heiko Schocher wrote:
>> Heiko Schocher schrieb:
>>> ksi at koi8.net wrote:
>>>> On Mon, 16 Feb 2009, Wolfgang Denk wrote:
>>>>
>>>>> Dear ksi at koi8.net,
>>>>>
>>>>> In message <Pine.LNX.4.64ksi.0902142019520.6240@home-gw.koi8.net> you wrote:
>>> [...]
>>>>>> And remember, the devil is in details. How are you going to assign
>>>>>> (initialize) that innocent looking "cur_adap_nr->hwadapnr"? How are you
>>>>>> going to work on an adapter other that "current" in a situation when you can
>>>>>> NOT change "current" adapter (e.g. perform all I2C layer initialization
>>>>>> while still running from flash?) Remember, this is plain C and there is no
>>>>> 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
>>> You have no i2c_set_current_bus() in your code! I think you mean
>>> i2c_set_current_bus(), right?
>>>
>>> And this function fails when running from flash! So, how can you switch
>>> busses with your patches when running from flash?
PLease answer my question!!!
How can you switch busses when running from flash???
>>> Here your function:
>>>
>>> int i2c_set_bus_num(unsigned int bus)
>>> {
>>> #ifndef CONFIG_SYS_I2C_DIRECT_BUS
>>> int i;
>>> u_int8_t buf;
>>> #endif
>>>
>>> if ((bus >= CONFIG_SYS_NUM_I2C_BUSSES) || !(gd->flags & GD_FLG_RELOC))
>>> return(-1);
>>> [...]
>>>
>>> This function wouldn;t work from flash ...
>> And one more reason, why your function will not work from flash:
>>
>> later in your i2c_set_bus_num function:
>> [...]
>> if ((i2c_bus[i2c_cur_bus].next_hop[0].chip != 0) &&
>> (ADAP(i2c_cur_bus)->init_done != 0)) {
>>
>> You only switch muxes if init_done != 0 ... but init_done is
>> not writeable when running from flash, so it is "= 0" when
>> code is not relocated ... how work this for you?
Again, how work this!
>> But this can be solved, if we always init the hardwareadapter
>> when switching to it and running from flash ... and if we are
>> relocated, we can analyse this flag, if init_done = 0, we init
>> this hardware adapter ...
>>
>> My proposal for the i2c_set_bus_num(unsigned int bus) function:
>>
>> int i2c_set_bus_num(unsigned int bus)
>> {
>> #ifndef CONFIG_SYS_I2C_DIRECT_BUS
>> int i;
>> u_int8_t buf;
>> #endif
>>
>> if (bus >= CONFIG_SYS_NUM_I2C_BUSSES)
>> return(-1);
>>
>> #ifndef CONFIG_SYS_I2C_DIRECT_BUS
>> /* Disconnect current bus (turn off muxes if any) */
>> if ((i2c_bus[i2c_cur_bus].next_hop[0].chip != 0) &&
>> (ADAP(i2c_cur_bus)->init_done != 0)) {
>>
>> i = CONFIG_SYS_I2C_MAX_HOPS;
>>
>> do {
>> u_int8_t chip;
>>
>> if ((chip = i2c_bus[i2c_cur_bus].next_hop[--i].chip) == 0)
>> continue;
>>
>> ADAP(i2c_cur_bus)->write(chip, 0, 0, &buf, 1);
>>
>> } while (i > 0);
>> }
>> #endif
>>
>> cur_adap_nr = (i2c_adap_t *)&ADAP(bus);
>> if (ADAP(bus)->init_done == 0) {
>> i2c_init_bus(bus, ADAP(bus)->speed, ADAP(bus)->slaveaddr);
>> }
>>
>> #ifndef CONFIG_SYS_I2C_DIRECT_BUS
>> /* Connect requested bus if behind muxes */
>> if (i2c_bus[bus].next_hop[0].chip != 0) {
>>
>> /* Set all muxes along the path to that bus */
>> for (i = 0; i < CONFIG_SYS_I2C_MAX_HOPS; i++) {
>>
>> if (i2c_bus[bus].next_hop[i].chip == 0) break;
>>
>> i2c_mux_set(i2c_bus[bus].adapter,
>> i2c_bus[bus].next_hop[i].mux.id,
>> i2c_bus[bus].next_hop[i].chip,
>> i2c_bus[bus].next_hop[i].channel);
>> }
>> }
>> #endif
>>
>> i2c_cur_bus = bus;
>> return(0);
>> }
>>
>> This function should also work, when running from flash. + a hardware adapter
>> is only initialized when we switch to it, so no need to initialize all
>> hardwareadapters somewhere ...
>> (requirement: cur_adap_nr, i2c_cur_bus is writeable when running in flash)
>
> You are multiplying entities. i2c_init() is invoked as a part of system
But Wolfgang suggested to init an I2C adapter just if we use it, and
above function will do this. Again read my EMails. I wrote:
>> This function should also work, when running from flash. + a hardware adapter
>> is only initialized when we switch to it, so no need to initialize all
>> hardwareadapters somewhere ...
So no need for calling i2c_init in libXXX/board.c or somewhere. We must just
look that for example in dtt_init is also a i2c_set_bus_num () called.
> bootup process in libXXX/board.c anyways. There is no need for any global
> variables, even non-writable for proposed code to initialize adapters.
Not for initialize adapters, because you want to init all adapters.
But if we want to do what Wolfgang suggested, we don;t need to call
i2c_init for all adapters.
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 6:42 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
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 [this message]
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=499CFF41.5000000@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox