u-boot.git/post/drivers/i2c.c, branch v2016.03 Unnamed repository; edit this file 'description' to name the repository. Add GPL-2.0+ SPDX-License-Identifier to source files 2013-07-24T13:44:38+00:00 Wolfgang Denk wd@denx.de 2013-07-08T07:37:19+00:00 1a4596601fd395f3afb8f82f3f840c5e00bdd57a Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com> 
Signed-off-by: Wolfgang Denk <wd@denx.de>
[trini: Fixup common/cmd_io.c]
Signed-off-by: Tom Rini <trini@ti.com>
post: fix I2C POST failure for devices in CONFIG_SYS_POST_I2C_IGNORES 2013-05-01T14:37:35+00:00 Anatolij Gustschin agust@denx.de 2013-04-15T04:01:07+00:00 c55285015ab0c94265665af01c80e60b080f5ac4 Devices in CONFIG_SYS_POST_I2C_IGNORES list may be absent and the rule is not to report I2C POST failure for devices in this list. Currently this doesn't work since probing for these devices isn't done and thus they are not marked as successfully probed. Ignore optional devices when checking for devices that didn't respond. Signed-off-by: Anatolij Gustschin <agust@denx.de> 
Devices in CONFIG_SYS_POST_I2C_IGNORES list may be absent
and the rule is not to report I2C POST failure for devices
in this list. Currently this doesn't work since probing for
these devices isn't done and thus they are not marked as
successfully probed. Ignore optional devices when checking
for devices that didn't respond.

Signed-off-by: Anatolij Gustschin <agust@denx.de>
post, i2c: add missing curly bracket in i2c_post_test 2010-11-17T07:04:03+00:00 Heiko Schocher hs@denx.de 2010-11-15T07:20:39+00:00 9b107e6138e719ea5a0b924862a9b109c020c7ac If CONFIG_SYS_POST_I2C_ADDRS is not defined and CONFIG_SYS_POST_I2C is activated, i2c_probe() is not called in the for statement, because missing curly bracket. Signed-off-by: Heiko Schocher <hs@denx.de> 
If CONFIG_SYS_POST_I2C_ADDRS is not defined and CONFIG_SYS_POST_I2C
is activated, i2c_probe() is not called in the for statement,
because missing curly bracket.

Signed-off-by: Heiko Schocher <hs@denx.de>
post/drivers/i2c.c: fix compile error 2010-10-27T18:09:59+00:00 Wolfgang Denk wd@denx.de 2010-10-26T21:22:36+00:00 8343f8a76434b7162cf5a4da5f456b014868853c Commit 7e263ce "post/i2c: Clean up detection logic" added a "const" qualifier to the declaration of i2c_addr_list[], missing the fact that the list gets modified later in the code, which results in build errors like these: i2c.c: In function 'i2c_post_test': i2c.c:88: error: assignment of read-only location Remove the incorrect "const". Signed-off-by: Wolfgang Denk <wd@denx.de> Cc: Peter Tyser <ptyser@xes-inc.com> Cc: Heiko Schocher <hs@denx.de> Acked-by: Heiko Schocher <hs@denx.de> 
Commit 7e263ce "post/i2c: Clean up detection logic" added a "const"
qualifier to the declaration of i2c_addr_list[], missing the fact that
the list gets modified later in the code, which results in build
errors like these:

i2c.c: In function 'i2c_post_test':
i2c.c:88: error: assignment of read-only location

Remove the incorrect "const".

Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Peter Tyser <ptyser@xes-inc.com>
Cc: Heiko Schocher <hs@denx.de>
Acked-by: Heiko Schocher <hs@denx.de>
post/i2c: Add ability to ignore I2C devices 2010-10-22T07:19:14+00:00 Peter Tyser ptyser@xes-inc.com 2010-10-22T05:20:31+00:00 9d921f19b3f981a499f49a57e2c3ace7be5aeecc Add the ability to not report an I2C POST error for a set of given I2C addresses on bootup. This is useful for cases when a device may or may not be present, and neither case is considered an error. For example: - Some form factors such as XMC and Compact PCI Express have an I2C EEPROM whose address changes based on geographical address. Eg installed in one slot its EEPROM address is, 0x50, in another its 0x51, etc. This allows multiple devices to have their EEPROMs present on the same I2C bus. Thus the I2C devices present for an XMC or CPCIe card depend on if and where other cards are installed in the same system. - Some cards have optional I2C devices. Eg one hardware build configuration has different I2C devices than another and software can't determine if the optional device should be present or not. - Some cards have optional daughtercards with I2C devices on them. - I2C EEPROMs address range depends on their size. Its possible to support differently size EEPROMs by only probing the EEPROM's base address and ignoring the other addresses that are impacted by its size. A new CONFIG_SYS_POST_I2C_IGNORES define has been added which specifies a list of I2C addresses for the I2C POST to ignore. Signed-off-by: Peter Tyser <ptyser@xes-inc.com> Acked-by: Heiko Schocher <hs@denx.de> Acked-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> 
Add the ability to not report an I2C POST error for a set of given I2C
addresses on bootup.  This is useful for cases when a device may or may
not be present, and neither case is considered an error.  For example:

