From: Crestez Dan Leonard <leonard.crestez@intel.com>
To: Mark Brown <broonie@kernel.org>, Jonathan Cameron <jic23@kernel.org>
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 15:15:54 +0300 [thread overview]
Message-ID: <5714CFFA.2080309@intel.com> (raw)
In-Reply-To: <20160418103212.GQ3217@sirena.org.uk>
On 04/18/2016 01:32 PM, Mark Brown wrote:
> On Sun, Apr 17, 2016 at 09:36:10AM +0100, Jonathan Cameron wrote:
>> On 11/04/16 16:08, Crestez Dan Leonard wrote:
>>> I used REGCACHE_FLAT because my device has a very small number of
>>> registers and I assume it uses less memory. Honestly it would make
>>> sense for regmap to include a REGCACHE_AUTO cache_type and pick the
>>> cache implementation automatically based on number of registers.
>
>> I've fallen for that one in the past as well. AUTO would indeed
>> be good if it was easy to do.
>
> It's extremely easy to do. Unless you've got a good reason to do
> anything else you should always be using an rbtree. The core would
> never select anything else.
Ok, I will remember this.
>>> Yes. It would not work otherwise since the regmap cache is explicitly
>>> initialized with my listed defaults.
>>> As far as I can tell regmap_write will always write to the hardware.
>
>> Interesting and counter intuitive if true...
>
> No, if the driver asked to write then we write. If the driver wants to
> do a read/modify/write cycle it should use regmap_update_bits().
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.
Otherwise for my device I would need some way to mention that the device
starts in an undefined state, not what is specified in reg_defaults.
For simplicity I will drop regmap_config.reg_defaults completely and
just setup the few parameters I need explicitly. This will be in v3.
--
Regards,
Leonard
next prev parent reply other threads:[~2016-04-18 12:16 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 [this message]
2016-04-18 12:34 ` Mark Brown
2016-04-18 19:36 ` Jonathan Cameron
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=5714CFFA.2080309@intel.com \
--to=leonard.crestez@intel.com \
--cc=broonie@kernel.org \
--cc=daniel.baluta@intel.com \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--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 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.