iio: imu new driver

iio: imu new driver

[Fawzi Khaber]

Hello Jonathan,
We are currently implementing a new driver for an invensense chip similar to 
iio/imu/inv_icm42600. The chip has 2 sensors a gyroscope and an 
accelerometer, and we are wandering if it was better the have two 
IIO devices, one for each sensor, or just one IIO device with two buffers.

Best regards,

Fawzi.

Re: iio: imu new driver

[Lars-Peter Clausen]

On 4/14/22 12:35, Fawzi Khaber wrote:
> Hello Jonathan,
> We are currently implementing a new driver for an invensense chip similar to
> iio/imu/inv_icm42600. The chip has 2 sensors a gyroscope and an
> accelerometer, and we are wandering if it was better the have two
> IIO devices, one for each sensor, or just one IIO device with two buffers.

Are these two completely independent sensors that only sit in the same 
package or do they share a common clock and the data acquisition can be 
synchronized?

If it is the latter the best might be to have a single device with a 
single buffer.

Typical algorithms that process IMU data, like odometry, want to process 
the accelerator and gyroscope data jointly. If the data gets 
artificially separated into two buffers it first has to be re-aligned, 
which might be tricky to do.

- Lars

Re: iio: imu new driver

[Jean-Baptiste Maneyrol]

Hello,

accel and gyro are synchronized and are outputting data inside the same hardware FIFO, as inv_icm42600 is doing. The issue is that the sensors have different frequencies, using a header for signaling data availability, thus demultiplexing from userspace is not possible in a standard way.

Solution found for inv_icm42600 was to use 2 devices with each one a buffer. FIFO is read, data demultiplexed, and sent in each device. Now that we can have 2 buffers for 1 device, is it simpler to use this solution rather than 2 devices?

Thanks for your advice,
JB


From: Lars-Peter Clausen <lars@metafoo.de>
Sent: Thursday, April 14, 2022 13:19
To: Fawzi Khaber <Fawzi.Khaber@tdk.com>; jic23@kernel.org <jic23@kernel.org>
Cc: Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@tdk.com>; linux-iio <linux-iio@vger.kernel.org>
Subject: Re: iio: imu new driver 
 
[CAUTION] This is EXTERNAL email. Do not click any links or open attachments unless you recognize the sender and know the content is safe.

======================================================================
On 4/14/22 12:35, Fawzi Khaber wrote:
> Hello Jonathan,
> We are currently implementing a new driver for an invensense chip similar to
> iio/imu/inv_icm42600. The chip has 2 sensors a gyroscope and an
> accelerometer, and we are wandering if it was better the have two
> IIO devices, one for each sensor, or just one IIO device with two buffers.

Are these two completely independent sensors that only sit in the same 
package or do they share a common clock and the data acquisition can be 
synchronized?

If it is the latter the best might be to have a single device with a 
single buffer.

Typical algorithms that process IMU data, like odometry, want to process 
the accelerator and gyroscope data jointly. If the data gets 
artificially separated into two buffers it first has to be re-aligned, 
which might be tricky to do.

- Lars

Re: iio: imu new driver

[Lars-Peter Clausen]

On 4/14/22 15:03, Jean-Baptiste Maneyrol wrote:
> Hello,
>
> accel and gyro are synchronized and are outputting data inside the same hardware FIFO, as inv_icm42600 is doing. The issue is that the sensors have different frequencies, using a header for signaling data availability, thus demultiplexing from userspace is not possible in a standard way.
>
> Solution found for inv_icm42600 was to use 2 devices with each one a buffer. FIFO is read, data demultiplexed, and sent in each device. Now that we can have 2 buffers for 1 device, is it simpler to use this solution rather than 2 devices?
>
> Thanks for your advice,
> JB

Hi,

So the data rates are synchronized, but different, i.e. integer ratios?

I think this might be a good use case to give the multi-buffer support a 
bit of real world testing.

- Lars


