Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain; charset="utf-8"
Cc:     jmaneyrol@invensense.com, stevemo@skydio.com, jic23@kernel.org,
        knaack.h@gmx.de, lars@metafoo.de, pmeerw@pmeerw.net,
        linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
User-Agent: SOGoMail 4.0.7
MIME-Version: 1.0
Date:   Tue, 21 May 2019 12:40:32 +0200
Subject: ICM20602 buffer issues with the =?utf-8?q?inv=5Fmpu6050?= driver
Message-ID: <42bd-5ce3d580-2b-ca9e8b0@181689754>
From:   "Andreea Lutac" <andreea.lutac@fixposition.ch>
Content-Transfer-Encoding: quoted-printable
To:     unlisted-recipients:; (no To-header on input)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hello,

I've been trying to get some data samples from the ICM20602 IMU using t=
he mpu6050 driver which recently added support for it, but I'm encounte=
ring an issue with the ordering of the data in the FIFO. 
According to the specs of the device, if the accel and gyro XYZ channel=
s are enabled, then the hardware FIFO is filled with 14 bytes correspon=
ding to the following channels: accel=5Fx, accel=5Fy, accel=5Fz, temp, =
anglvel=5Fx, anglvel=5Fy, anglvel=5Fz. However, when reading out the bu=
ffer, the value I get for anglvel=5Fx seems to actually be the temperat=
ure. This  occurs both when reading with iio=5Fchannel=5Fread (via libi=
io) and also if I read directly from /dev/iio:device with only in=5Fang=
lvel=5Fx=5Fen set. But in=5Fanglvel=5Fx=5Fraw reports correct values, w=
hich made me suspect that maybe somewhere in the driver this interleave=
d temp channel is not accounted for in the buffer structure.

I had a look at the driver code and inv=5Fmpu6050=5Fread=5Ffifo() in pa=
rticular, but I can't identify anything amiss. I've applied the recent =
patch that added the extra 2 temperature bytes (https://patchwork.kerne=
l.org/patch/10882883/), but the problem persists. So far I've tried cha=
nging the size of the data buffer, defined in inv=5Fmpu=5Fiio.h: 

/* 6 + 6 round up and plus 8 */
#define INV=5FMPU6050=5FOUTPUT=5FDATA=5FSIZE     24 

from 24 to 32, according to the intuition that 24 corresponds to readin=
gs without temperature (i.e. 6 bytes for accel, rounded up to 8 + 6 byt=
es for gyro, rounded up to 8 + 8 bytes for the timestamp =3D 24) and th=
us another 8 bytes would be needed, but that doesn't seem to have solve=
d it.

I'm quite new to driver development though, so I think there might be s=
omething I'm not getting. I would be really grateful if anyone could sh=
ed some light over what's happening here or give some advice as to what=
 I could be doing wrong.

Best regards,
Andreea Lutac