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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox