drivers/imu: add LSM6DSO gyroscope driver#1511
Open
dbortz wants to merge 1 commit into
Open
Conversation
gmarull
requested changes
Jun 15, 2026
gmarull
left a comment
Member
There was a problem hiding this comment.
split changes into smaller PRs, eg first driver, then service, etc.
Refactor the LSM6DSO chip management (init, I2C, and the shared hardware FIFO) out of the accelerometer driver into a small lsm6dso_core, then add a gyroscope driver (drivers/gyro.h) implemented on top of it. The accelerometer and gyroscope halves can now be compiled independently (CONFIG_ACCEL_LSM6DSO / CONFIG_GYRO_LSM6DSO); FIFO records from the two sensors are interleaved and dispatched by tag. The gyroscope is FIFO-batched and timer-polled (not all boards route an LSM6DSO interrupt pin) and is kept powered down until samples are requested. This also resolves the existing ULP-mode TODO: the accelerometer leaves ultra-low-power mode while the gyroscope is active, per LSM6DSO datasheet section 6.2.1. Not enabled on any board yet — the gyro_manager service that consumes this driver, and the board enablement, follow in a separate change. Signed-off-by: Dave Bortz <dbortz@gmail.com> Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Author
|
Thanks for the review! Split as suggested — this PR is now just the driver (the |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Splitting the original combined PR into smaller, layered PRs as requested (#1510 has the full context/RFC). This is the first of three:
gyro_managerservice + board enablementgyro_service+ SDK export (PBL_GYRO)I'll open each subsequent PR once the previous lands.
What this PR does
lsm6dso_core, so the accel and gyro halves can be compiled independently (CONFIG_ACCEL_LSM6DSO/CONFIG_GYRO_LSM6DSO). FIFO records from the two sensors are interleaved and dispatched by tag.drivers/gyro.hinterface and its LSM6DSO implementation (lsm6dso_gyro.c). The gyro is FIFO-batched and timer-polled (not all boards route an LSM6DSO interrupt pin) and stays powered down until samples are requested.lsm6dso.c: the accelerometer now leaves ultra-low-power mode while the gyro is active (datasheet §6.2.1).On building / coverage
The driver isn't enabled on any board here — the service that consumes it (and the board enablement that links the two) is the next PR, so they can be reviewed separately as you asked. Concretely:
lsm6dso_corerefactor is exercised in CI via the existing accelerometer onasterix(no behavior change).lsm6dso_gyro.cand the gyro-specific#if CONFIG_GYRO_LSM6DSOpaths compile once the service PR enables a board — this is the usual driver-then-enable split. I've verified the full 3-PR series builds clean onobelixandasterix.If you'd rather have the driver and service land together (so every line is exercised in this PR's own CI), I'm happy to combine those two — just say the word.
🤖 Generated with Claude Code