All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Javier Carrasco" <javier.carrasco.cruz@gmail.com>
To: "Andy Shevchenko" <andy.shevchenko@gmail.com>
Cc: "Matti Vaittinen" <mazziesaccount@gmail.com>,
	"Jonathan Cameron" <jic23@kernel.org>,
	"Lars-Peter Clausen" <lars@metafoo.de>,
	<linux-iio@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	"Jonathan Cameron" <Jonathan.Cameron@huawei.com>
Subject: Re: [PATCH v2 3/4] iio: light: veml3235: extend regmap to add cache
Date: Sun, 12 Jan 2025 17:21:22 +0100	[thread overview]
Message-ID: <D708DGNQA4MO.1DD0OCM1TOHS2@gmail.com> (raw)
In-Reply-To: <CAHp75Vd5LdP7+ndresVv5STN2zrC3S5puDhcACyEk7MbLA0hgA@mail.gmail.com>

On Sun Jan 12, 2025 at 5:11 PM CET, Andy Shevchenko wrote:
> On Sun, Jan 12, 2025 at 6:07 PM Javier Carrasco
> <javier.carrasco.cruz@gmail.com> wrote:
> >
> > On Sun Jan 12, 2025 at 4:18 PM CET, Andy Shevchenko wrote:
> > > Tue, Dec 24, 2024 at 11:59:02AM +0100, Javier Carrasco kirjoitti:
> > > > The configuration and ID registers are not volatile and are not affected
> > > > by read operations (i.e. not precious), making them suitable to be
> > > > cached in order to reduce the number of accesses to the device.
> > >
> > > ...
> > >
> > > >  static const struct regmap_config veml3235_regmap_config = {
> > > >     .name = "veml3235_regmap",
> > > >     .reg_bits = 8,
> > > >     .val_bits = 16,
> > > >     .max_register = VEML3235_REG_ID,
> > > >     .val_format_endian = REGMAP_ENDIAN_LITTLE,
> > > > +   .rd_table = &veml3235_readable_table,
> > > > +   .wr_table = &veml3235_writable_table,
> > > > +   .volatile_table = &veml3235_volatile_table,
> > > > +   .cache_type = REGCACHE_RBTREE,
> > >
> > > Any specific reason why this is NOT a maple tree?
> >
> > Hello Andy,
> >
> > I followed the most common approach in IIO (52 RBTREE vs 2 MAPLE),
>
> But it's historical and can't be taken as an argument.
>
> > assuming that the "low-end systems" comment for the different REGCACHE_*
> > applies well to the typical systems that will make use of this driver,
> > and many others under IIO. I considered that *possible* performance
> > advantage for low-end systems above other considerations, like the
> > general rule about using maple tree.
>
> https://elixir.bootlin.com/linux/v6.13-rc3/source/include/linux/regmap.h#L58
>
> "Any new caches
>  * should usually use the maple tree cache unless they specifically
>  * require that there are never any allocations at runtime and can't
>  * provide defaults in which case they should use the flat cache."
>
> Can you reconsider?

That was exactly the comment I referenced, actually the part about
low-end systems that appears right after what you highlighted.

I have nothing against switching to MAPLE, if that is preferred even if
the main user of this driver will be a low-end system. I think that IIO
is a typical subsystem that addresses needs for very low-end systems
that are sometimes slightly more powerful than a microcontroller, but on
the other hand I am by no means an expert, and if MAPLE is the way to go
here as well, I will send a follow-up patch for it.

Thank you for your feedback!

Javier Carrasco

  reply	other threads:[~2025-01-12 16:21 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-24 10:58 [PATCH v2 0/4] iio: light: fix scale in veml3235 and add helpers to iio-gts Javier Carrasco
2024-12-24 10:59 ` [PATCH v2 1/4] iio: gts-helper: add helpers to ease searches of gain_sel and new_gain Javier Carrasco
2024-12-28 15:41   ` Jonathan Cameron
2024-12-30  9:58     ` Javier Carrasco
2024-12-24 10:59 ` [PATCH v2 2/4] iio: light: veml3235: fix code style Javier Carrasco
2024-12-28 15:42   ` Jonathan Cameron
2024-12-24 10:59 ` [PATCH v2 3/4] iio: light: veml3235: extend regmap to add cache Javier Carrasco
2024-12-28 15:43   ` Jonathan Cameron
2025-01-12 15:18   ` Andy Shevchenko
2025-01-12 16:07     ` Javier Carrasco
2025-01-12 16:11       ` Andy Shevchenko
2025-01-12 16:21         ` Javier Carrasco [this message]
2025-01-12 18:50           ` Andy Shevchenko
2025-01-14 13:23             ` Jonathan Cameron
2024-12-24 10:59 ` [PATCH v2 4/4] iio: veml3235: fix scale to conform to ABI Javier Carrasco
2024-12-28 15:47   ` Jonathan Cameron
2024-12-29  6:53   ` Matti Vaittinen
2024-12-30 10:01     ` Javier Carrasco
2024-12-30 12:13       ` Matti Vaittinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D708DGNQA4MO.1DD0OCM1TOHS2@gmail.com \
    --to=javier.carrasco.cruz@gmail.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=jic23@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mazziesaccount@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.