Re: [PATCH v8 6/7] iio: imu: inv_icm42607: Implement MREGx register access

[Kanak Shilledar]

Hi Jonathan,
On Sat, 2026-11-07 at 03:48 +0000, Jonathan Cameron wrote:
> On Thu, 5 Nov 2026 16:48:54 +0100
> Kanak Shilledar <kanak.shilledar@xxxxxxxx> wrote:
> 
> > The device supports indirect register access to different banks. A
> > specific routine needs to be followed when accessing the registers
> > in
> > another bank as documented in the datasheet (section 13). This is
> > required for accessing registers configured via the user and
> > implementing buffer support. The implementation is inspired from
> > the
> > icm45600 driver.
> > 
> > The banks are defined based on their initial bank access code which
> > are
> > written to the BLK_SEL_* regs. However, there is a variation for
> > MREG1
> > as User Bank 0 and MREG1 both share the same 0x00, so User Bank 1
> > has
> > 0x00 and MREG1 has 0x01. When MREG1 register is accessed, then
> > BLK_SEL_*
> > is written with 0x00 instead of 0x01. All the register access goes
> > through the 16 bit virtual regmap layered on top of the 8bit bus
> > regmap.
> > Bank id in the upper byte and the register address in the lower
> > byte.
> > Bank 0 accesses are forwarded to the bus regmap with the bank field
> > stripped, while MREG accesses are forwarded to bank switching
> > sequence.
> > 
> > Due to the specific bank switching routine, it is not possible to
> > use
> > regmap-ranges. Only User Bank 0 supports bulk read/writes whereas
> > other
> > banks can only be accessed serially. Each time some data in the
> > other
> > bank needs to be accessed, it should go through the complete bank
> > switching sequence.
> Does turning off bulk accesses for user bank 0 have much impact on
> performance
> of existing features? 

No, after setting use_single_write to true, doesn't have much
performance impact as the driver doesn't issue any bulk_writes in the
current implementation. But there are some bulk_reads for reading the
raw sensor data and those are not affected due to this.

> 
> Otherwise looks fine to me,

Thanks and Regards,
Kanak Shilledar

Attachment: signature.asc
Description: This is a digitally signed message part