From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: shumingf@realtek.com, broonie@kernel.org, lgirdwood@gmail.com
Cc: alsa-devel@alsa-project.org, lars@metafoo.de, flove@realtek.com,
oder_chiou@realtek.com, jack.yu@realtek.com,
derek.fang@realtek.com, Vijendar.Mukunda@amd.com,
Bard Liao <yung-chuan.liao@linux.intel.com>
Subject: Re: [PATCH 1/5] ASoC: rt5682-sdw: fix for JD event handling in ClockStop Mode0
Date: Mon, 3 Jul 2023 12:17:16 +0200 [thread overview]
Message-ID: <f9e83b61-6e69-2467-d5a5-3c3a6a40e018@linux.intel.com> (raw)
In-Reply-To: <20230703090247.25261-1-shumingf@realtek.com>
On 7/3/23 11:02, shumingf@realtek.com wrote:
> From: Shuming Fan <shumingf@realtek.com>
>
> During ClockStop Mode0, peripheral interrupts are disabled.
I can see that the interrupts are disabled in
rt5682_dev_system_suspend(), which is NOT a mode where the clock stop is
used... I don't think this commit message is correct.
The IMPL_DEF interrupt which is used for jack detection is not disabled
at all during any clock stop mode, and it shouldn't otherwise that would
break the jack detection.
> When system level resume is invoked, Peripheral SDCA interrupts
> should be enabled to handle JD events.
The initial 'when system level resume is invoked' is aligned with my
comment above, this interrupt disabling is only for system suspend.
In addition, I think it's a copy paste here, there is no SDCA support in
RT5682 or the initial RT711.
> Enable SDCA interrupts in resume sequence when ClockStop Mode0 is applied.
same comments for rt711-sdw.c and other codecs which use the same
pattern with the same comment
/*
* prevent new interrupts from being handled after the
* deferred work completes and before the parent disables
* interrupts on the link
*/
BTW if this is an issue for system suspend, maybe we should disable the
interrupts on the link in the .prepare stage, that would remove this
step in all codec drivers? The .prepare deals with the parent first,
while .suspend deal with child devices first. The drawback would be that
the codec driver would depend on the manager driver doing the right
thing, which isn't great.
> Signed-off-by: Shuming Fan <shumingf@realtek.com>
> ---
> sound/soc/codecs/rt5682-sdw.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/sound/soc/codecs/rt5682-sdw.c b/sound/soc/codecs/rt5682-sdw.c
> index 67404f45389f..4968a8c0064d 100644
> --- a/sound/soc/codecs/rt5682-sdw.c
> +++ b/sound/soc/codecs/rt5682-sdw.c
> @@ -750,8 +750,15 @@ static int __maybe_unused rt5682_dev_resume(struct device *dev)
> if (!rt5682->first_hw_init)
> return 0;
>
> - if (!slave->unattach_request)
> + if (!slave->unattach_request) {
> + if (rt5682->disable_irq == true) {
> + mutex_lock(&rt5682->disable_irq_lock);
> + sdw_write_no_pm(slave, SDW_SCP_INTMASK1, SDW_SCP_INT1_IMPL_DEF);
> + rt5682->disable_irq = false;
> + mutex_unlock(&rt5682->disable_irq_lock);
> + }
> goto regmap_sync;
> + }
>
> time = wait_for_completion_timeout(&slave->initialization_complete,
> msecs_to_jiffies(RT5682_PROBE_TIMEOUT));
next prev parent reply other threads:[~2023-07-03 10:18 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-03 9:02 [PATCH 1/5] ASoC: rt5682-sdw: fix for JD event handling in ClockStop Mode0 shumingf
2023-07-03 10:17 ` Pierre-Louis Bossart [this message]
2023-07-03 11:11 ` Shuming [范書銘]
2023-07-03 12:25 ` Pierre-Louis Bossart
2023-07-03 13:00 ` Shuming [范書銘]
2023-07-03 13:31 ` Mukunda,Vijendar
2023-07-03 14:20 ` Pierre-Louis Bossart
2023-07-03 14:46 ` Mukunda,Vijendar
2023-07-03 14:45 ` Pierre-Louis Bossart
2023-07-03 15:18 ` Mukunda,Vijendar
2023-07-03 17:18 ` Pierre-Louis Bossart
2023-07-04 6:36 ` Mukunda,Vijendar
2023-07-04 7:11 ` Pierre-Louis Bossart
2023-07-04 7:37 ` Mukunda,Vijendar
2023-07-04 8:27 ` Pierre-Louis Bossart
2023-07-04 9:03 ` Mukunda,Vijendar
2023-07-04 9:14 ` 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=f9e83b61-6e69-2467-d5a5-3c3a6a40e018@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=Vijendar.Mukunda@amd.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=derek.fang@realtek.com \
--cc=flove@realtek.com \
--cc=jack.yu@realtek.com \
--cc=lars@metafoo.de \
--cc=lgirdwood@gmail.com \
--cc=oder_chiou@realtek.com \
--cc=shumingf@realtek.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