From: Kim Phillips <kim.phillips@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 03/12] 83xx, kmeter1: add I2C, dtt, eeprom support
Date: Wed, 18 Feb 2009 18:55:07 -0600 [thread overview]
Message-ID: <20090218185507.4e3663ee.kim.phillips@freescale.com> (raw)
In-Reply-To: <499BC34D.5010004@denx.de>
On Wed, 18 Feb 2009 09:14:05 +0100
Heiko Schocher <hs@denx.de> wrote:
> >>> between boots? If not, what's the reason the value isn't specified as
> >>> a CONFIG_SYS_DTT_BUS_NUM?
> >> It changes not between boots, but between different hardware.
> >
> > so why not make it a CONFIG_SYS_DTT_BUS_NUM instead of permanently
> > polluting environment namespace. That's what the rest of the boards
> > that use this DTT code do; what makes the kmeter1 special in this
> > regard? Because CONFIG_SYS_DTT_BUS_NUM is not just a single number?
>
> There are several hardwareversions, which only differ in the way, how
> the DTTs are reached (0,1,2 muxes and they use also different channels
> ...). So we save this "way" in an environment variable. When running
> in RAM, it is just a number see else part ...
>
> > In that case we can make CONFIG_SYS_DTT_BUS_REF or something (not sure
> > if that's a good enough name).
>
> What exactly do you mean with that?
you're assigning the env var dtt_bus "pca9547:70:a" whereas other
boards assign CONFIG_SYS_DTT_BUS_NUM a single integer value.
> But I was wondering why the DTTs are initialized so early. Is this
> necessary? If not, I don;t need this ...
I searched and didn't find out why. If there's no reason then maybe we
don't need it indeed.
Meanwhile, I've applied the 'v2' versions of your patches and still
have trouble building the kmeter1 board*, probably due to inter-patch
dependencies in this patchseries. This means at minimum you're breaking
git-bisection abilities for your boards. Can you resubmit without
breaking bisection?
Also, did you want any of these to go through the mpc83xx
tree, or should WD pick all of them up? Please make two separate
patchseries if you're targeting two trees.
Kim
* currently giving up at:
Configuring for kmeter1 board...
fsl_i2c.c:45: warning: 'i2c_bus_num_mux' defined but not used
lm75.c: In function 'dtt_init':
lm75.c:167: warning: implicit declaration of function 'i2c_mux_ident_muxstring_f'
../common/common.c: In function 'ivm_check_crc':
../common/common.c:202: error: 'CONFIG_SYS_IVM_EEPROM_PAGE_LEN' undeclared (first use in this function)
../common/common.c:202: error: (Each undeclared identifier is reported only once
../common/common.c:202: error: for each function it appears in.)
../common/common.c: In function 'ivm_analyze_block2':
../common/common.c:215: error: 'CONFIG_SYS_IVM_EEPROM_PAGE_LEN' undeclared (first use in this function)
../common/common.c:215: warning: unused variable 'valbuf'
../common/common.c: In function 'ivm_analyze_eeprom':
../common/common.c:244: error: 'CONFIG_SYS_IVM_EEPROM_PAGE_LEN' undeclared (first use in this function)
../common/common.c:244: warning: unused variable 'valbuf'
../common/common.c: In function 'ivm_read_eeprom':
../common/common.c:298: error: 'I2C_MUX_DEVICE' undeclared (first use in this function)
../common/common.c:298: error: 'dev' undeclared (first use in this function)
../common/common.c:299: error: 'CONFIG_SYS_IVM_EEPROM_MAX_LEN' undeclared (first use in this function)
../common/common.c:301: error: 'CONFIG_SYS_IVM_EEPROM_ADR' undeclared (first use in this function)
../common/common.c:309: warning: implicit declaration of function 'i2c_mux_ident_muxstring'
../common/common.c:299: warning: unused variable 'i2c_buffer'
make[1]: *** [../common/common.o] Error 1
make[1]: *** Waiting for unfinished jobs....
kmeter1.c: In function 'board_init_i2c_busses':
kmeter1.c:67: error: 'I2C_MUX_DEVICE' undeclared (first use in this function)
kmeter1.c:67: error: (Each undeclared identifier is reported only once
kmeter1.c:67: error: for each function it appears in.)
kmeter1.c:67: error: 'dev' undeclared (first use in this function)
kmeter1.c:73: warning: implicit declaration of function 'i2c_mux_ident_muxstring'
make[1]: *** [kmeter1.o] Error 1
make: *** [board/keymile/kmeter1/libkmeter1.a] Error 2
powerpc-linux-gnu-size: './u-boot': No such file
next prev parent reply other threads:[~2009-02-19 0:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-11 18:25 [U-Boot] [PATCH 03/12] 83xx, kmeter1: add I2C, dtt, eeprom support Heiko Schocher
2009-02-17 1:36 ` Kim Phillips
2009-02-17 6:03 ` Heiko Schocher
2009-02-18 1:22 ` Kim Phillips
2009-02-18 8:14 ` Heiko Schocher
2009-02-19 0:55 ` Kim Phillips [this message]
2009-02-19 8:10 ` Heiko Schocher
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=20090218185507.4e3663ee.kim.phillips@freescale.com \
--to=kim.phillips@freescale.com \
--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