From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: "andrey.smirnov@convergeddevices.net"
<andrey.smirnov@convergeddevices.net>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] [regmap] [RESEND] Add "no-bus" option for regmap API
Date: Tue, 15 Jan 2013 16:02:44 +0900 [thread overview]
Message-ID: <20130115070243.GF5701@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <CAHQ1cqGWYsfBAsp_8AOyJ0Q-7_PS-v6wRv6w5DQTju5tNf9fdg@mail.gmail.com>
On Mon, Jan 14, 2013 at 09:08:27AM -0800, Andrey Smirnov wrote:
> On Sun, Jan 13, 2013 at 3:18 PM, Mark Brown
> > On Sat, Jan 12, 2013 at 12:54:14PM -0800, Andrey Smirnov wrote:
> >> + bool cache_registers;
> > I'm afraid I don't quite understand this...
> From my understanding of the code it is done because the caching is
> handled differently for cases when format_write() and format_reg(),
> format_val() are provided.
> In case of 'format_write' the regcache_write() is called in
> _regmap_write() directly whereas when format_reg(), format_val() are
> there _regmap_write() calls _regmap_raw_write() which in turn calls
> regcache_write(). If I remove that variable and corresponding check
> then regcache_write() would be called twice in the case of
> format_reg(), format_val(), when _regmap_write() is called, would it
> not? I apologise if I miss something obvious and that is not a case(or
> issue).
OK, in this case the variable is confusingly named - it has no effect on
if we're going to cache, it's about where we cache. What's really
driving the decision here is a combination of having block I/O support
(this was done this way to support cache for block writes) and having
the ability to read (which is what limits us). Not sure I can think of
a good name right now though...
next prev parent reply other threads:[~2013-01-15 7:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-12 20:54 [PATCH 0/3] [regmap] [RESEND] Add "no-bus" configuration for regmap API Andrey Smirnov
2013-01-12 20:54 ` [PATCH 1/3] [regmap] [RESEND] Add provisions to have user-defined read operation Andrey Smirnov
2013-01-13 23:04 ` Mark Brown
2013-01-12 20:54 ` [PATCH 2/3] [regmap] [RESEND] Add provisions to have user-defined write operation Andrey Smirnov
2013-01-13 23:04 ` Mark Brown
2013-01-12 20:54 ` [PATCH 3/3] [regmap] [RESEND] Add "no-bus" option for regmap API Andrey Smirnov
2013-01-13 23:18 ` Mark Brown
2013-01-14 17:08 ` Andrey Smirnov
2013-01-15 7:02 ` Mark Brown [this message]
2013-01-13 12:03 ` [PATCH 0/3] [regmap] [RESEND] Add "no-bus" configuration " 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=20130115070243.GF5701@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=andrew.smirnov@gmail.com \
--cc=andrey.smirnov@convergeddevices.net \
--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 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.