Re: [PATCH v2 09/12] iio: imu: inv_icm42600: add buffer support in iio devices

2020-06-06 Thread Jonathan Cameron
On Tue, 2 Jun 2020 12:57:26 +
Jean-Baptiste Maneyrol  wrote:

> Hi Jonathan,
> 
> I agree that this multiplexed watermark computation value is anything except 
> simple and clear to understand.
> I will add more documentation about it. And it also triggered a
> kbuild robot issue, because it is using 64 bits modulo without using
> math64 macros.
> 
> For buffer preenable/postenable/..., the sequence I am using
> currently is:
> - preenable -> turn chip on (pm_runtime_get)
> - update_scan_mode -> set FIFO en bits configuration (which sensor
> data is going into the fifo)
> - hwfifo_watermark -> compute and set watermark value
> - postenable -> turn FIFO on (and multiplexed with a FIFO on counter
> since used by accel & gyro)
> - predisable -> turn FIFO off (multiplexed with counter)
> - postdisable -> turn chip off (pm_runtime_put)
> 
> This setting is working well. Good to note that if there is an error
> when enabling the buffer, postdisable will always get called after
> preenable. So it ensures pm_runtime reference counter to be always OK.
> 
> Another way would be to only store configuration in internal state
> with update_scan_mode and hwfifo_watermark, and do everything in
> postenable/predisable. This is a possibility, but makes things a
> little more complex.

What you have here is fine.  Thanks for the explanation.

> 
> For hwfifo flush, this is an interesting feature when there is a need
> to have data immediately. Or when there is a need to do a clean
> change of configuration. In Android systems, Android framework is
> mainly using FIFO flush to change the sensor configuration (ODR,
> watermark) in a clean way. For our case with the FIFO interleaved
> this is a not an issue. If there are samples from the 2 sensors, it
> means the 2 buffers are enabled. And if data is coming to the iio
> buffer sooner than expected, that should not be a problem. The
> limitation I see when the 2 sensors are runnings, is that we will
> return less data than should have been possible. I limit FIFO reading
> to the provided n bytes, so we could read less than n samples of 1
> sensor.

Yes.  I'm a little nervous about unexpected impacts of this last
case.  As you say early data rarely matters but late data can
potentially be an issue as software will assume it didn't get the
data because it didn't yet exist.

> 
> Something I have in mind, that would be really interesting to be able
> to set/change watermark value when the buffer is enabled. Otherwise,
> we are always loosing events by turning sensor off when we want to
> change the value. Is there any limitation to work this way, or should
> it be possible to implement this feature in the future ?

I can't see why it would particularly matter in general if we did this
whilst 'live'. However, potentially we have sensors where reducing the
value could result in not getting an interrupt from a hw fifo.
(unwise design perhaps but we all know those exist :)

So care would be needed - perhaps some kind of opt in?

> 
> Thanks,
> JB

Please remember to wrap our email if possible.

Thanks,

Jonathan



> 
> 
> From: Jonathan Cameron 
> Sent: Sunday, May 31, 2020 14:56
> To: Jean-Baptiste Maneyrol 
> Cc: robh...@kernel.org ; r...@kernel.org 
> ; mchehab+hua...@kernel.org ; 
> da...@davemloft.net ; gre...@linuxfoundation.org 
> ; linux-...@vger.kernel.org 
> ; devicet...@vger.kernel.org 
> ; linux-kernel@vger.kernel.org 
> 
> Subject: Re: [PATCH v2 09/12] iio: imu: inv_icm42600: add buffer support in 
> iio devices 
>  
>  CAUTION: This email originated from outside of the organization. Please make 
> sure the sender is who they say they are and do not click links or open 
> attachments unless you recognize the sender and know the content is safe.
> 
> On Wed, 27 May 2020 20:57:08 +0200
> Jean-Baptiste Maneyrol  wrote:
> 
> > Add all FIFO parsing and reading functions. Add accel and gyro
> > kfifo buffer and FIFO data parsing. Use device interrupt for
> > reading data FIFO and launching accel and gyro parsing.
> > 
> > Support hwfifo watermark by multiplexing gyro and accel settings.
> > Support hwfifo flush.  
> 
> Both of these are complex given the interactions of the two sensors
> types and to be honest I couldn't figure out exactly what the intent was.
> Needs more docs!
> 
> Thanks,
> 
> Jonathan
> 
> > 
> > Signed-off-by: Jean-Baptiste Maneyrol 
> > ---
> >  drivers/iio/imu/inv_icm42600/Kconfig  |   1 +
> >  drivers/iio/imu/inv_icm42600/Makefile |   1 +
> >  drivers/iio/imu/inv_icm42600/inv_icm42600.h   |   8 +
> >  .../iio/imu/inv_icm42600/inv_icm42600_accel.c | 160 -
> >  .../imu/inv_icm426

