linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Jorge Ramirez-Ortiz <jramirez@baylibre.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC] regmap: allow volatile register writes with cached only read maps
Date: Sun, 13 May 2018 11:22:02 +0900	[thread overview]
Message-ID: <20180513022202.GA17611@sirena.org.uk> (raw)
In-Reply-To: <7cc158bb-3471-4d8e-d066-2e7f535812eb@baylibre.com>

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

On Fri, May 11, 2018 at 12:29:42PM +0200, Jorge Ramirez-Ortiz wrote:
> On 05/11/2018 04:00 AM, Mark Brown wrote:

> > We don't currently suppress writes except when regmap_update_bits()
> > notices that the modification was a noop.  You probably want to be using
> > regmap_write_bits() here instead of regmap_update_bits(), that will
> > always do the write.

> but isnt that interface at a different level?

It's at the level where we suppress writes - the write suppression isn't
a feature of the caching, it's something that regmap_update_bits() does
if it notices that it won't change anything.  It'll happen even if
there's no cache at all.

> I am not sure if you are asking me to review my patch or just discarding the
> RFC and highlighting that I have a configuration problem.

I don't understand your patch as-is.

> In my use case and what triggered this RFC (config below), an 'amixer set'
> might never reach the driver's .reg_write interface even though the register
> is configured as volatile (to me this is not consistent since volatile_reg
> is being silently ignored).

I'm not seeing any inconsistency there.  Volatility means the register
can't be cached as it might change underneath us, it doesn't have any
impact on writes and it's happening at a lower level.  Like I say if you
absolutely need a write to happen you should be explicitly doing a
write, though if you need a write to happen for a noop control change it
sounds like there's something weird with that control that's possibly a
problem anyway.

> So I dont see where/how your recommendation fits; maybe you could clarify a
> bit more please?

As I've been saying if you explicitly need a write to happen don't use
regmap_update_bits(), do something that guarantees you'll get a write
like regmap_write() or regmap_write_bits().

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2018-05-13  2:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-08 22:06 [RFC] regmap: allow volatile register writes with cached only read maps Jorge Ramirez-Ortiz
2018-05-09  8:39 ` Mark Brown
2018-05-09 11:49   ` Jorge Ramirez-Ortiz
2018-05-11  2:00     ` Mark Brown
2018-05-11 10:29       ` Jorge Ramirez-Ortiz
2018-05-13  2:22         ` Mark Brown [this message]
2018-05-17  7:12           ` Jorge Ramirez-Ortiz
2018-05-17 17:04             ` Mark Brown

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=20180513022202.GA17611@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=jramirez@baylibre.com \
    --cc=linux-kernel@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).