linux-tegra.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Mark Brown
	<broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
Cc: "gregkh-l3A5Bk7waGM@public.gmane.org"
	<gregkh-l3A5Bk7waGM@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] regmap: add bulk_write() for non-volatile register set
Date: Thu, 9 Feb 2012 22:44:15 +0530	[thread overview]
Message-ID: <4F33FEE7.9080608@nvidia.com> (raw)
In-Reply-To: <20120209125505.GI3058-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>

On Thursday 09 February 2012 06:25 PM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> 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.
>
Ok, re-going through the apis again about the byte swapping, what I 
understand is that raw_read or raw_write always happen in bing-endian 
regardless of cpu. And bulk read/write supported the data which is in 
the cpu-endianess.
So we need to convert the data from cpu_to_bexx if we want to call 
raw_write from bulk_write. Similarly we need to convert the data from 
bexx_to_cpu when we read from raw-read which is called from bulk_read().
If this is case then if we want the data in integer type from bulk_write 
data pointer then just memcpy will be fine like
unsigned int ival;
memcpy(&ival, bulk_val_ptr, val_bytes);
and for calling raw_write, it need to call format_val() so this will do 
byte swapping. This require to duplicate the data pointer to new pointer 
and then do manipulation. Once we do this then we will be able to call 
raw_write() with the new duplicated pointer.

if the register writes are broken in multiple transaction then only get 
the integer_val using memcpy and call regmap_write(), need not to format it.

This may be require mem alloc/free on every call. It can be avoided by 
allocating memory for size (val_bytes + max_register) in advance during 
init..
Is it correct?

>> 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.
>
Now if we want to support the caching from raw-write then we need to 
either do caching first or device write first.
I am seeing one issue with this approach:
Whichever is first, if we do caching (which is in loop) and if it fails 
in between inside loop then we may not able to revert it
or it will be complicate to implement the reversal of old values.
Also if it is stored in cache first and later if write fails then also 
it will be difficult to revert it.

If above error is not the issue then possibly following is the solution:

- remove the warnings from raw-write...
- Let allow the reg_write as what it is already  there.
- Then parse input val pointer and put in cache register by register
                for (i = 0; i < val_len / map->format.val_bytes; i++) {
                   memcpy(map->work_buf, val + (i * val_bytes), val_bytes);
                   ival = map->format.parse_val(map->work_buf);
                   ret = regcache_write(map, reg + i, ival);
                   if (ret != 0)
                       dev_warn("Unable to cache register %d\n", reg +i);
                }

It seems modifying raw_write() looks simple if we are able to ignore the 
caching error..
Let me know your opinion?

Thanks,
Laxman


>>>> +	} 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
> * Unknown Key
> * 0x6E30FDDD

  parent reply	other threads:[~2012-02-09 17:14 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
     [not found] ` <1328789531-10067-1-git-send-email-ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-02-09 12:17   ` Mark Brown
     [not found]     ` <20120209121704.GF3058-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-02-09 12:45       ` Laxman Dewangan
     [not found]         ` <4F33BFDE.7020006-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-02-09 12:55           ` Mark Brown
     [not found]             ` <20120209125505.GI3058-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-02-09 17:14               ` Laxman Dewangan [this message]
     [not found]                 ` <4F33FEE7.9080608-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-02-09 18:12                   ` Mark Brown
     [not found]                     ` <20120209181224.GK3058-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-02-10  9:13                       ` Laxman Dewangan
     [not found]                         ` <4F34DFC7.3020208-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
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=4F33FEE7.9080608@nvidia.com \
    --to=ldewangan-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
    --cc=broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org \
    --cc=gregkh-l3A5Bk7waGM@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@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 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).