Re: --[[SPOOF or PHISHING]]--Re: [PATCH v2 09/12] iio: imu: inv_icm42600: add buffer support in iio devices

2020-06-03 Thread Jean-Baptiste Maneyrol
Hi Jonathan,

something I forgot, about the __packed attribute for the sensor data structure 
struct inv_icm42600_fifo_sensor_data located inside inv_icm42600_buffer.h.

I added it because this structure is used for decoding the FIFO data frame 
which can be unaligned. It is also used for storing data in other modules, but 
__packed attribute should not change anything here.

Thanks,
JB



From: linux-iio-ow...@vger.kernel.org  on 
behalf of Jean-Baptiste Maneyrol 
Sent: Tuesday, June 2, 2020 14:57
To: Jonathan Cameron 
Cc: robh...@kernel.org ; r...@kernel.org ; 
mchehab+hua...@kernel.org ; da...@davemloft.net 
; gre...@linuxfoundation.org ; 
linux-...@vger.kernel.org ; 
devicet...@vger.kernel.org ; 
linux-kernel@vger.kernel.org 
Subject: --[[SPOOF or PHISHING]]--Re: [PATCH v2 09/12] iio: imu: inv_icm42600: 
add buffer support in iio devices 
 
 CAUTION: This email originated from outside of the organization. Please make 
sure the sender is who they say they are and do not click links or open 
attachments unless you recognize the sender and know the content is safe.

Hi Jonathan,

I agree that this multiplexed watermark computation value is anything except 
simple and clear to understand.
I will add more documentation about it. And it also triggered a kbuild robot 
issue, because it is using 64 bits modulo without using math64 macros.

For buffer preenable/postenable/..., the sequence I am using currently is:
- preenable -> turn chip on (pm_runtime_get)
- update_scan_mode -> set FIFO en bits configuration (which sensor data is 
going into the fifo)
- hwfifo_watermark -> compute and set watermark value
- postenable -> turn FIFO on (and multiplexed with a FIFO on counter since used 
by accel & gyro)
- predisable -> turn FIFO off (multiplexed with counter)
- postdisable -> turn chip off (pm_runtime_put)

This setting is working well. Good to note that if there is an error when 
enabling the buffer, postdisable will always get called after preenable. So it 
ensures pm_runtime reference counter to be always OK.

Another way would be to only store configuration in internal state with 
update_scan_mode and hwfifo_watermark, and do everything in 
postenable/predisable. This is a possibility, but makes things a little more 
complex.

For hwfifo flush, this is an interesting feature when there is a need to have 
data immediately. Or when there is a need to do a clean change of 
configuration. In Android systems, Android framework is mainly using FIFO flush 
to change the sensor configuration (ODR, watermark) in a clean way. For our 
case with the FIFO interleaved this is a not an issue. If there are samples 
from the 2 sensors, it means the 2 buffers are enabled. And if data is coming 
to the iio buffer sooner than expected, that should not be a problem. The 
limitation I see when the 2 sensors are runnings, is that we will return less 
data than should have been possible. I limit FIFO reading to the provided n 
bytes, so we could read less than n samples of 1 sensor.

Something I have in mind, that would be really interesting to be able to 
set/change watermark value when the buffer is enabled. Otherwise, we are always 
loosing events by turning sensor off when we want to change the value. Is there 
any limitation to work this way, or should it be possible to implement this 
feature in the future ?

Thanks,
JB


