public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: "guennadi.liakhovetski@linux.intel.com" 
	<guennadi.liakhovetski@linux.intel.com>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"ryan.lee.maxim@gmail.com" <ryan.lee.maxim@gmail.com>,
	Ryan Lee <RyanS.Lee@maximintegrated.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"tiwai@suse.com" <tiwai@suse.com>,
	"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
	"sathya.prakash.m.r@intel.com" <sathya.prakash.m.r@intel.com>,
	"yung-chuan.liao@linux.intel.com"
	<yung-chuan.liao@linux.intel.com>
Subject: Re: [EXTERNAL] Re: [PATCH] ASoC: max98373: Mark cache dirty before entering sleep
Date: Mon, 27 Sep 2021 12:23:06 -0500	[thread overview]
Message-ID: <0af258d4-e33c-15ec-5dcc-a1c9961c0740@linux.intel.com> (raw)
In-Reply-To: <20210927171033.GF4199@sirena.org.uk>



On 9/27/21 12:10 PM, Mark Brown wrote:
> On Mon, Sep 27, 2021 at 11:48:56AM -0500, Pierre-Louis Bossart wrote:
>> On 9/27/21 11:06 AM, Mark Brown wrote:
> 
>>> More specifically what it does is make the invalidation of the register
>>> cache unconditional.  It doesn't really matter if the invalidation is
>>> done on suspend or resume, so long as it happens before we attempt to
>>> resync - this could also be done by deleting the first_hw_init check.
> 
>> Mark, that's exactly my point: if the amp rejoins the bus, we will
>> *always* mark the cache as dirty, before the resync is done in the
>> resume sequence.
> 
> Ah, yes - I see.
> 
>> I am really trying to figure out if we have a major flaw in the resume
>> sequence and why things are different in the case of the Maxim amp.
> 
>> Instead of changing the suspend sequence, can we please try to modify
>> the max98373_io_init() routine to unconditionally flag the cache as
>> dirty, maybe this points to a problem with the management of the
>> max98373->first_hw_init flag.
> 
> A quick survey of other drivers suggests that this pattern should be
> factored out into some helpers as it looks like there's several ways of
> implementing it that look very similar but not quite the same...

No disagreement here, we tried really hard to enforce a common pattern
for suspend-resume, but i just noticed that the maxim amp driver is
different on suspend (resume is consistent with the rest).


static int __maybe_unused rt711_dev_suspend(struct device *dev)
{
	struct rt711_priv *rt711 = dev_get_drvdata(dev);

	if (!rt711->hw_init)
		return 0;

	cancel_delayed_work_sync(&rt711->jack_detect_work);
	cancel_delayed_work_sync(&rt711->jack_btn_check_work);
	cancel_work_sync(&rt711->calibration_work);

	regcache_cache_only(rt711->regmap, true);

	return 0;
}

static int __maybe_unused rt1308_dev_suspend(struct device *dev)
{
	struct rt1308_sdw_priv *rt1308 = dev_get_drvdata(dev);

	if (!rt1308->hw_init)
		return 0;

	regcache_cache_only(rt1308->regmap, true);

	return 0;
}

static __maybe_unused int max98373_suspend(struct device *dev)
{
	struct max98373_priv *max98373 = dev_get_drvdata(dev);
	int i;

<<<< missing test

	/* cache feedback register values before suspend */
	for (i = 0; i < max98373->cache_num; i++)
		regmap_read(max98373->regmap, max98373->cache[i].reg,
&max98373->cache[i].val);

<<<< why is this needed???

	regcache_cache_only(max98373->regmap, true);

	return 0;
}




  reply	other threads:[~2021-09-27 17:35 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-24 22:13 [PATCH] ASoC: max98373: Mark cache dirty before entering sleep Ryan Lee
2021-09-27 14:54 ` Pierre-Louis Bossart
2021-09-27 16:01   ` [EXTERNAL] " Ryan Lee
2021-09-27 16:06     ` Mark Brown
2021-09-27 16:48       ` Pierre-Louis Bossart
2021-09-27 17:10         ` Mark Brown
2021-09-27 17:23           ` Pierre-Louis Bossart [this message]
2021-09-27 17:29             ` Mark Brown
2021-09-28 16:43             ` Ryan Lee
2021-09-28 18:15               ` Pierre-Louis Bossart
2021-09-27 18:44         ` Ryan Lee
2021-09-27 19:34           ` Pierre-Louis Bossart
2021-09-27 22:43             ` Ryan Lee
2021-09-30  6:21             ` Ryan Lee
2021-09-30 13:29               ` Pierre-Louis Bossart
2021-09-30 23:31               ` Ryan Lee
2021-09-30 23:53                 ` Pierre-Louis Bossart

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=0af258d4-e33c-15ec-5dcc-a1c9961c0740@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=RyanS.Lee@maximintegrated.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=guennadi.liakhovetski@linux.intel.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ryan.lee.maxim@gmail.com \
    --cc=sathya.prakash.m.r@intel.com \
    --cc=tiwai@suse.com \
    --cc=yung-chuan.liao@linux.intel.com \
    /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