summaryrefslogtreecommitdiff
path: root/drivers/i2c
diff options
context:
space:
mode:
authorShaveta Leekha <shaveta@freescale.com>2014-04-24 14:51:23 +0530
committerHeiko Schocher <hs@denx.de>2014-04-29 07:10:58 +0200
commita405764c1ec835a41ccda943b9156aee25e15d5e (patch)
tree9a54a9bd16b888e3c6f95f30090afbb36133868e /drivers/i2c
parentdec1861be90c948ea9fb771927d3d26a994d2e20 (diff)
downloadu-boot-imx-a405764c1ec835a41ccda943b9156aee25e15d5e.zip
u-boot-imx-a405764c1ec835a41ccda943b9156aee25e15d5e.tar.gz
u-boot-imx-a405764c1ec835a41ccda943b9156aee25e15d5e.tar.bz2
drivers/i2c/fsl_i2c: modify i2c_read to handle multi-byte write
Most of the I2C slaves support accesses in the typical style that is : read/write series of bytes at particular address offset. These transactions look like:" (1) START:Address:Tx:Offset:RESTART:Address[0..4]:Tx/Rx:data[0..n]:STOP" However there are certain devices which support accesses in terms of the transactions as follows: (2) "START:Address:Tx:Txdata[0..n1]:Clock_stretching: RESTART:Address:Rx:data[0..n2]" Here Txdata is typically a command and some associated data, similarly Rxdata could be command status plus some data received as a response to the command sent. Type (1) transactions are currently supportd in the i2c driver using i2c_read and i2c_write APIs. I2C EEPROMs, RTC, etc fall in this category. To handle type (2) along with type (1) transactions, i2c_read() function has been modified. Signed-off-by: Shaveta Leekha <shaveta@freescale.com> Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
Diffstat (limited to 'drivers/i2c')
-rw-r--r--drivers/i2c/fsl_i2c.c41
1 files changed, 34 insertions, 7 deletions
diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
index 291ad94..aa159f8 100644
--- a/drivers/i2c/fsl_i2c.c
+++ b/drivers/i2c/fsl_i2c.c
@@ -423,18 +423,45 @@ fsl_i2c_read(struct i2c_adapter *adap, u8 dev, uint addr, int alen, u8 *data,
struct fsl_i2c *device = (struct fsl_i2c *)i2c_dev[adap->hwadapnr];
int i = -1; /* signal error */
u8 *a = (u8*)&addr;
+ int len = alen * -1;
if (i2c_wait4bus(adap) < 0)
return -1;
- if ((!length || alen > 0)
- && i2c_write_addr(adap, dev, I2C_WRITE_BIT, 0) != 0
- && __i2c_write(adap, &a[4 - alen], alen) == alen)
- i = 0; /* No error so far */
+ /* To handle the need of I2C devices that require to write few bytes
+ * (more than 4 bytes of address as in the case of else part)
+ * of data before reading, Negative equivalent of length(bytes to write)
+ * is passed, but used the +ve part of len for writing data
+ */
+ if (alen < 0) {
+ /* Generate a START and send the Address and
+ * the Tx Bytes to the slave.
+ * "START: Address: Write bytes data[len]"
+ * IF part supports writing any number of bytes in contrast
+ * to the else part, which supports writing address offset
+ * of upto 4 bytes only.
+ * bytes that need to be written are passed in
+ * "data", which will eventually keep the data READ,
+ * after writing the len bytes out of it
+ */
+ if (i2c_write_addr(adap, dev, I2C_WRITE_BIT, 0) != 0)
+ i = __i2c_write(adap, data, len);
+
+ if (i != len)
+ return -1;
- if (length &&
- i2c_write_addr(adap, dev, I2C_READ_BIT, alen ? 1 : 0) != 0)
- i = __i2c_read(adap, data, length);
+ if (length && i2c_write_addr(adap, dev, I2C_READ_BIT, 1) != 0)
+ i = __i2c_read(adap, data, length);
+ } else {
+ if ((!length || alen > 0) &&
+ i2c_write_addr(adap, dev, I2C_WRITE_BIT, 0) != 0 &&
+ __i2c_write(adap, &a[4 - alen], alen) == alen)
+ i = 0; /* No error so far */
+
+ if (length &&
+ i2c_write_addr(adap, dev, I2C_READ_BIT, alen ? 1 : 0) != 0)
+ i = __i2c_read(adap, data, length);
+ }
writeb(I2C_CR_MEN, &device->cr);