From: Patrick Rudolph <patrick.rudolph@9elements.com>
To: Mark Brown <broonie@kernel.org>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
naresh.solanki@9elements.com, linux-gpio@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] pinctrl: cy8c95x0: Cache muxed registers
Date: Thu, 16 May 2024 19:03:54 +0200 [thread overview]
Message-ID: <CALNFmy1ZRqHz6_DD_2qamm-iLQ51AOFQH=ahCWRN7SAk3pfZ_A@mail.gmail.com> (raw)
In-Reply-To: <85577035-06b0-4059-8092-1b751c2a6b53@sirena.org.uk>
Hi Mark,
I tried to convert the cy8c95x0 driver to use the regmap ranges, but
had a few problems:
- I removed the regmap lock since the driver has it's own mutex to
protect all regmap accesses.
That disabled the regmap debugfs, which wasn't obvious to me and
took some time to figure out.
- I verified that the regmap range works as expected, but the debugfs
showed that the regcache has invalid defaults.
The defaults are read from HW using by setting "num_reg_defaults_raw".
From what I understand regmap_raw_read() called by
regcache_hw_init() ignores the ranges
and doesn't use the page selector at all. Since it's not using
paging the contents will be invalid.
I had to apply the workaround in the config ".use_single_read =
true" to fix the cache init, but
that might reduce performance when initializing the cache.
Is this a bug or a known limitation of the regcache?
It looks like none of the other drivers use num_reg_defaults_raw +
ranges at the same time.
Regards,
Patrick
prev parent reply other threads:[~2024-05-16 17:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-19 12:53 [PATCH] pinctrl: cy8c95x0: Cache muxed registers Patrick Rudolph
2023-12-20 12:04 ` Linus Walleij
2024-05-14 5:27 ` Andy Shevchenko
2024-05-14 7:49 ` Linus Walleij
2024-05-14 8:39 ` Patrick Rudolph
2024-05-14 8:51 ` Linus Walleij
2024-05-14 8:55 ` Andy Shevchenko
2024-05-14 8:57 ` Andy Shevchenko
2024-05-14 9:02 ` Mark Brown
2024-05-14 9:23 ` Andy Shevchenko
2024-05-14 9:30 ` Mark Brown
2024-05-14 8:55 ` Mark Brown
2024-05-16 17:03 ` Patrick Rudolph [this message]
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='CALNFmy1ZRqHz6_DD_2qamm-iLQ51AOFQH=ahCWRN7SAk3pfZ_A@mail.gmail.com' \
--to=patrick.rudolph@9elements.com \
--cc=andy.shevchenko@gmail.com \
--cc=broonie@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=naresh.solanki@9elements.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).