From: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Mark Brown
<broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
Cc: "sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org"
<sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
"lrg-l0cyMroinI0@public.gmane.org"
<lrg-l0cyMroinI0@public.gmane.org>,
"jedu-kDsPt+C1G03kYMGBc/C6ZA@public.gmane.org"
<jedu-kDsPt+C1G03kYMGBc/C6ZA@public.gmane.org>,
"gg-kDsPt+C1G03kYMGBc/C6ZA@public.gmane.org"
<gg-kDsPt+C1G03kYMGBc/C6ZA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH V1 1/2] mfd: tps65910: use regmap for device register access.
Date: Wed, 8 Feb 2012 19:04:14 +0530 [thread overview]
Message-ID: <4F3279D6.4000009@nvidia.com> (raw)
In-Reply-To: <20120208130726.GB5943-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
On Wednesday 08 February 2012 06:37 PM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Wed, Feb 08, 2012 at 05:45:43PM +0530, Laxman Dewangan wrote:
>
>> I did not wanted to make the list of register in core driver. Wanted
>> to leave the decision to the sub-devices driver where they need to
>> enable cache based on their requirements.
>> Do you think that the register list (although it is used in the
>> regulator driver) should be in the core file? If this is allow then
>> I can make the static table in core driver.
> Yes, it should be in the core driver.
>
Fine, it will much simple in this case.
>
>> This function added because there is no bulk_write function in core
>> driver which supports the non-volatile in the list. Even if number
>> of bytes read is 1.
>> Should we move the above logic to core driver?
> This is the core driver? If you mean the regmap core then yes.
>
Yes, change regmap core driver i.e. regmap.c
>> - If any of the register is non-volatile in bulk write then split
>> the transfer into the byte-wise/short-wise/long-wise
>> (format.val_bytes) based on register width?
>> - If all register is volatile the uses the regmap_raw_write()
>> Does it sounds reasonable? If yes then I can move this code to
>> regmap.c as regmap_bulk_write() i.e. new function.
> Yes, though bulk_write() is tricky as it's *really* unclear what it
> should take as an argument - should it be raw register size (in which
> case it's just raw_write()) or should it be ints (in which case it needs
> to repack the data too)? I suspect ints but I'm really not convinced
> there's much use case for this.
>
* @map: Register map to write to
* @reg: Initial register to write to
* @val: Block of data to be written, laid out for direct transmission
to the
* device
* @@val_count: Number of registers to write
int regmap_bulk_write(struct regmap *map, unsigned int reg, void *val,
size_t val_count)
only support if map->format.parse_val not null like bulk_read.
It will just do the regamp_raw_write() if all regs are volatile
otherwise make the unsigned int from the val by function
map->format.parse_val for separate write for each register.
> * Unknown Key
> * 0x6E30FDDD
WARNING: multiple messages have this Message-ID (diff)
From: Laxman Dewangan <ldewangan@nvidia.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: "sameo@linux.intel.com" <sameo@linux.intel.com>,
"lrg@ti.com" <lrg@ti.com>,
"jedu@slimlogic.co.uk" <jedu@slimlogic.co.uk>,
"gg@slimlogic.co.uk" <gg@slimlogic.co.uk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH V1 1/2] mfd: tps65910: use regmap for device register access.
Date: Wed, 8 Feb 2012 19:04:14 +0530 [thread overview]
Message-ID: <4F3279D6.4000009@nvidia.com> (raw)
In-Reply-To: <20120208130726.GB5943@opensource.wolfsonmicro.com>
On Wednesday 08 February 2012 06:37 PM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Wed, Feb 08, 2012 at 05:45:43PM +0530, Laxman Dewangan wrote:
>
>> I did not wanted to make the list of register in core driver. Wanted
>> to leave the decision to the sub-devices driver where they need to
>> enable cache based on their requirements.
>> Do you think that the register list (although it is used in the
>> regulator driver) should be in the core file? If this is allow then
>> I can make the static table in core driver.
> Yes, it should be in the core driver.
>
Fine, it will much simple in this case.
>
>> This function added because there is no bulk_write function in core
>> driver which supports the non-volatile in the list. Even if number
>> of bytes read is 1.
>> Should we move the above logic to core driver?
> This is the core driver? If you mean the regmap core then yes.
>
Yes, change regmap core driver i.e. regmap.c
>> - If any of the register is non-volatile in bulk write then split
>> the transfer into the byte-wise/short-wise/long-wise
>> (format.val_bytes) based on register width?
>> - If all register is volatile the uses the regmap_raw_write()
>> Does it sounds reasonable? If yes then I can move this code to
>> regmap.c as regmap_bulk_write() i.e. new function.
> Yes, though bulk_write() is tricky as it's *really* unclear what it
> should take as an argument - should it be raw register size (in which
> case it's just raw_write()) or should it be ints (in which case it needs
> to repack the data too)? I suspect ints but I'm really not convinced
> there's much use case for this.
>
* @map: Register map to write to
* @reg: Initial register to write to
* @val: Block of data to be written, laid out for direct transmission
to the
* device
* @@val_count: Number of registers to write
int regmap_bulk_write(struct regmap *map, unsigned int reg, void *val,
size_t val_count)
only support if map->format.parse_val not null like bulk_read.
It will just do the regamp_raw_write() if all regs are volatile
otherwise make the unsigned int from the val by function
map->format.parse_val for separate write for each register.
> * Unknown Key
> * 0x6E30FDDD
next prev parent reply other threads:[~2012-02-08 13:34 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-08 10:46 [PATCH V1 1/2] mfd: tps65910: use regmap for device register access Laxman Dewangan
2012-02-08 10:46 ` Laxman Dewangan
[not found] ` <1328697985-22504-1-git-send-email-ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-02-08 10:46 ` [PATCH V1 2/2] regulator: tps65910: Enable register caching of voltage controls Laxman Dewangan
2012-02-08 10:46 ` Laxman Dewangan
2012-02-08 11:41 ` [PATCH V1 1/2] mfd: tps65910: use regmap for device register access Mark Brown
2012-02-08 11:41 ` Mark Brown
[not found] ` <20120208114120.GF3120-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-02-08 12:15 ` Laxman Dewangan
2012-02-08 12:15 ` Laxman Dewangan
2012-02-08 13:07 ` Mark Brown
[not found] ` <20120208130726.GB5943-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-02-08 13:34 ` Laxman Dewangan [this message]
2012-02-08 13:34 ` Laxman Dewangan
[not found] ` <4F3279D6.4000009-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-02-08 13:58 ` Mark Brown
2012-02-08 13:58 ` Mark Brown
2012-02-09 5:03 ` Laxman Dewangan
[not found] ` <4F335385.5040400-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-02-09 11:55 ` Mark Brown
2012-02-09 11:55 ` Mark Brown
[not found] ` <20120209115502.GD3058-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-02-09 11:59 ` Laxman Dewangan
2012-02-09 11:59 ` Laxman Dewangan
[not found] ` <4F33B52A.5020900-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-02-09 12:03 ` Mark Brown
2012-02-09 12:03 ` Mark Brown
[not found] ` <20120209120312.GE3058-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-02-09 12:09 ` Laxman Dewangan
2012-02-09 12:09 ` Laxman Dewangan
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=4F3279D6.4000009@nvidia.com \
--to=ldewangan-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
--cc=broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org \
--cc=gg-kDsPt+C1G03kYMGBc/C6ZA@public.gmane.org \
--cc=jedu-kDsPt+C1G03kYMGBc/C6ZA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=lrg-l0cyMroinI0@public.gmane.org \
--cc=sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.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.