> We can discuss that offline and come up with an approach that is > reviewable by maintainers and the community. Sure, looking forward to working together with you! Thanks, Albert Wang On Fri, Mar 15, 2024 at 4:57 AM Wesley Cheng <quic_wcheng@xxxxxxxxxxx> wrote: > > Hi Albert > > On 3/14/2024 3:29 AM, Albert Wang wrote: > > On Thu, Mar 14, 2024 at 3:18 AM Wesley Cheng <quic_wcheng@xxxxxxxxxxx> wrote: > >> > >> Hi Albert, > >> > >> On 3/13/2024 1:03 AM, Albert Wang wrote: > >>> Hi Wesley, > >>> > >>> The suspend function `qc_usb_audio_offload_suspend()` looks to stop > >>> the traffic on the bus, so that the bus can be suspended. That allows > >>> the application processor(AP) to enter suspend. There is a subtle > >>> difference with our feature, which is to allow AP suspend with the > >>> Host and USB controller active to continue the audio offloading. We > >>> call this feature `allow AP suspend in playback`. So, I have some > >>> points to clarify with you: > >> > >> Yes, I'm aware of that feature also. > >> > >>> 1. Will the suspend flow `usb_audio_suspend() --> > >>> platform_ops->suspend_cb() --> qc_usb_audio_offload_suspend()` be > >>> called when offloading is active? > >> > >> It can be. This is why in our case, we are going to issue the > >> disconnect event to the audio DSP to stop the session if it is currently > >> in one. > >> > >>> 2. As my understanding, the suspend function is to allow AP suspend > >>> when the offloading is IDLE, but it won't allow AP suspend when in > >>> playback or capture. Please correct me if anything is wrong. > >> > >> As mentioned above, it will let apps go into PM suspend after forcing > >> the audio stream to be idle. We won't block PM suspend entry. > >> > > Right. Your design is to force the audio stream idle, or say, inform > > the audio DSP > > to stop the current offloading session first, then AP can go into PM > > suspend as usual. > > Then I can say the current design did not support the `allow AP > > suspend in playback` > > feature, right? > > > > Correct, this series does not cover this mechanism. > > >> Yes, I saw that patch as well. I'll take a look once this series lands > >> upstream. > > > > That patch is rejected and archived now. So we need to find another > > approach to do > > that, even based on your framework. > > > > We can discuss that offline and come up with an approach that is > reviewable by maintainers and the community. > > Thanks > Wesley Cheng > > > Thanks, > > Albert > > > > > >>> 3. We would like to integrate the `allow AP suspend in playback` > >>> feature with your framework to become one upstream offload solution. > >>> Here is the patch: > >>> https://patchwork.kernel.org/project/linux-pm/patch/20240223143833.1509961-1-guanyulin@xxxxxxxxxx/ > >>> . > >> > >> Yes, I saw that patch as well. I'll take a look once this series lands > >> upstream. > >> > >> Thanks > >> Wesley Cheng
