Skip to contentSkip to conversation

i2c: Bus drivers don't have to support I2C_M_REV_DIR_ADDR

PATCH In review Jean Delvare 2 participants 3 messages Sep 30, 2009 – Oct 14, 2009 2 messages not in the archive

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 i2c: Bus drivers don't have to support I2C_M_REV_DIR_ADDR

I2C bus drivers don't have to support I2C_M_REV_DIR_ADDR. It is a deviation from the I2C specification, which only makes sense to implement when really needed.

---
 drivers/i2c/busses/i2c-iop3xx.c   |    6 ------
 drivers/i2c/busses/i2c-mv64xxx.c  |    3 ---
 drivers/i2c/busses/i2c-powermac.c |    2 --
 3 files changed, 11 deletions(-)
drivers/i2c/busses/i2c-iop3xx.c +0 -6
@@ -56,12 +56,6 @@ iic_cook_addr(struct i2c_msg *msg)
 	if (msg->flags & I2C_M_RD)
 		addr |= 1;
 
-	/*
-	 * Read or Write?
-	 */
-	if (msg->flags & I2C_M_REV_DIR_ADDR)
-		addr ^= 1;
-
 	return addr;   
 }
 
drivers/i2c/busses/i2c-mv64xxx.c +0 -3
@@ -338,9 +338,6 @@ mv64xxx_i2c_prepare_for_io(struct mv64xx
 	if (msg->flags & I2C_M_RD)
 		dir = 1;
 
-	if (msg->flags & I2C_M_REV_DIR_ADDR)
-		dir ^= 1;
-
 	if (msg->flags & I2C_M_TEN) {
 		drv_data->addr1 = 0xf0 | (((u32)msg->addr & 0x300) >> 7) | dir;
 		drv_data->addr2 = (u32)msg->addr & 0xff;
drivers/i2c/busses/i2c-powermac.c +0 -2
@@ -156,8 +156,6 @@ static int i2c_powermac_master_xfer(	str
 		return -EINVAL;
 	read = (msgs->flags & I2C_M_RD) != 0;
 	addrdir = (msgs->addr << 1) | read;
-	if (msgs->flags & I2C_M_REV_DIR_ADDR)
-		addrdir ^= 1;
 
 	rc = pmac_i2c_open(bus, 0);
 	if (rc)
Signature · 1 line
Jean Delvare

A message that is not in the archive (sent off-list or not yet received): [email protected]

#2 lore raw
Quoted 3 lines · Jean Delvare

I2C bus drivers don't have to support I2C_M_REV_DIR_ADDR. It is a deviation from the I2C specification, which only makes sense to implement when really needed.

Probably the right thing to do, does anything actually use this support?

Quoted 6 lines
---
 drivers/i2c/busses/i2c-iop3xx.c   |    6 ------
 drivers/i2c/busses/i2c-mv64xxx.c  |    3 ---
 drivers/i2c/busses/i2c-powermac.c |    2 --

I assume that I should merge this in my -next tree?

Signature · 3 lines
Ben ([email protected], http://www.fluff.org/)

  'a smiley only costs 4 bytes'

A message that is not in the archive (sent off-list or not yet received): [email protected]

#4 lore raw

Hi Ben,

Quoted 7 lines · Ben Dooks
Quoted 3 lines · Jean Delvare

I2C bus drivers don't have to support I2C_M_REV_DIR_ADDR. It is a deviation from the I2C specification, which only makes sense to implement when really needed.

Probably the right thing to do, does anything actually use this support?

As far as I know, the only chip which uses this is the "Maven" which is found on some Matrox G450 graphics cards to handle the second head.

As the i2c-matroxfb driver builds on top of i2c-algo-bit, i2c-algo-bit is the only driver which needs to implement I2C_M_REV_DIR_ADDR.

I've left it in i2c-algo-pcf and i2c-s3c2410 for now because at least they properly declare the I2C_FUNC_PROTOCOL_MANGLING functionality, but this could be reconsidered.

The other protocol mangling flags are in a similar situation. For example I2C_M_NOSTART is only used by the Intel i915 and Matrox Maven chips. Both use i2c-algo-but, but no less than 9 other I2C adapter drivers implement it! Most of these implementations have most probably never been tested, and I wouldn't be surprised if some don't work.

I2C_M_IGNORE_NAK is only used by the msp3400 audio processing driver. But it is implemented by embedded I2C adapter drivers which probably will never see this chip: i2c-davinci, i2c-omap, i2c-s3c2410 and i2c-stu300.

I2C_M_NO_RD_ACK is only used by the ks0127 video driver, and only i2c-algo-bit implements it. That one is correct.

Quoted 8 lines
Quoted 6 lines
---
 drivers/i2c/busses/i2c-iop3xx.c   |    6 ------
 drivers/i2c/busses/i2c-mv64xxx.c  |    3 ---
 drivers/i2c/busses/i2c-powermac.c |    2 --

I assume that I should merge this in my -next tree?

Probably, yes. For now I have this patch in my own -next tree, but as all drivers affected are embedded ones, it would fit better in yours.

I leave it up to you to decide what to do with the i2c-s3c2410 driver. As I understand it, it doesn't need to implement I2C_M_REV_DIR_ADDR nor I2C_M_IGNORE_NAK nor I2C_M_NOSTART, so you could simplify the code a bit and stop defining I2C_FUNC_PROTOCOL_MANGLING.

BTW, is your -next tree visible somewhere? It might be convenient for me to be able to check what it includes.

Signature · 1 line
Jean Delvare