u-boot.git/drivers/i2c, branch v2015.10-rc2

i2c: lpc32xx: fix write timeout

2015-08-17T12:11:50Z

Fix a condition that generate watchdog timeout inside "lpc32xx_i2c_write" when parameters alen = 0 and len = 0. Signed-off-by: Sylvain Lemieux

i2c: lpc32xx: fix read timeout

2015-08-17T12:11:49Z

Fix a condition that generate watchdog timeout inside "lpc32xx_i2c_read" when parameters alen != 0 and len = 0. Signed-off-by: Sylvain Lemieux

i2c: lpc32xx: use api to get hclk instead of fix value

2015-08-17T12:11:49Z

The HCLK is not constant and can take different value; use the api function to get the value of the HCLK for the I2C clock high and low computation. Signed-off-by: Sylvain Lemieux

drivers: hierarchize drivers Kconfig menu

2015-08-13T00:47:44Z

The menuconfig for drivers are getting more and more cluttered and unreadable because too many entries are displayed in a single flat menu. Use hierarchic menu for each category. Signed-off-by: Masahiro Yamada Reviewed-by: Simon Glass [trini: Update to apply again in a few places, drop USB hunk] Signed-off-by: Tom Rini

cros_ec: Support the LDO access method used by spring

2015-08-06T03:06:11Z

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

dm: cros_ec: Convert the I2C tunnel code to use driver model

2015-08-06T03:06:11Z

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

exynos: i2c: Tidy up the driver model code

2015-08-06T03:06:10Z

The existing driver model implementation uses the old non-driver-model code to operate, but has become impossibly tangled as a result. The actual algorithm is quite simple. Also the normal-speed and high-speed buses are quite different and it doesn't seem that useful to put them in the same driver. Finally, there is a bug which breaks communication with the Maxim sound codec and may cause problems with other device. Rewrite the driver model code for normal-speed operation so that it is easier to understand, and fix the bug. Add a TODO to split the drivers. Signed-off-by: Simon Glass Reviewed-by: Heiko Schocher

exynos: i2c: Fix code style with ReadWriteByte()

2015-08-06T03:06:10Z

This function should not use mixed case, and it is simpler to use clrbits_le32() when clearing bits. Fix it. Signed-off-by: Simon Glass Acked-by: Heiko Schocher

i2c: Add a mux for GPIO-based I2C bus arbitration

2015-08-06T03:06:10Z

While I2C supports multi-master buses this is difficult to get right. The implementation on the master side in software is quite complex. Clock-stretching and the arbitrary time that an I2C transaction can take make it difficult to share the bus fairly in the face of high traffic. When one or more masters can be reset independently part-way through a transaction it is hard to know the state of the bus. This driver provides a scheme based on two 'claim' GPIOs, one driven by the AP (Application Processor, meaning the main CPU) and one driven by the EC (Embedded Controller, a small CPU aimed at handling system tasks). With these they can communicate and reliably share the bus. This scheme has minimal overhead and involves very little code. It is used on snow to permit the EC and the AP to share access to the main system PMIC and battery. The scheme can survive reboots by either side without difficulty. This scheme has been tested in the field with millions of devices. Since U-Boot runs on the AP, the terminology used is 'our' claim GPIO, meaning the AP's, and 'their' claim GPIO, meaning the EC's. This terminology is used by the device tree bindings in Linux also. Signed-off-by: Simon Glass

dm: i2c: Add support for multiplexed I2C buses

2015-08-06T03:06:10Z

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