linux-kernel - Re: [PATCH v18 20/41] ALSA: usb-audio: qcom: Introduce QC USB SND offloading support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0e9f0f2f-a404-3b76-3c52-9eca7594efa3@quicinc.com>
Date: Thu, 14 Mar 2024 13:57:19 -0700
From: Wesley Cheng <quic_wcheng@...cinc.com>
To: Albert Wang <albertccwang@...gle.com>
CC: <srinivas.kandagatla@...aro.org>, <mathias.nyman@...el.com>,
        <perex@...ex.cz>, <conor+dt@...nel.org>, <corbet@....net>,
        <lgirdwood@...il.com>, <andersson@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <gregkh@...uxfoundation.org>,
        <Thinh.Nguyen@...opsys.com>, <broonie@...nel.org>,
        <bgoswami@...cinc.com>, <tiwai@...e.com>, <robh+dt@...nel.org>,
        <konrad.dybcio@...aro.org>, <linux-kernel@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-sound@...r.kernel.org>,
        <linux-usb@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
        <linux-doc@...r.kernel.org>, <alsa-devel@...a-project.org>
Subject: Re: [PATCH v18 20/41] ALSA: usb-audio: qcom: Introduce QC USB SND
 offloading support

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@...cinc.com> 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@google.com/
>>> .
>>
>> Yes, I saw that patch as well.  I'll take a look once this series lands
>> upstream.
>>
>> Thanks
>> Wesley Cheng