Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: "Mukunda,Vijendar" <vijendar.mukunda@amd.com>,
	"Shuming [范書銘]" <shumingf@realtek.com>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"lgirdwood@gmail.com" <lgirdwood@gmail.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"lars@metafoo.de" <lars@metafoo.de>,
	"Flove(HsinFu)" <flove@realtek.com>,
	"Oder Chiou" <oder_chiou@realtek.com>,
	"Jack Yu" <jack.yu@realtek.com>,
	"Derek [方德義]" <derek.fang@realtek.com>,
	"Bard Liao" <yung-chuan.liao@linux.intel.com>,
	"Dommati, Sunil-kumar" <Sunil-kumar.Dommati@amd.com>,
	"Hiregoudar, Basavaraj" <Basavaraj.Hiregoudar@amd.com>
Subject: Re: [PATCH 1/5] ASoC: rt5682-sdw: fix for JD event handling in ClockStop Mode0
Date: Tue, 4 Jul 2023 09:11:49 +0200	[thread overview]
Message-ID: <ff732d09-b620-cdfd-d055-da116b99223c@linux.intel.com> (raw)
In-Reply-To: <abb4376e-15d3-6211-5024-03caf29c7a3f@amd.com>



On 7/4/23 08:36, Mukunda,Vijendar wrote:
> On 03/07/23 22:48, Pierre-Louis Bossart wrote:
>>
>> On 7/3/23 17:18, Mukunda,Vijendar wrote:
>>> On 03/07/23 20:15, Pierre-Louis Bossart wrote:
>>>> On 7/3/23 16:46, Mukunda,Vijendar wrote:
>>>>> On 03/07/23 19:50, Pierre-Louis Bossart wrote:
>>>>>> On 7/3/23 15:31, Mukunda,Vijendar wrote:
>>>>>>> On 03/07/23 18:30, Shuming [范書銘] wrote:
>>>>>>>>>>>> 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.
>>>>>>>>>> You are right. The commit message is wrong and not clear.
>>>>>>>>>> The situation is that the manager driver uses the clock stop mode0 to do
>>>>>>>>> system suspension.
>>>>>>>>>
>>>>>>>>> No it does not. The clock stop is ONLY used for pm_runtime, never for system
>>>>>>>>> suspend. We cannot go to system suspend with the link in clock-stop mode,
>>>>>>>>> that will create lots of issues, that's why we perform a full pm_runtime resume
>>>>>>>>> in the .prepare stage.
>>>>>>>> OK, I got your point. Thanks. However, this issue reported by AMD. 
>>>>>>>> The AMD platform validated system level pm and runtime pm ops with the different modes.
>>>>>>>>
>>>>>>>> Hi Vijendar,
>>>>>>>> Do you have any comments?
>>>>>>> On AMD platforms, we are supporting two power modes.
>>>>>>> 1) Bus reset mode
>>>>>>> 2) Clock Stop Mode
>>>>>>>
>>>>>>> In Bus reset mode, bus will re-enumerate the peripheral devices
>>>>>>> whereas in ClockStop Mode, applying ClockStop Mode0
>>>>>>> in both pm ops (runtime pm ops and system level pm ops).
>>>>>>>
>>>>>>> Currently, SDCA interrupts are disabled on peripheral side, when system level
>>>>>>> suspend is invoked.
>>>>>>> For ClockStop mode SDW manager is not receiving any jack alert when
>>>>>>> SoundWire manager device is in D3 state.
>>>>>> That was precisely the point of clock stop mode: a peripheral can
>>>>>> restart the system even when it's in lower-power mode.
>>>>>>
>>>>>> If there's no means to let a peripheral restart, the only benefit is
>>>>>> maybe to skip the enumeration time. That's not what the spec intended....
>>>>> As per our understanding, you are pointing to ClockStopMode1.
>>>>> ClockStopMode1 requires re-enumeration as peripherals move
>>>>> to unattached state.
>>>>> We have cross-checked ClockStopMode0 description in spec.
>>>>> It doesn't specify about peripheral device state as Unattached.
>>>>> We are referring here "ClockStopMode0" only.
>>>> No I was describing the difference between the 'Bus reset mode' and the
>>>> 'clock stop mode' on the manager side.
>>>>
>>>> There's also nothing in the spec preventing the manager from doing a
>>>> reset at any time, including after exiting the clock mode0 stop.
>>>>
>>>>
>>> Partly I agree.  As per our understanding, If any of the peripherals lost's sync,
>>> and re-enumeration is required.
>>> If continuous parity errors/bus clash conditions are reported over the link,
>>> Sdw Manager bus reset sequence should be invoked. This is a different scenario.
>>> Both the scenarios are asynchronous.
>>>  
>>> Going with Spec definition for ClockStopMode0, as it's Imp defined for
>>> SoundWire Manager, want to stick to Clockstop when D3 call is invoked
>>> and restore the clock when D0 call is invoked for our platforms.
>> The problem is that 'D3' can be used for two separate scenarios
>> - S0/D3: that's pm_runtime suspend
>> - Sx/D4: that's system suspend
>> It's very unclear what the benefit of clock stop mode would be for the
>> latter case.
>>
> We are pointing system level suspend scenario only.
> 
> We have already SoundWire Power off mode - ClockStop Mode will be
> applied followed by bus reset and SoundWire manager will be disabled.
> On parent side, ACP soft reset will be applied and ACP parent driver can
> wake for PME events for Soundwire manager.
> 
> Sx/D4 case, want to avoid re-enumeration when multiple peripherals are connected.
> For Clock Stop + Bus reset (keeping Sdw manager enabled), we can define a new power mode
> on SoundWire manager side.
> 
> Having said that, below are power modes we want to support on our side.
> 
> 1) Idle Mode - Don't stop the clock for SoundWire manager and Soundwire manager is not
> disabled during suspend callbacks.
> 2) ClockStop Mode - Only apply ClockStopMode0 on Soundwire manager side and restore
> the clock when resume sequence is invoked (even in case of system level suspend also)
> 3) ClockStop Mode + Bus reset - Apply ClockStopMode0 when Sound wire manager entering
> runtime suspend state. In system level resume case, apply clock stop exit and bus reset which
> will re-enumerate all peripheral devices over the links.
> 4) Power off mode: apply Clock Stop + SoundWire manager IP power off sequence.
> Parent device(ACP) will be powered off. ACP can wake up for in band wake-up events.
> 
> We expect if someone wants to go with only ClockStop mode, peripheral side also required
> support should be enabled.

I am not following any of this. You wrote both

"
For ClockStop mode SDW manager is not receiving any jack alert when
SoundWire manager device is in D3 state.
"

and

"
Parent device(ACP) will be powered off. ACP can wake up for in band
wake-up events.
"

I can't figure out how you deal with wake-ups and when exactly you
expect jack detection to be functional.

  reply	other threads:[~2023-07-04  7:13 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
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 [this message]
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=ff732d09-b620-cdfd-d055-da116b99223c@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=Basavaraj.Hiregoudar@amd.com \
    --cc=Sunil-kumar.Dommati@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=vijendar.mukunda@amd.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