Re: Adding SMBus block transfers to iic(4)
Just an update here.
In order to enable requesting block-mode transfers using the
I2C_IOCTL_EXEC method from userland, I'm now proposing to add two new
high-level operations to the i2c_op_t enum, along with a new macro
predicate:
typedef enum {
I2C_OP_READ_WITH_STOP = 1,
I2C_OP_WRITE= 2,
I2C_OP_WRITE_WITH_STOP = 3,
+ I2C_OP_READ_BLOCK = 5,/* All block operations imply STOP */
+ I2C_OP_WRITE_BLOCK = 7
} i2c_op_t;
#defineI2C_OP_READ_P(x)(((int)(x) 2) == 0)
#defineI2C_OP_WRITE_P(x) (! I2C_OP_READ_P(x))
#defineI2C_OP_STOP_P(x)(((int)(x) 1) != 0)
+#defineI2C_OP_BLKMODE_P(x) (((int)(x) 4) != 0)
On Sun, 11 Mar 2012, Paul Goyette wrote:
There are apparently some devices out there that really need to have i2c
block-mode transfers, and it appears that none of our current drivers (at
least, none of the mainstream pci drivers) supports this.
At first glance, it might appear that we could simply check the transfer
requested byte-count, and automatically operate in block mode if the count is
greater than 2; the implication is that we could fall back to byte or word
transfers for smaller byte counts. But it looks like at least one device out
there [1] doesn't support this.
So I propose adding a new flag bit that can be passed to iic_exec() to
request block-transfer protocols. In src/sys/dev/i2c/i2c_io.h
#define I2C_F_BLOCK 0x20
Comments? Suggestions? Alternatives?
[1] http://eeepc-linux.googlecode.com/files/9LPR426A.pdf
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-
!DSPAM:4f5d2d7a1985496917264!
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-
Adding SMBus block transfers to iic(4)
There are apparently some devices out there that really need to have i2c block-mode transfers, and it appears that none of our current drivers (at least, none of the mainstream pci drivers) supports this. At first glance, it might appear that we could simply check the transfer requested byte-count, and automatically operate in block mode if the count is greater than 2; the implication is that we could fall back to byte or word transfers for smaller byte counts. But it looks like at least one device out there [1] doesn't support this. So I propose adding a new flag bit that can be passed to iic_exec() to request block-transfer protocols. In src/sys/dev/i2c/i2c_io.h #define I2C_F_BLOCK 0x20 Comments? Suggestions? Alternatives? [1] http://eeepc-linux.googlecode.com/files/9LPR426A.pdf - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: Adding SMBus block transfers to iic(4)
[...] i2c block-mode transfers [...] #define I2C_F_BLOCK 0x20 Comments? Suggestions? Alternatives? BLOCK has a second, quite different, meaning (as in, blocking I/O). It may not apply here, but defining a bit in the interface that can be misunderstood as indicating it does could, at the very least, be confusing. Might I suggest BLKMODE instead of BLOCK? At least to my eye, that's a lot less ambiguous. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Adding SMBus block transfers to iic(4)
Good point. On Sun, 11 Mar 2012, Mouse wrote: [...] i2c block-mode transfers [...] #define I2C_F_BLOCK 0x20 Comments? Suggestions? Alternatives? BLOCK has a second, quite different, meaning (as in, blocking I/O). It may not apply here, but defining a bit in the interface that can be misunderstood as indicating it does could, at the very least, be confusing. Might I suggest BLKMODE instead of BLOCK? At least to my eye, that's a lot less ambiguous. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B !DSPAM:4f5d315b1981260811860! - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
