Re: [PATCH v5 5/6] iio: imu: inv_icm42607: Implement MREGx register access

[Kanak Shilledar <Kanak.Shilledar@axis.com>]

[-- Attachment #1: Type: text/plain, Size: 1970 bytes --]


Hi Andy,
On Sat, 2026-10-03 at 18:02 +0300, andriy.shevchenko@intel.com wrote:
> On Fri, Oct 02, 2026 at 02:25:48PM +0000, Kanak Shilledar wrote:
> 
> > On Fri, 2026-10-02 at 16:12 +0300, Andy Shevchenko wrote:
> > > On Fri, Oct 02, 2026 at 01:54:29PM +0200, Kanak Shilledar wrote:
> 
> ...
> 
> > > > +static int inv_icm42607_mreg_read(struct regmap *map, unsigned
> > > > int
> > > > reg,
> > > > +				  u8 *data, size_t count)
> > > > +{
> > > > +	unsigned int val;
> > > > +	bool idle_set;
> > > > 
...
> > > > +
> > > > +	return ret;
> > > >  }
> 
> ...
> 
> > > > +static const struct regmap_config inv_icm42607_regmap_config =
> > > > {
> > > > +	.reg_bits = 8,
> > > > +	.val_bits = 8,
> > > 
> > > No cache? Why?
> > As the virtual regmap config has some caching for USER BANK 0
> > registers
> > only. The indirect banks doesn't support caching [1].
> 
> This is strange. You mean they are volatile by definition (HW)?
> Otherwise if it's just a software issue, it can still be done,
> for regcache there is no difference if the offset is real or paged.

Sorry, I was not very clear in the explanation about caches. Only some
specific MREGx registers are volatile and I am not using those yet. I
have removed the MREGx registers from the _is_volatile_reg function.

In this 8-bit transport regmap I am not using any caching because the
16-bit virtual regmap (in _core.c) already knows all the registers
(readable/writeable/volatile) and also contains a cache. Everything
which reaches the transport regmap is either a write or read which was
missed in the virtual cache or an access to the bank switching
registers which should always reach the hardware. I tried adding
REGCACHE_MAPLE in the transport regmap, but accessing registers in
MREG1 then timed out due to stale cached values.

> > > 
> > [1] Datasheet: https://www.lcsc.com/product-detail/C5129967.html

Thanks and Regards,
Kanak Shilledar

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]