From: Jonathan Cameron 
Sent: Sunday, May 31, 2020 14:56
To: Jean-Baptiste Maneyrol 
Cc: robh...@kernel.org ; r...@kernel.org ; 
mchehab+hua...@kernel.org ; da...@davemloft.net 
; gre...@linuxfoundation.org ; 
linux-...@vger.kernel.org ; 
devicet...@vger.kernel.org ; 
linux-kernel@vger.kernel.org 
Subject: Re: [PATCH v2 09/12] iio: imu: inv_icm42600: add buffer support in iio 
devices 
 
 CAUTION: This email originated from outside of the organization. Please make 
sure the sender is who they say they are and do not click links or open 
attachments unless you recognize the sender and know the content is safe.

On Wed, 27 May 2020 20:57:08 +0200
Jean-Baptiste Maneyrol  wrote:

> Add all FIFO parsing and reading functions. Add accel and gyro
> kfifo buffer and FIFO data parsing. Use device interrupt for
> reading data FIFO and launching accel and gyro parsing.
> 
> Support hwfifo watermark by multiplexing gyro and accel settings.
> Support hwfifo flush.

Both of these are complex given the interactions of the two sensors
types and to be honest I couldn't figure out exactly what the intent was.
Needs more docs!

Thanks,

Jonathan

> 
> Signed-off-by: Jean-Baptiste Maneyrol 
> ---
>  drivers/iio/imu/inv_icm42600/Kconfig  |   1 +
>  drivers/iio/imu/inv_icm42600/Makefile |   1 +
>  drivers/iio/imu/inv_icm42600/inv_icm42600.h   |   8 +
>  .../iio/imu/inv_icm42600/inv_icm42600_accel.c | 160 -
>  .../imu/inv_icm42600/inv_icm42600_buffer.c    | 555 ++
>  .../imu/inv_icm42600/inv_icm42600_buffer.h    |  98 
>

Re: [PATCH v2 09/12] iio: imu: inv_icm42600: add buffer support in iio devices

2020-06-02 Thread Jean-Baptiste Maneyrol
Hi Jonathan,

I agree that this multiplexed watermark computation value is anything except 
simple and clear to understand.
I will add more documentation about it. And it also triggered a kbuild robot 
issue, because it is using 64 bits modulo without using math64 macros.

For buffer preenable/postenable/..., the sequence I am using currently is:
- preenable -> turn chip on (pm_runtime_get)
- update_scan_mode -> set FIFO en bits configuration (which sensor data is 
going into the fifo)
- hwfifo_watermark -> compute and set watermark value
- postenable -> turn FIFO on (and multiplexed with a FIFO on counter since used 
by accel & gyro)
- predisable -> turn FIFO off (multiplexed with counter)
- postdisable -> turn chip off (pm_runtime_put)

This setting is working well. Good to note that if there is an error when 
enabling the buffer, postdisable will always get called after preenable. So it 
ensures pm_runtime reference counter to be always OK.

Another way would be to only store configuration in internal state with 
update_scan_mode and hwfifo_watermark, and do everything in 
postenable/predisable. This is a possibility, but makes things a little more 
complex.

For hwfifo flush, this is an interesting feature when there is a need to have 
data immediately. Or when there is a need to do a clean change of 
configuration. In Android systems, Android framework is mainly using FIFO flush 
to change the sensor configuration (ODR, watermark) in a clean way. For our 
case with the FIFO interleaved this is a not an issue. If there are samples 
from the 2 sensors, it means the 2 buffers are enabled. And if data is coming 
to the iio buffer sooner than expected, that should not be a problem. The 
limitation I see when the 2 sensors are runnings, is that we will return less 
data than should have been possible. I limit FIFO reading to the provided n 
bytes, so we could read less than n samples of 1 sensor.

Something I have in mind, that would be really interesting to be able to 
set/change watermark value when the buffer is enabled. Otherwise, we are always 
loosing events by turning sensor off when we want to change the value. Is there 
any limitation to work this way, or should it be possible to implement this 
feature in the future ?

Thanks,
JB


