From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Laxman Dewangan <ldewangan@nvidia.com>
Cc: "gregkh@suse.de" <gregkh@suse.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH V1] regmap: add bulk_write() for non-volatile register set
Date: Thu, 9 Feb 2012 12:55:06 +0000 [thread overview]
Message-ID: <20120209125505.GI3058@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4F33BFDE.7020006@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 1705 bytes --]
On Thu, Feb 09, 2012 at 06:15:18PM +0530, Laxman Dewangan wrote:
> On Thursday 09 February 2012 05:47 PM, Mark Brown wrote:
> >On Thu, Feb 09, 2012 at 05:42:11PM +0530, Laxman Dewangan wrote:
> >>+ if (vol || map->cache_type == REGCACHE_NONE) {
> >>+ ret = _regmap_raw_write(map, reg, val, val_bytes * val_count);
> >You still need to do the byte swap here.
> I saw the regmap_raw_write() and it is using the same way without
> byte swapping.
That's the whole point with the difference between the bulk and raw APIs
though, the raw API skips the byte swapping and the bulk does it.
> Want to use the same function as it is.. I am not sure why do we
> require byte-swapping in this case. Required things will be done by
> _regmap_raw_write only.
The byte swapping is important for any device which has more than 8 bit
register values, it's only not an issue for you because you have 8 bit
registers.
> This api just break the transfer in register-wise if any of the
> register is cached..
Well, there's no fundamental reason why we can't support cache on raw
operations too. It's not implemented because there's no need for it
with any current users rather than because it's impossible.
>
> >>+ } else {
> >>+ for (i = 0; i< val_count; i++) {
> >>+ memcpy(map->work_buf, val + (i * val_bytes), val_bytes);
> >>+ ival = map->format.parse_val(map->work_buf);
> >They're currently symmetric but really this should use format_val().
> >
> The format_val is require integer argument and issue is that I dont
> have this otherwise I need not to parse, can use directly.
>
> Am I missing something here?
>
>
> >* Unknown Key
> >* 0x6E30FDDD
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-02-09 12:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-09 12:12 [PATCH V1] regmap: add bulk_write() for non-volatile register set Laxman Dewangan
2012-02-09 12:17 ` Mark Brown
2012-02-09 12:45 ` Laxman Dewangan
2012-02-09 12:55 ` Mark Brown [this message]
2012-02-09 17:14 ` Laxman Dewangan
2012-02-09 18:12 ` Mark Brown
2012-02-10 9:13 ` Laxman Dewangan
2012-02-10 11:06 ` 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=20120209125505.GI3058@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=gregkh@suse.de \
--cc=ldewangan@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@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).