i2c: i2c-uclass-compat: avoid any BSS usage

As I2C can be used before DRAM initialization for reading EEPROM,
avoid using static variables stored in BSS, since BSS is in DRAM, which
may not have bee

i2c: i2c-uclass-compat: avoid any BSS usage

As I2C can be used before DRAM initialization for reading EEPROM,
avoid using static variables stored in BSS, since BSS is in DRAM, which
may not have been initialised yet. Explicitly mark "static global"
variables as belonging to the .data section.

Signed-off-by: Vignesh R <vigneshr@ti.com>
Acked-by: Heiko Schocher<hs@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...

Merge branch 'u-boot/master' into 'u-boot-arm/master'

Merge branch 'master' of git://git.denx.de/u-boot

Merge git://git.denx.de/u-boot-dm

dm: i2c: Add compatibility functions for dm_i2c_reg_read/write()

Add the legacy i2c_reg_read/write() functions to the compatibility layer
so that they can be used when CONFIG_DM_I2C_COMPAT is define

dm: i2c: Add compatibility functions for dm_i2c_reg_read/write()

Add the legacy i2c_reg_read/write() functions to the compatibility layer
so that they can be used when CONFIG_DM_I2C_COMPAT is defined.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Heiko Schocher <hs@denx.de>

show more ...

Merge remote-tracking branch 'u-boot/master' into 'u-boot-arm/master'

Merge branch 'master' of git://git.denx.de/u-boot

Merge branch 'master' of git://git.denx.de/u-boot-dm

dm: i2c: Add two more I2C init functions to the compatibility layer

These functions are useful in case the board calls them. Also fix a missing
parameter caused by applying the wrong patch (actually

dm: i2c: Add two more I2C init functions to the compatibility layer

These functions are useful in case the board calls them. Also fix a missing
parameter caused by applying the wrong patch (actually I failed to send v2
and applied v1 by mistake).

Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...

dm: i2c-uclass-compat: fix missed argument

This patch fixes build error for CONFIG_DM_I2C_COMPAT.
In i2c_get_chip_for_busnum() call, one of argument was missed,
which was offset_len. Now it is set t

dm: i2c-uclass-compat: fix missed argument

This patch fixes build error for CONFIG_DM_I2C_COMPAT.
In i2c_get_chip_for_busnum() call, one of argument was missed,
which was offset_len. Now it is set to 'alen' as previous.

Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Acked-by: Simon Glass <sjg@chromium.org>

show more ...

dm: i2c: Move slave details to child platdata

At present we go through various contortions to store the I2C's chip
address in its private data. This only exists when the chip is active so
must be se

dm: i2c: Move slave details to child platdata

At present we go through various contortions to store the I2C's chip
address in its private data. This only exists when the chip is active so
must be set up when it is probed. Until the device is probed we don't
actually record what address it will appear on.

However, now that we can support per-child platform data, we can use that
instead. This allows us to set up the address when the child is bound,
and avoid the messy contortions.

Unfortunately this is a fairly large change and it seems to be difficult to
break it down further.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>

show more ...

dm: i2c: Add a compatbility layer

For boards which use multiple I2C devices, or for SOCs which support
multiple boards, we might want to convert these to driver model at different
times. At present

dm: i2c: Add a compatbility layer

For boards which use multiple I2C devices, or for SOCs which support
multiple boards, we might want to convert these to driver model at different
times. At present this is difficult because we need to either use
CONFIG_DM_I2C for a board or not.

Add a compatibility layer which implements the old API, thus allowing a
board to move to driver model for I2C without requiring that everything it
uses is moved in the same commit.

Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...