From: Mark Brown <broonie@kernel.org>
To: Kevin Cernekee <cernekee@chromium.org>
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
lars@metafoo.de, abrestic@chromium.org, lgirdwood@gmail.com,
linux-kernel@vger.kernel.org, dgreid@chromium.org,
olofj@chromium.org
Subject: Re: [PATCH V2 1/4] regmap: cache: Add "was_reset" argument to regcache_sync_region()
Date: Sat, 25 Apr 2015 12:32:35 +0100 [thread overview]
Message-ID: <20150425113235.GA31708@sirena.org.uk> (raw)
In-Reply-To: <1429915008-22015-2-git-send-email-cernekee@chromium.org>
[-- Attachment #1.1: Type: text/plain, Size: 2104 bytes --]
On Fri, Apr 24, 2015 at 03:36:45PM -0700, Kevin Cernekee wrote:
> index 116655d92269..ece122a6fdeb 100644
> --- a/include/linux/regmap.h
> +++ b/include/linux/regmap.h
> @@ -438,7 +438,7 @@ bool regmap_can_raw_write(struct regmap *map);
>
> int regcache_sync(struct regmap *map);
> int regcache_sync_region(struct regmap *map, unsigned int min,
> - unsigned int max);
> + unsigned int max, bool was_reset);
This seems pretty ugly - both the fact that we're changing the signature
of the function and the naming of the argument feel inelegant. The
point isn't if the device has been reset, the point is if the device
currently has the default register values or not, and this means that
the user is responsible for tracking that state until the next time it
does the sync. That may be immediately like in your case but there's no
reason that has to be the case. The fact that we're passing in
something called "is_reset" which sounds like a state value for the
register map is a bit of a warning sign here.
What we should be doing here is providing a way for users to tell regmap
if they've reset the register map and actually we already have that
interface, it's just not got the best name - regcache_mark_dirty() is
effectively it since there's really not a lot of other reasons why a
driver would need to mark the cache as dirty. We're just not handling
it properly. What we should do instead is to keep the interface as it
is for now and make it behave in a more expected fashion so that if the
cache is explicitly marked dirty we assume that the hardware is in the
default state and otherwise we don't.
Ideally what we'd do is both improve the naming of mark_dirty() (though
that's API churn which is nasty) and arrange for rbtree to cache the
default values lazily, that way the only things in the cache will be
things that have been explicitly changed (we will still want default
checking but it makes life easier and means we don't end up having to do
a full writeout for cases where things have been put into cache mode
without a reset).
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2015-04-25 11:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-24 22:36 [PATCH V2 0/4] tas571x amplifier driver Kevin Cernekee
2015-04-24 22:36 ` [PATCH V2 1/4] regmap: cache: Add "was_reset" argument to regcache_sync_region() Kevin Cernekee
2015-04-25 2:44 ` Kevin Cernekee
2015-04-25 11:27 ` Lars-Peter Clausen
2015-04-25 11:32 ` Mark Brown [this message]
2015-04-29 4:58 ` Kevin Cernekee
[not found] ` <CAJzqFtYkSds+s2HA3uKrMQes+D2K1TxOdzm5jJhtt2iZvyqxCA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-04-29 10:40 ` Mark Brown
2015-04-29 14:13 ` Kevin Cernekee
2015-04-29 16:46 ` Mark Brown
2015-04-29 17:02 ` Kevin Cernekee
2015-04-29 17:34 ` Mark Brown
2015-04-24 22:36 ` [PATCH V2 2/4] ASoC: tas571x: Add DT binding document Kevin Cernekee
[not found] ` <1429915008-22015-1-git-send-email-cernekee-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2015-04-24 22:36 ` [PATCH V2 3/4] ASoC: tas571x: New driver for TI TAS571x power amplifiers Kevin Cernekee
2015-04-25 11:35 ` Mark Brown
2015-04-24 22:36 ` [PATCH V2 4/4] MAINTAINERS: Add entry for tas571x ASoC codec driver Kevin Cernekee
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=20150425113235.GA31708@sirena.org.uk \
--to=broonie@kernel.org \
--cc=abrestic@chromium.org \
--cc=alsa-devel@alsa-project.org \
--cc=cernekee@chromium.org \
--cc=devicetree@vger.kernel.org \
--cc=dgreid@chromium.org \
--cc=lars@metafoo.de \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=olofj@chromium.org \
/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