On 05/14/2016 06:10 PM, Guenter Roeck wrote:
> On 05/14/2016 04:30 AM, Crestez Dan Leonard wrote:
>> On 05/14/2016 03:38 AM, Guenter Roeck wrote:
>>> On 05/13/2016 11:54 AM, Crestez Dan Leonard wrote:
>>>> This adds mode 'i' for I2C_SMBUS_I2C_BLOCK_DATA. This is the same mode
>>>> letter from i2cdump.
>>>>
>>>> Length is optional and defaults to 32 (maximum).
>>>>
>>>> The indended use is debugging i2c devices with shell commands.
>>>>
>>> How does this differ from the 'i' option of i2cdump ?
>>
>> Apparently i2cdump doesn't support a range in "i" mode. I considered
>> adding a range to i2cdump in all modes but:
>> - i2cdump code is a more complicated
>
> Maybe, but it already supports the command.
>
>> - Not all devices interpret i2c bulk read as a register range. Reading
>> X bytes from register Y can be different from reading registers from X
>> to X+Y.
>>
> Not sure I understand what that has to do with supporting i2c block data.
> Both commands call i2c_smbus_read_i2c_block_data(). Please explain.
I just found it easier to implement this as an extension to i2cget
rather than add range support to i2cdump 'i' mode. I also think it's a
better fit for i2cget because the "length" parameter doesn't always
imply a register range.
As to how this is useful: I have an i2c sensor where new data can come
in while the driver is still reading and this will prevent further
interrupts. I can confirm this by issuing a command like:
i2cget -f -y 0 0x18 0xa8 i 6
This bulk read of 6 bytes will unlock the driver for a short while.
This can't be done with current i2cdump's 'i' mode because that just
dumps all registers. i2cdump's byte/word modes issue multiple reads
which is not fast enough.
--
Regards,
Leonard
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