From: Jonathan Cameron 
Sent: Sunday, May 31, 2020 14:56
To: Jean-Baptiste Maneyrol 
Cc: robh...@kernel.org ; r...@kernel.org ; 
mchehab+hua...@kernel.org ; da...@davemloft.net 
; gre...@linuxfoundation.org ; 
linux-...@vger.kernel.org ; 
devicet...@vger.kernel.org ; 
linux-kernel@vger.kernel.org 
Subject: Re: [PATCH v2 09/12] iio: imu: inv_icm42600: add buffer support in iio 
devices 
 
 CAUTION: This email originated from outside of the organization. Please make 
sure the sender is who they say they are and do not click links or open 
attachments unless you recognize the sender and know the content is safe.

On Wed, 27 May 2020 20:57:08 +0200
Jean-Baptiste Maneyrol  wrote:

> Add all FIFO parsing and reading functions. Add accel and gyro
> kfifo buffer and FIFO data parsing. Use device interrupt for
> reading data FIFO and launching accel and gyro parsing.
> 
> Support hwfifo watermark by multiplexing gyro and accel settings.
> Support hwfifo flush.

Both of these are complex given the interactions of the two sensors
types and to be honest I couldn't figure out exactly what the intent was.
Needs more docs!

Thanks,

Jonathan

> 
> Signed-off-by: Jean-Baptiste Maneyrol 
> ---
>  drivers/iio/imu/inv_icm42600/Kconfig  |   1 +
>  drivers/iio/imu/inv_icm42600/Makefile |   1 +
>  drivers/iio/imu/inv_icm42600/inv_icm42600.h   |   8 +
>  .../iio/imu/inv_icm42600/inv_icm42600_accel.c | 160 -
>  .../imu/inv_icm42600/inv_icm42600_buffer.c    | 555 ++
>  .../imu/inv_icm42600/inv_icm42600_buffer.h    |  98 
>  .../iio/imu/inv_icm42600/inv_icm42600_core.c  |  30 +
>  .../iio/imu/inv_icm42600/inv_icm42600_gyro.c  | 160 -
>  8 files changed, 1011 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/iio/imu/inv_icm42600/inv_icm42600_buffer.c
>  create mode 100644 drivers/iio/imu/inv_icm42600/inv_icm42600_buffer.h
> 
> diff --git a/drivers/iio/imu/inv_icm42600/Kconfig 
> b/drivers/iio/imu/inv_icm42600/Kconfig
> index 22390a72f0a3..50cbcfcb6cf1 100644
> --- a/drivers/iio/imu/inv_icm42600/Kconfig
> +++ b/drivers/iio/imu/inv_icm42600/Kconfig
> @@ -2,6 +2,7 @@
>  
>  config INV_ICM42600
>    tristate
> + select IIO_BUFFER
>  
>  config INV_ICM42600_I2C
>    tristate "InvenSense ICM-426xx I2C driver"
> diff --git a/drivers/iio/imu/inv_icm42600/Makefile 
> b/drivers/iio/imu/inv_icm42600/Makefile
> index 48965824f00c..0f49f6df3647 100644
> --- a/drivers/iio/imu/inv_icm42600/Makefile
> +++ b/drivers/iio/imu/inv_icm42600/Makefile
> @@ -5,6 +5,7 @@ inv-icm42600-y += inv_icm42

Re: [PATCH v2 09/12] iio: imu: inv_icm42600: add buffer support in iio devices

2020-05-31 Thread Jonathan Cameron
On Wed, 27 May 2020 20:57:08 +0200
Jean-Baptiste Maneyrol  wrote:

> Add all FIFO parsing and reading functions. Add accel and gyro
> kfifo buffer and FIFO data parsing. Use device interrupt for
> reading data FIFO and launching accel and gyro parsing.
> 
> Support hwfifo watermark by multiplexing gyro and accel settings.
> Support hwfifo flush.

Both of these are complex given the interactions of the two sensors
types and to be honest I couldn't figure out exactly what the intent was.
Needs more docs!

Thanks,

Jonathan

