This is a possible drop in replacement for drivers/i2c/zynq-i2c.c

Since this is cadence IP it has been renamed to cdns-i2c,
to make sense with the compatible string.

Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

This is used on most Intel platforms. We don't have a driver for it yet, but
add a stub to handle the init. For now this targets ivybridge so we may want
to add a device tree binding and generalise it when other platforms are
supported.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Since I2C muxes are seldom needed in SPL, and the code for this increases
the size somewhat, add a separate option to enable I2C muxes for SPL.

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

compiling U-Boot for avr32 boards shows since
commit 3d1957f0ea01 "dm: i2c: Add support for multiplexed I2C buses"
this warning:

Building current source for 4 boards (4 threads, 8 jobs per thread)
     avr32:  +   atstk1002
+(atstk1002) drivers/i2c/built-in.o: warning: input is not relaxable
     avr32:  +   grasshopper
+(grasshopper) drivers/i2c/built-in.o: warning: input is not relaxable
     avr32:  +   atngw100
+(atngw100) drivers/i2c/built-in.o: warning: input is not relaxable
     avr32:  +   atngw100mkii
+(atngw100mkii) drivers/i2c/built-in.o: warning: input is not relaxable
    0    4    0 /4      0:00:16  : atngw100mkii

Fix it.

Signed-off-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Roger Meier <r.meier@siemens.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andreas Bießmann <andreas.devel@googlemail.com>

This arch does not seem to be supported / used at all in the current
U-Boot mainline source tree any more. So lets remove the core u8500 code
and code that was only referenced by this platform.

Please note that this patch also removes these config options:

- CONFIG_PL011_SERIAL_RLCR
- CONFIG_PL011_SERIAL_FLUSH_ON_INIT

As they only seem to be referenced by u8500 based boards. Without any
such board in the current code, these config option don't make sense
any more. Lets remove them as well.

If someone still wants to use this platform, then please send patches
to re-enable support by adding at least one board that references this
code.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: John Rigby <john.rigby@linaro.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Add an I2C driver for the Rockchip RK3288, using driver model. It should work
for other Rockchip SoCs also.

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

Add a driver to support the special LDO access used by spring. This is a
custom method in the cros_ec protocol - it does not use an I2C
pass-through.

There are two implementation choices:

1. Write a special LDO driver which can talk across the EC. Duplicate all
the logic from TPS65090 for retrying when the LDO fails to come up.

2. Write a special I2C bus driver which pretends to be a TPS65090 and
transfers reads and writes using the LDO message.

Either is distasteful. The latter method is chosen since it results in less
code duplication and a fairly simple (30-line) implementation of the core
logic.

The crosec 'ldo' subcommand could be removed (since i2c md/mw will work
instead) but is retained as a convenience.

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

The Chrome OS EC supports tunnelling through to an I2C bus on the EC. This
currently uses a copy of the I2C command code and a special 'crosec'
sub-command.

With driver model we can define an I2C bus which tunnels through to the EC,
and use the normal 'i2c' command to access it. This simplifies the code and
removes some duplication.

Add an I2C driver which tunnels through to the EC. Adjust the EC code to
support binding child devices so that it can be set up. Adjust the existing
I2C xfer function to fit driver model better.

For now the old code remains to allow things to still work. It will be
removed in a later patch once the new flow is fully enabled.

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

Add a new I2C_MUX uclass. Devices in this class can multiplex between
several I2C buses, selecting them one at a time for use by the system.
The multiplexing mechanism is left to the driver to decide - it may be
controlled by GPIOs, for example.

The uclass supports only two methods: select() and deselect().

The current mux state is expected to be stored in the mux itself since
it is the only thing that knows how to make things work. The mux can
record the current state and then avoid switching unless it is necessary.
So select() can be skipped if the mux is already in the correct state.
Also deselect() can be made a nop if required.

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

This commit adds driver model support to software emulated i2c bus driver.
This driver supports kernel-style device tree bindings. Fdt properties in use:
- compatible - "i2c-gpio"
- gpios      - data and clock GPIO pin phandles
- delay-us   - micro seconds delay between GPIOs toggle operations,
               which is 1/4 of I2C speed clock period.

Added:
- Config: CONFIG_DM_I2C_GPIO
- File: drivers/i2c/i2c-gpio.c
- File: doc/device-tree-bindings/i2c/i2c-gpio.txt

Driver base code is taken from: drivers/i2c/soft-i2c.c, changes:
- use "i2c-gpio" naming
- update comments style
- move preprocesor macros into functions
- add device tree support
- add driver model i2c support
- code cleanup,
- add Kconfig entry

Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Acked-by: Simon Glass <sjg@chromium.org>
Added braces in i2c_gpio_xfer() to fix style nit:
Signed-off-by: Simon Glass <sjg@chromium.org>