All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Kevin Cernekee <cernekee@chromium.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
	Lars-Peter Clausen <lars@metafoo.de>,
	dgreid@chromium.org, Andrew Bresticker <abrestic@chromium.org>,
	Olof Johansson <olofj@chromium.org>,
	alsa-devel@alsa-project.org, devicetree@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V2 1/4] regmap: cache: Add "was_reset" argument to regcache_sync_region()
Date: Wed, 29 Apr 2015 17:46:32 +0100	[thread overview]
Message-ID: <20150429164632.GO22845@sirena.org.uk> (raw)
In-Reply-To: <CAJzqFta=ndErf012QEV37kE0oSPp6dF_D7w_i_HsCkx5ytPgdA@mail.gmail.com>

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

On Wed, Apr 29, 2015 at 07:13:27AM -0700, Kevin Cernekee wrote:
> On Wed, Apr 29, 2015 at 3:40 AM, Mark Brown <broonie@kernel.org> wrote:

> > Like I said above we can tell if the hardware was reset because
> > mark_dirty() is called.

> That covers the public API, but I do not understand how you intended
> for this data to be stored in the rbtree if the use of a dirty bitmask
> is discouraged.

We just need a single boolean?

> i.e. regcache_sync() finds a register value marked "present".  How do
> we know whether we need to write it back to the hardware?  For the
> special case of "cached non default register values immediately after
> a HW reset" you can mostly figure this out, but if there was no HW
> reset how do we know which entries changed while the HW was
> inaccessible?

In the first instance do we care?

> > I'm not suggesting that we do anything based on the presence of a cache
> > entry, I'm suggesting that we could avoid having to ever cache values
> > that never get referenced on a system (which can be a lot of them for
> > common use cases) saving us memory.

> This seems to be solving a different problem.  It sounds like you are
> more worried about regcache_sync() writing back lots of default values
> for registers that were never touched, than performing unnecessary
> writes to a few (actively used) registers that weren't changed while
> we were in cache_only mode.  Is that accurate?

No.  This is nothing to do with sync, it's just something that might be
nice.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2015-04-29 16:46 UTC|newest]

Thread overview: 20+ 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  2:44     ` Kevin Cernekee
2015-04-25 11:27   ` Lars-Peter Clausen
2015-04-25 11:32   ` Mark Brown
2015-04-25 11:32     ` Mark Brown
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 10:40           ` Mark Brown
2015-04-29 14:13           ` Kevin Cernekee
2015-04-29 16:46             ` Mark Brown [this message]
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
2015-04-24 22:36   ` 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-24 22:36     ` 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=20150429164632.GO22845@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 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.