Hi Alan,
> +#define MPU3050_XOUT_H 0x1D
Is this via the FIFO mentioned in the product brief, or directly to the
sensor register. A quick look for a datasheet didn't find a I2C register
listing...
> +static int mpu3050_xyz_read_reg(struct i2c_client *client,
> + u8 *buffer, int length)
> +{
> + struct i2c_msg msg[] = {
> + {
> + .addr = client->addr,
> + .flags = 0,
> + .len = 1,
> + .buf = buffer,
> + },
> + {
> + .addr = client->addr,
> + .flags = I2C_M_RD,
> + .len = length,
> + .buf = buffer,
> + },
> + };
> + return i2c_transfer(client->adapter, msg, 2);
> +}
This assumes a number of things, mainly that the interrupt latency is fast
enough that the 'NEXT' measurement does not overwrite the 'CURRENT' sample
whilst it is being read. This could lead to corrupt values.
Without a detailed datasheet for the MPU3050 I can't say for certain; but
usually there is another register which is set when a measurement is
taken. This can be cleared before and accessed after reading the XYZ
values to confirm that they have not been corrupted.
Also some I2C hosts (such as the Intel SCH) don't support I2C block
read/writes, and thus the access will be broken into separate reads/writes
and be much slower.
Hope I'm not speaking out of turn,
Simon.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
