linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Mark Brown <broonie@kernel.org>,
	Crestez Dan Leonard <leonard.crestez@intel.com>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
	linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
	Hartmut Knaack <knaack.h@gmx.de>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Daniel Baluta <daniel.baluta@intel.com>
Subject: Re: [PATCH 1/5] max44000: Initial commit
Date: Mon, 18 Apr 2016 20:36:19 +0100	[thread overview]
Message-ID: <57153733.1070605@kernel.org> (raw)
In-Reply-To: <20160418123451.GB3217@sirena.org.uk>

On 18/04/16 13:34, Mark Brown wrote:
> On Mon, Apr 18, 2016 at 03:15:54PM +0300, Crestez Dan Leonard wrote:
> 
>> As a further clarification: regmap_write will write to hardware even if
>> the cache is known to be up-to-date and no matter the regcache_type. Did
>> I understand this correctly?
> 
>> I'm basing this on reading the code, it seems to me that map->reg_write
>> is only avoided on error paths or if map->cache_only is set to true.
> 
>> This always-write guarantee is not obvious and if it's OK for drivers to
>> rely on it perhaps it should be explicitly documented on regmap_write.
> 
> Yes.  I have to say that you are the first person I've encountered who
> has been confused by this, I'm not sure why you'd expect writes to be
> discarded.
> 
It confused me too :)  To my mind a classic cache optimization would be
to not write to the hardware if the value is already known to be as
desired.

Still, I guess it would add another check to identify which
registers you really wanted to hammer whatever vs which can be assumed
not to read the write is not worth the effort for this case that 
inherently won't be hit that often.

Jonathan 

  reply	other threads:[~2016-04-18 19:36 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-07 16:21 [PATCH 0/5] Support for max44000 Ambient and Infrared Proximity Sensor Crestez Dan Leonard
2016-04-07 16:21 ` [PATCH 1/5] max44000: Initial commit Crestez Dan Leonard
2016-04-07 19:48   ` Peter Meerwald-Stadler
2016-04-10 13:12     ` Jonathan Cameron
2016-04-11 15:08       ` Crestez Dan Leonard
2016-04-17  8:36         ` Jonathan Cameron
2016-04-18 10:32           ` Mark Brown
2016-04-18 10:59             ` Lars-Peter Clausen
2016-04-18 12:15             ` Crestez Dan Leonard
2016-04-18 12:34               ` Mark Brown
2016-04-18 19:36                 ` Jonathan Cameron [this message]
2016-04-19  9:06                   ` Mark Brown
2016-04-18 19:38             ` Jonathan Cameron
2016-04-07 16:21 ` [PATCH 2/5] max44000: Initial support for proximity reading Crestez Dan Leonard
2016-04-10 13:14   ` Jonathan Cameron
2016-04-07 16:21 ` [PATCH 3/5] max44000: Support controlling LED current output Crestez Dan Leonard
2016-04-10 13:16   ` Jonathan Cameron
2016-04-07 16:21 ` [PATCH 4/5] max44000: Expose ambient sensor scaling Crestez Dan Leonard
2016-04-10 13:20   ` Jonathan Cameron
2016-04-07 16:21 ` [PATCH 5/5] max44000: Initial triggered buffer support Crestez Dan Leonard
2016-04-07 19:59   ` Peter Meerwald-Stadler
2016-04-11 16:11     ` Crestez Dan Leonard
2016-04-17  8:41       ` Jonathan Cameron
2016-04-07 21:56   ` kbuild test robot
2016-04-10 13:24   ` Jonathan Cameron

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=57153733.1070605@kernel.org \
    --to=jic23@kernel.org \
    --cc=broonie@kernel.org \
    --cc=daniel.baluta@intel.com \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=leonard.crestez@intel.com \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmeerw@pmeerw.net \
    /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).