Hi all,
this series adds support for firmware/device-tree described constraints
on sequential register reads.
The motivating use case are camera modules from Vision Components.
These modules may integrate image sensors that normally support
incrementing multi-register reads, while the MCU (which sits basically
"between" the I2C host and the camera sensors) breaks them. In such
cases, single-register reads work, but sequential/bulk register reads do
not.
This limitation is therefore not a property of the sensor silicon
itself, but of the hardware module/integration in which the device is
used. As a result, it cannot be identified from the deivce driver and
handling it in each affected device driver does not scale well.
To address this, the series introduces a common firmware property
(no-sequential-read) describing hardware integrations where reading
multiple consecutive registers in a single operation is not reliable.
regmap then consumes that property and maps it to its existing
use_single_read configuration. This keeps the hardware constraint
described in firmware/device-tree while applying it in the layer that
already owns the register read transfer policy.
The initial discussion that motivated this approach can be found here:
https://lore.kernel.org/lkml/20260721151614.GN50424@killaraus.ideasonboard.com/
Feedback is especially welcome on the property naming, the placement of
the common binding schema, and if regmap is the best place to implment this.
Thanks,
Richard
Link: https://lore.kernel.org/lkml/20260721151614.GN50424@killaraus.ideasonboard.com/
Signed-off-by: Richard Leitner <richard.leitner@linux.dev>
---
Richard Leitner (2):
dt-bindings: regmap: add common schema for no-sequential-read
regmap: implement no-sequential-read firmware property
.../devicetree/bindings/regmap/common.yaml | 26 ++++++++++++++++++++++
drivers/base/regmap/regmap.c | 14 +++++++++++-
2 files changed, 39 insertions(+), 1 deletion(-)
---
base-commit: 248951ddc14de84de3910f9b13f51491a8cd91df
change-id: 20260722-regmap-single-read-a2e95070cd66
Best regards,
--
Richard Leitner <richard.leitner@linux.dev>