>
>
> From: Lars-Peter Clausen <lars@metafoo.de>
> Sent: Thursday, April 14, 2022 13:19
> To: Fawzi Khaber <Fawzi.Khaber@tdk.com>; jic23@kernel.org <jic23@kernel.org>
> Cc: Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@tdk.com>; linux-iio <linux-iio@vger.kernel.org>
> Subject: Re: iio: imu new driver
>   
> [CAUTION] This is EXTERNAL email. Do not click any links or open attachments unless you recognize the sender and know the content is safe.
>
> ======================================================================
> On 4/14/22 12:35, Fawzi Khaber wrote:
>> Hello Jonathan,
>> We are currently implementing a new driver for an invensense chip similar to
>> iio/imu/inv_icm42600. The chip has 2 sensors a gyroscope and an
>> accelerometer, and we are wandering if it was better the have two
>> IIO devices, one for each sensor, or just one IIO device with two buffers.
> Are these two completely independent sensors that only sit in the same
> package or do they share a common clock and the data acquisition can be
> synchronized?
>
> If it is the latter the best might be to have a single device with a
> single buffer.
>
> Typical algorithms that process IMU data, like odometry, want to process
> the accelerator and gyroscope data jointly. If the data gets
> artificially separated into two buffers it first has to be re-aligned,
> which might be tricky to do.
>
> - Lars

Re: iio: imu new driver

[Jonathan Cameron]

On Thu, 14 Apr 2022 13:03:28 +0000
Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@tdk.com> wrote:

> Hello,
> 
> accel and gyro are synchronized and are outputting data inside the same hardware FIFO, as inv_icm42600 is doing. The issue is that the sensors have different frequencies, using a header for signaling data availability, thus demultiplexing from userspace is not possible in a standard way.
> 
> Solution found for inv_icm42600 was to use 2 devices with each one a buffer. FIFO is read, data demultiplexed, and sent in each device. Now that we can have 2 buffers for 1 device, is it simpler to use this solution rather than 2 devices?
> 

yes.  I'd go with two buffers, one device now we have the option to do that.
You 'could' do something special to allow the case where the sampling rates are
equal if that is sufficiently interesting but so far I don't think we have
any drivers doing that sort of thing.

Roughly speaking it would mean two buffers:
1) Buffer A: All channels present - but you could only enable them all
   if the sampling frequencies match.
2) Buffer B: Other channels with separate sampling frequencies.

Then a user could in theory pick the best of all possible worlds.
I'm assuming that there are truely synchronised modes, but there
are device out there where the sensors are independently clocked
and just push into a common front end buffer. If it's one of those
then this trick wouldn't work.

Note I wouldn't enable this initially in the drive anyway as its
going to be complex - start off with two buffers and get that upstream
first.

Thanks,

Jonathan

> Thanks for your advice,
> JB
> 
> 
> From: Lars-Peter Clausen <lars@metafoo.de>
> Sent: Thursday, April 14, 2022 13:19
> To: Fawzi Khaber <Fawzi.Khaber@tdk.com>; jic23@kernel.org <jic23@kernel.org>
> Cc: Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@tdk.com>; linux-iio <linux-iio@vger.kernel.org>
> Subject: Re: iio: imu new driver 
>  
> [CAUTION] This is EXTERNAL email. Do not click any links or open attachments unless you recognize the sender and know the content is safe.
> 
> ======================================================================
> On 4/14/22 12:35, Fawzi Khaber wrote:
> > Hello Jonathan,
> > We are currently implementing a new driver for an invensense chip similar to
> > iio/imu/inv_icm42600. The chip has 2 sensors a gyroscope and an
> > accelerometer, and we are wandering if it was better the have two
> > IIO devices, one for each sensor, or just one IIO device with two buffers.  
> 
> Are these two completely independent sensors that only sit in the same 
> package or do they share a common clock and the data acquisition can be 
> synchronized?
> 
> If it is the latter the best might be to have a single device with a 
> single buffer.
> 
> Typical algorithms that process IMU data, like odometry, want to process 
> the accelerator and gyroscope data jointly. If the data gets 
> artificially separated into two buffers it first has to be re-aligned, 
> which might be tricky to do.
> 
> - Lars