drivers: sensor: adxl367: Added RTIO stream

[vladislav-pejic]

Updated ADXL367 driver with RTIO stream functionality. RTIO stream is using both FIFO threshold and FIFO full triggers. Together with RTIO stream, RTIO async read is also implemented. Supported FIFO_CHANNEL configurations:

• XYZ
• X
• Y
• Z
• XYZT
• XT
• YT
• ZT
  Configurations with external ADC are currently not supported.

Signed-off-by: Vladislav Pejic [email protected]

[teburd]

Likely this should be in the block ifdefs below, where STREAM is an option for trigger handling.

Unclear how this would operate with both streaming and a work/thread trigger being called out. Likely problematic?

[vladislav-pejic]

They are processing different IRQs (stream is expecting FIFO full or FIFO watermark and trigger is expecting Data ready or Activity threshold) so if both are enabled it should work ok. If for example, Data ready is triggered, stream code would call RTIO to read STATUS register (when callback is triggered it would determine that IRQ is not for the stream and do nothing) and adxl367_thread_cb would do the processing of that IRQ. Similar thing would happen when FIFO full would trigger (stream would do the processing and adxl367_thread_cb would do nothing). This is just my opinion. I could be wrong.

[ttmut]

What platform are you testing this on? I am getting a usage fault with MAX32690 somewhere in spi_max32.c when using streaming mode. Trigger mode works fine.

My build command is:

foo@bar:~$ west build -p -b max32690fthr/max32690/m4 samples/sensor/accel_polling -- -DCONFIG_ADXL367_STREAM=y -DCONFIG_SENSOR_ASYNC_API=y -DCONFIG_SPI_RTIO=y

Devicetree modification:

feather_spi: &spi0 {
	status = "okay";
	pinctrl-0 = <&spi0b_mosi_p2_28 &spi0b_miso_p2_27 &spi0b_sck_p2_29 &spi0b_ss1_p2_26>;
	pinctrl-names = "default";

	adxl367: adxl367@1 {
		compatible = "adi,adxl367";
		reg = <0x1>;
		int1-gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
		spi-max-frequency = <1000000>;
		odr = <0>;
		status = "okay";
	};
};

[vladislav-pejic]

What platform are you testing this on? I am getting a usage fault with MAX32690 somewhere in spi_max32.c when using streaming mode. Trigger mode works fine.

My build command is:

foo@bar:~$ west build -p -b max32690fthr/max32690/m4 samples/sensor/accel_polling -- -DCONFIG_ADXL367_STREAM=y -DCONFIG_SENSOR_ASYNC_API=y -DCONFIG_SPI_RTIO=y

Devicetree modification:

feather_spi: &spi0 {
	status = "okay";
	pinctrl-0 = <&spi0b_mosi_p2_28 &spi0b_miso_p2_27 &spi0b_sck_p2_29 &spi0b_ss1_p2_26>;
	pinctrl-names = "default";

	adxl367: adxl367@1 {
		compatible = "adi,adxl367";
		reg = <0x1>;
		int1-gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
		spi-max-frequency = <1000000>;
		odr = <0>;
		status = "okay";
	};
};

I am using apard32690 (also MAX32690). Regarding build command you do not need DCONFIG_ADXL367_STREAM. It will be set automatically with Kconfig.

There are couple of bugs in the original part of a driver. One of them is causing exception when SPI driver with RTIO is used. I made another PR with bug fixes so please check #80617.

[ttmut]

What platform are you testing this on? I am getting a usage fault with MAX32690 somewhere in spi_max32.c when using streaming mode. Trigger mode works fine.
My build command is:

foo@bar:~$ west build -p -b max32690fthr/max32690/m4 samples/sensor/accel_polling -- -DCONFIG_ADXL367_STREAM=y -DCONFIG_SENSOR_ASYNC_API=y -DCONFIG_SPI_RTIO=y

Devicetree modification:

feather_spi: &spi0 {
	status = "okay";
	pinctrl-0 = <&spi0b_mosi_p2_28 &spi0b_miso_p2_27 &spi0b_sck_p2_29 &spi0b_ss1_p2_26>;
	pinctrl-names = "default";

	adxl367: adxl367@1 {
		compatible = "adi,adxl367";
		reg = <0x1>;
		int1-gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
		spi-max-frequency = <1000000>;
		odr = <0>;
		status = "okay";
	};
};

I am using apard32690 (also MAX32690). Regarding build command you do not need DCONFIG_ADXL367_STREAM. It will be set automatically with Kconfig.

There are couple of bugs in the original part of a driver. One of them is causing exception when SPI driver with RTIO is used. I made another PR with bug fixes so please check #80617.

I will check that out, thanks.

[vladislav-pejic]

@teburd Can you please take a look at latest changes?

[teburd]

Would recommend using rtio_sqe_prep_callback_no_cqe for all of these to avoid creating a completion that you don't actually care about, but not a blocker if the driver is working