sensor: icm45686: Add basic IMU functionality

[ubieda]

Description

This PR introduces support for TDK's ICM45686 IMU sensor, including:

• Fetch/Get API.
• Read/Decode API.
• Configuration through device-tree properties.
• Bus support for SPI (although easily extensible to others as
  based on RTIO).
• Trigger for SENSOR_TRIG_DATA_READY.

Note

Depends on:

• RTIO fixes:
  • spi_rtio: fix Transaction OPs for Default SPI RTIO #85894
  • rtio: workq: Default workqueue to two threads with SPI/I2C/I3C #86169
• CI Failure fixes:
  • sensor: adxl367 and adxl372: fix CI build-failure with streaming mode #85966
  • sensor: lsm6ds: fix: Do not enable Streaming for buses with no RTIO support #85972

Testing

• Fetch/Get API tested with accel_polling sample.
• Read/Decode API tested with sensor_shell sample.
• Trigger with sensor_shell sample.

[ubieda]

Marked as DNM until in-flight PRs this depends upon are merged.

[afontaine-invn]

Hi @MaureenHelm , Hi @ubieda , Hi @kartben ,
You asked from TDK that we put in place a HAL to support our sensors. We are currently working at supporting this ICM-45686 device. I would appreciate to be notified by such PR. This driver does not support our drivers from the hal. I don't get it, it's not inline with what you asked from us. Why do you merge such drivers?

FYI @sriccardi-invn @JHKim8212

[ubieda]

Hi @afontaine-invn,

I'm adding some comments here:

• I've developed and submitted this driver as a community contribution, given I had a need for it to work with the Streaming API (Sensor Model v2).
• WRT the conflict of stepping on each others' toes: Being completely transparent, I was not aware you were working on it. Please note this PR was open about 3-weeks from now; but even so, I still don't see how I or the other Sensor collaborators/maintainers would have known so, given I still don't see an upstream PR filed to support this sensor functionality.
• As far as not being on the loop when the PR was submitted:
  1. The contribution followed its natural process. The automatic reviewers are Collaborators and Maintainers of the different areas. If you want to be notified on every PR filed for any TDK driver sensor driver, I encourage you to follow the process and nominate yourselves as collaborators/maintainers for your sensors.
  2. This driver was brought up on at least a Sensor WG meeting, where we discussed details on Triggers vs Streaming. I encourage you to join us these meetings as well to stay in the loop of what's going on with the WG and how we could collaborate each other.
• WRT Why merging such drivers, I really don't know what to say other than the Zephyr Project being open-source: individuals contribute source code and it follows the same process as companies, members and organization contributing code to support their products. I don't see what is wrong with that.
• As far as TDK being able to support their sensors: I personally have no preference of this driver using or not using a HAL, as long as it still supports my use-case: Streaming mode with Watermark interrupts on native RTIO support (just like the already existing ICM42688). Feel free to submit a PR with your tweaks and it will go through the proper review process.

@kartben @MaureenHelm please chime in if there's anything else to add or if you think otherwise.

[teburd]

I'd welcome you to take maintainership of the TDK drivers, I only maintain them today because no one else has volunteered to do so.

[kartben]

Great summary, @ubieda, thank you! The obvious thing that comes to mind is indeed that maybe TDK wants to step up to become maintainers of their sensors?
This will help ensure you folks are in the loop, and will make you more directly responsible for handling community contributions (which may or may not use your HAL!)
Putting thumbs down emojis when/if more of such contributions come will likely not be the best way to move forward though, as I'm sure you can imagine :) (cc @gjabouley-invn)

[afontaine-invn]

Thanks for your reply. For sure we would like to be maintainers of TDK drivers. What is the process to being so?

[teburd]

Thanks for your reply. For sure we would like to be maintainers of TDK drivers. What is the process to being so?

Send a PR with your desired maintainer/collaborator status changes to the MAINTAINERS file in this tree.

See for example:
https://github.com/zephyrproject-rtos/zephyr/blob/main/MAINTAINERS.yml#L4445

And an example PR:
#85528

I'll reiterate a few points here..

Please do refrain from leaving thumbs down emojis. This does not help anyone.

Please do join the working group and the bi-weekly meeting, we're a friendly bunch I promise. I like that you and TDK are contributing to Zephyr. I very much doubt anyone views this as a negative. That said being involved in driver reviews and working group discussions is important if you want to have a good understanding and a voice in the direction sensors in Zephyr are going.

Speaking of reviews, if you add your name to the collaborators list here you will see all sensor driver pull requests, and quality reviews are very much appreciated https://github.com/zephyrproject-rtos/zephyr/blob/main/MAINTAINERS.yml#L2047

[gjabouley-invn]

Thanks all for clarifying this point
we though initially that during the hal_tdk creation story we had expressed our intention to step-up to maintain/extend TDK sensors support in Zephyr ecosystem (#71374 (comment))
And seeing such PR (and some others) related to recent TDK sensors merged without being informed created some misunderstanding as it is also being finalized internally...
But turns out we are not yet properly identified as maintainers for TDK sensors, only for hal_tdk.
As recommended, we will create the PR to solved this gap and ensure we can provide quality feedbacks to community, also avoiding spread of alternate implementation of our drivers when it can be addressed as part of the HAL.

note i also removed my initial thumbs down reaction, and thumbs up (I definitely prefer to use this one btw) your comment @teburd

[afontaine-invn]

Thanks for your explanation @teburd ,

I opened #87191.
And we added the sensor WG meeting in our agenda.

Regarding your proposition, we rather start with only our sensor maintainership and see what it is implied before committed in the full sensor review.