devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lars-Peter Clausen <lars@metafoo.de>
To: Kevin Cernekee <cernekee@chromium.org>,
	lgirdwood@gmail.com, broonie@kernel.org
Cc: dgreid@chromium.org, abrestic@chromium.org, olofj@chromium.org,
	alsa-devel@alsa-project.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2 1/4] regmap: cache: Add "was_reset" argument to regcache_sync_region()
Date: Sat, 25 Apr 2015 13:27:13 +0200	[thread overview]
Message-ID: <553B7A11.7040706@metafoo.de> (raw)
In-Reply-To: <1429915008-22015-2-git-send-email-cernekee@chromium.org>

On 04/25/2015 12:36 AM, Kevin Cernekee wrote:
> regcache_sync() and regcache_sync_region() currently assume that the
> hardware has just emerged from a clean reset, and that all registers are
> in their default states.  But that isn't the only possibility; the device
> may have been in a different state in which the registers were
> inaccessible but have retained their contents, e.g. clock gating.
>
> So we will extend the more versatile of the two functions,
> regcache_sync_region(), to let the caller decide what assumptions should
> be made.
>
> One driver that can benefit from this is adau1977, which has hacks to
> overwrite the registers that regcache_sync() might have missed.

The issue with the adau1977 is slightly different, there is only one single 
register which is not affected, so we need special handling for that 
register. For all other registers the default behavior of regcache_sync() is 
correct.

> Also, the powerdown pin on tas571x does not reset the register contents
> either, so a similar feature will be required by that driver.
>
> This commit just adds the new argument by changing the function
> declarations and call sites, but doesn't wire it up yet.

I think a better approach is to introduce a new flag internally, similar to 
the cache_dirty flag. Set both this new flag and cache_dirty when 
regcache_mark_dirty() is called. But only cache_dirty when a write is 
performed when the regmap is marked as cache only. Now in regcache_sync() 
and friends check this new flag and only when it is set skip registers which 
match the default. At the end of regcache_sync() clear both flags.

[...]
> @@ -600,7 +605,8 @@ static bool regcache_reg_present(unsigned long *cache_present, unsigned int idx)
>   static int regcache_sync_block_single(struct regmap *map, void *block,
>   				      unsigned long *cache_present,
>   				      unsigned int block_base,
> -				      unsigned int start, unsigned int end)
> +				      unsigned int start, unsigned int end,
> +				      bool was_reset)
>   {
>   	unsigned int i, regtmp, val;
>   	int ret;
> @@ -614,10 +620,12 @@ static int regcache_sync_block_single(struct regmap *map, void *block,
>
>   		val = regcache_get_val(map, block, i);
>
> -		/* Is this the hardware default?  If so skip. */
> -		ret = regcache_lookup_reg(map, regtmp);
> -		if (ret >= 0 && val == map->reg_defaults[ret].def)
> -			continue;
> +		if (was_reset) {
> +			/* Is this the hardware default?  If so skip. */
> +			ret = regcache_lookup_reg(map, regtmp);
> +			if (ret >= 0 && val == map->reg_defaults[ret].def)
> +				continue;
> +		}

Probably factor the check whether wee need to sync or not into a helper 
function, that can be used here and below in sync_block_raw().

[...]
> @@ -689,14 +697,17 @@ static int regcache_sync_block_raw(struct regmap *map, void *block,
>
>   		val = regcache_get_val(map, block, i);
>
> -		/* Is this the hardware default?  If so skip. */
> -		ret = regcache_lookup_reg(map, regtmp);
> -		if (ret >= 0 && val == map->reg_defaults[ret].def) {
> -			ret = regcache_sync_block_raw_flush(map, &data,
> -							    base, regtmp);
> -			if (ret != 0)
> -				return ret;
> -			continue;
> +		if (was_reset) {
> +			/* Is this the hardware default?  If so skip. */
> +			ret = regcache_lookup_reg(map, regtmp);
> +			if (ret >= 0 && val == map->reg_defaults[ret].def) {
> +				ret = regcache_sync_block_raw_flush(map, &data,
> +								    base,
> +								    regtmp);
> +				if (ret != 0)
> +					return ret;
> +				continue;
> +			}
>   		}
>
[...]

  parent reply	other threads:[~2015-04-25 11:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-24 22:36 [PATCH V2 0/4] tas571x amplifier driver Kevin Cernekee
2015-04-24 22:36 ` [PATCH V2 1/4] regmap: cache: Add "was_reset" argument to regcache_sync_region() Kevin Cernekee
2015-04-25  2:44   ` Kevin Cernekee
2015-04-25 11:27   ` Lars-Peter Clausen [this message]
2015-04-25 11:32   ` Mark Brown
2015-04-29  4:58     ` Kevin Cernekee
     [not found]       ` <CAJzqFtYkSds+s2HA3uKrMQes+D2K1TxOdzm5jJhtt2iZvyqxCA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-04-29 10:40         ` Mark Brown
2015-04-29 14:13           ` Kevin Cernekee
2015-04-29 16:46             ` Mark Brown
2015-04-29 17:02               ` Kevin Cernekee
2015-04-29 17:34                 ` Mark Brown
2015-04-24 22:36 ` [PATCH V2 2/4] ASoC: tas571x: Add DT binding document Kevin Cernekee
     [not found] ` <1429915008-22015-1-git-send-email-cernekee-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2015-04-24 22:36   ` [PATCH V2 3/4] ASoC: tas571x: New driver for TI TAS571x power amplifiers Kevin Cernekee
2015-04-25 11:35     ` Mark Brown
2015-04-24 22:36 ` [PATCH V2 4/4] MAINTAINERS: Add entry for tas571x ASoC codec driver Kevin Cernekee

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=553B7A11.7040706@metafoo.de \
    --to=lars@metafoo.de \
    --cc=abrestic@chromium.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=cernekee@chromium.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dgreid@chromium.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olofj@chromium.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).