- Some form factors such as XMC and Compact PCI Express have an I2C
  EEPROM whose address changes based on geographical address.  Eg
  installed in one slot its EEPROM address is, 0x50, in another its
  0x51, etc.  This allows multiple devices to have their EEPROMs present
  on the same I2C bus.  Thus the I2C devices present for an XMC or
  CPCIe card depend on if and where other cards are installed in the
  same system.

- Some cards have optional I2C devices.  Eg one hardware build
  configuration has different I2C devices than another and software
  can't determine if the optional device should be present or not.

- Some cards have optional daughtercards with I2C devices on them.

- I2C EEPROMs address range depends on their size.  Its possible to
  support differently size EEPROMs by only probing the EEPROM's base
  address and ignoring the other addresses that are impacted by its
  size.

A new CONFIG_SYS_POST_I2C_IGNORES define has been added which specifies
a list of I2C addresses for the I2C POST to ignore.

Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
Acked-by: Heiko Schocher <hs@denx.de>
Acked-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
post/i2c: Rename I2C_ADDR_LIST to CONFIG_SYS_POST_I2C_ADDRS 2010-10-22T07:19:00+00:00 Peter Tyser ptyser@xes-inc.com 2010-10-22T05:20:30+00:00 60aaaa0782848062d0f499382035acc09eaff352 Signed-off-by: Peter Tyser <ptyser@xes-inc.com> Acked-by: Heiko Schocher <hs@denx.de> Acked-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> 
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
Acked-by: Heiko Schocher <hs@denx.de>
Acked-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
post/i2c: Don't probe address 0 2010-10-22T07:18:42+00:00 Peter Tyser ptyser@xes-inc.com 2010-10-22T05:20:29+00:00 9f949c9ac2c1bb5077a146753e24c7b3fe099991 According to the I2C specification device address 0 is the "general call address", ie a broadcast address. The I2C specification states that the format of a general call uses at least 2 bytes, which U-Boot's probing routine does not adhere to. Not probing device address 0 will prevent possible issues with devices that accept general calls. Additionally, this change shouldn't reduce POST coverage since each I2C device should still be accessed via its own, unique address. Signed-off-by: Peter Tyser <ptyser@xes-inc.com> Acked-by: Heiko Schocher <hs@denx.de> Acked-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> 
According to the I2C specification device address 0 is the "general call
address", ie a broadcast address.  The I2C specification states that the
format of a general call uses at least 2 bytes, which U-Boot's probing
routine does not adhere to.

Not probing device address 0 will prevent possible issues with devices
that accept general calls.  Additionally, this change shouldn't reduce
POST coverage since each I2C device should still be accessed via its
own, unique address.

Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
Acked-by: Heiko Schocher <hs@denx.de>
Acked-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
post/i2c: Clean up detection logic 2010-10-22T07:18:36+00:00 Peter Tyser ptyser@xes-inc.com 2010-10-22T05:20:28+00:00 7e263cea88995d0b4b9fb659a95c382128feca71 The logic previously used in the I2C post was a bit convoluted. Signed-off-by: Peter Tyser <ptyser@xes-inc.com> Acked-by: Heiko Schocher <hs@denx.de> Acked-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> 
The logic previously used in the I2C post was a bit convoluted.

Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
Acked-by: Heiko Schocher <hs@denx.de>
Acked-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
post/i2c: General clean up 2010-10-22T07:18:30+00:00 Peter Tyser ptyser@xes-inc.com 2010-10-22T05:20:27+00:00 b9b1bc8542db5f26453c45db843903dee7056244 - Clean up ifdeffery - Update coding style No functional change should have occurred. Signed-off-by: Peter Tyser <ptyser@xes-inc.com> Acked-by: Heiko Schocher <hs@denx.de> Acked-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> 
- Clean up ifdeffery
- Update coding style

No functional change should have occurred.

Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
Acked-by: Heiko Schocher <hs@denx.de>
Acked-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
rename CFG_ macros to CONFIG_SYS 2008-10-18T19:54:03+00:00 Jean-Christophe PLAGNIOL-VILLARD plagnioj@jcrosoft.com 2008-10-16T13:01:15+00:00 6d0f6bcf337c5261c08fabe12982178c2c489d76 Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> 
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>