> 
> Signed-off-by: Jean-Baptiste Maneyrol 
> ---
>  drivers/iio/imu/inv_icm42600/Kconfig  |   1 +
>  drivers/iio/imu/inv_icm42600/Makefile |   1 +
>  drivers/iio/imu/inv_icm42600/inv_icm42600.h   |   8 +
>  .../iio/imu/inv_icm42600/inv_icm42600_accel.c | 160 -
>  .../imu/inv_icm42600/inv_icm42600_buffer.c| 555 ++
>  .../imu/inv_icm42600/inv_icm42600_buffer.h|  98 
>  .../iio/imu/inv_icm42600/inv_icm42600_core.c  |  30 +
>  .../iio/imu/inv_icm42600/inv_icm42600_gyro.c  | 160 -
>  8 files changed, 1011 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/iio/imu/inv_icm42600/inv_icm42600_buffer.c
>  create mode 100644 drivers/iio/imu/inv_icm42600/inv_icm42600_buffer.h
> 
> diff --git a/drivers/iio/imu/inv_icm42600/Kconfig 
> b/drivers/iio/imu/inv_icm42600/Kconfig
> index 22390a72f0a3..50cbcfcb6cf1 100644
> --- a/drivers/iio/imu/inv_icm42600/Kconfig
> +++ b/drivers/iio/imu/inv_icm42600/Kconfig
> @@ -2,6 +2,7 @@
>  
>  config INV_ICM42600
>   tristate
> + select IIO_BUFFER
>  
>  config INV_ICM42600_I2C
>   tristate "InvenSense ICM-426xx I2C driver"
> diff --git a/drivers/iio/imu/inv_icm42600/Makefile 
> b/drivers/iio/imu/inv_icm42600/Makefile
> index 48965824f00c..0f49f6df3647 100644
> --- a/drivers/iio/imu/inv_icm42600/Makefile
> +++ b/drivers/iio/imu/inv_icm42600/Makefile
> @@ -5,6 +5,7 @@ inv-icm42600-y += inv_icm42600_core.o
>  inv-icm42600-y += inv_icm42600_gyro.o
>  inv-icm42600-y += inv_icm42600_accel.o
>  inv-icm42600-y += inv_icm42600_temp.o
> +inv-icm42600-y += inv_icm42600_buffer.o
>  
>  obj-$(CONFIG_INV_ICM42600_I2C) += inv-icm42600-i2c.o
>  inv-icm42600-i2c-y += inv_icm42600_i2c.o
> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600.h 
> b/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> index 43749f56426c..4d5811562a61 100644
> --- a/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> @@ -14,6 +14,8 @@
>  #include 
>  #include 
>  
> +#include "inv_icm42600_buffer.h"
> +
>  enum inv_icm42600_chip {
>   INV_CHIP_ICM42600,
>   INV_CHIP_ICM42602,
> @@ -123,6 +125,7 @@ struct inv_icm42600_suspended {
>   *  @indio_gyro: gyroscope IIO device.
>   *  @indio_accel:accelerometer IIO device.
>   *  @buffer: data transfer buffer aligned for DMA.
> + *  @fifo:   FIFO management structure.
>   */
>  struct inv_icm42600_state {
>   struct mutex lock;
> @@ -137,6 +140,7 @@ struct inv_icm42600_state {
>   struct iio_dev *indio_gyro;
>   struct iio_dev *indio_accel;
>   uint8_t buffer[2] cacheline_aligned;
> + struct inv_icm42600_fifo fifo;
>  };
>  
>  /* Virtual register addresses: @bank on MSB (4 upper bits), @address on LSB 
> */
> @@ -377,6 +381,10 @@ int inv_icm42600_core_probe(struct regmap *regmap, int 
> chip, int irq,
>  
>  int inv_icm42600_gyro_init(struct inv_icm42600_state *st);
>  
> +int inv_icm42600_gyro_parse_fifo(struct iio_dev *indio_dev);
> +
>  int inv_icm42600_accel_init(struct inv_icm42600_state *st);
>  
> +int inv_icm42600_accel_parse_fifo(struct iio_dev *indio_dev);
> +
>  #endif
> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c 
> b/drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c
> index 6a615d7ffb24..c73ce204efc6 100644
> --- a/drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c
> +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c
> @@ -11,9 +11,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include "inv_icm42600.h"
>  #include "inv_icm42600_temp.h"
> +#include "inv_icm42600_buffer.h"
>  
>  #define INV_ICM42600_ACCEL_CHAN(_modifier, _index, _ext_info)
> \
>   {   \
> @@ -64,6 +67,76 @@ static const struct iio_chan_spec 
> inv_icm42600_accel_channels[] = {
>   INV_ICM42600_TEMP_CHAN(INV_ICM42600_ACCEL_SCAN_TEMP),
>  };
>  
> +/* IIO buffer data: 8 bytes */
> +struct inv_icm42600_accel_buffer {
> + struct inv_icm42600_fifo_sensor_data accel;
> + int8_t temp;
> + uint8_t padding;
> +};
> +
> +#define INV_ICM42600_SCAN_MASK_ACCEL_3AXIS   \
> + (BIT(INV_ICM42600_ACCEL_SCAN_X) |   \
> + BIT(INV_ICM42600_ACCEL_SCAN_Y) |\
> + BIT(INV_ICM42600_ACCEL_SCAN_Z))
> +
> +#define INV_ICM42600_SCAN_MASK_TEMP  BIT(INV_ICM42600_ACCEL_SCAN_TEMP)
> +
> +static const 

Re: [PATCH v2 09/12] iio: imu: inv_icm42600: add buffer support in iio devices

2020-05-30 Thread kbuild test robot
Hi Jean-Baptiste,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on iio/togreg]
[also build test ERROR on robh/for-next linus/master v5.7-rc7 next-20200529]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Jean-Baptiste-Maneyrol/iio-imu-new-inv_icm42600-driver/20200528-030632
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
config: i386-randconfig-c001-20200529 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>, old ones prefixed by <<):

ld: drivers/iio/imu/inv_icm42600/inv_icm42600_buffer.o: in function 
`inv_icm42600_buffer_update_watermark':
drivers/iio/imu/inv_icm42600/inv_icm42600_buffer.c:215: undefined reference to 
`__moddi3'
>> ld: drivers/iio/imu/inv_icm42600/inv_icm42600_buffer.c:212: undefined 
>> reference to `__moddi3'

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip


[PATCH v2 09/12] iio: imu: inv_icm42600: add buffer support in iio devices

2020-05-27 Thread Jean-Baptiste Maneyrol
Add all FIFO parsing and reading functions. Add accel and gyro
kfifo buffer and FIFO data parsing. Use device interrupt for
reading data FIFO and launching accel and gyro parsing.

Support hwfifo watermark by multiplexing gyro and accel settings.
Support hwfifo flush.

Signed-off-by: Jean-Baptiste Maneyrol 
---
 drivers/iio/imu/inv_icm42600/Kconfig  |   1 +
 drivers/iio/imu/inv_icm42600/Makefile |   1 +
 drivers/iio/imu/inv_icm42600/inv_icm42600.h   |   8 +
 .../iio/imu/inv_icm42600/inv_icm42600_accel.c | 160 -
 .../imu/inv_icm42600/inv_icm42600_buffer.c| 555 ++
 .../imu/inv_icm42600/inv_icm42600_buffer.h|  98 
 .../iio/imu/inv_icm42600/inv_icm42600_core.c  |  30 +
 .../iio/imu/inv_icm42600/inv_icm42600_gyro.c  | 160 -
 8 files changed, 1011 insertions(+), 2 deletions(-)
 create mode 100644 drivers/iio/imu/inv_icm42600/inv_icm42600_buffer.c
 create mode 100644 drivers/iio/imu/inv_icm42600/inv_icm42600_buffer.h

diff --git a/drivers/iio/imu/inv_icm42600/Kconfig 
b/drivers/iio/imu/inv_icm42600/Kconfig
index 22390a72f0a3..50cbcfcb6cf1 100644
--- a/drivers/iio/imu/inv_icm42600/Kconfig
+++ b/drivers/iio/imu/inv_icm42600/Kconfig
@@ -2,6 +2,7 @@
 
 config INV_ICM42600
tristate
+   select IIO_BUFFER
 
 config INV_ICM42600_I2C
tristate "InvenSense ICM-426xx I2C driver"
diff --git a/drivers/iio/imu/inv_icm42600/Makefile 
b/drivers/iio/imu/inv_icm42600/Makefile
index 48965824f00c..0f49f6df3647 100644
--- a/drivers/iio/imu/inv_icm42600/Makefile
+++ b/drivers/iio/imu/inv_icm42600/Makefile
@@ -5,6 +5,7 @@ inv-icm42600-y += inv_icm42600_core.o
 inv-icm42600-y += inv_icm42600_gyro.o
 inv-icm42600-y += inv_icm42600_accel.o
 inv-icm42600-y += inv_icm42600_temp.o
+inv-icm42600-y += inv_icm42600_buffer.o
 
 obj-$(CONFIG_INV_ICM42600_I2C) += inv-icm42600-i2c.o
 inv-icm42600-i2c-y += inv_icm42600_i2c.o
diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600.h 
b/drivers/iio/imu/inv_icm42600/inv_icm42600.h
index 43749f56426c..4d5811562a61 100644
--- a/drivers/iio/imu/inv_icm42600/inv_icm42600.h
+++ b/drivers/iio/imu/inv_icm42600/inv_icm42600.h
@@ -14,6 +14,8 @@
 #include 
 #include 
 
+#include "inv_icm42600_buffer.h"
+
 enum inv_icm42600_chip {
INV_CHIP_ICM42600,
INV_CHIP_ICM42602,
@@ -123,6 +125,7 @@ struct inv_icm42600_suspended {
  *  @indio_gyro:   gyroscope IIO device.
  *  @indio_accel:  accelerometer IIO device.
  *  @buffer:   data transfer buffer aligned for DMA.
+ *  @fifo: FIFO management structure.
  */
 struct inv_icm42600_state {
struct mutex lock;
@@ -137,6 +140,7 @@ struct inv_icm42600_state {
struct iio_dev *indio_gyro;
struct iio_dev *indio_accel;
uint8_t buffer[2] cacheline_aligned;
+   struct inv_icm42600_fifo fifo;
 };
 
 /* Virtual register addresses: @bank on MSB (4 upper bits), @address on LSB */
@@ -377,6 +381,10 @@ int inv_icm42600_core_probe(struct regmap *regmap, int 
chip, int irq,
 
 int inv_icm42600_gyro_init(struct inv_icm42600_state *st);
 
+int inv_icm42600_gyro_parse_fifo(struct iio_dev *indio_dev);
+
 int inv_icm42600_accel_init(struct inv_icm42600_state *st);
 
+int inv_icm42600_accel_parse_fifo(struct iio_dev *indio_dev);
+
 #endif
diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c 
b/drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c
index 6a615d7ffb24..c73ce204efc6 100644
--- a/drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c
+++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c
@@ -11,9 +11,12 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "inv_icm42600.h"
 #include "inv_icm42600_temp.h"
+#include "inv_icm42600_buffer.h"
 
 #define INV_ICM42600_ACCEL_CHAN(_modifier, _index, _ext_info)  \
{   \
@@ -64,6 +67,76 @@ static const struct iio_chan_spec 
inv_icm42600_accel_channels[] = {
INV_ICM42600_TEMP_CHAN(INV_ICM42600_ACCEL_SCAN_TEMP),
 };
 
+/* IIO buffer data: 8 bytes */
+struct inv_icm42600_accel_buffer {
+   struct inv_icm42600_fifo_sensor_data accel;
+   int8_t temp;
+   uint8_t padding;
+};
+
+#define INV_ICM42600_SCAN_MASK_ACCEL_3AXIS \
+   (BIT(INV_ICM42600_ACCEL_SCAN_X) |   \
+   BIT(INV_ICM42600_ACCEL_SCAN_Y) |\
+   BIT(INV_ICM42600_ACCEL_SCAN_Z))
+
+#define INV_ICM42600_SCAN_MASK_TEMPBIT(INV_ICM42600_ACCEL_SCAN_TEMP)
+
+static const unsigned long inv_icm42600_accel_scan_masks[] = {
+   /* 3-axis accel + temperature */
+   INV_ICM42600_SCAN_MASK_ACCEL_3AXIS | INV_ICM42600_SCAN_MASK_TEMP,
+   0,
+};
+
+/* enable accelerometer sensor and FIFO write */
+static int inv_icm42600_accel_update_scan_mode(struct iio_dev *indio_dev,
+  const unsigned long *scan_mask)
+{
+   struct inv_icm42600_state *st = iio_device_get_drvdata(indio_dev);
+